RE: Requirement for DSI video mode support

[Taneja, Archit]

Hi,

Tomi Valkeinen wrote:
> Hi,
> 
> On Mon, 2010-09-20 at 22:18 +0200, ext Jorge Bustamante wrote:
>> Hi,
>> 
>> We (TI) have been working on a DSI video mode driver for OMAP4 and I
> 
> I hope it's also for OMAP3?
> 
>> am aware that other people are working with similar drivers. We had to
>> tweak the code to make the drivers work with current code but we would
>> like to make it the correct way, that is, introducing a proper
>> functionality instead of inserting tweaks in the present command mode
>> driver. Therefore, there is an initiative from us to modify current
>> dss/dsi code to support DSI video mode.
>> 
>> We have collected a list of requirements and ideas (with the help of
>> ppl copied) from our experience working with these drivers, but it
>> would be great if you can discuss/comment further on this.
>> 
>> Requirements:
>> 
>> - A better way of exposing VC's to a panel driver, since most panels
>> use more than one VC. Currently the design supports only one per
>> panel. Perhaps a VC resource pool could be created.
> 
> Hmm, why would most panels use more than one VC? I haven't
> seen a single one =).

Command mode panels will work fine with a single VC, I don't think video mode
can run by using only one VC.

Also, for command mode, there isn't a restriction to use a single VC. If you
configure one VC to have slave port as source and the other as video port, the 
need
to switch the VC source between L4 and VP would go away.

The most optimal way would be to use one VC for each peripheral, but I don't 
think
the usecase of connecting 4 panels to the same DSI lanes would ever be needed.

> 
> Nevertheless, it should be possible to use multiple VCs in one driver.
> I've implemented a driver for a buffer chip that used all 4 channels.

So did you connect more than one panel to DSI? I am curious about how it works

[snip]

>> 
>> - If we want a user to switch between modes, we may need to have a
> 
> While I don't see any reason to forbid changing modes, I
> don't see any real reason to implement switching between the
> modes either. If it comes for free, sure, but if it means
> lots of implementation, I'd rather leave it out. Or do you
> have some use cases where switching modes is important?
> 

There isn't any use case where we would use a panel for video mode and
command mode at different points in time. But if the panel supports both
video and command mode there should be some option (compile time/ boot time)
to choose which mode is to be used. I guess its more for the sake of 
completeness
of the panels capabilities.

Regards,

Archit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/5] omap: mailbox: initial hwmod support for omap3

[Varadarajan, Charulatha]

 

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org 
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
> Ramirez Luna, Omar
> Sent: Wednesday, October 27, 2010 3:23 AM
> To: Tony Lindgren; Hiroshi DOYU
> Cc: Felipe Contreras; Dmitry Kasatkin; Kevin Hilman; Ramirez 
> Luna, Omar; Anna, Suman; Paul Walmsley; Cousson, Benoit; 
> Raja, Govindraj; C.A, Subramaniam; linux-omap@vger.kernel.org
> Subject: [PATCH 1/5] omap: mailbox: initial hwmod support for omap3
> 
> From: Felipe Contreras 
> 
> HWMOD support for omap3.

Use "hwmod".

> 
> Signed-off-by: Felipe Contreras 
> Signed-off-by: Omar Ramirez Luna 
> ---
>  arch/arm/mach-omap2/devices.c  |  100 
> ---
>  arch/arm/mach-omap2/mailbox.c  |1 +
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   54 +++
>  3 files changed, 70 insertions(+), 85 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/devices.c 
> b/arch/arm/mach-omap2/devices.c
> index eaf3799..d977572 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -141,95 +141,25 @@ static inline void omap_init_camera(void)
>  #endif
>  
>  #if defined(CONFIG_OMAP_MBOX_FWK) || 
> defined(CONFIG_OMAP_MBOX_FWK_MODULE)
> -
> -#define MBOX_REG_SIZE   0x120
> -
> -#ifdef CONFIG_ARCH_OMAP2
> -static struct resource omap2_mbox_resources[] = {
> - {
> - .start  = OMAP24XX_MAILBOX_BASE,
> - .end= OMAP24XX_MAILBOX_BASE + 
> MBOX_REG_SIZE - 1,
> - .flags  = IORESOURCE_MEM,
> - },
> - {
> - .start  = INT_24XX_MAIL_U0_MPU,
> - .flags  = IORESOURCE_IRQ,
> - .name   = "dsp",
> - },
> - {
> - .start  = INT_24XX_MAIL_U3_MPU,
> - .flags  = IORESOURCE_IRQ,
> - .name   = "iva",
> - },
> -};
> -static int omap2_mbox_resources_sz = 
> ARRAY_SIZE(omap2_mbox_resources);
> -#else
> -#define omap2_mbox_resources NULL
> -#define omap2_mbox_resources_sz  0
> -#endif
> -
> -#ifdef CONFIG_ARCH_OMAP3
> -static struct resource omap3_mbox_resources[] = {
> - {
> - .start  = OMAP34XX_MAILBOX_BASE,
> - .end= OMAP34XX_MAILBOX_BASE + 
> MBOX_REG_SIZE - 1,
> - .flags  = IORESOURCE_MEM,
> - },
> - {
> - .start  = INT_24XX_MAIL_U0_MPU,
> - .flags  = IORESOURCE_IRQ,
> - .name   = "dsp",
> - },
> -};
> -static int omap3_mbox_resources_sz = 
> ARRAY_SIZE(omap3_mbox_resources);
> -#else
> -#define omap3_mbox_resources NULL
> -#define omap3_mbox_resources_sz  0
> -#endif
> -
> -#ifdef CONFIG_ARCH_OMAP4
> -
> -#define OMAP4_MBOX_REG_SIZE  0x130
> -static struct resource omap4_mbox_resources[] = {
> - {
> - .start  = OMAP44XX_MAILBOX_BASE,
> - .end= OMAP44XX_MAILBOX_BASE +
> - OMAP4_MBOX_REG_SIZE - 1,
> - .flags  = IORESOURCE_MEM,
> - },
> - {
> - .start  = OMAP44XX_IRQ_MAIL_U0,
> - .flags  = IORESOURCE_IRQ,
> - .name   = "mbox",
> - },
> -};
> -static int omap4_mbox_resources_sz = 
> ARRAY_SIZE(omap4_mbox_resources);
> -#else
> -#define omap4_mbox_resources NULL
> -#define omap4_mbox_resources_sz  0
> -#endif
> -
> -static struct platform_device mbox_device = {
> - .name   = "omap-mailbox",
> - .id = -1,
> -};
> -
>  static inline void omap_init_mbox(void)
>  {
> - if (cpu_is_omap24xx()) {
> - mbox_device.resource = omap2_mbox_resources;
> - mbox_device.num_resources = omap2_mbox_resources_sz;
> - } else if (cpu_is_omap34xx()) {
> - mbox_device.resource = omap3_mbox_resources;
> - mbox_device.num_resources = omap3_mbox_resources_sz;
> - } else if (cpu_is_omap44xx()) {
> - mbox_device.resource = omap4_mbox_resources;
> - mbox_device.num_resources = omap4_mbox_resources_sz;
> - } else {
> - pr_err("%s: platform not supported\n", __func__);
> + struct omap_hwmod *oh;
> + struct omap_device *od;
> +
> + oh = omap_hwmod_lookup("mailbox");
> + if (!oh) {
> + pr_err("%s: unable to find hwmod\n", __func__);
> + return;
> + }
> +
> + od = omap_device_build("omap-mailbox", -1, oh,
> + NULL, 0,
> + NULL, 0,
> + 0);

This patch series breaks OMAP4 support.

OMAP2 support is broken with this patch and the same is fixed
in the next patch. Hence patch 2 should be ordered before patch 1. 

> + if (!od) {
> + pr_err("%s: could not build device\n", __func__);
>   return;
>   }
> - platform_device_register(&mbo

RE: [PATCH 2/5] omap: mailbox: initial hwmod support for omap2

[Varadarajan, Charulatha]

 

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org 
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Omar 
> Ramirez Luna
> Sent: Wednesday, October 27, 2010 3:23 AM
> To: Tony Lindgren; Hiroshi DOYU
> Cc: Felipe Contreras; Dmitry Kasatkin; Kevin Hilman; Ramirez 
> Luna, Omar; Anna, Suman; Paul Walmsley; Cousson, Benoit; 
> Raja, Govindraj; C.A, Subramaniam; linux-omap@vger.kernel.org
> Subject: [PATCH 2/5] omap: mailbox: initial hwmod support for omap2
> 
> HWMOD support for omap2430 and 2420.

It is preferred to use the following $Subject while adding hwmod data
"OMAP2: hwmod data: Add mailbox"

-V Charulatha

<>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 4/5] omap: mailbox: fix detection for previously supported chips

[Varadarajan, Charulatha]

 

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org 
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
> Ramirez Luna, Omar
> Sent: Wednesday, October 27, 2010 3:23 AM
> To: Tony Lindgren; Hiroshi DOYU
> Cc: Felipe Contreras; Dmitry Kasatkin; Kevin Hilman; Ramirez 
> Luna, Omar; Anna, Suman; Paul Walmsley; Cousson, Benoit; 
> Raja, Govindraj; C.A, Subramaniam; linux-omap@vger.kernel.org
> Subject: [PATCH 4/5] omap: mailbox: fix detection for 
> previously supported chips
> 
> Fix the mailbox detection for OMAP3630 and 2430, also minor
> cleanup on conditional ifdef's that could affect it.
> 
> Given that 2430 has an iva too include it, as the same steps
> for omap3 apply.
> 
> Signed-off-by: Omar Ramirez Luna 
> ---
>  arch/arm/mach-omap2/mailbox.c |   16 ++--
>  1 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/mailbox.c 
> b/arch/arm/mach-omap2/mailbox.c
> index 61f2149..b8fd120 100644
> --- a/arch/arm/mach-omap2/mailbox.c
> +++ b/arch/arm/mach-omap2/mailbox.c
> @@ -277,7 +277,7 @@ static struct omap_mbox_ops omap2_mbox_ops = {
>  
>  /* FIXME: the following structs should be filled 
> automatically by the user id */
>  
> -#if defined(CONFIG_ARCH_OMAP3430) || defined(CONFIG_ARCH_OMAP2420)
> +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP2)
>  /* DSP */
>  static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
>   .tx_fifo = {
> @@ -302,7 +302,7 @@ struct omap_mbox mbox_dsp_info = {
>  };
>  #endif
>  
> -#if defined(CONFIG_ARCH_OMAP3430)
> +#if defined(CONFIG_ARCH_OMAP3)
>  struct omap_mbox *omap3_mboxes[] = { &mbox_dsp_info, NULL };
>  #endif
>  
> @@ -390,15 +390,19 @@ static int __devinit 
> omap2_mbox_probe(struct platform_device *pdev)
>  
>   if (false)
>   ;
> -#if defined(CONFIG_ARCH_OMAP3430)
> - else if (cpu_is_omap3430()) {
> +#if defined(CONFIG_ARCH_OMAP3)
> + else if (cpu_is_omap34xx()) {

Use cpu_is_* check only. No need to have #if CONFIG_ARCH_* checks.

>   list = omap3_mboxes;
>  
>   list[0]->irq = platform_get_irq_byname(pdev, "dsp");
>   }
>  #endif
> -#if defined(CONFIG_ARCH_OMAP2420)
> - else if (cpu_is_omap2420()) {
> +#if defined(CONFIG_ARCH_OMAP2)
> + else if (cpu_is_omap2430()) {
> + list = omap2_mboxes;
> +
> + list[0]->irq = platform_get_irq_byname(pdev, "dsp");
> + } else if (cpu_is_omap2420()) {

Ditto

>   list = omap2_mboxes;
>  
>   list[0]->irq = platform_get_irq_byname(pdev, "dsp");
> -- 
> 1.7.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v3 00/13] OMAP: DMA: hwmod and DMA as platform device

[G, Manjunath Kondaiah]

Hi, 

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org 
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G, 
> Manjunath Kondaiah
> Sent: Tuesday, October 26, 2010 6:55 PM
> To: linux-omap@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org; Cousson, Benoit; 
> Kevin Hilman; Shilimkar, Santosh
> Subject: [PATCH v3 00/13] OMAP: DMA: hwmod and DMA as platform device
> 
> This patch series converts DMA library into platform device 
> and hwmod adaptation is done for omap2+ processors.
> 
[...]
> 
> G, Manjunath Kondaiah (12):
[...]
>   OMAP: DMA: Use DMA device attributes

Looks like this patch is not getting posted due to its size(~105 KB)
The patch is available for review comments at:
http://dev.omapzoom.org/?p=manju/kernel-omap3-dev.git;a=commitdiff;h=7457a6b4248772aaa52dfb13a170f891596a512a

-Manjunath--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v3 01/13] OMAP: DMA: Replace read/write macros with functions

[G, Manjunath Kondaiah]

 

> -Original Message-
> From: Menon, Nishanth 
> Sent: Tuesday, October 26, 2010 8:19 PM
> To: G, Manjunath Kondaiah
> Cc: linux-omap@vger.kernel.org; 
> linux-arm-ker...@lists.infradead.org; Cousson, Benoit; Kevin 
> Hilman; Shilimkar, Santosh
> Subject: Re: [PATCH v3 01/13] OMAP: DMA: Replace read/write 
> macros with functions
> 
> G, Manjunath Kondaiah had written, on 10/26/2010 08:25 AM, 
> the following:
> [...]
> > 
> > diff --git a/arch/arm/plat-omap/dma.c 
> b/arch/arm/plat-omap/dma.c index 
> > f5c5b8d..77241e2 100644
> > --- a/arch/arm/plat-omap/dma.c
> > +++ b/arch/arm/plat-omap/dma.c
> > @@ -40,6 +40,147 @@
> > 
[...]
> > +static u16 reg_map_omap2[] = {
> > +   [REVISION]  = 0x00,
> > +   [GCR2]  = 0x78,
> > +   [IRQSTATUS_L0]  = 0x08,
> > +   [IRQSTATUS_L1]  = 0x0c,
> [..]
> > +   /* OMAP4 specific registers */
> > +   [CDP]   = 0xd0,
> > +   [CNDP]  = 0xd4,
> > +   [CCDN]  = 0xd8,
> > +};
> > +
> dumb question: any reason why a struct wont do?
> struct reg_map_omap2 {
> u16 revision;
> ...
> ...
> }

This approach is as per i2c driver as suggested by kevin. 
http://www.spinics.net/lists/linux-omap/msg36446.html

> 
> [..]
> > 
> > -#define dma_read(reg)  
> \
> > -({ 
> \
> > -   u32 __val;  
> \
> > -   if (cpu_class_is_omap1())   
> \
> > -   __val = __raw_readw(omap_dma_base + 
> OMAP1_DMA_##reg);   \
> > -   else
> \
> > -   __val = __raw_readl(omap_dma_base + 
> OMAP_DMA4_##reg);   \
> > -   __val;  
> \
> > -})
> > -
> > -#define dma_write(val, reg)
> \
> > -({ 
> \
> > -   if (cpu_class_is_omap1())   
> \
> > -   __raw_writew((u16)(val), omap_dma_base + 
> OMAP1_DMA_##reg); \
> > -   else
> \
> > -   __raw_writel((val), omap_dma_base + 
> OMAP_DMA4_##reg);   \
> > -})
> > +static inline void dma_write(u32 val, int reg, int lch) {
> > +   if (cpu_class_is_omap1()) {
> > +   if (reg > OMAP1_CH_COMMON_START)
> > +   __raw_writew(val, dma_base +
> > +   (reg_map_omap1[reg] + 0x40 * lch));
> > +   else
> > +   __raw_writew(val, dma_base + 
> reg_map_omap1[reg]);
> > +   } else {
> > +   if (reg > OMAP2_CH_COMMON_START)
> > +   __raw_writel(val, dma_base +
> > +   (reg_map_omap2[reg] + 0x60 * lch));
> > +   else
> > +   __raw_writel(val, dma_base + 
> reg_map_omap2[reg]);
> > +   }
> > +}
> > +
> > +static inline u32 dma_read(int reg, int lch) {
> > +   u32 val;
> > +
> > +   if (cpu_class_is_omap1()) {
> > +   if (reg > OMAP1_CH_COMMON_START)
> > +   val = __raw_readw(dma_base +
> > +   (reg_map_omap1[reg] 
> + 0x40 * lch));
> > +   else
> > +   val = __raw_readw(dma_base + 
> reg_map_omap1[reg]);
> > +   } else {
> > +   if (reg > OMAP2_CH_COMMON_START)
> > +   val = __raw_readl(dma_base +
> > +   (reg_map_omap2[reg] 
> + 0x60 * lch));
> > +   else
> > +   val = __raw_readl(dma_base + 
> reg_map_omap2[reg]);
> > +   }
> > +   return val;
> > +}
> What is the benefit of using inline function here? would'nt 
> we increase code size? cant we use a function pointer 
> initialized to class1 or rest? 
> Quote from CodingStyle (15):
> "A reasonable rule of thumb is to not put inline at functions 
> that have more than 3 lines of code in them. An exception to 
> this rule are the cases where a parameter is known to be a 
> compiletime constant, and as a result of this constantness 
> you *know* the compiler will be able to optimize most of your 
> function away at compile time. For a good example of this 
> later case, see the kmalloc() inline function.
> "
> is the expectation that cpu_class_is_omap1 compile time 
> constant hence the actual compiled in code is smaller 
> -candidate for inline?

Detailed discussion and alignment can be found at:
http://www.spinics.net/lists/linux-omap/thrd6.html

Search for:
[PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device registration


> 
> > 
> >  #ifdef CONFIG_ARCH_OMAP15XX
> >  /* Returns 1 if the DMA module is in OMAP1510-compatib

Re: [linux-pm] [PATCH] PERF(kernel): Cleanup power events V2

[Mathieu Desnoyers]

* Rafael J. Wysocki (r...@sisk.pl) wrote:
> On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
> > * Alan Stern (st...@rowland.harvard.edu) wrote:
> > > On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
> > > 
> > > > * Peter Zijlstra (pet...@infradead.org) wrote:
> > > > > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> > > > > > 
> > > > > > +   trace_runtime_pm_usage(dev, 
> > > > > > atomic_read(&dev->power.usage_count)+1);
> > > > > > atomic_inc(&dev->power.usage_count); 
> > > > > 
> > > > > That's terribly racy..
> > > > 
> > > > Looking at the original code, it looks racy even without considering the
> > > > tracepoint:
> > > > 
> > > > int __pm_runtime_get(struct device *dev, bool sync)
> > > >  {
> > > > int retval;
> > > > 
> > > > +   trace_runtime_pm_usage(dev, 
> > > > atomic_read(&dev->power.usage_count)+1);
> > > > atomic_inc(&dev->power.usage_count);
> > > > retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);
> > > > 
> > > > There is no implied memory barrier after "atomic_inc". So either all 
> > > > these
> > > > inc/dec are protected with mutexes or spinlocks, in which case one 
> > > > might wonder
> > > > why atomic operations are used at all, or it's a racy mess. (I vote for 
> > > > the
> > > > second option)
> > > 
> > > I don't understand.  What's the problem?  The inc/dec are atomic 
> > > because they are not protected by spinlocks, but everything else is 
> > > (aside from the tracepoint, which is new).
> > > 
> > > > kref should certainly be used there.
> > > 
> > > What for?
> > 
> > kref has the following "get":
> > 
> > atomic_inc(&kref->refcount);
> > smp_mb__after_atomic_inc();
> > 
> > What seems to be missing in __pm_runtime_get() and 
> > pm_runtime_get_noresume() is
> > the memory barrier after the atomic increment. The atomic increment is free 
> > to
> > be reordered into the following spinlock (within pm_request_resume or 
> > pm_request
> > resume execution) because taking a spinlock only acts as a memory barrier 
> > with
> > acquire semantic, not a full memory barrier.
> >
> > So AFAIU, the failure scenario would be as follows (sorry for the 80+ 
> > columns):
> > 
> > initial conditions: usage_count = 1
> > 
> > CPU A   CPU B
> > 1) __pm_runtime_get() (sync = true)
> > 2)   atomic_inc(&usage_count) (not committed to memory yet)
> > 3)   pm_runtime_resume()
> > 4) spin_lock_irqsave(&dev->power.lock, flags);
> > 5) retval = __pm_request_resume(dev);
> 
> If sync = true this is
>retval = __pm_runtime_resume(dev);
> which drops and reacquires the spinlock.

Let's see. Upon entry in __pm_runtime_resume, the following condition holds
(remember, the initial condition is that usage_count == 1):

  dev->power.runtime_status == RPM_ACTIVE

so retval is set to 1, which goto directly to "out", without setting "parent".
So there does not seem to be any spinlock reacquire on this path, or am I
misunderstanding how the "runtime_status" works ?

> In the meantime it sets
> ->power.runtime_status so that __pm_runtime_idle() will fail if run at this
> point.

runtime_status will be left at "RPM_ACTIVE", which is the appropriate value
expected by __pm_runtime_idle.

> 
> > 6) (execute the body of __pm_request_resume and return)
> > 7)  
> > __pm_runtime_put() (sync = true) 
> > 8)  if 
> > (atomic_dec_and_test(&dev->power.usage_count))
> >   (still see 
> > usage_count == 1 before decrement,
> >thus 
> > decrement to 0)
> > 9) 
> > pm_runtime_idle()
> > 10)  spin_unlock_irqrestore(&dev->power.lock, flags)
> > 11)
> > spin_lock_irq(&dev->power.lock);
> > 12)retval = 
> > __pm_runtime_idle(dev);
> 
> Moreover, __pm_runtime_idle() checks ->power.usage_count under the spinlock,
> so it will see it's been incremented in the meantime and it will back off.

This is a subtle but important point. Yes, my scenario seems to be dealt with by
the extra usage_count check while the spinlock is held.

How about adding a comment under this atomic_inc() stating that the memory
barriers are implicitely dealt with by the following spinlock release and the
extra check while spinlock is held ?

Commenting memory barriers is important, but commenting why memory barriers are
not needed due to a subtle corner-case looks even more important.

(hrm, but more below considering pm_runtime_get_noresume())

> 
> > 13)
> > spin_unlock_irq(&dev->power.lock);
> > 
> > So we end up in a situatio

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Thomas Renninger]

On Tuesday 26 October 2010 08:57:01 pm Rafael J. Wysocki wrote:
> On Tuesday, October 26, 2010, Thomas Renninger wrote:
> > > 
> > > Ok, that's at least generic. Needs the review of Rafael, to determine
> > > whether this state value is all we want to know when we enter suspend.
> > He already gave an acked-by on this generic one here:
> > Re: [PATCH 3/4] perf: add calls to suspend trace point
> > Oh now, that was on the X86 specific part which depends on this one.
> > One should expect that he's fine with the generic part as well then,
> > but I agree that he should definitely have a look at this and sign it off.
> 
> What patch exactly do you mean?  I'm not quite sure from your comment above.

Eh, Jean's patch, sorry about that.
Needs a tiny change to use PWR_EVENT_EXIT instead of 0 with
my new patch series:

Signed-off-by: Jean Pihet 
CC: Thomas Renninger 
Acked-by: Rafael J. Wysocki 

---
 kernel/power/suspend.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 7335952..10cad5c 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "power.h"
 
@@ -164,7 +165,9 @@ static int suspend_enter(suspend_state_t state)
error = sysdev_suspend(PMSG_SUSPEND);
if (!error) {
if (!suspend_test(TEST_CORE) && pm_check_wakeup_events()) {
+   trace_machine_suspend(state);
error = suspend_ops->enter(state);
+   trace_machine_suspend(0);
events_check_enabled = false;
}
sysdev_resume();
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] PERF(kernel): Cleanup power events V3

[Thomas Renninger]

Changes in V3:
  - PWR_EVENT_EXIT is -1 now instead of 0x
  - Use cpu_{idle,frequency} instead of processor_{idle,frequency}
events
  - Fixed a copy and paste bug (poll_idle should throw and event
state of zero, not 1)

Changes in V2:
  - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
  - Use u32 instead of u64 for cpuid, state which is by far enough

New power trace events:
power:cpu_idle
power:cpu_frequency
power:machine_suspend


C-state/idle accounting events:
  power:power_start
  power:power_end
are replaced with:
  power:cpu_idle

and
  power:power_frequency
is replaced with:
  power:cpu_frequency

power:machine_suspend
is newly introduced, a first implementation
comes from the ARM side, but it's easy to add these events
in X86 as well if needed.

the type= field got removed from both, it was never
used and the type is differed by the event type itself.

perf timechart
userspace tool gets adjusted in a separate patch.

Signed-off-by: Thomas Renninger 
Signed-off-by: Arjan van de Ven 
CC: linux-omap@vger.kernel.org
CC: linux...@lists.linux-foundation.org
CC: linux-trace-us...@vger.kernel.org
CC: Jean Pihet 
CC: Arjan van de Ven 
CC: Ingo Molnar 
CC: r...@sisk.pl
---
 arch/x86/kernel/process.c|7 +++-
 arch/x86/kernel/process_32.c |2 +-
 arch/x86/kernel/process_64.c |2 +
 drivers/cpufreq/cpufreq.c|1 +
 drivers/cpuidle/cpuidle.c|1 +
 drivers/idle/intel_idle.c|1 +
 include/trace/events/power.h |   87 +-
 kernel/trace/Kconfig |   14 +++
 kernel/trace/power-traces.c  |3 +
 9 files changed, 115 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 57d1868..155d975 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -374,6 +374,7 @@ void default_idle(void)
 {
if (hlt_use_halt()) {
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+   trace_cpu_idle(1, smp_processor_id());
current_thread_info()->status &= ~TS_POLLING;
/*
 * TS_POLLING-cleared state must be visible before we
@@ -444,6 +445,7 @@ EXPORT_SYMBOL_GPL(cpu_idle_wait);
 void mwait_idle_with_hints(unsigned long ax, unsigned long cx)
 {
trace_power_start(POWER_CSTATE, (ax>>4)+1, smp_processor_id());
+   trace_cpu_idle((ax>>4)+1, smp_processor_id());
if (!need_resched()) {
if (cpu_has(¤t_cpu_data, X86_FEATURE_CLFLUSH_MONITOR))
clflush((void *)¤t_thread_info()->flags);
@@ -460,6 +462,7 @@ static void mwait_idle(void)
 {
if (!need_resched()) {
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+   trace_cpu_idle(1, smp_processor_id());
if (cpu_has(¤t_cpu_data, X86_FEATURE_CLFLUSH_MONITOR))
clflush((void *)¤t_thread_info()->flags);
 
@@ -481,10 +484,12 @@ static void mwait_idle(void)
 static void poll_idle(void)
 {
trace_power_start(POWER_CSTATE, 0, smp_processor_id());
+   trace_cpu_idle(0, smp_processor_id());
local_irq_enable();
while (!need_resched())
cpu_relax();
-   trace_power_end(0);
+   trace_power_end(smp_processor_id());
+   trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
 }
 
 /*
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 96586c3..4b9befa 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -113,8 +113,8 @@ void cpu_idle(void)
stop_critical_timings();
pm_idle();
start_critical_timings();
-
trace_power_end(smp_processor_id());
+   trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
}
tick_nohz_restart_sched_tick();
preempt_enable_no_resched();
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 3d9ea53..28153a9 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -142,6 +142,8 @@ void cpu_idle(void)
start_critical_timings();
 
trace_power_end(smp_processor_id());
+   trace_cpu_idle(PWR_EVENT_EXIT,
+  smp_processor_id());
 
/* In many cases the interrupt that ended idle
   has already called exit_idle. But some idle
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 199dcb9..ed4919e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -355,6 +355,7 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs, 
unsigned int state)
dprintk("FREQ: %lu - CPU: %lu", (unsigned long)freqs->new,
(unsigned long)freqs->cpu);
trace_power_frequency(POWER_P

[PATCH 3/4] PERF(userspace): Adjust perf timechart to the new power events V3

[Thomas Renninger]

Changes in V3:
  - PWR_EVENT_EXIT is -1 now instead of 0x
  - Use cpu_{idle,frequency} instead of processor_{idle,frequency}
events

Changes in V2:
  - Hanlde PWR_EVENT_EXIT instead of 0 to recon non-power state

The transition was rather smooth, only part I had to fiddle
some time was the check whether a tracepoint/event is
supported by the running kernel.

builtin-timechart must only pass -e power:xy events which
are supported by the running kernel.
For this I added the tiny helper function:
int is_valid_tracepoint(const char *event_string)
to parse-events.[hc]
which could be more generic as an interface and support
hardware/software/... events, not only tracepoints, but someone
else could extend that if needed...

Signed-off-by: Thomas Renninger 
CC: linux-omap@vger.kernel.org
CC: linux...@lists.linux-foundation.org
CC: linux-trace-us...@vger.kernel.org
CC: Jean Pihet 
CC: Arjan van de Ven 
CC: Ingo Molnar 
CC: r...@sisk.pl
---
 tools/perf/builtin-timechart.c |   89 ---
 tools/perf/util/parse-events.c |   43 +++-
 tools/perf/util/parse-events.h |1 +
 3 files changed, 116 insertions(+), 17 deletions(-)

diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index 9bcc38f..bcc16b0 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -32,6 +32,10 @@
 #include "util/session.h"
 #include "util/svghelper.h"
 
+#define SUPPORT_OLD_POWER_EVENTS 1
+#define PWR_EVENT_EXIT 0x
+
+
 static charconst *input_name = "perf.data";
 static charconst *output_name = "output.svg";
 
@@ -298,12 +302,25 @@ struct trace_entry {
int lock_depth;
 };
 
-struct power_entry {
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+struct power_entry_old {
struct trace_entry te;
u64 type;
u64 value;
u64 cpu_id;
 };
+#endif
+
+struct power_processor_entry {
+   struct trace_entry te;
+   u64 state;
+   u64 cpu_id;
+};
+
+struct power_suspend_entry {
+   struct trace_entry te;
+   u64 state;
+};
 
 #define TASK_COMM_LEN 16
 struct wakeup_entry {
@@ -489,29 +506,46 @@ static int process_sample_event(event_t *event, struct 
perf_session *session)
te = (void *)data.raw_data;
if (session->sample_type & PERF_SAMPLE_RAW && data.raw_size > 0) {
char *event_str;
-   struct power_entry *pe;
-
-   pe = (void *)te;
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+   struct power_entry_old *peo;
+   peo = (void *)te;
+#endif
 
event_str = perf_header__find_event(te->type);
 
if (!event_str)
return 0;
 
-   if (strcmp(event_str, "power:power_start") == 0)
-   c_state_start(pe->cpu_id, data.time, pe->value);
-
-   if (strcmp(event_str, "power:power_end") == 0)
-   c_state_end(pe->cpu_id, data.time);
+   if (strcmp(event_str, "power:cpu_idle") == 0) {
+   struct power_processor_entry *ppe = (void *)te;
+   if (ppe->state == PWR_EVENT_EXIT)
+   c_state_end(ppe->cpu_id, data.time);
+   else
+   c_state_start(ppe->cpu_id, data.time,
+ ppe->state);
+   }
 
-   if (strcmp(event_str, "power:power_frequency") == 0)
-   p_state_change(pe->cpu_id, data.time, pe->value);
+   else if (strcmp(event_str, "power:cpu_frequency") == 0) {
+   struct power_processor_entry *ppe = (void *)te;
+   p_state_change(ppe->cpu_id, data.time, ppe->state);
+   }
 
-   if (strcmp(event_str, "sched:sched_wakeup") == 0)
+   else if (strcmp(event_str, "sched:sched_wakeup") == 0)
sched_wakeup(data.cpu, data.time, data.pid, te);
 
-   if (strcmp(event_str, "sched:sched_switch") == 0)
+   else if (strcmp(event_str, "sched:sched_switch") == 0)
sched_switch(data.cpu, data.time, te);
+
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+   else if (strcmp(event_str, "power:power_start") == 0)
+   c_state_start(peo->cpu_id, data.time, peo->value);
+
+   else if (strcmp(event_str, "power:power_end") == 0)
+   c_state_end(peo->cpu_id, data.time);
+
+   else if (strcmp(event_str, "power:power_frequency") == 0)
+   p_state_change(peo->cpu_id, data.time, peo->value);
+#endif
}
return 0;
 }
@@ -968,7 +1002,8 @@ static const char * const timechart_usage[] = {
NULL
 };
 
-static const char *record_args[] = {
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+static const char *record_old_args[] = {
"re

[PATCH 4/4] PERF: fix power:cpu_idle double end events

[Thomas Renninger]

cpu_idle events (transition into sleep state and exiting) are
both fired in pm_idle().

Entering sleep state and exiting should always get fired inside
pm_idle() already.

This is a revert of commit c882e0feb937af4e5b991cbd1c

Signed-off-by: Thomas Renninger 
CC: Robert Schoene 
CC: Arjan van de Ven 
CC: Ingo Molnar 
---
 arch/x86/kernel/process_32.c |4 
 arch/x86/kernel/process_64.c |6 --
 2 files changed, 0 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 4b9befa..8d12878 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -57,8 +57,6 @@
 #include 
 #include 
 
-#include 
-
 asmlinkage void ret_from_fork(void) __asm__("ret_from_fork");
 
 /*
@@ -113,8 +111,6 @@ void cpu_idle(void)
stop_critical_timings();
pm_idle();
start_critical_timings();
-   trace_power_end(smp_processor_id());
-   trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
}
tick_nohz_restart_sched_tick();
preempt_enable_no_resched();
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 28153a9..d7b3e95 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -51,8 +51,6 @@
 #include 
 #include 
 
-#include 
-
 asmlinkage extern void ret_from_fork(void);
 
 DEFINE_PER_CPU(unsigned long, old_rsp);
@@ -141,10 +139,6 @@ void cpu_idle(void)
pm_idle();
start_critical_timings();
 
-   trace_power_end(smp_processor_id());
-   trace_cpu_idle(PWR_EVENT_EXIT,
-  smp_processor_id());
-
/* In many cases the interrupt that ended idle
   has already called exit_idle. But some idle
   loops can be woken up without interrupt. */
-- 
1.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] PERF: Do not export power_frequency, but power_start event

[Thomas Renninger]

power_frequency moved to drivers/cpufreq/cpufreq.c which has
to be compiled in, no need to export it.

intel_idle can a be module though...

Signed-off-by: Thomas Renninger 
CC: linux-omap@vger.kernel.org
CC: linux...@lists.linux-foundation.org
CC: linux-trace-us...@vger.kernel.org
CC: Jean Pihet 
CC: Arjan van de Ven 
CC: Ingo Molnar 
CC: r...@sisk.pl
---
 drivers/idle/intel_idle.c   |2 --
 kernel/trace/power-traces.c |2 +-
 2 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index c37ef64..21ac077 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -201,9 +201,7 @@ static int intel_idle(struct cpuidle_device *dev, struct 
cpuidle_state *state)
kt_before = ktime_get_real();
 
stop_critical_timings();
-#ifndef MODULE
trace_power_start(POWER_CSTATE, (eax >> 4) + 1, cpu);
-#endif
if (!need_resched()) {
 
__monitor((void *)¤t_thread_info()->flags, 0, 0);
diff --git a/kernel/trace/power-traces.c b/kernel/trace/power-traces.c
index a22582a..0e0497d 100644
--- a/kernel/trace/power-traces.c
+++ b/kernel/trace/power-traces.c
@@ -13,5 +13,5 @@
 #define CREATE_TRACE_POINTS
 #include 
 
-EXPORT_TRACEPOINT_SYMBOL_GPL(power_frequency);
+EXPORT_TRACEPOINT_SYMBOL_GPL(power_start);
 
-- 
1.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH] PERF(kernel): Cleanup power events V2

[Rafael J. Wysocki]

On Wednesday, October 27, 2010, Rafael J. Wysocki wrote:
> On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
> > * Alan Stern (st...@rowland.harvard.edu) wrote:
> > > On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
> > > 
> > > > * Peter Zijlstra (pet...@infradead.org) wrote:
> > > > > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> > > > > > 
> > > > > > +   trace_runtime_pm_usage(dev, 
> > > > > > atomic_read(&dev->power.usage_count)+1);
> > > > > > atomic_inc(&dev->power.usage_count); 
> > > > > 
> > > > > That's terribly racy..
> > > > 
> > > > Looking at the original code, it looks racy even without considering the
> > > > tracepoint:
> > > > 
> > > > int __pm_runtime_get(struct device *dev, bool sync)
> > > >  {
> > > > int retval;
> > > > 
> > > > +   trace_runtime_pm_usage(dev, 
> > > > atomic_read(&dev->power.usage_count)+1);
> > > > atomic_inc(&dev->power.usage_count);
> > > > retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);
> > > > 
> > > > There is no implied memory barrier after "atomic_inc". So either all 
> > > > these
> > > > inc/dec are protected with mutexes or spinlocks, in which case one 
> > > > might wonder
> > > > why atomic operations are used at all, or it's a racy mess. (I vote for 
> > > > the
> > > > second option)
> > > 
> > > I don't understand.  What's the problem?  The inc/dec are atomic 
> > > because they are not protected by spinlocks, but everything else is 
> > > (aside from the tracepoint, which is new).
> > > 
> > > > kref should certainly be used there.
> > > 
> > > What for?
> > 
> > kref has the following "get":
> > 
> > atomic_inc(&kref->refcount);
> > smp_mb__after_atomic_inc();
> > 
> > What seems to be missing in __pm_runtime_get() and 
> > pm_runtime_get_noresume() is
> > the memory barrier after the atomic increment. The atomic increment is free 
> > to
> > be reordered into the following spinlock (within pm_request_resume or 
> > pm_request
> > resume execution) because taking a spinlock only acts as a memory barrier 
> > with
> > acquire semantic, not a full memory barrier.
> >
> > So AFAIU, the failure scenario would be as follows (sorry for the 80+ 
> > columns):
> > 
> > initial conditions: usage_count = 1
> > 
> > CPU A   CPU B
> > 1) __pm_runtime_get() (sync = true)
> > 2)   atomic_inc(&usage_count) (not committed to memory yet)
> > 3)   pm_runtime_resume()
> > 4) spin_lock_irqsave(&dev->power.lock, flags);
> > 5) retval = __pm_request_resume(dev);
> 
> If sync = true this is
>retval = __pm_runtime_resume(dev);
> which drops and reacquires the spinlock.  In the meantime it sets
> ->power.runtime_status so that __pm_runtime_idle() will fail if run at this
> point.
> 
> > 6) (execute the body of __pm_request_resume and return)
> > 7)  
> > __pm_runtime_put() (sync = true) 
> > 8)  if 
> > (atomic_dec_and_test(&dev->power.usage_count))
> >   (still see 
> > usage_count == 1 before decrement,
> >thus 
> > decrement to 0)
> > 9) 
> > pm_runtime_idle()
> > 10)  spin_unlock_irqrestore(&dev->power.lock, flags)
> > 11)
> > spin_lock_irq(&dev->power.lock);
> > 12)retval = 
> > __pm_runtime_idle(dev);
> 
> Moreover, __pm_runtime_idle() checks ->power.usage_count under the spinlock,
> so it will see it's been incremented in the meantime and it will back off.
> 
> > 13)
> > spin_unlock_irq(&dev->power.lock);
> > 
> > So we end up in a situation where CPU A expects the device to be resumed, 
> > but
> > the last action performed has been to bring it to idle.
> >
> > A smp_mb__after_atomic_inc() between lines 2 and 3 would fix this.
> 
> I don't think this particular race is possible.  However, there is another one
> that seems to be possible (in a different function) that an explicit barrier
> will prevent from happening.
> 
> It's related to pm_runtime_get_noresume(), but I think it's better to put the
> barrier where it's necessary rather than into pm_runtime_get_noresume() 
> itself.

