* [GIT PATCHES FOR v3.6] Samsung media driver fixes
@ 2012-08-22 8:32 Sylwester Nawrocki
2012-09-05 16:12 ` Sylwester Nawrocki
2012-10-01 9:52 ` Sylwester Nawrocki
0 siblings, 2 replies; 9+ messages in thread
From: Sylwester Nawrocki @ 2012-08-22 8:32 UTC (permalink / raw)
To: linux-media@vger.kernel.org; +Cc: Mauro Carvalho Chehab, Kamil Debski
Hi Mauro,
The following changes since commit f9cd49033b349b8be3bb1f01b39eed837853d880:
Merge tag 'v3.6-rc1' into staging/for_v3.6 (2012-08-03 22:41:33 -0300)
are available in the git repository at:
git://git.infradead.org/users/kmpark/linux-samsung v4l-fixes
for you to fetch changes up to 0e59db054e30658c6955d6e27b0a252cef9bfafc:
s5p-mfc: Fix second memory bank alignment (2012-08-16 19:12:19 +0200)
----------------------------------------------------------------
Kamil Debski (1):
s5p-mfc: Fix second memory bank alignment
Sylwester Nawrocki (7):
s5p-fimc: Enable FIMC-LITE driver only for SOC_EXYNOS4x12
s5p-fimc: Don't allocate fimc-lite video device structure dynamically
s5p-fimc: Don't allocate fimc-capture video device dynamically
s5p-fimc: Don't allocate fimc-m2m video device dynamically
m5mols: Add missing free_irq() on error path
m5mols: Fix cast warnings from m5mols_[set/get]_ctrl_mode
s5p-fimc: Fix setup of initial links to FIMC entities
drivers/media/video/m5mols/m5mols.h | 4 +--
drivers/media/video/m5mols/m5mols_controls.c | 4 +--
drivers/media/video/m5mols/m5mols_core.c | 4 ++-
drivers/media/video/s5p-fimc/Kconfig | 2 +-
drivers/media/video/s5p-fimc/fimc-capture.c | 31 +++++++-----------
drivers/media/video/s5p-fimc/fimc-core.h | 4 +--
drivers/media/video/s5p-fimc/fimc-lite-reg.c | 2 +-
drivers/media/video/s5p-fimc/fimc-lite.c | 42 ++++++++++---------------
drivers/media/video/s5p-fimc/fimc-lite.h | 2 +-
drivers/media/video/s5p-fimc/fimc-m2m.c | 40 ++++++++---------------
drivers/media/video/s5p-fimc/fimc-mdevice.c | 9 ++++--
drivers/media/video/s5p-fimc/fimc-mdevice.h | 6 ++--
drivers/media/video/s5p-fimc/fimc-reg.c | 6 ++--
drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c | 2 +-
14 files changed, 65 insertions(+), 93 deletions(-)
---
Thanks,
Sylwester
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [GIT PATCHES FOR v3.6] Samsung media driver fixes 2012-08-22 8:32 [GIT PATCHES FOR v3.6] Samsung media driver fixes Sylwester Nawrocki @ 2012-09-05 16:12 ` Sylwester Nawrocki 2012-10-01 9:52 ` Sylwester Nawrocki 1 sibling, 0 replies; 9+ messages in thread From: Sylwester Nawrocki @ 2012-09-05 16:12 UTC (permalink / raw) To: linux-media@vger.kernel.org; +Cc: Mauro Carvalho Chehab Hi Mauro, On 08/22/2012 10:32 AM, Sylwester Nawrocki wrote: > The following changes since commit f9cd49033b349b8be3bb1f01b39eed837853d880: > > Merge tag 'v3.6-rc1' into staging/for_v3.6 (2012-08-03 22:41:33 -0300) > > are available in the git repository at: > > > git://git.infradead.org/users/kmpark/linux-samsung v4l-fixes > > for you to fetch changes up to 0e59db054e30658c6955d6e27b0a252cef9bfafc: > > s5p-mfc: Fix second memory bank alignment (2012-08-16 19:12:19 +0200) > > ---------------------------------------------------------------- > Kamil Debski (1): > s5p-mfc: Fix second memory bank alignment > > Sylwester Nawrocki (7): > s5p-fimc: Enable FIMC-LITE driver only for SOC_EXYNOS4x12 > s5p-fimc: Don't allocate fimc-lite video device structure dynamically > s5p-fimc: Don't allocate fimc-capture video device dynamically > s5p-fimc: Don't allocate fimc-m2m video device dynamically > m5mols: Add missing free_irq() on error path > m5mols: Fix cast warnings from m5mols_[set/get]_ctrl_mode > s5p-fimc: Fix setup of initial links to FIMC entities I've added 2 more patches to this series: The following changes since commit f9cd49033b349b8be3bb1f01b39eed837853d880: Merge tag 'v3.6-rc1' into staging/for_v3.6 (2012-08-03 22:41:33 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l-fixes for you to fetch changes up to 06ed4e72ce30ef7d15ef2de7e15ed47107d05ded: s5p-fimc: fimc-lite: Propagate frame format on the subdev (2012-09-05 15:21:33 +0200) ---------------------------------------------------------------- Kamil Debski (1): s5p-mfc: Fix second memory bank alignment Sylwester Nawrocki (9): s5p-fimc: Enable FIMC-LITE driver only for SOC_EXYNOS4x12 s5p-fimc: Don't allocate fimc-lite video device structure dynamically s5p-fimc: Don't allocate fimc-capture video device dynamically s5p-fimc: Don't allocate fimc-m2m video device dynamically m5mols: Add missing free_irq() on error path m5mols: Fix cast warnings from m5mols_[set/get]_ctrl_mode s5p-fimc: Fix setup of initial links to FIMC entities s5p-fimc: fimc-lite: Correct Bayer pixel format definitions s5p-fimc: fimc-lite: Propagate frame format on the subdev drivers/media/video/m5mols/m5mols.h | 4 ++-- drivers/media/video/m5mols/m5mols_controls.c | 4 ++-- drivers/media/video/m5mols/m5mols_core.c | 4 +++- drivers/media/video/s5p-fimc/Kconfig | 2 +- drivers/media/video/s5p-fimc/fimc-capture.c | 31 ++++++++----------- drivers/media/video/s5p-fimc/fimc-core.h | 4 ++-- drivers/media/video/s5p-fimc/fimc-lite-reg.c | 8 ++++---- drivers/media/video/s5p-fimc/fimc-lite.c | 49 ++++++++++++++--------------- drivers/media/video/s5p-fimc/fimc-lite.h | 2 +- drivers/media/video/s5p-fimc/fimc-m2m.c | 40 +++++++++--------------- drivers/media/video/s5p-fimc/fimc-mdevice.c | 9 ++++++--- drivers/media/video/s5p-fimc/fimc-mdevice.h | 6 ++---- drivers/media/video/s5p-fimc/fimc-reg.c | 6 +++--- drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c | 2 +- 14 files changed, 73 insertions(+), 98 deletions(-) > drivers/media/video/m5mols/m5mols.h | 4 +-- > drivers/media/video/m5mols/m5mols_controls.c | 4 +-- > drivers/media/video/m5mols/m5mols_core.c | 4 ++- > drivers/media/video/s5p-fimc/Kconfig | 2 +- > drivers/media/video/s5p-fimc/fimc-capture.c | 31 +++++++----------- > drivers/media/video/s5p-fimc/fimc-core.h | 4 +-- > drivers/media/video/s5p-fimc/fimc-lite-reg.c | 2 +- > drivers/media/video/s5p-fimc/fimc-lite.c | 42 ++++++++++--------------- > drivers/media/video/s5p-fimc/fimc-lite.h | 2 +- > drivers/media/video/s5p-fimc/fimc-m2m.c | 40 ++++++++--------------- > drivers/media/video/s5p-fimc/fimc-mdevice.c | 9 ++++-- > drivers/media/video/s5p-fimc/fimc-mdevice.h | 6 ++-- > drivers/media/video/s5p-fimc/fimc-reg.c | 6 ++-- > drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c | 2 +- > 14 files changed, 65 insertions(+), 93 deletions(-) -- Thanks, Sylwester ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GIT PATCHES FOR v3.6] Samsung media driver fixes 2012-08-22 8:32 [GIT PATCHES FOR v3.6] Samsung media driver fixes Sylwester Nawrocki 2012-09-05 16:12 ` Sylwester Nawrocki @ 2012-10-01 9:52 ` Sylwester Nawrocki 2012-10-01 11:50 ` Antti Palosaari 1 sibling, 1 reply; 9+ messages in thread From: Sylwester Nawrocki @ 2012-10-01 9:52 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media@vger.kernel.org, Kamil Debski Hi Mauro, On 08/22/2012 10:32 AM, Sylwester Nawrocki wrote: It's been almost 6 weeks since I sent this pull request, now Linus released 3.6 kernel and this series is not included there. Moreover, I have been waiting with all patches for 3.7 until those get merged. Now it seems even too late for all these 3.7 patches. I cannot say I'm very happy about this situation. It's rather disappointing it takes so long for -rc patches to make it upstream, especially that not all of them are supposed to be allowed during late -rc periods. I wouldn't bother writing this email but AFAIR it's not the first time my -rc patches got missed. Is there anything I could do to improve this situation ? Regards, Sylwester > Hi Mauro, > > The following changes since commit f9cd49033b349b8be3bb1f01b39eed837853d880: > > Merge tag 'v3.6-rc1' into staging/for_v3.6 (2012-08-03 22:41:33 -0300) > > are available in the git repository at: > > > git://git.infradead.org/users/kmpark/linux-samsung v4l-fixes > > for you to fetch changes up to 0e59db054e30658c6955d6e27b0a252cef9bfafc: > > s5p-mfc: Fix second memory bank alignment (2012-08-16 19:12:19 +0200) > > ---------------------------------------------------------------- > Kamil Debski (1): > s5p-mfc: Fix second memory bank alignment > > Sylwester Nawrocki (7): > s5p-fimc: Enable FIMC-LITE driver only for SOC_EXYNOS4x12 > s5p-fimc: Don't allocate fimc-lite video device structure dynamically > s5p-fimc: Don't allocate fimc-capture video device dynamically > s5p-fimc: Don't allocate fimc-m2m video device dynamically > m5mols: Add missing free_irq() on error path > m5mols: Fix cast warnings from m5mols_[set/get]_ctrl_mode > s5p-fimc: Fix setup of initial links to FIMC entities > > drivers/media/video/m5mols/m5mols.h | 4 +-- > drivers/media/video/m5mols/m5mols_controls.c | 4 +-- > drivers/media/video/m5mols/m5mols_core.c | 4 ++- > drivers/media/video/s5p-fimc/Kconfig | 2 +- > drivers/media/video/s5p-fimc/fimc-capture.c | 31 +++++++----------- > drivers/media/video/s5p-fimc/fimc-core.h | 4 +-- > drivers/media/video/s5p-fimc/fimc-lite-reg.c | 2 +- > drivers/media/video/s5p-fimc/fimc-lite.c | 42 ++++++++++--------------- > drivers/media/video/s5p-fimc/fimc-lite.h | 2 +- > drivers/media/video/s5p-fimc/fimc-m2m.c | 40 ++++++++--------------- > drivers/media/video/s5p-fimc/fimc-mdevice.c | 9 ++++-- > drivers/media/video/s5p-fimc/fimc-mdevice.h | 6 ++-- > drivers/media/video/s5p-fimc/fimc-reg.c | 6 ++-- > drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c | 2 +- > 14 files changed, 65 insertions(+), 93 deletions(-) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GIT PATCHES FOR v3.6] Samsung media driver fixes 2012-10-01 9:52 ` Sylwester Nawrocki @ 2012-10-01 11:50 ` Antti Palosaari 2012-10-01 13:35 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 9+ messages in thread From: Antti Palosaari @ 2012-10-01 11:50 UTC (permalink / raw) To: Sylwester Nawrocki Cc: Mauro Carvalho Chehab, linux-media@vger.kernel.org, Kamil Debski Hello I have had similar problems too. We need badly find out better procedures for patch handling. Something like parches are updated about once per week to the master. I have found I lose quite much time rebasing and res-sending stuff all the time. What I propose: 1) module maintainers sends all patches to the ML with some tag marking it will pull requested later. I used lately [PATCH RFC] 2) module maintainer will pick up all the "random" patches and pull request those. There is no way to mark patch as handled in patchwork.... 3) PULL request are handled more often, like during one week or maximum two regards Antti On 10/01/2012 12:52 PM, Sylwester Nawrocki wrote: > Hi Mauro, > > On 08/22/2012 10:32 AM, Sylwester Nawrocki wrote: > > It's been almost 6 weeks since I sent this pull request, now Linus > released 3.6 kernel and this series is not included there. Moreover, > I have been waiting with all patches for 3.7 until those get merged. > Now it seems even too late for all these 3.7 patches. I cannot say > I'm very happy about this situation. It's rather disappointing it > takes so long for -rc patches to make it upstream, especially that > not all of them are supposed to be allowed during late -rc periods. > I wouldn't bother writing this email but AFAIR it's not the first > time my -rc patches got missed. > > Is there anything I could do to improve this situation ? > > Regards, > Sylwester > >> Hi Mauro, >> >> The following changes since commit f9cd49033b349b8be3bb1f01b39eed837853d880: >> >> Merge tag 'v3.6-rc1' into staging/for_v3.6 (2012-08-03 22:41:33 -0300) >> >> are available in the git repository at: >> >> >> git://git.infradead.org/users/kmpark/linux-samsung v4l-fixes >> >> for you to fetch changes up to 0e59db054e30658c6955d6e27b0a252cef9bfafc: >> >> s5p-mfc: Fix second memory bank alignment (2012-08-16 19:12:19 +0200) >> >> ---------------------------------------------------------------- >> Kamil Debski (1): >> s5p-mfc: Fix second memory bank alignment >> >> Sylwester Nawrocki (7): >> s5p-fimc: Enable FIMC-LITE driver only for SOC_EXYNOS4x12 >> s5p-fimc: Don't allocate fimc-lite video device structure dynamically >> s5p-fimc: Don't allocate fimc-capture video device dynamically >> s5p-fimc: Don't allocate fimc-m2m video device dynamically >> m5mols: Add missing free_irq() on error path >> m5mols: Fix cast warnings from m5mols_[set/get]_ctrl_mode >> s5p-fimc: Fix setup of initial links to FIMC entities >> >> drivers/media/video/m5mols/m5mols.h | 4 +-- >> drivers/media/video/m5mols/m5mols_controls.c | 4 +-- >> drivers/media/video/m5mols/m5mols_core.c | 4 ++- >> drivers/media/video/s5p-fimc/Kconfig | 2 +- >> drivers/media/video/s5p-fimc/fimc-capture.c | 31 +++++++----------- >> drivers/media/video/s5p-fimc/fimc-core.h | 4 +-- >> drivers/media/video/s5p-fimc/fimc-lite-reg.c | 2 +- >> drivers/media/video/s5p-fimc/fimc-lite.c | 42 ++++++++++--------------- >> drivers/media/video/s5p-fimc/fimc-lite.h | 2 +- >> drivers/media/video/s5p-fimc/fimc-m2m.c | 40 ++++++++--------------- >> drivers/media/video/s5p-fimc/fimc-mdevice.c | 9 ++++-- >> drivers/media/video/s5p-fimc/fimc-mdevice.h | 6 ++-- >> drivers/media/video/s5p-fimc/fimc-reg.c | 6 ++-- >> drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c | 2 +- >> 14 files changed, 65 insertions(+), 93 deletions(-) > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- http://palosaari.fi/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GIT PATCHES FOR v3.6] Samsung media driver fixes 2012-10-01 11:50 ` Antti Palosaari @ 2012-10-01 13:35 ` Mauro Carvalho Chehab 2012-10-01 14:05 ` Ezequiel Garcia 0 siblings, 1 reply; 9+ messages in thread From: Mauro Carvalho Chehab @ 2012-10-01 13:35 UTC (permalink / raw) To: Antti Palosaari Cc: Sylwester Nawrocki, linux-media@vger.kernel.org, Kamil Debski Hi Anti/Sylwester, Em 01-10-2012 08:50, Antti Palosaari escreveu: > Hello > I have had similar problems too. We need badly find out better procedures for patch handling. Something like parches are updated about once per week to the master. I have found I lose quite much time rebasing and res-sending stuff all the time. > > What I propose: > 1) module maintainers sends all patches to the ML with some tag marking it will pull requested later. I used lately [PATCH RFC] > 2) module maintainer will pick up all the "random" patches and pull request those. There is no way to mark patch as handled in patchwork.... > 3) PULL request are handled more often, like during one week or maximum two Yes, for sure we need to improve the workflow. After the return from KS, I found ~400 patches/pull requests on my queue. I'm working hard to get rid of that backlog, but still there are ~270 patches/pull requests on my queue today. The thing is that patches come on a high rate at the ML, and there's no obvious way to discover what patches are just the normal patch review discussions (e. g. RFC) and what are real patches. To make things worse, we have nowadays 494 drivers. A very few of those have an entry at MAINTAINERS, or a maintainer that care enough about his drivers to handle patches sent to the mailing list (even the trivial ones). Due to the missing MAINTAINERS entries, all patches go through the ML directly, instead of going through the driver maintainer. So, I need to manually review every single email that looks to have a patch inside, typically forwarding it to the driver maintainer, when it exists, handling them myself otherwise. I'm counting with our discussions at the Barcelona's mini-summit in order to be able to get fresh ideas and discuss some alternatives to improve the patch workflow, but there are several things that could be done already, like the ones you've proposed, and keeping the MAINTAINERS file updated. Regards, Mauro > > regards > Antti > > > On 10/01/2012 12:52 PM, Sylwester Nawrocki wrote: >> Hi Mauro, >> >> On 08/22/2012 10:32 AM, Sylwester Nawrocki wrote: >> >> It's been almost 6 weeks since I sent this pull request, now Linus >> released 3.6 kernel and this series is not included there. Moreover, >> I have been waiting with all patches for 3.7 until those get merged. >> Now it seems even too late for all these 3.7 patches. I cannot say >> I'm very happy about this situation. It's rather disappointing it >> takes so long for -rc patches to make it upstream, especially that >> not all of them are supposed to be allowed during late -rc periods. >> I wouldn't bother writing this email but AFAIR it's not the first >> time my -rc patches got missed. >> >> Is there anything I could do to improve this situation ? >> >> Regards, >> Sylwester >> >>> Hi Mauro, >>> >>> The following changes since commit f9cd49033b349b8be3bb1f01b39eed837853d880: >>> >>> Merge tag 'v3.6-rc1' into staging/for_v3.6 (2012-08-03 22:41:33 -0300) >>> >>> are available in the git repository at: >>> >>> >>> git://git.infradead.org/users/kmpark/linux-samsung v4l-fixes >>> >>> for you to fetch changes up to 0e59db054e30658c6955d6e27b0a252cef9bfafc: >>> >>> s5p-mfc: Fix second memory bank alignment (2012-08-16 19:12:19 +0200) >>> >>> ---------------------------------------------------------------- >>> Kamil Debski (1): >>> s5p-mfc: Fix second memory bank alignment >>> >>> Sylwester Nawrocki (7): >>> s5p-fimc: Enable FIMC-LITE driver only for SOC_EXYNOS4x12 >>> s5p-fimc: Don't allocate fimc-lite video device structure dynamically >>> s5p-fimc: Don't allocate fimc-capture video device dynamically >>> s5p-fimc: Don't allocate fimc-m2m video device dynamically >>> m5mols: Add missing free_irq() on error path >>> m5mols: Fix cast warnings from m5mols_[set/get]_ctrl_mode >>> s5p-fimc: Fix setup of initial links to FIMC entities >>> >>> drivers/media/video/m5mols/m5mols.h | 4 +-- >>> drivers/media/video/m5mols/m5mols_controls.c | 4 +-- >>> drivers/media/video/m5mols/m5mols_core.c | 4 ++- >>> drivers/media/video/s5p-fimc/Kconfig | 2 +- >>> drivers/media/video/s5p-fimc/fimc-capture.c | 31 +++++++----------- >>> drivers/media/video/s5p-fimc/fimc-core.h | 4 +-- >>> drivers/media/video/s5p-fimc/fimc-lite-reg.c | 2 +- >>> drivers/media/video/s5p-fimc/fimc-lite.c | 42 ++++++++++--------------- >>> drivers/media/video/s5p-fimc/fimc-lite.h | 2 +- >>> drivers/media/video/s5p-fimc/fimc-m2m.c | 40 ++++++++--------------- >>> drivers/media/video/s5p-fimc/fimc-mdevice.c | 9 ++++-- >>> drivers/media/video/s5p-fimc/fimc-mdevice.h | 6 ++-- >>> drivers/media/video/s5p-fimc/fimc-reg.c | 6 ++-- >>> drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c | 2 +- >>> 14 files changed, 65 insertions(+), 93 deletions(-) >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GIT PATCHES FOR v3.6] Samsung media driver fixes 2012-10-01 13:35 ` Mauro Carvalho Chehab @ 2012-10-01 14:05 ` Ezequiel Garcia 2012-10-01 14:28 ` Hans Verkuil 0 siblings, 1 reply; 9+ messages in thread From: Ezequiel Garcia @ 2012-10-01 14:05 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Antti Palosaari, Sylwester Nawrocki, linux-media@vger.kernel.org, Kamil Debski Mauro and folks, On Mon, Oct 1, 2012 at 10:35 AM, Mauro Carvalho Chehab <mchehab@redhat.com> wrote: > Hi Anti/Sylwester, > > Em 01-10-2012 08:50, Antti Palosaari escreveu: >> Hello >> I have had similar problems too. We need badly find out better procedures for patch handling. Something like parches are updated about once per week to the master. I have found I lose quite much time rebasing and res-sending stuff all the time. >> >> What I propose: >> 1) module maintainers sends all patches to the ML with some tag marking it will pull requested later. I used lately [PATCH RFC] >> 2) module maintainer will pick up all the "random" patches and pull request those. There is no way to mark patch as handled in patchwork.... >> 3) PULL request are handled more often, like during one week or maximum two > > Yes, for sure we need to improve the workflow. After the return from KS, > I found ~400 patches/pull requests on my queue. I'm working hard to get rid > of that backlog, but still there are ~270 patches/pull requests on my > queue today. > > The thing is that patches come on a high rate at the ML, and there's no > obvious way to discover what patches are just the normal patch review > discussions (e. g. RFC) and what are real patches. > > To make things worse, we have nowadays 494 drivers. A very few of those > have an entry at MAINTAINERS, or a maintainer that care enough about > his drivers to handle patches sent to the mailing list (even the trivial > ones). > > Due to the missing MAINTAINERS entries, all patches go through the ML directly, > instead of going through the driver maintainer. > > So, I need to manually review every single email that looks to have a patch > inside, typically forwarding it to the driver maintainer, when it exists, > handling them myself otherwise. > > I'm counting with our discussions at the Barcelona's mini-summit in order > to be able to get fresh ideas and discuss some alternatives to improve > the patch workflow, but there are several things that could be done already, > like the ones you've proposed, and keeping the MAINTAINERS file updated. > Perhaps I'm missing something but I don't think there's an obvious solution for this, unless more maintainers are willing to start providing reviews / tests / acks / etc. for patches that arrive. Seems to me media/ has become a truly large subsystem, though I'm not sure how does it compare to others subsystems. Has anyone thought about breaking media/ down into smaller sub-subsystems, with respective sub-maintainer? I'm not really sure if this should improve or worsen Mauro's rate. Just my two cents, Ezequiel. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GIT PATCHES FOR v3.6] Samsung media driver fixes 2012-10-01 14:05 ` Ezequiel Garcia @ 2012-10-01 14:28 ` Hans Verkuil 2012-10-01 14:44 ` Sylwester Nawrocki 0 siblings, 1 reply; 9+ messages in thread From: Hans Verkuil @ 2012-10-01 14:28 UTC (permalink / raw) To: Ezequiel Garcia Cc: Mauro Carvalho Chehab, Antti Palosaari, Sylwester Nawrocki, linux-media@vger.kernel.org, Kamil Debski On Mon October 1 2012 16:05:15 Ezequiel Garcia wrote: > Mauro and folks, > > On Mon, Oct 1, 2012 at 10:35 AM, Mauro Carvalho Chehab > <mchehab@redhat.com> wrote: > > Hi Anti/Sylwester, > > > > Em 01-10-2012 08:50, Antti Palosaari escreveu: > >> Hello > >> I have had similar problems too. We need badly find out better procedures for patch handling. Something like parches are updated about once per week to the master. I have found I lose quite much time rebasing and res-sending stuff all the time. > >> > >> What I propose: > >> 1) module maintainers sends all patches to the ML with some tag marking it will pull requested later. I used lately [PATCH RFC] > >> 2) module maintainer will pick up all the "random" patches and pull request those. There is no way to mark patch as handled in patchwork.... > >> 3) PULL request are handled more often, like during one week or maximum two > > > > Yes, for sure we need to improve the workflow. After the return from KS, > > I found ~400 patches/pull requests on my queue. I'm working hard to get rid > > of that backlog, but still there are ~270 patches/pull requests on my > > queue today. > > > > The thing is that patches come on a high rate at the ML, and there's no > > obvious way to discover what patches are just the normal patch review > > discussions (e. g. RFC) and what are real patches. > > > > To make things worse, we have nowadays 494 drivers. A very few of those > > have an entry at MAINTAINERS, or a maintainer that care enough about > > his drivers to handle patches sent to the mailing list (even the trivial > > ones). > > > > Due to the missing MAINTAINERS entries, all patches go through the ML directly, > > instead of going through the driver maintainer. > > > > So, I need to manually review every single email that looks to have a patch > > inside, typically forwarding it to the driver maintainer, when it exists, > > handling them myself otherwise. > > > > I'm counting with our discussions at the Barcelona's mini-summit in order > > to be able to get fresh ideas and discuss some alternatives to improve > > the patch workflow, but there are several things that could be done already, > > like the ones you've proposed, and keeping the MAINTAINERS file updated. > > > > Perhaps I'm missing something but I don't think there's an obvious > solution for this, > unless more maintainers are willing to start providing reviews / tests > / acks / etc. > for patches that arrive. > > Seems to me media/ has become a truly large subsystem, > though I'm not sure how does it compare to others subsystems. > Has anyone thought about breaking media/ down into smaller sub-subsystems, > with respective sub-maintainer? Yes, and this will be discussed next month during the Media Summit. Regards, Hans > I'm not really sure if this should improve or worsen Mauro's rate. > > Just my two cents, > Ezequiel. > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GIT PATCHES FOR v3.6] Samsung media driver fixes 2012-10-01 14:28 ` Hans Verkuil @ 2012-10-01 14:44 ` Sylwester Nawrocki 2012-10-01 14:48 ` Ezequiel Garcia 0 siblings, 1 reply; 9+ messages in thread From: Sylwester Nawrocki @ 2012-10-01 14:44 UTC (permalink / raw) To: Hans Verkuil Cc: Ezequiel Garcia, Mauro Carvalho Chehab, Antti Palosaari, linux-media@vger.kernel.org, Kamil Debski On 10/01/2012 04:28 PM, Hans Verkuil wrote: > On Mon October 1 2012 16:05:15 Ezequiel Garcia wrote: >> Mauro and folks, >> >> On Mon, Oct 1, 2012 at 10:35 AM, Mauro Carvalho Chehab >> <mchehab@redhat.com> wrote: >>> Hi Anti/Sylwester, >>> >>> Em 01-10-2012 08:50, Antti Palosaari escreveu: >>>> Hello >>>> I have had similar problems too. We need badly find out better procedures for patch handling. Something like parches are updated about once per week to the master. I have found I lose quite much time rebasing and res-sending stuff all the time. >>>> >>>> What I propose: >>>> 1) module maintainers sends all patches to the ML with some tag marking it will pull requested later. I used lately [PATCH RFC] >>>> 2) module maintainer will pick up all the "random" patches and pull request those. There is no way to mark patch as handled in patchwork.... >>>> 3) PULL request are handled more often, like during one week or maximum two >>> >>> Yes, for sure we need to improve the workflow. After the return from KS, >>> I found ~400 patches/pull requests on my queue. I'm working hard to get rid >>> of that backlog, but still there are ~270 patches/pull requests on my >>> queue today. >>> >>> The thing is that patches come on a high rate at the ML, and there's no >>> obvious way to discover what patches are just the normal patch review >>> discussions (e. g. RFC) and what are real patches. >>> >>> To make things worse, we have nowadays 494 drivers. A very few of those >>> have an entry at MAINTAINERS, or a maintainer that care enough about >>> his drivers to handle patches sent to the mailing list (even the trivial >>> ones). >>> >>> Due to the missing MAINTAINERS entries, all patches go through the ML directly, >>> instead of going through the driver maintainer. >>> >>> So, I need to manually review every single email that looks to have a patch >>> inside, typically forwarding it to the driver maintainer, when it exists, >>> handling them myself otherwise. >>> >>> I'm counting with our discussions at the Barcelona's mini-summit in order >>> to be able to get fresh ideas and discuss some alternatives to improve >>> the patch workflow, but there are several things that could be done already, >>> like the ones you've proposed, and keeping the MAINTAINERS file updated. >>> >> >> Perhaps I'm missing something but I don't think there's an obvious >> solution for this, >> unless more maintainers are willing to start providing reviews / tests >> / acks / etc. >> for patches that arrive. >> >> Seems to me media/ has become a truly large subsystem, >> though I'm not sure how does it compare to others subsystems. >> Has anyone thought about breaking media/ down into smaller sub-subsystems, >> with respective sub-maintainer? > > Yes, and this will be discussed next month during the Media Summit. Something like this came through my mind as well. It seems handling all the drivers/media stuff is becoming simply too much to tackle by one person in quality and timely manner. -- Regards, Sylwester ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GIT PATCHES FOR v3.6] Samsung media driver fixes 2012-10-01 14:44 ` Sylwester Nawrocki @ 2012-10-01 14:48 ` Ezequiel Garcia 0 siblings, 0 replies; 9+ messages in thread From: Ezequiel Garcia @ 2012-10-01 14:48 UTC (permalink / raw) To: Sylwester Nawrocki Cc: Hans Verkuil, Mauro Carvalho Chehab, Antti Palosaari, linux-media@vger.kernel.org, Kamil Debski On Mon, Oct 1, 2012 at 11:44 AM, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote: > On 10/01/2012 04:28 PM, Hans Verkuil wrote: >> On Mon October 1 2012 16:05:15 Ezequiel Garcia wrote: >>> Mauro and folks, >>> >>> On Mon, Oct 1, 2012 at 10:35 AM, Mauro Carvalho Chehab >>> <mchehab@redhat.com> wrote: >>>> Hi Anti/Sylwester, >>>> >>>> Em 01-10-2012 08:50, Antti Palosaari escreveu: >>>>> Hello >>>>> I have had similar problems too. We need badly find out better procedures for patch handling. Something like parches are updated about once per week to the master. I have found I lose quite much time rebasing and res-sending stuff all the time. >>>>> >>>>> What I propose: >>>>> 1) module maintainers sends all patches to the ML with some tag marking it will pull requested later. I used lately [PATCH RFC] >>>>> 2) module maintainer will pick up all the "random" patches and pull request those. There is no way to mark patch as handled in patchwork.... >>>>> 3) PULL request are handled more often, like during one week or maximum two >>>> >>>> Yes, for sure we need to improve the workflow. After the return from KS, >>>> I found ~400 patches/pull requests on my queue. I'm working hard to get rid >>>> of that backlog, but still there are ~270 patches/pull requests on my >>>> queue today. >>>> >>>> The thing is that patches come on a high rate at the ML, and there's no >>>> obvious way to discover what patches are just the normal patch review >>>> discussions (e. g. RFC) and what are real patches. >>>> >>>> To make things worse, we have nowadays 494 drivers. A very few of those >>>> have an entry at MAINTAINERS, or a maintainer that care enough about >>>> his drivers to handle patches sent to the mailing list (even the trivial >>>> ones). >>>> >>>> Due to the missing MAINTAINERS entries, all patches go through the ML directly, >>>> instead of going through the driver maintainer. >>>> >>>> So, I need to manually review every single email that looks to have a patch >>>> inside, typically forwarding it to the driver maintainer, when it exists, >>>> handling them myself otherwise. >>>> >>>> I'm counting with our discussions at the Barcelona's mini-summit in order >>>> to be able to get fresh ideas and discuss some alternatives to improve >>>> the patch workflow, but there are several things that could be done already, >>>> like the ones you've proposed, and keeping the MAINTAINERS file updated. >>>> >>> >>> Perhaps I'm missing something but I don't think there's an obvious >>> solution for this, >>> unless more maintainers are willing to start providing reviews / tests >>> / acks / etc. >>> for patches that arrive. >>> >>> Seems to me media/ has become a truly large subsystem, >>> though I'm not sure how does it compare to others subsystems. >>> Has anyone thought about breaking media/ down into smaller sub-subsystems, >>> with respective sub-maintainer? >> >> Yes, and this will be discussed next month during the Media Summit. > > Something like this came through my mind as well. It seems handling all > the drivers/media stuff is becoming simply too much to tackle by one person > in quality and timely manner. > Another issue that needs discussion is the vast amount of different devices (consider em28xx for instance) making maintainment particularly hard. Perhaps, some sort of "Device donation request" (aimed at hw vendors) to distribute among developers could be helpful. Regards, Ezequiel. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-10-01 14:48 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-08-22 8:32 [GIT PATCHES FOR v3.6] Samsung media driver fixes Sylwester Nawrocki 2012-09-05 16:12 ` Sylwester Nawrocki 2012-10-01 9:52 ` Sylwester Nawrocki 2012-10-01 11:50 ` Antti Palosaari 2012-10-01 13:35 ` Mauro Carvalho Chehab 2012-10-01 14:05 ` Ezequiel Garcia 2012-10-01 14:28 ` Hans Verkuil 2012-10-01 14:44 ` Sylwester Nawrocki 2012-10-01 14:48 ` Ezequiel Garcia
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).