Re: [RFC PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC

2012-09-21 Thread S, Venkatraman
On Fri, Sep 21, 2012 at 10:48 PM, Felipe Balbi  wrote:
> On Fri, Sep 21, 2012 at 10:47:30PM +0530, S, Venkatraman wrote:
>> On Fri, Sep 21, 2012 at 10:45 PM, S, Venkatraman  wrote:
>> > On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter  wrote:
>> >> The EDMA DMAC has a hardware limitation that prevents supporting
>> >> scatter gather lists with any number of segments. Since the EDMA
>> >> DMA Engine driver sets the maximum segments to 16, we do the
>> >> same.
>> >>
>> >> Note: this can be removed once the DMA Engine API supports an
>> >> API to query the DMAC's segment limitations.
>> >>
>> >
>> > I wouldn't want to bind the properties of EDMA to omap_hsmmc as this patch
>> > suggests. Why don't we have a max_segs property, which when explicitly 
>> > specified
>> > in DT, will override the default ?
>>
>> If you are adventurous, this can be a generic mmc DT binding instead
>> of restricting it to OMAP.
>
> I say if it's a limitation in the DMAC, then DMAC's driver should handle
> it, no ? Meaning that in this case you would copy from one multi-segment
> sg into a one-segment sg and when transfer is complete, before calling
> user's callback, copy data the other way around (?)
>

Right ! So even if the property is defined for MMC, Matt will end up coding the
limitation into every peripheral driver that uses EMAC, which doesn't scale.
Your solution is better.
--
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: [RFC PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC

2012-09-21 Thread S, Venkatraman
On Fri, Sep 21, 2012 at 10:45 PM, S, Venkatraman  wrote:
> On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter  wrote:
>> The EDMA DMAC has a hardware limitation that prevents supporting
>> scatter gather lists with any number of segments. Since the EDMA
>> DMA Engine driver sets the maximum segments to 16, we do the
>> same.
>>
>> Note: this can be removed once the DMA Engine API supports an
>> API to query the DMAC's segment limitations.
>>
>
> I wouldn't want to bind the properties of EDMA to omap_hsmmc as this patch
> suggests. Why don't we have a max_segs property, which when explicitly 
> specified
> in DT, will override the default ?

If you are adventurous, this can be a generic mmc DT binding instead
of restricting it to OMAP.
--
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: [RFC PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC

2012-09-21 Thread S, Venkatraman
On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter  wrote:
> The EDMA DMAC has a hardware limitation that prevents supporting
> scatter gather lists with any number of segments. Since the EDMA
> DMA Engine driver sets the maximum segments to 16, we do the
> same.
>
> Note: this can be removed once the DMA Engine API supports an
> API to query the DMAC's segment limitations.
>

I wouldn't want to bind the properties of EDMA to omap_hsmmc as this patch
suggests. Why don't we have a max_segs property, which when explicitly specified
in DT, will override the default ?
--
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] mmc: omap_hsmmc: fix max value of clkd

2012-09-21 Thread S, Venkatraman
On Fri, Sep 21, 2012 at 8:51 PM, Balaji T K  wrote:
> clock divisor can take a max value of 1023
> update code as per TRM so that card init can be handled with
> higher IP clock frequencies from which clock to the card is
> derived.
>
This is difficult to read without some punctuation / capitalization.

> Signed-off-by: Balaji T K 
> ---
>  drivers/mmc/host/omap_hsmmc.c |5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index d9af5f1..073b9ff 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -75,6 +75,7 @@
>  #define ICE0x1
>  #define ICS0x2
>  #define CEN(1 << 2)
> +#define CLKD_MAX   0x3FF

It'd be nice to have a comment on what 3FF stands for and it's
relation to clock in MHz.

>  #define CLKD_MASK  0xFFC0
>  #define CLKD_SHIFT 6
>  #define DTO_MASK   0x000F
> @@ -478,8 +479,8 @@ static u16 calc_divisor(struct omap_hsmmc_host *host, 
> struct mmc_ios *ios)
>
> if (ios->clock) {
> dsor = DIV_ROUND_UP(clk_get_rate(host->fclk), ios->clock);
> -   if (dsor > 250)
> -   dsor = 250;
> +   if (dsor > CLKD_MAX)
> +   dsor = CLKD_MAX;

Can these two lines be written in one line as
"dsor &= CLKD_MAX; " ?

> }
>
--
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] mmc: omap_hsmmc: Pass on the suspend failure to the PM core

2012-09-17 Thread S, Venkatraman
On Thu, Sep 13, 2012 at 12:01 PM, Hebbar, Gururaja
 wrote:
> From: Vaibhav Bedia 
>
> In some cases mmc_suspend_host() is not able to claim the
> host and proceed with the suspend process. The core returns
> -EBUSY to the host controller driver. Unfortunately, the
> host controller driver does not pass on this information
> to the PM core and hence the system suspend process continues.
>
> ret = mmc_suspend_host(host->mmc);
> if (ret) {
> host->suspended = 0;
> if (host->pdata->resume) {
> ret = host->pdata->resume(dev, host->slot_id);
>
> The return status from mmc_suspend_host() is overwritten by return
> status from host->pdata->resume. So the original return status is lost.
>
> In these cases the MMC core gets to an unexpected state
> during resume and multiple issues related to MMC crop up.
> 1. Host controller driver starts accessing the device registers
> before the clocks are enabled which leads to a prefetch abort.
> 2. A file copy thread which was launched before suspend gets
> stuck due to the host not being reclaimed during resume.
>
> To avoid such problems pass on the -EBUSY status to the PM core
> from the host controller driver. With this change, MMC core
> suspend might still fail but it does not end up making the
> system unusable. Suspend gets aborted and the user can try
> suspending the system again.
>
> Signed-off-by: Vaibhav Bedia 
> Signed-off-by: Hebbar, Gururaja 
This version is good.

Acked-by: Venkatraman S 

> ---
> Changes from V1:
> - Instead of forcibly returning -EBUSY on err, retain old
> status and pass on the same to the caller.
> - add more detail to commit message (explanation with code
> snippet)
>
> :100644 100644 9afdd20... d9af5f1... M  drivers/mmc/host/omap_hsmmc.c
>  drivers/mmc/host/omap_hsmmc.c |3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 9afdd20..d9af5f1 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2050,8 +2050,7 @@ static int omap_hsmmc_suspend(struct device *dev)
> if (ret) {
> host->suspended = 0;
> if (host->pdata->resume) {
> -   ret = host->pdata->resume(dev, host->slot_id);
> -   if (ret)
> +   if (host->pdata->resume(dev, host->slot_id))
> dev_dbg(dev, "Unmask interrupt failed\n");
> }
> goto err;
> --
> 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 3/4] drivers/mmc/host/omap_hsmmc.c: fix error return code

2012-09-17 Thread S, Venkatraman
On Mon, Sep 17, 2012 at 1:45 PM, Peter Senna Tschudin
 wrote:
> From: Peter Senna Tschudin 
>
> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // 
> (
> if@p1 (\(ret < 0\|ret != 0\))
>  { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
>   ... when != ret = e2
>   when forall
>  return ret;
> }
> // 
>
> Signed-off-by: Peter Senna Tschudin 

Looks good.
Acked-by: Venkatraman S 
--
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] mmc: omap_hsmmc: Enable HSPE bit for high speed cards

2012-09-12 Thread S, Venkatraman
On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja  wrote:
> HSMMC IP on AM33xx need a special setting to handle High-speed cards.
> Other platforms like TI81xx, OMAP4 may need this as-well. This depends
> on the HSMMC IP timing closure done for the high speed cards.
>
> From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
>
> The MMC/SD/SDIO output signals can be driven on either falling edge or
> rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
> to reach better timing performance, and thus to increase data transfer
> frequency.
>
> There are few pre-requisites for enabling the HSPE bit
> - Controller should support High-Speed-Enable Bit and
> - Controller should not be using DDR Mode and
> - Controller should advertise that it supports High Speed in
>   capabilities register and
> - MMC/SD clock coming out of controller > 25MHz
>

The patch is well written. But then, I don't see a need for a DT
binding for this feature.
By definition, HS implies 25MHz or above, so that check seems to be
redundant as well.
Meanwhile, I'll check with HSPE enabled on OMAP.

Regards,
Venkat.
--
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] mmc: omap_hsmmc: Pass on the suspend failure to the PM core

2012-09-10 Thread S, Venkatraman
On Tue, Sep 4, 2012 at 6:38 PM, Hebbar, Gururaja  wrote:
> From: Vaibhav Bedia 
>
> In some cases mmc_suspend_host() is not able to claim the
> host and proceed with the suspend process. The core returns
> -EBUSY to the host controller driver. Unfortunately, the
> host controller driver does not pass on this information
> to the PM core and hence the system suspend process continues.
>
> In these cases the MMC core gets to an unexpected state
> during resume and multiple issues related to MMC crop up.
> 1. Host controller driver starts accessing the device registers
> before the clocks are enabled which leads to a prefetch abort.
> 2. A file copy thread which was launched before suspend gets
> stuck due to the host not being reclaimed during resume.
>
> To avoid such problems pass on the -EBUSY status to the PM core
> from the host controller driver. With this change, MMC core
> suspend might still fail but it does not end up making the
> system unusable. Suspend gets aborted and the user can try
> suspending the system again.
>

The last time we discussed this, didn't we plan to fix this differently ?
Holding the return code of mmc_suspend_host in a separate variable and
passing it to the caller
of omap_hsmmc_suspend looks more sane to me.
--
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: [PATCHv2 1/2] mmc: omap_hsmmc: convert from IP timer to hrtimer

2012-09-09 Thread S, Venkatraman
On Sat, Sep 8, 2012 at 3:29 AM, Kevin Hilman
 wrote:
> Venkatraman S  writes:
>
>> omap hsmmc controller IP has a built in timer that can be programmed to
>> guard against unresponsive operations. But its range is very narrow,
>> and the maximum countable time is a few seconds.
>>
>> Card maintenance operations like BKOPS and MMC_ERASE and long
>> stream writes like packed command require timers of order of
>> several minutes, much beyond the capability of the IP timer.
>> So get rid of using the IP timer entirely and use kernel's hrtimer
>> functionality for guarding the device operations.
>> As part of this change, a workaround that disabled timeouts for
>> MMC_ERASE command is removed, and the arbitary timing of 100ms
>> is used only when the timeout is not explicitly specified by core.
>>
>> A trivial change to get rid of unnecessary dealiasing of host->data
>> in omap_hsmmc_do_irq is also included.
>>
>> Signed-off-by: Venkatraman S 
>
> Dumb question: if the timers needed are on the order of minutes, why do
> you need to use high-resolution timers?  I'm guessing the normal
> kernel-internal timers should suffice here (see  init_timer().)
>
Both sub ms and long duration timers are needed, based on the type of operation.
The eMMC standard has evolved to define new commands which require
such long duration
operations. The short ("control") commands do need high precision.

> Also, if they're on the order of minutes, I assume the actual firing
> doesn't have to be precise, so deferrable timers can probably be used
> (and thus help PM by coalescing wakeup events.)
>
> If my assumptions are true, it might be worth considering using the
> normal timers, and use init_timer_deferrable().
>
I'll certainly look into this. One way is to use the IP timer for
short commands and
deferrable timers for long ones - but I reckon it would be messy.

I've actually put this patch on hold - as someone pointed out to me that
this violates some sections of eMMC spec.


> 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 06/10] mmc: omap_hsmmc: remove access to SYSCONFIG register

2012-08-27 Thread S, Venkatraman
On Tue, Aug 21, 2012 at 9:08 PM, Shubhrajyoti Datta
 wrote:
> Hi Venkat,
> Some doubts below.
>
> On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S  wrote:
>> SYSCONFIG register of HSMMC IP is managed by the omap hwmod
>> abstraction layer.
>
> At init only right?
Yes.
>
>
>> Resetting the IP and configuring the correct
>> SYSCONFIG mode is centrally managed by hwmod.
>>
>> Remove code which manipulates IP reset and SYSCONFIG directly in the
>> driver.
>
> I am not sure if mmc needs a reset.
>
Actually it doesn't, as far as I know. That's why I propose it to be removed.

> However IMHO
> In case it needs a reset
>
> the hwmod way could be to use  omap_hwmod_reset
> However I  fear it may be an issue with dt.
> or
> may be sysc could be restored something like [1]
>
>
>
> if it doesnt need reset even the check for the SYSSTATUS could be
> considered for removal.
>
> [1] http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg12041.html
>
>
>
>>
>> Signed-off-by: Venkatraman S 
>> ---
>>  drivers/mmc/host/omap_hsmmc.c | 24 ++--
>>  1 file changed, 2 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>> index da4f5a7..4bc55ac 100644
>> --- a/drivers/mmc/host/omap_hsmmc.c
>> +++ b/drivers/mmc/host/omap_hsmmc.c
>> @@ -44,7 +44,6 @@
>>  #include 
>>
>>  /* OMAP HSMMC Host Controller Registers */
>> -#define OMAP_HSMMC_SYSCONFIG   0x0010
>>  #define OMAP_HSMMC_SYSSTATUS   0x0014
>>  #define OMAP_HSMMC_CON 0x002C
>>  #define OMAP_HSMMC_BLK 0x0104
>> @@ -576,21 +575,8 @@ static int omap_hsmmc_context_restore(struct 
>> omap_hsmmc_host *host)
>> if (host->context_loss == context_loss)
>> return 1;
>>
>> -   /* Wait for hardware reset */
>> -   timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
>> -   while ((OMAP_HSMMC_READ(host->base, SYSSTATUS) & RESETDONE) != 
>> RESETDONE
>> -   && time_before(jiffies, timeout))
>> -   ;
>> -
>> -   /* Do software reset */
>> -   OMAP_HSMMC_WRITE(host->base, SYSCONFIG, SOFTRESET);
>> -   timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
>> -   while ((OMAP_HSMMC_READ(host->base, SYSSTATUS) & RESETDONE) != 
>> RESETDONE
>> -   && time_before(jiffies, timeout))
>> -   ;
>> -
>> -   OMAP_HSMMC_WRITE(host->base, SYSCONFIG,
>> -   OMAP_HSMMC_READ(host->base, SYSCONFIG) | AUTOIDLE);
>> +   if (!OMAP_HSMMC_READ(host->base, SYSSTATUS) & RESETDONE)
>> +   return 1;
> Should this check be removed.
>
No - it's still needed to check that the IP is ready for use.

>>
>> if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
>> if (host->power_mode != MMC_POWER_OFF &&
>> @@ -1593,10 +1579,6 @@ static void omap_hsmmc_conf_bus_power(struct 
>> omap_hsmmc_host *host)
>> value = OMAP_HSMMC_READ(host->base, CAPA);
>> OMAP_HSMMC_WRITE(host->base, CAPA, value | capa);
>>
>> -   /* Set the controller to AUTO IDLE mode */
>> -   value = OMAP_HSMMC_READ(host->base, SYSCONFIG);
>> -   OMAP_HSMMC_WRITE(host->base, SYSCONFIG, value | AUTOIDLE);
>> -
>> /* Set SD bus power bit */
>> set_sd_bus_power(host);
>>  }
>> @@ -1654,8 +1636,6 @@ static int omap_hsmmc_regs_show(struct seq_file *s, 
>> void *data)
>>
>> pm_runtime_get_sync(host->dev);
>>
>> -   seq_printf(s, "SYSCONFIG:\t0x%08x\n",
>> -   OMAP_HSMMC_READ(host->base, SYSCONFIG));
>> seq_printf(s, "CON:\t\t0x%08x\n",
>> OMAP_HSMMC_READ(host->base, CON));
>> seq_printf(s, "HCTL:\t\t0x%08x\n",
>> --
>> 1.7.11.1.25.g0e18bef
>>
>> --
>> 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 07/10] mmc: omap_hsmmc: consolidate flush posted writes for HSMMC IRQs

2012-08-27 Thread S, Venkatraman
On Tue, Aug 21, 2012 at 8:51 PM, T Krishnamoorthy, Balaji
 wrote:
> On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S  wrote:
>> Flushing spurious IRQs from HSMMC IP is done twice in
>> omap_hsmmc_irq and omap_hsmmc_do_irq.
>
> spurious IRQ is flushed in start of omap_hsmmc_do_irq
> and irq acked at the end of omap_hsmmc_do_irq
>
>> Consolidate them to one location.
>
> if you wanted to consolidated ...
>
>>
>> Signed-off-by: Venkatraman S 
>> ---
>>  drivers/mmc/host/omap_hsmmc.c | 17 -
>>  1 file changed, 4 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>> index 4bc55ac..20453c8 100644
>> --- a/drivers/mmc/host/omap_hsmmc.c
>> +++ b/drivers/mmc/host/omap_hsmmc.c
>> @@ -969,15 +969,6 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
>> *host, int status)
>> struct mmc_data *data;
>> int end_cmd = 0, end_trans = 0;
>>
>> -   if (!host->req_in_progress) {
>
> just do a return from here

I think it's still better to filter out the validation to the outer
function and let do_irq to just 'do' it.

>
>> -   do {
>> -   OMAP_HSMMC_WRITE(host->base, STAT, status);
>> -   /* Flush posted write */
>> -   status = OMAP_HSMMC_READ(host->base, STAT);
>> -   } while (status & INT_EN_MASK);
>> -   return;
>> -   }
>> -
>> data = host->data;
>> dev_vdbg(mmc_dev(host->mmc), "IRQ Status is %x\n", status);
>>
>> @@ -1028,8 +1019,6 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
>> *host, int status)
>> }
>> }
>>
>> -   OMAP_HSMMC_WRITE(host->base, STAT, status);
>> -
>> if (end_cmd || ((status & CC) && host->cmd))
>> omap_hsmmc_cmd_done(host, host->cmd);
>> if ((end_trans || (status & TC)) && host->mrq)
>> @@ -1045,11 +1034,13 @@ static irqreturn_t omap_hsmmc_irq(int irq, void 
>> *dev_id)
>> int status;
>>
>> status = OMAP_HSMMC_READ(host->base, STAT);
>> -   do {
>> +   while (status & INT_EN_MASK && host->req_in_progress) {
>
> and remove the check for host->req_in_progress
> I think do while loop can be retained as it will get executed once anyway.

It's a minor issue, and the consolidation of the check for
req_in_progress makes sure that it might
sometimes be not executed at all..


>
>> omap_hsmmc_do_irq(host, status);
>> +
>
>> /* Flush posted write */
>
> comment is misplaced
>
Ok. I'll remove.

>> +   OMAP_HSMMC_WRITE(host->base, STAT, status);
>> status = OMAP_HSMMC_READ(host->base, STAT);
>> -   } while (status & INT_EN_MASK);
>> +   }
>>
>> return IRQ_HANDLED;
>>  }
>> --
>> 1.7.11.1.25.g0e18bef
>>
--
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 09/10] mmc: omap_hsmmc: convert from IP timer to hrtimer

2012-08-22 Thread S, Venkatraman
On Tue, Aug 21, 2012 at 4:12 PM, Felipe Balbi  wrote:
> On Sat, Aug 18, 2012 at 12:22:29AM +0530, Venkatraman S wrote:
>> omap hsmmc controller IP has an inbuilt timer that can be programmed to
>   ^^^
>   built-in
>> guard against unresponsive operations. But it's range is very narrow,
>  
>  its
>
>
>> and it's maximum countable time is a few seconds.
>   
>   its
>

Will fix.

>
>> Card maintenance operations like BKOPS and SECURE DISCARD and long
>> stream writes like packed command require timers of order of
>> several minutes.
>> So get rid of using the IP timer entirely and use kernel's hrtimer
>> functionality for guarding the device operations.
>> As part of this change, a workaround that disabled timeouts for
>> MMC_ERASE commands is removed, and the arbitary timing of 100ms
>> is used only when the timeout is not explicitly specified by core.
>>
>> Signed-off-by: Venkatraman S 
>> ---
>>  drivers/mmc/host/omap_hsmmc.c | 96 
>> ++-
>>  1 file changed, 50 insertions(+), 46 deletions(-)
>>
>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>> index 9afdd20..8f7cebc 100644
>> --- a/drivers/mmc/host/omap_hsmmc.c
>> +++ b/drivers/mmc/host/omap_hsmmc.c
>> @@ -79,7 +79,7 @@
>>  #define CLKD_SHIFT   6
>>  #define DTO_MASK 0x000F
>>  #define DTO_SHIFT16
>> -#define INT_EN_MASK  0x307F0033
>> +#define INT_EN_MASK  0x306E0033
>
> not related to this patch in particular, but it would be nice if this
> was converted to something more meaningfull, like ORing a bunch of bit
> defines.
>

Sure. Good to do now as part of the change.

>>  #define BWR_ENABLE   (1 << 4)
>>  #define BRR_ENABLE   (1 << 5)
>>  #define DTO_ENABLE   (1 << 20)
>> @@ -160,6 +160,7 @@ struct omap_hsmmc_host {
>>   unsigned intdma_sg_idx;
>>   unsigned char   bus_mode;
>>   unsigned char   power_mode;
>> + unsigned intns_per_clk_cycle;
>>   int suspended;
>>   int irq;
>>   int use_dma, dma_ch;
>> @@ -172,6 +173,7 @@ struct omap_hsmmc_host {
>>   int reqs_blocked;
>>   int use_reg;
>>   int req_in_progress;
>> + struct hrtimer  guard_timer;
>>   struct omap_hsmmc_next  next_data;
>>
>>   struct  omap_mmc_platform_data  *pdata;
>> @@ -455,10 +457,6 @@ static void omap_hsmmc_enable_irq(struct 
>> omap_hsmmc_host *host,
>>   else
>>   irq_mask = INT_EN_MASK;
>>
>> - /* Disable timeout for erases */
>> - if (cmd->opcode == MMC_ERASE)
>> - irq_mask &= ~DTO_ENABLE;
>> -
>>   OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
>>   OMAP_HSMMC_WRITE(host->base, ISE, irq_mask);
>>   OMAP_HSMMC_WRITE(host->base, IE, irq_mask);
>> @@ -508,6 +506,9 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host 
>> *host)
>>   && time_before(jiffies, timeout))
>>   cpu_relax();
>>
>> + if (ios->clock)
>> + host->ns_per_clk_cycle = DIV_ROUND_UP(NSEC_PER_SEC, 
>> ios->clock);
>> +
>>   omap_hsmmc_start_clock(host);
>>  }
>>
>> @@ -824,7 +825,7 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host, 
>> struct mmc_data *data)
>>   omap_hsmmc_request_done(host, mrq);
>>   return;
>>   }
>> -
>> + hrtimer_cancel(&host->guard_timer);
>>   host->data = NULL;
>>
>>   if (!data->error)
>> @@ -859,8 +860,11 @@ omap_hsmmc_cmd_done(struct omap_hsmmc_host *host, 
>> struct mmc_command *cmd)
>>   cmd->resp[0] = OMAP_HSMMC_READ(host->base, RSP10);
>>   }
>>   }
>> - if ((host->data == NULL && !host->response_busy) || cmd->error)
>> + if ((host->data == NULL && !host->response_busy) || cmd->error) {
>
> could just go ahead and make this check uniform by:
>
> if ((!host->data && !host->response_busy)) || cmd->error)
>

Ok.

