On Thu, 2012-06-28 at 13:16 +0530, Jassi Brar wrote:
> On 28 June 2012 12:11, Tomi Valkeinen wrote:
> > On Wed, 2012-06-27 at 20:23 +0530, Jassi Brar wrote:
> >> On 27 June 2012 13:43, Tomi Valkeinen wrote:
> >> >
> >> > I don't like it at all that omapdss disables and enables the panels in
> >>
On 28 June 2012 12:11, Tomi Valkeinen wrote:
> On Wed, 2012-06-27 at 20:23 +0530, Jassi Brar wrote:
>> On 27 June 2012 13:43, Tomi Valkeinen wrote:
>> >
>> > I don't like it at all that omapdss disables and enables the panels in
>> > omapdss's suspend/resume hooks. But I'm not sure how this shoul
On Wed, 2012-06-27 at 20:23 +0530, Jassi Brar wrote:
> On 27 June 2012 13:43, Tomi Valkeinen wrote:
> >
> > I don't like it at all that omapdss disables and enables the panels in
> > omapdss's suspend/resume hooks. But I'm not sure how this should work...
> > Should panel drivers each have their o
On 27 June 2012 13:43, Tomi Valkeinen wrote:
>
> I don't like it at all that omapdss disables and enables the panels in
> omapdss's suspend/resume hooks. But I'm not sure how this should work...
> Should panel drivers each have their own suspend/resume hooks, and
> handle it themselves? Or should
On Wed, 2012-06-27 at 13:11 +0530, Jassi Brar wrote:
> On 27 June 2012 11:28, Tomi Valkeinen wrote:
> >
> > It doesn't matter how omapdss is organized, -EACCES _is_ an error. It
> > tells us that something unexpected happened, and we should react to it
> > somehow.
> >
> $ git show 5025ce070
> E
On 27 June 2012 11:28, Tomi Valkeinen wrote:
>
> It doesn't matter how omapdss is organized, -EACCES _is_ an error. It
> tells us that something unexpected happened, and we should react to it
> somehow.
>
$ git show 5025ce070
Exactly how omapdss is organised is the reason -EBUSY isn't an error t
On Wed, 2012-06-27 at 10:12 +0530, Jassi Brar wrote:
> > True. But the HW could also be in disabled state. And that would lead to
> > a crash when accessing the registers.
> >
> > It is not a fatal error if pm_runtime_get returns -EACCES, but we sure
> > shouldn't ignore it (or avoid it with pm_ru
On 27 June 2012 00:14, Tomi Valkeinen wrote:
> On Tue, 2012-06-26 at 22:31 +0530, Jassi Brar wrote:
>>
>> > But if pm_runtime_get_sync() returns an error, it means the HW has not
>> > been resumed successfully, and is not operational,
>> >
>> Not always. The HW could be in RPM_ACTIVE state while P
On Tue, 2012-06-26 at 22:31 +0530, Jassi Brar wrote:
> While I think your patch is simpler and achieve the same, I also think
> your fears about this patch are unfounded.
Perhaps. But I do get a bad feeling from your patch, and I don't like
when that happens =). What I fear with changes like you
On 26 June 2012 20:41, Tomi Valkeinen wrote:
> On Tue, 2012-06-26 at 20:39 +0530, Jassi Brar wrote:
>> On 26 June 2012 20:38, Tomi Valkeinen wrote:
>> > On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote:
>> >> On 26 June 2012 17:33, Tomi Valkeinen wrote:
>> >> > On Tue, 2012-06-26 at 15:27 +05
On Tue, 2012-06-26 at 20:39 +0530, Jassi Brar wrote:
> On 26 June 2012 20:38, Tomi Valkeinen wrote:
> > On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote:
> >> On 26 June 2012 17:33, Tomi Valkeinen wrote:
> >> > On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
> >> >
> >> >> Seems similar,
On Tue, 26 Jun 2012, Tomi Valkeinen wrote:
> > Failure to suspend a device should not be regarded as particularly bad,
> > because it doesn't affect the device's functionality. That's true even
> > when CONFIG_RUNTIME_PM is enabled.
>
> This makes sense. So if CONFIG_RUNTIME_PM=n, using pm_run
On 26 June 2012 20:38, Tomi Valkeinen wrote:
> On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote:
>> On 26 June 2012 17:33, Tomi Valkeinen wrote:
>> > On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
>> >
>> >> Seems similar, but I only tested OMAP4 HDMI.
>> >
>> > Would something like this
On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote:
> On 26 June 2012 17:33, Tomi Valkeinen wrote:
> > On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
> >
> >> Seems similar, but I only tested OMAP4 HDMI.
> >
> > Would something like this one below work for you? It fixes the issues on
> > my
On Tue, 2012-06-26 at 10:34 -0400, Alan Stern wrote:
> On Tue, 26 Jun 2012, Grazvydas Ignotas wrote:
>
> > CCing some PM people, maybe they can comment?
> >
> > On Tue, Jun 26, 2012 at 7:51 AM, Rajendra Nayak wrote:
> > > On Monday 25 June 2012 06:20 PM, Tomi Valkeinen wrote:
> > >>
> > >> Do yo
On 26 June 2012 17:33, Tomi Valkeinen wrote:
> On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
>
>> Seems similar, but I only tested OMAP4 HDMI.
>
> Would something like this one below work for you? It fixes the issues on
> my overo board.
>
I think this should work too (I will get to test it
On Tue, 26 Jun 2012, Grazvydas Ignotas wrote:
> CCing some PM people, maybe they can comment?
>
> On Tue, Jun 26, 2012 at 7:51 AM, Rajendra Nayak wrote:
> > On Monday 25 June 2012 06:20 PM, Tomi Valkeinen wrote:
> >>
> >> Do you know how the drivers should handle CONFIG_PM_RUNTIME=n?
> >> Are th
CCing some PM people, maybe they can comment?
On Tue, Jun 26, 2012 at 7:51 AM, Rajendra Nayak wrote:
> On Monday 25 June 2012 06:20 PM, Tomi Valkeinen wrote:
>>
>> Do you know how the drivers should handle CONFIG_PM_RUNTIME=n?
>> Are they supposed to handle the error values returned by runtime PM
On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
> Seems similar, but I only tested OMAP4 HDMI.
Would something like this one below work for you? It fixes the issues on
my overo board.
Instead of using omapdss device's suspend/resume callbacks, this one
uses PM notifier calls which happen be
On 26 June 2012 14:37, Tomi Valkeinen wrote:
> On Tue, 2012-06-26 at 14:02 +0530, Jassi Brar wrote:
>
>> Something non-omapdss in vanilla breaks suspend/resume.
>
> I was able to reproduce (probably) the same issue with omap3 overo. Does
> this looks familiar:
>
> [ 2267.140197] [ cut
On 06/26/12 16:32, the mail apparently from Jassi Brar included:
On 26 June 2012 12:49, Tomi Valkeinen wrote:
On Mon, 2012-06-25 at 22:36 +0530, Jassi Brar wrote:
Normally if the driver does dispc_runtime_get() and dispc_read_reg(),
the first call will enable the HW so the reg read works.
On Tue, 2012-06-26 at 14:02 +0530, Jassi Brar wrote:
> Something non-omapdss in vanilla breaks suspend/resume.
I was able to reproduce (probably) the same issue with omap3 overo. Does
this looks familiar:
[ 2267.140197] [ cut here ]
[ 2267.145172] WARNING: at drivers/vide
On 26 June 2012 12:49, Tomi Valkeinen wrote:
> On Mon, 2012-06-25 at 22:36 +0530, Jassi Brar wrote:
>> >
>> > Normally if the driver does dispc_runtime_get() and dispc_read_reg(),
>> > the first call will enable the HW so the reg read works.
>> >
>> > But if the pm_runtime is disabled, say, durin
On Mon, 2012-06-25 at 22:36 +0530, Jassi Brar wrote:
> On 25 June 2012 19:19, Tomi Valkeinen wrote:
> > On Mon, 2012-06-25 at 19:01 +0530, Jassi Brar wrote:
>
> >> > /* this accesses a register, but the HW is disabled? */
> >> > dispc_read_reg(FOO);
> >> >
> >> the H/W is already always enab
On Monday 25 June 2012 06:20 PM, Tomi Valkeinen wrote:
On Mon, 2012-06-25 at 18:12 +0530, Rajendra Nayak wrote:
On Monday 25 June 2012 06:00 PM, Tomi Valkeinen wrote:
On Mon, 2012-06-25 at 15:05 +0300, Grazvydas Ignotas wrote:
On Mon, Jun 25, 2012 at 9:20 AM, Tomi Valkeinen wrote:
On Sat, 2
On 25 June 2012 19:19, Tomi Valkeinen wrote:
> On Mon, 2012-06-25 at 19:01 +0530, Jassi Brar wrote:
>> > /* this accesses a register, but the HW is disabled? */
>> > dispc_read_reg(FOO);
>> >
>> the H/W is already always enabled if CONFIG_PM_RUNTIME is not defined.
>>
>> If CONFIG_PM_RUNTIME
On Mon, 2012-06-25 at 19:01 +0530, Jassi Brar wrote:
> On 25 June 2012 18:11, Tomi Valkeinen wrote:
> > On Mon, 2012-06-25 at 17:57 +0530, Jassi Brar wrote:
> >> On 25 June 2012 15:00, Tomi Valkeinen wrote:
> >
> >> > The driver needs to enable the HW and the call to pm_runtime_get() is
> >> > sk
On 25 June 2012 18:11, Tomi Valkeinen wrote:
> On Mon, 2012-06-25 at 17:57 +0530, Jassi Brar wrote:
>> On 25 June 2012 15:00, Tomi Valkeinen wrote:
>
>> > The driver needs to enable the HW and the call to pm_runtime_get() is
>> > skipped. Won't this lead to crash as the DSS registers are accessed
On Mon, 2012-06-25 at 18:12 +0530, Rajendra Nayak wrote:
> On Monday 25 June 2012 06:00 PM, Tomi Valkeinen wrote:
> > On Mon, 2012-06-25 at 15:05 +0300, Grazvydas Ignotas wrote:
> >> On Mon, Jun 25, 2012 at 9:20 AM, Tomi Valkeinen
> >> wrote:
> >>> On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si.
On Monday 25 June 2012 06:00 PM, Tomi Valkeinen wrote:
On Mon, 2012-06-25 at 15:05 +0300, Grazvydas Ignotas wrote:
On Mon, Jun 25, 2012 at 9:20 AM, Tomi Valkeinen wrote:
On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:
Currenlty HDMI fails to come up in the suspend-resu
On Mon, 2012-06-25 at 17:57 +0530, Jassi Brar wrote:
> On 25 June 2012 15:00, Tomi Valkeinen wrote:
> > The driver needs to enable the HW and the call to pm_runtime_get() is
> > skipped. Won't this lead to crash as the DSS registers are accessed
> > without the HW in enabled state?
> >
> Hmm...
On 25 June 2012 17:35, Grazvydas Ignotas wrote:
> On Mon, Jun 25, 2012 at 9:20 AM, Tomi Valkeinen wrote:
>> On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:
>>>
>>> Currenlty HDMI fails to come up in the suspend-resume path.
>>> This patch helps that real-world scenario.
>>
>
On Mon, 2012-06-25 at 15:05 +0300, Grazvydas Ignotas wrote:
> On Mon, Jun 25, 2012 at 9:20 AM, Tomi Valkeinen wrote:
> > On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:
> >>
> >> Currenlty HDMI fails to come up in the suspend-resume path.
> >> This patch helps that real-world
On 25 June 2012 15:00, Tomi Valkeinen wrote:
> On Mon, 2012-06-25 at 14:19 +0530, Jassi Brar wrote:
>> On 25 June 2012 11:50, Tomi Valkeinen wrote:
>> > On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:
>>
>> >> Currenlty HDMI fails to come up in the suspend-resume path.
On Mon, Jun 25, 2012 at 9:20 AM, Tomi Valkeinen wrote:
> On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:
>>
>> Currenlty HDMI fails to come up in the suspend-resume path.
>> This patch helps that real-world scenario.
>
> What is the problem there? It'd be good to explain the
On Mon, 2012-06-25 at 14:19 +0530, Jassi Brar wrote:
> On 25 June 2012 11:50, Tomi Valkeinen wrote:
> > On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:
>
> >> Currenlty HDMI fails to come up in the suspend-resume path.
> >> This patch helps that real-world scenario.
> >
On 25 June 2012 11:50, Tomi Valkeinen wrote:
> On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:
>> Currenlty HDMI fails to come up in the suspend-resume path.
>> This patch helps that real-world scenario.
>
> What is the problem there? It'd be good to explain the problem
On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:
> From: Jassi Brar
>
> If the runtime PM of the device is disabled (for example in resume from
> suspend path), it doesn't make sense to attempt pm_runtime_get/put, esp
> when their return values affect the control flow path.
T
From: Jassi Brar
If the runtime PM of the device is disabled (for example in resume from
suspend path), it doesn't make sense to attempt pm_runtime_get/put, esp
when their return values affect the control flow path.
Signed-off-by: Jassi Brar
---
Currenlty HDMI fails to come up in the suspend-
39 matches
Mail list logo
