linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  reply	other threads:[~2013-12-20 16:04 UTC|newest]

Thread overview: 22+ 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 13:54 ` Tomi Valkeinen
2013-12-18 15:29   ` Russell King - ARM Linux
2013-12-18 16:03     ` Tomi Valkeinen
2013-12-18 18:23   ` Tony Lindgren
2013-12-19  5:23     ` Tomi Valkeinen
2013-12-19 16:56       ` Tony Lindgren
2013-12-20  7:45         ` Tomi Valkeinen
2013-12-19 17:56     ` Russell King - ARM Linux
2013-12-19 18:22       ` Tony Lindgren
2013-12-20 11:27         ` Russell King - ARM Linux
2013-12-20 11:48           ` Russell King - ARM Linux
2013-12-20 13:43             ` Tomi Valkeinen
2013-12-20 16:04               ` Tony Lindgren [this message]
2013-12-20 16:55                 ` Tony Lindgren
2013-12-21  0:59                   ` Russell King - ARM Linux
2013-12-28 23:30                     ` Russell King - ARM Linux
2013-12-23  7:53                   ` Tomi Valkeinen
2013-12-27 18:11                     ` Tony Lindgren
2013-12-23  7:49                 ` Tomi Valkeinen
2013-12-20 16:10           ` Tony Lindgren
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 \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).