I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.
Acked-by: Thoma
> In amdgpu_connector_add_common_modes(), the return value of drm_cvt_mode()
> is assigned to mode, which will lead to a NULL pointer dereference on
> failure of drm_cvt_mode(). Add a check to avoid npd.
>
> Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
> Signed-off-by: Ma Ke
Are you g
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.
Reviewed-by: Ro
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.
Acked-by: Alex
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of the
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the spec
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.
Reviewed-by: Ma
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.
Acked-by: Thoma
In amdgpu_connector_add_common_modes(), the return value of drm_cvt_mode()
is assigned to mode, which will lead to a NULL pointer dereference on
failure of drm_cvt_mode(). Add a check to avoid npd.
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: Ma Ke
---
Changes in v2:
-
Hello,
* Thomas Glanzmann [2024-07-10 07:19]:
> [ 11.902016] amdgpu :0b:00.0: [drm] *ERROR*
> dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
I resolved the issue by updating my firmware:
git clone
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.
Acked-by: Thoma
It leads to race condition if amdgpu_bo is marked as invalid
before it is really moved.
Signed-off-by: YuanShang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/a
Hi Easwar,
On Thu, Jul 11, 2024 at 05:27:31AM +, Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
> with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
> fix the terminology for users of I2C_ALGOBIT bitbanging int
On 04/07/2024 06:22, Vignesh Raman wrote:
Uprev IGT to the latest version, which includes a fix for the
writeback tests issue on MSM devices. Enable debugging for
igt-runner to log output such as 'Begin test' and 'End test'.
This will help identify which test causes system freeze or hangs.
Upd
Am 11.07.24 um 03:31 schrieb Zhu, Jiadong:
[AMD Official Use Only - AMD Internal Distribution Only]
-Original Message-
From: Christian König
Sent: Wednesday, July 10, 2024 8:46 PM
To: Zhu, Jiadong ; amd-gfx@lists.freedesktop.org;
Deucher, Alexander
Subject: Re: [PATCH v2] drm/amdgpu:
[AMD Official Use Only - AMD Internal Distribution Only]
This patch seems to be wrong.
Quite a lot of preparations have been done in amdgpu_bo_move_notify
For example, amdgpu_bo_kunmap() will be called to prevent the BO from being
accessed by CPU. If not called, the CPU may attempt to access the
Am 11.07.24 um 07:37 schrieb jiadong@amd.com:
From: Jiadong Zhu
The job's embedded fence is dma_fence which shall not be conversed
to amdgpu_fence. The start timestamp shall be saved on job for
hw_fence.
Again big NAK to adding the start time to the job.
Regards,
Christian.
v2: optimi
Yeah, completely agree. This patch doesn't really make sense.
Please explain why you would want to do this?
Regards,
Christian.
Am 11.07.24 um 13:56 schrieb Huang, Trigger:
[AMD Official Use Only - AMD Internal Distribution Only]
This patch seems to be wrong.
Quite a lot of preparations have
Increase the KMS minor version to indicate GFX12 DCC support since this
contains a major change in how DCC is managed across IPs like GFX, DCN
etc. This will be used mainly by userspace like Mesa to figure out
DCC support on GFX12 hardware.
Signed-off-by: Aurabindo Pillai
---
drivers/gpu/drm/amd
From: Leo Li
This change caused PSR SU panels to not read from their remote fb,
preventing us from entering self-refresh. It is a regression.
This reverts commit f8ebe6341a6a3745ef02648b4b5c2c89fa4a9ace.
Signed-off-by: Leo Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
1 file
On 7/10/2024 13:03, Thomas Glanzmann wrote:
Hello,
* Thomas Glanzmann [2024-07-10 07:19]:
[ 11.902016] amdgpu :0b:00.0: [drm] *ERROR*
dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
I resolved the issue by updating my firmware:
git clone
https://git.kernel.
On Thu, Jul 11, 2024 at 10:40 AM wrote:
>
> From: Leo Li
>
> This change caused PSR SU panels to not read from their remote fb,
> preventing us from entering self-refresh. It is a regression.
>
> This reverts commit f8ebe6341a6a3745ef02648b4b5c2c89fa4a9ace.
>
> Signed-off-by: Leo Li
Acked-by: A
On Thu, Jul 11, 2024 at 11:05 AM Aurabindo Pillai
wrote:
>
> Increase the KMS minor version to indicate GFX12 DCC support since this
> contains a major change in how DCC is managed across IPs like GFX, DCN
> etc. This will be used mainly by userspace like Mesa to figure out
> DCC support on GFX12
From: Tvrtko Ursulin
>From the department of questionable optimisations today we have a minor
improvement to how padding / filling the rings with nops is done.
Having noticed that typically 200+ nops per submission are filled into the
ring, using a rather verbose one-nop-at-a-time-plus-ring-buff
The camera sensors in the system are connected via the ISP I2C bus.
The ISP I2C bus is another IP block that shares the hardware resources with the
AMDGPU.
Just like the ISP device the ISP I2C bus also can't be enumerated via ACPI
mechanism,
since it's memory map is a subset of the AMDGPU memory
ISP I2C bus device can't be enumerated via ACPI mechanism
since it shares the memory map with the AMDGPU.
So use the MFD mechanism for registering the ISP I2C device
and add the required resources.
Signed-off-by: Venkata Narendra Kumar Gutta
---
drivers/gpu/drm/amd/amdgpu/amdgpu_isp.h | 1 +
dr
Hi Dave, Sima,
Fixes for 6.10.
The following changes since commit 256abd8e550ce977b728be79a74e1729438b4948:
Linux 6.10-rc7 (2024-07-07 14:23:46 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.10-2024-07-11
for you to fetc
[AMD Official Use Only - AMD Internal Distribution Only]
We need to make sure that all BOs of an active kfd process validated. Moving
buffer will trigger process eviction.
If mark it as invalided before process eviction, related kfd process is still
active and may attempt to access this invalida
[AMD Official Use Only - AMD Internal Distribution Only]
BTW, can we consider leveraging psp->mutext to protect both shared memory and
command submission?
Regards,
Hawking
-Original Message-
From: Chai, Thomas
Sent: Friday, June 28, 2024 18:01
To: Zhang, Hawking ; amd-gfx@lists.freedes
28 matches
Mail list logo
