Summary of the pending patches up to Dec, 31 (26 patches)

Dear Developers,

I'm enclosing the current list of patches that I have on my queue. I did an effort to apply a large amount of patches during the past two weeks, in order to be ready for the 2.6.38 merge window, expected to be after the end year's holiday.

I lost about one month of emails from the period between Nov-Dec, so I may have lost a pull request, or some patch comments. I had to fully rely on patchwork for the patches sent during that period.

Kernel 2.6.38 will be a nice Kernel for us, as it will contain some very interesting things:
- The removal of BKL (in fact, .37 will have that also, but
we have some BKL cleanups already for .38, and I suspect that we'll have some bug fixes for the changes during the .38 rc period);
- The removal of V4L1 API. We're trying to remove it for a
very long time. V4L2 API is here since 2002. That means that we took 8 years to remove the legacy API.
- The merge between lirc_i2c and ir-kbd-i2c. The LIRC i2c driver
is also very old, and there were several IR key parsers implemented on both. The missing things were migrated into ir-kbd-i2c and some board-specific get key parsers into their respective boards.

Due to that, we have enough reasons to celebrate the end of this year and the arrival of the next year.

Cheers!

I wish you all the best for the coming year!

P.S.:

1) I explicitly c/c the developers or the ones waiting for an analysis. If you're a developer and were c/c, please comment on the listed patches.
2) I removed the Videobuf2 patches from the list. I expect to be analyzing and testing them during the next week.

		== Need more tests/acks from DVB users == 

Aug, 7 2010: Avoid unnecessary data copying inside dvb_dmx_swfilter_204() function http://patchwork.kernel.org/patch/118147 Marko Ristola <[email protected]>

************************************************************************
* I want to see people testing the above patch, as it seems to improve *
* DVB performance by avoiding data copy. *
************************************************************************

		== mantis patches - Waiting for Manu Abraham <[email protected]> == 

Jun,20 2010: [2/2] DVB/V4L: mantis: remove unused files                             http://patchwork.kernel.org/patch/107062  Bjørn Mork <[email protected]>
Jul,19 2010: Twinhan DTV Ter-CI (3030 mantis)                                       http://patchwork.kernel.org/patch/112708  Niklas Claesson <[email protected]>
Aug, 7 2010: Refactor Mantis DMA transfer to deliver 16Kb TS data per interrupt     http://patchwork.kernel.org/patch/118173  Marko Ristola <[email protected]>
Oct,10 2010: [v2] V4L/DVB: faster DVB-S lock for mantis cards using stb0899 demod   http://patchwork.kernel.org/patch/244201  Tuxoholic <[email protected]>

		== for Adams.Xu <[email protected]> and Manu Abraham <[email protected]> review == 

Jun,11 2010: stb0899: Removed an extra byte sent at init on DiSEqC bus http://patchwork.kernel.org/patch/105621 Florent AUDEBERT <[email protected]>

		== Waiting for Steven Toth <[email protected]> review == 

Nov,24 2010: [media] saa7164: poll mask set incorrectly http://patchwork.kernel.org/patch/351711 Dan Carpenter <[email protected]>

		== Soc_camera waiting for Guennadi Liakhovetski <[email protected]> review == 

