Re: [PATCH] spi: omap2-mcspi: Cleanup the omap2_mcspi_txrx_dma function

2012-09-12 Thread Shubhrajyoti
On Wednesday 12 September 2012 08:51 AM, Mark Brown wrote:
 On Tue, Sep 11, 2012 at 12:13:20PM +0530, Shubhrajyoti D wrote:
  Currently in omap2_mcspi_txrx_dma the tx and the rx support is
  interleaved. Make the rx related code in omap2_mcspi_rx_dma
  and the tx related code omap2_mcspi_tx_dma and call the functions.
 I'd ideally like some testing from the OMAP side before applying this -
 is there someone who can give a Tested-by?
I have tested this patch with nfs boot with ethernet being on spi on
omap4sdp and spidev.
On omap3 sdp tested the touchscreen.

However can wait for some tested-bys :-)
--
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: [PATCHv7 20/23] i2c: omap: switch to threaded IRQ support

2012-09-12 Thread Shubhrajyoti
On Wednesday 12 September 2012 03:21 AM, Wolfram Sang wrote:
 -omap_i2c_isr(int this_irq, void *dev_id)
  +omap_i2c_isr(int irq, void *dev_id)
   {
 struct omap_i2c_dev *dev = dev_id;
  +  irqreturn_t ret = IRQ_HANDLED;
 Shouldn't that be IRQ_NONE?
Actually we are processing it so I thought it to be ok.
Also a similar discussion.
 
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/104422.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 v4 00/21] OMAP UART Patches

2012-09-12 Thread Felipe Balbi
Hi,

On Tue, Sep 11, 2012 at 10:02:48PM +, Paul Walmsley wrote:
 
 Hi Felipe
 
 Just tested these OMAP serial changes at commit 
 e36851d0fa94b0f7802b3cc80406dbd3ef4f2f16 (serial: omap: fix compile 
 breakage).  There's good news and bad news...
 
 The good news is that after applying this series, the 'OMAP4 UART garbage 
 on long transmit buffers when PM is enabled' bug:
 
 http://www.pwsan.com/omap/testlogs/test_v3.6-rc5/20120908202511/pm/4430es2panda/4430es2panda_log.txt
 
 ... goes away.  (Unclear if it's because the underlying bug was fixed, or 
 if unrelated changes are masking it.)  Not sure what caused the problem to 
 go away exactly, but it's one of the changes between d37c6ceb and bf63a08.  
 So that's good!

I'd point the finger at sticking to put_autosuspend() as that would give
HW enough time to actually unload all bytes from its FIFO through the
UART lines. can you check if forcing the autosuspend_delay to -1
triggers the issue again ? If it does, it's some help from autosuspend,
which would mean we still have the problem and needs to be properly
fixed.

 The bad news is that N800 no longer boots -- or the UART dies during 
 serial init:
 
 http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/boot/2420n800/2420n800_log.txt
 
 The problem doesn't seem to affect the 2430SDP.
 
 Could you put together a patch to fix N800?

I'll see what I can do. BTW, is that log with DEBUG_LL enabled ?

cheers

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp

2012-09-12 Thread ABRAHAM, KISHON VIJAY
Hi,

On Wed, Sep 12, 2012 at 3:58 AM, Paul Walmsley p...@pwsan.com wrote:
 Hi Kishon, Benoît,

 On Fri, 7 Sep 2012, Kishon Vijay Abraham I wrote:

 Made *ocp2scp_usb_phy_phy_48m* as the main_clk for ocp2scp. Since this
 ocp2scp module does not have any fck but does have a single opt_clock,
 it is added as the main_clk for ocp2scp. Also removed phy_48m as the
 optional clock since it is now made as the main clock. By this the
 driver need not enable/disable phy_48m clk separately and
 runtime_get/runtime_put will take care of that.

 Looking at this patch, it doesn't seem to make sense from a hardware point
 of view.  If you look at the OMAP4430 TRM Rev. AE, Table 23-1166 Clocks
 and Resets, the 48MHz clock input is listed as an Optional functional
 clock.  The main functional clock is listed as INIT_960M_FCLK, which
 according to the same TRM, Section 3.6.3.9.1 Overview, is an alias for
 the clock we call dpll_usb_clkdcoldo_ck.

 So if any clock should be the main functional clock in the hwmod data,
 shouldn't it be dpll_usb_clkdcoldo_ck?  The goal with the hwmod data
 is/was to have it match the hardware.

 ...

 More to the point, I guess I don't see what the problem is with
 adding a few lines to the ocp2scp driver to control the phy_48m optional

It should be added in omap-usb2 driver rather.
 clock via the clock framework.  Is there some reason why you
 couldn't prepare  enable it after the pm_runtime_get_*(),
 and disable and unprepare it before the pm_runtime_put_*() ?

We have omap-usb2 driver that is used for both omap4 and omap5. But
this 48m clock is used only in omap4. And we dint have any *main_clk*
in the ocp2scp_usb_phy_hwmod. So in order avoid some checks in the
omap-usb2 driver, we added 48m clk as the main clock of
ocp2scp_usb_phy_hwmod.

Thanks
Kishon
--
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/17] Input: omap-keypad: Remove dependencies to mach includes

2012-09-12 Thread Poddar, Sourav
Hi,

On Tue, Sep 11, 2012 at 11:26 PM, Tony Lindgren t...@atomide.com wrote:
 * Tony Lindgren t...@atomide.com [120910 23:17]:
 * Felipe Balbi ba...@ti.com [120910 23:02]:

static int __devinit omap_kp_probe(struct platform_device *pdev)
{
   - struct omap_kp *omap_kp;
 
   I don't see the point for that global omap_kp, actually ...

 Yes you're right. Will send an updated one tomorrow.

 Here's the updated patch that just removes all omap2+ code,
 and does not use the global omap_kp.

 Regards,

 Tony


 From: Tony Lindgren t...@atomide.com
 Date: Fri, 7 Sep 2012 13:27:58 -0700
 Subject: [PATCH] Input: omap-keypad: Remove dependencies to mach includes

 Remove support for omap2+ as it's no longer needed since
 it's using matrix-keypad. This way we can remove depency
 to plat and mach headers which is needed for ARM common
 zImage support.

 Also remove INT_KEYBOARD by using omap_kp-irq.

 Note that this patch depends on an earlier patch
 ARM: OMAP: Move gpio.h to include/linux/platform_data.

 Cc: Dmitry Torokhov dmitry.torok...@gmail.com
 Cc: linux-in...@vger.kernel.org
 Signed-off-by: Tony Lindgren t...@atomide.com

 --- a/drivers/input/keyboard/Kconfig
 +++ b/drivers/input/keyboard/Kconfig
 @@ -533,7 +533,7 @@ config KEYBOARD_DAVINCI

  config KEYBOARD_OMAP
 tristate TI OMAP keypad support
 -   depends on (ARCH_OMAP1 || ARCH_OMAP2)
 +   depends on ARCH_OMAP1
 select INPUT_MATRIXKMAP
 help
   Say Y here if you want to use the OMAP keypad.
 diff --git a/drivers/input/keyboard/omap-keypad.c 
 b/drivers/input/keyboard/omap-keypad.c
 index a0222db..2bda5f0b 100644
 --- a/drivers/input/keyboard/omap-keypad.c
 +++ b/drivers/input/keyboard/omap-keypad.c
 @@ -35,13 +35,9 @@
  #include linux/mutex.h
  #include linux/errno.h
  #include linux/slab.h
 -#include asm/gpio.h
 +#include linux/gpio.h
 +#include linux/platform_data/gpio-omap.h
  #include plat/keypad.h
 -#include plat/menelaus.h
 -#include asm/irq.h
 -#include mach/hardware.h
 -#include asm/io.h
 -#include plat/mux.h

  #undef NEW_BOARD_LEARNING_MODE

 @@ -96,28 +92,8 @@ static u8 get_row_gpio_val(struct omap_kp *omap_kp)

  static irqreturn_t omap_kp_interrupt(int irq, void *dev_id)
  {
 -   struct omap_kp *omap_kp = dev_id;
 -
 /* disable keyboard interrupt and schedule for handling */
 -   if (cpu_is_omap24xx()) {
 -   int i;
 -
 -   for (i = 0; i  omap_kp-rows; i++) {
 -   int gpio_irq = gpio_to_irq(row_gpios[i]);
 -   /*
 -* The interrupt which we're currently handling should
 -* be disabled _nosync() to avoid deadlocks waiting
 -* for this handler to complete.  All others should
 -* be disabled the regular way for SMP safety.
 -*/
 -   if (gpio_irq == irq)
 -   disable_irq_nosync(gpio_irq);
 -   else
 -   disable_irq(gpio_irq);
 -   }
 -   } else
 -   /* disable keyboard interrupt and schedule for handling */
 -   omap_writew(1, OMAP1_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
 +   omap_writew(1, OMAP1_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);

 tasklet_schedule(kp_tasklet);

 @@ -133,33 +109,22 @@ static void omap_kp_scan_keypad(struct omap_kp 
 *omap_kp, unsigned char *state)
  {
 int col = 0;

 -   /* read the keypad status */
 -   if (cpu_is_omap24xx()) {
 -   /* read the keypad status */
 -   for (col = 0; col  omap_kp-cols; col++) {
 -   set_col_gpio_val(omap_kp, ~(1  col));
 -   state[col] = ~(get_row_gpio_val(omap_kp))  0xff;
 -   }
 -   set_col_gpio_val(omap_kp, 0);
 -
 -   } else {
 -   /* disable keyboard interrupt and schedule for handling */
 -   omap_writew(1, OMAP1_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);
 +   /* disable keyboard interrupt and schedule for handling */
 +   omap_writew(1, OMAP1_MPUIO_BASE + OMAP_MPUIO_KBD_MASKIT);

 -   /* read the keypad status */
 -   omap_writew(0xff, OMAP1_MPUIO_BASE + OMAP_MPUIO_KBC);
 -   for (col = 0; col  omap_kp-cols; col++) {
 -   omap_writew(~(1  col)  0xff,
 -   OMAP1_MPUIO_BASE + OMAP_MPUIO_KBC);
 +   /* read the keypad status */
 +   omap_writew(0xff, OMAP1_MPUIO_BASE + OMAP_MPUIO_KBC);
 +   for (col = 0; col  omap_kp-cols; col++) {
 +   omap_writew(~(1  col)  0xff,
 +   OMAP1_MPUIO_BASE + OMAP_MPUIO_KBC);

 -   udelay(omap_kp-delay);
 +   udelay(omap_kp-delay);

 -   state[col] = ~omap_readw(OMAP1_MPUIO_BASE +
 -OMAP_MPUIO_KBR_LATCH)  0xff;

Re: [PATCHv7 19/23] i2c: omap: always return IRQ_HANDLED

2012-09-12 Thread Shubhrajyoti
On Wednesday 12 September 2012 03:23 AM, Wolfram Sang wrote:
 Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
 Can't we just drop this patch since the code gets removed soon anyhow?
 Or is patch 20/23 changing something I don't see yet?
yes it is dropped will update.

--
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: [PATCHv7 18/23] i2c: omap: remove redundant status read

2012-09-12 Thread Shubhrajyoti
On Wednesday 12 September 2012 03:24 AM, Wolfram Sang wrote:
 On Tue, Sep 11, 2012 at 03:12:13PM +0530, Shubhrajyoti D wrote:
 Remove the redundant read of the status register.
 Commit message is just repeating the subject.
 Why was the read there and why can it be removed now?

It is read and it is not read anywhere below.
 Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
 ---
  drivers/i2c/busses/i2c-omap.c |2 --
  1 files changed, 0 insertions(+), 2 deletions(-)

 diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
 index 5d4bad4..498a462 100644
 --- a/drivers/i2c/busses/i2c-omap.c
 +++ b/drivers/i2c/busses/i2c-omap.c
 @@ -946,7 +946,6 @@ omap_i2c_isr(int this_irq, void *dev_id)
  num_bytes = dev-buf_len;
  
  ret = omap_i2c_transmit_data(dev, num_bytes, true);
 -stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
  if (ret  0)
  goto out;
  
 @@ -962,7 +961,6 @@ omap_i2c_isr(int this_irq, void *dev_id)
  num_bytes = dev-threshold;
  
  ret = omap_i2c_transmit_data(dev, num_bytes, false);
 -stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
  if (ret  0)
  goto out;
  
 -- 
 1.7.5.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


[PATCH V2] ARM: OMAP2+: Round of the carve out memory requested to section_size

2012-09-12 Thread R Sricharan
memblock_steal tries to reserve physical memory during boot.
When the requested size is not aligned on the section size
then, the remaining memory available for lowmem becomes
unaligned on the section boundary. There is a issue with this,
which is discussed in the thread below.

https://lkml.org/lkml/2012/6/28/112

The final conclusion from the thread seems to
be align the memblock_steal calls on the SECTION boundary.
The issue comes out when LPAE is enabled, where the
section size is 2MB.

Boot tested this on OMAP5 evm with and without LPAE.

Signed-off-by: R Sricharan r.sricha...@ti.com
---
 [V2] Corrected the subject and added one more description line.

 arch/arm/mach-omap2/omap-secure.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-secure.c 
b/arch/arm/mach-omap2/omap-secure.c
index d9ae4a5..26edfec 100644
--- a/arch/arm/mach-omap2/omap-secure.c
+++ b/arch/arm/mach-omap2/omap-secure.c
@@ -61,8 +61,8 @@ int __init omap_secure_ram_reserve_memblock(void)
 {
u32 size = OMAP_SECURE_RAM_STORAGE;
 
-   size = ALIGN(size, SZ_1M);
-   omap_secure_memblock_base = arm_memblock_steal(size, SZ_1M);
+   size = ALIGN(size, SECTION_SIZE);
+   omap_secure_memblock_base = arm_memblock_steal(size, SECTION_SIZE);
 
return 0;
 }
-- 
1.7.9.5

--
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] ARM: OMAP: counter: add locking to read_persistent_clock

2012-09-12 Thread R Sricharan
From: Colin Cross ccr...@android.com

read_persistent_clock uses a global variable, use a spinlock to
ensure non-atomic updates to the variable don't overlap and cause
time to move backwards.

Signed-off-by: Colin Cross ccr...@android.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
 [V2] Added signed-off-by and looped in linux-arm-kernel list

 arch/arm/plat-omap/counter_32k.c |   21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index dbf1e03..2bc51fb 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -55,22 +55,29 @@ static u32 notrace omap_32k_read_sched_clock(void)
  * nsecs and adds to a monotonically increasing timespec.
  */
 static struct timespec persistent_ts;
-static cycles_t cycles, last_cycles;
+static cycles_t cycles;
 static unsigned int persistent_mult, persistent_shift;
+static DEFINE_SPINLOCK(read_persistent_clock_lock);
+
 static void omap_read_persistent_clock(struct timespec *ts)
 {
unsigned long long nsecs;
-   cycles_t delta;
-   struct timespec *tsp = persistent_ts;
+   cycles_t last_cycles;
+   unsigned long flags;
+
+   spin_lock_irqsave(read_persistent_clock_lock, flags);
 
last_cycles = cycles;
cycles = sync32k_cnt_reg ? __raw_readl(sync32k_cnt_reg) : 0;
-   delta = cycles - last_cycles;
 
-   nsecs = clocksource_cyc2ns(delta, persistent_mult, persistent_shift);
+   nsecs = clocksource_cyc2ns(cycles - last_cycles,
+   persistent_mult, persistent_shift);
+
+   timespec_add_ns(persistent_ts, nsecs);
+
+   *ts = persistent_ts;
 
-   timespec_add_ns(tsp, nsecs);
-   *ts = *tsp;
+   spin_unlock_irqrestore(read_persistent_clock_lock, flags);
 }
 
 /**
-- 
1.7.9.5

--
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 13/16] ARM: omap: move platform_data definitions

2012-09-12 Thread Pihet-XID, Jean
Hi Arnd,

On Tue, Sep 11, 2012 at 2:59 PM, Arnd Bergmann a...@arndb.de wrote:
 Platform data for device drivers should be defined in
 include/linux/platform_data/*.h, not in the architecture
 and platform specific directories.

 This moves such data out of the omap include directories

 Signed-off-by: Arnd Bergmann a...@arndb.de

...

 diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
 index 0ac2caf..7abf1c0 100644
 --- a/arch/arm/mach-omap2/voltage.h
 +++ b/arch/arm/mach-omap2/voltage.h
 @@ -16,7 +16,7 @@

  #include linux/err.h

 -#include plat/voltage.h
 +#include linux/platform_data/smartreflex-omap.h

  #include vc.h
  #include vp.h
...
 diff --git a/arch/arm/plat-omap/include/plat/voltage.h 
 b/include/linux/platform_data/smartreflex-omap.h
 similarity index 100%
 rename from arch/arm/plat-omap/include/plat/voltage.h
 rename to include/linux/platform_data/smartreflex-omap.h
The filename should be voltage-omap.h. The header file is for a
voltage layer which is used by other layers, one of them is the
smartreflex driver code (in drivers/power/avs).
The header file for the smartreflex driver is in
include/linux/power/smartreflex.h.

 diff --git a/include/linux/power/smartreflex.h 
 b/include/linux/power/smartreflex.h
 index 3101e62..e376f94 100644
 --- a/include/linux/power/smartreflex.h
 +++ b/include/linux/power/smartreflex.h
 @@ -23,7 +23,7 @@
  #include linux/types.h
  #include linux/platform_device.h
  #include linux/delay.h
 -#include plat/voltage.h
 +#include linux/platform_data/smartreflex-omap.h

  /*
   * Different Smartreflex IPs version. The v1 is the 65nm version used in

Thanks for the clean-up!

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


Re: [PATCH] CPUFreq: OMAP: remove unnecessary plat/ includes

2012-09-12 Thread Shilimkar, Santosh
On Wed, Sep 12, 2012 at 6:02 AM, Paul Walmsley p...@pwsan.com wrote:

 Remove some unnecessary plat/ includes that are interfering with multi-subarch
 ARM kernels.

 Signed-off-by: Paul Walmsley p...@pwsan.com
 Cc: Kevin Hilman khil...@ti.com
 Cc: Rafael J. Wysocki r...@sisk.pl
 Acked-by: Kevin Hilman khil...@ti.com
 ---

 Still awaiting some final testing here.  Rafael, was wondering if you
 would be willing to ack this so we can merge it via the OMAP tree?
 Otherwise the patch can be split into an OMAP part and a CPUFreq part that
 can go in across two merge windows.

Hmm.
I did similar change[1] a while back. Kevin didn't like idea though
that point of time.

Regards,
Santosh

[1] http://www.spinics.net/lists/linux-omap/msg48382.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] mmc: omap_hsmmc: Enable HSPE bit for high speed cards

2012-09-12 Thread Hebbar, Gururaja
On Tue, Sep 04, 2012 at 18:39:11, 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


Gentle Ping. Is there any update on this patch?. If not, can this be pulled in. 

 
 Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
 ---
 :100644 100644 be76a23... ed271fc... M
 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 :100644 100644 eb3e4d5... 00c658b... M
 arch/arm/plat-omap/include/plat/mmc.h
 :100644 100644 c3e96a2... 0e14834... Mdrivers/mmc/host/omap_hsmmc.c
  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |1 +
  arch/arm/plat-omap/include/plat/mmc.h  |1 +
  drivers/mmc/host/omap_hsmmc.c  |   30 
 +++-
  3 files changed, 31 insertions(+), 1 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
 b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 index be76a23..ed271fc 100644
 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 @@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
  supply-name examples are vmmc, vmmc_aux etc
  ti,non-removable: non-removable slot (like eMMC)
  ti,needs-special-reset: Requires a special softreset sequence
 +ti,needs-special-hs-handling: HSMMC IP needs special setting for handling 
 High Speed
  
  Example:
   mmc1: mmc@0x4809c000 {
 diff --git a/arch/arm/plat-omap/include/plat/mmc.h 
 b/arch/arm/plat-omap/include/plat/mmc.h
 index eb3e4d5..00c658b 100644
 --- a/arch/arm/plat-omap/include/plat/mmc.h
 +++ b/arch/arm/plat-omap/include/plat/mmc.h
 @@ -127,6 +127,7 @@ struct omap_mmc_platform_data {
   /* we can put the features above into this variable */
  #define HSMMC_HAS_PBIAS  (1  0)
  #define HSMMC_HAS_UPDATED_RESET  (1  1)
 +#define HSMMC_HAS_HSPE_SUPPORT   (1  2)
   unsigned features;
  
   int switch_pin; /* gpio (card detect) */
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index c3e96a2..0e14834 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -63,6 +63,7 @@
  
  #define VS18 (1  26)
  #define VS30 (1  25)
 +#define HSS  (1  21)
  #define SDVS18   (0x5  9)
  #define SDVS30   (0x6  9)
  #define SDVS33   (0x7  9)
 @@ -90,6 +91,7 @@
  #define MSBS (1  5)
  #define BCE  (1  1)
  #define FOUR_BIT (1  1)
 +#define HSPE (1  2)
  #define DDR  (1  19)
  #define DW8  (1  5)
  #define CC   0x1
 @@ -490,6 +492,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host 
 *host)
   struct mmc_ios *ios = host-mmc-ios;
   unsigned long regval;
   unsigned long timeout;
 + unsigned long clkdiv;
  
   dev_vdbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);
  
 @@ -497,7 +500,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host 
 *host)
  
   regval = OMAP_HSMMC_READ(host-base, SYSCTL);
   regval = regval  ~(CLKD_MASK | DTO_MASK);
 - regval = regval | (calc_divisor(host, ios)  6) | (DTO  16);
 + clkdiv = calc_divisor(host, ios);
 + regval = regval | (clkdiv  6) | (DTO  16);
   OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
   OMAP_HSMMC_WRITE(host-base, SYSCTL,
   OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
 @@ -508,6 +512,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host 
 *host)
time_before(jiffies, timeout))
   cpu_relax();
  
 + /*
 +  * Enable High-Speed Support
 +  * Pre-Requisites
 +  *  - Controller should support High-Speed-Enable Bit
 +  *  - Controller should not be using DDR Mode
 +  *  - Controller should advertise that it supports High Speed
 +  *in capabilities register
 +  *  - MMC/SD clock coming out of controller  25MHz
 +  */
 + if ((mmc_slot(host).features  HSMMC_HAS_HSPE_SUPPORT) 
 + (ios-timing != MMC_TIMING_UHS_DDR50) 
 + 

RE: [PATCH] mmc: omap_hsmmc: Pass on the suspend failure to the PM core

2012-09-12 Thread Hebbar, Gururaja
On Tue, Sep 11, 2012 at 11:13:26, S, Venkatraman wrote:
 On Tue, Sep 4, 2012 at 6:38 PM, Hebbar, Gururaja gururaja.heb...@ti.com 
 wrote:
  From: Vaibhav Bedia vaibhav.be...@ti.com
 
  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.

Correct. I missed it. I will reformat the patch and resend it.

 


Regards, 
Gururaja
--
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/4] staging: omap-thermal: Correct checkpatch.pl warnings

2012-09-12 Thread Dan Carpenter
On Tue, Sep 11, 2012 at 07:06:52PM +0300, Eduardo Valentin wrote:
 From: J Keerthy j-keer...@ti.com
 
 Removes checkpatch warnings on omap-bandgap.c.
 

Which checkpatch.pl warnings?

 + omap_bandgap_writel(bg_ptr,
 + rval-tshut_threshold,
 +tsr-tshut_threshold);

That's just whacky.

Personally, I've never cared much about long lines, so I'd prefer
to leave these as is until someone can break the functions up and
remove them in a proper way instead of just shifting everything
randomly to the left.

regards,
dan carpenter

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


[balbi-usb:merge-result-for-greg 66/99] drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma on the stack ((null))

2012-09-12 Thread Fengguang Wu
Hi Felipe,

FYI, there are new smatch warnings show up in

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
merge-result-for-greg
head:   23953bde3e4d6aa8780dc054f6ad9882ac63f4f4
commit: e918fa161f510136fce45a524e934fe20e62c8b1 [66/99] Merge tag 
'gadget-for-v3.7' into merge-result-for-greg

drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma on 
the stack ((null))
drivers/usb/core/hub.c:4733 store_port_power_control() info: why not propagate 
'ret' from set_port_feature() instead of -5?
drivers/usb/core/hub.c:4744 store_port_power_control() info: why not propagate 
'ret' from clear_port_feature() instead of -5?

vim +2654 drivers/usb/core/hub.c
  2644  return ret;
  2645  }
  2646  
  2647  static int usb_get_hub_port_power_state(struct usb_device *hdev, int 
port1)
  2648  {
  2649  struct usb_hub *hub = hdev_to_hub(hdev);
  2650  struct usb_port_status data;
  2651  u16 portstatus;
  2652  int ret;
  2653  
 2654  ret = get_port_status(hub-hdev, port1, data);
  2655  if (ret  4) {
  2656  dev_err(hub-intfdev,
  2657  %s failed (err = %d)\n, __func__, ret);
  2658  if (ret = 0)
  2659  ret = -EIO;
  2660  return ret;
  2661  } else
  2662  portstatus = le16_to_cpu(data.wPortStatus);
  2663  return port_is_power_on(hub, portstatus);
  2664  }

---
0-DAY kernel build testing backend Open Source Technology Centre
Fengguang Wu w...@linux.intel.com Intel Corporation
--
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/4] staging: omap-thermal: Correct checkpatch.pl warnings

