* Tentative Agenda for the November workshop @ 2012-10-22 8:35 Hans Verkuil 2012-10-22 10:39 ` [media-workshop] " Laurent Pinchart ` (2 more replies) 0 siblings, 3 replies; 41+ messages in thread From: Hans Verkuil @ 2012-10-22 8:35 UTC (permalink / raw) To: media-workshop; +Cc: linux-media Hi all, This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list. - Explain current merging process (Mauro) - Open floor for discussions on how to improve it (Mauro) - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil) - V4L2 ambiguities (Hans Verkuil) - TSMux device (a mux rather than a demux): Alain Volmat - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) - Device tree support (Guennadi, not known yet whether this topic is needed) - Creating/selecting contexts for hardware that supports this (Samsung, only if time is available) For those whose name is behind a topic: please prepare something before the meeting. We have currently 17 or 18 attendees of a maximum of 25, so there is room for a few more people. Regards, Hans ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-22 8:35 Tentative Agenda for the November workshop Hans Verkuil @ 2012-10-22 10:39 ` Laurent Pinchart 2012-10-22 10:53 ` Sylwester Nawrocki 2012-10-22 21:14 ` Guennadi Liakhovetski 2012-10-25 17:27 ` Mauro Carvalho Chehab 2 siblings, 1 reply; 41+ messages in thread From: Laurent Pinchart @ 2012-10-22 10:39 UTC (permalink / raw) To: media-workshop; +Cc: Hans Verkuil, linux-media Hello, On Monday 22 October 2012 10:35:56 Hans Verkuil wrote: > Hi all, > > This is the tentative agenda for the media workshop on November 8, 2012. > If you have additional things that you want to discuss, or something is > wrong or incomplete in this list, please let me know so I can update the > list. Thank you Hans for taking care of the agenda. > - Explain current merging process (Mauro) > - Open floor for discussions on how to improve it (Mauro) > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for > staging and mainline acceptance: which frameworks to use, v4l2-compliance, > etc. (Hans Verkuil) > - V4L2 ambiguities (Hans Verkuil) > - TSMux device (a mux rather than a demux): Alain Volmat > - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) > - Device tree support (Guennadi, not known yet whether this topic is needed) > - Creating/selecting contexts for hardware that supports this (Samsung, > only if time is available) This last topic will likely require lots of brainstorming, and thus time. If the schedule permits, would anyone be interested in meeting earlier during the week already ? > For those whose name is behind a topic: please prepare something before the > meeting. > > We have currently 17 or 18 attendees of a maximum of 25, so there is room > for a few more people. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-22 10:39 ` [media-workshop] " Laurent Pinchart @ 2012-10-22 10:53 ` Sylwester Nawrocki 2012-10-22 10:57 ` Alain VOLMAT 2012-10-22 11:18 ` Laurent Pinchart 0 siblings, 2 replies; 41+ messages in thread From: Sylwester Nawrocki @ 2012-10-22 10:53 UTC (permalink / raw) To: Laurent Pinchart; +Cc: media-workshop, Hans Verkuil, linux-media Hi Laurent, On 10/22/2012 12:39 PM, Laurent Pinchart wrote: > Hello, > > On Monday 22 October 2012 10:35:56 Hans Verkuil wrote: >> Hi all, >> >> This is the tentative agenda for the media workshop on November 8, 2012. >> If you have additional things that you want to discuss, or something is >> wrong or incomplete in this list, please let me know so I can update the >> list. > > Thank you Hans for taking care of the agenda. > >> - Explain current merging process (Mauro) >> - Open floor for discussions on how to improve it (Mauro) >> - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for >> staging and mainline acceptance: which frameworks to use, v4l2-compliance, >> etc. (Hans Verkuil) >> - V4L2 ambiguities (Hans Verkuil) >> - TSMux device (a mux rather than a demux): Alain Volmat >> - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) >> - Device tree support (Guennadi, not known yet whether this topic is needed) >> - Creating/selecting contexts for hardware that supports this (Samsung, >> only if time is available) > > This last topic will likely require lots of brainstorming, and thus time. If > the schedule permits, would anyone be interested in meeting earlier during the > week already ? My intention was to also possibly discuss it with others before the actual media workshop. Would be nice if we could have arranged such a meeting. I'm not sure about the room conditions though. It's probably not a big issue, unless there is really many people interested in that topic. -- Regards, Sylwester ^ permalink raw reply [flat|nested] 41+ messages in thread
* RE: [media-workshop] Tentative Agenda for the November workshop 2012-10-22 10:53 ` Sylwester Nawrocki @ 2012-10-22 10:57 ` Alain VOLMAT 2012-10-22 11:17 ` Sylwester Nawrocki 2012-10-22 11:18 ` Laurent Pinchart 1 sibling, 1 reply; 41+ messages in thread From: Alain VOLMAT @ 2012-10-22 10:57 UTC (permalink / raw) To: Sylwester Nawrocki, Laurent Pinchart; +Cc: media-workshop, linux-media Hi all, Could someone summaries very rapidly what is this create/select context stuff ? For now I do not plan to be in Barcelona more than 1 day but at the same time don't want to miss something that might be useful for us. Regards, Alain > -----Original Message----- > From: media-workshop-bounces@linuxtv.org [mailto:media-workshop- > bounces@linuxtv.org] On Behalf Of Sylwester Nawrocki > Sent: Monday, October 22, 2012 12:53 PM > To: Laurent Pinchart > Cc: media-workshop@linuxtv.org; linux-media > Subject: Re: [media-workshop] Tentative Agenda for the November > workshop > > Hi Laurent, > > On 10/22/2012 12:39 PM, Laurent Pinchart wrote: > > Hello, > > > > On Monday 22 October 2012 10:35:56 Hans Verkuil wrote: > >> Hi all, > >> > >> This is the tentative agenda for the media workshop on November 8, > 2012. > >> If you have additional things that you want to discuss, or something > >> is wrong or incomplete in this list, please let me know so I can > >> update the list. > > > > Thank you Hans for taking care of the agenda. > > > >> - Explain current merging process (Mauro) > >> - Open floor for discussions on how to improve it (Mauro) > >> - Write down minimum requirements for new V4L2 (and DVB?) drivers, > both for > >> staging and mainline acceptance: which frameworks to use, > >> v4l2-compliance, etc. (Hans Verkuil) > >> - V4L2 ambiguities (Hans Verkuil) > >> - TSMux device (a mux rather than a demux): Alain Volmat > >> - dmabuf status, esp. with regards to being able to test > >> (Mauro/Samsung) > >> - Device tree support (Guennadi, not known yet whether this topic is > >> needed) > >> - Creating/selecting contexts for hardware that supports this > >> (Samsung, only if time is available) > > > > This last topic will likely require lots of brainstorming, and thus > > time. If the schedule permits, would anyone be interested in meeting > > earlier during the week already ? > > My intention was to also possibly discuss it with others before the actual > media workshop. Would be nice if we could have arranged such a meeting. > I'm not sure about the room conditions though. It's probably not a big issue, > unless there is really many people interested in that topic. > > -- > Regards, > Sylwester > > > _______________________________________________ > media-workshop mailing list > media-workshop@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-22 10:57 ` Alain VOLMAT @ 2012-10-22 11:17 ` Sylwester Nawrocki 0 siblings, 0 replies; 41+ messages in thread From: Sylwester Nawrocki @ 2012-10-22 11:17 UTC (permalink / raw) To: Alain VOLMAT Cc: Sylwester Nawrocki, Laurent Pinchart, media-workshop, linux-media Hi, On 10/22/2012 12:57 PM, Alain VOLMAT wrote: > Hi all, > > Could someone summaries very rapidly what is this create/select context stuff ? > For now I do not plan to be in Barcelona more than 1 day but at the same time > don't want to miss something that might be useful for us. Please see this thread for more details: http://www.mail-archive.com/linux-media@vger.kernel.org/msg52168.html This is about creating, selecting device configuration contexts and handling e.g. camera modes like viewfinder and still capture. Currently only mem-to-mem devices in V4L2 API are allowed to support multiple device contexts, and those are per file handle. I hope this clarifies it a bit for you. -- Regards, Sylwester ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-22 10:53 ` Sylwester Nawrocki 2012-10-22 10:57 ` Alain VOLMAT @ 2012-10-22 11:18 ` Laurent Pinchart 2012-10-22 12:06 ` Hans Verkuil 2012-10-22 21:13 ` Guennadi Liakhovetski 1 sibling, 2 replies; 41+ messages in thread From: Laurent Pinchart @ 2012-10-22 11:18 UTC (permalink / raw) To: Sylwester Nawrocki; +Cc: media-workshop, Hans Verkuil, linux-media Hi Sylwester, On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote: > On 10/22/2012 12:39 PM, Laurent Pinchart wrote: > > On Monday 22 October 2012 10:35:56 Hans Verkuil wrote: > >> Hi all, > >> > >> This is the tentative agenda for the media workshop on November 8, 2012. > >> If you have additional things that you want to discuss, or something is > >> wrong or incomplete in this list, please let me know so I can update the > >> list. > > > > Thank you Hans for taking care of the agenda. > > > >> - Explain current merging process (Mauro) > >> - Open floor for discussions on how to improve it (Mauro) > >> - Write down minimum requirements for new V4L2 (and DVB?) drivers, both > >> for > >> > >> staging and mainline acceptance: which frameworks to use, > >> v4l2-compliance, > >> > >> etc. (Hans Verkuil) > >> - V4L2 ambiguities (Hans Verkuil) > >> - TSMux device (a mux rather than a demux): Alain Volmat > >> - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) > >> - Device tree support (Guennadi, not known yet whether this topic is > >> needed) - Creating/selecting contexts for hardware that supports this > >> (Samsung, only if time is available) > > > > This last topic will likely require lots of brainstorming, and thus time. > > If the schedule permits, would anyone be interested in meeting earlier > > during the week already ? > > My intention was to also possibly discuss it with others before the actual > media workshop. Would be nice if we could have arranged such a meeting. > I'm not sure about the room conditions though. It's probably not a big > issue, unless there is really many people interested in that topic. A small room with a projector would be nice if possible, although not required. Who would be interested in attending a brainstorming session on contexts ? -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-22 11:18 ` Laurent Pinchart @ 2012-10-22 12:06 ` Hans Verkuil 2012-10-23 1:03 ` Laurent Pinchart 2012-10-22 21:13 ` Guennadi Liakhovetski 1 sibling, 1 reply; 41+ messages in thread From: Hans Verkuil @ 2012-10-22 12:06 UTC (permalink / raw) To: Laurent Pinchart; +Cc: Sylwester Nawrocki, media-workshop, linux-media On Mon October 22 2012 13:18:46 Laurent Pinchart wrote: > Hi Sylwester, > > On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote: > > On 10/22/2012 12:39 PM, Laurent Pinchart wrote: > > > On Monday 22 October 2012 10:35:56 Hans Verkuil wrote: > > >> Hi all, > > >> > > >> This is the tentative agenda for the media workshop on November 8, 2012. > > >> If you have additional things that you want to discuss, or something is > > >> wrong or incomplete in this list, please let me know so I can update the > > >> list. > > > > > > Thank you Hans for taking care of the agenda. > > > > > >> - Explain current merging process (Mauro) > > >> - Open floor for discussions on how to improve it (Mauro) > > >> - Write down minimum requirements for new V4L2 (and DVB?) drivers, both > > >> for > > >> > > >> staging and mainline acceptance: which frameworks to use, > > >> v4l2-compliance, > > >> > > >> etc. (Hans Verkuil) > > >> - V4L2 ambiguities (Hans Verkuil) > > >> - TSMux device (a mux rather than a demux): Alain Volmat > > >> - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) > > >> - Device tree support (Guennadi, not known yet whether this topic is > > >> needed) - Creating/selecting contexts for hardware that supports this > > >> (Samsung, only if time is available) > > > > > > This last topic will likely require lots of brainstorming, and thus time. > > > If the schedule permits, would anyone be interested in meeting earlier > > > during the week already ? > > > > My intention was to also possibly discuss it with others before the actual > > media workshop. Would be nice if we could have arranged such a meeting. > > I'm not sure about the room conditions though. It's probably not a big > > issue, unless there is really many people interested in that topic. > > A small room with a projector would be nice if possible, although not > required. Who would be interested in attending a brainstorming session on > contexts ? I would be, but the problem is that the conference is also interesting. The only day I have really available is the Friday *after* the summit. Regards, Hans ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-22 12:06 ` Hans Verkuil @ 2012-10-23 1:03 ` Laurent Pinchart 2012-10-23 6:46 ` Hans Verkuil 0 siblings, 1 reply; 41+ messages in thread From: Laurent Pinchart @ 2012-10-23 1:03 UTC (permalink / raw) To: Hans Verkuil; +Cc: Sylwester Nawrocki, media-workshop, linux-media On Monday 22 October 2012 14:06:06 Hans Verkuil wrote: > On Mon October 22 2012 13:18:46 Laurent Pinchart wrote: > > On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote: > > > On 10/22/2012 12:39 PM, Laurent Pinchart wrote: > > > > On Monday 22 October 2012 10:35:56 Hans Verkuil wrote: > > > >> Hi all, > > > >> > > > >> This is the tentative agenda for the media workshop on November 8, > > > >> 2012. If you have additional things that you want to discuss, or > > > >> something is wrong or incomplete in this list, please let me know so > > > >> I can update the list. > > > > > > > > Thank you Hans for taking care of the agenda. > > > > > > > >> - Explain current merging process (Mauro) > > > >> - Open floor for discussions on how to improve it (Mauro) > > > >> - Write down minimum requirements for new V4L2 (and DVB?) drivers, > > > >> both for staging and mainline acceptance: which frameworks to use, > > > >> v4l2-compliance, > > > >> > > > >> etc. (Hans Verkuil) > > > >> - V4L2 ambiguities (Hans Verkuil) > > > >> - TSMux device (a mux rather than a demux): Alain Volmat > > > >> - dmabuf status, esp. with regards to being able to test > > > >> (Mauro/Samsung) > > > >> - Device tree support (Guennadi, not known yet whether this topic is > > > >> needed) - Creating/selecting contexts for hardware that supports this > > > >> (Samsung, only if time is available) > > > > > > > > This last topic will likely require lots of brainstorming, and thus > > > > time. If the schedule permits, would anyone be interested in meeting > > > > earlier during the week already ? > > > > > > My intention was to also possibly discuss it with others before the > > > actual media workshop. Would be nice if we could have arranged such a > > > meeting. I'm not sure about the room conditions though. It's probably > > > not a big issue, unless there is really many people interested in that > > > topic. > > > > A small room with a projector would be nice if possible, although not > > required. Who would be interested in attending a brainstorming session on > > contexts ? > > I would be, but the problem is that the conference is also interesting. More interesting than a brainstorming session about hardware contexts ? ;-) There's of course talks I want to attend, but I can probably skip some of them. > The only day I have really available is the Friday *after* the summit. We'll probably need several brainstorming sessions anyway. I'd like to organize one before the media summit though, as we'll have limited time to discuss the topic during the summit, which doesn't suit brainstorming sessions very well. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-23 1:03 ` Laurent Pinchart @ 2012-10-23 6:46 ` Hans Verkuil 2012-10-23 10:22 ` Laurent Pinchart 0 siblings, 1 reply; 41+ messages in thread From: Hans Verkuil @ 2012-10-23 6:46 UTC (permalink / raw) To: Laurent Pinchart; +Cc: Sylwester Nawrocki, media-workshop, linux-media On Tue October 23 2012 03:03:35 Laurent Pinchart wrote: > On Monday 22 October 2012 14:06:06 Hans Verkuil wrote: > > On Mon October 22 2012 13:18:46 Laurent Pinchart wrote: > > > On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote: > > > > On 10/22/2012 12:39 PM, Laurent Pinchart wrote: > > > > > On Monday 22 October 2012 10:35:56 Hans Verkuil wrote: > > > > >> Hi all, > > > > >> > > > > >> This is the tentative agenda for the media workshop on November 8, > > > > >> 2012. If you have additional things that you want to discuss, or > > > > >> something is wrong or incomplete in this list, please let me know so > > > > >> I can update the list. > > > > > > > > > > Thank you Hans for taking care of the agenda. > > > > > > > > > >> - Explain current merging process (Mauro) > > > > >> - Open floor for discussions on how to improve it (Mauro) > > > > >> - Write down minimum requirements for new V4L2 (and DVB?) drivers, > > > > >> both for staging and mainline acceptance: which frameworks to use, > > > > >> v4l2-compliance, > > > > >> > > > > >> etc. (Hans Verkuil) > > > > >> - V4L2 ambiguities (Hans Verkuil) > > > > >> - TSMux device (a mux rather than a demux): Alain Volmat > > > > >> - dmabuf status, esp. with regards to being able to test > > > > >> (Mauro/Samsung) > > > > >> - Device tree support (Guennadi, not known yet whether this topic is > > > > >> needed) - Creating/selecting contexts for hardware that supports this > > > > >> (Samsung, only if time is available) > > > > > > > > > > This last topic will likely require lots of brainstorming, and thus > > > > > time. If the schedule permits, would anyone be interested in meeting > > > > > earlier during the week already ? > > > > > > > > My intention was to also possibly discuss it with others before the > > > > actual media workshop. Would be nice if we could have arranged such a > > > > meeting. I'm not sure about the room conditions though. It's probably > > > > not a big issue, unless there is really many people interested in that > > > > topic. > > > > > > A small room with a projector would be nice if possible, although not > > > required. Who would be interested in attending a brainstorming session on > > > contexts ? > > > > I would be, but the problem is that the conference is also interesting. > > More interesting than a brainstorming session about hardware contexts ? ;-) > There's of course talks I want to attend, but I can probably skip some of > them. > > > The only day I have really available is the Friday *after* the summit. > > We'll probably need several brainstorming sessions anyway. I'd like to > organize one before the media summit though, as we'll have limited time to > discuss the topic during the summit, which doesn't suit brainstorming sessions > very well. Sylwester, would Samsung be able to prepare for a brainstorming session on Monday or Tuesday? Both Laurent and myself have presentations on Wednesday, so that's not the best day for such a session. Do you think we should do a half-day or a full day session on this? Regards, Hans ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-23 6:46 ` Hans Verkuil @ 2012-10-23 10:22 ` Laurent Pinchart 2012-10-23 11:59 ` Sylwester Nawrocki 0 siblings, 1 reply; 41+ messages in thread From: Laurent Pinchart @ 2012-10-23 10:22 UTC (permalink / raw) To: Hans Verkuil; +Cc: Sylwester Nawrocki, media-workshop, linux-media Hi Hans, On Tuesday 23 October 2012 08:46:21 Hans Verkuil wrote: > On Tue October 23 2012 03:03:35 Laurent Pinchart wrote: > > On Monday 22 October 2012 14:06:06 Hans Verkuil wrote: > > > On Mon October 22 2012 13:18:46 Laurent Pinchart wrote: > > > > On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote: > > > > > On 10/22/2012 12:39 PM, Laurent Pinchart wrote: > > > > > > On Monday 22 October 2012 10:35:56 Hans Verkuil wrote: > > > > > >> Hi all, > > > > > >> > > > > > >> This is the tentative agenda for the media workshop on November > > > > > >> 8, 2012. If you have additional things that you want to discuss, > > > > > >> or something is wrong or incomplete in this list, please let me > > > > > >> know so I can update the list. > > > > > > > > > > > > Thank you Hans for taking care of the agenda. > > > > > > > > > > > >> - Explain current merging process (Mauro) > > > > > >> - Open floor for discussions on how to improve it (Mauro) > > > > > >> - Write down minimum requirements for new V4L2 (and DVB?) > > > > > >> drivers, both for staging and mainline acceptance: which > > > > > >> frameworks to use, v4l2-compliance, etc. (Hans Verkuil) > > > > > >> - V4L2 ambiguities (Hans Verkuil) > > > > > >> - TSMux device (a mux rather than a demux): Alain Volmat > > > > > >> - dmabuf status, esp. with regards to being able to test > > > > > >> (Mauro/Samsung) > > > > > >> - Device tree support (Guennadi, not known yet whether this topic > > > > > >> is needed) - Creating/selecting contexts for hardware that > > > > > >> supports this (Samsung, only if time is available) > > > > > > > > > > > > This last topic will likely require lots of brainstorming, and > > > > > > thus time. If the schedule permits, would anyone be interested in > > > > > > meeting earlier during the week already ? > > > > > > > > > > My intention was to also possibly discuss it with others before the > > > > > actual media workshop. Would be nice if we could have arranged such > > > > > a meeting. I'm not sure about the room conditions though. It's > > > > > probably not a big issue, unless there is really many people > > > > > interested in that topic. > > > > > > > > A small room with a projector would be nice if possible, although not > > > > required. Who would be interested in attending a brainstorming session > > > > on contexts ? > > > > > > I would be, but the problem is that the conference is also interesting. > > > > More interesting than a brainstorming session about hardware contexts ? > > ;-) There's of course talks I want to attend, but I can probably skip some > > of them. > > > > > The only day I have really available is the Friday *after* the summit. > > > > We'll probably need several brainstorming sessions anyway. I'd like to > > organize one before the media summit though, as we'll have limited time to > > discuss the topic during the summit, which doesn't suit brainstorming > > sessions very well. > > Sylwester, would Samsung be able to prepare for a brainstorming session on > Monday or Tuesday? Both Laurent and myself have presentations on Wednesday, > so that's not the best day for such a session. > > Do you think we should do a half-day or a full day session on this? Half a day should be more than enough to start with. The topic is quite complex, and we'll need to sleep over it, several times. A full day would just result in brain overheat. I was thinking more in the line of starting our thought process, so maybe twice an hour or two hours would be good. That would allow us to attend the ELCE talks as well :-) (there's definitely a couple of them that I would like to listen to). -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-23 10:22 ` Laurent Pinchart @ 2012-10-23 11:59 ` Sylwester Nawrocki 2012-10-24 22:42 ` Laurent Pinchart 0 siblings, 1 reply; 41+ messages in thread From: Sylwester Nawrocki @ 2012-10-23 11:59 UTC (permalink / raw) To: Laurent Pinchart; +Cc: Hans Verkuil, media-workshop, linux-media Hi Hans, Laurent, On 10/23/2012 12:22 PM, Laurent Pinchart wrote: > On Tuesday 23 October 2012 08:46:21 Hans Verkuil wrote: >> On Tue October 23 2012 03:03:35 Laurent Pinchart wrote: >>> On Monday 22 October 2012 14:06:06 Hans Verkuil wrote: >>>> On Mon October 22 2012 13:18:46 Laurent Pinchart wrote: >>>>> On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote: >>>>>> On 10/22/2012 12:39 PM, Laurent Pinchart wrote: >>>>>>> On Monday 22 October 2012 10:35:56 Hans Verkuil wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> This is the tentative agenda for the media workshop on November >>>>>>>> 8, 2012. If you have additional things that you want to discuss, >>>>>>>> or something is wrong or incomplete in this list, please let me >>>>>>>> know so I can update the list. >>>>>>> >>>>>>> Thank you Hans for taking care of the agenda. >>>>>>> >>>>>>>> - Explain current merging process (Mauro) >>>>>>>> - Open floor for discussions on how to improve it (Mauro) >>>>>>>> - Write down minimum requirements for new V4L2 (and DVB?) >>>>>>>> drivers, both for staging and mainline acceptance: which >>>>>>>> frameworks to use, v4l2-compliance, etc. (Hans Verkuil) >>>>>>>> - V4L2 ambiguities (Hans Verkuil) >>>>>>>> - TSMux device (a mux rather than a demux): Alain Volmat >>>>>>>> - dmabuf status, esp. with regards to being able to test >>>>>>>> (Mauro/Samsung) >>>>>>>> - Device tree support (Guennadi, not known yet whether this topic >>>>>>>> is needed) - Creating/selecting contexts for hardware that >>>>>>>> supports this (Samsung, only if time is available) >>>>>>> >>>>>>> This last topic will likely require lots of brainstorming, and >>>>>>> thus time. If the schedule permits, would anyone be interested in >>>>>>> meeting earlier during the week already ? >>>>>> >>>>>> My intention was to also possibly discuss it with others before the >>>>>> actual media workshop. Would be nice if we could have arranged such >>>>>> a meeting. I'm not sure about the room conditions though. It's >>>>>> probably not a big issue, unless there is really many people >>>>>> interested in that topic. >>>>> >>>>> A small room with a projector would be nice if possible, although not >>>>> required. Who would be interested in attending a brainstorming session >>>>> on contexts ? >>>> >>>> I would be, but the problem is that the conference is also interesting. >>> >>> More interesting than a brainstorming session about hardware contexts ? >>> ;-) There's of course talks I want to attend, but I can probably skip some >>> of them. >>> >>>> The only day I have really available is the Friday *after* the summit. >>> >>> We'll probably need several brainstorming sessions anyway. I'd like to >>> organize one before the media summit though, as we'll have limited time to >>> discuss the topic during the summit, which doesn't suit brainstorming >>> sessions very well. >> >> Sylwester, would Samsung be able to prepare for a brainstorming session on >> Monday or Tuesday? Both Laurent and myself have presentations on Wednesday, >> so that's not the best day for such a session. Kamil has presentation on Tuesday so there would be only Monday left. >> Do you think we should do a half-day or a full day session on this? > > Half a day should be more than enough to start with. The topic is quite > complex, and we'll need to sleep over it, several times. A full day would just > result in brain overheat. I was thinking more in the line of starting our > thought process, so maybe twice an hour or two hours would be good. That would > allow us to attend the ELCE talks as well :-) (there's definitely a couple of > them that I would like to listen to). I agree, I wouldn't like to loose whole day of the conference for that as well. One, two hours for the starters could be sufficient. So we can possibly agree on some initial idea and could get back to it later. I don't think I have already material for a full day session. -- Regards, Sylwester ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-23 11:59 ` Sylwester Nawrocki @ 2012-10-24 22:42 ` Laurent Pinchart 2012-10-25 8:43 ` Sylwester Nawrocki 0 siblings, 1 reply; 41+ messages in thread From: Laurent Pinchart @ 2012-10-24 22:42 UTC (permalink / raw) To: Sylwester Nawrocki; +Cc: Hans Verkuil, media-workshop, linux-media Hi Sylwester, On Tuesday 23 October 2012 13:59:01 Sylwester Nawrocki wrote: > On 10/23/2012 12:22 PM, Laurent Pinchart wrote: > > On Tuesday 23 October 2012 08:46:21 Hans Verkuil wrote: > >> On Tue October 23 2012 03:03:35 Laurent Pinchart wrote: > >>> On Monday 22 October 2012 14:06:06 Hans Verkuil wrote: > >>>> On Mon October 22 2012 13:18:46 Laurent Pinchart wrote: > >>>>> On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote: > >>>>>> On 10/22/2012 12:39 PM, Laurent Pinchart wrote: > >>>>>>> On Monday 22 October 2012 10:35:56 Hans Verkuil wrote: > >>>>>>>> Hi all, > >>>>>>>> > >>>>>>>> This is the tentative agenda for the media workshop on November > >>>>>>>> 8, 2012. If you have additional things that you want to discuss, > >>>>>>>> or something is wrong or incomplete in this list, please let me > >>>>>>>> know so I can update the list. > >>>>>>> > >>>>>>> Thank you Hans for taking care of the agenda. > >>>>>>> > >>>>>>>> - Explain current merging process (Mauro) > >>>>>>>> - Open floor for discussions on how to improve it (Mauro) > >>>>>>>> - Write down minimum requirements for new V4L2 (and DVB?) > >>>>>>>> > >>>>>>>> drivers, both for staging and mainline acceptance: which > >>>>>>>> frameworks to use, v4l2-compliance, etc. (Hans Verkuil) > >>>>>>>> > >>>>>>>> - V4L2 ambiguities (Hans Verkuil) > >>>>>>>> - TSMux device (a mux rather than a demux): Alain Volmat > >>>>>>>> - dmabuf status, esp. with regards to being able to test > >>>>>>>> > >>>>>>>> (Mauro/Samsung) > >>>>>>>> > >>>>>>>> - Device tree support (Guennadi, not known yet whether this topic > >>>>>>>> > >>>>>>>> is needed) - Creating/selecting contexts for hardware that > >>>>>>>> supports this (Samsung, only if time is available) > >>>>>>> > >>>>>>> This last topic will likely require lots of brainstorming, and > >>>>>>> thus time. If the schedule permits, would anyone be interested in > >>>>>>> meeting earlier during the week already ? > >>>>>> > >>>>>> My intention was to also possibly discuss it with others before the > >>>>>> actual media workshop. Would be nice if we could have arranged such > >>>>>> a meeting. I'm not sure about the room conditions though. It's > >>>>>> probably not a big issue, unless there is really many people > >>>>>> interested in that topic. > >>>>> > >>>>> A small room with a projector would be nice if possible, although not > >>>>> required. Who would be interested in attending a brainstorming session > >>>>> on contexts ? > >>>> > >>>> I would be, but the problem is that the conference is also interesting. > >>> > >>> More interesting than a brainstorming session about hardware contexts ? > >>> ;-) There's of course talks I want to attend, but I can probably skip > >>> some of them. > >>> > >>>> The only day I have really available is the Friday *after* the summit. > >>> > >>> We'll probably need several brainstorming sessions anyway. I'd like to > >>> organize one before the media summit though, as we'll have limited time > >>> to discuss the topic during the summit, which doesn't suit brainstorming > >>> sessions very well. > >> > >> Sylwester, would Samsung be able to prepare for a brainstorming session > >> on Monday or Tuesday? Both Laurent and myself have presentations on > >> Wednesday, so that's not the best day for such a session. > > Kamil has presentation on Tuesday so there would be only Monday left. > > >> Do you think we should do a half-day or a full day session on this? > > > > Half a day should be more than enough to start with. The topic is quite > > complex, and we'll need to sleep over it, several times. A full day would > > just result in brain overheat. I was thinking more in the line of > > starting our thought process, so maybe twice an hour or two hours would > > be good. That would allow us to attend the ELCE talks as well :-) > > (there's definitely a couple of them that I would like to listen to). > > I agree, I wouldn't like to loose whole day of the conference for that > as well. One, two hours for the starters could be sufficient. So we can > possibly agree on some initial idea and could get back to it later. > I don't think I have already material for a full day session. One hour, possibly twice, would have my preference. That shouldn't be too difficult to organize. When will you and Kamil arrive ? -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-24 22:42 ` Laurent Pinchart @ 2012-10-25 8:43 ` Sylwester Nawrocki 2012-10-25 8:52 ` Hans Verkuil 0 siblings, 1 reply; 41+ messages in thread From: Sylwester Nawrocki @ 2012-10-25 8:43 UTC (permalink / raw) To: Laurent Pinchart; +Cc: Hans Verkuil, media-workshop, linux-media Hi Laurent, On 10/25/2012 12:42 AM, Laurent Pinchart wrote: >>>> Sylwester, would Samsung be able to prepare for a brainstorming session >>>> on Monday or Tuesday? Both Laurent and myself have presentations on >>>> Wednesday, so that's not the best day for such a session. >> >> Kamil has presentation on Tuesday so there would be only Monday left. >> >>>> Do you think we should do a half-day or a full day session on this? >>> >>> Half a day should be more than enough to start with. The topic is quite >>> complex, and we'll need to sleep over it, several times. A full day would >>> just result in brain overheat. I was thinking more in the line of >>> starting our thought process, so maybe twice an hour or two hours would >>> be good. That would allow us to attend the ELCE talks as well :-) >>> (there's definitely a couple of them that I would like to listen to). >> >> I agree, I wouldn't like to loose whole day of the conference for that >> as well. One, two hours for the starters could be sufficient. So we can >> possibly agree on some initial idea and could get back to it later. >> I don't think I have already material for a full day session. > > One hour, possibly twice, would have my preference. That shouldn't be too > difficult to organize. When will you and Kamil arrive ? Sounds good to me. We'll arrive on Sunday afternoon, and staying until next Sunday. -- Regards, Sylwester ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-25 8:43 ` Sylwester Nawrocki @ 2012-10-25 8:52 ` Hans Verkuil 0 siblings, 0 replies; 41+ messages in thread From: Hans Verkuil @ 2012-10-25 8:52 UTC (permalink / raw) To: Sylwester Nawrocki; +Cc: Laurent Pinchart, media-workshop, linux-media On Thu October 25 2012 10:43:59 Sylwester Nawrocki wrote: > Hi Laurent, > > On 10/25/2012 12:42 AM, Laurent Pinchart wrote: > >>>> Sylwester, would Samsung be able to prepare for a brainstorming session > >>>> on Monday or Tuesday? Both Laurent and myself have presentations on > >>>> Wednesday, so that's not the best day for such a session. > >> > >> Kamil has presentation on Tuesday so there would be only Monday left. > >> > >>>> Do you think we should do a half-day or a full day session on this? > >>> > >>> Half a day should be more than enough to start with. The topic is quite > >>> complex, and we'll need to sleep over it, several times. A full day would > >>> just result in brain overheat. I was thinking more in the line of > >>> starting our thought process, so maybe twice an hour or two hours would > >>> be good. That would allow us to attend the ELCE talks as well :-) > >>> (there's definitely a couple of them that I would like to listen to). > >> > >> I agree, I wouldn't like to loose whole day of the conference for that > >> as well. One, two hours for the starters could be sufficient. So we can > >> possibly agree on some initial idea and could get back to it later. > >> I don't think I have already material for a full day session. > > > > One hour, possibly twice, would have my preference. That shouldn't be too > > difficult to organize. When will you and Kamil arrive ? > > Sounds good to me. We'll arrive on Sunday afternoon, and staying until > next Sunday. I've tried to get a small room for Monday, but they were all gone, so we will have to find some other place in the hotel. Regards, Hans ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-22 11:18 ` Laurent Pinchart 2012-10-22 12:06 ` Hans Verkuil @ 2012-10-22 21:13 ` Guennadi Liakhovetski 1 sibling, 0 replies; 41+ messages in thread From: Guennadi Liakhovetski @ 2012-10-22 21:13 UTC (permalink / raw) To: Laurent Pinchart; +Cc: Sylwester Nawrocki, media-workshop, linux-media Hi Laurent On Mon, 22 Oct 2012, Laurent Pinchart wrote: > Hi Sylwester, > > On Monday 22 October 2012 12:53:02 Sylwester Nawrocki wrote: > > On 10/22/2012 12:39 PM, Laurent Pinchart wrote: > > > On Monday 22 October 2012 10:35:56 Hans Verkuil wrote: > > >> Hi all, > > >> > > >> This is the tentative agenda for the media workshop on November 8, 2012. > > >> If you have additional things that you want to discuss, or something is > > >> wrong or incomplete in this list, please let me know so I can update the > > >> list. > > > > > > Thank you Hans for taking care of the agenda. > > > > > >> - Explain current merging process (Mauro) > > >> - Open floor for discussions on how to improve it (Mauro) > > >> - Write down minimum requirements for new V4L2 (and DVB?) drivers, both > > >> for > > >> > > >> staging and mainline acceptance: which frameworks to use, > > >> v4l2-compliance, > > >> > > >> etc. (Hans Verkuil) > > >> - V4L2 ambiguities (Hans Verkuil) > > >> - TSMux device (a mux rather than a demux): Alain Volmat > > >> - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) > > >> - Device tree support (Guennadi, not known yet whether this topic is > > >> needed) - Creating/selecting contexts for hardware that supports this > > >> (Samsung, only if time is available) > > > > > > This last topic will likely require lots of brainstorming, and thus time. > > > If the schedule permits, would anyone be interested in meeting earlier > > > during the week already ? > > > > My intention was to also possibly discuss it with others before the actual > > media workshop. Would be nice if we could have arranged such a meeting. > > I'm not sure about the room conditions though. It's probably not a big > > issue, unless there is really many people interested in that topic. > > A small room with a projector would be nice if possible, although not > required. Who would be interested in attending a brainstorming session on > contexts ? I'd also be interested to participate. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-22 8:35 Tentative Agenda for the November workshop Hans Verkuil 2012-10-22 10:39 ` [media-workshop] " Laurent Pinchart @ 2012-10-22 21:14 ` Guennadi Liakhovetski 2012-10-31 13:12 ` Guennadi Liakhovetski 2012-10-25 17:27 ` Mauro Carvalho Chehab 2 siblings, 1 reply; 41+ messages in thread From: Guennadi Liakhovetski @ 2012-10-22 21:14 UTC (permalink / raw) To: Hans Verkuil; +Cc: media-workshop, linux-media On Mon, 22 Oct 2012, Hans Verkuil wrote: > Hi all, > > This is the tentative agenda for the media workshop on November 8, 2012. > If you have additional things that you want to discuss, or something is wrong > or incomplete in this list, please let me know so I can update the list. > > - Explain current merging process (Mauro) > - Open floor for discussions on how to improve it (Mauro) > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for > staging and mainline acceptance: which frameworks to use, v4l2-compliance, > etc. (Hans Verkuil) > - V4L2 ambiguities (Hans Verkuil) > - TSMux device (a mux rather than a demux): Alain Volmat > - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) > - Device tree support (Guennadi, not known yet whether this topic is needed) + asynchronous probing, I guess. It's probably implicitly included though. Thanks Guennadi > - Creating/selecting contexts for hardware that supports this (Samsung, only > if time is available) > > For those whose name is behind a topic: please prepare something before the > meeting. > > We have currently 17 or 18 attendees of a maximum of 25, so there is room > for a few more people. > > Regards, > > Hans > > _______________________________________________ > media-workshop mailing list > media-workshop@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-22 21:14 ` Guennadi Liakhovetski @ 2012-10-31 13:12 ` Guennadi Liakhovetski 2012-11-01 16:01 ` Hans Verkuil 0 siblings, 1 reply; 41+ messages in thread From: Guennadi Liakhovetski @ 2012-10-31 13:12 UTC (permalink / raw) To: Hans Verkuil; +Cc: media-workshop, linux-media Hi all On Mon, 22 Oct 2012, Guennadi Liakhovetski wrote: > On Mon, 22 Oct 2012, Hans Verkuil wrote: > > > Hi all, > > > > This is the tentative agenda for the media workshop on November 8, 2012. > > If you have additional things that you want to discuss, or something is wrong > > or incomplete in this list, please let me know so I can update the list. > > > > - Explain current merging process (Mauro) > > - Open floor for discussions on how to improve it (Mauro) > > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for > > staging and mainline acceptance: which frameworks to use, v4l2-compliance, > > etc. (Hans Verkuil) > > - V4L2 ambiguities (Hans Verkuil) > > - TSMux device (a mux rather than a demux): Alain Volmat > > - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) > > - Device tree support (Guennadi, not known yet whether this topic is needed) > > + asynchronous probing, I guess. It's probably implicitly included though. As the meeting approaches, it would be good to have a decision - do we want to discuss DT / async or not? My flights this time are not quite long enough to prepare for the discussion on them;-) Thanks Guennadi > > - Creating/selecting contexts for hardware that supports this (Samsung, only > > if time is available) > > > > For those whose name is behind a topic: please prepare something before the > > meeting. > > > > We have currently 17 or 18 attendees of a maximum of 25, so there is room > > for a few more people. > > > > Regards, > > > > Hans > > > > _______________________________________________ > > media-workshop mailing list > > media-workshop@linuxtv.org > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop > > > > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-31 13:12 ` Guennadi Liakhovetski @ 2012-11-01 16:01 ` Hans Verkuil 2012-11-01 16:05 ` Laurent Pinchart 0 siblings, 1 reply; 41+ messages in thread From: Hans Verkuil @ 2012-11-01 16:01 UTC (permalink / raw) To: Guennadi Liakhovetski; +Cc: media-workshop, linux-media On Wed October 31 2012 14:12:05 Guennadi Liakhovetski wrote: > Hi all > > On Mon, 22 Oct 2012, Guennadi Liakhovetski wrote: > > > On Mon, 22 Oct 2012, Hans Verkuil wrote: > > > > > Hi all, > > > > > > This is the tentative agenda for the media workshop on November 8, 2012. > > > If you have additional things that you want to discuss, or something is wrong > > > or incomplete in this list, please let me know so I can update the list. > > > > > > - Explain current merging process (Mauro) > > > - Open floor for discussions on how to improve it (Mauro) > > > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for > > > staging and mainline acceptance: which frameworks to use, v4l2-compliance, > > > etc. (Hans Verkuil) > > > - V4L2 ambiguities (Hans Verkuil) > > > - TSMux device (a mux rather than a demux): Alain Volmat > > > - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) > > > - Device tree support (Guennadi, not known yet whether this topic is needed) > > > > + asynchronous probing, I guess. It's probably implicitly included though. > > As the meeting approaches, it would be good to have a decision - do we > want to discuss DT / async or not? My flights this time are not quite long > enough to prepare for the discussion on them;-) Looking at the current discussions I think discussing possible async solutions would be very useful. The DT implementation itself seems to be OK, at least I haven't seen any big discussions regarding that. Regards, Hans ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-01 16:01 ` Hans Verkuil @ 2012-11-01 16:05 ` Laurent Pinchart 2012-11-01 19:01 ` Sylwester Nawrocki 0 siblings, 1 reply; 41+ messages in thread From: Laurent Pinchart @ 2012-11-01 16:05 UTC (permalink / raw) To: media-workshop; +Cc: Hans Verkuil, Guennadi Liakhovetski, linux-media On Thursday 01 November 2012 17:01:02 Hans Verkuil wrote: > On Wed October 31 2012 14:12:05 Guennadi Liakhovetski wrote: > > On Mon, 22 Oct 2012, Guennadi Liakhovetski wrote: > > > On Mon, 22 Oct 2012, Hans Verkuil wrote: > > > > Hi all, > > > > > > > > This is the tentative agenda for the media workshop on November 8, > > > > 2012. If you have additional things that you want to discuss, or > > > > something is wrong or incomplete in this list, please let me know so I > > > > can update the list. > > > > > > > > - Explain current merging process (Mauro) > > > > - Open floor for discussions on how to improve it (Mauro) > > > > - Write down minimum requirements for new V4L2 (and DVB?) drivers, > > > > both for staging and mainline acceptance: which frameworks to use, > > > > v4l2-compliance, etc. (Hans Verkuil) > > > > > > > > - V4L2 ambiguities (Hans Verkuil) > > > > - TSMux device (a mux rather than a demux): Alain Volmat > > > > - dmabuf status, esp. with regards to being able to test > > > > (Mauro/Samsung) > > > > - Device tree support (Guennadi, not known yet whether this topic is > > > > needed) > > > > > > + asynchronous probing, I guess. It's probably implicitly included > > > though. > > > > As the meeting approaches, it would be good to have a decision - do we > > want to discuss DT / async or not? My flights this time are not quite long > > enough to prepare for the discussion on them;-) > > Looking at the current discussions I think discussing possible async > solutions would be very useful. The DT implementation itself seems to be > OK, at least I haven't seen any big discussions regarding that. Agreed. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-01 16:05 ` Laurent Pinchart @ 2012-11-01 19:01 ` Sylwester Nawrocki 0 siblings, 0 replies; 41+ messages in thread From: Sylwester Nawrocki @ 2012-11-01 19:01 UTC (permalink / raw) To: Laurent Pinchart Cc: media-workshop, Hans Verkuil, Guennadi Liakhovetski, linux-media On 11/01/2012 05:05 PM, Laurent Pinchart wrote: > On Thursday 01 November 2012 17:01:02 Hans Verkuil wrote: >> On Wed October 31 2012 14:12:05 Guennadi Liakhovetski wrote: >>> On Mon, 22 Oct 2012, Guennadi Liakhovetski wrote: >>>> On Mon, 22 Oct 2012, Hans Verkuil wrote: >>>>> Hi all, >>>>> >>>>> This is the tentative agenda for the media workshop on November 8, >>>>> 2012. If you have additional things that you want to discuss, or >>>>> something is wrong or incomplete in this list, please let me know so I >>>>> can update the list. >>>>> >>>>> - Explain current merging process (Mauro) >>>>> - Open floor for discussions on how to improve it (Mauro) >>>>> - Write down minimum requirements for new V4L2 (and DVB?) drivers, >>>>> both for staging and mainline acceptance: which frameworks to use, >>>>> v4l2-compliance, etc. (Hans Verkuil) >>>>> >>>>> - V4L2 ambiguities (Hans Verkuil) >>>>> - TSMux device (a mux rather than a demux): Alain Volmat >>>>> - dmabuf status, esp. with regards to being able to test >>>>> (Mauro/Samsung) >>>>> - Device tree support (Guennadi, not known yet whether this topic is >>>>> needed) >>>> >>>> + asynchronous probing, I guess. It's probably implicitly included >>>> though. >>> >>> As the meeting approaches, it would be good to have a decision - do we >>> want to discuss DT / async or not? My flights this time are not quite long >>> enough to prepare for the discussion on them;-) >> >> Looking at the current discussions I think discussing possible async >> solutions would be very useful. The DT implementation itself seems to be >> OK, at least I haven't seen any big discussions regarding that. > > Agreed. That was my impression too, the bindings itself look fine in general. At least basic features of hardware are now covered, the not very common ones might be easily covered later when needed. I did an initial implementation for the s5p-fimc driver, with an I2C/SPI sensor subdev, based on current DT bindings and the (slightly modified) v4l2-of helpers. Relying only on the deferred probing mechanism and not using the notifiers. It's relatively simple and works without that much changes comparing to the previous non-dt version. Still there are possible races when subdevs are loadable modules. However, the non-dt version has also problems in this respect, as I misinterpreted in the past the get_driver()/put_driver() functions [1]. So that needs to get fixed somehow to make the modules usage reliable. -- Regards, Sylwester [1] http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=fde25a9b63b9a3dc91365c394a426ebe64cfc2da ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-22 8:35 Tentative Agenda for the November workshop Hans Verkuil 2012-10-22 10:39 ` [media-workshop] " Laurent Pinchart 2012-10-22 21:14 ` Guennadi Liakhovetski @ 2012-10-25 17:27 ` Mauro Carvalho Chehab 2012-11-01 15:44 ` Hans Verkuil 2 siblings, 1 reply; 41+ messages in thread From: Mauro Carvalho Chehab @ 2012-10-25 17:27 UTC (permalink / raw) To: Hans Verkuil; +Cc: media-workshop, linux-media Hi Hans, Em Mon, 22 Oct 2012 10:35:56 +0200 Hans Verkuil <hverkuil@xs4all.nl> escreveu: > Hi all, > > This is the tentative agenda for the media workshop on November 8, 2012. > If you have additional things that you want to discuss, or something is wrong > or incomplete in this list, please let me know so I can update the list. Thank you for taking care of it. > - Explain current merging process (Mauro) > - Open floor for discussions on how to improve it (Mauro) > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for > staging and mainline acceptance: which frameworks to use, v4l2-compliance, > etc. (Hans Verkuil) > - V4L2 ambiguities (Hans Verkuil) > - TSMux device (a mux rather than a demux): Alain Volmat > - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) > - Device tree support (Guennadi, not known yet whether this topic is needed) > - Creating/selecting contexts for hardware that supports this (Samsung, only > if time is available) I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry. It probably makes sense to mark them as "Orphan" (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them. This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme. There are some issues by not having a MAINTAINERS entry: - patches may not flow into the driver maintainer; - patches will likely be applied without tests/reviews or may stay for a long time queued; - ./scripts/get_maintainer.pl at --no-git-fallback won't return any maintainer[1]. [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would delay a lot the patch review process, if applied for every patch, with unreliable and doubtful results. I don't do it, due to the large volume of patches, and because the 'other' results aren't typically the driver maintainer. An example of this is the results for a patch I just applied (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): $ git show --pretty=email|./scripts/get_maintainer.pl Mauro Carvalho Chehab <mchehab@infradead.org> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%) Hans Verkuil <hans.verkuil@cisco.com> (commit_signer:4/7=57%) Anatolij Gustschin <agust@denx.de> (commit_signer:1/7=14%) Wei Yongjun <yongjun_wei@trendmicro.com.cn> (commit_signer:1/7=14%) Hans de Goede <hdegoede@redhat.com> (commit_signer:1/7=14%) linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) linux-kernel@vger.kernel.org (open list) According with this driver's copyrights: * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. * * Freescale VIU video driver * * Authors: Hongjun Chen <hong-jun.chen@freescale.com> * Porting to 2.6.35 by DENX Software Engineering, * Anatolij Gustschin <agust@denx.de> The driver author (Hongjun Chen <hong-jun.chen@freescale.com>) was not even shown there, and the co-author got only 15% hit, while I got 100% and Hans got 57%. This happens not only to this driver. In a matter of fact, on most cases where no MAINTAINERS entry exist, the driver's author gets a very small hit chance, as, on several of those drivers, the author doesn't post anything else but the initial patch series. Regards, Mauro ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-10-25 17:27 ` Mauro Carvalho Chehab @ 2012-11-01 15:44 ` Hans Verkuil 2012-11-01 16:12 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 41+ messages in thread From: Hans Verkuil @ 2012-11-01 15:44 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: media-workshop, linux-media On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: > Hi Hans, > > Em Mon, 22 Oct 2012 10:35:56 +0200 > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > > > Hi all, > > > > This is the tentative agenda for the media workshop on November 8, 2012. > > If you have additional things that you want to discuss, or something is wrong > > or incomplete in this list, please let me know so I can update the list. > > Thank you for taking care of it. > > > - Explain current merging process (Mauro) > > - Open floor for discussions on how to improve it (Mauro) > > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for > > staging and mainline acceptance: which frameworks to use, v4l2-compliance, > > etc. (Hans Verkuil) > > - V4L2 ambiguities (Hans Verkuil) > > - TSMux device (a mux rather than a demux): Alain Volmat > > - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) > > - Device tree support (Guennadi, not known yet whether this topic is needed) > > - Creating/selecting contexts for hardware that supports this (Samsung, only > > if time is available) > > I have an extra theme for discussions there: what should we do with the drivers > that don't have any MAINTAINERS entry. I've added this topic to the list. > It probably makes sense to mark them as "Orphan" (or, at least, have some > criteria to mark them as such). Perhaps before doing that, we could try > to see if are there any developer at the community with time and patience > to handle them. > > This could of course be handled as part of the discussions about how to improve > the merge process, but I suspect that this could generate enough discussions > to be handled as a separate theme. Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' (since I simply don't have the time for that), I wouldn't mind being marked as someone who can at least test patches if needed. > There are some issues by not having a MAINTAINERS entry: > - patches may not flow into the driver maintainer; > - patches will likely be applied without tests/reviews or may > stay for a long time queued; > - ./scripts/get_maintainer.pl at --no-git-fallback won't return > any maintainer[1]. > > [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would > delay a lot the patch review process, if applied for every patch, with > unreliable and doubtful results. I don't do it, due to the large volume > of patches, and because the 'other' results aren't typically the driver > maintainer. > > An example of this is the results for a patch I just applied > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): > > $ git show --pretty=email|./scripts/get_maintainer.pl > Mauro Carvalho Chehab <mchehab@infradead.org> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%) > Hans Verkuil <hans.verkuil@cisco.com> (commit_signer:4/7=57%) > Anatolij Gustschin <agust@denx.de> (commit_signer:1/7=14%) > Wei Yongjun <yongjun_wei@trendmicro.com.cn> (commit_signer:1/7=14%) > Hans de Goede <hdegoede@redhat.com> (commit_signer:1/7=14%) > linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) > linux-kernel@vger.kernel.org (open list) > > According with this driver's copyrights: > > * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. > * > * Freescale VIU video driver > * > * Authors: Hongjun Chen <hong-jun.chen@freescale.com> > * Porting to 2.6.35 by DENX Software Engineering, > * Anatolij Gustschin <agust@denx.de> > > The driver author (Hongjun Chen <hong-jun.chen@freescale.com>) was not even > shown there, and the co-author got only 15% hit, while I got 100% and Hans > got 57%. > > This happens not only to this driver. In a matter of fact, on most cases where > no MAINTAINERS entry exist, the driver's author gets a very small hit chance, > as, on several of those drivers, the author doesn't post anything else but > the initial patch series. We probably need to have an entry for all the media drivers, even if it just points to the linux-media mailinglist as being the 'collective default maintainer'. A MAINTAINERS entry should probably be required as well for new drivers. Regards, Hans ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-01 15:44 ` Hans Verkuil @ 2012-11-01 16:12 ` Mauro Carvalho Chehab 2012-11-02 13:13 ` drivers without explicit MAINTAINERS entry - was: " Mauro Carvalho Chehab 0 siblings, 1 reply; 41+ messages in thread From: Mauro Carvalho Chehab @ 2012-11-01 16:12 UTC (permalink / raw) To: Hans Verkuil; +Cc: media-workshop, linux-media Em Thu, 1 Nov 2012 16:44:50 +0100 Hans Verkuil <hverkuil@xs4all.nl> escreveu: > On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: > > Hi Hans, > > > > Em Mon, 22 Oct 2012 10:35:56 +0200 > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > > > > > Hi all, > > > > > > This is the tentative agenda for the media workshop on November 8, 2012. > > > If you have additional things that you want to discuss, or something is wrong > > > or incomplete in this list, please let me know so I can update the list. > > > > Thank you for taking care of it. > > > > > - Explain current merging process (Mauro) > > > - Open floor for discussions on how to improve it (Mauro) > > > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for > > > staging and mainline acceptance: which frameworks to use, v4l2-compliance, > > > etc. (Hans Verkuil) > > > - V4L2 ambiguities (Hans Verkuil) > > > - TSMux device (a mux rather than a demux): Alain Volmat > > > - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) > > > - Device tree support (Guennadi, not known yet whether this topic is needed) > > > - Creating/selecting contexts for hardware that supports this (Samsung, only > > > if time is available) > > > > I have an extra theme for discussions there: what should we do with the drivers > > that don't have any MAINTAINERS entry. > > I've added this topic to the list. Thanks! > > It probably makes sense to mark them as "Orphan" (or, at least, have some > > criteria to mark them as such). Perhaps before doing that, we could try > > to see if are there any developer at the community with time and patience > > to handle them. > > > > This could of course be handled as part of the discussions about how to improve > > the merge process, but I suspect that this could generate enough discussions > > to be handled as a separate theme. > > Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can > test. So while I wouldn't like to be marked as 'The Maintainer of driver X' > (since I simply don't have the time for that), I wouldn't mind being marked as > someone who can at least test patches if needed. There are several "maintainance" status there: S: Status, one of the following: Supported: Someone is actually paid to look after this. Maintained: Someone actually looks after it. Odd Fixes: It has a maintainer but they don't have time to do much other than throw the odd patch in. See below.. Orphan: No current maintainer [but maybe you could take the role as you write your new code]. Obsolete: Old code. Something tagged obsolete generally means it has been replaced by a better system and you should be using that. (btw, I just realized that I should be changing the EDAC drivers I maintain to Supported; the media drivers I maintain should be kept as Maintained). I suspect that the "maintainer-light" category for those radio and similar old stuff is likely "Odd Fixes". > > There are some issues by not having a MAINTAINERS entry: > > - patches may not flow into the driver maintainer; > > - patches will likely be applied without tests/reviews or may > > stay for a long time queued; > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return > > any maintainer[1]. > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would > > delay a lot the patch review process, if applied for every patch, with > > unreliable and doubtful results. I don't do it, due to the large volume > > of patches, and because the 'other' results aren't typically the driver > > maintainer. > > > > An example of this is the results for a patch I just applied > > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): > > > > $ git show --pretty=email|./scripts/get_maintainer.pl > > Mauro Carvalho Chehab <mchehab@infradead.org> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%) > > Hans Verkuil <hans.verkuil@cisco.com> (commit_signer:4/7=57%) > > Anatolij Gustschin <agust@denx.de> (commit_signer:1/7=14%) > > Wei Yongjun <yongjun_wei@trendmicro.com.cn> (commit_signer:1/7=14%) > > Hans de Goede <hdegoede@redhat.com> (commit_signer:1/7=14%) > > linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) > > linux-kernel@vger.kernel.org (open list) > > > > According with this driver's copyrights: > > > > * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. > > * > > * Freescale VIU video driver > > * > > * Authors: Hongjun Chen <hong-jun.chen@freescale.com> > > * Porting to 2.6.35 by DENX Software Engineering, > > * Anatolij Gustschin <agust@denx.de> > > > > The driver author (Hongjun Chen <hong-jun.chen@freescale.com>) was not even > > shown there, and the co-author got only 15% hit, while I got 100% and Hans > > got 57%. > > > > This happens not only to this driver. In a matter of fact, on most cases where > > no MAINTAINERS entry exist, the driver's author gets a very small hit chance, > > as, on several of those drivers, the author doesn't post anything else but > > the initial patch series. > > We probably need to have an entry for all the media drivers, even if it just > points to the linux-media mailinglist as being the 'collective default maintainer'. Yes, I think that all media drivers should be there. I prefer to tag the ones that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates that help is wanted. > > A MAINTAINERS entry should probably be required as well for new drivers. Agreed. Regards, Mauro ^ permalink raw reply [flat|nested] 41+ messages in thread
* drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-01 16:12 ` Mauro Carvalho Chehab @ 2012-11-02 13:13 ` Mauro Carvalho Chehab 2012-11-02 13:47 ` Hans Verkuil ` (3 more replies) 0 siblings, 4 replies; 41+ messages in thread From: Mauro Carvalho Chehab @ 2012-11-02 13:13 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Hans Verkuil, media-workshop, linux-media Em Thu, 1 Nov 2012 14:12:44 -0200 Mauro Carvalho Chehab <mchehab@redhat.com> escreveu: > Em Thu, 1 Nov 2012 16:44:50 +0100 > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > > > On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: > > > Hi Hans, > > > > > > Em Mon, 22 Oct 2012 10:35:56 +0200 > > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > > > > > > > Hi all, > > > > > > > > This is the tentative agenda for the media workshop on November 8, 2012. > > > > If you have additional things that you want to discuss, or something is wrong > > > > or incomplete in this list, please let me know so I can update the list. > > > > > > Thank you for taking care of it. > > > > > > > - Explain current merging process (Mauro) > > > > - Open floor for discussions on how to improve it (Mauro) > > > > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for > > > > staging and mainline acceptance: which frameworks to use, v4l2-compliance, > > > > etc. (Hans Verkuil) > > > > - V4L2 ambiguities (Hans Verkuil) > > > > - TSMux device (a mux rather than a demux): Alain Volmat > > > > - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) > > > > - Device tree support (Guennadi, not known yet whether this topic is needed) > > > > - Creating/selecting contexts for hardware that supports this (Samsung, only > > > > if time is available) > > > > > > I have an extra theme for discussions there: what should we do with the drivers > > > that don't have any MAINTAINERS entry. > > > > I've added this topic to the list. > > Thanks! > > > > It probably makes sense to mark them as "Orphan" (or, at least, have some > > > criteria to mark them as such). Perhaps before doing that, we could try > > > to see if are there any developer at the community with time and patience > > > to handle them. > > > > > > This could of course be handled as part of the discussions about how to improve > > > the merge process, but I suspect that this could generate enough discussions > > > to be handled as a separate theme. > > > > Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can > > test. So while I wouldn't like to be marked as 'The Maintainer of driver X' > > (since I simply don't have the time for that), I wouldn't mind being marked as > > someone who can at least test patches if needed. > > There are several "maintainance" status there: > > S: Status, one of the following: > Supported: Someone is actually paid to look after this. > Maintained: Someone actually looks after it. > Odd Fixes: It has a maintainer but they don't have time to do > much other than throw the odd patch in. See below.. > Orphan: No current maintainer [but maybe you could take the > role as you write your new code]. > Obsolete: Old code. Something tagged obsolete generally means > it has been replaced by a better system and you > should be using that. > > (btw, I just realized that I should be changing the EDAC drivers I maintain > to Supported; the media drivers I maintain should be kept as Maintained). > > I suspect that the "maintainer-light" category for those radio and similar > old stuff is likely "Odd Fixes". > > > > There are some issues by not having a MAINTAINERS entry: > > > - patches may not flow into the driver maintainer; > > > - patches will likely be applied without tests/reviews or may > > > stay for a long time queued; > > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return > > > any maintainer[1]. > > > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would > > > delay a lot the patch review process, if applied for every patch, with > > > unreliable and doubtful results. I don't do it, due to the large volume > > > of patches, and because the 'other' results aren't typically the driver > > > maintainer. > > > > > > An example of this is the results for a patch I just applied > > > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): > > > > > > $ git show --pretty=email|./scripts/get_maintainer.pl > > > Mauro Carvalho Chehab <mchehab@infradead.org> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%) > > > Hans Verkuil <hans.verkuil@cisco.com> (commit_signer:4/7=57%) > > > Anatolij Gustschin <agust@denx.de> (commit_signer:1/7=14%) > > > Wei Yongjun <yongjun_wei@trendmicro.com.cn> (commit_signer:1/7=14%) > > > Hans de Goede <hdegoede@redhat.com> (commit_signer:1/7=14%) > > > linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) > > > linux-kernel@vger.kernel.org (open list) > > > > > > According with this driver's copyrights: > > > > > > * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. > > > * > > > * Freescale VIU video driver > > > * > > > * Authors: Hongjun Chen <hong-jun.chen@freescale.com> > > > * Porting to 2.6.35 by DENX Software Engineering, > > > * Anatolij Gustschin <agust@denx.de> > > > > > > The driver author (Hongjun Chen <hong-jun.chen@freescale.com>) was not even > > > shown there, and the co-author got only 15% hit, while I got 100% and Hans > > > got 57%. > > > > > > This happens not only to this driver. In a matter of fact, on most cases where > > > no MAINTAINERS entry exist, the driver's author gets a very small hit chance, > > > as, on several of those drivers, the author doesn't post anything else but > > > the initial patch series. > > > > We probably need to have an entry for all the media drivers, even if it just > > points to the linux-media mailinglist as being the 'collective default maintainer'. > > Yes, I think that all media drivers should be there. I prefer to tag the ones > that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates > that help is wanted. I wrote a small shell script to see what's missing, using the analyze_build.pl script at media-build devel_scripts dir: DIR=$(dirname $0) $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint I excluded the core files from the list, as they don't need any specific entry. RC keymaps is also a special case, as I don't think any maintainer is needed for them. Basically, analyze_build.pl says that there are 613 drivers under drivers/media. The above script shows 348 drivers without an explicit maintainer. So, only 43% of the drivers have a formal maintainer. Yet, on the list below, I think several of them can be easily tagged as "Odd fixes", like cx88 and saa7134. I think I'll send today a few RFC MAINTAINERS patches for some stuff below that I can myself be added as "Odd fixes". Yet, I would very much prefer if someone with more time than me could be taking over the "Odd fixes" patches I'll propose. Regards, Mauro common/b2c2/b2c2-flexcop.ko = common/b2c2/flexcop-hw-filter.c common/b2c2/flexcop-sram.c common/b2c2/flexcop-eeprom.c common/b2c2/flexcop-misc.c common/b2c2/flexcop.c common/b2c2/flexcop-fe-tuner.c common/b2c2/flexcop-i2c.c common/siano/smsdvb.ko = common/siano/smsdvb.c common/siano/smsir.ko = common/siano/smsir.c common/siano/smsmdtv.ko = common/siano/smscoreapi.c common/siano/sms-cards.c common/siano/smsendian.c dvb-frontends/atbm8830.ko = dvb-frontends/atbm8830.c dvb-frontends/au8522_common.ko = dvb-frontends/au8522_common.c dvb-frontends/au8522_decoder.ko = dvb-frontends/au8522_decoder.c dvb-frontends/au8522_dig.ko = dvb-frontends/au8522_dig.c dvb-frontends/bcm3510.ko = dvb-frontends/bcm3510.c dvb-frontends/cx22700.ko = dvb-frontends/cx22700.c dvb-frontends/cx22702.ko = dvb-frontends/cx22702.c dvb-frontends/cx24110.ko = dvb-frontends/cx24110.c dvb-frontends/cx24113.ko = dvb-frontends/cx24113.c dvb-frontends/cx24116.ko = dvb-frontends/cx24116.c dvb-frontends/cx24123.ko = dvb-frontends/cx24123.c dvb-frontends/dib0070.ko = dvb-frontends/dib0070.c dvb-frontends/dib0090.ko = dvb-frontends/dib0090.c dvb-frontends/dib3000mb.ko = dvb-frontends/dib3000mb.c dvb-frontends/dib3000mc.ko = dvb-frontends/dib3000mc.c dvb-frontends/dib7000m.ko = dvb-frontends/dib7000m.c dvb-frontends/dib7000p.ko = dvb-frontends/dib7000p.c dvb-frontends/dib8000.ko = dvb-frontends/dib8000.c dvb-frontends/dib9000.ko = dvb-frontends/dib9000.c dvb-frontends/dibx000_common.ko = dvb-frontends/dibx000_common.c dvb-frontends/drxd.ko = dvb-frontends/drxd_firm.c dvb-frontends/drxd_hard.c dvb-frontends/drxk.ko = dvb-frontends/drxk_hard.c dvb-frontends/ds3000.ko = dvb-frontends/ds3000.c dvb-frontends/dvb_dummy_fe.ko = dvb-frontends/dvb_dummy_fe.c dvb-frontends/dvb-pll.ko = dvb-frontends/dvb-pll.c dvb-frontends/isl6405.ko = dvb-frontends/isl6405.c dvb-frontends/isl6421.ko = dvb-frontends/isl6421.c dvb-frontends/isl6423.ko = dvb-frontends/isl6423.c dvb-frontends/it913x-fe.ko = dvb-frontends/it913x-fe.c dvb-frontends/itd1000.ko = dvb-frontends/itd1000.c dvb-frontends/ix2505v.ko = dvb-frontends/ix2505v.c dvb-frontends/l64781.ko = dvb-frontends/l64781.c dvb-frontends/lgdt330x.ko = dvb-frontends/lgdt330x.c dvb-frontends/lgs8gl5.ko = dvb-frontends/lgs8gl5.c dvb-frontends/lgs8gxx.ko = dvb-frontends/lgs8gxx.c dvb-frontends/lnbp21.ko = dvb-frontends/lnbp21.c dvb-frontends/lnbp22.ko = dvb-frontends/lnbp22.c dvb-frontends/m88rs2000.ko = dvb-frontends/m88rs2000.c dvb-frontends/mb86a16.ko = dvb-frontends/mb86a16.c dvb-frontends/mb86a20s.ko = dvb-frontends/mb86a20s.c dvb-frontends/mt312.ko = dvb-frontends/mt312.c dvb-frontends/mt352.ko = dvb-frontends/mt352.c dvb-frontends/nxt200x.ko = dvb-frontends/nxt200x.c dvb-frontends/nxt6000.ko = dvb-frontends/nxt6000.c dvb-frontends/or51132.ko = dvb-frontends/or51132.c dvb-frontends/or51211.ko = dvb-frontends/or51211.c dvb-frontends/s5h1409.ko = dvb-frontends/s5h1409.c dvb-frontends/s5h1411.ko = dvb-frontends/s5h1411.c dvb-frontends/s5h1420.ko = dvb-frontends/s5h1420.c dvb-frontends/s5h1432.ko = dvb-frontends/s5h1432.c dvb-frontends/s921.ko = dvb-frontends/s921.c dvb-frontends/si21xx.ko = dvb-frontends/si21xx.c dvb-frontends/sp8870.ko = dvb-frontends/sp8870.c dvb-frontends/sp887x.ko = dvb-frontends/sp887x.c dvb-frontends/stb0899.ko = dvb-frontends/stb0899_drv.c dvb-frontends/stb0899_algo.c dvb-frontends/stb6000.ko = dvb-frontends/stb6000.c dvb-frontends/stb6100.ko = dvb-frontends/stb6100.c dvb-frontends/stv0288.ko = dvb-frontends/stv0288.c dvb-frontends/stv0297.ko = dvb-frontends/stv0297.c dvb-frontends/stv0299.ko = dvb-frontends/stv0299.c dvb-frontends/stv0367.ko = dvb-frontends/stv0367.c dvb-frontends/stv0900.ko = dvb-frontends/stv0900_core.c dvb-frontends/stv0900_sw.c dvb-frontends/stv090x.ko = dvb-frontends/stv090x.c dvb-frontends/stv6110.ko = dvb-frontends/stv6110.c dvb-frontends/stv6110x.ko = dvb-frontends/stv6110x.c dvb-frontends/tda10021.ko = dvb-frontends/tda10021.c dvb-frontends/tda10023.ko = dvb-frontends/tda10023.c dvb-frontends/tda10048.ko = dvb-frontends/tda10048.c dvb-frontends/tda1004x.ko = dvb-frontends/tda1004x.c dvb-frontends/tda10086.ko = dvb-frontends/tda10086.c dvb-frontends/tda18271c2dd.ko = dvb-frontends/tda18271c2dd.c dvb-frontends/tda665x.ko = dvb-frontends/tda665x.c dvb-frontends/tda8083.ko = dvb-frontends/tda8083.c dvb-frontends/tda8261.ko = dvb-frontends/tda8261.c dvb-frontends/tda826x.ko = dvb-frontends/tda826x.c dvb-frontends/tua6100.ko = dvb-frontends/tua6100.c dvb-frontends/ves1820.ko = dvb-frontends/ves1820.c dvb-frontends/ves1x93.ko = dvb-frontends/ves1x93.c dvb-frontends/zl10036.ko = dvb-frontends/zl10036.c dvb-frontends/zl10039.ko = dvb-frontends/zl10039.c dvb-frontends/zl10353.ko = dvb-frontends/zl10353.c firewire/firedtv.ko = + firewire/firedtv-rc.ko = firewire/firedtv-rc.c i2c/ad9389b.ko = i2c/ad9389b.c i2c/adp1653.ko = i2c/adp1653.c i2c/adv7170.ko = i2c/adv7170.c i2c/adv7175.ko = i2c/adv7175.c i2c/adv7180.ko = i2c/adv7180.c i2c/adv7183.ko = i2c/adv7183.c i2c/adv7343.ko = i2c/adv7343.c i2c/adv7393.ko = i2c/adv7393.c i2c/adv7604.ko = i2c/adv7604.c i2c/ak881x.ko = i2c/ak881x.c i2c/aptina-pll.ko = i2c/aptina-pll.c i2c/as3645a.ko = i2c/as3645a.c i2c/bt819.ko = i2c/bt819.c i2c/bt856.ko = i2c/bt856.c i2c/bt866.ko = i2c/bt866.c i2c/btcx-risc.ko = i2c/btcx-risc.c i2c/cs5345.ko = i2c/cs5345.c i2c/cs53l32a.ko = i2c/cs53l32a.c i2c/cx2341x.ko = i2c/cx2341x.c i2c/cx25840/cx25840.ko = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c i2c/ir-kbd-i2c.ko = i2c/ir-kbd-i2c.c i2c/ks0127.ko = i2c/ks0127.c i2c/m52790.ko = i2c/m52790.c i2c/msp3400.ko = i2c/msp3400-driver.c i2c/msp3400-kthreads.c i2c/mt9m032.ko = i2c/mt9m032.c i2c/mt9p031.ko = i2c/mt9p031.c i2c/mt9t001.ko = i2c/mt9t001.c i2c/mt9v011.ko = i2c/mt9v011.c i2c/mt9v032.ko = i2c/mt9v032.c i2c/noon010pc30.ko = i2c/noon010pc30.c i2c/s5k4ecgx.ko = i2c/s5k4ecgx.c i2c/s5k6aa.ko = i2c/s5k6aa.c i2c/saa6588.ko = i2c/saa6588.c i2c/saa7110.ko = i2c/saa7110.c i2c/saa7115.ko = i2c/saa7115.c i2c/saa7127.ko = i2c/saa7127.c i2c/saa717x.ko = i2c/saa717x.c i2c/saa7185.ko = i2c/saa7185.c i2c/saa7191.ko = i2c/saa7191.c i2c/smiapp-pll.ko = i2c/smiapp-pll.c i2c/smiapp/smiapp.ko = i2c/smiapp/smiapp-core.c i2c/smiapp/smiapp-regs.c i2c/smiapp/smiapp-quirk.c i2c/smiapp/smiapp-limits.c i2c/sr030pc30.ko = i2c/sr030pc30.c i2c/tcm825x.ko = i2c/tcm825x.c i2c/tda7432.ko = i2c/tda7432.c i2c/tda9840.ko = i2c/tda9840.c i2c/tea6415c.ko = i2c/tea6415c.c i2c/tea6420.ko = i2c/tea6420.c i2c/ths7303.ko = i2c/ths7303.c i2c/tlv320aic23b.ko = i2c/tlv320aic23b.c i2c/tvaudio.ko = i2c/tvaudio.c i2c/tveeprom.ko = i2c/tveeprom.c i2c/tvp514x.ko = i2c/tvp514x.c i2c/tvp5150.ko = i2c/tvp5150.c i2c/tvp7002.ko = i2c/tvp7002.c i2c/upd64031a.ko = i2c/upd64031a.c i2c/upd64083.ko = i2c/upd64083.c i2c/vp27smpx.ko = i2c/vp27smpx.c i2c/vpx3220.ko = i2c/vpx3220.c i2c/vs6624.ko = i2c/vs6624.c i2c/wm8739.ko = i2c/wm8739.c i2c/wm8775.ko = i2c/wm8775.c mmc/siano/smssdio.ko = mmc/siano/smssdio.c parport/bw-qcam.ko = parport/bw-qcam.c parport/c-qcam.ko = parport/c-qcam.c parport/pms.ko = parport/pms.c parport/w9966.ko = parport/w9966.c pci/b2c2/b2c2-flexcop-pci.ko = pci/b2c2/flexcop-pci.c pci/b2c2/flexcop-dma.c pci/bt8xx/bt878.ko = pci/bt8xx/bt878.c pci/bt8xx/dst_ca.ko = pci/bt8xx/dst_ca.c pci/bt8xx/dst.ko = pci/bt8xx/dst.c pci/bt8xx/dvb-bt8xx.ko = pci/bt8xx/dvb-bt8xx.c pci/cx23885/altera-ci.ko = pci/cx23885/altera-ci.c pci/cx23885/cx23885.ko = pci/cx23885/cx23885-cards.c pci/cx23885/cx23885-video.c pci/cx23885/cx23885-vbi.c pci/cx23885/cx23885-core.c pci/cx23885/cx23885-i2c.c pci/cx23885/cx23885-dvb.c pci/cx23885/cx23885-417.c pci/cx23885/cx23885-ioctl.c pci/cx23885/cx23885-ir.c pci/cx23885/cx23885-av.c pci/cx23885/cx23885-input.c pci/cx23885/cx23888-ir.c pci/cx23885/netup-init.c pci/cx23885/cimax2.c pci/cx23885/netup-eeprom.c pci/cx23885/cx23885-f300.c pci/cx23885/cx23885-alsa.c pci/cx25821/cx25821-alsa.ko = pci/cx25821/cx25821-alsa.c pci/cx25821/cx25821.ko = pci/cx25821/cx25821-core.c pci/cx25821/cx25821-cards.c pci/cx25821/cx25821-i2c.c pci/cx25821/cx25821-gpio.c pci/cx25821/cx25821-medusa-video.c pci/cx25821/cx25821-video.c pci/cx25821/cx25821-video-upstream.c pci/cx25821/cx25821-video-upstream-ch2.c pci/cx25821/cx25821-audio-upstream.c pci/cx88/cx8800.ko = pci/cx88/cx88-video.c pci/cx88/cx88-vbi.c pci/cx88/cx8802.ko = pci/cx88/cx88-mpeg.c pci/cx88/cx88-alsa.ko = pci/cx88/cx88-alsa.c pci/cx88/cx88-blackbird.ko = pci/cx88/cx88-blackbird.c pci/cx88/cx88-dvb.ko = pci/cx88/cx88-dvb.c pci/cx88/cx88-vp3054-i2c.ko = pci/cx88/cx88-vp3054-i2c.c pci/cx88/cx88xx.ko = pci/cx88/cx88-cards.c pci/cx88/cx88-core.c pci/cx88/cx88-i2c.c pci/cx88/cx88-tvaudio.c pci/cx88/cx88-dsp.c pci/cx88/cx88-input.c pci/ddbridge/ddbridge.ko = pci/ddbridge/ddbridge-core.c pci/dm1105/dm1105.ko = pci/dm1105/dm1105.c pci/mantis/hopper.ko = pci/mantis/hopper_cards.c pci/mantis/hopper_vp3028.c pci/mantis/mantis_core.ko = pci/mantis/mantis_ioc.c pci/mantis/mantis_uart.c pci/mantis/mantis_dma.c pci/mantis/mantis_pci.c pci/mantis/mantis_i2c.c pci/mantis/mantis_dvb.c pci/mantis/mantis_evm.c pci/mantis/mantis_hif.c pci/mantis/mantis_ca.c pci/mantis/mantis_pcmcia.c pci/mantis/mantis_input.c pci/mantis/mantis.ko = pci/mantis/mantis_cards.c pci/mantis/mantis_vp1033.c pci/mantis/mantis_vp1034.c pci/mantis/mantis_vp1041.c pci/mantis/mantis_vp2033.c pci/mantis/mantis_vp2040.c pci/mantis/mantis_vp3030.c pci/ngene/ngene.ko = pci/ngene/ngene-core.c pci/ngene/ngene-i2c.c pci/ngene/ngene-cards.c pci/ngene/ngene-dvb.c pci/pluto2/pluto2.ko = pci/pluto2/pluto2.c pci/pt1/earth-pt1.ko = pci/pt1/pt1.c pci/pt1/va1j5jf8007s.c pci/pt1/va1j5jf8007t.c pci/saa7134/saa6752hs.ko = pci/saa7134/saa6752hs.c pci/saa7134/saa7134-alsa.ko = pci/saa7134/saa7134-alsa.c pci/saa7134/saa7134-dvb.ko = pci/saa7134/saa7134-dvb.c pci/saa7134/saa7134-empress.ko = pci/saa7134/saa7134-empress.c pci/saa7134/saa7134-input.ko = pci/saa7134/saa7134-input.c pci/saa7134/saa7134.ko = + pci/saa7164/saa7164.ko = pci/saa7164/saa7164-cards.c pci/saa7164/saa7164-core.c pci/saa7164/saa7164-i2c.c pci/saa7164/saa7164-dvb.c pci/saa7164/saa7164-fw.c pci/saa7164/saa7164-bus.c pci/saa7164/saa7164-cmd.c pci/saa7164/saa7164-api.c pci/saa7164/saa7164-buffer.c pci/saa7164/saa7164-encoder.c pci/saa7164/saa7164-vbi.c pci/sta2x11/sta2x11_vip.ko = pci/sta2x11/sta2x11_vip.c pci/ttpci/budget-av.ko = pci/ttpci/budget-av.c pci/ttpci/budget-ci.ko = pci/ttpci/budget-ci.c pci/ttpci/budget-core.ko = pci/ttpci/budget-core.c pci/ttpci/budget.ko = pci/ttpci/budget.c pci/ttpci/budget-patch.ko = pci/ttpci/budget-patch.c pci/ttpci/dvb-ttpci.ko = pci/ttpci/av7110_ir.c pci/ttpci/av7110_hw.c pci/ttpci/av7110_v4l.c pci/ttpci/av7110_av.c pci/ttpci/av7110_ca.c pci/ttpci/av7110.c pci/ttpci/av7110_ipack.c pci/ttpci/ttpci-eeprom.ko = pci/ttpci/ttpci-eeprom.c platform/arv.ko = platform/arv.c platform/blackfin/bfin_video_capture.ko = platform/blackfin/bfin_capture.c platform/blackfin/ppi.c platform/coda.ko = platform/coda.c platform/davinci/dm355_ccdc.ko = platform/davinci/dm355_ccdc.c platform/davinci/dm644x_ccdc.ko = platform/davinci/dm644x_ccdc.c platform/davinci/isif.ko = platform/davinci/isif.c platform/davinci/vpbe_display.ko = platform/davinci/vpbe_display.c platform/davinci/vpbe.ko = platform/davinci/vpbe.c platform/davinci/vpbe_osd.ko = platform/davinci/vpbe_osd.c platform/davinci/vpbe_venc.ko = platform/davinci/vpbe_venc.c platform/davinci/vpfe_capture.ko = platform/davinci/vpfe_capture.c platform/davinci/vpif_capture.ko = platform/davinci/vpif_capture.c platform/davinci/vpif_display.ko = platform/davinci/vpif_display.c platform/davinci/vpif.ko = platform/davinci/vpif.c platform/davinci/vpss.ko = platform/davinci/vpss.c platform/exynos-gsc/exynos-gsc.ko = platform/exynos-gsc/gsc-core.c platform/exynos-gsc/gsc-m2m.c platform/exynos-gsc/gsc-regs.c platform/fsl-viu.ko = platform/fsl-viu.c platform/indycam.ko = platform/indycam.c platform/m2m-deinterlace.ko = platform/m2m-deinterlace.c platform/mem2mem_testdev.ko = platform/mem2mem_testdev.c platform/mx2_emmaprp.ko = platform/mx2_emmaprp.c platform/omap2cam.ko = platform/omap24xxcam.c platform/omap24xxcam-dma.c platform/omap/omap-vout.ko = + platform/omap/omap_vout_vrfb.ko = platform/omap/omap_vout_vrfb.c platform/s5p-g2d/s5p-g2d.ko = platform/s5p-g2d/g2d.c platform/s5p-g2d/g2d-hw.c platform/s5p-jpeg/s5p-jpeg.ko = platform/s5p-jpeg/jpeg-core.c platform/sh_vou.ko = platform/sh_vou.c platform/timblogiw.ko = platform/timblogiw.c platform/via-camera.ko = platform/via-camera.c platform/vino.ko = platform/vino.c platform/vivi.ko = platform/vivi.c radio/dsbr100.ko = radio/dsbr100.c radio/radio-aimslab.ko = radio/radio-aimslab.c radio/radio-aztech.ko = radio/radio-aztech.c radio/radio-cadet.ko = radio/radio-cadet.c radio/radio-gemtek.ko = radio/radio-gemtek.c radio/radio-isa.ko = radio/radio-isa.c radio/radio-keene.ko = radio/radio-keene.c radio/radio-maxiradio.ko = radio/radio-maxiradio.c radio/radio-miropcm20.ko = radio/radio-miropcm20.c radio/radio-mr800.ko = radio/radio-mr800.c radio/radio-rtrack2.ko = radio/radio-rtrack2.c radio/radio-sf16fmi.ko = radio/radio-sf16fmi.c radio/radio-sf16fmr2.ko = radio/radio-sf16fmr2.c radio/radio-shark.ko = radio/radio-shark.c radio/radio-si4713.ko = radio/radio-si4713.c radio/radio-tea5764.ko = radio/radio-tea5764.c radio/radio-terratec.ko = radio/radio-terratec.c radio/radio-timb.ko = radio/radio-timb.c radio/radio-trust.ko = radio/radio-trust.c radio/radio-typhoon.ko = radio/radio-typhoon.c radio/radio-wl1273.ko = radio/radio-wl1273.c radio/radio-zoltrix.ko = radio/radio-zoltrix.c radio/saa7706h.ko = radio/saa7706h.c radio/shark2.ko = radio/radio-shark2.c radio/radio-tea5777.c radio/si470x/radio-i2c-si470x.ko = radio/si470x/radio-si470x-i2c.c radio/si470x/radio-si470x-common.c radio/si470x/radio-usb-si470x.ko = radio/si470x/radio-si470x-usb.c radio/si470x/radio-si470x-common.c radio/si4713-i2c.ko = radio/si4713-i2c.c radio/tef6862.ko = radio/tef6862.c radio/wl128x/fm_drv.ko = radio/wl128x/fmdrv_common.c radio/wl128x/fmdrv_rx.c radio/wl128x/fmdrv_tx.c radio/wl128x/fmdrv_v4l2.c rc/ati_remote.ko = rc/ati_remote.c rc/fintek-cir.ko = rc/fintek-cir.c rc/gpio-ir-recv.ko = rc/gpio-ir-recv.c rc/iguanair.ko = rc/iguanair.c rc/imon.ko = rc/imon.c rc/ir-jvc-decoder.ko = rc/ir-jvc-decoder.c rc/ir-lirc-codec.ko = rc/ir-lirc-codec.c rc/ir-mce_kbd-decoder.ko = rc/ir-mce_kbd-decoder.c rc/ir-nec-decoder.ko = rc/ir-nec-decoder.c rc/ir-rc5-decoder.ko = rc/ir-rc5-decoder.c rc/ir-rc5-sz-decoder.ko = rc/ir-rc5-sz-decoder.c rc/ir-rc6-decoder.ko = rc/ir-rc6-decoder.c rc/ir-rx51.ko = rc/ir-rx51.c rc/ir-sanyo-decoder.ko = rc/ir-sanyo-decoder.c rc/ir-sony-decoder.ko = rc/ir-sony-decoder.c rc/ite-cir.ko = rc/ite-cir.c rc/lirc_dev.ko = rc/lirc_dev.c rc/mceusb.ko = rc/mceusb.c rc/nuvoton-cir.ko = rc/nuvoton-cir.c rc/rc-loopback.ko = rc/rc-loopback.c rc/redrat3.ko = rc/redrat3.c rc/streamzap.ko = rc/streamzap.c rc/ttusbir.ko = rc/ttusbir.c tuners/fc0012.ko = tuners/fc0012.c tuners/fc0013.ko = tuners/fc0013.c tuners/max2165.ko = tuners/max2165.c tuners/mc44s803.ko = tuners/mc44s803.c tuners/mt2060.ko = tuners/mt2060.c tuners/mt2063.ko = tuners/mt2063.c tuners/mt20xx.ko = tuners/mt20xx.c tuners/mt2131.ko = tuners/mt2131.c tuners/mt2266.ko = tuners/mt2266.c tuners/mxl5005s.ko = tuners/mxl5005s.c tuners/tda827x.ko = tuners/tda827x.c tuners/tda9887.ko = tuners/tda9887.c tuners/tea5761.ko = tuners/tea5761.c tuners/tea5767.ko = tuners/tea5767.c tuners/tuner-simple.ko = tuners/tuner-simple.c tuners/tuner-types.ko = tuners/tuner-types.c tuners/tuner-xc2028.ko = tuners/tuner-xc2028.c tuners/xc4000.ko = tuners/xc4000.c tuners/xc5000.ko = tuners/xc5000.c usb/au0828/au0828.ko = usb/au0828/au0828-core.c usb/au0828/au0828-i2c.c usb/au0828/au0828-cards.c usb/au0828/au0828-dvb.c usb/au0828/au0828-video.c usb/au0828/au0828-vbi.c usb/b2c2/b2c2-flexcop-usb.ko = usb/b2c2/flexcop-usb.c usb/cpia2/cpia2.ko = usb/cpia2/cpia2_v4l.c usb/cpia2/cpia2_usb.c usb/cpia2/cpia2_core.c usb/cx231xx/cx231xx-alsa.ko = usb/cx231xx/cx231xx-audio.c usb/cx231xx/cx231xx-dvb.ko = usb/cx231xx/cx231xx-dvb.c usb/cx231xx/cx231xx-input.ko = usb/cx231xx/cx231xx-input.c usb/cx231xx/cx231xx.ko = + usb/dvb-usb/dvb-usb-a800.ko = usb/dvb-usb/a800.c usb/dvb-usb/dvb-usb-af9005.ko = usb/dvb-usb/af9005.c usb/dvb-usb/af9005-fe.c usb/dvb-usb/dvb-usb-af9005-remote.ko = usb/dvb-usb/af9005-remote.c usb/dvb-usb/dvb-usb-az6027.ko = usb/dvb-usb/az6027.c usb/dvb-usb/dvb-usb-cinergyT2.ko = usb/dvb-usb/cinergyT2-core.c usb/dvb-usb/cinergyT2-fe.c usb/dvb-usb/dvb-usb-cxusb.ko = usb/dvb-usb/cxusb.c usb/dvb-usb/dvb-usb-dib0700.ko = usb/dvb-usb/dib0700_core.c usb/dvb-usb/dib0700_devices.c usb/dvb-usb/dvb-usb-dibusb-common.ko = usb/dvb-usb/dibusb-common.c usb/dvb-usb/dvb-usb-dibusb-mb.ko = usb/dvb-usb/dibusb-mb.c usb/dvb-usb/dvb-usb-dibusb-mc.ko = usb/dvb-usb/dibusb-mc.c usb/dvb-usb/dvb-usb-digitv.ko = usb/dvb-usb/digitv.c usb/dvb-usb/dvb-usb-dtt200u.ko = usb/dvb-usb/dtt200u.c usb/dvb-usb/dtt200u-fe.c usb/dvb-usb/dvb-usb-dtv5100.ko = usb/dvb-usb/dtv5100.c usb/dvb-usb/dvb-usb-dw2102.ko = usb/dvb-usb/dw2102.c usb/dvb-usb/dvb-usb-friio.ko = usb/dvb-usb/friio.c usb/dvb-usb/friio-fe.c usb/dvb-usb/dvb-usb-gp8psk.ko = usb/dvb-usb/gp8psk.c usb/dvb-usb/gp8psk-fe.c usb/dvb-usb/dvb-usb.ko = usb/dvb-usb/dvb-usb-dvb.c usb/dvb-usb/dvb-usb-remote.c usb/dvb-usb/usb-urb.c usb/dvb-usb/dvb-usb-firmware.c usb/dvb-usb/dvb-usb-init.c usb/dvb-usb/dvb-usb-urb.c usb/dvb-usb/dvb-usb-i2c.c usb/dvb-usb/dvb-usb-m920x.ko = usb/dvb-usb/m920x.c usb/dvb-usb/dvb-usb-nova-t-usb2.ko = usb/dvb-usb/nova-t-usb2.c usb/dvb-usb/dvb-usb-opera.ko = usb/dvb-usb/opera1.c usb/dvb-usb/dvb-usb-pctv452e.ko = usb/dvb-usb/pctv452e.c usb/dvb-usb/dvb-usb-technisat-usb2.ko = usb/dvb-usb/technisat-usb2.c usb/dvb-usb/dvb-usb-ttusb2.ko = usb/dvb-usb/ttusb2.c usb/dvb-usb/dvb-usb-umt-010.ko = usb/dvb-usb/umt-010.c usb/dvb-usb/dvb-usb-vp702x.ko = usb/dvb-usb/vp702x.c usb/dvb-usb/vp702x-fe.c usb/dvb-usb/dvb-usb-vp7045.ko = usb/dvb-usb/vp7045.c usb/dvb-usb/vp7045-fe.c usb/dvb-usb-v2/dvb-usb-az6007.ko = usb/dvb-usb-v2/az6007.c usb/dvb-usb-v2/dvb-usb-gl861.ko = usb/dvb-usb-v2/gl861.c usb/dvb-usb-v2/dvb-usb-it913x.ko = usb/dvb-usb-v2/it913x.c usb/dvb-usb-v2/dvb-usb-lmedm04.ko = usb/dvb-usb-v2/lmedm04.c usb/em28xx/em28xx-alsa.ko = usb/em28xx/em28xx-audio.c usb/em28xx/em28xx-dvb.ko = usb/em28xx/em28xx-dvb.c usb/em28xx/em28xx.ko = usb/em28xx/em28xx-core.c usb/em28xx/em28xx-vbi.c usb/em28xx/em28xx-video.c usb/em28xx/em28xx-i2c.c usb/em28xx/em28xx-cards.c usb/em28xx/em28xx-rc.ko = usb/em28xx/em28xx-input.c usb/hdpvr/hdpvr.ko = usb/hdpvr/hdpvr-control.c usb/hdpvr/hdpvr-core.c usb/hdpvr/hdpvr-video.c usb/hdpvr/hdpvr-i2c.c usb/pwc/pwc.ko = usb/pwc/pwc-dec1.c usb/pwc/pwc-dec23.c usb/pwc/pwc-kiara.c usb/pwc/pwc-timon.c usb/pwc/pwc-if.c usb/pwc/pwc-misc.c usb/pwc/pwc-ctrl.c usb/pwc/pwc-v4l.c usb/pwc/pwc-uncompress.c usb/s2255/s2255drv.ko = usb/s2255/s2255drv.c usb/siano/smsusb.ko = usb/siano/smsusb.c usb/stkwebcam/stkwebcam.ko = usb/stkwebcam/stk-webcam.c usb/stkwebcam/stk-sensor.c usb/tm6000/tm6000-alsa.ko = usb/tm6000/tm6000-alsa.c usb/tm6000/tm6000-dvb.ko = usb/tm6000/tm6000-dvb.c usb/tm6000/tm6000.ko = usb/tm6000/tm6000-cards.c usb/tm6000/tm6000-core.c usb/tm6000/tm6000-i2c.c usb/tm6000/tm6000-video.c usb/tm6000/tm6000-stds.c usb/tm6000/tm6000-input.c usb/ttusb-budget/dvb-ttusb-budget.ko = usb/ttusb-budget/dvb-ttusb-budget.c usb/ttusb-dec/ttusbdecfe.ko = usb/ttusb-dec/ttusbdecfe.c usb/ttusb-dec/ttusb_dec.ko = usb/ttusb-dec/ttusb_dec.c usb/usbvision/usbvision.ko = usb/usbvision/usbvision-core.c usb/usbvision/usbvision-video.c usb/usbvision/usbvision-i2c.c usb/usbvision/usbvision-cards.c ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-02 13:13 ` drivers without explicit MAINTAINERS entry - was: " Mauro Carvalho Chehab @ 2012-11-02 13:47 ` Hans Verkuil 2012-11-02 14:34 ` Mauro Carvalho Chehab 2012-11-03 9:25 ` [PATCH] firedtv: add MAINTAINERS entry Stefan Richter ` (2 subsequent siblings) 3 siblings, 1 reply; 41+ messages in thread From: Hans Verkuil @ 2012-11-02 13:47 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: media-workshop, linux-media On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote: > Em Thu, 1 Nov 2012 14:12:44 -0200 > Mauro Carvalho Chehab <mchehab@redhat.com> escreveu: > > > Em Thu, 1 Nov 2012 16:44:50 +0100 > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > > > > > On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: > > > > Hi Hans, > > > > > > > > Em Mon, 22 Oct 2012 10:35:56 +0200 > > > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > > > > > > > > > Hi all, > > > > > > > > > > This is the tentative agenda for the media workshop on November 8, 2012. > > > > > If you have additional things that you want to discuss, or something is wrong > > > > > or incomplete in this list, please let me know so I can update the list. > > > > > > > > Thank you for taking care of it. > > > > > > > > > - Explain current merging process (Mauro) > > > > > - Open floor for discussions on how to improve it (Mauro) > > > > > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for > > > > > staging and mainline acceptance: which frameworks to use, v4l2-compliance, > > > > > etc. (Hans Verkuil) > > > > > - V4L2 ambiguities (Hans Verkuil) > > > > > - TSMux device (a mux rather than a demux): Alain Volmat > > > > > - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) > > > > > - Device tree support (Guennadi, not known yet whether this topic is needed) > > > > > - Creating/selecting contexts for hardware that supports this (Samsung, only > > > > > if time is available) > > > > > > > > I have an extra theme for discussions there: what should we do with the drivers > > > > that don't have any MAINTAINERS entry. > > > > > > I've added this topic to the list. > > > > Thanks! > > > > > > It probably makes sense to mark them as "Orphan" (or, at least, have some > > > > criteria to mark them as such). Perhaps before doing that, we could try > > > > to see if are there any developer at the community with time and patience > > > > to handle them. > > > > > > > > This could of course be handled as part of the discussions about how to improve > > > > the merge process, but I suspect that this could generate enough discussions > > > > to be handled as a separate theme. > > > > > > Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can > > > test. So while I wouldn't like to be marked as 'The Maintainer of driver X' > > > (since I simply don't have the time for that), I wouldn't mind being marked as > > > someone who can at least test patches if needed. > > > > There are several "maintainance" status there: > > > > S: Status, one of the following: > > Supported: Someone is actually paid to look after this. > > Maintained: Someone actually looks after it. > > Odd Fixes: It has a maintainer but they don't have time to do > > much other than throw the odd patch in. See below.. > > Orphan: No current maintainer [but maybe you could take the > > role as you write your new code]. > > Obsolete: Old code. Something tagged obsolete generally means > > it has been replaced by a better system and you > > should be using that. > > > > (btw, I just realized that I should be changing the EDAC drivers I maintain > > to Supported; the media drivers I maintain should be kept as Maintained). > > > > I suspect that the "maintainer-light" category for those radio and similar > > old stuff is likely "Odd Fixes". > > > > > > There are some issues by not having a MAINTAINERS entry: > > > > - patches may not flow into the driver maintainer; > > > > - patches will likely be applied without tests/reviews or may > > > > stay for a long time queued; > > > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return > > > > any maintainer[1]. > > > > > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would > > > > delay a lot the patch review process, if applied for every patch, with > > > > unreliable and doubtful results. I don't do it, due to the large volume > > > > of patches, and because the 'other' results aren't typically the driver > > > > maintainer. > > > > > > > > An example of this is the results for a patch I just applied > > > > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): > > > > > > > > $ git show --pretty=email|./scripts/get_maintainer.pl > > > > Mauro Carvalho Chehab <mchehab@infradead.org> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%) > > > > Hans Verkuil <hans.verkuil@cisco.com> (commit_signer:4/7=57%) > > > > Anatolij Gustschin <agust@denx.de> (commit_signer:1/7=14%) > > > > Wei Yongjun <yongjun_wei@trendmicro.com.cn> (commit_signer:1/7=14%) > > > > Hans de Goede <hdegoede@redhat.com> (commit_signer:1/7=14%) > > > > linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) > > > > linux-kernel@vger.kernel.org (open list) > > > > > > > > According with this driver's copyrights: > > > > > > > > * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. > > > > * > > > > * Freescale VIU video driver > > > > * > > > > * Authors: Hongjun Chen <hong-jun.chen@freescale.com> > > > > * Porting to 2.6.35 by DENX Software Engineering, > > > > * Anatolij Gustschin <agust@denx.de> > > > > > > > > The driver author (Hongjun Chen <hong-jun.chen@freescale.com>) was not even > > > > shown there, and the co-author got only 15% hit, while I got 100% and Hans > > > > got 57%. > > > > > > > > This happens not only to this driver. In a matter of fact, on most cases where > > > > no MAINTAINERS entry exist, the driver's author gets a very small hit chance, > > > > as, on several of those drivers, the author doesn't post anything else but > > > > the initial patch series. > > > > > > We probably need to have an entry for all the media drivers, even if it just > > > points to the linux-media mailinglist as being the 'collective default maintainer'. > > > > Yes, I think that all media drivers should be there. I prefer to tag the ones > > that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates > > that help is wanted. > > I wrote a small shell script to see what's missing, using the analyze_build.pl script > at media-build devel_scripts dir: > > DIR=$(dirname $0) > > $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers > grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained > grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint > > I excluded the core files from the list, as they don't need any specific entry. RC > keymaps is also a special case, as I don't think any maintainer is needed for them. > > Basically, analyze_build.pl says that there are 613 drivers under drivers/media. > The above script shows 348 drivers without an explicit maintainer. So, only 43% > of the drivers have a formal maintainer. > > Yet, on the list below, I think several of them can be easily tagged as > "Odd fixes", like cx88 and saa7134. > > I think I'll send today a few RFC MAINTAINERS patches for some stuff below that > I can myself be added as "Odd fixes". Yet, I would very much prefer if someone > with more time than me could be taking over the "Odd fixes" patches I'll propose. > > Regards, > Mauro These two are 'Supported' by me: i2c/ad9389b.ko = i2c/ad9389b.c i2c/adv7604.ko = i2c/adv7604.c These are 'Maintained' by me: i2c/cx2341x.ko = i2c/cx2341x.c parport/bw-qcam.ko = parport/bw-qcam.c parport/c-qcam.ko = parport/c-qcam.c radio/dsbr100.ko = radio/dsbr100.c radio/radio-cadet.ko = radio/radio-cadet.c radio/radio-isa.ko = radio/radio-isa.c radio/radio-keene.ko = radio/radio-keene.c There are more radio drivers that can have that status, but I would need to check that when I'm back in Oslo. I can do 'Odd fixes' for the following: i2c/cx25840/cx25840.ko = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c i2c/m52790.ko = i2c/m52790.c i2c/msp3400.ko = i2c/msp3400-driver.c i2c/msp3400-kthreads.c i2c/saa6588.ko = i2c/saa6588.c i2c/saa7110.ko = i2c/saa7110.c i2c/saa7115.ko = i2c/saa7115.c i2c/saa7127.ko = i2c/saa7127.c i2c/saa717x.ko = i2c/saa717x.c i2c/tda7432.ko = i2c/tda7432.c i2c/tda9840.ko = i2c/tda9840.c i2c/tea6415c.ko = i2c/tea6415c.c i2c/tea6420.ko = i2c/tea6420.c i2c/tvaudio.ko = i2c/tvaudio.c i2c/tveeprom.ko = i2c/tveeprom.c i2c/tvp5150.ko = i2c/tvp5150.c i2c/wm8739.ko = i2c/wm8739.c i2c/wm8775.ko = i2c/wm8775.c parport/pms.ko = parport/pms.c platform/vivi.ko = platform/vivi.c radio/radio-aimslab.ko = radio/radio-aimslab.c radio/radio-gemtek.ko = radio/radio-gemtek.c radio/radio-maxiradio.ko = radio/radio-maxiradio.c radio/radio-miropcm20.ko = radio/radio-miropcm20.c radio/radio-mr800.ko = radio/radio-mr800.c radio/radio-rtrack2.ko = radio/radio-rtrack2.c radio/radio-si4713.ko = radio/radio-si4713.c usb/cx231xx/cx231xx-alsa.ko = usb/cx231xx/cx231xx-audio.c usb/cx231xx/cx231xx-dvb.ko = usb/cx231xx/cx231xx-dvb.c usb/cx231xx/cx231xx-input.ko = usb/cx231xx/cx231xx-input.c usb/cx231xx/cx231xx.ko = + usb/hdpvr/hdpvr.ko = usb/hdpvr/hdpvr-control.c usb/hdpvr/hdpvr-core.c usb/hdpvr/hdpvr-video.c usb/hdpvr/hdpvr-i2c.c usb/tm6000/tm6000-alsa.ko = usb/tm6000/tm6000-alsa.c usb/tm6000/tm6000.ko = usb/tm6000/tm6000-cards.c usb/tm6000/tm6000-core.c usb/tm6000/tm6000-i2c.c usb/tm6000/tm6000-video.c usb/tm6000/tm6000-stds.c usb/tm6000/tm6000-input.c usb/usbvision/usbvision.ko = usb/usbvision/usbvision-core.c usb/usbvision/usbvision-video.c usb/usbvision/usbvision-i2c.c usb/usbvision/usbvision-cards.c Regards, Hans ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-02 13:47 ` Hans Verkuil @ 2012-11-02 14:34 ` Mauro Carvalho Chehab 2012-11-02 15:05 ` [media-workshop] drivers without explicit MAINTAINERS entry - was: " Palash Bandyopadhyay 2012-11-12 18:41 ` drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] " Alexey Klimov 0 siblings, 2 replies; 41+ messages in thread From: Mauro Carvalho Chehab @ 2012-11-02 14:34 UTC (permalink / raw) To: Hans Verkuil; +Cc: media-workshop, linux-media Em Fri, 2 Nov 2012 14:47:49 +0100 Hans Verkuil <hverkuil@xs4all.nl> escreveu: > On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote: > > Em Thu, 1 Nov 2012 14:12:44 -0200 > > Mauro Carvalho Chehab <mchehab@redhat.com> escreveu: > > > > > Em Thu, 1 Nov 2012 16:44:50 +0100 > > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > > > > > > > On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: > > > > > Hi Hans, > > > > > > > > > > Em Mon, 22 Oct 2012 10:35:56 +0200 > > > > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > > > > > > > > > > > Hi all, > > > > > > > > > > > > This is the tentative agenda for the media workshop on November 8, 2012. > > > > > > If you have additional things that you want to discuss, or something is wrong > > > > > > or incomplete in this list, please let me know so I can update the list. > > > > > > > > > > Thank you for taking care of it. > > > > > > > > > > > - Explain current merging process (Mauro) > > > > > > - Open floor for discussions on how to improve it (Mauro) > > > > > > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for > > > > > > staging and mainline acceptance: which frameworks to use, v4l2-compliance, > > > > > > etc. (Hans Verkuil) > > > > > > - V4L2 ambiguities (Hans Verkuil) > > > > > > - TSMux device (a mux rather than a demux): Alain Volmat > > > > > > - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) > > > > > > - Device tree support (Guennadi, not known yet whether this topic is needed) > > > > > > - Creating/selecting contexts for hardware that supports this (Samsung, only > > > > > > if time is available) > > > > > > > > > > I have an extra theme for discussions there: what should we do with the drivers > > > > > that don't have any MAINTAINERS entry. > > > > > > > > I've added this topic to the list. > > > > > > Thanks! > > > > > > > > It probably makes sense to mark them as "Orphan" (or, at least, have some > > > > > criteria to mark them as such). Perhaps before doing that, we could try > > > > > to see if are there any developer at the community with time and patience > > > > > to handle them. > > > > > > > > > > This could of course be handled as part of the discussions about how to improve > > > > > the merge process, but I suspect that this could generate enough discussions > > > > > to be handled as a separate theme. > > > > > > > > Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can > > > > test. So while I wouldn't like to be marked as 'The Maintainer of driver X' > > > > (since I simply don't have the time for that), I wouldn't mind being marked as > > > > someone who can at least test patches if needed. > > > > > > There are several "maintainance" status there: > > > > > > S: Status, one of the following: > > > Supported: Someone is actually paid to look after this. > > > Maintained: Someone actually looks after it. > > > Odd Fixes: It has a maintainer but they don't have time to do > > > much other than throw the odd patch in. See below.. > > > Orphan: No current maintainer [but maybe you could take the > > > role as you write your new code]. > > > Obsolete: Old code. Something tagged obsolete generally means > > > it has been replaced by a better system and you > > > should be using that. > > > > > > (btw, I just realized that I should be changing the EDAC drivers I maintain > > > to Supported; the media drivers I maintain should be kept as Maintained). > > > > > > I suspect that the "maintainer-light" category for those radio and similar > > > old stuff is likely "Odd Fixes". > > > > > > > > There are some issues by not having a MAINTAINERS entry: > > > > > - patches may not flow into the driver maintainer; > > > > > - patches will likely be applied without tests/reviews or may > > > > > stay for a long time queued; > > > > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return > > > > > any maintainer[1]. > > > > > > > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would > > > > > delay a lot the patch review process, if applied for every patch, with > > > > > unreliable and doubtful results. I don't do it, due to the large volume > > > > > of patches, and because the 'other' results aren't typically the driver > > > > > maintainer. > > > > > > > > > > An example of this is the results for a patch I just applied > > > > > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): > > > > > > > > > > $ git show --pretty=email|./scripts/get_maintainer.pl > > > > > Mauro Carvalho Chehab <mchehab@infradead.org> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%) > > > > > Hans Verkuil <hans.verkuil@cisco.com> (commit_signer:4/7=57%) > > > > > Anatolij Gustschin <agust@denx.de> (commit_signer:1/7=14%) > > > > > Wei Yongjun <yongjun_wei@trendmicro.com.cn> (commit_signer:1/7=14%) > > > > > Hans de Goede <hdegoede@redhat.com> (commit_signer:1/7=14%) > > > > > linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) > > > > > linux-kernel@vger.kernel.org (open list) > > > > > > > > > > According with this driver's copyrights: > > > > > > > > > > * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. > > > > > * > > > > > * Freescale VIU video driver > > > > > * > > > > > * Authors: Hongjun Chen <hong-jun.chen@freescale.com> > > > > > * Porting to 2.6.35 by DENX Software Engineering, > > > > > * Anatolij Gustschin <agust@denx.de> > > > > > > > > > > The driver author (Hongjun Chen <hong-jun.chen@freescale.com>) was not even > > > > > shown there, and the co-author got only 15% hit, while I got 100% and Hans > > > > > got 57%. > > > > > > > > > > This happens not only to this driver. In a matter of fact, on most cases where > > > > > no MAINTAINERS entry exist, the driver's author gets a very small hit chance, > > > > > as, on several of those drivers, the author doesn't post anything else but > > > > > the initial patch series. > > > > > > > > We probably need to have an entry for all the media drivers, even if it just > > > > points to the linux-media mailinglist as being the 'collective default maintainer'. > > > > > > Yes, I think that all media drivers should be there. I prefer to tag the ones > > > that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates > > > that help is wanted. > > > > I wrote a small shell script to see what's missing, using the analyze_build.pl script > > at media-build devel_scripts dir: > > > > DIR=$(dirname $0) > > > > $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers > > grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained > > grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint > > > > I excluded the core files from the list, as they don't need any specific entry. RC > > keymaps is also a special case, as I don't think any maintainer is needed for them. > > > > Basically, analyze_build.pl says that there are 613 drivers under drivers/media. > > The above script shows 348 drivers without an explicit maintainer. So, only 43% > > of the drivers have a formal maintainer. > > > > Yet, on the list below, I think several of them can be easily tagged as > > "Odd fixes", like cx88 and saa7134. > > > > I think I'll send today a few RFC MAINTAINERS patches for some stuff below that > > I can myself be added as "Odd fixes". Yet, I would very much prefer if someone > > with more time than me could be taking over the "Odd fixes" patches I'll propose. > > > > Regards, > > Mauro > > These two are 'Supported' by me: > > i2c/ad9389b.ko = i2c/ad9389b.c > i2c/adv7604.ko = i2c/adv7604.c > > These are 'Maintained' by me: > > i2c/cx2341x.ko = i2c/cx2341x.c > parport/bw-qcam.ko = parport/bw-qcam.c > parport/c-qcam.ko = parport/c-qcam.c > radio/dsbr100.ko = radio/dsbr100.c > radio/radio-cadet.ko = radio/radio-cadet.c > radio/radio-isa.ko = radio/radio-isa.c > radio/radio-keene.ko = radio/radio-keene.c OK. Could you please send patches for those? I think that the better is to write one patch by each MAINTAINERS entry (except, of course, if there are consecutive entries), as I suspect that MAINTAINERS is likely one of top-rated merge-conflicts file. > > There are more radio drivers that can have that status, but I would need > to check that when I'm back in Oslo. > > I can do 'Odd fixes' for the following: > > i2c/cx25840/cx25840.ko = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c > i2c/m52790.ko = i2c/m52790.c > i2c/msp3400.ko = i2c/msp3400-driver.c i2c/msp3400-kthreads.c > i2c/saa6588.ko = i2c/saa6588.c > i2c/saa7110.ko = i2c/saa7110.c > i2c/saa7115.ko = i2c/saa7115.c > i2c/saa7127.ko = i2c/saa7127.c > i2c/saa717x.ko = i2c/saa717x.c > i2c/tda7432.ko = i2c/tda7432.c > i2c/tda9840.ko = i2c/tda9840.c > i2c/tea6415c.ko = i2c/tea6415c.c > i2c/tea6420.ko = i2c/tea6420.c > i2c/tvaudio.ko = i2c/tvaudio.c > i2c/tveeprom.ko = i2c/tveeprom.c > i2c/tvp5150.ko = i2c/tvp5150.c While I don't mind if you want to do odd fixes for this device, I think I can maintain this one, as the "default" device I use for random tests has this chipset (HVR-950), and I wrote this driver. > i2c/wm8739.ko = i2c/wm8739.c > i2c/wm8775.ko = i2c/wm8775.c > parport/pms.ko = parport/pms.c > platform/vivi.ko = platform/vivi.c > radio/radio-aimslab.ko = radio/radio-aimslab.c > radio/radio-gemtek.ko = radio/radio-gemtek.c > radio/radio-maxiradio.ko = radio/radio-maxiradio.c > radio/radio-miropcm20.ko = radio/radio-miropcm20.c > radio/radio-mr800.ko = radio/radio-mr800.c > radio/radio-rtrack2.ko = radio/radio-rtrack2.c > radio/radio-si4713.ko = radio/radio-si4713.c > usb/cx231xx/cx231xx-alsa.ko = usb/cx231xx/cx231xx-audio.c > usb/cx231xx/cx231xx-dvb.ko = usb/cx231xx/cx231xx-dvb.c > usb/cx231xx/cx231xx-input.ko = usb/cx231xx/cx231xx-input.c > usb/cx231xx/cx231xx.ko = + I think we should check if the driver author is not interested on taking maintainership for this one, before putting it on Odd fixes status. > usb/hdpvr/hdpvr.ko = usb/hdpvr/hdpvr-control.c usb/hdpvr/hdpvr-core.c usb/hdpvr/hdpvr-video.c usb/hdpvr/hdpvr-i2c.c > usb/tm6000/tm6000-alsa.ko = usb/tm6000/tm6000-alsa.c > usb/tm6000/tm6000.ko = usb/tm6000/tm6000-cards.c usb/tm6000/tm6000-core.c usb/tm6000/tm6000-i2c.c usb/tm6000/tm6000-video.c usb/tm6000/tm6000-stds.c usb/tm6000/tm6000-input.c Just submitted an RFC patch for this one, also as "Odd fixes". Of course, I don't mind if you prefer to take it. Btw, you forgot the tm6000-dvb driver, that it is part of it. > usb/usbvision/usbvision.ko = usb/usbvision/usbvision-core.c usb/usbvision/usbvision-video.c usb/usbvision/usbvision-i2c.c usb/usbvision/usbvision-cards.c > > Regards, > > Hans Regards, Mauro ^ permalink raw reply [flat|nested] 41+ messages in thread
* RE: [media-workshop] drivers without explicit MAINTAINERS entry - was: Re: Tentative Agenda for the November workshop 2012-11-02 14:34 ` Mauro Carvalho Chehab @ 2012-11-02 15:05 ` Palash Bandyopadhyay 2012-11-12 18:41 ` drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] " Alexey Klimov 1 sibling, 0 replies; 41+ messages in thread From: Palash Bandyopadhyay @ 2012-11-02 15:05 UTC (permalink / raw) To: Mauro Carvalho Chehab, Hans Verkuil; +Cc: media-workshop, linux-media Thanks Hans and Mauro. On any of the CX drivers, if we do not have any "maintainer" or "odd fixer", you could add me to the "odd fixer" list. Rgds, Palash -----Original Message----- From: media-workshop-bounces@linuxtv.org [mailto:media-workshop-bounces@linuxtv.org] On Behalf Of Mauro Carvalho Chehab Sent: Friday, November 02, 2012 7:35 AM To: Hans Verkuil Cc: media-workshop@linuxtv.org; linux-media Subject: Re: [media-workshop] drivers without explicit MAINTAINERS entry - was: Re: Tentative Agenda for the November workshop Em Fri, 2 Nov 2012 14:47:49 +0100 Hans Verkuil <hverkuil@xs4all.nl> escreveu: > On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote: > > Em Thu, 1 Nov 2012 14:12:44 -0200 > > Mauro Carvalho Chehab <mchehab@redhat.com> escreveu: > > > > > Em Thu, 1 Nov 2012 16:44:50 +0100 > > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > > > > > > > On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: > > > > > Hi Hans, > > > > > > > > > > Em Mon, 22 Oct 2012 10:35:56 +0200 Hans Verkuil > > > > > <hverkuil@xs4all.nl> escreveu: > > > > > > > > > > > Hi all, > > > > > > > > > > > > This is the tentative agenda for the media workshop on November 8, 2012. > > > > > > If you have additional things that you want to discuss, or > > > > > > something is wrong or incomplete in this list, please let me know so I can update the list. > > > > > > > > > > Thank you for taking care of it. > > > > > > > > > > > - Explain current merging process (Mauro) > > > > > > - Open floor for discussions on how to improve it (Mauro) > > > > > > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for > > > > > > staging and mainline acceptance: which frameworks to use, v4l2-compliance, > > > > > > etc. (Hans Verkuil) > > > > > > - V4L2 ambiguities (Hans Verkuil) > > > > > > - TSMux device (a mux rather than a demux): Alain Volmat > > > > > > - dmabuf status, esp. with regards to being able to test > > > > > > (Mauro/Samsung) > > > > > > - Device tree support (Guennadi, not known yet whether this > > > > > > topic is needed) > > > > > > - Creating/selecting contexts for hardware that supports this (Samsung, only > > > > > > if time is available) > > > > > > > > > > I have an extra theme for discussions there: what should we do > > > > > with the drivers that don't have any MAINTAINERS entry. > > > > > > > > I've added this topic to the list. > > > > > > Thanks! > > > > > > > > It probably makes sense to mark them as "Orphan" (or, at > > > > > least, have some criteria to mark them as such). Perhaps > > > > > before doing that, we could try to see if are there any > > > > > developer at the community with time and patience to handle them. > > > > > > > > > > This could of course be handled as part of the discussions > > > > > about how to improve the merge process, but I suspect that > > > > > this could generate enough discussions to be handled as a separate theme. > > > > > > > > Do we have a 'Maintainer-Light' category? I have a lot of > > > > hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' > > > > (since I simply don't have the time for that), I wouldn't mind > > > > being marked as someone who can at least test patches if needed. > > > > > > There are several "maintainance" status there: > > > > > > S: Status, one of the following: > > > Supported: Someone is actually paid to look after this. > > > Maintained: Someone actually looks after it. > > > Odd Fixes: It has a maintainer but they don't have time to do > > > much other than throw the odd patch in. See below.. > > > Orphan: No current maintainer [but maybe you could take the > > > role as you write your new code]. > > > Obsolete: Old code. Something tagged obsolete generally means > > > it has been replaced by a better system and you > > > should be using that. > > > > > > (btw, I just realized that I should be changing the EDAC drivers I > > > maintain to Supported; the media drivers I maintain should be kept as Maintained). > > > > > > I suspect that the "maintainer-light" category for those radio and > > > similar old stuff is likely "Odd Fixes". > > > > > > > > There are some issues by not having a MAINTAINERS entry: > > > > > - patches may not flow into the driver maintainer; > > > > > - patches will likely be applied without tests/reviews or may > > > > > stay for a long time queued; > > > > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return > > > > > any maintainer[1]. > > > > > > > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. > > > > > Letting it would delay a lot the patch review process, if > > > > > applied for every patch, with unreliable and doubtful results. > > > > > I don't do it, due to the large volume of patches, and because > > > > > the 'other' results aren't typically the driver maintainer. > > > > > > > > > > An example of this is the results for a patch I just applied > > > > > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): > > > > > > > > > > $ git show --pretty=email|./scripts/get_maintainer.pl > > > > > Mauro Carvalho Chehab <mchehab@infradead.org> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%) > > > > > Hans Verkuil <hans.verkuil@cisco.com> (commit_signer:4/7=57%) > > > > > Anatolij Gustschin <agust@denx.de> (commit_signer:1/7=14%) > > > > > Wei Yongjun <yongjun_wei@trendmicro.com.cn> (commit_signer:1/7=14%) > > > > > Hans de Goede <hdegoede@redhat.com> (commit_signer:1/7=14%) > > > > > linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) > > > > > linux-kernel@vger.kernel.org (open list) > > > > > > > > > > According with this driver's copyrights: > > > > > > > > > > * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. > > > > > * > > > > > * Freescale VIU video driver > > > > > * > > > > > * Authors: Hongjun Chen <hong-jun.chen@freescale.com> > > > > > * Porting to 2.6.35 by DENX Software Engineering, > > > > > * Anatolij Gustschin <agust@denx.de> > > > > > > > > > > The driver author (Hongjun Chen <hong-jun.chen@freescale.com>) > > > > > was not even shown there, and the co-author got only 15% hit, > > > > > while I got 100% and Hans got 57%. > > > > > > > > > > This happens not only to this driver. In a matter of fact, on > > > > > most cases where no MAINTAINERS entry exist, the driver's > > > > > author gets a very small hit chance, as, on several of those > > > > > drivers, the author doesn't post anything else but the initial patch series. > > > > > > > > We probably need to have an entry for all the media drivers, > > > > even if it just points to the linux-media mailinglist as being the 'collective default maintainer'. > > > > > > Yes, I think that all media drivers should be there. I prefer to > > > tag the ones that nobody sends us a MAINTAINERS entry with > > > "Orphan", as this tag indicates that help is wanted. > > > > I wrote a small shell script to see what's missing, using the > > analyze_build.pl script at media-build devel_scripts dir: > > > > DIR=$(dirname $0) > > > > $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers > > grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained > > grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e > > v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort > > >without_maint > > > > I excluded the core files from the list, as they don't need any > > specific entry. RC keymaps is also a special case, as I don't think any maintainer is needed for them. > > > > Basically, analyze_build.pl says that there are 613 drivers under drivers/media. > > The above script shows 348 drivers without an explicit maintainer. > > So, only 43% of the drivers have a formal maintainer. > > > > Yet, on the list below, I think several of them can be easily tagged > > as "Odd fixes", like cx88 and saa7134. > > > > I think I'll send today a few RFC MAINTAINERS patches for some stuff > > below that I can myself be added as "Odd fixes". Yet, I would very > > much prefer if someone with more time than me could be taking over the "Odd fixes" patches I'll propose. > > > > Regards, > > Mauro > > These two are 'Supported' by me: > > i2c/ad9389b.ko = i2c/ad9389b.c > i2c/adv7604.ko = i2c/adv7604.c > > These are 'Maintained' by me: > > i2c/cx2341x.ko = i2c/cx2341x.c > parport/bw-qcam.ko = parport/bw-qcam.c > parport/c-qcam.ko = parport/c-qcam.c > radio/dsbr100.ko = radio/dsbr100.c > radio/radio-cadet.ko = radio/radio-cadet.c > radio/radio-isa.ko = radio/radio-isa.c > radio/radio-keene.ko = radio/radio-keene.c OK. Could you please send patches for those? I think that the better is to write one patch by each MAINTAINERS entry (except, of course, if there are consecutive entries), as I suspect that MAINTAINERS is likely one of top-rated merge-conflicts file. > > There are more radio drivers that can have that status, but I would > need to check that when I'm back in Oslo. > > I can do 'Odd fixes' for the following: > > i2c/cx25840/cx25840.ko = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c > i2c/m52790.ko = i2c/m52790.c > i2c/msp3400.ko = i2c/msp3400-driver.c i2c/msp3400-kthreads.c > i2c/saa6588.ko = i2c/saa6588.c > i2c/saa7110.ko = i2c/saa7110.c > i2c/saa7115.ko = i2c/saa7115.c > i2c/saa7127.ko = i2c/saa7127.c > i2c/saa717x.ko = i2c/saa717x.c > i2c/tda7432.ko = i2c/tda7432.c > i2c/tda9840.ko = i2c/tda9840.c > i2c/tea6415c.ko = i2c/tea6415c.c > i2c/tea6420.ko = i2c/tea6420.c > i2c/tvaudio.ko = i2c/tvaudio.c > i2c/tveeprom.ko = i2c/tveeprom.c > i2c/tvp5150.ko = i2c/tvp5150.c While I don't mind if you want to do odd fixes for this device, I think I can maintain this one, as the "default" device I use for random tests has this chipset (HVR-950), and I wrote this driver. > i2c/wm8739.ko = i2c/wm8739.c > i2c/wm8775.ko = i2c/wm8775.c > parport/pms.ko = parport/pms.c > platform/vivi.ko = platform/vivi.c > radio/radio-aimslab.ko = radio/radio-aimslab.c > radio/radio-gemtek.ko = radio/radio-gemtek.c > radio/radio-maxiradio.ko = radio/radio-maxiradio.c > radio/radio-miropcm20.ko = radio/radio-miropcm20.c > radio/radio-mr800.ko = radio/radio-mr800.c > radio/radio-rtrack2.ko = radio/radio-rtrack2.c > radio/radio-si4713.ko = radio/radio-si4713.c > usb/cx231xx/cx231xx-alsa.ko = usb/cx231xx/cx231xx-audio.c > usb/cx231xx/cx231xx-dvb.ko = usb/cx231xx/cx231xx-dvb.c > usb/cx231xx/cx231xx-input.ko = usb/cx231xx/cx231xx-input.c > usb/cx231xx/cx231xx.ko = + I think we should check if the driver author is not interested on taking maintainership for this one, before putting it on Odd fixes status. > usb/hdpvr/hdpvr.ko = usb/hdpvr/hdpvr-control.c usb/hdpvr/hdpvr-core.c usb/hdpvr/hdpvr-video.c usb/hdpvr/hdpvr-i2c.c > usb/tm6000/tm6000-alsa.ko = usb/tm6000/tm6000-alsa.c > usb/tm6000/tm6000.ko = usb/tm6000/tm6000-cards.c usb/tm6000/tm6000-core.c usb/tm6000/tm6000-i2c.c usb/tm6000/tm6000-video.c usb/tm6000/tm6000-stds.c usb/tm6000/tm6000-input.c Just submitted an RFC patch for this one, also as "Odd fixes". Of course, I don't mind if you prefer to take it. Btw, you forgot the tm6000-dvb driver, that it is part of it. > usb/usbvision/usbvision.ko = usb/usbvision/usbvision-core.c usb/usbvision/usbvision-video.c usb/usbvision/usbvision-i2c.c usb/usbvision/usbvision-cards.c > > Regards, > > Hans Regards, Mauro _______________________________________________ media-workshop mailing list media-workshop@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop Conexant E-mail Firewall (Conexant.Com) made the following annotations --------------------------------------------------------------------- ********************** Legal Disclaimer **************************** "This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you." ********************************************************************** --------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-02 14:34 ` Mauro Carvalho Chehab 2012-11-02 15:05 ` [media-workshop] drivers without explicit MAINTAINERS entry - was: " Palash Bandyopadhyay @ 2012-11-12 18:41 ` Alexey Klimov 2012-11-12 18:54 ` Mauro Carvalho Chehab 2012-11-23 10:31 ` Hans Verkuil 1 sibling, 2 replies; 41+ messages in thread From: Alexey Klimov @ 2012-11-12 18:41 UTC (permalink / raw) To: Mauro Carvalho Chehab, Hans Verkuil; +Cc: media-workshop, linux-media Hi Mauro, Hans, all, On Fri, Nov 2, 2012 at 6:34 PM, Mauro Carvalho Chehab <mchehab@redhat.com> wrote: > Em Fri, 2 Nov 2012 14:47:49 +0100 > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > >> On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote: >> > Em Thu, 1 Nov 2012 14:12:44 -0200 >> > Mauro Carvalho Chehab <mchehab@redhat.com> escreveu: >> > >> > > Em Thu, 1 Nov 2012 16:44:50 +0100 >> > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: >> > > >> > > > On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: >> > > > > Hi Hans, >> > > > > >> > > > > Em Mon, 22 Oct 2012 10:35:56 +0200 >> > > > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: >> > > > > >> > > > > > Hi all, >> > > > > > >> > > > > > This is the tentative agenda for the media workshop on November 8, 2012. >> > > > > > If you have additional things that you want to discuss, or something is wrong >> > > > > > or incomplete in this list, please let me know so I can update the list. >> > > > > >> > > > > Thank you for taking care of it. >> > > > > >> > > > > > - Explain current merging process (Mauro) >> > > > > > - Open floor for discussions on how to improve it (Mauro) >> > > > > > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for >> > > > > > staging and mainline acceptance: which frameworks to use, v4l2-compliance, >> > > > > > etc. (Hans Verkuil) >> > > > > > - V4L2 ambiguities (Hans Verkuil) >> > > > > > - TSMux device (a mux rather than a demux): Alain Volmat >> > > > > > - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) >> > > > > > - Device tree support (Guennadi, not known yet whether this topic is needed) >> > > > > > - Creating/selecting contexts for hardware that supports this (Samsung, only >> > > > > > if time is available) >> > > > > >> > > > > I have an extra theme for discussions there: what should we do with the drivers >> > > > > that don't have any MAINTAINERS entry. >> > > > >> > > > I've added this topic to the list. >> > > >> > > Thanks! >> > > >> > > > > It probably makes sense to mark them as "Orphan" (or, at least, have some >> > > > > criteria to mark them as such). Perhaps before doing that, we could try >> > > > > to see if are there any developer at the community with time and patience >> > > > > to handle them. >> > > > > >> > > > > This could of course be handled as part of the discussions about how to improve >> > > > > the merge process, but I suspect that this could generate enough discussions >> > > > > to be handled as a separate theme. >> > > > >> > > > Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can >> > > > test. So while I wouldn't like to be marked as 'The Maintainer of driver X' >> > > > (since I simply don't have the time for that), I wouldn't mind being marked as >> > > > someone who can at least test patches if needed. >> > > >> > > There are several "maintainance" status there: >> > > >> > > S: Status, one of the following: >> > > Supported: Someone is actually paid to look after this. >> > > Maintained: Someone actually looks after it. >> > > Odd Fixes: It has a maintainer but they don't have time to do >> > > much other than throw the odd patch in. See below.. >> > > Orphan: No current maintainer [but maybe you could take the >> > > role as you write your new code]. >> > > Obsolete: Old code. Something tagged obsolete generally means >> > > it has been replaced by a better system and you >> > > should be using that. >> > > >> > > (btw, I just realized that I should be changing the EDAC drivers I maintain >> > > to Supported; the media drivers I maintain should be kept as Maintained). >> > > >> > > I suspect that the "maintainer-light" category for those radio and similar >> > > old stuff is likely "Odd Fixes". >> > > >> > > > > There are some issues by not having a MAINTAINERS entry: >> > > > > - patches may not flow into the driver maintainer; >> > > > > - patches will likely be applied without tests/reviews or may >> > > > > stay for a long time queued; >> > > > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return >> > > > > any maintainer[1]. >> > > > > >> > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would >> > > > > delay a lot the patch review process, if applied for every patch, with >> > > > > unreliable and doubtful results. I don't do it, due to the large volume >> > > > > of patches, and because the 'other' results aren't typically the driver >> > > > > maintainer. >> > > > > >> > > > > An example of this is the results for a patch I just applied >> > > > > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): >> > > > > >> > > > > $ git show --pretty=email|./scripts/get_maintainer.pl >> > > > > Mauro Carvalho Chehab <mchehab@infradead.org> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%) >> > > > > Hans Verkuil <hans.verkuil@cisco.com> (commit_signer:4/7=57%) >> > > > > Anatolij Gustschin <agust@denx.de> (commit_signer:1/7=14%) >> > > > > Wei Yongjun <yongjun_wei@trendmicro.com.cn> (commit_signer:1/7=14%) >> > > > > Hans de Goede <hdegoede@redhat.com> (commit_signer:1/7=14%) >> > > > > linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) >> > > > > linux-kernel@vger.kernel.org (open list) >> > > > > >> > > > > According with this driver's copyrights: >> > > > > >> > > > > * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. >> > > > > * >> > > > > * Freescale VIU video driver >> > > > > * >> > > > > * Authors: Hongjun Chen <hong-jun.chen@freescale.com> >> > > > > * Porting to 2.6.35 by DENX Software Engineering, >> > > > > * Anatolij Gustschin <agust@denx.de> >> > > > > >> > > > > The driver author (Hongjun Chen <hong-jun.chen@freescale.com>) was not even >> > > > > shown there, and the co-author got only 15% hit, while I got 100% and Hans >> > > > > got 57%. >> > > > > >> > > > > This happens not only to this driver. In a matter of fact, on most cases where >> > > > > no MAINTAINERS entry exist, the driver's author gets a very small hit chance, >> > > > > as, on several of those drivers, the author doesn't post anything else but >> > > > > the initial patch series. >> > > > >> > > > We probably need to have an entry for all the media drivers, even if it just >> > > > points to the linux-media mailinglist as being the 'collective default maintainer'. >> > > >> > > Yes, I think that all media drivers should be there. I prefer to tag the ones >> > > that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates >> > > that help is wanted. >> > >> > I wrote a small shell script to see what's missing, using the analyze_build.pl script >> > at media-build devel_scripts dir: >> > >> > DIR=$(dirname $0) >> > >> > $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers >> > grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained >> > grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint >> > >> > I excluded the core files from the list, as they don't need any specific entry. RC >> > keymaps is also a special case, as I don't think any maintainer is needed for them. >> > >> > Basically, analyze_build.pl says that there are 613 drivers under drivers/media. >> > The above script shows 348 drivers without an explicit maintainer. So, only 43% >> > of the drivers have a formal maintainer. >> > >> > Yet, on the list below, I think several of them can be easily tagged as >> > "Odd fixes", like cx88 and saa7134. >> > >> > I think I'll send today a few RFC MAINTAINERS patches for some stuff below that >> > I can myself be added as "Odd fixes". Yet, I would very much prefer if someone >> > with more time than me could be taking over the "Odd fixes" patches I'll propose. >> > >> > Regards, >> > Mauro >> >> These two are 'Supported' by me: >> >> i2c/ad9389b.ko = i2c/ad9389b.c >> i2c/adv7604.ko = i2c/adv7604.c >> >> These are 'Maintained' by me: >> >> i2c/cx2341x.ko = i2c/cx2341x.c >> parport/bw-qcam.ko = parport/bw-qcam.c >> parport/c-qcam.ko = parport/c-qcam.c >> radio/dsbr100.ko = radio/dsbr100.c >> radio/radio-cadet.ko = radio/radio-cadet.c >> radio/radio-isa.ko = radio/radio-isa.c >> radio/radio-keene.ko = radio/radio-keene.c > > OK. Could you please send patches for those? I think that the better is > to write one patch by each MAINTAINERS entry (except, of course, if there > are consecutive entries), as I suspect that MAINTAINERS is likely one > of top-rated merge-conflicts file. > >> >> There are more radio drivers that can have that status, but I would need >> to check that when I'm back in Oslo. >> >> I can do 'Odd fixes' for the following: >> >> i2c/cx25840/cx25840.ko = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c >> i2c/m52790.ko = i2c/m52790.c >> i2c/msp3400.ko = i2c/msp3400-driver.c i2c/msp3400-kthreads.c >> i2c/saa6588.ko = i2c/saa6588.c >> i2c/saa7110.ko = i2c/saa7110.c >> i2c/saa7115.ko = i2c/saa7115.c >> i2c/saa7127.ko = i2c/saa7127.c >> i2c/saa717x.ko = i2c/saa717x.c >> i2c/tda7432.ko = i2c/tda7432.c >> i2c/tda9840.ko = i2c/tda9840.c >> i2c/tea6415c.ko = i2c/tea6415c.c >> i2c/tea6420.ko = i2c/tea6420.c >> i2c/tvaudio.ko = i2c/tvaudio.c >> i2c/tveeprom.ko = i2c/tveeprom.c > >> i2c/tvp5150.ko = i2c/tvp5150.c > While I don't mind if you want to do odd fixes for this device, > I think I can maintain this one, as the "default" device I use for > random tests has this chipset (HVR-950), and I wrote this driver. > >> i2c/wm8739.ko = i2c/wm8739.c >> i2c/wm8775.ko = i2c/wm8775.c >> parport/pms.ko = parport/pms.c >> platform/vivi.ko = platform/vivi.c >> radio/radio-aimslab.ko = radio/radio-aimslab.c >> radio/radio-gemtek.ko = radio/radio-gemtek.c >> radio/radio-maxiradio.ko = radio/radio-maxiradio.c >> radio/radio-miropcm20.ko = radio/radio-miropcm20.c >> radio/radio-mr800.ko = radio/radio-mr800.c >> radio/radio-rtrack2.ko = radio/radio-rtrack2.c >> radio/radio-si4713.ko = radio/radio-si4713.c > >> usb/cx231xx/cx231xx-alsa.ko = usb/cx231xx/cx231xx-audio.c >> usb/cx231xx/cx231xx-dvb.ko = usb/cx231xx/cx231xx-dvb.c >> usb/cx231xx/cx231xx-input.ko = usb/cx231xx/cx231xx-input.c >> usb/cx231xx/cx231xx.ko = + > I think we should check if the driver author is not interested on > taking maintainership for this one, before putting it on Odd fixes status. I'm very sorry for long silence but i'm ready to take maintainership for radio-mr800. By the way, i think that only fixes will be present for this driver in the future. Is it possible for driver to have two maintainers or for example one person marked as maintainer and another one marked as "odd fixes" ? I mean i'm interested to be in c/c regarding all email, news, interesting patches for radio-mr800, dsbr100 and usb radio part of si470x but i don't know how to mark it that i want to help with these drivers. I have only dsbr100, mr800 and kworld fm700 (based on si470x) usb radios and i'm ready to test any patches and help as much as i can. I don't have usb radio for radio-keene.c driver but i probably will take a look how to buy it here.. And i'm also ready to maintain driver radio-ma901.c. I posted patches for this device about two weeks ago. Driver is rather small (first working version) but i hope to add more features there in future. Best regards and wishes, Alexey Klimov ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-12 18:41 ` drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] " Alexey Klimov @ 2012-11-12 18:54 ` Mauro Carvalho Chehab 2012-11-23 10:31 ` Hans Verkuil 1 sibling, 0 replies; 41+ messages in thread From: Mauro Carvalho Chehab @ 2012-11-12 18:54 UTC (permalink / raw) To: Alexey Klimov; +Cc: Hans Verkuil, media-workshop, linux-media Em Mon, 12 Nov 2012 22:41:57 +0400 Alexey Klimov <klimov.linux@gmail.com> escreveu: > Hi Mauro, Hans, all, > > On Fri, Nov 2, 2012 at 6:34 PM, Mauro Carvalho Chehab > <mchehab@redhat.com> wrote: > > Em Fri, 2 Nov 2012 14:47:49 +0100 > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > > > >> On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote: > >> > Em Thu, 1 Nov 2012 14:12:44 -0200 > >> > Mauro Carvalho Chehab <mchehab@redhat.com> escreveu: > >> > > >> > > Em Thu, 1 Nov 2012 16:44:50 +0100 > >> > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > >> > > > >> > > > On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: > >> > > > > Hi Hans, > >> > > > > > >> > > > > Em Mon, 22 Oct 2012 10:35:56 +0200 > >> > > > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > >> > > > > > >> > > > > > Hi all, > >> > > > > > > >> > > > > > This is the tentative agenda for the media workshop on November 8, 2012. > >> > > > > > If you have additional things that you want to discuss, or something is wrong > >> > > > > > or incomplete in this list, please let me know so I can update the list. > >> > > > > > >> > > > > Thank you for taking care of it. > >> > > > > > >> > > > > > - Explain current merging process (Mauro) > >> > > > > > - Open floor for discussions on how to improve it (Mauro) > >> > > > > > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for > >> > > > > > staging and mainline acceptance: which frameworks to use, v4l2-compliance, > >> > > > > > etc. (Hans Verkuil) > >> > > > > > - V4L2 ambiguities (Hans Verkuil) > >> > > > > > - TSMux device (a mux rather than a demux): Alain Volmat > >> > > > > > - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) > >> > > > > > - Device tree support (Guennadi, not known yet whether this topic is needed) > >> > > > > > - Creating/selecting contexts for hardware that supports this (Samsung, only > >> > > > > > if time is available) > >> > > > > > >> > > > > I have an extra theme for discussions there: what should we do with the drivers > >> > > > > that don't have any MAINTAINERS entry. > >> > > > > >> > > > I've added this topic to the list. > >> > > > >> > > Thanks! > >> > > > >> > > > > It probably makes sense to mark them as "Orphan" (or, at least, have some > >> > > > > criteria to mark them as such). Perhaps before doing that, we could try > >> > > > > to see if are there any developer at the community with time and patience > >> > > > > to handle them. > >> > > > > > >> > > > > This could of course be handled as part of the discussions about how to improve > >> > > > > the merge process, but I suspect that this could generate enough discussions > >> > > > > to be handled as a separate theme. > >> > > > > >> > > > Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can > >> > > > test. So while I wouldn't like to be marked as 'The Maintainer of driver X' > >> > > > (since I simply don't have the time for that), I wouldn't mind being marked as > >> > > > someone who can at least test patches if needed. > >> > > > >> > > There are several "maintainance" status there: > >> > > > >> > > S: Status, one of the following: > >> > > Supported: Someone is actually paid to look after this. > >> > > Maintained: Someone actually looks after it. > >> > > Odd Fixes: It has a maintainer but they don't have time to do > >> > > much other than throw the odd patch in. See below.. > >> > > Orphan: No current maintainer [but maybe you could take the > >> > > role as you write your new code]. > >> > > Obsolete: Old code. Something tagged obsolete generally means > >> > > it has been replaced by a better system and you > >> > > should be using that. > >> > > > >> > > (btw, I just realized that I should be changing the EDAC drivers I maintain > >> > > to Supported; the media drivers I maintain should be kept as Maintained). > >> > > > >> > > I suspect that the "maintainer-light" category for those radio and similar > >> > > old stuff is likely "Odd Fixes". > >> > > > >> > > > > There are some issues by not having a MAINTAINERS entry: > >> > > > > - patches may not flow into the driver maintainer; > >> > > > > - patches will likely be applied without tests/reviews or may > >> > > > > stay for a long time queued; > >> > > > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return > >> > > > > any maintainer[1]. > >> > > > > > >> > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would > >> > > > > delay a lot the patch review process, if applied for every patch, with > >> > > > > unreliable and doubtful results. I don't do it, due to the large volume > >> > > > > of patches, and because the 'other' results aren't typically the driver > >> > > > > maintainer. > >> > > > > > >> > > > > An example of this is the results for a patch I just applied > >> > > > > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): > >> > > > > > >> > > > > $ git show --pretty=email|./scripts/get_maintainer.pl > >> > > > > Mauro Carvalho Chehab <mchehab@infradead.org> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%) > >> > > > > Hans Verkuil <hans.verkuil@cisco.com> (commit_signer:4/7=57%) > >> > > > > Anatolij Gustschin <agust@denx.de> (commit_signer:1/7=14%) > >> > > > > Wei Yongjun <yongjun_wei@trendmicro.com.cn> (commit_signer:1/7=14%) > >> > > > > Hans de Goede <hdegoede@redhat.com> (commit_signer:1/7=14%) > >> > > > > linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) > >> > > > > linux-kernel@vger.kernel.org (open list) > >> > > > > > >> > > > > According with this driver's copyrights: > >> > > > > > >> > > > > * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. > >> > > > > * > >> > > > > * Freescale VIU video driver > >> > > > > * > >> > > > > * Authors: Hongjun Chen <hong-jun.chen@freescale.com> > >> > > > > * Porting to 2.6.35 by DENX Software Engineering, > >> > > > > * Anatolij Gustschin <agust@denx.de> > >> > > > > > >> > > > > The driver author (Hongjun Chen <hong-jun.chen@freescale.com>) was not even > >> > > > > shown there, and the co-author got only 15% hit, while I got 100% and Hans > >> > > > > got 57%. > >> > > > > > >> > > > > This happens not only to this driver. In a matter of fact, on most cases where > >> > > > > no MAINTAINERS entry exist, the driver's author gets a very small hit chance, > >> > > > > as, on several of those drivers, the author doesn't post anything else but > >> > > > > the initial patch series. > >> > > > > >> > > > We probably need to have an entry for all the media drivers, even if it just > >> > > > points to the linux-media mailinglist as being the 'collective default maintainer'. > >> > > > >> > > Yes, I think that all media drivers should be there. I prefer to tag the ones > >> > > that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates > >> > > that help is wanted. > >> > > >> > I wrote a small shell script to see what's missing, using the analyze_build.pl script > >> > at media-build devel_scripts dir: > >> > > >> > DIR=$(dirname $0) > >> > > >> > $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers > >> > grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained > >> > grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint > >> > > >> > I excluded the core files from the list, as they don't need any specific entry. RC > >> > keymaps is also a special case, as I don't think any maintainer is needed for them. > >> > > >> > Basically, analyze_build.pl says that there are 613 drivers under drivers/media. > >> > The above script shows 348 drivers without an explicit maintainer. So, only 43% > >> > of the drivers have a formal maintainer. > >> > > >> > Yet, on the list below, I think several of them can be easily tagged as > >> > "Odd fixes", like cx88 and saa7134. > >> > > >> > I think I'll send today a few RFC MAINTAINERS patches for some stuff below that > >> > I can myself be added as "Odd fixes". Yet, I would very much prefer if someone > >> > with more time than me could be taking over the "Odd fixes" patches I'll propose. > >> > > >> > Regards, > >> > Mauro > >> > >> These two are 'Supported' by me: > >> > >> i2c/ad9389b.ko = i2c/ad9389b.c > >> i2c/adv7604.ko = i2c/adv7604.c > >> > >> These are 'Maintained' by me: > >> > >> i2c/cx2341x.ko = i2c/cx2341x.c > >> parport/bw-qcam.ko = parport/bw-qcam.c > >> parport/c-qcam.ko = parport/c-qcam.c > >> radio/dsbr100.ko = radio/dsbr100.c > >> radio/radio-cadet.ko = radio/radio-cadet.c > >> radio/radio-isa.ko = radio/radio-isa.c > >> radio/radio-keene.ko = radio/radio-keene.c > > > > OK. Could you please send patches for those? I think that the better is > > to write one patch by each MAINTAINERS entry (except, of course, if there > > are consecutive entries), as I suspect that MAINTAINERS is likely one > > of top-rated merge-conflicts file. > > > >> > >> There are more radio drivers that can have that status, but I would need > >> to check that when I'm back in Oslo. > >> > >> I can do 'Odd fixes' for the following: > >> > >> i2c/cx25840/cx25840.ko = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c > >> i2c/m52790.ko = i2c/m52790.c > >> i2c/msp3400.ko = i2c/msp3400-driver.c i2c/msp3400-kthreads.c > >> i2c/saa6588.ko = i2c/saa6588.c > >> i2c/saa7110.ko = i2c/saa7110.c > >> i2c/saa7115.ko = i2c/saa7115.c > >> i2c/saa7127.ko = i2c/saa7127.c > >> i2c/saa717x.ko = i2c/saa717x.c > >> i2c/tda7432.ko = i2c/tda7432.c > >> i2c/tda9840.ko = i2c/tda9840.c > >> i2c/tea6415c.ko = i2c/tea6415c.c > >> i2c/tea6420.ko = i2c/tea6420.c > >> i2c/tvaudio.ko = i2c/tvaudio.c > >> i2c/tveeprom.ko = i2c/tveeprom.c > > > >> i2c/tvp5150.ko = i2c/tvp5150.c > > While I don't mind if you want to do odd fixes for this device, > > I think I can maintain this one, as the "default" device I use for > > random tests has this chipset (HVR-950), and I wrote this driver. > > > >> i2c/wm8739.ko = i2c/wm8739.c > >> i2c/wm8775.ko = i2c/wm8775.c > >> parport/pms.ko = parport/pms.c > >> platform/vivi.ko = platform/vivi.c > >> radio/radio-aimslab.ko = radio/radio-aimslab.c > >> radio/radio-gemtek.ko = radio/radio-gemtek.c > >> radio/radio-maxiradio.ko = radio/radio-maxiradio.c > >> radio/radio-miropcm20.ko = radio/radio-miropcm20.c > >> radio/radio-mr800.ko = radio/radio-mr800.c > >> radio/radio-rtrack2.ko = radio/radio-rtrack2.c > >> radio/radio-si4713.ko = radio/radio-si4713.c > > > >> usb/cx231xx/cx231xx-alsa.ko = usb/cx231xx/cx231xx-audio.c > >> usb/cx231xx/cx231xx-dvb.ko = usb/cx231xx/cx231xx-dvb.c > >> usb/cx231xx/cx231xx-input.ko = usb/cx231xx/cx231xx-input.c > >> usb/cx231xx/cx231xx.ko = + > > I think we should check if the driver author is not interested on > > taking maintainership for this one, before putting it on Odd fixes status. > > I'm very sorry for long silence but i'm ready to take maintainership > for radio-mr800. By the way, i think that only fixes will be present > for this driver in the future. Good. could you please send us a patch for Maintainers then? > Is it possible for driver to have two maintainers or for example one > person marked as maintainer and another one marked as "odd fixes" ? Well, it is possible to have two maintainers for a driver. A few of them have it, but, AFAIKT, the driver maintainership status should be just one for the entire driver. > I > mean i'm interested to be in c/c regarding all email, news, > interesting patches for radio-mr800, dsbr100 and usb radio part of > si470x but i don't know how to mark it that i want to help with these > drivers. I have only dsbr100, mr800 and kworld fm700 (based on si470x) > usb radios and i'm ready to test any patches and help as much as i > can. If the above drivers have a maintainer, the patch adding you there as another maintainer should be sent by him (or with his ack). > I don't have usb radio for radio-keene.c driver but i probably will > take a look how to buy it here.. > > And i'm also ready to maintain driver radio-ma901.c. I posted patches > for this device about two weeks ago. Driver is rather small (first > working version) but i hope to add more features there in future. Ok. Please send us a maintainership patch for it as well. Thank you! Mauro > > Best regards and wishes, > Alexey Klimov ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-12 18:41 ` drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] " Alexey Klimov 2012-11-12 18:54 ` Mauro Carvalho Chehab @ 2012-11-23 10:31 ` Hans Verkuil 2012-11-25 23:18 ` Alexey Klimov 1 sibling, 1 reply; 41+ messages in thread From: Hans Verkuil @ 2012-11-23 10:31 UTC (permalink / raw) To: Alexey Klimov; +Cc: Mauro Carvalho Chehab, media-workshop, linux-media Hi Alexey, On Mon November 12 2012 19:41:57 Alexey Klimov wrote: > Hi Mauro, Hans, all, > > On Fri, Nov 2, 2012 at 6:34 PM, Mauro Carvalho Chehab > <mchehab@redhat.com> wrote: > > Em Fri, 2 Nov 2012 14:47:49 +0100 > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > > > >> On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote: > >> > Em Thu, 1 Nov 2012 14:12:44 -0200 > >> > Mauro Carvalho Chehab <mchehab@redhat.com> escreveu: > >> > > >> > > Em Thu, 1 Nov 2012 16:44:50 +0100 > >> > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > >> > > > >> > > > On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: > >> > > > > Hi Hans, > >> > > > > > >> > > > > Em Mon, 22 Oct 2012 10:35:56 +0200 > >> > > > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > >> > > > > > >> > > > > > Hi all, > >> > > > > > > >> > > > > > This is the tentative agenda for the media workshop on November 8, 2012. > >> > > > > > If you have additional things that you want to discuss, or something is wrong > >> > > > > > or incomplete in this list, please let me know so I can update the list. > >> > > > > > >> > > > > Thank you for taking care of it. > >> > > > > > >> > > > > > - Explain current merging process (Mauro) > >> > > > > > - Open floor for discussions on how to improve it (Mauro) > >> > > > > > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for > >> > > > > > staging and mainline acceptance: which frameworks to use, v4l2-compliance, > >> > > > > > etc. (Hans Verkuil) > >> > > > > > - V4L2 ambiguities (Hans Verkuil) > >> > > > > > - TSMux device (a mux rather than a demux): Alain Volmat > >> > > > > > - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) > >> > > > > > - Device tree support (Guennadi, not known yet whether this topic is needed) > >> > > > > > - Creating/selecting contexts for hardware that supports this (Samsung, only > >> > > > > > if time is available) > >> > > > > > >> > > > > I have an extra theme for discussions there: what should we do with the drivers > >> > > > > that don't have any MAINTAINERS entry. > >> > > > > >> > > > I've added this topic to the list. > >> > > > >> > > Thanks! > >> > > > >> > > > > It probably makes sense to mark them as "Orphan" (or, at least, have some > >> > > > > criteria to mark them as such). Perhaps before doing that, we could try > >> > > > > to see if are there any developer at the community with time and patience > >> > > > > to handle them. > >> > > > > > >> > > > > This could of course be handled as part of the discussions about how to improve > >> > > > > the merge process, but I suspect that this could generate enough discussions > >> > > > > to be handled as a separate theme. > >> > > > > >> > > > Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can > >> > > > test. So while I wouldn't like to be marked as 'The Maintainer of driver X' > >> > > > (since I simply don't have the time for that), I wouldn't mind being marked as > >> > > > someone who can at least test patches if needed. > >> > > > >> > > There are several "maintainance" status there: > >> > > > >> > > S: Status, one of the following: > >> > > Supported: Someone is actually paid to look after this. > >> > > Maintained: Someone actually looks after it. > >> > > Odd Fixes: It has a maintainer but they don't have time to do > >> > > much other than throw the odd patch in. See below.. > >> > > Orphan: No current maintainer [but maybe you could take the > >> > > role as you write your new code]. > >> > > Obsolete: Old code. Something tagged obsolete generally means > >> > > it has been replaced by a better system and you > >> > > should be using that. > >> > > > >> > > (btw, I just realized that I should be changing the EDAC drivers I maintain > >> > > to Supported; the media drivers I maintain should be kept as Maintained). > >> > > > >> > > I suspect that the "maintainer-light" category for those radio and similar > >> > > old stuff is likely "Odd Fixes". > >> > > > >> > > > > There are some issues by not having a MAINTAINERS entry: > >> > > > > - patches may not flow into the driver maintainer; > >> > > > > - patches will likely be applied without tests/reviews or may > >> > > > > stay for a long time queued; > >> > > > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return > >> > > > > any maintainer[1]. > >> > > > > > >> > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would > >> > > > > delay a lot the patch review process, if applied for every patch, with > >> > > > > unreliable and doubtful results. I don't do it, due to the large volume > >> > > > > of patches, and because the 'other' results aren't typically the driver > >> > > > > maintainer. > >> > > > > > >> > > > > An example of this is the results for a patch I just applied > >> > > > > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): > >> > > > > > >> > > > > $ git show --pretty=email|./scripts/get_maintainer.pl > >> > > > > Mauro Carvalho Chehab <mchehab@infradead.org> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%) > >> > > > > Hans Verkuil <hans.verkuil@cisco.com> (commit_signer:4/7=57%) > >> > > > > Anatolij Gustschin <agust@denx.de> (commit_signer:1/7=14%) > >> > > > > Wei Yongjun <yongjun_wei@trendmicro.com.cn> (commit_signer:1/7=14%) > >> > > > > Hans de Goede <hdegoede@redhat.com> (commit_signer:1/7=14%) > >> > > > > linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) > >> > > > > linux-kernel@vger.kernel.org (open list) > >> > > > > > >> > > > > According with this driver's copyrights: > >> > > > > > >> > > > > * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. > >> > > > > * > >> > > > > * Freescale VIU video driver > >> > > > > * > >> > > > > * Authors: Hongjun Chen <hong-jun.chen@freescale.com> > >> > > > > * Porting to 2.6.35 by DENX Software Engineering, > >> > > > > * Anatolij Gustschin <agust@denx.de> > >> > > > > > >> > > > > The driver author (Hongjun Chen <hong-jun.chen@freescale.com>) was not even > >> > > > > shown there, and the co-author got only 15% hit, while I got 100% and Hans > >> > > > > got 57%. > >> > > > > > >> > > > > This happens not only to this driver. In a matter of fact, on most cases where > >> > > > > no MAINTAINERS entry exist, the driver's author gets a very small hit chance, > >> > > > > as, on several of those drivers, the author doesn't post anything else but > >> > > > > the initial patch series. > >> > > > > >> > > > We probably need to have an entry for all the media drivers, even if it just > >> > > > points to the linux-media mailinglist as being the 'collective default maintainer'. > >> > > > >> > > Yes, I think that all media drivers should be there. I prefer to tag the ones > >> > > that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates > >> > > that help is wanted. > >> > > >> > I wrote a small shell script to see what's missing, using the analyze_build.pl script > >> > at media-build devel_scripts dir: > >> > > >> > DIR=$(dirname $0) > >> > > >> > $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers > >> > grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained > >> > grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint > >> > > >> > I excluded the core files from the list, as they don't need any specific entry. RC > >> > keymaps is also a special case, as I don't think any maintainer is needed for them. > >> > > >> > Basically, analyze_build.pl says that there are 613 drivers under drivers/media. > >> > The above script shows 348 drivers without an explicit maintainer. So, only 43% > >> > of the drivers have a formal maintainer. > >> > > >> > Yet, on the list below, I think several of them can be easily tagged as > >> > "Odd fixes", like cx88 and saa7134. > >> > > >> > I think I'll send today a few RFC MAINTAINERS patches for some stuff below that > >> > I can myself be added as "Odd fixes". Yet, I would very much prefer if someone > >> > with more time than me could be taking over the "Odd fixes" patches I'll propose. > >> > > >> > Regards, > >> > Mauro > >> > >> These two are 'Supported' by me: > >> > >> i2c/ad9389b.ko = i2c/ad9389b.c > >> i2c/adv7604.ko = i2c/adv7604.c > >> > >> These are 'Maintained' by me: > >> > >> i2c/cx2341x.ko = i2c/cx2341x.c > >> parport/bw-qcam.ko = parport/bw-qcam.c > >> parport/c-qcam.ko = parport/c-qcam.c > >> radio/dsbr100.ko = radio/dsbr100.c > >> radio/radio-cadet.ko = radio/radio-cadet.c > >> radio/radio-isa.ko = radio/radio-isa.c > >> radio/radio-keene.ko = radio/radio-keene.c > > > > OK. Could you please send patches for those? I think that the better is > > to write one patch by each MAINTAINERS entry (except, of course, if there > > are consecutive entries), as I suspect that MAINTAINERS is likely one > > of top-rated merge-conflicts file. > > > >> > >> There are more radio drivers that can have that status, but I would need > >> to check that when I'm back in Oslo. > >> > >> I can do 'Odd fixes' for the following: > >> > >> i2c/cx25840/cx25840.ko = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c > >> i2c/m52790.ko = i2c/m52790.c > >> i2c/msp3400.ko = i2c/msp3400-driver.c i2c/msp3400-kthreads.c > >> i2c/saa6588.ko = i2c/saa6588.c > >> i2c/saa7110.ko = i2c/saa7110.c > >> i2c/saa7115.ko = i2c/saa7115.c > >> i2c/saa7127.ko = i2c/saa7127.c > >> i2c/saa717x.ko = i2c/saa717x.c > >> i2c/tda7432.ko = i2c/tda7432.c > >> i2c/tda9840.ko = i2c/tda9840.c > >> i2c/tea6415c.ko = i2c/tea6415c.c > >> i2c/tea6420.ko = i2c/tea6420.c > >> i2c/tvaudio.ko = i2c/tvaudio.c > >> i2c/tveeprom.ko = i2c/tveeprom.c > > > >> i2c/tvp5150.ko = i2c/tvp5150.c > > While I don't mind if you want to do odd fixes for this device, > > I think I can maintain this one, as the "default" device I use for > > random tests has this chipset (HVR-950), and I wrote this driver. > > > >> i2c/wm8739.ko = i2c/wm8739.c > >> i2c/wm8775.ko = i2c/wm8775.c > >> parport/pms.ko = parport/pms.c > >> platform/vivi.ko = platform/vivi.c > >> radio/radio-aimslab.ko = radio/radio-aimslab.c > >> radio/radio-gemtek.ko = radio/radio-gemtek.c > >> radio/radio-maxiradio.ko = radio/radio-maxiradio.c > >> radio/radio-miropcm20.ko = radio/radio-miropcm20.c > >> radio/radio-mr800.ko = radio/radio-mr800.c > >> radio/radio-rtrack2.ko = radio/radio-rtrack2.c > >> radio/radio-si4713.ko = radio/radio-si4713.c > > > >> usb/cx231xx/cx231xx-alsa.ko = usb/cx231xx/cx231xx-audio.c > >> usb/cx231xx/cx231xx-dvb.ko = usb/cx231xx/cx231xx-dvb.c > >> usb/cx231xx/cx231xx-input.ko = usb/cx231xx/cx231xx-input.c > >> usb/cx231xx/cx231xx.ko = + > > I think we should check if the driver author is not interested on > > taking maintainership for this one, before putting it on Odd fixes status. > > I'm very sorry for long silence but i'm ready to take maintainership > for radio-mr800. By the way, i think that only fixes will be present > for this driver in the future. > > Is it possible for driver to have two maintainers or for example one > person marked as maintainer and another one marked as "odd fixes" ? I > mean i'm interested to be in c/c regarding all email, news, > interesting patches for radio-mr800, dsbr100 and usb radio part of > si470x but i don't know how to mark it that i want to help with these > drivers. I have only dsbr100, mr800 and kworld fm700 (based on si470x) > usb radios and i'm ready to test any patches and help as much as i > can. I saw that you made a MAINTAINERS entry for radio-mr800, but not for dsbr100 or si470x. Do you want to be the maintainer for those two, or shall I add myself as the 'Odd Fixes' entry? I have hardware for both. > I don't have usb radio for radio-keene.c driver but i probably will > take a look how to buy it here.. I wrote the driver for that one, so I'll be the maintainer for this driver (I'm preparing MAINTAINERS patches as I write this). > > And i'm also ready to maintain driver radio-ma901.c. I posted patches > for this device about two weeks ago. Driver is rather small (first > working version) but i hope to add more features there in future. I missed this post, I'll try to do a quick review today. Did you run v4l2-compliance on this driver? If not, then you should do that (v4l2-compliance -r /dev/radioX) and fix any errors it produces. Regards, Hans ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-23 10:31 ` Hans Verkuil @ 2012-11-25 23:18 ` Alexey Klimov 2012-11-26 14:15 ` Hans Verkuil 0 siblings, 1 reply; 41+ messages in thread From: Alexey Klimov @ 2012-11-25 23:18 UTC (permalink / raw) To: Hans Verkuil; +Cc: Mauro Carvalho Chehab, media-workshop, linux-media Hi Hans, On Fri, Nov 23, 2012 at 2:31 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote: > Hi Alexey, > > On Mon November 12 2012 19:41:57 Alexey Klimov wrote: >> Hi Mauro, Hans, all, >> >> On Fri, Nov 2, 2012 at 6:34 PM, Mauro Carvalho Chehab >> <mchehab@redhat.com> wrote: >> > Em Fri, 2 Nov 2012 14:47:49 +0100 >> > Hans Verkuil <hverkuil@xs4all.nl> escreveu: >> > >> >> On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote: >> >> > Em Thu, 1 Nov 2012 14:12:44 -0200 >> >> > Mauro Carvalho Chehab <mchehab@redhat.com> escreveu: >> >> > >> >> > > Em Thu, 1 Nov 2012 16:44:50 +0100 >> >> > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: >> >> > > >> >> > > > On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: >> >> > > > > Hi Hans, >> >> > > > > >> >> > > > > Em Mon, 22 Oct 2012 10:35:56 +0200 >> >> > > > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: >> >> > > > > >> >> > > > > > Hi all, >> >> > > > > > >> >> > > > > > This is the tentative agenda for the media workshop on November 8, 2012. >> >> > > > > > If you have additional things that you want to discuss, or something is wrong >> >> > > > > > or incomplete in this list, please let me know so I can update the list. >> >> > > > > >> >> > > > > Thank you for taking care of it. >> >> > > > > >> >> > > > > > - Explain current merging process (Mauro) >> >> > > > > > - Open floor for discussions on how to improve it (Mauro) >> >> > > > > > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for >> >> > > > > > staging and mainline acceptance: which frameworks to use, v4l2-compliance, >> >> > > > > > etc. (Hans Verkuil) >> >> > > > > > - V4L2 ambiguities (Hans Verkuil) >> >> > > > > > - TSMux device (a mux rather than a demux): Alain Volmat >> >> > > > > > - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) >> >> > > > > > - Device tree support (Guennadi, not known yet whether this topic is needed) >> >> > > > > > - Creating/selecting contexts for hardware that supports this (Samsung, only >> >> > > > > > if time is available) >> >> > > > > >> >> > > > > I have an extra theme for discussions there: what should we do with the drivers >> >> > > > > that don't have any MAINTAINERS entry. >> >> > > > >> >> > > > I've added this topic to the list. >> >> > > >> >> > > Thanks! >> >> > > >> >> > > > > It probably makes sense to mark them as "Orphan" (or, at least, have some >> >> > > > > criteria to mark them as such). Perhaps before doing that, we could try >> >> > > > > to see if are there any developer at the community with time and patience >> >> > > > > to handle them. >> >> > > > > >> >> > > > > This could of course be handled as part of the discussions about how to improve >> >> > > > > the merge process, but I suspect that this could generate enough discussions >> >> > > > > to be handled as a separate theme. >> >> > > > >> >> > > > Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can >> >> > > > test. So while I wouldn't like to be marked as 'The Maintainer of driver X' >> >> > > > (since I simply don't have the time for that), I wouldn't mind being marked as >> >> > > > someone who can at least test patches if needed. >> >> > > >> >> > > There are several "maintainance" status there: >> >> > > >> >> > > S: Status, one of the following: >> >> > > Supported: Someone is actually paid to look after this. >> >> > > Maintained: Someone actually looks after it. >> >> > > Odd Fixes: It has a maintainer but they don't have time to do >> >> > > much other than throw the odd patch in. See below.. >> >> > > Orphan: No current maintainer [but maybe you could take the >> >> > > role as you write your new code]. >> >> > > Obsolete: Old code. Something tagged obsolete generally means >> >> > > it has been replaced by a better system and you >> >> > > should be using that. >> >> > > >> >> > > (btw, I just realized that I should be changing the EDAC drivers I maintain >> >> > > to Supported; the media drivers I maintain should be kept as Maintained). >> >> > > >> >> > > I suspect that the "maintainer-light" category for those radio and similar >> >> > > old stuff is likely "Odd Fixes". >> >> > > >> >> > > > > There are some issues by not having a MAINTAINERS entry: >> >> > > > > - patches may not flow into the driver maintainer; >> >> > > > > - patches will likely be applied without tests/reviews or may >> >> > > > > stay for a long time queued; >> >> > > > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return >> >> > > > > any maintainer[1]. >> >> > > > > >> >> > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would >> >> > > > > delay a lot the patch review process, if applied for every patch, with >> >> > > > > unreliable and doubtful results. I don't do it, due to the large volume >> >> > > > > of patches, and because the 'other' results aren't typically the driver >> >> > > > > maintainer. >> >> > > > > >> >> > > > > An example of this is the results for a patch I just applied >> >> > > > > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): >> >> > > > > >> >> > > > > $ git show --pretty=email|./scripts/get_maintainer.pl >> >> > > > > Mauro Carvalho Chehab <mchehab@infradead.org> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%) >> >> > > > > Hans Verkuil <hans.verkuil@cisco.com> (commit_signer:4/7=57%) >> >> > > > > Anatolij Gustschin <agust@denx.de> (commit_signer:1/7=14%) >> >> > > > > Wei Yongjun <yongjun_wei@trendmicro.com.cn> (commit_signer:1/7=14%) >> >> > > > > Hans de Goede <hdegoede@redhat.com> (commit_signer:1/7=14%) >> >> > > > > linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) >> >> > > > > linux-kernel@vger.kernel.org (open list) >> >> > > > > >> >> > > > > According with this driver's copyrights: >> >> > > > > >> >> > > > > * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. >> >> > > > > * >> >> > > > > * Freescale VIU video driver >> >> > > > > * >> >> > > > > * Authors: Hongjun Chen <hong-jun.chen@freescale.com> >> >> > > > > * Porting to 2.6.35 by DENX Software Engineering, >> >> > > > > * Anatolij Gustschin <agust@denx.de> >> >> > > > > >> >> > > > > The driver author (Hongjun Chen <hong-jun.chen@freescale.com>) was not even >> >> > > > > shown there, and the co-author got only 15% hit, while I got 100% and Hans >> >> > > > > got 57%. >> >> > > > > >> >> > > > > This happens not only to this driver. In a matter of fact, on most cases where >> >> > > > > no MAINTAINERS entry exist, the driver's author gets a very small hit chance, >> >> > > > > as, on several of those drivers, the author doesn't post anything else but >> >> > > > > the initial patch series. >> >> > > > >> >> > > > We probably need to have an entry for all the media drivers, even if it just >> >> > > > points to the linux-media mailinglist as being the 'collective default maintainer'. >> >> > > >> >> > > Yes, I think that all media drivers should be there. I prefer to tag the ones >> >> > > that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates >> >> > > that help is wanted. >> >> > >> >> > I wrote a small shell script to see what's missing, using the analyze_build.pl script >> >> > at media-build devel_scripts dir: >> >> > >> >> > DIR=$(dirname $0) >> >> > >> >> > $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers >> >> > grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained >> >> > grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint >> >> > >> >> > I excluded the core files from the list, as they don't need any specific entry. RC >> >> > keymaps is also a special case, as I don't think any maintainer is needed for them. >> >> > >> >> > Basically, analyze_build.pl says that there are 613 drivers under drivers/media. >> >> > The above script shows 348 drivers without an explicit maintainer. So, only 43% >> >> > of the drivers have a formal maintainer. >> >> > >> >> > Yet, on the list below, I think several of them can be easily tagged as >> >> > "Odd fixes", like cx88 and saa7134. >> >> > >> >> > I think I'll send today a few RFC MAINTAINERS patches for some stuff below that >> >> > I can myself be added as "Odd fixes". Yet, I would very much prefer if someone >> >> > with more time than me could be taking over the "Odd fixes" patches I'll propose. >> >> > >> >> > Regards, >> >> > Mauro >> >> >> >> These two are 'Supported' by me: >> >> >> >> i2c/ad9389b.ko = i2c/ad9389b.c >> >> i2c/adv7604.ko = i2c/adv7604.c >> >> >> >> These are 'Maintained' by me: >> >> >> >> i2c/cx2341x.ko = i2c/cx2341x.c >> >> parport/bw-qcam.ko = parport/bw-qcam.c >> >> parport/c-qcam.ko = parport/c-qcam.c >> >> radio/dsbr100.ko = radio/dsbr100.c >> >> radio/radio-cadet.ko = radio/radio-cadet.c >> >> radio/radio-isa.ko = radio/radio-isa.c >> >> radio/radio-keene.ko = radio/radio-keene.c >> > >> > OK. Could you please send patches for those? I think that the better is >> > to write one patch by each MAINTAINERS entry (except, of course, if there >> > are consecutive entries), as I suspect that MAINTAINERS is likely one >> > of top-rated merge-conflicts file. >> > >> >> >> >> There are more radio drivers that can have that status, but I would need >> >> to check that when I'm back in Oslo. >> >> >> >> I can do 'Odd fixes' for the following: >> >> >> >> i2c/cx25840/cx25840.ko = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c >> >> i2c/m52790.ko = i2c/m52790.c >> >> i2c/msp3400.ko = i2c/msp3400-driver.c i2c/msp3400-kthreads.c >> >> i2c/saa6588.ko = i2c/saa6588.c >> >> i2c/saa7110.ko = i2c/saa7110.c >> >> i2c/saa7115.ko = i2c/saa7115.c >> >> i2c/saa7127.ko = i2c/saa7127.c >> >> i2c/saa717x.ko = i2c/saa717x.c >> >> i2c/tda7432.ko = i2c/tda7432.c >> >> i2c/tda9840.ko = i2c/tda9840.c >> >> i2c/tea6415c.ko = i2c/tea6415c.c >> >> i2c/tea6420.ko = i2c/tea6420.c >> >> i2c/tvaudio.ko = i2c/tvaudio.c >> >> i2c/tveeprom.ko = i2c/tveeprom.c >> > >> >> i2c/tvp5150.ko = i2c/tvp5150.c >> > While I don't mind if you want to do odd fixes for this device, >> > I think I can maintain this one, as the "default" device I use for >> > random tests has this chipset (HVR-950), and I wrote this driver. >> > >> >> i2c/wm8739.ko = i2c/wm8739.c >> >> i2c/wm8775.ko = i2c/wm8775.c >> >> parport/pms.ko = parport/pms.c >> >> platform/vivi.ko = platform/vivi.c >> >> radio/radio-aimslab.ko = radio/radio-aimslab.c >> >> radio/radio-gemtek.ko = radio/radio-gemtek.c >> >> radio/radio-maxiradio.ko = radio/radio-maxiradio.c >> >> radio/radio-miropcm20.ko = radio/radio-miropcm20.c >> >> radio/radio-mr800.ko = radio/radio-mr800.c >> >> radio/radio-rtrack2.ko = radio/radio-rtrack2.c >> >> radio/radio-si4713.ko = radio/radio-si4713.c >> > >> >> usb/cx231xx/cx231xx-alsa.ko = usb/cx231xx/cx231xx-audio.c >> >> usb/cx231xx/cx231xx-dvb.ko = usb/cx231xx/cx231xx-dvb.c >> >> usb/cx231xx/cx231xx-input.ko = usb/cx231xx/cx231xx-input.c >> >> usb/cx231xx/cx231xx.ko = + >> > I think we should check if the driver author is not interested on >> > taking maintainership for this one, before putting it on Odd fixes status. >> >> I'm very sorry for long silence but i'm ready to take maintainership >> for radio-mr800. By the way, i think that only fixes will be present >> for this driver in the future. >> >> Is it possible for driver to have two maintainers or for example one >> person marked as maintainer and another one marked as "odd fixes" ? I >> mean i'm interested to be in c/c regarding all email, news, >> interesting patches for radio-mr800, dsbr100 and usb radio part of >> si470x but i don't know how to mark it that i want to help with these >> drivers. I have only dsbr100, mr800 and kworld fm700 (based on si470x) >> usb radios and i'm ready to test any patches and help as much as i >> can. > > I saw that you made a MAINTAINERS entry for radio-mr800, but not for dsbr100 > or si470x. Do you want to be the maintainer for those two, or shall I add > myself as the 'Odd Fixes' entry? I have hardware for both. About si470x. It consists of two parts (usb and i2c interfaces) if i remember correctly. I have kworld fm700 usb radio only. I saw platforms with radio-si470x-i2c but never had chances to play with it. May be it's also better to ask Tobias and Joonyoung Shim. I don't think that i'm ready to maintain si470x driver but i'll be happy to be up to date with any changes and discussions about all usb radio drivers. I have usb gemtek radio 21 (dsbr100) and i'm ready to maintain it. I can prepare patch. Also i think that only fixes and corrections will be present for this driver in future. >> I don't have usb radio for radio-keene.c driver but i probably will >> take a look how to buy it here.. > > I wrote the driver for that one, so I'll be the maintainer for this driver > (I'm preparing MAINTAINERS patches as I write this). Oh, i never mean to take maintainership on keene radio (you're the author) :) I just thought how to buy it. >> And i'm also ready to maintain driver radio-ma901.c. I posted patches >> for this device about two weeks ago. Driver is rather small (first >> working version) but i hope to add more features there in future. > > I missed this post, I'll try to do a quick review today. > > Did you run v4l2-compliance on this driver? If not, then you should do that > (v4l2-compliance -r /dev/radioX) and fix any errors it produces. > > Regards, > > Hans No, i didn't know about this tool. Thanks. I'll run v4l2-compliance on /dev/radio and check. -- Best regards, Alexey ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-25 23:18 ` Alexey Klimov @ 2012-11-26 14:15 ` Hans Verkuil 2012-11-26 14:21 ` Alexey Klimov 0 siblings, 1 reply; 41+ messages in thread From: Hans Verkuil @ 2012-11-26 14:15 UTC (permalink / raw) To: Alexey Klimov; +Cc: Mauro Carvalho Chehab, media-workshop, linux-media On Mon 26 November 2012 00:18:30 Alexey Klimov wrote: > Hi Hans, > > On Fri, Nov 23, 2012 at 2:31 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote: > > Hi Alexey, > > > > On Mon November 12 2012 19:41:57 Alexey Klimov wrote: > >> Hi Mauro, Hans, all, > >> > >> On Fri, Nov 2, 2012 at 6:34 PM, Mauro Carvalho Chehab > >> <mchehab@redhat.com> wrote: > >> > Em Fri, 2 Nov 2012 14:47:49 +0100 > >> > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > >> > > >> >> On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote: > >> >> > Em Thu, 1 Nov 2012 14:12:44 -0200 > >> >> > Mauro Carvalho Chehab <mchehab@redhat.com> escreveu: > >> >> > > >> >> > > Em Thu, 1 Nov 2012 16:44:50 +0100 > >> >> > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > >> >> > > > >> >> > > > On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: > >> >> > > > > Hi Hans, > >> >> > > > > > >> >> > > > > Em Mon, 22 Oct 2012 10:35:56 +0200 > >> >> > > > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > >> >> > > > > > >> >> > > > > > Hi all, > >> >> > > > > > > >> >> > > > > > This is the tentative agenda for the media workshop on November 8, 2012. > >> >> > > > > > If you have additional things that you want to discuss, or something is wrong > >> >> > > > > > or incomplete in this list, please let me know so I can update the list. > >> >> > > > > > >> >> > > > > Thank you for taking care of it. > >> >> > > > > > >> >> > > > > > - Explain current merging process (Mauro) > >> >> > > > > > - Open floor for discussions on how to improve it (Mauro) > >> >> > > > > > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for > >> >> > > > > > staging and mainline acceptance: which frameworks to use, v4l2-compliance, > >> >> > > > > > etc. (Hans Verkuil) > >> >> > > > > > - V4L2 ambiguities (Hans Verkuil) > >> >> > > > > > - TSMux device (a mux rather than a demux): Alain Volmat > >> >> > > > > > - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) > >> >> > > > > > - Device tree support (Guennadi, not known yet whether this topic is needed) > >> >> > > > > > - Creating/selecting contexts for hardware that supports this (Samsung, only > >> >> > > > > > if time is available) > >> >> > > > > > >> >> > > > > I have an extra theme for discussions there: what should we do with the drivers > >> >> > > > > that don't have any MAINTAINERS entry. > >> >> > > > > >> >> > > > I've added this topic to the list. > >> >> > > > >> >> > > Thanks! > >> >> > > > >> >> > > > > It probably makes sense to mark them as "Orphan" (or, at least, have some > >> >> > > > > criteria to mark them as such). Perhaps before doing that, we could try > >> >> > > > > to see if are there any developer at the community with time and patience > >> >> > > > > to handle them. > >> >> > > > > > >> >> > > > > This could of course be handled as part of the discussions about how to improve > >> >> > > > > the merge process, but I suspect that this could generate enough discussions > >> >> > > > > to be handled as a separate theme. > >> >> > > > > >> >> > > > Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can > >> >> > > > test. So while I wouldn't like to be marked as 'The Maintainer of driver X' > >> >> > > > (since I simply don't have the time for that), I wouldn't mind being marked as > >> >> > > > someone who can at least test patches if needed. > >> >> > > > >> >> > > There are several "maintainance" status there: > >> >> > > > >> >> > > S: Status, one of the following: > >> >> > > Supported: Someone is actually paid to look after this. > >> >> > > Maintained: Someone actually looks after it. > >> >> > > Odd Fixes: It has a maintainer but they don't have time to do > >> >> > > much other than throw the odd patch in. See below.. > >> >> > > Orphan: No current maintainer [but maybe you could take the > >> >> > > role as you write your new code]. > >> >> > > Obsolete: Old code. Something tagged obsolete generally means > >> >> > > it has been replaced by a better system and you > >> >> > > should be using that. > >> >> > > > >> >> > > (btw, I just realized that I should be changing the EDAC drivers I maintain > >> >> > > to Supported; the media drivers I maintain should be kept as Maintained). > >> >> > > > >> >> > > I suspect that the "maintainer-light" category for those radio and similar > >> >> > > old stuff is likely "Odd Fixes". > >> >> > > > >> >> > > > > There are some issues by not having a MAINTAINERS entry: > >> >> > > > > - patches may not flow into the driver maintainer; > >> >> > > > > - patches will likely be applied without tests/reviews or may > >> >> > > > > stay for a long time queued; > >> >> > > > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return > >> >> > > > > any maintainer[1]. > >> >> > > > > > >> >> > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would > >> >> > > > > delay a lot the patch review process, if applied for every patch, with > >> >> > > > > unreliable and doubtful results. I don't do it, due to the large volume > >> >> > > > > of patches, and because the 'other' results aren't typically the driver > >> >> > > > > maintainer. > >> >> > > > > > >> >> > > > > An example of this is the results for a patch I just applied > >> >> > > > > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): > >> >> > > > > > >> >> > > > > $ git show --pretty=email|./scripts/get_maintainer.pl > >> >> > > > > Mauro Carvalho Chehab <mchehab@infradead.org> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%) > >> >> > > > > Hans Verkuil <hans.verkuil@cisco.com> (commit_signer:4/7=57%) > >> >> > > > > Anatolij Gustschin <agust@denx.de> (commit_signer:1/7=14%) > >> >> > > > > Wei Yongjun <yongjun_wei@trendmicro.com.cn> (commit_signer:1/7=14%) > >> >> > > > > Hans de Goede <hdegoede@redhat.com> (commit_signer:1/7=14%) > >> >> > > > > linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) > >> >> > > > > linux-kernel@vger.kernel.org (open list) > >> >> > > > > > >> >> > > > > According with this driver's copyrights: > >> >> > > > > > >> >> > > > > * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. > >> >> > > > > * > >> >> > > > > * Freescale VIU video driver > >> >> > > > > * > >> >> > > > > * Authors: Hongjun Chen <hong-jun.chen@freescale.com> > >> >> > > > > * Porting to 2.6.35 by DENX Software Engineering, > >> >> > > > > * Anatolij Gustschin <agust@denx.de> > >> >> > > > > > >> >> > > > > The driver author (Hongjun Chen <hong-jun.chen@freescale.com>) was not even > >> >> > > > > shown there, and the co-author got only 15% hit, while I got 100% and Hans > >> >> > > > > got 57%. > >> >> > > > > > >> >> > > > > This happens not only to this driver. In a matter of fact, on most cases where > >> >> > > > > no MAINTAINERS entry exist, the driver's author gets a very small hit chance, > >> >> > > > > as, on several of those drivers, the author doesn't post anything else but > >> >> > > > > the initial patch series. > >> >> > > > > >> >> > > > We probably need to have an entry for all the media drivers, even if it just > >> >> > > > points to the linux-media mailinglist as being the 'collective default maintainer'. > >> >> > > > >> >> > > Yes, I think that all media drivers should be there. I prefer to tag the ones > >> >> > > that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates > >> >> > > that help is wanted. > >> >> > > >> >> > I wrote a small shell script to see what's missing, using the analyze_build.pl script > >> >> > at media-build devel_scripts dir: > >> >> > > >> >> > DIR=$(dirname $0) > >> >> > > >> >> > $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers > >> >> > grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained > >> >> > grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint > >> >> > > >> >> > I excluded the core files from the list, as they don't need any specific entry. RC > >> >> > keymaps is also a special case, as I don't think any maintainer is needed for them. > >> >> > > >> >> > Basically, analyze_build.pl says that there are 613 drivers under drivers/media. > >> >> > The above script shows 348 drivers without an explicit maintainer. So, only 43% > >> >> > of the drivers have a formal maintainer. > >> >> > > >> >> > Yet, on the list below, I think several of them can be easily tagged as > >> >> > "Odd fixes", like cx88 and saa7134. > >> >> > > >> >> > I think I'll send today a few RFC MAINTAINERS patches for some stuff below that > >> >> > I can myself be added as "Odd fixes". Yet, I would very much prefer if someone > >> >> > with more time than me could be taking over the "Odd fixes" patches I'll propose. > >> >> > > >> >> > Regards, > >> >> > Mauro > >> >> > >> >> These two are 'Supported' by me: > >> >> > >> >> i2c/ad9389b.ko = i2c/ad9389b.c > >> >> i2c/adv7604.ko = i2c/adv7604.c > >> >> > >> >> These are 'Maintained' by me: > >> >> > >> >> i2c/cx2341x.ko = i2c/cx2341x.c > >> >> parport/bw-qcam.ko = parport/bw-qcam.c > >> >> parport/c-qcam.ko = parport/c-qcam.c > >> >> radio/dsbr100.ko = radio/dsbr100.c > >> >> radio/radio-cadet.ko = radio/radio-cadet.c > >> >> radio/radio-isa.ko = radio/radio-isa.c > >> >> radio/radio-keene.ko = radio/radio-keene.c > >> > > >> > OK. Could you please send patches for those? I think that the better is > >> > to write one patch by each MAINTAINERS entry (except, of course, if there > >> > are consecutive entries), as I suspect that MAINTAINERS is likely one > >> > of top-rated merge-conflicts file. > >> > > >> >> > >> >> There are more radio drivers that can have that status, but I would need > >> >> to check that when I'm back in Oslo. > >> >> > >> >> I can do 'Odd fixes' for the following: > >> >> > >> >> i2c/cx25840/cx25840.ko = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c > >> >> i2c/m52790.ko = i2c/m52790.c > >> >> i2c/msp3400.ko = i2c/msp3400-driver.c i2c/msp3400-kthreads.c > >> >> i2c/saa6588.ko = i2c/saa6588.c > >> >> i2c/saa7110.ko = i2c/saa7110.c > >> >> i2c/saa7115.ko = i2c/saa7115.c > >> >> i2c/saa7127.ko = i2c/saa7127.c > >> >> i2c/saa717x.ko = i2c/saa717x.c > >> >> i2c/tda7432.ko = i2c/tda7432.c > >> >> i2c/tda9840.ko = i2c/tda9840.c > >> >> i2c/tea6415c.ko = i2c/tea6415c.c > >> >> i2c/tea6420.ko = i2c/tea6420.c > >> >> i2c/tvaudio.ko = i2c/tvaudio.c > >> >> i2c/tveeprom.ko = i2c/tveeprom.c > >> > > >> >> i2c/tvp5150.ko = i2c/tvp5150.c > >> > While I don't mind if you want to do odd fixes for this device, > >> > I think I can maintain this one, as the "default" device I use for > >> > random tests has this chipset (HVR-950), and I wrote this driver. > >> > > >> >> i2c/wm8739.ko = i2c/wm8739.c > >> >> i2c/wm8775.ko = i2c/wm8775.c > >> >> parport/pms.ko = parport/pms.c > >> >> platform/vivi.ko = platform/vivi.c > >> >> radio/radio-aimslab.ko = radio/radio-aimslab.c > >> >> radio/radio-gemtek.ko = radio/radio-gemtek.c > >> >> radio/radio-maxiradio.ko = radio/radio-maxiradio.c > >> >> radio/radio-miropcm20.ko = radio/radio-miropcm20.c > >> >> radio/radio-mr800.ko = radio/radio-mr800.c > >> >> radio/radio-rtrack2.ko = radio/radio-rtrack2.c > >> >> radio/radio-si4713.ko = radio/radio-si4713.c > >> > > >> >> usb/cx231xx/cx231xx-alsa.ko = usb/cx231xx/cx231xx-audio.c > >> >> usb/cx231xx/cx231xx-dvb.ko = usb/cx231xx/cx231xx-dvb.c > >> >> usb/cx231xx/cx231xx-input.ko = usb/cx231xx/cx231xx-input.c > >> >> usb/cx231xx/cx231xx.ko = + > >> > I think we should check if the driver author is not interested on > >> > taking maintainership for this one, before putting it on Odd fixes status. > >> > >> I'm very sorry for long silence but i'm ready to take maintainership > >> for radio-mr800. By the way, i think that only fixes will be present > >> for this driver in the future. > >> > >> Is it possible for driver to have two maintainers or for example one > >> person marked as maintainer and another one marked as "odd fixes" ? I > >> mean i'm interested to be in c/c regarding all email, news, > >> interesting patches for radio-mr800, dsbr100 and usb radio part of > >> si470x but i don't know how to mark it that i want to help with these > >> drivers. I have only dsbr100, mr800 and kworld fm700 (based on si470x) > >> usb radios and i'm ready to test any patches and help as much as i > >> can. > > > > I saw that you made a MAINTAINERS entry for radio-mr800, but not for dsbr100 > > or si470x. Do you want to be the maintainer for those two, or shall I add > > myself as the 'Odd Fixes' entry? I have hardware for both. > > About si470x. It consists of two parts (usb and i2c interfaces) if i > remember correctly. > I have kworld fm700 usb radio only. I saw platforms with > radio-si470x-i2c but never had chances to play with it. > May be it's also better to ask Tobias and Joonyoung Shim. > I don't think that i'm ready to maintain si470x driver but i'll be > happy to be up to date with any changes and discussions about all usb > radio drivers. I'm happy to maintain the usb part and do odd-fixes for the i2c part for this driver... > I have usb gemtek radio 21 (dsbr100) and i'm ready to maintain it. I > can prepare patch. > Also i think that only fixes and corrections will be present for this > driver in future. ...and if you can maintain this driver, then we've split it up nicely. Is that OK with you? > > >> I don't have usb radio for radio-keene.c driver but i probably will > >> take a look how to buy it here.. > > > > I wrote the driver for that one, so I'll be the maintainer for this driver > > (I'm preparing MAINTAINERS patches as I write this). > > Oh, i never mean to take maintainership on keene radio (you're the author) :) > I just thought how to buy it. It's hard to get outside the UK. I had to use a forwarding service to get mine from amazon.co.uk. Regards, Hans ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-26 14:15 ` Hans Verkuil @ 2012-11-26 14:21 ` Alexey Klimov 0 siblings, 0 replies; 41+ messages in thread From: Alexey Klimov @ 2012-11-26 14:21 UTC (permalink / raw) To: Hans Verkuil; +Cc: Mauro Carvalho Chehab, media-workshop, linux-media Hi Hans, On Mon, Nov 26, 2012 at 6:15 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote: > On Mon 26 November 2012 00:18:30 Alexey Klimov wrote: >> Hi Hans, >> >> On Fri, Nov 23, 2012 at 2:31 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote: >> > Hi Alexey, >> > >> > On Mon November 12 2012 19:41:57 Alexey Klimov wrote: >> >> Hi Mauro, Hans, all, >> >> >> >> On Fri, Nov 2, 2012 at 6:34 PM, Mauro Carvalho Chehab >> >> <mchehab@redhat.com> wrote: >> >> > Em Fri, 2 Nov 2012 14:47:49 +0100 >> >> > Hans Verkuil <hverkuil@xs4all.nl> escreveu: >> >> > >> >> >> On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote: >> >> >> > Em Thu, 1 Nov 2012 14:12:44 -0200 >> >> >> > Mauro Carvalho Chehab <mchehab@redhat.com> escreveu: >> >> >> > >> >> >> > > Em Thu, 1 Nov 2012 16:44:50 +0100 >> >> >> > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: >> >> >> > > >> >> >> > > > On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: >> >> >> > > > > Hi Hans, >> >> >> > > > > >> >> >> > > > > Em Mon, 22 Oct 2012 10:35:56 +0200 >> >> >> > > > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: >> >> >> > > > > >> >> >> > > > > > Hi all, >> >> >> > > > > > >> >> >> > > > > > This is the tentative agenda for the media workshop on November 8, 2012. >> >> >> > > > > > If you have additional things that you want to discuss, or something is wrong >> >> >> > > > > > or incomplete in this list, please let me know so I can update the list. >> >> >> > > > > >> >> >> > > > > Thank you for taking care of it. >> >> >> > > > > >> >> >> > > > > > - Explain current merging process (Mauro) >> >> >> > > > > > - Open floor for discussions on how to improve it (Mauro) >> >> >> > > > > > - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for >> >> >> > > > > > staging and mainline acceptance: which frameworks to use, v4l2-compliance, >> >> >> > > > > > etc. (Hans Verkuil) >> >> >> > > > > > - V4L2 ambiguities (Hans Verkuil) >> >> >> > > > > > - TSMux device (a mux rather than a demux): Alain Volmat >> >> >> > > > > > - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) >> >> >> > > > > > - Device tree support (Guennadi, not known yet whether this topic is needed) >> >> >> > > > > > - Creating/selecting contexts for hardware that supports this (Samsung, only >> >> >> > > > > > if time is available) >> >> >> > > > > >> >> >> > > > > I have an extra theme for discussions there: what should we do with the drivers >> >> >> > > > > that don't have any MAINTAINERS entry. >> >> >> > > > >> >> >> > > > I've added this topic to the list. >> >> >> > > >> >> >> > > Thanks! >> >> >> > > >> >> >> > > > > It probably makes sense to mark them as "Orphan" (or, at least, have some >> >> >> > > > > criteria to mark them as such). Perhaps before doing that, we could try >> >> >> > > > > to see if are there any developer at the community with time and patience >> >> >> > > > > to handle them. >> >> >> > > > > >> >> >> > > > > This could of course be handled as part of the discussions about how to improve >> >> >> > > > > the merge process, but I suspect that this could generate enough discussions >> >> >> > > > > to be handled as a separate theme. >> >> >> > > > >> >> >> > > > Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can >> >> >> > > > test. So while I wouldn't like to be marked as 'The Maintainer of driver X' >> >> >> > > > (since I simply don't have the time for that), I wouldn't mind being marked as >> >> >> > > > someone who can at least test patches if needed. >> >> >> > > >> >> >> > > There are several "maintainance" status there: >> >> >> > > >> >> >> > > S: Status, one of the following: >> >> >> > > Supported: Someone is actually paid to look after this. >> >> >> > > Maintained: Someone actually looks after it. >> >> >> > > Odd Fixes: It has a maintainer but they don't have time to do >> >> >> > > much other than throw the odd patch in. See below.. >> >> >> > > Orphan: No current maintainer [but maybe you could take the >> >> >> > > role as you write your new code]. >> >> >> > > Obsolete: Old code. Something tagged obsolete generally means >> >> >> > > it has been replaced by a better system and you >> >> >> > > should be using that. >> >> >> > > >> >> >> > > (btw, I just realized that I should be changing the EDAC drivers I maintain >> >> >> > > to Supported; the media drivers I maintain should be kept as Maintained). >> >> >> > > >> >> >> > > I suspect that the "maintainer-light" category for those radio and similar >> >> >> > > old stuff is likely "Odd Fixes". >> >> >> > > >> >> >> > > > > There are some issues by not having a MAINTAINERS entry: >> >> >> > > > > - patches may not flow into the driver maintainer; >> >> >> > > > > - patches will likely be applied without tests/reviews or may >> >> >> > > > > stay for a long time queued; >> >> >> > > > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return >> >> >> > > > > any maintainer[1]. >> >> >> > > > > >> >> >> > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would >> >> >> > > > > delay a lot the patch review process, if applied for every patch, with >> >> >> > > > > unreliable and doubtful results. I don't do it, due to the large volume >> >> >> > > > > of patches, and because the 'other' results aren't typically the driver >> >> >> > > > > maintainer. >> >> >> > > > > >> >> >> > > > > An example of this is the results for a patch I just applied >> >> >> > > > > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): >> >> >> > > > > >> >> >> > > > > $ git show --pretty=email|./scripts/get_maintainer.pl >> >> >> > > > > Mauro Carvalho Chehab <mchehab@infradead.org> (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%) >> >> >> > > > > Hans Verkuil <hans.verkuil@cisco.com> (commit_signer:4/7=57%) >> >> >> > > > > Anatolij Gustschin <agust@denx.de> (commit_signer:1/7=14%) >> >> >> > > > > Wei Yongjun <yongjun_wei@trendmicro.com.cn> (commit_signer:1/7=14%) >> >> >> > > > > Hans de Goede <hdegoede@redhat.com> (commit_signer:1/7=14%) >> >> >> > > > > linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) >> >> >> > > > > linux-kernel@vger.kernel.org (open list) >> >> >> > > > > >> >> >> > > > > According with this driver's copyrights: >> >> >> > > > > >> >> >> > > > > * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved. >> >> >> > > > > * >> >> >> > > > > * Freescale VIU video driver >> >> >> > > > > * >> >> >> > > > > * Authors: Hongjun Chen <hong-jun.chen@freescale.com> >> >> >> > > > > * Porting to 2.6.35 by DENX Software Engineering, >> >> >> > > > > * Anatolij Gustschin <agust@denx.de> >> >> >> > > > > >> >> >> > > > > The driver author (Hongjun Chen <hong-jun.chen@freescale.com>) was not even >> >> >> > > > > shown there, and the co-author got only 15% hit, while I got 100% and Hans >> >> >> > > > > got 57%. >> >> >> > > > > >> >> >> > > > > This happens not only to this driver. In a matter of fact, on most cases where >> >> >> > > > > no MAINTAINERS entry exist, the driver's author gets a very small hit chance, >> >> >> > > > > as, on several of those drivers, the author doesn't post anything else but >> >> >> > > > > the initial patch series. >> >> >> > > > >> >> >> > > > We probably need to have an entry for all the media drivers, even if it just >> >> >> > > > points to the linux-media mailinglist as being the 'collective default maintainer'. >> >> >> > > >> >> >> > > Yes, I think that all media drivers should be there. I prefer to tag the ones >> >> >> > > that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates >> >> >> > > that help is wanted. >> >> >> > >> >> >> > I wrote a small shell script to see what's missing, using the analyze_build.pl script >> >> >> > at media-build devel_scripts dir: >> >> >> > >> >> >> > DIR=$(dirname $0) >> >> >> > >> >> >> > $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers >> >> >> > grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained >> >> >> > grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint >> >> >> > >> >> >> > I excluded the core files from the list, as they don't need any specific entry. RC >> >> >> > keymaps is also a special case, as I don't think any maintainer is needed for them. >> >> >> > >> >> >> > Basically, analyze_build.pl says that there are 613 drivers under drivers/media. >> >> >> > The above script shows 348 drivers without an explicit maintainer. So, only 43% >> >> >> > of the drivers have a formal maintainer. >> >> >> > >> >> >> > Yet, on the list below, I think several of them can be easily tagged as >> >> >> > "Odd fixes", like cx88 and saa7134. >> >> >> > >> >> >> > I think I'll send today a few RFC MAINTAINERS patches for some stuff below that >> >> >> > I can myself be added as "Odd fixes". Yet, I would very much prefer if someone >> >> >> > with more time than me could be taking over the "Odd fixes" patches I'll propose. >> >> >> > >> >> >> > Regards, >> >> >> > Mauro >> >> >> >> >> >> These two are 'Supported' by me: >> >> >> >> >> >> i2c/ad9389b.ko = i2c/ad9389b.c >> >> >> i2c/adv7604.ko = i2c/adv7604.c >> >> >> >> >> >> These are 'Maintained' by me: >> >> >> >> >> >> i2c/cx2341x.ko = i2c/cx2341x.c >> >> >> parport/bw-qcam.ko = parport/bw-qcam.c >> >> >> parport/c-qcam.ko = parport/c-qcam.c >> >> >> radio/dsbr100.ko = radio/dsbr100.c >> >> >> radio/radio-cadet.ko = radio/radio-cadet.c >> >> >> radio/radio-isa.ko = radio/radio-isa.c >> >> >> radio/radio-keene.ko = radio/radio-keene.c >> >> > >> >> > OK. Could you please send patches for those? I think that the better is >> >> > to write one patch by each MAINTAINERS entry (except, of course, if there >> >> > are consecutive entries), as I suspect that MAINTAINERS is likely one >> >> > of top-rated merge-conflicts file. >> >> > >> >> >> >> >> >> There are more radio drivers that can have that status, but I would need >> >> >> to check that when I'm back in Oslo. >> >> >> >> >> >> I can do 'Odd fixes' for the following: >> >> >> >> >> >> i2c/cx25840/cx25840.ko = i2c/cx25840/cx25840-core.c i2c/cx25840/cx25840-audio.c i2c/cx25840/cx25840-firmware.c i2c/cx25840/cx25840-vbi.c i2c/cx25840/cx25840-ir.c >> >> >> i2c/m52790.ko = i2c/m52790.c >> >> >> i2c/msp3400.ko = i2c/msp3400-driver.c i2c/msp3400-kthreads.c >> >> >> i2c/saa6588.ko = i2c/saa6588.c >> >> >> i2c/saa7110.ko = i2c/saa7110.c >> >> >> i2c/saa7115.ko = i2c/saa7115.c >> >> >> i2c/saa7127.ko = i2c/saa7127.c >> >> >> i2c/saa717x.ko = i2c/saa717x.c >> >> >> i2c/tda7432.ko = i2c/tda7432.c >> >> >> i2c/tda9840.ko = i2c/tda9840.c >> >> >> i2c/tea6415c.ko = i2c/tea6415c.c >> >> >> i2c/tea6420.ko = i2c/tea6420.c >> >> >> i2c/tvaudio.ko = i2c/tvaudio.c >> >> >> i2c/tveeprom.ko = i2c/tveeprom.c >> >> > >> >> >> i2c/tvp5150.ko = i2c/tvp5150.c >> >> > While I don't mind if you want to do odd fixes for this device, >> >> > I think I can maintain this one, as the "default" device I use for >> >> > random tests has this chipset (HVR-950), and I wrote this driver. >> >> > >> >> >> i2c/wm8739.ko = i2c/wm8739.c >> >> >> i2c/wm8775.ko = i2c/wm8775.c >> >> >> parport/pms.ko = parport/pms.c >> >> >> platform/vivi.ko = platform/vivi.c >> >> >> radio/radio-aimslab.ko = radio/radio-aimslab.c >> >> >> radio/radio-gemtek.ko = radio/radio-gemtek.c >> >> >> radio/radio-maxiradio.ko = radio/radio-maxiradio.c >> >> >> radio/radio-miropcm20.ko = radio/radio-miropcm20.c >> >> >> radio/radio-mr800.ko = radio/radio-mr800.c >> >> >> radio/radio-rtrack2.ko = radio/radio-rtrack2.c >> >> >> radio/radio-si4713.ko = radio/radio-si4713.c >> >> > >> >> >> usb/cx231xx/cx231xx-alsa.ko = usb/cx231xx/cx231xx-audio.c >> >> >> usb/cx231xx/cx231xx-dvb.ko = usb/cx231xx/cx231xx-dvb.c >> >> >> usb/cx231xx/cx231xx-input.ko = usb/cx231xx/cx231xx-input.c >> >> >> usb/cx231xx/cx231xx.ko = + >> >> > I think we should check if the driver author is not interested on >> >> > taking maintainership for this one, before putting it on Odd fixes status. >> >> >> >> I'm very sorry for long silence but i'm ready to take maintainership >> >> for radio-mr800. By the way, i think that only fixes will be present >> >> for this driver in the future. >> >> >> >> Is it possible for driver to have two maintainers or for example one >> >> person marked as maintainer and another one marked as "odd fixes" ? I >> >> mean i'm interested to be in c/c regarding all email, news, >> >> interesting patches for radio-mr800, dsbr100 and usb radio part of >> >> si470x but i don't know how to mark it that i want to help with these >> >> drivers. I have only dsbr100, mr800 and kworld fm700 (based on si470x) >> >> usb radios and i'm ready to test any patches and help as much as i >> >> can. >> > >> > I saw that you made a MAINTAINERS entry for radio-mr800, but not for dsbr100 >> > or si470x. Do you want to be the maintainer for those two, or shall I add >> > myself as the 'Odd Fixes' entry? I have hardware for both. >> >> About si470x. It consists of two parts (usb and i2c interfaces) if i >> remember correctly. >> I have kworld fm700 usb radio only. I saw platforms with >> radio-si470x-i2c but never had chances to play with it. >> May be it's also better to ask Tobias and Joonyoung Shim. >> I don't think that i'm ready to maintain si470x driver but i'll be >> happy to be up to date with any changes and discussions about all usb >> radio drivers. > > I'm happy to maintain the usb part and do odd-fixes for the i2c part for > this driver... > >> I have usb gemtek radio 21 (dsbr100) and i'm ready to maintain it. I >> can prepare patch. >> Also i think that only fixes and corrections will be present for this >> driver in future. > > ...and if you can maintain this driver, then we've split it up nicely. > > Is that OK with you? Yes, of course, it's ok for me. >> >> I don't have usb radio for radio-keene.c driver but i probably will >> >> take a look how to buy it here.. >> > >> > I wrote the driver for that one, so I'll be the maintainer for this driver >> > (I'm preparing MAINTAINERS patches as I write this). >> >> Oh, i never mean to take maintainership on keene radio (you're the author) :) >> I just thought how to buy it. > > It's hard to get outside the UK. I had to use a forwarding service to get > mine from amazon.co.uk. > > Regards, > > Hans Ok, i'll take a look. Thanks. -- Best regards, Alexey ^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH] firedtv: add MAINTAINERS entry 2012-11-02 13:13 ` drivers without explicit MAINTAINERS entry - was: " Mauro Carvalho Chehab 2012-11-02 13:47 ` Hans Verkuil @ 2012-11-03 9:25 ` Stefan Richter 2012-11-08 14:18 ` drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop Laurent Pinchart 2012-11-10 20:55 ` Sakari Ailus 3 siblings, 0 replies; 41+ messages in thread From: Stefan Richter @ 2012-11-03 9:25 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Hans Verkuil, linux-media, linux1394-devel There is currently discussion to add MAINTAINERS records for media drivers that don't have one yet, possibly with 'orphan' or 'odd fixes' status. Here is a proper entry for the firedtv driver (for 1394 attached DVB STBs and 1394 attached DVB cards from Digital Everywhere). The L: linux-media and T: linux-media.git lines in this entry are redundant to what scripts/get_maintainer.pl would show automatically but I added them for folks who read MAINTAINERS directly. The "(firedtv)" string is for those folks as well if they look for driver name rather than file path. The F: drivers/media/firewire/ pattern and the "FireWire media drivers" title are currently synonymous with firedtv. If more drivers get added there, this can be revisited. I don't have documentation or DVB-S2 devices to test, but I have DVB-C and DVB-T devices for testing. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> --- MAINTAINERS | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3041,6 +3041,14 @@ T: git git://git.alsa-project.org/alsa-k S: Maintained F: sound/firewire/ +FIREWIRE MEDIA DRIVERS (firedtv) +M: Stefan Richter <stefanr@s5r6.in-berlin.de> +L: linux-media@vger.kernel.org +L: linux1394-devel@lists.sourceforge.net +T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git +S: Maintained +F: drivers/media/firewire/ + FIREWIRE SBP-2 TARGET M: Chris Boot <bootc@bootc.net> L: linux-scsi@vger.kernel.org On Nov 02 Mauro Carvalho Chehab wrote: > Em Thu, 1 Nov 2012 14:12:44 -0200 > Mauro Carvalho Chehab <mchehab@redhat.com> escreveu: > > > Em Thu, 1 Nov 2012 16:44:50 +0100 > > Hans Verkuil <hverkuil@xs4all.nl> escreveu: > > (thread [media-workshop] Tentative Agenda for the November workshop) > > > On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: > > > > I have an extra theme for discussions there: what should we do with the drivers > > > > that don't have any MAINTAINERS entry. [...] > > > > It probably makes sense to mark them as "Orphan" (or, at least, have some > > > > criteria to mark them as such). Perhaps before doing that, we could try > > > > to see if are there any developer at the community with time and patience > > > > to handle them. > > > > > > > > This could of course be handled as part of the discussions about how to improve > > > > the merge process, but I suspect that this could generate enough discussions > > > > to be handled as a separate theme. > > > > > > Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can > > > test. So while I wouldn't like to be marked as 'The Maintainer of driver X' > > > (since I simply don't have the time for that), I wouldn't mind being marked as > > > someone who can at least test patches if needed. > > > > There are several "maintainance" status there: > > > > S: Status, one of the following: > > Supported: Someone is actually paid to look after this. > > Maintained: Someone actually looks after it. > > Odd Fixes: It has a maintainer but they don't have time to do > > much other than throw the odd patch in. See below.. > > Orphan: No current maintainer [but maybe you could take the > > role as you write your new code]. > > Obsolete: Old code. Something tagged obsolete generally means > > it has been replaced by a better system and you > > should be using that. > > > > (btw, I just realized that I should be changing the EDAC drivers I maintain > > to Supported; the media drivers I maintain should be kept as Maintained). > > > > I suspect that the "maintainer-light" category for those radio and similar > > old stuff is likely "Odd Fixes". > > > > > > There are some issues by not having a MAINTAINERS entry: > > > > - patches may not flow into the driver maintainer; > > > > - patches will likely be applied without tests/reviews or may > > > > stay for a long time queued; > > > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return > > > > any maintainer[1]. > > > > > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would > > > > delay a lot the patch review process, if applied for every patch, with > > > > unreliable and doubtful results. I don't do it, due to the large volume > > > > of patches, and because the 'other' results aren't typically the driver > > > > maintainer. > > > > > > > > An example of this is the results for a patch I just applied > > > > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): > > > > > > > > $ git show --pretty=email|./scripts/get_maintainer.pl [...] > > > > The driver author (Hongjun Chen <hong-jun.chen@freescale.com>) was not even > > > > shown there, and the co-author got only 15% hit, while I got 100% and Hans > > > > got 57%. > > > > > > > > This happens not only to this driver. In a matter of fact, on most cases where > > > > no MAINTAINERS entry exist, the driver's author gets a very small hit chance, > > > > as, on several of those drivers, the author doesn't post anything else but > > > > the initial patch series. > > > > > > We probably need to have an entry for all the media drivers, even if it just > > > points to the linux-media mailinglist as being the 'collective default maintainer'. > > > > Yes, I think that all media drivers should be there. I prefer to tag the ones > > that nobody sends us a MAINTAINERS entry with "Orphan", as this tag indicates > > that help is wanted. > > I wrote a small shell script to see what's missing, using the analyze_build.pl script > at media-build devel_scripts dir: > > DIR=$(dirname $0) > > $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module >/tmp/all_drivers > grep drivers/media/ MAINTAINERS | perl -ne 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained > grep -v -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint > > I excluded the core files from the list, as they don't need any specific entry. RC > keymaps is also a special case, as I don't think any maintainer is needed for them. > > Basically, analyze_build.pl says that there are 613 drivers under drivers/media. > The above script shows 348 drivers without an explicit maintainer. So, only 43% > of the drivers have a formal maintainer. [...] -- Stefan Richter -=====-===-- =-== ---== http://arcgraph.de/sr/ ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-02 13:13 ` drivers without explicit MAINTAINERS entry - was: " Mauro Carvalho Chehab 2012-11-02 13:47 ` Hans Verkuil 2012-11-03 9:25 ` [PATCH] firedtv: add MAINTAINERS entry Stefan Richter @ 2012-11-08 14:18 ` Laurent Pinchart 2012-11-13 9:53 ` Laurent Pinchart 2012-11-10 20:55 ` Sakari Ailus 3 siblings, 1 reply; 41+ messages in thread From: Laurent Pinchart @ 2012-11-08 14:18 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Hans Verkuil, media-workshop, linux-media Hi Mauro, On Friday 02 November 2012 11:13:10 Mauro Carvalho Chehab wrote: > Em Thu, 1 Nov 2012 14:12:44 -0200 Mauro Carvalho Chehab escreveu: > > Em Thu, 1 Nov 2012 16:44:50 +0100 Hans Verkuil escreveu: > > > On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: > > > > Em Mon, 22 Oct 2012 10:35:56 +0200 Hans Verkuil escreveu: > > > > > Hi all, > > > > > > > > > > This is the tentative agenda for the media workshop on November 8, > > > > > 2012. > > > > > If you have additional things that you want to discuss, or something > > > > > is wrong or incomplete in this list, please let me know so I can > > > > > update the list. > > > > > > > > Thank you for taking care of it. > > > > > > > > > - Explain current merging process (Mauro) > > > > > - Open floor for discussions on how to improve it (Mauro) > > > > > - Write down minimum requirements for new V4L2 (and DVB?) drivers, > > > > > both for staging and mainline acceptance: which frameworks to use, > > > > > v4l2-compliance, etc. (Hans Verkuil) > > > > > - V4L2 ambiguities (Hans Verkuil) > > > > > - TSMux device (a mux rather than a demux): Alain Volmat > > > > > - dmabuf status, esp. with regards to being able to test > > > > > (Mauro/Samsung) > > > > > - Device tree support (Guennadi, not known yet whether this topic is > > > > > needed) - Creating/selecting contexts for hardware that supports > > > > > this (Samsung, only if time is available) > > > > > > > > I have an extra theme for discussions there: what should we do with > > > > the drivers that don't have any MAINTAINERS entry. > > > > > > I've added this topic to the list. > > > > Thanks! > > > > > > It probably makes sense to mark them as "Orphan" (or, at least, have > > > > some criteria to mark them as such). Perhaps before doing that, we > > > > could try to see if are there any developer at the community with time > > > > and patience to handle them. > > > > > > > > This could of course be handled as part of the discussions about how > > > > to improve the merge process, but I suspect that this could generate > > > > enough discussions to be handled as a separate theme. > > > > > > Do we have a 'Maintainer-Light' category? I have a lot of hardware that > > > I can test. So while I wouldn't like to be marked as 'The Maintainer of > > > driver X' (since I simply don't have the time for that), I wouldn't > > > mind being marked as someone who can at least test patches if needed. > > > > There are several "maintainance" status there: > > S: Status, one of the following: > > Supported: Someone is actually paid to look after this. > > Maintained: Someone actually looks after it. > > Odd Fixes: It has a maintainer but they don't have time to do > > much other than throw the odd patch in. See below.. > > Orphan: No current maintainer [but maybe you could take the > > role as you write your new code]. > > Obsolete: Old code. Something tagged obsolete generally means > > it has been replaced by a better system and you > > should be using that. > > > > (btw, I just realized that I should be changing the EDAC drivers I > > maintain to Supported; the media drivers I maintain should be kept as > > Maintained). > > > > I suspect that the "maintainer-light" category for those radio and similar > > old stuff is likely "Odd Fixes". > > > > > > There are some issues by not having a MAINTAINERS entry: > > > > - patches may not flow into the driver maintainer; > > > > - patches will likely be applied without tests/reviews or may > > > > stay for a long time queued; > > > > - ./scripts/get_maintainer.pl at --no-git-fallback won't return > > > > any maintainer[1]. > > > > > > > > [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it > > > > would delay a lot the patch review process, if applied for every > > > > patch, with unreliable and doubtful results. I don't do it, due to the > > > > large volume of patches, and because the 'other' results aren't > > > > typically the driver maintainer. > > > > > > > > An example of this is the results for a patch I just applied > > > > > > > > (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): > > > > $ git show --pretty=email|./scripts/get_maintainer.pl > > > > Mauro Carvalho Chehab <mchehab@infradead.org> (maintainer:MEDIA INPUT > > > > INFRA...,commit_signer:7/7=100%) Hans Verkuil > > > > <hans.verkuil@cisco.com> (commit_signer:4/7=57%) > > > > Anatolij Gustschin <agust@denx.de> (commit_signer:1/7=14%) > > > > Wei Yongjun <yongjun_wei@trendmicro.com.cn> (commit_signer:1/7=14%) > > > > Hans de Goede <hdegoede@redhat.com> (commit_signer:1/7=14%) > > > > linux-media@vger.kernel.org (open list:MEDIA INPUT INFRA...) > > > > linux-kernel@vger.kernel.org (open list) > > > > > > > > According with this driver's copyrights: > > > > * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights > > > > Reserved. > > > > * > > > > * Freescale VIU video driver > > > > * > > > > * Authors: Hongjun Chen <hong-jun.chen@freescale.com> > > > > * Porting to 2.6.35 by DENX Software Engineering, > > > > * Anatolij Gustschin <agust@denx.de> > > > > > > > > The driver author (Hongjun Chen <hong-jun.chen@freescale.com>) was not > > > > even shown there, and the co-author got only 15% hit, while I got 100% > > > > and Hans got 57%. > > > > > > > > This happens not only to this driver. In a matter of fact, on most > > > > cases where no MAINTAINERS entry exist, the driver's author gets a > > > > very small hit chance, as, on several of those drivers, the author > > > > doesn't post anything else but the initial patch series. > > > > > > We probably need to have an entry for all the media drivers, even if it > > > just points to the linux-media mailinglist as being the 'collective > > > default maintainer'. > > > > Yes, I think that all media drivers should be there. I prefer to tag the > > ones that nobody sends us a MAINTAINERS entry with "Orphan", as this tag > > indicates that help is wanted. > > I wrote a small shell script to see what's missing, using the > analyze_build.pl script at media-build devel_scripts dir: > > DIR=$(dirname $0) > > $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module > >/tmp/all_drivers grep drivers/media/ MAINTAINERS | perl -ne > 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained grep -v -f > maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ -e dvb-core/ > -e media.ko -e rc-core.ko -e ^#| sort >without_maint > > I excluded the core files from the list, as they don't need any specific > entry. RC keymaps is also a special case, as I don't think any maintainer > is needed for them. > > Basically, analyze_build.pl says that there are 613 drivers under > drivers/media. The above script shows 348 drivers without an explicit > maintainer. So, only 43% of the drivers have a formal maintainer. > > Yet, on the list below, I think several of them can be easily tagged as > "Odd fixes", like cx88 and saa7134. > > I think I'll send today a few RFC MAINTAINERS patches for some stuff below > that I can myself be added as "Odd fixes". Yet, I would very much prefer if > someone with more time than me could be taking over the "Odd fixes" patches > I'll propose. These are 'Maintained' by me: i2c/aptina-pll.ko = i2c/aptina-pll.c i2c/mt9p031.ko = i2c/mt9p031.c i2c/mt9t001.ko = i2c/mt9t001.c i2c/mt9v032.ko = i2c/mt9v032.c I can maintain the following driver if needed: i2c/mt9m032.ko = i2c/mt9m032.c I could also take over maintenance the following driver, but I don't have access to a hardware platform that uses it: i2c/mt9v011.ko = i2c/mt9v011.c These are, as far as I know, co-maintained by Sakari and me :-) i2c/adp1653.ko = i2c/adp1653.c i2c/as3645a.ko = i2c/as3645a.c -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-08 14:18 ` drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop Laurent Pinchart @ 2012-11-13 9:53 ` Laurent Pinchart 2012-12-10 22:01 ` martin 0 siblings, 1 reply; 41+ messages in thread From: Laurent Pinchart @ 2012-11-13 9:53 UTC (permalink / raw) To: martin; +Cc: Mauro Carvalho Chehab, Hans Verkuil, media-workshop, linux-media Hi Martin, On Thursday 08 November 2012 15:18:38 Laurent Pinchart wrote: > On Friday 02 November 2012 11:13:10 Mauro Carvalho Chehab wrote: > > Em Thu, 1 Nov 2012 14:12:44 -0200 Mauro Carvalho Chehab escreveu: > > > Em Thu, 1 Nov 2012 16:44:50 +0100 Hans Verkuil escreveu: > > > > On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: > > > > > Em Mon, 22 Oct 2012 10:35:56 +0200 Hans Verkuil escreveu: > > > > > > Hi all, > > > > > > > > > > > > This is the tentative agenda for the media workshop on November 8, > > > > > > 2012. If you have additional things that you want to discuss, or > > > > > > something is wrong or incomplete in this list, please let me know > > > > > > so I can update the list. [snip] > > > > > I have an extra theme for discussions there: what should we do with > > > > > the drivers that don't have any MAINTAINERS entry. > > > > > > > > I've added this topic to the list. > > > > > > Thanks! > > > > > > > > It probably makes sense to mark them as "Orphan" (or, at least, have > > > > > some criteria to mark them as such). Perhaps before doing that, we > > > > > could try to see if are there any developer at the community with > > > > > time and patience to handle them. > > > > > > > > > > This could of course be handled as part of the discussions about how > > > > > to improve the merge process, but I suspect that this could generate > > > > > enough discussions to be handled as a separate theme. > > > > > > > > Do we have a 'Maintainer-Light' category? I have a lot of hardware > > > > that I can test. So while I wouldn't like to be marked as 'The > > > > Maintainer of driver X' (since I simply don't have the time for that), > > > > I wouldn't mind being marked as someone who can at least test patches > > > > if needed. > > > > > > There are several "maintainance" status there: > > > S: Status, one of the following: > > > Supported: Someone is actually paid to look after this. > > > Maintained: Someone actually looks after it. > > > Odd Fixes: It has a maintainer but they don't have time to do > > > much other than throw the odd patch in. See below.. > > > Orphan: No current maintainer [but maybe you could take the > > > role as you write your new code]. > > > Obsolete: Old code. Something tagged obsolete generally means > > > it has been replaced by a better system and you > > > should be using that. [snip] > > > > We probably need to have an entry for all the media drivers, even if > > > > it just points to the linux-media mailinglist as being the 'collective > > > > default maintainer'. > > > > > > Yes, I think that all media drivers should be there. I prefer to tag the > > > ones that nobody sends us a MAINTAINERS entry with "Orphan", as this tag > > > indicates that help is wanted. > > > > I wrote a small shell script to see what's missing, using the > > > > analyze_build.pl script at media-build devel_scripts dir: > > DIR=$(dirname $0) > > > > $DIR/analyze_build.pl --path drivers/media/ --show_files_per_module > > > > >/tmp/all_drivers grep drivers/media/ MAINTAINERS | perl -ne > > > > 's/F:\s+//;s,drivers/media/,,; print $_ if (!/^\n/)' >maintained grep -v > > -f maintained /tmp/all_drivers |grep -v -e keymaps -e v4l2-core/ > > -e dvb-core/ -e media.ko -e rc-core.ko -e ^#| sort >without_maint > > > > I excluded the core files from the list, as they don't need any specific > > entry. RC keymaps is also a special case, as I don't think any maintainer > > is needed for them. > > > > Basically, analyze_build.pl says that there are 613 drivers under > > drivers/media. The above script shows 348 drivers without an explicit > > maintainer. So, only 43% of the drivers have a formal maintainer. > > > > Yet, on the list below, I think several of them can be easily tagged as > > "Odd fixes", like cx88 and saa7134. > > > > I think I'll send today a few RFC MAINTAINERS patches for some stuff below > > that I can myself be added as "Odd fixes". Yet, I would very much prefer > > if someone with more time than me could be taking over the "Odd fixes" > > patches I'll propose. > > These are 'Maintained' by me: > > i2c/aptina-pll.ko = i2c/aptina-pll.c > i2c/mt9p031.ko = i2c/mt9p031.c > i2c/mt9t001.ko = i2c/mt9t001.c > i2c/mt9v032.ko = i2c/mt9v032.c > > I can maintain the following driver if needed: > > i2c/mt9m032.ko = i2c/mt9m032.c Do you plan to send a MAINTAINERS patch for this driver (and thus maintain the driver :-)), or should I maintain it ? > I could also take over maintenance the following driver, but I don't have > access to a hardware platform that uses it: > > i2c/mt9v011.ko = i2c/mt9v011.c > > These are, as far as I know, co-maintained by Sakari and me :-) > > i2c/adp1653.ko = i2c/adp1653.c > i2c/as3645a.ko = i2c/as3645a.c -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-13 9:53 ` Laurent Pinchart @ 2012-12-10 22:01 ` martin 2012-12-11 0:11 ` Laurent Pinchart 0 siblings, 1 reply; 41+ messages in thread From: martin @ 2012-12-10 22:01 UTC (permalink / raw) To: Laurent Pinchart Cc: Mauro Carvalho Chehab, Hans Verkuil, media-workshop, linux-media On Tue, Nov 13, 2012 at 10:53:17AM +0100, Laurent Pinchart wrote: > Hi Martin, > > On Thursday 08 November 2012 15:18:38 Laurent Pinchart wrote: [ snip ] > > > > These are 'Maintained' by me: > > > > i2c/aptina-pll.ko = i2c/aptina-pll.c > > i2c/mt9p031.ko = i2c/mt9p031.c > > i2c/mt9t001.ko = i2c/mt9t001.c > > i2c/mt9v032.ko = i2c/mt9v032.c > > > > I can maintain the following driver if needed: > > > > i2c/mt9m032.ko = i2c/mt9m032.c > > Do you plan to send a MAINTAINERS patch for this driver (and thus maintain the > driver :-)), or should I maintain it ? I sadly neigher have time nor hardware to maintain this driver at the moment so i would be more than happy if you can maintain it. Thanks, - Martin Hostettler > > > I could also take over maintenance the following driver, but I don't have > > access to a hardware platform that uses it: > > > > i2c/mt9v011.ko = i2c/mt9v011.c > > > > These are, as far as I know, co-maintained by Sakari and me :-) > > > > i2c/adp1653.ko = i2c/adp1653.c > > i2c/as3645a.ko = i2c/as3645a.c > > -- > Regards, > > Laurent Pinchart > ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop 2012-12-10 22:01 ` martin @ 2012-12-11 0:11 ` Laurent Pinchart 0 siblings, 0 replies; 41+ messages in thread From: Laurent Pinchart @ 2012-12-11 0:11 UTC (permalink / raw) To: martin; +Cc: Mauro Carvalho Chehab, Hans Verkuil, media-workshop, linux-media Hi Martin, On Monday 10 December 2012 23:01:31 martin@neutronstar.dyndns.org wrote: > On Tue, Nov 13, 2012 at 10:53:17AM +0100, Laurent Pinchart wrote: > > Hi Martin, > > > On Thursday 08 November 2012 15:18:38 Laurent Pinchart wrote: > [ snip ] > > > > These are 'Maintained' by me: > > > > > > i2c/aptina-pll.ko = i2c/aptina-pll.c > > > i2c/mt9p031.ko = i2c/mt9p031.c > > > i2c/mt9t001.ko = i2c/mt9t001.c > > > i2c/mt9v032.ko = i2c/mt9v032.c > > > > > > I can maintain the following driver if needed: > > > > > > i2c/mt9m032.ko = i2c/mt9m032.c > > > > Do you plan to send a MAINTAINERS patch for this driver (and thus maintain > > the driver :-)), or should I maintain it ? > > I sadly neigher have time nor hardware to maintain this driver at the moment > so i would be more than happy if you can maintain it. OK, I will do that. > > > I could also take over maintenance the following driver, but I don't > > > have > > > access to a hardware platform that uses it: > > > > > > i2c/mt9v011.ko = i2c/mt9v011.c > > > > > > These are, as far as I know, co-maintained by Sakari and me :-) > > > > > > i2c/adp1653.ko = i2c/adp1653.c > > > i2c/as3645a.ko = i2c/as3645a.c -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-02 13:13 ` drivers without explicit MAINTAINERS entry - was: " Mauro Carvalho Chehab ` (2 preceding siblings ...) 2012-11-08 14:18 ` drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop Laurent Pinchart @ 2012-11-10 20:55 ` Sakari Ailus 2012-11-12 10:37 ` Mauro Carvalho Chehab 3 siblings, 1 reply; 41+ messages in thread From: Sakari Ailus @ 2012-11-10 20:55 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Hans Verkuil, media-workshop, linux-media Hi Mauro, On Fri, Nov 02, 2012 at 11:13:10AM -0200, Mauro Carvalho Chehab wrote: ... These are "Maintained" by me (with Laurent): > i2c/adp1653.ko = i2c/adp1653.c > i2c/as3645a.ko = i2c/as3645a.c "Maintained" by me: > i2c/smiapp-pll.ko = i2c/smiapp-pll.c > i2c/smiapp/smiapp.ko = i2c/smiapp/smiapp-core.c i2c/smiapp/smiapp-regs.c i2c/smiapp/smiapp-quirk.c i2c/smiapp/smiapp-limits.c "Odd fixes": > i2c/tcm825x.ko = i2c/tcm825x.c > platform/omap2cam.ko = platform/omap24xxcam.c platform/omap24xxcam-dma.c Regards, -- Sakari Ailus e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop 2012-11-10 20:55 ` Sakari Ailus @ 2012-11-12 10:37 ` Mauro Carvalho Chehab 2012-11-12 22:14 ` [PATCH 1/1] MAINTAINERS: Update maintainer for smiapp and adp1653 drivers Sakari Ailus 0 siblings, 1 reply; 41+ messages in thread From: Mauro Carvalho Chehab @ 2012-11-12 10:37 UTC (permalink / raw) To: Sakari Ailus; +Cc: Hans Verkuil, media-workshop, linux-media Hi Sakari, Em Sat, 10 Nov 2012 22:55:22 +0200 Sakari Ailus <sakari.ailus@iki.fi> escreveu: > Hi Mauro, > > On Fri, Nov 02, 2012 at 11:13:10AM -0200, Mauro Carvalho Chehab wrote: > ... > These are "Maintained" by me (with Laurent): > > > i2c/adp1653.ko = i2c/adp1653.c > > i2c/as3645a.ko = i2c/as3645a.c > > "Maintained" by me: > > > i2c/smiapp-pll.ko = i2c/smiapp-pll.c > > i2c/smiapp/smiapp.ko = i2c/smiapp/smiapp-core.c i2c/smiapp/smiapp-regs.c i2c/smiapp/smiapp-quirk.c i2c/smiapp/smiapp-limits.c > > "Odd fixes": > > > i2c/tcm825x.ko = i2c/tcm825x.c > > platform/omap2cam.ko = platform/omap24xxcam.c platform/omap24xxcam-dma.c > > Regards, > Care to send us a patch with the above? It is likely better to have one entry per driver, to reduce the risk of merge conflicts upstream. -- Regards, Mauro ^ permalink raw reply [flat|nested] 41+ messages in thread
* [PATCH 1/1] MAINTAINERS: Update maintainer for smiapp and adp1653 drivers 2012-11-12 10:37 ` Mauro Carvalho Chehab @ 2012-11-12 22:14 ` Sakari Ailus 0 siblings, 0 replies; 41+ messages in thread From: Sakari Ailus @ 2012-11-12 22:14 UTC (permalink / raw) To: mchehab; +Cc: linux-media, hverkuil, media-workshop And the smiapp-pll which is in a way part of the smiapp driver. Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> --- MAINTAINERS | 16 ++++++++++++++++ 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index f4b3aa8..9c2a6bb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -336,6 +336,13 @@ W: http://wireless.kernel.org/ S: Orphan F: drivers/net/wireless/adm8211.* +ADP1653 FLASH CONTROLLER DRIVER +M: Sakari Ailus <sakari.ailus@iki.fi> +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/i2c/adp1653.c +F: include/media/adp1653.h + ADP5520 BACKLIGHT DRIVER WITH IO EXPANDER (ADP5520/ADP5501) M: Michael Hennerich <michael.hennerich@analog.com> L: device-drivers-devel@blackfin.uclinux.org @@ -6685,6 +6692,15 @@ M: Nicolas Pitre <nico@fluxnic.net> S: Odd Fixes F: drivers/net/ethernet/smsc/smc91x.* +SMIA AND SMIA++ IMAGE SENSOR DRIVER +M: Sakari Ailus <sakari.ailus@iki.fi> +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/i2c/smiapp +F: include/media/smiapp.h +F: drivers/media/i2c/smiapp-pll.c +F: drivers/media/i2c/smiapp-pll.h + SMM665 HARDWARE MONITOR DRIVER M: Guenter Roeck <linux@roeck-us.net> L: lm-sensors@lm-sensors.org -- 1.7.2.5 ^ permalink raw reply related [flat|nested] 41+ messages in thread
end of thread, other threads:[~2012-12-11 0:10 UTC | newest] Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-10-22 8:35 Tentative Agenda for the November workshop Hans Verkuil 2012-10-22 10:39 ` [media-workshop] " Laurent Pinchart 2012-10-22 10:53 ` Sylwester Nawrocki 2012-10-22 10:57 ` Alain VOLMAT 2012-10-22 11:17 ` Sylwester Nawrocki 2012-10-22 11:18 ` Laurent Pinchart 2012-10-22 12:06 ` Hans Verkuil 2012-10-23 1:03 ` Laurent Pinchart 2012-10-23 6:46 ` Hans Verkuil 2012-10-23 10:22 ` Laurent Pinchart 2012-10-23 11:59 ` Sylwester Nawrocki 2012-10-24 22:42 ` Laurent Pinchart 2012-10-25 8:43 ` Sylwester Nawrocki 2012-10-25 8:52 ` Hans Verkuil 2012-10-22 21:13 ` Guennadi Liakhovetski 2012-10-22 21:14 ` Guennadi Liakhovetski 2012-10-31 13:12 ` Guennadi Liakhovetski 2012-11-01 16:01 ` Hans Verkuil 2012-11-01 16:05 ` Laurent Pinchart 2012-11-01 19:01 ` Sylwester Nawrocki 2012-10-25 17:27 ` Mauro Carvalho Chehab 2012-11-01 15:44 ` Hans Verkuil 2012-11-01 16:12 ` Mauro Carvalho Chehab 2012-11-02 13:13 ` drivers without explicit MAINTAINERS entry - was: " Mauro Carvalho Chehab 2012-11-02 13:47 ` Hans Verkuil 2012-11-02 14:34 ` Mauro Carvalho Chehab 2012-11-02 15:05 ` [media-workshop] drivers without explicit MAINTAINERS entry - was: " Palash Bandyopadhyay 2012-11-12 18:41 ` drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] " Alexey Klimov 2012-11-12 18:54 ` Mauro Carvalho Chehab 2012-11-23 10:31 ` Hans Verkuil 2012-11-25 23:18 ` Alexey Klimov 2012-11-26 14:15 ` Hans Verkuil 2012-11-26 14:21 ` Alexey Klimov 2012-11-03 9:25 ` [PATCH] firedtv: add MAINTAINERS entry Stefan Richter 2012-11-08 14:18 ` drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop Laurent Pinchart 2012-11-13 9:53 ` Laurent Pinchart 2012-12-10 22:01 ` martin 2012-12-11 0:11 ` Laurent Pinchart 2012-11-10 20:55 ` Sakari Ailus 2012-11-12 10:37 ` Mauro Carvalho Chehab 2012-11-12 22:14 ` [PATCH 1/1] MAINTAINERS: Update maintainer for smiapp and adp1653 drivers Sakari Ailus
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.