Aug, 3 2010: [04/11] mt9m111: added new bit offset defines                          http://patchwork.kernel.org/patch/116721  Michael Grzeschik <[email protected]>
Aug, 3 2010: [08/11] mt9m111: added reg_mask function                               http://patchwork.kernel.org/patch/116722  Michael Grzeschik <[email protected]>
Aug, 3 2010: [v2,11/11] mt9m111: make use of testpattern                            http://patchwork.kernel.org/patch/116730  Michael Grzeschik <[email protected]>
Oct,25 2010: [v3] mt9m111: rewrite set_pixfmt                                       http://patchwork.kernel.org/patch/266822  Michael Grzeschik <[email protected]>
Nov,17 2010: v4l: list entries no need to check                                     http://patchwork.kernel.org/patch/332611  Figo.zhang <[email protected]>
Dec, 2 2010: [v3] soc_camera: Add the ability to bind regulators to soc_camedra dev http://patchwork.kernel.org/patch/373691  Alberto Panizzo <[email protected]>
Dec, 2 2010: [v2] V4L2: Add a v4l2-subdev (soc-camera) driver for OmniVision OV2640 http://patchwork.kernel.org/patch/374771  Alberto Panizzo <[email protected]>
Dec, 5 2010: [1/2] OMAP1: allow reserving memory for camera                         http://patchwork.kernel.org/patch/381601  Janusz Krzysztofik <[email protected]>
Dec, 5 2010: [2/2] OMAP1: Amstrad Delta: reserve memory for camera                  http://patchwork.kernel.org/patch/381621  Janusz Krzysztofik <[email protected]>

Guennadi,
Probably, several of those patches are obsolete and you already pointed it to me. but I probably missed your comments, due to my email issues.

== waiting for Hendrik Skarpeid <[email protected]> tests ==

Oct,23 2010: DM1105: could not attach frontend 195d:1105 http://patchwork.kernel.org/patch/279091 Igor M. Liplianin <[email protected]>

		== Waiting for Patrick Boettcher <[email protected]> review == 

May,25 2010: Adding support to the Geniatech/MyGica SBTVD Stick S870 remote control http://patchwork.kernel.org/patch/102314  Hernán Ordiales <[email protected]>
Jul,14 2010: [1/4] drivers/media/dvb: Remove dead Configs                           http://patchwork.kernel.org/patch/111972  Christian Dietrich <[email protected]>
Jul,14 2010: [2/4] drivers/media/dvb: Remove undead configs                         http://patchwork.kernel.org/patch/111973  Christian Dietrich <[email protected]>

		== waiting for videobuf2 == 

Mar,17 2010: [2/2] V4L/DVB: buf-dma-sg.c: support non-pageable user-allocated memor http://patchwork.kernel.org/patch/97263   Arnout Vandecappelle <[email protected]>
Jul,27 2010: videobuf_dma_sg: a new implementation for mmap                         http://patchwork.kernel.org/patch/114520  Figo.zhang <[email protected]>
Jul,28 2010: [v2] videobuf_dma_sg: a new implementation for mmap                    http://patchwork.kernel.org/patch/114760  Figo.zhang <[email protected]>
Jul,30 2010: [v2] Resend:videobuf_dma_sg: a new implementation for mmap             http://patchwork.kernel.org/patch/115348  Figo.zhang <[email protected]>

The above patches will likely be obsolete after videobuf2 merge. We need to double-check if the needed functionality is provided on videobuf2.

		== Waiting for Mauro Carvalho Chehab <[email protected]> fixes on Docbook == 

Oct,23 2010: [RFC, PATCHv3] DocBook: Add rules to auto-generate some media docbooks http://patchwork.kernel.org/patch/279201 Mauro Carvalho Chehab <[email protected]>

		== Waiting for a Kworld UB430-AF to test and report back to Mauro Carvalho Chehab <[email protected]> == 

Nov, 8 2010: [RFC] cx231xx: Add support for Kworld UB430 AF http://patchwork.kernel.org/patch/308712 Mauro Carvalho Chehab <[email protected]>

Number of pending patches per reviewer:

  Guennadi Liakhovetski <[email protected]>                         : 9
  LinuxTV community                                                     : 5
  Manu Abraham <[email protected]>                                 : 4
  Patrick Boettcher <[email protected]>                         : 3
  Mauro Carvalho Chehab <[email protected]>                            : 2
  Adams Xu <[email protected]>                                     : 1
  Hendrik Skarpeid <[email protected]>                                    : 1
  Steven Toth <[email protected]>                                    : 1

Cheers,
Mauro

---

