[GIT PULL] fbdev changes for 3.8

Hi Linus,

Florian, the fbdev maintainer, has been very busy lately, so I offered to send
the pull request for fbdev for this merge window.

There are a few conflicts, but they look clear to me.
arch/arm/plat-omap/common.c is to be removed.

 Tomi

The following changes since commit 9489e9dcae718d5fde988e4a684a0f55b5f94d17:

  Linux 3.7-rc7 (2012-11-25 17:59:19 -0800)

are available in the git repository at:

  git://gitorious.org/linux-omap-dss2/linux.git tags/fbdev-for-3.8

for you to fetch changes up to e7f5c9a16ea2648a3e85af8e34191026bf3dcb62:

  Merge tag 'omapdss-for-3.8' of git://gitorious.org/linux-omap-dss2/linux into for-linus (2012-12-13 14:30:56 +0200)

----------------------------------------------------------------

fbdev changes for 3.8:

OMAPDSS changes, including:
- use dynanic debug prints
- OMAP platform dependency removals
- Creation of compat-layer, helping us to improve omapdrm
- Misc cleanups, aiming to make omadss more in line with the upcoming common
  display framework

Exynos DP changes for the 3.8 merge window:
- Device Tree support for Samsung Exynos DP
- SW Link training is cleaned up.
- HPD interrupt is supported.

Samsung Framebuffer changes for the 3.8 merge window:
- The bit definitions of header file are updated.

363 more lines

On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen [off-list ref] wrote:

Hi Linus,

Florian, the fbdev maintainer, has been very busy lately, so I offered to send
the pull request for fbdev for this merge window.

Pulled. However, with this I get the Kconfig question

   OMAP2+ Display Subsystem support (OMAP2_DSS) [N/m/y/?] (NEW)

which doesn't make a whole lot of sense on x86-64, unless there's
something about OMAP2 that I don't know.

So I'd suggest making that OMAP2_DSS be dependent on OMAP2. Or at
least ARM. Because showing it to anybody else seems insane.

Same goes for FB_OMAP2 for that matter. I realize that it's likely
nice to get compile testing for this on x86-64 too, but if that's the
intent, we need to think about it some more. I don't think it's good
to ask actual normal users questions like this just for compile
coverage.

Hmm?

                    Linus

On Sat, Dec 15, 2012 at 01:11:04PM -0800, Linus Torvalds wrote:
 > On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen [off-list ref] wrote:
 > > Hi Linus,
 > >
 > > Florian, the fbdev maintainer, has been very busy lately, so I offered to send
 > > the pull request for fbdev for this merge window.
 > 
 > Pulled. However, with this I get the Kconfig question
 > 
 >    OMAP2+ Display Subsystem support (OMAP2_DSS) [N/m/y/?] (NEW)
 > 
 > which doesn't make a whole lot of sense on x86-64, unless there's
 > something about OMAP2 that I don't know.
 > 
 > So I'd suggest making that OMAP2_DSS be dependent on OMAP2. Or at
 > least ARM. Because showing it to anybody else seems insane.
 > 
 > Same goes for FB_OMAP2 for that matter. I realize that it's likely
 > nice to get compile testing for this on x86-64 too, but if that's the
 > intent, we need to think about it some more. I don't think it's good
 > to ask actual normal users questions like this just for compile
 > coverage.

This OMAP stuff has been creeping into x86 builds for a while.
Grep from my current build config ..

# CONFIG_OMAP_OCP2SCP is not set
# CONFIG_KEYBOARD_OMAP4 is not set
# CONFIG_OMAP2_DSS is not set
# CONFIG_OMAP_USB2 is not set

There was some other arm-ism that does the same that I' currently forgetting,
or maybe that got fixed..

	Dave

* Dave Jones [off-list ref] [121215 14:27]:

