- 13 Jan, 2022 1 commit
-
-
Austin Zhang authored
The ACPI spec describes the FADT->Century field as: The RTC CMOS RAM index to the century of data value (hundred and thousand year decimals). If this field contains a zero, then the RTC centenary feature is not supported. If this field has a non-zero value, then this field contains an index into RTC RAM space that OSPM can use to program the centenary field. Use this field to decide whether to program the CENTURY register of the CMOS RTC device. Reviewed by: akumar3@isilon.com, dab, vangyzen MFC after: 1 week Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D33667 MFC after: 1 week Sponsored by: Dell EMC Isilon
-
- 01 Sep, 2020 2 commits
-
-
mjg authored
-
Mateusz Guzik authored
-
- 11 Mar, 2019 2 commits
-
-
wulf authored
Submitted by: jkim Reported by: rpokala MFC with: r344982
-
Vladimir Kondratyev authored
Submitted by: jkim Reported by: rpokala MFC with: r344982
-
- 10 Mar, 2019 2 commits
-
-
wulf authored
FreeBSD base system does not provide an ACPI handler for the PC/AT RTC/CMOS device with PnP ID PNP0B00; on some HP laptops, the absence of this handler causes suspend/resume and poweroff(8) to hang or fail [1], [2]. On these laptops EC _REG method queries the RTC date/time registers via ACPI before suspending/powering off. The handler should be registered before acpi_ec driver is loaded. This change adds handler to access CMOS RTC operation region described in section 9.15 of ACPI-6.2 specification [3]. It is installed only for ACPI version of atrtc(4) so it should not affect old ACPI-less i386 systems. It is possible to disable the handler with loader tunable: debug.acpi.disabled=atrtc Informational debugging printf can be enabled by setting hw.acpi.verbose=1 in loader.conf [1] https://wiki.freebsd.org/Laptops/HP_Envy_6Z-1100 [2] https://wiki.freebsd.org/Laptops/HP_Notebook_15-af104ur [3] https://uefi.org/sites/default/files/resources/ACPI_6_2.pdf PR: 207419, 213039 Submitted by: Anthony Jenkins <Scoobi_doo@yahoo.com> Reviewed by: ian Discussed on: acpi@, 2013-2015, several threads MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D19314
-
Vladimir Kondratyev authored
FreeBSD base system does not provide an ACPI handler for the PC/AT RTC/CMOS device with PnP ID PNP0B00; on some HP laptops, the absence of this handler causes suspend/resume and poweroff(8) to hang or fail [1], [2]. On these laptops EC _REG method queries the RTC date/time registers via ACPI before suspending/powering off. The handler should be registered before acpi_ec driver is loaded. This change adds handler to access CMOS RTC operation region described in section 9.15 of ACPI-6.2 specification [3]. It is installed only for ACPI version of atrtc(4) so it should not affect old ACPI-less i386 systems. It is possible to disable the handler with loader tunable: debug.acpi.disabled=atrtc Informational debugging printf can be enabled by setting hw.acpi.verbose=1 in loader.conf [1] https://wiki.freebsd.org/Laptops/HP_Envy_6Z-1100 [2] https://wiki.freebsd.org/Laptops/HP_Notebook_15-af104ur [3] https://uefi.org/sites/default/files/resources/ACPI_6_2.pdf PR: 207419, 213039 Submitted by: Anthony Jenkins <Scoobi_doo@yahoo.com> Reviewed by: ian Discussed on: acpi@, 2013-2015, several threads MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D19314
-
- 25 Jun, 2018 2 commits
-
-
kib authored
x86 boot flags. Reviewed by: royger Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D16004 MFC after: 1 week
-
Konstantin Belousov authored
x86 boot flags. Reviewed by: royger Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D16004 MFC after: 1 week
-
- 13 Mar, 2018 2 commits
-
-
royger authored
Or else disable the device. Note that the detection can be bypassed by setting the hw.atrtc.enable option in the loader configuration file. More information can be found on atrtc(4). Sponsored by: Citrix Systems R&D Reviewed by: ian Differential revision: https://reviews.freebsd.org/D14399
-
Roger Pau Monné authored
Or else disable the device. Note that the detection can be bypassed by setting the hw.atrtc.enable option in the loader configuration file. More information can be found on atrtc(4). Sponsored by: Citrix Systems R&D Reviewed by: ian Differential revision: https://reviews.freebsd.org/D14399
-
- 12 Mar, 2018 2 commits
-
-
ian authored
Reported by: hps@
-
Ian Lepore authored
Reported by: hps@
-
- 11 Mar, 2018 12 commits
-
-
ian authored
mutex before acquiring sleep mutexes. Reported by: kib@
-
Ian Lepore authored
mutex before acquiring sleep mutexes. Reported by: kib@
-
ian authored
from the i8254 driver when I created separate mutexes for each. The i8254 driver could be the active timecounter, leading to recursion during mutex profiling, but the atrtc driver cannot be a timecounter, so it isn't needed.
-
Ian Lepore authored
from the i8254 driver when I created separate mutexes for each. The i8254 driver could be the active timecounter, leading to recursion during mutex profiling, but the atrtc driver cannot be a timecounter, so it isn't needed.
-
ian authored
-
Ian Lepore authored
-
ian authored
just once around the whole group of accesses.
-
Ian Lepore authored
just once around the whole group of accesses.
-
ian authored
un-function-like RTC_LOCK/UNLOCK macro usage into normal function calls. Since there is no longer any need to handle register access from a debugger context, those function calls can just be regular mutex lock/unlock calls. Requested by: bde
-
Ian Lepore authored
un-function-like RTC_LOCK/UNLOCK macro usage into normal function calls. Since there is no longer any need to handle register access from a debugger context, those function calls can just be regular mutex lock/unlock calls. Requested by: bde
-
ian authored
command handler which provided much the same information. Removing the possibility of accessing the hardware regs from the debugger context paves the way for simplifying the locking code in the driver.
-
Ian Lepore authored
command handler which provided much the same information. Removing the possibility of accessing the hardware regs from the debugger context paves the way for simplifying the locking code in the driver.
-
- 29 Jan, 2018 2 commits
-
-
imp authored
ACPI ISA PBP tables not tagged, there's bigger issues with them.
-
Warner Losh authored
ACPI ISA PBP tables not tagged, there's bigger issues with them.
-
- 16 Jan, 2018 6 commits
-
-
ian authored
by these calls is now protected by a spin mutex (obscured within the RTC_LOCK/RTC_UNLOCK macros). Reported by: bde@
-
Ian Lepore authored
by these calls is now protected by a spin mutex (obscured within the RTC_LOCK/RTC_UNLOCK macros). Reported by: bde@
-
ian authored
The static atrtc_set() function was called only from clock_settime(), so just move its contents entirely into clock_settime() and delete atrtc_set(). Rename the struct bcd_clocktime variables from 'ct' to 'bct'. I had originally wanted to emphasize how identical the clocktime and bcd_clocktime structs were, but things evolved to the point where the structs are not at all identical anymore, so now emphasizing the difference seems better.
-
Ian Lepore authored
The static atrtc_set() function was called only from clock_settime(), so just move its contents entirely into clock_settime() and delete atrtc_set(). Rename the struct bcd_clocktime variables from 'ct' to 'bct'. I had originally wanted to emphasize how identical the clocktime and bcd_clocktime structs were, but things evolved to the point where the structs are not at all identical anymore, so now emphasizing the difference seems better.
-
ian authored
related series of operations without doing a lock/unlock for each byte. Use them when reading and writing the entire set of time registers. The original rtcin() and writertc() functions which do lock/unlock on each byte still exist, because they are public and called by outside code.
-
Ian Lepore authored
related series of operations without doing a lock/unlock for each byte. Use them when reading and writing the entire set of time registers. The original rtcin() and writertc() functions which do lock/unlock on each byte still exist, because they are public and called by outside code.
-
- 15 Jan, 2018 2 commits
-
-
ian authored
New common routines were added to kern/subr_clock.c for converting between calendrical time expressed in BCD and struct timespec. The new functions return EINVAL on error, as expected when the clock hardware does not provide valid time. PR: 224813 Differential Revision: https://reviews.freebsd.org/D13731 (no reviewers)
-
Ian Lepore authored
New common routines were added to kern/subr_clock.c for converting between calendrical time expressed in BCD and struct timespec. The new functions return EINVAL on error, as expected when the clock hardware does not provide valid time. PR: 224813 Differential Revision: https://reviews.freebsd.org/D13731 (no reviewers)
-
- 27 Nov, 2017 2 commits
-
-
pfg authored
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
-
Pedro F. Giffuni authored
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
-
- 11 Aug, 2017 2 commits
-
-
ian authored
removes the only reference to atrtc_set() from outside of atrtc.c, so make it static. The xen timer driver registers as a realtime clock with 1us resolution. In the past that resulted in only the xen timer's clock_settime() getting called, so it would call atrtc_set() to set the hardware clock as well. As of r32090, the clock_settime() method of all registered realtime clocks gets called, so the xen driver no longer needs to chain-call the lower-resolution driver. Thanks to royger@ for talking me through the xen stuff, and for testing.
-
Ian Lepore authored
removes the only reference to atrtc_set() from outside of atrtc.c, so make it static. The xen timer driver registers as a realtime clock with 1us resolution. In the past that resulted in only the xen timer's clock_settime() getting called, so it would call atrtc_set() to set the hardware clock as well. As of r32090, the clock_settime() method of all registered realtime clocks gets called, so the xen driver no longer needs to chain-call the lower-resolution driver. Thanks to royger@ for talking me through the xen stuff, and for testing.
-
- 12 Jul, 2017 1 commit
-
-
ian authored
The mutex protecting access to the registered realtime clock should not be overloaded to protect access to the atrtc hardware, which might not even be the registered rtc. More importantly, the resettodr mutex needs to be eliminated to remove locking/sleeping restrictions on clock drivers, and that can't happen if MD code for amd64 depends on it. This change moves the protection into what's really being protected: access to the atrtc date and time registers. This change also adds protection when the clock is accessed from xentimer_settime(), which bypasses the resettodr locking. Differential Revision: https://reviews.freebsd.org/D11483
-