>> + if (cmd->error != -ETIMEDOUT)
>> + hrtimer_cancel(&host->guard_timer);
>>   omap_hsmmc_request_done(host, cmd->mrq);
>> + }
>>  }
>>
>>  /*
>> @@ -992,7 +996,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
>> *host, int status)
>>   hsmmc_command_incomplete(host, -EILSEQ);
>>
>>   end_cmd = 1;
>> - if (host->data || host->response_busy) {
>> + if (data || host->response_busy) {
>
> This doesn't seem like it belongs to $SUBJECT...
>
I thought is was a small fix which didn't warrant a separate patch though.

>>   end_trans = 1;
>>   host->response_busy = 0;
>>   }
>> @@ -1292,41 +1296,35 @@ static int oma

Re: [PATCH] omap-hsmmc: Implementation of i761 errata

2012-08-19 Thread S, Venkatraman
On Fri, Aug 17, 2012 at 11:43 PM, Puttagunta, Viswanath  wrote:
> On Fri, Aug 17, 2012 at 12:28 PM, S, Venkatraman  wrote:
>> On Fri, Aug 17, 2012 at 9:35 PM, Semen Protsenko  
>> wrote:
>>> Errata description:
>>> Due to a bad behavior of an internal signal, the Card Error interrupt bit
>>> MMCHS_STAT[28] CERR may not be set sometimes when an error occurred in the
>>> card response.
>>>
>>> Workaround:
>>> After responses of type R1/R1b for all cards and responses of type R5/R5b/R6
>>> for SD and SDIO cards, software must read two registers: MMCHS_RSP10 and
>>> MMCHS_CSRE. When a MMCHS_CSRE[i] bit is set to 1, if the corresponding bit 
>>> at
>>> the same position in the response MMCHS_RSP10[i] is set to 1, the host
>>> controller indicates a card error and software should proceed in the same 
>>> way
>>> as if a CERR interrupt would have been detected in the MMCHS_STAT register.
>>>
>>> Note:
>>> This errata is applicable for omap44xx.
>>>
>>> Signed-off-by: Semen Protsenko 
>>
>> The implementation looks fine, but can we simply not set the errata
>> flag and make this as default
>> behaviour ? I suppose the documented behaviour with CSRE and RSP10 is
>> independent of the
>> errata..
>>
>> Also, please send it to the linux-mmc list as well.
>
> Vish>> We don't know if this errata effects OMAP5 as well. So, I think
> we should only do this if we are OMAP4.
>
That's precisely why the code shouldn't check for cpu_() flags. There are other
OMAP variants as well and we can't check all of them
What I mean is to make the check for RSP10 and CSRE all the time as part
of the IRQ check.
  Then it equally applies to silcon with or without errata.
--
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] omap-hsmmc: Implementation of i761 errata

2012-08-17 Thread S, Venkatraman
On Fri, Aug 17, 2012 at 9:35 PM, Semen Protsenko  wrote:
> Errata description:
> Due to a bad behavior of an internal signal, the Card Error interrupt bit
> MMCHS_STAT[28] CERR may not be set sometimes when an error occurred in the
> card response.
>
> Workaround:
> After responses of type R1/R1b for all cards and responses of type R5/R5b/R6
> for SD and SDIO cards, software must read two registers: MMCHS_RSP10 and
> MMCHS_CSRE. When a MMCHS_CSRE[i] bit is set to 1, if the corresponding bit at
> the same position in the response MMCHS_RSP10[i] is set to 1, the host
> controller indicates a card error and software should proceed in the same way
> as if a CERR interrupt would have been detected in the MMCHS_STAT register.
>
> Note:
> This errata is applicable for omap44xx.
>
> Signed-off-by: Semen Protsenko 

The implementation looks fine, but can we simply not set the errata
flag and make this as default
behaviour ? I suppose the documented behaviour with CSRE and RSP10 is
independent of the
errata..

Also, please send it to the linux-mmc list as well.

> ---
>  drivers/mmc/host/omap_hsmmc.c |   38 ++
>  1 file changed, 38 insertions(+)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 3a09f93..17803de 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -47,6 +48,7 @@
>  /* OMAP HSMMC Host Controller Registers */
>  #define OMAP_HSMMC_SYSCONFIG   0x0010
>  #define OMAP_HSMMC_SYSSTATUS   0x0014
> +#define OMAP_HSMMC_CSRE0x0024
>  #define OMAP_HSMMC_CON 0x002C
>  #define OMAP_HSMMC_BLK 0x0104
>  #define OMAP_HSMMC_ARG 0x0108
> @@ -117,6 +119,9 @@
>  #define OMAP_MMC_MAX_CLOCK 5200
>  #define DRIVER_NAME"omap_hsmmc"
>
> +/* Errata definitions */
> +#define OMAP_HSMMC_ERRATA_I761 BIT(0)
> +
>  /*
>   * One controller can have multiple slots, like on some omap boards using
>   * omap.c controller driver. Luckily this is not currently done on any known
> @@ -177,6 +182,7 @@ struct omap_hsmmc_host {
> int reqs_blocked;
> int use_reg;
> int req_in_progress;
> +   unsigned interrata;
> struct omap_hsmmc_next  next_data;
>
> struct  omap_mmc_platform_data  *pdata;
> @@ -857,6 +863,23 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host, 
> struct mmc_data *data)
> omap_hsmmc_start_command(host, data->stop, NULL);
>  }
>
> +static int
> +omap_hsmmc_errata_i761(struct omap_hsmmc_host *host, struct mmc_command *cmd)
> +{
> +   u32 rsp10, csre;
> +
> +   if ((cmd->flags & MMC_RSP_R1) == MMC_RSP_R1
> +   || (host->mmc->card && (mmc_card_sd(host->mmc->card)
> +   || mmc_card_sdio(host->mmc->card))
> +   && (cmd->flags & MMC_RSP_R5))) {
> +   rsp10 = OMAP_HSMMC_READ(host->base, RSP10);
> +   csre = OMAP_HSMMC_READ(host->base, CSRE);
> +   return rsp10 & csre;
> +   }
> +
> +   return 0;
> +}
> +
>  /*
>   * Notify the core about command completion
>   */
> @@ -1046,6 +1069,17 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
> *host, int status)
> }
> }
>
> +   /* Errata i761 */
> +   if ((host->errata & OMAP_HSMMC_ERRATA_I761) && host->cmd
> +   && omap_hsmmc_errata_i761(host, host->cmd)) {
> +   /* Do the same as for CARD_ERR case */
> +   dev_dbg(mmc_dev(host->mmc), "Ignoring card err CMD%d\n",
> +   host->cmd->opcode);
> +   end_cmd = 1;
> +   if (host->data)
> +   end_trans = 1;
> +   }
> +
> OMAP_HSMMC_WRITE(host->base, STAT, status);
>
> if (end_cmd || ((status & CC) && host->cmd))
> @@ -1829,6 +1863,10 @@ static int __devinit omap_hsmmc_probe(struct 
> platform_device *pdev)
> host->power_mode = MMC_POWER_OFF;
> host->next_data.cookie = 1;
>
> +   host->errata = 0;
> +   if (cpu_is_omap44xx())
> +   host->errata |= OMAP_HSMMC_ERRATA_I761;
> +
> platform_set_drvdata(pdev, host);
>
> mmc->ops= &omap_hsmmc_ops;
> --
> 1.7.10.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: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

2012-07-30 Thread S, Venkatraman
On Mon, Jul 30, 2012 at 8:14 PM, Russell King - ARM Linux
 wrote:
> On Mon, Jul 30, 2012 at 04:37:09PM +0200, Shilimkar, Santosh wrote:
>> On Mon, Jul 30, 2012 at 4:33 PM, Russell King - ARM Linux
>>  wrote:
>> > So I take that as you wanting exactly what is in linux-next merged without
>> > any further changes?
>>
>> Just one patch[1] on top of that so that default omap2plus_defconfig
>> keeps working.
>
> Err, I don't see what that patch does.  Setting ret=-ENXIO at the
> start of the function, when it's subsequently overwritten by:
>
> +   int ret = -ENXIO, irq;
> ...
> ret = omap_hsmmc_gpio_init(pdata);
> ...
> ... dma stuff ...
>
> seems absurd.

I think Santosh meant this patch..
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commitdiff;h=55936cdfaaf11ac352b56bc58e42d6661e65ee13
--
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: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

2012-07-29 Thread S, Venkatraman
On Sat, Jul 28, 2012 at 1:40 PM, Shilimkar, Santosh
 wrote:
> On Fri, Jul 27, 2012 at 6:50 PM, Russell King - ARM Linux
>  wrote:
>> On Fri, Jul 27, 2012 at 06:08:13PM +0200, Shilimkar, Santosh wrote:
>>> On Fri, Jul 27, 2012 at 3:42 PM, Russell King - ARM Linux
>>>  wrote:
>>> > On Wed, Jul 25, 2012 at 03:12:22PM +0100, Russell King - ARM Linux wrote:
>>> >> Just a quick reminder that I'm still on holiday, and at this point there
>>> >> are over 2500 messages from the mailing lists which are sitting unread
>>> >> since I left the UK.  As I mentioned before I left the UK, it is my
>>> >> intention *not* to go back and read all those outstanding messages -
>>> >> there's too many of them to do that.
>>> >>
>>> >> So, if you want me to react to any email message you've sent, you'd
>>> >> *better* send it again next week unless I've already responded.
>>> >>
>>> >> Meanwhile, I see v3.5 has been released; I have a couple of things I
>>> >> need to do with my tree before I can push the changes, and I'll
>>> >> probably see about sorting those out over the weekend.  I also see
>>> >> that 14 new patches have landed in the patch system.
>>> >>
>>> >> However, the timing of my holiday vs the merge window means that I
>>> >> can't take anything new, unless they're fixes, so don't be surprised
>>> >> if some stuff gets missed this merge window.
>>> >
>>> > Right.  I'm not fully recovered from the jet lag (I'm still rather tired
>>> > - I hate travelling back from the North American continent because it
>>> > takes days to recover.)
>>> >
>>> > I have now archived off *all* email sent to me during July - which means
>>> > that I will *NOT* be responding to anything sent during the last 17 days.
>>> > If anyone has sent me anything important, it *MUST* be resent now.
>>> >
>>> > I am aware of an issue concerning the OMAP DMA patches.  I'm not sure
>>> > exactly what is required there, so I've dropped them from my planned pull
>>> > request in the interests of getting everything else I have to Linus.  I
>>> > may plan to send a pull request this evening.
>>> >
>>> Well the only pending discussion was enabling the CONFIG option for
>>> DMA at driver level SOC config level. Not sure if there was anything else
>>> on this really.
>>
>> Why?  The DMA driver itself is optional.
> That was Tony's point too. Unfortunately MMC and SPI driver don't work
> today without DMA. Some works needs to be done to support polling
> mode and am bit skeptical if it is really worth it. Same case be with other
> SDMA supported drivers mostly.
>
Russell, Tony,
  Can I request to include the DMA & MMC changes into this merge window ?
We have many cleanups and new patches waiting to be queued up for next (3.7)
merge window, and it'd be easier if they are implemented on top of the
DMA changes,
so that it gets tested together, and don't create merge conflicts.
  I am looking into implementing polling mode, which might take some time.
Regards,
Venkat
--
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: NFS mount issue with OMAP4 on linux-next

2012-07-23 Thread S, Venkatraman
On Tue, Jul 24, 2012 at 11:48 AM, Archit Taneja  wrote:
> Hi,
>
> Comparing with working logs, I see this difference:
>
> [1.502166] spi spi1.0: no RX DMA engine channel for McSPI
> [1.507904] omap2_mcspi omap2_mcspi.1: can't setup spi1.0, status -11
> [1.514862] omap2_mcspi omap2_mcspi.1: can't create new device for ks8851
>
> I guess that's why it isn't working?
>
Most likely yes. SPI is needed for ethernet on OMAP4.
Please include this patch in your build and check..
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commit;h=55936cdfaaf11ac352b56bc58e42d6661e65ee13
--
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/25] mmc/omap_hsmmc: add a const qualifier

2012-07-23 Thread S, Venkatraman
On Mon, Jul 23, 2012 at 2:43 PM, Uwe Kleine-König
 wrote:
> This prepares *of_device_id.data becoming const. Without this change
> the following warning would occur:
>
> drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_probe':
> drivers/mmc/host/omap_hsmmc.c:1808: warning: initialization discards 
> qualifiers from pointer target type
>
> Signed-off-by: Uwe Kleine-König 

Acked-by: Venkatraman S 


> ---
>  drivers/mmc/host/omap_hsmmc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
--
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] mmc: host: enable OMAP DMA engine support for omap hosts by default

2012-07-20 Thread S, Venkatraman
On Fri, Jul 20, 2012 at 2:58 PM, S, Venkatraman  wrote:
> On Thu, Jul 19, 2012 at 5:02 PM, Tony Lindgren  wrote:
>> * Shilimkar, Santosh  [120718 02:49]:
>>>
>>> "The patch simply make them depend on DMA_OMAP since DMA_OMAP
>>> will select DMA_ENGINE automatically"
>>>
>>> This won't be true if the DMA selection are not done
>>> at ARCH_OMAP level as discussed in this thread.
>>>
>>> Having said that, I think Russell and Tony need to
>>> take call on how this needs to be handled.
>>
>> As the DMA channels can run out, drivers should also work
>> without DMA. And building everything as modules should be
>> possible for the distro kernels.
>>
>> So I'd rather not have either select or depends and have
>> the drivers fixed.
>>
>
> Ok - I'll work on getting polling mode to work, but as you know it's
> not the mode to get the best performance out of the device.
> I see that you've also merged the changes to omap2plus_defconfig, which should
> get MMC working as before DMA Engine conversion.
>
> There's a small patch needed to omap_hsmmc to return a non-zero error code
> during the probe error path. This will atleast make probe failure
> explicit when DMA
> is not available.
>
> Let me know if you want me to post it separately as a patch..
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 2338703..892a046 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1773,7 +1773,7 @@ static int __devinit omap_hsmmc_probe(struct
> platform_device *pdev)
> struct mmc_host *mmc;
> struct omap_hsmmc_host *host = NULL;
> struct resource *res;
> -   int ret, irq;
> +   int ret = -ENXIO, irq;
> const struct of_device_id *match;
> dma_cap_mask_t mask;
> unsigned tx_req, rx_req;

Please ignore this patch. The correct one was posted by Kevin last week [1].
An additional patch is needed on top of that to fix other error paths, I'll
send both now.

[1] http://marc.info/?l=linux-omap&m=134196391719430&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 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default

2012-07-20 Thread S, Venkatraman
On Thu, Jul 19, 2012 at 5:02 PM, Tony Lindgren  wrote:
> * Shilimkar, Santosh  [120718 02:49]:
>>
>> "The patch simply make them depend on DMA_OMAP since DMA_OMAP
>> will select DMA_ENGINE automatically"
>>
>> This won't be true if the DMA selection are not done
>> at ARCH_OMAP level as discussed in this thread.
>>
>> Having said that, I think Russell and Tony need to
>> take call on how this needs to be handled.
>
> As the DMA channels can run out, drivers should also work
> without DMA. And building everything as modules should be
> possible for the distro kernels.
>
> So I'd rather not have either select or depends and have
> the drivers fixed.
>

Ok - I'll work on getting polling mode to work, but as you know it's
not the mode to get the best performance out of the device.
I see that you've also merged the changes to omap2plus_defconfig, which should
get MMC working as before DMA Engine conversion.

There's a small patch needed to omap_hsmmc to return a non-zero error code
during the probe error path. This will atleast make probe failure
explicit when DMA
is not available.

Let me know if you want me to post it separately as a patch..

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2338703..892a046 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1773,7 +1773,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
struct mmc_host *mmc;
struct omap_hsmmc_host *host = NULL;
struct resource *res;
-   int ret, irq;
+   int ret = -ENXIO, irq;
const struct of_device_id *match;
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
--
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] MMC: OMAP: make MMC_OMAP* depend on DMA_OMAP

2012-07-19 Thread S, Venkatraman
On Thu, Jul 19, 2012 at 10:35 AM, Chris Ball  wrote:
> Hi Venkat -- please could you ACK/review this patch?
>

Chris,
 I think we have to hold on to this patch just for today. There's
another thread about this same issue on linux-omap

> On Wed, Jul 04 2012, Ming Lei wrote:
>> Recent commits on omap mmc/hsmmc in -next tree switch to
>> DMA_ENGINE entirely, so make MMC_OMAP* depend on DMA_OMAP
>> and DMA_ENGINE, otherwise OMAP MMC/HSMMC won't work without
>> enabling DMA_ENGINE and DMA_OMAP.
>>
>> The patch simply make them depend on DMA_OMAP since DMA_OMAP
>> will select DMA_ENGINE automatically.
>>
>> Signed-off-by: Ming Lei 
>> ---
>>  drivers/mmc/host/Kconfig |4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
>> index aa131b3..ef72c50 100644
>> --- a/drivers/mmc/host/Kconfig
>> +++ b/drivers/mmc/host/Kconfig
>> @@ -231,7 +231,7 @@ config MMC_SDHCI_S3C_DMA
>>
>>  config MMC_OMAP
>>   tristate "TI OMAP Multimedia Card Interface support"
>> - depends on ARCH_OMAP
>> + depends on ARCH_OMAP && DMA_OMAP
>>   select TPS65010 if MACH_OMAP_H2
>>   help> Thanks,
>
> - Chris.
> --
> Chris Ball  
> One Laptop Per Child


>> This selects the TI OMAP Multimedia card Interface.
>> @@ -242,7 +242,7 @@ config MMC_OMAP
>>
>>  config MMC_OMAP_HS
>>   tristate "TI OMAP High Speed Multimedia Card Interface support"
>> - depends on SOC_OMAP2430 || ARCH_OMAP3 || ARCH_OMAP4
>> + depends on (SOC_OMAP2430 || ARCH_OMAP3 || ARCH_OMAP4) && DMA_OMAP
>>   help
>> This selects the TI OMAP High Speed Multimedia card Interface.
>> If you have an OMAP2430 or OMAP3 board or OMAP4 board with a
>
--
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: am3517: geting MMC working

2012-07-19 Thread S, Venkatraman
On Thu, Jul 19, 2012 at 1:45 PM, Yegor Yefremov
 wrote:
> Am 19.07.2012 09:43, schrieb S, Venkatraman:
>> On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov
>>  wrote:
>>> Am 19.07.2012 09:07, schrieb Shilimkar, Santosh:
>>>> On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov
>>>>  wrote:
>>>>> Am 19.07.2012 08:34, schrieb Shilimkar, Santosh:
>>>>>> On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov
>>>>>>  wrote:
>>>>>>> What patches do I need to get MMC working with linux-omap master?
>>>>>>>
>>>>>>> omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
>>>>>>> omap-dma-engine omap-dma-engine: allocating channel for 62
>>>>>>> omap-dma-engine omap-dma-engine: allocating channel for 61
>>>>>>> omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
>>>>>>> omap-dma-engine omap-dma-engine: allocating channel for 48
>>>>>>> omap-dma-engine omap-dma-engine: allocating channel for 47
>>>>>>>
>>>>>>> I searched for this issue and saw some patches for common clock 
>>>>>>> framework
>>>>>>> that were scheduled for 3.6, but I'm not sure it's enough or weather 
>>>>>>> they
>>>>>>> are already incorporated in linux-omap.
>>>>>>>
>>>>>> I guess you need [1] to get around the issue.
>>>>>>
>>>>>> [1] http://www.spinics.net/lists/linux-omap/msg73965.html
>>>>> though I haven't applied this patch I have DMA activated 
>>>>> (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. 
>>>>> As far as I can tell, debounce clk is the problem.
>>>>>
>>>> Sorry. I miss-read the message.
>>> The whole log for reference:
>>>
>>> Booting Linux on physical CPU 0
>>> Linux version 3.5.0-rc6-12227-g60701f4-dirty () (gcc version 4.5.3 
>>> (Buildroot 2012.05-rc2-9-gfbd5a1d-dirty) ) #90 Thu Jul 19 09:23:31 CEST 
>>> 2012
>>> CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
>>> Machine: OMAP3517/AM3517 EVM
>>> Ignoring tag cmdline (using the default kernel command line)
>>> bootconsole [earlycon0] enabled
>>> Memory policy: ECC disabled, Data cache writeback
>>> AM3517 ES1.1 (l2cache sgx neon )
>>> Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
>>> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64768
>>> Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 
>>> earlyprintk=serial,ttyO2,115200
>>> PID hash table entries: 1024 (order: 0, 4096 bytes)
>>> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
>>> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
>>> Memory: 255MB = 255MB total
>>> Memory: 247380k/247380k available, 14764k reserved, 0K highmem
>>> Virtual kernel memory layout:
>>> vector  : 0x - 0x1000   (   4 kB)
>>> fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
>>> vmalloc : 0xd080 - 0xff00   ( 744 MB)
>>> lowmem  : 0xc000 - 0xd000   ( 256 MB)
>>> pkmap   : 0xbfe0 - 0xc000   (   2 MB)
>>>   .text : 0xc0008000 - 0xc055e6a8   (5466 kB)
>>>   .init : 0xc055f000 - 0xc0594874   ( 215 kB)
>>>   .data : 0xc0596000 - 0xc05fccc0   ( 412 kB)
>>>.bss : 0xc05fcce4 - 0xc0b2a1e8   (5302 kB)
>>> NR_IRQS:474
>>> IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts
>>> Total of 96 interrupts on 1 active controller
>>> OMAP clockevent source: GPTIMER1 at 32768 Hz
>>> sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
>>> OMAP clocksource: 32k_counter at 32768 Hz
>>> Console: colour dummy device 80x30
>>> Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
>>> ... MAX_LOCKDEP_SUBCLASSES:  8
>>> ... MAX_LOCK_DEPTH:  48
>>> ... MAX_LOCKDEP_KEYS:8191
>>> ... CLASSHASH_SIZE:  4096
>>> ... MAX_LOCKDEP_ENTRIES: 16384
>>> ... MAX_LOCKDEP_CHAINS:  32768
>>> ... CHAINHASH_SIZE:  16384
>>>  memory used by lock dependency info: 3695 kB
>>>  per task-struct memory footprint: 1152 bytes
>>> Calibrating delay loop... 331.40 BogoM

Re: am3517: geting MMC working

2012-07-19 Thread S, Venkatraman
On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov
 wrote:
> Am 19.07.2012 09:07, schrieb Shilimkar, Santosh:
>> On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov
>>  wrote:
>>> Am 19.07.2012 08:34, schrieb Shilimkar, Santosh:
 On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov
  wrote:
> What patches do I need to get MMC working with linux-omap master?
>
> omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
> omap-dma-engine omap-dma-engine: allocating channel for 62
> omap-dma-engine omap-dma-engine: allocating channel for 61
> omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
> omap-dma-engine omap-dma-engine: allocating channel for 48
> omap-dma-engine omap-dma-engine: allocating channel for 47
>
> I searched for this issue and saw some patches for common clock framework
> that were scheduled for 3.6, but I'm not sure it's enough or weather they
> are already incorporated in linux-omap.
>
 I guess you need [1] to get around the issue.

 [1] http://www.spinics.net/lists/linux-omap/msg73965.html
>>> though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES 
>>> and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, 
>>> debounce clk is the problem.
>>>
>> Sorry. I miss-read the message.
>
> The whole log for reference:
>
> Booting Linux on physical CPU 0
> Linux version 3.5.0-rc6-12227-g60701f4-dirty () (gcc version 4.5.3 (Buildroot 
> 2012.05-rc2-9-gfbd5a1d-dirty) ) #90 Thu Jul 19 09:23:31 CEST 2012
> CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> Machine: OMAP3517/AM3517 EVM
> Ignoring tag cmdline (using the default kernel command line)
> bootconsole [earlycon0] enabled
> Memory policy: ECC disabled, Data cache writeback
> AM3517 ES1.1 (l2cache sgx neon )
> Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64768
> Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 
> earlyprintk=serial,ttyO2,115200
> PID hash table entries: 1024 (order: 0, 4096 bytes)
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Memory: 255MB = 255MB total
> Memory: 247380k/247380k available, 14764k reserved, 0K highmem
> Virtual kernel memory layout:
> vector  : 0x - 0x1000   (   4 kB)
> fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
> vmalloc : 0xd080 - 0xff00   ( 744 MB)
> lowmem  : 0xc000 - 0xd000   ( 256 MB)
> pkmap   : 0xbfe0 - 0xc000   (   2 MB)
>   .text : 0xc0008000 - 0xc055e6a8   (5466 kB)
>   .init : 0xc055f000 - 0xc0594874   ( 215 kB)
>   .data : 0xc0596000 - 0xc05fccc0   ( 412 kB)
>.bss : 0xc05fcce4 - 0xc0b2a1e8   (5302 kB)
> NR_IRQS:474
> IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts
> Total of 96 interrupts on 1 active controller
> OMAP clockevent source: GPTIMER1 at 32768 Hz
> sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
> OMAP clocksource: 32k_counter at 32768 Hz
> Console: colour dummy device 80x30
> Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
> ... MAX_LOCKDEP_SUBCLASSES:  8
> ... MAX_LOCK_DEPTH:  48
> ... MAX_LOCKDEP_KEYS:8191
> ... CLASSHASH_SIZE:  4096
> ... MAX_LOCKDEP_ENTRIES: 16384
> ... MAX_LOCKDEP_CHAINS:  32768
> ... CHAINHASH_SIZE:  16384
>  memory used by lock dependency info: 3695 kB
>  per task-struct memory footprint: 1152 bytes
> Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384)
> pid_max: default: 32768 minimum: 301
> Security Framework initialized
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> Setting up static identity map for 0x80444ff0 - 0x80445048
> devtmpfs: initialized
> dummy:
> NET: Registered protocol family 16
> GPMC revision 5.0
> gpmc: irq-20 could not claim: err -22
> OMAP GPIO hardware version 2.5
> omap_mux_init: Add partition: #1: core, flags: 0
> _omap_mux_get_by_name: Could not find signal uart4_rx.uart4_rx
> Reprogramming SDRC clock to 33200 Hz
> dpll3_m2_clk rate change failed: -22
> hw-breakpoint: debug architecture 0x4 unsupported.
> OMAP DMA hardware revision 4.0
> bio: create slab  at 0
> omap-dma-engine omap-dma-engine: OMAP DMA engine driver
> SCSI subsystem initialized
> omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz
> omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz
> omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz
> Bluetooth: Core ver 2.16
> NET: Registered protocol family 31
> Bluetooth: HCI device and connection manager initialized
> Bluetooth: HCI socket layer initialized
> Bluetooth: L2CAP socket layer initialized
> Bluetooth: SCO socket layer initialized
> cfg80211: Calling CRDA to update world regulatory domain
> Switching to clocksource 32k_counter

Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default

2012-07-18 Thread S, Venkatraman
On Wed, Jul 18, 2012 at 2:46 PM, Javier Martinez Canillas
 wrote:
