Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 2月, 2021 8 次提交
  3. 15 2月, 2021 1 次提交
    • A
      leds: rt8515: add V4L2_FLASH_LED_CLASS dependency · dbeb02a0
      由 Arnd Bergmann 提交于 
      The leds-rt8515 driver can optionall use the v4l2 flash led class,
but it causes a link error when that class is in a loadable module
and the rt8515 driver itself is built-in:

ld.lld: error: undefined symbol: v4l2_flash_init
>>> referenced by leds-rt8515.c
>>>               leds/flash/leds-rt8515.o:(rt8515_probe) in archive
drivers/built-in.a

Adding 'depends on V4L2_FLASH_LED_CLASS' in Kconfig would avoid that,
but it would make it impossible to use the driver without the
v4l2 support.

Add the same dependency that the other users of this class have
instead, which just prevents the broken configuration.

Fixes: e1c6edcb ("leds: rt8515: Add Richtek RT8515 LED driver")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NPavel Machek <pavel@ucw.cz>
      dbeb02a0
  5. 12 2月, 2021 2 次提交
  7. 11 2月, 2021 2 次提交
  9. 10 2月, 2021 14 次提交
  11. 09 2月, 2021 1 次提交
  13. 08 2月, 2021 4 次提交
    • A
      Revert "ACPICA: Interpreter: fix memory leak by using existing buffer" · fe0af090
      由 Ard Biesheuvel 提交于 
      This reverts commit 32cf1a12.

The 'exisitng buffer' in this case is the firmware provided table, and
we should not modify that in place. This fixes a crash on arm64 with
initrd table overrides, in which case the DSDT is not mapped with
read/write permissions.
Reported-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fe0af090
    • R
      cpufreq: ACPI: Update arch scale-invariance max perf ratio if CPPC is not there · d11a1d08
      由 Rafael J. Wysocki 提交于 
      If the maximum performance level taken for computing the
arch_max_freq_ratio value used in the x86 scale-invariance code is
higher than the one corresponding to the cpuinfo.max_freq value
coming from the acpi_cpufreq driver, the scale-invariant utilization
falls below 100% even if the CPU runs at cpuinfo.max_freq or slightly
faster, which causes the schedutil governor to select a frequency
below cpuinfo.max_freq.  That frequency corresponds to a frequency
table entry below the maximum performance level necessary to get to
the "boost" range of CPU frequencies which prevents "boost"
frequencies from being used in some workloads.

