On 05/05/2021 14:12, Tony Lindgren wrote:
* Tony Lindgren [210503 12:18]:
I think we still fix the dispc related issue too, otherwise the parent
child_count will just keep increasing on each suspend. I check that
again though.
After tons more debugging, I found the root cause for the parent c
* Tony Lindgren [210503 12:18]:
> I think we still fix the dispc related issue too, otherwise the parent
> child_count will just keep increasing on each suspend. I check that
> again though.
After tons more debugging, I found the root cause for the parent child_count
increasing and posted a patch
* Tony Lindgren [210503 11:16]:
> ..the use of pm_runtime_put_sync() like you suggested. I did a quick
> test with the minimal change below and that works :) Seems like that's
> probably the best minimal fix for the -rc cycle.
Sorry I was mistaken, the patch below won't help for the omapdrm
PM ru
Hi,
* Tony Lindgren [210503 10:45]:
> * Tomi Valkeinen [210503 08:04]:
> > On 29/04/2021 07:46, Tony Lindgren wrote:
> > > Decoupling the system suspend and resume from PM runtime calls for
> > > all the other dss components should still also be done IMO. But that
> > > can be done as a separate
* Tomi Valkeinen [210503 08:04]:
> On 29/04/2021 07:46, Tony Lindgren wrote:
> > I think the remaining issue is how dispc should provide services to
> > the other components.
> >
> > If dispc needs to be enabled to provide services to the other modules,
> > maybe there's some better Linux generic
On 29/04/2021 07:46, Tony Lindgren wrote:
Hi,
* Laurent Pinchart [210428 14:10]:
Based on my experience on the camera and display side with devices that
are made of multiple components, suspend and resume are best handled in
a controlled way by the top-level driver. Otherwise you end up having
Hi,
* Laurent Pinchart [210428 14:10]:
> Based on my experience on the camera and display side with devices that
> are made of multiple components, suspend and resume are best handled in
> a controlled way by the top-level driver. Otherwise you end up having
> different components suspending and
Hi Tony,
Thank you for the patch.
On Wed, Apr 28, 2021 at 12:25:00PM +0300, Tony Lindgren wrote:
> On resume, dispc pm_runtime_force_resume() is not enabling the hardware
> as we pass the pm_runtime_need_not_resume() test as the device is suspended
> with no child devices.
>
> As the resume cont
On resume, dispc pm_runtime_force_resume() is not enabling the hardware
as we pass the pm_runtime_need_not_resume() test as the device is suspended
with no child devices.
As the resume continues, omap_atomic_comit_tail() calls dispc_runtime_get()
that calls rpm_resume() enabling the hardware, and
