* for mainline -- fix pcmcia interrupts
From: Pavel Machek @ 2011-01-26 12:22 UTC (permalink / raw)
To: linux-arm-kernel
commit 08fa159003aa510027951671b94aadc380ab2d2a
Author: Eric Miao <eric.y.miao@gmail.com>
Date: Sat Dec 26 12:32:38 2009 +0800
[ARM] sa1111: avoid using hardcoded IRQ numbers for PCMCIA driver
switched ready interrupts for slot 0 and 1 by mistake. Fix that to
make CF work again.
Signed-off-by: Pavel Machek <pma@sysgo.com>
--- a/drivers/pcmcia/sa1111_generic.c
+++ b/drivers/pcmcia/sa1111_generic.c
@@ -145,8 +145,8 @@ int sa1111_pcmcia_add(struct sa1111_dev *dev, struct pcmcia_low_level *ops,
s->soc.socket.owner = ops->owner;
s->soc.socket.dev.parent = &dev->dev;
s->soc.socket.pci_irq = s->soc.nr ?
- dev->irq[IDX_IRQ_S0_READY_NINT] :
- dev->irq[IDX_IRQ_S1_READY_NINT];
+ dev->irq[IDX_IRQ_S1_READY_NINT] :
+ dev->irq[IDX_IRQ_S0_READY_NINT];
s->dev = dev;
ret = add(&s->soc);
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Russell King - ARM Linux @ 2011-01-26 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimZ9itumf=QZPD55+JA5cUOWKgwuA1_5=XsdPsP@mail.gmail.com>
On Tue, Jan 25, 2011 at 03:33:24PM -0800, Colin Cross wrote:
> I think there is an additional change needed to
> __und_usr_unknown/do_undefinstr. do_undefinstr, which gets called
> directly in __und_usr as well as by mov pc, lr, expects regs->ARM_pc
> to be the fault address, and not the next PC, and gets called for 2 or
> 4 byte instructions.
It expects it to be the next PC:
asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
{
unsigned int correction = thumb_mode(regs) ? 2 : 4;
unsigned int instr;
siginfo_t info;
void __user *pc;
/*
* According to the ARM ARM, PC is 2 or 4 bytes ahead,
* depending whether we're in Thumb mode or not.
* Correct this offset.
*/
regs->ARM_pc -= correction;
We expect the PC to be pointing at the next instruction to be executed.
This is the value of the PC saved by the CPU when entering the exception.
We correct the PC by four bytes for ARM mode to point at the previously
executed instruction.
For 16-bit Thumb mode, the PC is again pointing at the next instruction
to be executed, and this is the value saved by the CPU. So we correct
the PC by two bytes as that is the Thumb instruction size.
The problem comes with T2, where we advance the saved PC by two bytes
if the instruction was 32-bit such that it again points at the next
instruction to be executed. This is where the problem comes in because
we have two different chunks of code with completely different
expectations.
Maybe we need to pass in the correction factor to do_undefinstr instead.
^ permalink raw reply
* SDMA on imx35
From: Alexander Stein @ 2011-01-26 11:24 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I'm currently fiddling on SDMA support for the uart driver on my imx35 rev2.
TX is working great, no problems so far. But on RX I never get the SDMA
interrupt that the request has been processed.
So I'm wondering if the UART-DMS-Script in ROM is actually working. Has
anybody get this to work (doesn't matter if linux-2.6 from git or kernel from
freescale)?
Best regards,
Alexander
^ permalink raw reply
* [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
From: Dave Martin @ 2011-01-26 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101251618230.8580@xanadu.home>
On Tue, Jan 25, 2011 at 9:21 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:
>
>> On Tue, Jan 25, 2011 at 05:33:14PM +0000, Dave Martin wrote:
>> > On Tue, Jan 25, 2011 at 4:59 PM, Russell King - ARM Linux
>> > <linux@arm.linux.org.uk> wrote:
>> > > On Tue, Jan 25, 2011 at 04:43:52PM +0000, Dave Martin wrote:
>> > >> A couple of questions on this:
>> > >>
>> > >> 1) I notice these spinlock functions are generally marked inline.
>> > >>
>> > >> Is that likely to happen in modules? ?If so, there would be a need to
>> > >> do SMP_ON_UP fixups at module load time -- I don't think that's
>> > >> currently implemented.
>> > >
>> > > No one should be using the arch_* spinlocks directly. ?The spinlocks
>> > > are implemented in out of line code in kernel/spinlock.c
>> >
>> > OK--- do think this is something we need a sanity-check for, or does
>> > this fall into to a category of bad driver implementation which will
>> > get thrown out during peer review?
>>
>> Hmm, actually it looks like you can end up with configurations where the
>> spinlocks are inlined.
>>
>> That means we'll have to get rid of the link-time discarding of the
>> .exit sections, and discard them along with the .init sections.
>
> ... but only when CONFIG_SMP_ON_UP=y.
>
>
> Nicolas
Do we need to consider any other discarded sections? In vmlinux.lds, I have:
/* Default discards */
/DISCARD/ : { *(.exit.text) *(.cpuexit.text) *(.memexit.text)
*(.exit.data) *(.cpuexit.data) *(.cpuexit.rodata) *(.memexit.data)
*(.memexit.rodata) *(.exitcall.exit) *(.discard) *(.discard.*) }
Alternatively, I wonder .alt.smp.init could make weak references
instead of normal references: then if the referenced section is
discarded, the reference will revert to 0 and the fixup code can
ignore it (at the expense of wasting a bit of space in the fixup table
... but it's no worse than the current situation). From
experimentation, it seems this doesn't work if the referenced symbol
is defined in the same file, since the linker resolves the reference
before discarding sections, but maybe there's a way around it...
This does rely on generating a globally unique symbol name for every
fixup ... we can come close using KBUILD_MODNAME, __LINE__ and/or the
assembler macro widget \@. But I think that KBUILD_MODNAME doesn't
take the file path into account so may not really be globally unique.
If we put every fixup in its own _section_ we might be able to
collapse those out of the list at link time too. However, that seems
hard to achieve, since in order to do the correct link-time filtering
we would need the fixup's section name to be based on the referenced
section's name ... due to preprocessor limitations I don't think we
can do that automatically (and manual maintenance would be a bad
plan).
Cheers
---Dave
^ permalink raw reply
* Message awaiting admin approval...
From: Jorge S. @ 2011-01-26 10:39 UTC (permalink / raw)
To: linux-arm-kernel
Hello:
I've just send a message to the list 2 days ago, and received a reply with
the following reason:
Message has a suspicious header
Could somebody tell me what exactly does it mean? i've sent it from my
e-mail account, with a descriptive subject, not giving any url or something
else, just a few questions...so i think i've triggered a false positive on
some filter :?
Thanks in advance,
Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110126/f950642a/attachment-0001.html>
^ permalink raw reply
* [PATCH] ARM: OMAP2: use early init hook
From: Russell King - ARM Linux @ 2011-01-26 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110126091103.GE1147@pengutronix.de>
On Wed, Jan 26, 2011 at 10:11:03AM +0100, Uwe Kleine-K?nig wrote:
> On Wed, Jan 26, 2011 at 08:52:40AM +0000, Russell King - ARM Linux wrote:
> > On Wed, Jan 26, 2011 at 09:46:13AM +0100, Uwe Kleine-K?nig wrote:
> > > Will you care for imx (mach-{mx*,imx}), too, or should I fix them up?
> >
> > Does mx stuff do non-irq setup or non-map_io stuff in those callbacks?
> the map_io callbacks (e.g. mx27_map_io) setup the infrastructure for
> cpu_is_xyz and arch_reset.
In which case yes please.
^ permalink raw reply
* [PATCH] ARM:ucb1x00-ts: Fix NULL pointer due to non-initialized absinfo
From: Jochen Friedrich @ 2011-01-26 10:30 UTC (permalink / raw)
To: linux-arm-kernel
Call input_set_abs_params instead of manually setting absbit only.
This fixes this oops:
Unable to handle kernel NULL pointer dereference at virtual address 00000024
Internal error: Oops: 41b67017 [#1]
CPU: 0 Not tainted (2.6.37 #4)
pc : [<c016d1fc>] lr : [<00000000>] psr: 20000093
sp : c19e5f30 ip : c19e5e6c fp : c19e5f58
r10: 00000000 r9 : c19e4000 r8 : 00000003
r7 : 000001e4 r6 : 00000001 r5 : c1854400 r4 : 00000003
r3 : 00000018 r2 : 00000018 r1 : 00000018 r0 : c185447c
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: c1b6717f Table: c1b6717f DAC: 00000017
Stack: (0xc19e5f30 to 0xc19e6000)
5f20: 00000003 00000003 c1854400 00000013
5f40: 00000001 000001e4 000001c5 c19e5f80 c19e5f5c c016d5e8 c016cf5c 000001e4
5f60: c1854400 c18b5860 00000000 00000171 000001e4 c19e5fc4 c19e5f84 c01559a4
5f80: c016d584 c18b5868 00000000 c1bb5c40 c0035afc c18b5868 c18b5868 c1a55d54
5fa0: c18b5860 c0155750 00000013 00000000 00000000 00000000 c19e5ff4 c19e5fc8
5fc0: c0050174 c015575c 00000000 c18b5860 00000000 c19e5fd4 c19e5fd4 c1a55d54
5fe0: c00500f0 c003b464 00000000 c19e5ff8 c003b464 c00500fc 04000400 04000400
Backtrace:
Function entered at [<c016cf50>] from [<c016d5e8>]
Function entered at [<c016d578>] from [<c01559a4>]
r8:000001e4 r7:00000171 r6:00000000 r5:c18b5860 r4:c1854400
Function entered at [<c0155750>] from [<c0050174>]
Function entered at [<c00500f0>] from [<c003b464>]
r6:c003b464 r5:c00500f0 r4:c1a55d54
Code: e59520fc e1a03286 e0433186 e0822003 (e592000c)
>>PC; c016d1fc <input_handle_event+2ac/5a0> <=====
Trace; c016cf50 <input_handle_event+0/5a0>
Trace; c016d5e8 <input_event+70/88>
Trace; c016d578 <input_event+0/88>
Trace; c01559a4 <ucb1x00_thread+254/2dc>
Trace; c0155750 <ucb1x00_thread+0/2dc>
Trace; c0050174 <kthread+84/8c>
Trace; c00500f0 <kthread+0/8c>
Trace; c003b464 <do_exit+0/624>
Signed-off-by: Jochen Friedrich <jochen@scram.de>
CC: stable at kernel.org
---
drivers/mfd/ucb1x00-ts.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/ucb1x00-ts.c b/drivers/mfd/ucb1x00-ts.c
index 000cb41..92b85e2 100644
--- a/drivers/mfd/ucb1x00-ts.c
+++ b/drivers/mfd/ucb1x00-ts.c
@@ -385,12 +385,18 @@ static int ucb1x00_ts_add(struct ucb1x00_dev *dev)
idev->close = ucb1x00_ts_close;
__set_bit(EV_ABS, idev->evbit);
- __set_bit(ABS_X, idev->absbit);
- __set_bit(ABS_Y, idev->absbit);
- __set_bit(ABS_PRESSURE, idev->absbit);
input_set_drvdata(idev, ts);
+ ucb1x00_adc_enable(ts->ucb);
+ ts->x_res = ucb1x00_ts_read_xres(ts);
+ ts->y_res = ucb1x00_ts_read_yres(ts);
+ ucb1x00_adc_disable(ts->ucb);
+
+ input_set_abs_params(idev, ABS_X, 0, ts->x_res, 0, 0);
+ input_set_abs_params(idev, ABS_Y, 0, ts->y_res, 0, 0);
+ input_set_abs_params(idev, ABS_PRESSURE, 0, 0, 0, 0);
+
err = input_register_device(idev);
if (err)
goto fail;
--
1.7.2.3
^ permalink raw reply related
* [PATCH] ARM: OMAP2: use early init hook
From: Poddar, Sourav @ 2011-01-26 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110125192836.GP13589@atomide.com>
On Wed, Jan 26, 2011 at 12:58 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Poddar, Sourav <sourav.poddar@ti.com> [110125 07:45]:
>>
>> Just FYI, I observed similar results on OMAP4 for these patches.
>> For OMAP2420, OMAP2430 and OMAP3430 SDPs, you can add my boot
>> Tested-by: Sourav Poddar<sourav.poddar@ti.com>
>
> Thanks, just posted third patch to this thread that fixes things
> for omap4, care to give that a try too?
>
I applied the third patch and now its booting
fine for OMAP4 also. :)
Tested-by: Sourav Poddar<sourav.poddar@ti.com>
^ permalink raw reply
* [PATCH] ARM: add PrimeCell generic DMA to MMCI/PL180
From: Russell King - ARM Linux @ 2011-01-26 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=kMnXm+VU2V8HR98DhL1wVk6cJJQ0DtkV=yFqs@mail.gmail.com>
On Tue, Jan 25, 2011 at 09:33:07AM +0100, Linus Walleij wrote:
> On 24 January 2011 22:22, Russell King - ARM Linux
> <linux@arm.linux.org.uk>wrote:
> > On Mon, Jan 24, 2011 at 10:06:53PM +0100, Linus Walleij wrote:
> > > What it does is to emulate single requests below a certain
> > > threshold by requesting one-word bursts. I think this is
> > > primarily for SDIO, not card transfers.
> >
> > This should be handled in hardware, if not it's DMA controller specific
> > as it shouldn't burst past the remainder of the transfer. If your DMA
> > controller does burst past the number of bytes in the transfer, surely
> > that's something that your DMA controller code needs to work around?
>
> Yes that indeed seems resonable. With the COH901318 DMA engine
> it worked just fine without the burst threshold. Just want to give my
> colleagues a chance to have a second opinion on this.
I've left this in, but noted a todo item in the commit message to remove
this.
I'd like to remove this, and then propose that DMA slave drivers should
store the entire channel configuration (and we drop the direction argument)
rather than picking out the source/destination parts of the structure so
we can avoid calling the DMA configuration function on every DMA request.
It'd also be less susceptible to mismatches between the configured direction
and the direction passed into the prep_dma_slave_sg() function (which I
think should be responsible for picking the configuration from the
dma_slave_config structure.)
> > > The original intent was to avoid writing anything than 32bit words
> > > into the register, and with the SDIO-modified versions you can
> > > actually do that.
> >
> > Surely that's to do with the DMA controller though?
>
> Absolutely.
So shouldn't this be in the DMA engine driver, so that prep_dma_slave_sg()
returns NULL if the scatterlist is unsuitable?
Here's the current patch, rebased on top of the blockend removal stuff.
8<------
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
Subject: [PATCH] ARM: MMCI: add dmaengine-based DMA support
Based on a patch from Linus Walleij.
Add dmaengine based support for DMA to the MMCI driver, using the
Primecell DMA engine interface. The changes over Linus' driver are:
- rename txsize_threshold to dmasize_threshold, as this reflects the
purpose more.
- use 'mmci_dma_' as the function prefix rather than 'dma_mmci_'.
- clean up requesting of dma channels.
- don't release a single channel twice when it's shared between tx and rx.
- get rid of 'dma_enable' bool - instead check whether the channel is NULL.
- detect incomplete DMA at the end of a transfer. Some DMA controllers
(eg, PL08x) are unable to be configured for scatter DMA and also listen
to all four DMA request signals [BREQ,SREQ,LBREQ,LSREQ] from the MMCI.
They can do one or other but not both. As MMCI uses LBREQ/LSREQ for the
final burst/words, PL08x does not transfer the last few words.
- map and unmap DMA buffers using the DMA engine struct device, not the
MMCI struct device - the DMA engine is doing the DMA transfer, not us.
- avoid double-unmapping of the DMA buffers on MMCI data errors.
- don't check for negative values from the dmaengine tx submission
function - Dan says this must never fail.
- use new dmaengine helper functions rather than using the ugly function
pointers directly.
- allow DMA code to be fully optimized away using dma_inprogress() which
is defined to constant 0 if DMA engine support is disabled.
- request maximum segment size from the DMA engine struct device and
set this appropriately.
- removed checking of buffer alignment - the DMA engine should deal with
its own restrictions on buffer alignment, not the individual DMA engine
users.
TODO: remove burst setting
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/mmc/host/mmci.c | 296 +++++++++++++++++++++++++++++++++++++++++++--
drivers/mmc/host/mmci.h | 13 ++
include/linux/amba/mmci.h | 17 +++
3 files changed, 316 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 2de12fe..3eaeed1 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -2,7 +2,7 @@
* linux/drivers/mmc/host/mmci.c - ARM PrimeCell MMCI PL180/1 driver
*
* Copyright (C) 2003 Deep Blue Solutions, Ltd, All Rights Reserved.
- * Copyright (C) 2010 ST-Ericsson AB.
+ * Copyright (C) 2010 ST-Ericsson SA
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -24,8 +24,10 @@
#include <linux/clk.h>
#include <linux/scatterlist.h>
#include <linux/gpio.h>
-#include <linux/amba/mmci.h>
#include <linux/regulator/consumer.h>
+#include <linux/dmaengine.h>
+#include <linux/dma-mapping.h>
+#include <linux/amba/mmci.h>
#include <asm/div64.h>
#include <asm/io.h>
@@ -41,20 +43,26 @@ static unsigned int fmax = 515633;
* struct variant_data - MMCI variant-specific quirks
* @clkreg: default value for MCICLOCK register
* @clkreg_enable: enable value for MMCICLOCK register
+ * @dmareg_enable: enable value for MMCIDATACTRL register
* @datalength_bits: number of bits in the MMCIDATALENGTH register
* @fifosize: number of bytes that can be written when MMCI_TXFIFOEMPTY
* is asserted (likewise for RX)
* @fifohalfsize: number of bytes that can be written when MCI_TXFIFOHALFEMPTY
* is asserted (likewise for RX)
+ * @dmasize_threshold: Sets DMA burst size to minimal if transfer size is
+ * less or equal to this threshold. This shall be specified in
+ * number of bytes. Set 0 for no burst compensation
* @sdio: variant supports SDIO
* @st_clkdiv: true if using a ST-specific clock divider algorithm
*/
struct variant_data {
unsigned int clkreg;
unsigned int clkreg_enable;
+ unsigned int dmareg_enable;
unsigned int datalength_bits;
unsigned int fifosize;
unsigned int fifohalfsize;
+ unsigned int dmasize_threshold;
bool sdio;
bool st_clkdiv;
};
@@ -76,8 +84,10 @@ static struct variant_data variant_u300 = {
static struct variant_data variant_ux500 = {
.fifosize = 30 * 4,
.fifohalfsize = 8 * 4,
+ .dmasize_threshold = 16,
.clkreg = MCI_CLK_ENABLE,
.clkreg_enable = 1 << 14, /* HWFCEN */
+ .dmareg_enable = 1 << 12, /* DMAREQCTRL */
.datalength_bits = 24,
.sdio = true,
.st_clkdiv = true,
@@ -188,6 +198,251 @@ static void mmci_init_sg(struct mmci_host *host, struct mmc_data *data)
sg_miter_start(&host->sg_miter, data->sg, data->sg_len, flags);
}
+/*
+ * All the DMA operation mode stuff goes inside this ifdef.
+ * This assumes that you have a generic DMA device interface,
+ * no custom DMA interfaces are supported.
+ */
+#ifdef CONFIG_DMA_ENGINE
+static void __devinit mmci_dma_setup(struct mmci_host *host)
+{
+ struct mmci_platform_data *plat = host->plat;
+ const char *rxname, *txname;
+ dma_cap_mask_t mask;
+
+ if (!plat || !plat->dma_filter) {
+ dev_info(mmc_dev(host->mmc), "no DMA platform data\n");
+ return;
+ }
+
+ /* Try to acquire a generic DMA engine slave channel */
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_SLAVE, mask);
+
+ /*
+ * If only an RX channel is specified, the driver will
+ * attempt to use it bidirectionally, however if it is
+ * is specified but cannot be located, DMA will be disabled.
+ */
+ if (plat->dma_rx_param) {
+ host->dma_rx_channel = dma_request_channel(mask,
+ plat->dma_filter,
+ plat->dma_rx_param);
+ /* E.g if no DMA hardware is present */
+ if (!host->dma_rx_channel)
+ dev_err(mmc_dev(host->mmc), "no RX DMA channel\n");
+ }
+
+ if (plat->dma_tx_param) {
+ host->dma_tx_channel = dma_request_channel(mask,
+ plat->dma_filter,
+ plat->dma_tx_param);
+ if (!host->dma_tx_channel)
+ dev_warn(mmc_dev(host->mmc), "no TX DMA channel\n");
+ } else {
+ host->dma_tx_channel = host->dma_rx_channel;
+ }
+
+ if (host->dma_rx_channel)
+ rxname = dma_chan_name(host->dma_rx_channel);
+ else
+ rxname = "none";
+
+ if (host->dma_tx_channel)
+ txname = dma_chan_name(host->dma_tx_channel);
+ else
+ txname = "none";
+
+ dev_info(mmc_dev(host->mmc), "DMA channels RX %s, TX %s\n",
+ rxname, txname);
+
+ /*
+ * Limit the maximum segment size in any SG entry according to
+ * the parameters of the DMA engine device.
+ */
+ if (host->dma_tx_channel) {
+ struct device *dev = host->dma_tx_channel->device->dev;
+ unsigned int max_seg_size = dma_get_max_seg_size(dev);
+
+ if (max_seg_size < host->mmc->max_seg_size)
+ host->mmc->max_seg_size = max_seg_size;
+ }
+ if (host->dma_rx_channel) {
+ struct device *dev = host->dma_rx_channel->device->dev;
+ unsigned int max_seg_size = dma_get_max_seg_size(dev);
+
+ if (max_seg_size < host->mmc->max_seg_size)
+ host->mmc->max_seg_size = max_seg_size;
+ }
+}
+
+/*
+ * This is used in __devinit or __devexit so inline it
+ * so it can be discarded.
+ */
+static inline void mmci_dma_release(struct mmci_host *host)
+{
+ struct mmci_platform_data *plat = host->plat;
+
+ if (host->dma_rx_channel)
+ dma_release_channel(host->dma_rx_channel);
+ if (host->dma_tx_channel && plat->dma_tx_param)
+ dma_release_channel(host->dma_tx_channel);
+ host->dma_rx_channel = host->dma_tx_channel = NULL;
+}
+
+static void mmci_dma_unmap(struct mmci_host *host, struct mmc_data *data)
+{
+ struct dma_chan *chan = host->dma_current;
+ enum dma_data_direction dir;
+ u32 status;
+ int i;
+
+ /* Wait up to 1ms for the DMA to complete */
+ for (i = 0; ; i++) {
+ status = readl(host->base + MMCISTATUS);
+ if (!(status & MCI_RXDATAAVLBLMASK) || i >= 100)
+ break;
+ udelay(10);
+ }
+
+ /*
+ * Check to see whether we still have some data left in the FIFO -
+ * this catches DMA controllers which are unable to monitor the
+ * DMALBREQ and DMALSREQ signals while allowing us to DMA to non-
+ * contiguous buffers. On TX, we'll get a FIFO underrun error.
+ */
+ if (status & MCI_RXDATAAVLBLMASK) {
+ dmaengine_terminate_all(chan);
+ data->error = -EIO;
+ }
+
+ if (data->flags & MMC_DATA_WRITE) {
+ dir = DMA_TO_DEVICE;
+ } else {
+ dir = DMA_FROM_DEVICE;
+ }
+
+ dma_unmap_sg(chan->device->dev, data->sg, data->sg_len, dir);
+
+ /*
+ * Use of DMA with scatter-gather is impossible.
+ * Give up with DMA and switch back to PIO mode.
+ */
+ if (status & MCI_RXDATAAVLBLMASK) {
+ dev_err(mmc_dev(host->mmc), "buggy DMA detected. Taking evasive action.\n");
+ mmci_dma_release(host);
+ }
+}
+
+static void mmci_dma_data_error(struct mmci_host *host)
+{
+ dev_err(mmc_dev(host->mmc), "error during DMA transfer!\n");
+ dmaengine_terminate_all(host->dma_current);
+}
+
+static int mmci_dma_start_data(struct mmci_host *host, unsigned int datactrl)
+{
+ struct variant_data *variant = host->variant;
+ struct dma_slave_config conf = {
+ .src_addr = host->phybase + MMCIFIFO,
+ .dst_addr = host->phybase + MMCIFIFO,
+ .src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .src_maxburst = variant->fifohalfsize >> 2, /* # of words */
+ .dst_maxburst = variant->fifohalfsize >> 2, /* # of words */
+ };
+ struct mmc_data *data = host->data;
+ struct dma_chan *chan;
+ struct dma_device *device;
+ struct dma_async_tx_descriptor *desc;
+ struct scatterlist *sg;
+ int i, nr_sg;
+
+ host->dma_current = NULL;
+
+ if (data->flags & MMC_DATA_READ) {
+ conf.direction = DMA_FROM_DEVICE;
+ chan = host->dma_rx_channel;
+ } else {
+ conf.direction = DMA_TO_DEVICE;
+ chan = host->dma_tx_channel;
+ }
+
+ /* If there's no DMA channel, fall back to PIO */
+ if (!chan)
+ return -EINVAL;
+
+ /* shouldn't this be in the DMA engine driver? */
+ if (host->size <= variant->dmasize_threshold) {
+ conf.src_maxburst = 1;
+ conf.dst_maxburst = 1;
+ }
+
+ device = chan->device;
+ nr_sg = dma_map_sg(device->dev, data->sg, data->sg_len, conf.direction);
+ if (nr_sg == 0)
+ return -EINVAL;
+
+ dmaengine_slave_config(chan, &conf);
+ desc = device->device_prep_slave_sg(chan, data->sg, nr_sg,
+ conf.direction, DMA_CTRL_ACK);
+ if (!desc)
+ goto unmap_exit;
+
+ /* Okay, go for it. */
+ host->dma_current = chan;
+
+ dev_vdbg(mmc_dev(host->mmc),
+ "Submit MMCI DMA job, sglen %d blksz %04x blks %04x flags %08x\n",
+ data->sg_len, data->blksz, data->blocks, data->flags);
+ dmaengine_submit(desc);
+ dma_async_issue_pending(chan);
+
+ datactrl |= MCI_DPSM_DMAENABLE;
+ datactrl |= variant->dmareg_enable;
+
+ /* Trigger the DMA transfer */
+ writel(datactrl, host->base + MMCIDATACTRL);
+
+ /*
+ * Let the MMCI say when the data is ended and it's time
+ * to fire next DMA request. When that happens, MMCI will
+ * call mmci_data_end()
+ */
+ writel(readl(host->base + MMCIMASK0) | MCI_DATAENDMASK,
+ host->base + MMCIMASK0);
+ return 0;
+
+unmap_exit:
+ dmaengine_terminate_all(chan);
+ dma_unmap_sg(device->dev, data->sg, data->sg_len, conf.direction);
+ return -ENOMEM;
+}
+#else
+/* Blank functions if the DMA engine is not available */
+static inline void mmci_dma_setup(struct mmci_host *host)
+{
+}
+
+static inline void mmci_dma_release(struct mmci_host *host)
+{
+}
+
+static inline void mmci_dma_unmap(struct mmci_host *host, struct mmc_data *data)
+{
+}
+
+static inline void mmci_dma_data_error(struct mmci_host *host)
+{
+}
+
+static inline int mmci_dma_start_data(struct mmci_host *host, unsigned int datactrl)
+{
+ return -ENOSYS;
+}
+#endif
+
static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
{
struct variant_data *variant = host->variant;
@@ -203,8 +458,6 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
host->size = data->blksz * data->blocks;
host->data_xfered = 0;
- mmci_init_sg(host, data);
-
clks = (unsigned long long)data->timeout_ns * host->cclk;
do_div(clks, 1000000000UL);
@@ -218,8 +471,21 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
BUG_ON(1 << blksz_bits != data->blksz);
datactrl = MCI_DPSM_ENABLE | blksz_bits << 4;
- if (data->flags & MMC_DATA_READ) {
+
+ if (data->flags & MMC_DATA_READ)
datactrl |= MCI_DPSM_DIRECTION;
+
+ /*
+ * Attempt to use DMA operation mode, if this
+ * should fail, fall back to PIO mode
+ */
+ if (!mmci_dma_start_data(host, datactrl))
+ return;
+
+ /* IRQ mode, map the SG list for CPU reading/writing */
+ mmci_init_sg(host, data);
+
+ if (data->flags & MMC_DATA_READ) {
irqmask = MCI_RXFIFOHALFFULLMASK;
/*
@@ -301,9 +567,12 @@ mmci_data_irq(struct mmci_host *host, struct mmc_data *data,
/*
* We hit an error condition. Ensure that any data
- * partially written to a page is properly coherent.
+ * partially written to a page is properly coherent,
+ * unless we're using DMA.
*/
- if (data->flags & MMC_DATA_READ) {
+ if (dma_inprogress(host))
+ mmci_dma_data_error(host);
+ else if (data->flags & MMC_DATA_READ) {
struct sg_mapping_iter *sg_miter = &host->sg_miter;
unsigned long flags;
@@ -320,6 +589,8 @@ mmci_data_irq(struct mmci_host *host, struct mmc_data *data,
dev_err(mmc_dev(host->mmc), "stray MCI_DATABLOCKEND interrupt\n");
if (status & MCI_DATAEND) {
+ if (dma_inprogress(host))
+ mmci_dma_unmap(host, data);
mmci_stop_data(host);
if (!data->error)
@@ -775,6 +1046,7 @@ static int __devinit mmci_probe(struct amba_device *dev, struct amba_id *id)
dev_dbg(mmc_dev(mmc), "eventual mclk rate: %u Hz\n",
host->mclk);
}
+ host->phybase = dev->res.start;
host->base = ioremap(dev->res.start, resource_size(&dev->res));
if (!host->base) {
ret = -ENOMEM;
@@ -902,9 +1174,12 @@ static int __devinit mmci_probe(struct amba_device *dev, struct amba_id *id)
amba_set_drvdata(dev, mmc);
- dev_info(&dev->dev, "%s: PL%03x rev%u at 0x%08llx irq %d,%d\n",
- mmc_hostname(mmc), amba_part(dev), amba_rev(dev),
- (unsigned long long)dev->res.start, dev->irq[0], dev->irq[1]);
+ dev_info(&dev->dev, "%s: PL%03x manf %x rev%u at 0x%08llx irq %d,%d (pio)\n",
+ mmc_hostname(mmc), amba_part(dev), amba_manf(dev),
+ amba_rev(dev), (unsigned long long)dev->res.start,
+ dev->irq[0], dev->irq[1]);
+
+ mmci_dma_setup(host);
mmc_add_host(mmc);
@@ -951,6 +1226,7 @@ static int __devexit mmci_remove(struct amba_device *dev)
writel(0, host->base + MMCICOMMAND);
writel(0, host->base + MMCIDATACTRL);
+ mmci_dma_release(host);
free_irq(dev->irq[0], host);
if (!host->singleirq)
free_irq(dev->irq[1], host);
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index c1df7b8..9626f51 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -148,8 +148,10 @@
struct clk;
struct variant_data;
+struct dma_chan;
struct mmci_host {
+ phys_addr_t phybase;
void __iomem *base;
struct mmc_request *mrq;
struct mmc_command *cmd;
@@ -181,5 +183,16 @@ struct mmci_host {
struct sg_mapping_iter sg_miter;
unsigned int size;
struct regulator *vcc;
+
+#ifdef CONFIG_DMA_ENGINE
+ /* DMA stuff */
+ struct dma_chan *dma_current;
+ struct dma_chan *dma_rx_channel;
+ struct dma_chan *dma_tx_channel;
+
+#define dma_inprogress(host) ((host)->dma_current)
+#else
+#define dma_inprogress(host) (0)
+#endif
};
diff --git a/include/linux/amba/mmci.h b/include/linux/amba/mmci.h
index f4ee9ac..f602270 100644
--- a/include/linux/amba/mmci.h
+++ b/include/linux/amba/mmci.h
@@ -6,6 +6,9 @@
#include <linux/mmc/host.h>
+/* Just some dummy forwarding */
+struct dma_chan;
+
/**
* struct mmci_platform_data - platform configuration for the MMCI
* (also known as PL180) block.
@@ -27,6 +30,17 @@
* @cd_invert: true if the gpio_cd pin value is active low
* @capabilities: the capabilities of the block as implemented in
* this platform, signify anything MMC_CAP_* from mmc/host.h
+ * @dma_filter: function used to select an apropriate RX and TX
+ * DMA channel to be used for DMA, if and only if you're deploying the
+ * generic DMA engine
+ * @dma_rx_param: parameter passed to the DMA allocation
+ * filter in order to select an apropriate RX channel. If
+ * there is a bidirectional RX+TX channel, then just specify
+ * this and leave dma_tx_param set to NULL
+ * @dma_tx_param: parameter passed to the DMA allocation
+ * filter in order to select an apropriate TX channel. If this
+ * is NULL the driver will attempt to use the RX channel as a
+ * bidirectional channel
*/
struct mmci_platform_data {
unsigned int f_max;
@@ -38,6 +52,9 @@ struct mmci_platform_data {
int gpio_cd;
bool cd_invert;
unsigned long capabilities;
+ bool (*dma_filter)(struct dma_chan *chan, void *filter_param);
+ void *dma_rx_param;
+ void *dma_tx_param;
};
#endif
--
1.6.2.5
^ permalink raw reply related
* [PATCH] OMAP3: PM: fix save secure RAM to restore MPU power state
From: Tero.Kristo at nokia.com @ 2011-01-26 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296003011-26427-1-git-send-email-khilman@ti.com>
>-----Original Message-----
>From: ext Kevin Hilman [mailto:khilman at ti.com]
>Sent: 26 January, 2011 02:50
>To: linux-omap at vger.kernel.org
>Cc: linux-arm-kernel at lists.infradead.org; Kristo Tero (Nokia-MS/Tampere)
>Subject: [PATCH] OMAP3: PM: fix save secure RAM to restore MPU power
>state
>
>Currently, on HS/EMU devices, MPU power state forced to on during PM
>init by the save secure RAM code. Rather than forcing the state of
>MPU powerdomain to on, simply read the current value and restore it
>after the ROM code has run.
>
>This only affects the !CPUidle case since when CPUidle is enabled, the
>MPU power state is dynamically changed by CPUidle. In the !CPUidle
>case, MPU power state is initialized once at init and never touched.
>
>Cc: Tero Kristo <tero.kristo@nokia.com>
>Signed-off-by: Kevin Hilman <khilman@ti.com>
>---
>If no objectsions, will be queued in my pm-fixes branch for 2.6.38-rc.
Looks good to me. Ack, if you need one.
>
> arch/arm/mach-omap2/pm34xx.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
>diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>index 8cbbead..1916038 100644
>--- a/arch/arm/mach-omap2/pm34xx.c
>+++ b/arch/arm/mach-omap2/pm34xx.c
>@@ -168,9 +168,10 @@ static void omap3_core_restore_context(void)
> * once during boot sequence, but this works as we are not using secure
> * services.
> */
>-static void omap3_save_secure_ram_context(u32 target_mpu_state)
>+static void omap3_save_secure_ram_context(void)
> {
> u32 ret;
>+ int mpu_next_state = pwrdm_read_next_pwrst(mpu_pwrdm);
>
> if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
> /*
>@@ -181,7 +182,7 @@ static void omap3_save_secure_ram_context(u32
>target_mpu_state)
> pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
> ret = _omap_save_secure_sram((u32 *)
> __pa(omap3_secure_ram_storage));
>- pwrdm_set_next_pwrst(mpu_pwrdm, target_mpu_state);
>+ pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
> /* Following is for error tracking, it should not happen */
> if (ret) {
> printk(KERN_ERR "save_secure_sram() returns %08x\n",
>@@ -1094,7 +1095,7 @@ static int __init omap3_pm_init(void)
> local_fiq_disable();
>
> omap_dma_global_context_save();
>- omap3_save_secure_ram_context(PWRDM_POWER_ON);
>+ omap3_save_secure_ram_context();
> omap_dma_global_context_restore();
>
> local_irq_enable();
>--
>1.7.3.5
^ permalink raw reply
* [PATCH] ARM: add PrimeCell generic DMA to MMCI/PL180
From: Russell King - ARM Linux @ 2011-01-26 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=kMnXm+VU2V8HR98DhL1wVk6cJJQ0DtkV=yFqs@mail.gmail.com>
On Tue, Jan 25, 2011 at 09:33:07AM +0100, Linus Walleij wrote:
> In any case I'm happy if you post/commit the MMCI support
> you have, if there are problems we can certainly sort it out later
> in any case.
>
> Hm, does this mean you got it working with one of the
> reference boards eventually?
Nope. ARM reference boards all seem to have broken DMA. I've given up
with the idea of getting DMA working on any of these platforms, and as
yet I've not had a response from the ARM Support request which Catalin
logged for me on this subject.
I don't believe it is possible for MMCI to ever work correctly with DMA
on ARM development platforms.
^ permalink raw reply
* [PATCH] ARM: OMAP2: use early init hook
From: Uwe Kleine-König @ 2011-01-26 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110126085240.GA2698@n2100.arm.linux.org.uk>
On Wed, Jan 26, 2011 at 08:52:40AM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 26, 2011 at 09:46:13AM +0100, Uwe Kleine-K?nig wrote:
> > Will you care for imx (mach-{mx*,imx}), too, or should I fix them up?
>
> Does mx stuff do non-irq setup or non-map_io stuff in those callbacks?
the map_io callbacks (e.g. mx27_map_io) setup the infrastructure for
cpu_is_xyz and arch_reset.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] ARM: OMAP2: use early init hook
From: Russell King - ARM Linux @ 2011-01-26 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110126084613.GD1147@pengutronix.de>
On Wed, Jan 26, 2011 at 09:46:13AM +0100, Uwe Kleine-K?nig wrote:
> Will you care for imx (mach-{mx*,imx}), too, or should I fix them up?
Does mx stuff do non-irq setup or non-map_io stuff in those callbacks?
^ permalink raw reply
* [PATCH 2/2] dma: ipu_idmac: do not lose valid received data in the irq handler
From: Anatolij Gustschin @ 2011-01-26 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296031789-1721-1-git-send-email-agust@denx.de>
Currently when two or more buffers are queued by the camera driver
and so the double buffering is enabled in the idmac, we lose the
first frame comming from CSI since it is just dropped by the
interrupt handler. The reason for this dropping is that the interrupt
handler misleadingly assumes that the cur_buf flag is pointing to the
buffer used by the IDMAC. Actually it is not the case since the
CUR_BUF flag will be flipped by the FSU when the FSU is sending the
<TASK>_NEW_FRM_RDY signal when new frame data is delivered by the CSI.
When sending this singal, FSU updates the DMA_CUR_BUF and the
DMA_BUFx_RDY flags: the DMA_CUR_BUF is flipped, the DMA_BUFx_RDY
is cleared, indicating that the frame data is beeing written by
the IDMAC to the pointed buffer. DMA_BUFx_RDY is supposed to be
set to the ready state again by the MCU, when it has handled the
received data. DMA_BUFx_RDY won't be set by the IPU, so waiting
for this event in the interrupt handler is wrong. Actually there
is no spurious interrupt as described in the comments, this
is the valid DMAIC_7_EOF interrupt indicating reception of the
frame from CSI.
This has been verified on the hardware which is triggering the
image sensor by the programmable state machine, allowing to
obtain exact number of frames. On this hardware we do not tolerate
losing frames.
This patch also removes resetting the DMA_BUFx_RDY flags of
all channels in ipu_disable_channel() since transfers on other
DMA channels might be triggered by other running tasks and the
buffers should always be ready for data sending or reception.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
drivers/dma/ipu/ipu_idmac.c | 50 -------------------------------------------
1 files changed, 0 insertions(+), 50 deletions(-)
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index cb26ee9..c1a125e 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -1145,29 +1145,6 @@ static int ipu_disable_channel(struct idmac *idmac, struct idmac_channel *ichan,
reg = idmac_read_icreg(ipu, IDMAC_CHA_EN);
idmac_write_icreg(ipu, reg & ~chan_mask, IDMAC_CHA_EN);
- /*
- * Problem (observed with channel DMAIC_7): after enabling the channel
- * and initialising buffers, there comes an interrupt with current still
- * pointing at buffer 0, whereas it should use buffer 0 first and only
- * generate an interrupt when it is done, then current should already
- * point to buffer 1. This spurious interrupt also comes on channel
- * DMASDC_0. With DMAIC_7 normally, is we just leave the ISR after the
- * first interrupt, there comes the second with current correctly
- * pointing to buffer 1 this time. But sometimes this second interrupt
- * doesn't come and the channel hangs. Clearing BUFx_RDY when disabling
- * the channel seems to prevent the channel from hanging, but it doesn't
- * prevent the spurious interrupt. This might also be unsafe. Think
- * about the IDMAC controller trying to switch to a buffer, when we
- * clear the ready bit, and re-enable it a moment later.
- */
- reg = idmac_read_ipureg(ipu, IPU_CHA_BUF0_RDY);
- idmac_write_ipureg(ipu, 0, IPU_CHA_BUF0_RDY);
- idmac_write_ipureg(ipu, reg & ~(1UL << channel), IPU_CHA_BUF0_RDY);
-
- reg = idmac_read_ipureg(ipu, IPU_CHA_BUF1_RDY);
- idmac_write_ipureg(ipu, 0, IPU_CHA_BUF1_RDY);
- idmac_write_ipureg(ipu, reg & ~(1UL << channel), IPU_CHA_BUF1_RDY);
-
spin_unlock_irqrestore(&ipu->lock, flags);
return 0;
@@ -1246,33 +1223,6 @@ static irqreturn_t idmac_interrupt(int irq, void *dev_id)
/* Other interrupts do not interfere with this channel */
spin_lock(&ichan->lock);
- if (unlikely(chan_id != IDMAC_SDC_0 && chan_id != IDMAC_SDC_1 &&
- ((curbuf >> chan_id) & 1) == ichan->active_buffer &&
- !list_is_last(ichan->queue.next, &ichan->queue))) {
- int i = 100;
-
- /* This doesn't help. See comment in ipu_disable_channel() */
- while (--i) {
- curbuf = idmac_read_ipureg(&ipu_data, IPU_CHA_CUR_BUF);
- if (((curbuf >> chan_id) & 1) != ichan->active_buffer)
- break;
- cpu_relax();
- }
-
- if (!i) {
- spin_unlock(&ichan->lock);
- dev_dbg(dev,
- "IRQ on active buffer on channel %x, active "
- "%d, ready %x, %x, current %x!\n", chan_id,
- ichan->active_buffer, ready0, ready1, curbuf);
- return IRQ_NONE;
- } else
- dev_dbg(dev,
- "Buffer deactivated on channel %x, active "
- "%d, ready %x, %x, current %x, rest %d!\n", chan_id,
- ichan->active_buffer, ready0, ready1, curbuf, i);
- }
-
if (unlikely((ichan->active_buffer && (ready1 >> chan_id) & 1) ||
(!ichan->active_buffer && (ready0 >> chan_id) & 1)
)) {
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] v4l: soc-camera: start stream after queueing the buffers
From: Anatolij Gustschin @ 2011-01-26 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296031789-1721-1-git-send-email-agust@denx.de>
Some camera systems have strong requirement for capturing
an exact number of frames after starting the stream and do
not tolerate losing captured frames. By starting the stream
after the videobuf has queued the buffers, we ensure that
no frame will be lost.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
drivers/media/video/soc_camera.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index a66811b..7299de0 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -646,11 +646,11 @@ static int soc_camera_streamon(struct file *file, void *priv,
if (icd->streamer != file)
return -EBUSY;
- v4l2_subdev_call(sd, video, s_stream, 1);
-
/* This calls buf_queue from host driver's videobuf_queue_ops */
ret = videobuf_streamon(&icd->vb_vidq);
+ v4l2_subdev_call(sd, video, s_stream, 1);
+
return ret;
}
--
1.7.1
^ permalink raw reply related
* [PATCH 0/2] Fix issues with frame reception from CSI on i.MX31
From: Anatolij Gustschin @ 2011-01-26 8:49 UTC (permalink / raw)
To: linux-arm-kernel
On some camera systems we do not tolerate the losing of
captured frames. We observed losing of the first frame
from CSI when double buffering is used (multiple buffers
queued by the mx3-camera driver).
The patches provide fixes for the observed problem.
Anatolij Gustschin (2):
v4l: soc-camera: start stream after queueing the buffers
dma: ipu_idmac: do not lose valid received data in the irq handler
drivers/dma/ipu/ipu_idmac.c | 50 --------------------------------------
drivers/media/video/soc_camera.c | 4 +-
2 files changed, 2 insertions(+), 52 deletions(-)
^ permalink raw reply
* [PATCH] ARM: OMAP2: use early init hook
From: Uwe Kleine-König @ 2011-01-26 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110123171344.GH30094@n2100.arm.linux.org.uk>
Hello Russell,
On Sun, Jan 23, 2011 at 05:13:44PM +0000, Russell King - ARM Linux wrote:
> Move non-mapping and non-irq initialization code out of .map_io and
> .init_irq respectively into the new init_early hook.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> I think I've updated this patch correctly for the new platforms merged
> into mainline.
>
> Please ensure that new platforms merged after this patch also use the
> new structure, and note that the initializers should be listed in the
> following order:
>
> .fixup
> .reserve
> .map_io
> .init_early
> .init_irq
> .timer
> .init_machine
Will you care for imx (mach-{mx*,imx}), too, or should I fix them up?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] ARM: mm: enforce pageblock alignment when freeing memmap entries at init
From: Mel Gorman @ 2011-01-26 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295567231-2384-1-git-send-email-dima@android.com>
On Thu, Jan 20, 2011 at 03:47:11PM -0800, Dima Zavin wrote:
> On some machines, the nodes do not always start on pageblock
> boundaries. In these cases it is possible for free_unused_memmap
> to free mappings for pages inside a pageblock with otherwise
> valid pages. This presents problems for page migration since it
> operates on whole pageblocks at a time.
>
This patch is not aligning on a pageblock boundary - it's aligning on
MAX_ORDER_NR_PAGES which is the boundary the buddy allocator works on.
This is a minor but important nit as different assumptions are made
about pageblocks and MAX_ORDER_NR_PAGES. Anyway;
If the node is not starting on the MAX_ORDER boundary then node_start_pfn
should also not be on the same boundary but the patch does not imply
that this has been broken. If anything it appears at a glance that there
is memmap *not* being freed because it was allocated on the
MAX_ORDER_NR_PAGES boundary and only partially freed.
The comment then is confusing because the function is freeing memmap but
rounding down to free more of it ensures that all pages get a mapping?
It's not clear at all to me what was broken or how this patch fixes it
but bear in mind that it's rare I look at how ARM is initialised.
> Round down bank_start to pageblock boundary so that whole
> pageblocks always have valid mappings.
>
> Signed-off-by: Dima Zavin <dima@android.com>
> ---
> arch/arm/mm/init.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 5164069..98de5d8 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -418,7 +418,11 @@ static void __init free_unused_memmap(struct meminfo *mi)
> for_each_bank(i, mi) {
> struct membank *bank = &mi->bank[i];
>
> - bank_start = bank_pfn_start(bank);
> + /* Round bank_start down to the start of a pageblock so that
> + * all pages in a pageblock always have a mapping.
> + */
> + bank_start = round_down(bank_pfn_start(bank),
> + MAX_ORDER_NR_PAGES);
>
> /*
> * If we had a previous bank, and there is a space
> --
> 1.7.3.1
>
--
Mel Gorman
Linux Technology Center
IBM Dublin Software Lab
^ permalink raw reply
* [PATCH 2/2] mach-ux500: rename defconfig
From: Linus Walleij @ 2011-01-26 8:24 UTC (permalink / raw)
To: linux-arm-kernel
This renames the former u8500_defconfig to ux500_defconfig to
reflect the fact that this kernel image supports any ux500
platform nowadays.
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
---
arch/arm/configs/u8500_defconfig | 105 --------------------------------------
arch/arm/configs/ux500_defconfig | 105 ++++++++++++++++++++++++++++++++++++++
2 files changed, 105 insertions(+), 105 deletions(-)
delete mode 100644 arch/arm/configs/u8500_defconfig
create mode 100644 arch/arm/configs/ux500_defconfig
diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig
deleted file mode 100644
index a5cce24..0000000
--- a/arch/arm/configs/u8500_defconfig
+++ /dev/null
@@ -1,105 +0,0 @@
-CONFIG_EXPERIMENTAL=y
-# CONFIG_SWAP is not set
-CONFIG_SYSVIPC=y
-CONFIG_BLK_DEV_INITRD=y
-CONFIG_KALLSYMS_ALL=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-# CONFIG_LBDAF is not set
-# CONFIG_BLK_DEV_BSG is not set
-CONFIG_ARCH_U8500=y
-CONFIG_UX500_SOC_DB5500=y
-CONFIG_UX500_SOC_DB8500=y
-CONFIG_MACH_U8500=y
-CONFIG_MACH_U5500=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
-CONFIG_SMP=y
-CONFIG_NR_CPUS=2
-CONFIG_HOTPLUG_CPU=y
-CONFIG_PREEMPT=y
-CONFIG_AEABI=y
-CONFIG_CMDLINE="root=/dev/ram0 console=ttyAMA2,115200n8"
-CONFIG_CPU_FREQ=y
-CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
-CONFIG_VFP=y
-CONFIG_NEON=y
-CONFIG_NET=y
-CONFIG_PHONET=y
-CONFIG_PHONET_PIPECTRLR=y
-# CONFIG_WIRELESS is not set
-CONFIG_CAIF=y
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-CONFIG_BLK_DEV_RAM=y
-CONFIG_BLK_DEV_RAM_SIZE=65536
-CONFIG_MISC_DEVICES=y
-CONFIG_AB8500_PWM=y
-CONFIG_SENSORS_BH1780=y
-# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
-CONFIG_INPUT_EVDEV=y
-# CONFIG_KEYBOARD_ATKBD is not set
-CONFIG_KEYBOARD_GPIO=y
-CONFIG_KEYBOARD_NOMADIK=y
-CONFIG_KEYBOARD_STMPE=y
-CONFIG_KEYBOARD_TC3589X=y
-# CONFIG_INPUT_MOUSE is not set
-CONFIG_INPUT_TOUCHSCREEN=y
-CONFIG_TOUCHSCREEN_BU21013=y
-CONFIG_INPUT_MISC=y
-CONFIG_INPUT_AB8500_PONKEY=y
-# CONFIG_SERIO is not set
-CONFIG_VT_HW_CONSOLE_BINDING=y
-CONFIG_SERIAL_AMBA_PL011=y
-CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
-# CONFIG_LEGACY_PTYS is not set
-CONFIG_HW_RANDOM=y
-CONFIG_HW_RANDOM_NOMADIK=y
-CONFIG_I2C=y
-CONFIG_I2C_NOMADIK=y
-CONFIG_SPI=y
-CONFIG_SPI_PL022=y
-CONFIG_GPIO_STMPE=y
-CONFIG_GPIO_TC3589X=y
-# CONFIG_HWMON is not set
-CONFIG_MFD_STMPE=y
-CONFIG_MFD_TC3589X=y
-CONFIG_AB8500_CORE=y
-CONFIG_REGULATOR=y
-CONFIG_REGULATOR_AB8500=y
-# CONFIG_HID_SUPPORT is not set
-# CONFIG_USB_SUPPORT is not set
-CONFIG_MMC=y
-CONFIG_MMC_ARMMMCI=y
-CONFIG_NEW_LEDS=y
-CONFIG_LEDS_CLASS=y
-CONFIG_LEDS_LP5521=y
-CONFIG_RTC_CLASS=y
-CONFIG_RTC_DRV_AB8500=y
-CONFIG_RTC_DRV_PL031=y
-CONFIG_DMADEVICES=y
-CONFIG_STE_DMA40=y
-CONFIG_STAGING=y
-# CONFIG_STAGING_EXCLUDE_BUILD is not set
-CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4=y
-CONFIG_EXT2_FS=y
-CONFIG_EXT2_FS_XATTR=y
-CONFIG_EXT2_FS_POSIX_ACL=y
-CONFIG_EXT2_FS_SECURITY=y
-CONFIG_EXT3_FS=y
-CONFIG_VFAT_FS=y
-CONFIG_TMPFS=y
-CONFIG_TMPFS_POSIX_ACL=y
-CONFIG_CONFIGFS_FS=m
-# CONFIG_MISC_FILESYSTEMS is not set
-CONFIG_NLS_CODEPAGE_437=y
-CONFIG_NLS_ISO8859_1=y
-CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_FS=y
-CONFIG_DEBUG_KERNEL=y
-# CONFIG_SCHED_DEBUG is not set
-# CONFIG_DEBUG_PREEMPT is not set
-CONFIG_DEBUG_INFO=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
-# CONFIG_FTRACE is not set
-CONFIG_DEBUG_USER=y
-CONFIG_DEBUG_ERRORS=y
diff --git a/arch/arm/configs/ux500_defconfig b/arch/arm/configs/ux500_defconfig
new file mode 100644
index 0000000..a5cce24
--- /dev/null
+++ b/arch/arm/configs/ux500_defconfig
@@ -0,0 +1,105 @@
+CONFIG_EXPERIMENTAL=y
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_ARCH_U8500=y
+CONFIG_UX500_SOC_DB5500=y
+CONFIG_UX500_SOC_DB8500=y
+CONFIG_MACH_U8500=y
+CONFIG_MACH_U5500=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=2
+CONFIG_HOTPLUG_CPU=y
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+CONFIG_CMDLINE="root=/dev/ram0 console=ttyAMA2,115200n8"
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_VFP=y
+CONFIG_NEON=y
+CONFIG_NET=y
+CONFIG_PHONET=y
+CONFIG_PHONET_PIPECTRLR=y
+# CONFIG_WIRELESS is not set
+CONFIG_CAIF=y
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=65536
+CONFIG_MISC_DEVICES=y
+CONFIG_AB8500_PWM=y
+CONFIG_SENSORS_BH1780=y
+# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
+CONFIG_INPUT_EVDEV=y
+# CONFIG_KEYBOARD_ATKBD is not set
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_NOMADIK=y
+CONFIG_KEYBOARD_STMPE=y
+CONFIG_KEYBOARD_TC3589X=y
+# CONFIG_INPUT_MOUSE is not set
+CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_TOUCHSCREEN_BU21013=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_AB8500_PONKEY=y
+# CONFIG_SERIO is not set
+CONFIG_VT_HW_CONSOLE_BINDING=y
+CONFIG_SERIAL_AMBA_PL011=y
+CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_HW_RANDOM=y
+CONFIG_HW_RANDOM_NOMADIK=y
+CONFIG_I2C=y
+CONFIG_I2C_NOMADIK=y
+CONFIG_SPI=y
+CONFIG_SPI_PL022=y
+CONFIG_GPIO_STMPE=y
+CONFIG_GPIO_TC3589X=y
+# CONFIG_HWMON is not set
+CONFIG_MFD_STMPE=y
+CONFIG_MFD_TC3589X=y
+CONFIG_AB8500_CORE=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_AB8500=y
+# CONFIG_HID_SUPPORT is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_MMC=y
+CONFIG_MMC_ARMMMCI=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_LP5521=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_AB8500=y
+CONFIG_RTC_DRV_PL031=y
+CONFIG_DMADEVICES=y
+CONFIG_STE_DMA40=y
+CONFIG_STAGING=y
+# CONFIG_STAGING_EXCLUDE_BUILD is not set
+CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT2_FS_XATTR=y
+CONFIG_EXT2_FS_POSIX_ACL=y
+CONFIG_EXT2_FS_SECURITY=y
+CONFIG_EXT3_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_TMPFS_POSIX_ACL=y
+CONFIG_CONFIGFS_FS=m
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_FS=y
+CONFIG_DEBUG_KERNEL=y
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_DEBUG_PREEMPT is not set
+CONFIG_DEBUG_INFO=y
+# CONFIG_RCU_CPU_STALL_DETECTOR is not set
+# CONFIG_FTRACE is not set
+CONFIG_DEBUG_USER=y
+CONFIG_DEBUG_ERRORS=y
--
1.7.3.2
^ permalink raw reply related
* [PATCH 1/2] mach-ux500: update the U8500 defconfig
From: Linus Walleij @ 2011-01-26 8:24 UTC (permalink / raw)
To: linux-arm-kernel
Config and activate all the devices we've merged for Ux500
in 2.6.38-rc1.
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
---
arch/arm/configs/u8500_defconfig | 59 ++++++++++++++++++++++++++++++++-----
1 files changed, 51 insertions(+), 8 deletions(-)
diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig
index 52d86c4..a5cce24 100644
--- a/arch/arm/configs/u8500_defconfig
+++ b/arch/arm/configs/u8500_defconfig
@@ -1,7 +1,6 @@
CONFIG_EXPERIMENTAL=y
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
-CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_KALLSYMS_ALL=y
CONFIG_MODULES=y
@@ -13,43 +12,89 @@ CONFIG_UX500_SOC_DB5500=y
CONFIG_UX500_SOC_DB8500=y
CONFIG_MACH_U8500=y
CONFIG_MACH_U5500=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2
+CONFIG_HOTPLUG_CPU=y
CONFIG_PREEMPT=y
CONFIG_AEABI=y
CONFIG_CMDLINE="root=/dev/ram0 console=ttyAMA2,115200n8"
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
CONFIG_VFP=y
CONFIG_NEON=y
+CONFIG_NET=y
+CONFIG_PHONET=y
+CONFIG_PHONET_PIPECTRLR=y
+# CONFIG_WIRELESS is not set
+CONFIG_CAIF=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=65536
-# CONFIG_MISC_DEVICES is not set
+CONFIG_MISC_DEVICES=y
+CONFIG_AB8500_PWM=y
+CONFIG_SENSORS_BH1780=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_EVDEV=y
-# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_KEYBOARD_ATKBD is not set
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_NOMADIK=y
+CONFIG_KEYBOARD_STMPE=y
+CONFIG_KEYBOARD_TC3589X=y
# CONFIG_INPUT_MOUSE is not set
+CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_TOUCHSCREEN_BU21013=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_AB8500_PONKEY=y
# CONFIG_SERIO is not set
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
# CONFIG_LEGACY_PTYS is not set
-# CONFIG_HW_RANDOM is not set
+CONFIG_HW_RANDOM=y
+CONFIG_HW_RANDOM_NOMADIK=y
+CONFIG_I2C=y
+CONFIG_I2C_NOMADIK=y
CONFIG_SPI=y
CONFIG_SPI_PL022=y
+CONFIG_GPIO_STMPE=y
+CONFIG_GPIO_TC3589X=y
# CONFIG_HWMON is not set
-# CONFIG_VGA_CONSOLE is not set
+CONFIG_MFD_STMPE=y
+CONFIG_MFD_TC3589X=y
+CONFIG_AB8500_CORE=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_AB8500=y
# CONFIG_HID_SUPPORT is not set
# CONFIG_USB_SUPPORT is not set
+CONFIG_MMC=y
+CONFIG_MMC_ARMMMCI=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_LP5521=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_AB8500=y
+CONFIG_RTC_DRV_PL031=y
+CONFIG_DMADEVICES=y
+CONFIG_STE_DMA40=y
+CONFIG_STAGING=y
+# CONFIG_STAGING_EXCLUDE_BUILD is not set
+CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
-CONFIG_INOTIFY=y
+CONFIG_EXT3_FS=y
+CONFIG_VFAT_FS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_CONFIGFS_FS=m
# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_SCHED_DEBUG is not set
# CONFIG_DEBUG_PREEMPT is not set
@@ -58,5 +103,3 @@ CONFIG_DEBUG_INFO=y
# CONFIG_FTRACE is not set
CONFIG_DEBUG_USER=y
CONFIG_DEBUG_ERRORS=y
-CONFIG_CRC_T10DIF=m
-# CONFIG_CRC32 is not set
--
1.7.3.2
^ permalink raw reply related
* [PATCH] ARM: pxa: fix suspend on PXA3XX
From: Sven Neumann @ 2011-01-26 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinrxiHx6jX9jFzVzjq5FH-W=MLoDThAtRq2a1zZ@mail.gmail.com>
On Wed, 2011-01-26 at 05:06 +0800, Eric Miao wrote:
> How about this instead?
>
> diff --git a/arch/arm/mach-pxa/pm.c b/arch/arm/mach-pxa/pm.c
> index 978e1b2..1807c9a 100644
> --- a/arch/arm/mach-pxa/pm.c
> +++ b/arch/arm/mach-pxa/pm.c
> @@ -33,7 +33,7 @@ int pxa_pm_enter(suspend_state_t state)
> #endif
>
> /* skip registers saving for standby */
> - if (state != PM_SUSPEND_STANDBY) {
> + if (state != PM_SUSPEND_STANDBY && pxa_cpu_pm_fns->save) {
> pxa_cpu_pm_fns->save(sleep_save);
> /* before sleeping, calculate and save a checksum */
> for (i = 0; i < pxa_cpu_pm_fns->save_count - 1; i++)
> @@ -44,7 +44,7 @@ int pxa_pm_enter(suspend_state_t state)
> pxa_cpu_pm_fns->enter(state);
> cpu_init();
>
> - if (state != PM_SUSPEND_STANDBY) {
> + if (state != PM_SUSPEND_STANDBY && pxa_cpu_pm_fns->restore) {
> /* after sleeping, validate the checksum */
> for (i = 0; i < pxa_cpu_pm_fns->save_count - 1; i++)
> checksum += sleep_save[i];
>
Not sure if that will work as well. With this change the code is
skipping more than just the calls to pxa_cpu_pm_fns->save() and
pxa_cpu_pm_fns->restore(). In particular it doesn't call
pxa_cpu_pm_fns->enter(state).
Thanks,
Sven
^ permalink raw reply
* [PATCH 1/5] ARM: gic: Add hooks for architecture specific extensions
From: Santosh Shilimkar @ 2011-01-26 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikVixQTGMMsh2uteEoV_xRgizAqkZ0Kf7Ggejya@mail.gmail.com>
> -----Original Message-----
> From: ccross at google.com [mailto:ccross at google.com] On Behalf Of
> Colin Cross
> Sent: Wednesday, January 26, 2011 1:23 PM
> To: Santosh Shilimkar
> Cc: linux-arm-kernel at lists.infradead.org; linux-
> omap at vger.kernel.org; catalin.marinas at arm.com;
> linux at arm.linux.org.uk; linus.ml.walleij at gmail.com; Russell King
> Subject: Re: [PATCH 1/5] ARM: gic: Add hooks for architecture
> specific extensions
>
> On Tue, Jan 25, 2011 at 11:31 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
> >> -----Original Message-----
> >> From: ccross at google.com [mailto:ccross at google.com] On Behalf Of
> >> Colin Cross
> >> Sent: Wednesday, January 26, 2011 12:54 PM
> >> To: Santosh Shilimkar
> >> Cc: linux-arm-kernel at lists.infradead.org; linux-
> >> omap at vger.kernel.org; catalin.marinas at arm.com;
> >> linux at arm.linux.org.uk; linus.ml.walleij at gmail.com; Russell King
> >> Subject: Re: [PATCH 1/5] ARM: gic: Add hooks for architecture
> >> specific extensions
> >>
> > [....]
> >
> >> >>
> >> > Great.
> >> > Can I fold below changes in my patch and add you ack and
> tested-
> >> by?
> >>
> >> Sure
> >
> > After reading your initial comment, you mentioned you need to have
> > 'gic_set_type' as well. Is this still true. If yes then we need to
> > have arch_extn call for that as well.
>
> You are right, I missed adding the extension for gic_set_type. My
> testing doesn't cover that case right now, because I don't have any
> drivers updated to linux-next that use a wake source that is
> compatible with Tegra's lowest power suspend mode, and that is the
> only time the extension to gic_set_type is necessary.
>
Ok.
So I will go ahead and add an extension for the same so that we have
most of the usecases covered.
Regards,
Santosh
^ permalink raw reply
* [PATCH 1/5] ARM: gic: Add hooks for architecture specific extensions
From: Colin Cross @ 2011-01-26 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ef807d5fb389a19b2bd046f5fc6d203b@mail.gmail.com>
On Tue, Jan 25, 2011 at 11:31 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: ccross at google.com [mailto:ccross at google.com] On Behalf Of
>> Colin Cross
>> Sent: Wednesday, January 26, 2011 12:54 PM
>> To: Santosh Shilimkar
>> Cc: linux-arm-kernel at lists.infradead.org; linux-
>> omap at vger.kernel.org; catalin.marinas at arm.com;
>> linux at arm.linux.org.uk; linus.ml.walleij at gmail.com; Russell King
>> Subject: Re: [PATCH 1/5] ARM: gic: Add hooks for architecture
>> specific extensions
>>
> [....]
>
>> >>
>> > Great.
>> > Can I fold below changes in my patch and add you ack and tested-
>> by?
>>
>> Sure
>
> After reading your initial comment, you mentioned you need to have
> 'gic_set_type' as well. Is this still true. If yes then we need to
> have arch_extn call for that as well.
You are right, I missed adding the extension for gic_set_type. My
testing doesn't cover that case right now, because I don't have any
drivers updated to linux-next that use a wake source that is
compatible with Tegra's lowest power suspend mode, and that is the
only time the extension to gic_set_type is necessary.
>> >> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>> >> index 0b6c043..7993f07 100644
>> >> --- a/arch/arm/common/gic.c
>> >> +++ b/arch/arm/common/gic.c
>> >> @@ -90,6 +90,8 @@ static inline unsigned int gic_irq(struct
>> irq_data
>> >> *d)
>> >> ?static void gic_ack_irq(struct irq_data *d)
>> >> ?{
>> >> ? ? ? spin_lock(&irq_controller_lock);
>> >> + ? ? if (gic_arch_extn.irq_ack)
>> >> + ? ? ? ? ? ? gic_arch_extn.irq_ack(d);
>> >> ? ? ? writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
>> >> ? ? ? spin_unlock(&irq_controller_lock);
>> >> ?}
>> >> @@ -161,6 +163,14 @@ static int gic_set_type(struct irq_data *d,
>> >> unsigned int type)
>> >> ? ? ? return 0;
>> >> ?}
>> >>
>> >> +static int gic_retrigger(struct irq_data *d)
>> >> +{
>> >> + ? ? if (gic_arch_extn.irq_retrigger)
>> >> + ? ? ? ? ? ? return gic_arch_extn.irq_retrigger(d);
>> >> +
>> >> + ? ? return 0;
>> >> +}
>> >> +
>> >> ?#ifdef CONFIG_SMP
>> >> ?static int
>> >> ?gic_set_cpu(struct irq_data *d, const struct cpumask *mask_val,
>> >> bool force)
>> >> @@ -234,6 +244,7 @@ static struct irq_chip gic_chip = {
>> >> ? ? ? .irq_mask ? ? ? ? ? ? ? = gic_mask_irq,
>> >> ? ? ? .irq_unmask ? ? ? ? ? ? = gic_unmask_irq,
>> >> ? ? ? .irq_set_type ? ? ? ? ? = gic_set_type,
>> >> + ? ? .irq_retrigger ? ? ? ? ?= gic_retrigger,
>> >> ?#ifdef CONFIG_SMP
>> >> ? ? ? .irq_set_affinity ? ? ? = gic_set_cpu,
>> >> ?#endif
>> >
>
^ permalink raw reply
* [PATCH 1/2] Updated XCEP partition sizes
From: Uwe Kleine-König @ 2011-01-26 7:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinLTuJY9vDH_oHeKk7j6oo4369cF35PG+fVc5A_@mail.gmail.com>
On Wed, Jan 26, 2011 at 05:19:55AM +0800, Eric Miao wrote:
> On Tue, Jan 25, 2011 at 2:54 AM, Matej Kenda <matejken@gmail.com> wrote:
> > Hi Eric,
> >
> > I've sent two simple patches for Iskratel XCEP last week.
> >
> > Can they be included in the kernel?
>
> I'm a bit tentative on this. Patch 1 is basically OK, but what if
> someone needs a even larger partition in the future? And some work
> is on-going with cleanup of those defconfigs, guess I'll hold a
> while those changes to the defconfig until that's clear enough.
>
> BTW - did you run Uwe's script to make sure the changes to defconfig
> is the smallest one?
there is no "Uwe's script" anymore. Just run
make ARCH=arm savedefconfig
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 1/5] ARM: gic: Add hooks for architecture specific extensions
From: Santosh Shilimkar @ 2011-01-26 7:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=-JYqKW0abCZKDzVjM0DkYF+LMOXDa1R+HrJ2i@mail.gmail.com>
> -----Original Message-----
> From: ccross at google.com [mailto:ccross at google.com] On Behalf Of
> Colin Cross
> Sent: Wednesday, January 26, 2011 12:54 PM
> To: Santosh Shilimkar
> Cc: linux-arm-kernel at lists.infradead.org; linux-
> omap at vger.kernel.org; catalin.marinas at arm.com;
> linux at arm.linux.org.uk; linus.ml.walleij at gmail.com; Russell King
> Subject: Re: [PATCH 1/5] ARM: gic: Add hooks for architecture
> specific extensions
>
[....]
> >>
> > Great.
> > Can I fold below changes in my patch and add you ack and tested-
> by?
>
> Sure
After reading your initial comment, you mentioned you need to have
'gic_set_type' as well. Is this still true. If yes then we need to
have arch_extn call for that as well.
>
> >> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> >> index 0b6c043..7993f07 100644
> >> --- a/arch/arm/common/gic.c
> >> +++ b/arch/arm/common/gic.c
> >> @@ -90,6 +90,8 @@ static inline unsigned int gic_irq(struct
> irq_data
> >> *d)
> >> ?static void gic_ack_irq(struct irq_data *d)
> >> ?{
> >> ? ? ? spin_lock(&irq_controller_lock);
> >> + ? ? if (gic_arch_extn.irq_ack)
> >> + ? ? ? ? ? ? gic_arch_extn.irq_ack(d);
> >> ? ? ? writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
> >> ? ? ? spin_unlock(&irq_controller_lock);
> >> ?}
> >> @@ -161,6 +163,14 @@ static int gic_set_type(struct irq_data *d,
> >> unsigned int type)
> >> ? ? ? return 0;
> >> ?}
> >>
> >> +static int gic_retrigger(struct irq_data *d)
> >> +{
> >> + ? ? if (gic_arch_extn.irq_retrigger)
> >> + ? ? ? ? ? ? return gic_arch_extn.irq_retrigger(d);
> >> +
> >> + ? ? return 0;
> >> +}
> >> +
> >> ?#ifdef CONFIG_SMP
> >> ?static int
> >> ?gic_set_cpu(struct irq_data *d, const struct cpumask *mask_val,
> >> bool force)
> >> @@ -234,6 +244,7 @@ static struct irq_chip gic_chip = {
> >> ? ? ? .irq_mask ? ? ? ? ? ? ? = gic_mask_irq,
> >> ? ? ? .irq_unmask ? ? ? ? ? ? = gic_unmask_irq,
> >> ? ? ? .irq_set_type ? ? ? ? ? = gic_set_type,
> >> + ? ? .irq_retrigger ? ? ? ? ?= gic_retrigger,
> >> ?#ifdef CONFIG_SMP
> >> ? ? ? .irq_set_affinity ? ? ? = gic_set_cpu,
> >> ?#endif
> >
^ 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