RE: [RFD] frame-size switching: preview / single-shot use-case
Adding Manjunath Hadli to the list... Murail -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Tuesday, February 15, 2011 12:34 PM To: Linux Media Mailing List Cc: Qing Xu; Hans Verkuil; Neil Johnson; Robert Jarzmik; Uwe Taeubert; Karicheri, Muralidharan; Eino-Ville Talvala Subject: [RFD] frame-size switching: preview / single-shot use-case Hi This topic has been slightly discussed several times [1] before, but there has been no conclusion, nor I'm aware of any implementation, suitably resolving this problem. I've added to CC all involved in earlier discussions, that I managed to find. What seems a typical use-case to me is a system with a vewfinder or a display, providing a live preview of the video data from a source, like a camera, with a relatively low resolution, and a possibility to take high-resolution still photos with a very short delay. Currently this is pretty difficult to realise, e.g., with soc-camera drivers you have to free the videobuf(2) queue, by either closing and re-opening the interface, or by issuing an ioctl(VIDIOC_REQBUFS, count=0) if your driver is already using videobuf2 and if this is really working;), configure with a different resolution and re-allocate videobuffers (or use different buffers, allocated per USERPTR). Another possibility would be to allocate and use buffers large enough for still photos, also for the preview, which would be wasteful, because one can well need many more preview than still-shot buffers. So, it seems to me, we could live with a better solution. 1. We could use separate inputs for different capture modes and support per-input videobuf queues. Advantage: no API changes required. Disadvantages: confusing, especially, if a driver already exports multiple inputs. The driver does not know, whether this mode is required or not, always exporting 2 inputs for this purpose doesn't seem like a good idea. Eventually, the user might want not 2, but 3 or more of such videobuf queues. 2. Use different IO methods, e.g., mmap() for preview and read() for still shots. I'm just mentioning this possibility here, because it occurred in one of previous threads, but I don't really like it either. What if you want to use the same IO method for all? Etc. 3. Not liking either of the above, it seems we need yet a new API for this... How about extending VIDIOC_REQBUFS with a videobuf queue index, thus using up one of the remaining two 32-bit reserved fields? Then we need one more ioctl() like VIDIOC_BUFQ_SELECT to switch from one queue to another, after which setting frame format and queuing and dequeuing buffers will affect this currently selected queue. We could also keep REQBUFS as is and require BUFQ_SELECT to be called before it for any queue except the default 0. Yes, I know, that some video sensors have a double register set for this dual-format operation, so, for them it is natural to support two queues, and drivers are certainly most welcome to use this feature for, say, the first two queues. On other sensors and for any further queues switching will have to be done in software. Ideas? Comments? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 7/7] davinci vpbe: Readme text for Dm6446 vpbe
Manju, Could you review the Document? I think it is not updated to reflect the latest status: + Current status:- + + A build tested version of vpbe controller is available. I guess you have already tested this using the v4l2 driver. + v4l2 driver +- A version is already developed which is to be cleaned up and unit tested Ditto. v4l2 driver is already tested, right? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Manjunath Hadli Sent: Wednesday, December 15, 2010 4:12 AM To: LMML Cc: dlos; Mauro Carvalho Chehab; Hans Verkuil; Hadli, Manjunath Subject: [PATCH v6 7/7] davinci vpbe: Readme text for Dm6446 vpbe Please refer to this file for detailed documentation of davinci vpbe v4l2 driver Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Acked-by: Muralidharan Karicheri m-kariche...@ti.com Acked-by: Hans Verkuil hverk...@xs4all.nl --- Documentation/video4linux/README.davinci-vpbe | 100 + 1 files changed, 100 insertions(+), 0 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe diff --git a/Documentation/video4linux/README.davinci-vpbe b/Documentation/video4linux/README.davinci-vpbe new file mode 100644 index 000..3ff2dc3 --- /dev/null +++ b/Documentation/video4linux/README.davinci-vpbe @@ -0,0 +1,100 @@ + +VPBE V4L2 driver design + == + + File partitioning + - + V4L2 display device driver + drivers/media/video/davinci/vpbe_display.c + drivers/media/video/davinci/vpbe_display.h + + VPBE display controller + drivers/media/video/davinci/vpbe.c + drivers/media/video/davinci/vpbe.h + + VPBE venc sub device driver + drivers/media/video/davinci/vpbe_venc.c + drivers/media/video/davinci/vpbe_venc.h + drivers/media/video/davinci/vpbe_venc_regs.h + + VPBE osd driver + drivers/media/video/davinci/vpbe_osd.c + drivers/media/video/davinci/vpbe_osd.h + drivers/media/video/davinci/vpbe_osd_regs.h + + Functional partitioning + --- + + Consists of the following (in the same order as the list under file + partitioning):- + + 1. V4L2 display driver +Implements video2 and video3 device nodes and +provides v4l2 device interface to manage VID0 and VID1 layers. + + 2. Display controller +Loads up venc, osd and external encoders such as ths8200. It provides +a set of API calls to V4L2 drivers to set the output/standards +in the venc or external sub devices. It also provides +a device object to access the services from osd sub device +using sub device ops. The connection of external encoders to venc LCD +controller port is done at init time based on default output and standard +selection or at run time when application change the output through +V4L2 IOCTLs. + +When connetected to an external encoder, vpbe controller is also responsible +for setting up the interface between venc and external encoders based on +board specific settings (specified in board-xxx-evm.c). This allows +interfacing external encoders such as ths8200. The setup_if_config() +is implemented for this as well as configure_venc() (part of the next patch) +API to set timings in venc for a specific display resolution. As of this +patch series, the interconnection and enabling ans setting of the external +encoders is not present, and would be a part of the next patch series. + + 3. Venc subdevice +Responsible for setting outputs provided through internal dacs and also +setting timings at LCD controller port when external encoders are connected +at the port or LCD panel timings required. When external encoder/LCD panel +is connected, the timings for a specific standard/preset is retrieved from +the board specific table and the values are used to set the timings in +venc using non-standard timing mode. + +Support LCD Panel displays using the venc. For example to support a Logic +PD display, it requires setting up the LCD controller port with a set of +timings for the resolution supported and setting the dot clock. So we could +add the available outputs as a board specific entry (i.e add the LogicPD +output name to board-xxx-evm.c). A table of timings for various LCDs +supported can be maintained in the board specific setup file to support +various LCD displays. + + 4. osd subdevice +Osd subdevice implements all osd layer management and hardware specific +features. In the legacfy drivers (LSPxxx), the hardware specific features +are configured through proprietary IOCTLs at the fb device interface. Since +subdevices are going to support device nodes, application will be able +to configure the hardware
RE: [PATCH v6 5/7] davinci vpbe: platform specific additions
Sergei, I think the DM644x EVM board changes should be in a separate patch. Any reason? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Sergei Shtylyov Sent: Wednesday, December 15, 2010 6:20 AM To: Hadli, Manjunath Cc: dlos; Mauro Carvalho Chehab; LMML Subject: Re: [PATCH v6 5/7] davinci vpbe: platform specific additions Hello. On 15-12-2010 12:11, Manjunath Hadli wrote: This patch implements the overall device creation for the Video display driver, and addition of tables for the mode and output list. Signed-off-by: Manjunath Hadlimanjunath.ha...@ti.com Acked-by: Muralidharan Karicherim-kariche...@ti.com Acked-by: Hans Verkuilhverk...@xs4all.nl [...] diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach- davinci/board-dm644x-evm.c index 34c8b41..e9b1243 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c I think the DM644x EVM board changes should be in a separate patch. WBR, Sergei ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 0/6] davinci vpbe: dm6446 v4l2 driver
Manju, 2. Fixed Murali's comments on moving davinci_vpbe_readme.txt to different patch different patch or path? My comment was to move the documentation to Documentation folder. But it is still in it's original path :( Manjunath Hadli (6): davinci vpbe: V4L2 display driver for DM644X SoC davinci vpbe: VPBE display driver davinci vpbe: OSD(On Screen Display) block davinci vpbe: VENC( Video Encoder) implementation davinci vpbe: platform specific additions davinci vpbe: Build infrastructure for VPBE driver arch/arm/mach-davinci/board-dm644x-evm.c | 79 +- arch/arm/mach-davinci/dm644x.c | 164 ++- arch/arm/mach-davinci/include/mach/dm644x.h|4 + drivers/media/video/davinci/Kconfig| 22 + drivers/media/video/davinci/Makefile |2 + .../media/video/davinci/davinci_vpbe_readme.txt| 100 + drivers/media/video/davinci/vpbe.c | 837 drivers/media/video/davinci/vpbe_display.c | 2099 drivers/media/video/davinci/vpbe_osd.c | 1211 +++ drivers/media/video/davinci/vpbe_osd_regs.h| 389 drivers/media/video/davinci/vpbe_venc.c| 574 ++ drivers/media/video/davinci/vpbe_venc_regs.h | 189 ++ include/media/davinci/vpbe.h | 186 ++ include/media/davinci/vpbe_display.h | 146 ++ include/media/davinci/vpbe_osd.h | 397 include/media/davinci/vpbe_types.h | 93 + include/media/davinci/vpbe_venc.h | 38 + 17 files changed, 6511 insertions(+), 19 deletions(-) create mode 100644 drivers/media/video/davinci/davinci_vpbe_readme.txt create mode 100644 drivers/media/video/davinci/vpbe.c create mode 100644 drivers/media/video/davinci/vpbe_display.c create mode 100644 drivers/media/video/davinci/vpbe_osd.c create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h create mode 100644 drivers/media/video/davinci/vpbe_venc.c create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h create mode 100644 include/media/davinci/vpbe.h create mode 100644 include/media/davinci/vpbe_display.h create mode 100644 include/media/davinci/vpbe_osd.h create mode 100644 include/media/davinci/vpbe_types.h create mode 100644 include/media/davinci/vpbe_venc.h ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 2/6] davinci vpbe: VPBE display driver
Acked-by Muralidharan Karicheri m-kariche...@ti.com
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hadli, Manjunath
Sent: Thursday, December 02, 2010 7:39 AM
To: LMML
Cc: dlos; Mauro Carvalho Chehab; Hans Verkuil; Hadli, Manjunath; Karicheri,
Muralidharan
Subject: [PATCH v3 2/6] davinci vpbe: VPBE display driver
This patch implements the coe functionality of the dislay driver,
mainly controlling the VENC and other encoders, and acting as
the one point interface for the man V4L2 driver.This implements
the cre of each of the V4L2 IOCTLs.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/vpbe.c | 847
include/media/davinci/vpbe.h | 186
2 files changed, 1033 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe.c
create mode 100644 include/media/davinci/vpbe.h
diff --git a/drivers/media/video/davinci/vpbe.c
b/drivers/media/video/davinci/vpbe.c
new file mode 100644
index 000..96c0eea
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe.c
@@ -0,0 +1,847 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/string.h
+#include linux/wait.h
+#include linux/time.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/clk.h
+#include linux/err.h
+
+#include media/v4l2-device.h
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe.h
+#include media/davinci/vpss.h
+
+
+#define VPBE_DEFAULT_OUTPUT Composite
+#define VPBE_DEFAULT_MODE ntsc
+
+static char *def_output = VPBE_DEFAULT_OUTPUT;
+static char *def_mode = VPBE_DEFAULT_MODE;
+static struct osd_state *osd_device;
+static struct venc_platform_data *venc_device;
+static int debug;
+
+module_param(def_output, charp, S_IRUGO);
+module_param(def_mode, charp, S_IRUGO);
+module_param(debug, int, 0644);
+
+MODULE_PARM_DESC(def_output, vpbe output name (default:Composite));
+MODULE_PARM_DESC(ef_mode, vpbe output mode name (default:ntsc);
+MODULE_PARM_DESC(debug, Debug level 0-1);
+
+MODULE_DESCRIPTION(TI DMXXX VPBE Display controller);
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Texas Instruments);
+
+/**
+ * vpbe_current_encoder_info - Get config info for current encoder
+ * @vpbe_dev - vpbe device ptr
+ *
+ * Return ptr to current encoder config info
+ */
+static struct encoder_config_info*
+vpbe_current_encoder_info(struct vpbe_device *vpbe_dev)
+{
+ struct vpbe_display_config *vpbe_config = vpbe_dev-cfg;
+ int index = vpbe_dev-current_sd_index;
+ return ((index == 0) ? vpbe_config-venc :
+ vpbe_config-ext_encoders[index-1]);
+}
+
+/**
+ * vpbe_find_encoder_sd_index - Given a name find encoder sd index
+ *
+ * @vpbe_config - ptr to vpbe cfg
+ * @output_index - index used by application
+ *
+ * Return sd index of the encoder
+ */
+static int vpbe_find_encoder_sd_index(struct vpbe_display_config
*vpbe_config,
+ int index)
+{
+ char *encoder_name = vpbe_config-outputs[index].subdev_name;
+ int i;
+
+ /* Venc is always first */
+ if (!strcmp(encoder_name, vpbe_config-venc.module_name))
+ return 0;
+
+ for (i = 0; i vpbe_config-num_ext_encoders; i++) {
+ if (!strcmp(encoder_name,
+ vpbe_config-ext_encoders[i].module_name))
+ return i+1;
+ }
+ return -EINVAL;
+}
+
+/**
+ * vpbe_g_cropcap - Get crop capabilities of the display
+ * @vpbe_dev - vpbe device ptr
+ * @cropcap - cropcap is a ptr to struct v4l2_cropcap
+ *
+ * Update the crop capabilities in crop cap for current
+ * mode
+ */
+static int vpbe_g_cropcap(struct vpbe_device *vpbe_dev,
+struct v4l2_cropcap *cropcap)
+{
+ if (NULL == cropcap)
+ return -EINVAL;
+ cropcap-bounds.left = 0;
+ cropcap-bounds.top = 0;
+ cropcap-bounds.width = vpbe_dev-current_timings.xres;
+ cropcap-bounds.height = vpbe_dev-current_timings.yres
RE: [PATCH 4/6] davinci vpbe: VENC( Video Encoder) implementation
Acked-by Muralidharan Karicheri m-kariche...@ti.com
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hadli, Manjunath
Sent: Thursday, December 02, 2010 7:39 AM
To: LMML
Cc: dlos; Mauro Carvalho Chehab; Hans Verkuil; Hadli, Manjunath; Karicheri,
Muralidharan
Subject: [PATCH 4/6] davinci vpbe: VENC( Video Encoder) implementation
This patch adds the VENC or the Video encoder, whichis responsible
for the blending of al source planes and timing generation for Video
modes like NTSC, PAL and other digital outputs. the VENC implementation
currently supports COMPOSITE and COMPONENT outputs and NTSC and PAL
resolutions through the analog DACs. The venc block is implemented
as a subdevice, allowing for additional extenal and internal encoders
of other kind to plug-in.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/vpbe_venc.c | 574
++
drivers/media/video/davinci/vpbe_venc_regs.h | 189 +
include/media/davinci/vpbe_venc.h| 38 ++
3 files changed, 801 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe_venc.c
create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
create mode 100644 include/media/davinci/vpbe_venc.h
diff --git a/drivers/media/video/davinci/vpbe_venc.c
b/drivers/media/video/davinci/vpbe_venc.c
new file mode 100644
index 000..bf30332
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_venc.c
@@ -0,0 +1,574 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307
USA
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/ctype.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+#include linux/slab.h
+
+#include mach/hardware.h
+#include mach/mux.h
+#include mach/io.h
+#include mach/i2c.h
+
+#include linux/io.h
+
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe_venc.h
+#include media/davinci/vpss.h
+#include media/v4l2-device.h
+
+#include vpbe_venc_regs.h
+
+#define MODULE_NAME VPBE_VENC_SUBDEV_NAME
+
+static int debug = 2;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, Debug level 0-2);
+
+struct venc_state {
+ struct v4l2_subdev sd;
+ struct venc_callback *callback;
+ struct venc_platform_data *pdata;
+ struct device *pdev;
+ u32 output;
+ v4l2_std_id std;
+ spinlock_t lock;
+ void __iomem *venc_base;
+ void __iomem *vdaccfg_reg;
+};
+
+static inline struct venc_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct venc_state, sd);
+}
+
+static inline u32 venc_read(struct v4l2_subdev *sd, u32 offset)
+{
+ struct venc_state *venc = to_state(sd);
+
+ return __raw_readl(venc-venc_base + offset);
+}
+
+static inline u32 venc_write(struct v4l2_subdev *sd, u32 offset, u32 val)
+{
+ struct venc_state *venc = to_state(sd);
+ __raw_writel(val, (venc-venc_base + offset));
+ return val;
+}
+
+static inline u32 venc_modify(struct v4l2_subdev *sd, u32 offset,
+ u32 val, u32 mask)
+{
+ u32 new_val = (venc_read(sd, offset) ~mask) | (val mask);
+
+ venc_write(sd, offset, new_val);
+ return new_val;
+}
+
+static inline u32 vdaccfg_write(struct v4l2_subdev *sd, u32 val)
+{
+ struct venc_state *venc = to_state(sd);
+
+ __raw_writel(val, venc-vdaccfg_reg);
+
+ val = __raw_readl(venc-vdaccfg_reg);
+ return val;
+}
+
+/* This function sets the dac of the VPBE for various outputs
+ */
+static int venc_set_dac(struct v4l2_subdev *sd, u32 out_index)
+{
+ int ret = 0;
+
+ switch (out_index) {
+ case 0:
+ v4l2_dbg(debug, 1, sd, Setting output to Composite\n);
+ venc_write(sd, VENC_DACSEL, 0);
+ break;
+ case 1:
+ v4l2_dbg(debug, 1, sd, Setting output to S-Video\n);
+ venc_write(sd, VENC_DACSEL, 0x210);
+ break;
+ case 2:
+ venc_write(sd, VENC_DACSEL, 0x543
RE: [PATCH v3 5/6] davinci vpbe: platform specific additions
-Original Message-
From: Hadli, Manjunath
Sent: Thursday, December 02, 2010 7:39 AM
To: LMML
Cc: dlos; Mauro Carvalho Chehab; Hans Verkuil; Hadli, Manjunath; Karicheri,
Muralidharan
Subject: [PATCH v3 5/6] davinci vpbe: platform specific additions
This patch implements the overall device creation for the Video
display driver, and addition of tables for the mode and output list
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
arch/arm/mach-davinci/board-dm644x-evm.c| 79 +++--
arch/arm/mach-davinci/dm644x.c | 164
++-
arch/arm/mach-davinci/include/mach/dm644x.h |4 +
3 files changed, 228 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-
davinci/board-dm644x-evm.c
index 34c8b41..e9b1243 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -166,18 +166,6 @@ static struct platform_device
davinci_evm_nandflash_device = {
.resource = davinci_evm_nandflash_resource,
};
-static u64 davinci_fb_dma_mask = DMA_BIT_MASK(32);
-
-static struct platform_device davinci_fb_device = {
- .name = davincifb,
- .id = -1,
- .dev = {
- .dma_mask = davinci_fb_dma_mask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- },
- .num_resources = 0,
-};
-
static struct tvp514x_platform_data tvp5146_pdata = {
.clk_polarity = 0,
.hs_polarity = 1,
@@ -606,8 +594,71 @@ static void __init evm_init_i2c(void)
i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
}
+#define VENC_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* venc standards timings */
+static struct vpbe_enc_mode_info vbpe_enc_std_timings[] = {
+ {ntsc, VPBE_ENC_STD, {V4L2_STD_525_60}, 1, 720, 480,
+ {11, 10}, {3, 1001}, 0x79, 0, 0x10, 0, 0, 0, 0},
+ {pal, VPBE_ENC_STD, {V4L2_STD_625_50}, 1, 720, 576,
+ {54, 59}, {25, 1}, 0x7E, 0, 0x16, 0, 0, 0, 0},
+};
+
+/* venc dv preset timings */
+static struct vpbe_enc_mode_info vbpe_enc_preset_timings[] = {
+ {480p59_94, VPBE_ENC_DV_PRESET, {V4L2_DV_480P59_94}, 0, 720, 480,
+ {1, 1}, {5994, 100}, 0x80, 0, 0x20, 0, 0, 0, 0},
+ {576p50, VPBE_ENC_DV_PRESET, {V4L2_DV_576P50}, 0, 720, 576,
+ {1, 1}, {50, 1}, 0x7E, 0, 0x30, 0, 0, 0, 0},
+};
+
+/*
+ * The outputs available from VPBE + ecnoders. Keep the
+ * the order same as that of encoders. First that from venc followed by
that
+ * from encoders. Index in the output refers to index on a particular
encoder.
+ * Driver uses this index to pass it to encoder when it supports more than
+ * one output. Application uses index of the array to set an output.
+ */
+static struct vpbe_output dm644x_vpbe_outputs[] = {
+ {
+ .output = {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_OUTPUT_TYPE_ANALOG,
+ .std = VENC_STD_ALL,
+ .capabilities = V4L2_OUT_CAP_STD,
+ },
+ .subdev_name = VPBE_VENC_SUBDEV_NAME,
+ .default_mode = ntsc,
+ .num_modes = ARRAY_SIZE(vbpe_enc_std_timings),
+ .modes = vbpe_enc_std_timings,
+ },
+ {
+ .output = {
+ .index = 1,
+ .name = Component,
+ .type = V4L2_OUTPUT_TYPE_ANALOG,
+ .capabilities = V4L2_OUT_CAP_PRESETS,
+ },
+ .subdev_name = VPBE_VENC_SUBDEV_NAME,
+ .default_mode = 480p59_94,
+ .num_modes = ARRAY_SIZE(vbpe_enc_preset_timings),
+ .modes = vbpe_enc_preset_timings,
+ },
+};
+
+static struct vpbe_display_config vpbe_display_cfg = {
+ .module_name = dm644x-vpbe-display,
+ .i2c_adapter_id = 1,
+ .osd = {
+ .module_name = VPBE_OSD_SUBDEV_NAME,
+ },
+ .venc = {
+ .module_name = VPBE_VENC_SUBDEV_NAME,
+ },
+ .num_outputs = ARRAY_SIZE(dm644x_vpbe_outputs),
+ .outputs = dm644x_vpbe_outputs,
+};
static struct platform_device *davinci_evm_devices[] __initdata = {
- davinci_fb_device,
rtc_dev,
};
@@ -620,6 +671,8 @@ davinci_evm_map_io(void)
{
/* setup input configuration for VPFE input devices */
dm644x_set_vpfe_config(vpfe_cfg);
+ /* setup configuration for vpbe devices */
+ dm644x_set_vpbe_display_config(vpbe_display_cfg);
dm644x_init();
}
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-
davinci/dm644x.c
index 5e5b0a7..e8b8e94 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -640,6 +640,142 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)
vpfe_capture_dev.dev.platform_data = cfg;
}
+static struct resource dm644x_osd_resources
RE: [PATCH v3 6/6] davinci vpbe: Build infrastructure for VPBE driver
Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hadli, Manjunath Sent: Thursday, December 02, 2010 7:40 AM To: LMML Cc: dlos; Mauro Carvalho Chehab; Hans Verkuil; Hadli, Manjunath; Karicheri, Muralidharan Subject: [PATCH v3 6/6] davinci vpbe: Build infrastructure for VPBE driver This patch adds the build infra-structure for Davinci VPBE dislay driver Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- drivers/media/video/davinci/Kconfig| 22 + drivers/media/video/davinci/Makefile |2 + .../media/video/davinci/davinci_vpbe_readme.txt| 100 3 files changed, 124 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/davinci_vpbe_readme.txt diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 6b19540..dab32d5 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -91,3 +91,25 @@ config VIDEO_ISIF To compile this driver as a module, choose M here: the module will be called vpfe. + +config VIDEO_DM644X_VPBE +tristate DM644X VPBE HW module +select VIDEO_VPSS_SYSTEM + select VIDEOBUF_DMA_CONTIG +help + Enables VPBE modules used for display on a DM644x + SoC. + + To compile this driver as a module, choose M here: the + module will be called vpbe. + + +config VIDEO_VPBE_DISPLAY +tristate VPBE V4L2 Display driver +select VIDEO_DM644X_VPBE +default y +help + Enables VPBE V4L2 Display driver on a DMXXX device + + To compile this driver as a module, choose M here: the + module will be called vpbe_display. diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index a379557..ae7dafb 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -16,3 +16,5 @@ obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o obj-$(CONFIG_VIDEO_ISIF) += isif.o +obj-$(CONFIG_VIDEO_DM644X_VPBE) += vpbe.o vpbe_osd.o vpbe_venc.o +obj-$(CONFIG_VIDEO_VPBE_DISPLAY) += vpbe_display.o diff --git a/drivers/media/video/davinci/davinci_vpbe_readme.txt b/drivers/media/video/davinci/davinci_vpbe_readme.txt new file mode 100644 index 000..e7aabba --- /dev/null +++ b/drivers/media/video/davinci/davinci_vpbe_readme.txt @@ -0,0 +1,100 @@ + I think this doesn't belong to davinci folder. Consider moving this to Documentation folder where v4l2 documentations are available. +VPBE V4L2 driver design + == + + File partitioning + - + V4L2 display device driver + drivers/media/video/davinci/vpbe_display.c + drivers/media/video/davinci/vpbe_display.h + + VPBE display controller + drivers/media/video/davinci/vpbe.c + drivers/media/video/davinci/vpbe.h + + VPBE venc sub device driver + drivers/media/video/davinci/vpbe_venc.c + drivers/media/video/davinci/vpbe_venc.h + drivers/media/video/davinci/vpbe_venc_regs.h + + VPBE osd driver + drivers/media/video/davinci/vpbe_osd.c + drivers/media/video/davinci/vpbe_osd.h + drivers/media/video/davinci/vpbe_osd_regs.h + + Functional partitioning + --- + + Consists of following (in the same order as the list under file + partitioning):- + + 1. V4L2 display driver +Implements video2 and video3 device nodes and +provides v4l2 device interface to manage VID0 and VID1 layers. + + 2. Display controller +Loads up venc, osd and external encoders such as ths8200. It provides +a set of API calls to V4L2 drivers to set the output/standards +in the venc or external sub devices. It also provides +a device object to access the services from osd sub device +using sub device ops. The connection of external encoders to venc LCD +controller port is done at init time based on default output and standard +selection or at run time when application change the output through +V4L2 IOCTLs. + +When connetected to an external encoder, vpbe controller is also responsible +for setting up the interface between venc and external encoders based on +board specific settings (specified in board-xxx-evm.c). This allowes +interfacing external encoders such as ths8200. The setup_if_config() +is implemented for this as well as configure_venc() (part of the next patch) +API to set timings in venc for a specific display resolution.As of this +patch series, the interconnection and enabling ans setting of the external +encoders
RE: [PATCH v5 0/3] Multi-planar video format and buffer support for the V4L2 API
Snip
struct v4l2_format {
enum v4l2_buf_type type;
union {
struct v4l2_pix_format pix; /*
V4L2_BUF_TYPE_VIDEO_CAPTURE */
+ struct v4l2_pix_format_mplane pix_mp; /*
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE */
struct v4l2_window win; /*
V4L2_BUF_TYPE_VIDEO_OVERLAY */
struct v4l2_vbi_format vbi; /*
V4L2_BUF_TYPE_VBI_CAPTURE */
struct v4l2_sliced_vbi_format sliced; /*
V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */
__u8raw_data[200]; /* user-defined */
} fmt;
};
For the new buffer types mp_pix member is chosen. For those buffer types,
struct v4l2_pix_format_mplane is used:
Typo. replae mp_pix with pix_mp
/**
* struct v4l2_pix_format_mplane - multiplanar format definition
* @width: image width in pixels
* @height: image height in pixels
* @pixelformat:little endian four character code (fourcc)
* @field: field order (for interlaced video)
* @colorspace: supplemental to pixelformat
* @plane_fmt: per-plane information
* @num_planes: number of planes for this format and number of
valid
Snip
7. Format conversion
--
v4l2 core ioctl handling includes a simple conversion layer that allows
translation - when possible - between multi-planar and single-planar APIs,
transparently to drivers and applications.
The table below summarizes conversion behavior for cases when driver and
application use different API versions:
---
| Application MP -- Driver SP -- Application MP
G_FMT |always OK | always OK
S_FMT |-EINVAL | always OK
TRY_FMT |-EINVAL | always OK
---
| Application SP -- Driver MP -- Application SP
G_FMT |always OK | -EBUSY
S_FMT |always OK | -EBUSY and WARN()
TRY_FMT |always OK | -EBUSY and WARN()
What is the logic behind using -EBUSY for this? Why not -EINVAL? Also why use
WARN()?
Legend:
- SP - single-planar API used (NOT format!)
- MP - multi-planar API used (NOT format!)
- always OK - conversion is always valid irrespective of number of planes
- -EINVAL - if an MP application tries to TRY or SET a format with more
than 1 plane, EINVAL is returned from the conversion function
(of course, 1-plane multi-planar formats work and are
converted)
- -EBUSY - if an MP driver returns a more than 1-plane format to an SP
application, the conversion layer returns EBUSY to the
application;
this is useful in cases when the driver is currently set to a
more
than 1-plane format, SP application would not be able to
understand
it)
- -EBUSY and WARN() - there is only one reason for which SET or TRY from an
SP
application would result in a driver returning a more than 1-
plane
format - when the driver adjusts a 1-plane format to a more than
1-plane format. This should not happen and is a bug in driver,
hence
a WARN_ON(). Application receives EBUSY.
Suppose, S_FMT/TRY_FMT is called with UYVY format and driver supports only NV12
(2 plane) only, then for
Application SP -- Driver MP -- Application SP
I guess in this case, new drivers that supports multi-plane format would have
to return old NV12 format code (for backward compatibility). Is
this handled by driver or translation layer?
Application MP -- Driver SP -- Application MP
In this case, new driver would return new NV12 format code and have no issue.
Not sure what translation layer does in this scenario.
snip
===
V. Using ioctl()s and mmap()
===
* Format calls (VIDIOC_S/TRY/G_FMT) are converted transparently across APIs
by the ioctl handling code, where possible. Conversion from single-planar
to multi-planar cannot fail, but the other way around is possible only
for
1-plane formats.
Possible errors in conversion are described below.
Could you explain what you mean by conversion of formats? The idea of the
translation layer functionality is not clear to me. An example would help.
Murali
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [SAMPLE v2 04/12] v4l-subdev: Add pads operations
Laurent, Thanks for clarifying this. I guess this will also get documented in the v4l2 specs (if not already done) as part of this patch. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Monday, July 26, 2010 12:13 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; sakari.ai...@maxwell.research.nokia.com Subject: Re: [SAMPLE v2 04/12] v4l-subdev: Add pads operations On Friday 23 July 2010 17:56:02 Karicheri, Muralidharan wrote: Laurent, Could you explain the probe and active usage using an example such as below? Link1Link2 input sensor - ccdc - video node. Assume Link2 we can have either format 1 or format 2 for capture. Sure. The probe and active formats are used to probe supported formats and getting/setting active formats. * Enumerating supported formats on the CCDC input and output would be done with the following calls ENUM_FMT(CCDC input pad) for the input, and S_FMT(PROBE, CCDC input pad, format) ENUM_FMT(CCDC output pad) for the output. Setting the probe format on the input pad is required, as the format on an output pad usually depends on the format on input pads. * Trying a format on the CCDC input and output would be done with S_FMT(PROBE, CCDC input pad, format) for the input, and S_FMT(PROBE, CCDC input pad, format) S_FMT(PROBE, CCDC output pad, format) on the output. The S_FMT call will mangle the format given format if it can't be supported exactly, so there's no need to call G_FMT after S_FMT (a G_FMT call following a S_FMT call will return the same format as the S_FMT call). * Setting the active format is done with S_FMT(ACTIVE, CCDC input pad, format) S_FMT(ACTIVE, CCDC output pad, format) The formats will be applied to the hardware (possibly with a delay, drivers can delay register writes until STREAMON for instance). Probe formats are stored in the subdev file handles, so two applications trying formats at the same time will not interfere with each other. Active formats are stored in the device structure, so modifications done by an application are visible to other applications. Hope this helps clarifying the API. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [SAMPLE v2 04/12] v4l-subdev: Add pads operations
Laurent,
Could you explain the probe and active usage using an example such as
below?
Link1Link2
input sensor - ccdc - video node.
Assume Link2 we can have either format 1 or format 2 for capture.
Thanks.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
Sent: Wednesday, July 21, 2010 10:42 AM
To: linux-media@vger.kernel.org
Cc: sakari.ai...@maxwell.research.nokia.com
Subject: [SAMPLE v2 04/12] v4l-subdev: Add pads operations
Add a v4l2_subdev_pad_ops structure for the operations that need to be
performed at the pad level such as format-related operations.
The format at the output of a subdev usually depends on the format at
its input(s). The try format operation is thus not suitable for probing
format at individual pads, as it can't modify the device state and thus
can't remember the format probed at the input to compute the output
format.
To fix the problem, pass an extra argument to the get/set format
operations to select the 'probe' or 'active' format.
The probe format is used when probing the subdev. Setting the probe
format must not change the device configuration but can store data for
later reuse. Data storage is provided at the file-handle level so
applications probing the subdev concurently won't interfere with each
other.
The active format is used when configuring the subdev. It's identical to
the format handled by the usual get/set operations.
Pad format-related operations use v4l2_mbus_framefmt instead of
v4l2_format.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/media/v4l2-subdev.h | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 01b4135..684ab60 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -41,6 +41,7 @@ struct v4l2_device;
struct v4l2_event_subscription;
struct v4l2_fh;
struct v4l2_subdev;
+struct v4l2_subdev_fh;
struct tuner_setup;
/* decode_vbi_line */
@@ -398,6 +399,25 @@ struct v4l2_subdev_ir_ops {
struct v4l2_subdev_ir_parameters *params);
};
+enum v4l2_subdev_format {
+ V4L2_SUBDEV_FORMAT_PROBE = 0,
+ V4L2_SUBDEV_FORMAT_ACTIVE = 1,
+};
+
+struct v4l2_subdev_pad_ops {
+ int (*enum_mbus_code)(struct v4l2_subdev *sd, struct v4l2_subdev_fh
*fh,
+struct v4l2_subdev_pad_mbus_code_enum *code);
+ int (*enum_frame_size)(struct v4l2_subdev *sd,
+ struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_frame_size_enum *fse);
+ int (*get_fmt)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
+ unsigned int pad, struct v4l2_mbus_framefmt *fmt,
+ enum v4l2_subdev_format which);
+ int (*set_fmt)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
+ unsigned int pad, struct v4l2_mbus_framefmt *fmt,
+ enum v4l2_subdev_format which);
+};
+
struct v4l2_subdev_ops {
const struct v4l2_subdev_core_ops *core;
const struct v4l2_subdev_tuner_ops *tuner;
@@ -406,6 +426,7 @@ struct v4l2_subdev_ops {
const struct v4l2_subdev_vbi_ops*vbi;
const struct v4l2_subdev_ir_ops *ir;
const struct v4l2_subdev_sensor_ops *sensor;
+ const struct v4l2_subdev_pad_ops*pad;
};
#define V4L2_SUBDEV_NAME_SIZE 32
--
1.7.1
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH 1/6] v4l: subdev: Don't require core operations
Laurent,
This is a good fix. For example, soc based sub devices may not
have core ops implemented.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
Sent: Wednesday, July 07, 2010 7:53 AM
To: linux-media@vger.kernel.org
Cc: sakari.ai...@maxwell.research.nokia.com
Subject: [RFC/PATCH 1/6] v4l: subdev: Don't require core operations
There's no reason to require subdevices to implement the core
operations. Remove the check for non-NULL core operations when
initializing the subdev.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/media/v4l2-subdev.h |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 02c6f4d..6088316 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -437,8 +437,7 @@ static inline void v4l2_subdev_init(struct v4l2_subdev
*sd,
const struct v4l2_subdev_ops *ops)
{
INIT_LIST_HEAD(sd-list);
- /* ops-core MUST be set */
- BUG_ON(!ops || !ops-core);
+ BUG_ON(!ops);
sd-ops = ops;
sd-v4l2_dev = NULL;
sd-flags = 0;
--
1.7.1
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH 2/6] v4l: subdev: Add device node support
v4l2_device *v4l2_dev,
if (err err != -ENOIOCTLCMD) {
v4l2_device_unregister_subdev(sd);
sd = NULL;
+ } else {
+ sd-initialized = 1;
}
Wouldn't checkpatch.pl script complain about { } on the else part since
there is only one statement?
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: sub device device node and ioctl support?
Laurent, The media controller upstreaming process will start in one or two weeks. This will require a lot of time, so everything won't be ready for 2.6.36. This being said, the subdevice userspace API is the first part of the media controller that will be pushed upstream. Is this already being reviewed in the list? If not, I suggest you send it for review separately, not with the media controller patch set. Getting it ready for 2.6.36 might be a bit difficult, it will depend on how many rc cycles we still get for 2.6.35. It will also depend on how fast the patches get reviewed, so you can help there :-) Of course I will review this since I need it for my work. If you can make it against the v4l-dvb latest tree, I can apply and get it tested since we are working on to add osd sub device for DMxxx VPBE display driver. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
sub device device node and ioctl support?
Hello, I need to support ioctls on sub devices as part of my work on vpbe display driver. For example, currently we have use proprietary ioctls on a fb device to configure osd hardware on DMXXX VPBE and would like to migrate them to the osd sub device node. But currently sub devices are not exporting device nodes. I know there is work done by Laurent to add this support as part of media controller activity, but then I have to wait for this for ever. Is there a way we can get this support merged to the kernel tree for 2.6.36? Murali Karicheri email: m-kariche...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] Davinci: Create seperate Kconfig file for davinci devices
Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hiremath, Vaibhav Sent: Thursday, May 27, 2010 9:11 AM To: linux-media@vger.kernel.org Cc: mche...@redhat.com; Karicheri, Muralidharan; linux- o...@vger.kernel.org; Hiremath, Vaibhav Subject: [PATCH 1/2] Davinci: Create seperate Kconfig file for davinci devices From: Vaibhav Hiremath hvaib...@ti.com Currently VPFE Capture driver and DM6446 CCDC driver is being reused for AM3517. So this patch is preparing the Kconfig/makefile for re-use of such IP's. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- drivers/media/video/Kconfig | 61 +-- drivers/media/video/Makefile|2 +- drivers/media/video/davinci/Kconfig | 93 +++ 3 files changed, 95 insertions(+), 61 deletions(-) create mode 100644 drivers/media/video/davinci/Kconfig diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index ad9e6f9..e5d74ae 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -570,66 +570,7 @@ config VIDEO_VIVI Say Y here if you want to test video apps or debug V4L devices. In doubt, say N. -config VIDEO_VPSS_SYSTEM - tristate VPSS System module driver - depends on ARCH_DAVINCI - help -Support for vpss system module for video driver - -config VIDEO_VPFE_CAPTURE - tristate VPFE Video Capture Driver - depends on VIDEO_V4L2 ARCH_DAVINCI - select VIDEOBUF_DMA_CONTIG - help -Support for DM VPFE based frame grabber. This is the -common V4L2 module for following DMXXX SoCs from Texas -Instruments:- DM6446 DM355. - Vaibhav, Could you also list DM365 here? This was somehow missed. -To compile this driver as a module, choose M here: the -module will be called vpfe-capture. - -config VIDEO_DM6446_CCDC - tristate DM6446 CCDC HW module - depends on ARCH_DAVINCI_DM644x VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces - with decoder modules such as TVP5146 over BT656 or - sensor module such as MT9T001 over a raw interface. This - module configures the interface and CCDC/ISIF to do - video frame capture from slave decoders. - - To compile this driver as a module, choose M here: the - module will be called vpfe. - -config VIDEO_DM355_CCDC - tristate DM355 CCDC HW module - depends on ARCH_DAVINCI_DM355 VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables DM355 CCD hw module. DM355 CCDC hw interfaces - with decoder modules such as TVP5146 over BT656 or - sensor module such as MT9T001 over a raw interface. This - module configures the interface and CCDC/ISIF to do - video frame capture from a slave decoders - - To compile this driver as a module, choose M here: the - module will be called vpfe. - -config VIDEO_ISIF - tristate ISIF HW module - depends on ARCH_DAVINCI_DM365 VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables ISIF hw module. This is the hardware module for - configuring ISIF in VPFE to capture Raw Bayer RGB data from - a image sensor or YUV data from a YUV source. - - To compile this driver as a module, choose M here: the - module will be called vpfe. +source drivers/media/video/davinci/Kconfig source drivers/media/video/omap/Kconfig diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index cc93859..aa1ea2f 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -177,7 +177,7 @@ obj-$(CONFIG_VIDEO_SAA7164) += saa7164/ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o -obj-$(CONFIG_ARCH_DAVINCI)+= davinci/ +obj-y += davinci/ obj-$(CONFIG_ARCH_OMAP) += omap/ diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig new file mode 100644 index 000..97f889d --- /dev/null +++ b/drivers/media/video/davinci/Kconfig @@ -0,0 +1,93 @@ +config DISPLAY_DAVINCI_DM646X_EVM + tristate DM646x EVM Video Display + depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + select VIDEOBUF_DMA_CONTIG + select VIDEO_DAVINCI_VPIF + select VIDEO_ADV7343 + select VIDEO_THS7303 + help +Support for DM6467 based display device. + +To compile this driver as a module, choose M here: the +module will be called vpif_display. + +config CAPTURE_DAVINCI_DM646X_EVM + tristate DM646x EVM Video Capture + depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + select VIDEOBUF_DMA_CONTIG + select VIDEO_DAVINCI_VPIF + help +Support for DM6467 based capture device
RE: [PATCH 2/2] AM3517: Add VPFE Capture driver support to board file
Vaibhav,
See below my comments...
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hiremath, Vaibhav
Sent: Thursday, May 27, 2010 9:11 AM
To: linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-
o...@vger.kernel.org; Hiremath, Vaibhav
Subject: [PATCH 2/2] AM3517: Add VPFE Capture driver support to board file
From: Vaibhav Hiremath hvaib...@ti.com
Also created vpfe master/slave clock aliases, since naming
convention is different in both Davinci and AM3517 devices.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 161
+
1 files changed, 161 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-
omap2/board-am3517evm.c
index c1c4389..edcb6db 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -30,15 +30,168 @@
#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/davinci/vpfe_capture.h
+
#include mux.h
#define LCD_PANEL_PWR 176
#define LCD_PANEL_BKLIGHT_PWR 182
#define LCD_PANEL_PWM 181
+/*
+ * 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,
[MK] You might want to change the card name to match with what you are using.
This is what user will see in querycap and should reflect the correct name IMO.
+ .ccdc = DM6446 CCDC,
+};
+
+static struct resource vpfe_resources
RE: [PATCH 1/2] Davinci: Create seperate Kconfig file for davinci devices
Vaibhav, Could you also list DM365 here? This was somehow missed. I believe you are referring to Instruments:- DM6446, DM365 DM355 yes. Thanks. Submitting this patch alone with this change. Thanks, Vaibhav -To compile this driver as a module, choose M here: the -module will be called vpfe-capture. - -config VIDEO_DM6446_CCDC - tristate DM6446 CCDC HW module - depends on ARCH_DAVINCI_DM644x VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces - with decoder modules such as TVP5146 over BT656 or - sensor module such as MT9T001 over a raw interface. This - module configures the interface and CCDC/ISIF to do - video frame capture from slave decoders. - - To compile this driver as a module, choose M here: the - module will be called vpfe. - -config VIDEO_DM355_CCDC - tristate DM355 CCDC HW module - depends on ARCH_DAVINCI_DM355 VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables DM355 CCD hw module. DM355 CCDC hw interfaces - with decoder modules such as TVP5146 over BT656 or - sensor module such as MT9T001 over a raw interface. This - module configures the interface and CCDC/ISIF to do - video frame capture from a slave decoders - - To compile this driver as a module, choose M here: the - module will be called vpfe. - -config VIDEO_ISIF - tristate ISIF HW module - depends on ARCH_DAVINCI_DM365 VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables ISIF hw module. This is the hardware module for - configuring ISIF in VPFE to capture Raw Bayer RGB data from - a image sensor or YUV data from a YUV source. - - To compile this driver as a module, choose M here: the - module will be called vpfe. +source drivers/media/video/davinci/Kconfig source drivers/media/video/omap/Kconfig diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index cc93859..aa1ea2f 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -177,7 +177,7 @@ obj-$(CONFIG_VIDEO_SAA7164) += saa7164/ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o -obj-$(CONFIG_ARCH_DAVINCI)+= davinci/ +obj-y += davinci/ obj-$(CONFIG_ARCH_OMAP) += omap/ diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig new file mode 100644 index 000..97f889d --- /dev/null +++ b/drivers/media/video/davinci/Kconfig @@ -0,0 +1,93 @@ +config DISPLAY_DAVINCI_DM646X_EVM + tristate DM646x EVM Video Display + depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + select VIDEOBUF_DMA_CONTIG + select VIDEO_DAVINCI_VPIF + select VIDEO_ADV7343 + select VIDEO_THS7303 + help +Support for DM6467 based display device. + +To compile this driver as a module, choose M here: the +module will be called vpif_display. + +config CAPTURE_DAVINCI_DM646X_EVM + tristate DM646x EVM Video Capture + depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + select VIDEOBUF_DMA_CONTIG + select VIDEO_DAVINCI_VPIF + help +Support for DM6467 based capture device. + +To compile this driver as a module, choose M here: the +module will be called vpif_capture. + +config VIDEO_DAVINCI_VPIF + tristate DaVinci VPIF Driver + depends on DISPLAY_DAVINCI_DM646X_EVM + help +Support for DaVinci VPIF Driver. + +To compile this driver as a module, choose M here: the +module will be called vpif. + +config VIDEO_VPSS_SYSTEM + tristate VPSS System module driver + depends on ARCH_DAVINCI + help +Support for vpss system module for video driver + +config VIDEO_VPFE_CAPTURE + tristate VPFE Video Capture Driver + depends on VIDEO_V4L2 (ARCH_DAVINCI || ARCH_OMAP3) + select VIDEOBUF_DMA_CONTIG + help +Support for DMx/AMx VPFE based frame grabber. This is the +common V4L2 module for following DMx/AMx SoCs from Texas +Instruments:- DM6446, DM355 AM3517/05. + +To compile this driver as a module, choose M here: the +module will be called vpfe-capture. + +config VIDEO_DM6446_CCDC + tristate DM6446 CCDC HW module + depends on VIDEO_VPFE_CAPTURE + select VIDEO_VPSS_SYSTEM + default y + help + Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces + with decoder modules such as TVP5146 over BT656 or + sensor module such as MT9T001 over a raw interface. This + module configures the interface and CCDC/ISIF to do + video frame capture from slave decoders. + + To compile this driver as a module, choose M here: the + module will be called vpfe. + +config VIDEO_DM355_CCDC + tristate DM355
RE:
Asheesh, Please re-send this patch with following:- 1) A detailed description of what you are trying to fix in each of this patch. You need to also run the checkpatch.pl script to make sure there are no errors. 2) Please make this patch based on the http://git.linuxtv.org/v4l-dvb.git master branch. I am assuming you have based it upon the Arago tree. 3) add the Signed-off-by field. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Bhardwaj, Asheesh Sent: Wednesday, May 19, 2010 12:45 PM To: linux-media@vger.kernel.org Subject: The patches will be applied to the davinci tree the ../drivers/media/video/davinci and will affect the both the capture and display drivers. Apply these patches to the git kernel. From ashee...@ti.com # This line is ignored. GIT: From: ashee...@ti.com Subject: In-Reply-To: -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PATCHES FOR 2.6.35] - Adding OMAP2/3 V4l2 display driver
Vaibhav, Thanks for clarifying Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hiremath, Vaibhav Sent: Thursday, April 29, 2010 1:33 AM To: Mauro Carvalho Chehab; Muralidharan Karicheri Cc: linux-media@vger.kernel.org; Hans Verkuil; Karicheri, Muralidharan Subject: RE: [GIT PATCHES FOR 2.6.35] - Adding OMAP2/3 V4l2 display driver -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Thursday, April 29, 2010 9:31 AM To: Muralidharan Karicheri Cc: linux-media@vger.kernel.org; Hiremath, Vaibhav; Hans Verkuil; Karicheri, Muralidharan Subject: Re: [GIT PATCHES FOR 2.6.35] - Adding OMAP2/3 V4l2 display driver Muralidharan Karicheri wrote: Hi Mauro, Please pull from:- The following changes since commit 184b7c85f31583632ad00c062a295b622759eef3: Mauro Carvalho Chehab (1): ir-core: Fix the delete logic are available in the git repository at: git://linuxtv.org/mkaricheri/vpfe-vpbe-video.git for_upstream_04_11 Vaibhav Hiremath (2): V4L2: Add support for OMAP2/3 V4L2 display driver on top of DSS2 omap_vout:V4L2 Display: Changed enum return type to int drivers/media/video/Kconfig |2 + drivers/media/video/Makefile|2 + drivers/media/video/omap/Kconfig| 11 + drivers/media/video/omap/Makefile |7 + drivers/media/video/omap/omap_vout.c| 2643 +++ drivers/media/video/omap/omap_voutdef.h | 147 ++ drivers/media/video/omap/omap_voutlib.c | 293 drivers/media/video/omap/omap_voutlib.h | 34 + 8 files changed, 3139 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/omap/Kconfig create mode 100644 drivers/media/video/omap/Makefile create mode 100644 drivers/media/video/omap/omap_vout.c create mode 100644 drivers/media/video/omap/omap_voutdef.h create mode 100644 drivers/media/video/omap/omap_voutlib.c create mode 100644 drivers/media/video/omap/omap_voutlib.h Applied. [Hiremath, Vaibhav] Missed to say Thanks. Cleanup patches and enhancement will follow now on top of this. Thanks, Vaibhav Yet, I didn't like to see all those memory allocations for userprt inside the driver. IMO, it would be better placed inside the videobuf code. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 06/16] V4L/DVB: vpif: remove unused #include linux/version.h
Signed-off-by: Muralidharan Karicheri mkarich...@gmail.com
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Huang Weiyi
Sent: Thursday, April 08, 2010 7:49 AM
To: mche...@redhat.com
Cc: linux-media@vger.kernel.org; Huang Weiyi
Subject: [PATCH 06/16] V4L/DVB: vpif: remove unused #include
linux/version.h
Remove unused #include linux/version.h('s) in
drivers/media/video/davinci/vpif_capture.c
drivers/media/video/davinci/vpif_display.c
Signed-off-by: Huang Weiyi weiyi.hu...@gmail.com
---
drivers/media/video/davinci/vpif_capture.c |1 -
drivers/media/video/davinci/vpif_display.c |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index 2e5a7fb..f74b551 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -33,7 +33,6 @@
#include linux/i2c.h
#include linux/platform_device.h
#include linux/io.h
-#include linux/version.h
#include linux/slab.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index 13c3a1b..f8cd5e5 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -29,7 +29,6 @@
#include linux/i2c.h
#include linux/platform_device.h
#include linux/io.h
-#include linux/version.h
#include linux/slab.h
#include asm/irq.h
--
1.6.1.3
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
Vaibhav,
[Murali] Shouldn't we remove omap_vout_uservirt_to_phys() and use
videobuf_iolock() instead as we have done in vpfe_capture.c?
As mentioned before, in my opinion we can address this in sub-sequent patch
series, and should not block this patch in getting to main-line.
+/*
+ * Convert V4L2 pixel format to DSS pixel format
+ */
+static enum omap_color_mode video_mode_to_dss_mode(struct
omap_vout_device
+ Â Â Â Â Â Â Â Â Â Â Â *vout)
+{
+ Â Â Â struct omap_overlay *ovl;
+ Â Â Â struct omapvideo_info *ovid;
+ Â Â Â struct v4l2_pix_format *pix = vout-pix;
+
+ Â Â Â ovid = vout-vid_info;
+ Â Â Â ovl = ovid-overlays[0];
+
+ Â Â Â switch (pix-pixelformat) {
+ Â Â Â case 0:
+ Â Â Â Â Â Â Â break;
+ Â Â Â case V4L2_PIX_FMT_YUYV:
+ Â Â Â Â Â Â Â return OMAP_DSS_COLOR_YUV2;
+
+ Â Â Â case V4L2_PIX_FMT_UYVY:
+ Â Â Â Â Â Â Â return OMAP_DSS_COLOR_UYVY;
+
+ Â Â Â case V4L2_PIX_FMT_RGB565:
+ Â Â Â Â Â Â Â return OMAP_DSS_COLOR_RGB16;
+
+ Â Â Â case V4L2_PIX_FMT_RGB24:
+ Â Â Â Â Â Â Â return OMAP_DSS_COLOR_RGB24P;
+
+ Â Â Â case V4L2_PIX_FMT_RGB32:
+ Â Â Â Â Â Â Â return (ovl-id == OMAP_DSS_VIDEO1) ?
+ Â Â Â Â Â Â Â Â Â Â Â OMAP_DSS_COLOR_RGB24U : OMAP_DSS_COLOR_ARGB32;
+ Â Â Â case V4L2_PIX_FMT_BGR32:
+ Â Â Â Â Â Â Â return OMAP_DSS_COLOR_RGBX32;
+
+ Â Â Â default:
+ Â Â Â Â Â Â Â return -EINVAL;
+ Â Â Â }
+ Â Â Â return -EINVAL;
[Murali] Also return type is enum and you are returning a negative number
here ???
I think yes it is acceptable, since ultimately enum is of type integer
constant. You can return the value which fits into this size.
[MK] I did some research into this and this code can behave differently
with different compilers. So if compiler treats the enum as int, it would
work fine, but not otherwise. IMO, we shouldn't write code that are dependant
on the tool chain (rather write portable code). So suggest you
change the return type to int instead of enum. Doesn't this code give
you a warning?
I have also asked Hans to provide
his comments since this is a new driver that he might have to approve.
Did
he review the code in the past?
[Hiremath, Vaibhav] Yes he reviewed it some time back; anyway he has
already provided few more comments now which I have already fixed. The
patch is following this reply.
Thanks,
Vaibhav
-Murali
snip
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
Vaibhav,
[Hiremath, Vaibhav] Thanks Murali, I really appreciate your comments here.
Please find response below -
You had responded only to some comments. Can I assume that you are taking care
of the other comments as well? I have also asked Hans to provide
his comments since this is a new driver that he might have to approve. Did he
review the code in the past?
-Murali
+
+#include asm/processor.h
Add a line here??
+#include plat/dma.h
+#include plat/vram.h
+#include plat/vrfb.h
+#include plat/display.h
+
+#include omap_voutlib.h
+#include omap_voutdef.h
+
+MODULE_AUTHOR(Texas Instruments);
+MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
+MODULE_LICENSE(GPL);
+
+
+/* Driver Configuration macros */
+#define VOUT_NAME omap_vout
+
+enum omap_vout_channels {
+ OMAP_VIDEO1 = 0,
Why do we have to initialize this to 0. It always start with a value 0
by default.
+ OMAP_VIDEO2,
+};
+
+enum dma_channel_state {
+ DMA_CHAN_NOT_ALLOTED = 0,
Ditto.
+ DMA_CHAN_ALLOTED,
+};
+
+#define QQVGA_WIDTH160
+#define QQVGA_HEIGHT 120
+
+/* Max Resolution supported by the driver */
+#define VID_MAX_WIDTH 1280/* Largest width */
+#define VID_MAX_HEIGHT 720 /* Largest height */
+
-
+
+module_param(debug, bool, S_IRUGO);
+MODULE_PARM_DESC(debug, Debug level (0-1));
+
+/* Local Helper functions */
+static void omap_vout_isr(void *arg, unsigned int irqstatus);
+static void omap_vout_cleanup_device(struct omap_vout_device *vout);
+
Is there a reason why you need these prototypes? I think we could
remove these prototypes and move the function ahead in the file before
it is called.
[Hiremath, Vaibhav] Do you see any harm with this? I think its only
implementation part. But still I will incorporate in next version.
+/* list of image formats supported by OMAP2 video pipelines */
+const static struct v4l2_fmtdesc omap_formats[] = {
+ {
+ /* Note: V4L2 defines RGB565 as:
+*
+* Byte 0Byte 1
+* g2 g1 g0 r4 r3 r2 r1 r0 b4 b3 b2 b1 b0 g5 g4
g3
+*
+* We interpret RGB565 as:
+*
+* Byte 0Byte 1
+* g2 g1 g0 b4 b3 b2 b1 b0 r4 r3 r2 r1 r0 g5 g4
g3
+*/
+ .description = RGB565, le,
+ .pixelformat = V4L2_PIX_FMT_RGB565,
+ },
+ {
+ /* Note: V4L2 defines RGB32 as: RGB-8-8-8-8 we use
+* this for RGB24 unpack mode, the last 8 bits are
ignored
+* */
+ .description = RGB32, le,
+ .pixelformat = V4L2_PIX_FMT_RGB32,
+ },
+ {
+ /* Note: V4L2 defines RGB24 as: RGB-8-8-8 we use
+*this for RGB24 packed mode
+*
+*/
+ .description = RGB24, le,
+ .pixelformat = V4L2_PIX_FMT_RGB24,
+ },
+ {
+ .description = YUYV (YUV 4:2:2), packed,
+ .pixelformat = V4L2_PIX_FMT_YUYV,
+ },
+ {
+ .description = UYVY, packed,
+ .pixelformat = V4L2_PIX_FMT_UYVY,
+ },
+};
+
+#define NUM_OUTPUT_FORMATS (ARRAY_SIZE(omap_formats))
+
+/*
+ * Allocate buffers
+ */
--
+
+/*
+ * omap_vout_uservirt_to_phys: This inline function is used to convert
user
+ * space virtual address to physical address.
+ */
+static u32 omap_vout_uservirt_to_phys(u32 virtp)
+{
+ unsigned long physp = 0;
+ struct vm_area_struct *vma;
+ struct mm_struct *mm = current-mm;
+
+ 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 addresses */
+ 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]) +
+
RE: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash on DM365
Mauro, Thanks a lot for your support. Do you plan to merge my pull request for 2.6.35 anytime soon? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] Sent: Thursday, April 01, 2010 12:21 PM To: Muralidharan Karicheri Cc: Karicheri, Muralidharan; linux-media@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open-sou...@linux.davincidsp.com Subject: Re: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash on DM365 Muralidharan Karicheri wrote: Mauro, When I had last replied to your email, I didn't check if the patch is actually applied to your v4l_for_linux branch of fixes.git tree. But Today I checked and I can't find the patch merged to this tree as you had mentioned.. So if you haven't merged it for some reason, please merge my updated patch available at https://patchwork.kernel.org/patch/86731/ I had merged, but, as I haven't pushed on linuxtv, I decided to rebase my local tree. Patch applied. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Resubmit: PATCH-V2] Introducing ti-media directory
Laurent, Using a dedicated directory in drivers/media/video for TI-specific cores is definitely a good idea (assuming the same IP cores won't be used by other vendors in the future). If another vendor uses it in another SOC (assuming for discussion), then the driver should be re-used. So there shouldn't be another version of the driver right? So why is this an issue? My concern is that, if we move the ISP driver in drivers/media/video/ti- media, the directory will soon get quite crowded. If a new TI processor comes up with a totally incompatible ISP, we will get a name conflict in drivers/media/video/ti-media. I was thinking about either replacing the isp prefix with omap3isp (or similar), or moving the driver to drivers/media/video/ti-media/omap3isp, but that will impede code sharing code between the Davinci and OMAP processor families. That's where my uncertainty comes from. I think vpfe is used for DM devices which is equivalent to ISP in OMAP. omap3 CCDC/Previewer/Resizer/H3A is re-used from DM6446 CCDC or vice-versa. The ccdc is also re-used in AM35xxx OMAP device (excuse me if I wrote the name incorrectly) that Vaibhav is working on. So we might want to name it as just ccdc.c/resizer.c/previewer.c. Currently we have dm644x_ccdc.c under davinci for DM644x and dm355_ccdc.c for DM355. We need to sort out the differences in the driver and use a common ccdc.c on OMAP/DM644x/AM35xxx. I am not sure if we have any control on how hardware designers name the IP, and would have to deal with it as it happens. For new IPs that is considerably different, but share the same name might have to be named by adding some prefix/suffix as appropriate (example v1, v2 etc for different versions of the same IP, resizer.c for OMAP/DM644x/AM35xxx, resizer_v1.c for resizer on DM355). Myself and Vaibhav had discussed this in the past and ti-media is the generic name that we could agree on. On DM SoCs (DM6446, DM355, DM365) I expect ti-media to be the home for all vpfe and vpbe driver files. Since we had a case of common IP across OMAP and DMxxx SoCs, we want to place all OMAP and DMxxx video driver files in a common directory so that sharing the drivers across the SoCs will be easy. We could discuss and agree on another name if need be. Any suggestions? It's not the name ti-media that I don't agree on, it's just that this will move the problem one step further in the directory hierarchy without actually solving it :-) Is it guaranteed today that no TI processors with new generation video blocks will reuse the names ISP, VPFE and VPBE ? The OMAP3 datasheet refers to VPFE and VPBE, but luckily those blocks are further divided into subblocks, and the driver doesn't refer to the VPFE and VPBE directly. As discussed above, we will have to expect name conflicts in future and come up with some naming convention to name files(and add it to v4 documentation). I think this shouldn't prevent this patch from merging to the tree since you are okay with the name. I will send a pull request if you are okay with this patch. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash on DM365
Mauro, Please discard this patch. I have sent an updated version to the list. The patch were already added at the fixes tree. I can't just discard, since this would break any other tree based on it. Ok. If the patch is so deadly broken, then we can add a rollback patch, making our and upstream tree dirty. Another alternative would be to add just a diff between the two patches. Not broken. I can send you another patch for adding the diff. Btw, please send me a patchwork ID when you want to refer to a patch sent to the mailing list, especially when there are two patches with the same name. Is this the one you're referring? X-Patchwork-Id: 86729 Yes. That is the one. I will send you a diff patch. Sorry for the trouble. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Resubmit: PATCH-V2] Introducing ti-media directory
Laurent, I'm not too sure to like the ti-media name. It will soon get quite crowded, and name collisions might occur (look at the linux-omap-camera tree and the ISP driver in there for instance). Isn't there an internal name to refer to both the DM6446 and AM3517 that could be used ? [Hiremath, Vaibhav] Laurent, ti-media directory is top level directory where we are putting all TI devices drivers. So having said that, we should worrying about what goes inside this directory. For me ISP is more generic, if you compare davinci and OMAP. Frankly, there are various naming convention we do have from device to device, even if the IP's are being reused. For example, the internal name for OMAP is ISP but Davinci refers it as a VPSS. Could you explain what name space issue you are referring to in linux-omap-camera since I am not quite familiar with that tree? Myself and Vaibhav had discussed this in the past and ti-media is the generic name that we could agree on. On DM SoCs (DM6446, DM355, DM365) I expect ti-media to be the home for all vpfe and vpbe driver files. Since we had a case of common IP across OMAP and DMxxx SoCs, we want to place all OMAP and DMxxx video driver files in a common directory so that sharing the drivers across the SoCs will be easy. We could discuss and agree on another name if need be. Any suggestions? Thanks, Vaibhav Signed-off-by: Vaibhav Hiremath hvaib...@ti.com -- Regards, Laurent Pinchart ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2 7/7] TVP514x: Add Powerup sequence during s_input to lock the signal properly
Vaibhav,
This patch has not fully resolved the lock issue. In my testing the change
done by Brijesh was required as well. Can you update me on what was your
findings based on my last email on this issue?
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hiremath, Vaibhav
Sent: Friday, March 19, 2010 2:04 AM
To: linux-media@vger.kernel.org
Cc: Karicheri, Muralidharan; Hiremath, Vaibhav; Rajashekhara, Sudhakar
Subject: [PATCH-V2 7/7] TVP514x: Add Powerup sequence during s_input to
lock the signal properly
From: Vaibhav Hiremath hvaib...@ti.com
For the sequence streamon - streamoff and again s_input, it fails
to lock the signal, since streamoff puts TVP514x into power off state
which leads to failure in sub-sequent s_input.
So add powerup sequence in s_routing (if disabled), since it is
important to lock the signal at this stage.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
drivers/media/video/tvp514x.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 26b4e71..97b7db5 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
@@ -78,6 +78,8 @@ struct tvp514x_std_info {
};
static struct tvp514x_reg tvp514x_reg_list_default[0x40];
+
+static int tvp514x_s_stream(struct v4l2_subdev *sd, int enable);
/**
* struct tvp514x_decoder - TVP5146/47 decoder object
* @sd: Subdevice Slave handle
@@ -643,6 +645,17 @@ static int tvp514x_s_routing(struct v4l2_subdev *sd,
/* Index out of bound */
return -EINVAL;
+ /*
+ * For the sequence streamon - streamoff and again s_input
+ * it fails to lock the signal, since streamoff puts TVP514x
+ * into power off state which leads to failure in sub-sequent s_input.
+ *
+ * So power up the TVP514x device here, since it is important to lock
+ * the signal at this stage.
+ */
+ if (!decoder-streaming)
+ tvp514x_s_stream(sd, 1);
+
input_sel = input;
output_sel = output;
--
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
RE: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash on DM365
Please discard this patch. I have sent an updated version to the list.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, March 17, 2010 1:19 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Karicheri, Muralidharan
Subject: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash on
DM365
From: Muralidharan Karicheri m-kariche...@ti.com
As part of upstream merge, set_params() function was removed from isif.c.
This requires
removal of BUG_ON() and check for set_params ptr in vpfe_capture.c.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/vpfe_capture.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 91f665b..aa7dd65 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -222,7 +222,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.get_frame_format);
BUG_ON(!dev-hw_ops.get_pixel_format);
BUG_ON(!dev-hw_ops.set_pixel_format);
- BUG_ON(!dev-hw_ops.set_params);
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
@@ -1704,16 +1703,19 @@ static long vpfe_param_handler(struct file *file,
void *priv,
case VPFE_CMD_S_CCDC_RAW_PARAMS:
v4l2_warn(vpfe_dev-v4l2_dev,
VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n);
- ret = ccdc_dev-hw_ops.set_params(param);
- if (ret) {
- v4l2_err(vpfe_dev-v4l2_dev,
- Error in setting parameters in CCDC\n);
- goto unlock_out;
- }
- if (vpfe_get_ccdc_image_format(vpfe_dev, vpfe_dev-fmt) 0) {
- v4l2_err(vpfe_dev-v4l2_dev,
- Invalid image format at CCDC\n);
- goto unlock_out;
+ if (ccdc_dev-hw_ops.set_params) {
+ ret = ccdc_dev-hw_ops.set_params(param);
+ if (ret) {
+ v4l2_err(vpfe_dev-v4l2_dev,
+ Error setting parameters in CCDC\n);
+ goto unlock_out;
+ }
+ if (vpfe_get_ccdc_image_format(vpfe_dev,
+ vpfe_dev-fmt) 0) {
+ v4l2_err(vpfe_dev-v4l2_dev,
+ Invalid image format at CCDC\n);
+ goto unlock_out;
+ }
}
break;
default:
--
1.6.0.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
RE: [patch 2/5] drivers/media/video: move dereference after NULL test
For drivers/media/video/davinci/vpif_display.c
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Julia Lawall [mailto:ju...@diku.dk]
Sent: Friday, March 12, 2010 4:16 AM
To: Karicheri, Muralidharan
Cc: a...@linux-foundation.org; mche...@infradead.org; linux-
me...@vger.kernel.org
Subject: RE: [patch 2/5] drivers/media/video: move dereference after NULL
test
From: Julia Lawall ju...@diku.dk
In quickcam_messenger.c, if the NULL test on uvd is needed, then the
dereference should be after the NULL test.
In vpif_display.c, std_info is initialized to the address of a structure
field. This seems unlikely to be NULL. Test std_info-stdid instead.
In saa7134-alsa.c, the function is only called from one place, where the
chip argument has already been dereferenced. On the other hand, if it
should be kept, then card should be initialized after it.
A simplified version of the semantic match that detects this problem is as
follows (http://coccinelle.lip6.fr/):
// smpl
@match exists@
expression x, E;
identifier fld;
@@
* x-fld
... when != \(x = E\|x\)
* x == NULL
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
---
drivers/media/video/davinci/vpif_display.c|2 +-
drivers/media/video/saa7134/saa7134-alsa.c|2 --
drivers/media/video/usbvideo/quickcam_messenger.c |3 ++-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/usbvideo/quickcam_messenger.c
b/drivers/media/video/usbvideo/quickcam_messenger.c
index 803d3e4..f0043d0 100644
--- a/drivers/media/video/usbvideo/quickcam_messenger.c
+++ b/drivers/media/video/usbvideo/quickcam_messenger.c
@@ -692,12 +692,13 @@ static int qcm_start_data(struct uvd *uvd)
static void qcm_stop_data(struct uvd *uvd)
{
- struct qcm *cam = (struct qcm *) uvd-user_data;
+ struct qcm *cam;
int i, j;
int ret;
if ((uvd == NULL) || (!uvd-streaming) || (uvd-dev == NULL))
return;
+ cam = (struct qcm *) uvd-user_data;
ret = qcm_camera_off(uvd);
if (ret)
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c
b/drivers/media/video/saa7134/saa7134-alsa.c
index d48c450..d3bd82a 100644
--- a/drivers/media/video/saa7134/saa7134-alsa.c
+++ b/drivers/media/video/saa7134/saa7134-alsa.c
@@ -1011,8 +1011,6 @@ static int
snd_card_saa7134_new_mixer(snd_card_saa7134_t * chip)
unsigned int idx;
int err, addr;
- if (snd_BUG_ON(!chip))
- return -EINVAL;
strcpy(card-mixername, SAA7134 Mixer);
for (idx = 0; idx ARRAY_SIZE(snd_saa7134_volume_controls); idx++) {
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index dfddef7..b2dce78 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -383,7 +383,7 @@ static int vpif_get_std_info(struct channel_obj *ch)
int index;
std_info-stdid = vid_ch-stdid;
- if (!std_info)
+ if (!std_info-stdid)
return -1;
for (index = 0; index ARRAY_SIZE(ch_params); index++) {
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 2/5] drivers/media/video: move dereference after NULL test
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of a...@linux-foundation.org
Sent: Thursday, March 11, 2010 5:02 PM
To: mche...@infradead.org
Cc: linux-media@vger.kernel.org; a...@linux-foundation.org; ju...@diku.dk
Subject: [patch 2/5] drivers/media/video: move dereference after NULL test
From: Julia Lawall ju...@diku.dk
In quickcam_messenger.c, if the NULL test on uvd is needed, then the
dereference should be after the NULL test.
In vpif_display.c, std_info is initialized to the address of a structure
field. This seems unlikely to be NULL. If it could somehow be NULL, then
the assignment should be moved after the NULL test. Alternatively, perhaps
the NULL test is intended to test std_info-stdid rather than std_info?
In saa7134-alsa.c, the function is only called from one place, where the
chip argument has already been dereferenced. On the other hand, if it
should be kept, then card should be initialized after it.
A simplified version of the semantic match that detects this problem is as
follows (http://coccinelle.lip6.fr/):
// smpl
@match exists@
expression x, E;
identifier fld;
@@
* x-fld
... when != \(x = E\|x\)
* x == NULL
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
Cc: Mauro Carvalho Chehab mche...@infradead.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/media/video/davinci/vpif_display.c|2 --
drivers/media/video/saa7134/saa7134-alsa.c|2 --
drivers/media/video/usbvideo/quickcam_messenger.c |3 ++-
3 files changed, 2 insertions(+), 5 deletions(-)
diff -puN drivers/media/video/davinci/vpif_display.c~drivers-media-video-
move-dereference-after-null-test drivers/media/video/davinci/vpif_display.c
--- a/drivers/media/video/davinci/vpif_display.c~drivers-media-video-move-
dereference-after-null-test
+++ a/drivers/media/video/davinci/vpif_display.c
@@ -383,8 +383,6 @@ static int vpif_get_std_info(struct chan
int index;
std_info-stdid = vid_ch-stdid;
- if (!std_info)
- return -1;
Please change it as
if (!std_info-stdid)
return -1;
Murali
for (index = 0; index ARRAY_SIZE(ch_params); index++) {
config = ch_params[index];
diff -puN drivers/media/video/saa7134/saa7134-alsa.c~drivers-media-video-
move-dereference-after-null-test drivers/media/video/saa7134/saa7134-alsa.c
--- a/drivers/media/video/saa7134/saa7134-alsa.c~drivers-media-video-move-
dereference-after-null-test
+++ a/drivers/media/video/saa7134/saa7134-alsa.c
@@ -1011,8 +1011,6 @@ static int snd_card_saa7134_new_mixer(sn
unsigned int idx;
int err, addr;
- if (snd_BUG_ON(!chip))
- return -EINVAL;
strcpy(card-mixername, SAA7134 Mixer);
for (idx = 0; idx ARRAY_SIZE(snd_saa7134_volume_controls); idx++) {
diff -puN drivers/media/video/usbvideo/quickcam_messenger.c~drivers-media-
video-move-dereference-after-null-test
drivers/media/video/usbvideo/quickcam_messenger.c
--- a/drivers/media/video/usbvideo/quickcam_messenger.c~drivers-media-
video-move-dereference-after-null-test
+++ a/drivers/media/video/usbvideo/quickcam_messenger.c
@@ -692,12 +692,13 @@ static int qcm_start_data(struct uvd *uv
static void qcm_stop_data(struct uvd *uvd)
{
- struct qcm *cam = (struct qcm *) uvd-user_data;
+ struct qcm *cam;
int i, j;
int ret;
if ((uvd == NULL) || (!uvd-streaming) || (uvd-dev == NULL))
return;
+ cam = (struct qcm *) uvd-user_data;
ret = qcm_camera_off(uvd);
if (ret)
_
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - FIX] V4L: vpfe_capture - free ccdc_lock when memory allocation fails
Hi,
If there are no comments, I will send a pull request for merging this.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, March 09, 2010 3:08 PM
To: linux-media@vger.kernel.org
Cc: Karicheri, Muralidharan
Subject: [PATCH - FIX] V4L: vpfe_capture - free ccdc_lock when memory
allocation fails
From: Murali Karicheri m-kariche...@ti.com
This patch fixes a bug in vpfe_probe() that doesn't call mutex_unlock() if
memory
allocation for ccdc_cfg fails. See also the smatch warning report from Dan
Carpenter that shows this as an issue.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/vpfe_capture.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 885cd54..91f665b 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1829,7 +1829,7 @@ static __init int vpfe_probe(struct platform_device
*pdev)
if (NULL == ccdc_cfg) {
v4l2_err(pdev-dev.driver,
Memory allocation failed for ccdc_cfg\n);
- goto probe_free_dev_mem;
+ goto probe_free_lock;
}
strncpy(ccdc_cfg-name, vpfe_cfg-ccdc, 32);
@@ -1981,8 +1981,9 @@ probe_out_video_release:
probe_out_release_irq:
free_irq(vpfe_dev-ccdc_irq0, vpfe_dev);
probe_free_ccdc_cfg_mem:
- mutex_unlock(ccdc_lock);
kfree(ccdc_cfg);
+probe_free_lock:
+ mutex_unlock(ccdc_lock);
probe_free_dev_mem:
kfree(vpfe_dev);
return ret;
--
1.6.0.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
RE: Status of the patches under review (45 patches)
Mauro, Feb,19 2010: video_device: don't free_irq() an element past array vpif_obj.dev[]http://patchwork.kernel.org/patch/80845 I had discussed this and am waiting for a response from the author against my last comment. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] Sent: Tuesday, March 09, 2010 2:06 PM To: LMML Cc: moin...@free.fr; Karicheri, Muralidharan; g.liakhovet...@gmx.de; pboettc...@dibcom.fr; tobias.lor...@gmx.net; awa...@radix.net; kh...@linux- fr.org; hdego...@redhat.com; abraham.m...@gmail.com; hverk...@xs4all.nl; cr...@iki.fi; davidtlw...@gmail.com; hen...@kurelid.se; st...@kernellabs.com Subject: Status of the patches under review (45 patches) This is the summary of the patches that are currently under review. Each patch is represented by its submission date, the subject (up to 70 chars) and the patchwork link (if submitted via email). Currently, there's no pending hg/git pull request or new patches at patchwork. P.S.: This email is c/c to the developers that some review action is expected. == Waiting for my fixes on Docbook == Feb,25 2010: DocBook/Makefile: Make it less verbose http://patchwork.kernel.org/patch/82076 Feb,25 2010: DocBook: Add rules to auto-generate some media docbooks http://patchwork.kernel.org/patch/82075 Feb,25 2010: [PATCHv2, http://patchwork.kernel.org/patch/82074 Feb,25 2010: [PATCHv2, http://patchwork.kernel.org/patch/82073 == Videobuf patches - Need more tests before committing it - Volunteers? == Jan,19 2010: [v1,1/1] V4L: Add sync before a hardware operation to videobuf. http://patchwork.kernel.org/patch/73896 Mar, 4 2010: [1/2] V4L/DVB: buf-dma-sg.c: don't assume nr_pages == sglen http://patchwork.kernel.org/patch/83626 Mar, 4 2010: [2/2] V4L/DVB: buf-dma-sg.c: support non-pageable user- allocated http://patchwork.kernel.org/patch/83627 == Waiting for Antti Palosaari cr...@iki.fi review == Feb,26 2010: af901x: NXP TDA18218 http://patchwork.kernel.org/patch/82494 == Waiting for Muralidharan Karicheri m-kariche...@ti.com review == Feb,19 2010: video_device: don't free_irq() an element past array vpif_obj.dev[]http://patchwork.kernel.org/patch/80845 == Waiting for Tobias Lorenz tobias.lor...@gmx.net review == Feb, 3 2010: radio-si470x-common: -EINVAL overwritten in si470x_vidioc_s_tuner()http://patchwork.kernel.org/patch/76786 == waiting for Jean Delvare kh...@linux-fr.org final submission after tests == Jan,30 2010: saa7134: Fix IR support of some ASUS TV-FM 7135 variants http://patchwork.kernel.org/patch/75883 == Waiting for its addition at linux-firmware and driver test by David Wong davidtlw...@gmail.com == Nov, 1 2009: lgs8gxx: remove firmware for lgs8g75 http://patchwork.kernel.org/patch/56822 == Andy Walls awa...@radix.net and Aleksandr Piskunov aleksandr.v.pisku...@gmail.com are discussing around the solution == Oct,11 2009: AVerTV MCE 116 Plus radio http://patchwork.kernel.org/patch/52981 == Patches waiting for Patrick Boettcher pboettc...@dibcom.fr review == Jan,15 2010: remove obsolete conditionalizing on DVB_DIBCOM_DEBUG http://patchwork.kernel.org/patch/73147 Feb, 8 2010: dib7000p: reduce large stack usage http://patchwork.kernel.org/patch/77891 Feb, 8 2010: dib3000mc: reduce large stack usage http://patchwork.kernel.org/patch/77892 == IR driver for IMON - Will likely go via drivers/input tree == Feb,25 2010: [v2, http://patchwork.kernel.org/patch/82119 == Gspca patches - Waiting Hans de Goede hdego...@redhat.com submission/review == Jan,29 2010: [gspca_jf,tree] gspca zc3xx: signal when unknown packet received http://patchwork.kernel.org/patch/75837 Mar, 8 2010: [1/1] gspca-stv06xx: Remove the 046d:08da usb id from linking to the http://patchwork.kernel.org/patch/84145 == Gspca patches - Waiting Jean-Francois Moine moin...@free.fr submission/review == Jan,14 2010: Problem with gspca and zc3xx http://patchwork.kernel.org/patch/72895 Feb,24 2010: gspca pac7302: add USB PID range based on heuristics http://patchwork.kernel.org/patch/81612 Feb,27 2010: [01/11] ov534: Remove ambiguous controls http://patchwork.kernel.org/patch/82721 Feb,27 2010: [02/11] ov534: Remove hue control http://patchwork.kernel.org/patch/82722 Feb,27 2010: [03/11] ov534: Fix autogain control, enable it by default http://patchwork.kernel.org/patch/82725 Feb,27 2010: [04/11] ov534: Add Auto Exposure http://patchwork.kernel.org/patch/82728 Mar, 1 2010: [v2,05/11] ov534: Fix and document setting manual exposure http://patchwork.kernel.org/patch/82910 Feb,27 2010: [06/11] ov534: Fix Auto White Balance control http://patchwork.kernel.org/patch/82718 Feb,27 2010: [07/11] ov534: Fixes
RE: More videobuf and streaming I/O questions
This being said, VIDIOC_S_INPUT was designed to switch analog sources. I'm not sure it would be the best would to multiplex streams from two digital sensors for instance. Even for analog signals, using the ioctl from userspace usually results in at least one corrupt frame if you don't synchronize the switching to the analog signals, which requires hardware support. Can you give us more details about the use case you're thinking about ? This is for supporting interfacing of TVP5148 to DM365 that can mux from two sources. There is an implementation of this in our internal release. Just exploring how this can be ported to upstream. Not done any work yet on this from my side. Does it require 2 buffers per input because every frame period, you have multiple frames to queue from the different inputs? In this case there's a single video stream, so I don't think it would require 2 buffers per input. Usually a minimum of 3 buffers are typically required in a SoC case to do streaming. Could you share the details if possible? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] video_device: don't free_irq() an element past array vpif_obj.dev[] and fix test
Roel,
Thanks for the patch.
In vpif_get_std_info(): std_info doesn't need the NULL test, it was already
dereferenced anyway. If std_info-stdid is 0 we could early return -1.
In vpif_probe(): local variable q was only assigned. If we error out with
either last two goto's then j equals VPIF_DISPLAY_MAX_DEVICES. So after the
probe_out: label, k also reaches VPIF_DISPLAY_MAX_DEVICES after the loop.
In
the first iteration in the loop after vpif_int_err: a free_irq() can occur
of an element vpif_obj.dev[VPIF_DISPLAY_MAX_DEVICES]-channel_id which is
outside vpif_obj.dev[] array boundaries.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
Or am I mistaken?
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index dfddef7..8f6605d 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -383,7 +383,7 @@ static int vpif_get_std_info(struct channel_obj *ch)
int index;
std_info-stdid = vid_ch-stdid;
- if (!std_info)
+ if (!std_info-stdid)
return -1;
This is a NACK. We shouldn't check for stdid since the function is supposed
to update std_info. So just remove
if (!std_info)
return -1;
I am okay with the below change. So please re-submit the patch with the
above change and my ACK.
Thanks
Murali
for (index = 0; index ARRAY_SIZE(ch_params); index++) {
@@ -1423,7 +1423,7 @@ static __init int vpif_probe(struct platform_device
*pdev)
{
struct vpif_subdev_info *subdevdata;
struct vpif_display_config *config;
- int i, j = 0, k, q, m, err = 0;
+ int i, j = 0, k, m, err = 0;
struct i2c_adapter *i2c_adap;
struct common_obj *common;
struct channel_obj *ch;
@@ -1573,10 +1573,12 @@ probe_out:
video_device_release(ch-video_dev);
ch-video_dev = NULL;
}
+ if (k == VPIF_DISPLAY_MAX_DEVICES)
+ k = VPIF_DISPLAY_MAX_DEVICES - 1;
vpif_int_err:
v4l2_device_unregister(vpif_obj.v4l2_dev);
vpif_err(VPIF IRQ request failed\n);
- for (q = k; k = 0; k--) {
+ for (; k = 0; k--) {
for (m = i; m = res-start; m--)
free_irq(m, (void *)(vpif_obj.dev[k]-channel_id));
res = platform_get_resource(pdev, IORESOURCE_IRQ, k-1);
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] video_device: don't free_irq() an element past array vpif_obj.dev[] and fix test
- Â Â Â if (!std_info)
+ Â Â Â if (!std_info-stdid)
       return -1;
This is a NACK. We shouldn't check for stdid since the function is
supposed
to update std_info. So just remove
if (!std_info)
    return -1;
I don't see how std_info could get updated. consider the loop in case
std_info-stdid equals 0:
Ok. You are right! The ch_params[] is a table for keeping the information
about different standards supported. For a given stdid in std_info, the
function matches the stdid with that in the table and get the corresponding
entry.
I am okay with the below change. So please re-submit the patch with the
above change and my ACK.
Thanks
Murali
+ Â Â Â if (k == VPIF_DISPLAY_MAX_DEVICES)
+ Â Â Â Â Â Â Â k = VPIF_DISPLAY_MAX_DEVICES - 1;
actually I think this is still not right. shouldn't it be be
k = VPIF_DISPLAY_MAX_DEVICES - 1;
What you mean here? What you suggest here is same as in your patch, right?
Murali
are you using this driver in your project?
No, I just found this in the code.
Thanks, Roel
N�r��yb�X��ǧv�^�)޺{.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
RE: Fourcc for multiplanar formats
Hi, I think all of the planar pix format defined in videodev2.h are contiguous in memory. So I would suggest adding some suffix to indicate this so that it is obvious to application users. What about V4L2_PIX_FMT_NV16_2P, V4L2_PIX_FMT_YUV422P_3P, etc.? Not sure what Hans mean by the 2P or 3P extensions since NV16 has 2 planes. Why do we want to re-define NV12 and NV12_2P since it can cause backward compatibility issues. Why don't we keep existing naming convention for contiguous formats and add a suffix for indicating the planes are not contiguous. For example V4L2_PIX_FMT_NV16 vs V4L2_PIX_FMT_NV16_NC where NC - Non Contiguous Just my thoughts... Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Wednesday, February 17, 2010 1:22 PM To: Pawel Osciak Cc: linux-media@vger.kernel.org; Sylwester Nawrocki; 'Kamil Debski' Subject: Re: Fourcc for multiplanar formats On Monday 15 February 2010 17:27:46 Pawel Osciak wrote: Hello, we would like to ask for suggestions for new fourcc formats for multiplanar buffers. There are planar formats in V4L2 API, but for all of them, each plane X immediately follows Y plane in memory. We are in the process of testing formats and V4L2 extensions that relax those requirements and allow each plane to reside in a separate area of memory. I am not sure how we should name those formats though. In our example, we are focusing on the following formats at the moment: - YCbCr 422 2-planar (multiplanar version of V4L2_PIX_FMT_NV16) - YCbCr 422 3-planar (multiplanar version of V4L2_PIX_FMT_YUV422P) - YCbCr 420 2-planar (multiplanar version of V4L2_PIX_FMT_NV12) - YCbCr 420 3-planar (multiplanar version of V4L2_PIX_FMT_YUV420) Could anyone give any suggestions how we should name such formats and what to pass to the v4l2_fourcc() macro? What about V4L2_PIX_FMT_NV16_2P, V4L2_PIX_FMT_YUV422P_3P, etc.? What we pass to the fourcc macro is not very important IMHO. As long as it is unique. Regards, Hans Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD Center -- 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Fourcc for multiplanar formats
Hi Pawel, Any progress on the RFC for allowing user applications to specify separate user ptr for each plane of a multi-planar format? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Wednesday, February 17, 2010 1:42 PM To: Karicheri, Muralidharan Cc: Pawel Osciak; linux-media@vger.kernel.org; Sylwester Nawrocki; 'Kamil Debski' Subject: Re: Fourcc for multiplanar formats On Wednesday 17 February 2010 19:32:06 Karicheri, Muralidharan wrote: Hi, I think all of the planar pix format defined in videodev2.h are contiguous in memory. So I would suggest adding some suffix to indicate this so that it is obvious to application users. What about V4L2_PIX_FMT_NV16_2P, V4L2_PIX_FMT_YUV422P_3P, etc.? Not sure what Hans mean by the 2P or 3P extensions since NV16 has 2 planes. Why do we want to re-define NV12 and NV12_2P since it can cause backward compatibility issues. Why don't we keep existing naming convention for contiguous formats and add a suffix for indicating the planes are not contiguous. For example V4L2_PIX_FMT_NV16 vs V4L2_PIX_FMT_NV16_NC where NC - Non Contiguous That's better than my suggestion. What I meant with 2P and 3P was that is has 2 (or 3 or whatever) non-contiguous planes. But that's confusing. Regards, Hans Just my thoughts... Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Wednesday, February 17, 2010 1:22 PM To: Pawel Osciak Cc: linux-media@vger.kernel.org; Sylwester Nawrocki; 'Kamil Debski' Subject: Re: Fourcc for multiplanar formats On Monday 15 February 2010 17:27:46 Pawel Osciak wrote: Hello, we would like to ask for suggestions for new fourcc formats for multiplanar buffers. There are planar formats in V4L2 API, but for all of them, each plane X immediately follows Y plane in memory. We are in the process of testing formats and V4L2 extensions that relax those requirements and allow each plane to reside in a separate area of memory. I am not sure how we should name those formats though. In our example, we are focusing on the following formats at the moment: - YCbCr 422 2-planar (multiplanar version of V4L2_PIX_FMT_NV16) - YCbCr 422 3-planar (multiplanar version of V4L2_PIX_FMT_YUV422P) - YCbCr 420 2-planar (multiplanar version of V4L2_PIX_FMT_NV12) - YCbCr 420 3-planar (multiplanar version of V4L2_PIX_FMT_YUV420) Could anyone give any suggestions how we should name such formats and what to pass to the v4l2_fourcc() macro? What about V4L2_PIX_FMT_NV16_2P, V4L2_PIX_FMT_YUV422P_3P, etc.? What we pass to the fourcc macro is not very important IMHO. As long as it is unique. Regards, Hans Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD Center -- 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 6/6] DaVinci - Adding platform board changes for vpfe capture on DM365
Kevin,
Please respond by today if you have any comments against this patch so that I
can add it to my development repository at linuxtv.org and ask Mauro to pull
this to your tree. As we are approaching the merge window for 2.6.34
and so many patches pending to be merged to 2.6.34, I would appreciate your
prompt response on this.
Regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Monday, February 01, 2010 5:27 PM
To: linux-media@vger.kernel.org; khil...@deeprootsystems.com
Cc: hverk...@xs4all.nl; davinci-linux-open-sou...@linux.davincidsp.com;
Karicheri, Muralidharan
Subject: [PATCH v3 6/6] DaVinci - Adding platform board changes for vpfe
capture on DM365
From: Murali Karicheri m-kariche...@ti.com
This patch adds following changes:-
1) add sub device configuration data for TVP5146 used by vpfe capture
2) registers platform devices for vpfe_capture, isif and vpss
3) defines hardware resources for the devices listed under 2)
4) defines clock aliase for isif driver
5) adding setup_pinmux() for isif
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
Applies to linux-next of v4l-dvb
- updated to add clock aliase (v3) and rebased to latest for merge
- review comments incorporated (v2)
arch/arm/mach-davinci/board-dm365-evm.c| 71 +++
arch/arm/mach-davinci/dm365.c | 102
+++-
arch/arm/mach-davinci/include/mach/dm365.h |2 +
3 files changed, 174 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-
davinci/board-dm365-evm.c
index b476395..c216783 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -37,6 +37,8 @@
#include mach/nand.h
#include mach/keyscan.h
+#include media/tvp514x.h
+
static inline int have_imager(void)
{
/* REVISIT when it's supported, trigger via Kconfig */
@@ -306,6 +308,73 @@ static void dm365evm_mmc_configure(void)
davinci_cfg_reg(DM365_SD1_DATA0);
}
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
+
+#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,
+ },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI2B,
+ .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, 0x5d),
+ .platform_data = tvp5146_pdata,
+ },
+ },
+};
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .sub_devs = vpfe_sub_devs,
+ .i2c_adapter_id = 1,
+ .card_name = DM365 EVM,
+ .ccdc = ISIF,
+};
+
static void __init evm_init_i2c(void)
{
davinci_init_i2c(i2c_pdata);
@@ -497,6 +566,8 @@ static struct davinci_uart_config uart_config
__initdata = {
static void __init dm365_evm_map_io(void)
{
+ /* setup input configuration for VPFE input devices */
+ dm365_set_vpfe_config(vpfe_cfg);
dm365_init();
}
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index f53735c..ce9da43 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1008,6 +1008,97 @@ void __init dm365_init(void)
davinci_common_init(davinci_soc_info_dm365);
}
+static struct resource dm365_vpss_resources[] = {
+ {
+ /* VPSS ISP5 Base address */
+ .name = isp5,
+ .start = 0x01c7
RE: [PATCH v3 1/6] V4L - vpfe capture - header files for ISIF driver
Mauro, If you scan the patch, you would see the status of this patch series. --- Applies to linux-next tree of v4l-dvb - rebasing to latest for merge (v3) Not sure if there is a better way to include this information. The arch part of this series requires sign-off from Kevin who is copied on this. I have seen your procedure for submitting patches and would send you an official pull request as per your procedure once Kevin sign-off the arch part. I have following questions though.. Should we always add [RFC PATCH] in the subject? It makes sense for patches being reviewed. How to request sign-off? Do I only send patches to the person, not to the list? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] Sent: Monday, February 01, 2010 6:12 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org Subject: Re: [PATCH v3 1/6] V4L - vpfe capture - header files for ISIF driver m-kariche...@ti.com wrote: From: Murali Karicheri m-kariche...@ti.com This is the header file for ISIF driver on DM365. ISIF driver is equivalent to CCDC driver on DM355 and DM644x. This driver is tested for YUV capture from TVP514x driver. This patch contains the header files required for this driver. The name of the file is changed to reflect the name of IP. Reviewed-by: Nori, Sekhar nsek...@ti.com Reviewed-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- Applies to linux-next tree of v4l-dvb - rebasing to latest for merge (v3) - Updated based on comments against v1 of the patch (v2) drivers/media/video/davinci/isif_regs.h | 269 include/media/davinci/isif.h| 531 +++ 2 files changed, 800 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/isif_regs.h create mode 100644 include/media/davinci/isif.h Hi Murali, As always, it is almost impossible for me to know if you're submitting yet another RFC version or a final version to be applied. So, I kindly ask you to send all those patches that are still under discussions with [RFC PATCH] at the subject, and, on the final version, send it to me via a git pull request. Unfortunately, I don't have enough time to go inside every RFC patch that are under discussion, so I prefer to optimize my time focusing on the patch versions that are considered ready for inclusion, and where there's no c/c to any members-only ML. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/6] V4L - vpfe capture - header files for ISIF driver
Hi Kevin, This patch is already approved by the V4L sub system. I need to get your approval for the arch part (patch #6). I have updated the clock handling based on your comments against the last patch (adding clock alias) I will request Mauro to merge the arch part via the v4l tree. I have a developer repository set up at linuxtv.org. Hereafter I will be sending pull request directly using the above repository. Thanks Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Karicheri, Muralidharan Sent: Monday, February 01, 2010 5:27 PM To: linux-media@vger.kernel.org; khil...@deeprootsystems.com Cc: hverk...@xs4all.nl; davinci-linux-open-sou...@linux.davincidsp.com; Karicheri, Muralidharan Subject: [PATCH v3 1/6] V4L - vpfe capture - header files for ISIF driver From: Murali Karicheri m-kariche...@ti.com This is the header file for ISIF driver on DM365. ISIF driver is equivalent to CCDC driver on DM355 and DM644x. This driver is tested for YUV capture from TVP514x driver. This patch contains the header files required for this driver. The name of the file is changed to reflect the name of IP. Reviewed-by: Nori, Sekhar nsek...@ti.com Reviewed-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- Applies to linux-next tree of v4l-dvb - rebasing to latest for merge (v3) - Updated based on comments against v1 of the patch (v2) drivers/media/video/davinci/isif_regs.h | 269 include/media/davinci/isif.h| 531 +++ 2 files changed, 800 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/isif_regs.h create mode 100644 include/media/davinci/isif.h diff --git a/drivers/media/video/davinci/isif_regs.h b/drivers/media/video/davinci/isif_regs.h new file mode 100644 index 000..f7b8893 --- /dev/null +++ b/drivers/media/video/davinci/isif_regs.h @@ -0,0 +1,269 @@ +/* + * Copyright (C) 2008-2009 Texas Instruments Inc + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#ifndef _ISIF_REGS_H +#define _ISIF_REGS_H + +/* ISIF registers relative offsets */ +#define SYNCEN0x00 +#define MODESET 0x04 +#define HDW 0x08 +#define VDW 0x0c +#define PPLN 0x10 +#define LPFR 0x14 +#define SPH 0x18 +#define LNH 0x1c +#define SLV0 0x20 +#define SLV1 0x24 +#define LNV 0x28 +#define CULH 0x2c +#define CULV 0x30 +#define HSIZE 0x34 +#define SDOFST0x38 +#define CADU 0x3c +#define CADL 0x40 +#define LINCFG0 0x44 +#define LINCFG1 0x48 +#define CCOLP 0x4c +#define CRGAIN0x50 +#define CGRGAIN 0x54 +#define CGBGAIN 0x58 +#define CBGAIN0x5c +#define COFSTA0x60 +#define FLSHCFG0 0x64 +#define FLSHCFG1 0x68 +#define FLSHCFG2 0x6c +#define VDINT00x70 +#define VDINT10x74 +#define VDINT20x78 +#define MISC 0x7c +#define CGAMMAWD 0x80 +#define REC656IF 0x84 +#define CCDCFG0x88 +/* +* Defect Correction registers
[PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform code
Mauro,
I know you are busy, but this patch is sitting too long for merge
and require your service. Could you at least respond to my email with
your plan so that I can work on the next patch set for your merge.
Thanks and regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
Of Karicheri, Muralidharan
Sent: Thursday, January 14, 2010 4:24 PM
To: mche...@infradead.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; mche...@infradead.org;
linux-media@vger.kernel.org
Subject: RE: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
Mauro,
Could you add patches 1-3 to linux-next ASAP?
See the response from Kevin for the arch part.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, January 14, 2010 3:48 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl;
mche...@infradead.org;
davinci-linux-open-sou...@linux.davincidsp.com
Subject: Re: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
Karicheri, Muralidharan m-kariche...@ti.com writes:
Mauro,
Please merge this patches if there are no more comments.
Kevin,
Could you work with Mauro to merge the arch part as required?
This version looks good with me.
I'll assume that these are targed for 2.6.34, not 2.6.33-rc fixes window.
These appear to be able at least compile independently, so as soon as
Mauro/Hans sign-off on them, I wi add PATCH 4/4 to davinci-next so
it will be queued for 2.6.34 and be a part of linux-next.
Mauro can queue patches 1-3 in his queue for 2.6.34. They will both
be in linux-next for testing.
Also, I can *temporarily* add patches 1-3 to davinci git so davinci git
will have them all while waiting for 2.6.34 merge window. I will then
drop them when Mauro's tree merges upstream.
Kevin
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, January 13, 2010 6:27 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com; mche...@infradead.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Karicheri,
Muralidharan
Subject: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
From: Muralidharan Karicheri m-kariche...@ti.com
Following changes are done in this patch:-
1) removed the platform code and clk configuration. They are now
part of ccdc driver (part of the ccdc patches and platform
patches 2-4)
2) Added proper error codes for ccdc register function
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree of v4l-dvb
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated
comments
against v1 of these patches.
drivers/media/video/davinci/vpfe_capture.c | 131 +++--
-
--
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
- /* for storing mem maps for CCDC */
- int ccdc_addr_size;
- void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
- BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct
ccdc_hw_device
*dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR vpfe capture not initialized\n);
- ret = -1;
+ ret = -EFAULT;
goto unlock;
}
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
ccdc_dev
RE: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform code
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, January 14, 2010 3:48 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl; mche...@infradead.org;
davinci-linux-open-sou...@linux.davincidsp.com
Subject: Re: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
Karicheri, Muralidharan m-kariche...@ti.com writes:
Mauro,
Please merge this patches if there are no more comments.
Kevin,
Could you work with Mauro to merge the arch part as required?
This version looks good with me.
I'll assume that these are targed for 2.6.34, not 2.6.33-rc fixes window.
That is correct.
These appear to be able at least compile independently, so as soon as
Mauro/Hans sign-off on them, I wi add PATCH 4/4 to davinci-next so
it will be queued for 2.6.34 and be a part of linux-next.
Thanks.
Murali
Mauro can queue patches 1-3 in his queue for 2.6.34. They will both
be in linux-next for testing.
Also, I can *temporarily* add patches 1-3 to davinci git so davinci git
will have them all while waiting for 2.6.34 merge window. I will then
drop them when Mauro's tree merges upstream.
Kevin
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, January 13, 2010 6:27 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com; mche...@infradead.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Karicheri,
Muralidharan
Subject: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
From: Muralidharan Karicheri m-kariche...@ti.com
Following changes are done in this patch:-
1) removed the platform code and clk configuration. They are now
part of ccdc driver (part of the ccdc patches and platform
patches 2-4)
2) Added proper error codes for ccdc register function
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree of v4l-dvb
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated
comments
against v1 of these patches.
drivers/media/video/davinci/vpfe_capture.c | 131 +++---
--
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
-/* for storing mem maps for CCDC */
-int ccdc_addr_size;
-void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
-BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR vpfe capture not initialized\n);
-ret = -1;
+ret = -EFAULT;
goto unlock;
}
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
ccdc_dev = dev;
-dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
- ccdc_cfg-ccdc_addr_size);
unlock:
mutex_unlock(ccdc_lock);
return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
-clk_disable(vpfe_cfg-vpssclk);
-clk_put(vpfe_cfg-vpssclk);
-clk_disable(vpfe_cfg-slaveclk);
-clk_put(vpfe_cfg-slaveclk);
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-int ret = -ENOENT;
-
-vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
-if (NULL == vpfe_cfg-vpssclk) {
-v4l2_err(vpfe_dev-pdev-driver, No clock defined for
- vpss_master\n
RE: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform code
Mauro,
Could you add patches 1-3 to linux-next ASAP?
See the response from Kevin for the arch part.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, January 14, 2010 3:48 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl; mche...@infradead.org;
davinci-linux-open-sou...@linux.davincidsp.com
Subject: Re: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
Karicheri, Muralidharan m-kariche...@ti.com writes:
Mauro,
Please merge this patches if there are no more comments.
Kevin,
Could you work with Mauro to merge the arch part as required?
This version looks good with me.
I'll assume that these are targed for 2.6.34, not 2.6.33-rc fixes window.
These appear to be able at least compile independently, so as soon as
Mauro/Hans sign-off on them, I wi add PATCH 4/4 to davinci-next so
it will be queued for 2.6.34 and be a part of linux-next.
Mauro can queue patches 1-3 in his queue for 2.6.34. They will both
be in linux-next for testing.
Also, I can *temporarily* add patches 1-3 to davinci git so davinci git
will have them all while waiting for 2.6.34 merge window. I will then
drop them when Mauro's tree merges upstream.
Kevin
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, January 13, 2010 6:27 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com; mche...@infradead.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Karicheri,
Muralidharan
Subject: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
From: Muralidharan Karicheri m-kariche...@ti.com
Following changes are done in this patch:-
1) removed the platform code and clk configuration. They are now
part of ccdc driver (part of the ccdc patches and platform
patches 2-4)
2) Added proper error codes for ccdc register function
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree of v4l-dvb
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated
comments
against v1 of these patches.
drivers/media/video/davinci/vpfe_capture.c | 131 +++---
--
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
-/* for storing mem maps for CCDC */
-int ccdc_addr_size;
-void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
-BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR vpfe capture not initialized\n);
-ret = -1;
+ret = -EFAULT;
goto unlock;
}
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
ccdc_dev = dev;
-dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
- ccdc_cfg-ccdc_addr_size);
unlock:
mutex_unlock(ccdc_lock);
return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
-clk_disable(vpfe_cfg-vpssclk);
-clk_put(vpfe_cfg-vpssclk);
-clk_disable(vpfe_cfg-slaveclk);
-clk_put(vpfe_cfg-slaveclk);
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-int ret = -ENOENT;
-
-vpfe_cfg
RE: [PATCH - v4 1/4] V4L-vpfe_capture-remove-clock and platform code
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, January 11, 2010 7:17 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; mche...@infradead.org; hverk...@xs4all.nl;
davinci-linux-open-sou...@linux.davincidsp.com
Subject: Re: [PATCH - v4 1/4] V4L-vpfe_capture-remove-clock and platform
code
m-kariche...@ti.com writes:
From: Muralidharan Karicheri m-kariche...@ti.com
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated
comments
against v1 of these patches.
This part is also not relevant to the git history, and should be after the
'---'
In this patch, the clock configuration is moved to ccdc driver since
clocks
are configured for ccdc. Also adding proper error codes for ccdc register
function and removing the ccdc memory resource handling.
Also, this doesn't accuratly reflect the changes done in the patch.
Here the clock configuration isn't moved, it's removed. You should
mention it being removed here and added to platform-specific code in
subsequent patches.
Sorry to be so nit-picky about the comments, but having a well-written
and descriptive changelog is extremely importanty. For the benefit of
reading the git history later, and also for those of us less familiar
with the details of these drivers, we rely heavily on a good changelog.
[MK] I think you are being too picky on these comments :( Besides this was
gone through several reviews and I was wondering why you chose to ignore these
comments earlier. It was now being sent for merge, not for review.
This is really not helping the upstream merge :(
Anyways, I will make these changes and send again.
Kevin
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree
Applies to linux-next tree of v4l-dvb
drivers/media/video/davinci/vpfe_capture.c | 131 +++---
--
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
-/* for storing mem maps for CCDC */
-int ccdc_addr_size;
-void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
-BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR vpfe capture not initialized\n);
-ret = -1;
+ret = -EFAULT;
goto unlock;
}
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
ccdc_dev = dev;
-dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
- ccdc_cfg-ccdc_addr_size);
unlock:
mutex_unlock(ccdc_lock);
return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
-clk_disable(vpfe_cfg-vpssclk);
-clk_put(vpfe_cfg-vpssclk);
-clk_disable(vpfe_cfg-slaveclk);
-clk_put(vpfe_cfg-slaveclk);
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-int ret = -ENOENT;
-
-vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
-if (NULL == vpfe_cfg-vpssclk) {
-v4l2_err(vpfe_dev-pdev-driver, No clock defined for
- vpss_master\n);
-return ret;
-}
-
-if (clk_enable(vpfe_cfg-vpssclk)) {
-v4l2_err(vpfe_dev-pdev-driver,
-vpfe vpss master clock not enabled\n
RE: [PATCH 0/9] Feature enhancement of VPFE/CCDC Capture driver
Vaibhav, Hans already merged my dm365 patches. So you have rebase this to that before merging. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hiremath, Vaibhav Sent: Monday, January 11, 2010 1:29 AM To: Hiremath, Vaibhav; linux-media@vger.kernel.org Cc: linux-o...@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- sou...@linux.davincidsp.com; Karicheri, Muralidharan Subject: RE: [PATCH 0/9] Feature enhancement of VPFE/CCDC Capture driver -Original Message- From: Hiremath, Vaibhav Sent: Monday, January 04, 2010 7:33 PM To: linux-media@vger.kernel.org Cc: linux-o...@vger.kernel.org; hverk...@xs4all.nl; davinci-linux- open-sou...@linux.davincidsp.com; Karicheri, Muralidharan; Hiremath, Vaibhav Subject: [PATCH 0/9] Feature enhancement of VPFE/CCDC Capture driver From: Vaibhav Hiremath hvaib...@ti.com While adding support for AM3517/05 devices I have implemented/came- across these features/enhancement/bug-fixes for VPFE-Capture driver. Also the important change added is, to introduced ti-media directory for all TI devices. Vaibhav Hiremath (9): Makfile:Removed duplicate entry of davinci TVP514x:Switch to automode for querystd tvp514x: add YUYV format support Introducing ti-media directory DMx:Update board files for ti-media directory change Davinci VPFE Capture:Return 0 from suspend/resume DM644x CCDC : Add Suspend/Resume Support VPFE Capture: Add call back function for interrupt clear to vpfe_cfg DM644x CCDC: Add 10bit BT support arch/arm/mach-davinci/include/mach/dm355.h |2 +- arch/arm/mach-davinci/include/mach/dm644x.h |2 +- 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| 1081 --- drivers/media/video/davinci/dm355_ccdc_regs.h | 310 drivers/media/video/davinci/dm644x_ccdc.c | 966 -- drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 -- drivers/media/video/davinci/vpfe_capture.c | 2055 - 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 | 1081 +++ 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 | 2067 + 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 | 15 + 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 + 46 files changed, 11207 insertions(+), 11040 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
RE: [PATCH - v4 1/4] V4L-vpfe_capture-remove-clock and platform code
Hi Mauro Kevin,
I am re-sending these patches to do following:-
1) arch patches are re-created based on Linus tree
2) V4l patches are rebased to latest linux-next tree
These patches will override the pull request from Hans.
I am trying to setup mercurial to send the pull request, but
will take few more days to be fully functional. Meanwhile
please merge the attached patches.
The kernel upstream tree is at 2.6.33.rc3. We have a bunch of
patches planned for 2.6.34. So please start merging these patches
to the linux-next so that they can make to 2.6.34. You might
have seen a bunch of patches from Vaibhav as well that is being
reviewed on the list.
Regarding the merge of arch patches, I would let Kevin to
comment on how to handle the merge. I have re-created the arch
patches against the Linus tree as per Kevin's suggestion.
Thanks.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Monday, January 11, 2010 2:23 PM
To: linux-media@vger.kernel.org; khil...@deeprootsystems.com;
mche...@infradead.org
Cc: hverk...@xs4all.nl; davinci-linux-open-sou...@linux.davincidsp.com;
Karicheri, Muralidharan
Subject: [PATCH - v4 1/4] V4L-vpfe_capture-remove-clock and platform code
From: Muralidharan Karicheri m-kariche...@ti.com
Rebased to latest linux-next tree
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v1 of these patches.
In this patch, the clock configuration is moved to ccdc driver since clocks
are configured for ccdc. Also adding proper error codes for ccdc register
function and removing the ccdc memory resource handling.
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next tree of v4l-dvb
drivers/media/video/davinci/vpfe_capture.c | 131 +++-
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
- /* for storing mem maps for CCDC */
- int ccdc_addr_size;
- void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
- BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR vpfe capture not initialized\n);
- ret = -1;
+ ret = -EFAULT;
goto unlock;
}
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
ccdc_dev = dev;
- dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
-ccdc_cfg-ccdc_addr_size);
unlock:
mutex_unlock(ccdc_lock);
return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
- struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
- clk_disable(vpfe_cfg-vpssclk);
- clk_put(vpfe_cfg-vpssclk);
- clk_disable(vpfe_cfg-slaveclk);
- clk_put(vpfe_cfg-slaveclk);
- v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
- struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
- int ret = -ENOENT;
-
- vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
- if (NULL == vpfe_cfg-vpssclk) {
- v4l2_err(vpfe_dev-pdev-driver, No clock defined for
- vpss_master\n);
- return ret;
- }
-
- if (clk_enable(vpfe_cfg-vpssclk)) {
- v4l2_err(vpfe_dev-pdev-driver,
- vpfe vpss master clock not enabled\n);
- goto out;
- }
- v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss
RE: [PATCH - v4 4/4] DaVinci-vpfe-capture-converting-ccdc-drivers-to-platform-drivers
Kevin,
Reworked the patches and sent it again.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, January 11, 2010 4:36 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; mche...@infradead.org; hverk...@xs4all.nl;
davinci-linux-open-sou...@linux.davincidsp.com
Subject: Re: [PATCH - v4 4/4] DaVinci-vpfe-capture-converting-ccdc-drivers-
to-platform-drivers
m-kariche...@ti.com writes:
From: Muralidharan Karicheri m-kariche...@ti.com
Re-sending the patches based on Kevin's comments.
Following are the changes from v3 :-
- replaced CLK entries with clk_add_alias() calls
- removed unused vpss_master and vpss_slave entries
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated
comments
against v2 of these patches. Two new clocks master and slave are
defined for ccdc driver
as per comments from Kevin Hilman.
This adds platform code for ccdc driver on DM355 and DM6446.
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to Linus tree
arch/arm/mach-davinci/dm355.c | 58 --
-
arch/arm/mach-davinci/dm644x.c | 36 ++---
2 files changed, 50 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-
davinci/dm355.c
index dedf4d4..b4d0396 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -112,20 +112,6 @@ static struct clk vpss_dac_clk = {
.lpsc = DM355_LPSC_VPSS_DAC,
};
-static struct clk vpss_master_clk = {
-.name = vpss_master,
-.parent = pll1_sysclk4,
-.lpsc = DAVINCI_LPSC_VPSSMSTR,
-.flags = CLK_PSC,
-};
-
-static struct clk vpss_slave_clk = {
-.name = vpss_slave,
-.parent = pll1_sysclk4,
-.lpsc = DAVINCI_LPSC_VPSSSLV,
-};
I suggested removing the duplicate, not removing them both.
These nodes should stay, and the clock aliases should be created as
aliaes of these nodes (which can be enabled/disabled) and not the PLL
outputs directly.
static struct clk clkout1_clk = {
.name = clkout1,
.parent = pll1_aux_clk,
@@ -345,8 +331,6 @@ static struct davinci_clk dm355_clks[] = {
CLK(NULL, pll1_aux, pll1_aux_clk),
CLK(NULL, pll1_sysclkbp, pll1_sysclkbp),
CLK(NULL, vpss_dac, vpss_dac_clk),
-CLK(NULL, vpss_master, vpss_master_clk),
-CLK(NULL, vpss_slave, vpss_slave_clk),
CLK(NULL, clkout1, clkout1_clk),
CLK(NULL, clkout2, clkout2_clk),
CLK(NULL, pll2, pll2_clk),
@@ -665,6 +649,17 @@ static struct platform_device dm355_asp1_device = {
.resource = dm355_asp1_resources,
};
+static void dm355_ccdc_setup_pinmux(void)
+{
+davinci_cfg_reg(DM355_VIN_PCLK);
+davinci_cfg_reg(DM355_VIN_CAM_WEN);
+davinci_cfg_reg(DM355_VIN_CAM_VD);
+davinci_cfg_reg(DM355_VIN_CAM_HD);
+davinci_cfg_reg(DM355_VIN_YIN_EN);
+davinci_cfg_reg(DM355_VIN_CINL_EN);
+davinci_cfg_reg(DM355_VIN_CINH_EN);
+}
+
static struct resource dm355_vpss_resources[] = {
{
/* VPSS BL Base address */
@@ -701,6 +696,10 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm355_ccdc_resource[] = {
/* CCDC Base address */
{
.flags = IORESOURCE_MEM,
@@ -708,8 +707,18 @@ static struct resource vpfe_resources[] = {
.end= 0x01c70600 + 0x1ff,
},
};
+static struct platform_device dm355_ccdc_dev = {
+.name = dm355_ccdc,
+.id = -1,
+.num_resources = ARRAY_SIZE(dm355_ccdc_resource),
+.resource = dm355_ccdc_resource,
+.dev = {
+.dma_mask = vpfe_capture_dma_mask,
+.coherent_dma_mask = DMA_BIT_MASK(32),
+.platform_data = dm355_ccdc_setup_pinmux,
+},
+};
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
static struct platform_device vpfe_capture_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
@@ -857,20 +866,13 @@ static int __init dm355_init_devices(void)
if (!cpu_is_davinci_dm355())
return 0;
+/* Add ccdc clock aliases */
+clk_add_alias(master, dm355_ccdc_dev.name, pll1_sysclk4, NULL);
+clk_add_alias(slave, dm355_ccdc_dev.name, pll1_sysclk4, NULL);
Not quite, see above...
The aliases should be of the vpss nodes, not the PLL outputs which
cannot be enabled/disabled
RE: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
Kevin, OK, I'm not extremely familar with the whole video architecture here, but are all of these drivers expected to be doing clk_get() and clk_enable()? [MK]Many IPs on DaVinci VPFE would require vpss master clock. So it is better to do the way I have done in my patch. So it is expected that clk_get, clk_enable etc are called from other drivers as well. I thought the point of moving the clocks into the CCDC driver was so that the clock management was done in a single, shared space. [MK] No. The CCDC IP is used across DaVinci and OMAP SOCs. The clock is named differently on OMAP, but the IP requires two clocks. So we named them as master and slave as a generic name. OMAP, patform code will be mapping master and slave clocks to their respective clocks. We had discussed this in the email chain. Murali Kevin Your earlier suggestion was to use as follows :- - CLK(NULL, vpss_master, vpss_master_clk), - CLK(NULL, vpss_slave, vpss_slave_clk), + CLK(vpfe-capture, master, vpss_master_clk), + CLK(vpfe-capture, slave, vpss_slave_clk), I am not sure if the following will work so that it can be used across multiple drivers. + CLK(NULL, master, vpss_master_clk), + CLK(NULL, slave, vpss_slave_clk), If yes, I can re-do this patch. Please confirm. No, this will not work. You need a dev_id field so that matching is done using the struct device. My original suggestion was when you had the VPFE driver doing the clk_get(). Now that it's in CCDC, maybe it should look like this. -CLK(NULL, vpss_master, vpss_master_clk), -CLK(NULL, vpss_slave, vpss_slave_clk), +CLK(ccdc, master, vpss_master_clk), +CLK(ccdc, slave, vpss_slave_clk), Kevin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
Kevin, Can I remove it through a separate patch? This patch is already merged in Hans tree. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, January 07, 2010 2:44 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- sou...@linux.davincidsp.com Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver Karicheri, Muralidharan m-kariche...@ti.com writes: Kevin, OK, I'm not extremely familar with the whole video architecture here, but are all of these drivers expected to be doing clk_get() and clk_enable()? [MK]Many IPs on DaVinci VPFE would require vpss master clock. So it is better to do the way I have done in my patch. So it is expected that clk_get, clk_enable etc are called from other drivers as well. OK, then you are expecting to add clkdev nodes for the other devices as well. That's ok. However, you still haven't answered my original question. AFAICT, there are no users of the clkdev nodes vpss_master and vpss_slave. Why not remove those and replace them with your new nodes instead of leaving them and adding new ones? Kevin -- 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
building v4l-dvb - compilation error
Hi, I have installed mercurial and cloned the v4l-dvb tree. I tried doing a build as per instructions and I get the following error. Since I am in the process of validating my build environment, I am not sure if the following is a genuine build error or due to my environment... Other questions I have are:- 1) I am just doing make. So does this build all v4l2 drivers? 2) Which target this build for? 3) What output this build create? CC [M] /local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.o In file included from /local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.c:9: /local/mkaricheri/mercury/v4l-dvb/v4l/compat.h:463: warning: struct snd_card d eclared inside parameter list /local/mkaricheri/mercury/v4l-dvb/v4l/compat.h:463: warning: its scope is only t his definition or declaration, which is probably not what you want /local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.c:32: error: invalid lvalue i n unary `' /local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.c:32: error: initializer elem ent is not constant /local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.c:32: error: (near initializa tion for `__param_arr_atv_input.num') /local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.c:33: error: invalid lvalue i n unary `' /local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.c:33: error: initializer elem ent is not constant /local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.c:33: error: (near initializa tion for `__param_arr_dtv_input.num') make[3]: *** [/local/mkaricheri/mercury/v4l-dvb/v4l/tuner-simple.o] Error 1 make[2]: *** [_module_/local/mkaricheri/mercury/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/kernels/2.6.9-55.0.12.EL-smp-i686' make[1]: *** [default] Error 2 Murali Karicheri -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
Arch patches are not usually merged in Hans tree. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, January 07, 2010 4:50 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- sou...@linux.davincidsp.com Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver Karicheri, Muralidharan m-kariche...@ti.com writes: Can I remove it through a separate patch? This patch is already merged in Hans tree. Hmm, arch patches should not be merged yet as I have not ack'd them. Kevin -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, January 07, 2010 2:44 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- sou...@linux.davincidsp.com Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver Karicheri, Muralidharan m-kariche...@ti.com writes: Kevin, OK, I'm not extremely familar with the whole video architecture here, but are all of these drivers expected to be doing clk_get() and clk_enable()? [MK]Many IPs on DaVinci VPFE would require vpss master clock. So it is better to do the way I have done in my patch. So it is expected that clk_get, clk_enable etc are called from other drivers as well. OK, then you are expecting to add clkdev nodes for the other devices as well. That's ok. However, you still haven't answered my original question. AFAICT, there are no users of the clkdev nodes vpss_master and vpss_slave. Why not remove those and replace them with your new nodes instead of leaving them and adding new ones? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
CLK(NULL, rto, rto_clk),
CLK(NULL, usb, usb_clk),
+CLK(dm355_ccdc, master, vpss_master_clk),
+CLK(dm355_ccdc, slave, vpss_slave_clk),
I still don't understand why you have to add new entries here and
can't simply rename the existing CLK nodes using vpss_*_clk.
[MK] This will allow multiple drivers define their own clocks derived from
these. ccdc driver is not the only driver using these clocks. Your earlier
suggestion was to use as follows :-
- CLK(NULL, vpss_master, vpss_master_clk),
- CLK(NULL, vpss_slave, vpss_slave_clk),
+ CLK(vpfe-capture, master, vpss_master_clk),
+ CLK(vpfe-capture, slave, vpss_slave_clk),
I am not sure if the following will work so that it can be used across
multiple drivers.
+ CLK(NULL, master, vpss_master_clk),
+ CLK(NULL, slave, vpss_slave_clk),
If yes, I can re-do this patch. Please confirm.
Same comment for dm644x.c changes.
Kevin
CLK(NULL, NULL, NULL),
};
@@ -665,6 +667,17 @@ static struct platform_device dm355_asp1_device = {
.resource = dm355_asp1_resources,
};
+static void dm355_ccdc_setup_pinmux(void)
+{
+davinci_cfg_reg(DM355_VIN_PCLK);
+davinci_cfg_reg(DM355_VIN_CAM_WEN);
+davinci_cfg_reg(DM355_VIN_CAM_VD);
+davinci_cfg_reg(DM355_VIN_CAM_HD);
+davinci_cfg_reg(DM355_VIN_YIN_EN);
+davinci_cfg_reg(DM355_VIN_CINL_EN);
+davinci_cfg_reg(DM355_VIN_CINH_EN);
+}
+
static struct resource dm355_vpss_resources[] = {
{
/* VPSS BL Base address */
@@ -701,6 +714,10 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm355_ccdc_resource[] = {
/* CCDC Base address */
{
.flags = IORESOURCE_MEM,
@@ -708,8 +725,18 @@ static struct resource vpfe_resources[] = {
.end= 0x01c70600 + 0x1ff,
},
};
+static struct platform_device dm355_ccdc_dev = {
+.name = dm355_ccdc,
+.id = -1,
+.num_resources = ARRAY_SIZE(dm355_ccdc_resource),
+.resource = dm355_ccdc_resource,
+.dev = {
+.dma_mask = vpfe_capture_dma_mask,
+.coherent_dma_mask = DMA_BIT_MASK(32),
+.platform_data = dm355_ccdc_setup_pinmux,
+},
+};
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
static struct platform_device vpfe_capture_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
@@ -860,17 +887,7 @@ static int __init dm355_init_devices(void)
davinci_cfg_reg(DM355_INT_EDMA_CC);
platform_device_register(dm355_edma_device);
platform_device_register(dm355_vpss_device);
-/*
- * setup Mux configuration for vpfe input and register
- * vpfe capture platform device
- */
-davinci_cfg_reg(DM355_VIN_PCLK);
-davinci_cfg_reg(DM355_VIN_CAM_WEN);
-davinci_cfg_reg(DM355_VIN_CAM_VD);
-davinci_cfg_reg(DM355_VIN_CAM_HD);
-davinci_cfg_reg(DM355_VIN_YIN_EN);
-davinci_cfg_reg(DM355_VIN_CINL_EN);
-davinci_cfg_reg(DM355_VIN_CINH_EN);
+platform_device_register(dm355_ccdc_dev);
platform_device_register(vpfe_capture_dev);
return 0;
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-
davinci/dm644x.c
index e65e29e..e5f1ee9 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -315,6 +315,8 @@ struct davinci_clk dm644x_clks[] = {
CLK(NULL, timer0, timer0_clk),
CLK(NULL, timer1, timer1_clk),
CLK(watchdog, NULL, timer2_clk),
+CLK(dm644x_ccdc, master, vpss_master_clk),
+CLK(dm644x_ccdc, slave, vpss_slave_clk),
CLK(NULL, NULL, NULL),
};
@@ -612,6 +614,11 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm644x_ccdc_resource[] = {
+/* CCDC Base address */
{
.start = 0x01c70400,
.end= 0x01c70400 + 0xff,
@@ -619,7 +626,17 @@ static struct resource vpfe_resources[] = {
},
};
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct platform_device dm644x_ccdc_dev = {
+.name = dm644x_ccdc,
+.id = -1,
+.num_resources = ARRAY_SIZE(dm644x_ccdc_resource),
+.resource = dm644x_ccdc_resource,
+.dev = {
+.dma_mask = vpfe_capture_dma_mask,
+.coherent_dma_mask = DMA_BIT_MASK(32),
+},
+};
+
static struct platform_device vpfe_capture_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
@@ -772,6 +789,7 @@ static int __init dm644x_init_devices(void)
RE: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
display, resizer drivers etc... Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, January 06, 2010 11:04 AM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- sou...@linux.davincidsp.com Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver Karicheri, Muralidharan m-kariche...@ti.com writes: CLK(NULL, rto, rto_clk), CLK(NULL, usb, usb_clk), + CLK(dm355_ccdc, master, vpss_master_clk), + CLK(dm355_ccdc, slave, vpss_slave_clk), I still don't understand why you have to add new entries here and can't simply rename the existing CLK nodes using vpss_*_clk. [MK] This will allow multiple drivers define their own clocks derived from these. ccdc driver is not the only driver using these clocks. OK, but that still doesn't answer why you need multiple CLK() nodes. Who else is using the clocks? Your earlier suggestion was to use as follows :- -CLK(NULL, vpss_master, vpss_master_clk), -CLK(NULL, vpss_slave, vpss_slave_clk), +CLK(vpfe-capture, master, vpss_master_clk), +CLK(vpfe-capture, slave, vpss_slave_clk), I am not sure if the following will work so that it can be used across multiple drivers. +CLK(NULL, master, vpss_master_clk), +CLK(NULL, slave, vpss_slave_clk), If yes, I can re-do this patch. Please confirm. No, this will not work. You need a dev_id field so that matching is done using the struct device. My original suggestion was when you had the VPFE driver doing the clk_get(). Now that it's in CCDC, maybe it should look like this. - CLK(NULL, vpss_master, vpss_master_clk), - CLK(NULL, vpss_slave, vpss_slave_clk), + CLK(ccdc, master, vpss_master_clk), + CLK(ccdc, slave, vpss_slave_clk), Kevin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hans, Thanks for this pull request.. I gather that Murali and you have figured out the right order to merge this, so I leave the details to the both of you. Not really :( I haven't seen a response to my last email on this. Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. Do you suggest creating separate arch part source for hg tree and upstream? (I see you have arch folders in the hg tree, but only few architectures currently supported mx*/px*). If so, how is the upstream merge of arch code handled in your case? My question is when the v4l part is merged, the corresponding arch part has to be merged as well to compile the upstream code base. So this is not going to solve the issue that we are facing currently. May be I am not getting the full picture here. BTW, I am okay to have an account in the hg tree. Is there a quick tutorial to understand the process and tools needed to get me started? Regards, Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Wednesday, December 30, 2009 8:49 AM To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab; Karicheri, Muralidharan; khil...@deeprootsystems.com Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver - V4L: vpfe capture: header files for ISIF driver - V4L: vpfe capture: source for ISIF driver on DM365 - V4L: vpfe capture: vpss driver enhancements for DM365 - V4L: vpfe_capture: bug fixes and enhancements - V4L: vpfe capture: build environment for isif driver And after the first three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ And after the other four patches are pulled in, then this arch patch should be merged for git: http://patchwork.kernel.org/patch/68876/ Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. I also think it is a good idea if you ask for an account on linuxtv.org so that you can set up your own hg trees and you don't have to wait for me. Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/isif.c | 1512 +++ b/linux/drivers/media/video/davinci/isif_regs.h | 269 b/linux/include/media/davinci/isif.h | 531 linux/drivers/media/video/Kconfig| 14 linux/drivers/media/video/davinci/Makefile |1 linux/drivers/media/video/davinci/dm355_ccdc.c | 413 +++--- linux/drivers/media/video/davinci/dm644x_ccdc.c | 362 +++-- linux/drivers/media/video/davinci/vpfe_capture.c | 254 +-- linux/drivers/media/video/davinci/vpss.c | 289 +++- linux/include/media/davinci/vpfe_capture.h | 12 linux/include/media/davinci/vpss.h | 41 11 files changed, 3180 insertions(+), 518 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG
help on mercurial
Hi,
I am trying to build and install mercurial 1.4 on my Redhat Linux machine. I
could build and install python. When building mercurial, I got following
error log:-
make all
= error log...
python setup.py build
File setup.py, line 147
for l in open('.hg_archival.txt'))
^
SyntaxError: invalid syntax.
I am trying to learn mercurial for hosting my own hg tree and ended up here :(.
Any help will be appreciated.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Mauro, What do you suggest for the existing 2 pull requests from Hans? I had suggested something in my last email to do this in 2 steps based on Kevin's proposal. 1) Merge the patches (including arch patches) to linux-next tree based on Hans's pull request. 2) When upstream merge window opens and Kevin's davinci tree is merged to Linus tree, drop the arch patches from v4l-dvb. We could re-work the dropped patches based on Linus tree and send the same to you. Do you think this is doable? If so, please merge these pull requests to linux-next. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Wednesday, December 30, 2009 5:25 PM To: Karicheri, Muralidharan Cc: Hans Verkuil; linux-media@vger.kernel.org; khil...@deeprootsystems.com Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Karicheri, Muralidharan wrote: Hans, Thanks for this pull request.. I gather that Murali and you have figured out the right order to merge this, so I leave the details to the both of you. Not really :( I haven't seen a response to my last email on this. Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. Do you suggest creating separate arch part source for hg tree and upstream? (I see you have arch folders in the hg tree, but only few architectures currently supported mx*/px*). If so, how is the upstream merge of arch code handled in your case? My question is when the v4l part is merged, the corresponding arch part has to be merged as well to compile the upstream code base. So this is not going to solve the issue that we are facing currently. May be I am not getting the full picture here. The issue is that non-v4l platform data changes that happens on the same headers where you have also v4l platform data changes cause lots of merge troubles. This happens with -hg, but this also would happen if I just merge from a - git tree. So, the problem is not about having a different procedure due to -hg, but having a way to avoid having merge conflicts every time an omap driver (or another driver that uses the platform_data stuff) is merged. On my experiences, the non-Intel arch headers used by V4L drivers got renamed, had several api changes and mixed several different subsystems at the same header, causing all sorts of merge conflicts. Since the soc_camera and omap drivers got merged, on every single kernel version, we had some sort of conflict to manage. On several cases, git bisect got broken, and we had even some worse case scenarios where the arch compilation got broken for some time, due to those conflicts. BTW, I am okay to have an account in the hg tree. Is there a quick tutorial to understand the process and tools needed to get me started? I can send you one, but maybe it is a little late for it, since my intention is to start discussing and working to replace -hg to -git at the beginning of 2010, if time allows me to do that. Cheers, Mauro.
RE: [PATCH - v2 4/6] V4L - vpfe_capture - bug fixes and enhancements
Hans,
If you are okay with this patch, could you please merge this to
your -hg tree and send a pull request to Mauro to merge to the
linux-next tree? This depends on the previous patch set which is
waiting for Mauro's merge.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, December 23, 2009 10:26 AM
To: 'Hans Verkuil'
Cc: linux-media@vger.kernel.org; khil...@deeprootsystems.com; Hiremath,
Vaibhav; Nori, Sekhar; davinci-linux-open-sou...@linux.davincidsp.com
Subject: RE: [PATCH - v2 4/6] V4L - vpfe_capture - bug fixes and
enhancements
Hans,
The change is because of the void * type that we use. Since ccdc parameter
structures are different for different IPs, a constant type for this arg
is not possible. The ccdc driver needs the pointer to structure. But the
v4l2 core tries to copies 4 bytes of data from the void * pointed location
which is not what we want. I am sure this code will change once we have a
device node available for ccdc on which case, this ioctl will be handled by
the ccdc sub device node. The long term goal is to convert ccdc/isif
drivers
to sub device and pass this user ioctl to that sub device node. But
currently we don't have support for device nodes for sub devices. I think
that is needed for this conversion to be complete.
BTW, does this patch series rely on the patches in my v4l-dvb-davinci
tree?
Or are these independent patches?
Yes, this is dependent on my earlier patch. I had asked Mauro to merge that
patch to linux-next, but still waiting
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Wednesday, December 23, 2009 9:24 AM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; khil...@deeprootsystems.com; Hiremath,
Vaibhav; Nori, Sekhar; davinci-linux-open-sou...@linux.davincidsp.com
Subject: Re: [PATCH - v2 4/6] V4L - vpfe_capture - bug fixes and
enhancements
Hi Murali,
Sorry for the long delay in reviewing this patch series. I've been very
busy,
first at work, and now for Christmas preparations (and occasionally I'd
like
to relax as well :-) ).
I'm OK with the other patches in this series, but I do have a few comments
on this one: I noticed that you added a wrapper function for video_ioctl2.
I don't quite understand why.
BTW, does this patch series rely on the patches in my v4l-dvb-davinci
tree?
Or are these independent patches? Is it because the experimental
VPFE_CMD_S/G_CCDC_RAW_PARAMS ioctls are used with different argument
pointers?
I mean, currently the arg is a void * instead of a properly typed argument.
However, if it always uses the same type, then you should use that type in
_IOR/_IOW and use video_ioctl2 directly so that the core framework will do
the
user-to-kernelspace conversion (and vv) for you.
Regards,
Hans
On Saturday 19 December 2009 00:58:25 m-kariche...@ti.com wrote:
From: Muralidharan Karicheri m-kariche...@ti.com
Updated based on comments against v1 of the patch
Added a experimental IOCTL, to read the CCDC parameters.
Default handler was not getting the original pointer from the core.
So a wrapper function added to handle the default handler properly.
Also fixed a bug in the probe() in the linux-next tree
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next of v4l-dvb
drivers/media/video/davinci/vpfe_capture.c | 120 +
-
--
include/media/davinci/vpfe_capture.h | 12 ++-
2 files changed, 81 insertions(+), 51 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 9e3a531..99ffc62 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -758,12 +758,83 @@ static unsigned int vpfe_poll(struct file *file,
poll_table *wait)
return 0;
}
+static long vpfe_param_handler(struct file *file, void *priv,
+ int cmd, void *param)
+{
+ struct vpfe_device *vpfe_dev = video_drvdata(file);
+ int ret = 0;
+
+ v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_param_handler\n);
+
+ if (NULL == param) {
+ v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+ Invalid user ptr\n);
+ return -EINVAL;
+ }
+
+ if (vpfe_dev-started) {
+ /* only allowed if streaming is not started */
+ v4l2_err(vpfe_dev-v4l2_dev, device already started\n);
+ return -EBUSY;
+ }
+
+ switch (cmd) {
+ case VPFE_CMD_S_CCDC_RAW_PARAMS:
+ v4l2_warn(vpfe_dev-v4l2_dev,
+ VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n);
+ ret = mutex_lock_interruptible(vpfe_dev-lock
RE: [PATCH - v2 4/6] V4L - vpfe_capture - bug fixes and enhancements
Hans,
The change is because of the void * type that we use. Since ccdc parameter
structures are different for different IPs, a constant type for this arg
is not possible. The ccdc driver needs the pointer to structure. But the
v4l2 core tries to copies 4 bytes of data from the void * pointed location
which is not what we want. I am sure this code will change once we have a
device node available for ccdc on which case, this ioctl will be handled by the
ccdc sub device node. The long term goal is to convert ccdc/isif drivers
to sub device and pass this user ioctl to that sub device node. But currently
we don't have support for device nodes for sub devices. I think
that is needed for this conversion to be complete.
BTW, does this patch series rely on the patches in my v4l-dvb-davinci tree?
Or are these independent patches?
Yes, this is dependent on my earlier patch. I had asked Mauro to merge that
patch to linux-next, but still waiting
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Wednesday, December 23, 2009 9:24 AM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; khil...@deeprootsystems.com; Hiremath,
Vaibhav; Nori, Sekhar; davinci-linux-open-sou...@linux.davincidsp.com
Subject: Re: [PATCH - v2 4/6] V4L - vpfe_capture - bug fixes and
enhancements
Hi Murali,
Sorry for the long delay in reviewing this patch series. I've been very
busy,
first at work, and now for Christmas preparations (and occasionally I'd
like
to relax as well :-) ).
I'm OK with the other patches in this series, but I do have a few comments
on this one: I noticed that you added a wrapper function for video_ioctl2.
I don't quite understand why.
BTW, does this patch series rely on the patches in my v4l-dvb-davinci tree?
Or are these independent patches? Is it because the experimental
VPFE_CMD_S/G_CCDC_RAW_PARAMS ioctls are used with different argument
pointers?
I mean, currently the arg is a void * instead of a properly typed argument.
However, if it always uses the same type, then you should use that type in
_IOR/_IOW and use video_ioctl2 directly so that the core framework will do
the
user-to-kernelspace conversion (and vv) for you.
Regards,
Hans
On Saturday 19 December 2009 00:58:25 m-kariche...@ti.com wrote:
From: Muralidharan Karicheri m-kariche...@ti.com
Updated based on comments against v1 of the patch
Added a experimental IOCTL, to read the CCDC parameters.
Default handler was not getting the original pointer from the core.
So a wrapper function added to handle the default handler properly.
Also fixed a bug in the probe() in the linux-next tree
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next of v4l-dvb
drivers/media/video/davinci/vpfe_capture.c | 120 +-
--
include/media/davinci/vpfe_capture.h | 12 ++-
2 files changed, 81 insertions(+), 51 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 9e3a531..99ffc62 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -758,12 +758,83 @@ static unsigned int vpfe_poll(struct file *file,
poll_table *wait)
return 0;
}
+static long vpfe_param_handler(struct file *file, void *priv,
+int cmd, void *param)
+{
+struct vpfe_device *vpfe_dev = video_drvdata(file);
+int ret = 0;
+
+v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_param_handler\n);
+
+if (NULL == param) {
+v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+Invalid user ptr\n);
+return -EINVAL;
+}
+
+if (vpfe_dev-started) {
+/* only allowed if streaming is not started */
+v4l2_err(vpfe_dev-v4l2_dev, device already started\n);
+return -EBUSY;
+}
+
+switch (cmd) {
+case VPFE_CMD_S_CCDC_RAW_PARAMS:
+v4l2_warn(vpfe_dev-v4l2_dev,
+ VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n);
+ret = mutex_lock_interruptible(vpfe_dev-lock);
+if (ret)
+return ret;
+ret = ccdc_dev-hw_ops.set_params(param);
+if (ret) {
+v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+Error in setting parameters in CCDC\n);
+goto unlock_out;
+}
+
+if (vpfe_get_ccdc_image_format(vpfe_dev, vpfe_dev-fmt) 0) {
+v4l2_err(vpfe_dev-v4l2_dev,
+Invalid image format at CCDC\n);
+ret = -EINVAL;
+}
+unlock_out:
+mutex_unlock(vpfe_dev-lock);
+break;
+case VPFE_CMD_G_CCDC_RAW_PARAMS
RE: [PATCH - v2 1/6] V4L - vpfe capture - header files for ISIF driver
Hi Hans, If there are no more comments on this patch set, could you please merge this to your hg tree? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Karicheri, Muralidharan Sent: Friday, December 18, 2009 6:58 PM To: linux-media@vger.kernel.org; hverk...@xs4all.nl; khil...@deeprootsystems.com; Hiremath, Vaibhav; Nori, Sekhar Cc: davinci-linux-open-sou...@linux.davincidsp.com; Karicheri, Muralidharan Subject: [PATCH - v2 1/6] V4L - vpfe capture - header files for ISIF driver From: Muralidharan Karicheri m-kariche...@ti.com Updated based on comments against v1 of the patch This is the header file for ISIF driver on DM365. ISIF driver is equivalent to CCDC driver on DM355 and DM644x. This driver is tested for YUV capture from TVP514x driver. This patch contains the header files required for this driver. The name of the file is changed to reflect the name of IP. Reviewed-by: Nori, Sekhar nsek...@ti.com Reviewed-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- Applies to linux-next tree of v4l-dvb drivers/media/video/davinci/isif_regs.h | 269 include/media/davinci/isif.h| 531 +++ 2 files changed, 800 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/isif_regs.h create mode 100644 include/media/davinci/isif.h diff --git a/drivers/media/video/davinci/isif_regs.h b/drivers/media/video/davinci/isif_regs.h new file mode 100644 index 000..f7b8893 --- /dev/null +++ b/drivers/media/video/davinci/isif_regs.h @@ -0,0 +1,269 @@ +/* + * Copyright (C) 2008-2009 Texas Instruments Inc + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#ifndef _ISIF_REGS_H +#define _ISIF_REGS_H + +/* ISIF registers relative offsets */ +#define SYNCEN0x00 +#define MODESET 0x04 +#define HDW 0x08 +#define VDW 0x0c +#define PPLN 0x10 +#define LPFR 0x14 +#define SPH 0x18 +#define LNH 0x1c +#define SLV0 0x20 +#define SLV1 0x24 +#define LNV 0x28 +#define CULH 0x2c +#define CULV 0x30 +#define HSIZE 0x34 +#define SDOFST0x38 +#define CADU 0x3c +#define CADL 0x40 +#define LINCFG0 0x44 +#define LINCFG1 0x48 +#define CCOLP 0x4c +#define CRGAIN0x50 +#define CGRGAIN 0x54 +#define CGBGAIN 0x58 +#define CBGAIN0x5c +#define COFSTA0x60 +#define FLSHCFG0 0x64 +#define FLSHCFG1 0x68 +#define FLSHCFG2 0x6c +#define VDINT00x70 +#define VDINT10x74 +#define VDINT20x78 +#define MISC 0x7c +#define CGAMMAWD 0x80 +#define REC656IF 0x84 +#define CCDCFG0x88 +/* +* Defect Correction registers +*/ +#define DFCCTL0x8c +#define VDFSATLV 0x90 +#define DFCMEMCTL 0x94 +#define DFCMEM0 0x98 +#define DFCMEM1 0x9c +#define DFCMEM2
RE: [PATCH] Davinci VPFE Capture: Add Suspend/Resume Support
Vaibhav,
Did you address my comments against this patch? What was
the resolution. I haven't seen any response from you. Please
forward me any response that you had sent.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hiremath, Vaibhav
Sent: Monday, December 21, 2009 1:29 AM
To: Karicheri, Muralidharan; linux-media@vger.kernel.org
Cc: hverk...@xs4all.nl
Subject: RE: [PATCH] Davinci VPFE Capture: Add Suspend/Resume Support
-Original Message-
From: Karicheri, Muralidharan
Sent: Friday, November 20, 2009 3:31 AM
To: Hiremath, Vaibhav; linux-media@vger.kernel.org
Cc: hverk...@xs4all.nl
Subject: RE: [PATCH] Davinci VPFE Capture: Add Suspend/Resume
Support
Vaibhav,
I have some comments. I have tested this patch for normal
use case of tvp5146 capture on DM355. It looks ok. We
don't have support for power management on DM355. So I couldn't
test the suspend resume operations.
[Hiremath, Vaibhav] Murali,
If you don't any further comments/analysis, this patch should go in. I will
resubmit the patch against the tip.
Thanks,
Vaibhav
struct ccdc_hw_device {
diff --git a/drivers/media/video/davinci/dm644x_ccdc.c
b/drivers/media/video/davinci/dm644x_ccdc.c
index 5dff8d9..fdab823 100644
--- a/drivers/media/video/davinci/dm644x_ccdc.c
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -88,6 +88,10 @@ static void *__iomem ccdc_base_addr;
static int ccdc_addr_size;
static enum vpfe_hw_if_type ccdc_if_type;
+#define CCDC_SZ_REGS SZ_1K
+
+static u32 ccdc_ctx[CCDC_SZ_REGS / sizeof(u32)];
The last register is at 0x94 on DM6446. So do we need 256
entries when we have only 37 registers?
+
/* register access routines */
static inline u32 regr(u32 offset)
{
@@ -834,6 +838,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] = regr(CCDC_PCR);
For this and below, You are using every 4th location in the array
for saving register values which is not necessary if you use
something like.
ccdc_ctx[CCDC_PCR 2] = regr(CCDC_PCR);
ccdc_ctx[CCDC_SYN_MODE 2] = regr(CCDC_SYN_MODE);
Any reason why you do this way?
+ ccdc_ctx[CCDC_SYN_MODE] = regr(CCDC_SYN_MODE);
+ ccdc_ctx[CCDC_HD_VD_WID] = regr(CCDC_HD_VD_WID);
+ ccdc_ctx[CCDC_PIX_LINES] = regr(CCDC_PIX_LINES);
+ ccdc_ctx[CCDC_HORZ_INFO] = regr(CCDC_HORZ_INFO);
+ ccdc_ctx[CCDC_VERT_START] = regr(CCDC_VERT_START);
+ ccdc_ctx[CCDC_VERT_LINES] = regr(CCDC_VERT_LINES);
+ ccdc_ctx[CCDC_CULLING] = regr(CCDC_CULLING);
+ ccdc_ctx[CCDC_HSIZE_OFF] = regr(CCDC_HSIZE_OFF);
+ ccdc_ctx[CCDC_SDOFST] = regr(CCDC_SDOFST);
+ ccdc_ctx[CCDC_SDR_ADDR] = regr(CCDC_SDR_ADDR);
+ ccdc_ctx[CCDC_CLAMP] = regr(CCDC_CLAMP);
+ ccdc_ctx[CCDC_DCSUB] = regr(CCDC_DCSUB);
+ ccdc_ctx[CCDC_COLPTN] = regr(CCDC_COLPTN);
+ ccdc_ctx[CCDC_BLKCMP] = regr(CCDC_BLKCMP);
+ ccdc_ctx[CCDC_FPC] = regr(CCDC_FPC);
+ ccdc_ctx[CCDC_FPC_ADDR] = regr(CCDC_FPC_ADDR);
+ ccdc_ctx[CCDC_VDINT] = regr(CCDC_VDINT);
+ ccdc_ctx[CCDC_ALAW] = regr(CCDC_ALAW);
+ ccdc_ctx[CCDC_REC656IF] = regr(CCDC_REC656IF);
+ ccdc_ctx[CCDC_CCDCFG] = regr(CCDC_CCDCFG);
+ ccdc_ctx[CCDC_FMTCFG] = regr(CCDC_FMTCFG);
+ ccdc_ctx[CCDC_FMT_HORZ] = regr(CCDC_FMT_HORZ);
+ ccdc_ctx[CCDC_FMT_VERT] = regr(CCDC_FMT_VERT);
+ ccdc_ctx[CCDC_FMT_ADDR0] = regr(CCDC_FMT_ADDR0);
+ ccdc_ctx[CCDC_FMT_ADDR1] = regr(CCDC_FMT_ADDR1);
+ ccdc_ctx[CCDC_FMT_ADDR2] = regr(CCDC_FMT_ADDR2);
+ ccdc_ctx[CCDC_FMT_ADDR3] = regr(CCDC_FMT_ADDR3);
+ ccdc_ctx[CCDC_FMT_ADDR4] = regr(CCDC_FMT_ADDR4);
+ ccdc_ctx[CCDC_FMT_ADDR5] = regr(CCDC_FMT_ADDR5);
+ ccdc_ctx[CCDC_FMT_ADDR6] = regr(CCDC_FMT_ADDR6);
+ ccdc_ctx[CCDC_FMT_ADDR7] = regr(CCDC_FMT_ADDR7);
+ ccdc_ctx[CCDC_PRGEVEN_0] = regr(CCDC_PRGEVEN_0);
+ ccdc_ctx[CCDC_PRGEVEN_1] = regr(CCDC_PRGEVEN_1);
+ ccdc_ctx[CCDC_PRGODD_0] = regr(CCDC_PRGODD_0);
+ ccdc_ctx[CCDC_PRGODD_1] = regr(CCDC_PRGODD_1);
+ ccdc_ctx[CCDC_VP_OUT] = regr(CCDC_VP_OUT);
+}
+
+static void ccdc_restore_context(void)
+{
+ regw(ccdc_ctx[CCDC_SYN_MODE], CCDC_SYN_MODE);
+ regw(ccdc_ctx[CCDC_HD_VD_WID], CCDC_HD_VD_WID);
+ regw(ccdc_ctx[CCDC_PIX_LINES], CCDC_PIX_LINES);
+ regw(ccdc_ctx[CCDC_HORZ_INFO], CCDC_HORZ_INFO);
+ regw(ccdc_ctx[CCDC_VERT_START], CCDC_VERT_START);
+ regw(ccdc_ctx[CCDC_VERT_LINES], CCDC_VERT_LINES);
+ regw(ccdc_ctx[CCDC_CULLING], CCDC_CULLING);
+ regw(ccdc_ctx[CCDC_HSIZE_OFF], CCDC_HSIZE_OFF);
+ regw(ccdc_ctx[CCDC_SDOFST], CCDC_SDOFST);
+ regw(ccdc_ctx[CCDC_SDR_ADDR], CCDC_SDR_ADDR);
+ regw(ccdc_ctx[CCDC_CLAMP], CCDC_CLAMP);
+ regw(ccdc_ctx[CCDC_DCSUB], CCDC_DCSUB);
+ regw(ccdc_ctx[CCDC_COLPTN], CCDC_COLPTN);
+ regw(ccdc_ctx[CCDC_BLKCMP], CCDC_BLKCMP);
+ regw(ccdc_ctx[CCDC_FPC], CCDC_FPC);
+ regw(ccdc_ctx
RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Mauro, Kevin is going to merge the arch part #67669 as we did last time. Please merge only the v4l2 part. I have copied Kevin in this email. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Thursday, December 17, 2009 6:18 AM To: Hans Verkuil Cc: linux-media@vger.kernel.org; Karicheri, Muralidharan Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver And after these three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ Hmm... It seems that git bisect will break if I merge first the conversion and then the platform_data patches. Also, we had some bad merge dependency troubles last time I merged an arch patch on my tree, as those omap arch header files are highly volatile. I bet that, if I merge the patch #67669 on my tree it will cause conflicts when I send it during the next merge window (and it is too late for sending those patches to linux-next, wait for a couple days and send upstream before -rc1). Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hans Mauro, I have already replied to Mauro's email. This is what we had followed last time for vpfe capture. Mauro will merge the v4l2 part and Kevin will merge the arch part. These needs be done in sync so that it will compile fine in the upstream. Let me know if this cannot be done this time. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Thursday, December 17, 2009 6:30 AM To: Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org; Karicheri, Muralidharan Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver And after these three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ Hmm... It seems that git bisect will break if I merge first the conversion and then the platform_data patches. Murali, what is the correct merge order? I assumed that the order you gave me was 'safe' (as in, it always compiles after each patch). I did compile the v4l patches, but I did not check if there was any breakage if I build the full kernel. Also, we had some bad merge dependency troubles last time I merged an arch patch on my tree, as those omap arch header files are highly volatile. I bet that, if I merge the patch #67669 on my tree it will cause conflicts when I send it during the next merge window (and it is too late for sending those patches to linux-next, wait for a couple days and send upstream before -rc1). Cheers, Mauro. So what do you want me or Murali to do? Wait until rc1 is released and then make sure that the arch patch will apply correctly to what is in rc1? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v1 4/6] V4L - vpfe_capture bug fix and enhancements
hans, Yes, isif_config_bclamp() set values in the register. Huh? That does not explain why apparently bc-horz.win_h_sz_calc can be larger than ISIF_HORZ_BC_WIN_H_SIZE_MASK. because the values come from the user and since we can't use the enum for the types, I have to make sure the value is within range. Other way to do is to check the value in the validate() function. I am inclined to do the validation so that the statements with masks can be removed while setting it in the register. Regards, Hans It would be interesting to know if people know of good ways of making awkward code like this more elegant (or at least less awkward). Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
FW: [PATCH - v3 1/4] V4L - vpfe_capture - remove clock and ccdc resource handling
Hans,
This has gone through multiple revisions after review and If you don't
have any comments against this series, could you merge this to your -hg
tree? DM365 patch series is dependent on this one. So if you can merge
this one ASAP, it will be great.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, December 15, 2009 11:38 AM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Karicheri, Muralidharan
Subject: [PATCH - v3 1/4] V4L - vpfe_capture - remove clock and ccdc
resource handling
From: Muralidharan Karicheri m-kariche...@ti.com
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v1 of these patches.
In this patch, the clock configuration is moved to ccdc driver since clocks
are configured for ccdc. Also adding proper error codes for ccdc register
function and removing the ccdc memory resource handling.
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next branch of v4l-dvb
drivers/media/video/davinci/vpfe_capture.c | 134 +++-
---
1 files changed, 15 insertions(+), 119 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 8dc9030..5c98d0c 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -108,9 +108,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
- /* for storing mem maps for CCDC */
- int ccdc_addr_size;
- void *__iomem ccdc_addr;
};
/* data structures */
@@ -230,7 +227,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
- BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
mutex_lock(ccdc_lock);
@@ -241,25 +237,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR vpfe capture not initialized\n);
- ret = -1;
+ ret = -EFAULT;
goto unlock;
}
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
ccdc_dev = dev;
- dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
-ccdc_cfg-ccdc_addr_size);
unlock:
mutex_unlock(ccdc_lock);
return ret;
@@ -1787,61 +1781,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
- struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
- clk_disable(vpfe_cfg-vpssclk);
- clk_put(vpfe_cfg-vpssclk);
- clk_disable(vpfe_cfg-slaveclk);
- clk_put(vpfe_cfg-slaveclk);
- v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
- struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
- int ret = -ENOENT;
-
- vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
- if (NULL == vpfe_cfg-vpssclk) {
- v4l2_err(vpfe_dev-pdev-driver, No clock defined for
- vpss_master\n);
- return ret;
- }
-
- if (clk_enable(vpfe_cfg-vpssclk)) {
- v4l2_err(vpfe_dev-pdev-driver,
- vpfe vpss master clock not enabled\n);
- goto out;
- }
- v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master clock enabled\n);
-
- vpfe_cfg-slaveclk = clk_get(vpfe_dev-pdev, vpss_slave);
- if (NULL == vpfe_cfg-slaveclk) {
- v4l2_err(vpfe_dev-pdev-driver,
- No clock defined for vpss slave\n);
- goto out;
- }
-
- if (clk_enable(vpfe_cfg-slaveclk)) {
- v4l2_err(vpfe_dev-pdev-driver,
- vpfe vpss slave clock not enabled\n);
- goto out;
- }
- v4l2_info(vpfe_dev-pdev-driver, vpfe vpss slave clock enabled\n);
- return 0;
-out:
- if (vpfe_cfg-vpssclk)
- clk_put(vpfe_cfg-vpssclk);
- if (vpfe_cfg-slaveclk)
- clk_put(vpfe_cfg-slaveclk);
-
- return -1
RE: [PATCH - v1 4/6] V4L - vpfe_capture bug fix and enhancements
Hans, I remember there was a comment against an earlier patch that asks for combining such statements since it makes the function appear as big. Not sure who had made that comment. That is the reason you find code like this in this patch. It was initially done with multiple OR statements to construct the value to be written to the register as you stated below as val = bc-horz.win_count_calc ISIF_HORZ_BC_WIN_COUNT_MASK; val |= !!bc-horz.base_win_sel_calc ISIF_HORZ_BC_WIN_SEL_SHIFT; I have checked few other drivers such as bt819.c ir-kbd-i2c.c, mt9m111.c etc, where similar statements are found, but they have used hardcoded values masks which makes it appears less complex. But I like to reduce magic numbers as much possible in the code. I think what I can do is to combine maximum of 2 such expressions in a statement which might make it less complex to read. Such as val = (bc-horz.win_count_calc ISIF_HORZ_BC_WIN_COUNT_MASK) | ((!!bc-horz.base_win_sel_calc) ISIF_HORZ_BC_WIN_SEL_SHIFT); val |= (!!bc-horz.clamp_pix_limit) ISIF_HORZ_BC_PIX_LIMIT_SHIFT) | ((bc-horz.win_h_sz_calc ISIF_HORZ_BC_WIN_H_SIZE_MASK) ISIF_HORZ_BC_WIN_H_SIZE_SHIFT); val |= ((bc-horz.win_v_sz_calc ISIF_HORZ_BC_WIN_V_SIZE_MASK) ISIF_HORZ_BC_WIN_V_SIZE_SHIFT); Also to make the line fits in 80 characters, I will consider reducing the number of characters in #define names such as val = (bc-horz.win_count_calc HZ_BC_WIN_CNT_MASK) | ((!!bc-horz.base_win_sel_calc) HZ_BC_WIN_SEL_SHIFT) | (!!bc-horz.clamp_pix_limit) HZ_BC_PIX_LIMIT_SHIFT); Let me know if you don't agree. Of course, in this particular piece of code from the function isif_config_bclamp() I am also wondering why bc-horz.win_h_sz_calc and bc-horz.win_v_sz_calc need to be ANDed anyway. I would expect that to happen when these values are set. But I did not look at this in-depth, so I may well have missed some subtlety here. Yes, isif_config_bclamp() set values in the register. It would be interesting to know if people know of good ways of making awkward code like this more elegant (or at least less awkward). Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Latest stack that can be merged on top of linux-next tree
Guennadi, I marged relevant files from the latest of your v4l tree after seeing your pull request. I worked fine for VGA capture. But I need to enable SOC_CAMERA to get the MT9T031 enabled which looks improper to me. Can we remove this restriction from KConfig? I plan to send a vpfe capture patch to support capture using this driver this week. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Friday, December 11, 2009 7:47 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org Subject: Re: Latest stack that can be merged on top of linux-next tree Hi Muralidharan On Thu, 10 Dec 2009, Karicheri, Muralidharan wrote: Guennadi, I am not sure if your MT9T031 changes are part of linux-next tree at v4l-dvb. If not, can you point me to the latest stack that I can apply on top of linux-next tree to get your latest changes for MT9T031 sensor driver? As you probably have seen, I posted a pull request a couple of hours ago, which also contains the change to mt9t031, that you're asking about. I plan to do integrate sensor driver with vpfe capture driver this week. BTW, Is there a driver for the PCA9543 i2c switch that is part of MT9T031 headboard? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Latest stack that can be merged on top of linux-next tree
Guennadi, I plan to send a vpfe capture patch to support capture using this driver this week. Good, looking forward to it. I will copy you on the request for reviewing the patch. It will be great if you can review the same. -Murali Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
Kevin,
That is what I had seen. I will check it again on Monday
and let you know.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, December 11, 2009 1:35 PM
To: Karicheri, Muralidharan
Cc: davinci-linux-open-sou...@linux.davincidsp.com; linux-
me...@vger.kernel.org
Subject: Re: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
Karicheri, Muralidharan m-kariche...@ti.com writes:
Kevin,
I think I have figured it out...
First issue was that I was adding my entry at the end of dm644x_clks[]
array. I need to add it before the CLK(NULL, NULL, NULL)
secondly, your suggestion didn't work as is. This is what I had to
do to get it working...
static struct clk ccdc_master_clk = {
.name = dm644x_ccdc,
.parent = vpss_master_clk,
};
static struct clk ccdc_slave_clk = {
.name = dm644x_ccdc,
.parent = vpss_slave_clk,
};
It doesn't work with out doing this. The cat /proc/davinci_clocks hangs
with
your suggestion implemented...
Can you track down the hang. It sounds like a bug in the walking of
the clock tree for davinci_clocks.
You should not need to add new clocks with new names. I don't thinke
the name field of the struct clk is used anywhere in the matching.
I think it's only used in /proc/davinci_clocks
static struct davinci_clk dm365_clks = {
CLK(dm644x_ccdc, master, ccdc_master_clk),
CLK(dm644x_ccdc, slave, ccdc_slave_clk),
Looks like the drivers name is 'dm644x_ccdc', not 'isif'. I'm
guessing just this should work without having to add new clock names.
No. I have mixed up the names. ISIF is for the new ISIF driver on DM365.
Below are for DM644x ccdc driver. With just these entries added, two
things observed
1) Only one clock is shown disabled (usually many are shown disabled)
during bootup
2) cat /proc/davinci_clocks hangs.
So this is the only way I got it working.
Hmm, it worked just fine for me without any of these side effects. I
applied the simple patch below on top of current master branch. It booted
fine showing all the unused clocks being disabled, and I was able to
see davinci_clocks just fine:
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-
davinci/dm644x.c
index e65e29e..e6f3570 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -293,8 +293,8 @@ struct davinci_clk dm644x_clks[] = {
CLK(NULL, dsp, dsp_clk),
CLK(NULL, arm, arm_clk),
CLK(NULL, vicp, vicp_clk),
- CLK(NULL, vpss_master, vpss_master_clk),
- CLK(NULL, vpss_slave, vpss_slave_clk),
+ CLK(dm644x_ccdc, master, vpss_master_clk),
+ CLK(dm644x_ccdc, slave, vpss_slave_clk),
CLK(NULL, arm, arm_clk),
CLK(NULL, uart0, uart0_clk),
CLK(NULL, uart1, uart1_clk),
[...]
Clocks: disable unused uart1
Clocks: disable unused uart2
Clocks: disable unused emac
Clocks: disable unused ide
Clocks: disable unused asp0
Clocks: disable unused mmcsd
Clocks: disable unused spi
Clocks: disable unused usb
Clocks: disable unused vlynq
Clocks: disable unused pwm0
Clocks: disable unused pwm1
Clocks: disable unused pwm2
Clocks: disable unused timer1
[...]
r...@dm644x:~# uname -r
2.6.32-arm-davinci-default-06873-g1a7277b-dirty
r...@dm644x:~# cat /debug/davinci_clocks
ref_clk users= 8 2700 Hz
pll1users= 8 pll 59400 Hz
pll1_sysclk1 users= 0 pll 59400 Hz
dsp users= 1 psc 59400 Hz
pll1_sysclk2 users= 2 pll 29700 Hz
arm users= 2 psc 29700 Hz
pll1_sysclk3 users= 0 pll 19800 Hz
vpss_master users= 0 psc 19800 Hz
vpss_slave users= 0 psc 19800 Hz
pll1_sysclk5 users= 3 pll 9900 Hz
emacusers= 1 psc 9900 Hz
ide users= 0 psc 9900 Hz
asp0users= 0 psc 9900 Hz
mmcsd users= 0 psc 9900 Hz
spi users= 0 psc 9900 Hz
gpiousers= 1 psc 9900 Hz
usb users= 0 psc 9900 Hz
vlynq users= 0 psc 9900 Hz
aemif users= 1 psc 9900 Hz
pll1_aux_clk users= 3 pll 2700 Hz
uart0 users= 1 psc 2700 Hz
uart1 users= 0 psc 2700 Hz
uart2 users= 0 psc 2700 Hz
i2c users= 1 psc 2700 Hz
pwm0users= 0 psc 2700 Hz
pwm1users= 0 psc 2700 Hz
pwm2users= 0 psc 2700 Hz
timer0 users= 1 psc 2700 Hz
timer1 users= 0 psc 2700 Hz
timer2 users= 1 psc 2700 Hz
pll1_sysclkbp users= 0 pll 2700 Hz
pll2users= 0 pll 64800 Hz
pll2_sysclk1 users= 0 pll 5400 Hz
pll2_sysclk2 users= 0 pll 32400 Hz
pll2_sysclkbp users= 0 pll 1350 Hz
r...@dm644x
Latest stack that can be merged on top of linux-next tree
Guennadi, I am not sure if your MT9T031 changes are part of linux-next tree at v4l-dvb. If not, can you point me to the latest stack that I can apply on top of linux-next tree to get your latest changes for MT9T031 sensor driver? I plan to do integrate sensor driver with vpfe capture driver this week. BTW, Is there a driver for the PCA9543 i2c switch that is part of MT9T031 headboard? Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
I thought following is correct:- Probe() clk_get() followed by clk_enable() Remove() clk_disable() followed by clk_put() Suspend() clk_disable() Resume() clk_enable() Yes, that is correct. I didn't look at the whole driver. My concern was that if the driver was enhanced to more aggressive clock management, you shouldn't do a clk_get() every time you do a clk_enable(), same for put. Got you. I am in sync with your thinking. -Murali Kevin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
Kevin,
I think I have figured it out...
First issue was that I was adding my entry at the end of dm644x_clks[]
array. I need to add it before the CLK(NULL, NULL, NULL)
secondly, your suggestion didn't work as is. This is what I had to
do to get it working...
static struct clk ccdc_master_clk = {
.name = dm644x_ccdc,
.parent = vpss_master_clk,
};
static struct clk ccdc_slave_clk = {
.name = dm644x_ccdc,
.parent = vpss_slave_clk,
};
It doesn't work with out doing this. The cat /proc/davinci_clocks hangs with
your suggestion implemented...
You should not need to add new clocks with new names. I don't thinke
the name field of the struct clk is used anywhere in the matching.
I think it's only used in /proc/davinci_clocks
static struct davinci_clk dm365_clks = {
CLK(dm644x_ccdc, master, ccdc_master_clk),
CLK(dm644x_ccdc, slave, ccdc_slave_clk),
Looks like the drivers name is 'dm644x_ccdc', not 'isif'. I'm
guessing just this should work without having to add new clock names.
No. I have mixed up the names. ISIF is for the new ISIF driver on DM365.
Below are for DM644x ccdc driver. With just these entries added, two
things observed
1) Only one clock is shown disabled (usually many are shown disabled) during
bootup
2) cat /proc/davinci_clocks hangs.
So this is the only way I got it working.
CLK(dm644x_ccdc, master, vpss_master_clk),
CLK(dm644x_ccdc, slave, vpss_slave_clk),
CLK(NULL, NULL, NULL);
Let me know if you think there is anything wrong with the above scheme.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Latest stack that can be merged on top of linux-next tree
Hi, Thanks for the email. Any idea how i2c drivers can work with this? Currently in my board, I have adapter id = 1 for main i2c bus. So when this mux driver is built into the kernel, I guess I can access it using a different adapter id, right? If so, what is the adapter id? How do I use this with MT9T031 driver? Any idea to share? Thanks Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Daniel Glöckner [mailto:d...@emlix.com] Sent: Thursday, December 10, 2009 3:15 PM To: HoP Cc: Karicheri, Muralidharan; linux-media@vger.kernel.org Subject: Re: Latest stack that can be merged on top of linux-next tree Hi, On 12/10/2009 08:39 PM, HoP wrote: 2009/12/10 Karicheri, Muralidharan m-kariche...@ti.com: BTW, Is there a driver for the PCA9543 i2c switch that is part of MT9T031 headboard? I would like to know answer also :) I had to add support for pca9542 (what is 2 port switch) for our project. After some googling I found some patches for similar kernel I was working on (2.6.22). You can find original patches for example there: http://www.mail-archive.com/i...@lm-sensors.org/msg00315.html FYI, the driver pca954x.c seems to be driver for full family of i2c muxes/switches. Such code works fine for me. The only thing I didn't find was why the code was never merged. the driver that has the greatest chance of being accepted has been discussed on the linux-i2c list a few days ago: http://thread.gmane.org/gmane.linux.drivers.i2c/4856 The patchset they are talking about is this one: http://thread.gmane.org/gmane.linux.drivers.i2c/2998 With these patches the bus segments beyond the i2c multiplexer will be registered as separate i2c busses. Access to a device on those busses will then automatically reconfigure the multiplexer. Last time we tried to enable only one channel of the pca9543 on the mt9d131 board it had an effect on the brightness. Unfortunately we don't have the schematics of the head board. Can anyone explain what was going on there? Daniel -- Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführer: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055 emlix - your embedded linux partner -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v1] V4L-Fix videobuf_dma_contig_user_get() for non-aligned offsets
Magnus, Thanks for testing and approving the patch. Mauro, Could you merge this bug fix? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Magnus Damm [mailto:magnus.d...@gmail.com] Sent: Wednesday, December 09, 2009 8:00 AM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org Subject: Re: [PATCH - v1] V4L-Fix videobuf_dma_contig_user_get() for non- aligned offsets On Wed, Dec 9, 2009 at 6:36 AM, m-kariche...@ti.com wrote: From: Muralidharan Karicheri m-kariche...@ti.com If a USERPTR address that is not aligned to page boundary is passed to the videobuf_dma_contig_user_get() function, it saves a page aligned address to the dma_handle. This is not correct. This issue is observed when using USERPTR IO machism for buffer exchange. Updates from last version:- Adding offset for size calculation as per comment from Magnus Damm. This ensures the last page is also included for checking if memory is contiguous. Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com Hi Murali, I've spent some time testing this patch with the SuperH CEU driver in USERPTR mode. My test case is based on capture.c with places a bunch of QVGA frames directly after each other. The size of each QVGA frame is not an even multiple of 4k page size, so some of the frames will use a non-aligned start addresses. Currently the CEU driver page aligns the size of each frame, but I'll fix that in an upcoming patch. Thank you! Acked-by: Magnus Damm d...@opensource.se -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
Kevin,
After sending out my last patch (moving clocks to ccdc driver), I thought of
reworking it in similar lines. I will re-send the patch after incorporating
this.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, December 09, 2009 11:00 AM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open-
sou...@linux.davincidsp.com; Hiremath, Vaibhav
Subject: Re: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
m-kariche...@ti.com writes:
From: Muralidharan Karicheri m-kariche...@ti.com
v1 - updated based on comments from Vaibhav Hiremath.
On DM365 we use only vpss master clock, where as on DM355 and
DM6446, we use vpss master and slave clocks for vpfe capture and AM3517
we use internal clock and pixel clock. So this patch makes it
configurable
on a per platform basis. This is needed for supporting DM365 for which
patches
will be available soon.
Tested-by: Vaibhav Hiremath hvaib...@ti.com, Muralidharan Karicheri m-
kariche...@ti.com
Acked-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
Sorry for jumping late into this thread, but I have a couple comments.
First, we should *never* pass clock names from platform code to driver
code. We have the clkdevs for this. Using clkdev, the right clock
is determined from the driver being used and any additional info.
Rather than passing the strings along, you should add the driver name
to the 'dev_id' field of the clkdev node, and then use the 'con_id' field
to distinguish between the two clocks:
- CLK(NULL, vpss_master, vpss_master_clk),
- CLK(NULL, vpss_slave, vpss_slave_clk),
+ CLK(vpfe-capture, master, vpss_master_clk),
+ CLK(vpfe-capture, slave, vpss_slave_clk),
NOTE: this assumes clks are used from VPFE. When you move to CCDC, this
should change accordingly.
More on the usage below...
---
drivers/media/video/davinci/vpfe_capture.c | 98 +-
-
include/media/davinci/vpfe_capture.h | 11 ++-
2 files changed, 70 insertions(+), 39 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 12a1b3d..c3468ee 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1787,61 +1787,87 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
+/**
+ * vpfe_disable_clock() - Disable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Disables clocks defined in vpfe configuration.
+ */
static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
{
struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
+int i;
-clk_disable(vpfe_cfg-vpssclk);
-clk_put(vpfe_cfg-vpssclk);
-clk_disable(vpfe_cfg-slaveclk);
-clk_put(vpfe_cfg-slaveclk);
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
+for (i = 0; i vpfe_cfg-num_clocks; i++) {
+clk_disable(vpfe_dev-clks[i]);
+clk_put(vpfe_dev-clks[i]);
While cleaning this up, you should move the clk_put() to module
disable/unload time. You dont' need to put he clock on every disable.
The same for clk_get(). You don't need to get the clock for every
enable. Just do a clk_get() at init time.
+}
+kfree(vpfe_dev-clks);
+v4l2_info(vpfe_dev-pdev-driver, vpfe capture clocks disabled\n);
}
+/**
+ * vpfe_enable_clock() - Enable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Enables clocks defined in vpfe configuration. The function
+ * assumes that at least one clock is to be defined which is
+ * true as of now. re-visit this if this assumption is not true
+ */
static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
{
struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-int ret = -ENOENT;
+int i;
-vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
Using my clkdevs from above, you just need to change this to:
vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, master);
Now that the device name is in the clkdev node, clk_get() will
find the right clock based on the device name.
-if (NULL == vpfe_cfg-vpssclk) {
-v4l2_err(vpfe_dev-pdev-driver, No clock defined for
- vpss_master\n);
-return ret;
-}
+if (!vpfe_cfg-num_clocks)
+return 0;
-if (clk_enable(vpfe_cfg-vpssclk)) {
-v4l2_err(vpfe_dev-pdev-driver,
-vpfe vpss master clock not enabled\n);
-goto out;
-}
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master clock enabled\n);
+vpfe_dev-clks = kzalloc(vpfe_cfg-num_clocks
RE: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
Kevin,
+/**
+ * vpfe_disable_clock() - Disable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Disables clocks defined in vpfe configuration.
+ */
static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
{
struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
+int i;
-clk_disable(vpfe_cfg-vpssclk);
-clk_put(vpfe_cfg-vpssclk);
-clk_disable(vpfe_cfg-slaveclk);
-clk_put(vpfe_cfg-slaveclk);
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
+for (i = 0; i vpfe_cfg-num_clocks; i++) {
+clk_disable(vpfe_dev-clks[i]);
+clk_put(vpfe_dev-clks[i]);
While cleaning this up, you should move the clk_put() to module
disable/unload time.
[MK] vpfe_disable_clock() is called from remove(). In the new
patch, from ccdc driver remove() function, clk_put() will be called.
Why do you think it should be moved to exit() function of the module?
You dont' need to put he clock on every disable.
The same for clk_get(). You don't need to get the clock for every
enable. Just do a clk_get() at init time.
Are you suggesting to call clk_get() during init() and call clk_put()
from exit()? What is wrong with calling clk_get() from probe()?
I thought following is correct:-
Probe()
clk_get() followed by clk_enable()
Remove()
clk_disable() followed by clk_put()
Suspend()
clk_disable()
Resume()
clk_enable()
Please confirm.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
Kevin,
I tried the following and I get error in clk_enable(). Do you know what might
be wrong?
in DM365.c
CLK(isif, master, vpss_master_clk)
The driver name is isif. I call clk_get(pdev-dev, master) from isif driver.
The platform device name is isif. This call succeeds, but clk_enable()
fails...
clk_ptr = clk_get(pdev-dev, master);
clk_enable(clk_ptr);
r...@dm355-evm:~# cat /proc/davinci_clocks
ref_clk users= 7 2400 Hz
pll1users= 6 pll 48600 Hz
pll1_aux_clk users= 3 pll 2400 Hz
uart0 users= 1 psc 2400 Hz
i2c users= 1 psc 2400 Hz
spi4users= 0 psc 2400 Hz
pwm0users= 0 psc 2400 Hz
pwm1users= 0 psc 2400 Hz
pwm2users= 0 psc 2400 Hz
timer0 users= 1 psc 2400 Hz
timer1 users= 0 psc 2400 Hz
timer2 users= 1 psc 2400 Hz
timer3 users= 0 psc 2400 Hz
usb users= 0 psc 2400 Hz
pll1_sysclkbp users= 0 pll 2400 Hz
clkout0 users= 0 pll 2400 Hz
pll1_sysclk1 users= 0 pll 48600 Hz
pll1_sysclk2 users= 0 pll 24300 Hz
pll1_sysclk3 users= 0 pll 24300 Hz
vpss_dacusers= 0 psc 24300 Hz
mjcpusers= 0 psc 24300 Hz
pll1_sysclk4 users= 3 pll 12150 Hz
uart1 users= 0 psc 12150 Hz
mmcsd1 users= 0 psc 12150 Hz
spi0users= 0 psc 12150 Hz
spi1users= 0 psc 12150 Hz
spi2users= 0 psc 12150 Hz
spi3users= 0 psc 12150 Hz
gpiousers= 1 psc 12150 Hz
aemif users= 1 psc 12150 Hz
emacusers= 1 psc 12150 Hz
asp0users= 0 psc 12150 Hz
rto users= 0 psc 12150 Hz
pll1_sysclk5 users= 0 pll 24300 Hz
vpss_master users= 0 psc 24300 Hz
pll1_sysclk6 users= 0 pll 2700 Hz
pll1_sysclk7 users= 0 pll 48600 Hz
pll1_sysclk8 users= 0 pll 12150 Hz
mmcsd0 users= 0 psc 12150 Hz
pll1_sysclk9 users= 0 pll 24300 Hz
pll2users= 1 pll 59400 Hz
pll2_aux_clk users= 0 pll 2400 Hz
clkout1 users= 0 pll 2400 Hz
pll2_sysclk1 users= 0 pll 59400 Hz
pll2_sysclk2 users= 1 pll 29700 Hz
arm_clk users= 1 psc 29700 Hz
pll2_sysclk3 users= 0 pll 59400 Hz
pll2_sysclk4 users= 0 pll 20482758 Hz
voice_codec users= 0 psc 20482758 Hz
pll2_sysclk5 users= 0 pll 7425 Hz
pll2_sysclk6 users= 0 pll 59400 Hz
pll2_sysclk7 users= 0 pll 59400 Hz
pll2_sysclk8 users= 0 pll 59400 Hz
pll2_sysclk9 users= 0 pll 59400 Hz
pwm3users= 0 psc 2400 Hz
r...@dm355-evm:~#
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
Of Karicheri, Muralidharan
Sent: Wednesday, December 09, 2009 12:45 PM
To: Kevin Hilman
Cc: davinci-linux-open-sou...@linux.davincidsp.com; linux-
me...@vger.kernel.org
Subject: RE: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
Kevin,
+/**
+ * vpfe_disable_clock() - Disable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Disables clocks defined in vpfe configuration.
+ */
static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
{
struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
+ int i;
- clk_disable(vpfe_cfg-vpssclk);
- clk_put(vpfe_cfg-vpssclk);
- clk_disable(vpfe_cfg-slaveclk);
- clk_put(vpfe_cfg-slaveclk);
- v4l2_info(vpfe_dev-pdev-driver,
-vpfe vpss master slave clocks disabled\n);
+ for (i = 0; i vpfe_cfg-num_clocks; i++) {
+ clk_disable(vpfe_dev-clks[i]);
+ clk_put(vpfe_dev-clks[i]);
While cleaning this up, you should move the clk_put() to module
disable/unload time.
[MK] vpfe_disable_clock() is called from remove(). In the new
patch, from ccdc driver remove() function, clk_put() will be called.
Why do you think it should be moved to exit() function of the module?
You dont' need to put he clock on every disable.
The same for clk_get(). You don't need to get the clock for every
enable. Just do a clk_get() at init time.
Are you suggesting to call clk_get() during init() and call clk_put()
from exit()? What is wrong with calling clk_get() from probe()?
I thought following is correct:-
Probe()
clk_get() followed by clk_enable()
Remove()
clk_disable() followed by clk_put()
Suspend()
clk_disable()
Resume()
clk_enable()
Please confirm.
___
Davinci-linux-open-source mailing list
davinci-linux-open-sou...@linux.davincidsp.com
http
RE: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
Kevin,
I think I have figured it out...
First issue was that I was adding my entry at the end of dm644x_clks[]
array. I need to add it before the CLK(NULL, NULL, NULL)
secondly, your suggestion didn't work as is. This is what I had to
do to get it working...
static struct clk ccdc_master_clk = {
.name = dm644x_ccdc,
.parent = vpss_master_clk,
};
static struct clk ccdc_slave_clk = {
.name = dm644x_ccdc,
.parent = vpss_slave_clk,
};
static struct davinci_clk dm365_clks = {
CLK(dm644x_ccdc, master, ccdc_master_clk),
CLK(dm644x_ccdc, slave, ccdc_slave_clk),
CLK(NULL, NULL, NULL);
Let me know if you think there is anything wrong with the above scheme.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, December 09, 2009 1:22 PM
To: Karicheri, Muralidharan; Kevin Hilman
Cc: davinci-linux-open-sou...@linux.davincidsp.com; linux-
me...@vger.kernel.org
Subject: RE: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
Kevin,
I tried the following and I get error in clk_enable(). Do you know what
might be wrong?
in DM365.c
CLK(isif, master, vpss_master_clk)
The driver name is isif. I call clk_get(pdev-dev, master) from isif
driver. The platform device name is isif. This call succeeds, but
clk_enable() fails...
clk_ptr = clk_get(pdev-dev, master);
clk_enable(clk_ptr);
r...@dm355-evm:~# cat /proc/davinci_clocks
ref_clk users= 7 2400 Hz
pll1users= 6 pll 48600 Hz
pll1_aux_clk users= 3 pll 2400 Hz
uart0 users= 1 psc 2400 Hz
i2c users= 1 psc 2400 Hz
spi4users= 0 psc 2400 Hz
pwm0users= 0 psc 2400 Hz
pwm1users= 0 psc 2400 Hz
pwm2users= 0 psc 2400 Hz
timer0 users= 1 psc 2400 Hz
timer1 users= 0 psc 2400 Hz
timer2 users= 1 psc 2400 Hz
timer3 users= 0 psc 2400 Hz
usb users= 0 psc 2400 Hz
pll1_sysclkbp users= 0 pll 2400 Hz
clkout0 users= 0 pll 2400 Hz
pll1_sysclk1 users= 0 pll 48600 Hz
pll1_sysclk2 users= 0 pll 24300 Hz
pll1_sysclk3 users= 0 pll 24300 Hz
vpss_dacusers= 0 psc 24300 Hz
mjcpusers= 0 psc 24300 Hz
pll1_sysclk4 users= 3 pll 12150 Hz
uart1 users= 0 psc 12150 Hz
mmcsd1 users= 0 psc 12150 Hz
spi0users= 0 psc 12150 Hz
spi1users= 0 psc 12150 Hz
spi2users= 0 psc 12150 Hz
spi3users= 0 psc 12150 Hz
gpiousers= 1 psc 12150 Hz
aemif users= 1 psc 12150 Hz
emacusers= 1 psc 12150 Hz
asp0users= 0 psc 12150 Hz
rto users= 0 psc 12150 Hz
pll1_sysclk5 users= 0 pll 24300 Hz
vpss_master users= 0 psc 24300 Hz
pll1_sysclk6 users= 0 pll 2700 Hz
pll1_sysclk7 users= 0 pll 48600 Hz
pll1_sysclk8 users= 0 pll 12150 Hz
mmcsd0 users= 0 psc 12150 Hz
pll1_sysclk9 users= 0 pll 24300 Hz
pll2users= 1 pll 59400 Hz
pll2_aux_clk users= 0 pll 2400 Hz
clkout1 users= 0 pll 2400 Hz
pll2_sysclk1 users= 0 pll 59400 Hz
pll2_sysclk2 users= 1 pll 29700 Hz
arm_clk users= 1 psc 29700 Hz
pll2_sysclk3 users= 0 pll 59400 Hz
pll2_sysclk4 users= 0 pll 20482758 Hz
voice_codec users= 0 psc 20482758 Hz
pll2_sysclk5 users= 0 pll 7425 Hz
pll2_sysclk6 users= 0 pll 59400 Hz
pll2_sysclk7 users= 0 pll 59400 Hz
pll2_sysclk8 users= 0 pll 59400 Hz
pll2_sysclk9 users= 0 pll 59400 Hz
pwm3users= 0 psc 2400 Hz
r...@dm355-evm:~#
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
Of Karicheri, Muralidharan
Sent: Wednesday, December 09, 2009 12:45 PM
To: Kevin Hilman
Cc: davinci-linux-open-sou...@linux.davincidsp.com; linux-
me...@vger.kernel.org
Subject: RE: [PATCH - v1 1/2] V4L - vpfe capture - make clocks
configurable
Kevin,
+/**
+ * vpfe_disable_clock() - Disable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Disables clocks defined in vpfe configuration.
+ */
static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
{
struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
+ int i;
- clk_disable(vpfe_cfg-vpssclk);
- clk_put(vpfe_cfg-vpssclk);
- clk_disable(vpfe_cfg-slaveclk);
- clk_put(vpfe_cfg-slaveclk);
- v4l2_info
RE: [PATCH - v0 2/2] DaVinci - vpfe capture - Make clocks configurable
Vaibhav,
I have posted a re-worked patch with clocks configuration moved
to ccdc. From your response below, I understand the clocks
are being called differently on different SoCs even though they
use the same IP. So IMO, it is better to customize it on a SoC
by defining the clock names in the respective platform file as
done by my original patch. This will avoid confusion since we need to
keep the name in sync with hardware signal names.
-Murali
[Hiremath, Vaibhav] Murali,
They might be using different naming conventions but the number of clocks
will always remain the same. If not, then they are not same IP and most
probably will not use same driver.
Just to clarify more on your Q, AM3517 also uses 2 clocks
- vpfe_ck (functional clock)
- vpfe_pck (external clock, pixel clock)
Whereas you are referring them as master and slave clock.
Thanks,
Vaibhav
Murali
Thanks,
Vaibhav
};
static struct platform_device *davinci_evm_devices[] __initdata
= {
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index fd0398b..45beb99 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -250,6 +250,8 @@ static struct vpfe_config vpfe_cfg = {
.sub_devs = vpfe_sub_devs,
.card_name = DM6446 EVM,
.ccdc = DM6446 CCDC,
+ .num_clocks = 2,
+ .clocks = {vpss_master, vpss_slave},
};
static struct platform_device rtc_dev = {
--
1.6.0.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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/5 - v0] V4L-vpfe capture - adding CCDC driver for DM365
Sekhar,
Hi Murali,
Here is a (styling related) review from an non-video person. The
[MK] The styling was mostly done by one of our intern who is new to open source
coding. So I will fix it based on your comments.
review is neither complete nor exhaustive (the patch is huge!),
but I thought will send across whatever I have for you to take a look.
[MK] Yes Sure!
On Wed, Dec 02, 2009 at 03:08:49, Karicheri, Muralidharan wrote:
From: Muralidharan Karicheri m-kariche...@ti.com
This patch is for adding support for DM365 CCDC. This will allow to
capture YUV video frames from TVP5146 video decoder on DM365 EVM. The
vpfe
capture driver will use this module to configure ISIF (a.k.a CCDC)
module to allow YUV data capture. This driver is written for
ccdc_hw_device
interface used by vpfe capture driver to configure the ccdc module.
This patch is tested using NTSC PAL video sources and verified for
both formats.
NOTE: This is the initial version for review.
Typically RFC is put instead of PATCH in subject line
to convey this.
[MK] IMO, RFC is for something that is a proposal to make some changes in the
architecture/implementation to get feedback from the reviewers. But here it is
a real code that is being reviewed. I just mentioned it to make sure no body
complains that it doesn't apply to the latest tree :). This is based on
what I see in the mailing list.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/dm365_ccdc.c | 1529
+
drivers/media/video/davinci/dm365_ccdc_regs.h | 293 +
include/media/davinci/dm365_ccdc.h| 555 +
3 files changed, 2377 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/dm365_ccdc.c
create mode 100644 drivers/media/video/davinci/dm365_ccdc_regs.h
create mode 100644 include/media/davinci/dm365_ccdc.h
diff --git a/drivers/media/video/davinci/dm365_ccdc.c
b/drivers/media/video/davinci/dm365_ccdc.c
Hopefully it is possible to choose a generic name
instead of tying it to an SoC.
[MK]I agree there is problem here. For example, we have same ccdc IP used
across DM6446, OMAP34xx and Sitara (earlier Shiva). We have it named
currently as dm644x_ccdc.c. I have checked the DM6446 and OMAP34xx PRG
and finds that CCDC IP has a Peripheral identification (TID) and class
identification (CID). For OMAP DM6446, they have the same values. So
We might be able to rename them as ccdc_TIDCID.c. But for CCDC on
DM355, we don't have a PID/CID for ccdc. So how do we name it? I don't
see a uniform way we can name the driver for these IPs.
Probably change dm365_ccdc.c to isif.c since that is the IP name on
DM365. ISIF stands for Image Sensor Interface.
new file mode 100644
index 000..2f27696
--- /dev/null
+++ b/drivers/media/video/davinci/dm365_ccdc.c
@@ -0,0 +1,1529 @@
[...]
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/uaccess.h
+#include linux/io.h
+#include linux/videodev2.h
+#include mach/mux.h
+#include media/davinci/dm365_ccdc.h
+#include media/davinci/vpss.h
+#include dm365_ccdc_regs.h
+#include ccdc_hw_device.h
Typically the includes are grouped using empty lines
based on the folder linux, media mach etc.
[MK]This is not strictly followed in the community, But I think it is good
to do this for better readability.
+
+static struct device *dev;
+
+/* Defauts for module configuation paramaters */
+static struct ccdc_config_params_raw ccdc_config_defaults = {
+.linearize = {
+.en = 0,
+.corr_shft = CCDC_NO_SHIFT,
+.scale_fact = {1, 0},
+},
+.df_csc = {
+.df_or_csc = 0,
+.csc = {
+.en = 0
Should use ',' at the end of line so adding
new members leads to adding just one line.
There are more of these in this static init
below.
[MK] Ok.
+},
+},
+.dfc = {
+.en = 0
+},
+.bclamp = {
+.en = 0
+},
+.gain_offset = {
+.gain = {
+.r_ye = {1, 0},
+.gr_cy = {1, 0},
+.gb_g = {1, 0},
+.b_mg = {1, 0},
+},
+},
+.culling = {
+.hcpat_odd = 0xff,
+.hcpat_even = 0xff,
+.vcpat = 0xff
+},
+.compress = {
+.alg = CCDC_ALAW,
+},
+};
+
+/* ISIF operation configuration */
+struct ccdc_oper_config {
+enum vpfe_hw_if_type if_type;
+struct ccdc_ycbcr_config ycbcr;
+struct ccdc_params_raw bayer;
+enum ccdc_data_pack data_pack;
+void *__iomem base_addr;
+void *__iomem linear_tbl0_addr;
+void *__iomem linear_tbl1_addr;
Usually it is void __iomem *foo;
[MK] Correct.
+};
+
+static struct ccdc_oper_config ccdc_cfg = {
+.ycbcr = {
+.pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+.frm_fmt = CCDC_FRMFMT_INTERLACED
RE: [PATCH] V4L - Fix videobuf_dma_contig_user_get() getting page aligned physical address
Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Magnus Damm [mailto:magnus.d...@gmail.com] Sent: Friday, December 04, 2009 6:06 AM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; mche...@infradead.org; davinci-linux-open- sou...@linux.davincidsp.com Subject: Re: [PATCH] V4L - Fix videobuf_dma_contig_user_get() getting page aligned physical address Hi again Murali, Thanks for your work on this. On Thu, Dec 3, 2009 at 12:48 AM, Karicheri, Muralidharan m-kariche...@ti.com wrote: Magnus, Thanks for the patch. For non-page aligned user space pointers I agree that a fix is needed. Don't you think the while loop in videobuf_dma_contig_user_get() also needs to be adjusted to include the last page? I think the while loop checks one page too little in the non-aligned case today. Thanks for reviewing my patch. It had worked for non-aligned address in my testing. If I understand this code correctly, the physical address of the user page start is determined in the first loop (pages_done == 0) and additional loops are run to make sure the memory is physically contiguous. Initially the mem-size is set to number of pages aligned to page size. Assume we pass 4097 bytes as size. mem-size = PAGE_ALIGN(vb-size); = 2 Inside the loop, iteration is done for 0 to pages-1. pages_done (mem-size 12) = pages_done 2 = iterate 2 times For size of 4096, we iterate once. For size of 4095, we iterate once. So IMO the loop is already iterate one more time when we pass non-aligned address since size is aligned to include the last page. So based on this could you ack my patch so that we could ask Mauro to merge it with priority? I think your observations are correct, but I also think there is one more hidden issue. In the case where the offset within the page is other than 0 then we should loop once more to also check the final page. Right now no one is checking if the last page is contiguous or not in the case on non-page-aligned offset.. So in your case with a 4096 or 4095 size, but if the offset withing the page is non-zero then we should loop twice to make sure the pages really are physically contiguous. Today we only loop once based on the size. We should also include the offset in the calculation of number of pages to check. Yes. You are right. For offsets that are non-aligned we need to check for the last one. Probably unsigned int offset = vb-baddr ~PAGE_MASK; mem-size = PAGE_ALIGN(vb-size + offset); .. if (pages_done == 0) mem-handle = (this_pfn PAGE_SHIFT) + offset; If this is fine, I can send you a updated patch. If you can fix it that is fine too. regards, Murali If you can include that fix in your patch that would be great. If not then i'll fix it up myself. If you could do this it will be great! Thanks! / magnus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v0 1/2] V4L - vpfe capture - convert ccdc drivers to platform drivers
Sekhar, + status = -EBUSY; [Hiremath, Vaibhav] Is -EBUSY right return value, I think it should be - ENXIO or -ENOMEM. I see -ENXIO -ENOMEM being used by drivers. -ENXIO stands for No such device or address. ENOMEM stands for Out of memory . Since we are trying to map the address here, -ENXIO looks reasonable to me. Same if request_mem_region() fails. Sergei had posted on this earlier[1]. Quoting him here: Was this his personal opinion or has he given any reference to support it? I did a grep for this in the driver directory and the result I got is in inline with Sergie's suggestion. So I am going to update the patch with these and send it again. -Murali What are the proper error codes when platform_get_resource, -ENODEV. request_mem_region -EBUSY. and ioremap functions fail?. -ENOMEM. Not sure if ioremap failure can relate to absence of a device. Thanks, Sekhar [1] http://www.mail-archive.com/davinci-linux-open- sou...@linux.davincidsp.com/msg14973.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v0 2/2] DaVinci - vpfe capture - Make clocks configurable
Vaibhav,
Could you confirm my question below? I need to submit a patch on Monday.
Currently we have vpfe_capture.c file (master/bridge driver) which is
handling clk_get/put, and platform data is providing the details about it.
Ideally we should handle it in respective ccdc driver file, since he has
all the knowledge about required number of clocks and its name. This way
we
don't have to maintain/pass clock information in platform data.
I would appreciate any comments/thoughts/pointers here.
Though I agree that this clock could be set by the ccdc driver, I am not
sure if the same clock is used by an IP on different SOCs. For example take
the case of ccdc on DM6446 which is also used on OMAP 35xx SOC. Do they use
vpss master and slave clocks as is done on DM6446? If this is true, then we
could set the clock inside ccdc driver.
Let me know so that I can re-work the patch and send it to the list.
Murali
Thanks,
Vaibhav
};
static struct platform_device *davinci_evm_devices[] __initdata = {
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index fd0398b..45beb99 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -250,6 +250,8 @@ static struct vpfe_config vpfe_cfg = {
.sub_devs = vpfe_sub_devs,
.card_name = DM6446 EVM,
.ccdc = DM6446 CCDC,
+ .num_clocks = 2,
+ .clocks = {vpss_master, vpss_slave},
};
static struct platform_device rtc_dev = {
--
1.6.0.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
RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings
Hans, Thanks for sending this pull request. No problem in my name being mentioned in the spec. Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Wednesday, December 02, 2009 11:40 PM To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab; Karicheri, Muralidharan Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings for the following: - v4l: Adding Digital Video Timings APIs - v4l2-spec: Digital Video Timings API documentation - v4l2-spec: updated revision history, updated version to 2.6.33. Murali, I've added you as one of the authors of the v4l2-spec (you did this timings API after all) and included your email as well. If that is a problem for you (either being mentioned at all, or that your email is mentioned), then let me know asap and I'll remove it. I don't expect it to be a problem since all this information is already public. Mauro, before adding these documentation patches it is probably a good idea to build and release a final 2.6.32 version of the documentation on http://www.linuxtv.org/docs.php. If you want to see an example of this api being used, then take a look at the tvp7002 driver patches that have been posted recently. I expect that driver to be merged soon after this pull request is merged. Thanks, Hans diffstat: b/linux/Documentation/DocBook/v4l/vidioc-enum-dv-presets.xml | 238 +++ b/linux/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml | 111 + b/linux/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml| 224 ++ b/linux/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml | 85 +++ linux/Documentation/DocBook/media-entities.tmpl | 18 linux/Documentation/DocBook/media-indices.tmpl |4 linux/Documentation/DocBook/v4l/common.xml | 35 + linux/Documentation/DocBook/v4l/compat.xml | 16 linux/Documentation/DocBook/v4l/v4l2.xml | 26 + linux/Documentation/DocBook/v4l/videodev2.h.xml | 116 + linux/Documentation/DocBook/v4l/vidioc-enuminput.xml | 36 + linux/Documentation/DocBook/v4l/vidioc-enumoutput.xml| 36 + linux/drivers/media/video/v4l2-compat-ioctl32.c |6 linux/drivers/media/video/v4l2-ioctl.c | 147 ++ linux/include/linux/videodev2.h | 116 + linux/include/media/v4l2-ioctl.h | 15 linux/include/media/v4l2-subdev.h| 21 media-specs/Makefile | 14 18 files changed, 1252 insertions(+), 12 deletions(-)
RE: [PATCH - v0 2/2] DaVinci - vpfe capture - Make clocks configurable
I was talking to Sekhar about this and actually he made some good points
about this implementation.
If we consider specific IP, then the required clocks would remain always be
the same. There might be some devices which may not be using some clocks
(so as that specific feature).
Actually we are trying to create one more wrapper for clock configuration.
Just to illustrate I am putting some other generic drivers examples -
Omap-hsmmc.c -
This driver requires 2 clocks, interface and functional. The devices which
would be using this driver have to define clock with names ick and fck.
VPFE-Capture (Considering only current implementation) -
Currently we have vpfe_capture.c file (master/bridge driver) which is
handling clk_get/put, and platform data is providing the details about it.
Ideally we should handle it in respective ccdc driver file, since he has
all the knowledge about required number of clocks and its name. This way we
don't have to maintain/pass clock information in platform data.
I would appreciate any comments/thoughts/pointers here.
Though I agree that this clock could be set by the ccdc driver, I am not sure
if the same clock is used by an IP on different SOCs. For example take
the case of ccdc on DM6446 which is also used on OMAP 35xx SOC. Do they use
vpss master and slave clocks as is done on DM6446? If this is true, then we
could set the clock inside ccdc driver.
Let me know so that I can re-work the patch and send it to the list.
Murali
Thanks,
Vaibhav
};
static struct platform_device *davinci_evm_devices[] __initdata = {
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index fd0398b..45beb99 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -250,6 +250,8 @@ static struct vpfe_config vpfe_cfg = {
.sub_devs = vpfe_sub_devs,
.card_name = DM6446 EVM,
.ccdc = DM6446 CCDC,
+.num_clocks = 2,
+.clocks = {vpss_master, vpss_slave},
};
static struct platform_device rtc_dev = {
--
1.6.0.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
RE: [PATCH 2/2] DaVinci - vpfe capture - converting ccdc to platform driver
-/*
- * setup Mux configuration for vpfe input and register
- * vpfe capture platform device
- */
-davinci_cfg_reg(DM355_VIN_PCLK);
-davinci_cfg_reg(DM355_VIN_CAM_WEN);
-davinci_cfg_reg(DM355_VIN_CAM_VD);
-davinci_cfg_reg(DM355_VIN_CAM_HD);
-davinci_cfg_reg(DM355_VIN_YIN_EN);
-davinci_cfg_reg(DM355_VIN_CINL_EN);
-davinci_cfg_reg(DM355_VIN_CINH_EN);
[Hiremath, Vaibhav] Why have you removed mux configuration from here and
moved to CCDC driver? Any specific reason?
Good catch. I wanted to do this clean up, but missed it. Actually platform data
should have a function setup_pinmux() to set up the pin mux for the
ccdc input. This function will be defined in the platform file and will be
called during probe()
Murali
+platform_device_register(dm355_ccdc_dev);
platform_device_register(vpfe_capture_dev);
return 0;
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-
davinci/dm644x.c
index 2cd0081..982be1f 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -612,6 +612,11 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm644x_ccdc_resource[] = {
+/* CCDC Base address */
{
.start = 0x01c70400,
.end= 0x01c70400 + 0xff,
@@ -619,7 +624,17 @@ static struct resource vpfe_resources[] = {
},
};
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct platform_device dm644x_ccdc_dev = {
+.name = dm644x_ccdc,
+.id = -1,
+.num_resources = ARRAY_SIZE(dm644x_ccdc_resource),
+.resource = dm644x_ccdc_resource,
+.dev = {
+.dma_mask = vpfe_capture_dma_mask,
+.coherent_dma_mask = DMA_BIT_MASK(32),
+},
+};
+
static struct platform_device vpfe_capture_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
@@ -772,6 +787,7 @@ static int __init dm644x_init_devices(void)
platform_device_register(dm644x_edma_device);
platform_device_register(dm644x_emac_device);
platform_device_register(dm644x_vpss_device);
+platform_device_register(dm644x_ccdc_dev);
platform_device_register(vpfe_capture_dev);
return 0;
--
1.6.0.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
RE: [PATCH v0 1/2] V4L - vpfe capture - convert ccdc drivers to platform drivers
+#include mach/mux.h
[Hiremath, Vaibhav] This should not be here, this should get handled in
board file. The driver should be generic.
See my comments against the platform part of this patch.
#include media/davinci/dm355_ccdc.h
#include media/davinci/vpss.h
#include dm355_ccdc_regs.h
@@ -105,7 +106,6 @@ static struct ccdc_params_ycbcr
ccdc_hw_params_ycbcr = {
static enum vpfe_hw_if_type ccdc_if_type;
static void *__iomem ccdc_base_addr;
-static int ccdc_addr_size;
/* Raw Bayer formats */
static u32 ccdc_raw_bayer_pix_formats[] =
@@ -126,12 +126,6 @@ static inline void regw(u32 val, u32 offset)
__raw_writel(val, ccdc_base_addr + offset);
}
-static void ccdc_set_ccdc_base(void *addr, int size)
-{
-ccdc_base_addr = addr;
-ccdc_addr_size = size;
-}
-
static void ccdc_enable(int en)
{
unsigned int temp;
@@ -938,7 +932,6 @@ static struct ccdc_hw_device ccdc_hw_dev = {
.hw_ops = {
.open = ccdc_open,
.close = ccdc_close,
-.set_ccdc_base = ccdc_set_ccdc_base,
.enable = ccdc_enable,
.enable_out_to_sdram = ccdc_enable_output_to_sdram,
.set_hw_if_params = ccdc_set_hw_if_params,
@@ -959,19 +952,89 @@ static struct ccdc_hw_device ccdc_hw_dev = {
},
};
-static int __init dm355_ccdc_init(void)
+static int __init dm355_ccdc_probe(struct platform_device *pdev)
{
-printk(KERN_NOTICE dm355_ccdc_init\n);
-if (vpfe_register_ccdc_device(ccdc_hw_dev) 0)
-return -1;
+static resource_size_t res_len;
+struct resource *res;
+int status = 0;
+
+/**
+ * first try to register with vpfe. If not correct platform,
then we
+ * don't have to iomap
+ */
+status = vpfe_register_ccdc_device(ccdc_hw_dev);
+if (status 0)
+return status;
+
+res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+if (!res) {
+status = -ENOENT;
[Hiremath, Vaibhav] I think right return value is -ENODEV.
Right. I will change it.
+goto fail_nores;
+}
+res_len = res-end - res-start + 1;
+
+res = request_mem_region(res-start, res_len, res-name);
[Hiremath, Vaibhav] You should use resource_size here for res_len here.
Ok. I didn't know about such a function :(
Will change res_len - resource_size(res)
+if (!res) {
+status = -EBUSY;
+goto fail_nores;
+}
+
+ccdc_base_addr = ioremap_nocache(res-start, res_len);
+if (!ccdc_base_addr) {
+status = -EBUSY;
[Hiremath, Vaibhav] Is -EBUSY right return value, I think it should be -
ENXIO or -ENOMEM.
I see -ENXIO -ENOMEM being used by drivers. -ENXIO stands for No such device
or address. ENOMEM stands for Out of memory . Since we are trying to map the
address here, -ENXIO looks reasonable to me. Same if request_mem_region() fails.
+goto fail;
+}
+/**
+ * setup Mux configuration for vpfe input and register
+ * vpfe capture platform device
+ */
+davinci_cfg_reg(DM355_VIN_PCLK);
+davinci_cfg_reg(DM355_VIN_CAM_WEN);
+davinci_cfg_reg(DM355_VIN_CAM_VD);
+davinci_cfg_reg(DM355_VIN_CAM_HD);
+davinci_cfg_reg(DM355_VIN_YIN_EN);
+davinci_cfg_reg(DM355_VIN_CINL_EN);
+davinci_cfg_reg(DM355_VIN_CINH_EN);
+
[Hiremath, Vaibhav] This should not be here, this code must be generic and
might get used in another SoC.
yes. See my suggestion against the architecture part. will be replaced
with a setup_pinmux() fuction from platform_data.
printk(KERN_NOTICE %s is registered with vpfe.\n,
ccdc_hw_dev.name);
return 0;
+fail:
+release_mem_region(res-start, res_len);
+fail_nores:
+vpfe_unregister_ccdc_device(ccdc_hw_dev);
+return status;
}
-static void __exit dm355_ccdc_exit(void)
+static int dm355_ccdc_remove(struct platform_device *pdev)
{
+struct resource *res;
+
+iounmap(ccdc_base_addr);
+res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+if (res)
+release_mem_region(res-start, res-end - res-start +
1);
[Hiremath, Vaibhav] Please use resource_size here for size.
Ok.
vpfe_unregister_ccdc_device(ccdc_hw_dev);
+return 0;
+}
+
+static struct platform_driver dm355_ccdc_driver = {
+.driver = {
+.name = dm355_ccdc,
+.owner = THIS_MODULE,
+},
+.remove = __devexit_p(dm355_ccdc_remove),
+.probe = dm355_ccdc_probe,
+};
+
+static int __init dm355_ccdc_init(void)
+{
+return platform_driver_register(dm355_ccdc_driver);
+}
+
+static void __exit dm355_ccdc_exit(void)
+{
+platform_driver_unregister(dm355_ccdc_driver);
}
module_init(dm355_ccdc_init);
diff --git a/drivers/media/video/davinci/dm644x_ccdc.c
b/drivers/media/video/davinci/dm644x_ccdc.c
index d5fa193..89ea6ae 100644
--- a/drivers/media/video/davinci/dm644x_ccdc.c
+++
RE: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
Hans,
Please hold on to this. I will send you an updated patch.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, December 01, 2009 12:22 PM
To: 'Hans Verkuil'
Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org
Subject: FW: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
Hans,
Could you please add this to your hg tree and send a pull
request to Mauro? This was reviewed by Vaibhav and tested on
DM355, DM6446, AM3517 DM365. I will request Kevin to pull
the Architecture part of this patch.
Thanks.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, December 01, 2009 12:19 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Hiremath, Vaibhav;
Karicheri, Muralidharan
Subject: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
From: Muralidharan Karicheri m-kariche...@ti.com
v1 - updated based on comments from Vaibhav Hiremath.
On DM365 we use only vpss master clock, where as on DM355 and
DM6446, we use vpss master and slave clocks for vpfe capture and AM3517
we use internal clock and pixel clock. So this patch makes it configurable
on a per platform basis. This is needed for supporting DM365 for which
patches
will be available soon.
Tested-by: Vaibhav Hiremath hvaib...@ti.com, Muralidharan Karicheri m-
kariche...@ti.com
Acked-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/vpfe_capture.c | 98 +--
-
---
include/media/davinci/vpfe_capture.h | 11 ++-
2 files changed, 70 insertions(+), 39 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 12a1b3d..c3468ee 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1787,61 +1787,87 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
+/**
+ * vpfe_disable_clock() - Disable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Disables clocks defined in vpfe configuration.
+ */
static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
{
struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
+ int i;
- clk_disable(vpfe_cfg-vpssclk);
- clk_put(vpfe_cfg-vpssclk);
- clk_disable(vpfe_cfg-slaveclk);
- clk_put(vpfe_cfg-slaveclk);
- v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
+ for (i = 0; i vpfe_cfg-num_clocks; i++) {
+ clk_disable(vpfe_dev-clks[i]);
+ clk_put(vpfe_dev-clks[i]);
+ }
+ kfree(vpfe_dev-clks);
+ v4l2_info(vpfe_dev-pdev-driver, vpfe capture clocks disabled\n);
}
+/**
+ * vpfe_enable_clock() - Enable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Enables clocks defined in vpfe configuration. The function
+ * assumes that at least one clock is to be defined which is
+ * true as of now. re-visit this if this assumption is not true
+ */
static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
{
struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
- int ret = -ENOENT;
+ int i;
- vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
- if (NULL == vpfe_cfg-vpssclk) {
- v4l2_err(vpfe_dev-pdev-driver, No clock defined for
- vpss_master\n);
- return ret;
- }
+ if (!vpfe_cfg-num_clocks)
+ return 0;
- if (clk_enable(vpfe_cfg-vpssclk)) {
- v4l2_err(vpfe_dev-pdev-driver,
- vpfe vpss master clock not enabled\n);
- goto out;
- }
- v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master clock enabled\n);
+ vpfe_dev-clks = kzalloc(vpfe_cfg-num_clocks *
+sizeof(struct clock *), GFP_KERNEL);
- vpfe_cfg-slaveclk = clk_get(vpfe_dev-pdev, vpss_slave);
- if (NULL == vpfe_cfg-slaveclk) {
- v4l2_err(vpfe_dev-pdev-driver,
- No clock defined for vpss slave\n);
- goto out;
+ if (NULL == vpfe_dev-clks) {
+ v4l2_err(vpfe_dev-pdev-driver, Memory allocation failed\n);
+ return -ENOMEM;
}
- if (clk_enable(vpfe_cfg-slaveclk)) {
- v4l2_err(vpfe_dev-pdev-driver,
- vpfe vpss slave clock not enabled\n);
- goto out;
+ for (i = 0; i vpfe_cfg-num_clocks; i++) {
+ if (NULL == vpfe_cfg-clocks[i]) {
+ v4l2_err(vpfe_dev-pdev-driver,
+ clock %s is not defined in vpfe config
RE: [PATCH] V4L - Fix videobuf_dma_contig_user_get() getting page aligned physical address
Magnus, Thanks for the patch. For non-page aligned user space pointers I agree that a fix is needed. Don't you think the while loop in videobuf_dma_contig_user_get() also needs to be adjusted to include the last page? I think the while loop checks one page too little in the non-aligned case today. Cheers, / magnus Thanks for reviewing my patch. It had worked for non-aligned address in my testing. If I understand this code correctly, the physical address of the user page start is determined in the first loop (pages_done == 0) and additional loops are run to make sure the memory is physically contiguous. Initially the mem-size is set to number of pages aligned to page size. Assume we pass 4097 bytes as size. mem-size = PAGE_ALIGN(vb-size); = 2 Inside the loop, iteration is done for 0 to pages-1. pages_done (mem-size 12) = pages_done 2 = iterate 2 times For size of 4096, we iterate once. For size of 4095, we iterate once. So IMO the loop is already iterate one more time when we pass non-aligned address since size is aligned to include the last page. So based on this could you ack my patch so that we could ask Mauro to merge it with priority? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -- 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
FW: [PATCH - v1] V4L - Digital Video Timings API documentation
Hans,
I have updated the API documentation based on your comments and the updated
patch is sent to the list. So could you please send a pull request to Mauro for
the video timing API patch along with this documentation patch? If there are
any minor issues, I would prefer to fix it by another patch than re-working
this again.
Regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, December 02, 2009 5:56 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Karicheri, Muralidharan
Subject: [PATCH - v1] V4L - Digital Video Timings API documentation
From: Muralidharan Karicheri m-kariche...@ti.com
This patch updates the v4l2-dvb documentation for the new video timings API
added.
Also updated the document based on comments from Hans Verkuil
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
diff -uNr v4l-dvb-
e0cd9a337600_master/linux/Documentation/DocBook/v4l/common.xml v4l-dvb-
patch/linux/Documentation/DocBook/v4l/common.xml
--- v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/common.xml
2009-12-01 17:02:04.0 -0500
+++ v4l-dvb-patch/linux/Documentation/DocBook/v4l/common.xml 2009-12-
02 17:16:24.0 -0500
@@ -716,6 +716,41 @@
}
/programlisting
/example
+ section id=dv-timings
+ titleDigital Video (DV) Timings/title
+ para
+ The video standards discussed so far has been dealing with Analog TV
and the
+corresponding video timings. Today there are many more different hardware
interfaces
+such as High Definition TV interfaces (HDMI), VGA, DVI connectors etc.,
that carry
+video signals and there is a need to extend the API to select the video
timings
+ for these interfaces. Since it is not possible to extend the v4l2-std-id
due to
+the limited bits available, a new set of IOCTLs are added to set/get video
timings at
+the input and output: /paraitemizedlist
+ listitem
+ para DV Presets: Digital Video (DV) presets. These are IDs
representing a
+video timing at the input/output. Presets are pre-defined timings
implemented
+by the hardware according to video standards. A __u32 data type is used to
represent
+ a preset unlike the bit mask that is used in v4l2-std-id; allowing
future extensions
+ to support many different presets as needed./para
+ /listitem
+ listitem
+ para Custom DV Timings: This will allow applications to define more
detailed
+custom video timings at the interface. This includes parameters such as
width, height,
+ polarities, frontporch, backporch etc.
+ /para
+ /listitem
+ /itemizedlist
+ para To enumerate and query the attributes of DV presets supported
by a device,
+ applications use the VIDIOC-ENUM-DV-PRESETS; ioctl. To get the current
DV preset,
+ application use the VIDIOC-G-DV-PRESET; ioctl and to set a preset it
uses the
+ VIDIOC-S-DV-PRESET; ioctl./para
+ para To set a Custom DV timings at the device, applications use the
+ VIDIOC-S-DV-TIMINGS; ioctl and to get current Custom DV timings, it uses
the
+ VIDIOC-G-DV-TIMINGS; ioctl./para
+ para Applications can make use of the xref linkend=input-
capabilities / and
+xref linkend=output-capabilities/ flags to decide what ioctls are
available to set the
+video timings for the device./para
+ /section
/section
sub-controls;
diff -uNr v4l-dvb-
e0cd9a337600_master/linux/Documentation/DocBook/v4l/v4l2.xml v4l-dvb-
patch/linux/Documentation/DocBook/v4l/v4l2.xml
--- v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/v4l2.xml
2009-12-01 17:02:04.0 -0500
+++ v4l-dvb-patch/linux/Documentation/DocBook/v4l/v4l2.xml 2009-12-02
17:16:50.0 -0500
@@ -416,6 +416,10 @@
sub-enum-frameintervals;
sub-enuminput;
sub-enumoutput;
+sub-enum-dv-presets;
+sub-g-dv-preset;
+sub-query-dv-preset;
+sub-g-dv-timings;
sub-enumstd;
sub-g-audio;
sub-g-audioout;
diff -uNr v4l-dvb-
e0cd9a337600_master/linux/Documentation/DocBook/v4l/videodev2.h.xml v4l-
dvb-patch/linux/Documentation/DocBook/v4l/videodev2.h.xml
--- v4l-dvb-
e0cd9a337600_master/linux/Documentation/DocBook/v4l/videodev2.h.xml
2009-12-01 17:02:04.0 -0500
+++ v4l-dvb-patch/linux/Documentation/DocBook/v4l/videodev2.h.xml 2009-12-
02 17:44:24.0 -0500
@@ -734,6 +734,99 @@
};
/*
+ * V I D E O T I M I N G S D V P R E S E T
+ */
+struct link linkend=v4l2-dv-presetv4l2_dv_preset/link {
+__u32 preset;
+__u32 reserved[4];
+};
+
+/*
+ * D V P R E S E T S E N U M E R A T I O N
+ */
+struct link linkend=v4l2-dv-enum-presetv4l2_dv_enum_preset/link {
+__u32 index;
+__u32 preset;
+__u8name[32]; /* Name of the preset timing */
+__u32
architecture part of video driver patch
Kevin,
Following patch merged to v4l-dvb linux-next has an architectural
part as attached. If you have not merged it to your next branch
for linux-davinci tree, please do so at your earliest convenience
so that they are in sync.
Patch merged to linux-next is available at
http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=commitdiff;h=600cc66f7f3ec93ab4f09cf6b63980f4c5e8f8db
I will be pushing some more patches to upstream that are having
changes to arch part. I will notify once they are merged to linux-next.
Thanks.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
---BeginMessage---
From: Vaibhav Hiremath hvaib...@ti.com
The I2C adapter ID is actually depends on Board and may vary, Davinci
uses id=1, but in case of AM3517 id=3.
So modified respective davinci board files.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-davinci/board-dm355-evm.c |1 +
arch/arm/mach-davinci/board-dm644x-evm.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index f683559..4a9252a 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -372,6 +372,7 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = {
static struct vpfe_config vpfe_cfg = {
.num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .i2c_adapter_id = 1,
.sub_devs = vpfe_sub_devs,
.card_name = DM355 EVM,
.ccdc = DM355 CCDC,
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index cfd9afa..fed64e2 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -257,6 +257,7 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = {
static struct vpfe_config vpfe_cfg = {
.num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .i2c_adapter_id = 1,
.sub_devs = vpfe_sub_devs,
.card_name = DM6446 EVM,
.ccdc = DM6446 CCDC,
--
1.6.2.4
___
Davinci-linux-open-source mailing list
davinci-linux-open-sou...@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
---End Message---
linux-media documentation fails to build
Hi, I had downloaded the v4l2-dvb tree few days back to create my video timings API documentation and it had compiled fine when I did, make media-spec I still can build using the old tar ball. But today, I downloaded v4l-dvb-e0cd9a337600.tar.gz, it fails immediately after running the make_myconfig.pl script with the error No rule to make target 'media-spec'. Stop Has something changed last few days that broke the build? I need to make updates to video timing API documentation based on Han's review comments and I am stuck at this issue now :( Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: linux-media documentation fails to build
Some body removed media-spec target from v4l/Makefile. I got it working with make spec. Why to change target name like this? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Karicheri, Muralidharan Sent: Tuesday, December 01, 2009 5:28 PM To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab; Hans Verkuil Subject: linux-media documentation fails to build Hi, I had downloaded the v4l2-dvb tree few days back to create my video timings API documentation and it had compiled fine when I did, make media-spec I still can build using the old tar ball. But today, I downloaded v4l-dvb- e0cd9a337600.tar.gz, it fails immediately after running the make_myconfig.pl script with the error No rule to make target 'media-spec'. Stop Has something changed last few days that broke the build? I need to make updates to video timing API documentation based on Han's review comments and I am stuck at this issue now :( Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v0 1/2] V4L - vpfe capture - make clocks configurable
Vaibhav,
Thanks for testing this. I will update the patch for your comments.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hiremath, Vaibhav
Sent: Tuesday, November 24, 2009 11:25 PM
To: Karicheri, Muralidharan; linux-media@vger.kernel.org;
hverk...@xs4all.nl; khil...@deeprootsystems.com
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Subject: RE: [PATCH - v0 1/2] V4L - vpfe capture - make clocks configurable
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On
Behalf Of Karicheri, Muralidharan
Sent: Wednesday, November 25, 2009 5:07 AM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Subject: [PATCH - v0 1/2] V4L - vpfe capture - make clocks
configurable
From: Muralidharan Karicheri m-kariche...@ti.com
On DM365 we use only vpss master clock, where as on DM355 and
DM6446, we use vpss master and slave clocks for vpfe capture.
[Hiremath, Vaibhav] Adding one more platform here, AM3517, which uses 2
clocks, internal clock used by internal logic and pixel clock.
Some minor review comments below -
Please note that I have validated these changes already on AM3517EVM, so
adding -
Tested-by: Vaibhav Hiremath hvaib...@ti.com
Acked-by: Vaibhav Hiremath hvaib...@ti.com
Thanks,
Vaibhav
So
this
patch makes it configurable on a per platform basis. This is
needed for supporting DM365 for which patches will be available
soon.
This is for review only. For merge to upstream, it will be
re-crated against the v4l-dbv tree.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/vpfe_capture.c | 98
+--
include/media/davinci/vpfe_capture.h | 11 ++-
2 files changed, 70 insertions(+), 39 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index cad60e3..1ba9d07 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1743,61 +1743,87 @@ static struct vpfe_device
*vpfe_initialize(void)
return vpfe_dev;
}
+/**
+ * vpfe_disable_clock() - Disable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Disables clocks defined in vpfe configuration.
+ */
static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
{
struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
+int i;
-clk_disable(vpfe_cfg-vpssclk);
-clk_put(vpfe_cfg-vpssclk);
-clk_disable(vpfe_cfg-slaveclk);
-clk_put(vpfe_cfg-slaveclk);
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
+for (i = 0; i vpfe_cfg-num_clocks; i++) {
+clk_disable(vpfe_dev-clks[i]);
+clk_put(vpfe_dev-clks[i]);
+}
+kfree(vpfe_dev-clks);
+v4l2_info(vpfe_dev-pdev-driver, vpfe capture clocks
disabled\n);
}
+/**
+ * vpfe_enable_clock() - Enable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Enables clocks defined in vpfe configuration. The function
+ * assumes that at least one clock is to be defined which is
+ * true as of now. re-visit this if this assumption is not true
+ */
static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
{
struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-int ret = -ENOENT;
+int ret = -EFAULT, i;
[Hiremath, Vaibhav] No need of variable ret, since we are not making use
of it. We can directly return -EFAULT from out: label.
Thanks,
Vaibhav
-vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
-if (NULL == vpfe_cfg-vpssclk) {
-v4l2_err(vpfe_dev-pdev-driver, No clock defined for
- vpss_master\n);
-return ret;
-}
+if (!vpfe_cfg-num_clocks)
+return 0;
-if (clk_enable(vpfe_cfg-vpssclk)) {
-v4l2_err(vpfe_dev-pdev-driver,
-vpfe vpss master clock not enabled\n);
-goto out;
-}
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master clock enabled\n);
+vpfe_dev-clks = kzalloc(vpfe_cfg-num_clocks *
+ sizeof(struct clock *), GFP_KERNEL);
-vpfe_cfg-slaveclk = clk_get(vpfe_dev-pdev, vpss_slave);
-if (NULL == vpfe_cfg-slaveclk) {
-v4l2_err(vpfe_dev-pdev-driver,
-No clock defined for vpss slave\n);
-goto out;
+if (NULL == vpfe_dev-clks) {
+v4l2_err(vpfe_dev-pdev-driver, Memory allocation
failed\n);
+return -ENOMEM;
}
-if (clk_enable(vpfe_cfg-slaveclk)) {
-v4l2_err(vpfe_dev-pdev-driver,
- vpfe vpss slave clock
RE: [PATCH 3/4 v8] TVP7002 driver for DM365
Hans, Note: Murali made a new function that will fill in the v4l2_dv_enum_preset based on the preset value. It's not yet in the v4l-dvb repository although I hope that the timing patches will go in soon. The only thing I'm waiting for is the revised documentation patch. I will try to spend some time on these this week. BTW: I think we need a g_dv_preset ops as well. That seems to be missing. Murali, is there any reason why we do not have that? One reason is we don't have a g_std() ops since core maintains the current norm. Other reason is at this point I don't see why we need this since bridge device driver is going to save the current std or current dv_preset set by application if s_std() or s_dv_preset() is successful. So if application calls G_DV_PRESET, bridge device driver will return the last successful std or dv_preset value. If we really need it for some reason, we could add it later when we integrate the vpfe/vpif drivers with this driver. +} Did you check whether it is really needed to power the chip off and on here? It still makes no sense to me that you have to do this. Can we make this a TODO item which can be addressed later? This driver is holding up my vpfe enhancements to support HD. This works functionally and we can always enhance the driver as required. So I suggest to keep this as a TODO item and address later using another patch. Murali -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/4 v10] TVP7002 driver for DM365
-Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Friday, November 27, 2009 10:07 PM To: santiago.nu...@ridgerun.com Cc: davinci-linux-open-sou...@linux.davincidsp.com; linux- me...@vger.kernel.org; Narnakaje, Snehaprabha; Karicheri, Muralidharan; diego.do...@ridgerun.com; todd.fisc...@ridgerun.com; Grosen, Mark Subject: Re: [PATCH 3/4 v10] TVP7002 driver for DM365 On Friday 27 November 2009 23:32:20 santiago.nu...@ridgerun.com wrote: From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com This patch provides the implementation of the TVP7002 decoder driver for DM365. Implemented using the V4L2 DV presets API. Removed shadow register values. Testing shows that the device needs not to be powered down and up for correct behaviour. Improved readability. Ok. That is great!. Looks like we are almost ready for merge. So please ignore my previous comments to keep this issue as a TODO list. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings
Mauro, I have submitted the doc patch for review. But no comments so far. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Tuesday, November 24, 2009 11:42 AM To: Hans Verkuil Cc: v4l-dvb; Karicheri, Muralidharan Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings for the following: - v4l: Adding Digital Video Timings APIs This adds an important missing piece to the V4L2 API: the ability to receive and transmit HDTV video. The documentation needs another review cycle, mostly for grammar and style, but that should prevent this patch from going in. I had some bad experiences of not merging both specs and patches at the same time... DVB S2 API were added one year ago, and the promises were that the doc patches would be sent 1-2 weeks after the merge... we're still waiting for it... So, please submit both specs and code changes at the same pull request. As a bonus, reviewing both docs and patches at the same time are easier than doing it in separate. Many thanks to Murali and everyone else who has been involved in the discussions and reviews for this new API. Thanks, Hans diffstat: drivers/media/video/v4l2-compat-ioctl32.c |6 + drivers/media/video/v4l2-ioctl.c | 147 ++ include/linux/videodev2.h | 116 +++ include/media/v4l2-ioctl.h| 15 +++ include/media/v4l2-subdev.h | 21 5 files changed, 303 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings
Mauro, So, I'm basically trusting that one of you will do the sub-maintainers job of adding the patches on a tree and asking me to pull. Currently, Sakari and Hans have accounts at linuxtv that can be used for that purpose. You may also host your -hg trees on any other place and ask me to pull from it. Currently all the patches go through Hans. If you (TI) think that you need another -hg account, feel free to send me a private email for me to create it, but please don't ask me to dig into I think we will have to do it eventually. We will work on this and let you know once we have this ready. Even in that case, H individual patches, since it won't scale. In the specific case of the V4L/DVB timings API, if you think that the current doc proposal is OK, please merge it with the patches into some -hg tree and ask me to pull from it. See email from Hans. Once he gives me his comments, I will work on it and provide an updated patch. But IMO you should go ahead and merge the video timing API patch for which Hans had sent you a pull request (since we have the documentation part being reviewed in the list). We are waiting for this to be merged to send additional patches that depends on it. So this is a high priority patch for 2.6.33. Thanks and regards, Murali Thanks, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH/RFC 7/9 v2] v4l: add an image-bus API for configuring v4l2 subdev pixel and frame formats
Hi,
I guess this is only one part of the required API support for setting
bus configuration for which I had sent an RFC some time back. I am sure
we need to set bus image/data format in vpfe/vpbe drivers of DMxxx.
I am starting to do more upstream work for vpfe capture display drivers and
would like to submit an updated RFC for bus configuration. I am not sure if
someone is already working on that RFC.
Looks like we need to have two APIs at sub-device level for handling this.
One for image data format (Which is addressed by this RFC) and other for
hardware signals like polarities, bus type etc. Any comments?
BTW, I didn't have a chance to go over Guennadi's RFC for bus image format
so far and hope to spend sometime on this next week.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Friday, November 20, 2009 7:29 AM
To: Guennadi Liakhovetski
Cc: Linux Media Mailing List; Laurent Pinchart; Sakari Ailus; Karicheri,
Muralidharan
Subject: Re: [PATCH/RFC 7/9 v2] v4l: add an image-bus API for configuring
v4l2 subdev pixel and frame formats
On Thursday 19 November 2009 23:33:22 Guennadi Liakhovetski wrote:
Hi Hans
On Sun, 15 Nov 2009, Hans Verkuil wrote:
[snip]
+s32 v4l2_imgbus_bytes_per_line(u32 width,
+ const struct v4l2_imgbus_pixelfmt *imgf)
+{
+switch (imgf-packing) {
+case V4L2_IMGBUS_PACKING_NONE:
+return width * imgf-bits_per_sample / 8;
+case V4L2_IMGBUS_PACKING_2X8_PADHI:
+case V4L2_IMGBUS_PACKING_2X8_PADLO:
+case V4L2_IMGBUS_PACKING_EXTEND16:
+return width * 2;
+}
+return -EINVAL;
+}
+EXPORT_SYMBOL(v4l2_imgbus_bytes_per_line);
As you know, I am not convinced that this code belongs in the core.
I do not think this translation from IMGBUS to PIXFMT is generic
enough. However, if you just make this part of soc-camera then I am
OK with this.
Are you referring to a specific function like
v4l2_imgbus_bytes_per_line or to the whole v4l2-imagebus.c?
I'm referring to the whole file.
The whole file and the
v4l2_imgbus_get_fmtdesc() function must be available to all drivers,
not just to soc-camera, if we want to use {enum,g,s,try}_imgbus_fmt
API in other drivers too, and we do want to use them, if we want to
re-use client drivers.
The sub-device drivers do not need this source. They just need to
report the supported image bus formats. And I am far from convinced
that other bridge drivers can actually reuse your v4l2-imagebus.c code.
You mean, all non-soc-camera bridge drivers only handle special client
formats, no generic pass-through?
That's correct. It's never been a problem until now. Usually the format is
fixed, so there is nothing to configure.
What about other SoC v4l host drivers,
not using soc-camera, and willing to switch to v4l2-subdev? Like OMAPs,
etc? I'm sure they would want to be able to use the pass-through mode
And if they can reuse your code, then we will rename it to v4l2-busimage.c
But I have my doubts about that. I don't like that code, but I also don't
have the time to think about a better alternative. As long as it is
soc-camera specific, then I don't mind. And if omap3 can reuse it, then I
clearly was wrong and we can rename it and make it part of the core
framework.
If they can, then we can always rename it from e.g. soc-imagebus.c to
v4l2-imagebus.c. Right now I prefer to keep it inside soc-camera where
is clearly does work and when other people start implementing imagebus
support, then we can refer them to the work you did in soc-camera and
we'll see what happens.
You know how it happens - some authors do not know about some hidden
code, during the review noone realises, that they are re-implementing
that... Eventually you end up with duplicated customised sub-optimal
code. Fresh example - the whole soc-camera framework:-) I only learned
about int-device after soc-camera has already been submitted in its
submission form. And I did ask on lists whether there was any code for
such systems:-)
All the relevant omap developers are CC-ed in this discussion, and I'm also
paying fairly close attention to anything SoC related.
I do not quite understand what disturbs you about making this API global.
It is a completely internal API - no exposure to user-space. We can
modify or remove it any time.
Then think about wider exposure, testing. If you like we can make it a
separate module and make soc-camera select it. And we can always degrade
it back to soc-camera-specific:-)
Making this API global means that it becomes part of the framework. And I
want to pay a lot more attention to that code than we did in the past. So I
have to be convinced that it is code that is really reusable
RE: [PATCH] Adding helper function to get dv preset description
Hans,
I feel the same way. I will send an updated patch.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Friday, November 20, 2009 7:41 AM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou...@linux.davincidsp.com
Subject: Re: [PATCH] Adding helper function to get dv preset description
On Thursday 19 November 2009 17:09:47 m-kariche...@ti.com wrote:
From: Muralidharan Karicheri m-kariche...@ti.com
This patch add a helper function to get description of a digital
video preset added by the video timing API. Hope this will be
usefull for drivers implementing the above API.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
NOTE: depends on the patch that adds video timing API.
This is very inefficient memory-wise. struct v4l2_dv_enum_preset takes 52
bytes and since I expect that we will see a lot of presets in the future,
this can add up very quickly.
IMHO it is better to make a separate struct:
struct v4l2_dv_preset_info {
u16 width;
u16 height;
const char *name;
};
static const struct v4l2_dv_preset_info dv_presets[] = {
{0,0, Invalid }, /* V4L2_DV_INVALID */
{ 720, 480, 4...@59.94 }, /* V4L2_DV_480P59_94 */
};
This is a lot more compact, especially with the strings.
---
Applies to V4L-DVB linux-next branch
drivers/media/video/v4l2-common.c | 135
+ include/media/v4l2-common.h |
1 +
2 files changed, 136 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c index f5a93ae..245e727 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -1015,3 +1015,138 @@ void v4l_bound_align_image(u32 *w, unsigned int
wmin, unsigned int wmax, }
}
EXPORT_SYMBOL_GPL(v4l_bound_align_image);
+
+/**
+ * v4l_fill_dv_preset_info - fill description of a digital video preset
+ * @preset - preset value
+ * @info - pointer to struct v4l2_dv_enum_preset
+ *
+ * drivers can use this helper function to fill description of dv preset
+ * in info.
+ */
+int v4l_fill_dv_preset_info(u32 preset, struct v4l2_dv_enum_preset
*info) +{
+static const struct v4l2_dv_enum_preset dv_presets[] = {
+{
+.preset = V4L2_DV_480P59_94,
+.name = 4...@59.94,
+.width = 720,
+.height = 480,
+},
+{
+.preset = V4L2_DV_576P50,
+.name = 5...@50,
+.width = 720,
+.height = 576,
+},
+{
+.preset = V4L2_DV_720P24,
+.name = 7...@24,
+.width = 1280,
+.height = 720,
+},
+{
+.preset = V4L2_DV_720P25,
+.name = 7...@25,
+.width = 1280,
+.height = 720,
+},
+{
+.preset = V4L2_DV_720P30,
+.name = 7...@30,
+.width = 1280,
+.height = 720,
+},
+{
+.preset = V4L2_DV_720P50,
+.name = 7...@50,
+.width = 1280,
+.height = 720,
+},
+{
+.preset = V4L2_DV_720P59_94,
+.name = 7...@59.94,
+.width = 1280,
+.height = 720,
+},
+{
+.preset = V4L2_DV_720P60,
+.name = 7...@60,
+.width = 1280,
+.height = 720,
+},
+{
+.preset = V4L2_DV_1080I29_97,
+.name = 10...@29.97,
+.width = 1920,
+.height = 1080,
+},
+{
+.preset = V4L2_DV_1080I30,
+.name = 10...@30,
+.width = 1920,
+.height = 1080,
+},
+{
+.preset = V4L2_DV_1080I25,
+.name = 10...@25,
+.width = 1920,
+.height = 1080,
+},
+{
+.preset = V4L2_DV_1080I50,
+.name = 10...@50,
+.width = 1920,
+.height = 1080,
+},
+{
+.preset = V4L2_DV_1080I60,
+.name = 10...@60,
+.width = 1920,
+.height = 1080
