Patchwork [GIT,PULL] Samsung devel for v3.3

login
register
mail settings
Submitter Kukjin Kim
Date Jan. 3, 2012, 11:33 p.m.
Message ID <018801ccca70$25f01260$71d03720$%kim@samsung.com>
Download mbox
Permalink /patch/134123/
State New
Headers show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git

Comments

Kukjin Kim - Jan. 3, 2012, 11:33 p.m.
Hi Arnd,

Please pull Samsung devel for v3.3 from:
 git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
next-samsung-devel-samsung

It is including s3c64xx cpuidle and development for Cragganmore, ORIGEN and
some boards.

If any problems, please let me know.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

The following changes since commit 5f0a6e2d503896062f641639dacfe5055c2f593b:

  Linux 3.2-rc7 (2011-12-23 21:51:06 -0800)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
next-samsung-devel-samsung

Denis Kuzmenko (1):
      ARM: S3C2440: Add new LCD (W35i) support for Mini2440 board

Jingoo Han (1):
      ARM: SAMSUNG: Add a callback 'notify_after' for PWM backlight control

Kamil Debski (3):
      ARM: SAMSUNG: add G2D to plat-s5p and mach-exynos
      ARM: EXYNOS: add G2D to mach-nuri
      ARM: EXYNOS: add G2D to mach-universal

Mark Brown (26):
      ARM: S3C64XX: Update for conversion to SAMSUNG_GPIO_EXTRA
      ARM: SAMSUNG: Fix GPIO space reservation for S3C64xx platforms
      ARM: S3C64XX: Correct reservation of GPIOs for CPU module on
Cragganmore
      ARM: S3C64XX: Raise the frequency of the second I2C bus on Cragganmore
      ARM: S3C64XX: Use software initiated powerdown for Cragganmore
      ARM: S3C64XX: Configure WM1250 EV1 GPIOs on Cragganmore
      ARM: S3C64XX: Improve logging of unknown Cragganmore module types
      ARM: S3C64XX: Run Tobermory interrupts in the default mode
      ARM: S3C64XX: Hook up platform data for Kilchomin module on
Cragganmore
      ARM: S3C64XX: Hook up Littlemill audio card on Cragganmore
      ARM: S3C64XX: Power gate unused domains
      ARM: S3C64XX: Hook up VDDINT on Cragganmore
      ARM: S3C64XX: Add basic cpuidle driver
      ARM: S3C64XX: Gate some more clocks by default
      ARM: SAMSUNG: Guard against multiple inclusion of plat/dma.h
      ARM: SAMSUNG: dma-ops.h needs mach/dma.h
      ARM: S3C64XX: Remove unconditional power domain disables
      ARM: S3C64XX: Remove hsmmc1 from Cragganmore
      ARM: SAMSUNG: Declare struct platform_device in plat/s3c64xx-spi.h
      ARM: S3C64XX: Fix the memory mapped GPIOs on Cragganmore
      ARM: S3C64XX: Support GPIO LEDs on Cragganmore
      ARM: S3C64XX: Reduce residency requirement for cpuidle WFI mode
      ARM: S3C64XX: Fix interrupt configuration for PCA935x on Cragganmore
      ARM: S3C64XX: Fix build of Cragganmore after SPI changes
      ARM: S3C64XX: Enable power management for disk on Cragganmore
      ARM: S3C64XX: Enable power management for WiFi on Cragganmore

MyungJoo Ham (3):
      ARM: EXYNOS: Add DMC1 and allow PPMU access for DMC
      ARM: EXYNOS: Add clock register addresses for EXYNOS4X12 bus devfreq
driver
      ARM: EXYNOS: Add support EXYNOS4210-bus Devfreq driver on Nuri board

Sachin Kamat (1):
      ARM: EXYNOS: Enable G2D on ORIGEN

Sangwook Lee (1):
      ARM: EXYNOS: Enable Bluetooth on ORIGEN