Actually, no.  Since rpm_idle() and rpm_suspend() both check usage_count under
the spinlock, the race I was thinking about doesn't appear to be possible after
all.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Rafael J. Wysocki]

On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
> * Rafael J. Wysocki (r...@sisk.pl) wrote:
> > On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
> > > * Peter Zijlstra (pet...@infradead.org) wrote:
> > > > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> > > > > 
> > > > > +   trace_runtime_pm_usage(dev, 
> > > > > atomic_read(&dev->power.usage_count)+1);
> > > > > atomic_inc(&dev->power.usage_count); 
> > > > 
> > > > That's terribly racy..
> > > 
> > > Looking at the original code, it looks racy even without considering the
> > > tracepoint:
> > > 
> > > int __pm_runtime_get(struct device *dev, bool sync)
> > >  {
> > > int retval;
> > > 
> > > +   trace_runtime_pm_usage(dev, 
> > > atomic_read(&dev->power.usage_count)+1);
> > > atomic_inc(&dev->power.usage_count);
> > > retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);
> > > 
> > > There is no implied memory barrier after "atomic_inc". So either all these
> > > inc/dec are protected with mutexes or spinlocks, in which case one might 
> > > wonder
> > > why atomic operations are used at all, or it's a racy mess. (I vote for 
> > > the
> > > second option)
> > 
> > No, it isn't.
> > 
> > > kref should certainly be used there.
> > 
> > No, it shouldn't.
> > 
> > Please try to understand the code you're commenting on first.
> 
> Please see my reply to Alan Stern:
> 
> http://www.spinics.net/lists/linux-omap/msg39382.html

I have and I'm still unimpressed. :-)

Please see my reply to that message.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH] PERF(kernel): Cleanup power events V2

[Rafael J. Wysocki]

On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
> * Alan Stern (st...@rowland.harvard.edu) wrote:
> > On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
> > 
> > > * Peter Zijlstra (pet...@infradead.org) wrote:
> > > > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> > > > > 
> > > > > +   trace_runtime_pm_usage(dev, 
> > > > > atomic_read(&dev->power.usage_count)+1);
> > > > > atomic_inc(&dev->power.usage_count); 
> > > > 
> > > > That's terribly racy..
> > > 
> > > Looking at the original code, it looks racy even without considering the
> > > tracepoint:
> > > 
> > > int __pm_runtime_get(struct device *dev, bool sync)
> > >  {
> > > int retval;
> > > 
> > > +   trace_runtime_pm_usage(dev, 
> > > atomic_read(&dev->power.usage_count)+1);
> > > atomic_inc(&dev->power.usage_count);
> > > retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);
> > > 
> > > There is no implied memory barrier after "atomic_inc". So either all these
> > > inc/dec are protected with mutexes or spinlocks, in which case one might 
> > > wonder
> > > why atomic operations are used at all, or it's a racy mess. (I vote for 
> > > the
> > > second option)
> > 
> > I don't understand.  What's the problem?  The inc/dec are atomic 
> > because they are not protected by spinlocks, but everything else is 
> > (aside from the tracepoint, which is new).
> > 
> > > kref should certainly be used there.
> > 
> > What for?
> 
> kref has the following "get":
> 
> atomic_inc(&kref->refcount);
> smp_mb__after_atomic_inc();
> 
> What seems to be missing in __pm_runtime_get() and pm_runtime_get_noresume() 
> is
> the memory barrier after the atomic increment. The atomic increment is free to
> be reordered into the following spinlock (within pm_request_resume or 
> pm_request
> resume execution) because taking a spinlock only acts as a memory barrier with
> acquire semantic, not a full memory barrier.
>
> So AFAIU, the failure scenario would be as follows (sorry for the 80+ 
> columns):
> 
> initial conditions: usage_count = 1
> 
> CPU A   CPU B
> 1) __pm_runtime_get() (sync = true)
> 2)   atomic_inc(&usage_count) (not committed to memory yet)
> 3)   pm_runtime_resume()
> 4) spin_lock_irqsave(&dev->power.lock, flags);
> 5) retval = __pm_request_resume(dev);

If sync = true this is
   retval = __pm_runtime_resume(dev);
which drops and reacquires the spinlock.  In the meantime it sets
->power.runtime_status so that __pm_runtime_idle() will fail if run at this
point.

> 6) (execute the body of __pm_request_resume and return)
> 7)  
> __pm_runtime_put() (sync = true) 
> 8)  if 
> (atomic_dec_and_test(&dev->power.usage_count))
>   (still see 
> usage_count == 1 before decrement,
>thus decrement 
> to 0)
> 9) 
> pm_runtime_idle()
> 10)  spin_unlock_irqrestore(&dev->power.lock, flags)
> 11)
> spin_lock_irq(&dev->power.lock);
> 12)retval = 
> __pm_runtime_idle(dev);

Moreover, __pm_runtime_idle() checks ->power.usage_count under the spinlock,
so it will see it's been incremented in the meantime and it will back off.

> 13)
> spin_unlock_irq(&dev->power.lock);
> 
> So we end up in a situation where CPU A expects the device to be resumed, but
> the last action performed has been to bring it to idle.
>
> A smp_mb__after_atomic_inc() between lines 2 and 3 would fix this.

I don't think this particular race is possible.  However, there is another one
that seems to be possible (in a different function) that an explicit barrier
will prevent from happening.

It's related to pm_runtime_get_noresume(), but I think it's better to put the
barrier where it's necessary rather than into pm_runtime_get_noresume() itself.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/5] omap: mailbox: initial hwmod support for omap2

[Omar Ramirez Luna]

HWMOD support for omap2430 and 2420.

Compiled tested only.

Signed-off-by: Omar Ramirez Luna 
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |   55 
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   54 +++
 2 files changed, 109 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a1a3dd6..e417fb4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -81,6 +81,7 @@ static struct omap_hwmod omap2420_uart2_hwmod;
 static struct omap_hwmod omap2420_uart3_hwmod;
 static struct omap_hwmod omap2420_i2c1_hwmod;
 static struct omap_hwmod omap2420_i2c2_hwmod;
+static struct omap_hwmod omap2420_mailbox_hwmod;
 
 /* L4_CORE -> L4_WKUP interface */
 static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
@@ -557,6 +558,59 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
.flags  = HWMOD_16BIT_REG,
 };
 
+/* Mailbox */
+
+static struct omap_hwmod_class omap2420_mailbox_hwmod_class = {
+   .name = "mailbox",
+};
+
+static struct omap_hwmod_irq_info omap2420_mailbox_irqs[] = {
+   { .name = "dsp", .irq = INT_24XX_MAIL_U0_MPU },
+   { .name = "iva", .irq = INT_24XX_MAIL_U3_MPU },
+};
+
+static struct omap_hwmod_addr_space omap2420_mailbox_addrs[] = {
+   {
+   .pa_start   = OMAP24XX_MAILBOX_BASE,
+   .pa_end = OMAP24XX_MAILBOX_BASE + SZ_4K - 1,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* L4_CORE -> Mailbox */
+static struct omap_hwmod_ocp_if omap2420_l4_core__mailbox = {
+   .master = &omap2420_l4_core_hwmod,
+   .slave  = &omap2420_mailbox_hwmod,
+   .addr   = omap2420_mailbox_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2420_mailbox_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* Mailbox slave ports */
+static struct omap_hwmod_ocp_if *omap2420_mailbox_slaves[] = {
+   &omap2420_l4_core__mailbox,
+};
+
+static struct omap_hwmod omap2420_mailbox_hwmod = {
+   .name   = "mailbox",
+   .class  = &omap2420_mailbox_hwmod_class,
+   .prcm   = {
+   .omap2 = {
+   .prcm_reg_id = 1,
+   .module_bit = OMAP24XX_EN_MAILBOXES_SHIFT,
+   .module_offs = CORE_MOD,
+   .idlest_reg_id = 1,
+   .idlest_idle_bit = OMAP24XX_ST_MAILBOXES_SHIFT,
+   },
+   },
+   .main_clk   = "mailboxes_ick",
+   .mpu_irqs   = omap2420_mailbox_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2420_mailbox_irqs),
+   .slaves = omap2420_mailbox_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap2420_mailbox_slaves),
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+};
+
 static __initdata struct omap_hwmod *omap2420_hwmods[] = {
&omap2420_l3_main_hwmod,
&omap2420_l4_core_hwmod,
@@ -569,6 +623,7 @@ static __initdata struct omap_hwmod *omap2420_hwmods[] = {
&omap2420_uart3_hwmod,
&omap2420_i2c1_hwmod,
&omap2420_i2c2_hwmod,
+   &omap2420_mailbox_hwmod,
NULL,
 };
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 7cf0d3a..1a7d2d9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -81,6 +81,7 @@ static struct omap_hwmod omap2430_uart2_hwmod;
 static struct omap_hwmod omap2430_uart3_hwmod;
 static struct omap_hwmod omap2430_i2c1_hwmod;
 static struct omap_hwmod omap2430_i2c2_hwmod;
+static struct omap_hwmod omap2430_mailbox_hwmod;
 
 /* I2C IP block address space length (in bytes) */
 #define OMAP2_I2C_AS_LEN   128
@@ -569,6 +570,58 @@ static struct omap_hwmod omap2430_i2c2_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
 };
 
+/* Mailbox */
+
+static struct omap_hwmod_class omap2430_mailbox_hwmod_class = {
+   .name = "mailbox",
+};
+
+static struct omap_hwmod_irq_info omap2430_mailbox_irqs[] = {
+   { .name = "dsp", .irq = INT_24XX_MAIL_U0_MPU },
+};
+
+static struct omap_hwmod_addr_space omap2430_mailbox_addrs[] = {
+   {
+   .pa_start   = OMAP24XX_MAILBOX_BASE,
+   .pa_end = OMAP24XX_MAILBOX_BASE + SZ_4K - 1,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* L4_CORE -> Mailbox */
+static struct omap_hwmod_ocp_if omap2430_l4_core__mailbox = {
+   .master = &omap2430_l4_core_hwmod,
+   .slave  = &omap2430_mailbox_hwmod,
+   .addr   = omap2430_mailbox_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2430_mailbox_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* Mailbox slave ports */
+static struct omap_hwmod_ocp_if *omap2430_mailbox_slaves[] = {
+   &omap2430_l4_core__mailbox,
+};
+
+static 

[PATCH 5/5] omap: mailbox: remove unreachable return

[Omar Ramirez Luna]

Remove unreachable return statement.

Signed-off-by: Omar Ramirez Luna 
---
 arch/arm/mach-omap2/mailbox.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index b8fd120..2dd0e07 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -435,8 +435,6 @@ static int __devinit omap2_mbox_probe(struct 
platform_device *pdev)
return ret;
}
return 0;
-
-   return ret;
 }
 
 static int __devexit omap2_mbox_remove(struct platform_device *pdev)
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/5] omap: mailbox: add omap_device latency information

[Omar Ramirez Luna]

From: Felipe Contreras 

So that we can enable the main clock.

Signed-off-by: Felipe Contreras 
Signed-off-by: Omar Ramirez Luna 
---
 arch/arm/mach-omap2/devices.c |   19 +--
 arch/arm/mach-omap2/mailbox.c |   21 +
 arch/arm/plat-omap/include/plat/mailbox.h |6 ++
 3 files changed, 32 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index d977572..337fd7a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mux.h"
 #include "control.h"
@@ -141,10 +142,20 @@ static inline void omap_init_camera(void)
 #endif
 
 #if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
+static struct omap_device_pm_latency mbox_latencies[] = {
+   [0] = {
+   .activate_func = omap_device_enable_clocks,
+   .activate_lat = 5, /* FIXME random value */
+   .deactivate_func = omap_device_enable_clocks,
+   .deactivate_lat = 5, /* FIXME random value */
+   },
+};
+
 static inline void omap_init_mbox(void)
 {
struct omap_hwmod *oh;
struct omap_device *od;
+   struct omap_mbox_platform_data pdata;
 
oh = omap_hwmod_lookup("mailbox");
if (!oh) {
@@ -152,10 +163,14 @@ static inline void omap_init_mbox(void)
return;
}
 
+   pdata.device_enable = omap_device_enable;
+   pdata.device_disable = omap_device_idle;
+
od = omap_device_build("omap-mailbox", -1, oh,
-   NULL, 0,
-   NULL, 0,
+   &pdata, sizeof(pdata),
+   mbox_latencies, ARRAY_SIZE(mbox_latencies),
0);
+
if (!od) {
pr_err("%s: could not build device\n", __func__);
return;
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 1ddb82d..61f2149 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -53,6 +53,7 @@
 #define OMAP4_MBOX_NR_REGS (OMAP4_MBOX_REG_SIZE / sizeof(u32))
 
 static void __iomem *mbox_base;
+static struct platform_device *mbox_pdev;
 
 struct omap_mbox2_fifo {
unsigned long msg;
@@ -71,8 +72,6 @@ struct omap_mbox2_priv {
unsigned long irqdisable;
 };
 
-static struct clk *mbox_ick_handle;
-
 static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
  omap_mbox_type_t irq);
 
@@ -91,14 +90,10 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
 {
u32 l;
unsigned long timeout;
+   struct omap_mbox_platform_data *pdata = mbox_pdev->dev.platform_data;
 
-   mbox_ick_handle = clk_get(NULL, "mailboxes_ick");
-   if (IS_ERR(mbox_ick_handle)) {
-   printk(KERN_ERR "Could not get mailboxes_ick: %ld\n",
-   PTR_ERR(mbox_ick_handle));
-   return PTR_ERR(mbox_ick_handle);
-   }
-   clk_enable(mbox_ick_handle);
+   if (pdata->device_enable)
+   pdata->device_enable(mbox_pdev);
 
if (cpu_is_omap44xx()) {
mbox_write_reg(OMAP4_SOFTRESET, MAILBOX_SYSCONFIG);
@@ -144,9 +139,9 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
 
 static void omap2_mbox_shutdown(struct omap_mbox *mbox)
 {
-   clk_disable(mbox_ick_handle);
-   clk_put(mbox_ick_handle);
-   mbox_ick_handle = NULL;
+   struct omap_mbox_platform_data *pdata = mbox_pdev->dev.platform_data;
+   if (pdata->device_disable)
+   pdata->device_disable(mbox_pdev);
 }
 
 /* Mailbox FIFO handle functions */
@@ -428,6 +423,8 @@ static int __devinit omap2_mbox_probe(struct 
platform_device *pdev)
if (!mbox_base)
return -ENOMEM;
 
+   mbox_pdev = pdev;
+
ret = omap_mbox_register(&pdev->dev, list);
if (ret) {
iounmap(mbox_base);
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h 
b/arch/arm/plat-omap/include/plat/mailbox.h
index 9976565..59443b1 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -11,6 +11,7 @@
 
 typedef u32 mbox_msg_t;
 struct omap_mbox;
+struct platform_device;
 
 typedef int __bitwise omap_mbox_irq_t;
 #define IRQ_TX ((__force omap_mbox_irq_t) 1)
@@ -59,6 +60,11 @@ struct omap_mbox {
void*priv;
 };
 
+struct omap_mbox_platform_data {
+   int (*device_enable)(struct platform_device *pdev);
+   int (*device_disable)(struct platform_device *pdev);
+};
+
 int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
 void omap_mbox_init_seq(struct omap_mbox *);
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/5] omap: mailbox: hwmod support and dependent cleanup patches

[Omar Ramirez Luna]

HWMOD support for omap2 and omap3 chips, plus cleanups.

1. omap: mailbox: initial hwmod support for omap3
Changes were made to:
- Rebase to latest code.
- Detect the hwmod by filling prcm union for omap2, without
  this it was unable to build the hwmod at runtime.
- Replace magic number for defines.
- Use ioremap again instead of relying on the one made by hwmod,
  as noted in http://patchwork.kernel.org/patch/101661/

Tested on 3430 and 3630

2. omap: mailbox: initial hwmod support for omap2
Was only compiled tested!! Unfortunately I don't have the HW for it.

4. omap: mailbox: fix detection for previously supported chips
Original patch was using features framework, but when compiled as a module
it was breaking, this patch uses cpu_is_omap34xx macro instead.

This is meant as a short term solution until proper cleanup is done, as 
suggested in:

http://marc.info/?l=linux-arm-kernel&m=128534253231481&w=2

Felipe Contreras (2):
  omap: mailbox: initial hwmod support for omap3
  omap: mailbox: add omap_device latency information

Omar Ramirez Luna (4):
  omap: mailbox: initial hwmod support for omap2
  omap: mailbox: fix detection for previously supported chips
  omap: mailbox: remove unreachable return

 arch/arm/mach-omap2/devices.c  |  104 +++-
 arch/arm/mach-omap2/mailbox.c  |   40 +-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |   55 +++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   54 ++
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   54 ++
 arch/arm/plat-omap/include/plat/mailbox.h  |6 ++
 6 files changed, 213 insertions(+), 100 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/5] omap: mailbox: initial hwmod support for omap3

[Omar Ramirez Luna]

From: Felipe Contreras 

HWMOD support for omap3.

Signed-off-by: Felipe Contreras 
Signed-off-by: Omar Ramirez Luna 
---
 arch/arm/mach-omap2/devices.c  |  100 ---
 arch/arm/mach-omap2/mailbox.c  |1 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   54 +++
 3 files changed, 70 insertions(+), 85 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index eaf3799..d977572 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -141,95 +141,25 @@ static inline void omap_init_camera(void)
 #endif
 
 #if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
-
-#define MBOX_REG_SIZE   0x120
-
-#ifdef CONFIG_ARCH_OMAP2
-static struct resource omap2_mbox_resources[] = {
-   {
-   .start  = OMAP24XX_MAILBOX_BASE,
-   .end= OMAP24XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
-   .flags  = IORESOURCE_MEM,
-   },
-   {
-   .start  = INT_24XX_MAIL_U0_MPU,
-   .flags  = IORESOURCE_IRQ,
-   .name   = "dsp",
-   },
-   {
-   .start  = INT_24XX_MAIL_U3_MPU,
-   .flags  = IORESOURCE_IRQ,
-   .name   = "iva",
-   },
-};
-static int omap2_mbox_resources_sz = ARRAY_SIZE(omap2_mbox_resources);
-#else
-#define omap2_mbox_resources   NULL
-#define omap2_mbox_resources_sz0
-#endif
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct resource omap3_mbox_resources[] = {
-   {
-   .start  = OMAP34XX_MAILBOX_BASE,
-   .end= OMAP34XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
-   .flags  = IORESOURCE_MEM,
-   },
-   {
-   .start  = INT_24XX_MAIL_U0_MPU,
-   .flags  = IORESOURCE_IRQ,
-   .name   = "dsp",
-   },
-};
-static int omap3_mbox_resources_sz = ARRAY_SIZE(omap3_mbox_resources);
-#else
-#define omap3_mbox_resources   NULL
-#define omap3_mbox_resources_sz0
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-
-#define OMAP4_MBOX_REG_SIZE0x130
-static struct resource omap4_mbox_resources[] = {
-   {
-   .start  = OMAP44XX_MAILBOX_BASE,
-   .end= OMAP44XX_MAILBOX_BASE +
-   OMAP4_MBOX_REG_SIZE - 1,
-   .flags  = IORESOURCE_MEM,
-   },
-   {
-   .start  = OMAP44XX_IRQ_MAIL_U0,
-   .flags  = IORESOURCE_IRQ,
-   .name   = "mbox",
-   },
-};
-static int omap4_mbox_resources_sz = ARRAY_SIZE(omap4_mbox_resources);
-#else
-#define omap4_mbox_resources   NULL
-#define omap4_mbox_resources_sz0
-#endif
-
-static struct platform_device mbox_device = {
-   .name   = "omap-mailbox",
-   .id = -1,
-};
-
 static inline void omap_init_mbox(void)
 {
-   if (cpu_is_omap24xx()) {
-   mbox_device.resource = omap2_mbox_resources;
-   mbox_device.num_resources = omap2_mbox_resources_sz;
-   } else if (cpu_is_omap34xx()) {
-   mbox_device.resource = omap3_mbox_resources;
-   mbox_device.num_resources = omap3_mbox_resources_sz;
-   } else if (cpu_is_omap44xx()) {
-   mbox_device.resource = omap4_mbox_resources;
-   mbox_device.num_resources = omap4_mbox_resources_sz;
-   } else {
-   pr_err("%s: platform not supported\n", __func__);
+   struct omap_hwmod *oh;
+   struct omap_device *od;
+
+   oh = omap_hwmod_lookup("mailbox");
+   if (!oh) {
+   pr_err("%s: unable to find hwmod\n", __func__);
+   return;
+   }
+
+   od = omap_device_build("omap-mailbox", -1, oh,
+   NULL, 0,
+   NULL, 0,
+   0);
+   if (!od) {
+   pr_err("%s: could not build device\n", __func__);
return;
}
-   platform_device_register(&mbox_device);
 }
 #else
 static inline void omap_init_mbox(void) { }
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 40ddeca..1ddb82d 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define MAILBOX_REVISION   0x000
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ed6bf4a..9e9e843 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -45,6 +45,7 @@ static struct omap_hwmod omap3xxx_wd_timer2_hwmod;
 static struct omap_hwmod omap3xxx_i2c1_hwmod;
 static struct omap_hwmod omap3xxx_i2c2_hwmod;
 static struct omap_hwmod omap3xxx_i2c3_hwmod;
+sta

[PATCH 4/5] omap: mailbox: fix detection for previously supported chips

[Omar Ramirez Luna]

Fix the mailbox detection for OMAP3630 and 2430, also minor
cleanup on conditional ifdef's that could affect it.

Given that 2430 has an iva too include it, as the same steps
for omap3 apply.

Signed-off-by: Omar Ramirez Luna 
---
 arch/arm/mach-omap2/mailbox.c |   16 ++--
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 61f2149..b8fd120 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -277,7 +277,7 @@ static struct omap_mbox_ops omap2_mbox_ops = {
 
 /* FIXME: the following structs should be filled automatically by the user id 
*/
 
-#if defined(CONFIG_ARCH_OMAP3430) || defined(CONFIG_ARCH_OMAP2420)
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP2)
 /* DSP */
 static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.tx_fifo = {
@@ -302,7 +302,7 @@ struct omap_mbox mbox_dsp_info = {
 };
 #endif
 
-#if defined(CONFIG_ARCH_OMAP3430)
+#if defined(CONFIG_ARCH_OMAP3)
 struct omap_mbox *omap3_mboxes[] = { &mbox_dsp_info, NULL };
 #endif
 
@@ -390,15 +390,19 @@ static int __devinit omap2_mbox_probe(struct 
platform_device *pdev)
 
if (false)
;
-#if defined(CONFIG_ARCH_OMAP3430)
-   else if (cpu_is_omap3430()) {
+#if defined(CONFIG_ARCH_OMAP3)
+   else if (cpu_is_omap34xx()) {
list = omap3_mboxes;
 
list[0]->irq = platform_get_irq_byname(pdev, "dsp");
}
 #endif
-#if defined(CONFIG_ARCH_OMAP2420)
-   else if (cpu_is_omap2420()) {
+#if defined(CONFIG_ARCH_OMAP2)
+   else if (cpu_is_omap2430()) {
+   list = omap2_mboxes;
+
+   list[0]->irq = platform_get_irq_byname(pdev, "dsp");
+   } else if (cpu_is_omap2420()) {
list = omap2_mboxes;
 
list[0]->irq = platform_get_irq_byname(pdev, "dsp");
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Mathieu Desnoyers]

* Rafael J. Wysocki (r...@sisk.pl) wrote:
> On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
> > * Peter Zijlstra (pet...@infradead.org) wrote:
> > > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> > > > 
> > > > +   trace_runtime_pm_usage(dev, 
> > > > atomic_read(&dev->power.usage_count)+1);
> > > > atomic_inc(&dev->power.usage_count); 
> > > 
> > > That's terribly racy..
> > 
> > Looking at the original code, it looks racy even without considering the
> > tracepoint:
> > 
> > int __pm_runtime_get(struct device *dev, bool sync)
> >  {
> > int retval;
> > 
> > +   trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)+1);
> > atomic_inc(&dev->power.usage_count);
> > retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);
> > 
> > There is no implied memory barrier after "atomic_inc". So either all these
> > inc/dec are protected with mutexes or spinlocks, in which case one might 
> > wonder
> > why atomic operations are used at all, or it's a racy mess. (I vote for the
> > second option)
> 
> No, it isn't.
> 
> > kref should certainly be used there.
> 
> No, it shouldn't.
> 
> Please try to understand the code you're commenting on first.

Please see my reply to Alan Stern:

http://www.spinics.net/lists/linux-omap/msg39382.html

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH] PERF(kernel): Cleanup power events V2

[Mathieu Desnoyers]

* Alan Stern (st...@rowland.harvard.edu) wrote:
> On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
> 
> > * Peter Zijlstra (pet...@infradead.org) wrote:
> > > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> > > > 
> > > > +   trace_runtime_pm_usage(dev, 
> > > > atomic_read(&dev->power.usage_count)+1);
> > > > atomic_inc(&dev->power.usage_count); 
> > > 
> > > That's terribly racy..
> > 
> > Looking at the original code, it looks racy even without considering the
> > tracepoint:
> > 
> > int __pm_runtime_get(struct device *dev, bool sync)
> >  {
> > int retval;
> > 
> > +   trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)+1);
> > atomic_inc(&dev->power.usage_count);
> > retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);
> > 
> > There is no implied memory barrier after "atomic_inc". So either all these
> > inc/dec are protected with mutexes or spinlocks, in which case one might 
> > wonder
> > why atomic operations are used at all, or it's a racy mess. (I vote for the
> > second option)
> 
> I don't understand.  What's the problem?  The inc/dec are atomic 
> because they are not protected by spinlocks, but everything else is 
> (aside from the tracepoint, which is new).
> 
> > kref should certainly be used there.
> 
> What for?

kref has the following "get":

atomic_inc(&kref->refcount);
smp_mb__after_atomic_inc();

What seems to be missing in __pm_runtime_get() and pm_runtime_get_noresume() is
the memory barrier after the atomic increment. The atomic increment is free to
be reordered into the following spinlock (within pm_request_resume or pm_request
resume execution) because taking a spinlock only acts as a memory barrier with
acquire semantic, not a full memory barrier.

So AFAIU, the failure scenario would be as follows (sorry for the 80+ columns):

initial conditions: usage_count = 1

CPU A   CPU B
1) __pm_runtime_get() (sync = true)
2)   atomic_inc(&usage_count) (not committed to memory yet)
3)   pm_runtime_resume()
4) spin_lock_irqsave(&dev->power.lock, flags);
5) retval = __pm_request_resume(dev);
6) (execute the body of __pm_request_resume and return)
7)  __pm_runtime_put() 
(sync = true) 
8)  if 
(atomic_dec_and_test(&dev->power.usage_count))
  (still see 
usage_count == 1 before decrement,
   thus decrement 
to 0)
9) pm_runtime_idle()
10)  spin_unlock_irqrestore(&dev->power.lock, flags)
11)
spin_lock_irq(&dev->power.lock);
12)retval = 
__pm_runtime_idle(dev);
13)
spin_unlock_irq(&dev->power.lock);

