Re: [PATCH for v3.6] VIDIOC_ENUM_FREQ_BANDS fix
On Wed August 1 2012 22:41:16 Rémi Denis-Courmont wrote: Le mercredi 1 août 2012 22:52:46 Hans Verkuil, vous avez écrit : When VIDIOC_ENUM_FREQ_BANDS is called for a driver that doesn't supply an enum_freq_bands op, then it will fall back to reporting a single freq band based on information from g_tuner or g_modulator. By the way... Isn't V4L2_TUNER_CAP_FREQ_BANDS expected to tell whether the driver can enumerate bands? Yes. And it is set as well in this fallback case. Why is there a need for fallback implementation? The main reason is that struct v4l2_frequency_band also returns the modulation of the frequency band. For all existing drivers (except radio-cadet, which now implements enum_freq_bands) this can be deduced by the type of device node that's used (/dev/radioX means FM, /dev/videoX or vbiX means VSB). While the application could do the same we decided it was more consistent if the V4L2 core does that for the application. It was trivial to implement. So apps will benefit, and only drivers that actually have more than one frequency band need to go to the trouble of implementing enum_freq_bands. 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: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote: Le mercredi 1 août 2012 14:35:03 Laurent Pinchart, vous avez écrit : But in general, the V4L element in the pipeline does not know how fast the downstream element(s) will consume the buffers. Thus it has to copy from the MMAP buffers into anonymous user memory pending processing. Then any dequeued buffer can be requeued as soon as possible. In theory, it might also be that, even though the latency is known, the number of required buffers exceeds the maximum MMAP buffers count of the V4L device. Either way, user space ends up doing memory copy from MMAP to custom buffers. This problem does not exist with USERBUF - the V4L2 element can simply allocate a new buffer for each dequeued buffer. What about using the CREATE_BUFS ioctl to add new MMAP buffers at runtime ? Does CREATE_BUFS always work while already streaming has already started? If it depends on the driver, it's kinda helpless. Yes, it does. It's one of the reasons it exists in the first place. But there are currently only a handful of drivers that implement it. I hope that as more and more drivers are converted to vb2 that the availability of create_bufs will increase. What's the guaranteed minimum buffer count? It seems in any case, MMAP has a hard limit of 32 buffers (at least videobuf2 has), though one might argue this should be more than enough. Minimum or maximum? The maximum is 32, that's hardcoded in the V4L2 core. Although drivers may force a lower maximum if they want. I have no idea whether there are drivers that do that. There probably are. The minimum is usually between 1 and 3, depending on hardware limitations. 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 v7 2/2] v4l2: add new pixel formats supported on dm365
Hi Sakari,
Thanks for the review.
On Thursday 02 August 2012 05:59 AM, Sakari Ailus wrote:
Hi Prabhakar,
Thanks for the patch.
On Fri, Jul 27, 2012 at 04:25:05PM +0530, Prabhakar Lad wrote:
From: Manjunath Hadli manjunath.ha...@ti.com
add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats
to represent Bayer format frames compressed by A-LAW algorithm,
add V4L2_PIX_FMT_UV8 to represent storage of CbCr data (UV interleaved)
only.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
.../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++
Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62
Documentation/DocBook/media/v4l/pixfmt.xml |2 +
include/linux/videodev2.h |8 +++
4 files changed, 106 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
new file mode 100644
index 000..c934192
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
@@ -0,0 +1,34 @@
+refentry
+ refmeta
+refentrytitle
+ V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
+ V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
+ V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
+ V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
+/refentrytitle
+manvol;
+ /refmeta
+ refnamediv
+refname id=V4L2-PIX-FMT-SBGGR10ALAW8
+ constantV4L2_PIX_FMT_SBGGR10ALAW8/constant
+/refname
+refname id=V4L2-PIX-FMT-SGBRG10ALAW8
+ constantV4L2_PIX_FMT_SGBRG10ALAW8/constant
+/refname
+refname id=V4L2-PIX-FMT-SGRBG10ALAW8
+ constantV4L2_PIX_FMT_SGRBG10ALAW8/constant
+/refname
+refname id=V4L2-PIX-FMT-SRGGB10ALAW8
+ constantV4L2_PIX_FMT_SRGGB10ALAW8/constant
+/refname
+refpurpose10-bit Bayer formats compressed to 8 bits/refpurpose
+ /refnamediv
+ refsect1
+titleDescription/title
+paraThe following four pixel formats are raw sRGB / Bayer
+formats with 10 bits per color compressed to 8 bits each,
+using the A-LAW algorithm. Each color component consumes 8
+bits of memory. In other respects this format is similar to
+xref linkend=V4L2-PIX-FMT-SRGGB8./xref/para
+ /refsect1
+/refentry
diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
new file mode 100644
index 000..c507c1f
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
@@ -0,0 +1,62 @@
+refentry id=V4L2-PIX-FMT-UV8
+ refmeta
+refentrytitleV4L2_PIX_FMT_UV8 ('UV8')/refentrytitle
+manvol;
+ /refmeta
+ refnamediv
+refnameconstantV4L2_PIX_FMT_UV8/constant/refname
+refpurposeUV plane interleaved/refpurpose
+ /refnamediv
+ refsect1
+titleDescription/title
+paraIn this format there is no Y plane, Only CbCr plane. ie
+(UV interleaved)/para
+example
+title
+ constantV4L2_PIX_FMT_UV8/constant
+ pixel image
+/title
+
+formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+informaltable frame=none
+tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+row
+ entrystartnbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCrsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ entryCrsubscript01/subscript/entry
+/row
+row
+ entrystartnbsp;+nbsp;4:/entry
+ entryCbsubscript10/subscript/entry
+ entryCrsubscript10/subscript/entry
+ entryCbsubscript11/subscript/entry
+ entryCrsubscript11/subscript/entry
+/row
+row
+ entrystartnbsp;+nbsp;8:/entry
+ entryCbsubscript20/subscript/entry
+ entryCrsubscript20/subscript/entry
+ entryCbsubscript21/subscript/entry
+ entryCrsubscript21/subscript/entry
+/row
+row
+ entrystartnbsp;+nbsp;12:/entry
+ entryCbsubscript30/subscript/entry
+
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Le jeudi 2 août 2012 09:35:58 Hans Verkuil, vous avez écrit : On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote: What about using the CREATE_BUFS ioctl to add new MMAP buffers at runtime ? Does CREATE_BUFS always work while already streaming has already started? If it depends on the driver, it's kinda helpless. Yes, it does. It's one of the reasons it exists in the first place. But there are currently only a handful of drivers that implement it. I hope that as more and more drivers are converted to vb2 that the availability of create_bufs will increase. That's contradictory. If most drivers do not support it, then it won't work during streaming. What's the guaranteed minimum buffer count? It seems in any case, MMAP has a hard limit of 32 buffers (at least videobuf2 has), though one might argue this should be more than enough. Minimum or maximum? The maximum is 32, that's hardcoded in the V4L2 core. Although drivers may force a lower maximum if they want. I have no idea whether there are drivers that do that. There probably are. The smallest of the maxima of all drivers. The minimum is usually between 1 and 3, depending on hardware limitations. And that's clearly insufficient without memory copy to userspace buffers. It does not seem to me that CREATE_BUFS+MMAP is a useful replacement for REQBUFS+USERBUF then. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
On Thu August 2 2012 08:56:43 Rémi Denis-Courmont wrote: Le jeudi 2 août 2012 09:35:58 Hans Verkuil, vous avez écrit : On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote: What about using the CREATE_BUFS ioctl to add new MMAP buffers at runtime ? Does CREATE_BUFS always work while already streaming has already started? If it depends on the driver, it's kinda helpless. Yes, it does. It's one of the reasons it exists in the first place. But there are currently only a handful of drivers that implement it. I hope that as more and more drivers are converted to vb2 that the availability of create_bufs will increase. That's contradictory. If most drivers do not support it, then it won't work during streaming. IF create_bufs is implemented in the driver, THEN you can use it during streaming. I.e., it will never return EBUSY as an error due to the fact that streaming is in progress. Obviously it won't work if the driver didn't implement it in the first place. What's the guaranteed minimum buffer count? It seems in any case, MMAP has a hard limit of 32 buffers (at least videobuf2 has), though one might argue this should be more than enough. Minimum or maximum? The maximum is 32, that's hardcoded in the V4L2 core. Although drivers may force a lower maximum if they want. I have no idea whether there are drivers that do that. There probably are. The smallest of the maxima of all drivers. I've no idea. Most will probably abide by the 32 maximum, but without analyzing all drivers I can't guarantee it. The minimum is usually between 1 and 3, depending on hardware limitations. And that's clearly insufficient without memory copy to userspace buffers. It does not seem to me that CREATE_BUFS+MMAP is a useful replacement for REQBUFS+USERBUF then. Just to put your mind at rest: USERPTR mode will *not* disappear or be deprecated in any way. It's been there for a long time, it's in heavy use, it's easy to use and it will not be turned into a second class citizen, because it isn't. Just because there is a new dmabuf mode available doesn't mean that everything should be done as a mmap+dmabuf thing. 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: support for Elgato eyetv one
I just subcribed to maillinglist to comment that there is probably some misunderstanding about the Elgato EyeTV One: It is not a Mac-only product, it is also on the market for Windows. In the Netherlands, Elgato EyeTV One is the only product available for receiving TV Channels that are not free to air. In the Netherlands, only the national public television channels Nederland 1, Nederland 2, Nederland 3 and a regional public television channels are made available free-to-air. DVB-T transmissions in the Netherlands are provided commercially by KPN daughter company Digitenne. They offer 25 TV channels and 16 radio channels (which is growing). In order to receive the TV channels that are not free to air, a smartcard is needed. IMHO, Elgato EyeTV One is the only product on the Dutch market that is compatible with this smartcard. -- 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 0/1] media/video: vpif: fixing function name start to vpif_config_params
This patch address the issue that a function named config_vpif_params should be vpif_config_params. This, however, conflicts with two structures defined already. So I changed the structures to config_vpif_params_t (origin was vpif_config_params) Dror Cohen (1): fixing function name start to vpif_config_params drivers/media/video/davinci/vpif.c |6 +++--- drivers/media/video/davinci/vpif_capture.c |2 +- drivers/media/video/davinci/vpif_capture.h |2 +- drivers/media/video/davinci/vpif_display.c |2 +- drivers/media/video/davinci/vpif_display.h |2 +- 5 files changed, 7 insertions(+), 7 deletions(-) -- 1.7.5.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
[PATCH 1/1] media/video: vpif: fixing function name start to vpif_config_params
diff --git a/drivers/media/video/davinci/vpif.c
b/drivers/media/video/davinci/vpif.c
index af96802..04dd8fa 100644
--- a/drivers/media/video/davinci/vpif.c
+++ b/drivers/media/video/davinci/vpif.c
@@ -301,12 +301,12 @@ static void vpif_set_mode_info(const struct
vpif_channel_config_params *config,
regw(value, vpifregs[channel_id].v_cfg);
}
-/* config_vpif_params
+/* vpif_config_params
* Function to set the parameters of a channel
* Mainly modifies the channel ciontrol register
* It sets frame format, yc mux mode
*/
-static void config_vpif_params(struct vpif_params *vpifparams,
+static void vpif_config_params(struct vpif_params *vpifparams,
u8 channel_id, u8 found)
{
const struct vpif_channel_config_params *config = vpifparams-std_info;
@@ -374,7 +374,7 @@ int vpif_set_video_params(struct vpif_params *vpifparams,
u8 channel_id)
found = 2;
}
- config_vpif_params(vpifparams, channel_id, found);
+ vpif_config_params(vpifparams, channel_id, found);
regw(0x80, VPIF_REQ_SIZE);
regw(0x01, VPIF_EMULATION_CTRL);
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index 9604695..59104e6 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -67,7 +67,7 @@ MODULE_PARM_DESC(ch3_numbuffers, Channel1 buffer count
(default:3));
MODULE_PARM_DESC(ch2_bufsize, Channel0 buffer size (default:1920 x 1080 x
2));
MODULE_PARM_DESC(ch3_bufsize, Channel1 buffer size (default:720 x 576 x 2));
-static struct vpif_config_params config_params = {
+static struct config_vpif_params_t config_params = {
.min_numbuffers = 3,
.numbuffers[0] = 3,
.numbuffers[1] = 3,
diff --git a/drivers/media/video/davinci/vpif_capture.h
b/drivers/media/video/davinci/vpif_capture.h
index a693d4e..8863de1 100644
--- a/drivers/media/video/davinci/vpif_capture.h
+++ b/drivers/media/video/davinci/vpif_capture.h
@@ -144,7 +144,7 @@ struct vpif_device {
struct v4l2_subdev **sd;
};
-struct vpif_config_params {
+struct config_vpif_params_t {
u8 min_numbuffers;
u8 numbuffers[VPIF_CAPTURE_NUM_CHANNELS];
s8 device_type;
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index e6488ee..652440d 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -70,7 +70,7 @@ MODULE_PARM_DESC(ch3_numbuffers, Channel3 buffer count
(default:3));
MODULE_PARM_DESC(ch2_bufsize, Channel2 buffer size (default:1920 x 1080 x
2));
MODULE_PARM_DESC(ch3_bufsize, Channel3 buffer size (default:720 x 576 x 2));
-static struct vpif_config_params config_params = {
+static struct config_vpif_params_t config_params = {
.min_numbuffers = 3,
.numbuffers[0] = 3,
.numbuffers[1] = 3,
diff --git a/drivers/media/video/davinci/vpif_display.h
b/drivers/media/video/davinci/vpif_display.h
index 56879d1..3e14807 100644
--- a/drivers/media/video/davinci/vpif_display.h
+++ b/drivers/media/video/davinci/vpif_display.h
@@ -154,7 +154,7 @@ struct vpif_device {
};
-struct vpif_config_params {
+struct config_vpif_params_t {
u32 min_bufsize[VPIF_DISPLAY_NUM_CHANNELS];
u32 channel_bufsize[VPIF_DISPLAY_NUM_CHANNELS];
u8 numbuffers[VPIF_DISPLAY_NUM_CHANNELS];
--
1.7.5.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
[PATCH v8 0/2] add dm365 specific media formats
add mediabus formats and pixel formats supported as part of dm365 vpfe device. The device supports media formats(transfer and storage) which include- 1: ALAW compressed bayer. 2: UV interleaved without Y (for resizer). 3: YDYU Changes for v8: 1: Fixed a comment from Sakari, removed extra space. Changes for v7: 1: Fixed a comment from Laurent, removed subscript for dummy tags. 2: Fixed a comment from Sakari, used the same order for ALAW pix fmt according to Documentation/video4linux/4CCs.txt. Changes for v6: 1: Fixed a comment from Hans, replaced YUYDYDYV and YVYDYDYU to YUYDYVYD and YVYDYUYD. Changes for v5: 1: Fixed comment from Laurent, moved ALAW format above DPCM format to keep the alphabetically sorted, grouped textual description for ALAW and DPCM compression, as they're mutally exclusive, Changed V4L2_MBUS_FMT_YDYC8_1X16 to V4L2_MBUS_FMT_YDYUYDYV8_1X16. Changes for v4: 1: Rebased the patch set on Sakari's branch (http://git.linuxtv.org/sailus/media_tree.git/shortlog/refs/heads/media-for-3.4) mainly because of this patch URL:http://www.spinics.net/lists/linux-media/msg44871.html 2: Fixed comments from Sakari, changed description for UV8, and re-arranged sub-uv8; in Documentation/DocBook/media/v4l/pixfmt.xml file. Changes for v3: 1: Added 4cc code for A-law compressed format as per specified in documentation, http://www.spinics.net/lists/linux-media/msg43890.html Changes for v2: 1: Added entries in subdev-formats.xml for V4L2_MBUS_FMT_YDYC8_1X16, V4L2_MBUS_FMT_UV8_1X8, V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8, V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8, V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8, V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8. 2: Added documentation of ALAW and UV8 pix format. Manjunath Hadli (2): media: add new mediabus format enums for dm365 v4l2: add new pixel formats supported on dm365 .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++ Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62 + Documentation/DocBook/media/v4l/pixfmt.xml |2 + Documentation/DocBook/media/v4l/subdev-formats.xml | 250 +++- include/linux/v4l2-mediabus.h | 10 +- include/linux/videodev2.h |8 + 6 files changed, 358 insertions(+), 8 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml -- 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 v8 1/2] media: add new mediabus format enums for dm365
From: Manjunath Hadli manjunath.ha...@ti.com add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Acked-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Signed-off-by: Lad, Prabhakar prabhakar@ti.com Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Documentation/DocBook/media/v4l/subdev-formats.xml | 250 +++- include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 252 insertions(+), 8 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..75dc275 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -353,9 +353,9 @@ listitemparaThe number of bits per pixel component. All components are transferred on the same number of bits. Common values are 8, 10 and 12./para /listitem - listitemparaIf the pixel components are DPCM-compressed, a mention of the - DPCM compression and the number of bits per compressed pixel component./para - /listitem + listitemparaThe compression (optional). If the pixel components are + ALAW- or DPCM-compressed, a mention of the compression scheme and the + number of bits per compressed pixel component./para/listitem listitemparaThe number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are 1 and 2./para/listitem @@ -504,6 +504,74 @@ entryrsubscript1/subscript/entry entryrsubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SBGGR10_ALAW8_1X8/entry + entry0x3015/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrybsubscript7/subscript/entry + entrybsubscript6/subscript/entry + entrybsubscript5/subscript/entry + entrybsubscript4/subscript/entry + entrybsubscript3/subscript/entry + entrybsubscript2/subscript/entry + entrybsubscript1/subscript/entry + entrybsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGBRG10_ALAW8_1X8/entry + entry0x3016/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGRBG10_ALAW8_1X8/entry + entry0x3017/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SRGGB10_ALAW8_1X8/entry + entry0x3018/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entryrsubscript7/subscript/entry + entryrsubscript6/subscript/entry + entryrsubscript5/subscript/entry + entryrsubscript4/subscript/entry + entryrsubscript3/subscript/entry + entryrsubscript2/subscript/entry + entryrsubscript1/subscript/entry + entryrsubscript0/subscript/entry + /row row id=V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8 entryV4L2_MBUS_FMT_SBGGR10_DPCM8_1X8/entry entry0x300b/entry @@ -853,10 +921,16 @@ titlePacked YUV Formats/title paraThose data formats transfer pixel
[PATCH v8 2/2] v4l2: add new pixel formats supported on dm365
From: Manjunath Hadli manjunath.ha...@ti.com
add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats
to represent Bayer format frames compressed by A-LAW algorithm,
add V4L2_PIX_FMT_UV8 to represent storage of CbCr data (UV interleaved)
only.
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
.../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++
Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62
Documentation/DocBook/media/v4l/pixfmt.xml |2 +
include/linux/videodev2.h |8 +++
4 files changed, 106 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
new file mode 100644
index 000..c934192
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
@@ -0,0 +1,34 @@
+ refentry
+ refmeta
+ refentrytitle
+ V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
+ V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
+ V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
+ V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
+ /refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname id=V4L2-PIX-FMT-SBGGR10ALAW8
+ constantV4L2_PIX_FMT_SBGGR10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SGBRG10ALAW8
+ constantV4L2_PIX_FMT_SGBRG10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SGRBG10ALAW8
+ constantV4L2_PIX_FMT_SGRBG10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SRGGB10ALAW8
+ constantV4L2_PIX_FMT_SRGGB10ALAW8/constant
+ /refname
+ refpurpose10-bit Bayer formats compressed to 8 bits/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+ paraThe following four pixel formats are raw sRGB / Bayer
+ formats with 10 bits per color compressed to 8 bits each,
+ using the A-LAW algorithm. Each color component consumes 8
+ bits of memory. In other respects this format is similar to
+ xref linkend=V4L2-PIX-FMT-SRGGB8./xref/para
+ /refsect1
+ /refentry
diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
new file mode 100644
index 000..c507c1f
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
@@ -0,0 +1,62 @@
+ refentry id=V4L2-PIX-FMT-UV8
+ refmeta
+ refentrytitleV4L2_PIX_FMT_UV8 ('UV8')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refnameconstantV4L2_PIX_FMT_UV8/constant/refname
+ refpurposeUV plane interleaved/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+ paraIn this format there is no Y plane, Only CbCr plane. ie
+ (UV interleaved)/para
+ example
+ title
+ constantV4L2_PIX_FMT_UV8/constant
+ pixel image
+ /title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystartnbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCrsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ entryCrsubscript01/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;4:/entry
+ entryCbsubscript10/subscript/entry
+ entryCrsubscript10/subscript/entry
+ entryCbsubscript11/subscript/entry
+ entryCrsubscript11/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;8:/entry
+ entryCbsubscript20/subscript/entry
+ entryCrsubscript20/subscript/entry
+ entryCbsubscript21/subscript/entry
+ entryCrsubscript21/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;12:/entry
+ entryCbsubscript30/subscript/entry
+ entryCrsubscript30/subscript/entry
+
Re: [Ksummit-2012-discuss] [MINI SUMMIT] media mini-summit at KS/2012
At Wed, 01 Aug 2012 16:17:07 -0300, Mauro Carvalho Chehab wrote: After the discussions around the media mini-summit, this is the consolidated list of topics. We tried to give a fair time for each topic. With regards to the proposed topic Intel media SDK, nobody volunteered to give such a talk. So, if there is anyone interested to talk about it, it can either be part of SoC vendor's feedback (if it won't take too long), or it could be handled as a topic during LPC. So, let's put this one in the fridge. Topics for the media mini-summit - morning: V4L2 API ambiguities + v4l2 compliance tool: 60 min Media Controller library: 30 min ALSA and V4L/Media Controller: 30 min ARM and needed features for V4L/DVB: 30 min - after lunch: SoC Vendors feedback – how to help them to go upstream: 45 min V4L2/DVB issues from userspace perspective: 45 min Android's V4L2 cam library: 30 min HDMI CEC: 30 min Synchronization, shared resource and optimizations: 30 min The DT discussions will likely require more time and maybe a different audience. So, it seems better to handle it as either as a separate/LPC section or at DT mini-summit: Common device tree bindings for media devices: 45 min Attendants == Guennadi Liakhovetski g.liakhovet...@gmx.de Hans Verkuil hans.verk...@xs4all.nl Laurent Pinchart laurent.pinch...@ideasonboard.com Mauro Carvalho Chehab mche...@redhat.com Michael Krufky mkru...@linuxtv.org Naveen Krishnamurthy naveen.krishnamur...@st.com Palash Bandyopadhyay palash.bandyopadh...@conexant.com Pawel Osciak pa...@osciak.com Rémi Denis-Courmont r...@remlab.net Sakari Ailus sakari.ai...@iki.fi Sri Deevi srinivasa.de...@conexant.com Steven Toth st...@kernellabs.com Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Marek Szyprowski m.szyprow...@samsung.com Kamil Debski k.deb...@samsung.com Naveen also asked another seat for ST, but didn't provide us yet the name of the other interested party. For the cross-system topics, it is important to have people from the other subsystems there. So, we're proposing to have some people there, but we need to double-check if they can really be there for the discussions. Of course, other Kernel developers from KS/LPC that work on those subsystems are welcome. The names that came up during our discussions for those panels are: Rob Clark rob.cl...@linaro.org (HDMI CEC, ALSA, ARM) Takashi Iwai ti...@suse.de (ALSA) Catalin Marinas catalin.mari...@arm.com (ARM) Mark Brown broo...@opensource.wolfsonmicro.com (DT) Not sure if they all will be there or if they'll have some time to discuss those things with us. We hope they will ;) I'll have a talk at Gstreamer conference on Tuesday afternoon, so I can't attend the conflicting slots, but other than that, I'll be likely available (e.g. before lunch). thanks, Takashi Thanks, Mauro Carvalho Chehab Hans Verkuil ___ Ksummit-2012-discuss mailing list ksummit-2012-disc...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/ksummit-2012-discuss -- 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 v8 2/2] v4l2: add new pixel formats supported on dm365
Hi Prabhakar, Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats to represent Bayer format frames compressed by A-LAW algorithm, add V4L2_PIX_FMT_UV8 to represent storage of CbCr data (UV interleaved) only. Acked-by: Sakari Ailus sakari.ai...@iki.fi -- Sakari Ailus sakari.ai...@iki.fi -- 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 v2] mt9v022: Add support for mt9v024
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/mt9v022.c | 45
2 files changed, 37 insertions(+), 10 deletions(-)
Changes for v2:
Fixed comment from Guennadi.
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index c128fac..3ce905c 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1058,7 +1058,7 @@ config SOC_CAMERA_MT9T112
This driver supports MT9T112 cameras from Aptina.
config SOC_CAMERA_MT9V022
- tristate mt9v022 support
+ tristate mt9v022 and mt9v024 support
depends on SOC_CAMERA I2C
select GPIO_PCA953X if MT9V022_PCA9536_SWITCH
help
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index 7247924..d46727b 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -57,6 +57,10 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or
\monochrome\);
#define MT9V022_AEC_AGC_ENABLE 0xAF
#define MT9V022_MAX_TOTAL_SHUTTER_WIDTH0xBD
+/* mt9v024 partial list register addresses changes with respect to mt9v022 */
+#define MT9V024_PIXCLK_FV_LV 0x72
+#define MT9V024_MAX_TOTAL_SHUTTER_WIDTH0xAD
+
/* Progressive scan, master, defaults */
#define MT9V022_CHIP_CONTROL_DEFAULT 0x188
@@ -67,6 +71,8 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or
\monochrome\);
#define MT9V022_COLUMN_SKIP1
#define MT9V022_ROW_SKIP 4
+#define is_mt9v024(p) (p-chip_id == 0x1324)
+
/* MT9V022 has only one fixed colorspace per pixelcode */
struct mt9v022_datafmt {
enum v4l2_mbus_pixelcodecode;
@@ -101,6 +107,22 @@ static const struct mt9v022_datafmt
mt9v022_monochrome_fmts[] = {
{V4L2_MBUS_FMT_Y8_1X8, V4L2_COLORSPACE_JPEG},
};
+/* only registers with different addresses on different mt9v02x sensors */
+struct mt9v02x_register {
+ u8 max_total_shutter_width;
+ u8 pixclk_fv_lv;
+};
+
+static const struct mt9v02x_register mt9v022_register = {
+ .max_total_shutter_width= MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
+ .pixclk_fv_lv = MT9V022_PIXCLK_FV_LV,
+};
+
+static const struct mt9v02x_register mt9v024_register = {
+ .max_total_shutter_width= MT9V024_MAX_TOTAL_SHUTTER_WIDTH,
+ .pixclk_fv_lv = MT9V024_PIXCLK_FV_LV,
+};
+
struct mt9v022 {
struct v4l2_subdev subdev;
struct v4l2_ctrl_handler hdl;
@@ -117,10 +139,12 @@ struct mt9v022 {
struct v4l2_rect rect; /* Sensor window */
const struct mt9v022_datafmt *fmt;
const struct mt9v022_datafmt *fmts;
+ const struct mt9v02x_register *reg;
int num_fmts;
int model; /* V4L2_IDENT_MT9V022* codes from v4l2-chip-ident.h */
u16 chip_control;
unsigned short y_skip_top; /* Lines to skip at the top */
+ s32 chip_id;
};
static struct mt9v022 *to_mt9v022(const struct i2c_client *client)
@@ -185,7 +209,7 @@ static int mt9v022_init(struct i2c_client *client)
if (!ret)
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH, 480);
if (!ret)
- ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH, 480);
+ ret = reg_write(client, mt9v022-reg-max_total_shutter_width,
480);
if (!ret)
/* default - auto */
ret = reg_clear(client, MT9V022_BLACK_LEVEL_CALIB_CTRL, 1);
@@ -238,7 +262,7 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
ret = reg_read(client, MT9V022_AEC_AGC_ENABLE);
if (ret = 0) {
if (ret 1) /* Autoexposure */
- ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
+ ret = reg_write(client,
mt9v022-reg-max_total_shutter_width,
rect.height + mt9v022-y_skip_top + 43);
else
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH,
@@ -566,21 +590,24 @@ static int mt9v022_video_probe(struct i2c_client *client)
{
struct mt9v022 *mt9v022 = to_mt9v022(client);
struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
- s32 data;
int ret;
unsigned long flags;
/* Read out the chip version register */
- data = reg_read(client, MT9V022_CHIP_VERSION);
+ mt9v022-chip_id = reg_read(client, MT9V022_CHIP_VERSION);
- /* must be 0x1311 or 0x1313 */
- if (data != 0x1311 data != 0x1313) {
+ /* must be 0x1311, 0x1313 or 0x1324 */
+ if (mt9v022-chip_id != 0x1311 mt9v022-chip_id != 0x1313
+ mt9v022-chip_id != 0x1324) {
ret = -ENODEV;
dev_info(client-dev, No MT9V022 found, ID register 0x%x\n,
-data);
+
Re: 3.5 kernel options for Hauppauge_WinTV-HVR-1250
James bjloc...@lockie.ca wrote:
On 08/01/12 07:07, Andy Walls wrote:
James bjloc...@lockie.ca wrote:
I got the latest kernel from git and I can't find the kernel options
for my tv card.
I have: http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1250
--
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
/sbin/modinfo cx23885
Regards,
Andy
I don't build any modules.
In case anyone else has trouble getting to work (the kernel makes
options invisible unless dependencies are met).
1. Turn on expert mode (to be able to select frontends to build).
General setup/Configure standard kernel features (expert users)
2. Device Drivers/Multimedia support
3. Analog TV support
4. Digital TV support
5. Remote Controller support
6. Customize analog and hybrid tuner modules to build
Customize TV tuners --- Microtune MT2131 silicon tuner
7. V4L PCI(e) devices/Conexant cx23885 (2388x successor) support
8. DVB/ATSC adapters --- Customise the frontend modules to
build/Customise DVB Frontends/Samsung S5H1409 based
I think that is it but I did other stuff so I may be missing a step or
2.
Can I make the make menuconfig show all the options an when I select
something, it selects all the dependencies?
--
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
No, the Kconfig system can't help.
You can 'grep MODULE_ drivers/media/video/cx23885/*
drivers/media/video/cx25840/* ' and other relevant directories under
drivers/media/{dvb, common} to find all the parameter options for all the
drivers involved in making a HVR_1250 work.
Regards,
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 v2] mt9v022: Add support for mt9v024
Hi Alex
Yes, this looks much better to me now. Still, I'd like to ask you to
make a couple more changes. First - there are different opinions about how
really important a patch description is, whether there are at all cases,
when an empty description is acceptable. I do sometimes myself provide no
description and accept the same from others, but only in really trivial
cases, where the single patch subject line perfectly tells it all.
However, I don't think this is the case here. It would be nice to have a
couple of words in the patch description, saying, that mt9v024 is a
camera sensor, very similar to mt9v022 with just a few differences, namely
its sensor matrix size is now ... instead of ..., some register locations
have changed,...
While at it, please, also change one more thing. Yes, it was my request to
move chip_id into the private struct, but now with the addition of struct
mt9v02x_register it is not needed anymore. The chip_id is only used in
the probe function, so, you don't have to save it. Please, if I'm not
mistaken and I haven't missed some additional uses of chip_id, remove it
again and just leave the local data variable without change.
Respectively, your is_mt9v024 macro will change to
#define is_mt9v024(id) (id == 0x1324)
Thanks
Guennadi
On Thu, 2 Aug 2012, Alex Gershgorin wrote:
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/mt9v022.c | 45
2 files changed, 37 insertions(+), 10 deletions(-)
Changes for v2:
Fixed comment from Guennadi.
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index c128fac..3ce905c 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1058,7 +1058,7 @@ config SOC_CAMERA_MT9T112
This driver supports MT9T112 cameras from Aptina.
config SOC_CAMERA_MT9V022
- tristate mt9v022 support
+ tristate mt9v022 and mt9v024 support
depends on SOC_CAMERA I2C
select GPIO_PCA953X if MT9V022_PCA9536_SWITCH
help
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index 7247924..d46727b 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -57,6 +57,10 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or
\monochrome\);
#define MT9V022_AEC_AGC_ENABLE 0xAF
#define MT9V022_MAX_TOTAL_SHUTTER_WIDTH 0xBD
+/* mt9v024 partial list register addresses changes with respect to mt9v022 */
+#define MT9V024_PIXCLK_FV_LV 0x72
+#define MT9V024_MAX_TOTAL_SHUTTER_WIDTH 0xAD
+
/* Progressive scan, master, defaults */
#define MT9V022_CHIP_CONTROL_DEFAULT 0x188
@@ -67,6 +71,8 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or
\monochrome\);
#define MT9V022_COLUMN_SKIP 1
#define MT9V022_ROW_SKIP 4
+#define is_mt9v024(p) (p-chip_id == 0x1324)
+
/* MT9V022 has only one fixed colorspace per pixelcode */
struct mt9v022_datafmt {
enum v4l2_mbus_pixelcodecode;
@@ -101,6 +107,22 @@ static const struct mt9v022_datafmt
mt9v022_monochrome_fmts[] = {
{V4L2_MBUS_FMT_Y8_1X8, V4L2_COLORSPACE_JPEG},
};
+/* only registers with different addresses on different mt9v02x sensors */
+struct mt9v02x_register {
+ u8 max_total_shutter_width;
+ u8 pixclk_fv_lv;
+};
+
+static const struct mt9v02x_register mt9v022_register = {
+ .max_total_shutter_width= MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
+ .pixclk_fv_lv = MT9V022_PIXCLK_FV_LV,
+};
+
+static const struct mt9v02x_register mt9v024_register = {
+ .max_total_shutter_width= MT9V024_MAX_TOTAL_SHUTTER_WIDTH,
+ .pixclk_fv_lv = MT9V024_PIXCLK_FV_LV,
+};
+
struct mt9v022 {
struct v4l2_subdev subdev;
struct v4l2_ctrl_handler hdl;
@@ -117,10 +139,12 @@ struct mt9v022 {
struct v4l2_rect rect; /* Sensor window */
const struct mt9v022_datafmt *fmt;
const struct mt9v022_datafmt *fmts;
+ const struct mt9v02x_register *reg;
int num_fmts;
int model; /* V4L2_IDENT_MT9V022* codes from v4l2-chip-ident.h */
u16 chip_control;
unsigned short y_skip_top; /* Lines to skip at the top */
+ s32 chip_id;
};
static struct mt9v022 *to_mt9v022(const struct i2c_client *client)
@@ -185,7 +209,7 @@ static int mt9v022_init(struct i2c_client *client)
if (!ret)
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH, 480);
if (!ret)
- ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH, 480);
+ ret = reg_write(client, mt9v022-reg-max_total_shutter_width,
480);
if (!ret)
/* default - auto */
ret = reg_clear(client, MT9V022_BLACK_LEVEL_CALIB_CTRL, 1);
@@ -238,7 +262,7 @@ static int mt9v022_s_crop(struct
Re: [PATCH 1/1] media/video: vpif: fixing function name start to vpif_config_params
Hello.
On 02-08-2012 11:40, Dror Cohen wrote:
diff --git a/drivers/media/video/davinci/vpif_capture.h
b/drivers/media/video/davinci/vpif_capture.h
index a693d4e..8863de1 100644
--- a/drivers/media/video/davinci/vpif_capture.h
+++ b/drivers/media/video/davinci/vpif_capture.h
@@ -144,7 +144,7 @@ struct vpif_device {
struct v4l2_subdev **sd;
};
-struct vpif_config_params {
+struct config_vpif_params_t {
IMO, '_t' postfix is used only for *typedef* names.
diff --git a/drivers/media/video/davinci/vpif_display.h
b/drivers/media/video/davinci/vpif_display.h
index 56879d1..3e14807 100644
--- a/drivers/media/video/davinci/vpif_display.h
+++ b/drivers/media/video/davinci/vpif_display.h
@@ -154,7 +154,7 @@ struct vpif_device {
};
-struct vpif_config_params {
+struct config_vpif_params_t {
Same comment.
WBR, Sergei
--
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 0/1] media/video: vpif: fixing function name start to vpif_config_params
Hello. On 02-08-2012 11:40, Dror Cohen wrote: This patch address the issue that a function named config_vpif_params should be vpif_config_params. This, however, conflicts with two structures defined already. Function names shouldn't conflict with the structure tags. Structure tags always follow 'struct' keyword and are only valid in this context. So I changed the structures to config_vpif_params_t (origin was vpif_config_params) WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] mt9v022: Add support for mt9v024
Hi Guennadi,
Thank you for your very detailed comment.
Hi Alex
Yes, this looks much better to me now. Still, I'd like to ask you to
make a couple more changes. First - there are different opinions about how
really important a patch description is, whether there are at all cases,
when an empty description is acceptable. I do sometimes myself provide no
description and accept the same from others, but only in really trivial
cases, where the single patch subject line perfectly tells it all.
However, I don't think this is the case here. It would be nice to have a
couple of words in the patch description, saying, that mt9v024 is a
camera sensor, very similar to mt9v022 with just a few differences, namely
its sensor matrix size is now ... instead of ..., some register locations
have changed,...
No problem, I'll add descriptions.
While at it, please, also change one more thing. Yes, it was my request to
move chip_id into the private struct, but now with the addition of struct
mt9v02x_register it is not needed anymore. The chip_id is only used in
the probe function, so, you don't have to save it. Please, if I'm not
mistaken and I haven't missed some additional uses of chip_id, remove it
again and just leave the local data variable without change.
Respectively, your is_mt9v024 macro will change to
#define is_mt9v024(id) (id == 0x1324)
I only have a few doubts about this:
mt9v024 camera sensor has about 20 additional registers that are not supported
in mt9v022 camera sensor.
What should be happened if someone wants to add this registers?
I guess, that in this case we will need to use the chip_id outside of the probe
function.
What do you think?
Regards,
Alex
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/mt9v022.c | 45
2 files changed, 37 insertions(+), 10 deletions(-)
Changes for v2:
Fixed comment from Guennadi.
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index c128fac..3ce905c 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1058,7 +1058,7 @@ config SOC_CAMERA_MT9T112
This driver supports MT9T112 cameras from Aptina.
config SOC_CAMERA_MT9V022
- tristate mt9v022 support
+ tristate mt9v022 and mt9v024 support
depends on SOC_CAMERA I2C
select GPIO_PCA953X if MT9V022_PCA9536_SWITCH
help
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index 7247924..d46727b 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -57,6 +57,10 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or
\monochrome\);
#define MT9V022_AEC_AGC_ENABLE 0xAF
#define MT9V022_MAX_TOTAL_SHUTTER_WIDTH 0xBD
+/* mt9v024 partial list register addresses changes with respect to mt9v022 */
+#define MT9V024_PIXCLK_FV_LV 0x72
+#define MT9V024_MAX_TOTAL_SHUTTER_WIDTH 0xAD
+
/* Progressive scan, master, defaults */
#define MT9V022_CHIP_CONTROL_DEFAULT 0x188
@@ -67,6 +71,8 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or
\monochrome\);
#define MT9V022_COLUMN_SKIP 1
#define MT9V022_ROW_SKIP 4
+#define is_mt9v024(p) (p-chip_id == 0x1324)
+
/* MT9V022 has only one fixed colorspace per pixelcode */
struct mt9v022_datafmt {
enum v4l2_mbus_pixelcodecode;
@@ -101,6 +107,22 @@ static const struct mt9v022_datafmt
mt9v022_monochrome_fmts[] = {
{V4L2_MBUS_FMT_Y8_1X8, V4L2_COLORSPACE_JPEG},
};
+/* only registers with different addresses on different mt9v02x sensors */
+struct mt9v02x_register {
+ u8 max_total_shutter_width;
+ u8 pixclk_fv_lv;
+};
+
+static const struct mt9v02x_register mt9v022_register = {
+ .max_total_shutter_width= MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
+ .pixclk_fv_lv = MT9V022_PIXCLK_FV_LV,
+};
+
+static const struct mt9v02x_register mt9v024_register = {
+ .max_total_shutter_width= MT9V024_MAX_TOTAL_SHUTTER_WIDTH,
+ .pixclk_fv_lv = MT9V024_PIXCLK_FV_LV,
+};
+
struct mt9v022 {
struct v4l2_subdev subdev;
struct v4l2_ctrl_handler hdl;
@@ -117,10 +139,12 @@ struct mt9v022 {
struct v4l2_rect rect; /* Sensor window */
const struct mt9v022_datafmt *fmt;
const struct mt9v022_datafmt *fmts;
+ const struct mt9v02x_register *reg;
int num_fmts;
int model; /* V4L2_IDENT_MT9V022* codes from v4l2-chip-ident.h */
u16 chip_control;
unsigned short y_skip_top; /* Lines to skip at the top */
+ s32 chip_id;
};
static struct mt9v022 *to_mt9v022(const struct i2c_client *client)
@@ -185,7 +209,7 @@ static int mt9v022_init(struct i2c_client *client)
if (!ret)
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH, 480);
if
s5p-fimc capturing interlaced BT656
Hi All, I'm using the S5PV210 camera IF and capturing BT656 video from a TVP5150 video decoder. I notice that the capture driver ignores the field interlace flags reported by the 'sensor' and always uses 'V4L2_FIELD_NONE'. It also seems each field ends up in it's own frame, using only half the height. What would need to be done to store both fields in a single frame, for example in a V4L2_FIELD_INTERLACE_TB/BT format? Cheers, Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] mt9v022: Add support for mt9v024
Hi Alex
On Thu, 2 Aug 2012, Alex Gershgorin wrote:
Hi Guennadi,
Thank you for your very detailed comment.
Hi Alex
Yes, this looks much better to me now. Still, I'd like to ask you to
make a couple more changes. First - there are different opinions about how
really important a patch description is, whether there are at all cases,
when an empty description is acceptable. I do sometimes myself provide no
description and accept the same from others, but only in really trivial
cases, where the single patch subject line perfectly tells it all.
However, I don't think this is the case here. It would be nice to have a
couple of words in the patch description, saying, that mt9v024 is a
camera sensor, very similar to mt9v022 with just a few differences, namely
its sensor matrix size is now ... instead of ..., some register locations
have changed,...
No problem, I'll add descriptions.
While at it, please, also change one more thing. Yes, it was my request to
move chip_id into the private struct, but now with the addition of struct
mt9v02x_register it is not needed anymore. The chip_id is only used in
the probe function, so, you don't have to save it. Please, if I'm not
mistaken and I haven't missed some additional uses of chip_id, remove it
again and just leave the local data variable without change.
Respectively, your is_mt9v024 macro will change to
#define is_mt9v024(id) (id == 0x1324)
I only have a few doubts about this:
mt9v024 camera sensor has about 20 additional registers that are not
supported in mt9v022 camera sensor.
I see...
What should be happened if someone wants to add this registers?
I guess, that in this case we will need to use the chip_id outside of the
probe function.
What do you think?
Well, this can of course happen. But I think, it is better to add code
when it is really needed, then try to guess in advance. If we had to
decide between two alternative modifications to the code, then yes, taking
into account possible future extensions might make sense. Whereas, when
deciding between no-modification and a modification, that might be useful
in the future, I think, the former is a safer bet.
Thanks
Guennadi
Regards,
Alex
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/mt9v022.c | 45
2 files changed, 37 insertions(+), 10 deletions(-)
Changes for v2:
Fixed comment from Guennadi.
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index c128fac..3ce905c 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1058,7 +1058,7 @@ config SOC_CAMERA_MT9T112
This driver supports MT9T112 cameras from Aptina.
config SOC_CAMERA_MT9V022
- tristate mt9v022 support
+ tristate mt9v022 and mt9v024 support
depends on SOC_CAMERA I2C
select GPIO_PCA953X if MT9V022_PCA9536_SWITCH
help
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index 7247924..d46727b 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -57,6 +57,10 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\
or \monochrome\);
#define MT9V022_AEC_AGC_ENABLE 0xAF
#define MT9V022_MAX_TOTAL_SHUTTER_WIDTH 0xBD
+/* mt9v024 partial list register addresses changes with respect to mt9v022
*/
+#define MT9V024_PIXCLK_FV_LV 0x72
+#define MT9V024_MAX_TOTAL_SHUTTER_WIDTH 0xAD
+
/* Progressive scan, master, defaults */
#define MT9V022_CHIP_CONTROL_DEFAULT 0x188
@@ -67,6 +71,8 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or
\monochrome\);
#define MT9V022_COLUMN_SKIP 1
#define MT9V022_ROW_SKIP 4
+#define is_mt9v024(p) (p-chip_id == 0x1324)
+
/* MT9V022 has only one fixed colorspace per pixelcode */
struct mt9v022_datafmt {
enum v4l2_mbus_pixelcodecode;
@@ -101,6 +107,22 @@ static const struct mt9v022_datafmt
mt9v022_monochrome_fmts[] = {
{V4L2_MBUS_FMT_Y8_1X8, V4L2_COLORSPACE_JPEG},
};
+/* only registers with different addresses on different mt9v02x sensors */
+struct mt9v02x_register {
+ u8 max_total_shutter_width;
+ u8 pixclk_fv_lv;
+};
+
+static const struct mt9v02x_register mt9v022_register = {
+ .max_total_shutter_width= MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
+ .pixclk_fv_lv = MT9V022_PIXCLK_FV_LV,
+};
+
+static const struct mt9v02x_register mt9v024_register = {
+ .max_total_shutter_width= MT9V024_MAX_TOTAL_SHUTTER_WIDTH,
+ .pixclk_fv_lv = MT9V024_PIXCLK_FV_LV,
+};
+
struct mt9v022 {
struct v4l2_subdev subdev;
struct v4l2_ctrl_handler hdl;
@@ -117,10 +139,12 @@ struct mt9v022 {
struct
[PATH v3 0/2] Add v4l2 subdev driver for S5K4ECGX sensor with embedded SoC ISP
The following 2 patches add driver for S5K4ECGX sensor with embedded ISP SoC, and minor v4l2 control API enhancement. S5K4ECGX is 5M CMOS Image sensor from Samsung Changes since v2: - added GPIO (reset/stby) and regulators - updated I2C read/write, based on s5k6aa datasheet - fixed set_fmt errors - reduced register tables a bit - removed vmalloc Changes since v1: - fixed s_stream(0) when it called twice - changed mutex_X position to be used when strictly necessary - add additional s_power(0) in case that error happens - update more accurate debugging statements - remove dummy else Sangwook Lee (2): v4l: Add factory register values form S5K4ECGX sensor v4l: Add v4l2 subdev driver for S5K4ECGX sensor drivers/media/video/Kconfig |8 + drivers/media/video/Makefile|1 + drivers/media/video/s5k4ecgx.c | 839 ++ drivers/media/video/s5k4ecgx_regs.h | 3105 +++ include/media/s5k4ecgx.h| 39 + 5 files changed, 3992 insertions(+) create mode 100644 drivers/media/video/s5k4ecgx.c create mode 100644 drivers/media/video/s5k4ecgx_regs.h create mode 100644 include/media/s5k4ecgx.h -- 1.7.9.5 -- 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
[PATH v3 2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor
This driver implements preview mode of the S5K4ECGX sensor.
capture (snapshot) operation, face detection are missing now.
Following controls are supported:
contrast/saturation/brightness/sharpness
Signed-off-by: Sangwook Lee sangwook@linaro.org
---
drivers/media/video/Kconfig|8 +
drivers/media/video/Makefile |1 +
drivers/media/video/s5k4ecgx.c | 839
include/media/s5k4ecgx.h | 39 ++
4 files changed, 887 insertions(+)
create mode 100644 drivers/media/video/s5k4ecgx.c
create mode 100644 include/media/s5k4ecgx.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index c128fac..2c3f434 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -580,6 +580,14 @@ config VIDEO_S5K6AA
This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M
camera sensor with an embedded SoC image signal processor.
+config VIDEO_S5K4ECGX
+tristate Samsung S5K4ECGX sensor support
+ depends on MEDIA_CAMERA_SUPPORT
+depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API
+---help---
+ This is a V4L2 sensor-level driver for Samsung S5K4ECGX 5M
+ camera sensor with an embedded SoC image signal processor.
+
source drivers/media/video/smiapp/Kconfig
comment Flash devices
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index b7da9fa..ec39c47 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -80,6 +80,7 @@ obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o
+obj-$(CONFIG_VIDEO_S5K4ECGX)+= s5k4ecgx.o
obj-$(CONFIG_VIDEO_SMIAPP) += smiapp/
obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o
obj-$(CONFIG_VIDEO_AS3645A)+= as3645a.o
diff --git a/drivers/media/video/s5k4ecgx.c b/drivers/media/video/s5k4ecgx.c
new file mode 100644
index 000..cfc90b8
--- /dev/null
+++ b/drivers/media/video/s5k4ecgx.c
@@ -0,0 +1,839 @@
+/*
+ * Driver for s5k4ecgx (5MP Camera) from Samsung
+ * a quarter-inch optical format 1.4 micron 5 megapixel (Mp)
+ * CMOS image sensor.
+ *
+ * Copyright (C) 2012, Linaro, Sangwook Lee sangwook@linaro.org
+ * Copyright (C) 2012, Insignal Co,. Ltd, Homin Lee suap...@insignal.co.kr
+ *
+ * Based on s5k6aa, noon010pc30 driver
+ * Copyright (C) 2011, Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/module.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include linux/vmalloc.h
+
+#include media/media-entity.h
+#include media/s5k4ecgx.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+#include media/v4l2-mediabus.h
+#include media/v4l2-subdev.h
+
+#include s5k4ecgx_regs.h
+
+static int debug;
+module_param(debug, int, 0644);
+
+#define S5K4ECGX_DRIVER_NAME s5k4ecgx
+
+/* Firmware revision information */
+#define REG_FW_REVISION0x71a6
+#define REG_FW_VERSION 0x71a4
+#define S5K4ECGX_REVISION_1_1 0x11
+#define S5K4ECGX_FW_VERSION0x4ec0
+
+/* General purpose parameters */
+#define REG_USER_BRIGHTNESS0x722c /* Brigthness */
+#define REG_USER_CONTRAST 0x722e /* Contrast */
+#define REG_USER_SATURATION0x7230 /* Saturation */
+
+#define REG_USER_SHARP10x7a28
+#define REG_USER_SHARP20x7ade
+#define REG_USER_SHARP30x7b94
+#define REG_USER_SHARP40x7c4a
+#define REG_USER_SHARP50x7d00
+
+/* Reduce sharpness range for user space API */
+#define SHARPNESS_DIV 8208
+
+#define TOK_TERM 0x
+
+/*
+ * FIMXE: This is copied from s5k6aa, because of no information
+ * in s5k4ecgx's datasheet
+ * H/W register Interface (0xd000 - 0xdfff)
+ */
+#define AHB_MSB_ADDR_PTR 0xfcfc
+#define GEN_REG_OFFSH 0xd000
+#define REG_CMDWR_ADDRH0x0028
+#define REG_CMDWR_ADDRL0x002a
+#define REG_CMDRD_ADDRH0x002c
+#define REG_CMDRD_ADDRL0x002e
+#define REG_CMDBUF0_ADDR 0x0f12
+
+/*
+ * Preview size lists supported by sensor
+ */
+static const struct regval_list *prev_regs[] = {
+ s5k4ecgx_176_preview,
+ s5k4ecgx_352_preview,
+ s5k4ecgx_640_preview,
+ s5k4ecgx_720_preview,
+};
+
+struct s5k4ecgx_frmsize {
+ u32 idx; /* Should
Re: support for Elgato eyetv one
On Thu, Aug 2, 2012 at 3:33 AM, Dutchdude pimkanteb...@gmail.com wrote: I just subcribed to maillinglist to comment that there is probably some misunderstanding about the Elgato EyeTV One: It is not a Mac-only product, it is also on the market for Windows. In the Netherlands, Elgato EyeTV One is the only product available for receiving TV Channels that are not free to air. In the Netherlands, only the national public television channels Nederland 1, Nederland 2, Nederland 3 and a regional public television channels are made available free-to-air. DVB-T transmissions in the Netherlands are provided commercially by KPN daughter company Digitenne. They offer 25 TV channels and 16 radio channels (which is growing). In order to receive the TV channels that are not free to air, a smartcard is needed. IMHO, Elgato EyeTV One is the only product on the Dutch market that is compatible with this smartcard. Bear in mind that this may not actually be the same product. Many of these vendors release multiple products with the same name. Hence the EyeTV One sold in the Netherlands may be different than the one that started this thread. This is especially likely since your product has a smartcard reader (and I don't think Tim's product does). 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
Re: 3.5 kernel options for Hauppauge_WinTV-HVR-1250
On Thu, Aug 2, 2012 at 5:53 AM, Andy Walls awa...@md.metrocast.net wrote:
You can 'grep MODULE_ drivers/media/video/cx23885/*
drivers/media/video/cx25840/* ' and other relevant directories under
drivers/media/{dvb, common} to find all the parameter options for all the
drivers involved in making a HVR_1250 work.
Or just build with everything enabled until you know it is working,
and then optimize the list of modules later.
Also, the 1250 is broken for analog until very recently (patches went
upstream for 3.5/3.6 a few days ago).
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
Re: [MINI SUMMIT] media mini-summit at KS/2012
Hi Mauro, Thanks for the update. Will you be also sending out invites like last year? How should we register and for what on the KS site? Thanks, Pawel On Wed, Aug 1, 2012 at 12:17 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: After the discussions around the media mini-summit, this is the consolidated list of topics. We tried to give a fair time for each topic. With regards to the proposed topic Intel media SDK, nobody volunteered to give such a talk. So, if there is anyone interested to talk about it, it can either be part of SoC vendor's feedback (if it won't take too long), or it could be handled as a topic during LPC. So, let's put this one in the fridge. Topics for the media mini-summit - morning: V4L2 API ambiguities + v4l2 compliance tool: 60 min Media Controller library: 30 min ALSA and V4L/Media Controller: 30 min ARM and needed features for V4L/DVB: 30 min - after lunch: SoC Vendors feedback – how to help them to go upstream: 45 min V4L2/DVB issues from userspace perspective: 45 min Android's V4L2 cam library: 30 min HDMI CEC: 30 min Synchronization, shared resource and optimizations: 30 min The DT discussions will likely require more time and maybe a different audience. So, it seems better to handle it as either as a separate/LPC section or at DT mini-summit: Common device tree bindings for media devices: 45 min Attendants == Guennadi Liakhovetski g.liakhovet...@gmx.de Hans Verkuil hans.verk...@xs4all.nl Laurent Pinchart laurent.pinch...@ideasonboard.com Mauro Carvalho Chehab mche...@redhat.com Michael Krufky mkru...@linuxtv.org Naveen Krishnamurthy naveen.krishnamur...@st.com Palash Bandyopadhyay palash.bandyopadh...@conexant.com Pawel Osciak pa...@osciak.com Rémi Denis-Courmont r...@remlab.net Sakari Ailus sakari.ai...@iki.fi Sri Deevi srinivasa.de...@conexant.com Steven Toth st...@kernellabs.com Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Marek Szyprowski m.szyprow...@samsung.com Kamil Debski k.deb...@samsung.com Naveen also asked another seat for ST, but didn't provide us yet the name of the other interested party. For the cross-system topics, it is important to have people from the other subsystems there. So, we're proposing to have some people there, but we need to double-check if they can really be there for the discussions. Of course, other Kernel developers from KS/LPC that work on those subsystems are welcome. The names that came up during our discussions for those panels are: Rob Clark rob.cl...@linaro.org (HDMI CEC, ALSA, ARM) Takashi Iwai ti...@suse.de (ALSA) Catalin Marinas catalin.mari...@arm.com (ARM) Mark Brown broo...@opensource.wolfsonmicro.com (DT) Not sure if they all will be there or if they'll have some time to discuss those things with us. We hope they will ;) Thanks, Mauro Carvalho Chehab Hans Verkuil -- 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 -- Best regards, Pawel Osciak -- 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 05/12] staging: lirc: use %*ph to print small buffers
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
---
drivers/staging/media/lirc/lirc_igorplugusb.c |4 ++--
drivers/staging/media/lirc/lirc_zilog.c |3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_igorplugusb.c
b/drivers/staging/media/lirc/lirc_igorplugusb.c
index 7a25017..939a801 100644
--- a/drivers/staging/media/lirc/lirc_igorplugusb.c
+++ b/drivers/staging/media/lirc/lirc_igorplugusb.c
@@ -325,8 +325,8 @@ static int igorplugusb_remote_poll(void *data, struct
lirc_buffer *buf)
if (ret DEVICE_HEADERLEN)
return -ENODATA;
- dprintk(DRIVER_NAME : Got %d bytes. Header: %02x %02x %02x\n,
- ret, ir-buf_in[0], ir-buf_in[1], ir-buf_in[2]);
+ dprintk(DRIVER_NAME : Got %d bytes. Header: %*ph\n,
+ ret, 3, ir-buf_in);
do_gettimeofday(now);
timediff = now.tv_sec - ir-last_time.tv_sec;
diff --git a/drivers/staging/media/lirc/lirc_zilog.c
b/drivers/staging/media/lirc/lirc_zilog.c
index 76ea4a8..11d5338 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -658,8 +658,7 @@ static int send_data_block(struct IR_tx *tx, unsigned char
*data_block)
buf[0] = (unsigned char)(i + 1);
for (j = 0; j tosend; ++j)
buf[1 + j] = data_block[i + j];
- dprintk(%02x %02x %02x %02x %02x,
- buf[0], buf[1], buf[2], buf[3], buf[4]);
+ dprintk(%*ph, 5, buf);
ret = i2c_master_send(tx-c, buf, tosend + 1);
if (ret != tosend + 1) {
zilog_error(i2c_master_send failed with %d\n, ret);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 03/15] v4l: vb2: add support for shared buffer (dma_buf)
Hi Laurent, Hi Dima, On 06/27/2012 10:40 PM, Laurent Pinchart wrote: Hi Dima, On Tuesday 26 June 2012 13:53:34 Dima Zavin wrote: On Tue, Jun 26, 2012 at 2:40 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Tue 26 June 2012 11:11:06 Laurent Pinchart wrote: On Tuesday 26 June 2012 10:40:44 Tomasz Stanislawski wrote: Hi Dima Zavin, Thank you for the patch and for a ping remainder :). You are right. The unmap is missing in __vb2_queue_cancel. I will apply your fix into next version of V4L2 support for dmabuf. Please refer to some comments below. On 06/20/2012 08:12 AM, Dima Zavin wrote: Tomasz, I've encountered an issue with this patch when userspace does several stream_on/stream_off cycles. When the user tries to qbuf a buffer after doing stream_off, we trigger the dmabuf already pinned warning since we didn't unmap the buffer as dqbuf was never called. The below patch adds calls to unmap in queue_cancel, but my feeling is that we probably should be calling detach too (i.e. put_dmabuf). According to the V4L2 specification, the VIDIOC_STREAMOFF ioctl, apart of aborting or finishing any DMA in progress, unlocks any user pointer buffers locked in physical memory, and it removes all buffers from the incoming and outgoing queues. Correct. And what that means in practice is that after a streamoff all buffers are returned to the state they had just before STREAMON was called. That can't be right. The buffers had to have been returned to the state just *after REQBUFS*, not just *before STREAMON*. You need to re-enqueue buffers before calling STREAMON. I assume that's what you meant? Your interpretation is correct. So now we should decide what should be changed: the spec or vb2 ? Bringing the queue state back to *after REQBUFS* may make the next (STREAMON + QBUFs) very costly operations. Reattaching and mapping a DMABUF might trigger DMA allocation and *will* trigger creation of IOMMU mappings. In case of a user pointer, calling next get_user_pages may cause numerous fault events and will *create* new IOMMU mapping. Is there any need to do such a cleanup if the destruction of buffers and all caches can be explicitly executed by REQBUFS(count = 0) ? Maybe it would be easier to change the spec by removing apart of ... in physical memory part? STREAMOFF should mean stopping streaming, and that resources are no longer used. DMABUFs are unmapped but unmapping does not mean releasing. The exporter may keep the resource in its caches. Currently, vb2 does not follow the policy from the spec. The put_userptr ops is called on: - VIDIOC_REBUFS - VIDIOC_CREATE_BUFS - vb2_queue_release() which is usually called on close() syscall The put_userptr is not called and streamoff therefore the user pages are locked after STREAMOFF. BTW. What does 'buffer locked' mean? Does it mean that a buffer is pinned or referenced by a driver/HW? Regards, Tomasz Stanislawski So after STREAMOFF you can immediately queue all buffers again with QBUF and call STREAMON to restart streaming. No mmap or other operations should be required. This behavior must be kept. VIDIOC_REQBUFS() or a close() are the only two operations that will actually free the buffers completely. In practice, a STREAMOFF is either followed by a STREAMON at a later time, or almost immediately followed by REQBUFS or close() to tear down the buffers. So I don't think the buffers should be detached at streamoff. I agree. I was leaning this way which is why I left it out of my patch and wanted to hear your guys' opinion as you are much more familiar with the intended behavior than I am. Thanks! You're welcome. Thank you for reporting the problem and providing a patch. -- 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: 3.5 kernel options for Hauppauge_WinTV-HVR-1250
On Thu, Aug 2, 2012 at 5:53 AM, Andy Walls awa...@md.metrocast.net
wrote:
You can 'grep MODULE_ drivers/media/video/cx23885/*
drivers/media/video/cx25840/* ' and other relevant directories under
drivers/media/{dvb, common} to find all the parameter options for all
the drivers involved in making a HVR_1250 work.
Or just build with everything enabled until you know it is working,
and then optimize the list of modules later.
It should have been easier, select the card and it builds all the drivers
it needs. :-)
Is there a script somewhere that lets me select a card and automatically
modifies the kernel config?
Also, the 1250 is broken for analog until very recently (patches went
upstream for 3.5/3.6 a few days ago).
North American OTA is all digital so I have no way to test it.
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
--
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: 3.5 kernel options for Hauppauge_WinTV-HVR-1250
Devin Heitmueller dheitmuel...@kernellabs.com wrote:
On Thu, Aug 2, 2012 at 5:53 AM, Andy Walls awa...@md.metrocast.net
wrote:
You can 'grep MODULE_ drivers/media/video/cx23885/*
drivers/media/video/cx25840/* ' and other relevant directories under
drivers/media/{dvb, common} to find all the parameter options for all
the drivers involved in making a HVR_1250 work.
Or just build with everything enabled until you know it is working,
and then optimize the list of modules later.
Also, the 1250 is broken for analog until very recently (patches went
upstream for 3.5/3.6 a few days ago).
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
Oh, James meant kernel *build* options, not kernel *commandline/module* options.
Then what I offered won't help at all.
-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: 3.5 kernel options for Hauppauge_WinTV-HVR-1250
On Thu, Aug 2, 2012 at 12:34 PM, bjloc...@lockie.ca wrote: It should have been easier, select the card and it builds all the drivers it needs. :-) Is there a script somewhere that lets me select a card and automatically modifies the kernel config? Yeah, that isn't really practical. There are *hundreds* of boards, and having one config option isn't practical given the number of different bridge/demod/tuner combinations there are. Heck, even for the 1250 there are eight or ten different versions, so most users wouldn't even know the right one to choose. The reality is that the kernel config isn't optimized for this use case, and given the overhead in administration combined with the *EXTREME* unlikelihood that any real users would use it, it just isn't worth the effort. If you're hacking the kernel config to include support for a single board as opposed to the whole media subsystem, you're 0.001% of the user base, and your use case isn't worth the developer effort that would be required. In short, we barely have the manpower to make this stuff work at all. Wasted effort to optimize for really obscure use cases is better spent on expanding the set of supported products. Also, the 1250 is broken for analog until very recently (patches went upstream for 3.5/3.6 a few days ago). North American OTA is all digital so I have no way to test it. That's fine. I was just trying to make clear that if you wanted analog functionality then you need the latest code. 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
Re: 3.5 kernel options for Hauppauge_WinTV-HVR-1250
bjloc...@lockie.ca wrote:
On Thu, Aug 2, 2012 at 5:53 AM, Andy Walls awa...@md.metrocast.net
wrote:
You can 'grep MODULE_ drivers/media/video/cx23885/*
drivers/media/video/cx25840/* ' and other relevant directories under
drivers/media/{dvb, common} to find all the parameter options for
all
the drivers involved in making a HVR_1250 work.
Or just build with everything enabled until you know it is working,
and then optimize the list of modules later.
It should have been easier, select the card and it builds all the
drivers
it needs. :-)
Is there a script somewhere that lets me select a card and
automatically
modifies the kernel config?
Also, the 1250 is broken for analog until very recently (patches went
upstream for 3.5/3.6 a few days ago).
North American OTA is all digital so I have no way to test it.
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
There are too many different card models and variants supported by bridge
drivers to list every one in the kconfig system.
There are several variants of the 1250 itself with different chips on board.
You have no guarantee that two retail boxes labeled HVR-1250 both contain
identical hardware.
IMO, trying to winnow down the supporting drivers you compile just sets
yourself for more work in the future if you add a second card.
Regards,
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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Thu Aug 2 19:00:22 CEST 2012 git hash:24ed693da0cefede7382d498dd5e9a83f0a21c38 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: ERRORS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.5 kernel options for Hauppauge_WinTV-HVR-1250
Heck, even for the 1250 there are eight or ten different versions, so most users wouldn't even know the right one to choose. Do you mean boards that use different chips? I hate it when manufacturers do that (ie. with routers). -- 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: 3.5 kernel options for Hauppauge_WinTV-HVR-1250
On 08/02/2012 10:41 PM, bjloc...@lockie.ca wrote: Heck, even for the 1250 there are eight or ten different versions, so most users wouldn't even know the right one to choose. Do you mean boards that use different chips? I hate it when manufacturers do that (ie. with routers). That happens quite often. Few weeks back someone sends mail saying he has got new version of Terratec Cinergy T Stick Dual RC. Old version uses Afatech AF9015 chips whilst new revision is ITE Technologies IT9135 and USB ID is same. Those are quite different chips and having different drivers. In such cases it could be quite challenging to get it working as both drivers are thinking it is for me according to USB ID. regards Antti -- http://palosaari.fi/ -- 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: 3.5 kernel options for Hauppauge_WinTV-HVR-1250
On Thu, Aug 2, 2012 at 3:41 PM, bjloc...@lockie.ca wrote: Heck, even for the 1250 there are eight or ten different versions, so most users wouldn't even know the right one to choose. Do you mean boards that use different chips? I hate it when manufacturers do that (ie. with routers). In some cases it's different chips (changing the design to use a better/cheaper bridge, demodulator or tuner). In some cases it's because they have different inputs (there are several variants that have different configurations of composite, s-video, audio connector, IR support, etc). As far as the manufacturer is concerned, if there is no end-user visible feature difference, it's reasonable to not change the model number and cause the confusion. That said though, it's a real PITA for Linux users who think they're something that the web says works but in fact they are getting something else. 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
Re: [PATH v3 0/2] Add v4l2 subdev driver for S5K4ECGX sensor with embedded SoC ISP
Hi Sangwook,
On 08/02/2012 03:42 PM, Sangwook Lee wrote:
The following 2 patches add driver for S5K4ECGX sensor with embedded ISP SoC,
and minor v4l2 control API enhancement. S5K4ECGX is 5M CMOS Image sensor from
Samsung
Changes since v2:
- added GPIO (reset/stby) and regulators
- updated I2C read/write, based on s5k6aa datasheet
- fixed set_fmt errors
- reduced register tables a bit
- removed vmalloc
It looks like a great improvement, well done! Thanks!
In the S5K4CAGX sensor datasheet, that can be found on the internet,
there is 0x...0x002E registers description, which look very much
same as in S5K6AAFX case and likely is also valid for S5K4CAGX.
My second thought was, if we won't be able to get rid of those hundreds
of initial register values, to convert them to regular firmware blob.
And add regular firmware handling at the driver. I know it may sound
not standard but imagine dozens of such sensor drivers coexisting in
the mainline kernel. The source code would have been mainly register
address/value arrays...
What do you think about converting s5k4ecgx_img_regs arrays (it has
over 2700 entries) to a firmware file and adding some simple parser
to the driver ? Then we would have the problem solved in most part.
Regarding various preview resolution set up, the difference in all
those s5k4ecgx_*_preview[] arrays is rather small, only register
values differ, e.g. for 640x480 and 720x480 there is only 8 different
entries:
$ diff -a s5k4ec_640.txt s5k4ec_720.txt
1c1
static const struct regval_list s5k4ecgx_640_preview[] = {
---
static const struct regval_list s5k4ecgx_720_preview[] = {
3c3
{ 0x7252, 0x0780 },
---
{ 0x7252, 0x06a8 },
5c5
{ 0x7256, 0x000c },
---
{ 0x7256, 0x0078 },
7c7
{ 0x725a, 0x0780 },
---
{ 0x725a, 0x06a8 },
9c9
{ 0x725e, 0x000c },
---
{ 0x725e, 0x0078 },
11c11
{ 0x7496, 0x0780 },
---
{ 0x7496, 0x06a8 },
15c15
{ 0x749e, 0x0780 },
---
{ 0x749e, 0x06a8 },
21c21
{ 0x72a6, 0x0280 },
---
{ 0x72a6, 0x02d0 },
28c28
{ 0x72c4, 0x014a },
---
{ 0x72c4, 0x014d },
I've found S5K4ECGX sensor datasheet on internet (Rev 0.07), and on a quick
look the description of most of registers from those tables could be found
there.
Could you please try to implement a function that replaces those tables,
based s5k6aa_set_prev_config() and s5k6aa_set_output_framefmt() ?
Regards,
Sylwester
--
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: 3.5 kernel options for Hauppauge_WinTV-HVR-1250
bjloc...@lockie.ca wrote: Heck, even for the 1250 there are eight or ten different versions, so most users wouldn't even know the right one to choose. Do you mean boards that use different chips? I hate it when manufacturers do that (ie. with routers). -- 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 Yup. There are HVR1250s with different bridge chips: CX23885 vs CX23888. Normally board differences are with tuner, demod, fm radio, and IR chips. Bridge drivers have the smarts to know what board they are dealing with much better than a human staring at vendor packaging. Bridge drivers look at: PCI/USB id Hard coded tables in the drivers EEPROM information (vendor specific) I2C bus probes at expected addresses Goofy hueristics based on register reads (I.e. cx25840_probe ) User provided module options for card type (last resort) The end user has no hope of compiling the exact linux drivers for a board without some simple experimentation with modprobe and lsmod with the hardware. The Kconfig system gets you the superset of everything the bridge driver might need for a card, given a particular bridge driver. Regards, 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: [PATH v3 1/2] v4l: Add factory register values form S5K4ECGX sensor
On 08/02/2012 03:42 PM, Sangwook Lee wrote:
Add factory default settings for S5K4ECGX sensor registers,
which was copied from the reference code of Samsung S.LSI.
Signed-off-by: Sangwook Leesangwook@linaro.org
---
drivers/media/video/s5k4ecgx_regs.h | 3105
+++
1 file changed, 3105 insertions(+)
create mode 100644 drivers/media/video/s5k4ecgx_regs.h
diff --git a/drivers/media/video/s5k4ecgx_regs.h
b/drivers/media/video/s5k4ecgx_regs.h
new file mode 100644
index 000..ef87c09
--- /dev/null
+++ b/drivers/media/video/s5k4ecgx_regs.h
@@ -0,0 +1,3105 @@
+/*
+ * Samsung S5K4ECGX register tables for default values
+ *
+ * Copyright (C) 2012 Linaro
+ * Copyright (C) 2012 Insignal Co,. Ltd
+ *
+ * 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.
+ */
+
+#ifndef __DRIVERS_MEDIA_VIDEO_S5K4ECGX_H__
+#define __DRIVERS_MEDIA_VIDEO_S5K4ECGX_H__
+
+struct regval_list {
+ u32 addr;
+ u16 val;
+};
+
+/*
+ * FIXME:
+ * The tables are default values of a S5K4ECGX sensor EVT1.1
+ * from Samsung LSI. currently there is no information available
+ * to the public in order to reduce these tables size.
+ */
+static const struct regval_list s5k4ecgx_apb_regs[] = {
sniiip
+/* configure 30 fps */
+static const struct regval_list s5k4ecgx_fps_30[] = {
It really depends on sensor master clock frequency (as specified
in FIMC driver platform data) and PLL setting what the resulting
frame rate will be.
+ { 0x72b4, 0x0052 },
REG_0TC_PCFG_PVIMask
+ { 0x72be, 0x },
REG_0TC_PCFG_usFrTimeType
+ { 0x72c0, 0x0001 },
REG_0TC_PCFG_FrRateQualityType
+ { 0x72c2, 0x014d },
REG_0TC_PCFG_usMaxFrTimeMsecMult10
+ { 0x72c4, 0x014d },
REG_0TC_PCFG_usMinFrTimeMsecMult10
+ { 0x72d0, 0x },
REG_0TC_PCFG_uPrevMirror
Looks surprising! Are we really just disabling horizontal/vertical
image mirror here ?
+ { 0x72d2, 0x },
REG_0TC_PCFG_uCaptureMirror
+ { 0x7266, 0x },
REG_TC_GP_ActivePrevConfig
+ { 0x726a, 0x0001 },
REG_TC_GP_PrevOpenAfterChange
+ { 0x724e, 0x0001 },
REG_TC_GP_NewConfigSync
+ { 0x7268, 0x0001 },
REG_TC_GP_PrevConfigChanged
Please have a look how it is handled in s5k6aa driver, it all looks
pretty similar.
+ { 0x, 0x },
+};
+
+static const struct regval_list s5k4ecgx_effect_normal[] = {
+ { 0x723c, 0x },
Just one register, why do we need an array for it ? And of course
0x is default value after reset, so it seems sort of pointless
doing this I2C write to set the default image effect value (disabled).
These are possible values as found in the datasheet:
0x723C REG_TC_GP_SpecialEffects 0x 2 RW Special effect
0 : Normal
1 : MONOCHROME (BW)
2 : Negative Mono
3 : Negative Color
4 : Sepia
5 : AQUA
6 : Reddish
7 : Bluish
8 : Greenish
9 : Sketch
10 : Emboss color
11 : Emboss Mono
+ { 0x, 0x },
+};
+
+static const struct regval_list s5k4ecgx_wb_auto[] = {
+ { 0x74e6, 0x077f },
Ditto - register REG_TC_DBG_AutoAlgEnBits. And 0x077f is the default
value after reset...
+ { 0x, 0x },
+};
+
+static const struct regval_list s5k4ecgx_iso_auto[] = {
+ { 0x7938, 0x },
+ { 0x7f2a, 0x0001 },
+ { 0x74e6, 0x077f },
+ { 0x74d0, 0x },
+ { 0x74d2, 0x },
+ { 0x74d4, 0x0001 },
+ { 0x76c2, 0x0200 },
+ { 0x, 0x },
+};
+
+static const struct regval_list s5k4ecgx_contrast_default[] = {
+ { 0x7232, 0x },
No need for an array, it's REG_TC_UserContrast.
+ { 0x, 0x },
+};
+
+static const struct regval_list s5k4ecgx_scene_default[] = {
+ { 0x70001492, 0x },
+ { 0x70001494, 0x0101 },
+ { 0x70001496, 0x0101 },
+ { 0x70001498, 0x },
+ { 0x7000149a, 0x0101 },
+ { 0x7000149c, 0x0101 },
+ { 0x7000149e, 0x0101 },
+ { 0x700014a0, 0x0101 },
+ { 0x700014a2, 0x0201 },
+ { 0x700014a4, 0x0303 },
+ { 0x700014a6, 0x0303 },
+ { 0x700014a8, 0x0102 },
+ { 0x700014aa, 0x0201 },
+ { 0x700014ac, 0x0403 },
+ { 0x700014ae, 0x0304 },
+ { 0x700014b0, 0x0102 },
+ { 0x700014b2, 0x0201 },
+ { 0x700014b4, 0x0403 },
+ { 0x700014b6, 0x0304 },
+ { 0x700014b8, 0x0102 },
+ { 0x700014ba, 0x0201 },
+ { 0x700014bc, 0x0403 },
+ { 0x700014be, 0x0304 },
+ { 0x700014c0, 0x0102 },
+ { 0x700014c2, 0x0201 },
+ { 0x700014c4, 0x0303 },
+ { 0x700014c6, 0x0303 },
+ { 0x700014c8, 0x0102 },
+ { 0x700014ca, 0x0201 },
+ { 0x700014cc, 0x0202 },
+ { 0x700014ce, 0x0202 },
+ { 0x700014d0, 0x0102 },
+ { 0x7938, 0x },
+ { 0x76b8,
dvb_usb_lmedm04 crash Kernel
Moi Malcolm, Any idea why this seems to crash Kernel just when device is plugged? [crope@localhost linux]$ uname -a Linux localhost.localdomain 3.4.6-2.fc17.x86_64 #1 SMP Thu Jul 19 22:54:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux [crope@localhost linux]$ modinfo dvb_usb_lmedm04 filename: /lib/modules/3.4.6-2.fc17.x86_64/kernel/drivers/media/dvb/dvb-usb/dvb-usb-lmedm04.ko license:GPL version:1.99 description:LME2510(C) DVB-S USB2.0 author: Malcolm Priestley tvbox...@gmail.com srcversion: 59949851F3132870B974EE7 alias: usb:v3344p22F0d*dc*dsc*dp*ic*isc*ip* alias: usb:v3344p1120d*dc*dsc*dp*ic*isc*ip* alias: usb:v3344p1122d*dc*dsc*dp*ic*isc*ip* depends:dvb-usb,dvb-core,rc-core intree: Y vermagic: 3.4.6-2.fc17.x86_64 SMP mod_unload parm: debug:set debugging level (1=info (or-able)). (debugging is not enabled) (int) parm: firmware:set default firmware 0=Sharp7395 1=LG (int) parm: pid:set default 0=default 1=off 2=on (int) parm: adapter_nr:DVB adapter numbers (array of short) [crope@localhost linux]$ Aug 2 23:46:19 localhost kernel: [ 211.527886] usb 1-2.2: new high-speed USB device number 7 using ehci_hcd Aug 2 23:46:19 localhost kernel: [ 211.601817] usb 1-2.2: config 1 interface 0 altsetting 1 bulk endpoint 0x81 has invalid maxpacket 64 Aug 2 23:46:19 localhost kernel: [ 211.601829] usb 1-2.2: config 1 interface 0 altsetting 1 bulk endpoint 0x1 has invalid maxpacket 64 Aug 2 23:46:19 localhost kernel: [ 211.601837] usb 1-2.2: config 1 interface 0 altsetting 1 bulk endpoint 0x2 has invalid maxpacket 64 Aug 2 23:46:19 localhost kernel: [ 211.601845] usb 1-2.2: config 1 interface 0 altsetting 1 bulk endpoint 0x8A has invalid maxpacket 64 Aug 2 23:46:19 localhost kernel: [ 211.602073] usb 1-2.2: New USB device found, idVendor=3344, idProduct=22f0 Aug 2 23:46:19 localhost kernel: [ 211.602083] usb 1-2.2: New USB device strings: Mfr=0, Product=0, SerialNumber=3 Aug 2 23:46:19 localhost kernel: [ 211.602093] usb 1-2.2: SerialNumber: 䥈児 Aug 2 23:46:19 localhost mtp-probe: checking bus 1, device 7: /sys/devices/pci:00/:00:12.2/usb1/1-2/1-2.2 Aug 2 23:46:19 localhost mtp-probe: bus: 1, device: 7 was not an MTP device Aug 2 23:46:19 localhost kernel: [ 211.628508] LME2510(C): Firmware Status: 6 (44) Aug 2 23:46:19 localhost kernel: [ 211.629545] LME2510(C): FRM Loading dvb-usb-lme2510c-rs2000.fw file Aug 2 23:46:19 localhost kernel: [ 211.629551] LME2510(C): FRM Starting Firmware Download Aug 2 23:46:19 localhost kernel: [ 211.629574] BUG: unable to handle kernel NULL pointer dereference at 0008 Aug 2 23:46:19 localhost kernel: [ 211.629739] IP: [a03ac116] lme_firmware_switch+0x526/0x800 [dvb_usb_lmedm04] Aug 2 23:46:19 localhost kernel: [ 211.629900] PGD 0 Aug 2 23:46:19 localhost kernel: [ 211.629947] Oops: [#1] SMP Aug 2 23:46:19 localhost kernel: [ 211.630019] CPU 3 Aug 2 23:46:19 localhost kernel: [ 211.630058] Modules linked in: dvb_usb_lmedm04(+) dvb_usb fuse tpm_bios rfcomm bnep ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_hdmi ppdev sp5100_tco snd_hda_codec_via btusb bluetooth i2c_piix4 8139too microcode 8139cp serio_raw snd_hda_intel edac_core edac_mce_amd k10temp snd_hda_codec snd_hwdep rfkill r8169 mii cx23885 altera_ci tda18271 altera_stapl cx2341x btcx_risc videobuf_dvb dvb_core snd_pcm snd_page_alloc snd_timer snd soundcore tveeprom videobuf_dma_sg videobuf_core v4l2_common videodev media rc_core shpchp parport_pc parport asus_atk0110 uinput xts gf128mul hid_logitech_dj ata_generic pata_acpi dm_crypt pata_atiixp wmi radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core [last unloaded: scsi_wait_scan] Aug 2 23:46:19 localhost kernel: [ 211.631729] Aug 2 23:46:19 localhost kernel: [ 211.631762] Pid: 528, comm: udevd Not tainted 3.4.6-2.fc17.x86_64 #1 System manufacturer System Product Name/M5A78L-M/USB3 Aug 2 23:46:19 localhost kernel: [ 211.631981] RIP: 0010:[a03ac116] [a03ac116] lme_firmware_switch+0x526/0x800 [dvb_usb_lmedm04] Aug 2 23:46:19 localhost kernel: [ 211.632183] RSP: 0018:88030b097ae8 EFLAGS: 00010286 Aug 2 23:46:19 localhost kernel: [ 211.632282] RAX: RBX: RCX: Aug 2 23:46:19 localhost kernel: [ 211.632414] RDX: 0008 RSI: 0046 RDI: 0246 Aug 2 23:46:19 localhost kernel: [ 211.632552] RBP: 88030b097c28 R08: 000a R09: Aug 2 23:46:19 localhost kernel: [ 211.632702] R10: R11: 8802f8255c02 R12: Aug 2 23:46:19 localhost kernel: [ 211.632833] R13: 8802f8255c00 R14: 8802f8255c02 R15: Aug 2 23:46:19 localhost kernel: [ 211.632967] FS:
Re: [PATH v3 2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor
On 08/02/2012 03:42 PM, Sangwook Lee wrote:
This driver implements preview mode of the S5K4ECGX sensor.
capture (snapshot) operation, face detection are missing now.
Following controls are supported:
contrast/saturation/brightness/sharpness
Signed-off-by: Sangwook
Leesangwook.lee-qsej5fyqhm4dnm+yrof...@public.gmane.org
---
...
+static const char * const s5k4ecgx_supply_names[] = {
+ /*
+ * vdd_2.8v is for Analog power supply 2.8V(vdda)
+ * and Digital IO(vddio, vddd_core)
+ */
+ vdd_2.8v,
Might be better to avoid voltage value in regulator supply names. Can you
just make it on of: vdda, vddio, vddcore ? On some systems all 3 power pads
might be used and all 3 voltage supply names might be needed. I guess it can
be changed if there is a need for it. Also we could specify all 3 entries as
above and add such regulator supply names at a corresponding regulator.
+ /* vdd_1.8v is for regulator input */
+ vdd_1.8v,
I would suggest just using vddreg.
+static int s5k4ecgx_write(struct i2c_client *client, u32 addr, u16 val)
+{
+ int ret = 0;
Unneeded initialization.
+ u16 high = addr 16, low = addr 0x;
+
+ ret = s5k4ecgx_i2c_write(client, REG_CMDWR_ADDRH, high);
+ ret |= s5k4ecgx_i2c_write(client, REG_CMDWR_ADDRL, low);
+ ret |= s5k4ecgx_i2c_write(client, REG_CMDBUF0_ADDR, val);
+ if (ret)
+ return -ENODEV;
+
+ return 0;
+}
+
+static int s5k4ecgx_read(struct i2c_client *client, u32 addr, u16 *val)
+{
+ int ret = 0;
Ditto.
+ u16 high = addr 16, low = addr 0x;
+
+ ret = s5k4ecgx_i2c_write(client, REG_CMDRD_ADDRH, high);
+ ret |= s5k4ecgx_i2c_write(client, REG_CMDRD_ADDRL, low);
+ ret |= s5k4ecgx_i2c_read(client, REG_CMDBUF0_ADDR, val);
+ if (ret) {
+ dev_err(client-dev, Failed to execute read command\n);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int s5k4ecgx_set_ahb_address(struct v4l2_subdev *sd)
+{
+ int ret;
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ /* Set APB peripherals start address */
+ ret = s5k4ecgx_i2c_write(client, AHB_MSB_ADDR_PTR, GEN_REG_OFFSH);
+ if (ret)
+ return ret;
+ /*
+ * FIMXE: This is copied from s5k6aa, because of no information
+ * in s5k4ecgx's datasheet.
+ * sw_reset is activated to put device into idle status
+ */
+ ret = s5k4ecgx_i2c_write(client, 0x0010, 0x0001);
+ if (ret)
+ return ret;
+
+ /* FIXME: no information avaialbe about this register */
avaialbe - available
+ ret = s5k4ecgx_i2c_write(client, 0x1030, 0x);
+ if (ret)
+ return ret;
+ /* Halt ARM CPU */
+ ret = s5k4ecgx_i2c_write(client, 0x0014, 0x0001);
+
+ return ret;
return s5k4ecgx_i2c_write(...); ?
+}
+
+static int s5k4ecgx_write_array(struct v4l2_subdev *sd,
+ const struct regval_list *reg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ u16 addr_incr = 0;
+ int ret = 0;
Unneeded initialization.
+
+ while (reg-addr != TOK_TERM) {
+ if (addr_incr != 2)
+ ret = s5k4ecgx_write(client, reg-addr, reg-val);
+ else
+ ret = s5k4ecgx_i2c_write(client, REG_CMDBUF0_ADDR,
+ reg-val);
+ if (ret)
+ break;
+ /* Assume that msg-addr is always less than 0xfffc */
+ addr_incr = (reg + 1)-addr - reg-addr;
+ reg++;
+ }
+
+ return ret;
+}
...
+
+static int s5k4ecgx_init_sensor(struct v4l2_subdev *sd)
+{
+ int ret = 0;
Ditto.
+
+ ret = s5k4ecgx_set_ahb_address(sd);
+ /* The delay is from manufacturer's settings */
+ msleep(100);
+
+ ret |= s5k4ecgx_write_array(sd, s5k4ecgx_apb_regs);
+ ret |= s5k4ecgx_write_array(sd, s5k4ecgx_img_regs);
+
+ if (ret)
+ v4l2_err(sd, Failed to write initial settings\n);
+
+ return 0;
+}
+
...
+static int s5k4ecgx_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+
+ struct v4l2_subdev *sd =container_of(ctrl-handler, struct s5k4ecgx,
+ handler)-sd;
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct s5k4ecgx *priv = to_s5k4ecgx(sd);
+ int err = 0;
Unneded initilization.
+
+ v4l2_dbg(1, debug, sd, ctrl: 0x%x, value: %d\n, ctrl-id, ctrl-val);
+
+ mutex_lock(priv-lock);
+ switch (ctrl-id) {
+ case V4L2_CID_CONTRAST:
+ err = s5k4ecgx_write(client, REG_USER_CONTRAST, ctrl-val);
+ break;
+
+ case V4L2_CID_SATURATION:
+ err = s5k4ecgx_write(client, REG_USER_SATURATION, ctrl-val);
+ break;
+
+ case V4L2_CID_SHARPNESS:
+ ctrl-val *= SHARPNESS_DIV;
+ err |=
Re: [PATCH] [media] davinci: vpfe: Add documentation
Hi Manjunath,
On Tuesday 31 July 2012 13:15:27 Manju wrote:
On Friday 27 July 2012 04:19 PM, Laurent Pinchart wrote:
On Friday 27 July 2012 05:49:24 Hadli, Manjunath wrote:
On Thu, Jul 26, 2012 at 05:55:31, Laurent Pinchart wrote:
On Tuesday 17 July 2012 10:43:54 Hadli, Manjunath wrote:
On Sun, Jul 15, 2012 at 18:16:25, Laurent Pinchart wrote:
On Wednesday 11 July 2012 21:09:26 Manjunath Hadli wrote:
Add documentation on the Davinci VPFE driver. Document the subdevs,
and private IOTCLs the driver implements
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
[snip]
+Private IOCTLs
+==
+
+The Davinci Video processing Front End (VPFE) driver supports
standard V4L2
+IOCTLs and controls where possible and practical. Much of the
functions provided
+by the VPFE, however, does not fall under the standard IOCTLs.
+
+In general, there is a private ioctl for configuring each of the
blocks
+containing hardware-dependent functions.
+
+The following private IOCTLs are supported:
+
+1: IOCTL: PREV_S_PARAM/PREV_G_PARAM
+Description:
+ Sets/Gets the parameters required by the previewer module
+Parameter:
+ /**
+ * struct prev_module_param- structure to configure preview
modules
+ * @version: Version of the preview module
Who is responsible for filling this field, the application or the
driver ?
The application is responsible for filling this info. He would
enumerate the capabilities first and set them using S_PARAM/G_PARAM.
And what's the point of the application setting the version field ? How
does the driver use it ?
The version may not be required. Will remove it.
+ * @len: Length of the module config structure
+ * @module_id: Module id
+ * @param: pointer to module config parameter.
What is module_id for ? What does param point to ?
There are a lot of tiny modules in the previewer/resizer which are
enumerated as individual modules. The param points to the parameter set
that the module expects to be set.
Why don't you implement something similar to
VPFE_CMD_S_CCDC_RAW_PARAMS/VPFE_CMD_G_CCDC_RAW_PARAMS instead ?
I feel if we implement direct IOCTLS there might be many of them. To make
sure than independent of the number of internal modules present, having
the
same IOCTL used for all modules is a good idea.
You can set several parameters using a single ioctl, much like
VPFE_CMD_S_CCDC_RAW_PARAMS does. You don't need one ioctl per parameter.
PREV_ENUM_CAP, PREV_[GS]_PARAM and PREV_[GS]_CONFIG are essentially
reinventing V4L2 controls, and I don't think that's a good idea.
Ok. I looked into this, and found that the structure needed to pass
all the parameters is going to be huge. just to avoid a big structure
from the user space, I propose:
Having a union of structures and a parameter identifying the structure.
In that way, we will remove the enumeration and all the other
things except for a SET and GET, much like the CCDC_RAW_PARAMS
like you suggested. So essentially we will have only 2 IOCTLS for setting
the private params/configs and remove the rest. I hope that was your
point and this proposal will solve it?
What about something like the following structure, from the OMAP3 ISP driver ?
struct omap3isp_prev_update_config {
__u32 update;
__u32 flag;
__u32 shading_shift;
struct omap3isp_prev_luma __user *luma;
struct omap3isp_prev_hmed __user *hmed;
struct omap3isp_prev_cfa __user *cfa;
struct omap3isp_prev_csup __user *csup;
struct omap3isp_prev_wbal __user *wbal;
struct omap3isp_prev_blkadj __user *blkadj;
struct omap3isp_prev_rgbtorgb __user *rgb2rgb;
struct omap3isp_prev_csc __user *csc;
struct omap3isp_prev_yclimit __user *yclimit;
struct omap3isp_prev_dcor __user *dcor;
struct omap3isp_prev_nf __user *nf;
struct omap3isp_prev_gtables __user *gamma;
};
I'll probably have more comments when I'll see the complete list of parameters
you need to expose.
+ */
+ struct prev_module_param {
+ char version[IMP_MAX_NAME_SIZE];
Is there a need to express the version as a string instead of an
integer ?
It could be integer. It is generally a fixed point num, and easy to
read
it as a string than an integer. Can I keep it as a string?
Let's first decide whether a version field is needed at all :-)
Will remove.
+ unsigned short len;
+ unsigned short module_id;
+ void *param;
+ };
--
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: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Hi Rémi, On Thursday 02 August 2012 09:56:43 Rémi Denis-Courmont wrote: Le jeudi 2 août 2012 09:35:58 Hans Verkuil, vous avez écrit : On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote: What about using the CREATE_BUFS ioctl to add new MMAP buffers at runtime ? Does CREATE_BUFS always work while already streaming has already started? If it depends on the driver, it's kinda helpless. Yes, it does. It's one of the reasons it exists in the first place. But there are currently only a handful of drivers that implement it. I hope that as more and more drivers are converted to vb2 that the availability of create_bufs will increase. That's contradictory. If most drivers do not support it, then it won't work during streaming. What's the guaranteed minimum buffer count? It seems in any case, MMAP has a hard limit of 32 buffers (at least videobuf2 has), though one might argue this should be more than enough. Minimum or maximum? The maximum is 32, that's hardcoded in the V4L2 core. Although drivers may force a lower maximum if they want. I have no idea whether there are drivers that do that. There probably are. The smallest of the maxima of all drivers. The minimum is usually between 1 and 3, depending on hardware limitations. And that's clearly insufficient without memory copy to userspace buffers. That's the minimum number of buffers *required* by the hardware. You can add up to 32 buffers, I'm not aware of any driver that would prevent that. It does not seem to me that CREATE_BUFS+MMAP is a useful replacement for REQBUFS+USERBUF then. -- 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: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Hi Hans, On Thursday 02 August 2012 09:08:18 Hans Verkuil wrote: On Thu August 2 2012 08:56:43 Rémi Denis-Courmont wrote: Le jeudi 2 août 2012 09:35:58 Hans Verkuil, vous avez écrit : On Wed August 1 2012 22:49:57 Rémi Denis-Courmont wrote: What about using the CREATE_BUFS ioctl to add new MMAP buffers at runtime ? Does CREATE_BUFS always work while already streaming has already started? If it depends on the driver, it's kinda helpless. Yes, it does. It's one of the reasons it exists in the first place. But there are currently only a handful of drivers that implement it. I hope that as more and more drivers are converted to vb2 that the availability of create_bufs will increase. That's contradictory. If most drivers do not support it, then it won't work during streaming. IF create_bufs is implemented in the driver, THEN you can use it during streaming. I.e., it will never return EBUSY as an error due to the fact that streaming is in progress. Obviously it won't work if the driver didn't implement it in the first place. What's the guaranteed minimum buffer count? It seems in any case, MMAP has a hard limit of 32 buffers (at least videobuf2 has), though one might argue this should be more than enough. Minimum or maximum? The maximum is 32, that's hardcoded in the V4L2 core. Although drivers may force a lower maximum if they want. I have no idea whether there are drivers that do that. There probably are. The smallest of the maxima of all drivers. I've no idea. Most will probably abide by the 32 maximum, but without analyzing all drivers I can't guarantee it. The minimum is usually between 1 and 3, depending on hardware limitations. And that's clearly insufficient without memory copy to userspace buffers. It does not seem to me that CREATE_BUFS+MMAP is a useful replacement for REQBUFS+USERBUF then. Just to put your mind at rest: USERPTR mode will *not* disappear or be deprecated in any way. It's been there for a long time, it's in heavy use, it's easy to use and it will not be turned into a second class citizen, because it isn't. Just because there is a new dmabuf mode available doesn't mean that everything should be done as a mmap+dmabuf thing. I disagree with this. Not everything should obviously be done with MMAP + DMABUF, but for buffer sharing between devices, we should encourage application developers to use DMABUF instead of USERPTR. -- 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
[PATCH] [BUG] Re: dvb_usb_lmedm04 crash Kernel (rs2000)
On Thu, 2012-08-02 at 23:54 +0300, Antti Palosaari wrote: Moi Malcolm, Any idea why this seems to crash Kernel just when device is plugged? Hi Antti Yes, there missing error handling when no firmware file found. It seems that this is more of a problem with udev-182+. However, so far udev-182 is only a problem on first ever plug. Regards Malcolm Signed-off-by: Malcolm Priestley tvbox...@gmail.com --- drivers/media/dvb/dvb-usb/lmedm04.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c b/drivers/media/dvb/dvb-usb/lmedm04.c index 25d1031..26ba5bc 100644 --- a/drivers/media/dvb/dvb-usb/lmedm04.c +++ b/drivers/media/dvb/dvb-usb/lmedm04.c @@ -878,6 +878,10 @@ static int lme_firmware_switch(struct usb_device *udev, int cold) fw_lme = fw_c_rs2000; ret = request_firmware(fw, fw_lme, udev-dev); dvb_usb_lme2510_firmware = TUNER_RS2000; + if (ret == 0) + break; + info(FRM No Firmware Found - please install); + cold_fw = 0; break; default: fw_lme = fw_c_s7395; -- 1.7.9.5 [crope@localhost linux]$ uname -a Linux localhost.localdomain 3.4.6-2.fc17.x86_64 #1 SMP Thu Jul 19 22:54:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux [crope@localhost linux]$ modinfo dvb_usb_lmedm04 filename: /lib/modules/3.4.6-2.fc17.x86_64/kernel/drivers/media/dvb/dvb-usb/dvb-usb-lmedm04.ko license:GPL version:1.99 description:LME2510(C) DVB-S USB2.0 author: Malcolm Priestley tvbox...@gmail.com srcversion: 59949851F3132870B974EE7 alias: usb:v3344p22F0d*dc*dsc*dp*ic*isc*ip* alias: usb:v3344p1120d*dc*dsc*dp*ic*isc*ip* alias: usb:v3344p1122d*dc*dsc*dp*ic*isc*ip* depends:dvb-usb,dvb-core,rc-core intree: Y vermagic: 3.4.6-2.fc17.x86_64 SMP mod_unload parm: debug:set debugging level (1=info (or-able)). (debugging is not enabled) (int) parm: firmware:set default firmware 0=Sharp7395 1=LG (int) parm: pid:set default 0=default 1=off 2=on (int) parm: adapter_nr:DVB adapter numbers (array of short) [crope@localhost linux]$ Aug 2 23:46:19 localhost kernel: [ 211.527886] usb 1-2.2: new high-speed USB device number 7 using ehci_hcd Aug 2 23:46:19 localhost kernel: [ 211.601817] usb 1-2.2: config 1 interface 0 altsetting 1 bulk endpoint 0x81 has invalid maxpacket 64 Aug 2 23:46:19 localhost kernel: [ 211.601829] usb 1-2.2: config 1 interface 0 altsetting 1 bulk endpoint 0x1 has invalid maxpacket 64 Aug 2 23:46:19 localhost kernel: [ 211.601837] usb 1-2.2: config 1 interface 0 altsetting 1 bulk endpoint 0x2 has invalid maxpacket 64 Aug 2 23:46:19 localhost kernel: [ 211.601845] usb 1-2.2: config 1 interface 0 altsetting 1 bulk endpoint 0x8A has invalid maxpacket 64 Aug 2 23:46:19 localhost kernel: [ 211.602073] usb 1-2.2: New USB device found, idVendor=3344, idProduct=22f0 Aug 2 23:46:19 localhost kernel: [ 211.602083] usb 1-2.2: New USB device strings: Mfr=0, Product=0, SerialNumber=3 Aug 2 23:46:19 localhost kernel: [ 211.602093] usb 1-2.2: SerialNumber: 䥈児 Aug 2 23:46:19 localhost mtp-probe: checking bus 1, device 7: /sys/devices/pci:00/:00:12.2/usb1/1-2/1-2.2 Aug 2 23:46:19 localhost mtp-probe: bus: 1, device: 7 was not an MTP device Aug 2 23:46:19 localhost kernel: [ 211.628508] LME2510(C): Firmware Status: 6 (44) Aug 2 23:46:19 localhost kernel: [ 211.629545] LME2510(C): FRM Loading dvb-usb-lme2510c-rs2000.fw file Aug 2 23:46:19 localhost kernel: [ 211.629551] LME2510(C): FRM Starting Firmware Download Aug 2 23:46:19 localhost kernel: [ 211.629574] BUG: unable to handle kernel NULL pointer dereference at 0008 Aug 2 23:46:19 localhost kernel: [ 211.629739] IP: [a03ac116] lme_firmware_switch+0x526/0x800 [dvb_usb_lmedm04] Aug 2 23:46:19 localhost kernel: [ 211.629900] PGD 0 Aug 2 23:46:19 localhost kernel: [ 211.629947] Oops: [#1] SMP Aug 2 23:46:19 localhost kernel: [ 211.630019] CPU 3 Aug 2 23:46:19 localhost kernel: [ 211.630058] Modules linked in: dvb_usb_lmedm04(+) dvb_usb fuse tpm_bios rfcomm bnep ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_hdmi ppdev sp5100_tco snd_hda_codec_via btusb bluetooth i2c_piix4 8139too microcode 8139cp serio_raw snd_hda_intel edac_core edac_mce_amd k10temp snd_hda_codec snd_hwdep rfkill r8169 mii cx23885 altera_ci tda18271 altera_stapl cx2341x btcx_risc videobuf_dvb dvb_core snd_pcm snd_page_alloc snd_timer snd soundcore tveeprom videobuf_dma_sg videobuf_core v4l2_common videodev media rc_core shpchp parport_pc parport asus_atk0110 uinput xts gf128mul hid_logitech_dj ata_generic pata_acpi dm_crypt pata_atiixp wmi radeon i2c_algo_bit
RE: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Hi Mauro, For the summit this time it is be just me who would be attending. The another person who was slated to join me cannot make it this time. Sorry for the delay in response. Regards Naveen -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] Sent: Tuesday, July 31, 2012 10:50 AM To: Naveen KRISHNAMURTHY Cc: Linux Media Mailing List; workshop-2...@linuxtv.org Subject: Re: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit Em 24-07-2012 21:17, Naveen KRISHNAMURTHY escreveu: Hello Mauro, We would like to participate in the media summit at San Diego. Can you please reserve 2 seats for us. Who are you planning to send to the media summit? If possible we would like to reserve a session to present how we have used the linuxTV to model our devices and support our use cases. We will also consolidate and pass on a list of questions related to spec ambiguities and hope to get it clarified during the summit! Can you please confirm back on the feasibility of our attendance? I'll be doing it along this week. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] Media summit/KS-2012 proposals
2012/8/1 Hans Verkuil hverk...@xs4all.nl: On Tue 31 July 2012 19:58:23 Mauro Carvalho Chehab wrote: In order to sum-up the discussions around the media summit, this is what we've got so far: Proposals proposed by =|= Common device tree bindings for media devices Sylvester Nawrocki / Guennadi Liakhovetski ALSA and V4L/Media Controller Steven Toth / Laurent Pinchart ARM and needed features for V4L/DVB Steven Toth Intel media SDK Steven Toth V4L compiance tool Hans Verkuil V4L2 API ambiguities Hans Verkuil Media Controller library Laurent Pincart / Sakari Ailus SoC Vendors feedback – how to help them to go upstream – Android's V4L2 cam library Laurent Pincart / Guennadi Liakhovetski / Palash Bandyopadhyay / Naveen Krishnamurthy Synchronization, shared resource and optimizations Pawel Osciak V4L2/DVB issues from userspace perspective Rémi Denis-Courmont As we'll have only one day for the summit, we may need to remove some themes, or maybe to get an extra time during LPC for the remaining discussions. Possible attendents: === Guennadi Liakhovetski Laurent Pinchart Mauro Carvalho Chehab Michael Krufky Naveen Krishnamurthy +1 seat from ST (waiting Naveen to define who will be the other seat) Palash Bandyopadhyay Pawel Osciak Rémi Denis-Courmont Sakari Ailus Steven Toth Sylvester Nawrocki Am I missing something? Are there other proposals or people intending to participate? Yes: I would like to discuss how to add support for HDMI CEC to the kernel. In particularly I need some feedback from the GPU driver developers on what their ideas are, since CEC is something that touches both V4L2 and GPU. I am not familiar with CEC implementation in GPU. But CEC should be independent in functionality with audio/video though it is A/V related. I prefer to support only CEC frame TX/RX in kernel. CEC include different category features that need parsing and may need application interaction. Venders may also configure some features as not supported. If kernel support more than TX/RX, policy may be separated to user space part and kernel space part. The kernel interface also becomes complex, maybe ambiguous too. An user space library is more suitable for this task to interact with OS/media player/audio control/etc. I'm not sure what the best place is to do this, it's a fairly specialized topic. It might be better suited to just get a few interested devs together in the evening or during some other suitable time and just see if we can hammer out some scheme. I'll have a presentation on the topic ready. Rob, what are your ideas on this? Who else might be interested in this? 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 -- 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
