* [GIT PULL] omap fixes for v3.2-rc2
@ 2011-11-19 19:44 Tony Lindgren
2011-11-23 21:15 ` Arnd Bergmann
0 siblings, 1 reply; 6+ messages in thread
From: Tony Lindgren @ 2011-11-19 19:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
Please pull omap fixes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes
Most of this pull request are fixes needed by Tomi for the
display driver clocking.
Regards,
Tony
The following changes since commit 6aaf05f472c97ebceff47d9eef464574f1a55727:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes
Archit Taneja (1):
ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader
Felipe Balbi (1):
arm: omap: smartreflex: fix IRQ handling bug
Govindraj.R (1):
ARM: OMAP2+: Fix Compilation error when omap_l3_noc built as module
Kevin Hilman (2):
ARM: OMAP3: CPUidle: include <linux/export.h>
ARM: OMAP: PM: only register TWL with voltage layer when device is present
Ming Lei (1):
arm: omap2: select ARM_AMBA if OMAP3_EMU is defined
Thomas Weber (1):
ARM: OMAP2+: Remove empty io.h
Tomi Valkeinen (9):
ARM: OMAP2xxx: HWMOD: Fix DSS reset
ARM: OMAP2xxx: HWMOD: fix DSS clock data
ARM: OMAP3: HWMOD: Fix DSS reset
ARM: OMAP3: HWMOD: fix DSS clock data
ARM: OMAP4: HWMOD: remove extra clocks
ARM: OMAP4: HWMOD: Add HWMOD_CONTROL_OPT_CLKS_IN_RESET for dss_core
ARM: OMAP4: HWMOD: fix DSS clock data
ARM: OMAP2/3: HWMOD: Add SYSS_HAS_RESET_STATUS for dss
ARM: OMAP: HWMOD: Unify DSS resets for OMAPs
Tony Lindgren (6):
ARM: OMAP: Fix map_io for Amstrad E3
ARM: OMAP: Fix dpll_data compile error when omap2 only is selected
ARM: OMAP: Fix reprogramming of dpll1 rate
Merge branch 'for_3.2-rc/hwmod-fixes' of git://gitorious.org/omap-pm/linux into fixes
Merge branch 'for_3.2/fixes/pm' of git://git.kernel.org/.../khilman/linux-omap-pm into fixes
Merge branch 'hwmod_dss_fixes_3.2rc' of git://git.pwsan.com/linux-2.6 into fixes
sricharan (1):
ARM: OMAP: hwmod: Fix the addr space, irq, dma count APIs
arch/arm/configs/omap1_defconfig | 1 -
arch/arm/mach-omap1/Kconfig | 8 -
arch/arm/mach-omap1/board-ams-delta.c | 10 +-
arch/arm/mach-omap1/clock.h | 3 +-
arch/arm/mach-omap1/clock_data.c | 53 ++++---
arch/arm/mach-omap1/devices.c | 3 +
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/Makefile | 5 +-
arch/arm/mach-omap2/cpuidle34xx.c | 1 +
arch/arm/mach-omap2/display.c | 159 ++++++++++++++++++++
arch/arm/mach-omap2/display.h | 29 ++++
arch/arm/mach-omap2/omap_hwmod.c | 6 +-
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 17 ++-
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 17 ++-
.../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c | 5 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 37 ++++-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 24 ++--
arch/arm/mach-omap2/omap_hwmod_common_data.c | 4 +
arch/arm/mach-omap2/omap_hwmod_common_data.h | 4 +
arch/arm/mach-omap2/omap_l3_noc.c | 2 +-
arch/arm/mach-omap2/pm.c | 6 +-
arch/arm/mach-omap2/smartreflex.c | 2 +-
arch/arm/mach-omap2/twl-common.c | 11 ++
arch/arm/mach-omap2/twl-common.h | 3 +
arch/arm/plat-omap/include/plat/clock.h | 2 +-
arch/arm/plat-omap/include/plat/common.h | 3 +
include/video/omapdss.h | 7 -
27 files changed, 346 insertions(+), 77 deletions(-)
create mode 100644 arch/arm/mach-omap2/display.h
delete mode 100644 arch/arm/mach-omap2/io.h
^ permalink raw reply [flat|nested] 6+ messages in thread
* [GIT PULL] omap fixes for v3.2-rc2
2011-11-19 19:44 [GIT PULL] omap fixes for v3.2-rc2 Tony Lindgren
@ 2011-11-23 21:15 ` Arnd Bergmann
2011-11-23 22:03 ` Tony Lindgren
0 siblings, 1 reply; 6+ messages in thread
From: Arnd Bergmann @ 2011-11-23 21:15 UTC (permalink / raw)
To: linux-arm-kernel
On Saturday 19 November 2011, Tony Lindgren wrote:
> Please pull omap fixes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes
>
> Most of this pull request are fixes needed by Tomi for the
> display driver clocking.
>
Hi Tony,
Sorry for the delay on my side, I've only today looked at this series.
The patches all look ok, as far as I can tell, but please rebase
the series to make it easier to see what is going on:
* At least one of the sub-branches is based on a random commit on
Linus' tree. Please always base patches on an -rc for consistency!
* Out of the 20 patches, not one is marked for 'stable' backports.
I really want to make sure this time that all long-standing bugs
get fixed in stable releases, so please go through the list and
add 'Cc: stable at kernel.org' to the ones you want to have backported.
If all patches are actually addressing regressions, just tell me
in the introductory mail next time.
* Since a lot of patches address the dss, it would be nice to have
a separate pull request for those. It's not really important, but
I feel that it's easier to review stuff that is less mixed and
splitting them out should be easy if you rebase the series anyway.
Thanks for your patience,
Arnd
^ permalink raw reply [flat|nested] 6+ messages in thread
* [GIT PULL] omap fixes for v3.2-rc2
2011-11-23 21:15 ` Arnd Bergmann
@ 2011-11-23 22:03 ` Tony Lindgren
2011-11-23 22:22 ` Arnd Bergmann
0 siblings, 1 reply; 6+ messages in thread
From: Tony Lindgren @ 2011-11-23 22:03 UTC (permalink / raw)
To: linux-arm-kernel
* Arnd Bergmann <arnd@arndb.de> [111123 12:40]:
> On Saturday 19 November 2011, Tony Lindgren wrote:
> > Please pull omap fixes from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes
> >
> > Most of this pull request are fixes needed by Tomi for the
> > display driver clocking.
> >
>
> Hi Tony,
>
> Sorry for the delay on my side, I've only today looked at this series.
> The patches all look ok, as far as I can tell, but please rebase
> the series to make it easier to see what is going on:
>
> * At least one of the sub-branches is based on a random commit on
> Linus' tree. Please always base patches on an -rc for consistency!
Yes sorry I made the same comment earlier to Benoit. That one patch
is certainly based on a random commit.. Will cherry pick that one.
The earlier patches are based on the earlier fixes (while waiting
for them to get merged). So that's certainly not a random commit.
Or at least was not at that time :) I can rebase those too anyways
now that the earlier fixes are merged.
> * Out of the 20 patches, not one is marked for 'stable' backports.
> I really want to make sure this time that all long-standing bugs
> get fixed in stable releases, so please go through the list and
> add 'Cc: stable at kernel.org' to the ones you want to have backported.
> If all patches are actually addressing regressions, just tell me
> in the introductory mail next time.
It's mostly regressions and fixes on new features merged during
the merge window. But looks like there's at least one patch that
might make sense for stable too, will check them all.
> * Since a lot of patches address the dss, it would be nice to have
> a separate pull request for those. It's not really important, but
> I feel that it's easier to review stuff that is less mixed and
> splitting them out should be easy if you rebase the series anyway.
OK will place those into fixes-dss branch.
Cheers,
Tony
^ permalink raw reply [flat|nested] 6+ messages in thread
* [GIT PULL] omap fixes for v3.2-rc2
2011-11-23 22:03 ` Tony Lindgren
@ 2011-11-23 22:22 ` Arnd Bergmann
2011-11-23 23:11 ` Tony Lindgren
0 siblings, 1 reply; 6+ messages in thread
From: Arnd Bergmann @ 2011-11-23 22:22 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 23 November 2011 14:03:58 Tony Lindgren wrote:
>
> The earlier patches are based on the earlier fixes (while waiting
> for them to get merged). So that's certainly not a random commit.
> Or at least was not at that time I can rebase those too anyways
> now that the earlier fixes are merged.
No need to do that unless you are rebasing them anyway. IMHO
it's fine if you have all your bug fixes in one branch based
on the previous bug fixes you sent, but it's of course also
fine to start a fresh branch for each pull request.
In general, I would recommend not rebasing when you have the
choice, because that means your patches are not as well tested.
Arnd
^ permalink raw reply [flat|nested] 6+ messages in thread
* [GIT PULL] omap fixes for v3.2-rc2
2011-11-23 22:22 ` Arnd Bergmann
@ 2011-11-23 23:11 ` Tony Lindgren
2011-11-24 0:42 ` Tony Lindgren
0 siblings, 1 reply; 6+ messages in thread
From: Tony Lindgren @ 2011-11-23 23:11 UTC (permalink / raw)
To: linux-arm-kernel
* Arnd Bergmann <arnd@arndb.de> [111123 13:47]:
> On Wednesday 23 November 2011 14:03:58 Tony Lindgren wrote:
> >
> > The earlier patches are based on the earlier fixes (while waiting
> > for them to get merged). So that's certainly not a random commit.
> > Or at least was not at that time I can rebase those too anyways
> > now that the earlier fixes are merged.
>
> No need to do that unless you are rebasing them anyway. IMHO
> it's fine if you have all your bug fixes in one branch based
> on the previous bug fixes you sent, but it's of course also
> fine to start a fresh branch for each pull request.
>
> In general, I would recommend not rebasing when you have the
> choice, because that means your patches are not as well tested.
Well I can keep only four of them because of the pull on a random
commit. Looks like four of them apply to v3.1, will send them
off to stable at vger.kernel.org and send you two new pull requests.
Tony
^ permalink raw reply [flat|nested] 6+ messages in thread
* [GIT PULL] omap fixes for v3.2-rc2
2011-11-23 23:11 ` Tony Lindgren
@ 2011-11-24 0:42 ` Tony Lindgren
0 siblings, 0 replies; 6+ messages in thread
From: Tony Lindgren @ 2011-11-24 0:42 UTC (permalink / raw)
To: linux-arm-kernel
* Tony Lindgren <tony@atomide.com> [111123 14:36]:
> * Arnd Bergmann <arnd@arndb.de> [111123 13:47]:
> > On Wednesday 23 November 2011 14:03:58 Tony Lindgren wrote:
> > >
> > > The earlier patches are based on the earlier fixes (while waiting
> > > for them to get merged). So that's certainly not a random commit.
> > > Or at least was not at that time I can rebase those too anyways
> > > now that the earlier fixes are merged.
> >
> > No need to do that unless you are rebasing them anyway. IMHO
> > it's fine if you have all your bug fixes in one branch based
> > on the previous bug fixes you sent, but it's of course also
> > fine to start a fresh branch for each pull request.
> >
> > In general, I would recommend not rebasing when you have the
> > choice, because that means your patches are not as well tested.
>
> Well I can keep only four of them because of the pull on a random
> commit. Looks like four of them apply to v3.1, will send them
> off to stable at vger.kernel.org and send you two new pull requests.
FYI, forgot to mention that I verified that merging in the two pull
requests produces the same end result as the original pull request.
Tony
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-11-24 0:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-11-19 19:44 [GIT PULL] omap fixes for v3.2-rc2 Tony Lindgren
2011-11-23 21:15 ` Arnd Bergmann
2011-11-23 22:03 ` Tony Lindgren
2011-11-23 22:22 ` Arnd Bergmann
2011-11-23 23:11 ` Tony Lindgren
2011-11-24 0:42 ` Tony Lindgren
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).