Re: OMAP patches for linux-media
Hi Sakari, Em Wed, 17 Jun 2009 20:40:32 +0300 Sakari Ailus sakari.ai...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP patches for linux-media
Em Wed, 17 Jun 2009 08:30:13 +0200 Hans Verkuil hverk...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP patches for linux-media
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.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP patches for linux-media
From: Mauro Carvalho Chehab [mche...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP patches for linux-media
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-kariche...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP patches for linux-media
Em Tue, 16 Jun 2009 10:40:18 -0500 Karicheri, Muralidharan m-kariche...@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-kariche...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
