From: Tomi Valkeinen <hidden> Date: 2011-01-07 12:41:43
Hello Paul,
Here are some OMAP display changes for .38. I hope they are not too
late, but the holidays messed up my schedules a bit.
I made two branches, as I'm not sure which is better:
for-paul-38 - This one is the original non-rebased branch. This causes a
trivial conflict with fbdev/master in drivers/video/omap2/vram.c (SZ_2M
is the right one), and also it contains a patch (memblock: fix
memblock_is_region_memory()) which is not yet in mainline, but is in
Andrew Morton's tree.
for-paul-38-rebased - The above branch rebased on top of v2.6.37, and
the memblock commit removed.
Which one you prefer? Or is there some other way I should handle this?
I could merge v2.6.37 to my branch, which would remove the conflict, but
that would still leave the memblock patch. I guess the patch is going in
soon, but as it's not in my area, I don't feel it's right to get it in
via my patch set. Alternatively I could wait until the patch is in
Linus' tree, but that could make it tight to be in time for the merge
window.
Tomi
The following changes since commit c8ddb2713c624f432fa5fe3c7ecffcdda46ea0d4:
Linux 2.6.37-rc1 (2010-11-01 07:54:12 -0400)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git for-paul-38
Archit Taneja (5):
OMAP: DSS2: Fix: Read correct bit in dispc_enable_alpha_blending()
OMAP: DSS2: Clean up DISPC color mode validation checks
OMAP: DSS2: Add dss_features for omap4 and overlay manager related features
OMAP: DSS2: Use dss_features to handle DISPC bits removed on OMAP4
OMAP: DSS2: Fix build breaks for rfbi.c and dsi.c
Bryan Wu (4):
OMAP: DSS2: Add generic DPI panel display driver
OMAP: use generic DPI panel driver in board files
OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers
OMAP: DSS2: Add back authors of panel-generic.c based drivers
Erik Gilling (1):
OMAP: DSS2: Add NEC NL8048HL11-01B display panel
Kishore Y (2):
OMAP3: ZOOM2/3/3630SDP: Add display board file for OMAP3
OMAP3: Enable display on ZOOM2/3/3630SDP
Rajkumar N (1):
OMAP3630: DSS2: Enable Pre-Multiplied Alpha Support
Samreen (2):
OMAP3: DSS2: Split OMAP3 has feature for 3430 & 3630
OMAP: DSS2: OMAPFB: Add null pointer check
Sumit Semwal (5):
OMAP: DSS2: Represent DISPC register defines with channel as parameter
OMAP: DSS2: Introduce omap_channel argument to DISPC functions used by interface drivers
OMAP: DSS2: Change remaining DISPC functions for new omap_channel argument
OMAP: DSS2: LCD2 Channel Changes for DISPC
OMAP: DSS2: Introduce omap_channel as an omap_dss_device parameter, add new overlay manager.
Tomi Valkeinen (4):
memblock: fix memblock_is_region_memory()
OMAP: VRAM: improve VRAM error prints
OMAP: VRAM: Fix boot-time memory allocation
OMAP: DSS: Fix documentation regarding 'vram' kernel parameter
Documentation/arm/OMAP/DSS | 7 +-
arch/arm/mach-omap2/Makefile | 3 +
arch/arm/mach-omap2/board-3430sdp.c | 12 +-
arch/arm/mach-omap2/board-3630sdp.c | 1 +
arch/arm/mach-omap2/board-am3517evm.c | 23 +-
arch/arm/mach-omap2/board-cm-t35.c | 23 +-
arch/arm/mach-omap2/board-devkit8000.c | 26 +-
arch/arm/mach-omap2/board-igep0020.c | 12 +-
arch/arm/mach-omap2/board-omap3beagle.c | 12 +-
arch/arm/mach-omap2/board-omap3evm.c | 12 +-
arch/arm/mach-omap2/board-omap3stalker.c | 23 +-
arch/arm/mach-omap2/board-zoom-display.c | 168 +++++
arch/arm/mach-omap2/board-zoom-peripherals.c | 49 ++-
arch/arm/mach-omap2/board-zoom2.c | 1 +
arch/arm/mach-omap2/board-zoom3.c | 1 +
arch/arm/mach-omap2/include/mach/board-zoom.h | 3 +
arch/arm/plat-omap/include/plat/display.h | 9 +
.../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 ++
drivers/video/omap2/displays/Kconfig | 27 +-
drivers/video/omap2/displays/Makefile | 5 +-
drivers/video/omap2/displays/panel-generic-dpi.c | 365 +++++++++++
drivers/video/omap2/displays/panel-generic.c | 174 ------
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 325 ++++++++++
.../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 -----
.../video/omap2/displays/panel-toppoly-tdo35s.c | 164 -----
drivers/video/omap2/dss/dispc.c | 636 +++++++++++++-------
drivers/video/omap2/dss/dpi.c | 40 +-
drivers/video/omap2/dss/dsi.c | 27 +-
drivers/video/omap2/dss/dss.h | 35 +-
drivers/video/omap2/dss/dss_features.c | 66 ++-
drivers/video/omap2/dss/dss_features.h | 10 +-
drivers/video/omap2/dss/manager.c | 80 ++-
drivers/video/omap2/dss/overlay.c | 55 ++-
drivers/video/omap2/dss/rfbi.c | 20 +-
drivers/video/omap2/dss/sdi.c | 24 +-
drivers/video/omap2/omapfb/omapfb-main.c | 5 +-
drivers/video/omap2/vram.c | 17 +-
mm/memblock.c | 8 +-
38 files changed, 1776 insertions(+), 894 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-display.c
create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h
create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
delete mode 100644 drivers/video/omap2/displays/panel-generic.c
create mode 100644 drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
delete mode 100644 drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
delete mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c
From: Paul Mundt <hidden> Date: 2011-01-07 13:25:41
On Fri, Jan 07, 2011 at 02:41:43PM +0200, Tomi Valkeinen wrote:
Hello Paul,
Here are some OMAP display changes for .38. I hope they are not too
late, but the holidays messed up my schedules a bit.
No, no problem. I usually aim to do two merges per merge window on
average, one at the beginning and one nearer the end. There are often
many patches that have dependencies that are blocked while other trees
merge that get sent off when their dependencies have been met.
I made two branches, as I'm not sure which is better:
for-paul-38 - This one is the original non-rebased branch. This causes a
trivial conflict with fbdev/master in drivers/video/omap2/vram.c (SZ_2M
is the right one), and also it contains a patch (memblock: fix
memblock_is_region_memory()) which is not yet in mainline, but is in
Andrew Morton's tree.
for-paul-38-rebased - The above branch rebased on top of v2.6.37, and
the memblock commit removed.
Which one you prefer? Or is there some other way I should handle this?
I could merge v2.6.37 to my branch, which would remove the conflict, but
that would still leave the memblock patch. I guess the patch is going in
soon, but as it's not in my area, I don't feel it's right to get it in
via my patch set. Alternatively I could wait until the patch is in
Linus' tree, but that could make it tight to be in time for the merge
window.
Andrew usually patch-bombs near the end of the window, so it's generally
a good idea to have things settled before then. In this case if the patch
is already destined for mainline then I can just pull the rebased branch,
send that out, and then once -mm syncs up everything should be good to go
for -rc1.
Looking at the change in question, it's just a correctness fix and
doesn't impact the API from the driver point of view, so at least there
won't be build damage if they're out of sync for a couple of days
(although it may trigger some nasty surprises for anyone unlucky enough
to bisect in the middle).
In any event, unless you absolutely need the change to be upstream first,
I'll plan to pull the rebase branch. If you need it there earlier we can
probably also just prod Andrew and get that one patch off earlier than
the rest of the -mm bits.
From: Tomi Valkeinen <hidden> Date: 2011-01-07 13:37:32
On Fri, 2011-01-07 at 22:25 +0900, ext Paul Mundt wrote:
On Fri, Jan 07, 2011 at 02:41:43PM +0200, Tomi Valkeinen wrote:
quoted
Hello Paul,
Here are some OMAP display changes for .38. I hope they are not too
late, but the holidays messed up my schedules a bit.
No, no problem. I usually aim to do two merges per merge window on
average, one at the beginning and one nearer the end. There are often
many patches that have dependencies that are blocked while other trees
merge that get sent off when their dependencies have been met.
Ok, good. There are still some patches going around reviews that would
be nice to get in .38, but time is running short so I decided to send
the current patches.
I guess it's not out-of-the-question to get driver changes in in early
rcs, but I'd rather get everything pulled during the merge window. Also,
some of the patches still out there touch OMAP's arch/ files, so they
are not plain driver changes.
quoted
I made two branches, as I'm not sure which is better:
for-paul-38 - This one is the original non-rebased branch. This causes a
trivial conflict with fbdev/master in drivers/video/omap2/vram.c (SZ_2M
is the right one), and also it contains a patch (memblock: fix
memblock_is_region_memory()) which is not yet in mainline, but is in
Andrew Morton's tree.
for-paul-38-rebased - The above branch rebased on top of v2.6.37, and
the memblock commit removed.
Which one you prefer? Or is there some other way I should handle this?
I could merge v2.6.37 to my branch, which would remove the conflict, but
that would still leave the memblock patch. I guess the patch is going in
soon, but as it's not in my area, I don't feel it's right to get it in
via my patch set. Alternatively I could wait until the patch is in
Linus' tree, but that could make it tight to be in time for the merge
window.
Andrew usually patch-bombs near the end of the window, so it's generally
a good idea to have things settled before then. In this case if the patch
is already destined for mainline then I can just pull the rebased branch,
send that out, and then once -mm syncs up everything should be good to go
for -rc1.
Looking at the change in question, it's just a correctness fix and
doesn't impact the API from the driver point of view, so at least there
won't be build damage if they're out of sync for a couple of days
(although it may trigger some nasty surprises for anyone unlucky enough
to bisect in the middle).
In any event, unless you absolutely need the change to be upstream first,
I'll plan to pull the rebase branch. If you need it there earlier we can
probably also just prod Andrew and get that one patch off earlier than
the rest of the -mm bits.
No, the fix is not needed urgently. The memblock fix is only important
for some rare use cases, which I don't think anyone is currently using
(allocating video memory from SDRAM at a predefined address).
Tomi
From: Paul Mundt <hidden> Date: 2011-01-07 13:52:17
On Fri, Jan 07, 2011 at 03:37:32PM +0200, Tomi Valkeinen wrote:
On Fri, 2011-01-07 at 22:25 +0900, ext Paul Mundt wrote:
I guess it's not out-of-the-question to get driver changes in in early
rcs, but I'd rather get everything pulled during the merge window. Also,
some of the patches still out there touch OMAP's arch/ files, so they
are not plain driver changes.
As long as all the new and big stuff goes in for -rc1 it's certainly fine
to take care of the rest over the next few rc releases. Things do
invariably break when multiple trees are being merged, so it's to be
expected.
quoted
Looking at the change in question, it's just a correctness fix and
doesn't impact the API from the driver point of view, so at least there
won't be build damage if they're out of sync for a couple of days
(although it may trigger some nasty surprises for anyone unlucky enough
to bisect in the middle).
In any event, unless you absolutely need the change to be upstream first,
I'll plan to pull the rebase branch. If you need it there earlier we can
probably also just prod Andrew and get that one patch off earlier than
the rest of the -mm bits.
No, the fix is not needed urgently. The memblock fix is only important
for some rare use cases, which I don't think anyone is currently using
(allocating video memory from SDRAM at a predefined address).
Hmm, I've just fast-forwarded to Linus's current tree and tried to pull
your rebase branch in, but it seems to have a board conflict with the
OMAP tree merge:
CONFLICT (delete/modify): arch/arm/mach-omap2/board-zoom2.c deleted in HEAD and modified in 122ffebf2191529153c079b457e38ca3829eac40. Version 122ffebf2191529153c079b457e38ca3829eac40 of arch/arm/mach-omap2/board-zoom2.c left in tree.
Additionally there's a board-zoom.c conflict that looks like this:
diff --cc arch/arm/mach-omap2/board-zoom.c
index e041c53,1523369..0000000
From: Tomi Valkeinen <hidden> Date: 2011-01-07 14:06:56
On Fri, 2011-01-07 at 22:52 +0900, ext Paul Mundt wrote:
Hmm, I've just fast-forwarded to Linus's current tree and tried to pull
your rebase branch in, but it seems to have a board conflict with the
OMAP tree merge:
CONFLICT (delete/modify): arch/arm/mach-omap2/board-zoom2.c deleted in HEAD and modified in 122ffebf2191529153c079b457e38ca3829eac40. Version 122ffebf2191529153c079b457e38ca3829eac40 of arch/arm/mach-omap2/board-zoom2.c left in tree.
Additionally there's a board-zoom.c conflict that looks like this:
Ah. I'll have to fix that. Let's leave this until Monday, as I don't
have a board here to test the fixes.
Tomi
From: Paul Mundt <hidden> Date: 2011-01-11 03:00:40
On Mon, Jan 10, 2011 at 11:51:02AM +0200, Tomi Valkeinen wrote:
Here's a new pull request for OMAP display subsystem patches. This one
is rebased on top of the new omap patches on mainline, and the resulting
board file conflict has been fixed.
And while rebasing, I squashed the topmost patch, OMAP: DSS2: Fix build
breaks for rfbi.c and dsi.c, into the respective patches. The patch
contained only a few trivial compile fixes to errors which mistakenly
slipped in.