On Sat, Dec 15, 2012 at 01:11:04PM -0800, Linus Torvalds wrote:
 > On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen [off-list ref] wrote:
 > > Hi Linus,
 > >
 > > Florian, the fbdev maintainer, has been very busy lately, so I offered to send
 > > the pull request for fbdev for this merge window.
 > 
 > Pulled. However, with this I get the Kconfig question
 > 
 >    OMAP2+ Display Subsystem support (OMAP2_DSS) [N/m/y/?] (NEW)
 > 
 > which doesn't make a whole lot of sense on x86-64, unless there's
 > something about OMAP2 that I don't know.
 > 
 > So I'd suggest making that OMAP2_DSS be dependent on OMAP2. Or at
 > least ARM. Because showing it to anybody else seems insane.
 > 
 > Same goes for FB_OMAP2 for that matter. I realize that it's likely
 > nice to get compile testing for this on x86-64 too, but if that's the
 > intent, we need to think about it some more. I don't think it's good
 > to ask actual normal users questions like this just for compile
 > coverage.

This OMAP stuff has been creeping into x86 builds for a while.
Grep from my current build config ..

# CONFIG_OMAP_OCP2SCP is not set
# CONFIG_KEYBOARD_OMAP4 is not set
# CONFIG_OMAP2_DSS is not set
# CONFIG_OMAP_USB2 is not set

There was some other arm-ism that does the same that I' currently forgetting,
or maybe that got fixed..

Those are all omap internal devices and should be all marked with
depends on ARCH_OMAP2PLUS.

It's a different story for external devices that may be used on other
architectures.

I only came up with one reason to compile internal devices for other
architectures: In some cases the driver subsystem maintainer may want to
be able to compile test subsystem wide changes without having to compile
for each target separately. But for those cases it's trivial to carry a
compile test patch that just drops the depends Kconfig entries.

Regards,

Tony

* Tony Lindgren [off-list ref] [121216 09:49]:

* Dave Jones [off-list ref] [121215 14:27]:

quoted

On Sat, Dec 15, 2012 at 01:11:04PM -0800, Linus Torvalds wrote:
 > On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen [off-list ref] wrote:
 > > Hi Linus,
 > >
 > > Florian, the fbdev maintainer, has been very busy lately, so I offered to send
 > > the pull request for fbdev for this merge window.
 > 
 > Pulled. However, with this I get the Kconfig question
 > 
 >    OMAP2+ Display Subsystem support (OMAP2_DSS) [N/m/y/?] (NEW)
 > 
 > which doesn't make a whole lot of sense on x86-64, unless there's
 > something about OMAP2 that I don't know.
 > 
 > So I'd suggest making that OMAP2_DSS be dependent on OMAP2. Or at
 > least ARM. Because showing it to anybody else seems insane.
 > 
 > Same goes for FB_OMAP2 for that matter. I realize that it's likely
 > nice to get compile testing for this on x86-64 too, but if that's the
 > intent, we need to think about it some more. I don't think it's good
 > to ask actual normal users questions like this just for compile
 > coverage.

This OMAP stuff has been creeping into x86 builds for a while.
Grep from my current build config ..

# CONFIG_OMAP_OCP2SCP is not set
# CONFIG_KEYBOARD_OMAP4 is not set
# CONFIG_OMAP2_DSS is not set
# CONFIG_OMAP_USB2 is not set

There was some other arm-ism that does the same that I' currently forgetting,
or maybe that got fixed..

Those are all omap internal devices and should be all marked with
depends on ARCH_OMAP2PLUS.

It's a different story for external devices that may be used on other
architectures.

6 more quoted lines

And here's a patch to limit the omap drivers above to omap only.

Regards,

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Sun, 16 Dec 2012 12:28:46 -0800
Subject: [PATCH] ARM: OMAP: Fix drivers to depend on omap for internal devices

These devices are not available on other architectures, so
let's limit them to omap.

If the driver subsystem maintainers want to build test
system wide changes without building for each target,
it's easy to carry a test patch that just strips out the
depends entries from Kconfig files.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig

@@ -6,6 +6,7 @@ menu "Bus devices"
 
 config OMAP_OCP2SCP
 	tristate "OMAP OCP2SCP DRIVER"
+	depends on ARCH_OMAP2PLUS
 	help
 	  Driver to enable ocp2scp module which transforms ocp interface
 	  protocol to scp protocol. In OMAP4, USB PHY is connected via
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig

@@ -544,6 +544,7 @@ config KEYBOARD_OMAP
 
 config KEYBOARD_OMAP4
 	tristate "TI OMAP4+ keypad support"
