date:20110629

* Grazvydas Ignotas nota...@gmail.com [110603 15:01]:
 On Sat, Jun 4, 2011 at 12:14 AM, Vimal Singh vimal.neww...@gmail.com wrote:
  On Sat, Jun 4, 2011 at 1:26 AM, Grazvydas Ignotas nota...@gmail.com wrote:
 
  -static int omap2_nand_gpmc_retime(void)
  +static int omap2_nand_gpmc_retime(struct omap_nand_platform_data 
  *gpmc_nand_data)
   {
         struct gpmc_timings t;
         int err;
  @@ -83,13 +81,11 @@ static int omap2_nand_gpmc_retime(void)
         return 0;
   }
 
  -int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
  +int __init gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data)
   {
         int err = 0;
         struct device *dev = gpmc_nand_device.dev;
 
  -       gpmc_nand_data = _nand_data;
  -       gpmc_nand_data-nand_setup = omap2_nand_gpmc_retime;
 
  Purpose of doing this was to be able to utilise
  'omap2_nand_gpmc_retime', when DVFS is ready to use it,
  for changing timing parameter dynamically when a frequency change is done.
 
 Well but it seems currently ...retime() only does single static
 configuration, I guess when it's updated to do DVFS stuff callback can
 easily be added back..

Applying this into devel-cleanup.

Regards,

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

Re: [PATCH] OMAP: board-omap3evm: Fix compillation error

* Peter Ujfalusi peter.ujfal...@ti.com [110628 03:12]:
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
 
 Hello Tony,
 
 While rebasing my series on top of your devel-cleanup branch,
 I found this compillation error.
 You can pick it right away, or I can queue this within my series.
 But I still waiting for Samuel's saying on the series, so it might
 be faster if you just pick this, I'll rebase my series before I
 send you the pull request anyways.

Thanks, applying into devel-fixes.

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

[PATCHv4 0/9] PRCM chain interrupt handling

Sorry for the delay, I had still some problems with the OMAP3 wakeup handling
with this set from suspend, but now this one works again. This set has been
tested on OMAP3 beagleboard, with suspend and cpuidle, with and without
off-mode. Appears to be working in all cases.

Main differences between previous version of the set:
- OMAP3 wakeup clearing moved back to PRCM interrupt (due to request)
  This caused problems with wakeup from suspend, and was fixed with patch #9
- PAD checks use now omap mux code
- PAD wakeups are enabled automatically by hwmod code for defined pads
- All other comments received for previous set should be taken care of
  (hopefully I didn't forget anything)

This patch set contains a number of testing purposes patches that should
probably not be integrated (tagged as TEMP.) They are mainly provided as
test setup for proof of consept.

-Tero


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. 
Kotipaikka: Helsinki
 

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

[PATCHv4 2/9] PRCM: Add support for PAD wakeup interrupts

PRCM interrupt handler will now parse registered pads to see whether there
is an active wakeup event. If there is a pending wakeup event, the registered
ISR will be called.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/prcm.c |   94 
 arch/arm/plat-omap/include/plat/prcm.h |5 ++
 2 files changed, 99 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 794e451..6b603eb 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -30,6 +30,7 @@
 #include plat/common.h
 #include plat/prcm.h
 #include plat/irqs.h
+#include plat/omap_hwmod.h
 
 #include clock.h
 #include clock2xxx.h
@@ -40,6 +41,7 @@
 #include prm-regbits-24xx.h
 #include prm-regbits-44xx.h
 #include control.h
+#include mux.h
 
 void __iomem *prm_base;
 void __iomem *cm_base;
@@ -50,6 +52,15 @@ void __iomem *cm2_base;
 /* Setup for the interrupt handling based on used platform */
 static struct omap_prcm_irq_setup *irq_setup;
 
+/* PAD handlers list */
+struct pad_def {
+   struct omap_device_pad *pad;
+   unsigned int irq;
+   struct list_head node;
+};
+
+static LIST_HEAD(pad_handler_list);
+
 static void prcm_irq_ack(struct irq_data *data)
 {
unsigned int prcm_irq = data-irq - OMAP_PRCM_IRQ_BASE;
@@ -71,6 +82,24 @@ static void prcm_irq_unmask(struct irq_data *data)
 static struct irq_chip_generic *prcm_irq_chips[OMAP_PRCM_MAX_NR_PENDING_REG];
 
 /*
+ * Handler for PAD irqs, called from PRCM interrupt handler
+ */
+static void omap_prcm_handle_pad_irqs(void)
+{
+   struct pad_def *def;
+   u16 val = 0;
+   list_for_each_entry(def, pad_handler_list, node) {
+   /* Read padconf value */
+   val = omap_mux_read(def-pad-partition,
+   def-pad-mux-reg_offset);
+
+   /* If pad wakeupevent is active, call registered ISR */
+   if (val  OMAP3_PADCONF_WAKEUPEVENT0)
+   generic_handle_irq(def-irq);
+   }
+}
+
+/*
  * PRCM Interrupt Handler
  *
  * The PRM_IRQSTATUS_MPU register indicates if there are any pending
@@ -92,6 +121,9 @@ static void prcm_irq_handler(unsigned int irq, struct 
irq_desc *desc)
unsigned long pending[OMAP_PRCM_MAX_NR_PENDING_REG];
struct irq_chip *chip = irq_desc_get_chip(desc);
 
+   /* Handle PAD events first, we don't want to ack them before parse */
+   omap_prcm_handle_pad_irqs();
+
/*
 * Loop until all pending irqs are handled, since
 * generic_handle_irq(), called by prcm_irq_handle_virtirqs()
@@ -139,6 +171,68 @@ int omap_prcm_event_to_irq(const char *name)
 }
 
 /*
+ * Register interrupt handler for a given omap_hwmod_mux. When the PRCM
+ * interrupt handler detects wakeupevent on the corresponding pad, the
+ * ISR will be called.
+ */
+int omap_prcm_register_pad_irqs(struct omap_hwmod_mux_info *mux,
+   unsigned int irq)
+{
+   struct pad_def *def;
+   int i;
+   u16 val;
+
+   if (!mux)
+   return 0;
+
+   for (i = 0; i  mux-nr_pads; i++) {
+   if (!(mux-pads[i].enable  OMAP_PIN_INPUT))
+   continue;
+
+   def = kmalloc(sizeof(struct pad_def), GFP_ATOMIC);
+   if (!def)
+   return -ENOMEM;
+
+   def-pad = mux-pads + i;
+   def-irq = irq;
+
+   /* Enable pad wakeup */
+   val = omap_mux_read(def-pad-partition,
+   def-pad-mux-reg_offset);
+   val |= OMAP_WAKEUP_EN;
+   omap_mux_write(def-pad-partition, val,
+   def-pad-mux-reg_offset);
+
+   list_add(def-node, pad_handler_list);
+   }
+   return 0;
+}
+
+/*
+ * Unregister pad irqs associated with a hwmod mux
+ */
+void omap_prcm_unregister_pad_irqs(struct omap_hwmod_mux_info *mux)
+{
+   struct pad_def *def;
+   int i;
+   u16 val;
+
+   list_for_each_entry(def, pad_handler_list, node)
+   for (i = 0; i  mux-nr_pads; i++)
+   if (def-pad == mux-pads + i) {
+   list_del(def-node);
+
+   /* Disable pad wakeup */
+   val = omap_mux_read(def-pad-partition,
+   def-pad-mux-reg_offset);
+   val = ~OMAP_WAKEUP_EN;
+   omap_mux_write(def-pad-partition, val,
+   def-pad-mux-reg_offset);
+   kfree(def);
+   }
+}
+
+/*
  * Prepare the array of PRCM events corresponding to the current SoC,
  * and set-up the chained interrupt handler mechanism.
  */
diff --git a/arch/arm/plat-omap/include/plat/prcm.h 
b/arch/arm/plat-omap/include/plat/prcm.h
index 205b9b1..7987819 100644
---

[PATCHv4 3/9] OMAP3: PM: remove serial resume / idle calls from idle path

This is no longer needed as it will be handled within serial driver itself.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/pm34xx.c |   19 ---
 1 files changed, 0 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 89cf027..e626a3d 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -335,18 +335,9 @@ void omap_sram_idle(void)
omap3_enable_io_chain();
}
 
-   /* Block console output in case it is on one of the OMAP UARTs */
-   if (!is_suspending())
-   if (per_next_state  PWRDM_POWER_ON ||
-   core_next_state  PWRDM_POWER_ON)
-   if (!console_trylock())
-   goto console_still_active;
-
/* PER */
if (per_next_state  PWRDM_POWER_ON) {
per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
-   omap_uart_prepare_idle(2);
-   omap_uart_prepare_idle(3);
omap2_gpio_prepare_for_idle(per_going_off);
if (per_next_state == PWRDM_POWER_OFF)
omap3_per_save_context();
@@ -354,8 +345,6 @@ void omap_sram_idle(void)
 
/* CORE */
if (core_next_state  PWRDM_POWER_ON) {
-   omap_uart_prepare_idle(0);
-   omap_uart_prepare_idle(1);
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_cm_save_context();
@@ -402,8 +391,6 @@ void omap_sram_idle(void)
omap3_sram_restore_context();
omap2_sms_restore_context();
}
-   omap_uart_resume_idle(0);
-   omap_uart_resume_idle(1);
if (core_next_state == PWRDM_POWER_OFF)
omap2_prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF_MASK,
   OMAP3430_GR_MOD,
@@ -417,14 +404,8 @@ void omap_sram_idle(void)
omap2_gpio_resume_after_idle();
if (per_prev_state == PWRDM_POWER_OFF)
omap3_per_restore_context();
-   omap_uart_resume_idle(2);
-   omap_uart_resume_idle(3);
}
 
-   if (!is_suspending())
-   console_unlock();
-
-console_still_active:
/* Disable IO-PAD and IO-CHAIN wakeup */
if (omap3_has_io_wakeup() 
(per_next_state  PWRDM_POWER_ON ||
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. 
Kotipaikka: Helsinki
 

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

[PATCHv4 4/9] TEMP: OMAP3: Serial: Made serial to work properly with PRCM chain handler

This patch is just a temporary hack to allow serial to work properly with
the PRCM chain handler. Should be replaced with a proper implementation.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/serial.c |   28 +---
 drivers/tty/serial/omap-serial.c |8 
 2 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 1ac361b..067a86b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -39,6 +39,7 @@
 #include plat/dma.h
 #include plat/omap_hwmod.h
 #include plat/omap_device.h
+#include plat/prcm.h
 
 #include prm2xxx_3xxx.h
 #include pm.h
@@ -380,6 +381,7 @@ static void omap_uart_allow_sleep(struct omap_uart_state 
*uart)
omap_uart_smart_idle_enable(uart, 1);
uart-can_sleep = 1;
del_timer(uart-timer);
+   omap_uart_disable_clocks(uart);
 }
 
 static void omap_uart_idle_timer(unsigned long data)
@@ -391,35 +393,23 @@ static void omap_uart_idle_timer(unsigned long data)
 
 void omap_uart_prepare_idle(int num)
 {
-   struct omap_uart_state *uart;
-
-   list_for_each_entry(uart, uart_list, node) {
-   if (num == uart-num  uart-can_sleep) {
-   omap_uart_disable_clocks(uart);
-   return;
-   }
-   }
 }
 
 void omap_uart_resume_idle(int num)
 {
struct omap_uart_state *uart;
+   u32 wkst;
 
list_for_each_entry(uart, uart_list, node) {
if (num == uart-num  uart-can_sleep) {
-   omap_uart_enable_clocks(uart);
+   omap_uart_block_sleep(uart);
 
-   /* Check for IO pad wakeup */
-   if (cpu_is_omap34xx()  uart-padconf) {
-   u16 p = omap_ctrl_readw(uart-padconf);
-
-   if (p  OMAP3_PADCONF_WAKEUPEVENT0)
-   omap_uart_block_sleep(uart);
+   /* Check for normal UART wakeup (and clear it) */
+   if (uart-wk_st  uart-wk_mask) {
+   wkst = __raw_readl(uart-wk_st)  uart-wk_mask;
+   if (wkst)
+   __raw_writel(wkst, uart-wk_st);
}
-
-   /* Check for normal UART wakeup */
-   if (__raw_readl(uart-wk_st)  uart-wk_mask)
-   omap_uart_block_sleep(uart);
return;
}
}
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 47cadf4..bd6ae02 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -261,6 +261,8 @@ static void serial_omap_start_tx(struct uart_port *port)
unsigned int start;
int ret = 0;
 
+   omap_uart_resume_idle(up-pdev-id);
+
if (!up-use_dma) {
serial_omap_enable_ier_thri(up);
return;
@@ -354,6 +356,8 @@ static inline irqreturn_t serial_omap_irq(int irq, void 
*dev_id)
unsigned int iir, lsr;
unsigned long flags;
 
+   omap_uart_resume_idle(up-pdev-id);
+
iir = serial_in(up, UART_IIR);
if (iir  UART_IIR_NO_INT)
return IRQ_NONE;
@@ -641,6 +645,8 @@ serial_omap_set_termios(struct uart_port *port, struct 
ktermios *termios,
unsigned long flags = 0;
unsigned int baud, quot;
 
+   omap_uart_resume_idle(up-pdev-id);
+
switch (termios-c_cflag  CSIZE) {
case CS5:
cval = UART_LCR_WLEN5;
@@ -947,6 +953,8 @@ serial_omap_console_write(struct console *co, const char *s,
unsigned int ier;
int locked = 1;
 
+   omap_uart_resume_idle(up-pdev-id);
+
local_irq_save(flags);
if (up-port.sysrq)
locked = 0;
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. 
Kotipaikka: Helsinki
 

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

[PATCHv4 1/9] omap: prcm: switch to a chained IRQ handler mechanism

Introduce a chained interrupt handler mechanism for the PRCM
interrupt, so that individual PRCM event can cleanly be handled by
handlers in separate drivers. We do this by introducing PRCM event
names, which are then matched to the particular PRCM interrupt bit
depending on the specific OMAP SoC being used.

arch/arm/mach-omap2/prcm.c implements the chained interrupt mechanism
itself, with individual PRCM events for OMAP3 and OMAP4 being
described in arch/arm/mach-omap2/prcm3xxx.c and
arch/arm/mach-omap2/prcm4xxx.c respectively. At initialization time,
the set of PRCM events is filtered against the SoC on which we are
running, keeping only the ones that are actually useful. All the logic
is written to be generic with regard to OMAP3/OMAP4, even though OMAP3
has single PRCM event registers and OMAP4 has two PRCM event
registers.

Patch tested on OMAP3 beagleboard.

Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Avinash.H.M avinas...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Govindraj.R govindraj.r...@ti.com
---
 arch/arm/mach-omap2/Makefile   |4 +
 arch/arm/mach-omap2/pm34xx.c   |  116 --
 arch/arm/mach-omap2/prcm.c |  163 ++
 arch/arm/mach-omap2/prcm3xxx.c |  141 ++
 arch/arm/mach-omap2/prcm4xxx.c |  170 
 arch/arm/plat-omap/include/plat/irqs.h |9 ++-
 arch/arm/plat-omap/include/plat/prcm.h |   43 
 7 files changed, 569 insertions(+), 77 deletions(-)
 create mode 100644 arch/arm/mach-omap2/prcm3xxx.c
 create mode 100644 arch/arm/mach-omap2/prcm4xxx.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5024064..339d2d4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -39,6 +39,10 @@ AFLAGS_sram242x.o:=-Wa,-march=armv6
 AFLAGS_sram243x.o  :=-Wa,-march=armv6
 AFLAGS_sram34xx.o  :=-Wa,-march=armv7-a
 
+# PRCM
+obj-$(CONFIG_ARCH_OMAP3)+= prcm3xxx.o
+obj-$(CONFIG_ARCH_OMAP4)+= prcm4xxx.o
+
 # Pin multiplexing
 obj-$(CONFIG_SOC_OMAP2420) += mux2420.o
 obj-$(CONFIG_SOC_OMAP2430) += mux2430.o
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 96a7624..89cf027 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -64,6 +64,9 @@ static inline bool is_suspending(void)
 }
 #endif
 
+static int prcm_io_irq;
+static int prcm_wkup_irq;
+
 /* Scratchpad offsets */
 #define OMAP343X_TABLE_ADDRESS_OFFSET 0xc4
 #define OMAP343X_TABLE_VALUE_OFFSET   0xc0
@@ -240,75 +243,16 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
return c;
 }
 
-static int _prcm_int_handle_wakeup(void)
+static irqreturn_t _prcm_int_handle_wakeup(int irq, void *unused)
 {
-   int c;
-
-   c = prcm_clear_mod_irqs(WKUP_MOD, 1);
-   c += prcm_clear_mod_irqs(CORE_MOD, 1);
-   c += prcm_clear_mod_irqs(OMAP3430_PER_MOD, 1);
+   prcm_clear_mod_irqs(WKUP_MOD, 1);
+   prcm_clear_mod_irqs(CORE_MOD, 1);
+   prcm_clear_mod_irqs(OMAP3430_PER_MOD, 1);
if (omap_rev()  OMAP3430_REV_ES1_0) {
-   c += prcm_clear_mod_irqs(CORE_MOD, 3);
-   c += prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
+   prcm_clear_mod_irqs(CORE_MOD, 3);
+   prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
}
 
-   return c;
-}
-
-/*
- * PRCM Interrupt Handler
- *
- * The PRM_IRQSTATUS_MPU register indicates if there are any pending
- * interrupts from the PRCM for the MPU. These bits must be cleared in
- * order to clear the PRCM interrupt. The PRCM interrupt handler is
- * implemented to simply clear the PRM_IRQSTATUS_MPU in order to clear
- * the PRCM interrupt. Please note that bit 0 of the PRM_IRQSTATUS_MPU
- * register indicates that a wake-up event is pending for the MPU and
- * this bit can only be cleared if the all the wake-up events latched
- * in the various PM_WKST_x registers have been cleared. The interrupt
- * handler is implemented using a do-while loop so that if a wake-up
- * event occurred during the processing of the prcm interrupt handler
- * (setting a bit in the corresponding PM_WKST_x register and thus
- * preventing us from clearing bit 0 of the PRM_IRQSTATUS_MPU register)
- * this would be handled.
- */
-static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
-{
-   u32 irqenable_mpu, irqstatus_mpu;
-   int c = 0;
-
-   irqenable_mpu = omap2_prm_read_mod_reg(OCP_MOD,
-OMAP3_PRM_IRQENABLE_MPU_OFFSET);
-   irqstatus_mpu = omap2_prm_read_mod_reg(OCP_MOD,
-OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
-   irqstatus_mpu = irqenable_mpu;
-
-   do {

[PATCHv4 5/9] TEMP: Serial: Added mux support

This should be replaced with a proper implementation.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/serial.c |   66 -
 1 files changed, 64 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 067a86b..822c9b8 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -851,17 +851,79 @@ void __init omap_serial_init_port(struct omap_board_data 
*bdata)
  * can call this function when they want to have default behaviour
  * for serial ports (e.g initialize them all as serial ports).
  */
+
+struct serial_mux_conf {
+   char *name;
+   int omap3_mux;
+   int omap4_mux;
+};
+
+#define OMAP3_SERIAL_MUX_IN_PU (OMAP_PIN_INPUT_PULLUP | \
+   OMAP_PIN_OFF_INPUT_PULLDOWN | OMAP_OFFOUT_EN | OMAP_MUX_MODE0)
+#define OMAP3_SERIAL_MUX_IN_PD (OMAP_PIN_INPUT_PULLDOWN | \
+   OMAP_PIN_OFF_INPUT_PULLDOWN | OMAP_OFFOUT_EN | OMAP_MUX_MODE0)
+#define OMAP3_SERIAL_MUX_IN (OMAP_PIN_INPUT | OMAP_PIN_OFF_INPUT_PULLDOWN | \
+   OMAP_OFFOUT_EN | OMAP_MUX_MODE0)
+#define OMAP3_SERIAL_MUX_OUT (OMAP_PIN_OUTPUT | OMAP_OFF_EN | OMAP_MUX_MODE0)
+#define OMAP4_SERIAL_MUX_IN_PU (OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0)
+#define OMAP4_SERIAL_MUX_OUT (OMAP_PIN_OUTPUT | OMAP_MUX_MODE0)
+#define OMAP4_SERIAL_MUX_IN (OMAP_PIN_INPUT | OMAP_MUX_MODE0)
+
+#define OMAP_SERIAL_NUM_PADS_PER_PORT 4
+
+static const struct serial_mux_conf serial_mux_data[] = {
+   { uart1_cts.uart1_cts, OMAP3_SERIAL_MUX_IN, 0, },
+   { uart1_rts.uart1_rts, OMAP3_SERIAL_MUX_OUT, 0, },
+   { uart1_rx.uart1_rx, OMAP3_SERIAL_MUX_IN, 0, },
+   { uart1_tx.uart1_tx, OMAP3_SERIAL_MUX_OUT, 0, },
+   { uart2_cts.uart2_cts, OMAP3_SERIAL_MUX_IN_PU,
+   OMAP4_SERIAL_MUX_IN_PU, },
+   { uart2_rts.uart2_rts, OMAP3_SERIAL_MUX_OUT, OMAP4_SERIAL_MUX_OUT, },
+   { uart2_rx.uart2_rx, OMAP3_SERIAL_MUX_IN, OMAP4_SERIAL_MUX_IN_PU, },
+   { uart2_tx.uart2_tx, OMAP3_SERIAL_MUX_OUT, OMAP4_SERIAL_MUX_OUT },
+   { uart3_cts_rctx.uart3_cts_rctx, OMAP3_SERIAL_MUX_IN_PD,
+   OMAP4_SERIAL_MUX_IN_PU, },
+   { uart3_rts_sd.uart3_rts_sd, OMAP3_SERIAL_MUX_OUT,
+   OMAP4_SERIAL_MUX_OUT, },
+   { uart3_rx_irrx.uart3_rx_irrx, OMAP3_SERIAL_MUX_IN,
+   OMAP4_SERIAL_MUX_IN, },
+   { uart3_tx_irtx.uart3_tx_irtx, OMAP3_SERIAL_MUX_OUT,
+   OMAP4_SERIAL_MUX_OUT, },
+   { uart4_rx.uart4_rx, 0, OMAP4_SERIAL_MUX_IN, },
+   { uart4_tx.uart4_tx, 0, OMAP4_SERIAL_MUX_OUT, },
+   { NULL, 0, 0, },
+   { NULL, 0, 0, },
+};
+
 void __init omap_serial_init(void)
 {
struct omap_uart_state *uart;
struct omap_board_data bdata;
+   struct omap_device_pad *pads;
+   int idx;
+   int i;
 
+   pads = kmalloc(sizeof(struct omap_device_pad) * 4, GFP_KERNEL);
list_for_each_entry(uart, uart_list, node) {
bdata.id = uart-num;
bdata.flags = 0;
-   bdata.pads = NULL;
bdata.pads_cnt = 0;
+   bdata.pads = pads;
+
+   for (i = 0; i  OMAP_SERIAL_NUM_PADS_PER_PORT; i++) {
+   idx = bdata.id * OMAP_SERIAL_NUM_PADS_PER_PORT + i;
+   pads[i].name = serial_mux_data[idx].name;
+   pads[i].enable = 0;
+   if (cpu_is_omap34xx())
+   pads[i].enable = serial_mux_data[idx].omap3_mux;
+   if (cpu_is_omap44xx())
+   pads[i].enable = serial_mux_data[idx].omap4_mux;
+   if (pads[i].enable)
+   bdata.pads_cnt++;
+   }
+   if (bdata.pads_cnt == 0)
+   bdata.pads = NULL;
omap_serial_init_port(bdata);
-
}
+   kfree(pads);
 }
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. 
Kotipaikka: Helsinki
 

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

[PATCHv4 6/9] OMAP device: change pr_warnings to pr_debugs

Prevents a hang when omap_device would want to print something for
serial console device while enabling / disabling its clocks.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/plat-omap/omap_device.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 49fc0df..c2b8461 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -146,12 +146,12 @@ static int _omap_device_activate(struct omap_device *od, 
u8 ignore_lat)
odpl-activate_lat_worst = act_lat;
if (odpl-flags  OMAP_DEVICE_LATENCY_AUTO_ADJUST) {
odpl-activate_lat = act_lat;
-   pr_warning(omap_device: %s.%d: new worst case 
+   pr_debug(omap_device: %s.%d: new worst case 
   activate latency %d: %llu\n,
   od-pdev.name, od-pdev.id,
   od-pm_lat_level, act_lat);
} else
-   pr_warning(omap_device: %s.%d: activate 
+   pr_debug(omap_device: %s.%d: activate 
   latency %d higher than exptected. 
   (%llu  %d)\n,
   od-pdev.name, od-pdev.id,
@@ -214,12 +214,12 @@ static int _omap_device_deactivate(struct omap_device 
*od, u8 ignore_lat)
odpl-deactivate_lat_worst = deact_lat;
if (odpl-flags  OMAP_DEVICE_LATENCY_AUTO_ADJUST) {
odpl-deactivate_lat = deact_lat;
-   pr_warning(omap_device: %s.%d: new worst case 
+   pr_debug(omap_device: %s.%d: new worst case 
   deactivate latency %d: %llu\n,
   od-pdev.name, od-pdev.id,
   od-pm_lat_level, deact_lat);
} else
-   pr_warning(omap_device: %s.%d: deactivate 
+   pr_debug(omap_device: %s.%d: deactivate 
   latency %d higher than exptected. 
   (%llu  %d)\n,
   od-pdev.name, od-pdev.id,
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. 
Kotipaikka: Helsinki
 

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

[PATCHv4 7/9] OMAP: hwmod: enable / disable pad wakeups for a module dynamically

PRCM chain interrupt registration is done now as part of
omap_hwmod_enable_wakeup() and omap_hwmod_disable_wakeup() calls. This
allows module ISR:s to be called when the module is idle but an IO_PAD
event is detected on the module input pads.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 293fa6c..f12fe89 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2123,6 +2123,7 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
v = oh-_sysc_cache;
_enable_wakeup(oh, v);
_write_sysconfig(v, oh);
+   omap_prcm_register_pad_irqs(oh-mux, oh-mpu_irqs[0].irq);
spin_unlock_irqrestore(oh-_lock, flags);
 
return 0;
@@ -2153,6 +2154,7 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
v = oh-_sysc_cache;
_disable_wakeup(oh, v);
_write_sysconfig(v, oh);
+   omap_prcm_unregister_pad_irqs(oh-mux);
spin_unlock_irqrestore(oh-_lock, flags);
 
return 0;
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. 
Kotipaikka: Helsinki
 

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

[PATCHv4 8/9] TEMP: OMAP: serial: remove padconf hacks

These are no longer needed as omap_hwmod takes care of multiplexing of pads.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/serial.c |   25 +
 1 files changed, 1 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 822c9b8..f8fafdd 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -73,7 +73,6 @@ struct omap_uart_state {
void __iomem *wk_st;
void __iomem *wk_en;
u32 wk_mask;
-   u32 padconf;
u32 dma_enabled;
 
struct clk *ick;
@@ -309,13 +308,6 @@ static void omap_uart_enable_wakeup(struct omap_uart_state 
*uart)
v |= uart-wk_mask;
__raw_writel(v, uart-wk_en);
}
-
-   /* Ensure IOPAD wake-enables are set */
-   if (cpu_is_omap34xx()  uart-padconf) {
-   u16 v = omap_ctrl_readw(uart-padconf);
-   v |= OMAP3_PADCONF_WAKEUPENABLE0;
-   omap_ctrl_writew(v, uart-padconf);
-   }
 }
 
 static void omap_uart_disable_wakeup(struct omap_uart_state *uart)
@@ -326,13 +318,6 @@ static void omap_uart_disable_wakeup(struct 
omap_uart_state *uart)
v = ~uart-wk_mask;
__raw_writel(v, uart-wk_en);
}
-
-   /* Ensure IOPAD wake-enables are cleared */
-   if (cpu_is_omap34xx()  uart-padconf) {
-   u16 v = omap_ctrl_readw(uart-padconf);
-   v = ~OMAP3_PADCONF_WAKEUPENABLE0;
-   omap_ctrl_writew(v, uart-padconf);
-   }
 }
 
 static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
@@ -479,7 +464,6 @@ static void omap_uart_idle_init(struct omap_uart_state 
*uart)
if (cpu_is_omap34xx()  !cpu_is_ti816x()) {
u32 mod = (uart-num  1) ? OMAP3430_PER_MOD : CORE_MOD;
u32 wk_mask = 0;
-   u32 padconf = 0;
 
/* XXX These PRM accesses do not belong here */
uart-wk_en = OMAP34XX_PRM_REGADDR(mod, PM_WKEN1);
@@ -487,23 +471,18 @@ static void omap_uart_idle_init(struct omap_uart_state 
*uart)
switch (uart-num) {
case 0:
wk_mask = OMAP3430_ST_UART1_MASK;
-   padconf = 0x182;
break;
case 1:
wk_mask = OMAP3430_ST_UART2_MASK;
-   padconf = 0x17a;
break;
case 2:
wk_mask = OMAP3430_ST_UART3_MASK;
-   padconf = 0x19e;
break;
case 3:
wk_mask = OMAP3630_ST_UART4_MASK;
-   padconf = 0x0d2;
break;
}
uart-wk_mask = wk_mask;
-   uart-padconf = padconf;
} else if (cpu_is_omap24xx()) {
u32 wk_mask = 0;
u32 wk_en = PM_WKEN1, wk_st = PM_WKST1;
@@ -533,7 +512,6 @@ static void omap_uart_idle_init(struct omap_uart_state 
*uart)
uart-wk_en = NULL;
uart-wk_st = NULL;
uart-wk_mask = 0;
-   uart-padconf = 0;
}
 
uart-irqflags |= IRQF_SHARED;
@@ -833,8 +811,7 @@ void __init omap_serial_init_port(struct omap_board_data 
*bdata)
 
console_unlock();
 
-   if ((cpu_is_omap34xx()  uart-padconf) ||
-   (uart-wk_en  uart-wk_mask)) {
+   if (uart-oh-mux || (uart-wk_en  uart-wk_mask)) {
device_init_wakeup(od-pdev.dev, true);
DEV_CREATE_FILE(od-pdev.dev, dev_attr_sleep_timeout);
}
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. 
Kotipaikka: Helsinki
 

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

[PATCHv4 9/9] OMAP3: PM: Disable / enable PRCM chain interrupts during wakeup from suspend

This prevents system hang while attempting to access suspended console.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/pm34xx.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e626a3d..dae0a8a 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -418,6 +418,10 @@ void omap_sram_idle(void)
pwrdm_post_transition();
 
clkdm_allow_idle(mpu_pwrdm-pwrdm_clkdms[0]);
+   if (suspend_state != PM_SUSPEND_ON) {
+   disable_irq(prcm_io_irq);
+   disable_irq(prcm_wkup_irq);
+   }
 }
 
 int omap3_can_sleep(void)
@@ -524,6 +528,8 @@ static void omap3_pm_end(void)
suspend_state = PM_SUSPEND_ON;
omap_uart_enable_irqs(1);
enable_hlt();
+   enable_irq(prcm_io_irq);
+   enable_irq(prcm_wkup_irq);
return;
 }
 
-- 
1.7.4.1


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. 
Kotipaikka: Helsinki
 

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

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

On Wed, Jun 29, 2011 at 5:02 AM, Kevin Hilman khil...@ti.com wrote:
 +Rajendra

 Balaji T K balaj...@ti.com writes:

 add runtime pm support to HSMMC host controller
 Use runtime pm API to enable/disable HSMMC clock
 Use runtime autosuspend APIs to enable auto suspend delay

 Based on OMAP HSMMC runtime implementation by Kevin Hilman, Kishore Kadiyala

 Signed-off-by: Balaji T K balaj...@ti.com

 I tried to test this series along with Benoit's clkdm/modulemode/hwmod
 cleanups and something strange is happening on OMAP4.

 First, this series by itself is working as I would expect, but testing
 in combination with Benoit's series, it's different...

 First, I'm using Benoit's branch:

       git://gitorious.org/omap-pm/linux.git for_3.0.1/7_hwmod_modulemode

 in combination with your series.

 I've also reverted these two commits:

   OMAP4: PM: TEMP: Prevent l3init from idling/force sleep
   OMAP3+: hwmod data: TEMP: Do not idle MMC1  MMC2 after boot

 which are temporary workarounds for not having MMC runtime PM.

 I turned the dev_dbg calls in the runtime PM callbacks into dev_info
 callbacks to see exactly when the device is enabled/disabled via runtime
 PM.

 To my surprise, I didn't see the device being enabled/disabled when
 writing do the device.

I tried for_3.0.1/7_hwmod_modulemode as you mentioned above,
changing dev_dbg to dev_err and I am not observing the delayed write
during umount. Can you let me know if the files are there in MMC after
remounting ?

 Any ideas why the same isn't happening when used with Benoit's series?

 Kevin

 P.S. note that the debug messages don't quite match.  One says 'host:
 enabled' the other says 'disabled' (without the host: prefix.)  making
 the prefixes match would be more readable.

Ok, Will align dev_dbg prints.
--
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 1/2] omap: mcbsp: Drop SPI mode support

* Péter Ujfalusi peter.ujfal...@ti.com [110614 05:34]:
 On Tuesday 14 June 2011 13:23:51 Jarkko Nikula wrote:
  We haven't seen any use for the SPI API in McBSP driver over the years. More
  over, Peter Ujfalusi peter.ujfal...@ti.com noticed that SPI mode is not
  even supported since OMAP2430 so it's very unlikely that we'll see any use
  for it in the future either.
  
  Signed-off-by: Jarkko Nikula jhnik...@gmail.com
 
 Either now or later, but for both:
 
 Acked-by: Peter Ujfalusi peter.ujfal...@ti.com

Applying both of these into devel-cleanup branch.

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

Re: [PATCH 1/4] cbus: move plat/cbus.h to linux/platform_data/cbus.h

* Felipe Balbi ba...@ti.com [110616 04:22]:
 it's a much more sensible location for that
 sort of thing.

Applying all four to cbus branch.

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

[PATCH 0/2] RETU meets Sparse IRQ

now with Sparse IRQ numbering, we don't need
to add a bunch of defines in plat/irqs.h

Compile tested with omap2plus_defconfig (+cbus)
and omap1_defconfig (+cbus).

Felipe Balbi (2):
  cbus: retu: use sparse IRQ numbering
  cbus: retu: stop polluting plat/irqs.h

 arch/arm/mach-omap1/board-nokia770.c   |2 --
 arch/arm/mach-omap2/board-n8x0.c   |2 --
 arch/arm/plat-omap/include/plat/irqs.h |   10 +-
 drivers/cbus/retu.c|   25 -
 include/linux/platform_data/cbus.h |2 --
 5 files changed, 17 insertions(+), 24 deletions(-)

-- 
1.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 1/2] cbus: retu: use sparse IRQ numbering

there's no need to pass a bunch of IRQ
bases down to drivers, we can use
irq_alloc_descs() for that and put the
sparse IRQ numbering scheme to work for
us.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/cbus/retu.c |   25 -
 1 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index 708b811..b58c6e5 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -441,9 +441,15 @@ static int __init retu_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, retu);
 
+   ret = irq_alloc_descs(-1, 0, MAX_RETU_IRQ_HANDLERS, 0);
+   if (ret  0) {
+   dev_err(pdev-dev, failed to allocate IRQ descs\n);
+   goto err1;
+   }
+
retu-irq   = platform_get_irq(pdev, 0);
-   retu-irq_base  = pdata-irq_base;
-   retu-irq_end   = pdata-irq_end;
+   retu-irq_base  = ret;
+   retu-irq_end   = ret + MAX_RETU_IRQ_HANDLERS;
retu-devid = pdata-devid;
retu-dev   = pdev-dev;
the_retu= retu;
@@ -467,7 +473,7 @@ static int __init retu_probe(struct platform_device *pdev)
  retu, retu);
if (ret  0) {
dev_err(pdev-dev, Unable to register IRQ handler\n);
-   goto err1;
+   goto err2;
}
 
irq_set_irq_wake(retu-irq, 1);
@@ -478,16 +484,19 @@ static int __init retu_probe(struct platform_device *pdev)
ret = retu_allocate_children(pdev-dev, retu-irq_base);
if (ret  0) {
dev_err(pdev-dev, Unable to allocate Retu children\n);
-   goto err2;
+   goto err3;
}
 
return 0;
 
-err2:
+err3:
pm_power_off = NULL;
-   __retu_write_reg(retu, RETU_REG_IMR, 0x);
free_irq(retu-irq, retu);
 
+err2:
+   retu_irq_exit(retu);
+   irq_free_descs(retu-irq_base, MAX_RETU_IRQ_HANDLERS);
+
 err1:
kfree(retu);
the_retu = NULL;
@@ -503,11 +512,9 @@ static int __exit retu_remove(struct platform_device *pdev)
pm_power_off = NULL;
the_retu = NULL;
 
-   /* Mask all RETU interrupts */
-   __retu_write_reg(retu, RETU_REG_IMR, 0x);
-
free_irq(retu-irq, retu);
retu_irq_exit(retu);
+   irq_free_descs(retu-irq_base, MAX_RETU_IRQ_HANDLERS);
kfree(retu);
 
return 0;
-- 
1.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 2/2] cbus: retu: stop polluting plat/irqs.h

now that we're using sparse IRQs, we don't
need to polute plat/irqs.h anymore with
the dumb IRQ_BASE/IRQ_END definitions.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 arch/arm/mach-omap1/board-nokia770.c   |2 --
 arch/arm/mach-omap2/board-n8x0.c   |2 --
 arch/arm/plat-omap/include/plat/irqs.h |   10 +-
 include/linux/platform_data/cbus.h |2 --
 4 files changed, 1 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap1/board-nokia770.c 
b/arch/arm/mach-omap1/board-nokia770.c
index 7990c48..5eb1a7f 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -124,8 +124,6 @@ static struct resource retu_resource[] = {
 };
 
 static struct cbus_retu_platform_data nokia770_retu_data = {
-   .irq_base   = CBUS_RETU_IRQ_BASE,
-   .irq_end= CBUS_RETU_IRQ_END,
.devid  = CBUS_RETU_DEVICE_ID,
 };
 
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index b3e80c9..f7548e4 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -220,8 +220,6 @@ static struct resource retu_resource[] = {
 };
 
 static struct cbus_retu_platform_data n8x0_retu_data = {
-   .irq_base   = CBUS_RETU_IRQ_BASE,
-   .irq_end= CBUS_RETU_IRQ_END,
.devid  = CBUS_RETU_DEVICE_ID,
 };
 
diff --git a/arch/arm/plat-omap/include/plat/irqs.h 
b/arch/arm/plat-omap/include/plat/irqs.h
index 8c8f517..24eeccd 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -419,15 +419,7 @@
 #define OMAP_GPMC_NR_IRQS  8
 #define OMAP_GPMC_IRQ_END  (OMAP_GPMC_IRQ_BASE + OMAP_GPMC_NR_IRQS)
 
-#define CBUS_RETU_IRQ_BASE OMAP_GPMC_IRQ_END
-#ifdef CONFIG_CBUS_RETU
-#define CBUS_RETU_NR_IRQS  16
-#else
-#define CBUS_RETU_NR_IRQS  0
-#endif
-#define CBUS_RETU_IRQ_END  (CBUS_RETU_IRQ_BASE + CBUS_RETU_NR_IRQS)
-
-#define NR_IRQSCBUS_RETU_IRQ_END
+#define NR_IRQSOMAP_GPMC_IRQ_END
 
 #define OMAP_IRQ_BIT(irq)  (1  ((irq) % 32))
 
diff --git a/include/linux/platform_data/cbus.h 
b/include/linux/platform_data/cbus.h
index a1c5a26..09809c7 100644
--- a/include/linux/platform_data/cbus.h
+++ b/include/linux/platform_data/cbus.h
@@ -32,8 +32,6 @@ struct cbus_host_platform_data {
 };
 
 struct cbus_retu_platform_data {
-   int irq_base;
-   int irq_end;
int devid;
 };
 
-- 
1.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

Re: [GIT PULL] misc. OMAP PM updates for v3.1

* Tony Lindgren t...@atomide.com [110627 12:17]:
 * Kevin Hilman khil...@ti.com [110627 09:45]:
  Tony Lindgren t...@atomide.com writes:
  
   * Kevin Hilman khil...@ti.com [110623 17:32]:
   Tony,
   
   Please pull the following misc. OMAP PM updates targetted for v3.1.
   
   This branch is based on your 'fixes' branch due to some dependencies.
 OMAP2: PM debug: move wakeup timer into clockevent code
  
   This won't work with the devel-timer branch. I think we should just
   drop it for now based on what I mentioned in the other thread.
  
  Hmm, so it's not just the wakeup timer that conflicts between
  devel-timer and my pm-misc branch.
  
  My branch also removes a bunch of other stuff from pm-debug.c and pm.h
  so it has overlapping changes with your devel-timer branch.
  
  The conflicts are easy enough to resolve since both branches are just
  removing code.
 
 OK thanks for checking.
  
  Is your devel-timer branch stable now?  Should I rebase my branch on top
  of devel-timer?  or can you just handle the conflicts?
 
 Just pushed what hopefully is the last version. But since there may
 still be some comments, it's probably best that I resolve the
 conflicts when merging.

Pulled now into devel-cleanup and pushed out. Also merged in devel-timer
branch into devel-cleanup.

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

Re: [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus

2011-06-29 Thread Arnd Bergmann

On Wednesday 29 June 2011, Ohad Ben-Cohen wrote:
 On Wed, Jun 29, 2011 at 2:44 AM, Randy Dunlap rdun...@xenotime.net wrote:
  +hardware accelerators, and therefore are often used to offload 
  cpu-intensive
 
  prefer:   CPU-
  throughout.
 
 Isn't that changing the meaning a bit ? Let's stick with the original
 version, I think it's more clear.

I think you misunderstood Randy, he meant you should do 's/cpu/CPU/' globally,
which does not change the meaning.

  +system's physical memory and/or other sensitive hardware resources (e.g. 
  on
  +OMAP4, remote cores (/hardware accelerators) may have direct access to the
  +physical memory, gpio banks, dma controllers, i2c bus, gptimers, mailbox
  +devices, hwspinlocks, etc..). Moreover, those remote processors might be
  +running RTOS where every task can access the entire memory/devices exposed
  +to the processor. To minimize the risks of rogue (/buggy) userland code
 
  What is with the leading / here and above (/hardware) and below?
 
 / here means or. You can read the sentence twice, either without the
 (/ ..) options or with them, and then you get two (different)
 examples.
 
 Any idea how to make it more readable ? I prefer not to drop the
 second example, as it's adding information.

The easiest way would be to replace it with 'or', as in

... remote cores (or hardware accelerators) may have ...

I would also suggest you drop the parentheses, especially in the first
case where you have two levels of them:

system's physical memory and/or other sensitive hardware resources, e.g. on
OMAP4, remote cores and hardware accelerators may have direct access to the
specific hardware blocks such as physical memory, gpio banks or dma
controllers.
Moreover, those remote processors might be...

  +if RPMSG
  +
  +# OK, it's a little counter-intuitive to do this, but it puts it neatly 
  under
  +# the rpmsg menu (and it's the approach preferred by the virtio folks).
  +
  +source drivers/virtio/Kconfig
 
  It seems odd to have that Kconfig file sourced in multiple places.
  Are the kconfig tools happy with that?
 
 They are, probably because these places are mutually exclusive today:
 
 $ git grep drivers/virtio/Kconfig
 arch/ia64/kvm/Kconfig:source drivers/virtio/Kconfig
 arch/mips/Kconfig:source drivers/virtio/Kconfig
 arch/powerpc/kvm/Kconfig:source drivers/virtio/Kconfig
 arch/s390/kvm/Kconfig:source drivers/virtio/Kconfig
 arch/sh/Kconfig:source drivers/virtio/Kconfig
 arch/tile/kvm/Kconfig:source drivers/virtio/Kconfig
 arch/x86/kvm/Kconfig:source drivers/virtio/Kconfig
 
 Now that we start using virtio for inter-processor communications,
 too, we might soon bump into a situation where virtio will be sourced
 twice.
 
 Probably the solution is to move 'source drivers/virtio/Kconfig'
 into drivers/Kconfig, and remove all other instances.

I think changing that would be good. However, you need to at least
restructure the contents, or they will show up in the main driver menu.

Arnd
--
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 7/8] drivers: introduce rpmsg, a remote-processor messaging bus

2011-06-29 Thread Ohad Ben-Cohen

On Wed, Jun 29, 2011 at 2:59 PM, Arnd Bergmann a...@arndb.de wrote:
 On Wednesday 29 June 2011, Ohad Ben-Cohen wrote:
 On Wed, Jun 29, 2011 at 2:44 AM, Randy Dunlap rdun...@xenotime.net wrote:
  +hardware accelerators, and therefore are often used to offload 
  cpu-intensive
 
  prefer:                                                           CPU-
  throughout.

 Isn't that changing the meaning a bit ? Let's stick with the original
 version, I think it's more clear.

 I think you misunderstood Randy, he meant you should do 's/cpu/CPU/' globally,

Oh, sorry, Randy. For some reason I thought you meant
s/cpu-intensive/CPU-throughout/ which didn't make a lot of sense to me
:)

s/cpu/CPU/ is of course nicer. thanks !

 The easiest way would be to replace it with 'or', as in

 ... remote cores (or hardware accelerators) may have ...

yeah, i'll do it, thanks.

It's a bit harder to get rid of the parentheses in the second
sentence, but I'll think of something too.

 Probably the solution is to move 'source drivers/virtio/Kconfig'
 into drivers/Kconfig, and remove all other instances.

 I think changing that would be good. However, you need to at least
 restructure the contents, or they will show up in the main driver menu.

I'll do that.

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

RE: [RFC PATCH v4] Consolidate SRAM support

2011-06-29 Thread Nori, Sekhar

Hi Jean-Christophe,

On Thu, May 26, 2011 at 06:32:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
 From: Russell King - ARM Linux li...@arm.linux.org.uk
 
 We have two SoCs using SRAM, both with their own allocation systems,
 and both with their own ways of copying functions into the SRAM.
 
 Let's unify this before we have additional SoCs re-implementing this
 obviously common functionality themselves.
 
 For this use the generic allocator and the newly introduce
 gen_pool_add_virt and gen_pool_virt_to_phys
 
 Uio_pruss should probably take the SRAM pool pointer via
 platform data so that it doesn't have to include Davinci specific
 includes.
 
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
 Cc: Sekhar Nori nsek...@ti.com
 Cc: Kevin Hilman khil...@ti.com
 Cc: Tony Lindgren t...@atomide.com
 Cc: Sascha Hauer ker...@pengutronix.de

Is this patch slated to be merged for v3.1?
I did not find it in linux-next.

There is some further cleanup done by Ben
Gardiner for DaVinci which depends on this patch.

 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
 index f4b7dfa..5ec5e5f 100644
 --- a/arch/arm/Kconfig
 +++ b/arch/arm/Kconfig
 @@ -848,6 +848,7 @@ config ARCH_DAVINCI
   bool TI DaVinci
   select GENERIC_CLOCKEVENTS
   select ARCH_REQUIRE_GPIOLIB
 + select GENERIC_ALLOCATOR
   select ZONE_DMA
   select HAVE_IDE
   select CLKDEV_LOOKUP

Just noticed that GENERIC_ALLOCATOR is already selected
For DaVinci (it is right below the CLKDEV_LOOKUP selection)
so this part of the patch can be dropped.

Thanks,
Sekhar

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

Re: [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.

2011-06-29 Thread K, Mythri P

Hi Tomi,


On Mon, Jun 27, 2011 at 6:28 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On Mon, 2011-06-27 at 11:21 +0530, K, Mythri P wrote:
 Hi Tomi,

 On Thu, Jun 23, 2011 at 6:01 PM, Tomi Valkeinen tomi.valkei...@ti.com 
 wrote:
  On Thu, 2011-06-23 at 17:35 +0530, K, Mythri P wrote:
  Hi Tomi,
 
  On Thu, Jun 23, 2011 at 3:28 PM, Tomi Valkeinen tomi.valkei...@ti.com 
  wrote:
   On Fri, 2011-06-17 at 13:47 +0530, Mythri P K wrote:
   HDMI IP block is common between TI OMAP4 Procerssor and Netra 
   processor although
   the Display subsytem is different. Thus to reuse the code between 
   these two
   processors , HDMI IP dependant code is seperated out from hdmi.c and 
   moved to
   new library file hdmi_ti_4xxx_ip.c which now resides in /drivers/video 
   a more
   generic location out of omap2/dss folder.
  
   This patch series does the split and also renames hdmi_omap4_panel.c to
   hdmi_panel.c as that file has nothing specific to OMAP4 and can be 
   reused for
   other OMAP family of processors as well.
  
   These comments are based on the branch you have, not to particular
   patches:
  
   include/video/hdmi_ti_4xxx_ip.h:
  
   - This file is in a way the most important one, because it's the public
   API of the component. So you should be extra careful with this, and see
   that everything in it makes sense, and it's clear how it is to be used.
  
   - hdmi_core_hdmi_dvi is defined but not used. Should it be in the
   private header?
 
   HDMI_HDMI  and HDMI_DVI are used everywhere in hdmi.c and 
  hdmi_ti_4xxx_ip.c,
  one thing  i could do is to add a patch to used this enumerator
  instead of int mode ?
 
  Oh, so the int mode in the header is actually enum hdmi_core_hdmi_dvi
  mode? Using int is obviously wrong, then.
 sure i shall fix it in a separate patch.
 
   - hdmi_pll_pwr seems to be very low level thing. It requires the user to
   know HW details about the PLL, I don't think it should be visible to the
   users. It is used in parameters for hdmi_ti_4xxx_set_pll_pwr(). When is
   it supposed to be used? Why is hdmi_ti_4xxx_wp_video_start() not enough?
  
  HDMI has core , PLL and PHY blocks, so user of the ip driver should
  configure them separately.
 
  Why? Is there some requirement/benefit to it?

 Yes , When the core block is replaced in future OMAP's same PLL and
 PHY blocks are used.

 That doesn't answer the question why the user should know about the
 details of the HW. As far as I see, the user wants basically to
 configure, enable and disable the HDMI HW. The user wants to do the same
 things, regardless of the HDMI HW blocks used in that particular OMAP.

 However, there is a reason why the HDMI PLL should be considered
 separately: the PLL can be used as a clock source for DISPC and VENC. So
 the API should offer functionality to configure and use the PLL
 separately from the HDMI core/phy. But even so, hdmi_pll_pwr feels a bit
 too low-level function for this API.

 As for HDMI core/phy, is there ever reason to use one but not another?
 Or is there a reason to configure them separately? If not, I don't see
 why they should be present separately in the API.

   - The same goes to hdmi_ti_4xxx_pll_program. Who does the PLL
   calculations, omapdss driver? Shouldn't the HDMI driver do it, the PLL
   is a HDMI HW thing, not DSS HW? Or if they are defined in the board
   file, and omapdss just gives them to the HDMI driver, I think the data
   should be somehow passed through omapdss without omapdss actively
   participating in the PLL programming. This would be easy if the HDMI
   would use a platform device/driver model, the data could be passed via
   the device data.
 
  Can you comment on this? Why the PLL calculation is not in the HDMI IP
  driver?
 The calculation of the PLL would depend on the sysclk freq right ? but
 only the TMDS is the concern of HDMI IP block , so i would configure
 only the TMDS portion in HDMI IP and calculation in DSS.

 The HDMI PLL is part of the HDMI HW, not DSS HW, right? What if the HDMI
 PLL used in next OMAP would contain one more divider? Using it would
 require writing new calculation code into DSS driver. The PLL dividers
 and calculations sound very much like HDMI PLL internal thing, not
 something that should be handled in the DSS level.

 Yes, PLL calculations depend on the input clock, in this case sys_clk.
 So it should be provided to the HDMI code.

   - If the PLL calculations have to be done by omapdss, couldn't the
   hdmi_pll_info be part of hdmi_config?
 
  hdmi_pll_info would be used only once while configuring (power on) ,
  Why would we have to store the pll_info then in hdmi_config?
 
  Whether you store the hdmi_pll_info or not is HDMI IP driver internal
  thing, not related to the API. We're talking about the API here.
 
  Look at the include/video/hdmi_ti_4xxx_ip.h file and think from the
  users view point: what is the most obvious and easiest way to use the
  API. Then make the HDMI IP driver work with the

Re: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation

On Tue, Jun 28, 2011 at 04:59:57PM -0700, Colin Cross wrote:
 On Tue, Jun 28, 2011 at 4:46 PM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
  On Tue, Jun 28, 2011 at 04:37:08PM -0700, Colin Cross wrote:
  I don't think it affects bogomips - loops_per_jiffy can still be
  calibrated and updated by cpufreq, udelay just wont use them.
 
  No, you can't avoid it.  __delay(), udelay(), and the global
  loops_per_jiffy are all linked together - for instance this is how
  the spinlock code has a 1s timeout:
 
  static void __spin_lock_debug(raw_spinlock_t *lock)
  {
         u64 loops = loops_per_jiffy * HZ;
         int print_once = 1;
 
         for (;;) {
                 for (i = 0; i  loops; i++) {
                         if (arch_spin_trylock(lock-raw_lock))
                                 return;
                         __delay(1);
                 }
 
  which goes wrong for all the same reasons you're pointing out about
  udelay().  So just restricting your argument to udelay() is not
  realistic.
 
 
 True, there are a few other users of loops_per_jiffy and __delay, but
 it looks like __spin_lock_debug is the only one worth worrying about,
 and it's timing is not as critical as udelay - worst case here is that
 the warning occurs after 250 ms instead of 1s.  Leaving
 loops_per_jiffy and __delay intact, and fixing udelay, would still be
 a net gain.

Other users of loops_per_jiffy are incorrect in any case:

static inline void omap_hsmmc_reset_controller_fsm(struct omap_hsmmc_host 
*host,   unsigned long bit)
{
unsigned long i = 0;
unsigned long limit = (loops_per_jiffy *
msecs_to_jiffies(MMC_TIMEOUT_MS));
...
if (mmc_slot(host).features  HSMMC_HAS_UPDATED_RESET) {
while ((!(OMAP_HSMMC_READ(host-base, SYSCTL)  bit))
 (i++  limit))
cpu_relax();
}

Is rubbish.

static void omap_write_buf_pref(struct mtd_info *mtd,
const u_char *buf, int len)
{
...
/* wait for data to flushed-out before reset the prefetch */
tim = 0;
limit = (loops_per_jiffy *

msecs_to_jiffies(OMAP_NAND_TIMEOUT_MS));while 
(gpmc_read_status(GPMC_PREFETCH_COUNT)  (tim++  limit))  
  cpu_relax();

Another load of rubbish.

static int flush(struct pl022 *pl022)
{
unsigned long limit = loops_per_jiffy  1;

dev_dbg(pl022-adev-dev, flush\n);
do {
while (readw(SSP_SR(pl022-virtbase))  SSP_SR_MASK_RNE)
readw(SSP_DR(pl022-virtbase));
} while ((readw(SSP_SR(pl022-virtbase))  SSP_SR_MASK_BSY)  limit--);

Yet more...

static int flush(struct driver_data *drv_data)
{
unsigned long limit = loops_per_jiffy  1;

void __iomem *reg = drv_data-ioaddr;

do {
while (read_SSSR(reg)  SSSR_RNE) {
read_SSDR(reg);
}
} while ((read_SSSR(reg)  SSSR_BSY)  --limit);

and...

sound/soc/samsung/i2s.c:
#define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
/* Be patient */
val = msecs_to_loops(1) / 1000; /* 1 usec */
while (--val)
cpu_relax();

even worse.

#define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
static int s3c2412_snd_lrsync(struct s3c_i2sv2_info *i2s)
{
u32 iiscon;
unsigned long loops = msecs_to_loops(5);

while (--loops) {
iiscon = readl(i2s-regs + S3C2412_IISCON);
if (iiscon  S3C2412_IISCON_LRINDEX)
break;

cpu_relax();
}

It just goes on...

And strangely the major offender of this stuff are ARM drivers, not other
peoples stuff and not stuff in drivers/staging.

So I don't think its sane to ignore loops_per_jiffy and __delay, and just
concentrate on udelay().
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

On Wed, Jun 29, 2011 at 12:11 AM, Paul Walmsley p...@pwsan.com wrote:
 On Tue, 28 Jun 2011, T Krishnamoorthy, Balaji wrote:

 On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley p...@pwsan.com wrote:
 
  On Wed, 22 Jun 2011, Balaji T K wrote:
 
  Use runtime autosuspend APIs to enable auto suspend delay
 
  Does this really need to use runtime autosuspend?  Seems to me that since
  PM runtime is just controlling the MMC IP blocks and not the regulators in
  this instance, this could simply use pm_runtime_put*() and just avoid the
  extra power wastage and complexity involved in autosuspend.

 I have seen some instabilities if delay is very less, on some production 
 boards.

 Could you be more specific?  What type of instabilities did you see?

There have been some experiments on our customer programs to reduce this
value to a few ms and infrequent crashes were observed (stress testing
for several hours) while
trying to access the controller registers.


 The previous implementation used 100ms delay before disabling the clocks.
 Is there any specific issue I should be aware of, for using _autosuspend ?


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

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

On Wed, Jun 29, 2011 at 2:00 AM, Kevin Hilman khil...@ti.com wrote:
 T Krishnamoorthy, Balaji balaj...@ti.com writes:

 On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley p...@pwsan.com wrote:
 (cc'ing Adrian also)

 Hi Balaji

 On Wed, 22 Jun 2011, Balaji T K wrote:

 Use runtime autosuspend APIs to enable auto suspend delay

 Does this really need to use runtime autosuspend?  Seems to me that since
 PM runtime is just controlling the MMC IP blocks and not the regulators in
 this instance, this could simply use pm_runtime_put*() and just avoid the
 extra power wastage and complexity involved in autosuspend.


 I have seen some instabilities if delay is very less, on some production 
 boards.
 The previous implementation used 100ms delay before disabling the clocks.

 And your new one is using 50ms.  How did this value come about?

I don't have any specific affinity to this number, but when requests
are bursty, they arrive
within a few 10s of ms within each other. Didn't want to have the
context/save restore
penalty associated with every request.

 As Paul mentioned, the timeout value here is probably usecase depeend


There is no direct relationship to the use case. Block layer buffers
and reworks the order
of requests and they are usually queued together. Having no context
save / restore
penalty for each request is definitely desirable.
(As I understand, MMC can lose context independent of MPU on OMAP4).
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:

 On Wed, Jun 29, 2011 at 12:11 AM, Paul Walmsley p...@pwsan.com wrote:
  On Tue, 28 Jun 2011, T Krishnamoorthy, Balaji wrote:
 
  On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley p...@pwsan.com wrote:
  
   On Wed, 22 Jun 2011, Balaji T K wrote:
  
   Use runtime autosuspend APIs to enable auto suspend delay
  
   Does this really need to use runtime autosuspend?  Seems to me that since
   PM runtime is just controlling the MMC IP blocks and not the regulators 
   in
   this instance, this could simply use pm_runtime_put*() and just avoid the
   extra power wastage and complexity involved in autosuspend.
 
  I have seen some instabilities if delay is very less, on some production 
  boards.
 
  Could you be more specific?  What type of instabilities did you see?
 
 There have been some experiments on our customer programs to reduce this 
 value to a few ms and infrequent crashes were observed (stress testing 
 for several hours) while trying to access the controller registers.

Was there an oops?  Any analysis, etc.?


- Paul

Re: [RFC 2/8] remoteproc: add omap implementation

2011-06-29 Thread Ohad Ben-Cohen

On Tue, Jun 28, 2011 at 12:00 AM, Grant Likely
grant.lik...@secretlab.ca wrote:
 Very little for me to comment on here.  However, something I just
 noticed.  Why is it necessary to pass in THIS_MODULE to the
 rproc_register function?  Having a reference to the pdev gives you the
 pointer to the driver, which has the THIS_MODULE value in it.  That
 should be sufficient.

Nice one, thanks !

 /me also isn't sure if incrementing the refcount on the module is the
 best way to prevent the rproc from going away, but I haven't dug into
 the details in the driver code to find out.  Drivers can get unbound
 from devices without the driver being unloaded, so I imagine there is
 an in-use count on the device itself that would prevent driver
 unbinding.

Yes, increasing the module refcount is necessary to prevent the user
from removing the driver when the rproc is used.

If the underlying device goes away while rproc is used, then
rproc_unregister should return -EBUSY, which would fail the underlying
driver's -remove() handler (gpiolib is doing something very similar).
I have forgotten to add this check, and will add it now.

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 4/4] mfd: global Suspend and resume support of ehci and ohci

2011-06-29 Thread Munegowda, Keshava

On Thu, Jun 2, 2011 at 5:36 AM, Kevin Hilman khil...@ti.com wrote:
 Keshava Munegowda keshava_mgo...@ti.com writes:

 From: Keshava Munegowda keshava_mgo...@ti.com

 The global suspend and resume functions for usbhs core driver
 are implemented.These routine are called when the global suspend
 and resume occurs. Before calling these functions, the
 bus suspend and resume of ehci and ohci drivers are called
 from runtime pm.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com

 First, from what I can see, this is only a partial implementation of
 runtime PM.  What I mean is that the runtime PM methods are used only
 during the suspend path.  The rest of the time the USB host IP block is
 left enabled, even when nothing is connected.

 I tested this on my 3530/Overo board, and verified that indeed the
 usbhost powerdomain hits retention on suspend, but while idle, when
 nothing is connected, I would expect the driver could be clever enough
 to use runtime PM (probably using autosuspend timeouts) to disable the
 hardware as well.

 ---
  drivers/mfd/omap-usb-host.c |  103 
 +++
  1 files changed, 103 insertions(+), 0 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 43de12a..32d19e2 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -146,6 +146,10 @@
  #define is_ehci_hsic_mode(x) (x == OMAP_EHCI_PORT_MODE_HSIC)


 +/* USBHS state bits */
 +#define OMAP_USBHS_INIT              0
 +#define OMAP_USBHS_SUSPEND   4

 These additional state bits don't seem to be necessary.

 For suspend, just check 'pm_runtime_is_suspended()'

 The init flag is only used in the suspend/resume hooks, but the need for
 it is a side effect of not correctly using the runtime PM callbacks.

 Remember that the runtime PM get/put hooks have usage counting.  Only
 when the usage count transitions to/from zero is the actual
 hardware-level enable/disable (via omap_hwmod) being done.

 The current code is making the assumption that every call to get/put is
 going to result in an enable/disable of the hardware.

 Instead, all of the code that needs to be run only upon actual
 enable/disable of the hardware should be done in the driver's
 runtime_suspend/runtime_resume callbacks.  These are only called when
 the hardware actually changes state.

 Not knowing that much about the EHCI block, upon first glance, it looks
 like mmuch of what is done in usbhs_enable() should actually be done in
 the -runtime_resume() callback, and similarily, much of what is done in
 usbhs_disable() should be done in the -runtime_suspend() callback.

Kevin,
   do you mean driver-runtime_resume and driver-runtime_resume call backs.
are these call backs from pm_runtime_get_sync and pm_runtime_put_sync?
--
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 2/8] remoteproc: add omap implementation

2011-06-29 Thread Grant Likely

On Wed, Jun 29, 2011 at 9:04 AM, Ohad Ben-Cohen o...@wizery.com wrote:
 On Tue, Jun 28, 2011 at 12:00 AM, Grant Likely
 grant.lik...@secretlab.ca wrote:
 Very little for me to comment on here.  However, something I just
 noticed.  Why is it necessary to pass in THIS_MODULE to the
 rproc_register function?  Having a reference to the pdev gives you the
 pointer to the driver, which has the THIS_MODULE value in it.  That
 should be sufficient.

 Nice one, thanks !

 /me also isn't sure if incrementing the refcount on the module is the
 best way to prevent the rproc from going away, but I haven't dug into
 the details in the driver code to find out.  Drivers can get unbound
 from devices without the driver being unloaded, so I imagine there is
 an in-use count on the device itself that would prevent driver
 unbinding.

 Yes, increasing the module refcount is necessary to prevent the user
 from removing the driver when the rproc is used.

That prevents removing the module which necessitates unbinding the
device.  However, I believe it is possible to unbind a driver
/without/ the module being unloaded.  My question (for which I don't
have an answer) is whether or not there is a way to increment a
refcount on users of the driver bound to the device..

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

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

On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:

 There have been some experiments on our customer programs to reduce this 
 value to a few ms and infrequent crashes were observed (stress testing 
 for several hours) while trying to access the controller registers.

By the way, could you send along a copy of the stress test script?


- Paul
--
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 7/8] drivers: introduce rpmsg, a remote-processor messaging bus

2011-06-29 Thread Grant Likely

On Tue, Jun 28, 2011 at 5:00 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 On Wed, Jun 29, 2011 at 1:51 AM, Grant Likely grant.lik...@secretlab.ca 
 wrote:
 It's not the device_for_each_child() that you're 'putting' back from
 here.  Its the original kref initialization when the device was
 created.

 device_unregister() is already calling put_device(), doesn't that deal
 with the original kref init for us ?

/me digs deeper:

device_register() has 2 parts; device_initialize() and device_add()
device_init() initialized the kref to 1 (via kobject_init()
device_add() calls get_device() to increment it to 2

Then similarly for device_unregister():
device_del() calls put_device() to decrement the kref to 1
a final put_device() call decrements the kref to 0 - which triggers a
call to the release method that kfrees the object.

So you are right that device_unregister drops the refcount to zero,
but the code still needs to be fixed to not call kfree() directly.

It also looks like rpmsg_destroy_channel() needs to be fixed to remove
the kfree call and an extra put_device() call.  This is important
because the last put_device() call above might /not/ decrement the
refcount to zero is for some reason something still holds a reference
to the device.  But the device will still get freed correctly when the
other holder finally calls device_put().

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

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

On Wed, Jun 29, 2011 at 8:12 PM, Paul Walmsley p...@pwsan.com wrote:
 On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:

 On Wed, Jun 29, 2011 at 12:11 AM, Paul Walmsley p...@pwsan.com wrote:
  On Tue, 28 Jun 2011, T Krishnamoorthy, Balaji wrote:
 
  On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley p...@pwsan.com wrote:
  
   On Wed, 22 Jun 2011, Balaji T K wrote:
  
   Use runtime autosuspend APIs to enable auto suspend delay
  
   Does this really need to use runtime autosuspend?  Seems to me that 
   since
   PM runtime is just controlling the MMC IP blocks and not the regulators 
   in
   this instance, this could simply use pm_runtime_put*() and just avoid 
   the
   extra power wastage and complexity involved in autosuspend.
 
  I have seen some instabilities if delay is very less, on some production 
  boards.
 
  Could you be more specific?  What type of instabilities did you see?

 There have been some experiments on our customer programs to reduce this
 value to a few ms and infrequent crashes were observed (stress testing
 for several hours) while trying to access the controller registers.

 Was there an oops?  Any analysis, etc.?

OOPS pointed to omap_hsmmc_prepare_data / set_data_timeout
Use case was MMC + SDIO +GPS activity, on kernel 2.6.35 though.

Unhandled fault: imprecise external abort (0x1406) at 0x4073102c
Internal error: : 1406 [#1] PREEMPT SMP
last sysfs file: /sys/devices/platform/switch-sio/usb_sel
Modules linked in: param(P) j4fs(P) vibetonz Si4709_driver fm_drv(C)
bt_drv(C) st_drv(C)
CPU: 0Tainted: PWC   (2.6.35.7 #2)
PC is at clk_get_rate+0x4/0x48
LR is at set_data_timeout+0x68/0xf4
[c06e78e0] (set_data_timeout+0x0/0xf4) from [c06e7dc8]
(omap_hsmmc_request+0x2d0/0x5c8)
 r8:efa78400 r7:0001 r6: r5:ef9efe78 r4:efa78640
r3:ef9efee4
[c06e7af8] (omap_hsmmc_request+0x0/0x5c8) from [c06df040]
(mmc_wait_for_req+0x118/0x130)
[c06def28] (mmc_wait_for_req+0x0/0x130) from [c06e59e8]
(mmc_blk_issue_rq+0x1c0/0x500)
 r6:ef86f000 r5:efa79000 r4:c91e61a0
[c06e5828] (mmc_blk_issue_rq+0x0/0x500) from [c06e6620]
(mmc_queue_thread+0xf4/0xf8)
[c06e652c] (mmc_queue_thread+0x0/0xf8) from [c045ddec] (kthread+0x84/0x8c)
[c045dd68] (kthread+0x0/0x8c) from [c044b748] (do_exit+0x0/0x604)
 r7:0013 r6:c044b748 r5:c045dd68 r4:ef8d5d68
Code: e1a4 e89da8f0 c0a653c0 e1a0c00d (e92dd818)
---[ end trace 533b4c955f5abafd ]---



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

Re: [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.

2011-06-29 Thread Tomi Valkeinen

Hi,

On Wed, 2011-06-29 at 19:08 +0530, K, Mythri P wrote:
 Hi Tomi,

 As the HDMI PLL , PHY and video blocks are logical blocks it would
 make sense to have the API's for all and the DSS HDMI (interface
 driver - user driver) would make a call to configure this in a
 particular sequence to enable HDMI , in case you the call to be
 generic across OMAPS in future then we should i either have a funtion
 in hdmi.c which will do this sequence and will be  aware of underlying
 IP , Which doesnt appear to be the solution you prefer but then there
 would be a need to have an intermediate file which would take the
 common API call(function pointer) and then arbitrate between different
 IP's based on the make , Is that what you are suggesting ?

I agree that they are separate blocks, and at some level they need to be
separate with own functions for each. But I don't see why the user needs
to know about it.

For example, consider OMAP DSI. DSI has protocol, PLL and PHY blocks,
and the driver has functions to initialize them, use them etc. But the
user of DSI, in this case panel drivers, do not need to know about it,
and the API exported to the panel drivers does not contain any functions
related to PLL or PHY. The panel drivers just enable the DSI driver and
use it.

So I'm still asking: what benefit does it give to the user that the API
has functions to handle the blocks separately? There has to be a reason
for the functions in the API.

  And it just occurred to me that perhaps our views of the API are a bit
  different, and that's why we have differing opinions. I see this API as
  something that could be used by OMAP DSS (and equivalent components on
  other SoCs) to use the HDMI HW on OMAP4 and any future OMAPs. And
  perhaps you see this API more as an API to use the current HDMI HW in
  the OMAP4.
 
 Tomi , Yes my Idea of this API is for OMAP and Netra series only , I
 am unable to envision a common HDMI API library , in that case it
 would make more sense to have an intermediate file and have function
 pointer , which would take common API calls like hdmi_enable ,
 hdmi_avi_confg etc and then arbitrate based on the build. Please let
 me know if you have anything else in mind.

I didn't mean a generic HDMI API either. I meant a TI HDMI API,
currently for OMAP and Netra. But my comments would be valid even if the
API would be only OMAP DSS internal. 

 Tomi


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

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

2011-06-29 Thread S, Venkatraman

On Wed, Jun 29, 2011 at 9:08 PM, Paul Walmsley p...@pwsan.com wrote:
 On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:

 There have been some experiments on our customer programs to reduce this
 value to a few ms and infrequent crashes were observed (stress testing
 for several hours) while trying to access the controller registers.

 By the way, could you send along a copy of the stress test script?


Paul, these scenarios are not scripted but end user tests with
additional devices
(WLAN, which is connected on the same controller) and executed 'on field' .
One such log is here .. http://pastebin.com/nq3cfZnT
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] mfd: global Suspend and resume support of ehci and ohci

2011-06-29 Thread Munegowda, Keshava

On Wed, Jun 29, 2011 at 8:52 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
 On Thu, Jun 2, 2011 at 5:36 AM, Kevin Hilman khil...@ti.com wrote:
 Keshava Munegowda keshava_mgo...@ti.com writes:

 From: Keshava Munegowda keshava_mgo...@ti.com

 The global suspend and resume functions for usbhs core driver
 are implemented.These routine are called when the global suspend
 and resume occurs. Before calling these functions, the
 bus suspend and resume of ehci and ohci drivers are called
 from runtime pm.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com

 First, from what I can see, this is only a partial implementation of
 runtime PM.  What I mean is that the runtime PM methods are used only
 during the suspend path.  The rest of the time the USB host IP block is
 left enabled, even when nothing is connected.

 I tested this on my 3530/Overo board, and verified that indeed the
 usbhost powerdomain hits retention on suspend, but while idle, when
 nothing is connected, I would expect the driver could be clever enough
 to use runtime PM (probably using autosuspend timeouts) to disable the
 hardware as well.

 ---
  drivers/mfd/omap-usb-host.c |  103 
 +++
  1 files changed, 103 insertions(+), 0 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 43de12a..32d19e2 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -146,6 +146,10 @@
  #define is_ehci_hsic_mode(x) (x == OMAP_EHCI_PORT_MODE_HSIC)


 +/* USBHS state bits */
 +#define OMAP_USBHS_INIT              0
 +#define OMAP_USBHS_SUSPEND   4

 These additional state bits don't seem to be necessary.

 For suspend, just check 'pm_runtime_is_suspended()'

 The init flag is only used in the suspend/resume hooks, but the need for
 it is a side effect of not correctly using the runtime PM callbacks.

 Remember that the runtime PM get/put hooks have usage counting.  Only
 when the usage count transitions to/from zero is the actual
 hardware-level enable/disable (via omap_hwmod) being done.

 The current code is making the assumption that every call to get/put is
 going to result in an enable/disable of the hardware.

 Instead, all of the code that needs to be run only upon actual
 enable/disable of the hardware should be done in the driver's
 runtime_suspend/runtime_resume callbacks.  These are only called when
 the hardware actually changes state.

 Not knowing that much about the EHCI block, upon first glance, it looks
 like mmuch of what is done in usbhs_enable() should actually be done in
 the -runtime_resume() callback, and similarily, much of what is done in
 usbhs_disable() should be done in the -runtime_suspend() callback.

 Kevin,
   do you mean driver-runtime_resume and driver-runtime_resume call backs.
 are these call backs from pm_runtime_get_sync and pm_runtime_put_sync?

for usb host case , I am seeing that the pm_runtime_get_sync


static int rpm_resume(struct device *dev, int rpmflags)
{
  
 ..
if (dev-pwr_domain) {
callback = dev-pwr_domain-ops.runtime_resume;
if(!strcmp(dev_name(dev),usbhs_omap))
 pr_err(dev-pwr_domain-ops.runtime_resume);
}   
else if (dev-type  dev-type-pm) {
callback = dev-type-pm-runtime_resume;
if(!strcmp(dev_name(dev),usbhs_omap))
 pr_err(dev-type-pm-runtime_resume);
}   
else if (dev-class  dev-class-pm) {
callback = dev-class-pm-runtime_resume;
if(!strcmp(dev_name(dev),usbhs_omap))
 pr_err(ev-class-pm-runtime_resume);
}   
else if (dev-bus  dev-bus-pm) {
callback = dev-bus-pm-runtime_resume;
if(!strcmp(dev_name(dev),usbhs_omap))
 pr_err(dev-bus-pm-runtime_resume);
}   
else
callback = NULL;
}


I am seeing that below if statement was hitting true:

if (dev-pwr_domain) {
callback = dev-pwr_domain-ops.runtime_resume;
if(!strcmp(dev_name(dev),usbhs_omap))
 pr_err(dev-pwr_domain-ops.runtime_resume);


due to this; the driver-runtime_resume was not getting called.

Any idea on why I am seeing only the dev-pwr_domain is set not
dev-bus  dev-bus-pm is hitting here?
--
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] OMAP3: run the ASM sleep code from DDR

2011-06-29 Thread jean . pihet

From: Jean Pihet j-pi...@ti.com

Most of the ASM sleep code (in arch/arm/mach-omap2/sleep34xx.S)
is copied to internal SRAM at boot and after wake-up from CORE OFF mode.
However only a small part of the code really needs to run from internal SRAM.

This fix lets most of the ASM idle code run from the DDR
in order to minimize the SRAM usage and the overhead in the code copy.

The only pieces of code that are mandatory in SRAM are:
- the i443 erratum WA,
- the i581 erratum WA,
- the security extension code.

SRAM usage:
- original code:
  . 560 bytes for omap3_sram_configure_core_dpll (used by DVFS),
  . 852 bytes for omap_sram_idle (used by suspend/resume in RETention),
  . 124 bytes for es3_sdrc_fix (used by suspend/resume in OFF mode on ES3.x),
  . 108 bytes for save_secure_ram_context (used on HS parts only).

With this fix the usage for suspend/resume in RETention goes down 288 bytes,
so the gain in SRAM usage for suspend/resume is 564 bytes.

Also fixed the SRAM initialization sequence to avoid an unnecessary
copy to SRAM at boot time and for readability.

Tested on Beagleboard (ES2.x) in idle with full RET and OFF modes.

Signed-off-by: Jean Pihet j-pi...@ti.com
---
 arch/arm/mach-omap2/pm.h|   20 ++-
 arch/arm/mach-omap2/pm34xx.c|   20 ++--
 arch/arm/mach-omap2/sleep34xx.S |  303 ++
 arch/arm/plat-omap/sram.c   |   15 +--
 4 files changed, 206 insertions(+), 152 deletions(-)

Rebased on the suspend branch of rmk's tree

diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 45bcfce..a4ec213 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -88,18 +88,28 @@ extern int pm_dbg_regset_init(int reg_set);
 #define pm_dbg_regset_init(reg_set) do {} while (0);
 #endif /* CONFIG_PM_DEBUG */
 
+/* 24xx */
 extern void omap24xx_idle_loop_suspend(void);
+extern unsigned int omap24xx_idle_loop_suspend_sz;
 
 extern void omap24xx_cpu_suspend(u32 dll_ctrl, void __iomem *sdrc_dlla_ctrl,
void __iomem *sdrc_power);
+extern unsigned int omap24xx_cpu_suspend_sz;
+
+/* 3xxx */
 extern void omap34xx_cpu_suspend(u32 *addr, int save_state);
-extern int save_secure_ram_context(u32 *addr);
-extern void omap3_save_scratchpad_contents(void);
 
-extern unsigned int omap24xx_idle_loop_suspend_sz;
+/* omap3_do_wfi function pointer and size, for copy to SRAM */
+extern void omap3_do_wfi(void);
+extern unsigned int omap3_do_wfi_sz;
+/* ... and its pointer from SRAM after copy */
+extern void (*omap3_do_wfi_sram)(void);
+
+/* save_secure_ram_context function pointer and size, for copy to SRAM */
+extern int save_secure_ram_context(u32 *addr);
 extern unsigned int save_secure_ram_context_sz;
-extern unsigned int omap24xx_cpu_suspend_sz;
-extern unsigned int omap34xx_cpu_suspend_sz;
+
+extern void omap3_save_scratchpad_contents(void);
 
 #define PM_RTA_ERRATUM_i608(1  0)
 #define PM_SDRC_WAKEUP_ERRATUM_i583(1  1)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 3e9a13e..e1c79ba 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -78,9 +78,8 @@ struct power_state {
 
 static LIST_HEAD(pwrst_list);
 
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
-
 static int (*_omap_save_secure_sram)(u32 *addr);
+void (*omap3_do_wfi_sram)(void);
 
 static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
 static struct powerdomain *core_pwrdm, *per_pwrdm;
@@ -309,7 +308,7 @@ static irqreturn_t prcm_interrupt_handler (int irq, void 
*dev_id)
 
 static void omap34xx_do_sram_idle(unsigned long save_state)
 {
-   _omap_sram_idle(omap3_arm_context, save_state);
+   omap34xx_cpu_suspend(omap3_arm_context, save_state);
 }
 
 void omap_sram_idle(void)
@@ -328,9 +327,6 @@ void omap_sram_idle(void)
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
 
-   if (!_omap_sram_idle)
-   return;
-
pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
pwrdm_clear_all_prev_pwrst(neon_pwrdm);
pwrdm_clear_all_prev_pwrst(core_pwrdm);
@@ -826,10 +822,17 @@ static int __init clkdms_setup(struct clockdomain *clkdm, 
void *unused)
return 0;
 }
 
+/*
+ * Push functions to SRAM
+ *
+ * The minimum set of functions is pushed to SRAM for execution:
+ * - omap3_do_wfi for erratum i581 WA,
+ * - save_secure_ram_context for security extensions.
+ */
 void omap_push_sram_idle(void)
 {
-   _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
-   omap34xx_cpu_suspend_sz);
+   omap3_do_wfi_sram = omap_sram_push(omap3_do_wfi, omap3_do_wfi_sz);
+
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
_omap_save_secure_sram = omap_sram_push(save_secure_ram_context,
save_secure_ram_context_sz);
@@ -894,7 +897,6 @@ static int __init omap3_pm_init(void)
per_clkdm = clkdm_lookup(per_clkdm);
core_clkdm =

Re: [PATCHv4 1/9] omap: prcm: switch to a chained IRQ handler mechanism

Hi,

On Wed, Jun 29, 2011 at 12:04:55PM +0300, Tero Kristo wrote:
 diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
 index 96a7624..89cf027 100644
 --- a/arch/arm/mach-omap2/pm34xx.c
 +++ b/arch/arm/mach-omap2/pm34xx.c
 @@ -880,20 +824,35 @@ static int __init omap3_pm_init(void)
   /* XXX prcm_setup_regs needs to be before enabling hw
* supervised mode for powerdomains */
   prcm_setup_regs();
 + ret = omap_prcm_irq_init();
 + if (ret) {
 + pr_err(omap_prcm_irq_init() failed with %d\n, ret);
 + goto err_prcm_irq_init;
 + }
 +
 + prcm_wkup_irq = omap_prcm_event_to_irq(wkup);
 + prcm_io_irq = omap_prcm_event_to_irq(io);
 +
 + ret = request_irq(prcm_wkup_irq, _prcm_int_handle_wakeup,
 + IRQF_NO_SUSPEND | IRQF_DISABLED, prcm_wkup, NULL);

does this _have_ to be all in hardirq context ?

 - ret = request_irq(INT_34XX_PRCM_MPU_IRQ,
 -   (irq_handler_t)prcm_interrupt_handler,
 -   IRQF_DISABLED, prcm, NULL);
   if (ret) {
 - printk(KERN_ERR request_irq failed to register for 0x%x\n,
 -INT_34XX_PRCM_MPU_IRQ);
 - goto err1;
 + printk(KERN_ERR Failed to request prcm_wkup irq\n);
 + goto err_prcm_wkup;
 + }
 +
 + ret = request_irq(prcm_io_irq, _prcm_int_handle_wakeup,
 + IRQF_NO_SUSPEND | IRQF_DISABLED, prcm_io, NULL);

same here...

 diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
 index 6be1438..794e451 100644
 --- a/arch/arm/mach-omap2/prcm.c
 +++ b/arch/arm/mach-omap2/prcm.c
 @@ -23,6 +23,8 @@
  #include linux/clk.h
  #include linux/io.h
  #include linux/delay.h
 +#include linux/irq.h
 +#include linux/slab.h
  
  #include mach/system.h
  #include plat/common.h
 @@ -45,6 +47,167 @@ void __iomem *cm2_base;
  
  #define MAX_MODULE_ENABLE_WAIT   10
  
 +/* Setup for the interrupt handling based on used platform */
 +static struct omap_prcm_irq_setup *irq_setup;

you can set this is irq_chip data, then you can:

 +static void prcm_irq_ack(struct irq_data *data)
 +{
struct omap_prcm_irq_setup  *irq_setup = 
irq_data_get_irq_chip_data(data)
unsigned intprcm_irq = data-irq - irq_setup-base;

irq_setup-ack_event(prcm_irq);
 +}

ditto to all other operations.

 +static struct irq_chip_generic *prcm_irq_chips[OMAP_PRCM_MAX_NR_PENDING_REG];

can't you allocate this dynamically ???

 +/*
 + * PRCM Interrupt Handler
 + *
 + * The PRM_IRQSTATUS_MPU register indicates if there are any pending
 + * interrupts from the PRCM for the MPU. These bits must be cleared in
 + * order to clear the PRCM interrupt. The PRCM interrupt handler is
 + * implemented to simply clear the PRM_IRQSTATUS_MPU in order to clear
 + * the PRCM interrupt. Please note that bit 0 of the PRM_IRQSTATUS_MPU
 + * register indicates that a wake-up event is pending for the MPU and
 + * this bit can only be cleared if the all the wake-up events latched
 + * in the various PM_WKST_x registers have been cleared. The interrupt
 + * handler is implemented using a do-while loop so that if a wake-up
 + * event occurred during the processing of the prcm interrupt handler
 + * (setting a bit in the corresponding PM_WKST_x register and thus
 + * preventing us from clearing bit 0 of the PRM_IRQSTATUS_MPU register)
 + * this would be handled.
 + */
 +static void prcm_irq_handler(unsigned int irq, struct irq_desc *desc)
 +{
 + unsigned long pending[OMAP_PRCM_MAX_NR_PENDING_REG];
 + struct irq_chip *chip = irq_desc_get_chip(desc);
 +
 + /*
 +  * Loop until all pending irqs are handled, since
 +  * generic_handle_irq(), called by prcm_irq_handle_virtirqs()
 +  * can cause new irqs to come
 +  */
 + while (1) {
 + unsigned int virtirq;
 +
 + chip-irq_ack(desc-irq_data);
 +
 + memset(pending, 0, sizeof(pending));
 + irq_setup-pending_events(pending);
 +
 + /* No bit set, then all IRQs are handled */
 + if (find_first_bit(pending, OMAP_PRCM_NR_IRQS)
 + = OMAP_PRCM_NR_IRQS) {
 + chip-irq_unmask(desc-irq_data);
 + break;
 + }
 +
 + /*
 +  * Loop on all currently pending irqs so that new irqs
 +  * cannot starve previously pending irqs
 +  */
 + for_each_set_bit(virtirq, pending, OMAP_PRCM_NR_IRQS)
 + generic_handle_irq(OMAP_PRCM_IRQ_BASE + virtirq);

if you use nested IRQ threads, you could be using
handle_nested_irq(irq);

 + chip-irq_unmask(desc-irq_data);
 + }
 +}
 +
 +/*
 + * Given a PRCM event name, returns the corresponding IRQ on which the
 + * handler should be registered.
 + */
 +int omap_prcm_event_to_irq(const char *name)
 +{
 + int i;
 +
 + for (i = 0; i

Re: [PATCHv4 1/9] omap: prcm: switch to a chained IRQ handler mechanism

On Wed, Jun 29, 2011 at 07:53:19PM +0300, Felipe Balbi wrote:
 On Wed, Jun 29, 2011 at 12:04:55PM +0300, Tero Kristo wrote:
  diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
  index 96a7624..89cf027 100644
  --- a/arch/arm/mach-omap2/pm34xx.c
  +++ b/arch/arm/mach-omap2/pm34xx.c
  @@ -880,20 +824,35 @@ static int __init omap3_pm_init(void)
  /* XXX prcm_setup_regs needs to be before enabling hw
   * supervised mode for powerdomains */
  prcm_setup_regs();
  +   ret = omap_prcm_irq_init();
  +   if (ret) {
  +   pr_err(omap_prcm_irq_init() failed with %d\n, ret);
  +   goto err_prcm_irq_init;
  +   }
  +
  +   prcm_wkup_irq = omap_prcm_event_to_irq(wkup);
  +   prcm_io_irq = omap_prcm_event_to_irq(io);
  +
  +   ret = request_irq(prcm_wkup_irq, _prcm_int_handle_wakeup,
  +   IRQF_NO_SUSPEND | IRQF_DISABLED, prcm_wkup, NULL);
 
 does this _have_ to be all in hardirq context ?
 
  -   ret = request_irq(INT_34XX_PRCM_MPU_IRQ,
  - (irq_handler_t)prcm_interrupt_handler,
  - IRQF_DISABLED, prcm, NULL);
  if (ret) {
  -   printk(KERN_ERR request_irq failed to register for 0x%x\n,
  -  INT_34XX_PRCM_MPU_IRQ);
  -   goto err1;
  +   printk(KERN_ERR Failed to request prcm_wkup irq\n);
  +   goto err_prcm_wkup;
  +   }
  +
  +   ret = request_irq(prcm_io_irq, _prcm_int_handle_wakeup,
  +   IRQF_NO_SUSPEND | IRQF_DISABLED, prcm_io, NULL);
 
 same here...
 
  diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
  index 6be1438..794e451 100644
  --- a/arch/arm/mach-omap2/prcm.c
  +++ b/arch/arm/mach-omap2/prcm.c
  @@ -23,6 +23,8 @@
   #include linux/clk.h
   #include linux/io.h
   #include linux/delay.h
  +#include linux/irq.h
  +#include linux/slab.h
   
   #include mach/system.h
   #include plat/common.h
  @@ -45,6 +47,167 @@ void __iomem *cm2_base;
   
   #define MAX_MODULE_ENABLE_WAIT 10
   
  +/* Setup for the interrupt handling based on used platform */
  +static struct omap_prcm_irq_setup *irq_setup;
 
 you can set this is irq_chip data, then you can:
 
  +static void prcm_irq_ack(struct irq_data *data)
  +{
   struct omap_prcm_irq_setup  *irq_setup = 
 irq_data_get_irq_chip_data(data)
   unsigned intprcm_irq = data-irq - irq_setup-base;
 
   irq_setup-ack_event(prcm_irq);
  +}
 
 ditto to all other operations.
 
  +static struct irq_chip_generic 
  *prcm_irq_chips[OMAP_PRCM_MAX_NR_PENDING_REG];
 
 can't you allocate this dynamically ???
 
  +/*
  + * PRCM Interrupt Handler
  + *
  + * The PRM_IRQSTATUS_MPU register indicates if there are any pending
  + * interrupts from the PRCM for the MPU. These bits must be cleared in
  + * order to clear the PRCM interrupt. The PRCM interrupt handler is
  + * implemented to simply clear the PRM_IRQSTATUS_MPU in order to clear
  + * the PRCM interrupt. Please note that bit 0 of the PRM_IRQSTATUS_MPU
  + * register indicates that a wake-up event is pending for the MPU and
  + * this bit can only be cleared if the all the wake-up events latched
  + * in the various PM_WKST_x registers have been cleared. The interrupt
  + * handler is implemented using a do-while loop so that if a wake-up
  + * event occurred during the processing of the prcm interrupt handler
  + * (setting a bit in the corresponding PM_WKST_x register and thus
  + * preventing us from clearing bit 0 of the PRM_IRQSTATUS_MPU register)
  + * this would be handled.
  + */
  +static void prcm_irq_handler(unsigned int irq, struct irq_desc *desc)
  +{
  +   unsigned long pending[OMAP_PRCM_MAX_NR_PENDING_REG];
  +   struct irq_chip *chip = irq_desc_get_chip(desc);
  +
  +   /*
  +* Loop until all pending irqs are handled, since
  +* generic_handle_irq(), called by prcm_irq_handle_virtirqs()
  +* can cause new irqs to come
  +*/
  +   while (1) {
  +   unsigned int virtirq;
  +
  +   chip-irq_ack(desc-irq_data);
  +
  +   memset(pending, 0, sizeof(pending));
  +   irq_setup-pending_events(pending);
  +
  +   /* No bit set, then all IRQs are handled */
  +   if (find_first_bit(pending, OMAP_PRCM_NR_IRQS)
  +   = OMAP_PRCM_NR_IRQS) {
  +   chip-irq_unmask(desc-irq_data);
  +   break;
  +   }
  +
  +   /*
  +* Loop on all currently pending irqs so that new irqs
  +* cannot starve previously pending irqs
  +*/
  +   for_each_set_bit(virtirq, pending, OMAP_PRCM_NR_IRQS)
  +   generic_handle_irq(OMAP_PRCM_IRQ_BASE + virtirq);
 
 if you use nested IRQ threads, you could be using
 handle_nested_irq(irq);
 
  +   chip-irq_unmask(desc-irq_data);
  +   }
  +}
  +
  +/*
  + * Given a PRCM event name, returns the corresponding IRQ on which the
  + * handler should be registered.
  + */
  +int

Re: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation

2011-06-29 Thread Colin Cross

On Wed, Jun 29, 2011 at 7:00 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Tue, Jun 28, 2011 at 04:59:57PM -0700, Colin Cross wrote:
 On Tue, Jun 28, 2011 at 4:46 PM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
  On Tue, Jun 28, 2011 at 04:37:08PM -0700, Colin Cross wrote:
  I don't think it affects bogomips - loops_per_jiffy can still be
  calibrated and updated by cpufreq, udelay just wont use them.
 
  No, you can't avoid it.  __delay(), udelay(), and the global
  loops_per_jiffy are all linked together - for instance this is how
  the spinlock code has a 1s timeout:
 
  static void __spin_lock_debug(raw_spinlock_t *lock)
  {
         u64 loops = loops_per_jiffy * HZ;
         int print_once = 1;
 
         for (;;) {
                 for (i = 0; i  loops; i++) {
                         if (arch_spin_trylock(lock-raw_lock))
                                 return;
                         __delay(1);
                 }
 
  which goes wrong for all the same reasons you're pointing out about
  udelay().  So just restricting your argument to udelay() is not
  realistic.
 

 True, there are a few other users of loops_per_jiffy and __delay, but
 it looks like __spin_lock_debug is the only one worth worrying about,
 and it's timing is not as critical as udelay - worst case here is that
 the warning occurs after 250 ms instead of 1s.  Leaving
 loops_per_jiffy and __delay intact, and fixing udelay, would still be
 a net gain.

 Other users of loops_per_jiffy are incorrect in any case:

The same conclusion I came to on a quick scan of other uses of
loops_per_jiffy...

snip

 And strangely the major offender of this stuff are ARM drivers, not other
 peoples stuff and not stuff in drivers/staging.

 So I don't think its sane to ignore loops_per_jiffy and __delay, and just
 concentrate on udelay().

But this I don't understand.  Every other use I found of
loops_per_jiffy is incorrect and should be changed.  Fixing udelay now
would not make them any worse - they would stay just as broken as they
were, so there is no need to couple a fix to udelay with fixing other
users of loops_per_jiffy.  Why block a legitimate fix because some
other broken code uses a variable whose behavior would not change?

If you are requesting an alternate change that would allow __delay to
continue to be used to time loops while irqs are off and jiffies is
not being updated, but also allows loops_per_jiffy to change in the
middle of a loop, while not increasing the number of instructions
executed in __delay, I don't think that is possible.  You could
replace __delay with a function that tests against a timer, and
loops_per_jiffy with the frequency of the counter divided by HZ, but
that would limit your spinlock spins to the frequency of the counter -
1MHz on Tegra.

Are there ever other legitimate uses of loops_per_jiffy/__delay?  I
don't think even the spinlock_debug use is correct - the number of
instructions executed in the loop before the __delay call (I count 17)
is going to be much higher than the instructions in the __delay(1)
call (3 instructions).  The spinlock debug timeout is already going to
be much longer than expected.  It looks to me like the only legitimate
use of loops_per_jiffy is to calculate the number of loops and call
__delay(loops) (exactly what udelay does), the overhead of doing
anything else will swamp the __delay call.  spinlock debug can get
away with its incorrect usage, because it doesn't really care how long
the delay is, and must have a minimum overhead.
--
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: DSS: dispc: enable/disable clocks in error handler

2011-06-29 Thread Archit Taneja


Hi,

On Tuesday 28 June 2011 09:58 PM, Valkeinen, Tomi wrote:

On Tue, 2011-06-28 at 09:19 -0700, Archit Taneja wrote:

Hi,

On Monday 27 June 2011 10:31 AM, Dima Zavin wrote:

There's no guarantee that the error handler worker thread
will run while the dispc clocks are on. Explicitly enable/disable
them.


I agree with this.


Yes, I think this patch is fine. I'll apply it to DSS tree.


Tomi,

We could get prevent scheduling of the error worker by registering
omap_dispc_irq_handler() as an interrupt thread.


But then we would get extra latency on the interrupt handlers. I wanted
to keep handling DSS interrupts in interrupt context, because some use
cases may require very fast reaction to an interrupt.


Okay..we don't need to handle the errors in interrupt context..the 
request_threaded_irq() takes 2 functions I think, we could have have 
omap_dispc_irq_handler() as the primary handler, and the error_worker as 
the thread.


I think the change I'm just suggesting just leads to some beautification 
in the end :), we would still need to ensure that clocks are enabled in 
the error_worker path.


Archit


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

Re: [PATCH] OMAP3: run the ASM sleep code from DDR

jean.pi...@newoldbits.com writes:

 From: Jean Pihet j-pi...@ti.com

 Most of the ASM sleep code (in arch/arm/mach-omap2/sleep34xx.S)
 is copied to internal SRAM at boot and after wake-up from CORE OFF mode.
 However only a small part of the code really needs to run from internal SRAM.

 This fix lets most of the ASM idle code run from the DDR
 in order to minimize the SRAM usage and the overhead in the code copy.

 The only pieces of code that are mandatory in SRAM are:
 - the i443 erratum WA,
 - the i581 erratum WA,
 - the security extension code.

 SRAM usage:
 - original code:
   . 560 bytes for omap3_sram_configure_core_dpll (used by DVFS),
   . 852 bytes for omap_sram_idle (used by suspend/resume in RETention),
   . 124 bytes for es3_sdrc_fix (used by suspend/resume in OFF mode on ES3.x),
   . 108 bytes for save_secure_ram_context (used on HS parts only).

 With this fix the usage for suspend/resume in RETention goes down 288 bytes,
 so the gain in SRAM usage for suspend/resume is 564 bytes.

 Also fixed the SRAM initialization sequence to avoid an unnecessary
 copy to SRAM at boot time and for readability.

 Tested on Beagleboard (ES2.x) in idle with full RET and OFF modes.

 Signed-off-by: Jean Pihet j-pi...@ti.com

Reviewed-by: Kevin Hilman khil...@ti.com

Also tested retention and off on 3430/n900, 3530/Overo and 3630/Zoom3

Tested-by: Kevin Hilman khil...@ti.com

Russell, if you're OK with it, can you add it to your suspend branch for
the upcoming merge window?

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

Re: [PATCH 4/4] mfd: global Suspend and resume support of ehci and ohci

2011-06-29 Thread Alan Stern

On Wed, 29 Jun 2011, Munegowda, Keshava wrote:

 for usb host case , I am seeing that the pm_runtime_get_sync
 
 
 static int rpm_resume(struct device *dev, int rpmflags)
 {
   
  ..
   if (dev-pwr_domain) {
   callback = dev-pwr_domain-ops.runtime_resume;
   if(!strcmp(dev_name(dev),usbhs_omap))
pr_err(dev-pwr_domain-ops.runtime_resume);
   }   
   else if (dev-type  dev-type-pm) {
   callback = dev-type-pm-runtime_resume;
   if(!strcmp(dev_name(dev),usbhs_omap))
pr_err(dev-type-pm-runtime_resume);
   }   
   else if (dev-class  dev-class-pm) {
   callback = dev-class-pm-runtime_resume;
   if(!strcmp(dev_name(dev),usbhs_omap))
pr_err(ev-class-pm-runtime_resume);
   }   
   else if (dev-bus  dev-bus-pm) {
   callback = dev-bus-pm-runtime_resume;
   if(!strcmp(dev_name(dev),usbhs_omap))
pr_err(dev-bus-pm-runtime_resume);
   }   
   else
   callback = NULL;
 }
 
 
 I am seeing that below if statement was hitting true:
 
   if (dev-pwr_domain) {
   callback = dev-pwr_domain-ops.runtime_resume;
   if(!strcmp(dev_name(dev),usbhs_omap))
pr_err(dev-pwr_domain-ops.runtime_resume);
 
 
 due to this; the driver-runtime_resume was not getting called.
 
 Any idea on why I am seeing only the dev-pwr_domain is set not
 dev-bus  dev-bus-pm is hitting here?

Because the PM domain takes precedence over the subsystem for PM 
callbacks.  If the subsystem routine should be called then the PM 
domain code has to call it.

Alan Stern

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

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

T Krishnamoorthy, Balaji balaj...@ti.com writes:

 On Wed, Jun 29, 2011 at 2:00 AM, Kevin Hilman khil...@ti.com wrote:
 T Krishnamoorthy, Balaji balaj...@ti.com writes:

 On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley p...@pwsan.com wrote:
 (cc'ing Adrian also)

 Hi Balaji

 On Wed, 22 Jun 2011, Balaji T K wrote:

 Use runtime autosuspend APIs to enable auto suspend delay

 Does this really need to use runtime autosuspend?  Seems to me that since
 PM runtime is just controlling the MMC IP blocks and not the regulators in
 this instance, this could simply use pm_runtime_put*() and just avoid the
 extra power wastage and complexity involved in autosuspend.


 I have seen some instabilities if delay is very less, on some production 
 boards.
 The previous implementation used 100ms delay before disabling the clocks.

 And your new one is using 50ms.  How did this value come about?


 I don't have any specific affinity to this number, but when requests
 are bursty, they arrive within a few 10s of ms within each
 other. Didn't want to have the context/save restore penalty associated
 with every request.

Have you measured the context save/restore penalty when only the clocks
are gated (and no regulators involved) ?

In the current code, it's understandable why there were large latencies
that were avoided because the regulators were also cut.  With only the
clocks being cut, the latency involved will be significantly less.

 As Paul mentioned, the timeout value here is probably usecase depeend


 There is no direct relationship to the use case. Block layer buffers
 and reworks the order of requests and they are usually queued
 together. Having no context save / restore penalty for each request is
 definitely desirable.  

Desirable for what?

What is implied in that statement is desirable for performance.

What if a different user would prefer the power savings gained by more
aggressively cuttting clocks over the performance gains of leaving
clocks enabled?

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

Re: [PATCH] OMAP3: run the ASM sleep code from DDR

2011-06-29 Thread Jean Pihet

On Wed, Jun 29, 2011 at 7:29 PM, Kevin Hilman khil...@ti.com wrote:
 jean.pi...@newoldbits.com writes:

 From: Jean Pihet j-pi...@ti.com

 Most of the ASM sleep code (in arch/arm/mach-omap2/sleep34xx.S)
 is copied to internal SRAM at boot and after wake-up from CORE OFF mode.
 However only a small part of the code really needs to run from internal SRAM.

 This fix lets most of the ASM idle code run from the DDR
 in order to minimize the SRAM usage and the overhead in the code copy.

 The only pieces of code that are mandatory in SRAM are:
 - the i443 erratum WA,
 - the i581 erratum WA,
 - the security extension code.

 SRAM usage:
 - original code:
   . 560 bytes for omap3_sram_configure_core_dpll (used by DVFS),
   . 852 bytes for omap_sram_idle (used by suspend/resume in RETention),
   . 124 bytes for es3_sdrc_fix (used by suspend/resume in OFF mode on ES3.x),
   . 108 bytes for save_secure_ram_context (used on HS parts only).

 With this fix the usage for suspend/resume in RETention goes down 288 bytes,
 so the gain in SRAM usage for suspend/resume is 564 bytes.

 Also fixed the SRAM initialization sequence to avoid an unnecessary
 copy to SRAM at boot time and for readability.

 Tested on Beagleboard (ES2.x) in idle with full RET and OFF modes.

 Signed-off-by: Jean Pihet j-pi...@ti.com

 Reviewed-by: Kevin Hilman khil...@ti.com

 Also tested retention and off on 3430/n900, 3530/Overo and 3630/Zoom3

 Tested-by: Kevin Hilman khil...@ti.com
Thanks for the extensive testing!

Regards,
Jean


 Russell, if you're OK with it, can you add it to your suspend branch for
 the upcoming merge window?

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

T Krishnamoorthy, Balaji balaj...@ti.com writes:

 On Wed, Jun 29, 2011 at 5:02 AM, Kevin Hilman khil...@ti.com wrote:
 +Rajendra

 Balaji T K balaj...@ti.com writes:

 add runtime pm support to HSMMC host controller
 Use runtime pm API to enable/disable HSMMC clock
 Use runtime autosuspend APIs to enable auto suspend delay

 Based on OMAP HSMMC runtime implementation by Kevin Hilman, Kishore Kadiyala

 Signed-off-by: Balaji T K balaj...@ti.com

 I tried to test this series along with Benoit's clkdm/modulemode/hwmod
 cleanups and something strange is happening on OMAP4.

 First, this series by itself is working as I would expect, but testing
 in combination with Benoit's series, it's different...

 First, I'm using Benoit's branch:

       git://gitorious.org/omap-pm/linux.git for_3.0.1/7_hwmod_modulemode

 in combination with your series.

 I've also reverted these two commits:

   OMAP4: PM: TEMP: Prevent l3init from idling/force sleep
   OMAP3+: hwmod data: TEMP: Do not idle MMC1  MMC2 after boot

 which are temporary workarounds for not having MMC runtime PM.

 I turned the dev_dbg calls in the runtime PM callbacks into dev_info
 callbacks to see exactly when the device is enabled/disabled via runtime
 PM.

 To my surprise, I didn't see the device being enabled/disabled when
 writing do the device.

 I tried for_3.0.1/7_hwmod_modulemode as you mentioned above,
 changing dev_dbg to dev_err and I am not observing the delayed write
 during umount. Can you let me know if the files are there in MMC after
 remounting ?

Did you also revert the above two commits?

I've pushed a 'tmp/mmc' branch to my git tree[1] which is my PM branch
(including various PM stuff queued for upstream) as well as Benoit's
series with the TEMP patches above reverted and your series on top of
it.  There's one additional patch to convert the dev_dbg into dev_info
to see the transitions.

Testing this on my OMAP4430 ES2.2 EMU device, I still see the above
behavior.

Can you try out this branch on your board using the default
omap2plus_defconfig?

Thanks,

Kevin

[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
--
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] OMAP3: run the ASM sleep code from DDR

On Wed, Jun 29, 2011 at 10:29:49AM -0700, Kevin Hilman wrote:
 Russell, if you're OK with it, can you add it to your suspend branch for
 the upcoming merge window?

Yes - though I think we can go a little bit further - this patch is on
top of my code so far, and is untested.  There isn't a need for the
saving of these registers to be in assembly because we can read them
just as easily from C code.

Comments?

 arch/arm/mach-omap2/pm.h|2 +-
 arch/arm/mach-omap2/pm34xx.c|   19 +--
 arch/arm/mach-omap2/sleep34xx.S |   12 ++--
 3 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 45bcfce..4984cca 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -92,7 +92,7 @@ extern void omap24xx_idle_loop_suspend(void);
 
 extern void omap24xx_cpu_suspend(u32 dll_ctrl, void __iomem *sdrc_dlla_ctrl,
void __iomem *sdrc_power);
-extern void omap34xx_cpu_suspend(u32 *addr, int save_state);
+extern void omap34xx_cpu_suspend(int save_state);
 extern int save_secure_ram_context(u32 *addr);
 extern void omap3_save_scratchpad_contents(void);
 
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 3e9a13e..6366352 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -78,7 +78,7 @@ struct power_state {
 
 static LIST_HEAD(pwrst_list);
 
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
+static void (*_omap_sram_idle)(int save_state);
 
 static int (*_omap_save_secure_sram)(u32 *addr);
 
@@ -307,9 +307,22 @@ static irqreturn_t prcm_interrupt_handler (int irq, void 
*dev_id)
return IRQ_HANDLED;
 }
 
+static void omap34xx_save_context(u32 *save)
+{
+   u32 val;
+
+   asm(mrc p15, 0, %0, c1, c0, 1 : =r (val));
+   *save++ = 1;
+   *save++ = val;
+
+   asm(mrc p15, 1, %0, c9, c0, 2 : =r (val));
+   *save++ = 1;
+   *save++ = val;
+}
+
 static void omap34xx_do_sram_idle(unsigned long save_state)
 {
-   _omap_sram_idle(omap3_arm_context, save_state);
+   _omap_sram_idle(save_state);
 }
 
 void omap_sram_idle(void)
@@ -412,6 +425,8 @@ void omap_sram_idle(void)
 * get saved. The rest is placed on the stack, and restored
 * from there before resuming.
 */
+   if (save_state)
+   omap34xx_save_context(omap3_arm_context);
if (save_state == 1 || save_state == 3)
cpu_suspend(save_state, omap34xx_do_sram_idle);
else
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index d18f52e..3335753 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -150,8 +150,7 @@ ENTRY(omap34xx_cpu_suspend)
stmfd   sp!, {r4 - r11, lr} @ save registers on stack
 
/*
-* r0 contains CPU context save/restore pointer in sdram
-* r1 contains information about saving context:
+* r0 contains information about saving context:
 *   0 - No context lost
 *   1 - Only L1 and logic lost
 *   2 - Only L2 lost (Even L1 is retained we clean it along with L2)
@@ -159,18 +158,11 @@ ENTRY(omap34xx_cpu_suspend)
 */
 
/* Directly jump to WFI is the context save is not required */
-   cmp r1, #0x0
+   cmp r0, #0x0
beq omap3_do_wfi
 
/* Otherwise fall through to the save context code */
 save_context_wfi:
-   mov r8, r0  @ Store SDRAM address in r8
-   mrc p15, 0, r5, c1, c0, 1   @ Read Auxiliary Control Register
-   mov r4, #0x1@ Number of parameters for restore call
-   stmia   r8!, {r4-r5}@ Push parameters for restore call
-   mrc p15, 1, r5, c9, c0, 2   @ Read L2 AUX ctrl register
-   stmia   r8!, {r4-r5}@ Push parameters for restore call
-
/*
 * jump out to kernel flush routine
 *  - reuse that code is better
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 4/4] mfd: global Suspend and resume support of ehci and ohci

2011-06-29 Thread Partha Basak

-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Wednesday, June 29, 2011 11:03 PM
To: Munegowda, Keshava
Cc: Kevin Hilman; linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
linux-ker...@vger.kernel.org; ba...@ti.com; gadi...@ti.com;
sa...@linux.intel.com; part...@india.ti.com; t...@atomide.com; b-
cous...@ti.com; p...@pwsan.com
Subject: Re: [PATCH 4/4] mfd: global Suspend and resume support of ehci
and ohci

On Wed, 29 Jun 2011, Munegowda, Keshava wrote:

 for usb host case , I am seeing that the pm_runtime_get_sync


 static int rpm_resume(struct device *dev, int rpmflags)
 {
   
  ..
  if (dev-pwr_domain) {
  callback = dev-pwr_domain-ops.runtime_resume;
  if(!strcmp(dev_name(dev),usbhs_omap))
   pr_err(dev-pwr_domain-ops.runtime_resume);
  }
  else if (dev-type  dev-type-pm) {
  callback = dev-type-pm-runtime_resume;
  if(!strcmp(dev_name(dev),usbhs_omap))
   pr_err(dev-type-pm-runtime_resume);
  }
  else if (dev-class  dev-class-pm) {
  callback = dev-class-pm-runtime_resume;
  if(!strcmp(dev_name(dev),usbhs_omap))
   pr_err(ev-class-pm-runtime_resume);
  }
  else if (dev-bus  dev-bus-pm) {
  callback = dev-bus-pm-runtime_resume;
  if(!strcmp(dev_name(dev),usbhs_omap))
   pr_err(dev-bus-pm-runtime_resume);
  }
  else
  callback = NULL;
 }


 I am seeing that below if statement was hitting true:

  if (dev-pwr_domain) {
  callback = dev-pwr_domain-ops.runtime_resume;
  if(!strcmp(dev_name(dev),usbhs_omap))
   pr_err(dev-pwr_domain-ops.runtime_resume);


 due to this; the driver-runtime_resume was not getting called.

 Any idea on why I am seeing only the dev-pwr_domain is set not
 dev-bus  dev-bus-pm is hitting here?

Because the PM domain takes precedence over the subsystem for PM
callbacks.  If the subsystem routine should be called then the PM
domain code has to call it.

This is taken care of in the pm-domain code:
static int _od_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);

omap_device_enable(pdev);

return pm_generic_runtime_resume(dev);
}
pm_generic_runtime_resume will in turn call the driver call back.

int pm_generic_runtime_resume(struct device *dev)
{
const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm :
NULL;
int ret;

ret = pm  pm-runtime_resume ? pm-runtime_resume(dev) : 0;

return ret;
}

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

Re: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation

2011-06-29 Thread Stephen Boyd

On 06/28/2011 04:17 PM, Russell King - ARM Linux wrote:

 That's why people have proposed hardware-timer based delay loops -
 these screw up the bogomips value (it no longer refers to the CPU
 but to the timer used for the delays) and the code proposed thus far
 probably has a severe negative impact on ARMs running at low clock
 rates (the calculation cost of the number of loops to run becomes
 significant for CPUs below 100MHz for short delays with the existing
 optimized assembler, so moving it into C and introducing function
 pointers will only make it worse.)

Am I people? ;-)

The code I've proposed doesn't seem to have a negative impact on our
targets even when the processor is running at 19.2 Mhz. Before and after
the patches I get the same lpj value (this is all described in the
commit text). I've also shown that rewriting delay.S into C doesn't
negatively affect the hand optimized assembly as the before and after
object code is nearly identical modulo register allocation. The only
issue would be the one function pointer which I haven't heard anyone
complain about until now.

Even if the time to get into the __delay() routine increases by a few
instructions I don't see how this harms anything as udelay() is a
minimum time guarantee. We should strive to make it as close as possible
to the time requested by the caller, but we shouldn't balk at the
introduction of a few more cycles along the setup path. Finally, since
the calibration takes into account most of the new instructions I doubt
it will even be noticeable overhead to have the function pointers.

What more can I do to convince you to take this patch?

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

--
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: platsmp: Allow secondary cpu hotplug with maxcpus=1

2011-06-29 Thread Stephen Boyd

If an ARM system has multiple cpus in the same socket and the
kernel is booted with maxcpus=1, secondary cpus are possible but
not present due to how platform_smp_prepare_cpus() is called.
Fix this by always calling platform_smp_prepare_cpus() as long as
max_cpus is non-zero (0 means no SMP) to allow platform code to
decide if any non-boot cpus are present in the system. Since
all current platform code doesn't support physical hotplug we
have a situation where possible == present and thus we can
simply copy the possible map to the present map.

With this patch it's possible to boot an ARM system with
maxcpus=1 on the command line and then hotplug in secondary cpus
via sysfs. This is more in line with how x86 works with maxcpus=1
on the command line.

Signed-off-by: Stephen Boyd sb...@codeaurora.org
---

This patch was tested along with an MSM patch:

  https://lkml.org/lkml/2011/4/7/354

I don't have any non-MSM hardware to test on so Acks and
tested-bys are welcome.

 arch/arm/kernel/smp.c |3 +--
 arch/arm/mach-exynos4/platsmp.c   |5 +
 arch/arm/mach-msm/platsmp.c   |5 +
 arch/arm/mach-omap2/omap-smp.c|5 +
 arch/arm/mach-realview/platsmp.c  |5 +
 arch/arm/mach-shmobile/platsmp.c  |5 +
 arch/arm/mach-tegra/platsmp.c |5 +
 arch/arm/mach-ux500/platsmp.c |5 +
 arch/arm/mach-vexpress/ct-ca9x4.c |5 +
 9 files changed, 9 insertions(+), 34 deletions(-)

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index e7f92a4..fbaa24a 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -365,8 +365,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
 */
if (max_cpus  ncores)
max_cpus = ncores;
-
-   if (max_cpus  1) {
+   if (ncores  1  max_cpus) {
/*
 * Enable the local timer or broadcast device for the
 * boot CPU, but only if we have more than one CPU.
diff --git a/arch/arm/mach-exynos4/platsmp.c b/arch/arm/mach-exynos4/platsmp.c
index c5e65a0..3f870d2 100644
--- a/arch/arm/mach-exynos4/platsmp.c
+++ b/arch/arm/mach-exynos4/platsmp.c
@@ -154,14 +154,11 @@ void __init smp_init_cpus(void)
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
 {
-   int i;
-
/*
 * Initialise the present map, which describes the set of CPUs
 * actually populated at the present time.
 */
-   for (i = 0; i  max_cpus; i++)
-   set_cpu_present(i, true);
+   init_cpu_present(cpu_possible_map);
 
scu_enable(scu_base_addr());
 
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 2034098..84e293f 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -157,12 +157,9 @@ void __init smp_init_cpus(void)
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
 {
-   int i;
-
/*
 * Initialise the present map, which describes the set of CPUs
 * actually populated at the present time.
 */
-   for (i = 0; i  max_cpus; i++)
-   set_cpu_present(i, true);
+   init_cpu_present(cpu_possible_map);
 }
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index ecfe93c..5895d19 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -125,14 +125,11 @@ void __init smp_init_cpus(void)
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
 {
-   int i;
-
/*
 * Initialise the present map, which describes the set of CPUs
 * actually populated at the present time.
 */
-   for (i = 0; i  max_cpus; i++)
-   set_cpu_present(i, true);
+   init_cpu_present(cpu_possible_map);
 
/*
 * Initialise the SCU and wake up the secondary core using
diff --git a/arch/arm/mach-realview/platsmp.c b/arch/arm/mach-realview/platsmp.c
index 963bf0d..00666be 100644
--- a/arch/arm/mach-realview/platsmp.c
+++ b/arch/arm/mach-realview/platsmp.c
@@ -68,14 +68,11 @@ void __init smp_init_cpus(void)
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
 {
-   int i;
-
/*
 * Initialise the present map, which describes the set of CPUs
 * actually populated at the present time.
 */
-   for (i = 0; i  max_cpus; i++)
-   set_cpu_present(i, true);
+   init_cpu_present(cpu_possible_map);
 
scu_enable(scu_base_addr());
 
diff --git a/arch/arm/mach-shmobile/platsmp.c b/arch/arm/mach-shmobile/platsmp.c
index f3888fe..ca5b523 100644
--- a/arch/arm/mach-shmobile/platsmp.c
+++ b/arch/arm/mach-shmobile/platsmp.c
@@ -64,10 +64,7 @@ void __init smp_init_cpus(void)
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
 {
-   int i;
-
-   for (i = 0; i  max_cpus; i++)
-   set_cpu_present(i, true);
+   init_cpu_present(cpu_possible_map);
 
shmobile_smp_prepare_cpus();
 }
diff --git

Re: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation

On Wed, Jun 29, 2011 at 11:29:29AM -0700, Stephen Boyd wrote:
 On 06/28/2011 04:17 PM, Russell King - ARM Linux wrote:
 
  That's why people have proposed hardware-timer based delay loops -
  these screw up the bogomips value (it no longer refers to the CPU
  but to the timer used for the delays) and the code proposed thus far
  probably has a severe negative impact on ARMs running at low clock
  rates (the calculation cost of the number of loops to run becomes
  significant for CPUs below 100MHz for short delays with the existing
  optimized assembler, so moving it into C and introducing function
  pointers will only make it worse.)
 
 Am I people? ;-)

That depends if you're a multiple personality person!

 The code I've proposed doesn't seem to have a negative impact on our
 targets even when the processor is running at 19.2 Mhz. Before and after
 the patches I get the same lpj value (this is all described in the
 commit text). I've also shown that rewriting delay.S into C doesn't
 negatively affect the hand optimized assembly as the before and after
 object code is nearly identical modulo register allocation. The only
 issue would be the one function pointer which I haven't heard anyone
 complain about until now.
 
 Even if the time to get into the __delay() routine increases by a few
 instructions I don't see how this harms anything as udelay() is a
 minimum time guarantee. We should strive to make it as close as possible
 to the time requested by the caller, but we shouldn't balk at the
 introduction of a few more cycles along the setup path. Finally, since
 the calibration takes into account most of the new instructions I doubt
 it will even be noticeable overhead to have the function pointers.
 
 What more can I do to convince you to take this patch?

What I'm aware of is that I did create a kernel-side parport jtag driver,
and the limiting factor in that was udelay(), or rather udelay(1) not
giving a delay of 1us but several us longer - and that was tracked down
to the overhead of the CPU getting into __delay.

So, having experienced that problem I'm over-sensitive towards it...
--
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] mfd: global Suspend and resume support of ehci and ohci

2011-06-29 Thread Alan Stern

On Wed, 29 Jun 2011, Partha Basak wrote:

 -Original Message-
 From: Alan Stern [mailto:st...@rowland.harvard.edu]
 Sent: Wednesday, June 29, 2011 11:03 PM
 To: Munegowda, Keshava
 Cc: Kevin Hilman; linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
 linux-ker...@vger.kernel.org; ba...@ti.com; gadi...@ti.com;
 sa...@linux.intel.com; part...@india.ti.com; t...@atomide.com; b-
 cous...@ti.com; p...@pwsan.com
 Subject: Re: [PATCH 4/4] mfd: global Suspend and resume support of ehci
 and ohci
 
 On Wed, 29 Jun 2011, Munegowda, Keshava wrote:
 
  for usb host case , I am seeing that the pm_runtime_get_sync
 
 
  static int rpm_resume(struct device *dev, int rpmflags)
  {

   ..
 if (dev-pwr_domain) {
 callback = dev-pwr_domain-ops.runtime_resume;
 if(!strcmp(dev_name(dev),usbhs_omap))
  pr_err(dev-pwr_domain-ops.runtime_resume);
 }
 else if (dev-type  dev-type-pm) {
 callback = dev-type-pm-runtime_resume;
 if(!strcmp(dev_name(dev),usbhs_omap))
  pr_err(dev-type-pm-runtime_resume);
 }
 else if (dev-class  dev-class-pm) {
 callback = dev-class-pm-runtime_resume;
 if(!strcmp(dev_name(dev),usbhs_omap))
  pr_err(ev-class-pm-runtime_resume);
 }
 else if (dev-bus  dev-bus-pm) {
 callback = dev-bus-pm-runtime_resume;
 if(!strcmp(dev_name(dev),usbhs_omap))
  pr_err(dev-bus-pm-runtime_resume);
 }
 else
 callback = NULL;
  }
 
 
  I am seeing that below if statement was hitting true:
 
 if (dev-pwr_domain) {
 callback = dev-pwr_domain-ops.runtime_resume;
 if(!strcmp(dev_name(dev),usbhs_omap))
  pr_err(dev-pwr_domain-ops.runtime_resume);
 
 
  due to this; the driver-runtime_resume was not getting called.
 
  Any idea on why I am seeing only the dev-pwr_domain is set not
  dev-bus  dev-bus-pm is hitting here?
 
 Because the PM domain takes precedence over the subsystem for PM
 callbacks.  If the subsystem routine should be called then the PM
 domain code has to call it.
 
 This is taken care of in the pm-domain code:
 static int _od_runtime_resume(struct device *dev)
 {
   struct platform_device *pdev = to_platform_device(dev);
 
   omap_device_enable(pdev);
 
   return pm_generic_runtime_resume(dev);
 }
 pm_generic_runtime_resume will in turn call the driver call back.
 
 int pm_generic_runtime_resume(struct device *dev)
 {
   const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm :
 NULL;
   int ret;
 
   ret = pm  pm-runtime_resume ? pm-runtime_resume(dev) : 0;
 
   return ret;
 }

You appear to be contradicting what Keshava wrote: due to this; the
driver-runtime_resume was not getting called.

You can't both be right.

Alan Stern


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

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

+ Venkat

Hi Balaji, Venkat,

On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:

 OOPS pointed to omap_hsmmc_prepare_data / set_data_timeout
 Use case was MMC + SDIO +GPS activity, on kernel 2.6.35 though.
 
 Unhandled fault: imprecise external abort (0x1406) at 0x4073102c
   ^

That's not good...

 Internal error: : 1406 [#1] PREEMPT SMP
 last sysfs file: /sys/devices/platform/switch-sio/usb_sel
 Modules linked in: param(P) j4fs(P) vibetonz Si4709_driver fm_drv(C)
 bt_drv(C) st_drv(C)
 CPU: 0Tainted: PWC   (2.6.35.7 #2)
^^

Neither is this...

 PC is at clk_get_rate+0x4/0x48
 LR is at set_data_timeout+0x68/0xf4
 [c06e78e0] (set_data_timeout+0x0/0xf4) from [c06e7dc8]
 (omap_hsmmc_request+0x2d0/0x5c8)
  r8:efa78400 r7:0001 r6: r5:ef9efe78 r4:efa78640
 r3:ef9efee4
 [c06e7af8] (omap_hsmmc_request+0x0/0x5c8) from [c06df040]
 (mmc_wait_for_req+0x118/0x130)
 [c06def28] (mmc_wait_for_req+0x0/0x130) from [c06e59e8]
 (mmc_blk_issue_rq+0x1c0/0x500)
  r6:ef86f000 r5:efa79000 r4:c91e61a0
 [c06e5828] (mmc_blk_issue_rq+0x0/0x500) from [c06e6620]
 (mmc_queue_thread+0xf4/0xf8)
 [c06e652c] (mmc_queue_thread+0x0/0xf8) from [c045ddec] (kthread+0x84/0x8c)
 [c045dd68] (kthread+0x0/0x8c) from [c044b748] (do_exit+0x0/0x604)
  r7:0013 r6:c044b748 r5:c045dd68 r4:ef8d5d68

Was CONFIG_PM enabled?  If so, was off-mode enabled for any IP blocks, or 
was it just clock-stop and/or retention?


- Paul
--
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] OMAP3: run the ASM sleep code from DDR

Russell King - ARM Linux li...@arm.linux.org.uk writes:

 On Wed, Jun 29, 2011 at 10:29:49AM -0700, Kevin Hilman wrote:
 Russell, if you're OK with it, can you add it to your suspend branch for
 the upcoming merge window?

 Yes - though I think we can go a little bit further - this patch is on
 top of my code so far, and is untested.  There isn't a need for the
 saving of these registers to be in assembly because we can read them
 just as easily from C code.

Indeed

 Comments?

Looks good to me (although untested) care to respin on top of $SUBJECT
patch?  

Minor comments below...

  arch/arm/mach-omap2/pm.h|2 +-
  arch/arm/mach-omap2/pm34xx.c|   19 +--
  arch/arm/mach-omap2/sleep34xx.S |   12 ++--
  3 files changed, 20 insertions(+), 13 deletions(-)

 diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
 index 45bcfce..4984cca 100644
 --- a/arch/arm/mach-omap2/pm.h
 +++ b/arch/arm/mach-omap2/pm.h
 @@ -92,7 +92,7 @@ extern void omap24xx_idle_loop_suspend(void);
  
  extern void omap24xx_cpu_suspend(u32 dll_ctrl, void __iomem *sdrc_dlla_ctrl,
   void __iomem *sdrc_power);
 -extern void omap34xx_cpu_suspend(u32 *addr, int save_state);
 +extern void omap34xx_cpu_suspend(int save_state);
  extern int save_secure_ram_context(u32 *addr);
  extern void omap3_save_scratchpad_contents(void);
  
 diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
 index 3e9a13e..6366352 100644
 --- a/arch/arm/mach-omap2/pm34xx.c
 +++ b/arch/arm/mach-omap2/pm34xx.c
 @@ -78,7 +78,7 @@ struct power_state {
  
  static LIST_HEAD(pwrst_list);
  
 -static void (*_omap_sram_idle)(u32 *addr, int save_state);
 +static void (*_omap_sram_idle)(int save_state);
  
  static int (*_omap_save_secure_sram)(u32 *addr);
  
 @@ -307,9 +307,22 @@ static irqreturn_t prcm_interrupt_handler (int irq, void 
 *dev_id)
   return IRQ_HANDLED;
  }
  
 +static void omap34xx_save_context(u32 *save)
 +{
 + u32 val;
 +
 + asm(mrc p15, 0, %0, c1, c0, 1 : =r (val));

Minor: for those of us who don't have all these registers memorized when
looking at the assembly, maybe keeping the original comments (e.g. Read
AUX 

 + *save++ = 1;
 + *save++ = val;
 +
 + asm(mrc p15, 1, %0, c9, c0, 2 : =r (val));
 + *save++ = 1;
 + *save++ = val;
 +}
 +
  static void omap34xx_do_sram_idle(unsigned long save_state)
  {
 - _omap_sram_idle(omap3_arm_context, save_state);
 + _omap_sram_idle(save_state);
  }
  
  void omap_sram_idle(void)
 @@ -412,6 +425,8 @@ void omap_sram_idle(void)
* get saved. The rest is placed on the stack, and restored
* from there before resuming.
*/
 + if (save_state)
 + omap34xx_save_context(omap3_arm_context);
   if (save_state == 1 || save_state == 3)
   cpu_suspend(save_state, omap34xx_do_sram_idle);
   else
 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
 index d18f52e..3335753 100644
 --- a/arch/arm/mach-omap2/sleep34xx.S
 +++ b/arch/arm/mach-omap2/sleep34xx.S
 @@ -150,8 +150,7 @@ ENTRY(omap34xx_cpu_suspend)
   stmfd   sp!, {r4 - r11, lr} @ save registers on stack
  
   /*
 -  * r0 contains CPU context save/restore pointer in sdram
 -  * r1 contains information about saving context:
 +  * r0 contains information about saving context:
*   0 - No context lost
*   1 - Only L1 and logic lost
*   2 - Only L2 lost (Even L1 is retained we clean it along with L2)
 @@ -159,18 +158,11 @@ ENTRY(omap34xx_cpu_suspend)
*/
  
   /* Directly jump to WFI is the context save is not required */
 - cmp r1, #0x0
 + cmp r0, #0x0
   beq omap3_do_wfi
  
   /* Otherwise fall through to the save context code */
  save_context_wfi:
 - mov r8, r0  @ Store SDRAM address in r8
 - mrc p15, 0, r5, c1, c0, 1   @ Read Auxiliary Control Register
 - mov r4, #0x1@ Number of parameters for restore call
 - stmia   r8!, {r4-r5}@ Push parameters for restore call
 - mrc p15, 1, r5, c9, c0, 2   @ Read L2 AUX ctrl register
 - stmia   r8!, {r4-r5}@ Push parameters for restore call
 -
   /*
* jump out to kernel flush routine
*  - reuse that code is better
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] mfd: global Suspend and resume support of ehci and ohci

Munegowda, Keshava keshava_mgo...@ti.com writes:

 On Wed, Jun 29, 2011 at 8:52 PM, Munegowda, Keshava
 keshava_mgo...@ti.com wrote:
 On Thu, Jun 2, 2011 at 5:36 AM, Kevin Hilman khil...@ti.com wrote:
 Keshava Munegowda keshava_mgo...@ti.com writes:

 From: Keshava Munegowda keshava_mgo...@ti.com

 The global suspend and resume functions for usbhs core driver
 are implemented.These routine are called when the global suspend
 and resume occurs. Before calling these functions, the
 bus suspend and resume of ehci and ohci drivers are called
 from runtime pm.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com

 First, from what I can see, this is only a partial implementation of
 runtime PM.  What I mean is that the runtime PM methods are used only
 during the suspend path.  The rest of the time the USB host IP block is
 left enabled, even when nothing is connected.

 I tested this on my 3530/Overo board, and verified that indeed the
 usbhost powerdomain hits retention on suspend, but while idle, when
 nothing is connected, I would expect the driver could be clever enough
 to use runtime PM (probably using autosuspend timeouts) to disable the
 hardware as well.

 ---
  drivers/mfd/omap-usb-host.c |  103 
 +++
  1 files changed, 103 insertions(+), 0 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 43de12a..32d19e2 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -146,6 +146,10 @@
  #define is_ehci_hsic_mode(x) (x == OMAP_EHCI_PORT_MODE_HSIC)


 +/* USBHS state bits */
 +#define OMAP_USBHS_INIT              0
 +#define OMAP_USBHS_SUSPEND   4

 These additional state bits don't seem to be necessary.

 For suspend, just check 'pm_runtime_is_suspended()'

 The init flag is only used in the suspend/resume hooks, but the need for
 it is a side effect of not correctly using the runtime PM callbacks.

 Remember that the runtime PM get/put hooks have usage counting.  Only
 when the usage count transitions to/from zero is the actual
 hardware-level enable/disable (via omap_hwmod) being done.

 The current code is making the assumption that every call to get/put is
 going to result in an enable/disable of the hardware.

 Instead, all of the code that needs to be run only upon actual
 enable/disable of the hardware should be done in the driver's
 runtime_suspend/runtime_resume callbacks.  These are only called when
 the hardware actually changes state.

 Not knowing that much about the EHCI block, upon first glance, it looks
 like mmuch of what is done in usbhs_enable() should actually be done in
 the -runtime_resume() callback, and similarily, much of what is done in
 usbhs_disable() should be done in the -runtime_suspend() callback.

 Kevin,
   do you mean driver-runtime_resume and driver-runtime_resume call backs.
 are these call backs from pm_runtime_get_sync and pm_runtime_put_sync?

 for usb host case , I am seeing that the pm_runtime_get_sync


 static int rpm_resume(struct device *dev, int rpmflags)
 {
   
  ..
   if (dev-pwr_domain) {
   callback = dev-pwr_domain-ops.runtime_resume;
   if(!strcmp(dev_name(dev),usbhs_omap))
pr_err(dev-pwr_domain-ops.runtime_resume);
   }   
   else if (dev-type  dev-type-pm) {
   callback = dev-type-pm-runtime_resume;
   if(!strcmp(dev_name(dev),usbhs_omap))
pr_err(dev-type-pm-runtime_resume);
   }   
   else if (dev-class  dev-class-pm) {
   callback = dev-class-pm-runtime_resume;
   if(!strcmp(dev_name(dev),usbhs_omap))
pr_err(ev-class-pm-runtime_resume);
   }   
   else if (dev-bus  dev-bus-pm) {
   callback = dev-bus-pm-runtime_resume;
   if(!strcmp(dev_name(dev),usbhs_omap))
pr_err(dev-bus-pm-runtime_resume);
   }   
   else
   callback = NULL;
 }


 I am seeing that below if statement was hitting true:

   if (dev-pwr_domain) {
   callback = dev-pwr_domain-ops.runtime_resume;
   if(!strcmp(dev_name(dev),usbhs_omap))
pr_err(dev-pwr_domain-ops.runtime_resume);


 due to this; the driver-runtime_resume was not getting called.

 Any idea on why I am seeing only the dev-pwr_domain is set not
 dev-bus  dev-bus-pm is hitting here?

Because that's how it was designed. :)

On OMAP, for on-chip devices (omap_devices) we use PM domains
(pwr_domain) and not the subsystem (bus) to implment runtime PM, and as
Alan pointed out, PM domains have precedence over subsystem callbacks.

I'm curious why you determined the driver's runtime resume was not
getting called?

The PM domain callback will call your driver's runtime_resume (assuming
it exists.)

rpm_resume()
   dev-pwr_domain-ops.runtime_resume()
   omap_device_enable()
   pm_generic_runtime_resume()

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

cc'ing lakml

Hi Venkat, Balaji,

On Wed, 29 Jun 2011, S, Venkatraman wrote:

 On Wed, Jun 29, 2011 at 9:08 PM, Paul Walmsley p...@pwsan.com wrote:
  On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:
 
  There have been some experiments on our customer programs to reduce this
  value to a few ms and infrequent crashes were observed (stress testing
  for several hours) while trying to access the controller registers.
 
  By the way, could you send along a copy of the stress test script?
 
 
 Paul, these scenarios are not scripted but end user tests with
 additional devices
 (WLAN, which is connected on the same controller) and executed 'on field' .

OK, thanks Venkat.  Do you still have one of these devices so the test can 
be repeated?

 One such log is here .. http://pastebin.com/nq3cfZnT

Looks like this is an Android 2.6.35.7-derived kernel on a 4430 ES2.2 EMU.  
Power management is enabled but MPU, L3INIT, and PER aren't entering any 
deeper power states than retention idle, so no context save/restore or 
off-mode worries here.

The system looks like it's entered suspend at least once and resumed, 
before the oops.  Also the second CPU is starting up and shutting down 
dynamically.  Backtrace is copied below for the archives.

Does the above summary match your understanding?

...

Reviewing this backtrace and the one that Balaji sent, it looks to 
me like this write in omap_hsmmc_prepare_data() is the proximate 
cause of the abort:

OMAP_HSMMC_WRITE(host-base, BLK, (req-data-blksz)
| (req-data-blocks  16));

I'll bet this was first access to the MMC IP block after the MMC layer 
re-enabled it.  The abort is imprecise because the Linux OMAP4 kernel 
marks MMIO registers as bufferable, so the ARM can continue executing 
while a register write is making its way across the OMAP interconnect(s).  
This guess also assumes that the ARM is executing instructions out of 
order, which is a reasonable assumption on a Cortex-A9.  This could be 
confirmed by reading some HSMMC register right before the 
OMAP_HSMMC_WRITE(); then the abort would turn precise and occur on the 
read.

Anyway, it looks like the HSMMC IP block wasn't yet ready to be accessed.  
Probably, this is because either the HSMMC IP block hasn't yet left the 
Idle or SleepTrans states, and the OMAP4 clock framework doesn't wait for 
that; or the PRCM is getting confused because the correct clockdomain 
enable sequence isn't being followed -- see for example the Fix 
module-mode enable sequence on OMAP4 patch series that have been posted 
to the linux-omap mailing list.  Probably one of those two issues is the 
root cause.

If you have a testing setup where you can reproduce this problem, I'd 
suggest adding the read as described above.  Otherwise, I don't think this 
will be an issue for the runtime PM conversion: first, because the hwmod 
code will wait for the HSMMC block to indicate that it has left idle 
before continuing; and second, because we'll hopefully have a patch series 
going in at the same time to make sure the clockdomain enable sequence is 
correct.


- Paul


0 Process mmcqd (pid: 851, stack limit = 0xef9682f8)
0 Stack: (0xef969db8 to 0xef96a000)
0 9da0:   ef969ee4 
efa30640
0 9dc0: ef969e78  0001 efa30400 ef969e2c ef969de0 c06ae2b8 
c06ace10
0 9de0:  efa305d8 ef969e04 efa30400  efa30578 ef969e44 
ef969e08
0 9e00: c054ea5c ef969e78 efa30400 ef969e34 0001 ef837e4c  
ef969ee4
0 9e20: ef969e64 ef969e30 c06a54d8 c06adff4    

0 9e40: ef969e40 ef969e40 ed3d4680 ed3d4680 efa30c00 ef837e40 ef969f94 
ef969e68
0 9e60: c06abe80 c06a53cc  efa31458 ef0cfdb4 ef0cfdb4 ef969e8c 
ef969ee4
0 9e80: ef969eb8 ef969e34 c06a55d0 0019 00fd50a2   

0 9ea0:  00b5   ef969ee4 ef969e78 000c 

0 9ec0:     049d   

0 9ee0: ef969e78 23c34600 0fa0 0200 0400  0100 

0 9f00: ef969eb8 ef969e78 003f ef238000 ef969f54 ef969f20 c0556c00 
c0555fac
0 9f20: ef969f3c 0001 c0425fa0 ef837e4c ef23 ef837e54 ef837e4c 
ef23
0 9f40: ef837e54 ef23 ef969f7c ef969f58  ed3d4680 ef969f7c 
ef969f68
0 9f60: c054911c c054ee7c 01082e21 ef837e4c ef968000 ef837e54 ef23 
ef2301d8
0 9f80:  ed3d4680 ef969fbc ef969f98 c06acab8 c06abccc ef985d68 
ef969fc4
0 9fa0: c06ac9c4 ef837e4c   ef969ff4 ef969fc0 c041fd20 
c06ac9d0
0 9fc0:     ef969fd0 ef969fd0 ef985d68 
c041fc9c
0 9fe0: c040d67c 0013  ef969ff8 c040d67c c041fca8  

4 Backtrace:
4 [c06ace04] (set_data_timeout+0x0/0xcc) from [c06ae2b8] 
(omap_hsmmc_request+0x2d0/0x5c8)
4  r8:efa30400 r7:0001 r6: r5:ef969e78 r4:efa30640
4 r3:ef969ee4
4 [c06adfe8] (omap_hsmmc_request+0x0/0x5c8)

Re: [PATCH 0/2] RETU meets Sparse IRQ

2011-06-29 Thread Leigh Brown


On Wed, 29 Jun 2011 14:46:49 +0300, Felipe Balbi wrote:

now with Sparse IRQ numbering, we don't need
to add a bunch of defines in plat/irqs.h

Compile tested with omap2plus_defconfig (+cbus)
and omap1_defconfig (+cbus).

Felipe Balbi (2):
  cbus: retu: use sparse IRQ numbering
  cbus: retu: stop polluting plat/irqs.h

 arch/arm/mach-omap1/board-nokia770.c   |2 --
 arch/arm/mach-omap2/board-n8x0.c   |2 --
 arch/arm/plat-omap/include/plat/irqs.h |   10 +-
 drivers/cbus/retu.c|   25 
-

 include/linux/platform_data/cbus.h |2 --
 5 files changed, 17 insertions(+), 24 deletions(-)


Tested-by: Leigh Brown le...@solinno.co.uk

Booted fine on my N810.

Regards,

Leigh.

--
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] OMAP3: run the ASM sleep code from DDR

On Wed, Jun 29, 2011 at 06:40:23PM +0200, jean.pi...@newoldbits.com wrote:
 @@ -309,7 +308,7 @@ static irqreturn_t prcm_interrupt_handler (int irq, void 
 *dev_id)
  
  static void omap34xx_do_sram_idle(unsigned long save_state)
  {
 - _omap_sram_idle(omap3_arm_context, save_state);
 + omap34xx_cpu_suspend(omap3_arm_context, save_state);

Actually, this should be called omap34xx_soc_suspend() or
omap34xx_finish_suspend() - finish_suspend() reflects the naming
of other such functions elsewhere.
--
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] OMAP3: run the ASM sleep code from DDR

On Wed, Jun 29, 2011 at 12:06:07PM -0700, Kevin Hilman wrote:
 Russell King - ARM Linux li...@arm.linux.org.uk writes:
 
  On Wed, Jun 29, 2011 at 10:29:49AM -0700, Kevin Hilman wrote:
  Russell, if you're OK with it, can you add it to your suspend branch for
  the upcoming merge window?
 
  Yes - though I think we can go a little bit further - this patch is on
  top of my code so far, and is untested.  There isn't a need for the
  saving of these registers to be in assembly because we can read them
  just as easily from C code.
 
 Indeed
 
  Comments?
 
 Looks good to me (although untested) care to respin on top of $SUBJECT
 patch?  
 
 Minor comments below...

Done.

 arch/arm/mach-omap2/pm.h|2 +-
 arch/arm/mach-omap2/pm34xx.c|   19 ++-
 arch/arm/mach-omap2/sleep34xx.S |   12 ++--
 3 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index a4ec213..04ee566 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -97,7 +97,7 @@ extern void omap24xx_cpu_suspend(u32 dll_ctrl, void __iomem 
*sdrc_dlla_ctrl,
 extern unsigned int omap24xx_cpu_suspend_sz;
 
 /* 3xxx */
-extern void omap34xx_cpu_suspend(u32 *addr, int save_state);
+extern void omap34xx_cpu_suspend(int save_state);
 
 /* omap3_do_wfi function pointer and size, for copy to SRAM */
 extern void omap3_do_wfi(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e1c79ba..7238a63 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -306,9 +306,24 @@ static irqreturn_t prcm_interrupt_handler (int irq, void 
*dev_id)
return IRQ_HANDLED;
 }
 
+static void omap34xx_save_context(u32 *save)
+{
+   u32 val;
+
+   /* Read Auxiliary Control Register */
+   asm(mrc p15, 0, %0, c1, c0, 1 : =r (val));
+   *save++ = 1;
+   *save++ = val;
+
+   /* Read L2 AUX ctrl register */
+   asm(mrc p15, 1, %0, c9, c0, 2 : =r (val));
+   *save++ = 1;
+   *save++ = val;
+}
+
 static void omap34xx_do_sram_idle(unsigned long save_state)
 {
-   omap34xx_cpu_suspend(omap3_arm_context, save_state);
+   omap34xx_cpu_suspend(save_state);
 }
 
 void omap_sram_idle(void)
@@ -408,6 +423,8 @@ void omap_sram_idle(void)
 * get saved. The rest is placed on the stack, and restored
 * from there before resuming.
 */
+   if (save_state)
+   omap34xx_save_context(omap3_arm_context);
if (save_state == 1 || save_state == 3)
cpu_suspend(save_state, omap34xx_do_sram_idle);
else
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 17dbc5a..f2ea1bd 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -152,8 +152,7 @@ ENTRY(omap34xx_cpu_suspend)
stmfd   sp!, {r4 - r11, lr} @ save registers on stack
 
/*
-* r0 contains CPU context save/restore pointer in sdram
-* r1 contains information about saving context:
+* r0 contains information about saving context:
 *   0 - No context lost
 *   1 - Only L1 and logic lost
 *   2 - Only L2 lost (Even L1 is retained we clean it along with L2)
@@ -166,19 +165,12 @@ ENTRY(omap34xx_cpu_suspend)
 */
ldr r4, omap3_do_wfi_sram_addr
ldr r5, [r4]
-   cmp r1, #0x0@ If no context save required,
+   cmp r0, #0x0@ If no context save required,
bxeqr5  @  jump to the WFI code in SRAM
 
 
/* Otherwise fall through to the save context code */
 save_context_wfi:
-   mov r8, r0  @ Store SDRAM address in r8
-   mrc p15, 0, r5, c1, c0, 1   @ Read Auxiliary Control Register
-   mov r4, #0x1@ Number of parameters for restore call
-   stmia   r8!, {r4-r5}@ Push parameters for restore call
-   mrc p15, 1, r5, c9, c0, 2   @ Read L2 AUX ctrl register
-   stmia   r8!, {r4-r5}@ Push parameters for restore call
-
/*
 * jump out to kernel flush routine
 *  - reuse that code is better
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP4: I2C: Enable FIFO usage for OMAP4

Shubhrajyoti D shubhrajy...@ti.com writes:

 Currently the fifo depth is set to zero for OMAP4 which disables
 the FIFO usage. This patch enables the FIFO usage for I2C transactions
 on OMAP4 also.

Do you know the history of why the FIFO depth was set to zero?  A
summary of that history would greatly help reviewers.

 Reported-By:Nishanth Menon n...@ti.com

minor: missing space after ':'

 Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com

Tested on what platforms?   OMAP3 also?

Could you please rebase this onto my for_3.1/i2c-andy branch[1] where we
have a large series of I2C patches queued up for the v3.1 merge window
already? 

Thanks,

Kevin

[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git

--
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] OMAP3: run the ASM sleep code from DDR

Russell King - ARM Linux li...@arm.linux.org.uk writes:

 On Wed, Jun 29, 2011 at 12:06:07PM -0700, Kevin Hilman wrote:
 Russell King - ARM Linux li...@arm.linux.org.uk writes:
 
  On Wed, Jun 29, 2011 at 10:29:49AM -0700, Kevin Hilman wrote:
  Russell, if you're OK with it, can you add it to your suspend branch for
  the upcoming merge window?
 
  Yes - though I think we can go a little bit further - this patch is on
  top of my code so far, and is untested.  There isn't a need for the
  saving of these registers to be in assembly because we can read them
  just as easily from C code.
 
 Indeed
 
  Comments?
 
 Looks good to me (although untested) care to respin on top of $SUBJECT
 patch?  
 
 Minor comments below...

 Done.

Tested-by: Kevin Hilman khil...@ti.com

Tested full-chip retention and off on 3430/n900, 3530/Overo and
3630/Zoom3.

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

[PATCH 1/8] OMAP3630: PRM: add ABB PRM register definitions

OMAP3630 supports an Adaptive Body-Bias ldo as well as some MPU interrupts
related to voltage control that are not present on OMAP34XX.  This patch
adds the offsets, register addresses, bitfield shifts and masks to support
this feature.

Signed-off-by: Mike Turquette mturque...@ti.com
---
 arch/arm/mach-omap2/prm-regbits-34xx.h |   34 
 arch/arm/mach-omap2/prm2xxx_3xxx.h |4 +++
 2 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h 
b/arch/arm/mach-omap2/prm-regbits-34xx.h
index 64c087a..0309ff6 100644
--- a/arch/arm/mach-omap2/prm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-34xx.h
@@ -216,6 +216,12 @@
 /* PRM_SYSCONFIG specific bits */
 
 /* PRM_IRQSTATUS_MPU specific bits */
+#define OMAP3630_VC_BYPASS_ACK_ST_SHIFT28
+#define OMAP3630_VC_BYPASS_ACK_ST_MASK (1  28)
+#define OMAP3630_VC_VP1_ACK_ST_SHIFT   27
+#define OMAP3630_VC_VP1_ACK_ST_MASK(1  27)
+#define OMAP3630_ABB_LDO_TRANXDONE_ST_SHIFT26
+#define OMAP3630_ABB_LDO_TRANXDONE_ST_MASK (1  26)
 #define OMAP3430ES2_SND_PERIPH_DPLL_ST_SHIFT   25
 #define OMAP3430ES2_SND_PERIPH_DPLL_ST_MASK(1  25)
 #define OMAP3430_VC_TIMEOUTERR_ST_MASK (1  24)
@@ -248,6 +254,12 @@
 #define OMAP3430_FS_USB_WKUP_ST_MASK   (1  1)
 
 /* PRM_IRQENABLE_MPU specific bits */
+#define OMAP3630_VC_BYPASS_ACK_EN_SHIFT28
+#define OMAP3630_VC_BYPASS_ACK_EN_MASK (1  28)
+#define OMAP3630_VC_VP1_ACK_EN_SHIFT   27
+#define OMAP3630_VC_VP1_ACK_EN_MASK(1  27)
+#define OMAP3630_ABB_LDO_TRANXDONE_EN_SHIFT26
+#define OMAP3630_ABB_LDO_TRANXDONE_EN_MASK (1  26)
 #define OMAP3430ES2_SND_PERIPH_DPLL_RECAL_EN_SHIFT 25
 #define OMAP3430ES2_SND_PERIPH_DPLL_RECAL_EN_MASK  (1  25)
 #define OMAP3430_VC_TIMEOUTERR_EN_MASK (1  24)
@@ -587,6 +599,28 @@
 
 /* PRM_VP2_STATUS specific bits */
 
+/* PRM_LDO_ABB_SETUP specific bits */
+#define OMAP3630_SR2_IN_TRANSITION_SHIFT   6
+#define OMAP3630_SR2_IN_TRANSITION_MASK(1  6)
+#define OMAP3630_SR2_STATUS_SHIFT  3
+#define OMAP3630_SR2_STATUS_MASK   (3  3)
+#define OMAP3630_OPP_CHANGE_SHIFT  2
+#define OMAP3630_OPP_CHANGE_MASK   (1  2)
+#define OMAP3630_OPP_SEL_SHIFT 0
+#define OMAP3630_OPP_SEL_MASK  (3  0)
+
+/* PRM_LDO_ABB_CTRL specific bits */
+#define OMAP3630_SR2_WTCNT_VALUE_SHIFT 8
+#define OMAP3630_SR2_WTCNT_VALUE_MASK  (0xff  8)
+#define OMAP3630_SLEEP_RBB_SEL_SHIFT   3
+#define OMAP3630_SLEEP_RBB_SEL_MASK(1  3)
+#define OMAP3630_ACTIVE_FBB_SEL_SHIFT  2
+#define OMAP3630_ACTIVE_FBB_SEL_MASK   (1  2)
+#define OMAP3630_ACTIVE_RBB_SEL_SHIFT  1
+#define OMAP3630_ACTIVE_RBB_SEL_MASK   (1  1)
+#define OMAP3630_SR2EN_SHIFT   0
+#define OMAP3630_SR2EN_MASK(1  0)
+
 /* RM_RSTST_NEON specific bits */
 
 /* PM_WKDEP_NEON specific bits */
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h 
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index cef533d..408d1c7 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -167,6 +167,10 @@
 #define OMAP3430_PRM_VP2_VOLTAGE   OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, 
0x00e0)
 #define OMAP3_PRM_VP2_STATUS_OFFSET0x00e4
 #define OMAP3430_PRM_VP2_STATUS
OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, 0x00e4)
+#define OMAP3_PRM_LDO_ABB_SETUP_OFFSET 0x00f0
+#define OMAP3630_PRM_LDO_ABB_SETUP OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, 
0x00f0)
+#define OMAP3_PRM_LDO_ABB_CTRL_OFFSET  0x00f4
+#define OMAP3630_PRM_LDO_ABB_CTRL  OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, 
0x00f4)
 
 #define OMAP3_PRM_CLKSEL_OFFSET0x0040
 #define OMAP3430_PRM_CLKSELOMAP34XX_PRM_REGADDR(OMAP3430_CCR_MOD, 
0x0040)
-- 
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

[PATCH 3/8] OMAP3+: PRM: add tranxdone IRQ handlers for ABB

From: Nishanth Menon n...@ti.com

OMAP3 and more recent platforms support a PRM interrupt to the MPU for
Adapative Body-Bias ldo transitions.

Add helpers to the OMAP3  OMAP4 PRM code to check the status of the
interrupt and also to clear it.  These will be called from the ABB code
as part of the greater voltage scaling sequence.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Mike Turquette mturque...@ti.com
---
 arch/arm/mach-omap2/prm2xxx_3xxx.c |   35 ++-
 arch/arm/mach-omap2/prm2xxx_3xxx.h |3 ++
 arch/arm/mach-omap2/prm44xx.c  |   40 +--
 arch/arm/mach-omap2/prm44xx.h  |3 ++
 4 files changed, 68 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c 
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 8a20242..49e9719 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -163,18 +163,23 @@ int omap2_prm_deassert_hardreset(s16 prm_mod, u8 
rst_shift, u8 st_shift)
 
 /*
  * struct omap3_prm_irq - OMAP3 PRM IRQ register access description.
- * @tranxdone_status: VP_TRANXDONE_ST bitmask in PRM_IRQSTATUS_MPU reg
+ * @vp_tranxdone_status: VP_TRANXDONE_ST bitmask in PRM_IRQSTATUS_MPU reg
+ * @abb_tranxdone_status: ABB_TRANXDONE_ST bitmask in PRM_IRQSTATUS_MPU reg
+ *   (ONLY for OMAP3630)
  */
 struct omap3_prm_irq {
-   u32 tranxdone_status;
+   u32 vp_tranxdone_status;
+   u32 abb_tranxdone_status;
 };
 
 static struct omap3_prm_irq omap3_prm_irqs[] = {
[OMAP3_PRM_IRQ_VDD_MPU_ID] = {
-   .tranxdone_status = OMAP3430_VP1_TRANXDONE_ST_MASK,
+   .vp_tranxdone_status = OMAP3430_VP1_TRANXDONE_ST_MASK,
+   .abb_tranxdone_status = OMAP3630_ABB_LDO_TRANXDONE_ST_MASK,
},
[OMAP3_PRM_IRQ_VDD_CORE_ID] = {
-   .tranxdone_status = OMAP3430_VP2_TRANXDONE_ST_MASK,
+   .vp_tranxdone_status = OMAP3430_VP2_TRANXDONE_ST_MASK,
+   /* no abb for core */
},
 };
 
@@ -187,14 +192,32 @@ u32 omap3_prm_vp_check_txdone(u8 irq_id)
 
irqstatus = omap2_prm_read_mod_reg(OCP_MOD,
   OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
-   return irqstatus  irq-tranxdone_status;
+   return irqstatus  irq-vp_tranxdone_status;
 }
 
 void omap3_prm_vp_clear_txdone(u8 irq_id)
 {
struct omap3_prm_irq *irq = omap3_prm_irqs[irq_id];
 
-   omap2_prm_write_mod_reg(irq-tranxdone_status,
+   omap2_prm_write_mod_reg(irq-vp_tranxdone_status,
+   OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
+}
+
+u32 omap36xx_prm_abb_check_txdone(u8 irq_id)
+{
+   struct omap3_prm_irq *irq = omap3_prm_irqs[irq_id];
+   u32 irqstatus;
+
+   irqstatus = omap2_prm_read_mod_reg(OCP_MOD,
+  OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
+   return irqstatus  irq-abb_tranxdone_status;
+}
+
+void omap36xx_prm_abb_clear_txdone(u8 irq_id)
+{
+   struct omap3_prm_irq *irq = omap3_prm_irqs[irq_id];
+
+   omap2_prm_write_mod_reg(irq-abb_tranxdone_status,
OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
 }
 
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h 
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index d90b23f..08d5f1e 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -313,6 +313,9 @@ extern int omap2_prm_deassert_hardreset(s16 prm_mod, u8 
rst_shift, u8 st_shift);
 u32 omap3_prm_vp_check_txdone(u8 irq_id);
 void omap3_prm_vp_clear_txdone(u8 irq_id);
 
+/* OMAP36xx-specific ABB functions */
+u32 omap36xx_prm_abb_check_txdone(u8 irq_id);
+void omap36xx_prm_abb_clear_txdone(u8 irq_id);
 
 /*
  * OMAP3 access functions for voltage controller (VC) and
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 9d0b641..a062b63 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -202,25 +202,30 @@ void omap4_prm_global_warm_sw_reset(void)
 /*
  * struct omap4_prm_irq - OMAP4 VP register access description.
  * @irqstatus_mpu: offset to IRQSTATUS_MPU register for VP
- * @tranxdone_status: VP_TRANXDONE_ST bitmask in PRM_IRQSTATUS_MPU reg
+ * @vp_tranxdone_status: VP_TRANXDONE_ST bitmask in PRM_IRQSTATUS_MPU reg
+ * @abb_tranxdone_status: ABB_TRANXDONE_ST bitmask in PRM_IRQSTATUS_MPU reg
  */
 struct omap4_prm_irq {
u32 irqstatus_mpu;
-   u32 tranxdone_status;
+   u32 vp_tranxdone_status;
+   u32 abb_tranxdone_status;
 };
 
 static struct omap4_prm_irq omap4_prm_irqs[] = {
[OMAP4_PRM_IRQ_VDD_MPU_ID] = {
.irqstatus_mpu = OMAP4_PRM_IRQSTATUS_MPU_2_OFFSET,
-   .tranxdone_status = OMAP4430_VP_MPU_TRANXDONE_ST_MASK,
+   .vp_tranxdone_status = OMAP4430_VP_MPU_TRANXDONE_ST_MASK,
+   .abb_tranxdone_status = OMAP4430_ABB_MPU_DONE_ST_MASK
},
[OMAP4_PRM_IRQ_VDD_IVA_ID] = {

[PATCH 4/8] OMAP3+: ABB: Adaptive Body-Bias structures data

Due to voltage domain trimming and silicon characterstics some silicon
may experience instability when operating at a high voltage.  To
compensate for this an Adaptive Body-Bias ldo exists.  First featured in
OMAP3630, the purpose of this ldo is to provide a voltage boost to PMOS
backgates when a voltage domain is operating at a high OPP.  In this
mode the ldo is said to be in Forward Body-Bias.  At OPPs within a
nominal voltage range the ABB ldo is bypassed.

This patch introduces the data structures needed to represent the ABB
ldo's in the voltage layer, and populates the appropriate data for 3630
and OMAP4.  Not all voltage domains have an ABB ldo, and OMAP34xx does
not have it at all; in such cases the voltage data will be marked with
OMAP_ABB_NO_LDO.

Signed-off-by: Mike Turquette mturque...@ti.com
---
 arch/arm/mach-omap2/Makefile   |5 +-
 arch/arm/mach-omap2/abb.h  |   85 
 arch/arm/mach-omap2/abb36xx_data.c |   38 
 arch/arm/mach-omap2/abb44xx_data.c |   44 ++
 4 files changed, 170 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-omap2/abb.h
 create mode 100644 arch/arm/mach-omap2/abb36xx_data.c
 create mode 100644 arch/arm/mach-omap2/abb44xx_data.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 2cbef35..7dbb4d5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -79,14 +79,15 @@ endif
 # PRCM
 obj-$(CONFIG_ARCH_OMAP2)   += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o
 obj-$(CONFIG_ARCH_OMAP3)   += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o \
-  vc3xxx_data.o vp3xxx_data.o
+  vc3xxx_data.o vp3xxx_data.o \
+  abb36xx_data.o
 # XXX The presence of cm2xxx_3xxx.o on the line below is temporary and
 # will be removed once the OMAP4 part of the codebase is converted to
 # use OMAP4-specific PRCM functions.
 obj-$(CONFIG_ARCH_OMAP4)   += prcm.o cm2xxx_3xxx.o cminst44xx.o \
   cm44xx.o prcm_mpu44xx.o \
   prminst44xx.o vc44xx_data.o \
-  vp44xx_data.o
+  vp44xx_data.o abb44xx_data.o
 
 # OMAP voltage domains
 ifeq ($(CONFIG_PM),y)
diff --git a/arch/arm/mach-omap2/abb.h b/arch/arm/mach-omap2/abb.h
new file mode 100644
index 000..74f2044
--- /dev/null
+++ b/arch/arm/mach-omap2/abb.h
@@ -0,0 +1,85 @@
+/*
+ * OMAP Adaptive Body-Bias structure and macro definitions
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Mike Turquette mturque...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_ABB_H
+#define __ARCH_ARM_MACH_OMAP2_ABB_H
+
+#include linux/kernel.h
+
+#include voltage.h
+
+/* NOMINAL_OPP bypasses the ABB ldo, FAST_OPP sets it to Forward Body-Bias */
+#define OMAP_ABB_NOMINAL_OPP   0
+#define OMAP_ABB_FAST_OPP  1
+#define OMAP_ABB_NO_LDO~0
+
+/* Time for the ABB ldo to settle after transition (in micro-seconds) */
+#define ABB_TRANXDONE_TIMEOUT  50
+
+/*
+ * struct omap_abb_ops - per-OMAP operations needed for ABB transition
+ *
+ * @check_tranxdone: return status of ldo transition from PRM_IRQSTATUS
+ * @clear_tranxdone: clear ABB transition status bit from PRM_IRQSTATUS
+ */
+struct omap_abb_ops {
+   u32 (*check_tranxdone)(u8 irq_id);
+   void (*clear_tranxdone)(u8 irq_id);
+};
+
+/*
+ * struct omap_abb_common - ABB data common to an OMAP family
+ *
+ * @opp_sel_mask: CTRL reg uses this to program next state of ldo
+ * @opp_change_mask: CTRL reg uses this to initiate ldo state change
+ * @sr2_wtcnt_value_mask: SETUP reg uses this to program ldo settling time
+ * @sr2en_mask: SETUP reg uses this to enable/disable ldo
+ * @active_fbb_sel_mask: SETUP reg uses this to enable/disable FBB operation
+ * @settling_time: number of micro-seconds it takes for ldo to transition
+ * @clock_cycles: settling_time is counted in multiples of clock cycles
+ * @ops: pointer to common ops for manipulating PRM_IRQSTATUS bits
+ */
+struct omap_abb_common {
+   u32 opp_sel_mask;
+   u32 opp_change_mask;
+   u32 sr2_wtcnt_value_mask;
+   u32 sr2en_mask;
+   u32 active_fbb_sel_mask;
+   unsigned long settling_time;
+   unsigned long clock_cycles;
+   const struct omap_abb_ops *ops;
+};
+
+/*
+ * struct omap_abb_instance - data for each instance of ABB ldo
+ *
+ * @setup_offs: PRM register offset for initial configuration of ABB ldo
+ * @ctrl_offs: PRM register offset for active programming of ABB ldo
+ * @prm_irq_id: IRQ handle used to resolve IRQSTATUS offset  masks
+ * @enabled: track whether ABB ldo is enabled or

[PATCH 5/8] OMAP3+: OPP: add ABB data to voltage tables

The operating mode of the Adaptive Body-Bias ldo maps directly to the
voltage of its voltage domain.  The two modes supported are bypass and
Forward Body-Bias (FBB).

This patch models this relationship by adding an opp_sel paramter to
struct omap_volt_data and populates this type in the 3630 and 4430
voltage tables.

NOMINAL_OPP causes the ABB ldo to be in bypass at that specific voltage.
FAST_OPP causes the ldo to operate in Forward Body-Bias mode.

Not all voltage domains have an ABB ldo and 3430 doesn't have one at
all.  In such cases voltages are marked with OMAP_ABB_NO_LDO.

Signed-off-by: Mike Turquette mturque...@ti.com
---
 arch/arm/mach-omap2/omap_opp_data.h |5 ++-
 arch/arm/mach-omap2/opp3xxx_data.c  |   37 ++-
 arch/arm/mach-omap2/opp4xxx_data.c  |   25 ---
 arch/arm/mach-omap2/voltage.h   |1 +
 4 files changed, 36 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_opp_data.h 
b/arch/arm/mach-omap2/omap_opp_data.h
index c784c12..5dd4dea 100644
--- a/arch/arm/mach-omap2/omap_opp_data.h
+++ b/arch/arm/mach-omap2/omap_opp_data.h
@@ -71,12 +71,13 @@ struct omap_opp_def {
  * Initialization wrapper used to define SmartReflex process data
  * XXX Is this needed?  Just use C99 initializers in data files?
  */
-#define VOLT_DATA_DEFINE(_v_nom, _efuse_offs, _errminlimit, _errgain)  \
+#define VOLT_DATA_DEFINE(_v_nom, _efuse_offs, _errminlimit, _errgain, 
_opp_sel) \
 { \
.volt_nominal   = _v_nom,  \
.sr_efuse_offs  = _efuse_offs, \
.sr_errminlimit = _errminlimit,\
-   .vp_errgain = _errgain \
+   .vp_errgain = _errgain,\
+   .opp_sel= _opp_sel \
 }
 
 /* Use this to initialize the default table */
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c 
b/arch/arm/mach-omap2/opp3xxx_data.c
index d95f3f9..12fc2da 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -24,6 +24,7 @@
 #include control.h
 #include omap_opp_data.h
 #include pm.h
+#include abb.h
 
 /* 34xx */
 
@@ -36,12 +37,12 @@
 #define OMAP3430_VDD_MPU_OPP5_UV   135
 
 struct omap_volt_data omap34xx_vddmpu_volt_data[] = {
-   VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP1_UV, 
OMAP343X_CONTROL_FUSE_OPP1_VDD1, 0xf4, 0x0c),
-   VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP2_UV, 
OMAP343X_CONTROL_FUSE_OPP2_VDD1, 0xf4, 0x0c),
-   VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP3_UV, 
OMAP343X_CONTROL_FUSE_OPP3_VDD1, 0xf9, 0x18),
-   VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP4_UV, 
OMAP343X_CONTROL_FUSE_OPP4_VDD1, 0xf9, 0x18),
-   VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP5_UV, 
OMAP343X_CONTROL_FUSE_OPP5_VDD1, 0xf9, 0x18),
-   VOLT_DATA_DEFINE(0, 0, 0, 0),
+   VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP1_UV, 
OMAP343X_CONTROL_FUSE_OPP1_VDD1, 0xf4, 0x0c, OMAP_ABB_NO_LDO),
+   VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP2_UV, 
OMAP343X_CONTROL_FUSE_OPP2_VDD1, 0xf4, 0x0c, OMAP_ABB_NO_LDO),
+   VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP3_UV, 
OMAP343X_CONTROL_FUSE_OPP3_VDD1, 0xf9, 0x18, OMAP_ABB_NO_LDO),
+   VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP4_UV, 
OMAP343X_CONTROL_FUSE_OPP4_VDD1, 0xf9, 0x18, OMAP_ABB_NO_LDO),
+   VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP5_UV, 
OMAP343X_CONTROL_FUSE_OPP5_VDD1, 0xf9, 0x18, OMAP_ABB_NO_LDO),
+   VOLT_DATA_DEFINE(0, 0, 0, 0, 0),
 };
 
 /* VDD2 */
@@ -51,10 +52,10 @@ struct omap_volt_data omap34xx_vddmpu_volt_data[] = {
 #define OMAP3430_VDD_CORE_OPP3_UV  115
 
 struct omap_volt_data omap34xx_vddcore_volt_data[] = {
-   VOLT_DATA_DEFINE(OMAP3430_VDD_CORE_OPP1_UV, 
OMAP343X_CONTROL_FUSE_OPP1_VDD2, 0xf4, 0x0c),
-   VOLT_DATA_DEFINE(OMAP3430_VDD_CORE_OPP2_UV, 
OMAP343X_CONTROL_FUSE_OPP2_VDD2, 0xf4, 0x0c),
-   VOLT_DATA_DEFINE(OMAP3430_VDD_CORE_OPP3_UV, 
OMAP343X_CONTROL_FUSE_OPP3_VDD2, 0xf9, 0x18),
-   VOLT_DATA_DEFINE(0, 0, 0, 0),
+   VOLT_DATA_DEFINE(OMAP3430_VDD_CORE_OPP1_UV, 
OMAP343X_CONTROL_FUSE_OPP1_VDD2, 0xf4, 0x0c, OMAP_ABB_NO_LDO),
+   VOLT_DATA_DEFINE(OMAP3430_VDD_CORE_OPP2_UV, 
OMAP343X_CONTROL_FUSE_OPP2_VDD2, 0xf4, 0x0c, OMAP_ABB_NO_LDO),
+   VOLT_DATA_DEFINE(OMAP3430_VDD_CORE_OPP3_UV, 
OMAP343X_CONTROL_FUSE_OPP3_VDD2, 0xf9, 0x18, OMAP_ABB_NO_LDO),
+   VOLT_DATA_DEFINE(0, 0, 0, 0, 0),
 };
 
 /* 36xx */
@@ -67,11 +68,11 @@ struct omap_volt_data omap34xx_vddcore_volt_data[] = {
 #define OMAP3630_VDD_MPU_OPP1G_UV  1375000
 
 struct omap_volt_data omap36xx_vddmpu_volt_data[] = {
-   VOLT_DATA_DEFINE(OMAP3630_VDD_MPU_OPP50_UV, 
OMAP3630_CONTROL_FUSE_OPP50_VDD1, 0xf4, 0x0c),
-   VOLT_DATA_DEFINE(OMAP3630_VDD_MPU_OPP100_UV, 
OMAP3630_CONTROL_FUSE_OPP100_VDD1, 0xf9, 0x16),
-

[PATCH 7/8] OMAP3+: ABB: initialization transition functions

The Adaptive Body-Bias ldo can be set to bypass or Forward Body-Bias
after voltage scaling is performed.

This patch implements the Adaptive Body-Bias ldo initialization routine
and the transition sequence which is needed after a vc_bypass or
vp_forceupdate sequence completes.

Signed-off-by: Mike Turquette mturque...@ti.com
---
 arch/arm/mach-omap2/Makefile |2 +-
 arch/arm/mach-omap2/abb.c|  218 ++
 arch/arm/mach-omap2/abb.h|5 +
 3 files changed, 224 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-omap2/abb.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 7dbb4d5..f87e1b2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -91,7 +91,7 @@ obj-$(CONFIG_ARCH_OMAP4)  += prcm.o cm2xxx_3xxx.o 
cminst44xx.o \
 
 # OMAP voltage domains
 ifeq ($(CONFIG_PM),y)
-voltagedomain-common   := voltage.o vc.o vp.o
+voltagedomain-common   := voltage.o vc.o vp.o abb.o
 obj-$(CONFIG_ARCH_OMAP2)   += $(voltagedomain-common) \
   voltagedomains2xxx_data.o
 obj-$(CONFIG_ARCH_OMAP3)   += $(voltagedomain-common) \
diff --git a/arch/arm/mach-omap2/abb.c b/arch/arm/mach-omap2/abb.c
new file mode 100644
index 000..b8b6b4b
--- /dev/null
+++ b/arch/arm/mach-omap2/abb.c
@@ -0,0 +1,218 @@
+/*
+ * OMAP Adaptive Body-Bias core
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Mike Turquette mturque...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/init.h
+#include linux/delay.h
+
+#include abb.h
+#include voltage.h
+
+/*
+ * omap_abb_set_opp - program ABB ldo based on new voltage
+ *
+ * @voltdm - pointer to voltage domain that just finished scaling voltage
+ *
+ * Look up the ABB ldo state for the new voltage that voltdm just finished
+ * transitioning to and compare it to current ldo state.  If a change is needed
+ * then clear appropriate PRM_IRQSTATUS bit, transition ldo and then clear
+ * PRM_IRQSTATUS bit again.  Returns 0 on success, -EERROR otherwise.
+ */
+int omap_abb_set_opp(struct voltagedomain *voltdm)
+{
+   struct omap_abb_instance *abb = voltdm-abb;
+   struct omap_volt_data *volt_data;
+   int ret, timeout;
+   u8 opp_sel;
+
+   /* fetch the ABB ldo OPP_SEL value for the new voltage */
+   volt_data = omap_voltage_get_voltdata(voltdm, voltdm-curr_volt);
+
+   if (IS_ERR_OR_NULL(volt_data))
+   return -EINVAL;
+
+   opp_sel = volt_data-opp_sel;
+
+   /* bail early if no transition is necessary */
+   if (opp_sel == abb-_opp_sel)
+   return 0;
+
+   /* clear interrupt status */
+   timeout = 0;
+   while (timeout++  ABB_TRANXDONE_TIMEOUT) {
+   abb-common-ops-clear_tranxdone(abb-prm_irq_id);
+
+   ret = abb-common-ops-check_tranxdone(abb-prm_irq_id);
+   if (!ret)
+   break;
+
+   udelay(1);
+   }
+
+   if (timeout= ABB_TRANXDONE_TIMEOUT) {
+   pr_warning(%s: vdd_%s ABB TRANXDONE timeout\n,
+   __func__, voltdm-name);
+   return -ETIMEDOUT;
+   }
+
+   /* program next state of ABB ldo */
+   voltdm-rmw(abb-common-opp_sel_mask,
+   opp_sel  __ffs(abb-common-opp_sel_mask),
+   abb-ctrl_offs);
+
+   /* initiate ABB ldo change */
+   voltdm-rmw(abb-common-opp_change_mask,
+   abb-common-opp_change_mask,
+   abb-ctrl_offs);
+
+   /* clear interrupt status */
+   timeout = 0;
+   while (timeout++  ABB_TRANXDONE_TIMEOUT) {
+   abb-common-ops-clear_tranxdone(abb-prm_irq_id);
+
+   ret = abb-common-ops-check_tranxdone(abb-prm_irq_id);
+   if (!ret)
+   break;
+
+   udelay(1);
+   }
+
+   if (timeout= ABB_TRANXDONE_TIMEOUT) {
+   pr_warning(%s: vdd_%s ABB TRANXDONE timeout\n,
+   __func__, voltdm-name);
+   return -ETIMEDOUT;
+   }
+
+   /* track internal state */
+   abb-_opp_sel = opp_sel;
+
+   return 0;
+}
+
+/*
+ * omap_abb_enable - enable ABB ldo on a particular voltage domain
+ *
+ * @voltdm - pointer to particular voltage domain
+ */
+void omap_abb_enable(struct voltagedomain *voltdm)
+{
+   struct omap_abb_instance *abb = voltdm-abb;
+
+   if (abb-enabled)
+   return;
+
+   abb-enabled = true;
+
+   voltdm-rmw(abb-common-sr2en_mask, abb-common-sr2en_mask,
+   abb-setup_offs);
+}
+
+/*
+ * omap_abb_disable - disable ABB ldo on a particular voltage domain
+ *
+ * @voltdm - pointer to particular voltage domain

[PATCH 0/8] OMAP3+: Voltage: introduce Adaptive Body-Bias ldo suppport

This patchset adds Adaptive Body-Bias ldo handling to the OMAP voltage
code with support for 36xx and 44xx chips.  ABB handling is a mandatory
part of the voltage scaling process when operating at high OPPs.

A longer explanation is that due to voltage domain trimming and silicon
characterstics some silicon may experience instability when operating at
a high voltage.  To compensate for this an Adaptive Body-Bias ldo
exists.  First featured in OMAP3630, the purpose of this ldo is to
provide a voltage boost to PMOS backgates when a voltage domain is
operating at a high OPP.  In this mode the ldo is said to be in Forward
Body-Bias.  At OPPs within a nominal voltage range the ABB ldo is
bypassed.

The TRM defines voltages that require Forward Body-Bias as FAST OPP's,
and all other voltages as NOMINAL OPP's.

Find more info in the 36xx TRM in section 3.5.6.6.1 ABB LDOs Control
and in the 4430 TRM in section 3.8.4.3 ABB LDOs Control and 3.10.4.2
Changing OPP.

Tested on OMAP 4430 SDP.  Built against Kevin's pm-wip/voltdm branch and
compiled with omap2plus_defconfig.

Mike Turquette (6):
  OMAP3630: PRM: add ABB PRM register definitions
  OMAP3+: ABB: Adaptive Body-Bias structures  data
  OMAP3+: OPP: add ABB data to voltage tables
  OMAP3+: Voltage: add ABB data to voltage domains
  OMAP3+: ABB: initialization  transition functions
  OMAP3+: Voltage: add ABB to voltage scaling

Nishanth Menon (2):
  OMAP3+: PM: VP: generalize PRM interrupt helpers
  OMAP3+: PRM: add tranxdone IRQ handlers for ABB

 arch/arm/mach-omap2/Makefile  |7 +-
 arch/arm/mach-omap2/abb.c |  218 +
 arch/arm/mach-omap2/abb.h |   90 ++
 arch/arm/mach-omap2/abb36xx_data.c|   38 +
 arch/arm/mach-omap2/abb44xx_data.c|   44 +
 arch/arm/mach-omap2/omap_opp_data.h   |5 +-
 arch/arm/mach-omap2/opp3xxx_data.c|   37 ++--
 arch/arm/mach-omap2/opp4xxx_data.c|   25 ++--
 arch/arm/mach-omap2/prm-regbits-34xx.h|   34 
 arch/arm/mach-omap2/prm2xxx_3xxx.c|   53 +--
 arch/arm/mach-omap2/prm2xxx_3xxx.h|   14 ++-
 arch/arm/mach-omap2/prm44xx.c |   64 +--
 arch/arm/mach-omap2/prm44xx.h |   10 +-
 arch/arm/mach-omap2/vc.c  |   10 +-
 arch/arm/mach-omap2/voltage.c |4 +
 arch/arm/mach-omap2/voltage.h |2 +
 arch/arm/mach-omap2/voltagedomains3xxx_data.c |3 +
 arch/arm/mach-omap2/voltagedomains44xx_data.c |3 +
 arch/arm/mach-omap2/vp.c  |9 +-
 arch/arm/mach-omap2/vp.h  |9 -
 arch/arm/mach-omap2/vp3xxx_data.c |4 +-
 arch/arm/mach-omap2/vp44xx_data.c |6 +-
 22 files changed, 598 insertions(+), 91 deletions(-)
 create mode 100644 arch/arm/mach-omap2/abb.c
 create mode 100644 arch/arm/mach-omap2/abb.h
 create mode 100644 arch/arm/mach-omap2/abb36xx_data.c
 create mode 100644 arch/arm/mach-omap2/abb44xx_data.c

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

[PATCH 8/8] OMAP3+: Voltage: add ABB to voltage scaling

Adaptive Body-Bias ldo state should be transitioned (if necessary) after
a voltage scaling sequence completes via vc_bypass or vp_forceupdate
methods.

This patch initializes the ABB ldo's as a part of the greater voltage
initialization function and adds the ABB transition routine to both the
vc_bypass and vp_forceupdate sequences.

Signed-off-by: Mike Turquette mturque...@ti.com
---
 arch/arm/mach-omap2/vc.c  |   10 --
 arch/arm/mach-omap2/voltage.c |4 
 arch/arm/mach-omap2/vp.c  |9 +++--
 3 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index aa9f0bc..6c51cc3 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -6,6 +6,7 @@
 
 #include voltage.h
 #include vc.h
+#include abb.h
 #include prm-regbits-34xx.h
 #include prm-regbits-44xx.h
 #include prm44xx.h
@@ -155,7 +156,7 @@ int omap_vc_bypass_scale_voltage(struct voltagedomain 
*voltdm,
u32 loop_cnt = 0, retries_cnt = 0;
u32 vc_valid, vc_bypass_val_reg, vc_bypass_value;
u8 target_vsel, current_vsel;
-   int ret;
+   int ret = 0;
 
ret = omap_vc_pre_scale(voltdm, target_volt, target_vsel, 
current_vsel);
if (ret)
@@ -193,7 +194,12 @@ int omap_vc_bypass_scale_voltage(struct voltagedomain 
*voltdm,
}
 
omap_vc_post_scale(voltdm, target_volt, target_vsel, current_vsel);
-   return 0;
+
+   /* transition Adaptive Body-Bias ldo */
+   if (voltdm-abb)
+   ret = omap_abb_set_opp(voltdm);
+
+   return ret;
 }
 
 static void __init omap3_vfsm_init(struct voltagedomain *voltdm)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 97f96ae..df6eac6 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -40,6 +40,7 @@
 
 #include vc.h
 #include vp.h
+#include abb.h
 
 static LIST_HEAD(voltdm_list);
 
@@ -311,6 +312,9 @@ int __init omap_voltage_late_init(void)
 
if (voltdm-vc)
omap_vc_init_channel(voltdm);
+
+   if (voltdm-abb)
+   omap_abb_init(voltdm);
}
 
return 0;
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 3807620..76de8cd 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -5,6 +5,7 @@
 
 #include voltage.h
 #include vp.h
+#include abb.h
 #include prm-regbits-34xx.h
 #include prm-regbits-44xx.h
 #include prm44xx.h
@@ -124,7 +125,7 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
struct omap_vp_instance *vp = voltdm-vp;
u32 vpconfig;
u8 target_vsel, current_vsel;
-   int ret, timeout = 0;
+   int ret = 0, timeout = 0;
 
ret = omap_vc_pre_scale(voltdm, target_volt, target_vsel, 
current_vsel);
if (ret)
@@ -202,7 +203,11 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
vpconfig = ~vp-common-vpconfig_forceupdate;
voltdm-write(vpconfig, vp-vpconfig);
 
-   return 0;
+   /* transition Adaptive Body-Bias LDO */
+   if (voltdm-abb)
+   ret = omap_abb_set_opp(voltdm);
+
+   return ret;
 }
 
 /**
-- 
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

[PATCH 2/8] OMAP3+: PM: VP: generalize PRM interrupt helpers

From: Nishanth Menon n...@ti.com

We have multiple interrupt status hidden in the PRM interrupt status
reg. Make this handling generic to allow us to pull out LDO status such
as those for ABB from it using the same data structure and indexing. We
hence rename accordingly.

We also fix a trivial warning as the variable does not need exporting:
arch/arm/mach-omap2/prm2xxx_3xxx.c:172:22: warning: symbol
'omap3_prm_irqs' was not declared. Should it be static?

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Mike Turquette mturque...@ti.com
---
 arch/arm/mach-omap2/prm2xxx_3xxx.c |   22 +++---
 arch/arm/mach-omap2/prm2xxx_3xxx.h |7 +--
 arch/arm/mach-omap2/prm44xx.c  |   28 ++--
 arch/arm/mach-omap2/prm44xx.h  |7 +--
 arch/arm/mach-omap2/vp.h   |9 -
 arch/arm/mach-omap2/vp3xxx_data.c  |4 ++--
 arch/arm/mach-omap2/vp44xx_data.c  |6 +++---
 7 files changed, 40 insertions(+), 43 deletions(-)

diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c 
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 3b83763..8a20242 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -162,39 +162,39 @@ int omap2_prm_deassert_hardreset(s16 prm_mod, u8 
rst_shift, u8 st_shift)
 /* PRM VP */
 
 /*
- * struct omap3_vp - OMAP3 VP register access description.
+ * struct omap3_prm_irq - OMAP3 PRM IRQ register access description.
  * @tranxdone_status: VP_TRANXDONE_ST bitmask in PRM_IRQSTATUS_MPU reg
  */
-struct omap3_vp {
+struct omap3_prm_irq {
u32 tranxdone_status;
 };
 
-struct omap3_vp omap3_vp[] = {
-   [OMAP3_VP_VDD_MPU_ID] = {
+static struct omap3_prm_irq omap3_prm_irqs[] = {
+   [OMAP3_PRM_IRQ_VDD_MPU_ID] = {
.tranxdone_status = OMAP3430_VP1_TRANXDONE_ST_MASK,
},
-   [OMAP3_VP_VDD_CORE_ID] = {
+   [OMAP3_PRM_IRQ_VDD_CORE_ID] = {
.tranxdone_status = OMAP3430_VP2_TRANXDONE_ST_MASK,
},
 };
 
 #define MAX_VP_ID ARRAY_SIZE(omap3_vp);
 
-u32 omap3_prm_vp_check_txdone(u8 vp_id)
+u32 omap3_prm_vp_check_txdone(u8 irq_id)
 {
-   struct omap3_vp *vp = omap3_vp[vp_id];
+   struct omap3_prm_irq *irq = omap3_prm_irqs[irq_id];
u32 irqstatus;
 
irqstatus = omap2_prm_read_mod_reg(OCP_MOD,
   OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
-   return irqstatus  vp-tranxdone_status;
+   return irqstatus  irq-tranxdone_status;
 }
 
-void omap3_prm_vp_clear_txdone(u8 vp_id)
+void omap3_prm_vp_clear_txdone(u8 irq_id)
 {
-   struct omap3_vp *vp = omap3_vp[vp_id];
+   struct omap3_prm_irq *irq = omap3_prm_irqs[irq_id];
 
-   omap2_prm_write_mod_reg(vp-tranxdone_status,
+   omap2_prm_write_mod_reg(irq-tranxdone_status,
OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
 }
 
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h 
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index 408d1c7..d90b23f 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -307,9 +307,12 @@ extern int omap2_prm_is_hardreset_asserted(s16 prm_mod, u8 
shift);
 extern int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift);
 extern int omap2_prm_deassert_hardreset(s16 prm_mod, u8 rst_shift, u8 
st_shift);
 
+#define OMAP3_PRM_IRQ_VDD_MPU_ID   0
+#define OMAP3_PRM_IRQ_VDD_CORE_ID  1
 /* OMAP3-specific VP functions */
-u32 omap3_prm_vp_check_txdone(u8 vp_id);
-void omap3_prm_vp_clear_txdone(u8 vp_id);
+u32 omap3_prm_vp_check_txdone(u8 irq_id);
+void omap3_prm_vp_clear_txdone(u8 irq_id);
+
 
 /*
  * OMAP3 access functions for voltage controller (VC) and
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 8a3bba3..9d0b641 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -200,49 +200,49 @@ void omap4_prm_global_warm_sw_reset(void)
 /* PRM VP */
 
 /*
- * struct omap4_vp - OMAP4 VP register access description.
+ * struct omap4_prm_irq - OMAP4 VP register access description.
  * @irqstatus_mpu: offset to IRQSTATUS_MPU register for VP
  * @tranxdone_status: VP_TRANXDONE_ST bitmask in PRM_IRQSTATUS_MPU reg
  */
-struct omap4_vp {
+struct omap4_prm_irq {
u32 irqstatus_mpu;
u32 tranxdone_status;
 };
 
-static struct omap4_vp omap4_vp[] = {
-   [OMAP4_VP_VDD_MPU_ID] = {
+static struct omap4_prm_irq omap4_prm_irqs[] = {
+   [OMAP4_PRM_IRQ_VDD_MPU_ID] = {
.irqstatus_mpu = OMAP4_PRM_IRQSTATUS_MPU_2_OFFSET,
.tranxdone_status = OMAP4430_VP_MPU_TRANXDONE_ST_MASK,
},
-   [OMAP4_VP_VDD_IVA_ID] = {
+   [OMAP4_PRM_IRQ_VDD_IVA_ID] = {
.irqstatus_mpu = OMAP4_PRM_IRQSTATUS_MPU_OFFSET,
.tranxdone_status = OMAP4430_VP_IVA_TRANXDONE_ST_MASK,
},
-   [OMAP4_VP_VDD_CORE_ID] = {
+   [OMAP4_PRM_IRQ_VDD_CORE_ID] = {
.irqstatus_mpu = OMAP4_PRM_IRQSTATUS_MPU_OFFSET,
.tranxdone_status =

[PATCH 6/8] OMAP3+: Voltage: add ABB data to voltage domains

Starting with OMAP36xx, some voltage domains have an ABB ldo meant to
insure stability when that voltage domain is operating at a high OPP.

This patch adds struct omap_abb_instance to struct voltagedomain and
populates the data for those voltage domains that have an ABB ldo on
both 36xx and 44xx silicon.

Signed-off-by: Mike Turquette mturque...@ti.com
---
 arch/arm/mach-omap2/voltage.h |1 +
 arch/arm/mach-omap2/voltagedomains3xxx_data.c |3 +++
 arch/arm/mach-omap2/voltagedomains44xx_data.c |3 +++
 3 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 51c0b31..5d567a2 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -71,6 +71,7 @@ struct voltagedomain {
struct omap_vc_channel *vc;
const struct omap_vfsm_instance *vfsm;
struct omap_vp_instance *vp;
+   struct omap_abb_instance *abb;
struct omap_voltdm_pmic *pmic;
 
/* VC/VP register access functions: SoC specific */
diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c 
b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
index e7a0be1..a7473e1 100644
--- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
@@ -26,6 +26,7 @@
 #include voltage.h
 #include vc.h
 #include vp.h
+#include abb.h
 
 /*
  * VDD data
@@ -96,6 +97,8 @@ void __init omap3xxx_voltagedomains_init(void)
if (cpu_is_omap3630()) {
omap3_vdd1_info.volt_data = omap36xx_vddmpu_volt_data;
omap3_vdd2_info.volt_data = omap36xx_vddcore_volt_data;
+
+   omap3_voltdm_mpu.abb = omap36xx_abb_mpu;
} else {
omap3_vdd1_info.volt_data = omap34xx_vddmpu_volt_data;
omap3_vdd2_info.volt_data = omap34xx_vddcore_volt_data;
diff --git a/arch/arm/mach-omap2/voltagedomains44xx_data.c 
b/arch/arm/mach-omap2/voltagedomains44xx_data.c
index d5f06c5e..31124c4 100644
--- a/arch/arm/mach-omap2/voltagedomains44xx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains44xx_data.c
@@ -32,6 +32,7 @@
 #include omap_opp_data.h
 #include vc.h
 #include vp.h
+#include abb.h
 
 static const struct omap_vfsm_instance omap4_vdd_mpu_vfsm = {
.voltsetup_reg = OMAP4_PRM_VOLTSETUP_MPU_RET_SLEEP_OFFSET,
@@ -60,6 +61,7 @@ static struct voltagedomain omap4_voltdm_mpu = {
.vc = omap4_vc_mpu,
.vfsm = omap4_vdd_mpu_vfsm,
.vp = omap4_vp_mpu,
+   .abb = omap4_abb_mpu,
.vdd = omap4_vdd_mpu_info,
 };
 
@@ -72,6 +74,7 @@ static struct voltagedomain omap4_voltdm_iva = {
.vc = omap4_vc_iva,
.vfsm = omap4_vdd_iva_vfsm,
.vp = omap4_vp_iva,
+   .abb = omap4_abb_iva,
.vdd = omap4_vdd_iva_info,
 };
 
-- 
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: [PATCH 2/3] MMC: OMAP: HSMMC: add runtime pm support

+ Venkat

Hi Balaji

On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:

 On Wed, Jun 29, 2011 at 2:00 AM, Kevin Hilman khil...@ti.com wrote:
  T Krishnamoorthy, Balaji balaj...@ti.com writes:
 
  I have seen some instabilities if delay is very less, on some 
  production boards. The previous implementation used 100ms delay 
  before disabling the clocks.
 
  And your new one is using 50ms.  How did this value come about?

 I don't have any specific affinity to this number, but when requests are 
 bursty, they arrive within a few 10s of ms within each other. Didn't 
 want to have the context/save restore penalty associated with every 
 request.

Kevin and I just chatted a little bit about this.  It seems best to 
separate the work done on the autosuspend timeout from the runtime PM 
conversion.  

So how about this: please send a new version of these patches with the 
previous value, 100ms, for the autosuspend timeout.  That should hopefully 
minimize the behavior change here for existing users.  And hopefully we'll 
be able to get the series in for this merge window.

Then later, we need to come back to this autosuspend timeout issue.


- Paul

[PATCH] OMAP: DSS2: DSI: Support non-dcs long read

2011-06-29 Thread Arve Hjønnevåg

Change-Id: I18168c887e1384c07dc033a1ffc57abdacb26073
Signed-off-by: Arve Hjønnevåg a...@android.com
---
 drivers/video/omap2/dss/dsi.c |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index c16b933..6975645 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -206,6 +206,7 @@ struct dsi_reg { u16 idx; };
 #define DSI_DT_DCS_LONG_WRITE  0x39
 
 #define DSI_DT_RX_ACK_WITH_ERR 0x02
+#define DSI_DT_RX_LONG_READ0x1a
 #define DSI_DT_RX_DCS_LONG_READ0x1c
 #define DSI_DT_RX_SHORT_READ_1 0x21
 #define DSI_DT_RX_SHORT_READ_2 0x22
@@ -2943,6 +2944,10 @@ static u16 dsi_vc_flush_receive_data(struct 
platform_device *dsidev,
} else if (dt == DSI_DT_RX_SHORT_READ_2) {
DSSERR(\tDCS short response, 2 byte: %#x\n,
FLD_GET(val, 23, 8));
+   } else if (dt == DSI_DT_RX_LONG_READ) {
+   DSSERR(\tlong response, len %d\n,
+   FLD_GET(val, 23, 8));
+   dsi_vc_flush_long_data(dsidev, channel);
} else if (dt == DSI_DT_RX_DCS_LONG_READ) {
DSSERR(\tDCS long response, len %d\n,
FLD_GET(val, 23, 8));
@@ -3287,7 +3292,7 @@ int dsi_vc_dcs_read(struct omap_dss_device *dssdev, int 
channel, u8 dcs_cmd,
buf[1] = (data  8)  0xff;
 
return 2;
-   } else if (dt == DSI_DT_RX_DCS_LONG_READ) {
+   } else if (dt == DSI_DT_RX_DCS_LONG_READ || dt == DSI_DT_RX_LONG_READ) {
int w;
int len = FLD_GET(val, 23, 8);
if (dsi-debug_read)
-- 
1.7.3.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: [PATCHv2 2/3] MMC: OMAP: HSMMC: add runtime pm support

On Wed, Jun 29, 2011 at 11:26 PM, Kevin Hilman khil...@ti.com wrote:
 T Krishnamoorthy, Balaji balaj...@ti.com writes:

 On Wed, Jun 29, 2011 at 5:02 AM, Kevin Hilman khil...@ti.com wrote:
 +Rajendra

 Balaji T K balaj...@ti.com writes:

 add runtime pm support to HSMMC host controller
 Use runtime pm API to enable/disable HSMMC clock
 Use runtime autosuspend APIs to enable auto suspend delay

 Based on OMAP HSMMC runtime implementation by Kevin Hilman, Kishore 
 Kadiyala

 Signed-off-by: Balaji T K balaj...@ti.com

 I tried to test this series along with Benoit's clkdm/modulemode/hwmod
 cleanups and something strange is happening on OMAP4.

 First, this series by itself is working as I would expect, but testing
 in combination with Benoit's series, it's different...

 First, I'm using Benoit's branch:

       git://gitorious.org/omap-pm/linux.git for_3.0.1/7_hwmod_modulemode

 in combination with your series.

 I've also reverted these two commits:

   OMAP4: PM: TEMP: Prevent l3init from idling/force sleep
   OMAP3+: hwmod data: TEMP: Do not idle MMC1  MMC2 after boot

 which are temporary workarounds for not having MMC runtime PM.

 I turned the dev_dbg calls in the runtime PM callbacks into dev_info
 callbacks to see exactly when the device is enabled/disabled via runtime
 PM.

 To my surprise, I didn't see the device being enabled/disabled when
 writing do the device.

 I tried for_3.0.1/7_hwmod_modulemode as you mentioned above,
 changing dev_dbg to dev_err and I am not observing the delayed write
 during umount. Can you let me know if the files are there in MMC after
 remounting ?

 Did you also revert the above two commits?

yes


 I've pushed a 'tmp/mmc' branch to my git tree[1] which is my PM branch
 (including various PM stuff queued for upstream) as well as Benoit's
 series with the TEMP patches above reverted and your series on top of
 it.  There's one additional patch to convert the dev_dbg into dev_info
 to see the transitions.

 Testing this on my OMAP4430 ES2.2 EMU device, I still see the above
 behavior.

I used OMAP4430 ES2.1 GP


 Can you try out this branch on your board using the default
 omap2plus_defconfig?

Ok, I will retry on EMU device.


 Thanks,

 Kevin

 [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git

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

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

2011-06-29 Thread S, Venkatraman

On Thu, Jun 30, 2011 at 1:37 AM, Paul Walmsley p...@pwsan.com wrote:
cc'ing lakml

Hi Venkat, Balaji,

On Wed, 29 Jun 2011, S, Venkatraman wrote:

On Wed, Jun 29, 2011 at 9:08 PM, Paul Walmsley p...@pwsan.com wrote:
On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:

There have been some experiments on our customer programs to reduce this
value to a few ms and infrequent crashes were observed (stress testing
for several hours) while trying to access the controller registers.

By the way, could you send along a copy of the stress test script?

Paul, these scenarios are not scripted but end user tests with
additional devices
(WLAN, which is connected on the same controller) and executed 'on field' .

OK, thanks Venkat. Do you still have one of these devices so the test can
be repeated?

One such log is here .. http://pastebin.com/nq3cfZnT

Looks like this is an Android 2.6.35.7-derived kernel on a 4430 ES2.2 EMU.
Power management is enabled but MPU, L3INIT, and PER aren't entering any
deeper power states than retention idle, so no context save/restore or
off-mode worries here.

The system looks like it's entered suspend at least once and resumed,
before the oops. Also the second CPU is starting up and shutting down
dynamically. Backtrace is copied below for the archives.

Does the above summary match your understanding?

Yes it does.

...

Reviewing this backtrace and the one that Balaji sent, it looks to
me like this write in omap_hsmmc_prepare_data() is the proximate
cause of the abort:

OMAP_HSMMC_WRITE(host-base, BLK, (req-data-blksz)
| (req-data-blocks 16));

I'll bet this was first access to the MMC IP block after the MMC layer
re-enabled it. The abort is imprecise because the Linux OMAP4 kernel
marks MMIO registers as bufferable, so the ARM can continue executing
while a register write is making its way across the OMAP interconnect(s).
This guess also assumes that the ARM is executing instructions out of
order, which is a reasonable assumption on a Cortex-A9. This could be
confirmed by reading some HSMMC register right before the
OMAP_HSMMC_WRITE(); then the abort would turn precise and occur on the
read.

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

Anyway, it looks like the HSMMC IP block wasn't yet ready to be accessed.
Probably, this is because either the HSMMC IP block hasn't yet left the
Idle or SleepTrans states, and the OMAP4 clock framework doesn't wait for
that; or the PRCM is getting confused because the correct clockdomain
enable sequence isn't being followed -- see for example the Fix
module-mode enable sequence on OMAP4 patch series that have been posted
to the linux-omap mailing list. Probably one of those two issues is the
root cause.

If you have a testing setup where you can reproduce this problem, I'd
suggest adding the read as described above. Otherwise, I don't think this
will be an issue for the runtime PM conversion: first, because the hwmod
code will wait for the HSMMC block to indicate that it has left idle
before continuing; and second, because we'll hopefully have a patch series
going in at the same time to make sure the clockdomain enable sequence is
correct.

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

- Paul

0 Process mmcqd (pid: 851, stack limit = 0xef9682f8)
0 Stack: (0xef969db8 to 0xef96a000)
0 9da0: ef969ee4
efa30640
0 9dc0: ef969e78 0001 efa30400 ef969e2c ef969de0 c06ae2b8
c06ace10
0 9de0: efa305d8 ef969e04 efa30400 efa30578 ef969e44
ef969e08
0 9e00: c054ea5c ef969e78 efa30400 ef969e34 0001 ef837e4c
ef969ee4
0 9e20: ef969e64 ef969e30 c06a54d8 c06adff4

0 9e40: ef969e40 ef969e40 ed3d4680 ed3d4680 efa30c00 ef837e40 ef969f94
ef969e68
0 9e60: c06abe80 c06a53cc efa31458 ef0cfdb4 ef0cfdb4 ef969e8c
ef969ee4
0 9e80: ef969eb8 ef969e34 c06a55d0 0019 00fd50a2

0 9ea0: 00b5 ef969ee4 ef969e78 000c

0 9ec0: 049d

0 9ee0: ef969e78 23c34600 0fa0 0200 0400 0100

0 9f00: ef969eb8 ef969e78 003f ef238000 ef969f54 ef969f20 c0556c00
c0555fac
0 9f20: ef969f3c 0001 c0425fa0 ef837e4c ef23 ef837e54 ef837e4c
ef23
0 9f40: ef837e54 ef23 ef969f7c ef969f58 ed3d4680 ef969f7c
ef969f68
0 9f60:

Re: about n810 integration status

2011-06-29 Thread Sakari Ailus

On Sat, Jun 25, 2011 at 03:00:01PM +0900, Kim HeungJun wrote:
 Hi everyone,

Hi HeungJun,

 Does anybody knows about n810 integration status on Kernel? I have one
 n810, and I try to update the newest kernel and filesystem image freely.
 And, if anyone know about , please let me know.

Are you using your own root filesystem or the original Diablo one?

I've been using Debian without display so I just have had a serial console.
The display might be working as well --- I just haven't tried it since the
serial port is enough for me right now. :-P I can find my kernel .config if
you're interested. NFS over USB works fine.

Just grab latest linux-omap kernel. I don't think all the required CBUS
changes are in mainline quite yet, but they're on their way there.

 The information which I know is just the flasher from Nokia is needed for
 updating. And, I can compile kernel and handle a litte.

Flashing instructions are available here:

URL:http://wiki.maemo.org/index.php?title=Updating_the_firmwareoldid=17120

It's the same flasher as on N900.

Regards,

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

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

2011-06-29 Thread S, Venkatraman

On Thu, Jun 30, 2011 at 6:10 AM, Paul Walmsley p...@pwsan.com wrote:
 + Venkat

 Hi Balaji

 On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote:

 On Wed, Jun 29, 2011 at 2:00 AM, Kevin Hilman khil...@ti.com wrote:
  T Krishnamoorthy, Balaji balaj...@ti.com writes:
 
  I have seen some instabilities if delay is very less, on some
  production boards. The previous implementation used 100ms delay
  before disabling the clocks.
 
  And your new one is using 50ms.  How did this value come about?

 I don't have any specific affinity to this number, but when requests are
 bursty, they arrive within a few 10s of ms within each other. Didn't
 want to have the context/save restore penalty associated with every
 request.

 Kevin and I just chatted a little bit about this.  It seems best to
 separate the work done on the autosuspend timeout from the runtime PM
 conversion.

 So how about this: please send a new version of these patches with the
 previous value, 100ms, for the autosuspend timeout.  That should hopefully
 minimize the behavior change here for existing users.  And hopefully we'll
 be able to get the series in for this merge window.

 Then later, we need to come back to this autosuspend timeout issue.


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

Re: [PATCH] arm: platsmp: Allow secondary cpu hotplug with maxcpus=1

2011-06-29 Thread Paul Mundt

On Wed, Jun 29, 2011 at 11:31:39AM -0700, Stephen Boyd wrote:
 If an ARM system has multiple cpus in the same socket and the
 kernel is booted with maxcpus=1, secondary cpus are possible but
 not present due to how platform_smp_prepare_cpus() is called.
 Fix this by always calling platform_smp_prepare_cpus() as long as
 max_cpus is non-zero (0 means no SMP) to allow platform code to
 decide if any non-boot cpus are present in the system. Since
 all current platform code doesn't support physical hotplug we
 have a situation where possible == present and thus we can
 simply copy the possible map to the present map.
 
 With this patch it's possible to boot an ARM system with
 maxcpus=1 on the command line and then hotplug in secondary cpus
 via sysfs. This is more in line with how x86 works with maxcpus=1
 on the command line.
 
 Signed-off-by: Stephen Boyd sb...@codeaurora.org

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

Re: [PATCHv4 1/9] omap: prcm: switch to a chained IRQ handler mechanism