Mårten Lindahl [Tue, 14 Jun 2022 09:38:55 +0000 (11:38 +0200)]
hwmon: (pmbus) Add list_voltage to pmbus ops
When checking if a regulator supports a voltage range, the regulator
needs to have a list_voltage callback set to the regulator_ops or else
-EINVAL will be returned. This support does not exist for the pmbus
regulators, so this patch adds pmbus_regulator_list_voltage to the
pmbus_regulator_ops.
Mårten Lindahl [Tue, 14 Jun 2022 09:38:54 +0000 (11:38 +0200)]
hwmon: (pmbus) Introduce and use cached vout margins
When setting a new voltage the voltage boundaries are read every time to
check that the new voltage is within the proper range. Checking these
voltage boundaries consists of reading one of PMBUS_MFR_VOUT_MIN/
PMBUS_VOUT_MARGIN_LOW registers and then PMBUS_MFR_VOUT_MAX/
PMBUS_VOUT_MARGIN_HIGH together with writing the PMBUS_CLEAR_FAULTS
register.
Since these boundaries are never being changed, it can be cached and
thus saving unnecessary smbus transmissions.
Liang He [Thu, 16 Jun 2022 11:40:24 +0000 (19:40 +0800)]
hwmon: (gsc-hwmon) Add missing of_node_put()
In gsc_hwmon_get_devtree_pdata(), of_find_compatible_node() will return
a node pointer with refcount incremented. We should use of_node_put() in
fail path or when it is not used anymore.
Armin Wolf [Sun, 12 Jun 2022 23:22:08 +0000 (01:22 +0200)]
hwmon: (dell-smm) Add Dell G5 5590 to DMI table
According to Bug 215983 at bugzilla.kernel.org,
the Dell G5 5590 supports the SMM interface and
can thus be loaded with ignore_dmi being set.
Add the model the DMI table to allow for
automatic loadig on this model.
Armin Wolf [Sun, 12 Jun 2022 04:18:06 +0000 (06:18 +0200)]
hwmon: (dell-smm) Add Dell XPS 13 7390 to fan control whitelist
A user reported that the program dell-bios-fan-control
worked on his Dell XPS 13 7390 to switch off automatic
fan control.
Since it uses the same mechanism as the dell_smm_hwmon
module, add this model to the fan control whitelist.
Ren Zhijie [Thu, 9 Jun 2022 12:04:48 +0000 (20:04 +0800)]
hwmon: (pmbus) fix build error unused-function
If CONFIG_PMBUS is y and CONFIG_DEBUG_FS is not set.
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-, will be failed, like this:
drivers/hwmon/pmbus/pmbus_core.c:593:13: error: ‘pmbus_check_block_register’ defined but not used [-Werror=unused-function]
static bool pmbus_check_block_register(struct i2c_client *client, int page,
^~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[3]: *** [drivers/hwmon/pmbus/pmbus_core.o] Error 1
make[2]: *** [drivers/hwmon/pmbus] Error 2
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [drivers/hwmon] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [drivers] Error 2
To fix building warning, use __maybe_unused to attach this func.
Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: c3ffc3a1ff83("hwmon: (pmbus) add a function to check the presence of a block register") Signed-off-by: Ren Zhijie <renzhijie2@huawei.com> Link: https://lore.kernel.org/r/20220609120448.139907-1-renzhijie2@huawei.com
[groeck: Fixed continuation line alignment] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
hwmon: (lm90) Read the channel's temperature offset from device-tree
Try to read the channel's temperature offset from device-tree. Having
offset in device-tree node is not mandatory. The offset can only be set
for remote channels.
Adam Wujek [Wed, 1 Jun 2022 01:33:17 +0000 (01:33 +0000)]
hwmon: (pmbus) add MFR_* registers to debugfs
Add registers to debugfs:
PMBUS_MFR_ID
PMBUS_MFR_MODEL
PMBUS_MFR_REVISION
PMBUS_MFR_LOCATION
PMBUS_MFR_DATE
PMBUS_MFR_SERIAL
To reduce the number of debugfs entries, only values from page 0 are
reported. It is assumed that values of these registers are the same for
all pages. Please note that the PMBUS standard allows added registers to
be page-specific.
Adam Wujek [Wed, 1 Jun 2022 01:33:03 +0000 (01:33 +0000)]
hwmon: (pmbus) add a function to check the presence of a block register
Other functions (like pmbus_check_byte_register) cannot be used to check
the presence of a block register, because it will generate error when PEC
is used.
Armin Wolf [Sat, 4 Jun 2022 22:02:00 +0000 (00:02 +0200)]
hwmon: (sch56xx-common) Add DMI override table
Some devices like the Fujitsu Celsius W380 do contain
a working sch56xx hardware monitoring device, but do
not contain the necessary DMI onboard device.
Do not check for the presence of an suitable onboard device
on these machines. The list of affected machines was created
using data collected by the Linux Hardware Project.
Tested on a Fujitsu Esprimo P720, but sadly not on a affected
machine.
Fixes: 393935baa45e (hwmon: (sch56xx-common) Add automatic module loading on supported devices) Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220604220200.2567-1-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Sun, 16 Jan 2022 16:55:49 +0000 (08:55 -0800)]
hwmon: (lm90) Support temp_samples attribute
Several of the chips supported by this driver support configuring the
number of samples (or the fault queue depth) necessary before a fault
or alarm is reported. This is done either with a bit in the configuration
register or with a separate "consecutive alert" register. Support this
functionality with the temp_samples attribute.
Guenter Roeck [Tue, 28 Dec 2021 15:59:26 +0000 (07:59 -0800)]
hwmon: (lm90) Only disable alerts if not already disabled
It was observed that the alert handler may be called from the i2c core
even after alerts have already been disabled. Only disable alerts if
they have not already been disabled.
Guenter Roeck [Thu, 16 Dec 2021 03:58:01 +0000 (19:58 -0800)]
hwmon: (lm90) Add support for ADT7421
ADT7421 is similar to ADT7461A but supports configurable Beta Compensation.
Packet Error Checking (PEC) is supported but undocumented.
A devicetree node is not added for the added chip since it is quite
unlikely that such an old chip will ever be used in a devicetree based
system. It can be added later if needed.
Guenter Roeck [Mon, 13 Dec 2021 19:26:54 +0000 (11:26 -0800)]
hwmon: (lm90) Add support for ON Semiconductor NCT218
NCT218 is compatible to NCT72 and NCT214. It also supports PEC (packet
error checking). Similar to NCT72 and NCT214, PEC support is undocumented.
Unlike NCT214 and NCT72, NCT218 does not support the undocumented secondary
chip and manufacturer ID registers at 0x3e and 0x3f and returns 0x00 when
reading those registers. The value for the chip revision register is not
documented but was observed to be 0xca. Use that information to improve
chip detection accuracy.
Guenter Roeck [Fri, 3 Dec 2021 05:58:25 +0000 (21:58 -0800)]
hwmon: (lm90) Add support for ON Semiconductor NCT214 and NCT72
NCT214 and NCT72 are compatible to ADT7461/ADT7461A but have full
PEC (packet error checking) support. PEC support is undocumented.
Both chips support the undocumented secondary chip and manufacturer
ID registers at 0x3e and 0x3f, and return 0x61 as chip ID. Use this
information to improve the accuracy of chip detection code.
Guenter Roeck [Thu, 6 Jan 2022 20:12:31 +0000 (12:12 -0800)]
hwmon: (lm90) Add explicit support for NCT210
Unlike ADM1023 and compatible chips, NCT210 does not support a temperature
offset register. A real chip was found to have a chip revision of 0x3f.
Use it to detect NCT210 explicitly.
Guenter Roeck [Mon, 22 Nov 2021 21:00:34 +0000 (13:00 -0800)]
hwmon: (lm90) Add remaining chips supported by adm1021 driver
All chips supported by the ADM1021 driver are also supported by the LM90
driver. Make that support official.
After this change, the adm1021 driver is only needed if the lm90 driver
is disabled. Also, the adm1021 driver misdetects a variety of chips as
MAX1617A, which is unwanted if any of those chips is in the system.
For this reason. make the adm1021 driver dependent on !SENSORS_LM90 to
show that it is not needed if the lm90 driver is enabled, and to avoid
misdetection if a chip supported by the lm90 driver is in the system.
Devicetree nodes are not added for the added chips since it is quite
unlikely that such old chips will ever be used in a devicetree based
system. They can be added later if needed.
Guenter Roeck [Sat, 20 Nov 2021 00:21:37 +0000 (16:21 -0800)]
hwmon: (lm90) Add support for ADM1021, ADM1021A, and ADM1023
Both chips are quite similar to other chips of this series, so add
support for them to the lm90 driver. Also mention ON Semiconductor NCT210,
which is pin and register compatible to ADM1021A.
None of the chips support the secondary manufacturer and chip ID registers
at 0x3e and 0x3f, but return 0 when reading from those registers.
Use that information to improve the accuracy of chip detection code.
Devicetree nodes are not added for the added chips since it is quite
unlikely that such old chips will ever be used in a devicetree based
system. They can be added later if needed.
Guenter Roeck [Fri, 19 Nov 2021 21:55:47 +0000 (13:55 -0800)]
hwmon: (lm90) Support MAX1617 and LM84
MAX1617 and LM84 are stripped-down versions of LM90, so they can easily
be supported by the LM90 driver. The most difficult part is chip detection,
since those old chips do not support manufacturer ID or chip ID registers.
The "alarms" attribute is enabled for both chips to match the functionality
of the adm1021 driver. Chip detection was improved and is less prone to
misdetection than the chip detection in the adm1021 driver.
Devicetree nodes are not added for the added chips since it is quite
unlikely that such old chips will ever be used in a devicetree based
system. They can be added later if needed.
Guenter Roeck [Fri, 19 Nov 2021 22:24:18 +0000 (14:24 -0800)]
hwmon: (lm90) Let lm90_read16() handle 8-bit read operations
Simplify the code a bit by handling single-register read operations
in lm90_read16(). All we need to do is to skip the low-byte read
operation if the register address is 0.
Guenter Roeck [Tue, 16 Nov 2021 02:10:11 +0000 (18:10 -0800)]
hwmon: (lm90) Add support for MAX6642
MAX6642 is a reduced version of LM90 with no low limits and no conversion
rate register. Its alert functionality is broken, similar to many other
chips supported by the lm90 driver.
After this change, the stand-alone max6642 driver is only needed if the
lm90 driver is disabled. Make it dependent on SENSORS_LM90=n to show that
it is not needed if the lm90 driver is enabled.
A devicetree node is not added for this chip since it is quite unlikely
that such an old chip will ever be used in a devicetree based system.
It can be added later if needed.
Guenter Roeck [Sat, 13 Nov 2021 06:03:31 +0000 (22:03 -0800)]
hwmon: (lm90) Add support for MAX6690
MAX6690 is all but identical to MAX6654. Revision 1 of its
datasheet lists the same chip ID as MAX6654, and a chip labeled
MAX6654 was found to have the chip ID listed as MAX6690 chip ID
in Revision 2 of its datasheet.
A devicetree node is not added for this chip since it is quite unlikely
that such an old chip will ever be used in a devicetree based system.
It can be added later if needed.
Guenter Roeck [Sat, 11 Dec 2021 03:35:20 +0000 (19:35 -0800)]
hwmon: (lm90) Strengthen chip detection for ADM1032, ADT7461(A), and NCT1008
ADT7461A and NCT1008 support the undocumented manufacturer and chip ID
registers at 0x3e and 0x3f, and return 0x61 as chip ID. ADM1032 and
ADT7461 do not support those registers but return 0 when reading them.
Use this information to improve the accuracy of the chip detection code.
Guenter Roeck [Sat, 6 Nov 2021 16:59:26 +0000 (09:59 -0700)]
hwmon: (lm90) Add support for ADT7481, ADT7482, and ADT7483
ADT7481, ADT7482, and ADT7483 are similar to ADT7461, but support two
external temperature sensors, similar to MAX6695/6696. They support an
extended temperature range similar to ADT7461. Registers for the second
external channel can be accessed directly or by using the same method as
used by MAX6695/6696. For simplicity, the access method implemented for
MAX6695/6696 is used.
The chips support PEC (packet error checking). Set the PEC feature flag
and let the user decide if it should be enabled or not (it is by default
disabled).
Even though it is only documented for ADT7483, all three chips support a
secondary manufacturer ID register at 0x3e and a chip ID register at 0x3f.
Use the contents of those registers register for improved chip detection
accuracy. Add the same check to the ADT7461A detection code since this chip
also supports the same (undocumented) registers.
Devicetree nodes are not added for the added chips since it is quite
unlikely that such old chips will ever be used in a devicetree based
system. They can be added later if needed.
Guenter Roeck [Sat, 6 Nov 2021 04:58:51 +0000 (21:58 -0700)]
hwmon: (lm90) Add explicit support for MAX6648/MAX6692
Unlike MAX6646/MAX6647/MAX6649, MAX6648 and MAX6692 only support
a temperature range of 0..127 degrees C. Separate support for the
two sets of chips to be able to support maximum temperature ranges
correctly for all chips. Introduce new feature flag to indicate
temperature support up to 255 degrees C.
Since the chips are almost identical except for the supported temperature
range, automatic chip detection is limited. Effectively this means that
MAX6648 may be mis-detected as MAX6649 when auto-detected, but there is
nothing we can do about that.
Devicetree nodes are not added for the added chips since it is quite
unlikely that such old chips will ever be used in a devicetree based
system. They can be added later if needed.
Guenter Roeck [Wed, 17 Nov 2021 19:57:57 +0000 (11:57 -0800)]
hwmon: (lm90) Add flag to indicate 'alarms' attribute support
We don't want to support the obsolete 'alarms' attribute for new
chips supported by this driver. Add flag to indicate 'alarms' attribute
support and use it for existing chips. This flag will not be set for
additional chips supported by this driver in the future.
Guenter Roeck [Fri, 3 Dec 2021 00:19:27 +0000 (16:19 -0800)]
hwmon: (lm90) Fix/Add detection of G781-1
When support for G781 was added, chips with ID 0x01 were found at I2C
addresses 0x4c and 0x4d. The G781 datasheet (version 1.3 from October 2003)
says that the device ID for G781-1 is 0x03, not 0x01. Also, the datasheet
states that the chip at I2C address is G781 and the chip at I2C address
0x4d is G781-1.
A G781-1 at I2C address 0x4d was now found to have a chip ID of 0x03
as suggested by the datasheet. Accept both 0x01 and 0x03 chip IDs at both
addresses to ensure that all variants of G781 are detected properly.
While at it, improve chip detection accuracy by reading two additional
registers and ensuring that only expected bits are set in those registers.
Guenter Roeck [Tue, 21 Dec 2021 01:02:36 +0000 (17:02 -0800)]
hwmon: (lm90) Add support for additional chip revision of NCT1008
The NCT1008 datasheet, Revision 3, states that its chip revision is
0x57. This matches the ADT7461A chip revision, and NCT1008 is therefore
detected as ADT7461A. In revision 6 of the datasheet, the chip revision
register is no longer documented. Multiple samples of NCT1008 were found
to report a chip revision of 0x54. As it turns out, one of the patches
submitted to add NCT1008 support to the lm90 driver already included a
check for chip revision 0x54. Unfortunately, that patch never made it into
the kernel. Remedy the situation and explicitly detect chips with revision
0x54 as NCT1008.
Guenter Roeck [Wed, 10 Nov 2021 04:38:22 +0000 (20:38 -0800)]
hwmon: (lm90) Rework detect function
The detect function is getting larger and larger and difficult to
understand or review. Split it into per-manufacturer detect functions
to improve readability.
Guenter Roeck [Mon, 22 Nov 2021 16:13:58 +0000 (08:13 -0800)]
hwmon: (lm90) Use single flag to indicate extended temperature support
Since temperature conversion functions are now unified, there is no need
to keep "the chip supports a configurable extended temperature range" and
"the chip has extended temperature range enabled" flags separate.
Use a single flag instead to reflect both.
Guenter Roeck [Wed, 3 Nov 2021 05:38:59 +0000 (22:38 -0700)]
hwmon: (lm90) Support multiple temperature resolutions
While most LM90 compatible chips support a temperature sensor resolution
of 11 bit, this is not the case for all chips. ADT7461 only supports a
resolution of 10 bit, and TMP451/TMP461 support a resolution of 12 bit.
Add support for various temperature sensor resolutions. To do this,
model all temperature sensors as 16 bit sensors, and use unified
temperature conversion functions which take the sensor resolution
as parameter.
While enhancing functionality, this has the positive side effect of
reducing code size by about 5%.
Guenter Roeck [Fri, 5 Nov 2021 23:04:52 +0000 (16:04 -0700)]
hwmon: (lm90) Only re-read registers if volatile
When reading 16-bit volatile registers, the code uses a trick to
determine if a temperature is consistent: It reads the high part
of the register twice. If the values are the same, the code assumes
that the reading is consistent. If the value differs, the code
re-reads the second register as well and assumes that it now has
correct values.
This is only necessary for volatile registers. Add a parameter to
lm90_read16() to indicate if the register is volatile to avoid the
extra overhead for non-volatile registers.
Guenter Roeck [Sat, 4 Dec 2021 15:53:00 +0000 (07:53 -0800)]
hwmon: (lm90) Add support for unsigned and signed temperatures
ADT7461 and TMP451 temperature sensors support extended temperature ranges.
If standard temperature range is selected, the temperature range is
unsigned and limited to 0 .. 127 degrees C. For TMP461, the standard
temperature range is -128000 ... 127000 degrees C. Distinguish between
the two chips by introducing a feature flag indicating if the standard
temperature range is signed or unsigned. Use the same flag for MAX6646/
MAX6647 as well since those chips also support unsigned temperatures.
Note that while the datasheet for ADT7461 suggests that the default
temperature range is unsigned, tests with a real chip suggest that this
is not the case: If the temperature offset is set to a value << 0,
the temperature register does report negative values.
Tests with real chips show that MAX6680/MAX6681 and SA56004 report
temperatures of 128 degrees C and higher as negative temperatures.
Add respective comments to the code.
Also use clamp_val() and DIV_ROUND_CLOSEST where appropriate in
calculations.
Guenter Roeck [Sat, 11 Dec 2021 05:18:27 +0000 (21:18 -0800)]
hwmon: (lm90) Enable full PEC support for ADT7461A
Experiments show that ADT7461A and NCT1008 support PEC, even though it is
not documented. Enable support for it in the driver. Since ADT7461 only
supports partial PEC, this means that the configuration for ADT7461A
needs to be separated from ADT7461.
Guenter Roeck [Tue, 9 Nov 2021 01:45:05 +0000 (17:45 -0800)]
hwmon: (lm90) Add partial PEC support for ADT7461
Revision 0 of the ADT7461 datasheet suggests that the chip supports PEC
(packet error checking). This information is gone in later versions of the
datasheet. Experiments show that PEC support on ADT7461 is similar to PEC
support in ADM1032, ie it is only supported for read operations. Add
support for it to the driver.
Guenter Roeck [Sun, 31 Oct 2021 16:34:33 +0000 (09:34 -0700)]
hwmon: (lm90) Improve PEC support
PEC (packet error checking) support for ADM1032 is currently only enabled
if the chip was auto-detected, but not if a chip is instantiated
explicitly. Always enable PEC support by introducing a chip feature flag
indicating partial PEC support. Also, for consistency, disable PEC support
by default to match existing functionality if the chip was not auto-
detected.
At the same time, introduce generic support for PEC with a separate feature
flag. This will be used when support for chips with full PEC functionality
is added.
Guenter Roeck [Sun, 31 Oct 2021 09:01:41 +0000 (02:01 -0700)]
hwmon: (lm90) Stop using R_/W_ register prefix
The register write address either matches the read address, or it is the
read address plus 6. Simplify the code and resolve the write address
programmatically instead of having two defines for each register.
Guenter Roeck [Sat, 30 Oct 2021 16:05:45 +0000 (09:05 -0700)]
hwmon: (lm90) Reorder chip enumeration to be in alphabetical order
Reorder chip enumeration in alphabetical order to make it easier to
see which chips are supported, and to clarify where to add support
new chip types. No functional change.
Guenter Roeck [Sat, 30 Oct 2021 16:02:56 +0000 (09:02 -0700)]
hwmon: (lm90) Reorder include files in alphabetical order
Reorder include files in alphabetical order to reduce the chance of
duplicates and to make it clear where new include files should be
added. Drop the unnecessary include of linux/sysfs.h. Include
linux/device.h instead because that is what is actually used.
Guenter Roeck [Sun, 9 Jan 2022 22:19:01 +0000 (14:19 -0800)]
hwmon: (lm90) Rework alarm/status handling
Many chips supported by this driver clear status registers after it
is read and update it in the next measurement cycle. Normally this falls
under the radar because all registers are only read once per measurement
cycle. However, there is an exception: Status registers are always read
during interrupt and laert handling. This can result in invalid status
reports if userspace reads an alarm attribute immediately afterwards.
Rework alarm/status handling by keeping a shadow register with 'current'
alarms, and by ensuring that the register is either only updated once per
measurement cycle or not cleared.
A second problem is related to alert handling: Alert handling is disabled
for chips with broken alert after an alert was reported, but only
re-enabled if attributes are read by the user. This means that alert
conditions may appear and disappear unnoticed. Remedy the situation
by introducing a worker to periodically read the status register(s) while
alert handling is disabled, and re-enable alerts after the alert condition
clears.
Yet another problem is that sysfs and udev events are currently only
reported to userspace if an alarm is raised, but not if an alarm condition
clears. Use the new worker to detect that situation and also generate
sysfs and udev events in that case.
Guenter Roeck [Fri, 20 May 2022 18:47:21 +0000 (11:47 -0700)]
hwmon: (pmbus) Move pec attribute to I2C device
Enabling and disabling PEC for PMBus devices is currently only supported
with a debugfs attribute, which requires debugfs to be enabled and is
thus less than perfect. Take the lm90 driver as example and add a 'pec'
attribute to the I2C device if both the I2C adapter and the PMBus device
support it. Remove the now obsolete 'pec' attribute from debugfs.
Cc: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Mario Kleiner [Mon, 11 Jul 2022 17:39:28 +0000 (19:39 +0200)]
drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.
Various DCE versions had trouble with 36 bpp lb depth, requiring fixes,
last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display
on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but now I
found out that on DCE-11.2 it causes dithering when there shouldn't be
any, so identity pixel passthrough with identity gamma LUTs doesn't work
when it should. This breaks various important neuroscience applications,
as reported to me by scientific users of Polaris cards under Ubuntu 22.04
with Linux 5.15, and confirmed by testing it myself on DCE-11.2.
Lets only use depth 36 for DCN engines, where my testing showed that it
is both necessary for high color precision output, e.g., RGBA16 fb's,
and not harmful, as far as more than one year in real-world use showed.
DCE engines seem to work fine for high precision output at 30 bpp, so
this ("famous last words") depth 30 should hopefully fix all known problems
without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on
top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # 5.14.0 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Fri, 8 Jul 2022 15:45:57 +0000 (11:45 -0400)]
drm/amd/display: make some dc_dmub_srv functions static
Not used outside of dc_dmub_srv.c.
Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: André Almeida <andrealmeid@igalia.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Tue, 12 Jul 2022 13:22:23 +0000 (09:22 -0400)]
drm/amdgpu: fix file permissions on some files
Drop execute.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2085 Reviewed-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Kent Russell [Tue, 12 Jul 2022 12:09:06 +0000 (08:09 -0400)]
drm/amdgpu: Fix acronym typo in glossary
The initialism of RunList Controller is RLC, not RCL
Signed-off-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
- Fixes for MST, MPO, PSRSU, DP 2.0, Freesync and others
- Add register offsets of NBI and DCN.
- Improvement of ALPM
- Removing assert statement for Linux DM
- Re-implementing ARGB16161616 pixel format
Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Aric Cyr <aric.cyr@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Samson Tam [Tue, 28 Jun 2022 20:20:00 +0000 (16:20 -0400)]
drm/amd/display: Fix lag when moving windowed MPO across display using ODM 2:1 combine
[Why]
With single display odm 2:1 policy, when moving windowed MPO across
the display, we experience a momentary lag when we move between the
centre of the display and the right half of the display. This is
caused by the MPO pipe being reallocated when it crosses this
boundary
[How]
Handle two cases:
1. if the head pipe has a MPO pipe already allocated in the old
context, then use that pipe if it is available in the current
context
2. if the head pipe is on the left side, check the right side to
see if it has a MPO pipe already allocated. If so, don't use
that pipe if it is selected as the idle pipe in the current
context
Add new function pointer called .acquire_idle_pipe_for_head_pipe
that will pass in the head pipe and handle case 1
Add find_idle_secondary_pipe_check_mpo() to handle case 2
if we don't hit case 1.
In dc_add_plane_to_context(), start with head pipe and check
case 1 and 2 in call acquire_free_pipe_for_head().
If we are on the right side of the display, check case 1
again by passing in right side pipe as the new head in
call acquire_free_pipe_for_head().
Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by: Ariel Bernstein <Eric.Bernstein@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Samson Tam <Samson.Tam@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Harry Wentland [Tue, 1 Feb 2022 20:37:37 +0000 (15:37 -0500)]
drm/amd/display: Add DCN reg offsets to DC
[Why&How]
Add a field to store the DCN IP offset for use with runtime offset
calculation
This offset is indexed using reg*_BASE_IDX for the corresponding
group of registers. For example, address of DIG_BE_CNTL instance 0 is
calculated like: dcn_reg_offsets[regDIG0_DIG_BE_CNTL_BASE_IDX] +
regDIG0_DIG_BE_CNTL.
{dcn,nbio}_reg_offsets are used only for the ASICs for which runtime
initializaion of offsets are enabled through the modified SR* macros
that contain an additional REG_STRUCT element in the macro definition.
DCN3.5+ will fail dc_create() if {dcn,nbio}_reg_offsets are null. They
are applicable starting with DCN32/321 and are not used for ASICs
upstreamed before them. ASICs before DCN32/321 will not contain any
computation that involves {dcn,nbio}_reg_offsets. For them, the
address/offset computation is done during compile time.
This is evident from the BASE_INNER definition for compile time vs run
time initialization:
Compile time init: #define BASE_INNER(seg) DCN_BASE__INST0_SEG ## seg
Run time init: #define BASE_INNER(seg) ctx->dcn_reg_offsets[seg]
BASE_INNER macro is local to each dcnxx_resource.c and hence different
ASICs can have either runtime or compile time initialization of offsets.
The computation of offset is done for registers all at once during
driver load and hence it does not introduce any performance overhead
during normal operation.
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Charlene Liu [Wed, 29 Jun 2022 14:27:21 +0000 (10:27 -0400)]
drm/amd/display: add system info table log
[why]
insert log for debug use.
v2: squash in fix (Alex)
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Wayne Lin [Tue, 31 May 2022 09:46:24 +0000 (17:46 +0800)]
drm/amd/display: Grab dc_lock before detecting link
[Why & How]
There is chance we change dc state while calling dc_link_detect().
As the result of that, grab the dm.dc_lock before detecting link.
Reviewed-by: Hersen Wu <hersen.wu@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Re-implementing ARGB16161616 pixel format as 22
[Why]
ABGR16161616 colour format was added to dcn10/20/30, and set
any ARGB16161616 to the same value as it (26). As such, the
HDR10 Green Point y value was too far off of the EDID stated
value for DisplayPort.
[How]
Added back the pixel format as 22 for ARGB16161616 for
dcn10/20/30.
Reviewed-by: Reza Amini <reza.amini@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Ethan Wellenreiter <Ethan.Wellenreiter@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Jun Lei [Fri, 24 Jun 2022 20:28:50 +0000 (16:28 -0400)]
drm/amd/display: update DML1 logic for unbounded req handling
[why]
Unbounded request logic in resource/DML has some issues where
unbounded request is being enabled incorrectly. SW today enables
unbounded request unconditionally in hardware, on the assumption
that HW can always support it in single pipe scenarios.
This worked until now because the same assumption is made in DML.
A new DML update is needed to fix a bug, where there are single
pipe scenarios where unbounded cannot be enabled, and this change
in DML needs to be ported in, and dcn32 resource logic fixed.
[how]
First, dcn32_resource should program unbounded req in HW according
to unbounded req enablement output from DML, as opposed to DML input
Second, port in DML1 update which disables unbounded req in some
scenarios to fix an issue with poor stutter performance
Reviewed-by: Nevenko Stupar <Nevenko.Stupar@amd.com> Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Jun Lei <jun.lei@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Le Ma [Fri, 30 Oct 2020 03:26:23 +0000 (11:26 +0800)]
drm/amdgpu/mes: ring aggregatged doorbell when mes queue is unmapped
Ring aggregated doorbel to make unmapped queue scheduled in mes firmware.
Signed-off-by: Le Ma <le.ma@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Jack Xiao <Jack.Xiao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Le Ma [Fri, 30 Oct 2020 03:24:07 +0000 (11:24 +0800)]
drm/amdgpu/mes: init aggregated doorbell
Allocate and enable aggregated doorbell.
Signed-off-by: Le Ma <le.ma@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Jack Xiao <Jack.Xiao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Move reset_context out of gpu recover function to make it configurable
for different reset purpose.
For the reset way of call gpu_recovery sysfs, force to use full reset
method. Otherwise, try soft reset by default if the related ASIC
supportted, if soft reset failed, will use full reset.
Chris Park [Thu, 23 Jun 2022 22:21:59 +0000 (18:21 -0400)]
drm/amd/display: Reduce SCDC Status Flags Definition
[Why]
Status flags definition is reduced to read
less bytes in SCDC transaction for status update.
[How]
Reduce definition of reserved bytes from 3 to 1
for status update.
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Chris Park <chris.park@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amdkfd: correct the MEC atomic support firmware checking for GC 10.3.7
On the GC 10.3.7 platform the initial MEC release version #3 can support
atomic operation,so need correct and set its MEC atomic support version to #3.
Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Aaron Liu <aaron.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Wenjing Liu [Mon, 13 Jun 2022 15:45:31 +0000 (11:45 -0400)]
drm/amd/display: make enable link independent from verified link caps
[why]
Ideally link capability should be independent from the link
configuration that we decide to use in enable link. Otherwise if link
capability is changed after validation has completed, we could end up
enabling a link configuration with invalid configuration. This would
lead to over link bandwidth subscription or in the extreme case
causes us to enable HPO link to a DIO stream.
[how]
Add a new struct in pipe ctx called link config. This structure will
contain link configuration to enable a link. It will be populated
during map pool resources after we validate link bandwidth. Remove
the reference of verified link cap during enable link process and
use link config in pipe ctx instead.
Reviewed-by: George Shen <George.Shen@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Ignore First MST Sideband Message Return Error
[why]
First MST sideband message returns AUX_RET_ERROR_HPD_DISCON
on certain intel platform. Aux transaction considered failure
if HPD unexpected pulled low. The actual aux transaction success
in such case, hence do not return error.
[how]
Not returning error when AUX_RET_ERROR_HPD_DISCON detected
on the first sideband message.
v2: squash in additional DMI entries
v3: squash in static fix
Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Acked-by: Solomon Chiu <solomon.chiu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Matthew Auld [Tue, 12 Jul 2022 17:40:50 +0000 (18:40 +0100)]
drm/i915/ttm: fix 32b build
Since segment_pages is no longer a compile time constant, it looks the
DIV_ROUND_UP(node->size, segment_pages) breaks the 32b build. Simplest
is just to use the ULL variant, but really we should need not need more
than u32 for the page alignment (also we are limited by that due to the
sg->length type), so also make it all u32.
Claudio Imbrenda [Tue, 28 Jun 2022 13:56:07 +0000 (15:56 +0200)]
KVM: s390: pv: add export before import
Due to upcoming changes, it will be possible to temporarily have
multiple protected VMs in the same address space, although only one
will be actually active.
In that scenario, it is necessary to perform an export of every page
that is to be imported, since the hardware does not allow a page
belonging to a protected guest to be imported into a different
protected guest.
This also applies to pages that are shared, and thus accessible by the
host.
projects / people / ms / linux.git / log
