Re: rtl28xxu - rtl2832 frontend attach
On 26.05.2012 04:47, poma wrote: On 05/20/2012 11:12 PM, Thomas Mair wrote: On 20.05.2012 22:08, Antti Palosaari wrote: On 20.05.2012 20:04, poma wrote: After hard/cold boot: DVB: register adapter0/net0 @ minor: 2 (0x02) rtl2832u_frontend_attach: rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 No compatible tuner found These errors are coming from tuner probe. As it still goes to probing and did not jump out earlier when gate is opened it means that demod is answering commands but tuner are not. My guess is that tuner is still on the reset or not powered at all. It is almost 100% sure error is wrong tuner GPIO. There is an issue with GPIO, as FC0012 tuner callback will set the value of one of the GPIO outputs. However fixing that, will not resolve the issue. So I need to debug the problem further. True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes even more. Precisely, what breaks a tuner on next soft [re]boot are apps/utils which engage tzap/scan[dvb]. To reproduce the bug it is not necessary to reboot the machine. Simply unload and load of the dvb_usb_rtl28xxu module will lead to the same situation. I suspect, that when power is turned off, the tuner power is not switched on correctly. The mistake is not related to the OUTPUT_VAL registers but probably to the OUTPUT_DIR or OUTPUT_EN registers. What makes me wonder is if no tuning operation is performed before reboot, the driver does work correctly after that, as poma already noticed. I have some spare time today and will investigate the problem further. Regards Thomas -- 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: Firmware blob in vs6624 driver
Hi Ben, This doesn't touch any of the documented registers, so presumably it's a patch to the firmware loaded from non-volatile memory. Unless you can provide source code for the patch, this should go in the linux-firmware repository and be loaded with request_firmware() instead of embedded in the GPL driver source. Sounds reasonable. Also, shouldn't you check the loaded firmware version first to verify that it's safe to apply the patch? The problem is you can't get version before power up device but you should apply patch at that time. Scott -- 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] file tree rearrangement - was: Re: [RFC PATCH 0/3] Improve Kconfig selection for media devices
On Sun May 27 2012 21:54:58 Mauro Carvalho Chehab wrote: Em 27-05-2012 14:25, Hans Verkuil escreveu: On Sun May 27 2012 19:13:38 Mauro Carvalho Chehab wrote: Em 27-05-2012 13:56, Mauro Carvalho Chehab escreveu: The Kconfig building system is improperly selecting some drivers, like analog TV tuners even when this is not required. Rearrange the Kconfig in a way to prevent that. Mauro Carvalho Chehab (3): media: reorganize the main Kconfig items media: Remove VIDEO_MEDIA Kconfig option media: only show V4L devices based on device type selection drivers/media/Kconfig | 114 +++ drivers/media/common/tuners/Kconfig | 64 ++-- drivers/media/dvb/frontends/Kconfig |1 + drivers/media/radio/Kconfig |1 + drivers/media/rc/Kconfig| 29 - drivers/media/video/Kconfig | 76 +-- drivers/media/video/m5mols/Kconfig |1 + drivers/media/video/pvrusb2/Kconfig |1 - drivers/media/video/smiapp/Kconfig |1 + 9 files changed, 181 insertions(+), 107 deletions(-) The organization between DVB only, V4L only and hybrid devices are somewhat confusing on our tree. From time to time, someone proposes changing one driver from one place to another or complains that his device is DVB only but it is inside the V4L tree (and other similar requests). This sometimes happen because the same driver can support analog only, digital only or hybrid devices. Also, one driver may start as a DVB only or as a V4L only and then it can be latter be converted into an hybrid driver. So, the better is to rearrange the drivers tree, in order to fix this issue, removing them from /video and /dvb, and storing them on a better place. So, my proposal is to move all radio, analog TV, digital TV, webcams and grabber bridge drivers to this arrangement: drivers/media/isa - ISA drivers drivers/media/usb - USB drivers drivers/media/pci - PCI/PCIe drivers drivers/media/platform - platform drivers drivers/media/parport Ok. drivers/media/i2c See below. Also, if we do this then I would really like to separate the sub-device drivers from the main drivers. I find it very messy that those are mixed. So: drivers/media/subdevs We might subdivide /subdevs even further (sensors, encoders, decoders, etc.) but I am not sure if that is worthwhile. I think all subdevs (being i2c or not) should be under the same directory. drivers/media/subdevs seems reasonable. What I meant with media/i2c was not for subdevices but for a few drivers that are pure i2c V4L drivers (radio-tea5764.c, radio-si470x-i2c.c). I am not sure whether we should bother though. What might be more useful is to have a 'others' subdirectory containing 'odds 'n ends' like parport and i2c drivers, and also drivers like the radio-si470x which comes in a i2c (as I mentioned above) and a usb variant and so is hard to classify (and splitting it up doesn't seem useful). Sub-dividing them doesn't seem a good idea, as some subdevs may have more than one function. I agree (for now :-) ). Frankly, the current directory structure (other than the lack of a subdevs directory) doesn't bother me. But your proposal is a bit cleaner. It doesn't bother me either[1], with regards to the existing drivers, but it is confusing for someone that wants to write a new driver. [1] with exception to the saa7146 driver under media/common - that looks really weird. Things like saa7146, cx2341x, tveeprom, radio-isa are all helper modules for particular types of hardware. So they should go to a 'common' or 'helpers' directory. Also, for example, Antti proposed to add V4L2 support for dvb-usb. I think he ended by discarding it for his GoC scope of work, but, anyway, with the current arrangement, that would mean that dvb-usb won't fit well at media/dvb (as all other hybrid cards aren't there). So, as we're removing the explicit Kconfig logic for compiling V4L2 core/DVB core, it makes sense to rearrange the rest of the structure and improve the building system to better handle the media cards, removing the artificial and imperfect divisions that it is used there. Go for it! :-) Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] file tree rearrangement - was: Re: [RFC PATCH 0/3] Improve Kconfig selection for media devices
On Sun May 27 2012 22:15:08 Mauro Carvalho Chehab wrote: Em 27-05-2012 15:47, Andy Walls escreveu: Hans Verkuil hverk...@xs4all.nl wrote: On Sun May 27 2012 19:13:38 Mauro Carvalho Chehab wrote: Em 27-05-2012 13:56, Mauro Carvalho Chehab escreveu: The Kconfig building system is improperly selecting some drivers, like analog TV tuners even when this is not required. Rearrange the Kconfig in a way to prevent that. Mauro Carvalho Chehab (3): media: reorganize the main Kconfig items media: Remove VIDEO_MEDIA Kconfig option media: only show V4L devices based on device type selection drivers/media/Kconfig | 114 +++ drivers/media/common/tuners/Kconfig | 64 ++-- drivers/media/dvb/frontends/Kconfig |1 + drivers/media/radio/Kconfig |1 + drivers/media/rc/Kconfig| 29 - drivers/media/video/Kconfig | 76 +-- drivers/media/video/m5mols/Kconfig |1 + drivers/media/video/pvrusb2/Kconfig |1 - drivers/media/video/smiapp/Kconfig |1 + 9 files changed, 181 insertions(+), 107 deletions(-) The organization between DVB only, V4L only and hybrid devices are somewhat confusing on our tree. From time to time, someone proposes changing one driver from one place to another or complains that his device is DVB only but it is inside the V4L tree (and other similar requests). This sometimes happen because the same driver can support analog only, digital only or hybrid devices. Also, one driver may start as a DVB only or as a V4L only and then it can be latter be converted into an hybrid driver. So, the better is to rearrange the drivers tree, in order to fix this issue, removing them from /video and /dvb, and storing them on a better place. So, my proposal is to move all radio, analog TV, digital TV, webcams and grabber bridge drivers to this arrangement: drivers/media/isa - ISA drivers drivers/media/usb - USB drivers drivers/media/pci - PCI/PCIe drivers drivers/media/platform - platform drivers drivers/media/parport drivers/media/i2c Also, if we do this then I would really like to separate the sub-device drivers from the main drivers. I find it very messy that those are mixed. So: drivers/media/subdevs We might subdivide /subdevs even further (sensors, encoders, decoders, etc.) but I am not sure if that is worthwhile. Frankly, the current directory structure (other than the lack of a subdevs directory) doesn't bother me. But your proposal is a bit cleaner. Regards, Hans Comments? Regards, Mauro - PS.: for now, I don't intend to touch at I2C/ancillary drivers. We may latter move the i2c drivers that aren't frontend/tuners to media/i2c or to media/common. -- 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 Also cx2341x and tveeprom cx2341x is a sub-device module. So, it can go to drivers/media/subdevs (ok, it has other problems, but solving them is not as simple as moving things from one place to the other - so let's not mix it here). It's not a subdev. It's a helper module, so it should go to common (or 'helpers'). The case of tveeprom is different, because it is not really a sub-device. Btw, this file is bad named - it should be called hauppauge-eeprom or something like that. Yet, I wouldn't move it out of drivers/media/video (or at least on this first step). There are other similar cases. for example, btcx-risc is a common module used by both cx88 and bttv drivers to handle the RISC processor that exists on both. This is not a sub-device, so it won't fit on the above structure. . Maybe we can create a drivers/media/v4l2-core and move everything that belongs to the core into it, and the things that won't fit elsewhere can be moved into drivers/media/common. Ack. I would also move tuner, dvb-core and frontend to an upper level: So, in summary, the final structure would be: drivers/media /common - drivers that are common to several ones, like tveeprom and btcx-risc And saa7146 sources in /common/saa7146. That will (finally!) make sense. What can go in here: - saa7146 - tveeprom - cx2341x - btcx-risc - radio-isa - smiapp-pll (?) We should probably also try and get tea575x-tuner.c in here. But that can be done in a separate step. /dvb-core - what is already at dvb/dvb-core /frontends - what is already at dvb/frontends /isa- all ISA drivers
Re: [RFC PATCH 0/3] Improve Kconfig selection for media devices
On May 27 Mauro Carvalho Chehab wrote: The Kconfig building system is improperly selecting some drivers, like analog TV tuners even when this is not required. Rearrange the Kconfig in a way to prevent that. Mauro Carvalho Chehab (3): media: reorganize the main Kconfig items media: Remove VIDEO_MEDIA Kconfig option media: only show V4L devices based on device type selection On 1/3 media: reorganize the main Kconfig items: a) I agree with Sylvester that the MEDIA_WEBCAM_SUPP variable, prompt text, and help text should be worded a bit more general. Wouldn't this variable also cover industrial cameras and who knows what other kinds of video inputs? I also agree with Sylvester about the SUPP vs. SUPPORT thing. b) Small typo in the MEDIA_ANALOG_TV_SUPP help text: of - or. c) The RC_CORE_SUPP help text gives the impression that RC core is always needed if there is hardware with an IR feature. But the firedtv driver is a case where the driver directly works on top of the input subsystem rather than on RC core. Maybe there are more such cases. (Currently we don't ask whether FireDTV owners want IR support; we silently build the IR part of firedtv in if CONFIG_INPUT is set, and silently omit the IR part of firedtv if CONFIG_INPUT was disabled, which requires CONFIG_EXPERT.) How about turning the Remote Controller support option into merely a filter for standalone IR and RF receivers and transmitters, whereas Kconfig options in the analog and digital TV categories silently do select RC_CORE if INPUT for combined tuner + IR/RF rx/tx hardware? -- Stefan Richter -=-===-- -=-= ===-- http://arcgraph.de/sr/ -- 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/PATCH] media: Add stk1160 new driver
On Sun May 27 2012 23:20:21 Ezequiel Garcia wrote: Hi Hans, On Sat, May 26, 2012 at 2:05 PM, Hans Verkuil hverk...@xs4all.nl wrote: Always test your driver using the v4l2-compliance test tool that it part of v4l-utils! If it passes that, then your code will be in really good shape! You're right. I'll add v4l2-compliance output in the next patch. On Sat May 26 2012 18:41:00 Ezequiel Garcia wrote: This driver adds support for stk1160 usb bridge as used in some video/audio usb capture devices. It is a complete rewrite of staging/media/easycap driver and it's expected as a future replacement. Signed-off-by: Ezequiel Garcia elezegar...@gmail.com --- As of today testing has been performed using both vlc and mplayer on a gentoo machine, including hot unplug and on-the-fly standard change using a device with 1-cvs and 1-audio output. However more testing is underway with another device and/or another distribution. Alsa sound support is a missing feature (work in progress). As this is my first complete driver, the patch is (obviously) intended as RFC only. Any comments/reviews of *any* kind will be greatly appreciated. --- drivers/media/video/Kconfig |2 + drivers/media/video/Makefile|1 + drivers/media/video/stk1160/Kconfig | 11 + drivers/media/video/stk1160/Makefile|6 + drivers/media/video/stk1160/stk1160-core.c | 399 + drivers/media/video/stk1160/stk1160-i2c.c | 304 ++ drivers/media/video/stk1160/stk1160-reg.h | 78 +++ drivers/media/video/stk1160/stk1160-v4l.c | 846 +++ drivers/media/video/stk1160/stk1160-video.c | 506 drivers/media/video/stk1160/stk1160.h | 183 ++ 10 files changed, 2336 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/stk1160/Kconfig create mode 100644 drivers/media/video/stk1160/Makefile create mode 100644 drivers/media/video/stk1160/stk1160-core.c create mode 100644 drivers/media/video/stk1160/stk1160-i2c.c create mode 100644 drivers/media/video/stk1160/stk1160-reg.h create mode 100644 drivers/media/video/stk1160/stk1160-v4l.c create mode 100644 drivers/media/video/stk1160/stk1160-video.c create mode 100644 drivers/media/video/stk1160/stk1160.h + + /* + * We take the lock just before device registration, + * to prevent someone (probably udev) from opening us + * before we finish initialization + */ + mutex_init(dev-mutex); + mutex_lock(dev-mutex); + + rc = stk1160_video_register(dev); It's usually better to register the video node as the very last thing in probe(). That way when the node appears it's ready for udev to use. No need to lock the mutex in that case. Done. + /* + * Wait until all current v4l2 operation are finished + * then deallocate resources + */ + mutex_lock(dev-mutex); + + /* Since saa7115 is no longer present, it's better to unregister it */ + v4l2_device_unregister_subdev(dev-sd_saa7115); + + stk1160_stop_streaming(dev); + + v4l2_device_disconnect(dev-v4l2_dev); + + /* This way current users can detect device is gone */ + dev-udev = NULL; + + mutex_unlock(dev-mutex); + + stk1160_i2c_unregister(dev); + stk1160_video_unregister(dev); I recommend that you use the same approach as I did in media/radio/dsbr100.c: use the v4l2_dev-release callback to handle the final cleanup. That is a safe method that does all the refcounting for you. I'm sorry but I don't really see the difference. Right now I'm having video_device release function to handle the final cleanup. I don't do the refcounting myself either. See my other comment below. First of all, you can make it work reliably with just the video_device release(). But the advantage of using the release of v4l2_device is that it will also work with USB devices with multiple video/vbi/radio nodes and it allows you to put all the code in disconnect() under the lock. The disconnect call can happen at any time, so it can be hard to get it right. In the code above an application can open the video node right after the unlock and before i2c_unregister (which I would move to the release callback anyway). The clean up from i2c_unregister might cause problems for that new open. In practice it seems that the easiest approach is not to clean up anything in the disconnect, just take the lock, do the bare minimum necessary for the disconnect, unregister the video nodes, unlock and end with v4l2_device_put(v4l2_dev). It's a suggestion only, but experience has shown that it works well. And as I said, when you get multiple device nodes, then this is the only workable approach. Weren't there easycap devices with multiple video inputs? Or is that handled by cycling
Re: [PATCH v3 1/1] v4l: drop v4l2_buffer.input and V4L2_BUF_FLAG_INPUT
Hi Ezequiel, I'm just bringing this proposal to your attention as I am wondering how your driver (and the old easycap driver that your driver will replace) handle the easycap device with multiple inputs? Is it cycling through all inputs? In that case we might need the input field. Regards, Hans On Wed May 2 2012 14:40:03 Sakari Ailus wrote: Remove input field in struct v4l2_buffer and flag V4L2_BUF_FLAG_INPUT which tells the former is valid. The flag is used by no driver currently. Also change the documentation accordingly. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Hi, This is the third version of the v4l2_buffer.input field removal patch. What has changed since the previous version: - Rename input as reserved2 instead of combining it to reserved and making it an array. - cpia compile fix. - Change documentation accordingly. Documentation/DocBook/media/v4l/compat.xml |6 ++ Documentation/DocBook/media/v4l/io.xml | 19 +-- Documentation/DocBook/media/v4l/vidioc-qbuf.xml |9 +++-- drivers/media/video/cpia2/cpia2_v4l.c |2 +- drivers/media/video/v4l2-compat-ioctl32.c | 11 +-- drivers/media/video/videobuf-core.c | 16 drivers/media/video/videobuf2-core.c|5 ++--- include/linux/videodev2.h |3 +-- 8 files changed, 23 insertions(+), 48 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 87339b2..b939457 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2422,6 +2422,12 @@ details./para VIDIOC-SUBDEV-G-SELECTION; and VIDIOC-SUBDEV-S-SELECTION;./para /listitem + listitem + paraReplaced structfieldinput/structfield in + structnamev4l2_buffer/structname by + structfieldreserved2/structfield and removed + constantV4L2_BUF_FLAG_INPUT/constant./para + /listitem /orderedlist /section diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index b815929..e4cb063 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -681,14 +681,12 @@ memory, set by the application. See xref linkend=userp / for details. /row row entry__u32/entry - entrystructfieldinput/structfield/entry + entrystructfieldreserved2/structfield/entry entry/entry - entrySome video capture drivers support rapid and -synchronous video input changes, a function useful for example in -video surveillance applications. For this purpose applications set the -constantV4L2_BUF_FLAG_INPUT/constant flag, and this field to the -number of a video input as in v4l2-input; field -structfieldindex/structfield./entry + entryA place holder for future extensions and custom +(driver defined) buffer types +constantV4L2_BUF_TYPE_PRIVATE/constant and higher. Applications +should set this to 0./entry /row row entry__u32/entry @@ -921,13 +919,6 @@ Drivers set or clear this flag when the constantVIDIOC_DQBUF/constant ioctl is called./entry /row row - entryconstantV4L2_BUF_FLAG_INPUT/constant/entry - entry0x0200/entry - entryThe structfieldinput/structfield field is valid. -Applications set or clear this flag before calling the -constantVIDIOC_QBUF/constant ioctl./entry - /row - row entryconstantV4L2_BUF_FLAG_PREPARED/constant/entry entry0x0400/entry entryThe buffer has been prepared for I/O and can be queued by the diff --git a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml index 9caa49a..77ff5be 100644 --- a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml +++ b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml @@ -71,12 +71,9 @@ initialize the structfieldbytesused/structfield, structfieldfield/structfield and structfieldtimestamp/structfield fields, see xref linkend=buffer / for details. -Applications must also set structfieldflags/structfield to 0. If a driver -supports capturing from specific video inputs and you want to specify a video -input, then structfieldflags/structfield should be set to -constantV4L2_BUF_FLAG_INPUT/constant and the field -structfieldinput/structfield must be initialized to the desired input. -The structfieldreserved/structfield field must be set to 0. When using +Applications must also set structfieldflags/structfield to 0. +The structfieldreserved2/structfield and +structfieldreserved/structfield fields must be set to 0. When using the link linkend=planar-apismulti-planar API/link, the
[RFCv2 PATCH 0/5] Add hwseek caps and frequency bands
Changes since v1: - Fixed typo in second patch - Patch 5 now only contains the part about frequency bands - Patch 6 contains only (I hope) a non-controversial clarification regarding modulators (and a small change making a line more understandable). Regards, Hans This patch series adds improved hwseek support as discussed here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg45957.html and on irc: http://linuxtv.org/irc/v4l/index.php?date=2012-05-26 From the RFC I have implemented/documented items 1-4 and 6a. I decided not to go with option 6b. This may be added in the future if there is a clear need. The addition of the frequency band came out of this discussion: http://www.spinics.net/lists/linux-media/msg48272.html 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
[RFCv2 PATCH 1/6] videodev2.h: add new hwseek capability bits.
From: Hans Verkuil hans.verk...@cisco.com
Tell the application whether the hardware seek is bounded and/or wraps around.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Hans de Goede hdego...@redhat.com
---
include/linux/videodev2.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 370d111..2339678 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2039,6 +2039,8 @@ struct v4l2_modulator {
/* Flags for the 'capability' field */
#define V4L2_TUNER_CAP_LOW 0x0001
#define V4L2_TUNER_CAP_NORM0x0002
+#define V4L2_TUNER_CAP_HWSEEK_BOUNDED 0x0004
+#define V4L2_TUNER_CAP_HWSEEK_WRAP 0x0008
#define V4L2_TUNER_CAP_STEREO 0x0010
#define V4L2_TUNER_CAP_LANG2 0x0020
#define V4L2_TUNER_CAP_SAP 0x0020
--
1.7.10
--
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
[RFCv2 PATCH 4/6] videodev2.h: add frequency band information.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Hans de Goede hdego...@redhat.com
---
include/linux/videodev2.h | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 2339678..013ee46 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2023,7 +2023,8 @@ struct v4l2_tuner {
__u32 audmode;
__s32 signal;
__s32 afc;
- __u32 reserved[4];
+ __u32 band;
+ __u32 reserved[3];
};
struct v4l2_modulator {
@@ -2033,7 +2034,8 @@ struct v4l2_modulator {
__u32 rangelow;
__u32 rangehigh;
__u32 txsubchans;
- __u32 reserved[4];
+ __u32 band;
+ __u32 reserved[3];
};
/* Flags for the 'capability' field */
@@ -2048,6 +2050,11 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS 0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS0x0200
+#define V4L2_TUNER_CAP_BAND_FM_EUROPE_US 0x0001
+#define V4L2_TUNER_CAP_BAND_FM_JAPAN 0x0002
+#define V4L2_TUNER_CAP_BAND_FM_RUSSIAN 0x0004
+#define V4L2_TUNER_CAP_BAND_FM_WEATHER 0x0008
+#define V4L2_TUNER_CAP_BAND_AM_MW0x0010
/* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO0x0001
@@ -2065,6 +2072,14 @@ struct v4l2_modulator {
#define V4L2_TUNER_MODE_LANG1 0x0003
#define V4L2_TUNER_MODE_LANG1_LANG20x0004
+/* Values for the 'band' field */
+#define V4L2_TUNER_BAND_DEFAULT 0
+#define V4L2_TUNER_BAND_FM_EUROPE_US 1 /* 87.5 Mhz - 108 MHz */
+#define V4L2_TUNER_BAND_FM_JAPAN 2 /* 76 MHz - 90 MHz */
+#define V4L2_TUNER_BAND_FM_RUSSIAN3 /* 65.8 MHz - 74 MHz */
+#define V4L2_TUNER_BAND_FM_WEATHER4 /* 162.4 MHz - 162.55 MHz */
+#define V4L2_TUNER_BAND_AM_MW 5
+
struct v4l2_frequency {
__u32 tuner;
__u32 type; /* enum v4l2_tuner_type */
--
1.7.10
--
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
[RFCv2 PATCH 3/6] S_HW_FREQ_SEEK: set capability flags and return ENODATA instead of EAGAIN.
From: Hans Verkuil hans.verk...@cisco.com
Set the new capability flags in G_TUNER and return ENODATA if no channels
were found.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Hans de Goede hdego...@redhat.com
---
drivers/media/radio/radio-mr800.c|5 +++--
drivers/media/radio/radio-wl1273.c |3 ++-
drivers/media/radio/si470x/radio-si470x-common.c |6 --
drivers/media/radio/wl128x/fmdrv_rx.c|2 +-
drivers/media/radio/wl128x/fmdrv_v4l2.c |4 +++-
sound/i2c/other/tea575x-tuner.c |4 +++-
6 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/media/radio/radio-mr800.c
b/drivers/media/radio/radio-mr800.c
index 94cb6bc..3182b26 100644
--- a/drivers/media/radio/radio-mr800.c
+++ b/drivers/media/radio/radio-mr800.c
@@ -295,7 +295,8 @@ static int vidioc_g_tuner(struct file *file, void *priv,
v-type = V4L2_TUNER_RADIO;
v-rangelow = FREQ_MIN * FREQ_MUL;
v-rangehigh = FREQ_MAX * FREQ_MUL;
- v-capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO;
+ v-capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
+ V4L2_TUNER_CAP_HWSEEK_WRAP;
v-rxsubchans = is_stereo ? V4L2_TUNER_SUB_STEREO : V4L2_TUNER_SUB_MONO;
v-audmode = radio-stereo ?
V4L2_TUNER_MODE_STEREO : V4L2_TUNER_MODE_MONO;
@@ -372,7 +373,7 @@ static int vidioc_s_hw_freq_seek(struct file *file, void
*priv,
timeout = jiffies + msecs_to_jiffies(3);
for (;;) {
if (time_after(jiffies, timeout)) {
- retval = -EAGAIN;
+ retval = -ENODATA;
break;
}
if (schedule_timeout_interruptible(msecs_to_jiffies(10))) {
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
index f1b6070..e8428f5 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -1514,7 +1514,8 @@ static int wl1273_fm_vidioc_g_tuner(struct file *file,
void *priv,
tuner-rangehigh = WL1273_FREQ(WL1273_BAND_OTHER_HIGH);
tuner-capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_RDS |
- V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS_BLOCK_IO;
+ V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS_BLOCK_IO |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED | V4L2_TUNER_CAP_HWSEEK_WRAP;
if (radio-stereo)
tuner-audmode = V4L2_TUNER_MODE_STEREO;
diff --git a/drivers/media/radio/si470x/radio-si470x-common.c
b/drivers/media/radio/si470x/radio-si470x-common.c
index 969cf49..d485b79 100644
--- a/drivers/media/radio/si470x/radio-si470x-common.c
+++ b/drivers/media/radio/si470x/radio-si470x-common.c
@@ -363,7 +363,7 @@ stop:
/* try again, if timed out */
if (retval == 0 timed_out)
- return -EAGAIN;
+ return -ENODATA;
return retval;
}
@@ -596,7 +596,9 @@ static int si470x_vidioc_g_tuner(struct file *file, void
*priv,
strcpy(tuner-name, FM);
tuner-type = V4L2_TUNER_RADIO;
tuner-capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
- V4L2_TUNER_CAP_RDS | V4L2_TUNER_CAP_RDS_BLOCK_IO;
+ V4L2_TUNER_CAP_RDS | V4L2_TUNER_CAP_RDS_BLOCK_IO |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED |
+ V4L2_TUNER_CAP_HWSEEK_WRAP;
/* range limits */
switch ((radio-registers[SYSCONFIG2] SYSCONFIG2_BAND) 6) {
diff --git a/drivers/media/radio/wl128x/fmdrv_rx.c
b/drivers/media/radio/wl128x/fmdrv_rx.c
index 43fb722..3dd9fc0 100644
--- a/drivers/media/radio/wl128x/fmdrv_rx.c
+++ b/drivers/media/radio/wl128x/fmdrv_rx.c
@@ -251,7 +251,7 @@ again:
if (!timeleft) {
fmerr(Timeout(%d sec),didn't get tune ended int\n,
jiffies_to_msecs(FM_DRV_RX_SEEK_TIMEOUT) / 1000);
- return -ETIMEDOUT;
+ return -ENODATA;
}
int_reason = fmdev-irq_info.flag (FM_TUNE_COMPLETE | FM_BAND_LIMIT);
diff --git a/drivers/media/radio/wl128x/fmdrv_v4l2.c
b/drivers/media/radio/wl128x/fmdrv_v4l2.c
index 080b96a..49a11ec 100644
--- a/drivers/media/radio/wl128x/fmdrv_v4l2.c
+++ b/drivers/media/radio/wl128x/fmdrv_v4l2.c
@@ -285,7 +285,9 @@ static int fm_v4l2_vidioc_g_tuner(struct file *file, void
*priv,
tuner-rxsubchans = V4L2_TUNER_SUB_MONO | V4L2_TUNER_SUB_STEREO |
((fmdev-rx.rds.flag == FM_RDS_ENABLE) ? V4L2_TUNER_SUB_RDS : 0);
tuner-capability = V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS |
- V4L2_TUNER_CAP_LOW;
+ V4L2_TUNER_CAP_LOW |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED |
+ V4L2_TUNER_CAP_HWSEEK_WRAP;
tuner-audmode = (stereo_mono_mode ?
V4L2_TUNER_MODE_MONO :
[RFCv2 PATCH 2/6] v4l2 spec: document the new v4l2_tuner capabilities
From: Hans Verkuil hans.verk...@cisco.com Update the spec with the new capabilities and specify new error codes for S_HW_FREQ_SEEK. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Hans de Goede hdego...@redhat.com --- .../DocBook/media/v4l/vidioc-g-frequency.xml |6 ++ Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 12 .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml | 18 +++--- 3 files changed, 33 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml index 69c178a..40e58a4 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml @@ -135,6 +135,12 @@ bounds or the value in the structfieldtype/structfield field is wrong./para /listitem /varlistentry + varlistentry + termerrorcodeEBUSY/errorcode/term + listitem + paraA hardware seek is in progress./para + /listitem + /varlistentry /variablelist /refsect1 /refentry diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml index 62a1aa2..95d5371 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml @@ -276,6 +276,18 @@ can or must be switched. (B/G PAL tuners for example are typically not constantV4L2_TUNER_ANALOG_TV/constant tuners can have this capability./entry /row row + entryconstantV4L2_TUNER_CAP_HWSEEK_BOUNDED/constant/entry + entry0x0004/entry + entryIf set, then this tuner supports the hardware seek functionality + where the seek stops when it reaches the end of the frequency range./entry + /row + row + entryconstantV4L2_TUNER_CAP_HWSEEK_WRAP/constant/entry + entry0x0008/entry + entryIf set, then this tuner supports the hardware seek functionality + where the seek wraps around when it reaches the end of the frequency range./entry + /row + row entryconstantV4L2_TUNER_CAP_STEREO/constant/entry entry0x0010/entry entryStereo audio reception is supported./entry diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml index 407dfce..f4db44d 100644 --- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml +++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml @@ -58,6 +58,9 @@ To do this applications initialize the structfieldtuner/structfield, call the constantVIDIOC_S_HW_FREQ_SEEK/constant ioctl with a pointer to this structure./para +paraIf an error is returned, then the original frequency will +be restored./para + paraThis ioctl is supported if the constantV4L2_CAP_HW_FREQ_SEEK/constant capability is set./para table pgwide=1 frame=none id=v4l2-hw-freq-seek @@ -87,7 +90,10 @@ field and the v4l2-tuner; structfieldindex/structfield field./entry row entry__u32/entry entrystructfieldwrap_around/structfield/entry - entryIf non-zero, wrap around when at the end of the frequency range, else stop seeking./entry + entryIf non-zero, wrap around when at the end of the frequency range, else stop seeking. + The v4l2-tuner; structfieldcapability/structfield field will tell you what the + hardware supports. + /entry /row row entry__u32/entry @@ -118,9 +124,15 @@ wrong./para /listitem /varlistentry varlistentry - termerrorcodeEAGAIN/errorcode/term + termerrorcodeENODATA/errorcode/term + listitem + paraThe hardware seek found no channels./para + /listitem + /varlistentry + varlistentry + termerrorcodeEBUSY/errorcode/term listitem - paraThe ioctl timed-out. Try again./para + paraAnother hardware seek is already in progress./para /listitem /varlistentry /variablelist -- 1.7.10 -- 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
[RFCv2 PATCH 6/6] V4L2 spec: clarify a few modulator issues.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/common.xml | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml index 4101aeb..b91d253 100644 --- a/Documentation/DocBook/media/v4l/common.xml +++ b/Documentation/DocBook/media/v4l/common.xml @@ -464,14 +464,14 @@ The structfieldtype/structfield field of the respective structfieldtuner/structfield field contains the index number of the tuner./para - paraRadio devices have exactly one tuner with index zero, no + paraRadio input devices have exactly one tuner with index zero, no video inputs./para paraTo query and change tuner properties applications use the VIDIOC-G-TUNER; and VIDIOC-S-TUNER; ioctl, respectively. The v4l2-tuner; returned by constantVIDIOC_G_TUNER/constant also contains signal status information applicable when the tuner of the -current video input, or a radio tuner is queried. Note that +current video or radio input is queried. Note that constantVIDIOC_S_TUNER/constant does not switch the current tuner, when there is more than one at all. The tuner is solely determined by the current video input. Drivers must support both ioctls and set the @@ -491,8 +491,17 @@ the modulator. The structfieldtype/structfield field of the respective v4l2-output; returned by the VIDIOC-ENUMOUTPUT; ioctl is set to constantV4L2_OUTPUT_TYPE_MODULATOR/constant and its structfieldmodulator/structfield field contains the index number -of the modulator. This specification does not define radio output -devices./para +of the modulator./para + + paraRadio output devices have exactly one modulator with index +zero, no video outputs./para + + paraA video or radio device cannot support both a tuner and a +modulator. Two separate device nodes will have to be used for such +hardware, one that supports the tuner functionality and one that supports +the modulator functionality. The reason is a limitation with the +VIDIOC-S-FREQUENCY; ioctl where you cannot specify whether the frequency +is for a tuner or a modulator./para paraTo query and change modulator properties applications use the VIDIOC-G-MODULATOR; and VIDIOC-S-MODULATOR; ioctl. Note that -- 1.7.10 -- 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] file tree rearrangement - was: Re: [RFC PATCH 0/3] Improve Kconfig selection for media devices
Em 28-05-2012 06:42, Hans Verkuil escreveu: On Sun May 27 2012 22:15:08 Mauro Carvalho Chehab wrote: Em 27-05-2012 15:47, Andy Walls escreveu: Hans Verkuil hverk...@xs4all.nl wrote: On Sun May 27 2012 19:13:38 Mauro Carvalho Chehab wrote: Em 27-05-2012 13:56, Mauro Carvalho Chehab escreveu: The Kconfig building system is improperly selecting some drivers, like analog TV tuners even when this is not required. Rearrange the Kconfig in a way to prevent that. Mauro Carvalho Chehab (3): media: reorganize the main Kconfig items media: Remove VIDEO_MEDIA Kconfig option media: only show V4L devices based on device type selection drivers/media/Kconfig | 114 +++ drivers/media/common/tuners/Kconfig | 64 ++-- drivers/media/dvb/frontends/Kconfig |1 + drivers/media/radio/Kconfig |1 + drivers/media/rc/Kconfig| 29 - drivers/media/video/Kconfig | 76 +-- drivers/media/video/m5mols/Kconfig |1 + drivers/media/video/pvrusb2/Kconfig |1 - drivers/media/video/smiapp/Kconfig |1 + 9 files changed, 181 insertions(+), 107 deletions(-) The organization between DVB only, V4L only and hybrid devices are somewhat confusing on our tree. From time to time, someone proposes changing one driver from one place to another or complains that his device is DVB only but it is inside the V4L tree (and other similar requests). This sometimes happen because the same driver can support analog only, digital only or hybrid devices. Also, one driver may start as a DVB only or as a V4L only and then it can be latter be converted into an hybrid driver. So, the better is to rearrange the drivers tree, in order to fix this issue, removing them from /video and /dvb, and storing them on a better place. So, my proposal is to move all radio, analog TV, digital TV, webcams and grabber bridge drivers to this arrangement: drivers/media/isa - ISA drivers drivers/media/usb - USB drivers drivers/media/pci - PCI/PCIe drivers drivers/media/platform - platform drivers drivers/media/parport drivers/media/i2c Also, if we do this then I would really like to separate the sub-device drivers from the main drivers. I find it very messy that those are mixed. So: drivers/media/subdevs We might subdivide /subdevs even further (sensors, encoders, decoders, etc.) but I am not sure if that is worthwhile. Frankly, the current directory structure (other than the lack of a subdevs directory) doesn't bother me. But your proposal is a bit cleaner. Regards, Hans Comments? Regards, Mauro - PS.: for now, I don't intend to touch at I2C/ancillary drivers. We may latter move the i2c drivers that aren't frontend/tuners to media/i2c or to media/common. -- 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 Also cx2341x and tveeprom cx2341x is a sub-device module. So, it can go to drivers/media/subdevs (ok, it has other problems, but solving them is not as simple as moving things from one place to the other - so let's not mix it here). It's not a subdev. It's a helper module, so it should go to common (or 'helpers'). The case of tveeprom is different, because it is not really a sub-device. Btw, this file is bad named - it should be called hauppauge-eeprom or something like that. Yet, I wouldn't move it out of drivers/media/video (or at least on this first step). There are other similar cases. for example, btcx-risc is a common module used by both cx88 and bttv drivers to handle the RISC processor that exists on both. This is not a sub-device, so it won't fit on the above structure. . Maybe we can create a drivers/media/v4l2-core and move everything that belongs to the core into it, and the things that won't fit elsewhere can be moved into drivers/media/common. Ack. I would also move tuner, dvb-core and frontend to an upper level: So, in summary, the final structure would be: drivers/media /common - drivers that are common to several ones, like tveeprom and btcx-risc And saa7146 sources in /common/saa7146. That will (finally!) make sense. What can go in here: - saa7146 - tveeprom - cx2341x - btcx-risc - radio-isa - smiapp-pll (?) We should probably also try and get tea575x-tuner.c in here. But that can be done in a separate step. /dvb-core - what is already at dvb/dvb-core /frontends - what is already at dvb/frontends /isa- all ISA drivers /parport- all parallel port drivers I
Re: [RFCv2 PATCH 0/5] Add hwseek caps and frequency bands
Hi, Looks good, the entire series is: Acked-by: Hans de Goede hdego...@redhat.com I was thinking that it would be a good idea to add a: #define V4L2_TUNER_CAP_BANDS_MASK 0x001f to videodev2.h, which apps can then easily use to test if the driver supports any bands other then the default, and decide to show band selection elements of the UI or not based on a test on the tuner-caps using that mask. This can be done in a separate patch, or merged into PATCH 4/6 videodev2.h: add frequency band information Regards, Hans On 05/28/2012 12:46 PM, Hans Verkuil wrote: Changes since v1: - Fixed typo in second patch - Patch 5 now only contains the part about frequency bands - Patch 6 contains only (I hope) a non-controversial clarification regarding modulators (and a small change making a line more understandable). Regards, Hans This patch series adds improved hwseek support as discussed here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg45957.html and on irc: http://linuxtv.org/irc/v4l/index.php?date=2012-05-26 From the RFC I have implemented/documented items 1-4 and 6a. I decided not to go with option 6b. This may be added in the future if there is a clear need. The addition of the frequency band came out of this discussion: http://www.spinics.net/lists/linux-media/msg48272.html 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: [RFC PATCH 0/3] Improve Kconfig selection for media devices
Em 28-05-2012 06:48, Stefan Richter escreveu: On May 27 Mauro Carvalho Chehab wrote: The Kconfig building system is improperly selecting some drivers, like analog TV tuners even when this is not required. Rearrange the Kconfig in a way to prevent that. Mauro Carvalho Chehab (3): media: reorganize the main Kconfig items media: Remove VIDEO_MEDIA Kconfig option media: only show V4L devices based on device type selection On 1/3 media: reorganize the main Kconfig items: a) I agree with Sylvester that the MEDIA_WEBCAM_SUPP variable, prompt text, and help text should be worded a bit more general. Wouldn't this variable also cover industrial cameras and who knows what other kinds of video inputs? I also agree with Sylvester about the SUPP vs. SUPPORT thing. b) Small typo in the MEDIA_ANALOG_TV_SUPP help text: of - or. Ok, fixed both above issues. I'll post a version 2 patch series soon. c) The RC_CORE_SUPP help text gives the impression that RC core is always needed if there is hardware with an IR feature. But the firedtv driver is a case where the driver directly works on top of the input subsystem rather than on RC core. Maybe there are more such cases. All other drivers use RC_CORE, as we've replaced the existing implementations to use it, removing bad/inconsistent IR code implementations everywhere. The only driver left is firedtv. (Currently we don't ask whether FireDTV owners want IR support; we silently build the IR part of firedtv in if CONFIG_INPUT is set, and silently omit the IR part of firedtv if CONFIG_INPUT was disabled, which requires CONFIG_EXPERT.) How about turning the Remote Controller support option into merely a filter for standalone IR and RF receivers and transmitters, whereas Kconfig options in the analog and digital TV categories silently do select RC_CORE if INPUT for combined tuner + IR/RF rx/tx hardware? The right thing to do is to convert drivers/media/dvb/firewire/firedtv-rc.c to use rc-core. There are several issues with the current implementation: - IR keycode tables are hardcoded; - There is a magic to convert a 16 bits scancode (NEC protocol?) into a key; - There's no way to replace the existing table to an user-provided one; - The IR userspace tools won't work, as it doesn't export the needed sysfs nodes to report an IR. If you want, I can write a patch doing that, but I can't test it here, as I don't have a firedtv device. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] file tree rearrangement - was: Re: [RFC PATCH 0/3] Improve Kconfig selection for media devices
On Mon May 28 2012 13:03:42 Mauro Carvalho Chehab wrote: Em 28-05-2012 06:42, Hans Verkuil escreveu: On Sun May 27 2012 22:15:08 Mauro Carvalho Chehab wrote: ... /dvb-core - what is already at dvb/dvb-core /frontends - what is already at dvb/frontends /isa- all ISA drivers /parport- all parallel port drivers I propose to replace /parport with a /others directory for things of which we have only a very few (parport, i2c) or are hard to classify (si470x, vivi, mem2mem_testdev). It makes sense to group those drivers that use other buses together. However, the term 'other' could have other meanings than other bus or other drivers. I think other-bus could be an appropriate name for that. OK. /media-core for the media*.c sources. media-core is a very bad name, as media is the name of the subsystem. maybe media-ctrl-core or something similar. mc-core? After doing that, the Kconfig options at isa, parport, pci, platform and usb can be optimized further, based on the media support filters: m Multimedia support --- [ ] Webcams and video grabbers support [ ] Analog TV support [ ] Digital TV support [ ] AM/FM radio receivers/transmitters support [ ] Remote Controller support One thing wasn't clear to me: if I have a hybrid device I gathered that it be enabled only if both analog and digital are set, right? But is that also true for radio and RC support? So if I have a card with all of the above, will it be enabled only if I check all four items? No. The tendency is to break drivers into RC support, analog TV support and DVB support. There are several requirements for that, and it actually makes sense to allow disabling what's not needed. So, the idea here is that, if only analog TV is selected, only the analog part of a board will be enabled. For example, if you select only analog TV, this is how the USB menu will show, for em28xx: --- V4L USB devices *** Webcam and/or TV USB devices *** Empia EM28xx USB video capture support (NEW) (em28xx has the RC part and the DTV part as separate Kconfig options) Currently, radio will be enabled together with em28xx, but it would be easy to add a logic inside em28xx-video to disable radio, if RADIO_SUPPORT is disabled. Unfortunately, all hybrid drivers currently require analog TV, although most of them implements the analog support on a separate file (foo-video.c). It shouldn't be hard and it makes sense to split hybrid drivers into a core driver, an analog driver, rc driver and a dvb driver. I don't think it makes sense to split radio into a separate driver, but it shouldn't be hard to do that too. OK, I misunderstood your original description. This is actually one of the issues I want to solve: there are several em28xx devices that don't support analog TV at all. Yet, V4L2 is not selected, the driver won't even appear to the user. Of course, just renaming the directories won't help with hybrid cards itself. A further work is required on each hybrid drivers. That doesn't really make sense to me. I think the average end-user just cares about the hardware that he wants to enable, and if a hybrid device is selected, then that should select all the various core configs that it needs. Not the other way around. We can add an option for hybrid TV support that would enable all 4 cores, in order to help the average end-user, although I don't think he would have any troubles to understand that, if his board has analog TV, digital TV and Remote Controller, that all those 3 options need to be selected, for full device support. Another thing: I would move 'video grabber' away from webcams and to 'Analog TV/Video support'. And rename 'Digital TV' to 'Digital TV/Video' as well. A video grabber driver has much more to do with TV then it does with webcams. From the Kconfig perspective, the difference between the 3 video categories is that: - analog TV: tuner-core is required, and 10 other tuner drivers that are listed inside tuner core; - digital TV: tuners are needed, but those are either customised or auto-selected; - camera/grabber: no tuner is needed. Also, there are several professional camera devices at bttv, cx88, saa7134 and cx25821 that don't require tuners, and support for them can be compiled without tuner support. In other words, a camera driver and a grabber driver are very similar. Of course, a webcam will also require a sensor (on several drivers, the sensor is internal to the driver, so no extra modules are needed). Of course, a platform camera driver will also require media controller, subdev API, but those features are already enabled via other config options. So, from tuners' perspective, and from Kconfig's perspective, a video grabber is just like a
Re: [GIT PULL FOR v3.5] Move sta2x11_vip to staging
On Mon May 28 2012 13:47:43 Federico Vaga wrote: I didn't get any reply from Federico when I posted my concerns last week, so that makes me unhappy as well. I hope the author will fix these issues, but in the meantime this will move it to staging waiting for further developments. The last time I worked on this device was 2 month and half ago (RFC time) and before answer Ok, I'll fix it I'm trying to understand if me or someone else will do that work. I'll provide a better answer than this when I have more information. Sorry for not sending an ack immediately, but be reassured that I'm still on the hardware and following the developments. Thank you for the feedback! Suddenly I feel a lot happier :-) You were just unlucky that you posted the driver just in a period where I was almost completely absent from the list due to personal circumstances. Otherwise you would have gotten the feedback at that time. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/1] v4l: drop v4l2_buffer.input and V4L2_BUF_FLAG_INPUT
Hi Hans, On Mon, May 28, 2012 at 7:27 AM, Hans Verkuil hverk...@xs4all.nl wrote: Hi Ezequiel, I'm just bringing this proposal to your attention as I am wondering how your driver (and the old easycap driver that your driver will replace) handle the easycap device with multiple inputs? Is it cycling through all inputs? In that case we might need the input field. I've been delaying the multiple input device handling because: 1) I wanted to understand the simpler case first, and 2) I didn't actually own the device (I've bought it a few days ago). So, I'm gonna take a look at it and let you all now, as soon as possible. Thanks, Ezequiel. -- 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: [RFCv2 PATCH 0/5] Add hwseek caps and frequency bands
On Mon May 28 2012 13:20:47 Hans de Goede wrote: Hi, Looks good, the entire series is: Acked-by: Hans de Goede hdego...@redhat.com I was thinking that it would be a good idea to add a: #define V4L2_TUNER_CAP_BANDS_MASK 0x001f to videodev2.h, which apps can then easily use to test if the driver supports any bands other then the default, and decide to show band selection elements of the UI or not based on a test on the tuner-caps using that mask. This can be done in a separate patch, or merged into PATCH 4/6 videodev2.h: add frequency band information Good idea, I've merged it into patch 4 and 5 (documenting it). It's here: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/bands Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] file tree rearrangement - was: Re: [RFC PATCH 0/3] Improve Kconfig selection for media devices
Em 28-05-2012 08:45, Hans Verkuil escreveu: On Mon May 28 2012 13:03:42 Mauro Carvalho Chehab wrote: Em 28-05-2012 06:42, Hans Verkuil escreveu: On Sun May 27 2012 22:15:08 Mauro Carvalho Chehab wrote: skip/ /media-core for the media*.c sources. media-core is a very bad name, as media is the name of the subsystem. maybe media-ctrl-core or something similar. mc-core? Ok. skip/ Another thing: I would move 'video grabber' away from webcams and to 'Analog TV/Video support'. And rename 'Digital TV' to 'Digital TV/Video' as well. A video grabber driver has much more to do with TV then it does with webcams. From the Kconfig perspective, the difference between the 3 video categories is that: - analog TV: tuner-core is required, and 10 other tuner drivers that are listed inside tuner core; - digital TV: tuners are needed, but those are either customised or auto-selected; - camera/grabber: no tuner is needed. Also, there are several professional camera devices at bttv, cx88, saa7134 and cx25821 that don't require tuners, and support for them can be compiled without tuner support. In other words, a camera driver and a grabber driver are very similar. Of course, a webcam will also require a sensor (on several drivers, the sensor is internal to the driver, so no extra modules are needed). Of course, a platform camera driver will also require media controller, subdev API, but those features are already enabled via other config options. So, from tuners' perspective, and from Kconfig's perspective, a video grabber is just like a professional camera driver, a cellphone camera or a webcam driver. I would never have understood that from the menu names. In particular that 'Analog TV' implies a tuner. For me it could just as well imply a composite input video grabber. (the discussion below is a little OT for file rearrangement - It belongs to the Kconfig selection patches - I'm about to post a version 2 of it) Can you use analog TV without a tuner? ;) Analog TV is a clear concept for the end user: it is something that allows tuning a channel and watch it. So, enabling this feature should enable both functionality. For us, this term causes some confusion as we generally use both analog TV and V4L2 to refer to the same thing. How about this: [ ] Video (aka V4L2) support DVB is also video. Also Radio is also V4L2 support. So, this seems confusing. [ ] Digital TV Tuner (aka DVB) support On both above, I don't like the idea of using an acronym, as it limits the scope. DVB, btw, is a bad name for the user interface, as users with other digital standards like ATSC may not select it, as they don't have DVB standard. Also, calling it as tuner also limits the scope and, worse than that, enforces the idea to the user to call the entire device as tuner (ok, some manufacturers do that, but, for us, when someone reports a problem at the tuner, we genrally think about the PLL, and not about the entire device). [ ] Analog TV Tuner support [ ] Radio Tuner/Modulator support [ ] Remote Controller support I didn't like the term 'Webcams and video grabbers' as that description is never 100%. The help text can clarify this in more detail, of course. At version 2, I renamed it to: Cameras/video grabbers support. Maybe we can use video capture devices instead of video grabbers to be even more clearer. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] Improve Kconfig selection for media devices
On May 28 Mauro Carvalho Chehab wrote: Em 28-05-2012 06:48, Stefan Richter escreveu: c) The RC_CORE_SUPP help text gives the impression that RC core is always needed if there is hardware with an IR feature. But the firedtv driver is a case where the driver directly works on top of the input subsystem rather than on RC core. Maybe there are more such cases. All other drivers use RC_CORE, as we've replaced the existing implementations to use it, removing bad/inconsistent IR code implementations everywhere. The only driver left is firedtv. [...] The right thing to do is to convert drivers/media/dvb/firewire/firedtv-rc.c to use rc-core. There are several issues with the current implementation: - IR keycode tables are hardcoded; - There is a magic to convert a 16 bits scancode (NEC protocol?) into a key; - There's no way to replace the existing table to an user-provided one; There are two tables: An old mapping and a new mapping. The new mapping is copied into a newly allocated writable array. It should be possible to overwrite this array by means of EVIOCSKEYCODE ioctls. If I remember correctly, the firedtv driver sources came only with the old mapping table when they were submitted for upstream merge. When I helped to clean up the driver, I noticed that the two FireDTV C/CI and T/CI (which I newly purchased at the time as test devices) emitted entirely different scan codes than what the sources suggested. I suppose the original driver sources were written against older firmware or maybe older hardware revisions, possibly even prototype hardware. We would have to get hold of the original authors if we wanted to find out. Anyway, I implemented the new scancode-keycode mapping in a way that followed Dimitry's (?) review advice at that time, but left the old immutable mapping in there as fallback if an old scancode was received. If it is a burden, we could rip out the old table and see if anybody complains. - The IR userspace tools won't work, as it doesn't export the needed sysfs nodes to report an IR. But at least keypad/ keyboard related userspace should work. If you want, I can write a patch doing that, but I can't test it here, as I don't have a firedtv device. I can test such a patch as spare time permits if you point me to particular tools that I should test. -- Stefan Richter -=-===-- -=-= ===-- http://arcgraph.de/sr/ -- 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 PATCHv2 0/3] Improve Kconfig selection for media devices
The Kconfig building system is improperly selecting some drivers, like analog TV tuners even when this is not required. Rearrange the Kconfig in a way to prevent that. v2: Some fixups at the first patch (typos, renames). Other patches got rebased due to that. Mauro Carvalho Chehab (3): [media] media: reorganize the main Kconfig items [media] media: Remove VIDEO_MEDIA Kconfig option [media] media: only show V4L devices based on device type selection drivers/media/Kconfig | 113 +++ drivers/media/common/tuners/Kconfig | 64 ++-- drivers/media/dvb/frontends/Kconfig |1 + drivers/media/radio/Kconfig |1 + drivers/media/rc/Kconfig| 29 - drivers/media/video/Kconfig | 76 +-- drivers/media/video/m5mols/Kconfig |1 + drivers/media/video/pvrusb2/Kconfig |1 - drivers/media/video/smiapp/Kconfig |1 + 9 files changed, 180 insertions(+), 107 deletions(-) -- 1.7.8 -- 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 PATCHv2 1/3] [media] media: reorganize the main Kconfig items
Change the main items to: m Multimedia support --- [ ] Cameras/video grabbers support [ ] Analog TV support [ ] Digital TV support [ ] AM/FM radio receivers/transmitters support [ ] Remote Controller support This provides an interface that is clearer to end users that are compiling the Kernel, and will allow the building system to automatically unselect drivers for unused functions. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/Kconfig | 109 +++--- drivers/media/common/tuners/Kconfig |1 + drivers/media/dvb/frontends/Kconfig |1 + drivers/media/rc/Kconfig| 29 - 4 files changed, 89 insertions(+), 51 deletions(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 9575db4..323b2f0 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -6,20 +6,82 @@ menuconfig MEDIA_SUPPORT tristate Multimedia support depends on HAS_IOMEM help - If you want to use Video for Linux, DVB for Linux, or DAB adapters, + If you want to use Webcams, Video grabber devices and/or TV devices enable this option and other options below. + Additional info and docs are available on the web at + http://linuxtv.org if MEDIA_SUPPORT comment Multimedia core support # +# Multimedia support - automatically enable V4L2 and DVB core +# +config MEDIA_CAMERA_SUPPORT + bool Cameras/video grabbers support + ---help--- + Enable support for webcams and video grabbers. + + Say Y when you have a webcam or a video capture grabber board. + +config MEDIA_ANALOG_TV_SUPPORT + bool Analog TV support + ---help--- + Enable analog TV support. + + Say Y when you have a TV board with analog support or with a + hybrid analog/digital TV chipset. + + Note: There are several DVB cards that are based on chips that + support both analog and digital TV. Disabling this option + will disable support for them. + +config MEDIA_DIGITAL_TV_SUPPORT + bool Digital TV support + ---help--- + Enable digital TV support. + + Say Y when you have a board with digital support or a board with + hybrid digital TV and analog TV. + +config MEDIA_RADIO_SUPPORT + bool AM/FM radio receivers/transmitters support + ---help--- + Enable AM/FM radio support. + + Additional info and docs are available on the web at + http://linuxtv.org + + Say Y when you have a board with radio support. + + Note: There are several TV cards that are based on chips that + support radio reception. Disabling this option will + disable support for them. + +menuconfig MEDIA_RC_SUPPORT + bool Remote Controller support + depends on INPUT + ---help--- + Enable support for Remote Controllers on Linux. This is + needed in order to support several video capture adapters, + standalone IR receivers/transmitters, and RF receivers. + + Enable this option if you have a video capture board even + if you don't need IR, as otherwise, you may not be able to + compile the driver for your adapter. + + Say Y when you have a TV or an IR device. + +# # Media controller +# Selectable only for webcam/grabbers, as other drivers don't use it # config MEDIA_CONTROLLER bool Media Controller API (EXPERIMENTAL) depends on EXPERIMENTAL + depends on MEDIA_CAMERA_SUPPORT ---help--- Enable the media controller API used to query media devices internal topology and configure it dynamically. @@ -27,26 +89,15 @@ config MEDIA_CONTROLLER This API is mostly used by camera interfaces in embedded platforms. # -# V4L core and enabled API's +# Video4Linux support +# Only enables if one of the V4L2 types (ATV, webcam, radio) is selected # config VIDEO_DEV - tristate Video For Linux - ---help--- - V4L core support for video capture and overlay devices, webcams and - AM/FM radio cards. - - This kernel includes support for the new Video for Linux Two API, - (V4L2). - - Additional info and docs are available on the web at - http://linuxtv.org - - Documentation for V4L2 is also available on the web at - http://bytesex.org/v4l/. - - To compile this driver as a module, choose M here: the - module will be called videodev. + tristate + depends on MEDIA_SUPPORT + depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || MEDIA_RADIO_SUPPORT + default y config VIDEO_V4L2_COMMON tristate @@ -64,25 +115,15 @@ config VIDEO_V4L2_SUBDEV_API # # DVB Core +# Only enables if one of DTV is selected # config DVB_CORE - tristate DVB for Linux +
[RFC PATCHv2 3/3] [media] media: only show V4L devices based on device type selection
After this patch, the MEDIA*_SUPPORT will be used as a filter, exposing only devices that are pertinent to one of the 3 V4L types: webcam/grabber, radio, analog TV. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/radio/Kconfig|1 + drivers/media/video/Kconfig| 76 ++- drivers/media/video/m5mols/Kconfig |1 + drivers/media/video/smiapp/Kconfig |1 + 4 files changed, 59 insertions(+), 20 deletions(-) diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index c257da1..24ce5a4 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -5,6 +5,7 @@ menuconfig RADIO_ADAPTERS bool Radio Adapters depends on VIDEO_V4L2 + depends on MEDIA_RADIO_SUPPORT default y ---help--- Say Y here to enable selecting AM/FM radio adapters. diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 99937c9..da363c4 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -5,7 +5,7 @@ config VIDEO_V4L2 tristate depends on VIDEO_DEV VIDEO_V4L2_COMMON - default VIDEO_DEV VIDEO_V4L2_COMMON + default y config VIDEOBUF_GEN tristate @@ -73,6 +73,7 @@ config VIDEOBUF2_DMA_SG menuconfig VIDEO_CAPTURE_DRIVERS bool Video capture adapters depends on VIDEO_V4L2 + depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT default y ---help--- Say Y here to enable selecting the video adapters for @@ -478,6 +479,7 @@ config VIDEO_SMIAPP_PLL config VIDEO_OV7670 tristate OmniVision OV7670 sensor support depends on I2C VIDEO_V4L2 + depends on MEDIA_CAMERA_SUPPORT ---help--- This is a Video4Linux2 sensor-level driver for the OmniVision OV7670 VGA camera. It currently only works with the M88ALP01 @@ -486,6 +488,7 @@ config VIDEO_OV7670 config VIDEO_VS6624 tristate ST VS6624 sensor support depends on VIDEO_V4L2 I2C + depends on MEDIA_CAMERA_SUPPORT ---help--- This is a Video4Linux2 sensor-level driver for the ST VS6624 camera. @@ -496,6 +499,7 @@ config VIDEO_VS6624 config VIDEO_MT9M032 tristate MT9M032 camera sensor support depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + depends on MEDIA_CAMERA_SUPPORT select VIDEO_APTINA_PLL ---help--- This driver supports MT9M032 camera sensors from Aptina, monochrome @@ -504,6 +508,7 @@ config VIDEO_MT9M032 config VIDEO_MT9P031 tristate Aptina MT9P031 support depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + depends on MEDIA_CAMERA_SUPPORT select VIDEO_APTINA_PLL ---help--- This is a Video4Linux2 sensor-level driver for the Aptina @@ -512,6 +517,7 @@ config VIDEO_MT9P031 config VIDEO_MT9T001 tristate Aptina MT9T001 support depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + depends on MEDIA_CAMERA_SUPPORT ---help--- This is a Video4Linux2 sensor-level driver for the Aptina (Micron) mt0t001 3 Mpixel camera. @@ -519,6 +525,7 @@ config VIDEO_MT9T001 config VIDEO_MT9V011 tristate Micron mt9v011 sensor support depends on I2C VIDEO_V4L2 + depends on MEDIA_CAMERA_SUPPORT ---help--- This is a Video4Linux2 sensor-level driver for the Micron mt0v011 1.3 Mpixel camera. It currently only works with the @@ -527,6 +534,7 @@ config VIDEO_MT9V011 config VIDEO_MT9V032 tristate Micron MT9V032 sensor support depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + depends on MEDIA_CAMERA_SUPPORT ---help--- This is a Video4Linux2 sensor-level driver for the Micron MT9V032 752x480 CMOS sensor. @@ -534,6 +542,7 @@ config VIDEO_MT9V032 config VIDEO_TCM825X tristate TCM825x camera sensor support depends on I2C VIDEO_V4L2 + depends on MEDIA_CAMERA_SUPPORT ---help--- This is a driver for the Toshiba TCM825x VGA camera sensor. It is used for example in Nokia N800. @@ -541,12 +550,14 @@ config VIDEO_TCM825X config VIDEO_SR030PC30 tristate Siliconfile SR030PC30 sensor support depends on I2C VIDEO_V4L2 + depends on MEDIA_CAMERA_SUPPORT ---help--- This driver supports SR030PC30 VGA camera from Siliconfile config VIDEO_NOON010PC30 tristate Siliconfile NOON010PC30 sensor support depends on I2C VIDEO_V4L2 EXPERIMENTAL VIDEO_V4L2_SUBDEV_API + depends on MEDIA_CAMERA_SUPPORT ---help--- This driver supports NOON010PC30 CIF camera from Siliconfile @@ -554,6 +565,7 @@ source drivers/media/video/m5mols/Kconfig config VIDEO_S5K6AA tristate Samsung S5K6AAFX sensor support + depends on MEDIA_CAMERA_SUPPORT depends on I2C VIDEO_V4L2
[RFC PATCHv2 2/3] [media] media: Remove VIDEO_MEDIA Kconfig option
In the past, it was possible to have either DVB or V4L2 core as module and the other as builtin. Such config never make much sense, and created several issues in order to make the Kconfig dependency to work, as all drivers that depend on both (most TV drivers) would need to be compiled as 'm'. Due to that, the VIDEO_MEDIA config option were added. Instead of such weird approach, let's just use the MEDIA_SUPPORT =y or =m to select if the media subsystem core will be either builtin or module, simplifying the building system logic. Also, fix the tuners configuration, by enabling them only if a tuner is required. So, if just webcam/grabbers support is selected, no tuner option will be selected. Also, if only digital TV is selected, no analog tuner support is selected. That removes the need of using EXPERT customise options, when analog TV is not selected. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/Kconfig |4 -- drivers/media/common/tuners/Kconfig | 63 ++- drivers/media/video/pvrusb2/Kconfig |1 - 3 files changed, 32 insertions(+), 36 deletions(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 323b2f0..6d10ccb 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -138,10 +138,6 @@ config DVB_NET You may want to disable the network support on embedded devices. If unsure say Y. -config VIDEO_MEDIA - tristate - default (DVB_CORE (VIDEO_DEV = n)) || (VIDEO_DEV (DVB_CORE = n)) || (DVB_CORE VIDEO_DEV) - source drivers/media/common/Kconfig source drivers/media/rc/Kconfig diff --git a/drivers/media/common/tuners/Kconfig b/drivers/media/common/tuners/Kconfig index 16ee1a4..94c6ff7 100644 --- a/drivers/media/common/tuners/Kconfig +++ b/drivers/media/common/tuners/Kconfig @@ -1,6 +1,6 @@ config MEDIA_ATTACH bool Load and attach frontend and tuner driver modules as needed - depends on VIDEO_MEDIA + depends on MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT || MEDIA_RADIO_SUPPORT depends on MODULES default y if !EXPERT help @@ -20,15 +20,15 @@ config MEDIA_ATTACH config MEDIA_TUNER tristate - default VIDEO_MEDIA I2C - depends on VIDEO_MEDIA I2C + depends on (MEDIA_ANALOG_TV_SUPPORT || MEDIA_RADIO_SUPPORT) I2C + default y select MEDIA_TUNER_XC2028 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_XC5000 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_XC4000 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_MT20XX if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_TDA8290 if !MEDIA_TUNER_CUSTOMISE - select MEDIA_TUNER_TEA5761 if !MEDIA_TUNER_CUSTOMISE EXPERIMENTAL - select MEDIA_TUNER_TEA5767 if !MEDIA_TUNER_CUSTOMISE + select MEDIA_TUNER_TEA5761 if !MEDIA_TUNER_CUSTOMISE MEDIA_RADIO_SUPPORT EXPERIMENTAL + select MEDIA_TUNER_TEA5767 if !MEDIA_TUNER_CUSTOMISE MEDIA_RADIO_SUPPORT select MEDIA_TUNER_SIMPLE if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_TDA9887 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_MC44S803 if !MEDIA_TUNER_CUSTOMISE @@ -48,10 +48,11 @@ config MEDIA_TUNER_CUSTOMISE menu Customize TV tuners visible if MEDIA_TUNER_CUSTOMISE + depends on MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT || MEDIA_RADIO_SUPPORT config MEDIA_TUNER_SIMPLE tristate Simple tuner support - depends on VIDEO_MEDIA I2C + depends on MEDIA_SUPPORT I2C select MEDIA_TUNER_TDA9887 default m if MEDIA_TUNER_CUSTOMISE help @@ -59,7 +60,7 @@ config MEDIA_TUNER_SIMPLE config MEDIA_TUNER_TDA8290 tristate TDA 8290/8295 + 8275(a)/18271 tuner combo - depends on VIDEO_MEDIA I2C + depends on MEDIA_SUPPORT I2C select MEDIA_TUNER_TDA827X select MEDIA_TUNER_TDA18271 default m if MEDIA_TUNER_CUSTOMISE @@ -68,21 +69,21 @@ config MEDIA_TUNER_TDA8290 config MEDIA_TUNER_TDA827X tristate Philips TDA827X silicon tuner - depends on VIDEO_MEDIA I2C + depends on MEDIA_SUPPORT I2C default m if MEDIA_TUNER_CUSTOMISE help A DVB-T silicon tuner module. Say Y when you want to support this tuner. config MEDIA_TUNER_TDA18271 tristate NXP TDA18271 silicon tuner - depends on VIDEO_MEDIA I2C + depends on MEDIA_SUPPORT I2C default m if MEDIA_TUNER_CUSTOMISE help A silicon tuner module. Say Y when you want to support this tuner. config MEDIA_TUNER_TDA9887 tristate TDA 9885/6/7 analog IF demodulator - depends on VIDEO_MEDIA I2C + depends on MEDIA_SUPPORT I2C default m if MEDIA_TUNER_CUSTOMISE help Say Y here to include support for Philips TDA9885/6/7 @@ -90,7 +91,7 @@ config MEDIA_TUNER_TDA9887 config MEDIA_TUNER_TEA5761 tristate TEA 5761 radio tuner (EXPERIMENTAL) -
Re: [RFC PATCH 0/3] Improve Kconfig selection for media devices
Em 28-05-2012 09:17, Stefan Richter escreveu:
On May 28 Mauro Carvalho Chehab wrote:
Em 28-05-2012 06:48, Stefan Richter escreveu:
c) The RC_CORE_SUPP help text gives the impression that RC core is
always needed if there is hardware with an IR feature. But the firedtv
driver is a case where the driver directly works on top of the input
subsystem rather than on RC core. Maybe there are more such cases.
All other drivers use RC_CORE, as we've replaced the existing implementations
to use it, removing bad/inconsistent IR code implementations everywhere.
The only driver left is firedtv.
[...]
The right thing to do is to convert drivers/media/dvb/firewire/firedtv-rc.c
to use rc-core. There are several issues with the current implementation:
- IR keycode tables are hardcoded;
- There is a magic to convert a 16 bits scancode (NEC protocol?)
into a key;
- There's no way to replace the existing table to an user-provided
one;
There are two tables: An old mapping and a new mapping. The new mapping
is copied into a newly allocated writable array. It should be possible to
overwrite this array by means of EVIOCSKEYCODE ioctls.
You can replace, but only if the keycode is inside the 0x0300-0x031f or 0x45xx
range:
void fdtv_handle_rc(struct firedtv *fdtv, unsigned int code)
{
...
if (code = 0x0300 code = 0x031f)
code = keycode[code - 0x0300];
else if (code = 0x0340 code = 0x0354)
code = keycode[code - 0x0320];
else if (code = 0x4501 code = 0x451f)
code = oldtable[code - 0x4501];
else if (code = 0x4540 code = 0x4542)
code = oldtable[code - 0x4521];
else {
printk(KERN_DEBUG firedtv: invalid key code 0x%04x
from remote control\n, code);
return;
}
So, you can't, for example, get some other NEC remote controller and
use it there.
Also, the userspace IR tool won't recognize it as an IR, so the existing
tables at userspace can't be loaded.
If I remember correctly, the firedtv driver sources came only with the old
mapping table when they were submitted for upstream merge. When I helped
to clean up the driver, I noticed that the two FireDTV C/CI and T/CI (which
I newly purchased at the time as test devices) emitted entirely different
scan codes than what the sources suggested. I suppose the original driver
sources were written against older firmware or maybe older hardware
revisions, possibly even prototype hardware. We would have to get hold of
the original authors if we wanted to find out.
It is very common to the vendors to replace the remote controllers that
are shipped together with the device.
Also, several advanced users prefer to not use the IR provided by the
vendor, but to use other IR's, assigning other keys to the driver to allow
them to control more things on their systems.
Anyway, I implemented the new scancode-keycode mapping in a way that
followed Dimitry's (?) review advice at that time, but left the old
immutable mapping in there as fallback if an old scancode was received.
The newer way you used only works fine if the scancode table is not
sparsed. That's why you needed to remove the higher bits on your RC
handling code, generating a table with 34 elements.
The RC core dynamically allocates the scancode table in runtime, allowing
users to use very big or very short scan tables. It also doesn't waste
space with sparsed keycodes.
Users can even merge several different keytables together, in order to
allow the device to be used by different remote controllers, at the
same time.
If it is a burden, we could rip out the old table and see if anybody
complains.
- The IR userspace tools won't work, as it doesn't export the
needed sysfs nodes to report an IR.
But at least keypad/ keyboard related userspace should work.
If you want, I can write a patch doing that, but I can't test it here, as
I don't have a firedtv device.
I can test such a patch as spare time permits if you point me to particular
tools that I should test.
Ok, I'll write a patch for you to test.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv2 1/3] [media] media: reorganize the main Kconfig items
On Mon May 28 2012 14:17:47 Mauro Carvalho Chehab wrote: Change the main items to: m Multimedia support --- [ ] Cameras/video grabbers support [ ] Analog TV support [ ] Digital TV support [ ] AM/FM radio receivers/transmitters support [ ] Remote Controller support This provides an interface that is clearer to end users that are compiling the Kernel, and will allow the building system to automatically unselect drivers for unused functions. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/Kconfig | 109 +++--- drivers/media/common/tuners/Kconfig |1 + drivers/media/dvb/frontends/Kconfig |1 + drivers/media/rc/Kconfig| 29 - 4 files changed, 89 insertions(+), 51 deletions(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 9575db4..323b2f0 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -6,20 +6,82 @@ menuconfig MEDIA_SUPPORT tristate Multimedia support depends on HAS_IOMEM help - If you want to use Video for Linux, DVB for Linux, or DAB adapters, + If you want to use Webcams, Video grabber devices and/or TV devices enable this option and other options below. + Additional info and docs are available on the web at + http://linuxtv.org if MEDIA_SUPPORT comment Multimedia core support # +# Multimedia support - automatically enable V4L2 and DVB core +# +config MEDIA_CAMERA_SUPPORT + bool Cameras/video grabbers support + ---help--- + Enable support for webcams and video grabbers. And memory-to-memory devices, and video output devices. Perhaps this should be called MEDIA_VIDEO_SUPPORT? It really refers to any video device that does not have a tuner, right? I find it really strange to have a e.g. HDMI video grabber depend on MEDIA_CAMERA_SUPPORT. + + Say Y when you have a webcam or a video capture grabber board. + +config MEDIA_ANALOG_TV_SUPPORT + bool Analog TV support + ---help--- + Enable analog TV support. I still prefer to see the term 'tuner' be used explicitly: MEDIA_ANALOG_TUNER_SUPPORT and 'Analog TV tuner support' + + Say Y when you have a TV board with analog support or with a + hybrid analog/digital TV chipset. + + Note: There are several DVB cards that are based on chips that + support both analog and digital TV. Disabling this option + will disable support for them. + +config MEDIA_DIGITAL_TV_SUPPORT + bool Digital TV support + ---help--- + Enable digital TV support. Ditto. + + Say Y when you have a board with digital support or a board with + hybrid digital TV and analog TV. + +config MEDIA_RADIO_SUPPORT + bool AM/FM radio receivers/transmitters support + ---help--- + Enable AM/FM radio support. Just drop the 'AM/FM' part. We may get other devices that support other bands as well (I know they exist, and one is actually on its way to me). + + Additional info and docs are available on the web at + http://linuxtv.org + + Say Y when you have a board with radio support. + + Note: There are several TV cards that are based on chips that + support radio reception. Disabling this option will + disable support for them. The remainder of this patch looks good to me. Regards, Hans + +menuconfig MEDIA_RC_SUPPORT + bool Remote Controller support + depends on INPUT + ---help--- + Enable support for Remote Controllers on Linux. This is + needed in order to support several video capture adapters, + standalone IR receivers/transmitters, and RF receivers. + + Enable this option if you have a video capture board even + if you don't need IR, as otherwise, you may not be able to + compile the driver for your adapter. + + Say Y when you have a TV or an IR device. + +# # Media controller +#Selectable only for webcam/grabbers, as other drivers don't use it # config MEDIA_CONTROLLER bool Media Controller API (EXPERIMENTAL) depends on EXPERIMENTAL + depends on MEDIA_CAMERA_SUPPORT ---help--- Enable the media controller API used to query media devices internal topology and configure it dynamically. @@ -27,26 +89,15 @@ config MEDIA_CONTROLLER This API is mostly used by camera interfaces in embedded platforms. # -# V4L core and enabled API's +# Video4Linux support +#Only enables if one of the V4L2 types (ATV, webcam, radio) is selected # config VIDEO_DEV - tristate Video For Linux - ---help--- - V4L core support for video capture and overlay devices, webcams and - AM/FM radio cards. - - This kernel includes support for the new Video for Linux Two API, -
Re: [PATCH 2/2] [media] firedtv: Port it to use rc_core
On May 28 Stefan Richter wrote: + idev-phys = /ir0;/* FIXME */ Something similar to drivers/media/dvb/dvb-usb/dvb-usb-remote.c:: usb_make_path(d-udev, d-rc_phys, sizeof(d-rc_phys)); strlcat(d-rc_phys, /ir0, sizeof(d-rc_phys)); should be implemented for this, right? PS: The current input device looks like this: /sys/devices/pci:00/:00:02.0/:02:00.0/:03:01.0/:04:00.0/fw7/fw7.0/input/input8/device - ../../../fw7.0 fw7.0 is dev_name(dev) in fdtv_register_rc() or dev_name(fdtv-device) in general in firedtv. The last numeric name before fw7, i.e. :04:00.0, is the name of the PCI device of the FireWire controller. fw7 is the name of the FireDTV node; fw7.0 is the name of the (only) unit within the FireDTV node which implements the DVB receiver and IR receiver. What would be needed from this? FWIW, usb_make_path() results in usb-%s-%s % (usb_device.bus.bus_name, usb_device.devpath). -- Stefan Richter -=-===-- -=-= ===-- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [media] firedtv: Port it to use rc_core
Em 28-05-2012 11:14, Stefan Richter escreveu: On May 28 Stefan Richter wrote: + idev-phys = /ir0;/* FIXME */ Something similar to drivers/media/dvb/dvb-usb/dvb-usb-remote.c:: usb_make_path(d-udev, d-rc_phys, sizeof(d-rc_phys)); strlcat(d-rc_phys, /ir0, sizeof(d-rc_phys)); should be implemented for this, right? PS: The current input device looks like this: /sys/devices/pci:00/:00:02.0/:02:00.0/:03:01.0/:04:00.0/fw7/fw7.0/input/input8/device - ../../../fw7.0 fw7.0 is dev_name(dev) in fdtv_register_rc() or dev_name(fdtv-device) in general in firedtv. The last numeric name before fw7, i.e. :04:00.0, is the name of the PCI device of the FireWire controller. fw7 is the name of the FireDTV node; fw7.0 is the name of the (only) unit within the FireDTV node which implements the DVB receiver and IR receiver. What would be needed from this? FWIW, usb_make_path() results in usb-%s-%s % (usb_device.bus.bus_name, usb_device.devpath). IMO, the physical patch is fw7.0. We add a /ir0 for the first IR device (as a driver might have more than one IR). So, the phys should be fw7.0/ir0. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl28xxu - rtl2832 frontend attach
On 28.05.2012 08:58, Thomas Mair wrote: On 26.05.2012 04:47, poma wrote: On 05/20/2012 11:12 PM, Thomas Mair wrote: On 20.05.2012 22:08, Antti Palosaari wrote: On 20.05.2012 20:04, poma wrote: After hard/cold boot: DVB: register adapter0/net0 @ minor: 2 (0x02) rtl2832u_frontend_attach: rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 No compatible tuner found These errors are coming from tuner probe. As it still goes to probing and did not jump out earlier when gate is opened it means that demod is answering commands but tuner are not. My guess is that tuner is still on the reset or not powered at all. It is almost 100% sure error is wrong tuner GPIO. There is an issue with GPIO, as FC0012 tuner callback will set the value of one of the GPIO outputs. However fixing that, will not resolve the issue. So I need to debug the problem further. True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes even more. Precisely, what breaks a tuner on next soft [re]boot are apps/utils which engage tzap/scan[dvb]. To reproduce the bug it is not necessary to reboot the machine. Simply unload and load of the dvb_usb_rtl28xxu module will lead to the same situation. I suspect, that when power is turned off, the tuner power is not switched on correctly. The mistake is not related to the OUTPUT_VAL registers but probably to the OUTPUT_DIR or OUTPUT_EN registers. What makes me wonder is if no tuning operation is performed before reboot, the driver does work correctly after that, as poma already noticed. I have some spare time today and will investigate the problem further. I tried a few things regarding the problem today and could find out a few more details, but could not resolve the issue. The GPIO pin configuration for the devices with the fc0012 (and probably also with the fc0013) tuner is the following: GPIO0: demod power GPIO3: tuner power? (the realtek driver puts this to 1 and never touches it again) GPIO4: tuner power? (maybe antenna power?) GPIO5: tuner reset GPIO6: UHF/VHF band selection All of these GPIOs are configured as output. When the device is plugged in the tuner is powered up correctly, but I am not able to power it up when a reboot is performed. What I tried was the following: - on rtl28xxu_power_ctrl off: - GPIO4 = 1 (off) - GPIO5 = 0 - GPIO6 = 0 (default state) - on rtl28xxu_power_ctrl on: - GPIO3 = 1 - GPIO4 = 0 (on) - GPIO5 = 0 - GPIO6 = 0 (default state) - on rtl2832_frontend_attach: - GPIO5 = 1 - GPIO5 = 0 This sequence should ensure that the tuner is powered on when the frontend is attached, and a tuner reset is being performed before the tuner is probed. However this sequence fails the same way as it did before. I tried to add timeouts to be sure that the tuner is not probed while it is reset but that did not help either. Right now I really don't know where I should look for the solution of the problem. It seems that the tuner reset does not have any effect on the tuner whatsoever. Is there anybody who could look at the code, or maybe knows what could be the cause of the problem? I suspect I am just too blind to see my own mistakes. Regards Thomas -- 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: [media-ctl PATCH 1/1] media-ctl: Compose print fixes
Hi Sakari, On Saturday 26 May 2012 19:43:16 Sakari Ailus wrote: The compose rectangles were printed incorrectly in my recent patch Compose rectangle support for libv4l2subdev without parenthesis. Fix this. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- Hi Laurent, Could you apply this simple fix to your tree? Currently the compose rectangles are printed differently than the crop rectangles which certainly isn't the intention. Done, thank you. src/main.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/main.c b/src/main.c index af16818..d10094b 100644 --- a/src/main.c +++ b/src/main.c @@ -81,14 +81,14 @@ static void v4l2_subdev_print_format(struct media_entity *entity, V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS, which); if (ret == 0) - printf(\n\t\t compose.bounds:%u,%u/%ux%u, + printf(\n\t\t compose.bounds:(%u,%u)/%ux%u, rect.left, rect.top, rect.width, rect.height); ret = v4l2_subdev_get_selection(entity, rect, pad, V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTUAL, which); if (ret == 0) - printf(\n\t\t compose:%u,%u/%ux%u, + printf(\n\t\t compose:(%u,%u)/%ux%u, rect.left, rect.top, rect.width, rect.height); printf(]\n); -- 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 v3 1/1] v4l: drop v4l2_buffer.input and V4L2_BUF_FLAG_INPUT
Hi again, On Mon, May 28, 2012 at 8:52 AM, Ezequiel Garcia elezegar...@gmail.com wrote: I'm just bringing this proposal to your attention as I am wondering how your driver (and the old easycap driver that your driver will replace) handle the easycap device with multiple inputs? Is it cycling through all inputs? In that case we might need the input field. What do you mean by cycling through all inputs? Do you mean registering one video node per video input and support simultaneous streaming? In that case, I don't have that in mind and I'm not sure if the hw supports it. On the contrary, I was thinking in registering just one video device and let user select input through ioctl. All that's needed it to set some stk1160 (and maybe saa711x) registers to route the selected input. I may be missing something, but I don't see any relation between video buffer queue and selected input. (Perhaps this is OT and we should discuss this in another thread) Regards, Ezequiel. -- 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] gspca - ov534/ov534_9: Fix sccd_read/write errors
The ov534 bridge is too slow to handle the sensor accesses
requested by fast hosts giving 'sccb_reg_write failed'.
A small delay fixes the problem.
Signed-off-by: Jean-François Moine moin...@free.fr
---
drivers/media/video/gspca/ov534.c |1 +
drivers/media/video/gspca/ov534_9.c |1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/media/video/gspca/ov534.c
b/drivers/media/video/gspca/ov534.c
index b5acb1e..d5a7873 100644
--- a/drivers/media/video/gspca/ov534.c
+++ b/drivers/media/video/gspca/ov534.c
@@ -851,6 +851,7 @@ static int sccb_check_status(struct gspca_dev *gspca_dev)
int i;
for (i = 0; i 5; i++) {
+ msleep(10);
data = ov534_reg_read(gspca_dev, OV534_REG_STATUS);
switch (data) {
diff --git a/drivers/media/video/gspca/ov534_9.c
b/drivers/media/video/gspca/ov534_9.c
index e6601b8..0120f94 100644
--- a/drivers/media/video/gspca/ov534_9.c
+++ b/drivers/media/video/gspca/ov534_9.c
@@ -1008,6 +1008,7 @@ static int sccb_check_status(struct gspca_dev *gspca_dev)
int i;
for (i = 0; i 5; i++) {
+ msleep(10);
data = reg_r(gspca_dev, OV534_REG_STATUS);
switch (data) {
--
1.7.10
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gspca - sonixj: Fix bad values of webcam 0458:7025
The webcam 0458:7025 (Eye911Q) has:
- an inverted power pin,
- a sensor mi0360b which cannot be probed.
Signed-off-by: Jean-François Moine moin...@free.fr
---
drivers/media/video/gspca/sonixj.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/video/gspca/sonixj.c
b/drivers/media/video/gspca/sonixj.c
index 4d1696d..f38faa9 100644
--- a/drivers/media/video/gspca/sonixj.c
+++ b/drivers/media/video/gspca/sonixj.c
@@ -3120,7 +3120,7 @@ static const struct sd_desc sd_desc = {
| (SENSOR_ ## sensor 8) \
| (flags)
static const struct usb_device_id device_table[] = {
- {USB_DEVICE(0x0458, 0x7025), BS(SN9C120, MI0360)},
+ {USB_DEVICE(0x0458, 0x7025), BSF(SN9C120, MI0360B, F_PDN_INV)},
{USB_DEVICE(0x0458, 0x702e), BS(SN9C120, OV7660)},
{USB_DEVICE(0x045e, 0x00f5), BSF(SN9C105, OV7660, F_PDN_INV)},
{USB_DEVICE(0x045e, 0x00f7), BSF(SN9C105, OV7660, F_PDN_INV)},
--
1.7.10
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/1] v4l: drop v4l2_buffer.input and V4L2_BUF_FLAG_INPUT
On Mon May 28 2012 18:29:11 Ezequiel Garcia wrote: Hi again, On Mon, May 28, 2012 at 8:52 AM, Ezequiel Garcia elezegar...@gmail.com wrote: I'm just bringing this proposal to your attention as I am wondering how your driver (and the old easycap driver that your driver will replace) handle the easycap device with multiple inputs? Is it cycling through all inputs? In that case we might need the input field. What do you mean by cycling through all inputs? Do you mean registering one video node per video input and support simultaneous streaming? In that case, I don't have that in mind and I'm not sure if the hw supports it. On the contrary, I was thinking in registering just one video device and let user select input through ioctl. All that's needed it to set some stk1160 (and maybe saa711x) registers to route the selected input. I may be missing something, but I don't see any relation between video buffer queue and selected input. (Perhaps this is OT and we should discuss this in another thread) Well, this particular API was intended to let the hardware switch from one input to another automatically: e.g. the first frame is from input 1, the second from input 2, etc. until it has gone through all inputs and goes back to input 1. This requires hardware support and if the stk1160 can't do that, then you can forget about all this. I was just wondering about it since the easycap is sold with surveillance applications in mind: http://dx.com/p/easycap-4-channel-4-input-usb-2-0-dvr-video-capture-surveillance-dongle-11127?item=5 However, reading through the comments I realize that the software just switches input every second or so, so this seems to be done by software, not hardware. In other words, your approach is the right one :-) Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/1] v4l: drop v4l2_buffer.input and V4L2_BUF_FLAG_INPUT
On Mon, May 28, 2012 at 2:10 PM, Hans Verkuil hverk...@xs4all.nl wrote: I may be missing something, but I don't see any relation between video buffer queue and selected input. (Perhaps this is OT and we should discuss this in another thread) Well, this particular API was intended to let the hardware switch from one input to another automatically: e.g. the first frame is from input 1, the second from input 2, etc. until it has gone through all inputs and goes back to input 1. This requires hardware support and if the stk1160 can't do that, then you can forget about all this. I did some tests earlier this morning and apparently the input switching is done through some stk1160 GPIO port setting. However, I'll have to figure this out reading easycap staging driver and trying different values over and over. Plus, saa7115 driver supports s_routing function, but couldn't make it work: it looked like saa7115 input setting was fixed and stk1160 handles the input switching. Also, I'm not sure if saa7115 s_stream to enable/disable capture is also working. Sounds a bit weird to me. One last query: I found *no* way to distinguish between one device (one composite input) and the other (four composite input). What do you suggest? Just implement all of them always? Looks like I'm on the right path anyway :) Thanks, Ezequiel. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Mon May 28 19:00:19 CEST 2012 git hash:5472d3f17845c4398c6a510b46855820920c2181 gcc version: i686-linux-gcc (GCC) 4.6.3 host hardware:x86_64 host os: 3.3-6.slh.2-amd64 linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: 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: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/1] v4l: drop v4l2_buffer.input and V4L2_BUF_FLAG_INPUT
On Mon May 28 2012 19:25:41 Ezequiel Garcia wrote: On Mon, May 28, 2012 at 2:10 PM, Hans Verkuil hverk...@xs4all.nl wrote: I may be missing something, but I don't see any relation between video buffer queue and selected input. (Perhaps this is OT and we should discuss this in another thread) Well, this particular API was intended to let the hardware switch from one input to another automatically: e.g. the first frame is from input 1, the second from input 2, etc. until it has gone through all inputs and goes back to input 1. This requires hardware support and if the stk1160 can't do that, then you can forget about all this. I did some tests earlier this morning and apparently the input switching is done through some stk1160 GPIO port setting. However, I'll have to figure this out reading easycap staging driver and trying different values over and over. Plus, saa7115 driver supports s_routing function, but couldn't make it work: it looked like saa7115 input setting was fixed and stk1160 handles the input switching. Also, I'm not sure if saa7115 s_stream to enable/disable capture is also working. Sounds a bit weird to me. One last query: I found *no* way to distinguish between one device (one composite input) and the other (four composite input). What do you suggest? Just implement all of them always? If you can't tell them apart, then that would be your only option. You might also add a 'model' module option so users can tell the driver which model it is. Another might be (I don't know if that will work) to try all inputs and see if you can detect a difference in the saa7115: however, I suspect you can't tell the difference between 'I have only one input' and 'I have four but I haven't hooked up anything to my inputs'. I *hate* it when they don't bother to change the USB IDs. Looks like I'm on the right path anyway :) Yup! 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: [PATCHv6 01/13] v4l: Add DMABUF as a memory type
Hi Tomasz,
Thanks for the patch.
On Wednesday 23 May 2012 14:10:15 Tomasz Stanislawski wrote:
From: Sumit Semwal sumit.sem...@ti.com
Adds DMABUF memory type to v4l framework. Also adds the related file
descriptor in v4l2_plane and v4l2_buffer.
Sorry not to have caught this earlier, but haven't you forgotten to add
support for V4L2_MEMORY_DMABUF to v4l2-compat-ioctl32.c ?
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
[original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-ioctl.c |1 +
include/linux/videodev2.h|7 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c index 91be4e8..31fc2ad 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -175,6 +175,7 @@ static const char *v4l2_memory_names[] = {
[V4L2_MEMORY_MMAP]= mmap,
[V4L2_MEMORY_USERPTR] = userptr,
[V4L2_MEMORY_OVERLAY] = overlay,
+ [V4L2_MEMORY_DMABUF] = dmabuf,
};
#define prt_names(a, arr) a) = 0) ((a) ARRAY_SIZE(arr))) ? \
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 370d111..51b20f4 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -185,6 +185,7 @@ enum v4l2_memory {
V4L2_MEMORY_MMAP = 1,
V4L2_MEMORY_USERPTR = 2,
V4L2_MEMORY_OVERLAY = 3,
+ V4L2_MEMORY_DMABUF = 4,
};
/* see also http://vektor.theorem.ca/graphics/ycbcr/ */
@@ -591,6 +592,8 @@ struct v4l2_requestbuffers {
* should be passed to mmap() called on the video node)
* @userptr: when memory is V4L2_MEMORY_USERPTR, a userspace pointer
* pointing to this plane
+ * @fd: when memory is V4L2_MEMORY_DMABUF, a userspace
file
+ * descriptor associated with this plane
* @data_offset: offset in the plane to the start of data; usually 0,
* unless there is a header in front of the data
*
@@ -605,6 +608,7 @@ struct v4l2_plane {
union {
__u32 mem_offset;
unsigned long userptr;
+ int fd;
} m;
__u32 data_offset;
__u32 reserved[11];
@@ -629,6 +633,8 @@ struct v4l2_plane {
* (or a cookie that should be passed to mmap() as offset)
* @userptr: for non-multiplanar buffers with memory ==
V4L2_MEMORY_USERPTR; *a userspace pointer pointing to this
buffer
+ * @fd: for non-multiplanar buffers with memory ==
V4L2_MEMORY_DMABUF;
+ * a userspace file descriptor associated with this buffer
* @planes: for multiplanar buffers; userspace pointer to the array of
plane * info structs for this buffer
* @length: size in bytes of the buffer (NOT its payload) for single-
plane
@@ -655,6 +661,7 @@ struct v4l2_buffer {
__u32 offset;
unsigned long userptr;
struct v4l2_plane *planes;
+ int fd;
} m;
__u32 length;
__u32 input;
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 02/13] Documentation: media: description of DMABUF importing in V4L2
Hi Tomasz, Thanks for the patch. On Wednesday 23 May 2012 14:10:16 Tomasz Stanislawski wrote: This patch adds description and usage examples for importing DMABUF file descriptor in V4L2. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com CC: linux-...@vger.kernel.org [snip] @@ -103,6 +105,7 @@ as the v4l2-format; structfieldtype/structfield field. See xref entrystructfieldmemory/structfield/entry entryApplications set this field to constantV4L2_MEMORY_MMAP/constant or +constantV4L2_MEMORY_DMABUF/constant or constantV4L2_MEMORY_USERPTR/constant. See xref linkend=v4l2-memory /./entry /row If you resubmit to fix the compat-ioctl issue in 01/13, could you please replace this with entryApplications set this field to constantV4L2_MEMORY_MMAP/constant, constantV4L2_MEMORY_DMABUF/constant or constantV4L2_MEMORY_USERPTR/constant. See xref linkend=v4l2-memory/. /entry like in v5 ? -- 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: [PATCHv6 00/13] Integration of videobuf2 with dmabuf
Hi Tomasz,
On Wednesday 23 May 2012 14:10:14 Tomasz Stanislawski wrote:
Hello everyone,
This patchset adds support for DMABUF [2] importing to V4L2 stack.
The support for DMABUF exporting was moved to separate patchset
due to dependency on patches for DMA mapping redesign by
Marek Szyprowski [4].
Except for the small issue with patches 01/13 and 02/13, the set is ready for
upstream as far as I'm concerned.
v6:
- fixed missing entry in v4l2_memory_names
- fixed a bug occuring after get_user_pages failure
I've missed that one, what was it ?
- fixed a bug caused by using invalid vma for get_user_pages
- prepare/finish no longer call dma_sync for dmabuf buffers
v5:
- removed change of importer/exporter behaviour
- fixes vb2_dc_pages_to_sgt basing on Laurent's hints
- changed pin/unpin words to lock/unlock in Doc
v4:
- rebased on mainline 3.4-rc2
- included missing importing support for s5p-fimc and s5p-tv
- added patch for changing map/unmap for importers
- fixes to Documentation part
- coding style fixes
- pairing {map/unmap}_dmabuf in vb2-core
- fixing variable types and semantic of arguments in videobufb2-dma-contig.c
v3:
- rebased on mainline 3.4-rc1
- split 'code refactor' patch to multiple smaller patches
- squashed fixes to Sumit's patches
- patchset is no longer dependant on 'DMA mapping redesign'
- separated path for handling IO and non-IO mappings
- add documentation for DMABUF importing to V4L
- removed all DMABUF exporter related code
- removed usage of dma_get_pages extension
v2:
- extended VIDIOC_EXPBUF argument from integer memoffset to struct
v4l2_exportbuffer
- added patch that breaks DMABUF spec on (un)map_atachment callcacks but
allows to work with existing implementation of DMABUF prime in DRM
- all dma-contig code refactoring patches were squashed
- bugfixes
v1: List of changes since [1].
- support for DMA api extension dma_get_pages, the function is used to
retrieve pages used to create DMA mapping.
- small fixes/code cleanup to videobuf2
- added prepare and finish callbacks to vb2 allocators, it is used keep
consistency between dma-cpu acess to the memory (by Marek Szyprowski)
- support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated
from [3].
- support for dma-buf exporting in vb2-dma-contig allocator
- support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers,
originated from [3]
- changed handling for userptr buffers (by Marek Szyprowski, Andrzej
Pietrasiewicz)
- let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski)
[1]
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/4296
6/focus=42968 [2] https://lkml.org/lkml/2011/12/26/29
[3]
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/3635
4/focus=36355 [4]
http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819
Laurent Pinchart (2):
v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc
v4l: vb2-dma-contig: Reorder functions
Marek Szyprowski (2):
v4l: vb2: add prepare/finish callbacks to allocators
v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator
Sumit Semwal (4):
v4l: Add DMABUF as a memory type
v4l: vb2: add support for shared buffer (dma_buf)
v4l: vb: remove warnings about MEMORY_DMABUF
v4l: vb2-dma-contig: add support for dma_buf importing
Tomasz Stanislawski (5):
Documentation: media: description of DMABUF importing in V4L2
v4l: vb2-dma-contig: Remove unneeded allocation context structure
v4l: vb2-dma-contig: add support for scatterlist in userptr mode
v4l: s5p-tv: mixer: support for dmabuf importing
v4l: s5p-fimc: support for dmabuf importing
Documentation/DocBook/media/v4l/compat.xml |4 +
Documentation/DocBook/media/v4l/io.xml | 179 +++
.../DocBook/media/v4l/vidioc-create-bufs.xml |1 +
Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 15 +
Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 45 +-
drivers/media/video/s5p-fimc/Kconfig |1 +
drivers/media/video/s5p-fimc/fimc-capture.c|2 +-
drivers/media/video/s5p-tv/Kconfig |1 +
drivers/media/video/s5p-tv/mixer_video.c |2 +-
drivers/media/video/v4l2-ioctl.c |1 +
drivers/media/video/videobuf-core.c|4 +
drivers/media/video/videobuf2-core.c | 207 +++-
drivers/media/video/videobuf2-dma-contig.c | 520 ++---
include/linux/videodev2.h |7 +
include/media/videobuf2-core.h | 34 ++
15 files changed, 924 insertions(+), 99 deletions(-)
--
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