2012-09-12 Thread Dan Carpenter
On Wed, Sep 12, 2012 at 11:11:27AM +0300, Dan Carpenter wrote:
 On Tue, Sep 11, 2012 at 07:06:52PM +0300, Eduardo Valentin wrote:
  From: J Keerthy j-keer...@ti.com
  
  Removes checkpatch warnings on omap-bandgap.c.
  
 
 Which checkpatch.pl warnings?
 
  +   omap_bandgap_writel(bg_ptr,
  +   rval-tshut_threshold,
  +  tsr-tshut_threshold);
 
 That's just whacky.
 
 Personally, I've never cared much about long lines, so I'd prefer
 to leave these as is until someone can break the functions up and
 remove them in a proper way instead of just shifting everything
 randomly to the left.
 

Sorry, that was my default response without looking at the code.

This is already broken up into small functions pretty nicely.  You
might want to consider using shorter names.  For example
omap_bandgap_writel() could be changed to obg_writel() and bg_ptr
could be changed to just bg because it's obviously a pointer.

regards,
dan carpenter
--
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: OMAP2+: TEMP: Round of the carve out memory requested to section_size

2012-09-12 Thread Sricharan R
[..]
  memblock_steal tries to reserve physical memory during boot.
  When the requested size is not aligned on the section size
  then, the remaining memory available for lowmem becomes
  unaligned on the section boundary. There is a issue with this,
  which is discussed in the thread below.
 
  https://lkml.org/lkml/2012/6/28/112
 
  The final conclusion from the thread seems to
  be align the memblock_steal calls on the SECTION boundary.
 
  Signed-off-by: R Sricharan r.sricha...@ti.com
 Why is the TEMP in the subject line. From patch it doesn't be
 temporary version. Can you please clarify that ?

 Oops, that was a mistake. Reposted by correcting it.

Thanks,
 Sricharan
--
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 gururaja.heb...@ti.com 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: [balbi-usb:merge-result-for-greg 66/99] drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma on the stack ((null))

2012-09-12 Thread Dan Carpenter
On Wed, Sep 12, 2012 at 04:26:22PM +0800, Fengguang Wu wrote:
 Hi Felipe,
 
 FYI, there are new smatch warnings show up in
 
 tree:   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
 merge-result-for-greg
 head:   23953bde3e4d6aa8780dc054f6ad9882ac63f4f4
 commit: e918fa161f510136fce45a524e934fe20e62c8b1 [66/99] Merge tag 
 'gadget-for-v3.7' into merge-result-for-greg
 
 drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma 
 on the stack ((null))

Smatch prints out a lot of these warnings.  I haven't looked at the
rules in a while, so maybe there is a bounce buffer somewhere where
it detects stack memory and allocates a DMA'able buffer?

It would be better if the function documentation for
usb_control_msg() said that the *data pointer had to be kmalloc()ed.

Also I wonder if Documentation/DMA-API-HOWTO.txt is out of data.
Are we allowed to DMA to vmalloc()ed memory yet?

regards,
dan carpenter

--
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] rpmsg: use right device paramter when calling dma_free_coherent function

2012-09-12 Thread Ohad Ben-Cohen
Hi Fernando,

On Thu, Aug 30, 2012 at 3:24 AM, Fernando Guzman Lugo
fernando.l...@ti.com wrote:
 dma_alloc/free_coherent APIs requires the platform specific remoteproc
 device as the device parameter. We are passing vdev-dev.parent to the
 dma_free_coherent function which is the generic rproc device and it is
 wrong, it has to be vdev-dev.parent-parent instead, same as when we
 call dma_alloc_coherent function.

 Signed-off-by: Fernando Guzman Lugo fernando.l...@ti.com

Thanks, applied to rpmsg-fixes.

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


[GIT PULL] ARM: OMAP2+: some Makefile cleanup for 3.7

2012-09-12 Thread Paul Walmsley
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Tony,

The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:

  Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
tags/omap-cleanup-a-for-3.7

for you to fetch changes up to df47adb825c221ff45126fd54e531f01ea490334:

  ARM: OMAP2+: clean up PRCM sections of the Makefile (2012-09-11 19:09:15 
-0600)

- - Paul

- 
Clean up and standardize several parts of
arch/arm/mach-omap2/Makefile.  Beyond readability and diffstat
improvements, the series should reduce the risk of conflicts during
future cleanups by ensuring related lines are in the same section of the
Makefile.

Test results are available here:

http://www.pwsan.com/omap/testlogs/makefile_cleanup_3.7/20120911191710/

- 
object size (delta in bytes from test_v3.6-rc5 
(55d512e245bc7699a8800e23df1a24195dd08217)):
  textdata bss   total  kernel
 0   0   0   0  2430_testconfig
 0   0   0   0  5912osk_testconfig
 0   0   0   0  am33xx_testconfig
+8   0   0  +8  n800_b_testconfig
+8   0   0  +8  n800_multi_omap2xxx
+8   0   0  +8  n800_testconfig
 0   0   0   0  omap1510_defconfig
 0   0   0   0  omap1_defconfig
   +32   0   0 +32  omap2_4_testconfig
 +4104   0   0   +4104  omap2plus_defconfig
+8   0   0  +8  omap2plus_defconfig_cpupm
   +16   0   0 +16  omap2plus_no_pm
-8   0   0  -8  omap3_4_testconfig
+8   0   0  +8  omap3_testconfig
 0   0   0   0  omap4_testconfig
 0   0   0   0  rmk_omap3430_ldp_oldconfig
 0   0   0   0  rmk_omap4430_sdp_oldconfig

Paul Walmsley (6):
  ARM: OMAP2+: clean up whitespace in Makefile
  ARM: OMAP2+: clean up omap_hwmod.o build directives in Makefile
  ARM: OMAP2+: move MPU INTCPS, secure monitor, SDRC build directives in 
Makefile
  ARM: OMAP2+: clean up OMAP4 PRM  sleep build directives in Makefile
  ARM: OMAP2+: clean up OMAP clock Makefile sections
  ARM: OMAP2+: clean up PRCM sections of the Makefile

 arch/arm/mach-omap2/Makefile |  108 +-
 1 file changed, 44 insertions(+), 64 deletions(-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJQUFBZAAoJEMePsQ0LvSpLdcwP/1Z6XcuaHQToJtemuoNDuWxz
KkfjcakpgmgQuB3ynO3skk2BNHLkxQhMFAMwGnhWwSuLZ3sYpTwnR4CiPTgP20PR
1PrN9u4ytFVaKMENoVhp/Wg1GtDim/DMdYVzEwFZC+eEig4hUsYZSAi0RVlcyz+T
LEaDcPu2+LPXaXCjMFIO1NiU3csFS4NByAuLTBuoWkIvZO7n5/Dk8DTDojcF+KMt
ilUp86spPbJTsY7jpegHE9QWA5qfPL5ca1V/QEYMnyxKkRrs95G0eelRq8ndBC+7
/FnC9uYyQnm/9jhki4u17udBoMq3WtGDk3nQSk391JwItsaDAGOXJ4icGl/xHAI/
EW+usBDKNvLSg5iNw6yM6uTAq18wehnVqzUlIYLPBzPjChq1nuYN2jHrUyhlOGlX
fSGDqiGlov1VvQT0dcPRevXiOBuIXtdsjQPZSuKv/RrZeMUin4g153Ccn1riZFJ9
hJ6BGa91LlghzOBY9vUk2cFKWgE4LKNql2UonGFtyzKogZK0vIRAJSxOV2ERh4iv
jWqycUbHAsIJ0qoIzi/CyR0qpf4PSC8Bw1kH7QAPq5NMEK29OIdvJKLjkEH5s0OS
EgW7z+bfvSJYymVjvPRZgfEfQF25z7NZl3vcgOfzAZLgiKGnpXrvkXN7xUuulPLl
70O2+vs7c0CF6ynXnprk
=A5QQ
-END PGP SIGNATURE-
--
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/4] staging: omap-thermal: Correct checkpatch.pl warnings

2012-09-12 Thread Valentin, Eduardo
Hello Dan,

On Wed, Sep 12, 2012 at 11:26 AM, Dan Carpenter
dan.carpen...@oracle.com wrote:
 On Wed, Sep 12, 2012 at 11:11:27AM +0300, Dan Carpenter wrote:
 On Tue, Sep 11, 2012 at 07:06:52PM +0300, Eduardo Valentin wrote:
  From: J Keerthy j-keer...@ti.com
 
  Removes checkpatch warnings on omap-bandgap.c.
 

 Which checkpatch.pl warnings?

  +   omap_bandgap_writel(bg_ptr,
  +   rval-tshut_threshold,
  +  tsr-tshut_threshold);

 That's just whacky.

 Personally, I've never cared much about long lines, so I'd prefer
 to leave these as is until someone can break the functions up and
 remove them in a proper way instead of just shifting everything
 randomly to the left.


 Sorry, that was my default response without looking at the code.

 This is already broken up into small functions pretty nicely.  You
 might want to consider using shorter names.  For example
 omap_bandgap_writel() could be changed to obg_writel() and bg_ptr
 could be changed to just bg because it's obviously a pointer.

Yeah, that's one option. Of course the deal is to find the proper
balance between cryptic symbol names and code mangled / shifted to the
left.


 regards,
 dan carpenter



-- 

Eduardo Valentin
--
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 T Krishnamoorthy, Balaji
On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja gururaja.heb...@ti.com 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.

Is this specific to some boards or all board with TI81xx ?
What is the side-effect if not done ?


 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

 Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
 ---
 :100644 100644 be76a23... ed271fc... M  
 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 :100644 100644 eb3e4d5... 00c658b... M  arch/arm/plat-omap/include/plat/mmc.h
 :100644 100644 c3e96a2... 0e14834... M  drivers/mmc/host/omap_hsmmc.c
  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |1 +
  arch/arm/plat-omap/include/plat/mmc.h  |1 +
  drivers/mmc/host/omap_hsmmc.c  |   30 
 +++-
  3 files changed, 31 insertions(+), 1 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
 b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 index be76a23..ed271fc 100644
 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 @@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
  supply-name examples are vmmc, vmmc_aux etc
  ti,non-removable: non-removable slot (like eMMC)
  ti,needs-special-reset: Requires a special softreset sequence
 +ti,needs-special-hs-handling: HSMMC IP needs special setting for handling 
 High Speed

  Example:
 mmc1: mmc@0x4809c000 {
 diff --git a/arch/arm/plat-omap/include/plat/mmc.h 
 b/arch/arm/plat-omap/include/plat/mmc.h
 index eb3e4d5..00c658b 100644
 --- a/arch/arm/plat-omap/include/plat/mmc.h
 +++ b/arch/arm/plat-omap/include/plat/mmc.h
 @@ -127,6 +127,7 @@ struct omap_mmc_platform_data {
 /* we can put the features above into this variable */
  #define HSMMC_HAS_PBIAS(1  0)
  #define HSMMC_HAS_UPDATED_RESET(1  1)
 +#define HSMMC_HAS_HSPE_SUPPORT (1  2)
 unsigned features;

 int switch_pin; /* gpio (card detect) */
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index c3e96a2..0e14834 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -63,6 +63,7 @@

  #define VS18   (1  26)
  #define VS30   (1  25)
 +#define HSS(1  21)
  #define SDVS18 (0x5  9)
  #define SDVS30 (0x6  9)
  #define SDVS33 (0x7  9)
 @@ -90,6 +91,7 @@
  #define MSBS   (1  5)
  #define BCE(1  1)
  #define FOUR_BIT   (1  1)
 +#define HSPE   (1  2)
  #define DDR(1  19)
  #define DW8(1  5)
  #define CC 0x1
 @@ -490,6 +492,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host 
 *host)
 struct mmc_ios *ios = host-mmc-ios;
 unsigned long regval;
 unsigned long timeout;
 +   unsigned long clkdiv;

 dev_vdbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);

 @@ -497,7 +500,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host 
 *host)

 regval = OMAP_HSMMC_READ(host-base, SYSCTL);
 regval = regval  ~(CLKD_MASK | DTO_MASK);
 -   regval = regval | (calc_divisor(host, ios)  6) | (DTO  16);
 +   clkdiv = calc_divisor(host, ios);
 +   regval = regval | (clkdiv  6) | (DTO  16);
 OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
 OMAP_HSMMC_WRITE(host-base, SYSCTL,
 OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
 @@ -508,6 +512,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host 
 *host)
  time_before(jiffies, timeout))
 cpu_relax();

 +   /*
 +* Enable High-Speed Support
 +* Pre-Requisites
 +*  - Controller should support High-Speed-Enable Bit
 +*  - Controller should not be using DDR Mode
 +*  - Controller should advertise that it supports High Speed
 +*in capabilities register
 +*  - MMC/SD clock coming out of controller  25MHz
 +*/
 +   if ((mmc_slot(host).features  HSMMC_HAS_HSPE_SUPPORT) 
 +   (ios-timing 

RE: [PATCH v3 10/10] mtd: nand: omap2: use gpmc provided irqs

2012-09-12 Thread Mohammed, Afzal
On Tue, Sep 11, 2012 at 23:51:07, Tony Lindgren wrote:

 Ah thanks, that's a copy paste UTF-8 issue. I'll just fold
 in the fixes and push them out to a new devel-gpmc-fixed
 branch.

Thanks Tony

Regards
Afzal


RE: [PATCH v6 10/10] ARM: OMAP2+: tusb6010: generic timing calculation

2012-09-12 Thread Mohammed, Afzal
Hi Tony,

On Wed, Sep 12, 2012 at 00:16:06, Tony Lindgren wrote:

 Here are the timing changes with and without this patch from
 my n800. You can just diff the two files to see some differences.

Hmm.. that was pretty close, OneNAND async,sync as well as
tusb sync values were same.

But some of the tusb async values is less by one. I need
to get it right.

And thanks for sending me the easily diff-able logs.

Regards
Afzal


[PATCH v6 0/7] ARM: OMAP2+: PM: introduce the power domains functional states

2012-09-12 Thread Jean Pihet
Here is a re-spin after some comments and suggestions after review
and discussions.

Implement the functional states for the power domains:
- unify the API to use the functional states. The new API
  consists of the pwrdm_set*_fpwrst and pwrdm_read*_fpwrst
  functions and is the API to use to control the power domains
  power and logic states,
- reorganize the powerdomain API in internal and external parts,
  in powerdomain.h [1]
- protect the power domain state change by a lock in the
  functions that read and set the powerdomains next functional state,
- introduce the functional states for power domains power states and
  logic power states [2], and the conversion functions between the
  functional and internal states. The conversion functions are
  lightweight and generic. The power domains allowed states [3] are
  defined in the pwrsts and pwrsts_logic_ret fields of the struct
  powerdomain,
- program the logic power state of power domains from the functional
  states, in pwrdm_set*_fpwrst
- convert the OMAP2/3/4 PM code to use the updated API,
- provide the power domains statistics by functional states,
- provide ftrace tracepoints with the functional state,
- provide error logs in critical code, which makes the development
  easier.

Notes:
[1] the physical split of internal and external APIs into
   different header files is not part of this series, it comes as
   a separate patch set.
[2] the abstraction for functional power states provides a generic
   way of controlling the power domains states across all OMAP
   chipsets and revisions. The users of the functional power states
   are (1) the OMAP PM components: cpuidle, suspend, pm, clock*
   and (2) the per-device PM QoS constraints and the generic power
   domain frameworks. All those users require a generic abstraction
   of the power domain states while the low level power domain code
   has the knowledge of the internal settings (power, logic... states).
[3] About the power domains allowed states:
   Power domains have varied capabilities, as defined by the value of
   the pwrsts and pwrsts_logic_ret fields of the powerdomain struct.
   When reading or setting a low power state such as OFF/RET, a specific
   requested state may not be supported on the given power domain.
   In the states conversion functions a power or logic state is first
   looked for in the lower power states in order to maximize the power
   savings, then if not found in the higher power states. An iteration
   function is used, as suggested by Rajendra Nayak rna...@ti.com
   This functionality brings consistency in the functional power states
   core code and acts as a guard against hardware implementations
   discrepancies, e.g. some power domains only support the RET logic
   state although reading the logic state registers (previous, current
   and next) always returns OFF. The DSS power domain on OMAP3 is an
   example.


Based on mainline kernel 3.6.0-rc4.

Tested on OMAP3 Beagleboard, with suspend and cpuidle in RET and
OFF modes.


History:
 v6:
 - rework to a lighter and generic conversion mechanism between the
   functional and the internal states (static internal functions
   are defined instead of using the pwrdm fops function pointers),
 - the functional power states API now has a function to set the next
   power state (pwrdm_set_next_fpwrst) and a function to program (i.e.
   set, apply the state and wait for completion) the power state
   (pwrdm_set_fpwrst),
 - When attempting a low power state such as OFF/RET, a specific
   requested state may not be supported on the given power domain.
   In the states conversion functions a power state is first looked
   for in the lower power states in order to maximize the power savings,
   then if not found in the higher power states. Only allowed states are
   returned by the conversion functions, as defined by the value of the
   pwrsts and pwrsts_logic_ret fields of the powerdomain struct.
 - added more error logging: check for NULL in pwrdm, better error
   messages using pr_err_ratelimited etc.

 v5:
 - complete rework after review and suggestions,
 - improved locking on next state read/write; spinlock instead of mutex
 - added more error logging in critical code,

 v4:
 - reworked the code after internal review and testing with OMAP34 device
   OFF,
 - fixed the tracepoints generation code,
 - introduce a function that returns power domains achievable functional
   states, in order to return a valid state for power domains that only
   support some of the power states. Although it has been tested OK the
   code is in RFC state.

 v3:
 - fix a bug in OMAP3 cpuidle which prevented the IO wake-ups in PER

 v2:
 - add the logic power states,
 - provide the power domains statistics by functional states

 v1:
 - initial implementation, in RFC state


Jean Pihet (6):
  ARM: OMAP2+: PM: introduce power domains functional states
  ARM: OMAP2+: PM: add a lock to protect the powerdomains next state
  ARM: OMAP2+: 

[PATCH 1/7] ARM: OMAP2+: PM: introduce power domains functional states

2012-09-12 Thread Jean Pihet
Introduce the functional states for power domains, which include
the power states and the logic states.
This patch provides the API functions to set and read the power
domains functional state and internal functions to convert between
the functional (i.e. logical) and the internal (or registers) values.

In the new API only the functions pwrdm_set_next_fpwrst and
pwrdm_set_next_fpwrst shall be used to change a power domain
target state, along with the associated PWRDM_FUNC_* and
PWRDM_LOGIC_* macros as the state parameters.

Note about the power domains allowed states:
Power domains have varied capabilities, as defined by the value of
the pwrsts and pwrsts_logic_ret fields of the powerdomain struct.
When reading or setting a low power state such as OFF/RET, a specific
requested state may not be supported on the given power domain.
In the states conversion functions a power or logic state is first
looked for in the lower power states in order to maximize the power
savings, then if not found in the higher power states. An iteration
function is used, as suggested by Rajendra Nayak rna...@ti.com

This functionality brings consistency in the functional power states
core code and acts as a guard against hardware implementations
discrepancies, e.g. some power domains only support the RET logic
state although reading the logic state registers (previous, current
and next) always returns OFF. The DSS power domain on OMAP3 is an
example.

Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Nishanth Menon n...@ti.com
---
 arch/arm/mach-omap2/powerdomain.c |  374 -
 arch/arm/mach-omap2/powerdomain.h |   32 +++-
 2 files changed, 396 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index 69b36e1..18c21fa 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -1,7 +1,7 @@
 /*
  * OMAP powerdomain control
  *
- * Copyright (C) 2007-2008, 2011 Texas Instruments, Inc.
+ * Copyright (C) 2007-2008, 2011-2012 Texas Instruments, Inc.
  * Copyright (C) 2007-2011 Nokia Corporation
  *
  * Written by Paul Walmsley
@@ -128,14 +128,14 @@ static void _update_logic_membank_counters(struct 
powerdomain *pwrdm)
 
prev_logic_pwrst = pwrdm_read_prev_logic_pwrst(pwrdm);
if ((pwrdm-pwrsts_logic_ret == PWRSTS_OFF_RET) 
-   (prev_logic_pwrst == PWRDM_POWER_OFF))
+   (prev_logic_pwrst == PWRDM_LOGIC_MEM_PWRST_OFF))
pwrdm-ret_logic_off_counter++;
 
for (i = 0; i  pwrdm-banks; i++) {
prev_mem_pwrst = pwrdm_read_prev_mem_pwrst(pwrdm, i);
 
if ((pwrdm-pwrsts_mem_ret[i] == PWRSTS_OFF_RET) 
-   (prev_mem_pwrst == PWRDM_POWER_OFF))
+   (prev_mem_pwrst == PWRDM_LOGIC_MEM_PWRST_OFF))
pwrdm-ret_mem_off_counter[i]++;
}
 }
@@ -199,6 +199,201 @@ static int _pwrdm_post_transition_cb(struct powerdomain 
*pwrdm, void *unused)
return 0;
 }
 
+/**
+ * Search down then up for a valid state from a list of allowed states.
+ * Used by states conversion functions (_pwrdm_fpwrst_to_*) to look for
+ * allowed power and logic states for a powerdomain.
+ *
+ * @pwrsts: list of allowed states, defined as a bitmask
+ * @pwrst: initial state to be used as a starting point
+ * @min: minimum (i.e. lowest consumption) allowed state
+ * @max: maximum (i.e. highest consumption) allowed state
+ *
+ * Returns the matching allowed state.
+ */
+static inline int _match_pwrst(u32 pwrsts, int pwrst, int min, int max)
+{
+   int found = 1, new_pwrst = pwrst;
+
+   /*
+* If the power domain does not allow any state programmation
+* return the max state which is always allowed
+*/
+   if (!pwrsts)
+   return max;
+
+   /*
+* Search lower: if the requested state is not supported
+* try the lower states, stopping at the minimum allowed
+* state
+*/
+   while (!(pwrsts  (1  new_pwrst))) {
+   if (new_pwrst = min) {
+   found = 0;
+   break;
+   }
+   new_pwrst--;
+   }
+
+   /*
+* Search higher: if no lower state found fallback to the higher
+* states, stopping at the maximum allowed state
+*/
+   if (!found) {
+   new_pwrst = pwrst;
+   while (!(pwrsts  (1  new_pwrst))) {
+   if (new_pwrst = max) {
+   new_pwrst = max;
+   break;
+   }
+   new_pwrst++;
+   }
+   }
+
+   return new_pwrst;
+}
+
+/**
+ * _pwrdm_fpwrst_to_pwrst - Convert functional (i.e. logical) to
+ * internal (i.e. registers) values for the power domains states.
+ * @struct powerdomain * to convert the values for
+ * 

[PATCH 2/7] ARM: OMAP2+: PM: add a lock to protect the powerdomains next state

2012-09-12 Thread Jean Pihet
pwrdm_set_fpwrst, pwrdm_set_next_fpwrst and pwrdm_read_next_fpwrst
are intented to be the only API to program and request the next
state of a power domain.
This patch protects the power domain next state settings and structs
from concurrent accesses by the use of a lock.

A spinlock is used since the API functions can be called from
atomic context (.i.e) either from cpuidle path or suspend path.

[ambr...@ti.com: reported the atomic context issue and suggested
to replace the initial mutex with a spinlock]

Signed-off-by: Jean Pihet j-pi...@ti.com
Reported-by: Ambresh K ambr...@ti.com
---
 arch/arm/mach-omap2/powerdomain.c |   40 
 arch/arm/mach-omap2/powerdomain.h |3 ++
 2 files changed, 38 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index 18c21fa..f4b219f 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -102,6 +102,7 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
INIT_LIST_HEAD(pwrdm-voltdm_node);
voltdm_add_pwrdm(voltdm, pwrdm);
 
+   spin_lock_init(pwrdm-lock);
list_add(pwrdm-node, pwrdm_list);
 
/* Initialize the powerdomain's state counter */
@@ -394,6 +395,22 @@ static int _pwrdm_pwrst_to_fpwrst(struct powerdomain 
*pwrdm, u8 pwrst, u8 logic)
 }
 
 
+/**
+ * _pwrdm_read_next_fpwrst - get next powerdomain functional power state
+ * @pwrdm: struct powerdomain * to get power state
+ *
+ * Return the powerdomain @pwrdm's next functional power state.
+ * Returns -EINVAL if the powerdomain pointer is null or returns
+ * the next power state upon success.
+ */
+static int _pwrdm_read_next_fpwrst(struct powerdomain *pwrdm)
+{
+   int next_pwrst = pwrdm_read_next_pwrst(pwrdm);
+   int next_logic = pwrdm_read_logic_retst(pwrdm);
+
+   return _pwrdm_pwrst_to_fpwrst(pwrdm, next_pwrst, next_logic);
+}
+
 /* Public functions */
 
 /**
@@ -677,6 +694,7 @@ int pwrdm_set_fpwrst(struct powerdomain *pwrdm, enum 
pwrdm_func_state fpwrst)
int pwrst = _pwrdm_fpwrst_to_pwrst(pwrdm, fpwrst);
int logic = _pwrdm_fpwrst_to_logic_pwrst(pwrdm, fpwrst);
int sleep_switch = -1, ret = 0, hwsup = 0;
+   unsigned long flags;
 
if (!pwrdm || IS_ERR(pwrdm) || (pwrst  0) || (logic  0)) {
pr_debug(%s: invalid params: pwrdm=%p, fpwrst=%0x\n,
@@ -687,9 +705,11 @@ int pwrdm_set_fpwrst(struct powerdomain *pwrdm, enum 
pwrdm_func_state fpwrst)
pr_debug(%s: set fpwrst %0x to pwrdm %s\n,
 __func__, fpwrst, pwrdm-name);
 
-   next_fpwrst = pwrdm_read_next_fpwrst(pwrdm);
+   spin_lock_irqsave(pwrdm-lock, flags);
+
+   next_fpwrst = _pwrdm_read_next_fpwrst(pwrdm);
if (next_fpwrst == fpwrst)
-   return ret;
+   goto out;
 
curr_pwrst = pwrdm_read_pwrst(pwrdm);
if (curr_pwrst  PWRDM_POWER_ON) {
@@ -725,6 +745,8 @@ int pwrdm_set_fpwrst(struct powerdomain *pwrdm, enum 
pwrdm_func_state fpwrst)
break;
}
 
+out:
+   spin_unlock_irqrestore(pwrdm-lock, flags);
return ret;
 }
 
@@ -741,6 +763,7 @@ int pwrdm_set_next_fpwrst(struct powerdomain *pwrdm,
int pwrst = _pwrdm_fpwrst_to_pwrst(pwrdm, fpwrst);
int logic = _pwrdm_fpwrst_to_logic_pwrst(pwrdm, fpwrst);
int ret = 0;
+   unsigned long flags;
 
if (!pwrdm || IS_ERR(pwrdm) || (pwrst  0) || (logic  0)) {
pr_debug(%s: invalid params: pwrdm=%p, fpwrst=%0x\n,
@@ -751,6 +774,8 @@ int pwrdm_set_next_fpwrst(struct powerdomain *pwrdm,
pr_debug(%s: set fpwrst %0x to pwrdm %s\n,
 __func__, fpwrst, pwrdm-name);
 
+   spin_lock_irqsave(pwrdm-lock, flags);
+
ret = pwrdm_set_logic_retst(pwrdm, logic);
if (ret)
pr_err(%s: unable to set logic state %0x of powerdomain: %s\n,
@@ -761,6 +786,7 @@ int pwrdm_set_next_fpwrst(struct powerdomain *pwrdm,
pr_err(%s: unable to set power state %0x of powerdomain: %s\n,
   __func__, pwrst, pwrdm-name);
 
+   spin_unlock_irqrestore(pwrdm-lock, flags);
return ret;
 };
 
@@ -837,10 +863,14 @@ int pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
  */
 int pwrdm_read_next_fpwrst(struct powerdomain *pwrdm)
 {
-   int next_pwrst = pwrdm_read_next_pwrst(pwrdm);
-   int next_logic = pwrdm_read_logic_retst(pwrdm);
+   int ret;
+   unsigned long flags;
 
-   return _pwrdm_pwrst_to_fpwrst(pwrdm, next_pwrst, next_logic);
+   spin_lock_irqsave(pwrdm-lock, flags);
+   ret = _pwrdm_read_next_fpwrst(pwrdm);
+   spin_unlock_irqrestore(pwrdm-lock, flags);
+
+   return ret;
 }
 
 /**
diff --git a/arch/arm/mach-omap2/powerdomain.h 
b/arch/arm/mach-omap2/powerdomain.h
index aa5de4f..c3dc363 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -17,6 +17,7 @@
 #include linux/types.h
 #include linux/list.h
 

[PATCH 4/7] ARM: OMAP2+: PM: use power domain functional state in stats counters

2012-09-12 Thread Jean Pihet
The PM code uses some counters to keep track of the power domains
transitions, in order to provide the information to drivers (in
pwrdm_get_context_loss_count) and to expose the information to
sysfs for debug purpose.

This patch provides the information for each functional state.

Signed-off-by: Jean Pihet j-pi...@ti.com
---
 arch/arm/mach-omap2/pm-debug.c|   15 ---
 arch/arm/mach-omap2/powerdomain.c |   12 ++--
 arch/arm/mach-omap2/powerdomain.h |4 ++--
 3 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 814bcd9..8eaa3f2 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -53,9 +53,10 @@ enum {
DEBUG_FILE_TIMERS,
 };
 
-static const char pwrdm_state_names[][PWRDM_MAX_PWRSTS] = {
+static const char pwrdm_state_names[][PWRDM_MAX_FUNC_PWRSTS] = {
OFF,
-   RET,
+   OSWR,
+   CSWR,
INA,
ON
 };
@@ -102,13 +103,13 @@ static int pwrdm_dbg_show_counter(struct powerdomain 
*pwrdm, void *user)
strncmp(pwrdm-name, dpll, 4) == 0)
return 0;
 
-   if (pwrdm-state != pwrdm_read_pwrst(pwrdm))
+   if (pwrdm-state != pwrdm_read_fpwrst(pwrdm))
printk(KERN_ERR pwrdm state mismatch(%s) %d != %d\n,
-   pwrdm-name, pwrdm-state, pwrdm_read_pwrst(pwrdm));
+  pwrdm-name, pwrdm-state, pwrdm_read_fpwrst(pwrdm));
 
seq_printf(s, %s (%s), pwrdm-name,
pwrdm_state_names[pwrdm-state]);
-   for (i = 0; i  PWRDM_MAX_PWRSTS; i++)
+   for (i = 0; i  PWRDM_MAX_FUNC_PWRSTS; i++)
seq_printf(s, ,%s:%d, pwrdm_state_names[i],
pwrdm-state_counter[i]);
 
@@ -137,7 +138,7 @@ static int pwrdm_dbg_show_timer(struct powerdomain *pwrdm, 
void *user)
seq_printf(s, %s (%s), pwrdm-name,
pwrdm_state_names[pwrdm-state]);
 
-   for (i = 0; i  4; i++)
+   for (i = 0; i  PWRDM_MAX_FUNC_PWRSTS; i++)
seq_printf(s, ,%s:%lld, pwrdm_state_names[i],
pwrdm-state_timer[i]);
 
@@ -211,7 +212,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, 
void *dir)
 
t = sched_clock();
 
-   for (i = 0; i  4; i++)
+   for (i = 0; i  PWRDM_MAX_FUNC_PWRSTS; i++)
pwrdm-state_timer[i] = 0;
 
pwrdm-timer = t;
diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index 82ae9e9..267241f 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -106,7 +106,7 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
list_add(pwrdm-node, pwrdm_list);
 
/* Initialize the powerdomain's state counter */
-   for (i = 0; i  PWRDM_MAX_PWRSTS; i++)
+   for (i = 0; i  PWRDM_MAX_FUNC_PWRSTS; i++)
pwrdm-state_counter[i] = 0;
 
pwrdm-ret_logic_off_counter = 0;
@@ -114,7 +114,7 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
pwrdm-ret_mem_off_counter[i] = 0;
 
pwrdm_wait_transition(pwrdm);
-   pwrdm-state = pwrdm_read_pwrst(pwrdm);
+   pwrdm-state = pwrdm_read_fpwrst(pwrdm);
pwrdm-state_counter[pwrdm-state] = 1;
 
pr_debug(powerdomain: registered %s\n, pwrdm-name);
@@ -149,17 +149,17 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm, 
int flag)
if (pwrdm == NULL)
return -EINVAL;
 
