* [PATCH v2 13/13] tty: pruss SUART driver
From: Subhasish Ghosh @ 2011-02-18 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110211162814.6ff274f1@lxorguk.ukuu.org.uk>
Hello,
Regarding the semaphore to mutex migration.
We are using down_trylock in interrupt context,
mutex_trylock cannot be used in interrupt context, so we cannot use mutex in
our driver.
--------------------------------------------------
From: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
Sent: Friday, February 11, 2011 9:58 PM
To: "Subhasish Ghosh" <subhasish@mistralsolutions.com>
Cc: <davinci-linux-open-source@linux.davincidsp.com>;
<linux-arm-kernel@lists.infradead.org>; <m-watkins@ti.com>;
<nsekhar@ti.com>; <sachi@mistralsolutions.com>; "Greg Kroah-Hartman"
<gregkh@suse.de>; "open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 13/13] tty: pruss SUART driver
> Don't see why it needs its own sub-directory
>
>
>
>> +#ifdef __SUART_DEBUG
>> +#define __suart_debug(fmt, args...) \
>> + printk(KERN_DEBUG "suart_debug: " fmt, ## args)
>> +#else
>> +#define __suart_debug(fmt, args...)
>> +#endif
>> +
>> +#define __suart_err(fmt, args...) printk(KERN_ERR "suart_err: " fmt, ##
>> args)
>
> Use dev_dbg/dev_err/pr_debug/pr_err
>
>
>> +static void omapl_pru_tx_chars(struct omapl_pru_suart *soft_uart, u32
>> uart_no)
>> +{
>> + struct circ_buf *xmit = &soft_uart->port[uart_no].state->xmit;
>> + struct device *dev = soft_uart->dev;
>> + s32 count = 0;
>> +
>> + if (!(suart_get_duplex(soft_uart, uart_no) & ePRU_SUART_HALF_TX))
>> + return;
>> +
>> + if (down_trylock(&soft_uart->port_sem[uart_no]))
>> + return;
>
> Please use a mutex not a semaphore. We are trying to get almost all the
> kernel using mutexes as it is needed for hard real time.
>
>
>> + pru_softuart_read_data(dev, &soft_uart->suart_hdl[uart_no],
>> + suart_data, data_len + 1,
>> + &data_len_read);
>> +
>> + for (i = 0; i <= data_len_read; i++) {
>> + soft_uart->port[uart_no].icount.rx++;
>> + /* check for sys rq */
>> + if (uart_handle_sysrq_char
>> + (&soft_uart->port[uart_no], suart_data))
>> + continue;
>> + }
>> + /* update the tty data structure */
>> + tty_insert_flip_string(tty, suart_data, data_len_read);
>
> You can avoid a copy here by using tty_prepare_flip_string()
>
> Also please use the tty_port_tty_get/tty_kref_put interfaces so the tty
> refcounting is right
>
>
>> +static void pruss_suart_set_termios(struct uart_port *port,
>> + struct ktermios *termios,
>> + struct ktermios *old)
>> +{
>> + struct omapl_pru_suart *soft_uart =
>> + container_of(port, struct omapl_pru_suart, port[port->line]);
>> + struct device *dev = soft_uart->dev;
>> + u8 cval = 0;
>> + unsigned long flags = 0;
>> + u32 baud = 0;
>> + u32 old_csize = old ? old->c_cflag & CSIZE : CS8;
>> +
>> +/*
>> + * Do not allow unsupported configurations to be set
>> + */
>> + if (1) {
>> + termios->c_cflag &= ~(HUPCL | CRTSCTS | CMSPAR | CSTOPB
>> + | PARENB | PARODD | CMSPAR);
>> + termios->c_cflag |= CLOCAL;
>
> No. CLOCAL and HUPCL are user side flags. Apps expect to able to set them
> even if in fact they have no effect, so leave those two alone. The rest
> is fine.
>
>
>> +/*
>> + * Characteres to ignore
>
> Typo
>
>
>
>> diff --git a/drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
>> b/drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
>> new file mode 100644
>> index 0000000..d809dd3
>> --- /dev/null
>> +++ b/drivers/tty/serial/da8xx_pruss/pruss_suart_api.c
>> @@ -0,0 +1,2350 @@
>> +/*
>> + * Copyright (C) 2010 Texas Instruments Incorporated
>> + * Author: Jitendra Kumar <jitendra@mistralsolutions.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> it
>> + * under the terms of the GNU General Public License as published by
>> the
>> + * Free Software Foundation version 2.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any kind,
>> + * whether express or implied; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * General Public License for more details.
>> + */
>> +
>> +#include <linux/types.h>
>> +#include <linux/mfd/pruss/da8xx_pru.h>
>> +#include <linux/io.h>
>> +#include <mach/hardware.h>
>> +#include "pruss_suart_api.h"
>> +#include "pruss_suart_regs.h"
>> +#include "pruss_suart_board.h"
>> +#include "pruss_suart_utils.h"
>> +#include "pruss_suart_err.h"
>> +
>> +static u8 g_uart_statu_table[8];
> Can you lose the g_, its a windows naming convention we dont use
>
>
>> +s16 pru_softuart_open(suart_handle h_suart)
>> +{
>
> If you just used normal integers you could surely make this routine
> trivial and remove all the duplication in the switches
>
>> + s16 status = PRU_SUART_SUCCESS;
>
> And please stick to Linux error codes
>
>
>> +/* suart instance close routine */
>> +s16 pru_softuart_close(suart_handle h_uart)
>> +{
>> + s16 status = SUART_SUCCESS;
>> +
>> + if (h_uart == NULL) {
>> + return PRU_SUART_ERR_HANDLE_INVALID;
>
> Which is never checked. Far better to use WARN_ON and the like for such
> cases - or if like this one they don't appear to be possible to simply
> delete them
>
>> + if ((tx_clk_divisor > 385) || (tx_clk_divisor == 0))
>> + return SUART_INVALID_CLKDIVISOR;
>> + if ((rx_clk_divisor > 385) || (rx_clk_divisor == 0))
>> + return SUART_INVALID_CLKDIVISOR;
>
> [minor] Lots of excess brackets
>
>
>> + u32offset = (u32) (PRUSS_INTC_CHANMAP9 & 0xFFFF);
>> + u32value = PRU_INTC_CHAN_34_SYSEVT_36_39;
>> + s16retval = pruss_writel(dev, u32offset, (u32 *)&u32value, 1);
>> + if (-1 == s16retval)
>> + return -1;
>
> If you fixed the API here you'd be able to just write
>
> if (pruss_writel(dev, PRUSS_INTC_CHANMAP9 & 0xFFFF,
> PRU_INTC_BLAH)
>
> or similar which would clean up a lot of messy code and shrink it
> dramatically. Given you have lots of series of writes some kind of
>
> pruss_writel_multi(dev, array, len)
>
> that took an array of addr/value pairs might also clean up a ton of code
> and turn it into trivial tables
>
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Arnd Bergmann @ 2011-02-18 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikjUEjr=Sd1Ewyj8-yAKPV3Wa2Ch1aE=0DtrXP6@mail.gmail.com>
On Friday 18 February 2011, Andrei Warkentin wrote:
> On Fri, Feb 11, 2011 at 4:33 PM, Andrei Warkentin <andreiw@motorola.com> wrote:
> > Arnd,
> >
> > Yes, this is a Toshiba card. I've sent the patch as a reply to Linus' email.
> >
> > cid - 02010053454d3332479070cc51451d00
> > csd - d00f00320f5903ffffffffff92404000
> > erase_size - 524288
> > fwrev - 0x0
> > hwrev - 0x0
> > manfid - 0x000002
> > name - SEM32G
> > oemid - 0x0100
> > preferred_erase_size - 2097152
> >
>
> Ok. Big mistake. Sorry about that. This card is Sandisk card. I got
> confused over all the manfids changing.
>
> Here is the Toshiba card:
>
> cid - 1101004d4d4333324703101a17746d00
> csd - 900e00320f5903ffffffffe796400000
> erase_size - 524288
> fwrev - 0x0
> hwrev - 0x0
> manfid - 0x000011
> name - MMC32G
> oemid - 0x0100
> preferred_erase_size - 4194304
>
> I'll get you the flashbench timings for both.
I'm curious. Neither the manfid nor the oemid fields of either card
match what I have seen on SD cards, I would expect them to be
Sandisk: manfid 0x000003, oemid 0x5344
Toshiba: manfid 0x000002, oemid 0x544d
I have not actually seen any Toshiba SD cards, but I assume that they
use the same controllers as Kingston.
Does anyone know if the IDs have any correlation between MMC and SD
controllers?
Arnd
^ permalink raw reply
* [PATCH v2 1/3] dmaengine: mxs-dma: add dma support for i.MX23/28
From: Shawn Guo @ 2011-02-18 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102181422.39266.arnd@arndb.de>
On Fri, Feb 18, 2011 at 02:22:39PM +0100, Arnd Bergmann wrote:
> On Friday 18 February 2011, Shawn Guo wrote:
> > > > +static dma_cookie_t mxs_dma_assign_cookie(struct mxs_dma_chan *mxs_chan)
> > > > +{
> > > > + dma_cookie_t cookie = mxs_chan->chan.cookie;
> > > > +
> > > > + if (++cookie < 0)
> > > > + cookie = 1;
> > > > +
> > > > + mxs_chan->chan.cookie = cookie;
> > > > + mxs_chan->desc.cookie = cookie;
> > > > +
> > > > + return cookie;
> > > > +}
> > > > +
> > > > +static struct mxs_dma_chan *to_mxs_dma_chan(struct dma_chan *chan)
> > > > +{
> > > > + return container_of(chan, struct mxs_dma_chan, chan);
> > > > +}
> > > > +
> > > > +static dma_cookie_t mxs_dma_tx_submit(struct dma_async_tx_descriptor *tx)
> > > > +{
> > > > + struct mxs_dma_chan *mxs_chan = to_mxs_dma_chan(tx->chan);
> > > > + dma_cookie_t cookie;
> > > > + unsigned long flags;
> > > > +
> > > > + spin_lock_irqsave(&mxs_chan->lock, flags);
> > > > +
> > > > + cookie = mxs_dma_assign_cookie(mxs_chan);
> > > > +
> > > > + mxs_dma_enable_chan(mxs_chan);
> > > > +
> > > > + spin_unlock_irqrestore(&mxs_chan->lock, flags);
> > > > +
> > > > + return cookie;
> > > > +}
> > >
> > > Just like the MMC driver, you use spin_lock_irqsave() in the functions that
> > > are called by other drivers, but then don't actually lock in the interrupt
> > > handler. This is clearly wrong, as I explained before:
> > >
> > > The interrupt handler may already be running on another CPU, so it
> > > is not at all serialized with this code.
> > >
> > I may be wrong on this point, but spin_lock_irqsave/irqrestore pair
> > is only for the protection you described? I learnt that the pair
> > should be used to protect the critical region, where I'm not sure
> > if it's called from interrupt context. Here I'm intending to protect
> > the dma registers accessed in mxs_dma_enable_chan.
>
> To generalize this further, a lock should protect specific data,
> not portions of the code, and ideally you should document
> exactly what you protect near the definition of the lock.
>
> If you use the lock to protect all the DMA registers, you should use
> it consistently, including inside of the interrupt handler, where
> you access some other registers.
>
> If you can prove that the registers used in the IRQ handler are
> totally independent of the other ones, you don't need to use the
> lock there, but then I'd advise documenting your assumptions.
>
When I change code to use readl/writel pair, I found the register
protection in mxs_dma_enable_chan is actually unnecessary, because
the registers are either channel specific or get set/clear address
to avoid read-modify-write operation.
So I'm removing the locking there.
> > Thanks for teaching. I intend to take the fix that Russell offered.
> > (Thanks, Russell). Does that look good to you, or spin_lock_bh
> > version should be used than spin_lock_irqsave?
>
> Russell's change looks correct to me.
>
> Regarding the choice between spin_lock_bh and spin_lock_irqsave,
> I always prefer to use the one that expresses best to the reader
> what the intention is. spin_lock_irqsave() is stronger than
> spin_lock_bh(), and can always be used in its place.
>
> A short form of the strict rules (there are better documentations
> out there) is:
>
> * If all users are outside of interrupt or tasklet context,
> use a bare spin_lock().
>
> * If one user is in a tasklet context, use spin_lock() inside
> the tasklet, but spin_lock_bh() outside, to prevent the
> tasklet from interrupting the critical section. Code that
> can be called in either tasklet or regular context needs
> to use spin_lock_bh() as well.
>
> * If one user is in interrupt context, use spin_lock() inside
> of the interrupt handler, but spin_lock_irq() in tasklet
> and normal context (not spin_lock_irqsave()), to prevent
> the interrupt from happening during the critical section.
>
> * Use spin_lock_irqsave() only for functions that can be called
> in either interrupt or non-interrupt context. Most drivers
> don't need this at all.
>
> The simplified rule would be to always use spin_lock_irqsave(),
> because that does not require you to understand what you are doing.
>
> My position is that it is better to use the stricter rules, because
> that documents that you actually do understand what you are doing ;-)
> It's also slightly more efficient, because it avoids having to
> save the interrupt status in a variable.
>
Thanks for this document. It helps.
I'm changing the tasklet to have callback only, and move others into
interrupt handler, so that I can remove the locking completely from
the driver.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v2] mxcmmc: use dmaengine API
From: Arnd Bergmann @ 2011-02-18 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110218092109.GG24426@pengutronix.de>
On Friday 18 February 2011, Sascha Hauer wrote:
> This switches the mxcmmc driver to use the dmaengine API. Unlike
> the old one this one is always present in the tree, even if no DMA
> is implemented, hence we can remove all the #ifdefs in from the driver.
> The driver automatically switches to PIO mode if no DMA support or no
> suitable channel is available.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The patch looks good to me, but shouldn't you also add a Kconfig
dependency or select on CONFIG_DMA_ENGINE? I don't see where that
gets set.
Acked-by: Arnd Bergmann <arnd@arndb.de>
> Arnd recognized that it's not a good idea that the driver has to
> know about the dmaengine implementation (the struct imx_dma_data field).
> I have a patch in my queue fixing this, but as this has to be
> synchronized with the platform code, I'd like to address this in a later
> patch.
Sounds good, since this patch is definitely a step forward.
Arnd
^ permalink raw reply
* [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG
From: Premi, Sanjeev @ 2011-02-18 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0387bf9911e20f7d6fa56aeb8ded4071@mail.gmail.com>
> -----Original Message-----
> From: Kalliguddi, Hema
> Sent: Friday, February 18, 2011 6:37 PM
> To: Premi, Sanjeev; Balbi, Felipe; Tony Lindgren
> Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List; Kevin Hilman;
> Cousson, Benoit; Paul Walmsley
> Subject: RE: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG
>
> Hi Premi,
>
> >-----Original Message-----
> >From: Premi, Sanjeev [mailto:premi at ti.com]
> >Sent: Friday, February 18, 2011 4:59 PM
> >To: Balbi, Felipe; Tony Lindgren
> >Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List;
> >Kalliguddi, Hema; Kevin Hilman; Cousson, Benoit; Paul Walmsley
> >Subject: RE: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG
> >
> >> -----Original Message-----
> >> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> >> owner at vger.kernel.org] On Behalf Of Balbi, Felipe
> >> Sent: Thursday, February 17, 2011 6:11 PM
> >> To: Tony Lindgren
> >> Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List;
> >Kalliguddi,
> >> Hema; Kevin Hilman; Cousson, Benoit; Paul Walmsley; Balbi, Felipe
> >> Subject: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG
> >>
> >> From: Hema HK <hemahk@ti.com>
> >>
> >> AM35xx hwmod data structures are populated for USBOTG with
> >base address,
> >> L3 and L4 interface clocks and IRQ.
> >>
> >> Signed-off-by: Hema HK <hemahk@ti.com>
> >> Cc: Tony Lindgren <tony@atomide.com>
> >> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> >> Cc: Cousson, Benoit <b-cousson@ti.com>
> >> Cc: Paul Walmsley <paul@pwsan.com>
> >> Signed-off-by: Felipe Balbi <balbi@ti.com>
> >> ---
> >> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 65
> >> ++++++++++++++++++++++++++++
> >> 1 files changed, 65 insertions(+), 0 deletions(-)
> >>
> >[snip]
> >>
> >> + /* usbotg for am35x */
> >> + &am35xx_usbhsotg_hwmod,
> >> +
> >> NULL,
> >
> >Felipe, Hema,
> >
> >This patch will break all existing OMAP35x (and I believe
> >OMAP3430 - since there is no difference - unless there is
> >some trick in the USB driver code).
> >
>
> I agree that this will break the AM35x because there is no
> separate CHIP_IS* defined for AM35x.
> AM35x is treated as one of the version of OMAP3430.
>
> >I have seen similar problems with smart reflex included in
> >the AM35x hwmod data.
>
> Unless the new CHIP_IS_* introduced for AM35x this problem will
> still exists.
>
> I thought you are already working on this because you were
> asking the questions in the list.
[sp] Yes. I am working on it. Just responded to same query.
>
> >
> >In this case accessing "unknown" registers corresponding to
> >SmartReflex in _setup() causes crash.
> >(http://marc.info/?l=linux-omap&m=129777408503329&w=2)
> >
> >I expect similar to be happening on OMAP35x with inclusion
> >of am35xx_usbhsotg_hwmod. If you don't see any crash, there
> >would be side-effects - and _setup() would be initializing
> >non-existent OTG registers on OMAP35x.
> >
> This will not impact for OMAP3 as the IDCODE is different AM35x and
> OMAP3, so passing the right chip version in the HWMOD database for AM35x
> will avoid the hwod init incase of OMAP3.
[sp] Are you saying that IDCODE is being used in HWMOD to prevent
possible 'pollution' in the current implementation of
am35xx_usbhsotg_hwmod?
>
> >Did you see any problems while testing?
> >
> I tested with OMAP3430SDP and OMAP3630Zoom3 and did not see
> the problem.
[sp] Could this be due to difference in kind of processing done
in _setup() for this hwmod. OR that addresses are (possibly)
overlapping/ or not used?
I suggest verifying this at the earliest.
>
> Regards,
> Hema
>
> >~sanjeev
> >
> >PS: Sending mail via webmailer. Formatting may break
> >
> >> };
> >>
> >> --
> >> 1.7.4.rc2
> >>
> >> --
> >> 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 v2 1/3] dmaengine: mxs-dma: add dma support for i.MX23/28
From: Arnd Bergmann @ 2011-02-18 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110218084513.GB18085@S2100-06.ap.freescale.net>
On Friday 18 February 2011, Shawn Guo wrote:
> > > +static dma_cookie_t mxs_dma_assign_cookie(struct mxs_dma_chan *mxs_chan)
> > > +{
> > > + dma_cookie_t cookie = mxs_chan->chan.cookie;
> > > +
> > > + if (++cookie < 0)
> > > + cookie = 1;
> > > +
> > > + mxs_chan->chan.cookie = cookie;
> > > + mxs_chan->desc.cookie = cookie;
> > > +
> > > + return cookie;
> > > +}
> > > +
> > > +static struct mxs_dma_chan *to_mxs_dma_chan(struct dma_chan *chan)
> > > +{
> > > + return container_of(chan, struct mxs_dma_chan, chan);
> > > +}
> > > +
> > > +static dma_cookie_t mxs_dma_tx_submit(struct dma_async_tx_descriptor *tx)
> > > +{
> > > + struct mxs_dma_chan *mxs_chan = to_mxs_dma_chan(tx->chan);
> > > + dma_cookie_t cookie;
> > > + unsigned long flags;
> > > +
> > > + spin_lock_irqsave(&mxs_chan->lock, flags);
> > > +
> > > + cookie = mxs_dma_assign_cookie(mxs_chan);
> > > +
> > > + mxs_dma_enable_chan(mxs_chan);
> > > +
> > > + spin_unlock_irqrestore(&mxs_chan->lock, flags);
> > > +
> > > + return cookie;
> > > +}
> >
> > Just like the MMC driver, you use spin_lock_irqsave() in the functions that
> > are called by other drivers, but then don't actually lock in the interrupt
> > handler. This is clearly wrong, as I explained before:
> >
> > The interrupt handler may already be running on another CPU, so it
> > is not at all serialized with this code.
> >
> I may be wrong on this point, but spin_lock_irqsave/irqrestore pair
> is only for the protection you described? I learnt that the pair
> should be used to protect the critical region, where I'm not sure
> if it's called from interrupt context. Here I'm intending to protect
> the dma registers accessed in mxs_dma_enable_chan.
To generalize this further, a lock should protect specific data,
not portions of the code, and ideally you should document
exactly what you protect near the definition of the lock.
If you use the lock to protect all the DMA registers, you should use
it consistently, including inside of the interrupt handler, where
you access some other registers.
If you can prove that the registers used in the IRQ handler are
totally independent of the other ones, you don't need to use the
lock there, but then I'd advise documenting your assumptions.
> Thanks for teaching. I intend to take the fix that Russell offered.
> (Thanks, Russell). Does that look good to you, or spin_lock_bh
> version should be used than spin_lock_irqsave?
Russell's change looks correct to me.
Regarding the choice between spin_lock_bh and spin_lock_irqsave,
I always prefer to use the one that expresses best to the reader
what the intention is. spin_lock_irqsave() is stronger than
spin_lock_bh(), and can always be used in its place.
A short form of the strict rules (there are better documentations
out there) is:
* If all users are outside of interrupt or tasklet context,
use a bare spin_lock().
* If one user is in a tasklet context, use spin_lock() inside
the tasklet, but spin_lock_bh() outside, to prevent the
tasklet from interrupting the critical section. Code that
can be called in either tasklet or regular context needs
to use spin_lock_bh() as well.
* If one user is in interrupt context, use spin_lock() inside
of the interrupt handler, but spin_lock_irq() in tasklet
and normal context (not spin_lock_irqsave()), to prevent
the interrupt from happening during the critical section.
* Use spin_lock_irqsave() only for functions that can be called
in either interrupt or non-interrupt context. Most drivers
don't need this at all.
The simplified rule would be to always use spin_lock_irqsave(),
because that does not require you to understand what you are doing.
My position is that it is better to use the stricter rules, because
that documents that you actually do understand what you are doing ;-)
It's also slightly more efficient, because it avoids having to
save the interrupt status in a variable.
Arnd
^ permalink raw reply
* [RFC/PATCH] OMAP: Fix section mismatch
From: Thomas Weber @ 2011-02-18 13:15 UTC (permalink / raw)
To: linux-arm-kernel
When compiling linux-omap with 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
the following output occurs:
WARNING: arch/arm/plat-omap/built-in.o(.data+0x6e8): Section mismatch in
reference from the variable omap_driver to the function
.init.text:omap_cpu_init()
The variable omap_driver references
the function __init omap_cpu_init()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
This patch fixes this by adding __refdata to the omap_driver variable.
Signed-off-by: Thomas Weber <weber@corscience.de>
---
arch/arm/plat-omap/cpu-omap.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index 11c54ec..17fdd5f 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -144,7 +144,7 @@ static struct freq_attr *omap_cpufreq_attr[] = {
NULL,
};
-static struct cpufreq_driver omap_driver = {
+static struct cpufreq_driver omap_driver __refdata = {
.flags = CPUFREQ_STICKY,
.verify = omap_verify_speed,
.target = omap_target,
--
1.7.4.1
^ permalink raw reply related
* [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG
From: Hema Kalliguddi @ 2011-02-18 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024B83BED5@dbde02.ent.ti.com>
Hi Premi,
>-----Original Message-----
>From: Premi, Sanjeev [mailto:premi at ti.com]
>Sent: Friday, February 18, 2011 4:59 PM
>To: Balbi, Felipe; Tony Lindgren
>Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List;
>Kalliguddi, Hema; Kevin Hilman; Cousson, Benoit; Paul Walmsley
>Subject: RE: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG
>
>> -----Original Message-----
>> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
>> owner at vger.kernel.org] On Behalf Of Balbi, Felipe
>> Sent: Thursday, February 17, 2011 6:11 PM
>> To: Tony Lindgren
>> Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List;
>Kalliguddi,
>> Hema; Kevin Hilman; Cousson, Benoit; Paul Walmsley; Balbi, Felipe
>> Subject: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG
>>
>> From: Hema HK <hemahk@ti.com>
>>
>> AM35xx hwmod data structures are populated for USBOTG with
>base address,
>> L3 and L4 interface clocks and IRQ.
>>
>> Signed-off-by: Hema HK <hemahk@ti.com>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Kevin Hilman <khilman@deeprootsystems.com>
>> Cc: Cousson, Benoit <b-cousson@ti.com>
>> Cc: Paul Walmsley <paul@pwsan.com>
>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>> ---
>> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 65
>> ++++++++++++++++++++++++++++
>> 1 files changed, 65 insertions(+), 0 deletions(-)
>>
>[snip]
>>
>> + /* usbotg for am35x */
>> + &am35xx_usbhsotg_hwmod,
>> +
>> NULL,
>
>Felipe, Hema,
>
>This patch will break all existing OMAP35x (and I believe
>OMAP3430 - since there is no difference - unless there is
>some trick in the USB driver code).
>
I agree that this will break the AM35x because there is no
separate CHIP_IS* defined for AM35x.
AM35x is treated as one of the version of OMAP3430.
>I have seen similar problems with smart reflex included in
>the AM35x hwmod data.
Unless the new CHIP_IS_* introduced for AM35x this problem will
still exists.
I thought you are already working on this because you were
asking the questions in the list.
>
>In this case accessing "unknown" registers corresponding to
>SmartReflex in _setup() causes crash.
>(http://marc.info/?l=linux-omap&m=129777408503329&w=2)
>
>I expect similar to be happening on OMAP35x with inclusion
>of am35xx_usbhsotg_hwmod. If you don't see any crash, there
>would be side-effects - and _setup() would be initializing
>non-existent OTG registers on OMAP35x.
>
This will not impact for OMAP3 as the IDCODE is different AM35x and
OMAP3, so passing the right chip version in the HWMOD database for AM35x
will avoid the hwod init incase of OMAP3.
>Did you see any problems while testing?
>
I tested with OMAP3430SDP and OMAP3630Zoom3 and did not see
the problem.
Regards,
Hema
>~sanjeev
>
>PS: Sending mail via webmailer. Formatting may break
>
>> };
>>
>> --
>> 1.7.4.rc2
>>
>> --
>> 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
* [RFC] MMC: error handling improvements
From: Linus Walleij @ 2011-02-18 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikDxOeW9Nfaew_mZLnVJ6e7pyzQTNs139g_AehW@mail.gmail.com>
2011/2/17 Brian Swetland <swetland@google.com>:
> On Wed, Feb 16, 2011 at 1:01 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> 2011/2/16 David Brown <davidb@codeaurora.org>:
>>> The SDCC block is shared between
>>> the modem processor and the processor running Linux. ?If the driver
>>> doesn't go through the DMA engine, which coordinates this, the registers
>>> will be stomped on by the other CPU whenever it decides to access it's
>>> parts of the flash device.
>> (...)
>>
>> At the same time what you're saying sounds very weird:
>> the ios handler in mmc_sdcc does not request any DMA
>> channel before messing with the hardware, it simply just write
>> into registers very much in the style of mmci.c. Wouldn't that
>> disturb any simultaneous access to the MMC from another
>> CPU?
>
> (...)
> The way register access for the SDCC is synchronized between these two
> cores is by using a locking primitive built into the MSM DMA
> controller. ?If you don't use this indirect access model (via DMA
> transactions to the registers), you end up tripping over the baseband
> or the other way 'round. ?It's not fun.
Wherever is that synchronized in the DMA controller?
I don't get it because the code is so very similar.
When the ios does this:
msmsdcc_writel(host, clk, MMCICLOCK);
This magic macro does the trick?
static inline void
msmsdcc_writel(struct msmsdcc_host *host, u32 data, unsigned int reg)
{
writel(data, host->base + reg);
/* 3 clk delay required! */
udelay(1 + ((3 * USEC_PER_SEC) /
(host->clk_rate ? host->clk_rate : msmsdcc_fmin)));
}
What is so hard about renaming this mmci_writel() and putting
the udelay() weirdness inside #ifdef ARCH_MSM? Wrapping
all the writes in the mmci driver inside an inline function is hardly
a big problem.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] OMAP4: hwmod data: Add rev and dev_attr fields in McSPI
From: Benoit Cousson @ 2011-02-18 13:01 UTC (permalink / raw)
To: linux-arm-kernel
- Add a rev attribute to identify various McSPI IP version.
- Add a dev_attr structure to provide the number of chipselect
supported by the instance.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Govindraj.R <govindraj.raja@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 84e795c..182aa79 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -24,6 +24,7 @@
#include <plat/cpu.h>
#include <plat/gpio.h>
#include <plat/dma.h>
+#include <plat/mcspi.h>
#include "omap_hwmod_common_data.h"
@@ -3114,6 +3115,7 @@ static struct omap_hwmod_class_sysconfig omap44xx_mcspi_sysc = {
static struct omap_hwmod_class omap44xx_mcspi_hwmod_class = {
.name = "mcspi",
.sysc = &omap44xx_mcspi_sysc,
+ .rev = OMAP4_MCSPI_REV,
};
/* mcspi1 */
@@ -3156,6 +3158,11 @@ static struct omap_hwmod_ocp_if *omap44xx_mcspi1_slaves[] = {
&omap44xx_l4_per__mcspi1,
};
+/* mcspi1 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi1_dev_attr = {
+ .num_chipselect = 4,
+};
+
static struct omap_hwmod omap44xx_mcspi1_hwmod = {
.name = "mcspi1",
.class = &omap44xx_mcspi_hwmod_class,
@@ -3169,6 +3176,7 @@ static struct omap_hwmod omap44xx_mcspi1_hwmod = {
.clkctrl_reg = OMAP4430_CM_L4PER_MCSPI1_CLKCTRL,
},
},
+ .dev_attr = &mcspi1_dev_attr,
.slaves = omap44xx_mcspi1_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mcspi1_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -3210,6 +3218,11 @@ static struct omap_hwmod_ocp_if *omap44xx_mcspi2_slaves[] = {
&omap44xx_l4_per__mcspi2,
};
+/* mcspi2 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi2_dev_attr = {
+ .num_chipselect = 2,
+};
+
static struct omap_hwmod omap44xx_mcspi2_hwmod = {
.name = "mcspi2",
.class = &omap44xx_mcspi_hwmod_class,
@@ -3223,6 +3236,7 @@ static struct omap_hwmod omap44xx_mcspi2_hwmod = {
.clkctrl_reg = OMAP4430_CM_L4PER_MCSPI2_CLKCTRL,
},
},
+ .dev_attr = &mcspi2_dev_attr,
.slaves = omap44xx_mcspi2_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mcspi2_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -3264,6 +3278,11 @@ static struct omap_hwmod_ocp_if *omap44xx_mcspi3_slaves[] = {
&omap44xx_l4_per__mcspi3,
};
+/* mcspi3 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi3_dev_attr = {
+ .num_chipselect = 2,
+};
+
static struct omap_hwmod omap44xx_mcspi3_hwmod = {
.name = "mcspi3",
.class = &omap44xx_mcspi_hwmod_class,
@@ -3277,6 +3296,7 @@ static struct omap_hwmod omap44xx_mcspi3_hwmod = {
.clkctrl_reg = OMAP4430_CM_L4PER_MCSPI3_CLKCTRL,
},
},
+ .dev_attr = &mcspi3_dev_attr,
.slaves = omap44xx_mcspi3_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mcspi3_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -3316,6 +3336,11 @@ static struct omap_hwmod_ocp_if *omap44xx_mcspi4_slaves[] = {
&omap44xx_l4_per__mcspi4,
};
+/* mcspi4 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi4_dev_attr = {
+ .num_chipselect = 1,
+};
+
static struct omap_hwmod omap44xx_mcspi4_hwmod = {
.name = "mcspi4",
.class = &omap44xx_mcspi_hwmod_class,
@@ -3329,6 +3354,7 @@ static struct omap_hwmod omap44xx_mcspi4_hwmod = {
.clkctrl_reg = OMAP4430_CM_L4PER_MCSPI4_CLKCTRL,
},
},
+ .dev_attr = &mcspi4_dev_attr,
.slaves = omap44xx_mcspi4_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mcspi4_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
--
1.7.0.4
--------------020600090501030202090907--
^ permalink raw reply related
* [PATCH] OMAP4: hwmod data: Add rev and dev_attr fields in McSPI
From: Benoit Cousson @ 2011-02-18 13:01 UTC (permalink / raw)
To: linux-arm-kernel
- Add a rev attribute to identify various McSPI IP version.
- Add a dev_attr structure to provide the number of chipselect
supported by the instance.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Govindraj.R <govindraj.raja@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 84e795c..182aa79 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -24,6 +24,7 @@
#include <plat/cpu.h>
#include <plat/gpio.h>
#include <plat/dma.h>
+#include <plat/mcspi.h>
#include "omap_hwmod_common_data.h"
@@ -3114,6 +3115,7 @@ static struct omap_hwmod_class_sysconfig omap44xx_mcspi_sysc = {
static struct omap_hwmod_class omap44xx_mcspi_hwmod_class = {
.name = "mcspi",
.sysc = &omap44xx_mcspi_sysc,
+ .rev = OMAP4_MCSPI_REV,
};
/* mcspi1 */
@@ -3156,6 +3158,11 @@ static struct omap_hwmod_ocp_if *omap44xx_mcspi1_slaves[] = {
&omap44xx_l4_per__mcspi1,
};
+/* mcspi1 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi1_dev_attr = {
+ .num_chipselect = 4,
+};
+
static struct omap_hwmod omap44xx_mcspi1_hwmod = {
.name = "mcspi1",
.class = &omap44xx_mcspi_hwmod_class,
@@ -3169,6 +3176,7 @@ static struct omap_hwmod omap44xx_mcspi1_hwmod = {
.clkctrl_reg = OMAP4430_CM_L4PER_MCSPI1_CLKCTRL,
},
},
+ .dev_attr = &mcspi1_dev_attr,
.slaves = omap44xx_mcspi1_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mcspi1_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -3210,6 +3218,11 @@ static struct omap_hwmod_ocp_if *omap44xx_mcspi2_slaves[] = {
&omap44xx_l4_per__mcspi2,
};
+/* mcspi2 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi2_dev_attr = {
+ .num_chipselect = 2,
+};
+
static struct omap_hwmod omap44xx_mcspi2_hwmod = {
.name = "mcspi2",
.class = &omap44xx_mcspi_hwmod_class,
@@ -3223,6 +3236,7 @@ static struct omap_hwmod omap44xx_mcspi2_hwmod = {
.clkctrl_reg = OMAP4430_CM_L4PER_MCSPI2_CLKCTRL,
},
},
+ .dev_attr = &mcspi2_dev_attr,
.slaves = omap44xx_mcspi2_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mcspi2_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -3264,6 +3278,11 @@ static struct omap_hwmod_ocp_if *omap44xx_mcspi3_slaves[] = {
&omap44xx_l4_per__mcspi3,
};
+/* mcspi3 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi3_dev_attr = {
+ .num_chipselect = 2,
+};
+
static struct omap_hwmod omap44xx_mcspi3_hwmod = {
.name = "mcspi3",
.class = &omap44xx_mcspi_hwmod_class,
@@ -3277,6 +3296,7 @@ static struct omap_hwmod omap44xx_mcspi3_hwmod = {
.clkctrl_reg = OMAP4430_CM_L4PER_MCSPI3_CLKCTRL,
},
},
+ .dev_attr = &mcspi3_dev_attr,
.slaves = omap44xx_mcspi3_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mcspi3_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -3316,6 +3336,11 @@ static struct omap_hwmod_ocp_if *omap44xx_mcspi4_slaves[] = {
&omap44xx_l4_per__mcspi4,
};
+/* mcspi4 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi4_dev_attr = {
+ .num_chipselect = 1,
+};
+
static struct omap_hwmod omap44xx_mcspi4_hwmod = {
.name = "mcspi4",
.class = &omap44xx_mcspi_hwmod_class,
@@ -3329,6 +3354,7 @@ static struct omap_hwmod omap44xx_mcspi4_hwmod = {
.clkctrl_reg = OMAP4430_CM_L4PER_MCSPI4_CLKCTRL,
},
},
+ .dev_attr = &mcspi4_dev_attr,
.slaves = omap44xx_mcspi4_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mcspi4_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
--
1.7.0.4
--------------020600090501030202090907
Content-Type: text/plain;
name="0001-OMAP4-hwmod-data-Add-rev-and-dev_attr-fields-in-McSP.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*0="0001-OMAP4-hwmod-data-Add-rev-and-dev_attr-fields-in-McSP.pa";
filename*1="tch"
^ permalink raw reply related
* [PATCH] ARM: mx53_smd: Add entry to uncompress.h
From: Fabio Estevam @ 2011-02-18 12:54 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/plat-mxc/include/mach/uncompress.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-mxc/include/mach/uncompress.h b/arch/arm/plat-mxc/include/mach/uncompress.h
index b702884..7412558 100644
--- a/arch/arm/plat-mxc/include/mach/uncompress.h
+++ b/arch/arm/plat-mxc/include/mach/uncompress.h
@@ -112,6 +112,7 @@ static __inline__ void __arch_decomp_setup(unsigned long arch_id)
break;
case MACH_TYPE_MX53_EVK:
case MACH_TYPE_MX53_LOCO:
+ case MACH_TYPE_MX53_SMD:
uart_base = MX53_UART1_BASE_ADDR;
break;
default:
--
1.6.0.4
^ permalink raw reply related
* [PATCH 2/2] omap4: l2x0: Populate set_debug() function and enable Errata 727915
From: Santosh Shilimkar @ 2011-02-18 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298032525-21115-1-git-send-email-santosh.shilimkar@ti.com>
Populate the l2x0 set_debug function pointer with OMAP secure call
and enable the PL310 Errata 727915
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/omap4-common.c | 7 +++++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 1a2cf62..b69fa0a 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -45,6 +45,7 @@ config ARCH_OMAP4
select CPU_V7
select ARM_GIC
select PL310_ERRATA_588369
+ select PL310_ERRATA_727915
select ARM_ERRATA_720789
select ARCH_HAS_OPP
select PM_OPP if PM
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 1926864..9ef8c29 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -52,6 +52,12 @@ static void omap4_l2x0_disable(void)
omap_smc1(0x102, 0x0);
}
+static void omap4_l2x0_set_debug(unsigned long val)
+{
+ /* Program PL310 L2 Cache controller debug register */
+ omap_smc1(0x100, val);
+}
+
static int __init omap_l2_cache_init(void)
{
u32 aux_ctrl = 0;
@@ -99,6 +105,7 @@ static int __init omap_l2_cache_init(void)
* specific one
*/
outer_cache.disable = omap4_l2x0_disable;
+ outer_cache.set_debug = omap4_l2x0_set_debug;
return 0;
}
--
1.6.0.4
^ permalink raw reply related
* [PATCH 1/2] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
From: Santosh Shilimkar @ 2011-02-18 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298032525-21115-1-git-send-email-santosh.shilimkar@ti.com>
PL310 implements the Clean & Invalidate by Way L2 cache maintenance
operation (offset 0x7FC). This operation runs in background so that
PL310 can handle normal accesses while it is in progress. Under very
rare circumstances, due to this erratum, write data can be lost when
PL310 treats a cacheable write transaction during a Clean & Invalidate
by Way operation.
Workaround:
Disable Write-Back and Cache Linefill (Debug Control Register)
Clean & Invalidate by Way (0x7FC)
Re-enable Write-Back and Cache Linefill (Debug Control Register)
This patch also removes any OMAP dependency on PL310 Errata's
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm/Kconfig | 15 ++++++++++++---
arch/arm/include/asm/outercache.h | 1 +
arch/arm/mm/cache-l2x0.c | 28 +++++++++++++++-------------
3 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 26d45e5..b6eeab2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1140,7 +1140,7 @@ config ARM_ERRATA_742231
config PL310_ERRATA_588369
bool "Clean & Invalidate maintenance operations do not invalidate clean lines"
- depends on CACHE_L2X0 && ARCH_OMAP4
+ depends on CACHE_L2X0
help
The PL310 L2 cache controller implements three types of Clean &
Invalidate maintenance operations: by Physical Address
@@ -1149,8 +1149,7 @@ config PL310_ERRATA_588369
clean operation followed immediately by an invalidate operation,
both performing to the same memory location. This functionality
is not correctly implemented in PL310 as clean lines are not
- invalidated as a result of these operations. Note that this errata
- uses Texas Instrument's secure monitor api.
+ invalidated as a result of these operations.
config ARM_ERRATA_720789
bool "ARM errata: TLBIASIDIS and TLBIMVAIS operations can broadcast a faulty ASID"
@@ -1177,6 +1176,16 @@ config ARM_ERRATA_743622
visible impact on the overall performance or power consumption of the
processor.
+config PL310_ERRATA_727915
+ bool "Background Clean & Invalidate by Way operation can cause data corruption"
+ depends on CACHE_L2X0
+ help
+ PL310 implements the Clean & Invalidate by Way L2 cache maintenance
+ operation (offset 0x7FC). This operation runs in background so that
+ PL310 can handle normal accesses while it is in progress. Under very
+ rare circumstances, due to this erratum, write data can be lost when
+ PL310 treats a cacheable write transaction during a Clean &
+ Invalidate by Way operation.
endmenu
source "arch/arm/common/Kconfig"
diff --git a/arch/arm/include/asm/outercache.h b/arch/arm/include/asm/outercache.h
index fc19009..348d513 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -31,6 +31,7 @@ struct outer_cache_fns {
#ifdef CONFIG_OUTER_CACHE_SYNC
void (*sync)(void);
#endif
+ void (*set_debug)(unsigned long);
};
#ifdef CONFIG_OUTER_CACHE
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 170c9bb..a8caee4 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -67,18 +67,22 @@ static inline void l2x0_inv_line(unsigned long addr)
writel_relaxed(addr, base + L2X0_INV_LINE_PA);
}
-#ifdef CONFIG_PL310_ERRATA_588369
+#if defined(CONFIG_PL310_ERRATA_588369) || defined(CONFIG_PL310_ERRATA_727915)
static void debug_writel(unsigned long val)
{
- extern void omap_smc1(u32 fn, u32 arg);
-
- /*
- * Texas Instrument secure monitor api to modify the
- * PL310 Debug Control Register.
- */
- omap_smc1(0x100, val);
+ if (outer_cache.set_debug)
+ outer_cache.set_debug(val);
+ else
+ writel(val, l2x0_base + L2X0_DEBUG_CTRL);
+}
+#else
+/* Optimised out for non-errata case */
+static inline void debug_writel(unsigned long val)
+{
}
+#endif
+#ifdef CONFIG_PL310_ERRATA_588369
static inline void l2x0_flush_line(unsigned long addr)
{
void __iomem *base = l2x0_base;
@@ -91,11 +95,6 @@ static inline void l2x0_flush_line(unsigned long addr)
}
#else
-/* Optimised out for non-errata case */
-static inline void debug_writel(unsigned long val)
-{
-}
-
static inline void l2x0_flush_line(unsigned long addr)
{
void __iomem *base = l2x0_base;
@@ -119,9 +118,11 @@ static void l2x0_flush_all(void)
/* clean all ways */
spin_lock_irqsave(&l2x0_lock, flags);
+ debug_writel(0x03);
writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_CLEAN_INV_WAY);
cache_wait_way(l2x0_base + L2X0_CLEAN_INV_WAY, l2x0_way_mask);
cache_sync();
+ debug_writel(0x00);
spin_unlock_irqrestore(&l2x0_lock, flags);
}
@@ -329,6 +330,7 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
outer_cache.flush_all = l2x0_flush_all;
outer_cache.inv_all = l2x0_inv_all;
outer_cache.disable = l2x0_disable;
+ outer_cache.set_debug = NULL;
printk(KERN_INFO "%s cache controller enabled\n", type);
printk(KERN_INFO "l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x, Cache size: %d B\n",
--
1.6.0.4
^ permalink raw reply related
* [PATCH 0/2] l2x0: Add PL310 Errata 727915
From: Santosh Shilimkar @ 2011-02-18 12:35 UTC (permalink / raw)
To: linux-arm-kernel
Based on feedback from Catalin on the L2X0 ERRATA 742231 patch, I have split
the original patch into two separate patches. First one adds errata and
also removes OMAP dependency from it so that other SOCs can use them.
Second patch populates the set_debug() pointer for OMAP using secure
SMC call to alter the debug registers.
Mail thread on this:
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg44571.html
The following changes since commit 85e2efbb1db9a18d218006706d6e4fbeb0216213:
Linus Torvalds (1):
Linux 2.6.38-rc5
Santosh Shilimkar (2):
ARM: l2x0: Errata fix for flush by Way operation can cause data
corruption
omap4: l2x0: Populate set_debug() function and enable Errata 727915
arch/arm/Kconfig | 15 ++++++++++++---
arch/arm/include/asm/outercache.h | 1 +
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/omap4-common.c | 7 +++++++
arch/arm/mm/cache-l2x0.c | 28 +++++++++++++++-------------
5 files changed, 36 insertions(+), 16 deletions(-)
^ permalink raw reply
* [PATCH 1/2] video: Add i.MX23/28 framebuffer driver
From: Shawn Guo @ 2011-02-18 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297850199-1688-2-git-send-email-s.hauer@pengutronix.de>
On Wed, Feb 16, 2011 at 10:56:38AM +0100, Sascha Hauer wrote:
> changes since v1:
> - Add a LCDC_ prefix to the register names.
> - use set/clear registers where appropriate
> - protect call to mxsfb_disable_controller() in mxsfb_remove()
> with a (host->enabled) as suggested by Lothar Wassmann
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Paul Mundt <lethal@linux-sh.org>
> Cc: linux-fbdev at vger.kernel.org
> Cc: Shawn Guo <shawn.guo@freescale.com>
> ---
> arch/arm/mach-mxs/include/mach/fb.h | 48 ++
> drivers/video/Kconfig | 9 +
> drivers/video/Makefile | 1 +
> drivers/video/mxsfb.c | 910 +++++++++++++++++++++++++++++++++++
> 4 files changed, 968 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-mxs/include/mach/fb.h
> create mode 100644 drivers/video/mxsfb.c
>
> diff --git a/arch/arm/mach-mxs/include/mach/fb.h b/arch/arm/mach-mxs/include/mach/fb.h
> new file mode 100644
> index 0000000..923f397
> --- /dev/null
> +++ b/arch/arm/mach-mxs/include/mach/fb.h
> @@ -0,0 +1,48 @@
> +/*
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301, USA.
> + */
> +
> +#ifndef __MACH_FB_H
> +#define __MACH_FB_H
> +
> +#include <linux/fb.h>
> +
> +#define STMLCDIF_8BIT 1 /** pixel data bus to the display is of 8 bit width */
> +#define STMLCDIF_16BIT 0 /** pixel data bus to the display is of 16 bit width */
> +#define STMLCDIF_18BIT 2 /** pixel data bus to the display is of 18 bit width */
> +#define STMLCDIF_24BIT 3 /** pixel data bus to the display is of 24 bit width */
> +
> +#define FB_SYNC_DATA_ENABLE_HIGH_ACT 64
> +
> +struct mxsfb_platform_data {
> + struct fb_videomode *mode_list;
> + unsigned mode_count;
> +
> + unsigned default_bpp;
> +
> + unsigned dotclk_delay; /* refer manual HW_LCDIF_VDCTRL4 register */
> + unsigned ld_intf_width; /* refer STMLCDIF_* macros */
> +
> + unsigned fb_size; /* Size of the video memory. If zero a
> + * default will be used
> + */
> + unsigned long fb_phys; /* physical address for the video memory. If
> + * zero the framebuffer memory will be dynamically
> + * allocated. If specified,fb_size must also be specified.
> + * fb_phys must be unused by Linux.
> + */
> +};
> +
> +#endif /* __MACH_FB_H */
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 6bafb51b..e0ea23f 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2365,6 +2365,15 @@ config FB_JZ4740
> help
> Framebuffer support for the JZ4740 SoC.
>
> +config FB_MXS
> + tristate "MXS LCD framebuffer support"
> + depends on FB && ARCH_MXS
> + select FB_CFB_FILLRECT
> + select FB_CFB_COPYAREA
> + select FB_CFB_IMAGEBLIT
> + help
> + Framebuffer support for the MXS SoC.
> +
> source "drivers/video/omap/Kconfig"
> source "drivers/video/omap2/Kconfig"
>
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index 8c8fabd..9a096ae 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -153,6 +153,7 @@ obj-$(CONFIG_FB_BFIN_T350MCQB) += bfin-t350mcqb-fb.o
> obj-$(CONFIG_FB_BFIN_7393) += bfin_adv7393fb.o
> obj-$(CONFIG_FB_MX3) += mx3fb.o
> obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o
> +obj-$(CONFIG_FB_MXS) += mxsfb.o
>
> # the test framebuffer is last
> obj-$(CONFIG_FB_VIRTUAL) += vfb.o
> diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
> new file mode 100644
> index 0000000..ac9939b
> --- /dev/null
> +++ b/drivers/video/mxsfb.c
> @@ -0,0 +1,910 @@
> +/*
> + * Copyright (C) 2010 Juergen Beisert, Pengutronix
> + *
> + * This code is based on:
> + * Author: Vitaly Wool <vital@embeddedalley.com>
> + *
> + * Copyright 2008-2009 Freescale Semiconductor, Inc. All Rights Reserved.
> + * Copyright 2008 Embedded Alley Solutions, Inc All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#define DRIVER_NAME "mxsfb"
> +
> +/**
> + * @file
> + * @brief LCDIF driver for i.MX23 and i.MX28
> + *
> + * The LCDIF support four modes of operation
> + * - MPU interface (to drive smart displays) -> not supported yet
> + * - VSYNC interface (like MPU interface plus Vsync) -> not supported yet
> + * - Dotclock interface (to drive LC displays with RGB data and sync signals)
> + * - DVI (to drive ITU-R BT656) -> not supported yet
> + *
> + * This driver depends on a correct setup of the pins used for this purpose
> + * (platform specific).
> + *
> + * For the developer: Don't forget to set the data bus width to the display
> + * in the imx_fb_videomode structure. You will else end up with ugly colours.
> + * If you fight against jitter you can vary the clock delay. This is a feature
> + * of the i.MX28 and you can vary it between 2 ns ... 8 ns in 2 ns steps. Give
> + * the required value in the imx_fb_videomode structure.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/platform_device.h>
> +#include <linux/clk.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/io.h>
> +#include <mach/fb.h>
> +#include <mach/hardware.h>
> +#include <mach/mxs.h>
> +
> +#define REG_SET 4
> +#define REG_CLR 8
> +
We already have these defined in mxs.h
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v2 1/1] ARM: imx53: correct Silicon Revision definition following fuse map
From: Richard Zhao @ 2011-02-18 12:26 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
diff --git a/arch/arm/mach-mx5/cpu.c b/arch/arm/mach-mx5/cpu.c
index d40671d..df46b5e 100644
--- a/arch/arm/mach-mx5/cpu.c
+++ b/arch/arm/mach-mx5/cpu.c
@@ -78,11 +78,16 @@ static int get_mx53_srev(void)
void __iomem *iim_base = MX51_IO_ADDRESS(MX53_IIM_BASE_ADDR);
u32 rev = readl(iim_base + IIM_SREV) & 0xff;
- if (rev == 0x0)
+ switch (rev) {
+ case 0x0:
return IMX_CHIP_REVISION_1_0;
- else if (rev == 0x10)
+ case 0x2:
return IMX_CHIP_REVISION_2_0;
- return 0;
+ case 0x3:
+ return IMX_CHIP_REVISION_2_1;
+ default:
+ return IMX_CHIP_REVISION_UNKNOWN;
+ }
}
/*
--
1.7.1
^ permalink raw reply related
* [PATCH] ARM: gic: use handle_fasteoi_irq for SPIs
From: Will Deacon @ 2011-02-18 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1102181240370.2701@localhost6.localdomain6>
> > I don't think the cascaded handlers would have assumed that because ack
> > just sends EOI - it doesn't do any masking. We do have a problem with
> > the percpu_irq flow though (the GIC reference manual says that EOIing a
> > non-active interrupt is UNPREDICTABLE).
> >
> > Another easy hack is to set IRQ_PER_CPU in the irq_desc->status for PPI
> > interrupts and then check this in the ack routine. It's pretty ugly, but
> > it doesn't affect the common case and it at least postpones the platform
> > changes.
>
> Conditionals in irq_chip callbacks are almost always a sign of
> doom. Don't do that.
Ok, that was a hack too far! Let's fix this properly.
> How many chained handlers need to be fixed, when the whole gic stuff
> switches to eoi ?
Well, grepping for set_chained_irq_handler yields a whole bunch of platforms
but the set of these which appear to use the gic is only:
mach-msm
mach-s5pv310
mach-shmobile
mach-tegra
I'll have a look through the code there and post some patches next week.
Hopefully if I've missed anybody, they'll shout then.
Cheers,
Will
^ permalink raw reply
* [PATCH 1/7] Add a mfd IPUv3 driver
From: Samuel Ortiz @ 2011-02-18 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110218094949.GJ24426@pengutronix.de>
Hi Sascha,
On Fri, Feb 18, 2011 at 10:49:49AM +0100, Sascha Hauer wrote:
> On Thu, Feb 17, 2011 at 07:10:24PM +0100, Arnaud Patard wrote:
> > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > index 6bafb51b..ffdb37a 100644
> > > --- a/drivers/video/Kconfig
> > > +++ b/drivers/video/Kconfig
> > > @@ -26,6 +26,8 @@ source "drivers/gpu/drm/Kconfig"
> > >
> > > source "drivers/gpu/stub/Kconfig"
> > >
> > > +source "drivers/video/imx-ipu-v3/Kconfig"
> > > +
> >
> > I don't see such a Kconfig file in this patch. Got lost while moving
> > from mfd to video ?
>
> Oops, yes still untracked in my repository. Will add in the next series.
>
> >
> >
> > > config VGASTATE
> > > tristate
> > > default n
> > > diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> > > index 8c8fabd..f4921ab 100644
> > > --- a/drivers/video/Makefile
> > > +++ b/drivers/video/Makefile
> > > @@ -153,6 +153,7 @@ obj-$(CONFIG_FB_BFIN_T350MCQB) += bfin-t350mcqb-fb.o
> > > obj-$(CONFIG_FB_BFIN_7393) += bfin_adv7393fb.o
> > > obj-$(CONFIG_FB_MX3) += mx3fb.o
> > > obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o
> > > +obj-$(CONFIG_MFD_IMX_IPU_V3) += imx-ipu-v3/
> >
> > Now that files are in drivers/video, do we want to keep MFD in the name ?
>
> I asked myself the same question and had no clear answer. Probably
> better to remove the MFD.
Definitely, yes.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
From: Santosh Shilimkar @ 2011-02-18 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikEjTgisftQV46djrOP8iWMFV267v-efHsVf_Nd@mail.gmail.com>
> -----Original Message-----
> From: catalin.marinas at gmail.com [mailto:catalin.marinas at gmail.com]
> On Behalf Of Catalin Marinas
> Sent: Wednesday, February 16, 2011 9:24 PM
> To: Santosh Shilimkar
> Cc: linux-arm-kernel at lists.infradead.org; Andrei Warkentin; Kevin
> Hilman; tony at atomide.com; linux-omap at vger.kernel.org
> Subject: Re: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way
> operation can cause data corruption
>
> On 15 February 2011 07:14, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1140,7 +1140,7 @@ config ARM_ERRATA_742231
> >
> > ?config PL310_ERRATA_588369
> > ? ? ? ?bool "Clean & Invalidate maintenance operations do not
> invalidate
> > clean lines"
> > - ? ? ? depends on CACHE_L2X0 && ARCH_OMAP4
> > + ? ? ? depends on CACHE_L2X0 && CACHE_PL310
>
> It can just depend on CACHE_PL310 as this depends on CACHE_L2X0.
>
With CACHE_PL310 alone, I get below warning.
warning: (ARCH_OMAP4) selects PL310_ERRATA_588369 which has unmet direct
dependencies (CACHE_PL310)
This is coming because Pl310 can't be selected on V6 and OMAP
common build has V6 and V7 both enabled.
So to avoid the warning and also able to select the errata in
OMAP build, I am making the errata's depends on CACHE_L2X0
with comment.
Regards,
Santosh
^ permalink raw reply
* [PATCH] ARM: gic: use handle_fasteoi_irq for SPIs
From: Thomas Gleixner @ 2011-02-18 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001d01cbcf5f$1cfc9870$56f5c950$@deacon@arm.com>
On Fri, 18 Feb 2011, Will Deacon wrote:
> > >> Right, so to get back to the original discussion about how to handle
> > >> chained handlers if the high-level flow type of the IRQ chip is altered
> > >> it seems that there are two options:
> > >>
> > >> 1.) Update all of the chained handlers to use the new flow-control
> > >> 2.) Retain backwards compatibility if a chained handler decides to
> > >> use the old method of flow control (specifically, leave an ack
> > >> implementation in the GIC code after moving to fasteoi).
> > >>
> > >> Obviously, I'd rather go with option (2) and let platforms migrate
> > >> over time if they choose to. Now, given that the ack function is really
> > >> not something you want to do in a virtualised environment (because it
> > >> pokes the distributor), is it worth sticking a
> > >> WARN_ON_ONCE(cpu_has_virtualisation()); in the ack code?
> > >
> > > #2 is less painful and just works. The fasteoi stuff does not use ack
> > > IIRC so it wont hurt.
> >
> > On an MSM we use handle_percpu_irq for PPIs, if we have ack and eoi we
> > will end up EOI ing the interrupt twice so #2 wont work. Also all the
> > cascaded handlers would have assumed that the ack function masks the
> > interrupt, it is best we fix all of them to use eoi at the end (just
> > like handle_fasteoi_irq). Please tell me how you guys locate such
> > cascaded handlers?
>
> I don't think the cascaded handlers would have assumed that because ack
> just sends EOI - it doesn't do any masking. We do have a problem with
> the percpu_irq flow though (the GIC reference manual says that EOIing a
> non-active interrupt is UNPREDICTABLE).
>
> Another easy hack is to set IRQ_PER_CPU in the irq_desc->status for PPI
> interrupts and then check this in the ack routine. It's pretty ugly, but
> it doesn't affect the common case and it at least postpones the platform
> changes.
Conditionals in irq_chip callbacks are almost always a sign of
doom. Don't do that.
How many chained handlers need to be fixed, when the whole gic stuff
switches to eoi ?
Thanks,
tglx
^ permalink raw reply
* [PATCH 00/11] Rationalize and consolidate ARMs evaluation boards
From: Catalin Marinas @ 2011-02-18 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110127134532.GE25968@n2100.arm.linux.org.uk>
On Thu, 2011-01-27 at 13:45 +0000, Russell King - ARM Linux wrote:
> This series, which applies on top of the CLCD series consolidates some
> of the code used on ARM platforms, in particular the FPGA interrupt,
> local timer, and SMP bring up code.
>
> We also add sched_clock() support for Integrator/CP, but only when we're
> building only for Integrator/CP as Integrator/AP platforms don't have
> the 24MHz counter. We also move the sched_clock() initialization to
> the early init callback, along with registering the clock lookups.
>
> As we know how DMA is to be supported with primecells, we no longer need
> the DMA definitions which aren't used, so these are removed.
The whole series looks fine (acked. if you need one).
--
Catalin
^ permalink raw reply
* [PATCHv2 1/2] ARM: perf_event: allow platform-specific interrupt handler
From: Will Deacon @ 2011-02-18 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=ph8U3qGFgfhc15SNuYcj6oSUq8VPyJ+h_8b5O@mail.gmail.com>
> On Thu, Feb 17, 2011 at 22:03, Will Deacon <will.deacon@arm.com> wrote:
> >> I gave this a try, along with the modifications to enable IRQ_PER_CPU
> >> and have the pmu code use the appropriate flags and set the affinity.
> >> Didn't work though; it always ends up triggering the spurious IRQ check.
> >
> > Hmm, that doesn't sound right. Did you have any synchronisation to ensure
> > that the CPU without the overflow didn't return IRQ_NONE until the handling
> > CPU had returned IRQ_HANDLED?
>
> No. What kind of synchronization do you mean?
Well my guess is that the CPU returning IRQ_NONE is perpetually taking the
same interrupt until the other CPU has poked the PMU to stop it asserting
the line (otherwise I can't see how the spurious check would trip). You could
have a lock in the driver to synchronise between the two CPUs so that if you
don't have an overflow, you wait for the other CPU to clear the interrupt before
returning.
This has quickly started to become horrible but I was just curious as to whether
it provides better results than the affinity-setting approach (which is certainly
less invasive).
Cheers,
Will
^ permalink raw reply
* [PATCH] ARM: gic: use handle_fasteoi_irq for SPIs
From: Will Deacon @ 2011-02-18 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D5DB193.5010007@codeaurora.org>
> >> Right, so to get back to the original discussion about how to handle
> >> chained handlers if the high-level flow type of the IRQ chip is altered
> >> it seems that there are two options:
> >>
> >> 1.) Update all of the chained handlers to use the new flow-control
> >> 2.) Retain backwards compatibility if a chained handler decides to
> >> use the old method of flow control (specifically, leave an ack
> >> implementation in the GIC code after moving to fasteoi).
> >>
> >> Obviously, I'd rather go with option (2) and let platforms migrate
> >> over time if they choose to. Now, given that the ack function is really
> >> not something you want to do in a virtualised environment (because it
> >> pokes the distributor), is it worth sticking a
> >> WARN_ON_ONCE(cpu_has_virtualisation()); in the ack code?
> >
> > #2 is less painful and just works. The fasteoi stuff does not use ack
> > IIRC so it wont hurt.
>
> On an MSM we use handle_percpu_irq for PPIs, if we have ack and eoi we
> will end up EOI ing the interrupt twice so #2 wont work. Also all the
> cascaded handlers would have assumed that the ack function masks the
> interrupt, it is best we fix all of them to use eoi at the end (just
> like handle_fasteoi_irq). Please tell me how you guys locate such
> cascaded handlers?
I don't think the cascaded handlers would have assumed that because ack
just sends EOI - it doesn't do any masking. We do have a problem with
the percpu_irq flow though (the GIC reference manual says that EOIing a
non-active interrupt is UNPREDICTABLE).
Another easy hack is to set IRQ_PER_CPU in the irq_desc->status for PPI
interrupts and then check this in the ack routine. It's pretty ugly, but
it doesn't affect the common case and it at least postpones the platform
changes.
Will
^ permalink raw reply
* [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG
From: Premi, Sanjeev @ 2011-02-18 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297946466-9565-6-git-send-email-balbi@ti.com>
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Balbi, Felipe
> Sent: Thursday, February 17, 2011 6:11 PM
> To: Tony Lindgren
> Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List; Kalliguddi,
> Hema; Kevin Hilman; Cousson, Benoit; Paul Walmsley; Balbi, Felipe
> Subject: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG
>
> From: Hema HK <hemahk@ti.com>
>
> AM35xx hwmod data structures are populated for USBOTG with base address,
> L3 and L4 interface clocks and IRQ.
>
> Signed-off-by: Hema HK <hemahk@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: Cousson, Benoit <b-cousson@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 65
> ++++++++++++++++++++++++++++
> 1 files changed, 65 insertions(+), 0 deletions(-)
>
[snip]
>
> + /* usbotg for am35x */
> + &am35xx_usbhsotg_hwmod,
> +
> NULL,
Felipe, Hema,
This patch will break all existing OMAP35x (and I believe
OMAP3430 - since there is no difference - unless there is
some trick in the USB driver code).
I have seen similar problems with smart reflex included in
the AM35x hwmod data.
In this case accessing "unknown" registers corresponding to
SmartReflex in _setup() causes crash.
(http://marc.info/?l=linux-omap&m=129777408503329&w=2)
I expect similar to be happening on OMAP35x with inclusion
of am35xx_usbhsotg_hwmod. If you don't see any crash, there
would be side-effects - and _setup() would be initializing
non-existent OTG registers on OMAP35x.
Did you see any problems while testing?
~sanjeev
PS: Sending mail via webmailer. Formatting may break
> };
>
> --
> 1.7.4.rc2
>
> --
> 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
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