OMAP patches for linux-media

OMAP patches for linux-media

[Mauro Carvalho Chehab]

Hi Sakari and others,

I'm seeing lots of patches and discussions for OMAP and DaVinci being handled
at the linux-media Mailing List, as part of the development process of the open
source drivers.

However, it is hard to track all those discussions and be sure what patches are
ready for merging and what patches are just RFC.

On the development model we use here, we have driver maintainers that are
responsible to discuss about improvements on their drivers. They are generally
the driver authors or the one that first started submitting the patches for
that driver(s). 

One of the roles of the driver maintainers is to collect the patches for the
drivers they maintain, merge on their trees, and periodically ask the patch
merge. 

One fundamental concept on Kernel development is the concept of "Commit earlier
and commit often", meaning that the better is to send small, incremental, and
periodic patches, than wait until having everything done, then submit a big
patch. Every time I receive a big patch I need to postpone its analysis and
open a big window on my schedule to analyze it. Of course, this means to
postpone it, and generally results on lots of comments going back to developer,
that, in turn, will need to do lots of changes and return me back with another
big patch for me to analyze again, resulting on a long period of time for
merging it.

As you, Sakari, was the first one that started merging the OMAP drivers, I was
expecting that you would be the one that will handle the figure of the driver
maintainer for OMAP. I even created you an account at linuxtv for you to create
your trees there and ask me to merge from it.

Unfortunately, you haven't sent me any pull requests yet along this year. This
is concerning me a lot, since, at the end, I'll need to review big piles of
patches and/or drivers when you decide to submit the final version.

So, I decided to send you this email, c/c a random list of people that I
believe are involved on the submit and/or review process of those patches, in
the hope to better understand and to discuss what's happening and how can we
speedup the merge process of those patches.



Cheers,
Mauro

RE: OMAP patches for linux-media

[Aguirre Rodriguez, Sergio Alberto]

> From: Mauro Carvalho Chehab [mchehab@infradead.org]
> Sent: Tuesday, June 16, 2009 8:40 AM
> To: Sakari Ailus
> Cc: Jadav, Brijesh R; Subrahmanya, Chaithrika; David Cohen; Curran, Dominic; Eduardo Valentin; Eero Nurkkala; Felipe Balbi; Shah, Hardik; Nagalla, Hari; Hadli, Manjunath; Mikko Hurskainen; Karicheri, Muralidharan; Menon, Nishanth; R, Sivaraj; Paulraj, Sandeep; Aguirre Rodriguez, Sergio Alberto; Tomi Valkeinen; Tuukka Toivonen; Hiremath, Vaibhav; Hans Verkuil; Linux Media Mailing List
> Subject: OMAP patches for linux-media
> 
> Hi Sakari and others,
> 
> I'm seeing lots of patches and discussions for OMAP and DaVinci being handled
> at the linux-media Mailing List, as part of the development process of the open
> source drivers.
> 
> However, it is hard to track all those discussions and be sure what patches are
> ready for merging and what patches are just RFC.
> 
> On the development model we use here, we have driver maintainers that are
> responsible to discuss about improvements on their drivers. They are generally
> the driver authors or the one that first started submitting the patches for
> that driver(s).
> 
> One of the roles of the driver maintainers is to collect the patches for the
> drivers they maintain, merge on their trees, and periodically ask the patch
> merge.
> 
> One fundamental concept on Kernel development is the concept of "Commit earlier
> and commit often", meaning that the better is to send small, incremental, and
> periodic patches, than wait until having everything done, then submit a big
> patch. Every time I receive a big patch I need to postpone its analysis and
> open a big window on my schedule to analyze it. Of course, this means to
> postpone it, and generally results on lots of comments going back to developer,
> that, in turn, will need to do lots of changes and return me back with another
> big patch for me to analyze again, resulting on a long period of time for
> merging it.
> 
> As you, Sakari, was the first one that started merging the OMAP drivers, I was
> expecting that you would be the one that will handle the figure of the driver
> maintainer for OMAP. I even created you an account at linuxtv for you to create
> your trees there and ask me to merge from it.
> 
> Unfortunately, you haven't sent me any pull requests yet along this year. This
> is concerning me a lot, since, at the end, I'll need to review big piles of
> patches and/or drivers when you decide to submit the final version.
> 
> So, I decided to send you this email, c/c a random list of people that I
> believe are involved on the submit and/or review process of those patches, in
> the hope to better understand and to discuss what's happening and how can we
> speedup the merge process of those patches.

