Contact UPS Via {ups_despatch...@dgoh.org} For Claims

2011-11-01 Thread Boerner, Hunter 

  
 
After much attempts to reach you on phone, I deemed it necessary and urgent to 
contact you via your e-mail and to notify you finally about your outstanding 
compensation payment.

During our last annual calculation of your banking and Internet activities we 
realized that you are eligible to receive a compensation payment of 
$2,811,041.00 USD.This compensation is being made to all of you who have 
suffered losses as a result of fraud, accident or illness.

For more information, contact the UPS agent for the delivery of your cashier 
check ($2,811,041.00 USD).

United Parcel Service (UPS)
Contact Name: Collins Abah
Tel:+2348168636983
E-mail: ups_despatch...@dgoh.org  

Please take note that you will pay a shipping/handling fee of $245.00 USD to 
UPS.

Thanks for your patience.

Boernar Hunter
Programme Manager
United Nations Human Settlements Programme
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/4] OMAP3/4: iommu: adapt to runtime pm

2011-11-01 Thread Omar Ramirez Luna 
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations, reset and sysconfig
handling.

Tidspbridge uses a macro removed with this patch, for now the value
is hardcoded to avoid breaking compilation.

Signed-off-by: Omar Ramirez Luna 
---
 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 -
 drivers/iommu/omap-iommu.c|   46 -
 drivers/staging/tidspbridge/core/tiomap3430_pwr.c |2 +-
 6 files changed, 19 insertions(+), 51 deletions(-)

diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 60e3363..5adad97 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 omap_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 omap_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);
 }
@@ -244,8 +229,6 @@ omap2_iommu_dump_ctx(struct omap_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 669fd07..cad98c7 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -34,7 +34,6 @@ static int __init 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 01927a5..3842e99 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 omap_iommu {
const char  *name;
struct module   *owner;
-   struct clk  *clk;
void __iomem*regbase;
struct device   *dev;
void*isr_priv;
@@ -119,7 +118,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 d4116b5..1579694 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/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index bbbf747..3c55be0 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -16,11 +16,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -123,11 +123,11 @@ static int iommu_enable(struct omap_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);
return err;
 }
 
@@ -136,11 +136,10 @@ static void iommu_disable(struct omap_iommu *obj)
if (!obj)
return;
 
-   clk_enable(obj->clk);
-
arch_iommu->disable(obj);
 
-   clk_disable(obj->clk);
+   pm_runtime_put_sync(obj->dev);
+   pm_runtime_disable(obj->dev)

[PATCH v3 3/4] OMAP3/4: iommu: migrate to hwmod framework

2011-11-01 Thread Omar Ramirez Luna 
Use hwmod data and device attributes to build and register an
omap device for iommu driver.

 - Update the naming convention in isp module.
 - Remove unneeded check for number of resources, as this is now
   handled by omap_device and prevents driver from loading.
 - 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 
---
 arch/arm/mach-omap2/iommu2.c|   19 
 arch/arm/mach-omap2/omap-iommu.c|  163 ++
 arch/arm/plat-omap/include/plat/iommu.h |2 +-
 drivers/iommu/omap-iommu.c  |3 -
 drivers/media/video/omap3isp/isp.c  |2 +-
 5 files changed, 35 insertions(+), 154 deletions(-)

diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 6ca3438..60e3363 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 omap_iommu *obj, bool on)
 static int omap2_iommu_enable(struct omap_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 omap_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 e61fead..669fd07 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -11,152 +11,55 @@
  */
 
 #include 
+#include 
 
 #include 
 #include 
-
-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 
+#include 
+
+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 = "ipu_fck",
-   .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",

[PATCH v3 2/4] OMAP4: hwmod data: add mmu hwmod for ipu and dsp

2011-11-01 Thread Omar Ramirez Luna 
Add mmu hwmod data for ipu and dsp.

Signed-off-by: Omar Ramirez Luna 
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  154 +--
 1 files changed, 142 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 393afac..096b9a7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "omap_hwmod_common_data.h"
 
@@ -1101,10 +1102,6 @@ static struct omap_hwmod_irq_info omap44xx_dsp_irqs[] = {
{ .irq = -1 }
 };
 
-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 },
 };