-   state = pwrdm_read_pwrst(pwrdm);
+   state = pwrdm_read_fpwrst(pwrdm);
 
switch (flag) {
case PWRDM_STATE_NOW:
prev = pwrdm-state;
break;
case PWRDM_STATE_PREV:
-   prev = pwrdm_read_prev_pwrst(pwrdm);
+   prev = pwrdm_read_prev_fpwrst(pwrdm);
if (pwrdm-state != prev)
pwrdm-state_counter[prev]++;
-   if (prev == PWRDM_POWER_RET)
+   if (prev == PWRDM_FUNC_PWRST_OSWR)
_update_logic_membank_counters(pwrdm);
/*
 * If the power domain did not hit the desired state,
@@ -1414,7 +1414,7 @@ int pwrdm_get_context_loss_count(struct powerdomain 
*pwrdm)
return -ENODEV;
}
 
-   count = pwrdm-state_counter[PWRDM_POWER_OFF];
+   count = pwrdm-state_counter[PWRDM_FUNC_PWRST_OFF];
count += pwrdm-ret_logic_off_counter;
 
for (i = 0; i  pwrdm-banks; i++)
diff --git a/arch/arm/mach-omap2/powerdomain.h 
b/arch/arm/mach-omap2/powerdomain.h
index c3dc363..a29caec 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -146,7 +146,7 @@ struct powerdomain {
struct list_head voltdm_node;
spinlock_t lock;
int state;
-   unsigned state_counter[PWRDM_MAX_PWRSTS];
+   unsigned state_counter[PWRDM_MAX_FUNC_PWRSTS];
unsigned ret_logic_off_counter;

[PATCH 5/7] ARM: OMAP2+: PM debug: trace the functional power domains states

2012-09-12 Thread Jean Pihet
Trace the power domain transitions using the functional power states,
which include the power and logic states.

While at it, fix the trace in the case a power domain did not hit
the desired state, as reported by Paul Walmsley.

Reported-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
 arch/arm/mach-omap2/powerdomain.c |   23 +--
 1 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index 267241f..2277ad3 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -144,7 +144,7 @@ static void _update_logic_membank_counters(struct 
powerdomain *pwrdm)
 static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
 {
 
-   int prev, state, trace_state = 0;
+   int prev, next, state, trace_state;
 
if (pwrdm == NULL)
return -EINVAL;
@@ -165,10 +165,10 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm, 
int flag)
 * If the power domain did not hit the desired state,
 * generate a trace event with both the desired and hit states
 */
-   if (state != prev) {
+   next = pwrdm_read_next_fpwrst(pwrdm);
+   if (next != prev) {
trace_state = (PWRDM_TRACE_STATES_FLAG |
-  ((state  OMAP_POWERSTATE_MASK)  8) |
-  ((prev  OMAP_POWERSTATE_MASK)  0));
+  (next  8) | (prev  0));
trace_power_domain_target(pwrdm-name, trace_state,
  smp_processor_id());
}
@@ -723,6 +723,10 @@ int pwrdm_set_fpwrst(struct powerdomain *pwrdm, enum 
pwrdm_func_state fpwrst)
}
}
 
+   /* Trace the pwrdm desired target state */
+   trace_power_domain_target(pwrdm-name, next_fpwrst,
+ smp_processor_id());
+
if (logic != pwrdm_read_logic_retst(pwrdm))
pwrdm_set_logic_retst(pwrdm, logic);
 
@@ -776,6 +780,10 @@ int pwrdm_set_next_fpwrst(struct powerdomain *pwrdm,
 
spin_lock_irqsave(pwrdm-lock, flags);
 
+   /* Trace the pwrdm desired target state */
+   trace_power_domain_target(pwrdm-name, fpwrst,
+ smp_processor_id());
+
ret = pwrdm_set_logic_retst(pwrdm, logic);
if (ret)
pr_err(%s: unable to set logic state %0x of powerdomain: %s\n,
@@ -821,13 +829,8 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 
pwrst)
pr_debug(powerdomain: setting next powerstate for %s to %0x\n,
 pwrdm-name, pwrst);
 
-   if (arch_pwrdm  arch_pwrdm-pwrdm_set_next_pwrst) {
-   /* Trace the pwrdm desired target state */
-   trace_power_domain_target(pwrdm-name, pwrst,
- smp_processor_id());
-   /* Program the pwrdm desired target state */
+   if (arch_pwrdm  arch_pwrdm-pwrdm_set_next_pwrst)
ret = arch_pwrdm-pwrdm_set_next_pwrst(pwrdm, pwrst);
-   }
 
return ret;
 }
-- 
1.7.7.6

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


[PATCH 3/7] ARM: OMAP2+: PM: use the functional power states API

2012-09-12 Thread Jean Pihet
Use the functional power states as the API to control power
domains:
- use the PWRDM_FUNC_PWRST_* and PWRDM_LOGIC_MEM_PWRST_*
  macros for the power states and logic settings,
- the function pwrdm_set_next_fpwrst, which controls
  the power domains next power and logic settings, shall
  be used instead of pwrdm_set_next_pwrst to program the
  power domains next states,
- the function pwrdm_set_fpwrst, which programs the power
  domains power and logic settings, shall be used instead
  of omap_set_pwrdm_state.

Signed-off-by: Jean Pihet j-pi...@ti.com
---
 arch/arm/mach-omap2/cpuidle34xx.c |   58 +++---
 arch/arm/mach-omap2/cpuidle44xx.c |   24 --
 arch/arm/mach-omap2/omap-hotplug.c|2 +-
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |   39 ---
 arch/arm/mach-omap2/pm24xx.c  |   14 ++---
 arch/arm/mach-omap2/pm34xx.c  |   75 +++--
 arch/arm/mach-omap2/pm44xx.c  |   24 --
 arch/arm/mach-omap2/powerdomain.c |2 +-
 8 files changed, 114 insertions(+), 124 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index f2a49a4..4ca37d2 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -44,32 +44,32 @@ struct omap3_idle_statedata {
 
 static struct omap3_idle_statedata omap3_idle_data[] = {
{
-   .mpu_state = PWRDM_POWER_ON,
-   .core_state = PWRDM_POWER_ON,
+   .mpu_state = PWRDM_FUNC_PWRST_ON,
+   .core_state = PWRDM_FUNC_PWRST_ON,
},
{
-   .mpu_state = PWRDM_POWER_ON,
-   .core_state = PWRDM_POWER_ON,
+   .mpu_state = PWRDM_FUNC_PWRST_ON,
+   .core_state = PWRDM_FUNC_PWRST_ON,
},
{
-   .mpu_state = PWRDM_POWER_RET,
-   .core_state = PWRDM_POWER_ON,
+   .mpu_state = PWRDM_FUNC_PWRST_CSWR,
+   .core_state = PWRDM_FUNC_PWRST_ON,
},
{
-   .mpu_state = PWRDM_POWER_OFF,
-   .core_state = PWRDM_POWER_ON,
+   .mpu_state = PWRDM_FUNC_PWRST_OFF,
+   .core_state = PWRDM_FUNC_PWRST_ON,
},
{
-   .mpu_state = PWRDM_POWER_RET,
-   .core_state = PWRDM_POWER_RET,
+   .mpu_state = PWRDM_FUNC_PWRST_CSWR,
+   .core_state = PWRDM_FUNC_PWRST_CSWR,
},
{
-   .mpu_state = PWRDM_POWER_OFF,
-   .core_state = PWRDM_POWER_RET,
+   .mpu_state = PWRDM_FUNC_PWRST_OFF,
+   .core_state = PWRDM_FUNC_PWRST_CSWR,
},
{
-   .mpu_state = PWRDM_POWER_OFF,
-   .core_state = PWRDM_POWER_OFF,
+   .mpu_state = PWRDM_FUNC_PWRST_OFF,
+   .core_state = PWRDM_FUNC_PWRST_OFF,
},
 };
 
@@ -84,8 +84,8 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
 
local_fiq_disable();
 
-   pwrdm_set_next_pwrst(mpu_pd, mpu_state);
-   pwrdm_set_next_pwrst(core_pd, core_state);
+   pwrdm_set_next_fpwrst(mpu_pd, mpu_state);
+   pwrdm_set_next_fpwrst(core_pd, core_state);
 
if (omap_irq_pending() || need_resched())
goto return_sleep_time;
@@ -100,7 +100,7 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
 * Call idle CPU PM enter notifier chain so that
 * VFP context is saved.
 */
-   if (mpu_state == PWRDM_POWER_OFF)
+   if (mpu_state == PWRDM_FUNC_PWRST_OFF)
cpu_pm_enter();
 
/* Execute ARM wfi */
@@ -110,7 +110,7 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
 * Call idle CPU PM enter notifier chain to restore
 * VFP context.
 */
-   if (pwrdm_read_prev_pwrst(mpu_pd) == PWRDM_POWER_OFF)
+   if (pwrdm_read_prev_fpwrst(mpu_pd) == PWRDM_FUNC_PWRST_OFF)
cpu_pm_exit();
 
/* Re-allow idle for C1 */
@@ -159,20 +159,20 @@ static int next_valid_state(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index)
 {
struct omap3_idle_statedata *cx = omap3_idle_data[index];
-   u32 mpu_deepest_state = PWRDM_POWER_RET;
-   u32 core_deepest_state = PWRDM_POWER_RET;
+   u32 mpu_deepest_state = PWRDM_FUNC_PWRST_CSWR;
+   u32 core_deepest_state = PWRDM_FUNC_PWRST_CSWR;
int idx;
int next_index = 0; /* C1 is the default value */
 
if (enable_off_mode) {
-   mpu_deepest_state = PWRDM_POWER_OFF;
+   mpu_deepest_state = PWRDM_FUNC_PWRST_OFF;
/*
 * Erratum i583: valable for ES rev  Es1.2 on 3630.
 * CORE OFF mode is not supported in a stable form, restrict
 * instead the CORE state to RET.
 */
if (!IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583))
-

[PATCH 6/7] ARM: OMAP2+: powerdomain: add error logs

2012-09-12 Thread Jean Pihet
From: Nishanth Menon n...@ti.com

Silent failure makes debug hard. So, provide rate limited error
messages in functional and oft-used code to prevent spam
when something goes wrong.

Signed-off-by: Nishanth Menon n...@ti.com
---
 arch/arm/mach-omap2/powerdomain.c |  177 +++--
 1 files changed, 130 insertions(+), 47 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index 2277ad3..37dfabf 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -19,6 +19,7 @@
 #include linux/list.h
 #include linux/errno.h
 #include linux/string.h
+#include linux/ratelimit.h
 #include trace/events/power.h
 
 #include cm2xxx_3xxx.h
@@ -146,8 +147,10 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm, 
int flag)
 
int prev, next, state, trace_state;
 
-   if (pwrdm == NULL)
+   if (!pwrdm) {
+   pr_err_ratelimited(%s: NULL pwrdm\n, __func__);
return -EINVAL;
+   }
 
state = pwrdm_read_fpwrst(pwrdm);
 
@@ -174,6 +177,8 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm, 
int flag)
}
break;
default:
+   pr_err_ratelimited(%s: powerdomain %s: bad flag %0x\n,
+  __func__, pwrdm-name, flag);
return -EINVAL;
}
 
@@ -385,6 +390,8 @@ static int _pwrdm_pwrst_to_fpwrst(struct powerdomain 
*pwrdm, u8 pwrst, u8 logic)
ret = PWRDM_FUNC_PWRST_OFF;
break;
default:
+   pr_err_ratelimited(%s: powerdomain %s: bad pwrst %0x\n,
+  __func__, pwrdm-name, pwrst);
ret = -EINVAL;
}
 
@@ -697,8 +704,8 @@ int pwrdm_set_fpwrst(struct powerdomain *pwrdm, enum 
pwrdm_func_state fpwrst)
unsigned long flags;
 
if (!pwrdm || IS_ERR(pwrdm) || (pwrst  0) || (logic  0)) {
-   pr_debug(%s: invalid params: pwrdm=%p, fpwrst=%0x\n,
-__func__, pwrdm, fpwrst);
+   pr_err_ratelimited(%s: invalid params: pwrdm=%p, fpwrst=%0x\n,
+  __func__, pwrdm, fpwrst);
return -EINVAL;
}
 
@@ -727,13 +734,17 @@ int pwrdm_set_fpwrst(struct powerdomain *pwrdm, enum 
pwrdm_func_state fpwrst)
trace_power_domain_target(pwrdm-name, next_fpwrst,
  smp_processor_id());
 
-   if (logic != pwrdm_read_logic_retst(pwrdm))
-   pwrdm_set_logic_retst(pwrdm, logic);
+   if (logic != pwrdm_read_logic_retst(pwrdm)) {
+   ret = pwrdm_set_logic_retst(pwrdm, logic);
+   if (ret)
+   pr_err_ratelimited(%s: unable to set logic state %0x 
of powerdomain %s, ret=%d\n,
+  __func__, logic, pwrdm-name, ret);
+   }
 
ret = pwrdm_set_next_pwrst(pwrdm, pwrst);
if (ret)
-   pr_err(%s: unable to set power state of powerdomain: %s\n,
-  __func__, pwrdm-name);
+   pr_err_ratelimited(%s: unable to set power state %0x of 
powerdomain %s, ret=%d\n,
+  __func__, pwrst, pwrdm-name, ret);
 
