linux-next: manual merge of the omap_dss2 tree with the omap tree

linux-next: manual merge of the omap_dss2 tree with the omap tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 366 bytes --]

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/configs/omap_3430sdp_defconfig between the omap tree and the
omap_dss2 tree.

I just used the version from the omap tree as I can't figure out anything
better, sorry.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tomi Valkeinen]

On Mon, 2009-11-16 at 06:04 +0100, ext Stephen Rothwell wrote:
> Hi Tomi,
> 
> Today's linux-next merge of the omap_dss2 tree got a conflict in
> arch/arm/configs/omap_3430sdp_defconfig between the omap tree and the
> omap_dss2 tree.
> 
> I just used the version from the omap tree as I can't figure out anything
> better, sorry.

Tony, 

These patches in omap tree seem to cause the conflicts. Are they stable,
ie. can I cherry pick them to my for-next tree, and put my patches on
top of them?

b30dcf5f37023d591caee80c233bf33706bc5a21
omap3: 3430sdp: Enable Linux Regulator framework

fc89f86e06c11b8828ce1d6c669f724877546c03
ARM: OMAP3: Fix 3430SDP defconfig

 Tomi

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tony Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

* Tomi Valkeinen <tomi.valkeinen@nokia.com> [091116 02:06]:
> On Mon, 2009-11-16 at 06:04 +0100, ext Stephen Rothwell wrote:
> > Hi Tomi,
> > 
> > Today's linux-next merge of the omap_dss2 tree got a conflict in
> > arch/arm/configs/omap_3430sdp_defconfig between the omap tree and the
> > omap_dss2 tree.
> > 
> > I just used the version from the omap tree as I can't figure out anything
> > better, sorry.
> 
> Tony, 
> 
> These patches in omap tree seem to cause the conflicts. Are they stable,
> ie. can I cherry pick them to my for-next tree, and put my patches on
> top of them?

Well all the board-*.c patches are still getting shuffled around
this week a bit.. But we can resolve it with the following two changes.
 
> b30dcf5f37023d591caee80c233bf33706bc5a21
> omap3: 3430sdp: Enable Linux Regulator framework

This we should keep as it is, but the commit ID may still change.
 
> fc89f86e06c11b8828ce1d6c669f724877546c03
> ARM: OMAP3: Fix 3430SDP defconfig

I've cut out the CONFIG_FB related sections of this patch in
omap for-next branch, see below.

Tomi, please update your patch by leaving out the now unnecessary
TWL4030 and regulator sections. See also the updated version of
your patch attached.

And please also use the static commit id I gave earlier, the other
patches can still change a bit.

Regards,

Tony