Hi Mauro,

We are currently going through an internal debugging process on new found issues while testing the driver on a proprietary HW/SW platform.

As there is priority for us to find stability in this platforms, we had to put aside a bit the maintenance of the shared patches.

One maybe important news is that I'll be creating a new tree soon to host current OMAP3 and future OMAP4 camera drivers for upstream from TI perspective. My main task will be to maintain this tree in TI, and take care of upstreaming and fixing patches for acceptance by both linux-omap and linux-media lists.

Some of the known to-dos are:
- v4l2_subdev conversion
- Regulator framework usage
- ISP registration as a memory to memory device.

I hope to resume this task soon, and keep in touch with the community on the latest version of patches. I'll let you know when the next version is ready for merge.

Thanks for your concern and time on this.

Regards,
Sergio
> 
> 
> 
> Cheers,
> Mauro
> 
> 

Re: OMAP patches for linux-media

[Mauro Carvalho Chehab]

Em Tue, 16 Jun 2009 09:24:14 -0500
"Aguirre Rodriguez, Sergio Alberto" <saaguirre@ti.com> escreveu:

> Hi Mauro,
> 
> We are currently going through an internal debugging process on new found issues while testing the driver on a proprietary HW/SW platform.
> 
> As there is priority for us to find stability in this platforms, we had to put aside a bit the maintenance of the shared patches.

Ok.
> 
> One maybe important news is that I'll be creating a new tree soon to host current OMAP3 and future OMAP4 camera drivers for upstream from TI perspective. My main task will be to maintain this tree in TI, and take care of upstreaming and fixing patches for acceptance by both linux-omap and linux-media lists.

That's good news! I think there are still some OMAP 2 RFC patches that weren't
applied. Are you also handling those?

> Some of the known to-dos are:
> - v4l2_subdev conversion
> - Regulator framework usage
> - ISP registration as a memory to memory device.
> 
> I hope to resume this task soon, and keep in touch with the community on the latest version of patches. I'll let you know when the next version is ready for merge.

Ok, thanks.

> Thanks for your concern and time on this.
> 
> Regards,
> Sergio



Cheers,
Mauro

RE: OMAP patches for linux-media

[Karicheri, Muralidharan]

Hi Mauro,

[snip]
>
>I'm seeing lots of patches and discussions for OMAP and DaVinci being
>handled
>at the linux-media Mailing List, as part of the development process of the
>open
>source drivers.

[MK] I along with Chaithrika are working with Hans Verkuil to get the DaVinci video drivers added to open source. I believe VPIF display driver for DM6467 is ready for merge. The VPFE capture driver for DM355 and DM6446 is almost ready. I will be creating the version 3 (hopefully final) version of the patch and review the same in the list.
Do you think these patches can be merged to 2.6.31? This will be of great help to us if this can be done since we have other works lined up based on these and our customers are waiting for this for a very long time.

[snip]
>
>One fundamental concept on Kernel development is the concept of "Commit
>earlier
>and commit often", meaning that the better is to send small, incremental,
>and
>periodic patches, than wait until having everything done, then submit a big

[MK] With that in mind, we began our porting work with minimum set of features and stripped off many of the features so that we can add them incrementally.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-karicheri2@ti.com

Re: OMAP patches for linux-media

[Mauro Carvalho Chehab]

Em Tue, 16 Jun 2009 10:40:18 -0500
"Karicheri, Muralidharan" <m-karicheri2@ti.com> escreveu:

> Hi Mauro,
> 
> [snip]
> >
> >I'm seeing lots of patches and discussions for OMAP and DaVinci being
> >handled
> >at the linux-media Mailing List, as part of the development process of the
> >open
> >source drivers.
> 
> [MK] I along with Chaithrika are working with Hans Verkuil to get the DaVinci video drivers added to open source. I believe VPIF display driver for DM6467 is ready for merge. The VPFE capture driver for DM355 and DM6446 is almost ready. I will be creating the version 3 (hopefully final) version of the patch and review the same in the list.
> Do you think these patches can be merged to 2.6.31? This will be of great help to us if this can be done since we have other works lined up based on these and our customers are waiting for this for a very long time.

Maybe there are still time for 2.6.31. Just please let me know what patches are
the final version (or, even better), add it on some -hg tree and ask me to pull
from it. If needed, I may create an account for a few TI/Nokia maintainers at
linuxtv.

I'll then review the patch series and apply if ok (or ask for changes
if needed).

> 
> [snip]
> >
> >One fundamental concept on Kernel development is the concept of "Commit
> >earlier
> >and commit often", meaning that the better is to send small, incremental,
> >and
> >periodic patches, than wait until having everything done, then submit a big
> 
> [MK] With that in mind, we began our porting work with minimum set of features and stripped off many of the features so that we can add them incrementally.

Seems ok to me.

I saw also some radio receiver drivers from TI at the ML. I'm not sure what of
those are meant for merging.

For now, I marked all patches I saw at patchwork that seemed to be related to
OMAP/Da Vinci as RFC at patchwork.kernel.org.

> Murali Karicheri
> Software Design Engineer
> Texas Instruments Inc.
> Germantown, MD 20874
> email: m-karicheri2@ti.com
> 
> 
> 
> --
> 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




Cheers,
Mauro

Re: OMAP patches for linux-media

[Hans Verkuil]

On Tuesday 16 June 2009 15:40:18 Mauro Carvalho Chehab wrote:
> Hi Sakari and others,
>
> I'm seeing lots of patches and discussions for OMAP and DaVinci being
> handled at the linux-media Mailing List, as part of the development
> process of the open source drivers.
>
> However, it is hard to track all those discussions and be sure what
> patches are ready for merging and what patches are just RFC.
>
> On the development model we use here, we have driver maintainers that are
> responsible to discuss about improvements on their drivers. They are
> generally the driver authors or the one that first started submitting the
> patches for that driver(s).
>
> One of the roles of the driver maintainers is to collect the patches for
> the drivers they maintain, merge on their trees, and periodically ask the
> patch merge.
>
> One fundamental concept on Kernel development is the concept of "Commit
> earlier and commit often", meaning that the better is to send small,
> incremental, and periodic patches, than wait until having everything
> done, then submit a big patch. Every time I receive a big patch I need to
> postpone its analysis and open a big window on my schedule to analyze it.
> Of course, this means to postpone it, and generally results on lots of
> comments going back to developer, that, in turn, will need to do lots of
> changes and return me back with another big patch for me to analyze
> again, resulting on a long period of time for merging it.
>
> As you, Sakari, was the first one that started merging the OMAP drivers,
> I was expecting that you would be the one that will handle the figure of
> the driver maintainer for OMAP. I even created you an account at linuxtv
> for you to create your trees there and ask me to merge from it.
>
> Unfortunately, you haven't sent me any pull requests yet along this year.
> This is concerning me a lot, since, at the end, I'll need to review big
> piles of patches and/or drivers when you decide to submit the final
> version.
>
> So, I decided to send you this email, c/c a random list of people that I
> believe are involved on the submit and/or review process of those
> patches, in the hope to better understand and to discuss what's happening
> and how can we speedup the merge process of those patches.

I have proposed this before, but I'll do it again: I'm more than happy to be 
the official person who collects and organizes the omap and davinci patches 
for you and who does the initial reviews. This is effectively already the 
case since I've been reviewing both omap and davinci patches pretty much 
from the beginning.