switch (sleep_switch) {
case FORCEWAKEUP_SWITCH:
@@ -770,8 +781,8 @@ int pwrdm_set_next_fpwrst(struct powerdomain *pwrdm,
unsigned long flags;
 
if (!pwrdm || IS_ERR(pwrdm) || (pwrst  0) || (logic  0)) {
-   pr_debug(%s: invalid params: pwrdm=%p, fpwrst=%0x\n,
-__func__, pwrdm, fpwrst);
+   pr_err_ratelimited(%s: invalid params: pwrdm=%p, fpwrst=%0x\n,
+  __func__, pwrdm, fpwrst);
return -EINVAL;
}
 
@@ -786,13 +797,13 @@ int pwrdm_set_next_fpwrst(struct powerdomain *pwrdm,
 
ret = pwrdm_set_logic_retst(pwrdm, logic);
if (ret)
-   pr_err(%s: unable to set logic state %0x of powerdomain: %s\n,
-  __func__, logic, pwrdm-name);
+   pr_err_ratelimited(%s: unable to set logic state %0x of 
powerdomain %s, ret=%d\n,
+  __func__, logic, pwrdm-name, ret);
 
ret = pwrdm_set_next_pwrst(pwrdm, pwrst);
if (ret)
-   pr_err(%s: unable to set power state %0x of powerdomain: %s\n,
-  __func__, pwrst, pwrdm-name);
+   pr_err_ratelimited(%s: unable to set power state %0x of 
powerdomain %s, ret=%d\n,
+  __func__, pwrst, pwrdm-name, ret);
 
spin_unlock_irqrestore(pwrdm-lock, flags);
return ret;
@@ -813,8 +824,10 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 
pwrst)
 {
int ret = -EINVAL;
 
-   if (!pwrdm)
+   if (!pwrdm) {
+   pr_err_ratelimited(%s: NULL pwrdm\n, __func__);
return -EINVAL;
+   }
 
/*
 * 

[PATCH 7/7] ARM: OMAP2+: PM: reorganize the powerdomain API in public and private parts

2012-09-12 Thread Jean Pihet
The newly added code for functional power states re-defines the
API to query and control the power domains settings.

The API is now split in the following parts in powerdomain.h:
- the public or external API, to be used by external PM components:
  cpuidle, suspend, pm, clock* etc.
- the private or internal API, to be used by the low level PM code
  only: powerdomain*, pm-debug, hwmod, voltage, clockdomain.

The function omap_set_pwrdm_state is not used anymore and so is
removed.

No functional change is introduced by this patch.

Note: the API reorganization in a public and private header files
is not part of this patch, this comes as a subsequent clean-up
patch series.

Signed-off-by: Jean Pihet j-pi...@ti.com
---
 arch/arm/mach-omap2/pm.c  |   62 
 arch/arm/mach-omap2/pm.h  |1 -
 arch/arm/mach-omap2/powerdomain.h |  112 +
 3 files changed, 63 insertions(+), 112 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 9cb5ced..dfe702b 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -74,10 +74,6 @@ static void __init omap2_init_processor_devices(void)
}
 }
 
-/* Types of sleep_switch used in omap_set_pwrdm_state */
-#define FORCEWAKEUP_SWITCH 0
-#define LOWPOWERSTATE_SWITCH   1
-
 int __init omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused)
 {
if (clkdm-flags  CLKDM_CAN_ENABLE_AUTO)
@@ -89,64 +85,6 @@ int __init omap_pm_clkdms_setup(struct clockdomain *clkdm, 
void *unused)
 }
 
 /*
- * This sets pwrdm state (other than mpu  core. Currently only ON 
- * RET are supported.
- */
-int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 pwrst)
-{
-   u8 curr_pwrst, next_pwrst;
-   int sleep_switch = -1, ret = 0, hwsup = 0;
-
-   if (!pwrdm || IS_ERR(pwrdm))
-   return -EINVAL;
-
-   while (!(pwrdm-pwrsts  (1  pwrst))) {
-   if (pwrst == PWRDM_POWER_OFF)
-   return ret;
-   pwrst--;
-   }
-
-   next_pwrst = pwrdm_read_next_pwrst(pwrdm);
-   if (next_pwrst == pwrst)
-   return ret;
-
-   curr_pwrst = pwrdm_read_pwrst(pwrdm);
-   if (curr_pwrst  PWRDM_POWER_ON) {
-   if ((curr_pwrst  pwrst) 
-   (pwrdm-flags  PWRDM_HAS_LOWPOWERSTATECHANGE)) {
-   sleep_switch = LOWPOWERSTATE_SWITCH;
-   } else {
-   hwsup = clkdm_in_hwsup(pwrdm-pwrdm_clkdms[0]);
-   clkdm_wakeup(pwrdm-pwrdm_clkdms[0]);
-   sleep_switch = FORCEWAKEUP_SWITCH;
-   }
-   }
-
-   ret = pwrdm_set_next_pwrst(pwrdm, pwrst);
-   if (ret)
-   pr_err(%s: unable to set power state of powerdomain: %s\n,
-  __func__, pwrdm-name);
-
-   switch (sleep_switch) {
-   case FORCEWAKEUP_SWITCH:
-   if (hwsup)
-   clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
-   else
-   clkdm_sleep(pwrdm-pwrdm_clkdms[0]);
-   break;
-   case LOWPOWERSTATE_SWITCH:
-   pwrdm_set_lowpwrstchange(pwrdm);
-   pwrdm_wait_transition(pwrdm);
-   pwrdm_state_switch(pwrdm);
-   break;
-   }
-
-   return ret;
-}
-
-
-
-/*
  * This API is to be called during init to set the various voltage
  * domains to the voltage as per the opp table. Typically we boot up
  * at the nominal voltage. So this function finds out the rate of
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 686137d..707e9cb 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -33,7 +33,6 @@ static inline int omap4_idle_init(void)
 extern void *omap3_secure_ram_storage;
 extern void omap3_pm_off_mode_enable(int);
 extern void omap_sram_idle(void);
-extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
 extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
 extern int (*omap_pm_suspend)(void);
 
diff --git a/arch/arm/mach-omap2/powerdomain.h 
b/arch/arm/mach-omap2/powerdomain.h
index a29caec..dcd2315 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -24,6 +24,11 @@
 
 #include voltage.h
 
+/***
+ * External API, to be used by external PM components: cpuidle,
+ * suspend, pm, clock* etc.
+ ***/
+
 /* Powerdomain functional power states, used by the external API functions */
 enum pwrdm_func_state {
PWRDM_FUNC_PWRST_OFF= 0x0,
@@ -44,6 +49,64 @@ enum pwrdm_logic_mem_state {
PWRDM_MAX_LOGIC_MEM_PWRST   /* Last value, used as the max value */
 };
 
+struct clockdomain;
+struct powerdomain;
+
+struct powerdomain *pwrdm_lookup(const char *name);
+
+int pwrdm_for_each(int (*fn)(struct 

Re: [PATCHv7 00/23]I2C big cleanup

2012-09-12 Thread Shubhrajyoti
On Wednesday 12 September 2012 03:30 AM, Wolfram Sang wrote:
 Changes since v6:
  - Fix comments on setting the pdev to NULL.
  - Trivial changelog update
 Looks mostly good, thanks. Only a few comments. Oh, and I still get
 reports about a section mismatch ;)
I am using omap2plus_defconfig
 $ make --ver
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

$ make CONFIG_DEBUG_SECTION_MISMATCH=y uImage

  LD  vmlinux.o
  MODPOST vmlinux.o
  GEN .version
  CHK include/generated/compile.h
  UPD include/generated/compile.h
  CC  init/version.o
  LD  init/built-in.o
  KSYM.tmp_kallsyms1.o
  KSYM.tmp_kallsyms2.o
  LD  vmlinux
  SYSMAP  System.map
  OBJCOPY arch/arm/boot/Image
  Kernel: arch/arm/boot/Image is ready
  GZIParch/arm/boot/compressed/piggy.gzip
  CC  arch/arm/boot/compressed/misc.o
  CC  arch/arm/boot/compressed/decompress.o
  CC  arch/arm/boot/compressed/string.o
  AS  arch/arm/boot/compressed/piggy.gzip.o
  LD  arch/arm/boot/compressed/vmlinux
  OBJCOPY arch/arm/boot/zImage
  Kernel: arch/arm/boot/zImage is ready
  UIMAGE  arch/arm/boot/uImage
Image Name:   Linux-3.6.0-rc5-00022-g49fb6db
Created:  Wed Sep 12 15:24:21 2012
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:4074688 Bytes = 3979.19 kB = 3.89 MB
Load Address: 80008000
Entry Point:  80008000
  Image arch/arm/boot/uImage is ready

I donot see the warning. Am I missing something?


--
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: [PATCHv7 00/23]I2C big cleanup

2012-09-12 Thread Wolfram Sang

 I donot see the warning. Am I missing something?

I deleted my logfiles already. Ignore it for now, if it comes up again
with your new series, I will give a more detailed pointer.

Thanks,

   Wolfram

-- 
Pengutronix e.K.   | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/  |


signature.asc
Description: Digital signature


[PATCHv8 11/22] i2c: omap: switch to platform_get_irq()

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

that's a nice helper from drivers core which
will give us the exact IRQ number, instead
of a pointer to an IRQ resource.

Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   12 +++-
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index bac1f11..0da8169 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -993,11 +993,12 @@ omap_i2c_probe(struct platform_device *pdev)
 {
struct omap_i2c_dev *dev;
struct i2c_adapter  *adap;
-   struct resource *mem, *irq;
+   struct resource *mem;
struct omap_i2c_bus_platform_data *pdata = pdev-dev.platform_data;
struct device_node  *node = pdev-dev.of_node;
const struct of_device_id *match;
irq_handler_t isr;
+   int irq;
int r;
 
/* NOTE: driver uses the static register mapping */
@@ -1006,10 +1007,11 @@ omap_i2c_probe(struct platform_device *pdev)
dev_err(pdev-dev, no mem resource?\n);
return -ENODEV;
}
-   irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
-   if (!irq) {
+
+   irq = platform_get_irq(pdev, 0);
+   if (irq  0) {
dev_err(pdev-dev, no irq resource?\n);
-   return -ENODEV;
+   return irq;
}
 
dev = devm_kzalloc(pdev-dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
@@ -1043,7 +1045,7 @@ omap_i2c_probe(struct platform_device *pdev)
}
 
dev-dev = pdev-dev;
-   dev-irq = irq-start;
+   dev-irq = irq;
 
platform_set_drvdata(pdev, dev);
init_completion(dev-cmd_complete);
-- 
1.7.5.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


[PATCHv8 15/22] i2c: omap: simplify IRQ exit path

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

instead of having multiple return points, use
a goto statement to make that clearer.

Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   20 
 1 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 96fd528..4af123f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -853,24 +853,21 @@ omap_i2c_isr(int this_irq, void *dev_id)
dev_dbg(dev-dev, IRQ (ISR = 0x%04x)\n, stat);
if (count++ == 100) {
dev_warn(dev-dev, Too much work in one IRQ\n);
-   omap_i2c_complete_cmd(dev, err);
-   return IRQ_HANDLED;
+   goto out;
}
 
 complete:
if (stat  OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
-   omap_i2c_complete_cmd(dev, err);
-   return IRQ_HANDLED;
+   goto out;
}
 
if (stat  OMAP_I2C_STAT_AL) {
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
-   omap_i2c_complete_cmd(dev, err);
-   return IRQ_HANDLED;
+   goto out;
}
 
/*
@@ -883,8 +880,7 @@ complete:
OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR |
OMAP_I2C_STAT_ARDY));
-   omap_i2c_complete_cmd(dev, err);
-   return IRQ_HANDLED;
+   goto out;
}
 
if (stat  OMAP_I2C_STAT_RDR) {
@@ -949,19 +945,19 @@ complete:
dev_err(dev-dev, Receive overrun\n);
err |= OMAP_I2C_STAT_ROVR;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ROVR);
-   omap_i2c_complete_cmd(dev, err);
-   return IRQ_HANDLED;
+   goto out;
}
 
if (stat  OMAP_I2C_STAT_XUDF) {
dev_err(dev-dev, Transmit underflow\n);
err |= OMAP_I2C_STAT_XUDF;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF);
-   omap_i2c_complete_cmd(dev, err);
-   return IRQ_HANDLED;
+   goto out;
}
} while (stat);
 
+out:
+   omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
 }
 
-- 
1.7.5.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


[PATCHv8 02/22] i2c: omap: simplify num_bytes handling

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

trivial patch, no functional changes

If the fifo is disabled or fifo_size is 0 the num_bytes
is set to 1. Else it is set to fifo_size or in case of a
draining interrupt the remaining bytes in the buff stat.
So the zero check is redundant and can be safely optimised.

Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 2d9b03c..236cb38 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -812,8 +812,7 @@ complete:
OMAP_I2C_BUFSTAT_REG)
 8)  0x3F;
}
-   while (num_bytes) {
-   num_bytes--;
+   while (num_bytes--) {
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
if (dev-buf_len) {
*dev-buf++ = w;
@@ -855,8 +854,7 @@ complete:
OMAP_I2C_BUFSTAT_REG)
 0x3F;
}
-   while (num_bytes) {
-   num_bytes--;
+   while (num_bytes--) {
w = 0;
if (dev-buf_len) {
w = *dev-buf++;
-- 
1.7.5.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


[PATCHv8 05/22] i2c: omap: simplify omap_i2c_ack_stat()

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

stat  BIT(1) is the same as BIT(1), so let's
simplify things a bit by removing stat  from
all omap_i2c_ack_stat() calls.

Code snippet (extremely simplified):

if (stat  NACK) {
...
omap_i2c_ack_stat(dev, stat  NACK);
}

if (stat  RDR) {
...
omap_i2c_ack_stat(dev, stat  RDR);
}

and so on. The tricky place is only WRT errata handling, for example:

if (*stat  (NACK | AL)) {
omap_i2c_ack_stat(dev, *stat  (XRDY | XDR));
...
}

but in this case, the errata says we must clear XRDY and XDR if that
errata triggers, so if they just got enabled or not, it doesn't matter.

Another tricky place is RDR | RRDY (likewise for XDR | XRDY):

if (stat  (RDR | RRDY)) {
...
omap_i2c_ack_stat(dev, stat  (RDR | RRDY));
}

again here there will be no issues because those IRQs never fire
simultaneously and one will only after after we have handled the
previous, that's because the same FIFO is used anyway and we won't shift
data into FIFO until we tell the IP hey, I'm done with the FIFO, you
can shift more data

Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
[Added the explaination from the discurssion to the commit logs]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   19 ++-
 1 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 30ea63c..f24eae9 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -731,7 +731,7 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev, u16 
*stat, int *err)
 
while (--timeout  !(*stat  OMAP_I2C_STAT_XUDF)) {
if (*stat  (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
-   omap_i2c_ack_stat(dev, *stat  (OMAP_I2C_STAT_XRDY |
+   omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
return -ETIMEDOUT;
}
@@ -792,10 +792,11 @@ complete:
 */
if (stat  (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
OMAP_I2C_STAT_AL)) {
-   omap_i2c_ack_stat(dev, stat 
-   (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
-   OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR |
-   OMAP_I2C_STAT_ARDY));
+   omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+   OMAP_I2C_STAT_RDR |
+   OMAP_I2C_STAT_XRDY |
+   OMAP_I2C_STAT_XDR |
+   OMAP_I2C_STAT_ARDY));
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
@@ -842,8 +843,8 @@ complete:
}
}
}
-   omap_i2c_ack_stat(dev,
-   stat  (OMAP_I2C_STAT_RRDY | 
OMAP_I2C_STAT_RDR));
+   omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+   OMAP_I2C_STAT_RDR));
continue;
}
 
@@ -890,8 +891,8 @@ complete:
 
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
-   omap_i2c_ack_stat(dev,
-   stat  (OMAP_I2C_STAT_XRDY | 
OMAP_I2C_STAT_XDR));
+   omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
+   OMAP_I2C_STAT_XDR));
continue;
}
 
-- 
1.7.5.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


[PATCHv8 03/22] i2c: omap: decrease indentation level on data handling

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

The patch intends to decrease the indentation level on the
data handling
by using the fact that else of if (dev-buf_len) is same as
if (!dev-buf_len)

if (dev-buf_len) {
aaa;
} else {
bbb;
break;
}

to

if (!dev-buf_len) {
bbb;
break;
}
aaa;

Hence no functional changes.

Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   63 -
 1 files changed, 31 insertions(+), 32 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 236cb38..0dd647a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -813,22 +813,7 @@ complete:
 8)  0x3F;
}
while (num_bytes--) {
-   w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
-   if (dev-buf_len) {
-   *dev-buf++ = w;
-   dev-buf_len--;
-   /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
-   if (dev-flags 
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
-   if (dev-buf_len) {
-   *dev-buf++ = w  8;
-   dev-buf_len--;
-   }
-   }
-   } else {
+   if (!dev-buf_len) {
if (stat  OMAP_I2C_STAT_RRDY)
dev_err(dev-dev,
RRDY IRQ while no data
@@ -839,6 +824,21 @@ complete:
 requested\n);
break;
}
+
+   w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+   *dev-buf++ = w;
+   dev-buf_len--;
+   /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+   if (dev-flags 
+   OMAP_I2C_FLAG_16BIT_DATA_REG) {
+   if (dev-buf_len) {
+   *dev-buf++ = w  8;
+   dev-buf_len--;
+   }
+   }
}
omap_i2c_ack_stat(dev,
stat  (OMAP_I2C_STAT_RRDY | 
OMAP_I2C_STAT_RDR));
@@ -855,22 +855,7 @@ complete:
 0x3F;
}
while (num_bytes--) {
-   w = 0;
-   if (dev-buf_len) {
-   w = *dev-buf++;
-   dev-buf_len--;
-   /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
-   if (dev-flags 
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
-   if (dev-buf_len) {
-   w |= *dev-buf++  8;
-   dev-buf_len--;
-   }
-   }
-   } else {
+   if (!dev-buf_len) {
if (stat  OMAP_I2C_STAT_XRDY)
dev_err(dev-dev,
XRDY IRQ while no 
@@ -882,6 +867,20 @@ complete:
break;
}
 
+   w = *dev-buf++;
+   dev-buf_len--;
+   /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+

[PATCHv8 17/22] i2c: omap: get rid of the complete label

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

we can ack stat and complete the command from
the errata handling itself.

Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   16 +---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f33bc5a..5d4bad4 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -775,6 +775,17 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev)
if (stat  (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
+   if (stat  OMAP_I2C_STAT_NACK) {
+   dev-cmd_err |= OMAP_I2C_STAT_NACK;
+   omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+   }
+
+   if (stat  OMAP_I2C_STAT_AL) {
+   dev_err(dev-dev, Arbitration lost\n);
+   dev-cmd_err |= OMAP_I2C_STAT_AL;
+   omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+   }
+
return -EIO;
}
 
@@ -875,7 +886,6 @@ omap_i2c_isr(int this_irq, void *dev_id)
goto out;
}
 
-complete:
if (stat  OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
@@ -938,7 +948,7 @@ complete:
ret = omap_i2c_transmit_data(dev, num_bytes, true);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
if (ret  0)
-   goto complete;
+   goto out;
 
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XDR);
continue;
@@ -954,7 +964,7 @@ complete:
ret = omap_i2c_transmit_data(dev, num_bytes, false);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
if (ret  0)
-   goto complete;
+   goto out;
 
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XRDY);
continue;
-- 
1.7.5.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


[PATCHv8 07/22] i2c: omap: improve i462 errata handling

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

Make it not depend on ISR's local variables
in order to make it easier to re-factor the
transmit data loop.
Also since we are waiting for XUDF(Transmitter underflow) just before
writing data lets not flag the underflow.
This is anyways going to go once we write
the data.

Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   43 
 1 files changed, 30 insertions(+), 13 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 815577b..fb57221 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -725,27 +725,30 @@ omap_i2c_omap1_isr(int this_irq, void *dev_id)
  * data to DATA_REG. Otherwise some data bytes can be lost while transferring
  * them from the memory to the I2C interface.
  */
-static int errata_omap3_i462(struct omap_i2c_dev *dev, u16 *stat, int *err)
+static int errata_omap3_i462(struct omap_i2c_dev *dev)
 {
unsigned long timeout = 1;
+   u16 stat;
 
-   while (--timeout  !(*stat  OMAP_I2C_STAT_XUDF)) {
-   if (*stat  (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
+   do {
+   stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+   if (stat  OMAP_I2C_STAT_XUDF)
+   break;
+
+   if (stat  (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
-   return -ETIMEDOUT;
+   return -EIO;
}
 
cpu_relax();
-   *stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
-   }
+   } while (--timeout);
 
if (!timeout) {
dev_err(dev-dev, timeout waiting on XUDF bit\n);
return 0;
}
 
-   *err |= OMAP_I2C_STAT_XUDF;
return 0;
 }
 
@@ -903,9 +906,16 @@ complete:
}
}
 
-   if ((dev-errata  I2C_OMAP_ERRATA_I462) 
-   errata_omap3_i462(dev, stat, err))
-   goto complete;
+   if (dev-errata  I2C_OMAP_ERRATA_I462) {
+   int ret;
+
+   ret = errata_omap3_i462(dev);
+   stat = omap_i2c_read_reg(dev,
+   OMAP_I2C_STAT_REG);
+
+   if (ret  0)
+   goto complete;
+   }
 
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
@@ -943,9 +953,16 @@ complete:
}
}
 
-   if ((dev-errata  I2C_OMAP_ERRATA_I462) 
-   errata_omap3_i462(dev, stat, err))
-   goto complete;
+   if (dev-errata  I2C_OMAP_ERRATA_I462) {
+   int ret;
+
+   ret = errata_omap3_i462(dev);
+   stat = omap_i2c_read_reg(dev,
+   OMAP_I2C_STAT_REG);
+
+   if (ret  0)
+   goto complete;
+   }
 
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
-- 
1.7.5.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


[PATCHv8 01/22] i2c: omap: switch to devm_* API

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

that helps deleting some boiler plate code
and lets driver-core manage our resources
for us.

Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   41 -
 1 files changed, 12 insertions(+), 29 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5d19a49..2d9b03c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -943,7 +943,7 @@ omap_i2c_probe(struct platform_device *pdev)
 {
struct omap_i2c_dev *dev;
struct i2c_adapter  *adap;
-   struct resource *mem, *irq, *ioarea;
+   struct resource *mem, *irq;
struct omap_i2c_bus_platform_data *pdata = pdev-dev.platform_data;
struct device_node  *node = pdev-dev.of_node;
const struct of_device_id *match;
@@ -962,17 +962,16 @@ omap_i2c_probe(struct platform_device *pdev)
return -ENODEV;
}
 
