mbox

[GIT,PULL] ux500-core for 3.2

Message ID CACRpkdZofKjOrPFWNR-2D0LWx3NGMiLwyhf7gAVdvBGvQHqJLQ@mail.gmail.com
State New
Headers show

Pull-request

git://git.linaro.org/people/triad/linux-stericsson.git for-arnd

Message

Linus Walleij Sept. 20, 2011, 7:53 a.m. UTC
Hi Arnd,

could you please pull:

git://git.linaro.org/people/triad/linux-stericsson.git for-arnd

to the ARM SoC tree (ux500 branch or however you prefer to handle it)?
They have all been reviewed on the ARM list recently and are mostly
minor fixes and Lee Jones nice cleanup patch.

I might be stacking up more but this is a good start.

The following changes since commit c6a389f123b9f68d605bb7e0f9b32ec1e3e14132:

  Linux 3.1-rc4 (2011-08-28 21:16:01 -0700)

are available in the git repository at:
  git://git.linaro.org/people/triad/linux-stericsson.git for-arnd

Barry Song (1):
      ARM: mach-ux500: add explicit cpu_relax() for busy wait loop

Fredrik Svensson (1):
      mach-ux500: remove pull-pinconfig and add SPI2

Lee Jones (1):
      mach-ux500: remove most of the ugly machine_is_*() calls

Linus Walleij (2):
      mach-ux500: factor out l2x0 handling code
      mach-ux500: unlock I&D l2x0 caches before init

srinidhi kasagar (1):
      mach-ux500: enable fix for ARM errata 754322

 arch/arm/mach-ux500/Kconfig                   |    1 +
 arch/arm/mach-ux500/Makefile                  |    1 +
 arch/arm/mach-ux500/board-mop500-pins.c       |   34 ++++--
 arch/arm/mach-ux500/board-mop500-sdi.c        |   52 ++++++---
 arch/arm/mach-ux500/board-mop500.c            |   78 +++++++++++---
 arch/arm/mach-ux500/board-mop500.h            |    3 +
 arch/arm/mach-ux500/cache-l2x0.c              |   95 +++++++++++++++++
 arch/arm/mach-ux500/cpu.c                     |   69 ------------
 arch/arm/mach-ux500/include/mach/uncompress.h |   10 +--
 arch/arm/mach-ux500/pins-db8500.h             |  142 +++++++++++++------------
 arch/arm/plat-nomadik/include/plat/pincfg.h   |    5 -
 11 files changed, 294 insertions(+), 196 deletions(-)
 create mode 100644 arch/arm/mach-ux500/cache-l2x0.c

Comments

Nicolas Pitre Sept. 20, 2011, 6:06 p.m. UTC | #1
On Tue, 20 Sep 2011, Linus Walleij wrote:

> Hi Arnd,
> 
> could you please pull:
> 
> git://git.linaro.org/people/triad/linux-stericsson.git for-arnd

[...]

> Barry Song (1):
>       ARM: mach-ux500: add explicit cpu_relax() for busy wait loop
> 
> Fredrik Svensson (1):
>       mach-ux500: remove pull-pinconfig and add SPI2
> 
> Lee Jones (1):
>       mach-ux500: remove most of the ugly machine_is_*() calls
> 
> Linus Walleij (2):
>       mach-ux500: factor out l2x0 handling code
>       mach-ux500: unlock I&D l2x0 caches before init
> 
> srinidhi kasagar (1):
>       mach-ux500: enable fix for ARM errata 754322

Please try to include the "ARM: " prefix (or ask the people you merge 
from) in all the patch titles.  Once in mainline with all the other 
stuff this helps others making sense of the log summaries.

no need to redo this lot though.


Nicolas
Arnd Bergmann Sept. 20, 2011, 8:48 p.m. UTC | #2
On Tuesday 20 September 2011, Linus Walleij wrote:
> could you please pull:
> 
> git://git.linaro.org/people/triad/linux-stericsson.git for-arnd
> 
> to the ARM SoC tree (ux500 branch or however you prefer to handle it)?
> They have all been reviewed on the ARM list recently and are mostly
> minor fixes and Lee Jones nice cleanup patch.

I would really like to see this split into logical branches, even
if there are just a few patches for each of them. It looks like
the series currently contains bug fixes and cleanups mixed together,
which makes it hard to backport fixes and for me to aggregate patches
across soc families by category.