Both the omap2/3 display driver and the davinci drivers are now very close 
to be ready for inclusion in the kernel as my last reviews only found some 
minor things.

Part of the reason for the delays for both omap and davinci was that they 
had to be modified for v4l2_subdev, which was an absolute necessity, and 
because they simply needed quite a bit of work to make them suitable for 
inclusion in the kernel.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

Re: OMAP patches for linux-media

[Mauro Carvalho Chehab]

Em Wed, 17 Jun 2009 08:30:13 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> On Tuesday 16 June 2009 15:40:18 Mauro Carvalho Chehab wrote:
> > Hi Sakari and others,
> >
> > I'm seeing lots of patches and discussions for OMAP and DaVinci being
> > handled at the linux-media Mailing List, as part of the development
> > process of the open source drivers.
> >
> > However, it is hard to track all those discussions and be sure what
> > patches are ready for merging and what patches are just RFC.
> >
> > On the development model we use here, we have driver maintainers that are
> > responsible to discuss about improvements on their drivers. They are
> > generally the driver authors or the one that first started submitting the
> > patches for that driver(s).
> >
> > One of the roles of the driver maintainers is to collect the patches for
> > the drivers they maintain, merge on their trees, and periodically ask the
> > patch merge.
> >
> > One fundamental concept on Kernel development is the concept of "Commit
> > earlier and commit often", meaning that the better is to send small,
> > incremental, and periodic patches, than wait until having everything
> > done, then submit a big patch. Every time I receive a big patch I need to
> > postpone its analysis and open a big window on my schedule to analyze it.
> > Of course, this means to postpone it, and generally results on lots of
> > comments going back to developer, that, in turn, will need to do lots of
> > changes and return me back with another big patch for me to analyze
> > again, resulting on a long period of time for merging it.
> >
> > As you, Sakari, was the first one that started merging the OMAP drivers,
> > I was expecting that you would be the one that will handle the figure of
> > the driver maintainer for OMAP. I even created you an account at linuxtv
> > for you to create your trees there and ask me to merge from it.
> >
> > Unfortunately, you haven't sent me any pull requests yet along this year.
> > This is concerning me a lot, since, at the end, I'll need to review big
> > piles of patches and/or drivers when you decide to submit the final
> > version.
> >
> > So, I decided to send you this email, c/c a random list of people that I
> > believe are involved on the submit and/or review process of those
> > patches, in the hope to better understand and to discuss what's happening
> > and how can we speedup the merge process of those patches.
> 
> I have proposed this before, but I'll do it again: I'm more than happy to be 
> the official person who collects and organizes the omap and davinci patches 
> for you and who does the initial reviews. This is effectively already the 
> case since I've been reviewing both omap and davinci patches pretty much 
> from the beginning.

As I said before, in general the maintainer is the driver author or the first
submitter. Submitting patches for me is part of maintainer's hole. It is also a
maintainers responsibility to receive bug fixes and patches from other
developers and deal with them.

In the case where the chipset manufacturer is providing official support, it is
preferred if they are also handling this task. Of course they can delegate this
task to someone else.

While we are still bound to mercurial, the maintainer(s) should use it for
sending me pull requests, especially for a high traffic of patches like
what we're having. I hope we can migrate the development model to -git, but
this may still take some time.

>From my side, I'm ok if they prefer to delegate maintainer's task to you.
I'm also ok if they want to do by themselves. 

As there are multiple driver sets involved (OMAP, OMAP2, OMAP3, OMAP4, DaVinci),
eventually the task can be split on different maintainers, provided that I know
exactly who is maintaining what drivers.

Just let me know what fits better.

> Both the omap2/3 display driver and the davinci drivers are now very close 
> to be ready for inclusion in the kernel as my last reviews only found some 
> minor things.
>
> Part of the reason for the delays for both omap and davinci was that they 
> had to be modified for v4l2_subdev, which was an absolute necessity, and 
> because they simply needed quite a bit of work to make them suitable for 
> inclusion in the kernel.

