[PATCH] ASoC: Declare Headset as Mic and Headphone widgets for SDP3430
Headset was declared previously as a Headphone widget connecting
HSMIC and HSOL/HSOR pins of TWL4030 codec in SDP430 machine driver.
The capture path becomes invalid as the Headphone widget is not a
valid input endpoint.
Instead of that, the Headset is declared as separate Microphone
and Headphone widgets. Current patch modifies audio map:
- Headset Mic: HSMIC with bias
- Headset Stereophone: HSOL, HSOR
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
---
sound/soc/omap/sdp3430.c | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/sound/soc/omap/sdp3430.c b/sound/soc/omap/sdp3430.c
index 0a41de6..10f1c86 100644
--- a/sound/soc/omap/sdp3430.c
+++ b/sound/soc/omap/sdp3430.c
@@ -90,8 +90,12 @@ static struct snd_soc_jack hs_jack;
/* Headset jack detection DAPM pins */
static struct snd_soc_jack_pin hs_jack_pins[] = {
{
- .pin = Headset Jack,
- .mask = SND_JACK_HEADSET,
+ .pin = Headset Mic,
+ .mask = SND_JACK_MICROPHONE,
+ },
+ {
+ .pin = Headset Stereophone,
+ .mask = SND_JACK_HEADPHONE,
},
};
@@ -109,7 +113,8 @@ static struct snd_soc_jack_gpio hs_jack_gpios[] = {
static const struct snd_soc_dapm_widget sdp3430_twl4030_dapm_widgets[] = {
SND_SOC_DAPM_MIC(Ext Mic, NULL),
SND_SOC_DAPM_SPK(Ext Spk, NULL),
- SND_SOC_DAPM_HP(Headset Jack, NULL),
+ SND_SOC_DAPM_MIC(Headset Mic, NULL),
+ SND_SOC_DAPM_HP(Headset Stereophone, NULL),
};
static const struct snd_soc_dapm_route audio_map[] = {
@@ -123,11 +128,13 @@ static const struct snd_soc_dapm_route audio_map[] = {
{Ext Spk, NULL, HFL},
{Ext Spk, NULL, HFR},
- /* Headset: HSMIC (with bias), HSOL, HSOR */
- {Headset Jack, NULL, HSOL},
- {Headset Jack, NULL, HSOR},
+ /* Headset Mic: HSMIC with bias */
{HSMIC, NULL, Headset Mic Bias},
- {Headset Mic Bias, NULL, Headset Jack},
+ {Headset Mic Bias, NULL, Headset Mic},
+
+ /* Headset Stereophone (Headphone): HSOL, HSOR */
+ {Headset Stereophone, NULL, HSOL},
+ {Headset Stereophone, NULL, HSOR},
};
static int sdp3430_twl4030_init(struct snd_soc_codec *codec)
@@ -146,7 +153,8 @@ static int sdp3430_twl4030_init(struct snd_soc_codec *codec)
/* SDP3430 connected pins */
snd_soc_dapm_enable_pin(codec, Ext Mic);
snd_soc_dapm_enable_pin(codec, Ext Spk);
- snd_soc_dapm_disable_pin(codec, Headset Jack);
+ snd_soc_dapm_disable_pin(codec, Headset Mic);
+ snd_soc_dapm_disable_pin(codec, Headset Stereophone);
/* TWL4030 not connected pins */
snd_soc_dapm_nc_pin(codec, AUXL);
--
1.5.4.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
Re: dma_alloc_coherent fragmentation
Hi Nishant, From: ext Kamat, Nishant nska...@ti.com Subject: dma_alloc_coherent fragmentation Date: Wed, 18 Mar 2009 14:03:45 +0100 Forwarding on behalf of Nishanth Menon: -Original Message- From: Menon, Nishanth Sent: Tuesday, March 17, 2009 8:17 AM To: 'linux-arm-ker...@lists.arm.linux.org.uk' Cc: Gupta, Ramesh; Kevin Hilman; linux-omap@vger.kernel.org; Ramirez Luna, Omar; Kanigeri, Hari; Ameya Palande; Guzman Lugo, Fernando; Ameya Palande Subject: dma_alloc_coherent fragmentation Looping in linux-arm ML: Discussion Ref: [1](linux-omap mailing list) While working with Linux OMAP kernel[2] we found that on allocating 4 meg chunks using dma_alloc_coherent and de-allocating with dma_free_coherent in a loop using a test driver[7], the memory is getting fragmented as shown by Ameya's observation [3] finally resulting in dump_stack due to lack of pages. What would happen with __GFP_RECLAIMABLE for dma_alloc_coherent()? -- To unsubscribe from this list: send the line unsubscribe 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/86] OMAP2/3: clock sync with linux-omap
Hello Russell, On Thu, 12 Mar 2009, Kevin Hilman wrote: This is the series of patches contained in the 'omap-clks3' branch of Russell King's git repository[1]. Posted on behalf of Russell who had some mail issues in first attempt, and then ran of out time. This series is proposed to be merged into the next merge window. Comments to the list appreciated. I've spent some time reviewing these patches. Many of the changes you've implemented are an improvement over the previous code. Some of the patches would ordinarily prompt further comments and revision, but the benefit of merging these patches upstream in this merge window exceeds the benefit of further revision. So my preference would be to see this current set sent upstream for this merge window. regards, - 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: dma_alloc_coherent fragmentation
Hi Hiroshi, -Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Thursday, March 19, 2009 8:43 AM What would happen with __GFP_RECLAIMABLE for dma_alloc_coherent()? As per [1], GFP_TEMPORARY might be the right approach.. but yes, Changing dummy to do: dma_alloc_coherent(NULL, b[i].size, b[i].phy, GFP_TEMPORARY); Seems to resolve the issue with the dummy driver. The question however still remains: For a driver to allocate a memory which is not temporary in nature we'd recommend GFP_KERNEL. But as part of the exit sequence the driver will deallocate that memory and as part of init sequence, reallocate. Given that the memory is not reclaimed immediately, it looks like the only way to ensure that would be to do GFP_KERNEL | __GFP_RECLAIMABLE (which essentially is the definition of GFP_TEMPORARY). Regards, Nishanth Menon Ref: [1] http://lkml.indiana.edu/hypermail/linux/kernel/0705.2/0638.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 00/05] OMAP3: SR: Fixes in Smartreflex driver
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, March 18, 2009 9:59 PM To: Nayak, Rajendra Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 00/05] OMAP3: SR: Fixes in Smartreflex driver Nayak, Rajendra rna...@ti.com writes: Hi, This series fixes a set of defects/issues in Smartreflex driver. SR autocompensation is now functional and is validated with these patches on a ES3.1 based SDP with the N values in Efuse. Patches apply and are validated on the latest pm branch (2.6.28). Hi Rajendra, Thanks for this series of SR fixes. I send a couple very minor comments to a couple of the patches. Also, this series does not apply cleanly to pm-2.6.28, I'm not sure why. Applying manually with 'patch' allows them to apply with fuzz suggesting that they were not generated against the current tree. I usually pull from kernel.org. The latest commit on pm branch that's pulled from it shows me this.. commit 4f422d583e2e233c19eb20754b8cfad6ed9e460a Author: Nayak, Rajendra rna...@ti.com Date: Fri Feb 13 11:30:57 2009 +0530 OMAP3: PM: Update voltage levels for OPP1/2 on VDD1/2 ..which does look quite old. But so does gitweb. Is there some delta between kernel.org and your internal tree? Also, while you are in there cleaing up, could you add one more patch which converts the printk(KERN_* ...) into pr_debug, pr_err, pr_info, etc. Yes, I can add a patch to clean that up. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] ARM: OMAP: Add command line option for I2C bus speed
On Wed, 18 Mar 2009 20:30:45 +0100 ext Russell King - ARM Linux li...@arm.linux.org.uk wrote: I had similar thought as Felipe that it looks more generic this way. But don't know now immediately would multibuild will work? Was that your concern? E.g. __setup(i2c_bus=, arm_xxx_i2c_bus_setup); __setup(i2c_bus=, omap_i2c_bus_setup); Well is it generic enough to work for everybody? And if so, we should run it by the LKML and the linux-i2c lists. Any comments from the I2C list? Unfortunately not. Are there some conference or why the list have been so idle recently? http://marc.info/?l=linux-i2cr=1b=200903w=2 Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH] ASoC: Declare Headset as Mic and Headphone widgets for SDP3430
On Thu, Mar 19, 2009 at 01:07:34AM -0500, Lopez Cruz, Misael wrote: Headset was declared previously as a Headphone widget connecting HSMIC and HSOL/HSOR pins of TWL4030 codec in SDP430 machine driver. The capture path becomes invalid as the Headphone widget is not a valid input endpoint. Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
BT656 Support and MMDC support on top of OMAP3EVM
Hi, I am getting some private requests for supporting BT656 and Multi-Media Daughter card on top of latest Kernel + Sakari's latest ISP-Camera patches/repository. So I am posting the patch supporting BT656 and MMDC support with all the review comments fixed (received from earlier posts). Please note that, hence forth I will try to avoid submitting patches on top of V4L2-int framework. The next immediate activity would be migration to sub-device framework. Sakari, How about merging these patches (BT656 support patch) into your repository so that I don't have to maintain and re-submit the patches again and again. If you feel it should be done, then please let me know if you have any review comments I will try to fix immediately and provide you a patch. The patches are following this mail. Thanks, Vaibhav Hiremath -- To unsubscribe from this list: send the line unsubscribe 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/2 (V3)] OMAP3 ISP-Camera: Added BT656 support ontop of Sakari's repository
From: Vaibhav Hiremath hvaib...@ti.com
Support for BT656 through TVP5146 decoder, works on top of
Sakari's repository
http://git.gitorious.org/omap3camera/mainline.git
NOTE: Please note that, hence forth I will try to avoid submitting
patches on top of V4L2-int framework. The next immediate activity
should be migration to sub-device framework.
Tested:
- On OMAP3EVM + Multi-Media Daughter card
- NTSC and PAL standard
- S-Video and Composite input
TODO:
- Migration to sub-devide framework
- Support for Scaling and Cropping
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Hardik Shah hardik.s...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/isp/isp.c | 85 --
drivers/media/video/isp/isp.h |3 +-
drivers/media/video/isp/ispccdc.c | 119 +---
drivers/media/video/isp/ispccdc.h |9 ++
drivers/media/video/omap34xxcam.c | 179 +---
drivers/media/video/omap34xxcam.h |1 +
6 files changed, 357 insertions(+), 39 deletions(-)
diff --git a/drivers/media/video/isp/isp.c b/drivers/media/video/isp/isp.c
index 54c839b..18313b3 100644
--- a/drivers/media/video/isp/isp.c
+++ b/drivers/media/video/isp/isp.c
@@ -215,6 +215,7 @@ struct isp_irq {
* @resizer_input_height: ISP Resizer module input image height.
* @resizer_output_width: ISP Resizer module output image width.
* @resizer_output_height: ISP Resizer module output image height.
+ * @current_field: Current field for interlaced capture.
*/
struct isp_module {
unsigned int isp_pipeline;
@@ -232,6 +233,7 @@ struct isp_module {
unsigned int resizer_input_height;
unsigned int resizer_output_width;
unsigned int resizer_output_height;
+ int current_field;
};
#define RAW_CAPTURE(isp) \
@@ -258,6 +260,7 @@ static struct isp {
dma_addr_t tmp_buf;
size_t tmp_buf_size;
unsigned long tmp_buf_offset;
+ int bt656ifen;
struct isp_bufs bufs;
struct isp_irq irq;
struct isp_module module;
@@ -266,6 +269,8 @@ static struct isp {
/* Structure for saving/restoring ISP module registers */
static struct isp_reg isp_reg_list[] = {
{OMAP3_ISP_IOMEM_MAIN, ISP_SYSCONFIG, 0},
+ {OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0ENABLE, 0},
+ {OMAP3_ISP_IOMEM_MAIN, ISP_IRQ1ENABLE, 0},
{OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_GRESET_LENGTH, 0},
{OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_PSTRB_REPLAY, 0},
{OMAP3_ISP_IOMEM_MAIN, ISP_CTRL, 0},
@@ -800,7 +805,10 @@ int isp_configure_interface(struct isp_interface_config
*config)
isp_buf_init();
+ isp_obj.bt656ifen = 0;
switch (config-ccdc_par_ser) {
+ case ISP_PARLL_YUV_BT:
+ isp_obj.bt656ifen = 1;
case ISP_PARLL:
ispctrl_val |= ISPCTRL_PAR_SER_CLK_SEL_PARALLEL;
ispctrl_val |= config-u.par.par_clk_pol
@@ -885,8 +893,18 @@ static irqreturn_t omap34xx_isp_isr(int irq, void *_isp)
spin_lock_irqsave(bufs-lock, flags);
wait_hs_vs = bufs-wait_hs_vs;
- if (irqstatus HS_VS bufs-wait_hs_vs)
- bufs-wait_hs_vs--;
+ if (irqstatus HS_VS) {
+ if (bufs-wait_hs_vs)
+ bufs-wait_hs_vs--;
+ else {
+ if (isp_obj.module.pix.field == V4L2_FIELD_INTERLACED) {
+ isp_obj.module.current_field =
+ (isp_reg_readl(OMAP3_ISP_IOMEM_CCDC,
+ ISPCCDC_SYN_MODE)
+ ISPCCDC_SYN_MODE_FLDSTAT) ? 1 : 0;
+ }
+ }
+ }
spin_unlock_irqrestore(bufs-lock, flags);
spin_lock_irqsave(isp_obj.lock, irqflags);
@@ -898,6 +916,12 @@ static irqreturn_t omap34xx_isp_isr(int irq, void *_isp)
goto out_ignore_buff;
if (irqstatus CCDC_VD0) {
+ if (isp_obj.module.pix.field == V4L2_FIELD_INTERLACED) {
+ /* Skip even fields */
+ if (isp_obj.module.current_field == 0) {
+ goto out_ignore_buff;
+ }
+ }
if (RAW_CAPTURE(isp_obj))
isp_buf_process(bufs);
if (!ispccdc_busy())
@@ -1046,6 +1070,11 @@ out_ignore_buff:
}
#endif
+ /* TODO: Workaround suggested by Tony for spurious
+* interrupt issue
+ */
+ irqstatus = isp_reg_readl(OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
+
return IRQ_HANDLED;
}
@@ -1262,11 +1291,16 @@ static u32 isp_calc_pipeline(struct v4l2_pix_format
*pix_input,
isp_obj.module.isp_pipeline = OMAP_ISP_CCDC;
ispccdc_request();
if (pix_input-pixelformat == V4L2_PIX_FMT_SGRBG10
-
[PATCH 2/2 (V3)] OMAP3EVM Multi-Media Daughter Card Support
From: Vaibhav Hiremath hvaib...@ti.com This is Third version of OMAP3EVM Mulit-Media Daughter Card support. NOTE: Please note that, hence forth I will try to avoid submitting patches on top of V4L2-int framework. The next immediate activity would be migration to sub-device framework. Fixes: - Refreshed with Latest ISP-Camera patches - Comments from 'Tony Lindgren' - Comments from 'Alexey Klimov' TODO: - Need to migrate along with OMAP3-Camera Tested: - TVP5146 (BT656) decoder interface on top of Sakari's Git tree. http://git.gitorious.org/omap3camera/mainline.git - Capturing the frame to file and validate Signed-off-by: Brijesh Jadav brijes...@ti.com Signed-off-by: Hardik Shah hardik.s...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- arch/arm/mach-omap2/Kconfig |8 +- arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-omap3evm-mmdc-v4l.c | 351 + arch/arm/mach-omap2/board-omap3evm-mmdc.h | 42 +++ 4 files changed, 401 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap3evm-mmdc-v4l.c create mode 100644 arch/arm/mach-omap2/board-omap3evm-mmdc.h diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 8fa650d..8dadf2a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -113,7 +113,7 @@ config MACH_OMAP_LDP bool OMAP3 LDP board depends on ARCH_OMAP3 ARCH_OMAP34XX -config MACH_OMAP2EVM +config MACH_OMAP2EVM bool OMAP 2530 EVM board depends on ARCH_OMAP2 ARCH_OMAP24XX @@ -125,6 +125,12 @@ config MACH_OMAP3EVM bool OMAP 3530 EVM board depends on ARCH_OMAP3 ARCH_OMAP34XX +config MACH_OMAP3EVM_MMDC + bool OMAP 3530 EVM Multi-Media Daughter Card board + depends on MACH_OMAP3EVM + help + Set this if you've got a Multi-Media Daughter Card board. + config MACH_OMAP3_BEAGLE bool OMAP3 BEAGLE board depends on ARCH_OMAP3 ARCH_OMAP34XX diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 33b5aa8..715d0e4 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -58,6 +58,7 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \ mmc-twl4030.o \ board-omap3evm-flash.o \ twl4030-generic-scripts.o +obj-$(CONFIG_MACH_OMAP3EVM_MMDC) += board-omap3evm-mmdc-v4l.o obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \ mmc-twl4030.o \ twl4030-generic-scripts.o diff --git a/arch/arm/mach-omap2/board-omap3evm-mmdc-v4l.c b/arch/arm/mach-omap2/board-omap3evm-mmdc-v4l.c new file mode 100644 index 000..c00a731 --- /dev/null +++ b/arch/arm/mach-omap2/board-omap3evm-mmdc-v4l.c @@ -0,0 +1,351 @@ +/* + * arch/arm/mach-omap2/board-omap3evm-mmdc-v4l.c + * + * Driver for OMAP3 EVM Multi Media Daughter Card + * + * Copyright (C) 2008 Texas Instruments Inc + * Author: Vaibhav Hiremath hvaib...@ti.com + * + * Contributors: + * Anuj Aggarwal anuj.aggar...@ti.com + * Sivaraj R siva...@ti.com + * + * This package 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., 675 Mass Ave, Cambridge, MA 02139, USA. + * + */ + +#include linux/init.h +#include linux/i2c.h +#include linux/gpio.h +#include linux/videodev2.h + +#include mach/mux.h + +#include media/v4l2-int-device.h +#include media/tvp514x.h + +/* Include V4L2 ISP-Camera driver related header file */ +#include ../drivers/media/video/omap34xxcam.h +#include ../drivers/media/video/isp/ispreg.h + +#include board-omap3evm-mmdc.h + +#define MODULE_NAMEomap3evm-mmdc + +/* Macro Definitions */ + +/* GPIO pins */ +#define GPIO134_SEL_TVP_Y (134) +#define GPIO54_SEL_EXP_CAM (54) +#define GPIO136_SEL_CAM(136) + +/* board internal information (BEGIN) */ + +/* I2C bus to which all I2C slave devices are attached */ +#define BOARD_I2C_BUSNUM (3) + +/* I2C address of chips present in board */ +#define TVP5146_I2C_ADDR (0x5D) + +#if defined(CONFIG_VIDEO_TVP514X) || defined(CONFIG_VIDEO_TVP514X_MODULE) +#if defined(CONFIG_VIDEO_OMAP3) ||
RE: [PATCH 1/1] DSPBRIDGE: Set __GFP_RECLAIMABLE for reloading bridge module
-Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Thursday, March 19, 2009 11:38 AM To: Kanigeri, Hari Cc: Guzman Lugo, Fernando; ameya.pala...@nokia.com; Menon, Nishanth; Gupta, Ramesh; linux-omap@vger.kernel.org; Hiroshi DOYU Subject: [PATCH 1/1] DSPBRIDGE: Set __GFP_RECLAIMABLE for reloading bridge module To restart DSP system after DSP crash, reloading bridge module is necessary and a high order page allocation may fail after long use time because of memory fragmentation. To avoid this, mark it as reclaimable for immediate reloading. Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Thanks Hiroshi. Tested-by: Nishanth Menon n...@ti.com Test h/w: SDP3430. - OMAP3430 ES3.0 Test iteration: insmod ./bridgedriver.ko shm_size=0x40 phys_mempool_base=0 base_img=/lib/dsp/baseimage.dof rmmod bridgedriver -- Num iterations: 25K Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] DSPBRIDGE Fix flush_workque
-Original Message- From: Gupta, Ramesh Sent: Thursday, March 19, 2009 6:25 AM To: linux-omap@vger.kernel.org Cc: Menon, Nishanth; Kanigeri, Hari; Varide, Nischal; Guzman Lugo, Fernando Subject: [PATCH 1/1] DSPBRIDGE Fix flush_workque From a8aabc6233329998d0ac62be42ade5a77f03ef2a Mon Sep 17 00:00:00 2001 From: Ramesh Gupta x0023...@ti.com Date: Thu, 19 Mar 2009 09:56:30 +0530 Subject: [PATCH 1/1] DSPBRIDGE Fix flush_workque Observed some crash with flush_workque after multiple load and unload. Replaced flush_workque with destroy_workque Signed-off-by: Varide Nischal x0102...@ti.com Thanks Ramesh. Tested-by: Nishanth Menon n...@ti.com Test h/w: SDP3430. - OMAP3430 ES3.0 Test iteration: (bootargs mem=122M) ./bridgedriver.ko phys_mempool_base=0x87A0 phys_mempool_size=0x0060 base_img=dsp/baseimage.dof rmmod bridgedriver -- Num iterations: 30K Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH B 2/3] tidspbridge: cleanup and remove HW_MMU_TLBFlushAll
On Wed, Mar 18, 2009 at 3:26 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
From: Felipe Contreras felipe.contre...@nokia.com
It doesn't make sense to have layers and layers of constants and defines
to turn one bit on.
Signed-off-by: Felipe Contreras felipe.contre...@nokia.com
---
I thought a bit more about this:
+static inline void tlb_flush_all(const u32 base)
+{
+ __raw_writeb(__raw_readb(base + MMU_GFLUSH) | 1, base + MMU_GFLUSH);
+}
+
Originally it was the equivalent of __raw_writel(__raw_readl but since
we are dealing only with one bit I chose 'b' instead of 'l'. Is that
correct?
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] DSPBRIDGE: Set __GFP_RECLAIMABLE for reloading bridge module
To restart DSP system after DSP crash, reloading bridge module is
necessary and a high order page allocation may fail after long use
time because of memory fragmentation. To avoid this, mark it as
reclaimable for immediate reloading.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
drivers/dsp/bridge/services/mem.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/dsp/bridge/services/mem.c
b/drivers/dsp/bridge/services/mem.c
index 0a10304..3661fb1 100644
--- a/drivers/dsp/bridge/services/mem.c
+++ b/drivers/dsp/bridge/services/mem.c
@@ -357,9 +357,14 @@ void *MEM_AllocPhysMem(u32 cBytes, u32 ulAlign, OUT u32
*pPhysicalAddress)
if (extPhysMemPoolEnabled) {
pVaMem = MEM_ExtPhysMemAlloc(cBytes, ulAlign,
(u32 *)paMem);
- } else
- pVaMem = dma_alloc_coherent(NULL, cBytes, paMem,
- (in_atomic()) ? GFP_ATOMIC :
GFP_KERNEL);
+ } else {
+ gfp_t gfp = (in_atomic()) ? GFP_ATOMIC : GFP_KERNEL;
+
+ /* To ensure allocation at immediate reloading */
+ gfp |= __GFP_RECLAIMABLE;
+
+ pVaMem = dma_alloc_coherent(NULL, cBytes, paMem, gfp);
+ }
if (pVaMem == NULL) {
*pPhysicalAddress = 0;
GT_1trace(MEM_debugMask, GT_6CLASS,
--
1.5.6.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
Re: [PATCHv2] OMAP: McBSP: Always maintain McBSP fclk while active
On Wed, 18 Mar 2009 12:31:02 +0100 Nurkkala Eero.An (EXT-Offcode/Oulu) ext-eero.nurkk...@nokia.com wrote: From: Eero Nurkkala ext-eero.nurkk...@nokia.com McBSP fclk must be maintained for the duration of audio playback or recording. Otherwise the fclk may get autogated when the PER96M clk is no longer required by other modules. This results in audio activity being hang. Also, if the McBSP is run as a slave, it is possible that words are randomly missed from the playback. Fix all this phenomenom by enabling the McBSP fclk clockactivity bit for the entire active duration of the McBSP usage. Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com --- ... w = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON); - w = ~(ENAWAKEUP | SIDLEMODE(0x03)); - w |= (ENAWAKEUP | SIDLEMODE(0x02)); + w = ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY (0x03)); + w |= (ENAWAKEUP | SIDLEMODE(0x02) | CLOCKACTIVITY (0x02)); Based on updated TRM info: http://marc.info/?l=linux-omapm=123674373120880w=2 Acked-by: Jarkko Nikula jarkko.nik...@nokia.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
CAM / V4L2: OMAP3 camera issues
Hi everybody, I just wanted to ask if someone of you recently had a look at the camera driver for the ov3640 sensor included in the omap zoom 1 platform. As I'm a total noob in writing drivers I'm searching for someone to help me to get this device to work the right way because currently it's really a mess. Unfortunately our future work with the omap zoom heavily relies on having camera images in reasonable resolutions and reasonable quality, so for us there is no way around fixing at least some of these points: As far as I have seen there are several issues. The main problem is that it is only possible to use a very restricted number of image formats. One can use Bayer images in 1024x768 up to 2048x1536 pixels, and using the Bayer format is the only way to get RGB images actually. The much more appreciated YUYV and YVYU formats seem to be broken somehow, so nobody is known to me who was able to decode such an image into a reasonable color image yet. Lastly, a problem is that there is no way to control the exposure of the sensor, such that the images are all heavily over-exposed and there is no way known to me to change any setting to use auto-exposure (the feature is reported to be not available by v4l2). I'd be happy if someone could help me in fixing some of these problems. Regards Clemens -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
test
test -- To unsubscribe from this list: send the line unsubscribe 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: test
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto Sent: Thursday, March 19, 2009 4:51 PM To: linux-omap@vger.kernel.org Subject: test Aaah, Few folks hitting: Generating server: snip linux-omap@vger.kernel.org vger.kernel.org #vger.kernel.org #5.7.1 SMTP; 550 5.7.1 Content-Policy accept-into-freezer-1 msg: Bayes Statistical Bogofilter considers this message SPAM. BF:S 1 In case you disagree, send the ENTIRE message plus this error message to postmas...@vger.kernel.org ; S1758343AbZCRQ3X #SMTP# Anyone seen similar issues recently? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: CAM / V4L2: OMAP3 camera issues
Hi Clemens, I'm the one responsible for this driver, and the features that are added by now are pretty basical. Currently I'm a bit absorbed by other higher priority tasks, so I haven’t been able to update the driver as fast as I would want. We are working towards enhancing the driver so most of the features be available, but if you have some enhancement suggestion, I'll invite you to do so. I appreciate your time. Regards, Sergio -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Opel Fahrer Sent: Thursday, March 19, 2009 8:24 AM To: linux-omap@vger.kernel.org Subject: CAM / V4L2: OMAP3 camera issues Hi everybody, I just wanted to ask if someone of you recently had a look at the camera driver for the ov3640 sensor included in the omap zoom 1 platform. As I'm a total noob in writing drivers I'm searching for someone to help me to get this device to work the right way because currently it's really a mess. Unfortunately our future work with the omap zoom heavily relies on having camera images in reasonable resolutions and reasonable quality, so for us there is no way around fixing at least some of these points: As far as I have seen there are several issues. The main problem is that it is only possible to use a very restricted number of image formats. One can use Bayer images in 1024x768 up to 2048x1536 pixels, and using the Bayer format is the only way to get RGB images actually. The much more appreciated YUYV and YVYU formats seem to be broken somehow, so nobody is known to me who was able to decode such an image into a reasonable color image yet. Lastly, a problem is that there is no way to control the exposure of the sensor, such that the images are all heavily over-exposed and there is no way known to me to change any setting to use auto-exposure (the feature is reported to be not available by v4l2). I'd be happy if someone could help me in fixing some of these problems. Regards Clemens -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/12] ARM: OMAP3: Store reboot mode in scratchpad on OMAP34xx
* Russell King - ARM Linux li...@arm.linux.org.uk [090318 17:08]:
On Wed, Mar 18, 2009 at 01:10:04PM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [090318 12:26]:
On Wed, Mar 18, 2009 at 11:28:06AM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [090316 15:22]:
On Mon, Mar 16, 2009 at 07:40:24PM +0200, Juha Yrjola wrote:
Russell King - ARM Linux wrote:
Right. You are aware that there is already a mechanism for doing
this
in the generic kernel (obviously not)?
I am. Unfortunately, glibc fails to support this mechanism, as you
say.
I didn't want to start making such intrusive changes for our
trivial
need.
Yes, glibc sucks with that - they hide the Linux reboot syscall.
Luckily, it is accessible via the syscall() interface:
#include linux/reboot.h
int sys_reboot(const char *cmd)
{
return syscall(SYS_reboot, LINUX_REBOOT_MAGIC1,
LINUX_REBOOT_MAGIC2C,
LINUX_REBOOT_CMD_RESTART2, cmd);
}
sys_reboot() with LINUX_REBOOT_CMD_RESTART2 takes a string in
addition
to the standard parameters. This string is passed into
machine_restart()
which we currently ignore. If LINUX_REBOOT_CMD_RESTART is used,
this
string is NULL.
We could change machine_restart() to pass this parameter through to
arm_pm_restart() and ultimately down to arch_reset().
Sure. With RESTART2, I could've even used the reboot notifier chain
with
an OMAP3-specific driver to store the string.
The notifier chain is called in any case.
Are you suggesting to get rid of reboot_mode altogether? If not,
could
we still have the sysfs mechanism? A one-character reboot_mode
would be
plenty enough for us.
No, reboot mode tells _how_ to perform the reboot - whether that be
by hardware reset, gpio reset or a soft call via the reset address.
It's not supposed to tell the boot loader what to do.
So if the reboot mode can't be used for this.. Should we change Juha's
sysfs interface patch to store something else like bootloader_mode?
I guess we cannot use kexec for this either?
Why not use the mechanism that's already there as I've already pointed
out?
Sorry I misunderstood, I thought you did not want to use reboot_mode
for this at all..
I don't want to use reboot_mode for this. machine_restart() and the
reboot syscall has a way of passing a string to the platform specific
code, and I'm suggesting that if you want the boot loader to do some
magic, that's the way to do it. Use the 'cmd' argument provided to
arch_reset() by the patch below - this will either be NULL if the
standard reboot call is used, or a string if the alternative version
is used.
To recap, so we change machine_restart() like you described above, and then
this patch is still valid, except to update the description.
No, you've still got the wrong end of the stick.
snip
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 811be55..0a0d49a 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -97,8 +97,8 @@ extern void __show_regs(struct pt_regs *);
extern int cpu_architecture(void);
extern void cpu_init(void);
-void arm_machine_restart(char mode);
-extern void (*arm_pm_restart)(char str);
+void arm_machine_restart(char mode, const char *cmd);
+extern void (*arm_pm_restart)(char str, const char *cmd);
#define UDBG_UNDEFINED (1 0)
#define UDBG_SYSCALL (1 1)
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index af377c7..2de14e2 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -83,7 +83,7 @@ static int __init hlt_setup(char *__unused)
__setup(nohlt, nohlt_setup);
__setup(hlt, hlt_setup);
-void arm_machine_restart(char mode)
+void arm_machine_restart(char mode, const char *cmd)
{
/*
* Clean and disable cache, and turn off interrupts
@@ -100,7 +100,7 @@ void arm_machine_restart(char mode)
/*
* Now call the architecture specific reboot code.
*/
- arch_reset(mode);
+ arch_reset(mode, cmd);
/*
* Whoops - the architecture was unable to reboot.
@@ -120,7 +120,7 @@ EXPORT_SYMBOL(pm_idle);
void (*pm_power_off)(void);
EXPORT_SYMBOL(pm_power_off);
-void (*arm_pm_restart)(char str) = arm_machine_restart;
+void (*arm_pm_restart)(char str, const char *cmd) = arm_machine_restart;
EXPORT_SYMBOL_GPL(arm_pm_restart);
@@ -195,9 +195,9 @@ void machine_power_off(void)
pm_power_off();
}
-void machine_restart(char * __unused)
+void machine_restart(char *cmd)
{
- arm_pm_restart(reboot_mode);
+
Re: [PATCH 00/86] OMAP2/3: clock sync with linux-omap
* Paul Walmsley p...@pwsan.com [090319 01:57]: Hello Russell, On Thu, 12 Mar 2009, Kevin Hilman wrote: This is the series of patches contained in the 'omap-clks3' branch of Russell King's git repository[1]. Posted on behalf of Russell who had some mail issues in first attempt, and then ran of out time. This series is proposed to be merged into the next merge window. Comments to the list appreciated. I've spent some time reviewing these patches. Many of the changes you've implemented are an improvement over the previous code. Some of the patches would ordinarily prompt further comments and revision, but the benefit of merging these patches upstream in this merge window exceeds the benefit of further revision. So my preference would be to see this current set sent upstream for this merge window. Right on, looks good to me too. Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: CAM / V4L2: OMAP3 camera issues
Hi Sergio,
thanks for your fast reply, it's good to hear that someone already has the
issues in mind that I'm talking of. As I mentioned before I haven't done any
driver development by now, but maybe it's also a good chance to get a little
bit into that now. Currently the one and only real problem with the driver at
this time is that the YUYV and YVYU support seems to be broken - it's hard to
say because of the heavy over-exposure, but I guess there is something wrong in
a conversion or something simple like that. Fixing only this issue (and maybe
the auto-exposure) would give us everything we need. However, as soon as you
have some time to take a look at that feel free to contact me such that we can
further talk about these things.
Regards
Clemens
- Ursprüngliche Mail
Von: Aguirre Rodriguez, Sergio Alberto saagui...@ti.com
An: Opel Fahrer opelfahre...@yahoo.de; linux-omap@vger.kernel.org
linux-omap@vger.kernel.org
Gesendet: Donnerstag, den 19. März 2009, 16:02:48 Uhr
Betreff: RE: CAM / V4L2: OMAP3 camera issues
Hi Clemens,
I'm the one responsible for this driver, and the features that are added by now
are pretty basical.
Currently I'm a bit absorbed by other higher priority tasks, so I haven’t
been able to update the driver as fast as I would want.
We are working towards enhancing the driver so most of the features be
available, but if you have some enhancement suggestion, I'll invite you to do
so.
I appreciate your time.
Regards,
Sergio
-Original Message-
From: linux-omap-ow...@vger.kernel..org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Opel Fahrer
Sent: Thursday, March 19, 2009 8:24 AM
To: linux-o...@vger.kernel..org
Subject: CAM / V4L2: OMAP3 camera issues
Hi everybody,
I just wanted to ask if someone of you recently had a look at the camera
driver for the ov3640 sensor included in the omap zoom 1 platform. As I'm
a total noob in writing drivers I'm searching for someone to help me to
get this device to work the right way because currently it's really a mess.
Unfortunately our future work with the omap zoom heavily relies on having
camera images in reasonable resolutions and reasonable quality, so for us
there is no way around fixing at least some of these points:
As far as I have seen there are several issues. The main problem is that
it is only possible to use a very restricted number of image formats. One
can use Bayer images in 1024x768 up to 2048x1536 pixels, and using the
Bayer format is the only way to get RGB images actually. The much more
appreciated YUYV and YVYU formats seem to be broken somehow, so nobody is
known to me who was able to decode such an image into a reasonable color
image yet. Lastly, a problem is that there is no way to control the
exposure of the sensor, such that the images are all heavily over-exposed
and there is no way known to me to change any setting to use auto-exposure
(the feature is reported to be not available by v4l2).
I'd be happy if someone could help me in fixing some of these problems.
Regards
Clemens
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±¢f©Š{ayºÊ‡Ú™ë,j¢f£¢·hš‹àz¹®w¥¢¸¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾«‘êçzZ+ƒùšŽŠÝ¢j�ú!¶i
--
To unsubscribe from this list: send the line unsubscribe 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: [APPLIED] [PATCH omap-fixes v2] OMAP2/3: GPIO: do not attempt to wake-enable
* Kevin Hilman khil...@deeprootsystems.com [090319 09:44]: Tony Lindgren t...@atomide.com writes: This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 2ac496a208895c925aec1774a873b5b096b2d3f0 PatchWorks http://patchwork.kernel.org/patch/10719/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=2ac496a208895c925aec1774a873b5b096b2d3f0 Tony, $SUBJECT on this commit seems to have been a bit mangled leaving a not very clear commit log/history. Heh looks like bad html parsing :) I'll revert and re-apply. 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 2.6.29-rc8 regulator-next] regulator: init fixes (v4)
On Wed, Mar 18, 2009 at 02:14:14PM -0700, David Brownell wrote: On Wednesday 18 March 2009, Mark Brown wrote: I think it's more that I'm viewing the use count as being useful information which the API can take advantage of (do any consumers actually want this on right now?). In that case, I don't understand why you didn't like the previous versions of this patch ... which just forced the regulator off (at init time) if that count was zero. There are two issues which I raised in response to that patch. One is that this is a fairly substantial interface change which will affect existing constraints without warning and will therefore break people using the current code. At the minute you can't rely on boot_on being set for any regulator which is enabled when Linux starts. This is the most serious issue - a quick survey leads me to expect that turning off regulators without boot_on would break most existing systems somehow. The other is that I'm fairly sure that we'll end up running into systems where the setup at startup is not fixed and forcing the regulator state immediately on regulator registration is likely to cause problems dealing gracefully with such systems. You addressed that by adding devmode, though ideally that should have a clearer name. I think we should be able to handle this without changing the use count and that this is preferable because otherwise we make more work with shared consumers, which should be the simplest case. That's what the earlier versions of this patch did, but you rejected that approach ... patches against both mainline (which is where the bug hurts TODAY), and against regulator-next. I have given you two suggestions which will allow your MMC driver to use mainline without impacting other drivers. I've also provided some suggestions for how we could introduce changes in the regulator core to support this better. Also, I don't see why you'd think a shared consumer would be the simplest, given all the special rules that you've already noted as only needing to kick in for those cases. Simplest for the consumers - they just need to do a get followed by basic reference counting, they don't need to (and can't, really) worry about anything else. The trick is getting the non-shared regulators into sync with the internal status, I don't see why that should need any tricks. At init time you have that state and the regulator; and you know there are no consumers. Put it into Realistically we don't have that information at the minute. For the most part we have the physical state and we may also have some constraint information but we can't rely on the constraint information right now. The fact that we can't rely on the constraint information means that we can't tell if a regulator is enabled because something is using it at the minute or if it's just been left on because that was the default or similar. a self-consistent state at that time ... done. There are really only two ways to make that state self-consistent. And you have rejected both. Both of the approaches you have suggested change the interfaces and cause problems for existing users with no warning to allow them to transition. Changing the reference count does avoid the problems with powering things off but it causes other problems in doing so, ones that look harder to resolve. When looking at bringing the use count in sync with the physical state during startup we have to deal with the fact that we can't currently rely on having information about the desired state of the hardware at the time the regulator is registered. We need to make an API change of some kind to get that information. during init. ?I think either using regulator_force_disable() or saying The force_disable() thing looks to me like an API design botch. As you said at one point, it has no users. And since the entire point is to bypass the entire usecount scheme ... it'd be much better to remove it. As the documentation says it was originally added for error handling cases where there is a danger of hardware damage. In that situation you really do want to power off immediately without reference to any other state. that the consmer wants exclusive access on get and then bumping the use count for it if the regulator is already enabled ought to cover it. I've not thought the latter option through fully, though. The problem I have with your approach here is that you have rejected quite a few alternative bugfixes applying to a common (and simple!!) configuration, but you haven't provided an alternative that can work for MMC init. I have given you a number of suggestions which should work for MMC init. These are: - Have the MMC style consumers use regulator_force_disable() to disable an enabled regulator on startup. - Have the MMC style consumers do an enable()/disable() pair to disable an enabled regulator on startup. - Changing the way the new behaviours are
Re: [APPLIED] [PATCH omap-fixes v2] OMAP2/3: GPIO: do not attempt to wake-enable
On Thu, Mar 19, 2009 at 05:53:35PM +0100, Tony Lindgren wrote: * Kevin Hilman khil...@deeprootsystems.com [090319 09:44]: Tony Lindgren t...@atomide.com writes: This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 2ac496a208895c925aec1774a873b5b096b2d3f0 PatchWorks http://patchwork.kernel.org/patch/10719/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=2ac496a208895c925aec1774a873b5b096b2d3f0 Tony, $SUBJECT on this commit seems to have been a bit mangled leaving a not very clear commit log/history. Heh looks like bad html parsing :) I'll revert and re-apply. why do you even try to parse the html ?? patchworks hold it in mbox format: http://patchwork.kernel.org/patch/10719/mbox/ -- 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: [APPLIED] [PATCH omap-fixes v2] OMAP2/3: GPIO: do not attempt to wake-enable
* Tony Lindgren t...@atomide.com [090319 09:54]: * Kevin Hilman khil...@deeprootsystems.com [090319 09:44]: Tony Lindgren t...@atomide.com writes: This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 2ac496a208895c925aec1774a873b5b096b2d3f0 PatchWorks http://patchwork.kernel.org/patch/10719/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=2ac496a208895c925aec1774a873b5b096b2d3f0 Tony, $SUBJECT on this commit seems to have been a bit mangled leaving a not very clear commit log/history. Heh looks like bad html parsing :) I'll revert and re-apply. Seems like a bug in pwclient.. $ pwclient get 10719 Shows the subject in the patch as: Subject: [omap-fixes, v2] OMAP2/3: GPIO: do not attempt to wake-enable GPIO bank IRQ 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: [APPLIED] [PATCH omap-fixes v2] OMAP2/3: GPIO: do not attempt to wake-enable
On Thu, Mar 19, 2009 at 10:16:33AM -0700, Tony Lindgren wrote: Seems like a bug in pwclient.. $ pwclient get 10719 Shows the subject in the patch as: Subject: [omap-fixes, v2] OMAP2/3: GPIO: do not attempt to wake-enable GPIO bank IRQ $ curl http://patchwork.kernel.org/patch/10719/mbox | git am -s would do the trick :-p -- 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] twl4030-regulator: expose VPLL2
On Mon, 2009-03-16 at 15:51 +, Mark Brown wrote: On Fri, Mar 13, 2009 at 05:54:54PM -0700, David Brownell wrote: From: David Brownell dbrown...@users.sourceforge.net Add VPLL2 to the set of twl4030-family regulators exposed for use by various drivers. It's commonly used to power the digital video outputs (e.g. LCD or DVI displays) on OMAP3 systems. Signed-off-by: David Brownell dbrown...@users.sourceforge.net Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Samuel, I've applied this to the regulator tree as the part that touches mfd is relatively minor and twl4030 specific (doesn't touch core). Thanks Liam -- To unsubscribe from this list: send the line unsubscribe 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.6.29-rc8 regulator-next] regulator: init fixes (v4)
On Wed, Mar 18, 2009 at 02:02:14PM -0700, David Brownell wrote: Huh? $SUBJECT patch hasn't merged. How could you have backed it out?? Sorry - another patch introducing a version of the same issue. Your patch: http://git.kernel.org/?p=linux/kernel/git/lrg/voltage-2.6.git;a=commit;h=67130ef073299cc7299d3ffa344122959e97753c bumped the refcount for boot_on regulators. This patch: http://git.kernel.org/?p=linux/kernel/git/lrg/voltage-2.6.git;a=commit;h=504e7d7e42fb3a58809946770ff5e07cc9d52dbf backs out that change only. This was my bad on the review. -- To unsubscribe from this list: send the line unsubscribe 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 B 3/3] tidspbridge: decreate timeout to a saner value
Hi Felipe,
I am seeing with this patch because of the timeout:
DSP device detected !!
DSPProcessor_Attach succeeded.
dspbridge: timed out waiting for mailbox
dspbridge: timed out waiting for mailbox
dspbridge: timed out waiting for mailbox
dspbridge: timed out waiting for mailbox
dspbridge: timed out waiting for mailbox
dspbridge: timed out waiting for mailbox
dspbridge: timed out waiting for mailbox
dspbridge: timed out waiting for mailbox
dspbridge: timed out waiting for mailbox
dspbridge: timed out waiting for mailbox
dspbridge: timed out waiting for mailbox
...
Did you see any issue when you change to 1ms? Maybe we can use a bigger timeout.
Please let me know your comments.
Regards,
Fernando.
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Tuesday, March 17, 2009 7:27 PM
To: linux-omap@vger.kernel.org
Cc: Kanigeri, Hari; Hiroshi DOYU; Ameya Palande; Guzman Lugo, Fernando; Felipe
Contreras
Subject: [PATCH B 3/3] tidspbridge: decreate timeout to a saner value
From: Felipe Contreras felipe.contre...@nokia.com
Signed-off-by: Felipe Contreras felipe.contre...@nokia.com
---
drivers/dsp/bridge/wmd/tiomap_sm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/tiomap_sm.c
b/drivers/dsp/bridge/wmd/tiomap_sm.c
index 1b31162..535dc13 100644
--- a/drivers/dsp/bridge/wmd/tiomap_sm.c
+++ b/drivers/dsp/bridge/wmd/tiomap_sm.c
@@ -144,7 +144,7 @@ DSP_STATUS CHNLSM_InterruptDSP2(struct WMD_DEV_CONTEXT
*pDevContext,
pDevContext-dwBrdState = BRD_RUNNING;
}
- timeout = jiffies + msecs_to_jiffies(10);
+ timeout = jiffies + msecs_to_jiffies(1);
while (fifo_full((void __iomem *) resources.dwMboxBase, 0)) {
if (time_after(jiffies, timeout)) {
printk(KERN_ERR dspbridge: timed out waiting for
mailbox\n);
--
1.6.2.1.287.g9a8be
--
To unsubscribe from this list: send the line unsubscribe 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 B 3/3] tidspbridge: decreate timeout to a saner value
On Thu, Mar 19, 2009 at 10:42 PM, Guzman Lugo, Fernando x0095...@ti.com wrote: Hi Felipe, I am seeing with this patch because of the timeout: DSP device detected !! DSPProcessor_Attach succeeded. dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox ... Did you see any issue when you change to 1ms? Maybe we can use a bigger timeout. Did you apply patch #1 of the B series? I didn't see any timeout on my tests. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH B 3/3] tidspbridge: decreate timeout to a saner value
Yes, I applied this; in fact I have applied all the patches. If I increase the timeout there are no problems. The test I run creates 4 process and each one does several a lot of calls to InputChnl and OutputChnl, so I think this test is using the mailbox a lot and would be better a bigger timeout. What do you think? Regards, Fernando. -Original Message- From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Sent: Thursday, March 19, 2009 3:04 PM To: Guzman Lugo, Fernando Cc: linux-omap@vger.kernel.org; Kanigeri, Hari; Hiroshi DOYU; Ameya Palande; Felipe Contreras Subject: Re: [PATCH B 3/3] tidspbridge: decreate timeout to a saner value On Thu, Mar 19, 2009 at 10:42 PM, Guzman Lugo, Fernando x0095...@ti.com wrote: Hi Felipe, I am seeing with this patch because of the timeout: DSP device detected !! DSPProcessor_Attach succeeded. dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox dspbridge: timed out waiting for mailbox ... Did you see any issue when you change to 1ms? Maybe we can use a bigger timeout. Did you apply patch #1 of the B series? I didn't see any timeout on my tests. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH B 3/3] tidspbridge: decreate timeout to a saner value
On Thu, Mar 19, 2009 at 11:19 PM, Guzman Lugo, Fernando x0095...@ti.com wrote: Yes, I applied this; in fact I have applied all the patches. If I increase the timeout there are no problems. The test I run creates 4 process and each one does several a lot of calls to InputChnl and OutputChnl, so I think this test is using the mailbox a lot and would be better a bigger timeout. What do you think? How fast are these messages sent? Can you track down which functions are calling CHNLSM_InterruptDSP2 and making these timeouts happen. I think it's safe to leave the timeout at 10, but that means it's possible the code will be busy-looping up to 10 ms which will increase the CPU load. Somebody from Nokia (Siarhei?) suggested to idle-wait for the mbox empty irq, I think that's the best way to implement this, but at least for the use cases I'm interested in (video encoding/decoding) timeouts don't seem to be an issue anymore. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Back-light class driver support for OMAP
On Wednesday 18 March 2009, hvaib...@ti.com wrote: + +#if defined(CONFIG_TWL4030_CORE) + twl4030_i2c_write_u8(TWL4030_MODULE_LED, 0x11, TWL4030_LED_EN); + twl4030_i2c_write_u8(TWL4030_MODULE_PWMA, c, TWL_PWMA_PWMAOFF); +#endif Hmm, I think I'm going to have to get off my butt and send in the PWM patches I have ... they work for the PWMs on the two LED outputs, but not yet for the two other PWM-equipped pins (GPIO-6, GPIO-7) - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH B 3/3] tidspbridge: decreate timeout to a saner value
This is a stress test, it creates 4 processes and each process will do 1000 transfers using streams, so the trace is: STRM_Issue - WMD_CHNL_AddIOReq - IO_Schedule IO_Schedule schedules a call to IO_DPC using task let. IO_DPC - IO_DispatchChnl - InputChnl - CHNLSM_InterruptDSP2 Also IO_DispatchChnl - OutputChnl - CHNLSM_InterruptDSP2. As we can call a lot CHNLSM_InterruptDSP2 in this test, there is a problem with the timeout. However running other tests, videos and mp3 there no problems. I think we should change to 10ms, only to make sure there is no problem when CHNLSM_InterruptDSP2 is called a lot. Let me know if you are agreed. Or have some comments about it. Regards, Fernando. -Original Message- From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Sent: Thursday, March 19, 2009 3:35 PM To: Guzman Lugo, Fernando Cc: linux-omap@vger.kernel.org; Kanigeri, Hari; Hiroshi DOYU; Ameya Palande; Felipe Contreras Subject: Re: [PATCH B 3/3] tidspbridge: decreate timeout to a saner value On Thu, Mar 19, 2009 at 11:19 PM, Guzman Lugo, Fernando x0095...@ti.com wrote: Yes, I applied this; in fact I have applied all the patches. If I increase the timeout there are no problems. The test I run creates 4 process and each one does several a lot of calls to InputChnl and OutputChnl, so I think this test is using the mailbox a lot and would be better a bigger timeout. What do you think? How fast are these messages sent? Can you track down which functions are calling CHNLSM_InterruptDSP2 and making these timeouts happen. I think it's safe to leave the timeout at 10, but that means it's possible the code will be busy-looping up to 10 ms which will increase the CPU load. Somebody from Nokia (Siarhei?) suggested to idle-wait for the mbox empty irq, I think that's the best way to implement this, but at least for the use cases I'm interested in (video encoding/decoding) timeouts don't seem to be an issue anymore. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH B 3/3] tidspbridge: decreate timeout to a saner value
On Fri, Mar 20, 2009 at 2:00 AM, Guzman Lugo, Fernando x0095...@ti.com wrote: This is a stress test, it creates 4 processes and each process will do 1000 transfers using streams, so the trace is: STRM_Issue - WMD_CHNL_AddIOReq - IO_Schedule IO_Schedule schedules a call to IO_DPC using task let. IO_DPC - IO_DispatchChnl - InputChnl - CHNLSM_InterruptDSP2 Also IO_DispatchChnl - OutputChnl - CHNLSM_InterruptDSP2. As we can call a lot CHNLSM_InterruptDSP2 in this test, there is a problem with the timeout. However running other tests, videos and mp3 there no problems. I think we should change to 10ms, only to make sure there is no problem when CHNLSM_InterruptDSP2 is called a lot. Let me know if you are agreed. Or have some comments about it. Well again, the best way to implement the wait for a slot in the mailbox is with interrupts, not busy-looping. If we busy-loop too much that would increase the CPU usage, and that would be bad. That's why I want to use the 1ms timeout; to find issues that cause increase in CPU load. But for now I think 10ms is the safest, as it's the current value. If somebody wants to pin-point issues, then the timeout should be decreased. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Some possible missing v4l2_subdev IOCTLs.
Hi Hans, I did a quick analysis of the subdev, and noticed that some video ioctls for the subdevices aren't there... [gs]_crop [gs]_parm enum_frameintervals enum_framesizes enum_fmt_cap I noticed this because we currently use them for a best sensor output selection before sending the image to the OMAP3 ISP. Any particular reason why these aren't there? Regards, Sergio -- To unsubscribe from this list: send the line unsubscribe 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] OMAP3 clock: Access only available clock bits
Hi All,
I found a problem on PM Branch with OMAP3430 ES3.1 Board when enabling
OMAP_RESET_CLOCKS feature.
In clk_disable_unsed() function, as soon as sad2d_ick is disabled,
prcm interrupt is generated and its handler can't exit loop at next
statement!
while (prm_read_mod_reg(OCP_MOD, OMAP2_PRM_IRQSTATUS_MPU_OFFSET));
I also found that sad2d_ick is available only OMAP3430 ES1. I fixed
this problem with below patch.
Your better solutions or comments appreciated.
Sincerely,
Kyuwon
--
This patch prevents setting or clearing reserved bits of 'Clock Enable
Register', in the clk_disable_unused() function. Especially, this
patch prevents using the sad2d_ick which doesn't exist in OMAP3430
ES2+.
Signed-off-by: Kim Kyuwon q1@samsung.com
---
arch/arm/mach-omap2/clock34xx.h |2 +-
arch/arm/plat-omap/clock.c | 10 ++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index e0dd7f3..039f7dd 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -1279,7 +1279,7 @@ static struct clk sad2d_ick = {
.prcm_mod = CORE_MOD,
.enable_reg = CM_ICLKEN1,
.enable_bit = OMAP3430_EN_SAD2D_SHIFT,
- .flags = CLOCK_IN_OMAP343X,
+ .flags = CLOCK_IN_OMAP3430ES1,
.clkdm = { .name = d2d_clkdm },
.recalc = followparent_recalc,
};
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 2eed047..b16c6c3 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -775,6 +775,16 @@ static int __init clk_disable_unused(void)
if (cpu_class_is_omap1() ck-enable_reg == 0)
continue;
+ if (cpu_is_omap34xx()) {
+ if ((omap_rev() == OMAP3430_REV_ES1_0)
+ (ck-flags CLOCK_IN_OMAP3430ES2))
+ continue;
+
+ /* In this case, board Rev. is greater then ES1 */
+ if (ck-flags CLOCK_IN_OMAP3430ES1)
+ continue;
+ }
+
spin_lock_irqsave(clockfw_lock, flags);
if (arch_clock-clk_disable_unused)
arch_clock-clk_disable_unused(ck);
--
1.5.2.5
--
To unsubscribe from this list: send the line unsubscribe 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 B 3/3] tidspbridge: decreate timeout to a saner value
From: ext Felipe Contreras felipe.contre...@gmail.com Subject: Re: [PATCH B 3/3] tidspbridge: decreate timeout to a saner value Date: Fri, 20 Mar 2009 01:06:16 +0100 On Fri, Mar 20, 2009 at 2:00 AM, Guzman Lugo, Fernando x0095...@ti.com wrote: This is a stress test, it creates 4 processes and each process will do 1000 transfers using streams, so the trace is: STRM_Issue - WMD_CHNL_AddIOReq - IO_Schedule IO_Schedule schedules a call to IO_DPC using task let. IO_DPC - IO_DispatchChnl - InputChnl - CHNLSM_InterruptDSP2 Also IO_DispatchChnl - OutputChnl - CHNLSM_InterruptDSP2. As we can call a lot CHNLSM_InterruptDSP2 in this test, there is a problem with the timeout. However running other tests, videos and mp3 there no problems. I think we should change to 10ms, only to make sure there is no problem when CHNLSM_InterruptDSP2 is called a lot. Let me know if you are agreed. Or have some comments about it. Well again, the best way to implement the wait for a slot in the mailbox is with interrupts, not busy-looping. If we busy-loop too much that would increase the CPU usage, and that would be bad. I think that s/w queuing of messages would be more efficient to allow multiple senders to continue thier work anyway, especially in the case of having these streamings. That's why I want to use the 1ms timeout; to find issues that cause increase in CPU load. But for now I think 10ms is the safest, as it's the current value. If somebody wants to pin-point issues, then the timeout should be decreased. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] V4L2 driver for OMAP2/3 with new CIDs.
Hi All, I will be posting series of three patches for the V4L2 driver on the OMAP2/3 DSS. Patch 1 - This is the second revision of the patch. Documentation added for the following new CIDs and bit fields added in V4L2 framework. V4L2_CID_BG_COLOR: Added new CID for setting of the back ground color on the output device. V4L2_CID_ROTATION: Added new CID for setting up of the rotation on the device. Both of the above ioctls are discussed in detail. V4L2_FBUF_FLAG_SRC_CHROMAKEY: Added the flags bit field to the flags field of the v4l2_framebuffer structure for supporting the source chroma keying. It's exactly opposite of the chroma keying supported with the flag V4L2_FBUF_FLAG_CHROMAKEY. V4L2_FBUF_CAP_SRC_CHROMAKEY: Added the capability bit field for the capability field of the v4l2_framebuffer structure. Documentation change related to the new bit field for the source chroma keying is new from the previous version. Patch 2 - Added New Control IDs for OMAP class of Devices as discussed above. This is the third revision of the patch of adding the new control IDs and bit fields. V4L2_FBUF_CAP_SRC_CHROMAKEY and V4L2_FBUF_FLAG_SRC_CHROMAKEY are newly added compared to previous revision of patch. New Ioctl for programming the color space conversion matrix is dropped from this patch as the accompanying driver with this patch is not still having implementation for the same. Related documentation is also removed. I will submit a separate patch for that with the necessary changes in driver to support the programming of the color space conversion. Some changes are required in DSS2 library also for doing the same. Patch 3 - This is a review patch since the DSS2 library is still to be accepted in community This is the third revision of the patch. This patch contains the V4L2 driver on the OMAP3 DSS2 using all of the above newly implemented CIDS and bit fields. Following are the changes in the driver compared to the previous version. 1. Added the chroma keying support. 2. Added alpha blending support. 3. Minor community comment fixed. 4. Ported to work with Tomi's latest DSS2 library with minor modification in DSS2 library. Path to Tomi's DSS2 library is http://www.bat.org/~tomba/git/linux-omap-dss.git/ commit id bc6dc4c7fabb8ba3bfe637a6c5dc271595a1bef6 All the comments and inputs are welcomed. Thanks and Regards Hardik Shah -- To unsubscribe from this list: send the line unsubscribe 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] Documentation for new V4L2 CIDs added.
1. Updated for V4L2_CID_BG_COLOR 2. Updated for V4L2_CID_ROTATION Both of the above are discussed in length with community 3. Updated for new flags and capability field added to v4l2_frame buffer structure. Signed-off-by: Brijesh Jadav brijes...@ti.com Signed-off-by: Hardik Shah hardik.s...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- v4l2-spec/controls.sgml | 19 ++- v4l2-spec/vidioc-g-fbuf.sgml | 19 +++ 2 files changed, 37 insertions(+), 1 deletions(-) diff --git a/v4l2-spec/controls.sgml b/v4l2-spec/controls.sgml index 477a970..79e2c28 100644 --- a/v4l2-spec/controls.sgml +++ b/v4l2-spec/controls.sgml @@ -281,10 +281,27 @@ minimum value disables backlight compensation./entry constantV4L2_COLORFX_SEPIA/constant (2)./entry /row row + entryconstantV4L2_CID_ROTATION/constant/entry + entryinteger/entry + entryRotates the image by specified angle. Common angles are 90, 270, +and 180. Rotating the image to 90 and 270 will reverse the height and width of +the display window. Its is necessary to set the new height and width of the picture +using S_FMT ioctl see xref linkend=vidioc-g-fmt according to the rotation angle selected/entry + /row + row + entryconstantV4L2_CID_BG_COLOR/constant/entry + entryinteger/entry + entrySets the background color on the current output device. +Background color needs to be specified in the RGB24 format. The supplied 32 +bit value is intepreted as Bits 0-7 Red color information, Bits 8-15 Green color +information, Bits 16-23 Blue color information and Bits 24-31 must be +zero./entry + /row + row entryconstantV4L2_CID_LASTP1/constant/entry entry/entry entryEnd of the predefined control IDs (currently -constantV4L2_CID_COLORFX/constant + 1)./entry +constantV4L2_CID_BG_COLOR/constant + 1)./entry /row row entryconstantV4L2_CID_PRIVATE_BASE/constant/entry diff --git a/v4l2-spec/vidioc-g-fbuf.sgml b/v4l2-spec/vidioc-g-fbuf.sgml index 6781b53..27d1e29 100644 --- a/v4l2-spec/vidioc-g-fbuf.sgml +++ b/v4l2-spec/vidioc-g-fbuf.sgml @@ -336,6 +336,13 @@ alpha value. Alpha blending makes no sense for destructive overlays./entry inverted alpha channel of the framebuffer or VGA signal. Alpha blending makes no sense for destructive overlays./entry /row + row + entryconstantV4L2_FBUF_CAP_SRC_CHROMAKEY/constant/entry + entry0x0080/entry + entryThe device supports source chorma keying. Framebuffer +images will be replaced by the video images. Exactly +opposite of constantV4L2_FBUF_CAP_CHROMAKEY/constant/entry + /row /tbody /tgroup /table @@ -411,6 +418,18 @@ images, but with an inverted alpha value. The blend function is: output = framebuffer pixel * (1 - alpha) + video pixel * alpha. The actual alpha depth depends on the framebuffer pixel format./entry /row + row + entryconstantV4L2_FBUF_FLAG_SRC_CHROMAKEY/constant/entry + entry0x0040/entry + entryUse chroma-keying. The chroma-key color is +determined by the structfieldchromakey/structfield field of +v4l2-window; and negotiated with the VIDIOC-S-FMT; ioctl, see xref +linkend=overlay and xref linkend=osd. +Since any one of the chorma keying can be active at a time as both +of them are exactly opposite same structfieldchromakey/structfield +field of v4l2-window; can be used to set the chroma key for source +keying also./entry + /row /tbody /tgroup /table -- 1.5.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] New V4L2 CIDs for OMAP class of Devices.
Added V4L2_CID_BG_COLOR for background color setting.
Added V4L2_CID_ROTATION for rotation setting.
Above two ioclts are indepth discussed. Posting
again with the driver usage.
V4L2 supports chroma keying added new flags for the
source chroma keying which is exactly opposite of the
chorma keying supported by V4L2. In current implementation
video data is replaced by the graphics buffer data for some
specific color. While for the source chroma keying grahics
data is replaced by the video data for some specific color.
Both are exactly opposite so are mutually exclusive
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Hardik Shah hardik.s...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
linux/drivers/media/video/v4l2-common.c |7 +++
linux/include/linux/videodev2.h |6 +-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/linux/drivers/media/video/v4l2-common.c
b/linux/drivers/media/video/v4l2-common.c
index 3c42316..fa408f0 100644
--- a/linux/drivers/media/video/v4l2-common.c
+++ b/linux/drivers/media/video/v4l2-common.c
@@ -422,6 +422,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_CHROMA_AGC: return Chroma AGC;
case V4L2_CID_COLOR_KILLER: return Color Killer;
case V4L2_CID_COLORFX: return Color Effects;
+ case V4L2_CID_ROTATION: return Rotation;
+ case V4L2_CID_BG_COLOR: return Background color;
/* MPEG controls */
case V4L2_CID_MPEG_CLASS: return MPEG Encoder Controls;
@@ -547,6 +549,10 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32
min, s32 max, s32 ste
qctrl-flags |= V4L2_CTRL_FLAG_READ_ONLY;
min = max = step = def = 0;
break;
+ case V4L2_CID_BG_COLOR:
+qctrl-type = V4L2_CTRL_TYPE_INTEGER;
+step = 1;
+break;
default:
qctrl-type = V4L2_CTRL_TYPE_INTEGER;
break;
@@ -571,6 +577,7 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32
min, s32 max, s32 ste
case V4L2_CID_BLUE_BALANCE:
case V4L2_CID_GAMMA:
case V4L2_CID_SHARPNESS:
+ case V4L2_CID_BG_COLOR:
qctrl-flags |= V4L2_CTRL_FLAG_SLIDER;
break;
case V4L2_CID_PAN_RELATIVE:
diff --git a/linux/include/linux/videodev2.h b/linux/include/linux/videodev2.h
index 2c83935..592d1c8 100644
--- a/linux/include/linux/videodev2.h
+++ b/linux/include/linux/videodev2.h
@@ -548,6 +548,7 @@ struct v4l2_framebuffer {
#define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010
#define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020
#define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040
+#define V4L2_FBUF_CAP_SRC_CHROMAKEY0x0080
/* Flags for the 'flags' field. */
#define V4L2_FBUF_FLAG_PRIMARY 0x0001
#define V4L2_FBUF_FLAG_OVERLAY 0x0002
@@ -555,6 +556,7 @@ struct v4l2_framebuffer {
#define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008
#define V4L2_FBUF_FLAG_GLOBAL_ALPHA0x0010
#define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020
+#define V4L2_FBUF_FLAG_SRC_CHROMAKEY 0x0040
struct v4l2_clip {
struct v4l2_rectc;
@@ -882,6 +884,8 @@ enum v4l2_power_line_frequency {
#define V4L2_CID_CHROMA_AGC (V4L2_CID_BASE+29)
#define V4L2_CID_COLOR_KILLER (V4L2_CID_BASE+30)
#define V4L2_CID_COLORFX (V4L2_CID_BASE+31)
+#define V4L2_CID_ROTATION (V4L2_CID_BASE+32)
+#define V4L2_CID_BG_COLOR (V4L2_CID_BASE+33)
enum v4l2_colorfx {
V4L2_COLORFX_NONE = 0,
V4L2_COLORFX_BW = 1,
@@ -889,7 +893,7 @@ enum v4l2_colorfx {
};
/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+32)
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+34)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
--
1.5.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
