Re: [GIT PATCHES FOR 2.6.40] Fixes
On Tuesday, May 24, 2011 03:42:32 Mauro Carvalho Chehab wrote: Em 23-05-2011 08:06, Hans Verkuil escreveu: Hi Mauro, Here are a few fixes: the first fixes a bug in the wl12xx drivers (I hope Matti's email is still correct). The second fixes a few DocBook validation errors, and the last fixes READ_ONLY and GRABBED handling in the control framework. Regards, Hans The following changes since commit 87cf028f3aa1ed51fe29c36df548aa714dc7438f: [media] dm1105: GPIO handling added, I2C on GPIO added, LNB control through GPIO reworked (2011-05-21 11:10:28 -0300) are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git fixes Hans Verkuil (3): wl12xx: g_volatile_ctrl fix: wrong field set. Media DocBook: fix validation errors. The two above are fixes... v4l2-ctrls: drivers should be able to ignore READ_ONLY and GRABBED flags But this one is a change at the behaviour. I need to analyse it better. The idea of a read only control that it is not read only seems too weird on my tired eyes. It's read-only for *applications*. But if you have a read-only control that reflects a driver state, then it should be possible for a *driver* to change it. It's something that is needed for the upcoming Flash and HDMI APIs. The userspace behavior does not change. BTW, if you prefer to move this last patch to 2.6.41, then that's OK by me. It's not really necessary for 2.6.40. Regards, Hans I'll take a more careful look on it tomorrow. Thanks, Mauro. Documentation/DocBook/dvb/dvbproperty.xml|5 ++- Documentation/DocBook/v4l/subdev-formats.xml | 10 ++-- drivers/media/radio/radio-wl1273.c |2 +- drivers/media/radio/wl128x/fmdrv_v4l2.c |2 +- drivers/media/video/v4l2-ctrls.c | 59 +- 5 files changed, 50 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: [ANNOUNCE] experimental alsa stream support at xawtv3
On Monday, May 23, 2011 22:17:06 Mauro Carvalho Chehab wrote: Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils) during the weekend, I decided to add alsa support also on xawtv3, basically to provide a real usecase example. Of course, for it to work, it needs the very latest v4l2-utils version from the git tree. Please, please add at the very least some very big disclaimer in libv4l2util that the API/ABI is likely to change. As mentioned earlier, this library is undocumented, has not gone through any peer-review, and I am very unhappy with it and with the decision (without discussion it seems) to install it. Once you install it on systems it becomes much harder to change. Regards, Hans I've basically added there the code that Devin wrote for tvtime, with a few small fixes and with the audio device auto-detection. With this patch, xawtv will now get the alsa device associated with a video device node (if any), and start streaming from it, on a separate thread. As the code is the same as the one at tvtime, it should work at the same devices that are supported there. I tested it only on two em28xx devices: - HVR-950; - WinTV USB-2. It worked with HVR-950, but it didn't work with WinTV USB-2. It seems that snd-usb-audio do something different to set the framerate, that the alsa-stream code doesn't recognize. While I didn't test, I think it probably won't work with saa7134, as the code seems to hardcode the frame rate to 48 kHz, but saa7134 supports only 32 kHz. It would be good to add an option to disable this behavior and to allow manually select the alsa out device, so please send us patches ;) Anyway, patches fixing it and more tests are welcome. The git repositories for xawtv3 and v4l-utils is at: http://git.linuxtv.org/xawtv3.git http://git.linuxtv.org/v4l-utils.git Thanks, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: [ANNOUNCE] experimental alsa stream support at xawtv3
Hi, On 05/24/2011 08:50 AM, Hans Verkuil wrote: On Monday, May 23, 2011 22:17:06 Mauro Carvalho Chehab wrote: Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils) during the weekend, I decided to add alsa support also on xawtv3, basically to provide a real usecase example. Of course, for it to work, it needs the very latest v4l2-utils version from the git tree. Please, please add at the very least some very big disclaimer in libv4l2util that the API/ABI is likely to change. As mentioned earlier, this library is undocumented, has not gone through any peer-review, and I am very unhappy with it and with the decision (without discussion it seems) to install it. My I suggest that we instead just copy over the single get_media_devices.c file to xawtv, and not install the not so much a lib lib ? Mauro, I plan to do a new v4l-utils release soon (*), maybe even today. I consider it unpolite to revert other peoples commits, so I would prefer for you to revert the install libv4l2util.a patch yourself. But if you don't (or don't get around to doing it before I do the release), I will revert it, as this clearly needs more discussion before making it into an official release tarbal (we can always re-introduce the patch after the release). Regards, Hans *) To get a number of libv4l changes which I did recently out there. Once you install it on systems it becomes much harder to change. Regards, Hans I've basically added there the code that Devin wrote for tvtime, with a few small fixes and with the audio device auto-detection. With this patch, xawtv will now get the alsa device associated with a video device node (if any), and start streaming from it, on a separate thread. As the code is the same as the one at tvtime, it should work at the same devices that are supported there. I tested it only on two em28xx devices: - HVR-950; - WinTV USB-2. It worked with HVR-950, but it didn't work with WinTV USB-2. It seems that snd-usb-audio do something different to set the framerate, that the alsa-stream code doesn't recognize. While I didn't test, I think it probably won't work with saa7134, as the code seems to hardcode the frame rate to 48 kHz, but saa7134 supports only 32 kHz. It would be good to add an option to disable this behavior and to allow manually select the alsa out device, so please send us patches ;) Anyway, patches fixing it and more tests are welcome. The git repositories for xawtv3 and v4l-utils is at: http://git.linuxtv.org/xawtv3.git http://git.linuxtv.org/v4l-utils.git Thanks, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.41] Add bitmask controls
Hans Verkuil wrote: Hi Mauro, These patches for 2.6.41 add support for bitmask controls, needed for the upcoming Flash API and HDMI API. Sakari, can you give your ack as well? The patch is the same as the original one posted April 4, except for a small change in the control logging based on feedback from Laurent and the new DocBook documentation. Thanks, Hans!! Acked-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] MT9P031: Add support for Aptina mt9p031 sensor.
Hi, Laurent, Guennadi,
thank you for your review. I've already fixed most of the issues.
On 23 May 2011 11:03, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Guennadi and Javier,
On Saturday 21 May 2011 17:29:18 Guennadi Liakhovetski wrote:
On Fri, 20 May 2011, Javier Martin wrote:
[snip]
diff --git a/drivers/media/video/mt9p031.c
b/drivers/media/video/mt9p031.c new file mode 100644
index 000..e406b64
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
[snip]
+}
+
+static int mt9p031_power_on(struct mt9p031 *mt9p031)
+{
+ int ret;
+
+ /* turn on VDD_IO */
+ ret = regulator_enable(mt9p031-reg_2v8);
+ if (ret) {
+ pr_err(Failed to enable 2.8v regulator: %d\n, ret);
dev_err()
+ return ret;
+ }
+ if (mt9p031-pdata-set_xclk)
+ mt9p031-pdata-set_xclk(mt9p031-subdev, 5400);
Can you make 5400 a #define at the beginning of the file ?
You should soft-reset the chip here by calling mt9p031_reset().
If I do this, I would be force to cache some registers and restart
them. I've tried to do this but I don't know what is failing that
there are some artifacts consisting on horizontal black lines in the
image.
Please, let me push this to mainline without this feature as a first
step, since I'll have to spend some assigned to another project.
[snip]
+ */
+static int mt9p031_video_probe(struct i2c_client *client)
+{
+ s32 data;
+ int ret;
+
+ /* Read out the chip version register */
+ data = reg_read(client, MT9P031_CHIP_VERSION);
+ if (data != MT9P031_CHIP_VERSION_VALUE) {
+ dev_err(client-dev,
+ No MT9P031 chip detected, register read %x\n, data);
+ return -ENODEV;
+ }
+
+ dev_info(client-dev, Detected a MT9P031 chip ID %x\n, data);
+
+ ret = mt9p031_reset(client);
+ if (ret 0)
+ dev_err(client-dev, Failed to initialise the camera\n);
If you move the soft-reset operation to mt9p031_power_on(), you don't need to
call it here.
The reason for this is the same as before. I haven't still been able
to success on restarting registers and getting everything to work
fine.
It would be great if you allowed me to push this as it is as an
intermediate step.
[snip]
+ mt9p031-rect.width = MT9P031_MAX_WIDTH;
+ mt9p031-rect.height = MT9P031_MAX_HEIGHT;
+
+ mt9p031-format.code = V4L2_MBUS_FMT_SGRBG12_1X12;
+
+ mt9p031-format.width = MT9P031_MAX_WIDTH;
+ mt9p031-format.height = MT9P031_MAX_HEIGHT;
+ mt9p031-format.field = V4L2_FIELD_NONE;
+ mt9p031-format.colorspace = V4L2_COLORSPACE_SRGB;
+
+ mt9p031-xskip = 1;
+ mt9p031-yskip = 1;
+
+ mt9p031-reg_1v8 = regulator_get(NULL, cam_1v8);
+ if (IS_ERR(mt9p031-reg_1v8)) {
+ ret = PTR_ERR(mt9p031-reg_1v8);
+ pr_err(Failed 1.8v regulator: %d\n, ret);
dev_err()
+ goto e1v8;
+ }
The driver can be used with boards where either or both of the 1.8V and 2.8V
supplies are always on, thus not connected to any regulator. I'm not sure how
that's usually handled, if board code should define an always-on power
supply, or if the driver shouldn't fail when no regulator is present. In any
case, this must be handled.
I think board code should define an always-on power supply.
+
+ mt9p031-reg_2v8 = regulator_get(NULL, cam_2v8);
+ if (IS_ERR(mt9p031-reg_2v8)) {
+ ret = PTR_ERR(mt9p031-reg_2v8);
+ pr_err(Failed 2.8v regulator: %d\n, ret);
ditto
+ goto e2v8;
+ }
+ /* turn on core */
+ ret = regulator_enable(mt9p031-reg_1v8);
+ if (ret) {
+ pr_err(Failed to enable 1.8v regulator: %d\n, ret);
ditto
+ goto e1v8en;
+ }
+ return 0;
Why do you leave core power on at the end of probe() ? You should only turn it
on when needed.
Just as I said, because restarting registers does not work yet.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] MT9P031: Add support for Aptina mt9p031 sensor.
Hi Javier,
On Tuesday 24 May 2011 10:31:46 javier Martin wrote:
On 23 May 2011 11:03, Laurent Pinchart wrote:
On Saturday 21 May 2011 17:29:18 Guennadi Liakhovetski wrote:
On Fri, 20 May 2011, Javier Martin wrote:
[snip]
diff --git a/drivers/media/video/mt9p031.c
b/drivers/media/video/mt9p031.c new file mode 100644
index 000..e406b64
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
[snip]
+}
+
+static int mt9p031_power_on(struct mt9p031 *mt9p031)
+{
+ int ret;
+
+ /* turn on VDD_IO */
+ ret = regulator_enable(mt9p031-reg_2v8);
+ if (ret) {
+ pr_err(Failed to enable 2.8v regulator: %d\n, ret);
dev_err()
+ return ret;
+ }
+ if (mt9p031-pdata-set_xclk)
+ mt9p031-pdata-set_xclk(mt9p031-subdev, 5400);
Can you make 5400 a #define at the beginning of the file ?
You should soft-reset the chip here by calling mt9p031_reset().
If I do this, I would be force to cache some registers and restart
them. I've tried to do this but I don't know what is failing that
there are some artifacts consisting on horizontal black lines in the
image.
You need to cache registers anyway, as the chip will be reset to default
values by the core power cycling. And as I'm writing those lines I realize
that you don't power cycle reg_1v8. This needs to be done to save power.
Please, let me push this to mainline without this feature as a first
step, since I'll have to spend some assigned to another project.
Power handling is an important feature. I don't think the driver is ready
without it.
[snip]
+ */
+static int mt9p031_video_probe(struct i2c_client *client)
+{
+ s32 data;
+ int ret;
+
+ /* Read out the chip version register */
+ data = reg_read(client, MT9P031_CHIP_VERSION);
+ if (data != MT9P031_CHIP_VERSION_VALUE) {
+ dev_err(client-dev,
+ No MT9P031 chip detected, register read %x\n,
data); + return -ENODEV;
+ }
+
+ dev_info(client-dev, Detected a MT9P031 chip ID %x\n, data);
+
+ ret = mt9p031_reset(client);
+ if (ret 0)
+ dev_err(client-dev, Failed to initialise the
camera\n);
If you move the soft-reset operation to mt9p031_power_on(), you don't
need to call it here.
The reason for this is the same as before. I haven't still been able
to success on restarting registers and getting everything to work
fine.
It would be great if you allowed me to push this as it is as an
intermediate step.
Sorry, but I'd like to see power management properly implemented before the
driver hits mainline. Other less important features (such as exposure/gain
controls for instance) can be missing, but proper power management is
important.
[snip]
+ mt9p031-rect.width = MT9P031_MAX_WIDTH;
+ mt9p031-rect.height= MT9P031_MAX_HEIGHT;
+
+ mt9p031-format.code = V4L2_MBUS_FMT_SGRBG12_1X12;
+
+ mt9p031-format.width = MT9P031_MAX_WIDTH;
+ mt9p031-format.height = MT9P031_MAX_HEIGHT;
+ mt9p031-format.field = V4L2_FIELD_NONE;
+ mt9p031-format.colorspace = V4L2_COLORSPACE_SRGB;
+
+ mt9p031-xskip = 1;
+ mt9p031-yskip = 1;
+
+ mt9p031-reg_1v8 = regulator_get(NULL, cam_1v8);
+ if (IS_ERR(mt9p031-reg_1v8)) {
+ ret = PTR_ERR(mt9p031-reg_1v8);
+ pr_err(Failed 1.8v regulator: %d\n, ret);
dev_err()
+ goto e1v8;
+ }
The driver can be used with boards where either or both of the 1.8V and
2.8V supplies are always on, thus not connected to any regulator. I'm
not sure how that's usually handled, if board code should define an
always-on power supply, or if the driver shouldn't fail when no
regulator is present. In any case, this must be handled.
I think board code should define an always-on power supply.
Fine with me. How is that done BTW ?
+
+ mt9p031-reg_2v8 = regulator_get(NULL, cam_2v8);
+ if (IS_ERR(mt9p031-reg_2v8)) {
+ ret = PTR_ERR(mt9p031-reg_2v8);
+ pr_err(Failed 2.8v regulator: %d\n, ret);
ditto
+ goto e2v8;
+ }
+ /* turn on core */
+ ret = regulator_enable(mt9p031-reg_1v8);
+ if (ret) {
+ pr_err(Failed to enable 1.8v regulator: %d\n, ret);
ditto
+ goto e1v8en;
+ }
+ return 0;
Why do you leave core power on at the end of probe() ? You should only
turn it on when needed.
Just as I said, because restarting registers does not work yet.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] MT9P031: Add support for Aptina mt9p031 sensor.
Hi Javier,
On Tuesday 24 May 2011 10:56:22 javier Martin wrote:
On 24 May 2011 10:39, Laurent Pinchart wrote:
On Tuesday 24 May 2011 10:31:46 javier Martin wrote:
On 23 May 2011 11:03, Laurent Pinchart wrote:
On Saturday 21 May 2011 17:29:18 Guennadi Liakhovetski wrote:
On Fri, 20 May 2011, Javier Martin wrote:
[snip]
diff --git a/drivers/media/video/mt9p031.c
b/drivers/media/video/mt9p031.c new file mode 100644
index 000..e406b64
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
[snip]
+}
+
+static int mt9p031_power_on(struct mt9p031 *mt9p031)
+{
+ int ret;
+
+ /* turn on VDD_IO */
+ ret = regulator_enable(mt9p031-reg_2v8);
+ if (ret) {
+ pr_err(Failed to enable 2.8v regulator: %d\n, ret);
dev_err()
+ return ret;
+ }
+ if (mt9p031-pdata-set_xclk)
+ mt9p031-pdata-set_xclk(mt9p031-subdev, 5400);
Can you make 5400 a #define at the beginning of the file ?
You should soft-reset the chip here by calling mt9p031_reset().
If I do this, I would be force to cache some registers and restart
them. I've tried to do this but I don't know what is failing that
there are some artifacts consisting on horizontal black lines in the
image.
You need to cache registers anyway, as the chip will be reset to default
values by the core power cycling. And as I'm writing those lines I
realize that you don't power cycle reg_1v8. This needs to be done to
save power.
Please, let me push this to mainline without this feature as a first
step, since I'll have to spend some assigned to another project.
Power handling is an important feature. I don't think the driver is ready
without it.
[snip]
+ */
+static int mt9p031_video_probe(struct i2c_client *client)
+{
+ s32 data;
+ int ret;
+
+ /* Read out the chip version register */
+ data = reg_read(client, MT9P031_CHIP_VERSION);
+ if (data != MT9P031_CHIP_VERSION_VALUE) {
+ dev_err(client-dev,
+ No MT9P031 chip detected, register read %x\n,
data); + return -ENODEV;
+ }
+
+ dev_info(client-dev, Detected a MT9P031 chip ID %x\n,
data); +
+ ret = mt9p031_reset(client);
+ if (ret 0)
+ dev_err(client-dev, Failed to initialise the
camera\n);
If you move the soft-reset operation to mt9p031_power_on(), you don't
need to call it here.
The reason for this is the same as before. I haven't still been able
to success on restarting registers and getting everything to work
fine.
It would be great if you allowed me to push this as it is as an
intermediate step.
Sorry, but I'd like to see power management properly implemented before
the driver hits mainline. Other less important features (such as
exposure/gain controls for instance) can be missing, but proper power
management is important.
OK, I'll focus on this feature from now on. However, I can't guarantee
that I won't be removed from the project in the process. If that
happens I will send my current patches to the community and someone
else will have to complete the job.
I understand. I could take over but I don't have an MT9P031 hardware :-S
[snip]
+ mt9p031-rect.width = MT9P031_MAX_WIDTH;
+ mt9p031-rect.height= MT9P031_MAX_HEIGHT;
+
+ mt9p031-format.code = V4L2_MBUS_FMT_SGRBG12_1X12;
+
+ mt9p031-format.width = MT9P031_MAX_WIDTH;
+ mt9p031-format.height = MT9P031_MAX_HEIGHT;
+ mt9p031-format.field = V4L2_FIELD_NONE;
+ mt9p031-format.colorspace = V4L2_COLORSPACE_SRGB;
+
+ mt9p031-xskip = 1;
+ mt9p031-yskip = 1;
+
+ mt9p031-reg_1v8 = regulator_get(NULL, cam_1v8);
+ if (IS_ERR(mt9p031-reg_1v8)) {
+ ret = PTR_ERR(mt9p031-reg_1v8);
+ pr_err(Failed 1.8v regulator: %d\n, ret);
dev_err()
+ goto e1v8;
+ }
The driver can be used with boards where either or both of the 1.8V
and 2.8V supplies are always on, thus not connected to any regulator.
I'm not sure how that's usually handled, if board code should define
an always-on power supply, or if the driver shouldn't fail when no
regulator is present. In any case, this must be handled.
I think board code should define an always-on power supply.
Fine with me. How is that done BTW ?
You can use a fixed regulator for that purpose:
http://lxr.linux.no/#linux+v2.6.37.2/include/linux/regulator/fixed.h
struct fixed_voltage_config is meant to be passed to drivers through platform
data. It doesn't declare an always-on regulator.
--
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
Re: dvb: one demux per tuner or one demux per demod?
Hi Rémi, The cxd2820r supports DVB-T/T2 and also DVB-C. As such antti coded up a multiple front end (MFE) implementation for em28xx then attaches the cxd2820r in both modes. I believe you can only use one frontend at once per adapter (this is certainly enforced in the cxd2820r module), so I don't see how it would cause a problem for mappings. I think a dual tuner device would register itself as two adapters, wouldn't it? But I'm new at this, so forgive me if I've overlooked something or misunderstood the issue you've raised. Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Tue, 2011-05-24 at 12:55 +0200, Rémi Denis-Courmont wrote: Hello, Been testing the bleeding-edge Hauppauge 290E (em28174 + Sony cxd2820r) from Antti Palosaari and Steve Kerrison, now in linux-media GIT tree. It seems the device creates two frontends and only one demux/dvr nodes. Are they not supposed to be one demux per frontend? Or how is user-space supposed to map the demux/dvr and the frontend, on a multi-proto card? on a multi-tuner card? Best regards, -- 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: one demux per tuner or one demux per demod?
2011/5/24 Steve Kerrison st...@stevekerrison.com: Hi Rémi, The cxd2820r supports DVB-T/T2 and also DVB-C. As such antti coded up a multiple front end (MFE) implementation for em28xx then attaches the cxd2820r in both modes. I believe you can only use one frontend at once per adapter (this is certainly enforced in the cxd2820r module), so I don't see how it would cause a problem for mappings. I think a dual tuner device would register itself as two adapters, wouldn't it? But I'm new at this, so forgive me if I've overlooked something or misunderstood the issue you've raised. Oh wow, is that what Antti did? I didn't really give much thought but I can appreciate why he did it (the DVB 3.x API won't allow a single frontend to advertise support for DVB-C and DVB-T). This is one of the big things that S2API fixes (through S2API you can specify the modulation that you want). Do we really want to be advertising two frontends that point to the same demod, when they cannot be used in parallel? This seems doomed to create problems with applications not knowing that they are in fact the same frontend. I'm tempted to say that this patch should be scapped and we should simply say that you cannot use DVB-C on this device unless you are using S2API. That would certainly be cleaner but it comes at the cost of DVB-C not working with tools that haven't been converted over to S2API yet. 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: [PATCH 0/2] V4L: Extended crop/compose API
Laurent Pinchart wrote: Hi Tomasz, On Wednesday 18 May 2011 18:55:51 Tomasz Stanislawski wrote: Laurent Pinchart wrote: On Saturday 14 May 2011 12:50:32 Hans Verkuil wrote: On Friday, May 13, 2011 14:43:08 Laurent Pinchart wrote: On Saturday 07 May 2011 13:52:25 Hans Verkuil wrote: On Thursday, May 05, 2011 11:39:54 Tomasz Stanislawski wrote: Hi Laurent and Hans, I am very sorry for replying so lately. I was really busy during last week. Thank you very much for your interest and comments :). No worries. I get more time to rest when you don't reply on the spot, so I don't mind :-) [snip] Applications set V4L2_SEL_TRY flag in v4l2_selection::flags to prevent a driver from applying selection configuration to hardware. I mentioned this before but I am very much opposed to this flag. It is inconsistent with the TRY_FMT and TRY_EXT_CTRLS ioctls. Note that in video_ioctl2 it should be just one function with 'try' boolean argument. It has always been a mistake that the try and set functions were separated in the driver code IMHO. I know that the subdev ioctls do not have a try version, but it is not quite the same in that those try functions actually store the try information. That's exactly why the subdevs pad-level API has a try flag instead of a try operation, and that's why g/s_selection on subdevs will be done with a try flag. As for the video device node API, I won't oppose a TRY ioctl, as long as we can guarantee there will never be dependencies between the selection rectangles and other parameters (or between the different selection rectangles). If the crop rectangle depends on the compose rectangle for instance, how can you implement a TRY ioctl to try a crop rectangle for a specific compose rectangle, without modifying the active compose rectangle first ? In that case the TRY would adjust the crop so that it works with the current compose rectangle. And how do you try both crop and compose settings without modifying the active configuration ? That's not possible, and I think it's a bad API limitation. VIDIOC_TRY_MULTISELECTION ? But this is just one more example of our lack of proper support for pipeline setup. It doesn't really matter whether this is at the subdev level or at the driver level, both have the same problems. This requires a brainstorm session to work out. This is something we need to look into more carefully. I am slowly becoming convinced that we need some sort of transaction-based configuration for pipelines. This RFC is about video device node configuration, not pipelines. For pipelines I think we'll need a transaction-based API. For video device nodes, I'm still unsure. As stated above, if we have multiple parameters that depend on each other, how do we let the user try them without changing the active configuration ? Cropping/scaling/composing IS a pipeline. Until recently the V4L2 device node API was sufficient to setup the trivial pipelines that most V4L2 consumer devices have. But with the more modern devices it starts to show its limitations. It's still a simple pipeline, and I think we should aim at making the V4L2 device node API useful to configure this kind of pipeline. The selection API is a superset of the crop API, applications should be able to use it to replace the crop API in the long term. The whole 'try' concept we had for a long time needs to be re-examined. I agree. As you remember, I was never satisfied with the subdev 'try' approach either, but I never could come up with a better alternative. I've noticed that there are two different meaning of TRY flag a) checking if a proposed configuration is applicable for a driver b) storing proposed configuration in some form of temporary buffer Ad. a. This is a real TRY command. The state of both hardware and driver does not change after TRY call. Ad. b. It should be called not TRY flag because the internal state of a driver changes. It should be named as something like SHADOW flag. It would indicate that the change is applied only to shadow configuration. I propose to change name of TRY flag for subdev to SHADOW flag. I think it would much clear to express the difference of TRY meaning in video node and subdev contexts. It's not a shadow configuration, it can't get applied to the active configuration (although that might open interesting opportunities). The TRY settings on subdevs are really TRY settings. They're local to the file handle, so you can have any number of unrelated TRY settings (limited by system resources limits of course). They're used to try settings, not to set a shadow configuration. Therefore ioctl VIDIOC_TRY_SELECTION is probably better and more convenient way of testing if configuration is applicable. Only if you make that a multi-selection, and if it can handle format and scaling parameters as well. Now that devices have lots of interdependent parameters, we need to try combinations, not individual parameters. Regardless of how such a scheme
Re: [GIT PATCH FOR 2.6.40] uvcvideo patches
Hi Mauro and Laurent, On Fri, May 20, 2011 at 06:01:18PM -0300, Mauro Carvalho Chehab wrote: Em 20-05-2011 16:47, Laurent Pinchart escreveu: [clip] By allowing access to those undocumented XU controls an Evil Manufacturer(tm) could try to sell its own proprietary software that will work on Linux where all other software will deadly fail or will produce very bad results. We've seen that history before. As you're putting some names, let me be clearer. In the past we had bad stuff like this one: http://kerneltrap.org/node/3729 that ended by the need of somebody to rewrite the entire pwc driver, because the only way to get a decent image using a Philips camera, with the open source driver were to run a closed-source binary. undocumented controls that can do everything, as you said, can create a similar situation to what we had in the past. We have several alternatives. One of them, that is being shipped in some systems, is a uvcvideo driver patched by the Evil Manufacturer(tm), incompatible with the mainline version. Another one is a closed-source userspace driver based on libusb shipped by the Evil Manufacturer(tm). Yet another one is webcams that work on Windows only. Which one do you prefer ? I prefer to ask the vendor about the XU controls that he needs and add a proper interface for them. As the UVC standard allows implementing custom functionality in a standard way (UVC), I wouldn't necessarily prevent using that. I definitely agree that the XU functionality should be properly documented by vendors, and what can be supported using a standardised interface must be. [clip] Why something else ? The XU interface has been designed by the USB-IF to be a kernelspace to userspace API. That's how Microsoft, and I think Apple, implemented it (it might not be a reference though). In the latter case, the developer that did the reverse engineering can just send us a patch adding the new V4L control/firmware upgrade logic/whatever to us. UVC is a class specification. I don't want to cripple the driver with tons of device-specific code. We already have Apple iSight- and Logitech-specific code and way too many quirks for my taste. Unfortunately, by being a generic driver for an USB class, and with vendors not quite following the specs, there's no way to avoid having device-specific stuff there. Other similar drivers like snd-usb-audio and sound hda driver has lots of quirks. In particular, the hda driver contains more lines to the patch-*.c drivers (with the device-specific stuff) than the driver core: $ wc -l sound/pci/hda/*.c 267 sound/pci/hda/hda_beep.c 5072 sound/pci/hda/hda_codec.c 637 sound/pci/hda/hda_eld.c 1084 sound/pci/hda/hda_generic.c 818 sound/pci/hda/hda_hwdep.c 2854 sound/pci/hda/hda_intel.c 727 sound/pci/hda/hda_proc.c 4988 sound/pci/hda/patch_analog.c 572 sound/pci/hda/patch_ca0110.c 1314 sound/pci/hda/patch_cirrus.c 776 sound/pci/hda/patch_cmedia.c 3905 sound/pci/hda/patch_conexant.c 1749 sound/pci/hda/patch_hdmi.c 20167 sound/pci/hda/patch_realtek.c 335 sound/pci/hda/patch_si3054.c 6434 sound/pci/hda/patch_sigmatel.c 6107 sound/pci/hda/patch_via.c 57806 total Yeah, device-specific stuff sucks, but sometimes there's no way to properly support a device. In this case the functionality the hardware provides is rather well defined --- audio streams and a set of mixer controls. It's just the implementation which varies, but that can still be made fit behind a standard interface which provides standardised functionality for the applications. In the case of the UVC hardware, there's a standard which is mostly followed relatively well by vendors. What likely cannot be standardised is, for example, the firmware update for Logitech webcams mentioned above, which the UVC standard still allows. This will stay specific to Logitech devices probably forever. As far as I understand, this discussion isn't really even related to the patchset. The XU access is still provided to user space without the patchset. So, I'm yet not convinced ;) In fact, I think we should just deprecate the XU private ioctls. http://www.quickcamteam.net/uvc-h264/USB_Video_Payload_H.264_0.87.pdf That's a brain-dead proposal for a new H.264 payload format pushed by Logitech and Microsoft. The document is a bit outdated, but the final version will likely be close. It requires direct XU access from applications. I don't like it either, and the alternative will be to not support H.264 UVC cameras at all (something I might consider, by blacklisting the product completely). Are you ready to refuse supporting large classes of USB hardware ? What's the difference between: 1) exposing XU access to userspace and having no applications using it; 2) just blacklisting them. The end result is the same. I
Re: [RFC/PATCH 1/2] v4l: Add generic board subdev registration function
Hi Hans, On Friday 20 May 2011 13:14:42 Hans Verkuil wrote: On Friday, May 20, 2011 12:12:23 Laurent Pinchart wrote: On Friday 20 May 2011 11:52:17 Hans Verkuil wrote: On Friday, May 20, 2011 11:37:24 Laurent Pinchart wrote: On Friday 20 May 2011 11:19:48 Hans Verkuil wrote: On Friday, May 20, 2011 11:05:00 Laurent Pinchart wrote: [snip] My idea was to use bus notifiers to delay the bridge/host device initialization. The bridge probe() function would pre-initialize the bridge and register notifiers. The driver would then wait until all subdevs are properly registered, and then proceed from to register V4L2 devices from the bus notifier callback (or possible a work queue). There would be no nested probe() calls. Would it be an option to create a new platform bus for the subdevs? That would have its own lock. It makes sense from a hierarchical point of view, but I'm not certain about the amount of work involved. Do you mean a subdev-platform bus for platform subdevs, or a V4L2 subdev bus for all subdevs ? The first option is possible, but it looks more like a hack to me. If the subdev really is a platform device, it should be handled by the platform bus. The first. So you have a 'top-level' platform device that wants to load platform subdevs (probably representing internal IP blocks). So it would create its own platform bus that is used to probe those platform subdevs. It is similar to e.g. an I2C device that has internal I2C busses: you would also create nested busses there. BTW, why do these platform subdevs have to be on the platform bus? Why not have standalone subdev drivers that are not on any bus? That's for example what ivtv does for the internal GPIO audio subdev. There's some misunderstanging here. Internal IP blocks don't need to sit on any bus. The host/bridge driver can create subdevs for those blocks directly, as it doesn't need to load a separate driver. The issue comes from external subdevs that offer little control or even none at all. The best example is an FPGA that will feed video data to the bridge in a fixed format without any mean of control, or with just an on/off control through a GPIO. Support for such subdevices need to be handled by a separate driver, so we need a way to load it at runtime. I'm not sure on what bus that driver should sit. I don't think the second option is possible, I2C and SPI subdevs need to sit on an I2C or SPI bus (I could be mistaken though, there's at least one example of a logical bus type in the kernel with the HID bus). Let's also not forget about sub-sub-devices. We need to handle them at some point as well. Sub-sub-devices are not a problem by themselves. They are only a problem if they on the same bus. This being said, I think that the use of platform devices to solve the initial problem can also be considered a hack as well. What we really need is a way to handle subdevs that can't be controlled at all (a video source that continuously delivers data for instance), or that can be controlled through GPIO. What bus should we use for a bus-less subdev ? And for GPIO-based subdevs, should we create a GPIO bus ? It is perfectly possible to have bus-less subdevs. See ivtv (I think there are one or two other examples as well). But how can we handle bus-less subdevs for embedded devices, where the host (e.g. OMAP3 ISP) doesn't know about the external subdevs (e.g. FPGA controlled by a couple of GPIOs) ? I remembered that we had to do something similar and I found the patch below. This was the result of some private discussions with Vaibhav Hiremath from TI. It almost certainly doesn't apply to the current kernel, but it is clear what happens. We are actually using this with the dm6467 capture driver. Hope this might at least give some ideas. Thanks for the code. My goal is to avoid having bus-specific (or bus-less-specific) code in bridge drivers. The bridge drivers should get a list of subdev information from board code through platform data (or possibly through the device tree) and call V4L2 core functions to instantiate and/or bind to the subdevs, regardless of the bus they're on. My RFC patch implements such a V4L2 abstraction function that supports I2C and SPI devices. If I were to add support for this FPGA subdev to that core function, this would add a dependency between the V4L2 core and the FPGA subdev driver. The FPGA subdev driver could be dynamically linked to the V4L2 core through symbol_get(), but that's still not an ideal solution. This won't solve the platform subdev problem though. Loading a platform driver (for the subdev) from within the probe function of another platform driver (the bridge) will lead to a deadlock. We need to find a way to fix that. My
Re: dvb: one demux per tuner or one demux per demod?
Hi Devin, Oh wow, is that what Antti did? I didn't really give much thought but I can appreciate why he did it (the DVB 3.x API won't allow a single frontend to advertise support for DVB-C and DVB-T). Yup, here's a quote from his initial pull request. I guess it doesn't make completely clear why he did what he did unless you knew in advance that the demod did DVB-T and DVB-C. Main part of this patch series is new demod driver for Sony CXD2820R. Other big part is multi frontend (MFE) support for em28xx driver. I don't have any other MFE device, so I cannot say if it is implemented correctly or not. At least it seems to work. MFE locking is done in demod driver. If there is some problems let me know and I will try to fix those - I think there is no such big major problems still. Back to your comments: This is one of the big things that S2API fixes (through S2API you can specify the modulation that you want). Do we really want to be advertising two frontends that point to the same demod, when they cannot be used in parallel? This seems doomed to create problems with applications not knowing that they are in fact the same frontend. Agreed, but I had thought that with a single adapter with two frontends it would be possible to obey the rules and only use one at once. If frontend0 is in use, then if you try to open either frontend0 or frontend1, you should get device busy... so I don't see it causing massive issues. Like you say, though, S2API is probably the better approach, with the frontend advertising its supported modulations and selecting one as required. I'm tempted to say that this patch should be scapped and we should simply say that you cannot use DVB-C on this device unless you are using S2API. That would certainly be cleaner but it comes at the cost of DVB-C not working with tools that haven't been converted over to S2API yet. Seeing as the 290e is the only cxd2820r based device supported in Linux right now, combined with the fact that it isn't even advertised as a DVB-C device by PCTV Systems, that's probably an acceptable hit to take. I'd be interested to see what Antti thinks though. :) Regards, -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Tue, 2011-05-24 at 08:28 -0400, Devin Heitmueller wrote: 2011/5/24 Steve Kerrison st...@stevekerrison.com: Hi Rémi, The cxd2820r supports DVB-T/T2 and also DVB-C. As such antti coded up a multiple front end (MFE) implementation for em28xx then attaches the cxd2820r in both modes. I believe you can only use one frontend at once per adapter (this is certainly enforced in the cxd2820r module), so I don't see how it would cause a problem for mappings. I think a dual tuner device would register itself as two adapters, wouldn't it? But I'm new at this, so forgive me if I've overlooked something or misunderstood the issue you've raised. Oh wow, is that what Antti did? I didn't really give much thought but I can appreciate why he did it (the DVB 3.x API won't allow a single frontend to advertise support for DVB-C and DVB-T). This is one of the big things that S2API fixes (through S2API you can specify the modulation that you want). Do we really want to be advertising two frontends that point to the same demod, when they cannot be used in parallel? This seems doomed to create problems with applications not knowing that they are in fact the same frontend. I'm tempted to say that this patch should be scapped and we should simply say that you cannot use DVB-C on this device unless you are using S2API. That would certainly be cleaner but it comes at the cost of DVB-C not working with tools that haven't been converted over to S2API yet. Devin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] build.sh fails on kernel 2.6.38
On Tue, May 24, 2011 at 7:55 AM, Stu Fleming stew...@wic.co.nz wrote: I note that the cx88 bug that affects HVR3000 and HVR4000 is still in this build https://lists.launchpad.net/mythbuntu-bugs/msg03390.html I would hugely appreciate the latter bug being fixed!! Hmm, I just looked at this now. I appreciate why they patch in the ticket *appears* to fix the problem, but nonetheless it's not the correct fix. This is basically a race condition related to teardown of the DVB frontend thread. The function used to take over the DVB bus strobes the reset pin on the demodulator, but there is no guarantee that the demod's init function will subsequently get called. In particular if you rapid close then reopen the DVB device, the demod will get reset but the init will not get called (since the thread wasn't torn down in time and the init() call is only made on thread creation), resulting in subsequent tuning requests failing. Unfortunately, failing to strobe the reset (which is what the patch does) will result in the chip potentially being in an unknown state, which would intermittent result in tuning failure. And you are also very likely to have problems switching between DVB-T and DVB-S/S2. This does explain though why an HVR-4000 user who came to me about a year ago complaining of the DVB-T channel scanner not working in MythTV, and the problem went away when I suggested he jam a sleep(1) between the close() and open() calls to the DVB frontend. Adding the sleep ensured that the dvb frontend went away, which ensured that the init call on the demod was always getting called when it got reopened. In short, the patch is wrong but the problem is much more complicated than simply removing the routine that strobes the reset. Likely the way bus acquire in the cx88 driver would have to be reworked to fix it properly. There may also need to be a fix to dvb_frontend.c as well. This is one of those cases where a rather insidious problem has been found with the framework, and the fix is both going to be complicated and run a very real risk of causing breakage in other boards relying on implicit behavior. I wonder if we can just get the MythTV developers to stick a 0.1 second sleep in between closing and opening the frontend. That would be *much* safer at least in the short term. 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: [PATCH v17 5/6] davinci vpbe: Build infrastructure for VPBE driver
On Mon, May 23, 2011 at 13:58:26, Nori, Sekhar wrote: On Fri, May 20, 2011 at 20:02:08, Sergei Shtylyov wrote: Hello. Manjunath Hadli wrote: This patch adds the build infra-structure for Davinci VPBE dislay driver. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Acked-by: Muralidharan Karicheri m-kariche...@ti.com Acked-by: Hans Verkuil hverk...@xs4all.nl [...] diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 6b19540..a7f11e7 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -91,3 +91,25 @@ config VIDEO_ISIF To compile this driver as a module, choose M here: the module will be called vpfe. + +config VIDEO_DM644X_VPBE + tristate DM644X VPBE HW module BTW, as this seems DM644x specific, shouldn't this depend on CONFIG_ARCH_DAVINCI_DM644x? Since VENC/OSD etc are also applicable to other DaVinci devices, this KConfig entry should probably be split to refer to them individually and in a generic way. depends on can then be used to make sure only the relevant ones show up. Both venc and osd have to be used together always, so might not make a good idea to split. However, I will add a dependency on DM644x, and include others with appropriate patch sets. Thanks, Sekhar -- 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: one demux per tuner or one demux per demod?
On 05/24/2011 03:28 PM, Devin Heitmueller wrote: 2011/5/24 Steve Kerrisonst...@stevekerrison.com: Hi Rémi, The cxd2820r supports DVB-T/T2 and also DVB-C. As such antti coded up a multiple front end (MFE) implementation for em28xx then attaches the cxd2820r in both modes. I believe you can only use one frontend at once per adapter (this is certainly enforced in the cxd2820r module), so I don't see how it would cause a problem for mappings. I think a dual tuner device would register itself as two adapters, wouldn't it? But I'm new at this, so forgive me if I've overlooked something or misunderstood the issue you've raised. Oh wow, is that what Antti did? I didn't really give much thought but I can appreciate why he did it (the DVB 3.x API won't allow a single frontend to advertise support for DVB-C and DVB-T). Yes I did, since I didn't know there is better way. Is there any other driver which implements it differently? I think all current MFE drivers does it like I did. For example look NetUP cx23885 + stv0367. /dev/dvb/adapter0/ crw-rw+ 1 root video 212, 2 May 24 15:51 demux0 crw-rw+ 1 root video 212, 3 May 24 15:51 dvr0 crw-rw+ 1 root video 212, 0 May 24 15:51 frontend0 crw-rw+ 1 root video 212, 1 May 24 15:51 frontend1 crw-rw+ 1 root video 212, 4 May 24 15:51 net0 This is one of the big things that S2API fixes (through S2API you can specify the modulation that you want). Do we really want to be advertising two frontends that point to the same demod, when they cannot be used in parallel? This seems doomed to create problems with applications not knowing that they are in fact the same frontend. I was in understanding it is MFE when there is multiple frontends in same adapter. In that case only one adapter can be used at time. I added lock to cxd2820r driver, which probably is in wrong place (I think it should be interface-driver or core which locks). I'm tempted to say that this patch should be scapped and we should simply say that you cannot use DVB-C on this device unless you are using S2API. That would certainly be cleaner but it comes at the cost of DVB-C not working with tools that haven't been converted over to S2API yet. reagrds, 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
[PATCH v4 0/3] TV driver for Samsung S5P platform (media part)
Hello, I would like to present the 4th version of TV drivers for Samsung S5P platform. The most recent changes are: 1. Configuration of TV is promoted to platform level. - setup of resources is moved to plat-s5p - support for EXYNOS4 and S5PV210 machine. - support for universal-c210 board - support for Goni board 2. Runtime PM for SDO driver. 3. Moved back to dma-contig allocator. - dma-contig is a generic interface for a device - dma-contig use iommu if sysmmu is enabled for a platform 4. Revision of mixer's output handling - list of to be registered outputs is kept in the mixer driver - output is not registered if it is not avaliable 4. Bugs and other fixes: - fixed power domain hang-up - fixed dead-lock caused by request_module called from probe - formatting and typos - fixed VSYNC handling in interrupt - hdmi: applying driver variant to select proper I2C bus Updated RFC for TV driver: == Introduction == The purpose of this RFC is to discuss the driver for a TV output interface available in upcoming Samsung SoC. The HW is able to generate digital and analog signals. Current version of the driver supports only digital output. Internally the driver uses videobuf2 framework, and DMA-CONTIG memory allocator. Not all of them are merged by now, but I decided to post the sources to start discussion driver's design. == Hardware description == The SoC contains a few HW sub-blocks: 1. Video Processor (VP). It is used for processing of NV12 data. An image stored in RAM is accessed by DMA. Pixels are cropped, scaled. Additionally, post processing operations like brightness, sharpness and contrast adjustments could be performed. The output in YCbCr444 format is send to Mixer. 2. Mixer (MXR). The piece of hardware responsible for mixing and blending multiple data inputs before passing it to an output device. The MXR is capable of handling up to three image layers. One is the output of VP. Other two are images in RGB format (multiple variants are supported). The layers are scaled, cropped and blended with background color. The blending factor, and layers' priority are controlled by MXR's registers. The output is passed either to HDMI or SDO. 3. HDMI. The piece of HW responsible for generation of HDMI packets. It takes pixel data from mixer and transforms it into data frames. The output is send to HDMIPHY interface. 4. HDMIPHY. Physical interface for HDMI. Its duties are sending HDMI packets to HDMI connector. Basically, it contains a PLL that produces source clock for Mixer, VP and HDMI during streaming. 5. SDO. Generation of TV analog signal. The alternative output for the Mixer. It receives data and passes it to VideoDAC. The SDO is responsible for timing generation of analog TV signal. It supports multiple standards. 6. VideoDAC. Modulator for TVOUT signal. Receives data from SDO. Converts it to analog domain. Next, the signal is modulated to CVBS format, amplified and sent to Comosite Connector. The diagram below depicts connection between all HW pieces. +---+ NV12 data ---dma---| Video | | Processor | +---+ | V +---+ RGB data ---dma---| | | Mixer | RGB data ---dma---| | +---+ | * dmux / +-* *--+ || VV +---++---+ |HDMI ||SDO| +---++---+ || VV +---++---+ | HDMIPHY || VideoDAC | +---++---+ || VV HDMI Composite connector connector == Driver interface == The posted driver implements three V4L2 nodes. Every video node implements V4L2 output buffer. One of nodes corresponds to input of Video Processor. The other two nodes correspond to RGB inputs of Mixer. All nodes share the same output. It is one of the Mixer's outputs: SDO or HDMI. Changing output in one layer using S_OUTPUT would change outputs of all other video nodes. The same thing happens if one try to reconfigure output i.e. by calling S_DV_PRESET. However it not possible to change or reconfigure the output while streaming. To sum up, all features in posted version of driver goes as follows: 1. QUERYCAP 2. S_FMT, G_FMT - single and multiplanar API a) node named video0 supports formats NV12, NV12, NV12T (tiled version of NV12), NV12MT (multiplane version of NV12T). b) nodes named
[PATCH 2/3] v4l: add g_tvnorms callback to V4L2 subdev
Callback is used to acquire TV norms supported by a subdev.
It is used to avoid having standards in top-level driver.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/media/v4l2-subdev.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1562c4f..4206e97 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -261,6 +261,7 @@ struct v4l2_subdev_video_ops {
int (*s_crystal_freq)(struct v4l2_subdev *sd, u32 freq, u32 flags);
int (*s_std_output)(struct v4l2_subdev *sd, v4l2_std_id std);
int (*querystd)(struct v4l2_subdev *sd, v4l2_std_id *std);
+ int (*g_tvnorms)(struct v4l2_subdev *sd, v4l2_std_id *std);
int (*g_input_status)(struct v4l2_subdev *sd, u32 *status);
int (*s_stream)(struct v4l2_subdev *sd, int enable);
int (*cropcap)(struct v4l2_subdev *sd, struct v4l2_cropcap *cc);
--
1.7.5.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] v4l: add macro for 1080p59_54 preset
The 1080p59_94 is supported in latest Samusng SoC.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/v4l2-common.c |1 +
include/linux/videodev2.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 06b9f9f..003e648 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -582,6 +582,7 @@ int v4l_fill_dv_preset_info(u32 preset, struct
v4l2_dv_enum_preset *info)
{ 1920, 1080, 1080p@30 }, /* V4L2_DV_1080P30 */
{ 1920, 1080, 1080p@50 }, /* V4L2_DV_1080P50 */
{ 1920, 1080, 1080p@60 }, /* V4L2_DV_1080P60 */
+ { 1920, 1080, 1080p@59.94 }, /* V4L2_DV_1080P59_94 */
};
if (info == NULL || preset = ARRAY_SIZE(dv_presets))
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 38575ae..4d58cfc 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -870,6 +870,7 @@ struct v4l2_dv_enum_preset {
#defineV4L2_DV_1080P30 16 /* SMPTE 296M */
#defineV4L2_DV_1080P50 17 /* BT.1120 */
#defineV4L2_DV_1080P60 18 /* BT.1120 */
+#defineV4L2_DV_1080P59_94 19
/*
* D V B T T I M I N G S
--
1.7.5.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v18 0/6] davinci vpbe: dm6446 v4l2 driver
Fixed Sergei's comments for Kconfig dm644x dependencies Fixed Sekhar'c comment on indentation Manjunath Hadli (6): davinci vpbe: V4L2 display driver for DM644X SoC davinci vpbe: VPBE display driver davinci vpbe: OSD(On Screen Display) block davinci vpbe: VENC( Video Encoder) implementation davinci vpbe: Build infrastructure for VPBE driver davinci vpbe: Readme text for Dm6446 vpbe Documentation/video4linux/README.davinci-vpbe | 93 ++ drivers/media/video/davinci/Kconfig | 23 + drivers/media/video/davinci/Makefile |2 + drivers/media/video/davinci/vpbe.c| 864 drivers/media/video/davinci/vpbe_display.c| 1860 + drivers/media/video/davinci/vpbe_osd.c| 1231 drivers/media/video/davinci/vpbe_osd_regs.h | 364 + drivers/media/video/davinci/vpbe_venc.c | 566 drivers/media/video/davinci/vpbe_venc_regs.h | 177 +++ include/media/davinci/vpbe.h | 184 +++ include/media/davinci/vpbe_display.h | 147 ++ include/media/davinci/vpbe_osd.h | 394 ++ include/media/davinci/vpbe_types.h| 91 ++ include/media/davinci/vpbe_venc.h | 45 + 14 files changed, 6041 insertions(+), 0 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe create mode 100644 drivers/media/video/davinci/vpbe.c create mode 100644 drivers/media/video/davinci/vpbe_display.c create mode 100644 drivers/media/video/davinci/vpbe_osd.c create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h create mode 100644 drivers/media/video/davinci/vpbe_venc.c create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h delete mode 100644 drivers/staging/vme/bridges/Module.symvers create mode 100644 include/media/davinci/vpbe.h create mode 100644 include/media/davinci/vpbe_display.h create mode 100644 include/media/davinci/vpbe_osd.h create mode 100644 include/media/davinci/vpbe_types.h create mode 100644 include/media/davinci/vpbe_venc.h -- 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 v18 2/6] davinci vpbe: VPBE display driver
This patch implements the core functionality of the display driver,
mainly controlling the VENC and other encoders, and acting as
the one point interface for the main V4L2 driver. This implements
the core of each of the V4L2 IOCTLs.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/davinci/vpbe.c | 864
include/media/davinci/vpbe.h | 184
2 files changed, 1048 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe.c
create mode 100644 include/media/davinci/vpbe.h
diff --git a/drivers/media/video/davinci/vpbe.c
b/drivers/media/video/davinci/vpbe.c
new file mode 100644
index 000..d773d30
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe.c
@@ -0,0 +1,864 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/string.h
+#include linux/wait.h
+#include linux/time.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/clk.h
+#include linux/err.h
+
+#include media/v4l2-device.h
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe.h
+#include media/davinci/vpss.h
+#include media/davinci/vpbe_venc.h
+
+#define VPBE_DEFAULT_OUTPUTComposite
+#define VPBE_DEFAULT_MODE ntsc
+
+static char *def_output = VPBE_DEFAULT_OUTPUT;
+static char *def_mode = VPBE_DEFAULT_MODE;
+static int debug;
+
+module_param(def_output, charp, S_IRUGO);
+module_param(def_mode, charp, S_IRUGO);
+module_param(debug, int, 0644);
+
+MODULE_PARM_DESC(def_output, vpbe output name (default:Composite));
+MODULE_PARM_DESC(def_mode, vpbe output mode name (default:ntsc);
+MODULE_PARM_DESC(debug, Debug level 0-1);
+
+MODULE_DESCRIPTION(TI DMXXX VPBE Display controller);
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Texas Instruments);
+
+/**
+ * vpbe_current_encoder_info - Get config info for current encoder
+ * @vpbe_dev - vpbe device ptr
+ *
+ * Return ptr to current encoder config info
+ */
+static struct encoder_config_info*
+vpbe_current_encoder_info(struct vpbe_device *vpbe_dev)
+{
+ struct vpbe_config *cfg = vpbe_dev-cfg;
+ int index = vpbe_dev-current_sd_index;
+
+ return ((index == 0) ? cfg-venc :
+ cfg-ext_encoders[index-1]);
+}
+
+/**
+ * vpbe_find_encoder_sd_index - Given a name find encoder sd index
+ *
+ * @vpbe_config - ptr to vpbe cfg
+ * @output_index - index used by application
+ *
+ * Return sd index of the encoder
+ */
+static int vpbe_find_encoder_sd_index(struct vpbe_config *cfg,
+int index)
+{
+ char *encoder_name = cfg-outputs[index].subdev_name;
+ int i;
+
+ /* Venc is always first */
+ if (!strcmp(encoder_name, cfg-venc.module_name))
+ return 0;
+
+ for (i = 0; i cfg-num_ext_encoders; i++) {
+ if (!strcmp(encoder_name,
+cfg-ext_encoders[i].module_name))
+ return i+1;
+ }
+
+ return -EINVAL;
+}
+
+/**
+ * vpbe_g_cropcap - Get crop capabilities of the display
+ * @vpbe_dev - vpbe device ptr
+ * @cropcap - cropcap is a ptr to struct v4l2_cropcap
+ *
+ * Update the crop capabilities in crop cap for current
+ * mode
+ */
+static int vpbe_g_cropcap(struct vpbe_device *vpbe_dev,
+ struct v4l2_cropcap *cropcap)
+{
+ if (NULL == cropcap)
+ return -EINVAL;
+ cropcap-bounds.left = 0;
+ cropcap-bounds.top = 0;
+ cropcap-bounds.width = vpbe_dev-current_timings.xres;
+ cropcap-bounds.height = vpbe_dev-current_timings.yres;
+ cropcap-defrect = cropcap-bounds;
+
+ return 0;
+}
+
+/**
+ * vpbe_enum_outputs - enumerate outputs
+ * @vpbe_dev - vpbe device ptr
+ * @output - ptr to v4l2_output structure
+ *
+ * Enumerates the outputs available at the vpbe display
+ * returns the status, -EINVAL if end of output list
+ */
+static int vpbe_enum_outputs(struct vpbe_device *vpbe_dev,
+struct v4l2_output *output)
+{
+ struct vpbe_config *cfg = vpbe_dev-cfg;
+ int temp_index = output-index;
+
+ if
[PATCH v18 4/6] davinci vpbe: VENC( Video Encoder) implementation
This patch adds the VENC or the Video encoder, which is responsible
for the blending of all source planes and timing generation for Video
modes like NTSC, PAL and other digital outputs. the VENC implementation
currently supports COMPOSITE and COMPONENT outputs and NTSC and PAL
resolutions through the analog DACs. The venc block is implemented
as a subdevice, allowing for additional external and internal encoders
of other kind to plug-in.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/davinci/vpbe_venc.c | 566 ++
drivers/media/video/davinci/vpbe_venc_regs.h | 177
include/media/davinci/vpbe_venc.h| 45 ++
3 files changed, 788 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe_venc.c
create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
create mode 100644 include/media/davinci/vpbe_venc.h
diff --git a/drivers/media/video/davinci/vpbe_venc.c
b/drivers/media/video/davinci/vpbe_venc.c
new file mode 100644
index 000..03a3e5c
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_venc.c
@@ -0,0 +1,566 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/ctype.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+#include linux/slab.h
+
+#include mach/hardware.h
+#include mach/mux.h
+#include mach/io.h
+#include mach/i2c.h
+
+#include linux/io.h
+
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe_venc.h
+#include media/davinci/vpss.h
+#include media/v4l2-device.h
+
+#include vpbe_venc_regs.h
+
+#define MODULE_NAMEVPBE_VENC_SUBDEV_NAME
+
+static int debug = 2;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, Debug level 0-2);
+
+struct venc_state {
+ struct v4l2_subdev sd;
+ struct venc_callback *callback;
+ struct venc_platform_data *pdata;
+ struct device *pdev;
+ u32 output;
+ v4l2_std_id std;
+ spinlock_t lock;
+ void __iomem *venc_base;
+ void __iomem *vdaccfg_reg;
+};
+
+static inline struct venc_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct venc_state, sd);
+}
+
+static inline u32 venc_read(struct v4l2_subdev *sd, u32 offset)
+{
+ struct venc_state *venc = to_state(sd);
+
+ return readl(venc-venc_base + offset);
+}
+
+static inline u32 venc_write(struct v4l2_subdev *sd, u32 offset, u32 val)
+{
+ struct venc_state *venc = to_state(sd);
+
+ writel(val, (venc-venc_base + offset));
+
+ return val;
+}
+
+static inline u32 venc_modify(struct v4l2_subdev *sd, u32 offset,
+u32 val, u32 mask)
+{
+ u32 new_val = (venc_read(sd, offset) ~mask) | (val mask);
+
+ venc_write(sd, offset, new_val);
+
+ return new_val;
+}
+
+static inline u32 vdaccfg_write(struct v4l2_subdev *sd, u32 val)
+{
+ struct venc_state *venc = to_state(sd);
+
+ writel(val, venc-vdaccfg_reg);
+
+ val = readl(venc-vdaccfg_reg);
+
+ return val;
+}
+
+/* This function sets the dac of the VPBE for various outputs
+ */
+static int venc_set_dac(struct v4l2_subdev *sd, u32 out_index)
+{
+ switch (out_index) {
+ case 0:
+ v4l2_dbg(debug, 1, sd, Setting output to Composite\n);
+ venc_write(sd, VENC_DACSEL, 0);
+ break;
+ case 1:
+ v4l2_dbg(debug, 1, sd, Setting output to S-Video\n);
+ venc_write(sd, VENC_DACSEL, 0x210);
+ break;
+ case 2:
+ venc_write(sd, VENC_DACSEL, 0x543);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void venc_enabledigitaloutput(struct v4l2_subdev *sd, int benable)
+{
+ v4l2_dbg(debug, 2, sd, venc_enabledigitaloutput\n);
+
+ if (benable) {
+ venc_write(sd, VENC_VMOD, 0);
+ venc_write(sd, VENC_CVBS, 0);
+ venc_write(sd, VENC_LCDOUT, 0);
+ venc_write(sd, VENC_HSPLS, 0);
+ venc_write(sd,
[PATCH v18 6/6] davinci vpbe: Readme text for Dm6446 vpbe
Please refer to this file for detailed documentation of davinci vpbe v4l2 driver. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Acked-by: Muralidharan Karicheri m-kariche...@ti.com Acked-by: Hans Verkuil hverk...@xs4all.nl --- Documentation/video4linux/README.davinci-vpbe | 93 + 1 files changed, 93 insertions(+), 0 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe diff --git a/Documentation/video4linux/README.davinci-vpbe b/Documentation/video4linux/README.davinci-vpbe new file mode 100644 index 000..7a460b0 --- /dev/null +++ b/Documentation/video4linux/README.davinci-vpbe @@ -0,0 +1,93 @@ + +VPBE V4L2 driver design + == + + File partitioning + - + V4L2 display device driver + drivers/media/video/davinci/vpbe_display.c + drivers/media/video/davinci/vpbe_display.h + + VPBE display controller + drivers/media/video/davinci/vpbe.c + drivers/media/video/davinci/vpbe.h + + VPBE venc sub device driver + drivers/media/video/davinci/vpbe_venc.c + drivers/media/video/davinci/vpbe_venc.h + drivers/media/video/davinci/vpbe_venc_regs.h + + VPBE osd driver + drivers/media/video/davinci/vpbe_osd.c + drivers/media/video/davinci/vpbe_osd.h + drivers/media/video/davinci/vpbe_osd_regs.h + + Functional partitioning + --- + + Consists of the following (in the same order as the list under file + partitioning):- + + 1. V4L2 display driver +Implements creation of video2 and video3 device nodes and +provides v4l2 device interface to manage VID0 and VID1 layers. + + 2. Display controller +Loads up VENC, OSD and external encoders such as ths8200. It provides +a set of API calls to V4L2 drivers to set the output/standards +in the VENC or external sub devices. It also provides +a device object to access the services from OSD subdevice +using sub device ops. The connection of external encoders to VENC LCD +controller port is done at init time based on default output and standard +selection or at run time when application change the output through +V4L2 IOCTLs. + +When connected to an external encoder, vpbe controller is also responsible +for setting up the interface between VENC and external encoders based on +board specific settings (specified in board-xxx-evm.c). This allows +interfacing external encoders such as ths8200. The setup_if_config() +is implemented for this as well as configure_venc() (part of the next patch) +API to set timings in VENC for a specific display resolution. As of this +patch series, the interconnection and enabling and setting of the external +encoders is not present, and would be a part of the next patch series. + + 3. VENC subdevice module +Responsible for setting outputs provided through internal DACs and also +setting timings at LCD controller port when external encoders are connected +at the port or LCD panel timings required. When external encoder/LCD panel +is connected, the timings for a specific standard/preset is retrieved from +the board specific table and the values are used to set the timings in +venc using non-standard timing mode. + +Support LCD Panel displays using the VENC. For example to support a Logic +PD display, it requires setting up the LCD controller port with a set of +timings for the resolution supported and setting the dot clock. So we could +add the available outputs as a board specific entry (i.e add the LogicPD +output name to board-xxx-evm.c). A table of timings for various LCDs +supported can be maintained in the board specific setup file to support +various LCD displays.As of this patch a basic driver is present, and this +support for external encoders and displays forms a part of the next +patch series. + + 4. OSD module +OSD module implements all OSD layer management and hardware specific +features. The VPBE module interacts with the OSD for enabling and +disabling appropriate features of the OSD. + + Current status:- + + A fully functional working version of the V4L2 driver is available. This + driver has been tested with NTSC and PAL standards and buffer streaming. + + Following are TBDs. + + vpbe display controller +- Add support for external encoders. +- add support for selecting external encoder as default at probe time. + + vpbe venc sub device +- add timings for supporting ths8200 +- add support for LogicPD LCD. + + FB drivers +- Add support for fbdev drivers.- Ready and part of subsequent patches. -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 24-05-2011 04:21, Hans de Goede escreveu: Hi, My I suggest that we instead just copy over the single get_media_devices.c file to xawtv, and not install the not so much a lib lib ? If we do that, then all other places where the association between an alsa device and a video4linux node is needed will need to copy it, and we'll have a fork. Also, we'll keep needing it at v4l-utils, as it is now needed by the new version of v4l2-sysfs-path tool. Btw, this lib were created due to a request from the vlc maintainer that something like that would be needed. After finishing it, I decided to add it at xawtv in order to have an example about how to use it. Mauro, I plan to do a new v4l-utils release soon (*), maybe even today. I consider it unpolite to revert other peoples commits, so I would prefer for you to revert the install libv4l2util.a patch yourself. But if you don't (or don't get around to doing it before I do the release), I will revert it, as this clearly needs more discussion before making it into an official release tarbal (we can always re-introduce the patch after the release). I'm not a big fan or exporting the rest of stuff at libv4l2util.a either, but I think that at least the get_media_devices stuff should be exported somewhere, maybe as part of libv4l. Anyway, as you're releasing today a new v4l-utils, I agree that it is too early to add such library, as it is still experimental. I'm not considering make any new xawtv release those days, so I'm OK to postpone it. I'll commit a few patches commenting the install procedure for now, re-adding it after the release, for those that want to experiment it with xawtv with the new support. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: FW: OMAP 3 ISP
merged :-) I don't need to step on toes and submit something you've already done, so maybe you want to point me to a branch with the SPI stuff, and I'll just put the platform stuff on top of it? I'll send the SPI support patches to linux-media, as they haven't been reviewed publicly yet. -- Regards, Laurent Pinchart __ Information from ESET NOD32 Antivirus, version of virus signature database 6135 (20110519) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6135 (20110519) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- Sakari Ailus sakari dot ailus at iki dot fi __ Information from ESET NOD32 Antivirus, version of virus signature database 6135 (20110519) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6147 (20110524) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.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: [GIT PATCH FOR 2.6.40] uvcvideo patches
Em 23-05-2011 19:27, Laurent Pinchart escreveu: Hi Mauro, On Friday 20 May 2011 23:01:18 Mauro Carvalho Chehab wrote: Em 20-05-2011 16:47, Laurent Pinchart escreveu: On Friday 20 May 2011 21:16:49 Mauro Carvalho Chehab wrote: Em 20-05-2011 12:49, Laurent Pinchart escreveu: On Friday 20 May 2011 17:32:45 Mauro Carvalho Chehab wrote: Em 15-05-2011 04:48, Laurent Pinchart escreveu: Hi Mauro, The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next They replace the git pull request I've sent on Thursday with the same subject. [snip] Laurent Pinchart (4): v4l: Release module if subdev registration fails uvcvideo: Register a v4l2_device uvcvideo: Register subdevices for each entity uvcvideo: Connect video devices to media entities We've discussed already about using the media controller for uvcvideo, but I can't remember anymore what where your aguments in favor of merging it (and, even if I've remembered it right now, the #irc channel log is not the proper way to document the rationale to apply a patch). The thing is: it is clear that SoC embedded devices need the media controller, as they have IP blocks that do weird things, and userspace may need to access those, as it is not possible to control such IP blocks using the V4L2 API. However, I have serious concerns about media_controller API usage on generic drivers, as it is required that all drivers should be fully configurable via V4L2 API alone, otherwise we'll have regressions, as no generic applications use the media_controller. In other words, if you have enough arguments about why we should add media_controller support at the uvcvideo, please clearly provide them at the patch descriptions, as this is not obvious. It would equally important do document, at the uvcvideo doc, what kind of information is provided via the media_controller and why an userspace application should care to use it. First of all, the uvcvideo driver doesn't require application to use the media controller API to operate. All configuration is handled through a V4L2 video device node, and these patches do not modify that. No change is required to applications to use the uvcvideo driver. There's however a reason why I want to add support for the media controller API to the uvcvideo driver (I wouldn't have submitted the patches otherwise :-)). UVC-compliant devices are modeled as a connected graph of :entities (called terminals and units in the UVC world). The device topology can be arbitrarily complex (or simple, which is fortunately often the case) and is exported by the device to the host through USB descriptors. The uvcvideo driver parses the descriptor, creates an internal representation of the device internal topology, and maps V4L2 operations to the various entities that the device contains. The UVC specification standardizes a couple of entities (camera terminal, processing unit, ...) and allows device vendors to create vendor-specific entities called extension units (XUs in short). Those XUs are usually used to expose controls that are not standardized by UVC to the host. These controls can be anything from an activity LED to a firmware update system. The uvcvideo tries to map those XU controls to V4L2 controls when it makes sense (and when the controls are documented by the device manufacturer, which is unfortunately often not the case). If an XU control can't be mapped to a V4L2 control, it can be accessed through uvcvideo-specific (documented) ioctls. In order to access those XU controls, device-specific applications (such as a firmware update application for instance) need to know what XUs are present in the device and possibly how they are connected. That information can't be exported through V4L2. That's why I'm adding media controller support to the uvcvideo driver. By allowing access to those undocumented XU controls an Evil Manufacturer(tm) could try to sell its own proprietary software that will work on Linux where all other software will deadly fail or will produce very bad results. We've seen that history before. As you're putting some names, let me be clearer. In the past we had bad stuff like this one: http://kerneltrap.org/node/3729 that ended by the need of somebody to rewrite the entire pwc driver, because the only way to get a decent image using a Philips camera, with the open source driver were to run a closed-source binary. I clearly remember that, and I think you know that I'm a strong advocate of open-source drivers (right ? :-)). undocumented controls that can do everything, as you said, can create a similar situation to what we had in the past. The situation with the pwc driver was very different. The
Re: [ANNOUNCE] experimental alsa stream support at xawtv3
Em 24-05-2011 03:50, Hans Verkuil escreveu: On Monday, May 23, 2011 22:17:06 Mauro Carvalho Chehab wrote: Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils) during the weekend, I decided to add alsa support also on xawtv3, basically to provide a real usecase example. Of course, for it to work, it needs the very latest v4l2-utils version from the git tree. Please, please add at the very least some very big disclaimer in libv4l2util that the API/ABI is likely to change. As mentioned earlier, this library is undocumented, has not gone through any peer-review, and I am very unhappy with it and with the decision (without discussion it seems) to install it. With respect to the other stuff inside libv4l2util, they are there for a long time, and not much has changed since them. Yet, I'm not a big fan of exporting them, as they may not be useful to other applications. With respect to the new API I've added, there are not much to change at the get_media_devices stuff. It has just 5 methods: one to retrieve info, one to free data, one to display all info (used by v4l2-sysfs-path tool), and two for getting the alsa devices. Of course, new functions can always be added, and the structs might need more fields. I've added a proper documentation for it. I also added a macro with a version number for the library. This will help userspace apps that would use it to check for the version number. That's said, I'm moving the get_media_devices into a new library, to avoid mixing it with other stuff. As I said, I'm OK to postpone the install to happen for the -next version of v4l2-utils, so I've commented for now the install scripts for it. Once you install it on systems it becomes much harder to change. Regards, Hans Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][RFC] Add mt9p031 sensor support.
This RFC includes a power management implementation that causes
the sensor to show images with horizontal artifacts (usually
monochrome lines that appear on the image randomly).
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile |1 +
drivers/media/video/mt9p031.c | 841 +
include/media/mt9p031.h | 11 +
4 files changed, 860 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mt9p031.c
create mode 100644 include/media/mt9p031.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 00f51dd..8a596cc 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -329,6 +329,13 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_MT9P031
+ tristate Aptina MT9P031 support
+ depends on I2C VIDEO_V4L2
+ ---help---
+This is a Video4Linux2 sensor-level driver for the Aptina
+(Micron) mt9p031 5 Mpixel camera.
+
config VIDEO_MT9V011
tristate Micron mt9v011 sensor support
depends on I2C VIDEO_V4L2
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ace5d8b..912b29b 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
+obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
new file mode 100644
index 000..04d8812
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
@@ -0,0 +1,841 @@
+/*
+ * Driver for MT9P031 CMOS Image Sensor from Aptina
+ *
+ * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * Based on the MT9V032 driver and Bastian Hecht's code.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/device.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include media/v4l2-subdev.h
+#include linux/videodev2.h
+
+#include media/mt9p031.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
+#include media/v4l2-device.h
+
+#define MT9P031_PIXCLK_FREQ5400
+
+/* mt9p031 selected register addresses */
+#define MT9P031_CHIP_VERSION 0x00
+#defineMT9P031_CHIP_VERSION_VALUE 0x1801
+#define MT9P031_ROW_START 0x01
+#defineMT9P031_ROW_START_DEF 54
+#define MT9P031_COLUMN_START 0x02
+#defineMT9P031_COLUMN_START_DEF16
+#define MT9P031_WINDOW_HEIGHT 0x03
+#define MT9P031_WINDOW_WIDTH 0x04
+#define MT9P031_H_BLANKING 0x05
+#defineMT9P031_H_BLANKING_VALUE0
+#define MT9P031_V_BLANKING 0x06
+#defineMT9P031_V_BLANKING_VALUE25
+#define MT9P031_OUTPUT_CONTROL 0x07
+#defineMT9P031_OUTPUT_CONTROL_CEN 2
+#defineMT9P031_OUTPUT_CONTROL_SYN 1
+#define MT9P031_SHUTTER_WIDTH_UPPER0x08
+#define MT9P031_SHUTTER_WIDTH 0x09
+#define MT9P031_PIXEL_CLOCK_CONTROL0x0a
+#define MT9P031_FRAME_RESTART 0x0b
+#define MT9P031_SHUTTER_DELAY 0x0c
+#define MT9P031_RST0x0d
+#defineMT9P031_RST_ENABLE 1
+#defineMT9P031_RST_DISABLE 0
+#define MT9P031_READ_MODE_10x1e
+#define MT9P031_READ_MODE_20x20
+#defineMT9P031_READ_MODE_2_ROW_MIR 0x8000
+#defineMT9P031_READ_MODE_2_COL_MIR 0x4000
+#define MT9P031_ROW_ADDRESS_MODE 0x22
+#define MT9P031_COLUMN_ADDRESS_MODE0x23
+#define MT9P031_GLOBAL_GAIN0x35
+
+#define MT9P031_WINDOW_HEIGHT_MAX 1944
+#define MT9P031_WINDOW_WIDTH_MAX 2592
+#define MT9P031_WINDOW_HEIGHT_MIN 2
+#define MT9P031_WINDOW_WIDTH_MIN 18
+
+struct mt9p031 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_rect rect; /* Sensor window */
+ struct v4l2_mbus_framefmt format;
+ struct mt9p031_platform_data *pdata;
+
Re: [ANNOUNCE] experimental alsa stream support at xawtv3
On Tue, May 24, 2011 at 2:50 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Monday, May 23, 2011 22:17:06 Mauro Carvalho Chehab wrote: Due to the alsa detection code that I've added at libv4l2util (at v4l2-utils) during the weekend, I decided to add alsa support also on xawtv3, basically to provide a real usecase example. Of course, for it to work, it needs the very latest v4l2-utils version from the git tree. Please, please add at the very least some very big disclaimer in libv4l2util that the API/ABI is likely to change. As mentioned earlier, this library is undocumented, has not gone through any peer-review, and I am very unhappy with it and with the decision (without discussion it seems) to install it. Once you install it on systems it becomes much harder to change. I share Hans' concern on this. This is an API that seems pretty immature, and I worry that it's adoption will cause lots of problems as people expect it to work with a wide variety of tuners. For example, how does the sysfs approach handle PCI boards that have multiple video and audio devices? The sysfs layout will effectively be: PCI DEVICE - video0 - video1 - alsa hw:1,0 - alsa hw:1,1 The approach taken in this library will probably help with the simple cases such as a USB tuner that only has a single video device, audio device, and VBI device. But it's going to fall flat on its face when it comes to devices that have multiple capture sources (since sysfs will represent this as a tree with all the nodes on the same level). Oh, and how is it expected to handle informing the application about device contention between DVB and V4L? Some devices share the tuner and therefore you cannot use both the V4L and DVB device at the same time. Other products have two independent input paths on the same board, allowing both to be used simultaneously (the HVR-1600 is a popular example of this). Sysfs isn't going to tell you this information, which is why in the MC API we explicitly added the notion of device groups (so the driver author can explicitly state the relationships). Today MythTV users accomplish this by manually specifying Input Groups. I say that's what they do, but in reality they don't realize that they need to configure MythTV this way until they complain that MythTV recordings fail when trying to record programs on both inputs, at which point an advanced user points it out to them. End users shouldn't have to understand the internal architecture of their capture card just to avoid weird crashy behavior (which is what often happens if you try to use both devices simultaneously since almost no hybrid drivers do proper locking). I am in favor of this finally getting some attention, but the reality is that sysfs isn't going to cut it. It just doesn't expose enough information about the underlying hardware layout. 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: [PATCH v18 5/6] davinci vpbe: Build infrastructure for VPBE driver
Hello. Manjunath Hadli wrote: This patch adds the build infra-structure for Davinci VPBE dislay driver. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Acked-by: Muralidharan Karicheri m-kariche...@ti.com Acked-by: Hans Verkuil hverk...@xs4all.nl --- drivers/media/video/davinci/Kconfig| 23 +++ drivers/media/video/davinci/Makefile |2 ++ 2 files changed, 25 insertions(+), 0 deletions(-) delete mode 100644 drivers/staging/vme/bridges/Module.symvers [...] diff --git a/drivers/staging/vme/bridges/Module.symvers b/drivers/staging/vme/bridges/Module.symvers deleted file mode 100644 index e69de29..000 Looks like a stray file got added to the patch... 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: [ANNOUNCE] experimental alsa stream support at xawtv3
Hi,
On 05/24/2011 04:09 PM, Mauro Carvalho Chehab wrote:
Em 24-05-2011 04:21, Hans de Goede escreveu:
Hi,
My I suggest that we instead just copy over the single get_media_devices.c
file to xawtv, and not install the not so much a lib lib ?
If we do that, then all other places where the association between an alsa
device
and a video4linux node is needed will need to copy it, and we'll have a fork.
Also, we'll keep needing it at v4l-utils, as it is now needed by the new version
of v4l2-sysfs-path tool.
Btw, this lib were created due to a request from the vlc maintainer that
something
like that would be needed. After finishing it, I decided to add it at xawtv in
order
to have an example about how to use it.
I'm not saying that this is not useful to have, I'm just worried about
exporting the API before it has had any chance to stabilize, and about
also throwing in the other random libv4l2util bits.
Mauro, I plan to do a new v4l-utils release soon (*), maybe even today. I
consider it unpolite to revert other peoples commits, so I would prefer for you
to revert the install libv4l2util.a patch yourself. But if you don't (or don't
get around to doing it before I do the release), I will revert it, as this
clearly needs more discussion before making it into an official release
tarbal (we can always re-introduce the patch after the release).
I'm not a big fan or exporting the rest of stuff at libv4l2util.a either
Glad we agree on that :)
but I
think that at least the get_media_devices stuff should be exported somewhere,
Agreed.
maybe as part of libv4l.
That would be a logical place to put it, otoh currently libv4l mostly mimics the
raw /dev/video# node API, so adding this API is not a logical fit there ...
It may make more sense to have something in libv4l2 like:
enum libv4l2_associated_device_types {
libv4l2_alsa_input,
libv4l2_alsa_output,
libv4l2_vbi
};
int libv4l2_get_associated_devive(int fd, enum libv4l2_associated_device_types
type, ...);
Where fd is the fd of an open /dev/video node, and ... is a param through
which the device gets returned (I guess a char * to a buffer of MAX_PATH
length where the device name gets stored, this could
be an also identifier like hw:0.0 or in case of vbi a /dev/vbi# path, etc.
Note that an API for enumerating available /dev/video nodes would also
be a welcome addition to libv4l2. Anyways I think we're are currently
doing this the wrong way up. We should first discuss what such an API
should look like and then implement it. Hopefully we can re-use a lot
of the existing code when we do this, but I think it is better
to first design the API and then write code to the API, the current
API at least to me feels somewhat like an API written around existing
code rather then the other way around.
Anyway, as you're releasing today a new v4l-utils, I agree that it is too early
to add such library, as it is still experimental. I'm not considering make any
new xawtv release those days, so I'm OK to postpone it.
I'll commit a few patches commenting the install procedure for now, re-adding it
after the release, for those that want to experiment it with xawtv with the new
support.
Thanks!
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: dvb: one demux per tuner or one demux per demod?
Hello, - Message d'origine - I believe you can only use one frontend at once per adapter (this is certainly enforced in the cxd2820r module), so I don't see how it would cause a problem for mappings. I think a dual tuner device would register itself as two adapters, wouldn't it? That would be one scheme: there would only ever be one demux per adapter then. But from archives of this very mailing list, I gather that say HVR 3000 shows up as two frontends (DVB-T and DVB-S) with a demux each... Not consistent if true (I do not have such a device to check). For seamless setup in userspace, I need a consistent mapping scheme, whatever that is. Ideally, I would be able to distinguish multiproto frontends from dual tuners from dual tuners with dual antenna. At the very least, I need a way to find the demux that corresponds to a frontend. And until DMX_OUT_TSDEMUX_TAP works correctly, to a dvr. Otherwise, user needs to configure frontend AND demux, which is really unfriendly and error-prone. -- Rémi -- 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
STV6110 FE_READ_STATUS implementation
Hi Manu, I'm currently writing an application that needs to know the detailed frontend status when there is no lock. As far as I can see from the sources, the code will only set the right status when there is a lock in stv6110x_get_status(). Does the STV6110 supports reporting of signal, carrier, viterbi and sync ? I'd be happy to implement that if it does but I wasn't able to find the datasheet. Do you have that available ? Regards, Guy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] drivers/media/dvb/dvb-usb/pctv452e.c does not work in latest media_tree.git
On Tuesday 24 May 2011 15:59:57 André Weidemann wrote:
Hi Peter,
For the time being the S2-3200 and related cards do not seem to work.
From my understanding this patch should have been rolled back, but
Mauro did not. Feel free to post a message to the linux-media mailing
list. Maybe someone there knows a bit more...
Regards
André
Hi,
I did some more investigation and found what appears to be close to a fix:
media_tree/drivers/media/dvb/frontends/stb0899_algo.c
There is some automagic frequency guessing which does not work:
/* timing loop computation symbol rate optimisation */
derot_limit = (internal-sub_range / 2L) / internal-mclk;
derot_step = (params-srate / 2L) / internal-mclk;
^ by changing this line to:
+derot_step = (params-srate / 16L) / internal-mclk;
Things are starting to look better. I'm thinking about using a simple:
derot_freq = ((index * index) - index) * internal-direction;
This gives 127 steps before the maximum is reached.
while ((stb0899_check_tmg(state) != TIMINGOK) next_loop) {
index++;
derot_freq += index * internal-direction * derot_step; /*
next derot zig zag position */
if (abs(derot_freq) derot_limit)
next_loop--;
if (next_loop) {
STB0899_SETFIELD_VAL(CFRM, cfr[0], MSB(state-config-
inversion * derot_freq));
STB0899_SETFIELD_VAL(CFRL, cfr[1], LSB(state-config-
inversion * derot_freq));
stb0899_write_regs(state, STB0899_CFRM, cfr, 2); /*
derotator frequency */
}
internal-direction = -internal-direction; /* Change
zigzag direction */
}
Any comments?
--HPS
--
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: [ANNOUNCE] experimental alsa stream support at xawtv3
--- On Tue, 24/5/11, Devin Heitmueller dheitmuel...@kernellabs.com wrote: From: Devin Heitmueller dheitmuel...@kernellabs.com Subject: Re: [ANNOUNCE] experimental alsa stream support at xawtv3 To: Hans Verkuil hverk...@xs4all.nl Cc: Mauro Carvalho Chehab mche...@redhat.com, Linux Media Mailing List linux-media@vger.kernel.org Date: Tuesday, 24 May, 2011, 16:57 On Tue, May 24, 2011 at 2:50 AM, Hans Oh, and how is it expected to handle informing the application about device contention between DVB and V4L? Some devices share the tuner and therefore you cannot use both the V4L and DVB device at the same time. Other products have two independent input paths on the same board, allowing both to be used simultaneously (the HVR-1600 is a popular example of this). Sysfs isn't going to tell you this information, which is why in the MC API we explicitly added the notion of device groups (so the driver author can explicitly state the relationships). Today MythTV users accomplish this by manually specifying Input Groups. I say that's what they do, but in reality they don't realize that they need to configure MythTV this way until they complain that MythTV recordings fail when trying to record programs on both inputs, at which point an advanced user points it out to them. End users shouldn't have to understand the internal architecture of their capture card just to avoid weird crashy behavior (which is what often happens if you try to use both devices simultaneously since almost no hybrid drivers do proper locking). Are there mechanisms for device-locking in the v4l api? With my 2 hybrid saa7134 cards I have observed exactly this issues in Mythtv and also in xawtv and kaffeine At the moment I disable one device via additional card definitions and modprobe-parameters, so that the other one is alone and only one app gets control over the tuner. But this driver (saa7134) seams not even lock the /dev/video0 correctly, as starting xawtv twice renders the card inoperable and forces rebooting to get the card working again... Is there a good starting point to implement the locking? I am in favor of this finally getting some attention, but the reality is that sysfs isn't going to cut it. It just doesn't expose enough information about the underlying hardware layout. 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 Emil -- 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: STV6110 FE_READ_STATUS implementation
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Guy Martin Sent: mardi 24 mai 2011 18:18 To: abraham.m...@gmail.com Cc: linux-media@vger.kernel.org Subject: STV6110 FE_READ_STATUS implementation Hi Manu, I'm currently writing an application that needs to know the detailed frontend status when there is no lock. As far as I can see from the sources, the code will only set the right status when there is a lock in stv6110x_get_status(). Does the STV6110 supports reporting of signal, carrier, viterbi and sync ? I've done some tests with the CineS2, that is using the STV6110A as the tuner and the STV0903 as the demodulator. The values you are searching for don't come from the tuner, but the demodulator. In my case, the STV0903 is reporting the five following states : SCVYL. I'd be happy to implement that if it does but I wasn't able to find the datasheet. Do you have that available ? Regards, Guy -- 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
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue May 24 19:00:58 CEST 2011 git hash:f9b51477fe540fb4c65a05027fdd6f2ecce4db3b gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: STV090x FE_READ_STATUS implementation
On Tue, 24 May 2011 19:47:17 +0200 Sébastien RAILLARD (COEXSI) s...@coexsi.fr wrote: Does the STV6110 supports reporting of signal, carrier, viterbi and sync ? I've done some tests with the CineS2, that is using the STV6110A as the tuner and the STV0903 as the demodulator. The values you are searching for don't come from the tuner, but the demodulator. In my case, the STV0903 is reporting the five following states : SCVYL. Indeed, after some more troubleshooting, I found out that the problem is not in the STV6110 but in the STV090X code. The card I'm using is a TT S2-1600. The function stv090x_read_status() only reports the status when locked. I couldn't find the datasheet either for this one. Manu is the maintainer as well. Maybe he has more input on this. In the meantime, I'll give a closer look at the code see if I can figure out a way to fix that. Thanks, Guy -- 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: STV090x FE_READ_STATUS implementation
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Guy Martin Sent: mardi 24 mai 2011 20:45 To: Sébastien RAILLARD (COEXSI) Cc: abraham.m...@gmail.com; linux-media@vger.kernel.org Subject: Re: STV090x FE_READ_STATUS implementation On Tue, 24 May 2011 19:47:17 +0200 Sébastien RAILLARD (COEXSI) s...@coexsi.fr wrote: Does the STV6110 supports reporting of signal, carrier, viterbi and sync ? I've done some tests with the CineS2, that is using the STV6110A as the tuner and the STV0903 as the demodulator. The values you are searching for don't come from the tuner, but the demodulator. In my case, the STV0903 is reporting the five following states : SCVYL. Indeed, after some more troubleshooting, I found out that the problem is not in the STV6110 but in the STV090X code. The card I'm using is a TT S2-1600. The function stv090x_read_status() only reports the status when locked. I couldn't find the datasheet either for this one. Manu is the maintainer as well. Maybe he has more input on this. Strange, as it must be the same demodulator and code as for the CineS2! Not easy to get the datasheets from ST, they have never replied to my enquiries... In the meantime, I'll give a closer look at the code see if I can figure out a way to fix that. Thanks, Guy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] drivers/media/dvb/dvb-usb/pctv452e.c does not work in latest media_tree.git
Final patch. Please test and review!
From 83224b9c4b5402332589139549b387066bff8277 Mon Sep 17 00:00:00 2001
From: Hans Petter Selasky hsela...@c2i.net
Date: Tue, 24 May 2011 21:44:53 +0200
Subject: [PATCH] Fix the derot zig-zag to work with TT-USB2.0 TechnoTrend
hardware.
Signed-off-by: Hans Petter Selasky hsela...@c2i.net
---
drivers/media/dvb/frontends/stb0899_algo.c | 113 ---
1 files changed, 50 insertions(+), 63 deletions(-)
diff --git a/drivers/media/dvb/frontends/stb0899_algo.c
b/drivers/media/dvb/frontends/stb0899_algo.c
index d70eee0..1dbd9be 100644
--- a/drivers/media/dvb/frontends/stb0899_algo.c
+++ b/drivers/media/dvb/frontends/stb0899_algo.c
@@ -23,6 +23,13 @@
#include stb0899_priv.h
#include stb0899_reg.h
+#include linux/kernel.h
+#include linux/module.h
+
+static int derot_max = 8192;
+module_param(derot_max, int, 0644);
+MODULE_PARM_DESC(derot_max, Set Maximum Derot Value (0..32767));
+
static inline u32 stb0899_do_div(u64 n, u32 d)
{
/* wrap do_div() for ease of use */
@@ -117,7 +124,7 @@ static u32 stb0899_set_srate(struct stb0899_state *state,
u32 master_clk, u32 sr
*/
static long stb0899_calc_derot_time(long srate)
{
- if (srate 0)
+ if (srate 999)
return (10 / (srate / 1000));
else
return 0;
@@ -207,30 +214,22 @@ static enum stb0899_status stb0899_search_tmg(struct
stb0899_state *state)
{
struct stb0899_internal *internal = state-internal;
struct stb0899_params *params = state-params;
-
- short int derot_step, derot_freq = 0, derot_limit, next_loop = 3;
+ int derot_freq = 0;
int index = 0;
u8 cfr[2];
internal-status = NOTIMING;
+ internal-direction = 1;
- /* timing loop computation symbol rate optimisation */
- derot_limit = (internal-sub_range / 2L) / internal-mclk;
- derot_step = (params-srate / 2L) / internal-mclk;
+ while ((stb0899_check_tmg(state) != TIMINGOK) (abs(derot_freq) =
derot_max)) {
+ derot_freq += index * (index - 1) * internal-direction;
/* next
derot zig zag position */
- while ((stb0899_check_tmg(state) != TIMINGOK) next_loop) {
- index++;
- derot_freq += index * internal-direction * derot_step; /* next
derot zig zag position */
+ STB0899_SETFIELD_VAL(CFRM, cfr[0], MSB(state-config-inversion
*
derot_freq));
+ STB0899_SETFIELD_VAL(CFRL, cfr[1], LSB(state-config-inversion
*
derot_freq));
+ stb0899_write_regs(state, STB0899_CFRM, cfr, 2); /* derotator
frequency */
- if (abs(derot_freq) derot_limit)
- next_loop--;
-
- if (next_loop) {
- STB0899_SETFIELD_VAL(CFRM, cfr[0],
MSB(state-config-inversion *
derot_freq));
- STB0899_SETFIELD_VAL(CFRL, cfr[1],
LSB(state-config-inversion *
derot_freq));
- stb0899_write_regs(state, STB0899_CFRM, cfr, 2); /*
derotator
frequency */
- }
internal-direction = -internal-direction; /* Change
zigzag direction
*/
+ index++;
}
if (internal-status == TIMINGOK) {
@@ -277,50 +276,41 @@ static enum stb0899_status stb0899_check_carrier(struct
stb0899_state *state)
static enum stb0899_status stb0899_search_carrier(struct stb0899_state
*state)
{
struct stb0899_internal *internal = state-internal;
-
- short int derot_freq = 0, last_derot_freq = 0, derot_limit, next_loop =
3;
+ int derot_freq;
int index = 0;
u8 cfr[2];
u8 reg;
internal-status = NOCARRIER;
- derot_limit = (internal-sub_range / 2L) / internal-mclk;
+ internal-direction = 1;
derot_freq = internal-derot_freq;
reg = stb0899_read_reg(state, STB0899_CFD);
STB0899_SETFIELD_VAL(CFD_ON, reg, 1);
stb0899_write_reg(state, STB0899_CFD, reg);
- do {
+ while ((stb0899_check_carrier(state) == NOCARRIER) (abs(derot_freq)
=
derot_max)) {
+
+ derot_freq += index * (index - 1) * internal-direction;
/* next
derot zig zag position */
+
dprintk(state-verbose, FE_DEBUG, 1, Derot Freq=%d, mclk=%d,
derot_freq, internal-mclk);
- if (stb0899_check_carrier(state) == NOCARRIER) {
- index++;
- last_derot_freq = derot_freq;
- derot_freq += index * internal-direction *
internal-derot_step;
/* next zig zag derotator position */
-
- if(abs(derot_freq) derot_limit)
- next_loop--;
-
- if (next_loop) {
- reg = stb0899_read_reg(state, STB0899_CFD);
- STB0899_SETFIELD_VAL(CFD_ON, reg, 1);
-
[PATCH] Fix the derot zig-zag to work with TT-USB2.0 TechnoTrend hardware.
(This time without any word wrappings)
From 83224b9c4b5402332589139549b387066bff8277 Mon Sep 17 00:00:00 2001
From: Hans Petter Selasky hsela...@c2i.net
Date: Tue, 24 May 2011 21:44:53 +0200
Subject: [PATCH] Fix the derot zig-zag to work with TT-USB2.0 TechnoTrend
hardware.
Signed-off-by: Hans Petter Selasky hsela...@c2i.net
---
drivers/media/dvb/frontends/stb0899_algo.c | 113 ---
1 files changed, 50 insertions(+), 63 deletions(-)
diff --git a/drivers/media/dvb/frontends/stb0899_algo.c
b/drivers/media/dvb/frontends/stb0899_algo.c
index d70eee0..1dbd9be 100644
--- a/drivers/media/dvb/frontends/stb0899_algo.c
+++ b/drivers/media/dvb/frontends/stb0899_algo.c
@@ -23,6 +23,13 @@
#include stb0899_priv.h
#include stb0899_reg.h
+#include linux/kernel.h
+#include linux/module.h
+
+static int derot_max = 8192;
+module_param(derot_max, int, 0644);
+MODULE_PARM_DESC(derot_max, Set Maximum Derot Value (0..32767));
+
static inline u32 stb0899_do_div(u64 n, u32 d)
{
/* wrap do_div() for ease of use */
@@ -117,7 +124,7 @@ static u32 stb0899_set_srate(struct stb0899_state *state,
u32 master_clk, u32 sr
*/
static long stb0899_calc_derot_time(long srate)
{
- if (srate 0)
+ if (srate 999)
return (10 / (srate / 1000));
else
return 0;
@@ -207,30 +214,22 @@ static enum stb0899_status stb0899_search_tmg(struct
stb0899_state *state)
{
struct stb0899_internal *internal = state-internal;
struct stb0899_params *params = state-params;
-
- short int derot_step, derot_freq = 0, derot_limit, next_loop = 3;
+ int derot_freq = 0;
int index = 0;
u8 cfr[2];
internal-status = NOTIMING;
+ internal-direction = 1;
- /* timing loop computation symbol rate optimisation */
- derot_limit = (internal-sub_range / 2L) / internal-mclk;
- derot_step = (params-srate / 2L) / internal-mclk;
+ while ((stb0899_check_tmg(state) != TIMINGOK) (abs(derot_freq) =
derot_max)) {
+ derot_freq += index * (index - 1) * internal-direction;
/* next derot zig zag position */
- while ((stb0899_check_tmg(state) != TIMINGOK) next_loop) {
- index++;
- derot_freq += index * internal-direction * derot_step; /* next
derot zig zag position */
+ STB0899_SETFIELD_VAL(CFRM, cfr[0], MSB(state-config-inversion
* derot_freq));
+ STB0899_SETFIELD_VAL(CFRL, cfr[1], LSB(state-config-inversion
* derot_freq));
+ stb0899_write_regs(state, STB0899_CFRM, cfr, 2); /* derotator
frequency */
- if (abs(derot_freq) derot_limit)
- next_loop--;
-
- if (next_loop) {
- STB0899_SETFIELD_VAL(CFRM, cfr[0],
MSB(state-config-inversion * derot_freq));
- STB0899_SETFIELD_VAL(CFRL, cfr[1],
LSB(state-config-inversion * derot_freq));
- stb0899_write_regs(state, STB0899_CFRM, cfr, 2); /*
derotator frequency */
- }
internal-direction = -internal-direction; /* Change
zigzag direction */
+ index++;
}
if (internal-status == TIMINGOK) {
@@ -277,50 +276,41 @@ static enum stb0899_status stb0899_check_carrier(struct
stb0899_state *state)
static enum stb0899_status stb0899_search_carrier(struct stb0899_state *state)
{
struct stb0899_internal *internal = state-internal;
-
- short int derot_freq = 0, last_derot_freq = 0, derot_limit, next_loop =
3;
+ int derot_freq;
int index = 0;
u8 cfr[2];
u8 reg;
internal-status = NOCARRIER;
- derot_limit = (internal-sub_range / 2L) / internal-mclk;
+ internal-direction = 1;
derot_freq = internal-derot_freq;
reg = stb0899_read_reg(state, STB0899_CFD);
STB0899_SETFIELD_VAL(CFD_ON, reg, 1);
stb0899_write_reg(state, STB0899_CFD, reg);
- do {
+ while ((stb0899_check_carrier(state) == NOCARRIER) (abs(derot_freq)
= derot_max)) {
+
+ derot_freq += index * (index - 1) * internal-direction;
/* next derot zig zag position */
+
dprintk(state-verbose, FE_DEBUG, 1, Derot Freq=%d, mclk=%d,
derot_freq, internal-mclk);
- if (stb0899_check_carrier(state) == NOCARRIER) {
- index++;
- last_derot_freq = derot_freq;
- derot_freq += index * internal-direction *
internal-derot_step; /* next zig zag derotator
position */
-
- if(abs(derot_freq) derot_limit)
- next_loop--;
-
- if (next_loop) {
- reg = stb0899_read_reg(state, STB0899_CFD);
- STB0899_SETFIELD_VAL(CFD_ON, reg, 1);
-
Re: [GIT PATCH FOR 2.6.40] uvcvideo patches
Hi Mauro and Laurent, On Tue, May 24, 2011 at 11:13:01AM -0300, Mauro Carvalho Chehab wrote: Em 23-05-2011 19:27, Laurent Pinchart escreveu: Hi Mauro, On Friday 20 May 2011 23:01:18 Mauro Carvalho Chehab wrote: [clip] I prefer to ask the vendor about the XU controls that he needs and add a proper interface for them. And I would rather having Nvidia documenting their hardware, but that's not the world we live in :-) Some XU controls are variable-size binary chunks of data. We can't expose that as V4L2 controls, which is why I expose them using a documented UVC API. The V4L2 API allows string controls. String controls are zero terminated, aren't they? XU controls may contain zeros in them; Laurent, please correct me if I'm wrong. [clip] The only Evil Manufacturer(tm) I know of that really uses XUs is Logitech. They've been quite supportive so far, and have documented at least part of their XU controls. If they're quite supportive, they are not an Evil Manufacturer. We can ask them to document the XU controls they need and add a proper documented support for them. They won't document everything. LED control is documented. Pan/tilt is documented. Firmware update isn't. Firmware update can even require a crypto handshake with the device. That's understandable, as they want to avoid people breaking their devices and sending them back to tech support. A Firmware update should require root access. Normal users/applications should not be allowed to touch at the firmware without root access, as otherwise some application may damage a device or put some weird stuff there. The XU controls (or whatever interface) for firmware upgrade should require CAP_SYS_ADMIN. I agree that the vendor should not be required to open the firmware upgrade protocol, but it can document what XU controls will be used for that, in order for the driver to require the proper security capability bits. That's true; if the ioctl has a capability to e.g. render the device unusable then requiring CAP_SYS_ADMIN is a good idea. [clip] Why something else ? The XU interface has been designed by the USB-IF to be a kernelspace to userspace API. That's how Microsoft, and I think Apple, implemented it (it might not be a reference though). In the latter case, the developer that did the reverse engineering can just send us a patch adding the new V4L control/firmware upgrade logic/whatever to us. UVC is a class specification. I don't want to cripple the driver with tons of device-specific code. We already have Apple iSight- and Logitech-specific code and way too many quirks for my taste. Unfortunately, by being a generic driver for an USB class, and with vendors not quite following the specs, there's no way to avoid having device-specific stuff there. Other similar drivers like snd-usb-audio and sound hda driver has lots of quirks. In particular, the hda driver contains more lines to the patch-*.c drivers (with the device-specific stuff) than the driver core: $ wc -l sound/pci/hda/*.c 267 sound/pci/hda/hda_beep.c 5072 sound/pci/hda/hda_codec.c 637 sound/pci/hda/hda_eld.c 1084 sound/pci/hda/hda_generic.c 818 sound/pci/hda/hda_hwdep.c 2854 sound/pci/hda/hda_intel.c 727 sound/pci/hda/hda_proc.c 4988 sound/pci/hda/patch_analog.c 572 sound/pci/hda/patch_ca0110.c 1314 sound/pci/hda/patch_cirrus.c 776 sound/pci/hda/patch_cmedia.c 3905 sound/pci/hda/patch_conexant.c 1749 sound/pci/hda/patch_hdmi.c 20167 sound/pci/hda/patch_realtek.c 335 sound/pci/hda/patch_si3054.c 6434 sound/pci/hda/patch_sigmatel.c 6107 sound/pci/hda/patch_via.c 57806 total Yeah, device-specific stuff sucks, but sometimes there's no way to properly support a device. Luckily there are proper ways to support UVC XUs, by exposing them to userspace :-) This is not the proper way. If you get a Realtek audio device (the biggest one from the list above), it will just works, as kernelspace will abstract the hardware for you. However, if you move patch_realtek to userspace, the driver would not work without a Realtek specific stuff in userspace, that could eventually be closed source. We should never allow such things, otherwise we'll be distrying the open source ecosystem. I fully agree with this: the driver definitely needs to provide a high level interface on V4L2 node when reasonably possible. I think it would make sense to provide XU controls that could be used for firmware update and require SYS_CAP_ADMIN. Then regular applications couldn't access the XU interface, be it firmware update or something else. For what it's worth, the Linux kernel supports register level access to I2C devices from user space --- see Documentation/i2c/dev-interface. Thia interface is used seldom (as far as I know) due to obvious advantages of higher level interfaces. I
RE: [PATCH] DVB-APPS : correct some issues in libdvben50221
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Sébastien RAILLARD (COEXSI)
Sent: jeudi 3 mars 2011 17:52
To: Linux Media Mailing List
Subject: [PATCH] DVB-APPS : correct some issues in libdvben50221
Dear all,
Here are two patches against the latest version of libdvben50221 in the
hg repository.
Details of corrections:
---
* In en50221_sl_handle_close_session_response, the expected data
length wasn't good, the close_session_response object is 3 bytes long,
not 4 bytes long (see the specification)
* The LLCI_RESPONSE_TIMEOUT_MS has been increased from 1000ms to
1ms in order to wait for long/complex MMI operations. The timeout
work at TPDU 2nd level and not at LPDU 1st level of communication stack.
* In en50221_stdcam_llci_destroy, all data from the CA device are read
before closing the device. This prevent from keeping the last poll reply
in the dvb_core module ringbuffer. The polling function used to keep
contact with the CAM is first reading data then writing data, so there
is always a reply left in the buffer.
* In llci_lookup_callback, some tests permitting resource usage limit
are disabled as they are not working correctly. When a new session is
created, it is declared. But when a session is closed, this isn't
declared so a new session can't be opened a second time.
* In llci_session_callback, a test was removed as it was duplicated.
* In en50221_stdcam_llci_poll and llci_datetime_enquiry_callback, if
the function en50221_stdcam_llci_dvbtime isn't called regularly, a
wrong date/time is send to the CAM. So, if the time wasn't supplied, we
send the UTC time from the system. Also, the time_offset parameter of
the called function en50221_app_datetime_send has been set to -1 as we
don't have the local_offset information and as this information is
optional (see the specification).
Best regards,
Sebastien RAILLARD.
This is a patch re-submission with the correct format in order to get catch
in patchwork:
Signed-off-by: Sebastien RAILLARD s...@coexsi.fr
diff -r 1f246cbf8104 -r abf3b2af3520 lib/libdvben50221/en50221_session.c
--- a/lib/libdvben50221/en50221_session.c Mon Jan 31 14:47:32 2011
+0100
+++ b/lib/libdvben50221/en50221_session.c Tue May 24 23:28:53 2011
+0200
@@ -715,13 +715,13 @@
uint8_t connection_id)
{
// check
- if (data_length 5) {
+ if (data_length 4) {
print(LOG_LEVEL, ERROR, 1,
Received data with invalid length from module on slot
%02x\n,
slot_id);
return;
}
- if (data[0] != 4) {
+ if (data[0] != 3) {
print(LOG_LEVEL, ERROR, 1,
Received data with invalid length from module on slot
%02x\n,
slot_id);
diff -r 1f246cbf8104 -r abf3b2af3520 lib/libdvben50221/en50221_stdcam_llci.c
--- a/lib/libdvben50221/en50221_stdcam_llci.c Mon Jan 31 14:47:32 2011
+0100
+++ b/lib/libdvben50221/en50221_stdcam_llci.c Tue May 24 23:28:53 2011
+0200
@@ -32,7 +32,7 @@
#include en50221_app_tags.h
#include en50221_stdcam.h
-#define LLCI_RESPONSE_TIMEOUT_MS 1000
+#define LLCI_RESPONSE_TIMEOUT_MS 10*1000
#define LLCI_POLL_DELAY_MS 100
/* resource IDs we support */
@@ -207,7 +207,16 @@
en50221_app_mmi_destroy(llci-stdcam.mmi_resource);
if (closefd)
+ {
+ // Read the buffer before closing the device to remove the
last polling answer
+ uint8_t r_slot_id;
+ uint8_t connection_id;
+ uint8_t data[4096];
+ dvbca_link_read(llci-cafd, r_slot_id,
+ connection_id,
+ data, sizeof(data));
close(llci-cafd);
+ }
free(llci);
}
@@ -243,9 +252,14 @@
if (llci-datetime_session_number != -1) {
time_t cur_time = time(NULL);
if (llci-datetime_response_interval (cur_time
llci-datetime_next_send)) {
- en50221_app_datetime_send(llci-datetime_resource,
-
llci-datetime_session_number,
- llci-datetime_dvbtime, 0);
+ if (llci-datetime_dvbtime0)
+
en50221_app_datetime_send(llci-datetime_resource,
+
llci-datetime_session_number,
+
llci-datetime_dvbtime, -1);
+ else
+
en50221_app_datetime_send(llci-datetime_resource,
+
llci-datetime_session_number,
+ time(NULL), -1);
llci-datetime_next_send = cur_time +
llci-datetime_response_interval;
}
}
@@ -334,12 +348,14 @@
return -3;
break;
case EN50221_APP_CA_RESOURCEID:
-
[PATCH 2/3] [media] ov9740: Correct print in ov9740_reg_rmw()
From: Andrew Chew ac...@nvidia.com
The register width of the ov9740 is 16-bits, so correct the debug print
to reflect this.
Signed-off-by: Andrew Chew ac...@nvidia.com
---
drivers/media/video/ov9740.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/ov9740.c b/drivers/media/video/ov9740.c
index 96811e4..d5c9061 100644
--- a/drivers/media/video/ov9740.c
+++ b/drivers/media/video/ov9740.c
@@ -537,7 +537,8 @@ static int ov9740_reg_rmw(struct i2c_client *client, u16
reg, u8 set, u8 unset)
ret = ov9740_reg_read(client, reg, val);
if (ret 0) {
dev_err(client-dev,
- [Read]-Modify-Write of register %02x failed!\n, reg);
+ [Read]-Modify-Write of register 0x%04x failed!\n,
+ reg);
return ret;
}
@@ -547,7 +548,8 @@ static int ov9740_reg_rmw(struct i2c_client *client, u16
reg, u8 set, u8 unset)
ret = ov9740_reg_write(client, reg, val);
if (ret 0) {
dev_err(client-dev,
- Read-Modify-[Write] of register %02x failed!\n, reg);
+ Read-Modify-[Write] of register 0x%04x failed!\n,
+ reg);
return ret;
}
--
1.7.5.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] [media] ov9740: Cleanup hex casing inconsistencies
From: Andrew Chew ac...@nvidia.com Made all hex number casing use lower-case throughout the entire driver for consistency. Signed-off-by: Andrew Chew ac...@nvidia.com --- drivers/media/video/ov9740.c | 111 +- 1 files changed, 55 insertions(+), 56 deletions(-) diff --git a/drivers/media/video/ov9740.c b/drivers/media/video/ov9740.c index 4d4ee4f..96811e4 100644 --- a/drivers/media/video/ov9740.c +++ b/drivers/media/video/ov9740.c @@ -44,12 +44,12 @@ #define OV9740_Y_ADDR_START_LO 0x0347 #define OV9740_X_ADDR_END_HI 0x0348 #define OV9740_X_ADDR_END_LO 0x0349 -#define OV9740_Y_ADDR_END_HI 0x034A -#define OV9740_Y_ADDR_END_LO 0x034B -#define OV9740_X_OUTPUT_SIZE_HI0x034C -#define OV9740_X_OUTPUT_SIZE_LO0x034D -#define OV9740_Y_OUTPUT_SIZE_HI0x034E -#define OV9740_Y_OUTPUT_SIZE_LO0x034F +#define OV9740_Y_ADDR_END_HI 0x034a +#define OV9740_Y_ADDR_END_LO 0x034b +#define OV9740_X_OUTPUT_SIZE_HI0x034c +#define OV9740_X_OUTPUT_SIZE_LO0x034d +#define OV9740_Y_OUTPUT_SIZE_HI0x034e +#define OV9740_Y_OUTPUT_SIZE_LO0x034f /* IO Control Registers */ #define OV9740_IO_CREL00 0x3002 @@ -89,28 +89,28 @@ #define OV9740_TIMING_CTRL35 0x3835 /* Banding Filter */ -#define OV9740_AEC_MAXEXPO_60_H0x3A02 -#define OV9740_AEC_MAXEXPO_60_L0x3A03 -#define OV9740_AEC_B50_STEP_HI 0x3A08 -#define OV9740_AEC_B50_STEP_LO 0x3A09 -#define OV9740_AEC_B60_STEP_HI 0x3A0A -#define OV9740_AEC_B60_STEP_LO 0x3A0B -#define OV9740_AEC_CTRL0D 0x3A0D -#define OV9740_AEC_CTRL0E 0x3A0E -#define OV9740_AEC_MAXEXPO_50_H0x3A14 -#define OV9740_AEC_MAXEXPO_50_L0x3A15 +#define OV9740_AEC_MAXEXPO_60_H0x3a02 +#define OV9740_AEC_MAXEXPO_60_L0x3a03 +#define OV9740_AEC_B50_STEP_HI 0x3a08 +#define OV9740_AEC_B50_STEP_LO 0x3a09 +#define OV9740_AEC_B60_STEP_HI 0x3a0a +#define OV9740_AEC_B60_STEP_LO 0x3a0b +#define OV9740_AEC_CTRL0D 0x3a0d +#define OV9740_AEC_CTRL0E 0x3a0e +#define OV9740_AEC_MAXEXPO_50_H0x3a14 +#define OV9740_AEC_MAXEXPO_50_L0x3a15 /* AEC/AGC Control */ #define OV9740_AEC_ENABLE 0x3503 -#define OV9740_GAIN_CEILING_01 0x3A18 -#define OV9740_GAIN_CEILING_02 0x3A19 -#define OV9740_AEC_HI_THRESHOLD0x3A11 -#define OV9740_AEC_3A1A0x3A1A -#define OV9740_AEC_CTRL1B_WPT2 0x3A1B -#define OV9740_AEC_CTRL0F_WPT 0x3A0F -#define OV9740_AEC_CTRL10_BPT 0x3A10 -#define OV9740_AEC_CTRL1E_BPT2 0x3A1E -#define OV9740_AEC_LO_THRESHOLD0x3A1F +#define OV9740_GAIN_CEILING_01 0x3a18 +#define OV9740_GAIN_CEILING_02 0x3a19 +#define OV9740_AEC_HI_THRESHOLD0x3a11 +#define OV9740_AEC_3A1A0x3a1a +#define OV9740_AEC_CTRL1B_WPT2 0x3a1b +#define OV9740_AEC_CTRL0F_WPT 0x3a0f +#define OV9740_AEC_CTRL10_BPT 0x3a10 +#define OV9740_AEC_CTRL1E_BPT2 0x3a1e +#define OV9740_AEC_LO_THRESHOLD0x3a1f /* BLC Control */ #define OV9740_BLC_AUTO_ENABLE 0x4002 @@ -132,7 +132,7 @@ #define OV9740_VT_SYS_CLK_DIV 0x0303 #define OV9740_VT_PIX_CLK_DIV 0x0301 #define OV9740_PLL_CTRL30100x3010 -#define OV9740_VFIFO_CTRL000x460E +#define OV9740_VFIFO_CTRL000x460e /* ISP Control */ #define OV9740_ISP_CTRL00 0x5000 @@ -141,9 +141,9 @@ #define OV9740_ISP_CTRL05 0x5005 #define OV9740_ISP_CTRL12 0x5012 #define OV9740_ISP_CTRL19 0x5019 -#define OV9740_ISP_CTRL1A 0x501A -#define OV9740_ISP_CTRL1E 0x501E -#define OV9740_ISP_CTRL1F 0x501F +#define OV9740_ISP_CTRL1A 0x501a +#define OV9740_ISP_CTRL1E 0x501e +#define OV9740_ISP_CTRL1F 0x501f #define OV9740_ISP_CTRL20 0x5020 #define OV9740_ISP_CTRL21 0x5021 @@ -158,12 +158,12 @@ #define OV9740_AWB_ADV_CTRL04 0x5187 #define OV9740_AWB_ADV_CTRL05 0x5188 #define OV9740_AWB_ADV_CTRL06 0x5189 -#define OV9740_AWB_ADV_CTRL07 0x518A -#define OV9740_AWB_ADV_CTRL08 0x518B -#define OV9740_AWB_ADV_CTRL09 0x518C -#define OV9740_AWB_ADV_CTRL10 0x518D -#define OV9740_AWB_ADV_CTRL11 0x518E -#define OV9740_AWB_CTRL0F 0x518F +#define OV9740_AWB_ADV_CTRL07 0x518a +#define OV9740_AWB_ADV_CTRL08 0x518b +#define OV9740_AWB_ADV_CTRL09 0x518c +#define OV9740_AWB_ADV_CTRL10 0x518d +#define
[PATCH 3/3] [media] ov9740: Fixed some settings
From: Andrew Chew ac...@nvidia.com
Based on vendor feedback, should issue a software reset at start of day.
Also, OV9740_ANALOG_CTRL15 needs to be changed so the sensor does not begin
streaming until it is ready (otherwise, results in a nonsense frame for the
initial frame).
For discontinuous clocks, need to change OV9740_MIPI_CTRL00.
Finally, OV9740_ISP_CTRL19 needs to be changed to really use YUYV ordering
(the previous value was for VYUY).
Signed-off-by: Andrew Chew ac...@nvidia.com
---
drivers/media/video/ov9740.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
Submitted three patches with the super basic things. Suspend/resume, and
supporting the different resolutions programmatically, coming soon.
diff --git a/drivers/media/video/ov9740.c b/drivers/media/video/ov9740.c
index d5c9061..9d7c74d 100644
--- a/drivers/media/video/ov9740.c
+++ b/drivers/media/video/ov9740.c
@@ -68,6 +68,7 @@
#define OV9740_ANALOG_CTRL04 0x3604
#define OV9740_ANALOG_CTRL10 0x3610
#define OV9740_ANALOG_CTRL12 0x3612
+#define OV9740_ANALOG_CTRL15 0x3615
#define OV9740_ANALOG_CTRL20 0x3620
#define OV9740_ANALOG_CTRL21 0x3621
#define OV9740_ANALOG_CTRL22 0x3622
@@ -222,6 +223,9 @@ struct ov9740_priv {
};
static const struct ov9740_reg ov9740_defaults[] = {
+ /* Software Reset */
+ { OV9740_SOFTWARE_RESET,0x01 },
+
/* Banding Filter */
{ OV9740_AEC_B50_STEP_HI, 0x00 },
{ OV9740_AEC_B50_STEP_LO, 0xe8 },
@@ -333,6 +337,7 @@ static const struct ov9740_reg ov9740_defaults[] = {
{ OV9740_ANALOG_CTRL10, 0xa1 },
{ OV9740_ANALOG_CTRL12, 0x24 },
{ OV9740_ANALOG_CTRL22, 0x9f },
+ { OV9740_ANALOG_CTRL15, 0xf0 },
/* Sensor Control */
{ OV9740_SENSOR_CTRL03, 0x42 },
@@ -385,7 +390,7 @@ static const struct ov9740_reg ov9740_defaults[] = {
{ OV9740_LN_LENGTH_PCK_LO, 0x62 },
/* MIPI Control */
- { OV9740_MIPI_CTRL00, 0x44 },
+ { OV9740_MIPI_CTRL00, 0x64 }, /* 0x44 for continuous clock */
{ OV9740_MIPI_3837, 0x01 },
{ OV9740_MIPI_CTRL01, 0x0f },
{ OV9740_MIPI_CTRL03, 0x05 },
@@ -393,6 +398,9 @@ static const struct ov9740_reg ov9740_defaults[] = {
{ OV9740_VFIFO_RD_CTRL, 0x16 },
{ OV9740_MIPI_CTRL_3012,0x70 },
{ OV9740_SC_CMMM_MIPI_CTR, 0x01 },
+
+ /* YUYV order */
+ { OV9740_ISP_CTRL19,0x02 },
};
static const struct ov9740_reg ov9740_regs_vga[] = {
--
1.7.5.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: STV090x FE_READ_STATUS implementation
On Tue, 24 May 2011 21:05:33 +0200 Sébastien RAILLARD (COEXSI) s...@coexsi.fr wrote: In my case, the STV0903 is reporting the five following states : SCVYL. Indeed, after some more troubleshooting, I found out that the problem is not in the STV6110 but in the STV090X code. The card I'm using is a TT S2-1600. The function stv090x_read_status() only reports the status when locked. I couldn't find the datasheet either for this one. Manu is the maintainer as well. Maybe he has more input on this. Strange, as it must be the same demodulator and code as for the CineS2! I think there is some missunderstanding about the issue I'm facing. When I have a lock, it does report all the SCVYL bits. The problem occurs when there is no lock. For instance if you try to tune to a transponder with an invalid symbol rate, you should get SIGNAL and CARRIER but no SYNC. Provided the demod would report that correctly, that'd allow me to try other possible symbol rate and only do so when the demod detects a carrier wave. Since I'm probing a lot of frequencies, trying ~10 possible symbol rates when there isn't a signal slows down the process a lot. Not easy to get the datasheets from ST, they have never replied to my enquiries... -- 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 1/2] MT9P031: Add support for Aptina mt9p031 sensor.
Hi, Have upgraded the driver to Javier's latest RFC driver. Still having problems viewing output. Setting up with: # media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Resetting all links to inactive Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] # media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], OMAP3 ISP CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]' Setting up format SGRBG12 320x240 on pad mt9p031 2-0048/0 Format set: SGRB Setting up format SGRBG12 320x240 on pad OMAP3 ISP CCDC/0 Format set: SGRBG12 320x240 Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/0 Format set: SGRBG8 320x240 Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/1 Format set: SGRBG8 320x240 Then: # yavta -f SGRBG8 -s 320x240 -n 4 --capture=100 -F /dev/video2 Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: width: 320 height: 240 buffer size: 76800 Video format: GRBG (47425247) 320x240 4 buffers requested. length: 76800 offset: 0 Buffer 0 mapped at address 0x4006c000. length: 76800 offset: 77824 Buffer 1 mapped at address 0x40222000. length: 76800 offset: 155648 Buffer 2 mapped at address 0x4025e000. length: 76800 offset: 233472 Buffer 3 mapped at address 0x402f. After this it hangs and will exit on 'ctrl c': omap3isp omap3isp: CCDC stop timeout! Any ideas what is causing this problem? This may be useful also: # media-ctl -p Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Device topology - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev0 pad0: Input [SGRBG10 4096x4096] - 'OMAP3 ISP CCP2 input':pad0 [] pad1: Output [SGRBG10 4096x4096] - 'OMAP3 ISP CCDC':pad0 [] - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Output - 'OMAP3 ISP CCP2':pad0 [] - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Input [SGRBG10 4096x4096] pad1: Output [SGRBG10 4096x4096] - 'OMAP3 ISP CSI2a output':pad0 [] - 'OMAP3 ISP CCDC':pad0 [] - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Input - 'OMAP3 ISP CSI2a':pad1 [] - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [SGRBG8 320x240] - 'OMAP3 ISP CCP2':pad1 [] - 'OMAP3 ISP CSI2a':pad1 [] - 'mt9p031 2-0048':pad0 [ACTIVE] pad1: Output [SGRBG8 320x240] - 'OMAP3 ISP CCDC output':pad0 [ACTIVE] - 'OMAP3 ISP resizer':pad0 [] pad2: Output [SGRBG8 320x239] - 'OMAP3 ISP preview':pad0 [] - 'OMAP3 ISP AEWB':pad0 [IMMUTABLE,ACTIVE] - 'OMAP3 ISP AF':pad0 [IMMUTABLE,ACTIVE] - 'OMAP3 ISP histogram':pad0 [IMMUTABLE,ACTIVE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L device node name /dev/video2 pad0: Input - 'OMAP3 ISP CCDC':pad1 [ACTIVE] - entity 7: OMAP3 ISP preview (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev3 pad0: Input [SGRBG10 4096x4096] - 'OMAP3 ISP CCDC':pad2 [] - 'OMAP3 ISP preview input':pad0 [] pad1: Output [YUYV 2034x4088] - 'OMAP3 ISP preview output':pad0 [] - 'OMAP3 ISP resizer':pad0 [] - entity 8: OMAP3 ISP preview input (1 pad, 1 link) type Node subtype V4L device node name /dev/video3 pad0: Output - 'OMAP3 ISP preview':pad0 [] - entity 9: OMAP3 ISP preview output (1 pad, 1 link) type Node subtype V4L device node name /dev/video4 pad0: Input - 'OMAP3 ISP preview':pad1 [] - entity 10: OMAP3 ISP resizer (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev4 pad0: Input [YUYV 4095x4095 (0,6)/4094x4082] - 'OMAP3 ISP CCDC':pad1 [] - 'OMAP3 ISP preview':pad1 [] - 'OMAP3 ISP resizer input':pad0 [] pad1: Output [YUYV 3312x4095] - 'OMAP3 ISP resizer output':pad0 [] - entity 11: OMAP3 ISP resizer input (1 pad, 1 link) type Node subtype V4L device node name /dev/video5 pad0: Output - 'OMAP3 ISP resizer':pad0 [] - entity 12: OMAP3 ISP resizer output (1 pad, 1
Re: [PATCH] xc5000, fix fw upload crash
On Fri, 20 May 2011 19:22:29 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em 20-05-2011 10:04, Devin Heitmueller escreveu: On Friday, May 20, 2011, Dmitri Belimov d.beli...@gmail.com wrote: Hi Devin snip NACK! I don't think this patch is correct. Concurrency problems are expected to be handled in the upper layers, as there are usually much more significant problems than just this case. For example, if this is a race between V4L2 and DVB, it is the responsibility of bridge driver to provide proper locking. ... I see two different way add mutex to function where firmware is loaded or to xc5000_set_analog_params Both of this is working I already test it. What you think about it?? ... [ 110.010686] [f81cb6d8] ? set_mode_freq+0xe4/0xff [tuner] [ 110.010689] [f81cb8d4] ? tuner_s_std+0x26/0x5aa [tuner] [ 110.010692] [f81cb8ae] ? tuner_s_std+0x0/0x5aa [tuner] Hmm... this is probably caused by the BKL removal patches. Basically, tuner_s_std is being called without holding dev-lock. The fix is simple, but requires some care: we need either to convert saa7134 to the v4l2 core support (probably not an easy task) or to review all places where dev-lock should be used, e. g. at (almost all) ioctls, and at the other file ops (open, close, mmap, etc). This driver is complex, due to the mpeg optional module used on some devices. So, maybe the in-core locking schema is not the proper way to fix it. Cheers, Mauro. Right now we can add mutex to xc5000 for solve crash problem and add FIXME string for remove it later and TODO for main core. What you think? With my best regards, Dmitry. -- 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