+	depends on ARCH_OMAP2PLUS
 	select INPUT_MATRIXKMAP
 	help
 	  Say Y here if you want to use the OMAP4+ keypad.
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig

@@ -6,6 +6,7 @@ comment "USB Physical Layer drivers"
 
 config OMAP_USB2
 	tristate "OMAP USB2 PHY Driver"
+	depends on ARCH_OMAP2PLUS
 	select USB_OTG_UTILS
 	help
 	  Enable this to support the transceiver that is part of SOC. This
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig

@@ -1,6 +1,10 @@
 config OMAP2_VRFB
 	bool
 
+if ARCH_OMAP2PLUS
+
 source "drivers/video/omap2/dss/Kconfig"
 source "drivers/video/omap2/omapfb/Kconfig"
 source "drivers/video/omap2/displays/Kconfig"
+
+endif
--- a/drivers/w1/masters/Kconfig
+++ b/drivers/w1/masters/Kconfig

@@ -60,6 +60,7 @@ config W1_MASTER_GPIO
 
 config HDQ_MASTER_OMAP
 	tristate "OMAP HDQ driver"
+	depends on ARCH_OMAP
 	help
 	  Say Y here if you want support for the 1-wire or HDQ Interface
 	  on an OMAP processor.

On Sun, Dec 16, 2012 at 12:35:37PM -0800, Tony Lindgren wrote:

* Tony Lindgren [off-list ref] [121216 09:49]:

quoted

* Dave Jones [off-list ref] [121215 14:27]:

quoted

On Sat, Dec 15, 2012 at 01:11:04PM -0800, Linus Torvalds wrote:
 > On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen [off-list ref] wrote:
 > > Hi Linus,
 > >
 > > Florian, the fbdev maintainer, has been very busy lately, so I offered to send
 > > the pull request for fbdev for this merge window.
 > 
 > Pulled. However, with this I get the Kconfig question
 > 
 >    OMAP2+ Display Subsystem support (OMAP2_DSS) [N/m/y/?] (NEW)
 > 
 > which doesn't make a whole lot of sense on x86-64, unless there's
 > something about OMAP2 that I don't know.
 > 
 > So I'd suggest making that OMAP2_DSS be dependent on OMAP2. Or at
 > least ARM. Because showing it to anybody else seems insane.
 > 
 > Same goes for FB_OMAP2 for that matter. I realize that it's likely
 > nice to get compile testing for this on x86-64 too, but if that's the
 > intent, we need to think about it some more. I don't think it's good
 > to ask actual normal users questions like this just for compile
 > coverage.

This OMAP stuff has been creeping into x86 builds for a while.
Grep from my current build config ..

# CONFIG_OMAP_OCP2SCP is not set
# CONFIG_KEYBOARD_OMAP4 is not set
# CONFIG_OMAP2_DSS is not set
# CONFIG_OMAP_USB2 is not set

There was some other arm-ism that does the same that I' currently forgetting,
or maybe that got fixed..

Those are all omap internal devices and should be all marked with
depends on ARCH_OMAP2PLUS.

It's a different story for external devices that may be used on other

9 more quoted lines

Do you think we could add a new symbol to debug options, something like
COMPILE_COVERAGE, and have drivers that can be compiled on platforms
other than ones having the hardware to do

	depend on ARCH_XXX || COMPILE_CONVERAGE

This way people who want to do compile coverage do not have to carry
patches and allyesconfig will pick this right up.

Thanks.

-- 
Dmitry

On 2012-12-16 22:35, Tony Lindgren wrote:

quoted

Those are all omap internal devices and should be all marked with
depends on ARCH_OMAP2PLUS.

It's a different story for external devices that may be used on other
architectures.

I only came up with one reason to compile internal devices for other
architectures: In some cases the driver subsystem maintainer may want to
be able to compile test subsystem wide changes without having to compile
for each target separately. But for those cases it's trivial to carry a
compile test patch that just drops the depends Kconfig entries.

And here's a patch to limit the omap drivers above to omap only.

The patch looks good to me.

The reason I removed the OMAP dependency from OMAP DSS was not (only)
because of the compile testing, but also because I thought it was right:
a driver for an IP block shouldn't presume that the IP is used only on
particular SoC.