If you discover any patch submitted via email that weren't caught by kernel.patchwork.org, this means that the patch got mangled by your emailer. The more likely cause is that the emailer converted tabs into spaces or broke long lines.

If you're using Thunderbird, the solution is to install Asalted Patches extension, available at:
https://hg.mozilla.org/users/clarkbw_gnome.org/asalted-patches/
Other emailers will need you to disable the wrapping long lines feature.

Merged into "Oct,25 2010: [v3] mt9m111: rewrite set_pixfmt" below

ditto

A .vidioc_s_input() implementation has been proposed, no reply followed

See my reply to this patch. It has been rejected in that form and there has been no update.

It's the first time I see this one.

In yesterday's pull request

ditto

These two could only go via the ARM tree, if at all.

Wishing you reliable communication in the new year;)

Thanks
Guennadi

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Hi Mauro,

I don't see this patch on it's way upstream:

https://patchwork.kernel.org/patch/376612/ (Sent on 5 Dec 2010)
http://www.spinics.net/lists/linux-media/msg26649.html (Resent on 19 Dec 2010)

It fixes a regression in IR and Analog video for cx23885 based cards and an intermittent analog video regression in ivtv based cards in 2.6.36 and soon in 2.6.37.

I don't see it in the media_tree staging/for_v2.6.38 nor staging/for_2.6.37-rc1 nor master:
http://git.linuxtv.org/media_tree.git?a=history;f=drivers/media/video/cx25840/cx25840-core.c;h=dfb198d0415bc200b0152c1be105d722261653c5;hb=staging/for_v2.6.38
http://git.linuxtv.org/media_tree.git?a=history;f=drivers/media/video/cx25840/cx25840-core.c;h=dfb198d0415bc200b0152c1be105d722261653c5;hb=master
http://git.linuxtv.org/media_tree.git?a=history;f=drivers/media/video/cx25840/cx25840-core.c;h=dfb198d0415bc200b0152c1be105d722261653c5;hb=staging/for_v2.6.37-rc1

I don't see it at a very recent linux-next:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=history;f=drivers/media/video/cx25840/cx25840-core.c;h=dfb198d0415bc200b0152c1be105d722261653c5;hb=bfa221f25c0ec816f725c3a145bda4ee65a277ff

I don't see it at your kernel.org linux-next tree:
http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=history;f=drivers/media/video/cx25840/cx25840-core.c;h=dfb198d0415bc200b0152c1be105d722261653c5;hb=refs/heads/master

Am I missing something?

I cannot get this *REGRESSION*, which I did not introduce, fixed in stable tree(s) until it is upstream.

Also this following commit causes a very bad analog audio *REGRESSION*, which is now shipping in major distirbutions:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fcb9757333df37cf4a7feccef7ef6f5300643864

I emailed the LMML, you, and the author, as soon as I verified the root cause on 31 Dec, and haven't heard from from anyone:

http://www.spinics.net/lists/linux-media/msg27261.html

Please revert it before the merge window closes.

<rant>
I have no time to make improvements that I want to make, much less waste my *VOLUNTEER* time on *REGRESSIONS* that *I DID NOT INTRODUCE*.

It bothers me enough, that as a volunteer, I have to clean up other people's untested cr*pware. AND, that as the lucky individual who finds the bugs, I have to do additional work to get fixes back into stable kernels.

Watching my requests for regressions to be fixed be ignored, as merge windows go by without the fixes going forward so that even more users and kernel versions are affected, makes me wonder why I do this anymore.

Anyone want to be ivtv and cx18 maintainer?
</rant>

I do not share your optimism. Regressions that affect the analog video capture, for the userbase I deal with, have been introduced due to lack of review and testing. It appears to me, that these regessions are going to be in yet another kernel version, 2.6.37, and the gates for getting the known fixes back into stable kernels will still be left unsatisfied.

I, nor PVR-150 and HVR-1250 users, have much to cheer about.

