* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-14 13:04 Patches submitted via linux-media ML that are at patchwork.linuxtv.org Mauro Carvalho Chehab
@ 2012-08-14 13:36 ` Prabhakar Lad
2012-08-14 14:02 ` Mauro Carvalho Chehab
2012-08-14 13:46 ` Hans Verkuil
` (5 subsequent siblings)
6 siblings, 1 reply; 25+ messages in thread
From: Prabhakar Lad @ 2012-08-14 13:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: LMML
Hi Mauro,
On Tuesday 14 August 2012 06:34 PM, Mauro Carvalho Chehab wrote:
> 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.
>
[Snip]
> == Laurent Pinchart <laurent.pinchart@ideasonboard.com> ==
>
> Sep,27 2011: [v2,1/5] omap3evm: Enable regulators for camera interface http://patchwork.linuxtv.org/patch/7969 Vaibhav Hiremath <hvaibhav@ti.com>
> Jul,26 2012: [1/2,media] omap3isp: implement ENUM_FMT http://patchwork.linuxtv.org/patch/13492 Michael Jones <michael.jones@matrix-vision.de>
> Jul,26 2012: [2/2,media] omap3isp: support G_FMT http://patchwork.linuxtv.org/patch/13493 Michael Jones <michael.jones@matrix-vision.de>
>
> == Prabhakar Lad <prabhakar.lad@ti.com> ==
>
> Aug, 2 2012: [1/1] media/video: vpif: fixing function name start to vpif_config_par http://patchwork.linuxtv.org/patch/13576 Dror Cohen <dror@liveu.tv>
>
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.
Thx,
--Prabhakar
> == Silvester Nawrocki <sylvester.nawrocki@gmail.com> ==
>
> Aug, 2 2012: [PATH,v3,1/2] v4l: Add factory register values form S5K4ECGX sensor http://patchwork.linuxtv.org/patch/13580 Sangwook Lee <sangwook.lee@linaro.org>
> Aug, 2 2012: [PATH,v3,2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor http://patchwork.linuxtv.org/patch/13581 Sangwook Lee <sangwook.lee@linaro.org>
> 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 <sachin.kamat@linaro.org>
> Aug,10 2012: [2/2,media] s5p-tv: Use devm_* functions in sii9234_drv.c file http://patchwork.linuxtv.org/patch/13720 Sachin Kamat <sachin.kamat@linaro.org>
> Aug,10 2012: [RESEND] v4l/s5p-mfc: added support for end of stream handling in MFC http://patchwork.linuxtv.org/patch/13721 Andrzej Hajda <a.hajda@samsung.com>
> Aug,10 2012: [v4,1/2] v4l: Add factory register values form S5K4ECGX sensor http://patchwork.linuxtv.org/patch/13727 Sangwook Lee <sangwook.lee@linaro.org>
> Aug,10 2012: [v4,2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor http://patchwork.linuxtv.org/patch/13728 Sangwook Lee <sangwook.lee@linaro.org>
> Jun,11 2012: [1/3,media] s5p-tv: Replace printk with pr_* functions http://patchwork.linuxtv.org/patch/11666 Sachin Kamat <sachin.kamat@linaro.org>
> Jun,11 2012: [2/3,media] s5p-mfc: Replace printk with pr_* functions http://patchwork.linuxtv.org/patch/11667 Sachin Kamat <sachin.kamat@linaro.org>
> Jun,11 2012: [3/3,media] s5p-fimc: Replace printk with pr_* functions http://patchwork.linuxtv.org/patch/11668 Sachin Kamat <sachin.kamat@linaro.org>
> Jun,12 2012: [1/1, media] s5p-fimc: Replace custom err() macro with v4l2_err() macr http://patchwork.linuxtv.org/patch/11675 Sachin Kamat <sachin.kamat@linaro.org>
>
> == Jonathan Corbet <corbet@lwn.net> ==
>
> Apr,26 2012: [2/2] marvell-cam: Build fix: missing "select VIDEOBUF2_VMALLOC" http://patchwork.linuxtv.org/patch/10848 Chris Ball <cjb@laptop.org>
>
> 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 <mchehab@redhat.com>
>
> == Manu Abraham <abraham.manu@gmail.com> ==
>
> Jun, 8 2011: Add remote control support for mantis http://patchwork.linuxtv.org/patch/7217 Christoph Pinkl <christoph.pinkl@gmail.com>
> Nov,29 2011: stv090x: implement function for reading uncorrected blocks count http://patchwork.linuxtv.org/patch/8656 Mariusz Bia?o?czyk <manio@skyboo.net>
> Mar,11 2012: [2/3] stv090x: use error counter 1 for BER estimation http://patchwork.linuxtv.org/patch/10301 Andreas Regel <andreas.regel@gmx.de>
> Mar,11 2012: [3/3] stv090x: On STV0903 do not set registers of the second path. http://patchwork.linuxtv.org/patch/10302 Andreas Regel <andreas.regel@gmx.de>
> Apr, 1 2012: [05/11] Slightly more friendly debugging output. http://patchwork.linuxtv.org/patch/10520 "Steinar H. Gunderson" <sesse@samfundet.no>
> 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" <sesse@samfundet.no>
> Apr, 1 2012: [07/11] Fix a ton of SMP-unsafe accesses. http://patchwork.linuxtv.org/patch/10523 "Steinar H. Gunderson" <sesse@samfundet.no>
> Apr, 1 2012: [11/11] Enable Mantis CA support. http://patchwork.linuxtv.org/patch/10524 "Steinar H. Gunderson" <sesse@samfundet.no>
> Apr, 1 2012: [08/11] Remove some unused structure members. http://patchwork.linuxtv.org/patch/10525 "Steinar H. Gunderson" <sesse@samfundet.no>
> Apr, 1 2012: [09/11] Correct wait_event_timeout error return check. http://patchwork.linuxtv.org/patch/10526 "Steinar H. Gunderson" <sesse@samfundet.no>
> Apr, 1 2012: [10/11] Ignore timeouts waiting for the IRQ0 flag. http://patchwork.linuxtv.org/patch/10527 "Steinar H. Gunderson" <sesse@samfundet.no>
>
> == David Härdeman <david@hardeman.nu> ==
>
> Jul,31 2012: [media] winbond-cir: Fix initialization http://patchwork.linuxtv.org/patch/13539 Sean Young <sean@mess.org>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-14 13:04 Patches submitted via linux-media ML that are at patchwork.linuxtv.org Mauro Carvalho Chehab
2012-08-14 13:36 ` Prabhakar Lad
@ 2012-08-14 13:46 ` Hans Verkuil
2012-08-14 14:28 ` Mauro Carvalho Chehab
2012-08-14 15:10 ` Sylwester Nawrocki
` (4 subsequent siblings)
6 siblings, 1 reply; 25+ messages in thread
From: Hans Verkuil @ 2012-08-14 13:46 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: LMML, Manu Abraham, David Härdeman, Silvester Nawrocki,
Laurent Pinchart, Jonathan Corbet, Guennadi Liakhovetski,
Prabhakar Lad
On Tue August 14 2012 15:04:17 Mauro Carvalho Chehab wrote:
> 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.
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.
> 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.
> == Silvester Nawrocki <sylvester.nawrocki@gmail.com> ==
>
> Aug, 2 2012: [PATH,v3,1/2] v4l: Add factory register values form S5K4ECGX sensor http://patchwork.linuxtv.org/patch/13580 Sangwook Lee <sangwook.lee@linaro.org>
> Aug, 2 2012: [PATH,v3,2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor http://patchwork.linuxtv.org/patch/13581 Sangwook Lee <sangwook.lee@linaro.org>
> 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 <sachin.kamat@linaro.org>
> Aug,10 2012: [2/2,media] s5p-tv: Use devm_* functions in sii9234_drv.c file http://patchwork.linuxtv.org/patch/13720 Sachin Kamat <sachin.kamat@linaro.org>
> Aug,10 2012: [RESEND] v4l/s5p-mfc: added support for end of stream handling in MFC http://patchwork.linuxtv.org/patch/13721 Andrzej Hajda <a.hajda@samsung.com>
> Aug,10 2012: [v4,1/2] v4l: Add factory register values form S5K4ECGX sensor http://patchwork.linuxtv.org/patch/13727 Sangwook Lee <sangwook.lee@linaro.org>
> Aug,10 2012: [v4,2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor http://patchwork.linuxtv.org/patch/13728 Sangwook Lee <sangwook.lee@linaro.org>
> Jun,11 2012: [1/3,media] s5p-tv: Replace printk with pr_* functions http://patchwork.linuxtv.org/patch/11666 Sachin Kamat <sachin.kamat@linaro.org>
> Jun,11 2012: [2/3,media] s5p-mfc: Replace printk with pr_* functions http://patchwork.linuxtv.org/patch/11667 Sachin Kamat <sachin.kamat@linaro.org>
> Jun,11 2012: [3/3,media] s5p-fimc: Replace printk with pr_* functions http://patchwork.linuxtv.org/patch/11668 Sachin Kamat <sachin.kamat@linaro.org>
> Jun,12 2012: [1/1, media] s5p-fimc: Replace custom err() macro with v4l2_err() macr http://patchwork.linuxtv.org/patch/11675 Sachin Kamat <sachin.kamat@linaro.org>
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.
Regards,
Hans
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-14 13:46 ` Hans Verkuil
@ 2012-08-14 14:28 ` Mauro Carvalho Chehab
2012-08-14 15:21 ` Laurent Pinchart
2012-08-15 9:54 ` Hans Verkuil
0 siblings, 2 replies; 25+ messages in thread
From: Mauro Carvalho Chehab @ 2012-08-14 14:28 UTC (permalink / raw)
To: Hans Verkuil
Cc: LMML, Manu Abraham, David Härdeman, Silvester Nawrocki,
Laurent Pinchart, Jonathan Corbet, Guennadi Liakhovetski,
Prabhakar Lad
Em 14-08-2012 10:46, Hans Verkuil escreveu:
> On Tue August 14 2012 15:04:17 Mauro Carvalho Chehab wrote:
>> 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.
> 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.
> 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.
>> 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.
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.
> 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.
> 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.
Regards,
Mauro
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-14 14:28 ` Mauro Carvalho Chehab
@ 2012-08-14 15:21 ` Laurent Pinchart
2012-08-15 7:33 ` Michael Jones
2012-08-15 9:54 ` Hans Verkuil
1 sibling, 1 reply; 25+ messages in thread
From: Laurent Pinchart @ 2012-08-14 15:21 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Hans Verkuil, LMML, Manu Abraham, David Härdeman,
Silvester Nawrocki, Jonathan Corbet, Guennadi Liakhovetski,
Prabhakar Lad
Hi Mauro,
On Tuesday 14 August 2012 11:28:05 Mauro Carvalho Chehab wrote:
> Em 14-08-2012 10:46, Hans Verkuil escreveu:
> > On Tue August 14 2012 15:04:17 Mauro Carvalho Chehab wrote:
> >> 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.
>
> > 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.
>
> > 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.
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.
> >> 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.
>
> 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.
>
> > 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.
>
> > 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.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-14 15:21 ` Laurent Pinchart
@ 2012-08-15 7:33 ` Michael Jones
2012-08-15 19:24 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 25+ messages in thread
From: Michael Jones @ 2012-08-15 7:33 UTC (permalink / raw)
To: LMML
Cc: Laurent Pinchart, Mauro Carvalho Chehab, Hans Verkuil,
Manu Abraham, David Härdeman, Silvester Nawrocki,
Jonathan Corbet, Guennadi Liakhovetski, Prabhakar Lad
On 08/14/2012 05:21 PM, Laurent Pinchart wrote:
> Hi Mauro,
>
> 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.
>>
>>> 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.
>
> 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.
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.
-Michael
[1] http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-15 7:33 ` Michael Jones
@ 2012-08-15 19:24 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 25+ messages in thread
From: Mauro Carvalho Chehab @ 2012-08-15 19:24 UTC (permalink / raw)
To: Michael Jones
Cc: LMML, Laurent Pinchart, Hans Verkuil, Manu Abraham,
David Härdeman, Silvester Nawrocki, Jonathan Corbet,
Guennadi Liakhovetski, Prabhakar Lad
Em 15-08-2012 04:33, Michael Jones escreveu:
> On 08/14/2012 05:21 PM, Laurent Pinchart wrote:
>> Hi Mauro,
>>
>> 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.
>>>
>>>> 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.
>>
>> 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.
>
> 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.
Patches for "not-so-frequent" contributors aren't the problem. There are lots of
them, but they usually don't take long time on reviews: almost all are trivial ones,
as there are just a few new driver additions.
On the latter case, it easier to check if someone else already asked the new developer
to fix trivial things (it happens that new contributors are not aware of some things).
If nobody comments, I'll need to review it anyway. So, that's fine.
The big issue happens with drivers that suffer lots of reviews until they go upstream:
there are patches that took almost 20 versions for the developers with that hardware
to agree around a solution. The differences between each version are typically
due to some driver internals, that only the ones with the actual device can review.
The new versions are typically on new email threads. Even if they were at the same
thread, patchwork unfortunately is not able to detect that a new version superseded
the previous patch series.
So, your poor maintainer needs to dig into all those drafts, in order to pick the
right stuff in the middle of them. It is like extracting gold from a coal mine.
On the other hand, it makes perfect sense that those patches should be discussed
at the ML before being ready for pushing.
So, I need help from the ones that work with those stuff, in order to allow me to
fast track what should be just marked as RFC without needing to dig into the
entire patch pile.
Regards,
Mauro
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-14 14:28 ` Mauro Carvalho Chehab
2012-08-14 15:21 ` Laurent Pinchart
@ 2012-08-15 9:54 ` Hans Verkuil
2012-08-15 10:13 ` Guennadi Liakhovetski
2012-08-15 19:34 ` Mauro Carvalho Chehab
1 sibling, 2 replies; 25+ messages in thread
From: Hans Verkuil @ 2012-08-15 9:54 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: LMML, Manu Abraham, David Härdeman, Silvester Nawrocki,
Laurent Pinchart, Jonathan Corbet, Guennadi Liakhovetski,
Prabhakar Lad
On Tue August 14 2012 16:28:05 Mauro Carvalho Chehab wrote:
> Em 14-08-2012 10:46, Hans Verkuil escreveu:
> > On Tue August 14 2012 15:04:17 Mauro Carvalho Chehab wrote:
>
> >> 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.
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.
> > 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.
>
> > 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.
I think that's overkill.
> >> 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.
>
> 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.
>
> > 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.
>
> > 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.
It's too bad patchwork doesn't support a way where the submitter can kill a
wrong patch. That would be very useful.
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-15 9:54 ` Hans Verkuil
@ 2012-08-15 10:13 ` Guennadi Liakhovetski
2012-08-15 19:34 ` Mauro Carvalho Chehab
1 sibling, 0 replies; 25+ messages in thread
From: Guennadi Liakhovetski @ 2012-08-15 10:13 UTC (permalink / raw)
To: Hans Verkuil
Cc: Mauro Carvalho Chehab, LMML, Manu Abraham, David Härdeman,
Silvester Nawrocki, Laurent Pinchart, Jonathan Corbet,
Prabhakar Lad
On Wed, 15 Aug 2012, Hans Verkuil wrote:
> On Tue August 14 2012 16:28:05 Mauro Carvalho Chehab wrote:
> > Em 14-08-2012 10:46, Hans Verkuil escreveu:
> > > On Tue August 14 2012 15:04:17 Mauro Carvalho Chehab wrote:
> >
> > >> 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.
>
> 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.
I think it goes in line with the common practice:
1. _ALL_ patches have to be posted to mailing lists before appearing in
any trees to be pushed to Linus. This includes any patches from
maintainers, something I was asking about for some time now - no ML
bypassing please! This also means, that you, Mauro, don't have to apply
any such patches from maintainers with trees, which is exactly what you're
doing with your RFC attribution.
2. All patches, lying in (sub)maintainer's competence area, have to be
pushed via their trees, not expecting the upstream maintainer to pick them
up from patches. This is also what Mauro is imposing now. This is a bit
less strict, than (1), I think, there can be exceptions, when a single
patch has to go urgently upstream and the respective (sub)maintainer
doesn't have an easy way to produce a pull request (e.g., traveling), in
which case (s)he can just post a patch or, equally, ack someone else's
patch and ask the upstream maintainer explicitly to apply that patch as an
exception without waiting for a pull request.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-15 9:54 ` Hans Verkuil
2012-08-15 10:13 ` Guennadi Liakhovetski
@ 2012-08-15 19:34 ` Mauro Carvalho Chehab
1 sibling, 0 replies; 25+ messages in thread
From: Mauro Carvalho Chehab @ 2012-08-15 19:34 UTC (permalink / raw)
To: Hans Verkuil
Cc: LMML, Manu Abraham, David Härdeman, Silvester Nawrocki,
Laurent Pinchart, Jonathan Corbet, Guennadi Liakhovetski,
Prabhakar Lad
Em 15-08-2012 06:54, Hans Verkuil escreveu:
> On Tue August 14 2012 16:28:05 Mauro Carvalho Chehab wrote:
>> Em 14-08-2012 10:46, Hans Verkuil escreveu:
>>> 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.
Yes. If patchwork had such support, patch senders could also be marking a patch
as superseded or as RFC.
I don't know enough about patchwork to write such addition into it.
>> 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.
[PATCH TRIVIAL] is something that makes sense on those cases, and it is pretty
used on other trees.
> 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.
True. I try to follow those patches at the ML when time allows me to do it,
and I'm just not so over-bloated with a huge patch backlog. FYI, on the last 2
days, ~60 new patches arriving and are waiting for my review. That's because
it is not close to the end of a merge window, when the volume of patch goes as
high as the sky.
> 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.
OK.
>
> 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-14 13:04 Patches submitted via linux-media ML that are at patchwork.linuxtv.org Mauro Carvalho Chehab
2012-08-14 13:36 ` Prabhakar Lad
2012-08-14 13:46 ` Hans Verkuil
@ 2012-08-14 15:10 ` Sylwester Nawrocki
2012-08-14 15:18 ` Sylwester Nawrocki
2012-08-14 15:16 ` Laurent Pinchart
` (3 subsequent siblings)
6 siblings, 1 reply; 25+ messages in thread
From: Sylwester Nawrocki @ 2012-08-14 15:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: LMML, Manu Abraham, David Härdeman, Silvester Nawrocki,
Laurent Pinchart, Jonathan Corbet, Guennadi Liakhovetski,
Prabhakar Lad, Sangwook Lee, Andrzej Hajda
Hi Mauro,
On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote:
> == Silvester Nawrocki <sylvester.nawrocki@gmail.com> ==
>
> Aug, 2 2012: [PATH,v3,1/2] v4l: Add factory register values form S5K4ECGX sensor http://patchwork.linuxtv.org/patch/13580 Sangwook Lee <sangwook.lee@linaro.org>
> Aug, 2 2012: [PATH,v3,2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor http://patchwork.linuxtv.org/patch/13581 Sangwook Lee <sangwook.lee@linaro.org>
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" ?
> 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 <sachin.kamat@linaro.org>
> Aug,10 2012: [2/2,media] s5p-tv: Use devm_* functions in sii9234_drv.c file http://patchwork.linuxtv.org/patch/13720 Sachin Kamat <sachin.kamat@linaro.org>
I've picked these two and will send a pull request shortly.
> Aug,10 2012: [RESEND] v4l/s5p-mfc: added support for end of stream handling in MFC http://patchwork.linuxtv.org/patch/13721 Andrzej Hajda <a.hajda@samsung.com>
There is some problem with that one on top of latest kernel tree:
drivers/media/video/s5p-mfc/s5p_mfc_enc.c: In function ‘vidioc_subscribe_event’:
drivers/media/video/s5p-mfc/s5p_mfc_enc.c:1536: error: too few arguments to
function ‘v4l2_event_subscribe’
make[4]: *** [drivers/media/video/s5p-mfc/s5p_mfc_enc.o] Error 1
make[3]: *** [drivers/media/video/s5p-mfc] Error 2
make[2]: *** [drivers/media/video] Error 2
make[2]: *** Waiting for unfinished jobs....
I'll ask Andrzej to see what's going on. This patch needs to be adapted now
to some recent changes at v4l2-core.
> Aug,10 2012: [v4,1/2] v4l: Add factory register values form S5K4ECGX sensor http://patchwork.linuxtv.org/patch/13727 Sangwook Lee <sangwook.lee@linaro.org>
Under review, can be marked as RFC (see comments on v3).
> Aug,10 2012: [v4,2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor http://patchwork.linuxtv.org/patch/13728 Sangwook Lee <sangwook.lee@linaro.org>
Ditto.
> Jun,11 2012: [1/3,media] s5p-tv: Replace printk with pr_* functions http://patchwork.linuxtv.org/patch/11666 Sachin Kamat <sachin.kamat@linaro.org>
I've added it to my pull request to follow.
> Jun,11 2012: [2/3,media] s5p-mfc: Replace printk with pr_* functions http://patchwork.linuxtv.org/patch/11667 Sachin Kamat <sachin.kamat@linaro.org>
There were changes requested by Kamil Debski on this patch, which still
seem not addressed.
> Jun,11 2012: [3/3,media] s5p-fimc: Replace printk with pr_* functions http://patchwork.linuxtv.org/patch/11668 Sachin Kamat <sachin.kamat@linaro.org>
This patch is superseded by this one [1] already merged.
> Jun,12 2012: [1/1, media] s5p-fimc: Replace custom err() macro with v4l2_err() macr http://patchwork.linuxtv.org/patch/11675 Sachin Kamat <sachin.kamat@linaro.org>
This one is already applied [1].
[1]
http://git.linuxtv.org/media_tree.git/commitdiff/a516d08fa6afb703ba508ccc55656d037c5b9e2e
--
Regards,
Sylwester
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-14 15:10 ` Sylwester Nawrocki
@ 2012-08-14 15:18 ` Sylwester Nawrocki
0 siblings, 0 replies; 25+ messages in thread
From: Sylwester Nawrocki @ 2012-08-14 15:18 UTC (permalink / raw)
To: Sangwook Lee; +Cc: Mauro Carvalho Chehab, LMML
On 08/14/2012 05:10 PM, Sylwester Nawrocki wrote:
> On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote:
>> == Silvester Nawrocki <sylvester.nawrocki@gmail.com> ==
>>
>> Aug, 2 2012: [PATH,v3,1/2] v4l: Add factory register values form S5K4ECGX sensor http://patchwork.linuxtv.org/patch/13580 Sangwook Lee <sangwook.lee@linaro.org>
>> Aug, 2 2012: [PATH,v3,2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor http://patchwork.linuxtv.org/patch/13581 Sangwook Lee <sangwook.lee@linaro.org>
>
> 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" ?
^^^^^^^
oops, sorry, of course it's supposed to be "RFC PATCH".
Thanks,
Sylwester
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-14 13:04 Patches submitted via linux-media ML that are at patchwork.linuxtv.org Mauro Carvalho Chehab
` (2 preceding siblings ...)
2012-08-14 15:10 ` Sylwester Nawrocki
@ 2012-08-14 15:16 ` Laurent Pinchart
2012-08-15 21:43 ` Mauro Carvalho Chehab
2012-08-14 16:37 ` Sylwester Nawrocki
` (2 subsequent siblings)
6 siblings, 1 reply; 25+ messages in thread
From: Laurent Pinchart @ 2012-08-14 15:16 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: LMML, Manu Abraham, David Härdeman, Silvester Nawrocki,
Jonathan Corbet, Guennadi Liakhovetski, Prabhakar Lad
Hi Mauro,
On Tuesday 14 August 2012 10:04:17 Mauro Carvalho Chehab wrote:
> 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 <g.liakhovetski@gmx.de> : 17
> Manu Abraham <abraham.manu@gmail.com> : 11
> Silvester Nawrocki <sylvester.nawrocki@gmail.com> : 11
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> : 3
> Jonathan Corbet <corbet@lwn.net> : 2
> David Härdeman <david@hardeman.nu> : 1
> Prabhakar Lad <prabhakar.lad@ti.com> : 1
>
>
> == Patches waiting for some action ==
[snip]
> 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 <s.nawrocki@samsung.com>
What is needed here, can I help with testing ?
[snip]
> == Guennadi Liakhovetski <g.liakhovetski@gmx.de> ==
>
> Aug, 2 2012: [v3] mt9v022: Add support for mt9v024
> http://patchwork.linuxtv.org/patch/13582
> Alex Gershgorin <alexg@meprolight.com>
> Aug, 6 2012: [1/1] media: mx3_camera: Improve data bus width check code for
> probe
> http://patchwork.linuxtv.org/patch/13618
> Liu Ying <Ying.liu@freescale.com>
> Aug, 9 2012: [1/1, v2] media/video: vpif: fixing function name start to
> vpif_config
> http://patchwork.linuxtv.org/patch/13689
> Dror Cohen <dror@liveu.tv>
I think this one has been misclassified. v1 was correctly attributed to
Prabhakar Lad <prabhakar.lad@ti.com>
[snip]
> == Laurent Pinchart <laurent.pinchart@ideasonboard.com> ==
>
> Sep,27 2011: [v2,1/5] omap3evm: Enable regulators for camera interface
> http://patchwork.linuxtv.org/patch/7969
> Vaibhav Hiremath <hvaibhav@ti.com>
I'm fine with that one, shouldn't it go through the arm tree ?
> Jul,26 2012: [1/2,media] omap3isp: implement ENUM_FMT
> http://patchwork.linuxtv.org/patch/13492
> Michael Jones <michael.jones@matrix-vision.de>
> Jul,26 2012: [2/2,media] omap3isp: support G_FMT
> http://patchwork.linuxtv.org/patch/13493
> Michael Jones <michael.jones@matrix-vision.de>
A proper solution for this will first require CREATE_BUFS/PREPARE_BUF support
in the OMAP3 ISP driver (and a move to videobuf2).
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-14 15:16 ` Laurent Pinchart
@ 2012-08-15 21:43 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 25+ messages in thread
From: Mauro Carvalho Chehab @ 2012-08-15 21:43 UTC (permalink / raw)
To: Laurent Pinchart
Cc: LMML, Manu Abraham, David Härdeman, Silvester Nawrocki,
Jonathan Corbet, Guennadi Liakhovetski, Prabhakar Lad,
Michael Jones
Em 14-08-2012 12:16, Laurent Pinchart escreveu:
>> May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API
>> http://patchwork.linuxtv.org/patch/11268
>> Sylwester Nawrocki <s.nawrocki@samsung.com>
>
> What is needed here, can I help with testing ?
Testing, as Sylwester answered. Yeah, any help with those are welcome.
I had some discussions with Sylwester today. Let's see if he can help
setting a test environment for it.
>
> [snip]
>
>> == Guennadi Liakhovetski <g.liakhovetski@gmx.de> ==
>>
>> Aug, 2 2012: [v3] mt9v022: Add support for mt9v024
>> http://patchwork.linuxtv.org/patch/13582
>> Alex Gershgorin <alexg@meprolight.com>
>> Aug, 6 2012: [1/1] media: mx3_camera: Improve data bus width check code for
>> probe
>> http://patchwork.linuxtv.org/patch/13618
>> Liu Ying <Ying.liu@freescale.com>
>> Aug, 9 2012: [1/1, v2] media/video: vpif: fixing function name start to
>> vpif_config
>> http://patchwork.linuxtv.org/patch/13689
>> Dror Cohen <dror@liveu.tv>
>
> I think this one has been misclassified. v1 was correctly attributed to
> Prabhakar Lad <prabhakar.lad@ti.com>
Ok, changed on my internal control.
>
> [snip]
>
>> == Laurent Pinchart <laurent.pinchart@ideasonboard.com> ==
>>
>> Sep,27 2011: [v2,1/5] omap3evm: Enable regulators for camera interface
>> http://patchwork.linuxtv.org/patch/7969
>> Vaibhav Hiremath <hvaibhav@ti.com>
>
> I'm fine with that one, shouldn't it go through the arm tree ?
Ah, yes. Dropped from my queue.
>> Jul,26 2012: [1/2,media] omap3isp: implement ENUM_FMT
>> http://patchwork.linuxtv.org/patch/13492
>> Michael Jones <michael.jones@matrix-vision.de>
>> Jul,26 2012: [2/2,media] omap3isp: support G_FMT
>> http://patchwork.linuxtv.org/patch/13493
>> Michael Jones <michael.jones@matrix-vision.de>
>
> A proper solution for this will first require CREATE_BUFS/PREPARE_BUF support
> in the OMAP3 ISP driver (and a move to videobuf2).
Marked as "changes requested".
Michael Jones c/c, to let him know.
Regards,
Mauro
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-14 13:04 Patches submitted via linux-media ML that are at patchwork.linuxtv.org Mauro Carvalho Chehab
` (3 preceding siblings ...)
2012-08-14 15:16 ` Laurent Pinchart
@ 2012-08-14 16:37 ` Sylwester Nawrocki
2012-08-14 22:06 ` Laurent Pinchart
2012-08-15 8:30 ` Patches submitted via linux-media ML that are at patchwork.linuxtv.org Guennadi Liakhovetski
2012-08-15 23:46 ` Mauro Carvalho Chehab
6 siblings, 1 reply; 25+ messages in thread
From: Sylwester Nawrocki @ 2012-08-14 16:37 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: LMML, Manu Abraham, David Härdeman, Laurent Pinchart,
Jonathan Corbet, Guennadi Liakhovetski, Prabhakar Lad
On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote:
> 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 <s.nawrocki@samsung.com>
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.
--
Regards,
Sylwester
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-14 16:37 ` Sylwester Nawrocki
@ 2012-08-14 22:06 ` Laurent Pinchart
2012-08-15 16:13 ` Sylwester Nawrocki
0 siblings, 1 reply; 25+ messages in thread
From: Laurent Pinchart @ 2012-08-14 22:06 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: Mauro Carvalho Chehab, LMML, Manu Abraham, David Härdeman,
Jonathan Corbet, Guennadi Liakhovetski, Prabhakar Lad
Hi Sylwester,
On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote:
> On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote:
> > 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
> > <s.nawrocki@samsung.com>
> 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.
What would be required to push it to v3.7 ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-14 22:06 ` Laurent Pinchart
@ 2012-08-15 16:13 ` Sylwester Nawrocki
2012-08-15 21:09 ` Laurent Pinchart
0 siblings, 1 reply; 25+ messages in thread
From: Sylwester Nawrocki @ 2012-08-15 16:13 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Sylwester Nawrocki, Mauro Carvalho Chehab, LMML, Manu Abraham,
David Härdeman, Jonathan Corbet, Guennadi Liakhovetski,
Prabhakar Lad, Tomasz Stanislawski
Hi Laurent,
On 08/15/2012 12:06 AM, Laurent Pinchart wrote:
> Hi Sylwester,
>
> On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote:
>> On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote:
>>> 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
>>> <s.nawrocki@samsung.com>
>> 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.
>
> 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/a7e755629a74a7ac137882032a0f7b2480fa1490:/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.
--
Regards,
Sylwester
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-15 16:13 ` Sylwester Nawrocki
@ 2012-08-15 21:09 ` Laurent Pinchart
2012-08-17 21:01 ` DRM/V4L2 buffer sharing (was: Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org) Sylwester Nawrocki
0 siblings, 1 reply; 25+ messages in thread
From: Laurent Pinchart @ 2012-08-15 21:09 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: Sylwester Nawrocki, Mauro Carvalho Chehab, LMML, Manu Abraham,
David Härdeman, Jonathan Corbet, Guennadi Liakhovetski,
Prabhakar Lad, Tomasz Stanislawski
Hi Sylwester,
On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote:
> On 08/15/2012 12:06 AM, Laurent Pinchart wrote:
> > On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote:
> >> On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote:
> >>> 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
> >>> <s.nawrocki@samsung.com>
> >>
> >> 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.
> >
> > 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.
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 ?
> 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.
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.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 25+ messages in thread
* DRM/V4L2 buffer sharing (was: Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org)
2012-08-15 21:09 ` Laurent Pinchart
@ 2012-08-17 21:01 ` Sylwester Nawrocki
2012-08-17 22:03 ` DRM/V4L2 buffer sharing Mauro Carvalho Chehab
0 siblings, 1 reply; 25+ messages in thread
From: Sylwester Nawrocki @ 2012-08-17 21:01 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Sylwester Nawrocki, Mauro Carvalho Chehab, LMML, Manu Abraham,
David Härdeman, Jonathan Corbet, Guennadi Liakhovetski,
Prabhakar Lad, Tomasz Stanislawski,
dri-devel@lists.freedesktop.org
Hi Laurent,
On 08/15/2012 11:09 PM, Laurent Pinchart wrote:
> On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote:
>> On 08/15/2012 12:06 AM, Laurent Pinchart wrote:
>>> On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote:
>>>> On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote:
>>>>> 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
>>>>> <s.nawrocki@samsung.com>
>>>>
>>>> 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.
>>>
>>> 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.
>
> 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.
>> 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.
>
> 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.
I guess ARM is where those APIs will be used mostly, still it would be helpful
to have easier reproducible test environment.
--
Thanks,
Sylwester
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: DRM/V4L2 buffer sharing
2012-08-17 21:01 ` DRM/V4L2 buffer sharing (was: Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org) Sylwester Nawrocki
@ 2012-08-17 22:03 ` Mauro Carvalho Chehab
2012-08-17 22:54 ` Laurent Pinchart
0 siblings, 1 reply; 25+ messages in thread
From: Mauro Carvalho Chehab @ 2012-08-17 22:03 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: Laurent Pinchart, Sylwester Nawrocki, LMML, Manu Abraham,
David Härdeman, Jonathan Corbet, Guennadi Liakhovetski,
Prabhakar Lad, Tomasz Stanislawski,
dri-devel@lists.freedesktop.org
Em 17-08-2012 18:01, Sylwester Nawrocki escreveu:
> Hi Laurent,
>
> On 08/15/2012 11:09 PM, Laurent Pinchart wrote:
>> On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote:
>>> On 08/15/2012 12:06 AM, Laurent Pinchart wrote:
>>>> On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote:
>>>>> On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote:
>>>>>> 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
>>>>>> <s.nawrocki@samsung.com>
>>>>>
>>>>> 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.
>>>>
>>>> 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.
>>
>> 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.
Regards,
Mauro
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: DRM/V4L2 buffer sharing
2012-08-17 22:03 ` DRM/V4L2 buffer sharing Mauro Carvalho Chehab
@ 2012-08-17 22:54 ` Laurent Pinchart
0 siblings, 0 replies; 25+ messages in thread
From: Laurent Pinchart @ 2012-08-17 22:54 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Sylwester Nawrocki, Sylwester Nawrocki, LMML, Manu Abraham,
David Härdeman, Jonathan Corbet, Guennadi Liakhovetski,
Prabhakar Lad, Tomasz Stanislawski,
dri-devel@lists.freedesktop.org
Hi Mauro,
On Friday 17 August 2012 19:03:47 Mauro Carvalho Chehab wrote:
> Em 17-08-2012 18:01, Sylwester Nawrocki escreveu:
> > On 08/15/2012 11:09 PM, Laurent Pinchart wrote:
> >> On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote:
> >>> On 08/15/2012 12:06 AM, Laurent Pinchart wrote:
> >>>> On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote:
> >>>>> On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote:
> >>>>>> 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
> >>>>>>
> >>>>>> <s.nawrocki@samsung.com>
> >>>>>
> >>>>> 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.
> >>>>
> >>>> 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.
> >>
> >> 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/
That won't really help for our test cases. I want to capture from a UVC device
using DMABUF import directly to the i915 DRM device using DRM export. In order
to do so I will need to get hold of GEM objects that I can use to display the
data, possibly through the OpenGL API. I'm looking for help on that last
point, I can easily handle the UVC capture code myself.
> 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.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-14 13:04 Patches submitted via linux-media ML that are at patchwork.linuxtv.org Mauro Carvalho Chehab
` (4 preceding siblings ...)
2012-08-14 16:37 ` Sylwester Nawrocki
@ 2012-08-15 8:30 ` Guennadi Liakhovetski
2012-08-15 23:46 ` Mauro Carvalho Chehab
6 siblings, 0 replies; 25+ messages in thread
From: Guennadi Liakhovetski @ 2012-08-15 8:30 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: LMML, Manu Abraham, David Härdeman, Silvester Nawrocki,
Laurent Pinchart, Jonathan Corbet, Prabhakar Lad
Hi Mauro
On Tue, 14 Aug 2012, Mauro Carvalho Chehab wrote:
> 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 <g.liakhovetski@gmx.de> : 17
> Manu Abraham <abraham.manu@gmail.com> : 11
> Silvester Nawrocki <sylvester.nawrocki@gmail.com> : 11
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> : 3
> Jonathan Corbet <corbet@lwn.net> : 2
> David Härdeman <david@hardeman.nu> : 1
> Prabhakar Lad <prabhakar.lad@ti.com> : 1
[snip]
> == Guennadi Liakhovetski <g.liakhovetski@gmx.de> ==
>
> Aug, 2 2012: [v3] mt9v022: Add support for mt9v024 http://patchwork.linuxtv.org/patch/13582 Alex Gershgorin <alexg@meprolight.com>
> Aug, 6 2012: [1/1] media: mx3_camera: Improve data bus width check code for probe http://patchwork.linuxtv.org/patch/13618 Liu Ying <Ying.liu@freescale.com>
above two waiting to be reviewed for 3.7
> Aug, 9 2012: [1/1, v2] media/video: vpif: fixing function name start to vpif_config http://patchwork.linuxtv.org/patch/13689 Dror Cohen <dror@liveu.tv>
That one is not for me
> 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 <twang13@marvell.com>
> Jul,30 2012: media: mx3_camera: buf_init() add buffer state check http://patchwork.linuxtv.org/patch/13528 Alex Gershgorin <alexg@meprolight.com>
> Jul,11 2012: [v2] media: mx2_camera: Don't modify non volatile parameters in try_fm http://patchwork.linuxtv.org/patch/13310 Javier Martin <javier.martin@vista-silicon.com>
will handle these, some are fixes for 3.6, others for 3.7
> Jul,11 2012: [v6] media: mx2_camera: Fix mbus format handling http://patchwork.linuxtv.org/patch/13314 Javier Martin <javier.martin@vista-silicon.com>
> Jul,12 2012: media: mx2_camera: Add YUYV output format. http://patchwork.linuxtv.org/patch/13330 Javier Martin <javier.martin@vista-silicon.com>
These patches are among those, that I pushed for 3.6 and that have been
lost.
> Jul,12 2012: media: mx2_camera: Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MS http://patchwork.linuxtv.org/patch/13331 Javier Martin <javier.martin@vista-silicon.com>
3.7 or even 3.8
> Jul,12 2012: [1/2,v2] media: Add mem2mem deinterlacing driver. http://patchwork.linuxtv.org/patch/13332 Javier Martin <javier.martin@vista-silicon.com>
I didn't necessarily consider this one for me? I could help review it id
you like, but so far I'm happy with others taking care of it;-)
> Jul,30 2012: mt9v022: Add support for mt9v024 http://patchwork.linuxtv.org/patch/13525 Alex Gershgorin <alexg@meprolight.com>
A duplicate of the first patch in this list.
> Aug, 1 2012: [v2] media: mx2_camera: Fix clock handling for i.MX27. http://patchwork.linuxtv.org/patch/13569 Javier Martin <javier.martin@vista-silicon.com>
IIRC, a fix for 3.6-rc.
> Aug, 2 2012: [v2] mt9v022: Add support for mt9v024 http://patchwork.linuxtv.org/patch/13579 Alex Gershgorin <alexg@meprolight.com>
a triplicate
> May,25 2012: [06/15] video: mx1_camera: Use clk_prepare_enable/clk_disable_unprepar http://patchwork.linuxtv.org/patch/11505 Fabio Estevam <fabio.estevam@freescale.com>
> May,25 2012: [07/15] video: mx2_camera: Use clk_prepare_enable/clk_disable_unprepar http://patchwork.linuxtv.org/patch/11506 Fabio Estevam <fabio.estevam@freescale.com>
dropped from 3.6 pull
> May,25 2012: [08/15] video: mx2_emmaprp: Use clk_prepare_enable/clk_disable_unprepa http://patchwork.linuxtv.org/patch/11507 Fabio Estevam <fabio.estevam@freescale.com>
not fot me
> Jun, 5 2012: media: mx2_camera: Add YUYV output format. http://patchwork.linuxtv.org/patch/11580 Javier Martin <javier.martin@vista-silicon.com>
a duplicate
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-14 13:04 Patches submitted via linux-media ML that are at patchwork.linuxtv.org Mauro Carvalho Chehab
` (5 preceding siblings ...)
2012-08-15 8:30 ` Patches submitted via linux-media ML that are at patchwork.linuxtv.org Guennadi Liakhovetski
@ 2012-08-15 23:46 ` Mauro Carvalho Chehab
2012-08-16 10:38 ` Prabhakar Lad
6 siblings, 1 reply; 25+ messages in thread
From: Mauro Carvalho Chehab @ 2012-08-15 23:46 UTC (permalink / raw)
To: LMML
Cc: Manu Abraham, David Härdeman, Silvester Nawrocki,
Laurent Pinchart, Jonathan Corbet, Guennadi Liakhovetski,
Prabhakar Lad, Malcolm Priestley
Em 14-08-2012 10:04, Mauro Carvalho Chehab escreveu:
> 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 <olivier.grenie@parrot.com>
Jun,21 2012: dvb: push down ioctl lock in dvb_usercopy http://patchwork.linuxtv.org/patch/12989 Nikolaus Schulz <schulz@macnetix.de>
Jul,26 2012: media: rc: Add support to decode Remotes using NECx IR protocol http://patchwork.linuxtv.org/patch/13480 Ravi Kumar V <kumarrav@codeaurora.org>
Jul,31 2012: [RFC] Fix DVB ioctls failing if frontend open/closed too fast http://patchwork.linuxtv.org/patch/13563 Juergen Lock <nox@jelal.kn-bremen.de>
Jan,20 2012: [RFC] dvb: Add DVBv5 properties for quality parameters http://patchwork.linuxtv.org/patch/9578 Mauro Carvalho Chehab <mchehab@redhat.com>
Aug,13 2012: [media] dvb: frontend API: Add a flag to indicate that get_frontend() http://patchwork.linuxtv.org/patch/13783 Mauro Carvalho Chehab <mchehab@redhat.com>
== Guennadi Liakhovetski <g.liakhovetski@gmx.de> ==
Jul,12 2012: media: mx2_camera: Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MS http://patchwork.linuxtv.org/patch/13331 Javier Martin <javier.martin@vista-silicon.com>
May,25 2012: [08/15] video: mx2_emmaprp: Use clk_prepare_enable/clk_disable_unprepa http://patchwork.linuxtv.org/patch/11507 Fabio Estevam <fabio.estevam@freescale.com>
== Prabhakar Lad <prabhakar.lad@ti.com> ==
Aug, 9 2012: [1/1, v2] media/video: vpif: fixing function name start to vpif_config http://patchwork.linuxtv.org/patch/13689 Dror Cohen <dror@liveu.tv>
== Jonathan Corbet <corbet@lwn.net> ==
Apr,26 2012: [2/2] marvell-cam: Build fix: missing "select VIDEOBUF2_VMALLOC" http://patchwork.linuxtv.org/patch/10848 Chris Ball <cjb@laptop.org>
Aug,13 2012: [2/2] marvell-cam: Build fix: missing "select VIDEOBUF2_VMALLOC" http://patchwork.linuxtv.org/patch/13784 Mauro Carvalho Chehab <mchehab@redhat.com>
== Manu Abraham <abraham.manu@gmail.com> ==
May,25 2011: Add remote control support for mantis Christoph Pinkl <christoph.pinkl@gmail.com>
Jun, 8 2011: Add remote control support for mantis http://patchwork.linuxtv.org/patch/7217 Christoph Pinkl <christoph.pinkl@gmail.com>
Nov,29 2011: stv090x: implement function for reading uncorrected blocks count http://patchwork.linuxtv.org/patch/8656 Mariusz Bia?o?czyk <manio@skyboo.net>
Mar,11 2012: [2/3] stv090x: use error counter 1 for BER estimation http://patchwork.linuxtv.org/patch/10301 Andreas Regel <andreas.regel@gmx.de>
Mar,11 2012: [3/3] stv090x: On STV0903 do not set registers of the second path. http://patchwork.linuxtv.org/patch/10302 Andreas Regel <andreas.regel@gmx.de>
Apr, 1 2012: [05/11] Slightly more friendly debugging output. http://patchwork.linuxtv.org/patch/10520 "Steinar H. Gunderson" <sesse@samfundet.no>
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" <sesse@samfundet.no>
Apr, 1 2012: [07/11] Fix a ton of SMP-unsafe accesses. http://patchwork.linuxtv.org/patch/10523 "Steinar H. Gunderson" <sesse@samfundet.no>
Apr, 1 2012: [11/11] Enable Mantis CA support. http://patchwork.linuxtv.org/patch/10524 "Steinar H. Gunderson" <sesse@samfundet.no>
Apr, 1 2012: [08/11] Remove some unused structure members. http://patchwork.linuxtv.org/patch/10525 "Steinar H. Gunderson" <sesse@samfundet.no>
Apr, 1 2012: [09/11] Correct wait_event_timeout error return check. http://patchwork.linuxtv.org/patch/10526 "Steinar H. Gunderson" <sesse@samfundet.no>
Apr, 1 2012: [10/11] Ignore timeouts waiting for the IRQ0 flag. http://patchwork.linuxtv.org/patch/10527 "Steinar H. Gunderson" <sesse@samfundet.no>
== David Härdeman <david@hardeman.nu> ==
Jul,31 2012: [media] winbond-cir: Fix initialization http://patchwork.linuxtv.org/patch/13539 Sean Young <sean@mess.org>
== Waiting for Malcolm Priestley <tvboxspy@gmail.com> 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 <liplianin@me.by>
May, 8 2012: [2/2] TeVii DVB-S s421 and s632 cards support, rs2000 part http://patchwork.linuxtv.org/patch/11104 Igor M. Liplianin <liplianin@me.by>
Number of pending patches per reviewer:
Manu Abraham <abraham.manu@gmail.com> : 12
LinuxTV community : 6
Malcolm Priestley <tvboxspy@gmail.com> : 2
Jonathan Corbet <corbet@lwn.net> : 2
Guennadi Liakhovetski <g.liakhovetski@gmx.de> : 2
David Härdeman <david@hardeman.nu> : 1
Prabhakar Lad <prabhakar.lad@ti.com> : 1
Cheers,
Mauro
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org
2012-08-15 23:46 ` Mauro Carvalho Chehab
@ 2012-08-16 10:38 ` Prabhakar Lad
0 siblings, 0 replies; 25+ messages in thread
From: Prabhakar Lad @ 2012-08-16 10:38 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: LMML, Manu Abraham, David Härdeman, Silvester Nawrocki,
Laurent Pinchart, Jonathan Corbet, Guennadi Liakhovetski,
Malcolm Priestley
Hi Mauro,
On Thursday 16 August 2012 05:16 AM, Mauro Carvalho Chehab wrote:
> Em 14-08-2012 10:04, Mauro Carvalho Chehab escreveu:
>> 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 <olivier.grenie@parrot.com>
> Jun,21 2012: dvb: push down ioctl lock in dvb_usercopy http://patchwork.linuxtv.org/patch/12989 Nikolaus Schulz <schulz@macnetix.de>
> Jul,26 2012: media: rc: Add support to decode Remotes using NECx IR protocol http://patchwork.linuxtv.org/patch/13480 Ravi Kumar V <kumarrav@codeaurora.org>
> Jul,31 2012: [RFC] Fix DVB ioctls failing if frontend open/closed too fast http://patchwork.linuxtv.org/patch/13563 Juergen Lock <nox@jelal.kn-bremen.de>
> Jan,20 2012: [RFC] dvb: Add DVBv5 properties for quality parameters http://patchwork.linuxtv.org/patch/9578 Mauro Carvalho Chehab <mchehab@redhat.com>
> Aug,13 2012: [media] dvb: frontend API: Add a flag to indicate that get_frontend() http://patchwork.linuxtv.org/patch/13783 Mauro Carvalho Chehab <mchehab@redhat.com>
>
> == Guennadi Liakhovetski <g.liakhovetski@gmx.de> ==
>
> Jul,12 2012: media: mx2_camera: Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MS http://patchwork.linuxtv.org/patch/13331 Javier Martin <javier.martin@vista-silicon.com>
> May,25 2012: [08/15] video: mx2_emmaprp: Use clk_prepare_enable/clk_disable_unprepa http://patchwork.linuxtv.org/patch/11507 Fabio Estevam <fabio.estevam@freescale.com>
>
> == Prabhakar Lad <prabhakar.lad@ti.com> ==
>
> Aug, 9 2012: [1/1, v2] media/video: vpif: fixing function name start to vpif_config http://patchwork.linuxtv.org/patch/13689 Dror Cohen <dror@liveu.tv>
>
This patch can be marked as 'Accepted'.
Thanks and Regards,
--Prabhakar
> == Jonathan Corbet <corbet@lwn.net> ==
>
> Apr,26 2012: [2/2] marvell-cam: Build fix: missing "select VIDEOBUF2_VMALLOC" http://patchwork.linuxtv.org/patch/10848 Chris Ball <cjb@laptop.org>
> Aug,13 2012: [2/2] marvell-cam: Build fix: missing "select VIDEOBUF2_VMALLOC" http://patchwork.linuxtv.org/patch/13784 Mauro Carvalho Chehab <mchehab@redhat.com>
>
> == Manu Abraham <abraham.manu@gmail.com> ==
>
> May,25 2011: Add remote control support for mantis Christoph Pinkl <christoph.pinkl@gmail.com>
> Jun, 8 2011: Add remote control support for mantis http://patchwork.linuxtv.org/patch/7217 Christoph Pinkl <christoph.pinkl@gmail.com>
> Nov,29 2011: stv090x: implement function for reading uncorrected blocks count http://patchwork.linuxtv.org/patch/8656 Mariusz Bia?o?czyk <manio@skyboo.net>
> Mar,11 2012: [2/3] stv090x: use error counter 1 for BER estimation http://patchwork.linuxtv.org/patch/10301 Andreas Regel <andreas.regel@gmx.de>
> Mar,11 2012: [3/3] stv090x: On STV0903 do not set registers of the second path. http://patchwork.linuxtv.org/patch/10302 Andreas Regel <andreas.regel@gmx.de>
> Apr, 1 2012: [05/11] Slightly more friendly debugging output. http://patchwork.linuxtv.org/patch/10520 "Steinar H. Gunderson" <sesse@samfundet.no>
> 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" <sesse@samfundet.no>
> Apr, 1 2012: [07/11] Fix a ton of SMP-unsafe accesses. http://patchwork.linuxtv.org/patch/10523 "Steinar H. Gunderson" <sesse@samfundet.no>
> Apr, 1 2012: [11/11] Enable Mantis CA support. http://patchwork.linuxtv.org/patch/10524 "Steinar H. Gunderson" <sesse@samfundet.no>
> Apr, 1 2012: [08/11] Remove some unused structure members. http://patchwork.linuxtv.org/patch/10525 "Steinar H. Gunderson" <sesse@samfundet.no>
> Apr, 1 2012: [09/11] Correct wait_event_timeout error return check. http://patchwork.linuxtv.org/patch/10526 "Steinar H. Gunderson" <sesse@samfundet.no>
> Apr, 1 2012: [10/11] Ignore timeouts waiting for the IRQ0 flag. http://patchwork.linuxtv.org/patch/10527 "Steinar H. Gunderson" <sesse@samfundet.no>
>
> == David Härdeman <david@hardeman.nu> ==
>
> Jul,31 2012: [media] winbond-cir: Fix initialization http://patchwork.linuxtv.org/patch/13539 Sean Young <sean@mess.org>
>
> == Waiting for Malcolm Priestley <tvboxspy@gmail.com> 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 <liplianin@me.by>
> May, 8 2012: [2/2] TeVii DVB-S s421 and s632 cards support, rs2000 part http://patchwork.linuxtv.org/patch/11104 Igor M. Liplianin <liplianin@me.by>
>
> Number of pending patches per reviewer:
> Manu Abraham <abraham.manu@gmail.com> : 12
> LinuxTV community : 6
> Malcolm Priestley <tvboxspy@gmail.com> : 2
> Jonathan Corbet <corbet@lwn.net> : 2
> Guennadi Liakhovetski <g.liakhovetski@gmx.de> : 2
> David Härdeman <david@hardeman.nu> : 1
> Prabhakar Lad <prabhakar.lad@ti.com> : 1
>
> Cheers,
> Mauro
>
^ permalink raw reply [flat|nested] 25+ messages in thread