-   ioarea = request_mem_region(mem-start, resource_size(mem),
-   pdev-name);
-   if (!ioarea) {
-   dev_err(pdev-dev, I2C region already claimed\n);
-   return -EBUSY;
+   dev = devm_kzalloc(pdev-dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
+   if (!dev) {
+   dev_err(pdev-dev, Menory allocation failed\n);
+   return -ENOMEM;
}
 
-   dev = kzalloc(sizeof(struct omap_i2c_dev), GFP_KERNEL);
-   if (!dev) {
-   r = -ENOMEM;
-   goto err_release_region;
+   dev-base = devm_request_and_ioremap(pdev-dev, mem);
+   if (!dev-base) {
+   dev_err(pdev-dev, I2C region already claimed\n);
+   return -ENOMEM;
}
 
match = of_match_device(of_match_ptr(omap_i2c_of_match), pdev-dev);
@@ -995,11 +994,6 @@ omap_i2c_probe(struct platform_device *pdev)
 
dev-dev = pdev-dev;
dev-irq = irq-start;
-   dev-base = ioremap(mem-start, resource_size(mem));
-   if (!dev-base) {
-   r = -ENOMEM;
-   goto err_free_mem;
-   }
 
platform_set_drvdata(pdev, dev);
init_completion(dev-cmd_complete);
@@ -1057,7 +1051,8 @@ omap_i2c_probe(struct platform_device *pdev)
 
isr = (dev-rev  OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr :
   omap_i2c_isr;
-   r = request_irq(dev-irq, isr, IRQF_NO_SUSPEND, pdev-name, dev);
+   r = devm_request_irq(pdev-dev, dev-irq, isr, IRQF_NO_SUSPEND,
+pdev-name, dev);
 
if (r) {
dev_err(dev-dev, failure requesting irq %i\n, dev-irq);
@@ -1081,7 +1076,7 @@ omap_i2c_probe(struct platform_device *pdev)
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev-dev, failure adding adapter\n);
-   goto err_free_irq;
+   goto err_unuse_clocks;
}
 
of_i2c_register_devices(adap);
@@ -1090,18 +1085,12 @@ omap_i2c_probe(struct platform_device *pdev)
 
return 0;
 
-err_free_irq:
-   free_irq(dev-irq, dev);
 err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
-   iounmap(dev-base);
pm_runtime_disable(pdev-dev);
 err_free_mem:
platform_set_drvdata(pdev, NULL);
-   kfree(dev);
-err_release_region:
-   release_mem_region(mem-start, resource_size(mem));
 
return r;
 }
@@ -1109,12 +1098,10 @@ err_release_region:
 static int __devexit omap_i2c_remove(struct platform_device *pdev)
 {
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
-   struct resource *mem;
int ret;
 
platform_set_drvdata(pdev, NULL);
 
-   free_irq(dev-irq, dev);
i2c_del_adapter(dev-adapter);
ret = pm_runtime_get_sync(pdev-dev);
if (IS_ERR_VALUE(ret))
@@ -1123,10 +1110,6 @@ static int __devexit omap_i2c_remove(struct 
platform_device *pdev)
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
-   iounmap(dev-base);
-   kfree(dev);
-   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   release_mem_region(mem-start, resource_size(mem));
return 0;
 }
 
-- 
1.7.5.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


[PATCHv8 04/22] i2c: omap: add blank lines

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

trivial patch to aid readability. No functional
changes.

Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0dd647a..30ea63c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -786,6 +786,7 @@ complete:
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
}
+
/*
 * ProDB0017052: Clear ARDY bit twice
 */
@@ -798,6 +799,7 @@ complete:
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
+
if (stat  (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
u8 num_bytes = 1;
 
@@ -844,6 +846,7 @@ complete:
stat  (OMAP_I2C_STAT_RRDY | 
OMAP_I2C_STAT_RDR));
continue;
}
+
if (stat  (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR)) {
u8 num_bytes = 1;
if (dev-fifo_size) {
@@ -891,10 +894,12 @@ complete:
stat  (OMAP_I2C_STAT_XRDY | 
OMAP_I2C_STAT_XDR));
continue;
}
+
if (stat  OMAP_I2C_STAT_ROVR) {
dev_err(dev-dev, Receive overrun\n);
dev-cmd_err |= OMAP_I2C_STAT_ROVR;
}
+
if (stat  OMAP_I2C_STAT_XUDF) {
dev_err(dev-dev, Transmit underflow\n);
dev-cmd_err |= OMAP_I2C_STAT_XUDF;
-- 
1.7.5.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


[PATCHv8 18/22] i2c: omap: remove redundant status read

2012-09-12 Thread Shubhrajyoti D
Currently omap_i2c_ack_stat doesn't use the stat variable.
After the read of the I2C_STAT_REG it is not used.
Remove the redundant read of the status register.

Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5d4bad4..498a462 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -946,7 +946,6 @@ omap_i2c_isr(int this_irq, void *dev_id)
num_bytes = dev-buf_len;
 
ret = omap_i2c_transmit_data(dev, num_bytes, true);
-   stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
if (ret  0)
goto out;
 
@@ -962,7 +961,6 @@ omap_i2c_isr(int this_irq, void *dev_id)
num_bytes = dev-threshold;
 
ret = omap_i2c_transmit_data(dev, num_bytes, false);
-   stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
if (ret  0)
goto out;
 
-- 
1.7.5.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


[PATCHv8 06/22] i2c: omap: split out [XR]DR and [XR]RDY

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

While they do pretty much the same thing, there
are a few peculiarities. Specially WRT erratas,
it's best to split those out and re-factor the
read/write loop to another function which both
cases call.

This last part will be done on another patch.

While at that, also avoid an unncessary register
read since dev-fifo_len will always contain the
correct amount of data to be transferred.

Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |  126 ++---
 1 files changed, 92 insertions(+), 34 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f24eae9..815577b 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -801,36 +801,62 @@ complete:
return IRQ_HANDLED;
}
 
-   if (stat  (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
+   if (stat  OMAP_I2C_STAT_RDR) {
u8 num_bytes = 1;
 
+   if (dev-fifo_size)
+   num_bytes = dev-buf_len;
+
+   while (num_bytes--) {
+   if (!dev-buf_len) {
+   dev_err(dev-dev,
+   RDR IRQ while no data
+requested\n);
+   break;
+   }
+
+   w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+   *dev-buf++ = w;
+   dev-buf_len--;
+
+   /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+   if (dev-flags 
+   OMAP_I2C_FLAG_16BIT_DATA_REG) {
+   if (dev-buf_len) {
+   *dev-buf++ = w  8;
+   dev-buf_len--;
+   }
+   }
+   }
+
if (dev-errata  I2C_OMAP_ERRATA_I207)
i2c_omap_errata_i207(dev, stat);
 
-   if (dev-fifo_size) {
-   if (stat  OMAP_I2C_STAT_RRDY)
-   num_bytes = dev-fifo_size;
-   else/* read RXSTAT on RDR interrupt */
-   num_bytes = (omap_i2c_read_reg(dev,
-   OMAP_I2C_BUFSTAT_REG)
-8)  0x3F;
-   }
+   omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
+   continue;
+   }
+
+   if (stat  OMAP_I2C_STAT_RRDY) {
+   u8 num_bytes = 1;
+
+   if (dev-fifo_size)
+   num_bytes = dev-fifo_size;
+
while (num_bytes--) {
if (!dev-buf_len) {
-   if (stat  OMAP_I2C_STAT_RRDY)
-   dev_err(dev-dev,
+   dev_err(dev-dev,
RRDY IRQ while no data
-requested\n);
-   if (stat  OMAP_I2C_STAT_RDR)
-   dev_err(dev-dev,
-   RDR IRQ while no data
-requested\n);
+requested\n);
break;
}
 
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
*dev-buf++ = w;
dev-buf_len--;
+
/*
 * Data reg in 2430, omap3 and
 * omap4 is 8 bit wide
@@ -843,36 +869,68 @@ complete:
}
}
}
-   omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
-   OMAP_I2C_STAT_RDR));
+
+   omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RRDY);
continue;
}
 
-   if (stat  (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR)) {
+ 

[PATCHv8 10/22] i2c: omap: ack IRQ in parts

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

According to flow diagrams on OMAP TRMs,
we should ACK the IRQ as they happen.

Signed-off-by: Felipe Balbi ba...@ti.com
[Ack the stat OMAP_I2C_STAT_AL in case of arbitration lost]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   28 
 1 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4045134..bac1f11 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -850,21 +850,19 @@ omap_i2c_isr(int this_irq, void *dev_id)
}
 
 complete:
-   /*
-* Ack the stat in one go, but [R/X]DR and [R/X]RDY should be
-* acked after the data operation is complete.
-* Ref: TRM SWPU114Q Figure 18-31
-*/
-   omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat 
-   ~(OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
-   OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
-
-   if (stat  OMAP_I2C_STAT_NACK)
+   if (stat  OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
+   omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+   omap_i2c_complete_cmd(dev, err);
+   return IRQ_HANDLED;
+   }
 
if (stat  OMAP_I2C_STAT_AL) {
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
+   omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
+   omap_i2c_complete_cmd(dev, err);
+   return IRQ_HANDLED;
}
 
/*
@@ -941,12 +939,18 @@ complete:
 
if (stat  OMAP_I2C_STAT_ROVR) {
dev_err(dev-dev, Receive overrun\n);
-   dev-cmd_err |= OMAP_I2C_STAT_ROVR;
+   err |= OMAP_I2C_STAT_ROVR;
+   omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ROVR);
+   omap_i2c_complete_cmd(dev, err);
+   return IRQ_HANDLED;
}
 
if (stat  OMAP_I2C_STAT_XUDF) {
dev_err(dev-dev, Transmit underflow\n);
-   dev-cmd_err |= OMAP_I2C_STAT_XUDF;
+   err |= OMAP_I2C_STAT_XUDF;
+   omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF);
+   omap_i2c_complete_cmd(dev, err);
+   return IRQ_HANDLED;
}
} while (stat);
 
-- 
1.7.5.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


[PATCHv8 00/23]I2C big cleanup

2012-09-12 Thread Shubhrajyoti D
Changes since v1:
   - removed tabification on patch 6/17
   - removed dev_err() which was introduced on patch 09/17
Changes since v2:
- do not set full fifo depth in the RDR interrupt.
- some changelog updates.
- rebase to the Wolfram's tree.
Changes since v3:
- Remove a redundant read of status register
- Read the dev-buf_len variable instead of the register
as the information of the remaining bytes is there.
Changes since v4:
- Ack the arbitration lost.
- Rebase to the i2c-embedded/for-next branch.
Changes since v5:
- Rebase to latest mainline
- Added some more cleanup patches so as have a consolidated series.
Changes since v6:
- Fix comments on setting the pdev to NULL.
- Trivial changelog update
Changes since v7:
- Remove a patch as the code is getting changed anyways
- Changelogs update.

Previous discussions can be found here 
http://www.spinics.net/lists/linux-i2c/msg09764.html

This is the cleanup only series.
  
Tested on omap4sdp and 3430sdp.

The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:

  Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)

are available in the git repository at:
  git://gitorious.org/linus-tree/linus-tree.git for_3.7/i2c/big_cleanups


Felipe Balbi (22):
  i2c: omap: switch to devm_* API
  i2c: omap: simplify num_bytes handling
  i2c: omap: decrease indentation level on data handling
  i2c: omap: add blank lines
  i2c: omap: simplify omap_i2c_ack_stat()
  i2c: omap: split out [XR]DR and [XR]RDY
  i2c: omap: improve i462 errata handling
  i2c: omap: re-factor receive/transmit data loop
  i2c: omap: switch over to do {} while loop
  i2c: omap: ack IRQ in parts
  i2c: omap: switch to platform_get_irq()
  i2c: omap: bus: add a receiver flag
  i2c: omap: simplify errata check
  i2c: omap: always return IRQ_HANDLED
  i2c: omap: simplify IRQ exit path
  i2c: omap: resize fifos before each message
  i2c: omap: get rid of the complete label
  i2c: omap: always return IRQ_HANDLED
  i2c: omap: switch to threaded IRQ support
  i2c: omap: remove unnecessary pm_runtime_suspended check
  i2c: omap: switch over to autosuspend API
  i2c: omap: sanitize exit path

Shubhrajyoti D (1):
  i2c: omap: remove redundant status read

 drivers/i2c/busses/i2c-omap.c |  442 +
 1 files changed, 271 insertions(+), 171 deletions(-)

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


[PATCHv8 20/22] i2c: omap: remove unnecessary pm_runtime_suspended check

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

before starting any messages we call pm_runtime_get_sync()
which will make sure that by the time we program a transfer
and our IRQ handler gets called, we're not suspended
anymore.

Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 049331c..6d38a57 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -883,9 +883,6 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
u16 stat;
int err = 0, count = 0;
 
-   if (pm_runtime_suspended(dev-dev))
-   return IRQ_NONE;
-
spin_lock_irqsave(dev-lock, flags);
do {
bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
-- 
1.7.5.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


[PATCHv8 21/22] i2c: omap: switch over to autosuspend API

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

this helps us reduce unnecessary pm transitions
in case we have another i2c message starting soon.

Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6d38a57..122f517 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -55,6 +55,9 @@
 /* timeout waiting for the controller to respond */
 #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
 
+/* timeout for pm runtime autosuspend */
+#define OMAP_I2C_PM_TIMEOUT1000/* ms */
+
 /* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
 enum {
OMAP_I2C_REV_REG = 0,
@@ -645,7 +648,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg 
msgs[], int num)
 
omap_i2c_wait_for_bb(dev);
 out:
-   pm_runtime_put(dev-dev);
+   pm_runtime_mark_last_busy(dev-dev);
+   pm_runtime_put_autosuspend(dev-dev);
return r;
 }
 
@@ -1113,6 +1117,9 @@ omap_i2c_probe(struct platform_device *pdev)
dev-regs = (u8 *)reg_map_ip_v1;
 
pm_runtime_enable(dev-dev);
+   pm_runtime_set_autosuspend_delay(dev-dev, OMAP_I2C_PM_TIMEOUT);
+   pm_runtime_use_autosuspend(dev-dev);
+
r = pm_runtime_get_sync(dev-dev);
if (IS_ERR_VALUE(r))
goto err_free_mem;
@@ -1190,7 +1197,8 @@ omap_i2c_probe(struct platform_device *pdev)
 
of_i2c_register_devices(adap);
 
-   pm_runtime_put(dev-dev);
+   pm_runtime_mark_last_busy(dev-dev);
+   pm_runtime_put_autosuspend(dev-dev);
 
return 0;
 
-- 
1.7.5.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


[PATCHv8 16/22] i2c: omap: resize fifos before each message

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

This patch will try to avoid the usage of
draining feature by reconfiguring the FIFO
the start condition of each message based
on the message's size.

By doing that, we will be better utilizing
the FIFO when doing big transfers.

While at that also drop the now unneeded
check for dev-buf_len as we always know
the amount of data to be transmitted.

Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   83 +
 1 files changed, 51 insertions(+), 32 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4af123f..f33bc5a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -193,6 +193,7 @@ struct omap_i2c_dev {
u8  *regs;
size_t  buf_len;
struct i2c_adapter  adapter;
+   u8  threshold;
u8  fifo_size;  /* use as flag and value
 * fifo_size==0 implies no fifo
 * if set, should be trsh+1
@@ -418,13 +419,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
 
-   if (dev-fifo_size) {
-   /* Note: setup required fifo size - 1. RTRSH and XTRSH */
-   buf = (dev-fifo_size - 1)  8 | OMAP_I2C_BUF_RXFIF_CLR |
-   (dev-fifo_size - 1) | OMAP_I2C_BUF_TXFIF_CLR;
-   omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
-   }
-
/* Take the I2C module out of reset: */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
 
@@ -462,6 +456,45 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
return 0;
 }
 
+static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev, u8 size, bool is_rx)
+{
+   u16 buf;
+
+   if (dev-flags  OMAP_I2C_FLAG_NO_FIFO)
+   return;
+
+   /*
+* Set up notification threshold based on message size. We're doing
+* this to try and avoid draining feature as much as possible. Whenever
+* we have big messages to transfer (bigger than our total fifo size)
+* then we might use draining feature to transfer the remaining bytes.
+*/
+
+   dev-threshold = clamp(size, (u8) 1, dev-fifo_size);
+
+   buf = omap_i2c_read_reg(dev, OMAP_I2C_BUF_REG);
+
+   if (is_rx) {
+   /* Clear RX Threshold */
+   buf = ~(0x3f  8);
+   buf |= ((dev-threshold - 1)  8) | OMAP_I2C_BUF_RXFIF_CLR;
+   } else {
+   /* Clear TX Threshold */
+   buf = ~0x3f;
+   buf |= (dev-threshold - 1) | OMAP_I2C_BUF_TXFIF_CLR;
+   }
+
+   omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
+
+   if (dev-rev  OMAP_I2C_REV_ON_3630_4430)
+   dev-b_hw = 1; /* Enable hardware fixes */
+
+   /* calculate wakeup latency constraint for MPU */
+   if (dev-set_mpu_wkup_lat != NULL)
+   dev-latency = (100 * dev-threshold) /
+   (1000 * dev-speed / 8);
+}
+
 /*
  * Low level master read/write transaction.
  */
@@ -478,6 +511,9 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (msg-len == 0)
return -EINVAL;
 
+   dev-receiver = !!(msg-flags  I2C_M_RD);
+   omap_i2c_resize_fifo(dev, msg-len, dev-receiver);
+
omap_i2c_write_reg(dev, OMAP_I2C_SA_REG, msg-addr);
 
/* REVISIT: Could the STB bit of I2C_CON be used with probing? */
@@ -493,7 +529,6 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
 
INIT_COMPLETION(dev-cmd_complete);
dev-cmd_err = 0;
-   dev-receiver = !!(msg-flags  I2C_M_RD);
 
w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT;
 
@@ -760,12 +795,6 @@ static void omap_i2c_receive_data(struct omap_i2c_dev 
*dev, u8 num_bytes,
u16 w;
 
while (num_bytes--) {
-   if (!dev-buf_len) {
-   dev_err(dev-dev, %s without data,
-   is_rdr ? RDR : RRDY);
-   break;
-   }
-
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
*dev-buf++ = w;
dev-buf_len--;
@@ -775,10 +804,8 @@ static void omap_i2c_receive_data(struct omap_i2c_dev 
*dev, u8 num_bytes,
 * omap4 is 8 bit wide
 */
if (dev-flags  OMAP_I2C_FLAG_16BIT_DATA_REG) {
-   if (dev-buf_len) {
-   *dev-buf++ = w  8;
-   dev-buf_len--;
-   }
+   *dev-buf++ = w  8;
+   dev-buf_len--;
}
}
 }

[PATCHv8 13/22] i2c: omap: simplify errata check

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

omap_i2c_dev is allocated with kzalloc(),
so we need not initialize b_hw to zero.

Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 3be147a..7918e48 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1095,9 +1095,7 @@ omap_i2c_probe(struct platform_device *pdev)
 
dev-fifo_size = (dev-fifo_size / 2);
 
-   if (dev-rev = OMAP_I2C_REV_ON_3630_4430)
-   dev-b_hw = 0; /* Disable hardware fixes */
-   else
+   if (dev-rev  OMAP_I2C_REV_ON_3630_4430)
dev-b_hw = 1; /* Enable hardware fixes */
 
/* calculate wakeup latency constraint for MPU */
-- 
1.7.5.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


[PATCHv8 12/22] i2c: omap: bus: add a receiver flag

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

that way we can ignore TX IRQs while in receiver
mode and ignore RX IRQs while in transmitter mode.

Signed-off-by: Felipe Balbi ba...@ti.com
[Remove unnecessary braces]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0da8169..3be147a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -199,6 +199,7 @@ struct omap_i2c_dev {
 */
u8  rev;
unsignedb_hw:1; /* bad h/w fixes */
+   unsignedreceiver:1; /* true when we're in receiver 
mode */
u16 iestate;/* Saved interrupt register */
u16 pscstate;
u16 scllstate;
@@ -492,6 +493,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
 
INIT_COMPLETION(dev-cmd_complete);
dev-cmd_err = 0;
+   dev-receiver = !!(msg-flags  I2C_M_RD);
 
w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT;
 
@@ -837,6 +839,12 @@ omap_i2c_isr(int this_irq, void *dev_id)
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
stat = bits;
 
+   /* If we're in receiver mode, ignore XDR/XRDY */
+   if (dev-receiver)
+   stat = ~(OMAP_I2C_STAT_XDR | OMAP_I2C_STAT_XRDY);
+   else
+   stat = ~(OMAP_I2C_STAT_RDR | OMAP_I2C_STAT_RRDY);
+
if (!stat) {
/* my work here is done */
return IRQ_HANDLED;
-- 
1.7.5.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


[PATCHv8 14/22] i2c: omap: always return IRQ_HANDLED

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

Always return IRQ_HANDLED otherwise we could get our IRQ line disabled due
to many spurious IRQs.

Signed-off-by: Felipe Balbi ba...@ti.com
[Trivial changes to commitlogs]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 7918e48..96fd528 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -962,7 +962,7 @@ complete:
}
} while (stat);
 
-   return count ? IRQ_HANDLED : IRQ_NONE;
+   return IRQ_HANDLED;
 }
 
 static const struct i2c_algorithm omap_i2c_algo = {
-- 
1.7.5.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


[PATCHv8 19/22] i2c: omap: switch to threaded IRQ support

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

for OMAP2, we can easily switch over to threaded
IRQs on the I2C driver. This will allow us to
spend less time in hardirq context.

Signed-off-by: Felipe Balbi ba...@ti.com
[Trivial formating changes]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   43 +++-
 1 files changed, 37 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 498a462..049331c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -176,6 +176,7 @@ enum {
 #define I2C_OMAP_ERRATA_I462   (1  1)
 
 struct omap_i2c_dev {
+   spinlock_t  lock;   /* IRQ synchronization */
struct device   *dev;
void __iomem*base;  /* virtual */
int irq;
@@ -854,9 +855,30 @@ static int omap_i2c_transmit_data(struct omap_i2c_dev 
*dev, u8 num_bytes,
 }
 
 static irqreturn_t
-omap_i2c_isr(int this_irq, void *dev_id)
+omap_i2c_isr(int irq, void *dev_id)
 {
struct omap_i2c_dev *dev = dev_id;
+   irqreturn_t ret = IRQ_HANDLED;
+   u16 mask;
+   u16 stat;
+
+   spin_lock(dev-lock);
+   mask = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
+   stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+
+   if (stat  mask)
+   ret = IRQ_WAKE_THREAD;
+
+   spin_unlock(dev-lock);
+
+   return ret;
+}
+
+static irqreturn_t
+omap_i2c_isr_thread(int this_irq, void *dev_id)
+{
+   struct omap_i2c_dev *dev = dev_id;
+   unsigned long flags;
u16 bits;
u16 stat;
int err = 0, count = 0;
@@ -864,6 +886,7 @@ omap_i2c_isr(int this_irq, void *dev_id)
if (pm_runtime_suspended(dev-dev))
return IRQ_NONE;
 
+   spin_lock_irqsave(dev-lock, flags);
do {
bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
@@ -877,6 +900,7 @@ omap_i2c_isr(int this_irq, void *dev_id)
 
if (!stat) {
/* my work here is done */
+   spin_unlock_irqrestore(dev-lock, flags);
return IRQ_HANDLED;
}
 
@@ -985,6 +1009,8 @@ omap_i2c_isr(int this_irq, void *dev_id)
 
 out:
omap_i2c_complete_cmd(dev, err);
+   spin_unlock_irqrestore(dev-lock, flags);
+
return IRQ_HANDLED;
 }
 
@@ -1028,7 +1054,6 @@ omap_i2c_probe(struct platform_device *pdev)
struct omap_i2c_bus_platform_data *pdata = pdev-dev.platform_data;
struct device_node  *node = pdev-dev.of_node;
const struct of_device_id *match;
-   irq_handler_t isr;
int irq;
int r;
 
@@ -1078,6 +1103,8 @@ omap_i2c_probe(struct platform_device *pdev)
dev-dev = pdev-dev;
dev-irq = irq;
 
+   spin_lock_init(dev-lock);
+
platform_set_drvdata(pdev, dev);
init_completion(dev-cmd_complete);
 
@@ -1130,10 +1157,14 @@ omap_i2c_probe(struct platform_device *pdev)
/* reset ASAP, clearing any IRQs */
omap_i2c_init(dev);
 
-   isr = (dev-rev  OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr :
-  omap_i2c_isr;
-   r = devm_request_irq(pdev-dev, dev-irq, isr, IRQF_NO_SUSPEND,
-pdev-name, dev);
+   if (dev-rev  OMAP_I2C_OMAP1_REV_2)
+   r = devm_request_irq(pdev-dev, dev-irq, omap_i2c_omap1_isr,
+   IRQF_NO_SUSPEND, pdev-name, dev);
+   else
+   r = devm_request_threaded_irq(pdev-dev, dev-irq,
+   omap_i2c_isr, omap_i2c_isr_thread,
+   IRQF_NO_SUSPEND | IRQF_ONESHOT,
+   pdev-name, dev);
 
if (r) {
dev_err(dev-dev, failure requesting irq %i\n, dev-irq);
-- 
1.7.5.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


[PATCHv8 08/22] i2c: omap: re-factor receive/transmit data loop

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

re-factor the common parts to a separate function,
so that code is easier to read and understand.

No functional changes.

Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |  204 
 1 files changed, 82 insertions(+), 122 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index fb57221..2c7d7cc 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -752,12 +752,81 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev)
return 0;
 }
 
+static void omap_i2c_receive_data(struct omap_i2c_dev *dev, u8 num_bytes,
+   bool is_rdr)
+{
+   u16 w;
+
+   while (num_bytes--) {
+   if (!dev-buf_len) {
+   dev_err(dev-dev, %s without data,
+   is_rdr ? RDR : RRDY);
+   break;
+   }
+
+   w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+   *dev-buf++ = w;
+   dev-buf_len--;
+
+   /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+   if (dev-flags  OMAP_I2C_FLAG_16BIT_DATA_REG) {
+   if (dev-buf_len) {
+   *dev-buf++ = w  8;
+   dev-buf_len--;
+   }
+   }
+   }
+}
+
+static int omap_i2c_transmit_data(struct omap_i2c_dev *dev, u8 num_bytes,
+   bool is_xdr)
+{
+   u16 w;
+
+   while (num_bytes--) {
+   if (!dev-buf_len) {
+   dev_err(dev-dev, %s without data,
+   is_xdr ? XDR : XRDY);
+   break;
+   }
+
+   w = *dev-buf++;
+   dev-buf_len--;
+
+   /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+   if (dev-flags  OMAP_I2C_FLAG_16BIT_DATA_REG) {
+   if (dev-buf_len) {
+   w |= *dev-buf++  8;
+   dev-buf_len--;
+   }
+   }
+
+   if (dev-errata  I2C_OMAP_ERRATA_I462) {
+   int ret;
+
+   ret = errata_omap3_i462(dev);
+   if (ret  0)
+   return ret;
+   }
+
+   omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
+   }
+
+   return 0;
+}
+
 static irqreturn_t
 omap_i2c_isr(int this_irq, void *dev_id)
 {
struct omap_i2c_dev *dev = dev_id;
u16 bits;
-   u16 stat, w;
+   u16 stat;
int err, count = 0;
 
if (pm_runtime_suspended(dev-dev))
@@ -810,30 +879,7 @@ complete:
if (dev-fifo_size)
num_bytes = dev-buf_len;
 
-   while (num_bytes--) {
-   if (!dev-buf_len) {
-   dev_err(dev-dev,
-   RDR IRQ while no data
-requested\n);
-   break;
-   }
-
-   w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
-   *dev-buf++ = w;
-   dev-buf_len--;
-
-   /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
-   if (dev-flags 
-   OMAP_I2C_FLAG_16BIT_DATA_REG) {
-   if (dev-buf_len) {
-   *dev-buf++ = w  8;
-   dev-buf_len--;
-   }
-   }
-   }
+   omap_i2c_receive_data(dev, num_bytes, true);
 
if (dev-errata  I2C_OMAP_ERRATA_I207)
i2c_omap_errata_i207(dev, stat);
@@ -848,77 +894,22 @@ complete:
if (dev-fifo_size)
num_bytes = dev-fifo_size;
 
-   while (num_bytes--) {
-   if (!dev-buf_len) {
-   dev_err(dev-dev,
-   RRDY IRQ while no data
-requested\n);
-   break;
-   }
-
-

[PATCHv8 22/22] i2c: omap: sanitize exit path

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

move the goto out label one line down, so that
it can be used when stat is read as zero. All
other exits, can be done with a break statement.

While at that, also break out as soon as we
complete draining IRQ, since at that time
we know we transferred everything there was
to be transferred.

Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   26 +-
 1 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 122f517..b149e32 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -901,27 +901,26 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
 
if (!stat) {
/* my work here is done */
-   spin_unlock_irqrestore(dev-lock, flags);
-   return IRQ_HANDLED;
+   goto out;
}
 
dev_dbg(dev-dev, IRQ (ISR = 0x%04x)\n, stat);
if (count++ == 100) {
dev_warn(dev-dev, Too much work in one IRQ\n);
-   goto out;
+   break;
}
 
if (stat  OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
-   goto out;
+   break;
}
 
if (stat  OMAP_I2C_STAT_AL) {
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
-   goto out;
+   break;
}
 
/*
@@ -934,7 +933,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR |
OMAP_I2C_STAT_ARDY));
-   goto out;
+   break;
}
 
if (stat  OMAP_I2C_STAT_RDR) {
@@ -949,7 +948,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
i2c_omap_errata_i207(dev, stat);
 
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
-   continue;
+   break;
}
 
if (stat  OMAP_I2C_STAT_RRDY) {
@@ -972,10 +971,10 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
 
ret = omap_i2c_transmit_data(dev, num_bytes, true);
if (ret  0)
-   goto out;
+   break;
 
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XDR);
-   continue;
+   break;
}
 
if (stat  OMAP_I2C_STAT_XRDY) {
@@ -987,7 +986,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
 
ret = omap_i2c_transmit_data(dev, num_bytes, false);
if (ret  0)
-   goto out;
+   break;
 
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XRDY);
continue;
@@ -997,19 +996,20 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
dev_err(dev-dev, Receive overrun\n);
err |= OMAP_I2C_STAT_ROVR;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ROVR);
-   goto out;
+   break;
}
 
if (stat  OMAP_I2C_STAT_XUDF) {
dev_err(dev-dev, Transmit underflow\n);
err |= OMAP_I2C_STAT_XUDF;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF);
-   goto out;
+   break;
}
} while (stat);
 
-out:
omap_i2c_complete_cmd(dev, err);
+
+out:
spin_unlock_irqrestore(dev-lock, flags);
 
return IRQ_HANDLED;
-- 
1.7.5.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


[PATCHv8 09/22] i2c: omap: switch over to do {} while loop

2012-09-12 Thread Shubhrajyoti D
From: Felipe Balbi ba...@ti.com

this will make sure that we execute at least once.
No functional changes otherwise.

Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   20 ++--
 1 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 2c7d7cc..4045134 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -827,20 +827,28 @@ omap_i2c_isr(int this_irq, void *dev_id)
struct omap_i2c_dev *dev = dev_id;
u16 bits;
u16 stat;
-   int err, count = 0;
+   int err = 0, count = 0;
 
if (pm_runtime_suspended(dev-dev))
return IRQ_NONE;
 
-   bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
-   while ((stat = (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)))  bits) {
+   do {
+   bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
+   stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+   stat = bits;
+
+   if (!stat) {
+   /* my work here is done */
+   return IRQ_HANDLED;
+   }
+
dev_dbg(dev-dev, IRQ (ISR = 0x%04x)\n, stat);
if (count++ == 100) {
dev_warn(dev-dev, Too much work in one IRQ\n);
-   break;
+   omap_i2c_complete_cmd(dev, err);
+   return IRQ_HANDLED;
}
 
-   err = 0;
 complete:
/*
 * Ack the stat in one go, but [R/X]DR and [R/X]RDY should be
@@ -940,7 +948,7 @@ complete:
dev_err(dev-dev, Transmit underflow\n);
dev-cmd_err |= OMAP_I2C_STAT_XUDF;
}
-   }
+   } while (stat);
 
return count ? IRQ_HANDLED : IRQ_NONE;
 }
-- 
1.7.5.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] mmc: omap_hsmmc: Enable HSPE bit for high speed cards

2012-09-12 Thread Hebbar, Gururaja
On Wed, Sep 12, 2012 at 14:51:34, Krishnamoorthy, Balaji T wrote:
 On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja gururaja.heb...@ti.com 
 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.
 
 Is this specific to some boards or all board with TI81xx ?
 What is the side-effect if not done ?

Platforms like (AM335x) needed this bit to be set in order to sustain high
speed transfers. This was concluded after HSMMC IP timing closure was 
completed for High speed Cards. 

This was confirmed on high speed cards with very low setup/hold delay (in the 
order of nsec) was tested. For AM335x, this bit was to be set to meet setup 
requirement and hold requirement for MMC/SD HS cards.

 
 
  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
 
  Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
  ---
  :100644 100644 be76a23... ed271fc... M  
  Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
  :100644 100644 eb3e4d5... 00c658b... M  
  arch/arm/plat-omap/include/plat/mmc.h
  :100644 100644 c3e96a2... 0e14834... M  drivers/mmc/host/omap_hsmmc.c

..snip..
..snip..
..snip..

 
  +   /*
  +* Enable High-Speed Support
  +* Pre-Requisites
  +*  - Controller should support High-Speed-Enable Bit
  +*  - Controller should not be using DDR Mode
  +*  - Controller should advertise that it supports High Speed
  +*in capabilities register
  +*  - MMC/SD clock coming out of controller  25MHz
  +*/
  +   if ((mmc_slot(host).features  HSMMC_HAS_HSPE_SUPPORT) 
  +   (ios-timing != MMC_TIMING_UHS_DDR50) 
  +   ((OMAP_HSMMC_READ(host-base, CAPA)  HSS) == HSS)) {
  +   regval = OMAP_HSMMC_READ(host-base, HCTL);
  +   if (clkdiv  (clk_get_rate(host-fclk)/clkdiv)  2500)
 
 I think clkdiv is not needed
 clk_get_rate(host-fclk)/clkdiv is same as ios-clock

There are chances that the platform is not supporting Clock output from HSMMC
IP greater than 25 MHz even if the card is High Speed. So it would be better 
to check host-fclk than ios-clock. 

Kindly correct me if I am wrong.

 
  +   regval |= HSPE;
  +   else
  +   regval = ~HSPE;
  +
  +   OMAP_HSMMC_WRITE(host-base, HCTL, regval);
  +   }
  +
  omap_hsmmc_start_clock(host);
   }
 
  @@ -1701,6 +1726,9 @@ static struct omap_mmc_platform_data 
  *of_get_hsmmc_pdata(struct device *dev)
  if (of_find_property(np, ti,needs-special-reset, NULL))
  pdata-slots[0].features |= HSMMC_HAS_UPDATED_RESET;
 
  +   if (of_find_property(np, ti,needs-special-hs-handling, NULL))
  +   pdata-slots[0].features |= HSMMC_HAS_HSPE_SUPPORT;
  +
  return pdata;
   }
   #else
  --
  1.7.1
 
  --
  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
 


Regards, 
Gururaja
--
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 00/11] ASoC: OMAP: Convert to use dmaengine

2012-09-12 Thread Peter Ujfalusi
Hello,

This series will switch the OMAP audio to use dmaengine.
The final patch which does the switch was based on Russell King's earlier patch.

The first 10 patch is to prepare the OMAP audio drivers for a smooth change to
dmaengine:
- sDMA FRAME sync mode is removed and replaced with PACKET mode
- dai drivers no longer need to configure sDMA sync mode
- dai drivers does not need to specify the DMA word length - with the exception
  of the omap-hdmi driver which requires 32bit word length regardless of the
  audio format in use
- the McPDM driver used (to my surprise) hackish way of getting the DMA channel
  and address - via defines from some header files

I have tested the series on:
- BeagleBoard (audio via McBSP) with aplay/arecord. In element mode and in
  threshold mode with different period sizes
- OMAP4 Blaze (audio via McPDM and DMIC)

With this conversion the NO_PERIOD_WAKEUP is not supported at the moment. I'll
be looking at the dmaengine core and omap parts to add this feature back.

The patches has been generated against:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-3.7

Janusz: Can you retest this series on OMAP1 to be sure I have not broken it?
Ricardo: Can you test the omap-hmdi if it is still working?

Regards,
Peter
---
Peter Ujfalusi (11):
  dmaengine: omap: Support for element mode in cyclic DMA
  ASoC: omap-mcbsp: Use sDMA packet mode instead of frame mode
  ASoC: omap-pcm: Select sDMA synchronization based on packet_size
  ASoC: OMAP: Remove sync_mode from omap_pcm_dma_data struct
  ASoC: omap-pcm: Prepare to configure the DMA data_type based on
stream properties
  ARM: OMAP4: hwmod_data: Add resource names to McPDM memory ranges
  ASoC: omap-mcpdm: Use platform_get_resource_* to get resources
  ASoC: OMAP: mcbsp, mcpdm, dmic: Let omap-pcm to pick the dma_type
  ASoC: omap-pcm, omap-hdmi: Change the use of
omap_pcm_dma_data-data_type
  ASoC: OMAP: mcbsp, mcpdm, dmic, hdmi: Set dma_data at startup time
  ASoC: omap-pcm: Convert to use dmaengine

 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   2 +
 drivers/dma/omap-dma.c |   5 +-
 sound/soc/omap/Kconfig |   3 +-
 sound/soc/omap/omap-dmic.c |   9 +-
 sound/soc/omap/omap-hdmi.c |  17 +-
 sound/soc/omap/omap-mcbsp.c|  60 +++
 sound/soc/omap/omap-mcpdm.c|  41 +++--
 sound/soc/omap/omap-pcm.c  | 246 -
 sound/soc/omap/omap-pcm.h  |   4 +-
 9 files changed, 136 insertions(+), 251 deletions(-)

-- 
1.7.12

--
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 08/11] ASoC: OMAP: mcbsp, mcpdm, dmic: Let omap-pcm to pick the dma_type

2012-09-12 Thread Peter Ujfalusi
omap-pcm can figure out the correct dma_type based on the stream's format.
In this way we can get rid of the plat/dma.h include from these drivers.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 sound/soc/omap/omap-dmic.c  | 2 --
 sound/soc/omap/omap-mcbsp.c | 3 ---
 sound/soc/omap/omap-mcpdm.c | 3 ---
 3 files changed, 8 deletions(-)

diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index 60b7b8c..df0ff24 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -33,7 +33,6 @@
 #include linux/slab.h
 #include linux/pm_runtime.h
 #include linux/of_device.h
-#include plat/dma.h
 
 #include sound/core.h
 #include sound/pcm.h
@@ -63,7 +62,6 @@ struct omap_dmic {
  */
 static struct omap_pcm_dma_data omap_dmic_dai_dma_params = {
.name   = DMIC capture,
-   .data_type  = OMAP_DMA_DATA_TYPE_S32,
 };
 
 static inline void omap_dmic_write(struct omap_dmic *dmic, u16 reg, u32 val)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 5b3bacc..a230646 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -34,7 +34,6 @@
 #include sound/initval.h
 #include sound/soc.h
 
-#include plat/dma.h
 #include plat/mcbsp.h
 #include mcbsp.h
 #include omap-mcbsp.h
@@ -234,11 +233,9 @@ static int omap_mcbsp_dai_hw_params(struct 
snd_pcm_substream *substream,
 
switch (params_format(params)) {
case SNDRV_PCM_FORMAT_S16_LE:
-   dma_data-data_type = OMAP_DMA_DATA_TYPE_S16;
wlen = 16;
break;
case SNDRV_PCM_FORMAT_S32_LE:
-   dma_data-data_type = OMAP_DMA_DATA_TYPE_S32;
wlen = 32;
break;
default:
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index 36648e0..c1b4935 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -40,7 +40,6 @@
 #include sound/pcm_params.h
 #include sound/soc.h
 
-#include plat/dma.h
 #include omap-mcpdm.h
 #include omap-pcm.h
 
@@ -70,11 +69,9 @@ struct omap_mcpdm {
 static struct omap_pcm_dma_data omap_mcpdm_dai_dma_params[] = {
{
.name = Audio playback,
-   .data_type = OMAP_DMA_DATA_TYPE_S32,
},
{
.name = Audio capture,
-   .data_type = OMAP_DMA_DATA_TYPE_S32,
},
 };
 
-- 
1.7.12

--
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 10/11] ASoC: OMAP: mcbsp, mcpdm, dmic, hdmi: Set dma_data at startup time

2012-09-12 Thread Peter Ujfalusi
Set the dma_data for the stream (snd_soc_dai_set_dma_data) at dai_startup
time so omap-pcm will have access to the needed information regarding to
the DMA channel earlier.
This is needed for the clean dmaengine support.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 sound/soc/omap/omap-dmic.c  |  6 --
 sound/soc/omap/omap-hdmi.c  | 15 +--
 sound/soc/omap/omap-mcbsp.c |  7 ---
 sound/soc/omap/omap-mcpdm.c |  8 
 4 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index df0ff24..68f2cd1 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -118,6 +118,7 @@ static int omap_dmic_dai_startup(struct snd_pcm_substream 
*substream,
 
mutex_unlock(dmic-mutex);
 
+   snd_soc_dai_set_dma_data(dai, substream, omap_dmic_dai_dma_params);
return ret;
 }
 
@@ -202,6 +203,7 @@ static int omap_dmic_dai_hw_params(struct snd_pcm_substream 
*substream,
struct snd_soc_dai *dai)
 {
struct omap_dmic *dmic = snd_soc_dai_get_drvdata(dai);
+   struct omap_pcm_dma_data *dma_data;
int channels;
 
dmic-clk_div = omap_dmic_select_divider(dmic, params_rate(params));
@@ -227,8 +229,8 @@ static int omap_dmic_dai_hw_params(struct snd_pcm_substream 
*substream,
}
 
/* packet size is threshold * channels */
-   omap_dmic_dai_dma_params.packet_size = dmic-threshold * channels;
-   snd_soc_dai_set_dma_data(dai, substream, omap_dmic_dai_dma_params);
+   dma_data = snd_soc_dai_get_dma_data(dai, substream);
+   dma_data-packet_size = dmic-threshold * channels;
 
return 0;
 }
diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index 0951767..f59c69f 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -67,6 +67,9 @@ static int omap_hdmi_dai_startup(struct snd_pcm_substream 
*substream,
dev_err(dai-dev, audio not supported\n);
return -ENODEV;
}
+
+   snd_soc_dai_set_dma_data(dai, substream, priv-dma_params);
+
return 0;
 }
 
@@ -85,24 +88,24 @@ static int omap_hdmi_dai_hw_params(struct snd_pcm_substream 
*substream,
struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai);
struct snd_aes_iec958 *iec = priv-iec;
struct snd_cea_861_aud_if *cea = priv-cea;
+   struct omap_pcm_dma_data *dma_data;
int err = 0;
 
+   dma_data = snd_soc_dai_get_dma_data(dai, substream);
+
switch (params_format(params)) {
case SNDRV_PCM_FORMAT_S16_LE:
-   priv-dma_params.packet_size = 16;
+   dma_data-packet_size = 16;
break;
case SNDRV_PCM_FORMAT_S24_LE:
-   priv-dma_params.packet_size = 32;
+   dma_data-packet_size = 32;
break;
default:
dev_err(dai-dev, format not supported!\n);
return -EINVAL;
}
 
-   priv-dma_params.data_type = 32;
-
-   snd_soc_dai_set_dma_data(dai, substream,
-priv-dma_params);
+   dma_data-data_type = 32;
 
/*
 * fill the IEC-60958 channel status word
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index a230646..fef2f59 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -151,6 +151,9 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream 
*substream,
   SNDRV_PCM_HW_PARAM_PERIOD_SIZE, 2);
}
 
+   snd_soc_dai_set_dma_data(cpu_dai, substream,
+mcbsp-dma_data[substream-stream]);
+
return err;
 }
 
@@ -228,7 +231,7 @@ static int omap_mcbsp_dai_hw_params(struct 
snd_pcm_substream *substream,
int pkt_size = 0;
unsigned int format, div, framesize, master;
 
-   dma_data = mcbsp-dma_data[substream-stream];
+   dma_data = snd_soc_dai_get_dma_data(cpu_dai, substream);
channels = params_channels(params);
 
switch (params_format(params)) {
@@ -277,8 +280,6 @@ static int omap_mcbsp_dai_hw_params(struct 
snd_pcm_substream *substream,
 
dma_data-packet_size = pkt_size;
 
-   snd_soc_dai_set_dma_data(cpu_dai, substream, dma_data);
-
if (mcbsp-configured) {
/* McBSP already configured by another stream */
return 0;
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index c1b4935..060cd16 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -266,9 +266,11 @@ static int omap_mcpdm_dai_startup(struct snd_pcm_substream 
*substream,
}
omap_mcpdm_open_streams(mcpdm);
}
-
mutex_unlock(mcpdm-mutex);
 
+   snd_soc_dai_set_dma_data(dai, substream,
+omap_mcpdm_dai_dma_params[substream-stream]);
+
return 0;
 }
 
@@ -323,7 

[PATCH 11/11] ASoC: omap-pcm: Convert to use dmaengine

2012-09-12 Thread Peter Ujfalusi
Original author: Russell King rmk+ker...@arm.linux.org.uk

Switch the omap-pcm to use dmaengine.
Certain features are not supported by after dmaengine conversion:
1. No period wakeup mode
   DMA engine has no way to communicate this information through
   standard channels.

2. Pause/Resume
   OMAP DMA engine backend does not support pausing and resuming
   an in-progress transfer.  It is unclear from the specs what
   effect clearing the enable bit has on the DMA position of a
   destination synchronized transfer, and whether the transfer
   can be restarted from the exact point that it was paused (or
   whether the data in the FIFO read from memory is simply
   discarded.)

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Russell King rmk+ker...@arm.linux.org.uk
---
 sound/soc/omap/Kconfig|   3 +-
 sound/soc/omap/omap-pcm.c | 279 +++---
 2 files changed, 67 insertions(+), 215 deletions(-)

diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 2c484a5..7048137 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -1,6 +1,7 @@
 config SND_OMAP_SOC
tristate SoC Audio for the Texas Instruments OMAP chips
-   depends on ARCH_OMAP
+   depends on ARCH_OMAP  DMA_OMAP
+   select SND_SOC_DMAENGINE_PCM
 
 config SND_OMAP_SOC_DMIC
tristate
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index 74da4b7..eb68c9e 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -25,21 +25,24 @@
 #include linux/dma-mapping.h
 #include linux/slab.h
 #include linux/module.h
+#include linux/omap-dma.h
 #include sound/core.h
 #include sound/pcm.h
 #include sound/pcm_params.h
+#include sound/dmaengine_pcm.h
 #include sound/soc.h
 
-#include plat/dma.h
 #include omap-pcm.h
 
 static const struct snd_pcm_hardware omap_pcm_hardware = {
.info   = SNDRV_PCM_INFO_MMAP |
  SNDRV_PCM_INFO_MMAP_VALID |
- SNDRV_PCM_INFO_INTERLEAVED |
- SNDRV_PCM_INFO_PAUSE |
- SNDRV_PCM_INFO_RESUME |
- SNDRV_PCM_INFO_NO_PERIOD_WAKEUP,
+ SNDRV_PCM_INFO_INTERLEAVED,
+ /*
+  * TODO: support for
+  * SNDRV_PCM_INFO_NO_PERIOD_WAKEUP
+  * via dmaengine.
+  */
.formats= SNDRV_PCM_FMTBIT_S16_LE |
  SNDRV_PCM_FMTBIT_S32_LE,
.period_bytes_min   = 32,
@@ -49,61 +52,34 @@ static const struct snd_pcm_hardware omap_pcm_hardware = {
.buffer_bytes_max   = 128 * 1024,
 };
 
-struct omap_runtime_data {
-   spinlock_t  lock;
-   struct omap_pcm_dma_data*dma_data;
-   int dma_ch;
-   int period_index;
-};
-
-static void omap_pcm_dma_irq(int ch, u16 stat, void *data)
+static int omap_pcm_get_dma_buswidth(int num_bits)
 {
-   struct snd_pcm_substream *substream = data;
-   struct snd_pcm_runtime *runtime = substream-runtime;
-   struct omap_runtime_data *prtd = runtime-private_data;
-   unsigned long flags;
-
-   if ((cpu_is_omap1510())) {
-   /*
-* OMAP1510 doesn't fully support DMA progress counter
-* and there is no software emulation implemented yet,
-* so have to maintain our own progress counters
-* that can be used by omap_pcm_pointer() instead.
-*/
-   spin_lock_irqsave(prtd-lock, flags);
-   if ((stat == OMAP_DMA_LAST_IRQ) 
-   (prtd-period_index == runtime-periods - 1)) {
-   /* we are in sync, do nothing */
-   spin_unlock_irqrestore(prtd-lock, flags);
-   return;
-   }
-   if (prtd-period_index = 0) {
-   if (stat  OMAP_DMA_BLOCK_IRQ) {
-   /* end of buffer reached, loop back */
-   prtd-period_index = 0;
-   } else if (stat  OMAP_DMA_LAST_IRQ) {
-   /* update the counter for the last period */
-   prtd-period_index = runtime-periods - 1;
-   } else if (++prtd-period_index = runtime-periods) {
-   /* end of buffer missed? loop back */
-   prtd-period_index = 0;
-   }
-   }
-   spin_unlock_irqrestore(prtd-lock, flags);
-   }
+   int buswidth;
 
-   snd_pcm_period_elapsed(substream);
+   switch (num_bits) {
+   case 16:
+   buswidth = 

[PATCH 07/11] ASoC: omap-mcpdm: Use platform_get_resource_* to get resources

2012-09-12 Thread Peter Ujfalusi
Get the needed resources in a correct way and avoid using defines for them.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 sound/soc/omap/omap-mcpdm.c | 28 +++-
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index baf92da..36648e0 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -41,7 +41,6 @@
 #include sound/soc.h
 
 #include plat/dma.h
-#include plat/omap_hwmod.h
 #include omap-mcpdm.h
 #include omap-pcm.h
 
@@ -71,15 +70,11 @@ struct omap_mcpdm {
 static struct omap_pcm_dma_data omap_mcpdm_dai_dma_params[] = {
{
.name = Audio playback,
-   .dma_req = OMAP44XX_DMA_MCPDM_DL,
.data_type = OMAP_DMA_DATA_TYPE_S32,
-   .port_addr = OMAP44XX_MCPDM_L3_BASE + MCPDM_REG_DN_DATA,
},
{
.name = Audio capture,
-   .dma_req = OMAP44XX_DMA_MCPDM_UP,
.data_type = OMAP_DMA_DATA_TYPE_S32,
-   .port_addr = OMAP44XX_MCPDM_L3_BASE + MCPDM_REG_UP_DATA,
},
 };
 
@@ -452,10 +447,33 @@ static __devinit int asoc_mcpdm_probe(struct 
platform_device *pdev)
 
mutex_init(mcpdm-mutex);
 
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, dma);
+   if (res == NULL)
+   return -ENOMEM;
+
+   omap_mcpdm_dai_dma_params[0].port_addr = res-start + MCPDM_REG_DN_DATA;
+   omap_mcpdm_dai_dma_params[1].port_addr = res-start + MCPDM_REG_UP_DATA;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL)
return -ENOMEM;
 
+   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, dn_link);
+   if (!res)
+   return -ENODEV;
+
+   omap_mcpdm_dai_dma_params[0].dma_req = res-start;
+
+   res = platform_get_resource_byname(pdev, IORESOURCE_DMA, up_link);
+   if (!res)
+   return -ENODEV;
+
+   omap_mcpdm_dai_dma_params[1].dma_req = res-start;
+
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, mpu);
+   if (res == NULL)
+   return -ENOMEM;
+
if (!devm_request_mem_region(pdev-dev, res-start,
 resource_size(res), McPDM))
return -EBUSY;
-- 
1.7.12

--
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 09/11] ASoC: omap-pcm, omap-hdmi: Change the use of omap_pcm_dma_data-data_type

2012-09-12 Thread Peter Ujfalusi
Instead of the OMAP DMA data type definition the data_type will be used to
specify the number of bits the DMA word should be configured or 0 in case
when based on the stream's format the omap-pcm can decide the needed DMA
word size.
This feature is needed for the omap-hdmi where the sDMA need to be
configured for 32bit word type regardless of the audio format used.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 sound/soc/omap/omap-hdmi.c | 3 +--
 sound/soc/omap/omap-pcm.c  | 3 ++-
 sound/soc/omap/omap-pcm.h  | 3 ++-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index b194646..0951767 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -34,7 +34,6 @@
 #include sound/asoundef.h
 #include video/omapdss.h
 
-#include plat/dma.h
 #include omap-pcm.h
 #include omap-hdmi.h
 
@@ -100,7 +99,7 @@ static int omap_hdmi_dai_hw_params(struct snd_pcm_substream 
*substream,
return -EINVAL;
}
 
-   priv-dma_params.data_type = OMAP_DMA_DATA_TYPE_S32;
+   priv-dma_params.data_type = 32;
 
snd_soc_dai_set_dma_data(dai, substream,
 priv-dma_params);
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index 4c13a5f..74da4b7 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -183,7 +183,8 @@ static int omap_pcm_prepare(struct snd_pcm_substream 
*substream)
memset(dma_params, 0, sizeof(dma_params));
 
if (dma_data-data_type)
-   dma_params.data_type = dma_data-data_type;
+   dma_params.data_type = omap_pcm_get_dma_type(
+   dma_data-data_type);
else
dma_params.data_type = omap_pcm_get_dma_type(
snd_pcm_format_physical_width(runtime-format));
diff --git a/sound/soc/omap/omap-pcm.h b/sound/soc/omap/omap-pcm.h
index 1bf47e4..cabe74c 100644
--- a/sound/soc/omap/omap-pcm.h
+++ b/sound/soc/omap/omap-pcm.h
@@ -32,7 +32,8 @@ struct omap_pcm_dma_data {
int dma_req;/* DMA request line */
unsigned long   port_addr;  /* transmit/receive register */
void (*set_threshold)(struct snd_pcm_substream *substream);
-   int data_type;  /* data type 8,16,32 */
+   int data_type;  /* 8, 16, 32 (bits) or 0 to let omap-pcm
+* to decide the sDMA data type */
int packet_size;/* packet size only in PACKET mode */
 };
 
-- 
1.7.12

--
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 01/11] dmaengine: omap: Support for element mode in cyclic DMA

2012-09-12 Thread Peter Ujfalusi
When src_maxburst/dst_maxburst is set to 0 by the users of cyclic DMA
(mostly audio) indicates that we should configure the omap DMA to element
sync mode instead of packet mode.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/omap-dma.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index ae05618..b77a40d 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -413,7 +413,10 @@ static struct dma_async_tx_descriptor 
*omap_dma_prep_dma_cyclic(
d-dev_addr = dev_addr;
d-fi = burst;
d-es = es;
-   d-sync_mode = OMAP_DMA_SYNC_PACKET;
+   if (burst)
+   d-sync_mode = OMAP_DMA_SYNC_PACKET;
+   else
+   d-sync_mode = OMAP_DMA_SYNC_ELEMENT;
d-sync_type = sync_type;
d-periph_port = OMAP_DMA_PORT_MPUI;
d-sg[0].addr = buf_addr;
-- 
1.7.12

--
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 04/11] ASoC: OMAP: Remove sync_mode from omap_pcm_dma_data struct

2012-09-12 Thread Peter Ujfalusi
The omap-pcm platform driver no longer needs this parameter to select
between ELEMENT and PACKET mode. The selection is based on the configured
packet_size.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 sound/soc/omap/omap-dmic.c  | 1 -
 sound/soc/omap/omap-hdmi.c  | 1 -
 sound/soc/omap/omap-mcbsp.c | 5 +
 sound/soc/omap/omap-mcpdm.c | 2 --
 sound/soc/omap/omap-pcm.h   | 1 -
 5 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index 75f5dca..60b7b8c 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -64,7 +64,6 @@ struct omap_dmic {
 static struct omap_pcm_dma_data omap_dmic_dai_dma_params = {
.name   = DMIC capture,
.data_type  = OMAP_DMA_DATA_TYPE_S32,
-   .sync_mode  = OMAP_DMA_SYNC_PACKET,
 };
 
 static inline void omap_dmic_write(struct omap_dmic *dmic, u16 reg, u32 val)
diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index a08245d..b194646 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -290,7 +290,6 @@ static __devinit int omap_hdmi_probe(struct platform_device 
*pdev)
 
hdmi_data-dma_params.dma_req =  hdmi_rsrc-start;
hdmi_data-dma_params.name = HDMI playback;
-   hdmi_data-dma_params.sync_mode = OMAP_DMA_SYNC_PACKET;
 
/*
 * TODO: We assume that there is only one DSS HDMI device. Future
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index fe3debc..5b3bacc 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -225,7 +225,7 @@ static int omap_mcbsp_dai_hw_params(struct 
snd_pcm_substream *substream,
struct omap_mcbsp *mcbsp = snd_soc_dai_get_drvdata(cpu_dai);
struct omap_mcbsp_reg_cfg *regs = mcbsp-cfg_regs;
struct omap_pcm_dma_data *dma_data;
-   int wlen, channels, wpf, sync_mode = OMAP_DMA_SYNC_ELEMENT;
+   int wlen, channels, wpf;
int pkt_size = 0;
unsigned int format, div, framesize, master;
 
@@ -272,15 +272,12 @@ static int omap_mcbsp_dai_hw_params(struct 
snd_pcm_substream *substream,
return -EINVAL;
 
pkt_size = period_words / divider;
-   sync_mode = OMAP_DMA_SYNC_PACKET;
} else if (channels  1) {
/* Use packet mode for non mono streams */
pkt_size = channels;
-   sync_mode = OMAP_DMA_SYNC_PACKET;
}
}
 
-   dma_data-sync_mode = sync_mode;
dma_data-packet_size = pkt_size;
 
snd_soc_dai_set_dma_data(cpu_dai, substream, dma_data);
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index f7babb3..baf92da 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -73,14 +73,12 @@ static struct omap_pcm_dma_data omap_mcpdm_dai_dma_params[] 
= {
.name = Audio playback,
.dma_req = OMAP44XX_DMA_MCPDM_DL,
.data_type = OMAP_DMA_DATA_TYPE_S32,
-   .sync_mode = OMAP_DMA_SYNC_PACKET,
.port_addr = OMAP44XX_MCPDM_L3_BASE + MCPDM_REG_DN_DATA,
},
{
.name = Audio capture,
.dma_req = OMAP44XX_DMA_MCPDM_UP,
.data_type = OMAP_DMA_DATA_TYPE_S32,
-   .sync_mode = OMAP_DMA_SYNC_PACKET,
.port_addr = OMAP44XX_MCPDM_L3_BASE + MCPDM_REG_UP_DATA,
},
 };