[-- Attachment #2: sdp3430-defconfig-nofb.patch --]
[-- Type: text/x-diff, Size: 1274 bytes --]

I've left out the CONFIG_FB related parts of
"ARM: OMAP3: Fix 3430SDP defconfig" and renamed
it to "ARM: OMAP3: Update 3430SDP defconfig".

--- a/arch/arm/configs/omap_3430sdp_defconfig
+++ b/arch/arm/configs/omap_3430sdp_defconfig
@@ -940,11 +940,9 @@ CONFIG_TWL4030_CORE=y
 # Graphics support
 #
 # CONFIG_VGASTATE is not set
-# CONFIG_VIDEO_OUTPUT_CONTROL is not set
 CONFIG_FB=y
 # CONFIG_FIRMWARE_EDID is not set
 # CONFIG_FB_DDC is not set
-# CONFIG_FB_BOOT_VESA_SUPPORT is not set
 CONFIG_FB_CFB_FILLRECT=y
 CONFIG_FB_CFB_COPYAREA=y
 CONFIG_FB_CFB_IMAGEBLIT=y
@@ -965,13 +963,8 @@ CONFIG_FB_CFB_IMAGEBLIT=y
 #
 # CONFIG_FB_S1D13XXX is not set
 # CONFIG_FB_VIRTUAL is not set
-# CONFIG_FB_METRONOME is not set
-# CONFIG_FB_MB862XX is not set
-# CONFIG_FB_BROADSHEET is not set
 CONFIG_FB_OMAP=y
-# CONFIG_FB_OMAP_LCD_VGA is not set
 # CONFIG_FB_OMAP_LCDC_EXTERNAL is not set
-# CONFIG_FB_OMAP_LCD_MIPID is not set
 # CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
 CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2
 # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
@@ -979,7 +972,11 @@ CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2
 #
 # Display device support
 #
-# CONFIG_DISPLAY_SUPPORT is not set
+CONFIG_DISPLAY_SUPPORT=y
+
+#
+# Display hardware drivers
+#
 
 #
 # Console display driver support

[-- Attachment #3: tomi-3430sdp-v2.patch --]
[-- Type: text/x-diff, Size: 7277 bytes --]

>From 5fdd839b3fcf292c52fd68b76a6b254436c86c3e Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@nokia.com>
Date: Wed, 5 Aug 2009 16:07:26 +0300
Subject: [PATCH] OMAP: SDP: Enable DSS2 for OMAP3 SDP board

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
Acked-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/configs/omap_3430sdp_defconfig b/arch/arm/configs/omap_3430sdp_defconfig
index 8a4a7e2..730ada3 100644
--- a/arch/arm/configs/omap_3430sdp_defconfig
+++ b/arch/arm/configs/omap_3430sdp_defconfig
@@ -1336,10 +1338,33 @@ CONFIG_FB_CFB_IMAGEBLIT=y
 #
 # CONFIG_FB_S1D13XXX is not set
 # CONFIG_FB_VIRTUAL is not set
-CONFIG_FB_OMAP=y
-# CONFIG_FB_OMAP_LCDC_EXTERNAL is not set
+# CONFIG_FB_METRONOME is not set
+# CONFIG_FB_MB862XX is not set
+# CONFIG_FB_BROADSHEET is not set
+# CONFIG_FB_OMAP_LCD_VGA is not set
 # CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
-CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2
+CONFIG_OMAP2_VRAM=y
+CONFIG_OMAP2_VRFB=y
+CONFIG_OMAP2_DSS=y
+CONFIG_OMAP2_VRAM_SIZE=4
+CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y
+# CONFIG_OMAP2_DSS_RFBI is not set
+CONFIG_OMAP2_DSS_VENC=y
+# CONFIG_OMAP2_DSS_SDI is not set
+# CONFIG_OMAP2_DSS_DSI is not set
+# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set
+CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0
+CONFIG_FB_OMAP2=y
+CONFIG_FB_OMAP2_DEBUG_SUPPORT=y
+# CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE is not set
+CONFIG_FB_OMAP2_NUM_FBS=3
+
+#
+# OMAP2/3 Display Device Drivers
+#
+CONFIG_PANEL_GENERIC=y
+# CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C is not set
+CONFIG_PANEL_SHARP_LS037V7DW01=y
 # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
 
 #
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index a2abac9..b697d50 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -37,6 +37,7 @@
 #include <plat/common.h>
 #include <plat/dma.h>
 #include <plat/gpmc.h>
+#include <plat/display.h>
 
 #include <plat/control.h>
 #include <plat/gpmc-smc91x.h>
@@ -152,31 +153,152 @@ static struct spi_board_info sdp3430_spi_board_info[] __initdata = {
 	},
 };
 
-static struct platform_device sdp3430_lcd_device = {
-	.name		= "sdp2430_lcd",
-	.id		= -1,
+
+#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO	8
+#define SDP3430_LCD_PANEL_ENABLE_GPIO		5
+
+static unsigned backlight_gpio;
+static unsigned enable_gpio;
+static int lcd_enabled;
+static int dvi_enabled;
+
+static void __init sdp3430_display_init(void)
+{
+	int r;
+
+	enable_gpio    = SDP3430_LCD_PANEL_ENABLE_GPIO;
+	backlight_gpio = SDP3430_LCD_PANEL_BACKLIGHT_GPIO;
+
+	r = gpio_request(enable_gpio, "LCD reset");
+	if (r) {
+		printk(KERN_ERR "failed to get LCD reset GPIO\n");
+		goto err0;
+	}
+
+	r = gpio_request(backlight_gpio, "LCD Backlight");
+	if (r) {
+		printk(KERN_ERR "failed to get LCD backlight GPIO\n");
+		goto err1;
+	}
+
+	gpio_direction_output(enable_gpio, 0);
+	gpio_direction_output(backlight_gpio, 0);
+
+	return;
+err1:
+	gpio_free(enable_gpio);
+err0:
+	return;
+}
+
+static int sdp3430_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+	if (dvi_enabled) {
+		printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
+		return -EINVAL;
+	}
+
+	gpio_direction_output(enable_gpio, 1);
+	gpio_direction_output(backlight_gpio, 1);
+
+	lcd_enabled = 1;
+
+	return 0;
+}
+
+static void sdp3430_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+	lcd_enabled = 0;
+
+	gpio_direction_output(enable_gpio, 0);
+	gpio_direction_output(backlight_gpio, 0);
+}
+
+static int sdp3430_panel_enable_dvi(struct omap_dss_device *dssdev)
+{
+	if (lcd_enabled) {
+		printk(KERN_ERR "cannot enable DVI, LCD is enabled\n");
+		return -EINVAL;
+	}
+
+	dvi_enabled = 1;
+
+	return 0;
+}
+
+static void sdp3430_panel_disable_dvi(struct omap_dss_device *dssdev)
+{
+	dvi_enabled = 0;
+}
+
+static int sdp3430_panel_enable_tv(struct omap_dss_device *dssdev)
+{
+	return 0;
+}
+
+static void sdp3430_panel_disable_tv(struct omap_dss_device *dssdev)
+{
+}
+
+
+static struct omap_dss_device sdp3430_lcd_device = {
+	.name			= "lcd",
+	.driver_name		= "sharp_ls_panel",
+	.type			= OMAP_DISPLAY_TYPE_DPI,
+	.phy.dpi.data_lines	= 16,
+	.platform_enable	= sdp3430_panel_enable_lcd,
+	.platform_disable	= sdp3430_panel_disable_lcd,
 };
 
