| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When we decode the latency and the max_latency, u16 value may not fit
the required size and could lead to the wrong LTR representation.
Scaling is represented as:
scale 0 - 1 (2^(5*0)) = 2^0
scale 1 - 32 (2^(5 *1))= 2^5
scale 2 - 1024 (2^(5 *2)) =2^10
scale 3 - 32768 (2^(5 *3)) =2^15
scale 4 - 1048576 (2^(5 *4)) = 2^20
scale 5 - 33554432 (2^(5 *4)) = 2^25
scale 4 and scale 5 required 20 and 25 bits respectively.
scale 6 reserved.
Replace the u16 type with the u32 type and allow corrected LTR
representation.
Cc: stable@vger.kernel.org
Fixes: 44a13a5d99c7 ("e1000e: Fix the max snoop/no-snoop latency for 10M")
Reported-by: James Hutchinson <jahutchinson99@googlemail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215689
Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Tested-by: James Hutchinson <jahutchinson99@googlemail.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
Some mainboard/CPU combinations, in particular, Alder Lake-S with a
W680 mainboard, have shown problems (system hangs usually, no kernel
logs) with suspend/resume when PCIe PTM is enabled and active. In some
cases, it could be reproduced when removing the igc module.
The best we can do is to stop PTM dialogs from the downstream/device
side before the interface is brought down. PCIe PTM will be re-enabled
when the interface is being brought up.
Fixes: a90ec8483732 ("igc: Add support for PTP getcrosststamp()")
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Acked-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
Remove the DTR checks as they are already handled in
spi_mem_default_supports_op(). This code removal was intentionally not done
in the previous patch that introduced the use of the
spi_mem_default_supports_op() core helper and fixed the buswidth adjustment
between SPIMEM and the SPI controller, so that the fix can be easily
backported to stable kernels.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20220406133604.455356-2-tudor.ambarus@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Use the spi_mem_default_supports_op() core helper in order to take into
account the buswidth specified by the user in device tree.
Cc: <stable@vger.kernel.org>
Fixes: 0e6aae08e9ae ("spi: Add QuadSPI driver for Atmel SAMA5D2")
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20220406133604.455356-1-tudor.ambarus@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Problem statement:
Once the user has disabled turbo frequency by
# echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
the cfs_rq's util_avg becomes quite small when compared with
CPU capacity.
Step to reproduce:
# echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
# ./x86_cpuload --count 1 --start 3 --timeout 100 --busy 99
would launch 1 thread and bind it to CPU3, lasting for 100 seconds,
with a CPU utilization of 99%. [1]
top result:
%Cpu3 : 98.4 us, 0.0 sy, 0.0 ni, 1.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
check util_avg:
cat /sys/kernel/debug/sched/debug | grep "cfs_rq\[3\]" -A 20 | grep util_avg
.util_avg : 611
So the util_avg/cpu capacity is 611/1024, which is much smaller than
98.4% shown in the top result.
This might impact some logic in the scheduler. For example,
group_is_overloaded() would compare the group_capacity and group_util
in the sched group, to check if this sched group is overloaded or not.
With this gap, even when there is a nearly 100% workload, the sched
group will not be regarded as overloaded. Besides group_is_overloaded(),
there are also other victims. There is a ongoing work that aims to
optimize the task wakeup in a LLC domain. The main idea is to stop
searching idle CPUs if the sched domain is overloaded[2]. This proposal
also relies on the util_avg/CPU capacity to decide whether the LLC
domain is overloaded.
Analysis:
CPU frequency invariance has caused this difference. In summary,
the util_sum of cfs rq would decay quite fast when the CPU is in
idle, when the CPU frequency invariance is enabled.
The detail is as followed:
As depicted in update_rq_clock_pelt(), when the frequency invariance
is enabled, there would be two clock variables on each rq, clock_task
and clock_pelt:
The clock_pelt scales the time to reflect the effective amount of
computation done during the running delta time but then syncs back to
clock_task when rq is idle.
absolute time | 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|16
@ max frequency ------******---------------******---------------
@ half frequency ------************---------************---------
clock pelt | 1| 2| 3| 4| 7| 8| 9| 10| 11|14|15|16
The fast decay of util_sum during idle is due to:
1. rq->clock_pelt is always behind rq->clock_task
2. rq->last_update is updated to rq->clock_pelt' after invoking
___update_load_sum()
3. Then the CPU becomes idle, the rq->clock_pelt' would be suddenly
increased a lot to rq->clock_task
4. Enters ___update_load_sum() again, the idle period is calculated by
rq->clock_task - rq->last_update, AKA, rq->clock_task - rq->clock_pelt'.
The lower the CPU frequency is, the larger the delta =
rq->clock_task - rq->clock_pelt' will be. Since the idle period will be
used to decay the util_sum only, the util_sum drops significantly during
idle period.
Proposal:
This symptom is not only caused by disabling turbo frequency, but it
would also appear if the user limits the max frequency at runtime.
Because, if the frequency is always lower than the max frequency,
CPU frequency invariance would decay the util_sum quite fast during
idle.
As some end users would disable turbo after boot up, this patch aims to
present this symptom and deals with turbo scenarios for now.
It might be ideal if CPU frequency invariance is aware of the max CPU
frequency (user specified) at runtime in the future.
Link: https://github.com/yu-chen-surf/x86_cpuload.git #1
Link: https://lore.kernel.org/lkml/20220310005228.11737-1-yu.c.chen@intel.com/ #2
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
A PM-runtime device usage count underflow is potentially critical,
because it may cause a device to be suspended when it is expected to
be operational. It is also a programming problem that would be good
to catch and warn about.
For this reason, (1) make rpm_check_suspend_allowed() return an error
when the device usage count is negative to prevent devices from being
suspended in that case, (2) introduce rpm_drop_usage_count() that will
detect device usage count underflows, warn about them and fix them up,
and (3) use it to drop the usage count in a few places instead of
atomic_dec_and_test().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
The initial configuration of ACPI power resources on some systems
implies that some PCI devices on them are initially in D3cold.
In some cases, especially for PCIe Root Ports, this is a "logical"
D3cold, meaning that the configuration space of the device is
accessible, but some of its functionality may be missing, but it
very well may be real D3cold, in which case the device will not
be accessible at all. However, the PCI bus type driver will need
to access its configuration space in order to enumerate it.
To prevent possible device enumeration failures that may ensue as
a result of ACPI power resources being initially in the "off"
state, power up all children of the host bridge ACPI device object
that hold valid _ADR objects (which indicates that they will be
enumerated by the PCI bus type driver) and do that to all children
of the ACPI device objects corresponding to PCI bridges (including
PCIe ports).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
Introduce a function powering up all of the children of a given ACPI
device object that are power-manageable and hold valid _ADR ACPI
objects so as to make it possible to prepare the corresponding
"physical" devices for enumeration carried out by a bus type driver,
like PCI.
This function will be used in a subsequent change set.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
Introduce a wrapper around device_for_each_child() to iterate over
the children of a given ACPI device object.
This function will be used in subsequent change sets.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
Convert all of the debug messages printed by acpi_device_set_power()
to acpi_handle_debug() and adjust them slightly for consistency with
acpi_device_get_power() and other acpi_device_set_power() debug
messages.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
All messages printed by functions in this file either contain
the "ACPI" or "acpi" string regardless of the format, or they don't
need to contain it at all.
In the former case, the "ACPI:" string added by the format is
redundant, so drop it from there.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Convert the debug message printed by acpi_device_get_power() to
acpi_handle_debug(), because that function is also called when
the ACPI device object name has not been set yet and the dev_dbg()
message printed by it at that time is not useful.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
powerpc's asm/prom.h brings some headers that it doesn't
need itself.
In order to clean it up, first add missing headers in
users of asm/prom.h
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Mention all domain attach menthods which dev_pm_domain_detach()
reverses.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Replace usleep_range() method with udelay() method to allow atomic contexts
in low-level MDIO access functions.
The following issue can be seen by doing the following:
$ modprobe -r bonding
$ modprobe -v bonding max_bonds=1 mode=1 miimon=100 use_carrier=0
$ ip link set bond0 up
$ ifenslave bond0 eth0 eth1
[ 982.357308] BUG: scheduling while atomic: kworker/u64:0/9/0x00000002
[ 982.364431] INFO: lockdep is turned off.
[ 982.368824] Modules linked in: bonding sctp ip6_udp_tunnel udp_tunnel mlx4_ib ib_uverbs ib_core mlx4_en mlx4_core nfp tls sunrpc intel_rapl_msr iTCO_wdt iTCO_vendor_support mxm_wmi dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate intel_uncore pcspkr lpc_ich mei_me ipmi_ssif mei ipmi_si ipmi_devintf ipmi_msghandler wmi acpi_power_meter xfs libcrc32c sr_mod cdrom sd_mod t10_pi sg mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm ahci libahci crc32c_intel libata i2c_algo_bit tg3 megaraid_sas igc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: bonding]
[ 982.437941] CPU: 25 PID: 9 Comm: kworker/u64:0 Kdump: loaded Tainted: G W --------- - - 4.18.0-348.el8.x86_64+debug #1
[ 982.451333] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 2.7.0 12/005/2017
[ 982.459791] Workqueue: bond0 bond_mii_monitor [bonding]
[ 982.465622] Call Trace:
[ 982.468355] dump_stack+0x8e/0xd0
[ 982.472056] __schedule_bug.cold.60+0x3a/0x60
[ 982.476919] __schedule+0x147b/0x1bc0
[ 982.481007] ? firmware_map_remove+0x16b/0x16b
[ 982.485967] ? hrtimer_fixup_init+0x40/0x40
[ 982.490625] schedule+0xd9/0x250
[ 982.494227] schedule_hrtimeout_range_clock+0x10d/0x2c0
[ 982.500058] ? hrtimer_nanosleep_restart+0x130/0x130
[ 982.505598] ? hrtimer_init_sleeper_on_stack+0x90/0x90
[ 982.511332] ? usleep_range+0x88/0x130
[ 982.515514] ? recalibrate_cpu_khz+0x10/0x10
[ 982.520279] ? ktime_get+0xab/0x1c0
[ 982.524175] ? usleep_range+0x88/0x130
[ 982.528355] usleep_range+0xdd/0x130
[ 982.532344] ? console_conditional_schedule+0x30/0x30
[ 982.537987] ? igc_put_hw_semaphore+0x17/0x60 [igc]
[ 982.543432] igc_read_phy_reg_gpy+0x111/0x2b0 [igc]
[ 982.548887] igc_phy_has_link+0xfa/0x260 [igc]
[ 982.553847] ? igc_get_phy_id+0x210/0x210 [igc]
[ 982.558894] ? lock_acquire+0x34d/0x890
[ 982.563187] ? lock_downgrade+0x710/0x710
[ 982.567659] ? rcu_read_unlock+0x50/0x50
[ 982.572039] igc_check_for_copper_link+0x106/0x210 [igc]
[ 982.577970] ? igc_config_fc_after_link_up+0x840/0x840 [igc]
[ 982.584286] ? rcu_read_unlock+0x50/0x50
[ 982.588661] ? lock_release+0x591/0xb80
[ 982.592939] ? lock_release+0x591/0xb80
[ 982.597220] igc_has_link+0x113/0x330 [igc]
[ 982.601887] ? lock_downgrade+0x710/0x710
[ 982.606362] igc_ethtool_get_link+0x6d/0x90 [igc]
[ 982.611614] bond_check_dev_link+0x131/0x2c0 [bonding]
[ 982.617350] ? bond_time_in_interval+0xd0/0xd0 [bonding]
[ 982.623277] ? rcu_read_lock_held+0x62/0xc0
[ 982.627944] ? rcu_read_lock_sched_held+0xe0/0xe0
[ 982.633198] bond_mii_monitor+0x314/0x2500 [bonding]
[ 982.638738] ? lock_contended+0x880/0x880
[ 982.643214] ? bond_miimon_link_change+0xa0/0xa0 [bonding]
[ 982.649336] ? lock_acquire+0x34d/0x890
[ 982.653615] ? lock_downgrade+0x710/0x710
[ 982.658089] ? debug_object_deactivate+0x221/0x340
[ 982.663436] ? rcu_read_unlock+0x50/0x50
[ 982.667811] ? debug_print_object+0x2b0/0x2b0
[ 982.672672] ? __switch_to_asm+0x41/0x70
[ 982.677049] ? __switch_to_asm+0x35/0x70
[ 982.681426] ? _raw_spin_unlock_irq+0x24/0x40
[ 982.686288] ? trace_hardirqs_on+0x20/0x195
[ 982.690956] ? _raw_spin_unlock_irq+0x24/0x40
[ 982.695818] process_one_work+0x8f0/0x1770
[ 982.700390] ? pwq_dec_nr_in_flight+0x320/0x320
[ 982.705443] ? debug_show_held_locks+0x50/0x50
[ 982.710403] worker_thread+0x87/0xb40
[ 982.714489] ? process_one_work+0x1770/0x1770
[ 982.719349] kthread+0x344/0x410
[ 982.722950] ? kthread_insert_work_sanity_check+0xd0/0xd0
[ 982.728975] ret_from_fork+0x3a/0x50
Fixes: 5586838fe9ce ("igc: Add code for PHY support")
Reported-by: Corinna Vinschen <vinschen@redhat.com>
Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Tested-by: Corinna Vinschen <vinschen@redhat.com>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
An infinite loop may occur if we fail to acquire the HW semaphore,
which is needed for resource release.
This will typically happen if the hardware is surprise-removed.
At this stage there is nothing to do, except log an error and quit.
Fixes: c0071c7aa5fe ("igc: Add HW initialization code")
Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
Fix access illegal address problem in following condition:
There are multiple devfreq cooling devices in system, some of them has
EM model but others do not. Energy model ops such as state2power will
append to global devfreq_cooling_ops when the cooling device with
EM model is registered. It makes the cooling device without EM model
also use devfreq_cooling_ops after appending when registered later by
of_devfreq_cooling_register_power() or of_devfreq_cooling_register().
The IPA governor regards the cooling devices without EM model as a power
actor, because they also have energy model ops, and will access illegal
address at dfc->em_pd when execute cdev->ops->get_requested_power,
cdev->ops->state2power or cdev->ops->power2state.
Fixes: 615510fe13bd2 ("thermal: devfreq_cooling: remove old power model and use EM")
Cc: 5.13+ <stable@vger.kernel.org> # 5.13+
Signed-off-by: Kant Fan <kant@allwinnertech.com>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Cleaning up the driver to use pm_sleep_ptr() macro instead of #ifdef
guards is simpler and allows the compiler to remove those functions
if built without CONFIG_PM_SLEEP support.
Signed-off-by: Hesham Almatary <hesham.almatary@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This driver currently rewrites bus_flags based solely on the value of
DT property 'data-mirror' and ignores bus_flags which might have been
set in DT panel-timing node. Specificaly, the 'de-active' DT property
sets DRM_BUS_FLAG_DE_ bus_flags.
Since of_get_drm_panel_display_mode() conveniently parses the bus_flags
out of DT panel-timing property, just ORR them with bus_flags inferred
from 'data-mirror' DT property and use the result as panel bus_flags.
This fixes handling of panels with 'panel-timing { de-active = <1>; };'.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dmitry Osipenko <digetx@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Robert Foss <robert.foss@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
To: dri-devel@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20220401162154.295152-2-marex@denx.de
|
|
The Energy Model power values might be artificial. In such case
it's safe to bail out during the registration, since the PowerCap
framework supports only micro-Watts.
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The Energy Model can now be artificial, which means the power values
are mathematically generated to leverage EAS while not expected to be on
an uniform scale with other devices providing power information. If this
EM type is in use, the thermal governor IPA should not be allowed to
operate, since the relation between cooling devices is not properly
defined. Thus, it might be possible that big GPU has lower power values
than a Little CPU. To mitigate a misbehaviour of the thermal control
algorithm, simply do not register the cooling device as IPA's power
actor.
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The mode parsing is currently implemented in three steps:
of_get_display_timing() - DT panel-timing to struct display_timing
videomode_from_timing() - struct display_timing to struct videomode
drm_display_mode_from_videomode() - struct videomode to struct drm_display_mode
Replace all that with simple of_get_drm_panel_display_mode() call,
which already populates struct drm_display_mode and then duplicate
that mode in panel_lvds_get_modes() each time, since the mode does
not change.
Nice bonus is the bus_flags parsed by of_get_drm_panel_display_mode()
out of panel-timing DT node, which is used in subsequent patch to fix
handling of 'de-active' DT property.
Tested-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dmitry Osipenko <digetx@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Robert Foss <robert.foss@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
To: dri-devel@lists.freedesktop.org
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220401162154.295152-1-marex@denx.de
|
|
The .active_power() callback passes the device pointer when it's called.
Aligned with a convetion present in other subsystems and pass the 'dev'
as a first argument. It looks more cleaner.
Adjust all affected drivers which implement that API callback.
Suggested-by: Ionela Voinescu <ionela.voinescu@arm.com>
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
To make debugging easier, convert driver to regmap. Implement read and write
regmap tables for known registers, keep all known register readable and mark
those which are obviously read-only as not writeable.
Use common I2C regmap for the I2C configuration, implement custom regmap bus
for DSI configuration. The later is mandatory as this chip requires one extra
byte set to read access length between register address and data.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Maxime Ripard <maxime@cerno.tech>
Cc: Robert Foss <robert.foss@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
To: dri-devel@lists.freedesktop.org
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220403171004.368464-1-marex@denx.de
|
|
Remove the pointless detour via __intel_fbc_post_update() during
frontbuffer flush.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-8-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
Let's make sure FBC is always disabled when we start to take
over the hardware state.
I suspect this should never really happen, since the only time
when we really should be taking over with the display already
active is when the previous state was progammed by the BIOS,
which likely shouldn't use FBC. This could be driver init,
or S4 resume when the boot kernel doesn't load i915. But I
suppose no harm in keeping this code around for exra safety
since it's quite trivial.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-7-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
By the time intel_fbc_global_disable() gets called during driver
teardown we should have already disabled all the crtcs, so
no way FBC should be enabled at this point.
And I have no idea what the other user (i915_restore_display())
is even trying to achieve.
So let's just throw intel_fbc_global_disable() into the bin.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-6-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
Now that fbc no longer nukes while a flip is pending we can
remove the last uncore.lock from the i9xx plane code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-5-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
Don't issue a nuke from frontbuffer flush while a flip is pending.
This avoids the DSPADDR/DSPSURF rmw abuse from the pre-snb nuke
from racing with the DSPADDR/DSPSURF write being performed by
the flip/plane update. The flip itself will already cause the nuke
so a double nuke is redundant.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-4-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
If the frontbuffer bits say this fbc instance isn't affected just
skip the whole thing.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-3-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
Not sure what the point of this fbc->possible_frontbuffer_bits is.
And especially don't see why it's returning all the bits when
fbc is not even enabled. So let's just get rid of this and only
say we are interested in the plane's frontbuffer bits when fbc
is actually enabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-2-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
|
|
Since the conversion to spi-mem, the driver advertised support for
various operations that cqspi_set_protocol() was never expected to handle
correctly - in particuar all non-DTR operations with command or address
buswidth > 1. For DTR, all operations except for 8-8-8 would fail, as
cqspi_set_protocol() returns -EINVAL.
In non-DTR mode, this resulted in data corruption for SPI-NOR flashes that
support such operations. As a minimal fix that can be backported to stable
kernels, simply disallow the unsupported operations again to avoid this
issue.
Fixes: a314f6367787 ("mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework")
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Link: https://lore.kernel.org/r/20220406132832.199777-1-matthias.schiffer@ew.tq-group.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This switch is not even supported, but if someone were to actually put
this compatible string "realtek,rtl8366s" in their device tree, they
would be greeted with a kernel panic because the probe function would
dereference NULL. So let's just remove it.
Link: https://lore.kernel.org/all/CACRpkdYdKZs0WExXc3=0yPNOwP+oOV60HRz7SRoGjZvYHaT=1g@mail.gmail.com/
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The kernel test robot reported a build failure:
or1k-linux-ld: drivers/net/dsa/realtek/realtek-smi.o:(.rodata+0x16c): undefined reference to `rtl8366rb_variant'
... with the following build configuration:
CONFIG_NET_DSA_REALTEK=y
CONFIG_NET_DSA_REALTEK_SMI=y
CONFIG_NET_DSA_REALTEK_RTL8365MB=y
CONFIG_NET_DSA_REALTEK_RTL8366RB=m
The problem here is that the realtek-smi interface driver gets built-in,
while the rtl8366rb switch subdriver gets built as a module, hence the
symbol rtl8366rb_variant is not reachable when defining the OF device
table in the interface driver.
The Kconfig dependencies don't help in this scenario because they just
say that the subdriver(s) depend on at least one interface driver. In
fact, the subdrivers don't depend on the interface drivers at all, and
can even be built even in their absence. Somewhat strangely, the
interface drivers can also be built in the absence of any subdriver,
BUT, if a subdriver IS enabled, then it must be reachable according to
the linkage of the interface driver: effectively what the IS_REACHABLE()
macro achieves. If it is not reachable, the above kind of linker error
will be observed.
Rather than papering over the above build error by simply using
IS_REACHABLE(), we can do a little better and admit that it is actually
the interface drivers that have a dependency on the subdrivers. So this
patch does exactly that. Specifically, we ensure that:
1. The interface drivers' Kconfig symbols must have a value no greater
than the value of any subdriver Kconfig symbols.
2. The subdrivers should by default enable both interface drivers, since
most users probably want at least one of them; those interface
drivers can be explicitly disabled however.
What this doesn't do is prevent a user from building only a subdriver,
without any interface driver. To that end, add an additional line of
help in the menu to guide users in the right direction.
Link: https://lore.kernel.org/all/202204110757.XIafvVnj-lkp@intel.com/
Reported-by: kernel test robot <lkp@intel.com>
Fixes: aac94001067d ("net: dsa: realtek: add new mdio interface for drivers")
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Previously it was not possible to determine which code path was responsible
for generating a certain message after a call to the nfp_X messaging
definitions for cases of duplicate strings. We therefore modify nfp_err,
nfp_warn, nfp_info, nfp_dbg and nfp_printk to print the corresponding file
and line number where the nfp_X definition is used.
Signed-off-by: Dylan Muller <dylan.muller@corigine.com>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The struct dbs_data embeds a struct gov_attr_set and
the struct gov_attr_set embeds a kobject. Since every kobject must have
a release() method and we can't use kfree() to free it directly,
so introduce cpufreq_dbs_data_release() to release the dbs_data via
the kobject::release() method. This fixes the calltrace like below:
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34
WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100
Modules linked in:
CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536
Hardware name: Marvell OcteonTX CN96XX board (DT)
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : debug_print_object+0xb8/0x100
lr : debug_print_object+0xb8/0x100
sp : ffff80001dfcf9a0
x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000
x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210
x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118
x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000
x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8
x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14
x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0
x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001
x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040
Call trace:
debug_print_object+0xb8/0x100
__debug_check_no_obj_freed+0x1d0/0x25c
debug_check_no_obj_freed+0x24/0xa0
kfree+0x11c/0x440
cpufreq_dbs_governor_exit+0xa8/0xac
cpufreq_exit_governor+0x44/0x90
cpufreq_set_policy+0x29c/0x570
store_scaling_governor+0x110/0x154
store+0xb0/0xe0
sysfs_kf_write+0x58/0x84
kernfs_fop_write_iter+0x12c/0x1c0
new_sync_write+0xf0/0x18c
vfs_write+0x1cc/0x220
ksys_write+0x74/0x100
__arm64_sys_write+0x28/0x3c
invoke_syscall.constprop.0+0x58/0xf0
do_el0_svc+0x70/0x170
el0_svc+0x54/0x190
el0t_64_sync_handler+0xa4/0x130
el0t_64_sync+0x1a0/0x1a4
irq event stamp: 189006
hardirqs last enabled at (189005): [<ffff8000080849d0>] finish_task_switch.isra.0+0xe0/0x2c0
hardirqs last disabled at (189006): [<ffff8000090667a4>] el1_dbg+0x24/0xa0
softirqs last enabled at (188966): [<ffff8000080106d0>] __do_softirq+0x4b0/0x6a0
softirqs last disabled at (188957): [<ffff80000804a618>] __irq_exit_rcu+0x108/0x1a4
[ rjw: Because can be freed by the gov_attr_set_put() in
cpufreq_dbs_governor_exit() now, it is also necessary to put the
invocation of the governor ->exit() callback into the new
cpufreq_dbs_data_release() function. ]
Fixes: c4435630361d ("cpufreq: governor: New sysfs show/store callbacks for governor tunables")
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Currently, the IO-links to the device being removed from topology,
are not cleared. As a result, there would be dangling links left in
the KFD topology. This patch aims to fix the following:
1. Cleanup all IO links to the device being removed.
2. Ensure that node numbering in sysfs and nodes proximity domain
values are consistent after the device is removed:
a. Adding a device and removing a GPU device are made mutually
exclusive.
b. The global proximity domain counter is no longer required to be
an atomic counter. A normal 32-bit counter can be used instead.
3. Update generation_count to let user-mode know that topology has
changed due to device removal.
CC: Shuotao Xu <shuotaoxu@microsoft.com>
Reviewed-by: Shuotao Xu <shuotaoxu@microsoft.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
MS_HYPERV with vega10 doesn't have the interface to process
request init data msg.
Check hypervisor type to not send the request for MS_HYPERV.
Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com>
Reviewed-by: Alice Wong <shiwei.wong@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
A MAX_GPU_INSTANCE bits bitmap will suffice.
Signed-off-by: Lang Yu <Lang.Yu@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why]
Extract update stream allocation table into link hwss as part of the
link hwss refactor work.
Reviewed-by: George Shen <George.Shen@amd.com>
Reviewed-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
Acked-by: Pavle Kotarac <Pavle.Kotarac@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why]
creating a generic helper for AMD specific PSR-SU sink validation.
Moving the function to the power module to reference it across all
OS.
[how]
- drop PSRSU specific sink validation helper and move to power
module by reading PSR version and other PSR caps
- call the new helper from linux DM (amdgpu_dm_psr)
Acked-by: Pavle Kotarac <Pavle.Kotarac@amd.com>
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: David Zhang <dingchen.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Intel Raptor Lake-S has the same SPI serial flash controller as Alder
Lake-P. Add Raptor Lake-S PCI ID to the driver list of supported
devices.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20220411112116.53281-1-mika.westerberg@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The Qualcomm SM8350 platform does, like the SM8450, provide a set of GPI
controllers with an ee-offset of 0x10000. Add this to the driver.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220412212959.2385085-1-bjorn.andersson@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Controller on newer SoCs like SM8450 have registers at at offset. Add
ee_offset to driver_data and add this compatible for the driver.
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220406132508.1029348-3-vkoul@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Newer platforms seem to have strict requirement for TRE flags which
causes transaction to timeout. This was resolved to missing chain and
link flag for duplex spi transaction.
So add these two flags.
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220406132508.1029348-1-vkoul@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Kalle Valo says:
====================
wireless fixes for v5.18
First set of fixes for v5.18. Maintainers file updates, two
compilation warning fixes, one revert for ath11k and smaller fixes to
drivers and stack. All the usual stuff.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Some implementations were returning type `unsigned long`, while others
that fell back to get_cycles() were implicitly returning a `cycles_t` or
an untyped constant int literal. That makes for weird and confusing
code, and basically all code in the kernel already handled it like it
was an `unsigned long`. I recently tried to handle it as the largest
type it could be, a `cycles_t`, but doing so doesn't really help with
much.
Instead let's just make random_get_entropy() return an unsigned long all
the time. This also matches the commonly used `arch_get_random_long()`
function, so now RDRAND and RDTSC return the same sized integer, which
means one can fallback to the other more gracefully.
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Rather than failing entirely if a copy_to_user() fails at some point,
instead we should return a partial read for the amount that succeeded
prior, unless none succeeded at all, in which case we return -EFAULT as
before.
This makes it consistent with other reader interfaces. For example, the
following snippet for /dev/zero outputs "4" followed by "1":
int fd;
void *x = mmap(NULL, 4096, PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
assert(x != MAP_FAILED);
fd = open("/dev/zero", O_RDONLY);
assert(fd >= 0);
printf("%zd\n", read(fd, x, 4));
printf("%zd\n", read(fd, x + 4095, 4));
close(fd);
This brings that same standard behavior to the various RNG reader
interfaces.
While we're at it, we can streamline the loop logic a little bit.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jann Horn <jannh@google.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Add support for the following ethtool commands:
ethtool -i|--driver devname
ethtool devname
ethtool -s devname [speed N] [autoneg on|off] [advertise N]
ethtool -S|--statistics devname
Signed-off-by: Veerasenareddy Burru <vburru@marvell.com>
Signed-off-by: Abhijit Ayarekar <aayarekar@marvell.com>
Signed-off-by: Satananda Burla <sburla@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add support to enable MSI-x and register interrupts.
Add support to process Tx and Rx traffic. Includes processing
Tx completions and Rx refill.
Signed-off-by: Veerasenareddy Burru <vburru@marvell.com>
Signed-off-by: Abhijit Ayarekar <aayarekar@marvell.com>
Signed-off-by: Satananda Burla <sburla@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
Sasha Neftin
Vinicius Costa Gomes
Tudor Ambarus
Chen Yu
Rafael J. Wysocki
Christophe Leroy
Krzysztof Kozlowski
Kant Fan
Hesham Almatary
Marek Vasut
Lukasz Luba
Ville Syrjälä
Matthias Schiffer
Alvin Šipraga
Dylan Muller
Kevin Hao
Mukul Joshi
Yongqiang Sun
Lang Yu
Wenjing Liu
David Zhang
Mika Westerberg
Bjorn Andersson
Vinod Koul
David S. Miller
Jason A. Donenfeld
Veerasenareddy Burru