Tushar Behera (1):
      ARM: EXYNOS: Invert VCLK polarity for framebuffer on ORIGEN

 arch/arm/mach-exynos/Kconfig                     |    3 +
 arch/arm/mach-exynos/cpu.c                       |    7 +-
 arch/arm/mach-exynos/include/mach/map.h          |    4 +
 arch/arm/mach-exynos/include/mach/regs-clock.h   |   42 +++++++++
 arch/arm/mach-exynos/mach-nuri.c                 |   12 ++-
 arch/arm/mach-exynos/mach-origen.c               |   38 ++++++++-
 arch/arm/mach-exynos/mach-universal_c210.c       |    1 +
 arch/arm/mach-s3c2440/mach-mini2440.c            |   18 ++++
 arch/arm/mach-s3c64xx/Kconfig                    |    7 +-
 arch/arm/mach-s3c64xx/Makefile                   |    1 +
 arch/arm/mach-s3c64xx/clock.c                    |   21 ++--
 arch/arm/mach-s3c64xx/cpuidle.c                  |   91 ++++++++++++++++++
 arch/arm/mach-s3c64xx/include/mach/crag6410.h    |    7 +-
 arch/arm/mach-s3c64xx/include/mach/gpio.h        |    2 +-
 arch/arm/mach-s3c64xx/include/mach/irqs.h        |    2 +-
 arch/arm/mach-s3c64xx/mach-crag6410-module.c     |   56 +++++++++++-
 arch/arm/mach-s3c64xx/mach-crag6410.c            |  107
+++++++++++++++++++---
 arch/arm/mach-s3c64xx/pm.c                       |    2 +
 arch/arm/plat-s5p/Kconfig                        |    5 +
 arch/arm/plat-samsung/Kconfig                    |    8 ++
 arch/arm/plat-samsung/dev-backlight.c            |    2 +
 arch/arm/plat-samsung/devs.c                     |   28 ++++++
 arch/arm/plat-samsung/include/plat/devs.h        |    1 +
 arch/arm/plat-samsung/include/plat/dma-ops.h     |    1 +
 arch/arm/plat-samsung/include/plat/dma.h         |    6 +-
 arch/arm/plat-samsung/include/plat/s3c64xx-spi.h |    2 +
 26 files changed, 434 insertions(+), 40 deletions(-)
 create mode 100644 arch/arm/mach-s3c64xx/cpuidle.c
Olof Johansson - Jan. 6, 2012, 9:58 p.m.
On Tue, Jan 3, 2012 at 3:33 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> Hi Arnd,
>
> Please pull Samsung devel for v3.3 from:
>  git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> next-samsung-devel-samsung
>
> It is including s3c64xx cpuidle and development for Cragganmore, ORIGEN and
> some boards.
>
> If any problems, please let me know.

Thanks. I've pulled this into late/devel, based on earlier email from
Arnd we might end up sending this in towards the end of the merge
window, but there's also a chance it will wait for 3.4.


-Olof
Kukjin Kim - Jan. 7, 2012, 10:09 a.m.
Olof Johansson wrote:
> 
> On Tue, Jan 3, 2012 at 3:33 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> > Hi Arnd,
> >
> > Please pull Samsung devel for v3.3 from:
> >  git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> > next-samsung-devel-samsung
> >
> > It is including s3c64xx cpuidle and development for Cragganmore, ORIGEN
> and
> > some boards.
> >
> > If any problems, please let me know.
> 
> Thanks. I've pulled this into late/devel, based on earlier email from
> Arnd we might end up sending this in towards the end of the merge
> window, but there's also a chance it will wait for 3.4.
> 
OK, but I hope we can see them on 3.3-rc1 and actually, they were queuing in
my devel branch for a long time.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
Mark Brown - Jan. 8, 2012, 8:49 p.m.
On Fri, Jan 06, 2012 at 01:58:29PM -0800, Olof Johansson wrote:

> > Please pull Samsung devel for v3.3 from:
> > ?git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> > next-samsung-devel-samsung

> Thanks. I've pulled this into late/devel, based on earlier email from
> Arnd we might end up sending this in towards the end of the merge
> window, but there's also a chance it will wait for 3.4.

