RE: [PATCH] [media] at91: add Atmel Image Sensor Interface (ISI) support
Hi, JC
+struct atmel_isi;
do we really this here?
Not really. I'll remove this.
+
[snip]
if VIDEO_CAPTURE_DRIVERS VIDEO_V4L2
+config VIDEO_ATMEL_ISI
+tristate ATMEL Image Sensor Interface (ISI) support
+depends on VIDEO_DEV SOC_CAMERA
depends on AT91 if the drivers is at91 specific or avr32 otherwise
I'll add that. I think now it is only supported AT91. I am not sure for the
AVR32 part
+select VIDEOBUF2_DMA_CONTIG
+default n
it's n by default please remove
I'll change that.
[snip]
+
+/* Frame buffer descriptor
+ * Used by the ISI module as a linked list for the DMA controller.
+ */
+struct fbd {
+/* Physical address of the frame buffer */
+u32 fb_address;
+#if defined(CONFIG_ARCH_AT91SAM9G45) ||\
+defined(CONFIG_ARCH_AT91SAM9X5)
+/* DMA Control Register(only in HISI2) */
+u32 dma_ctrl;
+#endif
no ifdef in the struct
I'll remove this #if. I think for the non-HISI2 version, like AT91SAM9263, we
should define another FBD structure which not includes dma_ctrl.
+/* Physical address of the next fbd */
+u32 next_fbd_address;
+};
+
+#if defined(CONFIG_ARCH_AT91SAM9G45) ||\
+defined(CONFIG_ARCH_AT91SAM9X5)
+static void set_dma_ctrl(struct fbd *fb_desc, u32 ctrl) {
+fb_desc-dma_ctrl = ctrl;
+}
+#else
+static void set_dma_ctrl(struct fbd *fb_desc, u32 ctrl) { } #endif
no ifdef here also as we want to have multi soc support
I'll remove this #if also.
[snip]
+/* State of the ISI module in capturing mode */
+int state;
+
+/* Capture/streaming wait queue for waiting for SOF */
+wait_queue_head_t capture_wq;
+
+struct v4l2_device v4l2_dev;
+
+struct vb2_alloc_ctx*alloc_ctx;
+
+struct clk *pclk;
+struct platform_device *pdev;
do you really need to store the pdev?
I'll remove this. It is no use.
+unsigned intirq;
+
+struct isi_platform_data*pdata;
+unsigned long platform_flags;
+
+struct list_headvideo_buffer_list;
+struct frame_buffer *active;
+
+struct soc_camera_device*icd;
+struct soc_camera_host soc_host;
+};
+
+static int configure_geometry(struct atmel_isi *isi, u32 width,
+u32 height, enum v4l2_mbus_pixelcode code) {
+u32 cfg2, cr, ctrl;
+
+cr = 0;
please move this in default
I'll remove this cr line. Seems it is not needed. cr will be initialized by the
following code.
[snip]
+
+size = bytes_per_line * icd-user_height;
+
+if (0 == *nbuffers)
please invert the test
I'll fix it.
+*nbuffers = MAX_BUFFER_NUMS;
+if (*nbuffers MAX_BUFFER_NUMS)
+*nbuffers = MAX_BUFFER_NUMS;
+
+while (size * *nbuffers vid_limit * 1024 * 1024)
+(*nbuffers)--;
+
+*nplanes = 1;
+sizes[0] = size;
+alloc_ctxs[0] = dev-alloc_ctx;
+
+dev-sequence = 0;
+dev-active = NULL;
+
+dev_dbg(icd-dev.parent, %s, count=%d, size=%ld\n, __func__,
+*nbuffers, size);
+
+return 0;
+}
+
+
+static void start_dma(struct atmel_isi *isi, struct frame_buffer
+*buffer) {
+u32 ctrl, cfg1;
please add ine ligne here
OK. I'll change that.
+ctrl = isi_readl(isi, V2_CTRL);
+cfg1 = isi_readl(isi, V2_CFG1);
+/* Enable irq: cxfr for the codec path, pxfr for the preview path */
+isi_writel(isi, V2_INTEN,
+ISI_BIT(V2_CXFR_DONE) | ISI_BIT(V2_PXFR_DONE));
+
+/* Enable codec path */
+ctrl |= ISI_BIT(V2_CDC);
+/* Check if already in a frame */
+while (isi_readl(isi, V2_STATUS) ISI_BIT(V2_CDC))
+cpu_relax();
no timeout?
I'll add time out code and test it.
+
+/* Write the address of the first frame buffer in the C_ADDR reg
+* write the address of the first descriptor(link list of buffer)
+* in the C_DSCR reg, and enable dma channel.
+*/
+isi_writel(isi, V2_DMA_C_DSCR, (__pa((buffer-fb_desc;
+isi_writel(isi, V2_DMA_C_CTRL,
+ISI_BIT(V2_DMA_FETCH) | ISI_BIT(V2_DMA_DONE));
+isi_writel(isi, V2_DMA_CHER, ISI_BIT(V2_DMA_C_CH_EN));
+
+/* Enable linked list */
+cfg1 |= ISI_BF(V2_FRATE, isi-pdata-frate) | ISI_BIT(V2_DISCR);
+
+/* Enable ISI module*/
+ctrl |= ISI_BIT(V2_ENABLE);
+isi_writel(isi, V2_CTRL, ctrl);
+isi_writel(isi, V2_CFG1, cfg1);
+}
+
+
+/* abort streaming and wait for last buffer */ static int
+stop_streaming(struct vb2_queue *vq) {
+struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
+struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+struct atmel_isi *isi = ici-priv;
+
+spin_lock_irq(isi-lock);
+isi-still_capture = 0;
+isi-active = NULL;
+
+while (isi_readl(isi, V2_STATUS) ISI_BIT(V2_CDC))
+
Re: adding dvb-t scan files for New Zealand
2011/5/16 Jodi the Tigger jodi.the.tig...@gmail.com: Sure! find 13 files attached: nz-AucklandInfill nz-AucklandWaiatarua nz-Christchurch nz-Dunedin nz-Hamilton nz-HawkesBayMtErin nz-HawkesBayNapier nz-Manawatu nz-Tauranga nz-Waikato nz-WellingtonInfill nz-WellingtonKaukau nz-WellingtonNgarara -Richard Maxwell snip Updated, thanks. Christoph -- 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: [Linaro-mm-sig] Video4Linux API for shared buffers
Hi Mauro, CC'ing linux-media, as the topic is of interest for the V4L2 developers. On Saturday 14 May 2011 11:19:49 Mauro Carvalho Chehab wrote: After the mm panels, I had a few discussions with Hans, Rob and Daniel, among others, during the V4L and KMS discussions and after that. Based on those discussions, I'm pretty much convinced that the normal MMAP way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's) are not the best way to share data with framebuffers. We probably need something that it is close to VIDIOC_FBUF/VIDIOC_OVERLAY, but it is still not the same thing. Why do you think so ? Can you explain what serious limitations you see in the current buffer-based API that would prevent sharing data with frame buffers (I'm talking about both fbdev and KMS) ? I suspect that working on such API is somewhat orthogonal to the decision of using a file pointer based or a bufer ID based based kABI for passing the buffer parameters to the newly V4L calls, Userspace won't pass a file pointer to the kernel, it will pass a file descriptor number. but we cannot decide about the type of buffer ID that we'll use if we not finish working at an initial RFC for the V4L API, as the way the buffers will be passed into it will depend on how we design such API. Shouldn't it be the other way around ? On the kernel side the dma buffer API will offer a function that converts a buffer ID, whatever it is, to a dma buffer structure pointer, so I don't think it matters much for drivers. It should be also noticed that, while in the shared buffers some definitions can be postponed to happen later (as it is basically a Kernelspace-only ABI - at least initially), the V4L API should be designed to consider all possible scenarios, as diamonds and userspace API's are forever(tm). It seems to me that the proper way to develop such API is starting working with Xorg V4L driver, changing it to work with KMS and with the new API (probably porting some parts of it to kernelspace). I'm not sure to follow you here. Please remember that X is not a requirement, we definitely want to share buffers between fbdev and V4L2 in X-less systems. One of the problems with a shared framebuffer is that an overlayed V4L stream may, at the worse case, be sent to up to 4 different GPU's and/or displays, like: ===+=== | D1 +|---+ D2 | | | | V4L| | | +-|+---|--| | D3 ++---+ D4 | === Where D1, D2, D3 and D4 are 4 different displays, and the same V4L framebuffer is partially shared between them (the above is an example of a V4L input, although the reverse scenario of having one frame buffer divided into 4 V4L outputs also seems to be possible). As the same image may be divided into 4 monitors, the buffer filling should be synced with all of them, in order to avoid flipping effects. Also, the buffer can't be re-used until all displays finish reading. Display API's currently has similar issues. From what I understood from Rob and Daniel, this is solved there by dynamically allocating buffers. So, we may need to do something similar to that also at V4L (in a matter of fact, there's currently a proposal to hack REQBUF's, in order to extend V4L API to allow dynamically creating more buffers than used by a stream). It makes sense to me to discuss such proposal together with the above discussions, in order to keep the API consistent. From my side, I'm expecting that the responsible(s) for the API proposals to also provide with open source drivers and userspace application(s), that allows to test and validate such API RFC. -- 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: [PATCH 3/3] adp1653: Add driver for LED flash controller
Hi Sakari,
On Tuesday 17 May 2011 07:38:38 Sakari Ailus wrote:
Laurent Pinchart wrote:
On Monday 16 May 2011 15:00:39 Sakari Ailus wrote:
This patch adds the driver for the adp1653 LED flash controller. This
controller supports a high power led in flash and torch modes and an
indicator light, sometimes also called privacy light.
The adp1653 is used on the Nokia N900.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
Signed-off-by: Tuukka Toivonen tuukka...@gmail.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: David Cohen daco...@gmail.com
[snip]
diff --git a/drivers/media/video/adp1653.c
b/drivers/media/video/adp1653.c new file mode 100644
index 000..92ea38b
--- /dev/null
+++ b/drivers/media/video/adp1653.c
[snip]
+/* Write values into ADP1653 registers. */
+static int adp1653_update_hw(struct adp1653_flash *flash)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(flash-subdev);
+ u8 out_sel;
+ u8 config = 0;
+ int rval;
+
+ out_sel = flash-indicator_intensity-val
+ ADP1653_REG_OUT_SEL_ILED_SHIFT;
+
+ switch (flash-led_mode-val) {
+ case V4L2_FLASH_LED_MODE_NONE:
+ break;
+ case V4L2_FLASH_LED_MODE_FLASH:
+ /* Flash mode, light on with strobe, duration from timer */
+ config = ADP1653_REG_CONFIG_TMR_CFG;
+ config |= TIMEOUT_US_TO_CODE(flash-flash_timeout-val)
+ ADP1653_REG_CONFIG_TMR_SET_SHIFT;
+ break;
+ case V4L2_FLASH_LED_MODE_TORCH:
+ /* Torch mode, light immediately on, duration indefinite */
+ out_sel |= flash-torch_intensity-val
+ ADP1653_REG_OUT_SEL_HPLED_SHIFT;
+ break;
+ }
+
+ rval = i2c_smbus_write_byte_data(client, ADP1653_REG_OUT_SEL,
out_sel);
out_sel can be used uninitialized here.
I don't think so. It's assigned a value in the beginning of the function.
My bad, I missed that. Sorry.
+ if (rval 0)
+ return rval;
+
+ rval = i2c_smbus_write_byte_data(client, ADP1653_REG_CONFIG, config);
+ if (rval 0)
+ return rval;
+
+ return 0;
+}
[snip]
+static int adp1653_get_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct adp1653_flash *flash =
+ container_of(ctrl-handler, struct adp1653_flash, ctrls);
+ struct i2c_client *client = v4l2_get_subdevdata(flash-subdev);
+ int fault;
+ int rval;
+
+ fault = i2c_smbus_read_byte_data(client, ADP1653_REG_FAULT);
+ if (IS_ERR_VALUE(fault))
+ return fault;
+
+ /* Clear faults. */
+ rval = i2c_smbus_write_byte_data(client, ADP1653_REG_OUT_SEL, 0);
+ if (IS_ERR_VALUE(rval))
+ return rval;
If several applications read controls, only one of them will be notified
of faults. Shouldn't clearing the fault be handled explicitly by writing
to a control ? I know this changes the API :-)
This is true.
Although I can't imagine right now why two separate processes should be
so interested in the faults but it is still entirely possible that
someone does that since it's permitted by the interface.
Having to write zero to faults to clear them isn't good either since it
might mean missing faults that are triggered between reading and writing
this control.
Perhaps this would make sense as a file handle specific control?
Good question. Control events will help I guess, maybe that's the solution.
The control documentation says that the faults are cleared when the
register is read, but the adp1653 also clears the faults whenever
writing zero to out_sel which happens also in other circumstances, for
example when changing mode from flash to torch when the torch intensity
is zero, or when indicator intensity is zero in other modes.
+ /* Restore configuration. */
+ rval = adp1653_update_hw(flash);
+ if (IS_ERR_VALUE(rval))
+ return rval;
Will that produce expected results ? For instance, if a fault was
detected during flash strobe, won't it try to re-strobe the flash ?
Shouldn't the user
No. Flash is strobed using adp1653_strobe().
be required to explicitly re-strobe the flash or turn the torch (or
indicator) on after a fault ? Once again this should be clarified in the
API :-)
The mode won't be changed from the flash but to strobe again, the user
has to push V4L2_CID_FLASH_STROBE again.
The adp1653 doesn't have any torch (as such) or indicator faults; some
other chips do have indicator faults at least. Using the torch mode
might trigger faults, too, since it's the same LED; just the power isn't
that high.
When an over-current fault is detected, shouldn't the mode be set back to none
? If we just clear the fault and reprogram the registers, the torch will be
turned back on, and the fault will likely happen again.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the
[GIT PATCHES FOR 2.6.40] gspca for_v2.6.40
The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v2.6.40 Jean-François Moine (10): gspca - cpia1: Fix some warnings. gspca - kinect: Remove __devinitdata gspca - stk014 / t613: Accept the index 0 in querymenu gspca - main: Version change to 2.13 gspca - main: Remove USB traces gspca - cpia1: Remove a bad conditional compilation instruction gspca: Unset debug by default gspca: Fix some warnings tied to 'no debug' gspca - sunplus: Simplify code and fix some warnings gspca - sunplus: Simplify code and fix some errors when 'debug' drivers/media/video/gspca/cpia1.c |6 +-- drivers/media/video/gspca/gl860/gl860.c | 15 + drivers/media/video/gspca/gspca.c |4 +- drivers/media/video/gspca/gspca.h |6 +- drivers/media/video/gspca/kinect.c |2 +- drivers/media/video/gspca/spca508.c |5 +- drivers/media/video/gspca/stk014.c | 15 ++--- drivers/media/video/gspca/sunplus.c | 99 ++ drivers/media/video/gspca/t613.c| 17 ++ drivers/media/video/gspca/zc3xx.c |5 +- 10 files changed, 61 insertions(+), 113 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] [media] at91: add Atmel Image Sensor Interface (ISI) support
On Friday, May 13, 2011 5:25 AM, Ryan Mallon wrote
On 05/12/2011 07:42 PM, Josh Wu wrote:
This patch is to enable Atmel Image Sensor Interface (ISI) driver support.
- Using soc-camera framework with videobuf2 dma-contig allocator
- Supporting video streaming of YUV packed format
- Tested on AT91SAM9M10G45-EK with OV2640
Hi Josh,
Thansk for doing this. Overall the patch looks really good. A few
comments below.
Hi, Ryan
Thank you for the comments.
Signed-off-by: Josh Wu josh...@atmel.com
---
base on branch staging/for_v2.6.40
arch/arm/mach-at91/include/mach/at91_isi.h | 454
drivers/media/video/Kconfig| 10 +
drivers/media/video/Makefile |1 +
drivers/media/video/atmel-isi.c| 1089
4 files changed, 1554 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-at91/include/mach/at91_isi.h
create mode 100644 drivers/media/video/atmel-isi.c
[snip]
+
+/* Bit manipulation macros */
+#define ISI_BIT(name) \
+(1 ISI_##name##_OFFSET)
+#define ISI_BF(name, value) \
+(((value) ((1 ISI_##name##_SIZE) - 1)) \
+ ISI_##name##_OFFSET)
+#define ISI_BFEXT(name, value) \
+(((value) ISI_##name##_OFFSET) \
+ ((1 ISI_##name##_SIZE) - 1))
+#define ISI_BFINS(name, value, old) \
+(((old) ~(((1 ISI_##name##_SIZE) - 1) \
+ ISI_##name##_OFFSET))\
+ | ISI_BF(name, value))
I really dislike this kind of register access magic. Not sure how others
feel about it. These macros are really ugly.
I understand this. So I will try to find a better way (static inline function)
to solve this. :)
+/* Register access macros */
+#define isi_readl(port, reg)\
+__raw_readl((port)-regs + ISI_##reg)
+#define isi_writel(port, reg, value)\
+__raw_writel((value), (port)-regs + ISI_##reg)
If the token pasting stuff gets dropped then these can be static inline
functions which is preferred.
sure, I'll try.
[snip]
+#define ISI_GS_2PIX_PER_WORD0x00
+#define ISI_GS_1PIX_PER_WORD0x01
+u8 pixfmt;
+u8 sfd;
+u8 sld;
+u8 thmask;
+#define ISI_BURST_4_8_160x00
+#define ISI_BURST_8_16 0x01
+#define ISI_BURST_160x02
+u8 frate;
+#define ISI_FRATE_DIV_2 0x01
+#define ISI_FRATE_DIV_3 0x02
+#define ISI_FRATE_DIV_4 0x03
+#define ISI_FRATE_DIV_5 0x04
+#define ISI_FRATE_DIV_6 0x05
+#define ISI_FRATE_DIV_7 0x06
+#define ISI_FRATE_DIV_8 0x07
+};
Might need some comments in this structure so that board file writers
know what each of the fields are for.
I think this part will be change a little bit. Also I will add the updated
comments.
+
+#endif /* __AT91_ISI_H__ */
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index d61414e..eae6005 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -80,6 +80,16 @@ menuconfig VIDEO_CAPTURE_DRIVERS
Some of those devices also supports FM radio.
if VIDEO_CAPTURE_DRIVERS VIDEO_V4L2
+config VIDEO_ATMEL_ISI
+tristate ATMEL Image Sensor Interface (ISI) support
+depends on VIDEO_DEV SOC_CAMERA
Depends on AT91/AVR32?
I think I will use AT91
[snip]
+
+#include media/videobuf2-dma-contig.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+
+#define ATMEL_ISI_VERSION KERNEL_VERSION(1, 0, 0)
Do we really need this version?
Since we need set a version for v4l2_capability.version in function
isi_camera_querycap(). So we use this macro.
How about this?
static int isi_camera_querycap(struct soc_camera_host *ici,
struct v4l2_capability *cap)
{
strcpy(cap-driver, atmel-isi);
strcpy(cap-card, Atmel Image Sensor Interface);
cap-version = KERNEL_VERSION(1, 0, 0);
cap-capabilities = (V4L2_CAP_VIDEO_CAPTURE |
V4L2_CAP_STREAMING);
return 0;
}
+#define MAX_BUFFER_NUMS 32
+#define MAX_SUPPORT_WIDTH 2048
+#define MAX_SUPPORT_HEIGHT 2048
+
+static unsigned int vid_limit = 16;
This never gets changed so it can become a const/define. The value is
MB, which is not clear from the name, and it gets multiplied out to
bytes in its only usage, so maybe:
#define VID_LIMIT_BYTES (16 * 1024 * 1024)
Your code is good. I will change according to your suggestion.
+
+enum isi_buffer_state {
+ISI_BUF_NEEDS_INIT,
+ISI_BUF_PREPARED,
+};
Aren't there v4l2 constants for this already?
VIDEOBUF_NEEDS_INIT,
VIDEOBUF_PREPARED,
Just reuse those.
I checked the code, above constants are used in
[no subject]
This series of patches provides support for Aptina mt9p031 sensor on Beagleboard xM. It has been tested using media-ctl and yavta. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] mt9p031: Add mt9p031 sensor driver.
It has been tested in beagleboard xM, using LI-5M03 module.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/Kconfig |8 +
drivers/media/video/Makefile|1 +
drivers/media/video/mt9p031.c | 773 +++
include/media/mt9p031.h | 11 +
include/media/v4l2-chip-ident.h |1 +
5 files changed, 794 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mt9p031.c
create mode 100644 include/media/mt9p031.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 00f51dd..32df8bd 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -329,6 +329,14 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_MT9P031
+ tristate Micron MT9P031 support
+ depends on I2C VIDEO_V4L2
+ ---help---
+ This driver supports MT9P031 cameras from Micron
+ This is a Video4Linux2 sensor-level driver for the Micron
+ mt0p031 5 Mpixel camera.
+
config VIDEO_MT9V011
tristate Micron mt9v011 sensor support
depends on I2C VIDEO_V4L2
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ace5d8b..912b29b 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
+obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
new file mode 100644
index 000..850cfec
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
@@ -0,0 +1,773 @@
+/*
+ * Driver for MT9P031 CMOS Image Sensor from Aptina
+ *
+ * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * Based on the MT9V032 driver and Bastian Hecht's code.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/device.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include media/v4l2-subdev.h
+#include linux/videodev2.h
+
+#include media/mt9p031.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
+#include media/v4l2-device.h
+
+/* mt9p031 selected register addresses */
+#define MT9P031_CHIP_VERSION 0x00
+#defineMT9P031_CHIP_VERSION_VALUE 0x1801
+#define MT9P031_ROW_START 0x01
+#defineMT9P031_ROW_START_SKIP 54
+#define MT9P031_COLUMN_START 0x02
+#defineMT9P031_COLUMN_START_SKIP 16
+#define MT9P031_WINDOW_HEIGHT 0x03
+#define MT9P031_WINDOW_WIDTH 0x04
+#define MT9P031_H_BLANKING 0x05
+#defineMT9P031_H_BLANKING_VALUE0
+#define MT9P031_V_BLANKING 0x06
+#defineMT9P031_V_BLANKING_VALUE25
+#define MT9P031_OUTPUT_CONTROL 0x07
+#defineMT9P031_OUTPUT_CONTROL_CEN 2
+#defineMT9P031_OUTPUT_CONTROL_SYN 1
+#define MT9P031_SHUTTER_WIDTH_UPPER0x08
+#define MT9P031_SHUTTER_WIDTH 0x09
+#define MT9P031_PIXEL_CLOCK_CONTROL0x0a
+#define MT9P031_FRAME_RESTART 0x0b
+#define MT9P031_SHUTTER_DELAY 0x0c
+#define MT9P031_RESET 0x0d
+#defineMT9P031_RESET_ENABLE1
+#defineMT9P031_RESET_DISABLE 0
+#define MT9P031_READ_MODE_10x1e
+#define MT9P031_READ_MODE_20x20
+#defineMT9P031_READ_MODE_2_ROW_MIR 0x8000
+#defineMT9P031_READ_MODE_2_COL_MIR 0x4000
+#define MT9P031_ROW_ADDRESS_MODE 0x22
+#define MT9P031_COLUMN_ADDRESS_MODE0x23
+#define MT9P031_GLOBAL_GAIN0x35
+
+#define MT9P031_MAX_HEIGHT 1944
+#define MT9P031_MAX_WIDTH 2592
+#define MT9P031_MIN_HEIGHT 2
+#define MT9P031_MIN_WIDTH 18
+
+struct mt9p031 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_rect rect; /* Sensor window */
+ struct v4l2_mbus_framefmt format;
+ struct mt9p031_platform_data *pdata;
+ int model; /* V4L2_IDENT_MT9P031* codes from v4l2-chip-ident.h */
+
[PATCH 2/2] OMAP3BEAGLE: Add support for mt9p031 sensor (LI-5M03 module).
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 130 ++-
arch/arm/mach-omap2/devices.c |2 +-
2 files changed, 127 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..ccd72dc 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,15 +24,20 @@
#include linux/input.h
#include linux/gpio_keys.h
#include linux/opp.h
+#include linux/i2c.h
+#include linux/mm.h
+#include linux/videodev2.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
#include linux/mtd/nand.h
#include linux/mmc/host.h
-
+#include linux/gpio.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
+#include media/mt9p031.h
+
#include mach/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -47,12 +52,18 @@
#include plat/nand.h
#include plat/usb.h
#include plat/omap_device.h
+#include plat/i2c.h
#include mux.h
#include hsmmc.h
#include timer-gp.h
#include pm.h
+#include devices.h
+#include ../../../drivers/media/video/omap3isp/isp.h
+#include ../../../drivers/media/video/omap3isp/ispreg.h
+#define MT9P031_RESET_GPIO 98
+#define MT9P031_XCLK ISP_XCLK_A
#define NAND_BLOCK_SIZESZ_128K
/*
@@ -273,6 +284,44 @@ static struct regulator_consumer_supply beagle_vsim_supply
= {
static struct gpio_led gpio_leds[];
+static struct regulator_consumer_supply beagle_vaux3_supply = {
+ .supply = cam_1v8,
+};
+
+static struct regulator_consumer_supply beagle_vaux4_supply = {
+ .supply = cam_2v8,
+};
+
+/* VAUX3 for CAM_1V8 */
+static struct regulator_init_data beagle_vaux3 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux3_supply,
+};
+
+/* VAUX4 for CAM_2V8 */
+static struct regulator_init_data beagle_vaux4 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux4_supply,
+};
+
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -309,6 +358,15 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ /*
+* Power on camera interface - only on pre-production, not
+* needed on production boards
+*/
+ gpio_request(gpio + 2, CAM_EN);
+ gpio_direction_output(gpio + 2, 1);
+ }
+
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
* high / others active low)
@@ -451,6 +509,8 @@ static struct twl4030_platform_data beagle_twldata = {
.vsim = beagle_vsim,
.vdac = beagle_vdac,
.vpll2 = beagle_vpll2,
+ .vaux3 = beagle_vaux3,
+ .vaux4 = beagle_vaux4,
};
static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
@@ -463,15 +523,16 @@ static struct i2c_board_info __initdata
beagle_i2c_boardinfo[] = {
};
static struct i2c_board_info __initdata beagle_i2c_eeprom[] = {
- {
- I2C_BOARD_INFO(eeprom, 0x50),
- },
+ {
+ I2C_BOARD_INFO(eeprom, 0x50),
+ },
};
static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
ARRAY_SIZE(beagle_i2c_boardinfo));
+ omap_register_i2c_bus(2, 100, NULL, 0); /* Enable I2C2 for camera */
/* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, beagle_i2c_eeprom,
ARRAY_SIZE(beagle_i2c_eeprom));
@@ -654,6 +715,62 @@ static void __init beagle_opp_init(void)
return;
}
+extern struct platform_device omap3isp_device;
+
+static int beagle_cam_set_xclk(struct
Re: [GIT PATCHES FOR 2.6.40] gspca for_v2.6.40
On Tue, 17 May 2011 10:54:17 +0200 Jean-Francois Moine moin...@free.fr wrote: The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v2.6.40 [...] Hi Jean-Francois, sometimes it is useful to add also a why section to commit messages so others can follow your thoughts, and even learn from them. I have this very simple scheme: a summary of the what goes into the short commit message and the why and how go into the long commit message when they are not immediately trivial from the code; for instance the why of the USB trace changes in this series wasn't trivial to me. Thanks, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- 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/3] adp1653: Add driver for LED flash controller
Laurent Pinchart wrote: Hi Sakari, Hi Laurent, On Tuesday 17 May 2011 07:38:38 Sakari Ailus wrote: [clip] If several applications read controls, only one of them will be notified of faults. Shouldn't clearing the fault be handled explicitly by writing to a control ? I know this changes the API :-) This is true. Although I can't imagine right now why two separate processes should be so interested in the faults but it is still entirely possible that someone does that since it's permitted by the interface. Having to write zero to faults to clear them isn't good either since it might mean missing faults that are triggered between reading and writing this control. Perhaps this would make sense as a file handle specific control? Good question. Control events will help I guess, maybe that's the solution. They would help, yes, but in the case of N900 we don't have that luxury since there's no interrupt line from the adp1653 to OMAP. So if one user would read the control, the others would get notified. Yes, that would work, too. The use case is mostly theoretical and that's actually best the hardware can offer, so I think this is good. No special arrangements needed then. So reading the value will reset the faults? The control documentation says that the faults are cleared when the register is read, but the adp1653 also clears the faults whenever writing zero to out_sel which happens also in other circumstances, for example when changing mode from flash to torch when the torch intensity is zero, or when indicator intensity is zero in other modes. + /* Restore configuration. */ + rval = adp1653_update_hw(flash); + if (IS_ERR_VALUE(rval)) + return rval; Will that produce expected results ? For instance, if a fault was detected during flash strobe, won't it try to re-strobe the flash ? Shouldn't the user No. Flash is strobed using adp1653_strobe(). be required to explicitly re-strobe the flash or turn the torch (or indicator) on after a fault ? Once again this should be clarified in the API :-) The mode won't be changed from the flash but to strobe again, the user has to push V4L2_CID_FLASH_STROBE again. The adp1653 doesn't have any torch (as such) or indicator faults; some other chips do have indicator faults at least. Using the torch mode might trigger faults, too, since it's the same LED; just the power isn't that high. When an over-current fault is detected, shouldn't the mode be set back to none ? If we just clear the fault and reprogram the registers, the torch will be turned back on, and the fault will likely happen again. That's a good point. Over-temperature, over-voltage, and short circuit faults should change the LED mode to be set to none. This is likely chip independent behaviour but on the other hand, not all the chips implement all the faults. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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 3/3] adp1653: Add driver for LED flash controller
Hi Sakari, On Tuesday 17 May 2011 12:47:25 Sakari Ailus wrote: Laurent Pinchart wrote: On Tuesday 17 May 2011 07:38:38 Sakari Ailus wrote: [clip] If several applications read controls, only one of them will be notified of faults. Shouldn't clearing the fault be handled explicitly by writing to a control ? I know this changes the API :-) This is true. Although I can't imagine right now why two separate processes should be so interested in the faults but it is still entirely possible that someone does that since it's permitted by the interface. Having to write zero to faults to clear them isn't good either since it might mean missing faults that are triggered between reading and writing this control. Perhaps this would make sense as a file handle specific control? Good question. Control events will help I guess, maybe that's the solution. They would help, yes, but in the case of N900 we don't have that luxury since there's no interrupt line from the adp1653 to OMAP. So if one user would read the control, the others would get notified. Yes, that would work, too. The use case is mostly theoretical and that's actually best the hardware can offer, so I think this is good. No special arrangements needed then. So reading the value will reset the faults? OK, let's leave it that way, at least for now. The control documentation says that the faults are cleared when the register is read, but the adp1653 also clears the faults whenever writing zero to out_sel which happens also in other circumstances, for example when changing mode from flash to torch when the torch intensity is zero, or when indicator intensity is zero in other modes. +/* Restore configuration. */ +rval = adp1653_update_hw(flash); +if (IS_ERR_VALUE(rval)) +return rval; Will that produce expected results ? For instance, if a fault was detected during flash strobe, won't it try to re-strobe the flash ? Shouldn't the user No. Flash is strobed using adp1653_strobe(). be required to explicitly re-strobe the flash or turn the torch (or indicator) on after a fault ? Once again this should be clarified in the API :-) The mode won't be changed from the flash but to strobe again, the user has to push V4L2_CID_FLASH_STROBE again. The adp1653 doesn't have any torch (as such) or indicator faults; some other chips do have indicator faults at least. Using the torch mode might trigger faults, too, since it's the same LED; just the power isn't that high. When an over-current fault is detected, shouldn't the mode be set back to none ? If we just clear the fault and reprogram the registers, the torch will be turned back on, and the fault will likely happen again. That's a good point. Over-temperature, over-voltage, and short circuit faults should change the LED mode to be set to none. This is likely chip independent behaviour but on the other hand, not all the chips implement all the faults. If the chip doesn't implement faults handling there little we can do. For chips that do implement faults handling, let's switch the LED mode to none when a fault is detected. -- 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: [PATCH 1/2] mt9p031: Add mt9p031 sensor driver.
Hi Javier,
Thanks for the patch.
On Tuesday 17 May 2011 11:28:47 Javier Martin wrote:
It has been tested in beagleboard xM, using LI-5M03 module.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
[snip]
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
new file mode 100644
index 000..850cfec
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
@@ -0,0 +1,773 @@
+/*
+ * Driver for MT9P031 CMOS Image Sensor from Aptina
+ *
+ * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * Based on the MT9V032 driver and Bastian Hecht's code.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/device.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include media/v4l2-subdev.h
+#include linux/videodev2.h
+
+#include media/mt9p031.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
+#include media/v4l2-device.h
+
+/* mt9p031 selected register addresses */
+#define MT9P031_CHIP_VERSION 0x00
+#define MT9P031_CHIP_VERSION_VALUE 0x1801
+#define MT9P031_ROW_START0x01
+#define MT9P031_ROW_START_SKIP 54
+#define MT9P031_COLUMN_START 0x02
+#define MT9P031_COLUMN_START_SKIP 16
+#define MT9P031_WINDOW_HEIGHT0x03
+#define MT9P031_WINDOW_WIDTH 0x04
+#define MT9P031_H_BLANKING 0x05
+#define MT9P031_H_BLANKING_VALUE0
+#define MT9P031_V_BLANKING 0x06
+#define MT9P031_V_BLANKING_VALUE25
+#define MT9P031_OUTPUT_CONTROL 0x07
+#define MT9P031_OUTPUT_CONTROL_CEN 2
+#define MT9P031_OUTPUT_CONTROL_SYN 1
+#define MT9P031_SHUTTER_WIDTH_UPPER 0x08
+#define MT9P031_SHUTTER_WIDTH0x09
+#define MT9P031_PIXEL_CLOCK_CONTROL 0x0a
+#define MT9P031_FRAME_RESTART0x0b
+#define MT9P031_SHUTTER_DELAY0x0c
+#define MT9P031_RESET0x0d
+#define MT9P031_RESET_ENABLE1
+#define MT9P031_RESET_DISABLE 0
+#define MT9P031_READ_MODE_1 0x1e
+#define MT9P031_READ_MODE_2 0x20
+#define MT9P031_READ_MODE_2_ROW_MIR 0x8000
+#define MT9P031_READ_MODE_2_COL_MIR 0x4000
+#define MT9P031_ROW_ADDRESS_MODE 0x22
+#define MT9P031_COLUMN_ADDRESS_MODE 0x23
+#define MT9P031_GLOBAL_GAIN 0x35
+
+#define MT9P031_MAX_HEIGHT 1944
+#define MT9P031_MAX_WIDTH2592
+#define MT9P031_MIN_HEIGHT 2
+#define MT9P031_MIN_WIDTH18
+
+struct mt9p031 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_rect rect; /* Sensor window */
+ struct v4l2_mbus_framefmt format;
+ struct mt9p031_platform_data *pdata;
+ int model; /* V4L2_IDENT_MT9P031* codes from v4l2-chip-ident.h */
model is assigned by never read, you can remove it.
+ u16 xskip;
+ u16 yskip;
+ struct regulator *reg_1v8, *reg_2v8;
Please split this on two lines.
You never enable the 1.8V regulator, is that intentional ?
+};
[snip]
+static int reg_set(struct i2c_client *client, const u8 reg,
+const u16 data)
+{
+ int ret;
+
+ ret = reg_read(client, reg);
+ if (ret 0)
+ return ret;
+ return reg_write(client, reg, ret | data);
+}
+
+static int reg_clear(struct i2c_client *client, const u8 reg,
+ const u16 data)
+{
+ int ret;
+
+ ret = reg_read(client, reg);
+ if (ret 0)
+ return ret;
+ return reg_write(client, reg, ret ~data);
+}
I still think you should use a shadow copy of the register in the mt9p031
structure instead of reading the value back from the hardware. As these two
functions are only used to handle the output control register, you could
create an mt9p031_set_output_control(struct mt9p031 *mt9p031, u16 clear, u16
set) function instead.
+static int mt9p031_idle(struct i2c_client *client)
This function resets the chip, what about calling it mt9p031_reset() instead ?
+{
+ int ret;
+
+ /* Disable chip output, synchronous option update */
+ ret = reg_write(client, MT9P031_RESET, MT9P031_RESET_ENABLE);
+ if (ret 0)
+ goto err;
You can return -EIO directly.
+ ret = reg_write(client, MT9P031_RESET,
Re: [PATCH 1/2] mt9p031: Add mt9p031 sensor driver.
Hi Laurent Thanks for your review! Javier, if you like, you can wait a couple of days until I find some time to review the driver, or you can submit a version, addressing Laurent's points, but be prepared to have to do another one;) 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 1/2] mt9p031: Add mt9p031 sensor driver.
On 17 May 2011 13:47, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Laurent Thanks for your review! Javier, if you like, you can wait a couple of days until I find some time to review the driver, or you can submit a version, addressing Laurent's points, but be prepared to have to do another one;) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ OK, I think I'll wait to have Guennadi's review too. Thank you both. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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: Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Em 15-05-2011 18:10, Hans Verkuil escreveu:
On Saturday, May 14, 2011 13:46:03 Mauro Carvalho Chehab wrote:
Em 14-05-2011 13:02, Hans Verkuil escreveu:
On Saturday, May 14, 2011 12:19:18 Mauro Carvalho Chehab wrote:
So, based at all I've seen, I'm pretty much convinced that the normal MMAP
way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's)
are not the best way to share data with framebuffers.
I agree with that, but it is a different story between two V4L2 devices.
There
you obviously want to use the streaming ioctls and still share buffers.
I don't think so. the requirement for syncing the framebuffer between the two
V4L2 devices is pretty much the same as we have with one V4L2 device and one
GPU.
On both cases, the requirement is to pass a framebuffer between two
entities,
and not a video stream.
For example, imagine something like:
V4L2 camera = V4L2 encoder t MPEG2
||
LL== GPU
For the sake of clarity on my next comments, I'm naming the V4L2 camera buffer
write endpoint as producer and the 2 buffer read endpoints as consumers.
Both GPU and the V4L2 encoder should use the same logic to be sure that they
will
use a buffer that were filled already by the camera. Also, the V4L2 camera
driver can't re-use such framebuffer before being sure that both consumers
has already stopped using it.
No. A camera whose output is sent to a resizer and then to a SW/FW/HW encoder
is a typical example where you want to queue/dequeue buffers.
Why? On a framebuffer-oriented set of ioctl's, some kernel internal calls will
need to take care of the buffer usage, in order to be sure when a buffer can
be rewritten, as userspace has no way to know when a buffer needs to be
queued/dequeued.
In other words, the framebuffer kernel API will probably be using a kernel
structure like:
struct v4l2_fb_handler {
bool has_finished; /* Marks when a handler
finishes to handle the buffer */
bool is_producer; /* Used by the handler
that writes data into the buffer */
struct list_head *handlers; /* List with all
handlers */
void (*qbuf)(struct v4l2_fb_handler *handler); /* qbuf-like callback,
called after having a buffer filled */
v4l2_buffer_ID buf;/* Buffer ID (or
filehandler?) - In practice, it will probably be a list with the available
buffers */
void *priv; /* handler priv data */
}
While stream is on, a kernel logic will run a loop, doing basically the steps
bellow:
1) Wait for the producer to rise the has_finished flag;
2) call qbuf() for all consumers. The qbuf() call shouldn't block; it
just calls
a per-handler logic to start using that buffer;
3) When each fb handler finishes using its buffer, it will rise
has_finished flag;
4) After having all buffer handlers marked as has_finished, cleans the
has_finished
flags and re-queue the buffer.
Step (2) is equivalent to VIDIOC_QBUF, and step (4) is equivalent to
VIDIOC_DQBUF.
PS.: The above is just a simplified view of such handler. We'll probably need
more steps. For
example, between (1) and (2) it may probably need some logic to check if is
there an available
empty buffer. If not, create a new one and use it.
What happens with REQBUF/QBUF/DQBUF is that:
- with those calls, there's just one buffer consumer, and just one
buffer producer;
- either the producer or the consumer is on userspace, and the other
pair is
at kernelspace;
- buffers are allocated before the start of a process, via an explicit
call;
- buffers need to be mmapped, in order to be visible at userspace.
None of the above applies to a framebuffer-oriented API:
- more than one buffer consumer is allowed;
- consumers and producers are on kernelspace (it might be needed to
have an
an API for handling such buffers also on userspace, although it doesn't sound a
good
idea to me, IMHO);
- buffers can be dynamically allocated/de-allocated;
- buffers don't need to be mmapped to userspace.
Especially since
the various parts of the pipeline may stall for a bit so you don't want to
lose
frames. That's not what the overlay API is for, that's what our streaming API
gives us.
The use case above isn't even possible without copying. At least, I don't see
a
way, unless the GPU buffer is non-destructive. In that case you can give the
frame to the GPU, and when the GPU is finished you can give it to the encoder.
I suspect that might become quite complex though.
Well, if some fb consumers would also be rewriting the buffers, serializing
them is
needed, as you can't allow another process to access a memory that CPU is
destroying
at the same time, as you'll have unpredicted
Re: Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Em 17-05-2011 09:49, Mauro Carvalho Chehab escreveu:
Em 15-05-2011 18:10, Hans Verkuil escreveu:
On Saturday, May 14, 2011 13:46:03 Mauro Carvalho Chehab wrote:
Em 14-05-2011 13:02, Hans Verkuil escreveu:
On Saturday, May 14, 2011 12:19:18 Mauro Carvalho Chehab wrote:
So, based at all I've seen, I'm pretty much convinced that the normal MMAP
way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's)
are not the best way to share data with framebuffers.
I agree with that, but it is a different story between two V4L2 devices.
There
you obviously want to use the streaming ioctls and still share buffers.
I don't think so. the requirement for syncing the framebuffer between the
two
V4L2 devices is pretty much the same as we have with one V4L2 device and
one GPU.
On both cases, the requirement is to pass a framebuffer between two
entities,
and not a video stream.
For example, imagine something like:
V4L2 camera = V4L2 encoder t MPEG2
||
LL== GPU
For the sake of clarity on my next comments, I'm naming the V4L2 camera
buffer
write endpoint as producer and the 2 buffer read endpoints as consumers.
Both GPU and the V4L2 encoder should use the same logic to be sure that
they will
use a buffer that were filled already by the camera. Also, the V4L2 camera
driver can't re-use such framebuffer before being sure that both consumers
has already stopped using it.
No. A camera whose output is sent to a resizer and then to a SW/FW/HW encoder
is a typical example where you want to queue/dequeue buffers.
Why? On a framebuffer-oriented set of ioctl's, some kernel internal calls will
need to take care of the buffer usage, in order to be sure when a buffer can
be rewritten, as userspace has no way to know when a buffer needs to be
queued/dequeued.
In other words, the framebuffer kernel API will probably be using a kernel
structure like:
struct v4l2_fb_handler {
bool has_finished; /* Marks when a handler
finishes to handle the buffer */
bool is_producer; /* Used by the handler
that writes data into the buffer */
struct list_head *handlers; /* List with all
handlers */
void (*qbuf)(struct v4l2_fb_handler *handler); /* qbuf-like callback,
called after having a buffer filled */
v4l2_buffer_ID buf;/* Buffer ID (or
filehandler?) - In practice, it will probably be a list with the available
buffers */
void *priv; /* handler priv data */
}
While stream is on, a kernel logic will run a loop, doing basically the steps
bellow:
1) Wait for the producer to rise the has_finished flag;
2) call qbuf() for all consumers. The qbuf() call shouldn't block; it
just calls
a per-handler logic to start using that buffer;
3) When each fb handler finishes using its buffer, it will rise
has_finished flag;
4) After having all buffer handlers marked as has_finished, cleans the
has_finished
flags and re-queue the buffer.
Step (2) is equivalent to VIDIOC_QBUF, and step (4) is equivalent to
VIDIOC_DQBUF.
PS.: The above is just a simplified view of such handler. We'll probably need
more steps. For
example, between (1) and (2) it may probably need some logic to check if is
there an available
empty buffer. If not, create a new one and use it.
What happens with REQBUF/QBUF/DQBUF is that:
- with those calls, there's just one buffer consumer, and just one
buffer producer;
- either the producer or the consumer is on userspace, and the other
pair is
at kernelspace;
- buffers are allocated before the start of a process, via an explicit
call;
- buffers need to be mmapped, in order to be visible at userspace.
None of the above applies to a framebuffer-oriented API:
- more than one buffer consumer is allowed;
- consumers and producers are on kernelspace (it might be needed to
have an
an API for handling such buffers also on userspace, although it doesn't sound
a good
idea to me, IMHO);
A side note: in the specific case of X server and display drivers, such
kernelspace-userspace
API for buffers already exists. I don't know DRI/GEM/KMS enough to tell
exactly how this work
or if it will require some changes or not, in order to work like the above, but
it seems that
the right approach is to try to use or extend the existing API's, instead of
creating
something new.
The main point is: DQBUF/QBUF API assumes that userspace has full control at
the buffer usage,
and buffer is handled at userspace (so, they should be mmapped there). This is
not the general
case where another IP block at the chip is re-using the buffer, or if is there
another DMA engine
doing direct transfers on it.
- buffers
Re: imon: spews to dmesg
I think I have found the source of this. linux/drivers/media/video/omap3isp/Makefile contains this: ifdef CONFIG_VIDEO_OMAP3_DEBUG EXTRA_CFLAGS += -DDEBUG endif but this module is not turned on,nor is the _DEBUG setting for it. % grep OMAP3 media_build/v4l/.config # CONFIG_VIDEO_OMAP3_DEBUG is not set # CONFIG_VIDEO_OMAP3 is not set % grep OMAP3 media_build/v4l/.myconfig CONFIG_VIDEO_OMAP3_DEBUG := n CONFIG_VIDEO_OMAP3 := n nonetheless: % grep DDEBUG media_build/v4l/.imon.o.cmd ... -fconserve-stack -Idrivers/media/dvb/dvb-core -Idrivers/media/dvb/dvb-usb -Idrivers/media/dvb/frontends -Idrivers/media/dvb/dvb-core -Idrivers/media/video -Idrivers/media/common/tuners -Idrivers/media/dvb/dvb-core -Idrivers/media/dvb/frontends -Idrivers/media/video -Idrivers/media/common/tuners -Idrivers/media/dvb/dvb-core -Idrivers/media/dvb/frontends -DDEBUG -Isound -Idrivers/staging/cxd2099/ -g ... Commenting out the three lines above in the omap3isp/Makefile gets rid of the -DDEBUG in the .cmd files. It seems to be the only Makefile that sets -DDEBUG in this way. Not sure what the real remedy is here. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 0/3] V4L2 API for flash devices and the adp1653 flash controller driver
Hi, This patchset implements RFC v4 of V4L2 API for flash devices [1], with minor modifications, and adds the adp1653 flash controller driver. There have been changes since v1 [2] of this patchset: - Faults on the flash LED are allowed to make the LED unusable before the faults are read. This is implemented in the adp1653 driver. - Intensities are using standard units; mA for flash / torch and uA for the indicator. Thanks to those who have given their feedback so far in the process! [1] http://www.spinics.net/lists/linux-media/msg32030.html [2] http://www.spinics.net/lists/linux-media/msg32396.html Cheers, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
[RFC v2 1/3] v4l: Add a class and a set of controls for flash devices.
From: Sakari Ailus sakari.ai...@iki.fi
Add a control class and a set of controls to support LED and Xenon flash
devices. An example of such a device is the adp1653.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/v4l2-ctrls.c | 45 ++
include/linux/videodev2.h| 36 ++
2 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..74aae36 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -216,6 +216,17 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
75 useconds,
NULL,
};
+ static const char * const flash_led_mode[] = {
+ Off,
+ Flash,
+ Torch,
+ NULL,
+ };
+ static const char * const flash_strobe_source[] = {
+ Software,
+ External,
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -256,6 +267,10 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
return tune_preemphasis;
+ case V4L2_CID_FLASH_LED_MODE:
+ return flash_led_mode;
+ case V4L2_CID_FLASH_STROBE_SOURCE:
+ return flash_strobe_source;
default:
return NULL;
}
@@ -389,6 +404,21 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_TUNE_POWER_LEVEL: return Tune Power Level;
case V4L2_CID_TUNE_ANTENNA_CAPACITOR: return Tune Antenna Capacitor;
+ /* Flash controls */
+ case V4L2_CID_FLASH_CLASS: return Flash controls;
+ case V4L2_CID_FLASH_LED_MODE: return LED mode;
+ case V4L2_CID_FLASH_STROBE_SOURCE: return Strobe source;
+ case V4L2_CID_FLASH_STROBE: return Strobe;
+ case V4L2_CID_FLASH_STROBE_STOP:return Stop strobe;
+ case V4L2_CID_FLASH_STROBE_STATUS: return Strobe status;
+ case V4L2_CID_FLASH_TIMEOUT:return Strobe timeout;
+ case V4L2_CID_FLASH_INTENSITY: return Intensity, flash mode;
+ case V4L2_CID_FLASH_TORCH_INTENSITY:return Intensity, torch mode;
+ case V4L2_CID_FLASH_INDICATOR_INTENSITY: return Intensity, indicator;
+ case V4L2_CID_FLASH_FAULT: return Faults;
+ case V4L2_CID_FLASH_CHARGE: return Charge;
+ case V4L2_CID_FLASH_READY: return Ready to strobe;
+
default:
return NULL;
}
@@ -423,12 +453,17 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_PILOT_TONE_ENABLED:
case V4L2_CID_ILLUMINATORS_1:
case V4L2_CID_ILLUMINATORS_2:
+ case V4L2_CID_FLASH_STROBE_STATUS:
+ case V4L2_CID_FLASH_CHARGE:
+ case V4L2_CID_FLASH_READY:
*type = V4L2_CTRL_TYPE_BOOLEAN;
*min = 0;
*max = *step = 1;
break;
case V4L2_CID_PAN_RESET:
case V4L2_CID_TILT_RESET:
+ case V4L2_CID_FLASH_STROBE:
+ case V4L2_CID_FLASH_STROBE_STOP:
*type = V4L2_CTRL_TYPE_BUTTON;
*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
*min = *max = *step = *def = 0;
@@ -452,6 +487,8 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_EXPOSURE_AUTO:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
+ case V4L2_CID_FLASH_LED_MODE:
+ case V4L2_CID_FLASH_STROBE_SOURCE:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_RDS_TX_PS_NAME:
@@ -462,6 +499,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_CAMERA_CLASS:
case V4L2_CID_MPEG_CLASS:
case V4L2_CID_FM_TX_CLASS:
+ case V4L2_CID_FLASH_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
/* You can neither read not write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
@@ -474,6 +512,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
/* Max is calculated as RGB888 that is 2^24 */
*max = 0xFF;
break;
+ case V4L2_CID_FLASH_FAULT:
+ *type = V4L2_CTRL_TYPE_BITMASK;
+ break;
default:
*type = V4L2_CTRL_TYPE_INTEGER;
break;
@@ -519,6 +560,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_ZOOM_RELATIVE:
*flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
break;
+ case V4L2_CID_FLASH_STROBE_STATUS:
+ case
[RFC v2 2/3] v4l: Add flash control documentation
Add documentation for V4L2 flash controls. Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com --- Documentation/DocBook/v4l/controls.xml | 221 ++ Documentation/DocBook/v4l/vidioc-g-ext-ctrls.xml |7 + 2 files changed, 228 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index a920ee8..a4e4542 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -2092,6 +2092,227 @@ manually or automatically if set to zero. Unit, range and step are driver-specif paraFor more details about RDS specification, refer to xref linkend=en50067 / document, from CENELEC./para /section + +section id=flash-controls + titleFlash Control Reference/title + + para + The V4L2 flash controls are intended to provide generic access + to flash controller devices. Flash controller devices are + typically used in digital cameras. + /para + + para + The interface can support both LED and xenon flash devices. + /para + + table pgwide=1 frame=none id=flash-control-id + titleFlash Control IDs/title + + tgroup cols=4 + colspec colname=c1 colwidth=1* / + colspec colname=c2 colwidth=6* / + colspec colname=c3 colwidth=2* / + colspec colname=c4 colwidth=6* / + spanspec namest=c1 nameend=c2 spanname=id / + spanspec namest=c2 nameend=c4 spanname=descr / + thead + row + entry spanname=id align=leftID/entry + entry align=leftType/entry + /rowrow rowsep=1entry spanname=descr align=leftDescription/entry + /row + /thead + tbody valign=top + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_FLASH_CLASS/constant/entry + entryclass/entry + /row + row + entry spanname=descrThe FLASH class descriptor./entry + /row + row + entry spanname=idconstantV4L2_CID_FLASH_LED_MODE/constant/entry + entrymenu/entry + /row + row + entry spanname=descrDefines the mode of the flash LED, + the high-power white LED attached to the flash + controller./entry + /row + row + entrytbl spanname=descr cols=2 + tbody valign=top + row + entryconstantV4L2_FLASH_LED_MODE_NONE/constant/entry + entryOff./entry + /row + row + entryconstantV4L2_FLASH_LED_MODE_FLASH/constant/entry + entryFlash mode./entry + /row + row + entryconstantV4L2_FLASH_LED_MODE_TORCH/constant/entry + entryTorch mode. See V4L2_CID_FLASH_TORCH_INTENSITY./entry + /row + /tbody + /entrytbl + /row + row + entry spanname=idconstantV4L2_CID_FLASH_STROBE_SOURCE/constant/entry + entrymenu/entry + /row + rowentry spanname=descrDefines the mode of the + flash LED strobe./entry + /row + row + entrytbl spanname=descr cols=2 + tbody valign=top + row + entryconstantV4L2_FLASH_STROBE_SOURCE_SOFTWARE/constant/entry + entryThe flash strobe is triggered by using + the V4L2_CID_FLASH_STROBE control./entry + /row + row + entryconstantV4L2_FLASH_STROBE_SOURCE_EXTERNAL/constant/entry + entryThe flash strobe is triggered by an + external source. Typically this is a sensor, + which makes it possible to synchronises the + flash strobe start to exposure start./entry + /row + /tbody + /entrytbl + /row + row + entry spanname=idconstantV4L2_CID_FLASH_STROBE/constant/entry + entrybutton/entry + /row + row + entry spanname=descrStrobe flash. Valid when + V4L2_CID_FLASH_LED_MODE is set to + V4L2_FLASH_LED_MODE_FLASH and V4L2_CID_FLASH_STROBE_SOURCE + is set to V4L2_FLASH_STROBE_SOURCE_SOFTWARE./entry + /row + row + entry spanname=idconstantV4L2_CID_FLASH_STROBE_STOP/constant/entry + entrybutton/entry + /row + rowentry spanname=descrStop flash strobe immediately./entry + /row + row + entry spanname=idconstantV4L2_CID_FLASH_STROBE_STATUS/constant/entry + entryboolean/entry + /row + row + entry spanname=descrStrobe status: whether the flash + is strobing at the moment or not. This is a read-only + control./entry + /row + row + entry
[RFC v2 3/3] adp1653: Add driver for LED flash controller
This patch adds the driver for the adp1653 LED flash controller. This
controller supports a high power led in flash and torch modes and an
indicator light, sometimes also called privacy light.
The adp1653 is used on the Nokia N900.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
Signed-off-by: Tuukka Toivonen tuukka...@gmail.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: David Cohen daco...@gmail.com
---
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile |2 +
drivers/media/video/adp1653.c | 485 +
include/media/adp1653.h | 126 +++
4 files changed, 620 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/adp1653.c
create mode 100644 include/media/adp1653.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 00f51dd..c004dbb 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -344,6 +344,13 @@ config VIDEO_TCM825X
This is a driver for the Toshiba TCM825x VGA camera sensor.
It is used for example in Nokia N800.
+config VIDEO_ADP1653
+ tristate ADP1653 flash support
+ depends on I2C VIDEO_V4L2 MEDIA_CONTROLLER
+ ---help---
+ This is a driver for the ADP1653 flash controller. It is used for
+ example in Nokia N900.
+
config VIDEO_SAA7110
tristate Philips SAA7110 video decoder
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ace5d8b..abdf021 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -131,6 +131,8 @@ obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
obj-$(CONFIG_VIDEO_OMAP3) += omap3isp/
+obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o
+
obj-$(CONFIG_USB_ZR364XX) += zr364xx.o
obj-$(CONFIG_USB_STKWEBCAM) += stkwebcam.o
diff --git a/drivers/media/video/adp1653.c b/drivers/media/video/adp1653.c
new file mode 100644
index 000..1679707
--- /dev/null
+++ b/drivers/media/video/adp1653.c
@@ -0,0 +1,485 @@
+/*
+ * drivers/media/video/adp1653.c
+ *
+ * Copyright (C) 2008--2011 Nokia Corporation
+ *
+ * Contact: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
+ *
+ * Contributors:
+ * Sakari Ailus sakari.ai...@maxwell.research.nokia.com
+ * Tuukka Toivonen tuukka...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ * TODO:
+ * - fault interrupt handling
+ * - faster strobe (use i/o pin instead of i2c)
+ * - should ensure that the pin is in some sane state even if not used
+ * - power doesn't need to be ON if all lights are off
+ *
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/slab.h
+#include linux/version.h
+#include media/adp1653.h
+#include media/v4l2-device.h
+
+#define TIMEOUT_MAX82
+#define TIMEOUT_STEP 54600
+#define TIMEOUT_MIN(TIMEOUT_MAX - ADP1653_REG_CONFIG_TMR_SET_MAX \
+* TIMEOUT_STEP)
+#define TIMEOUT_US_TO_CODE(t) ((TIMEOUT_MAX + (TIMEOUT_STEP / 2) - (t)) \
+/ TIMEOUT_STEP)
+#define TIMEOUT_CODE_TO_US(c) (TIMEOUT_MAX - (c) * TIMEOUT_STEP)
+
+static int adp1653_get_fault(struct adp1653_flash *flash)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(flash-subdev);
+ int fault;
+ int rval;
+
+ fault = i2c_smbus_read_byte_data(client, ADP1653_REG_FAULT);
+ if (IS_ERR_VALUE(fault))
+ return fault;
+
+ flash-fault |= fault;
+
+ if (!flash-fault)
+ return 0;
+
+ /* Clear faults. */
+ rval = i2c_smbus_write_byte_data(client, ADP1653_REG_OUT_SEL, 0);
+ if (IS_ERR_VALUE(rval))
+ return rval;
+
+ flash-led_mode-val = V4L2_FLASH_LED_MODE_NONE;
+
+ return flash-fault;
+}
+
+/* Write values into ADP1653 registers. */
+static int adp1653_update_hw(struct adp1653_flash *flash)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(flash-subdev);
+ u8 out_sel;
+ u8 config = 0;
+ int rval;
+
+ out_sel = ADP1653_INDICATOR_INTENSITY_uA_TO_REG(
+ flash-indicator_intensity-val)
+ADP1653_REG_OUT_SEL_ILED_SHIFT;
+
+ switch (flash-led_mode-val) {
+ case V4L2_FLASH_LED_MODE_NONE:
+
Re: [libdvben50221] [PATCH] Assign same resource_id in open_session_response when resource non-existent
On 18/01/2011 15:42, Tomer Barletz wrote: Attached a patch for a bug in the lookup_callback function, were in case of a non-existent resource, the connected_resource_id is not initialized and then used in the open_session_response call of the session layer. Hello Can you explain what kind of bug it fixes ? Thanks -- 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
Codec controls question
Hi, Some time ago we were discussing the set of controls that should be implemented for codec support. I remember that the result of this discussion was that the controls should be as integrated as possible. This included the V4L2_CID_MPEG_LEVEL and all controls related to the quantization parameter. The problem with such approach is that the levels are different for MPEG4, H264 and H263. Same for quantization parameter - it ranges from 1 to 31 for MPEG4/H263 and from 0 to 51 for H264. Having single controls for the more than one codec seemed as a good solution. Unfortunately I don't see a good option to implement it, especially with the control framework. My idea was to have the min/max values for QP set in the S_FMT call on the CAPTURE. For MPEG_LEVEL it would be checked in the S_CTRL callback and if it did not fit the chosen format it failed. So I see three solutions to this problem and I wanted to ask about your opinion. 1) Have a separate controls whenever the range or valid value range differs. This is the simplest and in my opinion the best solution I can think of. This way we'll have different set of controls if the valid values are different (e.g. V4L2_CID_MPEG_MPEG4_LEVEL, V4L2_CID_MPEG_H264_LEVEL). User can set the controls at any time. The only con of this approach is having more controls. 2) Permit the user to set the control only after running S_FMT on the CAPTURE. This approach would enable us to keep less controls, but would require to set the min/max values for controls in the S_FMT. This could be done by adding controls in S_FMT or by manipulating their range and disabling unused controls. In case of MPEG_LEVEL it would require s_ctrl callback to check whether the requested level is valid for the chosen codec. This would be somehow against the spec, but if we allow the codec interface to have some differences this would be ok. 3) Let the user set the controls whenever and check them during the STREAMON call. The controls could be set anytime, and the control range supplied to the control framework would cover values possible for all supported codecs. This approach is more difficult than first approach. It is worse in case of user space than the second approach - the user is unaware of any mistakes until the STREAMON call. The argument for this approach is the possibility to have a few controls less. So I would like to hear a comment about the above propositions. Personally I would opt for the first solution. Best regards, -- Kamil Debski 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
Re: Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Em 16-05-2011 17:45, Guennadi Liakhovetski escreveu: On Sat, 14 May 2011, Mauro Carvalho Chehab wrote: Em 18-04-2011 17:15, Jesse Barker escreveu: One of the big issues we've been faced with at Linaro is around GPU and multimedia device integration, in particular the memory management requirements for supporting them on ARM. This next cycle, we'll be focusing on driving consensus around a unified memory management solution for embedded systems that support multiple architectures and SoCs. This is listed as part of our working set of requirements for the next six-month cycle (in spite of the URL, this is not being treated as a graphics-specific topic - we also have participation from multimedia and kernel working group folks): https://wiki.linaro.org/Cycles//TechnicalTopics/Graphics As part of the memory management needs, Linaro organized several discussions during Linaro Development Summit (LDS), at Budapest, and invited me and other members of the V4L and DRI community to discuss about the requirements. I wish to thank Linaro for its initiative. [snip] Btw, the need of managing buffers is currently being covered by the proposal for new ioctl()s to support multi-sized video-buffers [1]. [1] http://www.spinics.net/lists/linux-media/msg30869.html It makes sense to me to discuss such proposal together with the above discussions, in order to keep the API consistent. The author of that RFC would have been thankful, if he had been put on Cc: ;) If I had added everybody interested on this summary, probably most smtp servers would refuse to deliver the message thinking that it is a SPAM ;) My intention were to submit a feedback about it when analysing your rfc patches, if you weren't able to see it before. But anyway, yes, consistency is good, but is my understanding correct, that functionally these two extensions - multi-size and buffer-forwarding/reuse are independent? Yes. We have to think about making the APIs consistent, e.g., by reusing data structures. But it's also good to make incremental smaller changes where possible, isn't it? So, yes, we should think about consistency, but develop and apply those two extensions separately? True, but one discussion can benefit the other. IMO, we should not rush new userspace API merges, to avoid merging a code that weren't reasonably discussed, as otherwise, the API will become too messy. 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
[PATCH] cx231xx: Add support for Iconbit U100
From: Igor Novgorodov i...@novg.net
This patch adds support for the Iconbit Analog Stick U100 FM.
Only composite s-video inputs, no tuner support now.
Signed-off-by: Igor Novgorodov i...@novg.net
---
--- linux-2.6.38.6.orig/drivers/media/video/cx231xx/cx231xx-cards.c
2011-05-10 02:16:23.0 +0400
+++ linux-2.6.38.6/drivers/media/video/cx231xx/cx231xx-cards.c
2011-05-17 12:03:11.410810992 +0400
@@ -435,7 +435,33 @@ struct cx231xx_board cx231xx_boards[] =
.gpio = 0,
} },
},
+
+ [CX231XX_BOARD_ICONBIT_U100] = {
+ .name = Iconbit Analog Stick U100 FM,
+ .tuner_type = TUNER_ABSENT,
+ .decoder = CX231XX_AVDECODER,
+ .output_mode = OUT_MODE_VIP11,
+ .demod_xfer_mode = 0,
+ .ctl_pin_status_mask = 0xFFC4,
+ .agc_analog_digital_select_gpio = 0x1C,
+ .gpio_pin_status_mask = 0x4001000,
+
+ .input = {{
+ .type = CX231XX_VMUX_COMPOSITE1,
+ .vmux = CX231XX_VIN_2_1,
+ .amux = CX231XX_AMUX_LINE_IN,
+ .gpio = NULL,
+ }, {
+ .type = CX231XX_VMUX_SVIDEO,
+ .vmux = CX231XX_VIN_1_1 |
+ (CX231XX_VIN_1_2 8) |
+ CX25840_SVIDEO_ON,
+ .amux = CX231XX_AMUX_LINE_IN,
+ .gpio = NULL,
+ } },
+ },
};
+
const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
/* table of devices that work with this driver */
@@ -464,6 +490,8 @@ struct usb_device_id cx231xx_id_table[]
.driver_info = CX231XX_BOARD_HAUPPAUGE_USBLIVE2},
{USB_DEVICE_VER(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD, 0x4000,
0x4001),
.driver_info = CX231XX_BOARD_PV_PLAYTV_USB_HYBRID},
+ {USB_DEVICE(0x1f4d, 0x0237),
+.driver_info = CX231XX_BOARD_ICONBIT_U100},
{},
};
--- linux-2.6.38.6.orig/drivers/media/video/cx231xx/cx231xx.h 2011-05-10
02:16:23.0 +0400
+++ linux-2.6.38.6/drivers/media/video/cx231xx/cx231xx.h2011-05-17
09:52:58.067471709 +0400
@@ -64,6 +64,7 @@
#define CX231XX_BOARD_HAUPPAUGE_EXETER 8
#define CX231XX_BOARD_HAUPPAUGE_USBLIVE2 9
#define CX231XX_BOARD_PV_PLAYTV_USB_HYBRID 10
+#define CX231XX_BOARD_ICONBIT_U100 11
/* Limits minimum and default number of buffers */
#define CX231XX_MIN_BUF 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
[GIT PATCHES FOR 2.6.40] v4l2 subdev driver for Samsung S5P MIPI CSI receiver
Hi Mauro, The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung s5p-csis It's a new driver for MIPI CSI receiver available in S5PVxxx/EXYNOS4 SoCs. The first patch adds a definition of media bus code for JPEG format. Gitweb: http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/s5p-csis Sylwester Nawrocki (3): v4l: Add V4L2_MBUS_FMT_JPEG_1X8 media bus format v4l: Move s5p-fimc driver into Video capture devices v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers Documentation/DocBook/v4l/subdev-formats.xml | 46 ++ drivers/media/video/Kconfig | 28 +- drivers/media/video/Makefile |1 + drivers/media/video/s5p-fimc/Makefile|6 +- drivers/media/video/s5p-fimc/mipi-csis.c | 724 ++ drivers/media/video/s5p-fimc/mipi-csis.h | 22 + include/linux/v4l2-mediabus.h|3 + 7 files changed, 820 insertions(+), 10 deletions(-) create mode 100644 drivers/media/video/s5p-fimc/mipi-csis.c create mode 100644 drivers/media/video/s5p-fimc/mipi-csis.h Regards, -- Sylwester Nawrocki 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
Re: [PATCH 1/2] mt9p031: Add mt9p031 sensor driver.
Javier, I have been using the aptina patch (https://github.com/Aptina/BeagleBoard-xM) on beagleboard while waiting linux-media solve this mt9p031 issue. Now that you have something working, I would like to try it - but I would like to know what is the clock rate you actually drove the sensor. Reviewing your path, I suppose it is 54MHz, so you would be achieving some 10 full 5MPix frames/s from the sensor. Is that correct? (the aptina patch delivers less than 4 fps). Regards, Ivan On Tuesday, May 17, 2011 08:59:04 javier Martin wrote: On 17 May 2011 13:47, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Laurent Thanks for your review! Javier, if you like, you can wait a couple of days until I find some time to review the driver, or you can submit a version, addressing Laurent's points, but be prepared to have to do another one;) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ OK, I think I'll wait to have Guennadi's review too. Thank you both. -- 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] drm: add overlays as first class KMS objects
Hi Daniel, On Friday 13 May 2011 18:16:30 Daniel Vetter wrote: Hi Jesse, Discussion here in Budapest with v4l and embedded graphics folks was extremely fruitful. A few quick things to take away - I'll try to dig through all the stuff I've learned more in-depth later (probably in a blog post or two): - embedded graphics is insane. The output routing/blending/whatever currently shipping hw can do is crazy and kms as-is is nowhere near up to snuff to support this. We've discussed omap4 and a ti chip targeted at video surveillance as use cases. I'll post block diagrams and explanations some when later. - we should immediately stop to call anything an overlay. It's a confusing concept that has a different meaning in every subsystem and for every hw manufacturer. More sensible names are dma fifo engines for things that slurp in planes and make them available to the display subsystem. Blend engines for blocks that take multiple input pipes and overlay/underlay/blend them together. Display subsytem/controller for the aggregate thing including encoders/resizers/outputs and especially the crazy routing network that connects everything. Most of the discussion centered around clearing up the confusion and reaching a mutual understanding between desktop graphics, embedded graphics and v4l people. Two rough ideas emerged though: 1) Splitting the crtc object into two objects: crtc with associated output mode (pixel clock, encoders/connectors) and dma engines (possibly multiple) that feed it. omap 4 has essentially just 4 dma engines that can be freely assigned to the available outputs, so a distinction between normal crtcs and overlay engines just does not make sense. There's the major open question of where to put the various attributes to set up the output pipeline. Also some of these attributes might need to be changed atomicly together with pageflips on a bunch of dma engines all associated with the same crtc on the next vsync, e.g. output position of an overlaid video buffer. I like that idea. Setting attributes atomically will likely be one of the biggest challenge. V4L2 shares the same need, but we haven't had time to address it yet. 2) The above should be good enough to support halfway sane chips like omap4. But hw with more insane routing capabilities that can also use v4l devices as sources (even video input connectors) media controller might be a good fit. Media controller is designed to expose multimedia pipe routing across different subsystem. But the first version, still marked experimental, only got merged in .39. We discussed a few ideas as how to splice media controller into kms but nothing clear emerged. So a possible kms integration with media controller is rather far away. You're probably right, but far away doesn't mean never. Especially when one of the media controller developers is interested in the project and could spend time on it :-) I've started working on a prototype implementation that would use the media controller API to report the CRTCs, encoders and connectors topology to userspace. The learning curve is pretty steep as I'm not familiar with the DRM and KMS code, but the code base turned out to be much easier to dive in than it seemed a couple of years ago. -- 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
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue May 17 19:00:35 CEST 2011 git hash:f9b51477fe540fb4c65a05027fdd6f2ecce4db3b gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Notes on the Linaro memory management mini-summit, V4L2
Hi, Here are my own notes from the Linaro memory management mini-summit in Budapest. I've written them from my own point of view, which is mostly V4L2 in embedded devices and camera related use cases. I attempted to summarise the discussion mostly concentrating into parts which I've considered important and ignored the rest. So please do not consider this as the generic notes of the mini-summit. :-) I still felt like sharing this since it might be found useful by those who are working with similar systems with similar problems. Memory buffer management --- the future === The memory buffer management can be split to following sub-problems which may have dependencies, both in implementation and possibly in the APIs as well: - Fulfilling buffer allocation requirements - API to allocate buffers - Sharing buffers among kernel subsystems (e.g. V4L2, DRM, FB) - Sharing buffers between processes - Cache coherency What has been agreed that we need kernel to recognise a DMA buffer which may be passed between user processes and different kernel subsystems. Fulfilling buffer allocation requirements - APIs, as well as devices, have different requirements on the buffers. It is difficult to come up with generic requirements for buffer allocation, and to keep the solution future-proof is challenging as well. In principle the user is interested in being able to share buffers between subsystems without knowing the exact requirements of the devices, which makes it possible to keep the requirement handling internal to the kernel. Whether this is the way to go or not, will be seen in the future. The buffer allocation remains a problem to be resolved in the future. Majority of the devices' requirements could be filled using a few allocators; one for physically continugous memory and the other for physically non-contiguous memory of single page allocations. Being able to allocate large pages would also be beneficial in many cases. API to allocate buffers --- It was agreed there was a need to have a generic interface for buffer object creation. This could be either a new system call which would be supported by all devices supporting such buffers in subsystem APIs (such as V4L2), or a new dedicated character device. Different subsystems have different ways of describing the properties of the buffers, such as how the data in the buffer should be interpreted. The V4L2 has width, height, bytesperline and pixel format, for example. The generic buffers should not recognise such properties since this is very subsystem specific information. Instead, the user which is aware of the different subsystems must come with matching set of buffer properties using the subsystem specific interfaces. Sharing buffers among kernel subsystems --- There was discussion on how to refer to generic DMA buffers, and the audience was first mostly split between using buffer IDs to refer to the buffers and using file handles for the purpose. Using file handles have pros and cons compared to the numeric IDs: + Easy life cycle management. Deallocation of buffers no longer in use is trivial. + Access control for files exists already. Passing file descriptors between processes is possible throught Unix sockets. - Allocating extremely large number of buffers would require as many file descriptors. This is not likely to be an important issue. Before the day ended, it was felt that the file handles are the right way to go. The generic DMA buffers further need to be associated to the subsystem buffers. This is up to the subsystem APIs. In V4L2, this would most likely mean that there will be a new buffer type for the generic DMA buffers. Sharing buffers between processes - Numeric IDs can be easily shared between processes while sharing file handles is more difficult. However, it can be done using the Unix sockets between any two processes. This also gives automatically the same access control mechanism as every other file. Access control mechanisms are mandatory when making the buffer shareable between processes. Cache coherency --- Cache coherency is seen largely orthogonal to any other sub-problems in memory buffer management. In few cases this might have something in common with buffer allocation. Some architectures, ARM in particular, do not have coherent caches, meaning that the operating system must know when to invalidate or clean various parts of the cache. There are two ways to approach the issue, independently of the cache implementation: 1. Allocate non-cacheable memory, or 2. invalidate or clean (or flush) the cache when necessary. Allocating non-cacheable memory is a valid solution to cache coherency handling in some situations, but mostly only when the buffer is only partially accessed by the CPU or at least not multiple times. In other cases, invalidating
Re: [PATCH RFC v2] radio-sf16fmr2: convert to generic TEA575x interface
Hi Ondrej! On Sunday, May 15, 2011 23:26:33 Hans Verkuil wrote: On Sunday, May 15, 2011 22:18:21 Ondrej Zary wrote: Thanks, it's much simpler with the new control framework. Do the negative volume control values make sense? The TC9154A chip can attenuate the volume from 0 to -68dB in 2dB steps. It does make sense, but I think I would offset the values so they start at 0. Mostly because there might be some old apps that set the volume to 0 when they want to mute, which in this case is full volume. I am not aware of any driver where a volume of 0 isn't the same as the lowest volume possible, so in this particular case I would apply an offset. I will have to do a closer review tomorrow or the day after. I think there are a few subtleties that I need to look at. Ping me if you haven't heard from me by Wednesday. I would really like to get these drivers up to spec now that I have someone who can test them, and once that's done I hope that I never have to look at them again :-) (Unlikely, but one can dream...) OK, I looked at it a bit more and it needs to be changed a little bit. The problem is that the VOLUME control is added after snd_tea575x_init, i.e. after the video_register_device call. The video_register_device call should be the last thing done before the init sequence returns. There may be applications (dbus/hal) that open devices as soon as they appear, so doing more initialization after the video node is registered is not a good idea (many older V4L drivers make this mistake). Perhaps creating a snd_tea575x_register function doing just the registration may be a good idea. Or a callback before doing the video_register_device. Another thing: the tea-mute field shouldn't be needed anymore. And the 'mute on init' bit in snd_tea575x_init can be removed as well since that is automatically performed by v4l2_ctrl_handler_setup. In addition, the .ioctl field in tea575x_fops can be replaced by .unlocked_ioctl. The whole exclusive open stuff and the in_use field can be removed. The only thing needed is a struct mutex in struct snd_tea575x, initialize it and set tea575x_radio_inst-lock to the mutex. This will serialize all access safely. To do this really right you should add struct v4l2_device to struct snd_tea575x (the radio-sf16fmr2 driver has one, so you can use that as an example). With that in place you can also add support for 'priority' handling. I'd say see what you can do, and if it takes too much time then mail me the tea575x code and the radio-sf16frm2 code and I'll finish it. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v2] radio-sf16fmr2: convert to generic TEA575x interface
On Tuesday 17 May 2011 21:33:14 Hans Verkuil wrote: Hi Ondrej! On Sunday, May 15, 2011 23:26:33 Hans Verkuil wrote: On Sunday, May 15, 2011 22:18:21 Ondrej Zary wrote: Thanks, it's much simpler with the new control framework. Do the negative volume control values make sense? The TC9154A chip can attenuate the volume from 0 to -68dB in 2dB steps. It does make sense, but I think I would offset the values so they start at 0. Mostly because there might be some old apps that set the volume to 0 when they want to mute, which in this case is full volume. I am not aware of any driver where a volume of 0 isn't the same as the lowest volume possible, so in this particular case I would apply an offset. I will have to do a closer review tomorrow or the day after. I think there are a few subtleties that I need to look at. Ping me if you haven't heard from me by Wednesday. I would really like to get these drivers up to spec now that I have someone who can test them, and once that's done I hope that I never have to look at them again :-) (Unlikely, but one can dream...) OK, I looked at it a bit more and it needs to be changed a little bit. The problem is that the VOLUME control is added after snd_tea575x_init, i.e. after the video_register_device call. The video_register_device call should be the last thing done before the init sequence returns. There may be applications (dbus/hal) that open devices as soon as they appear, so doing more initialization after the video node is registered is not a good idea (many older V4L drivers make this mistake). Perhaps creating a snd_tea575x_register function doing just the registration may be a good idea. Or a callback before doing the video_register_device. OK, I'll reorder the lines in snd_tea575x_init function and add a callback that radio-sf16fmr2 can use. Also upgraded my card with TC9154AP chip so I can actually test the volume control code (and it was broken in my previous patch...). The left and right channels can be separately controlled - is there a way to provide separate left and right volume controls? Or do I need to fake up a balance control? Another thing: the tea-mute field shouldn't be needed anymore. And the 'mute on init' bit in snd_tea575x_init can be removed as well since that is automatically performed by v4l2_ctrl_handler_setup. Thought about this too but the snd_tea575x_write() and snd_tea575x_read() functions need to know the mute status. And these functions are also used to detect the tuner presence before initializing the controls. I don't see any elegant solution. In addition, the .ioctl field in tea575x_fops can be replaced by .unlocked_ioctl. The whole exclusive open stuff and the in_use field can be removed. The only thing needed is a struct mutex in struct snd_tea575x, initialize it and set tea575x_radio_inst-lock to the mutex. This will serialize all access safely. I'll do this as a separate patch later. To do this really right you should add struct v4l2_device to struct snd_tea575x (the radio-sf16fmr2 driver has one, so you can use that as an example). With that in place you can also add support for 'priority' handling. I'd say see what you can do, and if it takes too much time then mail me the tea575x code and the radio-sf16frm2 code and I'll finish it. Regards, Hans -- Ondrej Zary -- 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/3 v5] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers
Hi Laurent, On 05/15/2011 11:10 PM, Laurent Pinchart wrote: On Sunday 15 May 2011 11:33:14 Sylwester Nawrocki wrote: On 05/14/2011 05:29 PM, Laurent Pinchart wrote: On Wednesday 11 May 2011 17:17:10 Sylwester Nawrocki wrote: snip I perhaps need to isolate functions out from of s5pcsis_resume/suspend and then call that in s_power op and s5pcsis_resume/suspend. Don't really like this idea though... It would virtually render pm_runtime_* calls unusable in this sub-device driver, those would make sense only in the host driver.. I think using the pm_runtime_* calls make sense, they could replace the subdev s_power operation in the long term. We'll need to evaluate that (I'm not sure if runtime PM is available on all platforms targeted by V4L2 for instance). That sounds like a really good direction. It would let us have clear standardized rules for power handling in V4L2. And with new chips of more complicated topologies the power handling details could be taken care of by the Runtime PM subsystem. As the runtime PM becomes more granular it appears a good alternative for simple subdev s_power call. Unfortunately still only a few architectures support runtime PM at device bus level in the mainline. What I identified is: arm/mach-exynos4 arm/mach-omap1 arm/mach-omap2 arm/mach-shmobile So very few, no x86 here. As we have I2C, SPI and platform device v4l subdevs ideally those buses should support Runtime PM. I just wanted to put all what is needed to control device's power in the PM helpers and then use pm_runtime_* calls where required. -- Regards, Sylwester Nawrocki -- 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 v4] V4L2 API for flash devices
Sylwester Nawrocki wrote: Hi Sakari, Hi Sylwester, On 05/09/2011 12:11 AM, Sakari Ailus wrote: Sylwester Nawrocki wrote: On 05/07/2011 02:46 PM, Hans Verkuil wrote: On Thursday, May 05, 2011 20:49:21 Sakari Ailus wrote: Hi, This is a fourth proposal for an interface for controlling flash devices on the V4L2/v4l2_subdev APIs. I want to thank everyone who have participated to the development of the flash interface. Comments and questions are very, very welcome as always. Changes since v3 [12] = - V4L2_CID_FLASH_STROBE changed to button control, V4L2_CID_FLASH_STROBE_STOP button control added, V4L2_CID_FLASH_STROBE_STATUS boolean control added. - No reason to say xenon flashes can't use V4L2_CID_FLASH_STROBE. - V4L2_CID_FLASH_STROBE_WHENCE changed to V4L2_CID_FLASH_STROBE_MODE. - V4L2_CID_TORCH_INTENSITY renamed to V4L2_CID_FLASH_TORCH_INTENSITY and V4L2_CID_INDICATOR_INTENSITY renamed to V4L2_CID_FLASH_INDICATOR_INTENSITY. - Moved V4L2_CID_FLASH_EXTERNAL_STROBE_MODE under Possible future extensions. [snip] 3. Sensor metadata on frames It'd be useful to be able to read back sensor metadata. If the flash is strobed (on sensor hardware) while streaming, it's difficult to know otherwise which frame in the stream has been exposed with flash. I wonder if it would make sense to have a V4L2_BUF_FLAG_FLASH buffer flag? That way userspace can tell if that particular frame was taken with flash. This looks more as a workaround for the problem rather than a good long term solution. It might be tempting to use the buffer flags which seem to be be more or less intended for buffer control. I'd like much more to see a buffer flags to be used to indicate whether an additional plane of (meta)data is carried by the buffer. There seem to be many more parameters, than a single flag indicating whether the frame has been exposed with flash or not, needed to be carried over to user space. But then we might need some standard format of the meta data, perhaps control id/value pairs and possibly a per plane configurable memory type. There are multiple possible approaches for this. For sensors where metadata is register-value pairs, that is, essentially V4L2 control values, I think this should be parsed by the sensor driver. The ISP (camera bridge) driver does receive the data so it'd have to ask for help from the sensor driver. I am inclined to let the ISP drivers parse the data but on the other hand it might be difficult to access same DMA buffers in kernel _and_ user space. This is just about mapping the buffer to both kernel and user spaces. If the ISP has an iommu the kernel mapping might already exist if it comes from vmalloc(). As discussed previously, using V4L2 control events shouldn't probably be the way to go, but I think it's obvious that this is _somehow_ bound to controls, at least control ids. Also as Sakari indicated some sensors adopt custom meta data formats so maybe we need to introduce standard fourcc like IDs for meta data formats? I am not sure whether it is possible to create common description of an image meta data that fits all H/W. I'm not sure either since I know of only one example. That example, i.e. register-value pairs, should be something that I'd assume _some_ other hardware uses as well, but there could exist also hardware which doesn't. This solution might not work on that hardware. Of course it's hard to find a silver bullet for a hardware we do not know ;) If there is metadata which does not associate to V4L2 controls (or ioctls), either existing or not yet existing, then that probably should be parsed by the driver. On the other hand, I can't think of metadata that wouldn't fall under this right now. :-) Some metadata are arrays of length specific to a given attribute, I wonder how to support that with v4l2 controls ? Is the metadata something which really isn't associated to any V4L2 control? Are we now talking about a sensor which is more complex than a regular raw bayer sensor? Do you know more examples of sensor produced metadata than SMIA++? The only metadata I've had a bit experience with was regular EXIF tags which could be retrieved from ISP through I2C bus. That obviously won't map to V4L2 controls. This should very likely be just passed to user space as-is as different... plane? In some cases it's time critical to pass data to user space that otherwise could be associated with a video buffer. I wonder if this case is time critical or not. These were mostly fixed point arithmetic numbers in [32-bit numerator/ 32-bit denominator] form carrying exposure time, shutter speed, aperture, brightness, flash, etc. information. The tags could be read from ISP after it buffered a frame in its memory and processed it. In case of a JPEG image format the tags can be embedded into the main image file. But the image processors not always
Re: [PATCH] [media] at91: add Atmel Image Sensor Interface (ISI) support
On 05/17/2011 08:59 PM, Wu, Josh wrote:
On Friday, May 13, 2011 5:25 AM, Ryan Mallon wrote
On 05/12/2011 07:42 PM, Josh Wu wrote:
This patch is to enable Atmel Image Sensor Interface (ISI) driver support.
- Using soc-camera framework with videobuf2 dma-contig allocator
- Supporting video streaming of YUV packed format
- Tested on AT91SAM9M10G45-EK with OV2640
Hi Josh,
Thansk for doing this. Overall the patch looks really good. A few
comments below.
Hi, Ryan
Thank you for the comments.
Signed-off-by: Josh Wu josh...@atmel.com
---
base on branch staging/for_v2.6.40
arch/arm/mach-at91/include/mach/at91_isi.h | 454
drivers/media/video/Kconfig| 10 +
drivers/media/video/Makefile |1 +
drivers/media/video/atmel-isi.c| 1089
4 files changed, 1554 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-at91/include/mach/at91_isi.h
create mode 100644 drivers/media/video/atmel-isi.c
[snip]
+
+/* Bit manipulation macros */
+#define ISI_BIT(name) \
+ (1 ISI_##name##_OFFSET)
+#define ISI_BF(name, value)\
+ (((value) ((1 ISI_##name##_SIZE) - 1)) \
+ ISI_##name##_OFFSET)
+#define ISI_BFEXT(name, value) \
+ (((value) ISI_##name##_OFFSET) \
+ ((1 ISI_##name##_SIZE) - 1))
+#define ISI_BFINS(name, value, old)\
+ (((old) ~(((1 ISI_##name##_SIZE) - 1) \
+ISI_##name##_OFFSET))\
+| ISI_BF(name, value))
I really dislike this kind of register access magic. Not sure how others
feel about it. These macros are really ugly.
I understand this. So I will try to find a better way (static inline
function) to solve this. :)
+/* Register access macros */
+#define isi_readl(port, reg) \
+ __raw_readl((port)-regs + ISI_##reg)
+#define isi_writel(port, reg, value) \
+ __raw_writel((value), (port)-regs + ISI_##reg)
If the token pasting stuff gets dropped then these can be static inline
functions which is preferred.
sure, I'll try.
Something like this is pretty common (should be moved into the .c file):
static inline unsigned atmel_isi_readl(struct atmel_isi *isi,
unsigned reg)
{
return readl(isi-regs + reg);
}
static inline void atmel_isi_writel(struct atmel_isi *isi,
unsigned reg, unsigned val)
{
writel(val, isi-regs + reg);
}
Then for single bit values you can just do:
#define ISI_REG_CR 0x
#define ISI_CR_GRAYSCALE(1 13)
cr = isi_readl(isi, ISI_REG_CR);
cr |= ISI_CR_GRAYSCALE;
isi_writel(isi, ISI_REG_CR, cr);
For bit-fields you could do something like:
static void atmel_isi_set_bitfield(struct atmel_isi *isi, unsigned reg,
unsigned offset, unsigned mask,
unsigned val)
{
unsigned tmp;
tmp = atmel_isi_readl(isi, reg);
tmp = ~(mask offset);
tmp |= (val mask) offset;
atmel_isi_writel(isi, reg, tmp);
}
#define ISI_V2_VCC_SWAP_OFFSET 28
#define ISI_V2_VCC_SWAP_MASK0x3
atmel_isi_set_bitfield(isi, ISI_REG_CR, ISI_V2_VCC_SWAP_OFFSET,
ISI_V2_SWAP_MASK, 2);
There are only a handful of bit-field accesses in the driver so I don't
think this will make the driver much more verbose and it will remove a
number of _SIZE definitions for the single bit values.
snip
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index d61414e..eae6005 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -80,6 +80,16 @@ menuconfig VIDEO_CAPTURE_DRIVERS
Some of those devices also supports FM radio.
if VIDEO_CAPTURE_DRIVERS VIDEO_V4L2
+config VIDEO_ATMEL_ISI
+ tristate ATMEL Image Sensor Interface (ISI) support
+ depends on VIDEO_DEV SOC_CAMERA
Depends on AT91/AVR32?
I think I will use AT91
Somebody else suggested leaving out the AT91 dependency to allow better
build coverage. The reason for having the AT91 dependency is so that it
doesn't show up in menuconfig for people on other platforms and
architectures who cannot use the driver. I've always made SoC drivers
depend on their architecture. Not sure what the correct answer is here?
[snip]
+
+#include media/videobuf2-dma-contig.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+
+#define ATMEL_ISI_VERSION KERNEL_VERSION(1, 0, 0)
Do we really need this version?
Since we need set a version for v4l2_capability.version in function
isi_camera_querycap(). So we use this macro.
How about this?
static int isi_camera_querycap(struct soc_camera_host *ici,
struct v4l2_capability *cap)
[PATCH RFC v3] radio-sf16fmr2: convert to generic TEA575x interface
Convert radio-sf16fmr2 to use generic TEA575x implementation. Most of the
driver code goes away as SF16-FMR2 is basically just a TEA5757 tuner
connected to ISA bus.
The card can optionally be equipped with PT2254A volume control (equivalent
of TC9154AP) - the volume setting is completely reworked and tested.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-2.6.39-rc2-/drivers/media/radio/radio-sf16fmr2.c 2011-04-06
03:30:43.0 +0200
+++ linux-2.6.39-rc2/drivers/media/radio/radio-sf16fmr2.c 2011-05-17
23:24:37.0 +0200
@@ -1,441 +1,184 @@
-/* SF16FMR2 radio driver for Linux radio support
- * heavily based on fmi driver...
- * (c) 2000-2002 Ziglio Frediano, fredd...@angelfire.com
+/* SF16-FMR2 radio driver for Linux
+ * Copyright (c) 2011 Ondrej Zary
*
- * Notes on the hardware
- *
- * Frequency control is done digitally -- ie out(port,encodefreq(95.8));
- * No volume control - only mute/unmute - you have to use line volume
- *
- * For read stereo/mono you must wait 0.1 sec after set frequency and
- * card unmuted so I set frequency on unmute
- * Signal handling seem to work only on autoscanning (not implemented)
- *
- * Converted to V4L2 API by Mauro Carvalho Chehab mche...@infradead.org
+ * Original driver was (c) 2000-2002 Ziglio Frediano, fredd...@angelfire.com
+ * but almost nothing remained here after conversion to generic TEA575x
+ * implementation
*/
+#include linux/delay.h
#include linux/module.h /* Modules */
#include linux/init.h/* Initdata */
#include linux/ioport.h /* request_region */
-#include linux/delay.h /* udelay */
-#include linux/videodev2.h /* kernel radio structs */
-#include linux/mutex.h
-#include linux/version.h /* for KERNEL_VERSION MACRO */
#include linux/io.h /* outb, outb_p */
-#include media/v4l2-device.h
-#include media/v4l2-ioctl.h
+#include sound/tea575x-tuner.h
-MODULE_AUTHOR(Ziglio Frediano, fredd...@angelfire.com);
-MODULE_DESCRIPTION(A driver for the SF16FMR2 radio.);
+MODULE_AUTHOR(Ondrej Zary);
+MODULE_DESCRIPTION(MediaForte SF16-FMR2 FM radio card driver);
MODULE_LICENSE(GPL);
-static int io = 0x384;
-static int radio_nr = -1;
-
-module_param(io, int, 0);
-MODULE_PARM_DESC(io, I/O address of the SF16FMR2 card (should be 0x384, if do
not work try 0x284));
-module_param(radio_nr, int, 0);
-
-#define RADIO_VERSION KERNEL_VERSION(0,0,2)
-
-#define AUD_VOL_INDEX 1
-
-#undef DEBUG
-//#define DEBUG 1
-
-#ifdef DEBUG
-# define debug_print(s) printk s
-#else
-# define debug_print(s)
-#endif
-
-/* this should be static vars for module size */
-struct fmr2
-{
- struct v4l2_device v4l2_dev;
- struct video_device vdev;
- struct mutex lock;
+struct fmr2 {
int io;
- int curvol; /* 0-15 */
- int mute;
- int stereo; /* card is producing stereo audio */
- unsigned long curfreq; /* freq in kHz */
- int card_type;
+ struct snd_tea575x tea;
};
+/* the port is hardwired so no need to support multiple cards */
+#define FMR2_PORT 0x384
static struct fmr2 fmr2_card;
-/* hw precision is 12.5 kHz
- * It is only useful to give freq in interval of 200 (=0.0125Mhz),
- * other bits will be truncated
- */
-#define RSF16_ENCODE(x)((x) / 200 + 856)
-#define RSF16_MINFREQ (87 * 16000)
-#define RSF16_MAXFREQ (108 * 16000)
+/* TEA575x tuner pins */
+#define STR_DATA (1 0)
+#define STR_CLK(1 1)
+#define STR_WREN (1 2)
+#define STR_MOST (1 3)
+/* PT2254A/TC9154A volume control pins */
+#define PT_ST (1 4)
+#define PT_CK (1 5)
+#define PT_DATA(1 6)
+/* volume control presence pin */
+#define FMR2_HASVOL(1 7)
-static inline void wait(int n, int io)
+static void fmr2_tea575x_set_pins(struct snd_tea575x *tea, u8 pins)
{
- for (; n; --n)
- inb(io);
-}
+ struct fmr2 *fmr2 = tea-private_data;
+ u8 bits = 0;
-static void outbits(int bits, unsigned int data, int nWait, int io)
-{
- int bit;
+ bits |= (pins TEA575X_DATA) ? STR_DATA : 0;
+ bits |= (pins TEA575X_CLK) ? STR_CLK : 0;
+ /* WRITE_ENABLE is inverted, DATA must be high during read */
+ bits |= (pins TEA575X_WREN) ? 0 : STR_WREN | STR_DATA;
- for (; --bits = 0;) {
- bit = (data bits) 1;
- outb(bit, io);
- wait(nWait, io);
- outb(bit | 2, io);
- wait(nWait, io);
- outb(bit, io);
- wait(nWait, io);
- }
-}
-
-static inline void fmr2_mute(int io)
-{
- outb(0x00, io);
- wait(4, io);
-}
-
-static inline void fmr2_unmute(int io)
-{
- outb(0x04, io);
- wait(4, io);
-}
-
-static inline int fmr2_stereo_mode(int io)
-{
- int n = inb(io);
-
- outb(6, io);
- inb(io);
-
[PATCH RFC v2] tea575x: convert to control framework
Convert tea575x-tuner to use the new V4L2 control framework.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-2.6.39-rc2-/include/sound/tea575x-tuner.h 2011-05-13
19:39:23.0 +0200
+++ linux-2.6.39-rc2/include/sound/tea575x-tuner.h 2011-05-17
22:35:19.0 +0200
@@ -23,8 +23,7 @@
*/
#include linux/videodev2.h
-#include media/v4l2-dev.h
-#include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
#define TEA575X_FMIF 10700
@@ -54,6 +53,8 @@ struct snd_tea575x {
void *private_data;
u8 card[32];
u8 bus_info[32];
+ struct v4l2_ctrl_handler ctrl_handler;
+ void (*ext_init)(struct snd_tea575x *tea);
};
int snd_tea575x_init(struct snd_tea575x *tea);
--- linux-2.6.39-rc2-/sound/i2c/other/tea575x-tuner.c 2011-05-13
19:39:23.0 +0200
+++ linux-2.6.39-rc2/sound/i2c/other/tea575x-tuner.c2011-05-17
23:32:07.0 +0200
@@ -22,11 +22,11 @@
#include asm/io.h
#include linux/delay.h
-#include linux/interrupt.h
#include linux/init.h
#include linux/slab.h
#include linux/version.h
-#include sound/core.h
+#include media/v4l2-dev.h
+#include media/v4l2-ioctl.h
#include sound/tea575x-tuner.h
MODULE_AUTHOR(Jaroslav Kysela pe...@perex.cz);
@@ -62,17 +62,6 @@ module_param(radio_nr, int, 0);
#define TEA575X_BIT_DUMMY (115) /* buffer */
#define TEA575X_BIT_FREQ_MASK 0x7fff
-static struct v4l2_queryctrl radio_qctrl[] = {
- {
- .id= V4L2_CID_AUDIO_MUTE,
- .name = Mute,
- .minimum = 0,
- .maximum = 1,
- .default_value = 1,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- }
-};
-
/*
* lowlevel part
*/
@@ -266,47 +255,19 @@ static int vidioc_s_audio(struct file *f
return 0;
}
-static int vidioc_queryctrl(struct file *file, void *priv,
- struct v4l2_queryctrl *qc)
-{
- int i;
-
- for (i = 0; i ARRAY_SIZE(radio_qctrl); i++) {
- if (qc-id qc-id == radio_qctrl[i].id) {
- memcpy(qc, (radio_qctrl[i]),
- sizeof(*qc));
- return 0;
- }
- }
- return -EINVAL;
-}
-
-static int vidioc_g_ctrl(struct file *file, void *priv,
- struct v4l2_control *ctrl)
-{
- struct snd_tea575x *tea = video_drvdata(file);
-
- switch (ctrl-id) {
- case V4L2_CID_AUDIO_MUTE:
- ctrl-value = tea-mute;
- return 0;
- }
- return -EINVAL;
-}
-
-static int vidioc_s_ctrl(struct file *file, void *priv,
- struct v4l2_control *ctrl)
+static int tea575x_s_ctrl(struct v4l2_ctrl *ctrl)
{
- struct snd_tea575x *tea = video_drvdata(file);
+ struct snd_tea575x *tea = container_of(ctrl-handler, struct
snd_tea575x, ctrl_handler);
switch (ctrl-id) {
case V4L2_CID_AUDIO_MUTE:
- if (tea-mute != ctrl-value) {
- tea-mute = ctrl-value;
+ if (tea-mute != ctrl-val) {
+ tea-mute = ctrl-val;
snd_tea575x_set_freq(tea);
}
return 0;
}
+
return -EINVAL;
}
@@ -355,9 +316,6 @@ static const struct v4l2_ioctl_ops tea57
.vidioc_s_input = vidioc_s_input,
.vidioc_g_frequency = vidioc_g_frequency,
.vidioc_s_frequency = vidioc_s_frequency,
- .vidioc_queryctrl = vidioc_queryctrl,
- .vidioc_g_ctrl = vidioc_g_ctrl,
- .vidioc_s_ctrl = vidioc_s_ctrl,
};
static struct video_device tea575x_radio = {
@@ -367,6 +325,10 @@ static struct video_device tea575x_radio
.release= video_device_release,
};
+static const struct v4l2_ctrl_ops tea575x_ctrl_ops = {
+ .s_ctrl = tea575x_s_ctrl,
+};
+
/*
* initialize all the tea575x chips
*/
@@ -384,29 +346,39 @@ int snd_tea575x_init(struct snd_tea575x
tea-in_use = 0;
tea-val = TEA575X_BIT_BAND_FM | TEA575X_BIT_SEARCH_10_40;
tea-freq = 90500 * 16; /* 90.5Mhz default */
+ snd_tea575x_set_freq(tea);
tea575x_radio_inst = video_device_alloc();
- if (tea575x_radio_inst == NULL) {
+ if (!tea575x_radio_inst) {
printk(KERN_ERR tea575x-tuner: not enough memory\n);
return -ENOMEM;
}
memcpy(tea575x_radio_inst, tea575x_radio, sizeof(tea575x_radio));
+ video_set_drvdata(tea575x_radio_inst, tea);
- strcpy(tea575x_radio.name, tea-tea5759 ?
- TEA5759 radio : TEA5757 radio);
+ v4l2_ctrl_handler_init(tea-ctrl_handler, 1);
+ tea575x_radio_inst-ctrl_handler = tea-ctrl_handler;
+ v4l2_ctrl_new_std(tea-ctrl_handler, tea575x_ctrl_ops,
V4L2_CID_AUDIO_MUTE, 0, 1, 1, 1);
+ retval =
[RFC] Standardize YUV support in the fbdev API
Hi everybody,
I need to implement support for a YUV frame buffer in an fbdev driver. As the
fbdev API doesn't support this out of the box, I've spent a couple of days
reading fbdev (and KMS) code and thinking about how we could cleanly add YUV
support to the API. I'd like to share my findings and thoughts, and hopefully
receive some comments back.
The terms 'format', 'pixel format', 'frame buffer format' and 'data format'
will be used interchangeably in this e-mail. They all refer to the way pixels
are stored in memory, including both the representation of a pixel as integer
values and the layout of those integer values in memory.
History and current situation
-
The fbdev API predates YUV frame buffers. In those old days developers only
cared (and probably thought) about RGB frame buffers, and they developed an
API that could express all kind of weird RGB layout in memory (such as R-
GGG- for instance, I can't imagine hardware implementing that).
This resulted in individual bit field description for the red, green, blue and
alpha components:
struct fb_bitfield {
__u32 offset; /* beginning of bitfield*/
__u32 length; /* length of bitfield */
__u32 msb_right; /* != 0 : Most significant bit is */
/* right */
};
Grayscale formats were pretty common, so a grayscale field tells color formats
(grayscale == 0) from grayscale formats (grayscale != 0).
People already realized that hardware developers were crazily inventive (the
word to remember here is crazily), and that non-standard formats would be
needed at some point. The fb_var_screeninfo ended up containing the following
format-related fields.
struct fb_var_screeninfo {
...
__u32 bits_per_pixel; /* guess what */
__u32 grayscale; /* != 0 Graylevels instead of colors */
struct fb_bitfield red;/* bitfield in fb mem if true color, */
struct fb_bitfield green; /* else only length is significant */
struct fb_bitfield blue;
struct fb_bitfield transp; /* transparency */
__u32 nonstd; /* != 0 Non standard pixel format */
...
};
Two bits have been specified for the nonstd field:
#define FB_NONSTD_HAM 1 /* Hold-And-Modify (HAM)*/
#define FB_NONSTD_REV_PIX_IN_B 2 /* order of pixels in each byte is reversed
*/
The FB_NONSTD_HAM bit is used by the video/amifb.c driver only to enable HAM
mode[1]. I very much doubt that any new hardware will implement HAM mode (and
I certainly hope none will).
The FB_NONSTD_REV_PIX_IN_B is used in video/fb_draw.h by the generic bitblit,
fillrect and copy area implementations, not directly by drivers.
A couple of drivers hardcode the nonstd field to 1 for some reason. Those are
video/arcfb.c (1bpp gray display), video/hecubafb.c (1bpp gray display) and
video/metronomefb.c (8bpp gray display).
The following drivers use nonstd for various other (and sometimes weird)
purposes:
video/arkfb.c
Used in 4bpp mode only, to control fb_setcolreg operation
video/fsl-diu-fb.c
Set var-nonstd bits into var-sync (why?)
video/pxafb.c
Encode frame buffer xpos and ypos in the nonstd field
video/s3fb.c
Used in 4bpp mode only, to control fb_setcolreg operation
video/vga16fb.c
When panning in non-8bpp, non-text mode, decrement xoffset
Do some other weird stuff when not 0
video/i810/i810_main.c
Select direct color mode when set to 1 (truecolor otherwise)
Fast forward a couple of years, hardware provides support for YUV frame
buffers. Several drivers had to provide YUV format selection to applications,
without any standard API to do so. All of them used the nonstd field for that
purpose:
media/video/ivtv/
Enable YUV mode when set to 1
video/pxafb.c
Encode pixel format in the nonstd field
video/sh_mobile_lcdfb.c
If bpp == 12 and nonstd != 0, enable NV12 mode
If bpp == 16 or bpp == 24, ?
video/omap/omapfb_main.c
Select direct color mode when set to 1 (depend on bpp otherwise)
Used as a pixel format identifier (YUV422, YUV420 or YUY422)
video/omap2/omapfb/omapfb-main.c
Select direct color mode when set to 1 (depend on bpp otherwise)
Used as a pixel format identifier (YUV422 or YUY422)
Those drivers use the nonstd field in different, incompatible ways.
Other related APIs
--
Beside the fbdev API, two other kernel/userspace APIs deal with video-related
modes and formats.
- Kernel Mode Setting (KMS)
The KMS API is similar in purpose to XRandR. Its main purpose is to provide a
kernel API to configure output video modes. As such, it doesn't care about
frame buffer formats, as they are irrelevant at the CRTC output.
In addition to handling
Re: [RFC] Standardize YUV support in the fbdev API
On Wed, May 18, 2011 at 1:07 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: I need to implement support for a YUV frame buffer in an fbdev driver. As the fbdev API doesn't support this out of the box, I've spent a couple of days reading fbdev (and KMS) code and thinking about how we could cleanly add YUV support to the API. I'd like to share my findings and thoughts, and hopefully receive some comments back. The terms 'format', 'pixel format', 'frame buffer format' and 'data format' will be used interchangeably in this e-mail. They all refer to the way pixels are stored in memory, including both the representation of a pixel as integer values and the layout of those integer values in memory. This is a great proposal. It was about time! The third solution has my preference. Comments and feedback will be appreciated. I will then work on a proof of concept and submit patches. I also would prefer the third solution. I don't think there's much difference from the user-space point of view, and a new ioctl would be cleaner. Also the v4l2 fourcc's should do. Cheers. -- Felipe Contreras -- 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/3 v5] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers
On Tue, May 17, 2011 at 10:06:23PM +0200, Sylwester Nawrocki wrote: As we have I2C, SPI and platform device v4l subdevs ideally those buses should support Runtime PM. They all do so. -- 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] OMAP3BEAGLE: Add support for mt9p031 sensor (LI-5M03 module).
On Tue, May 17, 2011 at 11:28:48AM +0200, Javier Martin wrote:
+#include devices.h
+#include ../../../drivers/media/video/omap3isp/isp.h
+#include ../../../drivers/media/video/omap3isp/ispreg.h
This suggests that there's something very wrong with what's going on;
it suggests that you're trying to access driver internals which should
be handled via some better means. And it looks like it's this:
@@ -654,6 +715,62 @@ static void __init beagle_opp_init(void)
return;
}
+extern struct platform_device omap3isp_device;
+
+static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+{
+ struct isp_device *isp = platform_get_drvdata(omap3isp_device);
+ int ret;
+
+ ret = isp-platform_cb.set_xclk(isp, hz, MT9P031_XCLK);
+ return 0;
+}
That really needs fixing in a different way.
--
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] mt9p031: Add mt9p031 sensor driver.
On Tue, May 17, 2011 at 01:33:52PM +0200, Laurent Pinchart wrote:
Hi Javier,
Thanks for the patch.
Sorry, but this laziness is getting beyond a joke... And the fact that
apparantly no one is picking up on it other than me is also a joke.
+static int mt9p031_power_on(struct mt9p031 *mt9p031)
+{
+ int ret;
+
+ if (mt9p031-pdata-set_xclk)
+ mt9p031-pdata-set_xclk(mt9p031-subdev, 5400);
+ /* turn on VDD_IO */
+ ret = regulator_enable(mt9p031-reg_2v8);
+ if (ret) {
+ pr_err(Failed to enable 2.8v regulator: %d\n, ret);
+ return -1;
And why all these 'return -1's? My guess is that this is plain laziness
on the authors part.
+static int mt9p031_set_params(struct i2c_client *client,
+ struct v4l2_rect *rect, u16 xskip, u16 yskip)
set_params should apply the parameters, not change them. They should have
already been validated by the callers.
+{
...
+err:
+ return -1;
And again...
+}
+
+static int mt9p031_set_crop(struct v4l2_subdev *sd,
+ struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_crop *crop)
+{
...
+ if (crop-which == V4L2_SUBDEV_FORMAT_ACTIVE) {
+ ret = mt9p031_set_params(client, rect, xskip, yskip);
+ if (ret 0)
+ return ret;
So this propagates the lazy 'return -1' all the way back to userspace.
This is utter crap - really it is, and I'm getting sick and tired of
telling people that they should not use 'return -1'. It's down right
lazy and sloppy programming.
I wish people would stop doing it. I wish people would review their own
stuff for this _before_ posting it onto a mailing list, so I don't have
to keep complaining about it. And I wish people reviewing drivers would
also look for this as well and complain about it.
'return -1' is generally a big fat warning sign that the author is doing
something wrong, and should _always_ be investigated and complained about.
--
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] Standardize YUV support in the fbdev API
On Wed, 2011-05-18 at 00:07 +0200, Laurent Pinchart wrote:
Hi everybody,
I need to implement support for a YUV frame buffer in an fbdev driver. As the
fbdev API doesn't support this out of the box, I've spent a couple of days
reading fbdev (and KMS) code and thinking about how we could cleanly add YUV
support to the API. I'd like to share my findings and thoughts, and hopefully
receive some comments back.
I haven't looked at anything below, but I'll mention that the ivtv
driver presents an fbdev interface for the YUV output stream of the
CX23415.
It may be worth a look and asking Hans what are the short-comings.
-Andy
The terms 'format', 'pixel format', 'frame buffer format' and 'data format'
will be used interchangeably in this e-mail. They all refer to the way pixels
are stored in memory, including both the representation of a pixel as integer
values and the layout of those integer values in memory.
History and current situation
-
The fbdev API predates YUV frame buffers. In those old days developers only
cared (and probably thought) about RGB frame buffers, and they developed an
API that could express all kind of weird RGB layout in memory (such as R-
GGG- for instance, I can't imagine hardware implementing that).
This resulted in individual bit field description for the red, green, blue
and
alpha components:
struct fb_bitfield {
__u32 offset; /* beginning of bitfield*/
__u32 length; /* length of bitfield */
__u32 msb_right; /* != 0 : Most significant bit is */
/* right */
};
Grayscale formats were pretty common, so a grayscale field tells color
formats
(grayscale == 0) from grayscale formats (grayscale != 0).
People already realized that hardware developers were crazily inventive (the
word to remember here is crazily), and that non-standard formats would be
needed at some point. The fb_var_screeninfo ended up containing the following
format-related fields.
struct fb_var_screeninfo {
...
__u32 bits_per_pixel; /* guess what */
__u32 grayscale; /* != 0 Graylevels instead of colors */
struct fb_bitfield red;/* bitfield in fb mem if true color, */
struct fb_bitfield green; /* else only length is significant */
struct fb_bitfield blue;
struct fb_bitfield transp; /* transparency */
__u32 nonstd; /* != 0 Non standard pixel format */
...
};
Two bits have been specified for the nonstd field:
#define FB_NONSTD_HAM 1 /* Hold-And-Modify (HAM)*/
#define FB_NONSTD_REV_PIX_IN_B 2 /* order of pixels in each byte is
reversed
*/
The FB_NONSTD_HAM bit is used by the video/amifb.c driver only to enable HAM
mode[1]. I very much doubt that any new hardware will implement HAM mode (and
I certainly hope none will).
The FB_NONSTD_REV_PIX_IN_B is used in video/fb_draw.h by the generic bitblit,
fillrect and copy area implementations, not directly by drivers.
A couple of drivers hardcode the nonstd field to 1 for some reason. Those are
video/arcfb.c (1bpp gray display), video/hecubafb.c (1bpp gray display) and
video/metronomefb.c (8bpp gray display).
The following drivers use nonstd for various other (and sometimes weird)
purposes:
video/arkfb.c
Used in 4bpp mode only, to control fb_setcolreg operation
video/fsl-diu-fb.c
Set var-nonstd bits into var-sync (why?)
video/pxafb.c
Encode frame buffer xpos and ypos in the nonstd field
video/s3fb.c
Used in 4bpp mode only, to control fb_setcolreg operation
video/vga16fb.c
When panning in non-8bpp, non-text mode, decrement xoffset
Do some other weird stuff when not 0
video/i810/i810_main.c
Select direct color mode when set to 1 (truecolor otherwise)
Fast forward a couple of years, hardware provides support for YUV frame
buffers. Several drivers had to provide YUV format selection to applications,
without any standard API to do so. All of them used the nonstd field for that
purpose:
media/video/ivtv/
Enable YUV mode when set to 1
video/pxafb.c
Encode pixel format in the nonstd field
video/sh_mobile_lcdfb.c
If bpp == 12 and nonstd != 0, enable NV12 mode
If bpp == 16 or bpp == 24, ?
video/omap/omapfb_main.c
Select direct color mode when set to 1 (depend on bpp otherwise)
Used as a pixel format identifier (YUV422, YUV420 or YUY422)
video/omap2/omapfb/omapfb-main.c
Select direct color mode when set to 1 (depend on bpp otherwise)
Used as a pixel format identifier (YUV422 or YUY422)
Those drivers use the nonstd field in different, incompatible ways.
Other related APIs
[GIT PULL for v2.6.39-rc7] media fixes
Hi Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus For the following fixes: - v4l2 core: fix two bad behaviours at subdev interface; - cx88: fix remote control suport; - soc-camera: fix a regression on image size calculus. Thanks! Mauro - The following changes since commit 693d92a1bbc9e42681c42ed190bd42b636ca876f: Linux 2.6.39-rc7 (2011-05-09 19:33:54 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus Hans Verkuil (1): [media] v4l2-subdev: fix broken subdev control enumeration Laurent Pinchart (1): [media] v4l: Release module if subdev registration fails Lawrence Rust (1): [media] Fix cx88 remote control input Sergio Aguirre (1): [media] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c drivers/media/video/cx88/cx88-input.c |2 +- drivers/media/video/soc_camera.c | 48 drivers/media/video/v4l2-device.c |5 +++- drivers/media/video/v4l2-subdev.c | 14 +- 4 files changed, 54 insertions(+), 15 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: [RFC] Standardize YUV support in the fbdev API
Oops. Nevermind, you already have looked at what ivtvfb does. -Andy -- 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] xc5000, fix fw upload crash
On Tue, May 17, 2011 at 12:23 AM, Dmitri Belimov d.beli...@gmail.com wrote:
Hi
Fix crash when init tuner and upload twice the firmware into xc5000 at the
some time.
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index aa1b2e8..a491a5b 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -996,6 +996,8 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend
*fe)
struct xc5000_priv *priv = fe-tuner_priv;
int ret = 0;
+ mutex_lock(xc5000_list_mutex);
+
if (xc5000_is_firmware_loaded(fe) != XC_RESULT_SUCCESS) {
ret = xc5000_fwupload(fe);
if (ret != XC_RESULT_SUCCESS)
@@ -1015,6 +1017,8 @@ static int xc_load_fw_and_init_tuner(struct
dvb_frontend *fe)
/* Default to CABLE mode */
ret |= xc_write_reg(priv, XREG_SIGNALSOURCE, XC_RF_MODE_CABLE);
+ mutex_unlock(xc5000_list_mutex);
+
return ret;
}
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com
With my best regards, Dmitry.
NACK!
I don't think this patch is correct. Concurrency problems are
expected to be handled in the upper layers, as there are usually much
more significant problems than just this case. For example, if this
is a race between V4L2 and DVB, it is the responsibility of bridge
driver to provide proper locking.
If patches like this were accepted, we would need to litter every call
of all the tuner drivers with mutex lock/unlock, and it simply isn't
maintainable.
NACK unless Dmitri can provide a much better explanation as to why
this patch should be accepted rather than fixing the problem in the
bridge driver.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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
pxa ccic driver based on soc_camera and videobuf
hi, Guennadi, Hans: I just converted Marvell CCIC driver from ccic_cafe to soc_camera + videobuf, and make it stable and robust. do you accept the soc_camera + videobuf to the latest kernel ? thanks Best regards Kassey Email: y...@marvell.com Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- 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: hvr950Q on Ubuntu 11.04
On Sat, May 14, 2011 at 12:54 PM, Bruce Barnett grymo...@gmail.com wrote: I'm having a heck of a time trying to get a TV buffer card running. I bought a Hauppauge 950Q and HVR1255. I can get neither to work. I also just bought a Evga GT 430 graphics card as I was using a LGA 1156 Intel i3 with Intel graphics, thinking the Intel graphics might not work. US w/Analog Cable and some unencrypted digital channels (local origin) on the cable. I can't get w_scan to work. It can't find any thing. I tried the latest from kernellabs. I tried various other programs. I have not yet tried a custom kernel. I have the right firmware for the hauppauge card. I installed the latest supported NVIDIA driver. I just don't know how to diagnose the problem... Hello Bruce, Questions like this are much better directed to the linux-media mailing list rather than to me personally. As a developer, if I answered every email from every new user who can't figure out how to make their card work then I would never get any code written. The linuxtv.org wiki is also a good resource for debugging. Adding the mailing list to the cc:. Somebody should be able to walk you through the introductory steps for debugging basic end-user issues. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: Audio Video synchronization for data received from a HDMI receiver chip
Hi, (adding alsa mailing list in cc) On Thursday, May 12, 2011 18:59:33 Charlie X. Liu wrote: Which HDMI receiver chip? Indeed, that's my question as well :-) We use Sil 9135 receiver chip which is provided by Silicon Image. Please see details here: http://www.siliconimage.com/products/product.aspx?pid=109 Anyway, this question comes up regularly. V4L2 provides timestamps for each frame, so that's no problem. But my understanding is that ALSA does not give you timestamps, so if there are processing delays between audio and video, then you have no way of knowing. The obvious solution is to talk to the ALSA people to see if some sort of timestamping is possible, but nobody has done that. I am aware of the time stamping feature provided by V4L2, but I am also not sure whether the same feature is supported by ALSA. I have included alsa-mailing list also in copy of this mail. Let's see if we can get some sort of confirmation on this from them. This is either because everyone that needs it hacks around it instead of trying to really solve it, or because it is never a problem in practice. What should be the proper solution according to you to solve this issue. Do we require a Audio-Video Bridge kind of utility/mechanism? Regards, Bhupesh -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Bhupesh SHARMA Sent: Wednesday, May 11, 2011 10:49 PM To: linux-media@vger.kernel.org Cc: Laurent Pinchart; Guennadi Liakhovetski; Hans Verkuil Subject: Audio Video synchronization for data received from a HDMI receiver chip Hi Linux media folks, We are considering putting an advanced HDMI receiver chip on our SoC, to allow reception of HDMI audio and video. The chip receives HDMI data from a host like a set-up box or DVD player. It provides a video data interface and SPDIF/I2S audio data interface. We plan to support the HDMI video using the V4L2 framework and the HDMI audio using ALSA framework. Now, what seems to be intriguing us is how the audio-video synchronization will be maintained? Will a separate bridging entity required to ensure the same or whether this can be left upon a user space application like mplayer or gstreamer. Also is there a existing interface between the V4L2 and ALSA frameworks and the same can be used in our design? Regards, Bhupesh ST Microelectronics -- 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 -- regards Shiraz Hashim -- 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] [media] at91: add Atmel Image Sensor Interface (ISI) support
On 08:58 Wed 18 May , Ryan Mallon wrote:
On 05/17/2011 08:59 PM, Wu, Josh wrote:
On Friday, May 13, 2011 5:25 AM, Ryan Mallon wrote
On 05/12/2011 07:42 PM, Josh Wu wrote:
This patch is to enable Atmel Image Sensor Interface (ISI) driver
support.
- Using soc-camera framework with videobuf2 dma-contig allocator
- Supporting video streaming of YUV packed format
- Tested on AT91SAM9M10G45-EK with OV2640
Hi Josh,
Thansk for doing this. Overall the patch looks really good. A few
comments below.
Hi, Ryan
Thank you for the comments.
Signed-off-by: Josh Wu josh...@atmel.com
---
base on branch staging/for_v2.6.40
arch/arm/mach-at91/include/mach/at91_isi.h | 454
drivers/media/video/Kconfig| 10 +
drivers/media/video/Makefile |1 +
drivers/media/video/atmel-isi.c| 1089
4 files changed, 1554 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-at91/include/mach/at91_isi.h
create mode 100644 drivers/media/video/atmel-isi.c
[snip]
+
+/* Bit manipulation macros */
+#define ISI_BIT(name)\
+ (1 ISI_##name##_OFFSET)
+#define ISI_BF(name, value) \
+ (((value) ((1 ISI_##name##_SIZE) - 1)) \
+ ISI_##name##_OFFSET)
+#define ISI_BFEXT(name, value) \
+ (((value) ISI_##name##_OFFSET) \
+ ((1 ISI_##name##_SIZE) - 1))
+#define ISI_BFINS(name, value, old) \
+ (((old) ~(((1 ISI_##name##_SIZE) - 1) \
+ ISI_##name##_OFFSET))\
+ | ISI_BF(name, value))
I really dislike this kind of register access magic. Not sure how others
feel about it. These macros are really ugly.
I understand this. So I will try to find a better way (static inline
function) to solve this. :)
+/* Register access macros */
+#define isi_readl(port, reg) \
+ __raw_readl((port)-regs + ISI_##reg)
+#define isi_writel(port, reg, value) \
+ __raw_writel((value), (port)-regs + ISI_##reg)
If the token pasting stuff gets dropped then these can be static inline
functions which is preferred.
sure, I'll try.
Something like this is pretty common (should be moved into the .c file):
static inline unsigned atmel_isi_readl(struct atmel_isi *isi,
unsigned reg)
{
return readl(isi-regs + reg);
}
static inline void atmel_isi_writel(struct atmel_isi *isi,
unsigned reg, unsigned val)
{
writel(val, isi-regs + reg);
}
really do not like it
and prefer the first implemetation
NACK for me
Then for single bit values you can just do:
#define ISI_REG_CR0x
#define ISI_CR_GRAYSCALE (1 13)
cr = isi_readl(isi, ISI_REG_CR);
cr |= ISI_CR_GRAYSCALE;
isi_writel(isi, ISI_REG_CR, cr);
For bit-fields you could do something like:
static void atmel_isi_set_bitfield(struct atmel_isi *isi, unsigned reg,
unsigned offset, unsigned mask,
unsigned val)
{
unsigned tmp;
tmp = atmel_isi_readl(isi, reg);
tmp = ~(mask offset);
tmp |= (val mask) offset;
atmel_isi_writel(isi, reg, tmp);
}
stop to reinvent thinks
use the bitops of the kernel
#define ISI_V2_VCC_SWAP_OFFSET28
#define ISI_V2_VCC_SWAP_MASK 0x3
atmel_isi_set_bitfield(isi, ISI_REG_CR, ISI_V2_VCC_SWAP_OFFSET,
ISI_V2_SWAP_MASK, 2);
There are only a handful of bit-field accesses in the driver so I don't
think this will make the driver much more verbose and it will remove a
number of _SIZE definitions for the single bit values.
snip
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index d61414e..eae6005 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -80,6 +80,16 @@ menuconfig VIDEO_CAPTURE_DRIVERS
Some of those devices also supports FM radio.
if VIDEO_CAPTURE_DRIVERS VIDEO_V4L2
+config VIDEO_ATMEL_ISI
+ tristate ATMEL Image Sensor Interface (ISI) support
+ depends on VIDEO_DEV SOC_CAMERA
Depends on AT91/AVR32?
I think I will use AT91
Somebody else suggested leaving out the AT91 dependency to allow better
build coverage. The reason for having the AT91 dependency is so that it
doesn't show up in menuconfig for people on other platforms and
architectures who cannot use the driver. I've always made SoC drivers
depend on their architecture. Not sure what the correct answer is here?
no if the drivers is soc specific we MUST not enabled it on other soc
and avoid maintainancne issue
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
