Bug 207419 - Add ACPI support for RTC/CMOS device
Summary: Add ACPI support for RTC/CMOS device
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-acpi mailing list
URL:
Keywords: feature, needs-qa
Depends on:
Blocks:
 
Reported: 2016-02-22 16:16 UTC by Anthony Jenkins
Modified: 2018-07-31 01:47 UTC (History)
2 users (show)

See Also:
koobs: mfc-stable10?
koobs: mfc-stable11?


Attachments
Impl. of ACPI RTC/CMOS interface. (5.68 KB, patch)
2016-02-22 16:16 UTC, Anthony Jenkins
no flags Details | Diff
Impl. of ACPI RTC/CMOS interface with bus/core separation. (19.44 KB, patch)
2016-02-22 16:19 UTC, Anthony Jenkins
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Anthony Jenkins 2016-02-22 16:16:32 UTC
Created attachment 167301 [details]
Impl. of ACPI RTC/CMOS interface.

FreeBSD base system does not provide an ACPI handler for the PC/AT RTC/CMOS device with PnP ID PNP0B00; on recent HP Envy laptops, the absence of this handler causes suspend/resume and poweroff(8) to hang/fail, emitting e.g.

ACPI Error: No handler for Region [RCM0] (0xfffff80005796480) [SystemCMOS] (20150818/evregion-176)
ACPI Error: Region SystemCMOS (ID=5) has no handler (20150818/exfldio-317)

These HP laptops have BIOSes which attempt to query the RTC date/time registers via ACPI before suspending/powering off.

ACPI-5.0 specification section 9.15 describes the ACPI interface to the RTC/CMOS device (atrtc(4) in FreeBSD).

I have implemented this ACPI handler; adding this allows poweroff and suspend/resume to occur.  At a FreeBSD committer's request, I've also implemented the same patch with additional changes to atrtc(4) to separate the bus functionality from the core functionality.
Comment 1 Anthony Jenkins 2016-02-22 16:19:29 UTC
Created attachment 167302 [details]
Impl. of ACPI RTC/CMOS interface with bus/core separation.

This version of the patch was requested by a FreeBSD committer.  I personally prefer the previous patch to this one; instead the separation should be performed as a new bug.
Comment 2 Jung-uk Kim freebsd_committer 2016-02-22 18:04:08 UTC
Please note the upstream received a CMOS handler implementation and the patch was posted here:

https://lists.acpica.org/pipermail/devel/2015-May/000698.html

Unfortunately, it is still not resolved.

https://lists.acpica.org/pipermail/devel/2016-February/000872.html
https://lists.acpica.org/pipermail/devel/2016-February/000873.html
https://lists.acpica.org/pipermail/devel/2016-February/000874.html

If possible, please participate in the discussion.
Comment 3 Anthony Jenkins 2016-02-22 19:32:47 UTC
The upstream thread actually mirrors the evolution of my OSPM patch.  I first tried adding code to the ACPICA code, then, based on some helpful suggestions from acpi@, moved it to the atrtc(4) driver.  I agree with the last thread post (https://lists.acpica.org/pipermail/devel/2016-February/000874.html) - that support for RTC/CMOS devices belongs in the OSPM, not in the ACPICA.  If you look closely at the OP's proposed ACPICA patch, the AcpiOs(Read|Write)Cmos() handlers are no-ops (Read returns 0, Write does nothing).

I mean I can toss my $0.02 into the thread, but it'll be little more than "I agree this shouldn't be added to ACPICA"...
Comment 4 Jung-uk Kim freebsd_committer 2016-02-22 19:48:24 UTC
(In reply to Anthony Jenkins from comment #3)
> If you look closely at the OP's proposed ACPICA patch, the
> AcpiOs(Read|Write)Cmos() handlers are no-ops (Read returns 0, Write does
> nothing).

Actually, those are stubs for userland tools, i.e., acpiexec.  FYI, OSPM must provide AcpiOsReadCmos() and AcpiOsWriteCmos().  See sys/dev/acpica/Osd/OsdMemory.c, for example.
Comment 5 Jung-uk Kim freebsd_committer 2016-02-22 20:03:58 UTC
BTW, these functions must be MD.  So, it should be placed in sys/x86/acpica (please see OsdEnvironment.c) and/or sys/x86/isa/atrtc.c.  If the upstream does not want them as official API, then your patch is good.

FYI, the official ACPICA API is documented here:

https://acpica.org/sites/acpica/files/acpica-reference_17.pdf
Comment 6 Jung-uk Kim freebsd_committer 2016-02-22 20:33:22 UTC
(In reply to Anthony Jenkins from comment #1)
FYI, the separation is important because ACPI is not mandatory for i386.
Comment 7 Anthony Jenkins 2016-02-25 05:06:23 UTC
(In reply to Jung-uk Kim from comment #6)

Ahh, okay I think that makes sense; seemed an arbitrary request before.

My bus-separation patch could probably use some work, but it builds and works on my amd64.
Comment 8 Anthony Jenkins 2018-07-31 01:47:34 UTC
I just assumed this was dropped for lack of interest.  What are my next steps?