Re: [PATCH/RFC 1/1] Add a libv4l plugin for Exynos4 camera
On 10/08/2014 05:49 PM, Antonio Ospite wrote: On Wed, 08 Oct 2014 15:22:43 +0200 Jacek Anaszewski wrote: Hi Hans, On 10/08/2014 02:42 PM, Hans de Goede wrote: Hi, On 10/08/2014 10:46 AM, Jacek Anaszewski wrote: The plugin provides support for the media device on Exynos4 SoC. Added is also a media device configuration file parser. The media configuration file is used for conveying information about media device links that need to be established as well as V4L2 user control ioctls redirection to a particular sub-device. The plugin performs single plane <-> multi plane API conversion, video pipeline linking and takes care of automatic data format negotiation for the whole pipeline, after intercepting VIDIOC_S_FMT or VIDIOC_TRY_FMT ioctls. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Mauro Carvalho Chehab Cc: Hans Verkuil --- configure.ac |1 + lib/Makefile.am|5 +- lib/libv4l-exynos4-camera/Makefile.am |7 + .../libv4l-devconfig-parser.h | 145 ++ lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c | 2486 5 files changed, 2642 insertions(+), 2 deletions(-) create mode 100644 lib/libv4l-exynos4-camera/Makefile.am create mode 100644 lib/libv4l-exynos4-camera/libv4l-devconfig-parser.h create mode 100644 lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c Ugh, that is a big plugin. Can you please split out the parser stuff into a separate file ? Yes, I tried to split it, but spent so much time fighting with autotools, that I decided to submit it in this form and ask more experienced v4l-utils build system maintainers for the advice. I mentioned this in the cover letter. What autotools issue in particular? The following change followed by "automake && ./configure" should be enough to add a new file libv4l-devconfig-parser.c: The same modifications produced libv4l-exynos4-camera.so without parser symbols, when I applied them previously, but when I tried them again everything is ok. Probably I wasn't doing proper cleanup. Thanks for the hints. Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/1] Add a libv4l plugin for Exynos4 camera
Hi, On 10/08/2014 03:22 PM, Jacek Anaszewski wrote: > Hi Hans, > > On 10/08/2014 02:42 PM, Hans de Goede wrote: >>> +} >>> + >>> +/* refresh device topology data after linking */ >>> +release_entities(mdev); >>> + >>> +ret = get_device_topology(mdev); >>> + >>> +/* close media device fd as it won't be longer required */ >>> +close(mdev->media_fd); >>> + >>> +if (ret < 0) >>> +goto err_get_dev_topology; >>> + >>> +/* discover a pipeline for the capture device */ >>> +ret = discover_pipeline_by_fd(mdev, fd); >>> +if (ret < 0) >>> +goto err_discover_pipeline; >> >> There does not seem to be any code here to ensure that this plugin does >> not bind to non exonys4 fimc devices. Please fix that. > > There is. Please look above at the > > "if (!capture_entity(media_entity_name))" condition above. I already checked that, that just checks for the string "capture", which is way too generic, please add a more narrow guard. 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 v2 14/14] [media] s5p-mfc: Don't change the image size to smaller than the request.
Hi, > From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com] > Sent: Wednesday, October 08, 2014 4:35 PM > > > Le 2014-10-08 06:24, Kamil Debski a écrit : > > Hi, > > > > This patch seems complicated and I do not understand your motives. > > > > Could you explain what is the problem with the current aligning of > the > > values? > > Is this a hardware problem? Which MFC version does it affect? > > Is it a software problem? If so, maybe the user space application > should > > take extra care on what value it passes/receives to try_fmt? > This looks like something I wanted to bring here as an RFC but never > manage to get the time. In an Odroid Integration we have started using > the following simple patch to work around this: > > https://github.com/dsd/linux- > odroid/commit/c76b38c1d682b9870ea3b00093ad6500a9c5f5f6 > > The context is that right now we have decided that alignment in s_fmt > shall be done with a closest rounding. So the format returned may be > bigger, or smaller, that's basically random. I've been digging through > a > lot, and so far I have found no rational that explains this choice > other > that this felt right. > > In real life, whenever the resulting format is smaller then request, > there is little we can do other then fail or try again blindly other > sizes. But with bigger raw buffers, we can use zero-copy cropping > techniques to keep going. Here's a example: > > image_generator -> hw_converter -> display > > As hw_converter is a V4L2 M2M, an ideal use case here would be for > image_generator to use buffers from the hw_converter. For the scenario, > it is likely that a fixed video size is wanted, but this size is also > likely not to match HW requirement. If hw_converter decide to give back > something smaller, there is nothing image_generator can do. It would > have to try again with random size to find out that best match. It's a > bit silly to force that on application, as the hw_converter know the > closest best match, which is simply the next valid bigger size if that > exist. > > hope that helps, > Nicolas Nicolas, thank you for shedding light on this problem. I see that it is not MFC specific. It seems that the problem applies to all Video4Linux2 devices that use v4l_bound_align_image. I agree with you that this deservers an RFC and some discussion as this would change the behaviour of quite a few drivers. I think the documentation does not specify how TRY_FMT/S_FMT should adjust the parameters. Maybe it would a good idea to add some flagS that determine the behaviour? Best wishes, -- Kamil Debski Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for Oct 8 (media/usb/gspca)
Em Thu, 09 Oct 2014 08:45:28 +0200 Paul Bolle escreveu: > On Wed, 2014-10-08 at 22:50 -0300, Mauro Carvalho Chehab wrote: > > Em Wed, 08 Oct 2014 13:53:33 -0700 > > Randy Dunlap escreveu: > > > On 10/08/14 11:31, Mauro Carvalho Chehab wrote: > > > > From gpsca's PoV, IMHO, it should be fine to disable the webcam buttons > > > > if > > > > the webcam was compiled as builtin and the input subsystem is compiled > > > > as > > > > module. The core feature expected on a camera is to capture streams. > > > > Buttons are just a plus. > > > > > > > > Also, most cams don't even have buttons. The gspca subdriver has > > > > support > > > > for buttons for the few models that have it. > > > > > > > > So, IMHO, it should be ok to have GSPCA=y and INPUT=m, provided that > > > > the buttons will be disabled. > > > > > > Then all of the sub-drivers that use IS_ENABLED(CONFIG_INPUT) should be > > > changed to use IS_BUILTIN(CONFIG_INPUT). > > > > > > But that is too restrictive IMO. The input subsystem will work fine when > > > CONFIG_INPUT=m and the GSPCA drivers are also loadable modules. > > > > Agreed. > > > > Maybe the solution would be something more complex like > > (for drivers/media/usb/gspca/zc3xx.c): > > > > #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && > > !IS_BUILTIN(CONFIG_USB_GSPCA_ZC3XX)) > > The above discussion meanders a bit, and I just stumbled onto it, but > would > #if IS_BUILTIN(CONFIG_INPUT) || (IS_MODULE(CONFIG_INPUT) && > defined(MODULE)) > > cover your requirements when using macros? No. What we need to do, for all gspca sub-drivers that have optional support for buttons is to only enable the buttons support if: CONFIG_INPUT=y or CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=m If we use a reverse logic, we need to disable the code if: # CONFIG_INPUT is not set or CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=y The rationale for disabling the code on the last expression is that a builtin code cannot call a function inside a module. Also, as the submodule is already being compiled, we know that CONFIG_USB_GSPCA_submodule is either module or builtin. So, either one of those expressions should work: #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && !IS_BUILTIN(CONFIG_USB_GSPCA_submodule)) or #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_MODULE(CONFIG_INPUT) && IS_MODULE(CONFIG_USB_GSPCA_submodule) && defined(MODULE)) or #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && IS_MODULE(CONFIG_USB_GSPCA_submodule)) > > > Probably the best would be to write another macro that would evaluate > > like the above. > > > Paul Bolle > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for Oct 8 (media/usb/gspca)
On Thu, 2014-10-09 at 07:30 -0300, Mauro Carvalho Chehab wrote: > Em Thu, 09 Oct 2014 08:45:28 +0200 > Paul Bolle escreveu: > > The above discussion meanders a bit, and I just stumbled onto it, but > > would > > #if IS_BUILTIN(CONFIG_INPUT) || (IS_MODULE(CONFIG_INPUT) && > > defined(MODULE)) > > > > cover your requirements when using macros? > > No. What we need to do, for all gspca sub-drivers that have optional > support for buttons is to only enable the buttons support if: > > CONFIG_INPUT=y > or > CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=m > > If we use a reverse logic, we need to disable the code if: > # CONFIG_INPUT is not set > or > CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=y > > The rationale for disabling the code on the last expression is that a > builtin code cannot call a function inside a module. > > Also, as the submodule is already being compiled, we know that > CONFIG_USB_GSPCA_submodule is either module or builtin. > > So, either one of those expressions should work: > #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && > !IS_BUILTIN(CONFIG_USB_GSPCA_submodule)) > or > #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_MODULE(CONFIG_INPUT) && > IS_MODULE(CONFIG_USB_GSPCA_submodule) && defined(MODULE)) I thought MODULE was only defined for code that will be part of a module. So "IS_MODULE(CONFIG_USB_GSPCA_submodule)" and "defined(MODULE)" should be equal when used _inside_ [...]/usb/gspca/that_submodule.c, shouldn't they? That would make this option basically identical to my suggestion. Or are you thinking about using these tests outside of these submodules themselves? > or > #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && > IS_MODULE(CONFIG_USB_GSPCA_submodule)) I think it's clearer to use IS_BUILTIN(CONFIG_FOO) || (IS_MODULE(CONFIG_FOO) && [...]) Ditto above. Perhaps just a matter of taste. (Depending on INPUT is apparently not possible for these submodules. So obviously any solution needs to check whether input is available, say like if (IS_MODULE(CONFIG_INPUT)) if (!is_input_loaded()) goto no_input; Doesn't it?) Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for Oct 8 (media/usb/gspca)
Em Thu, 09 Oct 2014 13:26:10 +0200 Paul Bolle escreveu: > On Thu, 2014-10-09 at 07:30 -0300, Mauro Carvalho Chehab wrote: > > Em Thu, 09 Oct 2014 08:45:28 +0200 > > Paul Bolle escreveu: > > > The above discussion meanders a bit, and I just stumbled onto it, but > > > would > > > #if IS_BUILTIN(CONFIG_INPUT) || (IS_MODULE(CONFIG_INPUT) && > > > defined(MODULE)) > > > > > > cover your requirements when using macros? > > > > No. What we need to do, for all gspca sub-drivers that have optional > > support for buttons is to only enable the buttons support if: > > > > CONFIG_INPUT=y > > or > > CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=m > > > > If we use a reverse logic, we need to disable the code if: > > # CONFIG_INPUT is not set > > or > > CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=y > > > > The rationale for disabling the code on the last expression is that a > > builtin code cannot call a function inside a module. > > > > Also, as the submodule is already being compiled, we know that > > CONFIG_USB_GSPCA_submodule is either module or builtin. > > > > So, either one of those expressions should work: > > #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && > > !IS_BUILTIN(CONFIG_USB_GSPCA_submodule)) > > or > > #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_MODULE(CONFIG_INPUT) && > > IS_MODULE(CONFIG_USB_GSPCA_submodule) && defined(MODULE)) > > I thought MODULE was only defined for code that will be part of a > module. So "IS_MODULE(CONFIG_USB_GSPCA_submodule)" and "defined(MODULE)" > should be equal when used _inside_ [...]/usb/gspca/that_submodule.c, Ah, I didn't know that. In such case, your suggestion is indeed better, as it is easier to write the patch. > shouldn't they? That would make this option basically identical to my > suggestion. Or are you thinking about using these tests outside of these > submodules themselves? > > > or > > #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && > > IS_MODULE(CONFIG_USB_GSPCA_submodule)) > > I think it's clearer to use > IS_BUILTIN(CONFIG_FOO) || (IS_MODULE(CONFIG_FOO) && [...]) > > Ditto above. Perhaps just a matter of taste. > > (Depending on INPUT is apparently not possible for these submodules. No, because the main functionality (webcam support) doesn't depend on INPUT. > So > obviously any solution needs to check whether input is available, say > like > if (IS_MODULE(CONFIG_INPUT)) > if (!is_input_loaded()) > goto no_input; > > Doesn't it?) Yeah, but the thing is that it breaks at compilation time, because the builtin module would try to use some symbols that are defined only at runtime. So, the above won't solve the issue. One possibility for future Kernels would be to add some logic that would automatically load the module if a call to one of those symbols defined inside a module happens inside a builtin module. The DVB subsystem actually does that for I2C frontend drivers, using those macros: #define dvb_attach(FUNCTION, ARGS...) ({ \ void *__r = NULL; \ typeof(&FUNCTION) __a = symbol_request(FUNCTION); \ if (__a) { \ __r = (void *) __a(ARGS); \ if (__r == NULL) \ symbol_put(FUNCTION); \ } else { \ printk(KERN_ERR "DVB: Unable to find symbol "#FUNCTION"()\n"); \ } \ __r; \ }) #define dvb_detach(FUNC)symbol_put_addr(FUNC) The above works reasonably fine when there's just one symbol needed from the module driver. There are, however, some issues with such approach: 1) as symbol_request increments refcount, this works very badly when there's more than one symbol needed, as symbol_put() would need to be called as many times as symbol_request() is called; 2) lsmod doesn't list what module is actually requesting such symbol (if the caller is also a module). It just increments refcounting. There were some patches meant to fix that, send a long time ago, but were never merged. Can't remember why: http://linuxtv.org/pipermail/linux-dvb/2006-August/012322.html Due to the above issues, and because we want to better use the I2C binding model, we're currently trying to get rid of such approach for the DVB subsystem, but there are too many changes to get rid of it. So, the migration is slow. Anyway, IMHO, having such sort of logic would help to solve the issues with some weird configs like INPUT=m. 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 00/11] Add configuration store support
Hi Hans, Thank you for the set, and my apologies for taking a look only now. On Sun, Sep 21, 2014 at 04:48:18PM +0200, Hans Verkuil wrote: > This patch series adds support for configuration stores to the control > framework. This allows you to store control values for a particular > configuration (up to VIDEO_MAX_FRAME configuration stores are currently > supported). When you queue a new buffer you can supply the store ID and > the driver will apply all controls for that configuration store. > > When you set a new value for a configuration store then you can choose > whether this is 'fire and forget', i.e. after the driver applies the > control value for that store it won't be applied again until a new value > is set. Or you can set the value every time that configuration store is > applied. This does work for video device nodes but not for sub-device nodes which have no buffer queues. Also if you think of using just a value from the closest video buffer queue, that doesn't work either since there could be more than one of those. Most of the time the controls that need to be applied on per-frame basis are present in embedded systems with complex media pipelines where most of the controls are present on sub-device nodes. In other words this approach alone is not sufficient to bind control related configurations to individual frames. For preparing and applying configurations it is applicable. Thinking about the Android camera API v3, controls are a part of the picture only: capture requests contain buffer sets as well. I think the concept makes sense also outside Android. Let's discuss this further at the Media summit. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 00/11] Add configuration store support
On 10/09/14 13:55, Sakari Ailus wrote: > Hi Hans, > > Thank you for the set, and my apologies for taking a look only now. > > On Sun, Sep 21, 2014 at 04:48:18PM +0200, Hans Verkuil wrote: >> This patch series adds support for configuration stores to the control >> framework. This allows you to store control values for a particular >> configuration (up to VIDEO_MAX_FRAME configuration stores are currently >> supported). When you queue a new buffer you can supply the store ID and >> the driver will apply all controls for that configuration store. >> >> When you set a new value for a configuration store then you can choose >> whether this is 'fire and forget', i.e. after the driver applies the >> control value for that store it won't be applied again until a new value >> is set. Or you can set the value every time that configuration store is >> applied. > > This does work for video device nodes but not for sub-device nodes which > have no buffer queues. The subdevices may not have buffer queues, but the high-level media driver will know when a subdevice has to apply a specific configuration store and can tell the subdev to do so. That's the way I expect it to work. > Also if you think of using just a value from the > closest video buffer queue, that doesn't work either since there could be > more than one of those. Good point. One solution might be to allow for a larger range of config store IDs (i.e., more than just 1-32, where 32 is the current maximum number of buffers). That way different buffer queues can use unique config store IDs. This does make the internal data structures a bit more complex, but it's not a big deal. > > Most of the time the controls that need to be applied on per-frame basis are > present in embedded systems with complex media pipelines where most of the > controls are present on sub-device nodes. > > In other words this approach alone is not sufficient to bind control related > configurations to individual frames. For preparing and applying > configurations it is applicable. > > Thinking about the Android camera API v3, controls are a part of the picture > only: capture requests contain buffer sets as well. I think the concept > makes sense also outside Android. Let's discuss this further at the Media > summit. Let's do that. 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 v2 14/14] [media] s5p-mfc: Don't change the image size to smaller than the request.
Le 2014-10-09 06:06, Kamil Debski a écrit : I think the documentation does not specify how TRY_FMT/S_FMT should adjust the parameters. Maybe it would a good idea to add some flagS that determine the behaviour? A flag could be a good option, maybe we should take a minute and discuss this next week. cheers, Nicolas -- 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: technisat-usb2: i2c-error
Hi Jan, On Tue, 07 Oct 2014 19:27:07 +0200 JPT wrote: > 01:14:52 VDR fails to start because there is no recording device. > > I was able to get things running by unloading the modules and loading > them again. After that I started VDR. > > What exactly do the i2c-errors mean? Find attached a > "grep i2c-error syslog*" I can't tell you exactly what happens in the device, but I can tell you that I have the same problem with my device on my PC sometimes. In addition to this I2c-failures from time to time the box is quite sensitive regarding: repowering, replugging and host-rebooting. This is a USB-device-firmware problem which makes the device crash and all subsequent USB-transfers are failed. Reloading the module or replugging the device will make it work again. I lost contact with Technisat some time ago and wouldn't be able easily to get the information (and I doubt they have a solution for this problem - up to them to prove me wrong). How many days without interruption did you use the device? I was following quietly you're discussion with Antti. Has someone taken care of the your changes regarding the transfer-size? I think it should included. regards, -- Patrick. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] ir-hix5hd2: fix build on c6x arch
While not all archs have readl_relaxed, we need to add a hack at the driver to allow it to COMPILE_TEST on all archs: drivers/media/rc/ir-hix5hd2.c: In function ‘hix5hd2_ir_config’: drivers/media/rc/ir-hix5hd2.c:100:2: error: implicit declaration of function ‘readl_relaxed’ [-Werror=implicit-function-declaration] Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/rc/ir-hix5hd2.c b/drivers/media/rc/ir-hix5hd2.c index c555ca2aed0e..08bbd4f508cd 100644 --- a/drivers/media/rc/ir-hix5hd2.c +++ b/drivers/media/rc/ir-hix5hd2.c @@ -20,6 +20,9 @@ #ifndef writel_relaxed # define writel_relaxed writel #endif +#ifndef readl_relaxed +# define readl_relaxed readl +#endif #define IR_ENABLE 0x00 #define IR_CONFIG 0x04 -- 1.9.3 -- 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
randconfig build error with next-20141009, in drivers/media/v4l2-core/videobuf2-core.c
Building with the attached random configuration file, drivers/built-in.o: In function `vb2_fop_mmap': (.text+0x30256b): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_expbuf': (.text+0x3025b9): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_streamoff': (.text+0x302639): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_streamon': (.text+0x3026b9): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_dqbuf': (.text+0x303094): undefined reference to `video_devdata' drivers/built-in.o:(.text+0x3031f1): more undefined references to `video_devdata' follow drivers/built-in.o: In function `vb2_thread': videobuf2-core.c:(.text+0x30396e): undefined reference to `v4l2_get_timestamp' drivers/built-in.o: In function `vb2_ioctl_qbuf': (.text+0x303aba): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_prepare_buf': (.text+0x303c43): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_create_bufs': (.text+0x3045e8): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_reqbufs': (.text+0x304cb9): undefined reference to `video_devdata' drivers/built-in.o: In function `_vb2_fop_release': (.text+0x305067): undefined reference to `video_devdata' drivers/built-in.o: In function `_vb2_fop_release': (.text+0x305117): undefined reference to `v4l2_fh_release' drivers/built-in.o: In function `vb2_fop_release': (.text+0x305148): undefined reference to `video_devdata' drivers/built-in.o: In function `__vb2_perform_fileio': videobuf2-core.c:(.text+0x3059bb): undefined reference to `v4l2_get_timestamp' drivers/built-in.o: In function `vb2_fop_write': (.text+0x305b07): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_fop_read': (.text+0x305cae): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_poll': (.text+0x305e11): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_poll': (.text+0x305e6d): undefined reference to `v4l2_event_pending' drivers/built-in.o: In function `vb2_fop_poll': (.text+0x3063f9): undefined reference to `video_devdata' make: *** [vmlinux] Error 1 # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.17.0 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_HAVE_INTEL_TXT=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SWAP is not set # CONFIG_SYSVIPC is not set CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TI
[GIT PULL for v3.18-rc1] media updates
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v3.18-rc1 For the media patches for v3.18-rc1: - new IR driver: hix5hd2-ir - the virtual test driver (vivi) was replaced by vivid, with has an almost complete set of features to emulate most v4l2 devices and properly test all sorts of userspace apps; - the as102 driver had several bugs fixed and was properly split into a frontend and a core driver. With that, it got promoted from staging into mainstream; - one new CI driver got added for CIMaX SP2/SP2HF (sp2 driver); - one new frontend driver for Toshiba ISDB-T/ISDB-S demod (tc90522); - one new PCI driver for ISDB-T/ISDB-S (pt3 driver); - saa7134 driver got support for go7007-based devices; - added a new PCI driver for Techwell 68xx chipsets (tw68); - a new platform driver was added (coda); - new tuner drivers: mxl301rf and qm1d1c0042; - a new DVB USB driver was added for DVBSky S860 & similar devices; - Added a new SDR driver (hackrf); - usbtv got audio support; - several platform drivers are now compiled with COMPILE_TEST; - a series of compiler fixup patches, making sparse/spatch happier with the media stuff and removing several warnings, especially on those platform drivers that didn't use to compile on x86; - Support for several new modern devices got added; - lots of other fixes, improvements and cleanups. Thanks! Mauro - The following changes since commit bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9: Linux 3.17 (2014-10-05 12:23:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v3.18-rc1 for you to fetch changes up to a66d05d504a24894a8fdf11e4569752f313e5764: Merge branch 'patchwork' into v4l_for_linus (2014-10-09 14:00:54 -0300) media updates for v3.18-rc1 Akihiro Tsukada (4): [media] mxl301rf: add driver for MaxLinear MxL301RF OFDM tuner [media] qm1d1c0042: add driver for Sharp QM1D1C0042 ISDB-S tuner [media] tc90522: add driver for Toshiba TC90522 quad demodulator [media] pt3: add support for Earthsoft PT3 ISDB-S/T receiver card Alexey Khoroshilov (2): [media] mceusb: fix usbdev leak [media] imon: fix usbdev leaks Amber Thrall (1): [media] Media: USB: usbtv: Fixed all coding style issues in usbtv source files Andreas Ruprecht (1): [media] drivers: media: pci: Makefile: Remove duplicate subdirectory from obj-y Andrey Utkin (1): [media] drivers/media/dvb-frontends/stv0900_sw.c: Fix break placement Andy Shevchenko (1): [media] hdpvr: reduce memory footprint when debugging Antonio Ospite (2): [media] trivial: drivers/media/usb/gspca/gspca.c: fix the indentation of a comment [media] trivial: drivers/media/usb/gspca/gspca.h: indent with TABs, not spaces Antti Palosaari (72): [media] dvb-usb-v2: remove dvb_usb_device NULL check [media] msi2500: remove unneeded local pointer on msi2500_isoc_init() [media] m88ts2022: fix 32bit overflow on filter calc [media] m88ts2022: fix coding style issues [media] m88ds3103: change .set_voltage() implementation [media] m88ds3103: fix coding style issues [media] m88ts2022: rename device state (priv => dev) [media] m88ts2022: clean up logging [media] m88ts2022: convert to RegMap I2C API [media] m88ts2022: change parameter type of m88ts2022_cmd [media] airspy: fix error handling on start streaming [media] airspy: coding style issues [media] airspy: logging changes [media] airspy: remove unneeded spinlock irq flags initialization [media] airspy: enhance sample rate debug calculation precision [media] msi2500: logging changes [media] msi001: logging changes [media] msi2500: remove unneeded spinlock irq flags initialization [media] e4000: logging changes [media] rtl2832_sdr: remove unneeded spinlock irq flags initialization [media] rtl2832_sdr: enhance sample rate debug calculation precision [media] rtl2832_sdr: logging changes [media] tda18212: add support for slave chip version [media] af9033: provide dyn0_clk clock source [media] af9035: enable AF9033 demod clock source for IT9135 [media] it913x: fix tuner sleep power leak [media] it913x: avoid division by zero on error case [media] it913x: fix IT9135 AX sleep [media] af9035: remove AVerMedia eeprom override [media] af9035: make checkpatch.pl happy [media] af9033: make checkpatch.pl happy [media] it913x: make checkpatch.pl happy [media] it913x: rename tuner_it913x => it913x [media] it913x: convert to I2C driver [media] it913x: change reg read/write routines more common [media] it913x: rename 'state' to 'dev' [media] it
[GIT PULL for v3.18-rc1] edac updates
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac tags/edac/v3.18-rc1 For some EDAC patches. Nothing really exiting here: just one bug fix at sb_edac, and some changes to allow other drivers to use some shared PCI addresses. Regards, Mauro The following changes since commit c91662cb18f00f225c74816353f222b6997131ca: Merge tag 'edac_for_3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp (2014-10-07 20:54:50 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac tags/edac/v3.18-rc1 for you to fetch changes up to d0585cd815faef50ce3d12cbe173438eb4d81eb8: sb_edac: Claim a different PCI device (2014-10-08 17:04:16 -0300) edac updates for v3.18-rc1 Andy Lutomirski (2): Move Intel SNB device ids from sb_edac to pci_ids.h sb_edac: Claim a different PCI device Seth Jennings (1): sb_edac: avoid INTERNAL ERROR message in EDAC with unspecified channel drivers/edac/sb_edac.c | 40 +++- include/linux/pci_ids.h | 15 +++ 2 files changed, 22 insertions(+), 33 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/1] Libv4l: Add a plugin for the Exynos4 camera
Hi, On 08/10/14 10:46, Jacek Anaszewski wrote: > This patch adds a plugin for the Exynos4 camera. I wanted to split > at least the parser part to the separate module but encountered > some problems with autotools configuration and therefore I'd like > to ask for an instruction on how to adjust the Makefile.am files > to achieve this. I was the one who authored the v4l-utils build system. It looks a little bit messy because of all the supported configurations and toolchain capabilities. Feel free to ask if you have any questions. Thanks, Gregor -- 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 4/4] v4l-utils/dvbv5-scan: add support for ISDB-S scanning
On 2014年10月09日 01:04, Mauro Carvalho Chehab wrote: >> @@ -251,6 +251,16 @@ static int run_scan(struct arguments *args, >> if (dvb_retrieve_entry_prop(entry, DTV_POLARIZATION, &pol)) >> pol = POLARIZATION_OFF; >> >> +if (parms->current_sys == SYS_ISDBS) { >> +uint32_t tsid = 0; >> + >> +dvb_store_entry_prop(entry, DTV_POLARIZATION, >> POLARIZATION_R); >> + >> +dvb_retrieve_entry_prop(entry, DTV_STREAM_ID, &tsid); >> +if (!dvb_new_ts_is_needed(dvb_file->first_entry, entry, >> + freq, shift, tsid)) >> +continue; > > This is likely needed for DVB-T2 and DVB-S2 too. Should we compare channel entries by (freq, stream_id, polarization) triplet instead of by the current (freq, polarization) or (freq, stream_id)? >> @@ -258,6 +268,10 @@ static int run_scan(struct arguments *args, >> count++; >> dvb_log("Scanning frequency #%d %d", count, freq); >> >> +if (!args->lnb_name && entry->lnb && >> +(!parms->lnb || strcasecmp(entry->lnb, parms->lnb->alias))) > > Shouldn't it be: !strcasecmp(entry->lnb, parms->lnb->alias)? Or maybe just > remove this test. I want to update parms->lnb (which was set from the prev entry) only if it differs from entry->lnb (current one), and don't want to linear-search all LNB types for every entries, as lots of entries are expected to have the same LNB types. -- akihiro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] v4l-utils:libdvbv5,dvb: add basic support for ISDB-S
Hi, Mauro, thanks for the review. I'll update the patch soon. And I wrote some comments and questions as a reply to your each review mail. On 2014年10月09日 01:22, Mauro Carvalho Chehab wrote: > Yeah, it will likely require a table just like the one we've added > for EN 300 468 specific charset with the euro sign. > > There are some patches for charset decoding like this one: > > http://marc.info/?l=mplayer-dev-eng&m=125642040004816 I already looked over other examples in some Japan local patches to the applications like mplayer,gstreamer, mythtv..., ( https://github.com/0p1pp1?tab=repositories https://github.com/takaakis62/mythtv_isdb ) so I'm going to reuse those code. regards, akihiro -- 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 resend] [media] rc-core: fix protocol_change regression in ir_raw_event_register
IR reciever using nuvoton-cir and lirc was not working anymore after upgrade from kernel 3.16 to 3.17-rcX. Bisected regression to commit da6e162d6a4607362f8478c715c797d84d449f8b ("[media] rc-core: simplify sysfs code"). The regression comes from adding function change_protocol in ir-raw.c. During registration, ir_raw_event_register enables all protocols by default. Later, rc_register_device also tests dev->change_protocol and changes the enabled protocols based on rc_map type. However, rc_map type only defines a single specific protocol, so in the case of a more generic driver, this disables all protocols but the one defined by the map. Changed back to original behaviour by removing empty function change_protocol in ir-raw.c. Instead only calling change_protocol for drivers that actually have the function set up. Signed-off-by: Tomas Melin --- drivers/media/rc/rc-ir-raw.c |7 --- drivers/media/rc/rc-main.c | 19 --- 2 files changed, 8 insertions(+), 18 deletions(-) diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c index e8fff2a..a118539 100644 --- a/drivers/media/rc/rc-ir-raw.c +++ b/drivers/media/rc/rc-ir-raw.c @@ -240,12 +240,6 @@ ir_raw_get_allowed_protocols(void) return protocols; } -static int change_protocol(struct rc_dev *dev, u64 *rc_type) -{ - /* the caller will update dev->enabled_protocols */ - return 0; -} - /* * Used to (un)register raw event clients */ @@ -263,7 +257,6 @@ int ir_raw_event_register(struct rc_dev *dev) dev->raw->dev = dev; dev->enabled_protocols = ~0; - dev->change_protocol = change_protocol; rc = kfifo_alloc(&dev->raw->kfifo, sizeof(struct ir_raw_event) * MAX_IR_EVENT_SIZE, GFP_KERNEL); diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c index a7991c7..633c682 100644 --- a/drivers/media/rc/rc-main.c +++ b/drivers/media/rc/rc-main.c @@ -1001,11 +1001,6 @@ static ssize_t store_protocols(struct device *device, set_filter = dev->s_wakeup_filter; } - if (!change_protocol) { - IR_dprintk(1, "Protocol switching not supported\n"); - return -EINVAL; - } - mutex_lock(&dev->lock); old_protocols = *current_protocols; @@ -1013,12 +1008,14 @@ static ssize_t store_protocols(struct device *device, rc = parse_protocol_change(&new_protocols, buf); if (rc < 0) goto out; - - rc = change_protocol(dev, &new_protocols); - if (rc < 0) { - IR_dprintk(1, "Error setting protocols to 0x%llx\n", - (long long)new_protocols); - goto out; + /* Only if protocol change set up in driver */ + if (change_protocol) { + rc = change_protocol(dev, &new_protocols); + if (rc < 0) { + IR_dprintk(1, "Error setting protocols to 0x%llx\n", + (long long)new_protocols); + goto out; + } } if (new_protocols == old_protocols) { -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] v4l-utils/dvbv5-scan: add support for ISDB-S scanning
Em Fri, 10 Oct 2014 03:11:32 +0900 Akihiro TSUKADA escreveu: > On 2014年10月09日 01:04, Mauro Carvalho Chehab wrote: > >> @@ -251,6 +251,16 @@ static int run_scan(struct arguments *args, > >>if (dvb_retrieve_entry_prop(entry, DTV_POLARIZATION, &pol)) > >>pol = POLARIZATION_OFF; > >> > >> + if (parms->current_sys == SYS_ISDBS) { > >> + uint32_t tsid = 0; > >> + > >> + dvb_store_entry_prop(entry, DTV_POLARIZATION, > >> POLARIZATION_R); > >> + > >> + dvb_retrieve_entry_prop(entry, DTV_STREAM_ID, &tsid); > >> + if (!dvb_new_ts_is_needed(dvb_file->first_entry, entry, > >> +freq, shift, tsid)) > >> + continue; > > > > This is likely needed for DVB-T2 and DVB-S2 too. > > Should we compare channel entries by (freq, stream_id, polarization) triplet > instead of by the current (freq, polarization) or (freq, stream_id)? For DVB-S2, it should likely be (freq, stream_id, polarization) triplet (tests needed). For DVB-T2, (freq, stream_id) pair should work; For ISDB-S, you likely need the (freq, stream_id, polarization) triplet too, as you may have two polarizations there, right? > >> @@ -258,6 +268,10 @@ static int run_scan(struct arguments *args, > >>count++; > >>dvb_log("Scanning frequency #%d %d", count, freq); > >> > >> + if (!args->lnb_name && entry->lnb && > >> + (!parms->lnb || strcasecmp(entry->lnb, parms->lnb->alias))) > > > > Shouldn't it be: !strcasecmp(entry->lnb, parms->lnb->alias)? Or maybe just > > remove this test. > I want to update parms->lnb (which was set from the prev entry) > only if it differs from entry->lnb (current one), > and don't want to linear-search all LNB types for every entries, > as lots of entries are expected to have the same LNB types. Ah, ok. Please add a comment then. > -- > akihiro -- 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: omap3isp Device Tree support status
Hi Sakari, On Wednesday 08 October 2014 05:03 PM, Sakari Ailus wrote: > Hi Alaganjar, > > On Tue, Oct 07, 2014 at 02:37:37AM +0530, Alaganraj Sandhanam wrote: >> Hi Sakari, >> >> Thanks for the patches. >> On Monday 29 September 2014 03:43 AM, Sakari Ailus wrote: >>> Hi, >>> >>> I managed to find some time for debugging my original omap3isp DT support >>> patchset (which includes smiapp DT support as well), and found a few small >>> but important bugs. >>> >>> The status is now that images can be captured using the Nokia N9 camera, in >>> which the sensor is connected to the CSI-2 interface. Laurent confirmed that >>> the parallel interface worked for him (Beagleboard, mt9p031 sensor on >>> Leopard imaging's li-5m03 board). >> Good news! >>> >>> These patches (on top of the smiapp patches I recently sent for review which >>> are in much better shape) are still experimental and not ready for review. I >>> continue to clean them up and post them to the list when that is done. For >>> now they can be found here: >>> >>> http://git.linuxtv.org/cgit.cgi/sailus/media_tree.git/log/?h=rm696-043-dt> >>> >> I couldn't clone the repo, getting "remote corrupt" error. >> >> $ git remote -v >> media-sakari git://linuxtv.org/sailus/media_tree.git (fetch) >> media-sakari git://linuxtv.org/sailus/media_tree.git (push) >> origin git://linuxtv.org/media_tree.git (fetch) >> origin git://linuxtv.org/media_tree.git (push) >> sakari git://vihersipuli.retiisi.org.uk/~sailus/linux.git (fetch) >> sakari git://vihersipuli.retiisi.org.uk/~sailus/linux.git (push) >> >> $ git fetch media-sakari >> warning: cannot parse SRV response: Message too long >> remote: error: Could not read 5ea878796f0a1d9649fe43a6a09df53d3915c0ef >> remote: fatal: revision walk setup failed >> remote: aborting due to possible repository corruption on the remote side. >> fatal: protocol error: bad pack header > > I'm not sure what this could be related. Can you fetch from other trees, > e.g. your origin remote? Do you get the same error from the remote on > vihersipuli, and by using http instead? > I'm able to fetch from "origin" and "vihersipuli" remotes. problem with only "git://linuxtv.org/sailus/media_tree.git" remote. Thanks&Regards Alaganraj -- 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] br-sp-SaoPaulo: Remove an invalid channel
Channel 12 is currently not valid for ISDB-T in Brazil. Also, due to an error FREQUENCY ended by not being filled here. Signed-off-by: Mauro Carvalho Chehab diff --git a/isdb-t/br-sp-SaoPaulo b/isdb-t/br-sp-SaoPaulo index 2f4d8d77662b..215e596caf2a 100644 --- a/isdb-t/br-sp-SaoPaulo +++ b/isdb-t/br-sp-SaoPaulo @@ -1,35 +1,6 @@ # Channel table for S??o Paulo - SP - Brazil # Source: http://portalbsd.com.br/novo/terrestres_channels.php?channels=1 -# Physical channel 12 -[TV Mackenzie] - DELIVERY_SYSTEM = ISDBT - BANDWIDTH_HZ = 600 - FREQUENCY = - INVERSION = AUTO - GUARD_INTERVAL = AUTO - TRANSMISSION_MODE = AUTO - INVERSION = AUTO - GUARD_INTERVAL = AUTO - TRANSMISSION_MODE = AUTO - ISDBT_LAYER_ENABLED = 7 - ISDBT_SOUND_BROADCASTING = 0 - ISDBT_SB_SUBCHANNEL_ID = 0 - ISDBT_SB_SEGMENT_IDX = 0 - ISDBT_SB_SEGMENT_COUNT = 0 - ISDBT_LAYERA_FEC = AUTO - ISDBT_LAYERA_MODULATION = QAM/AUTO - ISDBT_LAYERA_SEGMENT_COUNT = 0 - ISDBT_LAYERA_TIME_INTERLEAVING = 0 - ISDBT_LAYERB_FEC = AUTO - ISDBT_LAYERB_MODULATION = QAM/AUTO - ISDBT_LAYERB_SEGMENT_COUNT = 0 - ISDBT_LAYERB_TIME_INTERLEAVING = 0 - ISDBT_LAYERC_FEC = AUTO - ISDBT_LAYERC_MODULATION = QAM/AUTO - ISDBT_LAYERC_SEGMENT_COUNT = 0 - ISDBT_LAYERC_TIME_INTERLEAVING = 0 - # Physical channel 15 [Mega TV] DELIVERY_SYSTEM = ISDBT -- 1.9.3 -- 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
v4l2-compliance revision vs Kernel version
Hi, Can someone point me toward a mapping of v4l2-compliance release vs kernel version? I am currently working with a 3.14 kernel and would like to find the matching v4l2-compliance version. I am using git://linuxtv.org/v4l-utils.git commit id: 3719cef libdvbv5: reimplement the logic that gets a full section But on 3.14 running that version against vivi.ko shows a few failures and a bunch of "Not Supported". Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l2-compliance revision vs Kernel version
Hi Benoit, On 10/09/2014 11:45 PM, Benoit Parrot wrote: Hi, Can someone point me toward a mapping of v4l2-compliance release vs kernel version? There isn't any. It's trial and error, I'm afraid. The primary use-case of v4l2-compliance is testing drivers in the bleeding-edge media_tree.git repo. I am currently working with a 3.14 kernel and would like to find the matching v4l2-compliance version. I am using git://linuxtv.org/v4l-utils.git commit id: 3719cef libdvbv5: reimplement the logic that gets a full section But on 3.14 running that version against vivi.ko shows a few failures and a bunch of "Not Supported". "Not Supported" is not an error. It just means that the driver doesn't support that ioctl, so no compliance tests for that ioctl are done. 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: v4l2-compliance revision vs Kernel version
Hi Hans, Hans Verkuil wrote on Fri [2014-Oct-10 00:03:01 +0200]: > Hi Benoit, > > On 10/09/2014 11:45 PM, Benoit Parrot wrote: > >Hi, > > > >Can someone point me toward a mapping of v4l2-compliance release vs kernel > >version? > > There isn't any. It's trial and error, I'm afraid. The primary use-case of > v4l2-compliance is > testing drivers in the bleeding-edge media_tree.git repo. Thanks for the quick reply. I had a feeling that was going to be the case, but had to check. > > > > >I am currently working with a 3.14 kernel and would like to find the > >matching v4l2-compliance version. > >I am using git://linuxtv.org/v4l-utils.git commit id: > >3719cef libdvbv5: reimplement the logic that gets a full section > > > >But on 3.14 running that version against vivi.ko shows a few failures and a > >bunch of "Not Supported". > > "Not Supported" is not an error. It just means that the driver doesn't > support that ioctl, so > no compliance tests for that ioctl are done. Yeah I know but i am getting those even for simple stuff like: Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK (Not Supported) test read/write: OK test MMAP: OK (Not Supported) test USERPTR: OK (Not Supported) test DMABUF: OK (Not Supported) Regards, Benoit -- 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: Fri Oct 10 04:00:27 CEST 2014 git branch: test git hash: cf3167cf1e969b17671a4d3d956d22718a8ceb85 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-20-g7abd8a7 host hardware: x86_64 host os:3.17-0.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: WARNINGS linux-3.12.23-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-i686: OK linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: WARNINGS linux-3.12.23-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16-x86_64: WARNINGS linux-3.17-x86_64: WARNINGS apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API 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
[PATCH v2] [media] videobuf-dma-contig: set vm_pgoff to be zero to pass the sanity check in vm_iomap_memory().
When user requests V4L2_MEMORY_MMAP type buffers, the videobuf-core will assign the corresponding offset to the 'boff' field of the videobuf_buffer for each requested buffer sequentially. Later, user may call mmap() to map one or all of the buffers with the 'offset' parameter which is equal to its 'boff' value. Obviously, the 'offset' value is only used to find the matched buffer instead of to be the real offset from the buffer's physical start address as used by vm_iomap_memory(). So, in some case that if the offset is not zero, vm_iomap_memory() will fail. Signed-off-by: Fancy Fang Reviewed-by: Marek Szyprowski Reviewed-by: Hans Verkuil --- drivers/media/v4l2-core/videobuf-dma-contig.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c b/drivers/media/v4l2-core/videobuf-dma-contig.c index bf80f0f..e02353e 100644 --- a/drivers/media/v4l2-core/videobuf-dma-contig.c +++ b/drivers/media/v4l2-core/videobuf-dma-contig.c @@ -305,6 +305,15 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q, /* Try to remap memory */ size = vma->vm_end - vma->vm_start; vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); + + /* the "vm_pgoff" is just used in v4l2 to find the +* corresponding buffer data structure which is allocated +* earlier and it does not mean the offset from the physical +* buffer start address as usual. So set it to 0 to pass +* the sanity check in vm_iomap_memory(). +*/ + vma->vm_pgoff = 0; + retval = vm_iomap_memory(vma, mem->dma_handle, size); if (retval) { dev_err(q->dev, "mmap: remap failed with error %d. ", -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
GrabBee-HD
I have just bought an HDMI to USB-2.0 grabber called "GrabBee-HD". http://www.greada.com/grabbeex-hd.html Motherboard photo: http://www.davekimble.org.au/computers/GrabBee-HD.jpg Inside it has chips labelled "Sigma PL330B-CPE3" and "iTE IT6604E". Note that it compresses the video with H.264 . I knew it probably wouldn't have drivers for Linux, but it does have Windows drivers on CD, so since I run Ubuntu-VirtualBox-WinXP I thought it might well work one way or another. On Ubuntu 14.04, the USB device is picked up: $ lsusb -v -d 0658:1100 Bus 001 Device 007: ID 0658:1100 Sigma Designs, Inc. Couldn't open device, some information will be missing Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0658 Sigma Designs, Inc. idProduct 0x1100 bcdDevice0.00 iManufacturer 1 iProduct2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 3 but it is not recognised as a video capture device by VLC. /dev/dvb/ , /dev/v4l/ , /dev/video0 do not exist. So I fired up VB-WinXP and installed the Windows drivers and software, and restarted. Then plugged in the device, which should connect the device to the driver, but it didn't. Starting the Grabbee-HD software gives "No video capture device is connected!" Then I realised the USB device has to be passed through the VB interface, VB-Manager > USB > Add > "no devices available". So because Ubuntu doesn't properly recognise the device, it can't pass it on to VB and XP. Is there any chance of getting this going on Ubuntu 14.04 natively? -- 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] [media] ir-hix5hd2 fix build warning
Change CONFIG_PM to CONFIG_PM_SLEEP to solve warning: 'hix5hd2_ir_suspend' & 'hix5hd2_ir_resume' defined but not used Signed-off-by: Zhangfei Gao --- drivers/media/rc/ir-hix5hd2.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/ir-hix5hd2.c b/drivers/media/rc/ir-hix5hd2.c index c555ca2aed0e..455d1b53c9db 100644 --- a/drivers/media/rc/ir-hix5hd2.c +++ b/drivers/media/rc/ir-hix5hd2.c @@ -294,7 +294,7 @@ static int hix5hd2_ir_remove(struct platform_device *pdev) return 0; } -#ifdef CONFIG_PM +#ifdef CONFIG_PM_SLEEP static int hix5hd2_ir_suspend(struct device *dev) { struct hix5hd2_ir_priv *priv = dev_get_drvdata(dev); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html