On 17/06/2020 09:04, Tomi Valkeinen wrote:
On 16/06/2020 19:56, Grygorii Strashko wrote:
On 16/06/2020 18:30, Tony Lindgren wrote:
* Tomi Valkeinen [200616 13:02]:
On 11/06/2020 17:00, Grygorii Strashko wrote:
I think, suspend might be fixed if all devices, which are now child of
On 16/06/2020 19:56, Grygorii Strashko wrote:
On 16/06/2020 18:30, Tony Lindgren wrote:
* Tomi Valkeinen [200616 13:02]:
On 11/06/2020 17:00, Grygorii Strashko wrote:
I think, suspend might be fixed if all devices, which are now child of ti-sysc,
will do
pm_runtime_force_xxx() calls at
On 16/06/2020 18:30, Tony Lindgren wrote:
* Tomi Valkeinen [200616 13:02]:
On 11/06/2020 17:00, Grygorii Strashko wrote:
I think, suspend might be fixed if all devices, which are now child of ti-sysc,
will do
pm_runtime_force_xxx() calls at noirq suspend stage by adding:
* Tomi Valkeinen [200616 13:02]:
> On 11/06/2020 17:00, Grygorii Strashko wrote:
> > I think, suspend might be fixed if all devices, which are now child of
> > ti-sysc, will do
> > pm_runtime_force_xxx() calls at noirq suspend stage by adding:
> >
> >
On 11/06/2020 17:00, Grygorii Strashko wrote:
On 09/06/2020 18:26, Tomi Valkeinen wrote:
On 09/06/2020 18:19, Tony Lindgren wrote:
But there's an extra runtime PM reference (dev.power.usage_count) that seems
to come out of nowhere. So when omap_drm_suspend is finished, there's still
* Grygorii Strashko [200611 13:59]:
> I think, suspend might be fixed if all devices, which are now child of
> ti-sysc, will do
> pm_runtime_force_xxx() calls at noirq suspend stage by adding:
>
> SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
>
On 09/06/2020 18:26, Tomi Valkeinen wrote:
On 09/06/2020 18:19, Tony Lindgren wrote:
But there's an extra runtime PM reference (dev.power.usage_count) that seems
to come out of nowhere. So when omap_drm_suspend is finished, there's still
usage_count of 1, and dispc never suspends fully.
* Tomi Valkeinen [200610 11:48]:
> On 09/06/2020 20:10, Tony Lindgren wrote:
>
> > > On beagle-x15 I see these errors after modprobe:
> > >
> > > DSS: OMAP DSS rev 6.1
> > > omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops
> > > [omapdss])
> > > omapdss_dss 5800.dss:
On 09/06/2020 20:10, Tony Lindgren wrote:
On beagle-x15 I see these errors after modprobe:
DSS: OMAP DSS rev 6.1
omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops
[omapdss])
omapdss_dss 5800.dss: bound 5804.encoder (ops hdmi5_component_ops
[omapdss])
[drm]
* Tony Lindgren [200609 17:11]:
> I'm also seeing the rmmod omapdrm issue on am437x-sk-evm:
Oops sorry this is a user error. I've forgotten I need
to unbind the fb vtcon first :) thanks for hinting that
Tomi!
I can rmmod omapdrm just fine after doing:
# echo 0 >
* Tony Lindgren [200609 16:53]:
> * Tomi Valkeinen [200609 15:27]:
> > On 09/06/2020 18:19, Tony Lindgren wrote:
> > > Currently I'm only able to rmmod -f omapdrm, not sure if these issues
> > > might
> > > be related.
> >
> > Hmm, I always use modules, and can unload omapdrm and drm fine. But
* Tomi Valkeinen [200609 15:27]:
> On 09/06/2020 18:19, Tony Lindgren wrote:
> > Currently I'm only able to rmmod -f omapdrm, not sure if these issues might
> > be related.
>
> Hmm, I always use modules, and can unload omapdrm and drm fine. But there's
> a sequence that must be followed.
On 09/06/2020 18:19, Tony Lindgren wrote:
But there's an extra runtime PM reference (dev.power.usage_count) that seems
to come out of nowhere. So when omap_drm_suspend is finished, there's still
usage_count of 1, and dispc never suspends fully.
Hmm no idea about that. My guess is that there
* Tomi Valkeinen [200609 07:05]:
> On 03/06/2020 17:06, Tony Lindgren wrote:
> > * Tomi Valkeinen [200603 12:34]:
> > > Hi Tony,
> > >
> > > On 31/05/2020 22:39, Tony Lindgren wrote:
> > > > When booting without legacy platform data, we no longer have omap_device
> > > > calling PM runtime
On 03/06/2020 17:06, Tony Lindgren wrote:
* Tomi Valkeinen [200603 12:34]:
Hi Tony,
On 31/05/2020 22:39, Tony Lindgren wrote:
When booting without legacy platform data, we no longer have omap_device
calling PM runtime suspend for us on suspend. This causes the driver
context not be saved as
* Tomi Valkeinen [200603 12:34]:
> Hi Tony,
>
> On 31/05/2020 22:39, Tony Lindgren wrote:
> > When booting without legacy platform data, we no longer have omap_device
> > calling PM runtime suspend for us on suspend. This causes the driver
> > context not be saved as we have no suspend and
Hi Tony,
On 31/05/2020 22:39, Tony Lindgren wrote:
When booting without legacy platform data, we no longer have omap_device
calling PM runtime suspend for us on suspend. This causes the driver
context not be saved as we have no suspend and resume functions defined.
Let's fix the issue by
When booting without legacy platform data, we no longer have omap_device
calling PM runtime suspend for us on suspend. This causes the driver
context not be saved as we have no suspend and resume functions defined.
Let's fix the issue by switching over to use UNIVERSAL_DEV_PM_OPS as it
will call
18 matches
Mail list logo