> On Wed, Jul 18, 2012 at 11:11 AM, Shilimkar, Santosh
>  wrote:
>> On Wed, Jul 18, 2012 at 2:19 PM, Javier Martinez Canillas
>>  wrote:
>>> On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh
>>>  wrote:
>>>> On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman  wrote:
>>>>> On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren  wrote:
>>>>>> * Shilimkar, Santosh  [120718 00:09]:
>>>>>>> On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren  
>>>>>>> wrote:
>>>>>>> > * Javier Martinez Canillas  [120716 23:56]:
>>>>>>> >> On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
>>>>>>> >>  wrote:
>>>>>>> >> > Hi,
>>>>>>> >> >
>>>>>>> >> > On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
>>>>>>> >> >  wrote:
>>>>>>> >> >> The OMAP MMC and OMAP High Speed MMC hosts now use entirely the 
>>>>>>> >> >> DMA
>>>>>>> >> >> engine API instead of the previous private DMA API implementation.
>>>>>>> >> >>
>>>>>>> >> >> So, if the kernel is built with support for any of these hosts 
>>>>>>> >> >> but it
>>>>>>> >> >> doesn't support DMA devices nor OMAP DMA support, it fails when 
>>>>>>> >> >> trying
>>>>>>> >> >> to obtain a DMA channel which leads to the following error on an 
>>>>>>> >> >> OMAP3
>>>>>>> >> >> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC 
>>>>>>> >> >> support):
>>>>>>> >> >>
>>>>>>> >> >> [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA 
>>>>>>> >> >> engine channel 48
>>>>>>> >> >> [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA 
>>>>>>> >> >> engine channel 62
>>>>>>> >> >>
>>>>>>> >> >> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP 
>>>>>>> >> >> solves it.
>>>>>>> >> >>
>>>>>>> >> >> Signed-off-by: Javier Martinez Canillas 
>>>>>>> >> >> ---
>>>>>>> >> > Considering, we are updating drivers to select the DMA engine, can 
>>>>>>> >> > you
>>>>>>> >> > also include
>>>>>>> >> > "drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA 
>>>>>>> >> > engine.
>>>>>>> >> >
>>>>>>> >> > Regards
>>>>>>> >> > Santosh
>>>>>>> >>
>>>>>>> >> Hi Santosh,
>>>>>>> >>
>>>>>>> >> Ok, I'll send a v2 now which includes spi-omap2-mcspi then.
>>>>>>> >
>>>>>>> > I don't think we should do this, the drivers should work with and 
>>>>>>> > without
>>>>>>> > dma. This just needs to be added to the omap2plus_defconfig.
>>>>>>> >
>>>>>>> Well this was not decided based on any DMA CONFIG option before for
>>>>>>> the subject drivers. It is already by default enabled if the DMA is 
>>>>>>> supported
>>>>>>> by the driver IP. There is a possibility to disable it from driver 
>>>>>>> platform/dt
>>>>>>> data so that still remains.
>>>>>>
>>>>>> I think it should rather be that if the driver is broken and does not 
>>>>>> work
>>>>>> without DMA, it should have depends on CONFIG_DMA_OMAP.
>>>>>>
>>>>> I can confirm that omap MMC can't work without DMA; polled mode is not
>>>>> supported / implemented.
>>>>
>>>> Same case for SPI driver as well. It uses DMA for everything except the 
>>>> cases
>>>> where DMA doesn't make sense like 1 byte/2 byte etc. And its not 

Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default

2012-07-18 Thread S, Venkatraman
On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren  wrote:
> * Shilimkar, Santosh  [120718 00:09]:
>> On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren  wrote:
>> > * Javier Martinez Canillas  [120716 23:56]:
>> >> On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh
>> >>  wrote:
>> >> > Hi,
>> >> >
>> >> > On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas
>> >> >  wrote:
>> >> >> The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA
>> >> >> engine API instead of the previous private DMA API implementation.
>> >> >>
>> >> >> So, if the kernel is built with support for any of these hosts but it
>> >> >> doesn't support DMA devices nor OMAP DMA support, it fails when trying
>> >> >> to obtain a DMA channel which leads to the following error on an OMAP3
>> >> >> IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support):
>> >> >>
>> >> >> [2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine 
>> >> >> channel 48
>> >> >> [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine 
>> >> >> channel 62
>> >> >>
>> >> >> selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves 
>> >> >> it.
>> >> >>
>> >> >> Signed-off-by: Javier Martinez Canillas 
>> >> >> ---
>> >> > Considering, we are updating drivers to select the DMA engine, can you
>> >> > also include
>> >> > "drivers/spi/spi-omap2-mcspi.c" which is also updated for DMA engine.
>> >> >
>> >> > Regards
>> >> > Santosh
>> >>
>> >> Hi Santosh,
>> >>
>> >> Ok, I'll send a v2 now which includes spi-omap2-mcspi then.
>> >
>> > I don't think we should do this, the drivers should work with and without
>> > dma. This just needs to be added to the omap2plus_defconfig.
>> >
>> Well this was not decided based on any DMA CONFIG option before for
>> the subject drivers. It is already by default enabled if the DMA is supported
>> by the driver IP. There is a possibility to disable it from driver 
>> platform/dt
>> data so that still remains.
>
> I think it should rather be that if the driver is broken and does not work
> without DMA, it should have depends on CONFIG_DMA_OMAP.
>
I can confirm that omap MMC can't work without DMA; polled mode is not
supported / implemented.
--
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] mmc: omap_hsmmc: ensure probe returns error upon resource failure

2012-07-11 Thread S, Venkatraman
On Wed, Jul 11, 2012 at 5:10 AM, Kevin Hilman  wrote:
> If platform_get_resource_by_name() fails, driver probe is aborted an
> should return an error so the driver is not bound to the device.
>
> However, in the current error path of platform_get_resource_by_name(),
> probe returns zero since the return value (ret) is not properly set.
> With a zero return value, the driver core assumes probe was successful
> and will bind the driver to the device.
>
> Fix this by ensuring that probe returns an error code in this failure
> path.
>
> Signed-off-by: Kevin Hilman 

Good catch.
Acked-by: Venkatraman S 


> ---
>  drivers/mmc/host/omap_hsmmc.c |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 389a3ee..19e60e9 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1931,6 +1931,7 @@ static int __devinit omap_hsmmc_probe(struct 
> platform_device *pdev)
> res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
> if (!res) {
> dev_err(mmc_dev(host->mmc), "cannot get DMA TX channel\n");
> +   ret = -ENXIO;
> goto err_irq;
> }
> host->dma_line_tx = res->start;
> @@ -1938,6 +1939,7 @@ static int __devinit omap_hsmmc_probe(struct 
> platform_device *pdev)
> res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
> if (!res) {
> dev_err(mmc_dev(host->mmc), "cannot get DMA RX channel\n");
> +   ret = -ENXIO;
> goto err_irq;
> }
> host->dma_line_rx = res->start;
> --
> 1.7.9.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] mmc: omap_hsmmc: fix runtime suspend crash: add host checks in callbacks

2012-07-10 Thread S, Venkatraman
On Tue, Jul 10, 2012 at 7:47 PM, Kevin Hilman  wrote:
> "S, Venkatraman"  writes:
>
>> On Sat, Jul 7, 2012 at 5:56 AM, Kevin Hilman  wrote:
>>> Due to the way the driver core takes runtime PM references during
>>> probe, a driver's runtime PM callbacks may not be called until probe
>>> returns.  During probe, drvdata is set to the 'host' pointer but if
>>> probe fails, drvdata is set to NULL.
>>>
>>> The runtime PM callbacks currently blindly dereference this host
>>> pointer, but if probe fails, and the runtime PM callbacks are called
>>> after probe returns, a NULL pointer dereference will result.
>>>
>> Pardon my ignorance, but why would runtime suspend be called for a
>> device whose probe has failed ? AFAIK, MMC stack wouldn't make the
>> _enable()/disable() calls, which call runtime PM APIs, unless the
>> probe is successful.  Is there a stacktrace for the offending caller ?
>
> First thing to note: there are several error conditions *after*
> pm_runtime_enable() and the first _get_sync() are called.
>
> So here's what can happen:
>
> The driver core does a _get_noresume() before calling the driver's
> probe, so the runtime PM usecount is already 1 when the driver is
> called.  The _get_sync() in _probe enables the device and increases the
> usecount to 2.  The _put_sync() at the end of ->probe() will decrease
> the usecount to 1, but since the usecount is still non-zero, the
> driver's callbacks are still not called.  It's not until the driver core
> does its _put_sync (to balance the _get_noresume() that the usecount
> goes to zero and the driver's callbacks are called.
>
Thanks for the detailed explanation.
But pm_runtime_disable() is called in the error path, so shouldn't
it prevent the driver callbacks from being called ? (The docuementation
talks about disable_depth field, but it doesn't sound right that runtime
pm would be enabled before _probe() is called. So disable_depth should
be 1 when pm_runtime_disable is called in _probe error path, right ?)

> When probe succeeds, this all works fine.  However, if probe fails the
> host pointer is set to NULL, but the runtime PM callbacks are still
> called and attempt to dereference a NULL pointer.
>
>>> Fix this by simply checking to be sure the host pointer is non-NULL.
>>>
>>> Signed-off-by: Kevin Hilman 
>>> ---
>>> Applies to v3.5-rc5.  Fix is needed for v3.5-rc.
>>>
>> Can you please let me know which commit introduced this problem
>> in the first place ? There were not many changes in MMC PM code
>> in this merge window.
>
> I guess this problem is probably not a regression and has been around
> for some time.  It has not been seen because probe has not failed.
>
> In using recent l-o master though, with Russell's dmaengine changes
> merged, probe is failing for me becasue it can't allocate a DMA channel,
> and then I'm seeing this problem.
>
> Kevin

Ok. I'll let Chris decide on this - DMA engine is not yet in Linus's tree
though.
--
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] mmc: omap: add clk_prepare and clk_unprepare

2012-07-09 Thread S, Venkatraman
On Wed, Jun 27, 2012 at 2:19 PM, Rajendra Nayak  wrote:
> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> and clk_unprepare() for the hsmmc clocks.
>
> Signed-off-by: Rajendra Nayak 
> Cc: Chris Ball 
> Cc: Balaji T K 
> Cc: 
> Cc: Paul Walmsley 
> Cc: Mike Turquette 

Thanks Rajendra.
Acked-by: Venkatraman S 

> ---
>  drivers/mmc/host/omap_hsmmc.c |   14 +++---
>  1 files changed, 7 insertions(+), 7 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


Re: [PATCH] mmc: omap_hsmmc: fix runtime suspend crash: add host checks in callbacks

2012-07-09 Thread S, Venkatraman
On Sat, Jul 7, 2012 at 5:56 AM, Kevin Hilman  wrote:
> Due to the way the driver core takes runtime PM references during
> probe, a driver's runtime PM callbacks may not be called until probe
> returns.  During probe, drvdata is set to the 'host' pointer but if
> probe fails, drvdata is set to NULL.
>
> The runtime PM callbacks currently blindly dereference this host
> pointer, but if probe fails, and the runtime PM callbacks are called
> after probe returns, a NULL pointer dereference will result.
>
Pardon my ignorance, but why would runtime suspend be called for a
device whose probe has failed ? AFAIK, MMC stack wouldn't make
the _enable()/disable() calls, which call runtime PM APIs, unless the
probe is successful.
 Is there a stacktrace for the offending caller ?

> Fix this by simply checking to be sure the host pointer is non-NULL.
>
> Signed-off-by: Kevin Hilman 
> ---
> Applies to v3.5-rc5.  Fix is needed for v3.5-rc.
>
Can you please let me know which commit introduced this problem
in the first place ? There were not many changes in MMC PM code
in this merge window.
--
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: New compiler warnings with v3.5-rc

2012-06-28 Thread S, Venkatraman
On Thu, Jun 28, 2012 at 2:35 PM, Tero Kristo  wrote:
> On Thu, 2012-06-28 at 02:47 -0600, Paul Walmsley wrote:
>> Hi Tero,
>>
>> there are some new compiler warnings added in the v3.5-rc kernels:
>>
>> arch/arm/mach-omap2/twl-common.c:51:12: warning: 'twl_set_voltage' defined 
>> but not used
>> arch/arm/mach-omap2/twl-common.c:57:12: warning: 'twl_get_voltage' defined 
>> but not used
>>
>> They only seem to appear on my N800 builds:
>>
>> http://www.pwsan.com/omap/testlogs/am35xx_devel_3.6/20120628014213/build/build_20120628011813_log.txt
>>
>> but it looks like I somehow am not doing a 2430-specific build yet, so
>> they may be 24xx-common.
>>
>> Anyway they were probably added by:
>>
>> commit 49c008ecce1f9a549c12e8957668d60008ab0d79
>> Author: Tero Kristo 
>> Date:   Mon Feb 20 12:26:08 2012 +0200
>>
>>     arm: omap3: twl: add external controllers for core voltage regulators
>>
>>
>> Maybe you can put together a quick patch to fix these?
>
> Yea, I can do that. Can you provide your .config as reference?
>
You can generate one quickly using these steps..
make omap2plus_defconfig
scripts/config --disable ARCH_OMAP4
scripts/config --disable ARCH_OMAP3
make oldnoconfig
make uImage
... and it should expose the warning.
--
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 02/11] mmc: omap: add clk_prepare and clk_unprepare

2012-06-22 Thread S, Venkatraman
On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak  wrote:
> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> and clk_unprepare() for the mmc and hsmmc clocks as part of the drivers
> probe() and remove() routines.
>
> Signed-off-by: Rajendra Nayak 
> Cc: Chris Ball 
> Cc: Balaji T K 
> Cc: 

Rajendra,
  Can this be applied independently, or does this patch have a
dependency on other patches in the series ?
--
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: [CFT 03/11] mmc: omap_hsmmc: remove private DMA API implementation

2012-06-07 Thread S, Venkatraman
On Thu, Jun 7, 2012 at 4:37 PM, Russell King
 wrote:
> Remove the private DMA API implementation from omap_hsmmc, making it
> use entirely the DMA engine API.
>
> Signed-off-by: Russell King 

Tested this on 4430SDP with rootfs usage, untarring the kernel source
and compiling it natively.

Tested-by: Venkatraman S 

> ---
>  drivers/mmc/host/omap_hsmmc.c |  265 
> ++---
>  1 files changed, 64 insertions(+), 201 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


Re: [CFT 01/11] dmaengine: add OMAP DMA engine driver

2012-06-07 Thread S, Venkatraman
On Thu, Jun 7, 2012 at 6:10 PM, S, Venkatraman  wrote:
> On Thu, Jun 7, 2012 at 4:36 PM, Russell King
>  wrote:
>> Tested-by: Tony Lindgren 
>> Signed-off-by: Russell King 
>> ---
>>  drivers/dma/Kconfig      |    6 +
>>  drivers/dma/Makefile     |    1 +
>>  drivers/dma/omap-dma.c   |  522 
>> ++
>>  include/linux/omap-dma.h |   24 ++
>>  4 files changed, 553 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/dma/omap-dma.c
>>  create mode 100644 include/linux/omap-dma.h
>>
>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>> index eb2b60e..8be3bf6 100644
>> --- a/drivers/dma/Kconfig
>> +++ b/drivers/dma/Kconfig
>> @@ -261,6 +261,12 @@ config DMA_SA11X0
>>          SA-1110 SoCs.  This DMA engine can only be used with on-chip
>>          devices.
>>
>> +config DMA_OMAP
>> +       tristate "OMAP DMA support"
>> +       depends on ARCH_OMAP
>> +       select DMA_ENGINE
>> +       select DMA_VIRTUAL_CHANNELS
>> +
>>  config DMA_ENGINE
>>        bool
>>
>> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
>> index fc05f7d..ddc291a 100644
>> --- a/drivers/dma/Makefile
>> +++ b/drivers/dma/Makefile
>> @@ -29,3 +29,4 @@ obj-$(CONFIG_PCH_DMA) += pch_dma.o
>>  obj-$(CONFIG_AMBA_PL08X) += amba-pl08x.o
>>  obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o
>>  obj-$(CONFIG_DMA_SA11X0) += sa11x0-dma.o
>> +obj-$(CONFIG_DMA_OMAP) += omap-dma.o
>> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
>> new file mode 100644
>> index 000..500bc71
>> --- /dev/null
>> +++ b/drivers/dma/omap-dma.c
>> @@ -0,0 +1,522 @@
>> +/*
>> + * OMAP DMAengine support
>> + *
>> + * 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 "virt-dma.h"
> Russell,
>  I applied your entire series on 3.5-rc1 and build fails as it can't
> find virt-dma.h
> Perhaps a missed "git add" ?
>
Ok I reread your messages again and these 11 are based on the generic
dma-engine series.

>> +#include 
>> +
--
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: [CFT 01/11] dmaengine: add OMAP DMA engine driver

2012-06-07 Thread S, Venkatraman
On Thu, Jun 7, 2012 at 4:36 PM, Russell King
 wrote:
> Tested-by: Tony Lindgren 
> Signed-off-by: Russell King 
> ---
>  drivers/dma/Kconfig      |    6 +
>  drivers/dma/Makefile     |    1 +
>  drivers/dma/omap-dma.c   |  522 
> ++
>  include/linux/omap-dma.h |   24 ++
>  4 files changed, 553 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/dma/omap-dma.c
>  create mode 100644 include/linux/omap-dma.h
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index eb2b60e..8be3bf6 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -261,6 +261,12 @@ config DMA_SA11X0
>          SA-1110 SoCs.  This DMA engine can only be used with on-chip
>          devices.
>
> +config DMA_OMAP
> +       tristate "OMAP DMA support"
> +       depends on ARCH_OMAP
> +       select DMA_ENGINE
> +       select DMA_VIRTUAL_CHANNELS
> +
>  config DMA_ENGINE
>        bool
>
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index fc05f7d..ddc291a 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -29,3 +29,4 @@ obj-$(CONFIG_PCH_DMA) += pch_dma.o
>  obj-$(CONFIG_AMBA_PL08X) += amba-pl08x.o
>  obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o
>  obj-$(CONFIG_DMA_SA11X0) += sa11x0-dma.o
> +obj-$(CONFIG_DMA_OMAP) += omap-dma.o
> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> new file mode 100644
> index 000..500bc71
> --- /dev/null
> +++ b/drivers/dma/omap-dma.c
> @@ -0,0 +1,522 @@
> +/*
> + * OMAP DMAengine support
> + *
> + * 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 "virt-dma.h"
Russell,
  I applied your entire series on 3.5-rc1 and build fails as it can't
find virt-dma.h
Perhaps a missed "git add" ?

> +#include 
> +
--
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] Fix OMAP4 boot regression

2012-05-24 Thread S, Venkatraman
On Thu, May 24, 2012 at 2:34 PM, Russell King - ARM Linux
 wrote:
> Fix a boot regression in existing kernels causing:
>
> genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq XXX
>
> caused by 1c6c6952 (genirq: Reject bogus threaded irq requests).
>
> Signed-off-by: Russell King 
> --
>  drivers/mmc/host/omap_hsmmc.c |    2 +-

Thanks Russell.
The omap_hsmmc part of the change was already posted [1] and queued up
in mmc-next.

Regards,
Venkat.

[1] http://www.spinics.net/lists/linux-omap/msg70496.html

>  drivers/rtc/rtc-twl.c         |    2 +-
>  2 files changed, 2 insertions(+), 2 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


Re: [PATCH -next] mmc: omap_hsmmc: pass IRQF_ONESHOT to request_threaded_irq

2012-05-17 Thread S, Venkatraman
On Thu, May 17, 2012 at 7:57 AM, Ming Lei  wrote:
> The flag of IRQF_ONESHOT should be passed to request_threaded_irq,
> otherwise the following failure message should be dumped because
> hardware handler is defined as NULL:
>
> [    3.383483] genirq: Threaded irq requested with handler=NULL and
> !ONESHOT for irq 368
> [    3.392730] omap_hsmmc: probe of omap_hsmmc.0 failed with error -22
>
> The patch fixes one kernel hang bug which is caused by mmc card
> probe failure and root device can't be brought up.
>
> Signed-off-by: Ming Lei 
Right thing to do!
Acked-by: Venkatraman S 

> ---
>  drivers/mmc/host/omap_hsmmc.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index ebaf62a..9a7a60a 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1981,7 +1981,7 @@ static int __devinit omap_hsmmc_probe(struct 
> platform_device *pdev)
>                ret = request_threaded_irq(mmc_slot(host).card_detect_irq,
>                                           NULL,
>                                           omap_hsmmc_detect,
> -                                          IRQF_TRIGGER_RISING | 
> IRQF_TRIGGER_FALLING,
> +                                          IRQF_TRIGGER_RISING | 
> IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
>                                           mmc_hostname(mmc), host);
>                if (ret) {
>                        dev_dbg(mmc_dev(host->mmc),
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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: [PATCHv2 00/16] [FS, MM, block, MMC]: eMMC High Priority Interrupt Feature

2012-05-11 Thread S, Venkatraman
On Wed, May 9, 2012 at 6:15 AM, Minchan Kim  wrote:
> On 05/09/2012 01:31 AM, S, Venkatraman wrote:
>
>> On Tue, May 8, 2012 at 1:16 PM, Minchan Kim  wrote:
>>> On 05/03/2012 11:22 PM, Venkatraman S wrote:
>>>
>>>> Standard eMMC (Embedded MultiMedia Card) specification expects to execute
>>>> one request at a time. If some requests are more important than others, 
>>>> they
>>>> can't be aborted while the flash procedure is in progress.
>>>>
>>>> New versions of the eMMC standard (4.41 and above) specfies a feature
>>>> called High Priority Interrupt (HPI). This enables an ongoing transaction
>>>> to be aborted using a special command (HPI command) so that the card is 
>>>> ready
>>>> to receive new commands immediately. Then the new request can be submitted
>>>> to the card, and optionally the interrupted command can be resumed again.
>>>>
>>>> Some restrictions exist on when and how the command can be used. For 
>>>> example,
>>>> only write and write-like commands (ERASE) can be preempted, and the urgent
>>>> request must be a read.
>>>>
>>>> In order to support this in software,
>>>> a) At the top level, some policy decisions have to be made on what is
>>>> worth preempting for.
>>>>       This implementation uses the demand paging requests and swap
>>>> read requests as potential reads worth preempting an ongoing long write.
>>>>       This is expected to provide improved responsiveness for smarphones
>>>> with multitasking capabilities - example would be launch a email 
>>>> application
>>>> while a video capture session (which causes long writes) is ongoing.
>>>
>>>
>>> Do you have a number to prove it's really big effective?
>>
>> What type of benchmarks would be appropriate to post ?
>> As you know, the response time of a card would vary depending on
>> whether the flash device
>> has enough empty blocks to write into and doesn't have to resort to GC during
>> write requests.
>> Macro benchmarks like iozone etc would be inappropriate here, as they won't 
>> show
>> the latency effects of individual write requests hung up doing page
>> reclaim, which happens
>> once in a while.
>
>
> We don't have such special benchmark so you need time to think how to prove 
> it.
> IMHO, you can use run-many-x-apps.sh which checks elapsed time to activate 
> programs
> by posting by Wu long time ago.
>
> http://www.spinics.net/lists/linux-mm/msg09653.html
>
> Of course, your eMMC is used above 80~90% for triggering GC stress and
> your memory should be used up by dirty pages to happen reclaim.
>
>
>>>
>>> What I have a concern is when we got low memory situation.
>>> Then, writing speed for page reclaim is important for response.
>>> If we allow read preempt write and write is delay, it means read path takes 
>>> longer time to
>>> get a empty buffer pages in reclaim. In such case, it couldn't be good.
>>>
>>
>> I agree. But when writes are delayed anyway as it exceeds
>> hpi_time_threshold (the window
>> available for invoking HPI), it means that the device is in GC mode
>> and either read or write
>> could be equally delayed.  Note that even in case of interrupting a
>> write, a single block write
>> (which usually is too short to be interrupted, as designed) is
>> sufficient for doing a page reclaim,
>> and further write requests (including multiblock) would not be subject
>> to HPI, as they will
>> complete within the average time.
>
>
> My point is that it would be better for read to not preempt 
> write-for-page_reclaim.
> And we can identify it by PG_reclaim. You can get the idea.
>
> Anyway, HPI is only feature of a device of many storages and you are 
> requiring modification
> of generic layers although it's not big. So for getting justification and 
> attracting many
> core guys(MM,FS,BLOCK), you should provide data at least.
>
Hi Kim,
 Apologies for a delayed response. I am studying your suggestions and
will get back with
some changes and also some profiling data.
Regards,
Venkat.
--
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 14/16] mmc: block: Implement HPI invocation and handling logic.

2012-05-09 Thread S, Venkatraman
On Wed, May 9, 2012 at 2:05 PM,   wrote:
>
>> +static bool mmc_can_do_foreground_hpi(struct mmc_queue *mq,
>> +                     struct request *req, unsigned int thpi)
>> +{
>> +
>> +     /*
>> +      * If some time has elapsed since the issuing of previous write
>> +      * command, or if the size of the request was too small, there's
>> +      * no point in preempting it. Check if it's worthwhile to preempt
>> +      */
>> +     int time_elapsed = jiffies_to_msecs(jiffies -
>> +                     mq->mqrq_cur->mmc_active.mrq->cmd->started_time);
>> +
>> +     if (time_elapsed <= thpi)
>> +                     return true;
> Some host controllers (or DMA) has possibility to get the byte count of
> current transaction. It may be implemented as host api (similar to abort
> ops). Then you have more accurate estimation of worthiness.
>

Byte count returned by DMA or the HC doesn't mean that the data has
actually been
burnt into the device (due to internal buffering). This is one of the
reasons for
defining the CORRECTLY_PRG_SECTORS_NUM register in the standard which
can be queried to find how much was correctly written.
 Unfortunately it can only be queried after the abort has been issued.

>> +
>> +     return false;
>> +}
>
> Thanks, Kostya
>
--
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 01/16] FS: Added demand paging markers to filesystem