So we end up in a situation where CPU A expects the device to be resumed, but
the last action performed has been to bring it to idle.

A smp_mb__after_atomic_inc() between lines 2 and 3 would fix this.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Rafael J. Wysocki]

On Tuesday, October 26, 2010, Arjan van de Ven wrote:
> On 10/26/2010 1:38 PM, Rafael J. Wysocki wrote:
> > On Tuesday, October 26, 2010, Pierre Tardy wrote:
> >> On Tue, Oct 26, 2010 at 2:08 PM, Rafael J. Wysocki  wrote:
> >>> On Tuesday, October 26, 2010, Pierre Tardy wrote:
>  On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra  
>  wrote:
> > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> >> +   trace_runtime_pm_usage(dev, 
> >> atomic_read(&dev->power.usage_count)+1);
> >>  atomic_inc(&dev->power.usage_count);
> > That's terribly racy..
> >
>  I know. I'm not proud of this.. As I said, this is preliminary patch.
>  We dont really need to have this prev_usage. This is just for debug.
>  It mayprobably endup with something like:
> 
>    atomic_inc(&dev->power.usage_count);
>  +   trace_power_device_usage(dev);
> >>> Well, please tell me what you're trying to achieve.
> >> Please see attached the kind of pytimechart output I'm trying to
> >> achieve (yes, this chart is not coherent, seems I'm still missing some
> >> traces)
> >>
> >> We basically want to have a trace point eachtime the usage_counter
> >> changes, so that I can display nice timecharts, and Arjan can have the
> >> comm of the process that eventually generated the rpm_get, in order to
> >> pinpoint it in powertop.
> >>
> >> What you dont see in the above two lines is that
> >> trace_power_device_usage(dev); actually reads the usage_count, as well
> >> as the driver and device name.
> > I'm afraid that for this to really work you'd need to put usage_count under 
> > a
> > spinlock along with your trace point, which I'm not really sure I like.
> >
> > Besides, I'm not really sure the manipulations of usage_count are worth
> > tracing.
> 
> what's most interesting is the 0->1  and 1->0 transitions.

But they are only meaningful in specific situations.  For example, if someone
does pm_runtime_get_noresume() when the device is active, there may be
a device suspend already under way at the same time.  So IMO what really
is interesting is when rpm_resume() is called with usage_count > 0 and then
perhaps when rpm_idle() or rpm_suspend() is called after usage_count drops
back to 0.

There are some other interesting cases, but they all need to be checked under
->power.lock and you need to do that cleverly, so that the _functionality_ is
not harmed.

Overall, I think that adding tracepoints to the runtime PM core code is really
premature at this point, given that we've just reworked it quite a bit recently.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Arjan van de Ven]

On 10/26/2010 1:38 PM, Rafael J. Wysocki wrote:

On Tuesday, October 26, 2010, Pierre Tardy wrote:

On Tue, Oct 26, 2010 at 2:08 PM, Rafael J. Wysocki  wrote:

On Tuesday, October 26, 2010, Pierre Tardy wrote:

On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra  wrote:

On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:

+   trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)+1);
 atomic_inc(&dev->power.usage_count);

That's terribly racy..


I know. I'm not proud of this.. As I said, this is preliminary patch.
We dont really need to have this prev_usage. This is just for debug.
It mayprobably endup with something like:

  atomic_inc(&dev->power.usage_count);
+   trace_power_device_usage(dev);

Well, please tell me what you're trying to achieve.

Please see attached the kind of pytimechart output I'm trying to
achieve (yes, this chart is not coherent, seems I'm still missing some
traces)

We basically want to have a trace point eachtime the usage_counter
changes, so that I can display nice timecharts, and Arjan can have the
comm of the process that eventually generated the rpm_get, in order to
pinpoint it in powertop.

What you dont see in the above two lines is that
trace_power_device_usage(dev); actually reads the usage_count, as well
as the driver and device name.

I'm afraid that for this to really work you'd need to put usage_count under a
spinlock along with your trace point, which I'm not really sure I like.

Besides, I'm not really sure the manipulations of usage_count are worth
tracing.


what's most interesting is the 0->1  and 1->0 transitions.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Rafael J. Wysocki]

On Tuesday, October 26, 2010, Pierre Tardy wrote:
> On Tue, Oct 26, 2010 at 2:08 PM, Rafael J. Wysocki  wrote:
> > On Tuesday, October 26, 2010, Pierre Tardy wrote:
> >> On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra  
> >> wrote:
> >> > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> >> >>
> >> >> +   trace_runtime_pm_usage(dev, 
> >> >> atomic_read(&dev->power.usage_count)+1);
> >> >> atomic_inc(&dev->power.usage_count);
> >> >
> >> > That's terribly racy..
> >> >
> >> I know. I'm not proud of this.. As I said, this is preliminary patch.
> >> We dont really need to have this prev_usage. This is just for debug.
> >> It mayprobably endup with something like:
> >>
> >>  atomic_inc(&dev->power.usage_count);
> >> +   trace_power_device_usage(dev);
> >
> > Well, please tell me what you're trying to achieve.
> 
> Please see attached the kind of pytimechart output I'm trying to
> achieve (yes, this chart is not coherent, seems I'm still missing some
> traces)
> 
> We basically want to have a trace point eachtime the usage_counter
> changes, so that I can display nice timecharts, and Arjan can have the
> comm of the process that eventually generated the rpm_get, in order to
> pinpoint it in powertop.
> 
> What you dont see in the above two lines is that
> trace_power_device_usage(dev); actually reads the usage_count, as well
> as the driver and device name.

I'm afraid that for this to really work you'd need to put usage_count under a
spinlock along with your trace point, which I'm not really sure I like.

Besides, I'm not really sure the manipulations of usage_count are worth
tracing.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map

[Guzman Lugo, Fernando]

 

> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@nokia.com] 
> Sent: Tuesday, October 26, 2010 2:38 PM
> To: Guzman Lugo, Fernando; felipe.contre...@gmail.com
> Cc: gre...@suse.de; hiroshi.d...@nokia.com; 
> linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; 
> linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: RE: [PATCH 1/8] staging: tidspbridge - remove 
> req_addr from proc_map
> 
> fernando.l...@ti.com wrote:
> > > fernando.l...@ti.com wrote:
> > > > > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo 
> > > > >  wrote:
> > > > > > The device address is assigned by tidspbridge no need for
> > > > > that parameter anymore.
> > > > > >
> > > > > > Signed-off-by: Fernando Guzman Lugo 
> > > > > 
> > > > > This would break the API with user-space, right?
> > > > 
> > > > Yes, user-space needs to be changed accordingly.
> > > 
> > > Wouldn't it make sense to avoid stuffing so many changes at once 
> > > including ABI breakage?
> > > 
> > > Does user-space really _needs_ to be changed? Can't you 
> just ignore 
> > > that argument?
> > 
> > Actually, I had a previous version of that patch where I 
> only Ignored 
> > that paramteter. But after thinking again and seeing How 
> the long time 
> > ago depreacted function are still there I Removed the parameter in 
> > order to force apps to make the change.
> 
> Again, can we concentrate on first getting this thing to work?

If to make it work for 37 the iommu migration patch will be revert
These set of patches will have to wait until the patches are merged
Again. So the dspbridge would be "fix" first a then the patches would
Be merged.

> 
> We can think on breaking things again later.
> 
> > You can ignore that argument at API level, so all users of 
> the API not 
> > need to have change (in that momment). That should be Only few line 
> > change.
> 
> Yes, that's what I'm proposing.

I meant userspace api or library level:
Example:

Dsp_proc_map(proc, mpu_addr, req_addr, *dsp_addr, attr) {
...
struct proc_map args = {
.map_addr = mpu_addr;
/* ignore req_addr */
.dsp_addr = dsp_addr;
.attr = attr;
}

ret = ioctl(handle, PROCMAP_CMD, args)
...
}


> 
> > > > > I think this change should be delayed, preferably 
> after we have 
> > > > > a working tidspbridge.
> > > > 
> > > > The issue you were seeing must be fixed with patch 2/8, and
> > > Having all
> > > > the dependencies tidspbridge has to be working Properly.
> > > 
> > > Yes, which might not happen at .37. If we revert the 
> iommu stuff, we 
> > > might have a chance at having a working bridge on .37.
> > 
> > But havi that merged in tidspbridge make more pressure to 
> merged The 
> > dependencies, if not maybe that wont have event for .38.
> 
> Those patches have been there for a while and there's no sign 
> of when they'll be merged. Also, remember that the fact that 
> the patches have been sent doesn't guarantee they would be on 
> this, or even the next cycle.
> 
> Besides, the rule followed here is: it's ready when it's 
> ready. In the meantime the driver should work, and we can do 
> that rather easily.

I don't have much experience in this kind of situacion if it is
believed it is the best solution then ok for me.

> 
> > But That is just my opinion if you all are agree revert is the best 
> > Option I am ok, but I looks like more work reverting and rebaseing 
> > specially because it is a big change.
> 
> git makes this easy.

Till we need to fix all the conflics, make sure everything work
Properly and then send it again to review. That can take a while,
But it seems someone else is agree to revert the changes, so maybe
That is the best to do in this situacion.

Thanks and regards,
Fernando.

> 
> The hard part is for the people out there that are trying to 
> use this driver and have to hunt mailing lists and multiple 
> repos just to get this to work. Moving to staging was 
> supposed to make this easier, not harder.
> 
> --
> Felipe Contreras
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Pierre Tardy]

On Tue, Oct 26, 2010 at 2:08 PM, Rafael J. Wysocki  wrote:
> On Tuesday, October 26, 2010, Pierre Tardy wrote:
>> On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra  
>> wrote:
>> > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
>> >>
>> >> +       trace_runtime_pm_usage(dev, 
>> >> atomic_read(&dev->power.usage_count)+1);
>> >>         atomic_inc(&dev->power.usage_count);
>> >
>> > That's terribly racy..
>> >
>> I know. I'm not proud of this.. As I said, this is preliminary patch.
>> We dont really need to have this prev_usage. This is just for debug.
>> It mayprobably endup with something like:
>>
>>          atomic_inc(&dev->power.usage_count);
>> +       trace_power_device_usage(dev);
>
> Well, please tell me what you're trying to achieve.

Please see attached the kind of pytimechart output I'm trying to
achieve (yes, this chart is not coherent, seems I'm still missing some
traces)

We basically want to have a trace point eachtime the usage_counter
changes, so that I can display nice timecharts, and Arjan can have the
comm of the process that eventually generated the rpm_get, in order to
pinpoint it in powertop.

What you dont see in the above two lines is that
trace_power_device_usage(dev); actually reads the usage_count, as well
as the driver and device name.

Regards,
-- 
Pierre
<>

RE: [PATCH 8/8] staging: tidspbridge - make sync_wait_on_event interruptible

[Guzman Lugo, Fernando]

 

> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@nokia.com] 
> Sent: Tuesday, October 26, 2010 2:27 PM
> To: Guzman Lugo, Fernando; felipe.contre...@gmail.com
> Cc: gre...@suse.de; hiroshi.d...@nokia.com; 
> linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; 
> linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: RE: [PATCH 8/8] staging: tidspbridge - make 
> sync_wait_on_event interruptible
> 
> fernando.l...@ti.com wrote:
> > > fernando.l...@ti.com wrote:
> > > > > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo 
> > > > >  wrote:
> > > > > > So that avoid non-killable process.
> > > > > 
> > > > > It would be useful to interrupt these tasks from user-space. 
> > > > > A separate ioctl to do that would be needed.
> > > > 
> > > > I don't see use case where that could be needed. It is only
> > > To avoid a
> > > > nonkillable task in the case the user pass an infinite Timeout.
> > > > 
> > > > If you have some test case where that ioctl would be 
> needed Please 
> > > > share it in order to find the best solution.
> > > 
> > > Well, imagine the application is using a library to 
> access the DSP, 
> > > and the library has a dedicated thread listening for DSP 
> events in a 
> > > loop.
> > > This happens to be how libomxil-ti and gst-dsp work.
> > > 
> > > Now, the thread received the last message, but has set a 
> timeout of 
> > > 10s, or even worst, no timeout at all.
> > > 
> > > After realizing that was the last message, the main 
> thread decides 
> > > to shut down, but it has to wait for the DSP thread to join. 
> > > Unfortunately the DSP thread is stuck waiting for events, and 
> > > there's nothing that can be done.
> > > 
> > > However, if we have a separate ioctl to interrupt that task, then 
> > > the main thread can issue that ioctl, and unlock the DSP thread 
> > > without having to wait 10s, or forever.
> > > 
> > > Does that make sense?
> > 
> > Maybe sending a signal to yourselft and having a dummy 
> signal Handle 
> > should work, it that would not like good.
> 
> Signals on libraries is a no-no.
> 
> > I am thinking On having a ioctl to create and set an event the you 
> > could Something like this:
> > 
> > struct dsp_notification events[3];
> > 
> > proc_register_notify(proc, event_type, &events[0]); ...
> > proc_register_notify(proc, event_type, &events[1]); ...
> > Sync_open_event(&events[2]);
> > 
> > 
> > second thread:
> > 
> > mgr_wait_for_bridge_events(proc, events, 3, index);
> > 
> > if (index == 2) 
> > /* main thread force exit */
> > 
> > 
> > Main thread:
> > 
> > /* if some execption happened then finish the second thread */
> > sync_set_event(events[2]);
> > 
> > pthread_join(...);
> > 
> > 
> > However it is in progess a task for change replacing 
> dspbridge sync.c 
> > Module with event_fd to signal events to userspace. Where 
> now simple 
> > File descriptor will be used as event elements. So the 
> > mgr_wait_for_bridge_events Will be implemented using 
> "select" system call inside to wait for multiple events.
> > So you will be able to do something like this:
> > 
> > int events[3];
> > 
> > proc_register_notify(proc, event_type, &events[0]); ...
> > proc_register_notify(proc, event_type, &events[1]); ...
> > events[2] = eventfd(0, 0);
> > 
> > 
> > second thread:
> > 
> > mgr_wait_for_bridge_events(proc, events, 3, index);
> > 
> > if (index == 2) 
> > /* main thread force exit */
> > 
> > Main thread:
> > 
> > /* if some execption happened then finish the second thread */
> > write(events[2], "s", 1);
> > 
> > pthread_join(...);
> > 
> > You won't need any aditional ioctl in order to do what you 
> want to do.
> > 
> > So, I think it is not worth to make much changes to some 
> module that 
> > will Dissapear (my patch is just a fix it is not implementing 
> > something new), It is just a matter of time to that task is 
> finished 
> > and tested properly And then send to LO.
> 
> All right, that makes sense. I just wanted to make suere you 
> are aware of that need.

Sure, that need will cover soon.

Thanks and regards,
Fernando.

> 
> --
> Felipe Contreras
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map

[Felipe Contreras]

fernando.l...@ti.com wrote:
> > fernando.l...@ti.com wrote:
> > > > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo 
> > > >  wrote:
> > > > > The device address is assigned by tidspbridge no need for
> > > > that parameter anymore.
> > > > >
> > > > > Signed-off-by: Fernando Guzman Lugo 
> > > > 
> > > > This would break the API with user-space, right?
> > > 
> > > Yes, user-space needs to be changed accordingly.
> > 
> > Wouldn't it make sense to avoid stuffing so many changes at 
> > once including ABI breakage?
> > 
> > Does user-space really _needs_ to be changed? Can't you just 
> > ignore that argument?
> 
> Actually, I had a previous version of that patch where I only
> Ignored that paramteter. But after thinking again and seeing
> How the long time ago depreacted function are still there I 
> Removed the parameter in order to force apps to make the change.

Again, can we concentrate on first getting this thing to work?

We can think on breaking things again later.

> You can ignore that argument at API level, so all users of the
> API not need to have change (in that momment). That should be
> Only few line change.

Yes, that's what I'm proposing.

> > > > I think this change should be delayed, preferably after we have a 
> > > > working tidspbridge.
> > > 
> > > The issue you were seeing must be fixed with patch 2/8, and 
> > Having all 
> > > the dependencies tidspbridge has to be working Properly.
> > 
> > Yes, which might not happen at .37. If we revert the iommu 
> > stuff, we might have a chance at having a working bridge on .37.
> 
> But havi that merged in tidspbridge make more pressure to merged
> The dependencies, if not maybe that wont have event for .38.

Those patches have been there for a while and there's no sign of when
they'll be merged. Also, remember that the fact that the patches have
been sent doesn't guarantee they would be on this, or even the next
cycle.

Besides, the rule followed here is: it's ready when it's ready. In the
meantime the driver should work, and we can do that rather easily.

> But That is just my opinion if you all are agree revert is the best
> Option I am ok, but I looks like more work reverting and rebaseing
> specially because it is a big change.

git makes this easy.

The hard part is for the people out there that are trying to use this
driver and have to hunt mailing lists and multiple repos just to get
this to work. Moving to staging was supposed to make this easier, not
harder.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 8/8] staging: tidspbridge - make sync_wait_on_event interruptible

[Felipe Contreras]

fernando.l...@ti.com wrote:
> > fernando.l...@ti.com wrote:
> > > > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo 
> > > >  wrote:
> > > > > So that avoid non-killable process.
> > > > 
> > > > It would be useful to interrupt these tasks from user-space. 
> > > > A separate ioctl to do that would be needed.
> > > 
> > > I don't see use case where that could be needed. It is only 
> > To avoid a 
> > > nonkillable task in the case the user pass an infinite Timeout.
> > > 
> > > If you have some test case where that ioctl would be needed Please 
> > > share it in order to find the best solution.
> > 
> > Well, imagine the application is using a library to access 
> > the DSP, and the library has a dedicated thread listening for 
> > DSP events in a loop.
> > This happens to be how libomxil-ti and gst-dsp work.
> > 
> > Now, the thread received the last message, but has set a 
> > timeout of 10s, or even worst, no timeout at all.
> > 
> > After realizing that was the last message, the main thread 
> > decides to shut down, but it has to wait for the DSP thread 
> > to join. Unfortunately the DSP thread is stuck waiting for 
> > events, and there's nothing that can be done.
> > 
> > However, if we have a separate ioctl to interrupt that task, 
> > then the main thread can issue that ioctl, and unlock the DSP 
> > thread without having to wait 10s, or forever.
> > 
> > Does that make sense?
> 
> Maybe sending a signal to yourselft and having a dummy signal
> Handle should work, it that would not like good.

Signals on libraries is a no-no.

> I am thinking On having a ioctl to create and set an event the you
> could Something like this:
> 
> struct dsp_notification events[3];
> 
> proc_register_notify(proc, event_type, &events[0]);
> ...
> proc_register_notify(proc, event_type, &events[1]);
> ...
> Sync_open_event(&events[2]);
> 
> 
> second thread:
> 
>   mgr_wait_for_bridge_events(proc, events, 3, index);
> 
>   if (index == 2) 
>   /* main thread force exit */
> 
> 
> Main thread:
> 
>   /* if some execption happened then finish the second thread */
>   sync_set_event(events[2]);
> 
>   pthread_join(...);
> 
> 
> However it is in progess a task for change replacing dspbridge sync.c
> Module with event_fd to signal events to userspace. Where now simple
> File descriptor will be used as event elements. So the 
> mgr_wait_for_bridge_events
> Will be implemented using "select" system call inside to wait for multiple 
> events.
> So you will be able to do something like this:
> 
> int events[3];
> 
> proc_register_notify(proc, event_type, &events[0]);
> ...
> proc_register_notify(proc, event_type, &events[1]);
> ...
> events[2] = eventfd(0, 0);
> 
> 
> second thread:
> 
>   mgr_wait_for_bridge_events(proc, events, 3, index);
> 
>   if (index == 2) 
>   /* main thread force exit */
> 
> Main thread:
> 
>   /* if some execption happened then finish the second thread */
>   write(events[2], "s", 1);
> 
>   pthread_join(...);
> 
> You won't need any aditional ioctl in order to do what you want to do.
> 
> So, I think it is not worth to make much changes to some module that will
> Dissapear (my patch is just a fix it is not implementing something new),
> It is just a matter of time to that task is finished and tested properly
> And then send to LO.

All right, that makes sense. I just wanted to make suere you are aware
of that need.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Rafael J. Wysocki]

On Tuesday, October 26, 2010, Pierre Tardy wrote:
> On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra  wrote:
> > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> >>
> >> +   trace_runtime_pm_usage(dev, 
> >> atomic_read(&dev->power.usage_count)+1);
> >> atomic_inc(&dev->power.usage_count);
> >
> > That's terribly racy..
> >
> I know. I'm not proud of this.. As I said, this is preliminary patch.
> We dont really need to have this prev_usage. This is just for debug.
> It mayprobably endup with something like:
> 
>  atomic_inc(&dev->power.usage_count);
> +   trace_power_device_usage(dev);

Well, please tell me what you're trying to achieve.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] omap: add hwspinlock device

[Tony Lindgren]

* Ohad Ben-Cohen  [101026 04:45]:
> On Mon, Oct 25, 2010 at 9:02 PM, Tony Lindgren  wrote:
> >> if you feel that (2) is justifiable/desirable, I would be more
> >> than happy to submit that version.
> >
> > Yes (2) please. I would assume there will be more use of this. And then
> > we (or probably me again!) don't have to deal with cleaning up the drivers
> > again in the future.
> 
> Sounds good.
> 
> >> Or do you mean a variation of (2) with only the specific locking bits
> >> coming from pdata func pointers ? I guess that in this case we just
> >> might as well go with the full (2).
> >
> > Yes variation of (2) where you only pass the locking function via
> > platform data would be best.
> 
> It feels a bit funky to me because we would still have code that is
> omap-specific inside the "common" probe()/remove() calls.
> 
> I suggest to move everything that is omap-specific to a small omap
> module that, once probed, would register itself with the common
> hwspinlock framework (after initializing its hardware).
> 
> That small platfom-specific module probably doesn't have to sit in the
> arch/ folder; we can follow established conventions like
> mmc/i2c/gpio/spi/etc..
> 
> With that in hand, the hwspinlock would really be hardware-agnostic,
> and then applying s/omap_hwspin/hwspin/ would be justified.
> 
> Does this sound reasonable to you ?

Sounds good to me.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Rafael J. Wysocki]

On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
> * Peter Zijlstra (pet...@infradead.org) wrote:
> > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> > > 
> > > +   trace_runtime_pm_usage(dev, 
> > > atomic_read(&dev->power.usage_count)+1);
> > > atomic_inc(&dev->power.usage_count); 
> > 
> > That's terribly racy..
> 
> Looking at the original code, it looks racy even without considering the
> tracepoint:
> 
> int __pm_runtime_get(struct device *dev, bool sync)
>  {
> int retval;
> 
> +   trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)+1);
> atomic_inc(&dev->power.usage_count);
> retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);
> 
> There is no implied memory barrier after "atomic_inc". So either all these
> inc/dec are protected with mutexes or spinlocks, in which case one might 
> wonder
> why atomic operations are used at all, or it's a racy mess. (I vote for the
> second option)

No, it isn't.

> kref should certainly be used there.

No, it shouldn't.

Please try to understand the code you're commenting on first.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Rafael J. Wysocki]

