[PATCH v2 0/4] OMAP: iommu: hwmod support and runtime PM
Introduced hwmod support for OMAP3 (iva, isp) and OMAP4 (ipu, dsp), along with the corresponding runtime PM routines to deassert reset lines, enable/disable clocks and configure sysc registers. v2: - Added oh reset info to assert/deassert mmu reset lines. - Addressed previous comments on v1 http://www.spinics.net/lists/arm-kernel/msg103271.html Due to compatibility an ifdef needs to be propagated (previously on iommu resource info) to hwmod data in OMAP3, so users of iommu and tidspbridge can avoid issues of two modules managing mmu data/irqs/resets; this until tidspbridge can be safely migrated to iommu framework. Omar Ramirez Luna (4): OMAP3/4: iommu: migrate to hwmod framework OMAP3/4: iommu: adapt to runtime pm OMAP3: hwmod data: Add mmu data for iva and isp OMAP4: hwmod data: add mmu hwmod for ipu and dsp arch/arm/mach-omap2/iommu2.c | 36 -- arch/arm/mach-omap2/omap-iommu.c | 161 ++-- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 135 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 156 +-- arch/arm/plat-omap/include/plat/iommu.h| 14 ++- arch/arm/plat-omap/include/plat/iommu2.h |2 - arch/arm/plat-omap/iommu.c | 50 - 7 files changed, 344 insertions(+), 210 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 v2 1/4] OMAP3: hwmod data: add mmu data for iva and isp
Add mmu hwmod data for iva and isp.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 135
arch/arm/plat-omap/include/plat/iommu.h| 10 ++
2 files changed, 145 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index e2792cf..90eebee 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -27,6 +27,7 @@
#include plat/mcbsp.h
#include plat/mcspi.h
#include plat/dmtimer.h
+#include plat/iommu.h
#include omap_hwmod_common_data.h
@@ -3332,6 +,134 @@ static struct omap_hwmod omap34xx_mcspi4 = {
};
/*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig mmu_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_mmu_hwmod_class = {
+ .name = mmu,
+ .sysc = mmu_sysc,
+};
+
+/* isp mmu */
+
+static struct omap_mmu_dev_attr isp_mmu_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 8,
+};
+
+static struct omap_hwmod omap3xxx_isp_mmu_hwmod;
+static struct omap_hwmod_irq_info omap3xxx_isp_mmu_irqs[] = {
+ { .irq = 24 },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_isp_mmu_addrs[] = {
+ {
+ .pa_start = 0x480bd400,
+ .pa_end = 0x480bd47f,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+/* l4_core - isp mmu */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__isp_mmu = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_isp_mmu_hwmod,
+ .addr = omap3xxx_isp_mmu_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_isp_mmu_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* isp mmu slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_isp_mmu_slaves[] = {
+ omap3xxx_l4_core__isp_mmu,
+};
+
+static struct omap_hwmod omap3xxx_isp_mmu_hwmod = {
+ .name = isp_mmu,
+ .class = omap3xxx_mmu_hwmod_class,
+ .mpu_irqs = omap3xxx_isp_mmu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_isp_mmu_irqs),
+ .main_clk = cam_ick,
+ .dev_attr = isp_mmu_dev_attr,
+ .slaves = omap3xxx_isp_mmu_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_isp_mmu_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST,
+};
+
+/* iva mmu */
+
+static struct omap_mmu_dev_attr iva_mmu_dev_attr = {
+ .da_start = 0x1100,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap3xxx_iva_mmu_hwmod;
+static struct omap_hwmod_irq_info omap3xxx_iva_mmu_irqs[] = {
+ { .irq = 28 },
+};
+
+static struct omap_hwmod_rst_info omap3xxx_iva_mmu_resets[] = {
+ { .name = mmu, .rst_shift = 1, .st_shift = 9 },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_iva_mmu_addrs[] = {
+ {
+ .pa_start = 0x5d00,
+ .pa_end = 0x5d7f,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+/* l3_main - iva mmu */
+static struct omap_hwmod_ocp_if omap3xxx_l3_main__iva_mmu = {
+ .master = omap3xxx_l3_main_hwmod,
+ .slave = omap3xxx_iva_mmu_hwmod,
+ .addr = omap3xxx_iva_mmu_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_iva_mmu_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* iva mmu slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_iva_mmu_slaves[] = {
+ omap3xxx_l3_main__iva_mmu,
+};
+
+static struct omap_hwmod omap3xxx_iva_mmu_hwmod = {
+ .name = iva_mmu,
+ .class = omap3xxx_mmu_hwmod_class,
+ .mpu_irqs = omap3xxx_iva_mmu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_iva_mmu_irqs),
+ .rst_lines = omap3xxx_iva_mmu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap3xxx_iva_mmu_resets),
+ .main_clk = iva2_ck,
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430_IVA2_MOD,
+ },
+ },
+ .dev_attr = iva_mmu_dev_attr,
+ .slaves = omap3xxx_iva_mmu_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_iva_mmu_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST | HWMOD_INIT_NO_RESET,
+};
+
+/*
* usbhsotg
*/
static
[PATCH v2 3/4] OMAP3/4: iommu: migrate to hwmod framework
Use hwmod data and device attributes to build and register an
omap device for iommu driver.
Now unused, remove platform device and resource data, handling
of sysconfig register for softreset purposes; and add device
latency in preparation for runtime PM.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/iommu2.c| 19
arch/arm/mach-omap2/omap-iommu.c| 162 ++-
arch/arm/plat-omap/include/plat/iommu.h |2 +-
3 files changed, 33 insertions(+), 150 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index adb083e..a22d812 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -32,12 +32,8 @@
#define MMU_SYS_IDLE_SMART (2 MMU_SYS_IDLE_SHIFT)
#define MMU_SYS_IDLE_MASK (3 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_SOFTRESET (1 1)
#define MMU_SYS_AUTOIDLE 1
-/* SYSSTATUS */
-#define MMU_SYS_RESETDONE 1
-
/* IRQSTATUS IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 4)
#define MMU_IRQ_TABLEWALKFAULT (1 3)
@@ -88,7 +84,6 @@ static void __iommu_set_twl(struct iommu *obj, bool on)
static int omap2_iommu_enable(struct iommu *obj)
{
u32 l, pa;
- unsigned long timeout;
if (!obj-iopgd || !IS_ALIGNED((u32)obj-iopgd, SZ_16K))
return -EINVAL;
@@ -97,20 +92,6 @@ static int omap2_iommu_enable(struct iommu *obj)
if (!IS_ALIGNED(pa, SZ_16K))
return -EINVAL;
- iommu_write_reg(obj, MMU_SYS_SOFTRESET, MMU_SYSCONFIG);
-
- timeout = jiffies + msecs_to_jiffies(20);
- do {
- l = iommu_read_reg(obj, MMU_SYSSTATUS);
- if (l MMU_SYS_RESETDONE)
- break;
- } while (!time_after(jiffies, timeout));
-
- if (!(l MMU_SYS_RESETDONE)) {
- dev_err(obj-dev, can't take mmu out of reset\n);
- return -ENODEV;
- }
-
l = iommu_read_reg(obj, MMU_REVISION);
dev_info(obj-dev, %s: version %d.%d\n, obj-name,
(l 4) 0xf, l 0xf);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 3fc5dc7..564a078 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -14,149 +14,51 @@
#include plat/iommu.h
#include plat/irqs.h
-
-struct iommu_device {
- resource_size_t base;
- int irq;
- struct iommu_platform_data pdata;
- struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
- {
- .base = 0x480bd400,
- .irq = 24,
- .pdata = {
- .name = isp,
- .nr_tlb_entries = 8,
- .clk_name = cam_ick,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
- {
- .base = 0x5d00,
- .irq = 28,
- .pdata = {
- .name = iva2,
- .nr_tlb_entries = 32,
- .clk_name = iva2_ck,
- .da_start = 0x1100,
- .da_end = 0xF000,
- },
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+
+static struct omap_device_pm_latency iommu_latencies[] = {
+ [0] = {
+ .activate_func = omap_device_enable_hwmods,
+ .deactivate_func = omap_device_idle_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST
},
-#endif
};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev NULL
-#endif
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
- {
- .base = OMAP4_MMU1_BASE,
- .irq = OMAP44XX_IRQ_DUCATI_MMU,
- .pdata = {
- .name = ducati,
- .nr_tlb_entries = 32,
- .clk_name = ducati_ick,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
-#if defined(CONFIG_MPU_TESLA_IOMMU)
- {
- .base = OMAP4_MMU2_BASE,
- .irq = INT_44XX_DSP_MMU,
- .pdata = {
- .name = tesla,
- .nr_tlb_entries = 32,
- .clk_name = tesla_ick,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
-#endif
-};
-#define NR_OMAP4_IOMMU_DEVICES ARRAY_SIZE(omap4_devices)
-static struct platform_device *omap4_iommu_pdev[NR_OMAP4_IOMMU_DEVICES];
-#else
-#define
[PATCH v2 4/4] OMAP3/4: iommu: adapt to runtime pm
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations, reset and sysconfig
handling.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/iommu2.c | 17 --
arch/arm/mach-omap2/omap-iommu.c |1 -
arch/arm/plat-omap/include/plat/iommu.h |2 -
arch/arm/plat-omap/include/plat/iommu2.h |2 -
arch/arm/plat-omap/iommu.c | 50 ++
5 files changed, 23 insertions(+), 49 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index a22d812..89821d7 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -25,15 +25,6 @@
*/
#define IOMMU_ARCH_VERSION 0x0011
-/* SYSCONF */
-#define MMU_SYS_IDLE_SHIFT 3
-#define MMU_SYS_IDLE_FORCE (0 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_NONE (1 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_SMART (2 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_MASK (3 MMU_SYS_IDLE_SHIFT)
-
-#define MMU_SYS_AUTOIDLE 1
-
/* IRQSTATUS IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 4)
#define MMU_IRQ_TABLEWALKFAULT (1 3)
@@ -96,11 +87,6 @@ static int omap2_iommu_enable(struct iommu *obj)
dev_info(obj-dev, %s: version %d.%d\n, obj-name,
(l 4) 0xf, l 0xf);
- l = iommu_read_reg(obj, MMU_SYSCONFIG);
- l = ~MMU_SYS_IDLE_MASK;
- l |= (MMU_SYS_IDLE_SMART | MMU_SYS_AUTOIDLE);
- iommu_write_reg(obj, l, MMU_SYSCONFIG);
-
iommu_write_reg(obj, pa, MMU_TTB);
__iommu_set_twl(obj, true);
@@ -114,7 +100,6 @@ static void omap2_iommu_disable(struct iommu *obj)
l = ~MMU_CNTL_MASK;
iommu_write_reg(obj, l, MMU_CNTL);
- iommu_write_reg(obj, MMU_SYS_IDLE_FORCE, MMU_SYSCONFIG);
dev_dbg(obj-dev, %s is shutting down\n, obj-name);
}
@@ -240,8 +225,6 @@ static ssize_t omap2_iommu_dump_ctx(struct iommu *obj, char
*buf, ssize_t len)
char *p = buf;
pr_reg(REVISION);
- pr_reg(SYSCONFIG);
- pr_reg(SYSSTATUS);
pr_reg(IRQSTATUS);
pr_reg(IRQENABLE);
pr_reg(WALKING_ST);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 564a078..37a000c 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -33,7 +33,6 @@ static int omap_iommu_dev_init(struct omap_hwmod *oh, void
*unused)
static int i;
pdata.name = oh-name;
- pdata.clk_name = oh-main_clk;
pdata.nr_tlb_entries = a-nr_tlb_entries;
pdata.da_start = a-da_start;
pdata.da_end = a-da_end;
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 60f7c77..1ee01a9 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -28,7 +28,6 @@ struct iotlb_entry {
struct iommu {
const char *name;
struct module *owner;
- struct clk *clk;
void __iomem*regbase;
struct device *dev;
void*isr_priv;
@@ -114,7 +113,6 @@ struct omap_mmu_dev_attr {
struct iommu_platform_data {
const char *name;
- const char *clk_name;
int nr_tlb_entries;
u32 da_start;
u32 da_end;
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h
b/arch/arm/plat-omap/include/plat/iommu2.h
index 10ad05f..0cd475e 100644
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ b/arch/arm/plat-omap/include/plat/iommu2.h
@@ -19,8 +19,6 @@
* MMU Register offsets
*/
#define MMU_REVISION 0x00
-#define MMU_SYSCONFIG 0x10
-#define MMU_SYSSTATUS 0x14
#define MMU_IRQSTATUS 0x18
#define MMU_IRQENABLE 0x1c
#define MMU_WALKING_ST 0x40
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index e3eb038..510b5bb 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -16,8 +16,8 @@
#include linux/slab.h
#include linux/interrupt.h
#include linux/ioport.h
-#include linux/clk.h
#include linux/platform_device.h
+#include linux/pm_runtime.h
#include asm/cacheflush.h
@@ -107,11 +107,13 @@ static int iommu_enable(struct iommu *obj)
if (!arch_iommu)
return -ENODEV;
- clk_enable(obj-clk);
+ pm_runtime_enable(obj-dev);
+ pm_runtime_get_sync(obj-dev);
err = arch_iommu-enable(obj);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
+
return err;
}
@@ -120,11 +122,12 @@ static void iommu_disable(struct iommu *obj)
if (!obj)
return;
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
arch_iommu-disable(obj);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
+ pm_runtime_disable(obj-dev);
}
/*
@@ -247,7 +250,7 @@ int load_iotlb_entry(struct iommu *obj, struct iotlb_entry
*e)
[PATCH v2 2/4] OMAP4: hwmod data: add mmu hwmod for ipu and dsp
Add mmu hwmod data for ipu and dsp.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 156 +--
1 files changed, 144 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7dbcdf7..149d694 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -27,6 +27,7 @@
#include plat/mcspi.h
#include plat/mcbsp.h
#include plat/mmc.h
+#include plat/iommu.h
#include omap_hwmod_common_data.h
@@ -990,10 +991,6 @@ static struct omap_hwmod_irq_info omap44xx_dsp_irqs[] = {
{ .irq = 28 + OMAP44XX_IRQ_GIC_START },
};
-static struct omap_hwmod_rst_info omap44xx_dsp_resets[] = {
- { .name = mmu_cache, .rst_shift = 1 },
-};
-
static struct omap_hwmod_rst_info omap44xx_dsp_c0_resets[] = {
{ .name = dsp, .rst_shift = 0 },
};
@@ -1045,8 +1042,6 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
.class = omap44xx_dsp_hwmod_class,
.mpu_irqs = omap44xx_dsp_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dsp_irqs),
- .rst_lines = omap44xx_dsp_resets,
- .rst_lines_cnt = ARRAY_SIZE(omap44xx_dsp_resets),
.main_clk = dsp_fck,
.prcm = {
.omap4 = {
@@ -2323,10 +2318,6 @@ static struct omap_hwmod_rst_info
omap44xx_ipu_c1_resets[] = {
{ .name = cpu1, .rst_shift = 1 },
};
-static struct omap_hwmod_rst_info omap44xx_ipu_resets[] = {
- { .name = mmu_cache, .rst_shift = 2 },
-};
-
/* ipu master ports */
static struct omap_hwmod_ocp_if *omap44xx_ipu_masters[] = {
omap44xx_ipu__l3_main_2,
@@ -2380,8 +2371,6 @@ static struct omap_hwmod omap44xx_ipu_hwmod = {
.class = omap44xx_ipu_hwmod_class,
.mpu_irqs = omap44xx_ipu_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_ipu_irqs),
- .rst_lines = omap44xx_ipu_resets,
- .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_resets),
.main_clk = ipu_fck,
.prcm = {
.omap4 = {
@@ -3711,6 +3700,145 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
};
/*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig mmu_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_mmu_hwmod_class = {
+ .name = mmu,
+ .sysc = mmu_sysc,
+};
+
+/* ipu mmu */
+
+static struct omap_mmu_dev_attr ipu_mmu_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_ipu_mmu_hwmod;
+static struct omap_hwmod_irq_info omap44xx_ipu_mmu_irqs[] = {
+ { .irq = 100 + OMAP44XX_IRQ_GIC_START, },
+};
+
+static struct omap_hwmod_rst_info omap44xx_ipu_mmu_resets[] = {
+ { .name = mmu_cache, .rst_shift = 2 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_ipu_mmu_addrs[] = {
+ {
+ .pa_start = 0x55082000,
+ .pa_end = 0x550820ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+/* l3_main_1 - ipu mmu */
+static struct omap_hwmod_ocp_if omap44xx_l3_main_1__ipu_mmu = {
+ .master = omap44xx_l3_main_1_hwmod,
+ .slave = omap44xx_ipu_mmu_hwmod,
+ .addr = omap44xx_ipu_mmu_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* ipu mmu slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_ipu_mmu_slaves[] = {
+ omap44xx_l3_main_1__ipu_mmu,
+};
+
+static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
+ .name = ipu_mmu,
+ .class = omap44xx_mmu_hwmod_class,
+ .mpu_irqs = omap44xx_ipu_mmu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_irqs),
+ .rst_lines = omap44xx_ipu_mmu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
+ .main_clk = ipu_fck,
+ .prcm = {
+ .omap4 = {
+ .rstctrl_reg = OMAP4430_RM_DUCATI_RSTCTRL,
+ },
+ },
+ .slaves = omap44xx_ipu_mmu_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_slaves),
+ .dev_attr = ipu_mmu_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .flags = HWMOD_INIT_NO_RESET,
+};
+
+/* dsp mmu */
+
+static struct omap_mmu_dev_attr dsp_mmu_dev_attr = {
+ .da_start = 0x0,
+
Problem with DSS clocks accessing registers
Hi Kevin, Paul, We currently have a small problem with OMAP4 DSS. When we enable the DSS clocks, it seems that the DSS registers are not always accessible right after the clock enable. I understood that on OMAP4 the clock framework doesn't guarantee that the registers are accessible after enabling clocks, and pm_runtime will handle this. Is this correct? I have made a small hack fix for this. I added udelay(10) in the DSS code which enables the clocks and this seem to remove the problem. The delay is only called when DSS thinks the clocks have been off, so in practice the delay shouldn't be visible. Is this fix acceptable for now, until we get pm_runtime support to DSS? 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 v3 0/9] OMAP4 : DSS2 : HDMI support on OMAP4
On Fri, 2011-03-04 at 01:48 -0600, K, Mythri P wrote: Adding HDMI support on OMAP4. HDMI is a driver that is similar to the VENC or the DSI driver to support HDMI/DVI sink device. snip 1. v10 of omap2,3 hwmod DSS adaptation: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42914.html 2. v3 of OMAP2PLUS: DSS: Generalize clock names http://www.mail-archive.com/linux-omap@vger.kernel.org/msg43338.html 3. v3 of OMAP4: hwmod DSS support: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg43177.html 4. OMAP: DSS2: Adding dss_features for independent core clk divider https://patchwork.kernel.org/patch/529561/ 5. OMAP2PLUS-DSS2-Make-members-of-dss_clk_source-generic I believe all these are now in DSS2 tree's master branch, so can you rebase the next version on top of the master branch? 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 1/1] omap3: Save and restore CM_AUTOIDLE_PLL across off mode
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Saturday, March 05, 2011 4:16 AM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 1/1] omap3: Save and restore CM_AUTOIDLE_PLL across
off mode
Hello Sanjeev,
On Thu, 10 Feb 2011, Sanjeev Premi wrote:
As per commit bb33cc58, ROM code is expected to restore
context related to CORE domain. As part of this change,
CM_AUTOIDLE_PLL is neither saved nor restored.
... by Linux.
[sp] Yes.
This results in loosing the value of AUTO_PERIPH_DPLL.
A few questions:
- Is ROM code supposed to restore this register?
[sp] Going by the description of the commit message I referenced, it
It appears to be the case. I am yet to get official confirmation
from the ROM code team (usually takes quite long); but all
experiments (i put them in patch 0/1) suggest so.
- Is there a documented list of which registers/bitfields the ROM code
will and won't restore?
[sp] No that I am aware of; but yes I have already requested for same
since this issue was found.
- Are the entire contents of the register lost, or just AUTO_PERIPH_DPLL?
[sp] Just AUTO_PERIPH_DPLL.
The concern of setting the AUTOIDLE flag before the DPLL
is locked seems valid. Hence, the restoration of this
register is delayed until after the context of PER
domain is restored.
Could you explain a little more about this? Is there a hardware
limitation where AUTO_PERIPH_DPLL shouldn't be set unless the DPLL is
locked?
[sp] This is based on my understanding (and observation) that DPLL may
take longer to lock after resume. Now if the clock goes to AUTOIDLE
before it is locked; I am not sure what would be the consequences.
The patch has been verified on OMAP3EVM by checking value
of CM_AUTOIDLE_PLL register across the suspend/resume
sequence (using devmem) with flags sleep_while_idle and
enable_off_mode set to 1.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
[sp]
[snip]...[snip]
+/**
+ * Restore the contents of CM_AUTOIDLE_PLL register.
+ *
+ * The implementation below restores AUTO_CORE_DPLL as 'good'
redundancy.
I don't understand this part. Are the entire contents of the register
lost, or just the AUTO_PERIPH_DPLL field?
[sp] As put above, only AUTO_PERIPH_DPLL; but this is based on observation
not a *real specification*; I chose to set the AUTO_CORE_DPLL bit as
redundancy.
~sanjeev
+ */
+static void pll_mod_restore_autoidle(void)
+{
+ u32 ctx = stored_cm_autoidle_pll();
+ u32 val = omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE);
+
+ if (ctx OMAP3430_AUTO_CORE_DPLL_MASK)
+ val |= ctx OMAP3430_AUTO_CORE_DPLL_MASK;
+
+ if (ctx OMAP3430_AUTO_PERIPH_DPLL_MASK)
+ val |= ctx OMAP3430_AUTO_PERIPH_DPLL_MASK;
+
+ omap2_cm_write_mod_reg(val, PLL_MOD, CM_AUTOIDLE);
+}
+
[snip]...[snip]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] omap3: nand: report corrected ecc errors
On Mon, 2011-02-28 at 13:12 +0100, John Ogness wrote: From: John Ogness john.ogn...@linutronix.de The number of corrected ECC errors should be reported since other MTD systems make use of this information (such as UBI data scrubbing). Signed-off-by: John Ogness john.ogn...@linutronix.de --- Patch v2: o Patch against linux-next-20110225. o Added comments explaining return codes. Pushed to l2-mtd-2.6.git, thanks. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe 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 4/9] OMAP4 : DSS2 : HDMI: HDMI driver header file addition
On Fri, 2011-03-04 at 01:48 -0600, K, Mythri P wrote:
Adding the hdmi interface driver header file (hdmi.h) to the dss driver.
Register and timing declaration to be used by the corresponding c file
is added in this file.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.h | 444
1 files changed, 444 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/hdmi.h
snip
+struct hdmi_video_format {
+ enum hdmi_packing_mode packing_mode;
+ u32 y_res; /* Line per panel */
+ u32 x_res; /* pixel per line */
+};
+
+struct hdmi_video_interface {
+ int vsp;/* Vsync polarity */
+ int hsp;/* Hsync polarity */
+ int interlacing;
+ int tm; /* Timing mode */
+};
+
+struct hdmi_video_timing {
+ u32 hbp;
+ u32 hfp;
+ u32 hsw;
+ u32 vbp;
+ u32 vfp;
+ u32 vsw;
+};
+
+struct hdmi_config {
+ u16 ppl;/* pixel per line */
+ u16 lpp;/* line per panel */
+ u32 pixel_clock;
+ u16 hsw;/* Horizontal sync pulse width */
+ u16 hfp;/* Horizontal front porch */
+ u16 hbp;/* Horizontal back porch */
+ u16 vsw;/* Vertical sync pulse width */
+ u16 vfp;/* Vertical front porch */
+ u16 vbp;/* Vertical back porch */
+ u16 interlace;
+ u16 h_pol;
+ u16 v_pol;
+ u16 hdmi_dvi;
+ u16 video_format;
+};
I haven't really read through the hdmi code (as it doesn't apply to my
tree), but it looks quite strange to have multiple structs with
overlapping information. And then there's also the struct
omap_video_timings, which contains similar stuff.
So, could the hdmi_config use hdmi_video_timing, hdmi_video_interface
and hdmi_video_format structs? Can omap_video_timings be used here?
Should omap_video_timings be modified somehow to suit HDMI better?
+
+struct hdmi_cm {
+ int code;
+ int mode;
+};
+
+struct hdmi_irq_vector {
+ u8 pll_recal;
+ u8 pll_unlock;
+ u8 pll_lock;
+ u8 phy_disconnect;
+ u8 phy_connect;
+ u8 phy_short_5v;
+ u8 video_end_fr;
+ u8 video_vsync;
+ u8 fifo_sample_req;
+ u8 fifo_overflow;
+ u8 fifo_underflow;
+ u8 ocp_timeout;
+ u8 core;
+};
This struct is not used.
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] OMAP: DSS2: FEATURES: DSI PLL parameter cleanup
Hi,
On Monday 07 March 2011 01:24 PM, Valkeinen, Tomi wrote:
On Fri, 2011-03-04 at 05:03 -0600, Taneja, Archit wrote:
The DSI PLL parameters (regm, regn, regm_dispc, regm_dsi, fint) have different
fields and also different Max values on OMAP3 and OMAP4. Use dss features to
calculate the register fields and Max values based on current OMAP revision
Also, introduce a new function in dss_features dss_feat_get_param_range which
returns the maximum and minimum values supported by the parameter for
the current OMAP revision.
See comment about also in the last mail =). You are introducing a new
kind of dss feature as a sidenote. I think it should clearly be a
separate patch.
snip
+void dss_feat_get_param_range(enum dss_range_param param, int *min, int *max)
+{
+ *min = omap_current_dss_features-dss_params[param].min;
+ *max = omap_current_dss_features-dss_params[param].max;
This isn't right. Here you're using the param as index, but in the param
array itself the param is just part of the struct. So it's just luck
that the index is correct.
The param part of the struct is just for readability, and possibly more
thorough checking for later on.
The index isn't correct by luck, its mainly because during defining the
array, we fill it up in the sequence in which the enum is defined.
This is actually wrong with the reg fields and clock sources also...
I believe there was a way to give entries in an array by the index.
Something like:
static struct foo bar[] = {
[0] = { stuff },
[1] = { stuff },
};
I agree this is better , I didn't know we could use this.
In that solution it's not necessary to have the index in the struct
itself, like now.
Alternatively, with the current struct, we could iterate through the
array to find a matching id.
Yes, my earlier patch for dss features used a list and we iterated to
get the matching id, but that was bit of an overkill.
+}
+
/* DSS has_feature check */
bool dss_has_feature(enum dss_feat_id id)
{
diff --git a/drivers/video/omap2/dss/dss_features.h
b/drivers/video/omap2/dss/dss_features.h
index 3302247..78b51a9 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -52,6 +52,14 @@ enum dss_feat_reg_field {
FEAT_REG_HORIZONTALACCU,
FEAT_REG_VERTICALACCU,
FEAT_REG_DISPC_CLK_SWITCH,
+ FEAT_REG_DSIPLL_REGM,
+ FEAT_REG_DSIPLL_REGN,
+ FEAT_REG_DSIPLL_REGM_DISPC,
+ FEAT_REG_DSIPLL_REGM_DSI,
+};
+
+enum dss_range_param {
+ FEAT_DSI_FINT,
};
/* DSS Feature Functions */
@@ -63,6 +71,7 @@ enum omap_color_mode dss_feat_get_supported_color_modes(enum
omap_plane plane);
bool dss_feat_color_mode_supported(enum omap_plane plane,
enum omap_color_mode color_mode);
const char *dss_feat_get_clk_source_name(enum dss_clk_source id);
+void dss_feat_get_param_range(enum dss_range_param param, int *min, int *max);
Currently used only for fint, but if it's supposed to handle clock
rates, unsigned long instead of int could be better.
I was also thinking that we now have dss_feat_get_max_dss_fck(), which
is somewhat similar to this.
Could something like this work:
unsigned long dss_feat_get_param_min(enum dss_range_param param);
unsigned long dss_feat_get_param_max(enum dss_range_param param);
I agree. Should we remove the max_dss_fck patch since we are moving to
this approach?
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] omap2plus: Remove auto selection on PMICs
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, March 02, 2011 11:34 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap2plus: Remove auto selection on PMICs * Premi, Sanjeev pr...@ti.com [110226 00:27]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, February 25, 2011 11:47 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap2plus: Remove auto selection on PMICs * Sanjeev Premi pr...@ti.com [110223 04:11]: The current implementation almost assumes that only TWL4030/TWL5030/TWl6030 are (or can be) used with the OMAP processors. This is, however, not true. If selecting these on platforms that don't have twl causes problems the problem should be fixed. You can disable CONFIG_ARCH_OMAP2PLUS_TYPICAL, and then these don't get selected. [sp] But this means MUTLI_OMAP breaks. And same uImage won't run on the AM3517 EVM. If I remember, the problem is caused due to twl specific functions called even if it isn't present. And there is implicit assumption on TWL in most of code. Then let's fix that problem instead. The TWL functions should not get called (or at least they should not do anything) unless the TWL chip is there. [sp] Agree. Driver needs to be fixed. But, will take longer and AM35x will continue to suffer. Will start on this... [sp] I will be away from work for next week; may not be able to try this; but don't you think dependency on ARM is too generic? And this should still be fixed.. [sp] I haven't yet tried it myself. Need to clear lot of regular backlog before I can try this later this week. - depends on TWL4030_CORE ARM + depends on TWL4030_CORE (ARCH_OMAP3 || ARCH_OMAP4) Well in theory all the drivers should just build on whatever platform. I don't know if changing that really improves things, we should improve the driver instead. Note for example how the tps65010.c driver also builds on x86. That allows people doing Linux generic changes to build test those changes: [sp] Agree. But TPS6510 is far more generic PMIC than TWL4030 or others in the same family. Going by the argument, we should then be removing processor dependency altogether, i.e: - depends on TWL4030_CORE ARM + depends on TWL4030_CORE $git log --pretty=oneline drivers/mfd/tps65010.c 77b22897da093e80c40f03e8d83bf23e756b9fba mfd: Include linux/gpio.h instead of afdb32f2e463a195c104555ac9a8cdd39a2b6561 mfd: update workqueue usages fbae3fb1546e199ab0cd185348f8124411a1ca9d i2c: Remove all i2c_set_clientdata(clie f322d5f009743bfd92b47258ee997c889263 mfd: Fix dangling pointersRegards, ... So instead of breakage for the tps65010 driver we instead got the above changes compile tested as an extra bonus. 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 v3 5/9] OMAP4 : DSS2 : HDMI: HDMI driver header file addition
On Fri, 2011-03-04 at 01:48 -0600, K, Mythri P wrote:
Adding the hdmi interface driver header file (hdmi.h) to the dss driver.
Register and timing declaration to be used by the corresponding c file
is added in this file.
The subject and description are wrong. Always before sending patches do
a quick sanity check, by check the subjects, looking at the stats in the
intro letter, etc.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/Kconfig |8 +
drivers/video/omap2/dss/Makefile |1 +
drivers/video/omap2/dss/display.c |3 +
drivers/video/omap2/dss/dss.h | 31 +
drivers/video/omap2/dss/hdmi.c| 1332
+
drivers/video/omap2/dss/hdmi.h|5 +
6 files changed, 1380 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/hdmi.c
diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index db01473..7749ddb 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -60,6 +60,14 @@ config OMAP2_DSS_VENC
help
OMAP Video Encoder support for S-Video and composite TV-out.
+config OMAP2_DSS_HDMI
+ bool HDMI support
+ depends on ARCH_OMAP4
+default y
+ help
+ HDMI Interface. This adds the High Definition Multimedia Interface.
+ See http://www.hdmi.org/ for HDMI specification.
+
config OMAP2_DSS_SDI
bool SDI support
depends on ARCH_OMAP3
diff --git a/drivers/video/omap2/dss/Makefile
b/drivers/video/omap2/dss/Makefile
index 7db17b5..5998b69 100644
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -5,3 +5,4 @@ omapdss-$(CONFIG_OMAP2_DSS_RFBI) += rfbi.o
omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o
omapdss-$(CONFIG_OMAP2_DSS_SDI) += sdi.o
omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o
+omapdss-$(CONFIG_OMAP2_DSS_HDMI) += hdmi.o
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index e10b303..cbab61a 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -447,6 +447,9 @@ void dss_init_device(struct platform_device *pdev,
r = dsi_init_display(dssdev);
break;
#endif
+ case OMAP_DISPLAY_TYPE_HDMI:
+ r = hdmi_init_display(dssdev);
+ break;
default:
BUG();
}
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 004c782..5d4a7f6 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -168,6 +168,16 @@ struct dsi_clock_info {
bool use_dss2_fck;
};
+/* HDMI PLL structure */
+struct hdmi_pll_info {
+ u16 regn;
+ u16 regm;
+ u32 regmf;
+ u16 regm2;
+ u16 regsd;
+ u16 dcofreq;
+};
+
struct seq_file;
struct platform_device;
@@ -432,6 +442,27 @@ static inline void venc_uninit_platform_driver(void)
}
#endif
+/* HDMI */
+#ifdef CONFIG_OMAP2_DSS_HDMI
+int hdmi_init_platform_driver(void);
+void hdmi_uninit_platform_driver(void);
+int hdmi_init_display(struct omap_dss_device *dssdev);
+#else
+static inline int hdmi_init_display(struct omap_dss_device *dssdev)
+{
+ return 0;
+}
+static inline int hdmi_init_platform_driver(void)
+{
+ return 0;
+}
+static inline void hdmi_uninit_platform_driver(void)
+{
+}
+#endif
+int omapdss_hdmi_display_enable(struct omap_dss_device *dssdev);
+void omapdss_hdmi_display_disable(struct omap_dss_device *dssdev);
+
/* RFBI */
#ifdef CONFIG_OMAP2_DSS_RFBI
int rfbi_init_platform_driver(void);
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
new file mode 100644
index 000..a6f7936
--- /dev/null
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -0,0 +1,1332 @@
+/*
+ * hdmi.c
+ *
+ * HDMI interface DSS driver setting for TI's OMAP4 family of processor.
+ * Copyright (C) 2010-2011 Texas Instruments Incorporated -
http://www.ti.com/
+ * Authors: Yong Zhi
+ * Mythri pk mythr...@ti.com
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#define DSS_SUBSYS_NAME HDMI
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/err.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/mutex.h
+#include linux/delay.h
+#include linux/string.h
Re: [patch v3 3/3] arm: omap4: support pmu
On Fri, Mar 4, 2011 at 7:16 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
-Original Message-
From: tom.leim...@gmail.com [mailto:tom.leim...@gmail.com]
Sent: Thursday, March 03, 2011 4:24 PM
To: li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org; will.dea...@arm.com; Ming
Lei; Santosh Shilimkar; Woodruff Richard; Tony Lindgren; linux-
o...@vger.kernel.org
Subject: [patch v3 3/3] arm: omap4: support pmu
From: Ming Lei tom.leim...@gmail.com
This patch supports pmu irq routed from CTI, so
make pmu/perf working on OMAP4.
The idea is from Woodruff Richard in the disscussion
about Oprofile on Pandaboard / Omap4 on
pandabo...@googlegroups.com.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Woodruff Richard r-woodru...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Ming Lei tom.leim...@gmail.com
---
Looks good.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Great!
Acked-by: Jean Pihet j-pi...@ti.com
Thanks,
Jean
arch/arm/mach-omap2/devices.c | 82
+++-
arch/arm/plat-omap/include/plat/omap44xx.h | 2 +
2 files changed, 81 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-
omap2/devices.c
index d216976..d97bb5a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -22,6 +22,7 @@
#include asm/mach-types.h
#include asm/mach/map.h
#include asm/pmu.h
+#include asm/cti.h
#include plat/tc.h
#include plat/board.h
@@ -322,20 +323,95 @@ static struct resource omap3_pmu_resource = {
.flags = IORESOURCE_IRQ,
};
+static struct resource omap4_pmu_resource[] = {
+ {
+ .start = OMAP44XX_IRQ_CTI0,
+ .end = OMAP44XX_IRQ_CTI0,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = OMAP44XX_IRQ_CTI1,
+ .end = OMAP44XX_IRQ_CTI1,
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
static struct platform_device omap_pmu_device = {
.name = arm-pmu,
.id = ARM_PMU_DEVICE_CPU,
.num_resources = 1,
};
+static struct arm_pmu_platdata omap4_pmu_data;
+static struct cti omap4_cti[2];
+
+static void omap4_enable_cti(int irq)
+{
+ if (irq == OMAP44XX_IRQ_CTI0)
+ cti_enable(omap4_cti[0]);
+ else if (irq == OMAP44XX_IRQ_CTI1)
+ cti_enable(omap4_cti[1]);
+}
+
+static void omap4_disable_cti(int irq)
+{
+ if (irq == OMAP44XX_IRQ_CTI0)
+ cti_disable(omap4_cti[0]);
+ else if (irq == OMAP44XX_IRQ_CTI1)
+ cti_disable(omap4_cti[1]);
+}
+
+static irqreturn_t omap4_pmu_handler(int irq, void *dev,
irq_handler_t handler)
+{
+ if (irq == OMAP44XX_IRQ_CTI0)
+ cti_irq_ack(omap4_cti[0]);
+ else if (irq == OMAP44XX_IRQ_CTI1)
+ cti_irq_ack(omap4_cti[1]);
+
+ return handler(irq, dev);
+}
+
+static void omap4_configure_pmu_irq(void)
+{
+ void __iomem *base0;
+ void __iomem *base1;
+
+ base0 = ioremap(OMAP44XX_CTI0_BASE, SZ_4K);
+ base1 = ioremap(OMAP44XX_CTI1_BASE, SZ_4K);
+ if (!base0 !base1) {
+ pr_err(ioremap for OMAP4 CTI failed\n);
+ return;
+ }
+
+ /*configure CTI0 for pmu irq routing*/
+ cti_init(omap4_cti[0], base0, OMAP44XX_IRQ_CTI0, 6);
+ cti_unlock(omap4_cti[0]);
+ cti_map_trigger(omap4_cti[0], 1, 6, 2);
+
+ /*configure CTI1 for pmu irq routing*/
+ cti_init(omap4_cti[1], base1, OMAP44XX_IRQ_CTI1, 6);
+ cti_unlock(omap4_cti[1]);
+ cti_map_trigger(omap4_cti[1], 1, 6, 2);
+
+ omap4_pmu_data.handle_irq = omap4_pmu_handler;
+ omap4_pmu_data.enable_irq = omap4_enable_cti;
+ omap4_pmu_data.disable_irq = omap4_disable_cti;
+}
+
static void omap_init_pmu(void)
{
- if (cpu_is_omap24xx())
+ if (cpu_is_omap24xx()) {
omap_pmu_device.resource = omap2_pmu_resource;
- else if (cpu_is_omap34xx())
+ } else if (cpu_is_omap34xx()) {
omap_pmu_device.resource = omap3_pmu_resource;
- else
+ } else if (cpu_is_omap44xx()) {
+ omap_pmu_device.resource = omap4_pmu_resource;
+ omap_pmu_device.num_resources = 2;
+ omap_pmu_device.dev.platform_data = omap4_pmu_data;
+ omap4_configure_pmu_irq();
+ } else {
return;
+ }
platform_device_register(omap_pmu_device);
}
diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h
b/arch/arm/plat-omap/include/plat/omap44xx.h
index ea2b8a6..b127a16 100644
--- a/arch/arm/plat-omap/include/plat/omap44xx.h
+++ b/arch/arm/plat-omap/include/plat/omap44xx.h
@@ -57,5 +57,7 @@
#define OMAP44XX_HSUSB_OHCI_BASE (L4_44XX_BASE + 0x64800)
#define OMAP44XX_HSUSB_EHCI_BASE (L4_44XX_BASE + 0x64C00)
+#define OMAP44XX_CTI0_BASE 0x54148000
+#define
Re: [PATCH] OMAP: DSS2: FEATURES: DSI PLL parameter cleanup
On Mon, 2011-03-07 at 03:17 -0600, Taneja, Archit wrote:
Hi,
On Monday 07 March 2011 01:24 PM, Valkeinen, Tomi wrote:
On Fri, 2011-03-04 at 05:03 -0600, Taneja, Archit wrote:
The DSI PLL parameters (regm, regn, regm_dispc, regm_dsi, fint) have
different
fields and also different Max values on OMAP3 and OMAP4. Use dss features
to
calculate the register fields and Max values based on current OMAP revision
Also, introduce a new function in dss_features dss_feat_get_param_range
which
returns the maximum and minimum values supported by the parameter for
the current OMAP revision.
See comment about also in the last mail =). You are introducing a new
kind of dss feature as a sidenote. I think it should clearly be a
separate patch.
snip
+void dss_feat_get_param_range(enum dss_range_param param, int *min, int
*max)
+{
+ *min = omap_current_dss_features-dss_params[param].min;
+ *max = omap_current_dss_features-dss_params[param].max;
This isn't right. Here you're using the param as index, but in the param
array itself the param is just part of the struct. So it's just luck
that the index is correct.
The param part of the struct is just for readability, and possibly more
thorough checking for later on.
The index isn't correct by luck, its mainly because during defining the
array, we fill it up in the sequence in which the enum is defined.
Well, by reading the code nothing tells the reader that the ordering is
important, he has to guess it. One could easily add a new item in wrong
way, and it would be very difficult to notice.
snip
Could something like this work:
unsigned long dss_feat_get_param_min(enum dss_range_param param);
unsigned long dss_feat_get_param_max(enum dss_range_param param);
I agree. Should we remove the max_dss_fck patch since we are moving to
this approach?
Hmm. I guess it would cause a bit too many conflicts. I can check it
later if it's easy to remove, but for now let's just build on top of it.
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 1/1] omap3: Save and restore CM_AUTOIDLE_PLL across off mode
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev
Sent: Monday, March 07, 2011 2:16 PM
To: Paul Walmsley
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: RE: [PATCH 1/1] omap3: Save and restore CM_AUTOIDLE_PLL
across off mode
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Saturday, March 05, 2011 4:16 AM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 1/1] omap3: Save and restore
CM_AUTOIDLE_PLL across
off mode
Hello Sanjeev,
On Thu, 10 Feb 2011, Sanjeev Premi wrote:
As per commit bb33cc58, ROM code is expected to restore
context related to CORE domain. As part of this change,
CM_AUTOIDLE_PLL is neither saved nor restored.
... by Linux.
[sp] Yes.
This results in loosing the value of AUTO_PERIPH_DPLL.
A few questions:
- Is ROM code supposed to restore this register?
[sp] Going by the description of the commit message I referenced, it
It appears to be the case. I am yet to get official confirmation
from the ROM code team (usually takes quite long); but all
experiments (i put them in patch 0/1) suggest so.
- Is there a documented list of which registers/bitfields the ROM code
will and won't restore?
[sp] No that I am aware of; but yes I have already requested for same
since this issue was found.
- Are the entire contents of the register lost, or just
AUTO_PERIPH_DPLL?
[sp] Just AUTO_PERIPH_DPLL.
As per OMAP3630 TRM Section 26.5, register CM_AUTOIDLE_PLL is supposed to
be restored by ROM code. The PM code should only store these registers
before entering off mode. So only thing that needs to be done in this
patch set is to save these registers.
Vishwa
The concern of setting the AUTOIDLE flag before the DPLL
is locked seems valid. Hence, the restoration of this
register is delayed until after the context of PER
domain is restored.
Could you explain a little more about this? Is there a hardware
limitation where AUTO_PERIPH_DPLL shouldn't be set unless the DPLL
is
locked?
[sp] This is based on my understanding (and observation) that DPLL may
take longer to lock after resume. Now if the clock goes to AUTOIDLE
before it is locked; I am not sure what would be the consequences.
The patch has been verified on OMAP3EVM by checking value
of CM_AUTOIDLE_PLL register across the suspend/resume
sequence (using devmem) with flags sleep_while_idle and
enable_off_mode set to 1.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
[sp]
[snip]...[snip]
+/**
+ * Restore the contents of CM_AUTOIDLE_PLL register.
+ *
+ * The implementation below restores AUTO_CORE_DPLL as 'good'
redundancy.
I don't understand this part. Are the entire contents of the register
lost, or just the AUTO_PERIPH_DPLL field?
[sp] As put above, only AUTO_PERIPH_DPLL; but this is based on
observation
not a *real specification*; I chose to set the AUTO_CORE_DPLL bit
as
redundancy.
~sanjeev
+ */
+static void pll_mod_restore_autoidle(void)
+{
+ u32 ctx = stored_cm_autoidle_pll();
+ u32 val = omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE);
+
+ if (ctx OMAP3430_AUTO_CORE_DPLL_MASK)
+ val |= ctx OMAP3430_AUTO_CORE_DPLL_MASK;
+
+ if (ctx OMAP3430_AUTO_PERIPH_DPLL_MASK)
+ val |= ctx OMAP3430_AUTO_PERIPH_DPLL_MASK;
+
+ omap2_cm_write_mod_reg(val, PLL_MOD, CM_AUTOIDLE);
+}
+
[snip]...[snip]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/9] OMAP4 : DSS2 : HDMI: HDMI panel driver addition in the DSS
On Fri, 2011-03-04 at 01:48 -0600, K, Mythri P wrote:
The panel driver(hdmi_omap4_panel.c) in omap2/dss acts as a controller
to manage the enable and disable requests and synchronize audio and video.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/Kconfig|8 +
drivers/video/omap2/dss/Makefile |1 +
drivers/video/omap2/dss/hdmi_omap4_panel.c | 206
3 files changed, 215 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/hdmi_omap4_panel.c
snip
+static int hdmi_panel_suspend(struct omap_dss_device *dssdev)
+{
+ int r = 0;
+
+ mutex_lock(hdmi.hdmi_lock);
+
+ if (dssdev-state == OMAP_DSS_DISPLAY_DISABLED ||
+ dssdev-state == OMAP_DSS_DISPLAY_SUSPENDED) {
Here you could check if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ r = -EINVAL;
+ goto err;
+ }
+
+ dssdev-state = OMAP_DSS_DISPLAY_SUSPENDED;
+
+ omapdss_hdmi_display_disable(dssdev);
+
+err:
+ mutex_unlock(hdmi.hdmi_lock);
+
+ return r;
+}
+
+static int hdmi_panel_resume(struct omap_dss_device *dssdev)
+{
+ int r = 0;
+
+ mutex_lock(hdmi.hdmi_lock);
+
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE) {
Here you should check if (dssdev-state != OMAP_DSS_DISPLAY_SUSPENDED)
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 5/6] omap4: Initialise the l3 device with the hwmod data.
On 2/21/2011 8:03 PM, Shilimkar, Santosh wrote:
-Original Message-
From: Cousson, Benoit [mailto:b-cous...@ti.com]
Sent: Monday, February 21, 2011 11:41 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; Balbi, Felipe; R, Sricharan
Subject: Re: [PATCH 5/6] omap4: Initialise the l3 device with the
hwmod data.
On 2/21/2011 2:46 PM, Shilimkar, Santosh wrote:
From: sricharanr.sricha...@ti.com
The l3 interconnect device is build with all the data required
to handle the error logging. The data is extracted from the
hwmod data base.
Signed-off-by: sricharanr.sricha...@ti.com
Signed-off-by: sricharanr.sricha...@ti.com
Tested-by: sricharanr.sricha...@ti.com
Mmm, I'm not sure the tested-by is meaningfull in your case, since
you wrote the code and so everybody will assume you tested it.
One s-o-b should be probably enough.
Well he tested whole series including the patch from Felipe.
So a tested-by on whole series doesn't hurt, right ?
Just for record, I have seen tested by applied on whole series
Where as some of the patches in this series are just comment
updates.
Cc: Benoit Coussonb-cous...@ti.com
---
arch/arm/mach-omap2/devices.c | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-
omap2/devices.c
index 2d46f55..25fa2ad 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -57,6 +57,29 @@ static int __init omap3_l3_init(void)
}
postcore_initcall(omap3_l3_init);
+static int __init omap4_l3_init(void)
+{
+ int l;
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ char oh_name[12];
+
+ l = snprintf(oh_name, 12, l3_main_1);
+
+ oh = omap_hwmod_lookup(oh_name);
+
+ if (!oh)
+ pr_err(could not look up %s\n, oh_name);
+
+ od = omap_device_build(omap4-l3-interconnect, 0, oh, NULL,
In order to stick to the OMAP device naming convention and to have
something not dependent of the chip version, I think we'd better
name
the device like that: omap_l3_noc. Since it is a Arteris Network
On
Chip on OMAP4. We will not have to change it for OMAP5 then.
On OMAP3 the name can then be omap_l3_smx for the Sonics MX
interconnect.
Device name changes are fine but file name changes as per this.
dosn't look right if they are like
omap_l3_noc.c
omap_l3_smx.c
Why do you think that does not look right?
May be we can rename them like below
omap_l3_3xxx.c
omap_l3_4xxx.c
The point is that it will really depend of the amount of SoC specifics
data are in this file. If most of the code is reusable on OMAP5 for
example, then it makes sense to use the name of the IP.
If that's not the case, then you'd better use the SoC name.
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 v5 REPOST 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
On Fri, Mar 4, 2011 at 9:42 PM, Kevin Hilman khil...@ti.com wrote: Dave Martin dave.mar...@linaro.org writes: On Fri, Mar 4, 2011 at 5:47 PM, Tony Lindgren t...@atomide.com wrote: * Santosh Shilimkar santosh.shilim...@ti.com [110304 09:36]: Following up on this, it looks like I have some locally-recorded acks which didn't make it into my posting ... To me looks like this is ready to go, but I'd like to see Kevin's acks on this one as this touches the PM code. Or if Kevin wants to take the series, here's my ack for the series: Acked-by: Tony Lindgren t...@atomide.com Yeah, I'll queue this series. Thanks -- I'll wait for Kevin to comment also. I have to give one more round of sanity testing to this series, but otherwise I have no outstanding issues. I also need to coordinate with Santosh on this because he has an additional cleanup series that touches the same code. Dave, just to confirm something The outstanding toolchain bugs only affect compiling in Thumb-2 mode, right? IOW, if I merge just this series (without having the other toolchain workaround patches) we should still be able to compile/run fine in ARM mode, correct? Yes, that's right. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe 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] OMAP: DMA: mstandby mode and runtime pm support
On Fri, Mar 04, 2011 at 09:48:26AM +0530, G, Manjunath Kondaiah wrote: On Thu, Mar 03, 2011 at 10:35:23AM -0800, Kevin Hilman wrote: G, Manjunath Kondaiah manj...@ti.com writes: This patch series is remaining part of dma hwmod to support pm runtime and for handling mstandby mode for all applicable DMA mstandby mode errata. This is still not runtime-suspending when I use my DMA test in linking mode. If I put a large enough period between transfers, it should autosuspend during transfers. It seems to do auto-suspend and resume once, but then it never suspends again. I tested with my dmatest module[1], and loaded with: # insmod ./dmatest.ko linking=1 forever=1 forever_period=1024 Not only does it not auto-suspend between transfers (which I expected), it also doesn't suspend after removing the module which stops all active channels. The normal chaining test cases are executed and which used to show the proper status. Let me reproduce this issue with your test procedure. ok. I am able to reproduce this issue and fixed _get_sync usage in omap_start_dma if channel linking is used. Earlier it was handled for the cases with chaining API's. If linking is done without chaining API's, it will result in _get_sync and _put mismatch. Thanks for the test case and I will be re posting the patches with the above fix. -Manjunath -- To unsubscribe from this list: send the line unsubscribe 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 5/6] omap4: Initialise the l3 device with the hwmod data.
-Original Message- From: Cousson, Benoit [mailto:b-cous...@ti.com] Sent: Monday, March 07, 2011 3:52 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org; Balbi, Felipe; R, Sricharan Subject: Re: [PATCH 5/6] omap4: Initialise the l3 device with the hwmod data. On 2/21/2011 8:03 PM, Shilimkar, Santosh wrote: [] In order to stick to the OMAP device naming convention and to have something not dependent of the chip version, I think we'd better name the device like that: omap_l3_noc. Since it is a Arteris Network On Chip on OMAP4. We will not have to change it for OMAP5 then. On OMAP3 the name can then be omap_l3_smx for the Sonics MX interconnect. Device name changes are fine but file name changes as per this. dosn't look right if they are like omap_l3_noc.c omap_l3_smx.c Why do you think that does not look right? No strong preference but noc, smx didn't look ok to me. May be we can rename them like below omap_l3_3xxx.c omap_l3_4xxx.c The point is that it will really depend of the amount of SoC specifics data are in this file. If most of the code is reusable on OMAP5 for example, then it makes sense to use the name of the IP. If that's not the case, then you'd better use the SoC name. Ok. So let's go with the IP names then. New file names will be as above. omap_l3_3xxx.c omap_l3_4xxx.c 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 v11 2/8] OMAP4: hwmod data: add dmtimer version information
-Original Message-
From: Cousson, Benoit
Sent: Friday, March 04, 2011 4:47 PM
To: Hilman, Kevin; DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH v11 2/8] OMAP4: hwmod data: add dmtimer version
information
On 3/4/2011 1:24 AM, Hilman, Kevin wrote:
Tarun Kanti DebBarmatarun.ka...@ti.com writes:
OMAP4 has two groups of timers: version 1 timers are 1, 2, 10,
while the rest of the timers, 3-9, 11 are version 2 timers.
The version information is required by the driver so that they
could be handled correctly by it.
Signed-off-by: Tarun Kanti DebBarmatarun.ka...@ti.com
Minor comment below, also needs an ack from Benoît...
Oops, I missed that one.
Tarun,
I will be good to add me in Cc in order to avoid that.
In general it is always good to Cc the maintainers.
Once the tabs are fixed;
Acked-by: Benoit Cousson b-cous...@ti.com
I will Cc. Thanks.
--
Tarun
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +++
arch/arm/plat-omap/include/plat/dmtimer.h |2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 79a8601..ee57742 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -25,6 +25,7 @@
#includeplat/gpio.h
#includeplat/dma.h
#includeplat/mcspi.h
+#includeplat/dmtimer.h
#include omap_hwmod_common_data.h
@@ -3940,6 +3941,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_timer_1ms_sysc = {
static struct omap_hwmod_class omap44xx_timer_1ms_hwmod_class = {
.name = timer,
.sysc =omap44xx_timer_1ms_sysc,
+ .rev = OMAP_TIMER_IP_VERSION_1,
Please use tab and align '=' with above lines.
};
static struct omap_hwmod_class_sysconfig omap44xx_timer_sysc = {
@@ -3955,6 +3957,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_timer_sysc = {
static struct omap_hwmod_class omap44xx_timer_hwmod_class = {
.name = timer,
.sysc =omap44xx_timer_sysc,
+ .rev = OMAP_TIMER_IP_VERSION_2,
ditto
};
/* timer1 */
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h b/arch/arm/plat-
omap/include/plat/dmtimer.h
index d6c70d2..05a967e 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -55,6 +55,8 @@
* in OMAP4 can be distinguished.
*/
#define OMAP_TIMER_IP_VERSION_10x1
+#define OMAP_TIMER_IP_VERSION_20x2
+
struct omap_dm_timer;
extern struct omap_dm_timer *gptimer_wakeup;
extern struct sys_timer omap_timer;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/6] omap4: Initialise the l3 device with the hwmod data.
-Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Monday, March 07, 2011 4:49 PM To: Benoit Cousson Cc: linux-omap@vger.kernel.org; Felipe Balbi; Sricharan R Subject: RE: [PATCH 5/6] omap4: Initialise the l3 device with the hwmod data. [] Ok. So let's go with the IP names then. New file names will be as above. omap_l3_3xxx.c omap_l3_4xxx.c Sorry I mean ... omap_l3_noc.c omap_l3_smx.c 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] cbus-retu-wdt: Store all data in device struct
On Mon, 2011-03-07 at 09:43 +0200, Felipe Balbi wrote: - struct miscdevice retu_wdt_miscdev; + struct miscdevice miscdev; this rename is not part of $SUBJECT Well, that element is used in several new container_of() instances. retu_wdt_miscdev is needlessly long and just increases the line-length pain on the container_of() lines. The retu_wdt prefix is useless, because it's an element of the retu_wdt data structure. struct delayed_work ping_work; + struct mutexmutex; checkpatch.pl --strict will complain about this mutex not having a comment explaining it. Can you add something ? Is that really required? I mean, it's obvious what the mutex is used for and what it is protecting (the whole struct). -static int _retu_modify_counter(unsigned int new) +static inline void _retu_modify_counter(struct retu_wdt_dev *wdev, + unsigned int new) let the compiler inline it, maybe ?!? Ok, it doesn't change the object code either way. -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] OMAP3: cpuidle: prevent CORE power domain from going to RET or OFF when DSS is on
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman Sent: 04 March, 2011 18:56 To: Kristo Tero (Nokia-MS/Tampere) Cc: p...@pwsan.com; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 1/2] OMAP3: cpuidle: prevent CORE power domain from going to RET or OFF when DSS is on Hi Tero, tero.kri...@nokia.com writes: [...] + /* If DSS is active, prevent CORE RET/OFF */ + dss_state = pwrdm_read_pwrst(dss_pd); + if (dss_state == PWRDM_POWER_ON + core_next_state != PWRDM_POWER_ON) + core_next_state = PWRDM_POWER_INACTIVE; + Due to sleepdeps/autodeps, when this code runs, DSS powerdomain is always on. The result is that CORE is always set to INACTIVE. Now I recall that someone was asking about a patch similar to this earlier, and had the same issue with DSS sleepdep collision. What is the reason for having the sleepdep for DSS powerdomain anyway? At least I can't see any reason why the sleepdep for DSS should be set. In my opinion it should be perfectly okay for DSS domain to idle independently of MPU/CORE, as this is going to be better for power consumption also. Agreed, but currently the sleepdeps with MPU are automatically managed (by clkdm autodeps and hwmod initiator deps.) Until we have merged a solution to more selectively enable sleepdeps (or remove them) $SUBJECT patch cannot be merged. Ok I thought this is the case... it would be possible to implement a temporary/permanent solution that uses idle status check instead of pwrdm state check, and prevent core idle if dss is not going to idle. What is the current status with those idlest patches anyway? -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: [PATCH 1/2] ARM: l2x0: Errata fix for flush by Wayoperationcan cause data corruption
Thanks Will for reporting it.
-Original Message-
From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-
arm-kernel-boun...@lists.infradead.org] On Behalf Of Will Deacon
Sent: Monday, March 07, 2011 5:38 PM
To: 'Santosh Shilimkar'; Russell King - ARM Linux
Cc: t...@atomide.com; Catalin Marinas; linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org
Subject: RE: [PATCH 1/2] ARM: l2x0: Errata fix for flush by
Wayoperationcan cause data corruption
Hi Santosh,
On Sun, Feb 27, 2011 at 12:00:21PM +, Russell King - ARM
Linux
wrote:
+#else
+/* Optimised out for non-errata case */
+static inline void debug_writel(unsigned long val)
+{
}
#define l2x0_set_debug NULL
+#endif
I notice you got rid of the inline function. Have you tried
building this without the errata enabled?
I accidently dropped the inline function while
incorporating the comment from you. :(
Fixed it. Updated version # 6770/1
This version of the patch (as it appears in -next) is broken:
+#define debug_writel(val)outer_cache.set_debug(val)
+
+static void l2x0_set_debug(unsigned long val)
+{
+ writel(val, l2x0_base + L2X0_DEBUG_CTRL);
This should have been writel_relaxed() to avoid the
cache sync.
}
[...]
@@ -119,9 +120,11 @@ static void l2x0_flush_all(void)
/* clean all ways */
spin_lock_irqsave(l2x0_lock, flags);
+ debug_writel(0x03);
writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_CLEAN_INV_WAY);
cache_wait_way(l2x0_base + L2X0_CLEAN_INV_WAY, l2x0_way_mask);
cache_sync();
+ debug_writel(0x00);
spin_unlock_irqrestore(l2x0_lock, flags);
}
This deadlocks because the writel forces an outer cache sync, which
then tries to acquire the spinlock which is held by the calling
function.
If you change l2x0_set_debug to use writel_relaxed then you can
avoid the problem.
Ya understood. I couldn't test non-errata case because
direct right doesn't work because of security and henced missed
it.
Below is the updated version. Also attached.
Russell,
Do you want me to push this to patch system or you can
apply this one?
Regards,
Santosh
--
From 9167fd4eff8adf1f8be772cdb734bfc0f2061354 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 28 Feb 2011 13:31:09 +0100
Subject: [PATCH] ARM: 6770/1: l2x0: Errata fix for flush by Way operation
can cause data corruption
PL310 implements the Clean Invalidate by Way L2 cache maintenance
operation (offset 0x7FC). This operation runs in background so that
PL310 can handle normal accesses while it is in progress. Under very
rare circumstances, due to this erratum, write data can be lost when
PL310 treats a cacheable write transaction during a Clean Invalidate
by Way operation.
Workaround:
Disable Write-Back and Cache Linefill (Debug Control Register)
Clean Invalidate by Way (0x7FC)
Re-enable Write-Back and Cache Linefill (Debug Control Register)
This patch also removes any OMAP dependency on PL310 Errata's
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Catalin Marinas catalin.mari...@arm.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/Kconfig | 15 ---
arch/arm/include/asm/outercache.h |1 +
arch/arm/mm/cache-l2x0.c | 32 ++--
3 files changed, 31 insertions(+), 17 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 65ea7bb..ef41f7e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1135,7 +1135,7 @@ config ARM_ERRATA_742231
config PL310_ERRATA_588369
bool Clean Invalidate maintenance operations do not invalidate
clean lines
- depends on CACHE_L2X0 ARCH_OMAP4
+ depends on CACHE_L2X0
help
The PL310 L2 cache controller implements three types of Clean
Invalidate maintenance operations: by Physical Address
@@ -1144,8 +1144,7 @@ config PL310_ERRATA_588369
clean operation followed immediately by an invalidate
operation,
both performing to the same memory location. This functionality
is not correctly implemented in PL310 as clean lines are not
- invalidated as a result of these operations. Note that this
errata
- uses Texas Instrument's secure monitor api.
+ invalidated as a result of these operations.
config ARM_ERRATA_720789
bool ARM errata: TLBIASIDIS and TLBIMVAIS operations can
broadcast a faulty ASID
@@ -1172,6 +1171,16 @@ config ARM_ERRATA_743622
visible impact on the overall performance or power consumption
of the
processor.
+config PL310_ERRATA_727915
+ bool Background Clean Invalidate by Way operation can cause
data corruption
+ depends on CACHE_L2X0
+ help
+ PL310 implements the Clean Invalidate by Way L2 cache
maintenance
+ operation (offset 0x7FC). This
RE: [PATCH v11 6/8] dmtimer: switch-over to platform device driver
Tony, Santosh,
[...]
+void __init omap2_dm_timer_early_init(void)
+{
+ int ret = omap_hwmod_for_each_by_class(timer,
+ omap_timer_init, NULL);
Here we really only want to initialize the system timer. The
rest we
want to do later, so let's not init all of them early.
So, that is how it was at the beginning.
Later we realized different platforms can use different timers for
this.
For example, beagle uses GPT12. Therefore, as part of one of the
comments,
We decided to provide flexibility so that any of the timers could
be used.
You can still do it, just register the one that's being used and
mark it reserved so it won't get initialized again later on.
I agree with Tony. We can still registers only the system
timer because the timer ID is known well before we do
initialization.
I must say, there was a gap in my understanding of the comment.
So, here is the implementation change:
- Call omap2_dm_timer_early_init(u8 gptimer_id) from omap2_gp_timer_init()
- Initialize only gptimer_id inside this function
- In the regular init skip initialization of gptimer_id
As a result of this, we can rid of double registration and related code.
--
Tarun
--
To unsubscribe from this list: send the line unsubscribe 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 2/4] OMAP4: hwmod data: add mmu hwmod for ipu and dsp
Hi Omar,
I have some concern about the introduction of a hwmod that does not
match the actual HW capability. MMU does exist, but there is no SW
control for it. In fact the only control available is for mmu + cache +
logic, and that's why the MMU is handle today under the main DSP/IPU hwmod.
Here you are just duplicating dsp_hwmod and ipu_hwmod with dsp_mmu_hwmod
/ ipu_mmu_hwmod and adding some memory space for the mmu part.
In that case, you can still use the previous name and add the missing
entries in it.
The only advantage I can see is the usage of a common class that will
allow you to handle both DSP and IPU using the same MMU driver.
So, what are you going to do with the remaining entries for dsp_hwmod
and ipu_hwmod?
If these two become useless and only the mmu part is useful, we can
potentially rename them like you did, but without keeping the original.
On 3/7/2011 8:53 AM, Ramirez Luna, Omar wrote:
Add mmu hwmod data for ipu and dsp.
Signed-off-by: Omar Ramirez Lunaomar.rami...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 156 +--
1 files changed, 144 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7dbcdf7..149d694 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -27,6 +27,7 @@
#includeplat/mcspi.h
#includeplat/mcbsp.h
#includeplat/mmc.h
+#includeplat/iommu.h
#include omap_hwmod_common_data.h
@@ -990,10 +991,6 @@ static struct omap_hwmod_irq_info omap44xx_dsp_irqs[] = {
{ .irq = 28 + OMAP44XX_IRQ_GIC_START },
};
-static struct omap_hwmod_rst_info omap44xx_dsp_resets[] = {
- { .name = mmu_cache, .rst_shift = 1 },
-};
-
static struct omap_hwmod_rst_info omap44xx_dsp_c0_resets[] = {
{ .name = dsp, .rst_shift = 0 },
};
@@ -1045,8 +1042,6 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
.class =omap44xx_dsp_hwmod_class,
.mpu_irqs = omap44xx_dsp_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dsp_irqs),
- .rst_lines = omap44xx_dsp_resets,
- .rst_lines_cnt = ARRAY_SIZE(omap44xx_dsp_resets),
.main_clk = dsp_fck,
.prcm = {
.omap4 = {
@@ -2323,10 +2318,6 @@ static struct omap_hwmod_rst_info
omap44xx_ipu_c1_resets[] = {
{ .name = cpu1, .rst_shift = 1 },
};
-static struct omap_hwmod_rst_info omap44xx_ipu_resets[] = {
- { .name = mmu_cache, .rst_shift = 2 },
-};
-
/* ipu master ports */
static struct omap_hwmod_ocp_if *omap44xx_ipu_masters[] = {
omap44xx_ipu__l3_main_2,
@@ -2380,8 +2371,6 @@ static struct omap_hwmod omap44xx_ipu_hwmod = {
.class =omap44xx_ipu_hwmod_class,
.mpu_irqs = omap44xx_ipu_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_ipu_irqs),
- .rst_lines = omap44xx_ipu_resets,
- .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_resets),
.main_clk = ipu_fck,
.prcm = {
.omap4 = {
@@ -3711,6 +3700,145 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
};
/*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig mmu_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields=omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_mmu_hwmod_class = {
+ .name = mmu,
+ .sysc =mmu_sysc,
+};
+
+/* ipu mmu */
+
+static struct omap_mmu_dev_attr ipu_mmu_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_ipu_mmu_hwmod;
Minor comment, but if we want to focus on the MMU as the main class,
then ipu and dsp will become just instance qualifiers, and thus the name
should be mmu_ipu and mmu_dsp.
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
[PATCH] omap: iommu: disallow mapping NULL address
From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00 2001 From: Michael Jones michael.jo...@matrix-vision.de Date: Mon, 7 Mar 2011 13:36:15 +0100 Subject: [PATCH] omap: iommu: disallow mapping NULL address commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL address if da_start==0. Force da_start to exclude the first page. Signed-off-by: Michael Jones michael.jo...@matrix-vision.de --- arch/arm/plat-omap/iommu.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c index 5990ea6..dcb5513 100644 --- a/arch/arm/plat-omap/iommu.c +++ b/arch/arm/plat-omap/iommu.c @@ -850,7 +850,7 @@ int iommu_set_da_range(struct iommu *obj, u32 start, u32 end) if (end start || !PAGE_ALIGN(start | end)) return -EINVAL; - obj-da_start = start; + obj-da_start = max(start, (u32)PAGE_SIZE); obj-da_end = end; return 0; @@ -950,7 +950,9 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev) obj-name = pdata-name; obj-dev = pdev-dev; obj-ctx = (void *)obj + sizeof(*obj); - obj-da_start = pdata-da_start; + + /* reserve the first page for NULL */ + obj-da_start = max(pdata-da_start, (u32)PAGE_SIZE); obj-da_end = pdata-da_end; mutex_init(obj-iommu_lock); -- 1.7.4.1 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- To unsubscribe from this list: send the line unsubscribe 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: Problem with DSS clocks accessing registers
+ Rajendra Hi Tomi, On 3/7/2011 9:22 AM, Valkeinen, Tomi wrote: Hi Kevin, Paul, We currently have a small problem with OMAP4 DSS. When we enable the DSS clocks, it seems that the DSS registers are not always accessible right after the clock enable. What clocks are you talking about? As you know, the DSS has a bunch of functional clocks available depending of the use case. I understood that on OMAP4 the clock framework doesn't guarantee that the registers are accessible after enabling clocks, and pm_runtime will handle this. Is this correct? The point is that there is no status at clock level but only one status at module level. That's why this check does not have anything to do at clock level. So hwmod with handle that status (OMAP4430_CM_DSS_DSS_CLKCTRL) during the hwmod_enable that is indirectly called by pm_runtime, through omap_device API. I have made a small hack fix for this. I added udelay(10) in the DSS code which enables the clocks and this seem to remove the problem. The delay is only called when DSS thinks the clocks have been off, so in practice the delay shouldn't be visible. Is this fix acceptable for now, until we get pm_runtime support to DSS? Cannot you use omap_device for the moment? Relying on a udelay is not a very safe method, even temporally. Or you might hack the main clock node to check for the module status. I think it was done like that at the beginning of OMAP4. It was removed, but I do not remember if it was done at fmwk level or at clock nodes level. Rajendra should know the full story. 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: Problem with DSS clocks accessing registers
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Cousson, Benoit Sent: Monday, March 07, 2011 7:21 PM To: Valkeinen, Tomi; Nayak, Rajendra Cc: Paul Walmsley; Hilman, Kevin; linux-omap; Taneja, Archit; Semwal, Sumit Subject: Re: Problem with DSS clocks accessing registers + Rajendra Hi Tomi, On 3/7/2011 9:22 AM, Valkeinen, Tomi wrote: Hi Kevin, Paul, We currently have a small problem with OMAP4 DSS. When we enable the DSS clocks, it seems that the DSS registers are not always accessible right after the clock enable. What clocks are you talking about? As you know, the DSS has a bunch of functional clocks available depending of the use case. I understood that on OMAP4 the clock framework doesn't guarantee that the registers are accessible after enabling clocks, and pm_runtime will handle this. Is this correct? This seems to the question about a so called optional clock (DSS_CLK) which really not an optional clock :) This clock needs to be enabled and disabled along with interface and functional clock for the registers access to work. If you look internals of the clock routing in DSS, Figure 10-4 this clock is not really optional. You can call it optional because there can be a option to use PLL clock instead of this one. But the fact is either DSS_CLK or the PLL clock has to be running for the IP accesses to work. Sumit, Please add more points about our discussion on this one. 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] OMAP1: McBSP: fix build break for non-multi-OMAP1 configs
On Fri, 4 Mar 2011 15:36:46 -0700 (MST) Paul Walmsley p...@pwsan.com wrote: Commit 3cf32bba8ca0e0052ca41d74d455a5805b7fea85 (OMAP: McBSP: Convert McBSP to platform device model) in the current omap-for-linus branch breaks compilation with non-multi-OMAP1 configs: CC arch/arm/mach-omap1/mcbsp.o arch/arm/mach-omap1/mcbsp.c: In function 'omap1_mcbsp_init': arch/arm/mach-omap1/mcbsp.c:384: warning: dereferencing 'void *' pointer arch/arm/mach-omap1/mcbsp.c:387: error: invalid use of void expression arch/arm/mach-omap1/mcbsp.c:390: warning: dereferencing 'void *' pointer arch/arm/mach-omap1/mcbsp.c:393: error: invalid use of void expression +#define omap7xx_mcbsp_res_0 omap7xx_mcbsp_res[0] + ... if (cpu_is_omap7xx()) - omap_mcbsp_register_board_cfg(omap7xx_mcbsp_res[0], + omap_mcbsp_register_board_cfg(omap7xx_mcbsp_res_0, OMAP7XX_MCBSP_RES_SZ, omap7xx_mcbsp_pdata, OMAP7XX_MCBSP_COUNT); omapxxx_mcbsp_res_0 doesn't look the best here in readability point of view but provides the smallest fix as no need to rename array and modify the _RES_SZ and _COUNT macros. So this fix is needed here and a small readability update can be done later. Acked-by: Jarkko Nikula jhnik...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 13/19] OMAP3+: SR: Reuse sr_[start|stop]_vddautocomp functions
On Sat, 5 Mar 2011 20:59:16 +0530 Nishanth Menon n...@ti.com wrote: From: Jarkko Nikula jhnik...@gmail.com sr_start_vddautocomp and sr_stop_autocomp functions can be reused from omap_sr_enable, omap_sr_disable and omap_sr_disable_reset_volt and by adding one additional argument sr_stop_autocomp. This allows us to have a single point where SR enable and disable operations are controlled from. [n...@ti.com: synced it up with class start/stop as well. autocomp flag should only be disabled when SR is disabled for that domain] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Jarkko Nikula jhnik...@gmail.com --- Side note: Jarkko has'nt seen this rev as I just finished the rebase and tested but adding his signed-off anyways as he is primary contributor to the idea and the patch. This version looks good to me. We agreed with Nishant that squashing my trivial patches with Nishant's set makes the most sense. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP 3730 200 MHz SDRAM config
Hi, I'm looking at configuring an OMAP 3730 board for 200 MHz SDRAM. I've been looking at the kernel code (arch/arm/mach-omap2) the last couple of days to try and figure out what I need to do. We're basing ourselves off of the Beagleboard, so I tried copying the 200 MHz Hynix SDRAM entry for Beagleboard-xM but that didn't help: it still (re)programs the SDRC clock to 166 MHz. * Does the kernel at all use or depend on the boot loader's SDRAM config? (I'm using u-boot with a prepended configuration header.) * Does the SDRAM setup/clocking depend on the MPU rate at all? I.e. do I need to boot Linux in 1 GHz to be able to set 200 MHz SDRC clock? The clock config is a bit convoluted, so I'd appreciate any help. Thanks, Orjan Appendix: I'm using a program (user-mode app) called 'bandwidth' (which has an ARM port): http://home.comcast.net/~fbui/bandwidth.html for measurements. With big (several MB) sequential writes I get ~1170 MB/s. The theoretical max for a 166 MHz is 166*2 * 4 bytes = 1328 MB/s, so we're almost at 90%. We're not the only process accessing memory, and maybe there's some loss due to SDRAM refresh etc. -- Orjan Friberg FlatFrog Laboratories AB -- To unsubscribe from this list: send the line unsubscribe 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: Problem with DSS clocks accessing registers
On 3/7/2011 3:05 PM, Shilimkar, Santosh wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Cousson, Benoit + Rajendra Hi Tomi, On 3/7/2011 9:22 AM, Valkeinen, Tomi wrote: Hi Kevin, Paul, We currently have a small problem with OMAP4 DSS. When we enable the DSS clocks, it seems that the DSS registers are not always accessible right after the clock enable. What clocks are you talking about? As you know, the DSS has a bunch of functional clocks available depending of the use case. I understood that on OMAP4 the clock framework doesn't guarantee that the registers are accessible after enabling clocks, and pm_runtime will handle this. Is this correct? This seems to the question about a so called optional clock (DSS_CLK) which really not an optional clock :) This clock needs to be enabled and disabled along with interface and functional clock for the registers access to work. To be more accurate, this clock is one of the functional clock available for the DSS (the other being the SYS_CLK). You can use dss_clk or sys_clk (through dsi pll) to generate the functional clock of the DSS. The issue, as I said is that the availability status of the DSS is bound to the DSS module mode, not to any of this DSS clock. 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: Problem with DSS clocks accessing registers
On Mon, 2011-03-07 at 07:51 -0600, Cousson, Benoit wrote: + Rajendra Hi Tomi, On 3/7/2011 9:22 AM, Valkeinen, Tomi wrote: Hi Kevin, Paul, We currently have a small problem with OMAP4 DSS. When we enable the DSS clocks, it seems that the DSS registers are not always accessible right after the clock enable. What clocks are you talking about? As you know, the DSS has a bunch of functional clocks available depending of the use case. In this case the clocks for DISPC, iclk and fclk. On OMAP4 fclk is DSS_FCLK and iclk is not used, I believe. The problem is probably also in all the other DSS modules. I understood that on OMAP4 the clock framework doesn't guarantee that the registers are accessible after enabling clocks, and pm_runtime will handle this. Is this correct? The point is that there is no status at clock level but only one status at module level. That's why this check does not have anything to do at clock level. So hwmod with handle that status (OMAP4430_CM_DSS_DSS_CLKCTRL) during the hwmod_enable that is indirectly called by pm_runtime, through omap_device API. Ah. Ok. How does CM_DSS_DSS_CLKCTRL show that the DSS module is ready? IDLEST is 0? I have made a small hack fix for this. I added udelay(10) in the DSS code which enables the clocks and this seem to remove the problem. The delay is only called when DSS thinks the clocks have been off, so in practice the delay shouldn't be visible. Is this fix acceptable for now, until we get pm_runtime support to DSS? Cannot you use omap_device for the moment? Relying on a udelay is not a very safe method, even temporally. Yes, udelay is not very good option even as a hack, except if we can wait some amount of time which we know will always be enough. Can we? I have to say I'm not very familiar with omap_device, as I haven't been really working with them (nor hwmods). Sumit or Archit can perhaps fill in, but my understanding is that work on that area is going on, but it's not ready yet. So I'm looking for some temporary quick solution for this so that DSS driver doesn't randomly crash on OMAP4. 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: OMAP 3730 200 MHz SDRAM config
Hi,
On Mar 7, 2011, at 6:46 PM, Orjan Friberg wrote:
I'm looking at configuring an OMAP 3730 board for 200 MHz SDRAM.
I've been looking at the kernel code (arch/arm/mach-omap2) the last
couple of days to try and figure out what I need to do. We're basing
ourselves off of the Beagleboard, so I tried copying the 200 MHz Hynix SDRAM
entry for Beagleboard-xM but that didn't help: it still (re)programs the SDRC
clock to 166 MHz.
You probably need update x-loader. Try using the beagleboard x-loader project
located at gitorious (v1.44) or the ti arago one (1.48, but not quite the
latest in terms of support for beagleboard xm parts).
Looking at board/omap3530beagle/omap3530beagle.c for the memory part
definitions. For the XM, the Numonyx part is at 165Mhz, and the Micron part is
at 200Mhz.
case REVISION_XM:
if (identify_xm_ddr() == MICRON_DDR) {
__raw_writel(0x2, SDRC_CS_CFG); /* 256MB/bank */
__raw_writel(SDP_SDRC_MDCFG_0_DDR_MICRON_XM,
SDRC_MCFG_0);
__raw_writel(SDP_SDRC_MDCFG_0_DDR_MICRON_XM,
SDRC_MCFG_1);
__raw_writel(MICRON_V_ACTIMA_200, SDRC_ACTIM_CTRLA_0);
__raw_writel(MICRON_V_ACTIMB_200, SDRC_ACTIM_CTRLB_0);
__raw_writel(MICRON_V_ACTIMA_200, SDRC_ACTIM_CTRLA_1);
__raw_writel(MICRON_V_ACTIMB_200, SDRC_ACTIM_CTRLB_1);
__raw_writel(SDP_3430_SDRC_RFR_CTRL_200MHz,
SDRC_RFR_CTRL_0);
__raw_writel(SDP_3430_SDRC_RFR_CTRL_200MHz,
SDRC_RFR_CTRL_1);
} else {
__raw_writel(0x4, SDRC_CS_CFG); /* 512MB/bank */
__raw_writel(SDP_SDRC_MDCFG_0_DDR_NUMONYX_XM,
SDRC_MCFG_0);
__raw_writel(SDP_SDRC_MDCFG_0_DDR_NUMONYX_XM,
SDRC_MCFG_1);
__raw_writel(NUMONYX_V_ACTIMA_165, SDRC_ACTIM_CTRLA_0);
__raw_writel(NUMONYX_V_ACTIMB_165, SDRC_ACTIM_CTRLB_0);
__raw_writel(NUMONYX_V_ACTIMA_165, SDRC_ACTIM_CTRLA_1);
__raw_writel(NUMONYX_V_ACTIMB_165, SDRC_ACTIM_CTRLB_1);
__raw_writel(SDP_3430_SDRC_RFR_CTRL_165MHz,
SDRC_RFR_CTRL_0);
__raw_writel(SDP_3430_SDRC_RFR_CTRL_165MHz,
SDRC_RFR_CTRL_1);
}
break;
Elvis Dowson
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
-Original Message- From: Sripathy, Vishwanath Sent: Thursday, February 24, 2011 3:35 PM To: Premi, Sanjeev; linux-omap@vger.kernel.org Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023 Sanjeev, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Sanjeev Premi Sent: Wednesday, February 23, 2011 11:29 PM To: linux-omap@vger.kernel.org Cc: Sanjeev Premi Subject: [RFC 3/3] am35xx: pm: Hook-up with TPS65023 Add glue logic to hook-up AM35x processors with TPS65023. It seems that you are not really using Voltage layer for any interaction with TPS65023 as you are not using VP and VC. Then what is the purpose of registering this PMIC with Voltage layer. I fail to understand the purpose of this patch series. [sp] Then, can you suggest how do I get the AM35x EVM to boot? Given the current limitation of all voltage related data being extracted from the voltage layer - which expects only TWLx0y0 PMICs. Vishwa Signed-off-by: Sanjeev Premi pr...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP 3730 200 MHz SDRAM config
On 2011-03-07 16:19, Elvis Dowson wrote: You probably need update x-loader. Try using the beagleboard x-loader project located at gitorious (v1.44) or the ti arago one (1.48, but not quite the latest in terms of support for beagleboard xm parts). Looking at board/omap3530beagle/omap3530beagle.c for the memory part definitions. For the XM, the Numonyx part is at 165Mhz, and the Micron part is at 200Mhz. I'm using u-boot with a configuration header, and there I have set the new CTRLA, CTRLB and RFR values (and I did compare the values with the Micron data sheet; apart from the TCKE value they are all identical). But are you saying that the values set by the boot loader are preserved by the kernel? (In that case I wonder what the sdram-micron header file is for :) Thanks, Orjan -- Orjan Friberg FlatFrog Laboratories AB -- To unsubscribe from this list: send the line unsubscribe 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 03/19] OMAP3+: voltage: remove initial voltage
Hello. On 07-03-2011 5:52, Nishanth Menon wrote: Blindly setting a 1.2V setting Hm, seems tautological... As a non native English speaker, I would like to understand how we could improve this. I suppose you mean Blindly setting 1.2V is better here. Am i correct? Yes. WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023
-Original Message- From: Premi, Sanjeev [mailto:pr...@ti.com] Sent: Monday, March 07, 2011 8:51 PM To: Sripathy, Vishwanath; linux-omap@vger.kernel.org Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023 -Original Message- From: Sripathy, Vishwanath Sent: Thursday, February 24, 2011 3:35 PM To: Premi, Sanjeev; linux-omap@vger.kernel.org Subject: RE: [RFC 3/3] am35xx: pm: Hook-up with TPS65023 Sanjeev, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Sanjeev Premi Sent: Wednesday, February 23, 2011 11:29 PM To: linux-omap@vger.kernel.org Cc: Sanjeev Premi Subject: [RFC 3/3] am35xx: pm: Hook-up with TPS65023 Add glue logic to hook-up AM35x processors with TPS65023. It seems that you are not really using Voltage layer for any interaction with TPS65023 as you are not using VP and VC. Then what is the purpose of registering this PMIC with Voltage layer. I fail to understand the purpose of this patch series. [sp] Then, can you suggest how do I get the AM35x EVM to boot? Given the current limitation of all voltage related data being extracted from the voltage layer - which expects only TWLx0y0 PMICs. Pls use regulator framework for setting the voltage for your PMIC. Vishwa Vishwa Signed-off-by: Sanjeev Premi pr...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pm-core: recursive dependency on config
* Russell King - ARM Linux li...@arm.linux.org.uk [110305 01:55]: So I suspect that a merge conflict hasn't been resolved correctly. I'm not going to worry about that because I have the merge conflict resolution here already as part of my tree. Sounds like that's the case, I'll take a look. 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] staging: tidspbridge: protect dmm_map properly
On Mon, Dec 20, 2010 at 7:12 PM, Felipe Contreras felipe.contre...@nokia.com wrote: We need to protect not only the dmm_map list, but the individual map_obj's, otherwise, we might be building the scatter-gather list with garbage. So, use the existing proc_lock for that. I observed race conditions which caused kernel panics while running stress tests. This patch fixes those. I just heard that Tuomas Kulve is getting a lot of panics on Gumstix Overo. I propose we apply this patch on the stable tree ASAP, and if there's no better proposals, also on .38. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB issues with 2.6.38-rc7?
On Sun, Mar 6, 2011 at 11:37 PM, Felipe Balbi ba...@ti.com wrote: On Sun, Mar 06, 2011 at 08:58:47PM -0800, Steve Sakoman wrote: I began working with mainline 2.6.38-rc7 on Overo this past week in an attempt to get a few patches submitted in time for the 2.6.39 merge window. One thing I've noticed is that neither musb nor ehci USB support are working for me. I'm using the same config options as I did for 2.6.37. The 2.6.37 defconfig was my issue. The 2.6.37 deconfig did not include CONFIG_USB_MUSB_OMAP2PLUS. For some reason this causes CONFIG_USB_MUSB_TUSB6010 and CONFIG_USB_TUSB_OMAP_DMA to be set and results in non-working USB. Adding CONFIG_USB_MUSB_OMAP2PLUS to my defconfig did the trick and I now have working musb and ehci. Steve -- To unsubscribe from this list: send the line unsubscribe 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: protect dmm_map properly
On Mon, Mar 7, 2011 at 8:02 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Mon, Dec 20, 2010 at 7:12 PM, Felipe Contreras felipe.contre...@nokia.com wrote: We need to protect not only the dmm_map list, but the individual map_obj's, otherwise, we might be building the scatter-gather list with garbage. So, use the existing proc_lock for that. I observed race conditions which caused kernel panics while running stress tests. This patch fixes those. I just heard that Tuomas Kulve is getting a lot of panics on Gumstix Overo. I propose we apply this patch on the stable tree ASAP, and if there's no better proposals, also on .38. Agree that a fix should be merged asap, and I don't mind which. Especially since things have changed lately and chances that we will use this code for OMAP4 too are really small now. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] Remaining omap fixes for 2.6.37-r7
Hi Linus, Please pull omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus This contains the remaining PM related fixes that were missing from the last pull request and one new fix for a mailbox hang. Regards, Tony The following changes since commit dd9c1549edef02290edced639f67b54a25abbe0e: Linux 2.6.38-rc7 (2011-03-01 13:55:12 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Aaro Koskinen (1): arm: mach-omap2: smartreflex: fix another memory leak Hari Kanigeri (1): omap: mailbox: resolve hang issue Shweta Gulati (1): OMAP2+: PM: SmartReflex: fix memory leaks in Smartreflex driver Tony Lindgren (1): Merge branch 'for_2.6.38/pm-fixes' of ssh://master.kernel.org/.../khilman/linux-omap-pm into devel-fixes arch/arm/mach-omap2/mailbox.c | 10 ++ arch/arm/mach-omap2/smartreflex.c | 33 +++-- 2 files changed, 21 insertions(+), 22 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: tidspbridge: protect dmm_map properly
On Mon, Mar 07, 2011 at 08:02:44PM +0200, Felipe Contreras wrote: On Mon, Dec 20, 2010 at 7:12 PM, Felipe Contreras felipe.contre...@nokia.com wrote: We need to protect not only the dmm_map list, but the individual map_obj's, otherwise, we might be building the scatter-gather list with garbage. So, use the existing proc_lock for that. I observed race conditions which caused kernel panics while running stress tests. This patch fixes those. I just heard that Tuomas Kulve is getting a lot of panics on Gumstix Overo. I propose we apply this patch on the stable tree ASAP, and if there's no better proposals, also on .38. Um, I don't think you realize _how_ stable trees work, please go read Documentation/stable_kernel_rules.txt to see how it is not possible to take something into the stable releases before it goes to Linus's tree. Sorry, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] OMAP: GPIO: use PM runtime framework
Varadarajan, Charulatha ch...@ti.com writes:
[...]
GPIO driver is modified to use dev_pm_ops instead of sysdev_class.
With this approach, gpio_bank_suspend() gpio_bank_resume()
are not part of sys_dev_class.
Usage of PM runtime get/put APIs in GPIO driver is as given below:
pm_runtime_get_sync():
* In the probe before accessing the GPIO registers
* at the beginning of omap_gpio_request()
-only when one of the gpios is requested on a bank, in which,
no other gpio is being used (when mod_usage becomes non-zero).
When using runtime PM, bank-mod_usage acutally becomes redundant with
usage counting already done at the runtime PM level. IOW, checking
bank-mod_usage is he equivalent of checking pm_runtime_suspended(), so
I think you can totally get rid of bank-mod_usage.
I wish to differ here. bank-mod_usage is filled for each GPIO pin in a bank.
Hence during request/free if pm_runtime_get_sync() is called for each GPIO
pin, then the count gets increased for each GPIO pin in a bank. But
gpio_prepare_for_idle/suspend calls pm_runtime_put() only once for
each bank. Hence there will be a count mismatch and hence this will lead
to problems and never a bank will get suspended.
IMO it is required to have bank-mod_usage checks. Please correct
me if I am wrong.
You're right, I see what you're saying now. Thanks for clarifying.
In that case, keeping bank-mod_usage should be OK for now.
That being said, as I'm looking at the idle prepare/resume hooks
something else came to mind.
Most of what the idle prepare/resume mehods do should actually be done
in the -runtime_suspend() and -runtime_resume() hooks (e.g. debounce
clock disable, edge-detect stuff, context save/restore). IOW, that
stuff does not need to be done until the bank is actually
disabled/enabled. For example, prepare_for_idle itself could be a
relatively simple check for bank-mod_usage and a call to
pm_runtime_put_sync().
What do you think?
[...]
@@ -1058,22 +1079,7 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
__raw_writel(__raw_readl(reg) | (1 offset), reg);
}
#endif
- if (!cpu_class_is_omap1()) {
- if (!bank-mod_usage) {
- void __iomem *reg = bank-base;
- u32 ctrl;
-
- if (cpu_is_omap24xx() || cpu_is_omap34xx())
- reg += OMAP24XX_GPIO_CTRL;
- else if (cpu_is_omap44xx())
- reg += OMAP4_GPIO_CTRL;
- ctrl = __raw_readl(reg);
- /* Module is enabled, clocks are not gated */
- ctrl = 0xFFFE;
- __raw_writel(ctrl, reg);
- }
- bank-mod_usage |= 1 offset;
- }
Where did this code go? I expected it to be moved, but not removed
completely.
It is only moved and not removed.
bank-mod_usage |= 1 offset; is done above and the rest is done below.
I found the set of bank-mod_usage, but I do not see the clock un-gating
in the resulting code. Can you please share the line number in the
resulting code where this is done? I just grep'd for 'Module is
enabled' and the 'ctrl = 0xFFFE' line and could not find them.
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/5] OMAP: GPIO: use pwrdmn name to find wkup dmn GPIO
Varadarajan, Charulatha ch...@ti.com writes:
On Sat, Mar 5, 2011 at 02:21, Kevin Hilman khil...@ti.com wrote:
Charulatha V ch...@ti.com writes:
In omap3, save/restore context is implemented for GPIO
banks 2-6 as GPIO bank1 is in wakeup domain. Instead
of identifying bank's power domain by bank id, make use
of powerdomain name itself.
For this, omap_hwmod_get_pwrdm() is used. omap_device_get_pwrdm()
could not be used as the pwrdm information needs to be filled
in pdata. But omap_device_get_pwrdm() can be used only after
omap_device_build() call.
Signed-off-by: Charulatha V ch...@ti.com
Tested-by: Tarun Kanti DebBarma tarun.ka...@ti.com
(2430-SDP testing)
I like the idea of this change, but not the implementation...
[...]
@@ -1865,16 +1867,15 @@ static int workaround_enabled;
void omap2_gpio_prepare_for_idle(int off_mode)
{
int i, c = 0;
- int min = 0;
- if (cpu_is_omap34xx())
- min = 1;
-
- for (i = min; i gpio_bank_count; i++) {
+ for (i = 0; i gpio_bank_count; i++) {
struct gpio_bank *bank = gpio_bank[i];
u32 l1 = 0, l2 = 0;
int j;
+ if (!strcmp(bank-pwrdm_name, wkup_pwrdm))
+ continue;
+
This adds a string compare for every bank during every idle
transistion (and every resume.) That's a lot of unneeded overhead.
I'd rather see a per-bank flag 'looses_context' or something that can be
checked more efficiently in this fast path. This flag can be set based
on the powerdomain name in the device init code.
This looks better. Will do the needful.
One question, can looses_context be made as part of dev_attr?
I guess that's up to Benoît.
But, I don't think that's necessary. It should be easy to set at runtime
just doing a strcmp on the powerdomain during the device init,
omap_device_build phase.
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 v2 2/4] OMAP4: hwmod data: add mmu hwmod for ipu and dsp
Hi Benoit, On Mon, Mar 7, 2011 at 6:55 AM, Cousson, Benoit b-cous...@ti.com wrote: Hi Omar, I have some concern about the introduction of a hwmod that does not match the actual HW capability. MMU does exist, but there is no SW control for it. Maybe I'm missing something, but iommu (driver) is meant to control isp, iva, ipu and dsp MMUs; even with a simple driver interfaced with iommu, that had nothing to do with the modules mentioned, you could still deassert the reset, enable the clocks, create your tables and add entries, and so on... not that it would be useful for anybody other than the real HW containing the MMU subsystem. In fact the only control available is for mmu + cache + logic, and that's why the MMU is handle today under the main DSP/IPU hwmod. AFAIK, sysc configuration is missing from the old hwmods, I thought separate hwmods gave: - flexibility: so the system wouldn't dump_stack trying to read mmu registers, because the user doesn't know ipu/dsp code should handle the reset first. - clarity: so iommu handles its own mmu hwmods instead of hard coding the names of the pseudo hwmods containing the mmu. Here you are just duplicating dsp_hwmod and ipu_hwmod with dsp_mmu_hwmod / ipu_mmu_hwmod and adding some memory space for the mmu part. In that case, you can still use the previous name and add the missing entries in it. The only advantage I can see is the usage of a common class that will allow you to handle both DSP and IPU using the same MMU driver. So, what are you going to do with the remaining entries for dsp_hwmod and ipu_hwmod? I think these can be removed, and iommu code can handle its own hwmods; but if you want to update the old ones, that can be done too, the tradeoff would be that iommu needs to know the name of the hwmods with mmu data. 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
Re: [PATCH 0/3] OMAP: DMA: mstandby mode and runtime pm support
G, Manjunath Kondaiah manj...@ti.com writes: On Fri, Mar 04, 2011 at 09:48:26AM +0530, G, Manjunath Kondaiah wrote: On Thu, Mar 03, 2011 at 10:35:23AM -0800, Kevin Hilman wrote: G, Manjunath Kondaiah manj...@ti.com writes: This patch series is remaining part of dma hwmod to support pm runtime and for handling mstandby mode for all applicable DMA mstandby mode errata. This is still not runtime-suspending when I use my DMA test in linking mode. If I put a large enough period between transfers, it should autosuspend during transfers. It seems to do auto-suspend and resume once, but then it never suspends again. I tested with my dmatest module[1], and loaded with: # insmod ./dmatest.ko linking=1 forever=1 forever_period=1024 Not only does it not auto-suspend between transfers (which I expected), it also doesn't suspend after removing the module which stops all active channels. The normal chaining test cases are executed and which used to show the proper status. Let me reproduce this issue with your test procedure. ok. I am able to reproduce this issue and fixed _get_sync usage in omap_start_dma if channel linking is used. Earlier it was handled for the cases with chaining API's. If linking is done without chaining API's, it will result in _get_sync and _put mismatch. Great, glad you found it. My DMA test module predates the existence of a chaining API, so I guess that's part of the problem. Glad it helped though. Thanks for the test case and I will be re posting the patches with the above fix. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP3: cpuidle: prevent CORE power domain from going to RET or OFF when DSS is on
tero.kri...@nokia.com writes: [...] + /* If DSS is active, prevent CORE RET/OFF */ + dss_state = pwrdm_read_pwrst(dss_pd); + if (dss_state == PWRDM_POWER_ON + core_next_state != PWRDM_POWER_ON) + core_next_state = PWRDM_POWER_INACTIVE; + Due to sleepdeps/autodeps, when this code runs, DSS powerdomain is always on. The result is that CORE is always set to INACTIVE. Now I recall that someone was asking about a patch similar to this earlier, and had the same issue with DSS sleepdep collision. What is the reason for having the sleepdep for DSS powerdomain anyway? At least I can't see any reason why the sleepdep for DSS should be set. In my opinion it should be perfectly okay for DSS domain to idle independently of MPU/CORE, as this is going to be better for power consumption also. Agreed, but currently the sleepdeps with MPU are automatically managed (by clkdm autodeps and hwmod initiator deps.) Until we have merged a solution to more selectively enable sleepdeps (or remove them) $SUBJECT patch cannot be merged. Ok I thought this is the case... it would be possible to implement a temporary/permanent solution that uses idle status check instead of pwrdm state check, and prevent core idle if dss is not going to idle. What is the current status with those idlest patches anyway? Paul will have to answer that one. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: l2x0: Errata fix for flush by Wayoperationcan cause data corruption
On Mon, Mar 07, 2011 at 05:55:22PM +0530, Santosh Shilimkar wrote: Below is the updated version. Also attached. Russell, Do you want me to push this to patch system or you can apply this one? Patch system please. -- To unsubscribe from this list: send the line unsubscribe 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: iommu: disallow mapping NULL address
On Mon, Mar 7, 2011 at 7:10 AM, Michael Jones michael.jo...@matrix-vision.de wrote: From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00 2001 From: Michael Jones michael.jo...@matrix-vision.de Date: Mon, 7 Mar 2011 13:36:15 +0100 Subject: [PATCH] omap: iommu: disallow mapping NULL address commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL address if da_start==0. Force da_start to exclude the first page. what about devices that uses page 0? ipu after reset always starts from 0x how could we map that address?? Regards, Fernando. Signed-off-by: Michael Jones michael.jo...@matrix-vision.de --- arch/arm/plat-omap/iommu.c | 6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c index 5990ea6..dcb5513 100644 --- a/arch/arm/plat-omap/iommu.c +++ b/arch/arm/plat-omap/iommu.c @@ -850,7 +850,7 @@ int iommu_set_da_range(struct iommu *obj, u32 start, u32 end) if (end start || !PAGE_ALIGN(start | end)) return -EINVAL; - obj-da_start = start; + obj-da_start = max(start, (u32)PAGE_SIZE); obj-da_end = end; return 0; @@ -950,7 +950,9 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev) obj-name = pdata-name; obj-dev = pdev-dev; obj-ctx = (void *)obj + sizeof(*obj); - obj-da_start = pdata-da_start; + + /* reserve the first page for NULL */ + obj-da_start = max(pdata-da_start, (u32)PAGE_SIZE); obj-da_end = pdata-da_end; mutex_init(obj-iommu_lock); -- 1.7.4.1 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- To unsubscribe from this list: send the line unsubscribe 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: iommu: disallow mapping NULL address
On Mon, Mar 7, 2011 at 9:17 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Mon, Mar 7, 2011 at 7:10 AM, Michael Jones michael.jo...@matrix-vision.de wrote: From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00 2001 From: Michael Jones michael.jo...@matrix-vision.de Date: Mon, 7 Mar 2011 13:36:15 +0100 Subject: [PATCH] omap: iommu: disallow mapping NULL address commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL address if da_start==0. Force da_start to exclude the first page. what about devices that uses page 0? ipu after reset always starts from 0x how could we map that address?? from 0x0? The driver sees da == 0 as error. May I ask you why do you want it? Br, David Regards, Fernando. Signed-off-by: Michael Jones michael.jo...@matrix-vision.de --- arch/arm/plat-omap/iommu.c | 6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c index 5990ea6..dcb5513 100644 --- a/arch/arm/plat-omap/iommu.c +++ b/arch/arm/plat-omap/iommu.c @@ -850,7 +850,7 @@ int iommu_set_da_range(struct iommu *obj, u32 start, u32 end) if (end start || !PAGE_ALIGN(start | end)) return -EINVAL; - obj-da_start = start; + obj-da_start = max(start, (u32)PAGE_SIZE); obj-da_end = end; return 0; @@ -950,7 +950,9 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev) obj-name = pdata-name; obj-dev = pdev-dev; obj-ctx = (void *)obj + sizeof(*obj); - obj-da_start = pdata-da_start; + + /* reserve the first page for NULL */ + obj-da_start = max(pdata-da_start, (u32)PAGE_SIZE); obj-da_end = pdata-da_end; mutex_init(obj-iommu_lock); -- 1.7.4.1 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- To unsubscribe from this list: send the line unsubscribe 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: iommu: disallow mapping NULL address
On Mon, Mar 7, 2011 at 1:19 PM, David Cohen daco...@gmail.com wrote: On Mon, Mar 7, 2011 at 9:17 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Mon, Mar 7, 2011 at 7:10 AM, Michael Jones michael.jo...@matrix-vision.de wrote: From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00 2001 From: Michael Jones michael.jo...@matrix-vision.de Date: Mon, 7 Mar 2011 13:36:15 +0100 Subject: [PATCH] omap: iommu: disallow mapping NULL address commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL address if da_start==0. Force da_start to exclude the first page. what about devices that uses page 0? ipu after reset always starts from 0x how could we map that address?? from 0x0? The driver sees da == 0 as error. May I ask you why do you want it? unlike DSP that you can load a register with the addres the DSP will boot, IPU core always starts from address 0x, so if you take IPU out of reset it will try to access address 0x0 if not map it, there will be a mmu fault. Regards, Fernando. Br, David Regards, Fernando. Signed-off-by: Michael Jones michael.jo...@matrix-vision.de --- arch/arm/plat-omap/iommu.c | 6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c index 5990ea6..dcb5513 100644 --- a/arch/arm/plat-omap/iommu.c +++ b/arch/arm/plat-omap/iommu.c @@ -850,7 +850,7 @@ int iommu_set_da_range(struct iommu *obj, u32 start, u32 end) if (end start || !PAGE_ALIGN(start | end)) return -EINVAL; - obj-da_start = start; + obj-da_start = max(start, (u32)PAGE_SIZE); obj-da_end = end; return 0; @@ -950,7 +950,9 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev) obj-name = pdata-name; obj-dev = pdev-dev; obj-ctx = (void *)obj + sizeof(*obj); - obj-da_start = pdata-da_start; + + /* reserve the first page for NULL */ + obj-da_start = max(pdata-da_start, (u32)PAGE_SIZE); obj-da_end = pdata-da_end; mutex_init(obj-iommu_lock); -- 1.7.4.1 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- To unsubscribe from this list: send the line unsubscribe 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: protect dmm_map properly
Hi Felipe, On Mon, Mar 7, 2011 at 12:02 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Mon, Dec 20, 2010 at 7:12 PM, Felipe Contreras felipe.contre...@nokia.com wrote: We need to protect not only the dmm_map list, but the individual map_obj's, otherwise, we might be building the scatter-gather list with garbage. So, use the existing proc_lock for that. I observed race conditions which caused kernel panics while running stress tests. This patch fixes those. I just heard that Tuomas Kulve is getting a lot of panics on Gumstix Overo. I propose we apply this patch on the stable tree ASAP, and if there's no better proposals, also on .38. Can you or Tuomas share the bug report data (panic log, test case maybe)? I would like to discard issues affected by timing that could be hidden with this patch. I agree that for the time being this needs to be sent upstream, even if in paper Ohad's patch solves the issue without side effects of locking. Thanks, 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
Re: [PATCH] omap: iommu: disallow mapping NULL address
On Mon, Mar 7, 2011 at 9:25 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Mon, Mar 7, 2011 at 1:19 PM, David Cohen daco...@gmail.com wrote: On Mon, Mar 7, 2011 at 9:17 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Mon, Mar 7, 2011 at 7:10 AM, Michael Jones michael.jo...@matrix-vision.de wrote: From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00 2001 From: Michael Jones michael.jo...@matrix-vision.de Date: Mon, 7 Mar 2011 13:36:15 +0100 Subject: [PATCH] omap: iommu: disallow mapping NULL address commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL address if da_start==0. Force da_start to exclude the first page. what about devices that uses page 0? ipu after reset always starts from 0x how could we map that address?? from 0x0? The driver sees da == 0 as error. May I ask you why do you want it? unlike DSP that you can load a register with the addres the DSP will boot, IPU core always starts from address 0x, so if you take IPU out of reset it will try to access address 0x0 if not map it, there will be a mmu fault. Hm. Looks like the iommu should not restrict any da. The valid da range should rely only on pdata. Michael, what about just update ISP's da_start on omap-iommu.c file? Set it to 0x1000. Hiroshi, any opinion? Br, David Regards, Fernando. Br, David Regards, Fernando. Signed-off-by: Michael Jones michael.jo...@matrix-vision.de --- arch/arm/plat-omap/iommu.c | 6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c index 5990ea6..dcb5513 100644 --- a/arch/arm/plat-omap/iommu.c +++ b/arch/arm/plat-omap/iommu.c @@ -850,7 +850,7 @@ int iommu_set_da_range(struct iommu *obj, u32 start, u32 end) if (end start || !PAGE_ALIGN(start | end)) return -EINVAL; - obj-da_start = start; + obj-da_start = max(start, (u32)PAGE_SIZE); obj-da_end = end; return 0; @@ -950,7 +950,9 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev) obj-name = pdata-name; obj-dev = pdev-dev; obj-ctx = (void *)obj + sizeof(*obj); - obj-da_start = pdata-da_start; + + /* reserve the first page for NULL */ + obj-da_start = max(pdata-da_start, (u32)PAGE_SIZE); obj-da_end = pdata-da_end; mutex_init(obj-iommu_lock); -- 1.7.4.1 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- To unsubscribe from this list: send the line unsubscribe 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 v8 6/7] omap3430: Updating the board file to use TWL4030 scripts
Lesly A M lesl...@ti.com writes: Using TWL4030 power scripts to control the LDOs and DCDC regulators while going to low power mode. Signed-off-by: Lesly A M lesl...@ti.com Minor: Re: Subject: OMAP is an acronym, please capitalize. Cc: Nishanth Menon n...@ti.com Cc: David Derrick dderr...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com --- arch/arm/mach-omap2/Makefile|3 +- arch/arm/mach-omap2/board-3430sdp.c | 93 +-- 2 files changed, 4 insertions(+), 92 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 742ca67..bb11329 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -175,7 +175,8 @@ obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ hsmmc.o obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o \ hsmmc.o \ -board-flash.o +board-flash.o \ +twl4030.o This should not be board-specific in the Makefile, otherwise it will have to be added for every single board that uses it. Rather, it should probably be built as long as CONFIG_TWL4030_POWER=y. Also, please be sure to build test when that option is disabled as well. 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 v8 3/7] omap3: pm: TWL4030 power scripts for OMAP3 boards
Lesly A M lesl...@ti.com writes: Power bus message sequence for TWL4030 to enter sleep/wakeup/warm_reset. TWL4030 power scripts which can be used by different OMAP3 boards with the power companion chip (TWL4030 series). The twl4030 generic script is exported and can be used by any other boardfile to update the power data in twl4030_platform_data. http://omapedia.org/wiki/TWL4030_power_scripts This is a very helpful wiki page, thanks for writing that up. I'd recommend putting a link into the C file as well, saying this code implements the recommended sequence as detailed at wiki page. One minor nit on naming here. I think you should use the public name TWL4030 throughout instead of Triton (which AFAIK, is not an acronym and should not be capitalized.) 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 v8 6/7] omap3430: Updating the board file to use TWL4030 scripts
Kevin Hilman khil...@ti.com writes: Lesly A M lesl...@ti.com writes: Using TWL4030 power scripts to control the LDOs and DCDC regulators while going to low power mode. Signed-off-by: Lesly A M lesl...@ti.com Minor: Re: Subject: OMAP is an acronym, please capitalize. Cc: Nishanth Menon n...@ti.com Cc: David Derrick dderr...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com --- arch/arm/mach-omap2/Makefile|3 +- arch/arm/mach-omap2/board-3430sdp.c | 93 +-- 2 files changed, 4 insertions(+), 92 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 742ca67..bb11329 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -175,7 +175,8 @@ obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ hsmmc.o obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o \ hsmmc.o \ - board-flash.o + board-flash.o \ + twl4030.o This should not be board-specific in the Makefile, otherwise it will have to be added for every single board that uses it. Rather, it should probably be built as long as CONFIG_TWL4030_POWER=y. Also, please be sure to build test when that option is disabled as well. Just notcied that twl4030.c is already wrapped by CONFIG_TWL4030_POWER, so just build it for CONFIG_PM: diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 65d8701..8bdc969 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -61,7 +61,7 @@ ifeq ($(CONFIG_PM),y) obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o pm_bus.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o \ - cpuidle34xx.o pm_bus.o + cpuidle34xx.o pm_bus.o twl4030.o obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o Then, you'll also have to modify twl4030.h so that twl4030_generic_script is NULL when CONFIG_TWL_4030=n so board files will still compile. 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 v8 5/7] mfd: TWL4030: changes for TRITON Errata 27 workaround
Hi Lesly,
Lesly A M lesl...@ti.com writes:
Workaround for TWL5030 Silicon Errata 27 28:
27 - VDD1, VDD2, may have glitches when their output value is updated.
28 - VDD1 and / or VDD2 DCDC clock may stop working when internal clock
is switched from internal to external.
Errata 27:
If the DCDC regulators is running on their internal oscillator,
negative glitches may occur on VDD1, VDD2 output when voltage is
changed.
The OMAP device may reboot if the VDD1 or VDD2 go below the
core minimum operating voltage.
WORKAROUND
Set up the TWL5030 DC-DC power supplies to use the HFCLKIN instead of
the internal oscillator.
Errata 28:
VDD1/VDD2 clock system may hang during switching the clock source from
internal oscillator to external. VDD1/VDD2 output voltages may collapse
if clock stops.
WORKAROUND
If HFCLK is disabled in OFFMODE, modify the sleep/wakeup sequence and
setuptimes to make sure the switching will happen only when HFCLKIN is
stable.
Also use the TWL5030 watchdog to safeguard the first switching from
internal oscillator to HFCLKIN during the TWL5030 init.
IMPACT
power sequence is changed.
sleep/wakeup time values will be changed.
The workaround changes are called from twl4030_power_init(), since we have to
make some i2c_read calls to check the TRITON version the i2c will not be
initialized in the early stage.
This workaround is required for TWL5030 Silicon version less than ES1.2
The power script setup time changes are recommended by TI HW team.
http://omapedia.org/wiki/TWL4030_power_scripts
Changes taken from TRITON Errata27 workaround patch by Nishanth Menon.
Signed-off-by: Lesly A M lesl...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
Some minor comments below,
---
arch/arm/mach-omap2/twl4030.c | 114
+
drivers/mfd/twl4030-power.c | 64 +++
include/linux/i2c/twl.h |1 +
3 files changed, 179 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/twl4030.c b/arch/arm/mach-omap2/twl4030.c
index ff344b3..87de049 100644
--- a/arch/arm/mach-omap2/twl4030.c
+++ b/arch/arm/mach-omap2/twl4030.c
@@ -137,9 +137,123 @@ static struct twl4030_resconfig twl4030_rconfig[] = {
{ 0, 0},
};
+/*
+ * Active to Sleep sequence, which is executed upon P1/P2/P3
+ * transition for sleep.
+ *
+ * The sleep sequence is adjusted to do the switching of VDD1/VDD2/VIO OSC
from
+ * HFCLKIN to internal oscillator when the HFCLKIN is stable.
+ */
+static struct twl4030_ins __initdata sleep_on_seq_errata27[] = {
+ /*
+ * Singular message to disable HCLKOUT.
+ * Wait for ~488.32 uS to do the switching of VDD1/VDD2/VIO OSC from
+ * HFCLKIN to internal oscillator before disabling HFCLKIN.
+ */
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_HFCLKOUT, RES_STATE_SLEEP), 20},
+ /* Broadcast message to put res(TYPE2 = 1) to sleep */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
+ RES_STATE_SLEEP), 2},
+ /* Broadcast message to put res(TYPE2 = 2) to sleep, disable HFCLKIN */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_SLEEP), 2},
+};
+
+static struct twl4030_script sleep_on_script_errata27 __initdata = {
+ .script = sleep_on_seq_errata27,
+ .size = ARRAY_SIZE(sleep_on_seq_errata27),
+ .flags = TWL4030_SLEEP_SCRIPT,
+};
+
+/*
+ * Sleep to Active sequence, which is executed upon P1/P2/P3
+ * transition for wakeup.
+ *
+ * The wakeup sequence is adjusted to do the VDD1/VDD2 voltage rampup
+ * only after HFCLKIN is stabilized and the HFCLKOUT is enabled.
+ */
+static struct twl4030_ins wakeup_seq_errata27[] __initdata = {
+ /*
+ * Broadcast message to put res(TYPE2 = 2) to active.
+ * Wait for ~10 mS (rampup time for OSC on the board)
+ * after HFCLKIN is enabled
+ */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_ACTIVE), 55},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_ACTIVE), 55},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_ACTIVE), 54},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_ACTIVE), 1},
+ /* Singular message to enable HCLKOUT after HFCLKIN is stabilized */
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_HFCLKOUT, RES_STATE_ACTIVE),
Re: [PATCH] omap: iommu: disallow mapping NULL address
Hi David, On Monday 07 March 2011 20:41:21 David Cohen wrote: On Mon, Mar 7, 2011 at 9:25 PM, Guzman Lugo, Fernando wrote: On Mon, Mar 7, 2011 at 1:19 PM, David Cohen wrote: On Mon, Mar 7, 2011 at 9:17 PM, Guzman Lugo, Fernando wrote: On Mon, Mar 7, 2011 at 7:10 AM, Michael Jones wrote: From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00 2001 From: Michael Jones michael.jo...@matrix-vision.de Date: Mon, 7 Mar 2011 13:36:15 +0100 Subject: [PATCH] omap: iommu: disallow mapping NULL address commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL address if da_start==0. Force da_start to exclude the first page. what about devices that uses page 0? ipu after reset always starts from 0x how could we map that address?? from 0x0? The driver sees da == 0 as error. May I ask you why do you want it? unlike DSP that you can load a register with the addres the DSP will boot, IPU core always starts from address 0x, so if you take IPU out of reset it will try to access address 0x0 if not map it, there will be a mmu fault. Hm. Looks like the iommu should not restrict any da. The valid da range should rely only on pdata. Michael, what about just update ISP's da_start on omap-iommu.c file? Set it to 0x1000. What about patching the OMAP3 ISP driver to use a non-zero value (maybe -1) as an invalid/freed pointer ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/8] omap3: pm: TWL4030 power scripts and workaround for TWL errata 27
Lesly A M lesl...@ti.com writes: Patch series for TWL4030 power scripts and workaround for TWL errata 27. Changes for implementing TWL4030 power scripts recommended by hardware team. Introduced a new TWL4030 power script file, which can be used by different OMAP3 board with the power companion chip TWL4030. Updated the changes for TWL4030 errata 27 28, and modified the TWL4030 power script. Workaround for TWL4030 errata 27 28 is required for Si version less than or equal to TWL5030 ES1.1. TWL4030 script changes rebased on Kevin's PM tree in pm branch. This doesn't apply to the current PM branch. I dropped the old scripts from the PM branch some time back. It should be a simple rebase, and only affects PATCH 6/8. After the rebase, it will only add the new stuff to the 3430SDP board file instead of also delete the old scripts. Also, minor nit: please consistenly capitlize acronyms: API, OMAP, etc, and the singular for errata is erattum. This affects subjects, changelogs comments etc. Changes in v7: changes to fix Nishanth Menon's comments i) Added the TWL4030 Errata 27 fix split the first patch in v6 i) fix for twl4030 script load ii) correct the warning print during script loading Added new patch files i) changing sys_off signal polarity Changes in v8: updated the change logs moving the TWL IDCODE checking to twl-core.c Since the voltage layer is evolving to a new design, the voltage dependant changes required for the TRITON script are not incorporated in the patch series. So this TRITON script patch series can be tested with a separate patch for voltage layer changes. lnk: http://pastebin.mozilla.org/1118306 I'm OK with leaving the voltage layer changes for a separate series, but in order to test this should also be rebased against my current PM branch. For future reference, my pm-core branch includes only patches/series that are already queued for upstream, or will be queued for the next merge window. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 REPOST 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
Santosh Shilimkar santosh.shilim...@ti.com writes: Dave, -Original Message- From: Dave Martin [mailto:dave.mar...@linaro.org] Sent: Friday, March 04, 2011 11:05 PM To: linux-arm-ker...@lists.infradead.org Cc: patc...@linaro.org; Tony Lindgren; Santosh Shilimkar; Jean Pihet; Kevin Hilman; linux-omap@vger.kernel.org; Nicolas Pitre; linaro-...@lists.linaro.org Subject: Re: [PATCH v5 REPOST 0/5] ARM: omap[34]: Thumb-2 compatibility fixes On Fri, Mar 4, 2011 at 3:33 PM, Dave Martin dave.mar...@linaro.org wrote: This set of patches, along with some other patches under discussion on alkml, should enable omap3 and omap4 kernels to be built with CONFIG_THUMB2_KERNEL. This patch set builds on recent cleanup done by the omap maintainers. At least some of this code definitely works, most features have been tested successfully. Further testing, especially of Thumb-2 behaviour, is still welcome. In particular, I still have no Ack/Tested-by on the following patches, so it would be great if anyone who has an opportunity to do a final review / re-test can do so. * ARM: omap3: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL * ARM: omap3: Thumb-2 compatibility for sram34xx.S * ARM: omap3: Thumb-2 compatibility for sleep34xx.S Following up on this, it looks like I have some locally-recorded acks which didn't make it into my posting ... The one patch I currently have no feedback on is this one: * ARM: omap4: Provide do_wfi() for Thumb-2 You can drop this one since do_wfi() won't be needed anymore after my recent series. http://www.spinics.net/lists/linux-omap/msg46495.html Santosh, I'm planning to queue/merge Dave's series as-is for 2.6.39, since it has already received significan review testing. When you update your OMAP4 series, feel free to drop it as needed. 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] omap: iommu: disallow mapping NULL address
On Mon, Mar 7, 2011 at 11:19 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi David, Hi Laurent, On Monday 07 March 2011 20:41:21 David Cohen wrote: On Mon, Mar 7, 2011 at 9:25 PM, Guzman Lugo, Fernando wrote: On Mon, Mar 7, 2011 at 1:19 PM, David Cohen wrote: On Mon, Mar 7, 2011 at 9:17 PM, Guzman Lugo, Fernando wrote: On Mon, Mar 7, 2011 at 7:10 AM, Michael Jones wrote: From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00 2001 From: Michael Jones michael.jo...@matrix-vision.de Date: Mon, 7 Mar 2011 13:36:15 +0100 Subject: [PATCH] omap: iommu: disallow mapping NULL address commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL address if da_start==0. Force da_start to exclude the first page. what about devices that uses page 0? ipu after reset always starts from 0x how could we map that address?? from 0x0? The driver sees da == 0 as error. May I ask you why do you want it? unlike DSP that you can load a register with the addres the DSP will boot, IPU core always starts from address 0x, so if you take IPU out of reset it will try to access address 0x0 if not map it, there will be a mmu fault. Hm. Looks like the iommu should not restrict any da. The valid da range should rely only on pdata. Michael, what about just update ISP's da_start on omap-iommu.c file? Set it to 0x1000. What about patching the OMAP3 ISP driver to use a non-zero value (maybe -1) as an invalid/freed pointer ? I wouldn't be comfortable to use 0 (or NULL) value as valid address on ISP driver. The 'da' range (da_start and da_end) is defined per VM and specified as platform data. IMO, to set da_start = 0x1000 seems to be a correct approach for ISP as it's the only client for its IOMMU instance. Regards, David -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: tidspbridge: protect dmm_map properly
On Mon, Mar 7, 2011 at 9:29 PM, Ramirez Luna, Omar omar.rami...@ti.com wrote: On Mon, Mar 7, 2011 at 12:02 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Mon, Dec 20, 2010 at 7:12 PM, Felipe Contreras felipe.contre...@nokia.com wrote: We need to protect not only the dmm_map list, but the individual map_obj's, otherwise, we might be building the scatter-gather list with garbage. So, use the existing proc_lock for that. I observed race conditions which caused kernel panics while running stress tests. This patch fixes those. I just heard that Tuomas Kulve is getting a lot of panics on Gumstix Overo. I propose we apply this patch on the stable tree ASAP, and if there's no better proposals, also on .38. Can you or Tuomas share the bug report data (panic log, test case maybe)? I would like to discard issues affected by timing that could be hidden with this patch. I got this from Tuomas: http://pastie.org/1643677 It seems it's very easy to reproduce on Gumstix Overo with a gst-launch command. The way I reproduced it was very tedious; running a full blown Maemo test suite with GBs of clips. I think the issue is very clear; if you build a sg list with garbage memory, problems are expected =/ I agree that for the time being this needs to be sent upstream, even if in paper Ohad's patch solves the issue without side effects of locking. Perhaps. I don't remember if I ack'ed Ohad's patch, but even if it's ok, I think it can be applied on top of my patch. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] OMAP3: CPUIdle: prevent CORE from going off if doing so would reset an active clockdomain
Hi Tero,
Tero Kristo tero.kri...@nokia.com writes:
On OMAP3 SoCs, if the CORE powerdomain enters off-mode, many other
parts of the chip will be reset. If those parts of the chip are busy,
the reset will disrupt them, causing unpredictable and generally
undesirable results. This reset is caused by the core domain wakeup
(COREDOMAINWKUP_RST), and it can occur for example in a case where
some peripheral domain is in retention or inactive state and core
enters off. This will result in the peripheral domain being reset.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
---
Turns out this one suffers from same problem as the the other DSS one
because of sleepdeps.
In today's linux-omap because of sleepdeps, at least DSS will always
report ON during this check, and I think USB does as well. The result
is that core powerdomain will never hit off-mode.
I'm going to drop this one from my 2.6.39 queue for now as well until
we have a cleaner way to check powerdomain idle status.
Kevin
arch/arm/mach-omap2/cpuidle34xx.c | 40 +++-
1 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index f3e043f..d31b858 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -61,7 +61,7 @@ struct omap3_processor_cx {
struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES];
struct omap3_processor_cx current_cx_state;
struct powerdomain *mpu_pd, *core_pd, *per_pd;
-struct powerdomain *cam_pd;
+struct powerdomain *cam_pd, *dss_pd, *iva2_pd, *sgx_pd, *usb_pd;
/*
* The latencies/thresholds for various C states have
@@ -235,7 +235,7 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
{
struct cpuidle_state *new_state = next_valid_state(dev, state);
u32 core_next_state, per_next_state = 0, per_saved_state = 0;
- u32 cam_state;
+ u32 cam_state, dss_state, iva2_state, sgx_state, usb_state;
struct omap3_processor_cx *cx;
int ret;
@@ -256,6 +256,8 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
*its own code.
*/
+ /* XXX Add CORE-active check here */
+
/*
* Prevent idle completely if CAM is active.
* CAM does not have wakeup capability in OMAP3.
@@ -275,6 +277,36 @@ static int omap3_enter_idle_bm(struct cpuidle_device
*dev,
(core_next_state PWRDM_POWER_RET))
per_next_state = PWRDM_POWER_RET;
+ /* XXX Add prevent-PER-off check here */
+
+ /*
+ * If we are attempting CORE off, check if any other powerdomains
+ * are at retention or higher. CORE off causes chipwide reset which
+ * would reset these domains also.
+ */
+ if (core_next_state == PWRDM_POWER_OFF) {
+ iva2_state = pwrdm_read_pwrst(iva2_pd);
+ sgx_state = pwrdm_read_pwrst(sgx_pd);
+ usb_state = pwrdm_read_pwrst(usb_pd);
+ dss_state = pwrdm_read_pwrst(dss_pd);
Because of existing sleepdeps, some of these may be still on during the
idle path (especially DSS and USB in mainline kernels.)
+ if (cam_state PWRDM_POWER_OFF ||
+ dss_state PWRDM_POWER_OFF ||
+ iva2_state PWRDM_POWER_OFF ||
+ per_next_state PWRDM_POWER_OFF ||
+ sgx_state PWRDM_POWER_OFF ||
+ usb_state PWRDM_POWER_OFF)
+ core_next_state = PWRDM_POWER_RET;
+ }
+
+ /* Fallback to new target core/mpu state */
+ while (cx-core_state core_next_state) {
+ state--;
+ cx = cpuidle_get_statedata(state);
+ }
+
+ new_state = state;
+
/* Are we changing PER target state? */
if (per_next_state != per_saved_state)
pwrdm_set_next_pwrst(per_pd, per_next_state);
@@ -489,6 +521,10 @@ int __init omap3_idle_init(void)
core_pd = pwrdm_lookup(core_pwrdm);
per_pd = pwrdm_lookup(per_pwrdm);
cam_pd = pwrdm_lookup(cam_pwrdm);
+ dss_pd = pwrdm_lookup(dss_pwrdm);
+ iva2_pd = pwrdm_lookup(iva2_pwrdm);
+ sgx_pd = pwrdm_lookup(sgx_pwrdm);
+ usb_pd = pwrdm_lookup(usbhost_pwrdm);
omap_init_power_states();
cpuidle_register_driver(omap3_idle_driver);
--
To unsubscribe from this list: send the line unsubscribe 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 v5 REPOST 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
Dave Martin dave.mar...@linaro.org writes: This set of patches, along with some other patches under discussion on alkml, should enable omap3 and omap4 kernels to be built with CONFIG_THUMB2_KERNEL. This patch set builds on recent cleanup done by the omap maintainers. At least some of this code definitely works, most features have been tested successfully. Further testing, especially of Thumb-2 behaviour, is still welcome. In particular, I still have no Ack/Tested-by on the following patches, so it would be great if anyone who has an opportunity to do a final review / re-test can do so. * ARM: omap3: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL * ARM: omap3: Thumb-2 compatibility for sram34xx.S * ARM: omap3: Thumb-2 compatibility for sleep34xx.S Jean Pihet and I have now done both retention and off-mode testing of these, so I'll add a Tested-by for the last two for Jean and queue these for 2.6.39 in my PM queue git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_2.6.39/pm-misc If you want to do sanity checking with all the other OMAP PM stuff that is queued for 2.6.39, feel free to test with my pm-core branch in the tree above. This has all OMAP PM related changes that will be queued for 2.6.39 integrated. FWIW, I also tested on 3430/n900 (retention and off-mode) and 3630/Zoom3 (retention-only, since the Si rev have has off-mode errata.) Kevin Seems to work with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL enabled on Beagle xM A2 and Panda A1. Thanks also to Santosh Shilimkar and Kevin Hilman for their help with testing so far. v3: * make SMC instruction syntax more consistent * remove do_wfi() in favour of the generic wfi() macro v4: * revert to the OMAP-specific do_wfi() implementation, pending discussion of how generic macros can/should be provided v5: * use ARM for low-level code in mach-omap2/*34xx.S, for correct interoperation with non-Thumb-capable firmware. I've stripped the Acked/Tested-bys from the major patches to mach-omap2/*34xx.S, since the reversion to ARM constitutes a significant change -- I would be grateful if people could re- test / re-review if they have the chance. For best future compatibility, I've left the changes which avoid architecturally deprecated features. Details below. Cheers, Dave The patches can be found, along with a buildable working tree, in the following repo: git://git.linaro.org/people/dmart/linux-2.6-arm.git * arm/omap-thumb2: has the patches proposed here * arm/omap-thumb2+merged: additionally has some patches cherry- picked from other trees which are needed in order for the patches on arm/omap-thumb2 to work usefully. * dirty/arm/omap-thumb2+merged: buildable test tree, which adds 2 local patches to work around a toolchain bug. A working kernel config for this tree is here: http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config : CONFIG_SMP_ON_UP=y CONFIG_THUMB2_KERNEL=y CONFIG_SERIAL_OMAP=y (to avoid garbage on xM; for Panda use console=ttyS2) (The config is derived from the linaro omap config and so turns on loads of modules -- don't feel you have to build them all...) Cherry-picked patches originated from Russell's devel tree and Tony Lindgren's omap-testing tree: http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git devel git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-testing This series also depends on one un-merged patch to generic-ise the wfi() macro: git://git.linaro.org/people/dmart/linux-2.6-arm.git arm/wfi-macro Dave Martin (5): ARM: omap4: Provide do_wfi() for Thumb-2 ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL ARM: omap3: Remove hand-encoded SMC instructions ARM: omap3: Thumb-2 compatibility for sram34xx.S ARM: omap3: Thumb-2 compatibility for sleep34xx.S arch/arm/mach-omap2/include/mach/omap4-common.h |4 ++ arch/arm/mach-omap2/omap-headsmp.S |2 +- arch/arm/mach-omap2/omap44xx-smc.S |8 ++-- arch/arm/mach-omap2/sleep34xx.S | 62 ++ arch/arm/mach-omap2/sram34xx.S | 36 ++--- 5 files changed, 87 insertions(+), 25 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP3+: OPP: Replace voltage values with Macros
Nishanth Menon n...@ti.com writes: From: Vishwanath BS vishwanath...@ti.com Since all voltage data is now centralized in oppxxx_data.c, we can replace the values in the opp table with the macros used for voltage values. This will avoid opp table and voltage layer having conflicting values. Signed-off-by: Vishwanath BS vishwanath...@ti.com As you are now on the delivery path too, this should have your sign-off. Assuming this is a simple oversight, I added your signoff and queued for 2.6.39 (branch: for_2.6.39/pm-misc) Thanks, 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 V2 0/3]: OMAP4: Update OPP Table and Voltage Rail Values
Shweta Gulati shweta.gul...@ti.com writes: The Series Updates OPP Table for MPU, add OPP enteries for IVA and update Voltage Rail values for MPU/IVA. It is based on the Patch which replaces Voltage values with Macros, Submitted by Nishanth Menon https://patchwork.kernel.org/patch/607541/ Branch: pm-core Tested on OMAP4430 SDP. V2: Rebased on pm-core and incorporated comments from Nishanth Menon. This version looks OK to me. Will queue for 2.6.39 after I see an Ack from Nishanth. Thanks, Kevin Shweta Gulati (3): OMAP4: Enable 800 MHz and 1 GHz OPP for OMAP4. OMAP4: Update Voltage Rail Values for MPU/IVA OMAP4: Add IVA OPP enteries. arch/arm/mach-omap2/opp4xxx_data.c | 26 -- 1 files changed, 16 insertions(+), 10 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 -- To unsubscribe from this list: send the line unsubscribe 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: Integration branch base switchover to Tony's omap-for-linus branch
Hi Rajendra, Santosh,
On Fri, 4 Mar 2011, Rajendra Nayak wrote:
On Thursday 03 March 2011 06:00 PM, Rajendra Nayak wrote:
Also some more testing showed up a lockup in suspend on OMAP4 which I
could narrow down to a similar case with GPT1. Either keeping the
staticdep between MPU and L4_WKUP _or_ forcing GPT1 to use software
idle control seems to help.
This however is still not rootcaused and is not the same as the issue
seen with i2c as the WE for GPT1 is already programmed for enabling
wakeup.
The one way to fix this for now is to put GPT1 block in software
controlled idle as was done by your test patch for i2c.
OK, thanks for the update.
Benoît, do you have any more OMAP4 hwmod patches for 2.6.39? If not, want
to send an Acked-by:, and either Tony or I will take this one?
- Paul
---
From fde94c22bb2db233b0b0cc4c2024d6f4e9f95257 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak rna...@ti.com
Date: Fri, 4 Mar 2011 19:33:45 +0530
Subject: [PATCH] OMAP4: hwmod: Disable hardware-controlled idle for GPT1
Some issues seen (which cause lockups in suspend) with GPT1
after the MPU-L4_WKUP static dependency was cleared can be
Worked-around for now by forcing GPT1 in software
controlled idle.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 2c58827..9317a05 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3989,7 +3989,7 @@ static struct omap_hwmod_ocp_if
*omap44xx_timer1_slaves[] = {
static struct omap_hwmod omap44xx_timer1_hwmod = {
.name = timer1,
.class = omap44xx_timer_1ms_hwmod_class,
- .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
HWMOD_SWSUP_SIDLE,
.mpu_irqs = omap44xx_timer1_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_timer1_irqs),
.main_clk = timer1_fck,
--
1.7.0.4
- Paul
Re: [PATCH v11 6/8] dmtimer: switch-over to platform device driver
* DebBarma, Tarun Kanti tarun.ka...@ti.com [110307 04:52]: I agree with Tony. We can still registers only the system timer because the timer ID is known well before we do initialization. I must say, there was a gap in my understanding of the comment. So, here is the implementation change: - Call omap2_dm_timer_early_init(u8 gptimer_id) from omap2_gp_timer_init() - Initialize only gptimer_id inside this function - In the regular init skip initialization of gptimer_id As a result of this, we can rid of double registration and related code. I suggest we keep the system timer completely separate from the rest of the timers. This way we avoid adding hwmod dependencies early on when the system timer is initialized, and can still use hwmod for handling the the rest of the timers nicely. The rest of the timers can then become just a regular device driver that ignores the physical system timer. 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 v11 7/8] OMAP: dmtimer: pm_runtime support
* DebBarma, Tarun Kanti tarun.ka...@ti.com [110304 16:20]: Now, coming back to our present requirement where we initialize Only the system timer early and is skipped later, here is the plan: (1) Have a separate class in hwmod database with unique name system_timer (2) Initialize just this one during early init Let's keep the system timer code completely separate. For the system timer we really just need to implement one function to reprogram one timer. What you've implemented is pretty much done for the rest of the timers and allows us to turn them into a regular device driver eventually. 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 v11 6/8] dmtimer: switch-over to platform device driver
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, March 08, 2011 5:37 AM To: DebBarma, Tarun Kanti Cc: Shilimkar, Santosh; linux-omap@vger.kernel.org Subject: Re: [PATCH v11 6/8] dmtimer: switch-over to platform device driver * DebBarma, Tarun Kanti tarun.ka...@ti.com [110307 04:52]: I agree with Tony. We can still registers only the system timer because the timer ID is known well before we do initialization. I must say, there was a gap in my understanding of the comment. So, here is the implementation change: - Call omap2_dm_timer_early_init(u8 gptimer_id) from omap2_gp_timer_init() - Initialize only gptimer_id inside this function - In the regular init skip initialization of gptimer_id As a result of this, we can rid of double registration and related code. I suggest we keep the system timer completely separate from the rest of the timers. This way we avoid adding hwmod dependencies early on when the system timer is initialized, and can still use hwmod for handling the the rest of the timers nicely. Yes, just the system timer is initialized now. We just call omap_hwmod_setup_one() to initialize system timer. The rest of the timers can then become just a regular device driver that ignores the physical system timer. Right, system timer is NOT touched at all later. 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 v11 7/8] OMAP: dmtimer: pm_runtime support
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, March 08, 2011 5:40 AM To: DebBarma, Tarun Kanti Cc: Hilman, Kevin; linux-omap@vger.kernel.org; Basak, Partha Subject: Re: [PATCH v11 7/8] OMAP: dmtimer: pm_runtime support * DebBarma, Tarun Kanti tarun.ka...@ti.com [110304 16:20]: Now, coming back to our present requirement where we initialize Only the system timer early and is skipped later, here is the plan: (1) Have a separate class in hwmod database with unique name system_timer (2) Initialize just this one during early init Let's keep the system timer code completely separate. For the system timer we really just need to implement one function to reprogram one timer. What you've implemented is pretty much done for the rest of the timers and allows us to turn them into a regular device driver eventually. YES. So, this proposal of mine can be ignored now. 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 v3] OMAP3+: OPP: Replace voltage values with Macros
Kevin Hilman wrote, on 03/08/2011 03:45 AM: Nishanth Menonn...@ti.com writes: From: Vishwanath BSvishwanath...@ti.com Since all voltage data is now centralized in oppxxx_data.c, we can replace the values in the opp table with the macros used for voltage values. This will avoid opp table and voltage layer having conflicting values. Signed-off-by: Vishwanath BSvishwanath...@ti.com As you are now on the delivery path too, this should have your sign-off. Assuming this is a simple oversight, I added your signoff and queued for 2.6.39 (branch: for_2.6.39/pm-misc) thanks. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe 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] OMAP PM: create a PM layer plugin for the devices wakeup latency constraints
Jean Pihet jean.pi...@newoldbits.com writes:
Created arch/arm/plat-omap/omap-pm-constraints.c file from
arch/arm/plat-omap/omap-pm-noop.c and the associated Kconfig option
OMAP_PM_CONSTRAINTS.
Based on the original patch from Vishwanath,
cf. https://patchwork.kernel.org/patch/327312/
Cc: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
Based on khilman's pm-core branch
arch/arm/plat-omap/Kconfig |7 +
arch/arm/plat-omap/Makefile |1 +
arch/arm/plat-omap/omap-pm-constraints.c | 363
++
3 files changed, 371 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/omap-pm-constraints.c
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index b6333ae..b8f51e3 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -215,6 +215,13 @@ config OMAP_PM_NONE
config OMAP_PM_NOOP
bool No-op/debug PM layer
+config OMAP_PM_CONSTRAINTS
+ depends on PM
+ bool OMAP PM layer implementation, devices wakeup latency constraints
Minor: The 'OMAP PM layer implmentatin' is redundant here as it's a sub-choice
of the OMAP PM layer menu. How abou just per-device constraint
Kevin
+ help
+ Select this option to enable the PM layer plugin for
+ the devices wakeup latency constraints support
+
endchoice
endmenu
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index a4a1285..a293367 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -32,3 +32,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
+obj-$(CONFIG_OMAP_PM_CONSTRAINTS) += omap-pm-constraints.o
diff --git a/arch/arm/plat-omap/omap-pm-constraints.c
b/arch/arm/plat-omap/omap-pm-constraints.c
new file mode 100644
index 000..c8b4e4c
--- /dev/null
+++ b/arch/arm/plat-omap/omap-pm-constraints.c
@@ -0,0 +1,363 @@
+/*
+ * omap-pm.c - OMAP power management interface
+ *
+ * This code implements the OMAP power management interface to
+ * drivers, CPUIdle, CPUFreq, and DSP Bridge.
+ *
+ * Copyright (C) 2008-2009 Texas Instruments, Inc.
+ * Copyright (C) 2008-2009 Nokia Corporation
+ * Paul Walmsley
+ *
+ * Interface developed by (in alphabetical order):
+ * Karthik Dasu, Tony Lindgren, Jean Pihet, Rajendra Nayak, Sakari Poussa,
+ * Veeramanikandan Raju, Anand Sawant, Igor Stoppa, Paul Walmsley,
+ * Richard Woodruff
+ */
+
+#undef DEBUG
+
+#include linux/init.h
+#include linux/cpufreq.h
+#include linux/device.h
+#include linux/platform_device.h
+
+/* Interface documentation is in mach/omap-pm.h */
+#include plat/omap-pm.h
+#include plat/omap_device.h
+
+static bool off_mode_enabled;
+static u32 dummy_context_loss_counter;
+
+/*
+ * Device-driver-originated constraints (via board-*.c files)
+ */
+
+int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t)
+{
+ if (!dev || t -1) {
+ WARN(1, OMAP PM: %s: invalid parameter(s), __func__);
+ return -EINVAL;
+ };
+
+ if (t == -1)
+ pr_debug(OMAP PM: remove max MPU wakeup latency constraint:
+ dev %s\n, dev_name(dev));
+ else
+ pr_debug(OMAP PM: add max MPU wakeup latency constraint:
+ dev %s, t = %ld usec\n, dev_name(dev), t);
+
+ /*
+ * For current Linux, this needs to map the MPU to a
+ * powerdomain, then go through the list of current max lat
+ * constraints on the MPU and find the smallest. If
+ * the latency constraint has changed, the code should
+ * recompute the state to enter for the next powerdomain
+ * state.
+ *
+ * TI CDP code can call constraint_set here.
+ */
+
+ return 0;
+}
+
+int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long
r)
+{
+ if (!dev || (agent_id != OCP_INITIATOR_AGENT
+ agent_id != OCP_TARGET_AGENT)) {
+ WARN(1, OMAP PM: %s: invalid parameter(s), __func__);
+ return -EINVAL;
+ };
+
+ if (r == 0)
+ pr_debug(OMAP PM: remove min bus tput constraint:
+ dev %s for agent_id %d\n, dev_name(dev), agent_id);
+ else
+ pr_debug(OMAP PM: add min bus tput constraint:
+ dev %s for agent_id %d: rate %ld KiB\n,
+ dev_name(dev), agent_id, r);
+
+ /*
+ * This code should model the interconnect and compute the
+ * required clock frequency, convert that to a VDD2 OPP ID, then
+ * set the VDD2 OPP appropriately.
+ *
+ * TI CDP code can call constraint_set here on the VDD2 OPP.
+ */
+
+ return 0;
+}
+
+int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device
*dev,
+long
Re: [PATCH V3 03/19] OMAP3+: voltage: remove initial voltage
On Mon, Mar 07, 2011 at 07:23:15PM +0300, Sergei Shtylyov wrote: Hello. On 07-03-2011 5:52, Nishanth Menon wrote: Blindly setting a 1.2V setting Hm, seems tautological... As a non native English speaker, I would like to understand how we could improve this. I suppose you mean Blindly setting 1.2V is better here. Am i correct? Yes. OK, here is the update as per the suggestion: Regards, Nishanth Menon From: Nishanth Menon n...@ti.com Date: Tue, 15 Feb 2011 09:37:18 +0530 Subject: [PATCH V4 3/19] OMAP3+: voltage: remove initial voltage Blindly setting 1.2V in the initial structure may not even match the default voltages stored in the voltage table which are supported for the domain. For example, OMAP3430 core domain does not use 1.2V and ends up generating a warning on the first transition. Further, since omap2_set_init_voltage is called as part of the pm framework's initialization sequence to configure the voltage required for the current OPP, the call does(and has to) setup the system voltage(curr_volt as a result) using the right mechanisms appropriate for the system at that point of time. This also overrides initialization we are currently doing in voltage.c making it redundant. So, remove the wrong and redundant initialization. Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/voltage.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c index 56961df..1b40aa0 100644 --- a/arch/arm/mach-omap2/voltage.c +++ b/arch/arm/mach-omap2/voltage.c @@ -116,7 +116,6 @@ static int __init _config_common_vdd_data(struct omap_vdd_info *vdd) sys_clk_speed /= 1000; /* Generic voltage parameters */ - vdd-curr_volt = 120; vdd-volt_scale = vp_forceupdate_scale_voltage; vdd-vp_enabled = false; -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/3] OMAP4: Enable 800 MHz and 1 GHz MPU-OPP
Shweta Gulati wrote, on 03/05/2011 03:21 PM:
Almost all OMAP4 boards support OPP 800 MHz and OPP 1 GHz.
Enable them in OPP Table. For small minority of boards which use
OMAP4430-800 MHz device OPP 1GHz is not supported,
OPP 1GHz should be disabled from board file.
Signed-off-by: Shweta Gulatishweta.gul...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/mach-omap2/opp4xxx_data.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
index 57f1498..93b9744 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -71,9 +71,9 @@ static struct omap_opp_def __initdata omap44xx_opp_def_list[]
= {
/* MPU OPP2 - OPP100 */
OPP_INITIALIZER(mpu, true, 6, OMAP4430_VDD_MPU_OPP100_UV),
/* MPU OPP3 - OPP-Turbo */
- OPP_INITIALIZER(mpu, false, 8, OMAP4430_VDD_MPU_OPPTURBO_UV),
+ OPP_INITIALIZER(mpu, true, 8, OMAP4430_VDD_MPU_OPPTURBO_UV),
/* MPU OPP4 - OPP-SB */
- OPP_INITIALIZER(mpu, false, 100800, OMAP4430_VDD_MPU_OPPNITRO_UV),
+ OPP_INITIALIZER(mpu, true, 100800, OMAP4430_VDD_MPU_OPPNITRO_UV),
/* L3 OPP1 - OPP50 */
OPP_INITIALIZER(l3_main_1, true, 1,
OMAP4430_VDD_CORE_OPP50_UV),
/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
Acked-by: Nishanth Menon n...@ti.com
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe 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 2/3] OMAP4: Update Voltage Rail Values for MPU/IVA
Shweta Gulati wrote, on 03/05/2011 03:21 PM:
Update MPU/IVA voltage Rail values obtained from
OMAP4430 Data Manual Operating Condition Addendum_v0.3.
Tested on OMAP4430 SDP Board.
Signed-off-by: Shweta Gulatishweta.gul...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/mach-omap2/opp4xxx_data.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
index 93b9744..36a4517 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -31,10 +31,10 @@
* voltage dependent data for each VDD.
*/
-#define OMAP4430_VDD_MPU_OPP50_UV 93
-#define OMAP4430_VDD_MPU_OPP100_UV 110
-#define OMAP4430_VDD_MPU_OPPTURBO_UV 126
-#define OMAP4430_VDD_MPU_OPPNITRO_UV 135
+#define OMAP4430_VDD_MPU_OPP50_UV 1025000
+#define OMAP4430_VDD_MPU_OPP100_UV 120
+#define OMAP4430_VDD_MPU_OPPTURBO_UV 1313000
+#define OMAP4430_VDD_MPU_OPPNITRO_UV 1375000
struct omap_volt_data omap44xx_vdd_mpu_volt_data[] = {
VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPP50_UV,
OMAP44XX_CONTROL_FUSE_MPU_OPP50, 0xf4, 0x0c),
@@ -44,9 +44,9 @@ struct omap_volt_data omap44xx_vdd_mpu_volt_data[] = {
VOLT_DATA_DEFINE(0, 0, 0, 0),
};
-#define OMAP4430_VDD_IVA_OPP50_UV 93
-#define OMAP4430_VDD_IVA_OPP100_UV 110
-#define OMAP4430_VDD_IVA_OPPTURBO_UV 126
+#define OMAP4430_VDD_IVA_OPP50_UV 1013000
+#define OMAP4430_VDD_IVA_OPP100_UV 1188000
+#define OMAP4430_VDD_IVA_OPPTURBO_UV 130
struct omap_volt_data omap44xx_vdd_iva_volt_data[] = {
VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPP50_UV,
OMAP44XX_CONTROL_FUSE_IVA_OPP50, 0xf4, 0x0c),
Acked-by: Nishanth Menon n...@ti.com
Side note: unrelated to this patch: PMICs have discrete step sizes of
10mV, 12.5, 25mV etc.. which makes something lik 1.118V probably not
exactly possible on a PMIC with 25mV step. We need to next probably
create a framework to round_up the voltages to the PMIC step size once
the PMIC voltage layer changes are in.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe 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 3/3] OMAP4: Add IVA OPP enteries.
Shweta Gulati wrote, on 03/05/2011 03:22 PM:
This Patch adds OPP enteries for IVA in OMAP4 OPP Table
Tested on OMAP4430 SDP Board.
Signed-off-by: Shweta Gulatishweta.gul...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/mach-omap2/opp4xxx_data.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
index 36a4517..ba5eddd 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -78,7 +78,13 @@ static struct omap_opp_def __initdata
omap44xx_opp_def_list[] = {
OPP_INITIALIZER(l3_main_1, true, 1,
OMAP4430_VDD_CORE_OPP50_UV),
/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
OPP_INITIALIZER(l3_main_1, true, 2,
OMAP4430_VDD_CORE_OPP100_UV),
- /* TODO: add IVA, DSP, aess, fdif, gpu */
+ /* IVA OPP1 - OPP50 */
+ OPP_INITIALIZER(iva, true, 13300, OMAP4430_VDD_IVA_OPP50_UV),
+ /* IVA OPP2 - OPP100 */
+ OPP_INITIALIZER(iva, true, 26610, OMAP4430_VDD_IVA_OPP100_UV),
+ /* IVA OPP3 - OPP-Turbo */
+ OPP_INITIALIZER(iva, false, 33200, OMAP4430_VDD_IVA_OPPTURBO_UV),
+ /* TODO: add DSP, aess, fdif, gpu */
};
/**
Acked-by: Nishanth Menon n...@ti.com
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP: PM: implement devices wakeup latency constraints APIs
Jean Pihet jean.pi...@newoldbits.com writes:
Implement OMAP PM layer omap_pm_set_max_dev_wakeup_lat API by
creating similar APIs at the omap_device and omap_hwmod levels. The
omap_hwmod level call is the layer with access to the powerdomain
core, so it is the place where the powerdomain is queried to set and
release the constraints.
NOTE: only works for devices which have been converted to use
omap_device/omap_hwmod.
Longer term, we could possibly remove this API from the OMAP PM layer,
and instead directly use the device level API.
The power domains get the next power state programmed directly in
the registers via pwrdm_wakeuplat_update_pwrst.
Note about PM QOS: the MPU and CORE power domains get the next power
state via cpuidle, which get the strongest wake-up latency constraint
by querying PM QOS. The usage of PM QOS is temporary, until a generic
solution is in place.
Based on Vibhore's original patch, adapted to omap_device, omap_hwmod
and PM QOS frameworks.
I haven't got to a detailed review of this code yet, but did do some
experiements and have some general comments on the code/design to get
started.
Also, I had a problem doing a real dumb test until I figured out the
problem with the init sequence. I tried setting a constraint in the
device init code for UART (mach-omap2/serial.c:omap_serial_init_port()),
and then I realized that that runs before
mach-omap2/pm34xx.c:pwrdms_setup() which also calls
omap_set_pwrdm_state() for each powerdomain to initialize.
Also, for debug purposes, it might be useful to have a per-device sysfs
interface to setting this wakeup latency constraint. Something like
/sys/devices/platform/omap/.../power/wakeup_latency
I'm not sure exactly what to set the requesting device to though.
As far as implementation goes, you've so far implemented only wakeup
latencies, but not througput. When you implement throughput you will
have to duplicate large parts of this code and data structures for
throughput, and if ever add some other constraint (frequency, voltage)
it would need to be duplicated again.
Maybe now is the time to consider an interface to add a generic
per-device constraint, with a type (latency, throughput, etc.), or
class as it's called in PM QoS. For now the type/class does not need
to be exposed externally, but will make implementing new constraint
types much easer.
Some other comments below...
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Vibhore Vardhan vvard...@ti.com
---
Based on khilman's pm-core branch
arch/arm/mach-omap2/omap_hwmod.c | 62 -
arch/arm/mach-omap2/powerdomain.c | 197
+
arch/arm/mach-omap2/powerdomain.h | 39 +-
arch/arm/mach-omap2/powerdomains3xxx_data.c | 60
arch/arm/plat-omap/include/plat/omap_device.h |2 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +
arch/arm/plat-omap/omap-pm-constraints.c | 121 +++
arch/arm/plat-omap/omap_device.c | 28
8 files changed, 446 insertions(+), 65 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 028efda..bad8248 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -142,6 +142,7 @@
#include powerdomain.h
#include plat/clock.h
#include plat/omap_hwmod.h
+#include plat/omap_device.h
#include plat/prcm.h
#include cm2xxx_3xxx.h
@@ -2267,10 +2268,69 @@ ohsps_unlock:
}
/**
+ * omap_hwmod_set_max_dev_wakeup_lat - set a device wake-up constraint
+ * @oh: the device of @oh to set a constraint on.
+ * @req_oh: the device of @req_oh is the requester of the constraint.
+ * @t: wakeup latency constraint (us). -1 removes the existing constraint.
+ *
+ * Query the powerdomain of @oh to set/release the wake-up constraint.
+ * @oh is used to determine which power domain to set a constraint on.
+ * @req_oh is used to record the requester for later update or removal
+ * of a constraint.
+ *
+ * Returns -EINVAL if @oh or @req_oh have no power domain, or the return
+ * code from the pwrdm function (pwrdm_wakeuplat_set/release_constraint)
+ * of the powerdomain assocated with @oh.
+ */
+int omap_hwmod_set_max_dev_wakeup_lat(struct omap_hwmod *req_oh,
+ struct omap_hwmod *oh, long t)
+{
+ struct device *req_dev;
+ struct platform_device *req_pdev;
+ struct powerdomain *pwrdm;
+
+ pwrdm = omap_hwmod_get_pwrdm(oh);
+
+ /* Catch devices with undefined powerdomains */
+ if (!PTR_ERR(pwrdm)) {
+ pr_err(omap_hwmod: Error: could not find parent
+ powerdomain for %s\n, oh-name);
+ return -EINVAL;
+ }
+
+ req_pdev = (req_oh-od-pdev);
+ if (!PTR_ERR(req_pdev)) {
+ pr_err(omap_hwmod: Error: pdev not found for oh %s\n,
+oh-name);
+ return
[PATCH 0/3] OMAP2+: powerdomain: add fn to determine whether pwrdm is always on
Hello, this series adds an OMAP powerdomain API function that allows its callers to determine whether a particular powerdomain can ever lose register or memory bank context while the SoC is powered. This is intended for use by driver-subarch integration code (i.e., arch/arm/*omap*) to pass a flag to the driver to determine whether it is necessary to save and restore driver context. As part of this series, fix some long-standing bugs in the powerdomain data. These fixes are necessary for this function to work, and also for OSWR support. Tested on OMAP35xx BeagleBoard and OMAP44xx Pandaboard. - Paul pwrdm_add_can_lose_context_fns_2.6.39 textdata bss dec hex filename 5795912 501512 5598936 11896360 b58628 vmlinux.omap2plus_defconfig.orig 5796064 501512 5598936 11896512 b586c0 vmlinux.omap2plus_defconfig Paul Walmsley (3): OMAP2/3: WKUP powerdomain: mark as being always on OMAP2+: powerdomain: fix bank power state bitfields OMAP2+: powerdomain: add pwrdm_can_ever_lose_context() arch/arm/mach-omap2/powerdomain.c| 43 +++ arch/arm/mach-omap2/powerdomain.h| 18 ++--- arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c |9 +- arch/arm/mach-omap2/powerdomains2xxx_data.c | 18 ++--- arch/arm/mach-omap2/powerdomains3xxx_data.c | 38 +- arch/arm/mach-omap2/powerdomains44xx_data.c | 84 +++--- 6 files changed, 125 insertions(+), 85 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP2/3: WKUP powerdomain: mark as being always on
Mark the WKUP powerdomain as being always on -- at least, as long as the
chip has power. This will be used to enable the powerdomain code to
determine whether a given powerdomain is ever able to power off. While
here, update the file copyright.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c
b/arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c
index 5b4dd97..96cda13 100644
--- a/arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c
@@ -2,7 +2,7 @@
* OMAP2/3 common powerdomain definitions
*
* Copyright (C) 2007-2008 Texas Instruments, Inc.
- * Copyright (C) 2007-2010 Nokia Corporation
+ * Copyright (C) 2007-2011 Nokia Corporation
*
* Paul Walmsley, Jouni Högander
*
@@ -76,4 +76,5 @@ struct powerdomain wkup_omap2_pwrdm = {
.name = wkup_pwrdm,
.prcm_offs = WKUP_MOD,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX | CHIP_IS_OMAP3430),
+ .pwrsts = PWRSTS_ON,
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] OMAP2+: powerdomain: add pwrdm_can_ever_lose_context()
Some drivers wish to know whether the device that they control can
ever lose context, for example, when the device's enclosing
powerdomain loses power. They can use this information to determine
whether it is necessary to save and restore device context, or whether
it can be skipped. Implement the powerdomain portion of this by
adding the function pwrdm_can_ever_lose_context(). This is not for
use directly from driver code, but instead is intended to be called
from driver-subarch integration code (i.e., arch/arm/*omap* code).
Currently, the result from this function should be passed into the
driver code via struct platform_data, but at some point this should
be part of some common or OMAP-specific device code.
While here, update file copyrights.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/powerdomain.c | 43 -
arch/arm/mach-omap2/powerdomain.h | 18 +++
2 files changed, 50 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index eaed0df..a11be81 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -2,7 +2,7 @@
* OMAP powerdomain control
*
* Copyright (C) 2007-2008 Texas Instruments, Inc.
- * Copyright (C) 2007-2009 Nokia Corporation
+ * Copyright (C) 2007-2011 Nokia Corporation
*
* Written by Paul Walmsley
* Added OMAP4 specific support by Abhijit Pagare abhijitpag...@ti.com
@@ -938,3 +938,44 @@ u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm)
return count;
}
+
+/**
+ * pwrdm_can_ever_lose_context - can this powerdomain ever lose context?
+ * @pwrdm: struct powerdomain *
+ *
+ * Given a struct powerdomain * @pwrdm, returns 1 if the powerdomain
+ * can lose either memory or logic context or if @pwrdm is invalid, or
+ * returns 0 otherwise. This function is not concerned with how the
+ * powerdomain registers are programmed (i.e., to go off or not); it's
+ * concerned with whether it's ever possible for this powerdomain to
+ * go off while some other part of the chip is active. This function
+ * assumes that every powerdomain can go to either ON or INACTIVE.
+ */
+bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm)
+{
+ int i;
+
+ if (IS_ERR_OR_NULL(pwrdm)) {
+ pr_debug(powerdomain: %s: invalid powerdomain pointer\n,
+__func__);
+ return 1;
+ }
+
+ if (pwrdm-pwrsts PWRSTS_OFF)
+ return 1;
+
+ if (pwrdm-pwrsts PWRSTS_RET) {
+ if (pwrdm-pwrsts_logic_ret PWRSTS_OFF)
+ return 1;
+
+ for (i = 0; i pwrdm-banks; i++)
+ if (pwrdm-pwrsts_mem_ret[i] PWRSTS_OFF)
+ return 1;
+ }
+
+ for (i = 0; i pwrdm-banks; i++)
+ if (pwrdm-pwrsts_mem_on[i] PWRSTS_OFF)
+ return 1;
+
+ return 0;
+}
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 0b7a357..027f40b 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -2,7 +2,7 @@
* OMAP2/3/4 powerdomain control
*
* Copyright (C) 2007-2008, 2010 Texas Instruments, Inc.
- * Copyright (C) 2007-2010 Nokia Corporation
+ * Copyright (C) 2007-2011 Nokia Corporation
*
* Paul Walmsley
*
@@ -34,17 +34,14 @@
/* Powerdomain allowable state bitfields */
#define PWRSTS_ON (1 PWRDM_POWER_ON)
+#define PWRSTS_INACTIVE(1 PWRDM_POWER_INACTIVE)
+#define PWRSTS_RET (1 PWRDM_POWER_RET)
#define PWRSTS_OFF (1 PWRDM_POWER_OFF)
-#define PWRSTS_OFF_ON ((1 PWRDM_POWER_OFF) | \
-(1 PWRDM_POWER_ON))
-#define PWRSTS_OFF_RET ((1 PWRDM_POWER_OFF) | \
-(1 PWRDM_POWER_RET))
-
-#define PWRSTS_RET_ON ((1 PWRDM_POWER_RET) | \
-(1 PWRDM_POWER_ON))
-
-#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 PWRDM_POWER_ON))
+#define PWRSTS_OFF_ON (PWRSTS_OFF | PWRSTS_ON)
+#define PWRSTS_OFF_RET (PWRSTS_OFF | PWRSTS_RET)
+#define PWRSTS_RET_ON (PWRSTS_RET | PWRSTS_ON)
+#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | PWRSTS_ON)
/* Powerdomain flags */
@@ -211,6 +208,7 @@ int pwrdm_pre_transition(void);
int pwrdm_post_transition(void);
int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm);
u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
+bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm);
extern void omap2xxx_powerdomains_init(void);
extern void omap3xxx_powerdomains_init(void);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] OMAP2+: powerdomain: fix bank power state bitfields
The bank power state bitfields in the powerdomain data are
encoded incorrectly. These fields are intended to be bitfields,
representing a set of power states that the memory banks support.
However, when only one power state was supported by a given bank,
the field was incorrectly set to the bit shift -- not the mask.
While here, update some file copyrights.
The OMAP4 autogeneration scripts have been updated accordingly.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c |6 +-
arch/arm/mach-omap2/powerdomains2xxx_data.c | 18 ++---
arch/arm/mach-omap2/powerdomains3xxx_data.c | 38 +-
arch/arm/mach-omap2/powerdomains44xx_data.c | 84 +++---
4 files changed, 73 insertions(+), 73 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c
b/arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c
index 96cda13..4210c33 100644
--- a/arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c
@@ -62,13 +62,13 @@ struct powerdomain gfx_omap2_pwrdm = {
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP24XX |
CHIP_IS_OMAP3430ES1),
.pwrsts = PWRSTS_OFF_RET_ON,
- .pwrsts_logic_ret = PWRDM_POWER_RET,
+ .pwrsts_logic_ret = PWRSTS_RET,
.banks= 1,
.pwrsts_mem_ret = {
- [0] = PWRDM_POWER_RET, /* MEMRETSTATE */
+ [0] = PWRSTS_RET, /* MEMRETSTATE */
},
.pwrsts_mem_on= {
- [0] = PWRDM_POWER_ON, /* MEMONSTATE */
+ [0] = PWRSTS_ON, /* MEMONSTATE */
},
};
diff --git a/arch/arm/mach-omap2/powerdomains2xxx_data.c
b/arch/arm/mach-omap2/powerdomains2xxx_data.c
index 78739e1..cc389fb 100644
--- a/arch/arm/mach-omap2/powerdomains2xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains2xxx_data.c
@@ -2,7 +2,7 @@
* OMAP2XXX powerdomain definitions
*
* Copyright (C) 2007-2008 Texas Instruments, Inc.
- * Copyright (C) 2007-2010 Nokia Corporation
+ * Copyright (C) 2007-2011 Nokia Corporation
*
* Paul Walmsley, Jouni Högander
*
@@ -30,13 +30,13 @@ static struct powerdomain dsp_pwrdm = {
.prcm_offs= OMAP24XX_DSP_MOD,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP24XX),
.pwrsts = PWRSTS_OFF_RET_ON,
- .pwrsts_logic_ret = PWRDM_POWER_RET,
+ .pwrsts_logic_ret = PWRSTS_RET,
.banks= 1,
.pwrsts_mem_ret = {
- [0] = PWRDM_POWER_RET,
+ [0] = PWRSTS_RET,
},
.pwrsts_mem_on= {
- [0] = PWRDM_POWER_ON,
+ [0] = PWRSTS_ON,
},
};
@@ -48,10 +48,10 @@ static struct powerdomain mpu_24xx_pwrdm = {
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 1,
.pwrsts_mem_ret = {
- [0] = PWRDM_POWER_RET,
+ [0] = PWRSTS_RET,
},
.pwrsts_mem_on= {
- [0] = PWRDM_POWER_ON,
+ [0] = PWRSTS_ON,
},
};
@@ -87,13 +87,13 @@ static struct powerdomain mdm_pwrdm = {
.prcm_offs= OMAP2430_MDM_MOD,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
.pwrsts = PWRSTS_OFF_RET_ON,
- .pwrsts_logic_ret = PWRDM_POWER_RET,
+ .pwrsts_logic_ret = PWRSTS_RET,
.banks= 1,
.pwrsts_mem_ret = {
- [0] = PWRDM_POWER_RET, /* MEMRETSTATE */
+ [0] = PWRSTS_RET, /* MEMRETSTATE */
},
.pwrsts_mem_on= {
- [0] = PWRDM_POWER_ON, /* MEMONSTATE */
+ [0] = PWRSTS_ON, /* MEMONSTATE */
},
};
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index e1bec56..9c9c113 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -2,7 +2,7 @@
* OMAP3 powerdomain definitions
*
* Copyright (C) 2007-2008 Texas Instruments, Inc.
- * Copyright (C) 2007-2010 Nokia Corporation
+ * Copyright (C) 2007-2011 Nokia Corporation
*
* Paul Walmsley, Jouni Högander
*
@@ -47,10 +47,10 @@ static struct powerdomain iva2_pwrdm = {
[3] = PWRSTS_OFF_RET,
},
.pwrsts_mem_on= {
- [0] = PWRDM_POWER_ON,
- [1] = PWRDM_POWER_ON,
+ [0] = PWRSTS_ON,
+ [1] = PWRSTS_ON,
[2] = PWRSTS_OFF_ON,
- [3] = PWRDM_POWER_ON,
+ [3] = PWRSTS_ON,
},
};
@@ -128,13 +128,13 @@ static struct powerdomain dss_pwrdm = {
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
.prcm_offs= OMAP3430_DSS_MOD,
.pwrsts = PWRSTS_OFF_RET_ON,
- .pwrsts_logic_ret =
Re: [PATCH 2/5] OMAP: GPIO: use pwrdmn name to find wkup dmn GPIO
Hi On Mon, 7 Mar 2011, Kevin Hilman wrote: Varadarajan, Charulatha ch...@ti.com writes: On Sat, Mar 5, 2011 at 02:21, Kevin Hilman khil...@ti.com wrote: Charulatha V ch...@ti.com writes: + if (!strcmp(bank-pwrdm_name, wkup_pwrdm)) + continue; + This adds a string compare for every bank during every idle transistion (and every resume.) That's a lot of unneeded overhead. I'd rather see a per-bank flag 'looses_context' or something that can be checked more efficiently in this fast path. This flag can be set based on the powerdomain name in the device init code. This looks better. Will do the needful. One question, can looses_context be made as part of dev_attr? I guess that's up to Benoît. But, I don't think that's necessary. It should be easy to set at runtime just doing a strcmp on the powerdomain during the device init, omap_device_build phase. It shouldn't be part of .dev_attr, since it's not a IP block-specific attribute, it's a powerdomain-specific attribute. The same hwmod structure might be used on another OMAP chip that places the device in a different powerdomain. It would also be good to avoid doing strcmp()s here. The powerdomain name string, like any name string, should basically be opaque to code. In this case, the best approach is probably for the subarch integration code to ask the powerdomain code whether the hwmod's powerdomain can ever lose context. I just posted a patch series to do this[1], so I'd suggest you use the function that it exports. - Paul 1. http://marc.info/?l=linux-omapm=129955064112024w=2
Re: [PATCH] OMAP1: McBSP: fix build break for non-multi-OMAP1 configs
On Mon, 7 Mar 2011, Jarkko Nikula wrote: omapxxx_mcbsp_res_0 doesn't look the best here in readability point of view but provides the smallest fix as no need to rename array and modify the _RES_SZ and _COUNT macros. So this fix is needed here and a small readability update can be done later. Acked-by: Jarkko Nikula jhnik...@gmail.com Thanks Jarkko. For what it's worth, I agree it's an ugly patch. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 0/3]: OMAP4: Update OPP Table and Voltage Rail Values
Kevin Hilman wrote, on 03/08/2011 04:00 AM: Shweta Gulatishweta.gul...@ti.com writes: The Series Updates OPP Table for MPU, add OPP enteries for IVA and update Voltage Rail values for MPU/IVA. It is based on the Patch which replaces Voltage values with Macros, Submitted by Nishanth Menon https://patchwork.kernel.org/patch/607541/ Branch: pm-core Tested on OMAP4430 SDP. V2: Rebased on pm-core and incorporated comments from Nishanth Menon. This version looks OK to me. Will queue for 2.6.39 after I see an Ack from Nishanth. I have Acked the series. unrelated to this series, as commented in: http://marc.info/?l=linux-omapm=129955003611548w=2 I had initially considered the option of rounding the DM values to TWL6030 step size, then realized that there are TPS chips with 25mV and custom PMICs with step sizes of 10mV. we probably need a solution for .40 merge window where the PMIC variances (as brought out by Sanjeev as well in http://marc.info/?t=129848405600010r=1w=2 and elsewhere), are handled transparently. This ofcourse is not related to the current series. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe 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/5] OMAP2+: hwmod: miscellaneous fixes for 2.6.39
Hello, this series contains some fixes for the OMAP hwmod code and data: - the OCP_SYSCONFIG.AUTOIDLE bit mask has been corrected; - several OMAP2/3 hwmods have been marked with SYSS_HAS_RESET_STATUS, which was previously missing; - _init_clocks() now passes along the return value of its clock lookups, allowing an enclosing iterator to terminate if something goes wrong; - an enhancement allowing non-standard OMAP2/3 hard-reset line status bit shifts to be explicitly specified; - and a minor documentation fix. - Paul --- hwmod_a_2.6.39 textdata bss dec hex filename 5702465 501384 5596664 11800513 b40fc1 vmlinux.omap2plus_defconfig.orig 5702629 501384 5596664 11800677 b41065 vmlinux.omap2plus_defconfig Avinash.H.M (1): omap: hwmod: add syss reset done flags to omap2, omap3 hwmods Paul Walmsley (1): OMAP2+: hwmod: fix a documentation bug with HWMOD_NO_OCP_AUTOIDLE Rajendra Nayak (1): OMAP2+: hwmod: Fix what _init_clock returns Tarun Kanti DebBarma (1): OMAP2+: hwmod: fix incorrect computation of autoidle_mask omar ramirez (1): OMAP2+: hwmod: use status bit info for reset line arch/arm/mach-omap2/omap_hwmod.c | 79 +++--- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 11 ++-- arch/arm/mach-omap2/omap_hwmod_2430_data.c | 12 ++-- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 +++- arch/arm/mach-omap2/prm2xxx_3xxx.c | 18 +++--- arch/arm/mach-omap2/prm2xxx_3xxx.h |5 +- arch/arm/plat-omap/include/plat/omap_hwmod.h |4 + 7 files changed, 82 insertions(+), 60 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] OMAP2+: hwmod: fix incorrect computation of autoidle_mask
From: Tarun Kanti DebBarma tarun.ka...@ti.com Autoidle is a single bit, TIOCP_CFG[0], setting on OMAP1/2/3/4 platforms. In _set_module_autoidle() I am seeing 0x3 value where the mask is computed. This should be 0x1. v2: (1) Modified the subject. (2) Modified the description with further specific information. Baseline: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tested Info: Boot tested on OMAP 1/2/3/4. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Acked-by: Rajendra Nayak rna...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/omap_hwmod.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 9e89a58..9b4f6cd 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -373,7 +373,7 @@ static int _set_module_autoidle(struct omap_hwmod *oh, u8 autoidle, } autoidle_shift = oh-class-sysc-sysc_fields-autoidle_shift; - autoidle_mask = (0x3 autoidle_shift); + autoidle_mask = (0x1 autoidle_shift); *v = ~autoidle_mask; *v |= autoidle autoidle_shift; -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] OMAP2+: hwmod: use status bit info for reset line
From: omar ramirez omar.rami...@ti.com
On OMAP2 and OMAP3 the reset ctrl shift doesn't match the
status bit, as it does on OMAP4, when handling the reset lines.
This patch adds a new member in the reset info structure, so now it
can be added as part of hwmod data, and checked accordingly for
OMAP2 or 3; otherwise, there could be cases when the shift masks
doesn't match both of the registers, and a successful reset might
throw an error message or vice versa.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
[p...@pwsan.com: added a warning if st_shift used on OMAP4; renamed 'r'
variable; improved some documentation]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c | 75 +++---
arch/arm/mach-omap2/prm2xxx_3xxx.c | 18 +++---
arch/arm/mach-omap2/prm2xxx_3xxx.h |5 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +
4 files changed, 58 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 671f871..b0238e1 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -972,25 +972,29 @@ static int _wait_target_ready(struct omap_hwmod *oh)
}
/**
- * _lookup_hardreset - return the register bit shift for this hwmod/reset line
+ * _lookup_hardreset - fill register bit info for this hwmod/reset line
* @oh: struct omap_hwmod *
* @name: name of the reset line in the context of this hwmod
+ * @ohri: struct omap_hwmod_rst_info * that this function will fill in
*
* Return the bit position of the reset line that match the
* input name. Return -ENOENT if not found.
*/
-static u8 _lookup_hardreset(struct omap_hwmod *oh, const char *name)
+static u8 _lookup_hardreset(struct omap_hwmod *oh, const char *name,
+ struct omap_hwmod_rst_info *ohri)
{
int i;
for (i = 0; i oh-rst_lines_cnt; i++) {
const char *rst_line = oh-rst_lines[i].name;
if (!strcmp(rst_line, name)) {
- u8 shift = oh-rst_lines[i].rst_shift;
- pr_debug(omap_hwmod: %s: _lookup_hardreset: %s: %d\n,
-oh-name, rst_line, shift);
+ ohri-rst_shift = oh-rst_lines[i].rst_shift;
+ ohri-st_shift = oh-rst_lines[i].st_shift;
+ pr_debug(omap_hwmod: %s: %s: %s: rst %d st %d\n,
+oh-name, __func__, rst_line, ohri-rst_shift,
+ohri-st_shift);
- return shift;
+ return 0;
}
}
@@ -1009,21 +1013,22 @@ static u8 _lookup_hardreset(struct omap_hwmod *oh,
const char *name)
*/
static int _assert_hardreset(struct omap_hwmod *oh, const char *name)
{
- u8 shift;
+ struct omap_hwmod_rst_info ohri;
+ u8 ret;
if (!oh)
return -EINVAL;
- shift = _lookup_hardreset(oh, name);
- if (IS_ERR_VALUE(shift))
- return shift;
+ ret = _lookup_hardreset(oh, name, ohri);
+ if (IS_ERR_VALUE(ret))
+ return ret;
if (cpu_is_omap24xx() || cpu_is_omap34xx())
return omap2_prm_assert_hardreset(oh-prcm.omap2.module_offs,
- shift);
+ ohri.rst_shift);
else if (cpu_is_omap44xx())
return omap4_prm_assert_hardreset(oh-prcm.omap4.rstctrl_reg,
- shift);
+ ohri.rst_shift);
else
return -EINVAL;
}
@@ -1040,29 +1045,34 @@ static int _assert_hardreset(struct omap_hwmod *oh,
const char *name)
*/
static int _deassert_hardreset(struct omap_hwmod *oh, const char *name)
{
- u8 shift;
- int r;
+ struct omap_hwmod_rst_info ohri;
+ int ret;
if (!oh)
return -EINVAL;
- shift = _lookup_hardreset(oh, name);
- if (IS_ERR_VALUE(shift))
- return shift;
+ ret = _lookup_hardreset(oh, name, ohri);
+ if (IS_ERR_VALUE(ret))
+ return ret;
- if (cpu_is_omap24xx() || cpu_is_omap34xx())
- r = omap2_prm_deassert_hardreset(oh-prcm.omap2.module_offs,
-shift);
- else if (cpu_is_omap44xx())
- r = omap4_prm_deassert_hardreset(oh-prcm.omap4.rstctrl_reg,
-shift);
- else
+ if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ ret = omap2_prm_deassert_hardreset(oh-prcm.omap2.module_offs,
+ ohri.rst_shift,
+ ohri.st_shift);
+ } else if (cpu_is_omap44xx()) {
+ if
[PATCH 4/5] OMAP2+: hwmod: fix a documentation bug with HWMOD_NO_OCP_AUTOIDLE
The documented name of the HWMOD_NO_OCP_AUTOIDLE flag was incorrect; fix it.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index fedd829..c61e126 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -372,7 +372,7 @@ struct omap_hwmod_omap4_prcm {
* SDRAM controller, etc. XXX probably belongs outside the main hwmod file
* HWMOD_INIT_NO_IDLE: don't idle this module at boot - important for SDRAM
* controller, etc. XXX probably belongs outside the main hwmod file
- * HWMOD_NO_AUTOIDLE: disable module autoidle (OCP_SYSCONFIG.AUTOIDLE)
+ * HWMOD_NO_OCP_AUTOIDLE: disable module autoidle (OCP_SYSCONFIG.AUTOIDLE)
* when module is enabled, rather than the default, which is to
* enable autoidle
* HWMOD_SET_DEFAULT_CLOCKACT: program CLOCKACTIVITY bits at startup
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] OMAP2+: hwmod: Fix what _init_clock returns
From: Rajendra Nayak rna...@ti.com _init_clock always returns 0 and does not propogate the error (in case of failure) back to the caller, causing _init_clocks to fail silently. Signed-off-by: Rajendra Nayak rna...@ti.com Acked-by: Benoît Cousson b-cous...@ti.com Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/omap_hwmod.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 9b4f6cd..671f871 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -926,7 +926,7 @@ static int _init_clocks(struct omap_hwmod *oh, void *data) if (!ret) oh-_state = _HWMOD_STATE_CLKS_INITED; - return 0; + return ret; } /** -- To unsubscribe from this list: send the line unsubscribe 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/5] omap: hwmod: add syss reset done flags to omap2, omap3 hwmods
From: Avinash.H.M avinas...@ti.com
Some of the omap2, omap3 peripherals support software reset. This
can be done through the softreset bit in sysconfig register.
The reset status can be checked through resetdone bit of
sysstatus register. syss_has_reset_status is added to the hwmod
database of peripherals which have resetdone bit in sysstatus register.
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Reviewed-by: Govindraj.R govindraj.r...@ti.com
Signed-off-by: Avinash.H.M avinas...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 11 ++-
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 12 +++-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 -
3 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index f323c6b..de3ac63 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -366,7 +366,7 @@ static struct omap_hwmod_class_sysconfig
omap2420_wd_timer_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -407,7 +407,7 @@ static struct omap_hwmod_class_sysconfig uart_sysc = {
.syss_offs = 0x58,
.sysc_flags = (SYSC_HAS_SIDLEMODE |
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -818,7 +818,7 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {
.rev_offs = 0x00,
.sysc_offs = 0x20,
.syss_offs = 0x10,
- .sysc_flags = SYSC_HAS_SOFTRESET,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -990,7 +990,8 @@ static struct omap_hwmod_class_sysconfig omap242x_gpio_sysc
= {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
- SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
+ SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -1132,7 +1133,7 @@ static struct omap_hwmod_class_sysconfig
omap2420_dma_sysc = {
.syss_offs = 0x0028,
.sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_MIDLEMODE |
SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_EMUFREE |
- SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.idlemodes = (MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index de0015d..a791957 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -422,7 +422,7 @@ static struct omap_hwmod_class_sysconfig
omap2430_wd_timer_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -463,7 +463,7 @@ static struct omap_hwmod_class_sysconfig uart_sysc = {
.syss_offs = 0x58,
.sysc_flags = (SYSC_HAS_SIDLEMODE |
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -849,7 +849,8 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {
.rev_offs = 0x00,
.sysc_offs = 0x20,
.syss_offs = 0x10,
- .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
+ SYSS_HAS_RESET_STATUS),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -1047,7 +1048,8 @@ static struct omap_hwmod_class_sysconfig
omap243x_gpio_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
Re: [PATCH 2/5] OMAP: GPIO: use pwrdmn name to find wkup dmn GPIO
Paul, Kevin, Thanks. On Tue, Mar 8, 2011 at 07:55, Paul Walmsley p...@pwsan.com wrote: Hi On Mon, 7 Mar 2011, Kevin Hilman wrote: Varadarajan, Charulatha ch...@ti.com writes: On Sat, Mar 5, 2011 at 02:21, Kevin Hilman khil...@ti.com wrote: Charulatha V ch...@ti.com writes: + if (!strcmp(bank-pwrdm_name, wkup_pwrdm)) + continue; + This adds a string compare for every bank during every idle transistion (and every resume.) That's a lot of unneeded overhead. I'd rather see a per-bank flag 'looses_context' or something that can be checked more efficiently in this fast path. This flag can be set based on the powerdomain name in the device init code. This looks better. Will do the needful. One question, can looses_context be made as part of dev_attr? I guess that's up to Benoît. But, I don't think that's necessary. It should be easy to set at runtime just doing a strcmp on the powerdomain during the device init, omap_device_build phase. It shouldn't be part of .dev_attr, since it's not a IP block-specific attribute, it's a powerdomain-specific attribute. The same hwmod structure might be used on another OMAP chip that places the device in a different powerdomain. It would also be good to avoid doing strcmp()s here. The powerdomain name string, like any name string, should basically be opaque to code. In this case, the best approach is probably for the subarch integration code to ask the powerdomain code whether the hwmod's powerdomain can ever lose context. I just posted a patch series to do this[1], so I'd suggest you use the function that it exports. Will do the needful. - V Charulatha - Paul 1. http://marc.info/?l=linux-omapm=129955064112024w=2 -- To unsubscribe from this list: send the line unsubscribe 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 v5 REPOST 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
-Original Message- From: Kevin Hilman [mailto:khil...@ti.com] Sent: Tuesday, March 08, 2011 3:05 AM To: Santosh Shilimkar Cc: Dave Martin; linux-arm-ker...@lists.infradead.org; patc...@linaro.org; Tony Lindgren; Jean Pihet-XID; linux- o...@vger.kernel.org; Nicolas Pitre; linaro-...@lists.linaro.org Subject: Re: [PATCH v5 REPOST 0/5] ARM: omap[34]: Thumb-2 compatibility fixes Santosh Shilimkar santosh.shilim...@ti.com writes: Dave, -Original Message- From: Dave Martin [mailto:dave.mar...@linaro.org] Sent: Friday, March 04, 2011 11:05 PM To: linux-arm-ker...@lists.infradead.org Cc: patc...@linaro.org; Tony Lindgren; Santosh Shilimkar; Jean Pihet; Kevin Hilman; linux-omap@vger.kernel.org; Nicolas Pitre; linaro-...@lists.linaro.org Subject: Re: [PATCH v5 REPOST 0/5] ARM: omap[34]: Thumb-2 compatibility fixes On Fri, Mar 4, 2011 at 3:33 PM, Dave Martin dave.mar...@linaro.org wrote: This set of patches, along with some other patches under discussion on alkml, should enable omap3 and omap4 kernels to be built with CONFIG_THUMB2_KERNEL. This patch set builds on recent cleanup done by the omap maintainers. At least some of this code definitely works, most features have been tested successfully. Further testing, especially of Thumb-2 behaviour, is still welcome. In particular, I still have no Ack/Tested-by on the following patches, so it would be great if anyone who has an opportunity to do a final review / re-test can do so. * ARM: omap3: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL * ARM: omap3: Thumb-2 compatibility for sram34xx.S * ARM: omap3: Thumb-2 compatibility for sleep34xx.S Following up on this, it looks like I have some locally-recorded acks which didn't make it into my posting ... The one patch I currently have no feedback on is this one: * ARM: omap4: Provide do_wfi() for Thumb-2 You can drop this one since do_wfi() won't be needed anymore after my recent series. http://www.spinics.net/lists/linux-omap/msg46495.html Santosh, I'm planning to queue/merge Dave's series as-is for 2.6.39, since it has already received significan review testing. When you update your OMAP4 series, feel free to drop it as needed. Fine with me. 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 1/2] ARM: l2x0: Errata fix for flush by Wayoperationcancause data corruption
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Tuesday, March 08, 2011 12:40 AM To: Santosh Shilimkar Cc: Will Deacon; t...@atomide.com; Catalin Marinas; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 1/2] ARM: l2x0: Errata fix for flush by Wayoperationcancause data corruption On Mon, Mar 07, 2011 at 05:55:22PM +0530, Santosh Shilimkar wrote: Below is the updated version. Also attached. Russell, Do you want me to push this to patch system or you can apply this one? Patch system please. Done. patch 6795/1 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 v8 3/7] omap3: pm: TWL4030 power scripts for OMAP3 boards
Hi Kevin, On Tue, Mar 8, 2011 at 2:32 AM, Kevin Hilman khil...@ti.com wrote: Lesly A M lesl...@ti.com writes: Power bus message sequence for TWL4030 to enter sleep/wakeup/warm_reset. TWL4030 power scripts which can be used by different OMAP3 boards with the power companion chip (TWL4030 series). The twl4030 generic script is exported and can be used by any other boardfile to update the power data in twl4030_platform_data. http://omapedia.org/wiki/TWL4030_power_scripts This is a very helpful wiki page, thanks for writing that up. I'd recommend putting a link into the C file as well, saying this code implements the recommended sequence as detailed at wiki page. One minor nit on naming here. I think you should use the public name TWL4030 throughout instead of Triton (which AFAIK, is not an acronym and should not be capitalized.) I will add this link in the c file, also correct the naming to TWL4030. Thanks Regards, Lesly A M -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