2012-05-08 Thread S, Venkatraman
On Tue, May 8, 2012 at 11:58 AM, mani  wrote:
> How about adding the AS_DMPG flag in the file -> address_space when getting
> a filemap_fault()
> so that we can treat the page fault pages as the high priority pages over
> normal read requests.
> How about changing below lines for the support of the pages those are
> requested for the page fault ?
>
>
> --- a/fs/mpage.c 2012-05-04 12:59:12.0 +0530
> +++ b/fs/mpage.c 2012-05-07 13:13:49.0 +0530
> @@ -408,6 +408,8 @@ mpage_readpages(struct address_space *ma
>     &last_block_in_bio, &map_bh,
>     &first_logical_block,
>     get_block);
> +   if(test_bit(AS_DMPG, &mapping->flags) && bio)
>
> + bio->bi_rw |= REQ_RW_DMPG
>     }
>     page_cache_release(page);
>     }
> --- a/include/linux/pagemap.h    2012-05-04 12:57:35.0 +0530
> +++ b/include/linux/pagemap.h    2012-05-07 13:15:24.0 +0530
> @@ -27,6 +27,7 @@ enum mapping_flags {
>  #if defined (CONFIG_BD_CACHE_ENABLED)
>     AS_DIRECT  =   __GFP_BITS_SHIFT + 4,  /* DIRECT_IO specified on file op
> */
>  #endif
> +   AS_DMPG  =   __GFP_BITS_SHIFT + 5,  /* DEMAND PAGE specified on file op
> */
>  };
>
>  static inline void mapping_set_error(struct address_space *mapping, int
> error)
>
> --- a/mm/filemap.c   2012-05-04 12:58:49.0 +0530
> +++ b/mm/filemap.c   2012-05-07 13:15:03.0 +0530
> @@ -1646,6 +1646,7 @@ int filemap_fault(struct vm_area_struct
>     if (offset >= size)
>     return VM_FAULT_SIGBUS;
>
> +   set_bit(AS_DMPG, &file->f_mapping->flags);
>     /*
>  * Do we have something in the page cache already?
>  */
>
> Will these changes have any adverse effect ?
>

Thanks for the example but I can't judge which of the two is the most
elegant or acceptable to maintainers.
I can test with your change and inform if it works.

> Thanks & Regards
> Manish
>
> On Mon, May 7, 2012 at 5:01 AM, Dave Chinner  wrote:
>>
>> On Thu, May 03, 2012 at 07:53:00PM +0530, Venkatraman S wrote:
>> > From: Ilan Smith 
>> >
>> > Add attribute to identify demand paging requests.
>> > Mark readpages with demand paging attribute.
>> >
>> > Signed-off-by: Ilan Smith 
>> > Signed-off-by: Alex Lemberg 
>> > Signed-off-by: Venkatraman S 
>> > ---
>> >  fs/mpage.c                |    2 ++
>> >  include/linux/bio.h       |    7 +++
>> >  include/linux/blk_types.h |    2 ++
>> >  3 files changed, 11 insertions(+)
>> >
>> > diff --git a/fs/mpage.c b/fs/mpage.c
>> > index 0face1c..8b144f5 100644
>> > --- a/fs/mpage.c
>> > +++ b/fs/mpage.c
>> > @@ -386,6 +386,8 @@ mpage_readpages(struct address_space *mapping,
>> > struct list_head *pages,
>> >                                       &last_block_in_bio, &map_bh,
>> >                                       &first_logical_block,
>> >                                       get_block);
>> > +                     if (bio)
>> > +                             bio->bi_rw |= REQ_RW_DMPG;
>>
>> Have you thought about the potential for DOSing a machine
>> with this? That is, user data reads can now preempt writes of any
>> kind, effectively stalling writeback and memory reclaim which will
>> lead to OOM situations. Or, alternatively, journal flushing will get
>> stalled and no new modifications can take place until the read
>> stream stops.
>>
>> This really seems like functionality that belongs in an IO
>> scheduler so that write starvation can be avoided, not in high-level
>> data read paths where we have no clue about anything else going on
>> in the IO subsystem
>>
>> Cheers,
>>
>> Dave.
>> --
>> Dave Chinner
>> da...@fromorbit.com
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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: [PATCHv2 00/16] [FS, MM, block, MMC]: eMMC High Priority Interrupt Feature

2012-05-08 Thread S, Venkatraman
On Tue, May 8, 2012 at 1:16 PM, Minchan Kim  wrote:
> On 05/03/2012 11:22 PM, Venkatraman S wrote:
>
>> Standard eMMC (Embedded MultiMedia Card) specification expects to execute
>> one request at a time. If some requests are more important than others, they
>> can't be aborted while the flash procedure is in progress.
>>
>> New versions of the eMMC standard (4.41 and above) specfies a feature
>> called High Priority Interrupt (HPI). This enables an ongoing transaction
>> to be aborted using a special command (HPI command) so that the card is ready
>> to receive new commands immediately. Then the new request can be submitted
>> to the card, and optionally the interrupted command can be resumed again.
>>
>> Some restrictions exist on when and how the command can be used. For example,
>> only write and write-like commands (ERASE) can be preempted, and the urgent
>> request must be a read.
>>
>> In order to support this in software,
>> a) At the top level, some policy decisions have to be made on what is
>> worth preempting for.
>>       This implementation uses the demand paging requests and swap
>> read requests as potential reads worth preempting an ongoing long write.
>>       This is expected to provide improved responsiveness for smarphones
>> with multitasking capabilities - example would be launch a email application
>> while a video capture session (which causes long writes) is ongoing.
>
>
> Do you have a number to prove it's really big effective?

What type of benchmarks would be appropriate to post ?
As you know, the response time of a card would vary depending on
whether the flash device
has enough empty blocks to write into and doesn't have to resort to GC during
write requests.
Macro benchmarks like iozone etc would be inappropriate here, as they won't show
the latency effects of individual write requests hung up doing page
reclaim, which happens
once in a while.

>
> What I have a concern is when we got low memory situation.
> Then, writing speed for page reclaim is important for response.
> If we allow read preempt write and write is delay, it means read path takes 
> longer time to
> get a empty buffer pages in reclaim. In such case, it couldn't be good.
>

I agree. But when writes are delayed anyway as it exceeds
hpi_time_threshold (the window
available for invoking HPI), it means that the device is in GC mode
and either read or write
could be equally delayed.  Note that even in case of interrupting a
write, a single block write
(which usually is too short to be interrupted, as designed) is
sufficient for doing a page reclaim,
and further write requests (including multiblock) would not be subject
to HPI, as they will
complete within the average time.
--
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 01/16] FS: Added demand paging markers to filesystem

2012-05-07 Thread S, Venkatraman
Mon, May 7, 2012 at 5:01 AM, Dave Chinner  wrote:
> On Thu, May 03, 2012 at 07:53:00PM +0530, Venkatraman S wrote:
>> From: Ilan Smith 
>>
>> Add attribute to identify demand paging requests.
>> Mark readpages with demand paging attribute.
>>
>> Signed-off-by: Ilan Smith 
>> Signed-off-by: Alex Lemberg 
>> Signed-off-by: Venkatraman S 
>> ---
>>  fs/mpage.c                |    2 ++
>>  include/linux/bio.h       |    7 +++
>>  include/linux/blk_types.h |    2 ++
>>  3 files changed, 11 insertions(+)
>>
>> diff --git a/fs/mpage.c b/fs/mpage.c
>> index 0face1c..8b144f5 100644
>> --- a/fs/mpage.c
>> +++ b/fs/mpage.c
>> @@ -386,6 +386,8 @@ mpage_readpages(struct address_space *mapping, struct 
>> list_head *pages,
>>                                       &last_block_in_bio, &map_bh,
>>                                       &first_logical_block,
>>                                       get_block);
>> +                     if (bio)
>> +                             bio->bi_rw |= REQ_RW_DMPG;
>
> Have you thought about the potential for DOSing a machine
> with this? That is, user data reads can now preempt writes of any
> kind, effectively stalling writeback and memory reclaim which will
> lead to OOM situations. Or, alternatively, journal flushing will get
> stalled and no new modifications can take place until the read
> stream stops.

This feature doesn't fiddle with the I/O scheduler's ability to balance
read vs write requests or handling requests from various process queues (CFQ).

Also, for block devices which don't implement the ability to preempt (and even
for older versions of MMC devices which don't implement this feature),
the behaviour
falls back to waiting for write requests to complete before issuing the read.

In low end flash devices, some requests might take too long than normal
due to background device maintenance (i.e flash erase / reclaim procedure)
kicking in in the context of an ongoing write, stalling them by several
orders of magnitude.

This implementation (See 14/16) does have several
checks and timers to see that it's not triggered very often.
In my tests, where I usually have a generous preemption time window, the abort
happens < 0.1% of the time.


>
> This really seems like functionality that belongs in an IO
> scheduler so that write starvation can be avoided, not in high-level
> data read paths where we have no clue about anything else going on
> in the IO subsystem

Indeed, the feature is built mostly in the low level device driver and
minor changes in the elevator. Changes above the block layer are only
about setting
attributes and transparent to their operation.

>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> da...@fromorbit.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 v2 06/16] block: treat DMPG and SWAPIN requests as special

2012-05-03 Thread S, Venkatraman
On Thu, May 3, 2012 at 8:08 PM, Jeff Moyer  wrote:
> Venkatraman S  writes:
>
>> From: Ilan Smith 
>>
>> When exp_swapin and exp_dmpg are set, treat read requests
>> marked with DMPG and SWAPIN as high priority and move to
>> the front of the queue.
>>
> [...]
>> +     if (bio_swapin(bio) && blk_queue_exp_swapin(q)) {
>> +             spin_lock_irq(q->queue_lock);
>> +             where = ELEVATOR_INSERT_FLUSH;
>> +             goto get_rq;
>> +     }
>> +
>> +     if (bio_dmpg(bio) && blk_queue_exp_dmpg(q)) {
>> +             spin_lock_irq(q->queue_lock);
>> +             where = ELEVATOR_INSERT_FLUSH;
>> +             goto get_rq;
>
> Is ELEVATOR_INSERT_FRONT not good enough?  It seems wrong to use _FLUSH,
> here.  If the semantics of ELEVATOR_INSERT_FLUSH are really what is
> required, then perhaps we need to have another think about the naming of
> these flags.
>
Actually - yes, ELEVATOR_INSERT_FRONT would do as well. In the
previous version of MMC stack,
we needed the _FLUSH to trigger the write operation that was to be
preempted, to check that
it actually works.


> Cheers,
> Jeff
>
> --
--
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 2/3] mmc: omap_hsmmc: Add fclk frequency to debufs

2012-04-18 Thread S, Venkatraman
On Thu, Apr 19, 2012 at 5:34 AM, Chris Ball  wrote:
> Hi,
>
> On Wed, Apr 18 2012, Venkatraman S wrote:
>> From: Viswanath Puttagunta 
>>
>> Add mmc functional clock frequency to list of
>> internal state variables to display for debug.
>>
>> Signed-off-by: Viswanath Puttagunta 
>> Signed-off-by: Venkatraman S 
>> ---
>>  drivers/mmc/host/omap_hsmmc.c |    5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>> index d15b149..d046ba2 100644
>> --- a/drivers/mmc/host/omap_hsmmc.c
>> +++ b/drivers/mmc/host/omap_hsmmc.c
>> @@ -1683,8 +1683,9 @@ static int omap_hsmmc_regs_show(struct seq_file *s, 
>> void *data)
>>       if (host->pdata->get_context_loss_count)
>>               context_loss = host->pdata->get_context_loss_count(host->dev);
>>
>> -     seq_printf(s, "mmc%d:\n ctx_loss:\t%d:%d\n\nregs:\n",
>> -                     mmc->index, host->context_loss, context_loss);
>> +     seq_printf(s, "mmc%d:\n ctx_loss:\t%d:%d\n fclk:\t\t%lu Hz\n\nregs:\n",
>> +             mmc->index, host->context_loss, context_loss,
>
> Minor nit, but it looks like this line breaks indentation.

It does ? I thought I actually fixed the indentation of the original
patch by removing a tabstop, as it was going
too far into the right.
checkpatch.pl doesn't complain about it.

>
>> +                     clk_get_rate(host->fclk));
>>
>>       if (host->suspended) {
>>               seq_printf(s, "host suspended, can't read registers\n");
>
> Thanks,
>
> - Chris.
> --
> Chris Ball      
> One Laptop Per Child
--
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/3] mmc: omap_hsmmc: release correct resource

2012-04-18 Thread S, Venkatraman
On Wed, Apr 18, 2012 at 3:28 PM, Russell King - ARM Linux
 wrote:
> On Wed, Apr 18, 2012 at 03:19:11PM +0530, Venkatraman S wrote:
>> From: Russell King - ARM Linux 
>
> Please correct this to "Russell King "
>
Ok.
--
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] mmc: omap_hsmmc: release correct resource

2012-04-16 Thread S, Venkatraman
On Sat, Apr 14, 2012 at 7:11 PM, Russell King - ARM Linux
 wrote:
> res can be one of several resources, as this variable is re-used several
> times during probe.  This can cause the wrong resource parameters to be
> passed to release_mem_region().
>
> Get the original memory resource before calling release_mem_region().
>
> Signed-off-by: Russell King 
> ---
>  drivers/mmc/host/omap_hsmmc.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index d12bdbe..4b2e1f0 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2027,7 +2027,9 @@ static int __devinit omap_hsmmc_probe(struct 
> platform_device *pdev)
>  err_alloc:
>        omap_hsmmc_gpio_free(pdata);
>  err:
> -       release_mem_region(res->start, resource_size(res));
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       if (res)
> +               release_mem_region(res->start, resource_size(res));
>        return ret;
>  }
>
> --

Thanks Russell. I'll send it to Chris to be queued for 3.4-fixes.
--
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 00/19] I2C updates

2012-04-10 Thread S, Venkatraman
On Tue, Apr 10, 2012 at 4:26 PM, Shubhrajyoti D  wrote:
> The patch series does the following
>
> - Warn fixes if CONFIG_PM_RUNTIME is not selected.
> - I2C register restore only if context if the context is lost
> - Bus busy recovery mechanism.
> - the reset is not done in init.
>
> v2 changes
> -Adds a patch to use devm_* functions
> -Also checks the return type of the get_sync and in case
>  of errors prevents register access.
> - In case of i2c remove register access was done without any
>  get_sync fix the same.
> - Adds a pdata function pointer to do context save restore
>
> v3 changes
> - Split the omap_i2c_isr to increase readability
> - Adds the restore flag patch for OMAP4 to the series
> - Make the i2c use SET_RUNTIME_PM_OPS
> v4 changes
> - Folds a patch from Tasslehoff to prevent any merge conflicts.
> - Prevents the XDUF flag to be set if the underflow condition is not met.
>
> v5 changes
> - Add consistency in the subject naming.
>
> v6 changes
> - As per discussion in [1] .Adds a patch to rename the 1p153 errata and
>  use the unique id instead as the section number in the recent errata
>  docs has changed.
>
>
> [1] http://www.spinics.net/lists/linux-i2c/msg07607.html
>
> Tested on omap4sdp and omap3sdp.
>
>
> The following changes since commit 258f742635360175564e9470eb060ff4d4b984e7:
>
>  modpost: Fix modpost license checking of vmlinux.o (2012-04-09 20:52:56 
> -0700)
>
> are available in the git repository at:
>  g...@gitorious.org:linus-tree/linus-tree.git i2c_omap-next

Minor nit:
You might want to indicate a git:// link instead of an ssh URL ?

>
>
> Jon Hunter (1):
>  I2C: OMAP: Correct I2C revision for OMAP3
>
> Shubhrajyoti D (16):
>  I2C: OMAP: make omap_i2c_unidle/idle functions depend on
>    CONFIG_PM_RUNTIME
>  I2C: OMAP: Remove reset at init
>  I2C: OMAP: I2C register restore only if context is lost
>  I2C: OMAP: Fix the interrupt clearing in OMAP4
>  I2C: OMAP: Fix the mismatch of pm_runtime enable and disable
>  I2C: OMAP: Optimise the remove code
>  I2C: OMAP: Fix the error handling
>  I2C: OMAP: Don't check if wait_for_completion_timeout() returns less
>    than zero
>  I2C: OMAP: use devm_* functions
>  I2C: OMAP: Fix the crash in i2c remove
>  I2C: OMAP: Handle error check for pm runtime
>  I2C: OMAP: Use SET_RUNTIME_PM_OPS
>  I2C: OMAP: make the read ready processing a separate function
>  I2C: OMAP: Do not set the XUDF if the underflow is not reached
>  I2C: OMAP: Rename the 1p153 to the erratum id i462
>  ARM: OMAP4: hwmod data: I2C: add flag for context restore
>
> Tasslehoff Kjappfot (1):
>  I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153
>
> Vikram Pandita (1):
>  I2C: OMAP: Recover from Bus Busy condition
>
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    3 +-
>  arch/arm/plat-omap/i2c.c                   |    3 +
>  drivers/i2c/busses/i2c-omap.c              |  342 
> +++-
>  include/linux/i2c-omap.h                   |    1 +
>  4 files changed, 194 insertions(+), 155 deletions(-)
>
> --
> 1.7.4.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 RESEND] Input: omap-keypad: dynamically handle register offsets

2012-04-06 Thread S, Venkatraman
On Tue, Apr 3, 2012 at 10:52 AM, Sourav Poddar  wrote:
> From: G, Manjunath Kondaiah 
>
> Keypad controller register offsets are different for omap4
> and omap5. Handle these offsets through static mapping and
> assign these mappings during run time.
>
> Signed-off-by: Felipe Balbi 
> Signed-off-by: G, Manjunath Kondaiah 
> Signed-off-by: Sourav Poddar 

FWIW,
Reviewed-by: Venkatraman S 

> ---
> Test Info
>  - Tested on omap4 sdp with 3.4-rc1
>  - Tested on omap5430evm with 3.1 custom kernel.
>  drivers/input/keyboard/Kconfig        |    6 +-
>  drivers/input/keyboard/omap4-keypad.c |  120 ++--
>  2 files changed, 100 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index f354813..9a0e1a9 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -511,10 +511,10 @@ config KEYBOARD_OMAP
>          To compile this driver as a module, choose M here: the
>          module will be called omap-keypad.
>
> -config KEYBOARD_OMAP4
> -       tristate "TI OMAP4 keypad support"
> +config KEYBOARD_OMAP4+
> +       tristate "TI OMAP4+ keypad support"
>        help
> -         Say Y here if you want to use the OMAP4 keypad.
> +         Say Y here if you want to use the OMAP4+ keypad.
>
>          To compile this driver as a module, choose M here: the
>          module will be called omap4-keypad.
> diff --git a/drivers/input/keyboard/omap4-keypad.c 
> b/drivers/input/keyboard/omap4-keypad.c
> index e809ac0..742e1e3 100644
> --- a/drivers/input/keyboard/omap4-keypad.c
> +++ b/drivers/input/keyboard/omap4-keypad.c
> @@ -68,6 +68,11 @@
>
>  #define OMAP4_MASK_IRQSTATUSDISABLE    0x
>
> +enum {
> +       KBD_REVISION_OMAP4 = 0,
> +       KBD_REVISION_OMAP5,
> +};
> +
>  struct omap4_keypad {
>        struct input_dev *input;
>
> @@ -76,11 +81,66 @@ struct omap4_keypad {
>
>        unsigned int rows;
>        unsigned int cols;
> +       unsigned int revision;
> +       u32 irqstatus;
> +       u32 irqenable;
>        unsigned int row_shift;
>        unsigned char key_state[8];
>        unsigned short keymap[];
>  };
>
> +static int kbd_read_irqstatus(struct omap4_keypad *keypad_data, u32 offset)
> +{
> +       return __raw_readl(keypad_data->base + offset);
> +}
> +
> +static int kbd_write_irqstatus(struct omap4_keypad *keypad_data,
> +                                               u32 offset, u32 value)
> +{
> +       return __raw_writel(value, keypad_data->base + offset);
> +}
> +
> +static int kbd_write_irqenable(struct omap4_keypad *keypad_data,
> +                                               u32 offset, u32 value)
> +{
> +       return __raw_writel(value, keypad_data->base + offset);
> +}
> +
> +static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
> +{
> +       if (keypad_data->revision == KBD_REVISION_OMAP4)
> +               return __raw_readl(keypad_data->base + offset);
> +       else if (keypad_data->revision == KBD_REVISION_OMAP5)
> +               return __raw_readl(keypad_data->base + offset + 0x10);
> +
> +       return -ENODEV;
> +}
> +
> +static void kbd_writel(struct omap4_keypad *keypad_data, u32 offset, u32 
> value)
> +{
> +       if (keypad_data->revision == KBD_REVISION_OMAP4)
> +               __raw_writel(value, keypad_data->base + offset);
> +       else if (keypad_data->revision == KBD_REVISION_OMAP5)
> +               __raw_writel(value, keypad_data->base + offset + 0x10);
> +}
> +
> +static int kbd_read_revision(struct omap4_keypad *keypad_data, u32 offset)
> +{
> +       int reg;
> +       reg = __raw_readl(keypad_data->base + offset);
> +       reg &= 0x03 << 30;
> +       reg >>= 30;
> +
> +       switch (reg) {
> +       case 1:
> +               return KBD_REVISION_OMAP5;
> +       case 0:
> +               return KBD_REVISION_OMAP4;
> +       default:
> +               return -ENODEV;
> +       }
> +}
> +
>  /* Interrupt handler */
>  static irqreturn_t omap4_keypad_interrupt(int irq, void *dev_id)
>  {
> @@ -91,12 +151,11 @@ static irqreturn_t omap4_keypad_interrupt(int irq, void 
> *dev_id)
>        u32 *new_state = (u32 *) key_state;
>
>        /* Disable interrupts */
> -       __raw_writel(OMAP4_VAL_IRQDISABLE,
> -                    keypad_data->base + OMAP4_KBD_IRQENABLE);
> +       kbd_write_irqenable(keypad_data, keypad_data->irqenable,
> +                       OMAP4_VAL_IRQDISABLE);
>
> -       *new_state = __raw_readl(keypad_data->base + OMAP4_KBD_FULLCODE31_0);
> -       *(new_state + 1) = __raw_readl(keypad_data->base
> -                                               + OMAP4_KBD_FULLCODE63_32);
> +       *new_state = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
> +       *(new_state + 1) = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
>
>        for (row = 0; row < keypad_data->rows; row++) {
>                changed = key_state[row] ^ keypad_data->key_state[row];
> @@ -121,12 +180,13 @@ static irqreturn_t omap4_keypad_interrupt

Re: [PATCH 0/8][git pull] mmc: omap: Assorted fixes for 3.4 merge window

2012-04-02 Thread S, Venkatraman
On Sun, Apr 1, 2012 at 10:10 AM, Chris Ball  wrote:
> Hi,
>
> On Fri, Mar 16 2012, Venkatraman S wrote:
>> Chris,
>>    Here are a group of fixes posted by Felipe and Balaji for the
>> OMAP hsmmc driver in the past few days.
>>    I've rebased them to the lastest mmc-next and posted them
>> here again. These have also been tested on OMAP4 development platform.
>>
>> Please feel to apply directly or pull if that's convenient.
>>
>> Changes since yesterday (v1):-
>>       Fixed formatting issues as suggested by Felipe
>>       Marked some patches for stable.
>>
>> The following changes since commit 5f0390f10c0e9c9c504cdbf4af802252628a2490:
>>
>>   mmc: omap_hsmmc: Avoid a regulator voltage change with dt (2012-03-14 
>> 11:33:20 -0400)
>>
>> are available in the git repository at:
>>
>>   git://github.com/svenkatr/linux.git omap-mmc-pending-for-3.4
>>
>> for you to fetch changes up to 8d54766b608915035b47616ea564e4e9b4dda29c:
>>
>>   mmc: omap4: hsmmc: fix module re-insertion (2012-03-16 11:38:41 +0530)
>
> I've just rebased mmc-next on top of 3.4-rc1, and now there are many
> conflicts against your tree -- please could you resend patches 3-8
> against that base?  I'll take them for 3.4, and will take patches 1-2
> for 3.5.
>
I've rebased patches 3-8 into a new branch (See below).
I'll send you 1-2 on top of 3.4-rc2 once it's out. Is it Ok ?
==
The following changes since commit a4dfa827bb5b9a984d4000ffb80134b9495e4d8a:

  mmc: sdio: Use empty system suspend/resume callbacks at the bus
level (2012-04-01 00:35:06 -0400)

are available in the git repository at:

  git://github.com/svenkatr/linux.git omap-mmc-fixes-3.4

for you to fetch changes up to 80f833a2f77b8d6464209c0bb00a39ad835356a0:

  mmc: omap4: hsmmc: fix module re-insertion (2012-04-02 12:26:47 +0530)


Balaji T K (3):
  mmc: omap: use runtime put sync in probe error patch
  mmc: omap: context save after enabling runtime pm
  mmc: omap4: hsmmc: fix module re-insertion

Felipe Balbi (3):
  mmc: host: omap_hsmmc: trivial cleanups
  mmc: host: omap_hsmmc: make it behave well as a module
  mmc: host: omap_hsmmc: convert to module_platform_driver

 drivers/mmc/host/omap_hsmmc.c |  181
+--
 1 file changed, 79 insertions(+), 102 deletions(-)

Regards,
Venkat.
--
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: Occasional crashes in suspend-resume with MMC transactions

2012-03-25 Thread S, Venkatraman
On Thu, Mar 22, 2012 at 9:43 PM, Bedia, Vaibhav  wrote:
> On Thu, Mar 22, 2012 at 21:36:36, S, Venkatraman wrote:
>> On Thu, Mar 22, 2012 at 8:13 PM, Bedia, Vaibhav  wrote:
>> > On Thu, Mar 22, 2012 at 19:57:16, S, Venkatraman wrote:
>> > [...]
>> >>
>> >> I see (in 3.3) that the host controller driver does a "return ret" and
>> >> that means the errors is propagated.
>> >> Where is the return code lost /overridden ?
>> >>
>> >
>> > The return code gets overridden due to the call to host->pdata->resume()
>> > which always returns 0.
>>
>> Thanks - I see what you mean. But the patch is clunky.
>> A clean fix would be to not capture the return code of resume() in
>> "ret" and let the old
>> value of ret be propagated as is.
>>
>
> I agree. However, right now there's a dev_dbg() which checks for the return 
> code.
> I could change the host->pdata->resume() and host->pdata->suspend() to not 
> return
> anything if that's acceptable.
>
That's a good idea.

> More importantly, is this the right fix or does the driver need some other fix
> to make sure that such suspend failures do not occur at all?

I will look into this - but haven't seen such failures here to know
what's behind the symptom.
--
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: Occasional crashes in suspend-resume with MMC transactions

2012-03-22 Thread S, Venkatraman
On Thu, Mar 22, 2012 at 8:13 PM, Bedia, Vaibhav  wrote:
> On Thu, Mar 22, 2012 at 19:57:16, S, Venkatraman wrote:
> [...]
>>
>> I see (in 3.3) that the host controller driver does a "return ret" and
>> that means the errors is propagated.
>> Where is the return code lost /overridden ?
>>
>
> The return code gets overridden due to the call to host->pdata->resume()
> which always returns 0.

Thanks - I see what you mean. But the patch is clunky.
A clean fix would be to not capture the return code of resume() in
"ret" and let the old
value of ret be propagated as is.

>
> static int omap_hsmmc_resume_cdirq(struct device *dev, int slot)
> {
>        struct omap_mmc_platform_data *mmc = dev->platform_data;
>
>        enable_irq(mmc->slots[0].card_detect_irq);
>        return 0;
> }
>
> Regards,
> Vaibhav
--
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: Occasional crashes in suspend-resume with MMC transactions

2012-03-22 Thread S, Venkatraman
On Thu, Mar 22, 2012 at 6:50 PM, Bedia, Vaibhav  wrote:
> On Thu, Mar 22, 2012 at 09:53:23, Bedia, Vaibhav wrote:
>> Hi,
>>
>> I am trying to do suspend-resume test with a file copy on MMC/SD going on
>> in the background. The test involves simply copying a 450MB file on an ext3
>> partition to the same partition under a different name.
>>
>> This is on an AM335x board which uses the omap_hsmmc driver.
>> The kernel is v3.2 and I have also applied the following patch
>>
>
> [...]
>
> I found that whenever this issue crops up, mmc_host_suspend() is not able to 
> claim the host
> And returns -EBUSY. omap_hsmmc driver does not pass on this error code to the 
> PM core and
> hence the suspend process continues. When the driver is made to return 
> -EBUSY, the suspend
> process gets aborted and the user can try suspending again. I am not sure 
> whether this sort
> of suspend failure is acceptable or the driver is doing something wrong. The 
> following
> workaround is what I came up with. Do this look a reasonable thing to do?
>
> ---
>
> From a4040dd1869b351a5fa29dacd08facf6e24df609 Mon Sep 17 00:00:00 2001
> From: Vaibhav Bedia 
> Date: Thu, 22 Mar 2012 17:14:49 +0530
> Subject: [PATCH 1/1] mmc: omap_hsmmc: Pass on the suspend failure to the PM 
> core
>
> In some cases mmc_host_suspend() is not able to claim the
> host and proceed with the suspend process. The core returns
> -EBUSY to the host controller driver. Unfortunately, the
> host controller driver does not pass on this information
> to the PM core and hence the system suspend process continues.
>
> In these cases the MMC core gets to an unexpected state
> during resume and multiple issues related to MMC crop up.
> 1. Host controller driver starts accessing the device registers
> before the clocks are enabled which leads to a prefetch abort.
> 2. A file copy thread which was launched before suspend gets
> stuck due to the host not being reclaimed during resume.
>
> To avoid such problems pass on the -EBUSY status to the PM core
> from the host controller driver. With this change, MMC core
> suspend might still fail but it does not end up making the
> system unusable. Suspend gets aborted and the user can try
> suspending the system again.
>
> Signed-off-by: Vaibhav Bedia 
> ---
>  drivers/mmc/host/omap_hsmmc.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 3d8dbbb..1f938d9 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2238,6 +2238,7 @@ static int omap_hsmmc_suspend(struct device *dev)
>                                        dev_dbg(mmc_dev(host->mmc),
>                                                "Unmask interrupt failed\n");
>                        }
> +                       ret = -EBUSY;
>                        goto err;
>                }
>
> --
> 1.7.0.4

I see (in 3.3) that the host controller driver does a "return ret" and
that means the errors is propagated.
Where is the return code lost /overridden ?
--
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 5/8] mmc: host: omap_hsmmc: trivial cleanups