On Tuesday, October 26, 2010, Ingo Molnar wrote:
> 
> * Thomas Renninger  wrote:
> 
> > On Tuesday 26 October 2010 09:10:20 Ingo Molnar wrote:
> > > 
> > > * Thomas Renninger  wrote:
> > > 
> > > > Changes in V2:
> > > >   - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
> > > >   - Use u32 instead of u64 for cpuid, state which is by far enough
> > > > 
> > > > New power trace events:
> > > > power:processor_idle
> > > > power:processor_frequency
> > > > power:machine_suspend
> > > > 
> > > > 
> > > > C-state/idle accounting events:
> > > >   power:power_start
> > > >   power:power_end
> > > > are replaced with:
> > > >   power:processor_idle
> > > > 
> > > > and
> > > >   power:power_frequency
> > > > is replaced with:
> > > >   power:processor_frequency
> > > 
> > > Could you please name it power:cpu_idle and power:cpu_frequency instead, 
> > > for 
> > > shortness? We generally use 'cpu' in the kernel and for events.
> > Sure.
> > > 
> > > > power:machine_suspend
> > > 
> > > How will future PCI (or other device) power saving tracepoints be called?
> > > 
> > > Might be more consistent to use:
> > > 
> > >   power:cpu_idle
> > >   power:machine_idle
> > >   power:device_idle
> >
> > device idle is not true. Those may be low power modes
> > like reduced network throughput, reduced wlan range, the device
> > needs not to be idle.
> > Device power states is probably the most complex area, if such
> > a thing gets introduced, it should makes sense to state
> > the interface experimental for some time until a wider range of
> > devices uses it (in contrast to these new ones
> > which should not change that soon anymore...).
> 
> Ok.
> 
> > Also machine_idle may be true, but machine_suspend sounds more
> > familiar and everyone immediately knows what the event is about.
> 
> Ok - fair enough.
> 
> > > > +#define PWR_EVENT_EXIT 0x
> > > 
> > > Shouldnt this be part of the POWER_ enum? (and you can write -1 there)
> >
> > No, below enum will vanish, but -1 is nicer.
> 
> When it vanishes what will replace it?
> 
> > ...
> > 
> > > Plus:
> > > 
> > > > +DECLARE_EVENT_CLASS(processor,
> > > > +
> > > > +   TP_PROTO(unsigned int state, unsigned int cpu_id),
> > > > +
> > > > +   TP_ARGS(state, cpu_id),
> > > > +
> > > > +   TP_STRUCT__entry(
> > > > +   __field(u32,state   )
> > > > +   __field(u32,cpu_id  )
> > > 
> > > Trace entries can carry a cpu_id of the current processor already. Can 
> > > this cpu_id 
> > > ever be different from that CPU id?
> >
> > Yes. A core's frequency can depend on another one which
> > will get switched as well (by one command/MSR).
> > Compare with commit 6f4f2723d08534fd4e407e1e.
> > 
> > This can theoretically also be the case for sleep states.
> > Afaik such HW does not exist yet, but ACPI spec already
> > provides interfaces to pass these dependency from BIOS to OS.
> > -> We want a stable ABI and should be prepared for such stuff.
> > 
> > > > +   ),
> > > > +
> > > > +   TP_fast_assign(
> > > > +   __entry->state = state;
> > > > +   __entry->cpu_id = cpu_id;
> > > > +   ),
> > > > +
> > > > +   TP_printk("state=%lu cpu_id=%lu", (unsigned long)__entry->state,
> > > > + (unsigned long)__entry->cpu_id)
> > > > +);
> > > > +
> > > > +DEFINE_EVENT(processor, processor_idle,
> > > > +
> > > > +   TP_PROTO(unsigned int state, unsigned int cpu_id),
> > > > +
> > > > +TP_ARGS(state, cpu_id)
> > > > +);
> > > > +
> > > > +#define PWR_EVENT_EXIT 0x
> > > > +
> > > > +DEFINE_EVENT(processor, processor_frequency,
> > > > +
> > > > +   TP_PROTO(unsigned int frequency, unsigned int cpu_id),
> > > > +
> > > > +   TP_ARGS(frequency, cpu_id)
> > > > +);
> > > 
> > > So, we have a 'state' field in the class, which is used as 'state' by the 
> > > power::cpu_idle event, and as 'frequency' by the power::cpu_freq event?
> >
> > Yes, is this a problem?
> >
> > Definitions are a bit shorter having one power processor class.
> > As "frequency" is stated in frequency event definition everything should
> > be obvious and this one looks like the more elegant way to me.
> >  
> > > Are there any architectures that track frequency in Hz, not in kHz? If 
> > > yes, might 
> > > there ever be a need for the frequency value to be larger than 4.29 GHz? 
> > > If yes, 
> > > then it wont fit into u32.
> >
> > drivers/cpufreq subsystem is fixed to unsigned int (cmp. 
> > include/linux/cpufreq.h):
> > unsigned intmin;/* in kHz */
> > unsigned intmax;/* in kHz */
> > unsigned intcur;/* in kHz,
> > ...
> > that should be fine.
> 
> ok, good - so we should be fine up to 4 THz CPUs.
> 
> > > Also, might there be a future need to express different types of 
> > > frequencies? 
> > > For example, should we decide to track turbo frequencie

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Rafael J. Wysocki]

On Tuesday, October 26, 2010, Thomas Renninger wrote:
> On Tuesday 26 October 2010 13:21:29 Ingo Molnar wrote:
> > 
> > * Jean Pihet  wrote:
> ..
> > > >> +#ifndef _TRACE_POWER_ENUM_
> > > >> +#define _TRACE_POWER_ENUM_
> > > >> +enum {
> > > >> + POWER_NONE = 0,
> > > >> + POWER_CSTATE = 1,
> > > >> + POWER_PSTATE = 2,
> > > >> +};
> > > >> +#endif
> > > >
> > > > Since we are cleaning up all these events, those enum definitions dont 
> > > > really look
> > > > logical. For example, what is 'POWER_NONE'? Can a CPU have 'no power'?
> > >
> > > The enum belongs to the deprecated API so I would rather not touch it.
> > > Keeping the deprecated code isolated will make it easier to remove
> > > later.
> > 
> > So what will replace it? We still have a state field.
> Nothing, this is part of the cleanup.
> As you state above: POWER_NONE does not make sense at all.
> The whole thing (type= attribute that vanishes now) is
> passed to userspace, but never gets used there because the
> same info is in the event name:
> cpu_frequency <-> frequency_switch  <-> PSTATE
> cpu_idle  <-> power_start/power_end <-> CSTATE 
> 
> I expect that there was an initial power_start/end which
> was also used for frequency switching.
> Then it got realized that _start/_end does not work out and
> frequency_switch got introduced.
> To stay compatible the whole power_start/end was not renamed
> to cpu_idle and the type= field was kept.
> 
> This is a guess without even looking at the git history.
> Therefore my partly harsh comments about the sanity of the
> current power tracing events.
> 
> > Passing in platform specific codes is a step backwards.
> > 
> > > >> +TRACE_EVENT(machine_suspend,
> > > >> +
> > > >> + TP_PROTO(unsigned int state),
> > > >> +
> > > >> + TP_ARGS(state),
> > > >> +
> > > >> + TP_STRUCT__entry(
> > > >> + __field(u32,state   )
> > > >> + ),
> > > >
> > > > Hm, this event is not used anywhere in the submitted patches. Where is 
> > > > the patch
> > > > that adds usage, and what are the possible values for 'state'?
> > >
> > > This will come as a separate patch, which fits all platforms. Cf.
> > > http://marc.info/?l=linux-omap&m=128620575300682&w=2.
> > > The state field is of type suspend_state_t, cf. include/linux/suspend.h
> > 
> > Ok, that's at least generic. Needs the review of Rafael, to determine
> > whether this state value is all we want to know when we enter suspend.
> He already gave an acked-by on this generic one here:
> Re: [PATCH 3/4] perf: add calls to suspend trace point
> Oh now, that was on the X86 specific part which depends on this one.
> One should expect that he's fine with the generic part as well then,
> but I agree that he should definitely have a look at this and sign it off.

What patch exactly do you mean?  I'm not quite sure from your comment above.

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Rafael J. Wysocki]

On Tuesday, October 26, 2010, Thomas Renninger wrote:
> Changes in V2:
>   - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
>   - Use u32 instead of u64 for cpuid, state which is by far enough
> 
> New power trace events:
> power:processor_idle
> power:processor_frequency
> power:machine_suspend
> 
> 
> C-state/idle accounting events:
>   power:power_start
>   power:power_end
> are replaced with:
>   power:processor_idle
> 
> and
>   power:power_frequency
> is replaced with:
>   power:processor_frequency
> 
> power:machine_suspend
> is newly introduced, a first implementation
> comes from the ARM side, but it's easy to add these events
> in X86 as well if needed.

As I said already somewhere else, I think this one should be done at the
core level rather than in arch-specific code.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH] PERF(kernel): Cleanup power events V2

[Alan Stern]

On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:

> * Peter Zijlstra (pet...@infradead.org) wrote:
> > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> > > 
> > > +   trace_runtime_pm_usage(dev, 
> > > atomic_read(&dev->power.usage_count)+1);
> > > atomic_inc(&dev->power.usage_count); 
> > 
> > That's terribly racy..
> 
> Looking at the original code, it looks racy even without considering the
> tracepoint:
> 
> int __pm_runtime_get(struct device *dev, bool sync)
>  {
> int retval;
> 
> +   trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)+1);
> atomic_inc(&dev->power.usage_count);
> retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);
> 
> There is no implied memory barrier after "atomic_inc". So either all these
> inc/dec are protected with mutexes or spinlocks, in which case one might 
> wonder
> why atomic operations are used at all, or it's a racy mess. (I vote for the
> second option)

I don't understand.  What's the problem?  The inc/dec are atomic 
because they are not protected by spinlocks, but everything else is 
(aside from the tracepoint, which is new).

> kref should certainly be used there.

What for?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Pierre Tardy]

On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra  wrote:
> On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
>>
>> +       trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)+1);
>>         atomic_inc(&dev->power.usage_count);
>
> That's terribly racy..
>
I know. I'm not proud of this.. As I said, this is preliminary patch.
We dont really need to have this prev_usage. This is just for debug.
It mayprobably endup with something like:

 atomic_inc(&dev->power.usage_count);
+   trace_power_device_usage(dev);

-- 
Pierre
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Mathieu Desnoyers]

* Peter Zijlstra (pet...@infradead.org) wrote:
> On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> > 
> > +   trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)+1);
> > atomic_inc(&dev->power.usage_count); 
> 
> That's terribly racy..

Looking at the original code, it looks racy even without considering the
tracepoint:

int __pm_runtime_get(struct device *dev, bool sync)
 {
int retval;

+   trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)+1);
atomic_inc(&dev->power.usage_count);
retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);

There is no implied memory barrier after "atomic_inc". So either all these
inc/dec are protected with mutexes or spinlocks, in which case one might wonder
why atomic operations are used at all, or it's a racy mess. (I vote for the
second option)

kref should certainly be used there.

About the instrumentation, well... the only way to have something that's not
racy would be to instrument kref directly, and use atomic_add_return() in both
the get/put paths. But I fear that the performance impact on many architectures
might be significant (turning atomic_add + smp_mb() into a cmpxchg()). Maybe it
could be acceptable as a kernel debug option.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map

[Guzman Lugo, Fernando]

 

> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@nokia.com] 
> Sent: Tuesday, October 26, 2010 12:08 PM
> To: Guzman Lugo, Fernando; felipe.contre...@gmail.com
> Cc: gre...@suse.de; hiroshi.d...@nokia.com; 
> linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; 
> linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: RE: [PATCH 1/8] staging: tidspbridge - remove 
> req_addr from proc_map
> 
> fernando.l...@ti.com wrote:
> > > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo 
> > >  wrote:
> > > > The device address is assigned by tidspbridge no need for
> > > that parameter anymore.
> > > >
> > > > Signed-off-by: Fernando Guzman Lugo 
> > > 
> > > This would break the API with user-space, right?
> > 
> > Yes, user-space needs to be changed accordingly.
> 
> Wouldn't it make sense to avoid stuffing so many changes at 
> once including ABI breakage?
> 
> Does user-space really _needs_ to be changed? Can't you just 
> ignore that argument?

Actually, I had a previous version of that patch where I only
Ignored that paramteter. But after thinking again and seeing
How the long time ago depreacted function are still there I 
Removed the parameter in order to force apps to make the change.

You can ignore that argument at API level, so all users of the
API not need to have change (in that momment). That should be
Only few line change.

> 
> > > I think this change should be delayed, preferably after we have a 
> > > working tidspbridge.
> > 
> > The issue you were seeing must be fixed with patch 2/8, and 
> Having all 
> > the dependencies tidspbridge has to be working Properly.
> 
> Yes, which might not happen at .37. If we revert the iommu 
> stuff, we might have a chance at having a working bridge on .37.

But havi that merged in tidspbridge make more pressure to merged
The dependencies, if not maybe that wont have event for .38. But
That is just my opinion if you all are agree revert is the best
Option I am ok, but I looks like more work reverting and rebaseing
specially because it is a big change.

Thanks and regards,
Fernando.

> 
> --
> Felipe Contreras
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Peter Zijlstra]

On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> 
> +   trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)+1);
> atomic_inc(&dev->power.usage_count); 

That's terribly racy..
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 8/8] staging: tidspbridge - make sync_wait_on_event interruptible

[Guzman Lugo, Fernando]

 

> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@nokia.com] 
> Sent: Tuesday, October 26, 2010 12:03 PM
> To: Guzman Lugo, Fernando; felipe.contre...@gmail.com
> Cc: gre...@suse.de; hiroshi.d...@nokia.com; 
> linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; 
> linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: RE: [PATCH 8/8] staging: tidspbridge - make 
> sync_wait_on_event interruptible
> 
> fernando.l...@ti.com wrote:
> > > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo 
> > >  wrote:
> > > > So that avoid non-killable process.
> > > 
> > > It would be useful to interrupt these tasks from user-space. 
> > > A separate ioctl to do that would be needed.
> > 
> > I don't see use case where that could be needed. It is only 
> To avoid a 
> > nonkillable task in the case the user pass an infinite Timeout.
> > 
> > If you have some test case where that ioctl would be needed Please 
> > share it in order to find the best solution.
> 
> Well, imagine the application is using a library to access 
> the DSP, and the library has a dedicated thread listening for 
> DSP events in a loop.
> This happens to be how libomxil-ti and gst-dsp work.
> 
> Now, the thread received the last message, but has set a 
> timeout of 10s, or even worst, no timeout at all.
> 
> After realizing that was the last message, the main thread 
> decides to shut down, but it has to wait for the DSP thread 
> to join. Unfortunately the DSP thread is stuck waiting for 
> events, and there's nothing that can be done.
> 
> However, if we have a separate ioctl to interrupt that task, 
> then the main thread can issue that ioctl, and unlock the DSP 
> thread without having to wait 10s, or forever.
> 
> Does that make sense?

Maybe sending a signal to yourselft and having a dummy signal
Handle should work, it that would not like good. I am thinking
On having a ioctl to create and set an event the you could
Something like this:

struct dsp_notification events[3];

proc_register_notify(proc, event_type, &events[0]);
...
proc_register_notify(proc, event_type, &events[1]);
...
Sync_open_event(&events[2]);


second thread:

mgr_wait_for_bridge_events(proc, events, 3, index);

if (index == 2) 
/* main thread force exit */


Main thread:

/* if some execption happened then finish the second thread */
sync_set_event(events[2]);

pthread_join(...);


However it is in progess a task for change replacing dspbridge sync.c
Module with event_fd to signal events to userspace. Where now simple
File descriptor will be used as event elements. So the 
mgr_wait_for_bridge_events
Will be implemented using "select" system call inside to wait for multiple 
events.
So you will be able to do something like this:

int events[3];

proc_register_notify(proc, event_type, &events[0]);
...
proc_register_notify(proc, event_type, &events[1]);
...
events[2] = eventfd(0, 0);


second thread:

mgr_wait_for_bridge_events(proc, events, 3, index);

if (index == 2) 
/* main thread force exit */

Main thread:

/* if some execption happened then finish the second thread */
write(events[2], "s", 1);

pthread_join(...);

You won't need any aditional ioctl in order to do what you want to do.

So, I think it is not worth to make much changes to some module that will
Dissapear (my patch is just a fix it is not implementing something new),
It is just a matter of time to that task is finished and tested properly
And then send to LO.

Regards,
Fernando.

> 
> --
> Felipe Contreras
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/4] tidspbridge: SCM layer violation fixes

[Omar Ramirez Luna]

On Tue, Oct 26, 2010 at 12:13 PM, Felipe Contreras
 wrote:
>>  arch/arm/plat-omap/include/plat/iva2_dsp.h    |   56 
>> +
>
> Why not use the already existing dsp.h?

Good point, I guess when the patch was made dsp.h didn't exist, but
since the user of those defines is pm34xx.c too, including it in dsp.h
would include the declaration of everything inside dsp.h; however I
don't see that as an impediment for dma.h or gpmc.h to be included.

Regards,
Omar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/4] tidspbridge: SCM layer violation fixes

[Felipe Contreras]

On Tue, Oct 26, 2010 at 7:15 PM, Omar Ramirez Luna  wrote:
> This is the patch series shared by Paul, for a short term fix to
> a compile break due SCM layer layer violations from tidspbridge
> driver, where the latter is used to write directly into registers
> and use SCM layer macros, among other layer bypassing.
>
> patch: "staging: tidspbridge: use new SCM DSP boot control fns"
> was split from its original version, it is meant to be on hold until
> the rest of the series gets upstreamed and can be found in the
> staging tree (unless best advice is given).
>
> Paul Walmsley (4):
>  OMAP: control: add functions for DSP boot address/mode control
>  OMAP3: PM: update DSP reset code to use new SCM DSP boot control
>    functions
>  OMAP: dsp: convert OMAP3430 adaptation layer to use new SCM DSP boot
>    control fns
>  staging: tidspbridge: use new SCM DSP boot control fns
>
>  arch/arm/mach-omap2/control.c                 |   51 ++
>  arch/arm/mach-omap2/control.h                 |   16 ---
>  arch/arm/mach-omap2/dsp.c                     |    4 ++
>  arch/arm/mach-omap2/pm34xx.c                  |    6 +-
>  arch/arm/plat-omap/include/plat/dsp.h         |    4 ++
>  arch/arm/plat-omap/include/plat/iva2_dsp.h    |   56 
> +

Why not use the already existing dsp.h?

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map

[Felipe Contreras]

fernando.l...@ti.com wrote:
> > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo 
> >  wrote:
> > > The device address is assigned by tidspbridge no need for 
> > that parameter anymore.
> > >
> > > Signed-off-by: Fernando Guzman Lugo 
> > 
> > This would break the API with user-space, right?
> 
> Yes, user-space needs to be changed accordingly.

Wouldn't it make sense to avoid stuffing so many changes at once
including ABI breakage?

Does user-space really _needs_ to be changed? Can't you just ignore that
argument?

> > I think this change should be delayed, preferably after we 
> > have a working tidspbridge.
> 
> The issue you were seeing must be fixed with patch 2/8, and
> Having all the dependencies tidspbridge has to be working
> Properly.

Yes, which might not happen at .37. If we revert the iommu stuff, we
might have a chance at having a working bridge on .37.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 8/8] staging: tidspbridge - make sync_wait_on_event interruptible

[Felipe Contreras]

fernando.l...@ti.com wrote:
> > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo 
> >  wrote:
> > > So that avoid non-killable process.
> > 
> > It would be useful to interrupt these tasks from user-space. 
> > A separate ioctl to do that would be needed.
> 
> I don't see use case where that could be needed. It is only
> To avoid a nonkillable task in the case the user pass an infinite
> Timeout.
> 
> If you have some test case where that ioctl would be needed
> Please share it in order to find the best solution.

Well, imagine the application is using a library to access the DSP, and
the library has a dedicated thread listening for DSP events in a loop.
This happens to be how libomxil-ti and gst-dsp work.

Now, the thread received the last message, but has set a timeout of 10s,
or even worst, no timeout at all.

After realizing that was the last message, the main thread decides to
shut down, but it has to wait for the DSP thread to join. Unfortunately
the DSP thread is stuck waiting for events, and there's nothing that can
be done.

However, if we have a separate ioctl to interrupt that task, then the
main thread can issue that ioctl, and unlock the DSP thread without
having to wait 10s, or forever.

Does that make sense?

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Pierre Tardy]

> I would like to see a slightly more advanced tracepoint do the runtime pm
> framework;
> specifically I'd like to see the "comm" of the process that's taking a
> refcount on a device
> (that way, powertop can track which process keeps a device busy)
>
>
Yes, the "comm" for this tracepoint should be the runtime_pm workqueue.
To track responsabilities, I'm making another tracepoint, that traces
the rpm_get/put.

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 0f38447..54d9911 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -792,7 +792,7 @@ EXPORT_SYMBOL_GPL(pm_request_resume);
 int __pm_runtime_get(struct device *dev, bool sync)
 {
int retval;

+   trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)+1);
atomic_inc(&dev->power.usage_count);
retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);

@@ -813,6 +813,7 @@ int __pm_runtime_put(struct device *dev, bool sync)
 {
int retval = 0;

+   trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)-1);
if (atomic_dec_and_test(&dev->power.usage_count))
retval = sync ? pm_runtime_idle(dev) : pm_request_idle(dev);

@@ -1065,6 +1066,7 @@ void pm_runtime_forbid(struct device *dev)
goto out;

dev->power.runtime_auto = false;
+   trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)+1);
atomic_inc(&dev->power.usage_count);
__pm_runtime_resume(dev, false);

@@ -1086,6 +1088,7 @@ void pm_runtime_allow(struct device *dev)
goto out;

dev->power.runtime_auto = true;
+   trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)-1);
if (atomic_dec_and_test(&dev->power.usage_count))
__pm_runtime_idle(dev);
diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index ea514eb..813229c 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -100,6 +100,29 @@ TRACE_EVENT(runtime_pm_status,
TP_printk("driver=%s dev=%s prev_status=%s status=%s",
__get_str(drivername),__get_str(devname),
  show_rpm_status_name(__entry->prev_status),
show_rpm_status_name(__entry->status))
 );
+TRACE_EVENT(runtime_pm_usage,
+
+   TP_PROTO(struct device *dev, int new_usage),
+
+   TP_ARGS(dev, new_usage),
+
+   TP_STRUCT__entry(
+   __string(devname,dev_name(dev))
+   __string(drivername,dev_driver_string(dev))
+   __field(u32, prev_usage)
+   __field(u32, usage)
+   ),
+
+   TP_fast_assign(
+   __assign_str(devname, dev_name(dev));
+   __assign_str(drivername, dev_driver_string(dev));
+   __entry->prev_usage = (u32)atomic_read(&dev->power.usage_count);
+   __entry->usage = (u32)new_usage;
+   ),
+
+   TP_printk("driver=%s dev=%s prev_usage=%d usage=%s",
__get_str(drivername),__get_str(devname),
+ __entry->prev_usage, __entry->usage)
+);
-- 
Pierre
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

omap-pcm audio playback skips couple frames at first interrupt

[ylin]

Hi,

I am using 2.6.32 with omap3evm board.
The audio skips a couple of frames at the first interrupt on palyback 
(TWL4030) when I use small period size (10msec).  But the same 
parameters work fine on capture.  With large period/frame size, it 
works fine also.
The skip causes extra delays (30msec at 16kHz) which I tried to 
minimize.  From omap-pcm.c the similar parameters are used to setup DMA 
for both playback and capture, but why only playback does the skip?


The following are logs with xrun_debug=9:

r...@omap3evm:~# aplay -f S16_LE -r 16000 -c 2 -d 1 -F 1 -B 8 
-R 1 -T 16 < /dev/urandom


Oct 26 11:04:11 omap3evm user.debug kernel: ALSA 
sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: 
pos=0x280/0xa0/0x500, hwptr=0x0, hw_base=0x0, hw_intr=0x0
Oct 26 11:04:11 omap3evm user.debug kernel: ALSA 
sound/core/pcm_lib.c:334: PCM: Lost interrupts? (stream=0, delta=480, 
intr_ptr=160)
Oct 26 11:04:11 omap3evm user.debug kernel: ALSA 
sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: 
pos=0x3c0/0xa0/0x500, hwptr=0x320, hw_base=0x0, hw_intr=0x320
Oct 26 11:04:11 omap3evm user.debug kernel: ALSA 
sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: 
pos=0x0/0xa0/0x500, hwptr=0x460, hw_base=0x0, hw_intr=0x460
Oct 26 11:04:11 omap3evm user.debug kernel: ALSA 
sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: 
pos=0x140/0xa0/0x500, hwptr=0x5a0, hw_base=0x500, hw_intr=0x5a0
Oct 26 11:04:11 omap3evm user.debug kernel: ALSA 
sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: 
pos=0x280/0xa0/0x500, hwptr=0x6e0, hw_base=0x500, hw_intr=0x6e0
Oct 26 11:04:11 omap3evm user.debug kernel: ALSA 
sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: 
pos=0x3c0/0xa0/0x500, hwptr=0x820, hw_base=0x500, hw_intr=0x820
Oct 26 11:04:11 omap3evm user.debug kernel: ALSA 
sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: 
pos=0x0/0xa0/0x500, hwptr=0x960, hw_base=0x500, hw_intr=0x960



r...@omap3evm:~# arecord -f S16_LE -r 16000 -c 2 -d 1 -F 1 -B 8 
-R 1 -T 16 /tmp/test.pcm


Oct 26 11:04:13 omap3evm user.debug kernel: ALSA 
sound/core/pcm_lib.c:250: period_update: pcmC0D0c:0: 
pos=0x140/0xa0/0x500, hwptr=0xa0, hw_base=0x0, hw_intr=0xa0
Oct 26 11:04:13 omap3evm user.debug kernel: ALSA 
sound/core/pcm_lib.c:250: period_update: pcmC0D0c:0: 
pos=0x280/0xa0/0x500, hwptr=0x1e0, hw_base=0x0, hw_intr=0x1e0
Oct 26 11:04:13 omap3evm user.debug kernel: ALSA 
sound/core/pcm_lib.c:250: period_update: pcmC0D0c:0: 
pos=0x3c0/0xa0/0x500, hwptr=0x320, hw_base=0x0, hw_intr=0x320



r...@omap3evm:~# aplay -f S16_LE -r 16000 -c 2 -d 1 -F 4 -B 32 
-R 4 -T 64 < /dev/urandom


Oct 26 11:18:46 omap3evm user.debug kernel: ALSA 
sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: 
pos=0x400/0x200/0x1400, hwptr=0x200, hw_base=0x0, hw_intr=0x200
Oct 26 11:18:46 omap3evm user.debug kernel: ALSA 
sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: 
pos=0x800/0x200/0x1400, hwptr=0x600, hw_base=0x0, hw_intr=0x600
Oct 26 11:18:46 omap3evm user.debug kernel: ALSA 
sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: 
pos=0xc00/0x200/0x1400, hwptr=0xa00, hw_base=0x0, hw_intr=0xa00


Best regards,
Ying Lin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/4] OMAP: dsp: convert OMAP3430 adaptation layer to use new SCM DSP boot control fns

[Omar Ramirez Luna]

From: Paul Walmsley 

DSPBridge currently tries to __raw_writel() to the System Control
Module to control the DSP boot process.  This is a layering violation;
this is SoC-specific code, and belongs in a file in
arch/arm/mach-omap2/*.  None of those CM and PRM register accesses
through struct platform_data belong under drivers/.  (Nor would they
belong in DSP platform init code in arch/arm/mach-omap2/* - such code
must use the clock, clockdomain, powerdomain, omap_device, and
omap_hwmod layers that are provided for this purpose.)

The immediate problem, however, is that after commit
346a5c890a55495c718394b74214be1de9303cf6, this code can no longer compile.
So to fix this immediate problem, convert the DSP boot control code to
use platform_data function pointers.

Signed-off-by: Paul Walmsley 
Cc: 
---
 arch/arm/mach-omap2/dsp.c |4 
 arch/arm/plat-omap/include/plat/dsp.h |4 
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c
index 6feeeae..307f67a 100644
--- a/arch/arm/mach-omap2/dsp.c
+++ b/arch/arm/mach-omap2/dsp.c
@@ -12,6 +12,7 @@
  */
 
 #include 
+#include "control.h"
 #include "prm.h"
 #include "cm.h"
 #ifdef CONFIG_BRIDGE_DVFS
@@ -31,6 +32,9 @@ static struct omap_dsp_platform_data omap_dsp_pdata 
__initdata = {
.cpu_set_freq = omap_pm_cpu_set_freq,
.cpu_get_freq = omap_pm_cpu_get_freq,
 #endif
+   .set_dsp_bootaddr = omap2430_ctrl_set_dsp_bootaddr,
+   .set_dsp_bootmode = omap2430_ctrl_set_dsp_bootmode,
+
.dsp_prm_read = prm_read_mod_reg,
.dsp_prm_write = prm_write_mod_reg,
.dsp_prm_rmw_bits = prm_rmw_mod_reg_bits,
diff --git a/arch/arm/plat-omap/include/plat/dsp.h 
b/arch/arm/plat-omap/include/plat/dsp.h
index 9c604b3..34e2bd8 100644
--- a/arch/arm/plat-omap/include/plat/dsp.h
+++ b/arch/arm/plat-omap/include/plat/dsp.h
@@ -10,7 +10,11 @@ struct omap_dsp_platform_data {
unsigned long (*cpu_get_freq) (void);
unsigned long mpu_speed[6];
 
+   void (*set_dsp_bootaddr)(u32 pa);
+   void (*set_dsp_bootmode)(u8 mode);
+
/* functions to write and read PRCM registers */
+   /* XXX None of this should be here */
void (*dsp_prm_write)(u32, s16 , u16);
u32 (*dsp_prm_read)(s16 , u16);
u32 (*dsp_prm_rmw_bits)(u32, u32, s16, s16);
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/4] tidspbridge: SCM layer violation fixes

[Omar Ramirez Luna]

This is the patch series shared by Paul, for a short term fix to
a compile break due SCM layer layer violations from tidspbridge
driver, where the latter is used to write directly into registers
and use SCM layer macros, among other layer bypassing.

patch: "staging: tidspbridge: use new SCM DSP boot control fns"
was split from its original version, it is meant to be on hold until
the rest of the series gets upstreamed and can be found in the
staging tree (unless best advice is given).

Paul Walmsley (4):
  OMAP: control: add functions for DSP boot address/mode control
  OMAP3: PM: update DSP reset code to use new SCM DSP boot control
functions
  OMAP: dsp: convert OMAP3430 adaptation layer to use new SCM DSP boot
control fns
  staging: tidspbridge: use new SCM DSP boot control fns

 arch/arm/mach-omap2/control.c |   51 ++
 arch/arm/mach-omap2/control.h |   16 ---
 arch/arm/mach-omap2/dsp.c |4 ++
 arch/arm/mach-omap2/pm34xx.c  |6 +-
 arch/arm/plat-omap/include/plat/dsp.h |4 ++
 arch/arm/plat-omap/include/plat/iva2_dsp.h|   56 +
 drivers/staging/tidspbridge/core/tiomap3430.c |   13 +++---
 7 files changed, 133 insertions(+), 17 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/iva2_dsp.h

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/4] OMAP: control: add functions for DSP boot address/mode control

[Omar Ramirez Luna]

From: Paul Walmsley 

Add two functions for OMAP2430/OMAP3 IVA2 DSP boot control.  These
registers wound up in the System Control Module.  Other kernel code
that wishes to control the DSP's boot process should now use these
functions to do so; subsequent patches implement this in the two
in-tree users of these functions.

Signed-off-by: Paul Walmsley 
---
 arch/arm/mach-omap2/control.c  |   51 +
 arch/arm/mach-omap2/control.h  |   16 ---
 arch/arm/plat-omap/include/plat/iva2_dsp.h |   56 
 3 files changed, 116 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/iva2_dsp.h

diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 1fa3294..90fae36 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -209,6 +209,57 @@ void omap4_ctrl_pad_writel(u32 val, u16 offset)
__raw_writel(val, OMAP4_CTRL_PAD_REGADDR(offset));
 }
 
+/*
+ * OMAP3 DSP control functions
+ */
+
+/**
+ * omap2430_ctrl_set_dsp_bootaddr - set the DSP's boot address
+ * @pa: DSP boot address (in physical memory)
+ *
+ * Set the DSP's boot address.  This is an address in physical memory.
+ * No return value.  XXX The TRM claims that this is an "index to a
+ * 4kByte page".  If so, why is the bitfield 21 bits wide, rather than
+ * 20?
+ */
+void omap2430_ctrl_set_dsp_bootaddr(u32 pa)
+{
+   if (!(cpu_is_omap2430() || cpu_is_omap34xx())) {
+   WARN(1, "control: %s: not supported on this SoC\n", __func__);
+   return;
+   }
+
+   WARN(pa & ~OMAP_CTRL_DSP_BOOTADDR_MASK,
+"control: %s: invalid DSP boot address %08x\n", __func__, pa);
+
+   omap_ctrl_writel(pa, OMAP243X_CONTROL_IVA2_BOOTADDR);
+}
+
+/**
+ * omap2430_ctrl_set_dsp_bootmode - set the DSP's boot mode
+ * @mode: DSP boot mode (described below)
+ *
+ * Sets the DSP boot mode - see OMAP3 TRM revision ZH section 7.4.7.4
+ * "IVA2.2 Boot Registers".  Known values of @mode include 0, to boot
+ * directly to the address supplied by omap2_ctrl_set_dsp_bootaddr();
+ * 1, to boot to the DSP's ROM code and idle, waiting for interrupts;
+ * 2, to boot to the DSP's ROM code and spin in an idle loop; 3, to
+ * copy the user's bootstrap code from the DSP's internal memory and
+ * execute it (XXX how does the DSP know where to copy from?); and 4,
+ * to execute the DSP ROM code's context restore code.  No return
+ * value.
+ */
+void omap2430_ctrl_set_dsp_bootmode(u8 mode)
+{
+   if (!(cpu_is_omap2430() || cpu_is_omap34xx())) {
+   WARN(1, "control: %s: not supported on this SoC\n", __func__);
+   return;
+   }
+
+   omap_ctrl_writel(mode, OMAP243X_CONTROL_IVA2_BOOTMOD);
+}
+
+
 #if defined(CONFIG_ARCH_OMAP3) && defined(CONFIG_PM)
 /*
  * Clears the scratchpad contents in case of cold boot-
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index b6c6b7c..ac14e0a 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -258,11 +258,6 @@
 /* CONTROL_PROG_IO1 bits */
 #define OMAP3630_PRG_SDMMC1_SPEEDCTRL  (1 << 20)
 
-/* CONTROL_IVA2_BOOTMOD bits */
-#define OMAP3_IVA2_BOOTMOD_SHIFT   0
-#define OMAP3_IVA2_BOOTMOD_MASK(0xf << 0)
-#define OMAP3_IVA2_BOOTMOD_IDLE(0x1 << 0)
-
 /* CONTROL_PADCONF_X bits */
 #define OMAP3_PADCONF_WAKEUPEVENT0 (1 << 15)
 #define OMAP3_PADCONF_WAKEUPENABLE0(1 << 14)
@@ -280,7 +275,7 @@
 #define AM35XX_CPGMAC_FCLK_SHIFT9
 #define AM35XX_VPFE_FCLK_SHIFT  10
 
-/*AM35XX CONTROL_LVL_INTR_CLEAR bits*/
+/* AM35XX CONTROL_LVL_INTR_CLEAR bits */
 #define AM35XX_CPGMAC_C0_MISC_PULSE_CLRBIT(0)
 #define AM35XX_CPGMAC_C0_RX_PULSE_CLR  BIT(1)
 #define AM35XX_CPGMAC_C0_RX_THRESH_CLR BIT(2)
@@ -290,7 +285,7 @@
 #define AM35XX_VPFE_CCDC_VD1_INT_CLR   BIT(6)
 #define AM35XX_VPFE_CCDC_VD2_INT_CLR   BIT(7)
 
-/*AM35XX CONTROL_IP_SW_RESET bits*/
+/* AM35XX CONTROL_IP_SW_RESET bits */
 #define AM35XX_USBOTGSS_SW_RST BIT(0)
 #define AM35XX_CPGMACSS_SW_RST BIT(1)
 #define AM35XX_VPFE_VBUSP_SW_RST   BIT(2)
@@ -330,6 +325,10 @@
 #defineFEAT_NEON   0
 #defineFEAT_NEON_NONE  1
 
+/*
+ * DSP booting-related constants
+ */
+#define OMAP_CTRL_DSP_BOOTADDR_MASK0xfc00
 
 #ifndef __ASSEMBLY__
 #ifdef CONFIG_ARCH_OMAP2PLUS
@@ -351,6 +350,9 @@ extern u32 omap3_arm_context[128];
 extern void omap3_control_save_context(void);
 extern void omap3_control_restore_context(void);
 
+extern void omap2430_ctrl_set_dsp_bootaddr(u32 pa);
+extern void omap2430_ctrl_set_dsp_bootmode(u8 mode);
+
 #else
 #define omap_ctrl_base_get()   0
 #define omap_ctrl_readb(x) 0
diff --git a/arch/arm/plat-omap/include/plat/iva2_dsp.h 
b/arch/arm/plat-omap/include/plat/iva2_dsp.h
new file mode 100644
index 000..495c6a9
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/i

[PATCH v2 2/4] OMAP3: PM: update DSP reset code to use new SCM DSP boot control functions

[Omar Ramirez Luna]

From: Paul Walmsley 

Update the DSP reset code in pm34xx.c to use one of the new SCM DSP
boot control functions, omap2430_ctrl_set_dsp_bootmode().

This reset code should be moved out to a separate function to be
called by the hwmod reset process at some point.  Also, 2430
should be initializing the DSP in a similar fashion.

Signed-off-by: Paul Walmsley 
Cc: Kevin Hilman 
---
 arch/arm/mach-omap2/pm34xx.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 8c8f1ac..b90b1fb 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -614,6 +615,7 @@ static struct platform_suspend_ops omap_pm_ops = {
  * function forces the IVA2 into idle state so it can go
  * into retention/off and thus allow full-chip retention/off.
  *
+ * XXX This should be handled by the hwmod.
  **/
 static void __init omap3_iva_idle(void)
 {
@@ -635,9 +637,7 @@ static void __init omap3_iva_idle(void)
cm_write_mod_reg(OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_MASK,
 OMAP3430_IVA2_MOD, CM_FCLKEN);
 
-   /* Set IVA2 boot mode to 'idle' */
-   omap_ctrl_writel(OMAP3_IVA2_BOOTMOD_IDLE,
-OMAP343X_CONTROL_IVA2_BOOTMOD);
+   omap2430_ctrl_set_dsp_bootmode(OMAP_IVA2_DSP_BOOTMODE_IDLE);
 
/* Un-reset IVA2 */
prm_write_mod_reg(0, OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/4] staging: tidspbridge: use new SCM DSP boot control fns

[Omar Ramirez Luna]

From: Paul Walmsley 

Use the new functions from SCM layer instead of handling registers
directly with __raw_writel, as explained in:

http://marc.info/?l=linux-omap&m=128779652429922&w=2

Signed-off-by: Paul Walmsley 
Signed-off-by: Omar Ramirez Luna 
---
 drivers/staging/tidspbridge/core/tiomap3430.c |   13 ++---
 1 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c 
b/drivers/staging/tidspbridge/core/tiomap3430.c
index f22bc12..b91d911 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -23,7 +23,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 /*  --- DSP/BIOS Bridge */
 #include 
@@ -293,6 +293,7 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
u32 clk_cmd;
struct io_mgr *hio_mgr;
u32 ul_load_monitor_timer;
+   u8 bootmode;
struct omap_dsp_platform_data *pdata =
omap_dspbridge_dev->dev.platform_data;
 
@@ -334,15 +335,13 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
OMAP3430_RST1_IVA2_MASK, 
OMAP3430_IVA2_MOD,
OMAP2_RM_RSTCTRL);
/* Mask address with 1K for compatibility */
-   __raw_writel(dsp_addr & OMAP3_IVA2_BOOTADDR_MASK,
-   OMAP343X_CTRL_REGADDR(
-   OMAP343X_CONTROL_IVA2_BOOTADDR));
+   dsp_addr &= OMAP3_IVA2_BOOTADDR_MASK;
+   (*pdata->set_dsp_bootaddr)(dsp_addr);
/*
 * Set bootmode to self loop if dsp_debug flag is true
 */
-   __raw_writel((dsp_debug) ? OMAP3_IVA2_BOOTMOD_IDLE : 0,
-   OMAP343X_CTRL_REGADDR(
-   OMAP343X_CONTROL_IVA2_BOOTMOD));
+   bootmode = dsp_debug ? OMAP_IVA2_DSP_BOOTMODE_IDLE : 0;
+   (*pdata->set_dsp_bootmode)(bootmode);
}
}
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Arjan van de Ven]

