LDP support

LDP support

[Russell King - ARM Linux]

Tony, et.al.,

Any ideas when more LDP support will be pushed into mainline (such as
the framebuffer support)?

Thanks.

Re: LDP support

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [090428 15:07]:
> Tony, et.al.,
> 
> Any ideas when more LDP support will be pushed into mainline (such as
> the framebuffer support)?

I'll be looking at the board-*.c patches for the next merge window
hopefully this week or next week.

Looks like LDP keyboard, touchscreen & RTC are pretty much ready
to go. Then the MMC has some regulator updates, but AFAIK the MMC
should work OK already.

For the framebuffer, Imre and Tomi know the status the best, so
I've added them to Cc.

Imre has been meaning to send a bunch of drivers/video/omap changes
to the fbdev list for a while now and LDP framebuffer may depend on
those. Imre, any news on the status of sending the fb patches
upstream?

Then there are the upcoming DSS patches from Tomi, but those still
need some work before they're ready to go.

Regards,

Tony

Re: LDP support

[Koen Kooi]

Op 29 apr 2009 om 00:42 heeft Tony Lindgren <tony@atomide.com> het  
volgende geschreven:\

> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090428 15:07]:
>> Tony, et.al.,
>>
>> Any ideas when more LDP support will be pushed into mainline (such as
>> the framebuffer support)?
>
> I'll be looking at the board-*.c patches for the next merge window
> hopefully this week or next week.
>
> Looks like LDP keyboard, touchscreen

The ts is pretty much unusable in 2.6.29, haven't tried .30rc yet

Regards,

Koen



> & RTC are pretty much ready
> to go. Then the MMC has some regulator updates, but AFAIK the MMC
> should work OK already.
>
> For the framebuffer, Imre and Tomi know the status the best, so
> I've added them to Cc.
>
> Imre has been meaning to send a bunch of drivers/video/omap changes
> to the fbdev list for a while now and LDP framebuffer may depend on
> those. Imre, any news on the status of sending the fb patches
> upstream?
>
> Then there are the upcoming DSS patches from Tomi, but those still
> need some work before they're ready to go.
>
> Regards,
>
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux- 
> omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: LDP support

[Russell King - ARM Linux]

On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090428 15:07]:
> > Tony, et.al.,
> > 
> > Any ideas when more LDP support will be pushed into mainline (such as
> > the framebuffer support)?
> 
> I'll be looking at the board-*.c patches for the next merge window
> hopefully this week or next week.
> 
> Looks like LDP keyboard, touchscreen & RTC are pretty much ready
> to go. Then the MMC has some regulator updates, but AFAIK the MMC
> should work OK already.
> 
> For the framebuffer, Imre and Tomi know the status the best, so
> I've added them to Cc.
> 
> Imre has been meaning to send a bunch of drivers/video/omap changes
> to the fbdev list for a while now and LDP framebuffer may depend on
> those. Imre, any news on the status of sending the fb patches
> upstream?
> 
> Then there are the upcoming DSS patches from Tomi, but those still
> need some work before they're ready to go.

Is there any news on this?  Will we see more functional OMAP3 / LDP
support queued for the next merge window?

Re: LDP support

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [090505 12:52]:
> On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [090428 15:07]:
> > > Tony, et.al.,
> > > 
> > > Any ideas when more LDP support will be pushed into mainline (such as
> > > the framebuffer support)?
> > 
> > I'll be looking at the board-*.c patches for the next merge window
> > hopefully this week or next week.
> > 
> > Looks like LDP keyboard, touchscreen & RTC are pretty much ready
> > to go. Then the MMC has some regulator updates, but AFAIK the MMC
> > should work OK already.
> > 
> > For the framebuffer, Imre and Tomi know the status the best, so
> > I've added them to Cc.
> > 
> > Imre has been meaning to send a bunch of drivers/video/omap changes
> > to the fbdev list for a while now and LDP framebuffer may depend on
> > those. Imre, any news on the status of sending the fb patches
> > upstream?
> > 
> > Then there are the upcoming DSS patches from Tomi, but those still
> > need some work before they're ready to go.
> 
> Is there any news on this?  Will we see more functional OMAP3 / LDP
> support queued for the next merge window?

Yes fro the stuff listed above, but still no news on the framebuffer
patches. Imre?

Tony

[PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Tony Lindgren]

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

* Tony Lindgren <tony@atomide.com> [090505 21:00]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090505 12:52]:
> > On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [090428 15:07]:
> > > > Tony, et.al.,
> > > > 
> > > > Any ideas when more LDP support will be pushed into mainline (such as
> > > > the framebuffer support)?
> > > 
> > > I'll be looking at the board-*.c patches for the next merge window
> > > hopefully this week or next week.
> > > 
> > > Looks like LDP keyboard, touchscreen & RTC are pretty much ready
> > > to go. Then the MMC has some regulator updates, but AFAIK the MMC
> > > should work OK already.
> > > 
> > > For the framebuffer, Imre and Tomi know the status the best, so
> > > I've added them to Cc.
> > > 
> > > Imre has been meaning to send a bunch of drivers/video/omap changes
> > > to the fbdev list for a while now and LDP framebuffer may depend on
> > > those. Imre, any news on the status of sending the fb patches
> > > upstream?
> > > 
> > > Then there are the upcoming DSS patches from Tomi, but those still
> > > need some work before they're ready to go.
> > 
> > Is there any news on this?  Will we see more functional OMAP3 / LDP
> > support queued for the next merge window?
> 
> Yes fro the stuff listed above, but still no news on the framebuffer
> patches. Imre?

Added Stanley Miao to Cc. Here's an updated version of Stanley's patch to
add fb support for LDP.

I don't have an LDP, maybe you guys can give it a try against the mainline
kernel and see if it works! There might be some changes needed to 
drivers/video/omap/dispc.c too.. And those should be handled by Imre.

But if this works, at least we can then add support for few more boards
easily while waiting for Imre to send his updates.

Cheers,

Tony 

[-- Attachment #2: ldp-fb.patch --]
[-- Type: text/x-diff, Size: 11429 bytes --]

commit 6ceeed27b64fab326963a8a867c7549443e7536e
Author: Stanley Miao <stanley.miao@windriver.com>
Date:   Wed May 6 15:09:35 2009 -0700

    OMAP_LDP: Support LCD display as a FB device on ZOOM MDK
    
    Add glue to control the OMAP_LDP LCD as a frame buffer device
    using the existing dispc.c driver under omapfb.
    
    Patch updated for mainline kernel. Note that the
    drivers/video/omap should be updated to pass omap_lcd_config
    in platform_data. The patch should also be updated to compile
    if twl4030 is not selected, and eventually to use the regulator
    framework.
    
    Signed-off-by: Stanley.Miao <stanley.miao@windriver.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/configs/omap_ldp_defconfig b/arch/arm/configs/omap_ldp_defconfig
index 679a4a3..8a979cd 100644
--- a/arch/arm/configs/omap_ldp_defconfig
+++ b/arch/arm/configs/omap_ldp_defconfig
@@ -685,11 +685,16 @@ CONFIG_GPIOLIB=y
 # CONFIG_GPIO_SYSFS is not set
 
 #
+# Memory mapped GPIO expanders:
+#
+
+#
 # I2C GPIO expanders:
 #
 # CONFIG_GPIO_MAX732X is not set
 # CONFIG_GPIO_PCA953X is not set
 # CONFIG_GPIO_PCF857X is not set
+CONFIG_GPIO_TWL4030=y
 
 #
 # PCI GPIO expanders:
@@ -740,12 +745,19 @@ CONFIG_SSB_POSSIBLE=y
 #
 # CONFIG_MFD_CORE is not set
 # CONFIG_MFD_SM501 is not set
+# CONFIG_MFD_ASIC3 is not set
 # CONFIG_HTC_EGPIO is not set
 # CONFIG_HTC_PASIC3 is not set
+# CONFIG_TPS65010 is not set
+CONFIG_TWL4030_CORE=y
 # CONFIG_MFD_TMIO is not set
 # CONFIG_MFD_T7L66XB is not set
 # CONFIG_MFD_TC6387XB is not set
 # CONFIG_MFD_TC6393XB is not set
+# CONFIG_PMIC_DA903X is not set
+# CONFIG_MFD_WM8400 is not set
+# CONFIG_MFD_WM8350_I2C is not set
+# CONFIG_MFD_PCF50633 is not set
 
 #
 # Multimedia devices
@@ -767,8 +779,45 @@ CONFIG_DAB=y
 #
 # CONFIG_VGASTATE is not set
 CONFIG_VIDEO_OUTPUT_CONTROL=m
-# CONFIG_FB is not set
-# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+CONFIG_FB=y
+CONFIG_FIRMWARE_EDID=y
+# 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
+# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
+# CONFIG_FB_SYS_FILLRECT is not set
+# CONFIG_FB_SYS_COPYAREA is not set
+# CONFIG_FB_SYS_IMAGEBLIT is not set
+# CONFIG_FB_FOREIGN_ENDIAN is not set
+# CONFIG_FB_SYS_FOPS is not set
+# CONFIG_FB_SVGALIB is not set
+# CONFIG_FB_MACMODES is not set
+# CONFIG_FB_BACKLIGHT is not set
+CONFIG_FB_MODE_HELPERS=y
+CONFIG_FB_TILEBLITTING=y
+
+#
+# Frame buffer hardware drivers
+#
+# CONFIG_FB_S1D13XXX is not set
+# CONFIG_FB_VIRTUAL is not set
+# CONFIG_FB_METRONOME is not set
+CONFIG_FB_OMAP=y
+CONFIG_FB_OMAP_LCD_VGA=y
+# CONFIG_FB_OMAP_LCDC_EXTERNAL is not set
+# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
+CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=4
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_LCD_CLASS_DEVICE=y
+# CONFIG_LCD_LTV350QV is not set
+# CONFIG_LCD_ILI9320 is not set
+# CONFIG_LCD_TDO24M is not set
+# CONFIG_LCD_VGG2432A4 is not set
+CONFIG_LCD_PLATFORM=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+# CONFIG_BACKLIGHT_CORGI is not set
 
 #
 # Display device support
@@ -780,6 +829,16 @@ CONFIG_VIDEO_OUTPUT_CONTROL=m
 #
 # CONFIG_VGA_CONSOLE is not set
 CONFIG_DUMMY_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
+# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
+# CONFIG_FONTS is not set
+CONFIG_FONT_8x8=y
+CONFIG_FONT_8x16=y
+CONFIG_LOGO=y
+CONFIG_LOGO_LINUX_MONO=y
+CONFIG_LOGO_LINUX_VGA16=y
+CONFIG_LOGO_LINUX_CLUT224=y
 CONFIG_SOUND=y
 CONFIG_SND=y
 # CONFIG_SND_SEQUENCER is not set
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index da57b0f..abbbdfc 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -77,8 +77,14 @@ static struct platform_device ldp_smsc911x_device = {
 	},
 };
 