That'd be extremely disappointing, especially given that there's some
bug fixes in there for updates going in this merge window without which
mainline is going to have problems on s3c64xx (mostly the GPIO stuff).
Olof Johansson - Jan. 9, 2012, 1:21 a.m.
On Sun, Jan 8, 2012 at 12:49 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Fri, Jan 06, 2012 at 01:58:29PM -0800, Olof Johansson wrote:
>
>> > Please pull Samsung devel for v3.3 from:
>> > ?git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> > next-samsung-devel-samsung
>
>> Thanks. I've pulled this into late/devel, based on earlier email from
>> Arnd we might end up sending this in towards the end of the merge
>> window, but there's also a chance it will wait for 3.4.
>
> That'd be extremely disappointing, especially given that there's some
> bug fixes in there for updates going in this merge window without which
> mainline is going to have problems on s3c64xx (mostly the GPIO stuff).

Of course bug fixes should go in.

Mark, Kukjin, can either of you split out the fixes in a separate branch?


Thanks,

-Olof
Kukjin Kim - Jan. 9, 2012, 1:40 a.m.
Olof Johansson wrote:
> 
> On Sun, Jan 8, 2012 at 12:49 PM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
> > On Fri, Jan 06, 2012 at 01:58:29PM -0800, Olof Johansson wrote:
> >
> >> > Please pull Samsung devel for v3.3 from:
> >> > ?git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> >> > next-samsung-devel-samsung
> >
> >> Thanks. I've pulled this into late/devel, based on earlier email from
> >> Arnd we might end up sending this in towards the end of the merge
> >> window, but there's also a chance it will wait for 3.4.
> >
> > That'd be extremely disappointing, especially given that there's some
> > bug fixes in there for updates going in this merge window without which
> > mainline is going to have problems on s3c64xx (mostly the GPIO stuff).
> 
> Of course bug fixes should go in.
> 
> Mark, Kukjin, can either of you split out the fixes in a separate branch?
> 
Hi Olof,

In my opinion, as you know, it would be better to us if you could send this in this merge window.
Actually, it does not have any dependency with others, in addition, for a long time this has been included in linux-next for this
merge window.
If this can be missed from sending list to Linus, please kindly let me know. Let me send this to Linus at the end of this merge
window.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
Olof Johansson - Jan. 9, 2012, 2:03 a.m.
On Sun, Jan 8, 2012 at 5:40 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> Olof Johansson wrote:
>>
>> On Sun, Jan 8, 2012 at 12:49 PM, Mark Brown
>> <broonie@opensource.wolfsonmicro.com> wrote:
>> > On Fri, Jan 06, 2012 at 01:58:29PM -0800, Olof Johansson wrote:
>> >
>> >> > Please pull Samsung devel for v3.3 from:
>> >> > ?git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> >> > next-samsung-devel-samsung
>> >
>> >> Thanks. I've pulled this into late/devel, based on earlier email from
>> >> Arnd we might end up sending this in towards the end of the merge
>> >> window, but there's also a chance it will wait for 3.4.
>> >
>> > That'd be extremely disappointing, especially given that there's some
>> > bug fixes in there for updates going in this merge window without which
>> > mainline is going to have problems on s3c64xx (mostly the GPIO stuff).
>>
>> Of course bug fixes should go in.
>>
>> Mark, Kukjin, can either of you split out the fixes in a separate branch?
>>
> Hi Olof,
>
> In my opinion, as you know, it would be better to us if you could send this in this merge window.
> Actually, it does not have any dependency with others, in addition, for a long time this has been included in linux-next for this
> merge window.
> If this can be missed from sending list to Linus, please kindly let me know. Let me send this to Linus at the end of this merge
> window.

