aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-04-11ASoC: tda7419: use simple i2c probe functionStephen Kitt1-3/+2
The i2c probe functions here don't use the id information provided in their second argument, so the single-parameter i2c probe function ("probe_new") can be used instead. This avoids scanning the identifier tables during probes. Signed-off-by: Stephen Kitt <steve@sk2.org> Link: https://lore.kernel.org/r/20220405165836.2165310-12-steve@sk2.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: tas*: use simple i2c probe functionStephen Kitt5-15/+10
The i2c probe functions here don't use the id information provided in their second argument, so the single-parameter i2c probe function ("probe_new") can be used instead. This avoids scanning the identifier tables during probes. Signed-off-by: Stephen Kitt <steve@sk2.org> Link: https://lore.kernel.org/r/20220405165836.2165310-11-steve@sk2.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: sta*: use simple i2c probe functionStephen Kitt3-9/+6
The i2c probe functions here don't use the id information provided in their second argument, so the single-parameter i2c probe function ("probe_new") can be used instead. This avoids scanning the identifier tables during probes. Signed-off-by: Stephen Kitt <steve@sk2.org> Link: https://lore.kernel.org/r/20220405165836.2165310-10-steve@sk2.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: pcm*: use simple i2c probe functionStephen Kitt5-15/+10
The i2c probe functions here don't use the id information provided in their second argument, so the single-parameter i2c probe function ("probe_new") can be used instead. This avoids scanning the identifier tables during probes. Signed-off-by: Stephen Kitt <steve@sk2.org> Link: https://lore.kernel.org/r/20220405165836.2165310-9-steve@sk2.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: nau8*: use simple i2c probe functionStephen Kitt6-18/+12
The i2c probe functions here don't use the id information provided in their second argument, so the single-parameter i2c probe function ("probe_new") can be used instead. This avoids scanning the identifier tables during probes. Signed-off-by: Stephen Kitt <steve@sk2.org> Link: https://lore.kernel.org/r/20220405165836.2165310-8-steve@sk2.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: ml26124: use simple i2c probe functionStephen Kitt1-3/+2
The i2c probe functions here don't use the id information provided in their second argument, so the single-parameter i2c probe function ("probe_new") can be used instead. This avoids scanning the identifier tables during probes. Signed-off-by: Stephen Kitt <steve@sk2.org> Link: https://lore.kernel.org/r/20220405165836.2165310-7-steve@sk2.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: max9*: use simple i2c probe functionStephen Kitt12-35/+24
The i2c probe functions here don't use the id information provided in their second argument, so the single-parameter i2c probe function ("probe_new") can be used instead. This avoids scanning the identifier tables during probes. Signed-off-by: Stephen Kitt <steve@sk2.org> Link: https://lore.kernel.org/r/20220405165836.2165310-6-steve@sk2.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: lm4857: use simple i2c probe functionStephen Kitt1-3/+2
The i2c probe functions here don't use the id information provided in their second argument, so the single-parameter i2c probe function ("probe_new") can be used instead. This avoids scanning the identifier tables during probes. Signed-off-by: Stephen Kitt <steve@sk2.org> Link: https://lore.kernel.org/r/20220405165836.2165310-5-steve@sk2.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: es83*: use simple i2c probe functionStephen Kitt2-6/+4
The i2c probe functions here don't use the id information provided in their second argument, so the single-parameter i2c probe function ("probe_new") can be used instead. This avoids scanning the identifier tables during probes. Signed-off-by: Stephen Kitt <steve@sk2.org> Link: https://lore.kernel.org/r/20220405165836.2165310-4-steve@sk2.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: cx2072x: use simple i2c probe functionStephen Kitt1-3/+2
The i2c probe functions here don't use the id information provided in their second argument, so the single-parameter i2c probe function ("probe_new") can be used instead. This avoids scanning the identifier tables during probes. Signed-off-by: Stephen Kitt <steve@sk2.org> Link: https://lore.kernel.org/r/20220405165836.2165310-3-steve@sk2.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: ak4*: use simple i2c probe functionStephen Kitt4-12/+8
The i2c probe functions here don't use the id information provided in their second argument, so the single-parameter i2c probe function ("probe_new") can be used instead. This avoids scanning the identifier tables during probes. Signed-off-by: Stephen Kitt <steve@sk2.org> Link: https://lore.kernel.org/r/20220405165836.2165310-2-steve@sk2.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: amd: Add support for enabling DMIC on acp6x via _DSDMario Limonciello1-0/+13
Currently the acp6x machine driver requires a hardcoded list of systems that physically have DMIC connected. To avoid having to continually add to an evergrowing list of systems add support for a _DSD that can advertise this. OEMs can add this _DSD to their BIOS under the ACP device to automatically add the device to this driver without requiring any driver modifications. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220411134532.13538-3-mario.limonciello@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: amd: Add driver data to acp6x machine driverMario Limonciello1-4/+25
Currently all of the quirked systems use the same card and so the DMI quirk list doesn't contain driver data. Add driver data to these quirks and then check the data was present or not. This will allow potentially setting quirks for systems with faulty firmware that claims to have a DMIC but doesn't really. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220411134532.13538-2-mario.limonciello@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: SOF: ipc: Move the ipc_set_get_comp_data() local to ipc3-controlPeter Ujfalusi3-97/+88
The snd_sof_ipc_set_get_comp_data() only used for kcontrol data update and it is an IPC3 message parsing function. Move it out from the generic ipc.c to ipc3-control.c and rename it to better describe it's function. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220405172708.122168-16-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: SOF: sof-audio: Use the widget_kcontrol_setup ops for kcontrol set upPeter Ujfalusi1-50/+4
Remove the local implementation and switch to the IPC neutral ops to set up the kcontrols associated with the swidget. The set up call uses snd_sof_ipc_set_get_comp_data() which is largely an IPC3 parsing function. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220405172708.122168-15-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: SOF: Add widget_kcontrol_setup control ops for IPC3Peter Ujfalusi2-0/+40
Define and set the widget_kcontrol_setup control IPC ops for IPC3. The widget_kcontrol_setup callback can be used to set up all kcontrols associated with the swidget. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220405172708.122168-14-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: SOF: ipc: Switch over to use the rx_msg opsPeter Ujfalusi2-453/+4
Use the new ops for handling message reception. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220405172708.122168-13-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: SOF: ipc: Switch over to use the tx_msg and set_get_data opsPeter Ujfalusi1-278/+23
Use the new ops for sending messages and to handle large component data set get operation. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220405172708.122168-12-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: SOF: ipc: Use the get_reply ops in snd_sof_ipc_get_reply()Peter Ujfalusi1-48/+2
Use the get_reply ops to allow IPC dependent handling of the reply message. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220405172708.122168-11-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: SOF: ipc: Add check for mandatory IPC message handling opsPeter Ujfalusi1-0/+5
Make sure that the mandatory IPC message handling ops are provided by the IPC implementation. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220405172708.122168-10-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: SOF: ipc: Separate the ops checks by functions/topicsPeter Ujfalusi1-3/+9
Separate the mandatory ops checks by topics (pcm and topology for now) to be able to provide intuitive feedback on the possible missing ops and to make it easier to add new mandatory ops checks in the future. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220405172708.122168-9-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: SOF: ipc3: Implement rx_msg IPC opsPeter Ujfalusi1-0/+212
Add the implementation for the rx_msg callback to handle message reception for IPC3. The implementation is equivalent to the currently used code in ipc.c Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220405172708.122168-8-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: SOF: ipc3: Implement the get_reply IPC opsPeter Ujfalusi1-0/+55
Add the implementation for the get_reply callback to copy the reply message from mailbox to msg->reply_data buffer. The implementation is equivalent to the currently used code in ipc.c Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220405172708.122168-7-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: SOF: ipc3: Implement the set_get_data IPC opsPeter Ujfalusi1-0/+103
Add the implementation for the set_get_data callback for handling large data set and get. The set_get_data() in IPC3 can be used only for component messages. The function expects the caller to prepare the message behind the data pointer for sending/receiving data. The callback only implements the needed code to be able to split up a message if needed for transfer. The set_get_data ops is based on the existing snd_sof_ipc_set_get_comp_data() and sof_set_get_large_ctrl_data() but made it generic entry point. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220405172708.122168-6-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: SOF: ipc3: Use sof_ipc3_tx_msg() internally for message sendingPeter Ujfalusi1-2/+2
Instead of using sof_ipc_tx_message() for sending message, use the sof_ipc3_tx_msg() directly within ipc3.c Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220405172708.122168-5-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: SOF: ipc3: Implement the tx_msg IPC opsPeter Ujfalusi1-0/+308
Add the implementation for the IPC3 tx_msg callback for sending a single IPC message. The implementation is equivalent to the currently used code in ipc.c Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220405172708.122168-4-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: SOF: Add high level IPC IO callback definitions to ipc_opsPeter Ujfalusi1-0/+21
Add tx_msg(), rx_msg(), set_get_data() and get_reply() ops, which can be used as a generic API for sending, receiving single messages and to write and read large data. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220405172708.122168-3-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: SOF: Add helper function to prepare and send an IPC messagePeter Ujfalusi2-0/+55
The new sof_ipc_send_msg() can be used by IPC dependent code to prepare the ipc->msg for a new message transmission and then call in to platform code to send the message. Higher level code should be handling the completion and reply. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220405172708.122168-2-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11drm/i915/dg2: Do not explode on phy calibration errorLucas De Marchi1-2/+1
When the PHY fails on calibration we were previously skipping the ddi initialization. However the driver is not really prepared for that, ultimately leading to a NULL pointer dereference: [ 75.748348] i915 0000:03:00.0: [drm:intel_modeset_init_nogem [i915]] SNPS PHY A failed to calibrate; output will not be used. ... [ 75.750336] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [CRTC:80:pipe A] hw state readout: enabled ... ( no DDI A/PHY A ) [ 75.753080] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [ENCODER:235:DDI B/PHY B] hw state readout: disabled, pipe A [ 75.753164] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [ENCODER:245:DDI C/PHY C] hw state readout: disabled, pipe A ... [ 75.754425] i915 0000:03:00.0: [drm] *ERROR* crtc 80: Can't calculate constants, dotclock = 0! [ 75.765558] i915 0000:03:00.0: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev)) [ 75.765569] WARNING: CPU: 5 PID: 1759 at drivers/gpu/drm/drm_vblank.c:728 drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x347/0x360 ... [ 75.781230] BUG: kernel NULL pointer dereference, address: 000000000000007c [ 75.788198] #PF: supervisor read access in kernel mode [ 75.793347] #PF: error_code(0x0000) - not-present page [ 75.798480] PGD 0 P4D 0 [ 75.801019] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 75.805377] CPU: 5 PID: 1759 Comm: modprobe Tainted: G W 5.18.0-rc1-demarchi+ #199 [ 75.827613] RIP: 0010:icl_aux_power_well_disable+0x3b/0x200 [i915] [ 75.833890] Code: 83 ec 30 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 48 8b 06 0f b6 70 1c f6 40 20 04 8d 56 fa 0f 45 f2 e8 88 bd ff ff 48 89 ef <8b> 70 7c e8 ed 67 ff ff 48 89 ef 89 c6 e8 73 67 ff ff 84 c0 75 0a [ 75.852629] RSP: 0018:ffffc90003a7fb30 EFLAGS: 00010246 [ 75.857852] RAX: 0000000000000000 RBX: ffff8881145e8f10 RCX: 0000000000000000 [ 75.864978] RDX: ffff888115220840 RSI: 0000000000000000 RDI: ffff888115220000 [ 75.872106] RBP: ffff888115220000 R08: ffff88888effffe8 R09: 00000000fffdffff [ 75.879234] R10: ffff88888e200000 R11: ffff88888ed00000 R12: ffff8881145e8f10 [ 75.886363] R13: 0000000000000001 R14: ffff888115223240 R15: 0000000000000000 [ 75.893490] FS: 00007ff6e753a740(0000) GS:ffff88888f680000(0000) knlGS:0000000000000000 [ 75.901573] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 75.907313] CR2: 000000000000007c CR3: 00000001216a6001 CR4: 0000000000770ee0 [ 75.914446] PKRU: 55555554 [ 75.917153] Call Trace: [ 75.919603] <TASK> [ 75.921709] intel_power_domains_sanitize_state+0x88/0xb0 [i915] [ 75.927814] intel_modeset_init_nogem+0x317/0xef0 [i915] [ 75.933205] i915_driver_probe+0x5f6/0xdf0 [i915] [ 75.937976] i915_pci_probe+0x51/0x1d0 [i915] We skip the initialization of PHY A, but later we try to find out what is the phy for that power well and dereference dig_port, which is NULL. Failing the PHY calibration could be left as a warning or error, like it was before commit b4eb76d82a0e ("drm/i915/dg2: Skip output init on PHY calibration failure"). However that often fails for outputs not being used, which would make the warning/error appear on systems that have no visible issues. Anyway, there is still a need to fix those failures, but that is left for later. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220410061537.4187383-1-lucas.demarchi@intel.com
2022-04-11phy: qcom-qmp: Add SM6350 UFS PHY supportLuca Weiss1-0/+3
The SM6350 UFS PHY is compatible with the one from SDM845. Add a compatible for that. Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://lore.kernel.org/r/20220321133318.99406-4-luca.weiss@fairphone.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-04-11dt-bindings: phy: qcom,qmp: Add SM6350 UFS PHY bindingsLuca Weiss1-0/+2
Document the compatible string for the UFS PHY found in SM6350. Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20220321133318.99406-3-luca.weiss@fairphone.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-04-11drm/radeon: remove r600_blit_shaders.[c|h]Tom Rix3-758/+1
The only use of the global variables in r600_blit_shaders.c were in the old drivers/gpu/drm/radeon/r600_blit.c This file was removed in commit 8333f607a631 ("drm/radeon: remove UMS support") So remove the r600_blit_shaders.[c|h] files Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-11drm/amd/display: Disallow entering PSR when panel is disconnectedMax Erenberg1-0/+5
[WHY] The dGPU cannot enter PSR when it is not connected to a panel. [HOW] Added a check to dc_link_set_psr_allow_active which returns early if panel is disconnected. Reviewed-by: Harry Vanzylldejong <harry.vanzylldejong@amd.com> Reviewed-by: Evgenii Krasnikov <Evgenii.Krasnikov@amd.com> Reviewed-by: Nicholas Choi <Nicholas.Choi@amd.com> Acked-by: Pavle Kotarac <Pavle.Kotarac@amd.com> Signed-off-by: Max Erenberg <merenber@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-11drm/amd/display: Disabling Z10 on DCN31Saaem Rizvi1-0/+1
[WHY] Z10 is should not be enabled by default on DCN31. [HOW] Using DC debug flags to disable Z10 by default on DCN31. Reviewed-by: Eric Yang <Eric.Yang2@amd.com> Acked-by: Pavle Kotarac <Pavle.Kotarac@amd.com> Signed-off-by: Saaem Rizvi <syerizvi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-11drm/amd/display: do not wait for mpc idle if tg is disabledJosip Pavic1-1/+2
[Why] When booting, the driver waits for the MPC idle bit to be set as part of pipe initialization. However, on some systems this occurs before OTG is enabled, and since the MPC idle bit won't be set until the vupdate signal occurs (which requires OTG to be enabled), this never happens and the wait times out. This can add hundreds of milliseconds to the boot time. [How] Do not wait for mpc idle if tg is disabled Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Pavle Kotarac <Pavle.Kotarac@amd.com> Signed-off-by: Josip Pavic <Josip.Pavic@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-11drm/amd/display: undo clearing of z10 related function pointersEric Yang1-5/+0
[Why] Z10 and S0i3 have some shared path. Previous code clean up , incorrectly removed these pointers, which breaks s0i3 restore [How] Do not clear the function pointers based on Z10 disable. Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Pavle Kotarac <Pavle.Kotarac@amd.com> Signed-off-by: Eric Yang <Eric.Yang2@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-11drm/amdgpu: add umc query error status functionStanley.Yang1-58/+48
In order to debug ras error, driver will print IPID/SYND/MISC0 register value if detect correctable or uncorrectable error. Provide umc_query_error_status_helper function to reduce code redundancy. Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-11drm/amd/display: fix 64 bit divide in freesync codeAlex Deucher1-1/+1
Use div_u64() rather than a a 64 bit divide. Fixes: 3fe5739db48843 ("drm/amd/display: Add flip interval workaround") Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Angus Wang <Angus.Wang@amd.com> Cc: Anthony Koo <Anthony.Koo@amd.com> Cc: Aric Cyr <Aric.Cyr@amd.com> Cc: Nathan Chancellor <nathan@kernel.org>
2022-04-11drm/amdgpu: Fix incorrect enum typeGrigory Vasilyev3-3/+3
Instead of the 'amdgpu_ring_priority_level' type, the 'amdgpu_gfx_pipe_priority' type was used, which is an error when setting ring priority. This is a minor error, but may cause problems in the future. Instead of AMDGPU_RING_PRIO_2 = 2, we can use AMDGPU_RING_PRIO_MAX = 3, but AMDGPU_RING_PRIO_2 = 2 is used for compatibility with AMDGPU_GFX_PIPE_PRIO_HIGH = 2, and not change the behavior of the code. Signed-off-by: Grigory Vasilyev <h0tc0d3@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-11drm/radeon: change cayman_default_state table from global to staticTom Rix3-326/+290
cayman_default_state and cayman_default_size are only used in ni.c. Single file symbols should be static. So move their definitions to cayman_blit_shaders.h and change their storage-class-specifier to static. Remove unneeded cayman_blit_shader.c cayman_ps/vs definitions were removed with commit 4f8629675800 ("drm/radeon/kms: remove r6xx+ blit copy routines") So their declarations in cayman_blit_shader.h are not needed, so remove them. Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-11drm/amd/amdgpu: Update debugfs GCA dataTom St Denis1-3/+4
The data revision was not changed to 5 from 4 when the CG flags were extended to 64-bits. Since this was missed I took the opportunity to add future upper 64-bits of PG flags as well so we don't need to bump it again when that comes. Signed-off-by: Tom St Denis <tom.stdenis@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-11drm/amd/amdgpu: Fix asm/hypervisor.h build error.Yongqiang Sun1-0/+4
Add CONFIG_X86 check to fix the build error. Fixes: 49aa98ca30cd18 ("drm/amd/amdgpu: Only reserve vram for firmware with vega9 MS_HYPERV host.") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-11drm/amdkfd: Handle drain retry fault race with XNACK mode changePhilip Yang1-5/+6
Application could change XNACK enabled to disabled while KFD is draining stale retry fault, therefore the check for whether to drain retry faults must be before the check for whether xnack_enabled, to avoid report incorrect vm fault after application changes XNACK mode. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-11drm/amdgpu: Use flexible array memberLijo Lazar2-5/+5
Use flexible array member in ip discovery struct as recommended[1]. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays v2: squash in struct_size fixes Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-11phy: ti: tusb1210: Fix an error handling path in tusb1210_probe()Christophe JAILLET1-2/+8
tusb1210_probe_charger_detect() must be undone by a corresponding tusb1210_remove_charger_detect() in the error handling path, as already done in the remove function. Fixes: 48969a5623ed ("phy: ti: tusb1210: Add charger detection") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/07c4926c42243cedb3b6067a241bb486fdda01b5.1648991162.git.christophe.jaillet@wanadoo.fr Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-04-11drm: mali-dp: potential dereference of null pointerJiasheng Jiang1-1/+4
The return value of kzalloc() needs to be checked. To avoid use of null pointer '&state->base' in case of the failure of alloc. Fixes: 99665d072183 ("drm: mali-dp: add malidp_crtc_state struct") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Reviewed-by: Brian Starkey <brian.starkey@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211214100837.46912-1-jiasheng@iscas.ac.cn
2022-04-11drm/arm/malidp: Stop using iommu_present()Robin Murphy1-9/+5
iommu_get_domain_for_dev() is already perfectly happy to return NULL if the given device has no IOMMU. Drop the unnecessary check. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/5049994e6c2ba92c2f30d51850c8929136d0f8ca.1649167878.git.robin.murphy@arm.com
2022-04-11drm/komeda: return early if drm_universal_plane_init() fails.Liviu Dudau1-2/+4
If drm_universal_plane_init() fails early we jump to the common cleanup code that calls komeda_plane_destroy() which in turn could access the uninitalised drm_plane and crash. Return early if an error is detected without going through the common code. Reported-by: Steven Price <steven.price@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/dri-devel/20211203100946.2706922-1-liviu.dudau@arm.com
2022-04-11drm/komeda: Fix an undefined behavior bug in komeda_plane_add()Zhou Qingyang1-0/+4
In komeda_plane_add(), komeda_get_layer_fourcc_list() is assigned to formats and used in drm_universal_plane_init(). drm_universal_plane_init() passes formats to __drm_universal_plane_init(). __drm_universal_plane_init() further passes formats to memcpy() as src parameter, which could lead to an undefined behavior bug on failure of komeda_get_layer_fourcc_list(). Fix this bug by adding a check of formats. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_DRM_KOMEDA=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: 61f1c4a8ab75 ("drm/komeda: Attach komeda_dev to DRM-KMS") Signed-off-by: Zhou Qingyang <zhou1615@umn.edu> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/dri-devel/20211201033704.32054-1-zhou1615@umn.edu
2022-04-11KVM: x86: hyper-v: Avoid writing to TSC page without an active vCPUVitaly Kuznetsov4-40/+13
The following WARN is triggered from kvm_vm_ioctl_set_clock(): WARNING: CPU: 10 PID: 579353 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:3161 mark_page_dirty_in_slot+0x6c/0x80 [kvm] ... CPU: 10 PID: 579353 Comm: qemu-system-x86 Tainted: G W O 5.16.0.stable #20 Hardware name: LENOVO 20UF001CUS/20UF001CUS, BIOS R1CET65W(1.34 ) 06/17/2021 RIP: 0010:mark_page_dirty_in_slot+0x6c/0x80 [kvm] ... Call Trace: <TASK> ? kvm_write_guest+0x114/0x120 [kvm] kvm_hv_invalidate_tsc_page+0x9e/0xf0 [kvm] kvm_arch_vm_ioctl+0xa26/0xc50 [kvm] ? schedule+0x4e/0xc0 ? __cond_resched+0x1a/0x50 ? futex_wait+0x166/0x250 ? __send_signal+0x1f1/0x3d0 kvm_vm_ioctl+0x747/0xda0 [kvm] ... The WARN was introduced by commit 03c0304a86bc ("KVM: Warn if mark_page_dirty() is called without an active vCPU") but the change seems to be correct (unlike Hyper-V TSC page update mechanism). In fact, there's no real need to actually write to guest memory to invalidate TSC page, this can be done by the first vCPU which goes through kvm_guest_time_update(). Reported-by: Maxim Levitsky <mlevitsk@redhat.com> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20220407201013.963226-1-vkuznets@redhat.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.