* [RFC PATCH 4/6] ARM: kirkwood: nsa310: convert to pinctrl
From: Jason Cooper @ 2013-01-23 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1358983578.git.jason@lakedaemon.net>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
arch/arm/boot/dts/kirkwood-nsa310.dts | 99 +++++++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/board-dt.c | 3 --
arch/arm/mach-kirkwood/board-nsa310.c | 26 ---------
arch/arm/mach-kirkwood/common.h | 6 ---
4 files changed, 99 insertions(+), 35 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-nsa310.dts b/arch/arm/boot/dts/kirkwood-nsa310.dts
index dbb3551..3a178cf 100644
--- a/arch/arm/boot/dts/kirkwood-nsa310.dts
+++ b/arch/arm/boot/dts/kirkwood-nsa310.dts
@@ -16,6 +16,105 @@
};
ocp at f1000000 {
+ pinctrl: pinctrl at 10000 {
+ pinctrl-0 = < &pmx_led_esata_green
+ &pmx_led_esata_red
+ &pmx_led_usb_green
+ &pmx_led_usb_red
+ &pmx_usb_power_off
+ &pmx_led_sys_green
+ &pmx_led_sys_red
+ &pmx_btn_reset
+ &pmx_btn_copy
+ &pmx_led_copy_green
+ &pmx_led_copy_red
+ &pmx_led_hdd_green
+ &pmx_led_hdd_red
+ &pmx_unknown
+ &pmx_btn_power
+ &pmx_pwr_off >;
+ pinctrl-names = "default";
+
+ pmx_led_esata_green: pmx-led-esata-green {
+ marvell,pins = "mpp12";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_esata_red: pmx-led-esata-red {
+ marvell,pins = "mpp13";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_usb_green: pmx-led-usb-green {
+ marvell,pins = "mpp15";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_usb_red: pmx-led-usb-red {
+ marvell,pins = "mpp16";
+ marvell,function = "gpio";
+ };
+
+ pmx_usb_power_off: pmx-usb-power-off {
+ marvell,pins = "mpp21";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_sys_green: pmx-led-sys-green {
+ marvell,pins = "mpp28";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_sys_red: pmx-led-sys-red {
+ marvell,pins = "mpp29";
+ marvell,function = "gpio";
+ };
+
+ pmx_btn_reset: pmx-btn-reset {
+ marvell,pins = "mpp36";
+ marvell,function = "gpio";
+ };
+
+ pmx_btn_copy: pmx-btn-copy {
+ marvell,pins = "mpp37";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_copy_green: pmx-led-copy-green {
+ marvell,pins = "mpp39";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_copy_red: pmx-led-copy-red {
+ marvell,pins = "mpp40";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_hdd_green: pmx-led-hdd-green {
+ marvell,pins = "mpp41";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_hdd_red: pmx-led-hdd-red {
+ marvell,pins = "mpp42";
+ marvell,function = "gpio";
+ };
+
+ pmx_unknown: pmx-unknown {
+ marvell,pins = "mpp44";
+ marvell,function = "gpio";
+ };
+
+ pmx_btn_power: pmx-btn-power {
+ marvell,pins = "mpp46";
+ marvell,function = "gpio";
+ };
+
+ pmx_pwr_off: pmx-pwr-off {
+ marvell,pins = "mpp48";
+ marvell,function = "gpio";
+ };
+ };
serial at 12000 {
clock-frequency = <200000000>;
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 8eac548..8b35157 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -141,9 +141,6 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible("usi,topkick"))
usi_topkick_init();
- if (of_machine_is_compatible("zyxel,nsa310"))
- nsa310_init();
-
of_platform_populate(NULL, kirkwood_dt_match_table, NULL, NULL);
}
diff --git a/arch/arm/mach-kirkwood/board-nsa310.c b/arch/arm/mach-kirkwood/board-nsa310.c
index 0b99533..55ade93 100644
--- a/arch/arm/mach-kirkwood/board-nsa310.c
+++ b/arch/arm/mach-kirkwood/board-nsa310.c
@@ -13,32 +13,6 @@
#include <mach/kirkwood.h>
#include <linux/of.h>
#include "common.h"
-#include "mpp.h"
-
-static unsigned int nsa310_mpp_config[] __initdata = {
- MPP12_GPIO, /* led esata green */
- MPP13_GPIO, /* led esata red */
- MPP15_GPIO, /* led usb green */
- MPP16_GPIO, /* led usb red */
- MPP21_GPIO, /* control usb power off */
- MPP28_GPIO, /* led sys green */
- MPP29_GPIO, /* led sys red */
- MPP36_GPIO, /* key reset */
- MPP37_GPIO, /* key copy */
- MPP39_GPIO, /* led copy green */
- MPP40_GPIO, /* led copy red */
- MPP41_GPIO, /* led hdd green */
- MPP42_GPIO, /* led hdd red */
- MPP44_GPIO, /* ?? */
- MPP46_GPIO, /* key power */
- MPP48_GPIO, /* control power off */
- 0
-};
-
-void __init nsa310_init(void)
-{
- kirkwood_mpp_conf(nsa310_mpp_config);
-}
static int __init nsa310_pci_init(void)
{
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index e956d02..1c42cb8 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -130,12 +130,6 @@ void ns2_init(void);
static inline void ns2_init(void) {};
#endif
-#ifdef CONFIG_MACH_NSA310_DT
-void nsa310_init(void);
-#else
-static inline void nsa310_init(void) {};
-#endif
-
#ifdef CONFIG_MACH_OPENBLOCKS_A6_DT
void openblocks_a6_init(void);
#else
--
1.8.1.1
^ permalink raw reply related
* [RFC PATCH 3/6] ARM: kirkwood: nsa310: cleanup includes and unneeded code
From: Jason Cooper @ 2013-01-23 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1358983578.git.jason@lakedaemon.net>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
arch/arm/mach-kirkwood/board-nsa310.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm/mach-kirkwood/board-nsa310.c b/arch/arm/mach-kirkwood/board-nsa310.c
index 1bd328d..0b99533 100644
--- a/arch/arm/mach-kirkwood/board-nsa310.c
+++ b/arch/arm/mach-kirkwood/board-nsa310.c
@@ -10,11 +10,8 @@
#include <linux/kernel.h>
#include <linux/init.h>
-#include <linux/i2c.h>
-
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
#include <mach/kirkwood.h>
+#include <linux/of.h>
#include "common.h"
#include "mpp.h"
@@ -40,11 +37,7 @@ static unsigned int nsa310_mpp_config[] __initdata = {
void __init nsa310_init(void)
{
- u32 dev, rev;
-
kirkwood_mpp_conf(nsa310_mpp_config);
-
- kirkwood_pcie_id(&dev, &rev);
}
static int __init nsa310_pci_init(void)
--
1.8.1.1
^ permalink raw reply related
* [RFC PATCH 2/6] ARM: kirkwood: topkick: convert to pinctrl
From: Jason Cooper @ 2013-01-23 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1358983578.git.jason@lakedaemon.net>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
arch/arm/boot/dts/kirkwood-topkick.dts | 88 ++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/board-usi_topkick.c | 42 --------------
2 files changed, 88 insertions(+), 42 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-topkick.dts b/arch/arm/boot/dts/kirkwood-topkick.dts
index 23c2ddc..d959873 100644
--- a/arch/arm/boot/dts/kirkwood-topkick.dts
+++ b/arch/arm/boot/dts/kirkwood-topkick.dts
@@ -1,6 +1,7 @@
/dts-v1/;
/include/ "kirkwood.dtsi"
+/include/ "kirkwood-6281.dtsi"
/ {
model = "Univeral Scientific Industrial Co. Topkick-1281P2";
@@ -16,6 +17,93 @@
};
ocp at f1000000 {
+ pinctrl: pinctrl at 10000 {
+ /*
+ * GPIO LED layout
+ *
+ * /-SYS_LED(2)
+ * |
+ * | /-DISK_LED
+ * | |
+ * | | /-WLAN_LED(2)
+ * | | |
+ * [SW] [*] [*] [*]
+ */
+
+ /*
+ * Switch positions
+ *
+ * /-SW_LEFT(2)
+ * |
+ * | /-SW_IDLE
+ * | |
+ * | | /-SW_RIGHT
+ * | | |
+ * PS [L] [I] [R] LEDS
+ */
+ pinctrl-0 = < &pmx_led_disk_yellow
+ &pmx_sata0_pwr_enable
+ &pmx_led_sys_red
+ &pmx_led_sys_blue
+ &pmx_led_wifi_green
+ &pmx_sw_left
+ &pmx_sw_right
+ &pmx_sw_idle
+ &pmx_sw_left2
+ &pmx_led_wifi_yellow >;
+ pinctrl-names = "default";
+
+ pmx_led_disk_yellow: pmx-led-disk-yellow {
+ marvell,pins = "mpp21";
+ marvell,function = "gpio";
+ };
+
+ pmx_sata0_pwr_enable: pmx-sata0-pwr-enable {
+ marvell,pins = "mpp36";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_sys_red: pmx-led-sys-red {
+ marvell,pins = "mpp37";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_sys_blue: pmx-led-sys-blue {
+ marvell,pins = "mpp38";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_wifi_green: pmx-led-wifi-green {
+ marvell,pins = "mpp39";
+ marvell,function = "gpio";
+ };
+
+ pmx_sw_left: pmx-sw-left {
+ marvell,pins = "mpp43";
+ marvell,function = "gpio";
+ };
+
+ pmx_sw_right: pmx-sw-right {
+ marvell,pins = "mpp44";
+ marvell,function = "gpio";
+ };
+
+ pmx_sw_idle: pmx-sw-idle {
+ marvell,pins = "mpp45";
+ marvell,function = "gpio";
+ };
+
+ pmx_sw_left2: pmx-sw-left2 {
+ marvell,pins = "mpp46";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_wifi_yellow: pmx-led-wifi-yellow {
+ marvell,pins = "mpp48";
+ marvell,function = "gpio";
+ };
+ };
+
serial at 12000 {
clock-frequency = <200000000>;
status = "ok";
diff --git a/arch/arm/mach-kirkwood/board-usi_topkick.c b/arch/arm/mach-kirkwood/board-usi_topkick.c
index 95f0711..1cc04ec 100644
--- a/arch/arm/mach-kirkwood/board-usi_topkick.c
+++ b/arch/arm/mach-kirkwood/board-usi_topkick.c
@@ -15,57 +15,15 @@
#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
#include "common.h"
-#include "mpp.h"
static struct mv643xx_eth_platform_data topkick_ge00_data = {
.phy_addr = MV643XX_ETH_PHY_ADDR(0),
};
-/*
- * GPIO LED layout
- *
- * /-SYS_LED(2)
- * |
- * | /-DISK_LED
- * | |
- * | | /-WLAN_LED(2)
- * | | |
- * [SW] [*] [*] [*]
- */
-
-/*
- * Switch positions
- *
- * /-SW_LEFT
- * |
- * | /-SW_IDLE
- * | |
- * | | /-SW_RIGHT
- * | | |
- * PS [L] [I] [R] LEDS
- */
-
-static unsigned int topkick_mpp_config[] __initdata = {
- MPP21_GPIO, /* DISK_LED (low active) - yellow */
- MPP36_GPIO, /* SATA0 power enable (high active) */
- MPP37_GPIO, /* SYS_LED2 (low active) - red */
- MPP38_GPIO, /* SYS_LED (low active) - blue */
- MPP39_GPIO, /* WLAN_LED (low active) - green */
- MPP43_GPIO, /* SW_LEFT (low active) */
- MPP44_GPIO, /* SW_RIGHT (low active) */
- MPP45_GPIO, /* SW_IDLE (low active) */
- MPP46_GPIO, /* SW_LEFT (low active) */
- MPP48_GPIO, /* WLAN_LED2 (low active) - yellow */
- 0
-};
-
void __init usi_topkick_init(void)
{
/*
* Basic setup. Needs to be called early.
*/
- kirkwood_mpp_conf(topkick_mpp_config);
-
-
kirkwood_ge00_init(&topkick_ge00_data);
}
--
1.8.1.1
^ permalink raw reply related
* [RFC PATCH 1/6] ARM: kirkwood: topkick: init mvsdio via DT
From: Jason Cooper @ 2013-01-23 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1358983578.git.jason@lakedaemon.net>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
arch/arm/boot/dts/kirkwood-topkick.dts | 7 +++++++
arch/arm/mach-kirkwood/board-usi_topkick.c | 6 ------
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-topkick.dts b/arch/arm/boot/dts/kirkwood-topkick.dts
index cd15452..23c2ddc 100644
--- a/arch/arm/boot/dts/kirkwood-topkick.dts
+++ b/arch/arm/boot/dts/kirkwood-topkick.dts
@@ -54,6 +54,13 @@
status = "okay";
nr-ports = <1>;
};
+
+ mvsdio at 90000 {
+ pinctrl-0 = <&pmx_sdio>;
+ pinctrl-names = "default";
+ status = "okay";
+ /* No CD or WP GPIOs */
+ };
};
gpio-leds {
diff --git a/arch/arm/mach-kirkwood/board-usi_topkick.c b/arch/arm/mach-kirkwood/board-usi_topkick.c
index 23d2dd1..95f0711 100644
--- a/arch/arm/mach-kirkwood/board-usi_topkick.c
+++ b/arch/arm/mach-kirkwood/board-usi_topkick.c
@@ -14,7 +14,6 @@
#include <linux/init.h>
#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
-#include <linux/platform_data/mmc-mvsdio.h>
#include "common.h"
#include "mpp.h"
@@ -22,10 +21,6 @@ static struct mv643xx_eth_platform_data topkick_ge00_data = {
.phy_addr = MV643XX_ETH_PHY_ADDR(0),
};
-static struct mvsdio_platform_data topkick_mvsdio_data = {
- /* unfortunately the CD signal has not been connected */
-};
-
/*
* GPIO LED layout
*
@@ -73,5 +68,4 @@ void __init usi_topkick_init(void)
kirkwood_ge00_init(&topkick_ge00_data);
- kirkwood_sdio_init(&topkick_mvsdio_data);
}
--
1.8.1.1
^ permalink raw reply related
* [RFC PATCH 0/6] ARM: kirkwood: cleanup DT conversion
From: Jason Cooper @ 2013-01-23 23:34 UTC (permalink / raw)
To: linux-arm-kernel
All,
This is a first cut at cleaning up mach-kirkwood/. There are a few DT
conversions (topkick -> mvsdio, pinctrl) which, once reviewed, I'll put in the
normal pull request cycle.
The others which remove board-*.c files, I'll keep updating against
mvebu/for-next, and then apply at the end of the merge window.
Please test as you are able.
thx,
Jason.
Jason Cooper (6):
ARM: kirkwood: topkick: init mvsdio via DT
ARM: kirkwood: topkick: convert to pinctrl
ARM: kirkwood: nsa310: cleanup includes and unneeded code
ARM: kirkwood: nsa310: convert to pinctrl
ARM: kirkwood: consolidate DT init of pcie
ARM: kirkwood: consolidate mv643xx_eth init for DT
arch/arm/boot/dts/kirkwood-nsa310.dts | 99 +++++++++++++++++++
arch/arm/boot/dts/kirkwood-topkick.dts | 95 ++++++++++++++++++
arch/arm/mach-kirkwood/Kconfig | 101 -------------------
arch/arm/mach-kirkwood/Makefile | 15 ---
arch/arm/mach-kirkwood/board-dnskw.c | 7 --
arch/arm/mach-kirkwood/board-dockstar.c | 32 ------
arch/arm/mach-kirkwood/board-dreamplug.c | 35 -------
arch/arm/mach-kirkwood/board-dt.c | 140 ++++++++++++++++++++-------
arch/arm/mach-kirkwood/board-goflexnet.c | 34 -------
arch/arm/mach-kirkwood/board-ib62x0.c | 29 ------
arch/arm/mach-kirkwood/board-iconnect.c | 32 ------
arch/arm/mach-kirkwood/board-lsxl.c | 36 -------
arch/arm/mach-kirkwood/board-mplcec4.c | 36 -------
arch/arm/mach-kirkwood/board-ns2.c | 34 -------
arch/arm/mach-kirkwood/board-nsa310.c | 58 -----------
arch/arm/mach-kirkwood/board-openblocks_a6.c | 26 -----
arch/arm/mach-kirkwood/board-ts219.c | 13 ---
arch/arm/mach-kirkwood/board-usi_topkick.c | 77 ---------------
arch/arm/mach-kirkwood/common.h | 69 -------------
19 files changed, 298 insertions(+), 670 deletions(-)
delete mode 100644 arch/arm/mach-kirkwood/board-dockstar.c
delete mode 100644 arch/arm/mach-kirkwood/board-dreamplug.c
delete mode 100644 arch/arm/mach-kirkwood/board-goflexnet.c
delete mode 100644 arch/arm/mach-kirkwood/board-ib62x0.c
delete mode 100644 arch/arm/mach-kirkwood/board-iconnect.c
delete mode 100644 arch/arm/mach-kirkwood/board-lsxl.c
delete mode 100644 arch/arm/mach-kirkwood/board-mplcec4.c
delete mode 100644 arch/arm/mach-kirkwood/board-ns2.c
delete mode 100644 arch/arm/mach-kirkwood/board-nsa310.c
delete mode 100644 arch/arm/mach-kirkwood/board-openblocks_a6.c
delete mode 100644 arch/arm/mach-kirkwood/board-usi_topkick.c
--
1.8.1.1
^ permalink raw reply
* [GIT PULL] psci client-side implementation for 3.9
From: Russell King - ARM Linux @ 2013-01-23 22:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123180507.GH26811@mudshark.cambridge.arm.com>
On Wed, Jan 23, 2013 at 06:05:07PM +0000, Will Deacon wrote:
> Hello again guys,
>
> Please pull my PSCI client-side implementation for 3.9. This is used by
> the mach-virt platform, for which I'll send another pull request later
> on (since there are some timer dependencies that need resolving first).
>
> As before, I'll keep this branch stable so others can base against it.
Ok, pulled all four, but I'm going to delay a day before pushing the
tree out - I'd like to let the overnight build system chew on this for
one night.
^ permalink raw reply
* [PATCH v5 07/14] dmaengine: add dma_request_slave_channel_compat()
From: Arnd Bergmann @ 2013-01-23 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358281974-8411-8-git-send-email-mporter@ti.com>
On Tuesday 15 January 2013, Matt Porter wrote:
> Adds a dma_request_slave_channel_compat() wrapper which accepts
> both the arguments from dma_request_channel() and
> dma_request_slave_channel(). Based on whether the driver is
> instantiated via DT, the appropriate channel request call will be
> made.
>
> This allows for a much cleaner migration of drivers to the
> dmaengine DT API as platforms continue to be mixed between those
> that boot using DT and those that do not.
I noticed today some drivers in linux-next that rely on this patch,
but the patch itself still missing from -next.
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -1047,6 +1047,16 @@ void dma_run_dependencies(struct dma_async_tx_descriptor *tx);
> struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
> struct dma_chan *net_dma_find_channel(void);
> #define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
> +static inline struct dma_chan
> +*dma_request_slave_channel_compat(dma_cap_mask_t mask, dma_filter_fn fn,
> + void *fn_param, struct device *dev,
> + char *name)
> +{
> + if (dev->of_node)
> + return dma_request_slave_channel(dev, name);
> + else
> + return dma_request_channel(mask, fn, fn_param);
> +}
Hmm, dma_request_channel is actually a macro that passes mask by reference,
presumably because it can get modified by the filter function. Also, there
may be cases where we do have an of_node but don't use the dma binding
yet, or where dma_request_slave_channel doesn't actually use DT information
but rather one of the other methods that Vinod was talking about adding.
I think what it should look like instead is the below.
Arnd
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index bfcdecb..b6ffd7d 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -993,6 +993,19 @@ static inline void dma_release_channel(struct dma_chan *chan)
}
#endif
+static inline struct dma_chan *__dma_request_slave_channel_compat(dma_cap_mask_t *mask,
+ dma_filter_fn fn, void *fn_param, struct device *dev,
+ char *name)
+{
+ struct dma_chan *chan;
+
+ chan = dma_request_slave_channel(dev, name);
+ if (chan)
+ return chan;
+
+ return __dma_request_channel(mask, fn, fn_param);
+}
+
/* --- DMA device --- */
int dma_async_device_register(struct dma_device *device);
@@ -1001,6 +1014,8 @@ void dma_run_dependencies(struct dma_async_tx_descriptor *tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
+#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
+ __dma_request_slave_channel_compat(&(mask), x, y, dev, name)
/* --- Helper iov-locking functions --- */
^ permalink raw reply related
* [PATCH v2 1/2] clk: divider: prepare for minimum divider
From: Mike Turquette @ 2013-01-23 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6dc1c48cac5b2646a55da3079afb72f88e40c3bc.1358937138.git.afzal@ti.com>
Quoting Afzal Mohammed (2013-01-23 03:38:52)
> Some of clocks can have a limit on minimum divider value that can be
> programmed, prepare for such a support.
>
> Add a new field min_div for the basic divider clock and a new dynamic
> clock divider registration function where minimum divider value can
> be specified. Keep behaviour of existing divider clock registration
> functions, static initialization helpers as was earlier.
>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
Hi Afzal,
I'd like to understand this a bit better. At first the need for a
minimum divider makes a lot of sense, but I want to make sure it gets
designed correctly.
My first question is whether the minimum divider you plan to use is an
actual constraint of the hardware (e.g. the clock controller ip only
lets program two bits which divide by 4, 5, 6 or 7, where 4 is the
minimum divider) or if this is a functional constraint (e.g. the clock
hardware can divide by a lower value, but you never want that since it
results in non-functional video/audio/whatever). If this is more of a
functional constraint then perhaps a new api like clk_set_min_rate makes
more sense.
Secondly, have you looked into using the rate-table option provided by
the basic divider clock? Can you explain how this is not a good fit for
your needs? Perhaps there are too many divisor values so the table
would be large?
Thanks,
Mike
^ permalink raw reply
* [PATCH v5 00/14] DMA Engine support for AM33XX
From: Matt Porter @ 2013-01-23 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123022133.GA5727@opensource.wolfsonmicro.com>
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
If I don't get confirmation from Vinod soon, I'll just take a stab at
implementing the callbacks he mentioned in that thread. Static
per-channel caps don't provide the information needed by a client driver
the uses the EDMA DMAC.
Alternatively, we can go back to the hack that looks at the edma
phandle and hardcodes the mmc SG limits to magic values, but that's just
plain ugly. I could live with it temporarily if we can't get the
dmaengine api resolved until 3.10...dunno if others can though. ;)
-Matt
^ permalink raw reply
* [PATCH v2 2/3] arm: mvebu: Enable USB controllers on Armada 370/XP boards
From: Eric Bénard @ 2013-01-23 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123190352.2d001218@skate>
Hi Thomas,
Le Wed, 23 Jan 2013 19:03:52 +0100,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> a ?crit :
> On Wed, 23 Jan 2013 14:04:42 -0300, Ezequiel Garcia wrote:
>
> > from the OpenBlocks AX3-4 board dts file, since you mentioned this
> > board uses that USB
> > port for a PCIe connector -- if I understood correctly.
>
> No. The OpenBlocks has a different USB controller that sits on the PCIe
> bus. There is nothing like a PCIe port that uses a USB port, that
> doesn't make sense.
>
I don't have a AX3-4 but it seems to have a MiniPCIe socket and
not a PCIe one.
MiniPCIe specification includes both PCIe _and_ USB2.0 signals (on pins
36&38) (and also SMBus, SIM and LEDs drivers check the following table
for details http://pinoutsguide.com/Slots/mini_pcie_pinout.shtml ) so
the possibility to have a USB port connected to the MiniPCIe on the
AX3-4 makes sense.
For example most 3G MiniPCIe boards are using the USB2.0 signals and
not the PCIe ones.
Eric
^ permalink raw reply
* [RFC PATCH v3 02/16] ARM: davinci: move private EDMA API to arm/common
From: Matt Porter @ 2013-01-23 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d631bf39a8b8474bae448d089497fe0e@DLEE74.ent.ti.com>
On Tue, Jan 22, 2013 at 03:40:06PM +0000, Sekhar Nori wrote:
> Matt,
>
> Sorry about the late reply. I noticed this mail only after I started to
> look at v5 of your series :(
Any time is fine! :)
> On 1/11/2013 5:21 AM, Matt Porter wrote:
> > On Sun, Oct 28, 2012 at 01:47:09PM +0530, Sekhar Nori wrote:
> >> On 10/18/2012 6:56 PM, Matt Porter wrote:
> >>> Move mach-davinci/dma.c to common/edma.c so it can be used
> >>> by OMAP (specifically AM33xx) as well. This just moves the
> >>> private EDMA API but does not support OMAP.
> >>>
> >>> Signed-off-by: Matt Porter <mporter@ti.com>
> >>> ---
> >>
> >>> diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
> >>> index 4c48a36..f45d591 100644
> >>> --- a/arch/arm/mach-davinci/devices.c
> >>> +++ b/arch/arm/mach-davinci/devices.c
> >>> @@ -19,9 +19,10 @@
> >>> #include <mach/irqs.h>
> >>> #include <mach/cputype.h>
> >>> #include <mach/mux.h>
> >>> -#include <mach/edma.h>
> >>> #include <linux/platform_data/mmc-davinci.h>
> >>> #include <mach/time.h>
> >>> +#include <linux/platform_data/edma.h>
> >>
> >> Can you please introduce a patch to clean this mixture of linux/ and
> >> mach/ includes?
> >
> > Yeah, are you ok with a follow on series to clean all these files? I
> > don't want to make this series longer with something not dma related
> > that's purely cleanup from the great header reorg of 2012.
>
> Okay. I agree doing this sort of change now will cause merge issues.
Ok.
>
> >
> >>> +
> >>>
> >>> #include "davinci.h"
> >>> #include "clock.h"
> >>> @@ -141,10 +142,10 @@ static struct resource mmcsd0_resources[] = {
> >>> },
> >>> /* DMA channels: RX, then TX */
> >>> {
> >>> - .start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCRXEVT),
> >>> + .start = EDMA_CTLR_CHAN(0, 26),
> >>
> >> Instead of just replacing the event #defines with plain numbers, can you
> >> introduce a mach-davinci local edma.h which can then be included in the
> >> davinci platform files which refer to edma channel numbers?
> >
> > Ok, so when I removed the old edma.h it was full of unused defines and
> > we are left with just this one. If I introduced something like that it
> > would be used in just one place here. and only for these two values.
> > How about we just add a comment?
>
> I prefer adding a local #define in this file. This will keep it
> consistent with what is done in arch/arm/mach-davinci/dm365.c for
> example. Same for the change in sound/soc/davinci/davinci-sffsdr.c
Ok, will do.
> >
> >>
> >>> diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
> >>> index 7cd56ed..153fab8 100644
> >>> --- a/arch/arm/plat-omap/Kconfig
> >>> +++ b/arch/arm/plat-omap/Kconfig
> >>> @@ -28,6 +28,7 @@ config ARCH_OMAP2PLUS
> >>> select OMAP_DM_TIMER
> >>> select PROC_DEVICETREE if PROC_FS
> >>> select SPARSE_IRQ
> >>> + select TI_PRIV_EDMA
> >>
> >> This hunk does not seem to belong to subject of this patch.
> >
> > Let me reword the subject/description. The idea of this logical
> > chunk was to put everything in place to make it build on OMAP,
> > with the expectation that the build fails without the next patch
> > in the series.
>
> But this will break bisect. With just this patch applied, omap build
> breaks. Looks like it will be more logical to merge this hunk with 3/14
> since that's when you really start using the private DMA support on OMAP
> platforms.
Ahh, yes,. thanks for pointing that out. I will address it and add your
ack. Thanks.
> This issue is a must fix IMO.
Ok.
> I am ok with the patch otherwise. With these changes done, you can add:
>
> Acked-by: Sekhar Nori <nsekhar@ti.com>
>
> Thanks,
> Sekhar
^ permalink raw reply
* [PATCH v5 00/14] DMA Engine support for AM33XX
From: Matt Porter @ 2013-01-23 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FFC48B.80902@ti.com>
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. :)
Thanks for the catch, I'll add this in with your tested line as well for
the series.
-Matt
>
> Overall the series looks good to my eyes.
> Acked-tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Regards,
> Santosh
>
> From 2dcc90b7a4b2dcdb52ddd052ca7f3e88a78e83e4 Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Date: Wed, 23 Jan 2013 16:04:32 +0530
> Subject: [PATCH] mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt
> case
>
> MMC driver probe will abort for DT case because of failed
> platform_get_resource_byname() lookup. Fix it by skipping resource
> byname lookup for device tree build.
>
> Issue is hidden because hwmod popullates the IO resources which
> helps to succeed platform_get_resource_byname() and probe.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> drivers/mmc/host/omap_hsmmc.c | 28 +++++++++++++++-------------
> 1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index f74bd69..d4655e7 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1897,21 +1897,23 @@ static int omap_hsmmc_probe(struct
> platform_device *pdev)
>
> omap_hsmmc_conf_bus_power(host);
>
> - res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
> - if (!res) {
> - dev_err(mmc_dev(host->mmc), "cannot get DMA TX channel\n");
> - ret = -ENXIO;
> - goto err_irq;
> - }
> - tx_req = res->start;
> + if (!pdev->dev.of_node) {
> + res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
> + if (!res) {
> + dev_err(mmc_dev(host->mmc), "cannot get DMA TX channel\n");
> + ret = -ENXIO;
> + goto err_irq;
> + }
> + tx_req = res->start;
>
> - res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
> - if (!res) {
> - dev_err(mmc_dev(host->mmc), "cannot get DMA RX channel\n");
> - ret = -ENXIO;
> - goto err_irq;
> + res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
> + if (!res) {
> + dev_err(mmc_dev(host->mmc), "cannot get DMA RX channel\n");
> + ret = -ENXIO;
> + goto err_irq;
> + }
> + rx_req = res->start;
> }
> - rx_req = res->start;
>
> dma_cap_zero(mask);
> dma_cap_set(DMA_SLAVE, mask);
> --
> 1.7.9.5
>
>
>
>
> >From 2dcc90b7a4b2dcdb52ddd052ca7f3e88a78e83e4 Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Date: Wed, 23 Jan 2013 16:04:32 +0530
> Subject: [PATCH] mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt
> case
>
> MMC driver probe will abort for DT case because of failed
> platform_get_resource_byname() lookup. Fix it by skipping resource
> byname lookup for device tree build.
>
> Issue is hidden because hwmod popullates the IO resources which
> helps to succeed platform_get_resource_byname() and probe.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> drivers/mmc/host/omap_hsmmc.c | 28 +++++++++++++++-------------
> 1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index f74bd69..d4655e7 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1897,21 +1897,23 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
>
> omap_hsmmc_conf_bus_power(host);
>
> - res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
> - if (!res) {
> - dev_err(mmc_dev(host->mmc), "cannot get DMA TX channel\n");
> - ret = -ENXIO;
> - goto err_irq;
> - }
> - tx_req = res->start;
> + if (!pdev->dev.of_node) {
> + res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
> + if (!res) {
> + dev_err(mmc_dev(host->mmc), "cannot get DMA TX channel\n");
> + ret = -ENXIO;
> + goto err_irq;
> + }
> + tx_req = res->start;
>
> - res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
> - if (!res) {
> - dev_err(mmc_dev(host->mmc), "cannot get DMA RX channel\n");
> - ret = -ENXIO;
> - goto err_irq;
> + res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
> + if (!res) {
> + dev_err(mmc_dev(host->mmc), "cannot get DMA RX channel\n");
> + ret = -ENXIO;
> + goto err_irq;
> + }
> + rx_req = res->start;
> }
> - rx_req = res->start;
>
> dma_cap_zero(mask);
> dma_cap_set(DMA_SLAVE, mask);
> --
> 1.7.9.5
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
^ permalink raw reply
* [PATCH V2] ARM: imx27: add a clock gate to activate SPLL clock
From: Sascha Hauer @ 2013-01-23 20:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358086501-44408-1-git-send-email-gwenhael.goavec-merou@armadeus.com>
On Sun, Jan 13, 2013 at 03:15:01PM +0100, Gwenhael Goavec-Merou wrote:
> A clock gate is mandatory to activate SPLL clock needed, at least, for usb.
>
> Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
Applied, thanks
Sascha
> ---
> V2: - Suppress patch about ehci-mxc.c.
>
> arch/arm/mach-imx/clk-imx27.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
> index 4c1d1e4..4f066d13 100644
> --- a/arch/arm/mach-imx/clk-imx27.c
> +++ b/arch/arm/mach-imx/clk-imx27.c
> @@ -62,7 +62,7 @@ static const char *clko_sel_clks[] = {
> "32k", "usb_div", "dptc",
> };
>
> -static const char *ssi_sel_clks[] = { "spll", "mpll", };
> +static const char *ssi_sel_clks[] = { "spll_gate", "mpll", };
>
> enum mx27_clks {
> dummy, ckih, ckil, mpll, spll, mpll_main2, ahb, ipg, nfc_div, per1_div,
> @@ -82,7 +82,7 @@ enum mx27_clks {
> csi_ahb_gate, brom_ahb_gate, ata_ahb_gate, wdog_ipg_gate, usb_ipg_gate,
> uart6_ipg_gate, uart5_ipg_gate, uart4_ipg_gate, uart3_ipg_gate,
> uart2_ipg_gate, uart1_ipg_gate, ckih_div1p5, fpm, mpll_osc_sel,
> - mpll_sel, clk_max
> + mpll_sel, spll_gate, clk_max
> };
>
> static struct clk *clk[clk_max];
> @@ -104,6 +104,7 @@ int __init mx27_clocks_init(unsigned long fref)
> ARRAY_SIZE(mpll_sel_clks));
> clk[mpll] = imx_clk_pllv1("mpll", "mpll_sel", CCM_MPCTL0);
> clk[spll] = imx_clk_pllv1("spll", "ckih", CCM_SPCTL0);
> + clk[spll_gate] = imx_clk_gate("spll_gate", "spll", CCM_CSCR, 1);
> clk[mpll_main2] = imx_clk_fixed_factor("mpll_main2", "mpll", 2, 3);
>
> if (mx27_revision() >= IMX_CHIP_REVISION_2_0) {
> @@ -121,7 +122,7 @@ int __init mx27_clocks_init(unsigned long fref)
> clk[per4_div] = imx_clk_divider("per4_div", "mpll_main2", CCM_PCDR1, 24, 6);
> clk[vpu_sel] = imx_clk_mux("vpu_sel", CCM_CSCR, 21, 1, vpu_sel_clks, ARRAY_SIZE(vpu_sel_clks));
> clk[vpu_div] = imx_clk_divider("vpu_div", "vpu_sel", CCM_PCDR0, 10, 6);
> - clk[usb_div] = imx_clk_divider("usb_div", "spll", CCM_CSCR, 28, 3);
> + clk[usb_div] = imx_clk_divider("usb_div", "spll_gate", CCM_CSCR, 28, 3);
> clk[cpu_sel] = imx_clk_mux("cpu_sel", CCM_CSCR, 15, 1, cpu_sel_clks, ARRAY_SIZE(cpu_sel_clks));
> clk[clko_sel] = imx_clk_mux("clko_sel", CCM_CCSR, 0, 5, clko_sel_clks, ARRAY_SIZE(clko_sel_clks));
> if (mx27_revision() >= IMX_CHIP_REVISION_2_0)
> --
> 1.7.12.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v3 1/1 net-next] net: fec: enable pause frame to improve rx prefomance for 1G network
From: Ben Hutchings @ 2013-01-23 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358391358-27977-1-git-send-email-Frank.Li@freescale.com>
On Thu, 2013-01-17 at 10:55 +0800, Frank Li wrote:
> The limition of imx6 internal bus cause fec can't achieve 1G perfomance.
> There will be many packages lost because FIFO over run.
>
> This patch enable pause frame flow control.
[...]
> --- a/drivers/net/ethernet/freescale/fec.c
> +++ b/drivers/net/ethernet/freescale/fec.c
[...]
> +static int fec_enet_set_pauseparam(struct net_device *ndev,
> + struct ethtool_pauseparam *pause)
> +{
> + struct fec_enet_private *fep = netdev_priv(ndev);
> +
> + if (pause->tx_pause != pause->rx_pause) {
> + netdev_info(ndev,
> + "hardware only support enable/disable both tx and rx");
> + return -EINVAL;
> + }
> +
> + fep->pause_flag = 0;
> +
> + /* tx pause must be same as rx pause */
> + fep->pause_flag |= pause->rx_pause ? FEC_PAUSE_FLAG_ENABLE : 0;
> + fep->pause_flag |= pause->autoneg ? FEC_PAUSE_FLAG_AUTONEG : 0;
> +
> + if (pause->rx_pause || pause->autoneg) {
> + fep->phy_dev->supported |= ADVERTISED_Pause;
> + fep->phy_dev->advertising |= ADVERTISED_Pause;
> + } else {
> + fep->phy_dev->supported &= ~ADVERTISED_Pause;
> + fep->phy_dev->advertising &= ~ADVERTISED_Pause;
> + }
[...]
Why is this changing the supported flags, i.e. device capabilities? You
need to leave those flags alone and reject an attempt to enable pause
frames on a device that doesn't support them.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH v5 04/45] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Tejun Heo @ 2013-01-23 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51003B20.2060506@linux.vnet.ibm.com>
Hello, Srivatsa.
On Thu, Jan 24, 2013 at 01:03:52AM +0530, Srivatsa S. Bhat wrote:
> Hmm.. I split it up into steps to help explain the reasoning behind
> the code sufficiently, rather than spring all of the intricacies at
> one go (which would make it very hard to write the changelog/comments
> also). The split made it easier for me to document it well in the
> changelog, because I could deal with reasonable chunks of code/complexity
> at a time. IMHO that helps people reading it for the first time to
> understand the logic easily.
I don't know. It's a judgement call I guess. I personally would much
prefer having ample documentation as comments in the source itself or
as a separate Documentation/ file as that's what most people are gonna
be looking at to figure out what's going on. Maybe just compact it a
bit and add more in-line documentation instead?
> > The only two options are either punishing writers or identifying and
> > updating all such possible deadlocks. percpu_rwsem does the former,
> > right? I don't know how feasible the latter would be.
>
> I don't think we can avoid looking into all the possible deadlocks,
> as long as we use rwlocks inside get/put_online_cpus_atomic() (assuming
> rwlocks are fair). Even with Oleg's idea of using synchronize_sched()
> at the writer, we still need to take care of locking rules, because the
> synchronize_sched() only helps avoid the memory barriers at the reader,
> and doesn't help get rid of the rwlocks themselves.
Well, percpu_rwlock don't have to use rwlock for the slow path. It
can implement its own writer starving locking scheme. It's not like
implementing slow path global rwlock logic is difficult.
> CPU 0 CPU 1
>
> read_lock(&rwlock)
>
> write_lock(&rwlock) //spins, because CPU 0
> //has acquired the lock for read
>
> read_lock(&rwlock)
> ^^^^^
> What happens here? Does CPU 0 start spinning (and hence deadlock) or will
> it continue realizing that it already holds the rwlock for read?
I don't think rwlock allows nesting write lock inside read lock.
read_lock(); write_lock() will always deadlock.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH v5 04/45] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Srivatsa S. Bhat @ 2013-01-23 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123185522.GG2373@mtj.dyndns.org>
On 01/24/2013 12:25 AM, Tejun Heo wrote:
> Hello, Srivatsa.
>
> First of all, I'm not sure whether we need to be this step-by-step
> when introducing something new. It's not like we're transforming an
> existing implementation and it doesn't seem to help understanding the
> series that much either.
>
Hmm.. I split it up into steps to help explain the reasoning behind
the code sufficiently, rather than spring all of the intricacies at
one go (which would make it very hard to write the changelog/comments
also). The split made it easier for me to document it well in the
changelog, because I could deal with reasonable chunks of code/complexity
at a time. IMHO that helps people reading it for the first time to
understand the logic easily.
> On Tue, Jan 22, 2013 at 01:03:53PM +0530, Srivatsa S. Bhat wrote:
>> Using global rwlocks as the backend for per-CPU rwlocks helps us avoid many
>> lock-ordering related problems (unlike per-cpu locks). However, global
>
> So, unfortunately, this already seems broken, right? The problem here
> seems to be that previously, say, read_lock() implied
> preempt_disable() but as this series aims to move away from it, it
> introduces the problem of locking order between such locks and the new
> contruct.
>
Not sure I got your point correctly. Are you referring to Steve's comment
that rwlocks are probably fair now (and hence not really safe when used
like this)? If yes, I haven't actually verified that yet, but yes, that
will make this hard to use, since we need to take care of locking rules.
But suppose rwlocks are unfair (as I had assumed them to be), then we
have absolutely no problems and no lock-ordering to worry about.
> The only two options are either punishing writers or identifying and
> updating all such possible deadlocks. percpu_rwsem does the former,
> right? I don't know how feasible the latter would be.
I don't think we can avoid looking into all the possible deadlocks,
as long as we use rwlocks inside get/put_online_cpus_atomic() (assuming
rwlocks are fair). Even with Oleg's idea of using synchronize_sched()
at the writer, we still need to take care of locking rules, because the
synchronize_sched() only helps avoid the memory barriers at the reader,
and doesn't help get rid of the rwlocks themselves.
So in short, I don't see how we can punish the writers and thereby somehow
avoid looking into possible deadlocks (if rwlocks are fair).
> Srivatsa,
> you've been looking at all the places which would require conversion,
> how difficult would doing the latter be?
>
The problem is that some APIs like smp_call_function() will need to use
get/put_online_cpus_atomic(). That is when the locking becomes tricky
in the subsystem which invokes these APIs with other (subsystem-specific,
internal) locks held. So we could potentially use a convention such as
"Make get/put_online_cpus_atomic() your outer-most calls, within which
you nest the other locks" to rule out all ABBA deadlock possibilities...
But we might still hit some hard-to-convert places..
BTW, Steve, fair rwlocks doesn't mean the following scenario will result
in a deadlock right?
CPU 0 CPU 1
read_lock(&rwlock)
write_lock(&rwlock) //spins, because CPU 0
//has acquired the lock for read
read_lock(&rwlock)
^^^^^
What happens here? Does CPU 0 start spinning (and hence deadlock) or will
it continue realizing that it already holds the rwlock for read?
If the above ends in a deadlock, then its next to impossible to convert
all the places safely (because the above mentioned convention will simply
fall apart).
>> +#define reader_uses_percpu_refcnt(pcpu_rwlock, cpu) \
>> + (ACCESS_ONCE(per_cpu(*((pcpu_rwlock)->reader_refcnt), cpu)))
>> +
>> +#define reader_nested_percpu(pcpu_rwlock) \
>> + (__this_cpu_read(*((pcpu_rwlock)->reader_refcnt)) > 1)
>> +
>> +#define writer_active(pcpu_rwlock) \
>> + (__this_cpu_read(*((pcpu_rwlock)->writer_signal)))
>
> Why are these in the public header file? Are they gonna be used to
> inline something?
>
No, I can put it in the .c file itself. Will do.
>> +static inline void raise_writer_signal(struct percpu_rwlock *pcpu_rwlock,
>> + unsigned int cpu)
>> +{
>> + per_cpu(*pcpu_rwlock->writer_signal, cpu) = true;
>> +}
>> +
>> +static inline void drop_writer_signal(struct percpu_rwlock *pcpu_rwlock,
>> + unsigned int cpu)
>> +{
>> + per_cpu(*pcpu_rwlock->writer_signal, cpu) = false;
>> +}
>> +
>> +static void announce_writer_active(struct percpu_rwlock *pcpu_rwlock)
>> +{
>> + unsigned int cpu;
>> +
>> + for_each_online_cpu(cpu)
>> + raise_writer_signal(pcpu_rwlock, cpu);
>> +
>> + smp_mb(); /* Paired with smp_rmb() in percpu_read_[un]lock() */
>> +}
>> +
>> +static void announce_writer_inactive(struct percpu_rwlock *pcpu_rwlock)
>> +{
>> + unsigned int cpu;
>> +
>> + drop_writer_signal(pcpu_rwlock, smp_processor_id());
>> +
>> + for_each_online_cpu(cpu)
>> + drop_writer_signal(pcpu_rwlock, cpu);
>> +
>> + smp_mb(); /* Paired with smp_rmb() in percpu_read_[un]lock() */
>> +}
>
> It could be just personal preference but I find the above one line
> wrappers more obfuscating than anything else. What's the point of
> wrapping writer_signal = true/false into a separate function? These
> simple wrappers just add layers that people have to dig through to
> figure out what's going on without adding anything of value. I'd much
> prefer collapsing these into the percpu_write_[un]lock().
>
Sure, I see your point. I'll change that.
Thanks a lot for your feedback Tejun!
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* [GIT PULL] KVM/ARM core implementation
From: Christoffer Dall @ 2013-01-23 19:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi Will,
I've prepared a stable branch for you, for-will/kvm/core, based on
your stable perf branch.
Since the last patch series, I've addressed the reviewer comments, and
rev'ed KVM_CAP_ARM_PSCI to 87, since 86 is already used by PPC in
kvm/next.
kvmtool should probably be updated acoordingly.
I rebased the VGIC and the Arch. Timers series on the stable branch
and made these available in kvm/vgic and kvm/vgic-timers,
respectively. These branches are, however, not yet stable.
Thanks,
-Christoffer
The following changes since commit 6abc749f635005be78dfcb562c2235511965db6d:
Merge branch 'for-rmk/perf' into for-rmk/virt/kvm/core (2013-01-23
17:17:52 +0000)
are available in the git repository at:
git://github.com/virtualopensystems/linux-kvm-arm.git for-will/kvm/core
for you to fetch changes up to a749474de5f0f5902f59acb5c7f4dc6b816ac788:
KVM: ARM: Add maintainer entry for KVM/ARM (2013-01-23 13:29:19 -0500)
----------------------------------------------------------------
Christoffer Dall (13):
ARM: Add page table and page defines needed by KVM
ARM: Section based HYP idmap
KVM: ARM: Initial skeleton to compile KVM support
KVM: ARM: Hypervisor initialization
KVM: ARM: Memory virtualization setup
KVM: ARM: Inject IRQs and FIQs from userspace
KVM: ARM: World-switch implementation
KVM: ARM: Emulation framework and CP15 emulation
KVM: ARM: User space API for getting/setting co-proc registers
KVM: ARM: Demux CCSIDR in the userspace API
KVM: ARM: Handle guest faults in KVM
KVM: ARM: Handle I/O aborts
KVM: ARM: Add maintainer entry for KVM/ARM
Marc Zyngier (1):
KVM: ARM: Power State Coordination Interface implementation
Rusty Russell (1):
KVM: ARM: VFP userspace interface
Documentation/virtual/kvm/api.txt | 99 ++-
MAINTAINERS | 9 +
arch/arm/Kconfig | 2 +
arch/arm/Makefile | 1 +
arch/arm/include/asm/idmap.h | 1 +
arch/arm/include/asm/kvm_arm.h | 214 ++++++
arch/arm/include/asm/kvm_asm.h | 82 +++
arch/arm/include/asm/kvm_coproc.h | 47 ++
arch/arm/include/asm/kvm_emulate.h | 72 ++
arch/arm/include/asm/kvm_host.h | 161 +++++
arch/arm/include/asm/kvm_mmio.h | 56 ++
arch/arm/include/asm/kvm_mmu.h | 50 ++
arch/arm/include/asm/kvm_psci.h | 23 +
arch/arm/include/asm/pgtable-3level-hwdef.h | 5 +
arch/arm/include/asm/pgtable-3level.h | 18 +
arch/arm/include/asm/pgtable.h | 7 +
arch/arm/include/uapi/asm/kvm.h | 164 +++++
arch/arm/kernel/asm-offsets.c | 25 +
arch/arm/kernel/vmlinux.lds.S | 6 +-
arch/arm/kvm/Kconfig | 56 ++
arch/arm/kvm/Makefile | 21 +
arch/arm/kvm/arm.c | 1015 ++++++++++++++++++++++++++
arch/arm/kvm/coproc.c | 1046 +++++++++++++++++++++++++++
arch/arm/kvm/coproc.h | 153 ++++
arch/arm/kvm/coproc_a15.c | 162 +++++
arch/arm/kvm/emulate.c | 373 ++++++++++
arch/arm/kvm/guest.c | 222 ++++++
arch/arm/kvm/init.S | 114 +++
arch/arm/kvm/interrupts.S | 478 ++++++++++++
arch/arm/kvm/interrupts_head.S | 441 +++++++++++
arch/arm/kvm/mmio.c | 153 ++++
arch/arm/kvm/mmu.c | 787 ++++++++++++++++++++
arch/arm/kvm/psci.c | 108 +++
arch/arm/kvm/reset.c | 74 ++
arch/arm/kvm/trace.h | 235 ++++++
arch/arm/mm/idmap.c | 55 +-
arch/arm/mm/mmu.c | 22 +
include/uapi/linux/kvm.h | 9 +
38 files changed, 6546 insertions(+), 20 deletions(-)
create mode 100644 arch/arm/include/asm/kvm_arm.h
create mode 100644 arch/arm/include/asm/kvm_asm.h
create mode 100644 arch/arm/include/asm/kvm_coproc.h
create mode 100644 arch/arm/include/asm/kvm_emulate.h
create mode 100644 arch/arm/include/asm/kvm_host.h
create mode 100644 arch/arm/include/asm/kvm_mmio.h
create mode 100644 arch/arm/include/asm/kvm_mmu.h
create mode 100644 arch/arm/include/asm/kvm_psci.h
create mode 100644 arch/arm/include/uapi/asm/kvm.h
create mode 100644 arch/arm/kvm/Kconfig
create mode 100644 arch/arm/kvm/Makefile
create mode 100644 arch/arm/kvm/arm.c
create mode 100644 arch/arm/kvm/coproc.c
create mode 100644 arch/arm/kvm/coproc.h
create mode 100644 arch/arm/kvm/coproc_a15.c
create mode 100644 arch/arm/kvm/emulate.c
create mode 100644 arch/arm/kvm/guest.c
create mode 100644 arch/arm/kvm/init.S
create mode 100644 arch/arm/kvm/interrupts.S
create mode 100644 arch/arm/kvm/interrupts_head.S
create mode 100644 arch/arm/kvm/mmio.c
create mode 100644 arch/arm/kvm/mmu.c
create mode 100644 arch/arm/kvm/psci.c
create mode 100644 arch/arm/kvm/reset.c
create mode 100644 arch/arm/kvm/trace.h
^ permalink raw reply
* [PATCH] ARM: dts: Add EHCI device tree node for Exynos4
From: Dongjin Kim @ 2013-01-23 19:09 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds EHCI device node for Exynos4412
Signed-off-by: Dongjin Kim <tobetter@gmail.com>
---
arch/arm/boot/dts/exynos4412.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 387aa27..0c8f23b 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -33,4 +33,10 @@
#address-cells = <1>;
#size-cells = <0>;
};
+
+ ehci at 12580000 {
+ compatible = "samsung,exynos-ehci";
+ reg = <0x12580000 0x100>;
+ interrupts = <0 70 0>;
+ };
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH v5 04/45] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Tejun Heo @ 2013-01-23 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122073347.13822.85876.stgit@srivatsabhat.in.ibm.com>
Hello, Srivatsa.
First of all, I'm not sure whether we need to be this step-by-step
when introducing something new. It's not like we're transforming an
existing implementation and it doesn't seem to help understanding the
series that much either.
On Tue, Jan 22, 2013 at 01:03:53PM +0530, Srivatsa S. Bhat wrote:
> Using global rwlocks as the backend for per-CPU rwlocks helps us avoid many
> lock-ordering related problems (unlike per-cpu locks). However, global
So, unfortunately, this already seems broken, right? The problem here
seems to be that previously, say, read_lock() implied
preempt_disable() but as this series aims to move away from it, it
introduces the problem of locking order between such locks and the new
contruct.
The only two options are either punishing writers or identifying and
updating all such possible deadlocks. percpu_rwsem does the former,
right? I don't know how feasible the latter would be. Srivatsa,
you've been looking at all the places which would require conversion,
how difficult would doing the latter be?
> +#define reader_uses_percpu_refcnt(pcpu_rwlock, cpu) \
> + (ACCESS_ONCE(per_cpu(*((pcpu_rwlock)->reader_refcnt), cpu)))
> +
> +#define reader_nested_percpu(pcpu_rwlock) \
> + (__this_cpu_read(*((pcpu_rwlock)->reader_refcnt)) > 1)
> +
> +#define writer_active(pcpu_rwlock) \
> + (__this_cpu_read(*((pcpu_rwlock)->writer_signal)))
Why are these in the public header file? Are they gonna be used to
inline something?
> +static inline void raise_writer_signal(struct percpu_rwlock *pcpu_rwlock,
> + unsigned int cpu)
> +{
> + per_cpu(*pcpu_rwlock->writer_signal, cpu) = true;
> +}
> +
> +static inline void drop_writer_signal(struct percpu_rwlock *pcpu_rwlock,
> + unsigned int cpu)
> +{
> + per_cpu(*pcpu_rwlock->writer_signal, cpu) = false;
> +}
> +
> +static void announce_writer_active(struct percpu_rwlock *pcpu_rwlock)
> +{
> + unsigned int cpu;
> +
> + for_each_online_cpu(cpu)
> + raise_writer_signal(pcpu_rwlock, cpu);
> +
> + smp_mb(); /* Paired with smp_rmb() in percpu_read_[un]lock() */
> +}
> +
> +static void announce_writer_inactive(struct percpu_rwlock *pcpu_rwlock)
> +{
> + unsigned int cpu;
> +
> + drop_writer_signal(pcpu_rwlock, smp_processor_id());
> +
> + for_each_online_cpu(cpu)
> + drop_writer_signal(pcpu_rwlock, cpu);
> +
> + smp_mb(); /* Paired with smp_rmb() in percpu_read_[un]lock() */
> +}
It could be just personal preference but I find the above one line
wrappers more obfuscating than anything else. What's the point of
wrapping writer_signal = true/false into a separate function? These
simple wrappers just add layers that people have to dig through to
figure out what's going on without adding anything of value. I'd much
prefer collapsing these into the percpu_write_[un]lock().
Thanks.
--
tejun
^ permalink raw reply
* [PATCH] omap2: twl-common: Add default power configuration
From: Matthias Brugger @ 2013-01-23 18:50 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds a generic power script configuration.
When rebooting an OMAP3530 at 125 MHz, the reboot hangs.
With the generic power script, TWL4030 will be reset
when a warm reset occures. This way the OMAP3530 does not
hang on reboot.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
---
arch/arm/mach-omap2/twl-common.c | 38 ++++++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/twl-common.h | 1 +
2 files changed, 39 insertions(+)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index e49b40b..f096beb 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -120,6 +120,41 @@ static struct twl4030_audio_data omap3_audio_pdata = {
.codec = &omap3_codec,
};
+static struct twl4030_ins wrst_seq[] __initdata = {
+ {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
+ {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wrst_script __initdata = {
+ .script = wrst_seq,
+ .size = ARRAY_SIZE(wrst_seq),
+ .flags = TWL4030_WRST_SCRIPT,
+};
+
+static struct twl4030_script *omap3_power_scripts[] __initdata = {
+ &wrst_script,
+};
+
+static struct twl4030_resconfig omap3_rconfig[] = {
+ { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
+ .type2 = -1 },
+ { .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
+ .type2 = -1 },
+ { .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
+ .type2 = -1 },
+ { 0, 0},
+};
+
+static struct twl4030_power_data omap3_power_pdata = {
+ .scripts = omap3_power_scripts,
+ .num = ARRAY_SIZE(omap3_power_scripts),
+ .resource_config = omap3_rconfig,
+};
+
static struct regulator_consumer_supply omap3_vdda_dac_supplies[] = {
REGULATOR_SUPPLY("vdda_dac", "omapdss_venc"),
};
@@ -224,6 +259,9 @@ void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
if (pdata_flags & TWL_COMMON_PDATA_AUDIO && !pmic_data->audio)
pmic_data->audio = &omap3_audio_pdata;
+ if (pdata_flags & TWL_COMMON_PDATA_POWER && !pmic_data->power)
+ pmic_data->power = &omap3_power_pdata;
+
/* Common regulator configurations */
if (regulators_flags & TWL_COMMON_REGULATOR_VDAC && !pmic_data->vdac)
pmic_data->vdac = &omap3_vdac_idata;
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index dcfbad5..dbeb905 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -7,6 +7,7 @@
#define TWL_COMMON_PDATA_BCI (1 << 1)
#define TWL_COMMON_PDATA_MADC (1 << 2)
#define TWL_COMMON_PDATA_AUDIO (1 << 3)
+#define TWL_COMMON_PDATA_POWER (1 << 4)
/* Common LDO regulators for TWL4030/TWL6030 */
#define TWL_COMMON_REGULATOR_VDAC (1 << 0)
--
1.7.11.7
^ permalink raw reply related
* [PATCH 3/6 v14] gpio: Add userland device interface to block GPIO
From: Roland Stigge @ 2013-01-23 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122180349.068f2c6a@lwn.net>
On 23/01/13 02:03, Jonathan Corbet wrote:
> On Tue, 22 Jan 2013 13:06:41 +0100
> Roland Stigge <stigge@antcom.de> wrote:
>
>> This patch adds a character device interface to the block GPIO system.
>
> So I was looking at this, and a couple of things caught my eye...
Good points you mentioned. Will address them on a subsequent update.
Thanks,
Roland
^ permalink raw reply
* [PATCH v3 1/2] mtd: Add a common JEDEC flash device table
From: Tony Prisk @ 2013-01-23 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FFA692.2060907@parrot.com>
On Wed, 2013-01-23 at 10:00 +0100, Matthieu CASTET wrote:
> Tony Prisk a ?crit :
> > This patch adds a common JEDEC flash device table which can be
> > expanded on as more features are required.
> >
> > A simple match function is also included to query the table for
> > a match based on the JEDEC id.
>
> Why don't you use id from include/linux/mtd/cfi.h that is used by flash driver
> like drivers/mtd/devices/m25p80.c ?
>
Thanks - have changed for v4.
Regards
Tony P
^ permalink raw reply
* [PATCH 4/4] irqchip: gic: Perform the gic_secondary_init() call via CPU notifier
From: Stephen Warren @ 2013-01-23 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358963974-5496-5-git-send-email-catalin.marinas@arm.com>
On 01/23/2013 10:59 AM, Catalin Marinas wrote:
> All the calls to gic_secondary_init() pass 0 as the first argument.
> Since this function is called on each CPU when starting, it can be done
> in a platform-independent way via a CPU notifier registered by the GIC
> code.
Tegra part,
Acked-by: Stephen Warren <swarren@nvidia.com>
^ permalink raw reply
* [PATCH] omap2: twl-common: Add default power configuration
From: Matthias Brugger @ 2013-01-23 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABuKBeLUXMiTXotS=JJ1P-dGUr2m-_2JmrSgjDGU=49HLA3bCA@mail.gmail.com>
This patch adds a generic power script configuration.
When rebooting an OMAP3530 at 125 MHz, the reboot hangs.
With the generic power script, TWL4030 will be reset
when a warm reset occures. This way the OMAP3530 does not
hang on reboot.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
---
arch/arm/mach-omap2/twl-common.c | 41 ++++++++++++++++++++--------------------
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index d78180c..f096beb 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -121,41 +121,40 @@ static struct twl4030_audio_data omap3_audio_pdata = {
};
static struct twl4030_ins wrst_seq[] __initdata = {
- {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
- {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
- {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
- {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
- {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
+ {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
+ {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
};
static struct twl4030_script wrst_script __initdata = {
- .script = wrst_seq,
- .size = ARRAY_SIZE(wrst_seq),
- .flags = TWL4030_WRST_SCRIPT,
+ .script = wrst_seq,
+ .size = ARRAY_SIZE(wrst_seq),
+ .flags = TWL4030_WRST_SCRIPT,
};
static struct twl4030_script *omap3_power_scripts[] __initdata = {
- &wrst_script,
+ &wrst_script,
};
static struct twl4030_resconfig omap3_rconfig[] = {
- { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
- .type2 = -1 },
- { .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
- .type2 = -1 },
- { .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
- .type2 = -1 },
- { 0, 0},
+ { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
+ .type2 = -1 },
+ { .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
+ .type2 = -1 },
+ { .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
+ .type2 = -1 },
+ { 0, 0},
};
static struct twl4030_power_data omap3_power_pdata = {
- .scripts = omap3_power_scripts,
- .num = ARRAY_SIZE(omap3_power_scripts),
- .resource_config = omap3_rconfig,
+ .scripts = omap3_power_scripts,
+ .num = ARRAY_SIZE(omap3_power_scripts),
+ .resource_config = omap3_rconfig,
};
-
static struct regulator_consumer_supply omap3_vdda_dac_supplies[] = {
REGULATOR_SUPPLY("vdda_dac", "omapdss_venc"),
};
--
1.7.11.7
^ permalink raw reply related
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Andrew Lunn @ 2013-01-23 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51001BEE.9020201@web.de>
> >>
> >
> >Now (in the last hour) stable, occasionally lower numbers:
> >3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3396 3396 3396 3396 3396 3396 3396 3396 3396 3365 3396 3394 3396 3396
> >3396 3396 3373 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3396 3353 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3394 3396 3396 3396 3396 3396 3396 3396
> >
> >Before the last pool exhaustion going down:
> >3395 3395 3389 3379 3379 3374 3367 3360 3352 3343 3343 3343 3342 3336
> >3332 3324 3318 3314 3310 3307 3305 3299 3290 3283 3279 3272 3266 3265
> >3247 3247 3247 3242 3236 3236
> >
> Here I stopped vdr (and so closed all dvb_demux devices), the number
> was remaining the same 3236, even after restart of vdr (and restart
> of streaming).
So it does suggest a leak. Probably somewhere on an error path,
e.g. its lost video sync.
Andrew
^ 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