We've been pretty clear on this: Everything that came in after Arnd's
email (that wasn't obvious fixes) would be queued as late/* and, if
there is time, go in towards the end of the merge window. There's
plenty of time left in the window so right now it looks likely to
happen, especially since the branch lacks dependencies and applies
relatively cleanly.


-Olof
Russell King - ARM Linux - Jan. 9, 2012, 9:58 a.m.
On Sun, Jan 08, 2012 at 08:49:53PM +0000, Mark Brown wrote:
> On Fri, Jan 06, 2012 at 01:58:29PM -0800, Olof Johansson wrote:
> 
> > > Please pull Samsung devel for v3.3 from:
> > > ?git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> > > next-samsung-devel-samsung
> 
> > Thanks. I've pulled this into late/devel, based on earlier email from
> > Arnd we might end up sending this in towards the end of the merge
> > window, but there's also a chance it will wait for 3.4.
> 
> That'd be extremely disappointing, especially given that there's some
> bug fixes in there for updates going in this merge window without which
> mainline is going to have problems on s3c64xx (mostly the GPIO stuff).

Here we go again with sucky work practices.

This sucky behaviour has been around for a long time, I've long since
given up complaining about it as it's exactly like talking to a bloody
brick wall.  People just continue mixing development and fixes together.

They then wonder why their fixes don't make it into mainline in a timely
fashion.

Maybe delaying the whole lot will make people change their behaviour:
it's a behaviour that needs to change at the submitters end.  There's
nothing which Olof or Arnd can reasonably do to expedite the fixes.

So, please direct your complaints to the submitter for not having a
work practice which ensures that fixes receive a higher submission
priority.

Note: Linus _has_ taken a copy of linux-next (read the 3.2 release email),
and _is_ checking whether development stuff was in linux-next prior to
the merge window opening.  It would be very unwise to send new development
which wasn't already there.
Arnd Bergmann - Jan. 9, 2012, 3:56 p.m.
On Monday 09 January 2012, Kukjin Kim wrote:
> In my opinion, as you know, it would be better to us if you could send this in
> this merge window.
> Actually, it does not have any dependency with others, in addition, for a long
> time this has been included in linux-next for this
> merge window.

Your patches have caused too much problems already so far, with many complex
merges (multiple files combined into new files in the restart branch, but
modified in multiple other conflicting branches), and I would rather not
see *anything* besides fixes from you for late 3.3 patches. If it hadn't
been for the conflicts I mentioned, everything else from arm-soc could
have been sent last Saturday already, but this way I spent a national
holiday and a weekend day, both during my vacation, mostly trying to
understand what you were trying to do and get it into shape for upstream
submission, giving up in the end.

I don't consider it enough to have patches in linux-next before the merge
window, and I thought I had made it clear enough that everything has to be
in arm-soc before the merge window. I realize that sometimes there is stuff
that gets done last minute and really has to get merged, but since you have
had it in your own tree for so long, that certainly doesn't apply here.

> If this can be missed from sending list to Linus, please kindly let me know.

Sorry, but the chances are pretty slim this time.

> Let me send this to Linus at the end of this merge window.

No, if you do this, I will NAK that pull request.

Of course we will take all bug fixes. Just rebase the rest on top of 3.3-rc1
and we can take it right away for 3.4.

	Arnd
Mark Brown - Jan. 9, 2012, 4:11 p.m.
On Mon, Jan 09, 2012 at 03:56:34PM +0000, Arnd Bergmann wrote:

> Of course we will take all bug fixes. Just rebase the rest on top of 3.3-rc1
> and we can take it right away for 3.4.

I've sent a pull request earlier in the thread for the main ones I'm
aware of (which are mostly fixes for things introduced in this cycle) -
the others I'm aware of are all specific to Cragganmore and given that
we can't get any of the features for that merged the fixes aren't going
to have any practical effect until we can manage to get the feature
stuff merged so it's not really worth the effort.

This really is very disappointing.
Mark Brown - Jan. 9, 2012, 11:24 p.m.
On Mon, Jan 09, 2012 at 09:58:39AM +0000, Russell King - ARM Linux wrote:
> On Sun, Jan 08, 2012 at 08:49:53PM +0000, Mark Brown wrote:

> > That'd be extremely disappointing, especially given that there's some
> > bug fixes in there for updates going in this merge window without which
> > mainline is going to have problems on s3c64xx (mostly the GPIO stuff).

> Here we go again with sucky work practices.

> This sucky behaviour has been around for a long time, I've long since
> given up complaining about it as it's exactly like talking to a bloody
> brick wall.  People just continue mixing development and fixes together.

Actually in this case the issue is slightly different - the fixes are
mostly fixes for issues introduced by other development going in during
this merge window, what's gone wrong is that they've been applied to a
different branch to that which had the problem.  Still an issue of
course, just a different one.

That said there's also an issue if pure development gets delayed - it
makes it harder to do further work based on top of the work that got
delayed, especially if any cross tree issues come into play.

> Note: Linus _has_ taken a copy of linux-next (read the 3.2 release email),
> and _is_ checking whether development stuff was in linux-next prior to
> the merge window opening.  It would be very unwise to send new development
> which wasn't already there.

That's not an issue here, all the stuff that's being discussed is in
-next but not sent to the arm-soc tree.
Russell King - ARM Linux - Jan. 10, 2012, 9:06 a.m.
On Mon, Jan 09, 2012 at 08:11:54AM -0800, Mark Brown wrote:
> On Mon, Jan 09, 2012 at 03:56:34PM +0000, Arnd Bergmann wrote:
> 
> > Of course we will take all bug fixes. Just rebase the rest on top of 3.3-rc1
> > and we can take it right away for 3.4.
> 
> I've sent a pull request earlier in the thread for the main ones I'm
> aware of (which are mostly fixes for things introduced in this cycle) -
> the others I'm aware of are all specific to Cragganmore and given that
> we can't get any of the features for that merged the fixes aren't going
> to have any practical effect until we can manage to get the feature
> stuff merged so it's not really worth the effort.
> 
> This really is very disappointing.

No it isn't.

What is really disappointing is the lack of responsive maintainers for the
Samsung stuff.  It took _two_ bloody months to get the Samsung platforms
sorted for the restart changes in spite of reminding, and a last minute
rush over the course of a couple of days (one _in_ the merge window) to
get it properly merged into my tree.

The only reason something happened was because I stuck a #error into
the Samsung code in linux-next and people started reporting that Samsung
had broken.

This is not the worst of it - Nicolas took _three_ months to get a response
from the shmobile maintainers.  I never got a response from the shmobile
maintainers for the restart changes - so congratulations to the shmobile
maintainers, shmobile is now broken.

The alternative was basically Samsung ending up like shmobile is today.
Maybe that's what should have happened to save folk like Arnd such a
horrible job now.

So, I support Arnd's view: the Samsung stuff is just too late.  Even the
restart updates (which is what has caused this) were too late.  Anything
which causes new merge conflicts in the Samsung code is not acceptable at
this point, even if it's a 'fix' patch.  We've wasted far too much time
trying to get Samsung stuff sorted far too late in the cycle.

Let this be an object lesson in what happens if you leave stuff until the
last minute.
Mark Brown - Jan. 10, 2012, 6:31 p.m.
On Tue, Jan 10, 2012 at 09:06:35AM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 09, 2012 at 08:11:54AM -0800, Mark Brown wrote:

> > This really is very disappointing.

> No it isn't.

I think we're talking at cross purposes here - I'm saying that this
whole situation is disappointing, not a specific decision.

> What is really disappointing is the lack of responsive maintainers for the
> Samsung stuff.  It took _two_ bloody months to get the Samsung platforms

This is pretty much what I'm saying is disappointing - in this case the
whole fact that we're not managing to get stuff actually merged.  It's
very frustrating that we're ending up in a situation where getting
things applied to the maintainer's tree and into -next (which is usually
the end of what you need to do as a patch submitter) isn't enough to
actually get the changes pushed upstream.

