* [PATCH] arm: mvebu: add LED support in defconfig
From: Thomas Petazzoni @ 2012-10-23 8:19 UTC (permalink / raw)
To: linux-arm-kernel
The recently added support for the PlatHome Openblocks AX3 platform
requires the LED framework, so let's add it to mvebu_defconfig.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This is 3.8 material
---
arch/arm/configs/mvebu_defconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 3458752..b7ca617 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -26,6 +26,11 @@ CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
# CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH] arm: mvebu: support for the PlatHome OpenBlocks AX3 board
From: Thomas Petazzoni @ 2012-10-23 8:19 UTC (permalink / raw)
To: linux-arm-kernel
This platform, available in Japan from PlatHome, has a dual-core
Armada XP, the MV78260. For now, only the two serial ports and the
three front LEDs are supported. Support for network, SATA, USB and
other peripherals will be added as drivers for them become available
for Armada XP in mainline.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This is 3.8 material.
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/openblocks-ax3.dts | 69 ++++++++++++++++++++++++++++++++++
arch/arm/mach-mvebu/armada-370-xp.c | 1 +
3 files changed, 72 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/openblocks-ax3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f37cf9f..b7814b9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -44,7 +44,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
msm8960-cdp.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
- armada-xp-db.dtb
+ armada-xp-db.dtb \
+ openblocks-ax3.dtb
dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
imx53-ard.dtb \
imx53-evk.dtb \
diff --git a/arch/arm/boot/dts/openblocks-ax3.dts b/arch/arm/boot/dts/openblocks-ax3.dts
new file mode 100644
index 0000000..f757116
--- /dev/null
+++ b/arch/arm/boot/dts/openblocks-ax3.dts
@@ -0,0 +1,69 @@
+/*
+ * Device Tree file for OpenBlocks AX3 board
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "armada-xp-mv78260.dtsi"
+
+/ {
+ model = "PlatHome OpenBlocks AX3 board";
+ compatible = "plathome,openblocks-ax3", "marvell,armadaxp-mv78260", "marvell,armadaxp", "marvell,armada-370-xp";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x40000000>; /* 1 GB */
+ };
+
+ soc {
+ serial at d0012000 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+ serial at d0012100 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+ pinctrl {
+ led_pins: led-pins-0 {
+ marvell,pins = "mpp49", "mpp51", "mpp53";
+ marvell,function = "gpio";
+ };
+ };
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins>;
+
+ red_led {
+ label = "red_led";
+ gpios = <&gpio1 17 1>;
+ default-state = "off";
+ };
+
+ yellow_led {
+ label = "yellow_led";
+ gpios = <&gpio1 19 1>;
+ default-state = "off";
+ };
+
+ green_led {
+ label = "green_led";
+ gpios = <&gpio1 21 1>;
+ default-state = "off";
+ linux,default-trigger = "heartbeat";
+ };
+ };
+ };
+};
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 49d7915..cd2717b 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -49,6 +49,7 @@ static void __init armada_370_xp_dt_init(void)
static const char * const armada_370_xp_dt_board_dt_compat[] = {
"marvell,a370-db",
"marvell,axp-db",
+ "plathome,openblocks-ax3",
NULL,
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH] arm: mvebu: update defconfig with 3.7 changes
From: Thomas Petazzoni @ 2012-10-23 8:17 UTC (permalink / raw)
To: linux-arm-kernel
The split of 370 and XP into two Kconfig options and the multiplatform
kernel support has changed a few Kconfig symbols, so let's update the
mvebu_defconfig file with the latest changes.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
As this is a simple defconfig update against 3.7 changes, it should
most likely go into 3.7.
---
arch/arm/configs/mvebu_defconfig | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 7bcf850..3458752 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -1,6 +1,6 @@
CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
-CONFIG_NO_HZ=y
+CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_BLK_DEV_INITRD=y
@@ -9,10 +9,12 @@ CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_ARCH_MVEBU=y
-CONFIG_MACH_ARMADA_370_XP=y
+CONFIG_MACH_ARMADA_370=y
+CONFIG_MACH_ARMADA_XP=y
+# CONFIG_CACHE_L2X0 is not set
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
-CONFIG_USE_OF=y
+# CONFIG_COMPACTION is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
@@ -23,6 +25,8 @@ CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
+# CONFIG_USB_SUPPORT is not set
+# CONFIG_IOMMU_SUPPORT is not set
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
--
1.7.9.5
^ permalink raw reply related
* [PATCH] gpio: mvebu: correctly set the value in direction_output()
From: Thomas Petazzoni @ 2012-10-23 8:17 UTC (permalink / raw)
To: linux-arm-kernel
The ->direction_output() operation of gpio_chip is supposed to set the
direction to output but also to set the GPIO to an initial
value. Unfortunately, this last part was not done until now, causing
for example the LEDs to not be properly set to their default initial
value. This patch fixes this by calling the mvebu_gpio_set() function
from mvebu_gpio_direction_output() before configuring the GPIO as an
output GPIO.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
As this is a fix, it should most likely go into 3.7.
---
drivers/gpio/gpio-mvebu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index 7a87412..eb42ab1 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -244,6 +244,8 @@ static int mvebu_gpio_direction_output(struct gpio_chip *chip, unsigned pin,
if (ret)
return ret;
+ mvebu_gpio_set(chip, pin, value);
+
spin_lock_irqsave(&mvchip->lock, flags);
u = readl_relaxed(mvebu_gpioreg_io_conf(mvchip));
u &= ~(1 << pin);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
From: Pavan Kunapuli @ 2012-10-23 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350979047.20572.6.camel@tellur>
>> Does this work with boards where we don't have any MMC supplies? Or are we just deferring the probe indefinitely there?
The probe will be deferred indefinitely.
>> For boards that power MMC unconditionally, are we supposed to add dummy regulators to make them work with this patchset?
Yes. We need to add dummy regulators for boards that power MMC unconditionally. I am not sure if there is any other solution other than using deferred probe that would guarantee regulators availability.
-----Original Message-----
From: Lucas Stach [mailto:dev at lynxeye.de]
Sent: 23 October 2012 13:27
To: Pavan Kunapuli
Cc: swarren at wwwdotorg.org; linux at arm.linux.org.uk; cjb at laptop.org; linux-tegra at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-mmc at vger.kernel.org
Subject: Re: [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
Am Dienstag, den 23.10.2012, 12:49 +0530 schrieb Pavan Kunapuli:
> vmmc and vqmmc regulators control the voltage to the host and device.
> Defer the probe if either of them is not registered.
>
Does this work with boards where we don't have any MMC supplies? Or are we just deferring the probe indefinitely there?
For boards that power MMC unconditionally, are we supposed to add dummy regulators to make them work with this patchset?
> Signed-off-by: Pavan Kunapuli <pkunapuli@nvidia.com>
> ---
> drivers/mmc/host/sdhci.c | 25 ++++++++++++++++++++++---
> 1 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index
> 7922adb..925c403 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2844,11 +2844,17 @@ int sdhci_add_host(struct sdhci_host *host)
> !(host->mmc->caps & MMC_CAP_NONREMOVABLE))
> mmc->caps |= MMC_CAP_NEEDS_POLL;
>
> - /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
> + /*
> + * If vqmmc regulator and no 1.8V signalling, then there's no UHS.
> + * vqmmc regulator should be present. If it's not present,
> + * assume the regulator driver registration is not yet done and
> + * defer the probe.
> + */
> host->vqmmc = regulator_get(mmc_dev(mmc), "vqmmc");
> if (IS_ERR(host->vqmmc)) {
> - pr_info("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
> + pr_err("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
> host->vqmmc = NULL;
> + return -EPROBE_DEFER;
> }
> else if (regulator_is_supported_voltage(host->vqmmc, 1800000, 1800000))
> regulator_enable(host->vqmmc);
> @@ -2903,10 +2909,17 @@ int sdhci_add_host(struct sdhci_host *host)
>
> ocr_avail = 0;
>
> + /*
> + * vmmc regulator should be present. If it's not present,
> + * assume the regulator driver registration is not yet done
> + * and defer the probe.
> + */
> host->vmmc = regulator_get(mmc_dev(mmc), "vmmc");
> if (IS_ERR(host->vmmc)) {
> - pr_info("%s: no vmmc regulator found\n", mmc_hostname(mmc));
> + pr_err("%s: no vmmc regulator found\n", mmc_hostname(mmc));
> host->vmmc = NULL;
> + ret = -EPROBE_DEFER;
> + goto vmmc_err;
> } else
> regulator_enable(host->vmmc);
>
> @@ -3121,7 +3134,13 @@ reset:
> untasklet:
> tasklet_kill(&host->card_tasklet);
> tasklet_kill(&host->finish_tasklet);
> +vmmc_err:
> + if (host->vqmmc) {
> + if (regulator_is_enabled(host->vqmmc))
> + regulator_disable(host->vqmmc);
>
> + regulator_put(host->vqmmc);
> + }
> return ret;
> }
>
^ permalink raw reply
* [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
From: Tero Kristo @ 2012-10-23 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210230745160.32436@utopia.booyaka.com>
Hi Paul,
On Tue, 2012-10-23 at 07:47 +0000, Paul Walmsley wrote:
> Hi Tero,
>
> On Mon, 22 Oct 2012, Tero Kristo wrote:
>
> > When waking up from off-mode, some IP blocks are reset automatically by
> > hardware. For this reason, software must wait until the reset has
> > completed before attempting to access the IP block.
> >
> > This patch fixes for example the bug introduced by commit
> > 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c ("mmc: omap_hsmmc: remove access
> > to SYSCONFIG register"), in which the MMC IP block is reset during
> > off-mode entry, but the code expects the module to be already available
> > during the execution of context restore.
> >
> > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > Cc: Paul Walmsley <paul@pwsan.com>
> > Cc: Benoit Cousson <b-cousson@ti.com>
> > Cc: Venkatraman S <svenkatr@ti.com>
>
> What do you think about these modifications? The code is quite similar to
> what was in the _ocp_softreset() function, so just moved it into a
> function. Also moved the callsite from the end of _enable_sysc() to the
> beginning, which makes more sense to me, but would like to get your
> opinion.
Looks good to me. Only reason I pushed the reset wait to the end of the
function was a minimal potential timing optimization. As the beginning
of the function will write a register, it will consume a bit of time
(especially if in 32k domain), so it can maybe save a single register
read in the delay loop if ordered that way.
Your way is probably safer, it might cause problems in some cases if the
config is written before reset has completed (can it?)
-Tero
>
> - Paul
>
> From: Tero Kristo <t-kristo@ti.com>
> Date: Mon, 22 Oct 2012 19:15:32 +0300
> Subject: [PATCH] [RFC] ARM: OMAP: hwmod: wait for sysreset complete after
> enabling hwmod
>
> When waking up from off-mode, some IP blocks are reset automatically by
> hardware. For this reason, software must wait until the reset has
> completed before attempting to access the IP block.
>
> This patch fixes for example the bug introduced by commit
> 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c ("mmc: omap_hsmmc: remove access
> to SYSCONFIG register"), in which the MMC IP block is reset during
> off-mode entry, but the code expects the module to be already available
> during the execution of context restore.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Cc: Venkatraman S <svenkatr@ti.com>
> [paul at pwsan.com: moved softreset wait code into separate function; call
> from top of _enable_sysc() rather than the bottom]
>
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 56 ++++++++++++++++++++++++++++----------
> 1 file changed, 42 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 504e0e0..0356a09 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -423,6 +423,38 @@ static int _set_softreset(struct omap_hwmod *oh, u32 *v)
> }
>
> /**
> + * _wait_softreset_complete - wait for an OCP softreset to complete
> + * @oh: struct omap_hwmod * to wait on
> + *
> + * Wait until the IP block represented by @oh reports that its OCP
> + * softreset is complete. This can be triggered by software (see
> + * _ocp_softreset()) or by hardware upon returning from off-mode (one
> + * example is HSMMC). Waits for up to MAX_MODULE_SOFTRESET_WAIT
> + * microseconds. Returns the number of microseconds waited.
> + */
> +static int _wait_softreset_complete(struct omap_hwmod *oh)
> +{
> + struct omap_hwmod_class_sysconfig *sysc;
> + u32 softrst_mask;
> + int c = 0;
> +
> + sysc = oh->class->sysc;
> +
> + if (sysc->sysc_flags & SYSS_HAS_RESET_STATUS)
> + omap_test_timeout((omap_hwmod_read(oh, sysc->syss_offs)
> + & SYSS_RESETDONE_MASK),
> + MAX_MODULE_SOFTRESET_WAIT, c);
> + else if (sysc->sysc_flags & SYSC_HAS_RESET_STATUS) {
> + softrst_mask = (0x1 << sysc->sysc_fields->srst_shift);
> + omap_test_timeout(!(omap_hwmod_read(oh, sysc->sysc_offs)
> + & softrst_mask),
> + MAX_MODULE_SOFTRESET_WAIT, c);
> + }
> +
> + return c;
> +}
> +
> +/**
> * _set_dmadisable: set OCP_SYSCONFIG.DMADISABLE bit in @v
> * @oh: struct omap_hwmod *
> *
> @@ -1283,6 +1315,14 @@ static void _enable_sysc(struct omap_hwmod *oh)
> if (!oh->class->sysc)
> return;
>
> + /*
> + * Wait until reset has completed, this is needed as the IP
> + * block is reset automatically by hardware in some cases
> + * (off-mode for example), and the drivers require the
> + * IP to be ready when they access it
> + */
> + _wait_softreset_complete(oh);
> +
> v = oh->_sysc_cache;
> sf = oh->class->sysc->sysc_flags;
>
> @@ -1805,7 +1845,7 @@ static int _am33xx_disable_module(struct omap_hwmod *oh)
> */
> static int _ocp_softreset(struct omap_hwmod *oh)
> {
> - u32 v, softrst_mask;
> + u32 v;
> int c = 0;
> int ret = 0;
>
> @@ -1835,19 +1875,7 @@ static int _ocp_softreset(struct omap_hwmod *oh)
> if (oh->class->sysc->srst_udelay)
> udelay(oh->class->sysc->srst_udelay);
>
> - if (oh->class->sysc->sysc_flags & SYSS_HAS_RESET_STATUS)
> - omap_test_timeout((omap_hwmod_read(oh,
> - oh->class->sysc->syss_offs)
> - & SYSS_RESETDONE_MASK),
> - MAX_MODULE_SOFTRESET_WAIT, c);
> - else if (oh->class->sysc->sysc_flags & SYSC_HAS_RESET_STATUS) {
> - softrst_mask = (0x1 << oh->class->sysc->sysc_fields->srst_shift);
> - omap_test_timeout(!(omap_hwmod_read(oh,
> - oh->class->sysc->sysc_offs)
> - & softrst_mask),
> - MAX_MODULE_SOFTRESET_WAIT, c);
> - }
> -
> + c = _wait_softreset_complete(oh);
> if (c == MAX_MODULE_SOFTRESET_WAIT)
> pr_warning("omap_hwmod: %s: softreset failed (waited %d usec)\n",
> oh->name, MAX_MODULE_SOFTRESET_WAIT);
^ permalink raw reply
* [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
From: Lucas Stach @ 2012-10-23 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350976740-19284-3-git-send-email-pkunapuli@nvidia.com>
Am Dienstag, den 23.10.2012, 12:49 +0530 schrieb Pavan Kunapuli:
> vmmc and vqmmc regulators control the voltage to
> the host and device. Defer the probe if either of
> them is not registered.
>
Does this work with boards where we don't have any MMC supplies? Or are
we just deferring the probe indefinitely there?
For boards that power MMC unconditionally, are we supposed to add dummy
regulators to make them work with this patchset?
> Signed-off-by: Pavan Kunapuli <pkunapuli@nvidia.com>
> ---
> drivers/mmc/host/sdhci.c | 25 ++++++++++++++++++++++---
> 1 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 7922adb..925c403 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2844,11 +2844,17 @@ int sdhci_add_host(struct sdhci_host *host)
> !(host->mmc->caps & MMC_CAP_NONREMOVABLE))
> mmc->caps |= MMC_CAP_NEEDS_POLL;
>
> - /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
> + /*
> + * If vqmmc regulator and no 1.8V signalling, then there's no UHS.
> + * vqmmc regulator should be present. If it's not present,
> + * assume the regulator driver registration is not yet done and
> + * defer the probe.
> + */
> host->vqmmc = regulator_get(mmc_dev(mmc), "vqmmc");
> if (IS_ERR(host->vqmmc)) {
> - pr_info("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
> + pr_err("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
> host->vqmmc = NULL;
> + return -EPROBE_DEFER;
> }
> else if (regulator_is_supported_voltage(host->vqmmc, 1800000, 1800000))
> regulator_enable(host->vqmmc);
> @@ -2903,10 +2909,17 @@ int sdhci_add_host(struct sdhci_host *host)
>
> ocr_avail = 0;
>
> + /*
> + * vmmc regulator should be present. If it's not present,
> + * assume the regulator driver registration is not yet done
> + * and defer the probe.
> + */
> host->vmmc = regulator_get(mmc_dev(mmc), "vmmc");
> if (IS_ERR(host->vmmc)) {
> - pr_info("%s: no vmmc regulator found\n", mmc_hostname(mmc));
> + pr_err("%s: no vmmc regulator found\n", mmc_hostname(mmc));
> host->vmmc = NULL;
> + ret = -EPROBE_DEFER;
> + goto vmmc_err;
> } else
> regulator_enable(host->vmmc);
>
> @@ -3121,7 +3134,13 @@ reset:
> untasklet:
> tasklet_kill(&host->card_tasklet);
> tasklet_kill(&host->finish_tasklet);
> +vmmc_err:
> + if (host->vqmmc) {
> + if (regulator_is_enabled(host->vqmmc))
> + regulator_disable(host->vqmmc);
>
> + regulator_put(host->vqmmc);
> + }
> return ret;
> }
>
^ permalink raw reply
* [PATCH] pinctrl/nomadik: use zero as default irq_start
From: Linus Walleij @ 2012-10-23 7:53 UTC (permalink / raw)
To: linux-arm-kernel
From: Linus Walleij <linus.walleij@linaro.org>
The irqdomain semantics were supposed to be such that a linear
domain would be used if the passed first_irq was zero or
negative, but I got it wrong so only passing zero as first_irq
will work properly. Well, zero is NO_IRQ these days so let's
pass zero. The semantics of irqdomain_add_simple() will be
fixed in a separate patch.
Cc: Lee Jones <lee.jones@linaro.org>
Reported-by: Rikard Olsson <rikard.p.olsson@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/pinctrl-nomadik.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-nomadik.c b/drivers/pinctrl/pinctrl-nomadik.c
index d1d3cb9..3834629 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -1281,7 +1281,7 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev)
struct clk *clk;
int secondary_irq;
void __iomem *base;
- int irq_start = -1;
+ int irq_start = 0;
int irq;
int ret;
--
1.7.11.3
^ permalink raw reply related
* [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
From: Paul Walmsley @ 2012-10-23 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350922532-26338-1-git-send-email-t-kristo@ti.com>
Hi Tero,
On Mon, 22 Oct 2012, Tero Kristo wrote:
> When waking up from off-mode, some IP blocks are reset automatically by
> hardware. For this reason, software must wait until the reset has
> completed before attempting to access the IP block.
>
> This patch fixes for example the bug introduced by commit
> 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c ("mmc: omap_hsmmc: remove access
> to SYSCONFIG register"), in which the MMC IP block is reset during
> off-mode entry, but the code expects the module to be already available
> during the execution of context restore.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Cc: Venkatraman S <svenkatr@ti.com>
What do you think about these modifications? The code is quite similar to
what was in the _ocp_softreset() function, so just moved it into a
function. Also moved the callsite from the end of _enable_sysc() to the
beginning, which makes more sense to me, but would like to get your
opinion.
- Paul
From: Tero Kristo <t-kristo@ti.com>
Date: Mon, 22 Oct 2012 19:15:32 +0300
Subject: [PATCH] [RFC] ARM: OMAP: hwmod: wait for sysreset complete after
enabling hwmod
When waking up from off-mode, some IP blocks are reset automatically by
hardware. For this reason, software must wait until the reset has
completed before attempting to access the IP block.
This patch fixes for example the bug introduced by commit
6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c ("mmc: omap_hsmmc: remove access
to SYSCONFIG register"), in which the MMC IP block is reset during
off-mode entry, but the code expects the module to be already available
during the execution of context restore.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Venkatraman S <svenkatr@ti.com>
[paul at pwsan.com: moved softreset wait code into separate function; call
from top of _enable_sysc() rather than the bottom]
---
arch/arm/mach-omap2/omap_hwmod.c | 56 ++++++++++++++++++++++++++++----------
1 file changed, 42 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 504e0e0..0356a09 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -423,6 +423,38 @@ static int _set_softreset(struct omap_hwmod *oh, u32 *v)
}
/**
+ * _wait_softreset_complete - wait for an OCP softreset to complete
+ * @oh: struct omap_hwmod * to wait on
+ *
+ * Wait until the IP block represented by @oh reports that its OCP
+ * softreset is complete. This can be triggered by software (see
+ * _ocp_softreset()) or by hardware upon returning from off-mode (one
+ * example is HSMMC). Waits for up to MAX_MODULE_SOFTRESET_WAIT
+ * microseconds. Returns the number of microseconds waited.
+ */
+static int _wait_softreset_complete(struct omap_hwmod *oh)
+{
+ struct omap_hwmod_class_sysconfig *sysc;
+ u32 softrst_mask;
+ int c = 0;
+
+ sysc = oh->class->sysc;
+
+ if (sysc->sysc_flags & SYSS_HAS_RESET_STATUS)
+ omap_test_timeout((omap_hwmod_read(oh, sysc->syss_offs)
+ & SYSS_RESETDONE_MASK),
+ MAX_MODULE_SOFTRESET_WAIT, c);
+ else if (sysc->sysc_flags & SYSC_HAS_RESET_STATUS) {
+ softrst_mask = (0x1 << sysc->sysc_fields->srst_shift);
+ omap_test_timeout(!(omap_hwmod_read(oh, sysc->sysc_offs)
+ & softrst_mask),
+ MAX_MODULE_SOFTRESET_WAIT, c);
+ }
+
+ return c;
+}
+
+/**
* _set_dmadisable: set OCP_SYSCONFIG.DMADISABLE bit in @v
* @oh: struct omap_hwmod *
*
@@ -1283,6 +1315,14 @@ static void _enable_sysc(struct omap_hwmod *oh)
if (!oh->class->sysc)
return;
+ /*
+ * Wait until reset has completed, this is needed as the IP
+ * block is reset automatically by hardware in some cases
+ * (off-mode for example), and the drivers require the
+ * IP to be ready when they access it
+ */
+ _wait_softreset_complete(oh);
+
v = oh->_sysc_cache;
sf = oh->class->sysc->sysc_flags;
@@ -1805,7 +1845,7 @@ static int _am33xx_disable_module(struct omap_hwmod *oh)
*/
static int _ocp_softreset(struct omap_hwmod *oh)
{
- u32 v, softrst_mask;
+ u32 v;
int c = 0;
int ret = 0;
@@ -1835,19 +1875,7 @@ static int _ocp_softreset(struct omap_hwmod *oh)
if (oh->class->sysc->srst_udelay)
udelay(oh->class->sysc->srst_udelay);
- if (oh->class->sysc->sysc_flags & SYSS_HAS_RESET_STATUS)
- omap_test_timeout((omap_hwmod_read(oh,
- oh->class->sysc->syss_offs)
- & SYSS_RESETDONE_MASK),
- MAX_MODULE_SOFTRESET_WAIT, c);
- else if (oh->class->sysc->sysc_flags & SYSC_HAS_RESET_STATUS) {
- softrst_mask = (0x1 << oh->class->sysc->sysc_fields->srst_shift);
- omap_test_timeout(!(omap_hwmod_read(oh,
- oh->class->sysc->sysc_offs)
- & softrst_mask),
- MAX_MODULE_SOFTRESET_WAIT, c);
- }
-
+ c = _wait_softreset_complete(oh);
if (c == MAX_MODULE_SOFTRESET_WAIT)
pr_warning("omap_hwmod: %s: softreset failed (waited %d usec)\n",
oh->name, MAX_MODULE_SOFTRESET_WAIT);
--
1.7.10.4
^ permalink raw reply related
* [PATCH] ARM: imx: select HAVE_IMX_SRC when SMP is enabled
From: Shawn Guo @ 2012-10-23 7:39 UTC (permalink / raw)
To: linux-arm-kernel
With being part of multi-platform support, SMP can be enabled by other
platform even when SOC_IMX6Q is deselected. It leads to a situation
that arch/arm/mach-imx/platsmp.c is built without HAVE_IMX_SRC selection
which will cause build error. For example, the following link errors
will be seen when building imx5 with other v7 platforms.
arch/arm/mach-imx/built-in.o: In function `imx_cpu_die':
platform-ahci-imx.c:(.text+0x219c): undefined reference to `imx_enable_cpu'
arch/arm/mach-imx/built-in.o: In function `imx_boot_secondary':
platform-ahci-imx.c:(.cpuinit.text+0x14): undefined reference to `imx_set_cpu_jump'
platform-ahci-imx.c:(.cpuinit.text+0x20): undefined reference to `imx_enable_cpu'
Select HAVE_IMX_SRC as long as SMP is enabled to fix the problem.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
arch/arm/mach-imx/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 8c75bae..4f73866 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -72,7 +72,7 @@ config HAVE_IMX_MMDC
bool
config HAVE_IMX_SRC
- bool
+ def_bool y if SMP
config IMX_HAVE_IOMUX_V1
bool
@@ -839,7 +839,6 @@ config SOC_IMX6Q
select HAVE_CAN_FLEXCAN if CAN
select HAVE_IMX_GPC
select HAVE_IMX_MMDC
- select HAVE_IMX_SRC
select HAVE_SMP
select MFD_SYSCON
select PINCTRL
--
1.7.9.5
^ permalink raw reply related
* Deferring sdhci probe if regulators are not found
From: Pavan Kunapuli @ 2012-10-23 7:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Tegra sdhci platform driver currently enables the necessary gpios which will power on the SD host and sd/emmc cards. I have made changes to use vmmc and vqmmc regulators for the same.
During testing on some platforms, I observed that the there is a possibility of regulator driver probe being deferred due to dependencies on other modules like gpio etc. In such case, the vmmc and vqmmc regulators will not be available. MMC/SD cards will not work without enabling the regulators. To fix this, I am deferring sdhci probe if regulator_get() calls fail. The probe will continue when the regulators are present. With this change, mmc and SD cards are working properly.
However, this patch would require vmmc, vqmmc supplies to be registered either with a valid entry or a using dummy regulator entry for all platforms that use sdhci driver. I am aware of tegra platforms details and can add entries for the same. I don't know the details of other platforms which are using sdhci driver. I can try adding regulator_get() calls in the sdhci tegra platform driver and bypass the regulator_get calls in sdhci driver if the regulator structures are already present. This wouldn't effect non-tegra platforms. But, this is more of a hack and not a proper solution. I need suggestions on how to fix the issue properly without affecting other platforms. I have pushed patches with the above mentioned changes. I hope it helps in understanding better on what I am trying to do.
Regards,
Pavan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/e913f343/attachment-0001.html>
^ permalink raw reply
* [PATCH] Boottime: A tool for automatic measurement of kernel/bootloader boot time
From: Lee Jones @ 2012-10-23 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507C3125.70702@ti.com>
I have a few answers for you.
> >>>>>>root at ME:/ cat /sys/kernel/debug/boottime/bootgraph
> >>>>>>[ 0.185254] calling splash+0x0/0x0
> >>>>>>[ 2.984335] initcall splash+0x0/0x0 returned 0 after 2799 msecs.
> >>>>>>[ 2.984335] calling autoboot_delay+0x0/0x0
> >>>>>>[ 4.089513] initcall autoboot_delay+0x0/0x0 returned 0 after 1105 msecs.
> >>>>>>[ 4.089513] calling load_kernel+0x0/0x0
> >>>>>>[ 4.239174] initcall load_kernel+0x0/0x0 returned 0 after 149 msecs.
> >>>>>>[ 4.239174] calling boot_kernel+0x0/0x0
> >>>>>>[ 4.276260] initcall boot_kernel+0x0/0x0 returned 0 after 37 msecs.
> >>>>>>[ 4.276260] calling uncompress_ll_init+0x0/0x0
> >>>>>>[ 4.276260] initcall uncompress_ll_init+0x0/0x0 returned 0 after 0 msecs.
> >>>>>>[ 4.276260] Freeing init memory: 0K
> OK So has this been validated and tested on any other IC then a ST part?
No, it has not. As I believe I mentioned before, this is a tool
written for and used by ST-Ericsson. Extending it to use on other
platforms sounds like a great idea, but won't be done by
ST-Ericsson due to a lack of hardware and software assets.
> This boottime_activate patch seems to be only for the dbx500. If
> this is supposed to be a generic solution I would expect
> a generic patch for ARM to enable boot time activation.
Apparently a generic boottime extention would be fairly trivial
with the use of ktime_get().
> Have you profiled how much time the boot time logging has added to
> the over all boot?
This has not been completed, but the original author suspects
it would be <100ms.
> Also the boottime commit message should explain a little more what
> it is measuring.
> i.e. This patch enables logging the boot time from point x to point
> y for the kernel only. This does not include init.
> What about adding the boot time from the init sequence to init complete?
This sounds like a good idea, but again won't be extended upon by
us.
It appears that this driver is interesting and possibly very
useful for quite a lot of people out there. This patch should
therefore be seen as the foundations for other to then extend
in the ways alluded to above and ported to work on other more
generic platforms. I think these should be extra patches on
top of the one submitted here.
>From a personal perspective, I am happy to change a few bits
and pieces, but I don't have the time to satisfy all of the
suggestions made, or adapt the driver in any substantial
manor.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
From: Pavan Kunapuli @ 2012-10-23 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350976740-19284-1-git-send-email-pkunapuli@nvidia.com>
vmmc and vqmmc regulators control the voltage to
the host and device. Defer the probe if either of
them is not registered.
Signed-off-by: Pavan Kunapuli <pkunapuli@nvidia.com>
---
drivers/mmc/host/sdhci.c | 25 ++++++++++++++++++++++---
1 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 7922adb..925c403 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2844,11 +2844,17 @@ int sdhci_add_host(struct sdhci_host *host)
!(host->mmc->caps & MMC_CAP_NONREMOVABLE))
mmc->caps |= MMC_CAP_NEEDS_POLL;
- /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
+ /*
+ * If vqmmc regulator and no 1.8V signalling, then there's no UHS.
+ * vqmmc regulator should be present. If it's not present,
+ * assume the regulator driver registration is not yet done and
+ * defer the probe.
+ */
host->vqmmc = regulator_get(mmc_dev(mmc), "vqmmc");
if (IS_ERR(host->vqmmc)) {
- pr_info("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
+ pr_err("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
host->vqmmc = NULL;
+ return -EPROBE_DEFER;
}
else if (regulator_is_supported_voltage(host->vqmmc, 1800000, 1800000))
regulator_enable(host->vqmmc);
@@ -2903,10 +2909,17 @@ int sdhci_add_host(struct sdhci_host *host)
ocr_avail = 0;
+ /*
+ * vmmc regulator should be present. If it's not present,
+ * assume the regulator driver registration is not yet done
+ * and defer the probe.
+ */
host->vmmc = regulator_get(mmc_dev(mmc), "vmmc");
if (IS_ERR(host->vmmc)) {
- pr_info("%s: no vmmc regulator found\n", mmc_hostname(mmc));
+ pr_err("%s: no vmmc regulator found\n", mmc_hostname(mmc));
host->vmmc = NULL;
+ ret = -EPROBE_DEFER;
+ goto vmmc_err;
} else
regulator_enable(host->vmmc);
@@ -3121,7 +3134,13 @@ reset:
untasklet:
tasklet_kill(&host->card_tasklet);
tasklet_kill(&host->finish_tasklet);
+vmmc_err:
+ if (host->vqmmc) {
+ if (regulator_is_enabled(host->vqmmc))
+ regulator_disable(host->vqmmc);
+ regulator_put(host->vqmmc);
+ }
return ret;
}
--
1.7.1.1
^ permalink raw reply related
* [PATCH 1/2] ARM: dt: tegra: Add sdhci regulators
From: Pavan Kunapuli @ 2012-10-23 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350976740-19284-1-git-send-email-pkunapuli@nvidia.com>
Adding vmmc and vmmcq supplies for sdhci nodes
in tegra dt files.
Signed-off-by: Pavan Kunapuli <pkunapuli@nvidia.com>
---
arch/arm/boot/dts/tegra20-harmony.dts | 27 ++++++++++++++++++++-
arch/arm/boot/dts/tegra20-paz00.dts | 24 +++++++++++++++++++-
arch/arm/boot/dts/tegra20-seaboard.dts | 35 ++++++++++++++++++++++++++++-
arch/arm/boot/dts/tegra20-tamonten.dtsi | 10 ++++++++
arch/arm/boot/dts/tegra20-ventana.dts | 36 ++++++++++++++++++++++++++++-
arch/arm/boot/dts/tegra20-whistler.dts | 9 +++++-
arch/arm/boot/dts/tegra30-cardhu-a02.dts | 2 +
arch/arm/boot/dts/tegra30-cardhu-a04.dts | 2 +
arch/arm/boot/dts/tegra30-cardhu.dtsi | 19 ++++++++++++++-
9 files changed, 154 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index 74b8a47..5b02afe 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -419,7 +419,8 @@
status = "okay";
cd-gpios = <&gpio 69 0>; /* gpio PI5 */
wp-gpios = <&gpio 57 0>; /* gpio PH1 */
- power-gpios = <&gpio 155 0>; /* gpio PT3 */
+ vmmc-supply = <&vddio_sd_reg>;
+ vqmmc-supply = <&vddio_sd_reg>;
bus-width = <4>;
};
@@ -427,7 +428,8 @@
status = "okay";
cd-gpios = <&gpio 58 0>; /* gpio PH2 */
wp-gpios = <&gpio 59 0>; /* gpio PH3 */
- power-gpios = <&gpio 70 0>; /* gpio PI6 */
+ vmmc-supply = <&vddio_sdmmc_reg>;
+ vqmmc-supply = <&vddio_sdmmc_reg>;
bus-width = <8>;
};
@@ -495,6 +497,27 @@
gpio = <&gpio 176 0>; /* gpio PW0 */
enable-active-high;
};
+
+ vddio_sdmmc_reg: regulator at 6 {
+ compatible = "regulator-fixed";
+ reg = <6>;
+ regulator-name = "vddio_sdmmc";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio 70 0>; /* gpio PW0 */
+ enable-active-high;
+ };
+
+ vddio_sd_reg: regulator at 7 {
+ compatible = "regulator-fixed";
+ reg = <7>;
+ regulator-name = "vddio_sd";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio 155 0>; /* gpio PW0 */
+ enable-active-high;
+ };
+
};
sound {
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index 6a93d14..e161b65 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -422,13 +422,17 @@
status = "okay";
cd-gpios = <&gpio 173 0>; /* gpio PV5 */
wp-gpios = <&gpio 57 0>; /* gpio PH1 */
- power-gpios = <&gpio 169 0>; /* gpio PV1 */
bus-width = <4>;
+ vmmc-supply = <&vddio_sd_reg>;
+ vqmmc-supply = <&vddio_sd_reg>;
+
};
sdhci at c8000600 {
status = "okay";
bus-width = <8>;
+ vmmc-supply = <&vddio_sdmmc_reg>;
+ vqmmc-supply = <&vddio_sdmmc_reg>;
};
gpio-keys {
@@ -465,6 +469,24 @@
regulator-max-microvolt = <5000000>;
regulator-always-on;
};
+
+ vddio_sd_reg: regulator at 1 {
+ compatible = "regulator-fixed";
+ reg = <1>;
+ regulator-name = "vddio_sd";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ enable-active-high;
+ gpio = <&gpio 169 0>; /* gpio PV1 */
+ };
+
+ vddio_sdmmc_reg: regulator at 2 {
+ compatible = "regulator-fixed";
+ reg = <2>;
+ regulator-name = "vddio_sdmmc";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
};
sound {
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index eafeca6..1b7d692 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -450,7 +450,7 @@
regulator-always-on;
};
- ldo5 {
+ ldo5_reg: ldo5 {
regulator-name = "vdd_ldo5,vcore_mmc";
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
@@ -565,6 +565,9 @@
status = "okay";
power-gpios = <&gpio 86 0>; /* gpio PK6 */
bus-width = <4>;
+ vmmc-supply = <&vddio_sdmmc_reg>;
+ vqmmc-supply = <&vddio_sdmmc_reg>;
+
};
sdhci at c8000400 {
@@ -573,11 +576,15 @@
wp-gpios = <&gpio 57 0>; /* gpio PH1 */
power-gpios = <&gpio 70 0>; /* gpio PI6 */
bus-width = <4>;
+ vmmc-supply = <&vddio_sd_reg>;
+ vqmmc-supply = <&vddio_sd_reg>;
};
sdhci at c8000600 {
status = "okay";
bus-width = <8>;
+ vmmc-supply = <&ldo5_reg>;
+ vqmmc-supply = <&vddio_nand_reg>;
};
gpio-keys {
@@ -632,6 +639,32 @@
gpio = <&pmic 1 0>;
enable-active-high;
};
+
+ vddio_sd_reg: regulator at 3 {
+ compatible = "regulator-fixed";
+ reg = <3>;
+ regulator-name = "vddio_sd";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio 176 0>; /* gpio PW0 */
+ enable-active-high;
+ };
+
+ vddio_sdmmc_reg: regulator at 4 {
+ compatible = "regulator-fixed";
+ reg = <4>;
+ regulator-name = "vddio_sdmmc";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vddio_nand_reg: regulator at 5 {
+ compatible = "regulator-fixed";
+ reg = <5>;
+ regulator-name = "vddio_nand";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
};
sound {
diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi b/arch/arm/boot/dts/tegra20-tamonten.dtsi
index 5b3d8b1..a60e828 100644
--- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
+++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
@@ -396,6 +396,8 @@
wp-gpios = <&gpio 59 0>; /* gpio PH3 */
bus-width = <4>;
status = "okay";
+ vmmc-supply = <&vddio_sdmmc_reg>;
+ vqmmc-supply = <&vddio_sdmmc_reg>;
};
regulators {
@@ -412,5 +414,13 @@
regulator-max-microvolt = <5000000>;
regulator-always-on;
};
+
+ vddio_sdmmc_reg: regulator at 1 {
+ compatible = "regulator-fixed";
+ reg = <1>;
+ regulator-name = "vddio_sdmmc";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
};
};
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index bec8bb2..0210670 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -376,7 +376,7 @@
regulator-always-on;
};
- ldo5 {
+ ldo5_reg: ldo5 {
regulator-name = "vdd_ldo5,vcore_mmc";
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
@@ -439,19 +439,24 @@
status = "okay";
power-gpios = <&gpio 86 0>; /* gpio PK6 */
bus-width = <4>;
+ vmmc-supply = <&vddio_sdmmc_reg>;
+ vqmmc-supply = <&vddio_sdmmc_reg>;
};
sdhci at c8000400 {
status = "okay";
cd-gpios = <&gpio 69 0>; /* gpio PI5 */
wp-gpios = <&gpio 57 0>; /* gpio PH1 */
- power-gpios = <&gpio 70 0>; /* gpio PI6 */
bus-width = <4>;
+ vmmc-supply = <&vddio_sd_reg>;
+ vqmmc-supply = <&vddio_sd_reg>;
};
sdhci at c8000600 {
status = "okay";
bus-width = <8>;
+ vmmc-supply = <&ldo5_reg>;
+ vqmmc-supply = <&vddio_nand_reg>;
};
regulators {
@@ -506,6 +511,33 @@
gpio = <&gpio 176 0>; /* gpio PW0 */
enable-active-high;
};
+
+ vddio_sd_reg: regulator at 5 {
+ compatible = "regulator-fixed";
+ reg = <5>;
+ regulator-name = "vddio_sd";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio 70 0>; /* gpio PW0 */
+ enable-active-high;
+ };
+
+ vddio_sdmmc_reg: regulator at 6 {
+ compatible = "regulator-fixed";
+ reg = <6>;
+ regulator-name = "vddio_sdmmc";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vddio_nand_reg: regulator at 7 {
+ compatible = "regulator-fixed";
+ reg = <7>;
+ regulator-name = "vddio_nand";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
};
sound {
diff --git a/arch/arm/boot/dts/tegra20-whistler.dts b/arch/arm/boot/dts/tegra20-whistler.dts
index 94a71c9..bdc4918 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -349,7 +349,7 @@
regulator-always-on;
};
- ldo5 {
+ ldo5_reg: ldo5 {
regulator-name = "nvvdd_ldo5,vcore_mmc,avdd_lcd1,vddio_1wire";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
@@ -394,7 +394,7 @@
regulator-max-microvolt = <3300000>;
};
- ldo12 {
+ ldo12_reg: ldo12 {
regulator-name = "nvvdd_ldo12,vddio_sdio";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
@@ -496,11 +496,16 @@
status = "okay";
wp-gpios = <&gpio 173 0>; /* gpio PV5 */
bus-width = <8>;
+ vmmc-supply = <&ldo12_reg>;
+ vqmmc-supply = <&ldo12_reg>;
};
sdhci at c8000600 {
status = "okay";
bus-width = <8>;
+ vmmc-supply = <&ldo5_reg>;
+ vqmmc-supply = <&ldo5_reg>;
+
};
regulators {
diff --git a/arch/arm/boot/dts/tegra30-cardhu-a02.dts b/arch/arm/boot/dts/tegra30-cardhu-a02.dts
index adc88aa..697effa 100644
--- a/arch/arm/boot/dts/tegra30-cardhu-a02.dts
+++ b/arch/arm/boot/dts/tegra30-cardhu-a02.dts
@@ -88,6 +88,8 @@
status = "okay";
power-gpios = <&gpio 28 0>; /* gpio PD4 */
bus-width = <4>;
+ vmmc-supply = <&vio_reg>;
+ vqmmc-supply = <&vio_reg>;
};
};
diff --git a/arch/arm/boot/dts/tegra30-cardhu-a04.dts b/arch/arm/boot/dts/tegra30-cardhu-a04.dts
index 08163e1..ee4820a 100644
--- a/arch/arm/boot/dts/tegra30-cardhu-a04.dts
+++ b/arch/arm/boot/dts/tegra30-cardhu-a04.dts
@@ -100,5 +100,7 @@
status = "okay";
power-gpios = <&gpio 27 0>; /* gpio PD3 */
bus-width = <4>;
+ vmmc-supply = <&vio_reg>;
+ vqmmc-supply = <&vio_reg>;
};
};
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index b245e6c..fbf0fae 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -247,7 +247,7 @@
ldo5_reg: ldo5 {
regulator-name = "vddio_sdmmc,avdd_vdac";
- regulator-min-microvolt = <3300000>;
+ regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
@@ -290,13 +290,16 @@
status = "okay";
cd-gpios = <&gpio 69 0>; /* gpio PI5 */
wp-gpios = <&gpio 155 0>; /* gpio PT3 */
- power-gpios = <&gpio 31 0>; /* gpio PD7 */
bus-width = <4>;
+ vmmc-supply = <&sdcard_3v3_reg>;
+ vqmmc-supply = <&ldo5_reg>;
};
sdhci at 78000600 {
status = "okay";
bus-width = <8>;
+ vmmc-supply = <&emmc_3v3_reg>;
+ vqmmc-supply = <&vio_reg>;
};
regulators {
@@ -451,6 +454,18 @@
gpio-open-drain;
vin-supply = <&vdd_5v0_reg>;
};
+
+ sdcard_3v3_reg: regulator at 13 {
+ compatible = "regulator-fixed";
+ reg = <13>;
+ regulator-name = "sdcard_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ enable-active-high;
+ gpio = <&gpio 31 0>; /* GPIO PD7 */
+ vin-supply = <&sys_3v3_reg>;
+ };
+
};
sound {
--
1.7.1.1
^ permalink raw reply related
* [PATCH 0/2] mmc: sdhci: Defer probe if regulators are not registered
From: Pavan Kunapuli @ 2012-10-23 7:18 UTC (permalink / raw)
To: linux-arm-kernel
Regulator driver registration may sometimes be done after
mmc driver registration. In such cases, defer mmc probe
to obtain vmmc and vmmcq regulators.
Added vmmc and vmmcq supplies to tegra dt files.
Pavan Kunapuli (2):
ARM: dt: tegra: Add sdhci regulators
mmc: sdhci: Defer probe if regulator_get fails
arch/arm/boot/dts/tegra20-harmony.dts | 27 ++++++++++++++++++++-
arch/arm/boot/dts/tegra20-paz00.dts | 24 +++++++++++++++++++-
arch/arm/boot/dts/tegra20-seaboard.dts | 35 ++++++++++++++++++++++++++++-
arch/arm/boot/dts/tegra20-tamonten.dtsi | 10 ++++++++
arch/arm/boot/dts/tegra20-ventana.dts | 36 ++++++++++++++++++++++++++++-
arch/arm/boot/dts/tegra20-whistler.dts | 9 +++++-
arch/arm/boot/dts/tegra30-cardhu-a02.dts | 2 +
arch/arm/boot/dts/tegra30-cardhu-a04.dts | 2 +
arch/arm/boot/dts/tegra30-cardhu.dtsi | 19 ++++++++++++++-
drivers/mmc/host/sdhci.c | 25 ++++++++++++++++++--
10 files changed, 176 insertions(+), 13 deletions(-)
^ permalink raw reply
* [PATCH v3 0/4] make cadence ethernet drivers build on any architecture
From: David Miller @ 2012-10-23 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350931534-8416-1-git-send-email-manabian@gmail.com>
From: Joachim Eastwood <manabian@gmail.com>
Date: Mon, 22 Oct 2012 20:45:30 +0200
> Joachim Eastwood (4):
> net/macb: fix truncate warnings
> net/cadence: get rid of HAVE_NET_MACB
> net/at91_ether: select MACB in Kconfig
> net/at91_ether: add pdata flag for reverse Eth addr
All applied to net-next, thanks a lot.
^ permalink raw reply
* [PATCH] arm: dts: omap4-sdp: pinmux configuration for keypad
From: Sourav @ 2012-10-23 6:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022161909.GY4730@atomide.com>
Hi Tony,
On Monday 22 October 2012 09:49 PM, Tony Lindgren wrote:
> * Sourav Poddar <sourav.poddar@ti.com> [121022 00:30]:
>> --- a/arch/arm/boot/dts/omap4-sdp.dts
>> +++ b/arch/arm/boot/dts/omap4-sdp.dts
>> @@ -194,6 +194,27 @@
>> 0xbc 0x100 /* abe_mcbsp2_fsx.abe_mcbsp2_fsx INPUT | MODE0 */
>> >;
>> };
>> +
>> + keypad_pins: pinmux_keypad_pins {
>> + pinctrl-single,pins = <
>> + 0x24 0x4119 /* gpmc_a18.kpd_row6 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>> + 0x26 0x4119 /* gpmc_a19.kpd_row6 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>> + 0x2c 0x4001 /* gpmc_a22.kpd_col6 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
>> + 0x2e 0x4001 /* gpmc_a23.kpd_col7 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
>> + 0x13c 0x4001 /* kpd_col0.kpd_col0 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
>> + 0x13e 0x4001 /* kpd_col1.kpd_col1 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
>> + 0x140 0x4001 /* kpd_col2.kpd_col2 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
>> + 0x142 0x10F /* kpd_col3.kpd_col3 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
>> + 0x144 0x4001 /* kpd_col4.kpd_col4 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
>> + 0x146 0x4001 /* kpd_col5.kpd_col5 OMAP_WAKEUP_EN | OMAP_MUX_MODE1 */
>> + 0x148 0xc119 /* kpd_row0.kpd_row0 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>> + 0x14a 0x4119 /* kpd_row1.kpd_row1 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>> + 0x14c 0x4119 /* kpd_row2.kpd_row2 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>> + 0x14e 0x4119 /* kpd_row3.kpd_row3 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>> + 0x150 0x4119 /* kpd_row4.kpd_row4 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>> + 0x152 0x4119 /* kpd_row5.kpd_row5 OMAP_PULL_ENA | OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>> + >;
>> + };
>> };
> Please shorten these to leave out OMAP_:
Ok. Will update and send a new version.
> pinctrl-single,pins = <
> 0x24 0x4119 /* gpmc_a18.kpd_row6 PULL_ENA | PULL_UP | WAKEUP_EN | MUX_MODE1 | INPUT_EN */
> 0x26 0x4119 /* gpmc_a19.kpd_row6 PULL_ENA | PULL_UP | WAKEUP_EN | MUX_MODE1 | INPUT_EN */
> ...
>
> When we convert them over to use the preprocessor, we can still
> easily replace them.
>
> Regards,
>
> Tony
^ permalink raw reply
* [PATCH v2] arm: sched: stop sched_clock() during suspend
From: Felipe Balbi @ 2012-10-23 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <873916h1yi.fsf@deeprootsystems.com>
The scheduler imposes a requirement to sched_clock()
which is to stop the clock during suspend, if we don't
do that any RT thread will be rescheduled in the future
which might cause any sort of problems.
This became an issue on OMAP when we converted omap-i2c.c
to use threaded IRQs, it turned out that depending on how
much time we spent on suspend, the I2C IRQ thread would
end up being rescheduled so far in the future that I2C
transfers would timeout and, because omap_hsmmc depends
on an I2C-connected device to detect if an MMC card is
inserted in the slot, our rootfs would just vanish.
arch/arm/kernel/sched_clock.c already had an optional
implementation (sched_clock_needs_suspend()) which would
handle scheduler's requirement properly, what this patch
does is simply to make that implementation non-optional.
Note that this has the side-effect that printk timings
won't reflect the actual time spent on suspend so other
methods to measure that will have to be used.
This has been tested with beagleboard XM (OMAP3630) and
pandaboard rev A3 (OMAP4430). Suspend to RAM is now working
after this patch.
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
Changes since v1:
- changed commit log to mention that all RT threads will be
rescheduled to the future.
- changed commit log to mention the side effect on printk
timings
arch/arm/include/asm/sched_clock.h | 2 --
arch/arm/kernel/sched_clock.c | 18 ++++--------------
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/arm/include/asm/sched_clock.h b/arch/arm/include/asm/sched_clock.h
index 05b8e82..e3f7572 100644
--- a/arch/arm/include/asm/sched_clock.h
+++ b/arch/arm/include/asm/sched_clock.h
@@ -10,7 +10,5 @@
extern void sched_clock_postinit(void);
extern void setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
-extern void setup_sched_clock_needs_suspend(u32 (*read)(void), int bits,
- unsigned long rate);
#endif
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index e21bac2..fc6692e 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -107,13 +107,6 @@ static void sched_clock_poll(unsigned long wrap_ticks)
update_sched_clock();
}
-void __init setup_sched_clock_needs_suspend(u32 (*read)(void), int bits,
- unsigned long rate)
-{
- setup_sched_clock(read, bits, rate);
- cd.needs_suspend = true;
-}
-
void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
{
unsigned long r, w;
@@ -189,18 +182,15 @@ void __init sched_clock_postinit(void)
static int sched_clock_suspend(void)
{
sched_clock_poll(sched_clock_timer.data);
- if (cd.needs_suspend)
- cd.suspended = true;
+ cd.suspended = true;
return 0;
}
static void sched_clock_resume(void)
{
- if (cd.needs_suspend) {
- cd.epoch_cyc = read_sched_clock();
- cd.epoch_cyc_copy = cd.epoch_cyc;
- cd.suspended = false;
- }
+ cd.epoch_cyc = read_sched_clock();
+ cd.epoch_cyc_copy = cd.epoch_cyc;
+ cd.suspended = false;
}
static struct syscore_ops sched_clock_ops = {
--
1.8.0.rc0
^ permalink raw reply related
* [PATCH 3/5] arm: mvebu: Added IPI support via doorbells
From: Thomas Petazzoni @ 2012-10-23 5:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023054455.GP21046@lunn.ch>
Andrew,
On Tue, 23 Oct 2012 07:44:55 +0200, Andrew Lunn wrote:
> Thanks for the clear reply. Does the binding documentation make this
> clear? Should it be extended to indicate which address range should be
> used?
Indeed it should be clarified in the DT binding documentation. I'll see
with Gr?gory to add such a clarification in his v2 of the SMP patch
set, if that's ok with you.
Best regards,
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 3/5] arm: mvebu: Added IPI support via doorbells
From: Andrew Lunn @ 2012-10-23 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023071419.222c46d3@skate>
On Tue, Oct 23, 2012 at 07:14:19AM +0200, Thomas Petazzoni wrote:
>
> On Mon, 22 Oct 2012 23:11:02 +0200, Gregory CLEMENT wrote:
>
> > The correct explanation is that the offset +21070 is a CPU virtual offset.
> > That means that depending of the CPU core which will access to this register,
> > the controller will internally change the offset automagically to point the
> > correct offset.
> >
> > I should have added an explanation in the commit log. I will do it for V2.
>
> Just to expand on Gr??gory's comment: there is per-CPU banking for the
> interrupt controller registers. At 0x21070, you have "virtual"
> registers that automatically map to the interrupt controller registers
> of the current CPU. At 0x21870, you have the interrupt controllers
> registers of CPU0, regardless of which CPU you are running on.
>
> Before this patch set, there was no SMP support for Armada 370/XP, so
> accessing the interrupt controller registers at 0x21870 was OK
> (accessing them from 0x21070 would have been OK as well). With the
> introduction of SMP support, accessing them from 0x21870 no longer
> works, so we switch to the virtual registers at 0x21070.
>
> In other words: no it is not a bug fix and it therefore doesn't need to
> go into 3.7.
Hi Thomas
Thanks for the clear reply. Does the binding documentation make this
clear? Should it be extended to indicate which address range should be
used?
Thanks
Andrew
^ permalink raw reply
* [PATCH 3/5] arm: mvebu: Added IPI support via doorbells
From: Thomas Petazzoni @ 2012-10-23 5:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5085B666.1040500@free-electrons.com>
On Mon, 22 Oct 2012 23:11:02 +0200, Gregory CLEMENT wrote:
> The correct explanation is that the offset +21070 is a CPU virtual offset.
> That means that depending of the CPU core which will access to this register,
> the controller will internally change the offset automagically to point the
> correct offset.
>
> I should have added an explanation in the commit log. I will do it for V2.
Just to expand on Gr?gory's comment: there is per-CPU banking for the
interrupt controller registers. At 0x21070, you have "virtual"
registers that automatically map to the interrupt controller registers
of the current CPU. At 0x21870, you have the interrupt controllers
registers of CPU0, regardless of which CPU you are running on.
Before this patch set, there was no SMP support for Armada 370/XP, so
accessing the interrupt controller registers at 0x21870 was OK
(accessing them from 0x21070 would have been OK as well). With the
introduction of SMP support, accessing them from 0x21870 no longer
works, so we switch to the virtual registers at 0x21070.
In other words: no it is not a bug fix and it therefore doesn't need to
go into 3.7.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* OMAP baseline test results for v3.7-rc2
From: Paul Walmsley @ 2012-10-23 4:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210230311490.31118@utopia.booyaka.com>
On Tue, 23 Oct 2012, Paul Walmsley wrote:
> As Kevin mentioned earlier, this is unfortunately not true for those of us
> with earlier BeagleBoards:
er, BeagleBones, rather...
- Paul
^ permalink raw reply
* [PATCH] DMA: AT91: Get residual bytes in dma buffer
From: Song, Elen @ 2012-10-23 3:32 UTC (permalink / raw)
To: linux-arm-kernel
Ping....
>-----Original Message-----
>From: Song, Elen
>Sent: 2012?10?15? 17:19
>To: Ferre, Nicolas
>Cc: 'Russell King - ARM Linux'; 'Jean-Christophe PLAGNIOL-VILLARD';
>linux-arm-kernel at lists.infradead.org
>Subject: [PATCH] DMA: AT91: Get residual bytes in dma buffer
>
>The main purpose of atc_tx_status is to get residual bytes when dma transfer in
>progress or complete.
>
>Residual bytes is the number of bytes left to read from DMA source.
>During transfer, residual bytes is changing as DMA read from its source.
>When transfer complete, the residual bytes is zero.
>
>atc_get_bytes_left will dynamically get bytes left in dma buffer.
>It reads count register bit btsize to get residue, the btsize only indicate current
>descriptor receive data.
>So we should let atc_get_bytes_left know when descriptor switch or dma
>transfer done.
>DMA_CTRL_ACK is a useful ack, it means current descriptor can not be reused
>when clear.
>The atc_get_bytes_left will find out whether move to next descriptor or transfer
>done.
>
>So in dma handler, we get residue like below:
>dma_handler() {
> async_tx_clear_ack; //clear ack, tell driver it is time to switch
>descriptor
> read residue;
> async_tx_ack; //move to next descriptor
> // no need to set ack when dma transfer done }
>
>DMA should be pause so that we can trust data count.
>
>Signed-off-by: Elen Song <elen.song@atmel.com>
>---
> drivers/dma/at_hdmac.c | 127
>+++++++++++++++++++++++++++++++++++++++----
> drivers/dma/at_hdmac_regs.h | 4 ++
> 2 files changed, 120 insertions(+), 11 deletions(-)
>
>diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c index
>13a02f4..b0aa783 100644
>--- a/drivers/dma/at_hdmac.c
>+++ b/drivers/dma/at_hdmac.c
>@@ -229,6 +229,101 @@ static void atc_dostart(struct at_dma_chan *atchan,
>struct at_desc *first)
> vdbg_dump_regs(atchan);
> }
>
>+/*
>+ * atc_get_current_descriptors - get descriptor which equal to
>+ * physical address in DSCR.
>+ * @atchan: the channel we want to start
>+ * @dscr_addr: physical descriptor address in DSCR */ static struct
>+at_desc *atc_get_current_descriptors(struct at_dma_chan *atchan,
>+ u32 dscr_addr)
>+{
>+ struct at_desc *desc, *_desc, *child, *desc_cur = NULL;
>+
>+ list_for_each_entry_safe(desc, _desc, &atchan->active_list, desc_node)
>+{
>+
>+ if (desc->lli.dscr == dscr_addr) {
>+ desc_cur = desc;
>+ break;
>+ }
>+
>+ list_for_each_entry(child, &desc->tx_list, desc_node) {
>+
>+ if (child->lli.dscr == dscr_addr) {
>+ desc_cur = child;
>+ break;
>+ }
>+ }
>+ }
>+
>+ return desc_cur;
>+}
>+
>+/*
>+ * atc_get_bytes_left - Get the number of bytes
>+ * residue in dma buffer,
>+ * it is unwise to call this before stopping the channel for
>+ * absolute measures.
>+ * @atchan: the channel we want to start */ static int
>+atc_get_bytes_left(struct at_dma_chan *atchan) {
>+ struct at_desc *desc_first;
>+ int left = 0, count = 0;
>+ u32 dscr_addr;
>+
>+ /* First descriptor embedds additional information */
>+ desc_first = atc_first_active(atchan);
>+ if (!desc_first)
>+ return -EINVAL;
>+
>+ /* Initialize necessary value in the first time.
>+ * We use desc_cur to save current descriptor,
>+ * save_len record residual dma buffer length.
>+ */
>+ if (!atchan->desc_cur &&
>+ !atchan->save_len) {
>+ atchan->desc_cur = desc_first;
>+ atchan->save_len = desc_first->len;
>+ }
>+
>+ /* This happend in the end of dma transfer or descriptor switch,
>+ * during the dma interrupt handler, DMA_CTRL_ACK should be cleared.
>+ * We trigger this flag to get residual values.
>+ * To be aware of, two conditions should be taken into consideration:
>+ * at the end of a dma transfer, or descriptors switch.
>+ */
>+ if (!(desc_first->txd.flags & DMA_CTRL_ACK)) {
>+ dscr_addr = channel_readl(atchan, DSCR);
>+ /* End of a single or cyclic transfer */
>+ if (dscr_addr == 0 || dscr_addr == desc_first->lli.dscr) {
>+ atchan->desc_cur = NULL;
>+ atchan->save_len = 0;
>+ /* Switch between two descriptor.
>+ * Current descriptor transfer done.
>+ * The residual buffer length should reduce current descriptor.
>+ */
>+ } else {
>+ atchan->desc_cur = atc_get_current_descriptors(atchan,
>+ dscr_addr);
>+ if (!atchan->desc_cur)
>+ return -EINVAL;
>+ atchan->save_len -= (atchan->desc_cur->lli.ctrla
>+ & ATC_BTSIZE_MAX);
>+ }
>+
>+ left = atchan->save_len;
>+ }
>+
>+ /* Get residual value during a descriptor transfer */
>+ if (atchan->desc_cur) {
>+ count = channel_readl(atchan, CTRLA) & ATC_BTSIZE_MAX;
>+ left = atchan->save_len - count;
>+ }
>+
>+ return left;
>+}
>+
> /**
> * atc_chain_complete - finish work for one transaction chain
> * @atchan: channel we work on
>@@ -1034,23 +1129,33 @@ atc_tx_status(struct dma_chan *chan,
> dma_cookie_t last_complete;
> unsigned long flags;
> enum dma_status ret;
>-
>- spin_lock_irqsave(&atchan->lock, flags);
>+ int bytes = 0;
>
> ret = dma_cookie_status(chan, cookie, txstate);
>- if (ret != DMA_SUCCESS) {
>- atc_cleanup_descriptors(atchan);
>-
>- ret = dma_cookie_status(chan, cookie, txstate);
>+ /* Residue is zero while transactions complete */
>+ if (ret == DMA_SUCCESS) {
>+ dma_set_residue(txstate, 0);
>+ return ret;
>+ }
>+ /*
>+ * There's no point calculating the residue if there's
>+ * no txstate to store the value.
>+ */
>+ if (!txstate) {
>+ if (atc_chan_is_paused(atchan))
>+ ret = DMA_PAUSED;
>+ return ret;
> }
>
>- last_complete = chan->completed_cookie;
>- last_used = chan->cookie;
>+ spin_lock_irqsave(&atchan->lock, flags);
>
>- spin_unlock_irqrestore(&atchan->lock, flags);
>+ /* Get number of bytes left in the active transactions */
>+ bytes = atc_get_bytes_left(atchan);
>+ if (bytes < 0)
>+ dev_err(chan2dev(chan), "get residue value error\n");
>+ dma_set_residue(txstate, bytes);
>
>- if (ret != DMA_SUCCESS)
>- dma_set_residue(txstate, atc_first_active(atchan)->len);
>+ spin_unlock_irqrestore(&atchan->lock, flags);
>
> if (atc_chan_is_paused(atchan))
> ret = DMA_PAUSED;
>diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h index
>116e4ad..ea8d747 100644
>--- a/drivers/dma/at_hdmac_regs.h
>+++ b/drivers/dma/at_hdmac_regs.h
>@@ -226,12 +226,14 @@ enum atc_status {
> * @save_cfg: configuration register that is saved on suspend/resume cycle
> * @save_dscr: for cyclic operations, preserve next descriptor address in
> * the cyclic list on suspend/resume cycle
>+ * @save_len: to record dma buffer length
> * @dma_sconfig: configuration for slave transfers, passed via
>DMA_SLAVE_CONFIG
> * @lock: serializes enqueue/dequeue operations to descriptors lists
> * @active_list: list of descriptors dmaengine is being running on
> * @queue: list of descriptors ready to be submitted to engine
> * @free_list: list of descriptors usable by the channel
> * @descs_allocated: records the actual size of the descriptor pool
>+ * @desc_cur: current descriptor
> */
> struct at_dma_chan {
> struct dma_chan chan_common;
>@@ -242,6 +244,7 @@ struct at_dma_chan {
> struct tasklet_struct tasklet;
> u32 save_cfg;
> u32 save_dscr;
>+ u32 save_len;
> struct dma_slave_config dma_sconfig;
>
> spinlock_t lock;
>@@ -251,6 +254,7 @@ struct at_dma_chan {
> struct list_head queue;
> struct list_head free_list;
> unsigned int descs_allocated;
>+ struct at_desc *desc_cur;
> };
>
> #define channel_readl(atchan, name) \
>--
>1.7.9.5
^ permalink raw reply
* OMAP baseline test results for v3.7-rc2
From: Paul Walmsley @ 2012-10-23 3:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023015346.GB1855@beef>
On Mon, 22 Oct 2012, Matt Porter wrote:
> I've mentioned this a few times in various threads...no need to use
> appended DTB on a current U-Boot. Some of us are indeed booting this way
> with the DTB properly passed separately from the bootloader and chosen
> filled out by the bootloader. And yes, am335x_evm_config applies to all
> AM33xx TI EVMs and the BeagleBone board. There's an EEPROM onboard all
> that is used to determine what board is present so a single
> MLO/u-boot.img can be used.
As Kevin mentioned earlier, this is unfortunately not true for those of us
with earlier BeagleBoards:
http://marc.info/?l=linux-omap&m=135094296931913&w=2
Do you know what the minimum board revision is that you all are
supporting in U-boot?
- Paul
^ permalink raw reply
* pxa:spitz_pm.c: commit b6eede11 breaks spitz resume under certain conditions.
From: Eric Miao @ 2012-10-23 3:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHod+GfycPnugk0UF6aqFUb4UJwZRM_PHPiSDpGSbF3OXSwMLw@mail.gmail.com>
On Fri, Oct 19, 2012 at 7:37 PM, Marko Kati? <dromede@gmail.com> wrote:
> On Thu, Oct 18, 2012 at 11:28 AM, Marko Kati? <dromede@gmail.com> wrote:
>>> Almost there, but I guess we could do this better and less confusing by having
>>> another array, e.g. tosa_gpio18_config[], which is tosa specific, and only
>>> initialize that MFP setting in the tosa path.
>>>
>>>>
>>>> I also looked at the original sharp kernel sources.
>>>> Only tosa used the RDY signal for it's tc6393tx chip, other machines simply
>>>> configured gpio18 as output in their suspend routines.
>>
>>
>> Actually, tosa doesn't use sharpsl_pm. Tosa uses the pda-power framework.
>> I said that only tosa uses the RDY signal to point out that we
>> probably don't need
>> the mfp-config line in postsuspend. That being said, i still think
>> that the array ordering
>> fix is adequate. Maybe later we may remove the mfp-config line from
>> postsuspend when
>> we're absolutely sure it isn't necessary for devices that use spitz_pm.c.
>
> So Eric what do you think, is the simple gpio array reordering patch
> an adequate fix for this bug?
Sorry for late reply. That simple reordering still looks a bit confusing
to me, i.e. the same pin firstly configured as GPIO then RDY. Do we
have a less confusing way to fix this?
^ 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