Patches submitted via linux-media ML that are at patchwork.linuxtv.org

In order to help people to know about the status of the pending patches, I'm summing-up the patches pending for merge on this email.

If is there any patch missing, please check if it is at patchwork before asking what happened:
http://patchwork.linuxtv.org/project/linux-media/list/?state=*

If patchwork didn't pick, then the emailer likely line-wrapped or corrupted the patch.

		== Laurent Pinchart <[email protected]> == 

Sep,27 2011: [v2,1/5] omap3evm: Enable regulators for camera interface              http://patchwork.linuxtv.org/patch/7969   Vaibhav Hiremath <[email protected]>
Jul,26 2012: [1/2,media] omap3isp: implement ENUM_FMT                               http://patchwork.linuxtv.org/patch/13492  Michael Jones <[email protected]>
Jul,26 2012: [2/2,media] omap3isp: support G_FMT                                    http://patchwork.linuxtv.org/patch/13493  Michael Jones <[email protected]>

		== Prabhakar Lad <[email protected]> == 

Aug, 2 2012: [1/1] media/video: vpif: fixing function name start to vpif_config_par http://patchwork.linuxtv.org/patch/13576 Dror Cohen <[email protected]>

		== Silvester Nawrocki <[email protected]> == 

Aug, 2 2012: [PATH,v3,1/2] v4l: Add factory register values form S5K4ECGX sensor    http://patchwork.linuxtv.org/patch/13580  Sangwook Lee <[email protected]>
Aug, 2 2012: [PATH,v3,2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor          http://patchwork.linuxtv.org/patch/13581  Sangwook Lee <[email protected]>
Aug,10 2012: [1/2,media] s5p-tv: Use devm_regulator_get() in sdo_drv.c file         http://patchwork.linuxtv.org/patch/13719  Sachin Kamat <[email protected]>
Aug,10 2012: [2/2,media] s5p-tv: Use devm_* functions in sii9234_drv.c file         http://patchwork.linuxtv.org/patch/13720  Sachin Kamat <[email protected]>
Aug,10 2012: [RESEND] v4l/s5p-mfc: added support for end of stream handling in MFC  http://patchwork.linuxtv.org/patch/13721  Andrzej Hajda <[email protected]>
Aug,10 2012: [v4,1/2] v4l: Add factory register values form S5K4ECGX sensor         http://patchwork.linuxtv.org/patch/13727  Sangwook Lee <[email protected]>
Aug,10 2012: [v4,2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor               http://patchwork.linuxtv.org/patch/13728  Sangwook Lee <[email protected]>
Jun,11 2012: [1/3,media] s5p-tv: Replace printk with pr_* functions                 http://patchwork.linuxtv.org/patch/11666  Sachin Kamat <[email protected]>
Jun,11 2012: [2/3,media] s5p-mfc: Replace printk with pr_* functions                http://patchwork.linuxtv.org/patch/11667  Sachin Kamat <[email protected]>
Jun,11 2012: [3/3,media] s5p-fimc: Replace printk with pr_* functions               http://patchwork.linuxtv.org/patch/11668  Sachin Kamat <[email protected]>
Jun,12 2012: [1/1, media] s5p-fimc: Replace custom err() macro with v4l2_err() macr http://patchwork.linuxtv.org/patch/11675  Sachin Kamat <[email protected]>

		== Jonathan Corbet <[email protected]> == 

Apr,26 2012: [2/2] marvell-cam: Build fix: missing "select VIDEOBUF2_VMALLOC" http://patchwork.linuxtv.org/patch/10848 Chris Ball <[email protected]>

This one is an alternative RFC proposal for the above, if Jon/Chris decide to take another approach:

Aug,13 2012: [2/2] marvell-cam: Build fix: missing "select VIDEOBUF2_VMALLOC" http://patchwork.linuxtv.org/patch/13784 Mauro Carvalho Chehab <[email protected]>

		== Manu Abraham <[email protected]> == 

Jun, 8 2011: Add remote control support for mantis                                  http://patchwork.linuxtv.org/patch/7217   Christoph Pinkl <[email protected]>
Nov,29 2011: stv090x: implement function for reading uncorrected blocks count       http://patchwork.linuxtv.org/patch/8656   Mariusz Bia?o?czyk <[email protected]>
Mar,11 2012: [2/3] stv090x: use error counter 1 for BER estimation                  http://patchwork.linuxtv.org/patch/10301  Andreas Regel <[email protected]>
Mar,11 2012: [3/3] stv090x: On STV0903 do not set registers of the second path.     http://patchwork.linuxtv.org/patch/10302  Andreas Regel <[email protected]>
Apr, 1 2012: [05/11] Slightly more friendly debugging output.                       http://patchwork.linuxtv.org/patch/10520  "Steinar H. Gunderson" <[email protected]>
Apr, 1 2012: [06/11] Replace ca_lock by a slightly more general int_stat_lock.      http://patchwork.linuxtv.org/patch/10521  "Steinar H. Gunderson" <[email protected]>
Apr, 1 2012: [07/11] Fix a ton of SMP-unsafe accesses.                              http://patchwork.linuxtv.org/patch/10523  "Steinar H. Gunderson" <[email protected]>
Apr, 1 2012: [11/11] Enable Mantis CA support.                                      http://patchwork.linuxtv.org/patch/10524  "Steinar H. Gunderson" <[email protected]>
Apr, 1 2012: [08/11] Remove some unused structure members.                          http://patchwork.linuxtv.org/patch/10525  "Steinar H. Gunderson" <[email protected]>
Apr, 1 2012: [09/11] Correct wait_event_timeout error return check.                 http://patchwork.linuxtv.org/patch/10526  "Steinar H. Gunderson" <[email protected]>
Apr, 1 2012: [10/11] Ignore timeouts waiting for the IRQ0 flag.                     http://patchwork.linuxtv.org/patch/10527  "Steinar H. Gunderson" <[email protected]>

		== David Härdeman <[email protected]> == 

Jul,31 2012: [media] winbond-cir: Fix initialization http://patchwork.linuxtv.org/patch/13539 Sean Young <[email protected]>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi Mauro,

Quoted 4 lines

		== Prabhakar Lad <[email protected]> == 

Aug, 2 2012: [1/1] media/video: vpif: fixing function name start to vpif_config_par http://patchwork.linuxtv.org/patch/13576 Dror Cohen <[email protected]>

This patch can be marked as 'Rejected'. Dror has sent a v2 version
fixing few comments (http://patchwork.linuxtv.org/patch/13689/) which I'll issue a pull to this v2 patch through Manju's tree soon for 3.7.

In order to help people to know about the status of the pending patches, I'm summing-up the patches pending for merge on this email.

If is there any patch missing, please check if it is at patchwork before asking what happened:
http://patchwork.linuxtv.org/project/linux-media/list/?state=*

If patchwork didn't pick, then the emailer likely line-wrapped or corrupted the patch.

As announced, patchwork is now generating status change emails. So, those that didn't decide to opt-out emails there will receive notifications every time a patch is reviewed. Unfortunately, patchwork doesn't send emails is when a patch is stored there.

For the ones explicitly copied on this email, I kindly ask you to update me about the review status of the patches below.

In special, on my track list, there are three patches from 2011 still not reviewed. Driver maintainers: I kindly ask you to be more active on patch reviewing, not holding any patch for long periods like that, and sending pull request more often. You should only be holding patches if you have very strong reasons why this is required.

A final note: patches from driver maintainers with git trees are generally just marked as RFC. Well, I still applied several of them, when they're trivial enough and they're seem to be addressing a real bug - helping myself to not need to re-review them later.

I really expect people to add more "RFC" on patches. We're having a net commit rate of about 500-600 patches per merge window, and perhaps 3 or 4 times more patches at the ML that are just part of some discussions and aren't yet on their final version. It doesn't scale if I need to review ~3000 patches per merge window, as that would mean reviewing 75 patches per working day. Unfortunately, linux-media patch reviewing is not my full-time job. So, please help me marking those under-discussion patches as RFC, in order to allow me to focus on the 600 ones that will actually be merged.

		== Silvester Nawrocki <[email protected]> == 

Aug, 2 2012: [PATH,v3,1/2] v4l: Add factory register values form S5K4ECGX sensor    http://patchwork.linuxtv.org/patch/13580  Sangwook Lee <[email protected]>
Aug, 2 2012: [PATH,v3,2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor          http://patchwork.linuxtv.org/patch/13581  Sangwook Lee <[email protected]>
Aug,10 2012: [1/2,media] s5p-tv: Use devm_regulator_get() in sdo_drv.c file         http://patchwork.linuxtv.org/patch/13719  Sachin Kamat <[email protected]>
Aug,10 2012: [2/2,media] s5p-tv: Use devm_* functions in sii9234_drv.c file         http://patchwork.linuxtv.org/patch/13720  Sachin Kamat <[email protected]>
Aug,10 2012: [RESEND] v4l/s5p-mfc: added support for end of stream handling in MFC  http://patchwork.linuxtv.org/patch/13721  Andrzej Hajda <[email protected]>
Aug,10 2012: [v4,1/2] v4l: Add factory register values form S5K4ECGX sensor         http://patchwork.linuxtv.org/patch/13727  Sangwook Lee <[email protected]>
Aug,10 2012: [v4,2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor               http://patchwork.linuxtv.org/patch/13728  Sangwook Lee <[email protected]>
Jun,11 2012: [1/3,media] s5p-tv: Replace printk with pr_* functions                 http://patchwork.linuxtv.org/patch/11666  Sachin Kamat <[email protected]>
Jun,11 2012: [2/3,media] s5p-mfc: Replace printk with pr_* functions                http://patchwork.linuxtv.org/patch/11667  Sachin Kamat <[email protected]>
Jun,11 2012: [3/3,media] s5p-fimc: Replace printk with pr_* functions               http://patchwork.linuxtv.org/patch/11668  Sachin Kamat <[email protected]>
Jun,12 2012: [1/1, media] s5p-fimc: Replace custom err() macro with v4l2_err() macr http://patchwork.linuxtv.org/patch/11675  Sachin Kamat <[email protected]>

Quoted 5 lines

A final note: patches from driver maintainers with git trees are generally just marked as RFC. Well, I still applied several of them, when they're trivial enough and they're seem to be addressing a real bug - helping myself to not need to re-review them later.

Does that mean that if you are a maintainer with a git tree such as myself you should make a pull request instead of posting a [PATCH] because otherwise you mark it as an RFC patch?

I often just post simple patches instead of making a pull request, and I always use [RFC PATCH] if I believe the patches need more discussion.

So if I post a [PATCH] as opposed to an [RFC PATCH], then that means that I believe that the [PATCH] is ready for merging. If I should no longer do that, but make a pull request instead, then that needs to be stated very explicitly by you. Otherwise things will get very confusing.

Quoted 8 lines

I really expect people to add more "RFC" on patches. We're having a net commit rate of about 500-600 patches per merge window, and perhaps 3 or 4 times more patches at the ML that are just part of some discussions and aren't yet on their final version. It doesn't scale if I need to review ~3000 patches per merge window, as that would mean reviewing 75 patches per working day. Unfortunately, linux-media patch reviewing is not my full-time job. So, please help me marking those under-discussion patches as RFC, in order to allow me to focus on the 600 ones that will actually be merged.

In fairness: often you get no comments when you post the RFC patch series, but once you post what you consider to be the final version you suddenly do get comments.

One example where you apparently marked a [PATCH] as RFC is this one:

http://patchwork.linuxtv.org/patch/13659/

Is this because Sylwester has his own git tree and you were expecting a pull request?

In this case it is a simple compiler warning fix which I would really like to see merged since it fixes a fair number of compiler warnings during the daily build.

Em 14-08-2012 10:46, Hans Verkuil escreveu:

Quoted 10 lines · On Tue August 14 2012 15:04:17 Mauro Carvalho Chehab wrote:

Quoted 5 lines

A final note: patches from driver maintainers with git trees are generally
just marked as RFC. Well, I still applied several of them, when they're trivial enough and they're seem to be addressing a real bug - helping myself to not need to re-review them later.

Does that mean that if you are a maintainer with a git tree such as myself you should make a pull request instead of posting a [PATCH] because otherwise you mark it as an RFC patch?

Yes, please.

Quoted 2 lines

I often just post simple patches instead of making a pull request, and I always use [RFC PATCH] if I believe the patches need more discussion.

That would work if the others would be doing the same. Unfortunately, other usual developers don't do that: they send all patches under discussions as "PATCH", making really hard to track what's ready for maintainer's review and what isn't. As not-so-frequent contributors (trivial fixes people; users submitting their bug fix patches; first time contributors) send their patch as "PATCH". Those patches aren't typically picked by driver maintainers, so the task of reviewing them is, unfortunately, typically done only by me.

Quoted 4 lines

So if I post a [PATCH] as opposed to an [RFC PATCH], then that means that I believe that the [PATCH] is ready for merging. If I should no longer do that, but make a pull request instead, then that needs to be stated very explicitly by you. Otherwise things will get very confusing.

Yes, please post them as [RFC PATCH].

Maybe the patches that are about to be sent though a pull request could use something like [RFC FINAL] or [PATCH FINAL], but maybe doing that would be just overkill.

Quoted 10 lines

Quoted 9 lines

I really expect people to add more "RFC" on patches. We're having a net commit rate of about 500-600 patches per merge window, and perhaps 3 or 4 times more patches at the ML that are just part of some discussions and aren't yet on their final version. It doesn't scale if I need to review ~3000 patches per merge window, as that would mean reviewing 75 patches per working day. Unfortunately, linux-media patch reviewing is not my full-time job. So, please help me marking those under-discussion patches as RFC, in order to allow me to focus on the 600 ones that will actually be merged.

Quoted 3 lines

In fairness: often you get no comments when you post the RFC patch series, but once you post what you consider to be the final version you suddenly do get comments.

Well, if people don't comment the RFC patches, they should not be complaining when it gets merged.

Thinking about that, by not having a "non-RFC" final patch series may actually improve the process at long term, as people will look with another eyes for the RFC ones.

Quoted 6 lines

One example where you apparently marked a [PATCH] as RFC is this one:

http://patchwork.linuxtv.org/patch/13659/

Is this because Sylwester has his own git tree and you were expecting a pull request?

Yes.

Quoted 3 lines

In this case it is a simple compiler warning fix which I would really like to see merged since it fixes a fair number of compiler warnings during the daily build.

See:

	http://patchwork.linuxtv.org/patch/13763/

This is pretty much the same case of 13659, except that the patch was a RFC (not tagged as such), and it was wrong. The correct one is:

	http://patchwork.linuxtv.org/patch/13790/

Without tagging them differently, I don't have any way to know what are ready for merge, and what wasn't.

Anyway, I'm open to ideas on how to handle it better, especially when it helps to allow handling patches on uniform way, without needing to apply different procedures for each driver maintainer.

Hi Mauro,

Quoted 14 lines · On Tuesday 14 August 2012 11:28:05 Mauro Carvalho Chehab wrote:

Em 14-08-2012 10:46, Hans Verkuil escreveu:
That would work if the others would be doing the same. Unfortunately, other usual developers don't do that: they send all patches under discussions as "PATCH", making really hard to track what's ready for maintainer's review and what isn't. As not-so-frequent contributors (trivial fixes people; users submitting their bug fix patches; first time contributors) send their patch as "PATCH". Those patches aren't typically picked by driver maintainers, so the task of reviewing them is, unfortunately, typically done only by me.

Quoted 4 lines

So if I post a [PATCH] as opposed to an [RFC PATCH], then that means that I believe that the [PATCH] is ready for merging. If I should no longer do that, but make a pull request instead, then that needs to be stated very explicitly by you. Otherwise things will get very confusing.

Quoted 5 lines

Yes, please post them as [RFC PATCH].

Maybe the patches that are about to be sent though a pull request could use something like [RFC FINAL] or [PATCH FINAL], but maybe doing that would be just overkill.

I post patches that I believe to be ready to be merged as "[PATCH]", even if I plan to push them through my tree later. "RFC" usually has a different meaning, I understand it as a work in progress on which comments would be appreciated.

As new developers just post patches as "[PATCH]" (probably because that's git's default) we can't really change the meaning of that tag. We could ask developers who maintain their own git tree to use a different tag (something like "[PATCH FOR REVIEW]" for instance), but that won't work well if we need to cross-post to other mailing lists that follow a different standard.

Quoted 28 lines

Hi Mauro,

Quoted 14 lines · On Tuesday 14 August 2012 11:28:05 Mauro Carvalho Chehab wrote:

Em 14-08-2012 10:46, Hans Verkuil escreveu:
That would work if the others would be doing the same. Unfortunately, other usual developers don't do that: they send all patches under discussions as "PATCH", making really hard to track what's ready for maintainer's review and what isn't. As not-so-frequent contributors (trivial fixes people; users submitting their bug fix patches; first time contributors) send their patch as "PATCH". Those patches aren't typically picked by driver maintainers, so the task of reviewing them is, unfortunately, typically done only by me.

Quoted 4 lines

So if I post a [PATCH] as opposed to an [RFC PATCH], then that means that I believe that the [PATCH] is ready for merging. If I should no longer do that, but make a pull request instead, then that needs to be stated very explicitly by you. Otherwise things will get very confusing.

Quoted 5 lines

Yes, please post them as [RFC PATCH].

Maybe the patches that are about to be sent though a pull request could use something like [RFC FINAL] or [PATCH FINAL], but maybe doing that would be just overkill.

I post patches that I believe to be ready to be merged as "[PATCH]", even if I plan to push them through my tree later. "RFC" usually has a different meaning, I understand it as a work in progress on which comments would be appreciated.

Quoted 5 lines

As new developers just post patches as "[PATCH]" (probably because that's git's default) we can't really change the meaning of that tag. We could ask developers who maintain their own git tree to use a different tag (something like "[PATCH FOR REVIEW]" for instance), but that won't work well if we need to cross-post to other mailing lists that follow a different standard.

As one of the "not-so-frequent" contributors, it's obvious to me why we (incorrectly?) use just [PATCH] for initial submissions. Partly because it's git's default. Partly because Documentation/SubmittingPatches describes this. The LinuxTV Wiki says to [1] ("RFC" is nowhere on this page). There are many parts of protocol here that may just be obvious to the regulars, but documentation-by-mailing-list is a frustrating and error-prone way to have to glean the guidelines before submission. If this thread leads to new agreed-upon guidelines, could someone please update [1] to reflect whatever
the consensus is? It would be appropriate to at least mention 'git send-email' there, too.

Em 14-08-2012 10:46, Hans Verkuil escreveu:

Quoted 7 lines · On Tue August 14 2012 15:04:17 Mauro Carvalho Chehab wrote:

Quoted 5 lines

A final note: patches from driver maintainers with git trees are generally just marked as RFC. Well, I still applied several of them, when they're trivial enough and they're seem to be addressing a real bug - helping myself to not need to re-review them later.

Quoted 3 lines

Does that mean that if you are a maintainer with a git tree such as myself you should make a pull request instead of posting a [PATCH] because otherwise you mark it as an RFC patch?

Yes, please.

Quoted 2 lines

I often just post simple patches instead of making a pull request, and I always use [RFC PATCH] if I believe the patches need more discussion.

That would work if the others would be doing the same. Unfortunately, other usual developers don't do that: they send all patches under discussions as "PATCH", making really hard to track what's ready for maintainer's review and what isn't. As not-so-frequent contributors (trivial fixes people; users submitting their bug fix patches; first time contributors) send their patch as "PATCH". Those patches aren't typically picked by driver maintainers, so the task of reviewing them is, unfortunately, typically done only by me.

Quoted 4 lines

So if I post a [PATCH] as opposed to an [RFC PATCH], then that means that I believe that the [PATCH] is ready for merging. If I should no longer do that, but make a pull request instead, then that needs to be stated very explicitly by you. Otherwise things will get very confusing.

Yes, please post them as [RFC PATCH].

Maybe the patches that are about to be sent though a pull request could use something like [RFC FINAL] or [PATCH FINAL], but maybe doing that would be just overkill.

Quoted 9 lines

Quoted 8 lines

I really expect people to add more "RFC" on patches. We're having a net commit rate of about 500-600 patches per merge window, and perhaps 3 or 4 times more patches at the ML that are just part of some discussions and aren't yet on their final version. It doesn't scale if I need to review ~3000 patches per merge window, as that would mean reviewing 75 patches per working day. Unfortunately, linux-media patch reviewing is not my full-time job. So, please help me marking those under-discussion patches as RFC, in order to allow me to focus on the 600 ones that will actually be merged.

Quoted 3 lines

In fairness: often you get no comments when you post the RFC patch series, but once you post what you consider to be the final version you suddenly do get comments.

Well, if people don't comment the RFC patches, they should not be complaining when it gets merged.

Thinking about that, by not having a "non-RFC" final patch series may actually improve the process at long term, as people will look with another eyes for the RFC ones.

Quoted 6 lines

One example where you apparently marked a [PATCH] as RFC is this one:

http://patchwork.linuxtv.org/patch/13659/

Is this because Sylwester has his own git tree and you were expecting a pull request?

Yes.

Quoted 3 lines

In this case it is a simple compiler warning fix which I would really like to see merged since it fixes a fair number of compiler warnings during the daily build.

See:

	http://patchwork.linuxtv.org/patch/13763/

This is pretty much the same case of 13659, except that the patch was a RFC (not tagged as such), and it was wrong. The correct one is:

	http://patchwork.linuxtv.org/patch/13790/

Without tagging them differently, I don't have any way to know what are ready for merge, and what wasn't.

Anyway, I'm open to ideas on how to handle it better, especially when it helps to allow handling patches on uniform way, without needing to apply different procedures for each driver maintainer.

Quoted 12 lines · On Tue August 14 2012 16:28:05 Mauro Carvalho Chehab wrote:

Em 14-08-2012 10:46, Hans Verkuil escreveu:

Quoted 10 lines · On Tue August 14 2012 15:04:17 Mauro Carvalho Chehab wrote:

Quoted 5 lines

A final note: patches from driver maintainers with git trees are generally just marked as RFC. Well, I still applied several of them, when they're trivial enough and they're seem to be addressing a real bug - helping myself to not need to re-review them later.

Does that mean that if you are a maintainer with a git tree such as myself you should make a pull request instead of posting a [PATCH] because otherwise you mark it as an RFC patch?

Quoted 1 line

Yes, please.

OK. It would help if you notify all maintainers that you handle in such a manner. And perhaps have a list on the wiki as well.

That way there is no confusion.

Quoted 5 lines

Em 14-08-2012 10:46, Hans Verkuil escreveu:

Quoted 1 line · On Tue August 14 2012 15:04:17 Mauro Carvalho Chehab wrote:

Without tagging them differently, I don't have any way to know what are ready for merge, and what wasn't.

It's too bad patchwork doesn't support a way where the submitter can kill a wrong patch. That would be very useful.

Quoted 3 lines

Anyway, I'm open to ideas on how to handle it better, especially when it helps to allow handling patches on uniform way, without needing to apply different procedures for each driver maintainer.

I have no problem with making pull requests when I think a patch series is ready, as long as it is made very clear to me that that's the way you work for patches from me.

This is fine for 'regular' patches. But in practice I also have two other kinds of patches: the first is the trivial kind: fixing typos, compiler warnings, one-liner bug fixes. Basically patches where the review process takes one minute tops. I would propose a [PATCH TRIVIAL] category: patchwork would pick them up, you go through them quickly once or twice a week and either apply them or mark them as RFC or something if you think they aren't as trivial as they look.

That way my git tree won't get messy with lots of little branches for what are trivial patches, and these patches get processed quickly so they won't clutter patchwork.

The other type of patch are core kernel API changes. Those need a review from you as well, and it is frankly very annoying if after a long discussion on the mailinglist we come to a solution, make a final pull request for it, and only then will you review it and shoot it down... And sometimes that happens just before the merge window opens, leaving us with no time to fix things.

I don't mind being shot down, but I'd like to see that happen a bit earlier in the process when I haven't invested that much time in it and when I can make changes in a timely manner.

So I proprose a [PATCH API] category for patches enhancing or modifying the core API.

It's a signal for you that these are relevant for you as subsystem maintainer to look at them earlier rather than waiting for the final pull request.

What do you think?

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

		== Silvester Nawrocki <[email protected]> == 

Aug, 2 2012: [PATH,v3,1/2] v4l: Add factory register values form S5K4ECGX sensor    http://patchwork.linuxtv.org/patch/13580  Sangwook Lee <[email protected]>
Aug, 2 2012: [PATH,v3,2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor          http://patchwork.linuxtv.org/patch/13581  Sangwook Lee <[email protected]>

Aug,10 2012: [1/2,media] s5p-tv: Use devm_regulator_get() in sdo_drv.c file         http://patchwork.linuxtv.org/patch/13719  Sachin Kamat <[email protected]>
Aug,10 2012: [2/2,media] s5p-tv: Use devm_* functions in sii9234_drv.c file         http://patchwork.linuxtv.org/patch/13720  Sachin Kamat <[email protected]>

Aug,10 2012: [RESEND] v4l/s5p-mfc: added support for end of stream handling in MFC http://patchwork.linuxtv.org/patch/13721 Andrzej Hajda <[email protected]>

Aug,10 2012: [v4,1/2] v4l: Add factory register values form S5K4ECGX sensor http://patchwork.linuxtv.org/patch/13727 Sangwook Lee <[email protected]>

Aug,10 2012: [v4,2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor http://patchwork.linuxtv.org/patch/13728 Sangwook Lee <[email protected]>

Jun,11 2012: [1/3,media] s5p-tv: Replace printk with pr_* functions http://patchwork.linuxtv.org/patch/11666 Sachin Kamat <[email protected]>

Jun,11 2012: [2/3,media] s5p-mfc: Replace printk with pr_* functions http://patchwork.linuxtv.org/patch/11667 Sachin Kamat <[email protected]>

Jun,11 2012: [3/3,media] s5p-fimc: Replace printk with pr_* functions http://patchwork.linuxtv.org/patch/11668 Sachin Kamat <[email protected]>

Jun,12 2012: [1/1, media] s5p-fimc: Replace custom err() macro with v4l2_err() macr http://patchwork.linuxtv.org/patch/11675 Sachin Kamat <[email protected]>

Quoted 4 lines · Mauro Carvalho Chehab

		== Silvester Nawrocki <[email protected]> == 

Aug, 2 2012: [PATH,v3,1/2] v4l: Add factory register values form S5K4ECGX sensor    http://patchwork.linuxtv.org/patch/13580  Sangwook Lee <[email protected]>
Aug, 2 2012: [PATH,v3,2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor          http://patchwork.linuxtv.org/patch/13581  Sangwook Lee <[email protected]>

These two are superseded by v4, which is currently under review. We're going to send a pull request when these works are completed. Sangwook, could you mark any subsequent iterations in future as "PATCH" ?

In order to help people to know about the status of the pending patches, I'm summing-up the patches pending for merge on this email.

If is there any patch missing, please check if it is at patchwork before asking what happened:
http://patchwork.linuxtv.org/project/linux-media/list/?state=*

If patchwork didn't pick, then the emailer likely line-wrapped or corrupted the patch.

As announced, patchwork is now generating status change emails. So, those that didn't decide to opt-out emails there will receive notifications every time a patch is reviewed. Unfortunately, patchwork doesn't send emails is when a patch is stored there.

For the ones explicitly copied on this email, I kindly ask you to update me about the review status of the patches below.

In special, on my track list, there are three patches from 2011 still not reviewed. Driver maintainers: I kindly ask you to be more active on patch reviewing, not holding any patch for long periods like that, and sending pull request more often. You should only be holding patches if you have very strong reasons why this is required.

A final note: patches from driver maintainers with git trees are generally just marked as RFC. Well, I still applied several of them, when they're trivial enough and they're seem to be addressing a real bug - helping myself to not need to re-review them later.

I really expect people to add more "RFC" on patches. We're having a net commit rate of about 500-600 patches per merge window, and perhaps 3 or 4 times more patches at the ML that are just part of some discussions and aren't yet on their final version. It doesn't scale if I need to review ~3000 patches per merge window, as that would mean reviewing 75 patches per working day. Unfortunately, linux-media patch reviewing is not my full-time job. So, please help me marking those under-discussion patches as RFC, in order to allow me to focus on the 600 ones that will actually be merged.

Thank you!
Mauro

Number of pending patches per reviewer (excluding the newer ones):
Guennadi Liakhovetski <[email protected]> : 17

Manu Abraham <[email protected]>                                 : 11
Silvester Nawrocki <[email protected]>                     : 11
Laurent Pinchart <[email protected]>                  : 3
Jonathan Corbet <[email protected]>                                      : 2

David Härdeman <[email protected]> : 1
Prabhakar Lad <[email protected]> : 1

		== Patches waiting for some action ==

This one requires more testing:

May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API
http://patchwork.linuxtv.org/patch/11268
Sylwester Nawrocki <[email protected]>

		== Guennadi Liakhovetski <[email protected]> ==

Aug, 2 2012: [v3] mt9v022: Add support for mt9v024
http://patchwork.linuxtv.org/patch/13582
Alex Gershgorin <[email protected]>
Aug, 6 2012: [1/1] media: mx3_camera: Improve data bus width check code for probe

		http://patchwork.linuxtv.org/patch/13618
		Liu Ying <[email protected]>
Aug, 9 2012: [1/1, v2] media/video: vpif: fixing function name start to
vpif_config
		http://patchwork.linuxtv.org/patch/13689
		Dror Cohen <[email protected]>

		== Laurent Pinchart <[email protected]> ==

Sep,27 2011: [v2,1/5] omap3evm: Enable regulators for camera interface
http://patchwork.linuxtv.org/patch/7969
Vaibhav Hiremath <[email protected]>

Jul,26 2012: [1/2,media] omap3isp: implement ENUM_FMT

		http://patchwork.linuxtv.org/patch/13492
		Michael Jones <[email protected]>
Jul,26 2012: [2/2,media] omap3isp: support G_FMT
		http://patchwork.linuxtv.org/patch/13493
		Michael Jones <[email protected]>

Quoted 3 lines

May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API
http://patchwork.linuxtv.org/patch/11268
Sylwester Nawrocki <[email protected]>

What is needed here, can I help with testing ?

[snip]

Quoted 7 lines

		== Guennadi Liakhovetski <[email protected]> ==

Aug, 2 2012: [v3] mt9v022: Add support for mt9v024
http://patchwork.linuxtv.org/patch/13582
Alex Gershgorin <[email protected]>
Aug, 6 2012: [1/1] media: mx3_camera: Improve data bus width check code for probe

Quoted 6 lines

		http://patchwork.linuxtv.org/patch/13618
		Liu Ying <[email protected]>
Aug, 9 2012: [1/1, v2] media/video: vpif: fixing function name start to
vpif_config
		http://patchwork.linuxtv.org/patch/13689
		Dror Cohen <[email protected]>

I think this one has been misclassified. v1 was correctly attributed to Prabhakar Lad <[email protected]>

[snip]

Quoted 5 lines

		== Laurent Pinchart <[email protected]> ==

Sep,27 2011: [v2,1/5] omap3evm: Enable regulators for camera interface
http://patchwork.linuxtv.org/patch/7969
Vaibhav Hiremath <[email protected]>

I'm fine with that one, shouldn't it go through the arm tree ?

Quoted 6 lines

Jul,26 2012: [1/2,media] omap3isp: implement ENUM_FMT

		http://patchwork.linuxtv.org/patch/13492
		Michael Jones <[email protected]>
Jul,26 2012: [2/2,media] omap3isp: support G_FMT
		http://patchwork.linuxtv.org/patch/13493
		Michael Jones <[email protected]>

A proper solution for this will first require CREATE_BUFS/PREPARE_BUF support in the OMAP3 ISP driver (and a move to videobuf2).

This one requires more testing:

May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API http://patchwork.linuxtv.org/patch/11268 Sylwester Nawrocki <[email protected]>

Quoted 5 lines · Mauro Carvalho Chehab

This one requires more testing:

May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API
http://patchwork.linuxtv.org/patch/11268 Sylwester Nawrocki
<[email protected]>

Hmm, this is not valid any more. Tomasz just posted a new patch series that adds DMABUF importer and exporter feature altogether.

[PATCHv8 00/26] Integration of videobuf2 with DMABUF

I guess we need someone else to submit test patches for other H/W than just Samsung SoCs. I'm not sure if we've got enough resources to port this to other hardware. We have been using these features internally for some time already. It's been 2 kernel releases and I can see only Ack tags from Laurent on Tomasz's patch series, hence it seems there is no wide interest in DMABUF support in V4L2 and this patch series is probably going to stay in a fridge for another few kernel releases.

Hi Sylwester,

Quoted 11 lines · On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote:

Quoted 5 lines · Mauro Carvalho Chehab

This one requires more testing:

May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API
http://patchwork.linuxtv.org/patch/11268 Sylwester Nawrocki
<[email protected]>

Hmm, this is not valid any more. Tomasz just posted a new patch series that adds DMABUF importer and exporter feature altogether.

[PATCHv8 00/26] Integration of videobuf2 with DMABUF

Quoted 7 lines

I guess we need someone else to submit test patches for other H/W than just Samsung SoCs. I'm not sure if we've got enough resources to port this to other hardware. We have been using these features internally for some time already. It's been 2 kernel releases and I can see only Ack tags from Laurent on Tomasz's patch series, hence it seems there is no wide interest in DMABUF support in V4L2 and this patch series is probably going to stay in a fridge for another few kernel releases.

What would be required to push it to v3.7 ?

Quoted 21 lines · Laurent Pinchart

Quoted 12 lines · On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote:

Quoted 5 lines · Mauro Carvalho Chehab

This one requires more testing:

May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API
http://patchwork.linuxtv.org/patch/11268 Sylwester Nawrocki
<[email protected]>

Hmm, this is not valid any more. Tomasz just posted a new patch series that adds DMABUF importer and exporter feature altogether.

[PATCHv8 00/26] Integration of videobuf2 with DMABUF

Quoted 7 lines

I guess we need someone else to submit test patches for other H/W than just Samsung SoCs. I'm not sure if we've got enough resources to port this to other hardware. We have been using these features internally for some time already. It's been 2 kernel releases and I can see only Ack tags from Laurent on Tomasz's patch series, hence it seems there is no wide interest in DMABUF support in V4L2 and this patch series is probably going to stay in a fridge for another few kernel releases.

Quoted 1 line

What would be required to push it to v3.7 ?

Mauro requested more test coverage on that, which is understood since this is a fairly important API enhancement and the V4L2 video overlay API replacement.

We need DMABUF support added at some webcam driver and a DRM driver with prime support (or some V4L2 output driver), I guess it would be best to have that in a PC environment. It looks like i915/radeon/nouveau drivers already have prime support.

The DRM driver could be an exporter of buffers that would be passed to the webcam driver.

And except the kernel patches we would need a test application, similar to that one:
http://git.infradead.org/users/kmpark/public-apps/blob/a7e755629a74a7ac13788
2032a0f7b2480fa1490:/v4l2-drm-example/dmabuf-sharing.c

I haven't been closely following the DMABUF APIs development, I think Tomasz could provide more details on that.

It's likely I'll get around and prepare a test case as outlined above in coming days. Anyway, it would be appreciated if someone else could give this patch series a try.

Quoted 28 lines · On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote:

Quoted 21 lines · Laurent Pinchart

Quoted 12 lines · On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote:

Quoted 5 lines · Mauro Carvalho Chehab

This one requires more testing:

May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API
http://patchwork.linuxtv.org/patch/11268 Sylwester Nawrocki
<[email protected]>

Hmm, this is not valid any more. Tomasz just posted a new patch series that adds DMABUF importer and exporter feature altogether.

[PATCHv8 00/26] Integration of videobuf2 with DMABUF

Quoted 7 lines

I guess we need someone else to submit test patches for other H/W than just Samsung SoCs. I'm not sure if we've got enough resources to port this to other hardware. We have been using these features internally for some time already. It's been 2 kernel releases and I can see only Ack tags from Laurent on Tomasz's patch series, hence it seems there is no wide interest in DMABUF support in V4L2 and this patch series is probably going to stay in a fridge for another few kernel releases.

Quoted 1 line

What would be required to push it to v3.7 ?

Mauro requested more test coverage on that, which is understood since this is a fairly important API enhancement and the V4L2 video overlay API replacement.

Quoted 4 lines

We need DMABUF support added at some webcam driver and a DRM driver with prime support (or some V4L2 output driver), I guess it would be best to have that in a PC environment. It looks like i915/radeon/nouveau drivers already have prime support.

uvcvideo has recently been moved to videobuf2, using vb2_vmalloc. I can easily test that, except that I have no idea how to export buffers on the i915 side when X is running. Have you looked into that ?

Quoted 11 lines

The DRM driver could be an exporter of buffers that would be passed to the webcam driver.

And except the kernel patches we would need a test application, similar to that one:
http://git.infradead.org/users/kmpark/public-apps/blob/a7e755629a74a7ac13788
2032a0f7b2480fa1490:/v4l2-drm-example/dmabuf-sharing.c

I haven't been closely following the DMABUF APIs development, I think Tomasz could provide more details on that.

Quoted 3 lines

It's likely I'll get around and prepare a test case as outlined above in coming days. Anyway, it would be appreciated if someone else could give this patch series a try.

I've previously tested the patches on Renesas hardware, exporting buffers on the FBDEV side and importing them on the V4L2 side. We thus have test results for two different platforms, albeit all ARM-based.

Hi Laurent,

Quoted 34 lines · Laurent Pinchart

Quoted 32 lines · On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote:

Quoted 21 lines · Laurent Pinchart

Quoted 12 lines · On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote:

Quoted 5 lines · Mauro Carvalho Chehab

This one requires more testing:

May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API
http://patchwork.linuxtv.org/patch/11268 Sylwester Nawrocki
<[email protected]>

Hmm, this is not valid any more. Tomasz just posted a new patch series that adds DMABUF importer and exporter feature altogether.

[PATCHv8 00/26] Integration of videobuf2 with DMABUF

Quoted 7 lines

I guess we need someone else to submit test patches for other H/W than just Samsung SoCs. I'm not sure if we've got enough resources to port this to other hardware. We have been using these features internally for some time already. It's been 2 kernel releases and I can see only Ack tags from Laurent on Tomasz's patch series, hence it seems there is no wide interest in DMABUF support in V4L2 and this patch series is probably going to stay in a fridge for another few kernel releases.

Quoted 1 line

What would be required to push it to v3.7 ?

Mauro requested more test coverage on that, which is understood since this is a fairly important API enhancement and the V4L2 video overlay API replacement.

We need DMABUF support added at some webcam driver and a DRM driver with prime support (or some V4L2 output driver), I guess it would be best to have that in a PC environment. It looks like i915/radeon/nouveau drivers already have prime support.

Quoted 3 lines

uvcvideo has recently been moved to videobuf2, using vb2_vmalloc. I can easily test that, except that I have no idea how to export buffers on the i915 side when X is running. Have you looked into that ?

All right. Yes, I'm also not sure yet how to do it. I tried it on a laptop with i915 driver, but in the running system drmModeGetResources() just fails with EPERM. I've CCed dri-devel, so hopefully someone can shed some light on this.

Em 17-08-2012 18:01, Sylwester Nawrocki escreveu:

Quoted 38 lines · Laurent Pinchart

Quoted 37 lines · On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote:

Quoted 35 lines · Laurent Pinchart

Quoted 24 lines · On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote:

Quoted 15 lines · Mauro Carvalho Chehab

Quoted 8 lines

This one requires more testing:

May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API

http://patchwork.linuxtv.org/patch/11268 Sylwester Nawrocki

<[email protected]>

Hmm, this is not valid any more. Tomasz just posted a new patch series that adds DMABUF importer and exporter feature altogether.

[PATCHv8 00/26] Integration of videobuf2 with DMABUF

Quoted 7 lines

I guess we need someone else to submit test patches for other H/W than just Samsung SoCs. I'm not sure if we've got enough resources to port this to other hardware. We have been using these features internally for some time already. It's been 2 kernel releases and I can see only Ack tags from Laurent on Tomasz's patch series, hence it seems there is no wide interest in DMABUF support in V4L2 and this patch series is probably going to stay in a fridge for another few kernel releases.

Quoted 1 line

What would be required to push it to v3.7 ?

Mauro requested more test coverage on that, which is understood since this is a fairly important API enhancement and the V4L2 video overlay API replacement.

We need DMABUF support added at some webcam driver and a DRM driver with prime support (or some V4L2 output driver), I guess it would be best to have that in a PC environment. It looks like i915/radeon/nouveau drivers already have prime support.

Quoted 8 lines

Quoted 3 lines

uvcvideo has recently been moved to videobuf2, using vb2_vmalloc. I can easily test that, except that I have no idea how to export buffers on the i915 side when X is running. Have you looked into that ?

All right. Yes, I'm also not sure yet how to do it. I tried it on a laptop with i915 driver, but in the running system drmModeGetResources() just fails with EPERM. I've CCed dri-devel, so hopefully someone can shed some light on this.

Likely, you need to run with root permission to use it, or to write an Xorg driver.

It is probably easier to get the V4L driver there, that uses the VIDIOC_OVERLAY stuff, and make it work via DMABUF:

	http://cgit.freedesktop.org/xorg/driver/xf86-video-v4l/

In order to test it, xawtv has already the code needed to talk with the v4l plugin.

What the plugin does is to export the video board as a XV extension, accessible via xawtv. It currently talks with the display card also via XV, but I believe it won't be hard to port it to work with DMABUF.

As the interface between xawtv and the v4l plugin is just Xv, changing the code there from VIDIOC_OVERLAY to DMABUF should be trivial.

In order to help people to know about the status of the pending patches, I'm summing-up the patches pending for merge on this email.

If is there any patch missing, please check if it is at patchwork before asking what happened:
http://patchwork.linuxtv.org/project/linux-media/list/?state=*

If patchwork didn't pick, then the emailer likely line-wrapped or corrupted the patch.

As announced, patchwork is now generating status change emails. So, those that didn't decide to opt-out emails there will receive notifications every time a patch is reviewed. Unfortunately, patchwork doesn't send emails is when a patch is stored there.

For the ones explicitly copied on this email, I kindly ask you to update me about the review status of the patches below.

In special, on my track list, there are three patches from 2011 still not reviewed. Driver maintainers: I kindly ask you to be more active on patch reviewing, not holding any patch for long periods like that, and sending pull request more often. You should only be holding patches if you have very strong reasons why this is required.

A final note: patches from driver maintainers with git trees are generally just marked as RFC. Well, I still applied several of them, when they're trivial enough and they're seem to be addressing a real bug - helping myself to not need to re-review them later.

I really expect people to add more "RFC" on patches. We're having a net commit rate of about 500-600 patches per merge window, and perhaps 3 or 4 times more patches at the ML that are just part of some discussions and aren't yet on their final version. It doesn't scale if I need to review ~3000 patches per merge window, as that would mean reviewing 75 patches per working day. Unfortunately, linux-media patch reviewing is not my full-time job. So, please help me marking those under-discussion patches as RFC, in order to allow me to focus on the 600 ones that will actually be merged.

Thank you!
Mauro

Number of pending patches per reviewer (excluding the newer ones):

  Guennadi Liakhovetski <[email protected]>                         : 17
  Manu Abraham <[email protected]>                                 : 11
  Silvester Nawrocki <[email protected]>                     : 11
  Laurent Pinchart <[email protected]>                  : 3
  Jonathan Corbet <[email protected]>                                      : 2

David Härdeman <[email protected]> : 1
Prabhakar Lad <[email protected]> : 1

		== Guennadi Liakhovetski <[email protected]> == 

Aug, 2 2012: [v3] mt9v022: Add support for mt9v024                                  http://patchwork.linuxtv.org/patch/13582  Alex Gershgorin <[email protected]>
Aug, 6 2012: [1/1] media: mx3_camera: Improve data bus width check code for probe   http://patchwork.linuxtv.org/patch/13618  Liu Ying <[email protected]>

Aug, 9 2012: [1/1, v2] media/video: vpif: fixing function name start to vpif_config http://patchwork.linuxtv.org/patch/13689 Dror Cohen <[email protected]>

Aug, 1 2012: media: soc_camera: don't clear pix->sizeimage in JPEG mode when try_fm http://patchwork.linuxtv.org/patch/13565  Albert Wang <[email protected]>
Jul,30 2012: media: mx3_camera: buf_init() add buffer state check                   http://patchwork.linuxtv.org/patch/13528  Alex Gershgorin <[email protected]>
Jul,11 2012: [v2] media: mx2_camera: Don't modify non volatile parameters in try_fm http://patchwork.linuxtv.org/patch/13310  Javier Martin <[email protected]>

Jul,11 2012: [v6] media: mx2_camera: Fix mbus format handling                       http://patchwork.linuxtv.org/patch/13314  Javier Martin <[email protected]>
Jul,12 2012: media: mx2_camera: Add YUYV output format.                             http://patchwork.linuxtv.org/patch/13330  Javier Martin <[email protected]>

Jul,12 2012: media: mx2_camera: Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MS http://patchwork.linuxtv.org/patch/13331 Javier Martin <[email protected]>

Jul,12 2012: [1/2,v2] media: Add mem2mem deinterlacing driver. http://patchwork.linuxtv.org/patch/13332 Javier Martin <[email protected]>

Jul,30 2012: mt9v022: Add support for mt9v024 http://patchwork.linuxtv.org/patch/13525 Alex Gershgorin <[email protected]>

Aug, 1 2012: [v2] media: mx2_camera: Fix clock handling for i.MX27. http://patchwork.linuxtv.org/patch/13569 Javier Martin <[email protected]>

Aug, 2 2012: [v2] mt9v022: Add support for mt9v024 http://patchwork.linuxtv.org/patch/13579 Alex Gershgorin <[email protected]>

May,25 2012: [06/15] video: mx1_camera: Use clk_prepare_enable/clk_disable_unprepar http://patchwork.linuxtv.org/patch/11505 Fabio Estevam <[email protected]> May,25 2012: [07/15] video: mx2_camera: Use clk_prepare_enable/clk_disable_unprepar http://patchwork.linuxtv.org/patch/11506 Fabio Estevam <[email protected]>

May,25 2012: [08/15] video: mx2_emmaprp: Use clk_prepare_enable/clk_disable_unprepa http://patchwork.linuxtv.org/patch/11507 Fabio Estevam <[email protected]>

Jun, 5 2012: media: mx2_camera: Add YUYV output format. http://patchwork.linuxtv.org/patch/11580 Javier Martin <[email protected]>

In order to help people to know about the status of the pending patches, I'm summing-up the patches pending for merge on this email.

Em 14-08-2012 10:04, Mauro Carvalho Chehab escreveu:

Quoted 2 lines

In order to help people to know about the status of the pending patches, I'm summing-up the patches pending for merge on this email.

Thank you all maintainers that helped me updating it!

If I didn't miss anything, the patches below are what's under review.

I applied today the reorg patches part 2. Please test. There are still some mess at drivers/media/platform. I may try to address it next week, if I have some time. Of course, people are welcome to do that, instead ;) Basically, vivi, platform and mem2mem drivers are there, maybe together with some other stuff. I think soc_camera deserves its own directory, just like other platform drivers.

The Kconfig stuff on V4L can likely be simplified: there are too many hidden options there that probably can be removed, in order to make it simpler.

Anyway, at least in my humble opinion, things are now better organized.

With regards to media-build.git tree, I updated it to properly apply the fixup patches against the new tree. I didn't updated the driver removal logic there, used during "make install".

For the driver removal logic to work at media-build, the file "obsolete.txt" needs to have the name and patches for all drivers before the reorganization. As the maximum backport is 2.6.31, I suspect that all other stuff at "obsolete.txt" just got outdated and can be removed.

Thanks,
Mauro

		== Needing more discussions/review by the LinuxTV community == 

Jun,21 2012: [media] dvb frontend core: tuning in ISDB-T using DVB API v3           http://patchwork.linuxtv.org/patch/12988  Olivier Grenie <[email protected]>
Jun,21 2012: dvb: push down ioctl lock in dvb_usercopy                              http://patchwork.linuxtv.org/patch/12989  Nikolaus Schulz <[email protected]>
Jul,26 2012: media: rc: Add support to decode Remotes using NECx IR protocol        http://patchwork.linuxtv.org/patch/13480  Ravi Kumar V <[email protected]>
Jul,31 2012: [RFC] Fix DVB ioctls failing if frontend open/closed too fast          http://patchwork.linuxtv.org/patch/13563  Juergen Lock <[email protected]>
Jan,20 2012: [RFC] dvb: Add DVBv5 properties for quality parameters                 http://patchwork.linuxtv.org/patch/9578   Mauro Carvalho Chehab <[email protected]>
Aug,13 2012: [media] dvb: frontend API: Add a flag to indicate that get_frontend()  http://patchwork.linuxtv.org/patch/13783  Mauro Carvalho Chehab <[email protected]>

		== Guennadi Liakhovetski <[email protected]> == 

Jul,12 2012: media: mx2_camera: Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MS http://patchwork.linuxtv.org/patch/13331 Javier Martin <[email protected]> May,25 2012: [08/15] video: mx2_emmaprp: Use clk_prepare_enable/clk_disable_unprepa http://patchwork.linuxtv.org/patch/11507 Fabio Estevam <[email protected]>

		== Prabhakar Lad <[email protected]> == 

Aug, 9 2012: [1/1, v2] media/video: vpif: fixing function name start to vpif_config http://patchwork.linuxtv.org/patch/13689 Dror Cohen <[email protected]>

		== Jonathan Corbet <[email protected]> == 

Apr,26 2012: [2/2] marvell-cam: Build fix: missing "select VIDEOBUF2_VMALLOC"       http://patchwork.linuxtv.org/patch/10848  Chris Ball <[email protected]>
Aug,13 2012: [2/2] marvell-cam: Build fix: missing "select VIDEOBUF2_VMALLOC"       http://patchwork.linuxtv.org/patch/13784  Mauro Carvalho Chehab <[email protected]>

		== Manu Abraham <[email protected]> == 

May,25 2011: Add remote control support for mantis                                                                            Christoph Pinkl <[email protected]>
Jun, 8 2011: Add remote control support for mantis                                  http://patchwork.linuxtv.org/patch/7217   Christoph Pinkl <[email protected]>
Nov,29 2011: stv090x: implement function for reading uncorrected blocks count       http://patchwork.linuxtv.org/patch/8656   Mariusz Bia?o?czyk <[email protected]>
Mar,11 2012: [2/3] stv090x: use error counter 1 for BER estimation                  http://patchwork.linuxtv.org/patch/10301  Andreas Regel <[email protected]>
Mar,11 2012: [3/3] stv090x: On STV0903 do not set registers of the second path.     http://patchwork.linuxtv.org/patch/10302  Andreas Regel <[email protected]>
Apr, 1 2012: [05/11] Slightly more friendly debugging output.                       http://patchwork.linuxtv.org/patch/10520  "Steinar H. Gunderson" <[email protected]>
Apr, 1 2012: [06/11] Replace ca_lock by a slightly more general int_stat_lock.      http://patchwork.linuxtv.org/patch/10521  "Steinar H. Gunderson" <[email protected]>
Apr, 1 2012: [07/11] Fix a ton of SMP-unsafe accesses.                              http://patchwork.linuxtv.org/patch/10523  "Steinar H. Gunderson" <[email protected]>
Apr, 1 2012: [11/11] Enable Mantis CA support.                                      http://patchwork.linuxtv.org/patch/10524  "Steinar H. Gunderson" <[email protected]>
Apr, 1 2012: [08/11] Remove some unused structure members.                          http://patchwork.linuxtv.org/patch/10525  "Steinar H. Gunderson" <[email protected]>
Apr, 1 2012: [09/11] Correct wait_event_timeout error return check.                 http://patchwork.linuxtv.org/patch/10526  "Steinar H. Gunderson" <[email protected]>
Apr, 1 2012: [10/11] Ignore timeouts waiting for the IRQ0 flag.                     http://patchwork.linuxtv.org/patch/10527  "Steinar H. Gunderson" <[email protected]>

		== David Härdeman <[email protected]> == 

Jul,31 2012: [media] winbond-cir: Fix initialization http://patchwork.linuxtv.org/patch/13539 Sean Young <[email protected]>

		== Waiting for Malcolm Priestley <[email protected]> split tuner/demod new patches == 

May, 8 2012: [1/2] TeVii DVB-S s421 and s632 cards support                          http://patchwork.linuxtv.org/patch/11103  Igor M. Liplianin <[email protected]>
May, 8 2012: [2/2] TeVii DVB-S s421 and s632 cards support, rs2000 part             http://patchwork.linuxtv.org/patch/11104  Igor M. Liplianin <[email protected]>

Number of pending patches per reviewer:

  Manu Abraham <[email protected]>                                 : 12
  LinuxTV community                                                     : 6
  Malcolm Priestley <[email protected]>                                : 2
  Jonathan Corbet <[email protected]>                                      : 2
  Guennadi Liakhovetski <[email protected]>                         : 2

David Härdeman <[email protected]> : 1
Prabhakar Lad <[email protected]> : 1

Cheers,
Mauro