On 10/26/2010 8:32 AM, Pierre Tardy wrote:

On Tue, Oct 26, 2010 at 2:10 AM, Ingo Molnar  wrote:


How will future PCI (or other device) power saving tracepoints be called?

Might be more consistent to use:

  power:cpu_idle
  power:machine_idle
  power:device_idle

Agree with this.

FYI, I have a runtime_pm tracepoint currently cooking. Here is
preliminary patch.
Can this be a candidate for a "power:device_idle" tracepoint?



I would like to see a slightly more advanced tracepoint do the runtime 
pm framework;
specifically I'd like to see the "comm" of the process that's taking a 
refcount on a device

(that way, powertop can track which process keeps a device busy)

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map

[Guzman Lugo, Fernando]

 

> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com] 
> Sent: Tuesday, October 26, 2010 6:46 AM
> To: Guzman Lugo, Fernando
> Cc: gre...@suse.de; felipe.contre...@nokia.com; 
> hiroshi.d...@nokia.com; linux-ker...@vger.kernel.org; 
> andy.shevche...@gmail.com; linux-omap@vger.kernel.org; 
> linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 1/8] staging: tidspbridge - remove 
> req_addr from proc_map
> 
> On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo 
>  wrote:
> > The device address is assigned by tidspbridge no need for 
> that parameter anymore.
> >
> > Signed-off-by: Fernando Guzman Lugo 
> 
> This would break the API with user-space, right?

Yes, user-space needs to be changed accordingly.

> 
> I think this change should be delayed, preferably after we 
> have a working tidspbridge.

The issue you were seeing must be fixed with patch 2/8, and
Having all the dependencies tidspbridge has to be working
Properly.

Regards,
Fernando.

> 
> --
> Felipe Contreras
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 8/8] staging: tidspbridge - make sync_wait_on_event interruptible

[Guzman Lugo, Fernando]

 

> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com] 
> Sent: Monday, October 25, 2010 7:59 PM
> To: Guzman Lugo, Fernando
> Cc: gre...@suse.de; felipe.contre...@nokia.com; 
> hiroshi.d...@nokia.com; linux-ker...@vger.kernel.org; 
> andy.shevche...@gmail.com; linux-omap@vger.kernel.org; 
> linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 8/8] staging: tidspbridge - make 
> sync_wait_on_event interruptible
> 
> On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo 
>  wrote:
> > So that avoid non-killable process.
> 
> It would be useful to interrupt these tasks from user-space. 
> A separate ioctl to do that would be needed.

I don't see use case where that could be needed. It is only
To avoid a nonkillable task in the case the user pass an infinite
Timeout.

If you have some test case where that ioctl would be needed
Please share it in order to find the best solution.

Regards,
Fernando.

> 
> --
> Felipe Contreras
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 0/8] staging: tidspbridge - misc fixes

[Guzman Lugo, Fernando]

 

> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@nokia.com] 
> Sent: Tuesday, October 26, 2010 9:44 AM
> To: gre...@suse.de; Guzman Lugo, Fernando
> Cc: hiroshi.d...@nokia.com; linux-ker...@vger.kernel.org; 
> andy.shevche...@gmail.com; linux-omap@vger.kernel.org; 
> linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 0/8] staging: tidspbridge - misc fixes
> 
> gre...@suse.de wrote:
> > On Mon, Oct 25, 2010 at 07:51:38PM -0500, Fernando Guzman 
> Lugo wrote:
> > > This set of patches fix some issues found in lastest tree.
> > > 
> > > Fernando Guzman Lugo (8):
> > >   staging: tidspbridge - remove req_addr from proc_map
> > >   staging: tidspbridge - add kconfig parameter for DMM size
> > >   staging: tidspbridge - change mmufault tasklet to a workqueue
> > >   staging: tidspbridge - fix timeout in dsp_gpt_wait_overflow
> > >   staging: tidspbridge - use GTP7 for DSP stack dump
> > >   staging: tidspbridge - remove disabling twl when 
> printing DSP stack
> > >   staging: tidspbridge - fix some issues after iommu patches
> > >   staging: tidspbridge - make sync_wait_on_event interruptible
> > 
> > Are any of these really applicable for .37 after .37-rc1?  
> Or can they 
> > wait for .38?

I would like to merge as soon as they can becase most of them
Some fixes, However the patch 2/7 has a dependency on an iommu
Patch and if it is no merged first the compilation will be broken.
So maybe they can be marged as soon as iommu patches are merged.

> 
> As of right now the dspbridge doesn't work, and there's a 
> mess of dependencies to get it working.
> 
>  - omap iommu: linux-omap pull request has already been sent, and
>there's no target when the omap iommu pull request will be sent...
>right Hiroshi?
>  - linux-arm: some patches are needed, and it's not clear if they'll
>make it to .37-rc1, or .37 at all.
> 
> So, no, I don't think these patches should considered as of right now.
> 
> In fact, these affect mostly iommu, and I think until those 
> other dependencies are resolved, we should revert back to a 
> previous point where the driver was actually working.

That looks like double work, having the revert now to merge after. If
Someone needs tidspbridge withouts those patche, they can go back to
A previous commit. The issues will be fixed as soon as the dependencies
Are merged.

Regards,
Fernando.

> 
> What is guideline in staging when a driver is broken like this?
> 
> Cheers.
> 
> --
> Felipe Contreras
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Pierre Tardy]

On Tue, Oct 26, 2010 at 2:10 AM, Ingo Molnar  wrote:

> How will future PCI (or other device) power saving tracepoints be called?
>
> Might be more consistent to use:
>
>  power:cpu_idle
>  power:machine_idle
>  power:device_idle
Agree with this.

FYI, I have a runtime_pm tracepoint currently cooking. Here is
preliminary patch.
Can this be a candidate for a "power:device_idle" tracepoint?

Regards,
Pierre

>From 3d5e03405f590d470ecfa59c8b9759915bf29307 Mon Sep 17 00:00:00 2001
From: Pierre Tardy 
Date: Fri, 22 Oct 2010 03:07:07 -0500
Subject: [PATCH] trace/runtime_pm: add runtime_pm trace event

based on the recent hook from Arjan for powertop statistics
we add a tracepoint in order for pytimechart to display
the runtime_pm activity over time, and versus other events.

Signed-off-by: Pierre Tardy 
---
 drivers/base/power/runtime.c |3 ++-
 include/trace/events/power.h |   35 +++
 2 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index b78c401..0f38447 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 

 static int __pm_runtime_resume(struct device *dev, bool from_wq);
 static int __pm_request_idle(struct device *dev);
@@ -159,9 +160,9 @@ void update_pm_runtime_accounting(struct device *dev)
 static void __update_runtime_status(struct device *dev, enum rpm_status status)
 {
update_pm_runtime_accounting(dev);
+   trace_runtime_pm_status(dev, status);
dev->power.runtime_status = status;
 }
-
 /**
  * __pm_runtime_suspend - Carry out run-time suspend of given device.
  * @dev: Device to suspend.
diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index 286784d..dd57c29 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -6,6 +6,7 @@

 #include 
 #include 
+#include 

 #ifndef _TRACE_POWER_ENUM_
 #define _TRACE_POWER_ENUM_
@@ -75,6 +76,40 @@ TRACE_EVENT(power_end,

 );

+#ifdef CONFIG_PM_RUNTIME
+#define rpm_status_name(status) { RPM_##status, #status }
+#define show_rpm_status_name(val)  \
+   __print_symbolic(val,   \
+   rpm_status_name(SUSPENDED), \
+   rpm_status_name(SUSPENDING),\
+   rpm_status_name(RESUMING),  \
+   rpm_status_name(ACTIVE) \
+   )
+TRACE_EVENT(runtime_pm_status,
+
+   TP_PROTO(struct device *dev, int new_status),
+
+   TP_ARGS(dev, new_status),
+
+   TP_STRUCT__entry(
+   __string(devname,dev_name(dev))
+   __string(drivername,dev_driver_string(dev))
+   __field(u32, prev_status)
+   __field(u32, status)
+   ),
+
+   TP_fast_assign(
+   __assign_str(devname, dev_name(dev));
+   __assign_str(drivername, dev_driver_string(dev));
+   __entry->prev_status = (u32)dev->power.runtime_status;
+   __entry->status = (u32)new_status;
+   ),
+
+   TP_printk("driver=%s dev=%s prev_status=%s status=%s",
__get_str(drivername),__get_str(devname),
+ show_rpm_status_name(__entry->prev_status),
show_rpm_status_name(__entry->status))
+);
+#endif /* CONFIG_PM_RUNTIME */
+
 /*
  * The clock events are used for clock enable/disable and for
  *  clock rate change
-- 
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/8] staging: tidspbridge - misc fixes

[Omar Ramirez Luna]

On Tue, Oct 26, 2010 at 9:43 AM, Felipe Contreras
 wrote:
> gre...@suse.de wrote:
>> On Mon, Oct 25, 2010 at 07:51:38PM -0500, Fernando Guzman Lugo wrote:
>> > This set of patches fix some issues found in lastest tree.
>> >
>> > Fernando Guzman Lugo (8):
>> >   staging: tidspbridge - remove req_addr from proc_map
>> >   staging: tidspbridge - add kconfig parameter for DMM size
>> >   staging: tidspbridge - change mmufault tasklet to a workqueue
>> >   staging: tidspbridge - fix timeout in dsp_gpt_wait_overflow
>> >   staging: tidspbridge - use GTP7 for DSP stack dump
>> >   staging: tidspbridge - remove disabling twl when printing DSP stack
>> >   staging: tidspbridge - fix some issues after iommu patches
>> >   staging: tidspbridge - make sync_wait_on_event interruptible
>>
>> Are any of these really applicable for .37 after .37-rc1?  Or can they
>> wait for .38?
>
> As of right now the dspbridge doesn't work, and there's a mess of
> dependencies to get it working.

Just to note that there will be one more dependency for SCM changes[1]
that will fix compilation, as these need to climb from linux-omap (if
accepted) before applying tidspbridge chunks.

Regards,
Omar

---
[1] http://marc.info/?l=linux-omap&m=128779652429922&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 01/13] OMAP: DMA: Replace read/write macros with functions

[Nishanth Menon]

G, Manjunath Kondaiah had written, on 10/26/2010 08:25 AM, the following:
[...]


diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index f5c5b8d..77241e2 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -40,6 +40,147 @@

 #undef DEBUG

+enum {
+   GCR1 = 0,   GSCR,   GRST,   HW_ID,
+   PCH2_ID,PCH0_ID,PCH1_ID,PCHG_ID,
+   PCHD_ID,CAPS1_0_U,  CAPS1_0_L,  CAPS1_1_U,
+   CAPS1_1_L,  CAPS1_2,CAPS1_3,CAPS1_4,
+   PCH2_SR,PCH0_SR,PCH1_SR,PCHD_SR,

[...]


+};
+
+static u16 reg_map_omap1[] = {
+   [GCR1]  = 0x400,
+   [GSCR]  = 0x404,
+   [GRST]  = 0x408,
+   [HW_ID] = 0x442,
+   [PCH2_ID]   = 0x444,
+   [PCH0_ID]   = 0x446,
+   [PCH1_ID]   = 0x448,
+   [PCHG_ID]   = 0x44a,
+   [PCHD_ID]   = 0x44c,

[...]

+   [LCH_CTRL]  = 0x2a,
+};
+
+enum {
+   REVISION = 0,   GCR2,   IRQSTATUS_L0,   IRQSTATUS_L1,
+   IRQSTATUS_L2,   IRQSTATUS_L3,   IRQENABLE_L0,   IRQENABLE_L1,

[...]

+
+   /* OMAP4 specific registers */
+   CDP,CNDP,   CCDN,
+
+   OMAP2_CH_COMMON_END,
+};
+
+static u16 reg_map_omap2[] = {
+   [REVISION]  = 0x00,
+   [GCR2]  = 0x78,
+   [IRQSTATUS_L0]  = 0x08,
+   [IRQSTATUS_L1]  = 0x0c,

[..]

+   /* OMAP4 specific registers */
+   [CDP]   = 0xd0,
+   [CNDP]  = 0xd4,
+   [CCDN]  = 0xd8,
+};
+

dumb question: any reason why a struct wont do?
struct reg_map_omap2 {
u16 revision;
...
...
}

[..]


-#define dma_read(reg)  \
-({ \
-   u32 __val;  \
-   if (cpu_class_is_omap1())   \
-   __val = __raw_readw(omap_dma_base + OMAP1_DMA_##reg);   \
-   else\
-   __val = __raw_readl(omap_dma_base + OMAP_DMA4_##reg);   \
-   __val;  \
-})
-
-#define dma_write(val, reg)\
-({ \
-   if (cpu_class_is_omap1())   \
-   __raw_writew((u16)(val), omap_dma_base + OMAP1_DMA_##reg); \
-   else\
-   __raw_writel((val), omap_dma_base + OMAP_DMA4_##reg);   \
-})
+static inline void dma_write(u32 val, int reg, int lch)
+{
+   if (cpu_class_is_omap1()) {
+   if (reg > OMAP1_CH_COMMON_START)
+   __raw_writew(val, dma_base +
+   (reg_map_omap1[reg] + 0x40 * lch));
+   else
+   __raw_writew(val, dma_base + reg_map_omap1[reg]);
+   } else {
+   if (reg > OMAP2_CH_COMMON_START)
+   __raw_writel(val, dma_base +
+   (reg_map_omap2[reg] + 0x60 * lch));
+   else
+   __raw_writel(val, dma_base + reg_map_omap2[reg]);
+   }
+}
+
+static inline u32 dma_read(int reg, int lch)
+{
+   u32 val;
+
+   if (cpu_class_is_omap1()) {
+   if (reg > OMAP1_CH_COMMON_START)
+   val = __raw_readw(dma_base +
+   (reg_map_omap1[reg] + 0x40 * lch));
+   else
+   val = __raw_readw(dma_base + reg_map_omap1[reg]);
+   } else {
+   if (reg > OMAP2_CH_COMMON_START)
+   val = __raw_readl(dma_base +
+   (reg_map_omap2[reg] + 0x60 * lch));
+   else
+   val = __raw_readl(dma_base + reg_map_omap2[reg]);
+   }
+   return val;
+}
What is the benefit of using inline function here? would'nt we increase 
code size? cant we use a function pointer initialized to class1 or rest? 
Quote from CodingStyle (15):

"A reasonable rule of thumb is to not put inline at functions that have more
than 3 lines of code in them. An exception to this rule are the cases where
a parameter is known to be a compiletime constant, and as a result of this
constantness you *know* the compiler will be able to optimize most of your
function away at compile time. For a good example of this later case, see
the kmalloc() inline function.
"
is the expectation that cpu_class_is_omap1 compile time constant hence 
the actual compiled in code is smaller -candidate for inline?




 #ifdef CONFIG_ARCH_OMAP15XX
 /* Returns 1 if the DMA module is in OMAP1510-compatible mode, 0 otherwise */
@@ -209,11 +

Re: [PATCH 0/8] staging: tidspbridge - misc fixes

[Felipe Contreras]

gre...@suse.de wrote:
> On Mon, Oct 25, 2010 at 07:51:38PM -0500, Fernando Guzman Lugo wrote:
> > This set of patches fix some issues found in lastest tree.
> > 
> > Fernando Guzman Lugo (8):
> >   staging: tidspbridge - remove req_addr from proc_map
> >   staging: tidspbridge - add kconfig parameter for DMM size
> >   staging: tidspbridge - change mmufault tasklet to a workqueue
> >   staging: tidspbridge - fix timeout in dsp_gpt_wait_overflow
> >   staging: tidspbridge - use GTP7 for DSP stack dump
> >   staging: tidspbridge - remove disabling twl when printing DSP stack
> >   staging: tidspbridge - fix some issues after iommu patches
> >   staging: tidspbridge - make sync_wait_on_event interruptible
> 
> Are any of these really applicable for .37 after .37-rc1?  Or can they
> wait for .38?

As of right now the dspbridge doesn't work, and there's a mess of
dependencies to get it working.

 - omap iommu: linux-omap pull request has already been sent, and
   there's no target when the omap iommu pull request will be sent...
   right Hiroshi?
 - linux-arm: some patches are needed, and it's not clear if they'll
   make it to .37-rc1, or .37 at all.

So, no, I don't think these patches should considered as of right now.

In fact, these affect mostly iommu, and I think until those other
dependencies are resolved, we should revert back to a previous point
where the driver was actually working.

What is guideline in staging when a driver is broken like this?

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] tidspbridge: convert OMAP3430 adaptation layer to use new SCM DSP boot control fns

[Omar Ramirez Luna]

On Tue, Oct 26, 2010 at 12:43 AM, Paul Walmsley  wrote:
>>  arch/arm/mach-omap2/dsp.c                     |    4 
>>  arch/arm/plat-omap/include/plat/dsp.h         |    4 
>>  drivers/staging/tidspbridge/core/tiomap3430.c |   13 ++---
>
> Could you please split the tiomap3430.c change into a separate patch?
> That should go in via the staging tree once this series is accepted.

No problem.

Regards,
Omar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Thomas Renninger]

On Tuesday 26 October 2010 15:17:43 Thomas Renninger wrote:
> On Tuesday 26 October 2010 13:54:22 Ingo Molnar wrote:
> > 
> > * Thomas Renninger  wrote:
...
> If cpuidle is not registered, the events you get are arch specific.
> I mean they are arch specific anyway, but with cpuidle you can
> build up an arch independent userspace framework nicely by looking
> up name/desc/power/... of an cpu_idle event in cpuidle sysfs as
> described above.
About cpuidle and cpu_idle events:
There is some oddness that:
arch specific code which registers for cpuidle has to
throw the cpu_idle enter sleep state X event
and the generic cpuidle framework triggers the "exit" event.

So as there are only cpu_idle events in drivers/idle/intel_idle.c,
but not in drivers/acpi/processor_idle.c, I expect that processor.ko
idle driver is broken and only exit states are sent.
Ideally all cpuidle events should be thrown in cpuidle.c like this:

trace_processor_idle(target_state, smp_processor_id());
dev->last_residency = target_state->enter(dev, target_state);   
  
trace_processor_idle(PWR_EVENT_EXIT, smp_processor_id());

My patches do not touch this behavior. If, it was broken before.
I'll look at it separately.

  Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 12/13] OMAP2+: DMA: descriptor autoloading feature

[G, Manjunath Kondaiah]

Add sDMA driver support for descriptor autoloading feature.
Descriptor autoloading is OMAP sDMA v5 hardware capability that can be
exploited for scatter gather scenarios, currently available in OMAP3630
and OMAP4430.

The feature works as described below.
1. A sDMA channel is programmed to be in 'linked list' mode.
2) The client (sDMA user) provides a list of descriptors in a linked
list format
3) Each of the 'descriptor' (element in the linked list) contains an
updated set of DMA configuration register values.
4) Client starts DMA transfer.
5) sDMA controller loads the first element to its register configuration
memory and executes the transfer.
6) After completion, loads the next element (in linked list) to
configuration memory and executes the transfer, without MCU
intervention.
7) Interrupt is generated after all transfers are completed; this can be
configured to be done differently.

Configurations and additional features
1) Fast mode & non-fast mode
Fast mode/non-fast decides on how the first transfer begins. In non-fast
mode, the first element in the linked list is loaded only after
completing the
transfer according to the configurations already in the sDMA channel
registers.
In fast mode, the loading of the first element precedes the transfer.

2) Pause / resume of transfers
A transfer can be paused after a descriptor set has been loaded,
provided the pause bit' is set in the linked list element.
An ongoing transfer cannot be paused. If the 'pause bit' is set,
transfer is not started after loading the register set from memory.
Such a transfer can be resumed later.

3) Descriptor types
Three possible configurations of descriptors (initialized as linked list
elements) are possible.
Type 1 provides the maximum flexibility, which contains most register
definitions of a DMA logical channel.
Fewer options are present in type 2.
Type 3 can just modify source/destinations address of transfers. In all
transfers, unmodified registers settings are maintained for the next
transfer.

Patch provides options / API for
1) Setting up a descriptor loading for DMA channel for sg type transfers
2) configuration with linked list elements
3) Starting / pause and resume of the said transfers, query state
4) Clearing the sglist mode

Signed-off-by: Venkatraman S 
Signed-off-by: G, Manjunath Kondaiah 
Cc: Benoit Cousson 
Cc: Kevin Hilman 
Cc: Santosh Shilimkar 
---
 arch/arm/mach-omap2/dma.c |  257 +
 arch/arm/plat-omap/dma.c  |1 +
 arch/arm/plat-omap/include/plat/dma.h |  111 ++-
 3 files changed, 368 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index 6df4835..397e90e 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -41,6 +41,7 @@
 
 static u32 errata;
 static int dma_chan_count;
+static int dma_caps0_status;
 
 static struct omap_dma_dev_attr *d;
 static struct dma_link_info *dma_linked_lch;
@@ -240,6 +241,76 @@ static inline void omap2_disable_lnk(int lch)
dma_chan[lch].flags &= ~OMAP_DMA_ACTIVE;
 }
 
