Re: [PATCH v16 10/12] OMAP: dmtimer: extend spinlock in request functions
On Thu, Sep 22, 2011 at 6:12 AM, Tony Lindgren t...@atomide.com wrote: * Tarun Kanti DebBarma tarun.ka...@ti.com [110920 03:57]: The request functions now verify the success of omap_dm_timer_prepare() call after a timer is acquired. If *_prepare() fails then we have to release the timer. In order to avoid race condition during this time, include *_prepare() within lock. This I've folded into patch 5. That should be fine. -- Tarun Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v16 08/12] OMAP: dmtimer: do remaining initialization in probe
On Thu, Sep 22, 2011 at 6:30 AM, Tony Lindgren t...@atomide.com wrote:
* Tarun Kanti DebBarma tarun.ka...@ti.com [110920 03:57]:
@@ -514,10 +514,23 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-irq = irq-start;
timer-pdev = pdev;
- /* Skip pm_runtime_enable for OMAP1 */
- if (!pdata-needs_manual_reset) {
- pm_runtime_enable(pdev-dev);
- pm_runtime_irq_safe(pdev-dev);
+/*
+ * sys_timer_reserved is not defined for OMAP1.
+ * Use the macro to avoid compilation error on OMAP1.
+ */
+#if defined(CONFIG_ARCH_OMAP2PLUS)
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_irq_safe(pdev-dev);
+ /* Mark clocksource and clockevent timers as reserved */
+ if ((sys_timer_reserved (pdev-id - 1)) 0x1)
+ timer-reserved = 1;
+#endif
+
+ if (!timer-reserved) {
+ pm_runtime_get_sync(pdev-dev);
+ __omap_dm_timer_init_regs(timer);
+ timer-tidr = __raw_readl(timer-io_base);
+ pm_runtime_put(pdev-dev);
}
/* add the timer element to the list */
This all should not be necessary. We can pass the reserved flag
in pdata. Let's replace this one with the patch below.
Yes, this is much better organized.
--
Tarun
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Wed, 21 Sep 2011 16:38:51 -0700
Subject: [PATCH] ARM: OMAP: dmtimer: skip reserved timers
Pass the reserved flag in pdata and use it. We can
now make sys_timer_reserved static to mach-omap2/timer.c.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 9c2f588..f1e3ec1 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -69,7 +69,7 @@
/* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
#define MAX_GPTIMER_ID 12
-u32 sys_timer_reserved;
+static u32 sys_timer_reserved;
/* Clockevent code */
@@ -463,6 +463,10 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
pdata-set_timer_src = omap2_dm_timer_set_src;
pdata-timer_ip_version = oh-class-rev;
+ /* Mark clocksource and clockevent timers as reserved */
+ if ((sys_timer_reserved (id - 1)) 0x1)
+ pdata-reserved = 1;
+
od = omap_device_build(name, id, oh, pdata, sizeof(*pdata),
omap2_dmtimer_latency,
ARRAY_SIZE(omap2_dmtimer_latency),
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index ac904c2..c8df3c3 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -509,6 +509,7 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-id = pdev-id;
timer-irq = irq-start;
+ timer-reserved = pdata-reserved;
timer-pdev = pdev;
/* Skip pm_runtime_enable for OMAP1 */
@@ -517,6 +518,12 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
pm_runtime_irq_safe(pdev-dev);
}
+ if (!timer-reserved) {
+ pm_runtime_get_sync(pdev-dev);
+ __omap_dm_timer_init_regs(timer);
+ pm_runtime_put(pdev-dev);
+ }
+
/* add the timer element to the list */
spin_lock_irqsave(dm_timer_lock, flags);
list_add_tail(timer-node, omap_timer_list);
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 4e3a326..29764c3 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -77,6 +77,7 @@ struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
int timer_ip_version;
u32 needs_manual_reset:1;
+ bool reserved;
};
struct omap_dm_timer *omap_dm_timer_request(void);
@@ -248,7 +249,6 @@ struct omap_dm_timer {
struct list_head node;
};
-extern u32 sys_timer_reserved;
int omap_dm_timer_prepare(struct omap_dm_timer *timer);
static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg,
--
To unsubscribe from this list: send the line unsubscribe 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 v16 00/12] OMAP: dmtimer: adaptation to platform_driver
On Thu, Sep 22, 2011 at 6:29 AM, Tony Lindgren t...@atomide.com wrote: Hi Tarun, * Tarun Kanti DebBarma tarun.ka...@ti.com [110920 03:57]: Adaptation of dmtimer code to platform driver using omap_device and omap_hwmod abstraction. It also include pm-runtime and off-mode support. I've applied these into dmtimer branch with some changes to simplify things further. I've also merged it into linux-omap master branch for further testing. I'll reply to your patches with the changes I've done. Care give the dmtimer branch a try and see if I've missed something? Sure, I will go through the changes and do testing on it. -- Tarun Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr
Hi,
On Wednesday 21 September 2011 07:04 PM, Hiremath, Vaibhav wrote:
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 3:31 PM
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux-
me...@vger.kernel.org; Taneja, Archit
Subject: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in
omap_vout_isr
Currently, in omap_vout_isr(), if the panel type is DPI, and if we
get either VSYNC or VSYNC2 interrupts, we proceed ahead to set the
current buffers state to VIDEOBUF_DONE and prepare to display the
next frame in the queue.
On OMAP4, because we have 2 LCD managers, the panel type itself is not
sufficient to tell if we have received the correct irq, i.e, we shouldn't
proceed ahead if we get a VSYNC interrupt for LCD2 manager, or a VSYNC2
interrupt for LCD manager.
Fix this by correlating LCD manager to VSYNC interrupt and LCD2 manager
to VSYNC2 interrupt.
Signed-off-by: Archit Tanejaarc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index c5f2ea0..20638c3 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -566,8 +566,8 @@ err:
static void omap_vout_isr(void *arg, unsigned int irqstatus)
{
- int ret, fid;
- u32 addr;
+ int ret, fid, mgr_id;
+ u32 addr, irq;
struct omap_overlay *ovl;
struct timeval timevalue;
struct omapvideo_info *ovid;
@@ -583,6 +583,7 @@ static void omap_vout_isr(void *arg, unsigned int
irqstatus)
if (!ovl-manager || !ovl-manager-device)
return;
+ mgr_id = ovl-manager-id;
cur_display = ovl-manager-device;
spin_lock(vout-vbq_lock);
@@ -590,7 +591,14 @@ static void omap_vout_isr(void *arg, unsigned int
irqstatus)
switch (cur_display-type) {
case OMAP_DISPLAY_TYPE_DPI:
- if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
+ if (mgr_id == OMAP_DSS_CHANNEL_LCD)
+ irq = DISPC_IRQ_VSYNC;
+ else if (mgr_id == OMAP_DSS_CHANNEL_LCD2)
+ irq = DISPC_IRQ_VSYNC2;
+ else
+ goto vout_isr_err;
+
+ if (!(irqstatus irq))
goto vout_isr_err;
break;
I understand what this patch meant for, but I am more curious to know
What is value addition of this patch?
if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
Vs
if (mgr_id == OMAP_DSS_CHANNEL_LCD)
irq = DISPC_IRQ_VSYNC;
else if (mgr_id == OMAP_DSS_CHANNEL_LCD2)
irq = DISPC_IRQ_VSYNC2;
Isn't this same, because we are not doing anything separate and special
for VSYNC and VSYNC2?
Consider a use case where the primary LCD panel(connected to LCD
manager) is configured at a 60 Hz refresh rate, and the secondary
panel(connected to LCD2) refreshes at 30 Hz. Let the overlay
configuration be something like this:
/dev/video1-overlay1-LCD manager-Primary panel(60 Hz)
/dev/video2-overlay2-LCD2 manager-Secondary Panel(30 Hz)
Now if we are doing streaming on both video1 and video2, since we deque
on either VSYNC or VSYNC2, video2 buffers will deque faster than the
panels refresh, which is incorrect. So for video2, we should only deque
when we get a VSYNC2 interrupt. Thats why there is a need to correlate
the interrupt and the overlay manager.
Regards,
Archit
Thanks,
Vaibhav
case OMAP_DISPLAY_TYPE_VENC:
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v16 09/12] OMAP: dmtimer: low-power mode support
On Thu, Sep 22, 2011 at 6:30 AM, Tony Lindgren t...@atomide.com wrote:
* Tarun Kanti DebBarma tarun.ka...@ti.com [110920 03:57]:
Clock is enabled only when timer is started and disabled when the the timer
is stopped. Therefore before accessing registers in functions clock is
enabled
and then disabled back at the end of access. Context save is done dynamically
whenever the registers are modified. Context restore is called when context
is
lost.
I've updated this to use revision instead of tidr. Updated patch below.
Ok.
--
Tarun
Regards,
Tony
From: Tarun Kanti DebBarma tarun.ka...@ti.com
Date: Tue, 20 Sep 2011 17:00:24 +0530
Subject: [PATCH] ARM: OMAP: dmtimer: low-power mode support
Clock is enabled only when timer is started and disabled when the the timer
is stopped. Therefore before accessing registers in functions clock is enabled
and then disabled back at the end of access. Context save is done dynamically
whenever the registers are modified. Context restore is called when context is
lost.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
[t...@atomide.com: updated to use revision instead of tidr]
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index f1e3ec1..1140e98 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -44,6 +44,9 @@
#include plat/common.h
#include plat/omap_hwmod.h
#include plat/omap_device.h
+#include plat/omap-pm.h
+
+#include powerdomain.h
/* Parent clocks, eventually these will come from the clock framework */
@@ -433,6 +436,7 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
struct dmtimer_platform_data *pdata;
struct omap_device *od;
struct omap_timer_capability_dev_attr *timer_dev_attr;
+ struct powerdomain *pwrdm;
pr_debug(%s: %s\n, __func__, oh-name);
@@ -467,6 +471,11 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
if ((sys_timer_reserved (id - 1)) 0x1)
pdata-reserved = 1;
+ pwrdm = omap_hwmod_get_pwrdm(oh);
+ pdata-loses_context = pwrdm_can_ever_lose_context(pwrdm);
+#ifdef CONFIG_PM
+ pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
+#endif
od = omap_device_build(name, id, oh, pdata, sizeof(*pdata),
omap2_dmtimer_latency,
ARRAY_SIZE(omap2_dmtimer_latency),
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index c8df3c3..43eb750 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -77,6 +77,29 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer
*timer, u32 reg,
__omap_dm_timer_write(timer, reg, value, timer-posted);
}
+static void omap_timer_restore_context(struct omap_dm_timer *timer)
+{
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_OCP_CFG_OFFSET,
+ timer-context.tiocp_cfg);
+ if (timer-revision 1)
+ __raw_writel(timer-context.tistat, timer-sys_stat);
+
+ __raw_writel(timer-context.tisr, timer-irq_stat);
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_WAKEUP_EN_REG,
+ timer-context.twer);
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_COUNTER_REG,
+ timer-context.tcrr);
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_LOAD_REG,
+ timer-context.tldr);
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_MATCH_REG,
+ timer-context.tmar);
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG,
+ timer-context.tsicr);
+ __raw_writel(timer-context.tier, timer-irq_ena);
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG,
+ timer-context.tclr);
+}
+
static void omap_dm_timer_wait_for_reset(struct omap_dm_timer *timer)
{
int c;
@@ -96,12 +119,14 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer *timer)
static void omap_dm_timer_reset(struct omap_dm_timer *timer)
{
+ omap_dm_timer_enable(timer);
if (timer-pdev-id != 1) {
omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
omap_dm_timer_wait_for_reset(timer);
}
__omap_dm_timer_reset(timer, 0, 0);
+ omap_dm_timer_disable(timer);
timer-posted = 1;
}
@@ -117,8 +142,6 @@ int omap_dm_timer_prepare(struct omap_dm_timer *timer)
return -EINVAL;
}
- omap_dm_timer_enable(timer);
-
if (pdata-needs_manual_reset)
omap_dm_timer_reset(timer);
@@ -193,7 +216,6 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_request_specific);
void omap_dm_timer_free(struct omap_dm_timer *timer)
{
-
Re: [PATCH v5 09/15] OMAP2+: UART: Add runtime pm support for omap-serial driver
Hi,
On Wed, Sep 21, 2011 at 8:13 PM, Govindraj.R govindraj.r...@ti.com wrote:
Adapts omap-serial driver to use pm_runtime API's.
console_unlock();
- if ((cpu_is_omap34xx() bdata-pads) ||
- (pdata-wk_en pdata-wk_mask))
+ if ((cpu_is_omap34xx() bdata-pads))
device_init_wakeup(pdev-dev, true);
Just a bit curious, why doesn't the code enable wakeup at default
on omap4, which will disable runtime pm of serial port on omap4.
I have tested your patches on omap4 panda(enable wakeup at
default manually), runtime pm of serial port 2 can work well and
remote wakeup too.
kfree(pdata);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 74822b3..8ef81ce 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -62,6 +62,9 @@ struct omap_uart_port_info {
upf_t flags; /* UPF_* flags */
u32 errata;
+
+ void (*enable_wakeup)(struct platform_device *, bool);
+ u32 (*get_context_loss_count)(struct device *);
};
struct uart_omap_dma {
@@ -113,6 +116,8 @@ struct uart_omap_port {
unsigned char msr_saved_flags;
char name[20];
unsigned long port_activity;
+ u32 context_loss_cnt;
+ u8 wakeups_enabled;
};
#endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 9a0eac2..43c33da 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -37,11 +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
+#define OMAP_UART_AUTOSUSPEND_DELAY -1
+
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
@@ -102,6 +105,8 @@ static void serial_omap_stop_rxdma(struct uart_omap_port
*up)
omap_free_dma(up-uart_dma.rx_dma_channel);
up-uart_dma.rx_dma_channel = OMAP_UART_DMA_CH_FREE;
up-uart_dma.rx_dma_used = false;
+ pm_runtime_mark_last_busy(up-pdev-dev);
+ pm_runtime_put_autosuspend(up-pdev-dev);
}
}
@@ -110,8 +115,11 @@ static void serial_omap_enable_ms(struct uart_port *port)
struct uart_omap_port *up = (struct uart_omap_port *)port;
dev_dbg(up-port.dev, serial_omap_enable_ms+%d\n, up-pdev-id);
+
+ pm_runtime_get_sync(up-pdev-dev);
up-ier |= UART_IER_MSI;
serial_out(up, UART_IER, up-ier);
+ pm_runtime_put(up-pdev-dev);
}
static void serial_omap_stop_tx(struct uart_port *port)
@@ -129,23 +137,32 @@ static void serial_omap_stop_tx(struct uart_port *port)
omap_stop_dma(up-uart_dma.tx_dma_channel);
omap_free_dma(up-uart_dma.tx_dma_channel);
up-uart_dma.tx_dma_channel = OMAP_UART_DMA_CH_FREE;
+ pm_runtime_mark_last_busy(up-pdev-dev);
+ pm_runtime_put_autosuspend(up-pdev-dev);
}
+ pm_runtime_get_sync(up-pdev-dev);
if (up-ier UART_IER_THRI) {
up-ier = ~UART_IER_THRI;
serial_out(up, UART_IER, up-ier);
}
+
+ pm_runtime_mark_last_busy(up-pdev-dev);
+ pm_runtime_put_autosuspend(up-pdev-dev);
}
static void serial_omap_stop_rx(struct uart_port *port)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
+ pm_runtime_get_sync(up-pdev-dev);
if (up-use_dma)
serial_omap_stop_rxdma(up);
up-ier = ~UART_IER_RLSI;
up-port.read_status_mask = ~UART_LSR_DR;
serial_out(up, UART_IER, up-ier);
+ pm_runtime_mark_last_busy(up-pdev-dev);
+ pm_runtime_put_autosuspend(up-pdev-dev);
}
static inline void receive_chars(struct uart_omap_port *up, int *status)
@@ -262,7 +279,10 @@ static void serial_omap_start_tx(struct uart_port *port)
int ret = 0;
if (!up-use_dma) {
+ pm_runtime_get_sync(up-pdev-dev);
serial_omap_enable_ier_thri(up);
+ pm_runtime_mark_last_busy(up-pdev-dev);
+ pm_runtime_put_autosuspend(up-pdev-dev);
return;
}
@@ -272,6 +292,7 @@ static void serial_omap_start_tx(struct uart_port *port)
xmit = up-port.state-xmit;
if (up-uart_dma.tx_dma_channel == OMAP_UART_DMA_CH_FREE) {
+ pm_runtime_get_sync(up-pdev-dev);
ret = omap_request_dma(up-uart_dma.uart_dma_tx,
UART Tx DMA,
(void *)uart_tx_dma_callback, up,
@@ -354,9 +375,13 @@ static inline irqreturn_t serial_omap_irq(int irq, void
Re: [PATCH v5 09/15] OMAP2+: UART: Add runtime pm support for omap-serial driver
On Thu, Sep 22, 2011 at 1:18 PM, Ming Lei tom.leim...@gmail.com wrote: Hi, On Wed, Sep 21, 2011 at 8:13 PM, Govindraj.R govindraj.r...@ti.com wrote: Adapts omap-serial driver to use pm_runtime API's. console_unlock(); - if ((cpu_is_omap34xx() bdata-pads) || - (pdata-wk_en pdata-wk_mask)) + if ((cpu_is_omap34xx() bdata-pads)) device_init_wakeup(pdev-dev, true); Just a bit curious, why doesn't the code enable wakeup at default on omap4, which will disable runtime pm of serial port on omap4. yes sure will add for omap4. I have tested your patches on omap4 panda(enable wakeup at default manually), runtime pm of serial port 2 can work well and remote wakeup too. Thanks, for testing. -- Govindraj.R -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] OMAPDSS: HDMI: Move the comments in avi infoframe
From: Mythri P K mythr...@ti.com
Move the comments in AVI infoframe structure above each parameter
to align with other comments in the header file
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 34 ++--
1 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 929de88..de1e199 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -455,40 +455,40 @@ struct hdmi_core_video_config {
* details about infoframe databytes
*/
struct hdmi_core_infoframe_avi {
+ /* Y0, Y1 rgb,yCbCr */
u8 db1_format;
- /* Y0, Y1 rgb,yCbCr */
+ /* A0 Active information Present */
u8 db1_active_info;
- /* A0 Active information Present */
+ /* B0, B1 Bar info data valid */
u8 db1_bar_info_dv;
- /* B0, B1 Bar info data valid */
+ /* S0, S1 scan information */
u8 db1_scan_info;
- /* S0, S1 scan information */
+ /* C0, C1 colorimetry */
u8 db2_colorimetry;
- /* C0, C1 colorimetry */
+ /* M0, M1 Aspect ratio (4:3, 16:9) */
u8 db2_aspect_ratio;
- /* M0, M1 Aspect ratio (4:3, 16:9) */
+ /* R0...R3 Active format aspect ratio */
u8 db2_active_fmt_ar;
- /* R0...R3 Active format aspect ratio */
+ /* ITC IT content. */
u8 db3_itc;
- /* ITC IT content. */
+ /* EC0, EC1, EC2 Extended colorimetry */
u8 db3_ec;
- /* EC0, EC1, EC2 Extended colorimetry */
+ /* Q1, Q0 Quantization range */
u8 db3_q_range;
- /* Q1, Q0 Quantization range */
+ /* SC1, SC0 Non-uniform picture scaling */
u8 db3_nup_scaling;
- /* SC1, SC0 Non-uniform picture scaling */
+ /* VIC0..6 Video format identification */
u8 db4_videocode;
- /* VIC0..6 Video format identification */
+ /* PR0..PR3 Pixel repetition factor */
u8 db5_pixel_repeat;
- /* PR0..PR3 Pixel repetition factor */
+ /* Line number end of top bar */
u16 db6_7_line_eoftop;
- /* Line number end of top bar */
+ /* Line number start of bottom bar */
u16 db8_9_line_sofbottom;
- /* Line number start of bottom bar */
+ /* Pixel number end of left bar */
u16 db10_11_pixel_eofleft;
- /* Pixel number end of left bar */
+ /* Pixel number start of right bar */
u16 db12_13_pixel_sofright;
- /* Pixel number start of right bar */
};
/*
* Refer to section 8.2 in HDMI 1.3 specification for
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] OMAPDSS: HDMI: Replace hdmi_reg struct with u16
From: Mythri P K mythr...@ti.com
Remove usage of hdmi_reg struct to use u16 instead in the
HDMI IP header file.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 10 +-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 262 ++---
2 files changed, 134 insertions(+), 138 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index da7fe50..5f22d2e 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -32,15 +32,15 @@
#include dss.h
static inline void hdmi_write_reg(void __iomem *base_addr,
- const struct hdmi_reg idx, u32 val)
+ const u16 idx, u32 val)
{
- __raw_writel(val, base_addr + idx.idx);
+ __raw_writel(val, base_addr + idx);
}
static inline u32 hdmi_read_reg(void __iomem *base_addr,
- const struct hdmi_reg idx)
+ const u16 idx)
{
- return __raw_readl(base_addr + idx.idx);
+ return __raw_readl(base_addr + idx);
}
static inline void __iomem *hdmi_wp_base(struct hdmi_ip_data *ip_data)
@@ -69,7 +69,7 @@ static inline void __iomem *hdmi_core_sys_base(struct
hdmi_ip_data *ip_data)
}
static inline int hdmi_wait_for_bit_change(void __iomem *base_addr,
- const struct hdmi_reg idx,
+ const u16 idx,
int b2, int b1, u32 val)
{
u32 t = 0;
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index de1e199..694888a 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -30,142 +30,138 @@
#include sound/pcm_params.h
#endif
-struct hdmi_reg { u16 idx; };
-
-#define HDMI_REG(idx) ((const struct hdmi_reg) { idx })
-
/* HDMI Wrapper */
-#define HDMI_WP_REVISION HDMI_REG(0x0)
-#define HDMI_WP_SYSCONFIG HDMI_REG(0x10)
-#define HDMI_WP_IRQSTATUS_RAW HDMI_REG(0x24)
-#define HDMI_WP_IRQSTATUS HDMI_REG(0x28)
-#define HDMI_WP_PWR_CTRL HDMI_REG(0x40)
-#define HDMI_WP_IRQENABLE_SET HDMI_REG(0x2C)
-#define HDMI_WP_VIDEO_CFG HDMI_REG(0x50)
-#define HDMI_WP_VIDEO_SIZE HDMI_REG(0x60)
-#define HDMI_WP_VIDEO_TIMING_H HDMI_REG(0x68)
-#define HDMI_WP_VIDEO_TIMING_V HDMI_REG(0x6C)
-#define HDMI_WP_WP_CLK HDMI_REG(0x70)
-#define HDMI_WP_AUDIO_CFG HDMI_REG(0x80)
-#define HDMI_WP_AUDIO_CFG2 HDMI_REG(0x84)
-#define HDMI_WP_AUDIO_CTRL HDMI_REG(0x88)
-#define HDMI_WP_AUDIO_DATA HDMI_REG(0x8C)
+#define HDMI_WP_REVISION 0x0
+#define HDMI_WP_SYSCONFIG 0x10
+#define HDMI_WP_IRQSTATUS_RAW 0x24
+#define HDMI_WP_IRQSTATUS 0x28
+#define HDMI_WP_PWR_CTRL 0x40
+#define HDMI_WP_IRQENABLE_SET 0x2C
+#define HDMI_WP_VIDEO_CFG 0x50
+#define HDMI_WP_VIDEO_SIZE 0x60
+#define HDMI_WP_VIDEO_TIMING_H 0x68
+#define HDMI_WP_VIDEO_TIMING_V 0x6C
+#define HDMI_WP_WP_CLK 0x70
+#define HDMI_WP_AUDIO_CFG 0x80
+#define HDMI_WP_AUDIO_CFG2 0x84
+#define HDMI_WP_AUDIO_CTRL 0x88
+#define HDMI_WP_AUDIO_DATA 0x8C
/* HDMI IP Core System */
-#define HDMI_CORE_SYS_VND_IDL HDMI_REG(0x0)
-#define HDMI_CORE_SYS_DEV_IDL HDMI_REG(0x8)
-#define HDMI_CORE_SYS_DEV_IDH HDMI_REG(0xC)
-#define HDMI_CORE_SYS_DEV_REV HDMI_REG(0x10)
-#define HDMI_CORE_SYS_SRST HDMI_REG(0x14)
-#define HDMI_CORE_CTRL1HDMI_REG(0x20)
-#define HDMI_CORE_SYS_SYS_STAT HDMI_REG(0x24)
-#define HDMI_CORE_SYS_VID_ACEN HDMI_REG(0x124)
-#define HDMI_CORE_SYS_VID_MODE HDMI_REG(0x128)
-#define HDMI_CORE_SYS_INTR_STATE HDMI_REG(0x1C0)
-#define HDMI_CORE_SYS_INTR1HDMI_REG(0x1C4)
-#define HDMI_CORE_SYS_INTR2HDMI_REG(0x1C8)
-#define HDMI_CORE_SYS_INTR3HDMI_REG(0x1CC)
-#define HDMI_CORE_SYS_INTR4HDMI_REG(0x1D0)
-#define HDMI_CORE_SYS_UMASK1 HDMI_REG(0x1D4)
-#define HDMI_CORE_SYS_TMDS_CTRLHDMI_REG(0x208)
-#define HDMI_CORE_SYS_DE_DLY HDMI_REG(0xC8)
-#define HDMI_CORE_SYS_DE_CTRL HDMI_REG(0xCC)
-#define HDMI_CORE_SYS_DE_TOP HDMI_REG(0xD0)
[PATCH v2 3/5] OMAPDSS: HDMI: Add missing register definitions
From: Mythri P K mythr...@ti.com Add some of the missing register definitions, which are h/w indexable. Signed-off-by: Mythri P K mythr...@ti.com --- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h index 694888a..2040956 100644 --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h +++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h @@ -100,15 +100,15 @@ #define HDMI_CORE_AV_AVI_CHSUM 0x10C #define HDMI_CORE_AV_AVI_DBYTE(n) (n * 4 + 0x110) #define HDMI_CORE_AV_AVI_DBYTE_NELEMS 15 -#define HDMI_CORE_AV_SPD_DBYTE 0x190 +#define HDMI_CORE_AV_SPD_DBYTE(n) (n * 4 + 0x190) #define HDMI_CORE_AV_SPD_DBYTE_NELEMS 27 #define HDMI_CORE_AV_AUD_DBYTE(n) (n * 4 + 0x210) #define HDMI_CORE_AV_AUD_DBYTE_NELEMS 10 -#define HDMI_CORE_AV_MPEG_DBYTE0x290 +#define HDMI_CORE_AV_MPEG_DBYTE(n) (n * 4 + 0x290) #define HDMI_CORE_AV_MPEG_DBYTE_NELEMS 27 -#define HDMI_CORE_AV_GEN_DBYTE 0x300 +#define HDMI_CORE_AV_GEN_DBYTE(n) (n * 4 + 0x300) #define HDMI_CORE_AV_GEN_DBYTE_NELEMS 31 -#define HDMI_CORE_AV_GEN2_DBYTE0x380 +#define HDMI_CORE_AV_GEN2_DBYTE(n) (n * 4 + 0x380) #define HDMI_CORE_AV_GEN2_DBYTE_NELEMS 31 #define HDMI_CORE_AV_ACR_CTRL 0x4 #define HDMI_CORE_AV_FREQ_SVAL 0x8 -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] OMAPDSS: HDMI: Add support to dump clocks through
From: Mythri P K mythr...@ti.com
Add support to dump the HDMI regm, regn, and other clock parameters.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dss.c |3 +++
drivers/video/omap2/dss/dss.h |1 +
drivers/video/omap2/dss/hdmi.c | 35 +++
3 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 3e09726..76e2bcd 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -732,6 +732,9 @@ void dss_debug_dump_clocks(struct seq_file *s)
#ifdef CONFIG_OMAP2_DSS_DSI
dsi_dump_clocks(s);
#endif
+#ifdef CONFIG_OMAP4_DSS_HDMI
+ hdmi_dump_clocks(s);
+#endif
}
#endif
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 8652007..ef8770a 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -473,6 +473,7 @@ void hdmi_uninit_platform_driver(void);
int hdmi_init_display(struct omap_dss_device *dssdev);
unsigned long hdmi_get_pixel_clock(void);
void hdmi_dump_regs(struct seq_file *s);
+void hdmi_dump_clocks(struct seq_file *s);
#else
static inline int hdmi_init_display(struct omap_dss_device *dssdev)
{
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 3262f0f..8930998 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -33,6 +33,8 @@
#include linux/pm_runtime.h
#include linux/clk.h
#include video/omapdss.h
+#include linux/seq_file.h
+
#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
#include sound/soc.h
@@ -454,6 +456,39 @@ void hdmi_dump_regs(struct seq_file *s)
mutex_unlock(hdmi.lock);
}
+void hdmi_dump_clocks(struct seq_file *s)
+{
+ enum omap_dss_clk_source dispc_clk_src;
+
+ dispc_clk_src = dss_get_dispc_clk_source();
+
+ if (hdmi_runtime_get())
+ return;
+
+ seq_printf(s, - HDMI PLL -\n);
+
+ seq_printf(s, regm\t%u\n, hdmi.ip_data.pll_data.regm);
+
+ seq_printf(s, regmf\t%u\n, hdmi.ip_data.pll_data.regmf);
+
+ seq_printf(s, dcofreq\t%u\n, hdmi.ip_data.pll_data.dcofreq);
+
+ seq_printf(s, regsd\t%u\n, hdmi.ip_data.pll_data.regsd);
+
+ seq_printf(s, DISPC clock source %s (%s)\t(%s)\n,
+ dss_get_generic_clk_source_name(dispc_clk_src),
+ dss_feat_get_clk_source_name(dispc_clk_src),
+ dispc_clk_src == OMAP_DSS_CLK_SRC_FCK ?
+ off : on);
+
+ seq_printf(s, hdmi %s source rate = %lu\n,
+ hdmi.ip_data.pll_data.refsel == HDMI_REFSEL_SYSCLK ?
+ sysclk : pclk/ref1/ref2,
+ clk_get_rate(hdmi.sys_clk));
+
+ hdmi_runtime_put();
+}
+
int omapdss_hdmi_read_edid(u8 *buf, int len)
{
int r;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] OMAPDSS: HDMI: Add support to dump registers through
From: Mythri P K mythr...@ti.com
Add support to dump the HDMI wrapper ,core, PLL and PHY registers
through debugfs
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/core.c|4 +
drivers/video/omap2/dss/dss.h |1 +
drivers/video/omap2/dss/dss_features.c|5 +
drivers/video/omap2/dss/hdmi.c| 16 +++
drivers/video/omap2/dss/ti_hdmi.h | 14 +++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 173 +
6 files changed, 213 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 76821fe..86ec12e 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -145,6 +145,10 @@ static int dss_initialize_debugfs(void)
debugfs_create_file(venc, S_IRUGO, dss_debugfs_dir,
venc_dump_regs, dss_debug_fops);
#endif
+#ifdef CONFIG_OMAP4_DSS_HDMI
+ debugfs_create_file(hdmi, S_IRUGO, dss_debugfs_dir,
+ hdmi_dump_regs, dss_debug_fops);
+#endif
return 0;
}
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 47eebd8..8652007 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -472,6 +472,7 @@ int hdmi_init_platform_driver(void);
void hdmi_uninit_platform_driver(void);
int hdmi_init_display(struct omap_dss_device *dssdev);
unsigned long hdmi_get_pixel_clock(void);
+void hdmi_dump_regs(struct seq_file *s);
#else
static inline int hdmi_init_display(struct omap_dss_device *dssdev)
{
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 47e66d8..a2fc8e0 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -447,6 +447,11 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions = {
.pll_enable = ti_hdmi_4xxx_pll_enable,
.pll_disable= ti_hdmi_4xxx_pll_disable,
.video_enable = ti_hdmi_4xxx_wp_video_start,
+ .dump_wrapper = ti_hdmi_4xxx_wp_dump,
+ .dump_core = ti_hdmi_4xxx_core_dump,
+ .dump_pll = ti_hdmi_4xxx_pll_dump,
+ .dump_phy = ti_hdmi_4xxx_phy_dump,
+
};
void dss_init_hdmi_ip_ops(struct hdmi_ip_data *ip_data)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 2f554ae..3262f0f 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -438,6 +438,22 @@ void omapdss_hdmi_display_set_timing(struct
omap_dss_device *dssdev)
}
}
+void hdmi_dump_regs(struct seq_file *s)
+{
+ mutex_lock(hdmi.lock);
+
+ if (hdmi_runtime_get())
+ return;
+
+ hdmi.ip_data.ops-dump_wrapper(hdmi.ip_data, s);
+ hdmi.ip_data.ops-dump_pll(hdmi.ip_data, s);
+ hdmi.ip_data.ops-dump_phy(hdmi.ip_data, s);
+ hdmi.ip_data.ops-dump_core(hdmi.ip_data, s);
+
+ hdmi_runtime_put();
+ mutex_unlock(hdmi.lock);
+}
+
int omapdss_hdmi_read_edid(u8 *buf, int len)
{
int r;
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index d48603c..2c3443d 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -101,6 +101,15 @@ struct ti_hdmi_ip_ops {
void (*pll_disable)(struct hdmi_ip_data *ip_data);
void (*video_enable)(struct hdmi_ip_data *ip_data, bool start);
+
+ void (*dump_wrapper)(struct hdmi_ip_data *ip_data, struct seq_file *s);
+
+ void (*dump_core)(struct hdmi_ip_data *ip_data, struct seq_file *s);
+
+ void (*dump_pll)(struct hdmi_ip_data *ip_data, struct seq_file *s);
+
+ void (*dump_phy)(struct hdmi_ip_data *ip_data, struct seq_file *s);
+
};
struct hdmi_ip_data {
@@ -121,4 +130,9 @@ void ti_hdmi_4xxx_wp_video_start(struct hdmi_ip_data
*ip_data, bool start);
int ti_hdmi_4xxx_pll_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_pll_disable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data *ip_data);
+void ti_hdmi_4xxx_wp_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
+void ti_hdmi_4xxx_pll_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
+void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
+void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
+
#endif
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 5f22d2e..e1a6ce5 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -27,6 +27,7 @@
#include linux/mutex.h
#include linux/delay.h
#include linux/string.h
+#include linux/seq_file.h
#include ti_hdmi_4xxx_ip.h
#include dss.h
@@ -805,6 +806,178 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
[RFC PATCH V6 0/4] cpuidle: Global registration of idle states with per-cpu statistics
The following patch series implements global registration of cpuidle states, and also has the necessary data structure changes to accommodate the per-cpu writable members of the cpuidle_states structure. This patch series had been in discussion earlier and following are the links to the previous discussions. v1 -- https://lkml.org/lkml/2011/3/22/161 v2 -- https://lkml.org/lkml/2011/1/13/98 v3 -- https://lkml.org/lkml/2011/2/8/73 v4 -- https://lkml.org/lkml/2011/4/28/312 v5 -- https://lkml.org/lkml/2011/6/6/259 Changes from previous version (V5): Rebased the series to 3.1-rc7 Tests done: 1. Compile tested for ARM using the following configs: da8xx_omapl_defconfig, exynos4_defconfig, kirkwood_defconfig, omap2plus_defconfig, at91rm9200_defconfig 2. Boot tested on x86 nehalem with multiple C-states for both intel_idle and acpi_idle drivers. 3. Boot tested on T60p thinkpad that has T2600 cpu with multiple C-states. Also tested the case when there is dynamic changes in C-states AC - Battery Power switch. Brief description of the patches: Core change in this series is to split the cpuidle_device structure into two parts, i.e global and per-cpu basis. The per-cpu pieces are mostly generic statistics that can be independent of current running driver. As a result of these changes, there is single copy of cpuidle_states structure and single registration done by one cpu. The low level driver is free to set per-cpu driver data on each cpu if needed using the cpuidle_set_statedata() as the case today. Only in very rare cases asymmetric C-states exist which can be handled within the cpuidle driver. Most architectures do not have asymmetric C-states. First two patches in the series facilitate splitting of cpuidle_states and cpuidle_device structure and next two patches do the actual split, change the API's and make existing code follow the changed API. [1/4] - Move the idle residency accounting part from cpuidle.c to the respective low level drivers, so that the accounting can be accurately maintained if the driver decides to demote the chosen (suggested) by the governor. [2/4] - removes the cpuidle_device()-prepare API since is is not widely used and the only use case was to allow software demotion using CPUIDLE_FLAG_IGNORE flag. Both these functions can be absorbed within the cpuidle back-end driver ad hence deprecating the prepare routine and the CPUIDLE_FLAG_IGNORE flag. - Ref: https://lkml.org/lkml/2011/3/25/52 [3/4] - Splits the usage statistics (read/write) part out of cpuidle_state structure, so that the states can become read only and hence made global. [4/4] - Most APIs will now need to pass pointer to both global cpuidle_driver and per-cpu cpuidle_device structure. arch/arm/mach-at91/cpuidle.c | 41 +++-- arch/arm/mach-davinci/cpuidle.c | 51 --- arch/arm/mach-exynos4/cpuidle.c | 30 ++-- arch/arm/mach-kirkwood/cpuidle.c | 42 +++--- arch/arm/mach-omap2/cpuidle34xx.c | 133 +++-- arch/sh/kernel/cpu/shmobile/cpuidle.c | 28 ++-- drivers/acpi/processor_driver.c | 20 --- drivers/acpi/processor_idle.c | 251 +++-- drivers/cpuidle/cpuidle.c | 86 --- drivers/cpuidle/driver.c | 25 +++ drivers/cpuidle/governors/ladder.c| 41 - drivers/cpuidle/governors/menu.c | 29 ++-- drivers/cpuidle/sysfs.c | 22 ++- drivers/idle/intel_idle.c | 130 + include/acpi/processor.h |1 include/linux/cpuidle.h | 52 --- 16 files changed, 650 insertions(+), 332 deletions(-) -- Thanks -Deepthi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH V6 2/4] cpuidle: Remove CPUIDLE_FLAG_IGNORE and dev-prepare()
The cpuidle_device-prepare() mechanism causes updates to the
cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE
to tell the governor not to chose a state on a per-cpu basis at
run-time. State demotion is now handled by the driver and it returns
the actual state entered. Hence, this mechanism is not required.
Also this removes per-cpu flags from cpuidle_state enabling
it to be made global.
Ref: https://lkml.org/lkml/2011/3/25/52
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm
Signed-off-by: Trinabh Gupta g.trin...@gmail.com
---
drivers/cpuidle/cpuidle.c| 10 --
drivers/cpuidle/governors/menu.c |2 --
include/linux/cpuidle.h |3 ---
3 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 88bd121..f66bcf9 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -83,16 +83,6 @@ int cpuidle_idle_call(void)
hrtimer_peek_ahead_timers();
#endif
- /*
-* Call the device's prepare function before calling the
-* governor's select function. -prepare gives the device's
-* cpuidle driver a chance to update any dynamic information
-* of its cpuidle states for the current idle period, e.g.
-* state availability, latencies, residencies, etc.
-*/
- if (dev-prepare)
- dev-prepare(dev);
-
/* ask the governor for the next state */
next_state = cpuidle_curr_governor-select(dev);
if (need_resched()) {
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index e4b200c..af724e8 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -288,8 +288,6 @@ static int menu_select(struct cpuidle_device *dev)
for (i = CPUIDLE_DRIVER_STATE_START; i dev-state_count; i++) {
struct cpuidle_state *s = dev-states[i];
- if (s-flags CPUIDLE_FLAG_IGNORE)
- continue;
if (s-target_residency data-predicted_us)
continue;
if (s-exit_latency latency_req)
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 8da811b..c6d85cf 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -47,7 +47,6 @@ struct cpuidle_state {
/* Idle State Flags */
#define CPUIDLE_FLAG_TIME_VALID(0x01) /* is residency time measurable?
*/
-#define CPUIDLE_FLAG_IGNORE(0x100) /* ignore during this idle period */
#define CPUIDLE_DRIVER_FLAGS_MASK (0x)
@@ -93,8 +92,6 @@ struct cpuidle_device {
struct completion kobj_unregister;
void*governor_data;
int safe_state_index;
-
- int (*prepare) (struct cpuidle_device *dev);
};
DECLARE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH V6 1/4] cpuidle: Move dev-last_residency update to driver enter routine; remove dev-last_state
Cpuidle governor only suggests the state to enter using the
governor-select() interface, but allows the low level driver to
override the recommended state. The actual entered state
may be different because of software or hardware demotion. Software
demotion is done by the back-end cpuidle driver and can be accounted
correctly. Current cpuidle code uses last_state field to capture the
actual state entered and based on that updates the statistics for the
state entered.
Ideally the driver enter routine should update the counters,
and it should return the state actually entered rather than the time
spent there. The generic cpuidle code should simply handle where
the counters live in the sysfs namespace, not updating the counters.
Reference:
https://lkml.org/lkml/2011/3/25/52
To Do :
==
Russell King pointed out that in (V5) of this patch in
arch/arm/mach-at91/cpuidle.c, AT91 pieces may be broken.
In at91_enter_idle() routine, folks need to fix the two
consecutive asm() statements by combining
it to one as per the GCC reference manual.
Reference:
https://lkml.org/lkml/2011/6/6/273
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
Signed-off-by: Trinabh Gupta g.trin...@gmail.com
---
arch/arm/mach-at91/cpuidle.c | 10 +++-
arch/arm/mach-davinci/cpuidle.c |9 +++-
arch/arm/mach-exynos4/cpuidle.c |7 ++-
arch/arm/mach-kirkwood/cpuidle.c | 12 -
arch/arm/mach-omap2/cpuidle34xx.c | 67 +
arch/sh/kernel/cpu/shmobile/cpuidle.c | 12 +++--
drivers/acpi/processor_idle.c | 75 ++---
drivers/cpuidle/cpuidle.c | 32 +++---
drivers/cpuidle/governors/ladder.c| 13 ++
drivers/cpuidle/governors/menu.c |7 ++-
drivers/idle/intel_idle.c | 12 -
include/linux/cpuidle.h |7 +--
12 files changed, 164 insertions(+), 99 deletions(-)
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 1cfeac1..4696a0d 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -33,7 +33,7 @@ static struct cpuidle_driver at91_idle_driver = {
/* Actual code that puts the SoC in different idle states */
static int at91_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state)
+ int index)
{
struct timeval before, after;
int idle_time;
@@ -41,10 +41,10 @@ static int at91_enter_idle(struct cpuidle_device *dev,
local_irq_disable();
do_gettimeofday(before);
- if (state == dev-states[0])
+ if (index == 0)
/* Wait for interrupt state */
cpu_do_idle();
- else if (state == dev-states[1]) {
+ else if (index == 1) {
asm(b 1f; .align 5; 1:);
asm(mcr p15, 0, r0, c7, c10, 4); /* drain write buffer */
saved_lpr = sdram_selfrefresh_enable();
@@ -55,7 +55,9 @@ static int at91_enter_idle(struct cpuidle_device *dev,
local_irq_enable();
idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
(after.tv_usec - before.tv_usec);
- return idle_time;
+
+ dev-last_residency = idle_time;
+ return index;
}
/* Initialize CPU idle by registering the idle states */
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index bd59f31..ca8582a 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -78,9 +78,9 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
/* Actual code that puts the SoC in different idle states */
static int davinci_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state)
+ int index)
{
- struct davinci_ops *ops = cpuidle_get_statedata(state);
+ struct davinci_ops *ops = cpuidle_get_statedata(dev-states[index]);
struct timeval before, after;
int idle_time;
@@ -98,7 +98,10 @@ static int davinci_enter_idle(struct cpuidle_device *dev,
local_irq_enable();
idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
(after.tv_usec - before.tv_usec);
- return idle_time;
+
+ dev-last_residency = idle_time;
+
+ return index;
}
static int __init davinci_cpuidle_probe(struct platform_device *pdev)
diff --git a/arch/arm/mach-exynos4/cpuidle.c b/arch/arm/mach-exynos4/cpuidle.c
index bf7e96f..ea026e7 100644
--- a/arch/arm/mach-exynos4/cpuidle.c
+++ b/arch/arm/mach-exynos4/cpuidle.c
@@ -16,7 +16,7 @@
#include asm/proc-fns.h
static int exynos4_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state);
+ int index);
static struct cpuidle_state exynos4_cpuidle_set[] = {
[0] = {
@@ -37,7 +37,7
[RFC PATCH V6 3/4] cpuidle: Split cpuidle_state structure and move per-cpu statistics fields
This is the first step towards global registration of cpuidle
states. The statistics used primarily by the governor are per-cpu
and have to be split from rest of the fields inside cpuidle_state,
which would be made global i.e. single copy. The driver_data field
is also per-cpu and moved.
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
Signed-off-by: Trinabh Gupta g.trin...@gmail.com
---
arch/arm/mach-davinci/cpuidle.c |5 ++--
arch/arm/mach-omap2/cpuidle34xx.c | 13 ++
drivers/acpi/processor_idle.c | 25 ++--
drivers/cpuidle/cpuidle.c | 11 +
drivers/cpuidle/sysfs.c | 19 ++-
drivers/idle/intel_idle.c | 46 +++--
include/linux/cpuidle.h | 25
7 files changed, 90 insertions(+), 54 deletions(-)
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index ca8582a..f2d2f34 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -80,7 +80,8 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
static int davinci_enter_idle(struct cpuidle_device *dev,
int index)
{
- struct davinci_ops *ops = cpuidle_get_statedata(dev-states[index]);
+ struct cpuidle_state_usage *state_usage = dev-states_usage[index];
+ struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
struct timeval before, after;
int idle_time;
@@ -142,7 +143,7 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
strcpy(device-states[1].desc, WFI and DDR Self Refresh);
if (pdata-ddr2_pdown)
davinci_states[1].flags |= DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN;
- cpuidle_set_statedata(device-states[1], davinci_states[1]);
+ cpuidle_set_statedata(device-states_usage[1], davinci_states[1]);
device-state_count = DAVINCI_CPUIDLE_MAX_STATES;
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 58425c7..d3fce7b 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -97,7 +97,7 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
int index)
{
struct omap3_idle_statedata *cx =
- cpuidle_get_statedata(dev-states[index]);
+ cpuidle_get_statedata(dev-states_usage[index]);
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 mpu_state = cx-mpu_state, core_state = cx-core_state;
int idle_time;
@@ -160,8 +160,9 @@ return_sleep_time:
static int next_valid_state(struct cpuidle_device *dev,
int index)
{
+ struct cpuidle_state_usage *curr_usage = dev-states_usage[index];
struct cpuidle_state *curr = dev-states[index];
- struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr);
+ struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr_usage);
u32 mpu_deepest_state = PWRDM_POWER_RET;
u32 core_deepest_state = PWRDM_POWER_RET;
int next_index = -1;
@@ -202,7 +203,7 @@ static int next_valid_state(struct cpuidle_device *dev,
*/
idx--;
for (; idx = 0; idx--) {
- cx = cpuidle_get_statedata(dev-states[idx]);
+ cx = cpuidle_get_statedata(dev-states_usage[idx]);
if ((cx-valid)
(cx-mpu_state = mpu_deepest_state)
(cx-core_state = core_deepest_state)) {
@@ -231,7 +232,6 @@ static int next_valid_state(struct cpuidle_device *dev,
static int omap3_enter_idle_bm(struct cpuidle_device *dev,
int index)
{
- struct cpuidle_state *state = dev-states[index];
int new_state_idx;
u32 core_next_state, per_next_state = 0, per_saved_state = 0, cam_state;
struct omap3_idle_statedata *cx;
@@ -264,7 +264,7 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
* Prevent PER off if CORE is not in retention or off as this
* would disable PER wakeups completely.
*/
- cx = cpuidle_get_statedata(state);
+ cx = cpuidle_get_statedata(dev-states_usage[index]);
core_next_state = cx-core_state;
per_next_state = per_saved_state = pwrdm_read_next_pwrst(per_pd);
if ((per_next_state == PWRDM_POWER_OFF)
@@ -318,6 +318,7 @@ static inline struct omap3_idle_statedata *_fill_cstate(
{
struct omap3_idle_statedata *cx = omap3_idle_data[idx];
struct cpuidle_state *state = dev-states[idx];
+ struct cpuidle_state_usage *state_usage = dev-states_usage[idx];
state-exit_latency = cpuidle_params_table[idx].exit_latency;
state-target_residency = cpuidle_params_table[idx].target_residency;
@@ -326,7 +327,7 @@ static
[RFC PATCH V6 4/4] cpuidle: Single/Global registration of idle states
This patch makes the cpuidle_states structure global (single copy)
instead of per-cpu. The statistics needed on per-cpu basis
by the governor are kept per-cpu. This simplifies the cpuidle
subsystem as state registration is done by single cpu only.
Having single copy of cpuidle_states saves memory. Rare case
of asymmetric C-states can be handled within the cpuidle driver
and architectures such as POWER do not have asymmetric C-states.
ToDo:
Handle the case when idle states may change at run time
and acpi_processor_cst_has_changed() routine is called in a
better way than the current solution in this patch.
In this current solution where global registration is implemented,
the boot cpu on x86 would disable all the devices, repopulate the
states and later enable all the devices, irrespective of the cpu
that would receive the notification first.
Reference:
https://lkml.org/lkml/2011/4/25/83
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
Signed-off-by: Trinabh Gupta g.trin...@gmail.com
---
arch/arm/mach-at91/cpuidle.c | 31 +++--
arch/arm/mach-davinci/cpuidle.c | 39 ---
arch/arm/mach-exynos4/cpuidle.c | 23 ++--
arch/arm/mach-kirkwood/cpuidle.c | 30 +++--
arch/arm/mach-omap2/cpuidle34xx.c | 73 -
arch/sh/kernel/cpu/shmobile/cpuidle.c | 18 ++-
drivers/acpi/processor_driver.c | 20 +--
drivers/acpi/processor_idle.c | 191 +
drivers/cpuidle/cpuidle.c | 45 ++--
drivers/cpuidle/driver.c | 25
drivers/cpuidle/governors/ladder.c| 28 +++--
drivers/cpuidle/governors/menu.c | 20 ++-
drivers/cpuidle/sysfs.c |3 -
drivers/idle/intel_idle.c | 80 +++---
include/acpi/processor.h |1
include/linux/cpuidle.h | 19 ++-
16 files changed, 439 insertions(+), 207 deletions(-)
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 4696a0d..93178f6 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -33,6 +33,7 @@ static struct cpuidle_driver at91_idle_driver = {
/* Actual code that puts the SoC in different idle states */
static int at91_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
int index)
{
struct timeval before, after;
@@ -64,27 +65,29 @@ static int at91_enter_idle(struct cpuidle_device *dev,
static int at91_init_cpuidle(void)
{
struct cpuidle_device *device;
-
- cpuidle_register_driver(at91_idle_driver);
+ struct cpuidle_driver *driver = at91_idle_driver;
device = per_cpu(at91_cpuidle_device, smp_processor_id());
device-state_count = AT91_MAX_STATES;
+ driver-state_count = AT91_MAX_STATES;
/* Wait for interrupt state */
- device-states[0].enter = at91_enter_idle;
- device-states[0].exit_latency = 1;
- device-states[0].target_residency = 1;
- device-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(device-states[0].name, WFI);
- strcpy(device-states[0].desc, Wait for interrupt);
+ driver-states[0].enter = at91_enter_idle;
+ driver-states[0].exit_latency = 1;
+ driver-states[0].target_residency = 1;
+ driver-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
+ strcpy(driver-states[0].name, WFI);
+ strcpy(driver-states[0].desc, Wait for interrupt);
/* Wait for interrupt and RAM self refresh state */
- device-states[1].enter = at91_enter_idle;
- device-states[1].exit_latency = 10;
- device-states[1].target_residency = 1;
- device-states[1].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(device-states[1].name, RAM_SR);
- strcpy(device-states[1].desc, WFI and RAM Self Refresh);
+ driver-states[1].enter = at91_enter_idle;
+ driver-states[1].exit_latency = 10;
+ driver-states[1].target_residency = 1;
+ driver-states[1].flags = CPUIDLE_FLAG_TIME_VALID;
+ strcpy(driver-states[1].name, RAM_SR);
+ strcpy(driver-states[1].desc, WFI and RAM Self Refresh);
+
+ cpuidle_register_driver(at91_idle_driver);
if (cpuidle_register_device(device)) {
printk(KERN_ERR at91_init_cpuidle: Failed registering\n);
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index f2d2f34..dbeeccd 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -78,6 +78,7 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
/* Actual code that puts the SoC in different idle states */
static int davinci_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
int index)
{
struct cpuidle_state_usage *state_usage = dev-states_usage[index];
@@ -109,6 +110,7 @@
[PATCH 49/55] video: irq: Remove IRQF_DISABLED
Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
We run all interrupt handlers with interrupts disabled
and we even check and yell when an interrupt handler
returns with interrupts enabled (see commit [b738a50a:
genirq: Warn when handler enables interrupts]).
So now this flag is a NOOP and can be removed.
Signed-off-by: Yong Zhang yong.zha...@gmail.com
Acked-by: David Brown dav...@codeaurora.org
---
drivers/video/au1200fb.c |2 +-
drivers/video/bf54x-lq043fb.c |2 +-
drivers/video/bfin-lq035q1-fb.c |2 +-
drivers/video/bfin-t350mcqb-fb.c |2 +-
drivers/video/bfin_adv7393fb.c|2 +-
drivers/video/mb862xx/mb862xxfbdrv.c |4 ++--
drivers/video/msm/mddi.c |2 +-
drivers/video/msm/mdp.c |2 +-
drivers/video/nuc900fb.c |2 +-
drivers/video/omap2/displays/panel-taal.c |2 +-
drivers/video/ps3fb.c |2 +-
drivers/video/pxa3xx-gcu.c|2 +-
drivers/video/pxafb.c |2 +-
drivers/video/s3c2410fb.c |2 +-
drivers/video/sa1100fb.c |3 +--
drivers/video/sh_mobile_lcdcfb.c |2 +-
drivers/video/tmiofb.c|2 +-
drivers/video/vt8500lcdfb.c |2 +-
18 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/video/au1200fb.c b/drivers/video/au1200fb.c
index a19a40e..7200559 100644
--- a/drivers/video/au1200fb.c
+++ b/drivers/video/au1200fb.c
@@ -1673,7 +1673,7 @@ static int __devinit au1200fb_drv_probe(struct
platform_device *dev)
/* Now hook interrupt too */
irq = platform_get_irq(dev, 0);
ret = request_irq(irq, au1200fb_handle_irq,
- IRQF_DISABLED | IRQF_SHARED, lcd, (void *)dev);
+ IRQF_SHARED, lcd, (void *)dev);
if (ret) {
print_err(fail to request interrupt line %d (err: %d),
irq, ret);
diff --git a/drivers/video/bf54x-lq043fb.c b/drivers/video/bf54x-lq043fb.c
index 2464b91..56720fb 100644
--- a/drivers/video/bf54x-lq043fb.c
+++ b/drivers/video/bf54x-lq043fb.c
@@ -633,7 +633,7 @@ static int __devinit bfin_bf54x_probe(struct
platform_device *pdev)
goto out7;
}
- if (request_irq(info-irq, bfin_bf54x_irq_error, IRQF_DISABLED,
+ if (request_irq(info-irq, bfin_bf54x_irq_error, 0,
PPI ERROR, info) 0) {
printk(KERN_ERR DRIVER_NAME
: unable to request PPI ERROR IRQ\n);
diff --git a/drivers/video/bfin-lq035q1-fb.c b/drivers/video/bfin-lq035q1-fb.c
index 23b6c4b..c633068 100644
--- a/drivers/video/bfin-lq035q1-fb.c
+++ b/drivers/video/bfin-lq035q1-fb.c
@@ -695,7 +695,7 @@ static int __devinit bfin_lq035q1_probe(struct
platform_device *pdev)
goto out7;
}
- ret = request_irq(info-irq, bfin_lq035q1_irq_error, IRQF_DISABLED,
+ ret = request_irq(info-irq, bfin_lq035q1_irq_error, 0,
DRIVER_NAME PPI ERROR, info);
if (ret 0) {
dev_err(pdev-dev, unable to request PPI ERROR IRQ\n);
diff --git a/drivers/video/bfin-t350mcqb-fb.c b/drivers/video/bfin-t350mcqb-fb.c
index d8de29f..d5e1267 100644
--- a/drivers/video/bfin-t350mcqb-fb.c
+++ b/drivers/video/bfin-t350mcqb-fb.c
@@ -529,7 +529,7 @@ static int __devinit bfin_t350mcqb_probe(struct
platform_device *pdev)
goto out7;
}
- ret = request_irq(info-irq, bfin_t350mcqb_irq_error, IRQF_DISABLED,
+ ret = request_irq(info-irq, bfin_t350mcqb_irq_error, 0,
PPI ERROR, info);
if (ret 0) {
printk(KERN_ERR DRIVER_NAME
diff --git a/drivers/video/bfin_adv7393fb.c b/drivers/video/bfin_adv7393fb.c
index 8486f54..811dd7f 100644
--- a/drivers/video/bfin_adv7393fb.c
+++ b/drivers/video/bfin_adv7393fb.c
@@ -481,7 +481,7 @@ static int __devinit bfin_adv7393_fb_probe(struct
i2c_client *client,
goto out_4;
}
- if (request_irq(IRQ_PPI_ERROR, ppi_irq_error, IRQF_DISABLED,
+ if (request_irq(IRQ_PPI_ERROR, ppi_irq_error, 0,
PPI ERROR, fbdev) 0) {
dev_err(client-dev, unable to request PPI ERROR IRQ\n);
ret = -EFAULT;
diff --git a/drivers/video/mb862xx/mb862xxfbdrv.c
b/drivers/video/mb862xx/mb862xxfbdrv.c
index 12a634a..11a7a33 100644
--- a/drivers/video/mb862xx/mb862xxfbdrv.c
+++ b/drivers/video/mb862xx/mb862xxfbdrv.c
@@ -738,7 +738,7 @@ static int __devinit of_platform_mb862xx_probe(struct
platform_device *ofdev)
if (mb862xx_gdc_init(par))
goto io_unmap;
- if (request_irq(par-irq, mb862xx_intr, IRQF_DISABLED,
+ if (request_irq(par-irq, mb862xx_intr, 0,
DRV_NAME, (void *)par)) {
dev_err(dev, Cannot
[PATCH 37/55] mmc: irq: Remove IRQF_DISABLED
Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
We run all interrupt handlers with interrupts disabled
and we even check and yell when an interrupt handler
returns with interrupts enabled (see commit [b738a50a:
genirq: Warn when handler enables interrupts]).
So now this flag is a NOOP and can be removed.
Signed-off-by: Yong Zhang yong.zha...@gmail.com
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/mmc/host/omap_hsmmc.c |5 ++---
drivers/mmc/host/tmio_mmc.c |4 ++--
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21e4a79..75c6395 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2015,7 +2015,7 @@ static int __init omap_hsmmc_probe(struct platform_device
*pdev)
}
/* Request IRQ for MMC operations */
- ret = request_irq(host-irq, omap_hsmmc_irq, IRQF_DISABLED,
+ ret = request_irq(host-irq, omap_hsmmc_irq, 0,
mmc_hostname(mmc), host);
if (ret) {
dev_dbg(mmc_dev(host-mmc), Unable to grab HSMMC IRQ\n);
@@ -2043,8 +2043,7 @@ static int __init omap_hsmmc_probe(struct platform_device
*pdev)
if ((mmc_slot(host).card_detect_irq)) {
ret = request_irq(mmc_slot(host).card_detect_irq,
omap_hsmmc_cd_handler,
- IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING
- | IRQF_DISABLED,
+ IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
mmc_hostname(mmc), host);
if (ret) {
dev_dbg(mmc_dev(host-mmc),
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index 44a9668..a4ea102 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -88,8 +88,8 @@ static int __devinit tmio_mmc_probe(struct platform_device
*pdev)
if (ret)
goto cell_disable;
- ret = request_irq(irq, tmio_mmc_irq, IRQF_DISABLED |
- IRQF_TRIGGER_FALLING, dev_name(pdev-dev), host);
+ ret = request_irq(irq, tmio_mmc_irq, IRQF_TRIGGER_FALLING,
+ dev_name(pdev-dev), host);
if (ret)
goto host_remove;
--
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] OMAPDSS: HDMI: Move Avi infoframe structure to
From: Mythri P K mythr...@ti.com
With AVI infoframe various parameters of video stream such as
aspect ratio, quantization range, videocode etc will be indicated
from source to sink.Thus AVI information needs to be set/accessed
by the middle ware based on the video content.
Thus this parameter is now moved to the ip_data structure.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi.h | 42 +
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |8 +++---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 40 ---
3 files changed, 46 insertions(+), 44 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 2c3443d..f28f779 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -112,6 +112,47 @@ struct ti_hdmi_ip_ops {
};
+/*
+ * Refer to section 8.2 in HDMI 1.3 specification for
+ * details about infoframe databytes
+ */
+struct hdmi_core_infoframe_avi {
+ /* Y0, Y1 rgb,yCbCr */
+ u8 db1_format;
+ /* A0 Active information Present */
+ u8 db1_active_info;
+ /* B0, B1 Bar info data valid */
+ u8 db1_bar_info_dv;
+ /* S0, S1 scan information */
+ u8 db1_scan_info;
+ /* C0, C1 colorimetry */
+ u8 db2_colorimetry;
+ /* M0, M1 Aspect ratio (4:3, 16:9) */
+ u8 db2_aspect_ratio;
+ /* R0...R3 Active format aspect ratio */
+ u8 db2_active_fmt_ar;
+ /* ITC IT content. */
+ u8 db3_itc;
+ /* EC0, EC1, EC2 Extended colorimetry */
+ u8 db3_ec;
+ /* Q1, Q0 Quantization range */
+ u8 db3_q_range;
+ /* SC1, SC0 Non-uniform picture scaling */
+ u8 db3_nup_scaling;
+ /* VIC0..6 Video format identification */
+ u8 db4_videocode;
+ /* PR0..PR3 Pixel repetition factor */
+ u8 db5_pixel_repeat;
+ /* Line number end of top bar */
+ u16 db6_7_line_eoftop;
+ /* Line number start of bottom bar */
+ u16 db8_9_line_sofbottom;
+ /* Pixel number end of left bar */
+ u16 db10_11_pixel_eofleft;
+ /* Pixel number start of right bar */
+ u16 db12_13_pixel_sofright;
+};
+
struct hdmi_ip_data {
void __iomem*base_wp; /* HDMI wrapper */
unsigned long core_sys_offset;
@@ -121,6 +162,7 @@ struct hdmi_ip_data {
const struct ti_hdmi_ip_ops *ops;
struct hdmi_config cfg;
struct hdmi_pll_info pll_data;
+ struct hdmi_core_infoframe_avi avi_cfg;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index e1a6ce5..7b0dcd2 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -534,12 +534,12 @@ static void hdmi_core_video_config(struct hdmi_ip_data
*ip_data,
HDMI_CORE_SYS_TMDS_CTRL, cfg-tclk_sel_clkmult, 6, 5);
}
-static void hdmi_core_aux_infoframe_avi_config(struct hdmi_ip_data *ip_data,
- struct hdmi_core_infoframe_avi info_avi)
+static void hdmi_core_aux_infoframe_avi_config(struct hdmi_ip_data *ip_data)
{
u32 val;
char sum = 0, checksum = 0;
void __iomem *av_base = hdmi_av_base(ip_data);
+ struct hdmi_core_infoframe_avi info_avi = ip_data-avi_cfg;
sum += 0x82 + 0x002 + 0x00D;
hdmi_write_reg(av_base, HDMI_CORE_AV_AVI_TYPE, 0x082);
@@ -727,7 +727,7 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
struct hdmi_video_format video_format;
struct hdmi_video_interface video_interface;
/* HDMI core */
- struct hdmi_core_infoframe_avi avi_cfg;
+ struct hdmi_core_infoframe_avi avi_cfg = ip_data-avi_cfg;
struct hdmi_core_video_config v_core_cfg;
struct hdmi_core_packet_enable_repeat repeat_cfg;
struct hdmi_config *cfg = ip_data-cfg;
@@ -795,7 +795,7 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
avi_cfg.db10_11_pixel_eofleft = 0;
avi_cfg.db12_13_pixel_sofright = 0;
- hdmi_core_aux_infoframe_avi_config(ip_data, avi_cfg);
+ hdmi_core_aux_infoframe_avi_config(ip_data);
/* enable/repeat the infoframe */
repeat_cfg.avi_infoframe = HDMI_PACKETENABLE;
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 2040956..9f383c9 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -450,46 +450,6 @@ struct hdmi_core_video_config {
* Refer to section 8.2 in HDMI 1.3 specification for
* details about infoframe databytes
*/
-struct hdmi_core_infoframe_avi {
- /* Y0, Y1 rgb,yCbCr */
- u8 db1_format;
-
[PATCH 2/3] OMAPDSS: HDMI: Add support to configure quantization
From: Mythri P K mythr...@ti.com
Configure the IP to support the limited range and full range quantization
mode. If the full range is configured HDMI transmitter will expand the range
of pixel data from 16-235 to full 8 bit 0-235.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi.h |7 +
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 40 +
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index f28f779..ec30961 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -42,6 +42,11 @@ enum hdmi_clk_refsel {
HDMI_REFSEL_SYSCLK = 3
};
+enum hdmi_range {
+ HDMI_LIMITED_RANGE = 0,
+ HDMI_FULL_RANGE = 1,
+};
+
struct hdmi_video_timings {
u16 x_res;
u16 y_res;
@@ -163,6 +168,7 @@ struct hdmi_ip_data {
struct hdmi_config cfg;
struct hdmi_pll_info pll_data;
struct hdmi_core_infoframe_avi avi_cfg;
+ enum hdmi_range range;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
@@ -176,5 +182,6 @@ void ti_hdmi_4xxx_wp_dump(struct hdmi_ip_data *ip_data,
struct seq_file *s);
void ti_hdmi_4xxx_pll_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
+int ti_hdmi_4xxx_configure_range(struct hdmi_ip_data *ip_data);
#endif
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 7b0dcd2..e30fb22 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -610,6 +610,46 @@ static void hdmi_core_aux_infoframe_avi_config(struct
hdmi_ip_data *ip_data)
hdmi_write_reg(av_base, HDMI_CORE_AV_AVI_CHSUM, checksum);
}
+int ti_hdmi_4xxx_configure_range(struct hdmi_ip_data *ip_data)
+{
+ int var;
+
+ switch (ip_data-range) {
+ /*
+* Setting the AVI infroframe to respective limited range
+* 0 if limited range 1 if full range
+*/
+ case HDMI_LIMITED_RANGE:
+ ip_data-avi_cfg.db3_q_range = HDMI_INFOFRAME_AVI_DB3Q_LR;
+ hdmi_core_aux_infoframe_avi_config(ip_data);
+ var = hdmi_read_reg(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_VID_ACEN);
+ var = FLD_MOD(var, 1, 1, 1);
+ hdmi_write_reg(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_VID_ACEN, var);
+ break;
+ case HDMI_FULL_RANGE:
+ default:
+ /* HDMI 1.3 section 6.6 YCBCR components shall
+* always be Limited Range
+*/
+ if (ip_data-avi_cfg.db1_format ==
+ HDMI_INFOFRAME_AVI_DB1Y_YUV422) {
+ pr_err(Only limited range is supported for YUV);
+ return -EINVAL;
+ }
+ ip_data-avi_cfg.db3_q_range = HDMI_INFOFRAME_AVI_DB3Q_FR;
+ hdmi_core_aux_infoframe_avi_config(ip_data);
+ var = hdmi_read_reg(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_VID_MODE);
+ var = FLD_MOD(var, 1, 4, 4);
+ hdmi_write_reg(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_VID_MODE, var);
+ break;
+ }
+ return 0;
+}
+
static void hdmi_core_av_packet_config(struct hdmi_ip_data *ip_data,
struct hdmi_core_packet_enable_repeat repeat_cfg)
{
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] OMAPDSS: HDMI: Add sysfs support to configure
From: Mythri P K mythr...@ti.com
Add sysfs support for the uset space to configure limited range or full range
quantization for HDMI.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dss.h |2 +
drivers/video/omap2/dss/dss_features.c |1 +
drivers/video/omap2/dss/hdmi.c | 28 +
drivers/video/omap2/dss/hdmi_panel.c | 35 +++-
drivers/video/omap2/dss/ti_hdmi.h |2 +
5 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index ef8770a..bcfb5fa 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -499,6 +499,8 @@ int omapdss_hdmi_display_check_timing(struct
omap_dss_device *dssdev,
struct omap_video_timings *timings);
int omapdss_hdmi_read_edid(u8 *buf, int len);
bool omapdss_hdmi_detect(void);
+int omapdss_hdmi_get_range(void);
+int omapdss_hdmi_set_range(int range);
int hdmi_panel_init(void);
void hdmi_panel_exit(void);
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index a2fc8e0..8303ea2 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -451,6 +451,7 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions = {
.dump_core = ti_hdmi_4xxx_core_dump,
.dump_pll = ti_hdmi_4xxx_pll_dump,
.dump_phy = ti_hdmi_4xxx_phy_dump,
+ .configure_range= ti_hdmi_4xxx_configure_range,
};
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 8930998..ff33cb2 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -407,6 +407,34 @@ static void hdmi_power_off(struct omap_dss_device *dssdev)
hdmi_runtime_put();
}
+int omapdss_hdmi_set_range(int range)
+{
+ int r = 0;
+ enum hdmi_range old_range;
+
+ old_range = hdmi.ip_data.range;
+ hdmi.ip_data.range = range;
+
+ /* HDMI 1.3 section 6.6 VGA (640x480) format requires Full Range */
+ if ((range == 0)
+ ((hdmi.ip_data.cfg.cm.code == 4
+ hdmi.ip_data.cfg.cm.mode == HDMI_DVI) ||
+ (hdmi.ip_data.cfg.cm.code == 1
+ hdmi.ip_data.cfg.cm.mode == HDMI_HDMI)))
+ return -EINVAL;
+
+ r = hdmi.ip_data.ops-configure_range(hdmi.ip_data);
+ if (r)
+ hdmi.ip_data.range = old_range;
+
+ return r;
+}
+
+int omapdss_hdmi_get_range(void)
+{
+ return hdmi.ip_data.range;
+}
+
int omapdss_hdmi_display_check_timing(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
diff --git a/drivers/video/omap2/dss/hdmi_panel.c
b/drivers/video/omap2/dss/hdmi_panel.c
index 533d5dc..c0aa922 100644
--- a/drivers/video/omap2/dss/hdmi_panel.c
+++ b/drivers/video/omap2/dss/hdmi_panel.c
@@ -33,6 +33,33 @@ static struct {
struct mutex hdmi_lock;
} hdmi;
+static ssize_t hdmi_range_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int r;
+
+ r = omapdss_hdmi_get_range();
+ return snprintf(buf, PAGE_SIZE, %d\n, r);
+}
+
+static ssize_t hdmi_range_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ unsigned long range;
+ int r = kstrtoul(buf, 0, range);
+
+ if (r || range 1)
+ return -EINVAL;
+
+ r = omapdss_hdmi_set_range(range);
+ if (r)
+ return r;
+
+ return size;
+}
+
+static DEVICE_ATTR(range, S_IRUGO | S_IWUSR, hdmi_range_show,
hdmi_range_store);
static int hdmi_panel_probe(struct omap_dss_device *dssdev)
{
@@ -41,6 +68,12 @@ static int hdmi_panel_probe(struct omap_dss_device *dssdev)
dssdev-panel.config = OMAP_DSS_LCD_TFT |
OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS;
+ /* sysfs entry to provide user space control to set
+* quantization range
+*/
+ if (device_create_file(dssdev-dev, dev_attr_range))
+ DSSERR(failed to create sysfs file\n);
+
dssdev-panel.timings = (struct omap_video_timings){640, 480, 25175,
96, 16, 48, 2 , 11, 31};
DSSDBG(hdmi_panel_probe x_res= %d y_res = %d\n,
@@ -51,7 +84,7 @@ static int hdmi_panel_probe(struct omap_dss_device *dssdev)
static void hdmi_panel_remove(struct omap_dss_device *dssdev)
{
-
+ device_remove_file(dssdev-dev, dev_attr_range);
}
static int hdmi_panel_enable(struct omap_dss_device *dssdev)
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index ec30961..4e2418e 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -115,6 +115,8 @@ struct ti_hdmi_ip_ops {
void (*dump_phy)(struct
[PATCH 3/5 v11] arm: omap: usb: register hwmods of usbhs
The hwmod structure of uhh, ohci, ehci and tll are
retrieved and registered with omap device
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/usb-host.c | 116 +---
1 files changed, 50 insertions(+), 66 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 89ae298..9bc73eb 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -28,51 +28,30 @@
#include mach/hardware.h
#include mach/irqs.h
#include plat/usb.h
+#include plat/omap_device.h
#include mux.h
#ifdef CONFIG_MFD_OMAP_USB_HOST
-#define OMAP_USBHS_DEVICE usbhs-omap
-
-static struct resource usbhs_resources[] = {
- {
- .name = uhh,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = tll,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ehci,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ehci-irq,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = ohci,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ohci-irq,
- .flags = IORESOURCE_IRQ,
- }
-};
-
-static struct platform_device usbhs_device = {
- .name = OMAP_USBHS_DEVICE,
- .id = 0,
- .num_resources = ARRAY_SIZE(usbhs_resources),
- .resource = usbhs_resources,
-};
+#define OMAP_USBHS_DEVICE usbhs_omap
+#defineUSBHS_UHH_HWMODNAME usb_host_hs
+#defineUSBHS_OHCI_HWMODNAMEusb_ohci_hs
+#define USBHS_EHCI_HWMODNAME usb_ehci_hs
+#define USBHS_TLL_HWMODNAMEusb_tll_hs
static struct usbhs_omap_platform_data usbhs_data;
static struct ehci_hcd_omap_platform_data ehci_data;
static struct ohci_hcd_omap_platform_data ohci_data;
+static struct omap_device_pm_latency omap_uhhtll_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
/* MUX settings for EHCI pins */
/*
* setup_ehci_io_mux - initialize IO pad mux for USBHOST
@@ -508,7 +487,10 @@ static void setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
{
- int i;
+ struct omap_hwmod *oh[4];
+ struct omap_device *od;
+ int bus_id = -1;
+ int i;
for (i = 0; i OMAP3_HS_USB_PORTS; i++) {
usbhs_data.port_mode[i] = pdata-port_mode[i];
@@ -523,44 +505,48 @@ void __init usbhs_init(const struct usbhs_omap_board_data
*pdata)
usbhs_data.ohci_data = ohci_data;
if (cpu_is_omap34xx()) {
- usbhs_resources[0].start = OMAP34XX_UHH_CONFIG_BASE;
- usbhs_resources[0].end = OMAP34XX_UHH_CONFIG_BASE + SZ_1K - 1;
- usbhs_resources[1].start = OMAP34XX_USBTLL_BASE;
- usbhs_resources[1].end = OMAP34XX_USBTLL_BASE + SZ_4K - 1;
- usbhs_resources[2].start= OMAP34XX_EHCI_BASE;
- usbhs_resources[2].end = OMAP34XX_EHCI_BASE + SZ_1K - 1;
- usbhs_resources[3].start = INT_34XX_EHCI_IRQ;
- usbhs_resources[4].start= OMAP34XX_OHCI_BASE;
- usbhs_resources[4].end = OMAP34XX_OHCI_BASE + SZ_1K - 1;
- usbhs_resources[5].start = INT_34XX_OHCI_IRQ;
setup_ehci_io_mux(pdata-port_mode);
setup_ohci_io_mux(pdata-port_mode);
} else if (cpu_is_omap44xx()) {
- usbhs_resources[0].start = OMAP44XX_UHH_CONFIG_BASE;
- usbhs_resources[0].end = OMAP44XX_UHH_CONFIG_BASE + SZ_1K - 1;
- usbhs_resources[1].start = OMAP44XX_USBTLL_BASE;
- usbhs_resources[1].end = OMAP44XX_USBTLL_BASE + SZ_4K - 1;
- usbhs_resources[2].start = OMAP44XX_HSUSB_EHCI_BASE;
- usbhs_resources[2].end = OMAP44XX_HSUSB_EHCI_BASE + SZ_1K - 1;
- usbhs_resources[3].start = OMAP44XX_IRQ_EHCI;
- usbhs_resources[4].start = OMAP44XX_HSUSB_OHCI_BASE;
- usbhs_resources[4].end = OMAP44XX_HSUSB_OHCI_BASE + SZ_1K - 1;
- usbhs_resources[5].start = OMAP44XX_IRQ_OHCI;
setup_4430ehci_io_mux(pdata-port_mode);
setup_4430ohci_io_mux(pdata-port_mode);
}
- if (platform_device_add_data(usbhs_device,
- usbhs_data, sizeof(usbhs_data)) 0) {
- printk(KERN_ERR USBHS platform_device_add_data failed\n);
- goto init_end;
+ oh[0] = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
+ if (!oh[0]) {
+
[PATCH 0/5 v11] mfd: omap: usb: Runtime PM support for EHCI and OHCI drivers
From: Keshava Munegowda keshava_mgo...@ti.com The Hwmod structures and Runtime PM features are implemented For EHCI and OHCI drivers of OMAP3 and OMAP4. The global suspend/resume of EHCI and OHCI is validated on OMAP3430 sdp board with these patches. These patches are re-based to Kevin's pm branch : git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git TODO: - Adding pad configurations to Hwmods - Aggressive clock cutting in usb bus suspends - Remote Wakeup implementation using irq-chaining Benoit Cousson (1): arm: omap: usb: ehci and ohci hwmod structures for omap4 Keshava Munegowda (4): arm: omap: usb: ehci and ohci hwmod structures for omap3 arm: omap: usb: register hwmods of usbhs arm: omap: usb: device name change for the clk names of usbhs mfd: omap: usb: Runtime PM support arch/arm/mach-omap2/clock3xxx_data.c | 26 +- arch/arm/mach-omap2/clock44xx_data.c | 10 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 271 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 250 ++- arch/arm/mach-omap2/usb-host.c | 116 ++--- arch/arm/plat-omap/include/plat/usb.h |3 - drivers/mfd/omap-usb-host.c| 733 +++- drivers/usb/host/ehci-omap.c | 17 +- drivers/usb/host/ohci-omap3.c | 18 +- 9 files changed, 883 insertions(+), 561 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap4
From: Benoit Cousson b-cous...@ti.com
Following 4 hwmod structures are added
1. usb_host_hs hwmod of usbhs with uhh base address and functional clock,
2. usb_ehci_hs hwmod with irq and base address,
3. usb_ohci_hs hwmod with irq and base address,
- The ehci and ohci hwmods does not require functional clock
because usb_host_hs has functional clock which is sufficient
to access ehci and ohci address space.
- The usb_ehci_hs and usb_ohci_hs should be two separate hwmods
which should not be combined. This is needed because ehci and
ohci will have separate dedicated ports in omap4 there is a
clock per port.We should be able to configure the IO-Wakeup
capability of pins specific to EHCI OHCI separately and depending
on the I/O wakeup event the only port clocks corresponding
to the wakeup source will be enabled internally by the usb host driver.
4. usb_tll_hs hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Cousson b-cous...@ti.com
- The initial version had only two hwmods,usb_host_hs and usb_tll_hs.
These two hwmods are reorganized as above four hwmods, because there
will be dedicated ports for ehci and ohci; and each port will have I/O
mux, which will be initialized per hwmod in future.
- migrated these hwmod structures to Kevin's pm branch:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git .
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 250 +++-
1 files changed, 249 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..5e8a640 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -68,6 +68,10 @@ static struct omap_hwmod omap44xx_mmc2_hwmod;
static struct omap_hwmod omap44xx_mpu_hwmod;
static struct omap_hwmod omap44xx_mpu_private_hwmod;
static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
/*
* Interconnects omap_hwmod structures
@@ -5336,6 +5340,245 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
+ .master = omap44xx_usb_host_hs_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
+ .name = usb_host_hs,
+ .sysc = omap44xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
+ omap44xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x4a064000,
+ .pa_end = 0x4a0647ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_usb_host_hs_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_slaves[] = {
+ omap44xx_l4_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
+ .name = usb_host_hs,
+ .class = omap44xx_usb_host_hs_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .main_clk = usb_host_hs_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L3INIT_USB_HOST_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .slaves = omap44xx_usb_host_hs_slaves,
+ .slaves_cnt =
[PATCH 4/5 v11] arm: omap: usb: device name change for the clk names of usbhs
From: Keshava Munegowda keshava_mgo...@ti.com
device name usbhs clocks are changed from
usbhs-omap.0 to usbhs_omap; this is because
in the hwmod registration the device name is set
as usbhs_omap; The redudant clock nodes are removed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 26 --
arch/arm/mach-omap2/clock44xx_data.c | 10 +-
drivers/mfd/omap-usb-host.c |2 +-
3 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index ffd55b1..63a822f 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3285,7 +3285,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cpefuse_fck, cpefuse_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, ts_fck, ts_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbtll_fck, usbtll_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap-mcbsp.1, prcm_fck, core_96m_fck, CK_3XXX),
CLK(omap-mcbsp.5, prcm_fck, core_96m_fck, CK_3XXX),
CLK(NULL, core_96m_fck, core_96m_fck, CK_3XXX),
@@ -3321,7 +3321,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_34XX | CK_36XX),
CLK(NULL, core_l4_ick, core_l4_ick, CK_3XXX),
CLK(NULL, usbtll_ick, usbtll_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap_hsmmc.2, ick, mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, icr_ick, icr_ick, CK_34XX | CK_36XX),
CLK(omap-aes, ick, aes2_ick, CK_34XX | CK_36XX),
@@ -3367,20 +3367,18 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cam_ick, cam_ick, CK_34XX | CK_36XX),
CLK(NULL, csi2_96m_fck, csi2_96m_fck, CK_34XX | CK_36XX),
CLK(NULL, usbhost_120m_fck, usbhost_120m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, hs_fck, usbhost_120m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_48m_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, fs_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_ick, usbhost_ick, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, utmi_p1_gfclk,dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, utmi_p2_gfclk,dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, xclk60mhsp1_ck, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, init_60m_fclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, utmi_p1_gfclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, utmi_p2_gfclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, xclk60mhsp1_ck, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, init_60m_fclk,dummy_ck,
CK_3XXX),
CLK(NULL, usim_fck, usim_fck, CK_3430ES2PLUS |
CK_36XX),
CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX),
CLK(NULL, wkup_32k_fck, wkup_32k_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2af0e3f..088977a 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++
[PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
following 4 hwmod structures are added
1. usb_host_hs hwmod of usbhs with uhh base address and functional clock,
2. usb_ehci_hs hwmod with irq and base address,
3. usb_ohci_hs hwmod with irq and base address,
- the ehci and ohci hwmods does not require functional clock
because usb_host_hs has functional clock which is sufficient
to access ehci and ohci address space.
4. usb_tll_hs hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 271
1 files changed, 271 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..d79f728 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,10 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3196,6 +3200,266 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usb_host_hs,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk= l4_ick,
+ .addr = omap34xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk= usbhost_120m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f48m_cfg__usb_host_hs = {
+ .clk= usbhost_48m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ omap34xx_l4_cfg__usb_host_hs,
+ omap34xx_f128m_cfg__usb_host_hs,
+ omap34xx_f48m_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usb_host_hs,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .main_clk = usbhost_ick,
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430ES2_USBHOST_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = 0,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = 1,
+ .idlest_stdby_bit = 0,
+ },
+ },
+ .slaves = omap34xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_slaves),
+ .masters= omap34xx_usb_host_hs_masters,
+ .masters_cnt= ARRAY_SIZE(omap34xx_usb_host_hs_masters),
+/*
+ * The usbhs controller prevents the enter omap to low power mode
+ * if other than FORCE IDLE and FORCE STANDBY are used.
+ */
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+/* 'usb_ohci_hs' class */
+static struct omap_hwmod_class
[PATCH 5/5 v11] mfd: omap: usb: Runtime PM support
From: Keshava Munegowda keshava_mgo...@ti.com
The usbhs core driver does not enable/disable the interface and
functional clocks; These clocks are handled by hwmod and runtime pm,
hence instead of the clock enable/disable, the runtime pm APIS are
used. however,the port clocks are handled by the usbhs core.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/plat-omap/include/plat/usb.h |3 -
drivers/mfd/omap-usb-host.c | 731 +
drivers/usb/host/ehci-omap.c | 17 +-
drivers/usb/host/ohci-omap3.c | 18 +-
4 files changed, 295 insertions(+), 474 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 17d3c93..2b66dc2 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -100,9 +100,6 @@ extern void usb_musb_init(struct omap_musb_board_data
*board_data);
extern void usbhs_init(const struct usbhs_omap_board_data *pdata);
-extern int omap_usbhs_enable(struct device *dev);
-extern void omap_usbhs_disable(struct device *dev);
-
extern int omap4430_phy_power(struct device *dev, int ID, int on);
extern int omap4430_phy_set_clk(struct device *dev, int on);
extern int omap4430_phy_init(struct device *dev);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 9c2da29..e6f3b01 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -26,6 +26,7 @@
#include linux/spinlock.h
#include linux/gpio.h
#include plat/usb.h
+#include linux/pm_runtime.h
#define USBHS_DRIVER_NAME usbhs_omap
#define OMAP_EHCI_DEVICE ehci-omap
@@ -146,9 +147,6 @@
struct usbhs_hcd_omap {
- struct clk *usbhost_ick;
- struct clk *usbhost_hs_fck;
- struct clk *usbhost_fs_fck;
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
struct clk *utmi_p1_fck;
@@ -158,8 +156,6 @@ struct usbhs_hcd_omap {
struct clk *usbhost_p2_fck;
struct clk *usbtll_p2_fck;
struct clk *init_60m_fclk;
- struct clk *usbtll_fck;
- struct clk *usbtll_ick;
void __iomem*uhh_base;
void __iomem*tll_base;
@@ -168,7 +164,6 @@ struct usbhs_hcd_omap {
u32 usbhs_rev;
spinlock_t lock;
- int count;
};
/*-*/
@@ -318,269 +313,6 @@ err_end:
return ret;
}
-/**
- * usbhs_omap_probe - initialize TI-based HCDs
- *
- * Allocates basic resources for this USB host controller.
- */
-static int __devinit usbhs_omap_probe(struct platform_device *pdev)
-{
- struct device *dev = pdev-dev;
- struct usbhs_omap_platform_data *pdata = dev-platform_data;
- struct usbhs_hcd_omap *omap;
- struct resource *res;
- int ret = 0;
- int i;
-
- if (!pdata) {
- dev_err(dev, Missing platform data\n);
- ret = -ENOMEM;
- goto end_probe;
- }
-
- omap = kzalloc(sizeof(*omap), GFP_KERNEL);
- if (!omap) {
- dev_err(dev, Memory allocation failed\n);
- ret = -ENOMEM;
- goto end_probe;
- }
-
- spin_lock_init(omap-lock);
-
- for (i = 0; i OMAP3_HS_USB_PORTS; i++)
- omap-platdata.port_mode[i] = pdata-port_mode[i];
-
- omap-platdata.ehci_data = pdata-ehci_data;
- omap-platdata.ohci_data = pdata-ohci_data;
-
- omap-usbhost_ick = clk_get(dev, usbhost_ick);
- if (IS_ERR(omap-usbhost_ick)) {
- ret = PTR_ERR(omap-usbhost_ick);
- dev_err(dev, usbhost_ick failed error:%d\n, ret);
- goto err_end;
- }
-
- omap-usbhost_hs_fck = clk_get(dev, hs_fck);
- if (IS_ERR(omap-usbhost_hs_fck)) {
- ret = PTR_ERR(omap-usbhost_hs_fck);
- dev_err(dev, usbhost_hs_fck failed error:%d\n, ret);
- goto err_usbhost_ick;
- }
-
- omap-usbhost_fs_fck = clk_get(dev, fs_fck);
- if (IS_ERR(omap-usbhost_fs_fck)) {
- ret = PTR_ERR(omap-usbhost_fs_fck);
- dev_err(dev, usbhost_fs_fck failed error:%d\n, ret);
- goto err_usbhost_hs_fck;
- }
-
- omap-usbtll_fck = clk_get(dev, usbtll_fck);
- if (IS_ERR(omap-usbtll_fck)) {
- ret = PTR_ERR(omap-usbtll_fck);
- dev_err(dev, usbtll_fck
[PATCH 1/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap4
From: Benoit Cousson b-cous...@ti.com
Following 4 hwmod structures are added
1. usb_host_hs hwmod of usbhs with uhh base address and functional clock,
2. usb_ehci_hs hwmod with irq and base address,
3. usb_ohci_hs hwmod with irq and base address,
- The ehci and ohci hwmods does not require functional clock
because usb_host_hs has functional clock which is sufficient
to access ehci and ohci address space.
- The usb_ehci_hs and usb_ohci_hs should be two separate hwmods
which should not be combined. This is needed because ehci and
ohci will have separate dedicated ports in omap4 there is a
clock per port.We should be able to configure the IO-Wakeup
capability of pins specific to EHCI OHCI separately and depending
on the I/O wakeup event the only port clocks corresponding
to the wakeup source will be enabled internally by the usb host driver.
4. usb_tll_hs hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Cousson b-cous...@ti.com
- The initial version had only two hwmods,usb_host_hs and usb_tll_hs.
These two hwmods are reorganized as above four hwmods, because there
will be dedicated ports for ehci and ohci; and each port will have I/O
mux, which will be initialized per hwmod in future.
- migrated these hwmod structures to Kevin's pm branch:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git .
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 250 +++-
1 files changed, 249 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..5e8a640 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -68,6 +68,10 @@ static struct omap_hwmod omap44xx_mmc2_hwmod;
static struct omap_hwmod omap44xx_mpu_hwmod;
static struct omap_hwmod omap44xx_mpu_private_hwmod;
static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
/*
* Interconnects omap_hwmod structures
@@ -5336,6 +5340,245 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
+ .master = omap44xx_usb_host_hs_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
+ .name = usb_host_hs,
+ .sysc = omap44xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
+ omap44xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x4a064000,
+ .pa_end = 0x4a0647ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_usb_host_hs_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_slaves[] = {
+ omap44xx_l4_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
+ .name = usb_host_hs,
+ .class = omap44xx_usb_host_hs_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .main_clk = usb_host_hs_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L3INIT_USB_HOST_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .slaves = omap44xx_usb_host_hs_slaves,
+ .slaves_cnt =
Re: [PATCH v2 5/5] OMAPDSS: HDMI: Add support to dump clocks through
On Thu, 2011-09-22 at 13:37 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Add support to dump the HDMI regm, regn, and other clock parameters.
The subjects of this and previous patch seem to be still broken. And
while at it, you could fix missing periods and misplaced spaces (like
foo ,bar) in the descriptions of this patch series.
+void hdmi_dump_clocks(struct seq_file *s)
+{
+ enum omap_dss_clk_source dispc_clk_src;
+
+ dispc_clk_src = dss_get_dispc_clk_source();
+
+ if (hdmi_runtime_get())
+ return;
+
+ seq_printf(s, - HDMI PLL -\n);
+
+ seq_printf(s, regm\t%u\n, hdmi.ip_data.pll_data.regm);
+
+ seq_printf(s, regmf\t%u\n, hdmi.ip_data.pll_data.regmf);
+
+ seq_printf(s, dcofreq\t%u\n, hdmi.ip_data.pll_data.dcofreq);
+
+ seq_printf(s, regsd\t%u\n, hdmi.ip_data.pll_data.regsd);
Printing the dividers is fine, but I think we're usually more interested
in the resulting clocks. So you should print also the clocks. Possibly
internal clocks (like Fint for DSI) also, but at least the output
clocks. I believe for HDMI PLL they are CLKOUTLDO and CLKDCOLDO.
Looking at the dividers also brings up two things not directly related
to this patch:
- What is dcofreq? Looking at the code, it tells if the pixel clock is
1000MHz. Why is such a field needed, can't the HDMI driver manage that
itself? And if it's needed, why is it called dcofreq, the name doesn't
make much sense to me.
- We are doing HDMI PLL calculations in the omapdss drivers hdmi.c file.
The PLL calculations are PLL specific, and thus should be in the
specific HDMI implementation file, right?
+ seq_printf(s, DISPC clock source %s (%s)\t(%s)\n,
+ dss_get_generic_clk_source_name(dispc_clk_src),
+ dss_feat_get_clk_source_name(dispc_clk_src),
+ dispc_clk_src == OMAP_DSS_CLK_SRC_FCK ?
+ off : on);
Why do you print DISPC clock source? How is that part of HDMI clock
configuration?
+
+ seq_printf(s, hdmi %s source rate = %lu\n,
+ hdmi.ip_data.pll_data.refsel == HDMI_REFSEL_SYSCLK ?
+ sysclk : pclk/ref1/ref2,
+ clk_get_rate(hdmi.sys_clk));
Here I think it would be better to use the same format as the already
existing outputs (DSI). And as the PLL source is base clock, it's more
logical to print it first, like DSI does.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/3] AM3517: Booting up
This patch-set gets the kernel booting up on a AM3517 EVM. The board is able to boot with ramdisk after this,but the MMC and Ethernet drivers are not up yet. Lots of warnings remain which will be addressed in subsequent patches. The patches are tested on master of git://github.com/tmlind/linux.git Kernel version is 3.1.0-rc6 and last commit on top of which these patches were added is: 0c2838d00350afc5259730c35bbda81598e8875f: Linux-omap rebuilt: Updated to -rc7, merged in dmtimer Cc: Sanjeev Premi pr...@ti.com --- Changes in v4: -Rebased and tested against the latest 3.1.0-rc6. -Added a patch [3/3] to check for missing PMIC info in vp init. Changes in v3: Presence of SR feature is now used to decide if TWL4030 initialisation is to be done or not. Changes in v2: Incorporated Kevin's comments to add SmartReflex as a FEATURE, and use omap3_has_sr() to fall out of omap3_twl_init() for AM35x case. Abhilash K V (3): AM35x: Using OMAP3 generic hwmods omap_twl: Prevent SR to enable for am3517/am3505 devices OMAP2+: voltage: add check for missing PMIC info in vp init arch/arm/mach-omap2/id.c |2 +- arch/arm/mach-omap2/io.c | 11 +++ arch/arm/mach-omap2/omap_hwmod.c |2 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 18 ++ arch/arm/mach-omap2/pm.c |3 ++- arch/arm/mach-omap2/vp.c |7 +++ arch/arm/plat-omap/include/plat/cpu.h|2 ++ arch/arm/plat-omap/include/plat/omap_hwmod.h |3 +++ 8 files changed, 46 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices
In case of AM3517 AM3505, SmartReflex is not applicable so
we must not enable it. So omap3_twl_init() is now not called
when the processor does not support SR.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/id.c |2 +-
arch/arm/mach-omap2/pm.c |3 ++-
arch/arm/plat-omap/include/plat/cpu.h |2 ++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index d27daf9..b7e3082 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -188,7 +188,7 @@ static void __init omap3_check_features(void)
if (cpu_is_omap3630())
omap_features |= OMAP3_HAS_192MHZ_CLK;
if (!cpu_is_omap3505() !cpu_is_omap3517())
- omap_features |= OMAP3_HAS_IO_WAKEUP;
+ omap_features |= (OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_SR);
omap_features |= OMAP3_HAS_SDRC;
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index d34fc52..da71abc 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -252,7 +252,8 @@ postcore_initcall(omap2_common_pm_init);
static int __init omap2_common_pm_late_init(void)
{
/* Init the OMAP TWL parameters */
- omap3_twl_init();
+ if (omap3_has_sr())
+ omap3_twl_init();
omap4_twl_init();
/* Init the voltage layer */
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 2f90269..cc6fcd3 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -413,6 +413,7 @@ extern u32 omap_features;
#define OMAP4_HAS_MPU_1GHZ BIT(8)
#define OMAP4_HAS_MPU_1_2GHZ BIT(9)
#define OMAP4_HAS_MPU_1_5GHZ BIT(10)
+#define OMAP3_HAS_SR BIT(11)
#define OMAP3_HAS_FEATURE(feat,flag) \
@@ -429,6 +430,7 @@ OMAP3_HAS_FEATURE(isp, ISP)
OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
OMAP3_HAS_FEATURE(sdrc, SDRC)
+OMAP3_HAS_FEATURE(sr, SR)
/*
* Runtime detection of OMAP4 features
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/3] AM35x: Using OMAP3 generic hwmods
This patch enables AM35x SoCs to use generic OMAP3 hwmods
(i,e. omap3xxx_hwmods) by allowing am35xx_init_early() to
disable the modules which are not present in AM3517.
Reviewed-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/io.c | 11 +++
arch/arm/mach-omap2/omap_hwmod.c |2 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 18 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |3 +++
4 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 15f91c4..6a6e2cc 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -240,6 +240,16 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
};
#endif
+static char *am3517_unused_hwmods[] = {
+ iva,
+ sr1_hwmod,
+ sr2_hwmod,
+ mailbox,
+ usb_otg_hs,
+ NULL,
+};
+
+
static void __init _omap2_map_common_io(void)
{
/* Normally devicemaps_init() would flush caches and tlb after
@@ -432,6 +442,7 @@ void __init omap3630_init_early(void)
void __init am35xx_init_early(void)
{
+ omap2_disable_unused_hwmods(am3517_unused_hwmods);
omap2_init_common_infrastructure();
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index d713807..c7b0395 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1954,6 +1954,8 @@ int __init omap_hwmod_register(struct omap_hwmod **ohs)
i = 0;
do {
+ if (ohs[i]-flags HWMOD_UNUSED)
+ continue;
r = _register(ohs[i]);
WARN(r, omap_hwmod: %s: _register returned %d\n, ohs[i]-name,
r);
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3008e16..682171c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3259,6 +3259,24 @@ static __initdata struct omap_hwmod *am35xx_hwmods[] = {
NULL
};
+void __init omap2_disable_unused_hwmods(char *unused_hwmods[])
+{
+ int index;
+
+ for (index = 0; omap3xxx_hwmods[index]; index++) {
+ char **hwmods = unused_hwmods;
+ while (*hwmods) {
+ if (strcmp(omap3xxx_hwmods[index]-name,
+ *hwmods) == 0) {
+ omap3xxx_hwmods[index]-flags
+ = HWMOD_UNUSED;
+ break;
+ }
+ hwmods++;
+ }
+ }
+}
+
int __init omap3xxx_hwmod_init(void)
{
int r;
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 5419f1a..96650f3 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -398,6 +398,7 @@ struct omap_hwmod_omap4_prcm {
* in order to complete the reset. Optional clocks will be disabled
* again after the reset.
* HWMOD_16BIT_REG: Module has 16bit registers
+ * HWMOD_UNUSED: The IP for this module is unused or disabled on current SoC
*/
#define HWMOD_SWSUP_SIDLE (1 0)
#define HWMOD_SWSUP_MSTANDBY (1 1)
@@ -408,6 +409,7 @@ struct omap_hwmod_omap4_prcm {
#define HWMOD_NO_IDLEST(1 6)
#define HWMOD_CONTROL_OPT_CLKS_IN_RESET(1 7)
#define HWMOD_16BIT_REG(1 8)
+#define HWMOD_UNUSED (1 9)
/*
* omap_hwmod._int_flags definitions
@@ -612,5 +614,6 @@ extern int omap2420_hwmod_init(void);
extern int omap2430_hwmod_init(void);
extern int omap3xxx_hwmod_init(void);
extern int omap44xx_hwmod_init(void);
+extern void omap2_disable_unused_hwmods(char *unused_hwmods[]);
#endif
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/3] OMAP2+: voltage: add check for missing PMIC info in vp init
If PMIC info is not available in omap_vp_init(), abort.
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/vp.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 66bd700..2c99837 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -41,6 +41,13 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
u32 val, sys_clk_rate, timeout, waittime;
u32 vddmin, vddmax, vstepmin, vstepmax;
+ if (!voltdm-pmic || !voltdm-pmic-uv_to_vsel) {
+ pr_err(%s: PMIC info requried to configure vp for
+ vdd_%s not populated.Hence cannot initialize vp\n,
+ __func__, voltdm-name);
+ return;
+ }
+
if (!voltdm-read || !voltdm-write) {
pr_err(%s: No read/write API for accessing vdd_%s regs\n,
__func__, voltdm-name);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] AM35x: voltage: Basic initialization
This patch adds the basic initialization of voltage layer
for AM35x. Since AM35x doesn't support voltage scaling,
Many functions have been defined to plug into existing
voltage layer.
Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/omap_opp_data.h |1 +
arch/arm/mach-omap2/opp3xxx_data.c|9 +
arch/arm/mach-omap2/voltagedomains3xxx_data.c | 10 --
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_opp_data.h
b/arch/arm/mach-omap2/omap_opp_data.h
index c784c12..c7cedf3 100644
--- a/arch/arm/mach-omap2/omap_opp_data.h
+++ b/arch/arm/mach-omap2/omap_opp_data.h
@@ -88,6 +88,7 @@ extern struct omap_volt_data omap34xx_vddmpu_volt_data[];
extern struct omap_volt_data omap34xx_vddcore_volt_data[];
extern struct omap_volt_data omap36xx_vddmpu_volt_data[];
extern struct omap_volt_data omap36xx_vddcore_volt_data[];
+extern struct omap_volt_data am35xx_vdd_volt_data[];
extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[];
extern struct omap_volt_data omap44xx_vdd_iva_volt_data[];
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index d95f3f9..e4a5ee6 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -85,6 +85,15 @@ struct omap_volt_data omap36xx_vddcore_volt_data[] = {
VOLT_DATA_DEFINE(0, 0, 0, 0),
};
+/* AM35x
+ *
+ * Fields related to SmartReflex and Voltage Processor are set to 0.
+ */
+struct omap_volt_data am35xx_vdd_volt_data[] = {
+ VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP3_UV, 0x0, 0x0, 0x0),
+ VOLT_DATA_DEFINE(0, 0, 0, 0),
+};
+
/* OPP data */
static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
index 071101d..530082f 100644
--- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
@@ -85,7 +85,10 @@ void __init omap3xxx_voltagedomains_init(void)
* XXX Will depend on the process, validation, and binning
* for the currently-running IC
*/
- if (cpu_is_omap3630()) {
+ if (cpu_is_omap3505() || cpu_is_omap3517()) {
+ omap3_voltdm_mpu.volt_data = am35xx_vdd_volt_data;
+ omap3_voltdm_core.volt_data = am35xx_vdd_volt_data;
+ } else if (cpu_is_omap3630()) {
omap3_voltdm_mpu.volt_data = omap36xx_vddmpu_volt_data;
omap3_voltdm_core.volt_data = omap36xx_vddcore_volt_data;
} else {
@@ -93,8 +96,11 @@ void __init omap3xxx_voltagedomains_init(void)
omap3_voltdm_core.volt_data = omap34xx_vddcore_volt_data;
}
- for (i = 0; voltdm = voltagedomains_omap3[i], voltdm; i++)
+ for (i = 0; voltdm = voltagedomains_omap3[i], voltdm; i++) {
+ if (cpu_is_omap3505() || cpu_is_omap3517())
+ voltdm-scalable = false;
voltdm-sys_clk.name = sys_clk_name;
+ }
voltdm_init(voltagedomains_omap3);
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] AM35x: Adding PM init
This patch-set fixes the power and voltage management initialization sequence for AM35x. These patches are dependent on the following patch-set [PATCH v4 0/3] AM3517: Booting up which gets the AM3517 EVM booting. The patches are tested on master of git://github.com/tmlind/linux.git Kernel version is 3.1.0-rc6 and last commit on top of which these patches were added is: 0c2838d00350afc5259730c35bbda81598e8875f: Linux-omap rebuilt: Updated to -rc7, merged in dmtimer Cc: Sanjeev Premi pr...@ti.com --- Changes in v3: * Reworked against the cleaned-up voltage management layer. Changes in v2: * TWL4030 CORE and POWER drivers are no longer built only for ARM and OMAP * changed comments to mark AM35x voltgate-scaling code as ad hoc Abhilash K V (2): AM35x: voltage: Basic initialization OMAP3: Remove auto-selection of PMICs Sanjeev Premi (1): OMAP3: Add support for TPS65023 (AM35x only) arch/arm/configs/omap2plus_defconfig |3 + arch/arm/mach-omap2/Kconfig |3 - arch/arm/mach-omap2/Makefile |3 +- arch/arm/mach-omap2/omap_opp_data.h |1 + arch/arm/mach-omap2/opp3xxx_data.c|9 +++ arch/arm/mach-omap2/pm.c |1 + arch/arm/mach-omap2/pm.h |9 +++ arch/arm/mach-omap2/pmic_tps65023.c | 84 + arch/arm/mach-omap2/voltagedomains3xxx_data.c | 10 +++- drivers/mfd/Kconfig |2 +- 10 files changed, 118 insertions(+), 7 deletions(-) create mode 100644 arch/arm/mach-omap2/pmic_tps65023.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 v3 3/3] OMAP3: Remove auto-selection of PMICs
The current implementation almost assumes that only TWL4030/TWL5030/TWl6030 are (or can be) used with the OMAP processors. This is, however, not true. This patch removes the automatic selection of the PMIC from Kconfig. All currently used PMICs are now added to omap2plus_defconfig; any new PMIC that gets supported in future could now be enabled here rather than by changing Kconfig for ARCH_OMAP2PLUS_TYPICAL Signed-off-by: Sanjeev Premi pr...@ti.com Signed-off-by: Abhilash K V abhilash...@ti.com --- arch/arm/configs/omap2plus_defconfig |3 +++ arch/arm/mach-omap2/Kconfig |3 --- drivers/mfd/Kconfig |2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index d5f00d7..076b131 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -130,6 +130,9 @@ CONFIG_POWER_SUPPLY=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y +CONFIG_MENELAUS=y +CONFIG_TWL4030_CORE=y +CONFIG_TWL4030_POWER=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 7edf802..d40f6d2 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -15,9 +15,6 @@ config ARCH_OMAP2PLUS_TYPICAL select I2C select I2C_OMAP select MFD_SUPPORT - select MENELAUS if ARCH_OMAP2 - select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 - select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 help Compile a kernel suitable for booting most boards diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 21574bd..72e15c8 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -238,7 +238,7 @@ config TWL4030_MADC config TWL4030_POWER bool Support power resources on TWL4030 family chips - depends on TWL4030_CORE ARM + depends on TWL4030_CORE help Say yes here if you want to use the power resources on the TWL4030 family chips. Most of these resources are regulators, -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] OMAP3: Add support for TPS65023 (AM35x only)
From: Sanjeev Premi pr...@ti.com
This patch adds support for TPS65023 used with
OMAP3 devices. The PMIC is currently hooked to
AM35x devices, but can easily be extended for
other OMAP3 devices.
Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/pm.c|1 +
arch/arm/mach-omap2/pm.h|9
arch/arm/mach-omap2/pmic_tps65023.c | 84 +++
4 files changed, 96 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/pmic_tps65023.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 46a3497..e71e4bc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -18,7 +18,8 @@ obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common)
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
-obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
+obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
+obj-$(CONFIG_REGULATOR_TPS65023) += pmic_tps65023.o
# SMP support ONLY available for OMAP4
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index da71abc..bb64383 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -255,6 +255,7 @@ static int __init omap2_common_pm_late_init(void)
if (omap3_has_sr())
omap3_twl_init();
omap4_twl_init();
+ omap3_tps65023_init();
/* Init the voltage layer */
omap_voltage_late_init();
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4e166ad..ce028f6 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -133,5 +133,14 @@ static inline int omap4_twl_init(void)
return -EINVAL;
}
#endif
+#ifdef CONFIG_REGULATOR_TPS65023
+extern int omap3_tps65023_init(void);
+#else
+static inline int omap3_tps65023_init(void)
+{
+ return -EINVAL;
+}
+#endif
+
#endif
diff --git a/arch/arm/mach-omap2/pmic_tps65023.c
b/arch/arm/mach-omap2/pmic_tps65023.c
new file mode 100644
index 000..415d804
--- /dev/null
+++ b/arch/arm/mach-omap2/pmic_tps65023.c
@@ -0,0 +1,84 @@
+/**
+ * Implements support for TPS65023
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.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 version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/i2c/twl.h
+
+#include voltage.h
+
+#include pm.h
+
+#defineTPS65023_VDCDC1_MIN 80 /* 0.8V */
+#defineTPS65023_VDCDC1_STEP25000 /* 0.025V */
+
+
+/*
+ * Get voltage corresponding to specified vsel value using this formula:
+ * Vout = 0.8V + (25mV x Vsel)
+ */
+static unsigned long tps65023_vsel_to_uv(const u8 vsel)
+{
+ return TPS65023_VDCDC1_MIN + (TPS65023_VDCDC1_STEP * vsel);
+}
+
+/*
+ * Get vsel value corresponding to specified voltage using this formula:
+ * Vsel = (Vout - 0.8V)/ 25mV
+ */
+static u8 tps65023_uv_to_vsel(unsigned long uv)
+{
+ return DIV_ROUND_UP(uv - TPS65023_VDCDC1_MIN, TPS65023_VDCDC1_STEP);
+}
+
+/*
+ * TPS65023 is currently supported only for AM35x devices.
+ * Therefore, implementation below is specific to this device pair.
+ */
+
+/**
+ * Voltage information related to the MPU voltage domain of the
+ * AM35x processors - in relation to the TPS65023.
+ */
+static struct omap_voltdm_pmic tps65023_am35xx_mpu_volt_info = {
+ .step_size = 25000,
+ .on_volt= 120,
+ .vsel_to_uv = tps65023_vsel_to_uv,
+ .uv_to_vsel = tps65023_uv_to_vsel,
+};
+
+int __init omap3_tps65023_init(void)
+{
+ struct voltagedomain *voltdm;
+
+ if (!cpu_is_omap34xx())
+ return -ENODEV;
+
+ if (cpu_is_omap3505() || cpu_is_omap3517()) {
+ voltdm = voltdm_lookup(mpu);
+ omap_voltage_register_pmic(voltdm,
+ tps65023_am35xx_mpu_volt_info);
+ voltdm = voltdm_lookup(core);
+ omap_voltage_register_pmic(voltdm,
+ tps65023_am35xx_mpu_volt_info);
+ } else {
+ /* TODO:
+* Support for other devices that support TPS65023
+*/
+ }
+
+ return 0;
+}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH 0/5 v11] mfd: omap: usb: Runtime PM support for EHCI and OHCI drivers
Hi, On Thu, Sep 22, 2011 at 7:37 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com The Hwmod structures and Runtime PM features are implemented For EHCI and OHCI drivers of OMAP3 and OMAP4. The global suspend/resume of EHCI and OHCI is validated on OMAP3430 sdp board with these patches. These patches are re-based to Kevin's pm branch : git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Is kernel.org up now? :-) thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe 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/5 v11] mfd: omap: usb: Runtime PM support for EHCI and OHCI drivers
On Thu, Sep 22, 2011 at 7:02 PM, Ming Lei tom.leim...@gmail.com wrote: Hi, On Thu, Sep 22, 2011 at 7:37 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com The Hwmod structures and Runtime PM features are implemented For EHCI and OHCI drivers of OMAP3 and OMAP4. The global suspend/resume of EHCI and OHCI is validated on OMAP3430 sdp board with these patches. These patches are re-based to Kevin's pm branch : git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Is kernel.org up now? :-) thanks, -- Ming Lei no! its kevin tree, which i took it 3 weeks back. :-( regards keshava -- To unsubscribe from this list: send the line unsubscribe 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] iommu/omap: Fix build error with !IOMMU_SUPPORT
On Tue, Sep 20, 2011 at 1:54 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Tuesday 20 September 2011 12:01:46 Roedel, Joerg wrote: On Sat, Sep 17, 2011 at 08:02:22PM -0400, Laurent Pinchart wrote: On Wednesday 14 September 2011 16:07:39 Joerg Roedel wrote: Without this patch it is possible to select the VIDEO_OMAP3 driver which then selects OMAP_IOVMM. But the omap iommu driver is not compiled without IOMMU_SUPPORT enabled. Fix that by forcing OMAP_IOMMU and OMAP_IOVMM are enabled before VIDEO_OMAP3 can be selected. What about making VIDEO_OMAP3 select IOMMU_SUPPORT instead then ? Your patch would make the OMAP3 ISP driver disappear from the menu until IOMMU_SUPPORT gets turned on, which can confuse users. Using 'depends on' rather then 'selects' is common standard in Kconfig. You can't select PCI drivers without selecting PCI first, for example. You wouldn't expect a PCI driver to work without PCI support. My concern is that most OMAP3 ISP users won't know that IOMMU supports is required. Feel free to ignore it though :-) I agree with Laurent. As a user, why should I care about IOMMU? I just want this thing. That's why DRM_RADEON_KMS selects BACKLIGHT_CLASS_DEVICE; it's an implementation detail that the user should not need to care about. Why should I need to go see the dependencies of DRM_RADEON_KMS and manually select all of them? I shouldn't, that's the reason 'select' exists in the first place. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap cleanup part1 for v3.2 merge window
On Wednesday 21 September 2011, Kevin Hilman wrote: Found. Patch below. If this one is OK, I'll push to my for_3.2/voltage-cleanup branch (which is already pulled into arm-soc/next/voltage) so just re-pulling will pick up the fix. Looks good to me, it's always nice when a bug fix is also a cleanup ;-) Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-omap git tree ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I would like to clone the linux-omap git tree but git.kernel.org is down. Is there any backup somewhere ? Thanks -- Daniel - -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOe0pwAAoJEAKBbMCpUGYAHf4IAKbHErpvnghNHWoK4Q4cXGQP XzYet4j8yWUNkxCZcUA97a58jttEseKkj83grysv538j/pfD9n2hlNnMpijlksbk gTX2cj0m84XKbdznwyHAe13qZUE0oSKdhMULZ9MHkAjFFMVk93nd0B+LJxMcQPMr tkpbXL+z9g17JqWn+l02my3jr2dO11LfeRIRT/kB5R3cbDDMtI9DpKz//c3iaEwI RRMO6GbmrNzYgSR3yXDEHOJaY0PHHlN3MGOY48fUhM+jWz0JqJfQPA5sDzswkzBI KytsxDDbH6nNzGTN22wRFt9bXEZYysJWwzi9UAmyyKHsck6cMWK5Qhozc76LMJs= =faqL -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 37/57] mmc: irq: Remove IRQF_DISABLED
On Wed, Sep 21, 2011 at 2:58 PM, Yong Zhang yong.zha...@gmail.com wrote:
Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled],
We run all interrupt handlers with interrupts disabled
and we even check and yell when an interrupt handler
returns with interrupts enabled (see commit [b738a50a:
genirq: Warn when handler enables interrupts]).
So now this flag is a NOOP and can be removed.
Signed-off-by: Yong Zhang yong.zha...@gmail.com
For omap_hsmmc.c
Acked-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 5 ++---
drivers/mmc/host/tmio_mmc.c | 4 ++--
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21e4a79..75c6395 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2015,7 +2015,7 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
}
/* Request IRQ for MMC operations */
- ret = request_irq(host-irq, omap_hsmmc_irq, IRQF_DISABLED,
+ ret = request_irq(host-irq, omap_hsmmc_irq, 0,
mmc_hostname(mmc), host);
if (ret) {
dev_dbg(mmc_dev(host-mmc), Unable to grab HSMMC IRQ\n);
@@ -2043,8 +2043,7 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
if ((mmc_slot(host).card_detect_irq)) {
ret = request_irq(mmc_slot(host).card_detect_irq,
omap_hsmmc_cd_handler,
- IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING
- | IRQF_DISABLED,
+ IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
mmc_hostname(mmc), host);
if (ret) {
dev_dbg(mmc_dev(host-mmc),
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index 44a9668..a4ea102 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -88,8 +88,8 @@ static int __devinit tmio_mmc_probe(struct platform_device
*pdev)
if (ret)
goto cell_disable;
- ret = request_irq(irq, tmio_mmc_irq, IRQF_DISABLED |
- IRQF_TRIGGER_FALLING, dev_name(pdev-dev), host);
+ ret = request_irq(irq, tmio_mmc_irq, IRQF_TRIGGER_FALLING,
+ dev_name(pdev-dev), host);
if (ret)
goto host_remove;
--
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: linux-omap git tree ?
Hi, You can use https://github.com/tmlind/linux/commits/master. Regards, Jean On Thu, Sep 22, 2011 at 4:47 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I would like to clone the linux-omap git tree but git.kernel.org is down. Is there any backup somewhere ? Thanks -- Daniel - -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOe0pwAAoJEAKBbMCpUGYAHf4IAKbHErpvnghNHWoK4Q4cXGQP XzYet4j8yWUNkxCZcUA97a58jttEseKkj83grysv538j/pfD9n2hlNnMpijlksbk gTX2cj0m84XKbdznwyHAe13qZUE0oSKdhMULZ9MHkAjFFMVk93nd0B+LJxMcQPMr tkpbXL+z9g17JqWn+l02my3jr2dO11LfeRIRT/kB5R3cbDDMtI9DpKz//c3iaEwI RRMO6GbmrNzYgSR3yXDEHOJaY0PHHlN3MGOY48fUhM+jWz0JqJfQPA5sDzswkzBI KytsxDDbH6nNzGTN22wRFt9bXEZYysJWwzi9UAmyyKHsck6cMWK5Qhozc76LMJs= =faqL -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe 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-omap git tree ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/22/2011 04:53 PM, Jean Pihet wrote: Hi, You can use https://github.com/tmlind/linux/commits/master. Thank you Jean ! - -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOe0+1AAoJEAKBbMCpUGYATYcH/2PLTI5uY+G70qKTS8KIZ5H6 1wZcRrejBaIyM+gWUDQm5V8BMxCxlG+I4BwWrOcWo7A4YNvB2wZX765ygPVKB1Qv NmaC7GFWRAFmwHE57OYoClsLeXXYGHv91FRcrBtwzvu57Snh5th/1dmD5O+wM+vu VHBZn8TO/ZnEfUTT4lmg2lHc3/a2HcH1hdjynJdFYOhf1Csd5rWwGGh263vXA0cO dIn3+l5MeZS9uOwMfEMkzylixWssGdLaGlUW/uqLfUvaB9Q7Ga3J+XXxQV2Kwu3/ pJytSF00/fstOTVwI8VBEMbUkNwr1iPCIJVLLPsf4WKazOhHxIOWcNVCOvzx6YY= =19IQ -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/26] gpio/omap: driver cleanup and fixes
On Tue, Sep 13, 2011 at 6:32 PM, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
This series is continuation of cleanup of OMAP GPIO driver and fixes.
The cleanup include getting rid of cpu_is_* checks wherever possible,
use of gpio_bank list instead of static array, use of unique platform
specific value associated data member to OMAP platforms to avoid
cpu_is_* checks. The series also include PM runtime support.*
Baseline: git://gitorious.org/khilman/linux-omap-pm.git
Branch: for_3.2/gpio-cleanup
Commit: 8323374
Thanks Tony for ack'ing the patches.
Kevin,
Since Tony's has acked the patches, can you please pull them?
Thanks.
--
Tarun
Test Details:
- Compile tested for omap1_defconfig and omap2plus_defconfig.
- OMAP1710-H3: Bootup test.
- OMAP2430/SDP, OMAP3430/SDP, OMAP4430/SDP: Functional testing.
- PM Testing on OMAP3430-SDP: retention, off_mode, system_wide
suspend and gpio wakeup.
v7:
- Use pm_runtime_put() instead of pm_runtime_put_sync_suspend()
- Keep *_runtime_get/put*() outside spinlock
- Remove additional checking of conditions in _restore_context()
From:
if (bank-regs-set_dataout bank-regs-clear_dataout)
...
To:
if (bank-regs-set_dataout)
...
- Use SET_RUNTIME_PM_OPS and SET_SYSTEM_SLEEP_PM_OPS macros
- In [PATCH 19/25] gpio/omap: cleanup prepare_for_idle and resume_after_idle,
protect the bank data elements and register access using spinlock in
runtime_suspend/resume() callbacks.
This is because these callbacks run with interrupts enabled.
- Add dbclk aliases for all GPIO modules. Without this, GPIO modules were not
getting the correct clock handle to enable/disable debounec clock.
- Fix log comments on the following patches:
[PATCH 19/25] gpio/omap: cleanup prepare_for_idle and resume_after_idle
[PATCH 20/25] gpio/omap: skip operations in runtime callbacks
[PATCH 24/25] gpio/omap: restore OE only after setting the output level
v6:
- Save and restore debounce registers for proper driver operation.
- Restore interrupt enable after all configuration to avoid spurious
interrupts.
- Restore dataout register before oe register.
- Restore dataout into dataout_set or dataout based upon the OMAP version.
- Change register name from wkup_status to wkup_en.
- Remove wrapper around omap_pm_get_dev_context_loss_count(). Use it directly.
Also, changed the signature of get_context_loss_count in pdata and bank
structure
from int to u32.
- Use 'context' instead of 'ctx' for clarity wherever it is used.
- Merged two patches into one which are related to bank_is_mpuio()
modification.
- Use shift operator instead of following:
+ .irqctrl = OMAP_MPUIO_GPIO_INT_EDGE / 2,
- Remove redundant check from the following
+ if (bank_is_mpuio(bank)) {
+ if (bank-regs-wkup_status) --- redundant check
+ mpuio_init(bank);
- Change subject of following patch
[PATCH v5 15/22] gpio/omap: use readl in irq_handler for all access
into
[PATCH 14/25] gpio/omap: remove unnecessary bit-masking for read access
- Fix multi-line comments in
[PATCH v5 20/22] gpio/omap: cleanup prepare_for_idle and resume_after_idle
v5:
- Reduce runtime callback overhead when *_get/put_sync() called from probe()
and *_gpio_request/free().
- Dynamic context save within functions where context is modified instead of
saving all context within a common function.
- Removed call to mpuio_init() from omap_gpio_mod_init(). Both the functions
are
called once during initialization in *_gpio_probe().
Call to omap_gpio_mod_init() has been removed from omap_gpio_request() on the
first access to gpio bank. One time initialization looks sufficient.
- In *_gpio_irq_handler() use *_put_sync_suspend() instead of *_put_sync().
- Removed hardcoding of OMAP16xx sysconfig register value and instead defined
an
associated constant.
- Removed *_get_sync() call from *_gpio_suspend() and *_put_sync() call from
*_gpio_resume(). They got wrongly slipped into the code.
- Removed following redundant zero allocated initialization from
mach-omap2/gpio.c
+ pdata-regs-irqctrl = 0;
+ pdata-regs-edgectrl1 = 0;
+ pdata-regs-edgectrl2 = 0;
- Removed following redundant code in gpio-omap.c
-#define bank_is_mpuio(bank) ((bank)-method == METHOD_MPUIO)
v4:
- since all accesses to registers are 4-byte aligned, removing special
checks and handling of 16 and 32-bit wide bank registers and instead
use 32-bit read/write access consistently.
- redundant usage of MOD_REG_BIT has been corrected and replaced with
_gpio_rmw().
- omap_gpio_mod_init() function has been simplified further using _gpio_rmw().
- sysconfig register offset specific to omap16xx has been removed along
with its usage.
- additional logic to skip from suspend/resume:
if (!bank-regs-wkup_status || !bank-suspend_wakeup)
return 0;
if (!bank-regs-wkup_status || !bank-saved_wakeup)
return 0;
[PATCH 0/6] system control module device and support for temperature sensor
The patch series adds support of system control module device and adds support temperature sensor. The patch series adds hwmod for system control module and enables the clocks for temperature sensor. The OMAP4460 specific register set data for the on die mpu temperature sensor is also part of this series. Benoit Cousson (1): OMAP4: Hwmod: system control module hwmod Keerthy (4): OMAP4: Adding the temperature sensor register set bit fields OMAP4: Clock: Associate clocks for OMAP temperature sensor OMAP4460: Temperature sensor data OMAP4: System control module device support Vishwanath BS (1): OMAP4460: Clock: Adding support for 4460 specific clocks arch/arm/mach-omap2/Makefile |3 +- arch/arm/mach-omap2/clock44xx_data.c | 16 +- .../include/mach/ctrl_module_core_44xx.h | 70 +++-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 71 arch/arm/mach-omap2/scm_device.c | 125 ++ arch/arm/mach-omap2/temp_sensor4460_data.c | 115 + arch/arm/plat-omap/Kconfig | 12 ++ arch/arm/plat-omap/include/plat/scm.h | 175 8 files changed, 565 insertions(+), 22 deletions(-) create mode 100644 arch/arm/mach-omap2/scm_device.c create mode 100644 arch/arm/mach-omap2/temp_sensor4460_data.c create mode 100644 arch/arm/plat-omap/include/plat/scm.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] OMAP4: Clock: Associate clocks for OMAP temperature sensor
div_ts_ck feeds only the temperature sensor functional clock
and also has a clksel associated (for divider selection). Mapping this
as well as the bandgap_ts_fclk the fclk of temperature sensor in clkdev table,
so a clk_set_rate() on the div_ts_ck in the driver would have the effect of
changing the temperature sensor clock rate indirectly.
Signed-off-by: Keerthy j-keer...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
Cc: t...@atomide.com
Cc: p...@pwsan.com
---
arch/arm/mach-omap2/clock44xx_data.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 946bf04..c51e513 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3185,9 +3185,9 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, aes2_fck, aes2_fck,
CK_443X),
CLK(NULL, aess_fck, aess_fck,
CK_443X),
CLK(NULL, bandgap_fclk, bandgap_fclk,
CK_443X),
- CLK(NULL, bandgap_ts_fclk, bandgap_ts_fclk,
CK_446X),
+ CLK(omap4460plus_scm.0, fck, bandgap_ts_fclk,
CK_446X),
CLK(NULL, des3des_fck, des3des_fck,
CK_443X),
- CLK(NULL, div_ts_ck,div_ts_ck,
CK_446X),
+ CLK(omap4460plus_scm.0, div_ck,
div_ts_ck, CK_446X),
CLK(NULL, dmic_sync_mux_ck, dmic_sync_mux_ck,
CK_443X),
CLK(NULL, dmic_fck, dmic_fck,
CK_443X),
CLK(NULL, dsp_fck, dsp_fck,
CK_443X),
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] OMAP4460: Temperature sensor data
The register set and the
bit fields might vary across OMAP versions. Hence
creating a structure comprising of all the registers
and bit fields to make the driver uniform for all the
versions with different register sets. The data file
contains the structure populated with register offsets
and bit fields corresponding to OMAP4460 on die sensor.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/temp_sensor4460_data.c | 115 ++
arch/arm/plat-omap/include/plat/scm.h | 175
3 files changed, 291 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/temp_sensor4460_data.c
create mode 100644 arch/arm/plat-omap/include/plat/scm.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 46a3497..e6f8d36 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -86,7 +86,7 @@ obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o
prm2xxx_3xxx.o \
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 temp_sensor4460_data.o
# OMAP voltage domains
ifeq ($(CONFIG_PM),y)
diff --git a/arch/arm/mach-omap2/temp_sensor4460_data.c
b/arch/arm/mach-omap2/temp_sensor4460_data.c
new file mode 100644
index 000..2804615
--- /dev/null
+++ b/arch/arm/mach-omap2/temp_sensor4460_data.c
@@ -0,0 +1,115 @@
+/*
+ * OMAP4460 on die Temperature sensor data file
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: J Keerthy j-keer...@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.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/slab.h
+#include control.h
+#include plat/scm.h
+
+/*
+ * OMAP4460 has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+struct omap_temp_sensor_registers omap_mpu_temp_sensor_registers = {
+ .temp_sensor_ctrl = OMAP4460_TEMP_SENSOR_CTRL_OFFSET,
+ .bgap_tempsoff_mask = OMAP4460_BGAP_TEMPSOFF_MASK,
+ .bgap_soc_mask = OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK,
+ .bgap_eocz_mask = OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASK,
+ .bgap_dtemp_mask= OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK,
+
+ .bgap_mask_ctrl = OMAP4460_BGAP_CTRL_OFFSET,
+ .mask_hot_mask = OMAP4460_MASK_HOT_MASK,
+ .mask_cold_mask = OMAP4460_MASK_COLD_MASK,
+
+ .bgap_mode_ctrl = OMAP4460_BGAP_CTRL_OFFSET,
+ .mode_ctrl_mask = OMAP4460_SINGLE_MODE_MASK,
+
+ .bgap_counter = OMAP4460_BGAP_COUNTER_OFFSET,
+ .counter_mask = OMAP4460_COUNTER_MASK,
+
+ .bgap_threshold = OMAP4460_BGAP_THRESHOLD_OFFSET,
+ .threshold_thot_mask= OMAP4460_T_HOT_MASK,
+ .threshold_tcold_mask = OMAP4460_T_COLD_MASK,
+
+ .thsut_threshold= OMAP4460_BGAP_TSHUT_OFFSET,
+ .tshut_hot_mask = OMAP4460_TSHUT_HOT_MASK,
+ .tshut_cold_mask= OMAP4460_TSHUT_COLD_MASK,
+
+ .bgap_status= OMAP4460_BGAP_STATUS_OFFSET,
+ .status_clean_stop_mask = OMAP4460_CLEAN_STOP_MASK,
+ .status_bgap_alert_mask = OMAP4460_BGAP_ALERT_MASK,
+ .status_hot_mask= OMAP4460_HOT_FLAG_MASK,
+ .status_cold_mask = OMAP4460_COLD_FLAG_MASK,
+
+ .bgap_efuse = OMAP4460_FUSE_OPP_BGAP,
+};
+
+/*
+ * Temperature values in milli degree celsius
+ * ADC code values from 530 to 923
+ */
+int adc_to_temp[OMAP_ADC_END_VALUE - OMAP_ADC_START_VALUE + 1] = {
+ -4, -4, -4, -4, -39800, -39400, -39000, -38600, -38200,
+ -37800, -37300, -36800, -36400, -36000, -35600, -35200, -34800,
+ -34300, -33800, -33400, -33000, -32600, -32200, -31800, -31300,
+ -30800, -30400, -3, -29600, -29200, -28700, -28200, -27800,
+ -27400, -27000, -26600, -26200, -25700, -25200,
[PATCH 1/6] OMAP4: Adding the temperature sensor register set bit fields
OMAP4460 specific temperature sensor register bit fields are added. Existing OMAP4 entries are renamed to OMAP4430. Signed-off-by: Keerthy j-keer...@ti.com Cc: t...@atomide.com --- .../include/mach/ctrl_module_core_44xx.h | 70 1 files changed, 57 insertions(+), 13 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h b/arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h index 2f7ac70..725c1e1 100644 --- a/arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h +++ b/arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h @@ -256,19 +256,63 @@ #define OMAP4_LDOSRAMCORE_ACTMODE_VSET_OUT_SHIFT 0 #define OMAP4_LDOSRAMCORE_ACTMODE_VSET_OUT_MASK(0x1f 0) -/* TEMP_SENSOR */ -#define OMAP4_BGAP_TEMPSOFF_SHIFT 12 -#define OMAP4_BGAP_TEMPSOFF_MASK (1 12) -#define OMAP4_BGAP_TSHUT_SHIFT 11 -#define OMAP4_BGAP_TSHUT_MASK (1 11) -#define OMAP4_BGAP_TEMP_SENSOR_CONTCONV_SHIFT 10 -#define OMAP4_BGAP_TEMP_SENSOR_CONTCONV_MASK (1 10) -#define OMAP4_BGAP_TEMP_SENSOR_SOC_SHIFT 9 -#define OMAP4_BGAP_TEMP_SENSOR_SOC_MASK(1 9) -#define OMAP4_BGAP_TEMP_SENSOR_EOCZ_SHIFT 8 -#define OMAP4_BGAP_TEMP_SENSOR_EOCZ_MASK (1 8) -#define OMAP4_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 -#define OMAP4_BGAP_TEMP_SENSOR_DTEMP_MASK (0xff 0) +/* TEMP_SENSOR OMAP4430 */ +#define OMAP4430_BGAP_TEMPSOFF_SHIFT 12 +#define OMAP4430_BGAP_TEMPSOFF_MASK(1 12) +#define OMAP4430_BGAP_TSHUT_SHIFT 11 +#define OMAP4430_BGAP_TSHUT_MASK (1 11) +#define OMAP4430_BGAP_TEMP_SENSOR_CONTCONV_SHIFT 10 +#define OMAP4430_BGAP_TEMP_SENSOR_CONTCONV_MASK(1 10) +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_SHIFT9 +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK (1 9) +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_SHIFT 8 +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASK(1 8) +#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff 0) + +/* TEMP_SENSOR OMAP4460 */ +#define OMAP4460_BGAP_TEMPSOFF_SHIFT 13 +#define OMAP4460_BGAP_TEMPSOFF_MASK(1 13) +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_SHIFT11 +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK (1 11) +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_SHIFT 10 +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASK(1 10) +#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff 0) + +/* BANDGAP_CTRL */ +#define OMAP4460_SINGLE_MODE_SHIFT 31 +#define OMAP4460_SINGLE_MODE_MASK (1 31) +#define OMAP4460_MASK_HOT_SHIFT1 +#define OMAP4460_MASK_HOT_MASK (1 1) +#define OMAP4460_MASK_COLD_SHIFT 0 +#define OMAP4460_MASK_COLD_MASK(1 0) + +/* BANDGAP_COUNTER */ +#define OMAP4460_COUNTER_SHIFT 0 +#define OMAP4460_COUNTER_MASK (0xff 0) + +/* BANDGAP_THRESHOLD */ +#define OMAP4460_T_HOT_SHIFT 16 +#define OMAP4460_T_HOT_MASK(0x3ff 16) +#define OMAP4460_T_COLD_SHIFT 0 +#define OMAP4460_T_COLD_MASK (0x3ff 0) + +/* TSHUT_THRESHOLD */ +#define OMAP4460_TSHUT_HOT_SHIFT 16 +#define OMAP4460_TSHUT_HOT_MASK(0x3ff 16) +#define OMAP4460_TSHUT_COLD_SHIFT 0 +#define OMAP4460_TSHUT_COLD_MASK (0x3ff 0) + +/* BANDGAP_STATUS */ +#define OMAP4460_CLEAN_STOP_SHIFT 3 +#define OMAP4460_CLEAN_STOP_MASK (1 3) +#define OMAP4460_BGAP_ALERT_SHIFT 2 +#define OMAP4460_BGAP_ALERT_MASK (1 2) +#define OMAP4460_HOT_FLAG_SHIFT1 +#define OMAP4460_HOT_FLAG_MASK (1 1) +#define OMAP4460_COLD_FLAG_SHIFT 0 +#define OMAP4460_COLD_FLAG_MASK(1 0) /* DPLL_NWELL_TRIM_0 */ #define OMAP4_DPLL_ABE_NWELL_TRIM_MUX_CTRL_SHIFT 29 -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] OMAP4: System control module device support
The device file adds the device support for OMAP4 system control module.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/scm_device.c | 125 ++
arch/arm/plat-omap/Kconfig | 12
3 files changed, 138 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/scm_device.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index e6f8d36..3332693 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common)
obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common)
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
+obj-$(CONFIG_OMAP_SCM_DEV) += scm_device.o
obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
diff --git a/arch/arm/mach-omap2/scm_device.c b/arch/arm/mach-omap2/scm_device.c
new file mode 100644
index 000..d942f28
--- /dev/null
+++ b/arch/arm/mach-omap2/scm_device.c
@@ -0,0 +1,125 @@
+/*
+ * OMAP4460+ SCM device file
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: J Keerthy j-keer...@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.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/delay.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/mutex.h
+#include linux/idr.h
+#include plat/omap_device.h
+#include pm.h
+#include plat/scm.h
+
+static struct omap_device_pm_latency scm_latency[] = {
+ {
+ .deactivate_func = NULL,
+ .activate_func = NULL,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ }
+};
+
+static DEFINE_IDR(scm_device_idr);
+
+static int scm_dev_init(struct omap_hwmod *oh, void *user)
+{
+ struct omap4460plus_scm_pdata *scm_pdata;
+ struct omap_device *od;
+ struct omap4460plus_scm_dev_attr *scm_dev_attr;
+ struct omap_temp_sensor_registers *reg_ptr;
+ const char*name_ptr;
+ int ret = 0;
+ int num, i;
+
+ scm_pdata =
+ kzalloc(sizeof(*scm_pdata), GFP_KERNEL);
+ if (!scm_pdata) {
+ dev_err(oh-od-pdev.dev,
+ Unable to allocate memory for scm pdata\n);
+ return -ENOMEM;
+ }
+
+ ret = idr_pre_get(scm_device_idr, GFP_KERNEL);
+ if (ret 0)
+ goto fail_id;
+ ret = idr_get_new(scm_device_idr, scm_pdata, num);
+ if (ret 0)
+ goto fail_id;
+ scm_dev_attr = oh-dev_attr;
+ scm_pdata-cnt = scm_dev_attr-cnt;
+
+ if (scm_dev_attr-cnt 0) {
+ scm_pdata-name = kzalloc(sizeof(name_ptr) *
+ scm_dev_attr-cnt, GFP_KERNEL);
+ if (!scm_pdata-name) {
+ dev_err(oh-od-pdev.dev,
+ Unable to allocate memory for scm name\n);
+ ret = -ENOMEM;
+ goto fail_id;
+ }
+
+ scm_pdata-registers = kzalloc(sizeof(reg_ptr) *
+ scm_dev_attr-cnt, GFP_KERNEL);
+ if (!scm_pdata-name) {
+ dev_err(oh-od-pdev.dev,
+ Unable to allocate mem for scm registers\n);
+ ret = -ENOMEM;
+ kfree(scm_pdata-name);
+ goto fail_id;
+ }
+
+ for (i = 0; i scm_dev_attr-cnt; i++) {
+ scm_pdata-registers[i] = scm_dev_attr-list[i];
+ scm_pdata-name[i] = scm_dev_attr-name[i];
+ }
+ } else {
+ dev_warn(oh-od-pdev.dev, Invalid device count\n);
+ ret = -EINVAL;
+ goto fail_id;
+ }
+
+ od = omap_device_build(omap4460plus_scm, num,
+ oh, scm_pdata, sizeof(*scm_pdata),
+ scm_latency,
+ ARRAY_SIZE(scm_latency), 0);
+
+ if (IS_ERR(od)) {
+ dev_warn(oh-od-pdev.dev,
+ Could not build omap_device for %s\n, oh-name);
+ ret = PTR_ERR(od);
+ }
+
+fail_id:
+ kfree(scm_pdata);
+
[PATCH 4/6] OMAP4: Hwmod: system control module hwmod
From: Benoit Cousson b-cous...@ti.com
Adding the system control module hwmod.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 71
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 393afac..af77ec6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -30,6 +30,7 @@
#include plat/mmc.h
#include plat/i2c.h
#include plat/dmtimer.h
+#include plat/scm.h
#include omap_hwmod_common_data.h
@@ -821,6 +822,73 @@ static struct omap_hwmod omap44xx_aess_hwmod = {
};
/*
+ * 'ctrl_module' class
+ * attila core control module
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_ctrl_module_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = SYSC_HAS_SIDLEMODE,
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_ctrl_module_hwmod_class = {
+ .name = ctrl_module,
+ .sysc = omap44xx_ctrl_module_sysc,
+};
+
+/* ctrl_module_core */
+static struct omap_hwmod omap44xx_ctrl_module_core_hwmod;
+static struct omap_hwmod_irq_info omap44xx_ctrl_module_core_irqs[] = {
+ { .name = sec_evts, .irq = 8 + OMAP44XX_IRQ_GIC_START },
+ { .name = thermal_alert, .irq = 126 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_ctrl_module_core_addrs[] = {
+ {
+ .pa_start = 0x4a002000,
+ .pa_end = 0x4a0027ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_cfg - ctrl_module_core */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__ctrl_module_core = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_ctrl_module_core_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_ctrl_module_core_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* ctrl_module_core slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_ctrl_module_core_slaves[] = {
+ omap44xx_l4_cfg__ctrl_module_core,
+};
+
+/* scm dev_attr */
+static struct omap4460plus_scm_dev_attr scm_dev_attr = {
+ .cnt= 1,
+ .list[0]= omap_mpu_temp_sensor_registers,
+ .name[0]= mpu,
+ .t_shut = 1,
+};
+
+static struct omap_hwmod omap44xx_ctrl_module_core_hwmod = {
+ .name = ctrl_module_core,
+ .class = omap44xx_ctrl_module_hwmod_class,
+ .mpu_irqs = omap44xx_ctrl_module_core_irqs,
+ .main_clk = l4_div_ck,
+ .slaves = omap44xx_ctrl_module_core_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_ctrl_module_core_slaves),
+ .dev_attr = scm_dev_attr,
+ .clkdm_name = l4_wkup_clkdm,
+};
+
+/*
* 'bandgap' class
* bangap reference for ldo regulators
*/
@@ -5409,6 +5477,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
omap44xx_timer10_hwmod,
omap44xx_timer11_hwmod,
+ /* scm hwmod */
+ omap44xx_ctrl_module_core_hwmod,
+
/* uart class */
omap44xx_uart1_hwmod,
omap44xx_uart2_hwmod,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] OMAP4460: Clock: Adding support for 4460 specific clocks
From: Vishwanath BS vishwanath...@ti.com
OMAP4460 specific clocks are not getting added as the
cpu_is_omap44xx is choosing only OMAP4430 specific clock nodes.
Changing it to add to OMAP4460 specific clocks also.
This is clocks are required of temperature sensor.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Keerthy j-keer...@ti.com
Cc: p...@pwsan.com
---
arch/arm/mach-omap2/clock44xx_data.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index c51e513..f72513b 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1398,9 +1398,9 @@ static struct clk dss_dss_clk = {
};
static const struct clksel_rate div3_8to32_rates[] = {
- { .div = 8, .val = 0, .flags = RATE_IN_44XX },
- { .div = 16, .val = 1, .flags = RATE_IN_44XX },
- { .div = 32, .val = 2, .flags = RATE_IN_44XX },
+ { .div = 8, .val = 0, .flags = RATE_IN_4460 },
+ { .div = 16, .val = 1, .flags = RATE_IN_4460 },
+ { .div = 32, .val = 2, .flags = RATE_IN_4460 },
{ .div = 0 },
};
@@ -3403,12 +3403,12 @@ int __init omap4xxx_clk_init(void)
struct omap_clk *c;
u32 cpu_clkflg;
- if (cpu_is_omap44xx()) {
+ if (cpu_is_omap443x()) {
cpu_mask = RATE_IN_4430;
cpu_clkflg = CK_443X;
} else if (cpu_is_omap446x()) {
- cpu_mask = RATE_IN_4460;
- cpu_clkflg = CK_446X;
+ cpu_mask = RATE_IN_4460 | RATE_IN_4430;
+ cpu_clkflg = CK_446X | CK_443X;
} else {
return 0;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap cleanup part1 for v3.2 merge window
Arnd Bergmann a...@arndb.de writes: On Wednesday 21 September 2011, Kevin Hilman wrote: Found. Patch below. If this one is OK, I'll push to my for_3.2/voltage-cleanup branch (which is already pulled into arm-soc/next/voltage) so just re-pulling will pick up the fix. Looks good to me, it's always nice when a bug fix is also a cleanup ;-) OK, added it to the branch you've already pulled[1], if you (re)pull, you'll get the fix too. Thanks, Kevin [1] git://gitorious.org/khilman/linux-omap-pm.git for_3.2/voltage_cleanup -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] OMAP: omap_device cleanup for v3.2
Tony Lindgren t...@atomide.com writes: * Kevin Hilman khil...@ti.com [110915 16:23]: Kevin Hilman khil...@ti.com writes: Please pull this omap_device cleanup series for v3.2. This sets the groundwork for Benoit's DT infrastructure work. Turns out this series has a dependency on a patch[1] in Russell's for-next branch. Russell, any chance of picking this patch into your devel-stable so we have a fixed point to merge with? Or maybe Kevin can add it to his series instead? OK, Russell and I agreed (offline) that I would just take this patch, and he will drop from his for-next branch. I've cherry-picked it into the my branch, and here's the updated pull request. Should have no external dependencies now, and I compile tested for OMAP1 and OMAP2+ on top of the arm-soc/next/cleanup branch. Kevin The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb: Linux 3.1-rc6 (2011-09-12 14:02:02 -0700) are available in the git repository at: git://gitorious.org/khilman/linux-omap-pm.git for_3.2/omap_device Grazvydas Ignotas (1): OMAP: omap_device: make latency autoadjust messages debug Jarkko Nikula (1): omap: mcbsp: Remove omap device API Kevin Hilman (7): OMAP: omap_device: replace debug/warning/error prints with dev_* macros OMAP: omap_device: remove internal functions from omap_device.h OMAP: omap_device: when building return platform_device instead of omap_device OMAP: omap_device: device register functions now take platform_device pointer OMAP: omap_device: _disable_idle_on_suspend() takes platform_device pointer OMAP: omap_device: decouple platform_device from omap_device ARM: 7082/1: platform_device: pdev_archdata: add omap_device pointer arch/arm/include/asm/device.h |5 + arch/arm/mach-omap2/devices.c | 44 +++--- arch/arm/mach-omap2/display.c |6 +- arch/arm/mach-omap2/dma.c | 16 +- arch/arm/mach-omap2/gpio.c| 10 +- arch/arm/mach-omap2/hsmmc.c |8 +- arch/arm/mach-omap2/hwspinlock.c |8 +- arch/arm/mach-omap2/mcbsp.c |8 +- arch/arm/mach-omap2/opp.c |2 +- arch/arm/mach-omap2/pm.c |8 +- arch/arm/mach-omap2/serial.c | 14 +- arch/arm/mach-omap2/sr_device.c |6 +- arch/arm/plat-omap/i2c.c |8 +- arch/arm/plat-omap/include/plat/omap_device.h | 30 ++-- arch/arm/plat-omap/mcbsp.c| 27 arch/arm/plat-omap/omap_device.c | 185 + 16 files changed, 185 insertions(+), 200 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] mfd: OMAP4460+: System control module driver
The system control module has several components. On die temperature is a part
of system control module. The system control module driver registers the
temperature sensor as a client. A hwmon driver for temperature sensor to
route the temperature and the thresholds to the user space.
The system control module driver patch depends on the following series
found here: http://comments.gmane.org/gmane.linux.ports.arm.omap/64436
Signed-off-by: Keerthy j-keer...@ti.com
Cc:sa...@linux.intel.com
---
drivers/mfd/Kconfig|9 +
drivers/mfd/Makefile |2 +-
drivers/mfd/omap4460plus_scm.c | 581
3 files changed, 591 insertions(+), 1 deletions(-)
create mode 100644 drivers/mfd/omap4460plus_scm.c
Index: linux-omap-2.6/drivers/mfd/Kconfig
===
--- linux-omap-2.6.orig/drivers/mfd/Kconfig 2011-09-22 18:35:25.636575640
+0530
+++ linux-omap-2.6/drivers/mfd/Kconfig 2011-09-22 18:35:43.412576517 +0530
@@ -212,6 +212,15 @@
and other features that are often used in portable devices like
cell phones and PDAs.
+config OMAP4460PLUS_SCM
+ bool Texas Instruments OMAP4460 System control module
+ depends on ARCH_OMAP OMAP_SCM_DEV
+ help
+ If you say yes here you get support for the Texas Instruments
+ OMAP4460 system control module. This includes support for
+ on die temperature sensor which is a part of System control
+ module.
+
config TWL4030_CORE
bool Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support
depends on I2C=y GENERIC_HARDIRQS
Index: linux-omap-2.6/drivers/mfd/Makefile
===
--- linux-omap-2.6.orig/drivers/mfd/Makefile2011-09-22 18:35:25.604576115
+0530
+++ linux-omap-2.6/drivers/mfd/Makefile 2011-09-22 18:35:43.416576975 +0530
@@ -42,7 +42,7 @@
obj-$(CONFIG_MFD_TPS65912_I2C) += tps65912-i2c.o
obj-$(CONFIG_MFD_TPS65912_SPI) += tps65912-spi.o
obj-$(CONFIG_MENELAUS) += menelaus.o
-
+obj-$(CONFIG_OMAP4460PLUS_SCM) += omap4460plus_scm.o
obj-$(CONFIG_TWL4030_CORE) += twl-core.o twl4030-irq.o twl6030-irq.o
obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
Index: linux-omap-2.6/drivers/mfd/omap4460plus_scm.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-omap-2.6/drivers/mfd/omap4460plus_scm.c 2011-09-22
18:53:05.132583900 +0530
@@ -0,0 +1,581 @@
+/*
+ * OMAP4 system control module driver file
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: J Keerthy j-keer...@ti.com
+ * Author: Moiz Sonasath m-sonas...@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.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/interrupt.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/platform_device.h
+#include plat/omap_device.h
+#include linux/kernel.h
+#include linux/jiffies.h
+#include linux/err.h
+#include linux/types.h
+#include linux/mutex.h
+#include linux/delay.h
+#include plat/scm.h
+
+#define TSHUT_HOT 920 /* 122 deg C */
+#define TSHUT_COLD 866 /* 100 deg C */
+#define T_HOT 800 /* 73 deg C */
+#define T_COLD 795 /* 71 deg C */
+#define MAX_FREQ 200
+#define MIN_FREQ 100
+#define MIN_TEMP -4
+#define MAX_TEMP 123000
+#define HYST_VAL 5000
+
+static u32 omap4460plus_scm_readl(struct scm
+ *scm_ptr, u32 reg)
+{
+ return __raw_readl(scm_ptr-phy_base + reg);
+}
+
+static void omap4460plus_scm_writel(struct scm *scm_ptr, u32 val, u32 reg)
+{
+ __raw_writel(val, scm_ptr-phy_base + reg);
+}
+
+static int adc_to_temp_conversion(int adc_val)
+{
+ return adc_to_temp[adc_val - OMAP_ADC_START_VALUE];
+}
+
+static int temp_to_adc_conversion(long temp)
+{
+ int high, low, mid;
+
+ if (temp adc_to_temp[0] ||
+ temp adc_to_temp[OMAP_ADC_END_VALUE - OMAP_ADC_START_VALUE])
+ return -EINVAL;
+
+ high = OMAP_ADC_END_VALUE - OMAP_ADC_START_VALUE;
+ low = 0;
+ mid = (high
Re: [RFC PATCH V6 0/4] cpuidle: Global registration of idle states with per-cpu statistics
On 9/22/2011 1:28 AM, Deepthi Dharwar wrote: The following patch series implements global registration of cpuidle states, and also has the necessary data structure changes to accommodate the per-cpu writable members of the cpuidle_states structure. you can consider this series Acked-by: Arjan van de Ven ar...@linux.intel.com it's a good simplification of the code, and unlike frequencies, idle states are really shared between all cpus for very practical reasons. -- To unsubscribe from this list: send the line unsubscribe 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] hwmon: OMAP4460+: On die temperature sensor driver
On chip temperature sensor driver. The driver monitors the temperature of on die subsystems. It sends notifications to the user space if the temperature crosses user defined thresholds via kobject_uevent interface. The user is allowed to configure the temperature thresholds vis sysfs nodes exposed using hwmon interface. The patch depends on the the following series: http://comments.gmane.org/gmane.linux.ports.arm.omap/64436 and http://permalink.gmane.org/gmane.linux.ports.arm.omap/64446 Signed-off-by: Keerthy j-keer...@ti.com Cc: Jean Delvare kh...@linux-fr.org Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: lm-sens...@lm-sensors.org --- Documentation/hwmon/omap_temp_sensor | 25 +++ drivers/hwmon/Kconfig| 11 ++ drivers/hwmon/Makefile |1 + drivers/hwmon/omap4460plus_temp_sensor.c | 244 ++ 4 files changed, 281 insertions(+), 0 deletions(-) create mode 100644 Documentation/hwmon/omap_temp_sensor create mode 100644 drivers/hwmon/omap4460plus_temp_sensor.c Index: linux-omap-2.6/Documentation/hwmon/omap_temp_sensor === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-omap-2.6/Documentation/hwmon/omap_temp_sensor 2011-09-22 18:57:23.180918857 +0530 @@ -0,0 +1,25 @@ +Kernel driver omap_temp_sensor +== + +Supported chips: + * Texas Instruments OMAP4460 +Prefix: 'omap_temp_sensor' + +Author: +J Keerthy j-keer...@ti.com + +Description +--- + +The Texas Instruments OMAP4 family of chips have a bandgap temperature sensor. +The temperature sensor feature is used to convert the temperature of the device +into a decimal value coded on 10 bits. An internal ADC is used for conversion. +The recommended operating temperatures must be in the range -40 degree Celsius +to 123 degree celsius for standard conversion. +The thresholds are programmable and upon crossing the thresholds an interrupt +is generated. The OMAP temperature sensor has a programmable update rate in +milli seconds. +(Currently the driver programs a default of 2000 milliseconds). + +The driver provides the common sysfs-interface for temperatures (see +Documentation/hwmon/sysfs-interface under Temperatures). Index: linux-omap-2.6/drivers/hwmon/Kconfig === --- linux-omap-2.6.orig/drivers/hwmon/Kconfig 2011-09-22 17:48:38.032575702 +0530 +++ linux-omap-2.6/drivers/hwmon/Kconfig2011-09-22 19:02:28.744575604 +0530 @@ -323,6 +323,17 @@ This driver can also be built as a module. If so, the module will be called f71805f. +config SENSORS_OMAP_BANDGAP_TEMP_SENSOR + bool OMAP on-die temperature sensor hwmon driver + depends on HWMON ARCH_OMAP OMAP4460PLUS_SCM + help + If you say yes here you get support for hardware + monitoring features of the OMAP on die temperature + sensor. + + Continuous conversion programmable delay + mode is used for temperature conversion. + config SENSORS_F71882FG tristate Fintek F71882FG and compatibles help Index: linux-omap-2.6/drivers/hwmon/Makefile === --- linux-omap-2.6.orig/drivers/hwmon/Makefile 2011-09-22 17:48:38.020575728 +0530 +++ linux-omap-2.6/drivers/hwmon/Makefile 2011-09-22 18:57:23.192574712 +0530 @@ -93,6 +93,7 @@ obj-$(CONFIG_SENSORS_MAX6642) += max6642.o obj-$(CONFIG_SENSORS_MAX6650) += max6650.o obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o +obj-$(CONFIG_SENSORS_OMAP_BANDGAP_TEMP_SENSOR) += omap4460plus_temp_sensor.o obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o obj-$(CONFIG_SENSORS_PC87360) += pc87360.o obj-$(CONFIG_SENSORS_PC87427) += pc87427.o Index: linux-omap-2.6/drivers/hwmon/omap4460plus_temp_sensor.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-omap-2.6/drivers/hwmon/omap4460plus_temp_sensor.c 2011-09-22 19:02:11.096575567 +0530 @@ -0,0 +1,242 @@ +/* + * + * OMAP4460 Plus bandgap on die sensor hwmon driver. + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * J Keerthy j-keer...@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. + * + * 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., 51 Franklin St, Fifth Floor,
Re: [PATCH] hwmon: OMAP4460+: On die temperature sensor driver
On Thu, 2011-09-22 at 13:36 -0400, Keerthy wrote: On chip temperature sensor driver. The driver monitors the temperature of on die subsystems. It sends notifications to the user space if the temperature crosses user defined thresholds via kobject_uevent interface. The user is allowed to configure the temperature thresholds vis sysfs nodes exposed using hwmon interface. The patch depends on the the following series: http://comments.gmane.org/gmane.linux.ports.arm.omap/64436 and http://permalink.gmane.org/gmane.linux.ports.arm.omap/64446 Signed-off-by: Keerthy j-keer...@ti.com Cc: Jean Delvare kh...@linux-fr.org Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: lm-sens...@lm-sensors.org --- Documentation/hwmon/omap_temp_sensor | 25 +++ drivers/hwmon/Kconfig| 11 ++ drivers/hwmon/Makefile |1 + drivers/hwmon/omap4460plus_temp_sensor.c | 244 ++ 4 files changed, 281 insertions(+), 0 deletions(-) create mode 100644 Documentation/hwmon/omap_temp_sensor create mode 100644 drivers/hwmon/omap4460plus_temp_sensor.c Index: linux-omap-2.6/Documentation/hwmon/omap_temp_sensor === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-omap-2.6/Documentation/hwmon/omap_temp_sensor 2011-09-22 18:57:23.180918857 +0530 @@ -0,0 +1,25 @@ +Kernel driver omap_temp_sensor +== + +Supported chips: + * Texas Instruments OMAP4460 +Prefix: 'omap_temp_sensor' + +Author: +J Keerthy j-keer...@ti.com + +Description +--- + +The Texas Instruments OMAP4 family of chips have a bandgap temperature sensor. +The temperature sensor feature is used to convert the temperature of the device +into a decimal value coded on 10 bits. An internal ADC is used for conversion. +The recommended operating temperatures must be in the range -40 degree Celsius +to 123 degree celsius for standard conversion. +The thresholds are programmable and upon crossing the thresholds an interrupt +is generated. The OMAP temperature sensor has a programmable update rate in +milli seconds. +(Currently the driver programs a default of 2000 milliseconds). + +The driver provides the common sysfs-interface for temperatures (see +Documentation/hwmon/sysfs-interface under Temperatures). Index: linux-omap-2.6/drivers/hwmon/Kconfig === --- linux-omap-2.6.orig/drivers/hwmon/Kconfig 2011-09-22 17:48:38.032575702 +0530 +++ linux-omap-2.6/drivers/hwmon/Kconfig 2011-09-22 19:02:28.744575604 +0530 @@ -323,6 +323,17 @@ This driver can also be built as a module. If so, the module will be called f71805f. +config SENSORS_OMAP_BANDGAP_TEMP_SENSOR + bool OMAP on-die temperature sensor hwmon driver + depends on HWMON ARCH_OMAP OMAP4460PLUS_SCM + help + If you say yes here you get support for hardware + monitoring features of the OMAP on die temperature + sensor. + + Continuous conversion programmable delay + mode is used for temperature conversion. + config SENSORS_F71882FG tristate Fintek F71882FG and compatibles help Index: linux-omap-2.6/drivers/hwmon/Makefile === --- linux-omap-2.6.orig/drivers/hwmon/Makefile2011-09-22 17:48:38.020575728 +0530 +++ linux-omap-2.6/drivers/hwmon/Makefile 2011-09-22 18:57:23.192574712 +0530 @@ -93,6 +93,7 @@ obj-$(CONFIG_SENSORS_MAX6642)+= max6642.o obj-$(CONFIG_SENSORS_MAX6650)+= max6650.o obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o +obj-$(CONFIG_SENSORS_OMAP_BANDGAP_TEMP_SENSOR) += omap4460plus_temp_sensor.o obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o obj-$(CONFIG_SENSORS_PC87360)+= pc87360.o obj-$(CONFIG_SENSORS_PC87427)+= pc87427.o Index: linux-omap-2.6/drivers/hwmon/omap4460plus_temp_sensor.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-omap-2.6/drivers/hwmon/omap4460plus_temp_sensor.c 2011-09-22 19:02:11.096575567 +0530 @@ -0,0 +1,242 @@ +/* + * + * OMAP4460 Plus bandgap on die sensor hwmon driver. + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * J Keerthy j-keer...@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. + * + * 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
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
Hi
a few comments
On Thu, 22 Sep 2011, Keshava Munegowda wrote:
following 4 hwmod structures are added
1. usb_host_hs hwmod of usbhs with uhh base address and functional clock,
2. usb_ehci_hs hwmod with irq and base address,
3. usb_ohci_hs hwmod with irq and base address,
- the ehci and ohci hwmods does not require functional clock
because usb_host_hs has functional clock which is sufficient
to access ehci and ohci address space.
Every hwmod should have a functional clock defined. If they use the same
functional clock as usb_host_hs, then the same main_clk should be listed
for ehci/ohci also.
4. usb_tll_hs hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 271
1 files changed, 271 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..d79f728 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,10 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3196,6 +3200,266 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
This is missing a bunch of SYSC bits, according to Table 24-152
UHH_SYSCONFIG of the 34xx public TRM, version ZR.
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usb_host_hs,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk= l4_ick,
+ .addr = omap34xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk= usbhost_120m_fck,
This doesn't look right. This is an interface structure record, so it
should be associated with an interface clock. Is the hardware really
using the functional clock as the interface clock? Or, as seems more
likely...
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
... is this just a hack? OCPIF_SWSUP_IDLE is intended to work around
hardware autoidle bugs only. Are you sure this shouldn't be defined as an
optional clock instead?
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f48m_cfg__usb_host_hs = {
+ .clk= usbhost_48m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
Same comments as the above.
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ omap34xx_l4_cfg__usb_host_hs,
+ omap34xx_f128m_cfg__usb_host_hs,
+ omap34xx_f48m_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usb_host_hs,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .main_clk = usbhost_ick,
Is this really the main clock? The main clock is the clock that drives
the register logic in the IP block. Looks to me, based on the
Re: [PATCH 1/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi On Thu, 22 Sep 2011, Keshava Munegowda wrote: Following 4 hwmod structures are added 1. usb_host_hs hwmod of usbhs with uhh base address and functional clock, 2. usb_ehci_hs hwmod with irq and base address, 3. usb_ohci_hs hwmod with irq and base address, - The ehci and ohci hwmods does not require functional clock because usb_host_hs has functional clock which is sufficient to access ehci and ohci address space. - The usb_ehci_hs and usb_ohci_hs should be two separate hwmods which should not be combined. This is needed because ehci and ohci will have separate dedicated ports in omap4 there is a clock per port.We should be able to configure the IO-Wakeup capability of pins specific to EHCI OHCI separately and depending on the I/O wakeup event the only port clocks corresponding to the wakeup source will be enabled internally by the usb host driver. 4. usb_tll_hs hwmod of usbhs with the TLL base address and irq. Many of the same issues with the OMAP3 data (missing main_clks, missing ADDR_TYPE_RT, etc.) exist with this patch also. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] TI81XX: Prepare for addition of TI814X support
* Pedanekar, Hemant hema...@ti.com [110921 17:00]:
Tony Lindgren wrote on Thursday, September 22, 2011 2:11 AM:
* Hemant Pedanekar hema...@ti.com [110921 10:05]:
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -37,16 +37,16 @@ static void __init ti8168_evm_init(void)
static void __init ti8168_evm_map_io(void)
{
- omap2_set_globals_ti816x();
- omapti816x_map_common_io();
+ omap2_set_globals_ti81xx();
+ omapti81xx_map_common_io();
}
MACHINE_START(TI8168EVM, ti8168evm)
/* Maintainer: Texas Instruments */
.atag_offset= 0x100,
.map_io = ti8168_evm_map_io,
- .init_early = ti816x_init_early,
- .init_irq = ti816x_init_irq,
+ .init_early = ti81xx_init_early,
+ .init_irq = ti81xx_init_irq,
.timer = omap3_timer,
.init_machine = ti8168_evm_init,
MACHINE_END
Looks like you still need a minor rebase on the current cleanup
branch as the ti8668_evm_map_io is no longer needed. The cleanup
branch already has Paul's CHIP_IS removal, so that should be trivial.
Tony,
Can you please clarify? Do we not need ti8168_evm_map_io() for global data
initianlization and io init? Or, as you mentioned in comment on 3/3 of the
series, do you mean to rename this with ti81xx and move to common.c?
Yes just have a generic one in common.c should be enough. Sorry I thought
that was already done, but looks like it was only done for omap3_map_io.
Ideally the rename patch would be separate without any functional
changes, maybe you can move the changes and additions to the next patch?
Tony
If the above understanding is correct, then I will just have to rename+move
ti8168_evm_map_io() so the change can still be in this patch, right? Or are
You referring to any other part which should not be in this patch?
Yes it's OK to keep it in this patch.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] AM35x: Using OMAP3 generic hwmods
+ Chase Hi On Thu, 22 Sep 2011, Abhilash K V wrote: This patch enables AM35x SoCs to use generic OMAP3 hwmods (i,e. omap3xxx_hwmods) by allowing am35xx_init_early() to disable the modules which are not present in AM3517. Reviewed-by: Sanjeev Premi pr...@ti.com Signed-off-by: Abhilash K V abhilash...@ti.com We now use a different approach for registering hwmods that are device-specific. Could you please take a look at the approach that's in Tony's master branch and use it instead to handle AM3517 hwmod registration? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi Paul, On 9/22/2011 8:14 PM, Paul Walmsley wrote: Hi On Thu, 22 Sep 2011, Keshava Munegowda wrote: Following 4 hwmod structures are added 1. usb_host_hs hwmod of usbhs with uhh base address and functional clock, 2. usb_ehci_hs hwmod with irq and base address, 3. usb_ohci_hs hwmod with irq and base address, - The ehci and ohci hwmods does not require functional clock because usb_host_hs has functional clock which is sufficient to access ehci and ohci address space. - The usb_ehci_hs and usb_ohci_hs should be two separate hwmods which should not be combined. This is needed because ehci and ohci will have separate dedicated ports in omap4 there is a clock per port.We should be able to configure the IO-Wakeup capability of pins specific to EHCI OHCI separately and depending on the I/O wakeup event the only port clocks corresponding to the wakeup source will be enabled internally by the usb host driver. 4. usb_tll_hs hwmod of usbhs with the TLL base address and irq. Many of the same issues with the OMAP3 data (missing main_clks, missing ADDR_TYPE_RT, etc.) exist with this patch also. ADDR_TYPE_RT is mainly use for sysconfig access inside hwmod core today, so why should we use it in this case? To be honest, I've been confused with that flag for some time :-) * ADDR_TYPE_RT: Address space contains module register target data. Maybe that's my English, but what does register target data mean exactly? What was the intent? Providing a way to identify some register vs memory space? Regarding main_clk, I do not think that some internal IPs like ohci/ehci should have a main_clk, since this is not visible at that level. These blocks do not have any PRCM / OCP connection. In fact they should not even be hwmod in theory, these are just some internal IPs inside the usb_host controller. These are hwmods just because of the dynamic mux support needed by these IPs. That was one of the comments I made on these, and Keshava explained me the rational and added it in the changelog. Hopefully, we will not have that limitation once we will have migrated that to DT :-) Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe 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 V6 0/4] cpuidle: Global registration of idle states with per-cpu statistics
Hi, On Thu, Sep 22, 2011 at 10:28 AM, Deepthi Dharwar deep...@linux.vnet.ibm.com wrote: The following patch series implements global registration of cpuidle states, and also has the necessary data structure changes to accommodate the per-cpu writable members of the cpuidle_states structure. This patch series had been in discussion earlier and following are the links to the previous discussions. v1 -- https://lkml.org/lkml/2011/3/22/161 v2 -- https://lkml.org/lkml/2011/1/13/98 v3 -- https://lkml.org/lkml/2011/2/8/73 v4 -- https://lkml.org/lkml/2011/4/28/312 v5 -- https://lkml.org/lkml/2011/6/6/259 Changes from previous version (V5): Rebased the series to 3.1-rc7 Tests done: 1. Compile tested for ARM using the following configs: da8xx_omapl_defconfig, exynos4_defconfig, kirkwood_defconfig, omap2plus_defconfig, at91rm9200_defconfig Tested OK on OMAP3: Signed-off-by: Jean Pihet j-pi...@ti.com 2. Boot tested on x86 nehalem with multiple C-states for both intel_idle and acpi_idle drivers. 3. Boot tested on T60p thinkpad that has T2600 cpu with multiple C-states. Also tested the case when there is dynamic changes in C-states AC - Battery Power switch. Brief description of the patches: Core change in this series is to split the cpuidle_device structure into two parts, i.e global and per-cpu basis. The per-cpu pieces are mostly generic statistics that can be independent of current running driver. As a result of these changes, there is single copy of cpuidle_states structure and single registration done by one cpu. The low level driver is free to set per-cpu driver data on each cpu if needed using the cpuidle_set_statedata() as the case today. Only in very rare cases asymmetric C-states exist which can be handled within the cpuidle driver. Most architectures do not have asymmetric C-states. First two patches in the series facilitate splitting of cpuidle_states and cpuidle_device structure and next two patches do the actual split, change the API's and make existing code follow the changed API. [1/4] - Move the idle residency accounting part from cpuidle.c to the respective low level drivers, so that the accounting can be accurately maintained if the driver decides to demote the chosen (suggested) by the governor. This is a nice improvement since OMAP heavily uses the state demotion in the cpuidle driver, and will use it even more with the per-device PM QoS support added. Thanks regards, Jean [2/4] - removes the cpuidle_device()-prepare API since is is not widely used and the only use case was to allow software demotion using CPUIDLE_FLAG_IGNORE flag. Both these functions can be absorbed within the cpuidle back-end driver ad hence deprecating the prepare routine and the CPUIDLE_FLAG_IGNORE flag. - Ref: https://lkml.org/lkml/2011/3/25/52 [3/4] - Splits the usage statistics (read/write) part out of cpuidle_state structure, so that the states can become read only and hence made global. [4/4] - Most APIs will now need to pass pointer to both global cpuidle_driver and per-cpu cpuidle_device structure. arch/arm/mach-at91/cpuidle.c | 41 +++-- arch/arm/mach-davinci/cpuidle.c | 51 --- arch/arm/mach-exynos4/cpuidle.c | 30 ++-- arch/arm/mach-kirkwood/cpuidle.c | 42 +++--- arch/arm/mach-omap2/cpuidle34xx.c | 133 +++-- arch/sh/kernel/cpu/shmobile/cpuidle.c | 28 ++-- drivers/acpi/processor_driver.c | 20 --- drivers/acpi/processor_idle.c | 251 +++-- drivers/cpuidle/cpuidle.c | 86 --- drivers/cpuidle/driver.c | 25 +++ drivers/cpuidle/governors/ladder.c | 41 - drivers/cpuidle/governors/menu.c | 29 ++-- drivers/cpuidle/sysfs.c | 22 ++- drivers/idle/intel_idle.c | 130 + include/acpi/processor.h | 1 include/linux/cpuidle.h | 52 --- 16 files changed, 650 insertions(+), 332 deletions(-) -- Thanks -Deepthi ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH V6 0/4] cpuidle: Global registration of idle states with per-cpu statistics
Deepthi Dharwar deep...@linux.vnet.ibm.com writes: The following patch series implements global registration of cpuidle states, and also has the necessary data structure changes to accommodate the per-cpu writable members of the cpuidle_states structure. I reviewed earlier versions of the series, and this version still looks good to me. Any reason it is still RFC? Reviewed-by: Kevin Hilman khil...@ti.com and for the OMAP-specific parts, Acked-by: Kevin Hilman khil...@ti.com 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 v7 00/26] gpio/omap: driver cleanup and fixes
Hi Tarun, DebBarma, Tarun Kanti tarun.ka...@ti.com writes: On Tue, Sep 13, 2011 at 6:32 PM, Tarun Kanti DebBarma tarun.ka...@ti.com wrote: This series is continuation of cleanup of OMAP GPIO driver and fixes. The cleanup include getting rid of cpu_is_* checks wherever possible, use of gpio_bank list instead of static array, use of unique platform specific value associated data member to OMAP platforms to avoid cpu_is_* checks. The series also include PM runtime support.* Baseline: git://gitorious.org/khilman/linux-omap-pm.git Branch: for_3.2/gpio-cleanup Commit: 8323374 Thanks Tony for ack'ing the patches. Kevin, Since Tony's has acked the patches, can you please pull them? Before merging, I still need to review and test this version, and I *might* still get to it this week. Based on the dbclk aliases you added, I assume this has now been tested on platforms using some GPIOs with debounce enabled? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2] OMAP: omap_device: Add a method to build an omap_device from a DT node
Hi Kevin, This is the updated version of the initial series that introduced a notifier in order to create an omap_device from a platform_device bound to DT node as suggested by Grant. For the moment, the informations are all extracted from the hwmod data. The idea is to focus first on the devices / board static init removal. The other issue is that some bindings, like dma, are still not present in the DT core code. The reg and irq bindings are there, but cannot be used by some drivers due to the lack of named resources in DT for the moment. We agreed with Grant about the strategy to introduce the name without breaking the compatibility and the default assumption about the order. I'll update that in another series after 3.2 and then these informations will be moved from hwmod to DT. Patches are based on my for_3.2/1_omap_device_cleanup branch and are available here: git://gitorious.org/omap-pm/linux.git for_3.2/2_omap_device_dt It is tested on OMAP4 SDP, Panda and Beagle-xM with and without CONFIG_OF. Regards, Benoit Changes since v1: http://www.spinics.net/lists/linux-omap/msg55814.html - delete omap_device structure during BUS_NOTIFY_DEL_DEVICE callback as suggested by Kevin - merge previous patches 23 as suggested by Kevin - delete pm_lats in omap_device_delete since this is now kmalloc-ed - use kmemdup instead of kzalloc + memcopy for hmwods creation - Fix the wrong usage of of_*.h includes to build properly without CONFIG_OF. Changes since v2: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg55892.html - Add binding documentation for the OMAP attributes - Add ti, prefix to hwmods and no_idle_on_suspend attributes - Change the static init of the notifier_block structure as suggested by Grant - Add a comment to remove the helpers once the generic one from swarren will be merged Benoit Cousson (2): OMAP: omap_device: Add omap_device_[alloc|delete] for DT integration OMAP: omap_device: Add a method to build an omap_device from a DT node .../devicetree/bindings/arm/omap/omap.txt | 42 +++ arch/arm/plat-omap/omap_device.c | 322 2 files changed, 306 insertions(+), 58 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/omap.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] OMAP: omap_device: Add omap_device_[alloc|delete] for DT integration
Split the omap_device_build_ss into two smaller functions
that will allow to populate a platform_device already allocated by
device-tree.
The functionality of the omap_device_build_ss is still the same, but
the omap_device_alloc will be usable with devices already built by
device-tree.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/omap_device.c | 177 +
1 files changed, 119 insertions(+), 58 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 54bbe7b..cac7b9a 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -96,6 +96,11 @@
static int omap_device_register(struct platform_device *pdev);
static int omap_early_device_register(struct platform_device *pdev);
+static struct omap_device *omap_device_alloc(struct platform_device *pdev,
+ struct omap_hwmod **ohs, int oh_cnt,
+ struct omap_device_pm_latency *pm_lats,
+ int pm_lats_cnt);
+
static struct omap_device_pm_latency omap_default_latency[] = {
{
@@ -397,6 +402,110 @@ static int omap_device_fill_resources(struct omap_device
*od,
}
/**
+ * omap_device_alloc - allocate an omap_device
+ * @pdev: platform_device that will be included in this omap_device
+ * @oh: ptr to the single omap_hwmod that backs this omap_device
+ * @pdata: platform_data ptr to associate with the platform_device
+ * @pdata_len: amount of memory pointed to by @pdata
+ * @pm_lats: pointer to a omap_device_pm_latency array for this device
+ * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
+ *
+ * Convenience function for allocating an omap_device structure and filling
+ * hwmods, resources and pm_latency attributes.
+ *
+ * Returns an struct omap_device pointer or ERR_PTR() on error;
+ */
+static struct omap_device *omap_device_alloc(struct platform_device *pdev,
+ struct omap_hwmod **ohs, int oh_cnt,
+ struct omap_device_pm_latency *pm_lats,
+ int pm_lats_cnt)
+{
+ int ret = -ENOMEM;
+ struct omap_device *od;
+ struct resource *res = NULL;
+ int i, res_count;
+ struct omap_hwmod **hwmods;
+
+ od = kzalloc(sizeof(struct omap_device), GFP_KERNEL);
+ if (!od) {
+ ret = -ENOMEM;
+ goto oda_exit1;
+ }
+ od-hwmods_cnt = oh_cnt;
+
+ hwmods = kmemdup(ohs, sizeof(struct omap_hwmod *) * oh_cnt, GFP_KERNEL);
+ if (!hwmods)
+ goto oda_exit2;
+
+ od-hwmods = hwmods;
+ od-pdev = pdev;
+
+ /*
+* HACK: Ideally the resources from DT should match, and hwmod
+* should just add the missing ones. Since the name is not
+* properly populated by DT, stick to hwmod resources only.
+*/
+ if (pdev-num_resources pdev-resource)
+ dev_warn(pdev-dev, %s(): resources already allocated %d\n,
+ __func__, pdev-num_resources);
+
+ res_count = omap_device_count_resources(od);
+ if (res_count 0) {
+ dev_dbg(pdev-dev, %s(): resources allocated from hwmod %d\n,
+ __func__, res_count);
+ res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
+ if (!res)
+ goto oda_exit3;
+
+ omap_device_fill_resources(od, res);
+
+ ret = platform_device_add_resources(pdev, res, res_count);
+ kfree(res);
+
+ if (ret)
+ goto oda_exit3;
+ }
+
+ if (!pm_lats) {
+ pm_lats = omap_default_latency;
+ pm_lats_cnt = ARRAY_SIZE(omap_default_latency);
+ }
+
+ od-pm_lats_cnt = pm_lats_cnt;
+ od-pm_lats = kmemdup(pm_lats,
+ sizeof(struct omap_device_pm_latency) * pm_lats_cnt,
+ GFP_KERNEL);
+ if (!od-pm_lats)
+ goto oda_exit3;
+
+ pdev-archdata.od = od;
+
+ for (i = 0; i oh_cnt; i++) {
+ hwmods[i]-od = od;
+ _add_hwmod_clocks_clkdev(od, hwmods[i]);
+ }
+
+ return od;
+
+oda_exit3:
+ kfree(hwmods);
+oda_exit2:
+ kfree(od);
+oda_exit1:
+ dev_err(pdev-dev, omap_device: build failed (%d)\n, ret);
+
+ return ERR_PTR(ret);
+}
+
+static void omap_device_delete(struct omap_device *od)
+{
+ od-pdev-archdata.od = NULL;
+ kfree(od-pm_lats);
+ kfree(od-hwmods);
+ kfree(od);
+}
+
+/**
* omap_device_build - build and register an omap_device with one omap_hwmod
* @pdev_name: name of the platform_device driver to use
* @pdev_id: this platform_device's connection ID
@@ -455,9 +564,6 @@ struct platform_device *omap_device_build_ss(const char
*pdev_name, int pdev_id,
[PATCH v3 2/2] OMAP: omap_device: Add a method to build an omap_device from a DT node
Add a notifier called during device_add phase. If an of_node is present,
retrieve the hwmod entry in order to populate properly the omap_device
structure.
For the moment the resource from the device-tree are overloaded.
DT does not support named resource yet, and thus, most driver
will not work without that information.
Add two helpers function to parse a property that contains multiple
strings. Please note that these helpers will be replaced by a more generic
iterator currently proposed on devicetree mailing list as soon as it
will be merged.
Add a documentation to capture the specifics OMAP bindings
needed for device-tree support.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
.../devicetree/bindings/arm/omap/omap.txt | 42 ++
arch/arm/plat-omap/omap_device.c | 145
2 files changed, 187 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/omap.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
new file mode 100644
index 000..6513d05
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -0,0 +1,42 @@
+* Texas Instruments OMAP
+
+OMAP is currently using a static file per SoC family to describe the
+IPs present in the SoC.
+On top of that an omap_device is created to extend the platform_device
+capabilities and to allow binding with one or several hwmods.
+The hwmods will contain all the information to build the device:
+adresse range, irq lines, dma lines, interconnect, PRCM register,
+clock domain, input clocks.
+For the moment just point to the existing hwmod, the next step will be
+to move data from hwmod to device-tree representation.
+
+
+Required properties:
+- compatible: Every devices present in OMAP SoC should be in the
+ form: ti,XXX
+- ti,hwmods: list of hwmods attached to a device. Must contain at least
+ one hwmod.
+
+Optional properties:
+- ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
+ during suspend.
+
+
+Example:
+
+spinlock@1 {
+compatible = ti,omap-spinlock;
+ti,hwmods = spinlock;
+};
+
+
+Boards:
+
+- OMAP3 BeagleBoard : Low cost community board
+ compatible = ti,omap3-beagle, ti,omap3
+
+- OMAP4 SDP : Software Developement Board
+ compatible = ti,omap4-sdp, ti,omap4430
+
+- OMAP4 PandaBoard : Low cost community board
+ compatible = ti,omap4-panda, ti,omap4430
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index cac7b9a..5b63989 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -85,6 +85,8 @@
#include linux/clk.h
#include linux/clkdev.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/notifier.h
#include plat/omap_device.h
#include plat/omap_hwmod.h
@@ -94,12 +96,15 @@
#define USE_WAKEUP_LAT 0
#define IGNORE_WAKEUP_LAT 1
+#define MAX_HWMOD_NAME_SIZE32
+
static int omap_device_register(struct platform_device *pdev);
static int omap_early_device_register(struct platform_device *pdev);
static struct omap_device *omap_device_alloc(struct platform_device *pdev,
struct omap_hwmod **ohs, int oh_cnt,
struct omap_device_pm_latency *pm_lats,
int pm_lats_cnt);
+static void omap_device_delete(struct omap_device *od);
static struct omap_device_pm_latency omap_default_latency[] = {
@@ -315,6 +320,138 @@ static void _add_hwmod_clocks_clkdev(struct omap_device
*od,
_add_clkdev(od, oh-opt_clks[i].role, oh-opt_clks[i].clk);
}
+/*
+ * XXX: DT helper functions that should be replaced by more generic
+ * API introduced by Stephen Warren once they'll be in mainline.
+ */
+static int _dt_count_property_string(const char *prop, int len)
+{
+ int i = 0;
+ size_t l = 0, total = 0;
+
+ if (!prop || !len)
+ return -EINVAL;
+
+ for (i = 0; len = total; total += l, prop += l) {
+ l = strlen(prop) + 1;
+ if (*prop != 0)
+ i++;
+ }
+ return i;
+}
+
+static int _dt_get_property(const char *prop, int len, int index, char *output,
+ int size)
+{
+ int i = 0;
+ size_t l = 0, total = 0;
+
+ if (!prop || !len)
+ return -EINVAL;
+
+ for (i = 0; len = total; total += l, prop += l) {
+ l = strlcpy(output, prop, size) + 1;
+ if (*prop != 0) {
+ if (i++ == index)
+ return 0;
+ }
+ }
+ return -ENODEV;
+}
+
+static struct dev_pm_domain omap_device_pm_domain;
+
+/**
+ * omap_device_build_from_dt - build an omap_device with multiple hwmods
+ * @pdev_name: name of the platform_device driver to use
+ * @pdev_id: this
[PATCH 00/10] cpufreq: OMAP: move into drivers, cleanups/fixes for v3.2
This series moves the OMAP CPUfreq driver into drivers/cpufreq, add support for SMP devices (OMAP4+) and includes several cleanups and fixes from Nishanth Menon. This series applies to v3.1-rc6, and is available here: git://github.com/khilman/linux-omap-pm.git for_3.2/omap-cpufreq Kevin Colin Cross (1): cpufreq: OMAP: notify even with bad boot frequency Nishanth Menon (6): cpufreq: OMAP: move clk name decision to init cpufreq: OMAP: deny initialization if no mpudev cpufreq: OMAP: dont support !freq_table cpufreq: OMAP: only supports OPP library cpufreq: OMAP: put clk if cpu_init failed cpufreq: OMAP: fix freq_table leak Russell King (1): cpufreq: OMAP: Add SMP support for OMAP4+ Santosh Shilimkar (1): cpufreq: OMAP: cleanup for multi-SoC support, move into drivers/cpufreq Todd Poynor (1): cpufreq: OMAP: Enable all CPUs in shared policy mask arch/arm/plat-omap/Makefile|1 - arch/arm/plat-omap/cpu-omap.c | 171 - drivers/cpufreq/Makefile |1 + drivers/cpufreq/omap-cpufreq.c | 271 4 files changed, 272 insertions(+), 172 deletions(-) delete mode 100644 arch/arm/plat-omap/cpu-omap.c create mode 100644 drivers/cpufreq/omap-cpufreq.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
[PATCH 01/10] cpufreq: OMAP: cleanup for multi-SoC support, move into drivers/cpufreq
From: Santosh Shilimkar santosh.shilim...@ti.com
Move OMAP cpufreq driver from arch/arm/mach-omap2 into
drivers/cpufreq, along with a few cleanups:
- generalize support for better handling of different SoCs in the OMAP
- use OPP layer instead of OMAP clock internals for frequency table init
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[khil...@ti.com: move to drivers]
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/Makefile|1 -
arch/arm/plat-omap/cpu-omap.c | 171
drivers/cpufreq/Makefile |1 +
drivers/cpufreq/omap-cpufreq.c | 188
4 files changed, 189 insertions(+), 172 deletions(-)
delete mode 100644 arch/arm/plat-omap/cpu-omap.c
create mode 100644 drivers/cpufreq/omap-cpufreq.c
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index f0233e6..4ef7493 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -21,7 +21,6 @@ obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o
obj-$(CONFIG_OMAP_IOMMU_DEBUG) += iommu-debug.o
-obj-$(CONFIG_CPU_FREQ) += cpu-omap.o
obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
obj-$(CONFIG_OMAP_DEBUG_DEVICES) += debug-devices.o
obj-$(CONFIG_OMAP_DEBUG_LEDS) += debug-leds.o
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
deleted file mode 100644
index da4f68d..000
--- a/arch/arm/plat-omap/cpu-omap.c
+++ /dev/null
@@ -1,171 +0,0 @@
-/*
- * linux/arch/arm/plat-omap/cpu-omap.c
- *
- * CPU frequency scaling for OMAP
- *
- * Copyright (C) 2005 Nokia Corporation
- * Written by Tony Lindgren t...@atomide.com
- *
- * Based on cpu-sa1110.c, Copyright (C) 2001 Russell King
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include linux/types.h
-#include linux/kernel.h
-#include linux/sched.h
-#include linux/cpufreq.h
-#include linux/delay.h
-#include linux/init.h
-#include linux/err.h
-#include linux/clk.h
-#include linux/io.h
-
-#include mach/hardware.h
-#include plat/clock.h
-#include asm/system.h
-
-#define VERY_HI_RATE 9
-
-static struct cpufreq_frequency_table *freq_table;
-
-#ifdef CONFIG_ARCH_OMAP1
-#define MPU_CLKmpu
-#else
-#define MPU_CLKvirt_prcm_set
-#endif
-
-static struct clk *mpu_clk;
-
-/* TODO: Add support for SDRAM timing changes */
-
-static int omap_verify_speed(struct cpufreq_policy *policy)
-{
- if (freq_table)
- return cpufreq_frequency_table_verify(policy, freq_table);
-
- if (policy-cpu)
- return -EINVAL;
-
- cpufreq_verify_within_limits(policy, policy-cpuinfo.min_freq,
-policy-cpuinfo.max_freq);
-
- policy-min = clk_round_rate(mpu_clk, policy-min * 1000) / 1000;
- policy-max = clk_round_rate(mpu_clk, policy-max * 1000) / 1000;
- cpufreq_verify_within_limits(policy, policy-cpuinfo.min_freq,
-policy-cpuinfo.max_freq);
- return 0;
-}
-
-static unsigned int omap_getspeed(unsigned int cpu)
-{
- unsigned long rate;
-
- if (cpu)
- return 0;
-
- rate = clk_get_rate(mpu_clk) / 1000;
- return rate;
-}
-
-static int omap_target(struct cpufreq_policy *policy,
- unsigned int target_freq,
- unsigned int relation)
-{
- struct cpufreq_freqs freqs;
- int ret = 0;
-
- /* Ensure desired rate is within allowed range. Some govenors
-* (ondemand) will just pass target_freq=0 to get the minimum. */
- if (target_freq policy-min)
- target_freq = policy-min;
- if (target_freq policy-max)
- target_freq = policy-max;
-
- freqs.old = omap_getspeed(0);
- freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000;
- freqs.cpu = 0;
-
- if (freqs.old == freqs.new)
- return ret;
-
- cpufreq_notify_transition(freqs, CPUFREQ_PRECHANGE);
-#ifdef CONFIG_CPU_FREQ_DEBUG
- printk(KERN_DEBUG cpufreq-omap: transition: %u -- %u\n,
- freqs.old, freqs.new);
-#endif
- ret = clk_set_rate(mpu_clk, freqs.new * 1000);
- cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
-
- return ret;
-}
-
-static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
-{
- int result = 0;
-
- mpu_clk = clk_get(NULL, MPU_CLK);
- if (IS_ERR(mpu_clk))
- return PTR_ERR(mpu_clk);
-
- if (policy-cpu != 0)
- return -EINVAL;
-
- policy-cur = policy-min = policy-max = omap_getspeed(0);
-
- clk_init_cpufreq_table(freq_table);
- if (freq_table) {
- result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
- if (!result)
-
[PATCH 03/10] cpufreq: OMAP: Enable all CPUs in shared policy mask
From: Todd Poynor toddpoy...@google.com
Enable all CPUs in the shared policy in the CPU init callback.
Otherwise, the governor CPUFREQ_GOV_START event is invoked with
a policy that only includes the first CPU, leaving other CPUs
uninitialized by the governor.
Signed-off-by: Todd Poynor toddpoy...@google.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/cpufreq/omap-cpufreq.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index f9b4c4d..5e2f05a 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -151,7 +151,6 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
{
int result = 0;
struct device *mpu_dev;
- static cpumask_var_t cpumask;
if (cpu_is_omap24xx())
mpu_clk = clk_get(NULL, virt_prcm_set);
@@ -199,8 +198,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
*/
if (is_smp()) {
policy-shared_type = CPUFREQ_SHARED_TYPE_ANY;
- cpumask_or(cpumask, cpumask_of(policy-cpu), cpumask);
- cpumask_copy(policy-cpus, cpumask);
+ cpumask_setall(policy-cpus);
}
/* FIXME: what's the actual transition time? */
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] cpufreq: OMAP: Add SMP support for OMAP4+
From: Russell King rmk+ker...@arm.linux.org.uk
On OMAP SMP configuartion, both processors share the voltage
and clock. So both CPUs needs to be scaled together and hence
needs software co-ordination.
Also, update lpj with reference value to avoid progressive error.
Adjust _both_ the per-cpu loops_per_jiffy and global lpj. Calibrate
them with with reference to the initial values to avoid a
progressively bigger and bigger error in the value over time.
While at this, re-use the notifiers for UP/SMP since on UP machine or
UP_ON_SMP policy-cpus mask would contain only the boot CPU.
Based on initial SMP support by Santosh Shilimkar.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[khil...@ti.com: due to overlap/rework, combined original Santosh patch
and Russell's rework]
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/cpufreq/omap-cpufreq.c | 80 +++-
1 files changed, 70 insertions(+), 10 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index a6b2be7..f9b4c4d 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -23,6 +23,7 @@
#include linux/clk.h
#include linux/io.h
#include linux/opp.h
+#include linux/cpu.h
#include asm/system.h
#include asm/smp_plat.h
@@ -35,6 +36,16 @@
#define VERY_HI_RATE 9
+#ifdef CONFIG_SMP
+struct lpj_info {
+ unsigned long ref;
+ unsigned intfreq;
+};
+
+static DEFINE_PER_CPU(struct lpj_info, lpj_ref);
+static struct lpj_info global_lpj_ref;
+#endif
+
static struct cpufreq_frequency_table *freq_table;
static struct clk *mpu_clk;
@@ -60,7 +71,7 @@ static unsigned int omap_getspeed(unsigned int cpu)
{
unsigned long rate;
- if (cpu)
+ if (cpu = NR_CPUS)
return 0;
rate = clk_get_rate(mpu_clk) / 1000;
@@ -71,7 +82,7 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation)
{
- int ret = 0;
+ int i, ret = 0;
struct cpufreq_freqs freqs;
/* Ensure desired rate is within allowed range. Some govenors
@@ -81,22 +92,57 @@ static int omap_target(struct cpufreq_policy *policy,
if (target_freq policy-max)
target_freq = policy-max;
- freqs.old = omap_getspeed(0);
+ freqs.old = omap_getspeed(policy-cpu);
freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000;
- freqs.cpu = 0;
+ freqs.cpu = policy-cpu;
if (freqs.old == freqs.new)
return ret;
- cpufreq_notify_transition(freqs, CPUFREQ_PRECHANGE);
+ /* notifiers */
+ for_each_cpu(i, policy-cpus) {
+ freqs.cpu = i;
+ cpufreq_notify_transition(freqs, CPUFREQ_PRECHANGE);
+ }
#ifdef CONFIG_CPU_FREQ_DEBUG
pr_info(cpufreq-omap: transition: %u -- %u\n, freqs.old, freqs.new);
#endif
ret = clk_set_rate(mpu_clk, freqs.new * 1000);
+ freqs.new = omap_getspeed(policy-cpu);
+
+#ifdef CONFIG_SMP
+ /*
+* Note that loops_per_jiffy is not updated on SMP systems in
+* cpufreq driver. So, update the per-CPU loops_per_jiffy value
+* on frequency transition. We need to update all dependent CPUs.
+*/
+ for_each_cpu(i, policy-cpus) {
+ struct lpj_info *lpj = per_cpu(lpj_ref, i);
+ if (!lpj-freq) {
+ lpj-ref = per_cpu(cpu_data, i).loops_per_jiffy;
+ lpj-freq = freqs.old;
+ }
+
+ per_cpu(cpu_data, i).loops_per_jiffy =
+ cpufreq_scale(lpj-ref, lpj-freq, freqs.new);
+ }
- cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
+ /* And don't forget to adjust the global one */
+ if (!global_lpj_ref.freq) {
+ global_lpj_ref.ref = loops_per_jiffy;
+ global_lpj_ref.freq = freqs.old;
+ }
+ loops_per_jiffy = cpufreq_scale(global_lpj_ref.ref, global_lpj_ref.freq,
+ freqs.new);
+#endif
+
+ /* notifiers */
+ for_each_cpu(i, policy-cpus) {
+ freqs.cpu = i;
+ cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
+ }
return ret;
}
@@ -105,6 +151,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
{
int result = 0;
struct device *mpu_dev;
+ static cpumask_var_t cpumask;
if (cpu_is_omap24xx())
mpu_clk = clk_get(NULL, virt_prcm_set);
@@ -116,12 +163,12 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
if (IS_ERR(mpu_clk))
return PTR_ERR(mpu_clk);
- if (policy-cpu != 0)
+ if (policy-cpu = NR_CPUS)
return -EINVAL;
- policy-cur = policy-min =
[PATCH 05/10] cpufreq: OMAP: move clk name decision to init
From: Nishanth Menon n...@ti.com
Clk name does'nt need to dynamically detected during clk init.
move them off to driver initialization, if we dont have a clk name,
there is no point in registering the driver anyways. The actual clk
get and put is left at cpu_init and exit functions.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/cpufreq/omap-cpufreq.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 724d36c..07e835d 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -48,6 +48,7 @@ static struct lpj_info global_lpj_ref;
static struct cpufreq_frequency_table *freq_table;
static struct clk *mpu_clk;
+static char *mpu_clk_name;
static int omap_verify_speed(struct cpufreq_policy *policy)
{
@@ -152,13 +153,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
int result = 0;
struct device *mpu_dev;
- if (cpu_is_omap24xx())
- mpu_clk = clk_get(NULL, virt_prcm_set);
- else if (cpu_is_omap34xx())
- mpu_clk = clk_get(NULL, dpll1_ck);
- else if (cpu_is_omap44xx())
- mpu_clk = clk_get(NULL, dpll_mpu_ck);
-
+ mpu_clk = clk_get(NULL, mpu_clk_name);
if (IS_ERR(mpu_clk))
return PTR_ERR(mpu_clk);
@@ -232,6 +227,17 @@ static struct cpufreq_driver omap_driver = {
static int __init omap_cpufreq_init(void)
{
+ if (cpu_is_omap24xx())
+ mpu_clk_name = virt_prcm_set;
+ else if (cpu_is_omap34xx())
+ mpu_clk_name = dpll1_ck;
+ else if (cpu_is_omap44xx())
+ mpu_clk_name = dpll_mpu_ck;
+
+ if (!mpu_clk_name) {
+ pr_err(%s: unsupported Silicon?\n, __func__);
+ return -EINVAL;
+ }
return cpufreq_register_driver(omap_driver);
}
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/10] cpufreq: OMAP: deny initialization if no mpudev
From: Nishanth Menon n...@ti.com
if we do not have mpu_dev we normally fail in cpu_init. It is better
to fail driver registration if the devices are not available.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/cpufreq/omap-cpufreq.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 07e835d..fe943b3 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -49,6 +49,7 @@ static struct lpj_info global_lpj_ref;
static struct cpufreq_frequency_table *freq_table;
static struct clk *mpu_clk;
static char *mpu_clk_name;
+static struct device *mpu_dev;
static int omap_verify_speed(struct cpufreq_policy *policy)
{
@@ -151,7 +152,6 @@ static int omap_target(struct cpufreq_policy *policy,
static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
{
int result = 0;
- struct device *mpu_dev;
mpu_clk = clk_get(NULL, mpu_clk_name);
if (IS_ERR(mpu_clk))
@@ -161,12 +161,6 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
return -EINVAL;
policy-cur = policy-min = policy-max = omap_getspeed(policy-cpu);
- mpu_dev = omap2_get_mpuss_device();
-
- if (!mpu_dev) {
- pr_warning(%s: unable to get the mpu device\n, __func__);
- return -EINVAL;
- }
opp_init_cpufreq_table(mpu_dev, freq_table);
if (freq_table) {
@@ -238,6 +232,13 @@ static int __init omap_cpufreq_init(void)
pr_err(%s: unsupported Silicon?\n, __func__);
return -EINVAL;
}
+
+ mpu_dev = omap2_get_mpuss_device();
+ if (!mpu_dev) {
+ pr_warning(%s: unable to get the mpu device\n, __func__);
+ return -EINVAL;
+ }
+
return cpufreq_register_driver(omap_driver);
}
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/10] cpufreq: OMAP: dont support !freq_table
From: Nishanth Menon n...@ti.com
OMAP2+ all have frequency tables, hence the hacks we had for older
silicon do not need to be carried forward. As part of this change,
use cpufreq_frequency_table_target to find the best match for
frequency requested.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/cpufreq/omap-cpufreq.c | 67 +++
1 files changed, 33 insertions(+), 34 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index fe943b3..635778d 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -34,8 +34,6 @@
#include mach/hardware.h
-#define VERY_HI_RATE 9
-
#ifdef CONFIG_SMP
struct lpj_info {
unsigned long ref;
@@ -53,20 +51,9 @@ static struct device *mpu_dev;
static int omap_verify_speed(struct cpufreq_policy *policy)
{
- if (freq_table)
- return cpufreq_frequency_table_verify(policy, freq_table);
-
- if (policy-cpu)
+ if (!freq_table)
return -EINVAL;
-
- cpufreq_verify_within_limits(policy, policy-cpuinfo.min_freq,
-policy-cpuinfo.max_freq);
-
- policy-min = clk_round_rate(mpu_clk, policy-min * 1000) / 1000;
- policy-max = clk_round_rate(mpu_clk, policy-max * 1000) / 1000;
- cpufreq_verify_within_limits(policy, policy-cpuinfo.min_freq,
-policy-cpuinfo.max_freq);
- return 0;
+ return cpufreq_frequency_table_verify(policy, freq_table);
}
static unsigned int omap_getspeed(unsigned int cpu)
@@ -84,18 +71,31 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation)
{
- int i, ret = 0;
+ unsigned int i;
+ int ret = 0;
struct cpufreq_freqs freqs;
- /* Ensure desired rate is within allowed range. Some govenors
-* (ondemand) will just pass target_freq=0 to get the minimum. */
- if (target_freq policy-min)
- target_freq = policy-min;
- if (target_freq policy-max)
- target_freq = policy-max;
+ if (!freq_table) {
+ dev_err(mpu_dev, %s: cpu%d: no freq table!\n, __func__,
+ policy-cpu);
+ return -EINVAL;
+ }
+
+ ret = cpufreq_frequency_table_target(policy, freq_table, target_freq,
+ relation, i);
+ if (ret) {
+ dev_dbg(mpu_dev, %s: cpu%d: no freq match for %d(ret=%d)\n,
+ __func__, policy-cpu, target_freq, ret);
+ return ret;
+ }
+ freqs.new = freq_table[i].frequency;
+ if (!freqs.new) {
+ dev_err(mpu_dev, %s: cpu%d: no match for freq %d\n, __func__,
+ policy-cpu, target_freq);
+ return -EINVAL;
+ }
freqs.old = omap_getspeed(policy-cpu);
- freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000;
freqs.cpu = policy-cpu;
if (freqs.old == freqs.new policy-cur == freqs.new)
@@ -161,19 +161,18 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
return -EINVAL;
policy-cur = policy-min = policy-max = omap_getspeed(policy-cpu);
- opp_init_cpufreq_table(mpu_dev, freq_table);
-
- if (freq_table) {
- result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
- if (!result)
- cpufreq_frequency_table_get_attr(freq_table,
- policy-cpu);
- } else {
- policy-cpuinfo.min_freq = clk_round_rate(mpu_clk, 0) / 1000;
- policy-cpuinfo.max_freq = clk_round_rate(mpu_clk,
- VERY_HI_RATE) / 1000;
+ result = opp_init_cpufreq_table(mpu_dev, freq_table);
+
+ if (result) {
+ dev_err(mpu_dev, %s: cpu%d: failed creating freq table[%d]\n,
+ __func__, policy-cpu, result);
+ return result;
}
+ result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
+ if (!result)
+ cpufreq_frequency_table_get_attr(freq_table, policy-cpu);
+
policy-min = policy-cpuinfo.min_freq;
policy-max = policy-cpuinfo.max_freq;
policy-cur = omap_getspeed(policy-cpu);
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10] cpufreq: OMAP: only supports OPP library
From: Nishanth Menon n...@ti.com
OMAP2 is the only family using clk_[init|exit]_cpufreq_table, however,
the cpufreq code does not currently use clk_init_cpufreq_table. As a
result, it is unusuable for OMAP2 and only usable only on platforms
using OPP library.
Remove the unbalanced clk_exit_cpufreq_table(). Any platforms where
OPPs are not availble will fail on init because a freq table will not
be properly initialized.
Signed-off-by: Nishanth Menon n...@ti.com
[khil...@ti.com: changelog edits, and graceful failure mode changes]
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/cpufreq/omap-cpufreq.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 635778d..ce82d50 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -1,5 +1,5 @@
/*
- * CPU frequency scaling for OMAP
+ * CPU frequency scaling for OMAP using OPP information
*
* Copyright (C) 2005 Nokia Corporation
* Written by Tony Lindgren t...@atomide.com
@@ -197,7 +197,6 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
static int omap_cpu_exit(struct cpufreq_policy *policy)
{
- clk_exit_cpufreq_table(freq_table);
clk_put(mpu_clk);
return 0;
}
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/10] cpufreq: OMAP: fix freq_table leak
From: Nishanth Menon n...@ti.com
We use a single frequency table for multiple CPUs. But, with
OMAP4, since we have multiple CPUs, the cpu_init call for CPU1
causes freq_table previously allocated for CPU0 to be overwritten.
In addition, we dont free the table on exit path.
We solve this by maintaining an atomic type counter to ensure
just a single table exists at a given time.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/cpufreq/omap-cpufreq.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index a66c8b5..90918e1 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -45,6 +45,7 @@ static struct lpj_info global_lpj_ref;
#endif
static struct cpufreq_frequency_table *freq_table;
+static atomic_t freq_table_users = ATOMIC_INIT(0);
static struct clk *mpu_clk;
static char *mpu_clk_name;
static struct device *mpu_dev;
@@ -149,6 +150,12 @@ static int omap_target(struct cpufreq_policy *policy,
return ret;
}
+static inline void freq_table_free(void)
+{
+ if (atomic_dec_and_test(freq_table_users))
+ opp_free_cpufreq_table(mpu_dev, freq_table);
+}
+
static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
{
int result = 0;
@@ -163,7 +170,9 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
}
policy-cur = policy-min = policy-max = omap_getspeed(policy-cpu);
- result = opp_init_cpufreq_table(mpu_dev, freq_table);
+
+ if (atomic_inc_return(freq_table_users) == 1)
+ result = opp_init_cpufreq_table(mpu_dev, freq_table);
if (result) {
dev_err(mpu_dev, %s: cpu%d: failed creating freq table[%d]\n,
@@ -172,10 +181,10 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
}
result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
- if (!result)
- cpufreq_frequency_table_get_attr(freq_table, policy-cpu);
- else
- goto fail_ck;
+ if (result)
+ goto fail_table;
+
+ cpufreq_frequency_table_get_attr(freq_table, policy-cpu);
policy-min = policy-cpuinfo.min_freq;
policy-max = policy-cpuinfo.max_freq;
@@ -198,6 +207,8 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
return 0;
+fail_table:
+ freq_table_free();
fail_ck:
clk_put(mpu_clk);
return result;
@@ -205,6 +216,7 @@ fail_ck:
static int omap_cpu_exit(struct cpufreq_policy *policy)
{
+ freq_table_free();
clk_put(mpu_clk);
return 0;
}
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/10] cpufreq: OMAP: notify even with bad boot frequency
From: Colin Cross ccr...@google.com Sometimes, bootloaders starts up with a frequency which is not in the OPP table. At cpu_init, policy-cur contains the frequency we pick at boot. It is possible that system might have fixed it's boot frequency later on as part of power initialization. After this condition, the first call to omap_target results in the following: omap_getspeed(actual device frequency) != policy-cur(frequency that cpufreq thinks that the system is at), and it is possible that freqs.old == freqs.new (because the governor requested a scale down). We exit without triggering the notifiers in the current code, which does'nt let code which depends on cpufreq_notify_transition to have accurate information as to what the system frequency is. Instead, we do a normal transition if policy-cur is wrong, then, freqs.old will be the actual cpu frequency, freqs.new will be the actual new cpu frequency and all required notifiers have the accurate information. Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Colin Cross ccr...@google.com Signed-off-by: Kevin Hilman khil...@ti.com --- drivers/cpufreq/omap-cpufreq.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c index 5e2f05a..724d36c 100644 --- a/drivers/cpufreq/omap-cpufreq.c +++ b/drivers/cpufreq/omap-cpufreq.c @@ -96,7 +96,7 @@ static int omap_target(struct cpufreq_policy *policy, freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000; freqs.cpu = policy-cpu; - if (freqs.old == freqs.new) + if (freqs.old == freqs.new policy-cur == freqs.new) return ret; /* notifiers */ -- 1.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/10] cpufreq: OMAP: put clk if cpu_init failed
From: Nishanth Menon n...@ti.com
Release the mpu_clk in fail paths.
Reported-by: Todd Poynor toddpoy...@google.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/cpufreq/omap-cpufreq.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index ce82d50..a66c8b5 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -157,8 +157,10 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
if (IS_ERR(mpu_clk))
return PTR_ERR(mpu_clk);
- if (policy-cpu = NR_CPUS)
- return -EINVAL;
+ if (policy-cpu = NR_CPUS) {
+ result = -EINVAL;
+ goto fail_ck;
+ }
policy-cur = policy-min = policy-max = omap_getspeed(policy-cpu);
result = opp_init_cpufreq_table(mpu_dev, freq_table);
@@ -166,12 +168,14 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
if (result) {
dev_err(mpu_dev, %s: cpu%d: failed creating freq table[%d]\n,
__func__, policy-cpu, result);
- return result;
+ goto fail_ck;
}
result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
if (!result)
cpufreq_frequency_table_get_attr(freq_table, policy-cpu);
+ else
+ goto fail_ck;
policy-min = policy-cpuinfo.min_freq;
policy-max = policy-cpuinfo.max_freq;
@@ -193,6 +197,10 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
policy-cpuinfo.transition_latency = 300 * 1000;
return 0;
+
+fail_ck:
+ clk_put(mpu_clk);
+ return result;
}
static int omap_cpu_exit(struct cpufreq_policy *policy)
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP2+: clock: cleanup CPUfreq leftovers
Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no
longer need/use the clock framework code for filling up CPUfreq
tables. Remove it.
Signed-off-by: Kevin Hilman khil...@ti.com
---
Paul, this patch has a dependency on the OMAP CPUFreq driver
move/cleanup series just posted. Assuming that is merged for v3.2,
this can go also.
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 80 --
arch/arm/mach-omap2/clock.c |5 --
arch/arm/mach-omap2/clock.h |8 ---
3 files changed, 0 insertions(+), 93 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
index 39f9d5a..9a13e07 100644
--- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
+++ b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
@@ -164,83 +164,3 @@ int omap2_select_table_rate(struct clk *clk, unsigned long
rate)
return 0;
}
-
-#ifdef CONFIG_CPU_FREQ
-/*
- * Walk PRCM rate table and fillout cpufreq freq_table
- * XXX This should be replaced by an OPP layer in the near future
- */
-static struct cpufreq_frequency_table *freq_table;
-
-void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
-{
- const struct prcm_config *prcm;
- int i = 0;
- int tbl_sz = 0;
-
- if (!cpu_is_omap24xx())
- return;
-
- for (prcm = rate_table; prcm-mpu_speed; prcm++) {
- if (!(prcm-flags cpu_mask))
- continue;
- if (prcm-xtal_speed != sclk-rate)
- continue;
-
- /* don't put bypass rates in table */
- if (prcm-dpll_speed == prcm-xtal_speed)
- continue;
-
- tbl_sz++;
- }
-
- /*
-* XXX Ensure that we're doing what CPUFreq expects for this error
-* case and the following one
-*/
- if (tbl_sz == 0) {
- pr_warning(%s: no matching entries in rate_table\n,
- __func__);
- return;
- }
-
- /* Include the CPUFREQ_TABLE_END terminator entry */
- tbl_sz++;
-
- freq_table = kzalloc(sizeof(struct cpufreq_frequency_table) * tbl_sz,
-GFP_ATOMIC);
- if (!freq_table) {
- pr_err(%s: could not kzalloc frequency table\n, __func__);
- return;
- }
-
- for (prcm = rate_table; prcm-mpu_speed; prcm++) {
- if (!(prcm-flags cpu_mask))
- continue;
- if (prcm-xtal_speed != sclk-rate)
- continue;
-
- /* don't put bypass rates in table */
- if (prcm-dpll_speed == prcm-xtal_speed)
- continue;
-
- freq_table[i].index = i;
- freq_table[i].frequency = prcm-mpu_speed / 1000;
- i++;
- }
-
- freq_table[i].index = i;
- freq_table[i].frequency = CPUFREQ_TABLE_END;
-
- *table = freq_table[0];
-}
-
-void omap2_clk_exit_cpufreq_table(struct cpufreq_frequency_table **table)
-{
- if (!cpu_is_omap24xx())
- return;
-
- kfree(freq_table);
-}
-
-#endif
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 1f3481f..160e61c 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -536,10 +536,5 @@ struct clk_functions omap2_clk_functions = {
.clk_set_rate = omap2_clk_set_rate,
.clk_set_parent = omap2_clk_set_parent,
.clk_disable_unused = omap2_clk_disable_unused,
-#ifdef CONFIG_CPU_FREQ
- /* These will be removed when the OPP code is integrated */
- .clk_init_cpufreq_table = omap2_clk_init_cpufreq_table,
- .clk_exit_cpufreq_table = omap2_clk_exit_cpufreq_table,
-#endif
};
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 48ac568..7fa20b3 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -144,14 +144,6 @@ extern const struct clksel_rate gpt_sys_rates[];
extern const struct clksel_rate gfx_l3_rates[];
extern const struct clksel_rate dsp_ick_rates[];
-#if defined(CONFIG_ARCH_OMAP2) defined(CONFIG_CPU_FREQ)
-extern void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table
**table);
-extern void omap2_clk_exit_cpufreq_table(struct cpufreq_frequency_table
**table);
-#else
-#define omap2_clk_init_cpufreq_table 0
-#define omap2_clk_exit_cpufreq_table 0
-#endif
-
extern const struct clkops clkops_omap2_iclk_dflt_wait;
extern const struct clkops clkops_omap2_iclk_dflt;
extern const struct clkops clkops_omap2_iclk_idle_only;
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices
Abhilash K V abhilash...@ti.com writes:
In case of AM3517 AM3505, SmartReflex is not applicable so
we must not enable it.
This part is fine, but...
So omap3_twl_init() is now not called when the processor does not
support SR.
...I don't think this is right. DVFS using the PMIC is still doable
without SR.
Are you assuming that no DVFS is done on these devices?
Kevin
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/id.c |2 +-
arch/arm/mach-omap2/pm.c |3 ++-
arch/arm/plat-omap/include/plat/cpu.h |2 ++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index d27daf9..b7e3082 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -188,7 +188,7 @@ static void __init omap3_check_features(void)
if (cpu_is_omap3630())
omap_features |= OMAP3_HAS_192MHZ_CLK;
if (!cpu_is_omap3505() !cpu_is_omap3517())
- omap_features |= OMAP3_HAS_IO_WAKEUP;
+ omap_features |= (OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_SR);
omap_features |= OMAP3_HAS_SDRC;
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index d34fc52..da71abc 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -252,7 +252,8 @@ postcore_initcall(omap2_common_pm_init);
static int __init omap2_common_pm_late_init(void)
{
/* Init the OMAP TWL parameters */
- omap3_twl_init();
+ if (omap3_has_sr())
+ omap3_twl_init();
omap4_twl_init();
/* Init the voltage layer */
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 2f90269..cc6fcd3 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -413,6 +413,7 @@ extern u32 omap_features;
#define OMAP4_HAS_MPU_1GHZ BIT(8)
#define OMAP4_HAS_MPU_1_2GHZ BIT(9)
#define OMAP4_HAS_MPU_1_5GHZ BIT(10)
+#define OMAP3_HAS_SR BIT(11)
#define OMAP3_HAS_FEATURE(feat,flag) \
@@ -429,6 +430,7 @@ OMAP3_HAS_FEATURE(isp, ISP)
OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
OMAP3_HAS_FEATURE(sdrc, SDRC)
+OMAP3_HAS_FEATURE(sr, SR)
/*
* Runtime detection of OMAP4 features
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] OMAP2+: voltage: add check for missing PMIC info in vp init
Abhilash K V abhilash...@ti.com writes:
If PMIC info is not available in omap_vp_init(), abort.
Signed-off-by: Abhilash K V abhilash...@ti.com
Looks good, some minor nitpicking below...
---
arch/arm/mach-omap2/vp.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 66bd700..2c99837 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -41,6 +41,13 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
u32 val, sys_clk_rate, timeout, waittime;
u32 vddmin, vddmax, vstepmin, vstepmax;
+ if (!voltdm-pmic || !voltdm-pmic-uv_to_vsel) {
+ pr_err(%s: PMIC info requried to configure vp for
nit 1: s/vp/VP/
nit 2: need a space at the end of this string, otherwise the vdd_ will
be right after the for with no spaces.
+ vdd_%s not populated.Hence cannot initialize vp\n,
nit 3: Add space after '.'
Kevin
+ __func__, voltdm-name);
+ return;
+ }
+
if (!voltdm-read || !voltdm-write) {
pr_err(%s: No read/write API for accessing vdd_%s regs\n,
__func__, voltdm-name);
--
To unsubscribe from this list: send the line unsubscribe 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 01/10] cpufreq: OMAP: cleanup for multi-SoC support, move into drivers/cpufreq
* Kevin Hilman khil...@ti.com [110922 13:35]: From: Santosh Shilimkar santosh.shilim...@ti.com Move OMAP cpufreq driver from arch/arm/mach-omap2 into drivers/cpufreq, along with a few cleanups: - generalize support for better handling of different SoCs in the OMAP - use OPP layer instead of OMAP clock internals for frequency table init Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com [khil...@ti.com: move to drivers] Signed-off-by: Kevin Hilman khil...@ti.com Nice to see this happening: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] AM3517 : support for suspend/resume
Abhilash K V abhilash...@ti.com writes: This patch-set adds support for suspension to RAM and resumption on the AM3517. This includes: 1. Patch to disable dynamic sleep (as it is not supported on AM35xx). This should still be a separate patch, with justification. More on this below. 2. Imported the unique suspend/resume sequence for AM3517, contained in the new file arch/arm/mach-omap2/sleep3517.S. Caveat: If no_console_suspend is enabled (via boot-args),the device doesnot resume but simply hangs. Kevin's fix below should fix this: http://marc.info/?l=linux-omapm=131593828001388w=2#1 should fix? I assumed you tested it along with this. Signed-off-by: Ranjith Lohithakshan ranji...@ti.com Reviewed-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Abhilash K V abhilash...@ti.com --- This patch is dependent on the following patch-sets: * [PATCH v3 0/2] AM3517: Booting up at http://marc.info/?l=linux-omapm=131548349725176w=2 * [PATCH v2 0/3] AM35x: Adding PM init at http://marc.info/?l=linux-kernelm=131548606728209w=2 The patches are tested on master of tmlind/linux-omap-2.6.git. Kernel version is 3.1-rc3 and last commit on top of which these patches were added is: b148d763841161894ed6629794064065a834aa2b: Linux-omap rebuilt: Updated to use omap_sdrc_init with the folowing commit reverted: f3637a5f2e2eb391ff5757bc83fb5de8f9726464: irq: Always set IRQF_ONESHOT if no primary handler is specified Changes in v2: * Synchronised with the cleaned-up suspend-resume code for OMAP3 * Removed unused *_get_restore_pointer code * Added SECURE_SRAM feature to disallow saving and restoring secure ram context for AM35x Adding a new feature flag should be a separate patch. * Compacted the number of patches by squashing three closely coupled ones and eliminating one that was no longer needed. arch/arm/mach-omap2/Makefile |3 +- arch/arm/mach-omap2/id.c |4 +- arch/arm/mach-omap2/pm.h |3 + arch/arm/mach-omap2/pm34xx.c | 21 - arch/arm/mach-omap2/sleep3517.S | 156 + arch/arm/plat-omap/include/plat/cpu.h |2 + 6 files changed, 183 insertions(+), 6 deletions(-) create mode 100644 arch/arm/mach-omap2/sleep3517.S diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 590e797..37f62ae 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -61,7 +61,7 @@ endif ifeq ($(CONFIG_PM),y) obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o -obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o \ +obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o sleep3517.o \ cpuidle34xx.o obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o @@ -70,6 +70,7 @@ obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o AFLAGS_sleep24xx.o :=-Wa,-march=armv6 AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec) +AFLAGS_sleep3517.o :=-Wa,-march=armv7-a$(plus_sec) ifeq ($(CONFIG_PM_VERBOSE),y) CFLAGS_pm_bus.o += -DDEBUG diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index da71098..3e40c02 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -202,7 +202,9 @@ static void __init omap3_check_features(void) if (cpu_is_omap3630()) omap_features |= OMAP3_HAS_192MHZ_CLK; if (!cpu_is_omap3505() !cpu_is_omap3517()) - omap_features |= (OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_SR); + omap_features |= (OMAP3_HAS_IO_WAKEUP + | OMAP3_HAS_SR + | OMAP3_HAS_SECURE_SRAM); This is not related to suspend either, and should probably be part of the bootup series. The HAS_SECURE_SRAM part should be added to the separate patch that adds this new feature flag. omap_features |= OMAP3_HAS_SDRC; diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h index ce028f6..952eb2b 100644 --- a/arch/arm/mach-omap2/pm.h +++ b/arch/arm/mach-omap2/pm.h @@ -82,10 +82,13 @@ extern unsigned int omap24xx_cpu_suspend_sz; /* 3xxx */ extern void omap34xx_cpu_suspend(int save_state); +extern void omap3517_cpu_suspend(int save_state); /* omap3_do_wfi function pointer and size, for copy to SRAM */ extern void omap3_do_wfi(void); +extern void omap3517_do_wfi(void); extern unsigned int omap3_do_wfi_sz; +extern unsigned int omap3517_do_wfi_sz; /* ... and its pointer from SRAM after copy */ extern void (*omap3_do_wfi_sram)(void); diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 7255d9b..44f7bac 100644 ---
Re: [PATCH v3 3/3] OMAP3: Remove auto-selection of PMICs
Abhilash K V abhilash...@ti.com writes: The current implementation almost assumes that only almost? ;) TWL4030/TWL5030/TWl6030 are (or can be) used with the OMAP processors. This is, however, not true. This patch removes the automatic selection of the PMIC from Kconfig. All currently used PMICs are now added to omap2plus_defconfig; I don't think adding them to omap2plus_defconfig is right either, as those will get stripped out the next time that file is (re)generated. any new PMIC that gets supported in future could now be enabled here rather than by changing Kconfig for ARCH_OMAP2PLUS_TYPICAL IMO, the right fix is to have the board Kconfig entries select the PMIC being used on those boards. That is the only solution that will scale, and also work when using 'make randconfig'. Kevin Signed-off-by: Sanjeev Premi pr...@ti.com Signed-off-by: Abhilash K V abhilash...@ti.com --- arch/arm/configs/omap2plus_defconfig |3 +++ arch/arm/mach-omap2/Kconfig |3 --- drivers/mfd/Kconfig |2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index d5f00d7..076b131 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -130,6 +130,9 @@ CONFIG_POWER_SUPPLY=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y +CONFIG_MENELAUS=y +CONFIG_TWL4030_CORE=y +CONFIG_TWL4030_POWER=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 7edf802..d40f6d2 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -15,9 +15,6 @@ config ARCH_OMAP2PLUS_TYPICAL select I2C select I2C_OMAP select MFD_SUPPORT - select MENELAUS if ARCH_OMAP2 - select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 - select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 help Compile a kernel suitable for booting most boards diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 21574bd..72e15c8 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -238,7 +238,7 @@ config TWL4030_MADC config TWL4030_POWER bool Support power resources on TWL4030 family chips - depends on TWL4030_CORE ARM + depends on TWL4030_CORE help Say yes here if you want to use the power resources on the TWL4030 family chips. Most of these resources are regulators, -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] OMAP3: Remove auto-selection of PMICs
* Kevin Hilman khil...@ti.com [110922 14:30]: Abhilash K V abhilash...@ti.com writes: The current implementation almost assumes that only almost? ;) TWL4030/TWL5030/TWl6030 are (or can be) used with the OMAP processors. This is, however, not true. This patch removes the automatic selection of the PMIC from Kconfig. All currently used PMICs are now added to omap2plus_defconfig; I don't think adding them to omap2plus_defconfig is right either, as those will get stripped out the next time that file is (re)generated. any new PMIC that gets supported in future could now be enabled here rather than by changing Kconfig for ARCH_OMAP2PLUS_TYPICAL IMO, the right fix is to have the board Kconfig entries select the PMIC being used on those boards. That is the only solution that will scale, and also work when using 'make randconfig'. Agreed. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] AM35x: voltage: Basic initialization
Hi Abhilash,
Abhilash K V abhilash...@ti.com writes:
This patch adds the basic initialization of voltage layer
for AM35x. Since AM35x doesn't support voltage scaling,
I must admit to still being confused by this series.
This patch says AM35x doesn't support voltage scaling, and the next
patch adds PMIC support, and registers it with the voltage layer.
However, with each voltdm-scalable flag set to false, none of the PMIC
values will ever be used (by the current voltage layer.) Do you have
more patches on top of this that extend the voltage layer to directly
use the PMIC instead of using VC or VP?
I'm assuming we have some more assumptions in our current voltage layer
about the presence of VC/VP that are wrong and need to be fixed. Now
that the big voltage layer cleanup is done, I am *very* interested in
getting rid of any more assumptions we have in that code about how
devices are hooked up with PMICs.
Can you summarize how these devices are using (or want to use) the
voltage layer?
Thanks,
Kevin
Many functions have been defined to plug into existing
voltage layer.
Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/omap_opp_data.h |1 +
arch/arm/mach-omap2/opp3xxx_data.c|9 +
arch/arm/mach-omap2/voltagedomains3xxx_data.c | 10 --
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_opp_data.h
b/arch/arm/mach-omap2/omap_opp_data.h
index c784c12..c7cedf3 100644
--- a/arch/arm/mach-omap2/omap_opp_data.h
+++ b/arch/arm/mach-omap2/omap_opp_data.h
@@ -88,6 +88,7 @@ extern struct omap_volt_data omap34xx_vddmpu_volt_data[];
extern struct omap_volt_data omap34xx_vddcore_volt_data[];
extern struct omap_volt_data omap36xx_vddmpu_volt_data[];
extern struct omap_volt_data omap36xx_vddcore_volt_data[];
+extern struct omap_volt_data am35xx_vdd_volt_data[];
extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[];
extern struct omap_volt_data omap44xx_vdd_iva_volt_data[];
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index d95f3f9..e4a5ee6 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -85,6 +85,15 @@ struct omap_volt_data omap36xx_vddcore_volt_data[] = {
VOLT_DATA_DEFINE(0, 0, 0, 0),
};
+/* AM35x
+ *
+ * Fields related to SmartReflex and Voltage Processor are set to 0.
+ */
fix multi-line comment style (search for 'multi-line' in
Documentation/CodingStyle)
+struct omap_volt_data am35xx_vdd_volt_data[] = {
+ VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP3_UV, 0x0, 0x0, 0x0),
+ VOLT_DATA_DEFINE(0, 0, 0, 0),
+};
+
/* OPP data */
static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
index 071101d..530082f 100644
--- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
@@ -85,7 +85,10 @@ void __init omap3xxx_voltagedomains_init(void)
* XXX Will depend on the process, validation, and binning
* for the currently-running IC
*/
- if (cpu_is_omap3630()) {
+ if (cpu_is_omap3505() || cpu_is_omap3517()) {
+ omap3_voltdm_mpu.volt_data = am35xx_vdd_volt_data;
+ omap3_voltdm_core.volt_data = am35xx_vdd_volt_data;
+ } else if (cpu_is_omap3630()) {
omap3_voltdm_mpu.volt_data = omap36xx_vddmpu_volt_data;
omap3_voltdm_core.volt_data = omap36xx_vddcore_volt_data;
} else {
@@ -93,8 +96,11 @@ void __init omap3xxx_voltagedomains_init(void)
omap3_voltdm_core.volt_data = omap34xx_vddcore_volt_data;
}
- for (i = 0; voltdm = voltagedomains_omap3[i], voltdm; i++)
+ for (i = 0; voltdm = voltagedomains_omap3[i], voltdm; i++) {
+ if (cpu_is_omap3505() || cpu_is_omap3517())
+ voltdm-scalable = false;
voltdm-sys_clk.name = sys_clk_name;
+ }
voltdm_init(voltagedomains_omap3);
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] cpufreq: OMAP: Add SMP support for OMAP4+
Kevin Hilman khil...@ti.com writes: From: Russell King rmk+ker...@arm.linux.org.uk On OMAP SMP configuartion, both processors share the voltage and clock. So both CPUs needs to be scaled together and hence needs software co-ordination. [...] diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c index a6b2be7..f9b4c4d 100644 --- a/drivers/cpufreq/omap-cpufreq.c +++ b/drivers/cpufreq/omap-cpufreq.c @@ -23,6 +23,7 @@ #include linux/clk.h #include linux/io.h #include linux/opp.h +#include linux/cpu.h #include asm/system.h #include asm/smp_plat.h Thanks to checkpatch, I blindly removed an #include asm/cpu.h here without re-testing. Turns out it was important. Added it back, and updated the version available in my for_3.2/omap-cpufreq branch. 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 1/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi On Thu, 22 Sep 2011, Cousson, Benoit wrote: ADDR_TYPE_RT is mainly use for sysconfig access inside hwmod core today, so why should we use it in this case? Just for consistency, since the flag isn't defined to be SYSCONFIG-specific. That way, if there's another need -- other than SYSCONFIG access -- to identify the chunk of address space that's used for register access, we won't have to dig through and possibly repatch the hwmod data, just because some people didn't want to follow the rule. If the flag was simply defined to be SYSCONFIG-specific, then you're right, it wouldn't be needed. To be honest, I've been confused with that flag for some time :-) * ADDR_TYPE_RT: Address space contains module register target data. Maybe that's my English, but what does register target data mean exactly? The name comes from the L3 section of the 34xx TRM - see for example section 9.1.1 Terminology of the rev ZR TRM. The L3 has several address space sections, and whoever wrote that text -- Sonics? -- called the one with the L3's own internal registers the register target. And I was looking for a name that I did not have to make up, so I personally wouldn't have to defend the name ;-) What was the intent? Providing a way to identify some register vs memory space? As you suggest, the original impetus for the flag was to identify which chunk of address space needs to be mapped by the hwmod code for SYSCONFIG accesses to work. On current OMAPs, this seems to be the same thing as identifying the IP block's primary register area for every module with SYS* and REVISION registers. And I probably thought at the time that specifying the IP block's main register mapping seemed more useful and generally applicable than designating where the SYSCONFIG register was. Hence the current definition. Regarding main_clk, I do not think that some internal IPs like ohci/ehci should have a main_clk, since this is not visible at that level. Do you not agree that every IP block that contains sequential logic on current and foreseeable future SoCs must have some clock signal to drive that logic? The idea of the main_clk was not intended to be PRCM or OCP or even OMAP-specific. It's just intended to represent a clock that is used to drive the register logic inside the IP block. Therefore it must be enabled before any register access may occur. Even if clock gating is handled by some higher-level interface (e.g., at the IP block level), the main_clk has a rate, so it also implies an upper limit on how quickly register operations can occur. I suppose that all of the IP block's clocks could be optional clocks, but we know that every IP block with registers requires at least one clock to work, and that should be the main_clk. These blocks do not have any PRCM / OCP connection. In fact they should not even be hwmod in theory, these are just some internal IPs inside the usb_host controller. After looking at the OMAP USB host controller drivers, particularly drivers/mfd/omap-usb-host.c, I completely agree: it's not just theory: OMAP shouldn't have EHCI and OHCI hwmods in practice, either :-) These are hwmods just because of the dynamic mux support needed by these IPs. That was one of the comments I made on these, and Keshava explained me the rational and added it in the changelog. On OMAP, since the EHCI and OHCI IP blocks are integrated into the UHH IP block, an MFD driver creates the EHCI and OHCI platform_devices (see drivers/mfd/omap-usb-host.c:omap_usbhs_alloc_children()). On OMAP, the EHCI and OHCI aren't hwmod-backed devices, and so they shouldn't be using the hwmod dynamic pin remuxing code directly. So I'd suggest one of two approaches: 1. If the pin muxing can follow the PM runtime status of the UHH IP block, then the pin mux data should be associated with the UHH hwmod. 2. If the pin muxing must follow the EHCI/OHCI IP block PM runtime status, then drivers/mfd/omap-usb-host.c is what should be handling the remuxing. omap-usb-host.c can set the dev_pm_ops of the EHCI/OHCI platform_devices to point to functions either in arch/arm/mach-omap2/usb-host.c, or local functions that call into mach-omap2/usb-host.c functions to handle pin remuxing. (Those function pointers should be provided to the MFD driver in some clean way, like via platform_data.) Hopefully, we will not have that limitation once we will have migrated that to DT :-) Even if the data is coming from some other source, if the code still relies on main_clk, then it will need to be present. But why do you perceive that specifying a main_clk is a limitation? Or, put differently: what problem is caused by specifying a main_clk here? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi Keshava so based on a closer look at how the EHCI/OHCI IP blocks are actually implemented on OMAP, they should not have hwmod entries associated with them. Please take a look at http://marc.info/?l=linux-omapm=131673433121673w=2 - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] arm: omap: usb: enable I/O wakeups of ehci and ohci hwmods
Hi so as http://marc.info/?l=linux-omapm=131673433121673w=2 mentions, these should either be associated with the UHH IP block, or handled by code in arch/arm/mach-omap2/usb-host.c, since the EHCI and OHCI IP blocks are created by the OMAP USB host MFD driver. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2+: clock: cleanup CPUfreq leftovers
Hi Kevin On Thu, 22 Sep 2011, Kevin Hilman wrote: Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no longer need/use the clock framework code for filling up CPUfreq tables. Remove it. Signed-off-by: Kevin Hilman khil...@ti.com --- Paul, this patch has a dependency on the OMAP CPUFreq driver move/cleanup series just posted. Assuming that is merged for v3.2, this can go also. Great, could you cc lakml also ? thanks, - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/26] gpio/omap: driver cleanup and fixes
Tarun Kanti DebBarma tarun.ka...@ti.com writes: This series is continuation of cleanup of OMAP GPIO driver and fixes. The cleanup include getting rid of cpu_is_* checks wherever possible, use of gpio_bank list instead of static array, use of unique platform specific value associated data member to OMAP platforms to avoid cpu_is_* checks. The series also include PM runtime support.* PER is still not hitting retention for me on 34xx/n900 when GPIOs have debounce enabled. Disabling debounce in the board file makes it work. [...] - Add dbclk aliases for all GPIO modules. Without this, GPIO modules were not getting the correct clock handle to enable/disable debounec clock. This isn't right. hwmod should already be adding aliases for the optional clocks. After debugging this myself a bit, here's what I think may be going on. This may not be the only problem but here's at least one of them. First, debounce clocks are disabled in the runtime_suspend callback. When a GPIO is freed and it's the last one in the bank, bank-mod_usage goes to zero. After that, pm_runtime_put_sync() is called, which will trigger the driver's -runtime_suspend callback. The -runtime_suspend() callback checks bank-mod_usage as well, and if zero, doesn't do anything (notably, it doesn't disable debounce clocks.) 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 1/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi On Thu, 22 Sep 2011, Paul Walmsley wrote: On Thu, 22 Sep 2011, Cousson, Benoit wrote: ADDR_TYPE_RT is mainly use for sysconfig access inside hwmod core today, so why should we use it in this case? Just for consistency, since the flag isn't defined to be SYSCONFIG-specific. That way, if there's another need -- other than SYSCONFIG access -- to identify the chunk of address space that's used for register access, we won't have to dig through and possibly repatch the hwmod data, just because some people didn't want to follow the rule. If the flag was simply defined to be SYSCONFIG-specific, then you're right, it wouldn't be needed. To be honest, I've been confused with that flag for some time :-) * ADDR_TYPE_RT: Address space contains module register target data. Maybe that's my English, but what does register target data mean exactly? The name comes from the L3 section of the 34xx TRM - see for example section 9.1.1 Terminology of the rev ZR TRM. The L3 has several address space sections, and whoever wrote that text -- Sonics? -- called the one with the L3's own internal registers the register target. And I was looking for a name that I did not have to make up, so I personally wouldn't have to defend the name ;-) What was the intent? Providing a way to identify some register vs memory space? As you suggest, the original impetus for the flag was to identify which chunk of address space needs to be mapped by the hwmod code for SYSCONFIG accesses to work. On current OMAPs, this seems to be the same thing as identifying the IP block's primary register area for every module with SYS* and REVISION registers. And I probably thought at the time that specifying the IP block's main register mapping seemed more useful and generally applicable than designating where the SYSCONFIG register was. Hence the current definition. Hopefully this should go without saying, but if you think there's a good rationale for renaming this flag to indicate that an address space contains the SYSCONFIG registers, or maybe just changing the documentation for the flag to indicate that, that's fine with me, just send a patch. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/3] TI81XX: Prepare for addition of TI814X support
Tony Lindgren wrote on Thursday, September 22, 2011 11:51 PM:
* Pedanekar, Hemant hema...@ti.com [110921 17:00]:
Tony Lindgren wrote on Thursday, September 22, 2011 2:11 AM:
* Hemant Pedanekar hema...@ti.com [110921 10:05]:
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -37,16 +37,16 @@ static void __init ti8168_evm_init(void)
static void __init ti8168_evm_map_io(void)
{
- omap2_set_globals_ti816x();
- omapti816x_map_common_io();
+ omap2_set_globals_ti81xx();
+ omapti81xx_map_common_io();
}
MACHINE_START(TI8168EVM, ti8168evm)
/* Maintainer: Texas Instruments */
.atag_offset= 0x100,
.map_io = ti8168_evm_map_io,
- .init_early = ti816x_init_early,
- .init_irq = ti816x_init_irq,
+ .init_early = ti81xx_init_early,
+ .init_irq = ti81xx_init_irq,
.timer = omap3_timer,
.init_machine = ti8168_evm_init,
MACHINE_END
Looks like you still need a minor rebase on the current cleanup
branch as the ti8668_evm_map_io is no longer needed. The cleanup
branch already has Paul's CHIP_IS removal, so that should be trivial.
Tony,
Can you please clarify? Do we not need ti8168_evm_map_io() for global data
initianlization and io init? Or, as you mentioned in comment on 3/3 of the
series, do you mean to rename this with ti81xx and move to common.c?
Yes just have a generic one in common.c should be enough. Sorry I thought
that was already done, but looks like it was only done for omap3_map_io.
Ideally the rename patch would be separate without any functional
changes, maybe you can move the changes and additions to the next patch?
Tony
If the above understanding is correct, then I will just have to rename+move
ti8168_evm_map_io() so the change can still be in this patch, right? Or are
You referring to any other part which should not be in this patch?
Yes it's OK to keep it in this patch.
Tony
Thanks. I will send updated version.
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] hwmon: OMAP4460+: On die temperature sensor driver
Hi Guenter, Thanks for your quick review comments. On Thu, Sep 22, 2011 at 11:20 PM, Guenter Roeck guenter.ro...@ericsson.com wrote: On Thu, 2011-09-22 at 13:36 -0400, Keerthy wrote: On chip temperature sensor driver. The driver monitors the temperature of on die subsystems. It sends notifications to the user space if the temperature crosses user defined thresholds via kobject_uevent interface. The user is allowed to configure the temperature thresholds vis sysfs nodes exposed using hwmon interface. The patch depends on the the following series: http://comments.gmane.org/gmane.linux.ports.arm.omap/64436 and http://permalink.gmane.org/gmane.linux.ports.arm.omap/64446 Signed-off-by: Keerthy j-keer...@ti.com Cc: Jean Delvare kh...@linux-fr.org Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: lm-sens...@lm-sensors.org --- Documentation/hwmon/omap_temp_sensor | 25 +++ drivers/hwmon/Kconfig | 11 ++ drivers/hwmon/Makefile | 1 + drivers/hwmon/omap4460plus_temp_sensor.c | 244 ++ 4 files changed, 281 insertions(+), 0 deletions(-) create mode 100644 Documentation/hwmon/omap_temp_sensor create mode 100644 drivers/hwmon/omap4460plus_temp_sensor.c Index: linux-omap-2.6/Documentation/hwmon/omap_temp_sensor === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-omap-2.6/Documentation/hwmon/omap_temp_sensor 2011-09-22 18:57:23.180918857 +0530 @@ -0,0 +1,25 @@ +Kernel driver omap_temp_sensor +== + +Supported chips: + * Texas Instruments OMAP4460 + Prefix: 'omap_temp_sensor' + +Author: + J Keerthy j-keer...@ti.com + +Description +--- + +The Texas Instruments OMAP4 family of chips have a bandgap temperature sensor. +The temperature sensor feature is used to convert the temperature of the device +into a decimal value coded on 10 bits. An internal ADC is used for conversion. +The recommended operating temperatures must be in the range -40 degree Celsius +to 123 degree celsius for standard conversion. +The thresholds are programmable and upon crossing the thresholds an interrupt +is generated. The OMAP temperature sensor has a programmable update rate in +milli seconds. +(Currently the driver programs a default of 2000 milliseconds). + +The driver provides the common sysfs-interface for temperatures (see +Documentation/hwmon/sysfs-interface under Temperatures). Index: linux-omap-2.6/drivers/hwmon/Kconfig === --- linux-omap-2.6.orig/drivers/hwmon/Kconfig 2011-09-22 17:48:38.032575702 +0530 +++ linux-omap-2.6/drivers/hwmon/Kconfig 2011-09-22 19:02:28.744575604 +0530 @@ -323,6 +323,17 @@ This driver can also be built as a module. If so, the module will be called f71805f. +config SENSORS_OMAP_BANDGAP_TEMP_SENSOR + bool OMAP on-die temperature sensor hwmon driver + depends on HWMON ARCH_OMAP OMAP4460PLUS_SCM + help + If you say yes here you get support for hardware + monitoring features of the OMAP on die temperature + sensor. + + Continuous conversion programmable delay + mode is used for temperature conversion. + config SENSORS_F71882FG tristate Fintek F71882FG and compatibles help Index: linux-omap-2.6/drivers/hwmon/Makefile === --- linux-omap-2.6.orig/drivers/hwmon/Makefile 2011-09-22 17:48:38.020575728 +0530 +++ linux-omap-2.6/drivers/hwmon/Makefile 2011-09-22 18:57:23.192574712 +0530 @@ -93,6 +93,7 @@ obj-$(CONFIG_SENSORS_MAX6642) += max6642.o obj-$(CONFIG_SENSORS_MAX6650) += max6650.o obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o +obj-$(CONFIG_SENSORS_OMAP_BANDGAP_TEMP_SENSOR) += omap4460plus_temp_sensor.o obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o obj-$(CONFIG_SENSORS_PC87360) += pc87360.o obj-$(CONFIG_SENSORS_PC87427) += pc87427.o Index: linux-omap-2.6/drivers/hwmon/omap4460plus_temp_sensor.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-omap-2.6/drivers/hwmon/omap4460plus_temp_sensor.c 2011-09-22 19:02:11.096575567 +0530 @@ -0,0 +1,242 @@ +/* + * + * OMAP4460 Plus bandgap on die sensor hwmon driver. + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * J Keerthy j-keer...@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. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of +
Re: [PATCH v7 00/26] gpio/omap: driver cleanup and fixes
[...] This series is continuation of cleanup of OMAP GPIO driver and fixes. The cleanup include getting rid of cpu_is_* checks wherever possible, use of gpio_bank list instead of static array, use of unique platform specific value associated data member to OMAP platforms to avoid cpu_is_* checks. The series also include PM runtime support.* Baseline: git://gitorious.org/khilman/linux-omap-pm.git Branch: for_3.2/gpio-cleanup Commit: 8323374 Thanks Tony for ack'ing the patches. Kevin, Since Tony's has acked the patches, can you please pull them? Before merging, I still need to review and test this version, and I *might* still get to it this week. That's fine. Thanks. Based on the dbclk aliases you added, I assume this has now been tested on platforms using some GPIOs with debounce enabled? I have replicated gpio_debounce() code within *_gpio_mod_init() whereby _set_gpio_debounce() is called to enable debounce. After this, confirmed system going to off-mode through the CPU IDLE path. -- Tarun 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
