The sixth PCIe controller on X1E80100 can be used in either
4-lanes mode or 2-lanes mode. Add the configuration and compatible
for the 4-lane mode.
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20240823-x1e80100-phy-add-gen4x4-v3-2-b7765631ca01@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The sixth PCIe instance on X1E80100 can be used in either 4-lane mode or
2-lane mode. Document the 4-lane mode as a separate compatible.
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20240823-x1e80100-phy-add-gen4x4-v3-1-b7765631ca01@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
This makes the code more compact and error handling more robust
by ensuring that mutexes are released in all code paths when control
leaves critical section.
Acked-by: Henrik Rydberg <rydberg@bitmath.org>
Link: https://lore.kernel.org/r/ZsrBVO2w9WwX73iU@google.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Use __free(kfree) cleanup facility in matrix_keypad_parse_keymap() to
automatically free temporarily allocated memory.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/ZspoEPdTcH-hpciy@google.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Merge series from Neil Armstrong <neil.armstrong@linaro.org>:
Following an off-list discution with Jerome about fixing the following
DTBs check errors:
sound: Unevaluated properties are not allowed ('assigned-clock-parents', 'assigned-clock-rates', 'assigned-clocks' were unexpected)
from schema $id: http://devicetree.org/schemas/sound/amlogic,axg-sound-card.yaml#
sound: Unevaluated properties are not allowed ('assigned-clock-parents', 'assigned-clock-rates', 'assigned-clocks' were unexpected)
from schema $id: http://devicetree.org/schemas/sound/amlogic,gx-sound-card.yaml#
sound: 'anyOf' conditional failed, one must be fixed:
'clocks' is a required property
'#clock-cells' is a required property
from schema $id: http://devicetree.org/schemas/clock/clock.yaml#
It has been agreed documenting the clock in the sound card is a better solution
than moving them to a random clock controller or consumer node which is not
related to the actual meaning of those root frequencies.
The patchset adds the clocks proprty to the bindings and finally adds the
properties to the DT files.
The QUPs aren't shared in a way that requires parking the RCG at an
always on parent in case some other entity turns on the clk. The
hardware is capable of setting a new frequency itself with the DFS mode,
so parking is unnecessary. Furthermore, there aren't any GDSCs for these
devices, so there isn't a possibility of the GDSC turning on the clks
for housekeeping purposes.
Like for the SM8550 GCC QUP clocks at [1], do not use shared clk_ops for QUPs.
[1] https://lore.kernel.org/all/20240827231237.1014813-3-swboyd@chromium.org/
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20240829-topic-sm8650-upstream-fix-qup-clk-rcg-shared-v1-1-7ecdbc672187@linaro.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Amit Pundir reports that audio and USB-C host mode stops working if the
gcc_usb30_prim_master_clk_src clk is registered and
clk_rcg2_shared_init() parks it on XO. Skip parking this clk at
registration time to fix those issues.
Partially revert commit 01a0a6cc8c ("clk: qcom: Park shared RCGs upon
registration") by skipping the parking bit for this clk, but keep the
part where we cache the config register. That's still necessary to
figure out the true parent of the clk at registration time.
Fixes: 01a0a6cc8c ("clk: qcom: Park shared RCGs upon registration")
Fixes: 929c75d575 ("clk: qcom: gcc-sm8550: Mark RCGs shared where applicable")
Cc: Konrad Dybcio <konradybcio@kernel.org>
Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Taniya Das <quic_tdas@quicinc.com>
Reported-by: Amit Pundir <amit.pundir@linaro.org>
Closes: https://lore.kernel.org/CAMi1Hd1KQBE4kKUdAn8E5FV+BiKzuv+8FoyWQrrTHPDoYTuhgA@mail.gmail.com
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20240819233628.2074654-3-swboyd@chromium.org
Tested-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The QUPs aren't shared in a way that requires parking the RCG at an
always on parent in case some other entity turns on the clk. The
hardware is capable of setting a new frequency itself with the DFS mode,
so parking is unnecessary. Furthermore, there aren't any GDSCs for these
devices, so there isn't a possibility of the GDSC turning on the clks
for housekeeping purposes.
This wasn't a problem to mark these clks shared until we started parking
shared RCGs at clk registration time in commit 01a0a6cc8c ("clk: qcom:
Park shared RCGs upon registration"). Parking at init is actually
harmful to the UART when earlycon is used. If the device is pumping out
data while the frequency changes you'll see garbage on the serial
console until the driver can probe and actually set a proper frequency.
Revert the QUP part of commit 929c75d575 ("clk: qcom: gcc-sm8550: Mark
RCGs shared where applicable") so that the QUPs don't get parked during
clk registration and break UART operations.
Fixes: 01a0a6cc8c ("clk: qcom: Park shared RCGs upon registration")
Fixes: 929c75d575 ("clk: qcom: gcc-sm8550: Mark RCGs shared where applicable")
Cc: Konrad Dybcio <konradybcio@kernel.org>
Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Taniya Das <quic_tdas@quicinc.com>
Reported-by: Amit Pundir <amit.pundir@linaro.org>
Closes: https://lore.kernel.org/CAMi1Hd1KQBE4kKUdAn8E5FV+BiKzuv+8FoyWQrrTHPDoYTuhgA@mail.gmail.com
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20240819233628.2074654-2-swboyd@chromium.org
Tested-by: Amit Pundir <amit.pundir@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Commit 8bccf667f6 ("Input: cypress_ps2 - report timeouts when reading
command status") uncovered an existing problem with cypress_ps2 driver:
it tries waiting on a PS/2 device waitqueue without using the rest of
libps2. Unfortunately without it nobody signals wakeup for the
waiting process, and each "extended" command was timing out. But the
rest of the code simply did not notice it.
Fix this by switching from homegrown way of sending request to get
command response and reading it to standard ps2_command() which does
the right thing.
Reported-by: Woody Suwalski <terraluna977@gmail.com>
Tested-by: Woody Suwalski <terraluna977@gmail.com>
Fixes: 8bccf667f6 ("Input: cypress_ps2 - report timeouts when reading command status")
Link: https://lore.kernel.org/r/a8252e0f-dab4-ef5e-2aa1-407a6f4c7204@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
For mes11 old firmware has issue to map legacy queue,
add a flag to switch mes to map legacy queue.
Fixes: f9d8c5c785 ("drm/amdgpu/gfx: enable mes to map legacy queue support")
Reported-by: Andrew Worsley <amworsley@gmail.com>
Link: https://lists.freedesktop.org/archives/amd-gfx/2024-August/112773.html
Signed-off-by: Jack Xiao <Jack.Xiao@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
ih1 is not initialized for APUs. Don't drain it or NULL pointer
error will be triggered.
Fixes: 6ef29715ac ("drm/amdkfd: Change kfd/svm page fault drain handling")
Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When MES is enabled KIQ is not available. Return an error
when someone uses the debugfs preempt test interface in
that case.
Acked-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When MES is enabled KIQ is not available. Return an error
when someone uses the debugfs preempt test interface in
that case.
Acked-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
DCN IPS interoperates with other system idle power features, such as
Zstates.
On DCN35, there is a known issue where system Z8 + DCN IPS2 causes a
hard hang. We observe this on systems where the SBIOS allows Z8.
Though there is a SBIOS fix, there's no guarantee that users will get it
any time soon, or even install it. A workaround is needed to prevent
this from rearing its head in the wild.
[How]
For DCN35, check the pmfw version to determine whether the SBIOS has the
fix. If not, set IPS1+RCG as the deepest possible state in all cases
except for s0ix and display off (DPMS). Otherwise, enable all IPS
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
log message "Dumping IP State Completed" needs to
be logged only once when state dumping is complete.
Hence moving it out of the for loop.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Acked-by: Trigger Huang <Trigger.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[background] when unloading amdgpu driver right after running a
workload, drain_workqueue is causing "Fence fallback timer
expired on ring sdma0.0". Under sriov, this issue will cause sriov
full access timeout and a reset happening.
move drain_workqueue before shutdown is set to allow ih process and
before enter full access under sriov to avoid full access time cost.
Signed-off-by: Victor Zhao <Victor.Zhao@amd.com>
Reviewed-by: Feifei Xu <Feifei.Xu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Do the coredump immediately after a job timeout to get a closer
representation of GPU's error status.
V2: This will skip printing vram_lost as the GPU reset is not
happened yet (Alex)
V3: Unconditionally call the core dump as we care about all the reset
functions(soft-recovery and queue reset and full adapter reset, Alex)
V4: Do the dump after adev->job_hang = true (Sunil)
Signed-off-by: Trigger Huang <Trigger.Huang@amd.com>
Acked-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The vm lost status can only be obtained after a GPU reset occurs, but
sometimes a dev core dump can be happened before GPU reset. So a new
argument is added to tell the dev core dump implementation whether to
skip printing the vram_lost status in the dump.
And this patch is also trying to decouple the core dump function from
the GPU reset function, by replacing the argument amdgpu_reset_context
with amdgpu_job to specify the context for core dump.
V2: Inform user if VRAM lost check is skipped so users don't assume
VRAM wasn't lost (Alex)
Signed-off-by: Trigger Huang <Trigger.Huang@amd.com>
Suggested-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add this flag to enable experimental resets for testing before they
are fully validated.
Reviewed-and-tested-by: Jiadong Zhu <Jiadong.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
It is to fix in try_disable_dsc() due to misrevert of
commit 338567d176 ("drm/amd/display: Fix MST BW calculation Regression")
[How]
Fix restoring minimum compression bw by 'max_kbps', instead of native bw 'stream_kbps'
Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This is useful for debug, in case something goes wrong with the GSC. The
info includes the version information and the current value of the HECI1
status registers.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240828215158.2743994-5-daniele.ceraolospurio@intel.com
The GSC compatibility version number is reset for each new platform. To
indicate this, the version includes a number that identifies the
platform (102 = MTL, 104 = LNL); this matches what happens for the
release version, where the major number also identifies a platform.
To make it clearer in our logs that the compatibility version is
specific to the platform, it is useful to include this platform number.
However, given that our binary names already include the platform, it is
not necessary to add this extra number there.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240828215158.2743994-4-daniele.ceraolospurio@intel.com
We set the FW status to "TRANSFERRED" after the load completes and to
"RUNNING"once we're done with proxy init, so do the same if we're trying
to re-load the FW and it is already loaded.
Note that there is no difference in driver behavior between the 2
states, but it's useful to be accurate when we dump the status for
debug.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240828215158.2743994-3-daniele.ceraolospurio@intel.com
The GSC HW is only reset by driver FLR or D3cold entry. We don't support
the former at runtime, while the latter is only supported on DGFX, for
which we don't support GSC. Therefore, if GSC failed to load previously
there is no need to try again because the HW is stuck in the error state.
An assert has been added so that if we ever add DGFX support we'll know
we need to handle the D3 case.
v2: use "< 0" instead of "!= 0" in the FW state error check (Julia).
Fixes: dd0e89e5ed ("drm/xe/gsc: GSC FW load")
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Cc: <stable@vger.kernel.org> # v6.8+
Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240828215158.2743994-2-daniele.ceraolospurio@intel.com
LPC32XX connects few of its peripherals to pl08x DMA thru a multiplexer,
this driver allows to route a signal request line thru the multiplexer for
given peripheral.
Signed-off-by: Piotr Wojtaszczyk <piotr.wojtaszczyk@timesys.com>
Link: https://lore.kernel.org/r/20240628152022.274405-1-piotr.wojtaszczyk@timesys.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Check src ID to detect misuse of same src ID for multiple DMA channels.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20240701070232.2519179-3-joy.zou@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Introduce a scope guard to automatically unlock the mutex within
fsl_edma3_xlate() to simplify the code.
Prepare to add source ID checks in the future.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20240701070232.2519179-2-joy.zou@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Using an arbitrary string as a printf-style format can be a security
problem if that string contains % characters, as the optionalal
-Wformat-security flag points out:
drivers/dma/dmaengine.c: In function '__dma_async_device_channel_register':
drivers/dma/dmaengine.c:1073:17: error: format not a string literal and no format arguments [-Werror=format-security]
1073 | dev_set_name(&chan->dev->device, name);
| ^~~~~~~~~~~~
Change this newly added instance to use "%s" as the format instead to
pass the actual name.
Fixes: 10b8e0fd3f ("dmaengine: add channel device name to channel registration")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/20240719102319.546622-1-arnd@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
i.MX21 support has been removed since commit 4b563a0666 ("ARM: imx:
Remove imx21 support").
Remove the i.MX21 support inside the imx-dma driver.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20240806021744.2524233-1-festevam@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Document the IPG and AHB clocks that are needed by the DMA hardware
as required properties.
It is not possible to have DMA functional without the DMA clocks
being turned on.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240807170517.64290-1-festevam@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
ZynqMP DMA IP and AMD Versal Gen 2 DMA IP are similar but have different
interrupt register offset. Create a dedicated compatible string to
support Versal Gen 2 DMA IP with Irq register offset for interrupt
Enable/Disable/Status/Mask functionality.
Signed-off-by: Abin Joseph <abin.joseph@amd.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Link: https://lore.kernel.org/r/20240808100024.317497-3-abin.joseph@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add compatible string "amd,versal2-dma-1.0" to support AMD Versal Gen 2
platform.
AMD Versal Gen 2 has 8 LPD DMA IPs in PS that can be used as general
purpose DMAs which is designed to support memory to memory and memory to
IO buffer transfer. Versal Gen 2 DMA IP has different interrupt register
offset.
Signed-off-by: Abin Joseph <abin.joseph@amd.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240808100024.317497-2-abin.joseph@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
ACPICA commit 6c551e2c9487067d4b085333e7fe97e965a11625
Link: 6c551e2c
Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit aaa08569b81aa4d9ff59f91f00e589e98d499e6c
Redefine the 2 reserved bytes at offset 28 of Memory Side Cache Information
Structure as "Address Mode" and add defines of the new value.
* 0 - Reserved (Unkown Address Mode)
* 1 - Extended-linear (N direct-map aliases linearly mapped)
* 2..65535 - Reserved (Unknown Address Mode)
Link: aaa08569
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 6031b34b5dbabfaaebe80e57e8e415790b51d285
Only include the functions acpi_rs_dump_resource_list
and acpi_rs_dump_irq_list() if ACPI_DEBUGGER is defined, as
specified in the header.
This avoids the compiler warning by adding the ifdef for ACPI_DEBUGGER.
Link: 6031b34b
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit f2cb44f6deb6325a6b348b225fc82f565a870899
Add "0x" prefix for explicitly converted integers
and suppress leading zeros in such a case.
Provides compatibility with other ACPI implementations.
Link: f2cb44f6
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 86289439d9f8b9eda28c249da66ae230d6439491
Currently the leading_zeros argument has no effect when
converting hex integers. Fix that.
Link: 86289439
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 792a337104ce2c1729d33d76241b42b3214aa60f
Allow to specifiy wether leading zeros should be supressed
ot not when using acpi_ex_convert_to_ascii().
Link: 792a3371
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
A new DSA device ID, 0x1212, and a new IAA device ID, 0x1216, are
introduced for Diamond Rapids platform. Add the device IDs to the IDXD
driver.
The name "IAA" is used in new code instead of the old name "IAX".
However, the "IAX" naming (e.g., IDXD_TYPE_IAX) is retained for legacy
code compatibility.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/20240828233401.186007-3-fenghua.yu@intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
A new DSA device ID, 0x11fb, is introduced for the Granite Rapids-D
platform. Add the device ID to the IDXD driver.
Since a potential security issue has been fixed on the new device, it's
secure to assign the device to virtual machines, and therefore, the new
device ID will not be added to the VFIO denylist. Additionally, the new
device ID may be useful in identifying and addressing any other potential
issues with this specific device in the future. The same is also applied
to any other new DSA/IAA devices with new device IDs.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/20240828233401.186007-2-fenghua.yu@intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