> The only reason something happened was because I stuck a #error into
> the Samsung code in linux-next and people started reporting that Samsung
> had broken.

Yeah, me included.  Like I said I'd probably have sent a fix if I'd been
able to figure out what the changes the error referred to were.

> The alternative was basically Samsung ending up like shmobile is today.
> Maybe that's what should have happened to save folk like Arnd such a
> horrible job now.

So, is there anything that people like me who are contributing to rather
than maintaining things can do to help here beyond chasing maintainers?

Generally my process is roughly to monitor what goes into -next and
chase people if things don't make it in there but that's not working
well here as things are appearing in -next.
Nicolas Pitre - Jan. 10, 2012, 6:44 p.m.
On Tue, 10 Jan 2012, Mark Brown wrote:

> So, is there anything that people like me who are contributing to rather
> than maintaining things can do to help here beyond chasing maintainers?
> 
> Generally my process is roughly to monitor what goes into -next and
> chase people if things don't make it in there but that's not working
> well here as things are appearing in -next.

Maybe the Samsung maintainer(s) should target early merge into the 
arm-soc tree instead of going straight to linux-next only.  The former 
ends up in the later anyway.


Nicolas
Mark Brown - Jan. 10, 2012, 6:46 p.m.
On Tue, Jan 10, 2012 at 01:44:54PM -0500, Nicolas Pitre wrote:
> On Tue, 10 Jan 2012, Mark Brown wrote:

