Re: [RFC 7/7] iommu/core: split mapping to page sizes as supported by the hardware
Hi Cho, On Wed, Sep 7, 2011 at 4:30 AM, KyongHo Cho pullip@samsung.com wrote: Please find the following link that I submitted for our IOMMU. https://lkml.org/lkml/2011/7/3/152 s5p_iommu_map/unmap accepts any order of physical address and iova without support of your suggestion if the order is not less than PAGE_SHIFT That's exactly what I'm trying to prevent; there's no reason to duplicate the exact same logic in every iommu driver. As a result, your map function is quite big (it even duplicates the same logic for every page size it tries). Try to rebase your patch on the iommu/core: split mapping to page sizes as supported by the hardware patch I've just sent, and see how significantly simpler your code becomes. Relying on a single implementation, provided by the IOMMU core, means less code to maintain (and debug) and a consistent behavior (across all supported hardware) exposed to users of the IOMMU API. But I think IOMMU API must not expect that the caller of iommu_map() knows about the restriction of IOMMU API implementation. Right. But I don't think there's any disagreement here ? If any, then I think that s5p_iommu_map() is more limited than what I propose: if it is given a 64KB region aligned only to a 4KB address, it will BUG_ON() it. While not ideal, I don't think there's any reason not to map it using 4KB pages (which is exactly what the new iommu_map() I propose will do). Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 22/25] gpio/omap: save and restore debounce registers
On Wed, Sep 7, 2011 at 5:33 AM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Nishant Menon n...@ti.com
Check spelling of first name (I believe version in signed-off-by below
is the correct one.)
Yes, it should haven been Nishanth.
GPIO debounce registers need to be saved and restored for proper functioning
of driver. To save the registers, we cannot cut the clock before the save,
hence move the clk disable after the save.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c | 22 +++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index dc382f6..67e08e9 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -41,6 +41,8 @@ struct gpio_regs {
u32 risingdetect;
u32 fallingdetect;
u32 dataout;
+ u32 debounce;
+ u32 debounce_en;
};
struct gpio_bank {
@@ -1158,9 +1160,6 @@ static int omap_gpio_runtime_suspend(struct device
*dev)
u32 l1 = 0, l2 = 0;
int j;
- for (j = 0; j hweight_long(bank-dbck_enable_mask); j++)
- clk_disable(bank-dbck);
-
if (!bank-mod_usage)
return 0;
@@ -1192,6 +1191,16 @@ update_gpio_context_count:
bank-context_loss_count =
bank-get_context_loss_count(bank-dev);
+ if (bank-dbck_enable_mask) {
+ bank-context.debounce = __raw_readl(bank-base +
+ bank-regs-debounce);
+ bank-context.debounce_en = __raw_readl(bank-base +
+ bank-regs-debounce_en);
Here you're taking a step backwards from the goal of not having to read
registers in the runtime suspend callback.
Rather than reading the registers here, the values should be saved into
bank-context when they are initially written (_set_gpio_debounce()), so
you don't have the overhead of reading the registers in -runtime_suspend.
Good catch! Thanks.
--
Tarun
+ }
+
+ for (j = 0; j hweight_long(bank-dbck_enable_mask); j++)
+ clk_disable(bank-dbck);
+
return 0;
}
@@ -1331,6 +1340,13 @@ static void omap_gpio_restore_context(struct
gpio_bank *bank)
__raw_writel(bank-context.fallingdetect,
bank-base + bank-regs-fallingdetect);
__raw_writel(bank-context.dataout, bank-base + bank-regs-dataout);
+
+ if (bank-dbck_enable_mask) {
+ __raw_writel(bank-context.debounce, bank-base +
+ bank-regs-debounce);
+ __raw_writel(bank-context.debounce_en,
+ bank-base + bank-regs-debounce_en);
+ }
}
#else
#define omap_gpio_runtime_suspend NULL
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 v6 24/25] gpio/omap: restore OE only after setting the output level
On Wed, Sep 7, 2011 at 5:36 AM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Nishanth Menon n...@ti.com
Setup the dataout register before setting the GPIO to output mode
in restore path.
Please summarize why. (again, it may seem obvious now, but may not be for
those not familiar with the driver or when coming back to it after a few
months looking at other code.
Ok.
Kevin
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index db22df8..a629498 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1326,7 +1326,6 @@ static void omap_gpio_restore_context(struct gpio_bank
*bank)
__raw_writel(bank-context.wake_en,
bank-base + bank-regs-wkup_en);
__raw_writel(bank-context.ctrl, bank-base + bank-regs-ctrl);
- __raw_writel(bank-context.oe, bank-base + bank-regs-direction);
__raw_writel(bank-context.leveldetect0,
bank-base + bank-regs-leveldetect0);
__raw_writel(bank-context.leveldetect1,
@@ -1336,6 +1335,7 @@ static void omap_gpio_restore_context(struct gpio_bank
*bank)
__raw_writel(bank-context.fallingdetect,
bank-base + bank-regs-fallingdetect);
__raw_writel(bank-context.dataout, bank-base + bank-regs-dataout);
+ __raw_writel(bank-context.oe, bank-base + bank-regs-direction);
if (bank-dbck_enable_mask) {
__raw_writel(bank-context.debounce, bank-base +
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend.
Hi, On Sat, 2011-08-27 at 21:42 +0200, Alan Stern wrote: On Sat, 27 Aug 2011, Santosh wrote: On Saturday 27 August 2011 07:31 PM, Alan Stern wrote: On Sat, 27 Aug 2011, Santosh wrote: I might be wrong here, but after discussion with Govindraj on this issue, it seems there is a flaw in the way OMAP chain handler handling the child interrupts. On OMAP, we have special interrupt wakeup source at PRCM level and many devices can trigger wakeup from low power via this common interrupt source. The common interrupt source upon wakeup from low power state, decodes the source of interrupt and based on that source, calls the respective device ISR directly. The issue I see here is, the ISR on _a_ device (UART in this case) is happening even before UART resume and DPM resume has been completed. If this is the case, then it is surely asking for trouble. Because not just clocks, but even driver state machine is already in suspend state when the ISR is called. If the driver state machine is in the suspend state when the ISR is called, then the ISR should realize it is handling a wakeup event instead of a normal I/O event. All it needs to do is turn off the interrupt source; the event itself will be taken care of during the device's resume callback. Good point but the ISR is called as a function call and not real hardware event so no need to turn-off the source in the child ISR. Parent ISR will clear the source anyways. But the intention here is to record the event for the child. In that case the ISR only has to record the event. I mean for UART wakeup, the received character should be extracted. If not done, UART will loose that character because the event is lost. So not sure how the event will be taken care during resume callback. Could you elaborate bit more on last comment please? The resume callback routine must check to see if an event was recorded. If one was, the routine must see whether a character was received while the system was asleep and extract the character from the UART. (It probably won't hurt to do this even if an event wasn't recorded.) Alan Stern After thinking about this problem and looking at possible ways to fix it, I am planning to change the PRCM chain handler to be a driver, which gets suspended along with the rest of the system. This means the PRCM interrupt would get disabled also during this time, and it would be enabled in the driver-complete() call, which should happen after rest of the drivers have been able to enable their PM runtime in the driver-resume() call chain. Do you see any problems with this approach? The only issue I am seeing myself is if some driver decides to do resume() in the complete() pm-op and potentially screwing the ordering here... -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
[PATCH v4 08/11] Serial: OMAP2+: Move erratum handling from serial.c
Move the erratum handling mechanism from serial.c to driver file
and utilise the same func in driver file.
Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
drivers/tty/serial/omap-serial.c | 58 ++---
1 files changed, 53 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 30bdd05..96fc860 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -52,6 +52,7 @@ static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
static void uart_tx_dma_callback(int lch, u16 ch_status, void *data);
static void serial_omap_rx_timeout(unsigned long uart_no);
static int serial_omap_start_rxdma(struct uart_omap_port *up);
+static void omap_uart_mdr1_errataset(struct uart_omap_port *up, u8 mdr1);
static inline unsigned int serial_in(struct uart_omap_port *up, int offset)
{
@@ -805,7 +806,11 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
/* Protocol, Baud Rate, and Interrupt Settings */
- serial_out(up, UART_OMAP_MDR1, up-mdr1);
+ if (up-errata UART_ERRATA_i202_MDR1_ACCESS)
+ omap_uart_mdr1_errataset(up, up-mdr1);
+ else
+ serial_out(up, UART_OMAP_MDR1, up-mdr1);
+
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
up-efr = serial_in(up, UART_EFR);
@@ -830,7 +835,10 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
else
up-mdr1 = UART_OMAP_MDR1_16X_MODE;
- serial_out(up, UART_OMAP_MDR1, up-mdr1);
+ if (up-errata UART_ERRATA_i202_MDR1_ACCESS)
+ omap_uart_mdr1_errataset(up, up-mdr1);
+ else
+ serial_out(up, UART_OMAP_MDR1, up-mdr1);
/* Hardware Flow Control Configuration */
@@ -1424,9 +1432,47 @@ static int serial_omap_remove(struct platform_device
*dev)
return 0;
}
+/*
+ * Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6)
+ * The access to uart register after MDR1 Access
+ * causes UART to corrupt data.
+ *
+ * Need a delay =
+ * 5 L4 clock cycles + 5 UART functional clock cycle (@48MHz = ~0.2uS)
+ * give 10 times as much
+ */
+static void omap_uart_mdr1_errataset(struct uart_omap_port *up, u8 mdr1)
+{
+ u8 timeout = 255;
+
+ serial_out(up, UART_OMAP_MDR1, mdr1);
+ udelay(2);
+ serial_out(up, UART_FCR, up-fcr | UART_FCR_CLEAR_XMIT |
+ UART_FCR_CLEAR_RCVR);
+ /*
+* Wait for FIFO to empty: when empty, RX_FIFO_E bit is 0 and
+* TX_FIFO_E bit is 1.
+*/
+ while (UART_LSR_THRE != (serial_in(up, UART_LSR)
+ (UART_LSR_THRE | UART_LSR_DR))) {
+ timeout--;
+ if (!timeout) {
+ /* Should *never* happen. we warn and carry on */
+ dev_crit(up-pdev-dev, Errata i202: timedout %x\n,
+ serial_in(up, UART_LSR));
+ break;
+ }
+ udelay(1);
+ }
+}
+
static void omap_uart_restore_context(struct uart_omap_port *up)
{
- serial_out(up, UART_OMAP_MDR1, up-mdr1);
+ if (up-errata UART_ERRATA_i202_MDR1_ACCESS)
+ omap_uart_mdr1_errataset(up, UART_OMAP_MDR1_DISABLE);
+ else
+ serial_out(up, UART_OMAP_MDR1, UART_OMAP_MDR1_DISABLE);
+
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B); /* Config B mode */
serial_out(up, UART_EFR, UART_EFR_ECB);
serial_out(up, UART_LCR, 0x0); /* Operational mode */
@@ -1442,8 +1488,10 @@ static void omap_uart_restore_context(struct
uart_omap_port *up)
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B); /* Config B mode */
serial_out(up, UART_EFR, up-efr);
serial_out(up, UART_LCR, up-lcr);
- /* UART 16x mode */
- serial_out(up, UART_OMAP_MDR1, up-mdr1);
+ if (up-errata UART_ERRATA_i202_MDR1_ACCESS)
+ omap_uart_mdr1_errataset(up, up-mdr1);
+ else
+ serial_out(up, UART_OMAP_MDR1, up-mdr1);
}
static int omap_serial_runtime_suspend(struct device *dev)
--
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 v4 06/11] Serial: OMAP: Store certain reg values to port structure
In preparation to runtime conversion add missing uart regs to
port structure which can be used in context restore.
Also ensuring all uart reg info's are part of port structure.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/plat-omap/include/plat/omap-serial.h |3 ++
drivers/tty/serial/omap-serial.c | 33 ++--
2 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index f79a76f..06e3aa2 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -104,6 +104,9 @@ struct uart_omap_port {
unsigned char mcr;
unsigned char fcr;
unsigned char efr;
+ unsigned char dll;
+ unsigned char dlh;
+ unsigned char mdr1;
int use_dma;
/*
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 5e713d3..6ac0ade 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -433,8 +433,9 @@ static void serial_omap_set_mctrl(struct uart_port *port,
unsigned int mctrl)
if (mctrl TIOCM_LOOP)
mcr |= UART_MCR_LOOP;
- mcr |= up-mcr;
- serial_out(up, UART_MCR, mcr);
+ up-mcr = serial_in(up, UART_MCR);
+ up-mcr |= mcr;
+ serial_out(up, UART_MCR, up-mcr);
}
static void serial_omap_break_ctl(struct uart_port *port, int break_state)
@@ -573,8 +574,6 @@ static inline void
serial_omap_configure_xonxoff
(struct uart_omap_port *up, struct ktermios *termios)
{
- unsigned char efr = 0;
-
up-lcr = serial_in(up, UART_LCR);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
up-efr = serial_in(up, UART_EFR);
@@ -584,8 +583,7 @@ serial_omap_configure_xonxoff
serial_out(up, UART_XOFF1, termios-c_cc[VSTOP]);
/* clear SW control mode bits */
- efr = up-efr;
- efr = OMAP_UART_SW_CLR;
+ up-efr = OMAP_UART_SW_CLR;
/*
* IXON Flag:
@@ -593,7 +591,7 @@ serial_omap_configure_xonxoff
* Transmit XON1, XOFF1
*/
if (termios-c_iflag IXON)
- efr |= OMAP_UART_SW_TX;
+ up-efr |= OMAP_UART_SW_TX;
/*
* IXOFF Flag:
@@ -601,7 +599,7 @@ serial_omap_configure_xonxoff
* Receiver compares XON1, XOFF1.
*/
if (termios-c_iflag IXOFF)
- efr |= OMAP_UART_SW_RX;
+ up-efr |= OMAP_UART_SW_RX;
serial_out(up, UART_EFR, up-efr | UART_EFR_ECB);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
@@ -624,7 +622,7 @@ serial_omap_configure_xonxoff
* load the new software flow control mode IXON or IXOFF
* and restore the UARTi.EFR_REG[4] ENHANCED_EN value.
*/
- serial_out(up, UART_EFR, efr | UART_EFR_SCD);
+ serial_out(up, UART_EFR, up-efr | UART_EFR_SCD);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
serial_out(up, UART_MCR, up-mcr ~UART_MCR_TCRTLR);
@@ -671,6 +669,10 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
baud = uart_get_baud_rate(port, termios, old, 0, port-uartclk/13);
quot = serial_omap_get_divisor(port, baud);
+ up-dll = quot 0xff;
+ up-dlh = quot 8;
+ up-mdr1 = UART_OMAP_MDR1_DISABLE;
+
up-fcr = UART_FCR_R_TRIG_01 | UART_FCR_T_TRIG_01 |
UART_FCR_ENABLE_FIFO;
if (up-use_dma)
@@ -723,6 +725,7 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
up-ier |= UART_IER_MSI;
serial_out(up, UART_IER, up-ier);
serial_out(up, UART_LCR, cval); /* reset DLAB */
+ up-lcr = cval;
/* FIFOs and DMA Settings */
@@ -759,7 +762,7 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
/* Protocol, Baud Rate, and Interrupt Settings */
- serial_out(up, UART_OMAP_MDR1, UART_OMAP_MDR1_DISABLE);
+ serial_out(up, UART_OMAP_MDR1, up-mdr1);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
up-efr = serial_in(up, UART_EFR);
@@ -769,8 +772,8 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
serial_out(up, UART_IER, 0);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
- serial_out(up, UART_DLL, quot 0xff); /* LS of divisor */
- serial_out(up, UART_DLM, quot 8);/* MS of divisor */
+ serial_out(up, UART_DLL, up-dll); /* LS of divisor */
+ serial_out(up, UART_DLM, up-dlh); /* MS of divisor */
serial_out(up, UART_LCR, 0);
serial_out(up, UART_IER, up-ier);
@@ -780,9 +783,11 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
serial_out(up, UART_LCR,
[PATCH v4 05/11] OMAP2+: Serial: Add default mux for all uarts.
Add default mux data for all uart's if mux info is not passed from
board file to avoid breaking any board support.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 132 ++
1 files changed, 132 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index e732d6c..2e10357 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -62,6 +62,134 @@ static struct omap_device_pm_latency omap_uart_latency[] = {
},
};
+#ifdef CONFIG_OMAP_MUX
+static struct omap_device_pad default_uart1_pads[] __initdata = {
+ {
+ .name = uart1_cts.uart1_cts,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart1_rts.uart1_rts,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart1_tx.uart1_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart1_rx.uart1_rx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ .idle = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_device_pad default_uart2_pads[] __initdata = {
+ {
+ .name = uart2_cts.uart2_cts,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart2_rts.uart2_rts,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart2_tx.uart2_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart2_rx.uart2_rx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ .idle = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_device_pad default_uart3_pads[] __initdata = {
+ {
+ .name = uart3_cts_rctx.uart3_cts_rctx,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart3_rts_sd.uart3_rts_sd,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart3_tx_irtx.uart3_tx_irtx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart3_rx_irrx.uart3_rx_irrx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+ .idle = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_device_pad default_omap36xx_uart4_pads[] __initdata = {
+ {
+ .name = gpmc_wait2.uart4_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = gpmc_wait3.uart4_rx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE2,
+ .idle = OMAP_PIN_INPUT | OMAP_MUX_MODE2,
+ },
+};
+
+static struct omap_device_pad default_omap4_uart4_pads[] __initdata = {
+ {
+ .name = uart4_tx.uart4_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart4_rx.uart4_rx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+ .idle = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+ },
+};
+#else
+static struct omap_device_pad default_uart1_pads[] __initdata = {};
+static struct omap_device_pad default_uart2_pads[] __initdata = {};
+static struct omap_device_pad default_uart3_pads[] __initdata = {};
+static struct omap_device_pad default_omap36xx_uart4_pads[] __initdata = {};
+static struct omap_device_pad default_omap4_uart4_pads[] __initdata = {};
+#endif
+
+static void omap_serial_fill_default_pads(struct omap_board_data *bdata)
+{
+ switch (bdata-id) {
+ case 0:
+ bdata-pads = default_uart1_pads;
+ bdata-pads_cnt = ARRAY_SIZE(default_uart1_pads);
+ break;
+ case 1:
+ bdata-pads = default_uart2_pads;
+ bdata-pads_cnt = ARRAY_SIZE(default_uart2_pads);
+ break;
+ case 2:
+ bdata-pads = default_uart3_pads;
+ bdata-pads_cnt = ARRAY_SIZE(default_uart3_pads);
+ break;
+ case 3:
+ if (cpu_is_omap44xx()) {
+ bdata-pads = default_omap4_uart4_pads;
+ bdata-pads_cnt =
+ ARRAY_SIZE(default_omap4_uart4_pads);
+ } else {
+ bdata-pads =
[PATCH v4 09/11] OMAP2+: Serial: Use prepare and resume calls to gate uart clocks
Currently we are using uart prepare and resume calls to gate uart clocks
retaining the same method.
More details on reason to retain this design is provided here:
http://www.spinics.net/lists/linux-serial/msg04128.html
Since prepare and resume hooks are moved to driver itself we can just use
a single prepare and resume call. As in driver we traverse on number of uart
instance and handle it accordingly.
In 34xx uart can wakeup using module level PM_WKEN or IO PAD wakeup use
resume_call from prcm irq handler to wakeup uart, based on chk_wakeup_status
from io_pad or PM_WKST.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/pm24xx.c |8 +
arch/arm/mach-omap2/pm34xx.c | 17 +---
arch/arm/plat-omap/include/plat/serial.h |4 +-
drivers/tty/serial/omap-serial.c | 40 ++
4 files changed, 51 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 39f26af..91eacef 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -138,18 +138,14 @@ static void omap2_enter_full_retention(void)
if (!console_trylock())
goto no_sleep;
- omap_uart_prepare_idle(0);
- omap_uart_prepare_idle(1);
- omap_uart_prepare_idle(2);
+ omap_uart_prepare_idle();
/* Jump to SRAM suspend code */
omap2_sram_suspend(sdrc_read_reg(SDRC_DLLA_CTRL),
OMAP_SDRC_REGADDR(SDRC_DLLA_CTRL),
OMAP_SDRC_REGADDR(SDRC_POWER));
- omap_uart_resume_idle(2);
- omap_uart_resume_idle(1);
- omap_uart_resume_idle(0);
+ omap_uart_resume_idle();
if (!is_suspending())
console_unlock();
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 9f3bf2c..26ddd56 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -210,6 +210,7 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
wkst = omap2_prm_read_mod_reg(module, wkst_off);
wkst = omap2_prm_read_mod_reg(module, grpsel_off);
+ c += omap_uart_resume_idle();
if (wkst) {
iclk = omap2_cm_read_mod_reg(module, iclk_off);
fclk = omap2_cm_read_mod_reg(module, fclk_off);
@@ -380,17 +381,19 @@ void omap_sram_idle(void)
}
/* Block console output in case it is on one of the OMAP UARTs */
- if (!is_suspending())
+ if (!is_suspending()) {
if (per_next_state PWRDM_POWER_ON ||
- core_next_state PWRDM_POWER_ON)
+ core_next_state PWRDM_POWER_ON) {
if (!console_trylock())
goto console_still_active;
+ else
+ omap_uart_prepare_idle();
+ }
+ }
/* 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();
@@ -398,8 +401,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();
@@ -446,8 +447,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,
@@ -461,8 +460,6 @@ 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())
diff --git a/arch/arm/plat-omap/include/plat/serial.h
b/arch/arm/plat-omap/include/plat/serial.h
index bfd73b7..5b8c8f2 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -109,8 +109,8 @@ struct omap_board_data;
extern void omap_serial_init(void);
extern void omap_serial_init_port(struct omap_board_data *bdata);
-extern void omap_uart_prepare_idle(int num);
-extern void omap_uart_resume_idle(int num);
+extern void omap_uart_prepare_idle(void);
[PATCH v4 03/11] OMAP2+: UART: cleanup + remove certain uart calls from pm code
In preparation to UART runtime conversion. Remove certain uart specific calls
from pm24xx/34xx files. Remove uart pads from 3430 board file.
These func calls will no more be used with upcoming uart runtime design.
1.) omap_uart_can_sleep :- not needed driver can autosuspend based on
usage_count
and autosuspend delay.
2.) omap_uart_prepare_suspend :- can be taken care with driver.
3.) The pad values in 3430 board file are same as the default pad values to be
updated in serial.c file with uart runtime conversion changes.
Avoid structure duplication and use default pads.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 100 +-
arch/arm/mach-omap2/pm24xx.c |3 -
arch/arm/mach-omap2/pm34xx.c |5 --
arch/arm/plat-omap/include/plat/serial.h |4 -
4 files changed, 1 insertions(+), 111 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index bd600cf..b12b38f 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -482,106 +482,8 @@ static const struct usbhs_omap_board_data usbhs_bdata
__initconst = {
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
-
-static struct omap_device_pad serial1_pads[] __initdata = {
- /*
-* Note that off output enable is an active low
-* signal. So setting this means pin is a
-* input enabled in off mode
-*/
- OMAP_MUX_STATIC(uart1_cts.uart1_cts,
-OMAP_PIN_INPUT |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart1_rts.uart1_rts,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart1_rx.uart1_rx,
-OMAP_PIN_INPUT |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart1_tx.uart1_tx,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
-};
-
-static struct omap_device_pad serial2_pads[] __initdata = {
- OMAP_MUX_STATIC(uart2_cts.uart2_cts,
-OMAP_PIN_INPUT_PULLUP |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart2_rts.uart2_rts,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart2_rx.uart2_rx,
-OMAP_PIN_INPUT |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart2_tx.uart2_tx,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
-};
-
-static struct omap_device_pad serial3_pads[] __initdata = {
- OMAP_MUX_STATIC(uart3_cts_rctx.uart3_cts_rctx,
-OMAP_PIN_INPUT_PULLDOWN |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart3_rts_sd.uart3_rts_sd,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart3_rx_irrx.uart3_rx_irrx,
-OMAP_PIN_INPUT |
-OMAP_PIN_OFF_INPUT_PULLDOWN |
-OMAP_OFFOUT_EN |
-OMAP_MUX_MODE0),
- OMAP_MUX_STATIC(uart3_tx_irtx.uart3_tx_irtx,
-OMAP_PIN_OUTPUT |
-OMAP_OFF_EN |
-OMAP_MUX_MODE0),
-};
-
-static struct omap_board_data serial1_data __initdata = {
- .id = 0,
- .pads = serial1_pads,
- .pads_cnt = ARRAY_SIZE(serial1_pads),
-};
-
-static struct omap_board_data serial2_data __initdata = {
- .id = 1,
- .pads = serial2_pads,
- .pads_cnt = ARRAY_SIZE(serial2_pads),
-};
-
-static struct omap_board_data serial3_data __initdata = {
- .id = 2,
- .pads = serial3_pads,
- .pads_cnt = ARRAY_SIZE(serial3_pads),
-};
-
-static inline void board_serial_init(void)
-{
- omap_serial_init_port(serial1_data);
- omap_serial_init_port(serial2_data);
- omap_serial_init_port(serial3_data);
-}
#else
#define board_mux NULL
-
-static inline void board_serial_init(void)
-{
- omap_serial_init();
-}
#endif
/*
@@ -718,7
[PATCH v4 07/11] Serial: OMAP: Add runtime pm support for omap-serial driver
Adapts omap-serial driver to use pm_runtime API's.
1.) Moving context_restore func to driver from serial.c
2.) Use runtime irq safe to use get_sync from irq context.
3.) autosuspend for port specific activities and put for reg access.
4.) for earlyprintk usage the debug macro will write to console uart
so keep uart clocks active from boot, idle using hwmod API's re-enable back
using runtime API's.
5.) Moving context restore to runtime suspend and using reg values from port
structure to restore the uart port context based on context_loss_count.
Maintain internal state machine for avoiding repeated enable/disable of
uart port wakeup mechanism.
6.) Add API to enable wakeup and check wakeup status.
Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 49 ++
arch/arm/plat-omap/include/plat/omap-serial.h | 10 ++
drivers/tty/serial/omap-serial.c | 211 ++---
3 files changed, 250 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 2e10357..7117220 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -30,6 +30,7 @@
#include plat/common.h
#include plat/board.h
#include plat/omap_device.h
+#include plat/omap-pm.h
#include prm2xxx_3xxx.h
#include pm.h
@@ -246,6 +247,51 @@ static void omap_uart_idle_init(struct omap_uart_port_info
*uart,
}
}
+static bool omap_uart_chk_wakeup(struct platform_device *pdev)
+{
+ struct omap_uart_port_info *up = pdev-dev.platform_data;
+ struct omap_device *od;
+ u32 wkst = 0;
+ bool ret = false;
+
+ if (up-wk_st up-wk_en up-wk_mask) {
+ /* Check for normal UART wakeup (and clear it) */
+ wkst = __raw_readl(up-wk_st) up-wk_mask;
+ if (wkst) {
+ __raw_writel(up-wk_mask, up-wk_st);
+ ret = true;
+ }
+ }
+
+ od = to_omap_device(pdev);
+ if (omap_hwmod_pad_get_wakeup_status(od-hwmods[0]) == true)
+ ret = true;
+
+ return ret;
+}
+
+static void omap_uart_wakeup_enable(struct platform_device *pdev, bool enable)
+{
+ struct omap_device *od;
+ struct omap_uart_port_info *up = pdev-dev.platform_data;
+
+ /* Set or clear wake-enable bit */
+ if (up-wk_en up-wk_mask) {
+ u32 v = __raw_readl(up-wk_en);
+ if (enable)
+ v |= up-wk_mask;
+ else
+ v = ~up-wk_mask;
+ __raw_writel(v, up-wk_en);
+ }
+
+ od = to_omap_device(pdev);
+ if (enable)
+ omap_hwmod_enable_wakeup(od-hwmods[0]);
+ else
+ omap_hwmod_disable_wakeup(od-hwmods[0]);
+}
+
struct omap_hwmod *omap_uart_hwmod_lookup(int num)
{
struct omap_hwmod *oh;
@@ -317,6 +363,9 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata)
pdata-uartclk = OMAP24XX_BASE_BAUD * 16;
pdata-flags = UPF_BOOT_AUTOCONF;
+ pdata-enable_wakeup = omap_uart_wakeup_enable;
+ pdata-chk_wakeup = omap_uart_chk_wakeup;
+ pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
pdev = omap_device_build(name, bdata-id, oh, pdata,
sizeof(*pdata), omap_uart_latency,
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 06e3aa2..7fc63b8 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -67,6 +67,9 @@ struct omap_uart_port_info {
void __iomem *wk_st;
void __iomem *wk_en;
u32 wk_mask;
+ void (*enable_wakeup)(struct platform_device *, bool);
+ bool (*chk_wakeup)(struct platform_device *);
+ u32 (*get_context_loss_count)(struct device *);
};
struct uart_omap_dma {
@@ -118,7 +121,14 @@ struct uart_omap_port {
unsigned char msr_saved_flags;
charname[20];
unsigned long port_activity;
+ u32 context_loss_cnt;
+ u8 wake_status;
+
unsigned interrata;
+ unsigned intclocked;
+ u8 console_locked;
+
+ bool (*chk_wakeup)(struct platform_device *);
};
#endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 6ac0ade..30bdd05 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -37,10 +37,14 @@
#include linux/clk.h
#include linux/serial_core.h
#include linux/irq.h
+#include linux/pm_runtime.h
#include plat/dma.h
#include plat/dmtimer.h
#include plat/omap-serial.h
+#include plat/omap_device.h
+
+#define OMAP_UART_AUTOSUSPEND_DELAY 3000
Re: [PATCH 10/11] ARM: pm: convert some assembly to C
Hi Russell,
On Thu, Sep 01, 2011 at 01:51:39PM +0100, Russell King - ARM Linux wrote:
Convert some of the sleep.S guts to C code, which makes it easier to
use our macros and to add L2 cache handling. We provide a helper
function, __cpu_suspend_save(), which deals with saving the common
state, setting up for resume, and flushing caches.
The remainder left as assembly code is the saving of the CPU general
purpose registers, and allocating space on the stack to save the CPU
specific registers and resume state.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/include/asm/proc-fns.h |8 ++
arch/arm/kernel/sleep.S | 53 --
arch/arm/kernel/suspend.c | 24 +++--
3 files changed, 46 insertions(+), 39 deletions(-)
[...]
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 115736a..c78a88f 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -8,10 +8,29 @@
static pgd_t *suspend_pgd;
-extern int __cpu_suspend(int, long, unsigned long, int (*)(unsigned long));
+extern int __cpu_suspend(unsigned long, int (*)(unsigned long));
extern void cpu_resume_mmu(void);
/*
+ * This is called by __cpu_suspend() to save the state, and do whatever
+ * flushing is required to ensure that when the CPU goes to sleep we have
+ * the necessary data available when the caches are not searched.
+ */
+void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32 *save_ptr)
+{
+ *save_ptr = virt_to_phys(ptr);
+
+ /* This must correspond to the LDM in cpu_resume() assembly */
+ *ptr++ = virt_to_phys(suspend_pgd);
+ *ptr++ = sp;
+ *ptr++ = virt_to_phys(cpu_do_resume);
+
+ cpu_do_suspend(ptr);
+
+ flush_cache_all();
+}
+
+/*
* Hide the first two arguments to __cpu_suspend - these are an
implementation
* detail which platform code shouldn't have to know about.
*/
@@ -29,8 +48,7 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
* resume (indicated by a zero return code), we need to switch
* back to the correct page tables.
*/
- ret = __cpu_suspend(virt_to_phys(suspend_pgd),
- PHYS_OFFSET - PAGE_OFFSET, arg, fn);
+ ret = __cpu_suspend(arg, fn);
if (ret == 0)
cpu_switch_mm(mm-pgd, mm);
It is still early testing, but without a local tlb flush here I am getting
random segmentation faults in user space.
My fear is that 1:1 global TLB entries cause issues if user space processes
happen to map those pages at addresses overlapping 1:1 mapping set-up for
resume and we do not flush the TLB.
With the tlb flush the whole patchset works with nary a blemish, from cpuidle.
Still a question mark so please give me the benefit of the doubt.
Many thanks,
Lorenzo
--
To unsubscribe from this list: send the line unsubscribe 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 v4 04/11] OMAP2+: UART: Remove uart clock handling code from serial.c
Cleanup serial.c file in preparation to addition of runtime API's in omap-serial
file. Remove all clock handling mechanism as this will be taken care with
pm runtime API's in omap-serial.c file itself.
1.) Remove omap-device enable and disable. We can can use get_sync/put_sync
API's
2.) Remove context save/restore can be done with runtime_resume callback for
get_sync call. No need to save context as all reg details available in
uart_port structure can be used for restore, so add missing regs in
uart port struct.
3.) Add func to identify console uart.
4.) Erratum handling informed as flag to driver and func to handle erratum
can be moved to omap-serial driver itself.
Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 742 ++---
arch/arm/plat-omap/include/plat/omap-serial.h | 11 +-
2 files changed, 53 insertions(+), 700 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 3d1c1d3..e732d6c 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -19,25 +19,16 @@
*/
#include linux/kernel.h
#include linux/init.h
-#include linux/serial_reg.h
#include linux/clk.h
#include linux/io.h
#include linux/delay.h
#include linux/platform_device.h
#include linux/slab.h
-#include linux/serial_8250.h
#include linux/pm_runtime.h
-#include linux/console.h
-#ifdef CONFIG_SERIAL_OMAP
#include plat/omap-serial.h
-#endif
-
#include plat/common.h
#include plat/board.h
-#include plat/clock.h
-#include plat/dma.h
-#include plat/omap_hwmod.h
#include plat/omap_device.h
#include prm2xxx_3xxx.h
@@ -47,66 +38,8 @@
#include control.h
#include mux.h
-#define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV0x52
-#define UART_OMAP_WER 0x17/* Wake-up enable register */
-
-#define UART_ERRATA_FIFO_FULL_ABORT(0x1 0)
-#define UART_ERRATA_i202_MDR1_ACCESS (0x1 1)
-
-/*
- * NOTE: By default the serial timeout is disabled as it causes lost characters
- * over the serial ports. This means that the UART clocks will stay on until
- * disabled via sysfs. This also causes that any deeper omap sleep states are
- * blocked.
- */
-#define DEFAULT_TIMEOUT 0
-
#define MAX_UART_HWMOD_NAME_LEN16
-struct omap_uart_state {
- int num;
- int can_sleep;
- struct timer_list timer;
- u32 timeout;
-
- void __iomem *wk_st;
- void __iomem *wk_en;
- u32 wk_mask;
- u32 padconf;
- u32 dma_enabled;
-
- struct clk *ick;
- struct clk *fck;
- int clocked;
-
- int irq;
- int regshift;
- int irqflags;
- void __iomem *membase;
- resource_size_t mapbase;
-
- struct list_head node;
- struct omap_hwmod *oh;
- struct platform_device *pdev;
-
- u32 errata;
-#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
- int context_valid;
-
- /* Registers to be saved/restored for OFF-mode */
- u16 dll;
- u16 dlh;
- u16 ier;
- u16 sysc;
- u16 scr;
- u16 wer;
- u16 mcr;
-#endif
-};
-
-static LIST_HEAD(uart_list);
-static u8 num_uarts;
-
static int uart_idle_hwmod(struct omap_device *od)
{
omap_hwmod_idle(od-hwmods[0]);
@@ -129,396 +62,35 @@ static struct omap_device_pm_latency omap_uart_latency[]
= {
},
};
-static inline unsigned int __serial_read_reg(struct uart_port *up,
-int offset)
-{
- offset = up-regshift;
- return (unsigned int)__raw_readb(up-membase + offset);
-}
-
-static inline unsigned int serial_read_reg(struct omap_uart_state *uart,
- int offset)
-{
- offset = uart-regshift;
- return (unsigned int)__raw_readb(uart-membase + offset);
-}
-
-static inline void __serial_write_reg(struct uart_port *up, int offset,
- int value)
-{
- offset = up-regshift;
- __raw_writeb(value, up-membase + offset);
-}
-
-static inline void serial_write_reg(struct omap_uart_state *uart, int offset,
- int value)
-{
- offset = uart-regshift;
- __raw_writeb(value, uart-membase + offset);
-}
-
-/*
- * Internal UARTs need to be initialized for the 8250 autoconfig to work
- * properly. Note that the TX watermark initialization may not be needed
- * once the 8250.c watermark handling code is merged.
- */
-
-static inline void __init omap_uart_reset(struct omap_uart_state *uart)
-{
- serial_write_reg(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_DISABLE);
- serial_write_reg(uart, UART_OMAP_SCR, 0x08);
- serial_write_reg(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_16X_MODE);
-}
-
-#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3)
-
-/*
- * Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6)
- * The access to uart register after MDR1 Access
- * causes UART to corrupt data.
- *
- * Need a
[PATCH v4 11/11] Serial: OMAP2+: Make the RX_TIMEOUT for DMA configurable for each UART
From: Jon Hunter jon-hun...@ti.com
When using DMA there are two timeouts defined. The first timeout,
rx_timeout, is really a polling rate in which software polls the
DMA status to see if the DMA has finished. This is necessary for
the RX side because we do not know how much data we will receive.
The second timeout, RX_TIMEOUT, is a timeout after which the
DMA will be stopped if no more data is received. To make this
clearer, rename rx_timeout as rx_poll_rate and rename the
function serial_omap_rx_timeout() to serial_omap_rxdma_poll().
The OMAP-Serial driver defines an RX_TIMEOUT of 3 seconds that is
used to indicate when the DMA for UART can be stopped if no more
data is received. The value is a global definition that is applied
to all instances of the UART.
Each UART may be used for a different purpose and so the timeout
required may differ. Make this value configurable for each UART so
that this value can be optimised for power savings.
Acked-by: Kevin Hilman khil...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |5 -
arch/arm/plat-omap/include/plat/omap-serial.h |3 ++-
drivers/tty/serial/omap-serial.c | 15 ---
3 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index dd4d872..942438c 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -41,14 +41,16 @@
#define MAX_UART_HWMOD_NAME_LEN16
-#define DEFAULT_RXDMA_TIMEOUT 1 /* RX DMA polling rate (us) */
+#define DEFAULT_RXDMA_POLLRATE 1 /* RX DMA polling rate (us) */
#define DEFAULT_RXDMA_BUFSIZE 4096/* RX DMA buffer size */
#define DEFAULT_AUTOSUSPEND_DELAY 3000/* Runtime autosuspend (msecs)*/
+#define DEFAULT_RXDMA_TIMEOUT (3 * HZ)/* RX DMA timeout (jiffies) */
static struct omap_uart_port_info omap_serial_default_info[] = {
{
.dma_enabled= 0,
.dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE,
+ .dma_rx_poll_rate = DEFAULT_RXDMA_POLLRATE,
.dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT,
.auto_sus_timeout = DEFAULT_AUTOSUSPEND_DELAY,
},
@@ -386,6 +388,7 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
pdata-dma_enabled = info-dma_enabled;
pdata-dma_rx_buf_size = info-dma_rx_buf_size;
+ pdata-dma_rx_poll_rate = info-dma_rx_poll_rate;
pdata-dma_rx_timeout = info-dma_rx_timeout;
pdata-auto_sus_timeout = info-auto_sus_timeout;
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 211cb0a..0d4423d 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -51,7 +51,6 @@
#define OMAP_UART_DMA_CH_FREE -1
-#define RX_TIMEOUT (3 * HZ)
#define OMAP_MAX_HSUART_PORTS 4
#define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA
@@ -65,6 +64,7 @@ struct omap_uart_port_info {
unsigned interrata;
unsigned intdma_rx_buf_size;/* DMA Rx Buffer Size */
unsigned intdma_rx_timeout; /* DMA RX timeout */
+ unsigned intdma_rx_poll_rate; /* DMA RX timeout */
unsigned intauto_sus_timeout; /* Auto_suspend timeout */
void __iomem *wk_st;
@@ -97,6 +97,7 @@ struct uart_omap_dma {
/* timer to poll activity on rx dma */
struct timer_list rx_timer;
unsigned intrx_buf_size;
+ unsigned intrx_poll_rate;
unsigned intrx_timeout;
};
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 7e13036..cd79733 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -48,7 +48,7 @@ static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
static void uart_tx_dma_callback(int lch, u16 ch_status, void *data);
-static void serial_omap_rx_timeout(unsigned long uart_no);
+static void serial_omap_rxdma_poll(unsigned long uart_no);
static int serial_omap_start_rxdma(struct uart_omap_port *up);
static void omap_uart_mdr1_errataset(struct uart_omap_port *up, u8 mdr1);
@@ -582,7 +582,7 @@ static int serial_omap_startup(struct uart_port *port)
(dma_addr_t *)(up-uart_dma.tx_buf_dma_phys),
0);
init_timer((up-uart_dma.rx_timer));
- up-uart_dma.rx_timer.function = serial_omap_rx_timeout;
+ up-uart_dma.rx_timer.function = serial_omap_rxdma_poll;
up-uart_dma.rx_timer.data = up-pdev-id;
/* Currently the buffer size is 4KB. Can increase it
[PATCH v4 00/11] OMAP2+: Serial: Runtime adaptation + cleanup
Converting uart driver to adapt to pm runtime API's. Code re-org + cleanup. Moving some functionality from serial.c to omap-serial.c Changes involves: 1.) Cleaning up certain uart calls from sram_idle func. 2.) Removed all types of uart clock handling code from serial.c 3.) Using hwmod_mux API enable wakeup capability for uart pad during hwmod_idle state i.e., when uart clocks are disabled we can enable io-pad wakeup capability for uart if mux_data is available for given uart. Also during during resume from idle call to uart we need to enable clocks back conditionally and this can be done only when io-pad wakeup event bit is set for uart_rx pad. So we need a hwmod API which can probe the uart pad and let us know whether a uart wakeup happened. So omap_hmwod_pad_wakeup_status API is added to meet this requirement. 3.) Adapted omap-serial driver to use runtime API's. 4.) Modify serial_init calls to accept certain uart parameters from board file. 5.) using prepare and resume_call to disable/enable uart_port. Reference to discussion why we need to use prepare and resume hooks. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg52707.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53209.html Patch series is based on 3.1.0-rc4 + omap_device fixes. From Kevin's tree. git://gitorious.org/khilman/linux-omap-pm.git for_3.2/omap_device This Patch series based on Kevin's tree is hosted at: git://gitorious.org/runtime_3-0/runtime_3-0.git rc4_uart_od Testing updates: 3430SDP: retention, off_mode, system_wide suspend is tested. (earlyprintk no_console_suspend checked) OMAP3630 - Zoom3: pm-retention checked with quart/omap-uart3 [Also tested with uart3 as console uart and pm-ret checked] OMAP4430-SDP: Boot tested. OMAP2420/2430SDP: Boot tested. Govindraj.R (10): OMAP2+: hwmod: Add API to enable IO ring wakeup. OMAP2+: hwmod: Add API to check IO PAD wakeup status OMAP2+: UART: cleanup + remove certain uart calls from pm code OMAP2+: UART: Remove uart clock handling code from serial.c OMAP2+: Serial: Add default mux for all uarts. Serial: OMAP: Store certain reg values to port structure Serial: OMAP: Add runtime pm support for omap-serial driver Serial: OMAP2+: Move erratum handling from serial.c OMAP2+: Serial: Use prepare and resume calls to gate uart clocks OMAP: Serial: Allow UART parameters to be configured from board file. Jon Hunter (1): Serial: OMAP2+: Make the RX_TIMEOUT for DMA configurable for each UART arch/arm/mach-omap2/board-3430sdp.c | 100 +--- arch/arm/mach-omap2/board-4430sdp.c |8 +- arch/arm/mach-omap2/board-n8x0.c |6 +- arch/arm/mach-omap2/board-omap4panda.c|8 +- arch/arm/mach-omap2/mux.c | 30 + arch/arm/mach-omap2/mux.h | 13 + arch/arm/mach-omap2/omap_hwmod.c | 66 ++ arch/arm/mach-omap2/pm24xx.c | 11 +- arch/arm/mach-omap2/pm34xx.c | 22 +- arch/arm/mach-omap2/serial.c | 922 +++-- arch/arm/plat-omap/include/plat/omap-serial.h | 34 +- arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + arch/arm/plat-omap/include/plat/serial.h | 13 +- drivers/tty/serial/omap-serial.c | 349 -- 14 files changed, 717 insertions(+), 866 deletions(-) -- 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 03/11] ARM: pm: some ARMv7 requires a dsb in resume to ensure correctness
On Wed, Sep 07, 2011 at 04:41:32PM +0100, Catalin Marinas wrote: On 1 September 2011 13:49, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Add a dsb after the isb to ensure that the previous writes to the CP15 registers take effect before we enable the MMU. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mm/proc-v7.S | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index dec72ee..a773f4e 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -255,6 +255,7 @@ ENTRY(cpu_v7_do_resume) mcr p15, 0, r4, c10, c2, 0 @ write PRRR mcr p15, 0, r5, c10, c2, 1 @ write NMRR isb + dsb Isn't an ISB enough here? We usually have the DSB for some background operations like cache maintenance. That depends whether you're including the effects of the cache maintanence instructions in this. The ARM ARM tells me that a DSB is required to ensure that all cache maintanence is issued before the dsb is complete at the point that the dsb is executed. So for architectural compliance, yes, a dsb is required. The isb is also required to ensure that instruction cache maintanence is properly visible. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[v2 2/2] usb: musb: omap2+: save and restore OTG_INTERFSEL
From: Hema HK hem...@ti.com
we need to save and restore OTG_INTERFSEL register
else we will be unable to function on resume after
OFF mode.
Reported-by: Devaraj Rangasamy d...@ti.com
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
drivers/usb/musb/musb_core.h |1 +
drivers/usb/musb/omap2430.c |6 ++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index b3c065a..3259a6b 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -311,6 +311,7 @@ struct musb_context_registers {
u8 index, testmode;
u8 devctl, busctl, misc;
+ u32 otg_interfsel;
struct musb_csr_regs index_regs[MUSB_C_NUM_EPS];
};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index ba85f27..78eb13a 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -491,6 +491,9 @@ static int omap2430_runtime_suspend(struct device *dev)
struct omap2430_glue*glue = dev_get_drvdata(dev);
struct musb *musb = glue_to_musb(glue);
+ musb-context.otg_interfsel = musb_readl(musb-mregs,
+ OTG_INTERFSEL);
+
omap2430_low_level_exit(musb);
otg_set_suspend(musb-xceiv, 1);
@@ -503,6 +506,9 @@ static int omap2430_runtime_resume(struct device *dev)
struct musb *musb = glue_to_musb(glue);
omap2430_low_level_init(musb);
+ musb_writel(musb-mregs, OTG_INTERFSEL,
+ musb-context.otg_interfsel);
+
otg_set_suspend(musb-xceiv, 0);
return 0;
--
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
[v2 1/2] usb: musb: omap2+: fix context api's
From: Vikram Pandita vikram.pand...@ti.com RxFifoSz, TxFifoSz, RxFifoAddr, TxFifoAddr are all indexed registers. So before doing a context save or restore, INDEX register should be set, then only one gets to the right register offset. Signed-off-by: Vikram Pandita vikram.pand...@ti.com Signed-off-by: Anand Gadiyar gadi...@ti.com --- drivers/usb/musb/musb_core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 20a2873..6328aaf 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2159,6 +2159,7 @@ static void musb_save_context(struct musb *musb) if (!epio) continue; + musb_writeb(musb_base, MUSB_INDEX, i); musb-context.index_regs[i].txmaxp = musb_readw(epio, MUSB_TXMAXP); musb-context.index_regs[i].txcsr = @@ -2234,6 +2235,7 @@ static void musb_restore_context(struct musb *musb) if (!epio) continue; + musb_writeb(musb_base, MUSB_INDEX, i); musb_writew(epio, MUSB_TXMAXP, musb-context.index_regs[i].txmaxp); musb_writew(epio, MUSB_TXCSR, -- 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
[v2 0/2] usb: musb: off mode fixes
From: Vikram Pandita vikram.pand...@ti.com v1: Recent tests with OFF mode on OMAP44xx brings out these bugs v2: Fix review comments from: Sergei Shtylyov sshtyl...@mvista.com Hema HK (1): usb: musb: omap2+: save and restore OTG_INTERFSEL Vikram Pandita (1): usb: musb: omap2+: fix context api's drivers/usb/musb/musb_core.c |2 ++ drivers/usb/musb/musb_core.h |1 + drivers/usb/musb/omap2430.c |6 ++ 3 files changed, 9 insertions(+), 0 deletions(-) -- 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 09/22] OMAP2: add voltage domains and connect to powerdomains
Kevin, On Mon, Aug 29, 2011 at 7:35 PM, Kevin Hilman khil...@ti.com wrote: Create basic voltagedomains for OMAP2 and associate OMAP2 powerdomains with the newly created voltage domains. Signed-off-by: Kevin Hilman khil...@ti.com --- arch/arm/mach-omap2/Makefile | 3 +- arch/arm/mach-omap2/io.c | 2 + arch/arm/mach-omap2/powerdomains2xxx_data.c | 4 +++ arch/arm/mach-omap2/voltage.h | 1 + arch/arm/mach-omap2/voltagedomains2xxx_data.c | 32 + 5 files changed, 41 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/voltagedomains2xxx_data.c ... diff --git a/arch/arm/mach-omap2/voltagedomains2xxx_data.c b/arch/arm/mach-omap2/voltagedomains2xxx_data.c new file mode 100644 index 000..69ff261 --- /dev/null +++ b/arch/arm/mach-omap2/voltagedomains2xxx_data.c @@ -0,0 +1,32 @@ +/* + * OMAP3 voltage domain data + * + * Copyright (C) 2007, 2010 Texas Instruments, Inc. 2011? Regards, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/11] ARM: pm: some ARMv7 requires a dsb in resume to ensure correctness
On 7 September 2011 17:19, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Sep 07, 2011 at 04:41:32PM +0100, Catalin Marinas wrote: On 1 September 2011 13:49, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Add a dsb after the isb to ensure that the previous writes to the CP15 registers take effect before we enable the MMU. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mm/proc-v7.S | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index dec72ee..a773f4e 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -255,6 +255,7 @@ ENTRY(cpu_v7_do_resume) mcr p15, 0, r4, c10, c2, 0 @ write PRRR mcr p15, 0, r5, c10, c2, 1 @ write NMRR isb + dsb Isn't an ISB enough here? We usually have the DSB for some background operations like cache maintenance. That depends whether you're including the effects of the cache maintanence instructions in this. The ARM ARM tells me that a DSB is required to ensure that all cache maintanence is issued before the dsb is complete at the point that the dsb is executed. So for architectural compliance, yes, a dsb is required. The isb is also required to ensure that instruction cache maintanence is properly visible. That's correct, I got the wrong impression that there was a DSB earlier in the code after he TLB and cache maintenance, but that's not the case, so a DSB here is needed. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 01/11] OMAP2+: hwmod: Add API to enable IO ring wakeup.
Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux initialization.
Use the wakeup_enable flag and enable wakeup capability
for the given pads. Wakeup capability will be enabled/disabled
during hwmod idle transition based on whether wakeup_flag is
set or cleared.
Map the enable/disable pad wakeup API's to hwmod_wakeup_enable/disable.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 59 ++
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 84cc0bd..e751dd9 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2062,6 +2062,34 @@ static int __init omap_hwmod_setup_all(void)
core_initcall(omap_hwmod_setup_all);
/**
+ * omap_hwmod_set_ioring_wakeup - enable io pad wakeup flag.
+ * @oh: struct omap_hwmod *
+ * @set: bool value indicating to set or clear wakeup status.
+ *
+ * Set or Clear wakeup flag for the io_pad.
+ */
+static int omap_hwmod_set_ioring_wakeup(struct omap_hwmod *oh, bool set_wake)
+{
+ struct omap_device_pad *pad;
+ int ret = -EINVAL, j;
+
+ if (oh-mux oh-mux-enabled) {
+ for (j = 0; j oh-mux-nr_pads_dynamic; j++) {
+ pad = oh-mux-pads_dynamic[j];
+ if (pad-flags OMAP_DEVICE_PAD_WAKEUP) {
+ if (set_wake)
+ pad-idle |= OMAP_WAKEUP_EN;
+ else
+ pad-idle = ~OMAP_WAKEUP_EN;
+ ret = 0;
+ }
+ }
+ }
+
+ return ret;
+}
+
+/**
* omap_hwmod_enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -2393,6 +2421,35 @@ int omap_hwmod_del_initiator_dep(struct omap_hwmod *oh,
{
return _del_initiator_dep(oh, init_oh);
}
+/**
+ * omap_hwmod_enable_ioring_wakeup - Set wakeup flag for iopad.
+ * @oh: struct omap_hwmod *
+ *
+ * Traverse through dynamic pads, if pad is enabled then
+ * set wakeup enable bit flag for the mux pin. Wakeup pad bit
+ * will be set during hwmod idle transistion.
+ * Return error if pads are not enabled or not available.
+ */
+int omap_hwmod_enable_ioring_wakeup(struct omap_hwmod *oh)
+{
+ /* Enable pad wake-up capability */
+ return omap_hwmod_set_ioring_wakeup(oh, true);
+}
+
+/**
+ * omap_hwmod_disable_ioring_wakeup - Clear wakeup flag for iopad.
+ * @oh: struct omap_hwmod *
+ *
+ * Traverse through dynamic pads, if pad is enabled then
+ * clear wakeup enable bit flag for the mux pin. Wakeup pad bit
+ * will be set during hwmod idle transistion.
+ * Return error if pads are not enabled or not available.
+ */
+int omap_hwmod_disable_ioring_wakeup(struct omap_hwmod *oh)
+{
+ /* Disable pad wakeup capability */
+ return omap_hwmod_set_ioring_wakeup(oh, false);
+}
/**
* omap_hwmod_enable_wakeup - allow device to wake up the system
@@ -2419,6 +2476,7 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
v = oh-_sysc_cache;
_enable_wakeup(oh, v);
_write_sysconfig(v, oh);
+ omap_hwmod_enable_ioring_wakeup(oh);
spin_unlock_irqrestore(oh-_lock, flags);
return 0;
@@ -2449,6 +2507,7 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
v = oh-_sysc_cache;
_disable_wakeup(oh, v);
_write_sysconfig(v, oh);
+ omap_hwmod_disable_ioring_wakeup(oh);
spin_unlock_irqrestore(oh-_lock, flags);
return 0;
--
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 1/2] omap3: ISP: Fix the failure of CCDC capture during suspend/resume
Hi, On Wednesday 07 September 2011 12:10:23 Koyamangalath, Abhilash wrote: On Tue, Aug 30, 2011 Laurent Pinchart wrote: On Wednesday 10 August 2011 16:03:12 Deepthy Ravi wrote: From: Abhilash K V abhilash...@ti.com While resuming from the suspended to memory state, occasionally CCDC fails to get enabled and thus fails to capture frames any more till the next suspend/resume is issued. This is a race condition which happens only when a CCDC frame-completion ISR is pending even as ISP device's isp_pm_prepare() is getting called and only one buffer is left on the DMA queue. The DMA queue buffers are thus depleted which results in its underrun.So when ISP resumes there are no buffers on the queue (as the application which can issue buffers is yet to resume) to start video capture. This fix addresses this issue by dequeuing and enqueing the last buffer in isp_pm_prepare() after its DMA gets completed. Thus,when ISP resumes it always finds atleast one buffer on the DMA queue - this is true if application uses only 3 buffers. How is that problem specific to the CCDC ? Can't it be reproduce at the preview engine or resizer output as well ? Yes, I believe this issue would crop with preview and resizer too though I have not been able to try these out. That's my belief as well. In that case the fix should be generic, not CCDC- specific. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe 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/2] usb: musb: omap2+: save and restore OTG_INTERFSEL
Hello.
On 07-09-2011 4:49, Vikram Pandita wrote:
From: Hema HK hem...@ti.com
we need to save and restore OTG_INTERFSEL register
else we will be unable to function on resume after
OFF mode.
Change-Id: I6c29c69596d5f47e00cf74ab0e32bb44ef71dda9
Remove this, please.
Reported-by: Devaraj Rangasamyd...@ti.com
Signed-off-by: Hema HKhem...@ti.com
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
---
drivers/usb/musb/musb_core.h |1 +
drivers/usb/musb/omap2430.c |6 ++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index b3c065a..3259a6b 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -311,6 +311,7 @@ struct musb_context_registers {
u8 index, testmode;
u8 devctl, busctl, misc;
+ u32 otg_interfsel;
Shouldn't this be encosed in #ifdef?
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe 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 6/7] iommu/core: add fault reporting
On Mon, Sep 5, 2011 at 1:00 PM, Roedel, Joerg joerg.roe...@amd.com wrote: Please add a seperate function for setting the fault-handler. It is optional, so no need to be a value of the alloc-function. Will do. Can you elaborate a bit on what the user of the api will do different between IOMMU_TLBMISS and IOMMU_NOPTE? My feeling is that those differences should be handled internally in the IOMMU driver, but probably I miss a use-case. I actually agree. Moreover, since we're not planning on implementing this (dynamic PTE/TLB loading is supported by the hardware, but we're not really using it ATM), and I don't see any other user doing so at this point, I'll just remove those two fault types altogether. Also, we need some flags to distinguish between the type of the fault (read, write, ...). I'll add it (though it won't be used by OMAP since the hardware doesn't tell us this info). Thanks! Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] omap3: ISP: Fix the failure of CCDC capture during suspend/resume
On Tue, Aug 30, 2011 Laurent Pinchart wrote: Hi, On Wednesday 10 August 2011 16:03:12 Deepthy Ravi wrote: From: Abhilash K V abhilash...@ti.com While resuming from the suspended to memory state, occasionally CCDC fails to get enabled and thus fails to capture frames any more till the next suspend/resume is issued. This is a race condition which happens only when a CCDC frame-completion ISR is pending even as ISP device's isp_pm_prepare() is getting called and only one buffer is left on the DMA queue. The DMA queue buffers are thus depleted which results in its underrun.So when ISP resumes there are no buffers on the queue (as the application which can issue buffers is yet to resume) to start video capture. This fix addresses this issue by dequeuing and enqueing the last buffer in isp_pm_prepare() after its DMA gets completed. Thus,when ISP resumes it always finds atleast one buffer on the DMA queue - this is true if application uses only 3 buffers. How is that problem specific to the CCDC ? Can't it be reproduce at the preview engine or resizer output as well ? [Abhilash K V]Yes, I believe this issue would crop with preview and resizer too though I have not been able to try these out. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe 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 03/11] ARM: pm: some ARMv7 requires a dsb in resume to ensure correctness
On 7 September 2011 17:19, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Sep 07, 2011 at 04:41:32PM +0100, Catalin Marinas wrote: On 1 September 2011 13:49, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Add a dsb after the isb to ensure that the previous writes to the CP15 registers take effect before we enable the MMU. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mm/proc-v7.S | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index dec72ee..a773f4e 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -255,6 +255,7 @@ ENTRY(cpu_v7_do_resume) mcr p15, 0, r4, c10, c2, 0 @ write PRRR mcr p15, 0, r5, c10, c2, 1 @ write NMRR isb + dsb Isn't an ISB enough here? We usually have the DSB for some background operations like cache maintenance. That depends whether you're including the effects of the cache maintanence instructions in this. The ARM ARM tells me that a DSB is required to ensure that all cache maintanence is issued before the dsb is complete at the point that the dsb is executed. Another minor point, in general we would use the DSB before the ISB (but that's when the I-cache is enabled). -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6 v2] ti816evm: Add support for musb interface
From: Ravi Babu ravib...@ti.com
Adding musb support in ti816 EVM board file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
---
arch/arm/mach-omap2/board-ti8168evm.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
b/arch/arm/mach-omap2/board-ti8168evm.c
index e516a04..5a4a6c8 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -23,6 +23,14 @@
#include plat/irqs.h
#include plat/board.h
#include plat/common.h
+#include plat/usb.h
+
+static struct omap_musb_board_data musb_board_data = {
+ .set_phy_power = ti81xx_musb_phy_power,
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
+ .power = 500,
+};
static struct omap_board_config_kernel ti8168_evm_config[] __initdata = {
};
@@ -38,6 +46,7 @@ static void __init ti8168_evm_init(void)
omap_serial_init();
omap_board_config = ti8168_evm_config;
omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
+ usb_musb_init(musb_board_data);
}
static void __init ti8168_evm_map_io(void)
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6 v2] omap: musb: ti81xx: Add phy power function
Adding ti81xx_musb_phy_power() which will be used by musb driver through
its function pointer in board_data.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 24 +++
arch/arm/plat-omap/include/plat/usb.h | 32 +++
2 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 58775e3..352b6af 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -260,3 +260,27 @@ void am35x_set_mode(u8 musb_mode)
omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
}
+
+void ti81xx_musb_phy_power(u8 on)
+{
+ u32 usbphycfg = omap_ctrl_readl(USBCTRL0);
+
+ if (on) {
+ if (cpu_is_ti816x()) {
+ usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
+ usbphycfg = ~TI816X_USBPHY_REFCLK_OSC;
+ } else if (cpu_is_ti814x()) {
+ usbphycfg = ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN
+ | USBPHY_DPINPUT | USBPHY_DMINPUT);
+ usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN
+ | USBPHY_DPOPBUFCTL | USBPHY_DPOPBUFCTL);
+ }
+ } else {
+ if (cpu_is_ti816x())
+ usbphycfg = ~TI816X_USBPHY0_NORMAL_MODE;
+ else if (cpu_is_ti814x())
+ usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
+
+ }
+ omap_ctrl_writel(usbphycfg, USBCTRL0);
+}
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 17d3c93..c616385 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -114,6 +114,7 @@ extern void am35x_musb_reset(void);
extern void am35x_musb_phy_power(u8 on);
extern void am35x_musb_clear_irq(void);
extern void am35x_set_mode(u8 musb_mode);
+extern void ti81xx_musb_phy_power(u8 on);
/*
* FIXME correct answer depends on hmc_mode,
@@ -273,6 +274,37 @@ static inline void omap2_usbfs_init(struct omap_usb_config
*pdata)
#define CONF2_OTGPWRDN (1 2)
#define CONF2_DATPOL (1 1)
+/* TI81XX specific definitions */
+#define USBCTRL0 0x620
+#define USBSTAT0 0x624
+
+/* TI816X PHY controls bits */
+#define TI816X_USBPHY0_NORMAL_MODE (1 0)
+#define TI816X_USBPHY_REFCLK_OSC (1 8)
+
+/* TI814X PHY controls bits */
+#define USBPHY_CM_PWRDN(1 0)
+#define USBPHY_OTG_PWRDN (1 1)
+#define USBPHY_CHGDET_DIS (1 2)
+#define USBPHY_CHGDET_RSTRT(1 3)
+#define USBPHY_SRCONDM (1 4)
+#define USBPHY_SINKONDP(1 5)
+#define USBPHY_CHGISINK_EN (1 6)
+#define USBPHY_CHGVSRC_EN (1 7)
+#define USBPHY_DMPULLUP(1 8)
+#define USBPHY_DPPULLUP(1 9)
+#define USBPHY_CDET_EXTCTL (1 10)
+#define USBPHY_GPIO_MODE (1 12)
+#define USBPHY_DPOPBUFCTL (1 13)
+#define USBPHY_DMOPBUFCTL (1 14)
+#define USBPHY_DPINPUT (1 15)
+#define USBPHY_DMINPUT (1 16)
+#define USBPHY_DPGPIO_PD (1 17)
+#define USBPHY_DMGPIO_PD (1 18)
+#define USBPHY_OTGVDET_EN (1 19)
+#define USBPHY_OTGSESSEND_EN (1 20)
+#define USBPHY_DATA_POLARITY (1 23)
+
#if defined(CONFIG_ARCH_OMAP1) defined(CONFIG_USB)
u32 omap1_usb0_init(unsigned nwires, unsigned is_device);
u32 omap1_usb1_init(unsigned nwires);
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6 v2] usb: musb: Adding support for ti81xx
This patch set adds support for musb interface for TI81XX platforms and are dependent on recent patch series from Hemant Pedanekar at [1] and [2]. TI81XX platform has dual musb instances, uses CPPI4.1 DMA and has built in usb PHY. The current set of patches supports only the first interface and in PIO mode. [1] http://marc.info/?l=linux-omapm=131247989220300w=2 [2] http://marc.info/?l=linux-omapm=131411961308438w=2 Changes from v1: - cleaned up #ifdefs of CONFIG_USB_MUSB_HDRC_HCD and CONFIG_USB_GADGET_MUSB_HDRC - Fixed the full name of author - Renamed ti81xx.c to musb_dsps.c - Used platform_device_id table - created dsps_glue_wrapper structure and used the same Ajay Kumar Gupta (1): omap: musb: ti81xx: Add phy power function Ravi Babu (5): omap: musb: Adding hwmod data for ti81xx omap: musb: Adding support for ti81xx ti816evm: Add support for musb interface ti814evm: Add support for musb interface usb: musb: Add support for ti81xx platform arch/arm/mach-omap2/board-ti8148evm.c |9 + arch/arm/mach-omap2/board-ti8168evm.c |9 + arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 74 +++ arch/arm/mach-omap2/omap_phy_internal.c| 24 + arch/arm/mach-omap2/usb-musb.c |3 + arch/arm/plat-omap/include/plat/usb.h | 32 ++ drivers/usb/musb/Kconfig |6 + drivers/usb/musb/Makefile |1 + drivers/usb/musb/musb_core.c |4 +- drivers/usb/musb/musb_dsps.c | 684 10 files changed, 845 insertions(+), 1 deletions(-) create mode 100644 drivers/usb/musb/musb_dsps.c -- To unsubscribe from this list: send the line unsubscribe 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 5/6 v2] ti814evm: Add support for musb interface
From: Ravi Babu ravib...@ti.com
Adding musb support in ti814 EVM board file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
---
arch/arm/mach-omap2/board-ti8148evm.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8148evm.c
b/arch/arm/mach-omap2/board-ti8148evm.c
index 588d6b7..7dbf115 100644
--- a/arch/arm/mach-omap2/board-ti8148evm.c
+++ b/arch/arm/mach-omap2/board-ti8148evm.c
@@ -23,6 +23,14 @@
#include plat/irqs.h
#include plat/board.h
#include plat/common.h
+#include plat/usb.h
+
+static struct omap_musb_board_data musb_board_data = {
+ .set_phy_power = ti81xx_musb_phy_power,
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
+ .power = 500,
+};
static struct omap_board_config_kernel ti8148_evm_config[] __initdata = {
};
@@ -38,6 +46,7 @@ static void __init ti8148_evm_init(void)
omap_serial_init();
omap_board_config = ti8148_evm_config;
omap_board_config_size = ARRAY_SIZE(ti8148_evm_config);
+ usb_musb_init(musb_board_data);
}
static void __init ti8148_evm_map_io(void)
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6 v2] usb: musb: Add support for ti81xx platform
From: Ravi Babu ravib...@ti.com TI81XX platform has two musb interfaces and uses CPPI4.1 DMA engine. It has builtin USB PHYs as AM35x. The current set of patches adds support for one instance and only in PIO mode. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Ravi Babu ravib...@ti.com --- drivers/usb/musb/Kconfig |6 + drivers/usb/musb/Makefile|1 + drivers/usb/musb/musb_core.c |4 +- drivers/usb/musb/musb_dsps.c | 684 ++ 4 files changed, 694 insertions(+), 1 deletions(-) create mode 100644 drivers/usb/musb/musb_dsps.c diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 6192b45..444d106 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,6 +11,7 @@ config USB_MUSB_HDRC depends on USB USB_GADGET depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) + select NOP_USB_XCEIV if SOC_OMAPTI81XX select TWL4030_USB if MACH_OMAP_3430SDP select TWL6030_USB if MACH_OMAP_4430SDP || MACH_OMAP4_PANDA select USB_OTG_UTILS @@ -57,6 +58,10 @@ config USB_MUSB_AM35X tristate AM35x depends on ARCH_OMAP +config USB_MUSB_DSPS + tristate TI DSPS platforms + depends on SOC_OMAPTI81XX + config USB_MUSB_BLACKFIN tristate Blackfin depends on (BF54x !BF544) || (BF52x ! BF522 !BF523) @@ -71,6 +76,7 @@ config MUSB_PIO_ONLY bool 'Disable DMA (always use PIO)' depends on USB_MUSB_HDRC default USB_MUSB_TUSB6010 || USB_MUSB_DA8XX || USB_MUSB_AM35X + default SOC_OMAPTI81XX help All data is copied between memory and FIFO by the CPU. DMA controllers are ignored. diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile index d8fd9d0..d92d110 100644 --- a/drivers/usb/musb/Makefile +++ b/drivers/usb/musb/Makefile @@ -13,6 +13,7 @@ musb_hdrc-$(CONFIG_DEBUG_FS) += musb_debugfs.o # Hardware Glue Layer obj-$(CONFIG_USB_MUSB_OMAP2PLUS) += omap2430.o obj-$(CONFIG_USB_MUSB_AM35X) += am35x.o +obj-$(CONFIG_USB_MUSB_DSPS)+= musb_dsps.o obj-$(CONFIG_USB_MUSB_TUSB6010)+= tusb6010.o obj-$(CONFIG_USB_MUSB_DAVINCI) += davinci.o obj-$(CONFIG_USB_MUSB_DA8XX) += da8xx.o diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 20a2873..b04790d 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -1014,7 +1014,9 @@ static void musb_shutdown(struct platform_device *pdev) || defined(CONFIG_USB_MUSB_OMAP2PLUS) \ || defined(CONFIG_USB_MUSB_OMAP2PLUS_MODULE)\ || defined(CONFIG_USB_MUSB_AM35X) \ - || defined(CONFIG_USB_MUSB_AM35X_MODULE) + || defined(CONFIG_USB_MUSB_AM35X_MODULE)\ + || defined(CONFIG_USB_MUSB_DSPS)\ + || defined(CONFIG_USB_MUSB_DSPS_MODULE) static ushort __initdata fifo_mode = 4; #elif defined(CONFIG_USB_MUSB_UX500) \ || defined(CONFIG_USB_MUSB_UX500_MODULE) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c new file mode 100644 index 000..6a3fa52 --- /dev/null +++ b/drivers/usb/musb/musb_dsps.c @@ -0,0 +1,684 @@ +/* + * Texas Instruments DSPS platforms glue layer + * + * Copyright (C) 2011, by Texas Instruments + * + * Based on the am35x glue layer code. + * + * This file is part of the Inventra Controller Driver for Linux. + * + * The Inventra Controller Driver for Linux 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. + * + * The Inventra Controller Driver for Linux is distributed in + * the hope that it will be useful, but WITHOUT ANY WARRANTY; + * without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public + * License for more details. + * + * You should have received a copy of the GNU General Public License + * along with The Inventra Controller Driver for Linux ; if not, + * write to the Free Software Foundation, Inc., 59 Temple Place, + * Suite 330, Boston, MA 02111-1307 USA + * + * musb_dsps.c will be a common file for all the TI DSPS platforms + * such as dm64x, dm36x, dm35x, da8x, am35x and ti81x. + * For now only ti81x is using this and in future davinci.c, am35x.c + * da8xx.c would be merged to this file after testing. + */ + +#include linux/init.h +#include linux/io.h +#include linux/platform_device.h +#include linux/dma-mapping.h +#include linux/pm_runtime.h + +#include plat/usb.h + +#include musb_core.h + +/** + * avoid using musb_readx()/musb_writex() as glue layer should not be + * dependent on musb core layer symbols. + */ +static inline u8
[PATCH 1/6 v2] omap: musb: Adding hwmod data for ti81xx
From: Ravi Babu ravib...@ti.com
The usb subsystem (usbss) in ti81xx has two musb interfaces. There are three
irqs and three address spaces for usbss, musb0 and musb1 respectively. Created
one hwmod with three irq and memory resources.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 74
1 files changed, 74 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index e73a4c6..e960d70 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -194,6 +194,7 @@ static struct omap_hwmod ti81xx_timer4_hwmod;
static struct omap_hwmod ti81xx_timer5_hwmod;
static struct omap_hwmod ti81xx_timer6_hwmod;
static struct omap_hwmod ti81xx_timer7_hwmod;
+static struct omap_hwmod ti81xx_usbss_hwmod;
/* L4 SLOW - TIMER1 interface */
static struct omap_hwmod_addr_space ti81xx_timer1_addr_space[] = {
@@ -650,6 +651,78 @@ static struct omap_hwmod ti81xx_timer7_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_TI816X | CHIP_IS_TI814X)
};
+/* L3 SLOW - USBSS interface */
+static struct omap_hwmod_addr_space ti81xx_usbss_addr_space[] = {
+ {
+ .name = usbss,
+ .pa_start = 0x4740,
+ .pa_end = 0x4740 + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = musb0,
+ .pa_start = 0x47401000,
+ .pa_end = 0x47401000 + SZ_2K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = musb1,
+ .pa_start = 0x47401800,
+ .pa_end = 0x47401800 + SZ_2K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ },
+};
+
+static struct omap_hwmod_class_sysconfig ti81xx_usbhsotg_sysc = {
+ .rev_offs = 0x0,
+ .sysc_offs = 0x10,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class ti81xx_usbotg_class = {
+ .name = usbotg,
+ .sysc = ti81xx_usbhsotg_sysc,
+};
+
+static struct omap_hwmod_irq_info ti81xx_usbss_mpu_irqs[] = {
+ { .name = usbss-irq, .irq = 17, },
+ { .name = musb0-irq, .irq = 18, },
+ { .name = musb1-irq, .irq = 19, },
+ { .irq = -1, },
+};
+
+static struct omap_hwmod_ocp_if ti81xx_l3_slow__usbss = {
+ .master = ti81xx_l3_slow_hwmod,
+ .slave = ti81xx_usbss_hwmod,
+ .clk= usbotg_ick,
+ .addr = ti81xx_usbss_addr_space,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if *ti81xx_usbss_slaves[] = {
+ ti81xx_l3_slow__usbss,
+};
+
+static struct omap_hwmod ti81xx_usbss_hwmod = {
+ .name = usb_otg_hs,
+ .mpu_irqs = ti81xx_usbss_mpu_irqs,
+ .main_clk = usbotg_ick,
+ .clkdm_name = default_usb_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = TI816X_CM_DEFAULT_USB_CLKCTRL_OFFSET,
+ },
+ },
+ .slaves = ti81xx_usbss_slaves,
+ .slaves_cnt = ARRAY_SIZE(ti81xx_usbss_slaves),
+ .class = ti81xx_usbotg_class,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_TI816X | CHIP_IS_TI814X)
+};
static __initdata struct omap_hwmod *ti81xx_hwmods[] = {
ti81xx_l3_fast_hwmod,
@@ -668,6 +741,7 @@ static __initdata struct omap_hwmod *ti81xx_hwmods[] = {
ti81xx_timer5_hwmod,
ti81xx_timer6_hwmod,
ti81xx_timer7_hwmod,
+ ti81xx_usbss_hwmod,
NULL,
};
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6 v2] omap: musb: Adding support for ti81xx
From: Ravi Babu ravib...@ti.com
Added musb support for ti81xx platform which has two instances of musb
interface and uses CPPI4.1 DMA. The current patch set adds support for
single instance and in PIO mode only.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
---
arch/arm/mach-omap2/usb-musb.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index a65145b..8bceeca 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -143,6 +143,9 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
if (cpu_is_omap3517() || cpu_is_omap3505()) {
oh_name = am35x_otg_hs;
name = musb-am35x;
+ } else if (cpu_is_ti81xx()) {
+ oh_name = usb_otg_hs;
+ name = musb-ti81xx;
} else {
oh_name = usb_otg_hs;
name = musb-omap2430;
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] omap3: ISP: Fix the failure of CCDC capture during suspend/resume
From: Abhilash K V abhilash...@ti.com
While resuming from the suspended to memory state,
occasionally CCDC fails to get enabled and thus fails
to capture frames any more till the next suspend/resume
is issued.
This is a race condition which happens only when a CCDC
frame-completion ISR is pending even as ISP device's
isp_pm_prepare() is getting called and only one buffer
is left on the DMA queue.
The DMA queue buffers are thus depleted which results in
its underrun.So when ISP resumes there are no buffers on
the queue (as the application which can issue buffers is
yet to resume) to start video capture.
This fix addresses this issue by dequeuing and enqueing
the last buffer in isp_pm_prepare() after its DMA gets
completed. Thus,when ISP resumes it always finds atleast
one buffer on the DMA queue - this is true if application
uses only 3 buffers.
Signed-off-by: Abhilash K V abhilash...@ti.com
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
Changes since v1:
Merged the patch which fixes kernel crash when attempting suspend
drivers/media/video/omap3isp/isp.c | 30 +++-
drivers/media/video/omap3isp/isp.h |4 ++
drivers/media/video/omap3isp/ispvideo.c | 58 ++-
drivers/media/video/omap3isp/ispvideo.h |2 +
4 files changed, 92 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 5cea2bb..00fd021 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -1566,12 +1566,24 @@ static int isp_pm_prepare(struct device *dev)
{
struct isp_device *isp = dev_get_drvdata(dev);
int reset;
+ int err = 0;
+ struct isp_ccdc_device *ccdc = isp-isp_ccdc;
+ struct isp_video *video = ccdc-video_out;
+ struct isp_pipeline *pipe = to_isp_pipeline(video-video.entity);
+ unsigned long flags;
WARN_ON(mutex_is_locked(isp-isp_mutex));
-
if (isp-ref_count == 0)
return 0;
+ spin_lock_irqsave(pipe-lock, flags);
+ pipe-state |= ISP_PIPELINE_PREPARE_SUSPEND;
+ spin_unlock_irqrestore(pipe-lock, flags);
+
+ err = isp_video_handle_buffer_starvation(video);
+ if (err 0)
+ return err;
+
reset = isp_suspend_modules(isp);
isp_disable_interrupts(isp);
isp_save_ctx(isp);
@@ -1596,16 +1608,32 @@ static int isp_pm_suspend(struct device *dev)
static int isp_pm_resume(struct device *dev)
{
struct isp_device *isp = dev_get_drvdata(dev);
+ struct isp_ccdc_device *ccdc = isp-isp_ccdc;
+ struct isp_video *video = ccdc-video_out;
+ struct isp_pipeline *pipe = to_isp_pipeline(video-video.entity);
+ unsigned long flags;
if (isp-ref_count == 0)
return 0;
+ spin_lock_irqsave(pipe-lock, flags);
+ pipe-state = ~ISP_PIPELINE_PREPARE_SUSPEND;
+ spin_unlock_irqrestore(pipe-lock, flags);
+
return isp_enable_clocks(isp);
}
static void isp_pm_complete(struct device *dev)
{
struct isp_device *isp = dev_get_drvdata(dev);
+ struct isp_ccdc_device *ccdc = isp-isp_ccdc;
+ struct isp_video *video = ccdc-video_out;
+ struct isp_pipeline *pipe = to_isp_pipeline(video-video.entity);
+ unsigned long flags;
+
+ spin_lock_irqsave(pipe-lock, flags);
+ pipe-state = ~ISP_PIPELINE_PREPARE_SUSPEND;
+ spin_unlock_irqrestore(pipe-lock, flags);
if (isp-ref_count == 0)
return;
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h
index 521db0c..0acc622 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -259,6 +259,10 @@ int omap3isp_register_entities(struct platform_device
*pdev,
struct v4l2_device *v4l2_dev);
void omap3isp_unregister_entities(struct platform_device *pdev);
+#ifdef CONFIG_PM
+int isp_video_handle_buffer_starvation(struct isp_video *video);
+#endif
+
/*
* isp_reg_readl - Read value of an OMAP3 ISP register
* @dev: Device pointer specific to the OMAP3 ISP.
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index 0b7b6dd..d1c316c 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -526,6 +526,26 @@ static int isp_video_buffer_prepare(struct
isp_video_buffer *buf)
return 0;
}
+#ifdef CONFIG_PM
+static int isp_video_deq_enq(struct isp_video_queue *queue)
+{
+ int err = 0;
+ struct v4l2_buffer vbuf;
+
+ vbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ /* blocking dequeue to ensure DMA is done */
+ err = omap3isp_video_queue_dqbuf(queue, vbuf, 0);
+ if (err 0)
+ return err;
+ else {
+ err = omap3isp_video_queue_qbuf(queue, vbuf);
+ if (err 0)
+ return err;
+ }
+ return
[PATCH v2] ASoC: omap: add MODULE_ALIAS to mcbsp and pcm drivers
This adds MODULE_ALIAS directives to the omap-mcbsp-dai and omap-pcm-audio drivers so they can be auto-loaded when platform devices are scanned. Signed-off-by: Mans Rullgard mans.rullg...@linaro.org --- sound/soc/omap/omap-mcbsp.c |1 + sound/soc/omap/omap-pcm.c |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 07b7723..5ddfadd 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -783,3 +783,4 @@ module_exit(snd_omap_mcbsp_exit); MODULE_AUTHOR(Jarkko Nikula jhnik...@gmail.com); MODULE_DESCRIPTION(OMAP I2S SoC Interface); MODULE_LICENSE(GPL); +MODULE_ALIAS(platform:omap-mcbsp-dai); diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index e6a6b99..f19ccc1 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -437,3 +437,4 @@ module_exit(snd_omap_pcm_exit); MODULE_AUTHOR(Jarkko Nikula jhnik...@gmail.com); MODULE_DESCRIPTION(OMAP PCM DMA module); MODULE_LICENSE(GPL); +MODULE_ALIAS(platform:omap-pcm-audio); -- 1.7.6.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 v2] ASoC: omap: add MODULE_ALIAS to mcbsp and pcm drivers
On Wed, Sep 07, 2011 at 12:07:21PM +0100, Mans Rullgard wrote: This adds MODULE_ALIAS directives to the omap-mcbsp-dai and omap-pcm-audio drivers so they can be auto-loaded when platform devices are scanned. Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ASoC: omap: add MODULE_ALIAS to mcbsp and pcm drivers
Hi On 09/06/2011 11:14 PM, Mans Rullgard wrote: This adds MODULE_ALIAS directives to the omap-mcbsp-dai and omap-pcm-audio drivers so they can be auto-loaded when platform devices are scanned. Signed-off-by: Mans Rullgardmans.rullg...@linaro.org --- sound/soc/omap/omap-mcbsp.c |2 ++ sound/soc/omap/omap-pcm.c |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 07b7723..56b7504 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -758,6 +758,8 @@ static int __devexit asoc_mcbsp_remove(struct platform_device *pdev) return 0; } +MODULE_ALIAS(platform:omap-mcbsp-dai); + Put these at the end of file where the other MODULE_ macros are. Send updated patch to alsa-de...@alsa-project.org with Liam Girdwood and Mark Brown cc'ed (see SOUND - SOC LAYER in ./MAINTAINERS). -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend.
Tero Kristo t-kri...@ti.com writes: Hi, On Sat, 2011-08-27 at 21:42 +0200, Alan Stern wrote: On Sat, 27 Aug 2011, Santosh wrote: On Saturday 27 August 2011 07:31 PM, Alan Stern wrote: On Sat, 27 Aug 2011, Santosh wrote: I might be wrong here, but after discussion with Govindraj on this issue, it seems there is a flaw in the way OMAP chain handler handling the child interrupts. On OMAP, we have special interrupt wakeup source at PRCM level and many devices can trigger wakeup from low power via this common interrupt source. The common interrupt source upon wakeup from low power state, decodes the source of interrupt and based on that source, calls the respective device ISR directly. The issue I see here is, the ISR on _a_ device (UART in this case) is happening even before UART resume and DPM resume has been completed. If this is the case, then it is surely asking for trouble. Because not just clocks, but even driver state machine is already in suspend state when the ISR is called. If the driver state machine is in the suspend state when the ISR is called, then the ISR should realize it is handling a wakeup event instead of a normal I/O event. All it needs to do is turn off the interrupt source; the event itself will be taken care of during the device's resume callback. Good point but the ISR is called as a function call and not real hardware event so no need to turn-off the source in the child ISR. Parent ISR will clear the source anyways. But the intention here is to record the event for the child. In that case the ISR only has to record the event. I mean for UART wakeup, the received character should be extracted. If not done, UART will loose that character because the event is lost. So not sure how the event will be taken care during resume callback. Could you elaborate bit more on last comment please? The resume callback routine must check to see if an event was recorded. If one was, the routine must see whether a character was received while the system was asleep and extract the character from the UART. (It probably won't hurt to do this even if an event wasn't recorded.) Alan Stern After thinking about this problem and looking at possible ways to fix it, I am planning to change the PRCM chain handler to be a driver, which gets suspended along with the rest of the system. This means the PRCM interrupt would get disabled also during this time, and it would be enabled in the driver-complete() call, which should happen after rest of the drivers have been able to enable their PM runtime in the driver-resume() call chain. Do you see any problems with this approach? How will the system wakeup from retention or off-mode if the PRCM IRQ is disabled? Besides that, I don't like this approach because it leaves a rather long window during which no PRCM-triggered wakeup events can happen. This is not good since we also want potential wakeup events that happen *during* system suspend to be able to cancel the suspend. The only issue I am seeing myself is if some driver decides to do resume() in the complete() pm-op and potentially screwing the ordering here... Personally, I think Alan's approach is the only scalable approach. This has to be handled by the drivers. If the driver's ISR does a pm_runtime_get_sync() and it fails (in this case, with -EACCESS since runtime PM is disabled), the driver should handle that handle as Alan described above. 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 2/3] iommu/omap: migrate to the generic fault report mechanism
Start using the generic fault report mechanism, as provided by
the IOMMU core, and remove the now-redundant omap_iommu_set_isr API.
Always use the generic IOMMU_ERROR event type as we're only interested
in letting upper layers know about the error, so in case the faulting
device is a remote processor, they could restart it.
Dynamic PTE/TLB loading is not supported.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/include/plat/iommu.h |3 +--
drivers/iommu/omap-iommu.c | 31 +++
2 files changed, 4 insertions(+), 30 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 7f1df0e..a1d79ee 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -32,6 +32,7 @@ struct omap_iommu {
void __iomem*regbase;
struct device *dev;
void*isr_priv;
+ struct iommu_domain *domain;
unsigned intrefcount;
spinlock_t iommu_lock; /* global for this whole object */
@@ -48,8 +49,6 @@ struct omap_iommu {
struct list_headmmap;
struct mutexmmap_lock; /* protect mmap */
- int (*isr)(struct omap_iommu *obj, u32 da, u32 iommu_errs, void *priv);
-
void *ctx; /* iommu context: registres saved area */
u32 da_start;
u32 da_end;
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index bd5f606..ef70a08 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -775,6 +775,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
u32 da, errs;
u32 *iopgd, *iopte;
struct omap_iommu *obj = data;
+ struct iommu_domain *domain = obj-domain;
if (!obj-refcount)
return IRQ_NONE;
@@ -786,7 +787,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
return IRQ_HANDLED;
/* Fault callback or TLB/PTE Dynamic loading */
- if (obj-isr !obj-isr(obj, da, errs, obj-isr_priv))
+ if (!report_iommu_fault(domain, obj-dev, da, 0, IOMMU_ERROR))
return IRQ_HANDLED;
iommu_disable(obj);
@@ -904,33 +905,6 @@ static void omap_iommu_detach(struct omap_iommu *obj)
dev_dbg(obj-dev, %s: %s\n, __func__, obj-name);
}
-int omap_iommu_set_isr(const char *name,
- int (*isr)(struct omap_iommu *obj, u32 da, u32 iommu_errs,
-void *priv),
- void *isr_priv)
-{
- struct device *dev;
- struct omap_iommu *obj;
-
- dev = driver_find_device(omap_iommu_driver.driver, NULL, (void *)name,
-device_match_by_alias);
- if (!dev)
- return -ENODEV;
-
- obj = to_iommu(dev);
- spin_lock(obj-iommu_lock);
- if (obj-refcount != 0) {
- spin_unlock(obj-iommu_lock);
- return -EBUSY;
- }
- obj-isr = isr;
- obj-isr_priv = isr_priv;
- spin_unlock(obj-iommu_lock);
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(omap_iommu_set_isr);
-
/*
* OMAP Device MMU(IOMMU) detection
*/
@@ -1115,6 +1089,7 @@ omap_iommu_attach_dev(struct iommu_domain *domain, struct
device *dev)
}
omap_domain-iommu_dev = oiommu;
+ oiommu-domain = domain;
out:
spin_unlock(omap_domain-lock);
--
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 1/3] iommu/core: add fault reporting mechanism
Add iommu fault report mechanism to the IOMMU API, so implementations
could report about mmu faults (translation errors, hardware errors,
etc..).
Fault reports can be used in several ways:
- mere logging
- reset the device that accessed the faulting address (may be necessary
in case the device is a remote processor for example)
- implement dynamic PTE/TLB loading
A dedicated iommu_set_fault_handler() API has been added to allow
users, who are interested to receive such reports, to provide
their handler.
At this point only a generic IOMMU_ERROR fault type has been added.
Future users, who will require additional fault types, will add
new events as needed.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/iommu/iommu.c | 13 ++
include/linux/iommu.h | 65 +
2 files changed, 78 insertions(+), 0 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index e61a9ba..c68ff29 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -40,6 +40,19 @@ bool iommu_found(void)
}
EXPORT_SYMBOL_GPL(iommu_found);
+/**
+ * iommu_domain_alloc() - set a fault handler for an iommu domain
+ * @domain: iommu domain
+ * @handler: fault handler
+ */
+void iommu_set_fault_handler(struct iommu_domain *domain,
+ iommu_fault_handler_t handler)
+{
+ BUG_ON(!domain);
+
+ domain-handler = handler;
+}
+
struct iommu_domain *iommu_domain_alloc(void)
{
struct iommu_domain *domain;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 9940319..d67bf8c 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -26,9 +26,31 @@
#define IOMMU_CACHE(4) /* DMA cache coherency */
struct device;
+struct iommu_domain;
+
+/**
+ * enum iommu_fault_types - iommu fault types
+ *
+ * @IOMMU_ERROR: Unrecoverable error
+ *
+ * Currently we only support a generic error fault type.
+ * Future users, which will require more informative fault types, will add
+ * them as needed.
+ */
+enum iommu_fault_types {
+ IOMMU_ERROR,
+};
+
+/* iommu fault flags */
+#define IOMMU_FAULT_READ 0x0
+#define IOMMU_FAULT_WRITE 0x1
+
+typedef int (*iommu_fault_handler_t)(struct iommu_domain *,
+ struct device *, unsigned long, int, int);
struct iommu_domain {
void *priv;
+ iommu_fault_handler_t handler;
};
#define IOMMU_CAP_CACHE_COHERENCY 0x1
@@ -67,6 +89,44 @@ extern phys_addr_t iommu_iova_to_phys(struct iommu_domain
*domain,
unsigned long iova);
extern int iommu_domain_has_cap(struct iommu_domain *domain,
unsigned long cap);
+extern void iommu_set_fault_handler(struct iommu_domain *domain,
+ iommu_fault_handler_t handler);
+
+/**
+ * report_iommu_fault() - report about an IOMMU fault to the IOMMU framework
+ * @domain: the iommu domain where the fault has happened
+ * @dev: the device where the fault has happened
+ * @iova: the faulting address
+ * @flags: mmu fault flags (e.g. IOMMU_FAULT_READ/IOMMU_FAULT_WRITE/...)
+ * @event: the mmu fault type
+ *
+ * This function should be called by the low-level IOMMU implementations
+ * whenever IOMMU faults happen, to allow high-level users, that are
+ * interested in such events, to know about them.
+ *
+ * This event may be useful for several possible use cases:
+ * - mere logging of the event
+ * - dynamic TLB/PTE loading
+ * - if restarting of the faulting device is required
+ *
+ * Returns 0 on success and an appropriate error code otherwise (if dynamic
+ * PTE/TLB loading will one day be supported, implementations will be able
+ * to tell whether it succeeded or not according to this return value).
+ */
+static inline int report_iommu_fault(struct iommu_domain *domain,
+ struct device *dev, unsigned long iova, int flags, int event)
+{
+ int ret = 0;
+
+ /*
+* if upper layers showed interest and installed a fault handler,
+* invoke it.
+*/
+ if (domain-handler)
+ ret = domain-handler(domain, dev, iova, flags, event);
+
+ return ret;
+}
#else /* CONFIG_IOMMU_API */
@@ -123,6 +183,11 @@ static inline int domain_has_cap(struct iommu_domain
*domain,
return 0;
}
+static inline void iommu_set_fault_handler(struct iommu_domain *domain,
+ iommu_fault_handler_t handler)
+{
+}
+
#endif /* CONFIG_IOMMU_API */
#endif /* __LINUX_IOMMU_H */
--
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/3] iommu/core: split mapping to page sizes as supported by the hardware
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
The logic to do that is now added to the IOMMU core, so neither the iommu
drivers themselves nor users of the IOMMU API have to duplicate it.
This allows a more lenient granularity of mappings; traditionally the
IOMMU API took 'order' (of a page) as a mapping size, and directly let
the low level iommu drivers handle the mapping, but now that the IOMMU
core can split arbitrary memory regions into pages, we can remove this
limitation, so users don't have to split those regions by themselves.
Currently the supported page sizes are advertised once and they then
remain static. That works well for OMAP (and seemingly MSM too) but
it might not fly with intel's hardware, where the page size
capabilities seem to have the potential to be different between
several DMA remapping devices.
To simplify the migration, this patch retains the existing behavior
for the x86 IOMMU drivers, by having them advertise support for
all page sizes that are an order of 4KB.
OMAP and MSM iommu drivers are migrated to advertise support
for 4KB, 64KB, 1MB and 16MB (as supported by their hardware).
Mainline users of the IOMMU API (kvm and omap-iovmm) are adopted
to send the mapping size in bytes instead of in page order.
Tested with OMAP3 and OMAP4. Compile tested on X86-64.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: David Brown dav...@codeaurora.org
Cc: David Woodhouse dw...@infradead.org
Cc: Joerg Roedel joerg.roe...@amd.com
Cc: Stepan Moskovchenko step...@codeaurora.org
Cc: Hiroshi DOYU hiroshi.d...@nokia.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: k...@vger.kernel.org
---
drivers/iommu/amd_iommu.c | 20 ++-
drivers/iommu/intel-iommu.c | 20 ++-
drivers/iommu/iommu.c | 129 +++
drivers/iommu/msm_iommu.c |8 ++-
drivers/iommu/omap-iommu.c |6 ++-
drivers/iommu/omap-iovmm.c | 12 +---
include/linux/iommu.h |7 +-
virt/kvm/iommu.c|4 +-
8 files changed, 176 insertions(+), 30 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index a14f8dc..5cdfa91 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2488,12 +2488,30 @@ static unsigned device_dma_ops_init(void)
}
/*
+ * This bitmap is used to advertise the page sizes our hardware support
+ * to the IOMMU core, which will then use this information to split
+ * physically contiguous memory regions it is mapping into page sizes
+ * that we support.
+ *
+ * Traditionally the IOMMU core just handed us the mappings directly,
+ * after making sure the size is an order of a 4KB page and that the
+ * mapping has natural alignment.
+ *
+ * To retain this behavior, we currently advertise that we support
+ * all page sizes that are an order of 4KB.
+ *
+ * If at some point we'd like to utilize the IOMMU core's new behavior,
+ * we could change this to advertise the real page sizes we support.
+ */
+static unsigned long amd_iommu_pgsizes = ~0xFFFUL;
+
+/*
* The function which clues the AMD IOMMU driver into dma_ops.
*/
void __init amd_iommu_init_api(void)
{
- register_iommu(amd_iommu_ops);
+ register_iommu(amd_iommu_ops, amd_iommu_pgsizes, BITS_PER_LONG);
}
int __init amd_iommu_init_dma_ops(void)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c621c98..a8c91a6 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3426,6 +3426,24 @@ static struct notifier_block device_nb = {
.notifier_call = device_notifier,
};
+/*
+ * This bitmap is used to advertise the page sizes our hardware support
+ * to the IOMMU core, which will then use this information to split
+ * physically contiguous memory regions it is mapping into page sizes
+ * that we support.
+ *
+ * Traditionally the IOMMU core just handed us the mappings directly,
+ * after making sure the size is an order of a 4KB page and that the
+ * mapping has natural alignment.
+ *
+ * To retain this behavior, we currently advertise that we support
+ * all page sizes that are an order of 4KB.
+ *
+ * If at some point we'd like to utilize the IOMMU core's new behavior,
+ * we could change this to advertise the real page sizes we support.
+ */
+static unsigned long intel_iommu_pgsizes = ~0xFFFUL;
+
int __init intel_iommu_init(void)
{
int ret = 0;
@@ -3486,7 +3504,7 @@ int __init intel_iommu_init(void)
init_iommu_pm_ops();
- register_iommu(intel_iommu_ops);
+ register_iommu(intel_iommu_ops, intel_iommu_pgsizes, BITS_PER_LONG);
bus_register_notifier(pci_bus_type, device_nb);
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index c68ff29..e07ea03 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -16,6 +16,8 @@
* Foundation, Inc., 59 Temple Place,
Re: [PATCH 00/10] OMAP: voltage cleanup part B: VC cleanup
Kevin, On Mon, Aug 29, 2011 at 7:49 PM, Kevin Hilman khil...@ti.com wrote: This series focuses on cleanup and better abstraction in the voltage controller (VC) layer. Available in the pm-wip/voltdm_b branch of my linux-omap-pm tree git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Applies on v3.1-rc3 + the part A series (pm-wip/voltdm_a branch) Kevin Ok after review. FWIW: Acked-by: Jean Pihet j-pi...@ti.com Regards, Jean Kevin Hilman (10): OMAP3+: VC: cleanup i2c slave address configuration OMAP3+: VC: cleanup PMIC register address configuration OMAP3+: VC bypass: use fields from VC struct instead of PMIC info OMAP3+: VC: cleanup voltage setup time configuration OMAP3+: VC: move on/onlp/ret/off command configuration into common init OMAP3+: VC: abstract out channel configuration OMAP3+: voltage domain: move PMIC struct from vdd_info into struct voltagedomain OMAP3+: VC: make I2C config programmable with PMIC-specific settings OMAP3+: PM: VC: handle mutant channel config for OMAP4 MPU channel OMAP3+: VC: use last nominal voltage setting to get current_vsel arch/arm/mach-omap2/omap_twl.c | 32 ++-- arch/arm/mach-omap2/vc.c | 248 ++--- arch/arm/mach-omap2/vc.h | 35 +++- arch/arm/mach-omap2/vc3xxx_data.c | 13 +- arch/arm/mach-omap2/vc44xx_data.c | 18 ++- arch/arm/mach-omap2/voltage.c | 29 ++-- arch/arm/mach-omap2/voltage.h | 29 ++-- arch/arm/mach-omap2/voltagedomains3xxx_data.c | 8 +- arch/arm/mach-omap2/voltagedomains44xx_data.c | 12 +- arch/arm/mach-omap2/vp.c | 13 +- 10 files changed, 293 insertions(+), 144 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/22] OMAP: voltage cleanup part A
Kevin, On Mon, Aug 29, 2011 at 7:35 PM, Kevin Hilman khil...@ti.com wrote: This is the first phase of the OMAP voltage layer cleanup. The primary goal is to cleanup/reorganize data structures to facilitate splitting apart the voltage processor (VP) and voltage controller (VC) into separate layers. Based on v3.1-rc3 Series available in branch pm-wip/voltdm_a in my linux-omap-pm tree: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Some comments have been sent on this patch set, otherwise OK after review. FWIW: Acked-by: Jean Pihet j-pi...@ti.com Regards, Jean Benoit Cousson (1): OMAP4: powerdomain data: add voltage domains Kevin Hilman (21): OMAP2+: hwmod: remove unused voltagedomain pointer OMAP2+: voltage: move PRCM mod offets into VC/VP structures OMAP2+: voltage: move prm_irqst_reg from VP into voltage domain OMAP2+: voltage: start towards a new voltagedomain layer OMAP3: voltage: rename mpu voltagedomain to mpu_iva OMAP3: voltagedomain data: add wakeup domain OMAP3+: voltage: add scalable flag to voltagedomain OMAP2+: powerdomain: add voltagedomain to struct powerdomain OMAP2: add voltage domains and connect to powerdomains OMAP3: powerdomain data: add voltage domains OMAP2+: powerdomain: add voltage domain lookup during register OMAP2+: voltage: keep track of powerdomains in each voltagedomain OMAP2+: voltage: split voltage controller (VC) code into dedicated layer OMAP2+: voltage: move VC into struct voltagedomain, misc. renames OMAP2+: voltage: enable VC bypass scale method when VC is initialized OMAP2+: voltage: split out voltage processor (VP) code into new layer OMAP2+: VC: support PMICs with separate voltage and command registers OMAP2+: add PRM VP functions for checking/clearing VP TX done status OMAP3+ VP: replace transaction done check/clear with VP ops OMAP2+: PRM: add register access functions for VC/VP OMAP3+: voltage: convert to PRM register access functions arch/arm/mach-omap2/Makefile | 5 +- arch/arm/mach-omap2/io.c | 5 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4 +- arch/arm/mach-omap2/omap_twl.c | 20 +- arch/arm/mach-omap2/pm.c | 4 +- arch/arm/mach-omap2/powerdomain.c | 23 + arch/arm/mach-omap2/powerdomain.h | 10 + arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c | 2 + arch/arm/mach-omap2/powerdomains2xxx_data.c | 4 + arch/arm/mach-omap2/powerdomains3xxx_data.c | 16 + arch/arm/mach-omap2/powerdomains44xx_data.c | 16 + arch/arm/mach-omap2/prm2xxx_3xxx.c | 56 ++ arch/arm/mach-omap2/prm2xxx_3xxx.h | 12 + arch/arm/mach-omap2/prm44xx.c | 71 ++ arch/arm/mach-omap2/prm44xx.h | 12 + arch/arm/mach-omap2/sr_device.c | 2 +- arch/arm/mach-omap2/vc.c | 259 +++ arch/arm/mach-omap2/vc.h | 34 +- arch/arm/mach-omap2/vc3xxx_data.c | 10 +- arch/arm/mach-omap2/vc44xx_data.c | 14 +- arch/arm/mach-omap2/voltage.c | 889 +- arch/arm/mach-omap2/voltage.h | 61 +- arch/arm/mach-omap2/voltagedomains2xxx_data.c | 32 + arch/arm/mach-omap2/voltagedomains3xxx_data.c | 53 +- arch/arm/mach-omap2/voltagedomains44xx_data.c | 69 +- arch/arm/mach-omap2/vp.c | 367 + arch/arm/mach-omap2/vp.h | 45 +- arch/arm/mach-omap2/vp3xxx_data.c | 21 +- arch/arm/mach-omap2/vp44xx_data.c | 28 +- arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 - 30 files changed, 1281 insertions(+), 864 deletions(-) create mode 100644 arch/arm/mach-omap2/vc.c create mode 100644 arch/arm/mach-omap2/voltagedomains2xxx_data.c create mode 100644 arch/arm/mach-omap2/vp.c -- 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 -- To unsubscribe from this list: send the line unsubscribe 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/7] OMAP: voltage cleanup part D: voltage domain
Hi Kevin, On Mon, Aug 29, 2011 at 8:10 PM, Kevin Hilman khil...@ti.com wrote: This series focuses on cleanup of the remaining voltage domain layer (non-VC/VP code) Available in the pm-wip/voltdm_d branch of my linux-omap-pm tree git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Applies on v3.1-rc3 + the part A, B C series. Kevin Ok to me after review. FWIW: Acked-by: Jean Pihet j-pi...@ti.com Regards, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6 v2] usb: musb: Add support for ti81xx platform
Hi,
On Wed, Sep 07, 2011 at 10:32:25PM +0530, Ajay Kumar Gupta wrote:
+static int __devinit dsps_probe(struct platform_device *pdev)
+{
+ const struct platform_device_id *id = platform_get_device_id(pdev);
+ const struct dsps_musb_wrapper *wrp =
+ (struct dsps_musb_wrapper *)id-driver_data;
+ struct dsps_glue *glue;
+ struct resource *iomem;
+ int ret;
+
+ /* allocate glue */
+ glue = kzalloc(sizeof(*glue), GFP_KERNEL);
+ if (!glue) {
+ dev_err(pdev-dev, unable to allocate glue memory\n);
+ ret = -ENOMEM;
+ goto err0;
+ }
+
+ /* get memory resource */
+ iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!iomem) {
+ dev_err(pdev-dev, failed to get usbss mem resourse\n);
+ ret = -ENODEV;
+ goto err1;
+ }
+
+ glue-dev = pdev-dev;
+ glue-wrp = wrp;
wrp is marked __devinitconst, so I guess you need to copy it here,
instead of just pointing to it.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 00/12] OMAP: voltage cleanup part C: VP cleanup
Kevin, On Mon, Aug 29, 2011 at 7:58 PM, Kevin Hilman khil...@ti.com wrote: This series focuses on cleanup and better abstraction in the voltage processor (VP) layer. Available in the pm-wip/voltdm_c branch of my linux-omap-pm tree git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Applies on v3.1-rc3 + the part A B series. Kevin Some comments have been sent on this patch set, otherwise OK after review. FWIW: Acked-by: Jean Pihet j-pi...@ti.com Regards, Jean Kevin Hilman (11): OMAP3+: VP: cleanup: move VP instance into voltdm, misc. renames OMAP3+: voltage: remove unneeded debugfs interface OMAP3+: VP: struct omap_vp_common: replace shift with __ffs(mask) OMAP3+: VP: move SoC-specific sys clock rate retreival late init OMAP3+: VP: move timing calculation/config into VP init OMAP3+: VP: create VP helper function for updating error gain OMAP3+: VP: remove omap_vp_runtime_data OMAP3+: VP: move voltage scale function pointer into struct voltagedomain OMAP3+: VP: update_errorgain(): return error if VP OMAP3+: VP: remove unused omap_vp_get_curr_volt() OMAP3+: VP: combine setting init voltage into common function Todd Poynor (1): OMAP: VP: Explicitly mask VPVOLTAGE field arch/arm/mach-omap2/smartreflex.c | 29 ++- arch/arm/mach-omap2/vc.c | 22 +-- arch/arm/mach-omap2/voltage.c | 161 ++ arch/arm/mach-omap2/voltage.h | 24 +-- arch/arm/mach-omap2/voltagedomains3xxx_data.c | 18 +- arch/arm/mach-omap2/voltagedomains44xx_data.c | 23 ++- arch/arm/mach-omap2/vp.c | 292 + arch/arm/mach-omap2/vp.h | 91 +++- arch/arm/mach-omap2/vp3xxx_data.c | 16 +- arch/arm/mach-omap2/vp44xx_data.c | 19 +- 10 files changed, 226 insertions(+), 469 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 -- To unsubscribe from this list: send the line unsubscribe 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/8] OMAP3+: PM: VP: generalize PRM interrupt helpers
Mike, Kevin, On Thu, Jun 30, 2011 at 2:25 AM, Mike Turquette mturque...@ti.com wrote: 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. I am not sure that the rename is needed. Kevin, Nishant, what is your opinion? Regards, Jean 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(-) -- To unsubscribe from this list: send the line unsubscribe 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/8] OMAP3+: ABB: Adaptive Body-Bias structures data
Hi Mike, On Thu, Jun 30, 2011 at 2:25 AM, Mike Turquette mturque...@ti.com wrote: 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. The OMAP_ABB_ macros are defined but not used in this patch set. Is this intentional? Should the opp_sel field get tested against OMAP_ABB_NO_LDO and if true should the ABB operations be no-ops? 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 Regards, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 06/10] hwspinlock: OMAP4: Add spinlock support in DT
On Wed, Aug 24, 2011 at 4:09 PM, Benoit Cousson b-cous...@ti.com wrote:
Add a device-tree node for the spinlock.
Remove the static device build code if CONFIG_OF
is set.
Update the hwspinlock driver to use the of_match method.
Add the information in Documentation/devicetree.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Ohad Ben-Cohen o...@wizery.com
---
...
+ spinlock {
+ compatible = ti,omap-spinlock;
+ hwmods = spinlock;
+ };
This seem to satisfy the current hwspinlock driver, but I'm wondering
about an issue which was discussed awhile ago by Arnd and Mathieu:
Hwspinlock devices provide system-wide hardware locks that are used by
remote processors that have no other way to achieve synchronization.
For that to work, each physical lock must have a system-wide unique id
number that all processors are familiar with, otherwise they can't
possibly assume they're using the same hardware lock.
Usually SoC have a single hwspinlock device, which provides several
hardware spinlocks, and in this case, the locks can be trivially
numbered 0 to (num-of-locks - 1).
In case boards have several hwspinlocks devices (each of which
providing numerous hardware spinlocks) a different base id should be
used for each hwspinlock device (they can't all use 0 as a starting
id!).
While this is certainly not common, it's just plain wrong for the
hwspinlock driver to silently use 0 as a base id whenever it is probed
with a device (and by that implicitly assume there will always be only
one device).
So we need to couple an hwspinlock device with a base id (which is
trivially zero when there's only a single hwspinlock device). This can
be easily achieved today using platform data, which boards will use to
set a different base id for each of the hwspinlock devices they have
(i'll send a patch demonstrating this soon), but I'm wondering how to
specify this hwspinlock-specific data with DT: is there an existing
binding we can use for this ? or should we create something like a
baseid one especially for the hwspinlock driver ?
+#if defined(CONFIG_OF)
+static const struct of_device_id spinlock_match[] = {
+ {.compatible = ti,omap-spinlock, },
+ {},
+}
you're missing a semicolon there (yeah I actually tried to build this ;)
--
To unsubscribe from this list: send the line unsubscribe 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 7/8] OMAP3+: ABB: initialization transition functions
Mike,
I have a minor comment below.
On Thu, Jun 30, 2011 at 2:25 AM, Mike Turquette mturque...@ti.com wrote:
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
---
...
diff --git a/arch/arm/mach-omap2/abb.c b/arch/arm/mach-omap2/abb.c
new file mode 100644
index 000..b8b6b4b
...
+/*
+ * omap_abb_disable - disable ABB ldo on a particular voltage domain
+ *
+ * @voltdm - pointer to particular voltage domain
+ *
+ * Included for completeness. Not currently used but will be needed in the
+ * future if ABB is converted to a loadable module.
+ */
+void omap_abb_disable(struct voltagedomain *voltdm)
+{
+ struct omap_abb_instance *abb = voltdm-abb;
+
+ if (!abb-enabled)
+ return;
+
+ abb-enabled = false;
+
+ voltdm-rmw(abb-common-sr2en_mask,
+ (0 __ffs(abb-common-sr2en_mask)),
(0 x) can be replaced with 0.
+ abb-setup_offs);
+}
+
...
Regards,
Jean
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] McBSP cleanup and generalization
On Wed, 31 Aug 2011 at 17:22:47 Jarkko Nikula wrote: Hi Updates and continuation to my McBSP cleanup RFC set I sent before vacation period. Motivation here is to get rid off all is_omap and CONFIG_ARCH stuff and to make code a step more generic (and for preparing to move code out under arch/arm/). I hope this version doesn't break OMAP1. Works for me on my Amstrad Delta. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe 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 v2 5/6] TI81XX: Add minimal hwmod data
Hilman, Kevin wrote on Tuesday, August 30, 2011 6:03 AM: Hemant Pedanekar hema...@ti.com writes: This patch adds minimum required hwmod data (e.g., UARTs) for bootup of TI81XX devices (currently common data for TI816X and TI814X is added). Signed-off-by: Hemant Pedanekar hema...@ti.com I haven't looked at the details yet, but just tried to boot this using current mainline and it fails. My first guess is that it appears to be related to a missing clkdm for the MPU hwmod. Kevin Thanks for the feedback. I think that the issue is bacause clk_get() on fck_source is failing as TI816X clock data had different clock source names compared to OMAP3 (e.g., osc_sys_ck instead of sys_ck). I will update this in next version. Even after this, the kernel would get stuck at Calibrating delay loop... because a few timer register offsets on TI81XX are different than OMAP3. I see there are some patches floating on ML which add reg_map array (similar to i2c driver) but seems they have not (yet) been accepted. Any chance that this will get added to kernel? Thanks. Hemant-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] TI814X: Create board support and enable build for TI8148 EVM
Hilman, Kevin wrote on Tuesday, August 30, 2011 5:43 AM:
Hemant Pedanekar hema...@ti.com writes:
This patch adds minimal support and build configuration for TI8148 EVM.
Also adds support for low level debugging on UART1 console on the EVM.
Signed-off-by: Hemant Pedanekar hema...@ti.com
[...]
+static void __init ti8148_init_early(void)
+{
+omap2_init_common_infrastructure();
+omap2_init_common_devices(NULL, NULL);
Note that this function no longer exists in mainline.
Kevin
Will fix this in v2.
Thanks.
Hemant--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Issue: Runtime API usage in wake-up device irq_handler during wakeup from system-wide-suspend.
On Wed, 2011-09-07 at 19:59 +0200, Hilman, Kevin wrote: Tero Kristo t-kri...@ti.com writes: Hi, On Sat, 2011-08-27 at 21:42 +0200, Alan Stern wrote: On Sat, 27 Aug 2011, Santosh wrote: On Saturday 27 August 2011 07:31 PM, Alan Stern wrote: On Sat, 27 Aug 2011, Santosh wrote: I might be wrong here, but after discussion with Govindraj on this issue, it seems there is a flaw in the way OMAP chain handler handling the child interrupts. On OMAP, we have special interrupt wakeup source at PRCM level and many devices can trigger wakeup from low power via this common interrupt source. The common interrupt source upon wakeup from low power state, decodes the source of interrupt and based on that source, calls the respective device ISR directly. The issue I see here is, the ISR on _a_ device (UART in this case) is happening even before UART resume and DPM resume has been completed. If this is the case, then it is surely asking for trouble. Because not just clocks, but even driver state machine is already in suspend state when the ISR is called. If the driver state machine is in the suspend state when the ISR is called, then the ISR should realize it is handling a wakeup event instead of a normal I/O event. All it needs to do is turn off the interrupt source; the event itself will be taken care of during the device's resume callback. Good point but the ISR is called as a function call and not real hardware event so no need to turn-off the source in the child ISR. Parent ISR will clear the source anyways. But the intention here is to record the event for the child. In that case the ISR only has to record the event. I mean for UART wakeup, the received character should be extracted. If not done, UART will loose that character because the event is lost. So not sure how the event will be taken care during resume callback. Could you elaborate bit more on last comment please? The resume callback routine must check to see if an event was recorded. If one was, the routine must see whether a character was received while the system was asleep and extract the character from the UART. (It probably won't hurt to do this even if an event wasn't recorded.) Alan Stern After thinking about this problem and looking at possible ways to fix it, I am planning to change the PRCM chain handler to be a driver, which gets suspended along with the rest of the system. This means the PRCM interrupt would get disabled also during this time, and it would be enabled in the driver-complete() call, which should happen after rest of the drivers have been able to enable their PM runtime in the driver-resume() call chain. Do you see any problems with this approach? How will the system wakeup from retention or off-mode if the PRCM IRQ is disabled? This is actually some sort of an issue with retention if we disable PRCM irq completely, off works purely with wakeup signals as we come out of reset. Anyway, I did some experimentation with this, and OMAP3 is able to wake up if we leave WKUP irq up, but disable IO chain irq. IO chain events seem to trigger a WKUP event also always, we just postpone the processing of IO chain until later. I had to also split the wakeup clearing for OMAP3 into 2 parts, one part handles wakeups and another IO chain. Currently both IO chain and WKUP are acked by the same handler. Besides that, I don't like this approach because it leaves a rather long window during which no PRCM-triggered wakeup events can happen. This is not good since we also want potential wakeup events that happen *during* system suspend to be able to cancel the suspend. This should also be taken care of by the approach described above. The only issue I am seeing myself is if some driver decides to do resume() in the complete() pm-op and potentially screwing the ordering here... Personally, I think Alan's approach is the only scalable approach. This has to be handled by the drivers. If the driver's ISR does a pm_runtime_get_sync() and it fails (in this case, with -EACCESS since runtime PM is disabled), the driver should handle that handle as Alan described above. Yea I think this probably needs to be done anyway, at least on some cases. The PRCM chain handler approach might be able to solve most of the problems though. I think I will post what I have anyway for comments hopefully later today, so you can have a look and say what you think. -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
[PATCH 0/8] OMAP3/4: Misc fixes and clean-up
The series contains few fixes and clean-up for OMAP. Briefly, - HWMOD fix for the address space count - Improving the L3 register accesses - Bug fix in the L3 error handler - Sparce warning and indentation fixes in L3 error handler - Print master id in case of L3 custom errors for better debug. - Adding local time clock node for the CPUfreq and time re-calibration - Fix in the address overlap for emif and emulation domain. The series is tested on OMAP4430 SDP and OMAP4430 beagle and SDP. The following changes since commit c6a389f123b9f68d605bb7e0f9b32ec1e3e14132: Linux 3.1-rc4 (2011-08-28 21:16:01 -0700) are available in the git repository at: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git v3.1-rc4-omap-misc Santosh Shilimkar (2): OMAP4: clock: Add CPU local timer clock node. OMAP4: Fix the emif and dmm virtual mapping Todd Poynor (2): OMAP: Improve register access in L3 Error handler. OMAP: Fix a BUG in l3 error handler. sricharan (4): OMAP: hwmod: Fix the addr spaces count API. OMAP: Fix indentation issues in l3 error handler. OMAP: Fix sparse warnings in l3 error handler. OMAP: Print Initiator name for l3 custom error. arch/arm/mach-omap2/clock44xx_data.c |9 ++ arch/arm/mach-omap2/omap_hwmod.c |8 +- arch/arm/mach-omap2/omap_l3_noc.c| 130 ++-- arch/arm/mach-omap2/omap_l3_noc.h| 224 +++--- arch/arm/mach-omap2/omap_l3_smx.c| 91 +++--- arch/arm/mach-omap2/omap_l3_smx.h| 164 arch/arm/plat-omap/include/plat/io.h |4 +- 7 files changed, 336 insertions(+), 294 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] OMAP: hwmod: Fix the addr spaces count API.
From: sricharan r.sricha...@ti.com
The address space count API returns the number of address space
entries for a hwmod including a additional null value present in the
address space structure introduced recently. The devices which
have multiple hwmods and use device_build_ss are broken with this,
as their address resources are populated with a extra null value,
subsequently the probe fails. So fix the API not to add the null value.
Signed-off-by: sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 84cc0bd..32a0f48a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -791,9 +791,11 @@ static int _count_ocp_if_addr_spaces(struct
omap_hwmod_ocp_if *os)
if (!os || !os-addr)
return 0;
- do {
- mem = os-addr[i++];
- } while (mem-pa_start != mem-pa_end);
+ mem = os-addr[i];
+
+ while (mem-pa_start != mem-pa_end) {
+ mem = os-addr[++i];
+ };
return i;
}
--
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] OMAP: Fix a BUG in l3 error handler.
From: Todd Poynor toddpoy...@google.com
With the current sequence of registering the irq and
assigning it to the app_irq, debug_irq driver variables,
there can be corner cases where the pending irq gets
triggered immediately after registering, handler gets called
resulting in a crash. So changed this sequence.
Signed-off-by: sricharan r.sricha...@ti.com
Signed-off-by: Todd Poynor toddpoy...@google.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_l3_noc.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_l3_noc.c
b/arch/arm/mach-omap2/omap_l3_noc.c
index d560c88..cf237dd 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.c
+++ b/arch/arm/mach-omap2/omap_l3_noc.c
@@ -124,7 +124,7 @@ static int __init omap4_l3_probe(struct platform_device
*pdev)
{
static struct omap4_l3 *l3;
struct resource *res;
- int ret, irq;
+ int ret;
l3 = kzalloc(sizeof(*l3), GFP_KERNEL);
if (!l3)
@@ -176,8 +176,8 @@ static int __init omap4_l3_probe(struct platform_device
*pdev)
/*
* Setup interrupt Handlers
*/
- irq = platform_get_irq(pdev, 0);
- ret = request_irq(irq,
+ l3-debug_irq = platform_get_irq(pdev, 0);
+ ret = request_irq(l3-debug_irq,
l3_interrupt_handler,
IRQF_DISABLED, l3-dbg-irq, l3);
if (ret) {
@@ -185,10 +185,9 @@ static int __init omap4_l3_probe(struct platform_device
*pdev)
OMAP44XX_IRQ_L3_DBG);
goto err3;
}
- l3-debug_irq = irq;
- irq = platform_get_irq(pdev, 1);
- ret = request_irq(irq,
+ l3-app_irq = platform_get_irq(pdev, 1);
+ ret = request_irq(l3-app_irq,
l3_interrupt_handler,
IRQF_DISABLED, l3-app-irq, l3);
if (ret) {
@@ -196,7 +195,6 @@ static int __init omap4_l3_probe(struct platform_device
*pdev)
OMAP44XX_IRQ_L3_APP);
goto err4;
}
- l3-app_irq = irq;
return 0;
--
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 4/8] OMAP: Fix indentation issues in l3 error handler.
From: sricharan r.sricha...@ti.com
The indentation problems in the l3 noc and smx
error handler files are fixed.
Signed-off-by: sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Reported-by: Paul Walmsley p...@pwsan.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_l3_noc.c | 58 +++---
arch/arm/mach-omap2/omap_l3_noc.h | 106 +-
arch/arm/mach-omap2/omap_l3_smx.c | 86 ++--
arch/arm/mach-omap2/omap_l3_smx.h | 156 ++--
4 files changed, 202 insertions(+), 204 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_l3_noc.c
b/arch/arm/mach-omap2/omap_l3_noc.c
index cf237dd..1f68e95 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.c
+++ b/arch/arm/mach-omap2/omap_l3_noc.c
@@ -1,25 +1,25 @@
/*
- * OMAP4XXX L3 Interconnect error handling driver
- *
- * Copyright (C) 2011 Texas Corporation
- *Santosh Shilimkar santosh.shilim...@ti.com
- *Sricharan r.sricha...@ti.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
- * USA
- */
+ * OMAP4XXX L3 Interconnect error handling driver
+ *
+ * Copyright (C) 2011 Texas Corporation
+ * Santosh Shilimkar santosh.shilim...@ti.com
+ * Sricharan r.sricha...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ * USA
+ */
#include linux/init.h
#include linux/io.h
#include linux/platform_device.h
@@ -55,7 +55,7 @@
static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
{
- struct omap4_l3 *l3 = _l3;
+ struct omap4_l3 *l3 = _l3;
int inttype, i;
int err_src = 0;
u32 std_err_main, err_reg, clear, base, l3_targ_base;
@@ -122,7 +122,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
static int __init omap4_l3_probe(struct platform_device *pdev)
{
- static struct omap4_l3 *l3;
+ static struct omap4_l3 *l3;
struct resource *res;
int ret;
@@ -182,7 +182,7 @@ static int __init omap4_l3_probe(struct platform_device
*pdev)
IRQF_DISABLED, l3-dbg-irq, l3);
if (ret) {
pr_crit(L3: request_irq failed to register for 0x%x\n,
-OMAP44XX_IRQ_L3_DBG);
+ OMAP44XX_IRQ_L3_DBG);
goto err3;
}
@@ -192,7 +192,7 @@ static int __init omap4_l3_probe(struct platform_device
*pdev)
IRQF_DISABLED, l3-app-irq, l3);
if (ret) {
pr_crit(L3: request_irq failed to register for 0x%x\n,
-OMAP44XX_IRQ_L3_APP);
+ OMAP44XX_IRQ_L3_APP);
goto err4;
}
@@ -213,7 +213,7 @@ err0:
static int __exit omap4_l3_remove(struct platform_device *pdev)
{
- struct omap4_l3 *l3 = platform_get_drvdata(pdev);
+ struct omap4_l3 *l3 = platform_get_drvdata(pdev);
free_irq(l3-app_irq, l3);
free_irq(l3-debug_irq, l3);
@@ -226,9 +226,9 @@ static int __exit omap4_l3_remove(struct platform_device
*pdev)
}
static struct platform_driver omap4_l3_driver = {
- .remove = __exit_p(omap4_l3_remove),
- .driver = {
- .name = omap_l3_noc,
+ .remove = __exit_p(omap4_l3_remove),
+ .driver = {
+ .name = omap_l3_noc,
},
};
diff --git a/arch/arm/mach-omap2/omap_l3_noc.h
b/arch/arm/mach-omap2/omap_l3_noc.h
index 22c0d57..9120e70 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.h
+++ b/arch/arm/mach-omap2/omap_l3_noc.h
@@ -1,25
[PATCH 8/8] OMAP4: Fix the emif and dmm virtual mapping
Fix the address overlap with Emulation domain (EMU). The previous mapping was entering into EMU mapping and was not as per comments. Fix the mapping accordingly. [giris...@ti.com: Helped fixing comments.] Signed-off-by: Girish S G giris...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/plat-omap/include/plat/io.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/io.h b/arch/arm/plat-omap/include/plat/io.h index d72ec85..a2f7d31 100644 --- a/arch/arm/plat-omap/include/plat/io.h +++ b/arch/arm/plat-omap/include/plat/io.h @@ -228,12 +228,12 @@ #define OMAP44XX_EMIF2_PHYSOMAP44XX_EMIF2_BASE /* 0x4d00 -- 0xfd20 */ -#define OMAP44XX_EMIF2_VIRT(OMAP44XX_EMIF2_PHYS + OMAP4_L3_PER_IO_OFFSET) +#define OMAP44XX_EMIF2_VIRT(OMAP44XX_EMIF1_VIRT + SZ_1M) #define OMAP44XX_EMIF2_SIZESZ_1M #define OMAP44XX_DMM_PHYS OMAP44XX_DMM_BASE /* 0x4e00 -- 0xfd30 */ -#define OMAP44XX_DMM_VIRT (OMAP44XX_DMM_PHYS + OMAP4_L3_PER_IO_OFFSET) +#define OMAP44XX_DMM_VIRT (OMAP44XX_EMIF2_VIRT + SZ_1M) #define OMAP44XX_DMM_SIZE SZ_1M /* * -- 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 7/8] OMAP4: clock: Add CPU local timer clock node.
Local timer clock is sourced from the CPU clock and hence changes
along with CPU clock. These per CPU local timers are used as
clock-events, so they need to be reconfigured on CPU frequency
change as part of CPUfreq governor.
Newly introduced clockevents_reconfigure() needs to know the
twd clock-rate. Provide a clock-node to make clk_get_rate() work
for TWD.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2af0e3f..8c981ab 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3091,6 +3091,14 @@ static struct clk auxclkreq5_ck = {
.recalc = omap2_clksel_recalc,
};
+static struct clk smp_twd = {
+ .name = smp_twd,
+ .parent = dpll_mpu_ck,
+ .ops= clkops_null,
+ .fixed_div = 2,
+ .recalc = omap_fixed_divisor_recalc,
+};
+
/*
* clkdev
*/
@@ -3363,6 +3371,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(usbhs-omap.0, usbhost_ick, dummy_ck,
CK_443X),
CLK(usbhs-omap.0, usbtll_fck, dummy_ck,
CK_443X),
CLK(omap_wdt, ick, dummy_ck,
CK_443X),
+ CLK(NULL, smp_twd, smp_twd,
CK_443X),
};
int __init omap4xxx_clk_init(void)
--
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 6/8] OMAP: Print Initiator name for l3 custom error.
From: sricharan r.sricha...@ti.com
The initiator id gets logged in the l3 target registers for custom error.
So print it to aid debugging.
Based on a internal patch by Devaraj Rangasamy d...@ti.com
Signed-off-by: sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_l3_noc.c | 26 --
arch/arm/mach-omap2/omap_l3_noc.h | 34 ++
2 files changed, 50 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_l3_noc.c
b/arch/arm/mach-omap2/omap_l3_noc.c
index 8f18357..07a3d3e 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.c
+++ b/arch/arm/mach-omap2/omap_l3_noc.c
@@ -56,11 +56,11 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
{
struct omap4_l3 *l3 = _l3;
- int inttype, i;
+ int inttype, i, k;
int err_src = 0;
- u32 std_err_main, err_reg, clear;
+ u32 std_err_main, err_reg, clear, masterid;
void __iomem *base, *l3_targ_base;
- char *source_name;
+ char *target_name, *master_name = UN IDENTIFIED;
/* Get the Type of interrupt */
inttype = irq == l3-app_irq ? L3_APPLICATION_ERROR : L3_DEBUG_ERROR;
@@ -83,13 +83,15 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
l3_targ_base = base + *(l3_targ[i] + err_src);
std_err_main = __raw_readl(l3_targ_base +
L3_TARG_STDERRLOG_MAIN);
+ masterid = __raw_readl(l3_targ_base +
+ L3_TARG_STDERRLOG_MSTADDR);
switch (std_err_main CUSTOM_ERROR) {
case STANDARD_ERROR:
- source_name =
+ target_name =
l3_targ_inst_name[i][err_src];
- WARN(true, L3 standard error: SOURCE:%s at
address 0x%x\n,
- source_name,
+ WARN(true, L3 standard error: TARGET:%s at
address 0x%x\n,
+ target_name,
__raw_readl(l3_targ_base +
L3_TARG_STDERRLOG_SLVOFSLSB));
/* clear the std error log*/
@@ -99,11 +101,15 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
break;
case CUSTOM_ERROR:
- source_name =
+ target_name =
l3_targ_inst_name[i][err_src];
-
- WARN(true, L3 custom error: SOURCE:%s\n,
- source_name);
+ for (k = 0; k NUM_OF_L3_MASTERS; k++) {
+ if (masterid == l3_masters[k].id)
+ master_name =
+ l3_masters[k].name;
+ }
+ WARN(true, L3 custom error: MASTER:%s
TARGET:%s\n,
+ master_name, target_name);
/* clear the std error log*/
clear = std_err_main | CLEAR_STDERR_LOG;
writel(clear, l3_targ_base +
diff --git a/arch/arm/mach-omap2/omap_l3_noc.h
b/arch/arm/mach-omap2/omap_l3_noc.h
index 74c1643..90b5098 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.h
+++ b/arch/arm/mach-omap2/omap_l3_noc.h
@@ -34,8 +34,11 @@
/* L3 TARG register offsets */
#define L3_TARG_STDERRLOG_MAIN 0x48
#define L3_TARG_STDERRLOG_SLVOFSLSB0x5c
+#define L3_TARG_STDERRLOG_MSTADDR 0x68
#define L3_FLAGMUX_REGERR0 0xc
+#define NUM_OF_L3_MASTERS (sizeof(l3_masters)/sizeof(l3_masters[0]))
+
static u32 l3_flagmux[L3_MODULES] = {
0x500,
0x1000,
@@ -76,6 +79,37 @@ static u32 l3_targ_inst_clk3[] = {
0x0100 /* EMUSS */
};
+static struct l3_masters_data {
+ u32 id;
+ char name[10];
+} l3_masters[] = {
+ { 0x0 , MPU},
+ { 0x10, CS_ADP},
+ { 0x14, xxx},
+ { 0x20, DSP},
+ { 0x30, IVAHD},
+ { 0x40, ISS},
+ { 0x44, DucatiM3},
+ { 0x48, FaceDetect},
+ { 0x50, SDMA_Rd},
+ { 0x54, SDMA_Wr},
+ { 0x58, xxx},
+ { 0x5C, xxx},
+ { 0x60, SGX},
+ { 0x70, DSS},
+ { 0x80, C2C},
+ { 0x88, xxx},
+ { 0x8C, xxx},
+ { 0x90, HSI},
+ { 0xA0, MMC1},
+ { 0xA4, MMC2},
+ { 0xA8, MMC6},
+ { 0xB0, UNIPRO1},
+ { 0xC0, USBHOSTHS},
+ { 0xC4, USBOTGHS},
+ { 0xC8, USBHOSTFS}
+};
+
static char *l3_targ_inst_name[L3_MODULES][18] = {
{
DMM1,
--
1.7.4.1
--
[PATCH 2/8] OMAP: Improve register access in L3 Error handler.
From: Todd Poynor toddpoy...@google.com
* Changed the way of accessing L3 target
registers from standard base rather
than relative to STDERRLOG_MAIN.
* Use ffs() to find error source from
the L3_FLAGMUX_REGERRn register.
* Remove extra l3_base[] entry.
* Modified L3 custom error message.
Signed-off-by: Todd Poynor toddpoy...@google.com
Signed-off-by: sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_l3_noc.c | 43 +-
arch/arm/mach-omap2/omap_l3_noc.h | 86 +---
arch/arm/mach-omap2/omap_l3_smx.c |5 +-
arch/arm/mach-omap2/omap_l3_smx.h |2 +-
4 files changed, 65 insertions(+), 71 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_l3_noc.c
b/arch/arm/mach-omap2/omap_l3_noc.c
index 7b9f190..d560c88 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.c
+++ b/arch/arm/mach-omap2/omap_l3_noc.c
@@ -56,10 +56,9 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
{
struct omap4_l3 *l3 = _l3;
- int inttype, i, j;
+ int inttype, i;
int err_src = 0;
- u32 std_err_main_addr, std_err_main, err_reg;
- u32 base, slave_addr, clear;
+ u32 std_err_main, err_reg, clear, base, l3_targ_base;
char *source_name;
/* Get the Type of interrupt */
@@ -71,42 +70,43 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
* to determine the source
*/
base = (u32)l3-l3_base[i];
- err_reg = readl(base + l3_flagmux[i] + (inttype 3));
+ err_reg = readl(base + l3_flagmux[i] +
+ + L3_FLAGMUX_REGERR0 + (inttype 3));
/* Get the corresponding error and analyse */
if (err_reg) {
/* Identify the source from control status register */
- for (j = 0; !(err_reg (1 j)); j++)
- ;
+ err_src = __ffs(err_reg);
- err_src = j;
/* Read the stderrlog_main_source from clk domain */
- std_err_main_addr = base + *(l3_targ[i] + err_src);
- std_err_main = readl(std_err_main_addr);
+ l3_targ_base = base + *(l3_targ[i] + err_src);
+ std_err_main = readl(l3_targ_base +
+ L3_TARG_STDERRLOG_MAIN);
switch (std_err_main CUSTOM_ERROR) {
case STANDARD_ERROR:
source_name =
- l3_targ_stderrlog_main_name[i][err_src];
-
- slave_addr = std_err_main_addr +
- L3_SLAVE_ADDRESS_OFFSET;
+ l3_targ_inst_name[i][err_src];
WARN(true, L3 standard error: SOURCE:%s at
address 0x%x\n,
- source_name, readl(slave_addr));
+ source_name,
+ readl(l3_targ_base +
+ L3_TARG_STDERRLOG_SLVOFSLSB));
/* clear the std error log*/
clear = std_err_main | CLEAR_STDERR_LOG;
- writel(clear, std_err_main_addr);
+ writel(clear, l3_targ_base +
+ L3_TARG_STDERRLOG_MAIN);
break;
case CUSTOM_ERROR:
source_name =
- l3_targ_stderrlog_main_name[i][err_src];
+ l3_targ_inst_name[i][err_src];
- WARN(true, CUSTOM SRESP error with
SOURCE:%s\n,
- source_name);
+ WARN(true, L3 custom error: SOURCE:%s\n,
+ source_name);
/* clear the std error log*/
clear = std_err_main | CLEAR_STDERR_LOG;
- writel(clear, std_err_main_addr);
+ writel(clear, l3_targ_base +
+ L3_TARG_STDERRLOG_MAIN);
break;
default:
@@ -123,9 +123,8 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
static int __init omap4_l3_probe(struct platform_device *pdev)
{
static struct omap4_l3 *l3;
- struct resource *res;
- int ret;
- int irq;
+ struct resource *res;
+ int ret, irq;
[PATCH 5/8] OMAP: Fix sparse warnings in l3 error handler.
From: sricharan r.sricha...@ti.com Fix below sparse warnings from the l3-noc and l3-smx error handlers files. arch/arm/mach-omap2/omap_l3_smx.h:209:22: warning: symbol 'omap3_l3_app_bases' was not declared. Should it be static? arch/arm/mach-omap2/omap_l3_smx.h:308:22: warning: symbol 'omap3_l3_debug_bases' was not declared. Should it be static? arch/arm/mach-omap2/omap_l3_smx.h:325:2: warning: incorrect type in initializer (different address spaces) arch/arm/mach-omap2/omap_l3_smx.h:325:2:expected unsigned int [usertype] * arch/arm/mach-omap2/omap_l3_smx.h:325:2:got unsigned int [noderef] [toplevel] asn:2*noident arch/arm/mach-omap2/omap_l3_smx.h:326:2: warning: incorrect type in initializer (different address spaces) arch/arm/mach-omap2/omap_l3_smx.h:326:2:expected unsigned int [usertype] * arch/arm/mach-omap2/omap_l3_smx.h:326:2:got unsigned int [noderef] [toplevel] asn:2*noident arch/arm/mach-omap2/omap_l3_smx.h:324:5: warning: symbol 'omap3_l3_bases' was not declared. Should it be static? CC arch/arm/mach-omap2/omap_l3_smx.o CHECK arch/arm/mach-omap2/omap_l3_noc.c arch/arm/mach-omap2/omap_l3_noc.c:73:13: warning: symbol '__v' shadows an earlier one arch/arm/mach-omap2/omap_l3_noc.c:73:13: originally declared here arch/arm/mach-omap2/omap_l3_noc.c:83:20: warning: symbol '__v' shadows an earlier one arch/arm/mach-omap2/omap_l3_noc.c:83:20: originally declared here arch/arm/mach-omap2/omap_l3_noc.c:90:5: warning: symbol '__v' shadows an earlier one arch/arm/mach-omap2/omap_l3_noc.c:90:5: originally declared here arch/arm/mach-omap2/omap_l3_noc.h:39:5: warning: symbol 'l3_flagmux' was not declared. Should it be static? arch/arm/mach-omap2/omap_l3_noc.h:46:5: warning: symbol 'l3_targ_inst_clk1' was not declared. Should it be static? arch/arm/mach-omap2/omap_l3_noc.h:54:5: warning: symbol 'l3_targ_inst_clk2' was not declared. Should it be static? arch/arm/mach-omap2/omap_l3_noc.h:75:5: warning: symbol 'l3_targ_inst_clk3' was not declared. Should it be static? arch/arm/mach-omap2/omap_l3_noc.h:79:6: warning: symbol 'l3_targ_inst_name' was not declared. Should it be static? arch/arm/mach-omap2/omap_l3_noc.h:112:5: warning: symbol 'l3_targ' was not declared. Should it be static? arch/arm/mach-omap2/omap_l3_noc.c:72:11: warning: cast removes address space of expression arch/arm/mach-omap2/omap_l3_noc.c:73:13: warning: incorrect type in argument 1 (different base types) arch/arm/mach-omap2/omap_l3_noc.c:73:13:expected void const volatile [noderef] asn:2*noident arch/arm/mach-omap2/omap_l3_noc.c:73:13:got unsigned int arch/arm/mach-omap2/omap_l3_noc.c:83:20: warning: incorrect type in argument 1 (different base types) arch/arm/mach-omap2/omap_l3_noc.c:83:20:expected void const volatile [noderef] asn:2*noident arch/arm/mach-omap2/omap_l3_noc.c:83:20:got unsigned int arch/arm/mach-omap2/omap_l3_noc.c:90:5: warning: incorrect type in argument 1 (different base types) arch/arm/mach-omap2/omap_l3_noc.c:90:5:expected void const volatile [noderef] asn:2*noident arch/arm/mach-omap2/omap_l3_noc.c:90:5:got unsigned int arch/arm/mach-omap2/omap_l3_noc.c:96:5: warning: incorrect type in argument 1 (different base types) arch/arm/mach-omap2/omap_l3_noc.c:96:5:expected void const volatile [noderef] asn:2*noident arch/arm/mach-omap2/omap_l3_noc.c:96:5:got unsigned int arch/arm/mach-omap2/omap_l3_noc.c:108:5: warning: incorrect type in argument 1 (different base types) arch/arm/mach-omap2/omap_l3_noc.c:108:5:expected void const volatile [noderef] asn:2*noident arch/arm/mach-omap2/omap_l3_noc.c:108:5:got unsigned int Signed-off-by: sricharan r.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Reported-by: Paul Walmsley p...@pwsan.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/omap_l3_noc.c | 11 ++- arch/arm/mach-omap2/omap_l3_noc.h | 12 ++-- arch/arm/mach-omap2/omap_l3_smx.h |6 +++--- 3 files changed, 15 insertions(+), 14 deletions(-) diff --git a/arch/arm/mach-omap2/omap_l3_noc.c b/arch/arm/mach-omap2/omap_l3_noc.c index 1f68e95..8f18357 100644 --- a/arch/arm/mach-omap2/omap_l3_noc.c +++ b/arch/arm/mach-omap2/omap_l3_noc.c @@ -58,7 +58,8 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3) struct omap4_l3 *l3 = _l3; int inttype, i; int err_src = 0; - u32 std_err_main, err_reg, clear, base, l3_targ_base; + u32 std_err_main, err_reg, clear; + void __iomem *base, *l3_targ_base; char *source_name; /* Get the Type of interrupt */ @@ -69,8 +70,8 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3) * Read the regerr register of the clock domain * to determine the source */ - base = (u32)l3-l3_base[i]; - err_reg = readl(base + l3_flagmux[i] + + base = l3-l3_base[i]; + err_reg =
Re: [alsa-devel] [PATCH v2] ASoC: omap: add MODULE_ALIAS to mcbsp and pcm drivers
On 09/07/2011 08:10 PM, Mark Brown wrote: On Wed, Sep 07, 2011 at 12:07:21PM +0100, Mans Rullgard wrote: This adds MODULE_ALIAS directives to the omap-mcbsp-dai and omap-pcm-audio drivers so they can be auto-loaded when platform devices are scanned. Acked-by: Mark Brownbroo...@opensource.wolfsonmicro.com Now looks good. Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
