From: Kevin Hilman <khilman@deeprootsystems.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: grinberg@compulab.co.il, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: OMAP baseline test results for v3.7-rc2
Date: Tue, 23 Oct 2012 11:19:54 -0700 [thread overview]
Message-ID: <87objt8305.fsf@deeprootsystems.com> (raw)
In-Reply-To: <87r4oqc833.fsf@deeprootsystems.com> (Kevin Hilman's message of "Mon, 22 Oct 2012 18:04:16 -0700")
Kevin Hilman <khilman@deeprootsystems.com> writes:
> +Igor
>
> Paul Walmsley <paul@pwsan.com> writes:
>
>> Here are some basic OMAP test results for Linux v3.7-rc2.
>> Logs and other details at:
>>
>> http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
>
> [...]
>
>> * 37xx EVM: CORE not entering dynamic off-idle
>> - Cause unknown; dynamic retention-idle seems to work; system suspend to
>> off works
>
> I got a start on this one, and discovered (using CM_IDLEST1_CORE) that
> SPI1 was not idle when going off. A quick hack disabling the
> touchscreen showed that after that, core was hitting idle just fine.
>
> I ran out of time today debugging this, but it's definitely realted to
> the GPIO debounce setting for the touchscreen. Changing it to zero[1]
> makes CORE hit retention again in idle.
OK, found the root cause of this in the GPIO driver. Patch submitted:
http://marc.info/?l=linux-omap&m=135101577925972&w=2
however...
> Igor, I'm hoping you might know what's going on here since we already
> had some problems with this ads7846 init stuff and you're more familiar
> with this debounce init.
... board files that are setting debounce values for ads7846 will no
longer work.
Currently, omap_ads7846_init() in common-board-devices.c does this:
gpio_request_one()
gpio_set_debounce()
gpio_free()
because of a bug in the GPIO driver, the debounce settings were sticky
and lingered even after the gpio_free(). That bug has been fixed by the
above patch, which means the above gpio_set_debounce() is completely
pointless because it's followed immediately by a gpio_free().
IMO, the whole GPIO init for the ads7846 needs a rethink as it's
currently partially done by common-board-devices.c and done (again) in
the ads7846 driver. If the gpio_free() isn't done in
common-board-devices, then the ads7846 driver will currently fail to
probe/load becasue it can't request a GPIO line.
Having found and fixed the PM regression, I'll leave the ads7846 cleanup to
somone else.
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: khilman@deeprootsystems.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: OMAP baseline test results for v3.7-rc2
Date: Tue, 23 Oct 2012 11:19:54 -0700 [thread overview]
Message-ID: <87objt8305.fsf@deeprootsystems.com> (raw)
In-Reply-To: <87r4oqc833.fsf@deeprootsystems.com> (Kevin Hilman's message of "Mon, 22 Oct 2012 18:04:16 -0700")
Kevin Hilman <khilman@deeprootsystems.com> writes:
> +Igor
>
> Paul Walmsley <paul@pwsan.com> writes:
>
>> Here are some basic OMAP test results for Linux v3.7-rc2.
>> Logs and other details at:
>>
>> http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
>
> [...]
>
>> * 37xx EVM: CORE not entering dynamic off-idle
>> - Cause unknown; dynamic retention-idle seems to work; system suspend to
>> off works
>
> I got a start on this one, and discovered (using CM_IDLEST1_CORE) that
> SPI1 was not idle when going off. A quick hack disabling the
> touchscreen showed that after that, core was hitting idle just fine.
>
> I ran out of time today debugging this, but it's definitely realted to
> the GPIO debounce setting for the touchscreen. Changing it to zero[1]
> makes CORE hit retention again in idle.
OK, found the root cause of this in the GPIO driver. Patch submitted:
http://marc.info/?l=linux-omap&m=135101577925972&w=2
however...
> Igor, I'm hoping you might know what's going on here since we already
> had some problems with this ads7846 init stuff and you're more familiar
> with this debounce init.
... board files that are setting debounce values for ads7846 will no
longer work.
Currently, omap_ads7846_init() in common-board-devices.c does this:
gpio_request_one()
gpio_set_debounce()
gpio_free()
because of a bug in the GPIO driver, the debounce settings were sticky
and lingered even after the gpio_free(). That bug has been fixed by the
above patch, which means the above gpio_set_debounce() is completely
pointless because it's followed immediately by a gpio_free().
IMO, the whole GPIO init for the ads7846 needs a rethink as it's
currently partially done by common-board-devices.c and done (again) in
the ads7846 driver. If the gpio_free() isn't done in
common-board-devices, then the ads7846 driver will currently fail to
probe/load becasue it can't request a GPIO line.
Having found and fixed the PM regression, I'll leave the ads7846 cleanup to
somone else.
Kevin
next prev parent reply other threads:[~2012-10-23 18:19 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-20 21:26 OMAP baseline test results for v3.7-rc2 Paul Walmsley
2012-10-20 21:26 ` Paul Walmsley
2012-10-21 17:06 ` Paul Walmsley
2012-10-21 17:06 ` Paul Walmsley
2012-10-22 16:10 ` Jon Hunter
2012-10-22 16:10 ` Jon Hunter
2012-10-22 17:17 ` Paul Walmsley
2012-10-22 17:17 ` Paul Walmsley
2012-10-22 17:18 ` Paul Walmsley
2012-10-22 17:18 ` Paul Walmsley
2012-10-22 16:28 ` Jon Hunter
2012-10-22 16:28 ` Jon Hunter
2012-10-22 16:38 ` Tony Lindgren
2012-10-22 16:38 ` Tony Lindgren
2012-10-23 19:34 ` Paul Walmsley
2012-10-23 19:34 ` Paul Walmsley
2012-10-22 18:35 ` Paul Walmsley
2012-10-22 18:35 ` Paul Walmsley
2012-10-22 18:36 ` Paul Walmsley
2012-10-22 18:36 ` Paul Walmsley
2012-10-22 18:50 ` Jon Hunter
2012-10-22 18:50 ` Jon Hunter
2012-10-22 18:48 ` Jon Hunter
2012-10-22 18:48 ` Jon Hunter
2012-10-23 1:53 ` Matt Porter
2012-10-23 1:53 ` Matt Porter
2012-10-23 3:15 ` Paul Walmsley
2012-10-23 3:15 ` Paul Walmsley
2012-10-23 4:57 ` Paul Walmsley
2012-10-23 4:57 ` Paul Walmsley
2012-10-23 12:24 ` Matt Porter
2012-10-23 12:24 ` Matt Porter
2012-10-23 13:11 ` Matt Porter
2012-10-23 13:11 ` Matt Porter
2012-10-23 21:03 ` Kevin Hilman
2012-10-23 21:03 ` Kevin Hilman
2012-10-23 21:11 ` Matt Porter
2012-10-23 21:11 ` Matt Porter
2012-10-25 14:14 ` Kevin Hilman
2012-10-25 14:14 ` Kevin Hilman
2012-10-23 1:04 ` Kevin Hilman
2012-10-23 1:04 ` Kevin Hilman
2012-10-23 18:19 ` Kevin Hilman [this message]
2012-10-23 18:19 ` Kevin Hilman
2012-10-24 9:01 ` Igor Grinberg
2012-10-24 9:01 ` Igor Grinberg
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=87objt8305.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=grinberg@compulab.co.il \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.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.