+static inline void omap_dma_list_set_ntype(struct omap_dma_sglist_node *node,
+  int value)
+{
+   node->num_of_elem |= ((value) << 29);
+}
+
+static void omap_set_dma_sglist_pausebit(
+   struct omap_dma_list_config_params *lcfg, int nelem, int set)
+{
+   struct omap_dma_sglist_node *sgn = lcfg->sghead;
+
+   if (nelem > 0 && nelem < lcfg->num_elem) {
+   lcfg->pausenode = nelem;
+   sgn += nelem;
+
+   if (set)
+   sgn->next_desc_add_ptr |= DMA_LIST_DESC_PAUSE;
+   else
+   sgn->next_desc_add_ptr &= ~(DMA_LIST_DESC_PAUSE);
+   }
+}
+
+static int dma_sglist_set_phy_params(struct omap_dma_sglist_node *sghead,
+   dma_addr_t phyaddr, int nelem)
+{
+   struct omap_dma_sglist_node *sgcurr, *sgprev;
+   dma_addr_t elem_paddr = phyaddr;
+
+   for (sgprev = sghead;
+   sgprev < sghead + nelem;
+   sgprev++) {
+
+   sgcurr = sgprev + 1;
+   sgprev->next = sgcurr;
+   elem_paddr += (int)sizeof(*sgcurr);
+   sgprev->next_desc_add_ptr = elem_paddr;
+
+   switch (sgcurr->desc_type) {
+   case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE1:
+   omap_dma_list_set_ntype(sgprev, 1);
+   break;
+
+   case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE2a:
+   /* intentional no break */
+   case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE2b:
+   omap_dma_list_set_ntype(sgprev, 2);
+   break;
+
+   case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE3a:
+   /* intentional no break */
+   case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE3b:
+   omap_dma_list_set_ntype(sgprev, 3);
+   bre

[PATCH v3 13/13] OMAP: PM: DMA: Enable runtime pm

[G, Manjunath Kondaiah]

Enable runtime pm and use pm_runtime_get and pm_runtime_put
for OMAP DMA driver.

Signed-off-by: G, Manjunath Kondaiah 
Cc: Benoit Cousson 
Cc: Kevin Hilman 
Cc: Santosh Shilimkar 
---
 arch/arm/plat-omap/dma.c |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 41b14b0..feac7ee 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -367,6 +368,8 @@ int omap_request_dma(int dev_id, const char *dev_name,
chan = dma_chan + free_ch;
chan->dev_id = dev_id;
 
+   pm_runtime_get(&pd->dev);
+
if (d->dev_caps & IS_WORD_16)
p->clear_lch_regs(free_ch);
else
@@ -452,6 +455,7 @@ void omap_free_dma(int lch)
omap_clear_dma(lch);
p->clear_dma_sglist_mode(lch);
}
+   pm_runtime_put(&pd->dev);
spin_lock_irqsave(&dma_chan_lock, flags);
dma_chan[lch].dev_id = -1;
dma_chan[lch].next_lch = -1;
@@ -819,6 +823,11 @@ static int __devinit omap_system_dma_probe(struct 
platform_device *pdev)
dma_chan_count  = d->chan_count;
dma_chan= d->chan;
 
+   /* Enable run time PM */
+   pm_runtime_enable(&pd->dev);
+
+   /* Accessing hw registers, get clock */
+   pm_runtime_get(&pd->dev);
for (ch = 0; ch < dma_chan_count; ch++) {
unsigned long flags;
omap_clear_dma(ch);
@@ -846,6 +855,10 @@ static int __devinit omap_system_dma_probe(struct 
platform_device *pdev)
dma_chan[0].dev_id = 0;
dma_chan[1].dev_id = 1;
}
+
+   if (!omap_dma_reserve_channels)
+   pm_runtime_put(&pd->dev);
+
return 0;
 
 exit_release_region:
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 08/13] OMAP1: DMA: Introduce DMA driver as platform device

[G, Manjunath Kondaiah]

Register OMAP1 DMA driver as platform device and add support
for registering through platform device layer using resource
structures.

Signed-off-by: G, Manjunath Kondaiah 
Cc: Benoit Cousson 
Cc: Kevin Hilman 
Cc: Santosh Shilimkar 
---
 arch/arm/mach-omap1/dma.c  |  182 
 arch/arm/mach-omap1/include/mach/dma.h |   29 +
 2 files changed, 211 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap1/dma.c
 create mode 100644 arch/arm/mach-omap1/include/mach/dma.h

diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
new file mode 100644
index 000..e756069
--- /dev/null
+++ b/arch/arm/mach-omap1/dma.c
@@ -0,0 +1,182 @@
+/*
+ * dma.c - OMAP1/OMAP7xx-specific DMA code
+ *
+ * Copyright (C) 2003 - 2008 Nokia Corporation
+ * Author: Juha Yrjölä 
+ * DMA channel linking for 1610 by Samuel Ortiz 
+ * Graphics DMA and LCD DMA graphics tranformations
+ * by Imre Deak 
+ * OMAP2/3 support Copyright (C) 2004-2007 Texas Instruments, Inc.
+ * Some functions based on earlier dma-omap.c Copyright (C) 2001 RidgeRun, Inc.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Converted DMA library into platform driver
+ *   - G, Manjunath Kondaiah 
+ *
+ * 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
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define OMAP1_DMA_BASE (0xfffed800)
+
+static struct resource res[] __initdata = {
+   [0] = {
+   .start  = OMAP1_DMA_BASE,
+   .end= OMAP1_DMA_BASE + SZ_2K - 1,
+   .flags  = IORESOURCE_MEM,
+   },
+   [1] = {
+   .name   = "0",
+   .start  = INT_DMA_CH0_6,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [2] = {
+   .name   = "1",
+   .start  = INT_DMA_CH1_7,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [3] = {
+   .name   = "2",
+   .start  = INT_DMA_CH2_8,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [4] = {
+   .name   = "3",
+   .start  = INT_DMA_CH3,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [5] = {
+   .name   = "4",
+   .start  = INT_DMA_CH4,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [6] = {
+   .name   = "5",
+   .start  = INT_DMA_CH5,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [7] = {
+   .name   = "6",
+   .start  = INT_DMA_LCD,
+   .flags  = IORESOURCE_IRQ,
+   },
+   /* irq's for omap16xx and omap7xx */
+   [8] = {
+   .name   = "7",
+   .start  = 53 + IH2_BASE,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [9] = {
+   .name   = "8",
+   .start  = 54 + IH2_BASE,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [10] = {
+   .name  = "9",
+   .start = 55 + IH2_BASE,
+   .flags = IORESOURCE_IRQ,
+   },
+   [11] = {
+   .name  = "10",
+   .start = 56 + IH2_BASE,
+   .flags = IORESOURCE_IRQ,
+   },
+   [12] = {
+   .name  = "11",
+   .start = 57 + IH2_BASE,
+   .flags = IORESOURCE_IRQ,
+   },
+   [13] = {
+   .name  = "12",
+   .start = 58 + IH2_BASE,
+   .flags = IORESOURCE_IRQ,
+   },
+   [14] = {
+   .name  = "13",
+   .start = 59 + IH2_BASE,
+   .flags = IORESOURCE_IRQ,
+   },
+   [15] = {
+   .name  = "14",
+   .start = 60 + IH2_BASE,
+   .flags = IORESOURCE_IRQ,
+   },
+   [16] = {
+   .name  = "15",
+   .start = 61 + IH2_BASE,
+   .flags = IORESOURCE_IRQ,
+   },
+   [17] = {
+   .name  = "16",
+   .start = 62 + IH2_BASE,
+   .flags = IORESOURCE_IRQ,
+   },
+};
+
+static int __init omap1_system_dma_init(void)
+{
+   struct omap_system_dma_plat_info*p;
+   struct platform_device  *pdev;
+   int ret;
+
+   pdev = platform_device_alloc("omap_dma_system", 0);
+   if (!pdev) {
+   pr_err("%s: Unable to device alloc for dma\n",
+   __func__);
+   return -ENOMEM;
+   }
+
+   ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
+   if (ret) {
+   pr_err("%s: Unable to add resources for %s%d\n",
+   __func__, pdev->name, pdev->id);
+   goto exit_device_del;
+   }
+
+   p = kzalloc(sizeof(struct o

[PATCH v3 09/13] OMAP2+: DMA: hwmod: Device registration

[G, Manjunath Kondaiah]

Prepare omap2+ dma driver to use hwmod infrastructure
so that DMA driver can register as platform device.

Signed-off-by: G, Manjunath Kondaiah 
Cc: Benoit Cousson 
Cc: Kevin Hilman 
Cc: Santosh Shilimkar 
---
 arch/arm/mach-omap2/dma.c  |   86 
 arch/arm/mach-omap2/include/mach/dma.h |   32 
 2 files changed, 118 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/dma.c
 create mode 100644 arch/arm/mach-omap2/include/mach/dma.h

diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
new file mode 100644
index 000..30b20cd
--- /dev/null
+++ b/arch/arm/mach-omap2/dma.c
@@ -0,0 +1,86 @@
+/*
+ * dma.c - OMAP2 specific DMA code
+ *
+ * Copyright (C) 2003 - 2008 Nokia Corporation
+ * Author: Juha Yrjölä 
+ * DMA channel linking for 1610 by Samuel Ortiz 
+ * Graphics DMA and LCD DMA graphics tranformations
+ * by Imre Deak 
+ * OMAP2/3 support Copyright (C) 2004-2007 Texas Instruments, Inc.
+ * Some functions based on earlier dma-omap.c Copyright (C) 2001 RidgeRun, Inc.
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Added OMAP4 support - Santosh Shilimkar 
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Converted DMA library into platform driver
+ * - G, Manjunath Kondaiah 
+ *
+ * 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
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+static struct omap_device_pm_latency omap2_dma_latency[] = {
+   {
+   .deactivate_func = omap_device_idle_hwmods,
+   .activate_func   = omap_device_enable_hwmods,
+   .flags   = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+   },
+};
+
+/* One time initializations */
+static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void 
*unused)
+{
+   struct omap_device  *od;
+   struct omap_system_dma_plat_info*p;
+   char*name = "omap_system_dma";
+
+   p = kzalloc(sizeof(struct omap_system_dma_plat_info), GFP_KERNEL);
+   if (!p) {
+   pr_err("%s: Unable to allocate pdata for %s:%s\n",
+   __func__, name, oh->name);
+   return -ENOMEM;
+   }
+   od = omap_device_build(name, 0, oh, p, sizeof(*p),
+   omap2_dma_latency, ARRAY_SIZE(omap2_dma_latency), 0);
+
+   if (IS_ERR(od)) {
+   pr_err("%s: Cant build omap_device for %s:%s.\n",
+   __func__, name, oh->name);
+   kfree(p);
+   return IS_ERR(od);
+   }
+   kfree(p);
+
+   return 0;
+}
+
+static int __init omap2_system_dma_init(void)
+{
+   int ret;
+
+   ret = omap_hwmod_for_each_by_class("dma",
+   omap2_system_dma_init_dev, NULL);
+
+   return ret;
+}
+arch_initcall(omap2_system_dma_init);
diff --git a/arch/arm/mach-omap2/include/mach/dma.h 
b/arch/arm/mach-omap2/include/mach/dma.h
new file mode 100644
index 000..d0a7d5b
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/dma.h
@@ -0,0 +1,32 @@
+/*
+ *  OMAP DMA controller register offsets.
+ *
+ *  Copyright (C) 2003 Nokia Corporation
+ *  Author: Juha Yrjölä 
+ *
+ *  Copyright (C) 2009 Texas Instruments
+ *  Added OMAP4 support - Santosh Shilimkar 
+ *
+ *  Copyright (C) 2010 Texas Instruments
+ *  Converted DMA library into platform driver
+ *  - G, Manjunath Kondaiah 
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __ASM_ARCH_OMAP2_DMA_H
+#define __ASM_ARCH_OMAP2_DMA_H
+
+#endif /* __ASM_ARCH_OMAP2_DMA_H */
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 10/13] OMAP: DMA: Convert DMA library into DMA platform Driver

[G, Manjunath Kondaiah]

Convert DMA library into DMA platform driver and make use
of platform data provided by HWMOD data base for OMAP2PLUS onwards.
For OMAP1 processors, the DMA driver in mach-omap uses resource
structures for getting platform data.

Signed-off-by: G, Manjunath Kondaiah 
Cc: Benoit Cousson 
Cc: Kevin Hilman 
Cc: Santosh Shilimkar 
---
 arch/arm/mach-omap1/Makefile   |2 +-
 arch/arm/mach-omap1/dma.c  |  180 ++-
 arch/arm/mach-omap2/Makefile   |2 +-
 arch/arm/mach-omap2/dma.c  |  209 +-
 arch/arm/mach-omap2/include/mach/dma.h |3 +
 arch/arm/plat-omap/dma.c   |  321 +++-
 arch/arm/plat-omap/include/plat/dma.h  |   50 --
 7 files changed, 538 insertions(+), 229 deletions(-)

diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 9a304d8..b7dfc54 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -3,7 +3,7 @@
 #
 
 # Common support
-obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o
+obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o dma.o
 obj-y += clock.o clock_data.o opp_data.o
 
 obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index e756069..38a7294 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -35,6 +35,81 @@
 #include 
 
 #define OMAP1_DMA_BASE (0xfffed800)
+#define OMAP1_LOGICAL_DMA_CH_COUNT 17
+
+static u32 errata;
+static u32 enable_1510_mode;
+
+enum {
+   GCR1 = 0,   GSCR,   GRST,   HW_ID,
+   PCH2_ID,PCH0_ID,PCH1_ID,PCHG_ID,
+   PCHD_ID,CAPS_0_U,   CAPS_0_L,   CAPS_1_U,
+   CAPS_1_L,   CAPS_2, CAPS_3, CAPS_4,
+   PCH2_SR,PCH0_SR,PCH1_SR,PCHD_SR,
+
+   CH_COMMON_START,
+
+   /* Common Registers */
+   CSDP1,  CCR1,   CICR1,  CSR1,
+   CEN1,   CFN1,   CSFI1,  CSEI1,
+   CPC,CSAC1,  CDAC1,  CDEI1,
+   CDFI1,  CLNK_CTRL1,
+
+   /* Channel specific register offsets */
+   CSSA_L, CSSA_U, CDSA_L, CDSA_U,
+   COLOR_L,COLOR_U,CCR1_2, LCH_CTRL,
+
+   CH_COMMON_END,
+};
+
+static u16 reg_map[] = {
+   [GCR1]  = 0x400,
+   [GSCR]  = 0x404,
+   [GRST]  = 0x408,
+   [HW_ID] = 0x442,
+   [PCH2_ID]   = 0x444,
+   [PCH0_ID]   = 0x446,
+   [PCH1_ID]   = 0x448,
+   [PCHG_ID]   = 0x44a,
+   [PCHD_ID]   = 0x44c,
+   [CAPS_0_U]  = 0x44e,
+   [CAPS_0_L]  = 0x450,
+   [CAPS_1_U]  = 0x452,
+   [CAPS_1_L]  = 0x454,
+   [CAPS_2]= 0x456,
+   [CAPS_3]= 0x458,
+   [CAPS_4]= 0x45a,
+   [PCH2_SR]   = 0x460,
+   [PCH0_SR]   = 0x480,
+   [PCH1_SR]   = 0x482,
+   [PCHD_SR]   = 0x4c0,
+
+   /* Common Registers */
+   [CSDP1] = 0x00,
+   [CCR1]  = 0x02,
+   [CICR1] = 0x04,
+   [CSR1]  = 0x06,
+   [CEN1]  = 0x10,
+   [CFN1]  = 0x12,
+   [CSFI1] = 0x14,
+   [CSEI1] = 0x16,
+   [CPC]   = 0x18, /* 15xx only */
+   [CSAC1] = 0x18,
+   [CDAC1] = 0x1a,
+   [CDEI1] = 0x1c,
+   [CDFI1] = 0x1e,
+   [CLNK_CTRL1]= 0x28,
+
+   /* Channel specific register offsets */
+   [CSSA_L]= 0x08,
+   [CSSA_U]= 0x0a,
+   [CDSA_L]= 0x0c,
+   [CDSA_U]= 0x0e,
+   [COLOR_L]   = 0x20,
+   [COLOR_U]   = 0x22,
+   [CCR1_2]= 0x24,
+   [LCH_CTRL]  = 0x2a,
+};
 
 static struct resource res[] __initdata = {
[0] = {
@@ -130,9 +205,64 @@ static struct resource res[] __initdata = {
},
 };
 
+static void __iomem *dma_base;
+static inline void dma_write(u16 val, int reg, int lch)
+{
+   if (reg > CH_COMMON_START)
+   __raw_writew(val, dma_base + (reg_map[reg] + 0x40 * lch));
+   else
+   __raw_writew(val, dma_base + reg_map[reg]);
+}
+
+static inline u16 dma_read(int reg, int lch)
+{
+   if (reg > CH_COMMON_START)
+   return __raw_readw(dma_base + (reg_map[reg] + 0x40 * lch));
+   else
+   return __raw_readw(dma_base + reg_map[reg]);
+}
+
+static void omap1_show_dma_caps(void)
+{
+   if (enable_1510_mode) {
+   printk(KERN_INFO "DMA support for OMAP15xx initialized\n");
+   } else {
+   u16 w;
+   printk(KERN_INFO "OMAP DMA hardware version %d\n",
+  dma_read(HW_ID, 0));
+   printk(KERN_INFO "DMA capabilities: %08x:%08x:%04x:%04x:%04x\n",
+  (dma_read(CAPS_0_U, 0) << 16) 

[PATCH v3 06/13] OMAP3: DMA: hwmod: add system DMA

[G, Manjunath Kondaiah]

Add OMAP3 DMA hwmod structures.

Signed-off-by: G, Manjunath Kondaiah 
Cc: Benoit Cousson 
Cc: Kevin Hilman 
Cc: Santosh Shilimkar 
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   93 
 1 files changed, 93 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ed6bf4a..4a5231c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -45,6 +45,7 @@ static struct omap_hwmod omap3xxx_wd_timer2_hwmod;
 static struct omap_hwmod omap3xxx_i2c1_hwmod;
 static struct omap_hwmod omap3xxx_i2c2_hwmod;
 static struct omap_hwmod omap3xxx_i2c3_hwmod;
+static struct omap_hwmod omap3xxx_dma_system_hwmod;
 
 /* L3 -> L4_CORE interface */
 static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -736,6 +737,97 @@ static struct omap_hwmod omap3xxx_i2c3_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
 };
 
+/* dma_system -> L3 */
+static struct omap_hwmod_ocp_if omap3xxx_dma_system__l3 = {
+   .master = &omap3xxx_dma_system_hwmod,
+   .slave  = &omap3xxx_l3_main_hwmod,
+   .clk= "core_l3_ick",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+   .dev_caps  = DMA_LINKED_LCH | GLOBAL_PRIORITY |
+   IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+   .lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT,
+};
+
+static struct omap_hwmod_class_sysconfig omap3xxx_dma_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x002c,
+   .syss_offs  = 0x0028,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+   .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_dma_hwmod_class = {
+   .name = "dma",
+   .sysc = &omap3xxx_dma_sysc,
+};
+
+/* dma_system */
+static struct omap_hwmod_irq_info omap3xxx_dma_system_irqs[] = {
+   { .name = "0", .irq = INT_24XX_SDMA_IRQ0 },
+   { .name = "1", .irq = INT_24XX_SDMA_IRQ1 },
+   { .name = "2", .irq = INT_24XX_SDMA_IRQ2 },
+   { .name = "3", .irq = INT_24XX_SDMA_IRQ3 },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_dma_system_addrs[] = {
+   {
+   .pa_start   = 0x48056000,
+   .pa_end = 0x4a0560ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dma_system_masters[] = {
+   &omap3xxx_dma_system__l3,
+};
+
+/* l4_cfg -> dma_system */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dma_system = {
+   .master = &omap3xxx_l4_core_hwmod,
+   .slave  = &omap3xxx_dma_system_hwmod,
+   .clk= "core_l4_ick",
+   .addr   = omap3xxx_dma_system_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_dma_system_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dma_system_slaves[] = {
+   &omap3xxx_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap3xxx_dma_system_hwmod = {
+   .name   = "dma",
+   .class  = &omap3xxx_dma_hwmod_class,
+   .mpu_irqs   = omap3xxx_dma_system_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap3xxx_dma_system_irqs),
+   .main_clk   = "core_l3_ick",
+   .prcm = {
+   .omap2 = {
+   .prcm_reg_id= 1,
+   .module_bit = OMAP3430_ST_SDMA_SHIFT,
+   .idlest_reg_id  = 1,
+   .idlest_idle_bit= OMAP3430_ST_SDMA_SHIFT,
+   },
+   },
+   .slaves = omap3xxx_dma_system_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap3xxx_dma_system_slaves),
+   .masters= omap3xxx_dma_system_masters,
+   .masters_cnt= ARRAY_SIZE(omap3xxx_dma_system_masters),
+   .dev_attr   = &dma_dev_attr,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+   .flags = HWMOD_SET_DEFAULT_CLOCKACT,
+};
+
 static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_l3_main_hwmod,
&omap3xxx_l4_core_hwmod,
@@ -751,6 +843,7 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_i2c1_hwmod,
&omap3xxx_i2c2_hwmod,
&omap3xxx_i2c3_hwmod,
+   &omap3xxx_dma_system_hwmod,
NULL,
 };
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More major

[PATCH v3 07/13] OMAP4: DMA: hwmod: add system DMA

[G, Manjunath Kondaiah]

From: Benoit Cousson 

Add OMAP4 DMA hwmod structures.

Signed-off-by: G, Manjunath Kondaiah 
Signed-off-by: Benoit Cousson 
Cc: Kevin Hilman 
Cc: Santosh Shilimkar 
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   99 
 1 files changed, 99 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 0d5c6eb..f749f0d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,7 @@
 
 #include 
 #include 
+#include 
 
 #include "omap_hwmod_common_data.h"
 
@@ -35,6 +36,7 @@
 #define OMAP44XX_DMA_REQ_START  1
 
 /* Backward references (IPs with Bus Master capability) */
+static struct omap_hwmod omap44xx_dma_system_hwmod;
 static struct omap_hwmod omap44xx_dmm_hwmod;
 static struct omap_hwmod omap44xx_emif_fw_hwmod;
 static struct omap_hwmod omap44xx_l3_instr_hwmod;
@@ -215,6 +217,14 @@ static struct omap_hwmod_ocp_if 
omap44xx_l3_main_1__l3_main_2 = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* dma_system -> l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_dma_system__l3_main_2 = {
+   .master = &omap44xx_dma_system_hwmod,
+   .slave  = &omap44xx_l3_main_2_hwmod,
+   .clk= "l3_div_ck",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l4_cfg -> l3_main_2 */
 static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2 = {
.master = &omap44xx_l4_cfg_hwmod,
@@ -226,6 +236,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2 
= {
 /* l3_main_2 slave ports */
 static struct omap_hwmod_ocp_if *omap44xx_l3_main_2_slaves[] = {
&omap44xx_l3_main_1__l3_main_2,
+   &omap44xx_dma_system__l3_main_2,
&omap44xx_l4_cfg__l3_main_2,
 };
 
@@ -1043,6 +1054,92 @@ static struct omap_hwmod omap44xx_uart4_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
 };
 
+/*
+ * 'dma' class
+ * dma controller for data exchange between memory to memory (i.e. internal or
+ * external memory) and gp peripherals to memory or memory to gp peripherals
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_dma_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x002c,
+   .syss_offs  = 0x0028,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+   .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_dma_hwmod_class = {
+   .name = "dma",
+   .sysc = &omap44xx_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+   .dev_caps  = DMA_LINKED_LCH | GLOBAL_PRIORITY |
+   IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+   .lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT,
+};
+
+/* dma_system */
+static struct omap_hwmod_irq_info omap44xx_dma_system_irqs[] = {
+   { .name = "0", .irq = 12 + OMAP44XX_IRQ_GIC_START },
+   { .name = "1", .irq = 13 + OMAP44XX_IRQ_GIC_START },
+   { .name = "2", .irq = 14 + OMAP44XX_IRQ_GIC_START },
+   { .name = "3", .irq = 15 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_dma_system_addrs[] = {
+   {
+   .pa_start   = 0x4a056000,
+   .pa_end = 0x4a0560ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap44xx_dma_system_masters[] = {
+   &omap44xx_dma_system__l3_main_2,
+};
+
+/* l4_cfg -> dma_system */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__dma_system = {
+   .master = &omap44xx_l4_cfg_hwmod,
+   .slave  = &omap44xx_dma_system_hwmod,
+   .clk= "l4_div_ck",
+   .addr   = omap44xx_dma_system_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap44xx_dma_system_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_dma_system_slaves[] = {
+   &omap44xx_l4_cfg__dma_system,
+};
+
+static struct omap_hwmod omap44xx_dma_system_hwmod = {
+   .name   = "dma_system",
+   .class  = &omap44xx_dma_hwmod_class,
+   .mpu_irqs   = omap44xx_dma_system_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap44xx_dma_system_irqs),
+   .main_clk   = "l3_div_ck",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_reg = OMAP4430_CM_SDMA_SDMA_CLKCTRL,
+   },
+   },
+   .slaves = omap44xx_dma_system_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap44xx_dma_system_slaves),
+   .masters= omap44xx

[PATCH v3 05/13] OMAP2430: DMA: hwmod: add system DMA

[G, Manjunath Kondaiah]

Add OMAP2430 DMA hwmod structures.

Signed-off-by: G, Manjunath Kondaiah 
Cc: Benoit Cousson 
Cc: Kevin Hilman 
Cc: Santosh Shilimkar 
---
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   85 
 1 files changed, 85 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 7cf0d3a..d3b7239 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -38,6 +38,7 @@ static struct omap_hwmod omap2430_iva_hwmod;
 static struct omap_hwmod omap2430_l3_main_hwmod;
 static struct omap_hwmod omap2430_l4_core_hwmod;
 static struct omap_hwmod omap2430_wd_timer2_hwmod;
+static struct omap_hwmod omap2430_dma_system_hwmod;
 
 /* L3 -> L4_CORE interface */
 static struct omap_hwmod_ocp_if omap2430_l3_main__l4_core = {
@@ -569,6 +570,89 @@ static struct omap_hwmod omap2430_i2c2_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
 };
 
+/* dma_system */
+static struct omap_hwmod_class_sysconfig omap2430_dma_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x002c,
+   .syss_offs  = 0x0028,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+   .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_dma_hwmod_class = {
+   .name = "dma",
+   .sysc = &omap2430_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+   .dev_caps  = DMA_LINKED_LCH | GLOBAL_PRIORITY |
+   IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+   .lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT,
+};
+
+static struct omap_hwmod_irq_info omap2430_dma_system_irqs[] = {
+   { .name = "0", .irq = INT_24XX_SDMA_IRQ0 },
+   { .name = "1", .irq = INT_24XX_SDMA_IRQ1 },
+   { .name = "2", .irq = INT_24XX_SDMA_IRQ2 },
+   { .name = "3", .irq = INT_24XX_SDMA_IRQ3 },
+};
+
+static struct omap_hwmod_addr_space omap2430_dma_system_addrs[] = {
+   {
+   .pa_start   = 0x48056000,
+   .pa_end = 0x4a0560ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* dma_system -> L3 */
+static struct omap_hwmod_ocp_if omap2430_dma_system__l3 = {
+   .master = &omap2430_dma_system_hwmod,
+   .slave  = &omap2430_l3_main_hwmod,
+   .clk= "l3_div_ck",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap2430_dma_system_masters[] = {
+   &omap2430_dma_system__l3,
+};
+
+/* l4_cfg -> dma_system */
+static struct omap_hwmod_ocp_if omap2430_l4_core__dma_system = {
+   .master = &omap2430_l4_core_hwmod,
+   .slave  = &omap2430_dma_system_hwmod,
+   .clk= "l4_div_ck",
+   .addr   = omap2430_dma_system_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2430_dma_system_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap2430_dma_system_slaves[] = {
+   &omap2430_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap2430_dma_system_hwmod = {
+   .name   = "dma",
+   .class  = &omap2430_dma_hwmod_class,
+   .mpu_irqs   = omap2430_dma_system_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2430_dma_system_irqs),
+   .main_clk   = "l3_div_ck",
+   .slaves = omap2430_dma_system_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap2430_dma_system_slaves),
+   .masters= omap2430_dma_system_masters,
+   .masters_cnt= ARRAY_SIZE(omap2430_dma_system_masters),
+   .dev_attr   = &dma_dev_attr,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+   .flags  = HWMOD_NO_IDLEST,
+};
+
 static __initdata struct omap_hwmod *omap2430_hwmods[] = {
&omap2430_l3_main_hwmod,
&omap2430_l4_core_hwmod,
@@ -581,6 +665,7 @@ static __initdata struct omap_hwmod *omap2430_hwmods[] = {
&omap2430_uart3_hwmod,
&omap2430_i2c1_hwmod,
&omap2430_i2c2_hwmod,
+   &omap2430_dma_system_hwmod,
NULL,
 };
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 04/13] OMAP2420: DMA: hwmod: add system DMA

[G, Manjunath Kondaiah]

Add OMAP2420 DMA hwmod structures.

Signed-off-by: G, Manjunath Kondaiah 
Cc: Benoit Cousson 
Cc: Kevin Hilman 
Cc: Santosh Shilimkar 
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |   85 
 1 files changed, 85 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a1a3dd6..3a51392 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -38,6 +38,7 @@ static struct omap_hwmod omap2420_iva_hwmod;
 static struct omap_hwmod omap2420_l3_main_hwmod;
 static struct omap_hwmod omap2420_l4_core_hwmod;
 static struct omap_hwmod omap2420_wd_timer2_hwmod;
+static struct omap_hwmod omap2420_dma_system_hwmod;
 
 /* L3 -> L4_CORE interface */
 static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -557,6 +558,89 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
.flags  = HWMOD_16BIT_REG,
 };
 
+/* system dma */
+static struct omap_hwmod_class_sysconfig omap2420_dma_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x002c,
+   .syss_offs  = 0x0028,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+   .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_dma_hwmod_class = {
+   .name = "dma",
+   .sysc = &omap2420_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+   .dev_caps  = DMA_LINKED_LCH | GLOBAL_PRIORITY |
+   IS_CSSA_32 | IS_CDSA_32,
+   .lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT,
+};
+
+static struct omap_hwmod_irq_info omap2420_dma_system_irqs[] = {
+   { .name = "0", .irq = INT_24XX_SDMA_IRQ0 },
+   { .name = "1", .irq = INT_24XX_SDMA_IRQ1 },
+   { .name = "2", .irq = INT_24XX_SDMA_IRQ2 },
+   { .name = "3", .irq = INT_24XX_SDMA_IRQ3 },
+};
+
+static struct omap_hwmod_addr_space omap2420_dma_system_addrs[] = {
+   {
+   .pa_start   = 0x48056000,
+   .pa_end = 0x4a0560ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* dma_system -> L3 */
+static struct omap_hwmod_ocp_if omap2420_dma_system__l3 = {
+   .master = &omap2420_dma_system_hwmod,
+   .slave  = &omap2420_l3_main_hwmod,
+   .clk= "l3_div_ck",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap2420_dma_system_masters[] = {
+   &omap2420_dma_system__l3,
+};
+
+/* l4_cfg -> dma_system */
+static struct omap_hwmod_ocp_if omap2420_l4_core__dma_system = {
+   .master = &omap2420_l4_core_hwmod,
+   .slave  = &omap2420_dma_system_hwmod,
+   .clk= "l4_div_ck",
+   .addr   = omap2420_dma_system_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2420_dma_system_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap2420_dma_system_slaves[] = {
+   &omap2420_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap2420_dma_system_hwmod = {
+   .name   = "dma",
+   .class  = &omap2420_dma_hwmod_class,
+   .mpu_irqs   = omap2420_dma_system_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2420_dma_system_irqs),
+   .main_clk   = "l3_div_ck",
+   .slaves = omap2420_dma_system_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap2420_dma_system_slaves),
+   .masters= omap2420_dma_system_masters,
+   .masters_cnt= ARRAY_SIZE(omap2420_dma_system_masters),
+   .dev_attr   = &dma_dev_attr,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+   .flags  = HWMOD_NO_IDLEST,
+};
+
 static __initdata struct omap_hwmod *omap2420_hwmods[] = {
&omap2420_l3_main_hwmod,
&omap2420_l4_core_hwmod,
@@ -569,6 +653,7 @@ static __initdata struct omap_hwmod *omap2420_hwmods[] = {
&omap2420_uart3_hwmod,
&omap2420_i2c1_hwmod,
&omap2420_i2c2_hwmod,
+   &omap2420_dma_system_hwmod,
NULL,
 };
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 01/13] OMAP: DMA: Replace read/write macros with functions

[G, Manjunath Kondaiah]

The low level read/write macros are replaced with static inline functions
and register offsets are handled through static register offset tables
mapped through enumeration constants.

The objective of this patch is to prepare for omap dma driver cleanup
and dma hwmod implementation. The code optimization and moving machine
specific code to respective mach-omapx dma file will be handled in the
rest of this patch series.

Signed-off-by: G, Manjunath Kondaiah 
Cc: Benoit Cousson 
Cc: Kevin Hilman 
Cc: Santosh Shilimkar 
---
 arch/arm/plat-omap/dma.c  |  739 ++---
 arch/arm/plat-omap/include/plat/dma.h |  120 --
 2 files changed, 497 insertions(+), 362 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index f5c5b8d..77241e2 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -40,6 +40,147 @@
 
 #undef DEBUG
 
+enum {
+   GCR1 = 0,   GSCR,   GRST,   HW_ID,
+   PCH2_ID,PCH0_ID,PCH1_ID,PCHG_ID,
+   PCHD_ID,CAPS1_0_U,  CAPS1_0_L,  CAPS1_1_U,
+   CAPS1_1_L,  CAPS1_2,CAPS1_3,CAPS1_4,
+   PCH2_SR,PCH0_SR,PCH1_SR,PCHD_SR,
+
+   OMAP1_CH_COMMON_START,
+
+   /* Common Registers */
+   CSDP1,  CCR1,   CICR1,  CSR1,
+   CEN1,   CFN1,   CSFI1,  CSEI1,
+   CPC,CSAC1,  CDAC1,  CDEI1,
+   CDFI1,  CLNK_CTRL1,
+
+   /* Channel specific register offsets */
+   CSSA_L, CSSA_U, CDSA_L, CDSA_U,
+   COLOR_L,COLOR_U,CCR1_2, LCH_CTRL,
+
+   OMAP1_CH_COMMON_END,
+};
+
+static u16 reg_map_omap1[] = {
+   [GCR1]  = 0x400,
+   [GSCR]  = 0x404,
+   [GRST]  = 0x408,
+   [HW_ID] = 0x442,
+   [PCH2_ID]   = 0x444,
+   [PCH0_ID]   = 0x446,
+   [PCH1_ID]   = 0x448,
+   [PCHG_ID]   = 0x44a,
+   [PCHD_ID]   = 0x44c,
+   [CAPS1_0_U] = 0x44e,
+   [CAPS1_0_L] = 0x450,
+   [CAPS1_1_U] = 0x452,
+   [CAPS1_1_L] = 0x454,
+   [CAPS1_2]   = 0x456,
+   [CAPS1_3]   = 0x458,
+   [CAPS1_4]   = 0x45a,
+   [PCH2_SR]   = 0x460,
+   [PCH0_SR]   = 0x480,
+   [PCH1_SR]   = 0x482,
+   [PCHD_SR]   = 0x4c0,
+
+   /* Common Registers */
+   [CSDP1] = 0x00,
+   [CCR1]  = 0x02,
+   [CICR1] = 0x04,
+   [CSR1]  = 0x06,
+   [CEN1]  = 0x10,
+   [CFN1]  = 0x12,
+   [CSFI1] = 0x14,
+   [CSEI1] = 0x16,
+   [CPC]   = 0x18, /* 15xx only */
+   [CSAC1] = 0x18,
+   [CDAC1] = 0x1a,
+   [CDEI1] = 0x1c,
+   [CDFI1] = 0x1e,
+   [CLNK_CTRL1]= 0x28,
+
+   /* Channel specific register offsets */
+   [CSSA_L]= 0x08,
+   [CSSA_U]= 0x0a,
+   [CDSA_L]= 0x0c,
+   [CDSA_U]= 0x0e,
+   [COLOR_L]   = 0x20,
+   [COLOR_U]   = 0x22,
+   [CCR1_2]= 0x24,
+   [LCH_CTRL]  = 0x2a,
+};
+
+enum {
+   REVISION = 0,   GCR2,   IRQSTATUS_L0,   IRQSTATUS_L1,
+   IRQSTATUS_L2,   IRQSTATUS_L3,   IRQENABLE_L0,   IRQENABLE_L1,
+   IRQENABLE_L2,   IRQENABLE_L3,   SYSSTATUS,  OCP_SYSCONFIG,
+   CAPS2_0,CAPS2_2,CAPS2_3,CAPS2_4,
+
+   OMAP2_CH_COMMON_START,
+
+   /* Common register offsets */
+   CCR2,   CLNK_CTRL2, CICR2,  CSR2,
+   CSDP2,  CEN2,   CFN2,   CSEI2,
+   CSFI2,  CDEI2,  CDFI2,  CSAC2,
+   CDAC2,
+
+   /* Channel specific register offsets */
+   CSSA,   CDSA,   CCEN,   CCFN,
+   COLOR,
+
+   /* OMAP4 specific registers */
+   CDP,CNDP,   CCDN,
+
+   OMAP2_CH_COMMON_END,
+};
+
+static u16 reg_map_omap2[] = {
+   [REVISION]  = 0x00,
+   [GCR2]  = 0x78,
+   [IRQSTATUS_L0]  = 0x08,
+   [IRQSTATUS_L1]  = 0x0c,
+   [IRQSTATUS_L2]  = 0x10,
+   [IRQSTATUS_L3]  = 0x14,
+   [IRQENABLE_L0]  = 0x18,
+   [IRQENABLE_L1]  = 0x1c,
+   [IRQENABLE_L2]  = 0x20,
+   [IRQENABLE_L3]  = 0x24,
+   [SYSSTATUS] = 0x28,
+   [OCP_SYSCONFIG] = 0x2c,
+   [CAPS2_0]   = 0x64,
+   [CAPS2_2]   = 0x6c,
+   [CAPS2_3]   = 0x70,
+   [CAPS2_4]   = 0x74,
+
+   /* Common register offsets */
+   [CCR2]  = 0x80,
+   [CLNK_CTRL2]= 0x84,
+   [CICR2] = 0x88,
+   [CSR2]  = 0x8c,
+   [CSDP2] = 0x90,
+   [CEN2]   

[PATCH v3 02/13] OMAP: DMA: Introduce errata handling feature

[G, Manjunath Kondaiah]

Implement errata handling to use flags instead of cpu_is_*
and cpu_class_* in the code.

The errata flags are initialized at init time and during runtime
we are using the errata variable (via the IS_DMA_ERRATA macro)
to execute the required errata workaround.

Reused errata handling patch from Peter Ujfalusi 
https://patchwork.kernel.org/patch/231191/

Signed-off-by: G, Manjunath Kondaiah 
Cc: Peter Ujfalusi 
Cc: Benoit Cousson 
Cc: Kevin Hilman 
Cc: Santosh Shilimkar 
---
 arch/arm/plat-omap/dma.c  |  134 ++--
 arch/arm/plat-omap/include/plat/dma.h |   11 +++
 2 files changed, 103 insertions(+), 42 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 77241e2..0ff82d0 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -195,6 +195,7 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
 #define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
 
 static int enable_1510_mode;
+static u32 errata;
 
 static struct omap_dma_global_context_registers {
u32 dma_irqenable_l0;
@@ -1216,12 +1217,8 @@ void omap_start_dma(int lch)
 
cur_lch = next_lch;
} while (next_lch != -1);
-   } else if (cpu_is_omap242x() ||
-   (cpu_is_omap243x() &&  omap_type() <= OMAP2430_REV_ES1_0)) {
-
-   /* Errata: Need to write lch even if not using chaining */
+   } else if (IS_DMA_ERRATA(DMA_ERRATA_PARALLEL_CHANNELS))
dma_write(lch, CLNK_CTRL2, lch);
-   }
 
omap_enable_channel_irq(lch);
 
@@ -1231,17 +1228,8 @@ void omap_start_dma(int lch)
dma_write(l, CCR1, lch);
} else {
l = dma_read(CCR2, lch);
-   /*
-* Errata: Inter Frame DMA buffering issue (All OMAP2420 and
-* OMAP2430ES1.0): DMA will wrongly buffer elements if packing
-* and bursting is enabled. This might result in data gets
-* stalled in FIFO at the end of the block.
-* Workaround: DMA channels must have BUFFERING_DISABLED bit
-* set to guarantee no data will stay in the DMA FIFO in case
-* inter frame buffering occurs.
-*/
-   if (cpu_is_omap2420() || (cpu_is_omap2430() &&
-   (omap_type() == OMAP2430_REV_ES1_0)))
+
+   if (IS_DMA_ERRATA(DMA_ERRATA_IFRAME_BUFFERING))
l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
 
l |= OMAP_DMA_CCR_EN;
@@ -1253,14 +1241,14 @@ EXPORT_SYMBOL(omap_start_dma);
 
 void omap_stop_dma(int lch)
 {
-   u32 l;
+   u32 l = 0;
 
/* Disable all interrupts on the channel */
if (cpu_class_is_omap1())
dma_write(0, CICR1, lch);
 
-   /* OMAP3 Errata i541: sDMA FIFO draining does not finish */
-   if (cpu_is_omap34xx() && (l & OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
+   if (IS_DMA_ERRATA(DMA_ERRATA_i541) &&
+   (l & OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
int i = 0;
u32 sys_cf;
 
@@ -1367,11 +1355,7 @@ dma_addr_t omap_get_dma_src_pos(int lch)
else
offset = dma_read(CSAC2, lch);
 
-   /*
-* omap 3.2/3.3 erratum: sometimes 0 is returned if CSAC/CDAC is
-* read before the DMA controller finished disabling the channel.
-*/
-   if (!cpu_is_omap15xx() && offset == 0) {
+   if (IS_DMA_ERRATA(DMA_ERRATA_3_3) && offset == 0) {
if (cpu_class_is_omap1())
offset = dma_read(CSAC1, lch);
else
@@ -1966,7 +1950,7 @@ int omap_stop_dma_chain_transfers(int chain_id)
 {
int *channels;
u32 l, i;
-   u32 sys_cf;
+   u32 sys_cf = 0;
 
/* Check for input params */
if (unlikely((chain_id < 0 || chain_id >= dma_lch_count))) {
@@ -1981,15 +1965,13 @@ int omap_stop_dma_chain_transfers(int chain_id)
}
channels = dma_linked_lch[chain_id].linked_dmach_q;
 
-   /*
-* DMA Errata:
-* Special programming model needed to disable DMA before end of block
-*/
-   sys_cf = dma_read(OCP_SYSCONFIG, 0);
-   l = sys_cf;
-   /* Middle mode reg set no Standby */
-   l &= ~((1 << 12)|(1 << 13));
-   dma_write(l, OCP_SYSCONFIG, 0);
+   if (IS_DMA_ERRATA(DMA_ERRATA_i88)) {
+   sys_cf = dma_read(OCP_SYSCONFIG, 0);
+   l = sys_cf;
+   /* Middle mode reg set no Standby */
+   l &= ~((1 << 12)|(1 << 13));
+   dma_write(l, OCP_SYSCONFIG, 0);
+   }
 
for (i = 0; i < dma_linked_lch[chain_id].no_of_lchs_linked; i++) {
 
@@ -2008,8 +1990,8 @@ int omap_stop_dma_chain_transfers(int chain_id)
/* Reset the Queue pointers */
OMAP_DMA_CHAIN_QINIT(chain_id);
 
-   /* Errata - put in the old value */
-   dma_write(sys_cf, OCP_SYSCONFIG, 0);
+   if (IS_DMA_ERRATA

[PATCH v3 03/13] OMAP: DMA: Introduce DMA device attributes

[G, Manjunath Kondaiah]

This patch introduces OMAP DMA device attributes for using the same in
DMA platform driver for all OMAP's and HWMOD database(OMAP2PLUS onwards)

Signed-off-by: G, Manjunath Kondaiah 
Cc: Benoit Cousson 
Cc: Kevin Hilman 
Cc: Santosh Shilimkar 
---
 arch/arm/plat-omap/include/plat/dma.h |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/dma.h 
b/arch/arm/plat-omap/include/plat/dma.h
index 5e28d26..9757b22 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -296,6 +296,22 @@
 #define DMA_ERRATA_i88 (1 << 4)
 #define DMA_ERRATA_3_3 (1 << 5)
 
+/* Attributes for OMAP DMA Contrllers */
+#define ENABLE_1510_MODE   (1 << 0x0)
+#define DMA_LINKED_LCH (1 << 0x1)
+#define GLOBAL_PRIORITY(1 << 0x2)
+#define RESERVE_CHANNEL(1 << 0x3)
+#define SRC_PORT   (1 << 0x4)
+#define DST_PORT   (1 << 0x5)
+#define IS_CSSA_32 (1 << 0x6)
+#define IS_CDSA_32 (1 << 0x7)
+#define SRC_INDEX  (1 << 0x8)
+#define DST_INDEX  (1 << 0x9)
+#define IS_BURST_ONLY4 (1 << 0xA)
+#define CLEAR_CSR_ON_READ  (1 << 0xB)
+#define IS_WORD_16 (1 << 0xC)
+#define IS_RW_PRIORITY (1 << 0xD)
+
 enum omap_dma_burst_mode {
OMAP_DMA_DATA_BURST_DIS = 0,
OMAP_DMA_DATA_BURST_4,
@@ -361,6 +377,10 @@ struct omap_dma_channel_params {
 #endif
 };
 
+struct omap_dma_dev_attr {
+   u32 dev_caps;
+   u16 lch_count;
+};
 
 extern void omap_set_dma_priority(int lch, int dst_port, int priority);
 extern int omap_request_dma(int dev_id, const char *dev_name,
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 00/13] OMAP: DMA: hwmod and DMA as platform device

[G, Manjunath Kondaiah]

This patch series converts DMA library into platform device and hwmod 
adaptation is done for omap2+ processors.

It also replaces cpu_*is* checks by moving omap1 and omap2+ processor 
code into repsective mach-omapx directories. The common code in plat-omap
will use device attributes for differentiating omap1 and omap2 code.

Build Report:
omap1:  Success for omap_h2_1610_defconfig
omap2+: Success for omap2plus_defconfig

Test Report:
omap2+:(multiboot defconfig boots on all the omap2+ boards listed below):
OMAP4BLAZE: http://pastebin.com/HVnim30G
OMAP3630ZOOM3: http://pastebin.com/JJwrtP4F
OMAP243SDP: http://pastebin.com/mz7cVQL3

omap1 : Not tested 

Test cases executed:
1. All applicable TI DMA tests which are located at:
http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=tree;f=dma/test_code;h=0d00de3c0fe6933b405c62da63f694883f3e4b8f;hb=2c50a5a58dea0ffc2d31b827935aeef9b9d11253

2. Use case tests :  TI MMC tests are executed with differenct types of
files systems such as DOS, ext2, ext3 etc on omap4 blaze and omap3630 zoom3. 
More information can be found at:
http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=tree;f=mmc/test_code;h=d0bc1984eef46ac45719efb02b5c1f4193422a1b;hb=2c50a5a58dea0ffc2d31b827935aeef9b9d11253

Dependencies:
This patch series has dependency on omap_device patch:
https://patchwork.kernel.org/patch/282212/

This patch series applies on:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
Branch: master
commit a83d12a47c9a8c78a184910150797045d69a1570
Merge: f9f47f5 c1fb8df
Author: Tony Lindgren 
Date:   Fri Oct 22 11:21:08 2010 -0700

Linux-omap rebuilt: Updated to v2.6.36, add 24xx uart fix

Changelist summary:
v3:
Review comments fixed:
http://www.listware.net/201008/linux-omap/89002-patch-v2-0011-omap-dma-hwmod-and-dma-as-platform-driver.html
 - created and tested on latest linux-omap master branch(2.6.36 kernel)

v2:
The review comments which are fixed can be found at:
http://www.spinics.net/lists/linux-omap/msg34291.html
http://www.spinics.net/lists/linux-omap/msg34292.html
http://www.spinics.net/lists/linux-omap/msg34078.html
http://www.spinics.net/lists/linux-omap/msg34083.html

v1:
These changes are based on comments received during internal discussions which 
has changes(compared to previous version) such as:
 - Code optimization
 - Patches are rearranged in more meaningful way so that git bisect works at any
   intermediate patch in the series.
 - Build tested for all omap's(OMAP1 and OMAP2PLUS)
 - Boot tested for OMAP3 and OMAP4(appreciate if some one tests on OMAP1/2)
 - Applicalbe tests are executed on OMAP3 and OMAP4 boards
 - Rebased and added descriptor autoloading feature(only for omap3630 and omap4)


Benoit Cousson (1):
  OMAP4: DMA: hwmod: add system DMA

G, Manjunath Kondaiah (12):
  OMAP: DMA: Replace read/write macros with functions
  OMAP: DMA: Introduce errata handling feature
  OMAP: DMA: Introduce DMA device attributes
  OMAP2420: DMA: hwmod: add system DMA
  OMAP2430: DMA: hwmod: add system DMA
  OMAP3: DMA: hwmod: add system DMA
  OMAP1: DMA: Introduce DMA driver as platform device
  OMAP2+: DMA: hwmod: Device registration
  OMAP: DMA: Convert DMA library into DMA platform Driver
  OMAP: DMA: Use DMA device attributes
  sDMA: descriptor autoloading feature
  OMAP: PM: DMA: Enable runtime pm

 arch/arm/mach-omap1/Makefile   |2 +-
 arch/arm/mach-omap1/dma.c  |  665 ++
 arch/arm/mach-omap1/include/mach/dma.h |   51 +
 arch/arm/mach-omap2/Makefile   |2 +-
 arch/arm/mach-omap2/dma.c  | 1579 
 arch/arm/mach-omap2/include/mach/dma.h |   86 ++
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |   85 ++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   85 ++
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   93 ++
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   99 ++
 arch/arm/plat-omap/dma.c   | 1850 
 arch/arm/plat-omap/include/plat/dma.h  |  387 ---
 12 files changed, 3207 insertions(+), 1777 deletions(-)
 create mode 100644 arch/arm/mach-omap1/dma.c
 create mode 100644 arch/arm/mach-omap1/include/mach/dma.h
 create mode 100644 arch/arm/mach-omap2/dma.c
 create mode 100644 arch/arm/mach-omap2/include/mach/dma.h

Cc: Benoit Cousson 
Cc: Kevin Hilman 
Cc: Santosh Shilimkar 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Thomas Renninger]

On Tuesday 26 October 2010 13:54:22 Ingo Molnar wrote:
> 
> * Thomas Renninger  wrote:
> 
..
> As you state above: POWER_NONE does not make sense at all.
> > The whole thing (type= attribute that vanishes now) is
> > passed to userspace, but never gets used there because the
> > same info is in the event name:
> > cpu_frequency <-> frequency_switch  <-> PSTATE
> > cpu_idle  <-> power_start/power_end <-> CSTATE 
> 
> Ah, i see, so this 'state' enum went into the type field.
> 
> So my question is, and ignore this particular enum for now, what values go 
> into the 
> state field, which field is still kept in the new events as well.
Same as before:
cpu_idle:
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+   trace_processor_idle(1, smp_processor_id());
(Ooops found a copy and paste bug in my patch where I reverted
the poll_idle event, but it should be zero...).

State in cpu_idle is identical with cpuidle registered
state. If cpuidle got registered, one should be able to calculate the
same C-state residency time and usage via state=X (cpu_idle event)
which you can grab via:
cat /sys/devices/system/cpu/cpu0/cpuidle/stateX/{time,usage}
The cpu_idle event additionally gives you the timestamps of the state
changes.
This is rather nice as userspace can grab additional info from
cpuidle sysfs layer like:
/sys/devices/system/cpu/cpu0/cpuidle/stateX/{desc,power,name}

If cpuidle is not registered, the events you get are arch specific.
I mean they are arch specific anyway, but with cpuidle you can
build up an arch independent userspace framework nicely by looking
up name/desc/power/... of an cpu_idle event in cpuidle sysfs as
described above.

   Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] OMAP: hwmod: Update the sysc_cache in case module context is lost

[Rajendra Nayak]

Do not skip the sysc programming in the hmwod framework based
on the cached value alone, since at times the module might have lost
context (due to the Powerdomain in which the module belongs
transitions to either Open Switch RET or OFF).

Identifying if a module has lost context requires atleast one
register read, and since a register read has more latency than
a write, it makes sense to do a blind write always.

Signed-off-by: Rajendra Nayak 
Cc: Paul Walmsley 
Cc: Benoit Cousson 
Cc: Santosh Shilimkar 
Cc: Kevin Hilman 
---
 arch/arm/mach-omap2/omap_hwmod.c |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5a30658..aadd6dc 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -209,10 +209,9 @@ static void _write_sysconfig(u32 v, struct omap_hwmod *oh)
 
/* XXX ensure module interface clock is up */
 
-   if (oh->_sysc_cache != v) {
-   oh->_sysc_cache = v;
-   omap_hwmod_write(v, oh, oh->class->sysc->sysc_offs);
-   }
+   /* Module might have lost context, always update cache and register */
+   oh->_sysc_cache = v;
+   omap_hwmod_write(v, oh, oh->class->sysc->sysc_offs);
 }
 
 /**
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 12/14] drivers/video/omap/blizzard.c: delete double assignment

[Nicolas Kaiser]

* Julia Lawall :
> Delete successive assignments to the same location.  Initialize the out_y
> field as well as the out_x field, rather than initializing the out_x field
> twice.

Hi there!

An identical patch is already in the -mm tree:

> The patch titled
>  drivers/video/omap/blizzard.c: suspected typo in assignment
> has been added to the -mm tree.  Its filename is
>  video-omap-suspected-typo-in-assignment.patch

> See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
> out what to do about this
> 
> The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
> 
> --
> Subject: drivers/video/omap/blizzard.c: suspected typo in assignment
> From: Nicolas Kaiser 
> 
> Untested, but looks like an obvious typo to me.
> 
> Signed-off-by: Nicolas Kaiser 
> Cc: Tomi Valkeinen 
> Cc: Tony Lindgren 
> Signed-off-by: Andrew Morton 

Best regards,
Nicolas Kaiser
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] OMAP2+: PM: omap_device: API for set/get MSTANDBY mode

[G, Manjunath Kondaiah]

Certain errata's in OMAP2+ processors will require disabling
master standby mode before completing on going operation. Without
this, the results will be unpredictable.

Since current implementation of PM run time framework does not support
changing sysconfig settings during middle of the on going operation,
these API's will support the same.

These API's should be used by device drivers only incase of
erratum applicable to their modules if there is no other methods
to resolve.

This API is required for multiple DMA errata's which require
putting DMA controller in no mstandby mode before stopping dma.

The applicable errata's:
1. Errata ID: i557(Applicable for omap36xx all ES versions)
The channel hangs when the Pause bit (DMA4_CDPi [7] ) is cleared 
through config port while in Standby.

2. Errata ID: i541(all omap2plus except omap4)
sDMA FIFO draining does not finish

3. Errata ID: i88(only omap3430 ES1.0)
Special programming model needed to disable DMA before end
of block

4. OMAP3430 ES1.0(Errata ID:i88) will require DMA to be put in
no mstandby mode before disabling the channel after completing
the data transfer operation.

Signed-off-by: G, Manjunath Kondaiah 
Cc: Kevin Hilman 
Cc: Paul Walmsley 
Cc: Anand Gadiyar 
Cc: Benoit Cousson 
---
Changes from v1 to v2:
 - updated patch description with relevant errata id's.
 - API name changed to master_standbymode from master_idlemode

 arch/arm/mach-omap2/omap_hwmod.c  |   83 +
 arch/arm/plat-omap/include/plat/omap_device.h |3 +-
 arch/arm/plat-omap/include/plat/omap_hwmod.h  |3 +
 arch/arm/plat-omap/omap_device.c  |   36 +++
 4 files changed, 124 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5a30658..e3f7490 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -250,6 +250,35 @@ static int _set_master_standbymode(struct omap_hwmod *oh, 
u8 standbymode,
 }
 
 /**
+ * _get_master_standbymode: get the OCP_SYSCONFIG MIDLEMODE field in @midlemode
+ * @oh: struct omap_hwmod *
+ * @standbymode: pointer to get mstandby mode bits(shifted to bit 0)
+ *
+ * Get the master standby mode bits in @midlemode for the @oh hwmod.
+ * Does not fetch the data from the hardware instead returns value
+ * from sysc_cache. Returns -EINVAL upon error or 0 upon success.
+ */
+static int _get_master_standbymode(struct omap_hwmod *oh, u32 *midlemode)
+{
+   u32 mstandby_mask;
+   u8 mstandby_shift;
+
+   if (!oh->class->sysc ||
+   !(oh->class->sysc->sysc_flags & SYSC_HAS_MIDLEMODE))
+   return -EINVAL;
+
+   if (!oh->class->sysc->sysc_fields) {
+   WARN(1, "omap_hwmod: %s: offset struct for sysconfig not"
+   " provided in class\n", oh->name);
+   return -EINVAL;
+   }
+
+   *midlemode = ((oh->_sysc_cache) & mstandby_mask) >> mstandby_shift;
+
+   return 0;
+}
+
+/**
  * _set_slave_idlemode: set the OCP_SYSCONFIG SIDLEMODE field in @v
  * @oh: struct omap_hwmod *
  * @idlemode: SIDLEMODE field bits
@@ -1427,6 +1456,60 @@ int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, 
u8 idlemode)
 }
 
 /**
+ * omap_hwmod_set_master_standbymode - set the hwmod's OCP master idlemode
+ * @oh: struct omap_hwmod *
+ * @midlemode: MIDLEMODE field bits (shifted to bit 0)
+ *
+ * Sets the IP block's OCP master idlemode in hardware, and updates our
+ * local copy.  Intended to be used by drivers that have some erratum
+ * that requires direct manipulation of the MIDLEMODE bits.  Returns
+ * -EINVAL if @oh is null, or passes along the return value from
+ * _set_master_standbymode().
+ *
+ * Any users of this function should be scrutinized carefully.
+ */
+int omap_hwmod_set_master_standbymode(struct omap_hwmod *oh, u32 midlemode)
+{
+   u32 v;
+   int retval = 0;
+
+   if (!oh)
+   return -EINVAL;
+
+   v = oh->_sysc_cache;
+
+   retval = _set_master_standbymode(oh, midlemode, &v);
+   if (!retval)
+   _write_sysconfig(v, oh);
+
+   return retval;
+}
+
+/**
+ * omap_hwmod_get_master_idlemode - set the hwmod's OCP master idlemode
+ * @oh: struct omap_hwmod *
+ * @midlemode: pointer to get MIDLEMODE field bits (shifted to bit 0)
+ *
+ * Gets the IP block's OCP master idlemode from our local copy. Intended
+ * to be used by drivers that have some erratum that requires direct
+ * manipulation of the MIDLEMODE bits. Returns -EINVAL if @oh is null,
+ * or passes along the return value from _get_master_standbymode().
+ *
+ * Any users of this function should be scrutinized carefully.
+ */
+int omap_hwmod_get_master_standbymode(struct omap_hwmod *oh, u32 *midlemode)
+{
+   int retval = 0;
+
+   if (!oh)
+   return -EINVAL;
+
+   retval = _get_master_standbymode(oh, midlemode);
+
+   return retval;
+}
+
+/**
  * omap_hwmod_register - register a struct omap_

Re: [PATCH 3/3] omap: add hwspinlock device

[Ohad Ben-Cohen]

On Mon, Oct 25, 2010 at 9:02 PM, Tony Lindgren  wrote:
>> if you feel that (2) is justifiable/desirable, I would be more
>> than happy to submit that version.
>
> Yes (2) please. I would assume there will be more use of this. And then
> we (or probably me again!) don't have to deal with cleaning up the drivers
> again in the future.

Sounds good.

>> Or do you mean a variation of (2) with only the specific locking bits
>> coming from pdata func pointers ? I guess that in this case we just
>> might as well go with the full (2).
>
> Yes variation of (2) where you only pass the locking function via
> platform data would be best.

It feels a bit funky to me because we would still have code that is
omap-specific inside the "common" probe()/remove() calls.

I suggest to move everything that is omap-specific to a small omap
module that, once probed, would register itself with the common
hwspinlock framework (after initializing its hardware).

That small platfom-specific module probably doesn't have to sit in the
arch/ folder; we can follow established conventions like
mmc/i2c/gpio/spi/etc..

With that in hand, the hwspinlock would really be hardware-agnostic,
and then applying s/omap_hwspin/hwspin/ would be justified.

Does this sound reasonable to you ?

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Ingo Molnar]

* Thomas Renninger  wrote:

> On Tuesday 26 October 2010 13:21:29 Ingo Molnar wrote:
> > 
> > * Jean Pihet  wrote:
> ..
> > > >> +#ifndef _TRACE_POWER_ENUM_
> > > >> +#define _TRACE_POWER_ENUM_
> > > >> +enum {
> > > >> + POWER_NONE = 0,
> > > >> + POWER_CSTATE = 1,
> > > >> + POWER_PSTATE = 2,
> > > >> +};
> > > >> +#endif
> > > >
> > > > Since we are cleaning up all these events, those enum definitions dont 
> > > > really look
> > > > logical. For example, what is 'POWER_NONE'? Can a CPU have 'no power'?
> > >
> > > The enum belongs to the deprecated API so I would rather not touch it.
> > > Keeping the deprecated code isolated will make it easier to remove
> > > later.
> > 
> > So what will replace it? We still have a state field.
>
> Nothing, this is part of the cleanup.

I mean, what will go into the state field of the power:cpu_idle event?

> As you state above: POWER_NONE does not make sense at all.
> The whole thing (type= attribute that vanishes now) is
> passed to userspace, but never gets used there because the
> same info is in the event name:
> cpu_frequency <-> frequency_switch  <-> PSTATE
> cpu_idle  <-> power_start/power_end <-> CSTATE 

Ah, i see, so this 'state' enum went into the type field.

So my question is, and ignore this particular enum for now, what values go into 
the 
state field, which field is still kept in the new events as well.

[ I'd like to avoid us having to define a third set of power events a few years 
down 
  the road ;-) ]

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Thomas Renninger]

On Tuesday 26 October 2010 13:21:29 Ingo Molnar wrote:
> 
> * Jean Pihet  wrote:
..
> > >> +#ifndef _TRACE_POWER_ENUM_
> > >> +#define _TRACE_POWER_ENUM_
> > >> +enum {
> > >> + POWER_NONE = 0,
> > >> + POWER_CSTATE = 1,
> > >> + POWER_PSTATE = 2,
> > >> +};
> > >> +#endif
> > >
> > > Since we are cleaning up all these events, those enum definitions dont 
> > > really look
> > > logical. For example, what is 'POWER_NONE'? Can a CPU have 'no power'?
> >
> > The enum belongs to the deprecated API so I would rather not touch it.
> > Keeping the deprecated code isolated will make it easier to remove
> > later.
> 
> So what will replace it? We still have a state field.
Nothing, this is part of the cleanup.
As you state above: POWER_NONE does not make sense at all.
The whole thing (type= attribute that vanishes now) is
passed to userspace, but never gets used there because the
same info is in the event name:
cpu_frequency <-> frequency_switch  <-> PSTATE
cpu_idle  <-> power_start/power_end <-> CSTATE 

I expect that there was an initial power_start/end which
was also used for frequency switching.
Then it got realized that _start/_end does not work out and
frequency_switch got introduced.
To stay compatible the whole power_start/end was not renamed
to cpu_idle and the type= field was kept.

This is a guess without even looking at the git history.
Therefore my partly harsh comments about the sanity of the
current power tracing events.

> Passing in platform specific codes is a step backwards.
> 
> > >> +TRACE_EVENT(machine_suspend,
> > >> +
> > >> + TP_PROTO(unsigned int state),
> > >> +
> > >> + TP_ARGS(state),
> > >> +
> > >> + TP_STRUCT__entry(
> > >> + __field(u32,state   )
> > >> + ),
> > >
> > > Hm, this event is not used anywhere in the submitted patches. Where is 
> > > the patch
> > > that adds usage, and what are the possible values for 'state'?
> >
> > This will come as a separate patch, which fits all platforms. Cf.
> > http://marc.info/?l=linux-omap&m=128620575300682&w=2.
> > The state field is of type suspend_state_t, cf. include/linux/suspend.h
> 
> Ok, that's at least generic. Needs the review of Rafael, to determine
> whether this state value is all we want to know when we enter suspend.
He already gave an acked-by on this generic one here:
Re: [PATCH 3/4] perf: add calls to suspend trace point
Oh now, that was on the X86 specific part which depends on this one.
One should expect that he's fine with the generic part as well then,
but I agree that he should definitely have a look at this and sign it off.

So as they got signed-off already, I'll send the X86 suspend events
on top, once I find these in a tree...

Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map

[Felipe Contreras]

On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo  wrote:
> The device address is assigned by tidspbridge no need for that parameter 
> anymore.
>
> Signed-off-by: Fernando Guzman Lugo 

This would break the API with user-space, right?

I think this change should be delayed, preferably after we have a
working tidspbridge.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Ingo Molnar]

* Jean Pihet  wrote:

> Ingo,
> 
> On Tue, Oct 26, 2010 at 9:10 AM, Ingo Molnar  wrote:
> >
> > * Thomas Renninger  wrote:
> >
> >> Changes in V2:
> >>   - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
> >>   - Use u32 instead of u64 for cpuid, state which is by far enough
> 
> ...
> 
> >>
> >> +#define PWR_EVENT_EXIT 0x
> >
> > Shouldnt this be part of the POWER_ enum? (and you can write -1 there)
> >
> >> +#ifndef _TRACE_POWER_ENUM_
> >> +#define _TRACE_POWER_ENUM_
> >> +enum {
> >> +     POWER_NONE = 0,
> >> +     POWER_CSTATE = 1,
> >> +     POWER_PSTATE = 2,
> >> +};
> >> +#endif
> >
> > Since we are cleaning up all these events, those enum definitions dont 
> > really look
> > logical. For example, what is 'POWER_NONE'? Can a CPU have 'no power'?
>
> The enum belongs to the deprecated API so I would rather not touch it.
> Keeping the deprecated code isolated will make it easier to remove
> later.

So what will replace it? We still have a state field.

Passing in platform specific codes is a step backwards.

> >> +TRACE_EVENT(machine_suspend,
> >> +
> >> +     TP_PROTO(unsigned int state),
> >> +
> >> +     TP_ARGS(state),
> >> +
> >> +     TP_STRUCT__entry(
> >> +             __field(        u32,            state           )
> >> +     ),
> >
> > Hm, this event is not used anywhere in the submitted patches. Where is the 
> > patch
> > that adds usage, and what are the possible values for 'state'?
>
> This will come as a separate patch, which fits all platforms. Cf.
> http://marc.info/?l=linux-omap&m=128620575300682&w=2.
> The state field is of type suspend_state_t, cf. include/linux/suspend.h

Ok, that's at least generic. Needs the review of Rafael, to determine whether 
this 
state value is all we want to know when we enter suspend.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Ingo Molnar]

* Thomas Renninger  wrote:

> On Tuesday 26 October 2010 09:10:20 Ingo Molnar wrote:
> > 
> > * Thomas Renninger  wrote:
> > 
> > > Changes in V2:
> > >   - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
> > >   - Use u32 instead of u64 for cpuid, state which is by far enough
> > > 
> > > New power trace events:
> > > power:processor_idle
> > > power:processor_frequency
> > > power:machine_suspend
> > > 
> > > 
> > > C-state/idle accounting events:
> > >   power:power_start
> > >   power:power_end
> > > are replaced with:
> > >   power:processor_idle
> > > 
> > > and
> > >   power:power_frequency
> > > is replaced with:
> > >   power:processor_frequency
> > 
> > Could you please name it power:cpu_idle and power:cpu_frequency instead, 
> > for 
> > shortness? We generally use 'cpu' in the kernel and for events.
> Sure.
> > 
> > > power:machine_suspend
> > 
> > How will future PCI (or other device) power saving tracepoints be called?
> > 
> > Might be more consistent to use:
> > 
> >   power:cpu_idle
> >   power:machine_idle
> >   power:device_idle
>
> device idle is not true. Those may be low power modes
> like reduced network throughput, reduced wlan range, the device
> needs not to be idle.
> Device power states is probably the most complex area, if such
> a thing gets introduced, it should makes sense to state
> the interface experimental for some time until a wider range of
> devices uses it (in contrast to these new ones
> which should not change that soon anymore...).

Ok.

> Also machine_idle may be true, but machine_suspend sounds more
> familiar and everyone immediately knows what the event is about.

Ok - fair enough.

> > > +#define PWR_EVENT_EXIT 0x
> > 
> > Shouldnt this be part of the POWER_ enum? (and you can write -1 there)
>
> No, below enum will vanish, but -1 is nicer.

When it vanishes what will replace it?

> ...
> 
> > Plus:
> > 
> > > +DECLARE_EVENT_CLASS(processor,
> > > +
> > > + TP_PROTO(unsigned int state, unsigned int cpu_id),
> > > +
> > > + TP_ARGS(state, cpu_id),
> > > +
> > > + TP_STRUCT__entry(
> > > + __field(u32,state   )
> > > + __field(u32,cpu_id  )
> > 
> > Trace entries can carry a cpu_id of the current processor already. Can this 
> > cpu_id 
> > ever be different from that CPU id?
>
> Yes. A core's frequency can depend on another one which
> will get switched as well (by one command/MSR).
> Compare with commit 6f4f2723d08534fd4e407e1e.
> 
> This can theoretically also be the case for sleep states.
> Afaik such HW does not exist yet, but ACPI spec already
> provides interfaces to pass these dependency from BIOS to OS.
> -> We want a stable ABI and should be prepared for such stuff.
> 
> > > + ),
> > > +
> > > + TP_fast_assign(
> > > + __entry->state = state;
> > > + __entry->cpu_id = cpu_id;
> > > + ),
> > > +
> > > + TP_printk("state=%lu cpu_id=%lu", (unsigned long)__entry->state,
> > > +   (unsigned long)__entry->cpu_id)
> > > +);
> > > +
> > > +DEFINE_EVENT(processor, processor_idle,
> > > +
> > > + TP_PROTO(unsigned int state, unsigned int cpu_id),
> > > +
> > > +  TP_ARGS(state, cpu_id)
> > > +);
> > > +
> > > +#define PWR_EVENT_EXIT 0x
> > > +
> > > +DEFINE_EVENT(processor, processor_frequency,
> > > +
> > > + TP_PROTO(unsigned int frequency, unsigned int cpu_id),
> > > +
> > > + TP_ARGS(frequency, cpu_id)
> > > +);
> > 
> > So, we have a 'state' field in the class, which is used as 'state' by the 
> > power::cpu_idle event, and as 'frequency' by the power::cpu_freq event?
>
> Yes, is this a problem?
>
> Definitions are a bit shorter having one power processor class.
> As "frequency" is stated in frequency event definition everything should
> be obvious and this one looks like the more elegant way to me.
>  
> > Are there any architectures that track frequency in Hz, not in kHz? If yes, 
> > might 
> > there ever be a need for the frequency value to be larger than 4.29 GHz? If 
> > yes, 
> > then it wont fit into u32.
>
> drivers/cpufreq subsystem is fixed to unsigned int (cmp. 
> include/linux/cpufreq.h):
> unsigned intmin;/* in kHz */
> unsigned intmax;/* in kHz */
> unsigned intcur;/* in kHz,
> ...
> that should be fine.

ok, good - so we should be fine up to 4 THz CPUs.

> > Also, might there be a future need to express different types of 
> > frequencies? 
> > For example, should we decide to track turbo frequencies in Intel CPUs, how 
> > would that be expressed via these events? Are there any architectures and 
> > CPUs 
> > that somehow have some extra attribute to the frequency value?
>
> I wonder whether this ever can/will work in a sane way.
> Userspace can compare with:
> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
> everything above is turbo. So I do not think it's ever needed.
> But adding an additional value at the end does not v

Re: [PATCH v2 08/11] OMAP4: Adding dev atrributes to OMAP4 smartreflex hwmod data

[Cousson, Benoit]

On 9/25/2010 2:51 PM, Gopinath, Thara wrote:

This patch adds dev attributes for smartreflex modules
in the OMAP4 hwmod database. This patch also updates the
smartreflex rev in the smartreflex class data structure
in the OMAP4 hwmod database.

Signed-off-by: Thara Gopinath
---
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   56 
  arch/arm/plat-omap/include/plat/control.h  |   12 ++
  2 files changed, 68 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 ba3c215..82657b5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,8 @@

  #include
  #include
+#include
+#include

  #include "omap_hwmod_common_data.h"

@@ -474,6 +476,7 @@ static struct omap_hwmod_class_sysconfig 
omap44xx_smartreflex_sysc = {
  static struct omap_hwmod_class omap44xx_smartreflex_hwmod_class = {
.name = "smartreflex",
.sysc =&omap44xx_smartreflex_sysc,
+   .rev  = 2,
  };

  /* smartreflex_core */
@@ -505,6 +508,22 @@ static struct omap_hwmod_ocp_if 
*omap44xx_smartreflex_core_slaves[] = {
&omap44xx_l4_cfg__smartreflex_core,
  };

+static u32 omap44xx_sr_core_efuse_offs[] = {
+   OMAP44XX_CONTROL_FUSE_CORE_OPP50, OMAP44XX_CONTROL_FUSE_CORE_OPP100,
+};
+
+static u32 omap44xx_sr_core_test_nvalues[] = {
+   0x0, 0x0
+};


At first, I thought it was a good idea to put such data here, but now 
after the discussion about timer hwmod data, I realize I was wrong.


These informations belong to omap_volt_data. For each OPP you should 
provide the efuse offset an the SW nvalues.
BTW, you should not call them test Nvalues, these are perfectly valid 
and can be potentially used in production. There are just not as 
optimized as a efuse Nvalue.


Benoit



+
+static struct omap_sr_dev_data omap44xx_sr_core_dev_attr = {
+   .efuse_nvalues_offs = omap44xx_sr_core_efuse_offs,
+   .test_sennenable= 0x1,
+   .test_senpenable= 0x1,
+   .test_nvalues   = omap44xx_sr_core_test_nvalues,
+   .vdd_name   = "core"
+};
+
  static struct omap_hwmod omap44xx_smartreflex_core_hwmod = {
.name   = "smartreflex_core",
.class  =&omap44xx_smartreflex_hwmod_class,
@@ -518,6 +537,7 @@ static struct omap_hwmod omap44xx_smartreflex_core_hwmod = {
},
.slaves = omap44xx_smartreflex_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_smartreflex_core_slaves),
+   .dev_attr   =&omap44xx_sr_core_dev_attr,
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
  };

@@ -550,6 +570,23 @@ static struct omap_hwmod_ocp_if 
*omap44xx_smartreflex_iva_slaves[] = {
&omap44xx_l4_cfg__smartreflex_iva,
  };

+static u32 omap44xx_sr_iva_efuse_offs[] = {
+   OMAP44XX_CONTROL_FUSE_IVA_OPP50, OMAP44XX_CONTROL_FUSE_IVA_OPP100,
+   OMAP44XX_CONTROL_FUSE_IVA_OPPTURBO,
+};
+
+static u32 omap44xx_sr_iva_test_nvalues[] = {
+   0x0, 0x0, 0x0, 0x0
+};
+
+static struct omap_sr_dev_data omap44xx_sr_iva_dev_attr = {
+   .efuse_nvalues_offs = omap44xx_sr_iva_efuse_offs,
+   .test_sennenable= 0x1,
+   .test_senpenable= 0x1,
+   .test_nvalues   = omap44xx_sr_iva_test_nvalues,
+   .vdd_name   = "iva"
+};
+
  static struct omap_hwmod omap44xx_smartreflex_iva_hwmod = {
.name   = "smartreflex_iva",
.class  =&omap44xx_smartreflex_hwmod_class,
@@ -563,6 +600,7 @@ static struct omap_hwmod omap44xx_smartreflex_iva_hwmod = {
},
.slaves = omap44xx_smartreflex_iva_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_smartreflex_iva_slaves),
+   .dev_attr   =&omap44xx_sr_iva_dev_attr,
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
  };

@@ -595,6 +633,23 @@ static struct omap_hwmod_ocp_if 
*omap44xx_smartreflex_mpu_slaves[] = {
&omap44xx_l4_cfg__smartreflex_mpu,
  };

+static u32 omap44xx_sr_mpu_efuse_offs[] = {
+   OMAP44XX_CONTROL_FUSE_MPU_OPP50, OMAP44XX_CONTROL_FUSE_MPU_OPP100,
+   OMAP44XX_CONTROL_FUSE_MPU_OPPTURBO, OMAP44XX_CONTROL_FUSE_MPU_OPPNITRO,
+};
+
+static u32 omap44xx_sr_mpu_test_nvalues[] = {
+   0x0, 0x0, 0x0, 0x0
+};
+
+static struct omap_sr_dev_data omap44xx_sr_mpu_dev_attr = {
+   .efuse_nvalues_offs = omap44xx_sr_mpu_efuse_offs,
+   .test_sennenable= 0x1,
+   .test_senpenable= 0x1,
+   .test_nvalues   = omap44xx_sr_mpu_test_nvalues,
+   .vdd_name   = "mpu"
+};
+
  static struct omap_hwmod omap44xx_smartreflex_mpu_hwmod = {
.name   = "smartreflex_mpu",
.class  =&omap44xx_smartreflex_hwmod_class,
@@ -608,6 +663,7 @@ static struct omap_hwmod omap44xx_smartreflex_mpu_hwmod = {
},
.slaves = omap44xx_smartreflex_mpu_slaves,
.slaves_cnt = ARRAY_SIZE(om

Re: [PATCH v2 08/11] OMAP4: Adding dev atrributes to OMAP4 smartreflex hwmod data

[Cousson, Benoit]

Hi Kevin,

Sorry for that late reply, I missed that email a little bit.

On 10/14/2010 8:56 PM, Kevin Hilman wrote:

On Sat, 2010-09-25 at 18:21 +0530, Thara Gopinath wrote:

diff --git a/arch/arm/plat-omap/include/plat/control.h
b/arch/arm/plat-omap/include/plat/control.h
index 042eb6e..1e8f6ec 100644
--- a/arch/arm/plat-omap/include/plat/control.h
+++ b/arch/arm/plat-omap/include/plat/control.h
@@ -181,6 +181,18 @@
  #define OMAP3630_CONTROL_FUSE_OPP50_VDD2
(OMAP2_CONTROL_GENERAL + 0x0128)
  #define OMAP3630_CONTROL_FUSE_OPP100_VDD2
(OMAP2_CONTROL_GENERAL + 0x012C)

+/* 44xx control efuse offsets */
+#define OMAP44XX_CONTROL_FUSE_IVA_OPP500x22C
+#define OMAP44XX_CONTROL_FUSE_IVA_OPP100   0x22F
+#define OMAP44XX_CONTROL_FUSE_IVA_OPPTURBO 0x232
+#define OMAP44XX_CONTROL_FUSE_IVA_OPPNITRO 0x235
+#define OMAP44XX_CONTROL_FUSE_MPU_OPP500x240
+#define OMAP44XX_CONTROL_FUSE_MPU_OPP100   0x243
+#define OMAP44XX_CONTROL_FUSE_MPU_OPPTURBO 0x246
+#define OMAP44XX_CONTROL_FUSE_MPU_OPPNITRO 0x249
+#define OMAP44XX_CONTROL_FUSE_CORE_OPP50   0x254
+#define OMAP44XX_CONTROL_FUSE_CORE_OPP100  0x257
+


These names are not consistent with the TRM (ES2.x NDA TRM vL).  e.g.
rather than MPU_OPP50, OPP1, the TRM has MPU_0, MPU_1.  However, the
TRM is confusing here too since the register names are MPU_0,
MPU_1, etc. but the field names in the register descriptions use
OPP50, OPP100, etc.  What a mess.  We need a consistent naming for these.

Benoit?


It is indeed a mess... these names are the latest ones used in the HW 
spec. But we are still wondering how to name that in the future.
OPP_LOW, OPP_MID, OPP_HIGH, OPP_TURBO and OPP_NITRO are now considered 
but I'm not sure it is really better.


Honestly I do prefer the OPP50, OPP100, OPP130, OPP166 that are 
providing the percentage wrt nominal frequency and that can scale 
easily. If we do introduce a OPP between OPP_MID and OPP_HIGH, I'm not 
sure anybody will be able to find a proper name whereas OPP_80 is 
straightforward.


In anycase, that will never match the HW spec or the TRM :-(

Benoit



Also, based on the TRM, the offsets here don't look quite right.
e.g. there is no MPU OPP at 0x240, so the OMAP4 the code reading these is
using reserved/undocumented bits for the first OPP.

Also, the single byte offsets here could use a better explanation, not
necessarily here but in the omap4 code that reads the nvalues.  I expected that 
these
would be single byte aligned to compact the address space and remove some unused
space, but no, they seem to be arbitrarily shifted around.

Kevin




--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Thomas Renninger]

On Tuesday 26 October 2010 09:10:20 Ingo Molnar wrote:
> 
> * Thomas Renninger  wrote:
> 
> > Changes in V2:
> >   - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
> >   - Use u32 instead of u64 for cpuid, state which is by far enough
> > 
> > New power trace events:
> > power:processor_idle
> > power:processor_frequency
> > power:machine_suspend
> > 
> > 
> > C-state/idle accounting events:
> >   power:power_start
> >   power:power_end
> > are replaced with:
> >   power:processor_idle
> > 
> > and
> >   power:power_frequency
> > is replaced with:
> >   power:processor_frequency
> 
> Could you please name it power:cpu_idle and power:cpu_frequency instead, for 
> shortness? We generally use 'cpu' in the kernel and for events.
Sure.
> 
> > power:machine_suspend
> 
> How will future PCI (or other device) power saving tracepoints be called?
> 
> Might be more consistent to use:
> 
>   power:cpu_idle
>   power:machine_idle
>   power:device_idle
device idle is not true. Those may be low power modes
like reduced network throughput, reduced wlan range, the device
needs not to be idle.
Device power states is probably the most complex area, if such
a thing gets introduced, it should makes sense to state
the interface experimental for some time until a wider range of
devices uses it (in contrast to these new ones
which should not change that soon anymore...).

Also machine_idle may be true, but machine_suspend sounds more
familiar and everyone immediately knows what the event is about.

-> *_idle convention is not really worth it.

> Where machine_idle is the suspend event.
Here you name it. You talk about machine_idle but you mean
the suspend event, better just name it what it is.

> > the type= field got removed from both, it was never
> > used and the type is differed by the event type itself.
> >
> > +#define PWR_EVENT_EXIT 0x
> 
> Shouldnt this be part of the POWER_ enum? (and you can write -1 there)
No, below enum will vanish, but -1 is nicer.

...

> Plus:
> 
> > +DECLARE_EVENT_CLASS(processor,
> > +
> > +   TP_PROTO(unsigned int state, unsigned int cpu_id),
> > +
> > +   TP_ARGS(state, cpu_id),
> > +
> > +   TP_STRUCT__entry(
> > +   __field(u32,state   )
> > +   __field(u32,cpu_id  )
> 
> Trace entries can carry a cpu_id of the current processor already. Can this 
> cpu_id 
> ever be different from that CPU id?
Yes. A core's frequency can depend on another one which
will get switched as well (by one command/MSR).
Compare with commit 6f4f2723d08534fd4e407e1e.

This can theoretically also be the case for sleep states.
Afaik such HW does not exist yet, but ACPI spec already
provides interfaces to pass these dependency from BIOS to OS.
-> We want a stable ABI and should be prepared for such stuff.

> > +   ),
> > +
> > +   TP_fast_assign(
> > +   __entry->state = state;
> > +   __entry->cpu_id = cpu_id;
> > +   ),
> > +
> > +   TP_printk("state=%lu cpu_id=%lu", (unsigned long)__entry->state,
> > + (unsigned long)__entry->cpu_id)
> > +);
> > +
> > +DEFINE_EVENT(processor, processor_idle,
> > +
> > +   TP_PROTO(unsigned int state, unsigned int cpu_id),
> > +
> > +TP_ARGS(state, cpu_id)
> > +);
> > +
> > +#define PWR_EVENT_EXIT 0x
> > +
> > +DEFINE_EVENT(processor, processor_frequency,
> > +
> > +   TP_PROTO(unsigned int frequency, unsigned int cpu_id),
> > +
> > +   TP_ARGS(frequency, cpu_id)
> > +);
> 
> So, we have a 'state' field in the class, which is used as 'state' by the 
> power::cpu_idle event, and as 'frequency' by the power::cpu_freq event?
Yes, is this a problem?
Definitions are a bit shorter having one power processor class.
As "frequency" is stated in frequency event definition everything should
be obvious and this one looks like the more elegant way to me.
 
> Are there any architectures that track frequency in Hz, not in kHz? If yes, 
> might 
> there ever be a need for the frequency value to be larger than 4.29 GHz? If 
> yes, 
> then it wont fit into u32.
drivers/cpufreq subsystem is fixed to unsigned int (cmp. 
include/linux/cpufreq.h):
unsigned intmin;/* in kHz */
unsigned intmax;/* in kHz */
unsigned intcur;/* in kHz,
...
that should be fine.

> Also, might there be a future need to express different types of frequencies? 
> For 
> example, should we decide to track turbo frequencies in Intel CPUs, how would 
> that 
> be expressed via these events? Are there any architectures and CPUs that 
> somehow 
> have some extra attribute to the frequency value?
I wonder whether this ever can/will work in a sane way.
Userspace can compare with:
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
everything above is turbo. So I do not think it's ever needed.
But adding an additional value at the end does not violate
userspace compatibility. This has been done with the cpuid
as well.
 
>

Re: [PATCH 1/1] mtd: OneNAND: fix bufferram management when chip has 2-planes.

[Kyungmin Park]

On Tue, Oct 26, 2010 at 6:36 PM, Artem Bityutskiy
 wrote:
> On Sat, 2010-10-23 at 15:43 +0200, Enric Balletbo i Serra wrote:
>> This patch adds code that I think was lost when it was applied the commit
>>   5988af2319781bc8e0ce418affec4e09cfa77907 - mtd: Flex-OneNAND support
>>
>> Test case:
>>  1. Stress a jffs2 filesystem using
>>     bonnie++ -u 0:0 -s 32 -m 16 -r 16
>>  2. dmesg shows various 'Header CRC failed' errors like:
>>     Header CRC failed on REF_PRISTINE node at 0x1e81315c: Read 0x00e0,
>>     calculated 0x564fc9e8
>>
>> Tested on IGEP v2 board with a Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
>> with 2 planes from Numonyx and CONFIG_MTD_ONENAND_2X_PROGRAM set to y
>>
>> Signed-off-by: Enric Balletbo i Serra 
>
> Kyungmin, would be nice to have your ack/nack.
Sorry for late reply

One more check, it seems to use the invalidate instead of update bufferram.
In case of 2X PROGRAM, it always uses the BUFFERRAM0 so invalidate
another bufferram.

Don't set the bufferram index.

Thank you,
Kyungmin Park
>
> --
> Best Regards,
> Artem Bityutskiy (Артём Битюцкий)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Ingo Molnar]

* Arjan van de Ven  wrote:

> On 10/26/2010 12:10 AM, Ingo Molnar wrote:
> >+
> >>+   TP_STRUCT__entry(
> >>+   __field(u32,state   )
> >>+   __field(u32,cpu_id  )
> >Trace entries can carry a cpu_id of the current processor already. Can this 
> >cpu_id
> >ever be different from that CPU id?
> 
> yes
> 
> esp cpu frequency you can change cross cpu
> 
> originally we did not have this in the API but Thomas added it for that 
> reason 
> some time ago.

Ok, good! Maybe add this as a comment?

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 12/14] drivers/video/omap/blizzard.c: delete double assignment

[Julia Lawall]

From: Julia Lawall 

Delete successive assignments to the same location.  Initialize the out_y
field as well as the out_x field, rather than initializing the out_x field
twice.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression i;
@@

*i = ...;
 i = ...;
// 

Signed-off-by: Julia Lawall 

---
This changes the semantics and has not been tested.

 drivers/video/omap/blizzard.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/omap/blizzard.c b/drivers/video/omap/blizzard.c
index 2ffb34a..87785c2 100644
--- a/drivers/video/omap/blizzard.c
+++ b/drivers/video/omap/blizzard.c
@@ -1590,7 +1590,7 @@ static int blizzard_init(struct omapfb_device *fbdev, int 
ext_mode,
blizzard.auto_update_window.width = fbdev->panel->x_res;
blizzard.auto_update_window.height = fbdev->panel->y_res;
blizzard.auto_update_window.out_x = 0;
-   blizzard.auto_update_window.out_x = 0;
+   blizzard.auto_update_window.out_y = 0;
blizzard.auto_update_window.out_width = fbdev->panel->x_res;
blizzard.auto_update_window.out_height = fbdev->panel->y_res;
blizzard.auto_update_window.format = 0;

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Arjan van de Ven]

On 10/26/2010 12:10 AM, Ingo Molnar wrote:

+

+   TP_STRUCT__entry(
+   __field(u32,state   )
+   __field(u32,cpu_id  )

Trace entries can carry a cpu_id of the current processor already. Can this 
cpu_id
ever be different from that CPU id?


yes

esp cpu frequency you can change cross cpu

originally we did not have this in the API but Thomas added it for that 
reason some time ago.


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] mtd: OneNAND: fix bufferram management when chip has 2-planes.

[Artem Bityutskiy]

On Sat, 2010-10-23 at 15:43 +0200, Enric Balletbo i Serra wrote:
> This patch adds code that I think was lost when it was applied the commit
>   5988af2319781bc8e0ce418affec4e09cfa77907 - mtd: Flex-OneNAND support
> 
> Test case:
>  1. Stress a jffs2 filesystem using
> bonnie++ -u 0:0 -s 32 -m 16 -r 16
>  2. dmesg shows various 'Header CRC failed' errors like:
> Header CRC failed on REF_PRISTINE node at 0x1e81315c: Read 0x00e0,
> calculated 0x564fc9e8
> 
> Tested on IGEP v2 board with a Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
> with 2 planes from Numonyx and CONFIG_MTD_ONENAND_2X_PROGRAM set to y
> 
> Signed-off-by: Enric Balletbo i Serra 

Kyungmin, would be nice to have your ack/nack.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [GIT PULL] omap DSS changes for 2.6.27

[Tomi Valkeinen]

Hi,

Oo-ops. Right, the pull request is for 2.6.37. Missed the key, there...

 Tomi

On Tue, 2010-10-26 at 10:14 +0200, ext Shilimkar, Santosh wrote:
> Tomi,
> Did you mean '[GIT PULL] omap DSS changes for 2.6.37' and 
> not '[GIT PULL] omap DSS changes for 2.6.27'? 
> 
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Tomi Valkeinen
> > Sent: Tuesday, October 26, 2010 1:24 PM
> > To: Linus Torvalds
> > Cc: linux-kernel; linux-omap@vger.kernel.org; ext Tony Lindgren
> > Subject: [GIT PULL] omap DSS changes for 2.6.27
> > 
> > Hi Linus,
> > 
> > Please pull OMAP display subsystem changes:
> > 
> > 
> > The following changes since commit
> > 899611ee7d373e5eeda08e9a8632684e1ebbbf00:
> > 
> >   Linux 2.6.36-rc6 (2010-09-28 18:01:22 -0700)
> > 
> > are available in the git repository at:
> >   git://gitorious.org/linux-omap-dss2/linux.git for-linus
> > 
> > Archit Taneja (2):
> >   OMAP: DSS2: Introduce dss_features files
> >   OMAP: DSS2: Use dss_features framework on DSS2 code
> > 
> > Grazvydas Ignotas (1):
> >   OMAP: DSS2: make filter coefficient tables human readable
> > 
> > Jarkko Nikula (1):
> >   OMAP: DSS2: Add SPI dependency to Kconfig of ACX565AKM panel
> > 
> > Nicolas Kaiser (2):
> >   video/omap: remove mux.h include
> >   arm/omap: simplify conditional
> > 
> > Senthilvadivu Guruswamy (4):
> >   OMAP: DSS2: DSI: Remove extra iounmap in error path
> >   OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB
> >   OMAP: DSS2: OMAPFB: make VRFB depends on OMAP2,3
> >   OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3
> > 
> > Stanley.Miao (1):
> >   OMAP: DSS2: don't power off a panel twice
> > 
> > Tasslehoff Kjappfot (1):
> >   OMAP: DSS2: OMAPFB: swap front and back porches for both hsync and
> > vsync
> > 
> > Uwe Kleine-König (3):
> >   ARM: omap/fb: move omap_init_fb to .init.text
> >   ARM: omap/fb: move omapfb_reserve_sram to .init.text
> >   ARM: omap/fb: move get_fbmem_region() to .init.text
> > 
> >  arch/arm/plat-omap/fb.c|   14 +-
> >  arch/arm/plat-omap/include/plat/display.h  |   31 ---
> >  arch/arm/plat-omap/include/plat/vrfb.h |   16 ++
> >  drivers/video/omap/lcd_omap3beagle.c   |2 -
> >  drivers/video/omap2/displays/Kconfig   |2 +-
> >  drivers/video/omap2/displays/panel-acx565akm.c |6 +
> >  drivers/video/omap2/displays/panel-generic.c   |6 +
> >  .../video/omap2/displays/panel-sharp-lq043t1dg01.c |6 +
> >  .../video/omap2/displays/panel-sharp-ls037v7dw01.c |6 +
> >  .../video/omap2/displays/panel-toppoly-tdo35s.c|6 +
> >  .../video/omap2/displays/panel-tpo-td043mtea1.c|6 +
> >  drivers/video/omap2/dss/Makefile   |2 +-
> >  drivers/video/omap2/dss/core.c |3 +
> >  drivers/video/omap2/dss/dispc.c|  270 +--
> > -
> >  drivers/video/omap2/dss/dsi.c  |1 -
> >  drivers/video/omap2/dss/dss_features.c |  191 ++
> >  drivers/video/omap2/dss/dss_features.h |   50 
> >  drivers/video/omap2/dss/manager.c  |   33 ++--
> >  drivers/video/omap2/dss/overlay.c  |   24 +-
> >  drivers/video/omap2/omapfb/Kconfig |2 +-
> >  drivers/video/omap2/omapfb/omapfb-main.c   |   26 ++-
> >  21 files changed, 475 insertions(+), 228 deletions(-)
> >  create mode 100644 drivers/video/omap2/dss/dss_features.c
> >  create mode 100644 drivers/video/omap2/dss/dss_features.h
> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [GIT PULL] omap DSS changes for 2.6.27

[Shilimkar, Santosh]

Tomi,
Did you mean '[GIT PULL] omap DSS changes for 2.6.37' and 
not '[GIT PULL] omap DSS changes for 2.6.27'? 

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Tomi Valkeinen
> Sent: Tuesday, October 26, 2010 1:24 PM
> To: Linus Torvalds
> Cc: linux-kernel; linux-omap@vger.kernel.org; ext Tony Lindgren
> Subject: [GIT PULL] omap DSS changes for 2.6.27
> 
> Hi Linus,
> 
> Please pull OMAP display subsystem changes:
> 
> 
> The following changes since commit
> 899611ee7d373e5eeda08e9a8632684e1ebbbf00:
> 
>   Linux 2.6.36-rc6 (2010-09-28 18:01:22 -0700)
> 
> are available in the git repository at:
>   git://gitorious.org/linux-omap-dss2/linux.git for-linus
> 
> Archit Taneja (2):
>   OMAP: DSS2: Introduce dss_features files
>   OMAP: DSS2: Use dss_features framework on DSS2 code
> 
> Grazvydas Ignotas (1):
>   OMAP: DSS2: make filter coefficient tables human readable
> 
> Jarkko Nikula (1):
>   OMAP: DSS2: Add SPI dependency to Kconfig of ACX565AKM panel
> 
> Nicolas Kaiser (2):
>   video/omap: remove mux.h include
>   arm/omap: simplify conditional
> 
> Senthilvadivu Guruswamy (4):
>   OMAP: DSS2: DSI: Remove extra iounmap in error path
>   OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB
>   OMAP: DSS2: OMAPFB: make VRFB depends on OMAP2,3
>   OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3
> 
> Stanley.Miao (1):
>   OMAP: DSS2: don't power off a panel twice
> 
> Tasslehoff Kjappfot (1):
>   OMAP: DSS2: OMAPFB: swap front and back porches for both hsync and
> vsync
> 
> Uwe Kleine-König (3):
>   ARM: omap/fb: move omap_init_fb to .init.text
>   ARM: omap/fb: move omapfb_reserve_sram to .init.text
>   ARM: omap/fb: move get_fbmem_region() to .init.text
> 
>  arch/arm/plat-omap/fb.c|   14 +-
>  arch/arm/plat-omap/include/plat/display.h  |   31 ---
>  arch/arm/plat-omap/include/plat/vrfb.h |   16 ++
>  drivers/video/omap/lcd_omap3beagle.c   |2 -
>  drivers/video/omap2/displays/Kconfig   |2 +-
>  drivers/video/omap2/displays/panel-acx565akm.c |6 +
>  drivers/video/omap2/displays/panel-generic.c   |6 +
>  .../video/omap2/displays/panel-sharp-lq043t1dg01.c |6 +
>  .../video/omap2/displays/panel-sharp-ls037v7dw01.c |6 +
>  .../video/omap2/displays/panel-toppoly-tdo35s.c|6 +
>  .../video/omap2/displays/panel-tpo-td043mtea1.c|6 +
>  drivers/video/omap2/dss/Makefile   |2 +-
>  drivers/video/omap2/dss/core.c |3 +
>  drivers/video/omap2/dss/dispc.c|  270 +--
> -
>  drivers/video/omap2/dss/dsi.c  |1 -
>  drivers/video/omap2/dss/dss_features.c |  191 ++
>  drivers/video/omap2/dss/dss_features.h |   50 
>  drivers/video/omap2/dss/manager.c  |   33 ++--
>  drivers/video/omap2/dss/overlay.c  |   24 +-
>  drivers/video/omap2/omapfb/Kconfig |2 +-
>  drivers/video/omap2/omapfb/omapfb-main.c   |   26 ++-
>  21 files changed, 475 insertions(+), 228 deletions(-)
>  create mode 100644 drivers/video/omap2/dss/dss_features.c
>  create mode 100644 drivers/video/omap2/dss/dss_features.h
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Jean Pihet]

Ingo,

On Tue, Oct 26, 2010 at 9:10 AM, Ingo Molnar  wrote:
>
> * Thomas Renninger  wrote:
>
>> Changes in V2:
>>   - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
>>   - Use u32 instead of u64 for cpuid, state which is by far enough

...

>>
>> +#define PWR_EVENT_EXIT 0x
>
> Shouldnt this be part of the POWER_ enum? (and you can write -1 there)
>
>> +#ifndef _TRACE_POWER_ENUM_
>> +#define _TRACE_POWER_ENUM_
>> +enum {
>> +     POWER_NONE = 0,
>> +     POWER_CSTATE = 1,
>> +     POWER_PSTATE = 2,
>> +};
>> +#endif
>
> Since we are cleaning up all these events, those enum definitions dont really 
> look
> logical. For example, what is 'POWER_NONE'? Can a CPU have 'no power'?
The enum belongs to the deprecated API so I would rather not touch it.
Keeping the deprecated code isolated will make it easier to remove
later.

>
> Plus:
>
>> +DECLARE_EVENT_CLASS(processor,
>> +
>> +     TP_PROTO(unsigned int state, unsigned int cpu_id),
>> +
>> +     TP_ARGS(state, cpu_id),
>> +
>> +     TP_STRUCT__entry(
>> +             __field(        u32,            state           )
>> +             __field(        u32,            cpu_id          )
>
> Trace entries can carry a cpu_id of the current processor already. Can this 
> cpu_id
> ever be different from that CPU id?
I have no evidence of that (powr mgt on SMP ARM is coming real
soon...) but one can imagine one of the CPUs being the master for PM
decisions.

>
>> +     ),
>> +
>> +     TP_fast_assign(
>> +             __entry->state = state;
>> +             __entry->cpu_id = cpu_id;
>> +     ),
>> +
>> +     TP_printk("state=%lu cpu_id=%lu", (unsigned long)__entry->state,
>> +               (unsigned long)__entry->cpu_id)
>> +);
>> +
>> +DEFINE_EVENT(processor, processor_idle,
>> +
>> +     TP_PROTO(unsigned int state, unsigned int cpu_id),
>> +
>> +          TP_ARGS(state, cpu_id)
>> +);
>> +
>> +#define PWR_EVENT_EXIT 0x
>> +
>> +DEFINE_EVENT(processor, processor_frequency,
>> +
>> +     TP_PROTO(unsigned int frequency, unsigned int cpu_id),
>> +
>> +     TP_ARGS(frequency, cpu_id)
>> +);
>
> So, we have a 'state' field in the class, which is used as 'state' by the
> power::cpu_idle event, and as 'frequency' by the power::cpu_freq event?
>
> Are there any architectures that track frequency in Hz, not in kHz? If yes, 
> might
> there ever be a need for the frequency value to be larger than 4.29 GHz? If 
> yes,
> then it wont fit into u32.
>
> Also, might there be a future need to express different types of frequencies? 
> For
> example, should we decide to track turbo frequencies in Intel CPUs, how would 
> that
> be expressed via these events? Are there any architectures and CPUs that 
> somehow
> have some extra attribute to the frequency value?
>
>> +TRACE_EVENT(machine_suspend,
>> +
>> +     TP_PROTO(unsigned int state),
>> +
>> +     TP_ARGS(state),
>> +
>> +     TP_STRUCT__entry(
>> +             __field(        u32,            state           )
>> +     ),
>
> Hm, this event is not used anywhere in the submitted patches. Where is the 
> patch
> that adds usage, and what are the possible values for 'state'?
This will come as a separate patch, which fits all platforms. Cf.
http://marc.info/?l=linux-omap&m=128620575300682&w=2.
The state field is of type suspend_state_t, cf. include/linux/suspend.h
>
>        Ingo
>

Jean
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PERF(kernel): Cleanup power events V2

[Jean Pihet]

On Tue, Oct 26, 2010 at 1:33 AM, Thomas Renninger  wrote:
> Changes in V2:
>  - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
>  - Use u32 instead of u64 for cpuid, state which is by far enough
>
> New power trace events:
> power:processor_idle
> power:processor_frequency
> power:machine_suspend
>
>
> C-state/idle accounting events:
>  power:power_start
>  power:power_end
> are replaced with:
>  power:processor_idle
>
> and
>  power:power_frequency
> is replaced with:
>  power:processor_frequency
>
> power:machine_suspend
> is newly introduced, a first implementation
> comes from the ARM side, but it's easy to add these events
> in X86 as well if needed.
This will come as a separate patch, which fits all platforms. Cf.
http://marc.info/?l=linux-omap&m=128620575300682&w=2.

...

> @@ -481,10 +484,12 @@ static void mwait_idle(void)
>  static void poll_idle(void)
>  {
>        trace_power_start(POWER_CSTATE, 0, smp_processor_id());
> +   trace_processor_idle(1, smp_processor_id());

Should that be:
+   trace_processor_idle(0, smp_processor_id());
instead?
Since state '0' is for the CPU active in polling mode and
PWR_EVENT_EXIT means 'exit from any idle state'.

>        local_irq_enable();
>        while (!need_resched())
>                cpu_relax();
> -       trace_power_end(0);
> +       trace_power_end(smp_processor_id());
> +       trace_processor_idle(PWR_EVENT_EXIT, smp_processor_id());
>  }
>
>  /*

...

> diff --git a/include/trace/events/power.h b/include/trace/events/power.h
...

Regards,
Jean
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] omap DSS changes for 2.6.27

[Tomi Valkeinen]

Hi Linus,

Please pull OMAP display subsystem changes:


The following changes since commit 899611ee7d373e5eeda08e9a8632684e1ebbbf00:

  Linux 2.6.36-rc6 (2010-09-28 18:01:22 -0700)

are available in the git repository at:
  git://gitorious.org/linux-omap-dss2/linux.git for-linus

Archit Taneja (2):
  OMAP: DSS2: Introduce dss_features files
  OMAP: DSS2: Use dss_features framework on DSS2 code

Grazvydas Ignotas (1):
  OMAP: DSS2: make filter coefficient tables human readable

Jarkko Nikula (1):
  OMAP: DSS2: Add SPI dependency to Kconfig of ACX565AKM panel

Nicolas Kaiser (2):
  video/omap: remove mux.h include
  arm/omap: simplify conditional

Senthilvadivu Guruswamy (4):
  OMAP: DSS2: DSI: Remove extra iounmap in error path
  OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB
  OMAP: DSS2: OMAPFB: make VRFB depends on OMAP2,3
  OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3

Stanley.Miao (1):
  OMAP: DSS2: don't power off a panel twice

Tasslehoff Kjappfot (1):
  OMAP: DSS2: OMAPFB: swap front and back porches for both hsync and vsync

Uwe Kleine-König (3):
  ARM: omap/fb: move omap_init_fb to .init.text
  ARM: omap/fb: move omapfb_reserve_sram to .init.text
  ARM: omap/fb: move get_fbmem_region() to .init.text

 arch/arm/plat-omap/fb.c|   14 +-
 arch/arm/plat-omap/include/plat/display.h  |   31 ---
 arch/arm/plat-omap/include/plat/vrfb.h |   16 ++
 drivers/video/omap/lcd_omap3beagle.c   |2 -
 drivers/video/omap2/displays/Kconfig   |2 +-
 drivers/video/omap2/displays/panel-acx565akm.c |6 +
 drivers/video/omap2/displays/panel-generic.c   |6 +
 .../video/omap2/displays/panel-sharp-lq043t1dg01.c |6 +
 .../video/omap2/displays/panel-sharp-ls037v7dw01.c |6 +
 .../video/omap2/displays/panel-toppoly-tdo35s.c|6 +
 .../video/omap2/displays/panel-tpo-td043mtea1.c|6 +
 drivers/video/omap2/dss/Makefile   |2 +-
 drivers/video/omap2/dss/core.c |3 +
 drivers/video/omap2/dss/dispc.c|  270 +---
 drivers/video/omap2/dss/dsi.c  |1 -
 drivers/video/omap2/dss/dss_features.c |  191 ++
 drivers/video/omap2/dss/dss_features.h |   50 
 drivers/video/omap2/dss/manager.c  |   33 ++--
 drivers/video/omap2/dss/overlay.c  |   24 +-
 drivers/video/omap2/omapfb/Kconfig |2 +-
 drivers/video/omap2/omapfb/omapfb-main.c   |   26 ++-
 21 files changed, 475 insertions(+), 228 deletions(-)
 create mode 100644 drivers/video/omap2/dss/dss_features.c
 create mode 100644 drivers/video/omap2/dss/dss_features.h


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html