Re: [PATCH] ARM: OMAP4: cpuidle: Fix the C-state reporting to cpuidle governor.
On Wednesday 08 February 2012 04:08 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
OMAP4 cpuidle driver is reporting the state requested by governor rather than
the actually attempted one.
This is obviously misleading sysfs and powertop cpuidle statistics.
Fix it so that stats are reported correctly.
Reported-by: Kevin Hilman khil...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index cfdbb86..f128489 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -85,6 +85,7 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
cpu1_state = pwrdm_read_pwrst(cpu1_pd);
if (cpu1_state != PWRDM_POWER_OFF) {
new_state_idx = drv-safe_state_index;
+index = drv-safe_state_index;
How about just get rid of new_state_idx all together and just update
index and use it to index in to the states.
Make sense. Updated patch below.
Regards,
Santosh
From 939dc3eda7895043c03526110e2a6b41e9861146 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Sun, 5 Feb 2012 13:18:44 +0530
Subject: [PATCH 2/2] ARM: OMAP4: cpuidle: Fix the C-state reporting to
cpuidle governor.
OMAP4 cpuidle driver is reporting the state requested by governor rather
than
the actually attempted one.
This is obviously misleading sysfs and powertop cpuidle statistics.
Fix it so that stats are reported correctly.
While at this, get rid of new_state_idx, update and use
index in to the states.
Reported-by: Kevin Hilman khil...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index cfdbb86..72e018b 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -65,7 +65,6 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 cpu1_state;
int idle_time;
- int new_state_idx;
int cpu_id = smp_processor_id();
/* Used to keep track of the total time in idle */
@@ -84,8 +83,8 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
*/
cpu1_state = pwrdm_read_pwrst(cpu1_pd);
if (cpu1_state != PWRDM_POWER_OFF) {
- new_state_idx = drv-safe_state_index;
- cx = cpuidle_get_statedata(dev-states_usage[new_state_idx]);
+ index = drv-safe_state_index;
+ cx = cpuidle_get_statedata(dev-states_usage[index]);
}
if (index 0)
--
1.7.4.1
From 939dc3eda7895043c03526110e2a6b41e9861146 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Sun, 5 Feb 2012 13:18:44 +0530
Subject: [PATCH 2/2] ARM: OMAP4: cpuidle: Fix the C-state reporting to cpuidle governor.
OMAP4 cpuidle driver is reporting the state requested by governor rather than
the actually attempted one.
This is obviously misleading sysfs and powertop cpuidle statistics.
Fix it so that stats are reported correctly.
While at this, get rid of new_state_idx, update and use
index in to the states.
Reported-by: Kevin Hilman khil...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index cfdbb86..72e018b 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -65,7 +65,6 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 cpu1_state;
int idle_time;
- int new_state_idx;
int cpu_id = smp_processor_id();
/* Used to keep track of the total time in idle */
@@ -84,8 +83,8 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
*/
cpu1_state = pwrdm_read_pwrst(cpu1_pd);
if (cpu1_state != PWRDM_POWER_OFF) {
- new_state_idx = drv-safe_state_index;
- cx = cpuidle_get_statedata(dev-states_usage[new_state_idx]);
+ index = drv-safe_state_index;
+ cx = cpuidle_get_statedata(dev-states_usage[index]);
}
if (index 0)
--
1.7.4.1
Re: OMAP34xx
Hi, On Thu, Feb 09, 2012 at 11:34:42AM -0800, Rex Feany wrote: I also get these warnings when compiling: CC arch/arm/mach-omap2/usb-host.o arch/arm/mach-omap2/usb-host.c: In function 'usbhs_init': arch/arm/mach-omap2/usb-host.c:528: warning: assignment from incompatible pointer type yeah, I'll send a patch for that. CC drivers/usb/host/ehci-hcd.o drivers/usb/host/ehci-hub.c:1079: warning: 'ehci_relinquish_port' defined but not used drivers/usb/host/ehci-hub.c:1088: warning: 'ehci_port_handed_over' defined but not used This can't really be fixed without some extra trickery. The fact is that OMAP can't handle port handoff (go figure) and if we use those functions, we might end up in a situation where USB doesn't work just because you connected a full speed device. By not using those functions, we guarantee that the full speed device won't get enumerated but USB will still be functional after you disconnect such device. We could add a bunch of __maybe_unused annotation to all those ehci_* functions. What do you say Alan ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/2] ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback
On Saturday 11 February 2012 12:49 AM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [120202 05:33]:
arm_memblock_steal() is not suppose to be used outside -reserve callback.
OMAP barrier errata code was using it outside reserve callback and hence
it was broken.
Move the allocation as part of -reserve callback to fix the it.
Please update this to mention again commit that changed things
around for arm_memblock_steal() so it's clear why this is needed
as a fix.
Sure. Patch with updated change log below.
Regards,
Santosh
From 4d1ea22985adfe458275b9ae3e00edc6e41a267f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Thu, 2 Feb 2012 15:59:51 +0530
Subject: [PATCH 1/2] ARM: OMAP4: Move the barrier memboclk_steal() as
part of reserve callback
Commit 716a3dc{ARM: Add arm_memblock_steal() to allocate memory away
from the kernel} introduced arm_memblock_steal() which lead to
OMAP4_ERRATA_I688 to be broken and needed to be fixed.
arm_memblock_steal() is not suppose to be used outside -reserve callback.
OMAP barrier errata code was using it outside reserve callback and hence
it was broken.
Move the allocation as part of -reserve callback to fix the it.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig |4 ++--
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/io.c |1 +
arch/arm/mach-omap2/omap4-common.c| 25
-
arch/arm/plat-omap/common.c |1 +
arch/arm/plat-omap/include/plat/omap-secure.h |6 ++
6 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index d965da4..e20c8ab 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -364,8 +364,8 @@ config OMAP3_SDRC_AC_TIMING
going on could result in system crashes;
config OMAP4_ERRATA_I688
- bool OMAP4 errata: Async Bridge Corruption (BROKEN)
- depends on ARCH_OMAP4 BROKEN
+ bool OMAP4 errata: Async Bridge Corruption
+ depends on ARCH_OMAP4
select ARCH_HAS_BARRIERS
help
If a data is stalled inside asynchronous bridge because of back
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index febffde..7e9338e 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -132,6 +132,7 @@ void omap3_map_io(void);
void am33xx_map_io(void);
void omap4_map_io(void);
void ti81xx_map_io(void);
+void omap_barriers_init(void);
/**
* omap_test_timeout - busy-loop, testing a condition
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index eb50c29..fb11b44 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -307,6 +307,7 @@ void __init omapam33xx_map_common_io(void)
void __init omap44xx_map_common_io(void)
{
iotable_init(omap44xx_io_desc, ARRAY_SIZE(omap44xx_io_desc));
+ omap_barriers_init();
}
#endif
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 40a8fbc..ebc5950 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -24,6 +24,7 @@
#include plat/irqs.h
#include plat/sram.h
+#include plat/omap-secure.h
#include mach/hardware.h
#include mach/omap-wakeupgen.h
@@ -43,6 +44,9 @@ static void __iomem *sar_ram_base;
void __iomem *dram_sync, *sram_sync;
+static phys_addr_t paddr;
+static u32 size;
+
void omap_bus_sync(void)
{
if (dram_sync sram_sync) {
@@ -52,18 +56,20 @@ void omap_bus_sync(void)
}
}
-static int __init omap_barriers_init(void)
+/* Steal one page physical memory for barrier implementation */
+int __init omap_barrier_reserve_memblock(void)
{
- struct map_desc dram_io_desc[1];
- phys_addr_t paddr;
- u32 size;
-
- if (!cpu_is_omap44xx())
- return -ENODEV;
size = ALIGN(PAGE_SIZE, SZ_1M);
paddr = arm_memblock_steal(size, SZ_1M);
+ return 0;
+}
+
+void __init omap_barriers_init(void)
+{
+ struct map_desc dram_io_desc[1];
+
dram_io_desc[0].virtual = OMAP4_DRAM_BARRIER_VA;
dram_io_desc[0].pfn = __phys_to_pfn(paddr);
dram_io_desc[0].length = size;
@@ -75,9 +81,10 @@ static int __init omap_barriers_init(void)
pr_info(OMAP4: Map 0x%08llx to 0x%08lx for dram barrier\n,
(long long) paddr, dram_io_desc[0].virtual);
- return 0;
}
-core_initcall(omap_barriers_init);
+#else
+void __init omap_barriers_init(void)
+{}
#endif
void __init gic_init_irq(void)
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 06383b5..4de7d1e 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -69,6 +69,7 @@ void __init omap_reserve(void)
omap_vram_reserve_sdram_memblock();
[PATCH] arm: omap: usb-host: fix compile warning
when commit 3528c58 (OMAP: omap_device: when
building return platform_device instead of
omap_device) started returning a platform_device
instead of a omap_device pointer when building
a device, it failed to convert all users introducing
a compile warning when building
arch/arm/mach-omap2/usb-host.c.
This patch fixes that warning.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/usb-host.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 771dc78..f51348d 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -486,7 +486,7 @@ 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)
{
struct omap_hwmod *oh[2];
- struct omap_device *od;
+ struct platform_device *pdev;
int bus_id = -1;
int i;
@@ -522,11 +522,11 @@ void __init usbhs_init(const struct usbhs_omap_board_data
*pdata)
return;
}
- od = omap_device_build_ss(OMAP_USBHS_DEVICE, bus_id, oh, 2,
+ pdev = omap_device_build_ss(OMAP_USBHS_DEVICE, bus_id, oh, 2,
(void *)usbhs_data, sizeof(usbhs_data),
omap_uhhtll_latency,
ARRAY_SIZE(omap_uhhtll_latency), false);
- if (IS_ERR(od)) {
+ if (IS_ERR(pdev)) {
pr_err(Could not build hwmod devices %s,%s\n,
USBHS_UHH_HWMODNAME, USBHS_TLL_HWMODNAME);
return;
--
1.7.9
--
To unsubscribe from this list: send the line unsubscribe 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] i2c: fix missing handling of errata I2C_OMAP3_1P153
On 02/11/2012 06:18 PM, Shubhrajyoti wrote:
On Monday 06 February 2012 08:03 PM, tasskj...@gmail.com wrote:
From: Tasslehoff Kjappfottasskj...@gmail.com
i2c_prope set the dev-errata flag, but omap_i2c_init cleared the flag again.
Move the errata handling to i2c_init.
also in my opinion moving the reset to 0 should be moved to probe.
Do you mean moving all setting of the errate flag to probe instead of
having it in init?
also you may want to cc linux-i2c for the driver patches.
Done.
Signed-off-by: Tasslehoff Kjappfottasskj...@gmail.com
---
drivers/i2c/busses/i2c-omap.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..ecaa60d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -473,6 +473,10 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207)
dev-errata |= I2C_OMAP_ERRATA_I207;
+ if (dev-rev= OMAP_I2C_REV_ON_3430)
+ dev-errata |= I2C_OMAP3_1P153;
+
+
/* Enable interrupts */
dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
@@ -1058,9 +1062,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
- if (dev-rev= OMAP_I2C_REV_ON_3430)
- dev-errata |= I2C_OMAP3_1P153;
-
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
u16 s;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] I2C updates
On Tuesday 14 February 2012 11:42 AM, Hebbar, Gururaja wrote: Hi, I am interested in testing these patches on AM335x. Thanks for your interest in testin. Do you have a tree with these patches applied so that I can pull. tree: git://gitorious.org/linus-tree/linus-tree.git branch: i2c_misc_fixes let me know if that works for you On Fri, Feb 10, 2012 at 19:29:55, Datta, Shubhrajyoti wrote: This patch series colates the various i2c updates into a series. Since it is collection of various patches the version info is not retained, however most of them undergone multiple versions. This is rebased to linus head commit 63082402968f4b73f10b28a8ac1f3da821aeb82d The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - I2C register restore only if context if the context is lost - Bus busy recovery mechanism. - the reset is not done in init. Tested on omap4sdp and omap3sdp. Cc: Kevin Hilman khil...@ti.com Cc: Ben Dooks ben-li...@fluff.org Jon Hunter (1): I2C: OMAP: Correct I2C revision for OMAP3 Shubhrajyoti D (8): I2C : OMAP : make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME OMAP : I2C : Remove reset at init OMAP: I2C: I2C register restore only if context is lost OMAP: I2C: Fix the interrupt clearing in OMAP4 OMAP: I2C: Fix the mismatch of pm_runtime enable and disable OMAP: I2C: Optimise the remove code OMAP: I2C: Fix the error handling I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero Vikram Pandita (1): I2C: OMAP: Recover from Bus Busy condition drivers/i2c/busses/i2c-omap.c | 173 - 1 files changed, 101 insertions(+), 72 deletions(-) Regards, Gururaja -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: host: ehci: allow ehci_* symbols to be unused
not all platforms will use all of those ehci_*
symbols on their hc_driver structure. Sometimes
we might need to provide a modified version of
a certain method or not provide it at all, as is
the case with OMAPs which don't support port handoff
feature.
Whenever we compile a kernel for an OMAP board with
EHCI enabled, we get compile warnings:
drivers/usb/host/ehci-hub.c:1079: warning: 'ehci_relinquish_port' \
defined but not used
drivers/usb/host/ehci-hub.c:1088: warning: 'ehci_port_handed_over' \
defined but not used
In order to cleanup those warnings, we're adding
__maybe_unused annotation to those functions. We're
also trying to cope with other platforms which might
have similar issues with different methods by adding
the same annotation to all ehci_* functions.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Alan, what do you think about this patch ? It fixes our warnings
and tries to cope with other possible such cases.
drivers/usb/host/ehci-hub.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 77bbb23..d50571b 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -107,7 +107,7 @@ static void ehci_handover_companion_ports(struct ehci_hcd
*ehci)
ehci-owned_ports = 0;
}
-static int ehci_port_change(struct ehci_hcd *ehci)
+static int __maybe_unused ehci_port_change(struct ehci_hcd *ehci)
{
int i = HCS_N_PORTS(ehci-hcs_params);
@@ -201,7 +201,7 @@ static __maybe_unused void
ehci_adjust_port_wakeup_flags(struct ehci_hcd *ehci,
spin_unlock_irqrestore(ehci-lock, flags);
}
-static int ehci_bus_suspend (struct usb_hcd *hcd)
+static int __maybe_unused ehci_bus_suspend (struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
int port;
@@ -335,7 +335,7 @@ static int ehci_bus_suspend (struct usb_hcd *hcd)
/* caller has locked the root hub, and should reset/reinit on error */
-static int ehci_bus_resume (struct usb_hcd *hcd)
+static int __maybe_unused ehci_bus_resume (struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
u32 temp;
@@ -550,7 +550,7 @@ static int check_reset_complete (
/* build status change packet (one or two bytes) from HC registers */
-static int
+static int __maybe_unused
ehci_hub_status_data (struct usb_hcd *hcd, char *buf)
{
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
@@ -623,7 +623,7 @@ ehci_hub_status_data (struct usb_hcd *hcd, char *buf)
/*-*/
-static void
+static void __maybe_unused
ehci_hub_descriptor (
struct ehci_hcd *ehci,
struct usb_hub_descriptor *desc
@@ -658,7 +658,7 @@ ehci_hub_descriptor (
/*-*/
-static int ehci_hub_control (
+static int __maybe_unused ehci_hub_control (
struct usb_hcd *hcd,
u16 typeReq,
u16 wValue,
@@ -1076,7 +1076,8 @@ error_exit:
return retval;
}
-static void ehci_relinquish_port(struct usb_hcd *hcd, int portnum)
+static void __maybe_unused ehci_relinquish_port(struct usb_hcd *hcd,
+ int portnum)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
@@ -1085,7 +1086,8 @@ static void ehci_relinquish_port(struct usb_hcd *hcd, int
portnum)
set_owner(ehci, --portnum, PORT_OWNER);
}
-static int ehci_port_handed_over(struct usb_hcd *hcd, int portnum)
+static int __maybe_unused ehci_port_handed_over(struct usb_hcd *hcd,
+ int portnum)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
u32 __iomem *reg;
--
1.7.9
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3.3 v2] I2C: OMAP: fix build breakage when CONFIG_OF is not set
Hi Ben,
On Mon, 2012-02-13 at 23:27 +, Ben Dooks wrote:
On Wed, Feb 08, 2012 at 01:18:21PM +0200, Luciano Coelho wrote:
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f713eac..fd200eb 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -979,6 +979,8 @@ static const struct of_device_id omap_i2c_of_match[] = {
{ },
};
MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
+#else
+static const struct of_device_id *omap_i2c_of_match = NULL;
#endif
of_match_ptr(_ptr) will go to NULL if CONFIG_OF is not set, use that please.
Yes, you're right. But this patch can be ignored, since there was
already an equivalent one queued up (which I missed). And it uses
of_match_ptr() ;)
Thanks for your comment anyway!
--
Cheers,
Luca.
--
To unsubscribe from this list: send the line unsubscribe 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] i2c: fix missing handling of errata I2C_OMAP3_1P153
i2c_prope set the dev-errata flag, but omap_i2c_init cleared the flag again. Move the errata handling to i2c_probe. --- drivers/i2c/busses/i2c-omap.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 801df60..d609ae2 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -468,11 +468,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) /* Take the I2C module out of reset: */ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN); - dev-errata = 0; - - if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) - dev-errata |= I2C_OMAP_ERRATA_I207; - /* Enable interrupts */ dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY | OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK | @@ -1058,6 +1053,11 @@ omap_i2c_probe(struct platform_device *pdev) dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff; + dev-errata = 0; + + if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) + dev-errata |= I2C_OMAP_ERRATA_I207; + if (dev-rev = OMAP_I2C_REV_ON_3430) dev-errata |= I2C_OMAP3_1P153; -- 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] i2c: fix missing handling of errata I2C_OMAP3_1P153
Sorry about the bad mails. First time I use git send-email to follow up on a patch, and it seems I need to read up a bit more on it. Anyway. This patch is tested on our custom board based on Beagleboard rev C3. From 7c1e2c14bccb16c20dc7d93088b12ac6e6e351a3 Mon Sep 17 00:00:00 2001 From: Tasslehoff Kjappfot tasskj...@gmail.com Date: Mon, 6 Feb 2012 14:14:23 +0100 Subject: [PATCH] i2c: fix missing handling of errata I2C_OMAP3_1P153 i2c_prope set the dev-errata flag, but omap_i2c_init cleared the flag again. Move the errata handling to i2c_probe. Signed-off-by: Tasslehoff Kjappfot tasskj...@gmail.com --- drivers/i2c/busses/i2c-omap.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 801df60..d609ae2 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -468,11 +468,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) /* Take the I2C module out of reset: */ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN); - dev-errata = 0; - - if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) - dev-errata |= I2C_OMAP_ERRATA_I207; - /* Enable interrupts */ dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY | OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK | @@ -1058,6 +1053,11 @@ omap_i2c_probe(struct platform_device *pdev) dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff; + dev-errata = 0; + + if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) + dev-errata |= I2C_OMAP_ERRATA_I207; + if (dev-rev = OMAP_I2C_REV_ON_3430) dev-errata |= I2C_OMAP3_1P153; -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
Two more points:
On Mon, Feb 13, 2012 at 11:43:42AM -0500, Matt Porter wrote:
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f616f04d1f5da0e07bec4e0092f227 added the requirement
Always include the commit summary as well here, so:
Commit c7e963f616 (net/smsc911x: Add regulator support) added the ...
@@ -55,6 +94,11 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
+ if (platform_device_register(gpmc_smsc911x_regulator) 0) {
+ pr_err(Unable to register smsc911x regulators\n);
+ return;
+ }
It's always a good idea to indicate why something failed:
err = platform_device_register(gpmc_smsc911x_regulator);
if (err 0) {
pr_err(Unable to register smsc911x regulators: %d\n, err);
return;
}
so that people can see not only what failed, but also why it failed.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback
On Fri, Feb 10, 2012 at 11:19:26AM -0800, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [120202 05:33]: arm_memblock_steal() is not suppose to be used outside -reserve callback. OMAP barrier errata code was using it outside reserve callback and hence it was broken. Move the allocation as part of -reserve callback to fix the it. Please update this to mention again commit that changed things around for arm_memblock_steal() so it's clear why this is needed as a fix. It's more the case that this whole errata fix was broken right from the start, and the change to arm_memblock_steal() just enforced correct usage of the APIs. So, really the arm_memblock_steal() change has nothing to do with this. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback
On Tue, Feb 14, 2012 at 02:19:41PM +0530, Santosh Shilimkar wrote:
From 4d1ea22985adfe458275b9ae3e00edc6e41a267f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Thu, 2 Feb 2012 15:59:51 +0530
Subject: [PATCH 1/2] ARM: OMAP4: Move the barrier memboclk_steal() as
part of reserve callback
Commit 716a3dc{ARM: Add arm_memblock_steal() to allocate memory away
from the kernel} introduced arm_memblock_steal() which lead to
OMAP4_ERRATA_I688 to be broken and needed to be fixed.
That is misleading. Please don't attribute blame for this breakage to
that patch, which has nothing to do with introducing the breakage. The
errata was broken right from the start.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback
On Tue, Feb 14, 2012 at 4:44 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Feb 14, 2012 at 02:19:41PM +0530, Santosh Shilimkar wrote:
From 4d1ea22985adfe458275b9ae3e00edc6e41a267f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Thu, 2 Feb 2012 15:59:51 +0530
Subject: [PATCH 1/2] ARM: OMAP4: Move the barrier memboclk_steal() as
part of reserve callback
Commit 716a3dc{ARM: Add arm_memblock_steal() to allocate memory away
from the kernel} introduced arm_memblock_steal() which lead to
OMAP4_ERRATA_I688 to be broken and needed to be fixed.
That is misleading. Please don't attribute blame for this breakage to
that patch, which has nothing to do with introducing the breakage. The
errata was broken right from the start.
That's right and I didn't mean that way.
This was the same reason, first patch I just mentioned what was wrong
in the code
rather than mention of any commit.
Tony,
Let me know if you want to add any commit history to the change since
the issue was actually existing without 'arm_memblock_stea()' commit.
I think, first change log was good enough from the fix point of view.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] OMAPDSS: old OMAPFB cleanup
Hi Tony, On Tue, 2012-01-24 at 12:00 +0200, Tomi Valkeinen wrote: Now that all omap2+ boards have been changed to use the newer omapdss driver, this patch series removes omap2+ support from the old omapfb driver (drivers/video/omap), and thus makes it an omap1 dss/fb driver. The use of SRAM for video ram had earlier been disabled by removing the SRAM allocation (fee926bb0d399b1eaaf38f9f694bbf2747c4b8a2), and now this series also removes the support from the omap fb drivers. Also various cleanup patches allow us to remove remove OMAP_TAG_LCD and OMAP_TAG_FBMEM. All in all, the series removes quite a bit of unneeded code and cleans up the links between the board files and the display drivers, and this should help with device tree adaptation. Some of the patches affect the newer omapdss and omapfb drivers, but mostly the patches deal with omap1. I have compile tested the series for both omap1 and omap2, but I have only tested this on OMAP3 and OMAP4 boards, as I don't have OMAP1/2 boards. I think N770's display won't work after these patches, but other OMAP1 boards should be ok. To fix N770's display requires knowledge of the hardware setup, which is currently passed from the bootloader. Tony, do you have any feedback on this? I think the arch/arm changes are quite clean as such, but are you ok with (possibly) breaking N770's display? The other OMAP1 boards should, at least in theory, work as well as before. For N770, the bootloader passes the reset GPIO number and number of datalines, and I have no idea what those are. Tomi Tomi Tomi Valkeinen (16): OMAPFB: remove old blizzard driver OMAPFB: Remove OMAP2/3 support from old omapfb driver OMAPDSS: Remove video SRAM support OMAPFB: Remove video SRAM support (old omapfb) OMAP2+: remove unneeded #include omapfb.h OMAP: N770: remove HWA742 platform data OAMPFB: remove unused omapfb_set_ctrl_platform_data() OMAPFB: remove early mem alloc from old omapfb OMAPFB: remove mem info from platform_data OMAPFB: remove unused fb_format_to_dss_mode() OMAPFB: Move old omapfb private structs to a private include file OMAPFB: remove omapfb_set_platform_data() OMAP1: pass LCD config with omapfb_set_lcd_config() OMAP: Remove OMAP_TAG_LCD and OMAP_TAG_FBMEM OMAP1: Remove unused LCD devices from board files OMAPFB: remove remaining OMAP arch checks arch/arm/mach-omap1/board-ams-delta.c |9 +- arch/arm/mach-omap1/board-fsample.c| 15 +- arch/arm/mach-omap1/board-h2.c | 15 +- arch/arm/mach-omap1/board-h3.c |9 +- arch/arm/mach-omap1/board-htcherald.c |9 +- arch/arm/mach-omap1/board-innovator.c | 11 +- arch/arm/mach-omap1/board-nokia770.c | 19 +- arch/arm/mach-omap1/board-osk.c| 14 +- arch/arm/mach-omap1/board-palmte.c | 10 +- arch/arm/mach-omap1/board-palmtt.c | 10 +- arch/arm/mach-omap1/board-palmz71.c| 10 +- arch/arm/mach-omap1/board-perseus2.c | 15 +- arch/arm/mach-omap1/board-sx1.c| 16 +- arch/arm/mach-omap2/io.c |1 - arch/arm/plat-omap/common.c|2 - arch/arm/plat-omap/fb.c| 336 +-- arch/arm/plat-omap/fb.h| 10 - arch/arm/plat-omap/include/plat/blizzard.h | 12 - arch/arm/plat-omap/include/plat/board.h|2 - arch/arm/plat-omap/include/plat/hwa742.h |8 - arch/arm/plat-omap/include/plat/vram.h | 21 +- drivers/video/omap/Kconfig | 16 +- drivers/video/omap/Makefile| 12 +- drivers/video/omap/blizzard.c | 1648 drivers/video/omap/dispc.c | 1547 -- drivers/video/omap/dispc.h | 46 - drivers/video/omap/hwa742.c| 21 +- drivers/video/omap/omapfb.h| 25 +- drivers/video/omap/omapfb_main.c | 30 +- drivers/video/omap/rfbi.c | 598 -- drivers/video/omap2/dss/dispc.c|1 - drivers/video/omap2/omapfb/omapfb-ioctl.c |2 +- drivers/video/omap2/omapfb/omapfb-main.c | 101 +-- drivers/video/omap2/vram.c | 99 +-- include/linux/omapfb.h | 32 +- 35 files changed, 100 insertions(+), 4632 deletions(-) delete mode 100644 arch/arm/plat-omap/fb.h delete mode 100644 arch/arm/plat-omap/include/plat/blizzard.h delete mode 100644 arch/arm/plat-omap/include/plat/hwa742.h delete mode 100644 drivers/video/omap/blizzard.c delete mode 100644 drivers/video/omap/dispc.c delete mode 100644 drivers/video/omap/dispc.h delete mode 100644 drivers/video/omap/rfbi.c signature.asc Description: This is a digitally signed message part
Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
Hi, On Fri, 2012-02-10 at 11:45 +0530, Archit Taneja wrote: For DSS clock domain to transition from idle to active state. It's necessary to enable the optional clock DSS_FCLK before we enable the module using the MODULEMODE bits in the clock domain's CM_DSS_DSS_CLKCTRL register. This sequence was not followed correctly for the 'dss_hdmi' hwmod and it led to DSS clock domain not getting out of idle when pm_runtime_get_sync() was called for hdmi's platform device. Since the clock domain failed to change it's state to active, the hwmod code disables any clocks it had enabled before for this hwmod. This led to the clock 'dss_48mhz_clk' gettind disabled. When hdmi's runtime_resume() op is called, the call to dss_runtime_get() correctly enables the DSS clock domain this time. However, the clock 'dss_48mhz_clk' is needed for HDMI's PHY to function correctly. Since it was disabled previously, the driver fails when it tries to enable HDMI's PHY. Fix this for now by ensuring that dss_runtime_get() is called before we call pm_runtime_get_sync() for hdmi's platform device. A correct fix for later would be to modify the DSS related hwmod's mainclks, and also some changes in how opt clocks are handled in the DSS driver. This fixes the issue of HDMI not working when it's the default display. The issue is not seen if any other display is already enabled as the first display would have correctly enabled the DSS clockdomain. I think this looks fine, it's shouldn't have any side effects and is easy to remove later. Benoit, do you think we'll get the MODULEMODE mess cleaned up in the hwmod/clk framework at some point, and the drivers could do without these kinds of hacks? =) Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] OMAPDSS: add Innolux AT080TN52 display support
On Wed, 2012-02-08 at 11:11 +0100, yegorsli...@googlemail.com wrote: From: Yegor Yefremov yegorsli...@googlemail.com This patch adds support for Innolux AT080TN52 800x600 panel. Tested with AM3517 based board. Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com Looks fine to me, I'll apply. Thanks! Tomi signature.asc Description: This is a digitally signed message part
OMAP DSS warning in apply.c
kautobuildv2 discovered this in its omap4430sdp oldconfig build: drivers/video/omap2/dss/apply.c:350: warning: 'wait_pending_extra_info_updates' defined but not used This looks like a valid warning, because wait_pending_extra_info_updates() seems to be completely unreferenced. Should the function be removed? It looks like extra_updated_completion can also be removed as well, as that function is the only place it gets initialized and waited for. The function also looks weird - it calls extra_info_update_ongoing() first under a lock, and then outside the lock. It's not particularly nice API wise to have stuff sometimes called under a lock and sometimes not. -- To unsubscribe from this list: send the line unsubscribe 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] OMAPDSS: HDMI: Sysfs support to configure quantization
Hi, On Wed, 2012-02-08 at 11:54 +0530, mythr...@ti.com wrote: From: Mythri P K mythr...@ti.com Add sysfs support for the user space to configure limited range or full range quantization for HDMI. Signed-off-by: Mythri P K mythr...@ti.com I'd rather not add another non-standard sysfs entry. The color range is something that desktops have to handle also, so there's probably ways to handle it in DRM. DisplayPort also has the same range setting, so it's not specific to HDMI. So I propose to add a kernel API for this in the omap_dss_driver, so that the users of omapdss may handle setting the range as they see best. Btw, the displayport spec speaks of VESA and CEA ranges. Does HDMI spec only speak about limited/full range? I also only now realized that we have full/limited range setting in video overlay's ATTRIBUTEs also. And it seems that we currently set it always to 0, i.e. limited range. I wonder if this causes color degradation in case the HDMI/DP output also sets limited range, and thus the color range gets scaled down twice... Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v4 1/3] OMAPDSS: HDMI: Move Avi-infoframe struct to hdmi_ip_data
On Wed, 2012-02-08 at 11:54 +0530, mythr...@ti.com wrote: 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. This looks fine and separate from the full/limited range stuff, so I'll apply this patch already. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] OMAP: DSS2: TPO-TD03MTEA1: update default gamma
Hi, On Tue, 2012-02-07 at 02:13 +0200, Grazvydas Ignotas wrote: Over time better gamma has been determined and tuned with some equipment so update the defaults. From subjective point of view dark shades should be better visible. Is there even need for default gamma? I'd guess the panel has a default gamma in its firmware, so it should work fine without setting it. And there's sysfs interface to set the gamma from userspace. And, as you said, it's subjective, i.e. there's no right value for it, so I'm a bit inclined to say that the driver shouldn't even set a default gamma, and just leave it to userspace. Tomi signature.asc Description: This is a digitally signed message part
Re: OMAP DSS warning in apply.c
+ Tomi On 2/14/2012 1:06 PM, Russell King - ARM Linux wrote: kautobuildv2 discovered this in its omap4430sdp oldconfig build: drivers/video/omap2/dss/apply.c:350: warning: 'wait_pending_extra_info_updates' defined but not used This looks like a valid warning, because wait_pending_extra_info_updates() seems to be completely unreferenced. Should the function be removed? It looks like extra_updated_completion can also be removed as well, as that function is the only place it gets initialized and waited for. The function also looks weird - it calls extra_info_update_ongoing() first under a lock, and then outside the lock. It's not particularly nice API wise to have stuff sometimes called under a lock and sometimes not. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 4/5] twl4030: add support for external voltage get/set
On Tue, 2012-01-10 at 19:10 +, Mark Brown wrote: On Tue, Jan 10, 2012 at 07:19:18AM -0800, Kevin Hilman wrote: Yes, some of the control still goes via the normal path (although I forget which, maybe Benoit can remind us), so I think it's best to add the HW control part to each regulator that might uses it. Ideally this could be facilitated by adding the extentions to the regulator core so the amount of code needed for each regulator driver would be minimal. I think the original version of the patch was something along those lines but it was just a general facility which ignored the regulator driver entirely which didn't feel well integrated. The discussion suggested that this wasn't something that'd work with other regulators so a per-driver solution seemed OK. Coming back to this patch now as I have time to look at it, what is the general opinion, is it acceptable to patch the regulator core to add support for the external controller or should I just resend the latest version with changes Mark suggested? This will probably mean that once we add new regulator drivers (e.g. pmics) we may need to duplicate the external controller support here. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP DSS warning in apply.c
On Tue, 2012-02-14 at 12:06 +, Russell King - ARM Linux wrote: kautobuildv2 discovered this in its omap4430sdp oldconfig build: drivers/video/omap2/dss/apply.c:350: warning: 'wait_pending_extra_info_updates' defined but not used This looks like a valid warning, because wait_pending_extra_info_updates() seems to be completely unreferenced. Should the function be removed? It looks like extra_updated_completion can also be removed as well, as that function is the only place it gets initialized and waited for. The function will be used when the fifo merge series goes in in the next merge window. I added the extra_info code before fifo merge, as it's will be used by the fifo merge code and it kinda belonged with the other apply stuff. The fifo merge code was also supposed to go in in the previous merge window with the rest of the rewrites, but due to some complications it was delayed and missed the merge window. The function also looks weird - it calls extra_info_update_ongoing() first under a lock, and then outside the lock. It's not particularly nice API wise to have stuff sometimes called under a lock and sometimes not. The second call is actually extra, it was just added for verification purposes during development to ensure that the wait logic works correctly. I'll remove it. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
Hi Tomi, On 2/14/2012 12:57 PM, Tomi Valkeinen wrote: Hi, On Fri, 2012-02-10 at 11:45 +0530, Archit Taneja wrote: For DSS clock domain to transition from idle to active state. It's necessary to enable the optional clock DSS_FCLK before we enable the module using the MODULEMODE bits in the clock domain's CM_DSS_DSS_CLKCTRL register. This sequence was not followed correctly for the 'dss_hdmi' hwmod and it led to DSS clock domain not getting out of idle when pm_runtime_get_sync() was called for hdmi's platform device. Since the clock domain failed to change it's state to active, the hwmod code disables any clocks it had enabled before for this hwmod. This led to the clock 'dss_48mhz_clk' gettind disabled. When hdmi's runtime_resume() op is called, the call to dss_runtime_get() correctly enables the DSS clock domain this time. However, the clock 'dss_48mhz_clk' is needed for HDMI's PHY to function correctly. Since it was disabled previously, the driver fails when it tries to enable HDMI's PHY. Fix this for now by ensuring that dss_runtime_get() is called before we call pm_runtime_get_sync() for hdmi's platform device. A correct fix for later would be to modify the DSS related hwmod's mainclks, and also some changes in how opt clocks are handled in the DSS driver. This fixes the issue of HDMI not working when it's the default display. The issue is not seen if any other display is already enabled as the first display would have correctly enabled the DSS clockdomain. I think this looks fine, it's shouldn't have any side effects and is easy to remove later. Benoit, do you think we'll get the MODULEMODE mess cleaned up in the hwmod/clk framework at some point, and the drivers could do without these kinds of hacks? =) The best way to fix that for my point of view is to go to device tree or/and to consider the DSS as the parent of all the DSS modules. pm_runtime will then always ensure that the parent is enabled before any of the child are used. Implementing that with hwmod is not the right approach since is will require to add some more complex OMAP custom stuff in the hwmod fmwk whereas the LDM is already able to handle that. The whole point is that going to device tree, we will have to change the responsibility of hwmod to make it focus mainly on OMAP PRCM stuff and let the device handles the IRQ/DMA/REG/CLKS resources since it is the correct place to do that. 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: [PATCH] OMAP: DSS2: TPO-TD03MTEA1: update default gamma
On Tue, Feb 14, 2012 at 2:35 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, On Tue, 2012-02-07 at 02:13 +0200, Grazvydas Ignotas wrote: Over time better gamma has been determined and tuned with some equipment so update the defaults. From subjective point of view dark shades should be better visible. Is there even need for default gamma? I'd guess the panel has a default gamma in its firmware, so it should work fine without setting it. And there's sysfs interface to set the gamma from userspace. And, as you said, it's subjective, i.e. there's no right value for it, so I'm a bit inclined to say that the driver shouldn't even set a default gamma, and just leave it to userspace. Well for pandora, we encourage people to run custom Linux distros on the device, people reported running Debian, Arch and Slackware on the device, so we don't have control over everyone's userspace. To reduce the need for everyone to hack userspace of their distro of choice, it would be great to have nice display just from the kernel, out-of-the-box (this gamma has been tuned with some TV studio equipment so is not totally subjective). Still if you don't want it, we can keep carrying that in pandora's kernel tree too. -- Gražvydas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: DSS2: TPO-TD03MTEA1: update default gamma
On Tue, 2012-02-14 at 15:14 +0200, Grazvydas Ignotas wrote: On Tue, Feb 14, 2012 at 2:35 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, On Tue, 2012-02-07 at 02:13 +0200, Grazvydas Ignotas wrote: Over time better gamma has been determined and tuned with some equipment so update the defaults. From subjective point of view dark shades should be better visible. Is there even need for default gamma? I'd guess the panel has a default gamma in its firmware, so it should work fine without setting it. And there's sysfs interface to set the gamma from userspace. And, as you said, it's subjective, i.e. there's no right value for it, so I'm a bit inclined to say that the driver shouldn't even set a default gamma, and just leave it to userspace. Well for pandora, we encourage people to run custom Linux distros on the device, people reported running Debian, Arch and Slackware on the device, so we don't have control over everyone's userspace. To reduce the need for everyone to hack userspace of their distro of choice, it would be great to have nice display just from the kernel, out-of-the-box (this gamma has been tuned with some TV studio equipment so is not totally subjective). Still if you don't want it, we can keep carrying that in pandora's kernel tree too. Ok, fair enough. It's not a problem, just a few lines of code. But I don't want to get patches every now and that adjust the default gamma to whatever is subjectively best at that point of time =). Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
Hi,
On Tuesday 14 February 2012 06:45 PM, Tomi Valkeinen wrote:
On Tue, 2012-02-14 at 13:58 +0100, Cousson, Benoit wrote:
Hi Tomi,
Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
hwmod/clk framework at some point, and the drivers could do without
these kinds of hacks? =)
The best way to fix that for my point of view is to go to device tree
or/and to consider the DSS as the parent of all the DSS modules.
pm_runtime will then always ensure that the parent is enabled before any
of the child are used.
Ah, right. Sounds fine to me.
But is that a proper fix? Are we sure the MODULEMODE will then always
be handled correctly? Isn't the core problem still there, it just
doesn't happen with the setup anymore?
I mean, if we have these special requirements regarding MODULEMODE, and
the code doesn't really know about it, would it get broken easily with
restructuring/changes?
And no, I don't have any clear idea why/how it would break, but I have
just gotten the impression that the MODULEMODE is not handled quite
properly (and so we have these current problems), and having dss_core as
the parent of other dss modules doesn't really fix that in any way.
I agree with that.
In the current approach, we have multiple platform devices for DSS, and
all of them belong to the same clock domain, and the clock domain has
just one MODULEMODE bit field.
When shutting off a platform device(by calling pm_runtime_put()), hwmod
enables/disables MODULEMODE without taking into mind that other active
platform devices may still need it. So, for example, if we have 2
platform devices, say dss and dispc, and we have code like:
dispc_foo()
{
pm_runtime_get(dispc_pdev);
...
...
pm_runtime_put(dispc_pdev);
}
dss_foo()
{
pm_runtime_get(dss_pdev);
...
...
dispc_foo(); /* MODULEMODE off after this */
...
...
pm_runtime_put(dss_pdev);
}
This will lead to the situation of one platform device disabling
MODULEMODE even though other platform devices need it.
This may not be resolved in device tree either. We would need to have
some use count mechanism for these bits, or attach MODULEMODE only to
one platform device, and don't give others control to enable/disable it.
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
On Tue, 2012-02-14 at 19:00 +0530, Archit Taneja wrote:
Hi,
On Tuesday 14 February 2012 06:45 PM, Tomi Valkeinen wrote:
On Tue, 2012-02-14 at 13:58 +0100, Cousson, Benoit wrote:
Hi Tomi,
Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
hwmod/clk framework at some point, and the drivers could do without
these kinds of hacks? =)
The best way to fix that for my point of view is to go to device tree
or/and to consider the DSS as the parent of all the DSS modules.
pm_runtime will then always ensure that the parent is enabled before any
of the child are used.
Ah, right. Sounds fine to me.
But is that a proper fix? Are we sure the MODULEMODE will then always
be handled correctly? Isn't the core problem still there, it just
doesn't happen with the setup anymore?
I mean, if we have these special requirements regarding MODULEMODE, and
the code doesn't really know about it, would it get broken easily with
restructuring/changes?
And no, I don't have any clear idea why/how it would break, but I have
just gotten the impression that the MODULEMODE is not handled quite
properly (and so we have these current problems), and having dss_core as
the parent of other dss modules doesn't really fix that in any way.
I agree with that.
In the current approach, we have multiple platform devices for DSS, and
all of them belong to the same clock domain, and the clock domain has
just one MODULEMODE bit field.
When shutting off a platform device(by calling pm_runtime_put()), hwmod
enables/disables MODULEMODE without taking into mind that other active
platform devices may still need it. So, for example, if we have 2
platform devices, say dss and dispc, and we have code like:
dispc_foo()
{
pm_runtime_get(dispc_pdev);
...
...
pm_runtime_put(dispc_pdev);
}
dss_foo()
{
pm_runtime_get(dss_pdev);
...
...
dispc_foo(); /* MODULEMODE off after this */
...
...
pm_runtime_put(dss_pdev);
}
This will lead to the situation of one platform device disabling
MODULEMODE even though other platform devices need it.
This may not be resolved in device tree either. We would need to have
some use count mechanism for these bits, or attach MODULEMODE only to
one platform device, and don't give others control to enable/disable it.
Hmm, are you sure? Not that I checked the code, but isn't MODULEMODE
mapped to a dss clock (was it dss_clk)?. And so, the clock's refcount
should keep the MODULEMODE enabled/disabled?
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
On Tuesday 14 February 2012 07:03 PM, Tomi Valkeinen wrote:
On Tue, 2012-02-14 at 19:00 +0530, Archit Taneja wrote:
Hi,
On Tuesday 14 February 2012 06:45 PM, Tomi Valkeinen wrote:
On Tue, 2012-02-14 at 13:58 +0100, Cousson, Benoit wrote:
Hi Tomi,
Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
hwmod/clk framework at some point, and the drivers could do without
these kinds of hacks? =)
The best way to fix that for my point of view is to go to device tree
or/and to consider the DSS as the parent of all the DSS modules.
pm_runtime will then always ensure that the parent is enabled before any
of the child are used.
Ah, right. Sounds fine to me.
But is that a proper fix? Are we sure the MODULEMODE will then always
be handled correctly? Isn't the core problem still there, it just
doesn't happen with the setup anymore?
I mean, if we have these special requirements regarding MODULEMODE, and
the code doesn't really know about it, would it get broken easily with
restructuring/changes?
And no, I don't have any clear idea why/how it would break, but I have
just gotten the impression that the MODULEMODE is not handled quite
properly (and so we have these current problems), and having dss_core as
the parent of other dss modules doesn't really fix that in any way.
I agree with that.
In the current approach, we have multiple platform devices for DSS, and
all of them belong to the same clock domain, and the clock domain has
just one MODULEMODE bit field.
When shutting off a platform device(by calling pm_runtime_put()), hwmod
enables/disables MODULEMODE without taking into mind that other active
platform devices may still need it. So, for example, if we have 2
platform devices, say dss and dispc, and we have code like:
dispc_foo()
{
pm_runtime_get(dispc_pdev);
...
...
pm_runtime_put(dispc_pdev);
}
dss_foo()
{
pm_runtime_get(dss_pdev);
...
...
dispc_foo(); /* MODULEMODE off after this */
...
...
pm_runtime_put(dss_pdev);
}
This will lead to the situation of one platform device disabling
MODULEMODE even though other platform devices need it.
This may not be resolved in device tree either. We would need to have
some use count mechanism for these bits, or attach MODULEMODE only to
one platform device, and don't give others control to enable/disable it.
Hmm, are you sure? Not that I checked the code, but isn't MODULEMODE
mapped to a dss clock (was it dss_clk)?. And so, the clock's refcount
should keep the MODULEMODE enabled/disabled?
Yes, that's how we are currently dealing with it and making things work.
We are forced to represent MODULEMODE as a clock. I forgot to mention
that in the last mail :)
However, other modules don't do this. modulemode control is taken care
by hwmod by itself. We just have to fill the hwmod field
'.prcm.omap4.modulemode' and get done with it. If we try this approach,
we get into the trouble I mentioned before.
We represent MODULEMODE as dss_fck, and make this the l3 slave clock for
all DSS hwmods. This way, we ensure that it gets enabled, and we get a
usecount associated to it. We shouldn't stick to this approach because:
- It isn't exactly correct. MODULEMODE isn't a clock, and others don't
do it.
- DSS requires a particular sequence of disabling clocks to go into
lower power states, and with the current approach, this doesn't happen.
So, DSS doesn't idle, and that's the whole purpose of this :)
Archit
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP34xx
On Tue, 14 Feb 2012, Felipe Balbi wrote: Hi, On Thu, Feb 09, 2012 at 11:34:42AM -0800, Rex Feany wrote: I also get these warnings when compiling: CC arch/arm/mach-omap2/usb-host.o arch/arm/mach-omap2/usb-host.c: In function 'usbhs_init': arch/arm/mach-omap2/usb-host.c:528: warning: assignment from incompatible pointer type yeah, I'll send a patch for that. CC drivers/usb/host/ehci-hcd.o drivers/usb/host/ehci-hub.c:1079: warning: 'ehci_relinquish_port' defined but not used drivers/usb/host/ehci-hub.c:1088: warning: 'ehci_port_handed_over' defined but not used This can't really be fixed without some extra trickery. The fact is that OMAP can't handle port handoff (go figure) and if we use those functions, we might end up in a situation where USB doesn't work just because you connected a full speed device. By not using those functions, we guarantee that the full speed device won't get enumerated but USB will still be functional after you disconnect such device. We could add a bunch of __maybe_unused annotation to all those ehci_* functions. What do you say Alan ? Yes, that makes sense for now. In the future we'll probably rearrange things so that the annotations aren't needed, but at the moment this seems like the best solution. An alternative would be to add a quirks flag for controllers that don't support port handoff. But that would just create more code for all architectures and the end result wouldn't be any better. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: host: ehci: allow ehci_* symbols to be unused
On Tue, 14 Feb 2012, Felipe Balbi wrote: not all platforms will use all of those ehci_* symbols on their hc_driver structure. Sometimes we might need to provide a modified version of a certain method or not provide it at all, as is the case with OMAPs which don't support port handoff feature. Whenever we compile a kernel for an OMAP board with EHCI enabled, we get compile warnings: drivers/usb/host/ehci-hub.c:1079: warning: 'ehci_relinquish_port' \ defined but not used drivers/usb/host/ehci-hub.c:1088: warning: 'ehci_port_handed_over' \ defined but not used In order to cleanup those warnings, we're adding __maybe_unused annotation to those functions. We're also trying to cope with other platforms which might have similar issues with different methods by adding the same annotation to all ehci_* functions. Signed-off-by: Felipe Balbi ba...@ti.com --- Alan, what do you think about this patch ? It fixes our warnings and tries to cope with other possible such cases. Some of this makes sense: ehci_port_change, ehci_relinquish_port, and ehci_port_handed_over are fine. The others are questionable. What reason could there be for not implementing ehci_bus_suspend and ehci_bus_resume? Neither of those should involve much platform-specific work, if any. ehci_hub_status_data, ehci_hub_descriptor, and ehci_hub_control are even more puzzling. These are things that _have_ to be implemented for the driver to work at all. Platform code shouldn't replace them; it most it should call them as subroutines and override the results when necessary. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: OMAP4: Cleanup in cminst code
Similar to PRM code cleanup done recently to reuse prminst api's for AM33xx device, so in order to reuse the existing OMAP4 cminst code for AM33xx this patch adds, - Boot time __init function, to initialize _cm_bases based on cpu_is_xxx - Instead of maintaining phy addr for CM partition in _cm_bases[] table and then changing it to virt addr, directly maintain respective virt addr. And also hook-up support for AM33xx device to existing cminst code. Patch series is boot tested on AM335x EVM and AM37xEVM. NOTE: This patch series is dependent on earlier submitted PRM cleanup patch-series - http://www.spinics.net/lists/linux-omap/msg62351.html Vaibhav Hiremath (2): ARM: OMAP4: cminst: Add boot time __init function for cminst ARM: OMAP: am33xx: Hook-up am33xx support to existing cm code arch/arm/mach-omap2/cminst44xx.c | 38 +- arch/arm/mach-omap2/cminst44xx.h |1 + arch/arm/mach-omap2/io.c |3 +++ arch/arm/mach-omap2/omap_hwmod.c | 23 +++ 4 files changed, 48 insertions(+), 17 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 2/2] ARM: OMAP: am33xx: Hook-up am33xx support to existing cm code
Reuse existing omap4 cminst code for am33xx device,
add separate cm base table for am33xx device and initialize
it during __init for future use.
Also, since cpu_is_omap34xx() check is true for am33xx family of
devices, we must change the order of cpu_is_ check, so first
check for cpu_is_am33xx() to follow right execution path.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
CC: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/cminst44xx.c |9 +
arch/arm/mach-omap2/io.c |1 +
arch/arm/mach-omap2/omap_hwmod.c | 23 +++
3 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/cminst44xx.c b/arch/arm/mach-omap2/cminst44xx.c
index f709708..402d35a 100644
--- a/arch/arm/mach-omap2/cminst44xx.c
+++ b/arch/arm/mach-omap2/cminst44xx.c
@@ -31,6 +31,7 @@
#include cm-regbits-44xx.h
#include prcm44xx.h
#include prm44xx.h
+#include prm33xx.h
#include prcm_mpu44xx.h
/*
@@ -61,6 +62,11 @@ static u32 *omap44xx_cm_bases[] = {
[OMAP4430_PRCM_MPU_PARTITION] =
OMAP2_L4_IO_ADDRESS(OMAP4430_PRCM_MPU_BASE),
};
+static u32 *am33xx_cm_bases[] = {
+ [OMAP4430_INVALID_PRCM_PARTITION] = 0,
+ [AM33XX_PRM_PARTITION] =
AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRM_BASE),
+};
+
/* Private functions */
/**
@@ -358,5 +364,8 @@ void __init omap44xx_cminst_init(void)
if (cpu_is_omap44xx()) {
_cm_bases = omap44xx_cm_bases;
max_cm_partitions = ARRAY_SIZE(omap44xx_cm_bases);
+ } else if (cpu_is_am33xx()) {
+ _cm_bases =am33xx_cm_bases;
+ max_cm_partitions = ARRAY_SIZE(am33xx_cm_bases);
}
}
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index ebcc242..b318b44 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -479,6 +479,7 @@ void __init am33xx_init_early(void)
am33xx_voltagedomains_init();
omap44xx_prminst_init();
am33xx_powerdomains_init();
+ omap44xx_cminst_init();
omap3xxx_clk_init();
}
#endif
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 612701e..e4ae811 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -737,7 +737,7 @@ static void _disable_optional_clocks(struct omap_hwmod *oh)
static void _enable_module(struct omap_hwmod *oh)
{
/* The module mode does not exist prior OMAP4 */
- if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ if (!cpu_is_omap44xx() !cpu_is_am33xx())
return;
if (!oh-clkdm || !oh-prcm.omap4.modulemode)
@@ -764,7 +764,7 @@ static void _enable_module(struct omap_hwmod *oh)
*/
static int _omap4_wait_target_disable(struct omap_hwmod *oh)
{
- if (!cpu_is_omap44xx())
+ if (!cpu_is_omap44xx() !cpu_is_am33xx())
return 0;
if (!oh)
@@ -794,7 +794,7 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
int v;
/* The module mode does not exist prior OMAP4 */
- if (!cpu_is_omap44xx())
+ if (!cpu_is_omap44xx() !cpu_is_am33xx())
return -EINVAL;
if (!oh-clkdm || !oh-prcm.omap4.modulemode)
@@ -1219,11 +1219,13 @@ static int _wait_target_ready(struct omap_hwmod *oh)
/* XXX check clock enable states */
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
- ret = omap2_cm_wait_module_ready(oh-prcm.omap2.module_offs,
-oh-prcm.omap2.idlest_reg_id,
-
oh-prcm.omap2.idlest_idle_bit);
- } else if (cpu_is_omap44xx()) {
+ /*
+* In order to use omap4 cminst code for am33xx family of devices,
+* first check cpu_is_am33xx here.
+*
+* Note: cpu_is_omap34xx is true for am33xx device as well.
+*/
+ if (cpu_is_omap44xx() || cpu_is_am33xx()) {
if (!oh-clkdm)
return -EINVAL;
@@ -1231,6 +1233,11 @@ static int _wait_target_ready(struct omap_hwmod *oh)
oh-clkdm-cm_inst,
oh-clkdm-clkdm_offs,
oh-prcm.omap4.clkctrl_offs);
+ } else if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ ret = omap2_cm_wait_module_ready(
+ oh-prcm.omap2.module_offs,
+ oh-prcm.omap2.idlest_reg_id,
+ oh-prcm.omap2.idlest_idle_bit);
} else {
BUG();
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
[PATCH 1/2] ARM: OMAP4: cminst: Add boot time __init function for cminst
AM33xx CM module is closer to OMAP4 CM module, and
in order to reuse cminst api's we have to address
some of the differences like, base addresses and partitions.
Unlike OMAP4 CM, AM33xx doesn't have any partitions and
maintains only single partition.
So, in order to reuse the existing OMAP4 cminst code
for AM33xx this patch adds,
- Boot time __init function, to initialize _cm_bases
based on cpu_is_xxx
- Instead of maintaining phy addr for CM partition
in _cm_bases[] table and then changing it to virt addr,
directly maintain respective virt addr.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
CC: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/cminst44xx.c | 29 -
arch/arm/mach-omap2/cminst44xx.h |1 +
arch/arm/mach-omap2/io.c |2 ++
3 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/cminst44xx.c b/arch/arm/mach-omap2/cminst44xx.c
index 6204dea..f709708 100644
--- a/arch/arm/mach-omap2/cminst44xx.c
+++ b/arch/arm/mach-omap2/cminst44xx.c
@@ -49,13 +49,16 @@
#define CLKCTRL_IDLEST_INTERFACE_IDLE 0x2
#define CLKCTRL_IDLEST_DISABLED0x3
-static u32 _cm_bases[OMAP4_MAX_PRCM_PARTITIONS] = {
+static u32 **_cm_bases;
+static u32 max_cm_partitions;
+
+static u32 *omap44xx_cm_bases[] = {
[OMAP4430_INVALID_PRCM_PARTITION] = 0,
- [OMAP4430_PRM_PARTITION]= OMAP4430_PRM_BASE,
- [OMAP4430_CM1_PARTITION]= OMAP4430_CM1_BASE,
- [OMAP4430_CM2_PARTITION]= OMAP4430_CM2_BASE,
+ [OMAP4430_PRM_PARTITION]=
OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
+ [OMAP4430_CM1_PARTITION]=
OMAP2_L4_IO_ADDRESS(OMAP4430_CM1_BASE),
+ [OMAP4430_CM2_PARTITION]=
OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE),
[OMAP4430_SCRM_PARTITION] = 0,
- [OMAP4430_PRCM_MPU_PARTITION] = OMAP4430_PRCM_MPU_BASE,
+ [OMAP4430_PRCM_MPU_PARTITION] =
OMAP2_L4_IO_ADDRESS(OMAP4430_PRCM_MPU_BASE),
};
/* Private functions */
@@ -103,19 +106,19 @@ static bool _is_module_ready(u8 part, u16 inst, s16
cdoffs, u16 clkctrl_offs)
/* Read a register in a CM instance */
u32 omap4_cminst_read_inst_reg(u8 part, s16 inst, u16 idx)
{
- BUG_ON(part = OMAP4_MAX_PRCM_PARTITIONS ||
+ BUG_ON(part = max_cm_partitions ||
part == OMAP4430_INVALID_PRCM_PARTITION ||
!_cm_bases[part]);
- return __raw_readl(OMAP2_L4_IO_ADDRESS(_cm_bases[part] + inst + idx));
+ return __raw_readl(_cm_bases[part] + ((inst + idx)/sizeof(u32)));
}
/* Write into a register in a CM instance */
void omap4_cminst_write_inst_reg(u32 val, u8 part, s16 inst, u16 idx)
{
- BUG_ON(part = OMAP4_MAX_PRCM_PARTITIONS ||
+ BUG_ON(part = max_cm_partitions ||
part == OMAP4430_INVALID_PRCM_PARTITION ||
!_cm_bases[part]);
- __raw_writel(val, OMAP2_L4_IO_ADDRESS(_cm_bases[part] + inst + idx));
+ __raw_writel(val, _cm_bases[part] + ((inst + idx)/sizeof(u32)));
}
/* Read-modify-write a register in CM1. Caller must lock */
@@ -349,3 +352,11 @@ void omap4_cminst_module_disable(u8 part, u16 inst, s16
cdoffs,
v = ~OMAP4430_MODULEMODE_MASK;
omap4_cminst_write_inst_reg(v, part, inst, clkctrl_offs);
}
+
+void __init omap44xx_cminst_init(void)
+{
+ if (cpu_is_omap44xx()) {
+ _cm_bases = omap44xx_cm_bases;
+ max_cm_partitions = ARRAY_SIZE(omap44xx_cm_bases);
+ }
+}
diff --git a/arch/arm/mach-omap2/cminst44xx.h b/arch/arm/mach-omap2/cminst44xx.h
index a018a73..3d1bde1 100644
--- a/arch/arm/mach-omap2/cminst44xx.h
+++ b/arch/arm/mach-omap2/cminst44xx.h
@@ -63,4 +63,5 @@ extern u32 omap4_cminst_clear_inst_reg_bits(u32 bits, u8
part, s16 inst,
extern u32 omap4_cminst_read_inst_reg_bits(u8 part, u16 inst, s16 idx,
u32 mask);
+extern void __init omap44xx_cminst_init(void);
#endif
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 50cf914..ebcc242 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -40,6 +40,7 @@
#include voltage.h
#include powerdomain.h
#include prminst44xx.h
+#include cminst44xx.h
#include clockdomain.h
#include plat/omap_hwmod.h
@@ -492,6 +493,7 @@ void __init omap4430_init_early(void)
omap44xx_voltagedomains_init();
omap44xx_prminst_init();
omap44xx_powerdomains_init();
+ omap44xx_cminst_init();
omap44xx_clockdomains_init();
omap44xx_hwmod_init();
omap_hwmod_init_postsetup();
--
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
Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
On 2/14/2012 2:30 PM, Archit Taneja wrote:
Hi,
On Tuesday 14 February 2012 06:45 PM, Tomi Valkeinen wrote:
On Tue, 2012-02-14 at 13:58 +0100, Cousson, Benoit wrote:
Hi Tomi,
Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
hwmod/clk framework at some point, and the drivers could do without
these kinds of hacks? =)
The best way to fix that for my point of view is to go to device tree
or/and to consider the DSS as the parent of all the DSS modules.
pm_runtime will then always ensure that the parent is enabled before any
of the child are used.
Ah, right. Sounds fine to me.
But is that a proper fix? Are we sure the MODULEMODE will then always
be handled correctly? Isn't the core problem still there, it just
doesn't happen with the setup anymore?
I mean, if we have these special requirements regarding MODULEMODE, and
the code doesn't really know about it, would it get broken easily with
restructuring/changes?
And no, I don't have any clear idea why/how it would break, but I have
just gotten the impression that the MODULEMODE is not handled quite
properly (and so we have these current problems), and having dss_core as
the parent of other dss modules doesn't really fix that in any way.
I agree with that.
In the current approach, we have multiple platform devices for DSS, and
all of them belong to the same clock domain, and the clock domain has
just one MODULEMODE bit field.
When shutting off a platform device(by calling pm_runtime_put()), hwmod
enables/disables MODULEMODE without taking into mind that other active
platform devices may still need it. So, for example, if we have 2
platform devices, say dss and dispc, and we have code like:
dispc_foo()
{
pm_runtime_get(dispc_pdev);
...
...
pm_runtime_put(dispc_pdev);
}
dss_foo()
{
pm_runtime_get(dss_pdev);
...
...
dispc_foo(); /* MODULEMODE off after this */
...
...
pm_runtime_put(dss_pdev);
}
This will lead to the situation of one platform device disabling
MODULEMODE even though other platform devices need it.
This may not be resolved in device tree either. We would need to have
some use count mechanism for these bits, or attach MODULEMODE only to
one platform device, and don't give others control to enable/disable it.
And this is exactly what the pm_runtime will provide. The fmwk already
handles reference counting.
Moreover the dev-parent will increment the power.child_count and thus
ensure that the parent is always enabled if at least one child is active.
By initializing the dev-parent of each DSS modules to the dss_core, it
will ensure that the power dependency is managed properly.
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: [PATCH] usb: host: ehci: allow ehci_* symbols to be unused
On Tue, Feb 14, 2012 at 10:06:47AM -0500, Alan Stern wrote: On Tue, 14 Feb 2012, Felipe Balbi wrote: not all platforms will use all of those ehci_* symbols on their hc_driver structure. Sometimes we might need to provide a modified version of a certain method or not provide it at all, as is the case with OMAPs which don't support port handoff feature. Whenever we compile a kernel for an OMAP board with EHCI enabled, we get compile warnings: drivers/usb/host/ehci-hub.c:1079: warning: 'ehci_relinquish_port' \ defined but not used drivers/usb/host/ehci-hub.c:1088: warning: 'ehci_port_handed_over' \ defined but not used In order to cleanup those warnings, we're adding __maybe_unused annotation to those functions. We're also trying to cope with other platforms which might have similar issues with different methods by adding the same annotation to all ehci_* functions. Signed-off-by: Felipe Balbi ba...@ti.com --- Alan, what do you think about this patch ? It fixes our warnings and tries to cope with other possible such cases. Some of this makes sense: ehci_port_change, ehci_relinquish_port, and ehci_port_handed_over are fine. The others are questionable. What reason could there be for not implementing ehci_bus_suspend and ehci_bus_resume? Neither of those should involve much platform-specific work, if any. you never know what kind of silicon erratas might come up, right ? :-) ehci_hub_status_data, ehci_hub_descriptor, and ehci_hub_control are even more puzzling. These are things that _have_ to be implemented for the driver to work at all. Platform code shouldn't replace them; it most it should call them as subroutines and override the results when necessary. There's no doubt it needs to be implemented, but the fact is that in some situations we might need to implement it differently because of whatever reason. See for example that I have a pending workaround to implement for OMAP3 EHCI where we need to reparent a clock before handling SetFeature(port_suspend) so I would need to reimplement echi_hub_control() in order not to expose that detail to core ehci. Because clock reparenting is something so ARCH-specific it makes no sense to come up with a quirk flag for that. Granted, the way I had envisioned, I would reimplement the particular request that needs special handling and call the generic ehci_hub_control() otherwise, but still. Like I said, you never know what kind of erratas could pop up. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
On 2/14/2012 2:45 PM, Archit Taneja wrote:
On Tuesday 14 February 2012 07:03 PM, Tomi Valkeinen wrote:
On Tue, 2012-02-14 at 19:00 +0530, Archit Taneja wrote:
Hi,
On Tuesday 14 February 2012 06:45 PM, Tomi Valkeinen wrote:
On Tue, 2012-02-14 at 13:58 +0100, Cousson, Benoit wrote:
Hi Tomi,
Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
hwmod/clk framework at some point, and the drivers could do without
these kinds of hacks? =)
The best way to fix that for my point of view is to go to device tree
or/and to consider the DSS as the parent of all the DSS modules.
pm_runtime will then always ensure that the parent is enabled
before any
of the child are used.
Ah, right. Sounds fine to me.
But is that a proper fix? Are we sure the MODULEMODE will then always
be handled correctly? Isn't the core problem still there, it just
doesn't happen with the setup anymore?
I mean, if we have these special requirements regarding MODULEMODE, and
the code doesn't really know about it, would it get broken easily with
restructuring/changes?
And no, I don't have any clear idea why/how it would break, but I have
just gotten the impression that the MODULEMODE is not handled quite
properly (and so we have these current problems), and having
dss_core as
the parent of other dss modules doesn't really fix that in any way.
I agree with that.
In the current approach, we have multiple platform devices for DSS, and
all of them belong to the same clock domain, and the clock domain has
just one MODULEMODE bit field.
When shutting off a platform device(by calling pm_runtime_put()), hwmod
enables/disables MODULEMODE without taking into mind that other active
platform devices may still need it. So, for example, if we have 2
platform devices, say dss and dispc, and we have code like:
dispc_foo()
{
pm_runtime_get(dispc_pdev);
...
...
pm_runtime_put(dispc_pdev);
}
dss_foo()
{
pm_runtime_get(dss_pdev);
...
...
dispc_foo(); /* MODULEMODE off after this */
...
...
pm_runtime_put(dss_pdev);
}
This will lead to the situation of one platform device disabling
MODULEMODE even though other platform devices need it.
This may not be resolved in device tree either. We would need to have
some use count mechanism for these bits, or attach MODULEMODE only to
one platform device, and don't give others control to enable/disable it.
Hmm, are you sure? Not that I checked the code, but isn't MODULEMODE
mapped to a dss clock (was it dss_clk)?. And so, the clock's refcount
should keep the MODULEMODE enabled/disabled?
Yes, that's how we are currently dealing with it and making things work.
We are forced to represent MODULEMODE as a clock. I forgot to mention
that in the last mail :)
However, other modules don't do this. modulemode control is taken care
by hwmod by itself. We just have to fill the hwmod field
'.prcm.omap4.modulemode' and get done with it. If we try this approach,
we get into the trouble I mentioned before.
We represent MODULEMODE as dss_fck, and make this the l3 slave clock for
all DSS hwmods. This way, we ensure that it gets enabled, and we get a
usecount associated to it. We shouldn't stick to this approach because:
- It isn't exactly correct. MODULEMODE isn't a clock, and others don't
do it.
Yes, fully agree. This was done like that as a hack to avoid any
regression because at that time we were not sure if that dependency will
have to be handled by the hwmod fmwk or by the driver.
Now, I'm sure it should not be handled by the hwmod fmwk :-)
- DSS requires a particular sequence of disabling clocks to go into
lower power states, and with the current approach, this doesn't happen.
So, DSS doesn't idle, and that's the whole purpose of this :)
I'm just curious, what particular sequence is required?
Thanks,
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: [PATCH] staging: tidspbridge: enable watchdog by default
On Tue, Feb 14, 2012 at 3:06 AM, Ramirez Luna, Omar omar.rami...@ti.com wrote: On Feb 11, 2012 3:03 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sat, Feb 11, 2012 at 9:19 PM, Ramirez Luna, Omar omar.rami...@ti.com wrote: On Feb 10, 2012 12:44 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Feb 10, 2012 at 10:35 PM, Dan Carpenter dan.carpen...@oracle.com wrote: On Fri, Feb 10, 2012 at 09:42:32PM +0200, Felipe Contreras wrote: On Fri, Feb 10, 2012 at 8:00 PM, Dan Carpenter dan.carpen...@oracle.com wrote: On Fri, Feb 10, 2012 at 01:30:48AM +0200, Felipe Contreras wrote: It's not an oops, it's a warning, and again, it depends on the firmware being used. We don't have control over that, and we have no way to detect if this feature is there. It's up to the user. Perhaps just remove the warning message and handle the condition instead of printing a stack dump? The user should be triggering stack dumps. What on earth? The warning doesn't come from the driver. I'm not sure I understand. Are you saying that because it comes from the arch/ directory, it can't be fixed? I have good news for you my friend. :) It's all open source! \o/ The fact that you _can_ remove the warning doesn't mean you should. To me it sounds like a proper warning. Anyway, I saw in another email that Omar is working on a fix so probably we can just wait for his patch, yes? He only proposed a solution, I doubt he is working on. And to me, that sounded like a hack rather than a proper fix. I'm out on travel but will be able to look at it on Monday. Well, I think it is the right way, you look on the firmware if it has WDT you use it if it doesn't then you don't. Rather than guessing if you have the feature. It would be like reading a config option in the firmware. Yeah, but it's not really firmware, it's an operating system image. I can be running Linux there, and I might have implemented WDT. How is that code going to find that out? Tidspbridge loader doesn't support that use case, baseimage and let's say a dsp-linuximg won't have the same layout, hence it won't be able to parse and load the latter. When that case is applicable, we should first modify the loader code or prepare the baseimages to be common so we can get rid of specific loaders and just dump them into memory. I'd say the less workarounds, the better. WDT could be detected by prepending common symbols into the baseimages or just making the new images to treat all peripherals as resources, that is, the new baseimg should actually request the wdt3 as any other clock. I see, but if wdt3 is requested as another clock, the Linux ARM side would still need to know how to threat the WDT. 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
[PATCH 2/6] arm: omap3+: voltage/pwrdm/clkdm/clock add recursive usecount tracking
This patch fixes the usecount tracking for omap3+, previously the
usecount numbers were rather bogus and were not really useful for
any purpose. Now usecount numbers track the number of really active
clients on each domain. This patch also adds support for usecount
tracking on powerdomain level and autoidle flag for clocks that
are hardware controlled and should be skipped in usecount
calculations.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/clkt_iclk.c | 21 +++
arch/arm/mach-omap2/clockdomain.c | 34 +-
arch/arm/mach-omap2/clockdomain.h |2 +
arch/arm/mach-omap2/powerdomain.c | 10 +
arch/arm/mach-omap2/powerdomain.h |5
arch/arm/plat-omap/clock.c |6 +
arch/arm/plat-omap/include/plat/clock.h |2 +
7 files changed, 78 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_iclk.c b/arch/arm/mach-omap2/clkt_iclk.c
index 3d43fba..f8c2e77 100644
--- a/arch/arm/mach-omap2/clkt_iclk.c
+++ b/arch/arm/mach-omap2/clkt_iclk.c
@@ -21,6 +21,7 @@
#include clock2xxx.h
#include cm2xxx_3xxx.h
#include cm-regbits-24xx.h
+#include clockdomain.h
/* Private functions */
@@ -34,6 +35,16 @@ void omap2_clkt_iclk_allow_idle(struct clk *clk)
v = __raw_readl((__force void __iomem *)r);
v |= (1 clk-enable_bit);
__raw_writel(v, (__force void __iomem *)r);
+
+ /* Remove this clock from parent clockdomain usecounts */
+ if (clk-usecount clk-clkdm)
+ clkdm_usecount_dec(clk-clkdm);
+
+ /*
+* Mark as autoidle, so we continue to ignore this clock in
+* parent clkdm usecount calculations
+*/
+ clk-autoidle = true;
}
/* XXX */
@@ -46,6 +57,16 @@ void omap2_clkt_iclk_deny_idle(struct clk *clk)
v = __raw_readl((__force void __iomem *)r);
v = ~(1 clk-enable_bit);
__raw_writel(v, (__force void __iomem *)r);
+
+ /* Add clock back to parent clockdomain usecount */
+ if (clk-usecount clk-clkdm)
+ clkdm_usecount_inc(clk-clkdm);
+
+ /*
+* Disable autoidle flag so further clkdm usecounts take this
+* clock into account
+*/
+ clk-autoidle = false;
}
/* Public data */
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index ad07689..c0b6187 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -907,6 +907,28 @@ bool clkdm_in_hwsup(struct clockdomain *clkdm)
/* Clockdomain-to-clock/hwmod framework interface code */
+int clkdm_usecount_inc(struct clockdomain *clkdm)
+{
+ int usecount;
+
+ usecount = atomic_inc_return(clkdm-usecount);
+
+ if (usecount == 1)
+ pwrdm_clkdm_enable(clkdm-pwrdm.ptr);
+ return usecount;
+}
+
+int clkdm_usecount_dec(struct clockdomain *clkdm)
+{
+ int usecount;
+
+ usecount = atomic_dec_return(clkdm-usecount);
+
+ if (usecount == 0)
+ pwrdm_clkdm_disable(clkdm-pwrdm.ptr);
+ return usecount;
+}
+
static int _clkdm_clk_hwmod_enable(struct clockdomain *clkdm)
{
unsigned long flags;
@@ -919,7 +941,7 @@ static int _clkdm_clk_hwmod_enable(struct clockdomain
*clkdm)
* should be called for every clock instance or hwmod that is
* enabled, so the clkdm can be force woken up.
*/
- if ((atomic_inc_return(clkdm-usecount) 1) autodeps)
+ if ((clkdm_usecount_inc(clkdm) 1) autodeps)
return 0;
spin_lock_irqsave(clkdm-lock, flags);
@@ -945,7 +967,7 @@ static int _clkdm_clk_hwmod_disable(struct clockdomain
*clkdm)
return -ERANGE;
}
- if (atomic_dec_return(clkdm-usecount) 0)
+ if (clkdm_usecount_dec(clkdm) 0)
return 0;
spin_lock_irqsave(clkdm-lock, flags);
@@ -982,6 +1004,10 @@ int clkdm_clk_enable(struct clockdomain *clkdm, struct
clk *clk)
if (!clk)
return -EINVAL;
+ /* If autoidle clock, do not update clkdm usecounts */
+ if (clk-autoidle)
+ return 0;
+
return _clkdm_clk_hwmod_enable(clkdm);
}
@@ -1008,6 +1034,10 @@ int clkdm_clk_disable(struct clockdomain *clkdm, struct
clk *clk)
if (!clk)
return -EINVAL;
+ /* If autoidle clock, do not update clkdm usecounts */
+ if (clk-autoidle)
+ return 0;
+
return _clkdm_clk_hwmod_disable(clkdm);
}
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index f7b5860..373399a 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -191,6 +191,8 @@ int clkdm_clk_enable(struct clockdomain *clkdm, struct clk
*clk);
int clkdm_clk_disable(struct clockdomain *clkdm, struct clk *clk);
int clkdm_hwmod_enable(struct
[PATCH 5/6] arm: omap3: set autoidle flags for a few clocks
dpll3, dpll4 and sdrc_ick are controlled automatically by hardware.
Thus, reflect this with the autoidle flags, the clocks will no longer
show as active in usecount dumps and will allow the voltdm-sleep /
wakeup calls to work properly.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index d75e5f6..f3ee983 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -432,6 +432,7 @@ static struct clk dpll3_ck = {
.round_rate = omap2_dpll_round_rate,
.clkdm_name = dpll3_clkdm,
.recalc = omap3_dpll_recalc,
+ .autoidle = true,
};
/*
@@ -615,6 +616,7 @@ static struct clk dpll4_ck = {
.set_rate = omap3_dpll4_set_rate,
.clkdm_name = dpll4_clkdm,
.recalc = omap3_dpll_recalc,
+ .autoidle = true,
};
/*
@@ -1744,6 +1746,7 @@ static struct clk sdrc_ick = {
.flags = ENABLE_ON_INIT,
.clkdm_name = core_l3_clkdm,
.recalc = followparent_recalc,
+ .autoidle = true,
};
static struct clk gpmc_fck = {
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] arm: omap: pm-debug: enhanced usecount debug support
Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to
their own file, 'usecount'. This file shows the usecounts for every
active domain and their children recursively. 'count' file now only
shows power state counts for powerdomains.
This patch also provices a way to do printk dumps from kernel code,
by calling the pm_dbg_dump_X functions. The plan is to call these
functions once an error condition is detected, e.g. failed suspend.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm-debug.c | 128 ++--
arch/arm/mach-omap2/pm.h |6 ++
2 files changed, 115 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 4411163..444588e 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -51,6 +51,7 @@ static int pm_dbg_init(void);
enum {
DEBUG_FILE_COUNTERS = 0,
DEBUG_FILE_TIMERS,
+ DEBUG_FILE_USECOUNT,
};
static const char pwrdm_state_names[][PWRDM_MAX_PWRSTS] = {
@@ -75,23 +76,6 @@ void pm_dbg_update_time(struct powerdomain *pwrdm, int prev)
pwrdm-timer = t;
}
-static int clkdm_dbg_show_counter(struct clockdomain *clkdm, void *user)
-{
- struct seq_file *s = (struct seq_file *)user;
-
- if (strcmp(clkdm-name, emu_clkdm) == 0 ||
- strcmp(clkdm-name, wkup_clkdm) == 0 ||
- strncmp(clkdm-name, dpll, 4) == 0)
- return 0;
-
- seq_printf(s, %s-%s (%d), clkdm-name,
- clkdm-pwrdm.ptr-name,
- atomic_read(clkdm-usecount));
- seq_printf(s, \n);
-
- return 0;
-}
-
static int pwrdm_dbg_show_counter(struct powerdomain *pwrdm, void *user)
{
struct seq_file *s = (struct seq_file *)user;
@@ -145,11 +129,112 @@ static int pwrdm_dbg_show_timer(struct powerdomain
*pwrdm, void *user)
return 0;
}
+static struct voltagedomain *parent_voltdm;
+static struct powerdomain *parent_pwrdm;
+static struct clockdomain *parent_clkdm;
+
+#define PM_DBG_PRINT(s, fmt, args...) \
+ { \
+ if (s) \
+ seq_printf(s, fmt, ## args);\
+ else\
+ pr_info(fmt, ## args); \
+ }
+
+static int _pm_dbg_dump_clk(struct clk *clk, void *user)
+{
+ struct seq_file *s = user;
+
+ if (clk-clkdm == parent_clkdm clk-usecount !clk-autoidle)
+ PM_DBG_PRINT(s, ck:%s: %d\n, clk-name, clk-usecount);
+
+ return 0;
+}
+
+static int _pm_dbg_dump_hwmod(struct omap_hwmod *oh, void *user)
+{
+ struct seq_file *s = user;
+
+ if (oh-clkdm != parent_clkdm)
+ return 0;
+
+ if (oh-_state != _HWMOD_STATE_ENABLED)
+ return 0;
+
+ PM_DBG_PRINT(s, oh:%s: enabled\n, oh-name);
+
+ return 0;
+}
+
+static int _pm_dbg_dump_clkdm(struct clockdomain *clkdm, void *user)
+{
+ struct seq_file *s = user;
+ u32 usecount;
+
+ if (clkdm-pwrdm.ptr == parent_pwrdm) {
+ usecount = atomic_read(clkdm-usecount);
+ if (usecount) {
+ PM_DBG_PRINT(s, cd:%s: %d\n, clkdm-name,
+ usecount);
+ parent_clkdm = clkdm;
+ omap_hwmod_for_each(_pm_dbg_dump_hwmod, s);
+ omap_clk_for_each(_pm_dbg_dump_clk, s);
+ }
+ }
+ return 0;
+}
+
+static int _pm_dbg_dump_pwrdm(struct powerdomain *pwrdm, void *user)
+{
+ struct seq_file *s = user;
+ u32 usecount;
+
+ if (pwrdm-voltdm.ptr == parent_voltdm) {
+ usecount = atomic_read(pwrdm-usecount);
+ if (usecount) {
+ PM_DBG_PRINT(s, pd:%s: %d\n, pwrdm-name, usecount);
+ parent_pwrdm = pwrdm;
+ clkdm_for_each(_pm_dbg_dump_clkdm, s);
+ }
+ }
+ return 0;
+}
+
+void pm_dbg_dump_pwrdm(struct powerdomain *pwrdm)
+{
+ pr_info(pd:%s: %d\n, pwrdm-name, atomic_read(pwrdm-usecount));
+ parent_pwrdm = pwrdm;
+ clkdm_for_each(_pm_dbg_dump_clkdm, NULL);
+}
+
+void pm_dbg_dump_voltdm(struct voltagedomain *voltdm)
+{
+ pr_info(vd:%s: %d\n, voltdm-name, atomic_read(voltdm-usecount));
+ parent_voltdm = voltdm;
+ pwrdm_for_each(_pm_dbg_dump_pwrdm, NULL);
+}
+
+static int _voltdm_dbg_show_counters(struct voltagedomain *voltdm, void *user)
+{
+ struct seq_file *s = user;
+
+ seq_printf(s, vd:%s: %d\n, voltdm-name,
+ atomic_read(voltdm-usecount));
+
+ parent_voltdm = voltdm;
+ pwrdm_for_each(_pm_dbg_dump_pwrdm, s);
+ return 0;
+}
+
+static int pm_dbg_show_usecount(struct
[PATCH 3/6] arm: omap3+: voltage: add support for voltagedomain usecounts
These are updated based on powerdomain usecounts. Also added support
for voltdm-sleep and voltdm-wakeup calls that will be invoked once
voltagedomain enters sleep or wakes up based on usecount numbers. These
will be used for controlling voltage scaling functionality.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/powerdomain.c |6 +++-
arch/arm/mach-omap2/voltage.c | 48 +
arch/arm/mach-omap2/voltage.h | 11
3 files changed, 63 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 78bf3c0..4ded0c8 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -987,12 +987,14 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm)
void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
{
- atomic_inc(pwrdm-usecount);
+ if (atomic_inc_return(pwrdm-usecount) == 1)
+ voltdm_pwrdm_enable(pwrdm-voltdm.ptr);
}
void pwrdm_clkdm_disable(struct powerdomain *pwrdm)
{
- atomic_dec(pwrdm-usecount);
+ if (!atomic_dec_return(pwrdm-usecount))
+ voltdm_pwrdm_disable(pwrdm-voltdm.ptr);
}
int pwrdm_pre_transition(void)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 8a36342..88f0e98 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -38,6 +38,7 @@
#include voltage.h
#include powerdomain.h
+#include smartreflex.h
#include vc.h
#include vp.h
@@ -325,6 +326,53 @@ int voltdm_add_pwrdm(struct voltagedomain *voltdm, struct
powerdomain *pwrdm)
}
/**
+ * voltdm_pwrdm_enable - increase usecount for a voltagedomain
+ * @voltdm: struct voltagedomain * to increase count for
+ *
+ * Increases usecount for a given voltagedomain. If the usecount reaches
+ * 1, the domain is awakened from idle and the function will call the
+ * voltagedomain-wakeup callback for this domain, and also enable the
+ * smartreflex for the domain.
+ */
+void voltdm_pwrdm_enable(struct voltagedomain *voltdm)
+{
+ if (atomic_inc_return(voltdm-usecount) == 1) {
+ if (voltdm-wakeup)
+ voltdm-wakeup(voltdm);
+ omap_sr_enable(voltdm);
+ }
+}
+
+/**
+ * voltdm_pwrdm_disable - decrease usecount for a voltagedomain
+ * @voltdm: struct voltagedomain * to decrease count for
+ *
+ * Decreases the usecount for a given voltagedomain. If the usecount
+ * reaches zero, the domain can idle and the function will call the
+ * voltagedomain-sleep callback, disable smartreflex for the domain,
+ * and calculate the overall target state for the voltagedomain.
+ */
+void voltdm_pwrdm_disable(struct voltagedomain *voltdm)
+{
+ int target_state = -EINVAL;
+ int state;
+ struct powerdomain *pwrdm;
+
+ if (!atomic_dec_return(voltdm-usecount)) {
+ omap_sr_disable(voltdm);
+ /* Determine target state for voltdm */
+ list_for_each_entry(pwrdm, voltdm-pwrdm_list, voltdm_node) {
+ state = pwrdm_read_next_pwrst(pwrdm);
+ if (state target_state)
+ target_state = state;
+ }
+ voltdm-target_state = target_state;
+ if (voltdm-sleep)
+ voltdm-sleep(voltdm);
+ }
+}
+
+/**
* voltdm_for_each_pwrdm - call function for each pwrdm in a voltdm
* @voltdm: struct voltagedomain * to iterate over
* @fn: callback function *
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 16a1b09..8829201 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -54,10 +54,14 @@ struct omap_vfsm_instance {
* @pwrdm_list: list_head linking all powerdomains in this voltagedomain
* @vc: pointer to VC channel associated with this voltagedomain
* @vp: pointer to VP associated with this voltagedomain
+ * @usecount: number of users for this voltagedomain
+ * @target_state: calculated target state for the children of this domain
* @read: read a VC/VP register
* @write: write a VC/VP register
* @read: read-modify-write a VC/VP register
* @sys_clk: system clock name/frequency, used for various timing calculations
+ * @sleep: function to call once the domain enters idle
+ * @wakeup: function to call once the domain wakes up from idle
* @scale: function used to scale the voltage of the voltagedomain
* @nominal_volt: current nominal voltage for this voltage domain
* @volt_data: voltage table having the distinct voltages supported
@@ -73,6 +77,9 @@ struct voltagedomain {
struct omap_vp_instance *vp;
struct omap_voltdm_pmic *pmic;
+ atomic_t usecount;
+ int target_state;
+
/* VC/VP register access functions: SoC specific */
u32 (*read) (u8 offset);
void (*write) (u32
[PATCH 1/6] arm: omap: clk: add support for omap_clk_for_each
This works similarly to e.g. pwrdm_for_each(). Needed by enhanced
usecounting debug functionality that will be added to pm-debug.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/clock.c | 30 ++
arch/arm/plat-omap/include/plat/clock.h |2 ++
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 567e4b5..e17ee5e2 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -356,6 +356,36 @@ int omap_clk_enable_autoidle_all(void)
return 0;
}
+/**
+ * omap_clk_for_each - call a function for each registered clock
+ * @fn: pointer to callback function
+ * @data: void * data to pass to callback function
+ *
+ * Call @fn for each registered clock, passing @data to each function.
+ * @fn must return 0 for success or any other value for failure. If
+ * @fn returns non-zero, the iteration across clocks will stop and
+ * the non-zero return value will be passed to the caller of
+ * omap_clk_for_each(). @fn is called with clockfw_lock held.
+ */
+int omap_clk_for_each(int (*fn)(struct clk *clk, void *user), void *user)
+{
+ struct clk *c;
+ unsigned long flags;
+ int ret = 0;
+
+ spin_lock_irqsave(clockfw_lock, flags);
+
+ list_for_each_entry(c, clocks, node) {
+ ret = fn(c, user);
+ if (ret)
+ break;
+ }
+
+ spin_unlock_irqrestore(clockfw_lock, flags);
+
+ return ret;
+}
+
int omap_clk_disable_autoidle_all(void)
{
struct clk *c;
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index 240a7b9..c84f2a4 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -300,6 +300,8 @@ extern void propagate_rate(struct clk *clk);
extern void recalculate_root_clocks(void);
extern unsigned long followparent_recalc(struct clk *clk);
extern void clk_enable_init_clocks(void);
+extern int omap_clk_for_each(int (*fn)(struct clk *clk, void *user),
+ void *user);
unsigned long omap_fixed_divisor_recalc(struct clk *clk);
#ifdef CONFIG_CPU_FREQ
extern void clk_init_cpufreq_table(struct cpufreq_frequency_table **table);
--
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 0/6] arm: omap: clk/clkdm/pwrdm/voltdm changes to usecounting
This set is split out from a larger set earlier circulated on linux-omap list. The main purpose of this set is to provide useful recursive usecounting support for clockdomains / powerdomains / voltagedomains which can be used for debugging purposes and also to control certain chip power features once a sleep condition is reached (voltdm usecount=0). This set provides only the baseline support for the usecounting, and also adds a pm-debug related patch that can be used to check out stuff (patch 6), and should later prove rather useful for debugging. Rest of the functionality will be posted in separate sets. This set has been tested on omap3 beagle board with suspend / resume / cpuidle. Also boot tested on omap4 panda (sleep is not functional yet on that platform.) Applies on mainline kernel. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] arm: omap3: add manual control for mpu_iva voltdm usecounting
mpu_iva voltdm usecount is now decreased during idle. This will
allow the voltagedomain to reflect actual usage, and will allow
proper usage of vc callbacks.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index fc69875..14defaf 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -74,6 +74,7 @@ void (*omap3_do_wfi_sram)(void);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
static struct powerdomain *cam_pwrdm;
+static struct voltagedomain *mpu_iva_voltdm;
static inline void omap3_per_save_context(void)
{
@@ -311,6 +312,8 @@ void omap_sram_idle(void)
return;
}
+ voltdm_pwrdm_disable(mpu_iva_voltdm);
+
/* NEON control */
if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
@@ -393,6 +396,8 @@ void omap_sram_idle(void)
}
omap3_intc_resume_idle();
+ voltdm_pwrdm_enable(mpu_iva_voltdm);
+
pwrdm_post_transition();
/* PER */
@@ -828,6 +833,9 @@ static int __init omap3_pm_init(void)
(void) clkdm_for_each(clkdms_setup, NULL);
+ mpu_iva_voltdm = voltdm_lookup(mpu_iva);
+ voltdm_pwrdm_enable(mpu_iva_voltdm);
+
mpu_pwrdm = pwrdm_lookup(mpu_pwrdm);
if (mpu_pwrdm == NULL) {
printk(KERN_ERR Failed to get mpu_pwrdm\n);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
On Tue, Feb 14, 2012 at 9:32 PM, Cousson, Benoit b-cous...@ti.com wrote:
On 2/14/2012 2:45 PM, Archit Taneja wrote:
On Tuesday 14 February 2012 07:03 PM, Tomi Valkeinen wrote:
On Tue, 2012-02-14 at 19:00 +0530, Archit Taneja wrote:
Hi,
On Tuesday 14 February 2012 06:45 PM, Tomi Valkeinen wrote:
On Tue, 2012-02-14 at 13:58 +0100, Cousson, Benoit wrote:
Hi Tomi,
Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
hwmod/clk framework at some point, and the drivers could do without
these kinds of hacks? =)
The best way to fix that for my point of view is to go to device tree
or/and to consider the DSS as the parent of all the DSS modules.
pm_runtime will then always ensure that the parent is enabled
before any
of the child are used.
Ah, right. Sounds fine to me.
But is that a proper fix? Are we sure the MODULEMODE will then always
be handled correctly? Isn't the core problem still there, it just
doesn't happen with the setup anymore?
I mean, if we have these special requirements regarding MODULEMODE, and
the code doesn't really know about it, would it get broken easily with
restructuring/changes?
And no, I don't have any clear idea why/how it would break, but I have
just gotten the impression that the MODULEMODE is not handled quite
properly (and so we have these current problems), and having
dss_core as
the parent of other dss modules doesn't really fix that in any way.
I agree with that.
In the current approach, we have multiple platform devices for DSS, and
all of them belong to the same clock domain, and the clock domain has
just one MODULEMODE bit field.
When shutting off a platform device(by calling pm_runtime_put()), hwmod
enables/disables MODULEMODE without taking into mind that other active
platform devices may still need it. So, for example, if we have 2
platform devices, say dss and dispc, and we have code like:
dispc_foo()
{
pm_runtime_get(dispc_pdev);
...
...
pm_runtime_put(dispc_pdev);
}
dss_foo()
{
pm_runtime_get(dss_pdev);
...
...
dispc_foo(); /* MODULEMODE off after this */
...
...
pm_runtime_put(dss_pdev);
}
This will lead to the situation of one platform device disabling
MODULEMODE even though other platform devices need it.
This may not be resolved in device tree either. We would need to have
some use count mechanism for these bits, or attach MODULEMODE only to
one platform device, and don't give others control to enable/disable it.
Hmm, are you sure? Not that I checked the code, but isn't MODULEMODE
mapped to a dss clock (was it dss_clk)?. And so, the clock's refcount
should keep the MODULEMODE enabled/disabled?
Yes, that's how we are currently dealing with it and making things work.
We are forced to represent MODULEMODE as a clock. I forgot to mention
that in the last mail :)
However, other modules don't do this. modulemode control is taken care
by hwmod by itself. We just have to fill the hwmod field
'.prcm.omap4.modulemode' and get done with it. If we try this approach,
we get into the trouble I mentioned before.
We represent MODULEMODE as dss_fck, and make this the l3 slave clock for
all DSS hwmods. This way, we ensure that it gets enabled, and we get a
usecount associated to it. We shouldn't stick to this approach because:
- It isn't exactly correct. MODULEMODE isn't a clock, and others don't
do it.
Yes, fully agree. This was done like that as a hack to avoid any regression
because at that time we were not sure if that dependency will have to be
handled by the hwmod fmwk or by the driver.
Now, I'm sure it should not be handled by the hwmod fmwk :-)
- DSS requires a particular sequence of disabling clocks to go into
lower power states, and with the current approach, this doesn't happen.
So, DSS doesn't idle, and that's the whole purpose of this :)
I'm just curious, what particular sequence is required?
IIRC, the main issue is the order in which functional clock and what
is so called
optional clock enabled
While enabling the module
1. Enable optional clock
2. Enabled module mode.
While disabling module
1. Disable module mode
2. Disable optional clock.
I think only above sequence work. Not following above in either
path leads to modules being stuck in transition.
Is that right Archit ?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Move most of omap io.h into omap-iomap.h
* Tony Lindgren t...@atomide.com [120213 15:22]: Hi all, This is intended as clean-up before we apply Rob Herring's series to remove mach/io.h. Need to update this to fix up more driver modules though. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/4] ARM: OMAP2+: Interrupt controllers adaptation to DT
Hi Tony and Rob, Here is a small update of the INTC controller series that was already acked-by in the v2 [1]. This version is just updating the #2 patch to take advantage of the new irq_domain_add_legacy API introduced by Grant. Please note that in the near future that code can even be simplier with the introduction of the domain support inside generic irq chip. This series is based on lo/master + for_3.4/dt_base branch to get the needed cleanup and fixes for OMAP. It requires as well Grant's irq_domain generalization and refinement series available at: git://git.secretlab.ca/git/linux-2.6 irqdomain/next The series is available here for reference: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.4/dt_irq_domain Regards, Benoit [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/079467.html Benoit Cousson (4): arm/dts: OMAP4: Update DTS file with new GIC bindings ARM: OMAP2/3: intc: Add DT support for TI interrupt controller arm/dts: OMAP3: Add interrupt-controller bindings for INTC ARM: OMAP2+: board-generic: Use of_irq_init API .../devicetree/bindings/arm/omap/intc.txt | 27 + arch/arm/boot/dts/omap3.dtsi |6 +- arch/arm/boot/dts/omap4.dtsi |2 +- arch/arm/mach-omap2/board-generic.c| 30 +- arch/arm/mach-omap2/common.h | 10 +++ arch/arm/mach-omap2/irq.c | 59 --- 6 files changed, 107 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.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/4] arm/dts: OMAP4: Update DTS file with new GIC bindings
The GIC binding was updated in 3.2 and expects 3 interrupt-cells.
- Update the #interrupt-cells
Signed-off-by: Benoit Cousson b-cous...@ti.com
Acked-by: Rob Herring rob.herr...@calxeda.com
---
arch/arm/boot/dts/omap4.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index e8fe75f..70a44f6 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -99,7 +99,7 @@
gic: interrupt-controller@48241000 {
compatible = arm,cortex-a9-gic;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 3;
reg = 0x48241000 0x1000,
0x48240100 0x0100;
};
--
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 v3 2/4] ARM: OMAP2/3: intc: Add DT support for TI interrupt controller
Add a function to initialize the OMAP2/3 interrupt controller (INTC)
using a device tree node.
This version take advantage of the new irq_domain_add_legacy API.
Replace some printk() with the proper pr_ macro.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Grant Likely grant.lik...@secretlab.ca
---
.../devicetree/bindings/arm/omap/intc.txt | 27 +
arch/arm/mach-omap2/common.h | 10 +++
arch/arm/mach-omap2/irq.c | 59 ---
3 files changed, 86 insertions(+), 10 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/intc.txt
b/Documentation/devicetree/bindings/arm/omap/intc.txt
new file mode 100644
index 000..f2583e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/intc.txt
@@ -0,0 +1,27 @@
+* OMAP Interrupt Controller
+
+OMAP2/3 are using a TI interrupt controller that can support several
+configurable number of interrupts.
+
+Main node required properties:
+
+- compatible : should be:
+ ti,omap2-intc
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The type shall be a u32 and the value shall be 1.
+
+ The cell contains the interrupt number in the range [0-128].
+- ti,intc-size: Number of interrupts handled by the interrupt controller.
+- reg: physical base address and size of the intc registers map.
+
+Example:
+
+ intc: interrupt-controller@1 {
+ compatible = ti,omap2-intc;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ ti,intc-size = 96;
+ reg = 0x4820 0x1000;
+ };
+
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index febffde..a87ce52 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -174,6 +174,16 @@ void omap3_intc_handle_irq(struct pt_regs *regs);
extern void __iomem *omap4_get_l2cache_base(void);
#endif
+struct device_node;
+#ifdef CONFIG_OF
+int __init intc_of_init(struct device_node *node, struct device_node *parent);
+#else
+int __init intc_of_init(struct device_node *node, struct device_node *parent)
+{
+ return 0;
+}
+#endif
+
#ifdef CONFIG_SMP
extern void __iomem *omap4_get_scu_base(void);
#else
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 1fef061..e2d0f33 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -11,12 +11,16 @@
* for more details.
*/
#include linux/kernel.h
+#include linux/module.h
#include linux/init.h
#include linux/interrupt.h
#include linux/io.h
#include mach/hardware.h
#include asm/exception.h
#include asm/mach/irq.h
+#include linux/irqdomain.h
+#include linux/of.h
+#include linux/of_address.h
/* selected INTC register offsets */
@@ -57,6 +61,8 @@ static struct omap_irq_bank {
},
};
+static struct irq_domain *domain;
+
/* Structure to save interrupt controller context */
struct omap3_intc_regs {
u32 sysconfig;
@@ -147,17 +153,27 @@ omap_alloc_gc(void __iomem *base, unsigned int irq_start,
unsigned int num)
IRQ_NOREQUEST | IRQ_NOPROBE, 0);
}
-static void __init omap_init_irq(u32 base, int nr_irqs)
+static void __init omap_init_irq(u32 base, int nr_irqs,
+struct device_node *node)
{
void __iomem *omap_irq_base;
unsigned long nr_of_irqs = 0;
unsigned int nr_banks = 0;
- int i, j;
+ int i, j, irq_base;
omap_irq_base = ioremap(base, SZ_4K);
if (WARN_ON(!omap_irq_base))
return;
+ irq_base = irq_alloc_descs(-1, 0, nr_irqs, 0);
+ if (irq_base 0) {
+ pr_warn(Couldn't allocate IRQ numbers\n);
+ irq_base = 0;
+ }
+
+ domain = irq_domain_add_legacy(node, nr_irqs, irq_base, 0,
+ irq_domain_simple_ops, NULL);
+
for (i = 0; i ARRAY_SIZE(irq_banks); i++) {
struct omap_irq_bank *bank = irq_banks + i;
@@ -166,36 +182,36 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
/* Static mapping, never released */
bank-base_reg = ioremap(base, SZ_4K);
if (!bank-base_reg) {
- printk(KERN_ERR Could not ioremap irq bank%i\n, i);
+ pr_err(Could not ioremap irq bank%i\n, i);
continue;
}
omap_irq_bank_init_one(bank);
for (j = 0; j bank-nr_irqs; j += 32)
- omap_alloc_gc(bank-base_reg + j, j, 32);
+ omap_alloc_gc(bank-base_reg + j, j + irq_base, 32);
nr_of_irqs += bank-nr_irqs;
[PATCH v3 3/4] arm/dts: OMAP3: Add interrupt-controller bindings for INTC
Update the DTS with the proper information required by the
INTC bindings.
- Add the number of interrupt lines
- Add the reg and the compatible entries.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Acked-by: Rob Herring rob.herr...@calxeda.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/boot/dts/omap3.dtsi |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 216c331..34cce6d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -61,10 +61,12 @@
ranges;
ti,hwmods = l3_main;
- intc: interrupt-controller@1 {
- compatible = ti,omap3-intc;
+ intc: interrupt-controller@4820 {
+ compatible = ti,omap2-intc;
interrupt-controller;
#interrupt-cells = 1;
+ ti,intc-size = 96;
+ reg = 0x4820 0x1000;
};
uart1: serial@0x4806a000 {
--
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 v3 4/4] ARM: OMAP2+: board-generic: Use of_irq_init API
Use the of_irq_init API introduced in 3.2 to handle
interrupt-controller with DT.
Update the irq_match table to map the proper XXX_of_init
functions for INTC and GIC drivers.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Acked-by: Rob Herring rob.herr...@calxeda.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/mach-omap2/board-generic.c | 30 --
1 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 02d7e82..cf08921 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -12,6 +12,7 @@
* published by the Free Software Foundation.
*/
#include linux/io.h
+#include linux/of_irq.h
#include linux/of_platform.h
#include linux/irqdomain.h
#include linux/i2c/twl.h
@@ -24,6 +25,17 @@
#include common.h
#include common-board-devices.h
+static struct of_device_id irq_match[] __initdata = {
+ { .compatible = ti,omap2-intc, .data = intc_of_init, },
+ { .compatible = arm,cortex-a9-gic, .data = gic_of_init, },
+ { }
+};
+
+static void __init omap_init_irq(void)
+{
+ of_irq_init(irq_match);
+}
+
/*
* XXX: Still needed to boot until the i2c twl driver is adapted to
* device-tree
@@ -58,18 +70,8 @@ static struct of_device_id omap_dt_match_table[] __initdata
= {
{ }
};
-static struct of_device_id intc_match[] __initdata = {
- { .compatible = ti,omap3-intc, },
- { .compatible = arm,cortex-a9-gic, },
- { }
-};
-
static void __init omap_generic_init(void)
{
- struct device_node *node = of_find_matching_node(NULL, intc_match);
- if (node)
- irq_domain_add_legacy(node, 32, 0, 0, irq_domain_simple_ops,
NULL);
-
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
@@ -101,7 +103,7 @@ DT_MACHINE_START(OMAP242X_DT, Generic OMAP2420 (Flattened
Device Tree))
.reserve= omap_reserve,
.map_io = omap242x_map_io,
.init_early = omap2420_init_early,
- .init_irq = omap2_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = omap2_intc_handle_irq,
.init_machine = omap_generic_init,
.timer = omap2_timer,
@@ -120,7 +122,7 @@ DT_MACHINE_START(OMAP243X_DT, Generic OMAP2430 (Flattened
Device Tree))
.reserve= omap_reserve,
.map_io = omap243x_map_io,
.init_early = omap2430_init_early,
- .init_irq = omap2_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = omap2_intc_handle_irq,
.init_machine = omap_generic_init,
.timer = omap2_timer,
@@ -139,7 +141,7 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened Device
Tree))
.reserve= omap_reserve,
.map_io = omap3_map_io,
.init_early = omap3430_init_early,
- .init_irq = omap3_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = omap3_intc_handle_irq,
.init_machine = omap3_init,
.timer = omap3_timer,
@@ -158,7 +160,7 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened Device
Tree))
.reserve= omap_reserve,
.map_io = omap4_map_io,
.init_early = omap4430_init_early,
- .init_irq = gic_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = gic_handle_irq,
.init_machine = omap4_init,
.timer = omap4_timer,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: cpuidle: Fix the C-state reporting to cpuidle governor.
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Wednesday 08 February 2012 04:08 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
OMAP4 cpuidle driver is reporting the state requested by governor rather
than
the actually attempted one.
This is obviously misleading sysfs and powertop cpuidle statistics.
Fix it so that stats are reported correctly.
Reported-by: Kevin Hilman khil...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index cfdbb86..f128489 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -85,6 +85,7 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
cpu1_state = pwrdm_read_pwrst(cpu1_pd);
if (cpu1_state != PWRDM_POWER_OFF) {
new_state_idx = drv-safe_state_index;
+ index = drv-safe_state_index;
How about just get rid of new_state_idx all together and just update
index and use it to index in to the states.
Make sense. Updated patch below.
Regards,
Santosh
From 939dc3eda7895043c03526110e2a6b41e9861146 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Sun, 5 Feb 2012 13:18:44 +0530
Subject: [PATCH 2/2] ARM: OMAP4: cpuidle: Fix the C-state reporting to
cpuidle governor.
OMAP4 cpuidle driver is reporting the state requested by governor rather
than
the actually attempted one.
This is obviously misleading sysfs and powertop cpuidle statistics.
Fix it so that stats are reported correctly.
While at this, get rid of new_state_idx, update and use
index in to the states.
Reported-by: Kevin Hilman khil...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Perfect. Thanks.
Queuing as a fix for v3.3.
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: [PATCHv8 4/5] twl4030: add support for external voltage get/set
Tero Kristo t-kri...@ti.com writes: On Tue, 2012-01-10 at 19:10 +, Mark Brown wrote: On Tue, Jan 10, 2012 at 07:19:18AM -0800, Kevin Hilman wrote: Yes, some of the control still goes via the normal path (although I forget which, maybe Benoit can remind us), so I think it's best to add the HW control part to each regulator that might uses it. Ideally this could be facilitated by adding the extentions to the regulator core so the amount of code needed for each regulator driver would be minimal. I think the original version of the patch was something along those lines but it was just a general facility which ignored the regulator driver entirely which didn't feel well integrated. The discussion suggested that this wasn't something that'd work with other regulators so a per-driver solution seemed OK. Coming back to this patch now as I have time to look at it, what is the general opinion, is it acceptable to patch the regulator core to add support for the external controller or should I just resend the latest version with changes Mark suggested? This will probably mean that once we add new regulator drivers (e.g. pmics) we may need to duplicate the external controller support here. How about you keep it in the regulator driver for now, and when we need to abstract it out, we make the case for it then. 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 2/2] ARM: OMAP4: Move the barrier memboclk_steal() as part of reserve callback
* Shilimkar, Santosh santosh.shilim...@ti.com [120214 02:58]:
On Tue, Feb 14, 2012 at 4:44 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Feb 14, 2012 at 02:19:41PM +0530, Santosh Shilimkar wrote:
From 4d1ea22985adfe458275b9ae3e00edc6e41a267f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Thu, 2 Feb 2012 15:59:51 +0530
Subject: [PATCH 1/2] ARM: OMAP4: Move the barrier memboclk_steal() as
part of reserve callback
Commit 716a3dc{ARM: Add arm_memblock_steal() to allocate memory away
from the kernel} introduced arm_memblock_steal() which lead to
OMAP4_ERRATA_I688 to be broken and needed to be fixed.
That is misleading. Please don't attribute blame for this breakage to
that patch, which has nothing to do with introducing the breakage. The
errata was broken right from the start.
That's right and I didn't mean that way.
This was the same reason, first patch I just mentioned what was wrong
in the code
rather than mention of any commit.
Tony,
Let me know if you want to add any commit history to the change since
the issue was actually existing without 'arm_memblock_stea()' commit.
I think, first change log was good enough from the fix point of view.
OK, makes sense. I'll apply it into fixes as is then.
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 1/2] ARM: OMAP: Get rid of reset for system timer
* Shilimkar, Santosh santosh.shilim...@ti.com [120213 22:44]: On Tue, Feb 14, 2012 at 10:44 AM, Rajendra Nayak rna...@ti.com wrote: On Saturday 11 February 2012 12:48 AM, Tony Lindgren wrote: * Santosh Shilimkarsantosh.shilim...@ti.com [120202 05:33]: From: Rajendra Nayakrna...@ti.com hwmod setup already does a reset and sets the OCP sysconfig registers appropriately. Avoid doing a reset again and overriding the OCP sysconfig settings in the system timer init code. If we want this queued as a fix, it should also describe what actually breaks? Timer? PM? It only fixes the redundant reset and overriding the smartidle-wakeup OCP setting (done by hwmod) with the smartidle in the driver. Doing this doesn't really break anything as yet in mainline, but will cause timer wakeup issues once OFF mode is in place for OMAP4. On OMAP5 however this was causing more issues as the softreset bit position is different than on OMAP2/3/4. So it should be ok to queue this in for 3.4 considering neither OMAP4 OFF, not OMAP5 support is in mainline yet. I second Rajendra's comment. OK thanks, will apply into fixes-non-critical. 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 4/6] arm: omap3: add manual control for mpu_iva voltdm usecounting
Tero Kristo t-kri...@ti.com writes:
mpu_iva voltdm usecount is now decreased during idle. This will
allow the voltagedomain to reflect actual usage, and will allow
proper usage of vc callbacks.
I don't follow why this is needed in the idle path.
Why aren't the usecounts from clock/powerdomain disables (enables) causing this
voltdm disable (enable) to happen automatcially?
If these are needed, seems like they should be in the
pwrdm_[pre|post]_transition() hooks so they can be generic.
Kevin
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index fc69875..14defaf 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -74,6 +74,7 @@ void (*omap3_do_wfi_sram)(void);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
static struct powerdomain *cam_pwrdm;
+static struct voltagedomain *mpu_iva_voltdm;
static inline void omap3_per_save_context(void)
{
@@ -311,6 +312,8 @@ void omap_sram_idle(void)
return;
}
+ voltdm_pwrdm_disable(mpu_iva_voltdm);
+
/* NEON control */
if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
@@ -393,6 +396,8 @@ void omap_sram_idle(void)
}
omap3_intc_resume_idle();
+ voltdm_pwrdm_enable(mpu_iva_voltdm);
+
pwrdm_post_transition();
/* PER */
@@ -828,6 +833,9 @@ static int __init omap3_pm_init(void)
(void) clkdm_for_each(clkdms_setup, NULL);
+ mpu_iva_voltdm = voltdm_lookup(mpu_iva);
+ voltdm_pwrdm_enable(mpu_iva_voltdm);
+
mpu_pwrdm = pwrdm_lookup(mpu_pwrdm);
if (mpu_pwrdm == NULL) {
printk(KERN_ERR Failed to get mpu_pwrdm\n);
--
To unsubscribe from this list: send the line unsubscribe 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] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
On Tuesday 14 February 2012 10:29 PM, Shilimkar, Santosh wrote:
On Tue, Feb 14, 2012 at 9:32 PM, Cousson, Benoitb-cous...@ti.com wrote:
On 2/14/2012 2:45 PM, Archit Taneja wrote:
On Tuesday 14 February 2012 07:03 PM, Tomi Valkeinen wrote:
On Tue, 2012-02-14 at 19:00 +0530, Archit Taneja wrote:
Hi,
On Tuesday 14 February 2012 06:45 PM, Tomi Valkeinen wrote:
On Tue, 2012-02-14 at 13:58 +0100, Cousson, Benoit wrote:
Hi Tomi,
Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
hwmod/clk framework at some point, and the drivers could do without
these kinds of hacks? =)
The best way to fix that for my point of view is to go to device tree
or/and to consider the DSS as the parent of all the DSS modules.
pm_runtime will then always ensure that the parent is enabled
before any
of the child are used.
Ah, right. Sounds fine to me.
But is that a proper fix? Are we sure the MODULEMODE will then always
be handled correctly? Isn't the core problem still there, it just
doesn't happen with the setup anymore?
I mean, if we have these special requirements regarding MODULEMODE, and
the code doesn't really know about it, would it get broken easily with
restructuring/changes?
And no, I don't have any clear idea why/how it would break, but I have
just gotten the impression that the MODULEMODE is not handled quite
properly (and so we have these current problems), and having
dss_core as
the parent of other dss modules doesn't really fix that in any way.
I agree with that.
In the current approach, we have multiple platform devices for DSS, and
all of them belong to the same clock domain, and the clock domain has
just one MODULEMODE bit field.
When shutting off a platform device(by calling pm_runtime_put()), hwmod
enables/disables MODULEMODE without taking into mind that other active
platform devices may still need it. So, for example, if we have 2
platform devices, say dss and dispc, and we have code like:
dispc_foo()
{
pm_runtime_get(dispc_pdev);
...
...
pm_runtime_put(dispc_pdev);
}
dss_foo()
{
pm_runtime_get(dss_pdev);
...
...
dispc_foo(); /* MODULEMODE off after this */
...
...
pm_runtime_put(dss_pdev);
}
This will lead to the situation of one platform device disabling
MODULEMODE even though other platform devices need it.
This may not be resolved in device tree either. We would need to have
some use count mechanism for these bits, or attach MODULEMODE only to
one platform device, and don't give others control to enable/disable it.
Hmm, are you sure? Not that I checked the code, but isn't MODULEMODE
mapped to a dss clock (was it dss_clk)?. And so, the clock's refcount
should keep the MODULEMODE enabled/disabled?
Yes, that's how we are currently dealing with it and making things work.
We are forced to represent MODULEMODE as a clock. I forgot to mention
that in the last mail :)
However, other modules don't do this. modulemode control is taken care
by hwmod by itself. We just have to fill the hwmod field
'.prcm.omap4.modulemode' and get done with it. If we try this approach,
we get into the trouble I mentioned before.
We represent MODULEMODE as dss_fck, and make this the l3 slave clock for
all DSS hwmods. This way, we ensure that it gets enabled, and we get a
usecount associated to it. We shouldn't stick to this approach because:
- It isn't exactly correct. MODULEMODE isn't a clock, and others don't
do it.
Yes, fully agree. This was done like that as a hack to avoid any regression
because at that time we were not sure if that dependency will have to be
handled by the hwmod fmwk or by the driver.
Now, I'm sure it should not be handled by the hwmod fmwk :-)
- DSS requires a particular sequence of disabling clocks to go into
lower power states, and with the current approach, this doesn't happen.
So, DSS doesn't idle, and that's the whole purpose of this :)
I'm just curious, what particular sequence is required?
IIRC, the main issue is the order in which functional clock and what
is so called
optional clock enabled
While enabling the module
1. Enable optional clock
2. Enabled module mode.
While disabling module
1. Disable module mode
2. Disable optional clock.
I think only above sequence work. Not following above in either
path leads to modules being stuck in transition.
Is that right Archit ?
Yes. Also, this transition failure happens when DSS clock domain is set
to hardware supervised wakeup(HWAUTO).
The opt clock which requires this ordering with module mode is DSS_FCLK
by default. However, if some other clock (like DSI PLL, sourced by
SYS_CLK) is the source for DISPC_FCLK, then that clock is the one which
needs to be ordered with module mode.
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-fbdev 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
Re: [PATCH] arm: omap: usb-host: fix compile warning
* Felipe Balbi ba...@ti.com [120214 00:23]: when commit 3528c58 (OMAP: omap_device: when building return platform_device instead of omap_device) started returning a platform_device instead of a omap_device pointer when building a device, it failed to convert all users introducing a compile warning when building arch/arm/mach-omap2/usb-host.c. This patch fixes that warning. Thanks applying into fixes. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] ARM: OMAP2/3: intc: Add DT support for TI interrupt controller
On 02/14/2012 11:56 AM, Benoit Cousson wrote:
Add a function to initialize the OMAP2/3 interrupt controller (INTC)
using a device tree node.
This version take advantage of the new irq_domain_add_legacy API.
Replace some printk() with the proper pr_ macro.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Grant Likely grant.lik...@secretlab.ca
Given that you plan to do gen irqchip:
Acked-by: Rob Herring rob.herr...@calxeda.com
Rob
---
.../devicetree/bindings/arm/omap/intc.txt | 27 +
arch/arm/mach-omap2/common.h | 10 +++
arch/arm/mach-omap2/irq.c | 59 ---
3 files changed, 86 insertions(+), 10 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/intc.txt
b/Documentation/devicetree/bindings/arm/omap/intc.txt
new file mode 100644
index 000..f2583e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/intc.txt
@@ -0,0 +1,27 @@
+* OMAP Interrupt Controller
+
+OMAP2/3 are using a TI interrupt controller that can support several
+configurable number of interrupts.
+
+Main node required properties:
+
+- compatible : should be:
+ ti,omap2-intc
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The type shall be a u32 and the value shall be 1.
+
+ The cell contains the interrupt number in the range [0-128].
+- ti,intc-size: Number of interrupts handled by the interrupt controller.
+- reg: physical base address and size of the intc registers map.
+
+Example:
+
+ intc: interrupt-controller@1 {
+ compatible = ti,omap2-intc;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ ti,intc-size = 96;
+ reg = 0x4820 0x1000;
+ };
+
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index febffde..a87ce52 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -174,6 +174,16 @@ void omap3_intc_handle_irq(struct pt_regs *regs);
extern void __iomem *omap4_get_l2cache_base(void);
#endif
+struct device_node;
+#ifdef CONFIG_OF
+int __init intc_of_init(struct device_node *node, struct device_node
*parent);
+#else
+int __init intc_of_init(struct device_node *node, struct device_node *parent)
+{
+ return 0;
+}
+#endif
+
#ifdef CONFIG_SMP
extern void __iomem *omap4_get_scu_base(void);
#else
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 1fef061..e2d0f33 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -11,12 +11,16 @@
* for more details.
*/
#include linux/kernel.h
+#include linux/module.h
#include linux/init.h
#include linux/interrupt.h
#include linux/io.h
#include mach/hardware.h
#include asm/exception.h
#include asm/mach/irq.h
+#include linux/irqdomain.h
+#include linux/of.h
+#include linux/of_address.h
/* selected INTC register offsets */
@@ -57,6 +61,8 @@ static struct omap_irq_bank {
},
};
+static struct irq_domain *domain;
+
/* Structure to save interrupt controller context */
struct omap3_intc_regs {
u32 sysconfig;
@@ -147,17 +153,27 @@ omap_alloc_gc(void __iomem *base, unsigned int
irq_start, unsigned int num)
IRQ_NOREQUEST | IRQ_NOPROBE, 0);
}
-static void __init omap_init_irq(u32 base, int nr_irqs)
+static void __init omap_init_irq(u32 base, int nr_irqs,
+ struct device_node *node)
{
void __iomem *omap_irq_base;
unsigned long nr_of_irqs = 0;
unsigned int nr_banks = 0;
- int i, j;
+ int i, j, irq_base;
omap_irq_base = ioremap(base, SZ_4K);
if (WARN_ON(!omap_irq_base))
return;
+ irq_base = irq_alloc_descs(-1, 0, nr_irqs, 0);
+ if (irq_base 0) {
+ pr_warn(Couldn't allocate IRQ numbers\n);
+ irq_base = 0;
+ }
+
+ domain = irq_domain_add_legacy(node, nr_irqs, irq_base, 0,
+irq_domain_simple_ops, NULL);
+
for (i = 0; i ARRAY_SIZE(irq_banks); i++) {
struct omap_irq_bank *bank = irq_banks + i;
@@ -166,36 +182,36 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
/* Static mapping, never released */
bank-base_reg = ioremap(base, SZ_4K);
if (!bank-base_reg) {
- printk(KERN_ERR Could not ioremap irq bank%i\n, i);
+ pr_err(Could not ioremap irq bank%i\n, i);
continue;
}
omap_irq_bank_init_one(bank);
for (j = 0; j bank-nr_irqs;
Re: [PATCH 1/4] ARM: OMAP2+: board-generic: Remove un-needed .atag_offset for DT_MACHINE
* Benoit Cousson b-cous...@ti.com [120213 07:59]: Some .atag_offset entries were wrongly added during a merge conflict resolution in 3.3. Remove them all, since DT boot does not use that attribute anymore. Replace as well the #if... by #ifdef for consistency. How about let's also remove the 0x from the serial@0x.. in the .dts files in this clean-up patch? 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 0/6] arm: omap: clk/clkdm/pwrdm/voltdm changes to usecounting
Tero Kristo t-kri...@ti.com writes: This set is split out from a larger set earlier circulated on linux-omap list. The main purpose of this set is to provide useful recursive usecounting support for clockdomains / powerdomains / voltagedomains which can be used for debugging purposes and also to control certain chip power features once a sleep condition is reached (voltdm usecount=0). This set provides only the baseline support for the usecounting, and also adds a pm-debug related patch that can be used to check out stuff (patch 6), and should later prove rather useful for debugging. Rest of the functionality will be posted in separate sets. This set has been tested on omap3 beagle board with suspend / resume / cpuidle. Also boot tested on omap4 panda (sleep is not functional yet on that platform.) This is a great series, and results in pm_debug debugfs data that's actually useful for real debug. Thanks! I had a minor comment on the idle path changes, but all the other stuff is Acked-by: Kevin Hilman khil...@ti.com Paul, this should probably merge via you (when it's ready) since the important changes are clock and powerdomain core changes. 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] usb: host: ehci: allow ehci_* symbols to be unused
On Tue, 14 Feb 2012, Felipe Balbi wrote: The others are questionable. What reason could there be for not implementing ehci_bus_suspend and ehci_bus_resume? Neither of those should involve much platform-specific work, if any. you never know what kind of silicon erratas might come up, right ? :-) Well, when they come up we can annotate those routines. ehci_hub_status_data, ehci_hub_descriptor, and ehci_hub_control are even more puzzling. These are things that _have_ to be implemented for the driver to work at all. Platform code shouldn't replace them; it most it should call them as subroutines and override the results when necessary. There's no doubt it needs to be implemented, but the fact is that in some situations we might need to implement it differently because of whatever reason. See for example that I have a pending workaround to implement for OMAP3 EHCI where we need to reparent a clock before handling SetFeature(port_suspend) so I would need to reimplement echi_hub_control() in order not to expose that detail to core ehci. Because clock reparenting is something so ARCH-specific it makes no sense to come up with a quirk flag for that. Granted, the way I had envisioned, I would reimplement the particular request that needs special handling and call the generic ehci_hub_control() otherwise, but still. Like I said, you never know what kind of erratas could pop up. It's hard to imagine what sort of errata could require you not to call the generic routine. Besides, it's a big routine, and duplicating it in platform-specific code would be a big waste. For now I think you should annotate just the three routines that really need it. This is analogous to patches that add new features with no usages in the kernel; we just don't do such things. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] arm: omap: pm-debug: enhanced usecount debug support
* Tero Kristo t-kri...@ti.com [120214 08:19]: Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to their own file, 'usecount'. This file shows the usecounts for every active domain and their children recursively. 'count' file now only shows power state counts for powerdomains. This patch also provices a way to do printk dumps from kernel code, by calling the pm_dbg_dump_X functions. The plan is to call these functions once an error condition is detected, e.g. failed suspend. Why don't you replace this all with a userspace tool that deciphers the registers for you? 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.3 v2] OMAP4: PRM: fix build breakage when CONFIG_OF is not defined
* Luciano Coelho coe...@ti.com [120208 02:43]: Since 3.3-rc1, prm44xx.c build breaks if CONFIG_OF is not set: arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function) make[1]: *** [arch/arm/mach-omap2/prm44xx.o] Error 1 This is because of a missing include, which is added indirectly if CONFIG_OF is defined. This problem was introduced in commit 2f31b51 (ARM: OMAP4: PRM: use PRCM interrupt handler). Cc: Tero Kristo t-kri...@ti.com Signed-off-by: Luciano Coelho coe...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com A similar patch should be already in mainline kernel queued by Russell. Tony --- v2: changed the commit log to use abbrev sha and include the commit subject arch/arm/mach-omap2/prm44xx.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c index 33dd655..f2e06ad 100644 --- a/arch/arm/mach-omap2/prm44xx.c +++ b/arch/arm/mach-omap2/prm44xx.c @@ -20,6 +20,7 @@ #include common.h #include plat/cpu.h #include plat/prcm.h +#include plat/irqs.h #include vp.h #include prm44xx.h -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] ARM: OMAP2/3: intc: Add DT support for TI interrupt controller
On Tue, Feb 14, 2012 at 06:56:10PM +0100, Benoit Cousson wrote:
Add a function to initialize the OMAP2/3 interrupt controller (INTC)
using a device tree node.
This version take advantage of the new irq_domain_add_legacy API.
Replace some printk() with the proper pr_ macro.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Grant Likely grant.lik...@secretlab.ca
---
.../devicetree/bindings/arm/omap/intc.txt | 27 +
arch/arm/mach-omap2/common.h | 10 +++
arch/arm/mach-omap2/irq.c | 59 ---
3 files changed, 86 insertions(+), 10 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/intc.txt
b/Documentation/devicetree/bindings/arm/omap/intc.txt
new file mode 100644
index 000..f2583e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/intc.txt
@@ -0,0 +1,27 @@
+* OMAP Interrupt Controller
+
+OMAP2/3 are using a TI interrupt controller that can support several
+configurable number of interrupts.
+
+Main node required properties:
+
+- compatible : should be:
+ ti,omap2-intc
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The type shall be a u32 and the value shall be 1.
+
+ The cell contains the interrupt number in the range [0-128].
+- ti,intc-size: Number of interrupts handled by the interrupt controller.
+- reg: physical base address and size of the intc registers map.
+
+Example:
+
+ intc: interrupt-controller@1 {
+ compatible = ti,omap2-intc;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ ti,intc-size = 96;
+ reg = 0x4820 0x1000;
+ };
+
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index febffde..a87ce52 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -174,6 +174,16 @@ void omap3_intc_handle_irq(struct pt_regs *regs);
extern void __iomem *omap4_get_l2cache_base(void);
#endif
+struct device_node;
+#ifdef CONFIG_OF
+int __init intc_of_init(struct device_node *node, struct device_node
*parent);
This name is pretty generic for a global symbol. How about omap2_intc_of_init?
Otherwise this series looks good.
Acked-by: Grant Likely grant.lik...@secretlab.ca
This series need to be committed on top of the irqdomain tree. I can either
pick it up myself (with Tony's ack) or I can stabilize the irqdomain/next tree
so that you can use it as a stable base to commit against (which I should
probably do anyway since there are others who will depend on it).
g.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP: am33xx: Hook-up am33xx support to existing cm code
Vaibhav == Vaibhav Hiremath hvaib...@ti.com writes:
Vaibhav Reuse existing omap4 cminst code for am33xx device,
Vaibhav add separate cm base table for am33xx device and initialize
Vaibhav it during __init for future use.
Vaibhav Also, since cpu_is_omap34xx() check is true for am33xx family of
Vaibhav devices, we must change the order of cpu_is_ check, so first
Vaibhav check for cpu_is_am33xx() to follow right execution path.
Vaibhav if (cpu_is_omap44xx()) {
Vaibhav _cm_bases = omap44xx_cm_bases;
Vaibhav max_cm_partitions = ARRAY_SIZE(omap44xx_cm_bases);
Vaibhav + } else if (cpu_is_am33xx()) {
Vaibhav + _cm_bases =am33xx_cm_bases;
Space after '='.
Vaibhav +++ b/arch/arm/mach-omap2/omap_hwmod.c
Vaibhav @@ -737,7 +737,7 @@ static void _disable_optional_clocks(struct
omap_hwmod *oh)
Vaibhav static void _enable_module(struct omap_hwmod *oh)
Vaibhav {
Vaibhav /* The module mode does not exist prior OMAP4 */
Vaibhav - if (cpu_is_omap24xx() || cpu_is_omap34xx())
Vaibhav + if (!cpu_is_omap44xx() !cpu_is_am33xx())
Maybe update the comment as well?
Vaibhav /* The module mode does not exist prior OMAP4 */
Vaibhav - if (!cpu_is_omap44xx())
Vaibhav + if (!cpu_is_omap44xx() !cpu_is_am33xx())
Vaibhav return -EINVAL;
Here as well.
Otherwise it looks good.
Acked-by: Peter Korsgaard jac...@sunsite.dk
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line unsubscribe 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] modpost: Fix section warnings for ARM for many compilers
* Tony Lindgren t...@atomide.com [120213 16:41]: * Rusty Russell ru...@rustcorp.com.au [120213 16:07]: On Mon, 13 Feb 2012 22:51:18 +, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Feb 13, 2012 at 11:26:52PM +0100, Uwe Kleine-König wrote: On Mon, Feb 13, 2012 at 01:24:01PM -0800, Tony Lindgren wrote: Maybe: #ifndef R_ARM_CALL #warning you're elf.h include is outdated You are elf.h include is outdated does not make sense. Why are you calling Tony an elf.h include? Because he knew it would attract the attention of pedants to the patch? :) I've been called worse than that :) Just do the #ifndef, and skip the warning. There's not much the poor user receiving the warning can do about it. OK Acked-by: Rusty Russell ru...@rustcorp.com.au Assuming your ack applies for this patch below, let me know if that's not the case. This is now in Russell's patch tracking system as patch 7324/1. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP4: cminst: Add boot time __init function for cminst
Vaibhav == Vaibhav Hiremath hvaib...@ti.com writes:
Vaibhav AM33xx CM module is closer to OMAP4 CM module, and
Vaibhav in order to reuse cminst api's we have to address
Vaibhav some of the differences like, base addresses and partitions.
Vaibhav Unlike OMAP4 CM, AM33xx doesn't have any partitions and
Vaibhav maintains only single partition.
Vaibhav So, in order to reuse the existing OMAP4 cminst code
Vaibhav for AM33xx this patch adds,
Vaibhav - Boot time __init function, to initialize _cm_bases
Vaibhav based on cpu_is_xxx
Vaibhav - Instead of maintaining phy addr for CM partition
Vaibhav in _cm_bases[] table and then changing it to virt addr,
Vaibhav directly maintain respective virt addr.
Vaibhav @@ -103,19 +106,19 @@ static bool _is_module_ready(u8 part, u16 inst,
s16 cdoffs, u16 clkctrl_offs)
Vaibhav /* Read a register in a CM instance */
Vaibhav u32 omap4_cminst_read_inst_reg(u8 part, s16 inst, u16 idx)
Vaibhav {
Vaibhav - BUG_ON(part = OMAP4_MAX_PRCM_PARTITIONS ||
Vaibhav + BUG_ON(part = max_cm_partitions ||
Vaibhav part == OMAP4430_INVALID_PRCM_PARTITION ||
How about dropping the OMAP4430_ prefix here as it's no longer 4430 specific?
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] arm: omap: pm-debug: enhanced usecount debug support
Tony Lindgren t...@atomide.com writes: * Tero Kristo t-kri...@ti.com [120214 08:19]: Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to their own file, 'usecount'. This file shows the usecounts for every active domain and their children recursively. 'count' file now only shows power state counts for powerdomains. This patch also provices a way to do printk dumps from kernel code, by calling the pm_dbg_dump_X functions. The plan is to call these functions once an error condition is detected, e.g. failed suspend. Why don't you replace this all with a userspace tool that deciphers the registers for you? This patch isn't deciphering registers, it's just dumping usecounts, and I think that is extremely useful to have in debugfs. I've already removed all the register dumping from the kernel in the hopes that someone will write a userspace tool for that. 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 6/6] arm: omap: pm-debug: enhanced usecount debug support
* Kevin Hilman khil...@ti.com [120214 14:28]: Tony Lindgren t...@atomide.com writes: * Tero Kristo t-kri...@ti.com [120214 08:19]: Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to their own file, 'usecount'. This file shows the usecounts for every active domain and their children recursively. 'count' file now only shows power state counts for powerdomains. This patch also provices a way to do printk dumps from kernel code, by calling the pm_dbg_dump_X functions. The plan is to call these functions once an error condition is detected, e.g. failed suspend. Why don't you replace this all with a userspace tool that deciphers the registers for you? This patch isn't deciphering registers, it's just dumping usecounts, and I think that is extremely useful to have in debugfs. I've already removed all the register dumping from the kernel in the hopes that someone will write a userspace tool for that. OK good to hear you're already considering it. 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 4/5] OMAPDSS: Export functions to enable dynamic linking
Hi Tomi, Thanks for your comments. On Mon, 2012-02-13 at 15:48 +0200, Tomi Valkeinen wrote: Hi, On Sat, 2012-02-11 at 17:55 -0600, Ricardo Neri wrote: The functions dss_init_hdmi_ip_ops and dss_has_feature are used by the ASoC HDMI codec. Both the ASoC codec and DSS may be built as separate kernel modules. Hence, these two functions need to be available for dynamic linking. Neither of those functions should be exported, they are omapdss internal. And you had to hack around to make those usable by adding drivers/video/omap2/dss into the include path. Anything that is exported from omapdss should be added to include/video/omapdss.h. Users of omapdss should never include anything from drivers/video/omap2/dss. But as I said, neither of those functions should be exported, they are clearly omapdss internal functions. For dss_has_feature we probably need a new function to convey the information about the hdmi features that the audio side needs. Or perhaps it can be in the ip_data. I will try to create this new functions and add it to include/video/omapdss.h and resubmit the patch. The approach that I am following is to maintain an hdmi_ip_data structure in the ASoC HDMI codec driver to utilize the functions of the HDMI IP library. If the DSS features are stored in the ip_data then I would need a DSS function (i.e., dss_features_init or similar) to initialize it. This may not be right as that is an omapdss internal function. For dss_init_hdmi_ip_ops I don't see why the audio part should see it. Initializing the ops should clearly be done by omapdss automatically. Yes, the DSS HDMI driver already does this for its own struct hdmi_ip_data. However, under my approach, the hdmi_ip_data of the ASoC HDMI driver needs to be initialized as well. Another approach is to not have an hdmi_ip_data in the ASoC HDMI driver and reuse the ip_data of the DSS HDMI driver. In that case, however, a lot of set/get functions would need to be implemented in DSS to expose audio functionality: HDMI mode, deep color configuration, audio infoframe config and core and wrapper configuration for audio. An example of this is already present in here: http://www.spinics.net/lists/linux-omap/msg64479.html Being HDMI special as no other display combines audio and video, maybe a special header file could be created for HDMI. What do you think? Ricardo Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: tidspbridge: enable watchdog by default
On Tue, Feb 14, 2012 at 10:23 AM, Felipe Contreras felipe.contre...@gmail.com wrote: When that case is applicable, we should first modify the loader code or prepare the baseimages to be common so we can get rid of specific loaders and just dump them into memory. I'd say the less workarounds, the better. If there are ever more base images compatible with the dsp, I would say that unifying them into a common format to be dumped in memory isn't a workaround, and in that process we can get rid of the custom loader code. WDT could be detected by prepending common symbols into the baseimages or just making the new images to treat all peripherals as resources, that is, the new baseimg should actually request the wdt3 as any other clock. I see, but if wdt3 is requested as another clock, the Linux ARM side would still need to know how to threat the WDT. Tidspbridge does know how to treat other clock request from dsp (gpt, mcbsp), it would be a matter of adding the logic in the arm side for any dsp image that is able to do it, however this doesn't apply to the current (latest) base image since it assumes the wdt3 is always controlled by tidspbridge. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/2] staging: tidspbridge: detecting wdt from baseimage
This is an alternate solution for: WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:162 omap3_l3_app_irq... In-band Error seen by IVA_SS at address 0 Instead of setting CONFIG_TIDSPBRIDGE_WDT3 to 'default y', these patches include the code to be compiled for runtime detection of this feature based on baseimage symbols. As mentioned in the description of the first patch, we will lose the option to set a current overflow timeout and the default will be kept as 5 seconds. This can be replaced by a debugfs/sysfs entry if needed, I didn't include such a patch as we first need to decide which fix to take (between this and default y for CONFIG_TIDSPBRIDGE_WDT3[1]). [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg62119.html Omar Ramirez Luna (2): staging: tidspbridge: always compile dsp wdt code staging: tidspbridge: detect wdt3 feature at runtime drivers/staging/tidspbridge/Kconfig| 16 - drivers/staging/tidspbridge/core/tiomap3430.c | 10 +-- drivers/staging/tidspbridge/core/wdt.c | 24 +--- .../tidspbridge/include/dspbridge/_chnl_sm.h |4 --- 4 files changed, 8 insertions(+), 46 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/2] staging: tidspbridge: always compile dsp wdt code
In order to detect it at runtime, we need the code handling wdt
clock available at runtime to decide whether to enable or disable
based on the baseimage symbols. Default timeout has been set to 5
seconds.
Downside is that we will lose the option to set a custom timeout
for overflow, but than can be added (if needed) as part of debugfs.
Signed-off-by: Omar Ramirez omar.rami...@ti.com
---
drivers/staging/tidspbridge/Kconfig| 16 -
drivers/staging/tidspbridge/core/wdt.c | 24 +---
.../tidspbridge/include/dspbridge/_chnl_sm.h |4 ---
3 files changed, 1 insertions(+), 43 deletions(-)
diff --git a/drivers/staging/tidspbridge/Kconfig
b/drivers/staging/tidspbridge/Kconfig
index d660891..0dd479f 100644
--- a/drivers/staging/tidspbridge/Kconfig
+++ b/drivers/staging/tidspbridge/Kconfig
@@ -52,22 +52,6 @@ config TIDSPBRIDGE_CACHE_LINE_CHECK
This can lead to heap corruption. Say Y, to enforce the check for 128
byte alignment, buffers failing this check will be rejected.
-config TIDSPBRIDGE_WDT3
- bool Enable watchdog timer
- depends on TIDSPBRIDGE
- help
- WTD3 is managed by DSP and once it is enabled, DSP side bridge is in
- charge of refreshing the timer before overflow, if the DSP hangs MPU
- will caught the interrupt and try to recover DSP.
-
-config TIDSPBRIDGE_WDT_TIMEOUT
- int Watchdog timer timeout (in secs)
- depends on TIDSPBRIDGE TIDSPBRIDGE_WDT3
- default 5
- help
- Watchdog timer timeout value, after that time if the watchdog timer
- counter is not reset the wdt overflow interrupt will be triggered
-
config TIDSPBRIDGE_NTFY_PWRERR
bool Notify power errors
depends on TIDSPBRIDGE
diff --git a/drivers/staging/tidspbridge/core/wdt.c
b/drivers/staging/tidspbridge/core/wdt.c
index 2126f59..70055c8 100644
--- a/drivers/staging/tidspbridge/core/wdt.c
+++ b/drivers/staging/tidspbridge/core/wdt.c
@@ -25,8 +25,6 @@
#include dspbridge/host_os.h
-#ifdef CONFIG_TIDSPBRIDGE_WDT3
-
#define OMAP34XX_WDT3_BASE (L4_PER_34XX_BASE + 0x3)
static struct dsp_wdt_setting dsp_wdt;
@@ -84,7 +82,7 @@ int dsp_wdt_init(void)
void dsp_wdt_sm_set(void *data)
{
dsp_wdt.sm_wdt = data;
- dsp_wdt.sm_wdt-wdt_overflow = CONFIG_TIDSPBRIDGE_WDT_TIMEOUT;
+ dsp_wdt.sm_wdt-wdt_overflow = 5; /* in seconds */
}
@@ -128,23 +126,3 @@ void dsp_wdt_enable(bool enable)
clk_disable(dsp_wdt.fclk);
}
}
-
-#else
-void dsp_wdt_enable(bool enable)
-{
-}
-
-void dsp_wdt_sm_set(void *data)
-{
-}
-
-int dsp_wdt_init(void)
-{
- return 0;
-}
-
-void dsp_wdt_exit(void)
-{
-}
-#endif
-
diff --git a/drivers/staging/tidspbridge/include/dspbridge/_chnl_sm.h
b/drivers/staging/tidspbridge/include/dspbridge/_chnl_sm.h
index 6e7ab4f..cc95a18 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/_chnl_sm.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/_chnl_sm.h
@@ -99,14 +99,10 @@ struct shm {
struct opp_rqst_struct opp_request;
/* load monitor information structure */
struct load_mon_struct load_mon_info;
-#ifdef CONFIG_TIDSPBRIDGE_WDT3
/* Flag for WDT enable/disable F/I clocks */
u32 wdt_setclocks;
u32 wdt_overflow; /* WDT overflow time */
char dummy[176];/* padding to 256 byte boundary */
-#else
- char dummy[184];/* padding to 256 byte boundary */
-#endif
u32 shm_dbg_var[64];/* shared memory debug variables */
};
--
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
[RFC PATCH 2/2] staging: tidspbridge: detect wdt3 feature at runtime
In order to detect WDT feature on the dsp code, we need to
find the symbol used to enable it inside the baseimage.
This should fix the warning comming from L3 driver:
WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:161 omap3_l3_app_irq...
In-band Error seen by IVA_SS at address 0
...
That occurs because the dsp tries to access wdt3 registers when the clock
for those registers is not enabled.
Reported-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 670de0a..7862513 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -383,6 +383,7 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
u32 clk_cmd;
struct io_mgr *hio_mgr;
u32 ul_load_monitor_timer;
+ u32 wdt_en = 0;
struct omap_dsp_platform_data *pdata =
omap_dspbridge_dev-dev.platform_data;
@@ -594,9 +595,12 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
if (!wait_for_start(dev_context, dw_sync_addr))
status = -ETIMEDOUT;
- /* Start wdt */
- dsp_wdt_sm_set((void *)ul_shm_base);
- dsp_wdt_enable(true);
+ dev_get_symbol(dev_context-dev_obj, _WDT_enable, wdt_en);
+ if (wdt_en) {
+ /* Start wdt */
+ dsp_wdt_sm_set((void *)ul_shm_base);
+ dsp_wdt_enable(true);
+ }
status = dev_get_io_mgr(dev_context-dev_obj, hio_mgr);
if (hio_mgr) {
--
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 v2] OMAPDSS: HDMI: Add M2 divider while calculating clkout
From: Mythri P K mythr...@ti.com Add M2 divider in the equation to calculate regm and regmf. Formula for calculating: Output clock on digital core domain: CLKOUT = (M / (N+1))*CLKINP*(1/M2) Internal oscillator output clock on internal LDO domain: CLKDCOLDO = (M / (N+1))*CLKINP The current code when allows variable M2 values as input ignores using M2 divider values in calculation of regm and regmf. so fix it by using M2 in calculation although the default value for M2 is 1. Signed-off-by: Mythri P K mythr...@ti.com --- drivers/video/omap2/dss/hdmi.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c index 92a6679..9185630 100644 --- a/drivers/video/omap2/dss/hdmi.c +++ b/drivers/video/omap2/dss/hdmi.c @@ -256,24 +256,24 @@ static void hdmi_compute_pll(struct omap_dss_device *dssdev, int phy, refclk = clkin / pi-regn; - /* -* multiplier is pixel_clk/ref_clk -* Multiplying by 100 to avoid fractional part removal -*/ - pi-regm = (phy * 100 / (refclk)) / 100; - if (dssdev-clocks.hdmi.regm2 == 0) pi-regm2 = HDMI_DEFAULT_REGM2; else pi-regm2 = dssdev-clocks.hdmi.regm2; /* +* multiplier is pixel_clk/ref_clk +* Multiplying by 100 to avoid fractional part removal +*/ + pi-regm = (phy * 100 * pi-regm2 / (refclk)) / 100; + + /* * fractional multiplier is remainder of the difference between * multiplier and actual phy(required pixel clock thus should be * multiplied by 2^18(262144) divided by the reference clock */ - mf = (phy - pi-regm * refclk) * 262144; - pi-regmf = mf / (refclk); + mf = (phy - pi-regm / pi-regm2 * refclk) * 262144; + pi-regmf = pi-regm2 * mf / refclk; /* * Dcofreq should be set to 1 if required pixel clock -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] ARM: OMAP4: cminst: Add boot time __init function for cminst
On Wed, Feb 15, 2012 at 02:41:32, Peter Korsgaard wrote:
Vaibhav == Vaibhav Hiremath hvaib...@ti.com writes:
Vaibhav AM33xx CM module is closer to OMAP4 CM module, and
Vaibhav in order to reuse cminst api's we have to address
Vaibhav some of the differences like, base addresses and partitions.
Vaibhav Unlike OMAP4 CM, AM33xx doesn't have any partitions and
Vaibhav maintains only single partition.
Vaibhav So, in order to reuse the existing OMAP4 cminst code
Vaibhav for AM33xx this patch adds,
Vaibhav - Boot time __init function, to initialize _cm_bases
Vaibhav based on cpu_is_xxx
Vaibhav - Instead of maintaining phy addr for CM partition
Vaibhav in _cm_bases[] table and then changing it to virt addr,
Vaibhav directly maintain respective virt addr.
Vaibhav @@ -103,19 +106,19 @@ static bool _is_module_ready(u8 part, u16
inst, s16 cdoffs, u16 clkctrl_offs)
Vaibhav /* Read a register in a CM instance */
Vaibhav u32 omap4_cminst_read_inst_reg(u8 part, s16 inst, u16 idx)
Vaibhav {
Vaibhav - BUG_ON(part = OMAP4_MAX_PRCM_PARTITIONS ||
Vaibhav + BUG_ON(part = max_cm_partitions ||
Vaibhavpart == OMAP4430_INVALID_PRCM_PARTITION ||
How about dropping the OMAP4430_ prefix here as it's no longer 4430 specific?
Peter,
You could be right here, from this patch perspective, this change doesn't make
sense.
But at the first place I am quite not sure, why this has been named as
OMAP4430_? Vs some macros are named as OMAP4_.
So first we need to understand why it has been named this way,
may be Paul Walmsley can comment on this. He is original author of this
file.
Thanks,
Vaibhav
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ARM: OMAP: am33xx: Hook-up am33xx support to existing cm code
On Wed, Feb 15, 2012 at 02:25:34, Peter Korsgaard wrote:
Vaibhav == Vaibhav Hiremath hvaib...@ti.com writes:
Vaibhav Reuse existing omap4 cminst code for am33xx device,
Vaibhav add separate cm base table for am33xx device and initialize
Vaibhav it during __init for future use.
Vaibhav Also, since cpu_is_omap34xx() check is true for am33xx family of
Vaibhav devices, we must change the order of cpu_is_ check, so first
Vaibhav check for cpu_is_am33xx() to follow right execution path.
Vaibhav if (cpu_is_omap44xx()) {
Vaibhav _cm_bases = omap44xx_cm_bases;
Vaibhav max_cm_partitions = ARRAY_SIZE(omap44xx_cm_bases);
Vaibhav + } else if (cpu_is_am33xx()) {
Vaibhav + _cm_bases =am33xx_cm_bases;
Space after '='.
Oops...Will fix it.
Vaibhav +++ b/arch/arm/mach-omap2/omap_hwmod.c
Vaibhav @@ -737,7 +737,7 @@ static void _disable_optional_clocks(struct
omap_hwmod *oh)
Vaibhav static void _enable_module(struct omap_hwmod *oh)
Vaibhav {
Vaibhav /* The module mode does not exist prior OMAP4 */
Vaibhav - if (cpu_is_omap24xx() || cpu_is_omap34xx())
Vaibhav + if (!cpu_is_omap44xx() !cpu_is_am33xx())
Maybe update the comment as well?
Will update accordingly and submit the next version.
Vaibhav /* The module mode does not exist prior OMAP4 */
Vaibhav - if (!cpu_is_omap44xx())
Vaibhav + if (!cpu_is_omap44xx() !cpu_is_am33xx())
Vaibhav return -EINVAL;
Here as well.
Otherwise it looks good.
Acked-by: Peter Korsgaard jac...@sunsite.dk
Thanks
Vaibhav
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3.3 v2] OMAP4: PRM: fix build breakage when CONFIG_OF is not defined
Hi Tony, On Tue, 2012-02-14 at 12:38 -0800, Tony Lindgren wrote: * Luciano Coelho coe...@ti.com [120208 02:43]: Since 3.3-rc1, prm44xx.c build breaks if CONFIG_OF is not set: arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function) make[1]: *** [arch/arm/mach-omap2/prm44xx.o] Error 1 This is because of a missing include, which is added indirectly if CONFIG_OF is defined. This problem was introduced in commit 2f31b51 (ARM: OMAP4: PRM: use PRCM interrupt handler). Cc: Tero Kristo t-kri...@ti.com Signed-off-by: Luciano Coelho coe...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com A similar patch should be already in mainline kernel queued by Russell. Right, someone pointed this out to me after I sent the two patches. Sorry for the trouble, I should have looked more carefully before jumping in to fix this stuff. ;) -- Cheers, Luca. -- To unsubscribe from this list: send the line unsubscribe 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] usb: host: ehci: allow ehci_* symbols to be unused
not all platforms will use all of those ehci_*
symbols on their hc_driver structure. Sometimes
we might need to provide a modified version of
a certain method or not provide it at all, as is
the case with OMAPs which don't support port handoff
feature.
Whenever we compile a kernel for an OMAP board with
EHCI enabled, we get compile warnings:
drivers/usb/host/ehci-hub.c:1079: warning: 'ehci_relinquish_port' \
defined but not used
drivers/usb/host/ehci-hub.c:1088: warning: 'ehci_port_handed_over' \
defined but not used
In order to cleanup those warnings, we're adding
__maybe_unused annotation to those functions.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Changes from v1:
- only add __maybe_used to relinquish_port, port_handed_over
and port_change
drivers/usb/host/ehci-hub.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 77bbb23..01011dd 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -107,7 +107,7 @@ static void ehci_handover_companion_ports(struct ehci_hcd
*ehci)
ehci-owned_ports = 0;
}
-static int ehci_port_change(struct ehci_hcd *ehci)
+static int __maybe_unused ehci_port_change(struct ehci_hcd *ehci)
{
int i = HCS_N_PORTS(ehci-hcs_params);
@@ -1076,7 +1076,8 @@ error_exit:
return retval;
}
-static void ehci_relinquish_port(struct usb_hcd *hcd, int portnum)
+static void __maybe_unused ehci_relinquish_port(struct usb_hcd *hcd,
+ int portnum)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
@@ -1085,7 +1086,8 @@ static void ehci_relinquish_port(struct usb_hcd *hcd, int
portnum)
set_owner(ehci, --portnum, PORT_OWNER);
}
-static int ehci_port_handed_over(struct usb_hcd *hcd, int portnum)
+static int __maybe_unused ehci_port_handed_over(struct usb_hcd *hcd,
+ int portnum)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
u32 __iomem *reg;
--
1.7.9
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP4: cminst: Add boot time __init function for cminst
Vaibhav == Hiremath, Vaibhav hvaib...@ti.com writes: Hi, Vaibhav - BUG_ON(part = OMAP4_MAX_PRCM_PARTITIONS || Vaibhav + BUG_ON(part = max_cm_partitions || Vaibhav part == OMAP4430_INVALID_PRCM_PARTITION || How about dropping the OMAP4430_ prefix here as it's no longer 4430 specific? Vaibhav Peter, Vaibhav You could be right here, from this patch perspective, this Vaibhav change doesn't make sense. Vaibhav But at the first place I am quite not sure, why this has been Vaibhav named as OMAP4430_? Vs some macros are named as OMAP4_. Vaibhav So first we need to understand why it has been named this way, Vaibhav may be Paul Walmsley can comment on this. He is original Vaibhav author of this file. As I read it, it doesn't have anything to do with any specific hardware, it's just to catch bugs when people forget to initialize the structure field: arch/arm/mach-omap2/prcm44xx.h: /* * OMAP4 PRCM partition IDs * * The numbers and order are arbitrary, but 0 is reserved for the * 'invalid' partition in case someone forgets to add a * .prcm_partition field. */ #define OMAP4430_INVALID_PRCM_PARTITION 0 -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe 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] OMAPDSS: HDMI: Add M2 divider while calculating clkout
On Wed, 2012-02-15 at 11:20 +0530, mythr...@ti.com wrote: From: Mythri P K mythr...@ti.com Add M2 divider in the equation to calculate regm and regmf. Formula for calculating: Output clock on digital core domain: CLKOUT = (M / (N+1))*CLKINP*(1/M2) Internal oscillator output clock on internal LDO domain: CLKDCOLDO = (M / (N+1))*CLKINP The current code when allows variable M2 values as input ignores using M2 divider values in calculation of regm and regmf. so fix it by using M2 in calculation although the default value for M2 is 1. Signed-off-by: Mythri P K mythr...@ti.com --- drivers/video/omap2/dss/hdmi.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c index 92a6679..9185630 100644 --- a/drivers/video/omap2/dss/hdmi.c +++ b/drivers/video/omap2/dss/hdmi.c @@ -256,24 +256,24 @@ static void hdmi_compute_pll(struct omap_dss_device *dssdev, int phy, refclk = clkin / pi-regn; - /* - * multiplier is pixel_clk/ref_clk - * Multiplying by 100 to avoid fractional part removal - */ - pi-regm = (phy * 100 / (refclk)) / 100; - if (dssdev-clocks.hdmi.regm2 == 0) pi-regm2 = HDMI_DEFAULT_REGM2; else pi-regm2 = dssdev-clocks.hdmi.regm2; /* + * multiplier is pixel_clk/ref_clk + * Multiplying by 100 to avoid fractional part removal + */ + pi-regm = (phy * 100 * pi-regm2 / (refclk)) / 100; No need for parenthesis around refclk. + + /* * fractional multiplier is remainder of the difference between * multiplier and actual phy(required pixel clock thus should be * multiplied by 2^18(262144) divided by the reference clock */ - mf = (phy - pi-regm * refclk) * 262144; - pi-regmf = mf / (refclk); + mf = (phy - pi-regm / pi-regm2 * refclk) * 262144; What kind of values does regm have? If the regm2 is something else than 1, and regm is relatively small value, it's quite easy to lose precision there. Would it be better to have: pi-regm * refclk / pi-regm2 Tomi signature.asc Description: This is a digitally signed message part