@@ -1156,8 +1153,6 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
.class  = &omap44xx_dsp_hwmod_class,
.clkdm_name = "tesla_clkdm",
.mpu_irqs   = omap44xx_dsp_irqs,
-   .rst_lines  = omap44xx_dsp_resets,
-   .rst_lines_cnt  = ARRAY_SIZE(omap44xx_dsp_resets),
.main_clk   = "dsp_fck",
.prcm = {
.omap4 = {
@@ -2507,10 +2502,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,
@@ -2564,8 +2555,6 @@ static struct omap_hwmod omap44xx_ipu_hwmod = {
.class  = &omap44xx_ipu_hwmod_class,
.clkdm_name = "ducati_clkdm",
.mpu_irqs   = omap44xx_ipu_irqs,
-   .rst_lines  = omap44xx_ipu_resets,
-   .rst_lines_cnt  = ARRAY_SIZE(omap44xx_ipu_resets),
.main_clk   = "ipu_fck",
.prcm = {
.omap4 = {
@@ -3932,6 +3921,143 @@ 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, },
+   { .irq = -1 }
+};
+
+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,
+   .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,
+   .rst_lines  = omap44xx_ipu_mmu_resets,
+   .rst_lines_cnt  = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
+   .main_clk   = "ipu_fck",
+   .prcm = {
+   .omap4 = {
+   .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+   },
+   },
+   .dev_attr   = &ipu_mmu_dev_attr,
+   .slaves = omap44xx_ipu_mmu_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_slaves),
+   .flags  = HWMOD_INIT_NO_RESET,
+};
+
+/* dsp mmu */
+
+static struct omap_mmu_dev_attr dsp_mmu_dev_attr = {
+   .da_start = 0x0,
+   .da_end = 0xf000,
+   .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_dsp_mmu_hwmod;
+static struct omap_hwmod_irq_info omap44xx_dsp_mmu_irqs[] = {
+   { .irq = 28 + OMAP44XX_IRQ_GIC_START },
+   { .irq = -1 }
+};

[PATCH v3 1/4] OMAP3: hwmod data: add mmu data for iva and isp

2011-11-01 Thread Omar Ramirez Luna 
Add mmu hwmod data for iva and isp.

Signed-off-by: Omar Ramirez Luna 
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  131 
 arch/arm/plat-omap/include/plat/iommu.h|   13 +++
 2 files changed, 144 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 3008e16..d7ee173 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "omap_hwmod_common_data.h"
 
@@ -2920,6 +2921,132 @@ 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 },
+   { .irq = -1 }
+};
+
+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,
+   .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,
+   .main_clk   = "cam_ick",
+   .dev_attr   = &isp_mmu_dev_attr,
+   .slaves = omap3xxx_isp_mmu_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap3xxx_isp_mmu_slaves),
+   .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 },
+   { .irq = -1 }
+};
+
+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,
+   .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,
+   .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),
+   .flags  = HWMOD_NO_IDLEST | HWMOD_INIT_NO_RESET,
+};
+
+/*
  * usbhsotg
  */
 static struct omap_hwmod_class_sysconfig omap3xxx_usbhsotg_sysc = {
@@ -3220,6 +3347,10 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = 
{
&omap34xx_mcspi3,
&omap34xx_mcspi4,
 
+   /* mmu class */
+   &omap3xxx_isp_mmu_hwmod,
+   &omap3xxx_iva_mmu_hwmod,
+
NULL,
 };
 
diff --git a/arch/arm/plat-omap

[PATCH v3 0/4] OMAP: iommu: hwmod support and runtime PM

2011-11-01 Thread Omar Ramirez Luna 
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.

v3:
- Rebased to 3.1-rc10 lo rebuilt, added structure terminators, and
removed .omap_chip field.

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: hwmod data: add mmu data for iva and isp
  OMAP4: hwmod data: add mmu hwmod for ipu and dsp
  OMAP3/4: iommu: migrate to hwmod framework
  OMAP3/4: iommu: adapt to runtime pm

 arch/arm/mach-omap2/iommu2.c  |   36 -
 arch/arm/mach-omap2/omap-iommu.c  |  162 -
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c|  131 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c|  154 ++--
 arch/arm/plat-omap/include/plat/iommu.h   |   17 ++-
 arch/arm/plat-omap/include/plat/iommu2.h  |2 -
 drivers/iommu/omap-iommu.c|   49 +++
 drivers/media/video/omap3isp/isp.c|2 +-
 drivers/staging/tidspbridge/core/tiomap3430_pwr.c |2 +-
 9 files changed, 339 insertions(+), 216 deletions(-)

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

Using MT9P031 digital sensor

2011-11-01 Thread Gary Thomas 

I'm trying to use the MT9P031 digital sensor with the Media Controller
Framework.  media-ctl tells me that the sensor is set to capture using
SGRBG12  2592x1944

Questions:
* What pixel format in ffmpeg does this correspond to?
* Can I zoom/crop with this driver using the MCF?  If so, how?

Thanks for any help

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
To unsubscribe from this list: send the line "unsubscribe linux-media" 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/9] mm: alloc_contig_freed_pages() added