2012-03-19 Thread S, Venkatraman
On Mon, Mar 19, 2012 at 11:27 AM, Hebbar, Gururaja
 wrote:
> On Fri, Mar 16, 2012 at 19:09:01, S, Venkatraman wrote:
>> From: Felipe Balbi 
>>
>> a bunch of non-functional cleanups to the omap_hsmmc
>> driver.
>>
>> It basically decreases indentation level, drop unneeded
>
> s/unneeded/unneeded. Better to use unnecessary
>
>> dereferences and drop unneded accesses to the platform_device
>
> Same as above
>
Thanks. Now updated as below (and pushed out to the same branch)..

>From 7174f9a831a8fcd224bf6dc1c2895e40fa252e84 Mon Sep 17 00:00:00 2001
From: Felipe Balbi 
Date: Wed, 14 Mar 2012 11:18:27 +0200
Subject: [PATCH] mmc: host: omap_hsmmc: trivial cleanups

a bunch of non-functional cleanups to the omap_hsmmc
driver.

It basically decreases indentation level, drop unneeded
dereferences and drop unnecessary accesses to the platform_device
structure.

Signed-off-by: Felipe Balbi 
Signed-off-by: Venkatraman S 
---
 drivers/mmc/host/omap_hsmmc.c |  147 -
 1 file changed, 70 insertions(+), 77 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 925d2be..cafd879 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2055,30 +2055,28 @@ static int omap_hsmmc_remove(struct
platform_device *pdev)
struct omap_hsmmc_host *host = platform_get_drvdata(pdev);
struct resource *res;