Regards,
Andy

Em 02-01-2011 17:30, Andy Walls escreveu:

Not sure what happened here. I'm sure I've applied on my fixes tree. Anyway, I'm re-applying it.

Here, Dec, 31 is a national holiday. People work only half of the day. Yet, I was finishing some things and preparing patches for the incoming window, until afternoon.

I only noticed your email today, and I'm promptly sending it upstream, together with a patch revert for wm8775 regression.

I'm sending it right now.

Shit happens. A patch adding support for one board might cause regression on other boards, as it is not likely that the author of the patch have all boards that could potentially be affected. That's why we have a long rc period, where people with different hardware are expected to test the -rc kernels and point for regressions.

Mauro.

Thank you.

I understand. But AFAIK the 2.6.37 final is supposed to happen very soon and the end user effects of the problem are very bad.

Thank you.

-Andy

Dear Developers,

Happy New Year.

I'll try to describe my patches so that they would be more understandable.
First comment is for all dvb_dmx_swfilter() and dvb_dmx_swfilter_204() users: please test the performance improvement. The second comment is mostly to convince Manu Abraham, but the concept might be useful for others too. Please read.

This patch affects equally for both dvb_dmx_swfilter() and dvb_dmx_swfilter_204(). The resulting performance and functionality is similar with dvb_dmx_swfilter_packets(). dvb_dmx_swfilter(_204)() have robustness checks. Devices without such need can still use dvb_dmx_swfilter_packets().

My performance patch helps especially with high volume 256-QAM TS streams containing for example HDTV content by removing one unnecessary stream copy.
With "perf top", dvb_dmx_swfilter_204()'s CPU consumption reduced in the following way:

Without the patch dvb_dmx_swfilter_204() and dvb_dmx_swfilter_packet() took about equal amounts of CPU. With the patch dvb_dmx_swfilter_204()'s CPU consumption went into 1/5 or 1/10 of the original (resulting minor CPU consumption). dvb_dmx_swfilter_packet()'s CPU time was about as before.

Test environment was Fedora with VDR streaming HDTV into network.
I have tested the patch thoroughly (see for example https://patchwork.kernel.org/patch/108274).

The patch assumes that dvb_dmx_swfilter_packet() can eat data stream fast enough so that the DVB card's DMA engine will not replace buffer content underneath of dvb_dmx_swfilter_204().

It would be helpful if someone using dvb_dmx_swfilter() could try the patch too: maybe nobody has tried it. The benefit would be, that dvb_dmx_swfilter() is almost equally fast as the existing blatantly fast dvb_dmx_swfilter_packets() :)

16Kb TS stream improvement: What do you think about this, Manu Abraham?

If high volume TS stream (256-QAM) with 50Mbits/s generates one interrupt once per 4096 bytes, you have a problem.
Mantis driver copies 4096 bytes with one interrupt, into dvb_core's 128K buffer. VDR reads data in big pieces (as much data as you get).
Network layer receives data in about 100K - 300K pieces from VDR.

So I think that it is unnecessary to interrupt other processes once per 4096 bytes, for 56Mbit/s streams. With 16K / interrupt you reduce the number of interrupts into one quarter, without affecting VDR at all, lessening unnecessary interrupts and giving CPU time to other processes.

The CPU might have some other things to do without wanting to get interrupted once per (displaying HDTV, delivering HDTV stream to network). Mantis/Hopper kernel driver must process the whole high volume TS stream, although it might deliver only one radio channel forward.

I saw glitches with HDTV (followed by stream halt) even though the Mantis DVB card only delivered the data into the local network via VDR. I don't have such single CPU computer anymore though.

16K comes from the fact that it is not good to try to overload dvb_core's 128K buffer. 3/4 of the interrupts are gone. DVB driver does at least twice the number of interrupts compared to VDR reading the stream:
dvb_core's buffer is never empty when VDR asks more data.

Best regards,
Marko Ristola