It's also not clear if the two bug fix patches should be applied
to 3.1 and -stable as well as 3.2. My feeling is that they should.
If you want bug fixes to be backported, please add a 'Cc: stable@kernel.org'
line after your Signed-off-by. If not, add an explanation to the
pull request why they are not relevant for backporting.

I've applied the first four patches to the stericsson/cleanup
and next/cleanup branches now, since these look like they are
purely cleanup branches without noticeable code changes.

Please submit the two bug fixes again, rebased to an -rc release.
there is a dependency on one of the cleanup patches. Don't worry
about that, I'll take care of resolving this conflict after you
have rebased the bug fix to the mainline kernel.

Thanks,

	Arnd
Linus Walleij Sept. 22, 2011, 11:23 a.m. UTC | #3
On Tue, Sep 20, 2011 at 10:48 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 20 September 2011, Linus Walleij wrote:
>> to the ARM SoC tree (ux500 branch or however you prefer to handle it)?
>> They have all been reviewed on the ARM list recently and are mostly
>> minor fixes and Lee Jones nice cleanup patch.
>
> I would really like to see this split into logical branches, even
> if there are just a few patches for each of them.

No problem. So the preferred scheme is to have three topics
for a SoC: fixes, cleanup and "new stuff" or something like that?

> It's also not clear if the two bug fix patches should be applied
> to 3.1 and -stable as well as 3.2. My feeling is that they should.

Depends. For Srinidhi's
"mach-ux500: enable fix for ARM errata 754322"
yes, definately.

For:
"mach-ux500: unlock I&D l2x0 caches before init"
it's a performance regression, nothing like a crash or so.

(I guess you're referring to these two?)

> If you want bug fixes to be backported, please add a 'Cc: stable@kernel.org'
> line after your Signed-off-by. If not, add an explanation to the
> pull request why they are not relevant for backporting.
(...)
> Please submit the two bug fixes again, rebased to an -rc release.

I'll fix.

Since it's just two patches I guess you can just pick these
two in plaintext? But I can make a pull request if you prefer...

Thanks,
Linus Walleij
Arnd Bergmann Sept. 22, 2011, 11:35 a.m. UTC | #4
On Thursday 22 September 2011, Linus Walleij wrote:
> On Tue, Sep 20, 2011 at 10:48 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 20 September 2011, Linus Walleij wrote:
> >> to the ARM SoC tree (ux500 branch or however you prefer to handle it)?
> >> They have all been reviewed on the ARM list recently and are mostly
> >> minor fixes and Lee Jones nice cleanup patch.
> >
> > I would really like to see this split into logical branches, even
> > if there are just a few patches for each of them.
> 
> No problem. So the preferred scheme is to have three topics
> for a SoC: fixes, cleanup and "new stuff" or something like that?

Roughly, yes.  For new stuff, you can have multiple sub-categories,
depending on how many patches you have.

Some platforms have separated board-specific updates from overall
platform changes, which I find very useful.

Also, if you add (or remove) a major feature, that can be a branch
by itself for this feature.

> > It's also not clear if the two bug fix patches should be applied
> > to 3.1 and -stable as well as 3.2. My feeling is that they should.
> 
> Depends. For Srinidhi's
> "mach-ux500: enable fix for ARM errata 754322"
> yes, definately.
> 
> For:
> "mach-ux500: unlock I&D l2x0 caches before init"
> it's a performance regression, nothing like a crash or so.
> 
> (I guess you're referring to these two?)

Right, thanks for the explanation. If the latter is a regression,
I'd still treat it as a bug fix. For a general (non-regression)
performance improvement, I'd put it into a development branch.

> > If you want bug fixes to be backported, please add a 'Cc: stable@kernel.org'
> > line after your Signed-off-by. If not, add an explanation to the
> > pull request why they are not relevant for backporting.
> (...)
> > Please submit the two bug fixes again, rebased to an -rc release.
> 
> I'll fix.
> 
> Since it's just two patches I guess you can just pick these
> two in plaintext? But I can make a pull request if you prefer...

In general, I prefer pull requests, but if you have no other patches
for 3.2, I can just cherry-pick them from the branch I already pulled.
I would put the first patch into fixes for 3.1 and mark it as 'Cc:stable'
and the other one into fixes for 3.2 then.

	Arnd