> > So, is there anything that people like me who are contributing to rather
> > than maintaining things can do to help here beyond chasing maintainers?

> Maybe the Samsung maintainer(s) should target early merge into the 
> arm-soc tree instead of going straight to linux-next only.  The former 
> ends up in the later anyway.

That sounds like it'd be helpful overall but it's something that has to
be sorted out at the maintainer level.  I'm guessing there's not really
much that contributors can do here?
Nicolas Pitre - Jan. 10, 2012, 7 p.m.
On Tue, 10 Jan 2012, Mark Brown wrote:

> On Tue, Jan 10, 2012 at 01:44:54PM -0500, Nicolas Pitre wrote:
> > On Tue, 10 Jan 2012, Mark Brown wrote:
> 
> > > So, is there anything that people like me who are contributing to rather
> > > than maintaining things can do to help here beyond chasing maintainers?
> 
> > Maybe the Samsung maintainer(s) should target early merge into the 
> > arm-soc tree instead of going straight to linux-next only.  The former 
> > ends up in the later anyway.
> 
> That sounds like it'd be helpful overall but it's something that has to
> be sorted out at the maintainer level.  I'm guessing there's not really
> much that contributors can do here?

Maybe if enough contributor pressure builds up something will change...


Nicolas
Arnd Bergmann - Jan. 10, 2012, 8:13 p.m.
On Tuesday 10 January 2012, Mark Brown wrote:
> 
> On Tue, Jan 10, 2012 at 01:44:54PM -0500, Nicolas Pitre wrote:
> > On Tue, 10 Jan 2012, Mark Brown wrote:
> 
> > > So, is there anything that people like me who are contributing to rather
> > > than maintaining things can do to help here beyond chasing maintainers?
> 
> > Maybe the Samsung maintainer(s) should target early merge into the 
> > arm-soc tree instead of going straight to linux-next only.  The former 
> > ends up in the later anyway.
> 
> That sounds like it'd be helpful overall but it's something that has to
> be sorted out at the maintainer level.  I'm guessing there's not really
> much that contributors can do here?

I think you did everything as good as you could, we just need to routinely
call for everyone to submit stuff in time. A number of maintainers sent stuff
after Christmas (which I expected to start the merge window) and were mostly
lucky because Linus gave us an extra 10 days to sort things out.

The most reliable way improve things is pressure from upstream. We used to
have a lot of problems with omap until Linus complained loudly and the omap
merges are working completely flawless now process-wise. In the last few
releases I pushed back on substandard at91 patches and that also turned out
really well for 3.3. This time, the samsung and pxa patches were sticking
out as being worse than the others, so that's where the pushback went and
I'm sure it will work better in the future. PXA made it in in the
end, samsung also did for the most part but not entirely and you were
unfortunate to be the contributor of the patches that missed out.

Note that we're also constantly raising the bar with our expectations here,
and we have to, in order to keep up with increasing complexity and
increasing numbers of patches getting submitted. I think overall we're
doing fine, and occasionally letting good patches get delayed by one
release is the price we have to pay, even when it hurts an individual
contributor.

	Arnd
Mark Brown - Jan. 10, 2012, 10:37 p.m.
On Tue, Jan 10, 2012 at 08:13:54PM +0000, Arnd Bergmann wrote:
> On Tuesday 10 January 2012, Mark Brown wrote:

> > That sounds like it'd be helpful overall but it's something that has to
> > be sorted out at the maintainer level.  I'm guessing there's not really
> > much that contributors can do here?

> I think you did everything as good as you could, we just need to routinely
> call for everyone to submit stuff in time. A number of maintainers sent stuff
> after Christmas (which I expected to start the merge window) and were mostly
> lucky because Linus gave us an extra 10 days to sort things out.

I guess it would also be useful to have some way to compare what's in
-next with what's in the arm-soc tree and chase people if that diff gets
big.  I do also wonder if it's worth letting people push stuff to you
more aggressively - right now you seem to be asking people to batch
things up and I wonder if that's making it a it easier for things to end
up dropping on the floor if a time based routine isn't working well for
people.

