* [PATCH 1/5] mmc: sdhci-esdhc-imx: add support for write protect on custom GPIO
From: Wolfram Sang @ 2011-02-10 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297365291-1038-1-git-send-email-w.sang@pengutronix.de>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
arch/arm/plat-mxc/include/mach/esdhc.h | 10 +++++-
drivers/mmc/host/sdhci-esdhc-imx.c | 51 +++++++++++++++++++++++++-------
2 files changed, 49 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-mxc/include/mach/esdhc.h b/arch/arm/plat-mxc/include/mach/esdhc.h
index a48a9aa..dbf6d56 100644
--- a/arch/arm/plat-mxc/include/mach/esdhc.h
+++ b/arch/arm/plat-mxc/include/mach/esdhc.h
@@ -10,7 +10,15 @@
#ifndef __ASM_ARCH_IMX_ESDHC_H
#define __ASM_ARCH_IMX_ESDHC_H
+/**
+ * struct esdhc_platform_data - optional platform data for esdhc on i.MX
+ *
+ * strongly recommended for i.MX25/35, not needed for other variants
+ *
+ * @wp_gpio: gpio for write_protect
+ */
+
struct esdhc_platform_data {
- unsigned int wp_gpio; /* write protect pin */
+ unsigned int wp_gpio;
};
#endif /* __ASM_ARCH_IMX_ESDHC_H */
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index 9b82910..83d178b 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -15,9 +15,11 @@
#include <linux/delay.h>
#include <linux/err.h>
#include <linux/clk.h>
+#include <linux/gpio.h>
#include <linux/mmc/host.h>
#include <linux/mmc/sdhci-pltfm.h>
#include <mach/hardware.h>
+#include <mach/esdhc.h>
#include "sdhci.h"
#include "sdhci-pltfm.h"
#include "sdhci-esdhc.h"
@@ -100,10 +102,31 @@ static unsigned int esdhc_pltfm_get_min_clock(struct sdhci_host *host)
return clk_get_rate(pltfm_host->clk) / 256 / 16;
}
+static unsigned int esdhc_pltfm_get_ro(struct sdhci_host *host)
+{
+ struct esdhc_platform_data *boarddata = host->mmc->parent->platform_data;
+
+ if (boarddata && gpio_is_valid(boarddata->wp_gpio))
+ return gpio_get_value(boarddata->wp_gpio);
+ else
+ return -ENOSYS;
+}
+
+static struct sdhci_ops sdhci_esdhc_ops = {
+ .read_w = esdhc_readw_le,
+ .write_w = esdhc_writew_le,
+ .write_b = esdhc_writeb_le,
+ .set_clock = esdhc_set_clock,
+ .get_max_clock = esdhc_pltfm_get_max_clock,
+ .get_min_clock = esdhc_pltfm_get_min_clock,
+};
+
static int esdhc_pltfm_init(struct sdhci_host *host, struct sdhci_pltfm_data *pdata)
{
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct esdhc_platform_data *boarddata = host->mmc->parent->platform_data;
struct clk *clk;
+ int err;
clk = clk_get(mmc_dev(host->mmc), NULL);
if (IS_ERR(clk)) {
@@ -116,9 +139,20 @@ static int esdhc_pltfm_init(struct sdhci_host *host, struct sdhci_pltfm_data *pd
if (cpu_is_mx35() || cpu_is_mx51())
host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
- /* Fix errata ENGcm07207 which is present on i.MX25 and i.MX35 */
- if (cpu_is_mx25() || cpu_is_mx35())
+ if (cpu_is_mx25() || cpu_is_mx35()) {
+ /* Fix errata ENGcm07207 present on i.MX25 and i.MX35 */
host->quirks |= SDHCI_QUIRK_NO_MULTIBLOCK;
+ /* write_protect can't be routed to controller, use gpio */
+ sdhci_esdhc_ops.get_ro = esdhc_pltfm_get_ro;
+ }
+
+ if (boarddata) {
+ err = gpio_request_one(boarddata->wp_gpio, GPIOF_IN, "ESDHC_WP");
+ if (err) {
+ dev_warn(mmc_dev(host->mmc), "can't get wp_pin!\n");
+ boarddata->wp_gpio = err;
+ }
+ }
return 0;
}
@@ -126,20 +160,15 @@ static int esdhc_pltfm_init(struct sdhci_host *host, struct sdhci_pltfm_data *pd
static void esdhc_pltfm_exit(struct sdhci_host *host)
{
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct esdhc_platform_data *boarddata = host->mmc->parent->platform_data;
+
+ if (boarddata && gpio_is_valid(boarddata->wp_gpio))
+ gpio_free(boarddata->wp_gpio);
clk_disable(pltfm_host->clk);
clk_put(pltfm_host->clk);
}
-static struct sdhci_ops sdhci_esdhc_ops = {
- .read_w = esdhc_readw_le,
- .write_w = esdhc_writew_le,
- .write_b = esdhc_writeb_le,
- .set_clock = esdhc_set_clock,
- .get_max_clock = esdhc_pltfm_get_max_clock,
- .get_min_clock = esdhc_pltfm_get_min_clock,
-};
-
struct sdhci_pltfm_data sdhci_esdhc_imx_pdata = {
.quirks = ESDHC_DEFAULT_QUIRKS | SDHCI_QUIRK_BROKEN_ADMA,
/* ADMA has issues. Might be fixable */
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/5] sdhci-esdhc-imx: use gpio for write protection and card detection
From: Wolfram Sang @ 2011-02-10 19:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I finally could do a second version of my write protect-patches and the first
version of a card detect approach (thanks to Olof for the inspiration here).
Note that these feature are only needed for i.mx25/35 as the i.mx5x-series
_finally_ seem to be able to route the gpios to the controller directly.
These patches apply to mmc-next and have been tested with a mx35-based pcm043.
I think the first three patches should go via Chris and the latter two via
Sascha. The last one is more a cleanup-patch, but it depends on the former, so
I included it here.
The branch can be found at:
git://git.pengutronix.de/git/wsa/linux-2.6.git pcm043-mmc
Eric: Would be awesome if you could test these on your boards!
Looking forward to comments,
Wolfram
Wolfram Sang (5):
mmc: sdhci-esdhc-imx: add support for write protect on custom GPIO
mmc: sdhci-esdhc: broken card detection is not a default quirk
mmc: sdhci-esdhc-imx: add card detect on custom GPIO
arm: mach-mx3: pcm043: add write-protect and card-detect for SD1
arm: mach-mx3: use IMX_GPIO_NR instead of hard-coded values
arch/arm/mach-mx3/eukrea_mbimxsd-baseboard.c | 4 +-
arch/arm/mach-mx3/mach-cpuimx35.c | 2 +-
arch/arm/mach-mx3/mach-pcm043.c | 19 +++-
arch/arm/plat-mxc/include/mach/esdhc.h | 12 ++-
drivers/mmc/host/sdhci-esdhc-imx.c | 129 +++++++++++++++++++++++---
drivers/mmc/host/sdhci-esdhc.h | 1 -
drivers/mmc/host/sdhci-of-esdhc.c | 3 +-
7 files changed, 148 insertions(+), 22 deletions(-)
--
1.7.2.3
^ permalink raw reply
* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
From: Russell King - ARM Linux @ 2011-02-10 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTiks_8hXd=7cKN0jNw=1QGcb=5ZyFu1sEFc0G=Px@mail.gmail.com>
On Thu, Feb 10, 2011 at 06:29:41PM +0000, Dave Martin wrote:
> On Thu, Feb 10, 2011 at 2:46 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Thu, Feb 10, 2011 at 02:13:13PM +0000, Dave Martin wrote:
> >> Note that this tree contains some extra patches (though I believe
> >> nothing is there which should cause the problem), and does not contain
> >> everything from rmk/devel -- so it's possible this has been fixed in
> >> the meantime or no longer occurs for some other reason...
> >
> > No need - I now have some modules which contain SMP alternatives, so we
> > do need to fix the module loader for this, and keep the SMP alternatives
> > replacement code around. ?It's not worth eliminating the code as if we
> > include an informative printk() to say why we're refusing to load the
> > module, the string would be larger than the code it eliminates. ?So, I
> > think we need to merge the patch below to avoid run-time problems.
>
> I thought the problem was not caused by removal of the fixup code, but
> rather by the removal of code referenced by fixups?
It is. But:
arm-linux-objdump -h sound/core/snd-timer.ko
sound/core/snd-timer.ko: file format elf32-littlearm
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00002f34 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .exit.text 00000070 00000000 00000000 00002f68 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
2 .init.text 000001b4 00000000 00000000 00002fd8 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
3 .rodata 000000bc 00000000 00000000 0000318c 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
4 .rodata.str1.1 00000156 00000000 00000000 00003248 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .alt.smp.init 00000088 00000000 00000000 0000339e 2**0
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
...
Here we have a module which contains the spin_unlock assembly, which
contains the SMP alternatives. If we insert that into a kernel also
built with SMP alternatives support, but which is running on a UP
system, we need to run these fixups as well when the module is loaded.
^ permalink raw reply
* [PATCH v2] OMAP: PM: DMA: Enable runtime pm
From: G, Manjunath Kondaiah @ 2011-02-10 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297082286-8449-1-git-send-email-manjugk@ti.com>
Kevin,
Do you have any comments on these changes. I am planning to have these changes
as part of new dma series(runtime support+mstandby mode api changes+removing
redundant code). I am in the process of testing all the above changes on all
the omap boards.
-Manjunath
On Mon, Feb 07, 2011 at 06:08:06PM +0530, G, Manjunath Kondaiah wrote:
> From: Manjunath G Kondaiah <manjugk@ti.com>
>
> Enable runtime pm and use pm_runtime_get_sync and pm_runtime_put_autosuspend
> for OMAP DMA driver.
>
> The DMA driver uses auto suspend feature of runtime pm framework through
> which the clock gets disabled automatically if there is no activity for
> more than one second.
>
> Testing:
> Compile: omap1_defconfig and omap2plus_defconfig
> Boot: OMAP1710(H3), OMAP2420(H4), OMAP3630(Zoom3), OMAP4(Blaze)
>
> On zoom3 core retention is tested with following steps:
> echo 1 > /debug/pm_debug/sleep_while_idle
> echo 1 > /debug/pm_debug/enable_off_mode
> echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout
> echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout
> echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout
> echo 5 > /sys/devices/platform/omap/omap_uart.3/sleep_timeout
>
> It is observed that(on pm branch), core retention count gets increasing if the
> board is left idle for more than 5 seconds. However, it doesnot enter off mode
> (even without DMA runtime changes).
>
> Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
> ---
> arch/arm/plat-omap/dma.c | 27 +++++++++++++++++++++++++++
> 1 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> index 2ec3b5d..6bfe25c 100644
> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -35,6 +35,7 @@
> #include <linux/io.h>
> #include <linux/slab.h>
> #include <linux/delay.h>
> +#include <linux/pm_runtime.h>
>
> #include <asm/system.h>
> #include <mach/hardware.h>
> @@ -59,6 +60,7 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
>
> static struct omap_system_dma_plat_info *p;
> static struct omap_dma_dev_attr *d;
> +static struct device *dev;
>
> static int enable_1510_mode;
> static u32 errata;
> @@ -676,6 +678,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
> unsigned long flags;
> struct omap_dma_lch *chan;
>
> + pm_runtime_get_sync(dev);
> spin_lock_irqsave(&dma_chan_lock, flags);
> for (ch = 0; ch < dma_chan_count; ch++) {
> if (free_ch == -1 && dma_chan[ch].dev_id == -1) {
> @@ -686,6 +689,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
> }
> if (free_ch == -1) {
> spin_unlock_irqrestore(&dma_chan_lock, flags);
> + pm_runtime_put_autosuspend(dev);
> return -EBUSY;
> }
> chan = dma_chan + free_ch;
> @@ -743,6 +747,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
> }
>
> *dma_ch_out = free_ch;
> + pm_runtime_put_autosuspend(dev);
>
> return 0;
> }
> @@ -871,6 +876,8 @@ void omap_start_dma(int lch)
> {
> u32 l;
>
> + pm_runtime_get_sync(dev);
> +
> /*
> * The CPC/CDAC register needs to be initialized to zero
> * before starting dma transfer.
> @@ -1805,6 +1812,8 @@ static int omap1_dma_handle_ch(int ch)
> if (likely(dma_chan[ch].callback != NULL))
> dma_chan[ch].callback(ch, csr, dma_chan[ch].data);
>
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
> return 1;
> }
>
> @@ -1899,6 +1908,8 @@ static int omap2_dma_handle_ch(int ch)
> if (likely(dma_chan[ch].callback != NULL))
> dma_chan[ch].callback(ch, status, dma_chan[ch].data);
>
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
> return 0;
> }
>
> @@ -1978,6 +1989,7 @@ static int __devinit omap_system_dma_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> + dev = &pdev->dev;
> d = p->dma_attr;
> errata = p->errata;
>
> @@ -1999,6 +2011,11 @@ static int __devinit omap_system_dma_probe(struct platform_device *pdev)
> }
> }
>
> + pm_runtime_use_autosuspend(dev);
> + pm_runtime_set_autosuspend_delay(dev, 1000);
> + pm_runtime_enable(dev);
> + pm_runtime_get_sync(dev);
> +
> spin_lock_init(&dma_chan_lock);
> for (ch = 0; ch < dma_chan_count; ch++) {
> omap_clear_dma(ch);
> @@ -2064,6 +2081,16 @@ static int __devinit omap_system_dma_probe(struct platform_device *pdev)
> dma_chan[1].dev_id = 1;
> }
> p->show_dma_caps();
> +
> + /*
> + * Note: If dma channels are reserved through boot paramters,
> + * then dma device is always enabled.
> + */
> + if (omap_dma_reserve_channels)
> + pm_runtime_get(dev);
> +
> + pm_runtime_put_autosuspend(dev);
> +
> return 0;
>
> exit_dma_irq_fail:
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
From: Dave Martin @ 2011-02-10 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210144617.GD3652@n2100.arm.linux.org.uk>
On Thu, Feb 10, 2011 at 2:46 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Feb 10, 2011 at 02:13:13PM +0000, Dave Martin wrote:
>> On Thu, Feb 10, 2011 at 2:11 PM, Dave Martin <dave.martin@linaro.org> wrote:
>> > Hi, apologies-- didn't see my mail for a bit.
>> >
>> > I get the problem with this tree and config (which builds with
>> > SMP_ON_UP and THUMB2_KERNEL for omap3/4):
>> >
>> > Tree: git://git.linaro.org/people/dmart/linux-2.6-arm.git
>> > dirty/arm/omap-thumb2+merged
>> > Config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config
>
> Thanks for the config.
>
>> Note that this tree contains some extra patches (though I believe
>> nothing is there which should cause the problem), and does not contain
>> everything from rmk/devel -- so it's possible this has been fixed in
>> the meantime or no longer occurs for some other reason...
>
> No need - I now have some modules which contain SMP alternatives, so we
> do need to fix the module loader for this, and keep the SMP alternatives
> replacement code around. ?It's not worth eliminating the code as if we
> include an informative printk() to say why we're refusing to load the
> module, the string would be larger than the code it eliminates. ?So, I
> think we need to merge the patch below to avoid run-time problems.
I thought the problem was not caused by removal of the fixup code, but
rather by the removal of code referenced by fixups?
Cheers
---Dave
^ permalink raw reply
* [PATCH 1/7] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Arnd Bergmann @ 2011-02-10 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110211003533.GA9151@S2100-06.ap.freescale.net>
On Friday 11 February 2011, Shawn Guo wrote:
>
> > > + struct resource *res;
> > > + struct resource *dma_res;
> > > + struct clk *clk;
> >
> > are visible in the parent.
> >
> It seems this is a generally used approach, seen in mxcmmc and pxamci.
Just because someone else is doing it, it doesn't have to be a good
idea ;-)
But you're right, it seems to be done this way almost everywhere.
Unless Chris has a more definite opinion here, I don't mind if
you follow the same pattern.
If someone decides that it's really a bad idea, we should change
all drivers at once.
> > > + struct mxs_dma_data dma_data;
> >
> > Why do you need host specific DMA structures? Please stick to
> > the generic dma-engine API if possible.
> >
> I'm sticking to the generic dmaengine api. The mxs dma hardware
> has separate irq line for every single dma channel, which needs to
> be told by client driver.
I'm not convinced, it still sounds like a layering violation to
have specific information about the DMA controller in the
platform data of a driver using the dma engine API.
Why can't you put the interrupt number into the platform data of
the dma engine device? Your filter function already identifies
the number of the DMA channel.
> > > +static irqreturn_t mxs_mmc_irq_handler(int irq, void *dev_id)
> > > +{
> > > + struct mxs_mmc_host *host = dev_id;
> > > + u32 stat;
> > > +
> > > + stat = __raw_readl(host->base + HW_SSP_CTRL1);
> > > + __mxs_clrl(stat & MXS_MMC_IRQ_BITS, host->base + HW_SSP_CTRL1);
> > > +
> > > + if (host->cmd && (stat & MXS_MMC_ERR_BITS))
> > > + host->status = __raw_readl(host->base + HW_SSP_STATUS);
> > > +
> > > + if ((stat & BM_SSP_CTRL1_SDIO_IRQ) && (stat & BM_SSP_CTRL1_SDIO_IRQ_EN))
> > > + mmc_signal_sdio_irq(host->mmc);
> > > +
> > > + return IRQ_HANDLED;
> > > +}
> >
> > You use spin_lock_irqsave in mxs_mmc_enable_sdio_irq, but don't
> > actually use the spinlock in the interrupt handler. This means
> > that either your interrupt handler is broken because it doesn't
> > lock, or that you don't actually need the _irqsave part.
> >
> I do not understand this one. I'm seeing mxcmmc and pxamci use
> spin_lock_irqsave/irqrestore in the similar way.
The difference is that e.g. mxcmci_irq() takes the spinlock that is
used to protect the host->use_sdio flag, serializing the the
code that initializes sdio with the code that uses it.
[Actually, mxcmci_irq() also looks wrong, because it releases the
spinlock before calling mmc_signal_sdio_irq(), so sdio may be
disabled by then, but that is a slightly different bug]
What I meant is that you take care to avoid getting into the
interrupt handler while holding the spinlock, but in the handler,
you don't check if the lock is held. It can't be correct to
serialize just half the cases.
Arnd
^ permalink raw reply
* [PATCH] i.MX23/28 framebuffer driver
From: Robert Schwebel @ 2011-02-10 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102091731.07794.arnd@arndb.de>
On Wed, Feb 09, 2011 at 05:31:07PM +0100, Arnd Bergmann wrote:
> Ok. This sounds like a lot of upfront work indeed, to make KMS more
> generic, though I think a number of driver would benefit from it
> eventually. It could be something for the Linaro graphics working
> group to look at in the following 11.11 release, depending on how
> many other people are interested in getting there.
There is already a blueprint at linaro:
https://blueprints.launchpad.net/linaro-graphics-wg/+spec/multimedia-linaro-dri-1105
We have recently tested the state of Qt acceleration on the MX51, in
order to find out which is the best way to make use of the
possibilities. However, at least at the moment this requires highly
experimental Qt sceenegraph git branches, and even then it results in
lower perfomance than with software rendering ...
But for the long term, the linaro blueprint looks like the way to go.
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v4 10/15] ARM: tegra: iomap: Add missing devices, fix use of SZ_8, SZ_64
From: Stephen Warren @ 2011-02-10 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297320204-31882-11-git-send-email-ccross@android.com>
Colin Cross wrote at Wednesday, February 09, 2011 11:43 PM:
>
> From: Gary King <gking@nvidia.com>
>
> Adds gart, hdmi, avp, host1x, and pwm controllers to mach/iomap.h
> There is no SZ_8 or SZ_64, replace them with constants
Can't we add those SZ_* constants?
--
nvpublic
^ permalink raw reply
* [PATCHv5] omap3: Add basic support for 720MHz part
From: Kevin Hilman @ 2011-02-10 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297239010-29683-1-git-send-email-premi@ti.com>
Sanjeev Premi <premi@ti.com> writes:
> This patch adds support for speed enhanced variant of OMAP35x
> processors. These parts allow ARM and IVA running at 720MHz
> and 520MHz respectively.
>
> These parts can be detected at runtime by reading contents of
> PRODID.SKUID[3:0] at 0x4830A20C [1].
>
> This patch specifically does following:
> * Add new OPP to omap34xx_opp_def_list[] - disabled by default.
> * Detect devices capable of running at new OPP.
> * Enable new OPP only if device supports it.
> * Check for presence of IVA before attempting to enable the
> corresponding OPP.
>
> [1] http://focus.ti.com/lit/ug/spruff1d/spruff1d.pdf
>
> It appears from discussions (on this patch) that a variant of
> OMAP3430 supports this OPP but lacks runtime detection. This
> OPP can be enabled for these device by either:
> 1) Setting the bit corresponding to OMAP3_HAS_720MHZ
> in 'omap3_features'. (Refer changes to id.c)
> 2) Removing check for omap3_has_720mhz() before enabling
> the OPP. (Refer changes to opp3xxx_data.c)
> 3) Calling opp_enable() for 720MHz/VDD1 and 520MHz/VDD2 in
> the board file. (Refer changes to opp3xxx_data.c).
> This should, ideally, be done before omap3_opp_init() is
> called during device_initcall().
>
> CAUTION: This should be done for identified parts only.
> Else, the device could be damaged permanently.
>
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> Reviewed-by: G, Manjunath Kondaiah <manjugk@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
^ permalink raw reply
* [PATCH 4/5] ARM: scu: Move register defines to header file
From: Santosh Shilimkar @ 2011-02-10 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210161350.GA9350@n2100.arm.linux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Thursday, February 10, 2011 9:44 PM
> To: Santosh Shilimkar
> Cc: catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux-
> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> ccross at android.com
> Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header
> file
>
> On Thu, Feb 10, 2011 at 08:19:19PM +0530, Santosh Shilimkar wrote:
> > This patch will need below update so that the smp_scu.h
> > header can be included from assembly files. Will you
> > fold this into your patch or you want me to
> > send below as separate patch ?
>
> Folded.
Thanks.
Regards,
Santosh
^ permalink raw reply
* [PATCH 4/5] ARM: scu: Move register defines to header file
From: Russell King - ARM Linux @ 2011-02-10 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <06aa531b67f240da586a7b56238d56b2@mail.gmail.com>
On Thu, Feb 10, 2011 at 08:19:19PM +0530, Santosh Shilimkar wrote:
> This patch will need below update so that the smp_scu.h
> header can be included from assembly files. Will you
> fold this into your patch or you want me to
> send below as separate patch ?
Folded.
^ permalink raw reply
* [PATCH 1/1] omap3: Save and restore CM_AUTOIDLE_PLL across off mode
From: Sanjeev Premi @ 2011-02-10 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297353724-11665-1-git-send-email-premi@ti.com>
As per commit "bb33cc58", ROM code is expected to restore
context related to CORE domain. As part of this change,
CM_AUTOIDLE_PLL is neither saved nor restored.
This results in loosing the value of AUTO_PERIPH_DPLL.
The concern of setting the AUTOIDLE flag before the DPLL
is locked seems valid. Hence, the restoration of this
register is delayed until after the context of PER
domain is restored.
The patch has been verified on OMAP3EVM by checking value
of CM_AUTOIDLE_PLL register across the suspend/resume
sequence (using devmem) with flags sleep_while_idle and
enable_off_mode set to 1.
Signed-off-by: Sanjeev Premi <premi@ti.com>
---
arch/arm/mach-omap2/cm2xxx_3xxx.c | 13 +++++++++++++
arch/arm/mach-omap2/pm34xx.c | 25 ++++++++++++++++++++++++-
2 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cm2xxx_3xxx.c b/arch/arm/mach-omap2/cm2xxx_3xxx.c
index 96954aa..a775d8a 100644
--- a/arch/arm/mach-omap2/cm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/cm2xxx_3xxx.c
@@ -178,6 +178,7 @@ struct omap3_cm_regs {
u32 per_cm_clksel;
u32 emu_cm_clksel;
u32 emu_cm_clkstctrl;
+ u32 pll_cm_autoidle;
u32 pll_cm_autoidle2;
u32 pll_cm_clksel4;
u32 pll_cm_clksel5;
@@ -250,6 +251,8 @@ void omap3_cm_save_context(void)
omap2_cm_read_mod_reg(OMAP3430_EMU_MOD, CM_CLKSEL1);
cm_context.emu_cm_clkstctrl =
omap2_cm_read_mod_reg(OMAP3430_EMU_MOD, OMAP2_CM_CLKSTCTRL);
+ cm_context.pll_cm_autoidle =
+ omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE);
cm_context.pll_cm_autoidle2 =
omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE2);
cm_context.pll_cm_clksel4 =
@@ -468,4 +471,14 @@ void omap3_cm_restore_context(void)
omap2_cm_write_mod_reg(cm_context.cm_clkout_ctrl, OMAP3430_CCR_MOD,
OMAP3_CM_CLKOUT_CTRL_OFFSET);
}
+
+
+/**
+ * Returns the value corresponding to CM_AUTOIDLE_PLL from the most recent
+ * context saved before entering the OFF mode.
+ */
+u32 stored_cm_autoidle_pll(void)
+{
+ return cm_context.pll_cm_autoidle;
+}
#endif
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 8bb85fb..25bd230 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -91,6 +91,8 @@ static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
static struct powerdomain *cam_pwrdm;
+extern u32 stored_cm_autoidle_pll(void);
+
static inline void omap3_per_save_context(void)
{
omap_gpio_save_context();
@@ -163,6 +165,25 @@ static void omap3_core_restore_context(void)
omap_dma_global_context_restore();
}
+/**
+ * Restore the contents of CM_AUTOIDLE_PLL register.
+ *
+ * The implementation below restores AUTO_CORE_DPLL as 'good' redundancy.
+ */
+static void pll_mod_restore_autoidle(void)
+{
+ u32 ctx = stored_cm_autoidle_pll();
+ u32 val = omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE);
+
+ if (ctx & OMAP3430_AUTO_CORE_DPLL_MASK)
+ val |= ctx & OMAP3430_AUTO_CORE_DPLL_MASK;
+
+ if (ctx & OMAP3430_AUTO_PERIPH_DPLL_MASK)
+ val |= ctx & OMAP3430_AUTO_PERIPH_DPLL_MASK;
+
+ omap2_cm_write_mod_reg(val, PLL_MOD, CM_AUTOIDLE);
+}
+
/*
* FIXME: This function should be called before entering off-mode after
* OMAP3 secure services have been accessed. Currently it is only called
@@ -488,8 +509,10 @@ void omap_sram_idle(void)
if (per_next_state < PWRDM_POWER_ON) {
per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm);
omap2_gpio_resume_after_idle();
- if (per_prev_state == PWRDM_POWER_OFF)
+ if (per_prev_state == PWRDM_POWER_OFF) {
omap3_per_restore_context();
+ pll_mod_restore_autoidle();
+ }
omap_uart_resume_idle(2);
omap_uart_resume_idle(3);
}
--
1.7.2.2
^ permalink raw reply related
* [PATCH 0/1] omap3: pm: CM_AUTOIDLE_PLL isn't restored on wakeup from off state
From: Sanjeev Premi @ 2011-02-10 16:02 UTC (permalink / raw)
To: linux-arm-kernel
The value of AUTO_PERIPH_DPLL is being lost after resuming from
the off state. More details on problem and cause in PATCH 1/1.
The problem was found recently in 2.6.32 kernel version and exists
on the latest pm branch at:
commit 448e9a675e2cfb173fc47083058cf254ccc114a0
Merge: c1e460d f11bdd3
Author: Kevin Hilman <khilman@ti.com>
Date: Fri Jan 28 14:38:47 2011 -0800
rebuild PM from branches
The shell script below was used to validate the patch on 2.6.32 for
over 8hrs on OMAP3EVM. The same script has been running after the
patch for past 1 hour on the same EVM.
**** test.sh ****
#!/bin/sh
if [ ! -d /dbg ]; then
mkdir /dbg
fi
mount -t debugfs debugfs /dbg
echo 1 > /dbg/pm_debug/enable_off_mode
echo 1 > /dbg/pm_debug/sleep_while_idle
echo 5 > /dbg/pm_debug/wakeup_timer_seconds
while :
do
before=`devmem 0x48004D30`
echo mem > /sys/power/state
after=`devmem 0x48004D30`
sleep 2
echo ""
echo "CM_AUTOIDLE_PLL: before=$before after=$after"
echo ""
sleep 1
done
**** Before ****
[root at OMAP3EVM /]# ./test.sh
[ 48.089172] PM: Syncing filesystems ... done.
[ 48.110656] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 48.135009] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[ 48.175598] ------------[ cut here ]------------
[snip]...removing warning text. Not related to current context...[/snip]
[ 48.421356] ---[ end trace 16d570308536c978 ]---
[ 48.532165] PM: suspend of devices complete after 361.805 msecs
[snip]...removed more verbose text...[/snip]
[ 55.311767] PM: resume of devices complete after 501.922 msecs
[ 55.321807] Restarting tasks ... done.
CM_AUTOIDLE_PLL: before=0x00000009 after=0x00000001
[ 59.374603] PM: Syncing filesystems ... done.
[ 59.380798] Freezing user space processes ... (elapsed 0.01 seconds) done.
[snip]...removed more verbose text...[/snip]
[ 65.085968] PM: resume of devices complete after 501.953 msecs
[ 65.095642] Restarting tasks ... done.
CM_AUTOIDLE_PLL: before=0x00000001 after=0x00000001
[ 69.148101] PM: Syncing filesystems ... done.
[ 69.154235] Freezing user space processes ... (elapsed 0.01 seconds) done.
[snip]...removed more verbose text...[/snip]
[ 74.860839] PM: resume of devices complete after 501.922 msecs
[ 74.870544] Restarting tasks ... done.
CM_AUTOIDLE_PLL: before=0x00000001 after=0x00000001
**** After ****
[root at OMAP3EVM /]# ./test.sh
[ 60.737579] PM: Syncing filesystems ... done.
[ 60.758941] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 60.783233] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[ 60.819396] omap_device: omap_i2c.1: new worst case activate latency 0: 152587
[ 60.831573] ------------[ cut here ]------------
[ 60.836547] WARNING: at arch/arm/plat-omap/omap-pm-noop.c:326 omap_pm_get_dev_context_loss_count+0x64/0xb8()
[snip]...removing warning text. Not related to current context...[/snip]
[ 61.077392] ---[ end trace 79ed0d21d6b0de0a ]---
[ 61.187927] omap_device: omap_i2c.1: new worst case deactivate latency 0: 61035
[ 61.196136] PM: suspend of devices complete after 377.311 msecs
[ 61.204650] PM: late suspend of devices complete after 2.258 msecs
[ 61.211639] PM: Resume timer in 5.000 secs (163840 ticks at 32768 ticks/sec.)
[ 61.219299] omap_device: omap_uart.2: new worst case deactivate latency 0: 91552
[ 66.214691] Successfully put all powerdomains to target state
[ 66.222106] PM: early resume of devices complete after 1.220 msecs
[ 66.730926] PM: resume of devices complete after 501.983 msecs
[ 66.740997] Restarting tasks ... done.
[ 66.782165] omap_device: omap_uart.0: new worst case activate latency 0: 61035
CM_AUTOIDLE_PLL: before=0x00000009 after=0x00000009
[ 70.794433] PM: Syncing filesystems ... done.
[ 70.800598] Freezing user space processes ... (elapsed 0.01 seconds) done.
[snip]...removed more verbose text...[/snip]
[ 76.505432] PM: resume of devices complete after 501.892 msecs
[ 76.515197] Restarting tasks ... done.
CM_AUTOIDLE_PLL: before=0x00000009 after=0x00000009
[ 80.567687] PM: Syncing filesystems ... done.
[ 80.573822] Freezing user space processes ... (elapsed 0.01 seconds) done.
[snip]...removed more verbose text...[/snip]
[ 86.272399] PM: resume of devices complete after 501.953 msecs
[ 86.282165] Restarting tasks ... done.
Sanjeev Premi (1):
omap3: Save and restore CM_AUTOIDLE_PLL across off mode
arch/arm/mach-omap2/cm2xxx_3xxx.c | 13 +++++++++++++
arch/arm/mach-omap2/pm34xx.c | 25 ++++++++++++++++++++++++-
2 files changed, 37 insertions(+), 1 deletions(-)
--
1.7.2.2
^ permalink raw reply
* ARM: relocation out of range (when loading a module)
From: Russell King - ARM Linux @ 2011-02-10 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101270030220.8580@xanadu.home>
On Thu, Jan 27, 2011 at 12:43:54AM -0500, Nicolas Pitre wrote:
> The MMU-less kernel should still favor allocations close to the kernel
> text for modules, and anything else away from the kernel going
> downwards.
>
> Otherwise a veneer should be created by the module symbol resolver such
> that if the branch distance to reach, say, printk is too large, then the
> following code would have to be dynamically generated right next to the
> module:
>
> ldr pc, [pc, #-4]
> .word <far_away_symbol>
>
> Then, in your module, you patch the branch relocation for printk so that
> it branches to the code above instead, and then store the address of
> printk at the location represented by the .word directive.
What you're suggesting is what we used to do with the old user-space
module tools, which would've been nice to carry forwards to the new
module code. I never found a way to do it.
The problems:
1. Where do you create those veneers?
2. How many veneers do you allocate space for?
3. How do you determine that you need a veneer?
While you can say "next to the module" for (1), you can only do that at
the point in time when the space for the module is allocated, and you
need to know at that point how much space you require.
For (2), you could always allocate space for one veneer per symbol present
in the module, but that's very wasteful.
(3) is almost impossible to know ahead of time as you don't have the
relocations, realistically you have to allocate one veneer per symbol,
and as you don't know whether it's a data or code symbol, you'll have
to allocate one veneer for every symbol in a module.
I really don't like it, and I don't see that this is sanely solvable
without giving architectures much more control over module loading,
which I don't think will ever happen. It's probably simpler to build
modules with whatever that magic option is to tell GCC to always generate
'far call' veneers for everything rather than trying to 'fix' the kernel
module loader.
^ permalink raw reply
* [PATCH 4/5] ARM: scu: Move register defines to header file
From: Santosh Shilimkar @ 2011-02-10 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110207101829.GA32431@n2100.arm.linux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Monday, February 07, 2011 3:48 PM
> To: Santosh Shilimkar
> Cc: catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux-
> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> ccross at android.com
> Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header
> file
>
[....]
> > > 8<------
> > > Subject: [PATCH] ARM: smp: add function to set WFI low-power
> mode
> > > for SMP CPUs
> > >
> > > Add a function to set the SCU low-power mode for SMP CPUs. This
> > > centralizes this functionality rather than having to expose the
> > > SCU register definitions to each platform.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > > ---
> > > arch/arm/include/asm/smp_scu.h | 5 +++++
> > > arch/arm/kernel/smp_scu.c | 24 ++++++++++++++++++++++++
> > > 2 files changed, 29 insertions(+), 0 deletions(-)
> > >
[...]
> > > +int scu_power_mode(void __iomem *scu_base, unsigned int mode)
> > > +{
> > > + unsigned int val;
> > > + int cpu = smp_processor_id();
> > > + int shift;
> > shift is unused with this version now so I am removing it.
>
> Yes, I noticed that - it's gone in the version I merged into my
> tree.
This patch will need below update so that the smp_scu.h
header can be included from assembly files. Will you
fold this into your patch or you want me to
send below as separate patch ?
diff --git a/arch/arm/include/asm/smp_scu.h
b/arch/arm/include/asm/smp_scu.h
index 800860d..8895c6c 100644
--- a/arch/arm/include/asm/smp_scu.h
+++ b/arch/arm/include/asm/smp_scu.h
@@ -5,8 +5,11 @@
#define SCU_PM_DORMANT 2
#define SCU_PM_POWEROFF 3
+#ifndef __ASSEMBLER__
+
unsigned int scu_get_core_count(void __iomem *);
void scu_enable(void __iomem *);
int scu_power_mode(void __iomem *, unsigned int);
#endif
+#endif
^ permalink raw reply related
* [PATCH]ARM: mmp: add Trizeps6 board support
From: Eric Miao @ 2011-02-10 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim54zTKwhTEKF-ppq-nbtPRAYRvxH3YL0RJ4Vuc@mail.gmail.com>
>
> AC97+UCB1400: Sound and Touchscreen is ok. The related pxa2xx-ac97 files
> have to be modified, the changes are not in this patch. If u want, i can
> patch them later too.
>
If it doesn't create a building regression, you can submit the patches
later. For completeness, you may want to do this as a whole though,
and CC Mark Brown <broonie@opensource.wolfsonmicro.com> and
Liam Girdwood <lrg@slimlogic.co.uk> for the sound related patches.
Thanks
^ permalink raw reply
* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
From: Russell King - ARM Linux @ 2011-02-10 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinjAHLCMJja8q=bPhRBuoR2DCO_NjDw1qNi5MrU@mail.gmail.com>
On Thu, Feb 10, 2011 at 02:13:13PM +0000, Dave Martin wrote:
> On Thu, Feb 10, 2011 at 2:11 PM, Dave Martin <dave.martin@linaro.org> wrote:
> > Hi, apologies-- didn't see my mail for a bit.
> >
> > I get the problem with this tree and config (which builds with
> > SMP_ON_UP and THUMB2_KERNEL for omap3/4):
> >
> > Tree: git://git.linaro.org/people/dmart/linux-2.6-arm.git
> > dirty/arm/omap-thumb2+merged
> > Config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config
Thanks for the config.
> Note that this tree contains some extra patches (though I believe
> nothing is there which should cause the problem), and does not contain
> everything from rmk/devel -- so it's possible this has been fixed in
> the meantime or no longer occurs for some other reason...
No need - I now have some modules which contain SMP alternatives, so we
do need to fix the module loader for this, and keep the SMP alternatives
replacement code around. It's not worth eliminating the code as if we
include an informative printk() to say why we're refusing to load the
module, the string would be larger than the code it eliminates. So, I
think we need to merge the patch below to avoid run-time problems.
Of course, this conflicts rather badly with the p2v stuff...
arch/arm/kernel/head.S | 38 ++++++++++++++++++++++++++------------
arch/arm/kernel/module.c | 22 +++++++++++++++++++++-
2 files changed, 47 insertions(+), 13 deletions(-)
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index c0225da..f06ff9f 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -391,6 +391,7 @@ ENDPROC(__turn_mmu_on)
#ifdef CONFIG_SMP_ON_UP
+ __INIT
__fixup_smp:
and r3, r9, #0x000f0000 @ architecture version
teq r3, #0x000f0000 @ CPU ID supported?
@@ -415,18 +416,7 @@ __fixup_smp_on_up:
sub r3, r0, r3
add r4, r4, r3
add r5, r5, r3
-2: cmp r4, r5
- movhs pc, lr
- ldmia r4!, {r0, r6}
- ARM( str r6, [r0, r3] )
- THUMB( add r0, r0, r3 )
-#ifdef __ARMEB__
- THUMB( mov r6, r6, ror #16 ) @ Convert word order for big-endian.
-#endif
- THUMB( strh r6, [r0], #2 ) @ For Thumb-2, store as two halfwords
- THUMB( mov r6, r6, lsr #16 ) @ to be robust against misaligned r3.
- THUMB( strh r6, [r0] )
- b 2b
+ b __do_fixup_smp_on_up
ENDPROC(__fixup_smp)
.align
@@ -440,7 +430,31 @@ smp_on_up:
ALT_SMP(.long 1)
ALT_UP(.long 0)
.popsection
+#endif
+ .text
+__do_fixup_smp_on_up:
+ cmp r4, r5
+ movhs pc, lr
+ ldmia r4!, {r0, r6}
+ ARM( str r6, [r0, r3] )
+ THUMB( add r0, r0, r3 )
+#ifdef __ARMEB__
+ THUMB( mov r6, r6, ror #16 ) @ Convert word order for big-endian.
#endif
+ THUMB( strh r6, [r0], #2 ) @ For Thumb-2, store as two halfwords
+ THUMB( mov r6, r6, lsr #16 ) @ to be robust against misaligned r3.
+ THUMB( strh r6, [r0] )
+ b __do_fixup_smp_on_up
+ENDPROC(__do_fixup_smp_on_up)
+
+ENTRY(fixup_smp)
+ stmfd sp!, {r4 - r6, lr}
+ mov r4, r0
+ add r5, r0, r1
+ mov r3, #0
+ bl __do_fixup_smp_on_up
+ ldmfd sp!, {r4 - r6, pc}
+ENDPROC(fixup_smp)
#include "head-common.S"
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 2cfe816..6d4105e 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -22,6 +22,7 @@
#include <asm/pgtable.h>
#include <asm/sections.h>
+#include <asm/smp_plat.h>
#include <asm/unwind.h>
#ifdef CONFIG_XIP_KERNEL
@@ -268,12 +269,28 @@ struct mod_unwind_map {
const Elf_Shdr *txt_sec;
};
+static const Elf_Shdr *find_mod_section(const Elf32_Ehdr *hdr,
+ const Elf_Shdr *sechdrs, const char *name)
+{
+ const Elf_Shdr *s, *se;
+ const char *secstrs = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
+
+ for (s = sechdrs, se = sechdrs + hdr->e_shnum; s < se; s++)
+ if (strcmp(name, secstrs + s->sh_name) == 0)
+ return s;
+
+ return NULL;
+}
+
+extern void fixup_smp(const void *, unsigned long);
+
int module_finalize(const Elf32_Ehdr *hdr, const Elf_Shdr *sechdrs,
struct module *mod)
{
+ const Elf_Shdr * __maybe_unused s = NULL;
#ifdef CONFIG_ARM_UNWIND
const char *secstrs = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
- const Elf_Shdr *s, *sechdrs_end = sechdrs + hdr->e_shnum;
+ const Elf_Shdr *sechdrs_end = sechdrs + hdr->e_shnum;
struct mod_unwind_map maps[ARM_SEC_MAX];
int i;
@@ -315,6 +332,9 @@ int module_finalize(const Elf32_Ehdr *hdr, const Elf_Shdr *sechdrs,
maps[i].txt_sec->sh_addr,
maps[i].txt_sec->sh_size);
#endif
+ s = find_mod_section(hdr, sechdrs, ".alt.smp.init");
+ if (s && !is_smp())
+ fixup_smp((void *)s->sh_addr, s->sh_size);
return 0;
}
^ permalink raw reply related
* [PATCH 2/2] omap: rx51: mark reserved memory earlier
From: Felipe Contreras @ 2011-02-10 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1289568492.3297.277.camel@tubuntu>
On Fri, Nov 12, 2010 at 3:28 PM, Tomi Valkeinen
<tomi.valkeinen@nokia.com> wrote:
> On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
>> So that omap_vram_set_sdram_vram() is called before
>> omap_vram_reserve_sdram_memblock().
>
> Is this still valid after the latest memblock stuff? I presume it is.
> I'm not able to test this, and you said you didn't test it, so I'm a bit
> uneasy about applying =).
This has been tested on other boards. Can you apply?
--
Felipe Contreras
^ permalink raw reply
* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
From: Dave Martin @ 2011-02-10 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTin3+4pwxQRz1J_1B6dJxJm0_5ou0OWteDFZNbo9@mail.gmail.com>
On Thu, Feb 10, 2011 at 2:11 PM, Dave Martin <dave.martin@linaro.org> wrote:
> On Thu, Feb 10, 2011 at 12:56 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Wed, Feb 09, 2011 at 02:22:11PM +0000, Russell King - ARM Linux wrote:
>>> On Wed, Jan 26, 2011 at 05:25:35PM +0000, Dave P. Martin wrote:
>>> > SMP_ON_UP fixups lead to vmlinux link errors if those sections are
>>> > discarded at link-time. ?In particular this may happen for built-in
>>> > __exit stuff.
>>> >
>>> > This patch modifies the vmlinux linker script to reduce the amount
>>> > of discarded sections, and tries to make sure that __exit sections
>>> > are kept in.
>>> >
>>> > This is a hack and probably wrong! ?Further discussion is needed.
>>>
>>> Can you send the configuration which you see this problem with?
>>> I've tried to build a kernel which inlines the spinlocks, but I find
>>> that's not possible, so I'm doubting whether any fix is required for
>>> mainline.
>>
>> Any news on this, or can it not be reproduced?
>>
>
> Hi, apologies-- didn't see my mail for a bit.
>
> I get the problem with this tree and config (which builds with
> SMP_ON_UP and THUMB2_KERNEL for omap3/4):
>
> Tree: git://git.linaro.org/people/dmart/linux-2.6-arm.git
> dirty/arm/omap-thumb2+merged
> Config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config
Note that this tree contains some extra patches (though I believe
nothing is there which should cause the problem), and does not contain
everything from rmk/devel -- so it's possible this has been fixed in
the meantime or no longer occurs for some other reason...
Cheers
---Dave
^ permalink raw reply
* [PATCH] ARM: Avoid discarding sections that might have SMP_ON_UP fixups
From: Dave Martin @ 2011-02-10 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210125624.GA3652@n2100.arm.linux.org.uk>
On Thu, Feb 10, 2011 at 12:56 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Feb 09, 2011 at 02:22:11PM +0000, Russell King - ARM Linux wrote:
>> On Wed, Jan 26, 2011 at 05:25:35PM +0000, Dave P. Martin wrote:
>> > SMP_ON_UP fixups lead to vmlinux link errors if those sections are
>> > discarded at link-time. ?In particular this may happen for built-in
>> > __exit stuff.
>> >
>> > This patch modifies the vmlinux linker script to reduce the amount
>> > of discarded sections, and tries to make sure that __exit sections
>> > are kept in.
>> >
>> > This is a hack and probably wrong! ?Further discussion is needed.
>>
>> Can you send the configuration which you see this problem with?
>> I've tried to build a kernel which inlines the spinlocks, but I find
>> that's not possible, so I'm doubting whether any fix is required for
>> mainline.
>
> Any news on this, or can it not be reproduced?
>
Hi, apologies-- didn't see my mail for a bit.
I get the problem with this tree and config (which builds with
SMP_ON_UP and THUMB2_KERNEL for omap3/4):
Tree: git://git.linaro.org/people/dmart/linux-2.6-arm.git
dirty/arm/omap-thumb2+merged
Config: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config
I haven't identified the precise combination of options which causes
the problem, and I don't really understand what the clean solution
would be -- it's on my list of stuff to look at, but not at the top.
Other people not enabling THUMB2_KERNEL have also had the problem
(though I guess that shouldn't make a difference anyway).
I suggested a patch on the binutils mailing list to add a way for
putting fixups in separate, sensibly-named sections which would allow
for a proper fix to this class of problem, but I haven't had any
significant feedback on that ... anyway, that would not be available
on most people's toolchains for a while even if it got accepted --
see:
http://cygwin.com/ml/binutils/2011-02/msg00004.html
Cheers
---Dave
^ permalink raw reply
* [PATCH 1/2] atmel/macb: fix device name when SOFT/HARD_IRQ enabled
From: Sergei Shtylyov @ 2011-02-10 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110209144411.GB11255@game.jcrosoft.org>
Hello.
On 09-02-2011 17:44, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> From: Paul Chavent<paul.chavent@fnac.net>
>>> When listing processes on a system with SOFT/HARD_IRQ enabled,
>>> the name of the ethernet device is [irq/eth%d] (instead of [irq/eth0] for example).
>>> This patch call the request_irq function after having initialized the name of the device.
>>> Signed-off-by: Paul Chavent<paul.chavent@fnac.net>
>>> Signed-off-by: Nicolas Ferre<nicolas.ferre@atmel.com>
>>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD<plagnioj@jcrosoft.com>
>> [...]
>>> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
>>> index f69e73e..d642e08 100644
>>> --- a/drivers/net/macb.c
>>> +++ b/drivers/net/macb.c
>> [...]
>>> @@ -1219,13 +1209,23 @@ static int __init macb_probe(struct platform_device *pdev)
>>> err = register_netdev(dev);
>>> if (err) {
>>> dev_err(&pdev->dev, "Cannot register net device, aborting.\n");
>>> - goto err_out_free_irq;
>>> + goto err_out_iounmap;
>>> }
>>>
>>> - if (macb_mii_init(bp) != 0) {
>>> + dev->irq = platform_get_irq(pdev, 0);
>> platform_get_irq() can fail...
> request_irq will fail too so do we really need to check it?
You then will get the following printed:
macb: Unable to request IRQ -6 (error -22)
If this is acceptable, then platfrom_get_irq()'s result can be ignored indeed.
>>> + err = request_irq(dev->irq, macb_interrupt, IRQF_SAMPLE_RANDOM,
>>> + dev->name, dev);
> Best Regards,
> J.
WBR, Sergei
^ permalink raw reply
* [PATCH] i.MX51 iomux: Fixes MX51_PAD_UART2_TXD__UART2_TXD declaration
From: Julien Boibessot @ 2011-02-10 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210131051.GU9041@pengutronix.de>
Hi Sascha,
Sascha Hauer a ?crit :
> The patch is probably fine. Can you provide a better commit log,
> something like 'fixes uart3 on $myboard'?
>
yes, I will try :-)
> >From looking at the datasheet it is not clear to me how the current pin
> configuration bahaves. It looks like a uart tx loopback in the iomuxer.
> Is this correct?
>
Well I just reverted the setting back to what it was on 2.6.36, before
the recent MX51 iomux reorganisation.
IOMUXC_UART2_IPP_UART_RXD_MUX_SELECT_INPUT register (0x09ec) shouldn't
be used to configure UART2_TXD PAD, otherwise you overwrite current
UART2_RXD PAD config.
Current pin configuration seems to act as a kind of Tx->Rx loopback, yes.
Without my patch, my board (not mainlined yet) can't receive anything on
UART2 (used as console).
Julien
^ permalink raw reply
* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
From: Russell King - ARM Linux @ 2011-02-10 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297343555.9306.9.camel@e102109-lin.cambridge.arm.com>
On Thu, Feb 10, 2011 at 01:12:35PM +0000, Catalin Marinas wrote:
> On Thu, 2011-02-10 at 13:04 +0000, Russell King - ARM Linux wrote:
> > On Wed, Feb 09, 2011 at 10:01:33AM +0000, Catalin Marinas wrote:
> > > Could we make the domains usage a run-time feature based on the
> > > architecture version? For ARMv7, we need to have the vectors page
> > > read-only anyway if the SWP emulation is enabled (and I posted a
> > > simple patch in a reply to your email).
> > >
> > > The issue I see is that ARM11MPCore is reported as v7 though we still
> > > use domains on this processor (we could always remove the domains if
> > > TLS register is available or use some more precise architecture
> > > version identification).
> >
> > We could also do the below, which I think is more logical - SWP emulation
> > requires that CPU domains aren't enabled, so let's make that explicit
> > in the Kconfig.
>
> This may work but it is to restrictive IMHO.
At this point I really don't care - mainly because of the lack of support
from the community for sorting out these problems and testing solutions
to them.
It's the simplest solution for the corner we find ourselves in with all
this crap, and avoids any possibility of any side effects caused by having
different behaviours from the same kernel.
I've merged it into my tree and I'm intending to push it upstream. We can
then readdress it later once we have the real v6v7 crap fixed.
^ permalink raw reply
* [RFC,PATCH 1/3] Add a common struct clk
From: Russell King - ARM Linux @ 2011-02-10 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210130800.GB3316@richard-laptop>
On Thu, Feb 10, 2011 at 09:08:00PM +0800, Richard Zhao wrote:
> Why? what restriction will it cause to add parent in clk?
> Two benifits at least I can see:
> 1. null ops handle, as I said above.
> 2. export clock tree to user level for debug. It's very helpfull.
Don't be tempted to expand what's done at the generic level. Platforms
may need special handling at the current clock level before the parent
clock level is considered. Also platforms may not have parents so it
becomes mere bloat.
The more complicated the generic level becomes, the more platforms won't
covert to it.
^ permalink raw reply
* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
From: Catalin Marinas @ 2011-02-10 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110210130430.GB3652@n2100.arm.linux.org.uk>
On Thu, 2011-02-10 at 13:04 +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 09, 2011 at 10:01:33AM +0000, Catalin Marinas wrote:
> > Could we make the domains usage a run-time feature based on the
> > architecture version? For ARMv7, we need to have the vectors page
> > read-only anyway if the SWP emulation is enabled (and I posted a
> > simple patch in a reply to your email).
> >
> > The issue I see is that ARM11MPCore is reported as v7 though we still
> > use domains on this processor (we could always remove the domains if
> > TLS register is available or use some more precise architecture
> > version identification).
>
> We could also do the below, which I think is more logical - SWP emulation
> requires that CPU domains aren't enabled, so let's make that explicit
> in the Kconfig.
This may work but it is to restrictive IMHO. SWP emulation only requires
that RO user pages are also RO for the kernel. And there is a simple fix
for this:
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index ee57640..6e0b349 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -758,17 +758,21 @@ static void __init kuser_get_tls_init(unsigned long vectors)
void __init early_trap_init(void)
{
-#if defined(CONFIG_CPU_USE_DOMAINS)
- unsigned long vectors = CONFIG_VECTORS_BASE;
-#else
- unsigned long vectors = (unsigned long)vectors_page;
-#endif
+ unsigned long vectors;
extern char __stubs_start[], __stubs_end[];
extern char __vectors_start[], __vectors_end[];
extern char __kuser_helper_start[], __kuser_helper_end[];
int kuser_sz = __kuser_helper_end - __kuser_helper_start;
/*
+ * On ARMv7, user RO pages are mapped as kernel RO.
+ */
+ if (cpu_architecture() >= 7)
+ vectors = (unsigned long)vectors_page;
+ else
+ vectors = CONFIG_VECTORS_BASE;
+
+ /*
* Copy the vectors, stubs and kuser helpers (in entry-armv.S)
* into the vector page, mapped at 0xffff0000, and ensure these
* are visible to the instruction stream.
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 0c1172b..5f51592 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -146,11 +146,6 @@ ENTRY(cpu_v7_set_pte_ext)
tst r1, #L_PTE_USER
orrne r3, r3, #PTE_EXT_AP1
-#ifdef CONFIG_CPU_USE_DOMAINS
- @ allow kernel read/write access to read-only user pages
- tstne r3, #PTE_EXT_APX
- bicne r3, r3, #PTE_EXT_APX | PTE_EXT_AP0
-#endif
tst r1, #L_PTE_XN
orrne r3, r3, #PTE_EXT_XN
--
Catalin
^ permalink raw reply related
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