* Fwd: [PATCH v3 6/7] DT: Convert all kirkwood boards with mv643xx that use DT
From: Jason Cooper @ 2013-01-24 18:43 UTC (permalink / raw)
To: linux-arm-kernel
All,
Here's the patch converting all the kirkwood DT boards to Ian's
mv643xx_eth binding. Unfortunately, what I don't like is that the call
to kirkwood_ge00_init() remains, but with a NULL argument.
thx,
Jason.
----- Forwarded message from Ian Molton <ian.molton@codethink.co.uk> -----
Date: Tue, 7 Aug 2012 15:34:51 +0100
From: Ian Molton <ian.molton@codethink.co.uk>
To: linux-arm-kernel at lists.infradead.org
Cc: thomas.petazzoni at free-electrons.com, andrew at lunn.ch,
ben.dooks at codethink.co.uk, arnd at arndb.de, netdev at vger.kernel.org
Subject: [PATCH v3 6/7] DT: Convert all kirkwood boards with mv643xx that use DT
This patch converts all present DT capable kirkwood board configurations
to use DT to configure the mv643xx ethernet controller.
Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
---
arch/arm/boot/dts/kirkwood-dnskw.dtsi | 9 +++++++++
arch/arm/boot/dts/kirkwood-dreamplug.dts | 18 ++++++++++++++++++
arch/arm/boot/dts/kirkwood-goflexnet.dts | 8 ++++++++
arch/arm/boot/dts/kirkwood-ib62x0.dts | 10 ++++++++++
arch/arm/boot/dts/kirkwood-iconnect.dts | 10 ++++++++++
arch/arm/boot/dts/kirkwood-lsxl.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/kirkwood-ts219-6281.dts | 8 +++++++-
arch/arm/boot/dts/kirkwood-ts219-6282.dts | 8 +++++++-
arch/arm/boot/dts/kirkwood-ts219.dtsi | 3 +++
arch/arm/mach-kirkwood/board-dnskw.c | 7 +------
arch/arm/mach-kirkwood/board-dreamplug.c | 13 ++-----------
arch/arm/mach-kirkwood/board-goflexnet.c | 7 +------
arch/arm/mach-kirkwood/board-ib62x0.c | 7 +------
arch/arm/mach-kirkwood/board-iconnect.c | 7 +------
arch/arm/mach-kirkwood/board-lsxl.c | 13 ++-----------
arch/arm/mach-kirkwood/board-ts219.c | 10 +---------
16 files changed, 98 insertions(+), 57 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
index 7408655..214fe0b 100644
--- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
@@ -65,5 +65,14 @@
reg = <0x7b00000 0x500000>;
};
};
+
+ smi0: mdio at 72000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <8>;
+ status = "ok";
+ };
};
};
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index 26e281f..c27ed1c 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -53,6 +53,24 @@
status = "okay";
nr-ports = <1>;
};
+
+ smi0: mdio at 72000 {
+ status = "ok";
+ };
+
+ smi1: mdio at 76000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
+
+ egiga1 {
+ phy_addr = <1>;
+ status = "ok";
+ };
};
gpio-leds {
diff --git a/arch/arm/boot/dts/kirkwood-goflexnet.dts b/arch/arm/boot/dts/kirkwood-goflexnet.dts
index 7c8238f..f03dbd0 100644
--- a/arch/arm/boot/dts/kirkwood-goflexnet.dts
+++ b/arch/arm/boot/dts/kirkwood-goflexnet.dts
@@ -50,6 +50,14 @@
nr-ports = <2>;
};
+ smi0: mdio at 72000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
};
gpio-leds {
compatible = "gpio-leds";
diff --git a/arch/arm/boot/dts/kirkwood-ib62x0.dts b/arch/arm/boot/dts/kirkwood-ib62x0.dts
index 66794ed..8c462a1 100644
--- a/arch/arm/boot/dts/kirkwood-ib62x0.dts
+++ b/arch/arm/boot/dts/kirkwood-ib62x0.dts
@@ -45,6 +45,16 @@
};
};
+
+ smi0: mdio at 72000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <8>;
+ status = "ok";
+ };
+
};
gpio_keys {
diff --git a/arch/arm/boot/dts/kirkwood-iconnect.dts b/arch/arm/boot/dts/kirkwood-iconnect.dts
index 52d9470..9fc82be 100644
--- a/arch/arm/boot/dts/kirkwood-iconnect.dts
+++ b/arch/arm/boot/dts/kirkwood-iconnect.dts
@@ -30,6 +30,16 @@
clock-frequency = <200000000>;
status = "ok";
};
+
+ smi0: mdio at 72000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <b>;
+ status = "ok";
+ };
+
};
gpio-leds {
compatible = "gpio-leds";
diff --git a/arch/arm/boot/dts/kirkwood-lsxl.dtsi b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
index 8ac51c0..2f47661 100644
--- a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
+++ b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
@@ -40,6 +40,23 @@
};
};
};
+ smi0: mdio at 72000 {
+ status = "ok";
+ };
+
+ smi1: mdio at 76000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
+
+ egiga1 {
+ phy_addr = <8>;
+ status = "ok";
+ };
};
gpio_keys {
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6281.dts b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
index ccbf327..4ca49b5 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6281.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
@@ -3,6 +3,12 @@
/include/ "kirkwood-ts219.dtsi"
/ {
+ ocp at f1000000 {
+ egiga0 {
+ phy_addr = <8>;
+ status = "ok";
+ };
+ };
gpio_keys {
compatible = "gpio-keys";
#address-cells = <1>;
@@ -18,4 +24,4 @@
gpios = <&gpio0 16 1>;
};
};
-};
\ No newline at end of file
+};
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6282.dts b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
index fbe9932..40f3c61 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6282.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
@@ -3,6 +3,12 @@
/include/ "kirkwood-ts219.dtsi"
/ {
+ ocp at f1000000 {
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
+ };
gpio_keys {
compatible = "gpio-keys";
#address-cells = <1>;
@@ -18,4 +24,4 @@
gpios = <&gpio1 5 1>;
};
};
-};
\ No newline at end of file
+};
diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
index 64ea27c..06caf41 100644
--- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
@@ -74,5 +74,8 @@
status = "okay";
nr-ports = <2>;
};
+ smi0: mdio at 72000 {
+ status = "ok";
+ };
};
};
diff --git a/arch/arm/mach-kirkwood/board-dnskw.c b/arch/arm/mach-kirkwood/board-dnskw.c
index 4ab3506..4d8216b 100644
--- a/arch/arm/mach-kirkwood/board-dnskw.c
+++ b/arch/arm/mach-kirkwood/board-dnskw.c
@@ -15,7 +15,6 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
#include <linux/of.h>
#include <linux/gpio.h>
#include <linux/input.h>
@@ -29,10 +28,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data dnskw_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
static unsigned int dnskw_mpp_config[] __initdata = {
MPP13_UART1_TXD, /* Custom ... */
MPP14_UART1_RXD, /* ... Controller (DNS-320 only) */
@@ -112,7 +107,7 @@ void __init dnskw_init(void)
kirkwood_mpp_conf(dnskw_mpp_config);
kirkwood_ehci_init();
- kirkwood_ge00_init(&dnskw_ge00_data);
+ kirkwood_ge00_init(NULL);
platform_device_register(&dnskw_fan_device);
diff --git a/arch/arm/mach-kirkwood/board-dreamplug.c b/arch/arm/mach-kirkwood/board-dreamplug.c
index aeb234d..b97a112 100644
--- a/arch/arm/mach-kirkwood/board-dreamplug.c
+++ b/arch/arm/mach-kirkwood/board-dreamplug.c
@@ -15,7 +15,6 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_fdt.h>
@@ -34,14 +33,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data dreamplug_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data dreamplug_ge01_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(1),
-};
-
static struct mvsdio_platform_data dreamplug_mvsdio_data = {
/* unfortunately the CD signal has not been connected */
};
@@ -65,7 +56,7 @@ void __init dreamplug_init(void)
kirkwood_mpp_conf(dreamplug_mpp_config);
kirkwood_ehci_init();
- kirkwood_ge00_init(&dreamplug_ge00_data);
- kirkwood_ge01_init(&dreamplug_ge01_data);
+ kirkwood_ge00_init(NULL);
+ kirkwood_ge01_init(NULL);
kirkwood_sdio_init(&dreamplug_mvsdio_data);
}
diff --git a/arch/arm/mach-kirkwood/board-goflexnet.c b/arch/arm/mach-kirkwood/board-goflexnet.c
index 413e2c8..be7437d 100644
--- a/arch/arm/mach-kirkwood/board-goflexnet.c
+++ b/arch/arm/mach-kirkwood/board-goflexnet.c
@@ -20,7 +20,6 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_fdt.h>
@@ -36,10 +35,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data goflexnet_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(0),
-};
-
static unsigned int goflexnet_mpp_config[] __initdata = {
MPP29_GPIO, /* USB Power Enable */
MPP47_GPIO, /* LED Orange */
@@ -67,5 +62,5 @@ void __init goflexnet_init(void)
pr_err("can't setup GPIO 29 (USB Power Enable)\n");
kirkwood_ehci_init();
- kirkwood_ge00_init(&goflexnet_ge00_data);
+ kirkwood_ge00_init(NULL);
}
diff --git a/arch/arm/mach-kirkwood/board-ib62x0.c b/arch/arm/mach-kirkwood/board-ib62x0.c
index cfc47f8..0a29183 100644
--- a/arch/arm/mach-kirkwood/board-ib62x0.c
+++ b/arch/arm/mach-kirkwood/board-ib62x0.c
@@ -16,7 +16,6 @@
#include <linux/platform_device.h>
#include <linux/mtd/partitions.h>
#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
#include <linux/input.h>
#include <asm/mach-types.h>
@@ -27,10 +26,6 @@
#define IB62X0_GPIO_POWER_OFF 24
-static struct mv643xx_eth_platform_data ib62x0_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
static unsigned int ib62x0_mpp_config[] __initdata = {
MPP0_NF_IO2,
MPP1_NF_IO3,
@@ -62,7 +57,7 @@ void __init ib62x0_init(void)
kirkwood_mpp_conf(ib62x0_mpp_config);
kirkwood_ehci_init();
- kirkwood_ge00_init(&ib62x0_ge00_data);
+ kirkwood_ge00_init(NULL);
if (gpio_request(IB62X0_GPIO_POWER_OFF, "ib62x0:power:off") == 0 &&
gpio_direction_output(IB62X0_GPIO_POWER_OFF, 0) == 0)
pm_power_off = ib62x0_power_off;
diff --git a/arch/arm/mach-kirkwood/board-iconnect.c b/arch/arm/mach-kirkwood/board-iconnect.c
index d7a9198..220f0d4 100644
--- a/arch/arm/mach-kirkwood/board-iconnect.c
+++ b/arch/arm/mach-kirkwood/board-iconnect.c
@@ -17,7 +17,6 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/mtd/partitions.h>
-#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
#include <linux/input.h>
#include <linux/gpio_keys.h>
@@ -26,10 +25,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data iconnect_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(11),
-};
-
static unsigned int iconnect_mpp_config[] __initdata = {
MPP12_GPIO,
MPP35_GPIO,
@@ -92,7 +87,7 @@ void __init iconnect_init(void)
kirkwood_nand_init(ARRAY_AND_SIZE(iconnect_nand_parts), 25);
kirkwood_ehci_init();
- kirkwood_ge00_init(&iconnect_ge00_data);
+ kirkwood_ge00_init(NULL);
platform_device_register(&iconnect_button_device);
}
diff --git a/arch/arm/mach-kirkwood/board-lsxl.c b/arch/arm/mach-kirkwood/board-lsxl.c
index 83d8975..60331d1 100644
--- a/arch/arm/mach-kirkwood/board-lsxl.c
+++ b/arch/arm/mach-kirkwood/board-lsxl.c
@@ -18,7 +18,6 @@
#include <linux/ata_platform.h>
#include <linux/spi/flash.h>
#include <linux/spi/spi.h>
-#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
#include <linux/gpio-fan.h>
#include <linux/input.h>
@@ -28,14 +27,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data lsxl_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data lsxl_ge01_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
static unsigned int lsxl_mpp_config[] __initdata = {
MPP10_GPO, /* HDD Power Enable */
MPP11_GPIO, /* USB Vbus Enable */
@@ -126,8 +117,8 @@ void __init lsxl_init(void)
gpio_set_value(LSXL_GPIO_HDD_POWER, 1);
kirkwood_ehci_init();
- kirkwood_ge00_init(&lsxl_ge00_data);
- kirkwood_ge01_init(&lsxl_ge01_data);
+ kirkwood_ge00_init(NULL);
+ kirkwood_ge01_init(NULL);
platform_device_register(&lsxl_fan_device);
/* register power-off method */
diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
index 1750e68..7e7fe6c 100644
--- a/arch/arm/mach-kirkwood/board-ts219.c
+++ b/arch/arm/mach-kirkwood/board-ts219.c
@@ -18,7 +18,6 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
#include <linux/ata_platform.h>
#include <linux/gpio_keys.h>
#include <linux/input.h>
@@ -29,10 +28,6 @@
#include "mpp.h"
#include "tsx1x-common.h"
-static struct mv643xx_eth_platform_data qnap_ts219_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
static unsigned int qnap_ts219_mpp_config[] __initdata = {
MPP0_SPI_SCn,
MPP1_SPI_MOSI,
@@ -62,10 +57,7 @@ void __init qnap_dt_ts219_init(void)
kirkwood_mpp_conf(qnap_ts219_mpp_config);
kirkwood_pcie_id(&dev, &rev);
- if (dev == MV88F6282_DEV_ID)
- qnap_ts219_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
-
- kirkwood_ge00_init(&qnap_ts219_ge00_data);
+ kirkwood_ge00_init(NULL);
kirkwood_ehci_init();
pm_power_off = qnap_tsx1x_power_off;
--
1.7.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
----- End forwarded message -----
^ permalink raw reply related
* [PATCH RESEND] ARM: dts: max77686: Add DTS file for max77686 PMIC
From: Dongjin Kim @ 2013-01-24 18:46 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds a dedicated DTS file for max77686 PMIC, supposed to be included
in a board DTS to control the power for certain consumer devices or AP with 9 BUCKs
and 26 LDOs
Signed-off-by: Dongjin Kim <tobetter@gmail.com>
---
arch/arm/boot/dts/max77686.dtsi | 156 +++++++++++++++++++++++++++++++++++++++
1 file changed, 156 insertions(+)
create mode 100644 arch/arm/boot/dts/max77686.dtsi
diff --git a/arch/arm/boot/dts/max77686.dtsi b/arch/arm/boot/dts/max77686.dtsi
new file mode 100644
index 0000000..b80baef
--- /dev/null
+++ b/arch/arm/boot/dts/max77686.dtsi
@@ -0,0 +1,156 @@
+/*
+ * Copyright (C) 2013 Dongjin Kim <tobetter@gmail.com>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ */
+
+&max77686 {
+ compatible = "maxim,max77686";
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ voltage-regulators {
+ buck1: buck at 10 {
+ regulator-compatible = "BUCK1";
+ };
+
+ buck2: buck at 12 {
+ regulator-compatible = "BUCK2";
+ };
+
+ buck3: buck at 1c {
+ regulator-compatible = "BUCK3";
+ };
+
+ buck4: buck at 26 {
+ regulator-compatible = "BUCK4";
+ };
+
+ buck5: buck at 30 {
+ regulator-compatible = "BUCK5";
+ };
+
+ buck6: buck at 32 {
+ regulator-compatible = "BUCK6";
+ };
+
+ buck7: buck at 34 {
+ regulator-compatible = "BUCK7";
+ };
+
+ buck8: buck at 36 {
+ regulator-compatible = "BUCK8";
+ };
+
+ buck9: buck at 38 {
+ regulator-compatible = "BUCK9";
+ };
+
+ ldo1: ldo at 40 {
+ regulator-compatible = "LDO1";
+ };
+
+ ldo2: ldo at 41 {
+ regulator-compatible = "LDO2";
+ };
+
+ ldo3: ldo at 42 {
+ regulator-compatible = "LDO3";
+ };
+
+ ldo4: ldo at 43 {
+ regulator-compatible = "LDO4";
+ };
+
+ ldo5: ldo at 44 {
+ regulator-compatible = "LDO5";
+ };
+
+ ldo6: ldo at 45 {
+ regulator-compatible = "LDO6";
+ };
+
+ ldo7: ldo at 46 {
+ regulator-compatible = "LDO7";
+ };
+
+ ldo8: ldo at 47 {
+ regulator-compatible = "LDO8";
+ };
+
+ ldo9: ldo at 48 {
+ regulator-compatible = "LDO9";
+ };
+
+ ldo10: ldo at 49 {
+ regulator-compatible = "LDO10";
+ };
+
+ ldo11: ldo at 4a {
+ regulator-compatible = "LDO11";
+ };
+
+ ldo12: ldo at 4b {
+ regulator-compatible = "LDO12";
+ };
+
+ ldo13: ldo at 4c {
+ regulator-compatible = "LDO13";
+ };
+
+ ldo14: ldo at 4d {
+ regulator-compatible = "LDO14";
+ };
+
+ ldo15: ldo at 4e {
+ regulator-compatible = "LDO15";
+ };
+
+ ldo16: ldo at 4f {
+ regulator-compatible = "LDO16";
+ };
+
+ ldo17: ldo at 50 {
+ regulator-compatible = "LDO17";
+ };
+
+ ldo18: ldo at 51 {
+ regulator-compatible = "LDO18";
+ };
+
+ ldo19: ldo at 52 {
+ regulator-compatible = "LDO19";
+ };
+
+ ldo20: ldo at 53 {
+ regulator-compatible = "LDO20";
+ };
+
+ ldo21: ldo at 54 {
+ regulator-compatible = "LDO21";
+ };
+
+ ldo22: ldo at 55 {
+ regulator-compatible = "LDO22";
+ };
+
+ ldo23: ldo at 56 {
+ regulator-compatible = "LDO23";
+ };
+
+ ldo24: ldo at 57 {
+ regulator-compatible = "LDO24";
+ };
+
+ ldo25: ldo at 58 {
+ regulator-compatible = "LDO25";
+ };
+
+ ldo26: ldo at 59 {
+ regulator-compatible = "LDO26";
+ };
+ };
+};
--
1.7.10.4
^ permalink raw reply related
* [PATCH v8 0/3] Cortex-M3 series once more
From: Jonathan Austin @ 2013-01-24 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358413196-5609-1-git-send-email-u.kleine-koenig@pengutronix.de>
Hi Uwe,
On 17/01/13 08:59, Uwe Kleine-K?nig wrote:
> Based on Jonny's comments I changed a few more details. The diff to v7
> can be found below after the diffstat. These are:
>
> - describe why a #define for cr_alignment is OK in both the
> commit log and a comment in the header file
> - a work around for errata 752419 that newer gcc warns about
> - add a few more comments for better readability
> - a whitespace fix
>
Thanks for making these changes.
As you will see I've now reviewed the other to patches in the series and
there are quite a few smaller things in there...
> I think the updates are minor enough to still allow the patches to go
> into v3.9-rc1. Russell, what do you think? You can pull them from
>
I think we should assess this once you've responded to the review of the
other two patches.
As far as merging these patches go, as well as the review comments on
each patch, I still have the same reservations that I raised around v6
of these about the fact that NVIC support and a platform are missing.
This means there's no way to actually *use* the V7M code. I understand
that you're prepared to commit to getting this in shape and ready to be
merged once the base support goes in - is that right?
What sort of time-frame do you expect to be able to do this in?
I'm happy to help review/work on NVIC support if you need more eyes (and
perhaps even minds!) on the problem, as well as test on the efm32 board.
> git://git.pengutronix.de/git/ukl/linux.git for-next
>
> still based on v3.7-rc1 + your commit "ARM: fix oops on initial entry to
> userspace with Thumb2 kernels".
Does it trivially re-base to v3.8-rc4?
>
> Catalin Marinas (1):
> Cortex-M3: Add base support for Cortex-M3
>
> Uwe Kleine-K?nig (2):
> ARM: make cr_alignment read-only #ifndef CONFIG_CPU_CP15
> Cortex-M3: Add support for exception handling
>
> arch/arm/include/asm/assembler.h | 13 ++-
> arch/arm/include/asm/cp15.h | 16 +++-
> arch/arm/include/asm/cputype.h | 3 +
> arch/arm/include/asm/glue-cache.h | 25 ++++++
> arch/arm/include/asm/glue-df.h | 8 ++
> arch/arm/include/asm/glue-proc.h | 9 ++
> arch/arm/include/asm/irqflags.h | 22 +++--
> arch/arm/include/asm/processor.h | 7 ++
> arch/arm/include/asm/ptrace.h | 8 ++
> arch/arm/include/asm/system_info.h | 1 +
> arch/arm/include/uapi/asm/ptrace.h | 36 ++++++--
> arch/arm/kernel/asm-offsets.c | 3 +
> arch/arm/kernel/entry-common.S | 4 +
> arch/arm/kernel/entry-header.S | 148 +++++++++++++++++++++++++++++++++
> arch/arm/kernel/entry-v7m.S | 134 ++++++++++++++++++++++++++++++
> arch/arm/kernel/head-common.S | 9 +-
> arch/arm/kernel/head-nommu.S | 9 +-
> arch/arm/kernel/process.c | 4 +
> arch/arm/kernel/ptrace.c | 3 +
> arch/arm/kernel/setup.c | 13 ++-
> arch/arm/kernel/traps.c | 2 +
> arch/arm/mm/alignment.c | 2 +
> arch/arm/mm/mmu.c | 17 ++++
> arch/arm/mm/nommu.c | 2 +
> arch/arm/mm/proc-v7m.S | 161 ++++++++++++++++++++++++++++++++++++
> 25 files changed, 637 insertions(+), 22 deletions(-)
> create mode 100644 arch/arm/kernel/entry-v7m.S
> create mode 100644 arch/arm/mm/proc-v7m.S
>
> The incremental changes since v7 are:
>
> diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
> index d814435..1f3262e 100644
> --- a/arch/arm/include/asm/cp15.h
> +++ b/arch/arm/include/asm/cp15.h
> @@ -86,6 +86,11 @@ static inline void set_copro_access(unsigned int val)
>
> #else /* ifdef CONFIG_CPU_CP15 */
>
> +/*
> + * cr_alignment and cr_no_alignment are tightly coupled to cp15 (at least in the
> + * minds of the developers). Yielding 0 for machines without a cp15 (and making
> + * it read-only) is fine for most cases and saves quite some #ifdeffery.
> + */
> #define cr_no_alignment UL(0)
> #define cr_alignment UL(0)
>
> diff --git a/arch/arm/include/uapi/asm/ptrace.h b/arch/arm/include/uapi/asm/ptrace.h
> index 2ae7d1b..d3be66e 100644
> --- a/arch/arm/include/uapi/asm/ptrace.h
> +++ b/arch/arm/include/uapi/asm/ptrace.h
> @@ -144,7 +144,7 @@ struct pt_regs {
> #define ARM_r1 uregs[1]
> #define ARM_r0 uregs[0]
> #define ARM_ORIG_r0 uregs[17]
> -#define ARM_EXC_RET uregs[18]
> +#define ARM_EXC_RET uregs[18]
>
> /*
> * The size of the user-visible VFP state as seen by PTRACE_GET/SETVFPREGS
> diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
> index a0991dc..842394c 100644
> --- a/arch/arm/kernel/entry-v7m.S
> +++ b/arch/arm/kernel/entry-v7m.S
> @@ -102,8 +102,8 @@ ENTRY(__switch_to)
> mov ip, r4
> mov r0, r5
> ldmia ip!, {r4 - r11} @ Load all regs saved previously
> - ldr sp, [ip], #4
> - ldr pc, [ip]
> + ldr sp, [ip]
> + ldr pc, [ip, #4]!
> .fnend
> ENDPROC(__switch_to)
>
> diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
> index 2f560c5..5b391a6 100644
> --- a/arch/arm/kernel/head-common.S
> +++ b/arch/arm/kernel/head-common.S
> @@ -117,7 +117,7 @@ __mmap_switched_data:
> #ifdef CONFIG_CPU_CP15
> .long cr_alignment @ r7
> #else
> - .long 0
> + .long 0 @ r7
> #endif
> .long init_thread_union + THREAD_START_SP @ sp
> .size __mmap_switched_data, . - __mmap_switched_data
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index b675918..92abdb8 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -196,7 +196,7 @@ void adjust_cr(unsigned long mask, unsigned long set)
> }
> #endif
>
> -#else
> +#else /* ifdef CONFIG_CPU_CP15 */
>
> static int __init early_cachepolicy(char *p)
> {
> @@ -210,7 +210,7 @@ static int __init noalign_setup(char *__unused)
> }
> __setup("noalign", noalign_setup);
>
> -#endif
> +#endif /* ifdef CONFIG_CPU_CP15 / else */
>
> #define PROT_PTE_DEVICE L_PTE_PRESENT|L_PTE_YOUNG|L_PTE_DIRTY|L_PTE_XN
> #define PROT_SECT_DEVICE PMD_TYPE_SECT|PMD_SECT_AP_WRITE
>
^ permalink raw reply
* [PATCH 0/4] clk: Provide option to unprepare unused clocks at late init
From: Mike Turquette @ 2013-01-24 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359045956-30741-1-git-send-email-ulf.hansson@stericsson.com>
Quoting Ulf Hansson (2013-01-24 08:45:52)
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> The disable_unused sequence executed at late init, is already handling the
> fast unused ungated clocks to be gated. This patchset extends this sequence to
> include the slow unused prepared clocks to be unprepared.
>
> The default behavior will not change in this patchset. To unprepare unused
> clocks during the disable_unused sequence, the clk_hw needs to implement
> the new optional callback, is_prepared.
>
> The motivation for this patchset is to save power. Clocks that is from
> bootloaders prepared|enabled, but not used should be unprepared|disabled.
>
> Patch 4 is specific for ux500, which implements the is_prepared callback
> for it's PRMCU clocks.
>
> Note that patch 1-3 has been sent earlier, but since a proof of concept
> patch could be useful, as patch 4 is, the hole patchset is resent.
>
Hi Ulf,
I had some minor discussion in patch #1. Otherwise patches #2 & #3 look
good to me.
Patch #4 is a bit interesting. There is nothing wrong with it per se,
but the general layering of the prcmu power stuff is the opposite of how
I had envisioned things. Your .prepare callback is making calls to some
pm_qos api but a quick grep did not reveal any definitions for those
functions, just some stubs in include/linux/mfd/dbx500-prcmu.h.
Do these functions scale voltage? I had figured that some day
per-device pm qos apis would call the clk api, not the other way around.
Anyways that is just food for thought and no reason to block patch #4.
Regards,
Mike
> Ulf Hansson (4):
> clk: Introduce optional is_prepared callback
> clk: Unprepare the unused prepared slow clocks at late init
> clk: Introduce optional unprepare_unused callback
> clk: ux500: Support is_prepared callback for clk-prcmu
>
> drivers/clk/clk.c | 53 ++++++++++++++++
> drivers/clk/ux500/clk-prcmu.c | 134 ++++++++++++++++++++++++-----------------
> include/linux/clk-provider.h | 11 ++++
> 3 files changed, 144 insertions(+), 54 deletions(-)
>
> --
> 1.7.10
^ permalink raw reply
* [RFC/PATCH 32/32] usb: gadget: drop now unnecessary flag
From: Tomasz Figa @ 2013-01-24 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359042370-4358-33-git-send-email-balbi@ti.com>
Hi Felipe,
On Thursday 24 of January 2013 17:46:10 Felipe Balbi wrote:
> We don't need the ->register_my_device flag
> anymore because all UDC drivers have been
> properly converted.
>
> Let's remove every history of it.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> drivers/usb/chipidea/udc.c | 1 -
> drivers/usb/dwc3/gadget.c | 1 -
> drivers/usb/gadget/amd5536udc.c | 1 -
> drivers/usb/gadget/at91_udc.c | 1 -
> drivers/usb/gadget/atmel_usba_udc.c | 1 -
> drivers/usb/gadget/bcm63xx_udc.c | 1 -
> drivers/usb/gadget/dummy_hcd.c | 1 -
> drivers/usb/gadget/fsl_qe_udc.c | 1 -
> drivers/usb/gadget/fsl_udc_core.c | 1 -
> drivers/usb/gadget/fusb300_udc.c | 1 -
> drivers/usb/gadget/goku_udc.c | 1 -
> drivers/usb/gadget/imx_udc.c | 1 -
> drivers/usb/gadget/lpc32xx_udc.c | 1 -
> drivers/usb/gadget/m66592-udc.c | 1 -
> drivers/usb/gadget/mv_u3d_core.c | 1 -
> drivers/usb/gadget/mv_udc_core.c | 1 -
> drivers/usb/gadget/net2272.c | 1 -
> drivers/usb/gadget/net2280.c | 1 -
> drivers/usb/gadget/omap_udc.c | 1 -
> drivers/usb/gadget/pch_udc.c | 1 -
> drivers/usb/gadget/pxa25x_udc.c | 1 -
> drivers/usb/gadget/pxa27x_udc.c | 1 -
> drivers/usb/gadget/r8a66597-udc.c | 1 -
> drivers/usb/gadget/s3c-hsotg.c | 1 -
> drivers/usb/gadget/s3c-hsudc.c | 1 -
> drivers/usb/gadget/s3c2410_udc.c | 1 -
> drivers/usb/gadget/udc-core.c | 3 ---
> drivers/usb/musb/musb_gadget.c | 1 -
> drivers/usb/renesas_usbhs/mod_gadget.c | 1 -
> include/linux/usb/gadget.h | 4 ----
> 30 files changed, 35 deletions(-)
>
[snip]
> diff --git a/drivers/usb/gadget/udc-core.c
> b/drivers/usb/gadget/udc-core.c index 9195054..4ee0efc 100644
> --- a/drivers/usb/gadget/udc-core.c
> +++ b/drivers/usb/gadget/udc-core.c
> @@ -173,7 +173,6 @@ int usb_add_gadget_udc(struct device *parent, struct
> usb_gadget *gadget) if (!udc)
> goto err1;
>
> - if (gadget->register_my_device) {
> dev_set_name(&gadget->dev, "gadget");
>
> ret = device_register(&gadget->dev);
> @@ -211,7 +210,6 @@ err3:
> put_device(&udc->dev);
>
> err2:
> - if (gadget->register_my_device)
> put_device(&gadget->dev);
> err1:
> return ret;
> @@ -267,7 +265,6 @@ found:
> kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
> device_unregister(&udc->dev);
>
> - if (gadget->register_my_device)
> device_unregister(&gadget->dev);
Correct me if I am wrong, but doesn't this patch leave us with incorrect
indentation?
Otherwise looks good.
Best regards,
Tomasz Figa
^ permalink raw reply
* [RFC/PATCH 01/32] usb: gadget: udc-core: allow udc class register gadget device
From: Tomasz Figa @ 2013-01-24 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359042370-4358-2-git-send-email-balbi@ti.com>
Hi Felipe,
On Thursday 24 of January 2013 17:45:39 Felipe Balbi wrote:
> Currently all UDC drivers are calling
> device_register() before calling
> usb_add_gadget_udc(). In order to avoid
> code duplication, we can allow udc-core.c
> register that device.
>
> However that would become a really large patch,
> so to cope with the meanwhile and allow us
> to write bite-sized patches, we're adding
> a flag which will be set by UDC driver once
> it removes the code for registering the
> gadget device.
>
> Once all are converted, the new flag will
> be removed.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> drivers/usb/gadget/udc-core.c | 23 +++++++++++++++++++----
> include/linux/usb/gadget.h | 4 ++++
> 2 files changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc-core.c
> b/drivers/usb/gadget/udc-core.c index 2a9cd36..9195054 100644
> --- a/drivers/usb/gadget/udc-core.c
> +++ b/drivers/usb/gadget/udc-core.c
> @@ -173,6 +173,14 @@ int usb_add_gadget_udc(struct device *parent,
> struct usb_gadget *gadget) if (!udc)
> goto err1;
>
> + if (gadget->register_my_device) {
> + dev_set_name(&gadget->dev, "gadget");
> +
> + ret = device_register(&gadget->dev);
> + if (ret)
> + goto err2;
> + }
> +
> device_initialize(&udc->dev);
> udc->dev.release = usb_udc_release;
> udc->dev.class = udc_class;
> @@ -180,7 +188,7 @@ int usb_add_gadget_udc(struct device *parent, struct
> usb_gadget *gadget) udc->dev.parent = parent;
> ret = dev_set_name(&udc->dev, "%s", kobject_name(&parent->kobj));
> if (ret)
> - goto err2;
> + goto err3;
Just a nitpick: If you are at changing labels of error path, wouldn't it
be better to give them some meaningful names? Like err_del_unlock,
err_put_udc, err_put_gadget, err_ret.
Otherwise looks good. Nice idea.
Reviewed-by: Tomasz Figa <tomasz.figa@gmail.com>
Best regards,
Tomasz Figa
> udc->gadget = gadget;
>
> @@ -189,18 +197,22 @@ int usb_add_gadget_udc(struct device *parent,
> struct usb_gadget *gadget)
>
> ret = device_add(&udc->dev);
> if (ret)
> - goto err3;
> + goto err4;
>
> mutex_unlock(&udc_lock);
>
> return 0;
> -err3:
> +
> +err4:
> list_del(&udc->list);
> mutex_unlock(&udc_lock);
>
> -err2:
> +err3:
> put_device(&udc->dev);
>
> +err2:
> + if (gadget->register_my_device)
> + put_device(&gadget->dev);
> err1:
> return ret;
> }
> @@ -254,6 +266,9 @@ found:
>
> kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
> device_unregister(&udc->dev);
> +
> + if (gadget->register_my_device)
> + device_unregister(&gadget->dev);
> }
> EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
>
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index 2e297e8..fcd9ef8 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -494,6 +494,9 @@ struct usb_gadget_ops {
> * only supports HNP on a different root port.
> * @b_hnp_enable: OTG device feature flag, indicating that the A-Host
> * enabled HNP support.
> + * @register_my_device: Flag telling udc-core that UDC driver didn't
> + * register the gadget device to the driver model. Temporary until
> + * all UDC drivers are fixed up properly.
> * @name: Identifies the controller hardware type. Used in diagnostics
> * and sometimes configuration.
> * @dev: Driver model state for this abstract device.
> @@ -531,6 +534,7 @@ struct usb_gadget {
> unsigned b_hnp_enable:1;
> unsigned a_hnp_support:1;
> unsigned a_alt_hnp_support:1;
> + unsigned register_my_device:1;
> const char *name;
> struct device dev;
> unsigned out_epnum;
^ permalink raw reply
* [PATCH v1 4/6] drivers: usb: musb: omap: make use of the new PHY lib APIs
From: kishon @ 2013-01-24 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FE9DA6.4030507@ti.com>
Hi,
On Tuesday 22 January 2013 07:39 PM, Roger Quadros wrote:
> On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
>> New PHY lib APIs like usb_add_phy_dev() and devm_usb_get_phy_dev() are
>> used in MUSB (OMAP), in order to make use of the binding information
>> provided in the board file (of OMAP platforms).
>> All the platforms should be modified similar to this to add and get the
>> PHY.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>> drivers/usb/musb/omap2430.c | 2 +-
>> drivers/usb/otg/twl4030-usb.c | 3 ++-
>> drivers/usb/phy/omap-usb2.c | 3 ++-
>> 3 files changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>> index bf6cfe0..1a8cf6d 100644
>> --- a/drivers/usb/musb/omap2430.c
>> +++ b/drivers/usb/musb/omap2430.c
>> @@ -345,7 +345,7 @@ static int omap2430_musb_init(struct musb *musb)
>> * up through ULPI. TWL4030-family PMICs include one,
>> * which needs a driver, drivers aren't always needed.
>> */
>> - musb->xceiv = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
>> + musb->xceiv = devm_usb_get_phy_dev(dev, 0);
>> if (IS_ERR_OR_NULL(musb->xceiv)) {
>> pr_err("HS USB OTG: no transceiver configured\n");
>> return -ENODEV;
>> diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
>> index 0a70193..a994715 100644
>> --- a/drivers/usb/otg/twl4030-usb.c
>> +++ b/drivers/usb/otg/twl4030-usb.c
>> @@ -610,6 +610,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
>> twl->phy.dev = twl->dev;
>> twl->phy.label = "twl4030";
>> twl->phy.otg = otg;
>> + twl->phy.type = USB_PHY_TYPE_USB2;
>
> What is the need to set phy.type? I think this should be deprecated along with the old API.
The *type* field as such is not deprecated. Adding and getting a PHY
using *type* is deprecated.
Thanks
Kishon
^ permalink raw reply
* [PATCH 1/2] ARM: multi_v7_defconfig: remove unnecessary CONFIG_GPIOLIB
From: Josh Cartwright @ 2013-01-24 18:59 UTC (permalink / raw)
To: linux-arm-kernel
Commit 38669e045dbf8f62a008898a7fb1e93975b3817c ("ARM: vexpress: Start
using new Versatile Express infrastructure") introduces a hard
dependency to GPIOLIB for the multi_v7_defconfig:
ARCH_MULTI_V7 -> ARCH_VEXPRESS -> ARCH_REQUIRE_GPIOLIB -> GPIOLIB
Remove unnecessary explicit CONFIG_GPIOLIB=y from multi_v7_defconfig.
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
---
arch/arm/configs/multi_v7_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 2eeff1e..6862e76 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -39,7 +39,6 @@ CONFIG_I2C=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
CONFIG_SPI=y
CONFIG_SPI_PL022=y
-CONFIG_GPIOLIB=y
CONFIG_FB=y
CONFIG_FB_ARMCLCD=y
CONFIG_FRAMEBUFFER_CONSOLE=y
--
1.8.1.1
^ permalink raw reply related
* [RFC/PATCH 24/32] usb: gadget: s3c-hsotg: let udc-core manage gadget->dev
From: Tomasz Figa @ 2013-01-24 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359042370-4358-25-git-send-email-balbi@ti.com>
Hi Felipe,
On Thursday 24 of January 2013 17:46:02 Felipe Balbi wrote:
> By simply setting a flag, we can drop some
> boilerplate code.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> drivers/usb/gadget/s3c-hsotg.c | 14 +-------------
> 1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/drivers/usb/gadget/s3c-hsotg.c
> b/drivers/usb/gadget/s3c-hsotg.c index 833d85b..bd8292d 100644
> --- a/drivers/usb/gadget/s3c-hsotg.c
> +++ b/drivers/usb/gadget/s3c-hsotg.c
> @@ -3552,17 +3552,13 @@ static int s3c_hsotg_probe(struct
> platform_device *pdev)
>
> dev_info(dev, "regs %p, irq %d\n", hsotg->regs, hsotg->irq);
>
> - device_initialize(&hsotg->gadget.dev);
> -
> - dev_set_name(&hsotg->gadget.dev, "gadget");
> -
> hsotg->gadget.max_speed = USB_SPEED_HIGH;
> hsotg->gadget.ops = &s3c_hsotg_gadget_ops;
> hsotg->gadget.name = dev_name(dev);
> -
> hsotg->gadget.dev.parent = dev;
> hsotg->gadget.dev.dma_mask = dev->dma_mask;
> hsotg->gadget.dev.release = s3c_hsotg_release;
> + hsotg->gadget.register_my_device = true;
>
> /* reset the system */
>
> @@ -3643,12 +3639,6 @@ static int s3c_hsotg_probe(struct platform_device
> *pdev)
>
> s3c_hsotg_phy_disable(hsotg);
>
> - ret = device_add(&hsotg->gadget.dev);
> - if (ret) {
> - put_device(&hsotg->gadget.dev);
> - goto err_ep_mem;
> - }
> -
> ret = usb_add_gadget_udc(&pdev->dev, &hsotg->gadget);
> if (ret)
> goto err_ep_mem;
> @@ -3687,10 +3677,8 @@ static int s3c_hsotg_remove(struct
> platform_device *pdev) }
>
> s3c_hsotg_phy_disable(hsotg);
> -
> clk_disable_unprepare(hsotg->clk);
>
> - device_unregister(&hsotg->gadget.dev);
> return 0;
> }
Looks good.
Reviewed-by: Tomasz Figa <tomasz.figa@gmail.com>
Best regards,
Tomasz Figa
^ permalink raw reply
* [RFC/PATCH 32/32] usb: gadget: drop now unnecessary flag
From: Felipe Balbi @ 2013-01-24 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2268214.yJrDJgELNj@flatron>
On Thu, Jan 24, 2013 at 07:52:52PM +0100, Tomasz Figa wrote:
> Hi Felipe,
>
> On Thursday 24 of January 2013 17:46:10 Felipe Balbi wrote:
> > We don't need the ->register_my_device flag
> > anymore because all UDC drivers have been
> > properly converted.
> >
> > Let's remove every history of it.
> >
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > ---
> > drivers/usb/chipidea/udc.c | 1 -
> > drivers/usb/dwc3/gadget.c | 1 -
> > drivers/usb/gadget/amd5536udc.c | 1 -
> > drivers/usb/gadget/at91_udc.c | 1 -
> > drivers/usb/gadget/atmel_usba_udc.c | 1 -
> > drivers/usb/gadget/bcm63xx_udc.c | 1 -
> > drivers/usb/gadget/dummy_hcd.c | 1 -
> > drivers/usb/gadget/fsl_qe_udc.c | 1 -
> > drivers/usb/gadget/fsl_udc_core.c | 1 -
> > drivers/usb/gadget/fusb300_udc.c | 1 -
> > drivers/usb/gadget/goku_udc.c | 1 -
> > drivers/usb/gadget/imx_udc.c | 1 -
> > drivers/usb/gadget/lpc32xx_udc.c | 1 -
> > drivers/usb/gadget/m66592-udc.c | 1 -
> > drivers/usb/gadget/mv_u3d_core.c | 1 -
> > drivers/usb/gadget/mv_udc_core.c | 1 -
> > drivers/usb/gadget/net2272.c | 1 -
> > drivers/usb/gadget/net2280.c | 1 -
> > drivers/usb/gadget/omap_udc.c | 1 -
> > drivers/usb/gadget/pch_udc.c | 1 -
> > drivers/usb/gadget/pxa25x_udc.c | 1 -
> > drivers/usb/gadget/pxa27x_udc.c | 1 -
> > drivers/usb/gadget/r8a66597-udc.c | 1 -
> > drivers/usb/gadget/s3c-hsotg.c | 1 -
> > drivers/usb/gadget/s3c-hsudc.c | 1 -
> > drivers/usb/gadget/s3c2410_udc.c | 1 -
> > drivers/usb/gadget/udc-core.c | 3 ---
> > drivers/usb/musb/musb_gadget.c | 1 -
> > drivers/usb/renesas_usbhs/mod_gadget.c | 1 -
> > include/linux/usb/gadget.h | 4 ----
> > 30 files changed, 35 deletions(-)
> >
> [snip]
> > diff --git a/drivers/usb/gadget/udc-core.c
> > b/drivers/usb/gadget/udc-core.c index 9195054..4ee0efc 100644
> > --- a/drivers/usb/gadget/udc-core.c
> > +++ b/drivers/usb/gadget/udc-core.c
> > @@ -173,7 +173,6 @@ int usb_add_gadget_udc(struct device *parent, struct
> > usb_gadget *gadget) if (!udc)
> > goto err1;
> >
> > - if (gadget->register_my_device) {
> > dev_set_name(&gadget->dev, "gadget");
> >
> > ret = device_register(&gadget->dev);
> > @@ -211,7 +210,6 @@ err3:
> > put_device(&udc->dev);
> >
> > err2:
> > - if (gadget->register_my_device)
> > put_device(&gadget->dev);
> > err1:
> > return ret;
> > @@ -267,7 +265,6 @@ found:
> > kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
> > device_unregister(&udc->dev);
> >
> > - if (gadget->register_my_device)
> > device_unregister(&gadget->dev);
>
> Correct me if I am wrong, but doesn't this patch leave us with incorrect
> indentation?
right, I fixed it up on my branch, see [1]. That was me trusting my poor
sed skills and not verifying the result ;-)
[1] http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=commitdiff;h=d0bdf2970dd68677c65671be9bd56759593cfaf1
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130124/16277568/attachment.sig>
^ permalink raw reply
* [PATCH 5/7] clk: vt8500: Use common of_clk_init() function
From: Mike Turquette @ 2013-01-24 19:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358543280.8280.2.camel@gitbox>
Quoting Tony Prisk (2013-01-18 13:08:00)
> On Fri, 2013-01-18 at 09:56 -0800, Mike Turquette wrote:
> > Quoting Prashant Gaikwad (2013-01-03 23:00:56)
> > > Use common of_clk_init() function for clock initialization.
> > >
> > > Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
> >
> > Tony,
> >
> > Can I get a Tested-by from you before I take this in?
> >
> Tested-by: Tony Prisk <linux@prisktech.co.nz>
>
> FYI: This will need another patch to complete as we added another set of
> clocks to this clk-vt8500.c for 3.9.
>
Tony, is the following patch correct?
>From 5b6e0adb69674c684c33503f50010644b049029c Mon Sep 17 00:00:00 2001
From: Prashant Gaikwad <pgaikwad@nvidia.com>
Date: Fri, 4 Jan 2013 12:30:56 +0530
Subject: [PATCH] clk: vt8500: Use common of_clk_init() function
Use common of_clk_init() function for clock initialization.
Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
Tested-by: Tony Prisk <linux@prisktech.co.nz>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
[mturquette at linaro.org: added entry for wm8750-pll-clock]
Signed-off-by: Mike Turquette <mturquette@linaro.org>
---
drivers/clk/clk-vt8500.c | 17 +++++------------
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/clk-vt8500.c b/drivers/clk/clk-vt8500.c
index 2515d4f..b5538bb 100644
--- a/drivers/clk/clk-vt8500.c
+++ b/drivers/clk/clk-vt8500.c
@@ -291,7 +291,7 @@ static __init void vtwm_device_clk_init(struct device_node *node)
rc = of_clk_add_provider(node, of_clk_src_simple_get, clk);
clk_register_clkdev(clk, clk_name, NULL);
}
-
+CLK_OF_DECLARE(vt8500_device, "via,vt8500-device-clock", vtwm_device_clk_init);
/* PLL clock related functions */
@@ -612,26 +612,19 @@ static void __init vt8500_pll_init(struct device_node *node)
{
vtwm_pll_clk_init(node, PLL_TYPE_VT8500);
}
+CLK_OF_DECLARE(vt8500_pll, "via,vt8500-pll-clock", vt8500_pll_init);
static void __init wm8650_pll_init(struct device_node *node)
{
vtwm_pll_clk_init(node, PLL_TYPE_WM8650);
}
+CLK_OF_DECLARE(wm8650_pll, "wm,wm8650-pll-clock", wm8650_pll_init);
static void __init wm8750_pll_init(struct device_node *node)
{
vtwm_pll_clk_init(node, PLL_TYPE_WM8750);
}
-
-static const __initconst struct of_device_id clk_match[] = {
- { .compatible = "fixed-clock", .data = of_fixed_clk_setup, },
- { .compatible = "via,vt8500-pll-clock", .data = vt8500_pll_init, },
- { .compatible = "wm,wm8650-pll-clock", .data = wm8650_pll_init, },
- { .compatible = "wm,wm8750-pll-clock", .data = wm8750_pll_init, },
- { .compatible = "via,vt8500-device-clock",
- .data = vtwm_device_clk_init, },
- { /* sentinel */ }
-};
+CLK_OF_DECLARE(wm8750_pll, "wm,wm8750-pll-clock", wm8750_pll_init);
void __init vtwm_clk_init(void __iomem *base)
{
@@ -640,5 +633,5 @@ void __init vtwm_clk_init(void __iomem *base)
pmc_base = base;
- of_clk_init(clk_match);
+ of_clk_init(NULL);
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/7] clk: tegra: Use common of_clk_init() function
From: Mike Turquette @ 2013-01-24 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50E793A0.4020702@nvidia.com>
Quoting Prashant Gaikwad (2013-01-04 18:44:48)
> On Friday 04 January 2013 10:00 PM, Stephen Warren wrote:
> > On 01/04/2013 12:00 AM, Prashant Gaikwad wrote:
> >> Use common of_clk_init() function for clocks initialization.
> >> drivers/clk/tegra/clk-tegra20.c | 3 ++-
> >> drivers/clk/tegra/clk-tegra30.c | 3 ++-
> > Oh, so this series is written assuming that the Tegra CCF rework is
> > already applied then? That makes the dependencies quite painful, since I
> > think we'll end up with the following order being needed:
> >
> > 1) clk: Add composite clock type
> > -> This would usually go through the clk tree.
> > 2) The Tegra CCF rework series
> > -> This must go through the Tegra tree due to lots of dependencies
> > and merge conflicts with other Tegra patches.
> > 3) This series
> > -> This would usually go through the clk tree.
> >
> > Is it possible to re-order the dependencies as (1) (3) (2), so that Mike
> > can apply (1) and (3) to the clock tree, then I can use the clk tree as
> > the basis for a branch in the Tegra tree to apply (2) and all the other
> > Tegra patches that will conflict with (2)?
>
> If Mike approves the concept and implementation in (1) and (3) then I
> will repost (2) and (3) with dependencies re-ordered.
Patch (1) still has some unaddressed comments, and is not a real
dependency for this series. Since all of the patches have received their
Tested-by's then I propose to merge all patches from this series into
clk-next, which exception of patch 2/7 (the Tegra patch).
This reduces your Tegra CCF conversion dependencies and you can role the
necessary of_clk_init change into your Tegra CCF conversion branch (it
has my implicit Ack and can be taken through your tree).
Let me know if this is OK for you.
Thanks,
Mike
^ permalink raw reply
* [PATCH 2/7] clk: tegra: Use common of_clk_init() function
From: Stephen Warren @ 2013-01-24 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124192043.10623.60751@quantum>
On 01/24/2013 11:20 AM, Mike Turquette wrote:
> Quoting Prashant Gaikwad (2013-01-04 18:44:48)
>> On Friday 04 January 2013 10:00 PM, Stephen Warren wrote:
>>> On 01/04/2013 12:00 AM, Prashant Gaikwad wrote:
>>>> Use common of_clk_init() function for clocks initialization.
>>>> drivers/clk/tegra/clk-tegra20.c | 3 ++-
>>>> drivers/clk/tegra/clk-tegra30.c | 3 ++-
>>> Oh, so this series is written assuming that the Tegra CCF rework is
>>> already applied then? That makes the dependencies quite painful, since I
>>> think we'll end up with the following order being needed:
>>>
>>> 1) clk: Add composite clock type
>>> -> This would usually go through the clk tree.
>>> 2) The Tegra CCF rework series
>>> -> This must go through the Tegra tree due to lots of dependencies
>>> and merge conflicts with other Tegra patches.
>>> 3) This series
>>> -> This would usually go through the clk tree.
>>>
>>> Is it possible to re-order the dependencies as (1) (3) (2), so that Mike
>>> can apply (1) and (3) to the clock tree, then I can use the clk tree as
>>> the basis for a branch in the Tegra tree to apply (2) and all the other
>>> Tegra patches that will conflict with (2)?
>>
>> If Mike approves the concept and implementation in (1) and (3) then I
>> will repost (2) and (3) with dependencies re-ordered.
>
> Patch (1) still has some unaddressed comments, and is not a real
> dependency for this series.
I assume "Patch (1)" refers to the list of series a couple emails above,
not the first patch in the series you're replying to; that threw me for
a moment.
> Since all of the patches have received their
> Tested-by's then I propose to merge all patches from this series into
> clk-next, which exception of patch 2/7 (the Tegra patch).
>
> This reduces your Tegra CCF conversion dependencies and you can role the
> necessary of_clk_init change into your Tegra CCF conversion branch (it
> has my implicit Ack and can be taken through your tree).
>
> Let me know if this is OK for you.
OK, I'm happy to merge your clock tree into the Tegra tree and then
apply 2/7 on top of the Tegra CCF work.
^ permalink raw reply
* [PATCH 2/2] ARM: multi_v7_defconfig: add ARCH_ZYNQ
From: Josh Cartwright @ 2013-01-24 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bb37ce3392153c4cae3a2bc642f831683620473a.1359057921.git.josh.cartwright@ni.com>
Cc: Michal Simek <michal.simek@ni.com>
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
---
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 6862e76..e31d442 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -8,6 +8,7 @@ CONFIG_ARCH_HIGHBANK=y
CONFIG_ARCH_SOCFPGA=y
CONFIG_ARCH_SUNXI=y
# CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set
+CONFIG_ARCH_ZYNQ=y
CONFIG_ARM_ERRATA_754322=y
CONFIG_SMP=y
CONFIG_ARM_ARCH_TIMER=y
--
1.8.1.1
^ permalink raw reply related
* [PATCH 2/2] ARM: multi_v7_defconfig: add ARCH_ZYNQ
From: Josh Cartwright @ 2013-01-24 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <621fb4946273492b88fe9a903118047f497e00ee.1359057921.git.josh.cartwright@ni.com>
On Thu, Jan 24, 2013 at 01:33:25PM -0600, Josh Cartwright wrote:
> Cc: Michal Simek <michal.simek@ni.com>
Ugh, my fingers typed '@ni.com' out of habit. Corrected patch below
(and correct Cc added).
Josh
-- 8< --
Subject: [PATCH] ARM: multi_v7_defconfig: add ARCH_ZYNQ
Cc: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
---
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 6862e76..e31d442 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -8,6 +8,7 @@ CONFIG_ARCH_HIGHBANK=y
CONFIG_ARCH_SOCFPGA=y
CONFIG_ARCH_SUNXI=y
# CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set
+CONFIG_ARCH_ZYNQ=y
CONFIG_ARM_ERRATA_754322=y
CONFIG_SMP=y
CONFIG_ARM_ARCH_TIMER=y
--
1.8.1.1
^ permalink raw reply related
* [RFC PATCH 6/6] ARM: kirkwood: consolidate mv643xx_eth init for DT
From: Florian Fainelli @ 2013-01-24 20:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124181622.GD1758@titan.lakedaemon.net>
On Thursday 24 January 2013 13:16:22 Jason Cooper wrote:
> > >Ian's patch appears to do so. I'll respin this series using it vice my
> > >lookup table.
> > >
> > Sounds good, while at it, I wonder if we could not simplify Ian's
> > patch to be limited to the actual Ethernet MAC driver and use
> > Thomas's mvdio device tree binding for the MDIO bits of mv643xx_eth.
> > What do you think?
>
> It sounds like you just volunteered ;-) Do you think you have the time
> to knock it out for v3.9?
I do not have any kirkwood board at the moment and I really want to be able to
test this properly especially with the "clock must be enabled for ethernet not
be lost". Let me get one and I should be able to do it. Let's adopt your patch
for the moment, and once I have a kirkwood board I can deal with the ethernet
driver device tree bindings.
Does that sound ok with you?
>
> I'd like to drop most of these board-*.c files for v3.9. They've been
> bugging me since I added the first one (board-dreamplug.c).
>
> thx,
>
> Jason.
--
Florian
^ permalink raw reply
* [PATCH 1/4] clk: Introduce optional is_prepared callback
From: Ulf Hansson @ 2013-01-24 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124181249.10623.14484@quantum>
On 24 January 2013 19:12, Mike Turquette <mturquette@linaro.org> wrote:
> Quoting Ulf Hansson (2013-01-24 08:45:53)
>> From: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> To reflect whether a clk_hw is prepared the clk_hw may implement
>> the optional is_prepared callback. If not implemented we fall back
>> to use the software prepare counter.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> drivers/clk/clk.c | 21 +++++++++++++++++++++
>> include/linux/clk-provider.h | 6 ++++++
>> 2 files changed, 27 insertions(+)
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index 593a2e4..deb259a 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -458,6 +458,27 @@ unsigned long __clk_get_flags(struct clk *clk)
>> return !clk ? 0 : clk->flags;
>> }
>>
>> +bool __clk_is_prepared(struct clk *clk)
>> +{
>> + int ret;
>> +
>> + if (!clk)
>> + return false;
>> +
>> + /*
>> + * .is_prepared is optional for clocks that can prepare
>> + * fall back to software usage counter if it is missing
>> + */
>
> Why not make it mandatory? This could be as simple as saying "it is
> mandatory", or we could even enforce a check in clk_init, though the
> latter suggestion would be noisy until existing clock providers were
> updated.
I was trying to go "slow" forward and wanted to keep the same
behaviour for how .is_enabled is handled.
I am positive in making this mandatory, but then this should be
applied for is_enabled as well. If we make something mandatory I
definitely think it shall be checked in clk_int, it makes sense to me.
>
> Note that .is_enabled is technically mandatory for any clock that
> implements .enable/.disable but there is no check for compliance. It is
> only in Documentation/clk.txt and the kerneldoc.
According to the clk-provider.h file:
------
* @is_enabled: Queries the hardware to determine if the clock is enabled.
* This function must not sleep. Optional, if this op is not
* set then the enable count will be used.
-----
The Documentation/clk.txt says it is mandatory. :-) So we have a kind
of mixed message here.
>
> Regards,
> Mike
Kind regards
Ulf Hansson
^ permalink raw reply
* [RFC PATCH 6/6] ARM: kirkwood: consolidate mv643xx_eth init for DT
From: Jason Cooper @ 2013-01-24 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3084778.eWbl5o3HSt@bender>
On Thu, Jan 24, 2013 at 09:27:24PM +0100, Florian Fainelli wrote:
> On Thursday 24 January 2013 13:16:22 Jason Cooper wrote:
> > > >Ian's patch appears to do so. I'll respin this series using it vice my
> > > >lookup table.
> > > >
> > > Sounds good, while at it, I wonder if we could not simplify Ian's
> > > patch to be limited to the actual Ethernet MAC driver and use
> > > Thomas's mvdio device tree binding for the MDIO bits of mv643xx_eth.
> > > What do you think?
> >
> > It sounds like you just volunteered ;-) Do you think you have the time
> > to knock it out for v3.9?
>
> I do not have any kirkwood board at the moment and I really want to be able to
> test this properly especially with the "clock must be enabled for ethernet not
> be lost". Let me get one and I should be able to do it. Let's adopt your patch
> for the moment, and once I have a kirkwood board I can deal with the ethernet
> driver device tree bindings.
>
> Does that sound ok with you?
using Ian's patch as is, I have the following in kirkwood.dtsi:
+
+ smi0: mdio at 72000 {
+ compatible = "marvell,mdio-mv643xx";
+ reg = <0x72000 0x4000>;
+ interrupts = <46>;
+ status = "disabled";
+ };
+
+ smi1: mdio at 76000 {
+ compatible = "marvell,mdio-mv643xx";
+ reg = <0x76000 0x4000>;
+ interrupts = <47>;
+ status = "disabled";
+ };
+
+ egiga0 {
+ compatible = "marvell,mv643xx-eth";
+ reg = <0x72000 0x4000>;
+ mdio = <&smi0>;
+ port_number = <0>;
+ phy_addr = <0x80>;
+ interrupts = <11>;
+ clocks = <&gate_clk 0>;
+ status = "disabled";
+ };
+
+ egiga1 {
+ compatible = "marvell,mv643xx-eth";
+ reg = <0x76000 0x4000>;
+ mdio = <&smi1>;
+ port_number = <1>;
+ phy_addr = <0x81>;
+ interrupts = <15>;
+ clocks = <&gate_clk 19>;
+ status = "disabled";
+ };
I'll see if I can get it working as is, then we can migrate to Thomas'
mdio bindings.
btw - it might be a shared smi, I haven't looked yet, and haven't
tested...
thx,
Jason.
^ permalink raw reply
* [PATCH 0/4] clk: Provide option to unprepare unused clocks at late init
From: Ulf Hansson @ 2013-01-24 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124184944.10623.20870@quantum>
Hi Mike,
On 24 January 2013 19:49, Mike Turquette <mturquette@linaro.org> wrote:
> Quoting Ulf Hansson (2013-01-24 08:45:52)
>> From: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> The disable_unused sequence executed at late init, is already handling the
>> fast unused ungated clocks to be gated. This patchset extends this sequence to
>> include the slow unused prepared clocks to be unprepared.
>>
>> The default behavior will not change in this patchset. To unprepare unused
>> clocks during the disable_unused sequence, the clk_hw needs to implement
>> the new optional callback, is_prepared.
>>
>> The motivation for this patchset is to save power. Clocks that is from
>> bootloaders prepared|enabled, but not used should be unprepared|disabled.
>>
>> Patch 4 is specific for ux500, which implements the is_prepared callback
>> for it's PRMCU clocks.
>>
>> Note that patch 1-3 has been sent earlier, but since a proof of concept
>> patch could be useful, as patch 4 is, the hole patchset is resent.
>>
>
> Hi Ulf,
>
> I had some minor discussion in patch #1. Otherwise patches #2 & #3 look
> good to me.
>
> Patch #4 is a bit interesting. There is nothing wrong with it per se,
> but the general layering of the prcmu power stuff is the opposite of how
> I had envisioned things. Your .prepare callback is making calls to some
> pm_qos api but a quick grep did not reveal any definitions for those
> functions, just some stubs in include/linux/mfd/dbx500-prcmu.h.
>
> Do these functions scale voltage? I had figured that some day
> per-device pm qos apis would call the clk api, not the other way around.
You are right, these scale voltages. I would like to keep the code as
is, just as a reminder that some devices using some clocks will
requires these kind of operations.
On our internal STE development track this is how it is used but we a
are moving towards newer APIs.
So I am definitely sharing the same thought as you do and my plan is
to remove this code along the road, once drivers is adapted properly.
>
> Anyways that is just food for thought and no reason to block patch #4.
>
> Regards,
> Mike
>
>> Ulf Hansson (4):
>> clk: Introduce optional is_prepared callback
>> clk: Unprepare the unused prepared slow clocks at late init
>> clk: Introduce optional unprepare_unused callback
>> clk: ux500: Support is_prepared callback for clk-prcmu
>>
>> drivers/clk/clk.c | 53 ++++++++++++++++
>> drivers/clk/ux500/clk-prcmu.c | 134 ++++++++++++++++++++++++-----------------
>> include/linux/clk-provider.h | 11 ++++
>> 3 files changed, 144 insertions(+), 54 deletions(-)
>>
>> --
>> 1.7.10
Thanks for the review comments!
Kind regards
Ulf Hansson
^ permalink raw reply
* [PATCH v5 00/14] DMA Engine support for AM33XX
From: Matt Porter @ 2013-01-24 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d07dbfd50690423b903803720152c0dc@DLEE74.ent.ti.com>
On Thu, Jan 24, 2013 at 05:14:13AM +0000, Sekhar Nori wrote:
> Matt,
>
> On 1/24/2013 3:07 AM, Matt Porter wrote:
> > On Wed, Jan 23, 2013 at 10:21:42AM +0800, Mark Brown wrote:
> >> On Tue, Jan 22, 2013 at 09:26:34PM +0530, Sekhar Nori wrote:
> >>> On 1/16/2013 2:02 AM, Matt Porter wrote:
> >>
> >>>> This series adds DMA Engine support for AM33xx, which uses
> >>>> an EDMA DMAC. The EDMA DMAC has been previously supported by only
> >>>> a private API implementation (much like the situation with OMAP
> >>>> DMA) found on the DaVinci family of SoCs.
> >>
> >>> Will you take this series through the OMAP tree? Only 1/14 touches
> >>> mach-davinci and I am mostly okay with it except some changes I just
> >>> requested Matt to make in another thread.
> >>
> >> Is this series somewhere near actually getting merged then? It seemed
> >> like there was lots of stuff going on.
> >
> > The issues raised by Sekhar and Santosh were reasonably minor and will
> > be addressed. My major concern is that the dependency on some api to
> > fetch dmaengine driver SG limitations is not resolved. That's being
> > discussed in https://lkml.org/lkml/2013/1/10/432
>
> It might be worth posting the patches which don't have dependencies and
> are ready for acceptance as a separate series. That way at least some of
> these patches have a good chance of getting into v3.9 if not the entire
> series.
Yes a good idea and seems to be the best option. I've dropped the mmc
support from the series for the next version. I'll repost the separately
when we have an api to support it.
-Matt
^ permalink raw reply
* [PATCH v5 00/14] DMA Engine support for AM33XX
From: Matt Porter @ 2013-01-24 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8ea1d227d84648f68e670c56f27c481e@DFLE72.ent.ti.com>
On Thu, Jan 24, 2013 at 05:12:05AM +0000, Shilimkar, Santosh wrote:
> On Thursday 24 January 2013 02:19 AM, Matt Porter wrote:
> > On Wed, Jan 23, 2013 at 04:37:55PM +0530, Santosh Shilimkar wrote:
> >> Matt,
> >>
> >> On Wednesday 16 January 2013 02:02 AM, Matt Porter wrote:
> >>
> >> [..]
> >>
> >>> This series adds DMA Engine support for AM33xx, which uses
> >>> an EDMA DMAC. The EDMA DMAC has been previously supported by only
> >>> a private API implementation (much like the situation with OMAP
> >>> DMA) found on the DaVinci family of SoCs.
> >>>
> >>> The series applies on top of 3.8-rc3 and the following patches:
> >>>
> >>> - TPS65910 REGMAP_IRQ build fix:
> >>> https://patchwork.kernel.org/patch/1857701/
> >>> - dmaengine DT support from Vinod's dmaengine_dt branch in
> >>> git://git.infradead.org/users/vkoul/slave-dma.git since
> >>> 027478851791df751176398be02a3b1c5f6aa824
> >>> - edma dmaengine driver fix:
> >>> https://patchwork.kernel.org/patch/1961521/
> >>> - dmaengine dma_get_channel_caps v2:
> >>> https://patchwork.kernel.org/patch/1961601/
> >>> - dmaengine edma driver channel caps support v2:
> >>> https://patchwork.kernel.org/patch/1961591/
> >>>
> >>> The approach taken is similar to how OMAP DMA is being converted to
> >>> DMA Engine support. With the functional EDMA private API already
> >>> existing in mach-davinci/dma.c, we first move that to an ARM common
> >>> area so it can be shared. Adding DT and runtime PM support to the
> >>> private EDMA API implementation allows it to run on AM33xx. AM33xx
> >>> *only* boots using DT so we leverage Jon's generic DT DMA helpers to
> >>> register EDMA DMAC with the of_dma framework and then add support
> >>> for calling the dma_request_slave_channel() API to both the mmc
> >>> and spi drivers.
> >>>
> >>> With this series both BeagleBone and the AM335x EVM have working
> >>> MMC and SPI support.
> >>>
> >>> This is tested on BeagleBone with a SPI framebuffer driver and MMC
> >>> rootfs. A trivial gpio DMA event misc driver was used to test the
> >>> crossbar DMA event support. It is also tested on the AM335x EVM
> >>> with the onboard SPI flash and MMC rootfs. The branch at
> >>> https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v4
> >>> has the complete series, dependencies, and some test
> >>> drivers/defconfigs.
> >>>
> >>> Regression testing was done on AM180x-EVM (which also makes use
> >>> of the EDMA dmaengine driver and the EDMA private API) using SD,
> >>> SPI flash, and the onboard audio supported by the ASoC Davinci
> >>> driver. Regression testing was also done on a BeagleBoard xM
> >>> booting from the legacy board file using MMC rootfs.
> >>>
> >>> Matt Porter (14):
> >>> ARM: davinci: move private EDMA API to arm/common
> >>> ARM: edma: remove unused transfer controller handlers
> >>> ARM: edma: add AM33XX support to the private EDMA API
> >>> dmaengine: edma: enable build for AM33XX
> >>> dmaengine: edma: Add TI EDMA device tree binding
> >>> ARM: dts: add AM33XX EDMA support
> >>> dmaengine: add dma_request_slave_channel_compat()
> >>> mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
> >>> mmc: omap_hsmmc: set max_segs based on dma engine limitations
> >>> mmc: omap_hsmmc: add generic DMA request support to the DT binding
> >>> ARM: dts: add AM33XX MMC support
> >>> spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
> >>> spi: omap2-mcspi: add generic DMA request support to the DT binding
> >>> ARM: dts: add AM33XX SPI DMA support
> >>>
> >> While going through the series and testing it out, I observed an issue
> >> with MMC driver. You need patch in the end of the email to avoid the
> >> issue. Same is attached in case mailer damages it. Can you please
> >> add it with your series if you agree ?
> >
> > Yes, by inspection this makes sense. As you noticed, we've been relying
> > on the fact that DMA resources still don't come from DT, we only use our
> > DT data in conjunction with the DMA OF helpers to do channel filtering.
> > I was figuring we would address that separately later, but I see how
> > even omap4 has this issue with DMA resources named with "tx1", for
> > example. A good followup once this series is taken will be to only
> > use hwmod resources on a !populated-dt platform like we do for other
> > resources now. Baby steps. :)
> >
> We are already on it :-)
Great!
> > Thanks for the catch, I'll add this in with your tested line as well for
> > the series.
BTW, since I'm dropping mmc support from this series, I'll move your
patch into a separate series with only the mmc pieces.
-Matt
^ permalink raw reply
* [RFC PATCH 6/6] ARM: kirkwood: consolidate mv643xx_eth init for DT
From: Florian Fainelli @ 2013-01-24 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124203824.GG1758@titan.lakedaemon.net>
On Thursday 24 January 2013 15:38:24 Jason Cooper wrote:
> On Thu, Jan 24, 2013 at 09:27:24PM +0100, Florian Fainelli wrote:
> > On Thursday 24 January 2013 13:16:22 Jason Cooper wrote:
> > > > >Ian's patch appears to do so. I'll respin this series using it vice my
> > > > >lookup table.
> > > > >
> > > > Sounds good, while at it, I wonder if we could not simplify Ian's
> > > > patch to be limited to the actual Ethernet MAC driver and use
> > > > Thomas's mvdio device tree binding for the MDIO bits of mv643xx_eth.
> > > > What do you think?
> > >
> > > It sounds like you just volunteered ;-) Do you think you have the time
> > > to knock it out for v3.9?
> >
> > I do not have any kirkwood board at the moment and I really want to be able to
> > test this properly especially with the "clock must be enabled for ethernet not
> > be lost". Let me get one and I should be able to do it. Let's adopt your patch
> > for the moment, and once I have a kirkwood board I can deal with the ethernet
> > driver device tree bindings.
> >
> > Does that sound ok with you?
>
> using Ian's patch as is, I have the following in kirkwood.dtsi:
>
> +
> + smi0: mdio at 72000 {
> + compatible = "marvell,mdio-mv643xx";
> + reg = <0x72000 0x4000>;
> + interrupts = <46>;
> + status = "disabled";
> + };
> +
> + smi1: mdio at 76000 {
> + compatible = "marvell,mdio-mv643xx";
> + reg = <0x76000 0x4000>;
> + interrupts = <47>;
> + status = "disabled";
> + };
> +
> + egiga0 {
> + compatible = "marvell,mv643xx-eth";
> + reg = <0x72000 0x4000>;
> + mdio = <&smi0>;
> + port_number = <0>;
> + phy_addr = <0x80>;
> + interrupts = <11>;
> + clocks = <&gate_clk 0>;
> + status = "disabled";
> + };
> +
> + egiga1 {
> + compatible = "marvell,mv643xx-eth";
> + reg = <0x76000 0x4000>;
> + mdio = <&smi1>;
> + port_number = <1>;
> + phy_addr = <0x81>;
> + interrupts = <15>;
> + clocks = <&gate_clk 19>;
> + status = "disabled";
> + };
>
> I'll see if I can get it working as is, then we can migrate to Thomas'
> mdio bindings.
>
> btw - it might be a shared smi, I haven't looked yet, and haven't
> tested...
Ok, the existing mv643xx-eth SMI code also deals with an interrupt-driven SMI
completion scheme, which is not handled yet with Thomas's mvmdio driver.
--
Florian
^ permalink raw reply
* [PATCH v2 13/16] drivers/bus: add ARM CCI support
From: saeed bishara @ 2013-01-24 21:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359008879-9015-14-git-send-email-nicolas.pitre@linaro.org>
On Thu, Jan 24, 2013 at 8:27 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> +static int cci_driver_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + int ret = 0;
> +
> + info = kzalloc(sizeof(*info), GFP_KERNEL);
devm_kzalloc and managed resources allocation can save you few code lines.
> + if (!info) {
> + dev_err(&pdev->dev, "unable to allocate mem\n");
> + return -ENOMEM;
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(&pdev->dev, "No memory resource\n");
> + ret = -EINVAL;
> + goto mem_free;
> + }
> +
> + if (!request_mem_region(res->start, resource_size(res),
> + dev_name(&pdev->dev))) {
> + dev_err(&pdev->dev, "address 0x%x in use\n", (u32) res->start);
I suggest that you use %pR or %pr (more info at Documentation/prink-formats.txt
also, request_mem_region can fail due to other reasons
> + ret = -EBUSY;
> + goto mem_free;
^ permalink raw reply
* [PATCH v2 1/3] ARM: stacktrace: harden FP stacktraces against invalid stacks
From: Laura Abbott @ 2013-01-24 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1354230027-2204-2-git-send-email-ccross@android.com>
On 11/29/2012 3:00 PM, Colin Cross wrote:
> +bool sp_addr_valid(unsigned long sp)
> +{
> + unsigned long high;
> + unsigned long offset;
> + unsigned int pfn;
> + unsigned int start_pfn;
> + unsigned int end_pfn;
> +
> + if (!IS_ALIGNED(sp, 4))
> + return false;
> +
> + offset = sp & (THREAD_SIZE - 1);
> +
> + if (offset > THREAD_START_SP)
> + return false;
> +
> + if (offset < sizeof(struct thread_info))
> + return false;
> +
> + high = STACK_MAX(sp);
> +
> + if (!virt_addr_valid(sp) || !virt_addr_valid(high))
> + return false;
> +
> + start_pfn = page_to_pfn(virt_to_page(sp));
> + end_pfn = page_to_pfn(virt_to_page(high));
> + for (pfn = start_pfn; pfn <= end_pfn; pfn++)
> + if (!pfn_valid(pfn))
> + return false;
> +
> + return true;
> +}
I get crashes on bootup with CONFIG_SPARSEMEM enabled if a stacktrace
needs to be saved before the sections are setup:
<1>[ 0.000000] Unable to handle kernel NULL pointer dereference at
virtual address 00000000
<1>[ 0.000000] pgd = c0004000
<1>[ 0.000000] [00000000] *pgd=00000000
<0>[ 0.000000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
<4>[ 0.000000] Modules linked in:
<4>[ 0.000000] CPU: 0 Not tainted
(3.4.0-ga472ec0-00007-g6479b9e-dirty #10)
<4>[ 0.000000] PC is at sp_addr_valid+0xb0/0x1bc
<4>[ 0.000000] LR is at unwind_frame+0x4c/0x5b0
...
<1>[ 0.000000] Unable to handle kernel NULL pointer dereference at
virtual address 00000000
<1>[ 0.000000] pgd = c0004000
<1>[ 0.000000] [00000000] *pgd=00000000
<0>[ 0.000000] BUG: spinlock lockup on CPU#0, swapper/0
<0>[ 0.000000] lock: die_lock+0x0/0x10, .magic: dead4ead, .owner:
swapper/0, .owner_cpu: 0
<1>[ 0.000000] Unable to handle kernel NULL pointer dereference at
virtual address 00000000
<1>[ 0.000000] pgd = c0004000
<1>[ 0.000000] [00000000] *pgd=00000000
<0>[ 0.000000] BUG: spinlock lockup on CPU#0, swapper/0
<0>[ 0.000000] lock: die_lock+0x0/0x10, .magic: dead4ead, .owner:
swapper/0, .owner_cpu: 0
[repeat several more times]
In this case, the stacktrace is being saved via a call to kmemleak_free
in free_bootmem. The sections have not yet been initialized so there is
a crash in virt_to_page when accessing the section data.
I don't see an easy workaround for this right now unless we want to
restrict sp_addr_valid until later in bootup.
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds
From: Florian Vaussard @ 2013-01-24 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51016A84.20703@ti.com>
Hi
>>
>>>> I am working on a patch for pwm-twl-led to defer using a workqueue right now.
>>>
>>> Great!
>>> The only thing I worry about is the latency we are going to get with the
>>> workqueue.
>>>
>>
>> If the latency becomes critical, we can create our own workqueue.
>
> Hrm, when we handled the led via gpio-leds it was also going through the same
> path at the end, via i2c to twl4030.
> I think the fix for this is going to be needed in the pwm core level. Just
> need to look at the gpio code to have similar handling of might_sleep interfaces.
>
You are right. But then the pwm core must provide a way to know if the
pwm access function are callable
from atomic context or not (the gpio framework provides gpio_cansleep()).
This implies a good amount of changes to the pwm framework, and
currently we are the only driver using
non-atomic access.
I will take a closer look to the complexity of this solution tomorrow.
Florian
^ 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