-static struct regulator_consumer_supply sdp3430_vdac_supply = {
-	.supply		= "vdac",
-	.dev		= &sdp3430_lcd_device.dev,
+static struct omap_dss_device sdp3430_dvi_device = {
+	.name			= "dvi",
+	.driver_name		= "generic_panel",
+	.type			= OMAP_DISPLAY_TYPE_DPI,
+	.phy.dpi.data_lines	= 24,
+	.platform_enable	= sdp3430_panel_enable_dvi,
+	.platform_disable	= sdp3430_panel_disable_dvi,
 };
 
-static struct regulator_consumer_supply sdp3430_vdvi_supply = {
-	.supply		= "vdvi",
-	.dev		= &sdp3430_lcd_device.dev,
+static struct omap_dss_device sdp3430_tv_device = {
+	.name			= "tv",
+	.driver_name		= "venc",
+	.type			= OMAP_DISPLAY_TYPE_VENC,
+	.phy.venc.type		= OMAP_DSS_VENC_TYPE_SVIDEO,
+	.platform_enable	= sdp3430_panel_enable_tv,
+	.platform_disable	= sdp3430_panel_disable_tv,
 };
 
-static struct platform_device *sdp3430_devices[] __initdata = {
+
+static struct omap_dss_device *sdp3430_dss_devices[] = {
 	&sdp3430_lcd_device,
+	&sdp3430_dvi_device,
+	&sdp3430_tv_device,
 };
 
-static struct omap_lcd_config sdp3430_lcd_config __initdata = {
-	.ctrl_name	= "internal",
+static struct omap_dss_board_info sdp3430_dss_data = {
+	.num_devices	= ARRAY_SIZE(sdp3430_dss_devices),
+	.devices	= sdp3430_dss_devices,
+	.default_device	= &sdp3430_lcd_device,
+};
+
+static struct platform_device sdp3430_dss_device = {
+	.name		= "omapdss",
+	.id		= -1,
+	.dev		= {
+		.platform_data = &sdp3430_dss_data,
+	},
+};
+
+static struct regulator_consumer_supply sdp3430_vdda_dac_supply = {
+	.supply		= "vdda_dac",
+	.dev		= &sdp3430_dss_device.dev,
+};
+
+static struct platform_device *sdp3430_devices[] __initdata = {
+	&sdp3430_dss_device,
 };
 
 static struct omap_board_config_kernel sdp3430_config[] __initdata = {
-	{ OMAP_TAG_LCD,		&sdp3430_lcd_config },
 };
 
 static void __init omap_3430sdp_init_irq(void)
@@ -392,22 +514,34 @@ static struct regulator_init_data sdp3430_vdac = {
 					| REGULATOR_CHANGE_STATUS,
 	},
 	.num_consumer_supplies	= 1,
-	.consumer_supplies	= &sdp3430_vdac_supply,
+	.consumer_supplies	= &sdp3430_vdda_dac_supply,
 };
 
 /* VPLL2 for digital video outputs */
+static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
+	{
+		.supply		= "vdvi",
+		.dev		= &sdp3430_lcd_device.dev,
+	},
+	{
+		.supply		= "vdds_dsi",
+		.dev		= &sdp3430_dss_device.dev,
+	}
+};
+
 static struct regulator_init_data sdp3430_vpll2 = {
 	.constraints = {
 		.name			= "VDVI",
 		.min_uV			= 1800000,
 		.max_uV			= 1800000,
+		.apply_uV		= true,
 		.valid_modes_mask	= REGULATOR_MODE_NORMAL
 					| REGULATOR_MODE_STANDBY,
 		.valid_ops_mask		= REGULATOR_CHANGE_MODE
 					| REGULATOR_CHANGE_STATUS,
 	},
-	.num_consumer_supplies	= 1,
-	.consumer_supplies	= &sdp3430_vdvi_supply,
+	.num_consumer_supplies	= ARRAY_SIZE(sdp3430_vpll2_supplies),
+	.consumer_supplies	= sdp3430_vpll2_supplies,
 };
 
 static struct twl4030_platform_data sdp3430_twldata = {
@@ -499,6 +633,7 @@ static void __init omap_3430sdp_init(void)
 	omap_serial_init();
 	usb_musb_init();
 	board_smc91x_init();
+	sdp3430_display_init();
 	enable_board_wakeup_source();
 }
 

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Tomi Valkeinen]

On Mon, 2009-11-16 at 19:34 +0100, ext Tony Lindgren wrote:
> Tomi, please update your patch by leaving out the now unnecessary
> TWL4030 and regulator sections. See also the updated version of
> your patch attached.

Thanks, updated. Now I'm able to merge linux-omap/for-next and
dss/for-next without conflicts.

 Tomi

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

Hi Tomi,

On Tue, 17 Nov 2009 12:00:31 +0200 Tomi Valkeinen <tomi.valkeinen@nokia.com> wrote:
>
> On Mon, 2009-11-16 at 19:34 +0100, ext Tony Lindgren wrote:
> > Tomi, please update your patch by leaving out the now unnecessary
> > TWL4030 and regulator sections. See also the updated version of
> > your patch attached.
> 
> Thanks, updated. Now I'm able to merge linux-omap/for-next and
> dss/for-next without conflicts.

Great, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

[Sid Boyce]

On 16/11/09 05:04, Stephen Rothwell wrote:
> Hi Tomi,
> 
> Today's linux-next merge of the omap_dss2 tree got a conflict in
> arch/arm/configs/omap_3430sdp_defconfig between the omap tree and the
> omap_dss2 tree.
> 
> I just used the version from the omap tree as I can't figure out anything
> better, sorry.

In every incarnation, EHCI support is missing " default y if
ARCH_OMAP34XX" in drivers/usb/Kconfig
Regards
Sid.
-- 
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

Is the OMAP patch process badly flawed?

[Sid Boyce]

I'm curious - I download, build and test kernels on x86 and x86_64
platforms, -rc, -rc-git and -git all build and run.
On the OMAP platform I have so far not been able to do that with
omap-git, omap-dss2-git trees and snapshots all missing basic hardware
support, e.g:- I get the latest from gitorious.org, make
omap3_beagle_defconfg, make xconfig, but there is no EHCI config
available. I hunt down the patch and hand apply "default y if
ARCH_OMAP34XX" to drivers/usb/Kconfig, next the build complains that
drivers/usb/host/ehci-hcd.c: 1143:2: error: #error "missing bus glue for
ehci-hcd"

The bus glue patch ... ehci-omap.c no longer exists.
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1108,6 +1108,11 @@ MODULE_LICENSE ("GPL");
 #define        PLATFORM_DRIVER         ehci_hcd_au1xxx_driver
 #endif

+#ifdef CONFIG_ARCH_OMAP34XX
+#include "ehci-omap.c"
+#define        PLATFORM_DRIVER         ehci_hcd_omap_driver
+#endif
+
 #ifdef CONFIG_PPC_PS3
 #include "ehci-ps3.c"
 #define        PS3_SYSTEM_BUS_DRIVER   ps3_ehci_driver

I would expect patches sent upstream would result in all the basics for
long established platforms to be fully covered. Appreciating that
development is quite fast paced with mods and supporting new platforms.
Could someone please enlighten me?
Regards
Sid.
-- 
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

RE: Is the OMAP patch process badly flawed?

[Gadiyar, Anand]

Sid Boyce wrote: 
> I'm curious - I download, build and test kernels on x86 and x86_64
> platforms, -rc, -rc-git and -git all build and run.
> On the OMAP platform I have so far not been able to do that with
> omap-git, omap-dss2-git trees and snapshots all missing basic hardware
> support, e.g:- I get the latest from gitorious.org, make
> omap3_beagle_defconfg, make xconfig, but there is no EHCI config
> available. I hunt down the patch and hand apply "default y if
> ARCH_OMAP34XX" to drivers/usb/Kconfig, next the build complains that
> drivers/usb/host/ehci-hcd.c: 1143:2: error: #error "missing 
> bus glue for
> ehci-hcd"
> 
> The bus glue patch ... ehci-omap.c no longer exists.
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -1108,6 +1108,11 @@ MODULE_LICENSE ("GPL");
>  #define        PLATFORM_DRIVER         ehci_hcd_au1xxx_driver
>  #endif
> 
> +#ifdef CONFIG_ARCH_OMAP34XX
> +#include "ehci-omap.c"
> +#define        PLATFORM_DRIVER         ehci_hcd_omap_driver
> +#endif
> +
>  #ifdef CONFIG_PPC_PS3
>  #include "ehci-ps3.c"
>  #define        PS3_SYSTEM_BUS_DRIVER   ps3_ehci_driver
> 
> I would expect patches sent upstream would result in all the basics for
> long established platforms to be fully covered. Appreciating that
> development is quite fast paced with mods and supporting new platforms.
> Could someone please enlighten me?

Sid,

Speaking purely for EHCI, this is now queued up in Greg's USB queue
for upstream and will get merged in the next cycle.

Until then, the linux-omap code does have working EHCI support
on beagle, evm and the other boards. If you're cloning from
gitorious, you're probably picking the wrong tree.

- Anand

Re: Is the OMAP patch process badly flawed?

[Sid Boyce]

On 17/11/09 13:34, Gadiyar, Anand wrote:
> Sid Boyce wrote: 
>> I'm curious - I download, build and test kernels on x86 and x86_64
>> platforms, -rc, -rc-git and -git all build and run.
>> On the OMAP platform I have so far not been able to do that with
>> omap-git, omap-dss2-git trees and snapshots all missing basic hardware
>> support, e.g:- I get the latest from gitorious.org, make
>> omap3_beagle_defconfg, make xconfig, but there is no EHCI config
>> available. I hunt down the patch and hand apply "default y if
>> ARCH_OMAP34XX" to drivers/usb/Kconfig, next the build complains that
>> drivers/usb/host/ehci-hcd.c: 1143:2: error: #error "missing 
>> bus glue for
>> ehci-hcd"
>>
>> The bus glue patch ... ehci-omap.c no longer exists.
>> --- a/drivers/usb/host/ehci-hcd.c
>> +++ b/drivers/usb/host/ehci-hcd.c
>> @@ -1108,6 +1108,11 @@ MODULE_LICENSE ("GPL");
>>  #define        PLATFORM_DRIVER         ehci_hcd_au1xxx_driver
>>  #endif
>>
>> +#ifdef CONFIG_ARCH_OMAP34XX
>> +#include "ehci-omap.c"
>> +#define        PLATFORM_DRIVER         ehci_hcd_omap_driver
>> +#endif
>> +
>>  #ifdef CONFIG_PPC_PS3
>>  #include "ehci-ps3.c"
>>  #define        PS3_SYSTEM_BUS_DRIVER   ps3_ehci_driver
>>
>> I would expect patches sent upstream would result in all the basics for
>> long established platforms to be fully covered. Appreciating that
>> development is quite fast paced with mods and supporting new platforms.
>> Could someone please enlighten me?
> 
> Sid,
> 
> Speaking purely for EHCI, this is now queued up in Greg's USB queue
> for upstream and will get merged in the next cycle.
> 
> Until then, the linux-omap code does have working EHCI support
> on beagle, evm and the other boards. If you're cloning from
> gitorious, you're probably picking the wrong tree.
> 
> - Anand
> 
> 

Thanks, that explains a lot as I can't remember seeing those patches on
the linux-usb list for submission upstream.
What tree is best to clone?
Regards
Sid.
-- 
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

RE: Is the OMAP patch process badly flawed?

[Gadiyar, Anand]

Sid Boyce wrote:

<snip>

> >>
> >> I would expect patches sent upstream would result in all the basics for
> >> long established platforms to be fully covered. Appreciating that
> >> development is quite fast paced with mods and supporting new platforms.
> >> Could someone please enlighten me?
> > 
> > Sid,
> > 
> > Speaking purely for EHCI, this is now queued up in Greg's USB queue
> > for upstream and will get merged in the next cycle.
> > 
> > Until then, the linux-omap code does have working EHCI support
> > on beagle, evm and the other boards. If you're cloning from
> > gitorious, you're probably picking the wrong tree.
> > 
> > - Anand
> > 
> > 
> 
> Thanks, that explains a lot as I can't remember seeing those patches on
> the linux-usb list for submission upstream.
> What tree is best to clone?


Not sure which is best - I suppose that depends on what all you need.
The canonical linux-omap tree maintained by Tony is at [1].

For EHCI, Felipe sent the driver to Greg who queued it up for .33 [2].
Tony lined up the board files and mach-omap2/usb-ehci.c in the for-next
branch.



[1] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
[2] http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-07-usb-2.6.32-rc6.patch
 

Re: Is the OMAP patch process badly flawed?

[Sid Boyce]

On 17/11/09 14:51, Gadiyar, Anand wrote:
> Sid Boyce wrote:
> 
> <snip>
> 
>>>>
>>>> I would expect patches sent upstream would result in all the basics for
>>>> long established platforms to be fully covered. Appreciating that
>>>> development is quite fast paced with mods and supporting new platforms.
>>>> Could someone please enlighten me?
>>>
>>> Sid,
>>>
>>> Speaking purely for EHCI, this is now queued up in Greg's USB queue
>>> for upstream and will get merged in the next cycle.
>>>
>>> Until then, the linux-omap code does have working EHCI support
>>> on beagle, evm and the other boards. If you're cloning from
>>> gitorious, you're probably picking the wrong tree.
>>>
>>> - Anand
>>>
>>>
>>
>> Thanks, that explains a lot as I can't remember seeing those patches on
>> the linux-usb list for submission upstream.
>> What tree is best to clone?
> 
> 
> Not sure which is best - I suppose that depends on what all you need.
> The canonical linux-omap tree maintained by Tony is at [1].
> 
> For EHCI, Felipe sent the driver to Greg who queued it up for .33 [2].
> Tony lined up the board files and mach-omap2/usb-ehci.c in the for-next
> branch.
> 
> 
> 
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
> [2] http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-07-usb-2.6.32-rc6.patch
>  
> 

Thanks for the update and the patch. I downloaded the launchpad 2.6.31
kernel which I have currently running. Finally found one that outputs to
the LCD.
Regards
Sid.

-- 
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

Re: Is the OMAP patch process badly flawed?

[Felipe Contreras]

On Tue, Nov 17, 2009 at 3:30 PM, Sid Boyce <sboyce@blueyonder.co.uk> wrote:
> I'm curious - I download, build and test kernels on x86 and x86_64
> platforms, -rc, -rc-git and -git all build and run.

[...]

> I would expect patches sent upstream would result in all the basics for
> long established platforms to be fully covered. Appreciating that
> development is quite fast paced with mods and supporting new platforms.
> Could someone please enlighten me?

Previously all the linux-omap work had to be queued through the
linux-arm tree, that made it a bit difficult to push things to the
mainline, but now Tony is sending the pull requests directly to Linus,
so maybe kernels post 2.6.32 will be much better.

However, the only way to make sure that there's good OMAP support in
Linux is for the community to actively test the mainline and make sure
the patches are properly pushed and queued, and regressions are found
quickly, not only on the linux-omap tree, but linux-usb, fbdev, etc.
Unfortunately we haven't done such a great job on that, perhaps
because many people use old "stable" aka "frozen" kernels, but things
are improving.

Cheers.

-- 
Felipe Contreras

Re: Is the OMAP patch process badly flawed?

[Sid Boyce]

On 17/11/09 22:07, Felipe Contreras wrote:
> On Tue, Nov 17, 2009 at 3:30 PM, Sid Boyce <sboyce@blueyonder.co.uk> wrote:
>> I'm curious - I download, build and test kernels on x86 and x86_64
>> platforms, -rc, -rc-git and -git all build and run.
> 
> [...]
> 
>> I would expect patches sent upstream would result in all the basics for
>> long established platforms to be fully covered. Appreciating that
>> development is quite fast paced with mods and supporting new platforms.
>> Could someone please enlighten me?
> 
> Previously all the linux-omap work had to be queued through the
> linux-arm tree, that made it a bit difficult to push things to the
> mainline, but now Tony is sending the pull requests directly to Linus,
> so maybe kernels post 2.6.32 will be much better.
> 
I certainly hope so, it would be nice for the mainline to catch up so we
can work from the one code base.

> However, the only way to make sure that there's good OMAP support in
> Linux is for the community to actively test the mainline and make sure
> the patches are properly pushed and queued, and regressions are found
> quickly, not only on the linux-omap tree, but linux-usb, fbdev, etc.
> Unfortunately we haven't done such a great job on that, perhaps
> because many people use old "stable" aka "frozen" kernels, but things
> are improving.
> 
> Cheers.
> 

Thanks, I use vanilla kernels exclusively on my x86 and x86_64 boxes,
looking for anything that's regressed or broken with API changes.
Regards
Sid.
-- 
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks