* [PATCH] RFC: leds-pwm: don't disable pwm when setting brightness to 0
From: Uwe Kleine-König @ 2012-10-24 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024095603.GH639@pengutronix.de>
This fixes disabling the LED on i.MX28. The PWM hardware delays using
the newly set pwm-config until the beginning of a new period. It's very
likely that pwm_disable is called before the current period ends. In
case the LED was on brightness=max before the LED stays on because in
the disabled PWM block the period never ends.
It's unclear if the mxs-pwm driver doesn't implement the API as expected
(i.e. it should block until the newly set config is effective) or if the
leds-pwm driver makes wrong assumptions. This patch assumes the latter.
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
Hello,
I'm not sure this is correct, but this is the workaround I'm using until
I get some feed back.
Best regards
Uwe
drivers/leds/leds-pwm.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index f2e44c7..a909f4f 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -38,13 +38,8 @@ static void led_pwm_set(struct led_classdev *led_cdev,
unsigned int max = led_dat->cdev.max_brightness;
unsigned int period = led_dat->period;
- if (brightness == 0) {
- pwm_config(led_dat->pwm, 0, period);
- pwm_disable(led_dat->pwm);
- } else {
- pwm_config(led_dat->pwm, brightness * period / max, period);
- pwm_enable(led_dat->pwm);
- }
+ pwm_config(led_dat->pwm, brightness * period / max, period);
+ pwm_enable(led_dat->pwm);
}
static int led_pwm_probe(struct platform_device *pdev)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] arm: mvebu: adding SATA support: dt binding and config update
From: Gregory CLEMENT @ 2012-10-24 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351086561-13569-1-git-send-email-gregory.clement@free-electrons.com>
From: Lior Amsalem <alior@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
arch/arm/boot/dts/armada-370-db.dts | 3 +++
arch/arm/boot/dts/armada-370-xp.dtsi | 10 ++++++++++
arch/arm/boot/dts/armada-xp-db.dts | 3 +++
arch/arm/configs/mvebu_defconfig | 7 +++++++
4 files changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 4a31b03..2a2aa75 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -34,5 +34,8 @@
clock-frequency = <200000000>;
status = "okay";
};
+ sata at d00a0000 {
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 94b4b9e..3f08233 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -69,6 +69,16 @@
compatible = "marvell,armada-addr-decoding-controller";
reg = <0xd0020000 0x258>;
};
+
+ sata at d00a0000 {
+ compatible = "marvell,orion-sata";
+ reg = <0xd00a0000 0x2400>;
+ interrupts = <55>;
+ nr-ports = <2>;
+ clocks = <&coreclk 0>;//, <&coreclk 0>;
+ status = "disabled";
+ };
+
};
};
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index b1fc728..b0db9a3 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -46,5 +46,8 @@
clock-frequency = <250000000>;
status = "okay";
};
+ sata at d00a0000 {
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 7bcf850..8ac5f3c 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -18,6 +18,13 @@ CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_VFP=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_BLK_DEV_SD=y
+CONFIG_ATA=y
+CONFIG_SATA_MV=y
+CONFIG_MD=y
+CONFIG_BLK_DEV_MD=y
+# CONFIG_MD_AUTODETECT is not set
+CONFIG_MD_RAID456=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] arm: mvebu: increase atomic coherent pool size for armada 370/XP
From: Gregory CLEMENT @ 2012-10-24 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351086561-13569-1-git-send-email-gregory.clement@free-electrons.com>
For Armada 370/XP we have the same problem that for the commit
cb01b63, so we applied the same solution: "The default 256 KiB
coherent pool may be too small for some of the Kirkwood devices, so
increase it to make sure that devices will be able to allocate their
buffers with GFP_ATOMIC flag"
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm/mach-mvebu/armada-370-xp.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 2af6ce5..cbad821 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -17,6 +17,7 @@
#include <linux/of_platform.h>
#include <linux/io.h>
#include <linux/time-armada-370-xp.h>
+#include <linux/dma-mapping.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
#include <asm/mach/time.h>
@@ -43,6 +44,16 @@ void __init armada_370_xp_timer_and_clk_init(void)
armada_370_xp_timer_init();
}
+void __init armada_370_xp_init_early(void)
+{
+ /*
+ * Some Armada 370/XP devices allocate their coherent buffers
+ * from atomic context. Increase size of atomic coherent pool
+ * to make sure such the allocations won't fail.
+ */
+ init_dma_coherent_pool_size(SZ_1M);
+}
+
struct sys_timer armada_370_xp_timer = {
.init = armada_370_xp_timer_and_clk_init,
};
@@ -61,6 +72,7 @@ static const char * const armada_370_xp_dt_board_dt_compat[] = {
DT_MACHINE_START(ARMADA_XP_DT, "Marvell Aramada 370/XP (Device Tree)")
.init_machine = armada_370_xp_dt_init,
.map_io = armada_370_xp_map_io,
+ .init_early = armada_370_xp_init_early,
.init_irq = armada_370_xp_init_irq,
.handle_irq = armada_370_xp_handle_irq,
.timer = &armada_370_xp_timer,
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/2] Adding SATA support for Armada 370/XP
From: Gregory CLEMENT @ 2012-10-24 13:49 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
this small patch set adds the SATA support for Armada 370 and Armada XP.
The evaluation boards for Armada 370 and Armada XP come with 2 SATA
ports, and when both are enable the coherent pool for DMA mapping was
too short. It was exactly the same issue that was fixed for Kirkwood
two months ago. So I used the same fix in the first patch. Later when
Kirkwood will be part of mach-mvebu, then this fix will be shared
between the 2 SoCs families.
This patch set is based on 3.7-rc2 and depends one the framework clock
support (the last version was posted last week:
http://thread.gmane.org/gmane.linux.kernel/1375701). The git branch
called mvebu-SATA-for-3.8 is also available at
https://github.com/MISL-EBU-System-SW/mainline-public.git.
Regards,
Gregory
Gregory CLEMENT (1):
arm: mvebu: increase atomic coherent pool size for armada 370/XP
Lior Amsalem (1):
arm: mvebu: adding SATA support: dt binding and config update
arch/arm/boot/dts/armada-370-db.dts | 3 +++
arch/arm/boot/dts/armada-370-xp.dtsi | 10 ++++++++++
arch/arm/boot/dts/armada-xp-db.dts | 3 +++
arch/arm/configs/mvebu_defconfig | 7 +++++++
arch/arm/mach-mvebu/armada-370-xp.c | 12 ++++++++++++
5 files changed, 35 insertions(+)
--
1.7.9.5
^ permalink raw reply
* [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
From: Grazvydas Ignotas @ 2012-10-24 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5087E3D9.6040007@ti.com>
On Wed, Oct 24, 2012 at 3:49 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> On Wednesday 24 October 2012 05:32 PM, Grazvydas Ignotas wrote:
>>
>> On Tue, Oct 23, 2012 at 9:09 PM, Kevin Hilman
>> <khilman@deeprootsystems.com> wrote:
>>>
>>> From: Kevin Hilman <khilman@ti.com>
>>>
>>> When debounce clocks are disabled, ensure that the banks
>>> dbck_enable_mask is cleared also. Otherwise, context restore on
>>> subsequent off-mode transition will restore previous value from the
>>> shadow copies (bank->context.debounce*) leading to mismatch state
>>> between driver state and hardware state.
>>
>>
>> This doesn't look right to me, aren't you effectively disabling
>> debounce forever here? _gpio_dbck_disable is called from
>> omap_gpio_runtime_suspend() and nothing will ever restore
>> dbck_enable_mask back to what it was set by _set_gpio_debounce and
>> debounce functionality is lost.
>>
> As per commit log, the issue seen with request->debounce->free()
> sequence and hence on free, debounce state needs to be cleared.
> Next gpio_set_debounce() should set the debounce mask right so
> the patch seems to be right.
>
>
>>>
>>> This was discovered when board code was doing
>>>
>>> gpio_request_one()
>>> gpio_set_debounce()
>>> gpio_free()
>>>
>>> which was leaving the GPIO debounce settings in a confused state.
>>> Then, enabling off mode causing bogus state to be restored, leaving
>>> GPIO debounce enabled which then prevented the CORE powerdomain from
>>> transitioning.
>>>
>
> But there is one more case which might break because of this patch.
> As part of idle, we might end up with below without gpio_free()
> omap2_gpio_prepare_for_idle()
> ->pm_runtime_put_sync_suspend()
> -> omap_gpio_runtime_suspend()
> ->_gpio_dbck_disable()
>
> And last call will clear the debounce mask state which will lost and
> hence the debounce clock won't be enabled on resume.
>
> I let Kevin comment whether this is the valid case or not.
That's exactly what I had in mind - we lose debounce functionality on
first runtime suspend.
--
Gra?vydas
^ permalink raw reply
* Possible regression in arm/io.h
From: Bastian Hecht @ 2012-10-24 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024130957.GB7339@mudshark.cambridge.arm.com>
2012/10/24 Will Deacon <will.deacon@arm.com>:
> On Wed, Oct 24, 2012 at 01:34:18PM +0100, Bastian Hecht wrote:
>> 2012/10/24 Will Deacon <will.deacon@arm.com>:
>> > It sounds like we need to:
>> >
>> > (a) Understand what has changed in GCC to cause this error to start
>> > cropping up.
>> >
>> > (b) Have a look at the impact of using only "Q" on the generated
>> > code (especially register usage for the address).
>> >
>>
>> Uff... I've just started to write ARM assembly and have no practical
>> experience with the inner workings of real world compilers. So this
>> time I'm afraid I was just good enough to report this. It sounds
>> interesting to hunt it, but would take ages for me at this point.
>
> Ok, I'll have a look at the impact of moving exclusively to "Q" when I get a
> chance. Which toolchain are you using?
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
For a more verbose info take a look at the bug report link.
> Will
^ permalink raw reply
* [PATCH v3 3/5] zynq: remove use of CLKDEV_LOOKUP
From: Nick Bowler @ 2012-10-24 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024003442.GD31625@beefymiracle.amer.corp.natinst.com>
On 2012-10-23 19:34 -0500, Josh Cartwright wrote:
> The Zynq support in mainline does not (yet) make use of any of the
> generic clk or clk lookup functionality. Remove what is upstream for
> now, until the out-of-tree implementation is in suitable form for
> merging.
>
> An important side effect of this patch is that it allows the building of
> a Zynq kernel without running into unresolved symbol problems:
>
> drivers/built-in.o: In function `amba_get_enable_pclk':
> clkdev.c:(.text+0x444): undefined reference to `clk_enable'
For the record, I think this was introduced by commit 56a34b03ff427
("ARM: versatile: Make plat-versatile clock optional") which forgot to
select PLAT_VERSATILE_CLOCK on Zynq. This is not all that surprising,
because the fact that Zynq "uses" PLAT_VERSATILE is secretly hidden in
the Makefile.
Nevertheless, the only feature from versatile that Zynq needed was the
clock support, so this patch should *also* delete the secret use of
plat-versatile by removing this line from arch/arm/Makefile:
plat-$(CONFIG_ARCH_ZYNQ) += versatile
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index cce4f8d..de70d99 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -946,7 +946,6 @@ config ARCH_ZYNQ
> bool "Xilinx Zynq ARM Cortex A9 Platform"
> select ARM_AMBA
> select ARM_GIC
> - select CLKDEV_LOOKUP
> select CPU_V7
> select GENERIC_CLOCKEVENTS
> select ICST
I'd prefer if we just added "select COMMON_CLK" instead of removing this
so we don't have to re-add this later, but I guess it doesn't really
matter either way.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* [PATCH v4 1/2] ARM: davinci: dm365: add support for v4l2 video display
From: Sekhar Nori @ 2012-10-24 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1344430259-23968-2-git-send-email-prabhakar.lad@ti.com>
Hi Prabhakar,
Sorry about the late feedback on this patch.
On 8/8/2012 6:20 PM, Prabhakar Lad wrote:
> From: Manjunath Hadli <manjunath.hadli@ti.com>
>
> Create platform devices for various video modules like venc,osd,
> vpbe and v4l2 driver for dm365.
>
> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
> ---
> arch/arm/mach-davinci/board-dm365-evm.c | 4 +-
> arch/arm/mach-davinci/davinci.h | 2 +-
> arch/arm/mach-davinci/dm365.c | 203 +++++++++++++++++++++++++++++--
> 3 files changed, 196 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
> index 688a9c5..ac1f20d 100644
> --- a/arch/arm/mach-davinci/board-dm365-evm.c
> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
> @@ -564,8 +564,6 @@ static struct davinci_uart_config uart_config __initdata = {
>
> static void __init dm365_evm_map_io(void)
> {
> - /* setup input configuration for VPFE input devices */
> - dm365_set_vpfe_config(&vpfe_cfg);
> dm365_init();
> }
>
> @@ -597,6 +595,8 @@ static __init void dm365_evm_init(void)
>
> davinci_setup_mmc(0, &dm365evm_mmc_config);
>
> + dm365_init_video(&vpfe_cfg, NULL);
> +
> /* maybe setup mmc1/etc ... _after_ mmc0 */
> evm_init_cpld();
>
> diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
> index 8db0fc6..94d867f 100644
> --- a/arch/arm/mach-davinci/davinci.h
> +++ b/arch/arm/mach-davinci/davinci.h
> @@ -84,7 +84,7 @@ void __init dm365_init_ks(struct davinci_ks_platform_data *pdata);
> void __init dm365_init_rtc(void);
> void dm365_init_spi0(unsigned chipselect_mask,
> const struct spi_board_info *info, unsigned len);
> -void dm365_set_vpfe_config(struct vpfe_config *cfg);
> +int __init dm365_init_video(struct vpfe_config *, struct vpbe_config *);
>
> /* DM644x function declarations */
> void __init dm644x_init(void);
> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index a50d49d..7c0cc66 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -1232,6 +1232,199 @@ static struct platform_device dm365_isif_dev = {
> },
> };
>
> +#define DM365_OSD_REG_BASE 0x01C71C00
In this file all base addresses are defined at the beginning of the
file. Please move it there. Keep the list sorted by address.
> +
> +static struct resource dm365_osd_resources[] = {
> + {
> + .start = DM365_OSD_REG_BASE,
> + .end = DM365_OSD_REG_BASE + 0x100,
> + .flags = IORESOURCE_MEM,
> + },
> +};
> +
> +static u64 dm365_video_dma_mask = DMA_BIT_MASK(32);
> +
> +static struct osd_platform_data dm365_osd_data = {
> + .vpbe_type = VPBE_VERSION_2,
> +};
The better way to handle multiple versions of IP is to define different
platform names for each variant and then pass the right name from
platform code. Have a look at 'fec_devtype' in
"drivers/net/ethernet/freescale/fec.c" to see how this is done to handle
different variants of Ethernet IP in freescale Ethernet driver.
I understand this is how the driver has defined it, but I suggest fixing
this now. Taking the above approach will also make the DT transition easier.
> +
> +static struct platform_device dm365_osd_dev = {
> + .name = VPBE_OSD_SUBDEV_NAME,
> + .id = -1,
> + .num_resources = ARRAY_SIZE(dm365_osd_resources),
> + .resource = dm365_osd_resources,
> + .dev = {
> + .dma_mask = &dm365_video_dma_mask,
> + .coherent_dma_mask = DMA_BIT_MASK(32),
> + .platform_data = &dm365_osd_data,
> + },
> +};
> +
> +#define DM365_VENC_REG_BASE 0x01C71E00
> +#define DM3XX_VDAC_CONFIG 0x01C4002C
Similar to above comment, please move this to top of the file.
> +
> +static struct resource dm365_venc_resources[] = {
> + {
> + .start = IRQ_VENCINT,
> + .end = IRQ_VENCINT,
> + .flags = IORESOURCE_IRQ,
> + },
> + /* venc registers io space */
> + {
> + .start = DM365_VENC_REG_BASE,
> + .end = DM365_VENC_REG_BASE + 0x180,
> + .flags = IORESOURCE_MEM,
> + },
> + /* vdaccfg registers io space */
> + {
> + .start = DM3XX_VDAC_CONFIG,
> + .end = DM3XX_VDAC_CONFIG + 4,
> + .flags = IORESOURCE_MEM,
> + },
> +};
> +
> +static struct resource dm365_v4l2_disp_resources[] = {
> + {
> + .start = IRQ_VENCINT,
> + .end = IRQ_VENCINT,
> + .flags = IORESOURCE_IRQ,
> + },
> + /* venc registers io space */
> + {
> + .start = DM365_VENC_REG_BASE,
> + .end = DM365_VENC_REG_BASE + 0x180,
> + .flags = IORESOURCE_MEM,
> + },
> +};
> +
> +static int dm365_vpbe_setup_pinmux(enum v4l2_mbus_pixelcode if_type,
> + int field)
> +{
> + int ret = 0;
> +
> + switch (if_type) {
> + case V4L2_MBUS_FMT_SGRBG8_1X8:
> + davinci_cfg_reg(DM365_VOUT_FIELD_G81);
> + davinci_cfg_reg(DM365_VOUT_COUTL_EN);
> + davinci_cfg_reg(DM365_VOUT_COUTH_EN);
> + break;
> + case V4L2_MBUS_FMT_YUYV10_1X20:
> + if (field)
> + davinci_cfg_reg(DM365_VOUT_FIELD);
> + else
> + davinci_cfg_reg(DM365_VOUT_FIELD_G81);
> + davinci_cfg_reg(DM365_VOUT_COUTL_EN);
> + davinci_cfg_reg(DM365_VOUT_COUTH_EN);
> + break;
> + default:
> + ret = -EINVAL;
> + }
> +
> + return ret;
> +}
> +
> +#define DM365_VPSS_VENCCLKEN_ENABLE 0x8
> +#define DM365_VPSS_DACCLKEN_ENABLE 0x10
> +#define DM365_VPSS_PLLC2SYSCLK5 0x20
These are bit definitions? Please use BIT() instead. I feel it is more
logical to add bit definitions after the actual register definition.
> +#define DM365_VPSS_CLK_CTRL_ADDR 0x44
> +
> +static int dm365_venc_setup_clock(enum vpbe_enc_timings_type type,
> + unsigned int pclock)
> +{
> + void __iomem *vpss_clkctl_reg;
> + int ret = 0;
> +
> + vpss_clkctl_reg = DAVINCI_SYSMOD_VIRT(DM365_VPSS_CLK_CTRL_ADDR);
> +
> + switch (type) {
> + case VPBE_ENC_STD:
> + vpss_enable_clock(VPSS_VENC_CLOCK_SEL, 1);
> + vpss_enable_clock(VPSS_VPBE_CLOCK, 1);
> + __raw_writel(DM365_VPSS_VENCCLKEN_ENABLE +
> + DM365_VPSS_DACCLKEN_ENABLE, vpss_clkctl_reg);
Please use readl()/writel() instead. Here and down below as well. Also,
please use logical OR for bit masks, although in this case using '+'
works as well.
> + break;
> + case VPBE_ENC_CUSTOM_TIMINGS:
> + if (pclock <= 27000000) {
> + vpss_enable_clock(VPSS_VENC_CLOCK_SEL, 1);
> + vpss_enable_clock(VPSS_VPBE_CLOCK, 1);
> + __raw_writel(DM365_VPSS_VENCCLKEN_ENABLE +
> + DM365_VPSS_DACCLKEN_ENABLE, vpss_clkctl_reg);
> + } else {
> + /* set sysclk4 to output 74.25 MHz from pll1 */
> + __raw_writel(DM365_VPSS_PLLC2SYSCLK5 +
> + DM365_VPSS_DACCLKEN_ENABLE +
> + DM365_VPSS_VENCCLKEN_ENABLE, vpss_clkctl_reg);
> + }
> + break;
> + default:
> + ret = -EINVAL;
> + }
Since you write to vpss_clkctl_reg anyway, it will be neater to actually
use a variable to store the value to be written and write the register
only once, in the end.
> + return ret;
> +}
> +
> +static struct platform_device dm365_vpbe_display = {
> + .name = "vpbe-v4l2",
> + .id = -1,
> + .num_resources = ARRAY_SIZE(dm365_v4l2_disp_resources),
> + .resource = dm365_v4l2_disp_resources,
> + .dev = {
> + .dma_mask = &dm365_video_dma_mask,
> + .coherent_dma_mask = DMA_BIT_MASK(32),
> + },
> +};
> +
> +struct venc_platform_data dm365_venc_pdata = {
> + .venc_type = VPBE_VERSION_2,
As mentioned above, such IP version passing from platform data is better
avoided.
> + .setup_pinmux = dm365_vpbe_setup_pinmux,
> + .setup_clock = dm365_venc_setup_clock,
> +};
> +
> +static struct platform_device dm365_venc_dev = {
> + .name = VPBE_VENC_SUBDEV_NAME,
> + .id = -1,
> + .num_resources = ARRAY_SIZE(dm365_venc_resources),
> + .resource = dm365_venc_resources,
> + .dev = {
> + .dma_mask = &dm365_video_dma_mask,
> + .coherent_dma_mask = DMA_BIT_MASK(32),
> + .platform_data = (void *)&dm365_venc_pdata,
> + },
> +};
> +
> +static struct platform_device dm365_vpbe_dev = {
> + .name = "vpbe_controller",
> + .id = -1,
> + .dev = {
> + .dma_mask = &dm365_video_dma_mask,
> + .coherent_dma_mask = DMA_BIT_MASK(32),
> + },
> +};
> +
> +int __init dm365_init_video(struct vpfe_config *vpfe_cfg,
> + struct vpbe_config *vpbe_cfg)
> +{
> + if (vpfe_cfg || vpbe_cfg)
> + platform_device_register(&dm365_vpss_device);
> +
> + if (vpfe_cfg) {
> + vpfe_capture_dev.dev.platform_data = vpfe_cfg;
> + platform_device_register(&dm365_isif_dev);
> + platform_device_register(&vpfe_capture_dev);
> + /* Add isif clock alias */
> + clk_add_alias("master", dm365_isif_dev.name, "vpss_master",
> + NULL);
Why add clock aliases? Why not just fix the clk_get() call to use the
right con_id (or fix the clock look-up in platform code)?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 1/1] mmc: Standardise capability type
From: Arnd Bergmann @ 2012-10-24 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351084664-30526-1-git-send-email-lee.jones@linaro.org>
On Wednesday 24 October 2012, Lee Jones wrote:
>
> There are discrepancies with regards to how MMC capabilities
> are carried throughout the subsystem. Let's standardise them
> to elevate any confusion.
>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: linux-mmc at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Why make it "unsigned long" then? I think that adds to the
confusion because it's sometimes 32 bits and sometimes 64 bits,
depending on the CPU. Since it's a bitmask, I would suggest
using u32 to make the size explicit.
Arnd
^ permalink raw reply
* [PATCH 1/1] mmc: Standardise capability type
From: Lee Jones @ 2012-10-24 13:17 UTC (permalink / raw)
To: linux-arm-kernel
There are discrepancies with regards to how MMC capabilities
are carried throughout the subsystem. Let's standardise them
to elevate any confusion.
Cc: Chris Ball <cjb@laptop.org>
Cc: linux-mmc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mmc/core/mmc.c | 2 +-
include/linux/mmc/dw_mmc.h | 4 ++--
include/linux/mmc/host.h | 2 +-
include/linux/mmc/sdhci.h | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 7cc4638..f31bf80 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -239,7 +239,7 @@ static void mmc_select_card_type(struct mmc_card *card)
{
struct mmc_host *host = card->host;
u8 card_type = card->ext_csd.raw_card_type & EXT_CSD_CARD_TYPE_MASK;
- unsigned int caps = host->caps, caps2 = host->caps2;
+ unsigned long caps = host->caps, caps2 = host->caps2;
unsigned int hs_max_dtr = 0;
if (card_type & EXT_CSD_CARD_TYPE_26)
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 7c6a113..60b71ae 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -229,8 +229,8 @@ struct dw_mci_board {
u32 quirks; /* Workaround / Quirk flags */
unsigned int bus_hz; /* Clock speed at the cclk_in pad */
- unsigned int caps; /* Capabilities */
- unsigned int caps2; /* More capabilities */
+ unsigned long caps; /* Capabilities */
+ unsigned long caps2; /* More capabilities */
/*
* Override fifo depth. If 0, autodetect it from the FIFOTH register,
* but note that this may not be reliable after a bootloader has used
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 7abb0e1..f89c968 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -241,7 +241,7 @@ struct mmc_host {
#define MMC_CAP_CMD23 (1 << 30) /* CMD23 supported. */
#define MMC_CAP_HW_RESET (1 << 31) /* Hardware reset */
- unsigned int caps2; /* More host capabilities */
+ unsigned long caps2; /* More host capabilities */
#define MMC_CAP2_BOOTPART_NOACC (1 << 0) /* Boot partition no access */
#define MMC_CAP2_CACHE_CTRL (1 << 1) /* Allow cache control */
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index fa8529a..8c20910 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -157,8 +157,8 @@ struct sdhci_host {
struct timer_list timer; /* Timer for timeouts */
- unsigned int caps; /* Alternative CAPABILITY_0 */
- unsigned int caps1; /* Alternative CAPABILITY_1 */
+ unsigned long caps; /* Alternative CAPABILITY_0 */
+ unsigned long caps1; /* Alternative CAPABILITY_1 */
unsigned int ocr_avail_sdio; /* OCR bit masks */
unsigned int ocr_avail_sd;
--
1.7.9.5
^ permalink raw reply related
* Possible regression in arm/io.h
From: Will Deacon @ 2012-10-24 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABYn4swp9JBEHgGTOkoe=tOh3Mf1dq5WYr=2xuKNpTmLX5LcFQ@mail.gmail.com>
On Wed, Oct 24, 2012 at 01:34:18PM +0100, Bastian Hecht wrote:
> 2012/10/24 Will Deacon <will.deacon@arm.com>:
> > It sounds like we need to:
> >
> > (a) Understand what has changed in GCC to cause this error to start
> > cropping up.
> >
> > (b) Have a look at the impact of using only "Q" on the generated
> > code (especially register usage for the address).
> >
>
> Uff... I've just started to write ARM assembly and have no practical
> experience with the inner workings of real world compilers. So this
> time I'm afraid I was just good enough to report this. It sounds
> interesting to hunt it, but would take ages for me at this point.
Ok, I'll have a look at the impact of moving exclusively to "Q" when I get a
chance. Which toolchain are you using?
Will
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Linus Walleij @ 2012-10-24 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023200249.GA2712@core.coreip.homeip.net>
On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> I have seen just in a few days 3 or 4 drivers having exactly the same
> change - call to devm_pinctrl_get_select_default(), and I guess I will
> receive the same patches for the rest of input drivers shortly.
> This suggests that the operation is done at the wrong level. Do the
> pin configuration as you parse DT data, the same way you set up i2c
> devices registers in of_i2c.c, and leave the individual drivers that do
> not care about specifics alone.
Exactly this can be done with pinctrl hogs.
The problem with that is that it removes the cross-reference
between the device and it's pinctrl handle (also from the device
tree). Instead the pinctrl handle gets referenced to the pin controller
itself. So from a modelling perpective this looks a bit ugly.
So we have two kinds of ugly:
- Sprinke devm_pinctrl_get_select_default() over all drivers
which makes pinctrl handles properly reference their devices
- Use hogs and loose coupling between pinctrl handles and their
devices
A third alternative as outlined is to use notifiers and some
resource core in drivers/base/*
>> That's why it is named "get_select_default" and not "get" only.
>> This API ensure that the pin will be set to the default state, and this
>> is all we need to do during the probe.
>
> Why during the probe and not by default? Realistically, the driver will
> be loaded as long as there is a matching device and pins will need to be
> configured.
Hogs will do it by default but will disassociate the pinctrl from its
device as described.
>> There is no point to change the mux if the driver is not probed, because
>> potentially the pin can be use be another driver.
>
> What other driver would use it? Who would chose what driver to load?
I don't know about this specific driver, but for the SKE
keypad driver we have a runtime case switching around the
pins.
We recently patched the pinctrl core for a specific usecase like
this, and in that case both drivers are loaded, but one will be
disabled at runtime and the other become active.
In the ux500, if you need to perform deep debugging on a running
system (an ordinary cell phone, say) you can at runtime convert
the SD card output into an STM trace port and start monitoring
different messages coming out on a MIPI-type bus.
So basically it is not an SD card slot anymore, it turns into
something else, the silicon core for MMC/SD is decoupled from its
pins, and they are re-routed to the STM tracer. And you plug
a special piece of hardware into the SD-card slot and it
has a USB cord or something collection standard MIPI
traces.
We have the same for the SKE keypad actually. We can shunt
the STM tracing signals out on this as well, you "just" unmount
the physical keypad and start using the lines on the PCB as
a trace collecting mechanism.
Thus we need - at runtime, in systems produced in the the
millions, it's not "just for fun" - to recouple pins from one IP
block to another and turn it into a totally different thing.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
From: Santosh Shilimkar @ 2012-10-24 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANOLnOOUHJg5W9VbHhnK8ta+Bys_oMpSz9M5jQ0xCeOB1gxtdg@mail.gmail.com>
On Wednesday 24 October 2012 05:32 PM, Grazvydas Ignotas wrote:
> On Tue, Oct 23, 2012 at 9:09 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> From: Kevin Hilman <khilman@ti.com>
>>
>> When debounce clocks are disabled, ensure that the banks
>> dbck_enable_mask is cleared also. Otherwise, context restore on
>> subsequent off-mode transition will restore previous value from the
>> shadow copies (bank->context.debounce*) leading to mismatch state
>> between driver state and hardware state.
>
> This doesn't look right to me, aren't you effectively disabling
> debounce forever here? _gpio_dbck_disable is called from
> omap_gpio_runtime_suspend() and nothing will ever restore
> dbck_enable_mask back to what it was set by _set_gpio_debounce and
> debounce functionality is lost.
>
As per commit log, the issue seen with request->debounce->free()
sequence and hence on free, debounce state needs to be cleared.
Next gpio_set_debounce() should set the debounce mask right so
the patch seems to be right.
>>
>> This was discovered when board code was doing
>>
>> gpio_request_one()
>> gpio_set_debounce()
>> gpio_free()
>>
>> which was leaving the GPIO debounce settings in a confused state.
>> Then, enabling off mode causing bogus state to be restored, leaving
>> GPIO debounce enabled which then prevented the CORE powerdomain from
>> transitioning.
>>
But there is one more case which might break because of this patch.
As part of idle, we might end up with below without gpio_free()
omap2_gpio_prepare_for_idle()
->pm_runtime_put_sync_suspend()
-> omap_gpio_runtime_suspend()
->_gpio_dbck_disable()
And last call will clear the debounce mask state which will lost and
hence the debounce clock won't be enabled on resume.
I let Kevin comment whether this is the valid case or not.
Regards
Santosh
^ permalink raw reply
* [PATCH v2 2/2] ARM: topdown mmap support
From: Rob Herring @ 2012-10-24 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMj5Bkg9Ht4YG9TL4yQfT5y5Fea4ywLDANoO2NTnGJZatN2RLQ@mail.gmail.com>
On 10/24/2012 07:22 AM, zhangfei gao wrote:
> On Fri, Nov 18, 2011 at 5:47 AM, Rob Herring <robherring2@gmail.com> wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> Similar to other architectures, this adds topdown mmap support in user
>> process address space allocation policy. This allows mmap sizes greater
>> than 2GB. This support is largely copied from MIPS and the generic
>> implementations.
>>
>> The address space randomization is moved into arch_pick_mmap_layout.
>>
>> Tested on V-Express with ubuntu and a mmap test from here:
>> https://bugs.launchpad.net/bugs/861296
>>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> Acked-by: Nicolas Pitre <nico@linaro.org>
>
> Unfortunately, we met "no vspace available" during loading libmono.so,
> when using default arch_get_unmapped_area_topdown method, tested on
> Jelly Bean with 3.4 kernel.
> While no problem using arch_get_unmapped_area in the patch, or just
> revert this patch.
> The result is some application can not run.
>
> Just google, find same issue reported on Jelly Bean with 3.4 kernel.
>
> Any suggestion?
Perhaps Android has hardcoded expectations about the virtual memory
layout? I was worried about that at the time and asked the Linaro
Android folks to test it.
I believe either layout can be selected at runtime per process. I don't
recall the exact /proc file to control this.
Rob
^ permalink raw reply
* Possible regression in arm/io.h
From: Bastian Hecht @ 2012-10-24 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024105223.GC23775@mudshark.cambridge.arm.com>
2012/10/24 Will Deacon <will.deacon@arm.com>:
> On Wed, Oct 24, 2012 at 11:38:14AM +0100, Bastian Hecht wrote:
>> Hello Will,
>
> Hello,
>
>> your introduction of the "+Qo" in arch/arm/include/asm/io.h makes some
>> drivers fail to compile on newer gnu ARM gccs. Like in
>> drivers/mtd/nand/docg4.c there is an offset of 0x800 from a pointer
>> used to address I/O memory. This leads to the error message:
>>
>> /tmp/ccwLMdCy.s: Error: bad immediate value for 8-bit offset (2048)
>
> Urgh.
xD
>> The gnu gcc people tracked it down to the asm directive "+Qo". Do we
>> really want to enforce to allow only addresses that are offsetable
>> with one byte? If I understand it correctly from the gnu gcc docs, the
>> "o" is doing this.
>>
>> excerpt from asm/io.h:
>> static inline void __raw_writew(u16 val, volatile void __iomem *addr)
>> {
>> asm volatile("strh %1, %0"
>> : "+Qo" (*(volatile u16 __force *)addr)
>> : "r" (val));
>> }
>>
>> Bug report:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54983
>>
>> So do we want to remove the "o" from all __raw_readX and __raw_writeX
>> functions? I've tried it and stuff compiles again without errors.
>
> I was under the impression that specifying multiple constraints would mean
> that it would try "o", then if that didn't work it would fall back to "Q".
> That's certainly the behaviour we've seen in the past... has this changed
> with recent toolchains?
>
> The problem with using "Q" on its own is that the compiler tends to generate
> the address computation twice: once for "Q" and once for "r" -- this doesn't
> happen with "o", where the address is computed once. This leads to an
> increase in register pressure and I have seen the compiler choke claiming
> that the inline asm block contains "impossible constraints" because it
> insists on generating the address twice.
>
> It sounds like we need to:
>
> (a) Understand what has changed in GCC to cause this error to start
> cropping up.
>
> (b) Have a look at the impact of using only "Q" on the generated
> code (especially register usage for the address).
>
> Will
Uff... I've just started to write ARM assembly and have no practical
experience with the inner workings of real world compilers. So this
time I'm afraid I was just good enough to report this. It sounds
interesting to hunt it, but would take ages for me at this point.
cheers,
Bastian
^ permalink raw reply
* [PATCH v3] ARM: davinci: dm365 evm: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS
From: Prabhakar Lad @ 2012-10-24 12:30 UTC (permalink / raw)
To: linux-arm-kernel
From: Lad, Prabhakar <prabhakar.lad@ti.com>
This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
out.
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
---
This patch is based on the following patch series,
ARM: davinci: dm365 EVM: add support for VPBE display
(https://patchwork.kernel.org/patch/1295071/)
Changes for v3:
1: Changed the commit header appropriately as pointed by
Sekhar and Sergei.
Changes for v2:
1: Fixed code alignment as pointed by Sergei.
arch/arm/mach-davinci/board-dm365-evm.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index 2924d61..8519d2d 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -514,7 +514,7 @@ static struct vpbe_output dm365evm_vpbe_outputs[] = {
.index = 1,
.name = "Component",
.type = V4L2_OUTPUT_TYPE_ANALOG,
- .capabilities = V4L2_OUT_CAP_CUSTOM_TIMINGS,
+ .capabilities = V4L2_OUT_CAP_DV_TIMINGS,
},
.subdev_name = VPBE_VENC_SUBDEV_NAME,
.default_mode = "480p59_94",
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support
From: Thomas Petazzoni @ 2012-10-24 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351065841-18654-3-git-send-email-gregory.clement@free-electrons.com>
Hello,
On Wed, 24 Oct 2012 10:04:01 +0200, Gregory CLEMENT wrote:
> Armada 370 and XP come with an unit called coherency fabric. This unit
> allows to use the Armada XP as a nearly coherent architecture. The
the Armada 370/XP
> coherency mechanism uses snoop filters to ensure the coherency between
> caches, DRAM and devices. This mechanism needs a synchronization
> barrier which guarantees that all memory write initiated by the
write -> writes
> devices has reached their target and do not reside in intermediate
has -> have
> write buffers. That's why the architecture is not totally coherent and
> we need to provide our own functions for some DMA operations.
>
> Beside the use of the coherency fabric, the device units will have to
> set the attribute flag to select the accurate coherency process for
the attribute flag of what?
> the memory transaction. This is done each device driver programs the
> DRAM address windows. The value of the attribute set by the driver is
> retrieved through the orion_addr_map_cfg struct filled during the
> early initialization of the platform.
> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
> index 18ba60b..af22e53 100644
> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> @@ -38,7 +38,8 @@
>
> coherency-fabric at d0020200 {
> compatible = "marvell,coherency-fabric";
> - reg = <0xd0020200 0xb0>;
> + reg = <0xd0020200 0xb0>,
> + <0xd0021010 0x1c>;
> };
As others mentioned, documentation update needed.
>
> soc {
> diff --git a/arch/arm/mach-mvebu/addr-map.c b/arch/arm/mach-mvebu/addr-map.c
> index fe454a4..595f6b7 100644
> --- a/arch/arm/mach-mvebu/addr-map.c
> +++ b/arch/arm/mach-mvebu/addr-map.c
> @@ -108,6 +108,9 @@ static int __init armada_setup_cpu_mbus(void)
>
> addr_map_cfg.bridge_virt_base = mbus_unit_addr_decoding_base;
>
> + if (of_find_compatible_node(NULL, NULL, "marvell,coherency-fabric"))
> + addr_map_cfg.hw_io_coherency = 1;
> +
I don't really like to have this of_find_compatible_node(NULL, NULL,
"marvell,coherency-fabric") test in two places, but I don't see a way
around it since armada_setup_cpu_mbus() is called as an initcall, so we
can't pass arguments to it.
> +struct dma_map_ops armada_xp_dma_ops;
static
> +static inline void armada_xp_sync_io_barrier(void)
> +{
> + writel(0x1, coherency_cpu_base + IO_SYNC_BARRIER_CTL_OFFSET);
> + while (readl(coherency_cpu_base + IO_SYNC_BARRIER_CTL_OFFSET) & 0x1);
> +}
> +
> +dma_addr_t armada_xp_dma_map_page(struct device *dev, struct page *page,
> + unsigned long offset, size_t size,
> + enum dma_data_direction dir,
> + struct dma_attrs *attrs)
> +{
> + if (dir != DMA_TO_DEVICE)
> + armada_xp_sync_io_barrier();
> + return pfn_to_dma(dev, page_to_pfn(page)) + offset;
> +}
> +
> +
> +void armada_xp_dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
> + size_t size, enum dma_data_direction dir,
> + struct dma_attrs *attrs)
> +{
> + if (dir != DMA_TO_DEVICE)
> + armada_xp_sync_io_barrier();
> +}
> +
> +void armada_xp_dma_sync(struct device *dev, dma_addr_t dma_handle,
> + size_t size, enum dma_data_direction dir)
> +{
> + if (dir != DMA_TO_DEVICE)
> + armada_xp_sync_io_barrier();
> +}
As others said, the prefix is wrong. Since the file is named coherency,
maybe just "coherency_" as the prefix? Not sure, though. Shouldn't the
file be named coherency-armada-370-xp.c, as we have done for the irq
controller file? In that case, the armada_370_xp prefix would make
sense.
> int armada_xp_get_cpu_count(void)
> {
> int reg, cnt;
static?
> @@ -74,6 +115,42 @@ int armada_370_xp_set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
> return 0;
> }
>
> +static int armada_xp_platform_notifier(struct notifier_block *nb,
> + unsigned long event, void *__dev)
> +{
> + struct device *dev = __dev;
> +
> + if (event != BUS_NOTIFY_ADD_DEVICE)
> + return NOTIFY_DONE;
> + set_dma_ops(dev, &armada_xp_dma_ops);
> +
> + return NOTIFY_OK;
> +}
> +
> +static struct notifier_block armada_xp_platform_nb = {
> + .notifier_call = armada_xp_platform_notifier,
> +};
> +
> +void __init armada_370_xp_coherency_iocache_init(void)
> +{
> + /* When the coherency fabric is available, the Armada XP and
> + * Aramada 370 are close to a coherent architecture, so we based
> + * our dma ops on the coherent one, and just changes the
> + * operations which need a arch io sync */
> + if (of_find_compatible_node(NULL, NULL, "marvell,coherency-fabric")) {
> + struct dma_map_ops *dma_ops = &armada_xp_dma_ops;
> + memcpy(dma_ops, &arm_coherent_dma_ops, sizeof(*dma_ops));
> + dma_ops->map_page = armada_xp_dma_map_page;
> + dma_ops->unmap_page = armada_xp_dma_unmap_page;
> + dma_ops->unmap_sg = arm_dma_ops.unmap_sg;
> + dma_ops->sync_single_for_cpu = armada_xp_dma_sync;
> + dma_ops->sync_single_for_device = armada_xp_dma_sync;
> + dma_ops->sync_sg_for_cpu = arm_dma_ops.sync_sg_for_cpu;
> + dma_ops->sync_sg_for_device = arm_dma_ops.sync_sg_for_device;
> + }
> + bus_register_notifier(&platform_bus_type, &armada_xp_platform_nb);
As Arnd said, I would prefer a lot to have the armada_xp_dma_ops
structure be initialized statically, even though it means that if the
arm_coherent_dma_ops structure is changed, we'll have to update here as
well. But I think it's cleaner.
Also, the bus notifier should be registered only if we have the
coherency fabric, otherwise it is anyway going to be called, setting
invalid DMA operations for all the platform devices.
So:
static dma_map_ops armada_370_xp_dma_ops = {
...
};
void __init armada_370_xp_coherency_iocache_init(void)
{
if (! of_find_compatible_node(NULL, NULL, "marvell,coherency-fabric"))
return;
bus_register_notifier(&platform_bus_type, &armada_370_xp_platform_nb);
}
> int __init armada_370_xp_coherency_init(void)
> {
> struct device_node *np;
> @@ -82,7 +159,17 @@ int __init armada_370_xp_coherency_init(void)
> if (np) {
> pr_info("Initializing Coherency fabric\n");
> coherency_base = of_iomap(np, 0);
> + coherency_cpu_base = of_iomap(np, 1);
> + }
> +#ifndef CONFIG_SMP
> + if (coherency_base) {
> + /* In UP case, cpu coherency is enabled here, in SMP case cpu
> + * coherency is enabled for each CPU by
> + * armada_xp_smp_prepare_cpus() in platsmp.c */
> + int hw_cpuid = cpu_logical_map(smp_processor_id());
> + armada_370_xp_set_cpu_coherent(hw_cpuid, 0);
> }
> +#endif
I really don't like this part of the code. First, the test is done on
"coherency_base", while armada_370_xp_coherency_iocache_init() is
checking the existence of the DT node to find if we have a coherency
fabric or not. It should be consistent.
Then, I don't see why the code patch for SMP and UP should be
different. The code in platsmp.c:armada_xp_smp_prepare_cpus() only
enables the coherency unit for the boot CPU. The other CPUs are
enabling the mechanism in the assembly code in headsmp.S. In other
words, I think you can remove the call to
armada_370_xp_set_cpu_coherent() in armada_xp_smp_prepare_cpus(), and
make the call unconditionally here in coherency.c for the boot CPU.
It seems like there is a better way to do this.
> diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
> index 86484bb..fff952e 100644
> --- a/arch/arm/mach-mvebu/common.h
> +++ b/arch/arm/mach-mvebu/common.h
> @@ -23,6 +23,8 @@ void armada_370_xp_handle_irq(struct pt_regs *regs);
>
> void armada_xp_cpu_die(unsigned int cpu);
>
> +void armada_370_xp_coherency_iocache_init(void);
> +
> int armada_370_xp_coherency_init(void);
> int armada_370_xp_pmsu_init(void);
> void armada_xp_secondary_startup(void);
Do we have a good reason for having
armada_370_xp_coherency_iocache_init() separate from
armada_370_xp_coherency_iocache_init() ? I.e, what prevents us from
registering the bus notifier directly in armada_370_xp_coherency_init()
if the coherency unit is available?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support
From: Arnd Bergmann @ 2012-10-24 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5087D6B8.10209@free-electrons.com>
On Wednesday 24 October 2012, Gregory CLEMENT wrote:
> On 10/24/2012 01:48 PM, Gregory CLEMENT wrote:
> > On 10/24/2012 01:36 PM, Arnd Bergmann wrote:
> >>
> >> I think it would be cleaner to statically define the operations in a constant
> >> structure and point directly to the functions you need. If necessary, use
> >> multiple structures.
> >
> > My problem was that these functions are not exposed, only arm_dma_op and
> > arm_coherent_dma_ops are exported.
> > Or do you think about something like this:
>
> struct dma_map_ops *dma_ops = {
> .alloc = arm_coherent_dma_ops.arm_coherent_dma_alloc,
> .free = arm_coherent_dma_ops.arm_coherent_dma_free,
> .mmap = arm_coherent_dma_ops.arm_dma_mmap,
> .get_sgtable = arm_coherent_dma_ops.arm_dma_get_sgtable,
> .map_sg = arm_coherent_dma_ops.arm_dma_map_sg,
> .set_dma_mask = arm_coherent_dma_ops.arm_dma_set_mask,
> .map_page = armada_xp_dma_map_page,
> .unmap_page = armada_xp_dma_unmap_page,
> .unmap_sg = arm_dma_ops.unmap_sg,
> .sync_single_for_cpu = armada_xp_dma_sync,
> .sync_single_for_device = armada_xp_dma_sync,
> .sync_sg_for_cpu = arm_dma_ops.sync_sg_for_cpu,
> .sync_sg_for_device = arm_dma_ops.sync_sg_for_device,
> };
No, I was thinking of making the underlying functions globally visible
and have extern declarations in a header file so you can access them
directly.
Generally speaking, when you run into a problem with common code, your
first approach should be to fix the common code before you try to work
around it.
Arnd
^ permalink raw reply
* [PATCH v2 2/2] ARM: topdown mmap support
From: zhangfei gao @ 2012-10-24 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1321566426-31184-2-git-send-email-robherring2@gmail.com>
On Fri, Nov 18, 2011 at 5:47 AM, Rob Herring <robherring2@gmail.com> wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> Similar to other architectures, this adds topdown mmap support in user
> process address space allocation policy. This allows mmap sizes greater
> than 2GB. This support is largely copied from MIPS and the generic
> implementations.
>
> The address space randomization is moved into arch_pick_mmap_layout.
>
> Tested on V-Express with ubuntu and a mmap test from here:
> https://bugs.launchpad.net/bugs/861296
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> Acked-by: Nicolas Pitre <nico@linaro.org>
Unfortunately, we met "no vspace available" during loading libmono.so,
when using default arch_get_unmapped_area_topdown method, tested on
Jelly Bean with 3.4 kernel.
While no problem using arch_get_unmapped_area in the patch, or just
revert this patch.
The result is some application can not run.
Just google, find same issue reported on Jelly Bean with 3.4 kernel.
Any suggestion?
Thanks
^ permalink raw reply
* [PATCH 2/2] ARM: plat-nomadik: Use apb_pclock in mtu driver
From: Ulf Hansson @ 2012-10-24 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351080821-18660-1-git-send-email-ulf.hansson@stericsson.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
arch/arm/plat-nomadik/timer.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/plat-nomadik/timer.c b/arch/arm/plat-nomadik/timer.c
index 9222e55..17c690d 100644
--- a/arch/arm/plat-nomadik/timer.c
+++ b/arch/arm/plat-nomadik/timer.c
@@ -177,9 +177,15 @@ void nmdk_clksrc_reset(void)
void __init nmdk_timer_init(void __iomem *base)
{
unsigned long rate;
- struct clk *clk0;
+ struct clk *clk0, *pclk0;
mtu_base = base;
+
+ pclk0 = clk_get_sys("mtu0", "apb_pclk");
+ BUG_ON(IS_ERR(pclk0));
+ BUG_ON(clk_prepare(pclk0) < 0);
+ BUG_ON(clk_enable(pclk0) < 0);
+
clk0 = clk_get_sys("mtu0", NULL);
BUG_ON(IS_ERR(clk0));
BUG_ON(clk_prepare(clk0) < 0);
--
1.7.10
^ permalink raw reply related
* [PATCH 1/2] clk: ux500: Register mtu apb_pclocks
From: Ulf Hansson @ 2012-10-24 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351080821-18660-1-git-send-email-ulf.hansson@stericsson.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/clk/ux500/u8500_clk.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/ux500/u8500_clk.c b/drivers/clk/ux500/u8500_clk.c
index 4ec6f60..8ca3227 100644
--- a/drivers/clk/ux500/u8500_clk.c
+++ b/drivers/clk/ux500/u8500_clk.c
@@ -160,12 +160,6 @@ void u8500_clk_init(void)
clk = clk_reg_prcmu_gate("uiccclk", NULL, PRCMU_UICCCLK, CLK_IS_ROOT);
clk_register_clkdev(clk, NULL, "uicc");
- /*
- * FIXME: The MTU clocks might need some kind of "parent muxed join"
- * and these have no K-clocks. For now, we ignore the missing
- * connection to the corresponding P-clocks, p6_mtu0_clk and
- * p6_mtu1_clk. Instead timclk is used which is the valid parent.
- */
clk = clk_reg_prcmu_gate("timclk", NULL, PRCMU_TIMCLK, CLK_IS_ROOT);
clk_register_clkdev(clk, NULL, "mtu0");
clk_register_clkdev(clk, NULL, "mtu1");
@@ -402,8 +396,11 @@ void u8500_clk_init(void)
clk = clk_reg_prcc_pclk("p6_pclk6", "per6clk", U8500_CLKRST6_BASE,
BIT(6), 0);
+ clk_register_clkdev(clk, "apb_pclk", "mtu0");
+
clk = clk_reg_prcc_pclk("p6_pclk7", "per6clk", U8500_CLKRST6_BASE,
BIT(7), 0);
+ clk_register_clkdev(clk, "apb_pclk", "mtu1");
/* PRCC K-clocks
*
--
1.7.10
^ permalink raw reply related
* [PATCH 0/2] clk: ux500: Make mtu driver use apb_pclock
From: Ulf Hansson @ 2012-10-24 12:13 UTC (permalink / raw)
To: linux-arm-kernel
From: Ulf Hansson <ulf.hansson@linaro.org>
The apb clock was before the "common" clock driver for ux500 was merged,
handled internally by the clock driver. Now this clock needs to be managed
from the mtu driver as a separate clock.
This patches is based in 3.7 rc2.
It is important the "ARM nomadik patch" is merged together with the
clock patch to not break boot. Therefore I suggest this series to go
through Mike Turquettes clock tree.
Ulf Hansson (2):
clk: ux500: Register mtu apb_pclocks
ARM: plat-nomadik: Use apb_pclock in mtu driver
arch/arm/plat-nomadik/timer.c | 8 +++++++-
drivers/clk/ux500/u8500_clk.c | 9 +++------
2 files changed, 10 insertions(+), 7 deletions(-)
--
1.7.10
^ permalink raw reply
* [PATCH v3 0/5] zynq subarch cleanups
From: Arnd Bergmann @ 2012-10-24 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024003218.GA31625@beefymiracle.amer.corp.natinst.com>
On Wednesday 24 October 2012, Josh Cartwright wrote:
> Things have been relatively quiet on the Zynq front lately. This patchset does
> a bit of cleanup of the Zynq subarchitecture. It was the necessary set of
> things I had to do to get a zynq target booting with the upstream qemu model.
>
> Patches 1 and 2 move zynq to use the GIC and pl310 L2 cache controller device
> tree mappings respectively.
>
> Patch 3 removes unused clock infrastructure. the plan is to rework the
> out-of-tree Xilinx generic clk support into something suitable for merging.
> What's in tree now just isn't used at all, and can be removed.
>
> Patch 4 and 5 move around the static peripheral mappings into the vmalloc area.
Looks all good to me now.
>
> I intentionally did not Cc stable on patch 5, even though you had
> suggested otherwise. I do not think it will apply cleanly to the stable
> trees independent of the other patches. Additionally, with the current
> state of zynq upstream, I'm not convinced there would be enough users to
> make it worth the effort.
Ok, fair enough.
> Additionally, I've left the SCU static mapping around, even though its
> currently unused. We'll eventually need it around (maybe in a different form)
> when SMP support is added.
Right.
John, are you going to pick up these patches and send a pull request?
Arnd
^ permalink raw reply
* [PATCH v3 5/5] zynq: move static peripheral mappings
From: Arnd Bergmann @ 2012-10-24 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024003523.GF31625@beefymiracle.amer.corp.natinst.com>
On Wednesday 24 October 2012, Josh Cartwright wrote:
> Shifting them up into the vmalloc region prevents the following warning,
> when booting a zynq qemu target with more than 512mb of RAM:
>
> BUG: mapping for 0xe0000000 at 0xe0000000 out of vmalloc space
>
> In addition, it allows for reuse of these mappings when the proper
> drivers issue requests via ioremap().
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> Cc: John Linn <john.linn@xilinx.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH v3 4/5] ARM: annotate VMALLOC_END definition with _AC
From: Arnd Bergmann @ 2012-10-24 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024003502.GE31625@beefymiracle.amer.corp.natinst.com>
On Wednesday 24 October 2012, Josh Cartwright wrote:
> This makes the definition of VMALLOC_END suitable for use within
> assembly code. This is necessary to allow the use of VMALLOC_END in
> defining where the early uart is mapped for use with DEBUG_LL.
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ 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