* [PATCH 13/11] arm64: Add support for 48-bit VA space with 64KB page configuration
From: Jungseok Lee @ 2014-07-22 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ADA477FA-165D-4679-A38F-C82C901BEE4D@gmail.com>
On Jul 22, 2014, at 00:09 +900 Catalin Marinas wrote:
> This patch allows support for 3 levels of page tables with 64KB page
> configuration allowing 48-bit VA space. The pgd is no longer a full
> PAGE_SIZE (PTRS_PER_PGD is 64) and (swapper|idmap)_pg_dir are not fully
> populated (pgd_alloc falls back to kzalloc).
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
One more step :)
Are you going to post the next version of this series including [12/11]
and [13/11] or finalize the series?
In addition, could you put my gmail address in CC in coming patch or
the next version? It help me follow up the series easily.
- Jungseok Lee
^ permalink raw reply
* [PATCH v2 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
From: Felipe Balbi @ 2014-07-22 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722091800.GB8233@griffinp-ThinkPad-X1-Carbon-2nd>
Hi,
On Tue, Jul 22, 2014 at 10:18:00AM +0100, Peter Griffin wrote:
> > > +static inline u32 st_dwc3_readl(void __iomem *base, u32 offset)
> > > +{
> > > + return readl_relaxed(base + offset);
> > > +}
> > > +
> > > +static inline void st_dwc3_writel(void __iomem *base, u32 offset, u32 value)
> > > +{
> > > + writel_relaxed(value, base + offset);
> > > +}
> >
> > Why are these being abstracted?
> >
> > Just use {read,write}l_relaxed() directly.
>
> Ok, unabstracted in v3
no, no... all other glues add their own local helpers for register
access. This is good for tracing, it's very easy to add a tracepoint to
this sort of function and get very low overhead tracing of every
register access.
> > > + if (dwc3_data->drd_device_conf)
> > > + val |= USB_SET_PORT_DEVICE;
> > > + else
> > > + val &= USB_HOST_DEFAULT_MASK;
> > > +
> > > + return regmap_write(dwc3_data->regmap, dwc3_data->syscfg_reg_off, val);
> > > +}
> > > +
> > > +/**
> > > + * st_dwc3_init: init the controller via glue logic
> > > + * @dwc3_data: driver private structure
> > > + */
> > > +static void st_dwc3_init(struct st_dwc3 *dwc3_data)
> > > +{
> > > + u32 reg = st_dwc3_readl(dwc3_data->glue_base, USB2_CLKRST_CTRL);
> > > +
> > > + reg |= aux_clk_en(1) | ext_cfg_reset_n(1) | xhci_revision(1);
> > > + reg &= ~sw_pipew_reset_n(1);
> >
> > 1? Better to add defines for these magic numbers. What is 1 anyway?
>
> They are just bit setting macros, I've converted them over to use BIT macro now,
> so it no longer takes a parameter.
the macros are better, but make them upper case as everybody else.
> > > + st_dwc3_writel(dwc3_data->glue_base, USB2_CLKRST_CTRL, reg);
> > > +
> > > + reg = st_dwc3_readl(dwc3_data->glue_base, USB2_VBUS_MNGMNT_SEL1);
> > > + reg |= SEL_OVERRIDE_VBUSVALID(1) | SEL_OVERRIDE_POWERPRESENT(1) |
> > > + SEL_OVERRIDE_BVALID(1);
> > > + st_dwc3_writel(dwc3_data->glue_base, USB2_VBUS_MNGMNT_SEL1, reg);
> > > + udelay(100);
> >
> > Why 100?
>
> I've asked ST how this value was derirved and why. It came from validation.
> The docs don't mention that it is necessary, and removing it
> seems to have no ill effects. So I've removed this udelay in v3.
make sure to test with many, many iterations just to make sure.
> > > + reg = st_dwc3_readl(dwc3_data->glue_base, USB2_CLKRST_CTRL);
> > > + reg |= sw_pipew_reset_n(1);
> > > + st_dwc3_writel(dwc3_data->glue_base, USB2_CLKRST_CTRL, reg);
> > > +}
> > > +
> > > +static void st_dwc3_dt_get_pdata(struct platform_device *pdev,
> > > + struct st_dwc3 *dwc3_data)
> > > +{
> > > + struct device_node *np = pdev->dev.of_node;
> > > +
> > > + dwc3_data->drd_device_conf =
> > > + of_property_read_bool(np, "st,dwc3-drd-device");
> >
> > This requires a DT Ack.
>
> Ok. Do the DT folks have any comment on this?
look at the child's dr-mode property instead of adding your own.
> > > + dwc3_data->glue_base = devm_request_and_ioremap(dev, res);
use devm_ioremap_resource()
> > > + regmap = syscon_regmap_lookup_by_phandle(node, "st,syscfg");
> > > + if (IS_ERR(regmap))
> > > + return PTR_ERR(regmap);
> > > +
> > > + dwc3 = platform_device_alloc("st-dwc3", PLATFORM_DEVID_AUTO);
> > > + if (!dwc3) {
> > > + dev_err(&pdev->dev, "couldn't allocate dwc3 device\n");
> > > + return -ENOMEM;
> > > + }
> >
> > I'm confused. What is this doing? Isn't this the DWC3 driver, which
> > already had a platform device structure associated to it? Perhaps a
> > small ASCII diagram describing the layers might be useful.
>
> Your right, this was wrong. It was some legacy code which is
> unnecessary and I've removed this in v3.
if you're going for DT, why don't you create the parent and the child
from DT as omap/exynos/qcom are doing ?
> > > + dma_set_coherent_mask(&dwc3->dev, dev->coherent_dma_mask);
> > > +
> > > + dwc3->dev.parent = &pdev->dev;
> > > + dwc3->dev.dma_mask = pdev->dev.dma_mask;
> > > + dwc3->dev.dma_parms = pdev->dev.dma_parms;
stick to DT device creation. Look into dwc3-omap.c
> > > +static int st_dwc3_remove(struct platform_device *pdev)
> > > +{
> > > + struct st_dwc3 *dwc3_data = platform_get_drvdata(pdev);
> > > +
> > > + platform_device_unregister(dwc3_data->dwc3);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +#ifdef CONFIG_PM_SLEEP
> > > +static int st_dwc3_suspend(struct device *dev)
> > > +{
> > > + struct st_dwc3 *dwc3_data = dev_get_drvdata(dev);
> > > +
> > > + reset_control_assert(dwc3_data->rstc_pwrdn);
> > > +
> > > + pinctrl_pm_select_sleep_state(dev);
pinctrl will select sleep and default states automatically for you.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140722/9f43e8df/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: imx6: fix SMP compilation again
From: Shawn Guo @ 2014-07-22 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12850450.mxMbPOMjsW@wuerfel>
On Tue, Jul 22, 2014 at 04:37:55PM +0200, Arnd Bergmann wrote:
> On Tuesday 22 July 2014 21:48:16 Shawn Guo wrote:
> > I tried both mainline and -next tree. I really need some help to
> > reproduce the error first.
>
> My branch is at git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git
> in the randconfig-next branch. Sorry for the inconvenience.
Okay, I can see the error on your branch with the fixing patch reverted.
>
> > > arch/arm/mach-imx/built-in.o: In function `v7_secondary_startup':
> > > :(.text+0x5124): undefined reference to `v7_invalidate_l1'
> > >
> > > This puts the code inside of an "ifdef CONFIG_SMP" to hopefully
> >
> > The code says "ifdef CONFIG_SOC_IMX6"?
>
> It seems I'm having a bad day. I'll fix it up.
With that fixed up,
Acked-by: Shawn Guo <shawn.guo@freescale.com>
Or let me know if you expect me to handle the patch.
Shawn
^ permalink raw reply
* [PATCH 5/5] ARM: multi_v7_defconfig: Enable ST's Power Reset driver
From: Lee Jones @ 2014-07-22 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406040752-25229-1-git-send-email-lee.jones@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 5348364..1878e8d 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -221,6 +221,7 @@ CONFIG_CHARGER_TPS65090=y
CONFIG_POWER_RESET_AS3722=y
CONFIG_POWER_RESET_GPIO=y
CONFIG_POWER_RESET_SUN6I=y
+CONFIG_POWER_RESET_ST=y
CONFIG_SENSORS_LM90=y
CONFIG_THERMAL=y
CONFIG_ARMADA_THERMAL=y
--
1.8.3.2
^ permalink raw reply related
* [PATCH 4/5] ARM: sti: Add Restart support for the STiH416 (Orly2) board
From: Lee Jones @ 2014-07-22 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406040752-25229-1-git-send-email-lee.jones@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/stih416.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 84758d7..95b15b0 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -28,6 +28,12 @@
ranges;
compatible = "simple-bus";
+ restart {
+ compatible = "st,stih416-restart";
+ st,syscfg = <&syscfg_sbc>;
+ status = "okay";
+ };
+
powerdown: powerdown-controller {
#reset-cells = <1>;
compatible = "st,stih416-powerdown";
--
1.8.3.2
^ permalink raw reply related
* [PATCH 3/5] ARM: sti: Add Restart support for the STiH417 (Cannes) board
From: Lee Jones @ 2014-07-22 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406040752-25229-1-git-send-email-lee.jones@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/stih407.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/stih407.dtsi b/arch/arm/boot/dts/stih407.dtsi
index 4f9024f..a370e73 100644
--- a/arch/arm/boot/dts/stih407.dtsi
+++ b/arch/arm/boot/dts/stih407.dtsi
@@ -63,6 +63,12 @@
ranges;
compatible = "simple-bus";
+ restart {
+ compatible = "st,stih407-restart";
+ st,syscfg = <&syscfg_sbc_reg>;
+ status = "okay";
+ };
+
syscfg_sbc: sbc-syscfg at 9620000 {
compatible = "st,stih407-sbc-syscfg", "syscon";
reg = <0x9620000 0x1000>;
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/5] power: reset: st: Provide DT bindings for ST's Power Reset driver
From: Lee Jones @ 2014-07-22 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406040752-25229-1-git-send-email-lee.jones@linaro.org>
Signed-off-by: Christophe Kerello <christophe.kerello@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
Documentation/devicetree/bindings/power/reset/st-reset.txt | 11 +++++++++++
1 file changed, 11 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/reset/st-reset.txt
diff --git a/Documentation/devicetree/bindings/power/reset/st-reset.txt b/Documentation/devicetree/bindings/power/reset/st-reset.txt
new file mode 100644
index 0000000..809af54
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/st-reset.txt
@@ -0,0 +1,11 @@
+*Device-Tree bindings for ST SW reset functionality
+
+Required properties:
+- compatible: should be "st,<chip>-restart".
+- st,syscfg: should be a phandle of the syscfg node.
+
+Example node:
+ restart {
+ compatible = "st,stih416-restart";
+ st,syscfg = <&syscfg_sbc>;
+ };
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/5] power: reset: Add restart functionality for STiH41x platforms
From: Lee Jones @ 2014-07-22 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406040752-25229-1-git-send-email-lee.jones@linaro.org>
This driver adds the restart functionality for STiH415 and STiH416
platforms from STMicroelectronics. This driver registers an
arm_pm_restart function to reset the platform.
Signed-off-by: Christophe Kerello <christophe.kerello@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/power/reset/Kconfig | 6 ++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/st-poweroff.c | 151 ++++++++++++++++++++++++++++++++++++++
3 files changed, 158 insertions(+)
create mode 100644 drivers/power/reset/st-poweroff.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 003e4d4..445b330 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -58,6 +58,12 @@ config POWER_RESET_SUN6I
help
Reboot support for the Allwinner A31 SoCs.
+config POWER_RESET_ST
+ bool "ST restart power-off driver"
+ depends on POWER_RESET && ARCH_STI
+ help
+ Power off and reset support for STMicroelectronics boards.
+
config POWER_RESET_VEXPRESS
bool "ARM Versatile Express power-off and reset driver"
depends on ARM || ARM64
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index dde2e8b..aaae990 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
obj-$(CONFIG_POWER_RESET_SUN6I) += sun6i-reboot.o
+obj-$(CONFIG_POWER_RESET_ST) += st-poweroff.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
obj-$(CONFIG_POWER_RESET_KEYSTONE) += keystone-reset.o
diff --git a/drivers/power/reset/st-poweroff.c b/drivers/power/reset/st-poweroff.c
new file mode 100644
index 0000000..a0acf25
--- /dev/null
+++ b/drivers/power/reset/st-poweroff.c
@@ -0,0 +1,151 @@
+/*
+ * Copyright (C) 2014 STMicroelectronics
+ *
+ * Power off Restart driver, used in STMicroelectronics devices.
+ *
+ * Author: Christophe Kerello <christophe.kerello@st.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/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+
+#include <asm/system_misc.h>
+
+struct reset_syscfg {
+ struct regmap *regmap;
+ /* syscfg used for reset */
+ unsigned int offset_rst;
+ unsigned int mask_rst;
+ /* syscfg used for unmask the reset */
+ unsigned int offset_rst_msk;
+ unsigned int mask_rst_msk;
+};
+
+/* STiH415 */
+#define STIH415_SYSCFG_11 0x2c
+#define STIH415_SYSCFG_15 0x3c
+
+static struct reset_syscfg stih415_reset = {
+ .offset_rst = STIH415_SYSCFG_11,
+ .mask_rst = BIT(0),
+ .offset_rst_msk = STIH415_SYSCFG_15,
+ .mask_rst_msk = BIT(0)
+};
+
+/* STiH416 */
+#define STIH416_SYSCFG_500 0x7d0
+#define STIH416_SYSCFG_504 0x7e0
+
+static struct reset_syscfg stih416_reset = {
+ .offset_rst = STIH416_SYSCFG_500,
+ .mask_rst = BIT(0),
+ .offset_rst_msk = STIH416_SYSCFG_504,
+ .mask_rst_msk = BIT(0)
+};
+
+/* STiH407 */
+#define STIH407_SYSCFG_4000 0x0
+#define STIH407_SYSCFG_4008 0x20
+
+static struct reset_syscfg stih407_reset = {
+ .offset_rst = STIH407_SYSCFG_4000,
+ .mask_rst = BIT(0),
+ .offset_rst_msk = STIH407_SYSCFG_4008,
+ .mask_rst_msk = BIT(0)
+};
+
+/* STiD127 */
+#define STID127_SYSCFG_700 0x0
+#define STID127_SYSCFG_773 0x124
+
+static struct reset_syscfg stid127_reset = {
+ .offset_rst = STID127_SYSCFG_773,
+ .mask_rst = BIT(0),
+ .offset_rst_msk = STID127_SYSCFG_700,
+ .mask_rst_msk = BIT(8)
+};
+
+static struct reset_syscfg *st_restart_syscfg;
+
+static void st_restart(enum reboot_mode reboot_mode, const char *cmd)
+{
+ /* reset syscfg updated */
+ regmap_update_bits(st_restart_syscfg->regmap,
+ st_restart_syscfg->offset_rst,
+ st_restart_syscfg->mask_rst,
+ 0);
+
+ /* unmask the reset */
+ regmap_update_bits(st_restart_syscfg->regmap,
+ st_restart_syscfg->offset_rst_msk,
+ st_restart_syscfg->mask_rst_msk,
+ 0);
+}
+
+static struct of_device_id st_reset_of_match[] = {
+ {
+ .compatible = "st,stih415-restart",
+ .data = (void *)&stih415_reset,
+ }, {
+ .compatible = "st,stih416-restart",
+ .data = (void *)&stih416_reset,
+ }, {
+ .compatible = "st,stih407-restart",
+ .data = (void *)&stih407_reset,
+ }, {
+ .compatible = "st,stid127-restart",
+ .data = (void *)&stid127_reset,
+ },
+ {}
+};
+
+static int st_reset_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ const struct of_device_id *match;
+ struct device *dev = &pdev->dev;
+
+ match = of_match_device(st_reset_of_match, dev);
+ if (!match)
+ return -ENODEV;
+
+ st_restart_syscfg = (struct reset_syscfg *)match->data;
+
+ st_restart_syscfg->regmap =
+ syscon_regmap_lookup_by_phandle(np, "st,syscfg");
+ if (IS_ERR(st_restart_syscfg->regmap)) {
+ dev_err(dev, "No syscfg phandle specified\n");
+ return PTR_ERR(st_restart_syscfg->regmap);
+ }
+
+ arm_pm_restart = st_restart;
+
+ return 0;
+}
+
+static struct platform_driver st_reset_driver = {
+ .probe = st_reset_probe,
+ .driver = {
+ .name = "st_reset",
+ .of_match_table = st_reset_of_match,
+ },
+};
+
+static int __init st_reset_init(void)
+{
+ return platform_driver_register(&st_reset_driver);
+}
+
+device_initcall(st_reset_init);
+
+MODULE_AUTHOR("Christophe Kerello <christophe.kerello@st.com>");
+MODULE_DESCRIPTION("STMicroelectronics Power off Restart driver");
+MODULE_LICENSE("GPL v2");
--
1.8.3.2
^ permalink raw reply related
* [PATCH 0/5] power: reset: Add support for ST's boards
From: Lee Jones @ 2014-07-22 14:52 UTC (permalink / raw)
To: linux-arm-kernel
This set provides device reset support for Orly2 and Cannes.
Lee Jones (5):
power: reset: Add restart functionality for STiH41x platforms
power: reset: st: Provide DT bindings for ST's Power Reset driver
ARM: sti: Add Restart support for the STiH417 (Cannes) board
ARM: sti: Add Restart support for the STiH416 (Orly2) board
ARM: multi_v7_defconfig: Enable ST's Power Reset driver
.../devicetree/bindings/power/reset/st-reset.txt | 11 ++
arch/arm/boot/dts/stih407.dtsi | 6 +
arch/arm/boot/dts/stih416.dtsi | 6 +
arch/arm/configs/multi_v7_defconfig | 1 +
drivers/power/reset/Kconfig | 6 +
drivers/power/reset/Makefile | 1 +
drivers/power/reset/st-poweroff.c | 151 +++++++++++++++++++++
7 files changed, 182 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/reset/st-reset.txt
create mode 100644 drivers/power/reset/st-poweroff.c
--
1.8.3.2
^ permalink raw reply
* [PATCH 8/9] usb: phy: am335x: call usb_gen_phy_init()/usb_gen_phy_shutdown() in am335x_init()/am335x_shutdown()
From: Felipe Balbi @ 2014-07-22 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722100613.779a3e11@ipc1.ka-ro>
On Tue, Jul 22, 2014 at 10:06:13AM +0200, Lothar Wa?mann wrote:
> Hi,
>
> Felipe Balbi wrote:
> > Hi,,
> >
> > On Mon, Jul 21, 2014 at 10:03:07AM +0200, Lothar Wa?mann wrote:
> > > Hi,
> > >
> > > > On Fri, Jul 18, 2014 at 11:31:29AM +0200, Lothar Wa?mann wrote:
> > > > > This patch makes it possible to use the musb driver with HW that
> > > > > requires external regulators or clocks.
> > > >
> > > > can you provide an example of such HW ? Are you not using the internal
> > > > PHYs ?
> > > >
> > > The Ka-Ro electronics TX48 module uses the mmc0_clk pin as VBUSEN
> > > rathern than usb0_drvvbus. This patch makes it possible to use an
> > > external regulator to handle the VBUS switch through the 'vcc-supply'
> > > property of the underlying generic_phy device.
> >
> > OK, I get it now. But why would not use usb0_drvvbus ? You could still
> > route usb0_drvvbus to the regulator enable pin and the regulator would
> > be enabled for you once correct values are written to the IP's mailbox.
> >
> > I suppose this has something to do with layout constraints ?
> >
> Yes. The usb0_drvvbus is used for a different purpose.
alright, thanks for the info. I'll revisit this in a few days, quite
busy right now and my tree is closed for v3.17 anyway.
cheers
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140722/191cc982/attachment-0001.sig>
^ permalink raw reply
* [PATCH 9/9] usb: musb: musb_am335x: reinstate module loading/unloading support
From: Felipe Balbi @ 2014-07-22 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722094930.0c52bb01@ipc1.ka-ro>
On Tue, Jul 22, 2014 at 09:49:30AM +0200, Lothar Wa?mann wrote:
> Hi,
>
> Felipe Balbi wrote:
> > On Fri, Jul 18, 2014 at 11:31:30AM +0200, Lothar Wa?mann wrote:
> > > There is no need to throw the baby out with the bath due to a bad
> > > failure analysis. The commit:
> > > 7adb5c876e9c usb: musb: Fix panic upon musb_am335x module removal
> > > came to a wrong conclusion about the cause of the crash it was
> > > "fixing". The real culprit was the phy-am335x module that was removed
> > > from underneath its users that were still referencing data from it.
> > > After having fixed this in a previous patch, module unloading can be
> > > reinstated.
> > >
> > > Another bug with module loading/unloading was the fact, that after
> > > removing the devices instantiated from DT their 'OF_POPULATED' flag
> > > was still set, so that re-loading the module after an unload had no
> > > effect. This is also fixed in this patch.
> >
> > now this is a good commit log. I still can't see the need for the other
> > patch adding try_module_get(), though. Another thing, this needs to be
> > reviewed by DT folks too.
> >
> Without holding a reference to the phy module, the module may be
> unloaded when its resources are still in use which may lead to the
> crash observed in the above stated commit.
>
> > > Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
> > > ---
> > > drivers/usb/musb/musb_am335x.c | 23 ++++++++++++++++++-----
> > > 1 file changed, 18 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/usb/musb/musb_am335x.c b/drivers/usb/musb/musb_am335x.c
> > > index 164c868..152a6f5 100644
> > > --- a/drivers/usb/musb/musb_am335x.c
> > > +++ b/drivers/usb/musb/musb_am335x.c
> > > @@ -19,6 +19,22 @@ err:
> > > return ret;
> > > }
> > >
> > > +static int of_remove_populated_child(struct device *dev, void *d)
> > > +{
> > > + struct platform_device *pdev = to_platform_device(dev);
> > > +
> > > + of_device_unregister(pdev);
> > > + of_node_clear_flag(pdev->dev.of_node, OF_POPULATED);
> >
> > I don't think this should be called by drivers; rather by the bus.
> >
> Possibly the right thing to do would be to use of_platform_depopulate()
> in the remove function to pair up with op_platform_populate() in the
> probe function, but doing this results in a crash in
> platform_device_del() (called from platform_device_unregister()) when
> release_resource() is being called on resources that were never
> properly registered with the device:
> Unable to handle kernel NULL pointer dereference at virtual address 00000018
> pgd = 8dd64000
> [00000018] *pgd=8ddc2831, *pte=00000000, *ppte=00000000
> Internal error: Oops: 17 [#1] PREEMPT ARM
> Modules linked in: musb_am335x(-) [last unloaded: snd]
> CPU: 0 PID: 1435 Comm: modprobe Not tainted 3.16.0-rc5-next-20140717-dbg+ #13
> task: 8da00880 ti: 8dda0000 task.ti: 8dda0000
> PC is at release_resource+0x14/0x7c
> LR is at release_resource+0x10/0x7c
> pc : [<8003165c>] lr : [<80031658>] psr: a0000013
> sp : 8dda1ec0 ip : 8dda0000 fp : 00000000
> r10: 00000000 r9 : 8dda0000 r8 : 8deb7c10
> r7 : 8deb7c00 r6 : 00000200 r5 : 00000001 r4 : 8deed380
> r3 : 00000000 r2 : 00000000 r1 : 00000011 r0 : 806772a0
> Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 10c5387d Table: 8dd64019 DAC: 00000015
> Process modprobe (pid: 1435, stack limit = 0x8dda0238)
> Stack: (0x8dda1ec0 to 0x8dda2000)
> 1ec0: 8da00880 8deed380 00000001 802f850c 00000000 8deed380 44e10620 44e1062f
> 1ee0: 8deb7c00 00000000 80398c5c 00000081 8000e904 802f8848 8deb7c10 80398d0c
> 1f00: 00000000 802f3470 8d8d7200 8ddc84b0 8d92e810 7f0f9014 8d92e844 7f0f7010
> 1f20: 8d92e810 802f8110 802f80f8 802f68f8 7f0f9014 8d92e810 7f0f9014 802f7238
> 1f40: 7f0f9014 00000000 20000013 802f6764 7f0f9058 8007ec94 00000000 6273756d
> 1f60: 336d615f 00783533 8da00880 8000e764 00000001 80053ae4 00000058 76f41000
> 1f80: 7eb299e8 01290838 00000011 00000081 60000010 0000e854 7eb299e8 01290838
> 1fa0: 00000011 8000e740 7eb299e8 01290838 012908a0 00000080 00000000 00000001
> 1fc0: 7eb299e8 01290838 00000011 00000081 012908a0 00000000 01290844 00000000
> 1fe0: 76eb76f0 7eb2995c 0000a534 76eb76fc 60000010 012908a0 aaaaaaaa aaaaaaaa
> [<8003165c>] (release_resource) from [<802f850c>] (platform_device_del+0xb4/0xf4)
> [<802f850c>] (platform_device_del) from [<802f8848>] (platform_device_unregister+0xc/0x18)
> [<802f8848>] (platform_device_unregister) from [<80398d0c>] (of_platform_device_destroy+0xb0/0xc8)
> [<80398d0c>] (of_platform_device_destroy) from [<802f3470>] (device_for_each_child+0x34/0x74)
> [<802f3470>] (device_for_each_child) from [<7f0f7010>] (am335x_child_remove+0x10/0x24 [musb_am335x])
> [<7f0f7010>] (am335x_child_remove [musb_am335x]) from [<802f8110>] (platform_drv_remove+0x18/0x1c)
> [<802f8110>] (platform_drv_remove) from [<802f68f8>] (__device_release_driver+0x70/0xc4)
> [<802f68f8>] (__device_release_driver) from [<802f7238>] (driver_detach+0xb4/0xb8)
> [<802f7238>] (driver_detach) from [<802f6764>] (bus_remove_driver+0x5c/0xa4)
> [<802f6764>] (bus_remove_driver) from [<8007ec94>] (SyS_delete_module+0x120/0x18c)
> [<8007ec94>] (SyS_delete_module) from [<8000e740>] (ret_fast_syscall+0x0/0x48)
> Code: e1a04000 e59f0068 eb10bac4 e5943010 (e5932018)
> ---[ end trace 24ca43dfc1a677d6 ]---
>
> The cause for this seems to be calling platform_device_unregister() on
> a device that was created with device_add() (rather than
> platform_device_add()).
good, then you found another bug. Let's fix that and use
of_platform_depopulate().
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140722/3f879cc1/attachment.sig>
^ permalink raw reply
* [PATCH 0/6] net: mvpp2: Assorted fixes
From: Ezequiel Garcia @ 2014-07-22 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721.202749.913689946944612851.davem@davemloft.net>
On 21 Jul 08:27 PM, David Miller wrote:
> From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> Date: Mon, 21 Jul 2014 13:48:10 -0300
>
> > This patchset contains a set of fixes for issues found while doing some
> > more intensive tests on the recently accepted mvpp2 ethernet driver.
> >
> > David: if we are still in time, we'd like to get the driver fixes merged
> > for v3.17-rc1.
> >
> > For the devicetree changes, it's already too late for that, since Jason
> > Cooper has already posted the PRs for v3.17. I'll re-post them when
> > v3.17-rc1 is released.
> >
> > As usual, feedback is welcome.
>
> This series does not apply to the 'net' tree at all, please respin
> and resubmit.
This series applies on net-next.
Sorry for not mentioning it,
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] PM / OPP: Remove ARCH_HAS_OPP
From: Mark Brown @ 2014-07-22 14:43 UTC (permalink / raw)
To: linux-arm-kernel
From: Mark Brown <broonie@linaro.org>
Since the OPP layer is a kernel library which has been converted to be
directly selectable by its callers rather than user selectable and
requiring architectures to enable it explicitly the ARCH_HAS_OPP symbol
has become redundant and can be removed. Do so.
Signed-off-by: Mark Brown <broonie@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Nishanth Menon <nm@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Shawn Guo <shawn.guo@freescale.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
---
Raphael, IIRC you said that you'd applied this but it seems not to have
appeared in -next. There's a few more references crept in, I'll try to
get them removed at source.
Documentation/power/opp.txt | 3 ---
arch/arm/mach-exynos/Kconfig | 1 -
arch/arm/mach-highbank/Kconfig | 1 -
arch/arm/mach-imx/Kconfig | 1 -
arch/arm/mach-omap2/Kconfig | 1 -
arch/arm/mach-shmobile/Kconfig | 2 --
arch/arm/mach-vexpress/Kconfig | 1 -
arch/arm/mach-zynq/Kconfig | 1 -
drivers/devfreq/Kconfig | 1 -
kernel/power/Kconfig | 3 ---
10 files changed, 15 deletions(-)
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
index a9adad828cdc..c6279c2be47c 100644
--- a/Documentation/power/opp.txt
+++ b/Documentation/power/opp.txt
@@ -51,9 +51,6 @@ Typical usage of the OPP library is as follows:
SoC framework -> modifies on required cases certain OPPs -> OPP layer
-> queries to search/retrieve information ->
-Architectures that provide a SoC framework for OPP should select ARCH_HAS_OPP
-to make the OPP layer available.
-
OPP layer expects each domain to be represented by a unique device pointer. SoC
framework registers a set of initial OPPs per device with the OPP layer. This
list is expected to be an optimally small number typically around 5 per device.
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 8f9b66c4ac78..f7889f6a1353 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -100,7 +100,6 @@ config SOC_EXYNOS5440
default y
depends on ARCH_EXYNOS5
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
- select ARCH_HAS_OPP
select HAVE_ARM_ARCH_TIMER
select AUTO_ZRELADDR
select MIGHT_HAVE_PCI
diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
index a5960e2ac090..31aa866c3317 100644
--- a/arch/arm/mach-highbank/Kconfig
+++ b/arch/arm/mach-highbank/Kconfig
@@ -2,7 +2,6 @@ config ARCH_HIGHBANK
bool "Calxeda ECX-1000/2000 (Highbank/Midway)" if ARCH_MULTI_V7
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
select ARCH_HAS_HOLES_MEMORYMODEL
- select ARCH_HAS_OPP
select ARCH_SUPPORTS_BIG_ENDIAN
select ARM_AMBA
select ARM_ERRATA_764369 if SMP
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 2bc7b97861b4..9de84a215abd 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -1,6 +1,5 @@
menuconfig ARCH_MXC
bool "Freescale i.MX family" if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
- select ARCH_HAS_OPP
select ARCH_REQUIRE_GPIOLIB
select ARM_CPU_SUSPEND if PM
select CLKSRC_MMIO
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 1c1ed737f7ab..e7189dcc9309 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -15,7 +15,6 @@ config ARCH_OMAP3
bool "TI OMAP3"
depends on ARCH_MULTI_V7
select ARCH_OMAP2PLUS
- select ARCH_HAS_OPP
select ARM_CPU_SUSPEND if PM
select OMAP_INTERCONNECT
select PM_OPP if PM
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 384221d72d22..5814754c1240 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -92,7 +92,6 @@ config ARCH_R8A73A4
select CPU_V7
select SH_CLK_CPG
select RENESAS_IRQC
- select ARCH_HAS_OPP
select SYS_SUPPORTS_SH_CMT
select SYS_SUPPORTS_SH_TMU
@@ -244,7 +243,6 @@ config MACH_KOELSCH
config MACH_KZM9G
bool "KZM-A9-GT board"
depends on ARCH_SH73A0
- select ARCH_HAS_OPP
select ARCH_REQUIRE_GPIOLIB
select REGULATOR_FIXED_VOLTAGE if REGULATOR
select SND_SOC_AK4642 if SND_SIMPLE_CARD
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index d8b9330f896a..1af70329b88d 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -64,7 +64,6 @@ config ARCH_VEXPRESS_DCSCB
config ARCH_VEXPRESS_SPC
bool "Versatile Express Serial Power Controller (SPC)"
- select ARCH_HAS_OPP
select PM_OPP
help
The TC2 (A15x2 A7x3) versatile express core tile integrates a logic
diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig
index 0c164f81e72d..aaa5162c1509 100644
--- a/arch/arm/mach-zynq/Kconfig
+++ b/arch/arm/mach-zynq/Kconfig
@@ -1,6 +1,5 @@
config ARCH_ZYNQ
bool "Xilinx Zynq ARM Cortex A9 Platform" if ARCH_MULTI_V7
- select ARCH_HAS_OPP
select ARCH_SUPPORTS_BIG_ENDIAN
select ARM_AMBA
select ARM_GIC
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 49e74c1fc639..3dced0a9eae3 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -68,7 +68,6 @@ comment "DEVFREQ Drivers"
config ARM_EXYNOS4_BUS_DEVFREQ
bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) && !ARCH_MULTIPLATFORM
- select ARCH_HAS_OPP
select DEVFREQ_GOV_SIMPLE_ONDEMAND
select PM_OPP
help
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 9a83d780facd..e4e4121fa327 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -253,9 +253,6 @@ config APM_EMULATION
anything, try disabling/enabling this option (or disabling/enabling
APM in your BIOS).
-config ARCH_HAS_OPP
- bool
-
config PM_OPP
bool
---help---
--
2.0.1
^ permalink raw reply related
* [RFC] arm: section split in boot/compressed/head.S
From: Leif Lindholm @ 2014-07-22 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8k=1M9Y7mjYVYYqe94YNFAkG-MRw_GipvN7ORxo4CAMA@mail.gmail.com>
On Mon, Jul 21, 2014 at 08:29:54PM +0200, Ard Biesheuvel wrote:
> On 21 July 2014 19:54, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > Reported-by: Roy Franz <roy.franz@linaro.org>
> >
> > The current code in boot/compressed/head.S executes pretty much
> > sequentially from "start", all the way until the end of
> > "dtb_check_done". However, shortly after the "not_angel" symbol, there
> > is a section change, in the form of a ".text" directive.
> >
> > This means any literal pools in .start end up getting inserted into
> > the middle of the instruction stream.
> >
> > Would something like the below (pardon the semantic silliness) be an
> > acceptable fix?
> >
> > diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> > index 3a8b32d..8ee05e9 100644
> > --- a/arch/arm/boot/compressed/head.S
> > +++ b/arch/arm/boot/compressed/head.S
> > @@ -149,6 +149,10 @@ start:
> > mov r0, #0x17 @ angel_SWIreason_EnterSVC
> > ARM( swi 0x123456 ) @ angel_SWI_ARM
> > THUMB( svc 0xab ) @ angel_SWI_THUMB
> > + b angel
>
>
> The idea appears to be that code in .start sections from other
> platform specific object files gets put there, so it gets executed
> extremely early.
> Jumping over it kind of defeats the purpose here.
Ah, I got the impression something magic was going on, but failed to
spot that bit...
> Instead, adding an explicit .ltorg and jumping over /that/ should do
> the trick, I think, but perhaps it's better just to open code the
> literal pool in this case.
The current state seems fragile, so:
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 3a8b32d..8fded53 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -149,6 +149,11 @@ start:
mov r0, #0x17 @ angel_SWIreason_EnterSVC
ARM( swi 0x123456 ) @ angel_SWI_ARM
THUMB( svc 0xab ) @ angel_SWI_THUMB
+ b angel
+
+ .ltorg
+
+angel:
not_angel:
safe_svcmode_maskall r0
msr spsr_cxsf, r9 @ Save the CPU boot mode in
?
/
Leif
^ permalink raw reply related
* [PATCH] ARM: imx6: fix SMP compilation again
From: Arnd Bergmann @ 2014-07-22 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722134815.GZ8537@dragon>
On Tuesday 22 July 2014 21:48:16 Shawn Guo wrote:
> On Tue, Jul 22, 2014 at 12:26:31PM +0200, Arnd Bergmann wrote:
> > Ah, you are right, I got the text wrong here, and I think I now understand
> > why it didn't happen earlier. Updated patch below (same patch, new
> > text).
> >
> > 8<-------------
> > Subject: [PATCH] ARM: imx6: fix SMP compilation again
> >
> > My earlier patch 1fc593feaf8e ("ARM: imx: build i.MX6 functions
> > only when needed") fixed a problem with building an i.MX5 kernel,
> > but now the problem has returned for the case where we allow
> > ARMv6K SMP builds in multiplatform. With CONFIG_CPU_V7 disabled,
> > but i.MX3 and SMP enabled, we get this build error:
>
> Maybe I missed something, but I have problem to get the following three
> conditions meet in a single kernel configuration.
>
> a) CONFIG_CPU_V7 disabled
> b) i.MX3 enabled
> c) SMP enabled
>
> When I get a) and b) in the config, I have no way to get c). And it
> seems that the only way to get a) and c) at the same time is to enable
> MACH_REALVIEW_PB11MP, which is not part of multi-platform support. So
> i.MX3 cannot be enabled in there.
I have a patch series to make ARCH_REALVIEW multiplatform-enabled,
and I guess the condition can only be hit with these patches, or any
other that selects HAS_SMP.
> I tried both mainline and -next tree. I really need some help to
> reproduce the error first.
My branch is at git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git
in the randconfig-next branch. Sorry for the inconvenience.
> > arch/arm/mach-imx/built-in.o: In function `v7_secondary_startup':
> > :(.text+0x5124): undefined reference to `v7_invalidate_l1'
> >
> > This puts the code inside of an "ifdef CONFIG_SMP" to hopefully
>
> The code says "ifdef CONFIG_SOC_IMX6"?
It seems I'm having a bad day. I'll fix it up.
Arnd
^ permalink raw reply
* [PATCH v4 04/11] pwm: add DT bindings documentation for atmel-hlcdc-pwm driver
From: Varka Bhadram @ 2014-07-22 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406034695-15534-5-git-send-email-boris.brezillon@free-electrons.com>
On Tuesday 22 July 2014 06:41 PM, Boris BREZILLON wrote:
> The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12,
> at91sam9x5 family or sama5d3 family) provide a PWM device.
>
> The DT bindings used for this PWM device is following the default 3 cells
> bindings described in Documentation/devicetree/bindings/pwm/pwm.txt.
>
> Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
> ---
> .../devicetree/bindings/pwm/atmel-hlcdc-pwm.txt | 55 ++++++++++++++++++++++
> 1 file changed, 55 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
> new file mode 100644
> index 0000000..86ad3e2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
> @@ -0,0 +1,55 @@
> +Device-Tree bindings for Atmel's HLCDC (High LCD Controller) PWM driver
> +
> +The Atmel HLCDC PWM is subdevice of the HLCDC MFD device.
> +See ../mfd/atmel-hlcdc.txt for more details.
> +
> +Required properties:
> + - compatible: value should be one of the following:
> + "atmel,hlcdc-pwm"
> + - pinctr-names: the pin control state names. Should contain "default".
> + - pinctrl-0: should contain the pinctrl states described by pinctrl
> + default.
> + - #pwm-cells: should be set to 3. This PWM chip use the default 3 cells
> + bindings defined in Documentation/devicetree/bindings/pwm/pwm.txt.
> + The first cell encodes the PWM id (0 is the only acceptable value here,
> + because the chip only provide one PWM).
> + The second cell encodes the PWM period in nanoseconds.
> + The third cell encodes the PWM flags (the only supported flag is
> + PWM_POLARITY_INVERTED)
It will be readable if:
Required properties:
- compatible : value should be one of the following: "atmel,hlcdc-pwm"
- pinctr-names : the pin control state names. Should contain "default".
- pinctrl-0 : should contain the pinctrl states described by pinctrl default.
- #pwm-cells : should be set to 3. This PWM chip use the default 3 cells
bindings defined in Documentation/devicetree/bindings/pwm/pwm.txt.
The first cell encodes the PWM id (0 is the only acceptable value here,
because the chip only provide one PWM).
The second cell encodes the PWM period in nanoseconds.
The third cell encodes the PWM flags (the only supported flag is
PWM_POLARITY_INVERTED)
....
--
Regards,
Varka Bhadram
^ permalink raw reply
* [PATCH v4 02/11] mfd: add documentation for atmel-hlcdc DT bindings
From: Varka Bhadram @ 2014-07-22 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406034695-15534-3-git-send-email-boris.brezillon@free-electrons.com>
On Tuesday 22 July 2014 06:41 PM, Boris BREZILLON wrote:
> The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
> family or sama5d3 family) exposes 2 subdevices:
> - a display controller (controlled by a DRM driver)
> - a PWM chip
>
> This patch adds documentation for atmel-hlcdc DT bindings.
>
> Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
> ---
> .../devicetree/bindings/mfd/atmel-hlcdc.txt | 50 ++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
> new file mode 100644
> index 0000000..e9cc1b2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
> @@ -0,0 +1,50 @@
> +Device-Tree bindings for Atmel's HLCDC (High LCD Controller) MFD driver
> +
> +Required properties:
> + - compatible: value should be one of the following:
> + "atmel,sama5d3-hlcdc"
> + - reg: base address and size of the HLCDC device registers.
> + - clock-names: the name of the 3 clocks requested by the HLCDC device.
> + Should contain "periph_clk", "sys_clk" and "slow_clk".
> + - clocks: should contain the 3 clocks requested by the HLCDC device.
> +
These bindings not clearly readable. It would be readable if
Required properties:
- compatible : value should be one of the following:"atmel,sama5d3-hlcdc"
- reg : base address and size of the HLCDC device registers.
- clock-names : the name of the 3 clocks requested by the HLCDC device.
Should contain "periph_clk", "sys_clk" and "slow_clk".
- clocks : should contain the 3 clocks requested by the HLCDC device.
......
--
Regards,
Varka Bhadram
^ permalink raw reply
* [PATCH] ARM: imx6: fix SMP compilation again
From: Uwe Kleine-König @ 2014-07-22 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722134815.GZ8537@dragon>
On Tue, Jul 22, 2014 at 09:48:16PM +0800, Shawn Guo wrote:
> On Tue, Jul 22, 2014 at 12:26:31PM +0200, Arnd Bergmann wrote:
> > Ah, you are right, I got the text wrong here, and I think I now understand
> > why it didn't happen earlier. Updated patch below (same patch, new
> > text).
> >
> > 8<-------------
> > Subject: [PATCH] ARM: imx6: fix SMP compilation again
> >
> > My earlier patch 1fc593feaf8e ("ARM: imx: build i.MX6 functions
> > only when needed") fixed a problem with building an i.MX5 kernel,
> > but now the problem has returned for the case where we allow
> > ARMv6K SMP builds in multiplatform. With CONFIG_CPU_V7 disabled,
> > but i.MX3 and SMP enabled, we get this build error:
>
> Maybe I missed something, but I have problem to get the following three
> conditions meet in a single kernel configuration.
>
> a) CONFIG_CPU_V7 disabled
> b) i.MX3 enabled
> c) SMP enabled
>
> When I get a) and b) in the config, I have no way to get c). And it
> seems that the only way to get a) and c) at the same time is to enable
> MACH_REALVIEW_PB11MP, which is not part of multi-platform support. So
> i.MX3 cannot be enabled in there.
>
> I tried both mainline and -next tree. I really need some help to
> reproduce the error first.
Without even looking at the patch, I think the key here is this part of
Arnd's commit log:
for the case where we allow ARMv6K SMP builds in multiplatform
...
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2] iio: exynos-adc: add experimental touchscreen support
From: Varka Bhadram @ 2014-07-22 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5068889.1KfVx3ksNo@wuerfel>
On Tuesday 22 July 2014 06:33 PM, Arnd Bergmann wrote:
(...)
>
> +static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y)
> +{
> + struct exynos_adc *info = iio_priv(indio_dev);
> + unsigned long timeout;
> + int ret;
> +
> + mutex_lock(&indio_dev->mlock);
> + info->read_ts = true;
> +
> + reinit_completion(&info->completion);
> +
> + writel(ADC_S3C2410_TSC_PULL_UP_DISABLE | ADC_TSC_AUTOPST,
> + ADC_V1_TSC(info->regs));
> +
> + /* Select the ts channel to be used and Trigger conversion */
> + info->data->start_conv(info, ADC_S3C2410_MUX_TS);
> +
> + timeout = wait_for_completion_timeout
> + (&info->completion, EXYNOS_ADC_TIMEOUT);
Should be properly aligned:
wait_for_completion_timeout(&info->completion,
EXYNOS_ADC_TIMEOUT);
--
Regards,
Varka Bhadram
^ permalink raw reply
* [PATCH -next] ARM: mvebu: fix return value check in armada_xp_pmsu_cpufreq_init()
From: weiyj_lk at 163.com @ 2014-07-22 14:18 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
In case of error, the function clk_get() 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@trendmicro.com.cn>
---
arch/arm/mach-mvebu/pmsu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
index c30b7d7..4f6ef6e 100644
--- a/arch/arm/mach-mvebu/pmsu.c
+++ b/arch/arm/mach-mvebu/pmsu.c
@@ -637,9 +637,9 @@ static int __init armada_xp_pmsu_cpufreq_init(void)
}
clk = clk_get(cpu_dev, 0);
- if (!clk) {
+ if (IS_ERR(clk)) {
pr_err("Cannot get clock for CPU %d\n", cpu);
- return -ENODEV;
+ return PTR_ERR(clk);
}
/*
^ permalink raw reply related
* [PATCH] ARM: at91/dt: sam9x5: fix ADC compatible string
From: Alexandre Belloni @ 2014-07-22 14:07 UTC (permalink / raw)
To: linux-arm-kernel
Use the correct compatible string for the ADC of the at91sam9x5 family of SoCs.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/boot/dts/at91sam9x5.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 2c0d6ea3ab41..5d7cf394f537 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -964,7 +964,7 @@
adc0: adc at f804c000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "atmel,at91sam9260-adc";
+ compatible = "atmel,at91sam9x5-adc";
reg = <0xf804c000 0x100>;
interrupts = <19 IRQ_TYPE_LEVEL_HIGH 0>;
clocks = <&adc_clk>,
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] usb: host: st-hcd: Add USB HCD support for STi SoCs
From: Peter Griffin @ 2014-07-22 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1407141054010.10763-100000@netrider.rowland.org>
Hi Alan,
> >
> > Most platform drivers have already been moved.
>
> Okay, I grant the point. Objections withdrawn. Fix up the spelling
> error and the other stuff in the Kconfig help text, and this will be
> acceptable.
Thanks, I intend to send a new version shortly.
regards,
Peter.
^ permalink raw reply
* [RFC PATCH] usb: dwc3: core: allow vendor drivers to check probe status
From: Peter Griffin @ 2014-07-22 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718144044.GJ24914@saruman.home>
Hi Felipe,
Sorry for the delay in replying. I've been trying to get to the root cause
of this problem so I could reply which took longer than I had hoped.
The problem manifested itself as a hang on register read/write access if dwc3-st
probed before the usb3 phy. Even though dwc3 core would bail and return
-EPROBE_DEFER that is not propogated up through of_platform_populate.
<snip>
>
> yeah, because glue layers are not supposed to know. There should be no
> coupling what so ever between glue layer and core driver, other than the
> fact that glue layer is the one which triggers platform_device creation
> through of_platform_population(). But the glue layer has (or should
> have) no interest in exactly when the core driver finishes probing.
Thanks for this clue :-) As it got me debugging why there was this dependency
between the usb3 phy IP and the ST glue register wrapper around the dwc3 usb core.
The reason for the depedency / hang is that there is a shared reset signal
for the dwc3 core, glue registers and usb3 phy. This reset signal was only
being managed in the USB3 phy driver, which is why if dwc3-st or dwc3 did
any register access it would cause a hang.
So the solution is in addition to taking the devm_reset_control for the powerdown
signal, in V3 of the dwc3-st glue layer, it also gets the softreset signal,
and deasserts this before any register accesses.
This is now working properly without any init ordering hacks etc.
>
> > commit message, another way of ensuring the PHYs are available is to
> > request them, but this would mean an awful lot of code duplication.
> >
> > In your opinion, what's the best way to handle this?
>
> How can I know ? You still haven't fully explained what you need. All
> you said was that you're trying to "configure through the glue-layer".
We can forget about this now. Having dwc3-st take a reference on the usb3 phys was
just another method I was experimenting with to find out whether the usb3
PHY had probed or not.
>
> Care to further explain what the problem really is ? I'm assuming below
> is what you're concerned about which I had to go dig in the archives
> because there was no reference to that patch anywhere here.
Hopefully I have now above, and the proposed solution.
>
> > +static void st_dwc3_init(struct st_dwc3 *dwc3_data)
> > +{
> > + u32 reg = st_dwc3_readl(dwc3_data->glue_base, USB2_CLKRST_CTRL);
> > +
> > + reg |= aux_clk_en(1) | ext_cfg_reset_n(1) | xhci_revision(1);
>
> so you have auxiliary clock, an external config reset, what's this
> xhci_revision ?
xhci_revision is an input signal to the dwc3 core, if it is asserted then
the host controller compiles with the xHCI revision 1.0 spec, if not it
complies with xHCI revision 0.96 spec. This input signal to dwc3 core is
exposed in the CLKRST_CTRL glue register wrapped around the controller by ST.
Looking through the docs, it was present until 2.40a, then removed as an input signal
to the core from 2.50a onwards.
To make this clearer I have also added a comment above the xhci_revision macro
in V3 of the dwc3-st patches explaining the bitfield and what it does.
> looks like it should be split between a CCF and reset drivers. Or maybe
> a single driver which does both. Do you have a clock/reset control for
> all IPs ?
Yes most IPs which have reset or powerdown signals are already controlled by
a driver in drivers/reset/sti. These reset and powerdown signals are all exposed
in the sysconfig registers of the SoC. Indeed it was a shared reset signal
which wasn't being properly managed and causing the hang.
However the reset signal and clock gate here is controlling a small piece of
wrapper IP called pipew which sits between the dwc3 core and usb3 phy.
I believe this pipew protocol wrapper hardware is designed internally
by ST, and has some special contriants which is why these reset signals
are being exposed here in the glue logic (see below).
> That might be a good way to hide stuff, driver would simply
> call clk_get()/clk_prepare_enable() and reset_assert()/deassert() when
> necessary (sure, this doesn't solve the 'when has that guy probe' but
> you still haven't explained why you need it).
>
> > + reg = st_dwc3_readl(dwc3_data->glue_base, USB2_VBUS_MNGMNT_SEL1);
> > + reg |= SEL_OVERRIDE_VBUSVALID(1) | SEL_OVERRIDE_POWERPRESENT(1) |
> > + SEL_OVERRIDE_BVALID(1);
>
> this is not correct. You don't know if VBUS is really valid at this
> time. We have used a gpio which gets pull high/low depending on the
> state of VBUS/ID.
This isn't stating that VBUS is valid, it is configuring a mux to select where
the vbus / bvalid / powerpresent signals will be selected from.
I have added a better comment in V3 which hopefully makes the function of
VBUS_MNGMNT_SEL register clearer.
>
> > + st_dwc3_writel(dwc3_data->glue_base, USB2_VBUS_MNGMNT_SEL1, reg);
> > + udelay(100);
> > +
> > + reg = st_dwc3_readl(dwc3_data->glue_base, USB2_CLKRST_CTRL);
> > + reg |= sw_pipew_reset_n(1);
> > + st_dwc3_writel(dwc3_data->glue_base, USB2_CLKRST_CTRL, reg);
>
> let me ask you something else. Isn't the DWC3_GUSB3PIPECTL_PHYSOFTRST
> bit functional for you guys ? This sw_pipe2_reset_n looks suspicious.
Your right to be suspicious ;-)
Due to a constriant on the pipew hardware, they have provided two extra
software controlled resets ext_cfg_reset and sw_pipew_reset in the CLKRST_CTRL
glue reg.
These two software controlled resets are ANDED with the nominal cfg_reset_n
and pipe_reset_n resets to the pipew hardware.
So yes DWC3_GUSB3PIPECTL_PHYSOFTRST is functional, but it will only
actually issue a reset to pipew and then onto MiPHY if sw_pipew_reset_n
is also set in the glue. The same goes with the global bus_reset_n signal
which is subsystem wide reset, it will only bepropogated to pipew if
ext_cfg_reset is also set in CLKRST_CTRL.
Hopefully that makes things clearer and I've answered everything.
I intend to send a V3 shortly.
kind regards,
Peter.
^ permalink raw reply
* [PATCH 09/19] mfd: ezx-pcap: Repair coding style errors picked up with checkpatch
From: Lee Jones @ 2014-07-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406036038.30871.19.camel@joe-AO725>
On Tue, 22 Jul 2014, Joe Perches wrote:
> On Tue, 2014-07-22 at 12:11 +0100, Lee Jones wrote:
> > This is part of an effort to clean-up the MFD subsystem.
> >
> > WARNING: Missing a blank line after declarations
> > + u32 flags;
> > + void (*callback)(void *, u16[]);
>
> False positive from an old version of checkpatch.
>
> The one in -next doesn't emit this as it's
> simply a function pointer declaration.
Thanks Joe, will fix up.
> > diff --git a/drivers/mfd/ezx-pcap.c b/drivers/mfd/ezx-pcap.c
> []
> > @@ -25,8 +25,9 @@ struct pcap_adc_request {
> > u8 bank;
> > u8 ch[2];
> > u32 flags;
> > - void (*callback)(void *, u16[]);
> > void *data;
> > +
> > + void (*callback)(void *, u16[]);
> > };
>
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] ARM: imx6: fix SMP compilation again
From: Shawn Guo @ 2014-07-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <16557676.B1fW0k49Wz@wuerfel>
On Tue, Jul 22, 2014 at 12:26:31PM +0200, Arnd Bergmann wrote:
> Ah, you are right, I got the text wrong here, and I think I now understand
> why it didn't happen earlier. Updated patch below (same patch, new
> text).
>
> 8<-------------
> Subject: [PATCH] ARM: imx6: fix SMP compilation again
>
> My earlier patch 1fc593feaf8e ("ARM: imx: build i.MX6 functions
> only when needed") fixed a problem with building an i.MX5 kernel,
> but now the problem has returned for the case where we allow
> ARMv6K SMP builds in multiplatform. With CONFIG_CPU_V7 disabled,
> but i.MX3 and SMP enabled, we get this build error:
Maybe I missed something, but I have problem to get the following three
conditions meet in a single kernel configuration.
a) CONFIG_CPU_V7 disabled
b) i.MX3 enabled
c) SMP enabled
When I get a) and b) in the config, I have no way to get c). And it
seems that the only way to get a) and c) at the same time is to enable
MACH_REALVIEW_PB11MP, which is not part of multi-platform support. So
i.MX3 cannot be enabled in there.
I tried both mainline and -next tree. I really need some help to
reproduce the error first.
>
> arch/arm/mach-imx/built-in.o: In function `v7_secondary_startup':
> :(.text+0x5124): undefined reference to `v7_invalidate_l1'
>
> This puts the code inside of an "ifdef CONFIG_SMP" to hopefully
The code says "ifdef CONFIG_SOC_IMX6"?
Shawn
> do the right thing in all configurations.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index ac88599ca080..23c02932bf84 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -93,9 +93,11 @@ obj-$(CONFIG_HAVE_IMX_ANATOP) += anatop.o
> obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
> obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o
> obj-$(CONFIG_HAVE_IMX_SRC) += src.o
> +ifdef CONFIG_SOC_IMX6
> AFLAGS_headsmp.o :=-Wa,-march=armv7-a
> obj-$(CONFIG_SMP) += headsmp.o platsmp.o
> obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
> +endif
> obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o mach-imx6q.o
> obj-$(CONFIG_SOC_IMX6SL) += clk-imx6sl.o mach-imx6sl.o
> obj-$(CONFIG_SOC_IMX6SX) += clk-imx6sx.o mach-imx6sx.o
>
^ 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