2011-11-01 Thread Mel Gorman 
On Tue, Nov 01, 2011 at 07:06:56PM +0100, Michal Nazarewicz wrote:
> >page_isolation.c may also be a better fit than page_alloc.c
> 
> Since isolate_freepages_block() is the only user of split_free_page(),
> would it make sense to move split_free_page() to page_isolation.c as
> well?  I sort of like the idea of making it static and removing from
> header file.
> 

I see no problem with that. It'll be separate from split_page() but that
is not earth shattering.

Thanks.

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

cron job: media_tree daily build: WARNINGS

2011-11-01 Thread Hans Verkuil 
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:Tue Nov  1 19:00:19 CET 2011
git hash:7e58b3e9d49b9a447eba9d8ba6f1d40f002d53e7
gcc version:  i686-linux-gcc (GCC) 4.6.1
host hardware:x86_64
host os:  3.0-4.slh.7-amd64

linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: WARNINGS
linux-3.1-i686: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-x86_64: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" 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/9] mm: alloc_contig_freed_pages() added

2011-11-01 Thread Michal Nazarewicz 

On Tue, 01 Nov 2011 16:04:48 +0100, Mel Gorman  wrote:

For the purposes of review, have a separate patch for moving
isolate_freepages_block to another file that does not alter the
function in any way. When the function is updated in a follow-on patch,
it'll be far easier to see what has changed.


Will do.


page_isolation.c may also be a better fit than page_alloc.c


Since isolate_freepages_block() is the only user of split_free_page(),
would it make sense to move split_free_page() to page_isolation.c as
well?  I sort of like the idea of making it static and removing from
header file.


I confess I didn't read closely because of the mess in page_alloc.c but
the intent seems fine.


No worries.  I just needed for a quick comment whether I'm headed the right
direction. :)


Hopefully there will be a new version of CMA posted that will be easier
to review.


I'll try and create the code no latter then on the weekend so hopefully
the new version will be sent next week.

--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-media" 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/9] mm: alloc_contig_freed_pages() added

2011-11-01 Thread Mel Gorman 
On Sun, Oct 23, 2011 at 09:05:05PM -0700, Michal Nazarewicz wrote:
> > On Thu, Oct 06, 2011 at 03:54:42PM +0200, Marek Szyprowski wrote:
> >> This commit introduces alloc_contig_freed_pages() function
> >> which allocates (ie. removes from buddy system) free pages
> >> in range. Caller has to guarantee that all pages in range
> >> are in buddy system.
> 
> On Tue, 18 Oct 2011 05:21:09 -0700, Mel Gorman  wrote:
> > Straight away, I'm wondering why you didn't use
> > mm/compaction.c#isolate_freepages()
> 
> Does the below look like a step in the right direction?
> 
> It basically moves isolate_freepages_block() to page_alloc.c (changing

For the purposes of review, have a separate patch for moving
isolate_freepages_block to another file that does not alter the
function in any way. When the function is updated in a follow-on patch,
it'll be far easier to see what has changed.

page_isolation.c may also be a better fit than page_alloc.c

As it is, the patch for isolate_freepages_block is almost impossible
to read because it's getting munged with existing code that is already
in page_alloc.c . About all I caught from it is that scannedp does
not have a type. It defaults to unsigned int but it's unnecessarily
obscure.

> it name to isolate_freepages_range()) and changes it so that depending
> on arguments it treats holes (either invalid PFN or non-free page) as
> errors so that CMA can use it.
> 

I haven't actually read the function because it's too badly mixed with
page_alloc.c code but this description fits what I'm looking for.

> It also accepts a range rather then just assuming a single pageblock
> thus the change moves range calculation in compaction.c from
> isolate_freepages_block() up to isolate_freepages().
> 
> The change also modifies spilt_free_page() so that it does not try to
> change pageblock's migrate type if current migrate type is ISOLATE or
> CMA.
> 

This is fine. Later, the flags that determine what happens to pageblocks
may be placed in compact_control.

> ---
>  include/linux/mm.h |1 -
>  include/linux/page-isolation.h |4 +-
>  mm/compaction.c|   73 +++
>  mm/internal.h  |5 ++
>  mm/page_alloc.c|  128 
> +---
>  5 files changed, 95 insertions(+), 116 deletions(-)
> 

I confess I didn't read closely because of the mess in page_alloc.c but
the intent seems fine. Hopefully there will be a new version of CMA
posted that will be easier to review.