-   if (host) {
-   pm_runtime_get_sync(host->dev);
-   mmc_remove_host(host->mmc);
-   if (host->use_reg)
-   omap_hsmmc_reg_put(host);
-   if (host->pdata->cleanup)
-   host->pdata->cleanup(&pdev->dev);
-   free_irq(host->irq, host);
-   if (mmc_slot(host).card_detect_irq)
-   free_irq(mmc_slot(host).card_detect_irq, host);
-
-   pm_runtime_put_sync(host->dev);
-   pm_runtime_disable(host->dev);
-   clk_put(host->fclk);
-   if (host->got_dbclk) {
-   clk_disable(host->dbclk);
-   clk_put(host->dbclk);
-   }
+   pm_runtime_get_sync(host->dev);
+   mmc_remove_host(host->mmc);
+   if (host->use_reg)
+   omap_hsmmc_reg_put(host);
+   if (host->pdata->cleanup)
+   host->pdata->cleanup(&pdev->dev);
+   free_irq(host->irq, host);
+   if (mmc_slot(host).card_detect_irq)
+   free_irq(mmc_slot(host).card_detect_irq, host);

-   mmc_free_host(host->mmc);
-   iounmap(host->base);
-   omap_hsmmc_gpio_free(pdev->dev.platform_data);
+   pm_runtime_put_sync(host->dev);
+   pm_runtime_disable(host->dev);
+   clk_put(host->fclk);
+   if (host->got_dbclk) {
+   clk_disable(host->dbclk);
+   clk_put(host->dbclk);
}

+   mmc_free_host(host->mmc);
+   iounmap(host->base);
+   omap_hsmmc_gpio_free(pdev->dev.platform_data);
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res)
release_mem_region(res->start, resource_size(res));
@@ -2091,49 +2089,45 @@ static int omap_hsmmc_remove(struct
platform_device *pdev)
 static int omap_hsmmc_suspend(struct device *dev)
 {
int ret = 0;
-   struct platform_device *pdev = to_platform_device(dev);
-   struct omap_hsmmc_host *host = platform_get_drvdata(pdev);
+   struct omap_hsmmc_host *host = dev_get_drvdata(dev);

-   if (host && host->suspended)
+   if (!host)
return 0;

-   if (host) {
-   pm_runtime_get_sync(host->dev);
-   host->suspended = 1;
-   if (host->pdata->suspend) {
-   ret = host->pdata->suspend(&pdev->dev,
-   host->slot_id);
-   if (ret) {
-   dev_dbg(mmc_dev(host->mmc),
-   "Unable to handle MMC board"
-   " level suspend\n");
-   host->suspended = 0;
-   return ret;
-   }
-   }
-   ret = mmc_suspend_host(host->mmc);
+   if (host && host->suspended)
+   return 0;

+   pm_runtime_get_sync(host->dev);
+   host->suspended = 1;
+   if (host->pdata->suspend) {
+   ret = host->pdata->suspend(dev, host->slot_id);
if (ret) {
+   dev_dbg(dev, "Unable to handle MMC board"
+   "

Re: [PATCH v2 1/8] mmc: omap: Enable Auto CMD12

2012-03-16 Thread S, Venkatraman
On Fri, Mar 16, 2012 at 7:21 PM, Felipe Balbi  wrote:
> On Fri, Mar 16, 2012 at 07:08:57PM +0530, Venkatraman S wrote:
>> From: Balaji T K 
>>
>> Enable Auto-CMD12 for multi block read/write on HSMMC
>> Tested on OMAP4430, OMAP3430 and OMAP2430 SDP
>>
>> Signed-off-by: Balaji T K 
>> Signed-off-by: Venkatraman S 
>> ---
>>  drivers/mmc/host/omap_hsmmc.c |   16 +---
>>  1 file changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>> index f29e1a2..a9ffd70 100644
>> --- a/drivers/mmc/host/omap_hsmmc.c
>> +++ b/drivers/mmc/host/omap_hsmmc.c
>> @@ -85,6 +85,7 @@
>>  #define BRR_ENABLE           (1 << 5)
>>  #define DTO_ENABLE           (1 << 20)
>>  #define INIT_STREAM          (1 << 1)
>> +#define ACEN_ACMD12          (1 << 2)
>>  #define DP_SELECT            (1 << 21)
>>  #define DDIR                 (1 << 4)
>>  #define DMA_EN                       0x1
>> @@ -115,6 +116,7 @@
>>  #define OMAP_MMC_MAX_CLOCK   5200
>>  #define DRIVER_NAME          "omap_hsmmc"
>>
>> +#define AUTO_CMD12           (1 << 0)        /* Auto CMD12 support */
>>  /*
>>   * One controller can have multiple slots, like on some omap boards using
>>   * omap.c controller driver. Luckily this is not currently done on any known
>> @@ -175,6 +177,7 @@ struct omap_hsmmc_host {
>>       int                     reqs_blocked;
>>       int                     use_reg;
>>       int                     req_in_progress;
>> +     unsigned int            flags;
>>       struct omap_hsmmc_next  next_data;
>>
>>       struct  omap_mmc_platform_data  *pdata;
>> @@ -766,6 +769,8 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host, 
>> struct mmc_command *cmd,
>>               cmdtype = 0x3;
>>
>>       cmdreg = (cmd->opcode << 24) | (resptype << 16) | (cmdtype << 22);
>> +     if ((host->flags & AUTO_CMD12) && mmc_op_multi(cmd->opcode))
>> +             cmdreg |= ACEN_ACMD12;
>>
>>       if (data) {
>>               cmdreg |= DP_SELECT | MSBS | BCE;
>> @@ -837,11 +842,15 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host, 
>> struct mmc_data *data)
>>       else
>>               data->bytes_xfered = 0;
>>
>> -     if (!data->stop) {
>> +     if (data->stop && ((!(host->flags & AUTO_CMD12)) || data->error)) {
>> +             omap_hsmmc_start_command(host, data->stop, NULL);
>> +     }
>> +     else {
>
> while adding the braces, you broke the coding style. Please fix.
>

Oops - now fixed (and pushed out).

>From 00ae42358249e879698029201e3cbb9ea155305e Mon Sep 17 00:00:00 2001
From: Balaji T K 
Date: Fri, 24 Feb 2012 21:14:31 +0530
Subject: [PATCH] mmc: omap: Enable Auto CMD12

Enable Auto-CMD12 for multi block read/write on HSMMC
Tested on OMAP4430, OMAP3430 and OMAP2430 SDP

Signed-off-by: Balaji T K 
Signed-off-by: Venkatraman S 
---
 drivers/mmc/host/omap_hsmmc.c |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f29e1a2..729ac72 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -85,6 +85,7 @@
 #define BRR_ENABLE (1 << 5)
 #define DTO_ENABLE (1 << 20)
 #define INIT_STREAM(1 << 1)
+#define ACEN_ACMD12(1 << 2)
 #define DP_SELECT  (1 << 21)
 #define DDIR   (1 << 4)
 #define DMA_EN 0x1
@@ -115,6 +116,7 @@
 #define OMAP_MMC_MAX_CLOCK 5200
 #define DRIVER_NAME"omap_hsmmc"

+#define AUTO_CMD12 (1 << 0)/* Auto CMD12 support */
 /*
  * One controller can have multiple slots, like on some omap boards using
  * omap.c controller driver. Luckily this is not currently done on any known
@@ -175,6 +177,7 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+   unsigned intflags;
struct omap_hsmmc_next  next_data;

struct  omap_mmc_platform_data  *pdata;
@@ -766,6 +769,8 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host, struct mmc_command *cmd,
cmdtype = 0x3;

cmdreg = (cmd->opcode << 24) | (resptype << 16) | (cmdtype << 22);
+   if ((host->flags & AUTO_CMD12) && mmc_op_multi(cmd->opcode))
+   cmdreg |= ACEN_ACMD12;

if (data) {
cmdreg |= DP_SELECT | MSBS | BCE;
@@ -837,11 +842,14 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host
*host, struct mmc_data *data)
else
data->bytes_xfered = 0;

-   if (!data->stop) {
+   if (data->stop && ((!(host->flags & AUTO_CMD12)) || data->error)) {
+   omap_hsmmc_start_command(host, data->stop, NULL);
+   } else {
+   if (data->stop)
+   data->stop->resp[0] = OMAP_HSMMC_READ(host->base,
+   RSP76);
omap_hsmmc_request_done(host

Re: [PATCH RESEND 8/8] mmc: omap4: hsmmc: fix module re-insertion

2012-03-16 Thread S, Venkatraman
On Thu, Mar 15, 2012 at 8:34 PM, Felipe Balbi  wrote:
> Hi,
>
> On Thu, Mar 15, 2012 at 08:03:42PM +0530, Venkatraman S wrote:
>> From: Balaji T K 
>>
>> OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset.
>> Addng the offset to platform_device resource structure
>> increments the start address for every insmod operation.
>> MMC command fails on re-insertion as module due to incorrect register base.
>> Fix this by updating the ioremap base address only.
>>
>> Signed-off-by: Balaji T K 
>> ---
>>  drivers/mmc/host/omap_hsmmc.c |    4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>> index 4476b26..f324cf4 100644
>> --- a/drivers/mmc/host/omap_hsmmc.c
>> +++ b/drivers/mmc/host/omap_hsmmc.c
>> @@ -1813,8 +1813,6 @@ static int __devinit omap_hsmmc_probe(struct 
>> platform_device *pdev)
>>       if (res == NULL || irq < 0)
>>               return -ENXIO;
>>
>> -     res->start += pdata->reg_offset;
>> -     res->end += pdata->reg_offset;
>>       res = request_mem_region(res->start, resource_size(res), pdev->name);
>>       if (res == NULL)
>>               return -EBUSY;
>> @@ -1838,7 +1836,7 @@ static int __devinit omap_hsmmc_probe(struct 
>> platform_device *pdev)
>>       host->dma_ch    = -1;
>>       host->irq       = irq;
>>       host->slot_id   = 0;
>> -     host->mapbase   = res->start;
>> +     host->mapbase   = res->start + pdata->reg_offset;
>
> could this be done with a revision check at some point so we drop the
> pdata requirement ? Not part of $SUBJECT though, because you're just
> moving the increment.
>
That's a good idea. Will post that patch as part of another clean up series in
the pipeline.
--
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 RESEND 1/8] mmc: omap: Enable Auto CMD12

2012-03-15 Thread S, Venkatraman
On Thu, Mar 15, 2012 at 8:27 PM, Felipe Balbi  wrote:
> On Thu, Mar 15, 2012 at 08:03:35PM +0530, Venkatraman S wrote:
>> From: Balaji T K 
>>
>> Enable Auto-CMD12 for multi block read/write on HSMMC
>> Tested on OMAP4430, OMAP3430 and OMAP2430 SDP
>>
>> Signed-off-by: Balaji T K 
>
> BTW, since patches are flowing through you now, they should have your
> SoB line.
>

Sure. I'll edit and send again.
--
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] ARM: OMAP: hsmmc: add max_freq field

2012-03-02 Thread S, Venkatraman
On Fri, Mar 2, 2012 at 12:41 PM, S, Venkatraman  wrote:
> +Chris queues all MMC patches including omap_hsmmc.
> Ping ?
>
Just realized that it's already queued in mmc-next
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commitdiff;h=25d6ba8171995230b3757c78c7470fa76a931b98


>
> On Fri, Mar 2, 2012 at 5:41 AM, Tony Lindgren  wrote:
>> Hi,
>>
>> * Daniel Mack  [120217 05:13]:
>>> ping? Could anyone care for queueing this please?
>>
>> I suggest Rajendra queue up omap_hsmmc.c patches as he's already
>> patching it.
>>
>> Regards,
>>
>> Tony
>>
>>
>>> On Thu, Dec 29, 2011 at 2:22 PM, Daniel Mack  wrote:
>>> > On 12/23/2011 04:40 PM, T Krishnamoorthy, Balaji wrote:
>>> >> On Wed, Dec 14, 2011 at 6:52 PM, Daniel Mack  wrote:
>>> >>> diff --git a/drivers/mmc/host/omap_hsmmc.c 
>>> >>> b/drivers/mmc/host/omap_hsmmc.c
>>> >>> index 101cd31..8215ef9 100644
>>> >>> --- a/drivers/mmc/host/omap_hsmmc.c
>>> >>> +++ b/drivers/mmc/host/omap_hsmmc.c
>>> >>> @@ -1927,8 +1927,12 @@ static int __init omap_hsmmc_probe(struct 
>>> >>> platform_device *pdev)
>>> >>>        if (mmc_slot(host).vcc_aux_disable_is_sleep)
>>> >>>                mmc_slot(host).no_off = 1;
>>> >>>
>>> >>> -       mmc->f_min      = OMAP_MMC_MIN_CLOCK;
>>> >>> -       mmc->f_max      = OMAP_MMC_MAX_CLOCK;
>>> >>> +       mmc->f_min = OMAP_MMC_MIN_CLOCK;
>>> >>
>>> >> Stray change for f_min ?
>>> >
>>> > No, this was intended. The indentation doesn't make sense anymore when
>>> > not grouped with the f_max assignment.
>>> >
>>> > Other than that, what is necessary to get this picked? Tony? :)
>>> >
>>> >
>>> > Thanks,
>>> > Daniel
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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] ARM: OMAP: hsmmc: add max_freq field

2012-03-01 Thread S, Venkatraman
+Chris queues all MMC patches including omap_hsmmc.
Ping ?


On Fri, Mar 2, 2012 at 5:41 AM, Tony Lindgren  wrote:
> Hi,
>
> * Daniel Mack  [120217 05:13]:
>> ping? Could anyone care for queueing this please?
>
> I suggest Rajendra queue up omap_hsmmc.c patches as he's already
> patching it.
>
> Regards,
>
> Tony
>
>
>> On Thu, Dec 29, 2011 at 2:22 PM, Daniel Mack  wrote:
>> > On 12/23/2011 04:40 PM, T Krishnamoorthy, Balaji wrote:
>> >> On Wed, Dec 14, 2011 at 6:52 PM, Daniel Mack  wrote:
>> >>> diff --git a/drivers/mmc/host/omap_hsmmc.c 
>> >>> b/drivers/mmc/host/omap_hsmmc.c
>> >>> index 101cd31..8215ef9 100644
>> >>> --- a/drivers/mmc/host/omap_hsmmc.c
>> >>> +++ b/drivers/mmc/host/omap_hsmmc.c
>> >>> @@ -1927,8 +1927,12 @@ static int __init omap_hsmmc_probe(struct 
>> >>> platform_device *pdev)
>> >>>        if (mmc_slot(host).vcc_aux_disable_is_sleep)
>> >>>                mmc_slot(host).no_off = 1;
>> >>>
>> >>> -       mmc->f_min      = OMAP_MMC_MIN_CLOCK;
>> >>> -       mmc->f_max      = OMAP_MMC_MAX_CLOCK;
>> >>> +       mmc->f_min = OMAP_MMC_MIN_CLOCK;
>> >>
>> >> Stray change for f_min ?
>> >
>> > No, this was intended. The indentation doesn't make sense anymore when
>> > not grouped with the f_max assignment.
>> >
>> > Other than that, what is necessary to get this picked? Tony? :)
>> >
>> >
>> > Thanks,
>> > Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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 V2 1/1] mmc: start removing enable / disable API

2012-03-01 Thread S, Venkatraman
On Wed, Feb 29, 2012 at 12:47 PM, Adrian Hunter  wrote:
> Most parts of the enable / disable API are no longer used and
> can be removed.
>
> Cc: Rajendra Nayak 
> Cc: Venkatraman S 
> Cc: Kukjin Kim 
> Cc: Thomas Abraham 
> Cc: Kyungmin Park 
> Cc: Sekhar Nori 
> Cc: Kevin Hilman 
> Signed-off-by: Adrian Hunter 

Tested on OMAP4 SDP Platform
Tested-by: Venkatraman S 
> ---
>  arch/arm/mach-exynos/mach-nuri.c           |    5 +-
>  arch/arm/mach-exynos/mach-universal_c210.c |    9 +-
>  drivers/mmc/core/core.c                    |  187 
> +++-
>  drivers/mmc/core/host.c                    |    1 -
>  drivers/mmc/core/host.h                    |    1 -
>  drivers/mmc/host/davinci_mmc.c             |    4 -
>  drivers/mmc/host/omap_hsmmc.c              |   15 +--
>  include/linux/mmc/core.h                   |    1 -
>  include/linux/mmc/host.h                   |   46 +--
>  9 files changed, 27 insertions(+), 242 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/mach-nuri.c 
> b/arch/arm/mach-exynos/mach-nuri.c
> index 644af11..de68248 100644
> --- a/arch/arm/mach-exynos/mach-nuri.c
> +++ b/arch/arm/mach-exynos/mach-nuri.c
> @@ -109,7 +109,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc0_data 
> __initdata = {
>        .max_width              = 8,
>        .host_caps              = (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA |
>                                MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
> -                               MMC_CAP_DISABLE | MMC_CAP_ERASE),
> +                               MMC_CAP_ERASE),
>        .cd_type                = S3C_SDHCI_CD_PERMANENT,
>  };
>
> @@ -147,8 +147,7 @@ static struct platform_device emmc_fixed_voltage = {
>  static struct s3c_sdhci_platdata nuri_hsmmc2_data __initdata = {
>        .max_width              = 4,
>        .host_caps              = MMC_CAP_4_BIT_DATA |
> -                               MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
> -                               MMC_CAP_DISABLE,
> +                               MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
>        .ext_cd_gpio            = EXYNOS4_GPX3(3),      /* XEINT_27 */
>        .ext_cd_gpio_invert     = 1,
>        .cd_type                = S3C_SDHCI_CD_GPIO,
> diff --git a/arch/arm/mach-exynos/mach-universal_c210.c 
> b/arch/arm/mach-exynos/mach-universal_c210.c
> index 9b3fbae..57cfe61 100644
> --- a/arch/arm/mach-exynos/mach-universal_c210.c
> +++ b/arch/arm/mach-exynos/mach-universal_c210.c
> @@ -734,8 +734,7 @@ static struct platform_device universal_gpio_keys = {
>  static struct s3c_sdhci_platdata universal_hsmmc0_data __initdata = {
>        .max_width              = 8,
>        .host_caps              = (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA |
> -                               MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
> -                               MMC_CAP_DISABLE),
> +                               MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED),
>        .cd_type                = S3C_SDHCI_CD_PERMANENT,
>  };
>
> @@ -772,8 +771,7 @@ static struct platform_device mmc0_fixed_voltage = {
>  static struct s3c_sdhci_platdata universal_hsmmc2_data __initdata = {
>        .max_width              = 4,
>        .host_caps              = MMC_CAP_4_BIT_DATA |
> -                               MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
> -                               MMC_CAP_DISABLE,
> +                               MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
>        .ext_cd_gpio            = EXYNOS4_GPX3(4),      /* XEINT_28 */
>        .ext_cd_gpio_invert     = 1,
>        .cd_type                = S3C_SDHCI_CD_GPIO,
> @@ -783,8 +781,7 @@ static struct s3c_sdhci_platdata universal_hsmmc2_data 
> __initdata = {
>  static struct s3c_sdhci_platdata universal_hsmmc3_data __initdata = {
>        .max_width              = 4,
>        .host_caps              = MMC_CAP_4_BIT_DATA |
> -                               MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
> -                               MMC_CAP_DISABLE,
> +                               MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
>        .cd_type                = S3C_SDHCI_CD_EXTERNAL,
>  };
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 0b317f0..44dd013 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -605,105 +605,6 @@ unsigned int mmc_align_data_size(struct mmc_card *card, 
> unsigned int sz)
>  EXPORT_SYMBOL(mmc_align_data_size);
>
>  /**
> - *     mmc_host_enable - enable a host.
> - *     @host: mmc host to enable
> - *
> - *     Hosts that support power saving can use the 'enable' and 'disable'
> - *     methods to exit and enter power saving states. For more information
> - *     see comments for struct mmc_host_ops.
> - */
> -int mmc_host_enable(struct mmc_host *host)
> -{
> -       if (!(host->caps & MMC_CAP_DISABLE))
> -               return 0;
> -
> -       if (host->en_dis_recurs)
> -               return 0;
> -
>

Re: [PATCH v2 6/6] mmc: omap_hsmmc: Don't expect MMC1 to always have vmmc supply

2012-02-21 Thread S, Venkatraman
On Tue, Feb 21, 2012 at 3:33 PM, Rajendra Nayak  wrote:
>
> MMC1 is not the only instance that can be used/wired for SD.
> So remove this assumption from the driver.
>
> Now that all the mmc id based usage is removed, get rid
> of all the DEVID defines and also the 'id' field from the
> omap_hsmmc_host structure.
>
> Signed-off-by: Rajendra Nayak 
> Tested-by: Venkatraman S 
> Tested-by: Balaji T K 

For the whole series,
Acked-by: Venkatraman S 

> ---
>  drivers/mmc/host/omap_hsmmc.c |   31 ++-
>  1 files changed, 2 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 17e264b..e3eb9d4 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -106,17 +106,6 @@
>  #define SOFTRESET              (1 << 1)
>  #define RESETDONE              (1 << 0)
>
> -/*
> - * FIXME: Most likely all the data using these _DEVID defines should come
> - * from the platform_data, or implemented in controller and slot specific
> - * functions.
> - */
> -#define OMAP_MMC1_DEVID                0
> -#define OMAP_MMC2_DEVID                1
> -#define OMAP_MMC3_DEVID                2
> -#define OMAP_MMC4_DEVID                3
> -#define OMAP_MMC5_DEVID                4
> -
>  #define MMC_AUTOSUSPEND_DELAY  100
>  #define MMC_TIMEOUT_MS         20
>  #define OMAP_MMC_MIN_CLOCK     40
> @@ -164,7 +153,6 @@ struct omap_hsmmc_host {
>        void    __iomem         *base;
>        resource_size_t         mapbase;
>        spinlock_t              irq_lock; /* Prevent races with irq handler
> */
> -       unsigned int            id;
>        unsigned int            dma_len;
>        unsigned int            dma_sg_idx;
>        unsigned char           bus_mode;
> @@ -300,7 +288,6 @@ static int omap_hsmmc_set_power(struct device *dev,
> int slot, int power_on,
>  static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
>  {
>        struct regulator *reg;
> -       int ret = 0;
>        int ocr_value = 0;
>
>        mmc_slot(host).set_power = omap_hsmmc_set_power;
> @@ -308,15 +295,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
> *host)
>        reg = regulator_get(host->dev, "vmmc");
>        if (IS_ERR(reg)) {
>                dev_dbg(host->dev, "vmmc regulator missing\n");
> -               /*
> -               * HACK: until fixed.c regulator is usable,
> -               * we don't require a main regulator
> -               * for MMC2 or MMC3
> -               */
> -               if (host->id == OMAP_MMC1_DEVID) {
> -                       ret = PTR_ERR(reg);
> -                       goto err;
> -               }
>        } else {
>                host->vcc = reg;
>                ocr_value = mmc_regulator_get_ocrmask(reg);
> @@ -324,8 +302,8 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
> *host)
>                        mmc_slot(host).ocr_mask = ocr_value;
>                } else {
>                        if (!(mmc_slot(host).ocr_mask & ocr_value)) {
> -                               pr_err("MMC%d ocrmask %x is not
> supported\n",
> -                                       host->id,
> mmc_slot(host).ocr_mask);
> +                               pr_err("MMC ocrmask %x is not
> supported\n",
> +                                       mmc_slot(host).ocr_mask);
>                                mmc_slot(host).ocr_mask = 0;
>                                return -EINVAL;
>                        }
> @@ -358,10 +336,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
> *host)
>        }
>
>        return 0;
> -
> -err:
> -       mmc_slot(host).set_power = NULL;
> -       return ret;
>  }
>
>  static void omap_hsmmc_reg_put(struct omap_hsmmc_host *host)
> @@ -1791,7 +1765,6 @@ static int __init omap_hsmmc_probe(struct
> platform_device *pdev)
>        host->dev->dma_mask = &pdata->dma_mask;
>        host->dma_ch    = -1;
>        host->irq       = irq;
> -       host->id        = pdev->id;
>        host->slot_id   = 0;
>        host->mapbase   = res->start;
>        host->base      = ioremap(host->mapbase, SZ_4K);
> --
> 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 6/6] mmc: omap_hsmmc: Don't expect MMC1 to always have vmmc supply

2012-02-07 Thread S, Venkatraman
On Sat, Feb 4, 2012 at 8:21 PM, Rajendra Nayak  wrote:
> MMC1 is not the only instance that can be used/wired for SD.
> So remove this assumption from the driver.
>
> Signed-off-by: Rajendra Nayak 
> ---
>  drivers/mmc/host/omap_hsmmc.c |   14 --
>  1 files changed, 0 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 17e264b..97d3065 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -300,7 +300,6 @@ static int omap_hsmmc_set_power(struct device *dev, int 
> slot, int power_on,
>  static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
>  {
>        struct regulator *reg;
> -       int ret = 0;
>        int ocr_value = 0;
>
>        mmc_slot(host).set_power = omap_hsmmc_set_power;
> @@ -308,15 +307,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
> *host)
>        reg = regulator_get(host->dev, "vmmc");
>        if (IS_ERR(reg)) {
>                dev_dbg(host->dev, "vmmc regulator missing\n");
> -               /*
> -               * HACK: until fixed.c regulator is usable,
> -               * we don't require a main regulator
> -               * for MMC2 or MMC3
> -               */
> -               if (host->id == OMAP_MMC1_DEVID) {
> -                       ret = PTR_ERR(reg);
> -                       goto err;
> -               }
>        } else {
>                host->vcc = reg;
>                ocr_value = mmc_regulator_get_ocrmask(reg);
> @@ -358,10 +348,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
> *host)
>        }
>
>        return 0;
> -
> -err:
> -       mmc_slot(host).set_power = NULL;
> -       return ret;
>  }
>
>  static void omap_hsmmc_reg_put(struct omap_hsmmc_host *host)
> --

Almost all usage of the id field is gone, except for a trivial debug print.
Would be prudent to get rid of it entirely from struct omap_hsmmc_host.
--
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/6] mmc: omap_hsmmc: Clean up use/abuse of pdev->id

2012-02-07 Thread S, Venkatraman
On Sat, Feb 4, 2012 at 8:21 PM, Rajendra Nayak  wrote:
> This series mainly cleans up all instances of hardcoding's in
> the driver based on pdev->id. This is cleanup leading to the
> DT adaptation of omap_hsmmc driver.
>
> Patches are based on 3.3-rc2 and can be found here
> git://gitorious.org/omap-pm/linux.git omap_hsmmc_cleanup
>
> Tested the patches on my omap4 boards (panda and SDP) but
> haven't tested yet on omap3/2 since I did'nt have boards
> handy. So any testing on any omap3/2 boards is really
> appreciated.

I gave it a spin on Beagleboard-XM (OMAP3630) with root filesystem
on the SD card, and checked again on 4430SDP.

Tested-by: Venkatraman S 

>
> regards,
> Rajendra
>
> Balaji T K (3):
>  mmc: omap_hsmmc: use platform_get_resource_byname for tx/rx DMA
>    channels
>  mmc: omap_hsmmc: remove unused .set_sleep function
>  mmc: omap_hsmmc: Use OMAP_HSMMC_SUPPORTS_DUAL_VOLT flag to remove
>    host->id based hardcoding
>
> Rajendra Nayak (3):
>  mmc: omap_hsmmc: Get rid of omap_hsmmc_1_set_power function
>  mmc: omap_hsmmc: Get rid of omap_hsmmc_4_set_power function
>  mmc: omap_hsmmc: Don't expect MMC1 to always have vmmc supply
>
>  arch/arm/plat-omap/include/plat/mmc.h |    2 -
>  drivers/mmc/host/omap_hsmmc.c         |  158 
> +++--
>  2 files changed, 14 insertions(+), 146 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


Re: omap_hsmmc.c and MMC_CAP_SDIO_IRQ

2012-01-29 Thread S, Venkatraman
On Fri, Jan 27, 2012 at 7:39 PM, Steve Sakoman  wrote:
> On Tue, Jan 24, 2012 at 6:33 AM, Michael Hunold  wrote:
>> Hi,
>>
>> I am experimenting with an SDIO card on the Beagleboard. I have started
>> my experiments with Linux-3.1.4 some time ago and basically everything
>> is working.
>>
>> Except the fact that currently no native SDIO interrupts are used, but
>> the status register is polled to recognise the interrupts. Ugh.
>>
>> So I tried to find out the current state of MMC_CAP_SDIO_IRQ support.
>
> Your summary below is a pretty accurate description of the current state.
>
>> 0. No support for MMC_CAP_SDIO_IRQ in omap_hsmmc.c is present in mainline.
>>
>> 1. The "beagleboard-validation" kernel seems to have support for
>> MMC_CAP_SDIO_IRQ in omap_hsmmc.c:
>>
>> http://gitorious.org/beagleboard-validation/linux/blobs/beagleboardXM/drivers/mmc/host/omap_hsmmc.c
>>
>> But this is an ancient 2.6.32 kernel. I tried to use it anyway, but
>> compilation failed for me. I did not try to find the route cause of the
>> problem.
>>
>> 2. Another indication of MMC_CAP_SDIO_IRQ support in omap_hsmmc.c can be
>> found here:
>>
>> http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/recipes-kernel/linux/linux-omap-2.6.39/sakoman/0013-Enable-the-use-of-SDIO-card-interrupts.patch?id=1735237550d85da337ea57cb5d6be9ccc8c0355c
>>
>> I don't use Angstrom, so I just got a 2.6.39.4 kernel and tried to apply
>> that patch (and the
>> 0012-Don-t-turn-SDIO-cards-off-to-save-power.-Doing-so-wi.patch) patch
>> as well, but they did not apply cleanly.
>>
>> I tried to apply these patches to my 3.1.4 kernel, but of course they
>> did not apply cleanly either.
>
> Indeed, the structure of omap_hsmmc.c has changed significantly and
> applying those patches is not a trivial exercise.
>
> I've made an attempt at creating a patch for 3.2 that follows David
> Vrabel's original patch series as closely as possible with the new
> structure.
>
> Unfortunately it doesn't quite work.  I've only been doing this as a
> background task so progress is pretty slow.
>
> The patch doesn't seem to break support for memory devices (which is
> good since my rootfs is on an mmc device!) and I do see SDIO
> interrupts occurring and being handled in the debug log, so it is a
> good start:
>
> omap_hsmmc omap_hsmmc.1: enabled
> mmc1: starting CMD52 arg 10004000 flags 0195
> omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10004000
> omap_hsmmc omap_hsmmc.1: IRQ Status is 100
> Disabling SDIO interrupts
> omap_hsmmc omap_hsmmc.1: IRQ Status is 1
> mmc1: req done (CMD52): 0: 100a   
> mmc1: starting CMD53 arg 9294 flags 01b5
> mmc1:     blksz 148 blocks 1 flags 0100 tsac 1000 ms nsac 0
> omap_hsmmc omap_hsmmc.1: mmc1: CMD53, argument 0x9294
> omap_hsmmc omap_hsmmc.1: IRQ Status is 3
> mmc1: req done (CMD53): 0: 2000   
> mmc1:     148 bytes transferred: 0
> mmc1: starting CMD52 arg 1a00 flags 0195
> omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x1a00
> omap_hsmmc omap_hsmmc.1: IRQ Status is 1
> mmc1: req done (CMD52): 0: 1003   
> mmc1: starting CMD52 arg 9afc flags 0195
> omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x9afc
> omap_hsmmc omap_hsmmc.1: IRQ Status is 1
> mmc1: req done (CMD52): 0: 10fc   
> mmc1: starting CMD52 arg 10006800 flags 0195
> omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10006800
> omap_hsmmc omap_hsmmc.1: IRQ Status is 1
> mmc1: req done (CMD52): 0: 1012   
> mmc1: starting CMD52 arg 10006a00 flags 0195
> omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10006a00
> omap_hsmmc omap_hsmmc.1: IRQ Status is 1
> mmc1: req done (CMD52): 0: 1000   
> mmc1: starting CMD52 arg 10004000 flags 0195
> omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10004000
> omap_hsmmc omap_hsmmc.1: IRQ Status is 1
> mmc1: req done (CMD52): 0: 1009   
> mmc1: starting CMD53 arg 1214 flags 01b5
> mmc1:     blksz 20 blocks 1 flags 0200 tsac 1000 ms nsac 0
> omap_hsmmc omap_hsmmc.1: mmc1: CMD53, argument 0x1214
> omap_hsmmc omap_hsmmc.1: IRQ Status is 3
> mmc1: req done (CMD53): 0: 2000   
> mmc1:     20 bytes transferred: 0
> Enabling SDIO interrupts
> omap_hsmmc omap_hsmmc.1: IRQ Status is 100
> Disabling SDIO interrupts
> mmc1: starting CMD52 arg 1a00 flags 0195
> omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x1a00
> omap_hsmmc omap_hsmmc.1: IRQ Status is 1
> mmc1: req done (CMD52): 0: 1001   
> mmc1: starting CMD52 arg 9afe flags 0195
> omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x9afe
> omap_hsmmc omap_hsmmc.1: IRQ Status is 1
> mmc1: req done (CMD52): 0: 10fe   
> mmc1: starting CMD52 arg 10006800 flags 0195
> omap_hsmmc omap_hsmmc.1: mmc1: CMD

Re: OMAP CRAP: The Continuing Story Of Brokenness

2011-11-07 Thread S, Venkatraman
On Sun, Nov 6, 2011 at 5:48 PM, Russell King - ARM Linux
 wrote:
> Yet again I find that I'm having to email about crap on OMAP3.
>
> I'm getting really fed up with OMAP stuff which keeps breaking in
> idiotic ways - and the way there's fatal build errors at EVERY merge
> window.  The OMAP workflow is totally broken.  Something MUST change
> in the way the OMAP community works to stop the continual breakage
> at every single bloody merge window.
>
> One is new:
>
> WARNING: at arch/arm/mach-omap2/usb-musb.c:141 usb_musb_init+0xc0/0x174()
> usb_musb_init: could not find omap_hwmod for usb_otg_hs
> Modules linked in:
> Backtrace:
> [] (dump_backtrace+0x0/0x10c) from [] 
> (dump_stack+0x18/0x1c) r7:c181ff20 r6:c03ceb54 r5:c037545b r4:008d
> [] (dump_stack+0x0/0x1c) from [] 
> (warn_slowpath_common+0x58/0x70)
> [] (warn_slowpath_common+0x0/0x70) from [] 
> (warn_slowpath_fmt+0x38/0x40)
>  r8: r7:0013 r6:c0374b05 r5:c03f06e4 r4:c0374190
> [] (warn_slowpath_fmt+0x0/0x40) from [] 
> (usb_musb_init+0xc0/0x174)
>  r3:c02df894 r2:c03707d9
> [] (usb_musb_init+0x0/0x174) from [] 
> (omap_ldp_init+0xb0/0x100)
>  r6:c003e7d8 r5:c03f06e4 r4:c04053e4
> [] (omap_ldp_init+0x0/0x100) from [] 
> (customize_machine+0x24/0x30)
>  r4:c03f03a8
> [] (customize_machine+0x0/0x30) from [] 
> (do_one_initcall+0x9c/0x164)
> [] (do_one_initcall+0x0/0x164) from [] 
> (kernel_init+0x7c/0x120)
> [] (kernel_init+0x0/0x120) from [] (do_exit+0x0/0x62c)
>  r5:c03c3208 r4:
> ---[ end trace 1b75b31a2719ed1c ]---
>  omap_timer.1: alias fck already exists
>  omap_timer.2: alias fck already exists
>  omap_timer.3: alias fck already exists
>  omap_timer.4: alias fck already exists
>  omap_timer.5: alias fck already exists
>  omap_timer.6: alias fck already exists
>  omap_timer.7: alias fck already exists
>  omap_timer.8: alias fck already exists
>  omap_timer.9: alias fck already exists
>  omap_timer.10: alias fck already exists
>  omap_timer.11: alias fck already exists
>  omap_timer.12: alias fck already exists
>  omap-mcbsp.2: alias fck already exists
>  omap-mcbsp.3: alias fck already exists
>
> And this, which I reported on August 26th - so it's now over three months
> old is still there.  Clearly, no one cares about this driver so shall I
> delete the omap-hsmmc driver, or is someone going to clean up their crap?
> Or shall we revert all those patches for adding the asynchronous mapping
> of MMC requests until the _REGRESSION_ is fixed properly?
>
> mmcblk0: error -84 transferring data, sector 149209, nr 56, cmd response 
> 0x900,
> card status 0xb00
> [ cut here ]
> WARNING: at lib/dma-debug.c:865 check_unmap+0x1b0/0x76c()
> omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory it 
> has not allocated [device address=0x8000] [size=16384 bytes]
> Modules linked in:
> Backtrace:
> [] (dump_backtrace+0x0/0x10c) from [] 
> (dump_stack+0x18/0x1c) r7:c1af7cb0 r6:c018bfc8 r5:c038b4ff r4:0361
> [] (dump_stack+0x0/0x1c) from [] 
> (warn_slowpath_common+0x58/0x70)
> [] (warn_slowpath_common+0x0/0x70) from [] 
> (warn_slowpath_fmt+0x38/0x40)
>  r8:c1af7d48 r7: r6:4000 r5: r4:8000
> [] (warn_slowpath_fmt+0x0/0x40) from [] 
> (check_unmap+0x1b0/0x76c)
>  r3:c0375450 r2:c038b8f7
> [] (check_unmap+0x0/0x76c) from [] 
> (debug_dma_unmap_sg+0x100/0x134)
> [] (debug_dma_unmap_sg+0x0/0x134) from [] 
> (dma_unmap_sg+0x24/0x7c)
> [] (dma_unmap_sg+0x0/0x7c) from [] 
> (omap_hsmmc_post_req+0x48/0x54)
> [] (omap_hsmmc_post_req+0x0/0x54) from [] 
> (mmc_start_req+0x9c/0x128)
>  r4:c1ab2000
> [] (mmc_start_req+0x0/0x128) from [] 
> (mmc_blk_issue_rw_rq+0x80/0x4e8)
>  r8:c1aefc00 r7:c1aed800 r6:c1aefc24 r5:c1aed800 r4:c1aefc24
> [] (mmc_blk_issue_rw_rq+0x0/0x4e8) from [] 
> (mmc_blk_issue_rq+0x3f8/0x428)
> [] (mmc_blk_issue_rq+0x0/0x428) from [] 
> (mmc_queue_thread+0xa0/0x104)
> [] (mmc_queue_thread+0x0/0x104) from [] 
> (kthread+0x88/0x90)
> [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x62c)
>  r7:0013 r6:c003e7d8 r5:c0055b68 r4:c1831c5c
> ---[ end trace 1b75b31a2719ed1e ]---
>

This hsmmc issue is fixed by this patch sent out today..
http://marc.info/?l=linux-mmc&m=132068306510134&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: OMAP CRAP: The Continuing Story Of Brokenness

2011-11-06 Thread S, Venkatraman
On Sun, Nov 6, 2011 at 5:48 PM, Russell King - ARM Linux
 wrote:
> Yet again I find that I'm having to email about crap on OMAP3.
>
> I'm getting really fed up with OMAP stuff which keeps breaking in
> idiotic ways - and the way there's fatal build errors at EVERY merge
> window.  The OMAP workflow is totally broken.  Something MUST change
> in the way the OMAP community works to stop the continual breakage
> at every single bloody merge window.
>
> One is new:
>
> WARNING: at arch/arm/mach-omap2/usb-musb.c:141 usb_musb_init+0xc0/0x174()
> usb_musb_init: could not find omap_hwmod for usb_otg_hs
> Modules linked in:
> Backtrace:
> [] (dump_backtrace+0x0/0x10c) from [] 
> (dump_stack+0x18/0x1c) r7:c181ff20 r6:c03ceb54 r5:c037545b r4:008d
> [] (dump_stack+0x0/0x1c) from [] 
> (warn_slowpath_common+0x58/0x70)
> [] (warn_slowpath_common+0x0/0x70) from [] 
> (warn_slowpath_fmt+0x38/0x40)
>  r8: r7:0013 r6:c0374b05 r5:c03f06e4 r4:c0374190
> [] (warn_slowpath_fmt+0x0/0x40) from [] 
> (usb_musb_init+0xc0/0x174)
>  r3:c02df894 r2:c03707d9
> [] (usb_musb_init+0x0/0x174) from [] 
> (omap_ldp_init+0xb0/0x100)
>  r6:c003e7d8 r5:c03f06e4 r4:c04053e4
> [] (omap_ldp_init+0x0/0x100) from [] 
> (customize_machine+0x24/0x30)
>  r4:c03f03a8
> [] (customize_machine+0x0/0x30) from [] 
> (do_one_initcall+0x9c/0x164)
> [] (do_one_initcall+0x0/0x164) from [] 
> (kernel_init+0x7c/0x120)
> [] (kernel_init+0x0/0x120) from [] (do_exit+0x0/0x62c)
>  r5:c03c3208 r4:
> ---[ end trace 1b75b31a2719ed1c ]---
>  omap_timer.1: alias fck already exists
>  omap_timer.2: alias fck already exists
>  omap_timer.3: alias fck already exists
>  omap_timer.4: alias fck already exists
>  omap_timer.5: alias fck already exists
>  omap_timer.6: alias fck already exists
>  omap_timer.7: alias fck already exists
>  omap_timer.8: alias fck already exists
>  omap_timer.9: alias fck already exists
>  omap_timer.10: alias fck already exists
>  omap_timer.11: alias fck already exists
>  omap_timer.12: alias fck already exists
>  omap-mcbsp.2: alias fck already exists
>  omap-mcbsp.3: alias fck already exists
>
> And this, which I reported on August 26th - so it's now over three months
> old is still there.  Clearly, no one cares about this driver so shall I
> delete the omap-hsmmc driver, or is someone going to clean up their crap?
> Or shall we revert all those patches for adding the asynchronous mapping
> of MMC requests until the _REGRESSION_ is fixed properly?
>
Russell,
  I do apologize. I had posted a patch and didn't follow up on getting
it merged.
I will post a revised patch now.

> mmcblk0: error -84 transferring data, sector 149209, nr 56, cmd response 
> 0x900,
> card status 0xb00
> [ cut here ]
> WARNING: at lib/dma-debug.c:865 check_unmap+0x1b0/0x76c()
> omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory it 
> has not allocated [device address=0x8000] [size=16384 bytes]
> Modules linked in:
> Backtrace:
> [] (dump_backtrace+0x0/0x10c) from [] 
> (dump_stack+0x18/0x1c) r7:c1af7cb0 r6:c018bfc8 r5:c038b4ff r4:0361
> [] (dump_stack+0x0/0x1c) from [] 
> (warn_slowpath_common+0x58/0x70)
> [] (warn_slowpath_common+0x0/0x70) from [] 
> (warn_slowpath_fmt+0x38/0x40)
>  r8:c1af7d48 r7: r6:4000 r5: r4:8000
> [] (warn_slowpath_fmt+0x0/0x40) from [] 
> (check_unmap+0x1b0/0x76c)
>  r3:c0375450 r2:c038b8f7
> [] (check_unmap+0x0/0x76c) from [] 
> (debug_dma_unmap_sg+0x100/0x134)
> [] (debug_dma_unmap_sg+0x0/0x134) from [] 
> (dma_unmap_sg+0x24/0x7c)
> [] (dma_unmap_sg+0x0/0x7c) from [] 
> (omap_hsmmc_post_req+0x48/0x54)
> [] (omap_hsmmc_post_req+0x0/0x54) from [] 
> (mmc_start_req+0x9c/0x128)
>  r4:c1ab2000
> [] (mmc_start_req+0x0/0x128) from [] 
> (mmc_blk_issue_rw_rq+0x80/0x4e8)
>  r8:c1aefc00 r7:c1aed800 r6:c1aefc24 r5:c1aed800 r4:c1aefc24
> [] (mmc_blk_issue_rw_rq+0x0/0x4e8) from [] 
> (mmc_blk_issue_rq+0x3f8/0x428)
> [] (mmc_blk_issue_rq+0x0/0x428) from [] 
> (mmc_queue_thread+0xa0/0x104)
> [] (mmc_queue_thread+0x0/0x104) from [] 
> (kthread+0x88/0x90)
> [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x62c)
>  r7:0013 r6:c003e7d8 r5:c0055b68 r4:c1831c5c
> ---[ end trace 1b75b31a2719ed1e ]---
>
--
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] omap_hsmmc: fix missing parenthesis in pr_info

2011-11-03 Thread S, Venkatraman
On Thu, Nov 3, 2011 at 5:29 AM, Kevin Hilman  wrote:
> Hi Chris,
>
> Chris Ball  writes:
>
> [...]
>
>> Oops.  Thank you; I've pushed this to mmc-next now, and will send the
>> fix to Linus.  I've checked for other errors in the original patch.
>
> Where did you push this fix?
>
> I don't see this in the mmc-next branch of git://dev.laptop.org/users/cjb/mmc
>
MMC tree is back to kernel.org
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=summary
--
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/2] omap: hsmmc: Normalize dma cleanup operations

2011-09-14 Thread S, Venkatraman
On Tue, Sep 13, 2011 at 1:26 AM, Per Forlin  wrote:
> On 1 September 2011 21:05, Venkatraman S  wrote:
>> Reuse omap_hsmmc_dma_cleanup even for normal dma teardown in
>> omap_hsmmc_dma_cb. Consolidate multiple points of dma unmap into a
>> single location in post_req function, to prevent double unmapping.
> It's optional to use pre_req() and post_req(). The SDIO framework
> doesn't utilise these hooks. For instance this wont work together with
> SDIO-wlan on the pandaboard.
> If pre_req() has been issued it's fine to defer dma_unmap() until
> post_req(). If pre_req() is not called the driver should call
> dma_unmap() directly.
>

In that case, can the actual 'request' function just call pre_req and post_req
(at the beginning and at the end), if host_cookie is not set ?
--
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/2] omap: hsmmc: Normalize dma cleanup operations

2011-09-13 Thread S, Venkatraman
On Tue, Sep 13, 2011 at 1:26 AM, Per Forlin  wrote:
> On 1 September 2011 21:05, Venkatraman S  wrote:
>> Reuse omap_hsmmc_dma_cleanup even for normal dma teardown in
>> omap_hsmmc_dma_cb. Consolidate multiple points of dma unmap into a
>> single location in post_req function, to prevent double unmapping.
> It's optional to use pre_req() and post_req(). The SDIO framework
> doesn't utilise these hooks. For instance this wont work together with
> SDIO-wlan on the pandaboard.
> If pre_req() has been issued it's fine to defer dma_unmap() until
> post_req(). If pre_req() is not called the driver should call
> dma_unmap() directly.
>
Thanks for the clarification. I'll redo the fix.
--
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/2] OMAP: Update nr_irqs field in machine descriptors

2011-08-25 Thread S, Venkatraman
On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit  wrote:
> Hi Venkat,
>
> On 8/24/2011 9:46 PM, S, Venkatraman wrote:
>>
>> As part of an effort to get single ARM kernel binary [1],
>> multiple  definitions of NR_IRQS under various platforms
>> have to be reconciled and abstracted away from common code.
>>
>> This patch series takes the small step of populating the
>> machine descriptors with the pre-existing nr_irqs field.
>> Eventually, the common irq handler code will only look at this
>> field and not the compile time constant.
>
> Not related to this patch, but still on that topic. The current NR_IRQS
> depends as well on board stuff, like for example : the Phoenix
> IRQs:TWL6030_IRQ_BASE, TWL6040_CODEC_IRQ_BASE.
> Is there a plan to get rid of this static defines?
>

