[PATCH-V1 00/10] VPFE Capture Bug Fixes and feature enhancement
From: Vaibhav Hiremath hvaib...@ti.com This is second version of patch series fixing few bugs and adds some feature enhancements - Changes: - Introduce t-media directory - Add YUYV support to tvp514x.c - Add UserPtr support to vpfe_capture - Call-back function for interrupt clear (required for AM3517) - VPFE Capture support for AM3517 - Suspend Resume support Changes from last version - - Merge board specific changes to patch introduce ti-media directory (comment from Hans) Vaibhav Hiremath (10): Makfile:Removed duplicate entry of davinci tvp514x: add YUYV format support Introducing ti-media directory AM3517 CCDC: Debug register read prints removed VPFE Capture: Add call back function for interrupt clear to vpfe_cfg DM644x CCDC: Add 10bit BT support Davinci VPFE Capture:Return 0 from suspend/resume DM644x CCDC : Add Suspend/Resume Support VPFE Capture: Add support for USERPTR mode of operation AM3517: Add VPFE Capture driver support arch/arm/mach-davinci/include/mach/dm355.h |2 +- arch/arm/mach-davinci/include/mach/dm644x.h |2 +- arch/arm/mach-omap2/board-am3517evm.c | 160 ++ drivers/media/video/Kconfig | 84 +- drivers/media/video/Makefile|4 +- drivers/media/video/davinci/Makefile| 17 - drivers/media/video/davinci/ccdc_hw_device.h| 110 -- drivers/media/video/davinci/dm355_ccdc.c| 1082 --- drivers/media/video/davinci/dm355_ccdc_regs.h | 310 drivers/media/video/davinci/dm644x_ccdc.c | 967 -- drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 -- drivers/media/video/davinci/vpfe_capture.c | 2054 - drivers/media/video/davinci/vpif.c | 296 --- drivers/media/video/davinci/vpif.h | 642 --- drivers/media/video/davinci/vpif_capture.c | 2168 --- drivers/media/video/davinci/vpif_capture.h | 165 -- drivers/media/video/davinci/vpif_display.c | 1654 - drivers/media/video/davinci/vpif_display.h | 175 -- drivers/media/video/davinci/vpss.c | 301 drivers/media/video/ti-media/Kconfig| 88 + drivers/media/video/ti-media/Makefile | 17 + drivers/media/video/ti-media/ccdc_hw_device.h | 110 ++ drivers/media/video/ti-media/dm355_ccdc.c | 1082 +++ drivers/media/video/ti-media/dm355_ccdc_regs.h | 310 drivers/media/video/ti-media/dm644x_ccdc.c | 1090 drivers/media/video/ti-media/dm644x_ccdc_regs.h | 153 ++ drivers/media/video/ti-media/vpfe_capture.c | 2130 ++ drivers/media/video/ti-media/vpif.c | 296 +++ drivers/media/video/ti-media/vpif.h | 642 +++ drivers/media/video/ti-media/vpif_capture.c | 2168 +++ drivers/media/video/ti-media/vpif_capture.h | 165 ++ drivers/media/video/ti-media/vpif_display.c | 1654 + drivers/media/video/ti-media/vpif_display.h | 175 ++ drivers/media/video/ti-media/vpss.c | 301 drivers/media/video/tvp514x.c |7 + include/media/davinci/ccdc_types.h | 43 - include/media/davinci/dm355_ccdc.h | 321 include/media/davinci/dm644x_ccdc.h | 184 -- include/media/davinci/vpfe_capture.h| 200 --- include/media/davinci/vpfe_types.h | 51 - include/media/davinci/vpss.h| 69 - include/media/ti-media/ccdc_types.h | 43 + include/media/ti-media/dm355_ccdc.h | 321 include/media/ti-media/dm644x_ccdc.h| 184 ++ include/media/ti-media/vpfe_capture.h | 202 +++ include/media/ti-media/vpfe_types.h | 51 + include/media/ti-media/vpss.h | 69 + 47 files changed, 11423 insertions(+), 11041 deletions(-) delete mode 100644 drivers/media/video/davinci/Makefile delete mode 100644 drivers/media/video/davinci/ccdc_hw_device.h delete mode 100644 drivers/media/video/davinci/dm355_ccdc.c delete mode 100644 drivers/media/video/davinci/dm355_ccdc_regs.h delete mode 100644 drivers/media/video/davinci/dm644x_ccdc.c delete mode 100644 drivers/media/video/davinci/dm644x_ccdc_regs.h delete mode 100644 drivers/media/video/davinci/vpfe_capture.c delete mode 100644 drivers/media/video/davinci/vpif.c delete mode 100644 drivers/media/video/davinci/vpif.h delete mode 100644 drivers/media/video/davinci/vpif_capture.c delete mode 100644 drivers/media/video/davinci/vpif_capture.h delete mode 100644 drivers/media/video/davinci/vpif_display.c delete mode 100644 drivers/media/video/davinci/vpif_display.h delete mode 100644 drivers/media/video/davinci/vpss.c create mode 100644 drivers/media/video/ti-media/Kconfig create mode 100644
[PATCH-V1 04/10] AM3517 CCDC: Debug register read prints removed
From: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- drivers/media/video/ti-media/dm644x_ccdc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/ti-media/dm644x_ccdc.c b/drivers/media/video/ti-media/dm644x_ccdc.c index 727f7e1..a011d40 100644 --- a/drivers/media/video/ti-media/dm644x_ccdc.c +++ b/drivers/media/video/ti-media/dm644x_ccdc.c @@ -434,7 +434,6 @@ void ccdc_config_ycbcr(void) ccdc_sbl_reset(); dev_dbg(ccdc_cfg.dev, \nEnd of ccdc_config_ycbcr...\n); - ccdc_readregs(); } static void ccdc_config_black_clamp(struct ccdc_black_clamp *bclamp) -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V1 01/10] Makfile:Removed duplicate entry of davinci
From: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- drivers/media/video/Makefile |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index b88b617..c51c386 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -160,8 +160,6 @@ obj-$(CONFIG_VIDEO_MX3) += mx3_camera.o obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o -obj-$(CONFIG_ARCH_DAVINCI) += davinci/ - obj-$(CONFIG_VIDEO_AU0828) += au0828/ obj-$(CONFIG_USB_VIDEO_CLASS) += uvc/ -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V1 05/10] VPFE Capture: Add call back function for interrupt clear to vpfe_cfg
From: Vaibhav Hiremath hvaib...@ti.com
For the devices like AM3517, it is expected that driver clears the
interrupt in ISR. Since this is device spcific, callback function
added to the platform_data.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/ti-media/vpfe_capture.c | 24
include/media/ti-media/vpfe_capture.h |2 ++
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/ti-media/vpfe_capture.c
b/drivers/media/video/ti-media/vpfe_capture.c
index 2f9d3bb..3ffd636 100644
--- a/drivers/media/video/ti-media/vpfe_capture.c
+++ b/drivers/media/video/ti-media/vpfe_capture.c
@@ -475,6 +475,11 @@ static int vpfe_initialize_device(struct vpfe_device
*vpfe_dev)
ret = ccdc_dev-hw_ops.open(vpfe_dev-pdev);
if (!ret)
vpfe_dev-initialized = 1;
+
+ /* Clear all VPFE/CCDC interrupts */
+ if (vpfe_dev-cfg-clr_intr)
+ vpfe_dev-cfg-clr_intr(-1);
+
unlock:
mutex_unlock(ccdc_lock);
return ret;
@@ -562,7 +567,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
/* if streaming not started, don't do anything */
if (!vpfe_dev-started)
- return IRQ_HANDLED;
+ goto clear_intr;
/* only for 6446 this will be applicable */
if (NULL != ccdc_dev-hw_ops.reset)
@@ -574,7 +579,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
frame format is progressive...\n);
if (vpfe_dev-cur_frm != vpfe_dev-next_frm)
vpfe_process_buffer_complete(vpfe_dev);
- return IRQ_HANDLED;
+ goto clear_intr;
}
/* interlaced or TB capture check which field we are in hardware */
@@ -604,7 +609,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
addr += vpfe_dev-field_off;
ccdc_dev-hw_ops.setfbaddr(addr);
}
- return IRQ_HANDLED;
+ goto clear_intr;
}
/*
* if one field is just being captured configure
@@ -624,6 +629,10 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
*/
vpfe_dev-field_id = fid;
}
+clear_intr:
+ if (vpfe_dev-cfg-clr_intr)
+ vpfe_dev-cfg-clr_intr(irq);
+
return IRQ_HANDLED;
}
@@ -635,8 +644,11 @@ static irqreturn_t vdint1_isr(int irq, void *dev_id)
v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, \nInside vdint1_isr...\n);
/* if streaming not started, don't do anything */
- if (!vpfe_dev-started)
+ if (!vpfe_dev-started) {
+ if (vpfe_dev-cfg-clr_intr)
+ vpfe_dev-cfg-clr_intr(irq);
return IRQ_HANDLED;
+ }
spin_lock(vpfe_dev-dma_queue_lock);
if ((vpfe_dev-fmt.fmt.pix.field == V4L2_FIELD_NONE)
@@ -644,6 +656,10 @@ static irqreturn_t vdint1_isr(int irq, void *dev_id)
vpfe_dev-cur_frm == vpfe_dev-next_frm)
vpfe_schedule_next_buffer(vpfe_dev);
spin_unlock(vpfe_dev-dma_queue_lock);
+
+ if (vpfe_dev-cfg-clr_intr)
+ vpfe_dev-cfg-clr_intr(irq);
+
return IRQ_HANDLED;
}
diff --git a/include/media/ti-media/vpfe_capture.h
b/include/media/ti-media/vpfe_capture.h
index 5287368..f0a7b7a 100644
--- a/include/media/ti-media/vpfe_capture.h
+++ b/include/media/ti-media/vpfe_capture.h
@@ -94,6 +94,8 @@ struct vpfe_config {
/* vpfe clock */
struct clk *vpssclk;
struct clk *slaveclk;
+ /* Function for Clearing the interrupt */
+ void (*clr_intr)(int vdint);
};
struct vpfe_device {
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V1 07/10] Davinci VPFE Capture:Return 0 from suspend/resume
From: Vaibhav Hiremath hvaib...@ti.com
Now Suspend/Resume functionality is being handled by respective CCDC
code, so return true (0) from bridge suspend/resume function.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/ti-media/vpfe_capture.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/ti-media/vpfe_capture.c
b/drivers/media/video/ti-media/vpfe_capture.c
index 3ffd636..cece265 100644
--- a/drivers/media/video/ti-media/vpfe_capture.c
+++ b/drivers/media/video/ti-media/vpfe_capture.c
@@ -2022,18 +2022,14 @@ static int __devexit vpfe_remove(struct platform_device
*pdev)
return 0;
}
-static int
-vpfe_suspend(struct device *dev)
+static int vpfe_suspend(struct device *dev)
{
- /* add suspend code here later */
- return -1;
+ return 0;
}
-static int
-vpfe_resume(struct device *dev)
+static int vpfe_resume(struct device *dev)
{
- /* add resume code here later */
- return -1;
+ return 0;
}
static const struct dev_pm_ops vpfe_dev_pm_ops = {
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V1 06/10] DM644x CCDC: Add 10bit BT support
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/ti-media/dm644x_ccdc.c | 16 +---
drivers/media/video/ti-media/dm644x_ccdc_regs.h |8
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/ti-media/dm644x_ccdc.c
b/drivers/media/video/ti-media/dm644x_ccdc.c
index a011d40..506bbf5 100644
--- a/drivers/media/video/ti-media/dm644x_ccdc.c
+++ b/drivers/media/video/ti-media/dm644x_ccdc.c
@@ -399,7 +399,11 @@ void ccdc_config_ycbcr(void)
* configure the FID, VD, HD pin polarity,
* fld,hd pol positive, vd negative, 8-bit data
*/
- syn_mode |= CCDC_SYN_MODE_VD_POL_NEGATIVE | CCDC_SYN_MODE_8BITS;
+ syn_mode |= CCDC_SYN_MODE_VD_POL_NEGATIVE;
+ if (ccdc_cfg.if_type == VPFE_BT656_10BIT)
+ syn_mode |= CCDC_SYN_MODE_10BITS;
+ else
+ syn_mode |= CCDC_SYN_MODE_8BITS;
} else {
/* y/c external sync mode */
syn_mode |= (((params-fid_pol CCDC_FID_POL_MASK)
@@ -418,8 +422,13 @@ void ccdc_config_ycbcr(void)
* configure the order of y cb cr in SDRAM, and disable latch
* internal register on vsync
*/
- regw((params-pix_order CCDC_CCDCFG_Y8POS_SHIFT) |
-CCDC_LATCH_ON_VSYNC_DISABLE, CCDC_CCDCFG);
+ if (ccdc_cfg.if_type == VPFE_BT656_10BIT)
+ regw((params-pix_order CCDC_CCDCFG_Y8POS_SHIFT) |
+ CCDC_LATCH_ON_VSYNC_DISABLE | CCDC_CCDCFG_BW656_10BIT,
+ CCDC_CCDCFG);
+ else
+ regw((params-pix_order CCDC_CCDCFG_Y8POS_SHIFT) |
+ CCDC_LATCH_ON_VSYNC_DISABLE, CCDC_CCDCFG);
/*
* configure the horizontal line offset. This should be a
@@ -825,6 +834,7 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param
*params)
case VPFE_BT656:
case VPFE_YCBCR_SYNC_16:
case VPFE_YCBCR_SYNC_8:
+ case VPFE_BT656_10BIT:
ccdc_cfg.ycbcr.vd_pol = params-vdpol;
ccdc_cfg.ycbcr.hd_pol = params-hdpol;
break;
diff --git a/drivers/media/video/ti-media/dm644x_ccdc_regs.h
b/drivers/media/video/ti-media/dm644x_ccdc_regs.h
index 6e5d053..b18d166 100644
--- a/drivers/media/video/ti-media/dm644x_ccdc_regs.h
+++ b/drivers/media/video/ti-media/dm644x_ccdc_regs.h
@@ -135,11 +135,19 @@
#define CCDC_SYN_MODE_INPMOD_SHIFT 12
#define CCDC_SYN_MODE_INPMOD_MASK 3
#define CCDC_SYN_MODE_8BITS(7 8)
+#define CCDC_SYN_MODE_10BITS (6 8)
+#define CCDC_SYN_MODE_11BITS (5 8)
+#define CCDC_SYN_MODE_12BITS (4 8)
+#define CCDC_SYN_MODE_13BITS (3 8)
+#define CCDC_SYN_MODE_14BITS (2 8)
+#define CCDC_SYN_MODE_15BITS (1 8)
+#define CCDC_SYN_MODE_16BITS (0 8)
#define CCDC_SYN_FLDMODE_MASK 1
#define CCDC_SYN_FLDMODE_SHIFT 7
#define CCDC_REC656IF_BT656_EN 3
#define CCDC_SYN_MODE_VD_POL_NEGATIVE (1 2)
#define CCDC_CCDCFG_Y8POS_SHIFT11
+#define CCDC_CCDCFG_BW656_10BIT(1 5)
#define CCDC_SDOFST_FIELD_INTERLEAVED 0x249
#define CCDC_NO_CULLING0x00ff
#endif
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V1 08/10] DM644x CCDC : Add Suspend/Resume Support
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/ti-media/dm644x_ccdc.c | 114 +++
drivers/media/video/ti-media/dm644x_ccdc_regs.h |2 +-
2 files changed, 115 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/ti-media/dm644x_ccdc.c
b/drivers/media/video/ti-media/dm644x_ccdc.c
index 506bbf5..3045ebc 100644
--- a/drivers/media/video/ti-media/dm644x_ccdc.c
+++ b/drivers/media/video/ti-media/dm644x_ccdc.c
@@ -100,6 +100,9 @@ static u32 ccdc_raw_bayer_pix_formats[] =
static u32 ccdc_raw_yuv_pix_formats[] =
{V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YUYV};
+/* CCDC Save/Restore context */
+static u32 ccdc_ctx[CCDC_REG_END / sizeof(u32)];
+
/* register access routines */
static inline u32 regr(u32 offset)
{
@@ -845,6 +848,87 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param
*params)
return 0;
}
+static void ccdc_save_context(void)
+{
+ ccdc_ctx[CCDC_PCR 2] = regr(CCDC_PCR);
+ ccdc_ctx[CCDC_SYN_MODE 2] = regr(CCDC_SYN_MODE);
+ ccdc_ctx[CCDC_HD_VD_WID 2] = regr(CCDC_HD_VD_WID);
+ ccdc_ctx[CCDC_PIX_LINES 2] = regr(CCDC_PIX_LINES);
+ ccdc_ctx[CCDC_HORZ_INFO 2] = regr(CCDC_HORZ_INFO);
+ ccdc_ctx[CCDC_VERT_START 2] = regr(CCDC_VERT_START);
+ ccdc_ctx[CCDC_VERT_LINES 2] = regr(CCDC_VERT_LINES);
+ ccdc_ctx[CCDC_CULLING 2] = regr(CCDC_CULLING);
+ ccdc_ctx[CCDC_HSIZE_OFF 2] = regr(CCDC_HSIZE_OFF);
+ ccdc_ctx[CCDC_SDOFST 2] = regr(CCDC_SDOFST);
+ ccdc_ctx[CCDC_SDR_ADDR 2] = regr(CCDC_SDR_ADDR);
+ ccdc_ctx[CCDC_CLAMP 2] = regr(CCDC_CLAMP);
+ ccdc_ctx[CCDC_DCSUB 2] = regr(CCDC_DCSUB);
+ ccdc_ctx[CCDC_COLPTN 2] = regr(CCDC_COLPTN);
+ ccdc_ctx[CCDC_BLKCMP 2] = regr(CCDC_BLKCMP);
+ ccdc_ctx[CCDC_FPC 2] = regr(CCDC_FPC);
+ ccdc_ctx[CCDC_FPC_ADDR 2] = regr(CCDC_FPC_ADDR);
+ ccdc_ctx[CCDC_VDINT 2] = regr(CCDC_VDINT);
+ ccdc_ctx[CCDC_ALAW 2] = regr(CCDC_ALAW);
+ ccdc_ctx[CCDC_REC656IF 2] = regr(CCDC_REC656IF);
+ ccdc_ctx[CCDC_CCDCFG 2] = regr(CCDC_CCDCFG);
+ ccdc_ctx[CCDC_FMTCFG 2] = regr(CCDC_FMTCFG);
+ ccdc_ctx[CCDC_FMT_HORZ 2] = regr(CCDC_FMT_HORZ);
+ ccdc_ctx[CCDC_FMT_VERT 2] = regr(CCDC_FMT_VERT);
+ ccdc_ctx[CCDC_FMT_ADDR0 2] = regr(CCDC_FMT_ADDR0);
+ ccdc_ctx[CCDC_FMT_ADDR1 2] = regr(CCDC_FMT_ADDR1);
+ ccdc_ctx[CCDC_FMT_ADDR2 2] = regr(CCDC_FMT_ADDR2);
+ ccdc_ctx[CCDC_FMT_ADDR3 2] = regr(CCDC_FMT_ADDR3);
+ ccdc_ctx[CCDC_FMT_ADDR4 2] = regr(CCDC_FMT_ADDR4);
+ ccdc_ctx[CCDC_FMT_ADDR5 2] = regr(CCDC_FMT_ADDR5);
+ ccdc_ctx[CCDC_FMT_ADDR6 2] = regr(CCDC_FMT_ADDR6);
+ ccdc_ctx[CCDC_FMT_ADDR7 2] = regr(CCDC_FMT_ADDR7);
+ ccdc_ctx[CCDC_PRGEVEN_0 2] = regr(CCDC_PRGEVEN_0);
+ ccdc_ctx[CCDC_PRGEVEN_1 2] = regr(CCDC_PRGEVEN_1);
+ ccdc_ctx[CCDC_PRGODD_0 2] = regr(CCDC_PRGODD_0);
+ ccdc_ctx[CCDC_PRGODD_1 2] = regr(CCDC_PRGODD_1);
+ ccdc_ctx[CCDC_VP_OUT 2] = regr(CCDC_VP_OUT);
+}
+
+static void ccdc_restore_context(void)
+{
+ regw(ccdc_ctx[CCDC_SYN_MODE 2], CCDC_SYN_MODE);
+ regw(ccdc_ctx[CCDC_HD_VD_WID 2], CCDC_HD_VD_WID);
+ regw(ccdc_ctx[CCDC_PIX_LINES 2], CCDC_PIX_LINES);
+ regw(ccdc_ctx[CCDC_HORZ_INFO 2], CCDC_HORZ_INFO);
+ regw(ccdc_ctx[CCDC_VERT_START 2], CCDC_VERT_START);
+ regw(ccdc_ctx[CCDC_VERT_LINES 2], CCDC_VERT_LINES);
+ regw(ccdc_ctx[CCDC_CULLING 2], CCDC_CULLING);
+ regw(ccdc_ctx[CCDC_HSIZE_OFF 2], CCDC_HSIZE_OFF);
+ regw(ccdc_ctx[CCDC_SDOFST 2], CCDC_SDOFST);
+ regw(ccdc_ctx[CCDC_SDR_ADDR 2], CCDC_SDR_ADDR);
+ regw(ccdc_ctx[CCDC_CLAMP 2], CCDC_CLAMP);
+ regw(ccdc_ctx[CCDC_DCSUB 2], CCDC_DCSUB);
+ regw(ccdc_ctx[CCDC_COLPTN 2], CCDC_COLPTN);
+ regw(ccdc_ctx[CCDC_BLKCMP 2], CCDC_BLKCMP);
+ regw(ccdc_ctx[CCDC_FPC 2], CCDC_FPC);
+ regw(ccdc_ctx[CCDC_FPC_ADDR 2], CCDC_FPC_ADDR);
+ regw(ccdc_ctx[CCDC_VDINT 2], CCDC_VDINT);
+ regw(ccdc_ctx[CCDC_ALAW 2], CCDC_ALAW);
+ regw(ccdc_ctx[CCDC_REC656IF 2], CCDC_REC656IF);
+ regw(ccdc_ctx[CCDC_CCDCFG 2], CCDC_CCDCFG);
+ regw(ccdc_ctx[CCDC_FMTCFG 2], CCDC_FMTCFG);
+ regw(ccdc_ctx[CCDC_FMT_HORZ 2], CCDC_FMT_HORZ);
+ regw(ccdc_ctx[CCDC_FMT_VERT 2], CCDC_FMT_VERT);
+ regw(ccdc_ctx[CCDC_FMT_ADDR0 2], CCDC_FMT_ADDR0);
+ regw(ccdc_ctx[CCDC_FMT_ADDR1 2], CCDC_FMT_ADDR1);
+ regw(ccdc_ctx[CCDC_FMT_ADDR2 2], CCDC_FMT_ADDR2);
+ regw(ccdc_ctx[CCDC_FMT_ADDR3 2], CCDC_FMT_ADDR3);
+ regw(ccdc_ctx[CCDC_FMT_ADDR4 2], CCDC_FMT_ADDR4);
+ regw(ccdc_ctx[CCDC_FMT_ADDR5 2], CCDC_FMT_ADDR5);
+ regw(ccdc_ctx[CCDC_FMT_ADDR6 2], CCDC_FMT_ADDR6);
+ regw(ccdc_ctx[CCDC_FMT_ADDR7 2], CCDC_FMT_ADDR7);
+ regw(ccdc_ctx[CCDC_PRGEVEN_0 2], CCDC_PRGEVEN_0);
+ regw(ccdc_ctx[CCDC_PRGEVEN_1 2], CCDC_PRGEVEN_1);
+
[PATCH-V1 09/10] VPFE Capture: Add support for USERPTR mode of operation
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/ti-media/vpfe_capture.c | 94 ++
1 files changed, 79 insertions(+), 15 deletions(-)
diff --git a/drivers/media/video/ti-media/vpfe_capture.c
b/drivers/media/video/ti-media/vpfe_capture.c
index cece265..7d4ab44 100644
--- a/drivers/media/video/ti-media/vpfe_capture.c
+++ b/drivers/media/video/ti-media/vpfe_capture.c
@@ -538,7 +538,24 @@ static void vpfe_schedule_next_buffer(struct vpfe_device
*vpfe_dev)
struct videobuf_buffer, queue);
list_del(vpfe_dev-next_frm-queue);
vpfe_dev-next_frm-state = VIDEOBUF_ACTIVE;
- addr = videobuf_to_dma_contig(vpfe_dev-next_frm);
+ if (V4L2_MEMORY_USERPTR == vpfe_dev-memory)
+ addr = vpfe_dev-cur_frm-boff;
+ else
+ addr = videobuf_to_dma_contig(vpfe_dev-next_frm);
+
+ ccdc_dev-hw_ops.setfbaddr(addr);
+}
+
+static void vpfe_schedule_bottom_field(struct vpfe_device *vpfe_dev)
+{
+ unsigned long addr;
+
+ if (V4L2_MEMORY_USERPTR == vpfe_dev-memory)
+ addr = vpfe_dev-cur_frm-boff;
+ else
+ addr = videobuf_to_dma_contig(vpfe_dev-cur_frm);
+
+ addr += vpfe_dev-field_off;
ccdc_dev-hw_ops.setfbaddr(addr);
}
@@ -559,7 +576,6 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
{
struct vpfe_device *vpfe_dev = dev_id;
enum v4l2_field field;
- unsigned long addr;
int fid;
v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, \nStarting vpfe_isr...\n);
@@ -604,10 +620,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
* the CCDC memory address
*/
if (field == V4L2_FIELD_SEQ_TB) {
- addr =
- videobuf_to_dma_contig(vpfe_dev-cur_frm);
- addr += vpfe_dev-field_off;
- ccdc_dev-hw_ops.setfbaddr(addr);
+ vpfe_schedule_bottom_field(vpfe_dev);
}
goto clear_intr;
}
@@ -1234,7 +1247,10 @@ static int vpfe_videobuf_setup(struct videobuf_queue *vq,
struct vpfe_device *vpfe_dev = fh-vpfe_dev;
v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_buffer_setup\n);
- *size = config_params.device_bufsize;
+ *size = vpfe_dev-fmt.fmt.pix.sizeimage;
+ if (vpfe_dev-memory == V4L2_MEMORY_MMAP
+ vpfe_dev-fmt.fmt.pix.sizeimage config_params.device_bufsize)
+ *size = config_params.device_bufsize;
if (*count config_params.min_numbuffers)
*count = config_params.min_numbuffers;
@@ -1243,6 +1259,46 @@ static int vpfe_videobuf_setup(struct videobuf_queue *vq,
return 0;
}
+/*
+ * vpfe_uservirt_to_phys: This function is used to convert user
+ * space virtual address to physical address.
+ */
+static u32 vpfe_uservirt_to_phys(struct vpfe_device *vpfe_dev, u32 virtp)
+{
+ struct mm_struct *mm = current-mm;
+ unsigned long physp = 0;
+ struct vm_area_struct *vma;
+
+ vma = find_vma(mm, virtp);
+
+ /* For kernel direct-mapped memory, take the easy way */
+ if (virtp = PAGE_OFFSET)
+ physp = virt_to_phys((void *)virtp);
+ else if (vma (vma-vm_flags VM_IO) (vma-vm_pgoff))
+ /* this will catch, kernel-allocated, mmaped-to-usermode addr */
+ physp = (vma-vm_pgoff PAGE_SHIFT) + (virtp - vma-vm_start);
+ else {
+ /* otherwise, use get_user_pages() for general userland pages */
+ int res, nr_pages = 1;
+ struct page *pages;
+ down_read(current-mm-mmap_sem);
+
+ res = get_user_pages(current, current-mm,
+virtp, nr_pages, 1, 0, pages, NULL);
+ up_read(current-mm-mmap_sem);
+
+ if (res == nr_pages)
+ physp = __pa(page_address(pages[0]) +
+(virtp ~PAGE_MASK));
+ else {
+ v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+ get_user_pages failed\n);
+ return 0;
+ }
+ }
+ return physp;
+}
+
static int vpfe_videobuf_prepare(struct videobuf_queue *vq,
struct videobuf_buffer *vb,
enum v4l2_field field)
@@ -1259,6 +1315,18 @@ static int vpfe_videobuf_prepare(struct videobuf_queue
*vq,
vb-size = vpfe_dev-fmt.fmt.pix.sizeimage;
vb-field = field;
}
+
+ if (V4L2_MEMORY_USERPTR == vpfe_dev-memory) {
+ if (!vb-baddr) {
+ v4l2_dbg(1, debug,
[PATCH-V1 10/10] AM3517: Add VPFE Capture driver support
From: Vaibhav Hiremath hvaib...@ti.com
AM3517 and DM644x uses same CCDC IP, so reusing the driver
for AM3517.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 160 +
1 files changed, 160 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 195d0ce..9411979 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -30,11 +30,164 @@
#include plat/board.h
#include plat/common.h
+#include plat/control.h
#include plat/usb.h
#include plat/display.h
+#include media/tvp514x.h
+#include media/ti-media/vpfe_capture.h
+
#include mux.h
+/*
+ * VPFE - Video Decoder interface
+ */
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+};
+
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity= 1,
+ .vs_polarity= 1
+};
+
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI1A,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO(tvp5146, 0x5C),
+ .platform_data = tvp5146_pdata,
+ },
+ },
+};
+
+static void am3517_evm_clear_vpfe_intr(int vdint)
+{
+ unsigned int vpfe_int_clr;
+
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+
+ switch (vdint) {
+ /* VD0 interrrupt */
+ case INT_35XX_CCDC_VD0_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ break;
+ /* VD1 interrrupt */
+ case INT_35XX_CCDC_VD1_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD1_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD1_INT_CLR;
+ break;
+ /* VD2 interrrupt */
+ case INT_35XX_CCDC_VD2_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD2_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD2_INT_CLR;
+ break;
+ /* Clear all interrrupts */
+ default:
+ vpfe_int_clr = ~(AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ vpfe_int_clr |= (AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ break;
+ }
+ omap_ctrl_writel(vpfe_int_clr, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs= ARRAY_SIZE(vpfe_sub_devs),
+ .i2c_adapter_id = 3,
+ .sub_devs = vpfe_sub_devs,
+ .clr_intr = am3517_evm_clear_vpfe_intr,
+ .card_name = DM6446 EVM,
+ .ccdc = DM6446 CCDC,
+};
+
+static struct resource vpfe_resources[] = {
+ {
+ .start = INT_35XX_CCDC_VD0_IRQ,
+ .end= INT_35XX_CCDC_VD0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = INT_35XX_CCDC_VD1_IRQ,
+ .end= INT_35XX_CCDC_VD1_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct platform_device vpfe_capture_dev = {
+ .name = CAPTURE_DRV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(vpfe_resources),
+ .resource = vpfe_resources,
+ .dev = {
+ .dma_mask = vpfe_capture_dma_mask,
+ .coherent_dma_mask
[PATCH-V1 02/10] tvp514x: add YUYV format support
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/tvp514x.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 26b4e71..08fe579 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
@@ -212,6 +212,13 @@ static const struct v4l2_fmtdesc tvp514x_fmt_list[] = {
.description = 8-bit UYVY 4:2:2 Format,
.pixelformat = V4L2_PIX_FMT_UYVY,
},
+ {
+.index = 1,
+.type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+.flags = 0,
+.description = 8-bit YUYV 4:2:2 Format,
+.pixelformat = V4L2_PIX_FMT_YUYV,
+ },
};
/**
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 10/11] omap: musb: get rid of dyn_fifo
-Original Message-
From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-
kernel-boun...@lists.infradead.org] On Behalf Of Tony Lindgren
Sent: Saturday, February 20, 2010 5:01 AM
To: linux-arm-ker...@lists.infradead.org
Cc: Felipe Balbi; linux-omap@vger.kernel.org; linux-...@vger.kernel.org
Subject: [PATCH 10/11] omap: musb: get rid of dyn_fifo
From: Felipe Balbi felipe.ba...@nokia.com
that's deprecated as we can check dyn_fifo from
CONFIGDATA register.
Cc: linux-...@vger.kernel.org
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
Felipe,
This patch causes musb init failure if below patch[1] is not taken.
[1] http://marc.info/?l=linux-omapm=126088393130177w=2
I don't see patch [1] in Greg's queue also so please forward it to
Greg.
Regards,
Ajay
---
arch/arm/mach-omap2/usb-musb.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-
musb.c
index 2221a6c..85feb60 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -49,7 +49,6 @@ static struct resource musb_resources[] = {
static struct musb_hdrc_config musb_config = {
.multipoint = 1,
- .dyn_fifo = 1,
.num_eps= 16,
.ram_bits = 12,
};
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V6 0/2] OMAP3: Add V4L2 display driver support
From: Vaibhav Hiremath hvaib...@ti.com This is 6th Version of patch-set, adds support for V4L2 display driver ontop of DSS2 framework. Please note that this patch is dependent on patch which add ti-media directory (submitted earlier to this patch series). Vaibhav Hiremath (2): OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2 OMAP2/3: Add V4L2 DSS driver support in device.c arch/arm/plat-omap/devices.c| 29 + drivers/media/video/ti-media/Kconfig| 12 + drivers/media/video/ti-media/Makefile |4 + drivers/media/video/ti-media/omap_vout.c| 2655 +++ drivers/media/video/ti-media/omap_voutdef.h | 148 ++ drivers/media/video/ti-media/omap_voutlib.c | 258 +++ drivers/media/video/ti-media/omap_voutlib.h | 34 + 7 files changed, 3140 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/ti-media/omap_vout.c create mode 100644 drivers/media/video/ti-media/omap_voutdef.h create mode 100644 drivers/media/video/ti-media/omap_voutlib.c create mode 100644 drivers/media/video/ti-media/omap_voutlib.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V6 2/2] OMAP2/3: Add V4L2 DSS driver support in device.c
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/plat-omap/devices.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index 30b5db7..64f2a3a 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -357,6 +357,34 @@ static void omap_init_wdt(void)
static inline void omap_init_wdt(void) {}
#endif
+/*---*/
+
+#if defined(CONFIG_VIDEO_OMAP2_VOUT) || \
+ defined(CONFIG_VIDEO_OMAP2_VOUT_MODULE)
+#if defined (CONFIG_FB_OMAP2) || defined (CONFIG_FB_OMAP2_MODULE)
+static struct resource omap_vout_resource[3 - CONFIG_FB_OMAP2_NUM_FBS] = {
+};
+#else
+static struct resource omap_vout_resource[2] = {
+};
+#endif
+
+static struct platform_device omap_vout_device = {
+ .name = omap_vout,
+ .num_resources = ARRAY_SIZE(omap_vout_resource),
+ .resource = omap_vout_resource[0],
+ .id = -1,
+};
+static void omap_init_vout(void)
+{
+ (void) platform_device_register(omap_vout_device);
+}
+#else
+static inline void omap_init_vout(void) {}
+#endif
+
+/*---*/
+
/*
* This gets called after board-specific INIT_MACHINE, and initializes most
* on-chip peripherals accessible on this board (except for few like USB):
@@ -387,6 +415,7 @@ static int __init omap_init_devices(void)
omap_init_rng();
omap_init_uwire();
omap_init_wdt();
+ omap_init_vout();
return 0;
}
arch_initcall(omap_init_devices);
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] musb: fix power field to hold all possible values
MUSB can supply upto 500mA such as, AM3517 and OMAP3EVM Rev =E and thus
the 'power' field has to hold values above 255.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/plat-omap/include/plat/usb.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 288e29e..b181297 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -46,7 +46,7 @@ struct ehci_hcd_omap_platform_data {
struct omap_musb_board_data {
u8 interface_type;
u8 mode;
- u8 power;
+ u16 power;
};
enum musb_interface{MUSB_INTERFACE_ULPI, MUSB_INTERFACE_UTMI};
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] musb: fix power field to hold all possible values
Hi, On Tue, Feb 23, 2010 at 03:16:44PM +0530, Ajay Kumar Gupta wrote: MUSB can supply upto 500mA such as, AM3517 and OMAP3EVM Rev =E and thus the 'power' field has to hold values above 255. power on the arch code is same as bMaxPower it will be multiplied by two on musb_core.c. See line 150 of that file. Meaning 500mA is set to 250 on the board-file. -- balbi -- To unsubscribe from this list: send the line unsubscribe 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] musb: fix power field to hold all possible values
Felipe Balbi wrote: Hi, On Tue, Feb 23, 2010 at 03:16:44PM +0530, Ajay Kumar Gupta wrote: MUSB can supply upto 500mA such as, AM3517 and OMAP3EVM Rev =E and thus the 'power' field has to hold values above 255. power on the arch code is same as bMaxPower it will be multiplied by two on musb_core.c. See line 150 of that file. Meaning 500mA is set to 250 on the board-file. Any reason we have the multiply by 2 there? - Anand -- To unsubscribe from this list: send the line unsubscribe 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 RFC]OMAP3:PM:Dynamic Calculation of SDRC stall latency during DVFS
Hi Jouni, -Original Message- From: Högander Jouni [mailto:jouni.hogan...@nokia.com] Sent: Monday, February 15, 2010 2:27 PM To: Reddy, Teerth Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath; Paul Walmsley; Kevin Hilman Subject: Re: [PATCH RFC]OMAP3:PM:Dynamic Calculation of SDRC stall latency during DVFS ext Reddy, Teerth tee...@ti.com writes: From: Teerth Reddy tee...@ti.com Dynamic Calculation of SDRC stall latency during DVFS The patch has the changes to calculate the dpll3 clock stabilization delay dynamically. The SRAM delay is calibrated during bootup using the gptimers and used while calculating the stabilization delay. By using the dynamic method the dependency on the type of cache being used is removed. Hence there is no need of loop based calculation. The wait time for L3 clock stabilization is calculated using the formula : 4*REFCLK + 8*CLKOUTX2, which uses the M, N and M2 read from the registers.Since this value gives slightly less value, 2us is added as buffer for safety. This works fine for omap3. I think you could make a difference on 3630 in this patch. 3630 has different formula to calculate needed delay after setting m2 divider. We have considered the worst case scenario and used this formula which holds good for 3630 as well. We have used register dump and observability signal analysis to comeup with this formula. Regards Teerth -- To unsubscribe from this list: send the line unsubscribe 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] musb: fix power field to hold all possible values
Hi, On Tue, Feb 23, 2010 at 03:27:39PM +0530, Gadiyar, Anand wrote: power on the arch code is same as bMaxPower it will be multiplied by two on musb_core.c. See line 150 of that file. Meaning 500mA is set to 250 on the board-file. Any reason we have the multiply by 2 there? no big reason. It's just legacy code. Maybe it's to keep consistency with the gadget framework, donno. -- balbi -- To unsubscribe from this list: send the line unsubscribe 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: [RESEND][PATCHv2 4/4] OMAP: DSS2: Add Innolux 7 display for DEVKIT8000
On Fri, 2010-02-19 at 13:57 +0100, ext Thomas Weber wrote:
Tomi Valkeinen wrote:
On Fri, 2010-02-12 at 06:55 +0100, ext Jaya Kumar wrote:
On Fri, Feb 12, 2010 at 3:41 AM, Thomas Weber sw...@gmx.li wrote:
[snip]
+
+static struct omap_video_timings innolux_at_timings = {
+ .x_res = 800,
+ .y_res = 480,
+
+ .pixel_clock= 4,
+
+ .hsw= 48,
+ .hfp= 1,
+ .hbp= 1,
+
+ .vsw= 3,
+ .vfp= 12,
+ .vbp= 25,
+};
+
+static int innolux_at_panel_probe(struct omap_dss_device *dssdev)
+{
+ dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS;
+ dssdev-panel.acb = 0x28;
+ dssdev-panel.timings = innolux_at_timings;
+
+ return 0;
+}
+
Hi Thomas, Tomi,
Just curious, does this patch imply that code like this needs to be
written for every single LCD type and resolution that can be connected
to omap2? Maybe there is a better way, like a common table of timings
and values that can be selected with a module option or even
autodetected.
Yes, it is true that currently you need to write these for every LCD. I
have been thinking this issue, and I think we can make a common driver.
However, it's not just selecting timings, as LCDs can have also other
characteristics than just the video timings. For example, some may have
power on/off line, some reset enable/disable, some need 50ms after
reset, some 80ms after reset etc.
But if we manage to get a sane set of those settings into the table, we
could perhaps cover most of the dummy LCDs with it.
This change doesn't probably need any changes to the DSS core, only for
the panel driver. Any takers for this task? =)
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
Hello,
sorry but I am not able to take the task.
Make it sense to rework this patch or do you want first the changes to
the panel driver?
I probably won't have time to implement this generic panel driver yet.
However, I will be merging some DSS driver model changes (sent to
mailing lists) soon, after which this patch needs to be changed a bit.
The changes can be found from
http://gitorious.org/linux-omap-dss2/linux/commits/work but they may
still change a bit.
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] PM-WIP-OPP: Fixing wrong target level being passed during Core DVFS.
-Original Message-
From: Menon, Nishanth
Sent: Monday, February 22, 2010 11:31 PM
To: Aguirre, Sergio; Gopinath, Thara
Cc: linux-omap@vger.kernel.org; Kevin Hilman; Kristo Tero (Nokia-
D/Tampere)
Subject: RE: [PATCH] PM-WIP-OPP: Fixing wrong target level being passed
during Core DVFS.
From: Aguirre, Sergio
Sent: Tuesday, February 23, 2010 7:28 AM
To: Menon, Nishanth; Gopinath, Thara
[...]
Signed-off-by: Thara Gopinath th...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/resource34xx.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-
omap2/resource34xx.c
index 3604a38..d2336d8 100644
--- a/arch/arm/mach-omap2/resource34xx.c
+++ b/arch/arm/mach-omap2/resource34xx.c
@@ -463,6 +463,7 @@ int set_opp(struct shared_resource *resp, u32
target_level)
} else if (resp == vdd2_resp) {
unsigned long req_l3_freq;
struct omap_opp *oppx = NULL;
+ u8 opp;
/* Convert the tput in KiB/s to Bus frequency in MHz */
req_l3_freq = (target_level * 1000)/4;
@@ -478,10 +479,11 @@ int set_opp(struct shared_resource *resp, u32
target_level)
/* uh uh.. no OPPs?? */
BUG_ON(IS_ERR(oppx));
If you do target_level = 0; here, the entire patch is a oneliner :)
Actually, IMHO will be even more clean, to standardize all OPP value
passing to be u8.
Do you really need to be prepared for 2^32 opp values? ;)
Using OPP ID has to be completely removed from resource34xx.c - this
action is still pending. In this case, using u8 OR initing the
target_level to 0 has the same impact. Why add code that will be removed
later on anyways?
Well, I'm not proposing for code addition, but to fix that code just by
changing opp level parameters to u8, instead of u32, like this:
-int set_opp(struct shared_resource *resp, u32 target_level)
+int set_opp(struct shared_resource *resp, u8 target_level)
If you're going to replace all this in the near future, then it's
understandable to hold even this patch (target_level = 0).
Regards,
Sergio
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
About multicore OMAP
Hi Guys, I workin on OMAP4, just started, I appreciate, if some one could brief out working drivers and SMP benchmark data? Thanks, BR Jacob. -- To unsubscribe from this list: send the line unsubscribe 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: About multicore OMAP
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Jacob
john
Sent: Tuesday, February 23, 2010 6:34 PM
To: linux-omap@vger.kernel.org
Subject: About multicore OMAP
Hi Guys, I workin on OMAP4, just started,
I appreciate, if some one could brief out working drivers and SMP
benchmark data?
Welcome John !!
Can be explicit what you are looking for? Which omap4
platform do you have ?
Regards,
Santosh
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH] OMAP: HWMOD: Bug fixes in hwmod structure definitions
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Friday, February 19, 2010 2:20 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP: HWMOD: Bug fixes in hwmod structure definitions
Hello Thara,
some comments.
On Thu, 18 Feb 2010, Thara Gopinath wrote:
This patch corrects the width of some variables in hwmod structures
where the values to be stored in these variables exceed the current
field width.
Signed-off-by: Thara Gopinath th...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/plat-omap/include/plat/omap_hwmod.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-
omap/include/plat/omap_hwmod.h
index 921990e..06a7f20 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -258,7 +258,7 @@ struct omap_hwmod_sysconfig {
u16 sysc_offs;
u16 syss_offs;
u8 idlemodes;
- u8 sysc_flags;
+ u16 sysc_flags;
This part is fine.
u8 clockact;
};
@@ -280,9 +280,9 @@ struct omap_hwmod_sysconfig {
struct omap_hwmod_omap2_prcm {
s16 module_offs;
u8 prcm_reg_id;
- u8 module_bit;
+ u32 module_bit;
u8 idlest_reg_id;
- u8 idlest_idle_bit;
+ u32 idlest_idle_bit;
u8 idlest_stdby_bit;
};
This part I don't understand. These are bit shifts in a 32 bit register,
e.g., (1 idlest_idle_bit), so how could these ever exceed 31?
Hi Paul,
Oh... ok. I was under the impression these bits are to be assigned the value
1 shift.. My bad.. Do you want me to re sumbmit the patch with just the
first fix.
Regards
Thara
- 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: About multicore OMAP
It's Blaze with two lcd's and pico, looks great. Can I have this linux-omap kernel running on OMAP4?, plus I'm looking for SMP benchmark results etc. thanks On Tue, Feb 23, 2010 at 7:04 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Jacob john Sent: Tuesday, February 23, 2010 6:34 PM To: linux-omap@vger.kernel.org Subject: About multicore OMAP Hi Guys, I workin on OMAP4, just started, I appreciate, if some one could brief out working drivers and SMP benchmark data? Welcome John !! Can be explicit what you are looking for? Which omap4 platform do you have ? 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: About multicore OMAP
-Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Tuesday, February 23, 2010 7:51 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP It's Blaze with two lcd's and pico, looks great. Can I have this linux-omap kernel running on OMAP4?, plus I'm looking for SMP benchmark results etc. Linux-omap kernel with omap_4430sdp_defconfig will boot on blaze with SMP. This won't have lot of driver support as such currently. Also L2 cache support is in on the way to make it to mainline as well. You should be able to play with this with some basic benchmark test related to CPU. Display , Audio, Pico, keypad, touchscreeen etc drivers are available with the release and you should be able get more details from the TI contact person who gave you the blaze. You can also get the performance numbers from same source Regards, Santosh
Re: [PATCH 10/11] omap: musb: get rid of dyn_fifo
Tony Lindgren wrote:
From: Felipe Balbi felipe.ba...@nokia.com
that's deprecated as we can check dyn_fifo from
CONFIGDATA register.
Cc: linux-...@vger.kernel.org
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/usb-musb.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 2221a6c..85feb60 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -49,7 +49,6 @@ static struct resource musb_resources[] = {
static struct musb_hdrc_config musb_config = {
.multipoint = 1,
- .dyn_fifo = 1,
.num_eps= 16,
.ram_bits = 12,
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
I think this patch breaks musb_hdrc.
In musb_core_init is musb-config-dyn_fifo checked but is never set.
So I get the following dmesg output:
musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split,
HB-ISO Rx, HB-ISO Tx, SoftConn)
musb_hdrc: MHDRC RTL version 1.400
musb_core_init 1405: reconfigure software for Dynamic FIFOs
musb_hdrc musb_hdrc: musb_init_controller failed with status -19
Thomas
--
To unsubscribe from this list: send the line unsubscribe 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 10/11] omap: musb: get rid of dyn_fifo
On Tue, Feb 23, 2010 at 3:55 PM, Thomas Weber we...@corscience.de wrote:
Tony Lindgren wrote:
From: Felipe Balbi felipe.ba...@nokia.com
that's deprecated as we can check dyn_fifo from
CONFIGDATA register.
Cc: linux-...@vger.kernel.org
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/usb-musb.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 2221a6c..85feb60 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -49,7 +49,6 @@ static struct resource musb_resources[] = {
static struct musb_hdrc_config musb_config = {
.multipoint = 1,
- .dyn_fifo = 1,
.num_eps = 16,
.ram_bits = 12,
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
I think this patch breaks musb_hdrc.
In musb_core_init is musb-config-dyn_fifo checked but is never set.
So I get the following dmesg output:
musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split,
HB-ISO Rx, HB-ISO Tx, SoftConn)
musb_hdrc: MHDRC RTL version 1.400
musb_core_init 1405: reconfigure software for Dynamic FIFOs
musb_hdrc musb_hdrc: musb_init_controller failed with status -19
Thomas
I think I have the same problem.
There are other problems right now (I'm trying several different
branch/defconfig
combinations) so I can't be 100% sure.
--
To unsubscribe from this list: send the line unsubscribe 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 10/11] omap: musb: get rid of dyn_fifo
I think this patch breaks musb_hdrc. In musb_core_init is musb-config-dyn_fifo checked but is never set. So I get the following dmesg output: musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb_hdrc: MHDRC RTL version 1.400 musb_core_init 1405: reconfigure software for Dynamic FIFOs musb_hdrc musb_hdrc: musb_init_controller failed with status -19 Thomas I think I have the same problem. There are other problems right now (I'm trying several different branch/defconfig combinations) so I can't be 100% sure. Ajay reported earlier today [1] that there is a dependency patch [2] that needs to be taken in. Looks like it was missed when the MUSB patchset was added to linux-omap for extra testing. - Anand [1] http://marc.info/?l=linux-omapm=126691578831301w=2 [2] http://marc.info/?l=linux-omapm=126088393130177w=2
[PATCH] OMAP: McBSP: Drop unnecessary status/error bit clearing on reg_cache retrieved register values
The MsBSP register cache will never have any error/status flags set, since
these flags are never written to the reg_cache. So it is kind of not
necessary to clear these flags, which are actually always 0.
In other words, clearing the status/error flags are not necessary, since the
reg_cache will never got these bits set. We can just write back the
register content from the cache as it is when clearing an error condition.
Created against l-o for-next commit 62a7c2cc4c8e57e80ccf379536f362fe6e863ac3
dated 2010-02-22.
Tested on Amstrad Delta.
Reported-by: Peter Ujfalusi peter.ujfal...@nokia.com
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Friday 15 January 2010 10:11:28 Peter Ujfalusi wrote:
...
@@ -653,7 +657,7 @@ int omap_mcbsp_pollwrite(unsigned int id
if (MCBSP_READ(mcbsp, SPCR2) XSYNC_ERR) {
/* clear error */
MCBSP_WRITE(mcbsp, SPCR2,
- MCBSP_READ(mcbsp, SPCR2) (~XSYNC_ERR));
+ MCBSP_READ_CACHE(mcbsp, SPCR2)
(~XSYNC_ERR));
Well, I think here also, the reg_cache does not have the XSYNC_ERR set, it
is only set in the McBSP register.
Peter,
Yes, that's right.
/* resend */
return -1;
} else {
@@ -662,10 +666,12 @@ int omap_mcbsp_pollwrite(unsigned int id
while (!(MCBSP_READ(mcbsp, SPCR2) XRDY)) {
if (attemps++ 1000) {
MCBSP_WRITE(mcbsp, SPCR2,
- MCBSP_READ(mcbsp, SPCR2)
(~XRST));
+ MCBSP_READ_CACHE(mcbsp,
SPCR2)
+ (~XRST));
Also here, the XRST will surely not set in the cached SPCR2...
Probably not. XRST and other xRST flags seem to be controlled by software
only, and can be actually set by omap_mcbsp_request() to get required
functional blocks out of reset state. Here it is toggled back and forth, so
the code has to reset it explicitly and then set it back again.
This applies fro all other cases regarding to status/error bits in McBSP.
You probably managed to point out all applicable cases, since I was not able
to find more, neither while examining the code itself nor reviewing the
SPRU592E reference one more time.
udelay(10);
MCBSP_WRITE(mcbsp, SPCR2,
- MCBSP_READ(mcbsp, SPCR2) |
(XRST));
+ MCBSP_READ_CACHE(mcbsp,
SPCR2) |
+ (XRST));
udelay(10);
dev_err(mcbsp-dev, Could not write to
McBSP%d Register\n, mcbsp-id);
Thanks,
Janusz
arch/arm/plat-omap/mcbsp.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
--- git/arch/arm/plat-omap/mcbsp.c.orig 2010-02-23 11:36:43.0 +0100
+++ git/arch/arm/plat-omap/mcbsp.c 2010-02-23 16:39:45.0 +0100
@@ -133,8 +133,7 @@ static irqreturn_t omap_mcbsp_tx_irq_han
dev_err(mcbsp_tx-dev, TX Frame Sync Error! : 0x%x\n,
irqst_spcr2);
/* Writing zero to XSYNC_ERR clears the IRQ */
- MCBSP_WRITE(mcbsp_tx, SPCR2,
- MCBSP_READ_CACHE(mcbsp_tx, SPCR2) ~(XSYNC_ERR));
+ MCBSP_WRITE(mcbsp_tx, SPCR2, MCBSP_READ_CACHE(mcbsp_tx, SPCR2));
} else {
complete(mcbsp_tx-tx_irq_completion);
}
@@ -154,8 +153,7 @@ static irqreturn_t omap_mcbsp_rx_irq_han
dev_err(mcbsp_rx-dev, RX Frame Sync Error! : 0x%x\n,
irqst_spcr1);
/* Writing zero to RSYNC_ERR clears the IRQ */
- MCBSP_WRITE(mcbsp_rx, SPCR1,
- MCBSP_READ_CACHE(mcbsp_rx, SPCR1) ~(RSYNC_ERR));
+ MCBSP_WRITE(mcbsp_rx, SPCR1, MCBSP_READ_CACHE(mcbsp_rx, SPCR1));
} else {
complete(mcbsp_rx-tx_irq_completion);
}
@@ -934,8 +932,7 @@ int omap_mcbsp_pollwrite(unsigned int id
/* if frame sync error - clear the error */
if (MCBSP_READ(mcbsp, SPCR2) XSYNC_ERR) {
/* clear error */
- MCBSP_WRITE(mcbsp, SPCR2,
- MCBSP_READ_CACHE(mcbsp, SPCR2) (~XSYNC_ERR));
+ MCBSP_WRITE(mcbsp, SPCR2, MCBSP_READ_CACHE(mcbsp, SPCR2));
/* resend */
return -1;
} else {
@@ -975,8 +972,7 @@ int omap_mcbsp_pollread(unsigned int id,
/* if frame sync error - clear the error */
if (MCBSP_READ(mcbsp, SPCR1) RSYNC_ERR) {
/* clear error */
- MCBSP_WRITE(mcbsp, SPCR1,
- MCBSP_READ_CACHE(mcbsp, SPCR1) (~RSYNC_ERR));
+ MCBSP_WRITE(mcbsp, SPCR1,
[PATCH 1/5 v2] omap2/3/4: mailbox: remove compiler warning
From 02c45559105c62343e31226fe67117231ea10c35 Mon Sep 17 00:00:00 2001
From: Suman Anna s-a...@ti.com
Date: Mon, 25 Jan 2010 18:27:21 -0600
Subject: [PATCH] omap2/3/4: mailbox: remove compiler warning
Remove a compiler warning in device-specific
mailbox module.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/mailbox.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 2c9fd1c..a732664 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -409,19 +409,19 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
if (unlikely(!res)) {
dev_err(pdev-dev, invalid irq resource\n);
ret = -ENODEV;
- goto err_iva1;
+ omap_mbox_unregister(mbox_dsp_info);
+ goto err_dsp;
}
mbox_iva_info.irq = res-start;
ret = omap_mbox_register(pdev-dev, mbox_iva_info);
- if (ret)
- goto err_iva1;
+ if (ret) {
+ omap_mbox_unregister(mbox_dsp_info);
+ goto err_dsp;
+ }
}
#endif
return 0;
-err_iva1:
- omap_mbox_unregister(mbox_dsp_info);
-
err_dsp:
iounmap(mbox_base);
return ret;
--
1.6.6.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: [RESEND] [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
Omar, +#if defined(CONFIG_ARCH_OMAP2420) /* IVA */ err_iva1: - omap_mbox_unregister(mbox_dsp_info); + if (cpu_is_omap2420()) + omap_mbox_unregister(mbox_dsp_info); +#endif why not moving omap_mbox_unregister to the block containing the ifdefs? at least you won't be adding an ifdef and if(cpu_xx) Thanks Omar for the comment. I have received multiple comments on this new #ifdef. So, have sent out a new cleaner patch removing this. Regards Suman -- To unsubscribe from this list: send the line unsubscribe 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/9] omap3/4: uart: fix full-fifo write abort
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Tuesday, February 23, 2010 3:10 AM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Woodruff, Richard; Ghorai,
Sukumar
Subject: Re: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
* Shilimkar, Santosh santosh.shilim...@ti.com [100218 21:22]:
Bye the way just to add bit more clarity, this patch addresses TX
hardware restriction in the new UART IP used on omap3630 and omap4430.
First part of the fix for RX is already in mainline,
Commit: ce13d4716a276f4331d78ba28a5093a63822ab95
More details on this thread are here.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19447.html
Thanks, I've updated the comments for this patch with the link above
and added the whole series into omap for-next.
Please drop this patch since it has introduces regression on interrupt latency
while traces are enabled. Since 8250 driver calls serial_out() function is with
interrupt disabled ( spin_lock_irqsave), the interrupt latency at times is
as high as in few milliseconds because of error case.
I shall work towards this issue but for now we should drop this since the side
effect
of this change is known
-Original Message-
From: Shilimkar, Santosh
Sent: Thursday, February 18, 2010 2:29 PM
To: t...@atomide.com
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Shilimkar, Santosh;
Woodruff,
Richard; Ghorai, Sukumar
Subject: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
This patch is addition to the already merged commit on non-empty
uart fifo read abort. ce13d4716a276f4331d78ba28a5093a63822ab95
OMAP3630 and OMAP4430 UART IP blocks have a restriction on TX FIFO
too. If you try to write to the tx fifo when it is full, the system
aborts.
This can be easily reproducible by not suppressing interconnect errors or
long duration testing where continuous prints over console from multiple
threads. This patch is addressing the issue by ensuring that write is
not issued while fifo is full. A timeout is added to avoid any hang
on fifo-full for 10 mS which is unlikely case.
Patch is validated on OMAP3630 and OMAP4 SDP.
V2 version removed the additional 1 uS on every TX as per
Tony's suggestion
Signed-off-by: Woodruff Richard r-woodru...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Ghorai Sukumar s-gho...@ti.com
---
arch/arm/mach-omap2/serial.c | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 5f3035e..b79bc89 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -23,6 +23,7 @@
#include linux/serial_reg.h
#include linux/clk.h
#include linux/io.h
+#include linux/delay.h
#include plat/common.h
#include plat/board.h
@@ -160,6 +161,13 @@ static inline unsigned int serial_read_reg(struct
plat_serial8250_port *up,
return (unsigned int)__raw_readb(up-membase + offset);
}
+static inline void __serial_write_reg(struct uart_port *up, int offset,
+ int value)
+{
+ offset = up-regshift;
+ __raw_writeb(value, up-membase + offset);
+}
+
static inline void serial_write_reg(struct plat_serial8250_port *p, int
offset,
int value)
{
@@ -620,6 +628,20 @@ static unsigned int serial_in_override(struct
uart_port *up, int offset)
return __serial_read_reg(up, offset);
}
+static void serial_out_override(struct uart_port *up, int offset, int
value)
+{
+ unsigned int status, tmout = 1;
+
+ status = __serial_read_reg(up, UART_LSR);
+ while (!(status UART_LSR_THRE)) {
+ /* Wait up to 10ms for the character(s) to be sent. */
+ if (--tmout == 0)
+ break;
+ udelay(1);
+ status = __serial_read_reg(up, UART_LSR);
+ }
+ __serial_write_reg(up, offset, value);
+}
void __init omap_serial_early_init(void)
{
int i;
@@ -721,11 +743,14 @@ void __init omap_serial_init_port(int port)
* omap3xxx: Never read empty UART fifo on UARTs
* with IP rev =0x52
*/
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
uart-p-serial_in = serial_in_override;
- else if ((serial_read_reg(uart-p, UART_OMAP_MVER) 0xFF)
- = UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+ uart-p-serial_out = serial_out_override;
+ } else if ((serial_read_reg(uart-p, UART_OMAP_MVER) 0xFF)
+ = UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV) {
uart-p-serial_in = serial_in_override;
+ uart-p-serial_out = serial_out_override;
+ }
}
/**
--
1.6.0.4
Regards,
Santosh
--
To
Re: [PATCH] DSPBRIDGE: Get rid of memset() from MEM_Calloc()
On 2/16/2010 9:40 AM, Ameya Palande wrote: Signed-off-by: Ameya Palandeameya.pala...@nokia.com --- drivers/dsp/bridge/services/mem.c | 11 --- 1 files changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/dsp/bridge/services/mem.c b/drivers/dsp/bridge/services/mem.c index 614396e..2501eee 100644 --- a/drivers/dsp/bridge/services/mem.c +++ b/drivers/dsp/bridge/services/mem.c @@ -227,16 +227,13 @@ void *MEM_Calloc(u32 cBytes, enum MEM_POOLATTRS type) case MEM_NONPAGED: /* If non-paged memory required, see note at top of file. */ case MEM_PAGED: - pMem = kmalloc(cBytes, + pMem = kzalloc(cBytes, (in_atomic()) ? GFP_ATOMIC : GFP_KERNEL); - if (pMem) - memset(pMem, 0, cBytes); - break; case MEM_LARGEVIRTMEM: - pMem = vmalloc(cBytes); - if (pMem) - memset(pMem, 0, cBytes); + pMem = __vmalloc(cBytes, + GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO, + PAGE_KERNEL); break; default: GT_1trace(MEM_debugMask, GT_6CLASS, Acked-by: Omar Ramirez Luna omar.rami...@ti.com Pushed to dspbridge - 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 2/2] DSPBRIDGE: Reclaim all pending buffer on resource cleanup
On 2/16/2010 6:40 PM, Guzman Lugo, Fernando wrote: From 6ed51fea16df51e88a25bda2b9908f0a43b86303 Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugox0095...@ti.com Date: Tue, 16 Feb 2010 18:32:02 -0600 Subject: [PATCH] DSPBRIDGE: Reclaim all pending buffer on resource cleanup Before in case of pending buffer while we try to close a stream, it was doing only one reclaim, in the case there were more pending buffer the second STRM_Close would also fail, now all the pending buffers are reclaim. Signed-off-by: Fernando Guzman Lugox0095...@ti.com --- drivers/dsp/bridge/rmgr/drv.c | 22 +- 1 files changed, 13 insertions(+), 9 deletions(-) Acked-by: Omar Ramirez Luna omar.rami...@ti.com Pushed to dspbridge - 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 1/4] DSPBRIDGE: Rename DMM_RES_OBJECT to DMM_MAP_OBJECT
On 2/18/2010 8:40 AM, Ameya Palande wrote: In its current state DMM_RES_OBJECT is not correctly tracking reserve and unreserve but only map and unmap. So lets rename it to DMM_MAP_OBJECT to clarify what it is really doing! In addition to this, this patch also does some trivial code cleanup. Signed-off-by: Ameya Palandeameya.pala...@nokia.com Reviewed-by: Felipe Contrerasfelipe.contre...@nokia.com --- arch/arm/plat-omap/include/dspbridge/drv.h | 14 +++--- drivers/dsp/bridge/rmgr/drv.c | 69 ++-- drivers/dsp/bridge/rmgr/drv_interface.c|2 +- 3 files changed, 43 insertions(+), 42 deletions(-) Pushed to dspbridge - 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 2/4] DSPBRIDGE: New reserved memory accounting framework
On 2/18/2010 8:40 AM, Ameya Palande wrote: DSP_RSV_OBJECT is introduced to track reserved memory accounting information. This will allow us to do proper cleanup for memory reserved using PROC_ReserveMemory(). Signed-off-by: Ameya Palandeameya.pala...@nokia.com --- arch/arm/plat-omap/include/dspbridge/drv.h | 10 arch/arm/plat-omap/include/dspbridge/proc.h |4 +- drivers/dsp/bridge/pmgr/wcd.c |7 ++- drivers/dsp/bridge/rmgr/drv.c | 18 +--- drivers/dsp/bridge/rmgr/drv_interface.c |2 + drivers/dsp/bridge/rmgr/node.c |5 +- drivers/dsp/bridge/rmgr/proc.c | 62 ++- 7 files changed, 83 insertions(+), 25 deletions(-) Pushed to dspbridge - 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 3/4] DSPBRIDGE: Fix memory corruption in DRV_ProcFreeDMMRes
On 2/18/2010 8:40 AM, Ameya Palande wrote: This patch fixes following issues: 1. pDMMRes was dereferenced and modified when it was already freed by PROC_Ummap(). This results in memory corruption. 2. Instead of passing ulDSPAddr, ulDSPResAddr was passed to PROC_UnMap() which will not retrieve correct DMMRes element. Signed-off-by: Ameya Palandeameya.pala...@nokia.com Signed-off-by: Felipe Contrerasfelipe.contre...@nokia.com --- drivers/dsp/bridge/rmgr/drv.c | 12 ++-- 1 files changed, 2 insertions(+), 10 deletions(-) Pushed to dspbridge - 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 4/4] DSPBRIDGE: Improved mapped memory cleanup
On 2/18/2010 8:40 AM, Ameya Palande wrote: This patch improves current mapped memory cleanup mechanism by using linux native list implementation. As a side effect we also get following benefits: 1. Unnecessary data members in DMM_MAP_OBJECT are removed which results in memory saving. 2. Following functions are removed as they are not needed anymore: DRV_ProcFreeDMMRes() DRV_UpdateDMMResElement() DRV_InsertDMMResElement() DRV_GetDMMResElement() DRV_RemoveDMMResElement() Signed-off-by: Ameya Palandeameya.pala...@nokia.com --- arch/arm/plat-omap/include/dspbridge/drv.h | 30 +--- .../plat-omap/include/dspbridge/resourcecleanup.h | 11 -- drivers/dsp/bridge/rmgr/drv.c | 161 ++-- drivers/dsp/bridge/rmgr/drv_interface.c|3 +- drivers/dsp/bridge/rmgr/proc.c | 43 -- 5 files changed, 54 insertions(+), 194 deletions(-) Pushed to dspbridge - 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: About multicore OMAP
John, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Tuesday, February 23, 2010 8:01 PM To: Jacob john Cc: linux-omap@vger.kernel.org Subject: RE: About multicore OMAP -Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Tuesday, February 23, 2010 7:51 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP It's Blaze with two lcd's and pico, looks great. Can I have this linux-omap kernel running on OMAP4?, plus I'm looking for SMP benchmark results etc. Linux-omap kernel with omap_4430sdp_defconfig will boot on blaze with SMP. This won't have lot of driver support as such currently. Also L2 cache support is in on the way to make it to mainline as well. You should be able to play with this with some basic benchmark test related to CPU. Display , Audio, Pico, keypad, touchscreeen etc drivers are available with the release and you should be able get more details from the TI contact person who gave you the blaze. You can also get the performance numbers from same source If you need the full kernel with all the drivers I mentioned above, you can use below git. http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=shortlog;h=refs/heads/L24.4 Regards, Santosh
[PATCH] DSPBRIDGE: Remove GT_TRACE conditional macro
Remove GT_TRACE conditional macro
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/plat-omap/include/dspbridge/dbc.h | 14 --
drivers/dsp/bridge/Makefile|5 -
drivers/dsp/bridge/rmgr/drv.c |2 --
drivers/dsp/bridge/rmgr/drv_interface.c|2 --
4 files changed, 0 insertions(+), 23 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dbc.h
b/arch/arm/plat-omap/include/dspbridge/dbc.h
index c4bf803..4ed8f72 100644
--- a/arch/arm/plat-omap/include/dspbridge/dbc.h
+++ b/arch/arm/plat-omap/include/dspbridge/dbc.h
@@ -25,13 +25,7 @@
#ifndef DBC_
#define DBC_
-#ifndef GT_TRACE
-#define GT_TRACE 0 /* 0 = trace compiled out; 1 = trace active */
-#endif
-
/* Assertion Macros: */
-#if GT_TRACE
-
#define DBC_Assert(exp) \
if (!(exp)) \
pr_err(%s, line %d: Assertion ( #exp ) failed.\n, \
@@ -39,12 +33,4 @@
#define DBC_Require DBC_Assert /* Function Precondition. */
#define DBC_Ensure DBC_Assert /* Function Postcondition. */
-#else
-
-#define DBC_Assert(exp) {}
-#define DBC_Require(exp) {}
-#define DBC_Ensure(exp) {}
-
-#endif /* DEBUG */
-
#endif /* DBC_ */
diff --git a/drivers/dsp/bridge/Makefile b/drivers/dsp/bridge/Makefile
index 11d92cd..11f48cb 100644
--- a/drivers/dsp/bridge/Makefile
+++ b/drivers/dsp/bridge/Makefile
@@ -20,11 +20,6 @@ libhw = hw/hw_prcm.o hw/hw_dspssC64P.o hw/hw_mmu.o
hw/hw_mbox.o
bridgedriver-objs = $(libgen) $(libservices) $(libwmd) $(libpmgr) $(librmgr) \
$(libdload) $(libhw)
-# Debug
-ifeq ($(CONFIG_BRIDGE_DEBUG),y)
-ccflags-y += -DGT_TRACE
-endif
-
#Machine dependent
ccflags-y += -D_TI_ -D_DB_TIOMAP -DTMS32060 \
-DTICFG_PROC_VER -DTICFG_EVM_TYPE -DCHNL_SMCLASS \
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index ecd5905..47ca742 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -513,9 +513,7 @@ DSP_STATUS DRV_GetDevObject(u32 uIndex, struct DRV_OBJECT
*hDrvObject,
struct DEV_OBJECT **phDevObject)
{
DSP_STATUS status = DSP_SOK;
-#if GT_TRACE /* pDrvObject is used only for Assertions and debug messages.*/
struct DRV_OBJECT *pDrvObject = (struct DRV_OBJECT *)hDrvObject;
-#endif
struct DEV_OBJECT *pDevObject;
u32 i;
DBC_Require(MEM_IsValidHandle(pDrvObject, SIGNATURE));
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 3d3f02d..fa97caa 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -533,9 +533,7 @@ err:
/* This function maps kernel space memory to user space memory. */
static int bridge_mmap(struct file *filp, struct vm_area_struct *vma)
{
-#if GT_TRACE
u32 offset = vma-vm_pgoff PAGE_SHIFT;
-#endif
u32 status;
DBC_Assert(vma-vm_start vma-vm_end);
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] [PM-WIP-OPP]: Fixing wrong target level being passed during Core DVFS.
As per the current implementaion (u8*)target_level is being passed to freq_to_opp in set_opp. This would result in updating just the first 8 bits of a u32 variable. Later target_level is passed to resource_set_opp_level as a u32 parameter. This maens a. Initially target_level was 0xabcdefgh. b. freq_to_opp updates the lower eight bits of target_level to 0xXX. Now target_level = 0xabcdefXX. c. We pass 0xabcdefXX as target_level to resource_set_opp_level when we want to pass just 0xXX. This is leading to some corrupted bookkeeping later on in the dvfs path. This patch ensures that target_level passed to resource_set_opp_level is actually the level that is intended by freq_to_opp API. Signed-off-by: Thara Gopinath th...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/resource34xx.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-omap2/resource34xx.c index 3604a38..2c850a2 100644 --- a/arch/arm/mach-omap2/resource34xx.c +++ b/arch/arm/mach-omap2/resource34xx.c @@ -478,6 +478,7 @@ int set_opp(struct shared_resource *resp, u32 target_level) /* uh uh.. no OPPs?? */ BUG_ON(IS_ERR(oppx)); + target_level = 0; ret = freq_to_opp((u8 *)target_level, OPP_L3, req_l3_freq); /* we dont expect this to fail */ BUG_ON(ret); -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH] DSPBRIDGE: Remove GT_TRACE conditional macro
Please discard previous patch, I think it is best to place
DBC* under CONFIG_BRIDGE_DEBUG instead of printing by default.
---
Remove GT_TRACE conditional macro, replace in needed places
for CONFIG_BRIDGE_DEBUG
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/plat-omap/include/dspbridge/dbc.h |6 +-
drivers/dsp/bridge/Makefile|5 -
drivers/dsp/bridge/rmgr/drv.c |2 +-
drivers/dsp/bridge/rmgr/drv_interface.c|2 --
4 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dbc.h
b/arch/arm/plat-omap/include/dspbridge/dbc.h
index c4bf803..90cad03 100644
--- a/arch/arm/plat-omap/include/dspbridge/dbc.h
+++ b/arch/arm/plat-omap/include/dspbridge/dbc.h
@@ -25,12 +25,8 @@
#ifndef DBC_
#define DBC_
-#ifndef GT_TRACE
-#define GT_TRACE 0 /* 0 = trace compiled out; 1 = trace active */
-#endif
-
/* Assertion Macros: */
-#if GT_TRACE
+#ifdef CONFIG_BRIDGE_DEBUG
#define DBC_Assert(exp) \
if (!(exp)) \
diff --git a/drivers/dsp/bridge/Makefile b/drivers/dsp/bridge/Makefile
index 11d92cd..11f48cb 100644
--- a/drivers/dsp/bridge/Makefile
+++ b/drivers/dsp/bridge/Makefile
@@ -20,11 +20,6 @@ libhw = hw/hw_prcm.o hw/hw_dspssC64P.o hw/hw_mmu.o
hw/hw_mbox.o
bridgedriver-objs = $(libgen) $(libservices) $(libwmd) $(libpmgr) $(librmgr) \
$(libdload) $(libhw)
-# Debug
-ifeq ($(CONFIG_BRIDGE_DEBUG),y)
-ccflags-y += -DGT_TRACE
-endif
-
#Machine dependent
ccflags-y += -D_TI_ -D_DB_TIOMAP -DTMS32060 \
-DTICFG_PROC_VER -DTICFG_EVM_TYPE -DCHNL_SMCLASS \
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index ecd5905..a2737fd 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -513,7 +513,7 @@ DSP_STATUS DRV_GetDevObject(u32 uIndex, struct DRV_OBJECT
*hDrvObject,
struct DEV_OBJECT **phDevObject)
{
DSP_STATUS status = DSP_SOK;
-#if GT_TRACE /* pDrvObject is used only for Assertions and debug messages.*/
+#ifdef CONFIG_BRIDGE_DEBUG /* used only for Assertions and debug
messages.*/
struct DRV_OBJECT *pDrvObject = (struct DRV_OBJECT *)hDrvObject;
#endif
struct DEV_OBJECT *pDevObject;
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 3d3f02d..fa97caa 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -533,9 +533,7 @@ err:
/* This function maps kernel space memory to user space memory. */
static int bridge_mmap(struct file *filp, struct vm_area_struct *vma)
{
-#if GT_TRACE
u32 offset = vma-vm_pgoff PAGE_SHIFT;
-#endif
u32 status;
DBC_Assert(vma-vm_start vma-vm_end);
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: HWMOD: Adding clockdomain check.
This patch adds check for presence of clockdomain structure in the API omap_hwmod_get_pwrdm before trying to access the powerdomain structure. This will prevent unnecessary crashing of the system in case of a clock node with out an associated clockdomian. Signed-off-by: Thara Gopinath th...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/omap_hwmod.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 70912d1..97fd635 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -1440,6 +1440,8 @@ struct powerdomain *omap_hwmod_get_pwrdm(struct omap_hwmod *oh) c = oh-slaves[oh-_mpu_port_index]-_clk; } + if (!c-clkdm) + return NULL; return c-clkdm-pwrdm.ptr; } -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Custom debug cleanup
On 2/16/2010 2:42 AM, Ramirez Luna, Omar wrote: Step 1 to remove custom debug tracing Omar Ramirez Luna (18): DSPBRIDGE: Remove entry point custom debug statements for rmgr DSPBRIDGE: Remove entry point custom debug statements for wmd DSPBRIDGE: Remove entry point custom debug statements for pmgr DSPBRIDGE: Remove entry point custom debug statements for wmd DSPBRIDGE: Remove debug statements for success in rmgr DSPBRIDGE: Remove debug statements for success in wmd DSPBRIDGE: Remove debug statements for success in pmgr DSPBRIDGE: Remove debug statements for success in services DSPBRIDGE: Remove excessive debug statements for rmgr DSPBRIDGE: Remove excessive debug statements for wmd DSPBRIDGE: Remove excessive debug statements for pmgr DSPBRIDGE: Remove excessive debug statements for services DSPBRIDGE: change init statements to pr_info in rmgr DSPBRIDGE: change critical error statements to pr_err in rmgr DSPBRIDGE: change critical error statements to pr_err in wmd DSPBRIDGE: print dsp trace buffer by default DSPBRIDGE: change critical error statements to pr_err in pmgr DSPBRIDGE: change critical error statements to pr_err in services drivers/dsp/bridge/pmgr/chnl.c | 43 +--- drivers/dsp/bridge/pmgr/cmm.c | 87 +-- drivers/dsp/bridge/pmgr/cod.c | 107 ++--- drivers/dsp/bridge/pmgr/dbll.c | 59 + drivers/dsp/bridge/pmgr/dev.c | 238 ++ drivers/dsp/bridge/pmgr/dmm.c | 54 + drivers/dsp/bridge/pmgr/io.c| 34 +--- drivers/dsp/bridge/pmgr/msg.c | 15 +- drivers/dsp/bridge/pmgr/wcd.c | 139 +-- drivers/dsp/bridge/rmgr/dbdcd.c | 122 +- drivers/dsp/bridge/rmgr/disp.c | 143 +-- drivers/dsp/bridge/rmgr/drv.c | 166 +++--- drivers/dsp/bridge/rmgr/drv_interface.c | 62 ++ drivers/dsp/bridge/rmgr/dspdrv.c| 22 +-- drivers/dsp/bridge/rmgr/mgr.c | 75 +- drivers/dsp/bridge/rmgr/nldr.c | 57 + drivers/dsp/bridge/rmgr/node.c | 295 +-- drivers/dsp/bridge/rmgr/proc.c | 407 --- drivers/dsp/bridge/rmgr/rmm.c | 35 +--- drivers/dsp/bridge/rmgr/strm.c | 84 +-- drivers/dsp/bridge/services/cfg.c | 134 ++ drivers/dsp/bridge/services/clk.c | 49 +--- drivers/dsp/bridge/services/dbg.c |4 +- drivers/dsp/bridge/services/mem.c | 51 + drivers/dsp/bridge/services/ntfy.c |4 +- drivers/dsp/bridge/services/reg.c | 10 - drivers/dsp/bridge/services/services.c |3 - drivers/dsp/bridge/services/sync.c | 151 ++-- drivers/dsp/bridge/wmd/chnl_sm.c| 37 +--- drivers/dsp/bridge/wmd/io_sm.c | 130 ++- drivers/dsp/bridge/wmd/mmu_fault.c |9 - drivers/dsp/bridge/wmd/tiomap3430.c | 208 +++- drivers/dsp/bridge/wmd/tiomap3430_pwr.c | 70 +- drivers/dsp/bridge/wmd/tiomap_io.c | 58 + drivers/dsp/bridge/wmd/tiomap_sm.c |6 - drivers/dsp/bridge/wmd/ue_deh.c | 29 +-- 36 files changed, 418 insertions(+), 2779 deletions(-) Rebased and pushed to dspbridge - 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 00/12] Custom debug removal
On 2/18/2010 3:37 PM, Ramirez Luna, Omar wrote: Step 2 to remove custom debug tracing. This set of patches gets rid of GT_* and DBG_* functionality, and replaces them to use dev_dbg instead. This is meant to be a follow up of previous debug removal patches. More info on dynamic_debug: http://lwn.net/Articles/286191/ Omar Ramirez Luna (12): DSPBRIDGE: global bridge device DSPBRIDGE: Change custom GT_trace for dev_dbg DSPBRIDGE: Change custom GT_trace for dev_dbg in wmd DSPBRIDGE: Change custom GT_trace for dev_dbg in pmgr DSPBRIDGE: Change custom GT_trace for dev_dbg in services DSPBRIDGE: Remove GT_trace variables for rmgr DSPBRIDGE: Remove GT_trace variables for wmd DSPBRIDGE: Remove GT_trace variables for pmgr DSPBRIDGE: Remove GT_trace variables for services DSPBRIDGE: Remove custom debugging implementation DSPBRIDGE: Remove debug header files DSPBRIDGE: Remove unused instances of CONFIG_BRIDGE_DEBUG arch/arm/plat-omap/include/dspbridge/dbc.h |2 - arch/arm/plat-omap/include/dspbridge/dbg.h | 89 --- arch/arm/plat-omap/include/dspbridge/gt.h | 308 -- arch/arm/plat-omap/include/dspbridge/host_os.h |1 + drivers/dsp/bridge/Makefile|4 +- drivers/dsp/bridge/gen/_gt_para.c | 95 --- drivers/dsp/bridge/gen/gt.c| 336 drivers/dsp/bridge/pmgr/chnl.c | 11 - drivers/dsp/bridge/pmgr/cmm.c | 19 +- drivers/dsp/bridge/pmgr/cod.c | 15 +- drivers/dsp/bridge/pmgr/dbll.c | 75 ++ drivers/dsp/bridge/pmgr/dev.c |8 - drivers/dsp/bridge/pmgr/dmm.c | 58 ++--- drivers/dsp/bridge/pmgr/io.c | 10 - drivers/dsp/bridge/pmgr/msg.c | 13 +- drivers/dsp/bridge/pmgr/wcd.c |7 - drivers/dsp/bridge/rmgr/dbdcd.c| 32 +-- drivers/dsp/bridge/rmgr/disp.c | 69 ++ drivers/dsp/bridge/rmgr/drv.c | 96 +++ drivers/dsp/bridge/rmgr/drv_interface.c| 55 ++--- drivers/dsp/bridge/rmgr/dspdrv.c | 14 +- drivers/dsp/bridge/rmgr/mgr.c | 31 +-- drivers/dsp/bridge/rmgr/nldr.c | 43 +--- drivers/dsp/bridge/rmgr/node.c | 118 +++-- drivers/dsp/bridge/rmgr/proc.c | 94 ++- drivers/dsp/bridge/rmgr/rmm.c | 11 - drivers/dsp/bridge/rmgr/strm.c | 45 ++-- drivers/dsp/bridge/services/cfg.c | 23 +-- drivers/dsp/bridge/services/clk.c | 12 +- drivers/dsp/bridge/services/dbg.c | 88 -- drivers/dsp/bridge/services/mem.c |6 - drivers/dsp/bridge/services/ntfy.c |8 - drivers/dsp/bridge/services/reg.c |7 - drivers/dsp/bridge/services/regsup.c | 26 +-- drivers/dsp/bridge/services/services.c | 21 +-- drivers/dsp/bridge/services/sync.c |8 - drivers/dsp/bridge/wmd/chnl_sm.c |5 +- drivers/dsp/bridge/wmd/io_sm.c | 119 - drivers/dsp/bridge/wmd/mmu_fault.c | 10 +- drivers/dsp/bridge/wmd/tiomap3430.c| 134 +-- drivers/dsp/bridge/wmd/tiomap3430_pwr.c| 64 ++ drivers/dsp/bridge/wmd/tiomap_io.c |1 - drivers/dsp/bridge/wmd/tiomap_sm.c |6 +- drivers/dsp/bridge/wmd/ue_deh.c|6 +- 44 files changed, 406 insertions(+), 1797 deletions(-) delete mode 100644 arch/arm/plat-omap/include/dspbridge/dbg.h delete mode 100644 arch/arm/plat-omap/include/dspbridge/gt.h delete mode 100644 drivers/dsp/bridge/gen/_gt_para.c delete mode 100644 drivers/dsp/bridge/gen/gt.c delete mode 100644 drivers/dsp/bridge/services/dbg.c create mode 100644 drivers/dsp/bridge/uTimeout removed bogus file: create mode 100644 drivers/dsp/bridge/uTimeout from patch [02/12] DSPBRIDGE: Change custom GT_trace for dev_dbg Included as part of the set: DSPBRIDGE: Remove GT_TRACE conditional macro http://marc.info/?l=linux-omapm=126694528710256w=2 Rebased and pushed to dspbridge - 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: [PM-WIP-OPP] [PATCH 0/2] cleanups for pointer handling
Nishanth Menon n...@ti.com writes: Few pointer handling related cleanup patches Nishanth Menon (2): omap3:pm:srf: check if pointer results with IS_ERR omap:pm: return error pointers if inactive opp layer arch/arm/mach-omap2/resource34xx.c|2 +- arch/arm/plat-omap/include/plat/opp.h | 12 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) Cc: Ambresh K ambr...@ti.com Cc: Eduardo Valentin eduardo.valen...@nokia.com Cc: Kevin Hilman khil...@deeprootsystems.com Thanks, applying to pm-wip-opp. 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: HWMOD: Bug fixes in hwmod structure definitions
On Tue, 23 Feb 2010, Gopinath, Thara wrote:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Friday, February 19, 2010 2:20 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP: HWMOD: Bug fixes in hwmod structure definitions
Hello Thara,
some comments.
On Thu, 18 Feb 2010, Thara Gopinath wrote:
This patch corrects the width of some variables in hwmod structures
where the values to be stored in these variables exceed the current
field width.
Signed-off-by: Thara Gopinath th...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/plat-omap/include/plat/omap_hwmod.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-
omap/include/plat/omap_hwmod.h
index 921990e..06a7f20 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -258,7 +258,7 @@ struct omap_hwmod_sysconfig {
u16 sysc_offs;
u16 syss_offs;
u8 idlemodes;
- u8 sysc_flags;
+ u16 sysc_flags;
This part is fine.
u8 clockact;
};
@@ -280,9 +280,9 @@ struct omap_hwmod_sysconfig {
struct omap_hwmod_omap2_prcm {
s16 module_offs;
u8 prcm_reg_id;
- u8 module_bit;
+ u32 module_bit;
u8 idlest_reg_id;
- u8 idlest_idle_bit;
+ u32 idlest_idle_bit;
u8 idlest_stdby_bit;
};
This part I don't understand. These are bit shifts in a 32 bit register,
e.g., (1 idlest_idle_bit), so how could these ever exceed 31?
Hi Paul,
Oh... ok. I was under the impression these bits are to be assigned the value
1 shift.. My bad.. Do you want me to re sumbmit the patch with just the
first fix.
Yes.
_ 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] [PM-WIP-OPP]: Fixing wrong target level being passed during Core DVFS.
Thara Gopinath th...@ti.com writes: As per the current implementaion (u8*)target_level is being passed to freq_to_opp in set_opp. This would result in updating just the first 8 bits of a u32 variable. Later target_level is passed to resource_set_opp_level as a u32 parameter. This maens a. Initially target_level was 0xabcdefgh. b. freq_to_opp updates the lower eight bits of target_level to 0xXX. Now target_level = 0xabcdefXX. c. We pass 0xabcdefXX as target_level to resource_set_opp_level when we want to pass just 0xXX. This is leading to some corrupted bookkeeping later on in the dvfs path. This patch ensures that target_level passed to resource_set_opp_level is actually the level that is intended by freq_to_opp API. Signed-off-by: Thara Gopinath th...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Thanks, applying to pm-wip-opp after cleaning up the formatting in the changelog to be a little more readable. Kevin --- arch/arm/mach-omap2/resource34xx.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-omap2/resource34xx.c index 3604a38..2c850a2 100644 --- a/arch/arm/mach-omap2/resource34xx.c +++ b/arch/arm/mach-omap2/resource34xx.c @@ -478,6 +478,7 @@ int set_opp(struct shared_resource *resp, u32 target_level) /* uh uh.. no OPPs?? */ BUG_ON(IS_ERR(oppx)); + target_level = 0; ret = freq_to_opp((u8 *)target_level, OPP_L3, req_l3_freq); /* we dont expect this to fail */ BUG_ON(ret); -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe 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/6] OMAP2: hwmod: Fix MMC hwmod structs for 2430
Rajendra Nayak rna...@ti.com writes:
The existing MMC hwmod structs for 2430 are fixed based
on the changes in hwmod framework structurs.
Signed-off-by: Rajendra Nayak rna...@ti.com
Thanks, I'll fold this into the MMC hwmods in the pm-wip/hwmods branch.
Kevin
---
arch/arm/mach-omap2/omap_hwmod_2430.h | 26 +++---
1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430.h
b/arch/arm/mach-omap2/omap_hwmod_2430.h
index 0b6ca6f..2898749 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430.h
+++ b/arch/arm/mach-omap2/omap_hwmod_2430.h
@@ -21,7 +21,7 @@
#include plat/cpu.h
#include plat/dma.h
-#include mach/mmc.h
+#include plat/mmc.h
#include cm-regbits-24xx.h
#include prm-regbits-24xx.h
@@ -87,7 +87,8 @@ static struct omap_hwmod_addr_space
omap2430_mmc1_addr_space[] = {
static struct omap_hwmod_ocp_if omap2430_l4_core__mmc1 = {
.master = omap2430_l4_core_hwmod,
.slave = omap2430_mmc1_hwmod,
- .interface_clk = { .name = mmchs1_ick },
+ .clkdev_dev_id = mmci-omap-hs.0,
+ .clkdev_con_id = ick,
.addr = omap2430_mmc1_addr_space,
.addr_cnt = ARRAY_SIZE(omap2430_mmc1_addr_space),
.user = OCP_USER_MPU | OCP_USER_SDMA,
@@ -105,7 +106,8 @@ static struct omap_hwmod_addr_space
omap2430_mmc2_addr_space[] = {
static struct omap_hwmod_ocp_if omap2430_l4_core__mmc2 = {
.master = omap2430_l4_core_hwmod,
.slave = omap2430_mmc2_hwmod,
- .interface_clk = { .name = mmchs2_ick },
+ .clkdev_dev_id = mmci-omap-hs.1,
+ .clkdev_con_id = ick,
.addr = omap2430_mmc2_addr_space,
.addr_cnt = ARRAY_SIZE(omap2430_mmc2_addr_space),
.user = OCP_USER_MPU | OCP_USER_SDMA,
@@ -185,8 +187,8 @@ static struct mmc_dev_attr mmc1_dev_attr = {
.flags = MMC_INTERNAL_XCVR,
};
-static u8 mmc1_mpu_irqs[] = {
- INT_24XX_MMC_IRQ,
+static struct omap_hwmod_irq_info mmc1_mpu_irqs[] = {
+ { .irq = INT_24XX_MMC_IRQ, },
};
static struct omap_hwmod_dma_info mmc1_sdma_chs[] = {
@@ -195,7 +197,7 @@ static struct omap_hwmod_dma_info mmc1_sdma_chs[] = {
};
static struct omap_hwmod_opt_clk mmc1_opt_clks[] = {
- { .role = dbck, .clk = { .name = mmchsdb1_fck } },
+ { .clkdev_dev_id = mmci-omap-hs.0, .clkdev_con_id = mmchsdb_fck },
};
static struct omap_hwmod_ocp_if *omap2430_mmc1_slaves[] = {
@@ -210,7 +212,8 @@ static struct omap_hwmod omap2430_mmc1_hwmod = {
.sdma_chs_cnt = ARRAY_SIZE(mmc1_sdma_chs),
.opt_clks = mmc1_opt_clks,
.opt_clks_cnt = ARRAY_SIZE(mmc1_opt_clks),
- .main_clk = { .name = mmchs1_fck },
+ .clkdev_dev_id = mmci-omap-hs.0,
+ .clkdev_con_id = fck,
.prcm = {
.omap2 = {
.prcm_reg_id = 2,
@@ -230,8 +233,8 @@ static struct mmc_dev_attr mmc2_dev_attr = {
.flags = MMC_SUPPORTS_EXTERNAL_XCVR,
};
-static u8 mmc2_mpu_irqs[] = {
- INT_24XX_MMC2_IRQ,
+static struct omap_hwmod_irq_info mmc2_mpu_irqs[] = {
+ { .irq = INT_24XX_MMC2_IRQ, },
};
static struct omap_hwmod_dma_info mmc2_sdma_chs[] = {
@@ -240,7 +243,7 @@ static struct omap_hwmod_dma_info mmc2_sdma_chs[] = {
};
static struct omap_hwmod_opt_clk mmc2_opt_clks[] = {
- { .role = dbck, .clk = { .name = mmchsdb2_fck } },
+ { .clkdev_dev_id = mmci-omap-hs.1, .clkdev_con_id = mmchsdb_fck },
};
static struct omap_hwmod_ocp_if *omap2430_mmc2_slaves[] = {
@@ -255,7 +258,8 @@ static struct omap_hwmod omap2430_mmc2_hwmod = {
.sdma_chs_cnt = ARRAY_SIZE(mmc2_sdma_chs),
.opt_clks = mmc2_opt_clks,
.opt_clks_cnt = ARRAY_SIZE(mmc2_opt_clks),
- .main_clk = { .name = mmchs2_fck },
+ .clkdev_dev_id = mmci-omap-hs.1,
+ .clkdev_con_id = fck,
.prcm = {
.omap2 = {
.prcm_reg_id = 2,
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe 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 10/11] omap: musb: get rid of dyn_fifo
* Gadiyar, Anand gadi...@ti.com [100223 07:18]: I think this patch breaks musb_hdrc. In musb_core_init is musb-config-dyn_fifo checked but is never set. So I get the following dmesg output: musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb_hdrc: MHDRC RTL version 1.400 musb_core_init 1405: reconfigure software for Dynamic FIFOs musb_hdrc musb_hdrc: musb_init_controller failed with status -19 Thomas I think I have the same problem. There are other problems right now (I'm trying several different branch/defconfig combinations) so I can't be 100% sure. Ajay reported earlier today [1] that there is a dependency patch [2] that needs to be taken in. Looks like it was missed when the MUSB patchset was added to linux-omap for extra testing. - Anand [1] http://marc.info/?l=linux-omapm=126691578831301w=2 [2] http://marc.info/?l=linux-omapm=126088393130177w=2 Thanks, I'll drop this patch. Sounds like Felipe is back from vacation and can then merge it via linux-usb along with the other patch. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] OMAP: I2C: Convert i2c driver to use omap_device/omap_hwmod
Rajendra Nayak rna...@ti.com writes:
This patch converts the i2c driver to use omap_device/omap_hwmod.
Signed-off-by: Rajendra Nayak rna...@ti.com
Hi Rajendra,
Rather than using omap_device functions via platform_data pointers,
can you try to do this using runtime PM? You can use my
pm-wip/runtime branch (based on top of my pm-wip/hwmods branch.) I
also have a pm-wip/mmc branch on top of the runtime branch that does
this for the MMC if you'd like to compare.
Basically, this patch will be the same, except for instead of
if (pdata-device_enable)
pdata-device_enable(pdev);
you do
pm_runtime_get_sync(dev)
and instead of
if (pdata-device_enable)
pdata-device_enable(pdev);
you do
pm_runtime_put_sync(dev)
under the hood, the runtime PM core will do reference counting and
then call OMAP device when needed.
Kevin
---
drivers/i2c/busses/i2c-omap.c | 81
-
1 files changed, 32 insertions(+), 49 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0037e31..520ac5a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -38,6 +42,8 @@
#include linux/clk.h
#include linux/io.h
+#include plat/i2c.h
+
/* I2C controller revisions */
#define OMAP_I2C_REV_2 0x20
@@ -161,8 +167,6 @@ struct omap_i2c_dev {
struct device *dev;
void __iomem*base; /* virtual */
int irq;
- struct clk *iclk; /* Interface clock */
- struct clk *fclk; /* Functional clock */
struct completion cmd_complete;
struct resource *ioarea;
u32 speed; /* Speed of bus in Khz */
@@ -197,45 +201,19 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
return __raw_readw(i2c_dev-base + reg);
}
-static int __init omap_i2c_get_clocks(struct omap_i2c_dev *dev)
+static void omap_i2c_unidle(struct omap_i2c_dev *dev)
{
- int ret;
-
- dev-iclk = clk_get(dev-dev, ick);
- if (IS_ERR(dev-iclk)) {
- ret = PTR_ERR(dev-iclk);
- dev-iclk = NULL;
- return ret;
- }
+ struct platform_device *pdev;
+ struct omap_i2c_platform_data *pdata;
- dev-fclk = clk_get(dev-dev, fck);
- if (IS_ERR(dev-fclk)) {
- ret = PTR_ERR(dev-fclk);
- if (dev-iclk != NULL) {
- clk_put(dev-iclk);
- dev-iclk = NULL;
- }
- dev-fclk = NULL;
- return ret;
- }
-
- return 0;
-}
+ WARN_ON(!dev-idle);
-static void omap_i2c_put_clocks(struct omap_i2c_dev *dev)
-{
- clk_put(dev-fclk);
- dev-fclk = NULL;
- clk_put(dev-iclk);
- dev-iclk = NULL;
-}
+ pdev = container_of(dev-dev, struct platform_device, dev);
+ pdata = pdev-dev.platform_data;
-static void omap_i2c_unidle(struct omap_i2c_dev *dev)
-{
- WARN_ON(!dev-idle);
+ if (pdata-device_enable)
+ pdata-device_enable(pdev);
- clk_enable(dev-iclk);
- clk_enable(dev-fclk);
if (cpu_is_omap34xx()) {
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
@@ -258,10 +236,15 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
static void omap_i2c_idle(struct omap_i2c_dev *dev)
{
+ struct platform_device *pdev;
+ struct omap_i2c_platform_data *pdata;
u16 iv;
WARN_ON(dev-idle);
+ pdev = container_of(dev-dev, struct platform_device, dev);
+ pdata = pdev-dev.platform_data;
+
dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
if (dev-rev OMAP_I2C_REV_2) {
@@ -273,8 +256,8 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
}
dev-idle = 1;
- clk_disable(dev-fclk);
- clk_disable(dev-iclk);
+ if (pdata-device_idle)
+ pdata-device_idle(pdev);
}
static int omap_i2c_init(struct omap_i2c_dev *dev)
@@ -284,6 +267,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
unsigned long fclk_rate = 1200;
unsigned long timeout;
unsigned long internal_clk = 0;
+ struct clk *fclk;
if (dev-rev = OMAP_I2C_REV_2) {
/* Disable I2C controller before soft reset */
@@ -340,7 +324,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* always returns 12MHz for the functional clock, we can
* do this bit unconditionally.
*/
- fclk_rate = clk_get_rate(dev-fclk);
+ fclk = clk_get(dev-dev, fck);
+
Re: [PATCH] musb: fix power field to hold all possible values
Hi, On Tue, Feb 23, 2010 at 08:01:50PM +0530, Gupta, Ajay Kumar wrote: Board files are providing the actual mA and it is getting divided in Arch/arm/mach-omap2/usb-musb.c. See the code snippet below, musb_plat.clock = ick; musb_plat.board_data = board_data; -- musb_plat.power = board_data-power 1; musb_plat.mode = board_data-mode; So we need to either take this patch or fix this logic of dividing the mA supplied from all omap board files. that's true, had missed that. Sorry. -- balbi -- To unsubscribe from this list: send the line unsubscribe 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] OMAPFB: install omapfb.h
From: Ville Syrjälä ville.syrj...@nokia.com omapfb has several custom ioctls so user space needs the header in order to utilize them. Signed-off-by: Ville Syrjälä ville.syrj...@nokia.com --- include/linux/Kbuild |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/Kbuild b/include/linux/Kbuild index 1feed71..505ff9e 100644 --- a/include/linux/Kbuild +++ b/include/linux/Kbuild @@ -124,6 +124,7 @@ header-y += nfs2.h header-y += nfs4_mount.h header-y += nfs_mount.h header-y += nl80211.h +header-y += omapfb.h header-y += param.h header-y += pci_regs.h header-y += perf_event.h -- 1.6.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] DSS2: OMAPFB: Constify some function parameters
From: Ville Syrjälä ville.syrj...@nokia.com
Signed-off-by: Ville Syrjälä ville.syrj...@nokia.com
---
drivers/video/omap2/omapfb/omapfb-main.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index d17caef..d1f02ae 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -152,9 +152,9 @@ static void fill_fb(struct fb_info *fbi)
}
#endif
-static unsigned omapfb_get_vrfb_offset(struct omapfb_info *ofbi, int rot)
+static unsigned omapfb_get_vrfb_offset(const struct omapfb_info *ofbi, int rot)
{
- struct vrfb *vrfb = ofbi-region.vrfb;
+ const struct vrfb *vrfb = ofbi-region.vrfb;
unsigned offset;
switch (rot) {
@@ -179,7 +179,7 @@ static unsigned omapfb_get_vrfb_offset(struct omapfb_info
*ofbi, int rot)
return offset;
}
-static u32 omapfb_get_region_rot_paddr(struct omapfb_info *ofbi, int rot)
+static u32 omapfb_get_region_rot_paddr(const struct omapfb_info *ofbi, int rot)
{
if (ofbi-rotation_type == OMAP_DSS_ROT_VRFB) {
return ofbi-region.vrfb.paddr[rot]
@@ -189,7 +189,7 @@ static u32 omapfb_get_region_rot_paddr(struct omapfb_info
*ofbi, int rot)
}
}
-static u32 omapfb_get_region_paddr(struct omapfb_info *ofbi)
+static u32 omapfb_get_region_paddr(const struct omapfb_info *ofbi)
{
if (ofbi-rotation_type == OMAP_DSS_ROT_VRFB)
return ofbi-region.vrfb.paddr[0];
@@ -197,7 +197,7 @@ static u32 omapfb_get_region_paddr(struct omapfb_info *ofbi)
return ofbi-region.paddr;
}
-static void __iomem *omapfb_get_region_vaddr(struct omapfb_info *ofbi)
+static void __iomem *omapfb_get_region_vaddr(const struct omapfb_info *ofbi)
{
if (ofbi-rotation_type == OMAP_DSS_ROT_VRFB)
return ofbi-region.vrfb.vaddr[0];
@@ -778,8 +778,8 @@ static int omapfb_release(struct fb_info *fbi, int user)
return 0;
}
-static unsigned calc_rotation_offset_dma(struct fb_var_screeninfo *var,
- struct fb_fix_screeninfo *fix, int rotation)
+static unsigned calc_rotation_offset_dma(const struct fb_var_screeninfo *var,
+ const struct fb_fix_screeninfo *fix, int rotation)
{
unsigned offset;
@@ -789,8 +789,8 @@ static unsigned calc_rotation_offset_dma(struct
fb_var_screeninfo *var,
return offset;
}
-static unsigned calc_rotation_offset_vrfb(struct fb_var_screeninfo *var,
- struct fb_fix_screeninfo *fix, int rotation)
+static unsigned calc_rotation_offset_vrfb(const struct fb_var_screeninfo *var,
+ const struct fb_fix_screeninfo *fix, int rotation)
{
unsigned offset;
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] DSS2: OMAPFB: Add support for switching memory regions
From: Ville Syrjälä ville.syrj...@nokia.com
Separate the memory region from the framebuffer device a little bit.
It's now possible to select the memory region used by the framebuffer
device using the new source_idx parameter of omapfb_plane_info. If the
source_idx is specified it will be interpreted as an index into the
memory regions array, if it's not specified the framebuffer's index is
used instead. So by default each framebuffer keeps using it's own
memory region which preserves backwards compatibility.
This allows cloning the same memory region to several overlays and yet
each overlay can be controlled independently since they can be
associated with separate framebuffer devices.
Signed-off-by: Ville Syrjälä ville.syrj...@nokia.com
---
drivers/video/omap2/omapfb/omapfb-ioctl.c | 156 +++-
drivers/video/omap2/omapfb/omapfb-main.c | 185 +++--
drivers/video/omap2/omapfb/omapfb-sysfs.c | 47 +--
drivers/video/omap2/omapfb/omapfb.h | 47 +++-
include/linux/omapfb.h|5 +-
5 files changed, 326 insertions(+), 114 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 4c4bafd..14f8d6b 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -34,12 +34,37 @@
#include omapfb.h
+static u8 get_source_idx(struct omapfb_info *ofbi)
+{
+ if (ofbi-id == ofbi-region-id)
+ return 0;
+
+ return OMAPFB_SOURCE_IDX_ENABLED | ofbi-region-id;
+}
+
+static struct omapfb2_mem_region *get_mem_region(struct omapfb_info *ofbi,
+u8 source_idx)
+{
+ struct omapfb2_device *fbdev = ofbi-fbdev;
+
+ if (source_idx OMAPFB_SOURCE_IDX_ENABLED)
+ source_idx = OMAPFB_SOURCE_IDX_MASK;
+ else
+ source_idx = ofbi-id;
+
+ if (source_idx fbdev-num_fbs)
+ return NULL;
+
+ return omapfb_get_mem_region(fbdev-regions[source_idx]);
+}
+
static int omapfb_setup_plane(struct fb_info *fbi, struct omapfb_plane_info
*pi)
{
struct omapfb_info *ofbi = FB2OFB(fbi);
struct omapfb2_device *fbdev = ofbi-fbdev;
struct omap_overlay *ovl;
- struct omap_overlay_info info;
+ struct omap_overlay_info old_info;
+ struct omapfb2_mem_region *old_rg, *new_rg;
int r = 0;
DBG(omapfb_setup_plane\n);
@@ -52,57 +77,110 @@ static int omapfb_setup_plane(struct fb_info *fbi, struct
omapfb_plane_info *pi)
/* XXX uses only the first overlay */
ovl = ofbi-overlays[0];
- if (pi-enabled !ofbi-region.size) {
+ old_rg = omapfb_get_mem_region(ofbi-region);
+ new_rg = get_mem_region(ofbi, pi-source_idx);
+ if (!new_rg) {
+ r = -EINVAL;
+ goto out;
+ }
+
+ if (pi-enabled !new_rg-size) {
/*
* This plane's memory was freed, can't enable it
* until it's reallocated.
*/
r = -EINVAL;
- goto out;
+ goto put_regions;
}
- ovl-get_overlay_info(ovl, info);
+ ovl-get_overlay_info(ovl, old_info);
- info.pos_x = pi-pos_x;
- info.pos_y = pi-pos_y;
- info.out_width = pi-out_width;
- info.out_height = pi-out_height;
- info.enabled = pi-enabled;
+ if (old_rg != new_rg) {
+ ofbi-region = new_rg;
+ set_fb_fix(fbi);
+ }
- r = ovl-set_overlay_info(ovl, info);
- if (r)
- goto out;
+ if (pi-enabled) {
+ struct omap_overlay_info info;
- if (ovl-manager) {
- r = ovl-manager-apply(ovl-manager);
+ r = omapfb_setup_overlay(fbi, ovl, pi-pos_x, pi-pos_y,
+ pi-out_width, pi-out_height);
if (r)
- goto out;
+ goto undo;
+
+ ovl-get_overlay_info(ovl, info);
+
+ if (!info.enabled) {
+ info.enabled = pi-enabled;
+ r = ovl-set_overlay_info(ovl, info);
+ if (r)
+ goto undo;
+ atomic_inc(new_rg-use_count);
+ } else {
+ atomic_inc(new_rg-use_count);
+ atomic_dec(old_rg-use_count);
+ }
+ } else {
+ struct omap_overlay_info info;
+ bool enabled;
+
+ ovl-get_overlay_info(ovl, info);
+
+ enabled = info.enabled;
+
+ info.enabled = pi-enabled;
+ info.pos_x = pi-pos_x;
+ info.pos_y = pi-pos_y;
+ info.out_width = pi-out_width;
+ info.out_height = pi-out_height;
+
+ r = ovl-set_overlay_info(ovl, info);
+
Re: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
* Shilimkar, Santosh santosh.shilim...@ti.com [100222 23:16]:
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Tuesday, February 23, 2010 4:37 AM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Woodruff, Richard; Ghorai,
Sukumar
Subject: Re: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
* Tony Lindgren t...@atomide.com [100222 13:35]:
* Shilimkar, Santosh santosh.shilim...@ti.com [100218 21:22]:
Bye the way just to add bit more clarity, this patch addresses TX
hardware restriction in the new UART IP used on omap3630 and omap4430.
First part of the fix for RX is already in mainline,
Commit: ce13d4716a276f4331d78ba28a5093a63822ab95
More details on this thread are here.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19447.html
Thanks, I've updated the comments for this patch with the link above
and added the whole series into omap for-next.
Except patches 8 and 9 as they break compile for mach-omap1
and need to be updated.
Patch 8 is alright and doesn't break omap1. Patch 7 and patch 9 needs update
to fix
the mach-omap1 build issue by moving irqs-44xx.h header file to plat-omap
directory.
Attached are updated 7 and 9.
Build tested for omap1 (omap_generic_1710_defconfig and
omap_h2_1610_defconfig) and boot
tested with omap3_defconfig on omap4430sdp board.
Next time, one patch per email please. And updates as replies
to the original patches, or else the whole series. And patches
as inline attachments.
Otherwise it's hard to keep track of the patches and comment
them.
I've updated your patch 9/9 with the following as in omap for-next
I was getting:
arch/arm/mach-omap2/usb-musb.c:97: Building for omap_3430sdp_defconfigred
(first use in this function)
Building for omap_3630sdp_defconfigch-omap2/usb-musb.c:97: error:
(Each undeclared identifier is reported only once
arch/arm/mach-omap2/usb-musb.c:97: error: for each function it appears in.)
arch/arm/mach-omap2/usb-musb.c:98: error: 'INT_44XX_HS_USB_DMA' undeclared
(first use in this function)
Regards,
Tony
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -94,8 +94,8 @@ void __init usb_musb_init(struct omap_musb_board_data
*board_data)
musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
} else if (cpu_is_omap44xx()) {
musb_resources[0].start = OMAP44XX_HSUSB_OTG_BASE;
- musb_resources[1].start = INT_44XX_HS_USB_MC;
- musb_resources[2].start = INT_44XX_HS_USB_DMA;
+ musb_resources[1].start = OMAP44XX_IRQ_HS_USB_MC_N;
+ musb_resources[2].start = OMAP44XX_IRQ_HS_USB_DMA_N;
}
musb_resources[0].end = musb_resources[0].start + SZ_4K - 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/RFC 4/4] OMAP2/3 MMC: initial conversion to runtime PM
Madhusudhan madhu...@ti.com writes:
snip
err_irq:
mmc_host_disable(host-mmc);
-clk_disable(host-iclk);
+pm_runtime_suspend(host-dev);
Why not pm_runtime_put_sync() here? It can replace the calls:
mmc_host_disable(host-mmc);
clk_disable(host-iclk);
Not knowing a ton about this driver, I'd rather keep the
mmc_host_disable() since it matches the mmc_host_enable() earlier.
clk_put(host-fclk);
clk_put(host-iclk);
+
if (host-got_dbclk) {
clk_disable(host-dbclk);
clk_put(host-dbclk);
@@ -2216,7 +2164,8 @@ static int omap_hsmmc_remove(struct platform_device
*pdev)
flush_scheduled_work();
mmc_host_disable(host-mmc);
-clk_disable(host-iclk);
+pm_runtime_suspend(host-dev);
+
Ditto
clk_put(host-fclk);
clk_put(host-iclk);
if (host-got_dbclk) {
@@ -2272,7 +2221,7 @@ static int omap_hsmmc_suspend(struct device *dev)
OMAP_HSMMC_WRITE(host-base, HCTL,
OMAP_HSMMC_READ(host-base, HCTL) ~SDBP);
mmc_host_disable(host-mmc);
-clk_disable(host-iclk);
+
if (host-got_dbclk)
clk_disable(host-dbclk);
} else {
@@ -2287,6 +2236,11 @@ static int omap_hsmmc_suspend(struct device *dev)
mmc_host_disable(host-mmc);
}
+/*
+ * HACK: extra put to compensate for DPM core keeping
+ * runtime PM disabled. -- khilman
+ */
+pm_runtime_put_sync(host-dev);
}
return ret;
}
@@ -2302,12 +2256,14 @@ static int omap_hsmmc_resume(struct device *dev)
return 0;
if (host) {
-ret = clk_enable(host-iclk);
-if (ret)
-goto clk_en_err;
+/*
+ * HACK: extra get to compensate for DPM core keeping
+ * runtime PM disabled. -- khilman
+ */
+pm_runtime_get_sync(host-dev);
if (mmc_host_enable(host-mmc) != 0) {
-clk_disable(host-iclk);
+pm_runtime_suspend(host-dev);
goto clk_en_err;
}
@@ -2346,9 +2302,37 @@ clk_en_err:
#define omap_hsmmc_resume NULL
#endif
+/* called just before device is disabled */
+static int omap_hsmmc_runtime_suspend(struct device *dev)
+{
+struct omap_hsmmc_host *host;
+
+dev_dbg(dev, %s\n, __func__);
+
+host = platform_get_drvdata(to_platform_device(dev));
+omap_hsmmc_context_save(host);
The context_save fn is now empty. How does it help here?
It doesn't add anything, but I put it there to show that this is the
only place that context save would be needed, and as an example to other
drivers.
Kevin
+
+return 0;
+}
+
+/* called after device is (re)enabled, ONLY if context was lost */
+static int omap_hsmmc_runtime_resume(struct device *dev)
+{
+struct omap_hsmmc_host *host;
+
+dev_dbg(dev, %s\n, __func__);
+
+host = platform_get_drvdata(to_platform_device(dev));
+omap_hsmmc_context_restore(host);
+
+return 0;
+}
+
static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.suspend= omap_hsmmc_suspend,
.resume = omap_hsmmc_resume,
+.runtime_suspend = omap_hsmmc_runtime_suspend,
+.runtime_resume = omap_hsmmc_runtime_resume,
};
static struct platform_driver omap_hsmmc_driver = {
--
1.6.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V1 09/10] VPFE Capture: Add support for USERPTR mode of operation
Vaibhav,
There are changes to vpfe capture on Arago tree on top of this. For
example, vpfe_uservirt_to_phys() is removed and is replaced with
videobuf_iolock(). So please get the latest changes to upstream.
Murali
On Tue, Feb 23, 2010 at 3:34 AM, hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/ti-media/vpfe_capture.c | 94 ++
1 files changed, 79 insertions(+), 15 deletions(-)
diff --git a/drivers/media/video/ti-media/vpfe_capture.c
b/drivers/media/video/ti-media/vpfe_capture.c
index cece265..7d4ab44 100644
--- a/drivers/media/video/ti-media/vpfe_capture.c
+++ b/drivers/media/video/ti-media/vpfe_capture.c
@@ -538,7 +538,24 @@ static void vpfe_schedule_next_buffer(struct vpfe_device
*vpfe_dev)
struct videobuf_buffer, queue);
list_del(vpfe_dev-next_frm-queue);
vpfe_dev-next_frm-state = VIDEOBUF_ACTIVE;
- addr = videobuf_to_dma_contig(vpfe_dev-next_frm);
+ if (V4L2_MEMORY_USERPTR == vpfe_dev-memory)
+ addr = vpfe_dev-cur_frm-boff;
+ else
+ addr = videobuf_to_dma_contig(vpfe_dev-next_frm);
+
+ ccdc_dev-hw_ops.setfbaddr(addr);
+}
+
+static void vpfe_schedule_bottom_field(struct vpfe_device *vpfe_dev)
+{
+ unsigned long addr;
+
+ if (V4L2_MEMORY_USERPTR == vpfe_dev-memory)
+ addr = vpfe_dev-cur_frm-boff;
+ else
+ addr = videobuf_to_dma_contig(vpfe_dev-cur_frm);
+
+ addr += vpfe_dev-field_off;
ccdc_dev-hw_ops.setfbaddr(addr);
}
@@ -559,7 +576,6 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
{
struct vpfe_device *vpfe_dev = dev_id;
enum v4l2_field field;
- unsigned long addr;
int fid;
v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, \nStarting vpfe_isr...\n);
@@ -604,10 +620,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
* the CCDC memory address
*/
if (field == V4L2_FIELD_SEQ_TB) {
- addr =
- videobuf_to_dma_contig(vpfe_dev-cur_frm);
- addr += vpfe_dev-field_off;
- ccdc_dev-hw_ops.setfbaddr(addr);
+ vpfe_schedule_bottom_field(vpfe_dev);
}
goto clear_intr;
}
@@ -1234,7 +1247,10 @@ static int vpfe_videobuf_setup(struct videobuf_queue
*vq,
struct vpfe_device *vpfe_dev = fh-vpfe_dev;
v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_buffer_setup\n);
- *size = config_params.device_bufsize;
+ *size = vpfe_dev-fmt.fmt.pix.sizeimage;
+ if (vpfe_dev-memory == V4L2_MEMORY_MMAP
+ vpfe_dev-fmt.fmt.pix.sizeimage
config_params.device_bufsize)
+ *size = config_params.device_bufsize;
if (*count config_params.min_numbuffers)
*count = config_params.min_numbuffers;
@@ -1243,6 +1259,46 @@ static int vpfe_videobuf_setup(struct videobuf_queue
*vq,
return 0;
}
+/*
+ * vpfe_uservirt_to_phys: This function is used to convert user
+ * space virtual address to physical address.
+ */
+static u32 vpfe_uservirt_to_phys(struct vpfe_device *vpfe_dev, u32 virtp)
+{
+ struct mm_struct *mm = current-mm;
+ unsigned long physp = 0;
+ struct vm_area_struct *vma;
+
+ vma = find_vma(mm, virtp);
+
+ /* For kernel direct-mapped memory, take the easy way */
+ if (virtp = PAGE_OFFSET)
+ physp = virt_to_phys((void *)virtp);
+ else if (vma (vma-vm_flags VM_IO) (vma-vm_pgoff))
+ /* this will catch, kernel-allocated, mmaped-to-usermode addr
*/
+ physp = (vma-vm_pgoff PAGE_SHIFT) + (virtp -
vma-vm_start);
+ else {
+ /* otherwise, use get_user_pages() for general userland pages
*/
+ int res, nr_pages = 1;
+ struct page *pages;
+ down_read(current-mm-mmap_sem);
+
+ res = get_user_pages(current, current-mm,
+ virtp, nr_pages, 1, 0, pages, NULL);
+ up_read(current-mm-mmap_sem);
+
+ if (res == nr_pages)
+ physp = __pa(page_address(pages[0]) +
+ (virtp ~PAGE_MASK));
+ else {
+ v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+ get_user_pages failed\n);
+ return 0;
+ }
+ }
+ return physp;
+}
+
static int vpfe_videobuf_prepare(struct videobuf_queue *vq,
struct videobuf_buffer *vb,
Re: [PATCH 3/9] tvp514x: add YUYV format support
Vaibhav,
On Mon, Jan 4, 2010 at 9:02 AM, hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/tvp514x.c | 7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 4cf3593..b344b58 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
@@ -212,6 +212,13 @@ static const struct v4l2_fmtdesc tvp514x_fmt_list[] = {
.description = 8-bit UYVY 4:2:2 Format,
.pixelformat = V4L2_PIX_FMT_UYVY,
},
+ {
+ .index = 1,
+ .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ .flags = 0,
+ .description = 8-bit YUYV 4:2:2 Format,
+ .pixelformat = V4L2_PIX_FMT_YUYV,
+ },
};
As per data sheet I can see only CbYCrY format output from the tvp5146
which translate to UYVY. How are you configuring tvp to output YUYV? I
don;t see any change to the code to configure this format.
CCDC can switch the CbCr order and also can swap Y/C order. So if you
are achieving
this via ccdc configuration, there is no need to add this format to tvp5146 IMO.
-Murali
/**
--
1.6.2.4
--
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
--
Murali Karicheri
mkarich...@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
[PATCHv4 2/7] ASoC: TWL6030: Add twl6030 codec driver
From: Misael Lopez Cruz x0052...@ti.com
Initial version of TWL6030 codec driver.
The TWL6030 codec uses a propietary PDM-based digital audio interface.
Audio paths supported are:
- Input: Main Mic, Sub Mic, Headset Mic, Auxiliary-FM Left/Right
- Output: Headset Left/Right, Handsfree Left/Right
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com
---
sound/soc/codecs/Kconfig |4 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/twl6030.c | 823
sound/soc/codecs/twl6030.h | 94 +
4 files changed, 923 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/codecs/twl6030.c
create mode 100644 sound/soc/codecs/twl6030.h
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 52b005f..3b3d739 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -33,6 +33,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TPA6130A2 if I2C
select SND_SOC_TLV320DAC33 if I2C
select SND_SOC_TWL4030 if TWL4030_CORE
+ select SND_SOC_TWL6030 if TWL4030_CORE
select SND_SOC_UDA134X
select SND_SOC_UDA1380 if I2C
select SND_SOC_WM8350 if MFD_WM8350
@@ -155,6 +156,9 @@ config SND_SOC_TWL4030
select TWL4030_CODEC
tristate
+config SND_SOC_TWL6030
+ tristate
+
config SND_SOC_UDA134X
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index dbaecb1..e11a193 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -20,6 +20,7 @@ snd-soc-tlv320aic26-objs := tlv320aic26.o
snd-soc-tlv320aic3x-objs := tlv320aic3x.o
snd-soc-tlv320dac33-objs := tlv320dac33.o
snd-soc-twl4030-objs := twl4030.o
+snd-soc-twl6030-objs := twl6030.o
snd-soc-uda134x-objs := uda134x.o
snd-soc-uda1380-objs := uda1380.o
snd-soc-wm8350-objs := wm8350.o
@@ -76,6 +77,7 @@ obj-$(CONFIG_SND_SOC_TLV320AIC26) += snd-soc-tlv320aic26.o
obj-$(CONFIG_SND_SOC_TLV320AIC3X) += snd-soc-tlv320aic3x.o
obj-$(CONFIG_SND_SOC_TLV320DAC33) += snd-soc-tlv320dac33.o
obj-$(CONFIG_SND_SOC_TWL4030) += snd-soc-twl4030.o
+obj-$(CONFIG_SND_SOC_TWL6030) += snd-soc-twl6030.o
obj-$(CONFIG_SND_SOC_UDA134X) += snd-soc-uda134x.o
obj-$(CONFIG_SND_SOC_UDA1380) += snd-soc-uda1380.o
obj-$(CONFIG_SND_SOC_WM8350) += snd-soc-wm8350.o
diff --git a/sound/soc/codecs/twl6030.c b/sound/soc/codecs/twl6030.c
new file mode 100644
index 000..8b52aa1
--- /dev/null
+++ b/sound/soc/codecs/twl6030.c
@@ -0,0 +1,823 @@
+/*
+ * ALSA SoC TWL6030 codec driver
+ *
+ * Author: Misael Lopez Cruz x0052...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/pm.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/platform_device.h
+#include linux/i2c/twl.h
+
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+#include sound/soc-dapm.h
+#include sound/initval.h
+#include sound/tlv.h
+
+#include twl6030.h
+
+#define TWL6030_RATES (SNDRV_PCM_RATE_96000)
+#define TWL6030_FORMATS (SNDRV_PCM_FMTBIT_S32_LE)
+
+/* codec private data */
+struct twl6030_data {
+ struct snd_soc_codec codec;
+ int audpwron;
+ int codec_powered;
+};
+
+/*
+ * twl6030 register cache default register settings
+ */
+static const u8 twl6030_reg[TWL6030_CACHEREGNUM] = {
+ 0x00, /* not used 0x00*/
+ 0x4B, /* TWL6030_ASICID (ro)0x01*/
+ 0x00, /* TWL6030_ASICREV (ro) 0x02*/
+ 0x00, /* TWL6030_INTID 0x03*/
+ 0x7B, /* TWL6030_INTMR 0x04*/
+ 0x00, /* TWL6030_NCPCTRL0x05*/
+ 0x00, /* TWL6030_LDOCTL 0x06*/
+ 0x00, /* TWL6030_HPPLLCTL 0x07*/
+ 0x00, /* TWL6030_LPPLLCTL 0x08*/
+ 0x00, /* TWL6030_LPPLLDIV 0x09*/
+ 0x00, /* TWL6030_AMICBCTL 0x0A*/
+ 0x00, /* TWL6030_DMICBCTL 0x0B*/
+ 0x18, /* TWL6030_MICLCTL0x0C*/
+ 0x18, /* TWL6030_MICRCTL0x0D*/
+ 0x00, /* TWL6030_MICGAIN0x0E*/
+ 0x1B, /* TWL6030_LINEGAIN 0x0F*/
+
[PATCHv4 4/7] ASoC: TWL6030: Add support for low-power PLL
From: Misael Lopez Cruz x0052...@ti.com
TWL6030 codec sysclk can be provided by: low-power or high
performance PLL.
The low-power PLL takes a low-frequency input at 32,768 Hz and
generates an approximate of 17.64 or 19.2 MHz.
The high-performance PLL generates an exact 19.2 MHz clock signal
from high-frequency input at 12/19.2/26/38.4 MHz.
For the particular case of headset path, PLL being used defines the
headset power mode: low-power, high-performance. Headset DAC and
output driver should be configured according to the selected mode.
17.64 MHz sysclk is recommended only for headset low-power playback
mode.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com
---
sound/soc/codecs/twl6030.c | 232 +--
sound/soc/codecs/twl6030.h | 16 +++
2 files changed, 215 insertions(+), 33 deletions(-)
diff --git a/sound/soc/codecs/twl6030.c b/sound/soc/codecs/twl6030.c
index ec838b1..792407f 100644
--- a/sound/soc/codecs/twl6030.c
+++ b/sound/soc/codecs/twl6030.c
@@ -39,7 +39,7 @@
#include twl6030.h
-#define TWL6030_RATES (SNDRV_PCM_RATE_96000)
+#define TWL6030_RATES (SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000)
#define TWL6030_FORMATS (SNDRV_PCM_FMTBIT_S32_LE)
/* codec private data */
@@ -47,6 +47,9 @@ struct twl6030_data {
struct snd_soc_codec codec;
int audpwron;
int codec_powered;
+ int pll;
+ unsigned int sysclk;
+ struct snd_pcm_hw_constraint_list *sysclk_constraints;
};
/*
@@ -326,6 +329,29 @@ static void twl6030_power_down(struct snd_soc_codec *codec)
mdelay(10);
}
+/* set headset dac and driver power mode */
+static int headset_power_mode(struct snd_soc_codec *codec, int high_perf)
+{
+ int hslctl, hsrctl;
+ int mask = TWL6030_HSDRVMODEL | TWL6030_HSDACMODEL;
+
+ hslctl = twl6030_read_reg_cache(codec, TWL6030_REG_HSLCTL);
+ hsrctl = twl6030_read_reg_cache(codec, TWL6030_REG_HSRCTL);
+
+ if (high_perf) {
+ hslctl = ~mask;
+ hsrctl = ~mask;
+ } else {
+ hslctl |= mask;
+ hsrctl |= mask;
+ }
+
+ twl6030_write(codec, TWL6030_REG_HSLCTL, hslctl);
+ twl6030_write(codec, TWL6030_REG_HSRCTL, hsrctl);
+
+ return 0;
+}
+
/*
* MICATT volume control:
* from -6 to 0 dB in 6 dB steps
@@ -607,55 +633,195 @@ static int twl6030_set_bias_level(struct snd_soc_codec
*codec,
return 0;
}
+/* set of rates for each pll: low-power and high-performance */
+
+static unsigned int lp_rates[] = {
+ 88200,
+ 96000,
+};
+
+static struct snd_pcm_hw_constraint_list lp_constraints = {
+ .count = ARRAY_SIZE(lp_rates),
+ .list = lp_rates,
+};
+
+static unsigned int hp_rates[] = {
+ 96000,
+};
+
+static struct snd_pcm_hw_constraint_list hp_constraints = {
+ .count = ARRAY_SIZE(hp_rates),
+ .list = hp_rates,
+};
+
+static int twl6030_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_device *socdev = rtd-socdev;
+ struct snd_soc_codec *codec = socdev-card-codec;
+ struct twl6030_data *priv = codec-private_data;
+
+ if (!priv-sysclk) {
+ dev_err(codec-dev,
+ no mclk configured, call set_sysclk() on init\n);
+ return -EINVAL;
+ }
+
+ snd_pcm_hw_constraint_list(substream-runtime, 0,
+ SNDRV_PCM_HW_PARAM_RATE,
+ priv-sysclk_constraints);
+
+ return 0;
+}
+
+static int twl6030_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_device *socdev = rtd-socdev;
+ struct snd_soc_codec *codec = socdev-card-codec;
+ struct twl6030_data *priv = codec-private_data;
+ u8 lppllctl;
+ int rate;
+
+ /* nothing to do for high-perf pll, it supports only 48 kHz */
+ if (priv-pll == TWL6030_HPPLL_ID)
+ return 0;
+
+ lppllctl = twl6030_read_reg_cache(codec, TWL6030_REG_LPPLLCTL);
+
+ rate = params_rate(params);
+ switch (rate) {
+ case 88200:
+ lppllctl |= TWL6030_LPLLFIN;
+ priv-sysclk = 1764;
+ break;
+ case 96000:
+ lppllctl = ~TWL6030_LPLLFIN;
+ priv-sysclk = 1920;
+ break;
+ default:
+ dev_err(codec-dev, unsupported rate %d\n, rate);
+ return -EINVAL;
+ }
+
+ twl6030_write(codec, TWL6030_REG_LPPLLCTL, lppllctl);
+
+ return 0;
+}
+
static int
[PATCHv4 5/7] ASoC: TWL6030: Add restrictions for low-power playback mode
From: Misael Lopez Cruz x0052...@ti.com
Low-power playback mode is a special scenario where only headset path
(headset DAC and driver) is active. Only in this mode the codec can
support 44.1 and 48 kHz, low-power PLL should provide sysclk signal.
Currently, handsfree DAC and driver are the only components that can
prevent codec to enter to low-power playback mode. Other components
like earphone driver, vibrator driver or loopback (which are not yet
supported in the driver) can cause the same effect.
In order to detect conflicting paths, CODEC driver supervises
non-low-power widgets powered by DAPM mechanism, just at the point
pcm trigger callback gets called.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com
---
sound/soc/codecs/twl6030.c | 79 +++
1 files changed, 71 insertions(+), 8 deletions(-)
diff --git a/sound/soc/codecs/twl6030.c b/sound/soc/codecs/twl6030.c
index 792407f..53aa837 100644
--- a/sound/soc/codecs/twl6030.c
+++ b/sound/soc/codecs/twl6030.c
@@ -48,6 +48,7 @@ struct twl6030_data {
int audpwron;
int codec_powered;
int pll;
+ int non_lp;
unsigned int sysclk;
struct snd_pcm_hw_constraint_list *sysclk_constraints;
};
@@ -352,6 +353,20 @@ static int headset_power_mode(struct snd_soc_codec *codec,
int high_perf)
return 0;
}
+static int twl6030_power_mode_event(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol, int event)
+{
+ struct snd_soc_codec *codec = w-codec;
+ struct twl6030_data *priv = codec-private_data;
+
+ if (SND_SOC_DAPM_EVENT_ON(event))
+ priv-non_lp++;
+ else
+ priv-non_lp--;
+
+ return 0;
+}
+
/*
* MICATT volume control:
* from -6 to 0 dB in 6 dB steps
@@ -485,10 +500,14 @@ static const struct snd_soc_dapm_widget
twl6030_dapm_widgets[] = {
TWL6030_REG_HSLCTL, 0, 0),
SND_SOC_DAPM_DAC(HSDAC Right, Headset Playback,
TWL6030_REG_HSRCTL, 0, 0),
- SND_SOC_DAPM_DAC(HFDAC Left, Handsfree Playback,
- TWL6030_REG_HFLCTL, 0, 0),
- SND_SOC_DAPM_DAC(HFDAC Right, Handsfree Playback,
- TWL6030_REG_HFRCTL, 0, 0),
+ SND_SOC_DAPM_DAC_E(HFDAC Left, Handsfree Playback,
+ TWL6030_REG_HFLCTL, 0, 0,
+ twl6030_power_mode_event,
+ SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
+ SND_SOC_DAPM_DAC_E(HFDAC Right, Handsfree Playback,
+ TWL6030_REG_HFRCTL, 0, 0,
+ twl6030_power_mode_event,
+ SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
/* Analog playback switches */
SND_SOC_DAPM_SWITCH(HSDAC Left Playback,
@@ -504,10 +523,14 @@ static const struct snd_soc_dapm_widget
twl6030_dapm_widgets[] = {
SND_SOC_NOPM, 0, 0, hsl_driver_switch_controls),
SND_SOC_DAPM_SWITCH(Headset Right Driver,
SND_SOC_NOPM, 0, 0, hsr_driver_switch_controls),
- SND_SOC_DAPM_SWITCH(Handsfree Left Driver,
- SND_SOC_NOPM, 0, 0, hfl_driver_switch_controls),
- SND_SOC_DAPM_SWITCH(Handsfree Right Driver,
- SND_SOC_NOPM, 0, 0, hfr_driver_switch_controls),
+ SND_SOC_DAPM_SWITCH_E(Handsfree Left Driver,
+ SND_SOC_NOPM, 0, 0, hfl_driver_switch_controls,
+ twl6030_power_mode_event,
+ SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
+ SND_SOC_DAPM_SWITCH_E(Handsfree Right Driver,
+ SND_SOC_NOPM, 0, 0, hfr_driver_switch_controls,
+ twl6030_power_mode_event,
+ SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
/* Analog playback PGAs */
SND_SOC_DAPM_PGA(HFDAC Left PGA,
@@ -668,6 +691,17 @@ static int twl6030_startup(struct snd_pcm_substream
*substream,
return -EINVAL;
}
+ /*
+* capture is not supported at 17.64 MHz,
+* it's reserved for headset low-power playback scenario
+*/
+ if ((priv-sysclk == 1764) substream-stream) {
+ dev_err(codec-dev,
+ capture mode is not supported at %dHz\n,
+ priv-sysclk);
+ return -EINVAL;
+ }
+
snd_pcm_hw_constraint_list(substream-runtime, 0,
SNDRV_PCM_HW_PARAM_RATE,
priv-sysclk_constraints);
@@ -712,6 +746,34 @@ static int twl6030_hw_params(struct snd_pcm_substream
*substream,
return 0;
}
+static int twl6030_trigger(struct snd_pcm_substream *substream,
+ int cmd, struct snd_soc_dai *dai)
+{
+ struct
[PATCHv4 6/7] ASoC: TWL6030: Enable audio interrupt
From: Misael Lopez Cruz x0052...@ti.com
NAUDINT interrupt line is provided by the TWL6030 codec to signal
externally events like headset plug/unplug, hook, power-up sequence
completion, etc.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com
---
sound/soc/codecs/twl6030.c | 70 ---
sound/soc/codecs/twl6030.h | 14 +
2 files changed, 79 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/twl6030.c b/sound/soc/codecs/twl6030.c
index 53aa837..b8dd5ae 100644
--- a/sound/soc/codecs/twl6030.c
+++ b/sound/soc/codecs/twl6030.c
@@ -46,6 +46,7 @@
struct twl6030_data {
struct snd_soc_codec codec;
int audpwron;
+ int naudint;
int codec_powered;
int pll;
int non_lp;
@@ -61,7 +62,7 @@ static const u8 twl6030_reg[TWL6030_CACHEREGNUM] = {
0x4B, /* TWL6030_ASICID (ro)0x01*/
0x00, /* TWL6030_ASICREV (ro) 0x02*/
0x00, /* TWL6030_INTID 0x03*/
- 0x7B, /* TWL6030_INTMR 0x04*/
+ 0x00, /* TWL6030_INTMR 0x04*/
0x00, /* TWL6030_NCPCTRL0x05*/
0x00, /* TWL6030_LDOCTL 0x06*/
0x00, /* TWL6030_HPPLLCTL 0x07*/
@@ -367,6 +368,39 @@ static int twl6030_power_mode_event(struct
snd_soc_dapm_widget *w,
return 0;
}
+/* audio interrupt handler */
+static irqreturn_t twl6030_naudint_handler(int irq, void *data)
+{
+ struct snd_soc_codec *codec = data;
+ u8 intid;
+
+ twl_i2c_read_u8(TWL4030_MODULE_AUDIO_VOICE, intid, TWL6030_REG_INTID);
+
+ switch (intid) {
+ case TWL6030_THINT:
+ dev_alert(codec-dev, die temp over-limit detection\n);
+ break;
+ case TWL6030_PLUGINT:
+ case TWL6030_UNPLUGINT:
+ case TWL6030_HOOKINT:
+ break;
+ case TWL6030_HFINT:
+ dev_alert(codec-dev, hf drivers over current detection\n);
+ break;
+ case TWL6030_VIBINT:
+ dev_alert(codec-dev, vib drivers over current detection\n);
+ break;
+ case TWL6030_READYINT:
+ dev_alert(codec-dev, codec is ready\n);
+ break;
+ default:
+ dev_err(codec-dev, unknown audio interrupt %d\n, intid);
+ break;
+ }
+
+ return IRQ_HANDLED;
+}
+
/*
* MICATT volume control:
* from -6 to 0 dB in 6 dB steps
@@ -992,19 +1026,23 @@ static int __devinit twl6030_codec_probe(struct
platform_device *pdev)
struct twl4030_codec_data *twl_codec = pdev-dev.platform_data;
struct snd_soc_codec *codec;
struct twl6030_data *priv;
- int audpwron;
+ int audpwron, naudint;
int ret = 0;
priv = kzalloc(sizeof(struct twl6030_data), GFP_KERNEL);
if (priv == NULL)
return -ENOMEM;
- if (twl_codec)
+ if (twl_codec) {
audpwron = twl_codec-audpwron_gpio;
- else
+ naudint = twl_codec-naudint_irq;
+ } else {
audpwron = -EINVAL;
+ naudint = 0;
+ }
priv-audpwron = audpwron;
+ priv-naudint = naudint;
codec = priv-codec;
codec-dev = pdev-dev;
@@ -1042,13 +1080,28 @@ static int __devinit twl6030_codec_probe(struct
platform_device *pdev)
priv-codec_powered = 0;
}
+ if (naudint) {
+ /* audio interrupt */
+ ret = request_threaded_irq(naudint, NULL,
+ twl6030_naudint_handler,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+ twl6030_codec, codec);
+ if (ret)
+ goto gpio2_err;
+ } else {
+ dev_warn(codec-dev,
+ no naudint irq, audio interrupts disabled\n);
+ twl6030_write_reg_cache(codec, TWL6030_REG_INTMR,
+ TWL6030_ALLINT_MSK);
+ }
+
/* init vio registers */
twl6030_init_vio_regs(codec);
/* power on device */
ret = twl6030_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
if (ret)
- goto gpio2_err;
+ goto irq_err;
ret = snd_soc_register_codec(codec);
if (ret)
@@ -1067,6 +1120,9 @@ dai_err:
twl6030_codec = NULL;
reg_err:
twl6030_set_bias_level(codec, SND_SOC_BIAS_OFF);
+irq_err:
+ if (naudint)
+ free_irq(naudint, codec);
gpio2_err:
if (gpio_is_valid(audpwron))
gpio_free(audpwron);
@@ -1081,10 +1137,14 @@ static int __devexit twl6030_codec_remove(struct
platform_device *pdev)
{
struct twl6030_data *priv = twl6030_codec-private_data;
int audpwron = priv-audpwron;
+ int naudint =
[PATCHv4 7/7] ASoC: TWL6030: Detect power-up sequence completion
From: Misael Lopez Cruz x0052...@ti.com
When the codec is powered-up through external AUDPWRON line it starts
its power-up sequence. The completion of the sequence is signaled
through the audio interrupt, and then codec is operational.
If NAUDINT irq is provided, CODEC driver starts a wait_for_completion
just after AUDPWRON line transitions from low to high. It's signaled as
complete when servicing READYINT interrupt.
If AUDPWRON gpio line is provided but NAUDINT irq is not, then CODEC
driver enables READYINT and polls on INTID register. If none of them are
provided, then CODEC uses manual power sequences and disables all audio
interrupts.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com
---
sound/soc/codecs/twl6030.c | 61 +--
sound/soc/codecs/twl6030.h |1 +
2 files changed, 53 insertions(+), 9 deletions(-)
diff --git a/sound/soc/codecs/twl6030.c b/sound/soc/codecs/twl6030.c
index b8dd5ae..2847f1b 100644
--- a/sound/soc/codecs/twl6030.c
+++ b/sound/soc/codecs/twl6030.c
@@ -52,6 +52,7 @@ struct twl6030_data {
int non_lp;
unsigned int sysclk;
struct snd_pcm_hw_constraint_list *sysclk_constraints;
+ struct completion ready;
};
/*
@@ -372,6 +373,7 @@ static int twl6030_power_mode_event(struct
snd_soc_dapm_widget *w,
static irqreturn_t twl6030_naudint_handler(int irq, void *data)
{
struct snd_soc_codec *codec = data;
+ struct twl6030_data *priv = codec-private_data;
u8 intid;
twl_i2c_read_u8(TWL4030_MODULE_AUDIO_VOICE, intid, TWL6030_REG_INTID);
@@ -391,7 +393,7 @@ static irqreturn_t twl6030_naudint_handler(int irq, void
*data)
dev_alert(codec-dev, vib drivers over current detection\n);
break;
case TWL6030_READYINT:
- dev_alert(codec-dev, codec is ready\n);
+ complete(priv-ready);
break;
default:
dev_err(codec-dev, unknown audio interrupt %d\n, intid);
@@ -626,11 +628,45 @@ static int twl6030_add_widgets(struct snd_soc_codec
*codec)
return 0;
}
+static int twl6030_power_up_completion(struct snd_soc_codec *codec,
+ int naudint)
+{
+ struct twl6030_data *priv = codec-private_data;
+ int time_left;
+ u8 intid;
+
+ if (naudint) {
+ /* wait for ready interrupt with 48 ms timeout */
+ time_left = wait_for_completion_timeout(priv-ready,
+ msecs_to_jiffies(48));
+ } else {
+ /* retry 3 times only */
+ for (time_left = 3; time_left 0; time_left--) {
+ mdelay(16);
+ twl_i2c_read_u8(TWL4030_MODULE_AUDIO_VOICE, intid,
+ TWL6030_REG_INTID);
+ if (intid TWL6030_READYINT)
+ break;
+ }
+ }
+
+ if (!time_left) {
+ dev_err(codec-dev, timeout waiting for READYINT\n);
+ return -ETIMEDOUT;
+ }
+
+ priv-codec_powered = 1;
+
+ return 0;
+}
+
static int twl6030_set_bias_level(struct snd_soc_codec *codec,
enum snd_soc_bias_level level)
{
struct twl6030_data *priv = codec-private_data;
int audpwron = priv-audpwron;
+ int naudint = priv-naudint;
+ int ret;
switch (level) {
case SND_SOC_BIAS_ON:
@@ -643,8 +679,10 @@ static int twl6030_set_bias_level(struct snd_soc_codec
*codec,
/* use AUDPWRON line */
gpio_set_value(audpwron, 1);
- /* power-up sequence latency */
- mdelay(16);
+ /* wait for power-up completion */
+ ret = twl6030_power_up_completion(codec, naudint);
+ if (ret)
+ return ret;
/* sync registers updated during power-up sequence */
twl6030_read(codec, TWL6030_REG_NCPCTL);
@@ -653,12 +691,11 @@ static int twl6030_set_bias_level(struct snd_soc_codec
*codec,
} else {
/* use manual power-up sequence */
twl6030_power_up(codec);
+ priv-codec_powered = 1;
}
/* initialize vdd/vss registers with reg_cache */
twl6030_init_vdd_regs(codec);
-
- priv-codec_powered = 1;
break;
case SND_SOC_BIAS_OFF:
if (!priv-codec_powered)
@@ -1067,6 +1104,7 @@ static int __devinit twl6030_codec_probe(struct
platform_device *pdev)
mutex_init(codec-mutex);
INIT_LIST_HEAD(codec-dapm_widgets);
Re: [PATCH/RFC 0/4] convert HS-MMC driver to hwmod + runtime PM
Kevin Hilman khil...@deeprootsystems.com writes:
This series converts the OMAP HS-MMC driver to use omap_hwmod +
runtime PM API.
Depends on MMC hwmods available in 'pm-wip/hwmods' branch of
my git tree[1] as well as previously posted runtime PM series:
[PATCH/RFC 0/2] initial runtime PM layer for OMAP
The easies way to experiment/test is to use my 'pm-wip/mmc' branch
which has all the dependencies, and is based on omap/for-next'.
It has been tested by merging with current PM branch.
[1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git
A question for those of you who actually understand the MMC driver...
I'm having problems getting my head around the current PM stuff in the
MMC driver. My primary question is:
Why does the suspend hook need to re-enable the device before
suspending?
When using runtime PM, the MMC device is disabled including
clocks off and regulator off (if power_savings == true) when there
is no activity.
Then, in the static suspend hook, it's re-enabled (including taking it out of
off, re-enabling regulators etc) only to be quickly disabled again.
This seems horribly inefficient.
I admit to not understanding the MMC layer terribly well, so can someone
enlighten me as to what is going on here?
What I am testing here is a patch on top of this series (below) that
adds a check to the static suspend hook. If the device is already
runtime suspended, then the suspend and resume hooks should be noop.
This appears to work just fine while testing on omap3evm just doing
simple read/write tests before an after suspend resume.
Note that if you want to test this patch, it also depends on this
patch to runtime PM from the linux-pm list:
https://lists.linux-foundation.org/pipermail/linux-pm/2010-February/024275.html
These are all included in an updated version of my pm-wip/mmc branch
for ease of testing. Merge it with the current PM branch, enable
CONFIG_PM_RUNTIME and test away.
Kevin
commit 166cba7679fa267ee6e6eb39fd1e871ede5ded16
Author: Kevin Hilman khil...@deeprootsystems.com
Date: Tue Feb 23 16:21:56 2010 -0800
MMC: omap_hsmmc: check for runtime-suspend in static suspend
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 16d66b9..dd027bb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -,6 +,9 @@ static int omap_hsmmc_suspend(struct device *dev)
if (host host-suspended)
return 0;
+ if (pm_is_runtime_suspended(host-dev))
+ return 0;
+
if (host) {
host-suspended = 1;
if (host-pdata-suspend) {
@@ -2260,12 +2263,6 @@ static int omap_hsmmc_suspend(struct device *dev)
}
mmc_host_disable(host-mmc);
}
-
- /*
-* HACK: extra put to compensate for DPM core keeping
-* runtime PM disabled. -- khilman
-*/
- pm_runtime_put_sync(host-dev);
}
return ret;
}
@@ -2280,13 +2277,10 @@ static int omap_hsmmc_resume(struct device *dev)
if (host !host-suspended)
return 0;
- if (host) {
- /*
-* HACK: extra get to compensate for DPM core keeping
-* runtime PM disabled. -- khilman
-*/
- pm_runtime_get_sync(host-dev);
+ if (pm_is_runtime_suspended(host-dev))
+ return 0;
+ if (host) {
if (mmc_host_enable(host-mmc) != 0) {
pm_runtime_suspend(host-dev);
goto clk_en_err;
--
To unsubscribe from this list: send the line unsubscribe 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] DSPBRIDGE: logic error fix for SleepDSP timeout value
On 2/18/2010 3:55 PM, Ramirez Luna, Omar wrote: When leaving the loop waiting for the dsp to transition from its power state, timeout value will be negative, therefore a print for timeout waiting for the dsp won't be displayed, as the condition to check for is !timeout. Reported-by: Berenice Herreraberen...@ti.com Signed-off-by: Omar Ramirez Lunaomar.rami...@ti.com --- drivers/dsp/bridge/wmd/tiomap3430_pwr.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Pushed to dspbridge - 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 2/2] DSPBRIDGE: check pointer before dereference
On 2/18/2010 3:55 PM, Ramirez Luna, Omar wrote: Change the check for valid handle to detect a possible error, and now use it before dereferencing the pointer. Signed-off-by: Omar Ramirez Lunaomar.rami...@ti.com --- drivers/dsp/bridge/pmgr/msg.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) Rebased and pushed to dspbridge - 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: [Patchv2 0/8] DSPBRIDGE: typedef cleanup
On 2/5/2010 7:21 PM, Hebbar, Shivananda wrote: Resending the patches after updating review comments and also Fixing some compilation breaks. These patches remove the typedefs and replace it with normal C types: Shivananda Hebbar (8) DSPBRIDGE: typedef cleanup -DSP RTOS DSPBRIDGE: typedef cleanup -PROCTYPE DSPBRIDGE: typedef cleanup -PROCFAMILY DSPBRIDGE: typedef cleanup -DSP_HSTREAM DSPBRIDGE: typedef cleanup -DSP_HPROCESSOR DSPBRIDGE: typedef cleanup -DSP_HNODE DSPBRIDGE: typedef cleanup -BRD_STATUS DSPBRIDGE: typedef cleanup -CHNL_MODE arch/arm/plat-omap/include/dspbridge/brddefs.h |1 - arch/arm/plat-omap/include/dspbridge/chnldefs.h |2 - arch/arm/plat-omap/include/dspbridge/cmm.h |2 +- arch/arm/plat-omap/include/dspbridge/dbdefs.h | 18 +--- arch/arm/plat-omap/include/dspbridge/dispdefs.h |4 +- arch/arm/plat-omap/include/dspbridge/dmm.h |2 +- arch/arm/plat-omap/include/dspbridge/drv.h |6 +- arch/arm/plat-omap/include/dspbridge/node.h |4 +- arch/arm/plat-omap/include/dspbridge/proc.h | 43 +- arch/arm/plat-omap/include/dspbridge/wcdioctl.h | 96 +++--- arch/arm/plat-omap/include/dspbridge/wmd.h |4 +- arch/arm/plat-omap/include/dspbridge/wmdchnl.h |2 +- drivers/dsp/bridge/pmgr/cmm.c |2 +- drivers/dsp/bridge/pmgr/dev.c |6 +- drivers/dsp/bridge/pmgr/dmm.c |2 +- drivers/dsp/bridge/pmgr/wcd.c |4 +- drivers/dsp/bridge/rmgr/node.c | 12 ++-- drivers/dsp/bridge/rmgr/proc.c | 56 +++--- drivers/dsp/bridge/rmgr/strm.c |2 +- drivers/dsp/bridge/wmd/chnl_sm.c|8 +- drivers/dsp/bridge/wmd/tiomap3430.c |4 +- 21 files changed, 134 insertions(+), 146 deletions(-) -- Patch 5 had lots of checkpatch errors, I understand that they were there before but would be good if they are fixed when touching those lines (btw they were fixed). For this patch only one suspect code indent is still there because of the original code, it can't be fixed without changing a big chunk of the file so leaving it as it is (will be addressed by lindent) Pushed to dspbridge - 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
[ANNOUNCE] dspbridge: kill camelcase
Hi All, I'm currently working on removing camel case + hungarian notation from dspbridge code in the following branch: dspbridge-next-camelcase on d.o-z I'll appreciate if you can mail any unsent patch otherwise it will need to wait (and be rebased) after the camelcase changes. If nobody disagrees I'll be marking dspbridge 0.2 (as per private discussion) in the upcoming days. 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: [ANNOUNCE] dspbridge: kill camelcase
* Omar Ramirez Luna omar.rami...@ti.com [100223 18:11]: Hi All, I'm currently working on removing camel case + hungarian notation from dspbridge code in the following branch: dspbridge-next-camelcase on d.o-z I'll appreciate if you can mail any unsent patch otherwise it will need to wait (and be rebased) after the camelcase changes. If nobody disagrees I'll be marking dspbridge 0.2 (as per private discussion) in the upcoming days. Maybe do a perl or sed script that allows you to convert one string at a time? That way you can regenerate the patches as needed. We used something like that to convert the musb code a few years ago. I recommend converting one variable at a time and then compile and boot test in between. Otherwise you can easily convert substrings accidentally and then things will not compile.. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, February 24, 2010 4:42 AM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Woodruff, Richard; Ghorai,
Sukumar
Subject: Re: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
* Shilimkar, Santosh santosh.shilim...@ti.com [100222 23:16]:
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Tuesday, February 23, 2010 4:37 AM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Woodruff, Richard; Ghorai,
Sukumar
Subject: Re: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
* Tony Lindgren t...@atomide.com [100222 13:35]:
* Shilimkar, Santosh santosh.shilim...@ti.com [100218 21:22]:
Bye the way just to add bit more clarity, this patch addresses TX
hardware restriction in the new UART IP used on omap3630 and omap4430.
First part of the fix for RX is already in mainline,
Commit: ce13d4716a276f4331d78ba28a5093a63822ab95
More details on this thread are here.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19447.html
Thanks, I've updated the comments for this patch with the link above
and added the whole series into omap for-next.
Except patches 8 and 9 as they break compile for mach-omap1
and need to be updated.
Patch 8 is alright and doesn't break omap1. Patch 7 and patch 9 needs
update to fix
the mach-omap1 build issue by moving irqs-44xx.h header file to plat-omap
directory.
Attached are updated 7 and 9.
Build tested for omap1 (omap_generic_1710_defconfig and
omap_h2_1610_defconfig) and boot
tested with omap3_defconfig on omap4430sdp board.
Next time, one patch per email please. And updates as replies
to the original patches, or else the whole series. And patches
as inline attachments.
Otherwise it's hard to keep track of the patches and comment
them.
Ok. Will take care next time.
I've updated your patch 9/9 with the following as in omap for-next
I was getting:
arch/arm/mach-omap2/usb-musb.c:97: Building for omap_3430sdp_defconfigred
(first use in this
function)
Building for
omap_3630sdp_defconfigch-omap2/usb-musb.c:97: error: (Each undeclared
identifier is reported only
once
arch/arm/mach-omap2/usb-musb.c:97: error: for each function it appears in.)
arch/arm/mach-omap2/usb-musb.c:98: error: 'INT_44XX_HS_USB_DMA' undeclared
(first use in this
function)
Looks like musb is also merged now. My yesterday's pull of omap-for-linus
didn't have musb.
Regards,
Tony
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -94,8 +94,8 @@ void __init usb_musb_init(struct omap_musb_board_data
*board_data)
musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
} else if (cpu_is_omap44xx()) {
musb_resources[0].start = OMAP44XX_HSUSB_OTG_BASE;
- musb_resources[1].start = INT_44XX_HS_USB_MC;
- musb_resources[2].start = INT_44XX_HS_USB_DMA;
+ musb_resources[1].start = OMAP44XX_IRQ_HS_USB_MC_N;
+ musb_resources[2].start = OMAP44XX_IRQ_HS_USB_DMA_N;
}
musb_resources[0].end = musb_resources[0].start + SZ_4K - 1;
Thanks for fixing this.
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
[PATCH] musb: Add extvbus in musb_board_data
EXTVBUS programming is required by OMAP3EVM REV =E to supply 500mA
power so adding a flag which can be used by musb driver to program
EXTVBUS.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Created against l-o master branch and on top of below patch.
[PATCH] musb: fix power field to hold all possible values
arch/arm/mach-omap2/board-omap3evm.c |3 +++
arch/arm/mach-omap2/usb-musb.c|1 +
arch/arm/plat-omap/include/plat/usb.h |1 +
3 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index d6bc88c..b7ea9b7 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -702,6 +702,9 @@ static void __init omap3_evm_init(void)
omap_mux_init_gpio(21, OMAP_PIN_INPUT_PULLUP);
ehci_pdata.reset_gpio_port[1] = 21;
+ /* EVM REV = E can supply 500mA with EXTVBUS programming */
+ musb_board_data.power = 500;
+ musb_board_data.extvbus = 1;
} else {
/* setup EHCI phy reset on MDC */
omap_mux_init_gpio(135, OMAP_PIN_OUTPUT);
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 53a9638..17726ac 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -106,6 +106,7 @@ void __init usb_musb_init(struct omap_musb_board_data
*board_data)
musb_plat.board_data = board_data;
musb_plat.power = board_data-power 1;
musb_plat.mode = board_data-mode;
+ musb_plat.extvbus = board_data-extvbus;
if (platform_device_register(musb_device) 0)
printk(KERN_ERR Unable to register HS-USB (MUSB) device\n);
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index b181297..d82bf77 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -47,6 +47,7 @@ struct omap_musb_board_data {
u8 interface_type;
u8 mode;
u16 power;
+ unsigned extvbus:1;
};
enum musb_interface{MUSB_INTERFACE_ULPI, MUSB_INTERFACE_UTMI};
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About multicore OMAP
On Tue, Feb 23, 2010 at 10:20 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: John, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Tuesday, February 23, 2010 8:01 PM To: Jacob john Cc: linux-omap@vger.kernel.org Subject: RE: About multicore OMAP -Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Tuesday, February 23, 2010 7:51 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP It's Blaze with two lcd's and pico, looks great. Can I have this linux-omap kernel running on OMAP4?, plus I'm looking for SMP benchmark results etc. Linux-omap kernel with omap_4430sdp_defconfig will boot on blaze with SMP. This won't have lot of driver support as such currently. Also L2 cache support is in on the way to make it to mainline as well. You should be able to play with this with some basic benchmark test related to CPU. Display , Audio, Pico, keypad, touchscreeen etc drivers are available with the release and you should be able get more details from the TI contact person who gave you the blaze. You can also get the performance numbers from same source If you need the full kernel with all the drivers I mentioned above, you can use below git. http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=shortlog;h=refs/heads/L24.4 Good help so far.., wondering why two trees for OMAP4, tell me the diff b/n this list and the zoom. is there a different mailing list for zoom? confusing... and I am sorrythanks for the pointers 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: About multicore OMAP
-Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Wednesday, February 24, 2010 10:16 AM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP On Tue, Feb 23, 2010 at 10:20 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: John, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Tuesday, February 23, 2010 8:01 PM To: Jacob john Cc: linux-omap@vger.kernel.org Subject: RE: About multicore OMAP -Original Message- From: Jacob john [mailto:jacob.joh...@gmail.com] Sent: Tuesday, February 23, 2010 7:51 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: About multicore OMAP It's Blaze with two lcd's and pico, looks great. Can I have this linux-omap kernel running on OMAP4?, plus I'm looking for SMP benchmark results etc. Linux-omap kernel with omap_4430sdp_defconfig will boot on blaze with SMP. This won't have lot of driver support as such currently. Also L2 cache support is in on the way to make it to mainline as well. You should be able to play with this with some basic benchmark test related to CPU. Display , Audio, Pico, keypad, touchscreeen etc drivers are available with the release and you should be able get more details from the TI contact person who gave you the blaze. You can also get the performance numbers from same source If you need the full kernel with all the drivers I mentioned above, you can use below git. http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=shortlog;h=refs/heads/L24.4 Good help so far.., wondering why two trees for OMAP4, tell me the diff b/n this list and the zoom. is there a different mailing list for zoom? confusing... and I am sorrythanks for the pointers The mailing list is only one (Linux-omap). There is no difference. Linux-omap tree is almost mainline equivalent from omap4 point of view. The features are developed on the tree I mentioned above. The tested features will be up-streamed after rebasing one by one. You will find only upstreamed/lined-up features in linux-omap tree. Regards, Santosh
RE: [PATCH 00/11] OMAP clock/hwmod: final set of 2.6.34 patches
Paul,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul
Walmsley
Sent: Tuesday, February 23, 2010 10:20 AM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: [PATCH 00/11] OMAP clock/hwmod: final set of 2.6.34 patches
Hello,
Here are a few more OMAP clock and hwmod patches intended for 2.6.34,
posted in case anyone has any review comments.
These patches have been boot-tested on OSK5912, N800, 2430SDP,
Overo; and compile-tested on 4430SDP.
I have boot tested this series and earlier two series on OMAP4430 SDP.
They boot fine.
---
size:
text data bss dec hex filename
2882000127872 88872 3098744 2f4878 vmlinux.osk5912.orig
2882016127872 88872 3098760 2f4888 vmlinux.osk5912.patched
2324953121440 63728 2510121 264d29 vmlinux.n8x0.orig
2325885121536 63728 2511149 26512d vmlinux.n8x0.patched
3422044176928 146928 3745900 39286c vmlinux.2430sdp.orig
3423048177024 146928 3747000 392cb8 vmlinux.2430sdp.patched
6060161 1797424 5800396 13657981 d0677d vmlinux.omap3.orig
6061113 1797488 5800396 13658997 d06b75 vmlinux.omap3.patched
2049131168736 65412 2283279 22d70f vmlinux.4430sdp.orig
2050167169632 65412 2285211 22de9b vmlinux.4430sdp.patched
Paul Walmsley (7):
OMAP clock: add omap_clk_get_by_name() for use by OMAP hwmod core code
OMAP hwmod: convert hwmod to use hardware clock names rather than
clkdev dev+con
OMAP hwmod: convert header files with static allocations into C files
OMAP hwmod: add hwmod class support
OMAP clockdomain: if no autodeps exist, don't try to add or remove them
OMAP2/3 clock: combine OMAP2 3 boot-time MPU rate change code
OMAP2+ clock: revise omap2_clk_{disable,enable}()
Rajendra Nayak (1):
OMAP4: clock: Rename leaf clock nodes to end with a _ick or _fck
Santosh Shilimkar (2):
OMAP4: clock: Add dummy clock nodes for interface clocks
OMAP4: clock: Remove clock hacks from timer-gp.c
Vimarsh Zutshi (1):
From 5c87e27fd557a56aca72cd10529c3bdcb0c8a517 Mon Sep 17 00:00:00 2001
arch/arm/configs/omap_4430sdp_defconfig |7
arch/arm/mach-omap1/clock.c | 14 -
arch/arm/mach-omap1/clock_data.c |6
arch/arm/mach-omap2/Makefile | 12 -
arch/arm/mach-omap2/clock.c | 220 --
arch/arm/mach-omap2/clock.h |5
arch/arm/mach-omap2/clock2xxx.c | 34 -
arch/arm/mach-omap2/clock3xxx.c | 59 ---
arch/arm/mach-omap2/clock3xxx_data.c |2
arch/arm/mach-omap2/clock44xx_data.c | 596
++
arch/arm/mach-omap2/clockdomain.c| 16 +
arch/arm/mach-omap2/io.c | 21 -
arch/arm/mach-omap2/omap_hwmod.c | 244 ++-
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 38 +-
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 38 +-
arch/arm/mach-omap2/omap_hwmod_34xx.h| 168 ---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 181
arch/arm/mach-omap2/omap_hwmod_common_data.c | 24 +
arch/arm/mach-omap2/omap_hwmod_common_data.h | 24 +
arch/arm/mach-omap2/timer-gp.c |5
arch/arm/plat-omap/clock.c | 37 ++
arch/arm/plat-omap/include/plat/clock.h |3
arch/arm/plat-omap/include/plat/omap_hwmod.h | 71 ++-
23 files changed, 1073 insertions(+), 752 deletions(-)
rename arch/arm/mach-omap2/{omap_hwmod_2420.h = omap_hwmod_2420_data.c}
(82%)
rename arch/arm/mach-omap2/{omap_hwmod_2430.h = omap_hwmod_2430_data.c}
(83%)
delete mode 100644 arch/arm/mach-omap2/omap_hwmod_34xx.h
create mode 100644 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
create mode 100644 arch/arm/mach-omap2/omap_hwmod_common_data.h
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] OMAP: HWMOD: Bug fixes in hwmod structure definitions
This patch corrects the width of sysc_flags in hwmod sysconfig structure
where the values to be stored to this variable exceed the current
field width.
Signed-off-by: Thara Gopinath th...@ti.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 921990e..aad5948 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -258,7 +258,7 @@ struct omap_hwmod_sysconfig {
u16 sysc_offs;
u16 syss_offs;
u8 idlemodes;
- u8 sysc_flags;
+ u16 sysc_flags;
u8 clockact;
};
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe 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-V1 09/10] VPFE Capture: Add support for USERPTR mode of operation
-Original Message-
From: Muralidharan Karicheri [mailto:mkarich...@gmail.com]
Sent: Wednesday, February 24, 2010 4:53 AM
To: Hiremath, Vaibhav
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org;
hverk...@xs4all.nl; Karicheri, Muralidharan
Subject: Re: [PATCH-V1 09/10] VPFE Capture: Add support for USERPTR mode of
operation
Vaibhav,
There are changes to vpfe capture on Arago tree on top of this. For
example, vpfe_uservirt_to_phys() is removed and is replaced with
videobuf_iolock(). So please get the latest changes to upstream.
[Hiremath, Vaibhav] No, the Arago version doesn't support USERPTR mode at all,
1386if (V4L2_MEMORY_USERPTR == req_buf-memory) {
1386 /* we don't support user ptr IO */
1387 v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_reqbufs:
1388 USERPTR IO not supported\n);
1389 return -EINVAL;
1390 }
And also, I have received important comment from Mauro, which expects some code
tobe moved to generic VideoBuf layer. I will be submitting patch for the same
separately.
Thanks,
Vaibhav
Murali
On Tue, Feb 23, 2010 at 3:34 AM, hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/ti-media/vpfe_capture.c | 94
++
1 files changed, 79 insertions(+), 15 deletions(-)
diff --git a/drivers/media/video/ti-media/vpfe_capture.c
b/drivers/media/video/ti-media/vpfe_capture.c
index cece265..7d4ab44 100644
--- a/drivers/media/video/ti-media/vpfe_capture.c
+++ b/drivers/media/video/ti-media/vpfe_capture.c
@@ -538,7 +538,24 @@ static void vpfe_schedule_next_buffer(struct
vpfe_device *vpfe_dev)
struct videobuf_buffer, queue);
list_del(vpfe_dev-next_frm-queue);
vpfe_dev-next_frm-state = VIDEOBUF_ACTIVE;
- addr = videobuf_to_dma_contig(vpfe_dev-next_frm);
+ if (V4L2_MEMORY_USERPTR == vpfe_dev-memory)
+ addr = vpfe_dev-cur_frm-boff;
+ else
+ addr = videobuf_to_dma_contig(vpfe_dev-next_frm);
+
+ ccdc_dev-hw_ops.setfbaddr(addr);
+}
+
+static void vpfe_schedule_bottom_field(struct vpfe_device *vpfe_dev)
+{
+ unsigned long addr;
+
+ if (V4L2_MEMORY_USERPTR == vpfe_dev-memory)
+ addr = vpfe_dev-cur_frm-boff;
+ else
+ addr = videobuf_to_dma_contig(vpfe_dev-cur_frm);
+
+ addr += vpfe_dev-field_off;
ccdc_dev-hw_ops.setfbaddr(addr);
}
@@ -559,7 +576,6 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
{
struct vpfe_device *vpfe_dev = dev_id;
enum v4l2_field field;
- unsigned long addr;
int fid;
v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, \nStarting
vpfe_isr...\n);
@@ -604,10 +620,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
* the CCDC memory address
*/
if (field == V4L2_FIELD_SEQ_TB) {
- addr =
- videobuf_to_dma_contig(vpfe_dev-
cur_frm);
- addr += vpfe_dev-field_off;
- ccdc_dev-hw_ops.setfbaddr(addr);
+ vpfe_schedule_bottom_field(vpfe_dev);
}
goto clear_intr;
}
@@ -1234,7 +1247,10 @@ static int vpfe_videobuf_setup(struct
videobuf_queue *vq,
struct vpfe_device *vpfe_dev = fh-vpfe_dev;
v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_buffer_setup\n);
- *size = config_params.device_bufsize;
+ *size = vpfe_dev-fmt.fmt.pix.sizeimage;
+ if (vpfe_dev-memory == V4L2_MEMORY_MMAP
+ vpfe_dev-fmt.fmt.pix.sizeimage
config_params.device_bufsize)
+ *size = config_params.device_bufsize;
if (*count config_params.min_numbuffers)
*count = config_params.min_numbuffers;
@@ -1243,6 +1259,46 @@ static int vpfe_videobuf_setup(struct
videobuf_queue *vq,
return 0;
}
+/*
+ * vpfe_uservirt_to_phys: This function is used to convert user
+ * space virtual address to physical address.
+ */
+static u32 vpfe_uservirt_to_phys(struct vpfe_device *vpfe_dev, u32 virtp)
+{
+ struct mm_struct *mm = current-mm;
+ unsigned long physp = 0;
+ struct vm_area_struct *vma;
+
+ vma = find_vma(mm, virtp);
+
+ /* For kernel direct-mapped memory, take the easy way */
+ if (virtp = PAGE_OFFSET)
+ physp = virt_to_phys((void *)virtp);
+ else if (vma (vma-vm_flags VM_IO) (vma-vm_pgoff))
+ /* this will catch, kernel-allocated, mmaped-to-usermode
addr */
RE: [PATCH 3/9] tvp514x: add YUYV format support
-Original Message-
From: Muralidharan Karicheri [mailto:mkarich...@gmail.com]
Sent: Wednesday, February 24, 2010 5:15 AM
To: Hiremath, Vaibhav
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org;
hverk...@xs4all.nl; davinci-linux-open-sou...@linux.davincidsp.com;
Karicheri, Muralidharan
Subject: Re: [PATCH 3/9] tvp514x: add YUYV format support
Vaibhav,
On Mon, Jan 4, 2010 at 9:02 AM, hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/tvp514x.c | 7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 4cf3593..b344b58 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
@@ -212,6 +212,13 @@ static const struct v4l2_fmtdesc tvp514x_fmt_list[] =
{
.description = 8-bit UYVY 4:2:2 Format,
.pixelformat = V4L2_PIX_FMT_UYVY,
},
+ {
+ .index = 1,
+ .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ .flags = 0,
+ .description = 8-bit YUYV 4:2:2 Format,
+ .pixelformat = V4L2_PIX_FMT_YUYV,
+ },
};
As per data sheet I can see only CbYCrY format output from the tvp5146
which translate to UYVY. How are you configuring tvp to output YUYV? I
don;t see any change to the code to configure this format.
[Hiremath, Vaibhav] Yes you are right, actually this is dummy format created to
support YUYV.
CCDC can switch the CbCr order and also can swap Y/C order. So if you
are achieving
this via ccdc configuration, there is no need to add this format to tvp5146
IMO.
[Hiremath, Vaibhav] I think it makes sense to handle this is master driver,
since we are handling this in CCDC. It could possible in the future TVP5146
might get used with SoC which don't have this capability.
Thanks,
Vaibhav
-Murali
/**
--
1.6.2.4
--
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
--
Murali Karicheri
mkarich...@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
[PATCH] omap2/3/4: serial: Half revert multiboot changes
From 14bc4ee14ac5a3dab79d9292bf22ab0401879cd5 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Wed, 24 Feb 2010 01:15:55 -0600
Subject: [PATCH] omap2/3/4: serial: Half revert multiboot changes
The patch named:
omap2/3/4: Fix mach-omap2/serial.c for multiboot
Which added UART4 init also for 36xx based boards, broke zoom3
booting. External UART must be correctly initialized already
by board-zoom-debugboard.c file, therefore the addition on UART4
initialization can't be done blindly (i.e. board agnostic)
This patch removes the 36xx uart4 init for the above reason.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/serial.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b79bc89..fe3122b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -115,7 +115,6 @@ static struct plat_serial8250_port serial_platform_data2[]
= {
}
};
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static struct plat_serial8250_port serial_platform_data3[] = {
{
.irq= 70,
@@ -132,11 +131,6 @@ static inline void omap2_set_globals_uart4(struct
omap_globals *omap2_globals)
{
serial_platform_data3[0].mapbase = omap2_globals-uart4_phys;
}
-#else
-static inline void omap2_set_globals_uart4(struct omap_globals *omap2_globals)
-{
-}
-#endif
void __init omap2_set_globals_uart(struct omap_globals *omap2_globals)
{
@@ -597,7 +591,7 @@ static struct omap_uart_state omap_uart[] = {
},
},
},
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#ifdef CONFIG_ARCH_OMAP4
{
.pdev = {
.name = serial8250,
@@ -764,7 +758,7 @@ void __init omap_serial_init(void)
{
int i, nr_ports;
- if (!(cpu_is_omap3630() || cpu_is_omap4430()))
+ if (!cpu_is_omap4430())
nr_ports = 3;
else
nr_ports = ARRAY_SIZE(omap_uart);
--
1.6.3.3
0001-omap2-3-4-serial-Half-revert-multiboot-changes.patch
Description: 0001-omap2-3-4-serial-Half-revert-multiboot-changes.patch
RE: [PATCH] omap2/3/4: serial: Half revert multiboot changes
Hmm..
I think I sent this patch too soon...
Please ignore it, this is not a proper solution I feel..
But what it is true... is that, patch omap2/3/4: Fix mach-omap2/serial.c for
multiboot is definitely breaking Zoom3 boot, and needs to be fixed.
I'll try to come up with a better patch.
Regards,
Sergio
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
Sent: Wednesday, February 24, 2010 1:31 AM
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org; Sonasath, Moiz; Pandita, Vikram
Subject: [PATCH] omap2/3/4: serial: Half revert multiboot changes
From 14bc4ee14ac5a3dab79d9292bf22ab0401879cd5 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Wed, 24 Feb 2010 01:15:55 -0600
Subject: [PATCH] omap2/3/4: serial: Half revert multiboot changes
The patch named:
omap2/3/4: Fix mach-omap2/serial.c for multiboot
Which added UART4 init also for 36xx based boards, broke zoom3
booting. External UART must be correctly initialized already
by board-zoom-debugboard.c file, therefore the addition on UART4
initialization can't be done blindly (i.e. board agnostic)
This patch removes the 36xx uart4 init for the above reason.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/serial.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b79bc89..fe3122b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -115,7 +115,6 @@ static struct plat_serial8250_port
serial_platform_data2[] = {
}
};
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static struct plat_serial8250_port serial_platform_data3[] = {
{
.irq= 70,
@@ -132,11 +131,6 @@ static inline void omap2_set_globals_uart4(struct
omap_globals *omap2_globals)
{
serial_platform_data3[0].mapbase = omap2_globals-uart4_phys;
}
-#else
-static inline void omap2_set_globals_uart4(struct omap_globals
*omap2_globals)
-{
-}
-#endif
void __init omap2_set_globals_uart(struct omap_globals *omap2_globals)
{
@@ -597,7 +591,7 @@ static struct omap_uart_state omap_uart[] = {
},
},
},
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#ifdef CONFIG_ARCH_OMAP4
{
.pdev = {
.name = serial8250,
@@ -764,7 +758,7 @@ void __init omap_serial_init(void)
{
int i, nr_ports;
- if (!(cpu_is_omap3630() || cpu_is_omap4430()))
+ if (!cpu_is_omap4430())
nr_ports = 3;
else
nr_ports = ARRAY_SIZE(omap_uart);
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
