Re: [RFC PATCH 1/3] s5p-g2d: fix compiler warning
On Wed October 3 2012 12:16:48 Sylwester Nawrocki wrote: > On 10/02/2012 10:57 AM, Hans Verkuil wrote: > > drivers/media/platform/s5p-g2d/g2d.c:535:2: warning: passing argument 3 of > > 'vidioc_try_crop' discards 'const' qualifier from pointer target type > > [enabled by default] > > drivers/media/platform/s5p-g2d/g2d.c:510:12: note: expected 'struct > > v4l2_crop *' but argument is of type 'const struct v4l2_crop *' > > > > This is fall-out from this commit: > > > > commit 4f996594ceaf6c3f9bc42b40c40b0f7f87b79c86 > > Author: Hans Verkuil > > Date: Wed Sep 5 05:10:48 2012 -0300 > > > > [media] v4l2: make vidioc_s_crop const > > > > Signed-off-by: Hans Verkuil > > Aplied, thanks. Just to be clear, you're taking care of these s5p patches through your tree, right? 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
[GIT PULL FOR v3.7] v4l2-ctrl feature enhancement
Hi Mauro, Can you please pull the following patches which adds a new feature and a new control to v4l2-ctrl framework. One of the patch includes usage of the new control in the driver. Thanks and Regards, --Prabhakar Lad The following changes since commit 2425bb3d4016ed95ce83a90b53bd92c7f31091e4: em28xx: regression fix: use DRX-K sync firmware requests on em28xx (2012-10-02 17:15:22 -0300) are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git v4l2-ctrls-pull Lad, Prabhakar (3): media: v4l2-ctrls: add control for test pattern media: v4l2-ctrl: add a helper function to add standard control with driver specific menu media: mt9p031/mt9t001/mt9v032: use V4L2_CID_TEST_PATTERN for test pattern control Documentation/DocBook/media/v4l/controls.xml | 10 + Documentation/video4linux/v4l2-controls.txt | 24 +++ drivers/media/i2c/mt9p031.c | 19 ++--- drivers/media/i2c/mt9t001.c | 22 +++--- drivers/media/i2c/mt9v032.c | 54 +- drivers/media/v4l2-core/v4l2-ctrls.c | 32 +++ include/linux/v4l2-controls.h|1 + include/media/v4l2-ctrls.h | 23 +++ 8 files changed, 145 insertions(+), 40 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 v5] media: mt9p031/mt9t001/mt9v032: use V4L2_CID_TEST_PATTERN for test pattern control
Hi Laurent, On Wed, Oct 3, 2012 at 7:43 PM, Laurent Pinchart wrote: > Hi Prabhakar, > > On Wednesday 03 October 2012 19:23:05 Prabhakar wrote: >> From: Lad, Prabhakar >> >> V4L2_CID_TEST_PATTERN is now a standard control. >> This patch replaces the user defined control for test >> pattern to make use of standard control V4L2_CID_TEST_PATTERN. >> >> Signed-off-by: Lad, Prabhakar >> Signed-off-by: Manjunath Hadli >> Acked-by: Laurent Pinchart >> Cc: Sakari Ailus >> Cc: Paul Gortmaker >> Cc: Jean Delvare > > Should I push this patch through my tree ? If so I'll wait until the > V4L2_CID_TEST_PATTERN control patch hits Mauro's tree. > I will issue a pull request for this patch plus V4L2_CID_TEST_PATTERN today thanks. Regards, --Prabhakar > -- > 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Thu, Oct 4, 2012 at 12:58 AM, Linus Torvalds wrote: > That said, there's clearly enough variation here that I think that for > now I won't take the step to disable the udev part. I'll do the patch > to support "direct filesystem firmware loading" using the udev default > paths, and that hopefully fixes the particular case people see with > media modules. If that approach looks like it works out, please aim for full in-kernel-*only* support. I would absolutely like to get udev entirely out of the sick game of firmware loading here. I would welcome if we are not falling back to the blocking timeouted behaviour again. The whole story would be contained entirely in the kernel, and we get rid of the rather fragile "userspace transaction" to execute module_init(), where the kernel has no idea if userspace is even up to ever responding to its requests. There would be no coordination with userspace tools needed, which sounds like a better fit in the way we develop things with the loosely coupled kernel <-> udev requirements. If that works out, it would a bit like devtmpfs which turned out to be very simple, reliable and absolutely the right thing we could do to primarily mange /dev content. The whole dance with the fake firmware struct device, which has a 60 second timeout to wait for userspace, is a long story of weird failures at various aspects. It would not only solve the unfortunate modprobe lockup with init=/bin/sh we see here, also big servers with an insane amount of devices happen to run into the 60 sec timeout, because udev, which runs with 4000-8000 threads in parallel handling things like 30.000 disks is not scheduled in time to fulfill network card firmware requests. It would be nice if we don't have that arbitrary timeout at all. Having any timeout at all to answer the simple question if a file stored in the rootfs exists, should be a hint that there is something really wrong with the model that stuff is done. Thanks, Kay -- 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 6:33 PM, Ming Lei wrote: > > Yes, the patch will make firmware cache not working, I would like to fix > that when I return from one trip next week. > > BTW, firmware cache is still needed even direct loading is taken. I agree 100%, I'd have liked to do the caching for the direct-loading case too. It's just that the freeing case for that is so intimately tied to the firmware_buf format which is actually very inconvenient for direct-loading, that making that happen looked a lot more involved. And I was indeed hoping you'd look at it, since you touched the code last. "Tag, you're it" It shouldn't be *too* bad to instead of doing the "vmalloc()" allocate an array of pages and then using "vmap()" instead in order to read them (we end up doing the vmap anyway, since the firmware *user* wants a virtually contiguous buffer), but the code will definitely get a bit more opaque. Linus -- 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: udev breakages -
On 3 Oct 2012, Al Viro spake thusly: > Looks sane. TBH, I'd still prefer to see udev forcibly taken over and put > into > usr/udev in kernel tree - I don't trust that crowd at all and the fewer > critical userland bits they can play leverage games with, the safer we are. > > Al, that -><- close to volunteering for maintaining that FPOS kernel-side... Please! It has already been forked at least once in userspace by people who have the temerity to *not use systemd*, imagine that! and still want a udev that is up-to-date in other ways. (We are now being told that, contrary to what was said when udev was migrated into the systemd tree, running udev without systemd is now deprecated and untested and might go away completely. How surprising, nobody ever predicted that when it migrated in, oh wait yes we did, and were assured that we were wrong, that standalone udev would always be supported for those of us who weren't using systemd. Way to destroy your userbase's trust in you...) Possibly udev 175, the last standalone udev as far as I know, is a good place to start from: but you might want to go back a release or two before that, since 174 was where they started doing insane backward-compatibility breaks. By 175 they were requiring devtmpfs, no longer creating device nodes (which I thought was the original *point* of udev), moving lots of install locations on the assumption that / and /usr were on the same filesystem, and migrating udevd from /sbin into /lib/udev without bothering to provide a backward-compatibility symlink. Net benefit of all this thrashing about to udev users: nil. Net sysadmin overhead on upgrade: substantial, oh and if you don't do it your system won't boot. By udev 175 I, and a lot of other people, had simply stopped upgrading udev entirely on the grounds that we could no longer tolerate the uncertainty over whether our systems would boot every time we upgraded it, for no discernible benefit. Yes, all the incompatible changes are (or were, as of udev 175) called out in the release notes -- but there are so *many* of them, it's easy to miss one. And they all seem so completely unnecessary, and their implications for your system configuration grow more and more invasive all the time. When gregkh was maintaining udev it was nicely robust and kept working from release to release, and just did its job without requiring us to change the way our system booted in backwardly-incompatible ways on every release, merge filesystems together or mount /usr in early boot (which is SSH-tunneled over a network in the case of one of my systems, that was fun to do in the initramfs), or install invasive packages that extend tentacles throughout the entire system, require a complete rewriting of my boot process and require millions of kernel features that may not always be turned on. I'd like those days back. I can trust the kernel people to maintain some semblance of userspace compatibility between releases, as is crucial for boot-critical processes. It is now quite clear that I cannot trust the present udev maintainers, or anyone else involved in the ongoing Linux desktop trainwreck, to do any such thing. -- NULL && (void) -- 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 3:48 PM, Andy Walls wrote: > > I don't know if you can remove the /sys/.../firmware ABI altogether, because > there is at least one, somewhat popular udev replacement that also uses it: > mdev > > http://git.busybox.net/busybox/plain/docs/mdev.txt Heh. That web doc documents /lib/firmware as being the place to be. That said, there's clearly enough variation here that I think that for now I won't take the step to disable the udev part. I'll do the patch to support "direct filesystem firmware loading" using the udev default paths, and that hopefully fixes the particular case people see with media modules. We definitely want to have configurable paths and a way to configure udev entirely off for firmware (together with a lack of paths configuring the direct filesystem loading off - that way people can set things up just the way they like), but since I'm travelling tomorrow and this clearly needs more work, I'll do the first step only for now.. Linus -- 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
Hi Linus, On Wed, 3 Oct 2012 13:39:23 -0700 Linus Torvalds wrote: > > Ok, I wish this had been getting more testing in Linux-next or > something If you ever want a patch tested for a few days, just send it to me and I will put it in my "fixes" tree which is merged into linux-next immediately on top of your tree. If nothing else, that will give it wide build testing (see http://kisskb.ellerman.id.au/linux-next). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpuyFMHBy6Dt.pgp Description: PGP signature
Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
Linus Torvalds wrote: >On Wed, Oct 3, 2012 at 12:50 PM, Greg KH >wrote: >>> >>> Ok, like this? >> >> This looks good to me. Having udev do firmware loading and tieing it >to >> the driver model may have not been such a good idea so many years >ago. >> Doing it this way makes more sense. > >Ok, I wish this had been getting more testing in Linux-next or >something, but I suspect that what I'll do is to commit this patch >asap, and then commit another patch that turns off udev firmware >loading entirely for the synchronous firmware loading case. > >Why? Just to get more testing, and seeing if there are reports of >breakage. Maybe some udev out there has a different search path (or >because udev runs in a different filesystem namespace or whatever), in >which case running udev as a fallback would otherwise hide the fact >that he direct kernel firmware loading isn't working. > >We can (and will) revert things if that turns out to break things, but >I'd like to make any failures of the firmware direct-load path be fast >and hard, so that we can see when/what it breaks. > >Ok? Comments? > > Linus >-- >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 I don't know if you can remove the /sys/.../firmware ABI altogether, because there is at least one, somewhat popular udev replacement that also uses it: mdev http://git.busybox.net/busybox/plain/docs/mdev.txt Regards, Andy -- 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 2:58 PM, Lucas De Marchi wrote: > > So maintaining the fallback or adding a configurable entry to set the > firmware paths might be good. Yeah, I do think we need to make it configurable. Probably both at kernel compile time and dynamically. The aim of having a user-mode daemon do this was that it would be easy to configure. Sadly, if we can't trust the daemon, that is all totally worthless. Linus -- 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Tue, Oct 2, 2012 at 7:37 PM, Linus Torvalds wrote: > On Tue, Oct 2, 2012 at 2:03 PM, Ivan Kalvachev wrote: >> >> I'm not kernel developer and probably my opinion would be a little >> naive, but here it is. >> >> Please, make the kernel load firmware from the filesystem on its own. > > We probably should do that, not just for firmware, but for modules > too. It would also simplify the whole "built-in firmware" thing > > Afaik, the only thing udev really does is to lok in > /lib/firmware/updates and /lib/firmware for the file, load it, and > pass it back to the kernel. We could make the kernel try to do it > manually first, and only fall back to udev if that fails. > > Afaik, nobody ever does anything else anyway. > > I'd prefer to not have to do that, but if the udev code is buggy or > the maintainership is flaky, I guess we don't really have much choice. > > Doing the same thing for module loading is probably a good idea too. humn... I don't think so. It would work perfectly well for firmware, but for modules there are more things involved like fulfilling dependencies, soft-dependencies, aliases and the like. It would create several regressions. > There were already people (from the google/Android camp) who wanted to > do module loading based on filename rather than the buffer passed to > it, because they have a "I trust this filesystem" model. They wanted to pass a fd instead of a buffer. That is being done in the new finit_module syscall being discussed: http://www.gossamer-threads.com/lists/linux/kernel/1592271?do=post_view_flat Lucas De Marchi -- 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 5:39 PM, Linus Torvalds wrote: > On Wed, Oct 3, 2012 at 12:50 PM, Greg KH wrote: >>> >>> Ok, like this? >> >> This looks good to me. Having udev do firmware loading and tieing it to >> the driver model may have not been such a good idea so many years ago. >> Doing it this way makes more sense. > > Ok, I wish this had been getting more testing in Linux-next or > something, but I suspect that what I'll do is to commit this patch > asap, and then commit another patch that turns off udev firmware > loading entirely for the synchronous firmware loading case. This would break non-udev users with different paths. Namely Android, which uses /system/etc/firmware and /system/vendor/firmware (not sure about them though, I'm not keen on Android camp) So maintaining the fallback or adding a configurable entry to set the firmware paths might be good. Lucas De Marchi -- 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, 3 Oct 2012 23:18:06 +0200 Kay Sievers wrote: > On Wed, Oct 3, 2012 at 11:05 PM, Greg KH wrote: > > > As for the firmware path, maybe we should > > change that to be modified by userspace (much like /sbin/hotplug was) in > > a proc file so that distros can override the location if they need to. > > If that's needed, a CONFIG_FIRMWARE_PATH= with the array of locations > would probably be sufficient. The current system permits firmware to be served by a daemon, or even assembled on the fly from parts. You break that for one. Just fix udev, and if you can't fix it someone please just fork the last working one. Alan -- 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 11:05 PM, Greg KH wrote: > As for the firmware path, maybe we should > change that to be modified by userspace (much like /sbin/hotplug was) in > a proc file so that distros can override the location if they need to. If that's needed, a CONFIG_FIRMWARE_PATH= with the array of locations would probably be sufficient. Like udev's defaults here: http://cgit.freedesktop.org/systemd/systemd/tree/configure.ac#n550 Kay -- 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
Greg KH wrote:
>On Wed, Oct 03, 2012 at 10:32:08AM -0700, Linus Torvalds wrote:
>> On Wed, Oct 3, 2012 at 10:09 AM, Al Viro
>wrote:
>> >
>> > + if (!S_ISREG(inode->i_mode))
>> > + return false;
>> > + size = i_size_read(inode);
>> >
>> > Probably better to do vfs_getattr() and check mode and size in
>kstat; if
>> > it's sufficiently hot for that to hurt, we are fucked anyway.
>> >
>> > + file = filp_open(path, O_RDONLY, 0);
>> > + if (IS_ERR(file))
>> > + continue;
>> > +printk("from file '%s' ", path);
>> > + success = fw_read_file_contents(file, fw);
>> > + filp_close(file, NULL);
>> >
>> > fput(file), please. We have enough misuses of filp_close() as it
>is...
>>
>> Ok, like this?
>
>This looks good to me. Having udev do firmware loading and tieing it
>to
>the driver model may have not been such a good idea so many years ago.
>Doing it this way makes more sense.
>
>greg k-h
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media"
>in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
I agree that not calling out to userspace for firmware load is better.
Here is an old, unresolved bug about Oops on firmware loading race condition
https://bugzilla.kernel.org/show_bug.cgi?id=15294
The firmware loading timeout in the kernel was cleaning things up, just as udev
what trying to say "I'm done loading the firmware" via sysfs; and then *boom*.
Regards,
Andy
--
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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 03, 2012 at 01:39:23PM -0700, Linus Torvalds wrote: > On Wed, Oct 3, 2012 at 12:50 PM, Greg KH wrote: > >> > >> Ok, like this? > > > > This looks good to me. Having udev do firmware loading and tieing it to > > the driver model may have not been such a good idea so many years ago. > > Doing it this way makes more sense. > > Ok, I wish this had been getting more testing in Linux-next or > something, but I suspect that what I'll do is to commit this patch > asap, and then commit another patch that turns off udev firmware > loading entirely for the synchronous firmware loading case. > > Why? Just to get more testing, and seeing if there are reports of > breakage. Maybe some udev out there has a different search path (or > because udev runs in a different filesystem namespace or whatever), in > which case running udev as a fallback would otherwise hide the fact > that he direct kernel firmware loading isn't working. > > We can (and will) revert things if that turns out to break things, but > I'd like to make any failures of the firmware direct-load path be fast > and hard, so that we can see when/what it breaks. > > Ok? Comments? I have no objection to this. As for the firmware path, maybe we should change that to be modified by userspace (much like /sbin/hotplug was) in a proc file so that distros can override the location if they need to. But for now, that's probably overkill. This solves the problem that Mauro and others have reported and can be easily backported by any affected distros if needed. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 10:39 PM, Linus Torvalds wrote: > On Wed, Oct 3, 2012 at 12:50 PM, Greg KH wrote: >>> >>> Ok, like this? >> >> This looks good to me. Having udev do firmware loading and tieing it to >> the driver model may have not been such a good idea so many years ago. >> Doing it this way makes more sense. > > Ok, I wish this had been getting more testing in Linux-next or > something, but I suspect that what I'll do is to commit this patch > asap, and then commit another patch that turns off udev firmware > loading entirely for the synchronous firmware loading case. > > Why? Just to get more testing, and seeing if there are reports of > breakage. Maybe some udev out there has a different search path (or > because udev runs in a different filesystem namespace or whatever), in > which case running udev as a fallback would otherwise hide the fact > that he direct kernel firmware loading isn't working. > Ok? Comments? The current udev directory search order is: /lib/firmware/updates/$(uname -r)/ /lib/firmware/updates/ /lib/firmware/$(uname -r)/ /lib/firmware/ There is no commonly known /firmware directory. http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-firmware.c#n100 http://cgit.freedesktop.org/systemd/systemd/tree/configure.ac#n548 Kay -- 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 04/14] media: add V4L2 DT binding documentation
On 10/02/2012 09:33 AM, Guennadi Liakhovetski wrote:
> Hi Rob
>
> On Tue, 2 Oct 2012, Rob Herring wrote:
>
>> On 09/27/2012 09:07 AM, Guennadi Liakhovetski wrote:
>>> This patch adds a document, describing common V4L2 device tree bindings.
>>>
>>> Co-authored-by: Sylwester Nawrocki
>>> Signed-off-by: Guennadi Liakhovetski
>>> ---
>>> Documentation/devicetree/bindings/media/v4l2.txt | 162
>>> ++
>>> 1 files changed, 162 insertions(+), 0 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/media/v4l2.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/v4l2.txt
>>> b/Documentation/devicetree/bindings/media/v4l2.txt
>>> new file mode 100644
>>> index 000..b8b3f41
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/media/v4l2.txt
>>> @@ -0,0 +1,162 @@
>>> +Video4Linux Version 2 (V4L2)
>>
>> DT describes the h/w, but V4L2 is Linux specific. I think the binding
>> looks pretty good in terms of it is describing the h/w and not V4L2
>> components or settings. So in this case it's really just the name of the
>> file and title I have issue with.
>
> Hm, I see your point, then, I guess, you'd also like the file name
> changed. What should we use then? Just "video?" But there's already a
> whole directory Documentation/devicetree/bindings/video dedicated to
> graphics output (drm, fbdev). "video-camera" or "video-capture?" But this
> file shall also be describing video output. Use "video.txt" and describe
> inside what exactly this file is for?
Video output will probably have a lot of overlap with the graphics side.
How about video-interfaces.txt?
>
>>
>> One other comment below:
>>
>>> +
>>> +General concept
>>> +---
>>> +
>>> +Video pipelines consist of external devices, e.g. camera sensors,
>>> controlled
>>> +over an I2C, SPI or UART bus, and SoC internal IP blocks, including video
>>> DMA
>>> +engines and video data processors.
>>> +
>>> +SoC internal blocks are described by DT nodes, placed similarly to other
>>> SoC
>>> +blocks. External devices are represented as child nodes of their
>>> respective bus
>>> +controller nodes, e.g. I2C.
>>> +
>>> +Data interfaces on all video devices are described by "port" child DT
>>> nodes.
>>> +Configuration of a port depends on other devices participating in the data
>>> +transfer and is described by "link" DT nodes, specified as children of the
>>> +"port" nodes:
>>> +
>>> +/foo {
>>> + port@0 {
>>> + link@0 { ... };
>>> + link@1 { ... };
>>> + };
>>> + port@1 { ... };
>>> +};
>>> +
>>> +If a port can be configured to work with more than one other device on the
>>> same
>>> +bus, a "link" child DT node must be provided for each of them. If more
>>> than one
>>> +port is present on a device or more than one link is connected to a port, a
>>> +common scheme, using "#address-cells," "#size-cells" and "reg" properties
>>> is
>>> +used.
>>> +
>>> +Optional link properties:
>>> +- remote: phandle to the other endpoint link DT node.
>>
>> This name is a little vague. Perhaps "endpoint" would be better.
>
> "endpoint" can also refer to something local like in USB case. Maybe
> rather the description of the "remote" property should be improved?
>
remote-endpoint?
> Thanks
> Guennadi
>
>>
>> Rob
>>
>>> +- slave-mode: a boolean property, run the link in slave mode. Default is
>>> master
>>> + mode.
>>> +- data-shift: on parallel data busses, if data-width is used to specify the
>>> + number of data lines, data-shift can be used to specify which data lines
>>> are
>>> + used, e.g. "data-width=<10>; data-shift=<2>;" means, that lines 9:2 are
>>> used.
>>> +- hsync-active: 1 or 0 for active-high or -low HSYNC signal polarity
>>> + respectively.
>>> +- vsync-active: ditto for VSYNC. Note, that if HSYNC and VSYNC polarities
>>> are
>>> + not specified, embedded synchronisation may be required, where supported.
>>> +- data-active: similar to HSYNC and VSYNC specifies data line polarity.
>>> +- field-even-active: field signal level during the even field data
>>> transmission.
>>> +- pclk-sample: rising (1) or falling (0) edge to sample the pixel clock
>>> pin.
>>> +- data-lanes: array of serial, e.g. MIPI CSI-2, data hardware lane numbers
>>> in
>>> + the ascending order, beginning with logical lane 0.
>>> +- clock-lanes: hardware lane number, used for the clock lane.
>>> +- clock-noncontinuous: a boolean property to allow MIPI CSI-2
>>> non-continuous
>>> + clock mode.
>>> +
>>> +Example:
>>> +
>>> + ceu0: ceu@0xfe91 {
>>> + compatible = "renesas,sh-mobile-ceu";
>>> + reg = <0xfe91 0xa0>;
>>> + interrupts = <0x880>;
>>> +
>>> + mclk: master_clock {
>>> + compatible = "renesas,ceu-clock";
>>> + #clock-cells = <1>;
>>> + clock-frequency = <5000>; /* max clock frequency
>>> */
>>> + clock-output-names = "mclk";
>>> +
Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 12:50 PM, Greg KH wrote: >> >> Ok, like this? > > This looks good to me. Having udev do firmware loading and tieing it to > the driver model may have not been such a good idea so many years ago. > Doing it this way makes more sense. Ok, I wish this had been getting more testing in Linux-next or something, but I suspect that what I'll do is to commit this patch asap, and then commit another patch that turns off udev firmware loading entirely for the synchronous firmware loading case. Why? Just to get more testing, and seeing if there are reports of breakage. Maybe some udev out there has a different search path (or because udev runs in a different filesystem namespace or whatever), in which case running udev as a fallback would otherwise hide the fact that he direct kernel firmware loading isn't working. We can (and will) revert things if that turns out to break things, but I'd like to make any failures of the firmware direct-load path be fast and hard, so that we can see when/what it breaks. Ok? Comments? Linus -- 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: Access files from kernel
On Wed, Oct 3, 2012 at 12:48 PM, Kirill A. Shutemov wrote: > > AFAIK, accessing files on filesystem form kernel directly was no-go for a > long time. What's the new rule here? Oh, we've *always* accessed files from the kernel. What we don't want is random drivers doing so directly and without a good abstraction layer, because that just ends up being a total nightmare. Still, they've done that too. Ugh. Too many drivers having random hacks like that. Linus -- 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 03, 2012 at 10:32:08AM -0700, Linus Torvalds wrote:
> On Wed, Oct 3, 2012 at 10:09 AM, Al Viro wrote:
> >
> > + if (!S_ISREG(inode->i_mode))
> > + return false;
> > + size = i_size_read(inode);
> >
> > Probably better to do vfs_getattr() and check mode and size in kstat; if
> > it's sufficiently hot for that to hurt, we are fucked anyway.
> >
> > + file = filp_open(path, O_RDONLY, 0);
> > + if (IS_ERR(file))
> > + continue;
> > +printk("from file '%s' ", path);
> > + success = fw_read_file_contents(file, fw);
> > + filp_close(file, NULL);
> >
> > fput(file), please. We have enough misuses of filp_close() as it is...
>
> Ok, like this?
This looks good to me. Having udev do firmware loading and tieing it to
the driver model may have not been such a good idea so many years ago.
Doing it this way makes more sense.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Access files from kernel
On Wed, Oct 03, 2012 at 09:38:52AM -0700, Linus Torvalds wrote:
>+static bool fw_get_filesystem_firmware(struct firmware *fw, const char *name)
>+{
>+ int i;
>+ bool success = false;
>+ const char *fw_path[] = { "/lib/firmware/update", "/firmware",
>"/lib/firmware" };
>+ char *path = __getname();
>+
>+printk("Trying to load fw '%s' ", name);
>+ for (i = 0; i < ARRAY_SIZE(fw_path); i++) {
>+ struct file *file;
>+ snprintf(path, PATH_MAX, "%s/%s", fw_path[i], name);
>+
>+ file = filp_open(path, O_RDONLY, 0);
AFAIK, accessing files on filesystem form kernel directly was no-go for a
long time. What's the new rule here?
Is it worth to introduce an execption, if it's possible to solve the
problem in userspace.
--
Kirill A. Shutemov
--
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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
Em 03-10-2012 13:57, Greg KH escreveu: > On Wed, Oct 03, 2012 at 04:36:53PM +0200, Kay Sievers wrote: >> On Wed, Oct 3, 2012 at 12:12 AM, Greg KH wrote: >> >>> Mauro, what version of udev are you using that is still showing this >>> issue? >>> >>> Kay, didn't you resolve this already? If not, what was the reason why? >> >> It's the same in the current release, we still haven't wrapped our >> head around how to fix it/work around it. > > Ick, as this is breaking people's previously-working machines, shouldn't > this be resolved quickly? > >> Unlike what the heated and pretty uncivilized and rude emails here >> claim, udev does not dead-lock or "break" things, it's just "slow". >> The modprobe event handling runs into a ~30 second event timeout. >> Everything is still fully functional though, there's only this delay. > > Mauro said it broke the video drivers. Mauro, if you wait 30 seconds, > does everything then "work"? > > Not to say that waiting 30 seconds is a correct thing here... Before the implementation of the DVB async firmware load, as requested by udev maintainers, and on a test case, the additional 30 seconds wait won't hurt[1]. [1] Well, I didn't test any tm6000 devices with Kernel 3.6. On tm6000, firmwares are needed for xc3028 tuners, via the board internal I2C bus. Those devices only support 10 kHz speed for those transfers. Also, due to a bug at the hardware, extra delay is needed. So, a firmware load there takes ~30 seconds. I suspect that waiting for ~60 seconds will trigger the max allowed time for firmware load to happen, actually breaking completely the driver. There are applications like MythTV, however, that opens all interfaces produced by a media device at the same time (alsa, video nodes, dvb nodes). I'm not a MythTV user myself, but someone told me recently that MythTV has a 5 seconds timeout there. If it can't open an interface on that time, it will give up for that device. As you likely know, MythTV is used as a Media Center: there are distros that load it (or some other applications like XBMC) at boot time. As the media drivers are modular, the DVB, alsa and TV API's are implemented on (almost) independent modules. On such scenario, if the DVB firmware load takes 30 seconds, because the DVB demod requires a firmware, while the analog TV doesn't require a firmware, I suspect that Mythtv will assume that DVB is not there, causing a failure to the end user. [1] The attempt to fix the issues with udev forced us to re-design a few drivers. One of them (drxk) now loads firmware asynchronously. That effectively broke the driver on Kernel 3.6, for PCTV520e and similar devices, as the tuner driver, attached just after drx-k, stopped working, likely due to some missing clock or GPIO signals that drx-k is supposed to rise after firmware load. The fixes for it are at: http://git.linuxtv.org/media_tree.git/commit/6ae5e060840589f567c1837613e8a9d34fc9188a http://git.linuxtv.org/media_tree.git/commit/8e30783b0b3270736b2cff6415c68b894bc411df http://git.linuxtv.org/media_tree.git/commit/2425bb3d4016ed95ce83a90b53bd92c7f31091e4 In order to fix that issues, I had to defer DVB initialization for all em28xx devices, in despite of the fact that only 5 boards (of 86 devices supported there) require DVB firmwares. Patches are likely a little pedantic, as they are doing async DVB initialization even when the drivers are compiled builtin, but, as I do expect to revert the entire async thing from em28xx/drx-k, I didn't want to make too big changes there. FYI, I'm planning to upstream those fixes tomorrow, if nobody detects any issue on this approach. > I recommend making module loading async, like it used to be, and then > all should be fine, right? IMHO, module loading should be async: it seems a way better and more POSIX compliant to take more time during init, than delaying firmware init to happen open(), especially when open() is called on non-block mode. 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
cron job: media_tree daily build: ERRORS
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:Wed Oct 3 19:00:34 CEST 2012 git hash:2425bb3d4016ed95ce83a90b53bd92c7f31091e4 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-sh: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS 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 linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS 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-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 03, 2012 at 10:32:08AM -0700, Linus Torvalds wrote:
> On Wed, Oct 3, 2012 at 10:09 AM, Al Viro wrote:
> >
> > + if (!S_ISREG(inode->i_mode))
> > + return false;
> > + size = i_size_read(inode);
> >
> > Probably better to do vfs_getattr() and check mode and size in kstat; if
> > it's sufficiently hot for that to hurt, we are fucked anyway.
> >
> > + file = filp_open(path, O_RDONLY, 0);
> > + if (IS_ERR(file))
> > + continue;
> > +printk("from file '%s' ", path);
> > + success = fw_read_file_contents(file, fw);
> > + filp_close(file, NULL);
> >
> > fput(file), please. We have enough misuses of filp_close() as it is...
>
> Ok, like this?
Looks sane. TBH, I'd still prefer to see udev forcibly taken over and put into
usr/udev in kernel tree - I don't trust that crowd at all and the fewer
critical userland bits they can play leverage games with, the safer we are.
Al, that -><- close to volunteering for maintaining that FPOS kernel-side...
--
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] Add toggle to the tt3650_rc_query function of the ttusb2 driver
On Wednesday 03 October 2012 20:57:07 Hans Petter Selasky wrote: > On Tuesday 02 October 2012 21:52:11 Hans Petter Selasky wrote: > > On Saturday 08 September 2012 19:08:22 Jose Alberto Reguero wrote: > > > This patch add the toggle bit to the tt3650_rc_query function of the > > > ttusb2 driver. > > > > > > Signed-off-by: Jose Alberto Reguero > > > > > > Jose Alberto > > > > Hi, > > > > This patch looks OK. > > Hi, > > > Regarding the TTUSB2 support, I see an issue where the IR polling > > interference with the CAM access. If a IR poll request happens exactly > > between a write/read CAM request, then that CAM request will fail. How > > can this issue be solved without disabling the IR support entirely? > > I checked the code and see that "dvb_usb_generic_rw()" will synchronize the > requests, so this can't be the root cause. Currently I suspect the not > brand new AMD based EHCI controller I'm using to connect my TTUSB adapter > to be at fault. This is FreeBSD, not Linux. What I see when I dump all the > transactions is that I have quite frequent timeouts on some of the I2C/CAM > and IR commands going on the BULK endpoints. For example grepp'ed log > extract looks like this: > > 55 3B 42 02 00 A0 01 DF 00 00 00 00 00 FB F5 81 |U;B.| > AA 3C 42 02 00 01 -- -- -- -- -- -- -- -- -- -- |. 55 3C 42 02 00 01 01 DF 00 00 00 00 00 FB F5 81 |U AA 3D 42 02 00 01 -- -- -- -- -- -- -- -- -- -- |.=B... | > 18:46:16.972329 usbus1.3 DONE-BULK- > EP=0081,SPD=HIGH,NFR=0,SLEN=0,IVAL=0,ERR=TIMEOUT > AA 3E 31 04 11 01 01 1A -- -- -- -- -- -- -- -- |.>1.| > 55 3E 31 04 10 01 01 DF 00 00 00 00 00 FB F5 81 |U>1.| > AA 3D 42 02 00 01 -- -- -- -- -- -- -- -- -- -- |.=B... | > 55 3D 42 02 00 01 01 DF 00 00 00 00 00 FB F5 81 |U=B.| > AA 40 41 01 01 -- -- -- -- -- -- -- -- -- -- -- |.@A.. | > > I'm now trying some EHCI quirks, and will see what results I get later this > week. > > I can also say that VDR receives a ring buffer overflow at exactly the same > time the USB BULK endpoint timeout happens > > If this sounds familar to anyone, please let me know. > > Thank you, > > --HPS More info if anyone cares to look at it: vdr: [680141312] ERROR: can't write to CI adapter on device 0: Device not configured vdr: [680142848] ERROR: 7 ring buffer overflows (1316 bytes dropped) vdr: [680141312] CAM 1: module present vdr: [680141312] CAM 1: module ready vdr: [680141312] CAM 1: Conax Conditional Access, 01, 0B00, 0001 vdr: [680141312] CAM 1: doesn't reply to QUERY - only a single channel can be decrypted vdr: [680141312] ERROR: can't write to CI adapter on device 0: Device not configured vdr: [680142848] ERROR: 11 ring buffer overflows (2068 bytes dropped) vdr: [680141312] CAM 1: module present vdr: [680141312] CAM 1: module ready vdr: [680141312] CAM 1: Conax Conditional Access, 01, 0B00, 0001 vdr: [680141312] CAM 1: doesn't reply to QUERY - only a single channel can be decrypted Happens regularly, interrupts the stream and is very annoying :-) --HPS -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add toggle to the tt3650_rc_query function of the ttusb2 driver
On Tuesday 02 October 2012 21:52:11 Hans Petter Selasky wrote: > On Saturday 08 September 2012 19:08:22 Jose Alberto Reguero wrote: > > This patch add the toggle bit to the tt3650_rc_query function of the > > ttusb2 driver. > > > > Signed-off-by: Jose Alberto Reguero > > > > Jose Alberto > > Hi, > > This patch looks OK. > Hi, > Regarding the TTUSB2 support, I see an issue where the IR polling > interference with the CAM access. If a IR poll request happens exactly > between a write/read CAM request, then that CAM request will fail. How can > this issue be solved without disabling the IR support entirely? I checked the code and see that "dvb_usb_generic_rw()" will synchronize the requests, so this can't be the root cause. Currently I suspect the not brand new AMD based EHCI controller I'm using to connect my TTUSB adapter to be at fault. This is FreeBSD, not Linux. What I see when I dump all the transactions is that I have quite frequent timeouts on some of the I2C/CAM and IR commands going on the BULK endpoints. For example grepp'ed log extract looks like this: 55 3B 42 02 00 A0 01 DF 00 00 00 00 00 FB F5 81 |U;B.| AA 3C 42 02 00 01 -- -- -- -- -- -- -- -- -- -- |.1.| 55 3E 31 04 10 01 01 DF 00 00 00 00 00 FB F5 81 |U>1.| AA 3D 42 02 00 01 -- -- -- -- -- -- -- -- -- -- |.=B... | 55 3D 42 02 00 01 01 DF 00 00 00 00 00 FB F5 81 |U=B.| AA 40 41 01 01 -- -- -- -- -- -- -- -- -- -- -- |.@A.. | I'm now trying some EHCI quirks, and will see what results I get later this week. I can also say that VDR receives a ring buffer overflow at exactly the same time the USB BULK endpoint timeout happens If this sounds familar to anyone, please let me know. Thank you, --HPS -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 10:24 AM, Kay Sievers wrote: > > Nothing really "breaks", It's "slow" and it will surely be fixed when > we know what's the right fix, which we haven't sorted out at this > moment. A thirty-second pause at bootup is easily long enough that some people might think the machine is hung. I also call bullshit on your "it will surely be fixed when we know what's the right fix" excuses. The fact is, you've spent the last several months blaming everybody but yourself, and actively told people to stop blaming you: https://bugzilla.redhat.com/show_bug.cgi?id=827538#c12 and have ignored patches that were sent to you: http://lists.freedesktop.org/archives/systemd-devel/2012-August/006357.html despite having clearly seen the patch (you *replied* to it, for chissake, and I even told you in that same thread why that reply was wrong at the time). > I also have no issues at all if the kernel does load the firmware from > the filesystem on its own; it sounds like the simplest and most robust > solution from a general look at the problem. It would also make the > difference between in-kernel firmware and out-of-kernel firmware less > visible, which sounds good. So now, after you've dismissed the patch that did the equivalent fix in udev (Ming Lei's patch basically disabled your idiotic and wrong sequence number test for firmware loading), you say it's ok to bypass udev entirely, because that is "more robust". Kay, you are so full of sh*t that it's not funny. You're refusing to acknowledge your bugs, you refuse to fix them even when a patch is sent to you, and then you make excuses for the fact that we have to work around *your* bugs, and say that we should have done so from the very beginning. Yes, doing it in the kernel is "more robust". But don't play games, and stop the lying. It's more robust because we have maintainers that care, and because we know that regressions are not something we can play fast and loose with. If something breaks, and we don't know what the right fix for that breakage is, we *revert* the thing that broke. So yes, we're clearly better off doing it in the kernel. Not because firmware loading cannot be done in user space. But simply because udev maintenance since Greg gave it up has gone downhill. Linus -- 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] libv4lconvert: clarify the behavior and resulting restrictions of v4lconvert_convert()
Signed-off-by: Frank Schäfer --- lib/include/libv4lconvert.h | 20 ++-- 1 Datei geändert, 18 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-) diff --git a/lib/include/libv4lconvert.h b/lib/include/libv4lconvert.h index 167b57d..509655e 100644 --- a/lib/include/libv4lconvert.h +++ b/lib/include/libv4lconvert.h @@ -89,8 +89,24 @@ LIBV4L_PUBLIC int v4lconvert_needs_conversion(struct v4lconvert_data *data, const struct v4l2_format *src_fmt, /* in */ const struct v4l2_format *dest_fmt); /* in */ -/* return value of -1 on error, otherwise the amount of bytes written to - dest */ +/* This function does the following conversions: +- format conversion +- cropping + if enabled: +- processing (auto whitebalance, auto gain, gamma correction) +- horizontal/vertical flipping +- 90 degree (clockwise) rotation + + NOTE: the last 3 steps are enabled/disabled depending on +- the internal device list +- the state of the (software emulated) image controls + + Therefore this function should +- not be used when getting the frames from libv4l +- be called only once per frame + Otherwise this may result in unintended double conversions ! + + Returns the amount of bytes written to dest an -1 on error */ LIBV4L_PUBLIC int v4lconvert_convert(struct v4lconvert_data *data, const struct v4l2_format *src_fmt, /* in */ const struct v4l2_format *dest_fmt, /* in */ -- 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: qv4l2-bug / libv4lconvert API issue
Am 03.10.2012 15:32, schrieb Hans Verkuil: > On Wed 3 October 2012 12:22:48 Frank Schäfer wrote: >> Hi Hans, >> >> Am 30.09.2012 11:54, schrieb Hans de Goede: >>> Hi, >>> >>> On 09/28/2012 07:09 PM, Frank Schäfer wrote: Hi, Am 27.09.2012 21:41, schrieb Hans de Goede: > Hi, > > On 09/27/2012 03:20 PM, Frank Schäfer wrote: > > > >>> What you've found is a qv4l2 bug (do you have the latest version?) >> Of course, I'm using the latest developer version. >> >> Even if this is just a qv4l2-bug: how do you want to fix it without >> removing the format selction feature ? > Well, if qv4l2 can only handle rgb24 data, then it should gray out the > format selection (fixing it at rgb24) when not in raw mode. So you say "just remove this feature from qv4l2". I prefer fixing the library / API instead. >>> No I'm suggesting to keep the feature to select which input format >>> to use when in raw mode, while at the same time disabling the feature) >>> when in libv4l2 mode. What use is it to ask libv4l2 for say YUV420 data >>> and then later ask libv4lconvert to convert this to RGB24, when you could >>> have asked libv4l2 for RGB24 right away. >> I assume the idea behind input format selction when using libv4l2 is to >> provide a possibilty to test libv4l2 ? > The main reason why I show all formats is that the driver reports all these > formats, so one should be able to select them in order to test the driver. > > And I'm using libv4l2convert so that I can actually see a picture. For formats > like MPEG that are unsupported by libv4l2convert I just dump the 'image' as > is. Yes, but for pure testing of the driver output formats, it is better to open the device in raw mode and convert the picture for GUI-output with a v4lconvert_convert() call. > It is counterintuitive if a YUV format is converted to a proper picture using > qv4l2 -r, but that it is all wrong with qv4l2. I'm not sure I understand what you mean... Regards, Frank > I'm all for improving the library. > > 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
[GIT PULL FOR v3.7] V4L: s5p-fimc: support for interleaved image data capture
Hi Mauro, The following changes since commit 2425bb3d4016ed95ce83a90b53bd92c7f31091e4: em28xx: regression fix: use DRX-K sync firmware requests on em28xx (2012-10-02 17:15:22 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l_for_mauro for you to fetch changes up to 7f06319c3a6e99fcdf9774556384c62661a31940: m5mols: Implement .get_frame_desc subdev callback (2012-10-03 13:01:25 +0200) This includes a few more s5p-* driver updates and fixes, addition of a fourcc and media bus pixel code for S5C73M3 camera, some new v4l2 subdev callbacks for low level media bus frame parameters and a helper for capture of frame embedded data. Hans Verkuil (2): s5p-g2d: fix compiler warning s5p-fimc: fix compiler warning Sylwester Nawrocki (7): V4L: Add s_rx_buffer subdev video operation V4L: Add [get/set]_frame_desc subdev callbacks V4L: Add V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8 media bus format V4L: Add V4L2_PIX_FMT_S5C_UYVY_JPG fourcc definition s5p-csis: Add support for non-image data packets capture s5p-fimc: Add support for V4L2_PIX_FMT_S5C_UYVY_JPG fourcc m5mols: Implement .get_frame_desc subdev callback Thomas Abraham (1): s5p-jpeg: use clk_prepare_enable and clk_disable_unprepare Documentation/DocBook/media/v4l/compat.xml |4 + Documentation/DocBook/media/v4l/pixfmt.xml | 28 Documentation/DocBook/media/v4l/subdev-formats.xml | 44 +++ drivers/media/i2c/m5mols/m5mols.h |9 ++ drivers/media/i2c/m5mols/m5mols_capture.c |3 + drivers/media/i2c/m5mols/m5mols_core.c | 47 +++ drivers/media/i2c/m5mols/m5mols_reg.h |1 + drivers/media/platform/s5p-fimc/fimc-capture.c | 135 +--- drivers/media/platform/s5p-fimc/fimc-core.c| 19 ++- drivers/media/platform/s5p-fimc/fimc-core.h| 28 +++- drivers/media/platform/s5p-fimc/fimc-m2m.c | 25 ++-- drivers/media/platform/s5p-fimc/fimc-reg.c | 23 +++- drivers/media/platform/s5p-fimc/fimc-reg.h |3 +- drivers/media/platform/s5p-fimc/mipi-csis.c| 52 +++- drivers/media/platform/s5p-g2d/g2d.c |2 +- drivers/media/platform/s5p-jpeg/jpeg-core.c|6 +- include/linux/v4l2-mediabus.h |5 + include/linux/videodev2.h |1 + include/media/v4l2-subdev.h| 48 +++ 19 files changed, 433 insertions(+), 50 deletions(-) --- Thanks, Sylwester -- 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 10:09 AM, Al Viro wrote:
>
> + if (!S_ISREG(inode->i_mode))
> + return false;
> + size = i_size_read(inode);
>
> Probably better to do vfs_getattr() and check mode and size in kstat; if
> it's sufficiently hot for that to hurt, we are fucked anyway.
>
> + file = filp_open(path, O_RDONLY, 0);
> + if (IS_ERR(file))
> + continue;
> +printk("from file '%s' ", path);
> + success = fw_read_file_contents(file, fw);
> + filp_close(file, NULL);
>
> fput(file), please. We have enough misuses of filp_close() as it is...
Ok, like this?
Linus
patch.diff
Description: Binary data
Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 6:57 PM, Greg KH wrote: >> It's the same in the current release, we still haven't wrapped our >> head around how to fix it/work around it. > > Ick, as this is breaking people's previously-working machines, shouldn't > this be resolved quickly? Nothing really "breaks", It's "slow" and it will surely be fixed when we know what's the right fix, which we haven't sorted out at this moment. > module_init() can do lots of "bad" things, sleeping, asking for > firmware, and lots of other things. To have userspace block because of > this doesn't seem very wise. Not saying that it is right or nice, but it's the kernel itself that blocks. Run init=/bin/sh and do a modprobe of one of these drivers and it hangs un-interruptible until the kernel's internal firmware loading request times out, just because userspace is not there. > But previously this all "just worked" as we ran 'modprobe' in a new > thread/process right? No, we used to un-queue events which had a timeout specified in the environment, that code caused other issues and was removed. > it can do without worrying about stopping anything else in the system that > might > want to happen at the same time (like load multiple modules in a row). It should not be an issue, the serialization is strictly parent <-> child, everything else runs in parallel. >> If that unfortunate module_init() lockup can't be solved properly in >> the kernel, we need to find out if we need to make the modprobe >> handling in udev async, or let firmware events bypass dependency >> resolving. As mentioned, we haven't decided as of now which road to >> take here. > > It's not a lockup, there have never been rules about what a driver could > and could not do in its module_init() function. Sure, there are some > not-nice drivers out there, but don't halt the whole system just because > of them. It is a kind of lock up, just try modprobe with the init=/bin/sh boot. > I recommend making module loading async, like it used to be, and then > all should be fine, right? That's the current idea, and Tom is looking into it how it could look like. I also have no issues at all if the kernel does load the firmware from the filesystem on its own; it sounds like the simplest and most robust solution from a general look at the problem. It would also make the difference between in-kernel firmware and out-of-kernel firmware less visible, which sounds good. Honestly, requiring firmware-loading userspace-transactions to successfully link a module into the kernel sounds like a pretty bad idea to start with. Unlike module loading which needs the depmod alias database and userspace configuration; with firmware loading, there is no policy involved where userspace would add any single additional value to that step. Thanks, Kay -- 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 03, 2012 at 09:38:52AM -0700, Linus Torvalds wrote:
> Yeah, that bugzilla shows the problem with Kay as a maintainer too,
> not willing to own up to problems he caused.
>
> Can you actually see the problem? I did add the attached patch as an
> attachment to the bugzilla, so the reporter there may be able to test
> it, but it's been open for a long while..
>
> Anyway. Attached is a really stupid patch that tries to do the "direct
> firmware load" as suggested by Ivan. It has not been tested very
> extensively at all (but I did test that it loaded the brcmsmac
> firmware images on my laptop so it has the *potential* to work).
+ if (!S_ISREG(inode->i_mode))
+ return false;
+ size = i_size_read(inode);
Probably better to do vfs_getattr() and check mode and size in kstat; if
it's sufficiently hot for that to hurt, we are fucked anyway.
+ file = filp_open(path, O_RDONLY, 0);
+ if (IS_ERR(file))
+ continue;
+printk("from file '%s' ", path);
+ success = fw_read_file_contents(file, fw);
+ filp_close(file, NULL);
fput(file), please. We have enough misuses of filp_close() as it is...
> We are apparently better off trying to avoid udev like the plague.
> Doing something very similar to this for module loading is probably a
> good idea too.
That, or just adding usr/udev in the kernel git tree and telling the
vertical integrators to go kiss a lamprey...
--
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 v10 6/7] [media] s5p-mfc: MFCv6 register definitions
From: Jeongtae Park Adds register definitions for MFC v6.x firmware Signed-off-by: Jeongtae Park Signed-off-by: Janghyuck Kim Signed-off-by: Jaeryul Oh Signed-off-by: Naveen Krishna Chatradhi Signed-off-by: Arun Kumar K --- drivers/media/platform/s5p-mfc/regs-mfc-v6.h | 408 ++ 1 files changed, 408 insertions(+), 0 deletions(-) create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v6.h diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h new file mode 100644 index 000..363a97c --- /dev/null +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h @@ -0,0 +1,408 @@ +/* + * Register definition file for Samsung MFC V6.x Interface (FIMV) driver + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef _REGS_FIMV_V6_H +#define _REGS_FIMV_V6_H + +#include +#include + +#define S5P_FIMV_REG_SIZE_V6 (S5P_FIMV_END_ADDR - S5P_FIMV_START_ADDR) +#define S5P_FIMV_REG_COUNT_V6 ((S5P_FIMV_END_ADDR - S5P_FIMV_START_ADDR) / 4) + +/* Number of bits that the buffer address should be shifted for particular + * MFC buffers. */ +#define S5P_FIMV_MEM_OFFSET_V6 0 + +#define S5P_FIMV_START_ADDR_V6 0x +#define S5P_FIMV_END_ADDR_V6 0xfd80 + +#define S5P_FIMV_REG_CLEAR_BEGIN_V60xf000 +#define S5P_FIMV_REG_CLEAR_COUNT_V61024 + +/* Codec Common Registers */ +#define S5P_FIMV_RISC_ON_V60x +#define S5P_FIMV_RISC2HOST_INT_V6 0x003C +#define S5P_FIMV_HOST2RISC_INT_V6 0x0044 +#define S5P_FIMV_RISC_BASE_ADDRESS_V6 0x0054 + +#define S5P_FIMV_MFC_RESET_V6 0x1070 + +#define S5P_FIMV_HOST2RISC_CMD_V6 0x1100 +#define S5P_FIMV_H2R_CMD_EMPTY_V6 0 +#define S5P_FIMV_H2R_CMD_SYS_INIT_V6 1 +#define S5P_FIMV_H2R_CMD_OPEN_INSTANCE_V6 2 +#define S5P_FIMV_CH_SEQ_HEADER_V6 3 +#define S5P_FIMV_CH_INIT_BUFS_V6 4 +#define S5P_FIMV_CH_FRAME_START_V6 5 +#define S5P_FIMV_H2R_CMD_CLOSE_INSTANCE_V6 6 +#define S5P_FIMV_H2R_CMD_SLEEP_V6 7 +#define S5P_FIMV_H2R_CMD_WAKEUP_V6 8 +#define S5P_FIMV_CH_LAST_FRAME_V6 9 +#define S5P_FIMV_H2R_CMD_FLUSH_V6 10 +/* RMVME: REALLOC used? */ +#define S5P_FIMV_CH_FRAME_START_REALLOC_V6 5 + +#define S5P_FIMV_RISC2HOST_CMD_V6 0x1104 +#define S5P_FIMV_R2H_CMD_EMPTY_V6 0 +#define S5P_FIMV_R2H_CMD_SYS_INIT_RET_V6 1 +#define S5P_FIMV_R2H_CMD_OPEN_INSTANCE_RET_V6 2 +#define S5P_FIMV_R2H_CMD_SEQ_DONE_RET_V6 3 +#define S5P_FIMV_R2H_CMD_INIT_BUFFERS_RET_V6 4 + +#define S5P_FIMV_R2H_CMD_CLOSE_INSTANCE_RET_V6 6 +#define S5P_FIMV_R2H_CMD_SLEEP_RET_V6 7 +#define S5P_FIMV_R2H_CMD_WAKEUP_RET_V6 8 +#define S5P_FIMV_R2H_CMD_COMPLETE_SEQ_RET_V6 9 +#define S5P_FIMV_R2H_CMD_DPB_FLUSH_RET_V6 10 +#define S5P_FIMV_R2H_CMD_NAL_ABORT_RET_V6 11 +#define S5P_FIMV_R2H_CMD_FW_STATUS_RET_V6 12 +#define S5P_FIMV_R2H_CMD_FRAME_DONE_RET_V6 13 +#define S5P_FIMV_R2H_CMD_FIELD_DONE_RET_V6 14 +#define S5P_FIMV_R2H_CMD_SLICE_DONE_RET_V6 15 +#define S5P_FIMV_R2H_CMD_ENC_BUFFER_FUL_RET_V6 16 +#define S5P_FIMV_R2H_CMD_ERR_RET_V632 + +#define S5P_FIMV_FW_VERSION_V6 0xf000 + +#define S5P_FIMV_INSTANCE_ID_V60xf008 +#define S5P_FIMV_CODEC_TYPE_V6 0xf00c +#define S5P_FIMV_CONTEXT_MEM_ADDR_V6 0xf014 +#define S5P_FIMV_CONTEXT_MEM_SIZE_V6 0xf018 +#define S5P_FIMV_PIXEL_FORMAT_V6 0xf020 + +#define S5P_FIMV_METADATA_ENABLE_V60xf024 +#define S5P_FIMV_DBG_BUFFER_ADDR_V60xf030 +#define S5P_FIMV_DBG_BUFFER_SIZE_V60xf034 +#define S5P_FIMV_RET_INSTANCE_ID_V60xf070 + +#define S5P_FIMV_ERROR_CODE_V6 0xf074 +#define S5P_FIMV_ERR_WARNINGS_START_V6 160 +#define S5P_FIMV_ERR_DEC_MASK_V6 0x +#define S5P_FIMV_ERR_DEC_SHIFT_V6 0 +#define S5P_FIMV_ERR_DSPL_MASK_V6 0x +#define S5P_FIMV_ERR_DSPL_SHIFT_V6 16 + +#define S5P_FIMV_DBG_BUFFER_OUTPUT_SIZE_V6 0xf078 +#define S5P_FIMV_METADATA_STATUS_V60xf07C +#define S5P_FIMV_METADATA_ADDR_MB_INFO_V6 0xf080 +#define S5P_FIMV_METADATA_SIZE_MB_INFO_V6 0xf084 + +/* Decoder Registers */ +#define S5P_FIMV_D_CRC_CTRL_V6 0xf0b0 +#define S5P_FIMV_D_DEC_OPTIONS_V6 0xf0b4 +#define S5P_FIMV_D_OPT_FMO_ASO_CTRL_MASK_V64 +#define S5P_FIMV_D_OPT_DDELAY_EN_SHIFT_V6 3 +#define S5P_FIMV_D_OPT_LF_CTRL_SHIFT_V61 +#define S5P_FIMV_D_OPT_LF_CTRL_MASK_V6 0x3 +#define S5P_FIMV_D_OPT_TILE_M
[PATCH v10 5/7] [media] s5p-mfc: Add MFC variant data to device context
MFC variant data replaces various macros used in the driver
which will change in a different version of MFC hardware.
Also does a cleanup of MFC context structure and common files.
Signed-off-by: Jeongtae Park
Signed-off-by: Janghyuck Kim
Signed-off-by: Jaeryul Oh
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: Arun Kumar K
---
drivers/media/platform/s5p-mfc/regs-mfc.h | 20 ++
drivers/media/platform/s5p-mfc/s5p_mfc.c| 78 +
drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c |4 +-
drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 85 ++
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |7 +-
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 44 +
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 213 +++
7 files changed, 266 insertions(+), 185 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc.h
b/drivers/media/platform/s5p-mfc/regs-mfc.h
index a19bece..f33c54d 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc.h
@@ -12,6 +12,9 @@
#ifndef _REGS_FIMV_H
#define _REGS_FIMV_H
+#include
+#include
+
#define S5P_FIMV_REG_SIZE (S5P_FIMV_END_ADDR - S5P_FIMV_START_ADDR)
#define S5P_FIMV_REG_COUNT ((S5P_FIMV_END_ADDR - S5P_FIMV_START_ADDR) / 4)
@@ -414,5 +417,22 @@
#define S5P_FIMV_SHARED_EXTENDED_SAR 0x0078
#define S5P_FIMV_SHARED_H264_I_PERIOD 0x009C
#define S5P_FIMV_SHARED_RC_CONTROL_CONFIG 0x00A0
+#define S5P_FIMV_SHARED_DISP_FRAME_TYPE_SHIFT 2
+
+/* Offset used by the hardware to store addresses */
+#define MFC_OFFSET_SHIFT 11
+
+#define FIRMWARE_ALIGN (128 * SZ_1K) /* 128KB */
+#define MFC_H264_CTX_BUF_SIZE (600 * SZ_1K) /* 600KB per H264 instance */
+#define MFC_CTX_BUF_SIZE (10 * SZ_1K)/* 10KB per instance */
+#define DESC_BUF_SIZE (128 * SZ_1K) /* 128KB for DESC buffer */
+#define SHARED_BUF_SIZE(8 * SZ_1K) /* 8KB for shared
buffer */
+
+#define DEF_CPB_SIZE (256 * SZ_1K) /* 256KB */
+#define MAX_CPB_SIZE (4 * SZ_1M) /* 4MB */
+#define MAX_FW_SIZE(384 * SZ_1K)
+
+#define MFC_VERSION0x51
+#define MFC_NUM_PORTS 2
#endif /* _REGS_FIMV_H */
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index d711b0f..7feae81 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -477,7 +477,6 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx *ctx,
unsigned int reason, unsigned int err)
{
struct s5p_mfc_dev *dev;
- unsigned int guard_width, guard_height;
if (ctx == NULL)
return;
@@ -491,40 +490,8 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx
*ctx,
ctx->img_height = s5p_mfc_hw_call(dev->mfc_ops, get_img_height,
dev);
- ctx->buf_width = ALIGN(ctx->img_width,
- S5P_FIMV_NV12MT_HALIGN);
- ctx->buf_height = ALIGN(ctx->img_height,
- S5P_FIMV_NV12MT_VALIGN);
- mfc_debug(2, "SEQ Done: Movie dimensions %dx%d, "
- "buffer dimensions: %dx%d\n", ctx->img_width,
- ctx->img_height, ctx->buf_width,
- ctx->buf_height);
- if (ctx->codec_mode == S5P_FIMV_CODEC_H264_DEC) {
- ctx->luma_size = ALIGN(ctx->buf_width *
- ctx->buf_height, S5P_FIMV_DEC_BUF_ALIGN);
- ctx->chroma_size = ALIGN(ctx->buf_width *
-ALIGN((ctx->img_height >> 1),
- S5P_FIMV_NV12MT_VALIGN),
- S5P_FIMV_DEC_BUF_ALIGN);
- ctx->mv_size = ALIGN(ctx->buf_width *
- ALIGN((ctx->buf_height >> 2),
- S5P_FIMV_NV12MT_VALIGN),
- S5P_FIMV_DEC_BUF_ALIGN);
- } else {
- guard_width = ALIGN(ctx->img_width + 24,
- S5P_FIMV_NV12MT_HALIGN);
- guard_height = ALIGN(ctx->img_height + 16,
- S5P_FIMV_NV12MT_VALIGN);
- ctx->luma_size = ALIGN(guard_width *
- guard_height, S5P_FIMV_DEC_BUF_ALIGN);
- guard_width = ALIGN(ctx->img_width + 16,
- S5P_FIMV_NV12MT_HALIGN);
- guard_height = ALIGN((ctx->img_height >> 1) + 4,
- S5P_FIMV_NV12MT_VALIGN);
-
[PATCH v10 2/7] [media] v4l: Add control definitions for new H264 encoder features
New controls are added for supporting H264 encoding features like - MVC frame packing - Flexible macroblock ordering - Arbitrary slice ordering - Hierarchical coding Signed-off-by: Jeongtae Park Signed-off-by: Naveen Krishna Chatradhi Signed-off-by: Arun Kumar K --- Documentation/DocBook/media/v4l/controls.xml | 268 +- drivers/media/v4l2-core/v4l2-ctrls.c | 42 include/linux/v4l2-controls.h| 41 3 files changed, 350 insertions(+), 1 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 272a5f7..09e09bd 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -1586,7 +1586,6 @@ frame counter of the frame that is currently displayed (decoded). This value is the decoder is started. - V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE @@ -2270,6 +2269,14 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders. + + V4L2_CID_MPEG_VIDEO_VBV_DELAY + integer + Sets the initial delay in milliseconds for +VBV buffer control. + + + V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE integer @@ -2334,6 +2341,265 @@ Applicable to the MPEG4 decoder. vop_time_increment value for MPEG4. Applicable to the MPEG4 encoder. + + + V4L2_CID_MPEG_VIDEO_H264_SEI_FRAME_PACKING + boolean + + Enable generation of frame packing supplemental enhancement information in the encoded bitstream. +The frame packing SEI message contains the arrangement of L and R planes for 3D viewing. Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_SEI_FP_CURRENT_FRAME_0 + boolean + + Sets current frame as frame0 in frame packing SEI. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE + enum v4l2_mpeg_video_h264_sei_fp_arrangement_type + + Frame packing arrangement type for H264 SEI. +Applicable to the H264 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_CHEKERBOARD + Pixels are alternatively from L and R. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_COLUMN + L and R are interlaced by column. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_ROW + L and R are interlaced by row. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_SIDE_BY_SIDE + L is on the left, R on the right. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TOP_BOTTOM + L is on top, R on bottom. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TEMPORAL + One view per frame. + + + + + + + + V4L2_CID_MPEG_VIDEO_H264_FMO + boolean + + Enables flexible macroblock ordering in the encoded bitstream. It is a technique +used for restructuring the ordering of macroblocks in pictures. Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_FMO_MAP_TYPE + enum v4l2_mpeg_video_h264_fmo_map_type + + When using FMO, the map type divides the image in different scan patterns of macroblocks. +Applicable to the H264 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_INTERLEAVED_SLICES + Slices are interleaved one after other with macroblocks in run length order. + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_SCATTERED_SLICES + Scatters the macroblocks based on a mathematical function known to both encoder and decoder. + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_FOREGROUND_WITH_LEFT_OVER + Macroblocks arranged in rectangular areas or regions of interest. +
[PATCH v10 1/7] [media] v4l: Add fourcc definitions for new formats
Adds the following new fourcc definitions.
For multiplanar YCbCr
- V4L2_PIX_FMT_NV21M
- V4L2_PIX_FMT_NV12MT_16X16
and compressed formats
- V4L2_PIX_FMT_H264_MVC
- V4L2_PIX_FMT_VP8
Signed-off-by: Jeongtae Park
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: Arun Kumar K
---
Documentation/DocBook/media/v4l/pixfmt-nv12m.xml | 17 -
Documentation/DocBook/media/v4l/pixfmt.xml | 10 ++
include/linux/videodev2.h|4
3 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
index 5274c24..a990b34 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
@@ -1,11 +1,13 @@
-
+
- V4L2_PIX_FMT_NV12M ('NM12')
+ V4L2_PIX_FMT_NV12M ('NM12'), V4L2_PIX_FMT_NV21M
('NM21'), V4L2_PIX_FMT_NV12MT_16X16
&manvol;
-V4L2_PIX_FMT_NV12M
- Variation of V4L2_PIX_FMT_NV12 with
planes
+ V4L2_PIX_FMT_NV12M
+ V4L2_PIX_FMT_NV21M
+ V4L2_PIX_FMT_NV12MT_16X16
+ Variation of V4L2_PIX_FMT_NV12 and
V4L2_PIX_FMT_NV21 with planes
non contiguous in memory.
@@ -22,7 +24,12 @@ The CbCr plane is the same width, in bytes, as the Y plane
(and of the image),
but is half as tall in pixels. Each CbCr pair belongs to four pixels. For
example,
Cb0/Cr0 belongs to
Y'00, Y'01,
-Y'10, Y'11.
+Y'10, Y'11.
+V4L2_PIX_FMT_NV12MT_16X16 is the tiled version of
+V4L2_PIX_FMT_NV12M with 16x16 macroblock tiles. Here
pixels
+are arranged in 16x16 2D tiles and tiles are arranged in linear order in
memory.
+V4L2_PIX_FMT_NV21M is the same as
V4L2_PIX_FMT_NV12M
+except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr
byte.
V4L2_PIX_FMT_NV12M is intended to be
used only in drivers and applications that support the multi-planar API,
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml
b/Documentation/DocBook/media/v4l/pixfmt.xml
index 1ddbfab..6ca0be4 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -758,6 +758,11 @@ extended control
V4L2_CID_MPEG_STREAM_TYPE, see
'AVC1'
H264 video elementary stream without start codes.
+
+ V4L2_PIX_FMT_H264_MVC
+ 'MVC'
+ H264 MVC video elementary stream.
+
V4L2_PIX_FMT_H263
'H263'
@@ -793,6 +798,11 @@ extended control
V4L2_CID_MPEG_STREAM_TYPE, see
'VC1L'
VC1, SMPTE 421M Annex L compliant stream.
+
+ V4L2_PIX_FMT_VP8
+ 'VP8'
+ VP8 video elementary stream.
+
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 61395ef..16e6ab0 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -366,7 +366,9 @@ struct v4l2_pix_format {
/* two non contiguous planes - one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr
4:2:0 */
+#define V4L2_PIX_FMT_NV21M v4l2_fourcc('N', 'M', '2', '1') /* 21 Y/CrCb
4:2:0 */
#define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr
4:2:0 64x32 macroblocks */
+#define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12
Y/CbCr 4:2:0 16x16 macroblocks */
/* three non contiguous planes - Y, Cb, Cr */
#define V4L2_PIX_FMT_YUV420M v4l2_fourcc('Y', 'M', '1', '2') /* 12 YUV420
planar */
@@ -403,6 +405,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4
Multiplexed */
#define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264 with
start codes */
#define V4L2_PIX_FMT_H264_NO_SC v4l2_fourcc('A', 'V', 'C', '1') /* H264
without start codes */
+#define V4L2_PIX_FMT_H264_MVC v4l2_fourcc('M', '2', '6', '4') /* H264 MVC */
#define V4L2_PIX_FMT_H263 v4l2_fourcc('H', '2', '6', '3') /* H263
*/
#define V4L2_PIX_FMT_MPEG1v4l2_fourcc('M', 'P', 'G', '1') /* MPEG-1 ES
*/
#define V4L2_PIX_FMT_MPEG2v4l2_fourcc('M', 'P', 'G', '2') /* MPEG-2 ES
*/
@@ -410,6 +413,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_XVID v4l2_fourcc('X', 'V', 'I', 'D') /* Xvid
*/
#define V4L2_PIX_FMT_VC1_ANNEX_G v4l2_fourcc('V', 'C', '1', 'G') /* SMPTE 421M
Annex G compliant stream */
#define V4L2_PIX_FMT_VC1_ANNEX_L v4l2_fourcc('V', 'C', '1', 'L') /* SMPTE 421M
Annex L compliant stream */
+#define V4L2_PIX_FMT_VP8 v4l2_fourcc('V', 'P', '8', '0') /* VP8 */
/* Vendor-specific formats */
#define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-me
[PATCH v10 0/7] Update MFC v4l2 driver to support MFC6.x
The patchset adds support for MFCv6 firmware in s5p-mfc driver. The patches are rebased to the latest media-tree. Changelog v10 - Rebased onto latest media-tree 3.7 staging - Split driver rearchitecture patch into two Changelog v9 - Addressed review comments by Hans Verkuil http://www.mail-archive.com/linux-media@vger.kernel.org/msg53016.html Changelog v8 - Addressed review comments by Sylwester Nawrocki http://www.mail-archive.com/linux-media@vger.kernel.org/msg52942.html Changelog v7 - Removed unused macros from register files Changelog v6 - Use s5p_mfc_hw_call macro to call all HW related ops and cmds - Rebased onto latest media-tree - Resending patches adding required v4l controls - Addressed review comments of Patch v5 Changelog v5 - Modified ops mechanism for macro based function call - Addressed all other review comments on Patch v4 Changelog v4 - Separate patch for callback based architecture. - Patches divided to enable incremental compilation. - Working MFCv6 encoder and decoder. - Addressed review comments given for v3 patchset. Changelog v3 - Supports MFCv5 and v6 co-existence. - Tested for encoding & decoding in MFCv5. - Supports only decoding in MFCv6 now. - Can be compiled with kernel image and as module. - Config macros for MFC version selection removed. - All previous review comments addressed. Changelog v2 - Addressed review comments received http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/45189 Changelog v1 - Fixed crash issue in Exynos4 SoCs running MFC 5.1 - Encoder not tested Arun Kumar K (5): [media] v4l: Add fourcc definitions for new formats [media] v4l: Add control definitions for new H264 encoder features [media] s5p-mfc: Prepare driver for callback based re-architecture [media] s5p-mfc: Update MFCv5 driver for callback based architecture [media] s5p-mfc: Add MFC variant data to device context Jeongtae Park (2): [media] s5p-mfc: MFCv6 register definitions [media] s5p-mfc: Update MFC v4l2 driver to support MFC6.x Documentation/DocBook/media/v4l/controls.xml | 268 +++- Documentation/DocBook/media/v4l/pixfmt-nv12m.xml | 17 +- Documentation/DocBook/media/v4l/pixfmt.xml | 10 + drivers/media/platform/Kconfig |4 +- drivers/media/platform/s5p-mfc/Makefile |7 +- drivers/media/platform/s5p-mfc/regs-mfc-v6.h | 408 + drivers/media/platform/s5p-mfc/regs-mfc.h| 41 + drivers/media/platform/s5p-mfc/s5p_mfc.c | 293 +++-- drivers/media/platform/s5p-mfc/s5p_mfc_cmd.c | 111 +-- drivers/media/platform/s5p-mfc/s5p_mfc_cmd.h | 17 +- drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c | 166 ++ drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.h | 20 + drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c | 156 ++ drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.h | 20 + drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 191 ++- drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c| 202 ++- drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h|1 + drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 258 ++- drivers/media/platform/s5p-mfc/s5p_mfc_dec.h |1 + drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 236 ++-- drivers/media/platform/s5p-mfc/s5p_mfc_enc.h |1 + drivers/media/platform/s5p-mfc/s5p_mfc_intr.c| 11 +- drivers/media/platform/s5p-mfc/s5p_mfc_opr.c | 1418 + drivers/media/platform/s5p-mfc/s5p_mfc_opr.h | 137 +- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 1794 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.h | 85 + drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 1956 ++ drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h | 50 + drivers/media/platform/s5p-mfc/s5p_mfc_pm.c |3 +- drivers/media/platform/s5p-mfc/s5p_mfc_shm.c | 47 - drivers/media/platform/s5p-mfc/s5p_mfc_shm.h | 90 - drivers/media/v4l2-core/v4l2-ctrls.c | 42 + include/linux/v4l2-controls.h| 41 + include/linux/videodev2.h|4 + 34 files changed, 5981 insertions(+), 2125 deletions(-) create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v6.h create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.h create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.h create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.h create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h delete mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_shm.c delete mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_shm.h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the bod
Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 9:38 AM, Linus Torvalds wrote: > > Anyway. Attached is a really stupid patch that tries to do the "direct > firmware load" as suggested by Ivan. It has not been tested very > extensively at all (but I did test that it loaded the brcmsmac > firmware images on my laptop so it has the *potential* to work). Oh, and I stupidly put the new functions next to the builtin firmware loading function, which means that the patch only works if you have CONFIG_FW_LOADER enabled. That's bogus, and the functions should be moved out of that #ifdef, but I don't think it should hurt testing. Linus -- 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 03, 2012 at 04:36:53PM +0200, Kay Sievers wrote: > On Wed, Oct 3, 2012 at 12:12 AM, Greg KH wrote: > > > Mauro, what version of udev are you using that is still showing this > > issue? > > > > Kay, didn't you resolve this already? If not, what was the reason why? > > It's the same in the current release, we still haven't wrapped our > head around how to fix it/work around it. Ick, as this is breaking people's previously-working machines, shouldn't this be resolved quickly? > Unlike what the heated and pretty uncivilized and rude emails here > claim, udev does not dead-lock or "break" things, it's just "slow". > The modprobe event handling runs into a ~30 second event timeout. > Everything is still fully functional though, there's only this delay. Mauro said it broke the video drivers. Mauro, if you wait 30 seconds, does everything then "work"? Not to say that waiting 30 seconds is a correct thing here... > Udev ensures full dependency resolution between parent and child > events. Parent events have to finish the event handling and have to > return, before child event handlers are started. We need to ensure > such things so that (among other things) disk events have finished > their operations before the partition events are started, so they can > rely and access their fully set up parent devices. > > What happens here is that the module_init() call blocks in a userspace > transaction, creating a child event that is not started until the > parent event has finished. The event handler for modprobe times out > then the child event loads the firmware. module_init() can do lots of "bad" things, sleeping, asking for firmware, and lots of other things. To have userspace block because of this doesn't seem very wise. > Having kernel module relying on a running and fully functional > userspace to return from module_init() is surely a broken driver > model, at least it's not how things should work. If userspace does not > respond to firmware requests, module_init() locks up until the > firmware timeout happens. But previously this all "just worked" as we ran 'modprobe' in a new thread/process right? What's wrong with going back to just execing modprobe and letting that process go off and do what ever it wants to do? It can't be that "expensive" as modprobe is a very slow thing, and it should solve this issue. udev will then have handled the 'a device has shown up, run modprobe' event in the correct order, and then anything else that the module_init() process wants to do, it can do without worrying about stopping anything else in the system that might want to happen at the same time (like load multiple modules in a row). > This all is not so much about how probe() should behave, it's about a > fragile dependency on a specific userspace transaction to link a > loadable module into the kernel. Drivers should avoid such loops for > many reasons. Also, it's unclear in many cases how such a model should > work at all if the module is compiled in and initialized when no > userspace is running. > > If that unfortunate module_init() lockup can't be solved properly in > the kernel, we need to find out if we need to make the modprobe > handling in udev async, or let firmware events bypass dependency > resolving. As mentioned, we haven't decided as of now which road to > take here. It's not a lockup, there have never been rules about what a driver could and could not do in its module_init() function. Sure, there are some not-nice drivers out there, but don't halt the whole system just because of them. I recommend making module loading async, like it used to be, and then all should be fine, right? That's also the way the mdev works, and I don't think that people have been having problems there. :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 8:13 AM, Mauro Carvalho Chehab wrote: > > Yes. The issue was noticed with media drivers when people started using the > drivers on Fedora 17, witch came with udev-182. There's an open > bugzilla there: > https://bugzilla.redhat.com/show_bug.cgi?id=827538 Yeah, that bugzilla shows the problem with Kay as a maintainer too, not willing to own up to problems he caused. Can you actually see the problem? I did add the attached patch as an attachment to the bugzilla, so the reporter there may be able to test it, but it's been open for a long while.. Anyway. Attached is a really stupid patch that tries to do the "direct firmware load" as suggested by Ivan. It has not been tested very extensively at all (but I did test that it loaded the brcmsmac firmware images on my laptop so it has the *potential* to work). It has a few extra printk's sprinkled in (to show whether it does anything or not), and it has a few other issues, but it might be worth testing as a starting point. We are apparently better off trying to avoid udev like the plague. Doing something very similar to this for module loading is probably a good idea too. I'm adding Ming Lei to the participants too, because hooking into the firmware loader like this means that the image doesn't get cached. Which is sad. I'm hoping Ming Lei might be open to trying to fix that. Hmm? Linus patch.diff Description: Binary data
Re: [PATCH v5] media: mt9p031/mt9t001/mt9v032: use V4L2_CID_TEST_PATTERN for test pattern control
Prabhakar wrote: From: Lad, Prabhakar V4L2_CID_TEST_PATTERN is now a standard control. This patch replaces the user defined control for test pattern to make use of standard control V4L2_CID_TEST_PATTERN. Signed-off-by: Lad, Prabhakar Signed-off-by: Manjunath Hadli Acked-by: Laurent Pinchart Cc: Sakari Ailus Cc: Paul Gortmaker Cc: Jean Delvare Thanks! Acked-by: Sakari Ailus -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
Em 02-10-2012 19:47, Linus Torvalds escreveu: > On Tue, Oct 2, 2012 at 3:23 PM, Greg KH wrote: >> >> which went into udev release 187 which I think corresponds to the place >> when people started having problems, right Mauro? > > According to what I've seen, people started complaining in 182, not 187. Yes. The issue was noticed with media drivers when people started using the drivers on Fedora 17, witch came with udev-182. There's an open bugzilla there: https://bugzilla.redhat.com/show_bug.cgi?id=827538 > See for example > > http://patchwork.linuxtv.org/patch/13085/ > > which is a thread where you were involved too.. > > See also the arch linux thread: > > https://bbs.archlinux.org/viewtopic.php?id=134012&p=1 > > And see this email from Kay Sievers that shows that it was all known > about and intentional in the udev camp: > > http://www.spinics.net/lists/netdev/msg185742.html > > There's a possible patch suggested here: > > http://lists.freedesktop.org/archives/systemd-devel/2012-August/006357.html > > but quite frankly, I am leery of the fact that the udev maintenance > seems to have gone into some "crazy mode" where they have made changes > that were known to be problematic, and are pure and utter stupidity. > > Having the module init path load the firmware IS THE SENSIBLE AND > OBVIOUS THING TO DO for many cases. Yes, that is the case for most media devices. Some devices can only be detected as a supported device after the firmware load, as we need the firmware for the USB (or PCI) bridge to be there, in order to talk with the media components under the board's internal I2C bus, as sometimes the same USB/PCI ID is used by boards with different internal components. > The fact that udev people have > apparently unilaterally decided that it's somehow wrong is scary. > Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 7:36 AM, Kay Sievers wrote: > > If that unfortunate module_init() lockup can't be solved properly in > the kernel Stop this idiocy. The kernel doesn't have a lockup problem. udev does. As even you admit, it is *udev* that has the whole serialization issue, and does excessive (and incorrect) serialization between events. Resulting in the kernel timing out a udev event that takes too long. The fact that you then continually try to make this a "kernel issue" is just disgusting. Talking about the kernel solving it "properly" is pretty dishonest, when the kernel wasn't the problem in the first place. The kernel not only does things right, but this all used to work fine. Linus -- 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 12:12 AM, Greg KH wrote: > Mauro, what version of udev are you using that is still showing this > issue? > > Kay, didn't you resolve this already? If not, what was the reason why? It's the same in the current release, we still haven't wrapped our head around how to fix it/work around it. Unlike what the heated and pretty uncivilized and rude emails here claim, udev does not dead-lock or "break" things, it's just "slow". The modprobe event handling runs into a ~30 second event timeout. Everything is still fully functional though, there's only this delay. Udev ensures full dependency resolution between parent and child events. Parent events have to finish the event handling and have to return, before child event handlers are started. We need to ensure such things so that (among other things) disk events have finished their operations before the partition events are started, so they can rely and access their fully set up parent devices. What happens here is that the module_init() call blocks in a userspace transaction, creating a child event that is not started until the parent event has finished. The event handler for modprobe times out then the child event loads the firmware. Having kernel module relying on a running and fully functional userspace to return from module_init() is surely a broken driver model, at least it's not how things should work. If userspace does not respond to firmware requests, module_init() locks up until the firmware timeout happens. This all is not so much about how probe() should behave, it's about a fragile dependency on a specific userspace transaction to link a loadable module into the kernel. Drivers should avoid such loops for many reasons. Also, it's unclear in many cases how such a model should work at all if the module is compiled in and initialized when no userspace is running. If that unfortunate module_init() lockup can't be solved properly in the kernel, we need to find out if we need to make the modprobe handling in udev async, or let firmware events bypass dependency resolving. As mentioned, we haven't decided as of now which road to take here. Thanks, Kay -- 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 v5] media: mt9p031/mt9t001/mt9v032: use V4L2_CID_TEST_PATTERN for test pattern control
Hi Prabhakar, On Wednesday 03 October 2012 19:23:05 Prabhakar wrote: > From: Lad, Prabhakar > > V4L2_CID_TEST_PATTERN is now a standard control. > This patch replaces the user defined control for test > pattern to make use of standard control V4L2_CID_TEST_PATTERN. > > Signed-off-by: Lad, Prabhakar > Signed-off-by: Manjunath Hadli > Acked-by: Laurent Pinchart > Cc: Sakari Ailus > Cc: Paul Gortmaker > Cc: Jean Delvare Should I push this patch through my tree ? If so I'll wait until the V4L2_CID_TEST_PATTERN control patch hits Mauro's tree. -- 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
Em 02-10-2012 19:23, Greg KH escreveu: > On Tue, Oct 02, 2012 at 03:12:39PM -0700, Greg KH wrote: >> On Tue, Oct 02, 2012 at 09:33:03AM -0700, Linus Torvalds wrote: >>> I don't know where the problem started in udev, but the report I saw >>> was that udev175 was fine, and udev182 was broken, and would deadlock >>> if module_init() did a request_firmware(). That kind of nested >>> behavior is absolutely *required* to work, in order to not cause >>> idiotic problems for the kernel for no good reason. >>> >>> What kind of insane udev maintainership do we have? And can we fix it? >>> >>> Greg, I think you need to step up here too. You were the one who let >>> udev go. If the new maintainers are causing problems, they need to be >>> fixed some way. >> >> I've talked about this with Kay in the past (Plumbers conference I >> think) and I thought he said it was all fixed in the latest version of >> udev so there shouldn't be any problems anymore with this. >> >> Mauro, what version of udev are you using that is still showing this >> issue? >> >> Kay, didn't you resolve this already? If not, what was the reason why? > > Hm, in digging through the udev tree, the only change I found was this > one: > > commit 39177382a4f92a834b568d6ae5d750eb2a5a86f9 > Author: Kay Sievers > Date: Thu Jul 19 12:32:24 2012 +0200 > > udev: firmware - do not cancel requests in the initrd > > diff --git a/src/udev/udev-builtin-firmware.c > b/src/udev/udev-builtin-firmware.c > index 56dc8fc..de93d7b 100644 > --- a/src/udev/udev-builtin-firmware.c > +++ b/src/udev/udev-builtin-firmware.c > @@ -129,7 +129,13 @@ static int builtin_firmware(struct udev_device *dev, int > argc, char *argv[], boo > err = -errno; > } while (err == -ENOENT); > rc = EXIT_FAILURE; > -set_loading(udev, loadpath, "-1"); > +/* > + * Do not cancel the request in the initrd, the real root > might have > + * the firmware file and the 'coldplug' run in the real root > will find > + * this pending request and fulfill or cancel it. > + * */ > +if (!in_initrd()) > +set_loading(udev, loadpath, "-1"); > goto exit; > } > > > which went into udev release 187 which I think corresponds to the place > when people started having problems, right Mauro? I'm using here udev-182. > If so, Mauro, is the solution just putting the firmware into the initrd? I don't think that putting firmware on initrd is something that we want to for media drivers. None of the webcam drivers currently need a firmware; those are required on more complex devices (typically digital TV ones). While there are a number of PCI devices that require firmware, in practice, we're seeing more people using USB devices. IMO, it doesn't make any sense that a hot-pluggable USB device to require a firmware at initrd/initramfs, with is available only at boot time. > No wait, it looks like this change was trying to fix the problem where > firmware files were not in the initrd, so it would stick around for the > real root to show up so that they could be loaded. > > So this looks like it was fixing firmware loading problems for people? I'll run some tests with this patch applied and see what happens. > Kay, am I just looking at the totally wrong place here, and this file in > udev didn't have anything to do with the breakage? > > thanks, > > greg k-h > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] media: mt9p031/mt9t001/mt9v032: use V4L2_CID_TEST_PATTERN for test pattern control
From: Lad, Prabhakar
V4L2_CID_TEST_PATTERN is now a standard control.
This patch replaces the user defined control for test
pattern to make use of standard control V4L2_CID_TEST_PATTERN.
Signed-off-by: Lad, Prabhakar
Signed-off-by: Manjunath Hadli
Acked-by: Laurent Pinchart
Cc: Sakari Ailus
Cc: Paul Gortmaker
Cc: Jean Delvare
---
Changes for v5:
1: Fixed the min value of mt9v032_test_pattern_color control
to zero which wrongly set to 4, pointed out by Laurent.
Changes for v4:
1: Fixed some grammatical issues, pointed by Laurent.
Changes for v3:
1: Used cluster in mt9v032 for test pattern,
pointed by Laurent.
Changes for v2:
1: Fixed review comments pointed by Laurent.
drivers/media/i2c/mt9p031.c | 19 ---
drivers/media/i2c/mt9t001.c | 22 -
drivers/media/i2c/mt9v032.c | 54 +++---
3 files changed, 55 insertions(+), 40 deletions(-)
diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
index 2c0f407..e328332 100644
--- a/drivers/media/i2c/mt9p031.c
+++ b/drivers/media/i2c/mt9p031.c
@@ -574,7 +574,6 @@ static int mt9p031_set_crop(struct v4l2_subdev *subdev,
* V4L2 subdev control operations
*/
-#define V4L2_CID_TEST_PATTERN (V4L2_CID_USER_BASE | 0x1001)
#define V4L2_CID_BLC_AUTO (V4L2_CID_USER_BASE | 0x1002)
#define V4L2_CID_BLC_TARGET_LEVEL (V4L2_CID_USER_BASE | 0x1003)
#define V4L2_CID_BLC_ANALOG_OFFSET (V4L2_CID_USER_BASE | 0x1004)
@@ -740,18 +739,6 @@ static const char * const mt9p031_test_pattern_menu[] = {
static const struct v4l2_ctrl_config mt9p031_ctrls[] = {
{
.ops= &mt9p031_ctrl_ops,
- .id = V4L2_CID_TEST_PATTERN,
- .type = V4L2_CTRL_TYPE_MENU,
- .name = "Test Pattern",
- .min= 0,
- .max= ARRAY_SIZE(mt9p031_test_pattern_menu) - 1,
- .step = 0,
- .def= 0,
- .flags = 0,
- .menu_skip_mask = 0,
- .qmenu = mt9p031_test_pattern_menu,
- }, {
- .ops= &mt9p031_ctrl_ops,
.id = V4L2_CID_BLC_AUTO,
.type = V4L2_CTRL_TYPE_BOOLEAN,
.name = "BLC, Auto",
@@ -950,7 +937,7 @@ static int mt9p031_probe(struct i2c_client *client,
mt9p031->model = did->driver_data;
mt9p031->reset = -1;
- v4l2_ctrl_handler_init(&mt9p031->ctrls, ARRAY_SIZE(mt9p031_ctrls) + 5);
+ v4l2_ctrl_handler_init(&mt9p031->ctrls, ARRAY_SIZE(mt9p031_ctrls) + 6);
v4l2_ctrl_new_std(&mt9p031->ctrls, &mt9p031_ctrl_ops,
V4L2_CID_EXPOSURE, MT9P031_SHUTTER_WIDTH_MIN,
@@ -966,6 +953,10 @@ static int mt9p031_probe(struct i2c_client *client,
v4l2_ctrl_new_std(&mt9p031->ctrls, &mt9p031_ctrl_ops,
V4L2_CID_PIXEL_RATE, pdata->target_freq,
pdata->target_freq, 1, pdata->target_freq);
+ v4l2_ctrl_new_std_menu_items(&mt9p031->ctrls, &mt9p031_ctrl_ops,
+ V4L2_CID_TEST_PATTERN,
+ ARRAY_SIZE(mt9p031_test_pattern_menu) - 1, 0,
+ 0, mt9p031_test_pattern_menu);
for (i = 0; i < ARRAY_SIZE(mt9p031_ctrls); ++i)
v4l2_ctrl_new_custom(&mt9p031->ctrls, &mt9p031_ctrls[i], NULL);
diff --git a/drivers/media/i2c/mt9t001.c b/drivers/media/i2c/mt9t001.c
index 6d343ad..2e189d8 100644
--- a/drivers/media/i2c/mt9t001.c
+++ b/drivers/media/i2c/mt9t001.c
@@ -371,7 +371,7 @@ static int mt9t001_set_crop(struct v4l2_subdev *subdev,
* V4L2 subdev control operations
*/
-#define V4L2_CID_TEST_PATTERN (V4L2_CID_USER_BASE | 0x1001)
+#define V4L2_CID_TEST_PATTERN_COLOR(V4L2_CID_USER_BASE | 0x1001)
#define V4L2_CID_BLACK_LEVEL_AUTO (V4L2_CID_USER_BASE | 0x1002)
#define V4L2_CID_BLACK_LEVEL_OFFSET(V4L2_CID_USER_BASE | 0x1003)
#define V4L2_CID_BLACK_LEVEL_CALIBRATE (V4L2_CID_USER_BASE | 0x1004)
@@ -487,12 +487,11 @@ static int mt9t001_s_ctrl(struct v4l2_ctrl *ctrl)
ctrl->val >> 16);
case V4L2_CID_TEST_PATTERN:
- ret = mt9t001_set_output_control(mt9t001,
+ return mt9t001_set_output_control(mt9t001,
ctrl->val ? 0 : MT9T001_OUTPUT_CONTROL_TEST_DATA,
ctrl->val ? MT9T001_OUTPUT_CONTROL_TEST_DATA : 0);
- if (ret < 0)
- return ret;
+ case V4L2_CID_TEST_PATTERN_COLOR:
return mt9t001_write(client, MT9T001_TEST_DATA, ctrl->val << 2);
case V4L2_CID_BLACK_LEVEL_AUTO:
@@ -533,12 +532,17 @@ static struct v4l2_ctrl_ops mt9t001_ctrl_ops = {
.s_ctrl = mt9t001_s_ctrl,
};
+static const char * const mt9t001_test_pattern_menu[] = {
+ "
[PATCH] media: davinci: vpif: Add return code check at vb2_queue_init()
From: Lad, Prabhakar
from commit with id 896f38f582730a19eb49677105b4fe4c0270b82e
it's mandatory to check the return code of vb2_queue_init().
Signed-off-by: Lad, Prabhakar
Signed-off-by: Manjunath Hadli
Cc: Hans Verkuil
---
drivers/media/platform/davinci/vpif_capture.c |8 ++--
drivers/media/platform/davinci/vpif_display.c |8 ++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 83b80ba..3521725 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -976,6 +976,7 @@ static int vpif_reqbufs(struct file *file, void *priv,
struct common_obj *common;
u8 index = 0;
struct vb2_queue *q;
+ int ret;
vpif_dbg(2, debug, "vpif_reqbufs\n");
@@ -1015,8 +1016,11 @@ static int vpif_reqbufs(struct file *file, void *priv,
q->mem_ops = &vb2_dma_contig_memops;
q->buf_struct_size = sizeof(struct vpif_cap_buffer);
- vb2_queue_init(q);
-
+ ret = vb2_queue_init(q);
+ if (ret) {
+ vpif_err("vpif_capture: vb2_queue_init() failed\n");
+ return ret;
+ }
/* Set io allowed member of file handle to TRUE */
fh->io_allowed[index] = 1;
/* Increment io usrs member of channel object to 1 */
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index ae8329d..84cee9d 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -936,6 +936,7 @@ static int vpif_reqbufs(struct file *file, void *priv,
enum v4l2_field field;
struct vb2_queue *q;
u8 index = 0;
+ int ret;
/* This file handle has not initialized the channel,
It is not allowed to do settings */
@@ -981,8 +982,11 @@ static int vpif_reqbufs(struct file *file, void *priv,
q->mem_ops = &vb2_dma_contig_memops;
q->buf_struct_size = sizeof(struct vpif_disp_buffer);
- vb2_queue_init(q);
-
+ ret = vb2_queue_init(q);
+ if (ret) {
+ vpif_err("vpif_display: vb2_queue_init() failed\n");
+ return ret;
+ }
/* Set io allowed member of file handle to TRUE */
fh->io_allowed[index] = 1;
/* Increment io usrs member of channel object to 1 */
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On 10/03/2012 02:46 PM, Maarten Lankhorst wrote: Op 03-10-12 12:53, Thomas Hellstrom schreef: On 10/03/2012 10:53 AM, Daniel Vetter wrote: On Wed, Oct 3, 2012 at 10:37 AM, Thomas Hellstrom wrote: So if I understand you correctly, the reservation changes in TTM are motivated by the fact that otherwise, in the generic reservation code, lockdep can only be annotated for a trylock and not a waiting lock, when it *is* in fact a waiting lock. I'm completely unfamiliar with setting up lockdep annotations, but the only place a deadlock might occur is if the trylock fails and we do a wait_for_unreserve(). Isn't it possible to annotate the call to wait_for_unreserve() just like an interruptible waiting lock (that is always interrupted, but at least any deadlock will be catched?). Hm, I have to admit that idea hasn't crossed my mind, but it's indeed a hole in our current reservation lockdep annotations - since we're blocking for the unreserve, other threads could potential block waiting on us to release a lock we're holding already, resulting in a deadlock. Since no other locking primitive that I know of has this wait_for_unlocked interface, I don't know how we could map this in lockdep. One idea is to grab the lock and release it again immediately (only in the annotations, not the real lock ofc). But I need to check the lockdep code to see whether that doesn't trip it up. I imagine doing the same as mutex_lock_interruptible() does in the interrupted path should work... It simply calls the unlock lockdep annotation function if it breaks out. So doing a lock/unlock cycle in wait_unreserve should do what we want. And to properly annotate the ttm reserve paths we could just add an unconditional wait_unreserve call at the beginning like you suggested (maybe with #ifdef CONFIG_PROVE_LOCKING in case ppl freak out about the added atomic read in the uncontended case). -Daniel I think atomic_read()s are cheap, at least on intel as IIRC they don't require bus locking, still I think we should keep it within CONFIG_PROVE_LOCKING which btw reminds me there's an optimization that can be done in that one should really only call atomic_cmpxchg() if a preceding atomic_read() hints that it will succeed. Now, does this mean TTM can keep the atomic reserve <-> lru list removal? I don't think it would be a good idea to keep this across devices, Why? there's currently no callback to remove buffers off the lru list. So why don't we add one, and one to put them on the *correct* LRU list while unreserving. /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: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
Op 03-10-12 12:53, Thomas Hellstrom schreef: > On 10/03/2012 10:53 AM, Daniel Vetter wrote: >> On Wed, Oct 3, 2012 at 10:37 AM, Thomas Hellstrom >> wrote: > So if I understand you correctly, the reservation changes in TTM are > motivated by the > fact that otherwise, in the generic reservation code, lockdep can only be > annotated for a trylock and not a waiting lock, when it *is* in fact a > waiting lock. > > I'm completely unfamiliar with setting up lockdep annotations, but the > only > place a > deadlock might occur is if the trylock fails and we do a > wait_for_unreserve(). > Isn't it possible to annotate the call to wait_for_unreserve() just like > an > interruptible waiting lock > (that is always interrupted, but at least any deadlock will be catched?). Hm, I have to admit that idea hasn't crossed my mind, but it's indeed a hole in our current reservation lockdep annotations - since we're blocking for the unreserve, other threads could potential block waiting on us to release a lock we're holding already, resulting in a deadlock. Since no other locking primitive that I know of has this wait_for_unlocked interface, I don't know how we could map this in lockdep. One idea is to grab the lock and release it again immediately (only in the annotations, not the real lock ofc). But I need to check the lockdep code to see whether that doesn't trip it up. >>> >>> I imagine doing the same as mutex_lock_interruptible() does in the >>> interrupted path should work... >> It simply calls the unlock lockdep annotation function if it breaks >> out. So doing a lock/unlock cycle in wait_unreserve should do what we >> want. >> >> And to properly annotate the ttm reserve paths we could just add an >> unconditional wait_unreserve call at the beginning like you suggested >> (maybe with #ifdef CONFIG_PROVE_LOCKING in case ppl freak out about >> the added atomic read in the uncontended case). >> -Daniel > > I think atomic_read()s are cheap, at least on intel as IIRC they don't > require bus locking, > still I think we should keep it within CONFIG_PROVE_LOCKING > > which btw reminds me there's an optimization that can be done in that one > should really only > call atomic_cmpxchg() if a preceding atomic_read() hints that it will succeed. > > Now, does this mean TTM can keep the atomic reserve <-> lru list removal? I don't think it would be a good idea to keep this across devices, there's currently no callback to remove buffers off the lru list. However I am convinced that the current behavior where swapout and eviction/destruction never ever do a blocking reserve should be preserved. I looked more into it and it seems to allow to recursely quite a few times between all the related commands, and it wouldn't surprise me if that turned out to be cause of the lockups before moving to the current code. no_wait_reserve in those functions should be removed and always treated as true. Atomic lru_lock + reserve can still be done in the places where it matters though, but it might have to try the list for multiple bo's before it succeeds. As long as no blocking is done the effective behavior would stay the same. ~Maarten -- 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: [Linaro-mm-sig] [RFC] New dma_buf -> EGLImage EGL extension
On Tue, Oct 2, 2012 at 2:10 PM, Maarten Lankhorst wrote: > How do you want to deal with the case where Y' and CbCr are different > hardware buffers? > Could some support for 2d arrays be added in case Y' and CbCr are separated > into top/bottom fields? > How are semi-planar/planar formats handled that have a different width/height > for Y' and CbCr? (YUV420) The API works (AFAIU) like drm addfb2 ioctl, take I420 for example, you could either do: single buffer: fd0 = fd offset0 = 0 pitch0 = width fd1 = fd offset1 = width * height pitch1 = width / 2 fd2 = fd offset2 = offset1 + (width / height / 4) pitch2 = width / 2 multiple buffers: offset0 = offset1 = offset2 = 0 fd0 = fd_luma fd1 = fd_u fd2 = fd_v ... and so on for interlaced/stereo.. is sticking our heads in sand an option? :-P You could get lots of permutations for data layout of fields between interlaced and stereo. One option might be to ignore and let the user create two egl-images and deal with blending in the shader? BR, -R -- 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/5] reservation: cross-device reservation support
I took a quick look on the fencing and added some thoughts on
shared fences:
On 09/28/2012 02:43 PM, Maarten Lankhorst wrote:
This adds support for a generic reservations framework that can be
hooked up to ttm and dma-buf and allows easy sharing of reservations
across devices.
The idea is that a dma-buf and ttm object both will get a pointer
to a struct reservation_object, which has to be reserved before
anything is done with the buffer.
Some followup patches are needed in ttm so the lru_lock is no longer
taken during the reservation step. This makes the lockdep annotation
patch a lot more useful, and the assumption that the lru lock protects
atomic removal off the lru list will fail soon, anyway.
Signed-off-by: Maarten Lankhorst
+
+/**
+ * ticket_commit - commit a reservation with a new fence
+ * @ticket:[in]the reservation_ticket returned by
+ * ticket_reserve
+ * @entries: [in]a linked list of struct reservation_entry
+ * @fence: [in]the fence that indicates completion
+ *
+ * This function will call reservation_ticket_fini, no need
+ * to do it manually.
+ *
+ * This function should be called after a hardware command submission is
+ * completed succesfully. The fence is used to indicate completion of
+ * those commands.
+ */
+void
+ticket_commit(struct reservation_ticket *ticket,
+ struct list_head *entries, struct fence *fence)
+{
+ struct list_head *cur;
+
+ if (list_empty(entries))
+ return;
+
+ if (WARN_ON(!fence)) {
+ ticket_backoff(ticket, entries);
+ return;
+ }
+
+ list_for_each(cur, entries) {
+ struct reservation_object *bo;
+ bool shared;
+
+ reservation_entry_get(cur, &bo, &shared);
+
+ if (!shared) {
+ int i;
+ for (i = 0; i < bo->fence_shared_count; ++i) {
+ fence_put(bo->fence_shared[i]);
+ bo->fence_shared[i] = NULL;
+ }
+ bo->fence_shared_count = 0;
+ if (bo->fence_excl)
+ fence_put(bo->fence_excl);
+
+ bo->fence_excl = fence;
I assume here that the validation code has made sure that fences are
either ordered or expired so that "fence" signals *after* all other fences
have signaled.
+ } else {
+ if (WARN_ON(bo->fence_shared_count >=
+ ARRAY_SIZE(bo->fence_shared))) {
+ continue;
+ }
This is bad. Failure to fence a buffer is a catastrophic error that can lead
to pages being reused for other stuff while still being read by the GPU,
and the caller must be informed with an error code and sync on the fence.
I guess this has been discussed previously, but I think it might be more
appropriate with a list of pointers to fences. There is an allocation
overhead,
for this, but allocation from a mem cache should really be fast enough, and
the list entries can be allocated during ticket_reserve to avoid errors in
the commit code.
+
+ bo->fence_shared[bo->fence_shared_count++] = fence;
It might be good if this function had access to a light version of a
cross-device
struct fence * order_fences(struct fence *a, struct fence *b)
function that can quickly check two fences and determine whether
signaling one means that the other
one also is signaled. In that case one or more of the shared fences can
be unreferenced,
putting less pressure on the fence_shared array.
The lightweight version of order_fences is allowed to fail if there is
no simple
and quick way of ordering them. Could perhaps be added to the fence API.
And (even though not part of the reservation API)
There is a heavyweight version of that cross-device function
int order_fence(struct fence *a, int gpu_engine) needed for the
validation code
exclusive fencing that
*makes sure* fence a has signaled before the current gpu_engine executes
its commands.
For some gpu - fence pairs the ordering is done implicitly since they
share the same command
stream, for some it's possible to insert barriers in the gpu_engine
command stream
(radeon and nouveau is doing that), and if there is no other way of
doing it, the code will need to
wait for the fence.
+ }
+ fence_get(fence);
Hmm. Perhaps a fence_get(fence, NUM) to avoid a huge number of atomic incs?
+
+ object_unreserve(bo, ticket);
+ }
+ reservation_ticket_fini(ticket);
+}
+EXPORT_SYMBOL(ticket_commit);
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: qv4l2-bug / libv4lconvert API issue
On Wed 3 October 2012 12:22:48 Frank Schäfer wrote: > Hi Hans, > > Am 30.09.2012 11:54, schrieb Hans de Goede: > > Hi, > > > > On 09/28/2012 07:09 PM, Frank Schäfer wrote: > >> Hi, > >> > >> Am 27.09.2012 21:41, schrieb Hans de Goede: > >>> Hi, > >>> > >>> On 09/27/2012 03:20 PM, Frank Schäfer wrote: > >>> > >>> > >>> > > What you've found is a qv4l2 bug (do you have the latest version?) > > Of course, I'm using the latest developer version. > > Even if this is just a qv4l2-bug: how do you want to fix it without > removing the format selction feature ? > >>> > >>> Well, if qv4l2 can only handle rgb24 data, then it should gray out the > >>> format selection (fixing it at rgb24) when not in raw mode. > >> > >> So you say "just remove this feature from qv4l2". > >> I prefer fixing the library / API instead. > > > > No I'm suggesting to keep the feature to select which input format > > to use when in raw mode, while at the same time disabling the feature) > > when in libv4l2 mode. What use is it to ask libv4l2 for say YUV420 data > > and then later ask libv4lconvert to convert this to RGB24, when you could > > have asked libv4l2 for RGB24 right away. > > I assume the idea behind input format selction when using libv4l2 is to > provide a possibilty to test libv4l2 ? The main reason why I show all formats is that the driver reports all these formats, so one should be able to select them in order to test the driver. And I'm using libv4l2convert so that I can actually see a picture. For formats like MPEG that are unsupported by libv4l2convert I just dump the 'image' as is. It is counterintuitive if a YUV format is converted to a proper picture using qv4l2 -r, but that it is all wrong with qv4l2. I'm all for improving the library. 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
[GIT PULL] for 3.7 (technisat-usb2)
Hi Mauro, The following changes since commit 2425bb3d4016ed95ce83a90b53bd92c7f31091e4: em28xx: regression fix: use DRX-K sync firmware requests on em28xx are available in the git repository at: http://linuxtv.org/git/pb/media_tree.git staging/for_v3.7 for you to fetch changes up to e196a346d5d2e4695a587ca2f99da5e5491d4e95: [media]: add MODULE_DEVICE_TABLE to technisat-usb2 Patrick Boettcher (1): [media]: add MODULE_DEVICE_TABLE to technisat-usb2 drivers/media/usb/dvb-usb/technisat-usb2.c |1 + 1 file changed, 1 insertion(+) 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
Re: ITE9135 on AMD SB700 - ehci_hcd bug
On 10/03/2012 01:55 PM, Marx wrote: On 23.09.2012 18:22, Antti Palosaari wrote: On 09/16/2012 05:23 PM, Antti Palosaari wrote: On 09/12/2012 09:32 AM, Marx wrote: Hello I'm trying to use dual DVB-T tuner based on ITE9135 tuner. I use Debian kernel 3.5-trunk-686-pae. My motherboard is AsRock E350M1 (no USB3 ports). Tuner is detected ok, see log at the end of post. When I try to scan channels, bug happens: Sep 11 17:16:31 wuwek kernel: [ 209.291329] ehci_hcd :00:13.2: force halt; handshake f821a024 4000 -> -110 Sep 11 17:16:31 wuwek kernel: [ 209.291401] ehci_hcd :00:13.2: HC died; cleaning up Sep 11 17:16:31 wuwek kernel: [ 209.291606] usb 2-3: USB disconnect, device number 2 Sep 11 17:16:41 wuwek kernel: [ 219.312848] dvb-usb: error while stopping stream. Sep 11 17:16:41 wuwek kernel: [ 219.320585] dvb-usb: ITE 9135(9006) Generic successfully deinitialized and disconnected. After trying many ways I've read about problems with ehci on SB700 based boards and switched off ehci via command sh -c 'echo -n ":00:13.2" > unbind' and now ehci bug doesn't happen. Of course I can see only one tuner and in slower USB mode (see log at the end). But now I can scan succesfully without any errors. Of course it isn't acceptable fix for my problem. Drivers for ITE9135 seems ok, but there is a problem with ehci_hcd on my motherboard. I would like to know what can I do to fix my problem. I am quite sure dvb_usb_v2 fixes that. Test latest tree. Antti Test results please? I've replaced motherboard (no AMD chipset) and this problem disappeared. Unfortunatelly there were some problem with newsgate on gmane and I didn't receive your reply on time. Now I don't have this motherboard, but I can confirm ITE9135 drivers now works ok, so this problem was with USB driver. I have also AMD SB700 USB bridge and saw these errors. I suspect it race condition in DVB USB which happens in certain situation / combinations. I added one mutex to DVB USB v2 due to that... Now I have some small problem with ITE9135 driver. I use dual tuner. When I restart computer while the card is connected then disconnect and connect card again, I have four devices in /dev/dvb instead of two. Is it known bug and is fixed or I should attach some logs? Marx New for me. It could be ITE9135 driver bug or DVB USB bug. I have to test it. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qv4l2-bug / libv4lconvert API issue
Hi Hans, Am 30.09.2012 11:54, schrieb Hans de Goede: > Hi, > > On 09/28/2012 07:09 PM, Frank Schäfer wrote: >> Hi, >> >> Am 27.09.2012 21:41, schrieb Hans de Goede: >>> Hi, >>> >>> On 09/27/2012 03:20 PM, Frank Schäfer wrote: >>> >>> >>> > What you've found is a qv4l2 bug (do you have the latest version?) Of course, I'm using the latest developer version. Even if this is just a qv4l2-bug: how do you want to fix it without removing the format selction feature ? >>> >>> Well, if qv4l2 can only handle rgb24 data, then it should gray out the >>> format selection (fixing it at rgb24) when not in raw mode. >> >> So you say "just remove this feature from qv4l2". >> I prefer fixing the library / API instead. > > No I'm suggesting to keep the feature to select which input format > to use when in raw mode, while at the same time disabling the feature) > when in libv4l2 mode. What use is it to ask libv4l2 for say YUV420 data > and then later ask libv4lconvert to convert this to RGB24, when you could > have asked libv4l2 for RGB24 right away. I assume the idea behind input format selction when using libv4l2 is to provide a possibilty to test libv4l2 ? I'm not sure if we really need this. If not, sure, we can simply remove it to get rid of the problem. [we both agree that the current design/behavior is "suboptimal", needs to be documented and should be improved] > ... But saying that libv4l2 and libv4lconvert can't be used at the same (although they are separate public libraries) and that v4lconvert_convert() may only be called once per frame seems to me like a - I would say "weird" - reinterpretation of the API... I don't think this is what applications currently expect (qv4l2 doesn't ;) ) and at least this would need public clarification. >>> >>> Using the 2 at the same time never was the intention libv4lconvert >>> lies *beneath* libv4l2 in the stack. >> >> Yeah, sure. >> >>> Using them both at the same time >>> would be like using some high level file io API, while at the same >>> making lowlevel seek / read / write calls on the underlying fd and >>> then expecting things to behave consistently. 00.9% of all apps should >>> (and do) use the "highlevel" libv4l2 API. Some testing / developer >>> apps like qv4l2 use libv4lconvert directly. >> >> The problem here is, that we actually have TWO high level APIs which >> interact in a - let's call it "unfortunate" - way. > > I disagree that they are both highlevel. I know of only 2 tools which > use libv4lconvert directly, qv4l2 and svv, and both of them were > written by > kernel developers for driver testing. So in practice everyone who want a > "high" level API is using libv4l2 (which is already low-level enough by > it self). Hmmm... that's a weird argumentation. Because only a few applications are using it, it is not a high level API ? And assuming that we really know all users of a public API is very dangerous... > > > This interaction is not clear for the users (due to the transparent > > processing stuff) and it doesn't match not what users expect. > > But I think we can fix it and gain some nice extra features as a bonus. > > Then lets document the interaction. I think you don't realize which can > of worms you're opening when you try to make libv4lconvert more generally > usable. > > Please read the v4lconvert_convert function very carefully, esp. > the part where it hooks into v4lprocessing (software whitebalance, and > gamma correction). Make sure you understand what > v4lprocessing_pre_processing() does, what the difference is between > convert = 1 and convert = 2, and where *all* the callers are of > v4lprocessing_processing() (hint one is hiding in > v4lconvert_convert_pixfmt) Yeah, it's a bit tricky, but understandable. At the moment, the plan is not to change WHAT is done in this function, but WHERE it is done. > > Make sure you understand every single line of v4lconvert_convert! Once > you've done that I will welcome a proposal to make the libv4lconvert API > more general usable which: > > 1) Does not break any existing use-cases > 2) Does not slow down things in anyway (so which does not introduce any >extra intermediate buffers) > Sure. Will do that. Basically, the idea is to make libv4lconvert a pure toolbox with methods for - for V4L_PIX_FORMAT conversion - cropping - horizontal+vertical flipping - rotation - processing (applying filters => auto whitebalance, auto gain, gamma correction etc.) - ... of frames. Most of these methods are already there and only need to be made public (some with small extenstions/modifiactions). The whole "magic" (transparent flipping, rotation, ...) should be done inside libv4l. Does that make sense for you ? > > >>> 2) What is the use case for having separate convert_pixfmt etc. >>> functions available ... ? >> >> We already have them as separate functions, so the only question is: >> does it make sense to make them public ? >> I
Re: ITE9135 on AMD SB700 - ehci_hcd bug
On 23.09.2012 18:22, Antti Palosaari wrote: On 09/16/2012 05:23 PM, Antti Palosaari wrote: On 09/12/2012 09:32 AM, Marx wrote: Hello I'm trying to use dual DVB-T tuner based on ITE9135 tuner. I use Debian kernel 3.5-trunk-686-pae. My motherboard is AsRock E350M1 (no USB3 ports). Tuner is detected ok, see log at the end of post. When I try to scan channels, bug happens: Sep 11 17:16:31 wuwek kernel: [ 209.291329] ehci_hcd :00:13.2: force halt; handshake f821a024 4000 -> -110 Sep 11 17:16:31 wuwek kernel: [ 209.291401] ehci_hcd :00:13.2: HC died; cleaning up Sep 11 17:16:31 wuwek kernel: [ 209.291606] usb 2-3: USB disconnect, device number 2 Sep 11 17:16:41 wuwek kernel: [ 219.312848] dvb-usb: error while stopping stream. Sep 11 17:16:41 wuwek kernel: [ 219.320585] dvb-usb: ITE 9135(9006) Generic successfully deinitialized and disconnected. After trying many ways I've read about problems with ehci on SB700 based boards and switched off ehci via command sh -c 'echo -n ":00:13.2" > unbind' and now ehci bug doesn't happen. Of course I can see only one tuner and in slower USB mode (see log at the end). But now I can scan succesfully without any errors. Of course it isn't acceptable fix for my problem. Drivers for ITE9135 seems ok, but there is a problem with ehci_hcd on my motherboard. I would like to know what can I do to fix my problem. I am quite sure dvb_usb_v2 fixes that. Test latest tree. Antti Test results please? I've replaced motherboard (no AMD chipset) and this problem disappeared. Unfortunatelly there were some problem with newsgate on gmane and I didn't receive your reply on time. Now I don't have this motherboard, but I can confirm ITE9135 drivers now works ok, so this problem was with USB driver. Now I have some small problem with ITE9135 driver. I use dual tuner. When I restart computer while the card is connected then disconnect and connect card again, I have four devices in /dev/dvb instead of two. Is it known bug and is fixed or I should attach some logs? Marx -- 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 1/2] of: add helper to parse display specs
On Mon, Oct 01, 2012 at 10:53:08AM -0600, Stephen Warren wrote:
> On 09/24/2012 09:35 AM, Steffen Trumtrar wrote:
> > Parse a display-node with timings and hardware-specs from devictree.
>
> > diff --git a/Documentation/devicetree/bindings/video/display
> > b/Documentation/devicetree/bindings/video/display
> > new file mode 100644
> > index 000..722766a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/display
>
> This should be display.txt.
>
Okay
> > @@ -0,0 +1,208 @@
> > +display bindings
> > +==
> > +
> > +display-node
> > +
>
> I'm not personally convinced about the direction this is going. While I
> think it's reasonable to define DT bindings for displays, and DT
> bindings for display modes, I'm not sure that it's reasonable to couple
> them together into a single binding.
>
> I think creating a well-defined timing binding first will be much
> simpler than doing so within the context of a display binding; the
> scope/content of a general display binding seems much less well-defined
> to me at least, for reasons I mentioned before.
>
Yes, you are right. I'm in the middle of moving things around a little.
It seems best, to have bindings only for the timings at the moment and
get people to agree on those and use them, instead of all the adhoc solutions
based on of_videomode v2.
Then, the of_get_display_timings and the conversion via videomode to
fb_videomode
etc can be combined with Laurent Pincharts panel proposal.
> > +required properties:
> > + - none
> > +
> > +optional properties:
> > + - default-timing: the default timing value
> > + - width-mm, height-mm: Display dimensions in mm
>
> > + - hsync-active-high (bool): Hsync pulse is active high
> > + - vsync-active-high (bool): Vsync pulse is active high
>
> At least those two properties should exist in the display timing instead
> (or perhaps as well). There are certainly cases where different similar
> display modes are differentiated by hsync/vsync polarity more than
> anything else. This is probably more likely with analog display
> connectors than digital, but I see no reason why a DT binding for
> display timing shouldn't cover both.
>
Yes. Will do.
> > + - de-active-high (bool): Data-Enable pulse is active high
> > + - pixelclk-inverted (bool): pixelclock is inverted
>
> > + - pixel-per-clk
>
> pixel-per-clk is probably something that should either be part of the
> timing definition, or something computed internally to the display
> driver based on rules for the signal type, rather than something
> represented in DT.
>
> The above comment assumes this property is intended to represent DVI's
> requirement for pixel clock doubling for low-pixel-clock-rate modes. If
> it's something to do with e.g. a single-data-rate vs. double-data-rate
> property of the underlying physical connection, that's most likely
> something that should be defined in a binding specific to e.g. LVDS,
> rather than something generic.
>
> > + - link-width: number of channels (e.g. LVDS)
> > + - bpp: bits-per-pixel
> > +
> > +timings-subnode
> > +---
> > +
> > +required properties:
> > +subnodes that specify
> > + - hactive, vactive: Display resolution
> > + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing
> > parameters
> > + in pixels
> > + vfront-porch, vback-porch, vsync-len: Vertical display timing
> > parameters in
> > + lines
> > + - clock: displayclock in Hz
> > +
> > +There are different ways of describing a display and its capabilities. The
> > devicetree
> > +representation corresponds to the one commonly found in datasheets for
> > displays.
> > +The description of the display and its timing is split in two parts: first
> > the display
> > +properties like size in mm and (optionally) multiple subnodes with the
> > supported timings.
> > +If a display supports multiple signal timings, the default-timing can be
> > specified.
> > +
> > +Example:
> > +
> > + display@0 {
> > + width-mm = <800>;
> > + height-mm = <480>;
> > + default-timing = <&timing0>;
> > + timings {
> > + timing0: timing@0 {
>
> If you're going to use a unit address ("@0") to ensure that node names
> are unique (which is not mandatory), then each node also needs a reg
> property with matching value, and #address-cells/#size-cells in the
> parent. Instead, you could name the nodes something unique based on the
> mode name to avoid this, e.g. 1080p24 { ... }.
>
Ah, okay. Wasn't sure that was valid. I prefer to not use unit addresses.
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a
Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On 10/03/2012 10:53 AM, Daniel Vetter wrote: On Wed, Oct 3, 2012 at 10:37 AM, Thomas Hellstrom wrote: So if I understand you correctly, the reservation changes in TTM are motivated by the fact that otherwise, in the generic reservation code, lockdep can only be annotated for a trylock and not a waiting lock, when it *is* in fact a waiting lock. I'm completely unfamiliar with setting up lockdep annotations, but the only place a deadlock might occur is if the trylock fails and we do a wait_for_unreserve(). Isn't it possible to annotate the call to wait_for_unreserve() just like an interruptible waiting lock (that is always interrupted, but at least any deadlock will be catched?). Hm, I have to admit that idea hasn't crossed my mind, but it's indeed a hole in our current reservation lockdep annotations - since we're blocking for the unreserve, other threads could potential block waiting on us to release a lock we're holding already, resulting in a deadlock. Since no other locking primitive that I know of has this wait_for_unlocked interface, I don't know how we could map this in lockdep. One idea is to grab the lock and release it again immediately (only in the annotations, not the real lock ofc). But I need to check the lockdep code to see whether that doesn't trip it up. I imagine doing the same as mutex_lock_interruptible() does in the interrupted path should work... It simply calls the unlock lockdep annotation function if it breaks out. So doing a lock/unlock cycle in wait_unreserve should do what we want. And to properly annotate the ttm reserve paths we could just add an unconditional wait_unreserve call at the beginning like you suggested (maybe with #ifdef CONFIG_PROVE_LOCKING in case ppl freak out about the added atomic read in the uncontended case). -Daniel I think atomic_read()s are cheap, at least on intel as IIRC they don't require bus locking, still I think we should keep it within CONFIG_PROVE_LOCKING which btw reminds me there's an optimization that can be done in that one should really only call atomic_cmpxchg() if a preceding atomic_read() hints that it will succeed. Now, does this mean TTM can keep the atomic reserve <-> lru list removal? Thanks, 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: [PATCH] [media] s5p-jpeg: use clk_prepare_enable and clk_disable_unprepare
On 10/03/2012 01:55 AM, Thomas Abraham wrote: > Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare > calls as required by common clock framework. > > Signed-off-by: Thomas Abraham Applied, thanks. -- 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 2/3] s5p-fimc: fix compiler warning
On 10/02/2012 10:57 AM, Hans Verkuil wrote: > drivers/media/platform/s5p-fimc/fimc-m2m.c:561:2: warning: passing argument 2 > of 'fimc_m2m_try_crop' discards 'const' qualifier from pointer target type > [enabled by default] > drivers/media/platform/s5p-fimc/fimc-m2m.c:502:12: note: expected 'struct > v4l2_crop *' but argument is of type 'const struct v4l2_crop *' > > This is fall-out from this commit: > > commit 4f996594ceaf6c3f9bc42b40c40b0f7f87b79c86 > Author: Hans Verkuil > Date: Wed Sep 5 05:10:48 2012 -0300 > > [media] v4l2: make vidioc_s_crop const > > Signed-off-by: Hans Verkuil Applied, thanks. -- 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 1/3] s5p-g2d: fix compiler warning
On 10/02/2012 10:57 AM, Hans Verkuil wrote: > drivers/media/platform/s5p-g2d/g2d.c:535:2: warning: passing argument 3 of > 'vidioc_try_crop' discards 'const' qualifier from pointer target type > [enabled by default] > drivers/media/platform/s5p-g2d/g2d.c:510:12: note: expected 'struct v4l2_crop > *' but argument is of type 'const struct v4l2_crop *' > > This is fall-out from this commit: > > commit 4f996594ceaf6c3f9bc42b40c40b0f7f87b79c86 > Author: Hans Verkuil > Date: Wed Sep 5 05:10:48 2012 -0300 > > [media] v4l2: make vidioc_s_crop const > > Signed-off-by: Hans Verkuil Aplied, thanks. -- 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
[GIT PULL FOR v3.7] Davinci VPBE feature enhancement and fixes
Hi Mauro, Can you please pull the following patches for davinci VPBE driver. Some of the patches include platform changes for which Sekhar has Acked it. Thanks and Regards, --Prabhakar Lad The following changes since commit 2425bb3d4016ed95ce83a90b53bd92c7f31091e4: em28xx: regression fix: use DRX-K sync firmware requests on em28xx (2012-10-02 17:15:22 -0300) are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git vpbe_3.7_pull Hans Verkuil (1): dm644x: replace the obsolete preset API by the timings API. Lad, Prabhakar (2): media: davinci: vpbe: fix build warning davinci: vpbe: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS Manjunath Hadli (1): ths7303: enable THS7303 for HD modes arch/arm/mach-davinci/board-dm644x-evm.c | 15 ++-- arch/arm/mach-davinci/dm644x.c| 17 +--- drivers/media/i2c/ths7303.c | 106 drivers/media/platform/davinci/vpbe.c | 110 +++-- drivers/media/platform/davinci/vpbe_display.c | 80 +- drivers/media/platform/davinci/vpbe_venc.c| 25 +++--- include/media/davinci/vpbe.h | 14 ++-- include/media/davinci/vpbe_types.h|8 +-- include/media/davinci/vpbe_venc.h |2 +- 9 files changed, 211 insertions(+), 166 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
[GIT PULL FOR v3.7] small af9033 correction
The following changes since commit 2425bb3d4016ed95ce83a90b53bd92c7f31091e4: em28xx: regression fix: use DRX-K sync firmware requests on em28xx (2012-10-02 17:15:22 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git for_v3.7_mauro-4 for you to fetch changes up to cac7edcf11c48801b40cb8bc32c545da506e8435: af9033: prevent unintended underflow (2012-10-03 12:36:53 +0300) Hans-Frieder Vogt (1): af9033: prevent unintended underflow drivers/media/dvb-frontends/af9033.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 3.7] Samsung Exynos MFC driver update
Hi Arun, On 10/03/2012 07:38 AM, Arun Kumar K wrote: >> Indeed it looks like big blob patch. I think this reflects how these patches >> were created, were one person creates practically new driver for new device >> revision, with not much care about the old one, and then somebody else is >> trying to make it a step by step process and ensuring support for all H/W >> revisions is properly maintained. >> >> Anyway, Arun, can you please rebase your patch series onto latest linuxtv >> for_v3.7 branch and try to split this above patch. AFAICS there are following >> things done there that could be separated: >> >> 1. Move contents of file s5p_mfc_opr.c to new file s5p_mfc_opr_v5.c >> 2. Rename functions in s5p_mfc_opr_v5.c >> 3. Use s5p_mfc_hw_call for H/W specific function calls >> 4. Do S5P_FIMV/S5P_MFC whatever magic. > > I couldnt go with more finer splits, as I wanted to keep a working driver > between all successive patches. Now I will try to make the splits as > suggested and see if it can still be done. > >> Also I've noticed some patches do break compilation. There are some >> definitions >> used there which are added only in subsequent patches. Arun, can you please >> make >> sure there is no build break after each single patch is applied ? > > I have checked this while applying and I didnt see any break in > compilation after each patch is applied. I ensured not only compilation > but also a working driver after applying each patch. I will ensure > this again on the next rebase. Sorry, I wrongly concluded from looking at the diffs only. Preserving working driver is a good thing, but it is not really required AFAICT. Still it would be nice split the patch as above keeping the v5 driver working. Probably splitting it in 3 is enough. It is worthwhile as long as it makes the total diffs smaller (e.g. file renames don't need to be a huge diff with git rename detection enabled). I understand you've got now an additional work due to conflict with Andrzej's patches. All pending s5p-mfc patches seems to be in Mauro's tree for_v3.7 and nothing should get in before your patches now. > I will make these suggested changes and post an updated patchset today. Thanks. -- Regards, Sylwester -- 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] af9033: prevent unintended underflow
On 10/03/2012 12:25 PM, Hans-Frieder Vogt wrote:
As spotted by Dan Carpenter (thanks!), we have
improperly used an unsigned variable in a calculation that may result in a
negative number. This may cause an unintended underflow if the interface
frequency of the tuner is > approx. 40MHz.
This patch should resolve the issue, following an approach similar to what is
used in af9013.c.
Signed-off-by: Hans-Frieder Vogt
Acked-by: Antti Palosaari
I will PULL-request that via my tree for 3.7. I don't see any reason
this should go older ones.
regards
Antti
drivers/media/dvb-frontends/af9033.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
--- a/drivers/media/dvb-frontends/af9033.c 2012-09-28 05:45:17.0
+0200
+++ b/drivers/media/dvb-frontends/af9033.c 2012-10-03 11:08:18.160894181
+0200
@@ -408,7 +408,7 @@ static int af9033_set_frontend(struct dv
{
struct af9033_state *state = fe->demodulator_priv;
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
- int ret, i, spec_inv;
+ int ret, i, spec_inv, sampling_freq;
u8 tmp, buf[3], bandwidth_reg_val;
u32 if_frequency, freq_cw, adc_freq;
@@ -465,18 +465,20 @@ static int af9033_set_frontend(struct dv
else
if_frequency = 0;
- while (if_frequency > (adc_freq / 2))
- if_frequency -= adc_freq;
+ sampling_freq = if_frequency;
- if (if_frequency >= 0)
+ while (sampling_freq > (adc_freq / 2))
+ sampling_freq -= adc_freq;
+
+ if (sampling_freq >= 0)
spec_inv *= -1;
else
- if_frequency *= -1;
+ sampling_freq *= -1;
- freq_cw = af9033_div(state, if_frequency, adc_freq, 23ul);
+ freq_cw = af9033_div(state, sampling_freq, adc_freq, 23ul);
if (spec_inv == -1)
- freq_cw *= -1;
+ freq_cw = 0x80 - freq_cw;
/* get adc multiplies */
ret = af9033_rd_reg(state, 0x800045, &tmp);
Hans-Frieder Vogt e-mail: hfvogt gmx .dot. net
--
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
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] af9033: prevent unintended underflow
As spotted by Dan Carpenter (thanks!), we have
improperly used an unsigned variable in a calculation that may result in a
negative number. This may cause an unintended underflow if the interface
frequency of the tuner is > approx. 40MHz.
This patch should resolve the issue, following an approach similar to what is
used in af9013.c.
Signed-off-by: Hans-Frieder Vogt
drivers/media/dvb-frontends/af9033.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
--- a/drivers/media/dvb-frontends/af9033.c 2012-09-28 05:45:17.0
+0200
+++ b/drivers/media/dvb-frontends/af9033.c 2012-10-03 11:08:18.160894181
+0200
@@ -408,7 +408,7 @@ static int af9033_set_frontend(struct dv
{
struct af9033_state *state = fe->demodulator_priv;
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
- int ret, i, spec_inv;
+ int ret, i, spec_inv, sampling_freq;
u8 tmp, buf[3], bandwidth_reg_val;
u32 if_frequency, freq_cw, adc_freq;
@@ -465,18 +465,20 @@ static int af9033_set_frontend(struct dv
else
if_frequency = 0;
- while (if_frequency > (adc_freq / 2))
- if_frequency -= adc_freq;
+ sampling_freq = if_frequency;
- if (if_frequency >= 0)
+ while (sampling_freq > (adc_freq / 2))
+ sampling_freq -= adc_freq;
+
+ if (sampling_freq >= 0)
spec_inv *= -1;
else
- if_frequency *= -1;
+ sampling_freq *= -1;
- freq_cw = af9033_div(state, if_frequency, adc_freq, 23ul);
+ freq_cw = af9033_div(state, sampling_freq, adc_freq, 23ul);
if (spec_inv == -1)
- freq_cw *= -1;
+ freq_cw = 0x80 - freq_cw;
/* get adc multiplies */
ret = af9033_rd_reg(state, 0x800045, &tmp);
Hans-Frieder Vogt e-mail: hfvogt gmx .dot. net
--
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] davinci: vpbe: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS
On 10/3/2012 12:02 PM, Prabhakar wrote: > From: Lad, Prabhakar > > This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with > V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased > out. > > Signed-off-by: Lad, Prabhakar > Signed-off-by: Manjunath Hadli > Cc: Sekhar Nori > Cc: Hans Verkuil > Cc: Mauro Carvalho Chehab For the DaVinci platform change: Acked-by: Sekhar Nori Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 13/14] davinci: move struct vpif_interface to chan_cfg.
On 9/20/2012 5:36 PM, Hans Verkuil wrote: > From: Hans Verkuil > > struct vpif_interface is channel specific, not subdev specific. > Move it to the channel config. > > Signed-off-by: Hans Verkuil For the DaVinci platform changes: Acked-by: Sekhar Nori Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On Wed, Oct 3, 2012 at 10:37 AM, Thomas Hellstrom wrote: >>> So if I understand you correctly, the reservation changes in TTM are >>> motivated by the >>> fact that otherwise, in the generic reservation code, lockdep can only be >>> annotated for a trylock and not a waiting lock, when it *is* in fact a >>> waiting lock. >>> >>> I'm completely unfamiliar with setting up lockdep annotations, but the >>> only >>> place a >>> deadlock might occur is if the trylock fails and we do a >>> wait_for_unreserve(). >>> Isn't it possible to annotate the call to wait_for_unreserve() just like >>> an >>> interruptible waiting lock >>> (that is always interrupted, but at least any deadlock will be catched?). >> >> Hm, I have to admit that idea hasn't crossed my mind, but it's indeed >> a hole in our current reservation lockdep annotations - since we're >> blocking for the unreserve, other threads could potential block >> waiting on us to release a lock we're holding already, resulting in a >> deadlock. >> >> Since no other locking primitive that I know of has this >> wait_for_unlocked interface, I don't know how we could map this in >> lockdep. One idea is to grab the lock and release it again immediately >> (only in the annotations, not the real lock ofc). But I need to check >> the lockdep code to see whether that doesn't trip it up. > > > I imagine doing the same as mutex_lock_interruptible() does in the > interrupted path should work... It simply calls the unlock lockdep annotation function if it breaks out. So doing a lock/unlock cycle in wait_unreserve should do what we want. And to properly annotate the ttm reserve paths we could just add an unconditional wait_unreserve call at the beginning like you suggested (maybe with #ifdef CONFIG_PROVE_LOCKING in case ppl freak out about the added atomic read in the uncontended case). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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 06/14] vpif_capture: move routing info from subdev to input.
On 9/20/2012 5:36 PM, Hans Verkuil wrote: > From: Hans Verkuil > > Routing information is a property of the input, not of the subdev. > One subdev may provide multiple inputs, each with its own routing > information. > > Signed-off-by: Hans Verkuil For the DaVinci platform change: Acked-by: Sekhar Nori Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 05/14] vpif_capture: remove unnecessary can_route flag.
On 9/20/2012 5:36 PM, Hans Verkuil wrote: > From: Hans Verkuil > > Calling a subdev op that isn't implemented will just return -ENOIOCTLCMD > No need to have a flag for that. > > Signed-off-by: Hans Verkuil For the DaVinci platform change: Acked-by: Sekhar Nori Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] drxk: allow loading firmware synchrousnously
On 10/03/2012 10:13 AM, Oliver Endriss wrote:
Mauro Carvalho Chehab wrote:
Due to udev-182, the firmware load was changed to be async, as
otherwise udev would give up of loading a firmware.
Add an option to return to the previous behaviour, async firmware
loads cause failures with the tda18271 driver.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/drxk.h | 2 ++
drivers/media/dvb-frontends/drxk_hard.c | 20 +++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb-frontends/drxk.h
b/drivers/media/dvb-frontends/drxk.h
index d615d7d..94fecfb 100644
--- a/drivers/media/dvb-frontends/drxk.h
+++ b/drivers/media/dvb-frontends/drxk.h
@@ -28,6 +28,7 @@
*A value of 0 (default) or lower indicates that
*the correct number of parameters will be
*automatically detected.
+ * @load_firmware_sync:Force the firmware load to be
synchronous.
*
* On the *_gpio vars, bit 0 is UIO-1, bit 1 is UIO-2 and bit 2 is
* UIO-3.
@@ -39,6 +40,7 @@ struct drxk_config {
boolparallel_ts;
booldynamic_clk;
boolenable_merr_cfg;
+ boolload_firmware_sync;
boolantenna_dvbt;
u16 antenna_gpio;
diff --git a/drivers/media/dvb-frontends/drxk_hard.c
b/drivers/media/dvb-frontends/drxk_hard.c
index 1ab8154..8b4c6d5 100644
--- a/drivers/media/dvb-frontends/drxk_hard.c
+++ b/drivers/media/dvb-frontends/drxk_hard.c
@@ -6609,15 +6609,25 @@ struct dvb_frontend *drxk_attach(const struct
drxk_config *config,
/* Load firmware and initialize DRX-K */
if (state->microcode_name) {
- status = request_firmware_nowait(THIS_MODULE, 1,
+ if (config->load_firmware_sync) {
+ const struct firmware *fw = NULL;
+
+ status = request_firmware(&fw, state->microcode_name,
+ state->i2c->dev.parent);
+ if (status < 0)
+ fw = NULL;
+ load_firmware_cb(fw, state);
+ } else {
+ status = request_firmware_nowait(THIS_MODULE, 1,
state->microcode_name,
state->i2c->dev.parent,
GFP_KERNEL,
state, load_firmware_cb);
- if (status < 0) {
- printk(KERN_ERR
- "drxk: failed to request a firmware\n");
- return NULL;
+ if (status < 0) {
+ printk(KERN_ERR
+ "drxk: failed to request a firmware\n");
+ return NULL;
+ }
}
} else if (init_drxk(state) < 0)
goto error;
Sorry. loading the firmware asynchronously is simply crap! Remove this!
If you intend to load a firmware, firmware loading must be the first
thing you do with the drxk. You must not access the device, before
firmware loading has completed, or correct operation will not be
guaranteed.
If you insist to keep this option, I request that you make synchronous
loading the default, and you enable asynchronous loading only for
devices _you_ have tested. I will never use asynchronous loading.
(In fact, I have already backed-out your firmware patches from my
drivers and forked off my own version of the drxk.)
+1, indeed. Broken by design.
That was quite what I explained earlier too. You are not allowed to
continue attach path until previous attach is done and chip is ready to
offer interface(s) to the chips which are next in attach path. It is not
only that, but general rule.
I don't see any reason why this code should be left here.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On 10/03/2012 09:54 AM, Daniel Vetter wrote: On Wed, Oct 3, 2012 at 9:45 AM, Thomas Hellstrom wrote: On 10/02/2012 10:03 AM, Daniel Vetter wrote: On Tue, Oct 02, 2012 at 08:46:32AM +0200, Thomas Hellstrom wrote: On 10/01/2012 11:47 AM, Maarten Lankhorst wrote: I was doing a evil hack where I 'released' lru_lock to lockdep before doing the annotation for a blocking acquire, and left trylock annotations as they were. This made lockdep do the right thing. I've never looked into how lockdep works. Is this something that can be done permanently or just for testing purposes? Although not related to this, is it possible to do something similar to the trylock reversal in the fault() code where mmap_sem() and reserve() change order using a reserve trylock? lockdep just requires a bunch of annotations, is a compile-time configure option CONFIG_PROVE_LOCKING and if disabled, has zero overhead. And it's rather awesome in detected deadlocks and handling crazy locking schemes correctly: - correctly handles trylocks - correctly handles nested locking (i.e. grabbing a global lock, then grabbing subordinate locks in an unordered sequence since the global lock ensures that no deadlocks can happen). - any kinds of inversions with special contexts like hardirq, softirq - same for page-reclaim, i.e. it will yell if you could (potentially) deadlock because your shrinker grabs a lock that you hold while calling kmalloc. - there are special annotates for various subsystems, e.g. to check for del_timer_sync vs. locks held by that timer. Or the console_lock annotations I've just recently submitted. - all that with a really flexible set of annotation primitives that afaics should work for almost any insane locking scheme. The fact that Maarten could come up with proper reservation annotations without any changes to lockdep testifies this (he only had to fix a tiny thing to make it a bit more strict in a corner case). In short I think it's made of awesome. The only downside is that it lacks documentation, you have to read the code to understand it :( The reason I've suggested to Maarten to abolish the trylock_reservation within the lru_lock is that in that way lockdep only ever sees the trylock, and hence is less strict about complainig about deadlocks. But semantically it's an unconditional reserve. Maarten had some horrible hacks that leaked the lockdep annotations out of the new reservation code, which allowed ttm to be properly annotated. But those also reduced the usefulness for any other users of the reservation code, and so Maarten looked into whether he could remove that trylock dance in ttm. Imo having excellent lockdep support for cross-device reservations is a requirment, and ending up with less strict annotations for either ttm based drivers or other drivers is not good. And imo the ugly layering that Maarten had in his first proof-of-concept also indicates that something is amiss in the design. So if I understand you correctly, the reservation changes in TTM are motivated by the fact that otherwise, in the generic reservation code, lockdep can only be annotated for a trylock and not a waiting lock, when it *is* in fact a waiting lock. I'm completely unfamiliar with setting up lockdep annotations, but the only place a deadlock might occur is if the trylock fails and we do a wait_for_unreserve(). Isn't it possible to annotate the call to wait_for_unreserve() just like an interruptible waiting lock (that is always interrupted, but at least any deadlock will be catched?). Hm, I have to admit that idea hasn't crossed my mind, but it's indeed a hole in our current reservation lockdep annotations - since we're blocking for the unreserve, other threads could potential block waiting on us to release a lock we're holding already, resulting in a deadlock. Since no other locking primitive that I know of has this wait_for_unlocked interface, I don't know how we could map this in lockdep. One idea is to grab the lock and release it again immediately (only in the annotations, not the real lock ofc). But I need to check the lockdep code to see whether that doesn't trip it up. I imagine doing the same as mutex_lock_interruptible() does in the interrupted path should work... Cheers, Daniel -- 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 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On 10/03/2012 09:57 AM, Maarten Lankhorst wrote: Hey, Op 03-10-12 09:45, Thomas Hellstrom schreef: On 10/02/2012 10:03 AM, Daniel Vetter wrote: On Tue, Oct 02, 2012 at 08:46:32AM +0200, Thomas Hellstrom wrote: On 10/01/2012 11:47 AM, Maarten Lankhorst wrote: I was doing a evil hack where I 'released' lru_lock to lockdep before doing the annotation for a blocking acquire, and left trylock annotations as they were. This made lockdep do the right thing. I've never looked into how lockdep works. Is this something that can be done permanently or just for testing purposes? Although not related to this, is it possible to do something similar to the trylock reversal in the fault() code where mmap_sem() and reserve() change order using a reserve trylock? lockdep just requires a bunch of annotations, is a compile-time configure option CONFIG_PROVE_LOCKING and if disabled, has zero overhead. And it's rather awesome in detected deadlocks and handling crazy locking schemes correctly: - correctly handles trylocks - correctly handles nested locking (i.e. grabbing a global lock, then grabbing subordinate locks in an unordered sequence since the global lock ensures that no deadlocks can happen). - any kinds of inversions with special contexts like hardirq, softirq - same for page-reclaim, i.e. it will yell if you could (potentially) deadlock because your shrinker grabs a lock that you hold while calling kmalloc. - there are special annotates for various subsystems, e.g. to check for del_timer_sync vs. locks held by that timer. Or the console_lock annotations I've just recently submitted. - all that with a really flexible set of annotation primitives that afaics should work for almost any insane locking scheme. The fact that Maarten could come up with proper reservation annotations without any changes to lockdep testifies this (he only had to fix a tiny thing to make it a bit more strict in a corner case). In short I think it's made of awesome. The only downside is that it lacks documentation, you have to read the code to understand it :( The reason I've suggested to Maarten to abolish the trylock_reservation within the lru_lock is that in that way lockdep only ever sees the trylock, and hence is less strict about complainig about deadlocks. But semantically it's an unconditional reserve. Maarten had some horrible hacks that leaked the lockdep annotations out of the new reservation code, which allowed ttm to be properly annotated. But those also reduced the usefulness for any other users of the reservation code, and so Maarten looked into whether he could remove that trylock dance in ttm. Imo having excellent lockdep support for cross-device reservations is a requirment, and ending up with less strict annotations for either ttm based drivers or other drivers is not good. And imo the ugly layering that Maarten had in his first proof-of-concept also indicates that something is amiss in the design. So if I understand you correctly, the reservation changes in TTM are motivated by the fact that otherwise, in the generic reservation code, lockdep can only be annotated for a trylock and not a waiting lock, when it *is* in fact a waiting lock. I'm completely unfamiliar with setting up lockdep annotations, but the only place a deadlock might occur is if the trylock fails and we do a wait_for_unreserve(). Isn't it possible to annotate the call to wait_for_unreserve() just like an interruptible waiting lock (that is always interrupted, but at least any deadlock will be catched?). That would not find all bugs, lockdep is meant to find even theoretical bugs, so annotating it as a waiting lock makes more sense. Otherwise lockdep will only barf when the initial trylock fails. Really, starting a waiting reserve with a call to wait_for_unreserve() if CONFIG_LOCKDEP is set shouldn't be that bad :)? That would catch also the the theoretical errors. In fact, it should suffice with annotating for such a call? /Thomas ~Maarten -- 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
[GIT PULL FOR v3.7] Davinci VPFE bug fix
Hi Mauro, Can you please pull the following patch for VPFE, Which fixes build error for VPFE driver. Thanks and Regards, --Prabhakar Lad The following changes since commit 2425bb3d4016ed95ce83a90b53bd92c7f31091e4: em28xx: regression fix: use DRX-K sync firmware requests on em28xx (2012-10-02 17:15:22 -0300) are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git vpfe_3.7_pull Lad, Prabhakar (1): media: davinci: vpfe: fix build error drivers/media/platform/davinci/vpfe_capture.c | 17 + 1 files changed, 9 insertions(+), 8 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
[PATCH RFC v3] dvb: LNA implementation changes
* use dvb property cache
* implement get (thus API minor++)
* PCTV 290e: 1=LNA ON, all the other values LNA OFF
Also fix PCTV 290e LNA comment, it is disabled by default
Hans and Mauro proposed use of cache implementation of get as they
were planning to extend LNA usage for analog side too.
Reported-by: Hans Verkuil
Reported-by: Mauro Carvalho Chehab
Signed-off-by: Antti Palosaari
Acked-by: Hans Verkuil
---
drivers/media/dvb-core/dvb_frontend.c | 18 ++
drivers/media/dvb-core/dvb_frontend.h | 4 +++-
drivers/media/usb/em28xx/em28xx-dvb.c | 13 +++--
include/linux/dvb/version.h | 2 +-
4 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index 8f58f24..246a3c5 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -966,6 +966,8 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
break;
}
+ c->lna = LNA_AUTO;
+
return 0;
}
@@ -1054,6 +1056,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_B, 0, 0),
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_C, 0, 0),
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_D, 0, 0),
+
+ _DTV_CMD(DTV_LNA, 0, 0),
};
static void dtv_property_dump(struct dvb_frontend *fe, struct dtv_property
*tvp)
@@ -1440,6 +1444,10 @@ static int dtv_property_process_get(struct dvb_frontend
*fe,
tvp->u.data = fe->dtv_property_cache.atscmh_sccc_code_mode_d;
break;
+ case DTV_LNA:
+ tvp->u.data = c->lna;
+ break;
+
default:
return -EINVAL;
}
@@ -1731,10 +1739,6 @@ static int dtv_property_process_set(struct dvb_frontend
*fe,
case DTV_INTERLEAVING:
c->interleaving = tvp->u.data;
break;
- case DTV_LNA:
- if (fe->ops.set_lna)
- r = fe->ops.set_lna(fe, tvp->u.data);
- break;
/* ISDB-T Support here */
case DTV_ISDBT_PARTIAL_RECEPTION:
@@ -1806,6 +1810,12 @@ static int dtv_property_process_set(struct dvb_frontend
*fe,
fe->dtv_property_cache.atscmh_rs_frame_ensemble = tvp->u.data;
break;
+ case DTV_LNA:
+ c->lna = tvp->u.data;
+ if (fe->ops.set_lna)
+ r = fe->ops.set_lna(fe);
+ break;
+
default:
return -EINVAL;
}
diff --git a/drivers/media/dvb-core/dvb_frontend.h
b/drivers/media/dvb-core/dvb_frontend.h
index 44a445c..97112cd 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -303,7 +303,7 @@ struct dvb_frontend_ops {
int (*dishnetwork_send_legacy_command)(struct dvb_frontend* fe,
unsigned long cmd);
int (*i2c_gate_ctrl)(struct dvb_frontend* fe, int enable);
int (*ts_bus_ctrl)(struct dvb_frontend* fe, int acquire);
- int (*set_lna)(struct dvb_frontend *, int);
+ int (*set_lna)(struct dvb_frontend *);
/* These callbacks are for devices that implement their own
* tuning algorithms, rather than a simple swzigzag
@@ -391,6 +391,8 @@ struct dtv_frontend_properties {
u8 atscmh_sccc_code_mode_b;
u8 atscmh_sccc_code_mode_c;
u8 atscmh_sccc_code_mode_d;
+
+ u32 lna;
};
struct dvb_frontend {
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 913e522..13ae821 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -574,18 +574,19 @@ static void pctv_520e_init(struct em28xx *dev)
i2c_master_send(&dev->i2c_client, regs[i].r, regs[i].len);
};
-static int em28xx_pctv_290e_set_lna(struct dvb_frontend *fe, int val)
+static int em28xx_pctv_290e_set_lna(struct dvb_frontend *fe)
{
+ struct dtv_frontend_properties *c = &fe->dtv_property_cache;
struct em28xx *dev = fe->dvb->priv;
#ifdef CONFIG_GPIOLIB
struct em28xx_dvb *dvb = dev->dvb;
int ret;
unsigned long flags;
- if (val)
- flags = GPIOF_OUT_INIT_LOW;
+ if (c->lna == 1)
+ flags = GPIOF_OUT_INIT_HIGH; /* enable LNA */
else
- flags = GPIOF_OUT_INIT_HIGH;
+ flags = GPIOF_OUT_INIT_LOW; /* disable LNA */
ret = gpio_request_one(dvb->lna_gpio, flags, NULL);
if (ret)
@@ -595,8 +596,8 @@ static int em28xx_pctv_290e_set_lna(struct dvb_frontend
*fe, int val)
return ret;
#else
- dev_warn(&dev->udev->dev, "%s: LNA control is disabled\n",
- KBUILD_MODNAME);
+ dev_warn(&dev->udev->dev, "%s: LNA control is disabled (lna=%u)\n",
+ KBUILD_M
Re: [PATCH RFC v2] dvb: LNA implementation changes
On 10/03/2012 09:21 AM, Hans Verkuil wrote:
On Wed October 3 2012 01:49:47 Antti Palosaari wrote:
* use dvb property cache
* implement get (thus API minor++)
* PCTV 290e: 1=LNA ON, all the other values LNA OFF
Also fix PCTV 290e LNA comment, it is disabled by default
Hans and Mauro proposed use of cache implementation of get as they
were planning to extend LNA usage for analog side too.
LNA_AUTO value was changed from (~0U) to INT_MIN as (~0U) resulted
only -1 which is waste of numeric range if need to extend that in
the future.
Is the sentence above still valid? It doesn't seem to be as LNA_AUTO wasn't
changed.
No it is not. I will resend :s
Antti
The code itself looks good to me:
Acked-by: Hans Verkuil
Regards,
Hans
Reported-by: Hans Verkuil
Reported-by: Mauro Carvalho Chehab
Signed-off-by: Antti Palosaari
---
drivers/media/dvb-core/dvb_frontend.c | 18 ++
drivers/media/dvb-core/dvb_frontend.h | 4 +++-
drivers/media/usb/em28xx/em28xx-dvb.c | 13 +++--
include/linux/dvb/version.h | 2 +-
4 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index 8f58f24..246a3c5 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -966,6 +966,8 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
break;
}
+ c->lna = LNA_AUTO;
+
return 0;
}
@@ -1054,6 +1056,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_B, 0, 0),
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_C, 0, 0),
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_D, 0, 0),
+
+ _DTV_CMD(DTV_LNA, 0, 0),
};
static void dtv_property_dump(struct dvb_frontend *fe, struct dtv_property
*tvp)
@@ -1440,6 +1444,10 @@ static int dtv_property_process_get(struct dvb_frontend
*fe,
tvp->u.data = fe->dtv_property_cache.atscmh_sccc_code_mode_d;
break;
+ case DTV_LNA:
+ tvp->u.data = c->lna;
+ break;
+
default:
return -EINVAL;
}
@@ -1731,10 +1739,6 @@ static int dtv_property_process_set(struct dvb_frontend
*fe,
case DTV_INTERLEAVING:
c->interleaving = tvp->u.data;
break;
- case DTV_LNA:
- if (fe->ops.set_lna)
- r = fe->ops.set_lna(fe, tvp->u.data);
- break;
/* ISDB-T Support here */
case DTV_ISDBT_PARTIAL_RECEPTION:
@@ -1806,6 +1810,12 @@ static int dtv_property_process_set(struct dvb_frontend
*fe,
fe->dtv_property_cache.atscmh_rs_frame_ensemble = tvp->u.data;
break;
+ case DTV_LNA:
+ c->lna = tvp->u.data;
+ if (fe->ops.set_lna)
+ r = fe->ops.set_lna(fe);
+ break;
+
default:
return -EINVAL;
}
diff --git a/drivers/media/dvb-core/dvb_frontend.h
b/drivers/media/dvb-core/dvb_frontend.h
index 44a445c..97112cd 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -303,7 +303,7 @@ struct dvb_frontend_ops {
int (*dishnetwork_send_legacy_command)(struct dvb_frontend* fe,
unsigned long cmd);
int (*i2c_gate_ctrl)(struct dvb_frontend* fe, int enable);
int (*ts_bus_ctrl)(struct dvb_frontend* fe, int acquire);
- int (*set_lna)(struct dvb_frontend *, int);
+ int (*set_lna)(struct dvb_frontend *);
/* These callbacks are for devices that implement their own
* tuning algorithms, rather than a simple swzigzag
@@ -391,6 +391,8 @@ struct dtv_frontend_properties {
u8 atscmh_sccc_code_mode_b;
u8 atscmh_sccc_code_mode_c;
u8 atscmh_sccc_code_mode_d;
+
+ u32 lna;
};
struct dvb_frontend {
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 913e522..13ae821 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -574,18 +574,19 @@ static void pctv_520e_init(struct em28xx *dev)
i2c_master_send(&dev->i2c_client, regs[i].r, regs[i].len);
};
-static int em28xx_pctv_290e_set_lna(struct dvb_frontend *fe, int val)
+static int em28xx_pctv_290e_set_lna(struct dvb_frontend *fe)
{
+ struct dtv_frontend_properties *c = &fe->dtv_property_cache;
struct em28xx *dev = fe->dvb->priv;
#ifdef CONFIG_GPIOLIB
struct em28xx_dvb *dvb = dev->dvb;
int ret;
unsigned long flags;
- if (val)
- flags = GPIOF_OUT_INIT_LOW;
+ if (c->lna == 1)
+ flags = GPIOF_OUT_INIT_HIGH; /* enable LNA */
else
- flags = GPIOF_OUT_INIT_HIGH;
+ flags = GPIOF_OUT_I
RE: Previewing PAL fields on framebuffer
Please, don't drop the mailing list from the CC list. On Wed, 3 Oct 2012, Alex Pollard wrote: > Thanks! > > I have found that in their demo application the capture board developer > (e-consystems) supports various interlacing options thru ioctl calls. So > I think I will find a solution. Isn't specifying one of V4L2_FIELD_INTERLACED* values in standard V4L2 ioctl()s enough? Or is this what you mean? > The main issue now is the ability to do > overlays on the low-latency framebuffer preview, I am guessing > ipu_prp_vf_sdc_bg.c provides a way to accomplish this. Sorry, I don't know what file you mean. In any case you'd have to implement overlay support in the mx3fb.c framebuffer driver. Thanks Guennadi > Cheers, > Alex > > -Original Message- > From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] > Sent: Wednesday, 3 October 2012 5:06 PM > To: Alex Pollard > Cc: Linux Media Mailing List > Subject: Re: Previewing PAL fields on framebuffer > > Hi Alex > > (added linux-media to CC on your request) > > On Wed, 3 Oct 2012, Alex Pollard wrote: > > > Hi, > > > > I am wondering if it is possible to use the DMA features in > > drivers/dma/ipu/ipu_idmac.c to write the top field of a PAL frame into a > > framebuffer on alternating lines, and write the bottom field of the PAL > > frame to the other lines ie deinterlace. > > Looking at the i.MX31 CSI documentation it seems it could be possible to > use CSI_SENS_FRM_SIZE and CSI_ACT_FRM_SIZE to specify stride != width to > basically do stride = 2 * width and then do 2 transfers per frame - one > beginning with line 0 and one beginning with line 1? But that's just an > idea, the description of those registers is vague and I'm also not sure > how to implement that. > > Good luck > Guennadi > > > Do you know a good discussion > > list where I could post the question? I am using an i.MX53 but the > > support "community" is a bit quiet. > > > > Thanks > > > > Alex Pollard > > Software Engineer > > > > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
Hey, Op 03-10-12 09:45, Thomas Hellstrom schreef: > On 10/02/2012 10:03 AM, Daniel Vetter wrote: >> On Tue, Oct 02, 2012 at 08:46:32AM +0200, Thomas Hellstrom wrote: >>> On 10/01/2012 11:47 AM, Maarten Lankhorst wrote: I was doing a evil hack where I 'released' lru_lock to lockdep before doing the annotation for a blocking acquire, and left trylock annotations as they were. This made lockdep do the right thing. >>> I've never looked into how lockdep works. Is this something that can >>> be done permanently or just for testing >>> purposes? Although not related to this, is it possible to do >>> something similar to the trylock reversal in the >>> fault() code where mmap_sem() and reserve() change order using a >>> reserve trylock? >> lockdep just requires a bunch of annotations, is a compile-time configure >> option CONFIG_PROVE_LOCKING and if disabled, has zero overhead. And it's >> rather awesome in detected deadlocks and handling crazy locking schemes >> correctly: >> - correctly handles trylocks >> - correctly handles nested locking (i.e. grabbing a global lock, then >>grabbing subordinate locks in an unordered sequence since the global >>lock ensures that no deadlocks can happen). >> - any kinds of inversions with special contexts like hardirq, softirq >> - same for page-reclaim, i.e. it will yell if you could (potentially) >>deadlock because your shrinker grabs a lock that you hold while calling >>kmalloc. >> - there are special annotates for various subsystems, e.g. to check for >>del_timer_sync vs. locks held by that timer. Or the console_lock >>annotations I've just recently submitted. >> - all that with a really flexible set of annotation primitives that afaics >>should work for almost any insane locking scheme. The fact that Maarten >>could come up with proper reservation annotations without any changes to >>lockdep testifies this (he only had to fix a tiny thing to make it a bit >>more strict in a corner case). >> >> In short I think it's made of awesome. The only downside is that it lacks >> documentation, you have to read the code to understand it :( >> >> The reason I've suggested to Maarten to abolish the trylock_reservation >> within the lru_lock is that in that way lockdep only ever sees the >> trylock, and hence is less strict about complainig about deadlocks. But >> semantically it's an unconditional reserve. Maarten had some horrible >> hacks that leaked the lockdep annotations out of the new reservation code, >> which allowed ttm to be properly annotated. But those also reduced the >> usefulness for any other users of the reservation code, and so Maarten >> looked into whether he could remove that trylock dance in ttm. >> >> Imo having excellent lockdep support for cross-device reservations is a >> requirment, and ending up with less strict annotations for either ttm >> based drivers or other drivers is not good. And imo the ugly layering that >> Maarten had in his first proof-of-concept also indicates that something is >> amiss in the design. >> >> > So if I understand you correctly, the reservation changes in TTM are > motivated by the > fact that otherwise, in the generic reservation code, lockdep can only be > annotated for a trylock and not a waiting lock, when it *is* in fact a > waiting lock. > > I'm completely unfamiliar with setting up lockdep annotations, but the only > place a > deadlock might occur is if the trylock fails and we do a wait_for_unreserve(). > Isn't it possible to annotate the call to wait_for_unreserve() just like an > interruptible waiting lock > (that is always interrupted, but at least any deadlock will be catched?). That would not find all bugs, lockdep is meant to find even theoretical bugs, so annotating it as a waiting lock makes more sense. Otherwise lockdep will only barf when the initial trylock fails. ~Maarten -- 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 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On Wed, Oct 3, 2012 at 9:45 AM, Thomas Hellstrom wrote: > On 10/02/2012 10:03 AM, Daniel Vetter wrote: >> >> On Tue, Oct 02, 2012 at 08:46:32AM +0200, Thomas Hellstrom wrote: >>> >>> On 10/01/2012 11:47 AM, Maarten Lankhorst wrote: I was doing a evil hack where I 'released' lru_lock to lockdep before doing the annotation for a blocking acquire, and left trylock annotations as they were. This made lockdep do the right thing. >>> >>> I've never looked into how lockdep works. Is this something that can >>> be done permanently or just for testing >>> purposes? Although not related to this, is it possible to do >>> something similar to the trylock reversal in the >>> fault() code where mmap_sem() and reserve() change order using a >>> reserve trylock? >> >> lockdep just requires a bunch of annotations, is a compile-time configure >> option CONFIG_PROVE_LOCKING and if disabled, has zero overhead. And it's >> rather awesome in detected deadlocks and handling crazy locking schemes >> correctly: >> - correctly handles trylocks >> - correctly handles nested locking (i.e. grabbing a global lock, then >>grabbing subordinate locks in an unordered sequence since the global >>lock ensures that no deadlocks can happen). >> - any kinds of inversions with special contexts like hardirq, softirq >> - same for page-reclaim, i.e. it will yell if you could (potentially) >>deadlock because your shrinker grabs a lock that you hold while calling >>kmalloc. >> - there are special annotates for various subsystems, e.g. to check for >>del_timer_sync vs. locks held by that timer. Or the console_lock >>annotations I've just recently submitted. >> - all that with a really flexible set of annotation primitives that afaics >>should work for almost any insane locking scheme. The fact that Maarten >>could come up with proper reservation annotations without any changes >> to >>lockdep testifies this (he only had to fix a tiny thing to make it a >> bit >>more strict in a corner case). >> >> In short I think it's made of awesome. The only downside is that it lacks >> documentation, you have to read the code to understand it :( >> >> The reason I've suggested to Maarten to abolish the trylock_reservation >> within the lru_lock is that in that way lockdep only ever sees the >> trylock, and hence is less strict about complainig about deadlocks. But >> semantically it's an unconditional reserve. Maarten had some horrible >> hacks that leaked the lockdep annotations out of the new reservation code, >> which allowed ttm to be properly annotated. But those also reduced the >> usefulness for any other users of the reservation code, and so Maarten >> looked into whether he could remove that trylock dance in ttm. >> >> Imo having excellent lockdep support for cross-device reservations is a >> requirment, and ending up with less strict annotations for either ttm >> based drivers or other drivers is not good. And imo the ugly layering that >> Maarten had in his first proof-of-concept also indicates that something is >> amiss in the design. >> >> > So if I understand you correctly, the reservation changes in TTM are > motivated by the > fact that otherwise, in the generic reservation code, lockdep can only be > annotated for a trylock and not a waiting lock, when it *is* in fact a > waiting lock. > > I'm completely unfamiliar with setting up lockdep annotations, but the only > place a > deadlock might occur is if the trylock fails and we do a > wait_for_unreserve(). > Isn't it possible to annotate the call to wait_for_unreserve() just like an > interruptible waiting lock > (that is always interrupted, but at least any deadlock will be catched?). Hm, I have to admit that idea hasn't crossed my mind, but it's indeed a hole in our current reservation lockdep annotations - since we're blocking for the unreserve, other threads could potential block waiting on us to release a lock we're holding already, resulting in a deadlock. Since no other locking primitive that I know of has this wait_for_unlocked interface, I don't know how we could map this in lockdep. One idea is to grab the lock and release it again immediately (only in the annotations, not the real lock ofc). But I need to check the lockdep code to see whether that doesn't trip it up. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On 10/02/2012 10:03 AM, Daniel Vetter wrote: On Tue, Oct 02, 2012 at 08:46:32AM +0200, Thomas Hellstrom wrote: On 10/01/2012 11:47 AM, Maarten Lankhorst wrote: I was doing a evil hack where I 'released' lru_lock to lockdep before doing the annotation for a blocking acquire, and left trylock annotations as they were. This made lockdep do the right thing. I've never looked into how lockdep works. Is this something that can be done permanently or just for testing purposes? Although not related to this, is it possible to do something similar to the trylock reversal in the fault() code where mmap_sem() and reserve() change order using a reserve trylock? lockdep just requires a bunch of annotations, is a compile-time configure option CONFIG_PROVE_LOCKING and if disabled, has zero overhead. And it's rather awesome in detected deadlocks and handling crazy locking schemes correctly: - correctly handles trylocks - correctly handles nested locking (i.e. grabbing a global lock, then grabbing subordinate locks in an unordered sequence since the global lock ensures that no deadlocks can happen). - any kinds of inversions with special contexts like hardirq, softirq - same for page-reclaim, i.e. it will yell if you could (potentially) deadlock because your shrinker grabs a lock that you hold while calling kmalloc. - there are special annotates for various subsystems, e.g. to check for del_timer_sync vs. locks held by that timer. Or the console_lock annotations I've just recently submitted. - all that with a really flexible set of annotation primitives that afaics should work for almost any insane locking scheme. The fact that Maarten could come up with proper reservation annotations without any changes to lockdep testifies this (he only had to fix a tiny thing to make it a bit more strict in a corner case). In short I think it's made of awesome. The only downside is that it lacks documentation, you have to read the code to understand it :( The reason I've suggested to Maarten to abolish the trylock_reservation within the lru_lock is that in that way lockdep only ever sees the trylock, and hence is less strict about complainig about deadlocks. But semantically it's an unconditional reserve. Maarten had some horrible hacks that leaked the lockdep annotations out of the new reservation code, which allowed ttm to be properly annotated. But those also reduced the usefulness for any other users of the reservation code, and so Maarten looked into whether he could remove that trylock dance in ttm. Imo having excellent lockdep support for cross-device reservations is a requirment, and ending up with less strict annotations for either ttm based drivers or other drivers is not good. And imo the ugly layering that Maarten had in his first proof-of-concept also indicates that something is amiss in the design. So if I understand you correctly, the reservation changes in TTM are motivated by the fact that otherwise, in the generic reservation code, lockdep can only be annotated for a trylock and not a waiting lock, when it *is* in fact a waiting lock. I'm completely unfamiliar with setting up lockdep annotations, but the only place a deadlock might occur is if the trylock fails and we do a wait_for_unreserve(). Isn't it possible to annotate the call to wait_for_unreserve() just like an interruptible waiting lock (that is always interrupted, but at least any deadlock will be catched?). /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: [PATCH 1/2] drxk: allow loading firmware synchrousnously
Mauro Carvalho Chehab wrote:
> Due to udev-182, the firmware load was changed to be async, as
> otherwise udev would give up of loading a firmware.
>
> Add an option to return to the previous behaviour, async firmware
> loads cause failures with the tda18271 driver.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/dvb-frontends/drxk.h | 2 ++
> drivers/media/dvb-frontends/drxk_hard.c | 20 +++-
> 2 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/drxk.h
> b/drivers/media/dvb-frontends/drxk.h
> index d615d7d..94fecfb 100644
> --- a/drivers/media/dvb-frontends/drxk.h
> +++ b/drivers/media/dvb-frontends/drxk.h
> @@ -28,6 +28,7 @@
> * A value of 0 (default) or lower indicates that
> * the correct number of parameters will be
> * automatically detected.
> + * @load_firmware_sync: Force the firmware load to be
> synchronous.
> *
> * On the *_gpio vars, bit 0 is UIO-1, bit 1 is UIO-2 and bit 2 is
> * UIO-3.
> @@ -39,6 +40,7 @@ struct drxk_config {
> boolparallel_ts;
> booldynamic_clk;
> boolenable_merr_cfg;
> + boolload_firmware_sync;
>
> boolantenna_dvbt;
> u16 antenna_gpio;
> diff --git a/drivers/media/dvb-frontends/drxk_hard.c
> b/drivers/media/dvb-frontends/drxk_hard.c
> index 1ab8154..8b4c6d5 100644
> --- a/drivers/media/dvb-frontends/drxk_hard.c
> +++ b/drivers/media/dvb-frontends/drxk_hard.c
> @@ -6609,15 +6609,25 @@ struct dvb_frontend *drxk_attach(const struct
> drxk_config *config,
>
> /* Load firmware and initialize DRX-K */
> if (state->microcode_name) {
> - status = request_firmware_nowait(THIS_MODULE, 1,
> + if (config->load_firmware_sync) {
> + const struct firmware *fw = NULL;
> +
> + status = request_firmware(&fw, state->microcode_name,
> + state->i2c->dev.parent);
> + if (status < 0)
> + fw = NULL;
> + load_firmware_cb(fw, state);
> + } else {
> + status = request_firmware_nowait(THIS_MODULE, 1,
> state->microcode_name,
> state->i2c->dev.parent,
> GFP_KERNEL,
> state, load_firmware_cb);
> - if (status < 0) {
> - printk(KERN_ERR
> - "drxk: failed to request a firmware\n");
> - return NULL;
> + if (status < 0) {
> + printk(KERN_ERR
> +"drxk: failed to request a firmware\n");
> + return NULL;
> + }
> }
> } else if (init_drxk(state) < 0)
> goto error;
>
Sorry. loading the firmware asynchronously is simply crap! Remove this!
If you intend to load a firmware, firmware loading must be the first
thing you do with the drxk. You must not access the device, before
firmware loading has completed, or correct operation will not be
guaranteed.
If you insist to keep this option, I request that you make synchronous
loading the default, and you enable asynchronous loading only for
devices _you_ have tested. I will never use asynchronous loading.
(In fact, I have already backed-out your firmware patches from my
drivers and forked off my own version of the drxk.)
Oliver
--
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: Previewing PAL fields on framebuffer
Hi Alex (added linux-media to CC on your request) On Wed, 3 Oct 2012, Alex Pollard wrote: > Hi, > > I am wondering if it is possible to use the DMA features in > drivers/dma/ipu/ipu_idmac.c to write the top field of a PAL frame into a > framebuffer on alternating lines, and write the bottom field of the PAL > frame to the other lines ie deinterlace. Looking at the i.MX31 CSI documentation it seems it could be possible to use CSI_SENS_FRM_SIZE and CSI_ACT_FRM_SIZE to specify stride != width to basically do stride = 2 * width and then do 2 transfers per frame - one beginning with line 0 and one beginning with line 1? But that's just an idea, the description of those registers is vague and I'm also not sure how to implement that. Good luck Guennadi > Do you know a good discussion > list where I could post the question? I am using an i.MX53 but the > support "community" is a bit quiet. > > Thanks > > Alex Pollard > Software Engineer > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