Currently, the goal is to get rid of the singleton nature
of NR_IRQS. Then it just becomes a property of the
platform, and the arm common code should not see this define.
This cleanup has to be done across multiple SoCs, not just OMAP.

After I get to complete some meaningful cleanup of NR_IRQS,
I can look into the static defines that you mention.

Best regards,
Venkat.
--
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: [PATCHv4 2/3] MMC: OMAP: HSMMC: add runtime pm support

2011-07-13 Thread S, Venkatraman
On Wed, Jul 13, 2011 at 8:29 PM, Kevin Hilman  wrote:
> "Dong, Chuanxiao"  writes:
>
> [...]
>
>>>
>>> Basially, the question is: can the driver be reworked such that a system
>>> suspend does not need to runtime resume the device?  For most devices,
>>> we kind of expect that if the device is runtime suspended, a system
>>> suspend will have nothing extra to do, but this driver runtime resumes
>>> the device during system suspend in order to do "stuff", which I
>>> admitedly don't fully undestand.
>>>
>>> Ideally, the "stuff" needed for runtime suspend and system suspend could
>>> be made to be common such that a system suspend of a runtime suspended
>>> device would be a noop.
>>>
>>> Is this possible?
>>>
>>> Kevin
>>
>> During system suspended patch, a callback named .prepare will be first
>> done before .suspend is called, and .complete callback will be called
>> after .resume is called. These two callbacks are in pair. If driver
>> can implement the .prepare and hold the usage count in this callback,
>> then runtime pm suspend/resume will not happen during device
>> suspending. So there will be no need to add pm_runtime_get* and
>> pm_runtime_put* in .suspend/.resume.
>
> That doesn't avoid the problem, since the device is still runtime
> resumed and then re-suspended during system suspend.
>
> My basic question is this: why does this device need to be runtime
> resumed during system suspend?  Why can't it just stay runtime
> suspended?
>

>From my understanding, the runtime suspend is usually implemented to not
lose the card 'context', i.e. transactions can continue after a
runtime suspend /
resume cycle.

For system suspend, the MMC core sends a sleep command (which, in itself,
is a transaction) to the card to go to sleep state, and for all
practical purposes,
the card is treated as 'removed'. When the system resumes, the card is rescanned
and re-initialized.

Hence, for system suspend, the MMC controller needs to be enabled to actually
send the command which puts the card to sleep (and hence the resume).

Best regards,
Venkat.
--
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: [PATCHv4 0/3] OMAP: HSMMC: cleanup and runtime pm

2011-07-04 Thread S, Venkatraman
> From: Kevin Hilman 
> Date: Fri, Jul 1, 2011 at 11:24 PM
> Subject: Re: [PATCHv4 0/3] OMAP: HSMMC: cleanup and runtime pm
> To: c...@laptop.org
> Cc: Balaji T K , linux-omap@vger.kernel.org,
> linux-...@vger.kernel.org, t...@atomide.com, madhu...@ti.com,
> b-cous...@ti.com, p...@pwsan.com, kishore.kadiy...@ti.com
>
>
> Chris,
>
> Balaji T K  writes:
>
>> Removing the custom state machine - lazy disable framework in
>> omap_hsmmc to make way for runtime pm to handle host controller power
>> states.
>>
>> This allows mmc_host_enable/mmc_host_disable to be replaced
>> by runtime get_sync and put_sync at host controller driver.
>>
>> Enable runtime PM in omap_hsmmc
>>
>> Rebased to MMC tree : mmc-next branch
>> Tested on OMAP4430SDP, OMAP3430SDP, OMAP2430SDP
>
> Reviewed-by: Kevin Hilman 
> Tested-by: Kevin Hilman 
>
> Could you queue this series for the v3.1 merge window?  Or, with your
> ack, we are happy to take this through the OMAP tree along with the
> other dependecies mentioned below.
>
> I've also tested this on OMAP4430/Blaze, OMAP3630/Zoom3 and
> OMAP3430/n900.
>
> We have OMAP PM core code changes queued for v3.1 which require the MMC
> driver to correctly use runtime PM or we can get hangs if MMC is used
> during boot.
>
> Kevin

Kevin,
  Another series from Per Forlin [1] is also modifying the same file,
and might result in merge conflict if this series is queued under OMAP
and the other is queued by Chris.

Chris,
  If you intend to queue [1] into mmc-next, Balaji / myself can repost
this series on
top of it or you'd like to practice some git merge ? Let me know if
there is anything that I can do to help.

[1] https://lkml.org/lkml/2011/7/1/303

>
>> MMC runtime patch has dependency on
>> [PATCH 0/6] OMAP2+: hwmod framework fixes [1]
>> for MMC1/MMC2 clock to get ungated after idle in OMAP4.
>>
>> Without [1] patches, MMC1/MMC2 fails to get detected on OMAP4.
>>
>> [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg51457.html
>>
>> Balaji T K (3):
>>   MMC: OMAP: HSMMC: Remove lazy_disable
>>   MMC: OMAP: HSMMC: add runtime pm support
>>   MMC: OMAP: HSMMC: Remove unused iclk
>>
>>  drivers/mmc/host/omap_hsmmc.c |  365 
>> +++--
>>  1 files changed, 57 insertions(+), 308 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


Re: [PATCH] MMC: OMAP: change HSMMC maintainence to Orphan

2011-07-04 Thread S, Venkatraman
On Fri, Jul 1, 2011 at 11:06 PM, Kevin Hilman  wrote:
> From: Madhusudhan Chikkature 
>
> Update the OMAP HS MMC entry from the MAINTAINERS file as I will
> no longer be able to maintain this driver.
>
> Signed-off-by: Madhusudhan Chikkature 
> [khil...@ti.com: change to Orphan rather than complete removal]
> Signed-off-by: Kevin Hilman 
> ---
> Applies to v3.0-rc5
>
>  MAINTAINERS |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f0358cd..2f238b5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4574,9 +4574,8 @@ S:        Maintained
>  F:     drivers/mmc/host/omap.c
>
>  OMAP HS MMC SUPPORT
> -M:     Madhusudhan Chikkature 
>  L:     linux-omap@vger.kernel.org
> -S:     Maintained
> +S:     Orphan
>  F:     drivers/mmc/host/omap_hsmmc.c
>
>  OMAP RANDOM NUMBER GENERATOR SUPPORT
> --
> 1.7.6
>
Note for the record:
I am interested in making sure that this driver is well supported, even if
not designated as 'official' maintainer due to other commitments (as of now).
Patches are welcome.

Acked-by: Venkatraman S 
--
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] OMAP: HSMMC maintainence

2011-06-30 Thread S, Venkatraman
On Fri, Jul 1, 2011 at 2:37 AM,   wrote:
> From: Madhusudhan Chikkature 
>
> Removing the OMAP HS MMC entry from the MAINTAINERS file as I will
> no longer be able to maintain this driver.
>
> Signed-off-by: Madhusudhan Chikkature 
> ---
>  MAINTAINERS |    6 --
>  1 files changed, 0 insertions(+), 6 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0094224..96061d2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4306,12 +4306,6 @@ L:       linux-omap@vger.kernel.org
>  S:     Maintained
>  F:     drivers/mmc/host/omap.c
>
> -OMAP HS MMC SUPPORT
> -M:     Madhusudhan Chikkature 
> -L:     linux-omap@vger.kernel.org
> -S:     Maintained
> -F:     drivers/mmc/host/omap_hsmmc.c
> -
>  OMAP RANDOM NUMBER GENERATOR SUPPORT
>  M:     Deepak Saxena 
>  S:     Maintained
> --
> 1.7.0.4
>

Hi Madhu,
 Thanks to your hard work and maintenance of OMAP MMC & good luck to
whatever you plan to do after this!!
For this patch, NAK :-)
It would be better to just change the status to 'Orphaned' than
deleting the entire section.
I hope that someone will step up to maintain it shortly..

Best regards,
Venkat.
--
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 2/3] MMC: OMAP: HSMMC: add runtime pm support

2011-06-29 Thread S, Venkatraman
On Thu, Jun 30, 2011 at 6:10 AM, Paul Walmsley  wrote:
> + Venkat
>
> Hi Balaji
>
> On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:
>
>> On Wed, Jun 29, 2011 at 2:00 AM, Kevin Hilman  wrote:
>> > "T Krishnamoorthy, Balaji"  writes:
>> >>
>> >> I have seen some instabilities if delay is very less, on some
>> >> production boards. The previous implementation used 100ms delay
>> >> before disabling the clocks.
>> >
>> > And your new one is using 50ms.  How did this value come about?
>>
>> I don't have any specific affinity to this number, but when requests are
>> bursty, they arrive within a few 10s of ms within each other. Didn't
>> want to have the context/save restore penalty associated with every
>> request.
>
> Kevin and I just chatted a little bit about this.  It seems best to
> separate the work done on the autosuspend timeout from the runtime PM
> conversion.
>
> So how about this: please send a new version of these patches with the
> previous value, 100ms, for the autosuspend timeout.  That should hopefully
> minimize the behavior change here for existing users.  And hopefully we'll
> be able to get the series in for this merge window.
>
> Then later, we need to come back to this autosuspend timeout issue.
>

Ok.
--
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 2/3] MMC: OMAP: HSMMC: add runtime pm support

2011-06-29 Thread S, Venkatraman
On Thu, Jun 30, 2011 at 1:37 AM, Paul Walmsley  wrote:
> cc'ing lakml
>
> Hi Venkat, Balaji,
>
> On Wed, 29 Jun 2011, S, Venkatraman wrote:
>
>> On Wed, Jun 29, 2011 at 9:08 PM, Paul Walmsley  wrote:
>> > On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:
>> >
>> >> There have been some experiments on our customer programs to reduce this
>> >> value to a few ms and infrequent crashes were observed (stress testing
>> >> for several hours) while trying to access the controller registers.
>> >
>> > By the way, could you send along a copy of the stress test script?
>> >
>>
>> Paul, these scenarios are not scripted but end user tests with
>> additional devices
>> (WLAN, which is connected on the same controller) and executed 'on field' .
>
> OK, thanks Venkat.  Do you still have one of these devices so the test can
> be repeated?
>
>> One such log is here .. http://pastebin.com/nq3cfZnT
>
> Looks like this is an Android 2.6.35.7-derived kernel on a 4430 ES2.2 EMU.
> Power management is enabled but MPU, L3INIT, and PER aren't entering any
> deeper power states than retention idle, so no context save/restore or
> off-mode worries here.
>
> The system looks like it's entered suspend at least once and resumed,
> before the oops.  Also the second CPU is starting up and shutting down
> dynamically.  Backtrace is copied below for the archives.
>
> Does the above summary match your understanding?

Yes it does.
>
> ...
>
> Reviewing this backtrace and the one that Balaji sent, it looks to
> me like this write in omap_hsmmc_prepare_data() is the proximate
> cause of the abort:
>
>        OMAP_HSMMC_WRITE(host->base, BLK, (req->data->blksz)
>                                        | (req->data->blocks << 16));
>
> I'll bet this was first access to the MMC IP block after the MMC layer
> re-enabled it.  The abort is imprecise because the Linux OMAP4 kernel
> marks MMIO registers as bufferable, so the ARM can continue executing
> while a register write is making its way across the OMAP interconnect(s).
> This guess also assumes that the ARM is executing instructions out of
> order, which is a reasonable assumption on a Cortex-A9.  This could be
> confirmed by reading some HSMMC register right before the
> OMAP_HSMMC_WRITE(); then the abort would turn precise and occur on the
> read.

Yes - The issue is not an issue with the set_data_timeout function but the
_first_ access to MMC IP register blocks after enabling the mmc_host.
(This backtrace signature is very common during MMC-PM hackathons )
  But I have not seen any difference if the access is read or write..
Will check again..

>
> Anyway, it looks like the HSMMC IP block wasn't yet ready to be accessed.
> Probably, this is because either the HSMMC IP block hasn't yet left the
> Idle or SleepTrans states, and the OMAP4 clock framework doesn't wait for
> that; or the PRCM is getting confused because the correct clockdomain
> enable sequence isn't being followed -- see for example the "Fix
> module-mode enable sequence on OMAP4" patch series that have been posted
> to the linux-omap mailing list.  Probably one of those two issues is the
> root cause.
>
> If you have a testing setup where you can reproduce this problem, I'd
> suggest adding the read as described above.  Otherwise, I don't think this
> will be an issue for the runtime PM conversion: first, because the hwmod
> code will wait for the HSMMC block to indicate that it has left idle
> before continuing; and second, because we'll hopefully have a patch series
> going in at the same time to make sure the clockdomain enable sequence is
> correct.
>

As you might have guessed, the test setup is not accessible for me and it's not
a simulated environment or scripted test. I'll try to check if some testcases
can be written to simulate this.

>
> - Paul
>
>
> <0> Process mmcqd (pid: 851, stack limit = 0xef9682f8)
> <0> Stack: (0xef969db8 to 0xef96a000)
> <0> 9da0:                                                       ef969ee4 
> efa30640
> <0> 9dc0: ef969e78  0001 efa30400 ef969e2c ef969de0 c06ae2b8 
> c06ace10
> <0> 9de0:  efa305d8 ef969e04 efa30400  efa30578 ef969e44 
> ef969e08
> <0> 9e00: c054ea5c ef969e78 efa30400 ef969e34 0001 ef837e4c  
> ef969ee4
> <0> 9e20: ef969e64 ef969e30 c06a54d8 c06adff4    
> 
> <0> 9e40: ef969e40 ef969e40 ed3d4680 ed3d4680 efa30c00 ef837e40 ef969f94 
> ef969e68
> <0> 9e60: c06abe80 c06a53cc  efa31458 ef0c

Re: [PATCH 2/3] MMC: OMAP: HSMMC: add runtime pm support

2011-06-29 Thread S, Venkatraman
On Wed, Jun 29, 2011 at 9:08 PM, Paul Walmsley  wrote:
> On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:
>
>> There have been some experiments on our customer programs to reduce this
>> value to a few ms and infrequent crashes were observed (stress testing
>> for several hours) while trying to access the controller registers.
>
> By the way, could you send along a copy of the stress test script?
>

Paul, these scenarios are not scripted but end user tests with
additional devices
(WLAN, which is connected on the same controller) and executed 'on field' .
One such log is here .. http://pastebin.com/nq3cfZnT
--
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] OMAP: HSMMC: Fix GPIO muxing