Ok.



Cheers,
Mauro

RE: [DaVinci] patches for linux-media

[Karicheri, Muralidharan]

Hi Hans & Mauro,

The v3 version of the DaVici VPFE Capture driver and TVP514x driver has been sent to the list for review. I expect this to sail through with out any comments as I have addressed few minor comments from last review. I think Hans will send you the pull request for these patches. Once again, it will be great if this can be merged to 2.6.31.

Murali Karicheri
m-karicheri2@ti.com

>I have proposed this before, but I'll do it again: I'm more than happy to
>be
>the official person who collects and organizes the omap and davinci patches
>for you and who does the initial reviews. This is effectively already the
>case since I've been reviewing both omap and davinci patches pretty much
>from the beginning.
>
>Both the omap2/3 display driver and the davinci drivers are now very close
>to be ready for inclusion in the kernel as my last reviews only found some
>minor things.
>
>Part of the reason for the delays for both omap and davinci was that they
>had to be modified for v4l2_subdev, which was an absolute necessity, and
>because they simply needed quite a bit of work to make them suitable for
>inclusion in the kernel.
>
>Regards,
>
>	Hans
>
>--
>Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

Re: [DaVinci] patches for linux-media

[Hans Verkuil]

On Wednesday 17 June 2009 23:01:21 Karicheri, Muralidharan wrote:
> Hi Hans & Mauro,
>
> The v3 version of the DaVici VPFE Capture driver and TVP514x driver has
> been sent to the list for review. I expect this to sail through with out
> any comments as I have addressed few minor comments from last review. I
> think Hans will send you the pull request for these patches. Once again,
> it will be great if this can be merged to 2.6.31.

I'll prepare a pull request for this tomorrow.

Regards,

	Hans

>
> Murali Karicheri
> m-karicheri2@ti.com
>
> >I have proposed this before, but I'll do it again: I'm more than happy
> > to be
> >the official person who collects and organizes the omap and davinci
> > patches for you and who does the initial reviews. This is effectively
> > already the case since I've been reviewing both omap and davinci
> > patches pretty much from the beginning.
> >
> >Both the omap2/3 display driver and the davinci drivers are now very
> > close to be ready for inclusion in the kernel as my last reviews only
> > found some minor things.
> >
> >Part of the reason for the delays for both omap and davinci was that
> > they had to be modified for v4l2_subdev, which was an absolute
> > necessity, and because they simply needed quite a bit of work to make
> > them suitable for inclusion in the kernel.
> >
> >Regards,
> >
> >	Hans
> >
> >--
> >Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

Re: OMAP patches for linux-media

[Sakari Ailus]

Mauro Carvalho Chehab wrote:
> Hi Sakari and others,

Hi, Mauro!

> I'm seeing lots of patches and discussions for OMAP and DaVinci being handled
> at the linux-media Mailing List, as part of the development process of the open
> source drivers.
> 
> However, it is hard to track all those discussions and be sure what patches are
> ready for merging and what patches are just RFC.
> 
> On the development model we use here, we have driver maintainers that are
> responsible to discuss about improvements on their drivers. They are generally
> the driver authors or the one that first started submitting the patches for
> that driver(s). 
> 
> One of the roles of the driver maintainers is to collect the patches for the
> drivers they maintain, merge on their trees, and periodically ask the patch
> merge. 
> 
> One fundamental concept on Kernel development is the concept of "Commit earlier
> and commit often", meaning that the better is to send small, incremental, and
> periodic patches, than wait until having everything done, then submit a big
> patch. Every time I receive a big patch I need to postpone its analysis and
> open a big window on my schedule to analyze it. Of course, this means to
> postpone it, and generally results on lots of comments going back to developer,
> that, in turn, will need to do lots of changes and return me back with another
> big patch for me to analyze again, resulting on a long period of time for
> merging it.
> 
> As you, Sakari, was the first one that started merging the OMAP drivers, I was
> expecting that you would be the one that will handle the figure of the driver
> maintainer for OMAP. I even created you an account at linuxtv for you to create
> your trees there and ask me to merge from it.
> 
> Unfortunately, you haven't sent me any pull requests yet along this year. This
> is concerning me a lot, since, at the end, I'll need to review big piles of
> patches and/or drivers when you decide to submit the final version.
> 
> So, I decided to send you this email, c/c a random list of people that I
> believe are involved on the submit and/or review process of those patches, in
> the hope to better understand and to discuss what's happening and how can we
> speedup the merge process of those patches.

