I think the check should definately be removed. It is not right for
what we are trying to do -- best effort suspend. This driver contains
more than enough for success, and that ACPI bit is meaningless. At most
it is "advisory".
> From: Greg Steuck
> Date: Thu, 15 Aug 2024 20:36:03 -0700
>
> Mark Kettenis writes:
>
> > The diff also defines CONFIG_AMD_PMC and #ifdefs out the FADT check.
> > With that suspend-to-idle also works on that m715q. I'm still not
> > entirely sure what to do there. But I'll probably propose
Greg Steuck wrote:
> Mark Kettenis writes:
>
> > The diff also defines CONFIG_AMD_PMC and #ifdefs out the FADT check.
> > With that suspend-to-idle also works on that m715q. I'm still not
> > entirely sure what to do there. But I'll probably propose to commit
> > those separately such that we
Mark Kettenis writes:
> The diff also defines CONFIG_AMD_PMC and #ifdefs out the FADT check.
> With that suspend-to-idle also works on that m715q. I'm still not
> entirely sure what to do there. But I'll probably propose to commit
> those separately such that we can easily back those bits out.
On Fri, Aug 16, 2024 at 12:52:59AM +0200, Mark Kettenis wrote:
>
> That diff skips amdgpu_pmops_prepare(). Here is a better diff. And
> interestingly enough this fixes S3 suspend/resume on my m715q mini
> desktop with:
>
> amdgpu0: RAVEN GC 9.1.0 8 CU rev 0x01
I agree this diff is better.
>
> Date: Thu, 15 Aug 2024 13:54:00 +1000
> From: Jonathan Gray
>
> for in_s0ix to be set the activate function needs to
> call the pmops wrappers
>
> that may help
>
> amdgpu_pm_ops contains other function pointers that may
> also be of interest
>
> Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_drv.
> Date: Thu, 15 Aug 2024 15:02:08 +0200
> From: Mark Kettenis
>
> > From: Greg Steuck
> > Date: Wed, 14 Aug 2024 21:16:08 -0700
> >
> > Jonathan Gray writes:
> >
> > > for in_s0ix to be set the activate function needs to
> > > call the pmops wrappers
> > >
> > > that may help
> > >
> > > amdg
> Or maybe the code that checks S0i support is buggy?
Or maybe we should not be looking at this ACPI bit, and instead
carry on trying to do best-effort idle. It's better than not doing
anything.
> From: Greg Steuck
> Date: Wed, 14 Aug 2024 21:16:08 -0700
>
> Jonathan Gray writes:
>
> > for in_s0ix to be set the activate function needs to
> > call the pmops wrappers
> >
> > that may help
> >
> > amdgpu_pm_ops contains other function pointers that may
> > also be of interest
>
> Applyin
Jonathan Gray writes:
> for in_s0ix to be set the activate function needs to
> call the pmops wrappers
>
> that may help
>
> amdgpu_pm_ops contains other function pointers that may
> also be of interest
Applying this (and undoing the return true stampede) gets me into a
state where I can reliabl
for in_s0ix to be set the activate function needs to
call the pmops wrappers
that may help
amdgpu_pm_ops contains other function pointers that may
also be of interest
Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_drv.c
===
RCS file: /cvs
Greg Steuck writes:
> The patch below doesn't seem to have any effect. I still see the same
> unfinished sleep the second time around. The last dmesg entry then
> is still
>> config_suspend: wsdisplay0 0
>
> I'll try to run other experiments with not having started X at all.
Not having run X doe
Mark Kettenis writes:
> Certainly looks like a smoking gun to me.
>
> One thing to look at is amdgpu_acpi_is_s0ix_active() in
> dev/pci/drm/amd/amdgpu/amdgpu_acpi.c. That function should return
> true, but may be returning false because we don't #define CONFIG_AMD_PMC.
> So maybe try what happen
> From: Greg Steuck
> Date: Tue, 13 Aug 2024 21:13:19 -0700
>
> Greg Steuck writes:
>
> >> I suspect around wsdisplay_suspend() and wsdisplay_resume(); I've recently
> >> discovered that the mux aspects are insane.
> >
> > I applied the patches below and added a bunch of tracing to
> > subr_sus
On Tue, Aug 13, 2024 at 08:33:05PM -0700, Greg Steuck wrote:
> "Theo de Raadt" writes:
>
> > Here's more, but some of it is S3 related, or won't matter on your machine.
> >
> > it would be nice to see printf's in your subr_suspend.c to see where it
> > stops
> > the next time.
> >
> > I suspect
Greg Steuck writes:
>> I suspect around wsdisplay_suspend() and wsdisplay_resume(); I've recently
>> discovered that the mux aspects are insane.
>
> I applied the patches below and added a bunch of tracing to
> subr_suspend. First zzz:
I also added this:
modified sys/kern/subr_autoconf.c
@@ -
> From: Greg Steuck
> Date: Mon, 12 Aug 2024 18:46:51 -0700
>
> Now that my BIOS update took away S3 I started playing with zzz'ing to
> S0. The first time it seems to be working: the display turns off and the
> usb device are powered off. The power button brings everything back up
> and seemingl
Well you can do the same thing as the rest of us, sadly.
printf debugging!
"Theo de Raadt" writes:
>
> Index: sys/dev/pci/azalia.c
> ===
> RCS file: /cvs/src/sys/dev/pci/azalia.c,v
> diff -u -p -u -r1.287 azalia.c
> --- sys/dev/pci/azalia.c 17 May 2024 19:43:45 - 1.287
> +++ sys/dev/pci/azalia
Now that my BIOS update took away S3 I started playing with zzz'ing to
S0. The first time it seems to be working: the display turns off and the
usb device are powered off. The power button brings everything back up
and seemingly functional. The second zzz turns off the display and
nothing else seem
20 matches
Mail list logo