2011-06-28 Thread S, Venkatraman
On Tue, Jun 28, 2011 at 2:15 PM, Silesh C V  wrote:
> Use generic gpio call to check the validity of the gpio. Note that
> this includes gpio 0 also which was missing before.
>
> Signed-off-by: Silesh C V 
> ---
>  arch/arm/mach-omap2/hsmmc.c |    7 +++
>  1 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
> index 66868c5..a9b45c7 100644
> --- a/arch/arm/mach-omap2/hsmmc.c
> +++ b/arch/arm/mach-omap2/hsmmc.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -213,12 +214,10 @@ static int nop_mmc_set_power(struct device *dev, int 
> slot, int power_on,
>  static inline void omap_hsmmc_mux(struct omap_mmc_platform_data 
> *mmc_controller,
>                        int controller_nr)
>  {
> -       if ((mmc_controller->slots[0].switch_pin > 0) && \
> -               (mmc_controller->slots[0].switch_pin < OMAP_MAX_GPIO_LINES))
> +       if (gpio_is_valid(mmc_controller->slots[0].switch_pin))
>                omap_mux_init_gpio(mmc_controller->slots[0].switch_pin,
>                                        OMAP_PIN_INPUT_PULLUP);
> -       if ((mmc_controller->slots[0].gpio_wp > 0) && \
> -               (mmc_controller->slots[0].gpio_wp < OMAP_MAX_GPIO_LINES))
> +       if (gpio_is_valid(mmc_controller->slots[0].gpio_wp))
>                omap_mux_init_gpio(mmc_controller->slots[0].gpio_wp,
>                                        OMAP_PIN_INPUT_PULLUP);
>        if (cpu_is_omap34xx()) {
> --
> 1.7.1
>

Looks good to me.
Reviewed-by: Venkatraman S 
--
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: Testing cbus in N800

2011-06-05 Thread S, Venkatraman
Here is one attached which was known to be working (a few months ago,
I haven't tested recently)

Best regards,
Venkat.

On Mon, Jun 6, 2011 at 3:45 AM, Nicolau Werneck  wrote:
> Hello. I wanted to try the latest cbus patches in my N800. I
> downloaded the branch from
>
> git://gitorious.org/usb/usb.git cbus
>
> But there is no "defconfig" file for either N800 or N810. Does
> anybody have a config file ready to use?...
>
> Thanks,
>  ++nic
>
> --
> Nicolau Werneck           C3CF E29F 5350 5DAA 3705
> http://www.lti.pcs.usp.br/~nwerneck           7B9E D6C4 37BB DA64 6F15
> Linux user #460716
> "Object-oriented programming is an exceptionally bad idea which could only 
> have originated in California."
> -- Edsger Dijkstra
>


n8x0_defconfig
Description: Binary data


Re: cross compiling on Pandaboard

2011-05-30 Thread S, Venkatraman
Hi,
On Mon, May 30, 2011 at 2:56 PM, sureshbalijepalli
 wrote:
>
> Hi,
> Iam very new to the omap platforms . recetly i got(pandaboard). I
> ported ubuntu on it .
> please direct me how can i make a croos compilation .
>
>

I am not clear what exactly you are looking for.. The websites
www.pandaboard.org and www.omappedia.org contain most of the general
setup instructions for compiling / cross compiling Kernel and other
packages.
You might also want to subscribe to pandabo...@googlegroups.com
mailing list, if you have not done so already..

Regards,
Venkat.
--
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 08/22] mmc: omap_hsmmc: correct debug report error status mnemonics

2011-05-06 Thread S, Venkatraman
On Thu, May 5, 2011 at 5:21 PM, Adrian Hunter  wrote:
> CERR and BADA were in the wrong place and there are only
> 32 not 35.
>
> Signed-off-by: Adrian Hunter 
> ---
>  drivers/mmc/host/omap_hsmmc.c |   19 +++
>  1 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index bd52849..a1a1101 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -982,14 +982,14 @@ static void omap_hsmmc_dma_cleanup(struct 
> omap_hsmmc_host *host, int errno)
>  * Readable error output
>  */
>  #ifdef CONFIG_MMC_DEBUG
> -static void omap_hsmmc_report_irq(struct omap_hsmmc_host *host, u32 status)
> +static void omap_hsmmc_dbg_report_irq(struct omap_hsmmc_host *host, u32 
> status)
>  {
>        /* --- means reserved bit without definition at documentation */
>        static const char *omap_hsmmc_status_bits[] = {
> -               "CC", "TC", "BGE", "---", "BWR", "BRR", "---", "---", "CIRQ",
> -               "OBI", "---", "---", "---", "---", "---", "ERRI", "CTO", 
> "CCRC",
> -               "CEB", "CIE", "DTO", "DCRC", "DEB", "---", "ACE", "---",
> -               "---", "---", "---", "CERR", "CERR", "BADA", "---", "---", 
> "---"
> +               "CC"  , "TC"  , "BGE", "---", "BWR" , "BRR" , "---" , "---" ,
> +               "CIRQ", "OBI" , "---", "---", "---" , "---" , "---" , "ERRI",
> +               "CTO" , "CCRC", "CEB", "CIE", "DTO" , "DCRC", "DEB" , "---" ,
> +               "ACE" , "---" , "---", "---", "CERR", "BADA", "---" , "---"
>        };
>        char res[256];
>        char *buf = res;
> @@ -1006,6 +1006,11 @@ static void omap_hsmmc_report_irq(struct 
> omap_hsmmc_host *host, u32 status)
>
>        dev_dbg(mmc_dev(host->mmc), "%s\n", res);
>  }
> +#else
> +static inline void omap_hsmmc_dbg_report_irq(struct omap_hsmmc_host *host,
> +                                            u32 status)
> +{
> +}
>  #endif  /* CONFIG_MMC_DEBUG */
>
>  /*
> @@ -1064,9 +1069,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
> *host, int status)
>        dev_dbg(mmc_dev(host->mmc), "IRQ Status is %x\n", status);
>
>        if (status & ERR) {
> -#ifdef CONFIG_MMC_DEBUG
> -               omap_hsmmc_report_irq(host, status);
> -#endif
> +               omap_hsmmc_dbg_report_irq(host, status);
>                if ((status & CMD_TIMEOUT) ||
>                        (status & CMD_CRC)) {
>                        if (host->cmd) {
> --
> 1.7.0.4
>
I checked against the TRM and you are right.
FWIW,
 Reviewed-by: Venkatraman S 
--
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: SDHC card affected by preemption model in 2.6.35

2011-02-20 Thread S, Venkatraman
On Sun, Feb 20, 2011 at 10:42 PM, S, Venkatraman  wrote:
>
> On Fri, Feb 18, 2011 at 6:27 PM, Thomas Weber  wrote:
>>
>> Hello Mathieu, hello Venkat,
>>
>> I hope it is not too old and you remember this:
>> >
>> >   This provides a good 100ms window for delays due to scheduling 
>> > variations.
>> > I have to still find out which section is sensitive to it.
>> > Regards,
>> > Venkat.
>> > --
>>
>> We have a custom omap3 board and use kernel 2.6.37-rc8.  We have the
>> problem that we sometimes cannot mount our rootfs from sd-card. This
>> happens only when CONFIG_PREEMPT=y. When using CONFIG_PREEMPT_NONE or
>> enabling CONFIG_MMC_DEBUG everything works fine.
>>
>> The "100 ms patch" doesn't work for us. Do you found other solution(s)?
>>

No - I was working on some other things lately - I'll check this out this week.
What type of card are you using ?
Regards,
Venkat.
--
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: newbie: can I ask a question about linux-omap-pm on this mailing list?

2010-11-22 Thread S, Venkatraman
> Hi.
>
> I want to ask a newbie questions regarding linux-omap-pm 
> repositories(http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=summary).
>
> I know this mailing list is for the linux-omap repository. I have searched 
> the web for a mailing list specific for linux-omap-pm without success.
>
> Is this the right mailing list to pose my question?
> If not, can you point me to a better one?
>

You have come to the right place. The linux-omap-pm tree is maintained
by Kevin Hilman, and he checks this mailing list regularly.
Ask away...
--
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


build error: omap_ctrl_readl and omap_ctrl_writel undefined

2010-09-29 Thread S, Venkatraman
I am trying to build the master branch on linux-omap and I am getting
the following error on 'make modules'

Git log:

2365f1f | Wed, 29 Sep 2010 11:19:10 -0700 | Tony Lindgren | Linux-omap
rebuilt: Updated to v2.6.36-rc6, merged in few more patches
acc012f | Wed, 29 Sep 2010 11:19:00 -0700 | Tony Lindgren | Merge for-next
11f4559 | Wed, 29 Sep 2010 11:18:58 -0700 | Tony Lindgren | Merge omap-testing
03d0fcb | Wed, 29 Sep 2010 11:18:56 -0700 | Tony Lindgren | Merge omap-fixes
cddb52c | Wed, 29 Sep 2010 11:18:54 -0700 | Tony Lindgren | Merge cbu

Build error:
  LD [M]  net/wireless/cfg80211.o
  CC [M]  net/wireless/lib80211.o
ERROR: "omap_ctrl_writel" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined!
ERROR: "omap_ctrl_readl" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Regards,
Venkat.
--
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 RESEND] update omap3 features bitmap and API to generic names

2010-05-10 Thread S, Venkatraman
> -Original Message-
> From: menon.nisha...@gmail.com 
> [mailto:menon.nisha...@gmail.com] On Behalf Of Menon, Nishanth
> Sent: Tuesday, May 11, 2010 5:02 AM
> To: S, Venkatraman
> Cc: linux-omap@vger.kernel.org; 
> linux-arm-ker...@lists.infradead.org; Tony Lindgren; 
> Chikkature Rajashekar, Madhusudhan
> Subject: Re: [PATCH RESEND] update omap3 features bitmap and 
> API to generic names
> 
> On Mon, May 10, 2010 at 2:55 PM, Venkatraman S 
>  wrote:
> >        OMAP3 features bitmap is used a method to check for SoC 
> > specific features. This patch renames the global variables and the 
> > accessor functions to use a generic name from omap3_* to
> > omap_*
> >
> > Signed-off-by: Venkatraman S 
> > CC: Nishant Menon 
> Just for the patchworks
> NAK - discussed before - 
> http://marc.info/?l=linux-omap&m=127349696800651&w=2

This patch doesn't have the descriptor load changes, and just the rename.
Did you take a look at it first?
 
> > CC: Tony Lindgren 
> > CC: Madhusudhan Chikkature 
> > ---
> >  * Resent to CC Madhu
> >
> >  arch/arm/mach-omap2/clock3xxx_data.c  |    2 +-
> >  arch/arm/mach-omap2/id.c              |   18 
> >  arch/arm/plat-omap/include/plat/cpu.h |   34 
> > 
> >  3 files changed, 27 insertions(+), 27 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
> > b/arch/arm/mach-omap2/clock3xxx_data.c
> > index 9cba556..afa481d 100644
> > --- a/arch/arm/mach-omap2/clock3xxx_data.c
> > +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> > @@ -3510,7 +3510,7 @@ int __init omap3xxx_clk_init(void)
> >                        cpu_clkflg |= CK_3430ES2;
> >                }
> >        }
> > -       if (omap3_has_192mhz_clk())
> > +       if (omap_has_192mhz_clk())
> >                omap_96m_alwon_fck = omap_96m_alwon_fck_3630;
> >
> >        if (cpu_is_omap3630()) {
> > diff --git a/arch/arm/mach-omap2/id.c 
> b/arch/arm/mach-omap2/id.c index 
> > 37b8a1a..a095b87 100644
> > --- a/arch/arm/mach-omap2/id.c
> > +++ b/arch/arm/mach-omap2/id.c
> > @@ -28,7 +28,7 @@
> >  static struct omap_chip_id omap_chip;
> >  static unsigned int omap_revision;
> >
> > -u32 omap3_features;
> > +u32 omap_features;
> >
> >  unsigned int omap_rev(void)
> >  {
> > @@ -161,14 +161,14 @@ void __init omap24xx_check_revision(void)
> >  #define OMAP3_CHECK_FEATURE(status,feat)                   
>             
> > \
> >        if (((status & OMAP3_ ##feat## _MASK)                
>            
> > \
> >                >> OMAP3_ ##feat## _SHIFT) != FEAT_ ##feat## 
> _NONE) {   
> > \
> > -               omap3_features |= OMAP3_HAS_ ##feat;        
>             
> > \
> > +               omap_features |= OMAP_HAS_ ##feat;          
>             
> > + \
> >        }
> >
> >  void __init omap3_check_features(void)
> >  {
> >        u32 status;
> >
> > -       omap3_features = 0;
> > +       omap_features = 0;
> >
> >        status = omap_ctrl_readl(OMAP3_CONTROL_OMAP_STATUS);
> >
> > @@ -178,7 +178,7 @@ void __init omap3_check_features(void)
> >        OMAP3_CHECK_FEATURE(status, NEON);
> >        OMAP3_CHECK_FEATURE(status, ISP);
> >        if (cpu_is_omap3630())
> > -               omap3_features |= OMAP3_HAS_192MHZ_CLK;
> > +               omap_features |= OMAP_HAS_192MHZ_CLK;
> >
> >        /*
> >         * TODO: Get additional info (where applicable) @@ -294,7 
> > +294,7 @@ void __init omap4_check_revision(void)
> >  }
> >
> >  #define OMAP3_SHOW_FEATURE(feat)               \
> > -       if (omap3_has_ ##feat())                \
> > +       if (omap_has_ ##feat())         \
> >                printk(#feat" ");
> >
> >  void __init omap3_cpuinfo(void)
> > @@ -314,20 +314,20 @@ void __init omap3_cpuinfo(void)
> >                /*
> >                 * AM35xx devices
> >                 */
> > -               if (omap3_has_sgx()) {
> > +               if (omap_has_sgx()) {
> >                        omap_revision = OMAP3517_REV(rev);
> >                        strcpy(cpu_name, "AM3517");
> >                } else {
> >                        /* Already set in omap3_check_revision() */
> >                        strcpy(cpu_name, "AM3505");
> >                }
> > -       } else if (omap3_has_iva() && omap3_has_sgx()) {
> > +       } else if (oma

RE: [Patch v4] OMAP: sDMA driver: descriptor autoloading feature

2010-01-07 Thread S, Venkatraman
> Venkatraman S wrote: 
> > On Wed, Jan 6, 2010 at 6:46 PM, Adrian Hunter 
> > 
> > wrote: 
> > > Venkatraman S wrote: 
> > > > 
> > > > On Tue, Dec 29, 2009 at 3:18 AM, Tony Lindgren 
> 
> > wrote: 
> > > > > 
> > > > > * Venkatraman S  [091211 07:01]: 
> > > > > > 
> > > > > > Here is the most updated version of the patch (thanks to 
> > > > > > Russell's review). This patch is applicable to OMAP4xxx as 
> > > > > > well as OMAP3630 Reference to previous posts
> > > > > > v1  http://marc.info/?l=linux-omap&m=125012097403050&w=2
> > > > > > v2  http://marc.info/?l=linux-omap&m=125137152606644&w=2
> > > > > > v3  http://patchwork.kernel.org/patch/45408/
> > > > > 
> > > > > Do you have a patch for drivers/mmc/host/omap_hsmmc.c to use 
> > > > > this feature? Or some other driver?
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Tony
> > > > 
> > > > I am about to start working on omap_hsmmc to use the descriptor 
> > > > load feature. If the DMA changes are acceptable, I can post the 
> > > > driver patch as well.
> > > 
> > > I presume this is about performance.  How does it compare 
> to chained
> > DMA? 
> > > We have a patch for omap_hsmmc for chained DMA that we are still
> > testing. 
> > > 
> >  The main difference would be the number of logical channels used. 
> > With chaining, I assume you'd request for (or the API internally
> > reserves) as many logical channels as there are segments. Here a  
> >single logical channel would do.
> > 
> 
> How does the performance compare? Which is faster? Does 
> descriptor autoloading reduce the number of interrupts? 
> >>
> This should improve the perforamance compared to chaining  
> case. This features emulates scatter gather transfers 
> capability with minimum MPU support by removing the 
> successive channel configuration processing and the 
> associated interrupt handling overheads. 
> This is apart from optimize channel resources by enabling 
> efficient transfer “serialization” on a single logical 
> channel versus concurrent (multiple) logical channel usage. 
> 
> Regards,
> Santosh
> 

We have not done full benchmark tests yet, but as Santosh mentioned,
1) Only one logical channel is used.
2) No interrupts are generated till the end of transfer of the entire 
scatterlist.
(Infact, multiple scatterlists can be combined by the user driver to a single
descriptor list, and no IRQs would be generated till the entire transfer 
completes.
If needed, the descriptors can be programmed to generate interrupt(s) at any 
point.)
This should yield better performance / CPU utilization than chaining.

Regards,
Venkat.



[PATCH v3] OMAP4: sDMA driver: descriptor autoloading feature

2009-09-03 Thread S, Venkatraman
Comments received and fixed after previous posts
http://marc.info/?l=linux-omap&m=125012097403050&w=2  (v1)
http://marc.info/?l=linux-omap&m=125137152606644&w=2  (v2)

Summary:
OMAP sDMA driver changes for descriptor autoloading feature.
Signed-off-by: Venkatraman S 

---
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 7677a4a..3a75272 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -46,13 +47,42 @@ enum { DMA_CH_ALLOC_DONE, DMA_CH_PARAMS_SET_DONE, 
DMA_CH_STARTED,
 enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
 #endif

+/* CDP Register bitmaps */
+#define DMA_LIST_CDP_DST_VALID (BIT(0))
+#define DMA_LIST_CDP_SRC_VALID (BIT(2))
+#define DMA_LIST_CDP_TYPE1 (BIT(4))
+#define DMA_LIST_CDP_TYPE2 (BIT(5))
+#define DMA_LIST_CDP_TYPE3 (BIT(4) | BIT(5))
+#define DMA_LIST_CDP_PAUSEMODE (BIT(7))
+#define DMA_LIST_CDP_LISTMODE  (BIT(8))
+#define DMA_LIST_CDP_FASTMODE  (BIT(10))
+/* CAPS register bitmaps */
+#define DMA_CAPS_SGLIST_SUPPORT(BIT(20))
+
+#define DMA_LIST_DESC_PAUSE(BIT(0))
+#define DMA_LIST_DESC_SRC_VALID(BIT(24))
+#define DMA_LIST_DESC_DST_VALID(BIT(26))
+#define DMA_LIST_DESC_BLK_END  (BIT(28))
+
 #define OMAP_DMA_ACTIVE0x01
 #define OMAP_DMA_CCR_EN(1 << 7)
 #define OMAP2_DMA_CSR_CLEAR_MASK   0xffe

 #define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
+#define OMAP_DMA_INVALID_FRAME_COUNT   (0x)
+#define OMAP_DMA_INVALID_ELEM_COUNT(0xff)
+#define OMAP_DMA_INVALID_DESCRIPTOR_POINTER(0xfffc)

 static int enable_1510_mode;
+static int dma_caps0_status;
+
+struct omap_dma_list_config_params {
+   int chid;
+   int num_elem;
+   struct omap_dma_sglist_node *sghead;
+   int sgheadphy;
+   int pausenode;
+};

 struct omap_dma_lch {
int next_lch;
@@ -72,6 +102,8 @@ struct omap_dma_lch {

int status;
 #endif
+
+   void *list_config;
long flags;
 };

@@ -209,6 +241,12 @@ static void clear_lch_regs(int lch)
__raw_writew(0, lch_base + i);
 }

+static inline void omap_dma_list_set_ntype(struct omap_dma_sglist_node *node,
+  int value)
+{
+   node->num_of_elem |= ((value) << 29);
+}
+
 void omap_set_dma_priority(int lch, int dst_port, int priority)
 {
unsigned long reg;
@@ -1787,6 +1825,269 @@ EXPORT_SYMBOL(omap_get_dma_chain_src_pos);
 #endif /* ifndef CONFIG_ARCH_OMAP1 */

 
/**/
+int omap_request_dma_sglist(int dev_id, const char *dev_name,
+   void (*callback) (int channel_id, u16 ch_status, void *data),
+   int *listid, int nelem, struct omap_dma_sglist_node **elems)
+{
+   struct omap_dma_list_config_params *lcfg;
+   struct omap_dma_sglist_node *desc;
+   int dma_lch;
+   int rc, i;
+
+   if (unlikely((dma_caps0_status & DMA_CAPS_SGLIST_SUPPORT) == 0)) {
+   printk(KERN_ERR "omap DMA: sglist feature not supported\n");
+   return -EPERM;
+   }
+   if (unlikely(nelem <= 2)) {
+   printk(KERN_ERR "omap DMA: Need >2 elements in the list\n");
+   return -EINVAL;
+   }
+   rc = omap_request_dma(dev_id, dev_name,
+ callback, NULL, &dma_lch);
+   if (rc < 0) {
+   printk(KERN_ERR "omap_dma_list: Request failed %d\n", rc);
+   return rc;
+   }
+   *listid = dma_lch;
+   dma_chan[dma_lch].state = DMA_CH_NOTSTARTED;
+   lcfg = kmalloc(sizeof(*lcfg), GFP_KERNEL);
+   if (NULL == lcfg)
+   goto error1;
+   dma_chan[dma_lch].list_config = lcfg;
+
+   lcfg->num_elem = nelem;
+
+   *elems = desc = lcfg->sghead = dma_alloc_coherent(NULL,
+   sizeof(*desc), &(lcfg->sgheadphy), 0);
+   if (NULL == desc)
+   goto error1;
+
+   for (i = 1; i < nelem; i++) {
+   desc->next = dma_alloc_coherent(NULL,
+   sizeof(*(desc->next)), &(desc->next_desc_add_ptr), 0);
+   if (NULL == desc->next)
+   goto error1;
+   desc = desc->next;
+   desc->next = NULL;
+   }
+   desc->next_desc_add_ptr = OMAP_DMA_INVALID_DESCRIPTOR_POINTER;
+
+   dma_write(0, CCDN(dma_lch)); /* Reset List index numbering */
+   /* Initialize frame and element counters to invalid values */
+   dma_write(OMAP_DMA_INVALID_FRAME_COUNT, CCFN(dma_lch));
+   dma_write(OMAP_DMA_INVALID_ELEM_COUNT, CCEN(dma_lch));
+   return 0;
+
+error1:
+   omap_release_dma_sglist(dma_lch);
+   return -ENOMEM;
+
+}
+EXPORT_SYMBOL(omap_request_dma_sglist);
+
+/* The client can choose to not preconfigure the DMA registers
+ * In fast mode,the DMA controller uses the first element in the list to
+ * program the registers

RE: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor autoloading feature

2009-09-03 Thread S, Venkatraman
> -Original Message-
> From: Shilimkar, Santosh 
> Sent: Monday, August 31, 2009 11:41 PM
> To: S, Venkatraman; linux-omap@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Subject: RE: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor 
> autoloading feature
> 
> Venkat,
> Few comments other wise patch looks fine to me.

I am sending a new version with the changes. Can you please Ack ?
Thanks,

Venkat.--
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][RFC] OMAP4: sDMA driver: descriptor autoloading feature

2009-09-01 Thread S, Venkatraman
Santosh, 

> -Original Message-
> From: Shilimkar, Santosh 
> Sent: Monday, August 31, 2009 11:41 PM
> To: S, Venkatraman; linux-omap@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Subject: RE: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor 
> autoloading feature

> > 
> > 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.
> Would it be good if we move this description just above those 
> APIs. Even though this information is good to be here but 
> later once merged, this would go in commit history.
> Somebody reading code also would benefit from this info. I 
> leave that decision to you.

Agreed partly. Consistent with rest of the source tree,
 I don't like to fit a complete user guide in here.
But I'll repost the patch with some brief API comments.

> > 3) Descriptor types
> >3 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.
> 
> This information too should be in source code somewhere.

Ditto

> > +int omap_request_dma_sglist(int dev_id, const char *dev_name,
> > +   void (*callback) (int channel_id, u16 ch_status, void *data),
> > +   int *listid, int nelem, struct omap_dma_sglist_node **elems) {
> > +   struct omap_dma_list_config_params *lcfg;
> > +   struct omap_dma_sglist_node *desc;
> > +   int dma_lch;
> > +   int rc, i;
> > +
> > +   if (unlikely((dma_caps0_status & 
> DMA_CAPS_SGLIST_SUPPORT) == 0)) {
> > +   printk(KERN_ERR "omap DMA: sglist feature not 
> supported\n");
> > +   return -EPERM;
> > +   }
> Don't you need this check in all exported Descriptor API's ?
> 

Just adds clutter. The request_* API is the first one to be called,
and the driver above has to respect the error code and not make 
further configuration requests.
 If not, it is  equally likely on OMAP4 and the check would pass, but create 
havoc.
Short answer: Can't defend against poor programming.
Perhaps a omap_dma_is_sg_capable() API is needed ? That doesn't scale for
all the drivers & capabilities. Please comment.

> > +   if (unlikely(nelem <= 2)) {
> > +   printk(KERN_ERR "omap DMA: Need >2 elements in 
> the list\n");
> > +   return -EINVAL;
> > +   }
> > +   rc = omap_request_dma(dev_id, dev_name,
> > + callback, NULL, &dma_lch);
> > +   if (rc < 0) {
> > +   printk(KERN_ERR "omap_dma_list: Request failed 
> %d\n", rc);
> > +   return rc;
> > +   }
> > +   *listid = dma_lch;
> > +   dma_chan[dma_lch].state = DMA_CH_NOTSTARTED;
> You have updated channel status here but below allocations 
> can still fail.
> Safer is to update this once all allocation and variable 
> population done.

It doesn't matter. It's the earliest possible state, that seems to apply to 
a unconfigured channel as well.

> >  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, @@ -656,6 +739,21 @@ extern int 
> > omap_modify_dma_chain_params(int chain_id,  extern int 
> > omap_dma_chain_status(int chain_id);  #endif
> 
> > +extern int omap_request_dma_sglist(int dev_id, const char *dev_name,
> > +   void (*callback) (int channel_id, u16 ch_status, void *data),
> > +   int *listid, int nelem, struct omap_dma_sglist_node **elems);
> With this code callback after fewer nodes is not supported right ?

I suppose you mean the interrupt callback. 
The controller & the interrupt management are clever enough to call back when
you have set a pause in the middle.
A fine grained control is available if the DMA user provides a TYPE 1 
descriptor.
Not usually needed - it beats the purpose of providing a list.
--
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][RFC] OMAP4: sDMA driver: descriptor autoloading feature

2009-08-27 Thread S, Venkatraman
(Updated version of previous patch: 
http://marc.info/?l=linux-omap&m=125012097403050&w=2)
Add sDMA driver support for descriptor autoloading feature.
 Descriptor autoloading is OMAP4 sDMA hardware capability that can be exploited 
for scatter gather scenarios.

 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
   3 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) Closing/Releasing the DMA channel

The patches are generated against kernel 2.6.31-rc1, tested on OMAP4 simulator 
platform.

Summary:
OMAP sDMA driver changes for descriptor autoloading feature.
Signed-off-by: Venkatraman S 

---
 arch/arm/plat-omap/dma.c  |  303 +
 arch/arm/plat-omap/include/mach/dma.h |   98 +++
 2 files changed, 401 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 7677a4a..3a75272 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -46,13 +47,42 @@ enum { DMA_CH_ALLOC_DONE, DMA_CH_PARAMS_SET_DONE, 
DMA_CH_STARTED,
 enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
 #endif

+/* CDP Register bitmaps */
+#define DMA_LIST_CDP_DST_VALID (BIT(0))
+#define DMA_LIST_CDP_SRC_VALID (BIT(2))
+#define DMA_LIST_CDP_TYPE1 (BIT(4))
+#define DMA_LIST_CDP_TYPE2 (BIT(5))
+#define DMA_LIST_CDP_TYPE3 (BIT(4) | BIT(5))
+#define DMA_LIST_CDP_PAUSEMODE (BIT(7))
+#define DMA_LIST_CDP_LISTMODE  (BIT(8))
+#define DMA_LIST_CDP_FASTMODE  (BIT(10))
+/* CAPS register bitmaps */
+#define DMA_CAPS_SGLIST_SUPPORT(BIT(20))
+
+#define DMA_LIST_DESC_PAUSE(BIT(0))
+#define DMA_LIST_DESC_SRC_VALID(BIT(24))
+#define DMA_LIST_DESC_DST_VALID(BIT(26))
+#define DMA_LIST_DESC_BLK_END  (BIT(28))
+
 #define OMAP_DMA_ACTIVE0x01
 #define OMAP_DMA_CCR_EN(1 << 7)
 #define OMAP2_DMA_CSR_CLEAR_MASK   0xffe

 #define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
+#define OMAP_DMA_INVALID_FRAME_COUNT   (0x)
+#define OMAP_DMA_INVALID_ELEM_COUNT(0xff)
+#define OMAP_DMA_INVALID_DESCRIPTOR_POINTER(0xfffc)

 static int enable_1510_mode;
+static int dma_caps0_status;
+
+struct omap_dma_list_config_params {
+   int chid;
+   int num_elem;
+   struct omap_dma_sglist_node *sghead;
+   int sgheadphy;
+   int pausenode;
+};

 struct omap_dma_lch {
int next_lch;
@@ -72,6 +102,8 @@ struct omap_dma_lch {

int status;
 #endif
+
+   void *list_config;
long flags;
 };

@@ -209,6 +241,12 @@ static void clear_lch_regs(int lch)
__raw_writew(0, lch_base + i);
 }

+static inline void omap_dma_list_set_ntype(struct omap_dma_sglist_node *node,
+  int value)
+{
+   node->num_of_elem |= ((value) << 29);
+}
+
 void omap_set_dma_priority(int lch, int dst_port, int priority)
 {
unsigned long reg;
@@ -1787,6 +1825,269 @@ EXPORT_SYMBOL(omap_get_dma_chain_src_pos);
 #endif /*

[RFC][PATCH 2/2] OMAP4: sDMA driver: descriptor autoloading feature

2009-08-12 Thread S, Venkatraman
This patch adds the essential APIs for using the linked list mode of OMAP4 sDMA.

Signed-off-by: Venkatraman S 

---
 arch/arm/plat-omap/dma.c  |  284 +
 arch/arm/plat-omap/include/mach/dma.h |  100 
 2 files changed, 384 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 7677a4a..dd4990a 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -52,8 +53,23 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
 
 #define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
 
+#define OMAP_DMALIST_SET_NTYPE(nod_, val_) \
+   do { \
+   (nod_)->num_of_elem |= ((val_) << 29); \
+   } while (0)
+
 static int enable_1510_mode;
 
+#ifdef CONFIG_OMAP_DMA_DESCRIPTOR_LOAD
+struct omap_dma_list_config_params {
+   int chid;
+   int num_elem;
+   struct omap_dma_sglist_node *sghead;
+   int sgheadphy;
+   int pausenode;
+};
+#endif
+
 struct omap_dma_lch {
int next_lch;
int dev_id;
@@ -72,6 +88,10 @@ struct omap_dma_lch {
 
int status;
 #endif
+
+#ifdef CONFIG_OMAP_DMA_DESCRIPTOR_LOAD
+   void *list_config;
+#endif
long flags;
 };
 
@@ -1787,6 +1807,267 @@ EXPORT_SYMBOL(omap_get_dma_chain_src_pos);
 #endif /* ifndef CONFIG_ARCH_OMAP1 */
 
 
/**/
+#ifdef CONFIG_OMAP_DMA_DESCRIPTOR_LOAD
+
+int omap_request_dma_sglist(int dev_id, const char *dev_name,
+   void (*callback) (int channel_id, u16 ch_status, void *data),
+   int *listid, int nelem, struct omap_dma_sglist_node **elems)
+{
+   struct omap_dma_list_config_params *lcfg;
+   struct omap_dma_sglist_node *desc;
+   int dma_lch;
+   int rc, i;
+
+   if (unlikely(nelem <= 2)) {
+   printk(KERN_ERR "omap DMA: Need >2 elements in the list\n");
+   return -EINVAL;
+   }
+   rc = omap_request_dma(dev_id, dev_name,
+ callback, NULL, &dma_lch);
+   if (rc < 0) {
+   printk(KERN_ERR "omap_dma_list: Request failed %d\n", rc);
+   return rc;
+   }
+   *listid = dma_lch;
+   dma_chan[dma_lch].state = DMA_CH_NOTSTARTED;
+   lcfg = kmalloc(sizeof(*lcfg), GFP_KERNEL);
+   if (NULL == lcfg)
+   goto error1;
+   dma_chan[dma_lch].list_config = lcfg;
+
+   lcfg->num_elem = nelem;
+
+   *elems = desc = lcfg->sghead = dma_alloc_coherent(NULL,
+   sizeof(*desc), &(lcfg->sgheadphy), 0);
+   if (NULL == desc)
+   goto error1;
+
+   for (i = 1; i < nelem; i++) {
+   desc->next = dma_alloc_coherent(NULL,
+   sizeof(*(desc->next)), &(desc->next_desc_add_ptr), 0);
+   if (NULL == desc->next)
+   goto error1;
+   desc = desc->next;
+   desc->next = NULL;
+   }
+   desc->next_desc_add_ptr = 0xfffc;
+
+   /* TRM Sec 1.4.21.4.3 */
+   dma_write(0, CCDN(dma_lch));
+   dma_write(0x, CCFN(dma_lch));
+   dma_write(0xff, CCEN(dma_lch));
+   return 0;
+
+error1:
+   omap_release_dma_sglist(dma_lch);
+   return -ENOMEM;
+
+}
+EXPORT_SYMBOL(omap_request_dma_sglist);
+
+/* The client can choose to not preconfigure the DMA registers
+ * In fast mode,the DMA controller uses the first element in the list to
+ * program the registers first, and then starts the transfer
+ */
+
+int omap_set_dma_sglist_params(const int listid,
+   struct omap_dma_sglist_node *sghead,
+   struct omap_dma_channel_params *chparams)
+{
+   struct omap_dma_list_config_params *lcfg;
+   struct omap_dma_sglist_node *sgitcurr, *sgitprev;
+   int l = 0x100; /* Enable Linked list mode in CDP */
+
+   lcfg = dma_chan[listid].list_config;
+   if (lcfg->sghead != sghead) {
+   printk(KERN_ERR "Unknown config pointer passed\n");
+   return -EPERM;
+   }
+
+   if (NULL == chparams)
+   l |= 0x400;  /* FAST mode bit:10 */
+   else
+   omap_set_dma_params(listid, chparams);
+   /* The client can set the dma params and still use fast mode
+* by using the set fast mode api
+*/
+   dma_write(l, CDP(listid));
+
+   sgitprev = sghead;
+   sgitcurr = sgitprev->next;
+
+   while (sgitcurr != NULL) {
+   switch (sgitcurr->desc_type) {
+   case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE1:
+   OMAP_DMALIST_SET_NTYPE(sgitprev, 1);
+   break;
+
+   case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE2a:
+   /* intentional no break */
+   case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE2b:
+   OMAP_DMALIST_SET_NTYPE(sgitprev, 2);
+   br

[RFC][PATCH 1/2] OMAP4: sDMA drvier: adding OMAP kConfig option CONFIG_OMAP_DMA_DESCRIPTOR_LOAD

2009-08-12 Thread S, Venkatraman
The hardware feature is available on OMAP4430 and also expected to be 
in OMAP3630. Hence the feature flag will control the inclusion of the 
additional functions.

Addition of omap kconfig option CONFIG_OMAP_DMA_DESCRIPTOR_LOAD.

Signed-off-by: Venkatraman S 
---
 arch/arm/configs/omap_4430sdp_defconfig |1 +
 arch/arm/plat-omap/Kconfig  |7 +++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/configs/omap_4430sdp_defconfig 
b/arch/arm/configs/omap_4430sdp_defconfig
index 23e43ea..bea9dcb 100644
--- a/arch/arm/configs/omap_4430sdp_defconfig
+++ b/arch/arm/configs/omap_4430sdp_defconfig
@@ -182,6 +182,7 @@ CONFIG_ARCH_OMAP4=y
 #
 # OMAP Feature Selections
 #
+CONFIG_OMAP_DMA_DESCRIPTOR_LOAD=y
 # CONFIG_OMAP_RESET_CLOCKS is not set
 # CONFIG_OMAP_MUX is not set
 # CONFIG_OMAP_MCBSP is not set
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index efe85d0..885b8b8 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -53,6 +53,13 @@ config OMAP_DEBUG_POWERDOMAIN
  for every powerdomain register write.  However, the
  extra detail costs some memory.
 
+config OMAP_DMA_DESCRIPTOR_LOAD
+   bool "sDMA descriptor loading feature"
+   depends on ARCH_OMAP4
+   help
+ Say Y here if you want to include the DMA descriptor
+ autoloading feature. Supported only in OMAP4
+
 config OMAP_DEBUG_CLOCKDOMAIN
bool "Emit debug messages from clockdomain layer"
depends on ARCH_OMAP2 || ARCH_OMAP3

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


[RFC][PATCH 0/2] OMAP4: sDMA driver updates for descriptor autoloading feature

2009-08-12 Thread S, Venkatraman
This patch series provides OMAP sDMA driver changes for descriptor autoloading 
feature.
  Descriptor autoloading is OMAP4 sDMA hardware capability that can be 
exploited for scatter gather scenarios.

 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
3 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
4) Closing/Releasing the DMA channel

The patches are generated against kernel 2.6.31-rc1, tested on OMAP4 simulator 
platform.

Patch List
[Patch 1/2] Adding a new OMAP Kernel configuration option 
CONFIG_OMAP_DMA_DESCRIPTOR_FEATURE
[Patch 2/2] sDMA driver support for descriptor autoloading feature.

Comments requested.

Regards,

Venkat.

--
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