diff --git a/sound/soc/omap/omap-pcm.h b/sound/soc/omap/omap-pcm.h
index b92248c..1bf47e4 100644
--- a/sound/soc/omap/omap-pcm.h
+++ b/sound/soc/omap/omap-pcm.h
@@ -33,7 +33,6 @@ struct omap_pcm_dma_data {
unsigned long   port_addr;  /* transmit/receive register */
void (*set_threshold)(struct snd_pcm_substream *substream);
int data_type;  /* data type 8,16,32 */
-   int sync_mode;  /* DMA sync mode */
int packet_size;/* packet size only in PACKET mode */
 };
 
-- 
1.7.12

--
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 06/11] ARM: OMAP4: hwmod_data: Add resource names to McPDM memory ranges

2012-09-12 Thread Peter Ujfalusi
To help the driver to get the correct memory range to access McPDM
registers.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..f65251e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5059,6 +5059,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_per__mcbsp4 = 
{
 
 static struct omap_hwmod_addr_space omap44xx_mcpdm_addrs[] = {
{
+   .name   = mpu,
.pa_start   = 0x40132000,
.pa_end = 0x4013207f,
.flags  = ADDR_TYPE_RT
@@ -5077,6 +5078,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcpdm = {
 
 static struct omap_hwmod_addr_space omap44xx_mcpdm_dma_addrs[] = {
{
+   .name   = dma,
.pa_start   = 0x49032000,
.pa_end = 0x4903207f,
.flags  = ADDR_TYPE_RT
-- 
1.7.12

--
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 05/11] ASoC: omap-pcm: Prepare to configure the DMA data_type based on stream properties

2012-09-12 Thread Peter Ujfalusi
Based on the format of the stream the omap-pcm can decide alone what data
type should be used with by the sDMA.
Keep the possibility for OMAP dai drivers to tell omap-pcm if they want to
use different data type. This is needed for the omap-hdmi for example which
needs 32bit data type even if the stream format is S16_LE.

The check if (dma_data-data_type) is safe at the moment since omap-pcm
does not support 8bit samples (OMAP_DMA_DATA_TYPE_S8 == 0x00).

The next step is to redefine the meaning of dma_data-data_type to unblock
this limitation.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 sound/soc/omap/omap-pcm.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index 02eeb2e..4c13a5f 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -149,6 +149,24 @@ static int omap_pcm_hw_free(struct snd_pcm_substream 
*substream)
return 0;
 }
 
+static int omap_pcm_get_dma_type(int num_bits)
+{
+   int data_type;
+
+   switch (num_bits) {
+   case 16:
+   data_type = OMAP_DMA_DATA_TYPE_S16;
+   break;
+   case 32:
+   data_type = OMAP_DMA_DATA_TYPE_S32;
+   break;
+   default:
+   data_type = -EINVAL;
+   break;
+   }
+   return data_type;
+}
+
 static int omap_pcm_prepare(struct snd_pcm_substream *substream)
 {
struct snd_pcm_runtime *runtime = substream-runtime;
@@ -163,7 +181,16 @@ static int omap_pcm_prepare(struct snd_pcm_substream 
*substream)
return 0;
 
memset(dma_params, 0, sizeof(dma_params));
-   dma_params.data_type= dma_data-data_type;
+
+   if (dma_data-data_type)
+   dma_params.data_type = dma_data-data_type;
+   else
+   dma_params.data_type = omap_pcm_get_dma_type(
+   snd_pcm_format_physical_width(runtime-format));
+
+   if (dma_params.data_type  0)
+   return dma_params.data_type;
+
dma_params.trigger  = dma_data-dma_req;
 
if (dma_data-packet_size)
@@ -195,7 +222,7 @@ static int omap_pcm_prepare(struct snd_pcm_substream 
*substream)
 * still can get an interrupt at each period bounary
 */
bytes = snd_pcm_lib_period_bytes(substream);
-   dma_params.elem_count   = bytes  dma_data-data_type;
+   dma_params.elem_count   = bytes  dma_params.data_type;
dma_params.frame_count  = runtime-periods;
omap_set_dma_params(prtd-dma_ch, dma_params);
 
-- 
1.7.12

--
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 03/11] ASoC: omap-pcm: Select sDMA synchronization based on packet_size

2012-09-12 Thread Peter Ujfalusi
Since we only have element or packet synchronization we can use the
dma_data-packet_size to select the desired mode:
if packet_size is 0 we use ELEMENT mode
if packet_size is not 0 we use PACKET mode for sDMA synchronization.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 sound/soc/omap/omap-pcm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index f0feb06..02eeb2e 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -165,7 +165,12 @@ static int omap_pcm_prepare(struct snd_pcm_substream 
*substream)
memset(dma_params, 0, sizeof(dma_params));
dma_params.data_type= dma_data-data_type;
dma_params.trigger  = dma_data-dma_req;
-   dma_params.sync_mode= dma_data-sync_mode;
+
+   if (dma_data-packet_size)
+   dma_params.sync_mode = OMAP_DMA_SYNC_PACKET;
+   else
+   dma_params.sync_mode = OMAP_DMA_SYNC_ELEMENT;
+
if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK) {
dma_params.src_amode= OMAP_DMA_AMODE_POST_INC;
dma_params.dst_amode= OMAP_DMA_AMODE_CONSTANT;
-- 
1.7.12

--
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 02/11] ASoC: omap-mcbsp: Use sDMA packet mode instead of frame mode

2012-09-12 Thread Peter Ujfalusi
When McBSP is configured in threshold mode we can use sDMA packet mode in
all cases.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 sound/soc/omap/omap-mcbsp.c | 47 -
 1 file changed, 17 insertions(+), 30 deletions(-)

diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 2e91a86..fe3debc 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -81,9 +81,6 @@ static void omap_mcbsp_set_threshold(struct snd_pcm_substream 
*substream)
 */
if (dma_data-packet_size)
words = dma_data-packet_size;
-   else if (mcbsp-dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)
-   words = snd_pcm_lib_period_bytes(substream) /
-   (mcbsp-wlen / 8);
else
words = 1;
 
@@ -251,6 +248,7 @@ static int omap_mcbsp_dai_hw_params(struct 
snd_pcm_substream *substream,
dma_data-set_threshold = omap_mcbsp_set_threshold;
if (mcbsp-dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) {
int period_words, max_thrsh;
+   int divider = 0;
 
period_words = params_period_bytes(params) / (wlen / 8);
if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
@@ -258,34 +256,23 @@ static int omap_mcbsp_dai_hw_params(struct 
snd_pcm_substream *substream,
else
max_thrsh = mcbsp-max_rx_thres;
/*
-* If the period contains less or equal number of words,
-* we are using the original threshold mode setup:
-* McBSP threshold = sDMA frame size = period_size
-* Otherwise we switch to sDMA packet mode:
-* McBSP threshold = sDMA packet size
-* sDMA frame size = period size
+* Use sDMA packet mode if McBSP is in threshold mode:
+* If period words less than the FIFO size the packet
+* size is set to the number of period words, otherwise
+* Look for the biggest threshold value which divides
+* the period size evenly.
 */
-   if (period_words  max_thrsh) {
-   int divider = 0;
-
-   /*
-* Look for the biggest threshold value, which
-* divides the period size evenly.
-*/
-   divider = period_words / max_thrsh;
-   if (period_words % max_thrsh)
-   divider++;
-   while (period_words % divider 
-   divider  period_words)
-   divider++;
-   if (divider == period_words)
-   return -EINVAL;
-
-   pkt_size = period_words / divider;
-   sync_mode = OMAP_DMA_SYNC_PACKET;
-   } else {
-   sync_mode = OMAP_DMA_SYNC_FRAME;
-   }
+   divider = period_words / max_thrsh;
+   if (period_words % max_thrsh)
+   divider++;
+   while (period_words % divider 
+   divider  period_words)
+   divider++;
+   if (divider == period_words)
+   return -EINVAL;
+
+   pkt_size = period_words / divider;
+   sync_mode = OMAP_DMA_SYNC_PACKET;
} else if (channels  1) {
/* Use packet mode for non mono streams */
pkt_size = channels;
-- 
1.7.12

--
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] perf: Use raw_smp_processor_id insted of smp_processor_id

2012-09-12 Thread Roger Quadros
gets rid of below messages with CONFIG_DEBUG_PREEMPT enabled

[   28.832916] debug_smp_processor_id: 18 callbacks suppressed
[   28.832946] BUG: using smp_processor_id() in preemptible [] code: 
modprobe/1763
[   28.841491] caller is pwrdm_set_next_pwrst+0x54/0x120

Tested with perf on OMAP4 Panda.

Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/mach-omap2/clock.c   |6 +++---
 arch/arm/mach-omap2/pm34xx.c  |   11 +++
 arch/arm/mach-omap2/powerdomain.c |4 ++--
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index ea3f565..2765acd 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -285,7 +285,7 @@ void omap2_clk_disable(struct clk *clk)
pr_debug(clock: %s: disabling in hardware\n, clk-name);
 
if (clk-ops  clk-ops-disable) {
-   trace_clock_disable(clk-name, 0, smp_processor_id());
+   trace_clock_disable(clk-name, 0, raw_smp_processor_id());
clk-ops-disable(clk);
}
 
@@ -339,7 +339,7 @@ int omap2_clk_enable(struct clk *clk)
}
 
if (clk-ops  clk-ops-enable) {
-   trace_clock_enable(clk-name, 1, smp_processor_id());
+   trace_clock_enable(clk-name, 1, raw_smp_processor_id());
ret = clk-ops-enable(clk);
if (ret) {
WARN(1, clock: %s: could not enable: %d\n,
@@ -380,7 +380,7 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long rate)
 
/* dpll_ck, core_ck, virt_prcm_set; plus all clksel clocks */
if (clk-set_rate) {
-   trace_clock_set_rate(clk-name, rate, smp_processor_id());
+   trace_clock_set_rate(clk-name, rate, raw_smp_processor_id());
ret = clk-set_rate(clk, rate);
}
 
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 05bd8f0..d384068 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -346,18 +346,21 @@ void omap_sram_idle(void)
 
 static void omap3_pm_idle(void)
 {
+   int cpu;
+
local_fiq_disable();
 
if (omap_irq_pending())
goto out;
 
-   trace_power_start(POWER_CSTATE, 1, smp_processor_id());
-   trace_cpu_idle(1, smp_processor_id());
+   cpu = raw_smp_processor_id();
+   trace_power_start(POWER_CSTATE, 1, cpu);
+   trace_cpu_idle(1, cpu);
 
omap_sram_idle();
 
-   trace_power_end(smp_processor_id());
-   trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
+   trace_power_end(cpu);
+   trace_cpu_idle(PWR_EVENT_EXIT, cpu);
 
 out:
local_fiq_enable();
diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index 69b36e1..f1d0d69 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -169,7 +169,7 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm, 
int flag)
   ((state  OMAP_POWERSTATE_MASK)  8) |
   ((prev  OMAP_POWERSTATE_MASK)  0));
trace_power_domain_target(pwrdm-name, trace_state,
- smp_processor_id());
+ raw_smp_processor_id());
}
break;
default:
@@ -491,7 +491,7 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 
pwrst)
if (arch_pwrdm  arch_pwrdm-pwrdm_set_next_pwrst) {
/* Trace the pwrdm desired target state */
trace_power_domain_target(pwrdm-name, pwrst,
- smp_processor_id());
+ raw_smp_processor_id());
/* Program the pwrdm desired target state */
ret = arch_pwrdm-pwrdm_set_next_pwrst(pwrdm, pwrst);
}
-- 
1.7.4.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: [PATCHv7 20/23] i2c: omap: switch to threaded IRQ support

2012-09-12 Thread Wolfram Sang
On Wed, Sep 12, 2012 at 11:55:39AM +0530, Shubhrajyoti wrote:
 On Wednesday 12 September 2012 03:21 AM, Wolfram Sang wrote:
  -omap_i2c_isr(int this_irq, void *dev_id)
   +omap_i2c_isr(int irq, void *dev_id)
{
struct omap_i2c_dev *dev = dev_id;
   +irqreturn_t ret = IRQ_HANDLED;
  Shouldn't that be IRQ_NONE?
 Actually we are processing it so I thought it to be ok.

Are we processing it? There is nothing acknowledged AFAICS. Anyway, we
can fix that with a later patch.

 Also a similar discussion.
  
 http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/104422.html

I totally agree to the things said there.

-- 
Pengutronix e.K.   | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/  |


signature.asc
Description: Digital signature


Re: [PATCH 11/11] ASoC: omap-pcm: Convert to use dmaengine

2012-09-12 Thread Russell King - ARM Linux
On Wed, Sep 12, 2012 at 02:47:07PM +0300, Peter Ujfalusi wrote:
 2. Pause/Resume
OMAP DMA engine backend does not support pausing and resuming
an in-progress transfer.  It is unclear from the specs what
effect clearing the enable bit has on the DMA position of a
destination synchronized transfer, and whether the transfer
can be restarted from the exact point that it was paused (or
whether the data in the FIFO read from memory is simply
discarded.)

It's worth noting that this comment (which was in my original patch)
is there to spark _comment_ and _discussion_ and should not make its
way into the final version of these patches.

Given that suspend/resume is important on OMAP platforms, it's something
that needs to be resolved - in a way that complies with what ALSA expects.
I do not believe that the way the existing drivers do this is compliant
as the manuals imply that stopping memory-peripheral transfers results
in data being discarded from the DMA's FIFOs.  As I understand it, ALSA
requires no data to be discarded.

As we have no way to know how much data may be discarded from the DMA
FIFO...
--
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 Hebbar, Gururaja
On Wed, Sep 12, 2012 at 14:19:51, S, Venkatraman wrote:
 On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja gururaja.heb...@ti.com 
 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.

My reasons for DT Binding
1. Not all platforms using this driver has this bit (OMAP2)
2. Not all platforms using this driver needs this bit to be enabled (OMAP4)
3. Platforms which require this bit this to be set needs a method to inform 
driver.

In order to not disturb old/unsupported platforms, I chose this DT method.

 By definition, HS implies 25MHz or above, so that check seems to be
 redundant as well.

There are chances that the platform Max Clock output from HSMMC IP is  than 
25 MHz even if the card is High Speed. In such cases it would be better to
Confirm that the Clock output is actually  25 MHz

Kindly correct me if I am wrong.

 Meanwhile, I'll check with HSPE enabled on OMAP.
 
 Regards,
 Venkat.
 


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


Re: [PATCH] perf: Use raw_smp_processor_id insted of smp_processor_id

2012-09-12 Thread Russell King - ARM Linux
On Wed, Sep 12, 2012 at 02:50:10PM +0300, Roger Quadros wrote:
 gets rid of below messages with CONFIG_DEBUG_PREEMPT enabled
 
 [   28.832916] debug_smp_processor_id: 18 callbacks suppressed
 [   28.832946] BUG: using smp_processor_id() in preemptible [] code: 
 modprobe/1763
 [   28.841491] caller is pwrdm_set_next_pwrst+0x54/0x120
 
 Tested with perf on OMAP4 Panda.

NAK.  Using a different function which doesn't have the warning isn't a
subsitute for fixing the problem properly.  What you're doing is papering
over the bug, making the warning go away without properly understanding
the problem.

The warning is there because something is being done wrong.  What that is
is exactly what is being said in the warning message.  You're getting a
CPU number in a context where preemptions can occur - and therefore the
CPU that you're running on can change.

Think about this sequence:

- cpu = smp_processor_id(); /* returns 0 */
- you are preempted
- you resume on CPU 1
- trace_clock_disable(clk-name, 0, 0);

If trace_clock_disable() uses the CPU number to access per-CPU data
without locking, that's going to cause corruption.

Please, if you're going to fix a warning, analyse it properly first and
don't just search for a function which appears to give you the same
functionality but without the warning message.
--
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: [balbi-usb:merge-result-for-greg 66/99] drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma on the stack ((null))

2012-09-12 Thread Felipe Balbi
Hi,

On Wed, Sep 12, 2012 at 11:50:57AM +0300, Dan Carpenter wrote:
 On Wed, Sep 12, 2012 at 04:26:22PM +0800, Fengguang Wu wrote:
  Hi Felipe,
  
  FYI, there are new smatch warnings show up in
  
  tree:   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
  merge-result-for-greg
  head:   23953bde3e4d6aa8780dc054f6ad9882ac63f4f4
  commit: e918fa161f510136fce45a524e934fe20e62c8b1 [66/99] Merge tag 
  'gadget-for-v3.7' into merge-result-for-greg
  
  drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma 
  on the stack ((null))

that's not part of what I handle :-(

And merge-result-for-greg was really a temporary branch, btw :-)

-- 
balbi


signature.asc
Description: Digital signature


Re: [balbi-usb:merge-result-for-greg 66/99] drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing dma on the stack ((null))

2012-09-12 Thread Fengguang Wu
On Wed, Sep 12, 2012 at 03:02:13PM +0300, Felipe Balbi wrote:
 Hi,
 
 On Wed, Sep 12, 2012 at 11:50:57AM +0300, Dan Carpenter wrote:
  On Wed, Sep 12, 2012 at 04:26:22PM +0800, Fengguang Wu wrote:
   Hi Felipe,
   
   FYI, there are new smatch warnings show up in
   
   tree:   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
   merge-result-for-greg
   head:   23953bde3e4d6aa8780dc054f6ad9882ac63f4f4
   commit: e918fa161f510136fce45a524e934fe20e62c8b1 [66/99] Merge tag 
   'gadget-for-v3.7' into merge-result-for-greg
   
   drivers/usb/core/hub.c:2654 usb_get_hub_port_power_state() error: doing 
   dma on the stack ((null))
 
 that's not part of what I handle :-(
 
 And merge-result-for-greg was really a temporary branch, btw :-)