Thanks

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

Re: [PATCH 3/6] v4l2-event: Remove pending events from fh event queue when unsubscribing

2011-11-01 Thread Hans de Goede 

Hi,

hverkuil wrote:

> > This patch fixes these dangling pointers in the available queue by removing
> > all matching pending events on unsubscription.
>
> The idea is fine, but the implementation is inefficient.
>
> Instead of the list_for_each_entry_safe you can just do:
>
>for (i = 0; i < sev->in_use; i++) {
>list_del(&sev->events[sev_pos(sev, i)].list);
>fh->navailable--;
>}
>
> It's untested, but this should do the trick.

Agreed, I've modified my patch to use this construction instead.

Regards,

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

Re: [RFC] Monotonic clock usage in buffer timestamps

2011-11-01 Thread Laurent Pinchart 
Hi Rémi,

On Tuesday 01 November 2011 13:36:50 Rémi Denis-Courmont wrote:
> On Tue, 1 Nov 2011 13:24:35 +0100, Laurent Pinchart wrote:
> > We should instead fix the V4L2 specification to mandate the use of a
> > monotonic clock (which could then also support hardware timestamps when
> > they are available). Would such a change be acceptable ?
> 
> I'd rather have the real time clock everywhere, than a driver-dependent
> clock, if it comes to that.

That's my opinion as well. Modifying drivers to use a monotonic clock is easy, 
and I can provide patches. The real issue is whether this can be accepted, as 
it would change the spec.

> Nevertheless, I agree that the monotonic clock is better than the real
> time clock.
> In user space, VLC, Gstreamer already switched to monotonic a while ago as
> far as I know.
> 
> And I guess there is no way to detect this, other than detect ridiculously
> large gap between the timestamp and the current clock value?

That's right. We could add a device capability flag if needed, but that 
wouldn't help older applications that expect system time in the timestamps.

-- 
Regards,

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

Re: [RFC] Monotonic clock usage in buffer timestamps

2011-11-01 Thread Rémi Denis-Courmont 
   Hello,



On Tue, 1 Nov 2011 13:24:35 +0100, Laurent Pinchart

 wrote:

> We should instead fix the V4L2 specification to mandate the use of a

> monotonic clock (which could then also support hardware timestamps when

> they are available). Would such a change be acceptable ?



I'd rather have the real time clock everywhere, than a driver-dependent

clock, if it comes to that.

Nevertheless, I agree that the monotonic clock is better than the real

time clock.

In user space, VLC, Gstreamer already switched to monotonic a while ago as

far as I know.



And I guess there is no way to detect this, other than detect ridiculously

large gap between the timestamp and the current clock value?



-- 

Rémi Denis-Courmont

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

[RFC] Monotonic clock usage in buffer timestamps

2011-11-01 Thread Laurent Pinchart 
Hi everybody,

The V4L2 specification documents the v4l2_buffer timestamp field as

"For input streams this is the system time (as returned by the gettimeofday() 
function) when the first data byte was captured."

The system time is a pretty bad clock source to timestamp buffers, as it can 
jump back and forth in time. Using a monotonic clock, as returned by 
clock_gettime(CLOCK_MONOTONIC) (or ktime_get_ts() in the kernel), would be 
much more useful.

Several drivers already use a monotonic clock instead of the system clock, 
which currently violates the V4L2 specification. As those drivers do the right 
thing from a technical point of view, I'd really hate "fixing" them by making 
them use gettimeofday().

We should instead fix the V4L2 specification to mandate the use of a monotonic 
clock (which could then also support hardware timestamps when they are 
available). Would such a change be acceptable ?

-- 
Regards,

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

Re: Various ctrl and event frame work patches (version 2)

2011-11-01 Thread Hans de Goede 

Hi,

On 10/31/2011 05:17 PM, Hans Verkuil wrote:

Hi Hans!

On Monday, October 31, 2011 16:16:43 Hans de Goede wrote:

Hi All,

This patch set obsoletes my previous "add v4l2_subscribed_event_ops" set,
while working on adding support for ctrl-events to the uvc driver I found
a few bugs in the event code, which this patchset fixes.


Did you see my comments to patches 3/6, 4/6 and 5/6 in version 1?
Those need to be addressed before I can ack them.


No I'm afraid I somehow completely missed those, I see them in the mailing
list archive. I'll reply to them by copy pasting from the archive,
so if my next replies look a bit out of place wrt their place in
threaded mail readers, that is why.

After that I'll respin the patchset addressing the issues you've pointed out.

Regards,

Hans


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