* [PATCH 00/16] pinctrl: samsung: Usability and extensibiltiy improvements
From: Tomasz Figa @ 2012-10-10 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbUmM2=vhjhCq_qN2v=8RUDeWV4b8A8oXXPE4e8Z9C7zg@mail.gmail.com>
On Wednesday 10 of October 2012 09:46:28 Linus Walleij wrote:
> On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> > This patch series is a work on improving usability and extensibiltiy of
> > the>
> > pinctrl-samsung driver. It consists of three main parts:
> > - moving SoC-specific data to device tree
> > - converting the driver to use one GPIO chip and one IRQ domain per
> > pin bank - introducing generic wake-up interrupt capability
> > description
>
> So can you prepare a patch series which does all but the first
> bullet to begin with, and a SoC-and register offset patch
> on top of that as a separate series, because it is controversial?
>
> I don't like that these two things are mingled together like this
> in an all-or-nothing manner.
>
> So I'm OK with a patch series for bulle (2) and (3) but not (1).
>
> And I'd like to have Thomas A:s ACK on the series too.
>
I have managed to rework the changes to drop (1). I will send next version
of patches tomorrow. It would be nice to have them merged for 3.7, as they
are rather important for further work.
Moving data from the driver to device tree is not as important, so it might
be discussed later.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH 6/6] mfd: Differentiate between u8500 and u9540 TCDM address mapping
From: Lee Jones @ 2012-10-10 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349882335-6786-1-git-send-email-lee.jones@linaro.org>
The TCDM mappings are quite different from u8500 to u9540. If these
aren't correctly specified for a given board, it will fail to boot.
Here we add the correct TCDM base for the u9540.
Please note that although this patch allows us to boot the u9540,
it doesn't provide us with full enablement. For that, another
patch-set will follow which completely re-vamps the way the PRCMU
is passed TCDM mappings.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/db8500-prcmu.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 9d51585..fd0462a 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -2670,7 +2670,7 @@ static int db8500_irq_init(struct device_node *np)
void __init db8500_prcmu_early_init(void)
{
- if (cpu_is_u8500v2()) {
+ if (cpu_is_u8500v2() || cpu_is_u9540()) {
void *tcpm_base = ioremap_nocache(U8500_PRCMU_TCPM_BASE, SZ_4K);
if (tcpm_base != NULL) {
@@ -2688,7 +2688,11 @@ void __init db8500_prcmu_early_init(void)
iounmap(tcpm_base);
}
- tcdm_base = __io_address(U8500_PRCMU_TCDM_BASE);
+ if (cpu_is_u9540())
+ tcdm_base = ioremap_nocache(U8500_PRCMU_TCDM_BASE,
+ SZ_4K + SZ_8K) + SZ_8K;
+ else
+ tcdm_base = __io_address(U8500_PRCMU_TCDM_BASE);
} else {
pr_err("prcmu: Unsupported chip version\n");
BUG();
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/6] ARM: ux500: Enable SDI4 port on the u9540 when booting with Device Tree
From: Lee Jones @ 2012-10-10 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349882335-6786-1-git-send-email-lee.jones@linaro.org>
Here we add the device node for the SDI4 (MMC) port to the u9540
Device Tree source file. This will allow successful probing of
the internal MMC storage device when booting with DT enabled.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/u9540.dts | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/u9540.dts b/arch/arm/boot/dts/u9540.dts
index 28efe20..2dade76 100644
--- a/arch/arm/boot/dts/u9540.dts
+++ b/arch/arm/boot/dts/u9540.dts
@@ -21,7 +21,6 @@
};
soc-u9500 {
-
uart at 80120000 {
status = "okay";
};
@@ -33,5 +32,16 @@
uart at 80007000 {
status = "okay";
};
+
+ // On-board eMMC
+ sdi4_per2 at 80114000 {
+ arm,primecell-periphid = <0x10480180>;
+ max-frequency = <50000000>;
+ bus-width = <8>;
+ mmc-cap-mmc-highspeed;
+ vmmc-supply = <&ab8500_ldo_aux2_reg>;
+
+ status = "okay";
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/6] ARM: ux500: Add UART support to the u9540 Device Tree
From: Lee Jones @ 2012-10-10 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349882335-6786-1-git-send-email-lee.jones@linaro.org>
Add the 3 UART nodes required to enable serial ports on the u9540.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/u9540.dts | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/u9540.dts b/arch/arm/boot/dts/u9540.dts
index 0a66f34..28efe20 100644
--- a/arch/arm/boot/dts/u9540.dts
+++ b/arch/arm/boot/dts/u9540.dts
@@ -21,6 +21,17 @@
};
soc-u9500 {
- };
+ uart at 80120000 {
+ status = "okay";
+ };
+
+ uart at 80121000 {
+ status = "okay";
+ };
+
+ uart at 80007000 {
+ status = "okay";
+ };
+ };
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/6] ARM: ux500: Add support for ST-Ericsson's u9540 SoC
From: Lee Jones @ 2012-10-10 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349882335-6786-1-git-send-email-lee.jones@linaro.org>
First level board support for the u9540.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/cpu-db8500.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 3d8e321..6b7f970 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -17,6 +17,7 @@
#include <linux/platform_device.h>
#include <linux/io.h>
#include <linux/mfd/abx500/ab8500.h>
+#include <linux/mfd/dbx500-prcmu.h>
#include <linux/of.h>
#include <linux/of_platform.h>
#include <linux/regulator/machine.h>
@@ -319,6 +320,8 @@ static void __init u8500_init_machine(void)
snowball_pinmaps_init();
else if (of_machine_is_compatible("st-ericsson,hrefv60+"))
hrefv60_pinmaps_init();
+ else if (of_machine_is_compatible("st-ericsson,u9540")) {}
+ /* TODO: Add u9540 pinmaps. */
/* TODO: Export SoC, USB, cpu-freq and DMA40 */
parent = u8500_of_init_devices();
@@ -331,6 +334,7 @@ static const char * u8500_dt_board_compat[] = {
"calaosystems,snowball-a9500",
"st-ericsson,hrefv60+",
"st-ericsson,mop500",
+ "st-ericsson,u9540",
NULL,
};
@@ -345,4 +349,14 @@ DT_MACHINE_START(U8500_DT, "ST-Ericsson U8500 platform (Device Tree Support)")
.dt_compat = u8500_dt_board_compat,
MACHINE_END
+DT_MACHINE_START(U9540_DT, "ST-Ericsson 9540 platform (Device Tree Support)")
+ .map_io = u8500_map_io,
+ .init_irq = ux500_init_irq,
+ .timer = &ux500_timer,
+ .handle_irq = gic_handle_irq,
+ .init_machine = u8500_init_machine,
+ .init_late = NULL,
+ .dt_compat = u8500_dt_board_compat,
+MACHINE_END
+
#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/6] ARM: ux500: Add skeleton DTS file for the u9540
From: Lee Jones @ 2012-10-10 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349882335-6786-1-git-send-email-lee.jones@linaro.org>
This patch sees the creation of a sparse Device Tree file for
ST-Ericsson's latest development board supporting the latest
dual-core Cortex-a9 u9540 SoC.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/u9540.dts | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 arch/arm/boot/dts/u9540.dts
diff --git a/arch/arm/boot/dts/u9540.dts b/arch/arm/boot/dts/u9540.dts
new file mode 100644
index 0000000..0a66f34
--- /dev/null
+++ b/arch/arm/boot/dts/u9540.dts
@@ -0,0 +1,26 @@
+/*
+ * 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 {
+ };
+
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/6] ARM: ux500: Remove unused board compatible string
From: Lee Jones @ 2012-10-10 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349882335-6786-1-git-send-email-lee.jones@linaro.org>
'st-ericsson,u8500' is too much of a broad name to be used for
any of the supported development boards supported by ST-Ericsson.
As such it was never used. It has no place to remain in the board
compatible list, hence why it's being removed.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/mach-ux500/cpu-db8500.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 9f87b4d..3d8e321 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -330,7 +330,6 @@ static void __init u8500_init_machine(void)
static const char * u8500_dt_board_compat[] = {
"calaosystems,snowball-a9500",
"st-ericsson,hrefv60+",
- "st-ericsson,u8500",
"st-ericsson,mop500",
NULL,
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/6] Provide basic support for the u9540
From: Lee Jones @ 2012-10-10 15:18 UTC (permalink / raw)
To: linux-arm-kernel
After this patch-set has been applied the Mainline kernel
successfully boots on the u9540 development board. It is
by no means fully enabled, but it does provide solid
foundations for further development.
arch/arm/boot/dts/u9540.dts | 47 ++++++++++++++++++++++++++++++++++++++
arch/arm/mach-ux500/cpu-db8500.c | 15 +++++++++++-
drivers/mfd/db8500-prcmu.c | 8 +++++--
3 files changed, 67 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH 2/3] ARM: dts: Correcting size of memory defined for omap5
From: Benoit Cousson @ 2012-10-10 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349870716-25511-3-git-send-email-lokeshvutla@ti.com>
On 10/10/2012 02:05 PM, Lokesh Vutla wrote:
> Memory present for omap5 is 2GB. But in dt file
omap5 -> OMAP5
dt -> dts
And this patch is about omap5-evm so you should be more specific in your
changelog and even in the subject:
ARM: dts: omap5-evm: Fix size of memory defined for EVM
> it is specified as 1GB. Correcting the same
> in this patch
No "patch" in the changelog, please add a dot at the end of a sentence
and make a correct sentence.
Regards,
Benoit
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> arch/arm/boot/dts/omap5-evm.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
> index 9c41a3f..6f87e1a 100644
> --- a/arch/arm/boot/dts/omap5-evm.dts
> +++ b/arch/arm/boot/dts/omap5-evm.dts
> @@ -15,7 +15,7 @@
>
> memory {
> device_type = "memory";
> - reg = <0x80000000 0x40000000>; /* 1 GB */
> + reg = <0x80000000 0x80000000>; /* 2 GB */
> };
>
> vmmcsd_fixed: fixedregulator-mmcsd {
>
^ permalink raw reply
* [PATCH 3/3] ARM: dts: EMIF and LPDDR2 device tree data for OMAP5 boards
From: Benoit Cousson @ 2012-10-10 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349870716-25511-4-git-send-email-lokeshvutla@ti.com>
On 10/10/2012 02:05 PM, Lokesh Vutla wrote:
> Device tree data for the EMIF sdram controllers in OMAP5
> and LPDDR2 memory devices attached to OMAP5 boards.
Nit: Could you make a sentence with a verb to explain what you are doing
in this patch.
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> arch/arm/boot/dts/lpddr2_data.dtsi | 64 +++++++++++++++++++++++++++++++++++-
> arch/arm/boot/dts/omap5-evm.dts | 11 +++++++
> arch/arm/boot/dts/omap5.dtsi | 18 ++++++++++
> 3 files changed, 92 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/lpddr2_data.dtsi b/arch/arm/boot/dts/lpddr2_data.dtsi
> index f97f70f..8e8c1bc 100644
> --- a/arch/arm/boot/dts/lpddr2_data.dtsi
> +++ b/arch/arm/boot/dts/lpddr2_data.dtsi
> @@ -3,7 +3,7 @@
> */
>
> / {
> - elpida_ECB240ABACN: lpddr2 {
> + elpida_ECB240ABACN: lpddr2 at 0 {
> compatible = "Elpida,ECB240ABACN","jedec,lpddr2-s4";
> density = <2048>;
> io-width = <32>;
> @@ -64,4 +64,66 @@
> tDQSCK-max-derated = <6000>;
> };
> };
> +
> + samsung_K3PE0E000B: lpddr2 at 1 {
I'm confused now, why are you reusing the same lpddr2_data.dtsi file?
You should create a file per memory. That will make the reuse much easier.
If the goal of your first patch was to do that, it is then the wrong
approach.
> + compatible = "Samsung,K3PE0E000B","jedec,lpddr2-s4";
> + density = <4096>;
> + io-width = <32>;
> +
> + tRPab-min-tck = <3>;
> + tRCD-min-tck = <3>;
> + tWR-min-tck = <3>;
> + tRASmin-min-tck = <3>;
> + tRRD-min-tck = <2>;
> + tWTR-min-tck = <2>;
> + tXP-min-tck = <2>;
> + tRTP-min-tck = <2>;
> + tCKE-min-tck = <3>;
> + tCKESR-min-tck = <3>;
> + tFAW-min-tck = <8>;
> +
> + timings_samsung_K3PE0E000B_533mhz: lpddr2-timings at 0 {
> + compatible = "jedec,lpddr2-timings";
> + min-freq = <10000000>;
> + max-freq = <533333333>;
> + tRPab = <21000>;
> + tRCD = <18000>;
> + tWR = <15000>;
> + tRAS-min = <42000>;
> + tRRD = <10000>;
> + tWTR = <7500>;
> + tXP = <7500>;
> + tRTP = <7500>;
> + tCKESR = <15000>;
> + tDQSCK-max = <5500>;
> + tFAW = <50000>;
> + tZQCS = <90000>;
> + tZQCL = <360000>;
> + tZQinit = <1000000>;
> + tRAS-max-ns = <70000>;
> + tDQSCK-max-derated = <5620>;
> + };
> +
> + timings_samsung_K3PE0E000B_266mhz: lpddr2-timings at 1 {
> + compatible = "jedec,lpddr2-timings";
> + min-freq = <10000000>;
> + max-freq = <266666666>;
> + tRPab = <21000>;
> + tRCD = <18000>;
> + tWR = <15000>;
> + tRAS-min = <42000>;
> + tRRD = <10000>;
> + tWTR = <7500>;
> + tXP = <7500>;
> + tRTP = <7500>;
> + tCKESR = <15000>;
> + tDQSCK-max = <5500>;
> + tFAW = <50000>;
> + tZQCS = <90000>;
> + tZQCL = <360000>;
> + tZQinit = <1000000>;
> + tRAS-max-ns = <70000>;
> + tDQSCK-max-derated = <6000>;
> + };
> + };
> };
> diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
> index 6f87e1a..8a952f8 100644
> --- a/arch/arm/boot/dts/omap5-evm.dts
> +++ b/arch/arm/boot/dts/omap5-evm.dts
> @@ -8,6 +8,7 @@
> /dts-v1/;
>
> /include/ "omap5.dtsi"
> +/include/ "lpddr2_data.dtsi"
>
> / {
> model = "TI OMAP5 EVM board";
> @@ -82,3 +83,13 @@
> 0x020700d9>; /* SEARCH */
> linux,input-no-autorepeat;
> };
> +
> +&emif1 {
> + cs1-used;
> + device-handle = <&samsung_K3PE0E000B>;
> +};
> +
> +&emif2 {
> + cs1-used;
> + device-handle = <&samsung_K3PE0E000B>;
> +};
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 5db33f4..40b41c2 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -319,5 +319,23 @@
> ti,buffer-size = <128>;
> ti,hwmods = "mcbsp3";
> };
> +
> + emif1: emif at 0x4c000000 {
> + compatible = "ti,emif-4d5";
> + ti,hwmods = "emif1";
> + phy-type = <2>;
> + hw-caps-read-idle-ctrl;
> + hw-caps-ll-interface;
> + hw-caps-temp-alert;
You should now add the reg, and interrupt attributes as well.
Regards,
Benoit
^ permalink raw reply
* [GIT PULL 0/9] ARM architecture fixes for 3.7
From: Stefano Stabellini @ 2012-10-10 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210091840.25176.arnd@arndb.de>
On Tue, 9 Oct 2012, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Russell King - ARM Linux wrote:
> >
> > On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > > Here are some patches that belong into your domain, I hope you can
> > > just send the lot to Linus the next time you send other patches.
> > >
> > > These bug fixes all address problems found with automated build testing.
> > > Some of them have been around for a long time, other bugs are
> > > regressions since the merge window.
> >
> > Apart from the sliced off comment in one commit (which XEN people need
> > to confirm they're happy with the final version), I think these are
> > otherwise fine... I'll hold off pulling them until that can be fixed.
>
> Fixed that now, and I also added the Acks that I got in the meantime,
> changed the dependency from Xen on (CPU_v7 && !CPU_V6), and edited the
> description for patch 6 as Dave suggested.
Thanks for the update, the new Xen patch is fine by me
^ permalink raw reply
* [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
From: Ian Campbell @ 2012-10-10 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1210101544500.2689@kaball.uk.xensource.com>
On Wed, 2012-10-10 at 15:47 +0100, Stefano Stabellini wrote:
> On Wed, 10 Oct 2012, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > > > config XEN
> > > > > bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > > > depends on EXPERIMENTAL && ARM && OF
> > > > > + depends on !CPU_V6
> > > > > help
> > > > > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > > >
> > > > Considering that we rely on the virtualization extensions, this one can
> > > > be:
> > > >
> > > > depends on CPU_V7
> > > >
> > > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > > CPU_V7 later, if you prefer.
> > >
> > > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > > with virtualization extensions, but that is a different issue. We don't
> > > actually have a configuration symbol for that yet, as far as I can tell.
> >
> > I don't think the guest kernels (including dom0) need the extensions to
> > run under Xen, they are only need by Xen itself. The guests should just
> > see a relatively normal v7 processor.
> >
> > Stefano, does that sound right?
>
> Keep in mind that we are using HVC to issue hypercalls, and HVC has been
> introduced with the virtualization extensions, if I am not mistaken.
I think we can ignore that in this context since it is only used by bits
which are already virtualisation aware -- i.e. you wouldn't want to add
it to the Kconfig as a dependency for Xen.
Ian.
^ permalink raw reply
* [PATCH 1/3] ARM: dts: Renaming elpida_ecb240abacn.dtsi as lpddr2_data.dtsi
From: Benoit Cousson @ 2012-10-10 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349870716-25511-2-git-send-email-lokeshvutla@ti.com>
Hi Lokesh,
On 10/10/2012 02:05 PM, Lokesh Vutla wrote:
> Renaming elpida_ecb240abacn.dtsi file generic, so that the
> same file can be reused for other parts from different vendors.
Could you elaborate a little bit?
Are these settings purely reflecting lpddr2 spec timings?
Regards,
Benoit
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> arch/arm/boot/dts/{elpida_ecb240abacn.dtsi => lpddr2_data.dtsi} | 0
> arch/arm/boot/dts/omap4-panda.dts | 2 +-
> arch/arm/boot/dts/omap4-sdp.dts | 2 +-
> 3 files changed, 2 insertions(+), 2 deletions(-)
> rename arch/arm/boot/dts/{elpida_ecb240abacn.dtsi => lpddr2_data.dtsi} (100%)
>
> diff --git a/arch/arm/boot/dts/elpida_ecb240abacn.dtsi b/arch/arm/boot/dts/lpddr2_data.dtsi
> similarity index 100%
> rename from arch/arm/boot/dts/elpida_ecb240abacn.dtsi
> rename to arch/arm/boot/dts/lpddr2_data.dtsi
> diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
> index 20b966e..09d3a32 100644
> --- a/arch/arm/boot/dts/omap4-panda.dts
> +++ b/arch/arm/boot/dts/omap4-panda.dts
> @@ -8,7 +8,7 @@
> /dts-v1/;
>
> /include/ "omap4.dtsi"
> -/include/ "elpida_ecb240abacn.dtsi"
> +/include/ "lpddr2_data.dtsi"
>
> / {
> model = "TI OMAP4 PandaBoard";
> diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
> index 94a23b3..dd749fc 100644
> --- a/arch/arm/boot/dts/omap4-sdp.dts
> +++ b/arch/arm/boot/dts/omap4-sdp.dts
> @@ -8,7 +8,7 @@
> /dts-v1/;
>
> /include/ "omap4.dtsi"
> -/include/ "elpida_ecb240abacn.dtsi"
> +/include/ "lpddr2_data.dtsi"
>
> / {
> model = "TI OMAP4 SDP board";
>
^ permalink raw reply
* [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
From: Stefano Stabellini @ 2012-10-10 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349855687.6952.75.camel@dagon.hellion.org.uk>
On Wed, 10 Oct 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > > config XEN
> > > > bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > > depends on EXPERIMENTAL && ARM && OF
> > > > + depends on !CPU_V6
> > > > help
> > > > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > >
> > > Considering that we rely on the virtualization extensions, this one can
> > > be:
> > >
> > > depends on CPU_V7
> > >
> > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > CPU_V7 later, if you prefer.
> >
> > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > with virtualization extensions, but that is a different issue. We don't
> > actually have a configuration symbol for that yet, as far as I can tell.
>
> I don't think the guest kernels (including dom0) need the extensions to
> run under Xen, they are only need by Xen itself. The guests should just
> see a relatively normal v7 processor.
>
> Stefano, does that sound right?
Keep in mind that we are using HVC to issue hypercalls, and HVC has been
introduced with the virtualization extensions, if I am not mistaken.
^ permalink raw reply
* [PATCH] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Matt Porter @ 2012-10-10 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121010143501.GC13724@beef>
On Wed, Oct 10, 2012 at 10:35:01AM -0400, Matt Porter wrote:
> On Wed, Oct 10, 2012 at 02:19:40PM +0000, Vaibhav Hiremath wrote:
> > On Wed, Oct 10, 2012 at 19:30:27, Porter, Matt wrote:
> > > On Tue, Oct 09, 2012 at 02:27:20PM +0530, Vaibhav Hiremath wrote:
> > > > With recent changes in omap gpmc driver code, in case of DT
> > > > boot mode, where bootloader does not configure gpmc cs space
> > > > will result into kernel BUG() inside gpmc_mem_init() function,
> > > > as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
> > > > gpmc_config7[0].baseaddress is set to '0' on reset.
> > > >
> > > > This use-case is applicable for any board/EVM which doesn't have
> > > > any peripheral connected to gpmc cs0, for example BeagleXM and
> > > > BeagleBone, so DT boot mode fails.
> > > >
> > > > This patch adds of_have_populated_dt() check before creating
> > > > device, so that for DT boot mode, gpmc probe will not be called
> > > > which is expected behavior, as gpmc is not supported yet from DT.
> > > >
> > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > > > Cc: Afzal Mohammed <afzal@ti.com>
> > > > Cc: Tony Lindgren <tony@atomide.com>
> > > > Cc Paul Walmsley <paul@pwsan.com>
> > > > ---
> > > > This should go in for rc1, as this breaks AM33xx boot.
> > >
> > > Fixes BeagleBone on mainline.
> > >
> > > Tested-by: Matt Porter <mporter@ti.com>
> > >
> >
> > Thanks Matt and Afzal,
> >
> > Tony can this be picked up for rc1?? I know you have already sent pull
> > request for rc1, but by any chance you are planning to send another request?
>
> I also found a separate problem with the mcasp clock data that's needed
> for rc1. I just posted a patch for that as I need both this patch and the
> clock data fix to boot from current mainline.
Disregard now that you got me pointed to the pull request with this :)
-Matt
^ permalink raw reply
* [PATCH] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries
From: Matt Porter @ 2012-10-10 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB3B5BD@DBDE01.ent.ti.com>
On Wed, Oct 10, 2012 at 02:33:54PM +0000, Vaibhav Hiremath wrote:
> On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote:
> > 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage
> > exposes a bug in the AM33XX clock data for mcasp. After moving to
> > clk_get() usage, the _init() of all registered hwmods fails on mcasp0
> > due to incorrect clock data causing clk_get() to fail. This causes all
> > successive hwmods to fail to _init() leaving them in a bad state.
> >
> > This patch updates the mcasp clock entries so clk_get() will succeed.
> > It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx
> > boot.
> >
>
> Matt,
>
> I have already submitted patch for this and it is accepted and merged in
> Tony's pull request.
>
> https://patchwork.kernel.org/patch/1499271/
Heh, ok. My search skills failed badly when I ran into this.
Thanks :)
-Matt
^ permalink raw reply
* [PATCH 02/13] clk: davinci - add PSC clock driver
From: Karicheri, Muralidharan @ 2012-10-10 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50756B96.1070008@ti.com>
>> -----Original Message-----
>> From: Nori, Sekhar
>> Sent: Wednesday, October 10, 2012 8:36 AM
>> To: Karicheri, Muralidharan
>> Cc: mturquette at linaro.org; arnd at arndb.de; akpm at linux-foundation.org;
>> shawn.guo at linaro.org; rob.herring at calxeda.com; linus.walleij at linaro.org;
>> viresh.linux at gmail.com; linux-kernel at vger.kernel.org; Hilman, Kevin;
>> linux at arm.linux.org.uk; davinci-linux-open-source at linux.davincidsp.com; linux-arm-
>> kernel at lists.infradead.org; linux-keystone at list.ti.com - Linux developers for Keystone
>> family of devices (May contain non-TIers); linux-c6x-dev at linux-c6x.org; Chemparathy,
>> Cyril
>> Subject: Re: [PATCH 02/13] clk: davinci - add PSC clock driver
>>
>> On 9/26/2012 11:37 PM, Murali Karicheri wrote:
>> > This is the driver for the Power Sleep Controller (PSC) hardware found
>> > on DM SoCs as well Keystone SoCs (c6x). This driver borrowed code from
>> > arch/arm/mach-davinci/psc.c and implemented the driver as per common
>> > clock provider API. The PSC module is responsible for
>> > enabling/disabling the Power Domain and Clock domain for different IPs
>> > present in the SoC. The driver is configured through the platform data
>> > structure struct clk_davinci_psc_data.
>> >
>> > Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>> >
>> > diff --git a/drivers/clk/davinci/clk-davinci-psc.c
>> > b/drivers/clk/davinci/clk-davinci-psc.c
>> > new file mode 100644
>> > index 0000000..b7aa332
>> > --- /dev/null
>> > +++ b/drivers/clk/davinci/clk-davinci-psc.c
>> > @@ -0,0 +1,197 @@
>> > +/*
>> > + * PSC clk driver for DaVinci devices
>> > + *
>> > + * Copyright (C) 2006-2012 Texas Instruments.
>> > + * Copyright (C) 2008-2009 Deep Root Systems, LLC
>> > + *
>> > + * 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/clk-provider.h>
>> > +#include <linux/delay.h>
>> > +#include <linux/err.h>
>> > +#include <linux/io.h>
>> > +#include <linux/slab.h>
>> > +#include <linux/platform_data/clk-davinci-psc.h>
>>
>> Sort these alphabetically.
>>
>> > +
>> > +/* PSC register offsets */
>> > +#define EPCPR 0x070
>> > +#define PTCMD 0x120
>> > +#define PTSTAT 0x128
>> > +#define PDSTAT 0x200
>> > +#define PDCTL 0x300
>> > +#define MDSTAT 0x800
>> > +#define MDCTL 0xA00
>> > +
>> > +/* PSC module states */
>> > +#define PSC_STATE_SWRSTDISABLE 0
>> > +#define PSC_STATE_SYNCRST 1
>> > +#define PSC_STATE_DISABLE 2
>> > +#define PSC_STATE_ENABLE 3
>> > +
>> > +#define MDSTAT_STATE_MASK 0x3f
>> > +#define PDSTAT_STATE_MASK 0x1f
>> > +#define MDCTL_FORCE BIT(31)
>> > +#define PDCTL_NEXT BIT(0)
>> > +#define PDCTL_EPCGOOD BIT(8)
>> > +
>> > +/* PSC flags */
>> > +#define PSC_SWRSTDISABLE BIT(0) /* Disable state is SwRstDisable */
>> > +#define PSC_FORCE BIT(1) /* Force module state transtition */
>> > +#define PSC_HAS_EXT_POWER_CNTL BIT(2) /* PSC has external power control
>> > + * available (for DM6446 SoC) */
>>
>> Can you try and keep the comment above on a single line?
>>
>> > +/**
>> > + * struct clk_psc - DaVinci PSC clock
>> > + * @hw: clk_hw for the psc
>> > + * @psc_data: PSC driver specific data
>> > + * @lock: Spinlock used by the driver */ struct clk_psc {
>> > + struct clk_hw hw;
>> > + struct clk_davinci_psc_data *psc_data;
>> > + spinlock_t *lock;
>> > +};
>> > +
>> > +#define to_clk_psc(_hw) container_of(_hw, struct clk_psc, hw)
>> > +
>> > +/* Enable or disable a PSC domain */
>> > +static void clk_psc_config(void __iomem *base, unsigned int domain,
>> > + unsigned int id, bool enable, u32 flags) {
>> > + u32 epcpr, ptcmd, ptstat, pdstat, pdctl, mdstat, mdctl;
>> > + u32 next_state = PSC_STATE_ENABLE;
>> > + void __iomem *psc_base = base;
>> > +
>> > + if (!enable) {
>> > + if (flags & PSC_SWRSTDISABLE)
>> > + next_state = PSC_STATE_SWRSTDISABLE;
>> > + else
>> > + next_state = PSC_STATE_DISABLE;
>> > + }
>> > +
>> > + mdctl = __raw_readl(psc_base + MDCTL + 4 * id);
>>
>> Please convert all __raw_ variants to simple readl/writel() calls.
>>
>> > + mdctl &= ~MDSTAT_STATE_MASK;
>> > + mdctl |= next_state;
>> > + if (flags & PSC_FORCE)
>> > + mdctl |= MDCTL_FORCE;
>> > + __raw_writel(mdctl, psc_base + MDCTL + 4 * id);
>> > +
>> > + pdstat = __raw_readl(psc_base + PDSTAT + 4 * domain);
>> > + if ((pdstat & PDSTAT_STATE_MASK) == 0) {
>> > + pdctl = __raw_readl(psc_base + PDCTL + 4 * domain);
>> > + pdctl |= PDCTL_NEXT;
>> > + __raw_writel(pdctl, psc_base + PDCTL + 4 * domain);
>> > +
>> > + ptcmd = 1 << domain;
>> > + __raw_writel(ptcmd, psc_base + PTCMD);
>> > +
>> > + if (flags & PSC_HAS_EXT_POWER_CNTL) {
>> > + do {
>> > + epcpr = __raw_readl(psc_base + EPCPR);
>> > + } while ((((epcpr >> domain) & 1) == 0));
>> > + }
>> > +
>> > + pdctl = __raw_readl(psc_base + PDCTL + 4 * domain);
>> > + pdctl |= 0x100;
>> > + __raw_writel(pdctl, psc_base + PDCTL + 4 * domain);
>> > +
>> > + pdctl = __raw_readl(psc_base + PDCTL + 4 * domain);
>> > + pdctl |= PDCTL_EPCGOOD;
>> > + __raw_writel(pdctl, psc_base + PDCTL + 4 * domain);
>> > + } else {
>> > + ptcmd = 1 << domain;
>> > + __raw_writel(ptcmd, psc_base + PTCMD);
>> > + }
>> > +
>> > + do {
>> > + ptstat = __raw_readl(psc_base + PTSTAT);
>> > + } while (!(((ptstat >> domain) & 1) == 0));
>> > +
>> > + do {
>> > + mdstat = __raw_readl(psc_base + MDSTAT + 4 * id);
>> > + } while (!((mdstat & MDSTAT_STATE_MASK) == next_state)); }
>> > +
>> > +static int clk_psc_is_enabled(struct clk_hw *hw) {
>> > + struct clk_psc *psc = to_clk_psc(hw);
>> > + struct clk_davinci_psc_data *psc_data = psc->psc_data;
>> > + u32 mdstat;
>> > +
>> > + mdstat = __raw_readl(psc_data->base + MDSTAT + 4 * psc_data->lpsc);
>> > + /* if clocked, state can be "Enable" or "SyncReset" */
>> > + return (mdstat & BIT(12)) ? 1 : 0;
>>
>> Can you include a blank line before the return. Also, since the API seems to expect a 0 or
>> 1, you can simply do:
>>
>> return !!(mdstat & BIT(12);
>>
>> > +}
>> > +
>> > +static int clk_psc_enable(struct clk_hw *hw) {
>> > + struct clk_psc *psc = to_clk_psc(hw);
>> > + struct clk_davinci_psc_data *psc_data = psc->psc_data;
>> > + unsigned long flags = 0;
>>
>> No need to initialize flags here.
>>
>> > +
>> > + if (psc->lock)
>> > + spin_lock_irqsave(psc->lock, flags);
>>
>> Is locking really optional here?
>>
>> > +
>> > + clk_psc_config(psc_data->base, psc_data->domain, psc_data->lpsc,
>> > + 1, psc_data->psc_flags);
>> > +
>> > + if (psc->lock)
>> > + spin_unlock_irqrestore(psc->lock, flags);
>> > +
>> > + return 0;
>> > +}
>> > +
>> > +static void clk_psc_disable(struct clk_hw *hw) {
>> > + struct clk_psc *psc = to_clk_psc(hw);
>> > + struct clk_davinci_psc_data *psc_data = psc->psc_data;
>> > + unsigned long flags = 0;
>> > +
>> > + if (psc->lock)
>> > + spin_lock_irqsave(psc->lock, flags);
>> > +
>> > + clk_psc_config(psc_data->base, psc_data->domain, psc_data->lpsc,
>> > + 0, psc_data->psc_flags);
>> > +
>> > + if (psc->lock)
>> > + spin_unlock_irqrestore(psc->lock, flags); }
>> > +
>> > +static const struct clk_ops clk_psc_ops = {
>> > + .enable = clk_psc_enable,
>> > + .disable = clk_psc_disable,
>> > + .is_enabled = clk_psc_is_enabled,
>> > +};
>> > +
>> > +struct clk *clk_register_davinci_psc(struct device *dev, const char *name,
>> > + const char *parent_name,
>> > + struct clk_davinci_psc_data *psc_data,
>> > + spinlock_t *lock)
>>
>> Why do you need the lock to be provided from outside of this file? You can initialize a lock
>> for serializing writes to PSC registers within this file, no?
>>
>> > +{
>> > + struct clk_init_data init;
>> > + struct clk_psc *psc;
>> > + struct clk *clk;
>> > +
>> > + psc = kzalloc(sizeof(*psc), GFP_KERNEL);
>> > + if (!psc)
>> > + return ERR_PTR(-ENOMEM);
>> > +
>> > + init.name = name;
>> > + init.ops = &clk_psc_ops;
>> > + init.flags = psc_data->flags;
>> > + init.parent_names = (parent_name ? &parent_name : NULL);
>> > + init.num_parents = (parent_name ? 1 : 0);
>> > +
>> > + psc->psc_data = psc_data;
>> > + psc->lock = lock;
>> > + psc->hw.init = &init;
>> > +
>> > + clk = clk_register(NULL, &psc->hw);
>> > + if (IS_ERR(clk))
>> > + kfree(psc);
>> > +
>> > + return clk;
>> > +}
>>
>> I guess, an unregister API will be useful here as well.
>>
>> > diff --git a/include/linux/platform_data/clk-davinci-psc.h
>> > b/include/linux/platform_data/clk-davinci-psc.h
>> > new file mode 100644
>> > index 0000000..b805f72
>> > --- /dev/null
>> > +++ b/include/linux/platform_data/clk-davinci-psc.h
>> > @@ -0,0 +1,53 @@
>> > +/*
>> > + * DaVinci Power & Sleep Controller (PSC) clk driver platform data
>> > + *
>> > + * Copyright (C) 2006-2012 Texas Instruments.
>> > + *
>> > + * 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 SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
>> > + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
>> OF
>> > + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
>> DISCLAIMED. IN
>> > + * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
>> > + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
>> (INCLUDING, BUT
>> > + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
>> LOSS OF
>> > + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
>> > +AND ON
>> > + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
>> > +OR TORT
>> > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
>> > +USE OF
>> > + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>>
>> Is this taken from GPL text? There should be no need to have this here.
>>
>> > + *
>> > + * 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.,
>> > + * 675 Mass Ave, Cambridge, MA 02139, USA.
>>
>> This is not needed as well. ;-)
>>
>> Thanks,
>> Sekhar
Thanks. I will take care of this in the next revision.
Murali
^ permalink raw reply
* [PATCH] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Matt Porter @ 2012-10-10 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB3B573@DBDE01.ent.ti.com>
On Wed, Oct 10, 2012 at 02:19:40PM +0000, Vaibhav Hiremath wrote:
> On Wed, Oct 10, 2012 at 19:30:27, Porter, Matt wrote:
> > On Tue, Oct 09, 2012 at 02:27:20PM +0530, Vaibhav Hiremath wrote:
> > > With recent changes in omap gpmc driver code, in case of DT
> > > boot mode, where bootloader does not configure gpmc cs space
> > > will result into kernel BUG() inside gpmc_mem_init() function,
> > > as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
> > > gpmc_config7[0].baseaddress is set to '0' on reset.
> > >
> > > This use-case is applicable for any board/EVM which doesn't have
> > > any peripheral connected to gpmc cs0, for example BeagleXM and
> > > BeagleBone, so DT boot mode fails.
> > >
> > > This patch adds of_have_populated_dt() check before creating
> > > device, so that for DT boot mode, gpmc probe will not be called
> > > which is expected behavior, as gpmc is not supported yet from DT.
> > >
> > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > > Cc: Afzal Mohammed <afzal@ti.com>
> > > Cc: Tony Lindgren <tony@atomide.com>
> > > Cc Paul Walmsley <paul@pwsan.com>
> > > ---
> > > This should go in for rc1, as this breaks AM33xx boot.
> >
> > Fixes BeagleBone on mainline.
> >
> > Tested-by: Matt Porter <mporter@ti.com>
> >
>
> Thanks Matt and Afzal,
>
> Tony can this be picked up for rc1?? I know you have already sent pull
> request for rc1, but by any chance you are planning to send another request?
I also found a separate problem with the mcasp clock data that's needed
for rc1. I just posted a patch for that as I need both this patch and the
clock data fix to boot from current mainline.
-Matt
^ permalink raw reply
* [PATCH 01/13] calk: davinci - add Main PLL clock driver
From: Karicheri, Muralidharan @ 2012-10-10 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507563C3.2000305@ti.com>
>> -----Original Message-----
>> From: Nori, Sekhar
>> Sent: Wednesday, October 10, 2012 8:02 AM
>> To: Karicheri, Muralidharan
>> Cc: mturquette at linaro.org; arnd at arndb.de; akpm at linux-foundation.org;
>> shawn.guo at linaro.org; rob.herring at calxeda.com; linus.walleij at linaro.org;
>> viresh.linux at gmail.com; linux-kernel at vger.kernel.org; Hilman, Kevin;
>> linux at arm.linux.org.uk; davinci-linux-open-source at linux.davincidsp.com; linux-arm-
>> kernel at lists.infradead.org; linux-keystone at list.ti.com - Linux developers for Keystone
>> family of devices (May contain non-TIers); linux-c6x-dev at linux-c6x.org; Chemparathy,
>> Cyril
>> Subject: Re: [PATCH 01/13] clk: davinci - add Main PLL clock driver
>>
>> Hi Murali,
>>
>> On 9/26/2012 11:37 PM, Murali Karicheri wrote:
>> > This is the driver for the main PLL clock hardware found on DM SoCs.
>> > This driver borrowed code from arch/arm/mach-davinci/clock.c and
>> > implemented the driver as per common clock provider API. The main PLL
>> > hardware typically has a multiplier, a pre-divider and a post-divider.
>> > Some of the SoCs has the divider fixed meaning they can not be
>> > configured through a register. HAS_PREDIV and HAS_POSTDIV flags are
>> > used to tell the driver if a hardware has these dividers present or not.
>> > Driver is configured through the structure clk_davinci_pll_data that
>> > has the platform data for the driver.
>> >
>> > Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>>
>> Are you using git-format-patch to generate the patches? It should have added a diffstat
>> here by default which is very useful in quickly understanding what the patch is touching.
>> >
>> > diff --git a/drivers/clk/davinci/clk-davinci-pll.c
>> > b/drivers/clk/davinci/clk-davinci-pll.c
>> > new file mode 100644
>> > index 0000000..13e1690
>> > --- /dev/null
>> > +++ b/drivers/clk/davinci/clk-davinci-pll.c
>> > @@ -0,0 +1,128 @@
>> > +/*
>> > + * PLL clk driver DaVinci devices
>> > + *
>> > + * Copyright (C) 2006-2012 Texas Instruments.
>> > + * Copyright (C) 2008-2009 Deep Root Systems, LLC
>> > + *
>> > + * 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.
>> > + * TODO - Add set_parent_rate()
>> > + */
>> > +#include <linux/clk.h>
>> > +#include <linux/clk-provider.h>
>> > +#include <linux/delay.h>
>> > +#include <linux/err.h>
>> > +#include <linux/io.h>
>> > +#include <linux/slab.h>
>> > +#include <linux/platform_data/clk-davinci-pll.h>
>>
>> It will be nice to keep these sorted in alphabetical order. You got it almost right, except
>> the last one. Keeping it sorted keeps out duplicates.
>>
>> > +
>> > +#include <mach/cputype.h>
>>
>> Hmm, why is this needed? mach/ includes in driver files make it tough to use this on
>> other architectures/machines. You have plan to use this on driver on keystone and c6x as
>> well, right? It will also break multi-platform ARM build.
>>
>> > +
>> > +#define PLLM 0x110
>> > +#define PLLM_PLLM_MASK 0xff
>> > +#define PREDIV 0x114
>> > +#define POSTDIV 0x128
>> > +#define PLLDIV_EN BIT(15)
>>
>> Can you use tabs for indentation?
>>
>> > +
>> > +/**
>> > + * struct clk_davinci_pll - DaVinci Main pll clock
>>
>> no capitalization on 'M' needed, I think.
>>
>> > + * @hw: clk_hw for the pll
>> > + * @pll_data: PLL driver specific data */ struct clk_davinci_pll {
>> > + struct clk_hw hw;
>> > + struct clk_davinci_pll_data *pll_data; };
>> > +
>> > +#define to_clk_pll(_hw) container_of(_hw, struct clk_davinci_pll, hw)
>> > +
>> > +static unsigned long clk_pllclk_recalc(struct clk_hw *hw,
>> > + unsigned long parent_rate)
>> > +{
>> > + struct clk_davinci_pll *pll = to_clk_pll(hw);
>> > + struct clk_davinci_pll_data *pll_data = pll->pll_data;
>> > + u32 mult = 1, prediv = 1, postdiv = 1;
>>
>> No need to initialize mult here since you are doing it right away below.
>>
>> > + unsigned long rate = parent_rate;
>> > +
>> > + /* If there is a device specific recalc defined invoke it. Otherwise
>> > + * fallback to default one
>> > + */
>>
>> This is not following the multi-line comment style defined in Documentation/CodingStyle.
>>
>> > + mult = __raw_readl(pll_data->pllm);
>>
>> Do not use __raw_ variants since they are not safe on ARMv7. Use readl/writel instead.
>>
>> > + if (pll_data->pllm_multiplier)
>> > + mult = pll_data->pllm_multiplier *
>> > + (mult & pll_data->pllm_mask);
>> > + else
>> > + mult = (mult & pll_data->pllm_mask) + 1;
>> > +
>> > + if (pll_data->flags & CLK_DAVINCI_PLL_HAS_PREDIV) {
>> > + /* pre-divider is fixed, take prediv value from pll_data */
>> > + if (pll_data->fixed_prediv)
>> > + prediv = pll_data->fixed_prediv;
>>
>> Since else is multi-line, if needs braces as well.
>>
>> > + else {
>> > + prediv = __raw_readl(pll_data->prediv);
>> > + if (prediv & PLLDIV_EN)
>> > + prediv = (prediv & pll_data->prediv_mask) + 1;
>> > + else
>> > + prediv = 1;
>> > + }
>> > + }
>> > +
>> > + if (pll_data->flags & CLK_DAVINCI_PLL_HAS_POSTDIV) {
>> > + postdiv = __raw_readl(pll_data->postdiv);
>> > + if (postdiv & PLLDIV_EN)
>> > + postdiv = (postdiv & pll_data->postdiv_mask) + 1;
>> > + else
>> > + postdiv = 1;
>> > + }
>> > +
>> > + rate /= prediv;
>> > + rate *= mult;
>> > + rate /= postdiv;
>> > +
>> > + pr_debug("PLL%d: input = %lu MHz [ ",
>> > + pll_data->num, parent_rate / 1000000);
>> > + if (prediv > 1)
>> > + pr_debug("/ %d ", prediv);
>> > + if (mult > 1)
>> > + pr_debug("* %d ", mult);
>> > + if (postdiv > 1)
>> > + pr_debug("/ %d ", postdiv);
>> > + pr_debug("] --> %lu MHz output.\n", rate / 1000000);
>> > + return rate;
>>
>> Have a blank like before the return, its easier to read that way.
>>
>> > +}
>> > +
>> > +static const struct clk_ops clk_pll_ops = {
>> > + .recalc_rate = clk_pllclk_recalc,
>> > +};
>> > +
>> > +struct clk *clk_register_davinci_pll(struct device *dev, const char *name,
>> > + const char *parent_name,
>> > + struct clk_davinci_pll_data *pll_data) {
>> > + struct clk_init_data init;
>> > + struct clk_davinci_pll *pll;
>> > + struct clk *clk;
>> > +
>> > + if (!pll_data)
>> > + return ERR_PTR(-ENODEV);
>> > +
>> > + pll = kzalloc(sizeof(*pll), GFP_KERNEL);
>> > + if (!pll)
>> > + return ERR_PTR(-ENOMEM);
>> > + init.name = name;
>> > + init.ops = &clk_pll_ops;
>> > + init.flags = pll_data->flags;
>> > + init.parent_names = (parent_name ? &parent_name : NULL);
>> > + init.num_parents = (parent_name ? 1 : 0);
>> > +
>> > + pll->pll_data = pll_data;
>> > + pll->hw.init = &init;
>> > +
>> > + clk = clk_register(NULL, &pll->hw);
>> > + if (IS_ERR(clk))
>> > + kfree(pll);
>> > +
>> > + return clk;
>> > +}
>>
>> I guess there is an an "unregister" required as well which will free the pll memory
>> allocated above and unregister the clock? Not sure if you would ever unregister a PLL,
>> but providing this will probably help symmetry.
Sekhar,
clk_unregister() itself is a null statement in clk.c. Besides none of the clk drivers presently have implemented the unregister(). So I believe this is unnecessary.
>>
>> Thanks,
>> Sekhar
All of your other comments will be addressed in v3 patch.
BTW, please review the v2 patch for the rest of the series. For the one you have already reviewed, it should be fine.
Murali
^ permalink raw reply
* [PATCH] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries
From: Hiremath, Vaibhav @ 2012-10-10 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349879449-22657-1-git-send-email-mporter@ti.com>
On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote:
> 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage
> exposes a bug in the AM33XX clock data for mcasp. After moving to
> clk_get() usage, the _init() of all registered hwmods fails on mcasp0
> due to incorrect clock data causing clk_get() to fail. This causes all
> successive hwmods to fail to _init() leaving them in a bad state.
>
> This patch updates the mcasp clock entries so clk_get() will succeed.
> It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx
> boot.
>
Matt,
I have already submitted patch for this and it is accepted and merged in
Tony's pull request.
https://patchwork.kernel.org/patch/1499271/
Thanks,
Vaibhav
> Signed-off-by: Matt Porter <mporter@ti.com>
> ---
> arch/arm/mach-omap2/clock33xx_data.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock33xx_data.c b/arch/arm/mach-omap2/clock33xx_data.c
> index b87b88c..0a64139 100644
> --- a/arch/arm/mach-omap2/clock33xx_data.c
> +++ b/arch/arm/mach-omap2/clock33xx_data.c
> @@ -1033,8 +1033,8 @@ static struct omap_clk am33xx_clks[] = {
> CLK("481d0000.d_can", NULL, &dcan1_fck, CK_AM33XX),
> CLK(NULL, "debugss_ick", &debugss_ick, CK_AM33XX),
> CLK(NULL, "pruss_ocp_gclk", &pruss_ocp_gclk, CK_AM33XX),
> - CLK("davinci-mcasp.0", NULL, &mcasp0_fck, CK_AM33XX),
> - CLK("davinci-mcasp.1", NULL, &mcasp1_fck, CK_AM33XX),
> + CLK(NULL, "mcasp0_fck", &mcasp0_fck, CK_AM33XX),
> + CLK(NULL, "mcasp1_fck", &mcasp1_fck, CK_AM33XX),
> CLK("NULL", "mmc2_fck", &mmc2_fck, CK_AM33XX),
> CLK(NULL, "mmu_fck", &mmu_fck, CK_AM33XX),
> CLK(NULL, "smartreflex0_fck", &smartreflex0_fck, CK_AM33XX),
> --
> 1.7.9.5
>
>
^ permalink raw reply
* [PATCH] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries
From: Matt Porter @ 2012-10-10 14:30 UTC (permalink / raw)
To: linux-arm-kernel
6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage
exposes a bug in the AM33XX clock data for mcasp. After moving to
clk_get() usage, the _init() of all registered hwmods fails on mcasp0
due to incorrect clock data causing clk_get() to fail. This causes all
successive hwmods to fail to _init() leaving them in a bad state.
This patch updates the mcasp clock entries so clk_get() will succeed.
It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx
boot.
Signed-off-by: Matt Porter <mporter@ti.com>
---
arch/arm/mach-omap2/clock33xx_data.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock33xx_data.c b/arch/arm/mach-omap2/clock33xx_data.c
index b87b88c..0a64139 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -1033,8 +1033,8 @@ static struct omap_clk am33xx_clks[] = {
CLK("481d0000.d_can", NULL, &dcan1_fck, CK_AM33XX),
CLK(NULL, "debugss_ick", &debugss_ick, CK_AM33XX),
CLK(NULL, "pruss_ocp_gclk", &pruss_ocp_gclk, CK_AM33XX),
- CLK("davinci-mcasp.0", NULL, &mcasp0_fck, CK_AM33XX),
- CLK("davinci-mcasp.1", NULL, &mcasp1_fck, CK_AM33XX),
+ CLK(NULL, "mcasp0_fck", &mcasp0_fck, CK_AM33XX),
+ CLK(NULL, "mcasp1_fck", &mcasp1_fck, CK_AM33XX),
CLK("NULL", "mmc2_fck", &mmc2_fck, CK_AM33XX),
CLK(NULL, "mmu_fck", &mmu_fck, CK_AM33XX),
CLK(NULL, "smartreflex0_fck", &smartreflex0_fck, CK_AM33XX),
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 1/8] dt: add helper inline for retrieving timeout-sec property
From: Rob Herring @ 2012-10-10 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349784251-28261-2-git-send-email-fabio.porcedda@gmail.com>
On 10/09/2012 07:04 AM, Fabio Porcedda wrote:
> The first user of this function is the watchdog framework.
Who is the 2nd user because I don't see any others. I don't see this
being a widely used property.
Rob
>
> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Rob Herring <rob.herring@calxeda.com>
> ---
> include/linux/of.h | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 72843b7..5870818 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -470,4 +470,15 @@ static inline int of_property_read_u32(const struct device_node *np,
> return of_property_read_u32_array(np, propname, out_value, 1);
> }
>
> +/**
> + * of_get_timeout_sec() - Helper to read the timeout_sec property
> + * @np: device node from which the property value is to be read.
> + * @timeout: adress of the output value
> + */
> +static inline int of_get_timeout_sec(const struct device_node *np,
> + u32 *timeout)
> +{
> + return of_property_read_u32(np, "timeout-sec", timeout);
> +}
> +
> #endif /* _LINUX_OF_H */
>
^ permalink raw reply
* [PATCH] i2c: at91: add a sanity check on i2c message length
From: ludovic.desroches at atmel.com @ 2012-10-10 14:25 UTC (permalink / raw)
To: linux-arm-kernel
From: Ludovic Desroches <ludovic.desroches@atmel.com>
If the i2c message length is zero, i2c-at91 will directly return an error
instead of trying to send a zero-length message.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
---
fix for 3.7
drivers/i2c/busses/i2c-at91.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index aa59a25..eaddc77 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -263,6 +263,9 @@ static int at91_twi_xfer(struct i2c_adapter *adap, struct i2c_msg *msg, int num)
unsigned int_addr_flag = 0;
struct i2c_msg *m_start = msg;
+ if (!msg->len)
+ return -EINVAL;
+
dev_dbg(&adap->dev, "at91_xfer: processing %d messages:\n", num);
/*
--
1.7.11.3
^ permalink raw reply related
* [PATCH] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Hiremath, Vaibhav @ 2012-10-10 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121010140027.GB13724@beef>
On Wed, Oct 10, 2012 at 19:30:27, Porter, Matt wrote:
> On Tue, Oct 09, 2012 at 02:27:20PM +0530, Vaibhav Hiremath wrote:
> > With recent changes in omap gpmc driver code, in case of DT
> > boot mode, where bootloader does not configure gpmc cs space
> > will result into kernel BUG() inside gpmc_mem_init() function,
> > as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
> > gpmc_config7[0].baseaddress is set to '0' on reset.
> >
> > This use-case is applicable for any board/EVM which doesn't have
> > any peripheral connected to gpmc cs0, for example BeagleXM and
> > BeagleBone, so DT boot mode fails.
> >
> > This patch adds of_have_populated_dt() check before creating
> > device, so that for DT boot mode, gpmc probe will not be called
> > which is expected behavior, as gpmc is not supported yet from DT.
> >
> > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > Cc: Afzal Mohammed <afzal@ti.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc Paul Walmsley <paul@pwsan.com>
> > ---
> > This should go in for rc1, as this breaks AM33xx boot.
>
> Fixes BeagleBone on mainline.
>
> Tested-by: Matt Porter <mporter@ti.com>
>
Thanks Matt and Afzal,
Tony can this be picked up for rc1?? I know you have already sent pull
request for rc1, but by any chance you are planning to send another request?
Thanks,
Vaibhav
> -Matt
>
^ permalink raw reply
* [PATCH 02/13] clk: davinci - add PSC clock driver
From: Karicheri, Muralidharan @ 2012-10-10 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50756DFD.4070203@ti.com>
>> -----Original Message-----
>> From: Nori, Sekhar
>> Sent: Wednesday, October 10, 2012 8:46 AM
>> To: Nori, Sekhar
>> Cc: Karicheri, Muralidharan; Hilman, Kevin; davinci-linux-open-
>> source at linux.davincidsp.com; mturquette at linaro.org; linux-c6x-dev at linux-c6x.org;
>> arnd at arndb.de; linus.walleij at linaro.org; linux-kernel at vger.kernel.org;
>> rob.herring at calxeda.com; linux-keystone at list.ti.com - Linux developers for Keystone
>> family of devices (May contain non-TIers); viresh.linux at gmail.com;
>> linux at arm.linux.org.uk; akpm at linux-foundation.org; shawn.guo at linaro.org; linux-arm-
>> kernel at lists.infradead.org
>> Subject: Re: [PATCH 02/13] clk: davinci - add PSC clock driver
>>
>> On 10/10/2012 6:05 PM, Sekhar Nori wrote:
>>
>> >> +struct clk *clk_register_davinci_psc(struct device *dev, const char *name,
>> >> + const char *parent_name,
>> >> + struct clk_davinci_psc_data *psc_data,
>> >> + spinlock_t *lock)
>> >
>> > Why do you need the lock to be provided from outside of this file? You
>> > can initialize a lock for serializing writes to PSC registers within
>> > this file, no?
>>
>> Looking again, it seems like the common clock framework defines an "enable_lock" in
>> drivers/clk/clk.c to serialize the clock enable/disable calls. Unless I am missing something,
>> this lock seems unnecessary.
>>
I think you are right. For enable() api, enable_lock is sufficient and I will remove this.
>> Thanks,
>> Sekhar
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox