summaryrefslogtreecommitdiff
path: root/drivers/thermal/intel_soc_dts_thermal.c
AgeCommit message (Collapse)AuthorFilesLines
2018-12-07drivers: thermal: Move various drivers for intel platforms into a subdirAmit Kucheria1-132/+0
This cleans up the directory a bit, now that we have several other platforms using platform-specific sub-directories. Compile-tested with ARCH=x86 defconfig and the drivers explicitly enabled with menuconfig. Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2018-10-02x86/cpu: Sanitize FAM6_ATOM namingPeter Zijlstra1-1/+1
Going primarily by: https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors with additional information gleaned from other related pages; notably: - Bonnell shrink was called Saltwell - Moorefield is the Merriefield refresh which makes it Airmont The general naming scheme is: FAM6_ATOM_UARCH_SOCTYPE for i in `git grep -l FAM6_ATOM` ; do sed -i -e 's/ATOM_PINEVIEW/ATOM_BONNELL/g' \ -e 's/ATOM_LINCROFT/ATOM_BONNELL_MID/' \ -e 's/ATOM_PENWELL/ATOM_SALTWELL_MID/g' \ -e 's/ATOM_CLOVERVIEW/ATOM_SALTWELL_TABLET/g' \ -e 's/ATOM_CEDARVIEW/ATOM_SALTWELL/g' \ -e 's/ATOM_SILVERMONT1/ATOM_SILVERMONT/g' \ -e 's/ATOM_SILVERMONT2/ATOM_SILVERMONT_X/g' \ -e 's/ATOM_MERRIFIELD/ATOM_SILVERMONT_MID/g' \ -e 's/ATOM_MOOREFIELD/ATOM_AIRMONT_MID/g' \ -e 's/ATOM_DENVERTON/ATOM_GOLDMONT_X/g' \ -e 's/ATOM_GEMINI_LAKE/ATOM_GOLDMONT_PLUS/g' ${i} done Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: dave.hansen@linux.intel.com Cc: len.brown@intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-26Thermal: Intel SoC DTS: Translate IO-APIC GSI number to linux irq numberHans de Goede1-3/+23
The Intel SoC DTS uses a hardcoded GSI number, before this commit it was passing it to request_irq as if it were a linux irq number, but there is no 1:1 mapping so in essence it was requesting a random interrupt. Besides this causing the DTS driver to not actually get an interrupt if the thermal thresholds are exceeded this also is causing an interrupt conflict on some devices since the linux irq 86 which is being requested is already in use, leading to oopses like this: genirq: Flags mismatch irq 86. 00002001 (soc_dts) vs. 00000083 (volume_down) CPU: 0 PID: 601 Comm: systemd-udevd Tainted: G C OE 4.17.0-rc6+ #45 Hardware name: Insyde i86/Type2 - Board Product Name, BIOS CHUWI.D86JLBNR03 01/14/2015 Call Trace: dump_stack+0x5c/0x80 __setup_irq.cold.50+0x4e/0xac ? request_threaded_irq+0xad/0x160 request_threaded_irq+0xf5/0x160 ? 0xffffffffc0a93000 intel_soc_thermal_init+0x74/0x1000 [intel_soc_dts_thermal] This commit makes the intel_soc_dts_thermal.c code call acpi_register_gsi() to translate the hardcoded IO-APIC GSI number (86) to a linux irq, so that the dts code uses the right interrupt and we no longer get an oops about an irq conflict. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2017-05-05Thermal: Intel SoC DTS: Change interrupt request behaviorBrian Bian1-3/+6
The interrupt request call in Intel SoC DTS driver may fail if there is no underlying BIOS support. However, the user space thermal daemon can still use the thermal zones created by the SoC DTS driver in polling mode, therefore, instead of bailing out on interrupt request failures, it is better just to log a warning message and continue the init process. Signed-off-by: Brian Bian <brian.bian@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2016-06-08x86, thermal: Clean up and fix CPU model detection for intel_soc_dts_thermalDave Hansen1-1/+3
The X86_FAMILY_ANY in here is bogus. "BYT" and model 0x37 are family-6 only. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dave Hansen <dave@sr71.net> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Zhang Rui <rui.zhang@intel.com> Cc: jacob.jun.pan@intel.com Cc: linux-pm@vger.kernel.org Link: http://lkml.kernel.org/r/20160603001952.9B6E114D@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-05-01Thermal: Intel SoC: DTS thermal use common APIsSrinivas Pandruvada1-409/+21
There is no change in functionality but using the common IOSF core APIs. This driver is now just responsible for enumeration and call relevant API to create thermal zone and register critical trip. Also cpuid 0x4c is now handled in the int340x processor thermal driver with the same functionality. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
2015-01-29thermal: Intel SoC DTS: Add Braswell supportSrinivas Pandruvada1-16/+30
Added Intel Braswell CPU id for SOC DTS. Since this doesn't support APIC IRQ, the driver is modified to have capability to not register any modifiable trips. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2014-12-09thermal: Intel SoC DTS: Don't do thermal zone update inside spin_lockMaurice Petallo1-5/+7
The driver calls spin_lock_irqsave during DTS interrupt. The interrupt handle then calls thermal_zone_device_update which implicitly calls a sleep function and produce the following bug: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97 in_atomic(): 1, irqs_disabled(): 1, pid: 920, name: irq/86-soc_dts CPU: 0 PID: 920 Comm: irq/86-soc_dts Tainted: G E 3.17.0-rc2+ #1 Hardware name: Intel Corp. VALLEYVIEW B3 PLATFORM/NOTEBOOK, BIOS BYTICRB1.86C.0092.R31.1408290850 08/29/2014 00000000 00000000 c25dbe74 c1818cfd f3cc488c c25dbe9c c1059305 c1b4063b 00000001 00000001 00000398 f3cc488c f6817644 f6817644 f3ecc6c0 c25dbea8 c18208f2 f6817400 c25dbebc c159b0bb c25dbedc f6817400 f32a2300 c25dbee8 Call Trace: [<c1818cfd>] dump_stack+0x48/0x60 [<c1059305>] __might_sleep+0xec/0xf4 [<c18208f2>] mutex_lock+0x1c/0x34 [<c159b0bb>] thermal_zone_get_temp+0x34/0x59 [<c159bde5>] thermal_zone_device_update+0x2d/0xcb [<f85da16a>] ? iosf_mbi_write+0x6c/0x74 [iosf_mbi] [<f7c7445d>] soc_irq_thread_fn+0x10c/0x163 [intel_soc_dts_thermal] [<c107b72b>] irq_thread_fn+0x18/0x2a [<c107bedb>] irq_thread+0x81/0x11f [<c107b713>] ? irq_finalize_oneshot+0x7c/0x7c [<c107bf79>] ? irq_thread+0x11f/0x11f [<c107be5a>] ? wake_threads_waitq+0x31/0x31 [<c1054217>] kthread+0x87/0x8c [<c1821e41>] ret_from_kernel_thread+0x21/0x30 [<c1054190>] ? __kthread_parkme+0x55/0x55 Signed-off-by: Maurice Petallo <mauricex.r.petallo@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Eduardo Valentin <edubezval@gmail.com> CC: Kweh, Hock Leong <hock.leong.kweh@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2014-05-15thermal: Intel SoC DTS thermalSrinivas Pandruvada1-0/+479
In the Intel SoCs like Bay Trail, there are 2 additional digital temperature sensors(DTS), in addition to the standard DTSs in the core. Also they support 4 programmable thresholds, out of which two can be used by OSPM. These thresholds can be used by OSPM thermal control. Out of these two thresholds, one is used by driver and one user mode can change via thermal sysfs to get notifications on threshold violations. The driver defines one critical trip points, which is set to TJ MAX - offset. The offset can be changed via module parameter (default 5C). Also it uses one of the thresholds to get notification for this temperature violation. This is very important for orderly shutdown as the many of these devices don't have ACPI thermal zone, and expects that there is some other thermal control mechanism present in OSPM. When a Linux distro is used without additional specialized thermal control program, BIOS can do force shutdown when thermals are not under control. When temperature reaches critical, the Linux thermal core will initiate an orderly shutdown. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>