But perhaps that's a bit too academic approach for an IP that's in real
world only used for OMAP.

 Tomi

Hi,

On Sun, Dec 16, 2012 at 12:35:37PM -0800, Tony Lindgren wrote:

* Tony Lindgren [off-list ref] [121216 09:49]:

quoted

* Dave Jones [off-list ref] [121215 14:27]:

quoted

On Sat, Dec 15, 2012 at 01:11:04PM -0800, Linus Torvalds wrote:
 > On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen [off-list ref] wrote:
 > > Hi Linus,
 > >
 > > Florian, the fbdev maintainer, has been very busy lately, so I offered to send
 > > the pull request for fbdev for this merge window.
 > 
 > Pulled. However, with this I get the Kconfig question
 > 
 >    OMAP2+ Display Subsystem support (OMAP2_DSS) [N/m/y/?] (NEW)
 > 
 > which doesn't make a whole lot of sense on x86-64, unless there's
 > something about OMAP2 that I don't know.
 > 
 > So I'd suggest making that OMAP2_DSS be dependent on OMAP2. Or at
 > least ARM. Because showing it to anybody else seems insane.
 > 
 > Same goes for FB_OMAP2 for that matter. I realize that it's likely
 > nice to get compile testing for this on x86-64 too, but if that's the
 > intent, we need to think about it some more. I don't think it's good
 > to ask actual normal users questions like this just for compile
 > coverage.

This OMAP stuff has been creeping into x86 builds for a while.
Grep from my current build config ..

# CONFIG_OMAP_OCP2SCP is not set
# CONFIG_KEYBOARD_OMAP4 is not set
# CONFIG_OMAP2_DSS is not set
# CONFIG_OMAP_USB2 is not set

There was some other arm-ism that does the same that I' currently forgetting,
or maybe that got fixed..

Those are all omap internal devices and should be all marked with
depends on ARCH_OMAP2PLUS.

It's a different story for external devices that may be used on other

59 more quoted lines

for Keypad, PHY and OCP2SCP I would rather not as I want to use
linux-next for compile testing our stuff in all arches.

-- 
balbi

* Dmitry Torokhov [off-list ref] [121216 22:03]:

On Sun, Dec 16, 2012 at 12:35:37PM -0800, Tony Lindgren wrote:

quoted

* Tony Lindgren [off-list ref] [121216 09:49]:

quoted

* Dave Jones [off-list ref] [121215 14:27]:

quoted

On Sat, Dec 15, 2012 at 01:11:04PM -0800, Linus Torvalds wrote:
 > On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen [off-list ref] wrote:
 > > Hi Linus,
 > >
 > > Florian, the fbdev maintainer, has been very busy lately, so I offered to send
 > > the pull request for fbdev for this merge window.
 > 
 > Pulled. However, with this I get the Kconfig question
 > 
 >    OMAP2+ Display Subsystem support (OMAP2_DSS) [N/m/y/?] (NEW)
 > 
 > which doesn't make a whole lot of sense on x86-64, unless there's
 > something about OMAP2 that I don't know.
 > 
 > So I'd suggest making that OMAP2_DSS be dependent on OMAP2. Or at
 > least ARM. Because showing it to anybody else seems insane.
 > 
 > Same goes for FB_OMAP2 for that matter. I realize that it's likely
 > nice to get compile testing for this on x86-64 too, but if that's the
 > intent, we need to think about it some more. I don't think it's good
 > to ask actual normal users questions like this just for compile
 > coverage.

This OMAP stuff has been creeping into x86 builds for a while.
Grep from my current build config ..

# CONFIG_OMAP_OCP2SCP is not set
# CONFIG_KEYBOARD_OMAP4 is not set
# CONFIG_OMAP2_DSS is not set
# CONFIG_OMAP_USB2 is not set

There was some other arm-ism that does the same that I' currently forgetting,
or maybe that got fixed..

Those are all omap internal devices and should be all marked with
depends on ARCH_OMAP2PLUS.

19 more quoted lines

I like that idea. Looks like Linus already applied the earlier
patch, I'll do a patch for COMPILE_COVERAGE separately.

Regards,

Tony