+static struct platform_device ldp_lcd_device = {
+	.name		= "ldp_lcd",
+	.id		= -1,
+};
+
 static struct platform_device *ldp_devices[] __initdata = {
 	&ldp_smsc911x_device,
+	&ldp_lcd_device,
 };
 
 static inline void __init ldp_init_smsc911x(void)
@@ -122,8 +128,13 @@ static struct omap_uart_config ldp_uart_config __initdata = {
 	.enabled_uarts	= ((1 << 0) | (1 << 1) | (1 << 2)),
 };
 
+static struct omap_lcd_config ldp_lcd_config __initdata = {
+	.ctrl_name	= "internal",
+};
+
 static struct omap_board_config_kernel ldp_config[] __initdata = {
 	{ OMAP_TAG_UART,	&ldp_uart_config },
+	{ OMAP_TAG_LCD,		&ldp_lcd_config },
 };
 
 static struct twl4030_gpio_platform_data ldp_gpio_data = {
diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig
index 4440885..6c86ec0 100644
--- a/drivers/video/omap/Kconfig
+++ b/drivers/video/omap/Kconfig
@@ -7,6 +7,10 @@ config FB_OMAP
 	help
           Frame buffer driver for OMAP based boards.
 
+config FB_OMAP_LCD_VGA
+        bool "Use LCD in VGA mode"
+	  depends on MACH_OMAP_3430SDP || MACH_OMAP_LDP
+
 config FB_OMAP_BOOTLOADER_INIT
 	bool "Check bootloader initialization"
 	depends on FB_OMAP
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index ed13889..a8f5b2e 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -8,6 +8,7 @@ objs-yy := omapfb_main.o
 
 objs-y$(CONFIG_ARCH_OMAP1) += lcdc.o
 objs-y$(CONFIG_ARCH_OMAP2) += dispc.o
+objs-y$(CONFIG_ARCH_OMAP3) += dispc.o
 
 objs-$(CONFIG_ARCH_OMAP1)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += sossi.o
 objs-$(CONFIG_ARCH_OMAP2)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += rfbi.o
@@ -23,6 +24,7 @@ objs-y$(CONFIG_MACH_OMAP_PALMZ71) += lcd_palmz71.o
 objs-$(CONFIG_ARCH_OMAP16XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1610.o
 objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o
 objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
+objs-y$(CONFIG_MACH_OMAP_LDP) += lcd_ldp.o
 
 omapfb-objs := $(objs-yy)
 
diff --git a/drivers/video/omap/lcd_ldp.c b/drivers/video/omap/lcd_ldp.c
new file mode 100644
index 0000000..8925230
--- /dev/null
+++ b/drivers/video/omap/lcd_ldp.c
@@ -0,0 +1,200 @@
+/*
+ * LCD panel support for the TI LDP board
+ *
+ * Copyright (C) 2007 WindRiver
+ * Author: Stanley Miao <stanley.miao@windriver.com>
+ *
+ * Derived from drivers/video/omap/lcd-2430sdp.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/i2c/twl4030.h>
+
+#include <mach/gpio.h>
+#include <mach/mux.h>
+#include <mach/omapfb.h>
+#include <asm/mach-types.h>
+
+#define LCD_PANEL_BACKLIGHT_GPIO 	(15 + OMAP_MAX_GPIO_LINES)
+#define LCD_PANEL_ENABLE_GPIO 		(7 + OMAP_MAX_GPIO_LINES)
+
+#define LCD_PANEL_RESET_GPIO		55
+#define LCD_PANEL_QVGA_GPIO		56
+
+#ifdef CONFIG_FB_OMAP_LCD_VGA
+#define LCD_XRES		480
+#define LCD_YRES		640
+#define LCD_PIXCLOCK_MAX	41700
+#else
+#define LCD_XRES		240
+#define LCD_YRES		320
+#define LCD_PIXCLOCK_MAX	185186
+#endif
+
+#define PM_RECEIVER             TWL4030_MODULE_PM_RECEIVER
+#define ENABLE_VAUX2_DEDICATED  0x09
+#define ENABLE_VAUX2_DEV_GRP    0x20
+#define ENABLE_VAUX3_DEDICATED	0x03
+#define ENABLE_VAUX3_DEV_GRP	0x20
+
+#define ENABLE_VPLL2_DEDICATED          0x05
+#define ENABLE_VPLL2_DEV_GRP            0xE0
+#define TWL4030_VPLL2_DEV_GRP           0x33
+#define TWL4030_VPLL2_DEDICATED         0x36
+
+#define t2_out(c, r, v) twl4030_i2c_write_u8(c, r, v)
+
+
+static int ldp_panel_init(struct lcd_panel *panel,
+				struct omapfb_device *fbdev)
+{
+	gpio_request(LCD_PANEL_RESET_GPIO, "lcd reset");
+	gpio_request(LCD_PANEL_QVGA_GPIO, "lcd qvga");
+	gpio_request(LCD_PANEL_ENABLE_GPIO, "lcd panel");
+	gpio_request(LCD_PANEL_BACKLIGHT_GPIO, "lcd backlight");
+
+	gpio_direction_output(LCD_PANEL_QVGA_GPIO, 0);
+	gpio_direction_output(LCD_PANEL_RESET_GPIO, 0);
+	gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
+	gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 0);
+
+#ifdef CONFIG_FB_OMAP_LCD_VGA
+	gpio_set_value(LCD_PANEL_QVGA_GPIO, 0);
+#else
+	gpio_set_value(LCD_PANEL_QVGA_GPIO, 1);
+#endif
+	gpio_set_value(LCD_PANEL_RESET_GPIO, 1);
+
+	return 0;
+}
+
+static void ldp_panel_cleanup(struct lcd_panel *panel)
+{
+	gpio_free(LCD_PANEL_RESET_GPIO);
+	gpio_free(LCD_PANEL_QVGA_GPIO);
+	gpio_free(LCD_PANEL_ENABLE_GPIO);
+	gpio_free(LCD_PANEL_BACKLIGHT_GPIO);
+}
+
+static int ldp_panel_enable(struct lcd_panel *panel)
+{
+	if (0 != t2_out(PM_RECEIVER, ENABLE_VPLL2_DEDICATED,
+			TWL4030_VPLL2_DEDICATED))
+		return -EIO;
+	if (0 != t2_out(PM_RECEIVER, ENABLE_VPLL2_DEV_GRP,
+			TWL4030_VPLL2_DEV_GRP))
+		return -EIO;
+
+	gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 1);
+	gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 1);
+
+	if (0 != t2_out(PM_RECEIVER, ENABLE_VAUX3_DEDICATED,
+				TWL4030_VAUX3_DEDICATED))
+		return -EIO;
+	if (0 != t2_out(PM_RECEIVER, ENABLE_VAUX3_DEV_GRP,
+				TWL4030_VAUX3_DEV_GRP))
+		return -EIO;
+
+	return 0;
+}
+
+static void ldp_panel_disable(struct lcd_panel *panel)
+{
+	gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
+	gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 0);
+
+	t2_out(PM_RECEIVER, 0x0, TWL4030_VPLL2_DEDICATED);
+	t2_out(PM_RECEIVER, 0x0, TWL4030_VPLL2_DEV_GRP);
+	mdelay(4);
+}
+
+static unsigned long ldp_panel_get_caps(struct lcd_panel *panel)
+{
+	return 0;
+}
+
+struct lcd_panel ldp_panel = {
+	.name		= "ldp",
+	.config		= OMAP_LCDC_PANEL_TFT | OMAP_LCDC_INV_VSYNC |
+			  OMAP_LCDC_INV_HSYNC,
+
+	.bpp		= 16,
+	.data_lines	= 18,
+	.x_res		= LCD_XRES,
+	.y_res		= LCD_YRES,
+	.hsw		= 3,		/* hsync_len (4) - 1 */
+	.hfp		= 3,		/* right_margin (4) - 1 */
+	.hbp		= 39,		/* left_margin (40) - 1 */
+	.vsw		= 1,		/* vsync_len (2) - 1 */
+	.vfp		= 2,		/* lower_margin */
+	.vbp		= 7,		/* upper_margin (8) - 1 */
+
+	.pixel_clock	= LCD_PIXCLOCK_MAX,
+
+	.init		= ldp_panel_init,
+	.cleanup	= ldp_panel_cleanup,
+	.enable		= ldp_panel_enable,
+	.disable	= ldp_panel_disable,
+	.get_caps	= ldp_panel_get_caps,
+};
+
+static int ldp_panel_probe(struct platform_device *pdev)
+{
+	omapfb_register_panel(&ldp_panel);
+	return 0;
+}
+
+static int ldp_panel_remove(struct platform_device *pdev)
+{
+	return 0;
+}
+
+static int ldp_panel_suspend(struct platform_device *pdev, pm_message_t mesg)
+{
+	return 0;
+}
+
+static int ldp_panel_resume(struct platform_device *pdev)
+{
+	return 0;
+}
+
+struct platform_driver ldp_panel_driver = {
+	.probe		= ldp_panel_probe,
+	.remove		= ldp_panel_remove,
+	.suspend	= ldp_panel_suspend,
+	.resume		= ldp_panel_resume,
+	.driver		= {
+		.name	= "ldp_lcd",
+		.owner	= THIS_MODULE,
+	},
+};
+
+static int __init ldp_panel_drv_init(void)
+{
+	return platform_driver_register(&ldp_panel_driver);
+}
+
+static void __exit ldp_panel_drv_exit(void)
+{
+	platform_driver_unregister(&ldp_panel_driver);
+}
+
+module_init(ldp_panel_drv_init);
+module_exit(ldp_panel_drv_exit);

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[stanley.miao]

Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [090505 21:00]:
>   
>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090505 12:52]:
>>     
>>> On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote:
>>>       
>>>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090428 15:07]:
>>>>         
>>>>> Tony, et.al.,
>>>>>
>>>>> Any ideas when more LDP support will be pushed into mainline (such as
>>>>> the framebuffer support)?
>>>>>           
>>>> I'll be looking at the board-*.c patches for the next merge window
>>>> hopefully this week or next week.
>>>>
>>>> Looks like LDP keyboard, touchscreen & RTC are pretty much ready
>>>> to go. Then the MMC has some regulator updates, but AFAIK the MMC
>>>> should work OK already.
>>>>
>>>> For the framebuffer, Imre and Tomi know the status the best, so
>>>> I've added them to Cc.
>>>>
>>>> Imre has been meaning to send a bunch of drivers/video/omap changes
>>>> to the fbdev list for a while now and LDP framebuffer may depend on
>>>> those. Imre, any news on the status of sending the fb patches
>>>> upstream?
>>>>
>>>> Then there are the upcoming DSS patches from Tomi, but those still
>>>> need some work before they're ready to go.
>>>>         
>>> Is there any news on this?  Will we see more functional OMAP3 / LDP
>>> support queued for the next merge window?
>>>       
>> Yes fro the stuff listed above, but still no news on the framebuffer
>> patches. Imre?
>>     
>
> Added Stanley Miao to Cc. Here's an updated version of Stanley's patch to
> add fb support for LDP.
>
> I don't have an LDP, maybe you guys can give it a try against the mainline
> kernel and see if it works! There might be some changes needed to 
> drivers/video/omap/dispc.c too.. And those should be handled by Imre.
>
> But if this works, at least we can then add support for few more boards
> easily while waiting for Imre to send his updates.
>   
Hi, Tony,

Now the kernel can't boot on LDP. The attached file is the boot log.

I will check it when I have  time.

Stanley.

> Cheers,
>
> Tony 
>   

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Russell King - ARM Linux]

On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
> Hi, Tony,
>
> Now the kernel can't boot on LDP. The attached file is the boot log.

No boot log found.

My master branch, based upon 2.6.29-rc3 boots fine on the LDP.

Uncompressing Linux.............................................................
............................................ done, booting the kernel.
Linux version 2.6.29-rc3 (rmk@dyn-67.arm.linux.org.uk) (gcc version 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP LDP board
Memory policy: ECC disabled, Data cache writeback
OMAP3430 ES2.1
SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: console=ttyS2,115200n8 noinitrd mem=128M root=/dev/mmcblk0p2 rw ip=none rootdelay=2 video=omap24xxfb:rotation=270
Clocking rate (Crystal/DPLL/ARM core): 26.0/266/500 MHz
GPMC revision 5.0
IRQ: Found an INTC at 0xd8200000 (revision 4.0) with 96 interrupts
Total of 96 interrupts on 1 active controller
OMAP34xx GPIO hardware version 2.5
PID hash table entries: 512 (order: 9, 2048 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 126292KB available (2964K code, 372K data, 120K init)
Calibrating delay loop... 498.87 BogoMIPS (lpj=1945600)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 296 bytes
NET: Registered protocol family 16
OMAP DMA hardware revision 4.0
USB: No board-specific platform config found
bio: create slab <bio-0> at 0
SCSI subsystem initialized
i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz
twl4030: PIH (irq 7) chaining IRQs 368..375
twl4030: power (irq 373) chaining IRQs 376..383
twl4030: gpio (irq 368) chaining IRQs 384..401
i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz
i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
NET: Registered protocol family 1
NetWinder Floating Point Emulator V0.97 (double precision)
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
msgmni has been set to 246
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
omapfb: configured for panel ldp
omapfb: DISPC version 3.0 initialized
omapfb: Framebuffer initialized. Total vram 614400 planes 1
omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654
serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654
console [ttyS2] enabled
brd: module loaded
loop: module loaded
smsc911x: Driver version 2008-10-21.
smsc911x-mdio: probed
eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=ffffffff:01, irq=-1)
net eth0: MAC Address: 00:08:ee:02:24:b2
Driver 'sd' needs updating - please use bus_type methods
twl4030_rtc twl4030_rtc: rtc core: registered twl4030_rtc as rtc0
twl4030_rtc twl4030_rtc: Power up reset detected.
twl4030_rtc twl4030_rtc: Enabling TWL4030-RTC.
i2c /dev entries driver
Driver for 1-wire Dallas network protocol.
OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
Advanced Linux Sound Architecture Driver Version 1.0.18a.
No device for DAI AD73311
No device for DAI AK4535
No device for DAI CS4270
No device for DAI PCM3008 HiFi
No device for DAI SSM2602
No device for DAI tlv320aic23
No device for DAI tlv320aic3x
No device for DAI twl4030
No device for DAI UDA134X
No device for DAI UDA1380
No device for DAI UDA1380
No device for DAI UDA1380
No device for DAI WM8510 HiFi
No device for DAI WM8580 PAIFRX
No device for DAI WM8580 PAIFTX
No device for DAI WM8728
No device for DAI WM8731
No device for DAI WM8750
No device for DAI WM8971
No device for DAI WM8990 ADC/DAC Primary
ALSA device list:
  No soundcards found.
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800)
Waiting 2sec before mounting root device...
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new high speed SD card at address 0002
mmcblk0: mmc0:0002 00000 971 MiB 
 mmcblk0: p1 p2
kjournald starting.  Commit interval 5 seconds
EXT3-fs warning: mounting fs with errors, running e2fsck is recommended
EXT3 FS on mmcblk0p2, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) on device 179:2.
Freeing init memory: 120K
INIT: version 2.86 booting
.udev/ already exists on the static /dev!
Starting the hotplug events dispatcher udevd
Synthesizing the initial hotplug events
...

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [090507 09:19]:
> On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
> > Hi, Tony,
> >
> > Now the kernel can't boot on LDP. The attached file is the boot log.
> 
> No boot log found.
> 
> My master branch, based upon 2.6.29-rc3 boots fine on the LDP.
> 
> Uncompressing Linux.............................................................
> ............................................ done, booting the kernel.
> Linux version 2.6.29-rc3 (rmk@dyn-67.arm.linux.org.uk) (gcc version 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009

<snip snip>

> omapfb: configured for panel ldp
> omapfb: DISPC version 3.0 initialized
> omapfb: Framebuffer initialized. Total vram 614400 planes 1
> omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz

Can you see the penguin?

Tony

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Russell King - ARM Linux]

On Thu, May 07, 2009 at 09:28:34AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090507 09:19]:
> > On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
> > > Hi, Tony,
> > >
> > > Now the kernel can't boot on LDP. The attached file is the boot log.
> > 
> > No boot log found.
> > 
> > My master branch, based upon 2.6.29-rc3 boots fine on the LDP.
> > 
> > Uncompressing Linux.............................................................
> > ............................................ done, booting the kernel.
> > Linux version 2.6.29-rc3 (rmk@dyn-67.arm.linux.org.uk) (gcc version 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009
> 
> <snip snip>
> 
> > omapfb: configured for panel ldp
> > omapfb: DISPC version 3.0 initialized
> > omapfb: Framebuffer initialized. Total vram 614400 planes 1
> > omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz
> 
> Can you see the penguin?

Interestingly, CONFIG_FB is not set, so I'm not sure why we have a
framebuffer driver.

Ah, hmm.  Oh sod it, what kernel am I booting.  Oh, it's an ages
old one.  Fucking $#^"$#^%$^#"^^"%#%^5268903284769065983 UBOOT.

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Russell King - ARM Linux]

On Thu, May 07, 2009 at 05:34:05PM +0100, Russell King - ARM Linux wrote:
> On Thu, May 07, 2009 at 09:28:34AM -0700, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [090507 09:19]:
> > > On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
> > > > Hi, Tony,
> > > >
> > > > Now the kernel can't boot on LDP. The attached file is the boot log.
> > > 
> > > No boot log found.
> > > 
> > > My master branch, based upon 2.6.29-rc3 boots fine on the LDP.
> > > 
> > > Uncompressing Linux.............................................................
> > > ............................................ done, booting the kernel.
> > > Linux version 2.6.29-rc3 (rmk@dyn-67.arm.linux.org.uk) (gcc version 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009
> > 
> > <snip snip>
> > 
> > > omapfb: configured for panel ldp
> > > omapfb: DISPC version 3.0 initialized
> > > omapfb: Framebuffer initialized. Total vram 614400 planes 1
> > > omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz
> > 
> > Can you see the penguin?
> 
> Interestingly, CONFIG_FB is not set, so I'm not sure why we have a
> framebuffer driver.
> 
> Ah, hmm.  Oh sod it, what kernel am I booting.  Oh, it's an ages
> old one.  Fucking $#^"$#^%$^#"^^"%#%^5268903284769065983 UBOOT.

Sod it, I'm not going to bother with this crap with its stupidly long
build times because of bloated gcc4 requirements this side of my holiday.
I've better things to be doing like washing the car.

So you're on your own with LDP support for the next 9 days.  So this
email marks the end of my pre-holiday Linux involvement.

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [090507 09:37]:
> On Thu, May 07, 2009 at 05:34:05PM +0100, Russell King - ARM Linux wrote:
> > On Thu, May 07, 2009 at 09:28:34AM -0700, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [090507 09:19]:
> > > > On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
> > > > > Hi, Tony,
> > > > >
> > > > > Now the kernel can't boot on LDP. The attached file is the boot log.
> > > > 
> > > > No boot log found.
> > > > 
> > > > My master branch, based upon 2.6.29-rc3 boots fine on the LDP.
> > > > 
> > > > Uncompressing Linux.............................................................
> > > > ............................................ done, booting the kernel.
> > > > Linux version 2.6.29-rc3 (rmk@dyn-67.arm.linux.org.uk) (gcc version 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009
> > > 
> > > <snip snip>
> > > 
> > > > omapfb: configured for panel ldp
> > > > omapfb: DISPC version 3.0 initialized
> > > > omapfb: Framebuffer initialized. Total vram 614400 planes 1
> > > > omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz
> > > 
> > > Can you see the penguin?
> > 
> > Interestingly, CONFIG_FB is not set, so I'm not sure why we have a
> > framebuffer driver.
> > 
> > Ah, hmm.  Oh sod it, what kernel am I booting.  Oh, it's an ages
> > old one.  Fucking $#^"$#^%$^#"^^"%#%^5268903284769065983 UBOOT.
> 
> Sod it, I'm not going to bother with this crap with its stupidly long
> build times because of bloated gcc4 requirements this side of my holiday.
> I've better things to be doing like washing the car.
> 
> So you're on your own with LDP support for the next 9 days.  So this
> email marks the end of my pre-holiday Linux involvement.

Happy holidays :) We'll get the LDP patches ready by the time you're back.

Tony

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Koen Kooi]

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


Op 7 mei 2009, om 18:28 heeft Tony Lindgren het volgende geschreven:

> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090507 09:19]:
>> On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
>>> Hi, Tony,
>>>
>>> Now the kernel can't boot on LDP. The attached file is the boot log.
>>
>> No boot log found.
>>
>> My master branch, based upon 2.6.29-rc3 boots fine on the LDP.
>>
>> Uncompressing  
>> Linux.............................................................
>> ............................................ done, booting the  
>> kernel.
>> Linux version 2.6.29-rc3 (rmk@dyn-67.arm.linux.org.uk) (gcc version  
>> 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009
>
> <snip snip>
>
>> omapfb: configured for panel ldp
>> omapfb: DISPC version 3.0 initialized
>> omapfb: Framebuffer initialized. Total vram 614400 planes 1
>> omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz
>
> Can you see the penguin?

2.6.29 does this on my zoom:

http://www.flickr.com/photos/koenkooi/3406819626/

Boots into X and all :) That's with DSS1, not Tomi's DSS2. As I said  
earlier, the touchscreen is unusable.

regards,

Koen



[-- Attachment #2: Dit deel van het bericht is digitaal ondertekend --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Tony Lindgren]

* Koen Kooi <koen@dominion.thruhere.net> [090507 09:57]:
>
> Op 7 mei 2009, om 18:28 heeft Tony Lindgren het volgende geschreven:
>
>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090507 09:19]:
>>> On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
>>>> Hi, Tony,
>>>>
>>>> Now the kernel can't boot on LDP. The attached file is the boot log.
>>>
>>> No boot log found.
>>>
>>> My master branch, based upon 2.6.29-rc3 boots fine on the LDP.
>>>
>>> Uncompressing  
>>> Linux.............................................................
>>> ............................................ done, booting the  
>>> kernel.
>>> Linux version 2.6.29-rc3 (rmk@dyn-67.arm.linux.org.uk) (gcc version  
>>> 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009
>>
>> <snip snip>
>>
>>> omapfb: configured for panel ldp
>>> omapfb: DISPC version 3.0 initialized
>>> omapfb: Framebuffer initialized. Total vram 614400 planes 1
>>> omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz
>>
>> Can you see the penguin?
>
> 2.6.29 does this on my zoom:
>
> http://www.flickr.com/photos/koenkooi/3406819626/
>
> Boots into X and all :) That's with DSS1, not Tomi's DSS2. As I said  
> earlier, the touchscreen is unusable.

Good to hear. What patches do you have applied?

What exactly is wrong with the touchscreen? Got any patches for that?

Regards,

Tony

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Koen Kooi]

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


Op 7 mei 2009, om 19:18 heeft Tony Lindgren het volgende geschreven:

> * Koen Kooi <koen@dominion.thruhere.net> [090507 09:57]:
>>
>> Op 7 mei 2009, om 18:28 heeft Tony Lindgren het volgende geschreven:
>>
>>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090507 09:19]:
>>>> On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
>>>>> Hi, Tony,
>>>>>
>>>>> Now the kernel can't boot on LDP. The attached file is the boot  
>>>>> log.
>>>>
>>>> No boot log found.
>>>>
>>>> My master branch, based upon 2.6.29-rc3 boots fine on the LDP.
>>>>
>>>> Uncompressing
>>>> Linux.............................................................
>>>> ............................................ done, booting the
>>>> kernel.
>>>> Linux version 2.6.29-rc3 (rmk@dyn-67.arm.linux.org.uk) (gcc version
>>>> 4.3.2 (GCC)) #125 Mon Feb 2 22:22:54 GMT 2009
>>>
>>> <snip snip>
>>>
>>>> omapfb: configured for panel ldp
>>>> omapfb: DISPC version 3.0 initialized
>>>> omapfb: Framebuffer initialized. Total vram 614400 planes 1
>>>> omapfb: Pixclock 32000 kHz hfreq 60.3 kHz vfreq 93.7 Hz
>>>
>>> Can you see the penguin?
>>
>> 2.6.29 does this on my zoom:
>>
>> http://www.flickr.com/photos/koenkooi/3406819626/
>>
>> Boots into X and all :) That's with DSS1, not Tomi's DSS2. As I said
>> earlier, the touchscreen is unusable.
>
> Good to hear. What patches do you have applied?

None relating to DSS1, the rest are DSS2 patches (not enabled in  
defconfig), musb patches, etc.

> What exactly is wrong with the touchscreen?

It seems to have a reduced resolution with lots of noise, tslib is  
unable to calibrate it to a usable state. It might be the mcspi  
problem the evm had (has?) all over again, haven't looked into that.

> Got any patches for that?

none, sorry.

regards,

Koen

>
> Regards,
>
> Tony


[-- Attachment #2: Dit deel van het bericht is digitaal ondertekend --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Tony Lindgren]

* stanley.miao <stanley.miao@windriver.com> [090507 07:59]:
> Tony Lindgren wrote:
>> * Tony Lindgren <tony@atomide.com> [090505 21:00]:
>>   
>>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090505 12:52]:
>>>     
>>>> On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote:
>>>>       
>>>>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090428 15:07]:
>>>>>         
>>>>>> Tony, et.al.,
>>>>>>
>>>>>> Any ideas when more LDP support will be pushed into mainline (such as
>>>>>> the framebuffer support)?
>>>>>>           
>>>>> I'll be looking at the board-*.c patches for the next merge window
>>>>> hopefully this week or next week.
>>>>>
>>>>> Looks like LDP keyboard, touchscreen & RTC are pretty much ready
>>>>> to go. Then the MMC has some regulator updates, but AFAIK the MMC
>>>>> should work OK already.
>>>>>
>>>>> For the framebuffer, Imre and Tomi know the status the best, so
>>>>> I've added them to Cc.
>>>>>
>>>>> Imre has been meaning to send a bunch of drivers/video/omap changes
>>>>> to the fbdev list for a while now and LDP framebuffer may depend on
>>>>> those. Imre, any news on the status of sending the fb patches
>>>>> upstream?
>>>>>
>>>>> Then there are the upcoming DSS patches from Tomi, but those still
>>>>> need some work before they're ready to go.
>>>>>         
>>>> Is there any news on this?  Will we see more functional OMAP3 / LDP
>>>> support queued for the next merge window?
>>>>       
>>> Yes fro the stuff listed above, but still no news on the framebuffer
>>> patches. Imre?
>>>     
>>
>> Added Stanley Miao to Cc. Here's an updated version of Stanley's patch to
>> add fb support for LDP.
>>
>> I don't have an LDP, maybe you guys can give it a try against the mainline
>> kernel and see if it works! There might be some changes needed to  
>> drivers/video/omap/dispc.c too.. And those should be handled by Imre.
>>
>> But if this works, at least we can then add support for few more boards
>> easily while waiting for Imre to send his updates.
>>   
> Hi, Tony,
>
> Now the kernel can't boot on LDP. The attached file is the boot log.
>
> I will check it when I have  time.

Looks like the get_dss_clocks() in dispc.c at least needs updating for
omap3. It should use clkdev too now btw.

Tony

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[stanley.miao]

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

Russell King - ARM Linux wrote:
> On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
>   
>> Hi, Tony,
>>
>> Now the kernel can't boot on LDP. The attached file is the boot log.
>>     
>
> No boot log found.
>
>
>   
Sorry, forgot to attach the boot log.

It is linux-omap master branch.

Stanley.



[-- Attachment #2: ldp_boot_log.txt --]
[-- Type: text/plain, Size: 1733 bytes --]

Uncompressing Linux.................................................................................................................... done, booting the kernel.
<5>Linux version 2.6.30-rc4-omap1-05873-g2489dcb (stanley@stanley-desktop) (gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-53)) #1 Thu May 7 22:52:12 CST9
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP LDP board
Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 32768
<7>free_area_init_node: node 0, pgdat c038db50, node_mem_map c03a9000
<7>  Normal zone: 256 pages used for memmap
<7>  Normal zone: 0 pages reserved
<7>  Normal zone: 32512 pages, LIFO batch:7
<6>OMAP3430 ES2.1
<6>SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
<5>Kernel command line: root=/dev/nfs rw nfsroot=128.224.163.169:/export/rootfs console=ttyS2,115200n8 mem=128M ip=128.224.163.125:128.224.163.169:128.224.162.1:25}
<6>NR_IRQS:402
<6>Clocking rate (Crystal/DPLL/ARM core): 26.0/266/500 MHz
<6>GPMC revision 5.0
<6>IRQ: Found an INTC at 0xd8200000 (revision 4.0) with 96 interrupts
<6>Total of 96 interrupts on 1 active controller
<6>OMAP34xx GPIO hardware version 2.5
PID hash table entries: 512 (order: 9, 2048 bytes)
<6>OMAP clockevent source: GPTIMER1 at 32768 Hz
Console: colour dummy device 80x30
<6>Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
<6>Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
<6>Memory: 128MB = 128MB total
<5>Memory: 126036KB available (3176K code, 292K data, 132K init, 0K highmem)
<6>Calibrating delay loop... 

RE: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Gadiyar, Anand]

Stanley.miao wrote:
> Russell King - ARM Linux wrote:
> > On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
> >   
> >> Hi, Tony,
> >>
> >> Now the kernel can't boot on LDP. The attached file is the boot log.
> >>     
> >
> > No boot log found.
> >
> >
> >   
> Sorry, forgot to attach the boot log.
> 
> It is linux-omap master branch.
> 
> Stanley.

Looks like you used the CodeSourcery 2007q3 toolchain. This had been
reported earlier. Switching to 2008q3 works.

- Anand

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[stanley.miao]

Gadiyar, Anand wrote:
> Stanley.miao wrote:
>   
>> Russell King - ARM Linux wrote:
>>     
>>> On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
>>>   
>>>       
>>>> Hi, Tony,
>>>>
>>>> Now the kernel can't boot on LDP. The attached file is the boot log.
>>>>     
>>>>         
>>> No boot log found.
>>>
>>>
>>>   
>>>       
>> Sorry, forgot to attach the boot log.
>>
>> It is linux-omap master branch.
>>
>> Stanley.
>>     
>
> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
> reported earlier. Switching to 2008q3 works.
>
> - Anand
>
>
>
>   
Yeah, Now the kernel booted. it's compiler's problem.

Linux version 2.6.30-rc4-omap1-05873-g2489dcb (stanley@stanley-desktop) 
(gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #2 Fri May 8 17:06:34 
CST 2009
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP LDP board


Hi, Tony,

LCD still works.
The code I tested is the master branch of linux-omap. Is it right ?

Stanley.

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Tony Lindgren]

* stanley.miao <stanley.miao@windriver.com> [090508 02:15]:
> Gadiyar, Anand wrote:
>> Stanley.miao wrote:
>>   
>>> Russell King - ARM Linux wrote:
>>>     
>>>> On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
>>>>         
>>>>> Hi, Tony,
>>>>>
>>>>> Now the kernel can't boot on LDP. The attached file is the boot log.
>>>>>             
>>>> No boot log found.
>>>>
>>>>
>>>>         
>>> Sorry, forgot to attach the boot log.
>>>
>>> It is linux-omap master branch.
>>>
>>> Stanley.
>>>     
>>
>> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
>> reported earlier. Switching to 2008q3 works.
>>
>> - Anand
>>
>>
>>
>>   
> Yeah, Now the kernel booted. it's compiler's problem.
>
> Linux version 2.6.30-rc4-omap1-05873-g2489dcb (stanley@stanley-desktop)  
> (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #2 Fri May 8 17:06:34  
> CST 2009
> CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f
> CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> Machine: OMAP LDP board
>
>
> Hi, Tony,
>
> LCD still works.
> The code I tested is the master branch of linux-omap. Is it right ?

Well the goal here is to get the mainline code to work for the LCD.

I'll post few patches for you to test after trying them out on 3430sdp.

Regards,

Tony

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Kalle Valo]

"stanley.miao" <stanley.miao@windriver.com> writes:

>> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
>> reported earlier. Switching to 2008q3 works.
>
> Yeah, Now the kernel booted. it's compiler's problem.

I was bitten by the same problem few weeks ago. Any chance of getting a
warning/error if using 2007q3 compiler until the problem is fixed?

-- 
Kalle Valo

Re: LDP support

[Imre Deak]

On Wed, May 06, 2009 at 06:00:16AM +0200, ext Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090505 12:52]:
> > On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [090428 15:07]:
> > > > Tony, et.al.,
> > > > 
> > > > Any ideas when more LDP support will be pushed into mainline (such as
> > > > the framebuffer support)?
> > > 
> > > I'll be looking at the board-*.c patches for the next merge window
> > > hopefully this week or next week.
> > > 
> > > Looks like LDP keyboard, touchscreen & RTC are pretty much ready
> > > to go. Then the MMC has some regulator updates, but AFAIK the MMC
> > > should work OK already.
> > > 
> > > For the framebuffer, Imre and Tomi know the status the best, so
> > > I've added them to Cc.
> > > 
> > > Imre has been meaning to send a bunch of drivers/video/omap changes
> > > to the fbdev list for a while now and LDP framebuffer may depend on
> > > those. Imre, any news on the status of sending the fb patches
> > > upstream?
> > > 
> > > Then there are the upcoming DSS patches from Tomi, but those still
> > > need some work before they're ready to go.
> > 
> > Is there any news on this?  Will we see more functional OMAP3 / LDP
> > support queued for the next merge window?
> 
> Yes fro the stuff listed above, but still no news on the framebuffer
> patches. Imre?

There is a mainline based tree with the missing DSS1 FB stuff that I'm
planning to submit to fb-devel:

git clone git://koowaldah.org/people/imre/linux-2.6-fb

I could only compile test it for OMAP2/3 targets, it would be nice
if someone could check if it works too. Also if some DSS1 FB related things
are still missing from that tree, I could add them / submit them with
the rest of the things.

Sorry for the big delay.

--Imre

Re: LDP support

[Tony Lindgren]

* Imre Deak <imre.deak@nokia.com> [090514 02:09]:
> On Wed, May 06, 2009 at 06:00:16AM +0200, ext Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [090505 12:52]:
> > > On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote:
> > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [090428 15:07]:
> > > > > Tony, et.al.,
> > > > > 
> > > > > Any ideas when more LDP support will be pushed into mainline (such as
> > > > > the framebuffer support)?
> > > > 
> > > > I'll be looking at the board-*.c patches for the next merge window
> > > > hopefully this week or next week.
> > > > 
> > > > Looks like LDP keyboard, touchscreen & RTC are pretty much ready
> > > > to go. Then the MMC has some regulator updates, but AFAIK the MMC
> > > > should work OK already.
> > > > 
> > > > For the framebuffer, Imre and Tomi know the status the best, so
> > > > I've added them to Cc.
> > > > 
> > > > Imre has been meaning to send a bunch of drivers/video/omap changes
> > > > to the fbdev list for a while now and LDP framebuffer may depend on
> > > > those. Imre, any news on the status of sending the fb patches
> > > > upstream?
> > > > 
> > > > Then there are the upcoming DSS patches from Tomi, but those still
> > > > need some work before they're ready to go.
> > > 
> > > Is there any news on this?  Will we see more functional OMAP3 / LDP
> > > support queued for the next merge window?
> > 
> > Yes fro the stuff listed above, but still no news on the framebuffer
> > patches. Imre?
> 
> There is a mainline based tree with the missing DSS1 FB stuff that I'm
> planning to submit to fb-devel:
> 
> git clone git://koowaldah.org/people/imre/linux-2.6-fb
> 
> I could only compile test it for OMAP2/3 targets, it would be nice
> if someone could check if it works too. Also if some DSS1 FB related things
> are still missing from that tree, I could add them / submit them with
> the rest of the things.
> 
> Sorry for the big delay.

Great, I've started mirroring this as omapfb-upstream branch in the linux-omap
tree for easy testing.

Looks like your patch "ARM: OMAP: NOKIA-770: Add support for HWA742 LCD controller"
needs fixing to just pass the clocks to the LCD driver as discussed in
the recent 770 thread.

Also your patch "ARM: OMAP: FB: Add OMAP3 DISPC support" will be obsolete,
I have a fix in my omap-fixes queue that solves the problem with clkdev.

Regards,

Tony

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Russell King - ARM Linux]

On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote:
> "stanley.miao" <stanley.miao@windriver.com> writes:
> 
> >> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
> >> reported earlier. Switching to 2008q3 works.
> >
> > Yeah, Now the kernel booted. it's compiler's problem.
> 
> I was bitten by the same problem few weeks ago. Any chance of getting a
> warning/error if using 2007q3 compiler until the problem is fixed?

Is there any way of detecting the 2007q3 compiler?

With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and
__GNUC_PATCHLEVEL__ to identify the three digit version number.

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Kalle Valo]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote:
>> "stanley.miao" <stanley.miao@windriver.com> writes:
>> 
>> >> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
>> >> reported earlier. Switching to 2008q3 works.
>> >
>> > Yeah, Now the kernel booted. it's compiler's problem.
>> 
>> I was bitten by the same problem few weeks ago. Any chance of getting a
>> warning/error if using 2007q3 compiler until the problem is fixed?
>
> Is there any way of detecting the 2007q3 compiler?
>
> With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and
> __GNUC_PATCHLEVEL__ to identify the three digit version number.

I don't know, most probably not. But Jon Hunter investigated the issue
and he found the issue was related to CONFIG_ARCH_WANT_FRAME_POINTERS:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12403.html

So maybe we can fix or workaround this.

-- 
Kalle Valo

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Russell King - ARM Linux]

On Mon, May 18, 2009 at 06:54:56PM +0300, Kalle Valo wrote:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> 
> > On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote:
> >> "stanley.miao" <stanley.miao@windriver.com> writes:
> >> 
> >> >> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
> >> >> reported earlier. Switching to 2008q3 works.
> >> >
> >> > Yeah, Now the kernel booted. it's compiler's problem.
> >> 
> >> I was bitten by the same problem few weeks ago. Any chance of getting a
> >> warning/error if using 2007q3 compiler until the problem is fixed?
> >
> > Is there any way of detecting the 2007q3 compiler?
> >
> > With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and
> > __GNUC_PATCHLEVEL__ to identify the three digit version number.
> 
> I don't know, most probably not. But Jon Hunter investigated the issue
> and he found the issue was related to CONFIG_ARCH_WANT_FRAME_POINTERS:
> 
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12403.html
> 
> So maybe we can fix or workaround this.

Why does this change anything?  FRAME_POINTERS seems to be enabled
anyway (and should be given the Kconfig setup we have.)

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Kevin Hilman]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> On Mon, May 18, 2009 at 06:54:56PM +0300, Kalle Valo wrote:
>> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>> 
>> > On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote:
>> >> "stanley.miao" <stanley.miao@windriver.com> writes:
>> >> 
>> >> >> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
>> >> >> reported earlier. Switching to 2008q3 works.
>> >> >
>> >> > Yeah, Now the kernel booted. it's compiler's problem.
>> >> 
>> >> I was bitten by the same problem few weeks ago. Any chance of getting a
>> >> warning/error if using 2007q3 compiler until the problem is fixed?
>> >
>> > Is there any way of detecting the 2007q3 compiler?
>> >
>> > With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and
>> > __GNUC_PATCHLEVEL__ to identify the three digit version number.
>> 
>> I don't know, most probably not. But Jon Hunter investigated the issue
>> and he found the issue was related to CONFIG_ARCH_WANT_FRAME_POINTERS:
>> 
>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12403.html
>> 
>> So maybe we can fix or workaround this.
>
> Why does this change anything?  FRAME_POINTERS seems to be enabled
> anyway (and should be given the Kconfig setup we have.)

See the 'depends on' line in lib/Kconfig.debug.  The result is that
without the patch from Jon, even if you have CONFIG_FRAME_POINTERS=y
in your .config, it gets dropped if the arch doesn't set
CONFIG_ARCH_WANT_FRAME_POINTERS.

Kevin

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Russell King - ARM Linux]

On Mon, May 18, 2009 at 10:13:55AM -0700, Kevin Hilman wrote:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> 
> > On Mon, May 18, 2009 at 06:54:56PM +0300, Kalle Valo wrote:
> >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> >> 
> >> > On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote:
> >> >> "stanley.miao" <stanley.miao@windriver.com> writes:
> >> >> 
> >> >> >> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
> >> >> >> reported earlier. Switching to 2008q3 works.
> >> >> >
> >> >> > Yeah, Now the kernel booted. it's compiler's problem.
> >> >> 
> >> >> I was bitten by the same problem few weeks ago. Any chance of getting a
> >> >> warning/error if using 2007q3 compiler until the problem is fixed?
> >> >
> >> > Is there any way of detecting the 2007q3 compiler?
> >> >
> >> > With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and
> >> > __GNUC_PATCHLEVEL__ to identify the three digit version number.
> >> 
> >> I don't know, most probably not. But Jon Hunter investigated the issue
> >> and he found the issue was related to CONFIG_ARCH_WANT_FRAME_POINTERS:
> >> 
> >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12403.html
> >> 
> >> So maybe we can fix or workaround this.
> >
> > Why does this change anything?  FRAME_POINTERS seems to be enabled
> > anyway (and should be given the Kconfig setup we have.)
> 
> See the 'depends on' line in lib/Kconfig.debug.  The result is that
> without the patch from Jon, even if you have CONFIG_FRAME_POINTERS=y
> in your .config, it gets dropped if the arch doesn't set
> CONFIG_ARCH_WANT_FRAME_POINTERS.

Well, two things.

1. We don't want to force frame pointers on if unwinding support is enabled.

2. The lib/Kconfig.debug entry is overridden by ARM's own version in
   arch/arm/Kconfig.debug.  I've added samr into the discussion since
   he created this.

arch/arm/Kconfig.debug:

# RMK wants arm kernels compiled with frame pointers or stack unwinding.
# If you know what you are doing and are willing to live without stack
# traces, you can get a slightly smaller kernel by setting this option to
# n, but then RMK will have to kill you ;).
config FRAME_POINTER
        bool
        default y if !ARM_UNWIND
        help
          If you say N here, the resulting kernel will be slightly smaller and
          faster. However, if neither FRAME_POINTER nor ARM_UNWIND are enabled,
          when a problem occurs with the kernel, the information that is
          reported is severely limited.

And lib/Kconfig.debug:

config FRAME_POINTER
        bool "Compile the kernel with frame pointers"
        depends on DEBUG_KERNEL && \
                (CRIS || M68K || M68KNOMMU || FRV || UML || \
                 AVR32 || SUPERH || BLACKFIN || MN10300) || \
                ARCH_WANT_FRAME_POINTERS
        default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
        help
          If you say Y here the resulting kernel image will be slightly
          larger and slower, but it gives very useful debugging information
          in case of kernel bugs. (precise oopses/stacktraces/warnings)

this still results in frame pointers being enabled.  This is because the
ARM version follows the one in lib/, it overrides it rather than
supplementing the generic version.  I've just checked that by adding
'n &&' to that depends on line in lib/Kconfig.debug, and making oldconfig.
I still end up with FRAME_POINTER=y in my configs.  However, if I stub out
the 'default y' line in arch/arm/Kconfig.debug, it goes away.

So I think setting ARCH_WANT_FRAME_POINTERS will be ineffectual.

Moreover, I don't think forcing frame pointers to be enabled even with
unwinding support is the right solution - if we have frame pointers
there's no need for unwind support (so maybe the right answer is to
force unwind support off for the time being?)

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

[Jon Hunter]

Russell King - ARM Linux wrote:
> Moreover, I don't think forcing frame pointers to be enabled even with
> unwinding support is the right solution - if we have frame pointers
> there's no need for unwind support (so maybe the right answer is to
> force unwind support off for the time being?)

Ok, so I have tested this and if we add the following to the omap 
defconfigs then this will enable frame pointers and disable unwinding 
support. Hence, this should avoid the problems seen with the 2007q3 code 
sourcery compiler.

# CONFIG_ARM_UNWIND is not set

Tony, would this be ok with you?

Russell, sorry I did not see this thread earlier.

Jon

Re: LDP support

[Russell King - ARM Linux]

On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090428 15:07]:
> > Tony, et.al.,
> > 
> > Any ideas when more LDP support will be pushed into mainline (such as
> > the framebuffer support)?
> 
> I'll be looking at the board-*.c patches for the next merge window
> hopefully this week or next week.
> 
> Looks like LDP keyboard, touchscreen & RTC are pretty much ready
> to go. Then the MMC has some regulator updates, but AFAIK the MMC
> should work OK already.
> 
> For the framebuffer, Imre and Tomi know the status the best, so
> I've added them to Cc.
> 
> Imre has been meaning to send a bunch of drivers/video/omap changes
> to the fbdev list for a while now and LDP framebuffer may depend on
> those. Imre, any news on the status of sending the fb patches
> upstream?
> 
> Then there are the upcoming DSS patches from Tomi, but those still
> need some work before they're ready to go.

Okay, now that I've merged your tree, we've moved a few steps forward but
a couple of steps backward with LDP support:

1. LDP LCD platform device added
2. GPIO keyboard platform data added
3. TWL4030 keyboard platform data added
4. TSC2046 touchscreen platform data added
5. MMC has regressed - no sign of the driver initializing, not even an
   error message from it, so I can't boot to check what the status of
   these are.