> end, samsung also did for the most part but not entirely and you were
> unfortunate to be the contributor of the patches that missed out.

It's not just me, I'm just vocal and perhaps more to the point spend a
reasonable amount of time chasing stuff into various trees so want to
figure out if I need to change what I'm doing with that.
Olof Johansson - Jan. 11, 2012, 12:11 a.m.
On Tue, Jan 10, 2012 at 2:37 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Tue, Jan 10, 2012 at 08:13:54PM +0000, Arnd Bergmann wrote:
>> On Tuesday 10 January 2012, Mark Brown wrote:
>
>> > That sounds like it'd be helpful overall but it's something that has to
>> > be sorted out at the maintainer level.  I'm guessing there's not really
>> > much that contributors can do here?
>
>> I think you did everything as good as you could, we just need to routinely
>> call for everyone to submit stuff in time. A number of maintainers sent stuff
>> after Christmas (which I expected to start the merge window) and were mostly
>> lucky because Linus gave us an extra 10 days to sort things out.
>
> I guess it would also be useful to have some way to compare what's in
> -next with what's in the arm-soc tree and chase people if that diff gets
> big.  I do also wonder if it's worth letting people push stuff to you
> more aggressively - right now you seem to be asking people to batch
> things up and I wonder if that's making it a it easier for things to end
> up dropping on the floor if a time based routine isn't working well for
> people.

I actually did just this today based on this discussion, and I'll do
it through the next staging cycle to keep a track of the "arm backlog"
of how much is sitting in maintainer trees vs what has already been
merged into Russell's tree or arm-soc. We can include these stats in
next rounds "last call for patches" email to help catch forgotten
branches.

I merged rmk's for-next branch with the arm-soc one, merged that on
top of mainline and diffed arch/arm with what is in linux-next.

Right now, plus or minus some sloppy merge conflict resolutions on my
part, the statistics are:

git diff --stat next/master -- arch/arm
[..]
 113 files changed, 670 insertions(+), 810 deletions(-)

(this diffstat does not include late/* branches since they got
included in the arm-soc side of the diff)

Most of these are rightfully still there; some changes are going
through other trees such as some PCI changes, ASoC, PM, a few fixes
that haven't been sent up to arm-soc yet, etc.  A couple of patches
seem to have been queued in for-3.4 branches a bit early (Stephen
doesn't generally want people to start queueing new stuff until the
merge window is over), but that's just a couple of them.

So, it looks like there's no major backlog left for any specific vendor subtree.

>> end, samsung also did for the most part but not entirely and you were
>> unfortunate to be the contributor of the patches that missed out.
>
> It's not just me, I'm just vocal and perhaps more to the point spend a
> reasonable amount of time chasing stuff into various trees so want to
> figure out if I need to change what I'm doing with that.

What I would do myself is that if I hadn't seen the patches land in
the topmost staging tree by -rc6 or -rc7, I would ping the owner of
the tree that the patches are sitting in to make sure they go up.
Hopefully this kind of thing will be a rare scenario.


-Olof
Kukjin Kim - Jan. 11, 2012, 6:20 a.m.
Russell King - ARM Linux wrote:
> 
> On Mon, Jan 09, 2012 at 08:11:54AM -0800, Mark Brown wrote:

[...]

> > This really is very disappointing.
> 
> No it isn't.
> 
> What is really disappointing is the lack of responsive maintainers for the
> Samsung stuff.  It took _two_ bloody months to get the Samsung platforms
> sorted for the restart changes in spite of reminding, and a last minute
> rush over the course of a couple of days (one _in_ the merge window) to
> get it properly merged into my tree.
> 
Yeah, I had to do earlier and it's true that many conflicts caused from my
late ARM restart working for Samsung stuff.

[...]

> So, I support Arnd's view: the Samsung stuff is just too late.  Even the
> restart updates (which is what has caused this) were too late.  Anything
> which causes new merge conflicts in the Samsung code is not acceptable at
> this point, even if it's a 'fix' patch.  We've wasted far too much time
> trying to get Samsung stuff sorted far too late in the cycle.
> 
> Let this be an object lesson in what happens if you leave stuff until the
> last minute.

I will do more carefully next time and of course not too late.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
Kukjin Kim - Jan. 11, 2012, 6:39 a.m.
Olof Johansson wrote:
> 

[...]

> What I would do myself is that if I hadn't seen the patches land in
> the topmost staging tree by -rc6 or -rc7, I would ping the owner of
> the tree that the patches are sitting in to make sure they go up.

Would be helpful to us.

> Hopefully this kind of thing will be a rare scenario.
> 
Yes, and Samsung's topic branch will be sent to arm-soc as soon as possible
when it's ready from me.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
Arnd Bergmann - Jan. 11, 2012, 4:19 p.m.
On Tuesday 10 January 2012, Mark Brown wrote:

> I do also wonder if it's worth letting people push stuff to you
> more aggressively - right now you seem to be asking people to batch
> things up and I wonder if that's making it a it easier for things to end
> up dropping on the floor if a time based routine isn't working well for
> people.

I really wish people would push stuff into arm-soc more aggressively,
and I certainly didn't want to give the impression that maintainers
should let their stuff sit in linux-next before sending it to us.

It's absolutely fine to send multiple updates per branch for arm-soc
as stuff comes in, as long as we can keep track of the dependencies
and we don't have to rebase the stuff that's already merged.

I would also prefer if people stopped having their own trees included
in next, but I know that I'm sometimes slow to pick up patches that
were submitted to arm-soc and that it helps people if they can get
earlier integration testing that way. Hopefully we're also getting
better at dealing with pull requests quickly so that there is no
need for the other tree in linux-next any more.

	Arnd
Olof Johansson - Jan. 11, 2012, 4:50 p.m.
Hi,

On Wed, Jan 11, 2012 at 8:19 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 10 January 2012, Mark Brown wrote:
>
>> I do also wonder if it's worth letting people push stuff to you
>> more aggressively - right now you seem to be asking people to batch
>> things up and I wonder if that's making it a it easier for things to end
>> up dropping on the floor if a time based routine isn't working well for
>> people.
>
> I really wish people would push stuff into arm-soc more aggressively,
> and I certainly didn't want to give the impression that maintainers
> should let their stuff sit in linux-next before sending it to us.
>
> It's absolutely fine to send multiple updates per branch for arm-soc
> as stuff comes in, as long as we can keep track of the dependencies
> and we don't have to rebase the stuff that's already merged.
>
> I would also prefer if people stopped having their own trees included
> in next, but I know that I'm sometimes slow to pick up patches that
> were submitted to arm-soc and that it helps people if they can get
> earlier integration testing that way. Hopefully we're also getting
> better at dealing with pull requests quickly so that there is no
> need for the other tree in linux-next any more.

There's value in having the vendor trees in linux-next, and the main
reason is that it's actually possible for us to see what the backlog
is. As mentioned yesterday, I'll try to diff rmk+arm-soc trees with
linux-next this upcoming staging cycle to keep track of how much is
sitting in vendor trees yet. The alternative is that they sit in a
repo somewhere that we don't even know about yet.

I also have to admit, as tegra maintainer, that it is convenient to
have my tree in linux-next, and have things show up in linux-next as
soon as I pick it up, and then send arm-soc pull requests about once a
week or so. While we should reduce latency to pull into arm-soc,
getting pull requests daily will be a bit on the heavy side.


-Olof
Mark Brown - Jan. 11, 2012, 5:29 p.m.
On Wed, Jan 11, 2012 at 08:50:54AM -0800, Olof Johansson wrote:
> On Wed, Jan 11, 2012 at 8:19 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> > I would also prefer if people stopped having their own trees included
> > in next, but I know that I'm sometimes slow to pick up patches that

> I also have to admit, as tegra maintainer, that it is convenient to
> have my tree in linux-next, and have things show up in linux-next as
> soon as I pick it up, and then send arm-soc pull requests about once a
> week or so. While we should reduce latency to pull into arm-soc,
> getting pull requests daily will be a bit on the heavy side.

Plus it also means that if there are problems you can resolve it
directly rather than having to get the fixes included in a separate tree
which helps cut down on latencies.