kernel.git/arch/x86/kernel/hpet.c, branch linux-5.12.y

x86/hpet: Use irq_find_matching_fwspec() to find remapping irqdomain

2020-10-28T19:26:28Z

All possible parent domains have a select method now. Make use of it. Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20201024213535.443185-28-dwmw2@infradead.org

x86/hpet: Move MSI support into hpet.c

2020-10-28T19:26:25Z

This isn't really dependent on PCI MSI; it's just generic MSI which is now supported by the generic x86_vector_domain. Move the HPET MSI support back into hpet.c with the rest of the HPET support. Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20201024213535.443185-11-dwmw2@infradead.org

remove ioremap_nocache and devm_ioremap_nocache

2020-01-06T08:45:59Z

ioremap has provided non-cached semantics by default since the Linux 2.6 days, so remove the additional ioremap_nocache interface. Signed-off-by: Christoph Hellwig Acked-by: Arnd Bergmann

x86/hpet: Undo the early counter is counting check

2019-07-25T10:21:32Z

Rui reported that on a Pentium D machine which has HPET forced enabled because it is not advertised by ACPI, the early counter is counting check leads to a silent boot hang. The reason is that the ordering of checking the counter first and then reconfiguring the HPET fails to work on that machine. As the HPET is not advertised and presumably not initialized by the BIOS the early enable and the following reconfiguration seems to bring it into a broken state. Adding clocksource=jiffies to the command line results in the following clocksource watchdog warning: clocksource: timekeeping watchdog on CPU1: Marking clocksource 'tsc-early' as unstable because the skew is too large: clocksource: 'hpet' wd_now: 33 wd_last: 33 mask: ffffffff That clearly shows that the HPET is not counting after it got reconfigured and reenabled. If the counter is not working then the HPET timer is not expiring either, which explains the boot hang. Move the counter is counting check after the full configuration again to unbreak these systems. Reported-by: Rui Salvaterra Fixes: 3222daf970f3 ("x86/hpet: Separate counter check out of clocksource register code") Signed-off-by: Thomas Gleixner Tested-by: Rui Salvaterra Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1907250810530.1791@nanos.tec.linutronix.de

x86/hpet: Use channel for legacy clockevent storage

2019-06-27T22:57:27Z

All preparations are done. Use the channel storage for the legacy clockevent and remove the static variable. Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Cc: Peter Zijlstra Cc: Ricardo Neri Cc: Ashok Raj Cc: Andi Kleen Cc: Suravee Suthikulpanit Cc: Stephane Eranian Cc: Ravi Shankar Link: https://lkml.kernel.org/r/20190623132436.737689919@linutronix.de

x86/hpet: Use common init for legacy clockevent

2019-06-27T22:57:27Z

Replace the static initialization of the legacy clockevent with runtime initialization utilizing the common init function as the last preparatory step to switch the legacy clockevent over to the channel 0 storage in hpet_base. This comes with a twist. The static clockevent initializer has selected support for periodic and oneshot mode unconditionally whether the HPET config advertised periodic mode or not. Even the pre clockevents code did this. But.... Using the conditional in hpet_init_clockevent() makes at least Qemu and one hardware machine fail to boot. There are two issues which cause the boot failure: #1 After the timer delivery test in IOAPIC and the IOAPIC setup the next interrupt is not delivered despite the HPET channel being programmed correctly. Reprogramming the HPET after switching to IOAPIC makes it work again. After fixing this, the next issue surfaces: #2 Due to the unconditional periodic mode 'availability' the Local APIC timer calibration can hijack the global clockevents event handler without causing damage. Using oneshot at this stage makes if hang because the HPET does not get reprogrammed due to the handler hijacking. Duh, stupid me! Both issues require major surgery and especially the kick HPET again after enabling IOAPIC results in really nasty hackery. This 'assume periodic works' magic has survived since HPET support got added, so it's questionable whether this should be fixed. Both Qemu and the failing hardware machine support periodic mode despite the fact that both don't advertise it in the configuration register and both need that extra kick after switching to IOAPIC. Seems to be a feature... Keep the 'assume periodic works' magic around and add a big fat comment. Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Cc: Peter Zijlstra Cc: Ricardo Neri Cc: Ashok Raj Cc: Andi Kleen Cc: Suravee Suthikulpanit Cc: Stephane Eranian Cc: Ravi Shankar Link: https://lkml.kernel.org/r/20190623132436.646565913@linutronix.de

x86/hpet: Carve out shareable parts of init_one_hpet_msi_clockevent()

2019-06-27T22:57:26Z

To finally remove the static channel0/clockevent storage and to utilize the channel 0 storage in hpet_base, it's required to run time initialize the clockevent. The MSI clockevents already have a run time init function. Carve out the parts which can be shared between the legacy and the MSI implementation. Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Cc: Peter Zijlstra Cc: Ricardo Neri Cc: Ashok Raj Cc: Andi Kleen Cc: Suravee Suthikulpanit Cc: Stephane Eranian Cc: Ravi Shankar Link: https://lkml.kernel.org/r/20190623132436.552451082@linutronix.de

x86/hpet: Consolidate clockevent functions

2019-06-27T22:57:26Z

Now that the legacy clockevent is wrapped in a hpet_channel struct most clockevent functions can be shared between the legacy and the MSI based clockevents. Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Cc: Peter Zijlstra Cc: Ricardo Neri Cc: Ashok Raj Cc: Andi Kleen Cc: Suravee Suthikulpanit Cc: Stephane Eranian Cc: Ravi Shankar Link: https://lkml.kernel.org/r/20190623132436.461437795@linutronix.de

x86/hpet: Wrap legacy clockevent in hpet_channel

2019-06-27T22:57:25Z

For HPET channel 0 there exist two clockevent structures right now: - the static hpet_clockevent - the clockevent in channel 0 storage The goal is to use the clockevent in the channel storage, remove the static variable and share code with the MSI implementation. As a first step wrap the legacy clockevent into a hpet_channel struct and convert the users. Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Cc: Peter Zijlstra Cc: Ricardo Neri Cc: Ashok Raj Cc: Andi Kleen Cc: Suravee Suthikulpanit Cc: Stephane Eranian Cc: Ravi Shankar Link: https://lkml.kernel.org/r/20190623132436.368141247@linutronix.de

x86/hpet: Use cached info instead of extra flags

2019-06-27T22:57:25Z

Now that HPET clockevent support is integrated into the channel data, reuse the cached boot configuration instead of copying the same information into a flags field. This also allows to consolidate the reservation code into one place, which can now solely depend on the mode information. Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Cc: Peter Zijlstra Cc: Ricardo Neri Cc: Ashok Raj Cc: Andi Kleen Cc: Suravee Suthikulpanit Cc: Stephane Eranian Cc: Ravi Shankar Link: https://lkml.kernel.org/r/20190623132436.277510163@linutronix.de