[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. - Some minor typos are fixed. - Some minor bugs of s3c_fb_check_var() are fixed. FB related changes for SH Mobile, Freescale DIU Add support for the Solomon SSD1307 OLED Controller Aaro Koskinen (1): OMAPDSS: panel-n8x0: register the DSS driver after SPI probe Ajay Kumar (5): video: exynos_dp: Add device tree support to DP driver video: exynos_dp: device tree documentation video: exynos_dp: Reset and initialize DP before requesting irq video: exynos_dp: Fix incorrect setting for INT_CTL video: exynos_dp: remove redundant parameters Archit Taneja (10): OMAPDSS: Remove acb and acbi fields from omap_dss_device OMAPDSS: DISPC: Fix calc_scaling_44xx() bugs for writeback pipeline OMAPDSS: DISPC: Don't allow predecimation for writeback OMAPDSS: DISPC: Use output width and height to calculate row/pix inc for writeback OMAPDSS: APPLY: Don't treat an overlay's channel out as shadow bits OMAPDSS: APPLY: Remove unnecessary variable in dss_apply_irq_handler OMAPDSS: APPLY: Remove unnecessary call to mg_clear_shadow_dirty OMAPDSS: Add overlay manager width and height limits as a dispc feature OMAPDSS: Add a dispc_features struct for OMAP5 OMAPDSS: Use only "omapdss_dss" platform device to get context lost count Axel Lin (1): OMAPDSS: Add terminating entry for picodlp_i2c_id table Chandrabhanu Mahapatra (5): OMAPDSS: Move definition of DEBUG flag to Makefile OMAPDSS: Create new debug config options OMAPDSS: Cleanup DSSDBG with dynamic pr_debug function OMAPDSS: Replace multi part debug prints with pr_debug OMAPDSS: Remove dss_debug variable Chuansheng Liu (2): OMAPDSS: DISPC: Fix the usage of wait_for_completion_timeout OMAPDSS: APPLY: Fix the usage of wait_for_completion_timeout Hideki EIRAKU (1): fbdev: sh_mobile_lcdc: use dma_mmap_coherent Jingoo Han (14): video: s3c-fb: clean the bit definition for WINCON register video: s3c-fb: move the address definitions for VIDTCON registers video: s3c-fb: move the address definition for VIDOSD register video: s3c-fb: move the bit definitions for VIDINTCON0 register video: s3c-fb: move the bit definitions for WINxMAP and WPALCON register video: s3c-fb: move the bit definitions for DITHMODE register video: s3c-fb: add the bit definitions for VIDCON0_VIDOUT_WB video: s3c-fb: fix typo in comment video: s3c-fb: fix help message for FB_S3C_DEBUG_REGWRITE video: s3c-fb: use FIMD_V8_VIDTCON0 for EXYNOS5 FIMD video: s3c-fb: use dev_get_drvdata() instead of platform_get_drvdata() video: s3c-fb: add "drop through" comment video: s3c-fb: return an error when bpp is invalid video: s3c-fb: fix red offset and length for ARGB232 format Laurent Pinchart (19): fbdev: sh_mobile_lcdc: Get display dimensions from the channel structure fbdev: sh_mobile_lcdc: Rename mode argument to modes fbdev: sh_mobile_lcdc: Remove priv argument from channel and overlay init ARM: mach-shmobile: ag5evm: Add LCDC tx_dev field to platform data fbdev: sh_mipi_dsi: Add channel field to platform data ARM: mach-shmobile: Initiliaze the new sh_mipi_dsi_info channel field fbdev: sh_mipi_dsi: Use the sh_mipi_dsi_info channel field fbdev: sh_mipi_dsi: Use the LCDC entity default mode fbdev: sh_mipi_dsi: Remove last reference to LCDC platform data ARM: mach-shmobile: Remove the unused sh_mipi_dsi_info lcd_chan field fbdev: sh_mipi_dsi: Remove the unused sh_mipi_dsi_info lcd_chan field fbdev: sh_mobile_lcdc:
Re: [GIT PULL] fbdev changes for 3.8
On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] fbdev changes for 3.8
On Sat, Dec 15, 2012 at 01:11:04PM -0800, Linus Torvalds wrote: > On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] fbdev changes for 3.8
* Dave Jones [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 > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] fbdev changes for 3.8
* Tony Lindgren [121216 09:49]: > * Dave Jones [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 > > 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. And here's a patch to limit the omap drivers above to omap only. Regards, Tony From: Tony Lindgren 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 --- 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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] fbdev changes for 3.8
On Sun, Dec 16, 2012 at 12:35:37PM -0800, Tony Lindgren wrote: > * Tony Lindgren [121216 09:49]: > > * Dave Jones [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 > > > 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. > > And here's a patch to limit the omap drivers above to omap only. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] fbdev changes for 3.8
On 2012-12-16 22:35, Tony Lindgren wrote: >> 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 signature.asc Description: OpenPGP digital signature
Re: [GIT PULL] fbdev changes for 3.8
Hi, On Sun, Dec 16, 2012 at 12:35:37PM -0800, Tony Lindgren wrote: > * Tony Lindgren [121216 09:49]: > > * Dave Jones [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 > > > 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. > > And here's a patch to limit the omap drivers above to omap only. > > Regards, > > Tony > > > From: Tony Lindgren > 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 > > --- 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 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 signature.asc Description: Digital signature
Re: [GIT PULL] fbdev changes for 3.8
* Dmitry Torokhov [121216 22:03]: > On Sun, Dec 16, 2012 at 12:35:37PM -0800, Tony Lindgren wrote: > > * Tony Lindgren [121216 09:49]: > > > * Dave Jones [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 > > > > 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. > > > > And here's a patch to limit the omap drivers above to omap only. > > 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. I like that idea. Looks like Linus already applied the earlier patch, I'll do a patch for COMPILE_COVERAGE separately. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