While this issue is related to scale-invariance, it may be amplified
by commit db865272 ("cpufreq: Avoid configuring old governors as
default with intel_pstate") from the 5.10 development cycle which
made it extremely easy to default to schedutil even if the preferred
driver is acpi_cpufreq as long as intel_pstate is built too, because
the mere presence of the latter effectively removes the ondemand
governor from the defaults.  Distro kernels are likely to include
both intel_pstate and acpi_cpufreq on x86, so their users who cannot
use intel_pstate or choose to use acpi_cpufreq may easily be
affectecd by this issue.

If CPPC is available, it can be used to address this issue by
extending the frequency tables created by acpi_cpufreq to cover the
entire available frequency range (including "boost" frequencies) for
each CPU, but if CPPC is not there, acpi_cpufreq has no idea what
the maximum "boost" frequency is and the frequency tables created by
it cannot be extended in a meaningful way, so in that case make it
ask the arch scale-invariance code to to use the "nominal" performance
level for CPU utilization scaling in order to avoid the issue at hand.

Fixes: db865272 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NGiovanni Gherdovich <ggherdovich@suse.cz>
Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      d11a1d08
    • R
      cpufreq: ACPI: Extend frequency tables to cover boost frequencies · 3c55e94c
      由 Rafael J. Wysocki 提交于 
      A severe performance regression on AMD EPYC processors when using
the schedutil scaling governor was discovered by Phoronix.com and
attributed to the following commits:

  41ea6672 ("x86, sched: Calculate frequency invariance for AMD
  systems")

  976df7e5 ("x86, sched: Use midpoint of max_boost and max_P for
  frequency invariance on AMD EPYC")

The source of the problem is that the maximum performance level taken
for computing the arch_max_freq_ratio value used in the x86 scale-
invariance code is higher than the one corresponding to the
cpuinfo.max_freq value coming from the acpi_cpufreq driver.

This effectively causes the scale-invariant utilization to fall below
100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so
the schedutil governor selects a frequency below cpuinfo.max_freq
then.  That frequency corresponds to a frequency table entry below
the maximum performance level necessary to get to the "boost" range
of CPU frequencies.

However, if the cpuinfo.max_freq value coming from acpi_cpufreq was
higher, the schedutil governor would select higher frequencies which
in turn would allow acpi_cpufreq to set more adequate performance
levels and to get to the "boost" range of CPU frequencies more often.

This issue affects any systems where acpi_cpufreq is used and the
"boost" (or "turbo") frequencies are enabled, not just AMD EPYC.
Moreover, commit db865272 ("cpufreq: Avoid configuring old
governors as default with intel_pstate") from the 5.10 development
cycle made it extremely easy to default to schedutil even if the
preferred driver is acpi_cpufreq as long as intel_pstate is built
too, because the mere presence of the latter effectively removes the
ondemand governor from the defaults.  Distro kernels are likely to
include both intel_pstate and acpi_cpufreq on x86, so their users
who cannot use intel_pstate or choose to use acpi_cpufreq may
easily be affectecd by this issue.

To address this issue, extend the frequency table constructed by
acpi_cpufreq for each CPU to cover the entire range of available
frequencies (including the "boost" ones) if CPPC is available and
indicates that "boost" (or "turbo") frequencies are enabled.  That
causes cpuinfo.max_freq to become the maximum "boost" frequency of
the given CPU (instead of the maximum frequency returned by the ACPI
_PSS object that corresponds to the "nominal" performance level).

Fixes: 41ea6672 ("x86, sched: Calculate frequency invariance for AMD systems")
Fixes: 976df7e5 ("x86, sched: Use midpoint of max_boost and max_P for frequency invariance on AMD EPYC")
Fixes: db865272 ("cpufreq: Avoid configuring old governors as default with intel_pstate")
Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/Reported-by: NMichael Larabel <Michael@phoronix.com>
Diagnosed-by: NGiovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: NGiovanni Gherdovich <ggherdovich@suse.cz>
Reviewed-by: NGiovanni Gherdovich <ggherdovich@suse.cz>
Tested-by: NMichael Larabel <Michael@phoronix.com>
      3c55e94c
    • C
      dmaengine dw: Revert "dmaengine: dw: Enable runtime PM" · b6c14d7a
      由 Cezary Rojewski 提交于 
      This reverts commit 84206794.
For some solutions e.g. sound/soc/intel/catpt, DW DMA is part of a
compound device (in that very example, domains: ADSP, SSP0, SSP1, DMA0
and DMA1 are part of a single entity) rather than being a standalone
one. Driver for said device may enlist DMA to transfer data during
suspend or resume sequences.

Manipulating RPM explicitly in dw's DMA request and release channel
functions causes suspend() to also invoke resume() for the exact same
device. Similar situation occurs for resume() sequence. Effectively
renders device dysfunctional after first suspend() attempt. Revert the
change to address the problem.

Fixes: 84206794 ("dmaengine: dw: Enable runtime PM")
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NCezary Rojewski <cezary.rojewski@intel.com>
Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210203191924.15706-1-cezary.rojewski@intel.comSigned-off-by: NVinod Koul <vkoul@kernel.org>
      b6c14d7a
  15. 07 2月, 2021 2 次提交
  17. 06 2月, 2021 4 次提交
  19. 05 2月, 2021 2 次提交