No problem. I'll stop testing this branch :)

Thanks,
Fengguang
--
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] ARM: mm: ADD descriptor string to CONFIG_DMA_ADDR_64BIT_T

2012-09-12 Thread Cyril Chemparathy

On 9/12/2012 1:50 AM, R Sricharan wrote:

Even if CONFIG_DMA_ADDR_64BIT_T is enabled by the defconfig,
the feature is not getting selected.
Adding a string description in the Kconfig resolves this.

But not sure if this is the right way to fix this.



Shouldn't you be selecting this in your 64-bit dma address capable arch 
instead?



Signed-off-by: R Sricharan r.sricha...@ti.com
Cc: Catalin Marinas catalin.mari...@arm.com
---
  arch/arm/mm/Kconfig |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 101b968..90c5ea4 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -601,7 +601,7 @@ config ARCH_PHYS_ADDR_T_64BIT
def_bool ARM_LPAE

  config ARCH_DMA_ADDR_T_64BIT
-   bool
+   bool 64bit capable DMA device

  config ARM_THUMB
bool Support Thumb user binaries



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


RE: [PATCH 4/4] can: c_can: Add d_can suspend resume support

2012-09-12 Thread AnilKumar, Chimata
Hi Marc,

On Tue, Sep 04, 2012 at 12:57:18, Marc Kleine-Budde wrote:
 On 09/04/2012 08:14 AM, AnilKumar, Chimata wrote:
  Marc,
  
  Thanks for the comments,
  
  On Tue, Sep 04, 2012 at 01:31:35, Marc Kleine-Budde wrote:
  On 09/03/2012 01:52 PM, AnilKumar Ch wrote:
  Adds suspend resume support to DCAN driver which enables
  DCAN power down mode bit (PDR). Then DCAN will ack the local
  power-down mode by setting PDA bit in STATUS register.
 
  Also adds a status flag to know the status of DCAN module,
  whether it is opened or not.
 
  Use ndev-flags  IFF_UP for that. Have a look at the at91_can driver
  [1]. I'm not sure if you need locking here.
 
  
  Then I can use this to check the status, lock is not
  required.
  
  [1] http://lxr.free-electrons.com/source/drivers/net/can/at91_can.c#L1198
 
  Signed-off-by: AnilKumar Ch anilku...@ti.com
  ---
   drivers/net/can/c_can/c_can.c  |   78 
  
   drivers/net/can/c_can/c_can.h  |5 ++
   drivers/net/can/c_can/c_can_platform.c |   70 
  ++--
   3 files changed, 150 insertions(+), 3 deletions(-)

[snip]

  +#ifdef CONFIG_PM
  +int c_can_power_down(struct net_device *dev)
  +{
  + unsigned long time_out;
  + struct c_can_priv *priv = netdev_priv(dev);
  +
  + if (!priv-is_opened)
  + return 0;
 
  Should we add a BUG_ON(id-driver_data != BOSCH_D_CAN)?
  
  These APIs are called from platform driver where device type
  device type is verified. I think we have to add BUG_ON() in
  platform driver.
 
 The platform driver returns if not on D_CAN and will not call this
 function. But this functions are exported, so can be called by someone
 else. So if the caller is not D_CAN, it's a bug.


I agree with you, but I have some concern here.
I think we should do return 0; instead of BUG_ON(). With
BUG_ON() system will hang and ultimately user lost his/her
contents.

Thanks
AnilKumar
--
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 11/11] ASoC: omap-pcm: Convert to use dmaengine

2012-09-12 Thread Peter Ujfalusi
On 09/12/2012 03:00 PM, Russell King - ARM Linux wrote:
 On Wed, Sep 12, 2012 at 02:47:07PM +0300, Peter Ujfalusi wrote:
 2. Pause/Resume
OMAP DMA engine backend does not support pausing and resuming
an in-progress transfer.  It is unclear from the specs what
effect clearing the enable bit has on the DMA position of a
destination synchronized transfer, and whether the transfer
can be restarted from the exact point that it was paused (or
whether the data in the FIFO read from memory is simply
discarded.)
 
 It's worth noting that this comment (which was in my original patch)
 is there to spark _comment_ and _discussion_ and should not make its
 way into the final version of these patches.
 
 Given that suspend/resume is important on OMAP platforms, it's something
 that needs to be resolved - in a way that complies with what ALSA expects.
 I do not believe that the way the existing drivers do this is compliant
 as the manuals imply that stopping memory-peripheral transfers results
 in data being discarded from the DMA's FIFOs.  As I understand it, ALSA
 requires no data to be discarded.
 
 As we have no way to know how much data may be discarded from the DMA
 FIFO...

I need to look at this, but at first look we do wait for the drain in
omap_stop_dma(). We used to use omap_stop_dma/omap_start_dma for pause/resume
operations.
But sDMA also have a bit: CDPi: PAUSE_LINK_LIST which should do what we are
looking for.
Need to read the relevant parts of the TRM, but AFAIK we are using normal mode
with linked list (self linking).
I already have the patch for this, I just need to test it on HW.

-- 
Péter
--
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] ARM: mm: ADD descriptor string to CONFIG_DMA_ADDR_64BIT_T

2012-09-12 Thread Catalin Marinas
On Wed, Sep 12, 2012 at 01:46:18PM +0100, Cyril Chemparathy wrote:
 On 9/12/2012 1:50 AM, R Sricharan wrote:
  Even if CONFIG_DMA_ADDR_64BIT_T is enabled by the defconfig,
  the feature is not getting selected.
  Adding a string description in the Kconfig resolves this.
 
  But not sure if this is the right way to fix this.
 
 Shouldn't you be selecting this in your 64-bit dma address capable arch 
 instead?

Yes, that's how it was meant to be used.

-- 
Catalin
--
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] ARM: mm: ADD descriptor string to CONFIG_DMA_ADDR_64BIT_T

2012-09-12 Thread Shilimkar, Santosh
On Wed, Sep 12, 2012 at 6:16 PM, Cyril Chemparathy cy...@ti.com wrote:

 On 9/12/2012 1:50 AM, R Sricharan wrote:

 Even if CONFIG_DMA_ADDR_64BIT_T is enabled by the defconfig,
 the feature is not getting selected.
 Adding a string description in the Kconfig resolves this.

 But not sure if this is the right way to fix this.


 Shouldn't you be selecting this in your 64-bit dma address capable arch
 instead?

Yes. The selection to enable  CONFIG_DMA_ADDR_64BIT_T happens
in the arch which needs it. Since this option was made as simple bool,
looks like because of some KCONFIG magic, it was not getting selected.
Adding some help text does fix the issue and thats is the patch all about.

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


Re: [PATCH 4/4] can: c_can: Add d_can suspend resume support

