Re: OMAP display subsystem - does it work?
On Sat, Dec 21, 2013 at 12:59:41AM +, Russell King - ARM Linux wrote: > On Fri, Dec 20, 2013 at 08:55:03AM -0800, Tony Lindgren wrote: > > Yeah this seems to do the trick for me for the built-in DSS on LDP. > > > > Tony > > > > 8< --- > > From: Tony Lindgren > > Date: Fri, 20 Dec 2013 08:53:27 -0800 > > Subject: [PATCH] ARM: OMAP2+: Fix LCD panel backlight regression for LDP > > legacy booting > > > > Looks like the LCD panel on LDP has been broken quite a while, and > > recently got fixed. However, there's still an issue where the panel > > backlight does not come on if the LCD drivers are built into the > > kernel. > > > > Fix the issue by registering the DPI LCD panel only after the twl4030 > > GPIO has probed. > > > > Reported-by: Russell King > > Signed-off-by: Tony Lindgren > > > > --- a/arch/arm/mach-omap2/board-ldp.c > > +++ b/arch/arm/mach-omap2/board-ldp.c > > @@ -248,7 +248,7 @@ static int ldp_twl_gpio_setup(struct device *dev, > > unsigned gpio, unsigned ngpio) > > /* Backlight enable GPIO */ > > ldp_lcd_pdata.backlight_gpio = gpio + 15; > > > > - return 0; > > + return platform_device_register(&ldp_lcd_device); > > } > > > > static struct twl4030_gpio_platform_data ldp_gpio_data = { > > @@ -346,7 +346,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = { > > > > static struct platform_device *ldp_devices[] __initdata = { > > &ldp_gpio_keys_device, > > - &ldp_lcd_device, > > }; > > > > #ifdef CONFIG_OMAP_MUX > > I've added it to the test build for tonight (only as an uncommitted > modification) so we'll see what happens tomorrow morning. BTW, yes, this does result in the display working again on the LDP. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP display subsystem - does it work?
* Tomi Valkeinen [131222 23:55]: > On 2013-12-20 18:55, Tony Lindgren wrote: > > --- a/arch/arm/mach-omap2/board-ldp.c > > +++ b/arch/arm/mach-omap2/board-ldp.c > > @@ -248,7 +248,7 @@ static int ldp_twl_gpio_setup(struct device *dev, > > unsigned gpio, unsigned ngpio) > > /* Backlight enable GPIO */ > > ldp_lcd_pdata.backlight_gpio = gpio + 15; > > > > - return 0; > > + return platform_device_register(&ldp_lcd_device); > > If the panel device registration fails, does the whole TWL probe fail? > If so, that sounds a bit harsh to me. OK I've applied the updated version below which does not make the TWL GPIO probe to fail on errors. > Looks right to me: > > Acked-by: Tomi Valkeinen > > Rather ugly, though, but there's probably no point in trying to do it in > a cleaner way (the new GPIO API, I think?), as we'll move to DT soon. Yes we should not need the callbacks just to set TWL GPIO numbers when booted with DT so this problem will disappear. Updated patch below for reference, I kept your ack hope that's OK with you. Regards, Tony 8< From: Tony Lindgren Date: Fri, 27 Dec 2013 09:33:27 -0800 Subject: [PATCH] ARM: OMAP2+: Fix LCD panel backlight regression for LDP legacy booting Looks like the LCD panel on LDP has been broken quite a while, and recently got fixed by commit 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl gpio output). However, there's still an issue left where the panel backlight does not come on if the LCD drivers are built into the kernel. Fix the issue by registering the DPI LCD panel only after the twl4030 GPIO has probed. Reported-by: Russell King Acked-by: Tomi Valkeinen [t...@atomide.com: updated per Tomi's comments] Signed-off-by: Tony Lindgren --- a/arch/arm/mach-omap2/board-ldp.c +++ b/arch/arm/mach-omap2/board-ldp.c @@ -242,12 +242,18 @@ static void __init ldp_display_init(void) static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio) { + int res; + /* LCD enable GPIO */ ldp_lcd_pdata.enable_gpio = gpio + 7; /* Backlight enable GPIO */ ldp_lcd_pdata.backlight_gpio = gpio + 15; + res = platform_device_register(&ldp_lcd_device); + if (res) + pr_err("Unable to register LCD: %d\n", res); + return 0; } @@ -346,7 +352,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = { static struct platform_device *ldp_devices[] __initdata = { &ldp_gpio_keys_device, - &ldp_lcd_device, }; #ifdef CONFIG_OMAP_MUX -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP display subsystem - does it work?
On 2013-12-20 18:55, Tony Lindgren wrote: >> I bet that's it though. If the display is probed before twl4030 GPIO >> is initialized, the GPIO numbers will be 0. I'm using omap2plus_defconfig >> which has DSS built as modules. > > Yeah this seems to do the trick for me for the built-in DSS on LDP. > > Tony > > 8< --- > From: Tony Lindgren > Date: Fri, 20 Dec 2013 08:53:27 -0800 > Subject: [PATCH] ARM: OMAP2+: Fix LCD panel backlight regression for LDP > legacy booting > > Looks like the LCD panel on LDP has been broken quite a while, and > recently got fixed. However, there's still an issue where the panel > backlight does not come on if the LCD drivers are built into the > kernel. > > Fix the issue by registering the DPI LCD panel only after the twl4030 > GPIO has probed. > > Reported-by: Russell King > Signed-off-by: Tony Lindgren > > --- a/arch/arm/mach-omap2/board-ldp.c > +++ b/arch/arm/mach-omap2/board-ldp.c > @@ -248,7 +248,7 @@ static int ldp_twl_gpio_setup(struct device *dev, > unsigned gpio, unsigned ngpio) > /* Backlight enable GPIO */ > ldp_lcd_pdata.backlight_gpio = gpio + 15; > > - return 0; > + return platform_device_register(&ldp_lcd_device); If the panel device registration fails, does the whole TWL probe fail? If so, that sounds a bit harsh to me. > } > > static struct twl4030_gpio_platform_data ldp_gpio_data = { > @@ -346,7 +346,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = { > > static struct platform_device *ldp_devices[] __initdata = { > &ldp_gpio_keys_device, > - &ldp_lcd_device, > }; > > #ifdef CONFIG_OMAP_MUX > Looks right to me: Acked-by: Tomi Valkeinen Rather ugly, though, but there's probably no point in trying to do it in a cleaner way (the new GPIO API, I think?), as we'll move to DT soon. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP display subsystem - does it work?
On 2013-12-20 18:04, Tony Lindgren wrote: >> This looks odd... Presuming the panel device was probed successfully, it >> should always get the gpios or return an error. Only if gpio_is_valid() >> returns false for the gpio, it skips it and continues. But in this case, >> the gpio number comes from the platform data, so it should always be valid. >> >> And if it wasn't probed successfully, then there shouldn't be a fb0. > > I bet that's it though. If the display is probed before twl4030 GPIO > is initialized, the GPIO numbers will be 0. I'm using omap2plus_defconfig > which has DSS built as modules. Ah, right, I see. The gpio numbers for the panel pdata are initialized to -1 (not 0) in the board file. The twl init code will set those to their appropriate numbers, but if the panel is probed before twl, the panel driver just presumes gpios are not needed as they are -1. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP display subsystem - does it work?
On Fri, Dec 20, 2013 at 08:55:03AM -0800, Tony Lindgren wrote: > Yeah this seems to do the trick for me for the built-in DSS on LDP. > > Tony > > 8< --- > From: Tony Lindgren > Date: Fri, 20 Dec 2013 08:53:27 -0800 > Subject: [PATCH] ARM: OMAP2+: Fix LCD panel backlight regression for LDP > legacy booting > > Looks like the LCD panel on LDP has been broken quite a while, and > recently got fixed. However, there's still an issue where the panel > backlight does not come on if the LCD drivers are built into the > kernel. > > Fix the issue by registering the DPI LCD panel only after the twl4030 > GPIO has probed. > > Reported-by: Russell King > Signed-off-by: Tony Lindgren > > --- a/arch/arm/mach-omap2/board-ldp.c > +++ b/arch/arm/mach-omap2/board-ldp.c > @@ -248,7 +248,7 @@ static int ldp_twl_gpio_setup(struct device *dev, > unsigned gpio, unsigned ngpio) > /* Backlight enable GPIO */ > ldp_lcd_pdata.backlight_gpio = gpio + 15; > > - return 0; > + return platform_device_register(&ldp_lcd_device); > } > > static struct twl4030_gpio_platform_data ldp_gpio_data = { > @@ -346,7 +346,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = { > > static struct platform_device *ldp_devices[] __initdata = { > &ldp_gpio_keys_device, > - &ldp_lcd_device, > }; > > #ifdef CONFIG_OMAP_MUX I've added it to the test build for tonight (only as an uncommitted modification) so we'll see what happens tomorrow morning. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP display subsystem - does it work?
* Tony Lindgren [131220 08:06]: > * Tomi Valkeinen [131220 05:45]: > > On 2013-12-20 13:48, Russell King - ARM Linux wrote: > > > > > Or maybe this is getting buggered by the idiotic deferred probing... It > > > seems that the GPIOs for controlling the LCD and backlight aren't even > > > getting claimed if the DSS modules are built in: > > > > > > # cat /sys/kernel/debug/gpio > > > ... > > > GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep: > > > # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/unbind > > > # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/bind > > > # cat /sys/kernel/debug/gpio > > > ... > > > GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep: > > > gpio-245 (panel enable) out lo > > > gpio-253 (panel backlight ) out lo > > > > This looks odd... Presuming the panel device was probed successfully, it > > should always get the gpios or return an error. Only if gpio_is_valid() > > returns false for the gpio, it skips it and continues. But in this case, > > the gpio number comes from the platform data, so it should always be valid. > > > > And if it wasn't probed successfully, then there shouldn't be a fb0. > > I bet that's it though. If the display is probed before twl4030 GPIO > is initialized, the GPIO numbers will be 0. I'm using omap2plus_defconfig > which has DSS built as modules. Yeah this seems to do the trick for me for the built-in DSS on LDP. Tony 8< --- From: Tony Lindgren Date: Fri, 20 Dec 2013 08:53:27 -0800 Subject: [PATCH] ARM: OMAP2+: Fix LCD panel backlight regression for LDP legacy booting Looks like the LCD panel on LDP has been broken quite a while, and recently got fixed. However, there's still an issue where the panel backlight does not come on if the LCD drivers are built into the kernel. Fix the issue by registering the DPI LCD panel only after the twl4030 GPIO has probed. Reported-by: Russell King Signed-off-by: Tony Lindgren --- a/arch/arm/mach-omap2/board-ldp.c +++ b/arch/arm/mach-omap2/board-ldp.c @@ -248,7 +248,7 @@ static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio) /* Backlight enable GPIO */ ldp_lcd_pdata.backlight_gpio = gpio + 15; - return 0; + return platform_device_register(&ldp_lcd_device); } static struct twl4030_gpio_platform_data ldp_gpio_data = { @@ -346,7 +346,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = { static struct platform_device *ldp_devices[] __initdata = { &ldp_gpio_keys_device, - &ldp_lcd_device, }; #ifdef CONFIG_OMAP_MUX -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP display subsystem - does it work?
* Russell King - ARM Linux [131220 03:28]: > > > BTW, I'm seeing MMC errors with my LDP here though, does that work > > for you? > > I see no errors there. OK thanks that's good to hear. I'm seeing them even after changing the MMC card, need to check that again though. I'm almost certain it worked just fine a month ago or so when I was playing with it.. Maybe some dirt in the contacts or something. > Okay, while digging through the changes, I found this - this is the old > code. gpio + 15 is the backlight enable GPIO. > > static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned > ngpio) > { > - ldp_panel_data.gpios[0] = gpio + 7; > - ldp_panel_data.gpio_invert[0] = true; > > - ldp_panel_data.gpios[1] = gpio + 15; > - ldp_panel_data.gpio_invert[1] = true; > > return 0; > } > > ... > > -static int generic_dpi_panel_power_on(struct omap_dss_device *dssdev) > -{ > ... > - for (i = 0; i < panel_data->num_gpios; ++i) { > - gpio_set_value_cansleep(panel_data->gpios[i], > - panel_data->gpio_invert[i] ? 0 : 1); > - } > > -static void generic_dpi_panel_power_off(struct omap_dss_device *dssdev) > -{ > ... > - for (i = panel_data->num_gpios - 1; i >= 0; --i) { > - gpio_set_value_cansleep(panel_data->gpios[i], > - panel_data->gpio_invert[i] ? 1 : 0); > - } > > -static int generic_dpi_panel_probe(struct omap_dss_device *dssdev) > -{ > - for (i = 0; i < panel_data->num_gpios; ++i) { > - r = devm_gpio_request_one(dssdev->dev, panel_data->gpios[i], > - panel_data->gpio_invert[i] ? > - GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW, > - "panel gpio"); > - if (r) > - return r; > - } > > So, when gpio_invert[] is set, the signal is active low for "on". What > does the new code do? > > static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned > ngpio) > { > + /* LCD enable GPIO */ > + ldp_lcd_pdata.enable_gpio = gpio + 7; > > + /* Backlight enable GPIO */ > + ldp_lcd_pdata.backlight_gpio = gpio + 15; > ... > > static int panel_dpi_enable(struct omap_dss_device *dssdev) > { > ... > if (gpio_is_valid(ddata->backlight_gpio)) > gpio_set_value_cansleep(ddata->backlight_gpio, 1); > > ... > static void panel_dpi_disable(struct omap_dss_device *dssdev) > { > ... > if (gpio_is_valid(ddata->backlight_gpio)) > gpio_set_value_cansleep(ddata->backlight_gpio, 0); > > ... > static int panel_dpi_probe(struct platform_device *pdev) > { > ... > if (gpio_is_valid(ddata->backlight_gpio)) { > r = devm_gpio_request_one(&pdev->dev, ddata->backlight_gpio, > GPIOF_OUT_INIT_LOW, "panel backlight"); > > which is fixed at active-high for "on". > > Would you like to revise whether this works for you... I suspect that > you're missing configuration which means that the backlight_gpio is > not valid, and hence it's being left in same default state (maybe by > the boot loader?) Nope, my LCD if off from the bootloader and gets enabled by the kernel. I think the old gpio_invert was inverting the value unnecessarily or something, the new code does the right thing without a need for the gpio_invert flags. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP display subsystem - does it work?
* Tomi Valkeinen [131220 05:45]: > On 2013-12-20 13:48, Russell King - ARM Linux wrote: > > On Fri, Dec 20, 2013 at 11:27:01AM +, Russell King - ARM Linux wrote: > >> Maybe, but that's the problem - finding out what is missing. This is the > >> endless problem where things keep changing - it's very difficult to keep > >> a "working configuration" working because the config symbols keep changing. > >> > >> Also, bear in mind that there's many different variants of the LDP hardware > >> with stuff connected up in different ways (I'm aware that the keypad is > >> just randomly allocated). I wouldn't be surprised if this also applied > >> to how the backlight on the LCD was done. > > I need to cook up a patch for the gpio active-low problem. I tried to > figure out how to do it with the old GPIO API, but as far as I > understand, I have to do it manually in the driver (as it was done in > the old driver). > > > Or maybe this is getting buggered by the idiotic deferred probing... It > > seems that the GPIOs for controlling the LCD and backlight aren't even > > getting claimed if the DSS modules are built in: > > > > # cat /sys/kernel/debug/gpio > > ... > > GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep: > > # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/unbind > > # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/bind > > # cat /sys/kernel/debug/gpio > > ... > > GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep: > > gpio-245 (panel enable) out lo > > gpio-253 (panel backlight ) out lo > > This looks odd... Presuming the panel device was probed successfully, it > should always get the gpios or return an error. Only if gpio_is_valid() > returns false for the gpio, it skips it and continues. But in this case, > the gpio number comes from the platform data, so it should always be valid. > > And if it wasn't probed successfully, then there shouldn't be a fb0. I bet that's it though. If the display is probed before twl4030 GPIO is initialized, the GPIO numbers will be 0. I'm using omap2plus_defconfig which has DSS built as modules. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP display subsystem - does it work?
On 2013-12-20 13:48, Russell King - ARM Linux wrote: > On Fri, Dec 20, 2013 at 11:27:01AM +, Russell King - ARM Linux wrote: >> Maybe, but that's the problem - finding out what is missing. This is the >> endless problem where things keep changing - it's very difficult to keep >> a "working configuration" working because the config symbols keep changing. >> >> Also, bear in mind that there's many different variants of the LDP hardware >> with stuff connected up in different ways (I'm aware that the keypad is >> just randomly allocated). I wouldn't be surprised if this also applied >> to how the backlight on the LCD was done. I need to cook up a patch for the gpio active-low problem. I tried to figure out how to do it with the old GPIO API, but as far as I understand, I have to do it manually in the driver (as it was done in the old driver). > Or maybe this is getting buggered by the idiotic deferred probing... It > seems that the GPIOs for controlling the LCD and backlight aren't even > getting claimed if the DSS modules are built in: > > # cat /sys/kernel/debug/gpio > ... > GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep: > # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/unbind > # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/bind > # cat /sys/kernel/debug/gpio > ... > GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep: > gpio-245 (panel enable) out lo > gpio-253 (panel backlight ) out lo This looks odd... Presuming the panel device was probed successfully, it should always get the gpios or return an error. Only if gpio_is_valid() returns false for the gpio, it skips it and continues. But in this case, the gpio number comes from the platform data, so it should always be valid. And if it wasn't probed successfully, then there shouldn't be a fb0. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP display subsystem - does it work?
On Fri, Dec 20, 2013 at 11:27:01AM +, Russell King - ARM Linux wrote: > Maybe, but that's the problem - finding out what is missing. This is the > endless problem where things keep changing - it's very difficult to keep > a "working configuration" working because the config symbols keep changing. > > Also, bear in mind that there's many different variants of the LDP hardware > with stuff connected up in different ways (I'm aware that the keypad is > just randomly allocated). I wouldn't be surprised if this also applied > to how the backlight on the LCD was done. Or maybe this is getting buggered by the idiotic deferred probing... It seems that the GPIOs for controlling the LCD and backlight aren't even getting claimed if the DSS modules are built in: # cat /sys/kernel/debug/gpio ... GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep: # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/unbind # echo panel-dpi.0 > /sys/bus/platform/drivers/panel-dpi/bind # cat /sys/kernel/debug/gpio ... GPIOs 238-255, platform/twl4030_gpio, twl4030, can sleep: gpio-245 (panel enable) out lo gpio-253 (panel backlight ) out lo Tony, try this with the stuff not as modules but built-in. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP display subsystem - does it work?
On Thu, Dec 19, 2013 at 10:22:53AM -0800, Tony Lindgren wrote: > * Russell King - ARM Linux [131219 09:58]: > > On Wed, Dec 18, 2013 at 10:23:54AM -0800, Tony Lindgren wrote: > > > * Tomi Valkeinen [131218 05:56]: > > > > I don't have an LDP board at hand, and I wasn't able to find out > > > > anything from > > > > the logs. > > > > > > > > I think I should change omapfb to print something if it's probed > > > > succesfully, > > > > as the deferred probing makes finding out if something is probed fine > > > > or not > > > > quite murky. Without deferred probing, it was simpler: no errors -> the > > > > driver > > > > must be (most likely) ok. > > > > > > > > Although... In an earlier log, where there was no panel driver, the log > > > > has > > > > these errors: > > > > > > > > Error opening /dev/fb0: No such device > > > > > > > > There are none in the latest log, which makes me guess the omapfb has > > > > been > > > > probed, and fb0 is actually there. But the X is still dying for some > > > > reason... > > > > > > > > I'll look at this more. Maybe someone in our team can find a board to > > > > test. > > > > > > Hmm I had the framebuffer working with DT on LDP after fixing the twl4030 > > > gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl > > > gpio output) using this pdata quirks patch: > > > > > > [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 > > > LDP to use it > > > > > > AFAIK the pdata hack above should not be needed now, but I have not tried > > > with Tomi's DSS DT patches yet. > > > > > > Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I > > > could try at some point? > > > > > > Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar > > > from your kernel cmdline? > > > > Note that I'm trying to get non-DT stuff working properly here first, in > > such a state that it has done in the past with mainline kernels. This is > > quite an old regression, but it's still a regression nevertheless. > > Yeah that should just work now. > > > I've just built and booted a kernel with the backlight support in. No > > change. > > I just tried it here with v3.13-rc4 in legacy mode using omap2plus_defconfig > with the following test script and seems to work just fine for producing a > nice random color pattern on the LCD: > > #!/bin/sh > mount -o rw,remount / > depmod -a > modprobe panel-generic-dpi > modprobe panel-dpi > modprobe omapfb vram=0:2M,1:5M > if [ -c /dev/fb0 ]; then > dd if=/dev/urandom of=/dev/fb0; > fi > > Note that as the panel name has changed recently so my script tries to > load both panel modules. I don't think the problem is with the creation of the framebuffer. > Maybe you're missing something from your .config file still? Maybe, but that's the problem - finding out what is missing. This is the endless problem where things keep changing - it's very difficult to keep a "working configuration" working because the config symbols keep changing. Also, bear in mind that there's many different variants of the LDP hardware with stuff connected up in different ways (I'm aware that the keypad is just randomly allocated). I wouldn't be surprised if this also applied to how the backlight on the LCD was done. > BTW, I'm seeing MMC errors with my LDP here though, does that work > for you? I see no errors there. Okay, while digging through the changes, I found this - this is the old code. gpio + 15 is the backlight enable GPIO. static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio) { - ldp_panel_data.gpios[0] = gpio + 7; - ldp_panel_data.gpio_invert[0] = true; - ldp_panel_data.gpios[1] = gpio + 15; - ldp_panel_data.gpio_invert[1] = true; return 0; } ... -static int generic_dpi_panel_power_on(struct omap_dss_device *dssdev) -{ ... - for (i = 0; i < panel_data->num_gpios; ++i) { - gpio_set_value_cansleep(panel_data->gpios[i], - panel_data->gpio_invert[i] ? 0 : 1); - } -static void generic_dpi_panel_power_off(struct omap_dss_device *dssdev) -{ ... - for (i = panel_data->num_gpios - 1; i >= 0; --i) { - gpio_set_value_cansleep(panel_data->gpios[i], - panel_data->gpio_invert[i] ? 1 : 0); - } -static int generic_dpi_panel_probe(struct omap_dss_device *dssdev) -{ - for (i = 0; i < panel_data->num_gpios; ++i) { - r = devm_gpio_request_one(dssdev->dev, panel_data->gpios[i], - panel_data->gpio_invert[i] ? - GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW, - "panel gpio"); - if (r) - return r; - } So, when gpio_invert[] is set, the signal is active low for "on". What does the new code do? static int ldp_twl_gpio_setup(struct device *dev, unsigned gpi
Re: OMAP display subsystem - does it work?
On 2013-12-19 18:56, Tony Lindgren wrote: >>> Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar >>> from your kernel cmdline? >> >> Nothing like that should be required for normal operation. > > Hmm maybe these instructions need some updating then: > > http://omappedia.org/wiki/Bootargs_for_enabling_display The page says omapfb.vram "can" be used, and "If the size is not specified, frame buffers with default size are created". You only need omapfb.vram option if you want to allocate extra memory for the fb. The plain 'vram' option has no function anymore, now that we're using normal dma alloc. So that part should be updated. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP display subsystem - does it work?
* Russell King - ARM Linux [131219 09:58]: > On Wed, Dec 18, 2013 at 10:23:54AM -0800, Tony Lindgren wrote: > > * Tomi Valkeinen [131218 05:56]: > > > I don't have an LDP board at hand, and I wasn't able to find out anything > > > from > > > the logs. > > > > > > I think I should change omapfb to print something if it's probed > > > succesfully, > > > as the deferred probing makes finding out if something is probed fine or > > > not > > > quite murky. Without deferred probing, it was simpler: no errors -> the > > > driver > > > must be (most likely) ok. > > > > > > Although... In an earlier log, where there was no panel driver, the log > > > has > > > these errors: > > > > > > Error opening /dev/fb0: No such device > > > > > > There are none in the latest log, which makes me guess the omapfb has been > > > probed, and fb0 is actually there. But the X is still dying for some > > > reason... > > > > > > I'll look at this more. Maybe someone in our team can find a board to > > > test. > > > > Hmm I had the framebuffer working with DT on LDP after fixing the twl4030 > > gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl > > gpio output) using this pdata quirks patch: > > > > [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 > > LDP to use it > > > > AFAIK the pdata hack above should not be needed now, but I have not tried > > with Tomi's DSS DT patches yet. > > > > Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I > > could try at some point? > > > > Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar > > from your kernel cmdline? > > Note that I'm trying to get non-DT stuff working properly here first, in > such a state that it has done in the past with mainline kernels. This is > quite an old regression, but it's still a regression nevertheless. Yeah that should just work now. > I've just built and booted a kernel with the backlight support in. No > change. I just tried it here with v3.13-rc4 in legacy mode using omap2plus_defconfig with the following test script and seems to work just fine for producing a nice random color pattern on the LCD: #!/bin/sh mount -o rw,remount / depmod -a modprobe panel-generic-dpi modprobe panel-dpi modprobe omapfb vram=0:2M,1:5M if [ -c /dev/fb0 ]; then dd if=/dev/urandom of=/dev/fb0; fi Note that as the panel name has changed recently so my script tries to load both panel modules. Maybe you're missing something from your .config file still? BTW, I'm seeing MMC errors with my LDP here though, does that work for you? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP display subsystem - does it work?
On Wed, Dec 18, 2013 at 10:23:54AM -0800, Tony Lindgren wrote: > * Tomi Valkeinen [131218 05:56]: > > I don't have an LDP board at hand, and I wasn't able to find out anything > > from > > the logs. > > > > I think I should change omapfb to print something if it's probed > > succesfully, > > as the deferred probing makes finding out if something is probed fine or not > > quite murky. Without deferred probing, it was simpler: no errors -> the > > driver > > must be (most likely) ok. > > > > Although... In an earlier log, where there was no panel driver, the log has > > these errors: > > > > Error opening /dev/fb0: No such device > > > > There are none in the latest log, which makes me guess the omapfb has been > > probed, and fb0 is actually there. But the X is still dying for some > > reason... > > > > I'll look at this more. Maybe someone in our team can find a board to test. > > Hmm I had the framebuffer working with DT on LDP after fixing the twl4030 > gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl > gpio output) using this pdata quirks patch: > > [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP > to use it > > AFAIK the pdata hack above should not be needed now, but I have not tried > with Tomi's DSS DT patches yet. > > Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I > could try at some point? > > Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar > from your kernel cmdline? Note that I'm trying to get non-DT stuff working properly here first, in such a state that it has done in the past with mainline kernels. This is quite an old regression, but it's still a regression nevertheless. I've just built and booted a kernel with the backlight support in. No change. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP display subsystem - does it work?
On Wed, Dec 18, 2013 at 03:54:42PM +0200, Tomi Valkeinen wrote: > On 2013-12-18 14:00, Russell King - ARM Linux wrote: > > > So, here goes. LDP3430: > > > > OMAP DSS rev 2.0 > > omapdss DPI error: can't get VDDS_DSI regulator > > omapfb omapfb: failed to connect default display > > omapfb omapfb: failed to init overlay connections > > omapfb omapfb: failed to setup omapfb > > platform omapfb: Driver omapfb requests probe deferral > > > > I don't see evidence of it being re-probed, but I do see this during boot > > which implies that there's nothing there: > > > > XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0" > > after 0 requests (0 known processed) with 0 events remaining. > > I don't have an LDP board at hand, and I wasn't able to find out anything > from the logs. Well, the X server dies because of some issue with tslib. No idea about that. However, disabling touschreen stuff, the X server comes up, but the LCD remains blank. Since the LDP has openembedded stuff on it, it normally would boot with a progress splash - that also is never displayed. Maybe there's something up with the backlight support? This used to work with mainline kernels I don't know how long ago. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP display subsystem - does it work?
* Tomi Valkeinen [131218 21:24]: > On 2013-12-18 20:23, Tony Lindgren wrote: > > > Hmm I had the framebuffer working with DT on LDP after fixing the twl4030 > > gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl > > gpio output) using this pdata quirks patch: > > > > [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 > > LDP to use it > > > > AFAIK the pdata hack above should not be needed now, but I have not tried > > with Tomi's DSS DT patches yet. > > > > Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I > > could try at some point? > > Hmm, I thought this was about legacy booting on v3.14-rc4. That still > uses the board files for omap3. AFAIK 0b2aa8bed3e1 was the only thing needed for legacy booting and it's in -rc4. > > Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar > > from your kernel cmdline? > > Nothing like that should be required for normal operation. Hmm maybe these instructions need some updating then: http://omappedia.org/wiki/Bootargs_for_enabling_display Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP display subsystem - does it work?
On 2013-12-18 20:23, Tony Lindgren wrote: > Hmm I had the framebuffer working with DT on LDP after fixing the twl4030 > gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl > gpio output) using this pdata quirks patch: > > [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP > to use it > > AFAIK the pdata hack above should not be needed now, but I have not tried > with Tomi's DSS DT patches yet. > > Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I > could try at some point? Hmm, I thought this was about legacy booting on v3.14-rc4. That still uses the board files for omap3. > Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar > from your kernel cmdline? Nothing like that should be required for normal operation. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP display subsystem - does it work?
* Tomi Valkeinen [131218 05:56]: > On 2013-12-18 14:00, Russell King - ARM Linux wrote: > > > So, here goes. LDP3430: > > > > OMAP DSS rev 2.0 > > omapdss DPI error: can't get VDDS_DSI regulator > > omapfb omapfb: failed to connect default display > > omapfb omapfb: failed to init overlay connections > > omapfb omapfb: failed to setup omapfb > > platform omapfb: Driver omapfb requests probe deferral > > > > I don't see evidence of it being re-probed, but I do see this during boot > > which implies that there's nothing there: > > > > XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0" > > after 0 requests (0 known processed) with 0 events remaining. > > I don't have an LDP board at hand, and I wasn't able to find out anything from > the logs. > > I think I should change omapfb to print something if it's probed succesfully, > as the deferred probing makes finding out if something is probed fine or not > quite murky. Without deferred probing, it was simpler: no errors -> the driver > must be (most likely) ok. > > Although... In an earlier log, where there was no panel driver, the log has > these errors: > > Error opening /dev/fb0: No such device > > There are none in the latest log, which makes me guess the omapfb has been > probed, and fb0 is actually there. But the X is still dying for some reason... > > I'll look at this more. Maybe someone in our team can find a board to test. Hmm I had the framebuffer working with DT on LDP after fixing the twl4030 gpio regression with 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl gpio output) using this pdata quirks patch: [PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it AFAIK the pdata hack above should not be needed now, but I have not tried with Tomi's DSS DT patches yet. Tomi do you have some sample panel dpi .dts entry somewhere for the LDP I could try at some point? Russell, maybe all you're missing is just omapfb.vram=0:2M,1:5M or similar from your kernel cmdline? > > For the SDP4430, it used to detect the displays, even though nothing has > > ever been displayed on them. Now it just spits out this: > > Those particular LCDs are supposed to be updated manually using custom ioctl, > so normal software using fb won't put anything on the display. For testing > purposes, a SW based automatic update (~20 fps) can be enabled by kernel > cmdline parameter "omapfb.auto_update" or via sysfs: > > echo 1 > /sys/class/graphics/fb0/update_mode > > > OMAP DSS rev 4.0 > > omapdss DSI error: can't get VDDS_DSI regulator > > panel-dsi-cm panel-dsi-cm.0: Failed to connect to video source > > omapfb omapfb: failed to connect default display > > omapfb omapfb: failed to init overlay connections > > omapfb omapfb: failed to setup omapfb > > platform omapfb: Driver omapfb requests probe deferral > > ... > > omapdss DSI error: failed to set complexio power state to 1 > > panel-dsi-cm panel-dsi-cm.0: failed to enable DSI > > omapfb omapfb: Failed to enable display 'lcd' > > omapfb omapfb: failed to initialize default display > > omapfb omapfb: failed to setup omapfb > > Commit e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 (ARM: OMAP2+: Remove legacy > mux > code for display.c) was overly enthusiastic in removing legacy code which was > already in use. Tony has a partial revert for that queued up. It can also be > reverted fully for testing. After that, the panel wakes up. Yes sorry for accidentally removing some extra code there, I just sent a pull request for the fix. My 4430 SDP is face down in the rack because of the way the Ethernet connector plugs in.. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP display subsystem - does it work?
On 2013-12-18 17:29, Russell King - ARM Linux wrote: > On Wed, Dec 18, 2013 at 03:54:42PM +0200, Tomi Valkeinen wrote: >> On 2013-12-18 14:00, Russell King - ARM Linux wrote: >>> For the SDP4430, it used to detect the displays, even though nothing has >>> ever been displayed on them. Now it just spits out this: >> >> Those particular LCDs are supposed to be updated manually using custom ioctl, >> so normal software using fb won't put anything on the display. For testing >> purposes, a SW based automatic update (~20 fps) can be enabled by kernel >> cmdline parameter "omapfb.auto_update" or via sysfs: >> >> echo 1 > /sys/class/graphics/fb0/update_mode > > I'm confused. How then can the original kernel which came with the board > run two gstreamer videos on these displays by just talking to the > framebuffers and play it back smoothly given that we're talking about > video at normal fps settings? > > When I received the board, that's exactly what it did at boot up - it > played back two different video trailers, one on each LCD, and the > playback was smooth, just like you'd expect from watching a DVD on your > TV. No missing frames, which is what you'd get if you tried to update > at 20fps. We once had auto-update support in omapdss in the early versions. It was removed quite a while ago, as it was a burden to maintain. Either the kernel you talk about had the auto-update support, or the userspace has support for manual-update displays. The thing is, these LCDs are not meant to be used in auto-update mode. The main point with LCDs with their own framebuffer is that they are only updated when needed. So a production device would not need auto-update support. Furthermore, as these LCDs are quite rare, and 4430SDP is the only one we support having these displays, and that board itself is not exactly a common one, it was decided that the maintenance burden is not worth it. I have been thinking of improving the auto-update in omapfb, but it has never been on the top of my list (or even middle). The current code basically does just queue_delayed_work() 20 times per second, so it's just a hack for testing. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP display subsystem - does it work?
On Wed, Dec 18, 2013 at 03:54:42PM +0200, Tomi Valkeinen wrote: > On 2013-12-18 14:00, Russell King - ARM Linux wrote: > > For the SDP4430, it used to detect the displays, even though nothing has > > ever been displayed on them. Now it just spits out this: > > Those particular LCDs are supposed to be updated manually using custom ioctl, > so normal software using fb won't put anything on the display. For testing > purposes, a SW based automatic update (~20 fps) can be enabled by kernel > cmdline parameter "omapfb.auto_update" or via sysfs: > > echo 1 > /sys/class/graphics/fb0/update_mode I'm confused. How then can the original kernel which came with the board run two gstreamer videos on these displays by just talking to the framebuffers and play it back smoothly given that we're talking about video at normal fps settings? When I received the board, that's exactly what it did at boot up - it played back two different video trailers, one on each LCD, and the playback was smooth, just like you'd expect from watching a DVD on your TV. No missing frames, which is what you'd get if you tried to update at 20fps. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP display subsystem - does it work?
On 2013-12-18 14:00, Russell King - ARM Linux wrote: > So, here goes. LDP3430: > > OMAP DSS rev 2.0 > omapdss DPI error: can't get VDDS_DSI regulator > omapfb omapfb: failed to connect default display > omapfb omapfb: failed to init overlay connections > omapfb omapfb: failed to setup omapfb > platform omapfb: Driver omapfb requests probe deferral > > I don't see evidence of it being re-probed, but I do see this during boot > which implies that there's nothing there: > > XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0" > after 0 requests (0 known processed) with 0 events remaining. I don't have an LDP board at hand, and I wasn't able to find out anything from the logs. I think I should change omapfb to print something if it's probed succesfully, as the deferred probing makes finding out if something is probed fine or not quite murky. Without deferred probing, it was simpler: no errors -> the driver must be (most likely) ok. Although... In an earlier log, where there was no panel driver, the log has these errors: Error opening /dev/fb0: No such device There are none in the latest log, which makes me guess the omapfb has been probed, and fb0 is actually there. But the X is still dying for some reason... I'll look at this more. Maybe someone in our team can find a board to test. > For the SDP4430, it used to detect the displays, even though nothing has > ever been displayed on them. Now it just spits out this: Those particular LCDs are supposed to be updated manually using custom ioctl, so normal software using fb won't put anything on the display. For testing purposes, a SW based automatic update (~20 fps) can be enabled by kernel cmdline parameter "omapfb.auto_update" or via sysfs: echo 1 > /sys/class/graphics/fb0/update_mode > OMAP DSS rev 4.0 > omapdss DSI error: can't get VDDS_DSI regulator > panel-dsi-cm panel-dsi-cm.0: Failed to connect to video source > omapfb omapfb: failed to connect default display > omapfb omapfb: failed to init overlay connections > omapfb omapfb: failed to setup omapfb > platform omapfb: Driver omapfb requests probe deferral > ... > omapdss DSI error: failed to set complexio power state to 1 > panel-dsi-cm panel-dsi-cm.0: failed to enable DSI > omapfb omapfb: Failed to enable display 'lcd' > omapfb omapfb: failed to initialize default display > omapfb omapfb: failed to setup omapfb Commit e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 (ARM: OMAP2+: Remove legacy mux code for display.c) was overly enthusiastic in removing legacy code which was already in use. Tony has a partial revert for that queued up. It can also be reverted fully for testing. After that, the panel wakes up. Tomi signature.asc Description: OpenPGP digital signature
OMAP display subsystem - does it work?
In my continuing woes with having the OMAP boards I have produce output, where things used to work on the LDP, they now do not. And on the SDP4430 board, where things were detected, they're no longer detected. I thought this was just a matter of adjusting the configuration, but it seems there's much more wrong than just that - so I wasn't too worried. Last night, I updated the configuration to ensure that the appropriate connector configuration symbols were enabled (see the changelog in the configuration seeds.) All the time that stuff on OMAP gets broken and/or doesn't work (inspite of repeated attempts at reporting problems - I've never seen the displays on the SDP4430 board ever work with a mainline kernel in all the years I've had the platform - but they have worked with the originally supplied TI kernels) I really find myself not really caring very much about OMAP and whether it works or not. Quite honestly, I regard OMAP as nothing more than an overly complex toy implementation rather than a serious architecture because of this kind of stuff - unlike every other ARM platform where stuff like this "just works", OMAP stuff is always seems to be much harder to make work, and more prone to stuff breaking. So, here goes. LDP3430: OMAP DSS rev 2.0 omapdss DPI error: can't get VDDS_DSI regulator omapfb omapfb: failed to connect default display omapfb omapfb: failed to init overlay connections omapfb omapfb: failed to setup omapfb platform omapfb: Driver omapfb requests probe deferral I don't see evidence of it being re-probed, but I do see this during boot which implies that there's nothing there: XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0" after 0 requests (0 known processed) with 0 events remaining. For the SDP4430, it used to detect the displays, even though nothing has ever been displayed on them. Now it just spits out this: OMAP DSS rev 4.0 omapdss DSI error: can't get VDDS_DSI regulator panel-dsi-cm panel-dsi-cm.0: Failed to connect to video source omapfb omapfb: failed to connect default display omapfb omapfb: failed to init overlay connections omapfb omapfb: failed to setup omapfb platform omapfb: Driver omapfb requests probe deferral ... omapdss DSI error: failed to set complexio power state to 1 panel-dsi-cm panel-dsi-cm.0: failed to enable DSI omapfb omapfb: Failed to enable display 'lcd' omapfb omapfb: failed to initialize default display omapfb omapfb: failed to setup omapfb Configurations, build and boot logs are all on http://www.arm.linux.org.uk/developer/build/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html