Re: [patch] Fix AF9015 Dual tuner i2c write failures
Switching channels for long time seems to hang device (no errors seen but it does not lock anymore), I don't know why. It is not very easy to reproduce. For me it will take generally few days just tune from channel to channel in loop. Antti On 03/05/2011 10:56 AM, Juan Jesús García de Soria Lucena wrote: Hi, Andrew. This is what happens to me with both the KWorld dual tuner (when using only one tuner) and the Avermedia Volar Black (single tuner), both based on AF9015. I also got corrupted streams with the KWorld when capturing via both tuners (the video our the audio would show artifacts in mythtv each several seconds). As far as the loss of tuning ability goes, I think it's a problem related to tuning itself, since it wouldn't happen when you just left a channel tuned and streaming in a simple client, but would trigger after a random time when you left mythtv scanning the channels for EIT data. I don't think it's a problem with a specific HW implementation, since I got it with both AF9015-based cards. It could be either a chipset quirk our a bug in the driver. My informal and quick tests with Windows Media Center and these cards did not reproduce the problem, when trying to change channels as quickly as possible, admittedly for not so long a time. Best regards, Juan Jesus. El 05/03/2011 02:53, adqa...@lidskialf.net escribió: On 5 March 2011 01:43, adqa...@lidskialf.net wrote: On 4 March 2011 23:11, Andrew de Quinceyadq_...@lidskialf.net wrote: On 4 March 2011 22:59, Antti Palosaaricr...@iki.fi wrote: On 03/05/2011 12:44 AM, Andrew de Quincey wrote: Adding a bus lock to af9015_i2c_xfer() will not work as demod/tuner accesses will take multiple i2c transactions. Therefore, the following patch overrides the dvb_frontend_ops functions to add a per-device lock around them: only one frontend can now use the i2c bus at a time. Testing with the scripts above shows this has eliminated the errors. This have annoyed me too, but since it does not broken functionality much I haven't put much effort for fixing it. I like that fix since it is in AF9015 driver where it logically belongs to. But it looks still rather complex. I see you have also considered bus lock to af9015_i2c_xfer() which could be much smaller in code size (that's I have tried to implement long time back). I would like to ask if it possible to check I2C gate open / close inside af9015_i2c_xfer() and lock according that? Something like: Hmm, I did think about that, but I felt overriding the functions was just cleaner: I felt it was more obvious what it was doing. Doing exactly this sort of tweaking was one of the main reasons we added that function overriding feature. I don't like the idea of returning error locked by FE since that'll mean the tuning will randomly fail sometimes in a way visible to userspace (unless we change the core dvb_frontend code), which was one of the things I was trying to avoid. Unless, of course, I've misunderstood your proposal. Not returning error, but waiting in lock like that: if (mutex_lock_interruptible(d-i2c_mutex) 0) return -EAGAIN; Ah k, sorry However, looking at the code again, I realise it is possible to simplify it. Since its only the demod gates that cause a problem, we only /actually/ need to lock the get_frontend() and set_frontend() calls. I don't understand why .get_frontend() causes problem, since it does not access tuner at all. It only reads demod registers. The main problem is (like schema in af9015.c shows) that there is two tuners on same I2C bus using same address. And demod gate is only way to open access for desired tuner only. AFAIR /some/ tuner code accesses the tuner hardware to read the exact tuned frequency back on a get_frontend(); was just being extra paranoid :) You should block traffic based of tuner not demod. And I think those callbacks which are needed for override are tuner driver callbacks. Consider situation device goes it v4l-core calls same time both tuner .sleep() == problem. Hmm, yeah, you're right, let me have another look tomorrow. Hi, must admit I misunderstood your diagram originally, I thought it was the demods AND the tuners that had the same i2c addresses. As you say though. its just the tuners, so adding the locking into the gate ctrl as you suggested makes perfect sense. Attached is v3 implementing this; it seems to be working fine here. Unfortunately even with this fix, I'm still seeing the problem I was trying to fix to begin with. Although I no longer get any i2c errors (or *any* reported errors), after a bit, one of the frontends just.. stops working. All attempts to tune it fail. I can even unload and reload the driver module, and its stuck in the same state, indicating its a problem with the hardware. :( -- 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: [patch] Fix AF9015 Dual tuner i2c write failures
On 03/05/2011 03:51 AM, adq wrote: As you say though. its just the tuners, so adding the locking into the gate ctrl as you suggested makes perfect sense. Attached is v3 implementing this; it seems to be working fine here. Unfortunately even with this fix, I'm still seeing the problem I was trying to fix to begin with. Although I no longer get any i2c errors (or *any* reported errors), after a bit, one of the frontends just.. stops working. All attempts to tune it fail. I can even unload and reload the driver module, and its stuck in the same state, indicating its a problem with the hardware. :( How easily you can re-produce this? Does it work using your first patch? Could try some changes for GPIOs, LEDs are not important but tuner GPIOs? Here is instructions how GPIOs should be done: FE0 START FE0 READ EEPROM FE0 GPIO RESET and ENABLE FE1? // set_gpio(0, 3); // msleep(40) // set_gpio(0, 7); FE0 DOWNLOAD FW FE0 enable POWER LED ??? // wr_reg(0xd734, upper nibble 3) FE1 set power management (0xd731) FE0 tuner OFF // set_gpio(3, 7); FE0 LOCK LED OFF FE1 tuner OFF // set_gpio(0, 7); FE1 LOCK LED OFF *** DEVICE is NOW IN SLEEP *** *** TUNE REQ for FE1 ** FE1 tuner ON // set_gpio(0, b); FE1 LOCK LED ON *** now streaming ** FE1 tuner OFF // set_gpio(0, 7); FE1 LOCK LED OFF *** DEVICE is NOW IN SLEEP *** *** TUNE REQ for FE0 ** FE0 tuner ON // set_gpio(3, b); FE0 LOCK LED ON *** now streaming ** FE0 tuner OFF // set_gpio(3, 7); FE0 LOCK LED OFF *** DEVICE is NOW IN SLEEP *** Also configure some power management for FE1, write register 0xd731 value 0x47. Do that in af9013_init() before OFSM init (since it changes some bits in same register). And this is list of used GPIOs, it is my latest understanding. I have ensured many of those by just testing. AF9015 GPIO0 AF9013 reset AF9015 GPIO1 NC (note: on MC44S803 device tuner reset) AF9015 GPIO2 NC AF9015 GPIO3 TUNER AF9015 GPIO_LOCK1 LOCK LED AF9015 GPIO_LOCK2 POWER LED (not sure, I don't have any device having power LED, but it looks like it could be) AF9013 GPIO0 TUNER AF9013 GPIO1 NC AF9013 GPIO2 LOCK LED AF9013 GPIO3 HW power down? AF9013 GPIO_LOCK1 LOCK LED AF9013 GPIO_LOCK2 NC -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] Fix AF9015 Dual tuner i2c write failures
On 03/05/2011 03:43 AM, adq wrote:
+static int af9015_lock_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
+{
+ int result;
+ struct dvb_usb_adapter *adap = fe-dvb-priv;
+ struct af9015_state *state = adap-dev-priv;
+
+ if (enable)
+ if (mutex_lock_interruptible(adap-dev-usb_mutex))
+ return -EAGAIN;
+
+ result = state-i2c_gate_ctrl[adap-id](fe, enable);
+
+ if (!enable)
+ mutex_unlock(adap-dev-usb_mutex);
+
+ return result;
+}
I think this will cause problems in case of tuner driver calls more than
one time gate close or gate enable one after the other.
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/5] [media] s5p-tvout: Add S5P TVOUT driver
Hi! Sorry for not replying earlier. To be honest, there is not much I can say yet. The main new part in this driver is the HDMI/CEC support. And that is one of the topics of the upcoming Warsaw brainstorm meeting (several of your Samsung colleagues will be attending). An RFC for CEC support has been posted last week and hopefully we (Cisco Systems Norway) can get a HDMI RFC posted as well in time for the meeting. The main difference of our approach to HDMI is that we integrate it in V4L2 rather than creating new device nodes. Once the media controller is in we also have per-subdevice nodes in /dev which we want to utilize for the HDMI and CEC APIs. Functionality-wise the CEC RFC is effectively identical to your implementation. Regards, Hans On Friday, February 25, 2011 08:53:28 Abhilash Kesavan wrote: This patch-set adds support for TV-OUT interface in the EXYNOS4 series of SoCs. TVOUT includes the HDMI interface, analog TV interface, mixer and video processor. This is a full-featured driver providing the following: 1) HDMI Support 2) Analog Support 3) Mixer Support 4) Video Processor Support 5) Hotplug Detect Support 6) HDCP Support 7) CEC Support 8) I2S/SPDIF Support The driver is under development and needs major modifications, as mentioned later in the TODO section, to conform to open source standards. Please have a look at the driver design and offer any suggestions/comments. I) HARDWARE Video processor is responsible for video scaling, de-interlacing, and video post processing of TVOUT data path. It reads reconstructed YCbCr video sequences from DRAM, processes the sequence, and sends it to mixer on-the-fly. Input to VP is NV12 and NV21 (Linear and tiled) format while the output to the mixer is YUV444. Mixer overlaps or blends input data such as graphic, video, background and sends the resulting data to the HDMI or analog TV interface. Along with the YUV444 in- put from VP interface, the mixer can receive two RGB inputs. It allows for layer blending, alpha blending, chroma key, scaling etc. HDMI interface supports 1.3 Tx subsystem V1.0 comprising an HDMI Tx core with I2S input interface, CEC block, and HDCP key block. It receives YUV444 or RGB888 data from the mixer and converts it into HDMI packets. Supports a variety of video formats varying from 480p to 1080p. Analog TV interface supports ITU-R BT 470 and EIA-770 compliant analog TV signals with 1 channel 10bit DAC. Supports PAL-m@60Hz, PAL-60@60Hz, NTSC@60Hz, NTSC-443@60Hz, PAL@50Hz, PAL-n@50Hz and (M)NTSC@60Hz formats for composite output. II) S/W DESIGN === --- VFS --- KERNEL | | V V -- -- V4L2 STACK FB STACKLinux Driver Model -- -- | || =+===++ | || | | +-| | | | | V V V | +---+---+ | | | | | | | - --- | | | Video Ctrl -- Graphics Ctrl -- TVOUT I/F| | | - --- V | | | | ||__ --- | | | | | | HPD Driver | | V V V V(GPIO) | | --- --- --- --- --- | | VP I/F Mixer I/F Analog I/FHDMI I/F | | --- --- --- --- | | | | | | | | DEVICE| | | | | |___ | DRIVER| | | | | | | | | |
Re: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
On Friday, March 04, 2011 21:10:05 Mauro Carvalho Chehab wrote: Em 03-03-2011 07:25, Laurent Pinchart escreveu: Hi Mauro, The following changes since commit 88a763df226facb74fdb254563e30e9efb64275c: [media] dw2102: prof 1100 corrected (2011-03-02 16:56:54 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git media-2.6.39-0005-omap3isp The branch has been rebased on top of the latest for_v2.6.39 branch, with the v4l2-ioctl.c conflict resolved. Antti Koskipaa (1): v4l: v4l2_subdev userspace crop API David Cohen (1): omap3isp: Statistics Laurent Pinchart (36): v4l: Share code between video_usercopy and video_ioctl2 v4l: subdev: Don't require core operations v4l: subdev: Add device node support v4l: subdev: Uninline the v4l2_subdev_init function v4l: subdev: Control ioctls support media: Media device node support media: Media device media: Entities, pads and links media: Entity use count media: Media device information query media: Entities, pads and links enumeration media: Links setup media: Pipelines and media streams v4l: Add a media_device pointer to the v4l2_device structure v4l: Make video_device inherit from media_entity v4l: Make v4l2_subdev inherit from media_entity v4l: Move the media/v4l2-mediabus.h header to include/linux v4l: Replace enums with fixed-sized fields in public structure v4l: Rename V4L2_MBUS_FMT_GREY8_1X8 to V4L2_MBUS_FMT_Y8_1X8 v4l: Group media bus pixel codes by types and sort them alphabetically The presence of those mediabus names against the traditional fourcc codes at the API adds some mess to the media controller. Not sure how to solve, but maybe the best way is to add a table at the V4L2 API associating each media bus format to the corresponding V4L2 fourcc codes. You can't do that in general. Only for specific hardware platforms. If you could do it, then we would have never bothered creating these mediabus fourccs. How a mediabus fourcc translates to a pixelcode (== memory format) depends entirely on the hardware capabilities (mostly that of the DMA engine). A generic V4L2 application will never use mediabus fourcc codes. It's only used by drivers and applications written specifically for that hardware and using /dev/v4l-subdevX devices. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] Fix AF9015 Dual tuner i2c write failures
2011/3/5 Juan Jesús García de Soria Lucena skanda...@gmail.com: Hi, Andrew. This is what happens to me with both the KWorld dual tuner (when using only one tuner) and the Avermedia Volar Black (single tuner), both based on AF9015. I also got corrupted streams with the KWorld when capturing via both tuners (the video our the audio would show artifacts in mythtv each several seconds). As far as the loss of tuning ability goes, I think it's a problem related to tuning itself, since it wouldn't happen when you just left a channel tuned and streaming in a simple client, but would trigger after a random time when you left mythtv scanning the channels for EIT data. I don't think it's a problem with a specific HW implementation, since I got it with both AF9015-based cards. It could be either a chipset quirk our a bug in the driver. My informal and quick tests with Windows Media Center and these cards did not reproduce the problem, when trying to change channels as quickly as possible, admittedly for not so long a time. Correct. I have two af9015 cards from different manufacturers as well, and they both exhibit the same problem. However, on a hunch last night, I went back to my original (-v1) patch with the total i2c bus lock and left it running with my tuning scripts for 10 hours. Both tuners are still working fine. That isn't conclusive, but it is encouraging. I'm just swapping back to a completely unpatched state to see how long it takes to break and to check if its easily reproducible (on my live system, it usually does it within a few hours of normal usage). -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] Fix AF9015 Dual tuner i2c write failures
Perhaps it depends on the characteristics of the transmissions being received? I'm in the UK. 2011/3/5 Antti Palosaari cr...@iki.fi: Switching channels for long time seems to hang device (no errors seen but it does not lock anymore), I don't know why. It is not very easy to reproduce. For me it will take generally few days just tune from channel to channel in loop. Antti On 03/05/2011 10:56 AM, Juan Jesús García de Soria Lucena wrote: Hi, Andrew. This is what happens to me with both the KWorld dual tuner (when using only one tuner) and the Avermedia Volar Black (single tuner), both based on AF9015. I also got corrupted streams with the KWorld when capturing via both tuners (the video our the audio would show artifacts in mythtv each several seconds). As far as the loss of tuning ability goes, I think it's a problem related to tuning itself, since it wouldn't happen when you just left a channel tuned and streaming in a simple client, but would trigger after a random time when you left mythtv scanning the channels for EIT data. I don't think it's a problem with a specific HW implementation, since I got it with both AF9015-based cards. It could be either a chipset quirk our a bug in the driver. My informal and quick tests with Windows Media Center and these cards did not reproduce the problem, when trying to change channels as quickly as possible, admittedly for not so long a time. Best regards, Juan Jesus. El 05/03/2011 02:53, adqa...@lidskialf.net escribió: On 5 March 2011 01:43, adqa...@lidskialf.net wrote: On 4 March 2011 23:11, Andrew de Quinceyadq_...@lidskialf.net wrote: On 4 March 2011 22:59, Antti Palosaaricr...@iki.fi wrote: On 03/05/2011 12:44 AM, Andrew de Quincey wrote: Adding a bus lock to af9015_i2c_xfer() will not work as demod/tuner accesses will take multiple i2c transactions. Therefore, the following patch overrides the dvb_frontend_ops functions to add a per-device lock around them: only one frontend can now use the i2c bus at a time. Testing with the scripts above shows this has eliminated the errors. This have annoyed me too, but since it does not broken functionality much I haven't put much effort for fixing it. I like that fix since it is in AF9015 driver where it logically belongs to. But it looks still rather complex. I see you have also considered bus lock to af9015_i2c_xfer() which could be much smaller in code size (that's I have tried to implement long time back). I would like to ask if it possible to check I2C gate open / close inside af9015_i2c_xfer() and lock according that? Something like: Hmm, I did think about that, but I felt overriding the functions was just cleaner: I felt it was more obvious what it was doing. Doing exactly this sort of tweaking was one of the main reasons we added that function overriding feature. I don't like the idea of returning error locked by FE since that'll mean the tuning will randomly fail sometimes in a way visible to userspace (unless we change the core dvb_frontend code), which was one of the things I was trying to avoid. Unless, of course, I've misunderstood your proposal. Not returning error, but waiting in lock like that: if (mutex_lock_interruptible(d-i2c_mutex) 0) return -EAGAIN; Ah k, sorry However, looking at the code again, I realise it is possible to simplify it. Since its only the demod gates that cause a problem, we only /actually/ need to lock the get_frontend() and set_frontend() calls. I don't understand why .get_frontend() causes problem, since it does not access tuner at all. It only reads demod registers. The main problem is (like schema in af9015.c shows) that there is two tuners on same I2C bus using same address. And demod gate is only way to open access for desired tuner only. AFAIR /some/ tuner code accesses the tuner hardware to read the exact tuned frequency back on a get_frontend(); was just being extra paranoid :) You should block traffic based of tuner not demod. And I think those callbacks which are needed for override are tuner driver callbacks. Consider situation device goes it v4l-core calls same time both tuner .sleep() == problem. Hmm, yeah, you're right, let me have another look tomorrow. Hi, must admit I misunderstood your diagram originally, I thought it was the demods AND the tuners that had the same i2c addresses. As you say though. its just the tuners, so adding the locking into the gate ctrl as you suggested makes perfect sense. Attached is v3 implementing this; it seems to be working fine here. Unfortunately even with this fix, I'm still seeing the problem I was trying to fix to begin with. Although I no longer get any i2c errors (or *any* reported errors), after a bit, one of the frontends just.. stops working. All attempts to tune it fail. I can even unload and reload the driver module, and its stuck in the same state,
RE: [RFC/PATCH v7 1/5] Changes in include/linux/videodev2.h for MFC 5.1
Hi, I commented as below.
-Original Message-
From: Kamil Debski [mailto:k.deb...@samsung.com]
Sent: Saturday, March 05, 2011 3:57 AM
To: 'Laurent Pinchart'
Cc: linux-media@vger.kernel.org; linux-samsung-...@vger.kernel.org; Marek
Szyprowski; kyungmin.p...@samsung.com; jaeryul...@samsung.com;
kgene@samsung.com
Subject: RE: [RFC/PATCH v7 1/5] Changes in include/linux/videodev2.h for
MFC 5.1
Hi,
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: 04 March 2011 17:39
To: Kamil Debski
Cc: linux-media@vger.kernel.org; linux-samsung-...@vger.kernel.org;
m.szyprow...@samsung.com; kyungmin.p...@samsung.com;
jaeryul...@samsung.com; kgene@samsung.com
Subject: Re: [RFC/PATCH v7 1/5] Changes in include/linux/videodev2.h
for MFC 5.1
On Friday 04 March 2011 12:26:18 Kamil Debski wrote:
This patch adds fourcc values for compressed video stream formats and
V4L2_CTRL_CLASS_CODEC. Also adds controls used by MFC 5.1 driver.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/linux/videodev2.h | 39
+++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index a94c4d5..a48a42e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -369,6 +369,19 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_DV v4l2_fourcc('d', 'v', 's', 'd') /*
1394 */
#define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /*
MPEG-1/2/4 */
+#define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /*
H264 */
+#define V4L2_PIX_FMT_H263 v4l2_fourcc('H', '2', '6', '3') /*
H263 */
+#define V4L2_PIX_FMT_MPEG12 v4l2_fourcc('M', 'P', '1', '2') /*
MPEG-1/2 */
+#define V4L2_PIX_FMT_MPEG4v4l2_fourcc('M', 'P', 'G', '4') /*
MPEG-4 */
+#define V4L2_PIX_FMT_DIVX v4l2_fourcc('D', 'I', 'V', 'X') /*
DivX */
+#define V4L2_PIX_FMT_DIVX3v4l2_fourcc('D', 'I', 'V', '3') /*
DivX 3.11 */
+#define V4L2_PIX_FMT_DIVX4v4l2_fourcc('D', 'I', 'V', '4') /*
DivX 4.12 */
+#define V4L2_PIX_FMT_DIVX500 v4l2_fourcc('D', 'X', '5', '2') /*
DivX 5.00 - 5.02 */
+#define V4L2_PIX_FMT_DIVX503 v4l2_fourcc('D', 'X', '5', '3') /*
DivX 5.03 - x */
+#define V4L2_PIX_FMT_XVID v4l2_fourcc('X', 'V', 'I', 'D') /*
Xvid */
+#define V4L2_PIX_FMT_VC1 v4l2_fourcc('V', 'C', '1', 'A') /* VC-
1 */
+#define V4L2_PIX_FMT_VC1_RCV v4l2_fourcc('V', 'C', '1', 'R') /* VC-
1 RCV */
+
Hans, you mentioned some time ago that you were against ading H.264 or
MPEG4
fourccs, and that drivers should use the MPEG controls instead. Could
you
clarify your current position on this ?
If I remember correct there was no clear conclusion on this. I hope we can
discuss this
during the upcoming meeting.
Have you got an alternative suggestion to using fourccs?
The existing MPEG controls won't cover all the functions and parameters
that
are
used by video codecs. The controls that are in this patch are the ones
related to
decoding, there is even more for encoding.
Yesterday I have been talking with Hans on the IRC channel about the
control
for
quantization parameters and he has suggested to use different for MPEG4,
H263 and H264.
Personally I'd like to have a common one, as the QP meaning is the same in
those 3
cases, the difference is the range of the value.
So I think that this still is a subject that could use more discussion as
there are
a few ideas.
According to the fource.org, and if fourcc definition here has been made
from fourcc.org,
We need to have a discussion about new types that Kamil added not only h264
but divx_xxx.
QP might be a same topic. So let's discuss more at Poland meeting.
Best regards,
--
Kamil Debski
Linux Platform Group
Samsung Poland RD Center
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
On Friday, March 04, 2011 21:49:32 Mauro Carvalho Chehab wrote: Em 03-03-2011 07:25, Laurent Pinchart escreveu: Hi Mauro, The following changes since commit 88a763df226facb74fdb254563e30e9efb64275c: [media] dw2102: prof 1100 corrected (2011-03-02 16:56:54 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git media-2.6.39-0005-omap3isp ... Laurent Pinchart (36): ... v4l: subdev: Generic ioctl supportFrom 57b36ef1b9733124f3e04e6e2c06cf358051e209 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart laurent.pinch...@ideasonboard.com Date: Fri, 26 Feb 2010 16:23:10 +0100 Subject: v4l: subdev: Generic ioctl support Cc: Linux Media Mailing List linux-media@vger.kernel.org Instead of returning an error when receiving an ioctl call with an unsupported command, forward the call to the subdev core::ioctl handler. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- Documentation/video4linux/v4l2-framework.txt |5 + drivers/media/video/v4l2-subdev.c|2 +- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 77d96f4..f2df31b 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -405,6 +405,11 @@ VIDIOC_UNSUBSCRIBE_EVENT To properly support events, the poll() file operation is also implemented. +Private ioctls + + All ioctls not in the above list are passed directly to the sub-device + driver through the core::ioctl operation. + I2C sub-device drivers -- diff --git a/drivers/media/video/v4l2-subdev.c b/drivers/media/video/v4l2-subdev.c index 6e76f73..0b80644 100644 --- a/drivers/media/video/v4l2-subdev.c +++ b/drivers/media/video/v4l2-subdev.c @@ -276,7 +276,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg) } #endif default: - return -ENOIOCTLCMD; + return v4l2_subdev_call(sd, core, ioctl, cmd, arg); } return 0; -- 1.7.1 I don't like to apply a patch like that without a very good explanation about why it is needed and where it is used. Private ioctls are generally a very bad idea, as they lack proper documentation. Private ioctls are perfectly valid in sub-devices as they will only be used by applications that are written specifically for that hardware. Provided of course that they are documented reasonably well (the less public documentation there is, the more detailed the documentation should be) and that it is possible to still use the hardware (if in a more limited capability) without using them. Also, we may quickly loose the control about what ioctl's are valid for subdevs, as the same code could also be used to accept a video (or audio) ioctl directly into a subdev. That's why we do reviews. It's pretty easy to review: you just have to pay special attention to the ioctl core op in the subdev driver. So, IMO, the better is to manually add ioctl's there as they're needed inside subdevs. I'll not apply this patch on my tree for now. Yuck, then we pollute the core v4l2-subdev.c file with hardware-specific ioctls and subdev ops. We do the same for V4L2 drivers (vidioc_default), which works quite well. Obviously, there are problems with private ioctls in some legacy drivers. But in those days there was much less reviewing going on. Regards, Hans Is it currently needed for omap3isp? If so, what are the used ioctls inside omap3isp? v4l: Add subdev sensor g_skip_frames operation v4l: Add 8-bit YUYV on 16-bit bus and SGRBG10 media bus pixel codes v4l: Add remaining RAW10 patterns w DPCM pixel code variants v4l: Add missing 12 bits bayer media bus formats v4l: Add 12 bits bayer pixel formats Had you document all those newly-added formats at the API? Is there a way to double check if something is missed there? With the V4L2 API, as we add videodev2.h header, and we create dynamic links between the .h file and the specs, DocBook warns if some FOURCC is missed. From our experience, it is common that people add stuff at the header files, but forget to add the corresponding documentation for it. We need something similar for MBUS formats, as I suspect that we'll also have lots of additions there. Ok, I finished the review of the 36 media controller patches. I'll now start to dig into omap3isp patches. 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 -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe
[GIT PATCHES FOR 2.6.39] cx23885, altera-ci, stv0367: uncorrected blocks counter and other fixes
The following changes since commit 88a763df226facb74fdb254563e30e9efb64275c: [media] dw2102: prof 1100 corrected (2011-03-02 16:56:54 -0300) are available in the git repository at: git://linuxtv.org/liplianin/media_tree.git dual_dvb_t_c_ci_rf-1 Abylay Ospan (5): cx23885: Altera FPGA CI interface reworked. stv0367: change default value for AGC register. stv0367: implement uncorrected blocks counter. Fix CI code for NetUP Dual DVB-T/C CI RF card Force xc5000 firmware loading for NetUP Dual DVB-T/C CI RF card drivers/media/dvb/frontends/stv0367.c | 24 +--- drivers/media/video/cx23885/altera-ci.c | 14 ++ drivers/media/video/cx23885/cx23885-dvb.c | 23 +-- 3 files changed, 44 insertions(+), 17 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Hi Hans, On Sat, Mar 5, 2011 at 1:52 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Friday, March 04, 2011 21:10:05 Mauro Carvalho Chehab wrote: Em 03-03-2011 07:25, Laurent Pinchart escreveu: Hi Mauro, The following changes since commit 88a763df226facb74fdb254563e30e9efb64275c: [media] dw2102: prof 1100 corrected (2011-03-02 16:56:54 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git media-2.6.39-0005-omap3isp The branch has been rebased on top of the latest for_v2.6.39 branch, with the v4l2-ioctl.c conflict resolved. Antti Koskipaa (1): v4l: v4l2_subdev userspace crop API David Cohen (1): omap3isp: Statistics Laurent Pinchart (36): v4l: Share code between video_usercopy and video_ioctl2 v4l: subdev: Don't require core operations v4l: subdev: Add device node support v4l: subdev: Uninline the v4l2_subdev_init function v4l: subdev: Control ioctls support media: Media device node support media: Media device media: Entities, pads and links media: Entity use count media: Media device information query media: Entities, pads and links enumeration media: Links setup media: Pipelines and media streams v4l: Add a media_device pointer to the v4l2_device structure v4l: Make video_device inherit from media_entity v4l: Make v4l2_subdev inherit from media_entity v4l: Move the media/v4l2-mediabus.h header to include/linux v4l: Replace enums with fixed-sized fields in public structure v4l: Rename V4L2_MBUS_FMT_GREY8_1X8 to V4L2_MBUS_FMT_Y8_1X8 v4l: Group media bus pixel codes by types and sort them alphabetically The presence of those mediabus names against the traditional fourcc codes at the API adds some mess to the media controller. Not sure how to solve, but maybe the best way is to add a table at the V4L2 API associating each media bus format to the corresponding V4L2 fourcc codes. You can't do that in general. Only for specific hardware platforms. If you could do it, then we would have never bothered creating these mediabus fourccs. How a mediabus fourcc translates to a pixelcode (== memory format) depends entirely on the hardware capabilities (mostly that of the DMA engine). May I ask you one question here? (not entirely related to this patch set). Why pixelcode != mediabus fourcc? e.g. OMAP2 camera driver talks to sensor through subdev interface and sets its own output pixelformat depending on sensor's mediabus fourcc. So it needs a translation table mbus_pixelcode - pixelformat. Why can't it be pixelformat - pixelformat ? Regards, David A generic V4L2 application will never use mediabus fourcc codes. It's only used by drivers and applications written specifically for that hardware and using /dev/v4l-subdevX devices. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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 PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
On Saturday, March 05, 2011 14:04:21 David Cohen wrote: Hi Hans, On Sat, Mar 5, 2011 at 1:52 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Friday, March 04, 2011 21:10:05 Mauro Carvalho Chehab wrote: Em 03-03-2011 07:25, Laurent Pinchart escreveu: Hi Mauro, The following changes since commit 88a763df226facb74fdb254563e30e9efb64275c: [media] dw2102: prof 1100 corrected (2011-03-02 16:56:54 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git media-2.6.39-0005-omap3isp The branch has been rebased on top of the latest for_v2.6.39 branch, with the v4l2-ioctl.c conflict resolved. Antti Koskipaa (1): v4l: v4l2_subdev userspace crop API David Cohen (1): omap3isp: Statistics Laurent Pinchart (36): v4l: Share code between video_usercopy and video_ioctl2 v4l: subdev: Don't require core operations v4l: subdev: Add device node support v4l: subdev: Uninline the v4l2_subdev_init function v4l: subdev: Control ioctls support media: Media device node support media: Media device media: Entities, pads and links media: Entity use count media: Media device information query media: Entities, pads and links enumeration media: Links setup media: Pipelines and media streams v4l: Add a media_device pointer to the v4l2_device structure v4l: Make video_device inherit from media_entity v4l: Make v4l2_subdev inherit from media_entity v4l: Move the media/v4l2-mediabus.h header to include/linux v4l: Replace enums with fixed-sized fields in public structure v4l: Rename V4L2_MBUS_FMT_GREY8_1X8 to V4L2_MBUS_FMT_Y8_1X8 v4l: Group media bus pixel codes by types and sort them alphabetically The presence of those mediabus names against the traditional fourcc codes at the API adds some mess to the media controller. Not sure how to solve, but maybe the best way is to add a table at the V4L2 API associating each media bus format to the corresponding V4L2 fourcc codes. You can't do that in general. Only for specific hardware platforms. If you could do it, then we would have never bothered creating these mediabus fourccs. How a mediabus fourcc translates to a pixelcode (== memory format) depends entirely on the hardware capabilities (mostly that of the DMA engine). May I ask you one question here? (not entirely related to this patch set). Why pixelcode != mediabus fourcc? e.g. OMAP2 camera driver talks to sensor through subdev interface and sets its own output pixelformat depending on sensor's mediabus fourcc. The media bus deals with how pixels are transferred over a physical bus. For example 10-bit RGB samples. But how those samples end up in memory is quite a different story: depending on the (DMA) hardware this might end up as a 24-bit RGB format (8 bits per sample), or a multi-planar format where one plane has the top 8 bits and another plane the lower 2 bits, or it might go through a built-in colorspace convertor, and let's not forget the endianness issues you get once you DMA into memory. So mediabus formats are quite different from memory formats. In certain simple cases the mapping may be straightforward, but not in the general case. In a nutshell: mediabus deals with how two devices stream media over a bus between one another, whereas pixelformats deal with how the media is encoded in memory. Hope this helps. Regards, Hans So it needs a translation table mbus_pixelcode - pixelformat. Why can't it be pixelformat - pixelformat ? Regards, David A generic V4L2 application will never use mediabus fourcc codes. It's only used by drivers and applications written specifically for that hardware and using /dev/v4l-subdevX devices. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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 PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Hi David, On 03/05/2011 02:04 PM, David Cohen wrote: Hi Hans, On Sat, Mar 5, 2011 at 1:52 PM, Hans Verkuilhverk...@xs4all.nl wrote: On Friday, March 04, 2011 21:10:05 Mauro Carvalho Chehab wrote: Em 03-03-2011 07:25, Laurent Pinchart escreveu: ... v4l: Group media bus pixel codes by types and sort them alphabetically The presence of those mediabus names against the traditional fourcc codes at the API adds some mess to the media controller. Not sure how to solve, but maybe the best way is to add a table at the V4L2 API associating each media bus format to the corresponding V4L2 fourcc codes. You can't do that in general. Only for specific hardware platforms. If you could do it, then we would have never bothered creating these mediabus fourccs. How a mediabus fourcc translates to a pixelcode (== memory format) depends entirely on the hardware capabilities (mostly that of the DMA engine). May I ask you one question here? (not entirely related to this patch set). Why pixelcode != mediabus fourcc? e.g. OMAP2 camera driver talks to sensor through subdev interface and sets its own output pixelformat depending on sensor's mediabus fourcc. So it needs a translation table mbus_pixelcode - pixelformat. Why can't it be pixelformat - pixelformat ? Let me try to explain, struct v4l2_mbus_framefmt::code (pixelcode) describes how data is transfered/sampled on the camera parallel or serial bus. It defines bus width, data alignment and how many data samples form a single pixel. struct v4l2_pix_format::pixelformat (fourcc) on the other hand describes how the image data is stored in memory. As Hans pointed out there is not always a 1:1 correspondence, e.g. 1. Both V4L2_MBUS_FMT_YUYV8_1x16 and V4L2_MBUS_FMT_YUYV8_2x8 may being translating to V4L2_PIX_FMT_YUYV fourcc, 2. Or the DMA engine in the camera host interface might be capable of converting single V4L2_MBUS_FMT_RGB555 pixelcode to V4L2_PIX_FMT_RGB555 and V4L2_PIX_FMT_RGB565 fourcc's. So the user can choose any of them they seem most suitable and the hardware takes care of the conversion. What translations are available really depends on the hardware, so how could we define a standard translation table? IMO it should be realized in each driver on an individual basis. Regards, Sylwester Regards, David A generic V4L2 application will never use mediabus fourcc codes. It's only used by drivers and applications written specifically for that hardware and using /dev/v4l-subdevX devices. 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
[ANN] First draft of the agenda for the Warsaw meeting
Hi all! Here is the first draft of the agenda for the Warsaw meeting. Next weekend I'll prepare the final version. Please let me know any changes to/errors in the attendee list! I tried to order the agenda so we start gently (I hope!) and mix large and small items. I tried to name the main 'proponents' or 'stakeholders' for each item. Let me know if I am missing someone. For each item I added links to mailinglist discussions. I'm sure I'm missing links, so please let me know and I'll add it to the final agenda. If there are items missing, let me know as well. Although I suspect there won't be time for anything complicated. Hans Draft Agenda for V4L2 brainstorm meeting in Warsaw, March 16-18 2011. = Purpose of the meeting: to brainstorm about current V4L2 API limitations with regards to required functionality. Ideally the results of the meeting are actual solutions to these problems, but at the very least we should have a concensus of what direction to take and who will continue working on each problem. The hope is that this meeting will save us endless email and irc discussions. It is *not* a summit meeting, so any conclusions need to be discussed and approved on the mailinglist. The basic outline is the same as during previous meetings: the first day we go through all the agenda points and make sure everyone understands the problem. Smaller issues will be discussed and decided, more complex issues are just discussed. The second day we go in depth into the complex issues and try to come up with ideas that might work. The last day we translate the all agenda items into actions. This approach worked well in the past and it ensures that we end up with something concrete. Those who have a vested interest in an agenda item should be prepared to explain their take on it and if necessary have a presentation ready. Besides the main agenda I also added a few items falling under the category 'if time permits'. Attendees: Samsung Poland RD Center: Kamil Debski Sylwester Nawrocki Tomasz Stanislawski Marek Szyprowski (Organizer) Cisco Systems Norway: Martin Bugge Hans Verkuil (Chair) Nokia: Sakari Ailus Ideas On Board: Laurent Pinchart ST-Ericsson: Willy Poisson Samsung Korea (is this correct?): Jonghun Han Jaeryul Oh Freelance: Guennadi Liakhovetski Agenda: 1) Compressed format API for MPEG, H.264, etc. Also need to discuss what to do with weird 'H.264 inside MJPEG' muxed formats. (Hans, Laurent, Samsung) 2) Subdev architecture enhancements: - Acquiring subdevs from other devices using subdev pool http://www.mail-archive.com/linux-media@vger.kernel.org/msg21831.html - Introducing subdev hierarchy. Below there is a link to driver using it: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/28885/focus=28890 (Tomasz) 3) Entity information ioctl (Laurent) 4) Pipeline configuration, cropping and scaling: http://www.mail-archive.com/linux-media@vger.kernel.org/msg27956.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg26630.html (Everyone) 5) HDMI receiver/transmitter API support Some hotplug/CEC code can be found here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg28549.html CEC RFC from Cisco Systems Norway: http://www.mail-archive.com/linux-media@vger.kernel.org/msg28735.html (Martin, Hans, Samsung, ST-Ericsson) 6) Sensor/Flash/Snapshot functionality. http://www.mail-archive.com/linux-media@vger.kernel.org/msg28192.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg28490.html - Sensor blanking/pixel-clock/frame-rate settings (including enumeration/discovery) - Multiple video buffer queues per device (currently implemented in the OMAP 3 ISP driver in non-standard way). - Synchronising parameters (e.g. exposure time and gain) on given frames. Some sensors support this on hardware. There are many use cases which benefit from this, for example this one: URL:http://fcam.garage.maemo.org/ - Flash synchronisation (might fall under the above topic). - Frame metadata. It is important for the control algorithms (exposure, white balance, for example), to know which sensor settings have been used to expose a given frame. Many sensors do support this. Do we want to parse this in the kernel or does it belong to user space? The metadata formats are mostly sensor dependent. (Everyone) Items 4 and 6 are 'the big ones'. Past experience indicates that we can't go through all items on the first day and so I expect that item 6 (and perhaps even 5) will have to move to the second day. If time permits, then we can also look at these items: A) Buffer Pool (HWMEM, GEM, CMA) (ST-Ericsson, Samsung) B) Use of V4L2 as a frontend for SW/DSP codecs (Laurent) The reason I put these items here
Re: Patches an media build tree
On Sun, 16 Jan 2011 16:37:38 -0200 Mauro Carvalho Chehab mche...@redhat.com wrote: Em 15-01-2011 11:46, Helmut Auer escreveu: Hello List How long does it usually take til patches are integrated into the media build tree ( after posting these here ) ? I'm just wondering because I miss some patches posted here. It takes as much it needs for the driver maintainer to look into it, and for me to have time to handle them. The pending patches are always at: https://patchwork.kernel.org/project/linux-media/list/ Please note that, by default, Patchwork filters the patches to display only the ones marked as New or Under Review. If you want to see all patches, you need to change the state filter to show all patches: https://patchwork.kernel.org/project/linux-media/list/?state=* If the patch you're waiting are marked as Under Review, you should ping the driver maintainer, as I'm waiting for his review. If it is new, that means that I didn't have time yet to dig into it. Can you please check these patches ? What is missing ? Something to be corrected ? What happens to orphaned drivers ? Manu are you still working on this ? Manu , Mauro please comment ! Thanks ! Avoid unnecessary data copying inside dvb_dmx_swfilter_204() function 2010-08-07 Marko Ristola Under Review Refactor Mantis DMA transfer to deliver 16Kb TS data per interrupt 2010-08-07 Marko Ristola Under Review [v2] V4L/DVB: faster DVB-S lock for mantis cards using stb0899 demod 2010-10-10 Tuxoholic Under Review -- 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: please update dvb-t es-Madrid scan file
Please send a patch. Christoph 2011/2/28 Alberto Segura asgs...@gmail.com: Hello, es-Madrid has to be updated: * Removing channels: - EsMadrid TV (not functional) - Onda 6 (now la10) - CNN+ (now Gran Hermano 24h) - 40 Latino (inexistent) - Telecinco Sport (inexistent) - Telecinco Estrellas (inexistent) - Fly Music (inexistent) *Adding channels: - La Sexta 2 (not correctly tuned) - La Sexta 3 (new channel) - Nitro (new channel) - Boing (new channel) - La Siete (new channel) - La Sexta HD (HD) - TVE HD - pruebas (HD) - Telecinco HD (HD) - Telemadrid HD (HD) THANKS, Alberto. -- 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: V4L2 'brainstorming' meeting in Warsaw, March 2011
On Monday, February 28, 2011 19:12:00 Laurent Pinchart wrote: On Monday 28 February 2011 19:03:39 Hans Verkuil wrote: On Monday, February 28, 2011 18:11:47 Marek Szyprowski wrote: [snip] 4. Agenda TBD, everyone is welcomed to put his items here :) In no particular order: 1) pipeline configuration, cropping and scaling: http://www.mail-archive.com/linux-media@vger.kernel.org/msg27956.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg26630.html 2) HDMI API support Some hotplug/CEC code can be found here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg28549.html but Cisco will soon post RFCs on this topic as well. 3) Snapshot functionality. http://www.mail-archive.com/linux-media@vger.kernel.org/msg28192.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg28490.html If we finish quicker than expected, then we can also look at this: - use of V4L2 as a frontend for SW/DSP codecs In still no particular order: - Muxed formats (H.264 inside MJPEG) - H.264 - Buffers pool - Entity information ioctl Can you elaborate on this one? - Userspace drivers (OMX) And this one? - Sensor blanking/pixel-clock/frame-rate settings (including enumeration/discovery) - GL/ES in V4L2 devices And this one? I need a bit more information for the agenda. Thanks! Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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: [ANN] First draft of the agenda for the Warsaw meeting
On 03/05/2011 04:20 PM, Hans Verkuil wrote: Hi all! Here is the first draft of the agenda for the Warsaw meeting. Next weekend I'll prepare the final version. Please let me know any changes to/errors in the attendee list! I tried to order the agenda so we start gently (I hope!) and mix large and small items. I tried to name the main 'proponents' or 'stakeholders' for each item. Let me know if I am missing someone. For each item I added links to mailinglist discussions. I'm sure I'm missing links, so please let me know and I'll add it to the final agenda. If there are items missing, let me know as well. Although I suspect there won't be time for anything complicated. Hans Draft Agenda for V4L2 brainstorm meeting in Warsaw, March 16-18 2011. = Purpose of the meeting: to brainstorm about current V4L2 API limitations with regards to required functionality. Ideally the results of the meeting are actual solutions to these problems, but at the very least we should have a concensus of what direction to take and who will continue working on each problem. The hope is that this meeting will save us endless email and irc discussions. It is *not* a summit meeting, so any conclusions need to be discussed and approved on the mailinglist. The basic outline is the same as during previous meetings: the first day we go through all the agenda points and make sure everyone understands the problem. Smaller issues will be discussed and decided, more complex issues are just discussed. The second day we go in depth into the complex issues and try to come up with ideas that might work. The last day we translate the all agenda items into actions. This approach worked well in the past and it ensures that we end up with something concrete. Those who have a vested interest in an agenda item should be prepared to explain their take on it and if necessary have a presentation ready. Besides the main agenda I also added a few items falling under the category 'if time permits'. Attendees: Samsung Poland RD Center: Kamil Debski Sylwester Nawrocki Tomasz Stanislawski Marek Szyprowski (Organizer) Cisco Systems Norway: Martin Bugge Hans Verkuil (Chair) Nokia: Sakari Ailus Ideas On Board: Laurent Pinchart ST-Ericsson: Willy Poisson Samsung Korea (is this correct?): Yes, that's right. Exactly it's Samsung System LSI Division, Korea. Thanks to Mr. Han and Mr. Oh for joining us! :) Jonghun Han Jaeryul Oh Freelance: Guennadi Liakhovetski Agenda: 1) Compressed format API for MPEG, H.264, etc. Also need to discuss what to do with weird 'H.264 inside MJPEG' muxed formats. (Hans, Laurent, Samsung) 2) Subdev architecture enhancements: - Acquiring subdevs from other devices using subdev pool http://www.mail-archive.com/linux-media@vger.kernel.org/msg21831.html - Introducing subdev hierarchy. Below there is a link to driver using it: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/28885/focus=28890 (Tomasz) 3) Entity information ioctl (Laurent) 4) Pipeline configuration, cropping and scaling: http://www.mail-archive.com/linux-media@vger.kernel.org/msg27956.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg26630.html (Everyone) 5) HDMI receiver/transmitter API support Some hotplug/CEC code can be found here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg28549.html CEC RFC from Cisco Systems Norway: http://www.mail-archive.com/linux-media@vger.kernel.org/msg28735.html (Martin, Hans, Samsung, ST-Ericsson) 6) Sensor/Flash/Snapshot functionality. http://www.mail-archive.com/linux-media@vger.kernel.org/msg28192.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg28490.html - Sensor blanking/pixel-clock/frame-rate settings (including enumeration/discovery) - Multiple video buffer queues per device (currently implemented in the OMAP 3 ISP driver in non-standard way). - Synchronising parameters (e.g. exposure time and gain) on given frames. Some sensors support this on hardware. There are many use cases which benefit from this, for example this one: URL:http://fcam.garage.maemo.org/ - Flash synchronisation (might fall under the above topic). - Frame metadata. It is important for the control algorithms (exposure, white balance, for example), to know which sensor settings have been used to expose a given frame. Many sensors do support this. Do we want to parse this in the kernel or does it belong to user space? The metadata formats are mostly sensor dependent. I'd like to discuss also, as time permits, handling of EXIF files produced by more
Re: scan file norway, bergen
Added, thanks. Christoph 2011/2/28 Thomas Amland thomas.aml...@gmail.com: -- Forwarded message -- From: Thomas Amland thomas.aml...@gmail.com Date: Mon, Feb 28, 2011 at 4:03 PM Subject: scan file norway, bergen To: linux-...@linuxtv.org Created with w_scan, frequencies from http://www.ntv.no/dekningskart, and confirmed with scan. # Norway, Bergen # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 57000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO T 61800 8MHz AUTO AUTO AUTO AUTO AUTO AUTO T 65000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO T 69800 8MHz AUTO AUTO AUTO AUTO AUTO AUTO T 73000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO -- 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 PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Em 05-03-2011 10:02, Laurent Pinchart escreveu: Hi Mauro, Thanks for the review. Let me address all your concerns in a single mail. - ioctl numbers I'll send you a patch that reserves a range in Documentation/ioctl/ioctl- number.txt and update include/linux/media.h accordingly. Ok, thanks. - private ioctls As already explained by David, the private ioctls are used to control advanced device features that can't be handled by V4L2 controls at the moment (such as setting a gamma correction table). Using those ioctls is not mandatory, and the device will work correctly without them (albeit with a non optimal image quality). David said he will submit a patch to document the ioctls. Ok. - media bus formats As Hans explained, there's no 1:1 relationship between media bus formats and pixel formats. Yet, there are some relationship between them. See my comments on my previous email. - FOURCC and media bus codes documentation I forgot to document some of them. I'll send a new patch that adds the missing documentation. Ok. Is there any other issue I need to address ? Nothing else, in the patches I've analysed so far. I'll take a look at the remaining omap3isp after receiving the documentation for the private ioctl's. My understanding is that there's no need to rebase the existing patches, is that correct ? Yes, it is correct. Just send the new patches to be applied at the end of the series. I'll eventually reorder them if needed to avoid breaking git bisect. Thanks! Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: isp or soc-camera for image co-processors
Bhupesh SHARMA wrote: Hi Sakari, Laurent and Guennadi, Hi Bhupesh and others, ... Are there are reference drivers that I can use for my study? The OMAP3 ISP driver. Thanks, I will go through the same. The major difference in this to OMAP 3 is that the OMAP 3 does have access to host side memory but the co-processor doesn't --- as it's a CSI-2 link. Additional CSI-2 receiver (and a driver for it) is required on the host side. This receiver likely is not dependent on the co-processor so the driver shouldn't be either. For example, using this co-processor should well be possible with the OMAP 3 ISP, in theory at least. What would be needed in this case is... support for multiple complex Media device drivers under a single Media device --- both drivers would be accessible through the same media device. The co-processor would mostly look like a sensor for the OMAP 3 ISP driver. Its internal topology would be more complex, though. Just a few ideas; what do you think of this? :-) Yes, but I think I need to explain the system design better : One, there is an camera interface IP within the SOC as well which has an internal buffer to store a line of image data and dma capabilities to send this data to system ddr. So, co-processor has no access to system MMU or buffers inside the main SoC, but it has internal buffer to store data. It is connected via either a ITU or CSI-2 interface to the SoC. This is the primary and major difference between our architecture and OMAP 3 ISP. As I read more the OMAP 3 TRM, I wonder whether SoC framework fits better in our case, as we have three separate entities to consider here: - Camera Host inside the SoC - Camera Co-processor connected with host via CSI-2/ITU (data interface) and I2C/CCI (control interface) - Camera sensor connected to the co-processor via CSI-2 (data interface) and I2C/CCI (control interface) What are your views? Guennadi can you also pitch in with your thoughts.. I fear that neither soc-camera nor media framework have support for 3 entities listed above, as of now. The Media controller interface allows enumerating entities and links in the media device, activating the links between the entities. There is no such thing as support for particular type of entity. V4L2 subdevs on the other hand do give access to the V4L2 specifics of the entities. I think the Media controller V4L2 subdevs are a good starting point for supporting this kind of hardware. Changes in the Media controller framework are likely needed to allow more flexible graph definition than currently is possible. That should make attaching this type of a device to any existing CSI-2 (or parallel) receiver on the host CPU relatively easy. Unfortunately the data-sheet of the co-processor cannot be made public as of yet. Can you publish a block diagram of the co-processor internals ? I will check internally to see if I can send a block-diagram of the co-processor internals to you. The internals seem similar to I'd be very interested in this as well, thank you. I have raised a request internally to enquire about the same :) Thanks! OMAP ISP (which I can see from the public TRM). However, our co-processor doesn't have the circular buffer and MMU that ISP seem to have (and some other features). In the meantime I copy the features of the co-processor here for your review: Input / Output interfaces of co-processor: == - Sensor interfaces: 2 x MIPI CSI-2 receivers (1 x dual-lane up to 1.6 Gbit/s and 1 x single lane up to 800 Mbit/s) - Host interface: MIPI CSI-2 dual lane transmitter (up to 1.6 Gbit/s) or ITU (8-bit CCIR interface, up to 100 MHz) - all with independent variable transmitter clock (PLL) - Control interface: CCI (up to 400 kHz) or SPI Sensor support: === - Supports two MIPI compliant sensors of up to 8 Megapixel resolution (one sensor streaming at a time) - Support for auto-focus (AF), extended depth of field (EDOF) and wide dynamic range (WDR)sensors Internal Features: == - Versatile clock manager and internal buffer to accommodate a wide range of data rates between sensors and the coprocessor and between the coprocessor and the host. - Synchronized flash gun control with red-eye reduction (pre-flash and main-flash strobes) for high-power LED or Xenon strobe light Does the co-processor have internal memory or can external memory be attached to it for buffer storage? The co-processor has no access to system MMU or buffers inside the main SoC, but it has internal buffer to store data. One more question... does the co-processor have enough memory to store images themselves? The rotation functionality suggests that it has more memory than is required to save just a few lines of image data. What about the jpeg encoding; is the co-processor also able to provide the same
[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:Sat Mar 5 19:00:27 CET 2011 git hash:88a763df226facb74fdb254563e30e9efb64275c gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: ERRORS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: ERRORS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification failed to build, but the last compiled spec 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: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Hi Mauro, On Saturday 05 March 2011 19:22:28 Mauro Carvalho Chehab wrote: Em 05-03-2011 10:02, Laurent Pinchart escreveu: Hi Mauro, Thanks for the review. Let me address all your concerns in a single mail. - ioctl numbers I'll send you a patch that reserves a range in Documentation/ioctl/ioctl- number.txt and update include/linux/media.h accordingly. Ok, thanks. media: Pick a free ioctls range at the top of the http://git.linuxtv.org/pinchartl/media.git?a=shortlog;h=refs/heads/media-2.6.39-0005- omap3isp branch - private ioctls As already explained by David, the private ioctls are used to control advanced device features that can't be handled by V4L2 controls at the moment (such as setting a gamma correction table). Using those ioctls is not mandatory, and the device will work correctly without them (albeit with a non optimal image quality). David said he will submit a patch to document the ioctls. Ok. Working on that. - media bus formats As Hans explained, there's no 1:1 relationship between media bus formats and pixel formats. Yet, there are some relationship between them. See my comments on my previous email. Let's continue the discussion in the mail thread. - FOURCC and media bus codes documentation I forgot to document some of them. I'll send a new patch that adds the missing documentation. Ok. v4l: Add documentation for the 12 bits bayer pixel formats v4l: Fix 12 bits bayer media bus format documentation in the http://git.linuxtv.org/pinchartl/media.git?a=shortlog;h=refs/heads/media-2.6.39-0004- v4l-misc branch. Is there any other issue I need to address ? Nothing else, in the patches I've analysed so far. I'll take a look at the remaining omap3isp after receiving the documentation for the private ioctl's. My understanding is that there's no need to rebase the existing patches, is that correct ? Yes, it is correct. Just send the new patches to be applied at the end of the series. I'll eventually reorder them if needed to avoid breaking git bisect. Please squash v4l: Add documentation for the 12 bits bayer pixel formats with v4l: Add 12 bits bayer pixel formats and v4l: Fix 12 bits bayer media bus format documentation with v4l: Add missing 12 bits bayer media bus formats when applying to keep the history clean. You can discard the commit message of the two new patches. -- 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: V4L2 'brainstorming' meeting in Warsaw, March 2011
Hi Hans, On Saturday 05 March 2011 17:02:13 Hans Verkuil wrote: On Monday, February 28, 2011 19:12:00 Laurent Pinchart wrote: On Monday 28 February 2011 19:03:39 Hans Verkuil wrote: On Monday, February 28, 2011 18:11:47 Marek Szyprowski wrote: [snip] 4. Agenda TBD, everyone is welcomed to put his items here :) In no particular order: 1) pipeline configuration, cropping and scaling: http://www.mail-archive.com/linux-media@vger.kernel.org/msg27956.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg26630.html 2) HDMI API support Some hotplug/CEC code can be found here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg28549.html but Cisco will soon post RFCs on this topic as well. 3) Snapshot functionality. http://www.mail-archive.com/linux-media@vger.kernel.org/msg28192.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg28490.html If we finish quicker than expected, then we can also look at this: - use of V4L2 as a frontend for SW/DSP codecs In still no particular order: - Muxed formats (H.264 inside MJPEG) - H.264 - Buffers pool - Entity information ioctl Can you elaborate on this one? Some drivers (namely the uvcvideo driver) will need to report driver-specific information about each entity (the UVC entity GUID, the UVC controls it supports, ...). We need an API for that. - Userspace drivers (OMX) And this one? This is a follow-up of the v4l2 vs omx for camera discussion. I'd like to discuss whether we need an API for userspace drivers, like OMX has. - Sensor blanking/pixel-clock/frame-rate settings (including enumeration/discovery) - GL/ES in V4L2 devices And this one? Devices are becoming hybrid. GPUs are supported through DRM and OpenGL (OpenGL/ES is embedded devices), and video output with V4L2. What about a video output device with OpenGL/ES capabilities ? We'll need to think about it at some point. -- 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: BUG at mm/mmap.c:2309 when cx18.ko and cx18-alsa.ko loaded
On Sat, 2011-03-05 at 16:59 -0500, Andy Walls wrote:
On Thu, 2011-03-03 at 21:06 -0500, Andy Walls wrote:
Hi,
I got a BUG when loading the cx18.ko module (which in turn requests the
cx18-alsa.ko module) on a kernel built from this repository
http://git.linuxtv.org/media_tree.git staging/for_v2.6.39
which I beleive is based on 2.6.38-rc2.
[snip]
So here is my transcription of a fuzzy digital photo of the screen:
kernel BUG at /home/andy/cx18dev/git/media_tree/mm/mmap.c:2309!
invalid opcode: [#1] SMP
last sysfs file: /sys/module/snd_pcm/initstate
Modules linked in: tda9887 tda8290 mxl5005s s5h1409 tuner_simple ...
...
Pid: 2580, comm: udevd Not tainted 2.6.38-rc2-cx18-vb2-proto+
RIP: 0010:[810eb50b] [810eb50b] exit_mmap+0x10f/0x11e
RAX: RBX: RCX: 0020
RDX: 00160011 RSI: eac42___ RDI: 0202
RBP: 18c1f_58 R08: R09: 0004
R10: ___bb_38 R11: R12: 344a6680
R13: 7fff22__ R14: R15: 0001
...
CR2: ...
Process udevd (pid: 25__, threadinfo , ...
Stack:
015e 3bc0e1d0 0246
.
Call Trace:
... mmput+0x63/0xcf
... exit_mm+0x132/0x13f
... do_exit+0x238/0x749
... ? __dequeue_signal+0xfa/0x12f
... do_group_exit+0x7d/0xa5
... get_signal_to_deliver+0x371/0x395
... do_signal+0x72/0x692
... ? do_page_fault+0x24a/0x391
... ? printk+0x41/0x47
... ? sigprocmask+0xa3/0xcd
... do_notify_resume+0x2c/0x64
... retint_signal+0x48/0x8c
Code: ff ff 48 8b 7d d8 4c 89 ea 31 f6 e8 3e fe ff ff 48 89 df e8 78 fe
ff ff 48 85 c0 48 89 c3 75 f0 49 83 bc 24 e0 00 00 00 00 74 04 0f 0b
eb fe 48 83 c4 18 5b 41 5c 41 5d c9 c3 55 48 89 e5 41 57
RIP [810eb50b] exit_mmap+0x10f/0x11e
RSP 880018c1fc28
general protection fault: [#2] SMP
last sysfs file: /sys/devices/virtual/sound/card2/uevent
CPU 1
Modules linked in: cx18-alsa tda9887 tda8290 mxl5005s s5h1409
tuner_simple tuner_types cs5345 tuner cx18 dvb_core cx2341x v4l2_common
videodev v4l2_compat_ioctl32
I'm dumping all my previous assumtpions about this BUG. After a bit of
reading, all I can say is that it's a page table deallocation problem at
process exit. After all the page table deallocations on exit,
mm-nr_ptes is still 0, and that's a bad thing.
It apparently happened in a child udevd exiting shortly after cx18.ko
loaded. The cx18 driver allocating large amounts kernel memory for DMA
buffers upon load may be related to triggering the problem, but I doubt
it is a root cause of the BUG.
This monsterous thread from 5 years ago is somewhat enlightening:
http://lkml.indiana.edu/hypermail/linux/kernel/0503.2/1680.html
http://lkml.indiana.edu/hypermail/linux/kernel/0503.2/1787.html
so it gives me a place to start looking for the problem.
Any advice on what data to collect is appreciated.
When attemtping to reproduce this BUG, I got another bug related to
memory management:
(Details handtyped from a photo):
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [010f22fa] remove_vm_area+0x42/0x77
PGD 37cdd067 PUD 336c__67 PMD 0
Oops: [#1] SMP
last sysfs file:
/sys/devices/pci:00/:00:14.4/:03:00.0/firmware/:03:00.0/loading
CPU 0
Modules linked in: tda9887 tda8290 mxl5005s s5h1409 tuner_simple tuner_types
cx5345 tuner cx18(+) dvb_core cx2341x ...
Pid: 2470, comm: work_for_cpu Tainted: GW 2.6.28-rc2-cx18-vb2-proto+
RIP: 0010:[010f22fa] [010f22fa] remove_vm_area+0x42/0x77
...
RAX: RBX: 35e7c540 RCX: 1000
RDX:
...
CR2:
Stack:
__0011485968 001 1147dc9_ _1_f23__
Call Trace:
... __vunmap+0x3e/0xbd
... vfree+0x2e/0x30
... dvb_dmx_init+0x7e/0x253 [dvb_core]
... cx18_dvb_register+0xd2/0x75c [cx18]
... cx18_streams_resgister+0x6a/0x26a [cx18]
... cx18_streams_setup+0x3cc/0x486 [cx18]
... cx18_probe+0x11cc/0x12fb [cx18]
..
The code appears to be failing here:
/home/andy/cx18dev/git/media_tree/mm/vmalloc.c:1352
161d: eb 06 jmp1625 remove_vm_area+0x45
161f: 48 89 c2mov%rax,%rdx
1622: 48 8b 00mov(%rax),%rax--- Oops p =
tmp-next) (tmp = *p)
1625: 48 39 d8cmp%rbx,%rax(tmp =
*p) != vm;
1628: 75 f5 jne161f remove_vm_area+0x3f
/home/andy/cx18dev/git/media_tree/mm/vmalloc.c:1354
Corresponding to this code in mm/vmalloc.c:
struct vm_struct *remove_vm_area(const void *addr)
{
struct vmap_area *va;
va = find_vmap_area((unsigned long)addr);
if (va va-flags
Re: [PATCH 0/13] lirc_zilog: Ref-counting and locking cleanup
On Feb 17, 2011, at 8:11 PM, Andy Walls wrote: The following 13 patches are a substantial rework of lirc_zilog reference counting, object allocation and deallocation, and object locking. With these changes, devices can now disappear out from under lircd + lirc_dev + lirc_zilog with no adverse effects. I tested this with irw + lircd + lirc_dev + lirc_zilog + cx18 + HVR-1600. I could unload the cx18 driver without any oops or application crashes. When I reloaded the cx18 driver, irw started receiving RX button presses again, and irsend worked without a problem (and I didn't even need to restart lircd!). The ref counting fixes aren't finished as lirc_zilog itself can still be unloaded by the user when it shouldn't be, but a hot unplug of an HD-PVR, PVR-USB2, or HVR-1950 isn't going to trigger that. These changes are base off of Jarod Wilson's git repo http://git.linuxtv.org/jarod/linux-2.6-ir.git for-2.6.38 (IIRC) As discussed on irc Friday, after figuring out an issue with trying to test these using media_build against a 2.6.32 kernel, both the hdpvr and hvr-1950 still function with these patches, and now you can even hot-unplug them with lirc_zilog loaded and the system doesn't blow up. Also gave a cursory read over all the code changes, didn't see anything jump out that looked out of sorts, aside from the few minor fixlets we also discussed. I'll just fix those locally in what I merge into the tree I'm prepping with a variety of IR-related fixes for 2.6.39 to have Mauro pull. So for the set: Acked-by: Jarod Wilson ja...@redhat.com -- Jarod Wilson ja...@wilsonet.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