There are a few reasons for apparent stalling of the development 
process. I should have sent a status update earlier.

The code quality of the ISP driver was originally quite low and from 
that part it wouldn't have made much sense to repeatedly post that for 
reviewing. It's been improving since many of the subdrivers have been 
refactored or rewritten since I last posted the patchset. The end result 
should be (more?) easily understood by human beings...

Another reason for no upstream patches is that we are still depending on 
the obsolete v4l2-int-device in the camera / sensor / lens / flash 
driver interface. Hans' opinion was that we must switch to v4l2_subdev 
instead with which I fully agree. However, due to our internal reasons 
we have not been able to even start that transition process yet.

There is no definite deadline for the v4l2_subdev transition (or even 
its start) at the moment. I'm planning to update the patchset in 
Gitorious, however.

Best regards,

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com

Re: OMAP patches for linux-media

[Hans Verkuil]

> Hi Sakari,
>
> Em Wed, 17 Jun 2009 20:40:32 +0300
> Sakari Ailus <sakari.ailus@nokia.com> escreveu:
>
>> > So, I decided to send you this email, c/c a random list of people that
>> I
>> > believe are involved on the submit and/or review process of those
>> patches, in
>> > the hope to better understand and to discuss what's happening and how
>> can we
>> > speedup the merge process of those patches.
>>
>> There are a few reasons for apparent stalling of the development
>> process. I should have sent a status update earlier.
>>
>> The code quality of the ISP driver was originally quite low and from
>> that part it wouldn't have made much sense to repeatedly post that for
>> reviewing. It's been improving since many of the subdrivers have been
>> refactored or rewritten since I last posted the patchset. The end result
>> should be (more?) easily understood by human beings...
>
> Ok, makes sense.
>
>> Another reason for no upstream patches is that we are still depending on
>> the obsolete v4l2-int-device in the camera / sensor / lens / flash
>> driver interface. Hans' opinion was that we must switch to v4l2_subdev
>> instead with which I fully agree. However, due to our internal reasons
>> we have not been able to even start that transition process yet.
>>
>> There is no definite deadline for the v4l2_subdev transition (or even
>> its start) at the moment. I'm planning to update the patchset in
>> Gitorious, however.
>
> I also see advantages on porting it to v4l2 dev/subdev. However, I don't
> see
> much sense on holding a driver for such a long time just because an
> internal
> KABI, especially since the old v4l2-int-device is still supported, and
> provided
> that you'll do the conversion anyway.

That part is very important. The tvp514x driver went in while still using
v4l2-int-device, but the deal was that it would be converted as soon as
possible, in principle before the next kernel release. That was indeed the
case (and I'll prepare a pull request for that tomorrow), so I was OK with
it.

So if we accept other v4l2-int-device drivers, then only if we have a
solid agreement on when they will be converted to v4l2_subdev. It is very
tempting to postpone that once a driver is in, but the only way we can
have real reuse of i2c drivers is if they all use the same API.

Just my 5 cents...

Regards,

         Hans

>
> Whatever you decide, it is up to you do choose the proper snapshot where
> you
> consider the code ready for the merge submission.
>
> Just be nice with me by avoid sending me all drivers at the same time, on
> big
> pull requests ;)
>
> Cheers,
> Mauro
>


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG