From: Tony Lindgren <tony@atomide.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: OMAP display subsystem - does it work?
Date: Fri, 20 Dec 2013 08:04:33 -0800 [thread overview]
Message-ID: <20131220160432.GZ27438@atomide.com> (raw)
In-Reply-To: <52B44982.4020501@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131220 05:45]:
> On 2013-12-20 13:48, Russell King - ARM Linux wrote:
> > On Fri, Dec 20, 2013 at 11:27:01AM +0000, 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
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: OMAP display subsystem - does it work?
Date: Fri, 20 Dec 2013 08:04:33 -0800 [thread overview]
Message-ID: <20131220160432.GZ27438@atomide.com> (raw)
In-Reply-To: <52B44982.4020501@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131220 05:45]:
> On 2013-12-20 13:48, Russell King - ARM Linux wrote:
> > On Fri, Dec 20, 2013 at 11:27:01AM +0000, 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
next prev parent reply other threads:[~2013-12-20 16:04 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-18 12:00 OMAP display subsystem - does it work? Russell King - ARM Linux
2013-12-18 12:00 ` Russell King - ARM Linux
2013-12-18 13:54 ` Tomi Valkeinen
2013-12-18 13:54 ` Tomi Valkeinen
2013-12-18 15:29 ` Russell King - ARM Linux
2013-12-18 15:29 ` Russell King - ARM Linux
2013-12-18 16:03 ` Tomi Valkeinen
2013-12-18 16:03 ` Tomi Valkeinen
2013-12-18 18:23 ` Tony Lindgren
2013-12-18 18:23 ` Tony Lindgren
2013-12-19 5:23 ` Tomi Valkeinen
2013-12-19 5:23 ` Tomi Valkeinen
2013-12-19 16:56 ` Tony Lindgren
2013-12-19 16:56 ` Tony Lindgren
2013-12-20 7:45 ` Tomi Valkeinen
2013-12-20 7:45 ` Tomi Valkeinen
2013-12-19 17:56 ` Russell King - ARM Linux
2013-12-19 17:56 ` Russell King - ARM Linux
2013-12-19 18:22 ` Tony Lindgren
2013-12-19 18:22 ` Tony Lindgren
2013-12-20 11:27 ` Russell King - ARM Linux
2013-12-20 11:27 ` Russell King - ARM Linux
2013-12-20 11:48 ` Russell King - ARM Linux
2013-12-20 11:48 ` Russell King - ARM Linux
2013-12-20 13:43 ` Tomi Valkeinen
2013-12-20 13:43 ` Tomi Valkeinen
2013-12-20 16:04 ` Tony Lindgren [this message]
2013-12-20 16:04 ` Tony Lindgren
2013-12-20 16:55 ` Tony Lindgren
2013-12-20 16:55 ` Tony Lindgren
2013-12-21 0:59 ` Russell King - ARM Linux
2013-12-21 0:59 ` Russell King - ARM Linux
2013-12-28 23:30 ` Russell King - ARM Linux
2013-12-28 23:30 ` Russell King - ARM Linux
2013-12-23 7:53 ` Tomi Valkeinen
2013-12-23 7:53 ` Tomi Valkeinen
2013-12-27 18:11 ` Tony Lindgren
2013-12-27 18:11 ` Tony Lindgren
2013-12-23 7:49 ` Tomi Valkeinen
2013-12-23 7:49 ` Tomi Valkeinen
2013-12-20 16:10 ` Tony Lindgren
2013-12-20 16:10 ` Tony Lindgren
2013-12-19 17:53 ` Russell King - ARM Linux
2013-12-19 17:53 ` Russell King - ARM Linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131220160432.GZ27438@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=tomi.valkeinen@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.