2012-09-12 Thread Marc Kleine-Budde
On 09/12/2012 02:48 PM, AnilKumar, Chimata wrote:
 Hi Marc,
 
 On Tue, Sep 04, 2012 at 12:57:18, Marc Kleine-Budde wrote:
 On 09/04/2012 08:14 AM, AnilKumar, Chimata wrote:
 Marc,

 Thanks for the comments,

 On Tue, Sep 04, 2012 at 01:31:35, Marc Kleine-Budde wrote:
 On 09/03/2012 01:52 PM, AnilKumar Ch wrote:
 Adds suspend resume support to DCAN driver which enables
 DCAN power down mode bit (PDR). Then DCAN will ack the local
 power-down mode by setting PDA bit in STATUS register.

 Also adds a status flag to know the status of DCAN module,
 whether it is opened or not.

 Use ndev-flags  IFF_UP for that. Have a look at the at91_can driver
 [1]. I'm not sure if you need locking here.


 Then I can use this to check the status, lock is not
 required.

 [1] http://lxr.free-electrons.com/source/drivers/net/can/at91_can.c#L1198

 Signed-off-by: AnilKumar Ch anilku...@ti.com
 ---
  drivers/net/can/c_can/c_can.c  |   78 
 
  drivers/net/can/c_can/c_can.h  |5 ++
  drivers/net/can/c_can/c_can_platform.c |   70 
 ++--
  3 files changed, 150 insertions(+), 3 deletions(-)
 
 [snip]
 
 +#ifdef CONFIG_PM
 +int c_can_power_down(struct net_device *dev)
 +{
 + unsigned long time_out;
 + struct c_can_priv *priv = netdev_priv(dev);
 +
 + if (!priv-is_opened)
 + return 0;

 Should we add a BUG_ON(id-driver_data != BOSCH_D_CAN)?

 These APIs are called from platform driver where device type
 device type is verified. I think we have to add BUG_ON() in
 platform driver.

 The platform driver returns if not on D_CAN and will not call this
 function. But this functions are exported, so can be called by someone
 else. So if the caller is not D_CAN, it's a bug.

 
 I agree with you, but I have some concern here.
 I think we should do return 0; instead of BUG_ON(). With
 BUG_ON() system will hang and ultimately user lost his/her
 contents.

Good point, better safe then sorry.
But this should not happen. What about WARN_ON()?

Marc
-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature


Re: [PATCHv8 00/23]I2C big cleanup

2012-09-12 Thread Wolfram Sang
On Wed, Sep 12, 2012 at 04:27:54PM +0530, Shubhrajyoti D wrote:
 Changes since v1:
- removed tabification on patch 6/17
- removed dev_err() which was introduced on patch 09/17
 Changes since v2:
 - do not set full fifo depth in the RDR interrupt.
 - some changelog updates.
 - rebase to the Wolfram's tree.
 Changes since v3:
 - Remove a redundant read of status register
 - Read the dev-buf_len variable instead of the register
 as the information of the remaining bytes is there.
 Changes since v4:
 - Ack the arbitration lost.
 - Rebase to the i2c-embedded/for-next branch.
 Changes since v5:
 - Rebase to latest mainline
 - Added some more cleanup patches so as have a consolidated series.
 Changes since v6:
 - Fix comments on setting the pdev to NULL.
 - Trivial changelog update
 Changes since v7:
   - Remove a patch as the code is getting changed anyways
   - Changelogs update.
 
 Previous discussions can be found here 
 http://www.spinics.net/lists/linux-i2c/msg09764.html
 
 This is the cleanup only series.
   
 Tested on omap4sdp and 3430sdp.
 
 The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:
 
   Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)
 
 are available in the git repository at:
   git://gitorious.org/linus-tree/linus-tree.git for_3.7/i2c/big_cleanups

Pushed to -next. Thanks to all involved!

-- 
Pengutronix e.K.   | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/  |


signature.asc
Description: Digital signature


Re: [RFC PATCH] ARM: mm: ADD descriptor string to CONFIG_DMA_ADDR_64BIT_T

2012-09-12 Thread Catalin Marinas
On Wed, Sep 12, 2012 at 01:57:26PM +0100, Shilimkar, Santosh wrote:
 On Wed, Sep 12, 2012 at 6:16 PM, Cyril Chemparathy cy...@ti.com wrote:
 
  On 9/12/2012 1:50 AM, R Sricharan wrote:
 
  Even if CONFIG_DMA_ADDR_64BIT_T is enabled by the defconfig,
  the feature is not getting selected.
  Adding a string description in the Kconfig resolves this.
 
  But not sure if this is the right way to fix this.
 
 
  Shouldn't you be selecting this in your 64-bit dma address capable arch
  instead?
 
 Yes. The selection to enable  CONFIG_DMA_ADDR_64BIT_T happens
 in the arch which needs it. Since this option was made as simple bool,
 looks like because of some KCONFIG magic, it was not getting selected.
 Adding some help text does fix the issue and thats is the patch all about.

Are you sure you select this explicitly in Kconfig? It should not depend
on a description.

What I understood from the initial email was that this option was only
added to the defconfig but ignored by the kernel as it's not a user
selectable option (unless you add some text).

-- 
Catalin
--
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: [PATCHv8 00/23]I2C big cleanup

2012-09-12 Thread Shubhrajyoti
On Wednesday 12 September 2012 06:46 PM, Wolfram Sang wrote:
 Tested on omap4sdp and 3430sdp.
  
  The following changes since commit 
  55d512e245bc7699a8800e23df1a24195dd08217:
  
Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)
  
  are available in the git repository at:
git://gitorious.org/linus-tree/linus-tree.git for_3.7/i2c/big_cleanups
 Pushed to -next. Thanks to all involved!
Thanks.
--
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] ARM: mm: ADD descriptor string to CONFIG_DMA_ADDR_64BIT_T

2012-09-12 Thread R, Sricharan
Hi,
On Wed, Sep 12, 2012 at 6:55 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
 On Wed, Sep 12, 2012 at 6:49 PM, Catalin Marinas
 catalin.mari...@arm.com wrote:
 On Wed, Sep 12, 2012 at 01:57:26PM +0100, Shilimkar, Santosh wrote:
 On Wed, Sep 12, 2012 at 6:16 PM, Cyril Chemparathy cy...@ti.com wrote:
 
  On 9/12/2012 1:50 AM, R Sricharan wrote:
 
  Even if CONFIG_DMA_ADDR_64BIT_T is enabled by the defconfig,
  the feature is not getting selected.
  Adding a string description in the Kconfig resolves this.
 
  But not sure if this is the right way to fix this.
 
 
  Shouldn't you be selecting this in your 64-bit dma address capable arch
  instead?
 
 Yes. The selection to enable  CONFIG_DMA_ADDR_64BIT_T happens
 in the arch which needs it. Since this option was made as simple bool,
 looks like because of some KCONFIG magic, it was not getting selected.
 Adding some help text does fix the issue and thats is the patch all about.

 Are you sure you select this explicitly in Kconfig? It should not depend
 on a description.

 You are right.

 What I understood from the initial email was that this option was only
 added to the defconfig but ignored by the kernel as it's not a user
 selectable option (unless you add some text).

 That's right. Explicit KCONFIG select should work.
 yes. It works when enabled in arch/KCONFIG.
 Thanks. This patch is not needed then.

Thanks,
 Sricharan
--
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] spi: omap2-mcspi: Cleanup the omap2_mcspi_txrx_dma function

2012-09-12 Thread Felipe Balbi
On Tue, Sep 11, 2012 at 12:13:20PM +0530, Shubhrajyoti D wrote:
 Currently in omap2_mcspi_txrx_dma the tx and the rx support is
 interleaved. Make the rx related code in omap2_mcspi_rx_dma
 and the tx related code omap2_mcspi_tx_dma and call the functions.
 
 While at it remove the braces in the if statements which has only
 one line.
 Also fix [foo * bar to foo *bar] warn for the rx and tx variables.
 
 Only a cleanup no functional change.
 
 Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com

I just tested this on my pandaboard by shorting out MISO and MOSI (since
panda doesn't have any clients on spi bus) and using spidev:

#  ./spidev_test -D /dev/spidev
spi mode: 0
bits per word: 8
max speed: 50 Hz (500 KHz)

FF FF FF FF FF FF 
40 00 00 00 00 95 
FF FF FF FF FF FF 
FF FF FF FF FF FF 
FF FF FF FF FF FF 
DE AD BE EF BA AD 
F0 0D

./spidev_test -D /dev/spidev -s 2400
spi mode: 0
bits per word: 8
max speed: 2400 Hz (24000 KHz)

FF FF FF FF FF FF 
40 00 00 00 00 95 
FF FF FF FF FF FF 
FF FF FF FF FF FF 
FF FF FF FF FF FF 
DE AD BE EF BA AD 
F0 0D

seems to be working fine (at least from my quick tests)

Tested-by: Felipe Balbi ba...@ti.com

 ---
  drivers/spi/spi-omap2-mcspi.c |  256 
 +++--
  1 files changed, 144 insertions(+), 112 deletions(-)
 
 diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
 index 1c1dd34..dd8fc88 100644
 --- a/drivers/spi/spi-omap2-mcspi.c
 +++ b/drivers/spi/spi-omap2-mcspi.c
 @@ -315,49 +315,27 @@ static void omap2_mcspi_tx_callback(void *data)
   omap2_mcspi_set_dma_req(spi, 0, 0);
  }
  
 -static unsigned
 -omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer)
 +static void omap2_mcspi_tx_dma(struct spi_device *spi,
 + struct spi_transfer *xfer,
 + struct dma_slave_config cfg)
  {
   struct omap2_mcspi  *mcspi;
 - struct omap2_mcspi_cs   *cs = spi-controller_state;
   struct omap2_mcspi_dma  *mcspi_dma;
   unsigned intcount;
 - int word_len, element_count;
 - int elements = 0;
 - u32 l;
   u8  * rx;
   const u8* tx;
   void __iomem*chstat_reg;
 - struct dma_slave_config cfg;
 - enum dma_slave_buswidth width;
 - unsigned es;
 + struct omap2_mcspi_cs   *cs = spi-controller_state;
  
   mcspi = spi_master_get_devdata(spi-master);
   mcspi_dma = mcspi-dma_channels[spi-chip_select];
 - l = mcspi_cached_chconf0(spi);
 + count = xfer-len;
  
 + rx = xfer-rx_buf;
 + tx = xfer-tx_buf;
   chstat_reg = cs-base + OMAP2_MCSPI_CHSTAT0;
  
 - if (cs-word_len = 8) {
 - width = DMA_SLAVE_BUSWIDTH_1_BYTE;
 - es = 1;
 - } else if (cs-word_len = 16) {
 - width = DMA_SLAVE_BUSWIDTH_2_BYTES;
 - es = 2;
 - } else {
 - width = DMA_SLAVE_BUSWIDTH_4_BYTES;
 - es = 4;
 - }
 -
 - memset(cfg, 0, sizeof(cfg));
 - cfg.src_addr = cs-phys + OMAP2_MCSPI_RX0;
 - cfg.dst_addr = cs-phys + OMAP2_MCSPI_TX0;
 - cfg.src_addr_width = width;
 - cfg.dst_addr_width = width;
 - cfg.src_maxburst = 1;
 - cfg.dst_maxburst = 1;
 -
 - if (xfer-tx_buf  mcspi_dma-dma_tx) {
 + if (mcspi_dma-dma_tx) {
   struct dma_async_tx_descriptor *tx;
   struct scatterlist sg;
  
 @@ -368,7 +346,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct 
 spi_transfer *xfer)
   sg_dma_len(sg) = xfer-len;
  
   tx = dmaengine_prep_slave_sg(mcspi_dma-dma_tx, sg, 1,
 - DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
 + DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
   if (tx) {
   tx-callback = omap2_mcspi_tx_callback;
   tx-callback_param = spi;
 @@ -377,8 +355,50 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct 
 spi_transfer *xfer)
   /* FIXME: fall back to PIO? */
   }
   }
 + dma_async_issue_pending(mcspi_dma-dma_tx);
 + omap2_mcspi_set_dma_req(spi, 0, 1);
  
 - if (xfer-rx_buf  mcspi_dma-dma_rx) {
 + wait_for_completion(mcspi_dma-dma_tx_completion);
 + dma_unmap_single(mcspi-dev, xfer-tx_dma, count,
 +  DMA_TO_DEVICE);
 +
 + /* for TX_ONLY mode, be sure all words have shifted out */
 + if (rx == NULL) {
 + if (mcspi_wait_for_reg_bit(chstat_reg,
 + OMAP2_MCSPI_CHSTAT_TXS)  0)
 + dev_err(spi-dev, TXS timed out\n);
 + else if (mcspi_wait_for_reg_bit(chstat_reg,
 + OMAP2_MCSPI_CHSTAT_EOT)  0)
 + dev_err(spi-dev, EOT timed out\n);
 + }
 +}
 +
 +static unsigned
 +omap2_mcspi_rx_dma(struct spi_device *spi, struct 

Re: [PATCHv7 00/23]I2C big cleanup

2012-09-12 Thread Wolfram Sang
On Wed, Sep 12, 2012 at 12:18:50PM +0200, Wolfram Sang wrote:
 
  I donot see the warning. Am I missing something?
 
 I deleted my logfiles already. Ignore it for now, if it comes up again
 with your new series, I will give a more detailed pointer.

Sorry, the section mismatch was not related to I2C it seems:

WARNING: vmlinux.o(.data+0x30958): Section mismatch in reference from the 
variable rx51_si4713_dev to the (unknown reference) .init.data:(unknown)
The variable rx51_si4713_dev references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

Got it with an allnoconfig and then selecting MMU and OMAP.

Regards,

   Wolfram

-- 
Pengutronix e.K.   | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/  |


signature.asc
Description: Digital signature


Re: [PATCH] spi: omap2-mcspi: Cleanup the omap2_mcspi_txrx_dma function

2012-09-12 Thread Shubhrajyoti
On Wednesday 12 September 2012 07:09 PM, Felipe Balbi wrote:
 seems to be working fine (at least from my quick tests)

 Tested-by: Felipe Balbi ba...@ti.com
Thanks Felipe.
--
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] spi: omap2-mcspi: Cleanup the omap2_mcspi_txrx_dma function

2012-09-12 Thread Mark Brown
On Tue, Sep 11, 2012 at 12:13:20PM +0530, Shubhrajyoti D wrote:
 Currently in omap2_mcspi_txrx_dma the tx and the rx support is
 interleaved. Make the rx related code in omap2_mcspi_rx_dma
 and the tx related code omap2_mcspi_tx_dma and call the functions.

Applied, thanks.
--
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-i2c: fix incorrect log message when using a device tree

2012-09-12 Thread Wolfram Sang
On Fri, Aug 31, 2012 at 01:02:55PM +0200, Florian Vaussard wrote:
 When booting using a device tree, the adapter number is dynamically
 assigned after the log message is sent.
 This patch modifies the log message to get a correct adapter id.
 
 Applies on 3.6-rc3. Tested on OMAP3 (Gumstix Overo).
 
 Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch

Pushed to -next, thanks.

-- 
Pengutronix e.K.   | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/  |


signature.asc
Description: Digital signature


Re: [PATCH] CPUFreq: OMAP: remove unnecessary plat/ includes

2012-09-12 Thread Kevin Hilman
Shilimkar, Santosh santosh.shilim...@ti.com writes:

 On Wed, Sep 12, 2012 at 6:02 AM, Paul Walmsley p...@pwsan.com wrote:

 Remove some unnecessary plat/ includes that are interfering with 
 multi-subarch
 ARM kernels.

 Signed-off-by: Paul Walmsley p...@pwsan.com
 Cc: Kevin Hilman khil...@ti.com
 Cc: Rafael J. Wysocki r...@sisk.pl
 Acked-by: Kevin Hilman khil...@ti.com
 ---

 Still awaiting some final testing here.  Rafael, was wondering if you
 would be willing to ack this so we can merge it via the OMAP tree?
 Otherwise the patch can be split into an OMAP part and a CPUFreq part that
 can go in across two merge windows.

 Hmm.
 I did similar change[1] a while back. Kevin didn't like idea though
 that point of time.

I was wrong.

At the time, we were thinking about how to get rid of clkdev nodes
instead of add more.  Now, we need to clean up these drivers and this is
the only way to do it, so I retract my objection.

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: [alsa-devel] [PATCH 11/11] ASoC: omap-pcm: Convert to use dmaengine

2012-09-12 Thread Takashi Iwai
At Wed, 12 Sep 2012 13:00:28 +0100,
Russell King - ARM Linux wrote:
 
 On Wed, Sep 12, 2012 at 02:47:07PM +0300, Peter Ujfalusi wrote:
  2. Pause/Resume
 OMAP DMA engine backend does not support pausing and resuming
 an in-progress transfer.  It is unclear from the specs what
 effect clearing the enable bit has on the DMA position of a
 destination synchronized transfer, and whether the transfer
 can be restarted from the exact point that it was paused (or
 whether the data in the FIFO read from memory is simply
 discarded.)
 
 It's worth noting that this comment (which was in my original patch)
 is there to spark _comment_ and _discussion_ and should not make its
 way into the final version of these patches.

I agree this can be regarded as a sort of regression...

 Given that suspend/resume is important on OMAP platforms, it's something
 that needs to be resolved - in a way that complies with what ALSA expects.
 I do not believe that the way the existing drivers do this is compliant
 as the manuals imply that stopping memory-peripheral transfers results
 in data being discarded from the DMA's FIFOs.  As I understand it, ALSA
 requires no data to be discarded.

... but in general you don't need to implement the full PAUSE and
RESUME operations for PCM.  For example, when SNDRV_PCM_INFO_RESUME
bit isn't set, user-space is supposed to do a clean restart of the
stream at wake up.  So, it shouldn't break the apps severely in
theory (but in practice, who knows :)

 As we have no way to know how much data may be discarded from the DMA
 FIFO...

Yeah, the FIFO and the amount of other on flight data can be better
managed.


Takashi
--
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/4] staging: omap-thermal: Correct checkpatch.pl warnings

2012-09-12 Thread Dan Carpenter
On Wed, Sep 12, 2012 at 12:19:00PM +0300, Valentin, Eduardo wrote:
 Hello Dan,
 
 On Wed, Sep 12, 2012 at 11:26 AM, Dan Carpenter
 dan.carpen...@oracle.com wrote:
  On Wed, Sep 12, 2012 at 11:11:27AM +0300, Dan Carpenter wrote:
  On Tue, Sep 11, 2012 at 07:06:52PM +0300, Eduardo Valentin wrote:
   From: J Keerthy j-keer...@ti.com
  
   Removes checkpatch warnings on omap-bandgap.c.
  
 
  Which checkpatch.pl warnings?
 
   +   omap_bandgap_writel(bg_ptr,
   +   rval-tshut_threshold,
   +  tsr-tshut_threshold);
 
  That's just whacky.
 
  Personally, I've never cared much about long lines, so I'd prefer
  to leave these as is until someone can break the functions up and
  remove them in a proper way instead of just shifting everything
  randomly to the left.
 
 
  Sorry, that was my default response without looking at the code.
 
  This is already broken up into small functions pretty nicely.  You
  might want to consider using shorter names.  For example
  omap_bandgap_writel() could be changed to obg_writel() and bg_ptr
  could be changed to just bg because it's obviously a pointer.
 
 Yeah, that's one option. Of course the deal is to find the proper
 balance between cryptic symbol names and code mangled / shifted to the
 left.
 

Another option would be to just let checkpatch complain.  It's a
perl script, not the king of us.  Do what looks the nicest to human
beings.

regards,
dan carpenter

--
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 11/11] ASoC: omap-pcm: Convert to use dmaengine

2012-09-12 Thread Peter Ujfalusi
On 09/12/2012 03:53 PM, Peter Ujfalusi wrote:
 I need to look at this, but at first look we do wait for the drain in
 omap_stop_dma(). We used to use omap_stop_dma/omap_start_dma for pause/resume
 operations.
 But sDMA also have a bit: CDPi: PAUSE_LINK_LIST which should do what we are
 looking for.
 Need to read the relevant parts of the TRM, but AFAIK we are using normal mode
 with linked list (self linking).
 I already have the patch for this, I just need to test it on HW.

We can get the PAUSE/RESUME work either:
1.
drivers/dma/omap-dma.c
static int omap_dma_pause(struct omap_chan *c)
 {
-   /* FIXME: not supported by platform private API */
-   return -EINVAL;
+   /* Only in cyclic mode */
+   if (!c-cyclic)
+   return -EINVAL;
+
+   if (!c-paused) {
+   omap_stop_dma(c-dma_ch);
+   c-paused = true;
+   }
+
+   return 0;
 }

 static int omap_dma_resume(struct omap_chan *c)
 {
-   /* FIXME: not supported by platform private API */
-   return -EINVAL;
+   /* Only in cyclic mode */
+   if (!c-cyclic)
+   return -EINVAL;
+
+   if (c-paused) {
+   omap_start_dma(c-dma_ch);
+   c-paused = false;
+   }
+
+   return 0;
 }


2.
arch/arm/plat-omap/dma.c
+void omap_pause_linked_dma(int lch)
+{
+   u32 l;
+   unsigned long flags;
+
+   local_irq_save(flags);
+   l = p-dma_read(CDP, lch);
+   l |= 0x80; /* PAUSE_LINK_LIST */
+   p-dma_write(l, CDP, lch);
+   local_irq_restore(flags);
+}
+EXPORT_SYMBOL(omap_pause_linked_dma);
+
+void omap_resume_linked_dma(int lch)
+{
+   u32 l;
+   unsigned long flags;
+
+   local_irq_save(flags);
+   l = p-dma_read(CDP, lch);
+   l = (~0x80); /* PAUSE_LINK_LIST */
+   p-dma_write(l, CDP, lch);
+   local_irq_restore(flags);
+}
+EXPORT_SYMBOL(omap_resume_linked_dma);

drivers/dma/omap-dma.c
 static int omap_dma_pause(struct omap_chan *c)
 {
-   /* FIXME: not supported by platform private API */
-   return -EINVAL;
+   /* Only in cyclic mode */
+   if (!c-cyclic)
+   return -EINVAL;
+
+   if (!c-paused) {
+   omap_pause_linked_dma(c-dma_ch);
+   c-paused = true;
+   }
+
+   return 0;
 }

 static int omap_dma_resume(struct omap_chan *c)
 {
-   /* FIXME: not supported by platform private API */
-   return -EINVAL;
+   /* Only in cyclic mode */
+   if (!c-cyclic)
+   return -EINVAL;
+
+   if (c-paused) {
+   omap_resume_linked_dma(c-dma_ch);
+   c-paused = false;
+   }
+
+   return 0;
 }


Both works fine (have tested it on BeagleBoard with mplayer).
With [1] we have identical way of dealing with the PAUSE/RESUME as we had
previously, so it is know to work fine on OMAP1/2/3/4/5

We have never used [2] in the past, but I think that is not going to work on
OMAP1 and OMAP2420. Also we need to add code to arch/arm/plat-omap/dma.c for
this...

I can resend the series with either of these to fix this regression caused by
the dmaengine conversion (after cleanup off course).

-- 
Péter
--
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] ARM: OMAP: rx51: Fix a section mismatch warn

2012-09-12 Thread Shubhrajyoti D
rx51_si4713_dev is referenced only from rx51_init_si4713.
So the memory for rx51_si4713_dev can be safely freed after init.
Also it references rx51_si4713_board_info which is __initdata_or_module.

fixes the below warning.

WARNING: vmlinux.o(.data+0x30958): Section mismatch in reference from the 
variable rx51_si4713_dev to the (unknown reference) .init.data:(unknown)
The variable rx51_si4713_dev references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

Reported-by: Wolfram Sang w.s...@pengutronix.de
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index df2534d..e2e1148 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -743,7 +743,7 @@ static struct radio_si4713_platform_data rx51_si4713_data 
__initdata_or_module =
.subdev_board_info = rx51_si4713_board_info,
 };
 
-static struct platform_device rx51_si4713_dev = {
+static struct platform_device rx51_si4713_dev __initdata_or_module = {
.name   = radio-si4713,
.id = -1,
.dev= {
-- 
1.7.5.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: [PATCHv7 00/23]I2C big cleanup

2012-09-12 Thread Shubhrajyoti Datta
On Wed, Sep 12, 2012 at 7:14 PM, Wolfram Sang w.s...@pengutronix.de wrote:
 On Wed, Sep 12, 2012 at 12:18:50PM +0200, Wolfram Sang wrote:

  I donot see the warning. Am I missing something?

 I deleted my logfiles already. Ignore it for now, if it comes up again
 with your new series, I will give a more detailed pointer.

 Sorry, the section mismatch was not related to I2C it seems:

Thanks for the report just sent a patch fixing that.


 WARNING: vmlinux.o(.data+0x30958): Section mismatch in reference from the 
 variable rx51_si4713_dev to the (unknown reference) .init.data:(unknown)
 The variable rx51_si4713_dev references
 the (unknown reference) __initdata (unknown)
 If the reference is valid then annotate the
 variable with __init* or __refdata (see linux/init.h) or name the variable:
 *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

 Got it with an allnoconfig and then selecting MMU and OMAP.

 Regards,

Wolfram

 --
 Pengutronix e.K.   | Wolfram Sang|
 Industrial Linux Solutions | http://www.pengutronix.de/  |

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iEYEARECAAYFAlBQkbsACgkQD27XaX1/VRtbuACgkBa0lOIN551eec9TSetVPsCE
 Ew0AoKizKon3DIILpERWJIwzAXdgRVDc
 =T4Yq
 -END PGP SIGNATURE-

--
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] ARM: mm: ADD descriptor string to CONFIG_DMA_ADDR_64BIT_T

2012-09-12 Thread Russell King - ARM Linux
On Wed, Sep 12, 2012 at 06:50:00PM +0530, R, Sricharan wrote:
 Hi,
 On Wed, Sep 12, 2012 at 6:27 PM, Shilimkar, Santosh
 santosh.shilim...@ti.com wrote:
  On Wed, Sep 12, 2012 at 6:16 PM, Cyril Chemparathy cy...@ti.com wrote:
 
  On 9/12/2012 1:50 AM, R Sricharan wrote:
 
  Even if CONFIG_DMA_ADDR_64BIT_T is enabled by the defconfig,
  the feature is not getting selected.
  Adding a string description in the Kconfig resolves this.
 
  But not sure if this is the right way to fix this.
 
 
  Shouldn't you be selecting this in your 64-bit dma address capable arch
  instead?
 
  Yes. The selection to enable  CONFIG_DMA_ADDR_64BIT_T happens
  in the arch which needs it. Since this option was made as simple bool,
  looks like because of some KCONFIG magic, it was not getting selected.
  Adding some help text does fix the issue and thats is the patch all about.
 
   Correct. So even if you select this in the arch/defconfig,

That is correct behaviour.

You need an explicit select DMA_ADDR_64BIT_T somewhere in a Kconfig file
to make it happen.

Editing defconfigs is not how we enable these options.
--
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


  1   2   >