On Thu, Jan 16, 2020 at 10:14 AM Alex Deucher wrote:
>
> On Wed, Jan 15, 2020 at 2:44 AM Daniel Drake wrote:
> >
> > On Thu, Dec 19, 2019 at 10:08 PM Alex Deucher wrote:
> > > I think there may be some AMD specific handling needed in
> > > drivers/acpi/sleep.c. My understanding from reading the
On Thu, Jan 16, 2020 at 11:15 PM Alex Deucher wrote:
> It's just papering over the problem. It would be better from a power
> perspective for the driver to just not suspend and keep running like
> normal. When the driver is not suspended runtime things like clock
> and power gating are active wh
On Wed, Jan 15, 2020 at 2:44 AM Daniel Drake wrote:
>
> On Thu, Dec 19, 2019 at 10:08 PM Alex Deucher wrote:
> > I think there may be some AMD specific handling needed in
> > drivers/acpi/sleep.c. My understanding from reading the modern
> > standby documents from MS is that each vendor needs to
On Thu, Dec 19, 2019 at 10:08 PM Alex Deucher wrote:
> I think there may be some AMD specific handling needed in
> drivers/acpi/sleep.c. My understanding from reading the modern
> standby documents from MS is that each vendor needs to provide a
> platform specific PEP driver. I'm not sure how mu
On Mon, Dec 16, 2019 at 4:00 AM Daniel Drake wrote:
>
> Hi Alex,
>
> On Mon, Nov 25, 2019 at 1:17 PM Daniel Drake wrote:
> > Unfortunately not. The original issue still exists (dead gfx after
> > resume from s2idle) and also when I trigger execution of the suspend
> > or runtime suspend routines
Hi Alex,
On Mon, Nov 25, 2019 at 1:17 PM Daniel Drake wrote:
> Unfortunately not. The original issue still exists (dead gfx after
> resume from s2idle) and also when I trigger execution of the suspend
> or runtime suspend routines the power usage increases around 1.5W as
> before.
>
> Have you co
On Fri, Nov 22, 2019 at 11:32 PM Alex Deucher wrote:
> Do these patches help?
> https://patchwork.freedesktop.org/patch/341775/
> https://patchwork.freedesktop.org/patch/341968/
Unfortunately not. The original issue still exists (dead gfx after
resume from s2idle) and also when I trigger executio
On Wed, Oct 16, 2019 at 3:24 AM Daniel Drake wrote:
>
> On Wed, Oct 16, 2019 at 2:43 AM Alex Deucher wrote:
> > Is s2idle actually powering down the GPU?
>
> My understanding is that s2idle (at a high level) just calls all
> devices suspend routines and then puts the CPU into its deepest
> runnin
On Wed, Oct 16, 2019 at 2:43 AM Alex Deucher wrote:
> Is s2idle actually powering down the GPU?
My understanding is that s2idle (at a high level) just calls all
devices suspend routines and then puts the CPU into its deepest
running state.
So if there is something special to be done to power off
On Tue, Oct 15, 2019 at 2:50 AM Daniel Drake wrote:
>
> On Asus UX434DA (Ryzen7 3700U), upon resume from s2idle, the screen
> turns on again and shows the pre-suspend image, but the display remains
> frozen from that point onwards.
>
> The kernel logs show errors:
>
> [drm] psp command failed and
On Asus UX434DA (Ryzen7 3700U), upon resume from s2idle, the screen
turns on again and shows the pre-suspend image, but the display remains
frozen from that point onwards.
The kernel logs show errors:
[drm] psp command failed and response status is (0x7)
[drm] Fence fallback timer expired on ri
11 matches
Mail list logo
