Re: [PATCH 3/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
On Tuesday, October 04, 2011 07:31:27 Mauro Carvalho Chehab wrote: Em 03-10-2011 19:37, Javier Martinez Canillas escreveu: Hello, Reading the last emails I understand that still isn't a consensus on the way this has to be made. True. If it has to be implemented at the video device node level or at the sub-device level. And if it has to be made in kernel or user-space. For now, I propose you to just add/improve the auto-detection on the existing callbacks. We need to reach a consensus before working at the pad level. I agree. On Mon, Oct 3, 2011 at 11:56 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em 03-10-2011 18:44, Laurent Pinchart escreveu: Hi Mauro, On Monday 03 October 2011 21:16:45 Mauro Carvalho Chehab wrote: Em 03-10-2011 08:53, Laurent Pinchart escreveu: On Monday 03 October 2011 11:53:44 Javier Martinez Canillas wrote: [snip] Laurent, I have a few questions about MCF and the OMAP3ISP driver if you are so kind to answer. 1- User-space programs that are not MCF aware negotiate the format with the V4L2 device (i.e: OMAP3 ISP CCDC output), which is a sink pad. But the real format is driven by the analog video format in the source pad (i.e: tvp5151). That's not different from existing systems using digital sensors, where the format is driven by the sensor. I modified the ISP driver to get the data format from the source pad and set the format for each pad on the pipeline accordingly but I've read from the documentation [1] that is not correct to propagate a data format from source pads to sink pads, that the correct thing is to do it from sink to source. So, in this case an administrator has to externally configure the format for each pad and to guarantee a coherent format on the whole pipeline?. That's correct (except you don't need to be an administrator to do so :-)). NACK. Double NACK :-D When userspace sends a VIDIOC_S_STD ioctl to the sink node, the subdevs that are handling the video/audio standard should be changed, in order to obey the V4L2 ioctl. This is what happens with all other drivers since the beginning of the V4L1 API. There's no reason to change it, and such change would be a regression. The same could have been told for the format API: When userspace sends a VIDIOC_S_FMT ioctl to the sink node, the subdevs that are handling the video format should be changed, in order to obey the V4L2 ioctl. This is what happens with all other drivers since the beginning of the V4L1 API. There's no reason to change it, and such change would be a regression. But we've introduced a pad-level format API. I don't see any reason to treat standard differently. Neither do I. The pad-level API should not replace the V4L2 API for standard, for controls and/or for format settings. Remember we are talking about the subdev driver here. It makes no sense to have both a s_mbus_fmt video op and a set_fmt pad op, which both do the same thing. Bridge drivers should be adapted to use set_fmt only, so we can drop s_mbus_fmt. BTW, the names 'set_fmt' and 'get_fmt' are very confusing to me. I always think these refer to v4l2_format. Can we please rename this to g/s_mbus_fmt? And set/get_crop to s/g_crop? This for consistent naming. When it comes to S_STD I don't see the need for a pad version of this. It is an op that is used to configure subdevs to handle a specific standard. If you are configuring the pipelines manually, then after calling S_STD you have to set up the mbus formats yourself. Of course, I can generate scenarios where you would need to set the standard through the subdev node (i.e. two video receivers connected to a SoC, one receiving PAL, the other receiving NTSC, and both streams composed into a single new stream that's DMA-ed to memory), but frankly, those scenarios are very contrived :-) The preset ioctls would be more realistic since I know that a scenario like the one above does exist for e.g. HDMI inputs, where each can receive a different format. In that case the preset ioctls would have to be exposed to the subdev nodes, allowing you to set it up for each HDMI receiver independently. But you still do not need pads to do this since this is a subdev-level operation, not pad-level. Or does exist a way to do this automatic?. i.e: The output entity on the pipeline promotes the capabilities of the source pad so applications can select a data format and this format gets propagated all over the pipeline from the sink pad to the source? It can be automated in userspace (through a libv4l plugin for instance), but it's really not the kernel's job to do so. It is a kernel job to handle VIDIOC_S_STD, and not a task to be left to any userspace plugin. And VIDIOC_S_FMT is handled by userspace for the OMAP3 ISP today. Why are standards different ? All v4l media devices have sub-devices with
Re: [PATCH 3/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
On Tue, Oct 4, 2011 at 7:31 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
For now, I propose you to just add/improve the auto-detection on the
existing callbacks. We need to reach a consensus before working at the pad
level.
Ok, I'll do that using saa7115 driver as a reference as you suggested.
On Mon, Oct 3, 2011 at 11:56 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
Em 03-10-2011 18:44, Laurent Pinchart escreveu:
It can be automated in userspace (through a libv4l plugin for instance),
but it's really not the kernel's job to do so.
It is a kernel job to handle VIDIOC_S_STD, and not a task to be left to
any
userspace plugin.
And VIDIOC_S_FMT is handled by userspace for the OMAP3 ISP today. Why are
standards different ?
All v4l media devices have sub-devices with either tv decoders or sensors
connected
into a sink. The sink implements the /dev/video? node.
When an ioctl is sent to the v4l node, the sensors/decoders are controlled
to implement whatever is requested: video standards, formats etc.
Changing it would be a major regression. If OMAP3 is not doing the right
thing,
it should be fixed, and not the opposite.
That is the approach we took, we hack the isp v4l2 device driver
(ispvideo) to bypass the ioctls to the sub-device that as the source
pad (tvp5151 in our case, but it could be a sensor as well). So, for
example the VIDIOC_S_STD ioctl handler looks like this (I post a
simplified version of the code, just to give an idea):
static int isp_video_s_std(struct file *file, void *fh, v4l2_std_id *norm)
{
struct isp_video *video = video_drvdata(file);
struct v4l2_subdev *sink_subdev;
struct v4l2_subdev *source_subdev;
sink_subdev = isp_video_remote_subdev(video, NULL);
sink_pad = sink_subdev-entity.pads[0];
source_pad = media_entity_remote_source(sink_pad);
source_subdev = media_entity_to_v4l2_subdev(source_pad-entity);
v4l2_subdev_call(source_subdev, core, s_std, NULL, norm);
}
So applications interact with the /dev/video? via V4L2 ioctls whose
handlers call the sub-dev functions. Is that what you propose?
Something like that. For example:
static int vidioc_s_std(struct file *file, void *priv, v4l2_std_id *norm)
{
/* Do some sanity test/resolution adjustments, etc */
v4l2_device_call_all(dev-v4l2_dev, 0, core, s_std, dev-norm);
return 0;
}
It should be noticed that:
1) a full standard auto-detection is only possible at the V4L2 level, as a
standard is a composition of audio and video carriers. I intend to work
tomorrow
to add audio auto-detection to pvrusb2;
2) a full s_std should not only adjust the TV demod pad, but also, the audio
pad
and the tuner pad (if the analog input comes from a tuner).
Ok, got it. Thanks.
The MC/subdev API is there to fill the blanks, e. g. to handle cases where
the
same function could be implemented on two different places of the pipeline,
e. g.
when both the sensor and the bridge could do scaling, and userspace wants to
explicitly use one, or the other, but it were never meant to replace the
V4L2
functionality.
With the OMAP3 ISP, which is I believe what Javier was asking about, the
application will set the format on the OMAP3 ISP resizer input and output
pads
to configure scaling.
Yes, that was my question about. But still is not clear to me if
configuring the ISP resizer input and output pads with different frame
sizes automatically means that I have to do the scale or this has to
be configured using a S_FMT ioctl to the /dev/video? node.
Basically what I don't know is when I have to modify the pipeline
graph inside the ISP driver and when this has to be made from
user-space via MCF.
In the specific case of analog inputs, In general, better results are obtained
if the scaling is done at the analog demod, as it can play with the pixel
sampling rate, and obtaining a better result than a decimation filter. Not
all demods accept this through.
Anyway, S_FMT is expected to work at the /dev/video? node. Laurent will likely
argument against, but, again, allowing to control the scaling on a different
place is a bonus of the MC/subdev API, but it should never replace the S_FMT
V4L2 call.
The V4L2 API doesn't tell where a function like scaler will be implemented.
So, it is fine to implement it at tvp5151 or at the omap3 resizer, when a
V4L2 call is sent.
I don't think I can do the cropping and scaling in the tvp5151 driver
since this is a dumb device, it only spits bytes via its parallel
interface. The actual buffer is inside the ISP.
I wrote the tvp5150 driver from scratch a long time ago. Can't remember all
details anymore. As far as I can remember, I don't think it has scaling. Also,
its sampler seems to use a fixed pixel clock rate.
It does support crop by adjusting the blank registers. Probably there's a
limit to the range that cropping can be done, but, in general, it
Re: [PATCH 3/5] doc: v4l: add documentation for selection API
On 09/30/2011 06:52 PM, Mauro Carvalho Chehab wrote:
Em 29-09-2011 11:22, Tomasz Stanislawski escreveu:
This patch adds a documentation for VIDIOC_{G/S}_SELECTION ioctl. Moreover, the
patch adds the description of modeling of composing, cropping and scaling
features in V4L2. Finally, some examples are presented.
Hi Mauro,
The patchset works perfectly on my PC. I tested it after rebasing on the
latest linuxtv/staging/for_v3.2 . Try to call 'git clean -dfx' before
'make htmldocs'. Maybe I made some mistake configuring dependencies in
docbook. Could you help me find it?
Regards,
Tomasz Stanislawski
Doesn't work:
$ make htmldocs
GEN /home/v4l/v4l/patchwork/Documentation/DocBook//v4l2.xml
GEN /home/v4l/v4l/patchwork/Documentation/DocBook//media-entities.tmpl
GEN /home/v4l/v4l/patchwork/Documentation/DocBook//media-indices.tmpl
GEN /home/v4l/v4l/patchwork/Documentation/DocBook//videodev2.h.xml
GEN /home/v4l/v4l/patchwork/Documentation/DocBook//audio.h.xml
GEN /home/v4l/v4l/patchwork/Documentation/DocBook//ca.h.xml
GEN /home/v4l/v4l/patchwork/Documentation/DocBook//frontend.h.xml
GEN /home/v4l/v4l/patchwork/Documentation/DocBook//net.h.xml
GEN /home/v4l/v4l/patchwork/Documentation/DocBook//dmx.h.xml
GEN /home/v4l/v4l/patchwork/Documentation/DocBook//video.h.xml
DOCPROC Documentation/DocBook/media_api.xml
HTMLDocumentation/DocBook/media_api.html
/home/v4l/v4l/patchwork/Documentation/DocBook/selection-api.xml:232: parser
error : Entity 'v4l2-selection' not defined
structname v4l2-selection;/structname provides a lot of place for future
^
/home/v4l/v4l/patchwork/Documentation/DocBook/selection-api.xml:250: parser
error : Entity 'v4l2-selection' not defined
v4l2-selection; sel = {
^
/home/v4l/v4l/patchwork/Documentation/DocBook/selection-api.xml:254: parser
error : Entity 'VIDIOC-G-SELECTION' not defined
ret = ioctl(fd,VIDIOC-G-SELECTION;,amp;sel);
^
/home/v4l/v4l/patchwork/Documentation/DocBook/selection-api.xml:258: parser
error : Entity 'VIDIOC-S-SELECTION' not defined
ret = ioctl(fd,VIDIOC-S-SELECTION;,amp;sel);
^
/home/v4l/v4l/patchwork/Documentation/DocBook/selection-api.xml:271: parser
error : Entity 'v4l2-selection' not defined
v4l2-selection; sel = {
^
/home/v4l/v4l/patchwork/Documentation/DocBook/selection-api.xml:277: parser
error : Entity 'VIDIOC-G-SELECTION' not defined
ret = ioctl(fd,VIDIOC-G-SELECTION;,amp;sel);
^
/home/v4l/v4l/patchwork/Documentation/DocBook/selection-api.xml:288: parser
error : Entity 'VIDIOC-S-SELECTION' not defined
ret = ioctl(fd,VIDIOC-S-SELECTION;,amp;sel);
^
/home/v4l/v4l/patchwork/Documentation/DocBook/selection-api.xml:301: parser
error : Entity 'v4l2-selection' not defined
v4l2-selection; compose = {
^
/home/v4l/v4l/patchwork/Documentation/DocBook/selection-api.xml:305: parser
error : Entity 'v4l2-selection' not defined
v4l2-selection; crop = {
^
/home/v4l/v4l/patchwork/Documentation/DocBook/selection-api.xml:311: parser
error : Entity 'VIDIOC-G-SELECTION' not defined
ret = ioctl(fd,VIDIOC-G-SELECTION;,amp;compose);
^
/home/v4l/v4l/patchwork/Documentation/DocBook/selection-api.xml:314: parser
error : Entity 'VIDIOC-G-SELECTION' not defined
ret = ioctl(fd,VIDIOC-G-SELECTION;,amp;crop);
^
/home/v4l/v4l/patchwork/Documentation/DocBook/selection-api.xml:328: parser
error : chunk is not well balanced
^
/home/v4l/v4l/patchwork/Documentation/DocBook/common.xml:1171: parser error :
Failure to process entity sub-selection-api
sub-selection-api;
^
/home/v4l/v4l/patchwork/Documentation/DocBook/common.xml:1171: parser error :
Entity 'sub-selection-api' not defined
sub-selection-api;
^
/home/v4l/v4l/patchwork/Documentation/DocBook/v4l2.xml:423: parser error :
Failure to process entity sub-common
sub-common;
^
/home/v4l/v4l/patchwork/Documentation/DocBook/v4l2.xml:423: parser error :
Entity 'sub-common' not defined
sub-common;
^
Signed-off-by: Tomasz Stanislawskit.stanisl...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
Documentation/DocBook/media/v4l/common.xml |2 +
Documentation/DocBook/media/v4l/compat.xml |9 +
Documentation/DocBook/media/v4l/selection-api.xml | 327
Documentation/DocBook/media/v4l/v4l2.xml |1 +
.../DocBook/media/v4l/vidioc-g-selection.xml | 303 ++
5 files changed, 642
PULL request for 3.2 (fixes 'n' features)
Hi Mauro, if it's not too late for 3.2 could you please pull from git://linuxtv.org/pb/media_tree.git staging/for_v3.2 for [media] dib9090: limit the I2C speed [media] dib8096P: add the reference board [media] add the support for DiBcom [media] dib7090: add the reference board [media] DiB8000: improve the tuning and the SNR monitoring [media] DiBcom: correct warnings [media] dib7090: add the reference board TFE7090E [media] dib7000p/dib0090: update the driver Thanks a lot in advance, -- Patrick -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] tvp5150: Migrate to media-controller framework and add video format detection
Em 04-10-2011 04:03, Hans Verkuil escreveu: On Tuesday, October 04, 2011 07:31:27 Mauro Carvalho Chehab wrote: Em 03-10-2011 19:37, Javier Martinez Canillas escreveu: Hello, Reading the last emails I understand that still isn't a consensus on the way this has to be made. True. If it has to be implemented at the video device node level or at the sub-device level. And if it has to be made in kernel or user-space. For now, I propose you to just add/improve the auto-detection on the existing callbacks. We need to reach a consensus before working at the pad level. I agree. On Mon, Oct 3, 2011 at 11:56 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em 03-10-2011 18:44, Laurent Pinchart escreveu: Hi Mauro, On Monday 03 October 2011 21:16:45 Mauro Carvalho Chehab wrote: Em 03-10-2011 08:53, Laurent Pinchart escreveu: On Monday 03 October 2011 11:53:44 Javier Martinez Canillas wrote: [snip] Laurent, I have a few questions about MCF and the OMAP3ISP driver if you are so kind to answer. 1- User-space programs that are not MCF aware negotiate the format with the V4L2 device (i.e: OMAP3 ISP CCDC output), which is a sink pad. But the real format is driven by the analog video format in the source pad (i.e: tvp5151). That's not different from existing systems using digital sensors, where the format is driven by the sensor. I modified the ISP driver to get the data format from the source pad and set the format for each pad on the pipeline accordingly but I've read from the documentation [1] that is not correct to propagate a data format from source pads to sink pads, that the correct thing is to do it from sink to source. So, in this case an administrator has to externally configure the format for each pad and to guarantee a coherent format on the whole pipeline?. That's correct (except you don't need to be an administrator to do so :-)). NACK. Double NACK :-D When userspace sends a VIDIOC_S_STD ioctl to the sink node, the subdevs that are handling the video/audio standard should be changed, in order to obey the V4L2 ioctl. This is what happens with all other drivers since the beginning of the V4L1 API. There's no reason to change it, and such change would be a regression. The same could have been told for the format API: When userspace sends a VIDIOC_S_FMT ioctl to the sink node, the subdevs that are handling the video format should be changed, in order to obey the V4L2 ioctl. This is what happens with all other drivers since the beginning of the V4L1 API. There's no reason to change it, and such change would be a regression. But we've introduced a pad-level format API. I don't see any reason to treat standard differently. Neither do I. The pad-level API should not replace the V4L2 API for standard, for controls and/or for format settings. Remember we are talking about the subdev driver here. It makes no sense to have both a s_mbus_fmt video op and a set_fmt pad op, which both do the same thing. Bridge drivers should be adapted to use set_fmt only, so we can drop s_mbus_fmt. Agreed. BTW, the names 'set_fmt' and 'get_fmt' are very confusing to me. I always think these refer to v4l2_format. Can we please rename this to g/s_mbus_fmt? And set/get_crop to s/g_crop? This for consistent naming. When it comes to S_STD I don't see the need for a pad version of this. It is an op that is used to configure subdevs to handle a specific standard. If you are configuring the pipelines manually, then after calling S_STD you have to set up the mbus formats yourself. Of course, I can generate scenarios where you would need to set the standard through the subdev node (i.e. two video receivers connected to a SoC, one receiving PAL, the other receiving NTSC, and both streams composed into a single new stream that's DMA-ed to memory), but frankly, those scenarios are very contrived :-) Even a very rare scenario like the above could be easily implemented with V4L2 API, using 3 video nodes, one for each receiver, and another for the composed stream. A device like ivtv or cx25821 probably can do that already, maybe with a few adjustments at the driver. The preset ioctls would be more realistic since I know that a scenario like the one above does exist for e.g. HDMI inputs, where each can receive a different format. In that case the preset ioctls would have to be exposed to the subdev nodes, allowing you to set it up for each HDMI receiver independently. But you still do not need pads to do this since this is a subdev-level operation, not pad-level. Or does exist a way to do this automatic?. i.e: The output entity on the pipeline promotes the capabilities of the source pad so applications can select a data format and this format gets propagated all over the pipeline from the sink pad to the source? It can be automated in userspace (through a libv4l plugin for instance), but it's really not
Re: Help with omap3isp resizing
Hi Paul, On Monday 03 October 2011 07:51:34 Paul Chiha wrote: Hi, I've been having trouble getting the resizer to work, and mainly because I don't know how to correctly configure it. I'm using kernel 2.6.37 on arm DM37x board. I've been able to configure the media links sensor=ccdc=ccdc_output (all with 640x480 V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on /dev/video2. But if I configure media links sensor=ccdc=resizer=resizer_output, then VIDIOC_STREAMON fails on /dev/video6 (with pixelformat mismatch). I noticed that the resizer driver only supports V4L2_MBUS_FMT_UYVY8_1X16 V4L2_MBUS_FMT_YUYV8_1X16, so I tried again with all the links set to V4L2_MBUS_FMT_UYVY8_1X16 instead, but then ioctl VIDIOC_SUBDEV_S_FMT fails on /dev/v4l-subdev8, because the sensor driver doesn't support 1X16. Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the sensor and V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either failed with pixelformat mismatch or link pipeline mismatch, depending on which pads were different. Can someone please tell me what I need to do to make this work? Long story short, I don't think that pipeline has ever been tested. I'm unfortunately lacking hardware to work on that, as none of my OMAP3 hardware has a YUV input. -- 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: Help with omap3isp resizing
Hi Ivan,
On Tuesday 04 October 2011 13:46:32 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:03 +0200, Laurent Pinchart wrote:
On Monday 03 October 2011 07:51:34 Paul Chiha wrote:
Hi,
I've been having trouble getting the resizer to work, and mainly
because I don't know how to correctly configure it.
I'm using kernel 2.6.37 on arm DM37x board.
I've been able to configure the media links sensor=ccdc=ccdc_output
(all with 640x480 V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on
/dev/video2.
But if I configure media links sensor=ccdc=resizer=resizer_output,
then VIDIOC_STREAMON fails on /dev/video6 (with pixelformat mismatch).
I noticed that the resizer driver only supports
V4L2_MBUS_FMT_UYVY8_1X16 V4L2_MBUS_FMT_YUYV8_1X16, so I tried again
with all the links set to V4L2_MBUS_FMT_UYVY8_1X16 instead, but then
ioctl VIDIOC_SUBDEV_S_FMT fails on /dev/v4l-subdev8, because the
sensor driver doesn't support 1X16.
Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the sensor and
V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either failed with
pixelformat mismatch or link pipeline mismatch, depending on which pads
were different.
Can someone please tell me what I need to do to make this work?
Long story short, I don't think that pipeline has ever been tested. I'm
unfortunately lacking hardware to work on that, as none of my OMAP3
hardware has a YUV input.
If i am not mistaken currently resizer sub device supports only:
/* resizer pixel formats */
static const unsigned int resizer_formats[] = {
V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,
};
Adding something like this [1] in ispresizer.c should add
support 2X8 formats. Completely untested :-).
Regards,
iivanov
[1]
@@ -1307,6 +1311,10 @@ static int resizer_s_crop(struct v4l2_subdev *sd,
struct v4l2_subdev_fh *fh, static const unsigned int resizer_formats[] = {
V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,
+ V4L2_MBUS_FMT_UYVY8_2X8,
+ V4L2_MBUS_FMT_VYUY8_2X8,
+ V4L2_MBUS_FMT_YUYV8_2X8,
+ V4L2_MBUS_FMT_YVYU8_2X8,
};
I'd rather modify ispccdc.c to output V4L2_MBUS_FMT_YUYV8_1X16. What do you
think ?
static unsigned int resizer_max_in_width(struct isp_res_device *res)
@@ -1340,12 +1348,21 @@ static void resizer_try_format(struct
isp_res_device *res, struct resizer_ratio ratio;
struct v4l2_rect crop;
+ switch (fmt-code) {
+
+ case V4L2_MBUS_FMT_YUYV8_1X16:
+ case V4L2_MBUS_FMT_UYVY8_1X16:
+ case V4L2_MBUS_FMT_UYVY8_2X8:
+ case V4L2_MBUS_FMT_VYUY8_2X8:
+ case V4L2_MBUS_FMT_YUYV8_2X8:
+ case V4L2_MBUS_FMT_YVYU8_2X8:
+ break;
+ default:
+ fmt-code = V4L2_MBUS_FMT_YUYV8_1X16;
+ }
+
switch (pad) {
case RESZ_PAD_SINK:
- if (fmt-code != V4L2_MBUS_FMT_YUYV8_1X16
- fmt-code != V4L2_MBUS_FMT_UYVY8_1X16)
- fmt-code = V4L2_MBUS_FMT_YUYV8_1X16;
-
fmt-width = clamp_t(u32, fmt-width, MIN_IN_WIDTH,
resizer_max_in_width(res));
fmt-height = clamp_t(u32, fmt-height, MIN_IN_HEIGHT,
--
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: [DVB] CXD2099 - Question about the CAM clock
I managed to find a series of values that are working correctly for MCLKI: MCLKI = 0x5554 - i * 0x0c In my case I can go down to 0x5338 before having TS errors. From CXD2099 specs -- It is a requirement for the frequency of MCLKI to be set higher than the input data rate. ie 8 times TICLK. If this condition is not met then the internal buffer will overflow and the register TSIN_FIFO_OVFL is set to 1. This register should be read at regular intervals to ensure reliable operation. -- Watch out that you're not slowly overflowing the internal buffer if MCLKI is not fast enough... Are you working with the ddbridge ? -- Issa -- 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: Help with omap3isp resizing
Hi Ivan,
On Tuesday 04 October 2011 13:54:12 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:50 +0200, Laurent Pinchart wrote:
On Tuesday 04 October 2011 13:46:32 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:03 +0200, Laurent Pinchart wrote:
On Monday 03 October 2011 07:51:34 Paul Chiha wrote:
Hi,
I've been having trouble getting the resizer to work, and mainly
because I don't know how to correctly configure it.
I'm using kernel 2.6.37 on arm DM37x board.
I've been able to configure the media links
sensor=ccdc=ccdc_output (all with 640x480
V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on /dev/video2.
But if I configure media links
sensor=ccdc=resizer=resizer_output, then VIDIOC_STREAMON fails
on /dev/video6 (with pixelformat mismatch). I noticed that the
resizer driver only supports
V4L2_MBUS_FMT_UYVY8_1X16 V4L2_MBUS_FMT_YUYV8_1X16, so I tried
again with all the links set to V4L2_MBUS_FMT_UYVY8_1X16 instead,
but then ioctl VIDIOC_SUBDEV_S_FMT fails on /dev/v4l-subdev8,
because the sensor driver doesn't support 1X16.
Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the sensor and
V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either failed with
pixelformat mismatch or link pipeline mismatch, depending on which
pads were different.
Can someone please tell me what I need to do to make this work?
Long story short, I don't think that pipeline has ever been tested.
I'm unfortunately lacking hardware to work on that, as none of my
OMAP3 hardware has a YUV input.
If i am not mistaken currently resizer sub device supports only:
/* resizer pixel formats */
static const unsigned int resizer_formats[] = {
V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,
};
Adding something like this [1] in ispresizer.c should add
support 2X8 formats. Completely untested :-).
Regards,
iivanov
[1]
@@ -1307,6 +1311,10 @@ static int resizer_s_crop(struct v4l2_subdev
*sd, struct v4l2_subdev_fh *fh, static const unsigned int
resizer_formats[] = {
V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,
+ V4L2_MBUS_FMT_UYVY8_2X8,
+ V4L2_MBUS_FMT_VYUY8_2X8,
+ V4L2_MBUS_FMT_YUYV8_2X8,
+ V4L2_MBUS_FMT_YVYU8_2X8,
};
I'd rather modify ispccdc.c to output V4L2_MBUS_FMT_YUYV8_1X16. What do
you think ?
For memory-Resizer-memory use cases, CCDC is no involved in pipeline.
But the original poster wants to use the sensor - ccdc - resizer - resizer
output pipeline.
Also several sensor drivers that i have checked, usually define its
output as 2X8 output. I think is more natural to add 2X8 support to
CCDC and Resizer engines instead to modifying exiting drivers.
Sure, sensor drivers should not be modified. What I was talking about was to
configure the pipeline as
sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16], resizer:0
[YUYV8_1X16]
--
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
UK DVB-T uk-Ramsbottom config
Hello, Please find below the DVB-T frequencies for the Ramsbottom, Lancashire, UK transmitter. #-- # file automatically generated by w_scan # (http://wirbel.htpc-forum.de/w_scan/index2.html) #! w_scan 20110702 1 0 OFDM GB /w_scan #-- # location and provider: Ramsbottom, Lancashire, UK # date (-mm-dd) : 2011-10-03 # provided by (opt) : tim.gib...@lunarlite.co.uk # # T[2] freq bw fec_hi fec_lo mod tm guard hi [# comment] #-- T 49000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO T 51400 8MHz AUTO AUTO AUTO AUTO AUTO AUTO T 74600 8MHz 2/3 NONE QAM64 8k 1/32 NONE T 76200 8MHz 1/2 NONE QPSK 8k 1/32 NONE T 801833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE T 77800 8MHz 2/3 NONE QAM64 8k 1/32 NONE T 77000 8MHz 2/3 NONE QAM64 8k 1/32 NONE T 793833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE T 73000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO # North West T 78600 8MHz AUTO AUTO AUTO AUTO AUTO AUTO # North West Please could this be added to the UK transmitters? More information on the transmitter should it be required. http://www.ukfree.tv/shutdowndetail.php?tx=SD803159 tng -- 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 7/9] V4L: soc-camera: add a Media Controller wrapper
On Mon, 3 Oct 2011, Laurent Pinchart wrote:
Hi Guennadi,
On Monday 03 October 2011 17:29:23 Guennadi Liakhovetski wrote:
Hi Laurent
Thanks for the reviews!
You're welcome.
On Mon, 3 Oct 2011, Laurent Pinchart wrote:
On Thursday 29 September 2011 18:18:55 Guennadi Liakhovetski wrote:
This wrapper adds a Media Controller implementation to soc-camera
drivers. To really benefit from it individual host drivers should
implement support for values of enum soc_camera_target other than
SOCAM_TARGET_PIPELINE in their .set_fmt() and .try_fmt() methods.
[snip]
diff --git a/drivers/media/video/soc_entity.c
b/drivers/media/video/soc_entity.c new file mode 100644
index 000..3a04700
--- /dev/null
+++ b/drivers/media/video/soc_entity.c
@@ -0,0 +1,284 @@
[snip]
+static int bus_sd_pad_g_fmt(struct v4l2_subdev *sd, struct
v4l2_subdev_fh *fh,
+ struct v4l2_subdev_format *sd_fmt)
+{
+ struct soc_camera_device *icd = v4l2_get_subdevdata(sd);
+ struct v4l2_mbus_framefmt *f = sd_fmt-format;
+
+ if (sd_fmt-which == V4L2_SUBDEV_FORMAT_TRY) {
+ sd_fmt-format = *v4l2_subdev_get_try_format(fh,
sd_fmt-pad);
+ return 0;
+ }
+
+ if (sd_fmt-pad == SOC_HOST_BUS_PAD_SINK) {
+ f-width= icd-host_input_width;
+ f-height = icd-host_input_height;
+ } else {
+ f-width= icd-user_width;
+ f-height = icd-user_height;
+ }
+ f-field= icd-field;
+ f-code = icd-current_fmt-code;
+ f-colorspace = icd-colorspace;
Can soc-camera hosts perform format conversion ? If so you will likely
need to store the mbus code for the input and output separately,
possibly in v4l2_mbus_format fields. You could then simplify the
[gs]_fmt functions by implementing similar to the __*_get_format
functions in the OMAP3 ISP driver.
They can, yes. But, under soc-camera conversions are performed between
mediabus codes and fourcc formats. Upon pipeline construction (probing) a
table of format conversions is built, where hosts generate one or more
translation entries for all client formats, that they support. The only
example of a more complex translations so far is MIPI CSI-2, but even
there we have decided to identify CSI-2 formats using the same media-bus
codes, as what you get between the CSI-2 block and the DMA engine. For
the only CSI-2 capable soc-camera host so far - the CEU driver - this is
also a very natural representation, because there the CSI-2 block is
indeed an additional pipeline stage, uniquely translating CSI-2 to
media-bus codes, that are then fed to the CEU parallel port.
How does that work with the MC API then ? If the bridge can, let's say,
convert between raw bayer and YUV, shouldn't the format at the bridge input
be
raw bayer and at the bridge output YUV ?
Doesn't it depend on your definition? I define the conversion as taking
place on the DMA-engine entity. I.e., a media-bus code is transferred
unchanged all the way down to that entity and there it gets converted to
one of fourcc formats for storage in the memory. Isn't what you are
suggesting some kind of a t2o-stage conversion: first you convert one
media-bus code to another one, then you convert the latter one to some
fourcc, which is also not a one-to-one conversion.
[snip]
+int soc_camera_mc_streamon(struct soc_camera_device *icd)
+{
+ struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+ struct v4l2_subdev *bus_sd = ici-bus_sd;
+ struct media_entity *bus_me = bus_sd-entity;
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ struct v4l2_mbus_framefmt mf;
+ int ret = v4l2_subdev_call(sd, video, g_mbus_fmt, mf);
+ if (WARN_ON(ret 0))
+ return ret;
+ if (icd-host_input_width != mf.width ||
+ icd-host_input_height != mf.height ||
+ icd-current_fmt-code != mf.code)
+ return -EINVAL;
Shouldn't you also check that the source pad format matches the video
node format ?
I think, that's true by construction. It is already cheked in
soc_camera_set_fmt():
} else if (!icd-current_fmt ||
icd-current_fmt-host_fmt-fourcc != pix-pixelformat) {
dev_err(icd-pdev,
Host driver hasn't set up current format
correctly!\n);
return -EINVAL;
But aren't applications allowed to configure the format at the bridge output
pad first ?
They are. In either case an mbus - fourcc translation is selected and the
.current_fmt is filled.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
Re: Help with omap3isp resizing
Hi Laurent,
On Tue, 2011-10-04 at 15:00 +0200, Laurent Pinchart wrote:
Hi Ivan,
On Tuesday 04 October 2011 13:54:12 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:50 +0200, Laurent Pinchart wrote:
On Tuesday 04 October 2011 13:46:32 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:03 +0200, Laurent Pinchart wrote:
On Monday 03 October 2011 07:51:34 Paul Chiha wrote:
Hi,
I've been having trouble getting the resizer to work, and mainly
because I don't know how to correctly configure it.
I'm using kernel 2.6.37 on arm DM37x board.
I've been able to configure the media links
sensor=ccdc=ccdc_output (all with 640x480
V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on /dev/video2.
But if I configure media links
sensor=ccdc=resizer=resizer_output, then VIDIOC_STREAMON fails
on /dev/video6 (with pixelformat mismatch). I noticed that the
resizer driver only supports
V4L2_MBUS_FMT_UYVY8_1X16 V4L2_MBUS_FMT_YUYV8_1X16, so I tried
again with all the links set to V4L2_MBUS_FMT_UYVY8_1X16 instead,
but then ioctl VIDIOC_SUBDEV_S_FMT fails on /dev/v4l-subdev8,
because the sensor driver doesn't support 1X16.
Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the sensor and
V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either failed with
pixelformat mismatch or link pipeline mismatch, depending on which
pads were different.
Can someone please tell me what I need to do to make this work?
Long story short, I don't think that pipeline has ever been tested.
I'm unfortunately lacking hardware to work on that, as none of my
OMAP3 hardware has a YUV input.
If i am not mistaken currently resizer sub device supports only:
/* resizer pixel formats */
static const unsigned int resizer_formats[] = {
V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,
};
Adding something like this [1] in ispresizer.c should add
support 2X8 formats. Completely untested :-).
Regards,
iivanov
[1]
@@ -1307,6 +1311,10 @@ static int resizer_s_crop(struct v4l2_subdev
*sd, struct v4l2_subdev_fh *fh, static const unsigned int
resizer_formats[] = {
V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,
+ V4L2_MBUS_FMT_UYVY8_2X8,
+ V4L2_MBUS_FMT_VYUY8_2X8,
+ V4L2_MBUS_FMT_YUYV8_2X8,
+ V4L2_MBUS_FMT_YVYU8_2X8,
};
I'd rather modify ispccdc.c to output V4L2_MBUS_FMT_YUYV8_1X16. What do
you think ?
For memory-Resizer-memory use cases, CCDC is no involved in pipeline.
But the original poster wants to use the sensor - ccdc - resizer - resizer
output pipeline.
Ah, right, i have miss that,
Also several sensor drivers that i have checked, usually define its
output as 2X8 output. I think is more natural to add 2X8 support to
CCDC and Resizer engines instead to modifying exiting drivers.
Sure, sensor drivers should not be modified. What I was talking about was to
configure the pipeline as
sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16], resizer:0
[YUYV8_1X16]
This sound simpler and reasonable. In this case maybe for every
reference to V4L2_MBUS_FMT_8_2X8 in ispccdc.c, additional
V4L2_MBUS_FMT_xxx8_1X16 can be added.
Regards,
iivanov
--
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: WARNINGS
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:Tue Oct 4 19:00:22 CEST 2011 git hash:2f4cf2c3a971c4d5154def8ef9ce4811d702852d gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.7-amd64 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS 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-rc1-i686: 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-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] af9013 frontend tuner bus lock
2011/9/28 tvboxspy tvbox...@gmail.com:
Frontend bus lock for af9015 devices.
Last week, I aqcuired a dual KWorld PlusTV Dual DVB-T Stick (DVB-T 399U).
The lock is intended for dual frontends that share the same tuner I2C address
to stop either frontend sending data while any gate is open. The patch
should have no effect on single devices or multiple single devices, well
not on the ones I have!
It also delays read_status call backs being sent while either gate is open, a
mostly like cause of corruption.
The lock also covers the attachment process of the tuner in case there is any
race condition, although unlikely.
Points about troubles with Myth TV;
Streaming corruptions are more likely to appear from the I2C noise generated
from setting either frontend. Afatech love their bits as bytes:-)
Latest version of Myth TV appears to have a bug where you can't select the
second
frontend independently and when it does it tunes to the same frequency as
the first frontend!
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/dvb-usb/af9015.c | 7 ++-
drivers/media/dvb/frontends/af9013.c | 13 -
drivers/media/dvb/frontends/af9013.h | 5 +++--
3 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index c6c275b..0089858 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -43,6 +43,7 @@ MODULE_PARM_DESC(remote, select remote);
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
static DEFINE_MUTEX(af9015_usb_mutex);
+static DEFINE_MUTEX(af9015_fe_mutex);
static struct af9015_config af9015_config;
static struct dvb_usb_device_properties af9015_properties[3];
@@ -1114,7 +1115,7 @@ static int af9015_af9013_frontend_attach(struct
dvb_usb_adapter *adap)
/* attach demodulator */
adap-fe_adap[0].fe = dvb_attach(af9013_attach,
af9015_af9013_config[adap-id],
- adap-dev-i2c_adap);
+ adap-dev-i2c_adap, af9015_fe_mutex);
return adap-fe_adap[0].fe == NULL ? -ENODEV : 0;
}
@@ -1187,6 +1188,9 @@ static int af9015_tuner_attach(struct dvb_usb_adapter
*adap)
int ret;
deb_info(%s:\n, __func__);
+ if (mutex_lock_interruptible(af9015_fe_mutex) 0)
+ return -EAGAIN;
+
switch (af9015_af9013_config[adap-id].tuner) {
case AF9013_TUNER_MT2060:
case AF9013_TUNER_MT2060_2:
@@ -1242,6 +1246,7 @@ static int af9015_tuner_attach(struct dvb_usb_adapter
*adap)
err(Unknown tuner id:%d,
af9015_af9013_config[adap-id].tuner);
}
+ mutex_unlock(af9015_fe_mutex);
return ret;
}
diff --git a/drivers/media/dvb/frontends/af9013.c
b/drivers/media/dvb/frontends/af9013.c
index 345311c..b220a87 100644
--- a/drivers/media/dvb/frontends/af9013.c
+++ b/drivers/media/dvb/frontends/af9013.c
@@ -50,6 +50,7 @@ struct af9013_state {
u16 snr;
u32 frequency;
unsigned long next_statistics_check;
+ struct mutex *fe_mutex;
};
static u8 regmask[8] = { 0x01, 0x03, 0x07, 0x0f, 0x1f, 0x3f, 0x7f, 0xff };
@@ -630,9 +631,14 @@ static int af9013_set_frontend(struct dvb_frontend *fe,
state-frequency = params-frequency;
/* program tuner */
+ if (mutex_lock_interruptible(state-fe_mutex) 0)
+ return -EAGAIN;
+
if (fe-ops.tuner_ops.set_params)
fe-ops.tuner_ops.set_params(fe, params);
+ mutex_unlock(state-fe_mutex);
+
/* program CFOE coefficients */
ret = af9013_set_coeff(state, params-u.ofdm.bandwidth);
if (ret)
@@ -1038,6 +1044,9 @@ static int af9013_read_status(struct dvb_frontend *fe,
fe_status_t *status)
u8 tmp;
*status = 0;
+ if (mutex_lock_interruptible(state-fe_mutex) 0)
+ return -EAGAIN;
+
/* MPEG2 lock */
ret = af9013_read_reg_bits(state, 0xd507, 6, 1, tmp);
if (ret)
@@ -1086,6 +1095,7 @@ static int af9013_read_status(struct dvb_frontend *fe,
fe_status_t *status)
ret = af9013_update_statistics(fe);
error:
+ mutex_unlock(state-fe_mutex);
return ret;
}
@@ -1446,7 +1456,7 @@ static void af9013_release(struct dvb_frontend *fe)
static struct dvb_frontend_ops af9013_ops;
struct dvb_frontend *af9013_attach(const struct af9013_config *config,
- struct i2c_adapter *i2c)
+ struct i2c_adapter *i2c, struct mutex *fe_mutex)
{
int ret;
struct af9013_state *state = NULL;
@@ -1459,6 +1469,7 @@ struct dvb_frontend *af9013_attach(const struct
af9013_config *config,
/* setup the state */
state-i2c = i2c;
+ state-fe_mutex = fe_mutex;
memcpy(state-config, config, sizeof(struct af9013_config));
/* download firmware */
diff --git a/drivers/media/dvb/frontends/af9013.h
[PATCHv2 1/8] [media] saa7115: Fix standards detection
There are several bugs at saa7115 standards detection:
After the fix, the driver is returning the proper standards,
as tested with 3 different broadcast sources:
On an invalid channel (without any TV signal):
[ 4394.931630] saa7115 15-0021: Status byte 2 (0x1f)=0xe0
[ 4394.931635] saa7115 15-0021: detected std mask = 00ff
With a PAL/M signal:
[ 4410.836855] saa7115 15-0021: Status byte 2 (0x1f)=0xb1
[ 4410.837727] saa7115 15-0021: Status byte 1 (0x1e)=0x82
[ 4410.837731] saa7115 15-0021: detected std mask = 0900
With a NTSC/M signal:
[ 4422.383893] saa7115 15-0021: Status byte 2 (0x1f)=0xb1
[ 4422.384768] saa7115 15-0021: Status byte 1 (0x1e)=0x81
[ 4422.384772] saa7115 15-0021: detected std mask = b000
Tests were done with a WinTV PVR USB2 Model 29xx card.
Reviewed-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/saa7115.c | 47 +++-
1 files changed, 32 insertions(+), 15 deletions(-)
diff --git a/drivers/media/video/saa7115.c b/drivers/media/video/saa7115.c
index cee98ea..86627a8 100644
--- a/drivers/media/video/saa7115.c
+++ b/drivers/media/video/saa7115.c
@@ -1344,35 +1344,52 @@ static int saa711x_g_vbi_data(struct v4l2_subdev *sd,
struct v4l2_sliced_vbi_dat
static int saa711x_querystd(struct v4l2_subdev *sd, v4l2_std_id *std)
{
struct saa711x_state *state = to_state(sd);
- int reg1e;
+ int reg1f, reg1e;
- *std = V4L2_STD_ALL;
- if (state-ident != V4L2_IDENT_SAA7115) {
- int reg1f = saa711x_read(sd, R_1F_STATUS_BYTE_2_VD_DEC);
-
- if (reg1f 0x20)
- *std = V4L2_STD_525_60;
- else
- *std = V4L2_STD_625_50;
-
- return 0;
+ reg1f = saa711x_read(sd, R_1F_STATUS_BYTE_2_VD_DEC);
+ v4l2_dbg(1, debug, sd, Status byte 2 (0x1f)=0x%02x\n, reg1f);
+ if (reg1f 0x40) {
+ /* horizontal/vertical not locked */
+ *std = V4L2_STD_ALL;
+ goto ret;
}
+ if (reg1f 0x20)
+ *std = V4L2_STD_525_60;
+ else
+ *std = V4L2_STD_625_50;
+
+ if (state-ident != V4L2_IDENT_SAA7115)
+ goto ret;
reg1e = saa711x_read(sd, R_1E_STATUS_BYTE_1_VD_DEC);
switch (reg1e 0x03) {
case 1:
- *std = V4L2_STD_NTSC;
+ *std = V4L2_STD_NTSC;
break;
case 2:
- *std = V4L2_STD_PAL;
+ /*
+* V4L2_STD_PAL just cover the european PAL standards.
+* This is wrong, as the device could also be using an
+* other PAL standard.
+*/
+ *std = V4L2_STD_PAL | V4L2_STD_PAL_N | V4L2_STD_PAL_Nc |
+ V4L2_STD_PAL_M | V4L2_STD_PAL_60;
break;
case 3:
- *std = V4L2_STD_SECAM;
+ *std = V4L2_STD_SECAM;
break;
default:
+ /* Can't detect anything */
+ *std = V4L2_STD_ALL;
break;
}
+
+ v4l2_dbg(1, debug, sd, Status byte 1 (0x1e)=0x%02x\n, reg1e);
+
+ret:
+ v4l2_dbg(1, debug, sd, detected std mask = %08Lx\n, *std);
+
return 0;
}
--
1.7.6.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
[PATCHv2 2/8] [media] pvrusb2: implement VIDIOC_QUERYSTD
Acked-by: Mike Isely is...@pobox.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/pvrusb2/pvrusb2-hdw.c |7 +++
drivers/media/video/pvrusb2/pvrusb2-hdw.h |3 +++
drivers/media/video/pvrusb2/pvrusb2-v4l2.c |7 +++
3 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
index e98d382..5a6f24d 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
@@ -2993,6 +2993,13 @@ static void pvr2_subdev_set_control(struct pvr2_hdw
*hdw, int id,
pvr2_subdev_set_control(hdw, id, #lab, (hdw)-lab##_val); \
}
+int pvr2_hdw_get_detected_std(struct pvr2_hdw *hdw, v4l2_std_id *std)
+{
+ v4l2_device_call_all(hdw-v4l2_dev, 0,
+video, querystd, std);
+ return 0;
+}
+
/* Execute whatever commands are required to update the state of all the
sub-devices so that they match our current control values. */
static void pvr2_subdev_update(struct pvr2_hdw *hdw)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.h
b/drivers/media/video/pvrusb2/pvrusb2-hdw.h
index d7753ae..6654658 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-hdw.h
+++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.h
@@ -214,6 +214,9 @@ struct pvr2_stream *pvr2_hdw_get_video_stream(struct
pvr2_hdw *);
int pvr2_hdw_get_stdenum_value(struct pvr2_hdw *hdw,struct v4l2_standard *std,
unsigned int idx);
+/* Get the detected video standard */
+int pvr2_hdw_get_detected_std(struct pvr2_hdw *hdw, v4l2_std_id *std);
+
/* Enable / disable retrieval of CPU firmware or prom contents. This must
be enabled before pvr2_hdw_cpufw_get() will function. Note that doing
this may prevent the device from running (and leaving this mode may
diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
index e27f8ab..0d029da 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
@@ -227,6 +227,13 @@ static long pvr2_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
break;
}
+ case VIDIOC_QUERYSTD:
+ {
+ v4l2_std_id *std = arg;
+ ret = pvr2_hdw_get_detected_std(hdw, std);
+ break;
+ }
+
case VIDIOC_G_STD:
{
int val = 0;
--
1.7.6.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
[PATCHv2 4/8] [media] saa7115: Trust that V4L2 core will fill the mask
Instead of using V4L2_STD_ALL when no standard is detected,
trust that the maximum allowed standards are already filled by
the V4L2 core. It is better this way, as the bridge and/or the audio
decoder may have some extra restrictions to some video standards.
This also allow other devices like audio and tuners to contribute to
standards detection, when they support such feature.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/saa7115.c | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/saa7115.c b/drivers/media/video/saa7115.c
index 86627a8..5cfdbc7 100644
--- a/drivers/media/video/saa7115.c
+++ b/drivers/media/video/saa7115.c
@@ -1346,17 +1346,23 @@ static int saa711x_querystd(struct v4l2_subdev *sd,
v4l2_std_id *std)
struct saa711x_state *state = to_state(sd);
int reg1f, reg1e;
+ /*
+* The V4L2 core already initializes std with all supported
+* Standards. All driver needs to do is to mask it, to remove
+* standards that don't apply from the mask
+*/
+
reg1f = saa711x_read(sd, R_1F_STATUS_BYTE_2_VD_DEC);
v4l2_dbg(1, debug, sd, Status byte 2 (0x1f)=0x%02x\n, reg1f);
- if (reg1f 0x40) {
- /* horizontal/vertical not locked */
- *std = V4L2_STD_ALL;
+
+ /* horizontal/vertical not locked */
+ if (reg1f 0x40)
goto ret;
- }
+
if (reg1f 0x20)
- *std = V4L2_STD_525_60;
+ *std = V4L2_STD_525_60;
else
- *std = V4L2_STD_625_50;
+ *std = V4L2_STD_625_50;
if (state-ident != V4L2_IDENT_SAA7115)
goto ret;
@@ -1381,7 +1387,6 @@ static int saa711x_querystd(struct v4l2_subdev *sd,
v4l2_std_id *std)
break;
default:
/* Can't detect anything */
- *std = V4L2_STD_ALL;
break;
}
--
1.7.6.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
[PATCHv2 5/8] [media] pvrusb2: initialize standards mask before detecting standard
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/pvrusb2/pvrusb2-v4l2.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
index 0d029da..ce7ac45 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
@@ -230,6 +230,7 @@ static long pvr2_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
case VIDIOC_QUERYSTD:
{
v4l2_std_id *std = arg;
+ *std = V4L2_STD_ALL;
ret = pvr2_hdw_get_detected_std(hdw, std);
break;
}
--
1.7.6.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: Cypress EZ-USB FX2 firmware development
Hi Antti, I would like to made own firmware for Cypress FX2 based DVB device. Is there any sample to look example? I've done multiple FX2 firmware projects in the past, including DVB-T. The technical reference manual for the FX2 explains the GPIF waveform sampling engine very well. It also shows sample firmware listings for operating the fifo engine in the different input or output modes. You'll find it via google. If you have specific questions then I'd be happy to answer them on the mailing-list. -- Steven Toth - 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: [PATCH] af9013 frontend tuner bus lock
I have had some luck with this patch. I am still getting fouled
recordings with tuner A but it's not consistent. I have yet to
ascertain if the problem occurs depending on the order of tuning to
have both tuners recording different frquencies at the same time, ie
Tuner B then Tuner A or vice versa.
Malcolm, did you say there was a MythTV tubing bug? Do you have an
URL for the bug if it has been reported?
I fear I might have a multi-layered problem - not only the Afatech
tuners but perhaps some PCI issue too. It doesn't help if MythTV
isn't doing the right thing either.
On 5 October 2011 06:28, Josu Lazkano josu.lazk...@gmail.com wrote:
2011/9/28 tvboxspy tvbox...@gmail.com:
Frontend bus lock for af9015 devices.
Last week, I aqcuired a dual KWorld PlusTV Dual DVB-T Stick (DVB-T 399U).
The lock is intended for dual frontends that share the same tuner I2C address
to stop either frontend sending data while any gate is open. The patch
should have no effect on single devices or multiple single devices, well
not on the ones I have!
It also delays read_status call backs being sent while either gate is open, a
mostly like cause of corruption.
The lock also covers the attachment process of the tuner in case there is any
race condition, although unlikely.
Points about troubles with Myth TV;
Streaming corruptions are more likely to appear from the I2C noise generated
from setting either frontend. Afatech love their bits as bytes:-)
Latest version of Myth TV appears to have a bug where you can't select the
second
frontend independently and when it does it tunes to the same frequency as
the first frontend!
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/dvb-usb/af9015.c | 7 ++-
drivers/media/dvb/frontends/af9013.c | 13 -
drivers/media/dvb/frontends/af9013.h | 5 +++--
3 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index c6c275b..0089858 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -43,6 +43,7 @@ MODULE_PARM_DESC(remote, select remote);
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
static DEFINE_MUTEX(af9015_usb_mutex);
+static DEFINE_MUTEX(af9015_fe_mutex);
static struct af9015_config af9015_config;
static struct dvb_usb_device_properties af9015_properties[3];
@@ -1114,7 +1115,7 @@ static int af9015_af9013_frontend_attach(struct
dvb_usb_adapter *adap)
/* attach demodulator */
adap-fe_adap[0].fe = dvb_attach(af9013_attach,
af9015_af9013_config[adap-id],
- adap-dev-i2c_adap);
+ adap-dev-i2c_adap, af9015_fe_mutex);
return adap-fe_adap[0].fe == NULL ? -ENODEV : 0;
}
@@ -1187,6 +1188,9 @@ static int af9015_tuner_attach(struct dvb_usb_adapter
*adap)
int ret;
deb_info(%s:\n, __func__);
+ if (mutex_lock_interruptible(af9015_fe_mutex) 0)
+ return -EAGAIN;
+
switch (af9015_af9013_config[adap-id].tuner) {
case AF9013_TUNER_MT2060:
case AF9013_TUNER_MT2060_2:
@@ -1242,6 +1246,7 @@ static int af9015_tuner_attach(struct dvb_usb_adapter
*adap)
err(Unknown tuner id:%d,
af9015_af9013_config[adap-id].tuner);
}
+ mutex_unlock(af9015_fe_mutex);
return ret;
}
diff --git a/drivers/media/dvb/frontends/af9013.c
b/drivers/media/dvb/frontends/af9013.c
index 345311c..b220a87 100644
--- a/drivers/media/dvb/frontends/af9013.c
+++ b/drivers/media/dvb/frontends/af9013.c
@@ -50,6 +50,7 @@ struct af9013_state {
u16 snr;
u32 frequency;
unsigned long next_statistics_check;
+ struct mutex *fe_mutex;
};
static u8 regmask[8] = { 0x01, 0x03, 0x07, 0x0f, 0x1f, 0x3f, 0x7f, 0xff };
@@ -630,9 +631,14 @@ static int af9013_set_frontend(struct dvb_frontend *fe,
state-frequency = params-frequency;
/* program tuner */
+ if (mutex_lock_interruptible(state-fe_mutex) 0)
+ return -EAGAIN;
+
if (fe-ops.tuner_ops.set_params)
fe-ops.tuner_ops.set_params(fe, params);
+ mutex_unlock(state-fe_mutex);
+
/* program CFOE coefficients */
ret = af9013_set_coeff(state, params-u.ofdm.bandwidth);
if (ret)
@@ -1038,6 +1044,9 @@ static int af9013_read_status(struct dvb_frontend *fe,
fe_status_t *status)
u8 tmp;
*status = 0;
+ if (mutex_lock_interruptible(state-fe_mutex) 0)
+ return -EAGAIN;
+
/* MPEG2 lock */
ret = af9013_read_reg_bits(state, 0xd507, 6, 1, tmp);
if (ret)
@@ -1086,6 +1095,7 @@ static int af9013_read_status(struct dvb_frontend *fe,
fe_status_t *status)
ret = af9013_update_statistics(fe);
error:
+ mutex_unlock(state-fe_mutex);
return ret;
}
@@ -1446,7 +1456,7 @@ static void af9013_release(struct
Re: Help with omap3isp resizing
On Tue, Oct 04, 2011 at 03:00:55PM +0200, Laurent Pinchart wrote:
Hi Ivan,
Hi all,
On Tuesday 04 October 2011 13:54:12 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:50 +0200, Laurent Pinchart wrote:
On Tuesday 04 October 2011 13:46:32 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:03 +0200, Laurent Pinchart wrote:
On Monday 03 October 2011 07:51:34 Paul Chiha wrote:
Hi,
I've been having trouble getting the resizer to work, and mainly
because I don't know how to correctly configure it.
I'm using kernel 2.6.37 on arm DM37x board.
I've been able to configure the media links
sensor=ccdc=ccdc_output (all with 640x480
V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on /dev/video2.
But if I configure media links
sensor=ccdc=resizer=resizer_output, then VIDIOC_STREAMON fails
on /dev/video6 (with pixelformat mismatch). I noticed that the
resizer driver only supports
V4L2_MBUS_FMT_UYVY8_1X16 V4L2_MBUS_FMT_YUYV8_1X16, so I tried
again with all the links set to V4L2_MBUS_FMT_UYVY8_1X16 instead,
but then ioctl VIDIOC_SUBDEV_S_FMT fails on /dev/v4l-subdev8,
because the sensor driver doesn't support 1X16.
Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the sensor and
V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either failed with
pixelformat mismatch or link pipeline mismatch, depending on which
pads were different.
Can someone please tell me what I need to do to make this work?
Long story short, I don't think that pipeline has ever been tested.
I'm unfortunately lacking hardware to work on that, as none of my
OMAP3 hardware has a YUV input.
If i am not mistaken currently resizer sub device supports only:
/* resizer pixel formats */
static const unsigned int resizer_formats[] = {
V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,
};
Adding something like this [1] in ispresizer.c should add
support 2X8 formats. Completely untested :-).
Regards,
iivanov
[1]
@@ -1307,6 +1311,10 @@ static int resizer_s_crop(struct v4l2_subdev
*sd, struct v4l2_subdev_fh *fh, static const unsigned int
resizer_formats[] = {
V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,
+ V4L2_MBUS_FMT_UYVY8_2X8,
+ V4L2_MBUS_FMT_VYUY8_2X8,
+ V4L2_MBUS_FMT_YUYV8_2X8,
+ V4L2_MBUS_FMT_YVYU8_2X8,
};
I'd rather modify ispccdc.c to output V4L2_MBUS_FMT_YUYV8_1X16. What do
you think ?
For memory-Resizer-memory use cases, CCDC is no involved in pipeline.
But the original poster wants to use the sensor - ccdc - resizer - resizer
output pipeline.
Also several sensor drivers that i have checked, usually define its
output as 2X8 output. I think is more natural to add 2X8 support to
CCDC and Resizer engines instead to modifying exiting drivers.
Sure, sensor drivers should not be modified. What I was talking about was to
configure the pipeline as
sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16], resizer:0
[YUYV8_1X16]
Looks good to me. This also does reflect the real bus formats in the device
quite well; the links from ccdc onwards only use one clock cycle for sample.
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
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
serial device name for smart card reader that is integrated to Anysee DVB USB device
I have been looking for correct device name for serial smart card reader that is integrated to Anysee DVB USB devices. Consider it like old so called Phoenix reader. Phoenix is de facto protocol used for such readers and there is whole bunch of different RS232 (/dev/ttyS#) or USB-serial (/dev/ttyUSB#) readers using that protocol. Anyhow, that one is integrated to DVB USB device that is driven by dvb_usb_anysee driver. As I understand, I need reserve new device name and major number for my device. See Documentation/devices.txt Current proof-of-concept driver can be found from: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/anysee-sc Don't review code since it is not ready for release yet, it even lacks locking. There have been some proposes about names, mainly whether to register it under the DVB adapter it is physically (/dev/dvb/adapterN/sc#) or to the root of /dev (/dev/sc#). I used sc as name, SC=SmartCard. Could someone who have enough knowledge point out which one is correct or better? 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: Cypress EZ-USB FX2 firmware development
On Tue, Oct 04, 2011 at 10:43:59PM +0300, Antti Palosaari wrote: I would like to made own firmware for Cypress FX2 based DVB device. Is there any sample to look example? http://linuxtv.org/cgi-bin/viewvc.cgi/dvb-hw/dvbusb-fx2/termini/ HTH Johannes -- 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] af9013 frontend tuner bus lock
On Wed, 2011-10-05 at 07:44 +1100, Jason Hecker wrote: I have had some luck with this patch. I am still getting fouled recordings with tuner A but it's not consistent. I have yet to ascertain if the problem occurs depending on the order of tuning to have both tuners recording different frquencies at the same time, ie Tuner B then Tuner A or vice versa. Which Firmware are your using? I am having some problems with firmware version:5.1.0 I have gone back to using firmware version:4.95.0 no problems at all. Malcolm, did you say there was a MythTV tubing bug? Yes, sometimes tries to tune to same frequency as the other frontend for a different channel. Do you have an URL for the bug if it has been reported? No I fear I might have a multi-layered problem - not only the Afatech tuners but perhaps some PCI issue too. It doesn't help if MythTV isn't doing the right thing either. Yes, because it is also happening with other duo devices on Myth TV 0.24.1 So far Myth TV 0.23.0 on Kernel 2.6.35 seems consistently stable. Regards Malcolm -- 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] af9013 frontend tuner bus lock
Which Firmware are your using? 4.95 Yes, because it is also happening with other duo devices on Myth TV 0.24.1 OK, well that is what I am using so I guess I am stuck until it's fixed. Josu what software and versions are you using? -- 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: Help with omap3isp resizing
On Tue, Oct 04, 2011 at 03:00:55PM +0200, Laurent Pinchart wrote:
Hi Ivan,
On Tuesday 04 October 2011 13:54:12 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:50 +0200, Laurent Pinchart wrote:
On Tuesday 04 October 2011 13:46:32 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:03 +0200, Laurent Pinchart wrote:
On Monday 03 October 2011 07:51:34 Paul Chiha wrote:
Hi,
I've been having trouble getting the resizer to work, and
mainly because I don't know how to correctly configure it.
I'm using kernel 2.6.37 on arm DM37x board.
I've been able to configure the media links
sensor=ccdc=ccdc_output (all with 640x480
V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on
/dev/video2.
But if I configure media links
sensor=ccdc=resizer=resizer_output, then VIDIOC_STREAMON
fails on /dev/video6 (with pixelformat mismatch). I noticed
that the resizer driver only supports
V4L2_MBUS_FMT_UYVY8_1X16 V4L2_MBUS_FMT_YUYV8_1X16, so I
tried again with all the links set to V4L2_MBUS_FMT_UYVY8_1X16
instead, but then ioctl VIDIOC_SUBDEV_S_FMT fails on
/dev/v4l-subdev8, because the sensor driver doesn't support 1X16.
Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the sensor and
V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either failed
with pixelformat mismatch or link pipeline mismatch, depending
on which pads were different.
Can someone please tell me what I need to do to make this work?
Long story short, I don't think that pipeline has ever been tested.
I'm unfortunately lacking hardware to work on that, as none of
my
OMAP3 hardware has a YUV input.
If i am not mistaken currently resizer sub device supports only:
/* resizer pixel formats */
static const unsigned int resizer_formats[] = {
V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,
};
Adding something like this [1] in ispresizer.c should add support
2X8 formats. Completely untested :-).
Regards,
iivanov
[1]
@@ -1307,6 +1311,10 @@ static int resizer_s_crop(struct
v4l2_subdev *sd, struct v4l2_subdev_fh *fh, static const unsigned
int resizer_formats[] = {
V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,
+ V4L2_MBUS_FMT_UYVY8_2X8,
+ V4L2_MBUS_FMT_VYUY8_2X8,
+ V4L2_MBUS_FMT_YUYV8_2X8,
+ V4L2_MBUS_FMT_YVYU8_2X8,
};
I'd rather modify ispccdc.c to output V4L2_MBUS_FMT_YUYV8_1X16. What
do you think ?
For memory-Resizer-memory use cases, CCDC is no involved in pipeline.
But the original poster wants to use the sensor - ccdc - resizer - resizer
output
pipeline.
Also several sensor drivers that i have checked, usually define its
output as 2X8 output. I think is more natural to add 2X8 support to
CCDC and Resizer engines instead to modifying exiting drivers.
Sure, sensor drivers should not be modified. What I was talking about was to
configure the pipeline as
sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16], resizer:0
[YUYV8_1X16]
--
Regards,
Laurent Pinchart
Thanks for your help.
I've updated ispccdc.c to support the _1X16 codes and the pipeline seems to
work now.
However, I needed to take out the memcpy in ccdc_try_format(), because
otherwise pad 0 format was being copied to pad 1 or 2, regardless of what pad 1
or 2 were being set to.
I'm not sure why it was done that way. I think it's better that the given code
gets checked to see if it's in the list and if so use it. Do you know of any
valid reason why this copy is done?
Paul
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Re: serial device name for smart card reader that is integrated to Anysee DVB USB device
On Wed, Oct 05, 2011 at 12:22:09AM +0300, Antti Palosaari wrote: I have been looking for correct device name for serial smart card reader that is integrated to Anysee DVB USB devices. Consider it like old so called Phoenix reader. Phoenix is de facto protocol used for such readers and there is whole bunch of different RS232 (/dev/ttyS#) or USB-serial (/dev/ttyUSB#) readers using that protocol. Anyhow, that one is integrated to DVB USB device that is driven by dvb_usb_anysee driver. As I understand, I need reserve new device name and major number for my device. See Documentation/devices.txt Why not just use the usb-serial core and then you get a ttyUSB* device node for free? It also should provide a lot of the basic tty infrastructure and ring buffer logic all ready to use. thanks, greg k-h Current proof-of-concept driver can be found from: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/anysee-sc Don't review code since it is not ready for release yet, it even lacks locking. There have been some proposes about names, mainly whether to register it under the DVB adapter it is physically (/dev/dvb/adapterN/sc#) or to the root of /dev (/dev/sc#). I used sc as name, SC=SmartCard. Could someone who have enough knowledge point out which one is correct or better? regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-serial 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: serial device name for smart card reader that is integrated to Anysee DVB USB device
On 10/05/2011 07:59 AM, Greg KH wrote: On Wed, Oct 05, 2011 at 12:22:09AM +0300, Antti Palosaari wrote: I have been looking for correct device name for serial smart card reader that is integrated to Anysee DVB USB devices. Consider it like old so called Phoenix reader. Phoenix is de facto protocol used for such readers and there is whole bunch of different RS232 (/dev/ttyS#) or USB-serial (/dev/ttyUSB#) readers using that protocol. Anyhow, that one is integrated to DVB USB device that is driven by dvb_usb_anysee driver. As I understand, I need reserve new device name and major number for my device. See Documentation/devices.txt Why not just use the usb-serial core and then you get a ttyUSB* device node for free? It also should provide a lot of the basic tty infrastructure and ring buffer logic all ready to use. Since I don't see how I can access same platform data from DVB USB and USB-serial driver (usb_set_intfdata). I asked that earlier, see: http://www.mail-archive.com/linux-media@vger.kernel.org/msg36027.html 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