6. do ___NOT___ (underscored in triplicate and 500ft high letters) enable
   ARM errata 460075 - it solidly prevents the kernel booting on LDP.
   (it's taken many hours to debug that.)

However, things that still seem to be missing:

1. GPIO keyboard (presumably) needs to be enabled in omap_ldp_defconfig
2. No TWL4030 keyboard driver merged (not even in linux-next)
3. No LDP LCD driver merged
4. No OMAP3 video driver
5. No sound?

Any ideas what's happening with these?  Will they make the next merge
window (which is possibly about a week away) - I guess not. :(

RE: LDP support

[Woodruff, Richard]

> 6. do ___NOT___ (underscored in triplicate and 500ft high letters) enable
>    ARM errata 460075 - it solidly prevents the kernel booting on LDP.
>    (it's taken many hours to debug that.)

This is an r2p0 errata only.  It's not in earlier versions or in later cores.

Today there are only r1pX OMAP3s today.  In the future there will be r3px also.

Regards,
Regards,
Richard W.

Re: LDP support

[Felipe Balbi]

On Sun, May 31, 2009 at 11:24:49PM +0200, ext Russell King - ARM Linux wrote:
> 2. No TWL4030 keyboard driver merged (not even in linux-next)

I recall David Brownell sending this one via linux-input. Don't know the
status though.

-- 
balbi

Re: LDP support

[Russell King - ARM Linux]

On Sun, May 31, 2009 at 07:24:19PM -0500, Woodruff, Richard wrote:
> > 6. do ___NOT___ (underscored in triplicate and 500ft high letters) enable
> >    ARM errata 460075 - it solidly prevents the kernel booting on LDP.
> >    (it's taken many hours to debug that.)
> 
> This is an r2p0 errata only.  It's not in earlier versions or in later cores.

Yes.

> Today there are only r1pX OMAP3s today.  In the future there will be r3px
> also.

That's something that TI may know, but it's almost impossible for developers
to know because:

(a) the OMAP3430 TRMs aren't available.
(b) you have to reverse engineer the ARM ID register using the ARM Cortex
A8 TRMs to find out that the 'variant' field describes the number after
'r' and the 'revision' field describes the number after the 'p', and then
looking at the ID value reported by the kernel for the OMAP3430 in the
LDP, you find that it's an undocumented r1p2 version.

So it's all very well specifying that errata N applies to some random
variants and revisions of the CPU, but that's insufficient for developers
who'll be configuring the kernel.

As said on linux-arm-kernel, we need the kernel to only apply these errata
fixes to the CPUs which they are applicable to if enabled, rather than
every CPU.  I provided a patch to do this, and this enables LDP to boot
with all errata config options enabled.

RE: LDP support

[Woodruff, Richard]

> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Monday, June 01, 2009 2:45 AM

> On Sun, May 31, 2009 at 07:24:19PM -0500, Woodruff, Richard wrote:
> > > 6. do ___NOT___ (underscored in triplicate and 500ft high letters) enable
> > >    ARM errata 460075 - it solidly prevents the kernel booting on LDP.
> > >    (it's taken many hours to debug that.)
> >
> > This is an r2p0 errata only.  It's not in earlier versions or in later cores.
>
> Yes.
>
> > Today there are only r1pX OMAP3s today.  In the future there will be r3px
> > also.
>
> That's something that TI may know, but it's almost impossible for developers
> to know because:
>
> (a) the OMAP3430 TRMs aren't available.

Yes it is publicly available in a few forms. Using google I was just able to find a few references.

For public 3430 look here:
http://focus.ti.com/pdfs/wtbu/SWPU114Q_PrelimFinal_EPDF_03_05_2009.pdf

The 35xx one is out there also (mostly the same) and easier to find.

The public TRM above has the ARM revision/patch version documented in section 3.1.2. The ARM core is r1p3 in OMAP3430-ES3.1 and r1p7 for OMAP3430-ES3.1.1.

Last time I looked in an ID register it seemed ok but I had inside information and may have missed something.

Your use of a run time check seemed good.

Thanks,
Richard W.

RE: LDP support

[Woodruff, Richard]

> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Monday, June 01, 2009 2:45 AM

> That's something that TI may know, but it's almost impossible for developers
> to know because:

BTW, yes, the forest of TRMs for OMAP3 can be hard to follow.

There are public and private versions and many addendums. There are also 35xx vs. 34xx versions.

In the end most of the necessary information is publically available. Sites like beagleboard and zoom try to make more of this digestible.

Regards,
Richard W.

Re: LDP support

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [090531 14:25]:
> On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [090428 15:07]:
> > > Tony, et.al.,
> > > 
> > > Any ideas when more LDP support will be pushed into mainline (such as
> > > the framebuffer support)?
> > 
> > I'll be looking at the board-*.c patches for the next merge window
> > hopefully this week or next week.
> > 
> > Looks like LDP keyboard, touchscreen & RTC are pretty much ready
> > to go. Then the MMC has some regulator updates, but AFAIK the MMC
> > should work OK already.
> > 
> > For the framebuffer, Imre and Tomi know the status the best, so
> > I've added them to Cc.
> > 
> > Imre has been meaning to send a bunch of drivers/video/omap changes
> > to the fbdev list for a while now and LDP framebuffer may depend on
> > those. Imre, any news on the status of sending the fb patches
> > upstream?
> > 
> > Then there are the upcoming DSS patches from Tomi, but those still
> > need some work before they're ready to go.
> 
> Okay, now that I've merged your tree, we've moved a few steps forward but
> a couple of steps backward with LDP support:
> 
> 1. LDP LCD platform device added
> 2. GPIO keyboard platform data added
> 3. TWL4030 keyboard platform data added
> 4. TSC2046 touchscreen platform data added
> 5. MMC has regressed - no sign of the driver initializing, not even an
>    error message from it, so I can't boot to check what the status of
>    these are.

Do you have CONFIG_REGULATOR set in your .config? That seems to be missing
from arch/arm/configs/omap_ldp_defconfig.

> 6. do ___NOT___ (underscored in triplicate and 500ft high letters) enable
>    ARM errata 460075 - it solidly prevents the kernel booting on LDP.
>    (it's taken many hours to debug that.)
> 
> However, things that still seem to be missing:
> 
> 1. GPIO keyboard (presumably) needs to be enabled in omap_ldp_defconfig

Anybody with an LDP care to update the omap_ldp_defconfig? No LDP here.

> 2. No TWL4030 keyboard driver merged (not even in linux-next)
> 3. No LDP LCD driver merged
> 4. No OMAP3 video driver

For 3 & 4, I know Imre has the patches ready to go.. Imre, have they been
posted to the fb list?

> 5. No sound?

This could be pretty easy now with the ASoC driver, anybody seen a driver
fro this?
 
> Any ideas what's happening with these?  Will they make the next merge
> window (which is possibly about a week away) - I guess not. :(

Well sounds like the defconfig fixes, keyboard, and fb updates still have
a chance to get in.

Tony

Re: LDP support

[Russell King - ARM Linux]

On Mon, Jun 01, 2009 at 09:00:33AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090531 14:25]:
> > Okay, now that I've merged your tree, we've moved a few steps forward but
> > a couple of steps backward with LDP support:
> > 
> > 1. LDP LCD platform device added
> > 2. GPIO keyboard platform data added
> > 3. TWL4030 keyboard platform data added
> > 4. TSC2046 touchscreen platform data added
> > 5. MMC has regressed - no sign of the driver initializing, not even an
> >    error message from it, so I can't boot to check what the status of
> >    these are.
> 
> Do you have CONFIG_REGULATOR set in your .config? That seems to be missing
> from arch/arm/configs/omap_ldp_defconfig.

Yes, that fixes it.

I think it would be a good thing that a KERN_ERR message is displayed
to cover this case, since it currently fails completely silently.

Re: LDP support

[Imre Deak]

On Mon, Jun 01, 2009 at 06:00:33PM +0200, ext Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090531 14:25]:
> > On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [090428 15:07]:
> > > > Tony, et.al.,
> > > > 
> > > > Any ideas when more LDP support will be pushed into mainline (such as
> > > > the framebuffer support)?
> > > 
> > > I'll be looking at the board-*.c patches for the next merge window
> > > hopefully this week or next week.
> > > 
> > > Looks like LDP keyboard, touchscreen & RTC are pretty much ready
> > > to go. Then the MMC has some regulator updates, but AFAIK the MMC
> > > should work OK already.
> > > 
> > > For the framebuffer, Imre and Tomi know the status the best, so
> > > I've added them to Cc.
> > > 
> > > Imre has been meaning to send a bunch of drivers/video/omap changes
> > > to the fbdev list for a while now and LDP framebuffer may depend on
> > > those. Imre, any news on the status of sending the fb patches
> > > upstream?
> > > 
> > > Then there are the upcoming DSS patches from Tomi, but those still
> > > need some work before they're ready to go.
> > 
> > Okay, now that I've merged your tree, we've moved a few steps forward but
> > a couple of steps backward with LDP support:
> > 
> > 1. LDP LCD platform device added
> > 2. GPIO keyboard platform data added
> > 3. TWL4030 keyboard platform data added
> > 4. TSC2046 touchscreen platform data added
> > 5. MMC has regressed - no sign of the driver initializing, not even an
> >    error message from it, so I can't boot to check what the status of
> >    these are.
> 
> Do you have CONFIG_REGULATOR set in your .config? That seems to be missing
> from arch/arm/configs/omap_ldp_defconfig.
> 
> > 6. do ___NOT___ (underscored in triplicate and 500ft high letters) enable
> >    ARM errata 460075 - it solidly prevents the kernel booting on LDP.
> >    (it's taken many hours to debug that.)
> > 
> > However, things that still seem to be missing:
> > 
> > 1. GPIO keyboard (presumably) needs to be enabled in omap_ldp_defconfig
> 
> Anybody with an LDP care to update the omap_ldp_defconfig? No LDP here.
> 
> > 2. No TWL4030 keyboard driver merged (not even in linux-next)
> > 3. No LDP LCD driver merged
> > 4. No OMAP3 video driver
> 
> For 3 & 4, I know Imre has the patches ready to go.. Imre, have they been
> posted to the fb list?

Not yet, I updated the patches, removing the board file changes as we agreed.
Also they don't include the latest HWA742 clock changes, which should be already
in the omap-fixes queue.

Other than these the patches have the following changes based on the omap-fixes
version of the driver:
- checkpatch fixes
- logically related commits merged, keeping the authorship info
- commit removed: omapfb: remove wrong scale call for gfx_plane
  This can't be correct, as it disables scaling completely.

I updated the omapfb-upstream branch on git://koowaldah.org/people/imre/linux-2.6-fb,
if these are ok with you I'll post them on the fb list.

--Imre

Re: LDP support

[Russell King - ARM Linux]

On Thu, Jun 04, 2009 at 12:39:55AM +0300, Imre Deak wrote:
> I updated the omapfb-upstream branch on git://koowaldah.org/people/imre/linux-2.6-fb,
> if these are ok with you I'll post them on the fb list.

Just be aware that Linus released -rc8 on Tuesday, and said that will
be the final rc before the merge window opens.  So I reckon there's less
than a week to the merge window opening.

That's not a suggestion that people should panic and sent their half
complete patches out for merging.  [for the wider audience] Looking
at the amount of unread email from the last two days, I think I have
sufficient quantity to keep me occupied until the merge window does
open.

Re: LDP support

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [090603 15:34]:
> On Thu, Jun 04, 2009 at 12:39:55AM +0300, Imre Deak wrote:
> > I updated the omapfb-upstream branch on git://koowaldah.org/people/imre/linux-2.6-fb,
> > if these are ok with you I'll post them on the fb list.
> 
> Just be aware that Linus released -rc8 on Tuesday, and said that will
> be the final rc before the merge window opens.  So I reckon there's less
> than a week to the merge window opening.

Imre, few comments after browsing through your patches:

"omapfb: Add support for MIPI-DCS compatible LCDs" seems to depend on
drivers/cbus which is not yet merged. Please leave out those parts so
it compiles. Then we can add the missing functions once drivers/cbus
is merged in the future.

"omapfb: dispc: Add OMAP3 support" should no longer be needed, this
got already fixed with clkdev patch 005187eecaa400b4b43d9f640fbde9fcc50f37c1
in mainline.

"omapfb: Fix coding style / remove dead line" has a typo in Russell's
name.
 
> That's not a suggestion that people should panic and sent their half
> complete patches out for merging.  [for the wider audience] Looking
> at the amount of unread email from the last two days, I think I have
> sufficient quantity to keep me occupied until the merge window does
> open.

Just FYI, I don't think we have much anything more heading your way
this merge window from the omap land. Just the second clock fixes
series from Paul, and the omap4 SMP patches are still pending.

Regards,

Tony

Re: LDP support

[Imre Deak]

On Thu, Jun 04, 2009 at 01:41:26AM +0200, ext Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [090603 15:34]:
> > On Thu, Jun 04, 2009 at 12:39:55AM +0300, Imre Deak wrote:
> > > I updated the omapfb-upstream branch on git://koowaldah.org/people/imre/linux-2.6-fb,
> > > if these are ok with you I'll post them on the fb list.
> > 
> > Just be aware that Linus released -rc8 on Tuesday, and said that will
> > be the final rc before the merge window opens.  So I reckon there's less
> > than a week to the merge window opening.
> 
> Imre, few comments after browsing through your patches:
> 
> "omapfb: Add support for MIPI-DCS compatible LCDs" seems to depend on
> drivers/cbus which is not yet merged. Please leave out those parts so
> it compiles. Then we can add the missing functions once drivers/cbus
> is merged in the future.
> 
> "omapfb: dispc: Add OMAP3 support" should no longer be needed, this
> got already fixed with clkdev patch 005187eecaa400b4b43d9f640fbde9fcc50f37c1
> in mainline.
> 
> "omapfb: Fix coding style / remove dead line" has a typo in Russell's
> name.

Thanks, I fixed these and updated the tree. From lcd_mipid I removed the
cbus thing and added platform hooks instead, so the backlight code should
be now in the board file. This needs to be added for n770, I'll follow-up
with a patch for that later.

There are two additional patches, one enabling the LCD in the N770 Kconfig
and a variable type fix for HWA742. Do you want to put these to omap-fixes
or I can just submit them?

How about the rest of the Kconfig changes?

--Imre

Re: LDP support

[Tony Lindgren]

* Imre Deak <imre.deak@nokia.com> [090604 07:58]:
> On Thu, Jun 04, 2009 at 01:41:26AM +0200, ext Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [090603 15:34]:
> > > On Thu, Jun 04, 2009 at 12:39:55AM +0300, Imre Deak wrote:
> > > > I updated the omapfb-upstream branch on git://koowaldah.org/people/imre/linux-2.6-fb,
> > > > if these are ok with you I'll post them on the fb list.
> > > 
> > > Just be aware that Linus released -rc8 on Tuesday, and said that will
> > > be the final rc before the merge window opens.  So I reckon there's less
> > > than a week to the merge window opening.
> > 
> > Imre, few comments after browsing through your patches:
> > 
> > "omapfb: Add support for MIPI-DCS compatible LCDs" seems to depend on
> > drivers/cbus which is not yet merged. Please leave out those parts so
> > it compiles. Then we can add the missing functions once drivers/cbus
> > is merged in the future.
> > 
> > "omapfb: dispc: Add OMAP3 support" should no longer be needed, this
> > got already fixed with clkdev patch 005187eecaa400b4b43d9f640fbde9fcc50f37c1
> > in mainline.
> > 
> > "omapfb: Fix coding style / remove dead line" has a typo in Russell's
> > name.
> 
> Thanks, I fixed these and updated the tree. From lcd_mipid I removed the
> cbus thing and added platform hooks instead, so the backlight code should
> be now in the board file. This needs to be added for n770, I'll follow-up
> with a patch for that later.

OK, thanks!
 
> There are two additional patches, one enabling the LCD in the N770 Kconfig
> and a variable type fix for HWA742. Do you want to put these to omap-fixes
> or I can just submit them?
> 
> How about the rest of the Kconfig changes?

I think all these are fine to go via the fb list, just Cc also linux-omap.
Then for the patches touching defconfigs and the type fix, please also Cc
linux-arm-kernel list too.

Regards,

Tony