RE: [PATCH 1/2] drm/print: drop include debugfs.h and include where needed
[Public] > -Original Message- > From: Jani Nikula > Sent: Wednesday, April 24, 2024 9:55 AM > To: dri-devel@lists.freedesktop.org > Cc: Andrzej Hajda ; Maxime Ripard > ; Jacek Lawrynowicz > ; Stanislaw Gruszka > ; Oded Gabbay ; > Russell King ; David Airlie ; Daniel > Vetter ; Neil Armstrong ; Robert > Foss ; Laurent Pinchart > ; Jonas Karlman ; > Jernej Skrabec ; Maarten Lankhorst > ; Thomas Zimmermann > ; Rodrigo Vivi ; Joonas > Lahtinen ; Tvrtko Ursulin > ; Frank Binns ; Matt Coster > ; Rob Clark ; Abhinav > Kumar ; Dmitry Baryshkov > ; Sean Paul ; Marijn Suijten > ; Karol Herbst ; Lyude > Paul ; Danilo Krummrich ; Deucher, > Alexander ; Koenig, Christian > ; Pan, Xinhui ; Alain > Volmat ; Huang, Ray ; > Zack Rusin ; Broadcom internal kernel review list > ; Lucas De Marchi > ; Thomas Hellström > ; intel-...@lists.freedesktop.org; intel- > x...@lists.freedesktop.org; linux-arm-...@vger.kernel.org; > freedr...@lists.freedesktop.org; nouv...@lists.freedesktop.org; amd- > g...@lists.freedesktop.org > Subject: Re: [PATCH 1/2] drm/print: drop include debugfs.h and include where > needed > > On Mon, 22 Apr 2024, Jani Nikula wrote: > > Surprisingly many places depend on debugfs.h to be included via > > drm_print.h. Fix them. > > > > v3: Also fix armada, ite-it6505, imagination, msm, sti, vc4, and xe > > > > v2: Also fix ivpu and vmwgfx > > > > Reviewed-by: Andrzej Hajda > > Acked-by: Maxime Ripard > > Link: > > > https://patchwork.freedesktop.org/patch/msgid/20240410141434.157908 > -1- > > jani.nik...@intel.com > > Signed-off-by: Jani Nikula > > While the changes all over the place are small, mostly just adding the > debugfs.h include, please consider acking. I've sent this a few times already. > For radeon: Acked-by: Alex Deucher > Otherwise, I'll merge this by the end of the week, acks or not. > > Thanks, > Jani. > > > > > > > --- > > > > Cc: Jacek Lawrynowicz > > Cc: Stanislaw Gruszka > > Cc: Oded Gabbay > > Cc: Russell King > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Andrzej Hajda > > Cc: Neil Armstrong > > Cc: Robert Foss > > Cc: Laurent Pinchart > > Cc: Jonas Karlman > > Cc: Jernej Skrabec > > Cc: Maarten Lankhorst > > Cc: Maxime Ripard > > Cc: Thomas Zimmermann > > Cc: Jani Nikula > > Cc: Rodrigo Vivi > > Cc: Joonas Lahtinen > > Cc: Tvrtko Ursulin > > Cc: Frank Binns > > Cc: Matt Coster > > Cc: Rob Clark > > Cc: Abhinav Kumar > > Cc: Dmitry Baryshkov > > Cc: Sean Paul > > Cc: Marijn Suijten > > Cc: Karol Herbst > > Cc: Lyude Paul > > Cc: Danilo Krummrich > > Cc: Alex Deucher > > Cc: "Christian König" > > Cc: "Pan, Xinhui" > > Cc: Alain Volmat > > Cc: Huang Rui > > Cc: Zack Rusin > > Cc: Broadcom internal kernel review list > > > > Cc: Lucas De Marchi > > Cc: "Thomas Hellström" > > Cc: dri-devel@lists.freedesktop.org > > Cc: intel-...@lists.freedesktop.org > > Cc: intel...@lists.freedesktop.org > > Cc: linux-arm-...@vger.kernel.org > > Cc: freedr...@lists.freedesktop.org > > Cc: nouv...@lists.freedesktop.org > > Cc: amd-...@lists.freedesktop.org > > --- > > drivers/accel/ivpu/ivpu_debugfs.c | 2 ++ > > drivers/gpu/drm/armada/armada_debugfs.c | 1 + > > drivers/gpu/drm/bridge/ite-it6505.c | 1 + > > drivers/gpu/drm/bridge/panel.c | 2 ++ > > drivers/gpu/drm/drm_print.c | 6 +++--- > > drivers/gpu/drm/i915/display/intel_dmc.c| 1 + > > drivers/gpu/drm/imagination/pvr_fw_trace.c | 1 + > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 2 ++ > > drivers/gpu/drm/nouveau/dispnv50/crc.c | 2 ++ > > drivers/gpu/drm/radeon/r100.c | 1 + > > drivers/gpu/drm/radeon/r300.c | 1 + > > drivers/gpu/drm/radeon/r420.c | 1 + > > drivers/gpu/drm/radeon/r600.c | 3 ++- > > drivers/gpu/drm/radeon/radeon_fence.c | 1 + > > drivers/gpu/drm/radeon/radeon_gem.c | 1 + > > drivers/gpu/drm/radeon/radeon_ib.c | 2 ++ > > drivers/gpu/drm/radeon/radeon_pm.c | 1 + > > drivers/gpu/drm/radeon/radeon_ring.c| 2 ++ > > drivers/gpu/drm/radeon/radeon_ttm.c | 1 + > > drivers/gpu/drm/radeon/rs400.c | 1 + > > drivers/gpu/drm/radeon/rv515.c | 1 + > > drivers/gpu/drm/sti/sti_drv.c | 1 + > > d
RE: [PATCH v2] drm/amdgpu: Clear the hotplug interrupt ack bit before hpd initialization
[Public]
> -Original Message-
> From: Qiang Ma
> Sent: Wednesday, March 13, 2024 2:18 AM
> To: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; SHANMUGAM, SRINIVASAN
> ; sunran...@208suo.com
> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v2] drm/amdgpu: Clear the hotplug interrupt ack bit
> before hpd initialization
>
> On Wed, 31 Jan 2024 15:57:03 +0800
> Qiang Ma wrote:
>
> Hello everyone, please help review this patch.
This was applied back in January, sorry if I forget to reply.
Alex
>
> Qiang Ma
>
> > Problem:
> > The computer in the bios initialization process, unplug the HDMI
> > display, wait until the system up, plug in the HDMI display, did not
> > enter the hotplug interrupt function, the display is not bright.
> >
> > Fix:
> > After the above problem occurs, and the hpd ack interrupt bit is 1,
> > the interrupt should be cleared during hpd_init initialization so that
> > when the driver is ready, it can respond to the hpd interrupt
> > normally.
> >
> > Signed-off-by: Qiang Ma
> > ---
> > v2:
> > - Remove unused variable 'tmp'
> > - Fixed function spelling errors
> >
> > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 ++
> > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 ++
> > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 22 ++---
> -
> > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 22 ++---
> -
> > 4 files changed, 40 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c index
> > bb666cb7522e..12a8ba929a72 100644 ---
> > a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c +++
> > b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c @@ -51,6 +51,7 @@
> >
> > static void dce_v10_0_set_display_funcs(struct amdgpu_device *adev);
> > static void dce_v10_0_set_irq_funcs(struct amdgpu_device *adev);
> > +static void dce_v10_0_hpd_int_ack(struct amdgpu_device *adev, int
> > hpd);
> > static const u32 crtc_offsets[] = {
> > CRTC0_REGISTER_OFFSET,
> > @@ -363,6 +364,7 @@ static void dce_v10_0_hpd_init(struct
> > amdgpu_device *adev) AMDGPU_HPD_DISCONNECT_INT_DELAY_IN_MS);
> > WREG32(mmDC_HPD_TOGGLE_FILT_CNTL +
> > hpd_offsets[amdgpu_connector->hpd.hpd], tmp);
> > + dce_v10_0_hpd_int_ack(adev,
> > amdgpu_connector->hpd.hpd); dce_v10_0_hpd_set_polarity(adev,
> > amdgpu_connector->hpd.hpd); amdgpu_irq_get(adev, >hpd_irq,
> >amdgpu_connector->hpd.hpd); diff --git
> > a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c index
> > 7af277f61cca..745e4fdffade 100644 ---
> > a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c +++
> > b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c @@ -51,6 +51,7 @@
> >
> > static void dce_v11_0_set_display_funcs(struct amdgpu_device *adev);
> > static void dce_v11_0_set_irq_funcs(struct amdgpu_device *adev);
> > +static void dce_v11_0_hpd_int_ack(struct amdgpu_device *adev, int
> > hpd);
> > static const u32 crtc_offsets[] =
> > {
> > @@ -387,6 +388,7 @@ static void dce_v11_0_hpd_init(struct
> > amdgpu_device *adev) AMDGPU_HPD_DISCONNECT_INT_DELAY_IN_MS);
> > WREG32(mmDC_HPD_TOGGLE_FILT_CNTL +
> > hpd_offsets[amdgpu_connector->hpd.hpd], tmp);
> > + dce_v11_0_hpd_int_ack(adev,
> > amdgpu_connector->hpd.hpd); dce_v11_0_hpd_set_polarity(adev,
> > amdgpu_connector->hpd.hpd); amdgpu_irq_get(adev, >hpd_irq,
> > amdgpu_connector->hpd.hpd); } diff --git
> > a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> > b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c index
> > 143efc37a17f..28c4a735716b 100644 ---
> > a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c +++
> > b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c @@ -272,6 +272,21 @@
> static
> > void dce_v6_0_hpd_set_polarity(struct amdgpu_device *adev,
> > WREG32(mmDC_HPD1_INT_CONTROL + hpd_offsets[hpd], tmp); }
> >
> > +static void dce_v6_0_hpd_int_ack(struct amdgpu_device *adev,
> > +int hpd)
> > +{
> > + u32 tmp;
> > +
> > + if (hpd >= adev->mode_info.num_hpd) {
> > + DRM_DEBUG("invalid hdp %d\n", hpd);
> > + return;
> > + }
> > +
> > + tmp = RREG32(mmDC_HPD1_INT_CONTROL + hpd_offsets[hpd]);
> > + tmp |= DC_HPD1_INT_CONTROL__DC_HPD1_INT_ACK_MASK;
> > + WREG32(mmDC_HPD1_INT_CONTROL + hpd_offse
RE: [PATCH] drm/amdgpu: add vm fault information to devcoredump
[Public]
> -Original Message-
> From: Sunil Khatri
> Sent: Wednesday, March 6, 2024 1:20 PM
> To: Deucher, Alexander ; Koenig, Christian
> ; Sharma, Shashank
>
> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> ker...@vger.kernel.org; Joshi, Mukul ; Paneer
> Selvam, Arunpravin ; Khatri, Sunil
>
> Subject: [PATCH] drm/amdgpu: add vm fault information to devcoredump
>
> Add page fault information to the devcoredump.
>
> Output of devcoredump:
> AMDGPU Device Coredump
> version: 1
> kernel: 6.7.0-amd-staging-drm-next
> module: amdgpu
> time: 29.725011811
> process_name: soft_recovery_p PID: 1720
>
> Ring timed out details
> IP Type: 0 Ring Name: gfx_0.0.0
>
> [gfxhub] Page fault observed for GPU family:143 Faulty page starting at
I think we should add a separate section for the GPU identification information
(family, PCI ids, IP versions, etc.). For this patch, I think fine to just
print the fault address and status.
Alex
> address 0x Protection fault status register:0x301031
>
> VRAM is lost due to GPU reset!
>
> Signed-off-by: Sunil Khatri
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 15 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h | 1 +
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c
> index 147100c27c2d..d7fea6cdf2f9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c
> @@ -203,8 +203,20 @@ amdgpu_devcoredump_read(char *buffer, loff_t
> offset, size_t count,
> coredump->ring->name);
> }
>
> + if (coredump->fault_info.status) {
> + struct amdgpu_vm_fault_info *fault_info =
> >fault_info;
> +
> + drm_printf(, "\n[%s] Page fault observed for GPU
> family:%d\n",
> +fault_info->vmhub ? "mmhub" : "gfxhub",
> +coredump->adev->family);
> + drm_printf(, "Faulty page starting at address 0x%016llx\n",
> +fault_info->addr);
> + drm_printf(, "Protection fault status register:0x%x\n",
> +fault_info->status);
> + }
> +
> if (coredump->reset_vram_lost)
> - drm_printf(, "VRAM is lost due to GPU reset!\n");
> + drm_printf(, "\nVRAM is lost due to GPU reset!\n");
> if (coredump->adev->reset_info.num_regs) {
> drm_printf(, "AMDGPU register dumps:\nOffset:
> Value:\n");
>
> @@ -253,6 +265,7 @@ void amdgpu_coredump(struct amdgpu_device
> *adev, bool vram_lost,
> if (job) {
> s_job = >base;
> coredump->ring = to_amdgpu_ring(s_job->sched);
> + coredump->fault_info = job->vm->fault_info;
> }
>
> coredump->adev = adev;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h
> index 60522963aaca..3197955264f9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h
> @@ -98,6 +98,7 @@ struct amdgpu_coredump_info {
> struct timespec64 reset_time;
> boolreset_vram_lost;
> struct amdgpu_ring *ring;
> + struct amdgpu_vm_fault_info fault_info;
> };
> #endif
>
> --
> 2.34.1
RE: [PATCH] drm/amd: Only allow one entity to control ABM
[Public] > -Original Message- > From: amd-gfx On Behalf Of > Christian König > Sent: Tuesday, February 20, 2024 9:10 AM > To: Alex Deucher > Cc: Limonciello, Mario ; Wentland, Harry > ; amd-...@lists.freedesktop.org; dri- > de...@lists.freedesktop.org; Mahfooz, Hamza ; > Li, Sun peng (Leo) > Subject: Re: [PATCH] drm/amd: Only allow one entity to control ABM > > Am 19.02.24 um 16:28 schrieb Alex Deucher: > > On Mon, Feb 19, 2024 at 10:19 AM Christian König > > wrote: > >> Am 16.02.24 um 19:37 schrieb Alex Deucher: > >>> On Fri, Feb 16, 2024 at 10:42 AM Christian König > >>> wrote: > Am 16.02.24 um 16:12 schrieb Mario Limonciello: > > On 2/16/2024 09:05, Harry Wentland wrote: > >> On 2024-02-16 09:47, Christian König wrote: > >>> Am 16.02.24 um 15:42 schrieb Mario Limonciello: > On 2/16/2024 08:38, Christian König wrote: > > Am 16.02.24 um 15:07 schrieb Mario Limonciello: > >> By exporting ABM to sysfs it's possible that DRM master and > >> software controlling the sysfs file fight over the value programmed > for ABM. > >> > >> Adjust the module parameter behavior to control who control > ABM: > >> -2: DRM > >> -1: sysfs (IE via software like power-profiles-daemon) > > Well that sounds extremely awkward. Why should a > > power-profiles-deamon has control over the panel power saving > > features? > > > > I mean we are talking about things like reducing backlight > > level when the is inactivity, don't we? > We're talking about activating the ABM algorithm when the > system is in power saving mode; not from inactivity. This > allows the user to squeeze out some extra power "just" in that > situation. > > But given the comments on the other patch, I tend to agree with > Harry's proposal instead that we just drop the DRM property > entirely as there are no consumers of it. > >>> Yeah, but even then the design to let this be controlled by an > >>> userspace deamon is questionable. Stuff like that is handled > >>> inside the kernel and not exposed to userspace usually. > >>> > > Regarding the "how" and "why" of PPD; besides this panel power > > savings sysfs file there are two other things that are nominally > > changed. > > > > ACPI platform profile: > > https://www.kernel.org/doc/html/latest/userspace-api/sysfs-platfor > > m_profile.html > > > > AMD-Pstate EPP value: > > https://www.kernel.org/doc/html//latest/admin-guide/pm/amd- > pstate. > > html > > > > When a user goes into "power saving" mode both of those are tweaked. > > Before we introduced the EPP tweaking in PPD we did discuss a > > callback within the kernel so that userspace could change "just" > > the ACPI platform profile and everything else would react. There > > was pushback on this, and so instead knobs are offered for things > > that should be tweaked and the userspace daemon can set up policy > > for what to do when a a user uses a userspace client (such as > > GNOME or KDE) to change the desired system profile. > Ok, well who came up with the idea of the userspace deamon? Cause I > think there will be even more push back on this approach. > > Basically when we go from AC to battery (or whatever) the drivers > usually handle that all inside the kernel today. Involving > userspace is only done when there is a need for that, e.g. > inactivity detection or similar. > >>> Well, we don't want policy in the kernel unless it's a platform or > >>> hardware requirement. Kernel should provide the knobs and then > >>> userspace can set them however they want depending on user preference. > >> Well, you not have the policy itself but usually the handling inside > >> the kernel. > >> > >> In other words when I connect/disconnect AC from my laptop I can hear > >> the fan changing, which is a switch in power state. Only the beep > >> which comes out of the speakers as conformation is handled in userspace I > think. > >> > >> And IIRC changing background light is also handled completely inside > >> the kernel and when I close the lid the display turns off on its own > >> and not because of some userspace deamon. > >> > >> So why is for this suddenly a userspace deamon involved? > > It's a user preference. Some people won't like ABM, some will. They > > set the policy from user space. It's similar to the backlight level. > > Some users always prefer a bright backlight regardless of AC/DC state, > > others want the backlight to get brighter when on AC power. The > > kernel provides the knobs to set the ABM level and then user space can > > specify the level and also device when they want it enabled (never, > > only on DC, etc.). The kernel driver for the backlight doesn't change > > the backlight at AC/DC switch,
RE: [PATCH 1/3] drm/radeon: Use RMW accessors for changing LNKCTL2
[Public] > -Original Message- > From: Ilpo Järvinen > Sent: Thursday, February 15, 2024 8:32 AM > To: Deucher, Alexander ; amd- > g...@lists.freedesktop.org; Daniel Vetter ; David Airlie > ; Dennis Dalessandro > ; dri- > de...@lists.freedesktop.org; Jason Gunthorpe ; Leon > Romanovsky ; linux-ker...@vger.kernel.org; linux- > r...@vger.kernel.org; Pan, Xinhui ; Koenig, Christian > > Cc: Ilpo Järvinen ; Lukas Wunner > > Subject: [PATCH 1/3] drm/radeon: Use RMW accessors for changing LNKCTL2 > > Convert open coded RMW accesses for LNKCTL2 to use > pcie_capability_clear_and_set_word() which makes its easier to understand > what the code tries to do. > > LNKCTL2 is not really owned by any driver because it is a collection of > control > bits that PCI core might need to touch. RMW accessors already have support > for proper locking for a selected set of registers > (LNKCTL2 is not yet among them but likely will be in the future) to avoid > losing > concurrent updates. > > Suggested-by: Lukas Wunner > Signed-off-by: Ilpo Järvinen The radeon and amdgpu patches are: Acked-by: Alex Deucher Are you looking for me to pick them up or do you want to land them as part of some larger change? Either way is fine with me. Alex > --- > drivers/gpu/drm/radeon/cik.c | 40 ++-- > drivers/gpu/drm/radeon/si.c | 40 ++-- > 2 files changed, 30 insertions(+), 50 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c > index 10be30366c2b..b5e96a8fc2c1 100644 > --- a/drivers/gpu/drm/radeon/cik.c > +++ b/drivers/gpu/drm/radeon/cik.c > @@ -9592,28 +9592,18 @@ static void cik_pcie_gen3_enable(struct > radeon_device *rdev) > > PCI_EXP_LNKCTL_HAWD); > > /* linkctl2 */ > - pcie_capability_read_word(root, > PCI_EXP_LNKCTL2, > - ); > - tmp16 &= ~(PCI_EXP_LNKCTL2_ENTER_COMP > | > -PCI_EXP_LNKCTL2_TX_MARGIN); > - tmp16 |= (bridge_cfg2 & > - (PCI_EXP_LNKCTL2_ENTER_COMP | > -PCI_EXP_LNKCTL2_TX_MARGIN)); > - pcie_capability_write_word(root, > -PCI_EXP_LNKCTL2, > -tmp16); > - > - pcie_capability_read_word(rdev->pdev, > - PCI_EXP_LNKCTL2, > - ); > - tmp16 &= ~(PCI_EXP_LNKCTL2_ENTER_COMP > | > -PCI_EXP_LNKCTL2_TX_MARGIN); > - tmp16 |= (gpu_cfg2 & > - (PCI_EXP_LNKCTL2_ENTER_COMP | > -PCI_EXP_LNKCTL2_TX_MARGIN)); > - pcie_capability_write_word(rdev->pdev, > -PCI_EXP_LNKCTL2, > -tmp16); > + pcie_capability_clear_and_set_word(root, > PCI_EXP_LNKCTL2, > + > PCI_EXP_LNKCTL2_ENTER_COMP | > + > PCI_EXP_LNKCTL2_TX_MARGIN, > +bridge_cfg2 > | > + > (PCI_EXP_LNKCTL2_ENTER_COMP | > + > PCI_EXP_LNKCTL2_TX_MARGIN)); > + pcie_capability_clear_and_set_word(rdev- > >pdev, PCI_EXP_LNKCTL2, > + > PCI_EXP_LNKCTL2_ENTER_COMP | > + > PCI_EXP_LNKCTL2_TX_MARGIN, > +gpu_cfg2 | > + > (PCI_EXP_LNKCTL2_ENTER_COMP | > + > PCI_EXP_LNKCTL2_TX_MARGIN)); > > tmp = RREG32_PCIE_PORT(PCIE_LC_CNTL4); > tmp &= ~LC_SET_QUIESCE; > @@ -9627,15 +9617,15 @@ static void cik_pcie_gen3_enable(struct > radeon_device *rdev) > speed_cntl &= ~LC_FORCE_DIS_SW_SPEED_CHANGE; > WREG32_PCIE_PORT(PCIE_LC_SPEED_CNTL, speed_cntl); > > - pcie_capability_read_word(rdev->pdev, PCI_EXP_LNKCTL2, ); > - tmp16 &= ~PCI_EXP_LNKCTL2_TLS; > + tmp16 = 0; > if (speed_cap == PCIE_SPEED_8_0GT) > tmp16 |= PCI_EXP_LNKCTL2_TLS_8_0GT; /* gen3 */ > else if (speed_cap == PCIE_SPEED_5_0GT) > tmp16 |= PCI_EXP_LNKCTL2_TLS_5_0GT; /* gen2 */ > else > tmp16 |= PCI_EXP_LNK
RE: [PATCH] drm/amdgpu: Clear the hotplug interrupt ack bit before hpd initialization
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of Qiang
> Ma
> Sent: Tuesday, January 30, 2024 4:35 AM
> To: lexander.deuc...@amd.com; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; sunran...@208suo.com;
> SHANMUGAM, SRINIVASAN
> Cc: Qiang Ma ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] drm/amdgpu: Clear the hotplug interrupt ack bit before hpd
> initialization
>
> Problem:
> The computer in the bios initialization process, unplug the HDMI display, wait
> until the system up, plug in the HDMI display, did not enter the hotplug
> interrupt function, the display is not bright.
>
> Fix:
> After the above problem occurs, and the hpd ack interrupt bit is 1, the
> interrupt should be cleared during hpd_init initialization so that when the
> driver is ready, it can respond to the hpd interrupt normally.
>
> Signed-off-by: Qiang Ma
> ---
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 ++
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 ++
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 20 +---
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 20 +---
> 4 files changed, 38 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index bb666cb7522e..11859059fd10 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -51,6 +51,7 @@
>
> static void dce_v10_0_set_display_funcs(struct amdgpu_device *adev);
> static void dce_v10_0_set_irq_funcs(struct amdgpu_device *adev);
> +static void dce_v10_0_hpd_int_ack(struct amdgpu_device *adev, int hpd);
>
> static const u32 crtc_offsets[] = {
> CRTC0_REGISTER_OFFSET,
> @@ -363,6 +364,7 @@ static void dce_v10_0_hpd_init(struct
> amdgpu_device *adev)
>
> AMDGPU_HPD_DISCONNECT_INT_DELAY_IN_MS);
> WREG32(mmDC_HPD_TOGGLE_FILT_CNTL +
> hpd_offsets[amdgpu_connector->hpd.hpd], tmp);
>
> + dce_v6_0_hpd_int_ack(adev, amdgpu_connector->hpd.hpd);
Should be dce_v10_0_hpd_int_ack().
> dce_v10_0_hpd_set_polarity(adev, amdgpu_connector-
> >hpd.hpd);
> amdgpu_irq_get(adev, >hpd_irq,
> amdgpu_connector->hpd.hpd);
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index 7af277f61cca..745e4fdffade 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -51,6 +51,7 @@
>
> static void dce_v11_0_set_display_funcs(struct amdgpu_device *adev);
> static void dce_v11_0_set_irq_funcs(struct amdgpu_device *adev);
> +static void dce_v11_0_hpd_int_ack(struct amdgpu_device *adev, int hpd);
>
> static const u32 crtc_offsets[] =
> {
> @@ -387,6 +388,7 @@ static void dce_v11_0_hpd_init(struct
> amdgpu_device *adev)
>
> AMDGPU_HPD_DISCONNECT_INT_DELAY_IN_MS);
> WREG32(mmDC_HPD_TOGGLE_FILT_CNTL +
> hpd_offsets[amdgpu_connector->hpd.hpd], tmp);
>
> + dce_v11_0_hpd_int_ack(adev, amdgpu_connector-
> >hpd.hpd);
> dce_v11_0_hpd_set_polarity(adev, amdgpu_connector-
> >hpd.hpd);
> amdgpu_irq_get(adev, >hpd_irq, amdgpu_connector-
> >hpd.hpd);
> }
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> index 143efc37a17f..f8e15ebf74b4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> @@ -272,6 +272,21 @@ static void dce_v6_0_hpd_set_polarity(struct
> amdgpu_device *adev,
> WREG32(mmDC_HPD1_INT_CONTROL + hpd_offsets[hpd], tmp); }
>
> +static void dce_v6_0_hpd_int_ack(struct amdgpu_device *adev,
> + int hpd)
> +{
> + u32 tmp;
> +
> + if (hpd >= adev->mode_info.num_hpd) {
> + DRM_DEBUG("invalid hdp %d\n", hpd);
> + return;
> + }
> +
> + tmp = RREG32(mmDC_HPD1_INT_CONTROL + hpd_offsets[hpd]);
> + tmp |= DC_HPD1_INT_CONTROL__DC_HPD1_INT_ACK_MASK;
> + WREG32(mmDC_HPD1_INT_CONTROL + hpd_offsets[hpd], tmp); }
> +
> /**
> * dce_v6_0_hpd_init - hpd setup callback.
> *
> @@ -311,6 +326,7 @@ static void dce_v6_0_hpd_init(struct amdgpu_device
> *adev)
> continue;
> }
>
> + dce_v6_0_hpd_int_ack(adev, amdgpu_connector->hpd.hpd);
> dce_v6_0_hpd_set_polarity(adev, amdgpu_connector-
> >hpd.hpd);
> amdgpu_irq_get(adev, >hpd_irq, amdgpu_connector-
> >hpd.hpd);
> }
> @@ -3101,9 +3117,7 @@ static int dce_v6_0_hpd_irq(struct amdgpu_device
> *adev,
> mask = interrupt_status_offsets[hpd].hpd;
>
> if (disp_int & mask) {
> - tmp = RREG32(mmDC_HPD1_INT_CONTROL +
> hpd_offsets[hpd]);
> - tmp |=
> DC_HPD1_INT_CONTROL__DC_HPD1_INT_ACK_MASK;
> - WREG32(mmDC_HPD1_INT_CONTROL + hpd_offsets[hpd],
> tmp);
> +
RE: [PATCH] drm/amd/display: fix documentation for dm_crtc_additional_color_mgmt()
[Public] > -Original Message- > From: Melissa Wen > Sent: Thursday, December 14, 2023 2:45 PM > To: Wentland, Harry ; Li, Sun peng (Leo) > ; Siqueira, Rodrigo ; > Deucher, Alexander ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch > Cc: kernel test robot ; amd-...@lists.freedesktop.org; dri- > de...@lists.freedesktop.org; kernel-...@igalia.com > Subject: [PATCH] drm/amd/display: fix documentation for > dm_crtc_additional_color_mgmt() > > warning: expecting prototype for drm_crtc_additional_color_mgmt(). > Prototype was for dm_crtc_additional_color_mgmt() instead > > Reported-by: kernel test robot > Closes: https://lore.kernel.org/oe-kbuild-all/202312141801.o9eBCxt9- > l...@intel.com/ > Signed-off-by: Melissa Wen Applied. Thanks! Alex > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c > index 8b3aa674741d..4439e5a27362 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c > @@ -292,7 +292,7 @@ static int amdgpu_dm_crtc_late_register(struct > drm_crtc *crtc) > > #ifdef AMD_PRIVATE_COLOR > /** > - * drm_crtc_additional_color_mgmt - enable additional color properties > + * dm_crtc_additional_color_mgmt - enable additional color properties > * @crtc: DRM CRTC > * > * This function lets the driver enable post-blending CRTC regamma transfer > -- > 2.42.0
RE: [PATCH 1/6] Revert "drm/prime: Unexport helpers for fd/handle conversion"
[AMD Official Use Only - General]
> -Original Message-
> From: Kuehling, Felix
> Sent: Friday, December 1, 2023 6:40 PM
> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Deucher,
> Alexander
> Cc: Daniel Vetter ; Koenig, Christian
> ; Thomas Zimmermann
>
> Subject: Re: [PATCH 1/6] Revert "drm/prime: Unexport helpers for fd/handle
> conversion"
>
> Hi Alex,
>
> I'm about to push patches 1-3 to the rebased amd-staging-drm-next. It would
> be good to get patch 1 into drm-fixes so that Linux 6.6 will be the only
> kernel
> without these prime helpers. That would minimize the hassle for DKMS driver
> installations on future distros.
Already done:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0514f63cfff38a0dcb7ba9c5f245827edc0c5107
Alex
>
> Thanks,
>Felix
>
>
> On 2023-12-01 18:34, Felix Kuehling wrote:
> > This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.
> >
> > These helper functions are needed for KFD to export and import DMABufs
> > the right way without duplicating the tracking of DMABufs associated
> > with GEM objects while ensuring that move notifier callbacks are
> > working as intended.
> >
> > Acked-by: Christian König
> > Acked-by: Thomas Zimmermann
> > Acked-by: Daniel Vetter
> > Signed-off-by: Felix Kuehling
> > ---
> > drivers/gpu/drm/drm_prime.c | 33 ++---
> > include/drm/drm_prime.h | 7 +++
> > 2 files changed, 25 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > index 63b709a67471..834a5e28abbe 100644
> > --- a/drivers/gpu/drm/drm_prime.c
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -278,7 +278,7 @@ void drm_gem_dmabuf_release(struct dma_buf
> *dma_buf)
> > }
> > EXPORT_SYMBOL(drm_gem_dmabuf_release);
> >
> > -/*
> > +/**
> >* drm_gem_prime_fd_to_handle - PRIME import function for GEM drivers
> >* @dev: drm_device to import into
> >* @file_priv: drm file-private structure @@ -292,9 +292,9 @@
> > EXPORT_SYMBOL(drm_gem_dmabuf_release);
> >*
> >* Returns 0 on success or a negative error code on failure.
> >*/
> > -static int drm_gem_prime_fd_to_handle(struct drm_device *dev,
> > - struct drm_file *file_priv, int prime_fd,
> > - uint32_t *handle)
> > +int drm_gem_prime_fd_to_handle(struct drm_device *dev,
> > + struct drm_file *file_priv, int prime_fd,
> > + uint32_t *handle)
> > {
> > struct dma_buf *dma_buf;
> > struct drm_gem_object *obj;
> > @@ -360,6 +360,7 @@ static int drm_gem_prime_fd_to_handle(struct
> drm_device *dev,
> > dma_buf_put(dma_buf);
> > return ret;
> > }
> > +EXPORT_SYMBOL(drm_gem_prime_fd_to_handle);
> >
> > int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
> > struct drm_file *file_priv)
> > @@ -408,7 +409,7 @@ static struct dma_buf
> *export_and_register_object(struct drm_device *dev,
> > return dmabuf;
> > }
> >
> > -/*
> > +/**
> >* drm_gem_prime_handle_to_fd - PRIME export function for GEM drivers
> >* @dev: dev to export the buffer from
> >* @file_priv: drm file-private structure @@ -421,10 +422,10 @@
> > static struct dma_buf *export_and_register_object(struct drm_device *dev,
> >* The actual exporting from GEM object to a dma-buf is done through the
> >* _gem_object_funcs.export callback.
> >*/
> > -static int drm_gem_prime_handle_to_fd(struct drm_device *dev,
> > - struct drm_file *file_priv, uint32_t
> > handle,
> > - uint32_t flags,
> > - int *prime_fd)
> > +int drm_gem_prime_handle_to_fd(struct drm_device *dev,
> > + struct drm_file *file_priv, uint32_t handle,
> > + uint32_t flags,
> > + int *prime_fd)
> > {
> > struct drm_gem_object *obj;
> > int ret = 0;
> > @@ -506,6 +507,7 @@ static int drm_gem_prime_handle_to_fd(struct
> > drm_device *dev,
> >
> > return ret;
> > }
> > +EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
> >
> > int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, void *data,
> > struct drm_file *file_priv)
>
RE: [PATCH] drm/radeon: replace 1-element arrays with flexible-array members
[Public] > -Original Message- > From: José Pekkarinen > Sent: Friday, October 27, 2023 12:59 PM > To: Deucher, Alexander ; Koenig, Christian > ; Pan, Xinhui ; > sk...@linuxfoundation.org > Cc: José Pekkarinen ; airl...@gmail.com; > dan...@ffwll.ch; amd-...@lists.freedesktop.org; dri- > de...@lists.freedesktop.org; linux-ker...@vger.kernel.org; linux-kernel- > ment...@lists.linuxfoundation.org > Subject: [PATCH] drm/radeon: replace 1-element arrays with flexible-array > members > > Reported by coccinelle, the following patch will move the following 1 element > arrays to flexible arrays. > > drivers/gpu/drm/radeon/atombios.h:5523:32-48: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:5545:32-48: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:5461:34-44: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:4447:30-40: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:4236:30-41: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:7044:24-37: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:7054:24-37: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:7095:28-45: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:7553:8-17: WARNING use flexible-array > member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:7559:8-17: WARNING use flexible-array > member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:3896:27-37: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:5443:16-25: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:5454:34-43: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:4603:21-32: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:6299:32-44: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:4628:32-46: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:6285:29-39: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:4296:30-36: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:4756:28-36: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:4064:22-35: WARNING use flexible- > array member instead > (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero- > length-and-one-element-arrays) > drivers/gpu/drm/radeon/atombios.h:7327:9-24: WARNING use flexible-array > member instead > (https://www.kernel.org/doc/html/latest/proces
RE: [PATCH 13/15] platform/x86/amd/pmf: Add PMF-AMDGPU set interface
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of
> Shyam Sundar S K
> Sent: Friday, September 22, 2023 1:51 PM
> To: hdego...@redhat.com; markgr...@kernel.org; Natikar, Basavaraj
> ; ji...@kernel.org;
> benjamin.tissoi...@redhat.com; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch
> Cc: S-k, Shyam-sundar ; amd-
> g...@lists.freedesktop.org; platform-driver-...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; Patil Rajesh ; linux-
> in...@vger.kernel.org; Limonciello, Mario
> Subject: [PATCH 13/15] platform/x86/amd/pmf: Add PMF-AMDGPU set
> interface
>
> For the Smart PC Solution to fully work, it has to enact to the actions coming
> from TA. Add the initial code path for set interface to AMDGPU.
This seems to be limited to backlight at this point. What does setting or not
setting the backlight level mean for the system when this framework is in
place? What if a user manually changes the backlight level? Additional
comments below.
>
> Co-developed-by: Mario Limonciello
> Signed-off-by: Mario Limonciello
> Signed-off-by: Shyam Sundar S K
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c | 21
> +
> drivers/platform/x86/amd/pmf/pmf.h | 2 ++
> drivers/platform/x86/amd/pmf/tee-if.c | 19 +--
> include/linux/amd-pmf-io.h | 1 +
> 4 files changed, 41 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c
> index 232d11833ddc..5c567bff0548 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c
> @@ -68,3 +68,24 @@ int amd_pmf_get_gfx_data(struct amd_gpu_pmf_data
> *pmf)
> return 0;
> }
> EXPORT_SYMBOL_GPL(amd_pmf_get_gfx_data);
> +
> +int amd_pmf_set_gfx_data(struct amd_gpu_pmf_data *pmf) {
> + struct drm_device *drm_dev = pci_get_drvdata(pmf->gpu_dev);
> + struct amdgpu_device *adev = drm_to_adev(drm_dev);
> + struct backlight_device *bd;
> +
> + if (!(adev->flags & AMD_IS_APU)) {
> + DRM_ERROR("PMF-AMDGPU interface not supported\n");
> + return -ENODEV;
> + }
> +
> + bd = backlight_device_get_by_type(BACKLIGHT_RAW);
> + if (!bd)
> + return -ENODEV;
> +
> + backlight_device_set_brightness(bd, pmf->brightness);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(amd_pmf_set_gfx_data);
> diff --git a/drivers/platform/x86/amd/pmf/pmf.h
> b/drivers/platform/x86/amd/pmf/pmf.h
> index 9032df4ba48a..ce89cc0daa5a 100644
> --- a/drivers/platform/x86/amd/pmf/pmf.h
> +++ b/drivers/platform/x86/amd/pmf/pmf.h
> @@ -73,6 +73,7 @@
> #define PMF_POLICY_STT_SKINTEMP_APU 7
> #define PMF_POLICY_STT_SKINTEMP_HS2 8
> #define PMF_POLICY_SYSTEM_STATE 9
> +#define PMF_POLICY_DISPLAY_BRIGHTNESS12
> #define PMF_POLICY_P3T 38
>
> /* TA macros */
> @@ -480,6 +481,7 @@ enum ta_pmf_error_type { };
>
> struct pmf_action_table {
> + unsigned long display_brightness;
> enum system_state system_state;
> unsigned long spl; /* in mW */
> unsigned long sppt; /* in mW */
> diff --git a/drivers/platform/x86/amd/pmf/tee-if.c
> b/drivers/platform/x86/amd/pmf/tee-if.c
> index 1608996654e8..eef83a4c 100644
> --- a/drivers/platform/x86/amd/pmf/tee-if.c
> +++ b/drivers/platform/x86/amd/pmf/tee-if.c
> @@ -79,10 +79,10 @@ static int amd_pmf_update_uevents(struct
> amd_pmf_dev *dev, u16 event)
> return 0;
> }
>
> -static void amd_pmf_apply_policies(struct amd_pmf_dev *dev, struct
> ta_pmf_enact_result *out)
> +static int amd_pmf_apply_policies(struct amd_pmf_dev *dev, struct
> +ta_pmf_enact_result *out)
> {
> u32 val, event = 0;
> - int idx;
> + int idx, ret;
>
> for (idx = 0; idx < out->actions_count; idx++) {
> val = out->actions_list[idx].value;
> @@ -160,8 +160,23 @@ static void amd_pmf_apply_policies(struct
> amd_pmf_dev *dev, struct ta_pmf_enact_
> dev->prev_data->system_state = 0;
> }
> break;
> +
> + case PMF_POLICY_DISPLAY_BRIGHTNESS:
> + ret = amd_pmf_get_gfx_data(>gfx_data);
> + if (ret)
> + return ret;
> +
> + dev->prev_data->display_brightness = dev-
> >gfx_data.brightness;
Are we using standardized
RE: [RFT PATCH v2 07/12] drm/amdgpu: Call drm_atomic_helper_shutdown() at shutdown time
[Public]
> -Original Message-
> From: Douglas Anderson
> Sent: Thursday, September 21, 2023 3:27 PM
> To: dri-devel@lists.freedesktop.org; Maxime Ripard
> Cc: Douglas Anderson ; Zhang, Bokun
> ; Zhang, Hawking ;
> Zhu, James ; Zhao, Victor ;
> Pan, Xinhui ; airl...@gmail.com; Deucher, Alexander
> ; amd-...@lists.freedesktop.org; Koenig,
> Christian ; dan...@ffwll.ch; Kuehling, Felix
> ; jim.cro...@gmail.com; Ma, Le
> ; Lazar, Lijo ; linux-
> ker...@vger.kernel.org; maarten.lankho...@linux.intel.com; Limonciello,
> Mario ; mdaen...@redhat.com; Zhang,
> Morris ; SHANMUGAM, SRINIVASAN
> ; tzimmerm...@suse.de
> Subject: [RFT PATCH v2 07/12] drm/amdgpu: Call
> drm_atomic_helper_shutdown() at shutdown time
>
> Based on grepping through the source code this driver appears to be missing a
> call to drm_atomic_helper_shutdown() at system shutdown time. Among
> other things, this means that if a panel is in use that it won't be cleanly
> powered off at system shutdown time.
>
> The fact that we should call drm_atomic_helper_shutdown() in the case of OS
> shutdown/restart comes straight out of the kernel doc "driver instance
> overview" in drm_drv.c.
>
> Suggested-by: Maxime Ripard
> Signed-off-by: Douglas Anderson
> ---
> This commit is only compile-time tested.
>
> ...and further, I'd say that this patch is more of a plea for help than a
> patch I
> think is actually right. I'm _fairly_ certain that drm/amdgpu needs this call
> at
> shutdown time but the logic is a bit hard for me to follow. I'd appreciate if
> anyone who actually knows what this should look like could illuminate me, or
> perhaps even just post a patch themselves!
>
> (no changes since v1)
>
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 2 ++
> 3 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 8f2255b3a38a..cfcff0b37466 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1104,6 +1104,7 @@ static inline struct amdgpu_device
> *amdgpu_ttm_adev(struct ttm_device *bdev) int amdgpu_device_init(struct
> amdgpu_device *adev,
> uint32_t flags);
> void amdgpu_device_fini_hw(struct amdgpu_device *adev);
> +void amdgpu_device_shutdown_hw(struct amdgpu_device *adev);
> void amdgpu_device_fini_sw(struct amdgpu_device *adev);
>
> int amdgpu_gpu_wait_for_idle(struct amdgpu_device *adev); diff --git
> a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index a2cdde0ca0a7..fa5925c2092d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -4247,6 +4247,16 @@ void amdgpu_device_fini_hw(struct
> amdgpu_device *adev)
>
> }
>
> +void amdgpu_device_shutdown_hw(struct amdgpu_device *adev) {
This needs a better name since its only for displays. Also maybe move it into
amdgpu_display.c since it's really about turning off the displays. That said
is this really even needed? The driver already calls its suspend functionality
to turn off all of the hardware and put it into a quiescent state before
shutdown. Basically shares the same code we use for suspend.
> + if (adev->mode_info.mode_config_initialized) {
> + if (!drm_drv_uses_atomic_modeset(adev_to_drm(adev)))
> + drm_helper_force_disable_all(adev_to_drm(adev));
> + else
> + drm_atomic_helper_shutdown(adev_to_drm(adev));
> + }
> +}
> +
> void amdgpu_device_fini_sw(struct amdgpu_device *adev) {
> int idx;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index e90f730eb715..3a7cbff111d1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -2333,6 +2333,8 @@ amdgpu_pci_shutdown(struct pci_dev *pdev)
> struct drm_device *dev = pci_get_drvdata(pdev);
> struct amdgpu_device *adev = drm_to_adev(dev);
>
> + amdgpu_device_shutdown_hw(adev);
I would move this after the ras_intr check below.
Alex
> +
> if (amdgpu_ras_intr_triggered())
> return;
>
> --
> 2.42.0.515.g380fc7ccd1-goog
RE: [RFT PATCH v2 11/12] drm/radeon: Call drm_helper_force_disable_all() at shutdown/remove time
[Public]
> -Original Message-
> From: Douglas Anderson
> Sent: Thursday, September 21, 2023 3:27 PM
> To: dri-devel@lists.freedesktop.org; Maxime Ripard
> Cc: Douglas Anderson ; Pan, Xinhui
> ; airl...@gmail.com; Deucher, Alexander
> ; amd-...@lists.freedesktop.org; Koenig,
> Christian ; dan...@ffwll.ch; linux-
> ker...@vger.kernel.org
> Subject: [RFT PATCH v2 11/12] drm/radeon: Call
> drm_helper_force_disable_all() at shutdown/remove time
>
> Based on grepping through the source code, this driver appears to be missing
> a call to drm_atomic_helper_shutdown(), or in this case the non-atomic
> equivalent drm_helper_force_disable_all(), at system shutdown time and at
> driver remove time. This is important because
> drm_helper_force_disable_all() will cause panels to get disabled cleanly which
> may be important for their power sequencing. Future changes will remove any
> custom powering off in individual panel drivers so the DRM drivers need to
> start getting this right.
>
> The fact that we should call drm_atomic_helper_shutdown(), or in this case
> the non-atomic equivalent drm_helper_force_disable_all(), in the case of OS
> shutdown/restart comes straight out of the kernel doc "driver instance
> overview" in drm_drv.c.
>
> NOTE: in order to get things inserted in the right place, I had to replace the
> old/deprecated drm_put_dev() function with the equivalent new calls.
>
> Suggested-by: Maxime Ripard
> Reviewed-by: Maxime Ripard
> Signed-off-by: Douglas Anderson
> ---
> I honestly have no idea if I got this patch right. The shutdown() function
> already had some special case logic for PPC, Loongson, and VMs and I don't
> 100% for sure know how this interacts with those. Everything here is just
> compile tested.
I think the reason for most of this funniness is to reduce shutdown time. Lots
of users complain if driver takes a while to shutdown and there is a point to
be made that if the system is going into power down, there is not much reason
to spend a lot of time messing with the hardware.
Alex
>
> (no changes since v1)
>
> drivers/gpu/drm/radeon/radeon_drv.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 39cdede460b5..67995ea24852 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -38,6 +38,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> @@ -357,7 +358,9 @@ radeon_pci_remove(struct pci_dev *pdev) {
> struct drm_device *dev = pci_get_drvdata(pdev);
>
> - drm_put_dev(dev);
> + drm_dev_unregister(dev);
> + drm_helper_force_disable_all(dev);
> + drm_dev_put(dev);
> }
>
> static void
> @@ -368,6 +371,8 @@ radeon_pci_shutdown(struct pci_dev *pdev)
>*/
> if (radeon_device_is_virtual())
> radeon_pci_remove(pdev);
> + else
> + drm_helper_force_disable_all(pci_get_drvdata(pdev));
>
> #if defined(CONFIG_PPC64) || defined(CONFIG_MACH_LOONGSON64)
> /*
> --
> 2.42.0.515.g380fc7ccd1-goog
RE: WARNING in amdgpu_sync_keep_later / dma_fence_is_later should be rate limited
[Public]
> -Original Message-
> From: Rafał Miłecki
> Sent: Thursday, September 21, 2023 3:41 PM
> To: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ; amd-
> g...@lists.freedesktop.org; dri-devel ; Yu,
> Lang
> Subject: WARNING in amdgpu_sync_keep_later / dma_fence_is_later should
> be rate limited
>
> Hi,
>
> backporting commit 187916e6ed9d ("drm/amdgpu: install stub fence into
> potential unused fence pointers") to stable kernels resulted in lots of
> WARNINGs on some devices. In my case I was getting 3 WARNINGs per
> second (~150 lines logged every second). Commit ended up being reverted for
> stable but it exposed a potential problem. My messages log size was reaching
> gigabytes and was running my /tmp/ out of space.
>
> Could someone take a look at amdgpu_sync_keep_later / dma_fence_is_later
> and make sure its logging is rate limited to avoid such situations in the
> future,
> please?
>
> Revert in linux-5.15.x:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=li
> nux-5.15.y=fae2d591f3cb31f722c7f065acf586830eab8c2a
>
> openSUSE bug report:
> https://bugzilla.opensuse.org/show_bug.cgi?id=1215523
These patches were never intended for stable. They were picked up by Sasha's
stable autoselect tools and automatically applied to stable kernels.
Alex
RE: [PATCH] drm/amd/pm: Replace 1-element arrays with flexible array members
[Public]
> -Original Message-
> From: Samuel Holland
> Sent: Wednesday, August 30, 2023 2:58 PM
> To: Quan, Evan ; Deucher, Alexander
> ; Koenig, Christian
>
> Cc: Samuel Holland ; Daniel Vetter
> ; David Airlie ; Pan, Xinhui
> ; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] drm/amd/pm: Replace 1-element arrays with flexible array
> members
>
> Since commit df8fc4e934c1 ("kbuild: Enable -fstrict-flex-arrays=3"),
> UBSAN_BOUNDS no longer pretends 1-element arrays are unbounded. The
> bounds check is tripped in smu7_get_pp_table_entry_callback_func_v1(),
> while reading from mclk_dep_table.
>
> For consistency, fix all affected struct definitions in this file.
>
> Signed-off-by: Samuel Holland
+ Gustavo
Please make sure any code that uses these structures properly deals with the
change in structure size.
Alex
> ---
>
> .../drm/amd/pm/powerplay/hwmgr/pptable_v1_0.h | 20 +
> --
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pptable_v1_0.h
> b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pptable_v1_0.h
> index b0ac4d121adc..fb5e935ef786 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pptable_v1_0.h
> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pptable_v1_0.h
> @@ -164,7 +164,7 @@ typedef struct _ATOM_Tonga_State { typedef struct
> _ATOM_Tonga_State_Array {
> UCHAR ucRevId;
> UCHAR ucNumEntries; /* Number of entries. */
> - ATOM_Tonga_State entries[1];/* Dynamically allocate entries. */
> + ATOM_Tonga_State entries[]; /* Dynamically allocate entries. */
> } ATOM_Tonga_State_Array;
>
> typedef struct _ATOM_Tonga_MCLK_Dependency_Record { @@ -179,7
> +179,7 @@ typedef struct _ATOM_Tonga_MCLK_Dependency_Record {
> typedef struct _ATOM_Tonga_MCLK_Dependency_Table {
> UCHAR ucRevId;
> UCHAR ucNumEntries;
> /* Number of entries. */
> - ATOM_Tonga_MCLK_Dependency_Record entries[1];
> /* Dynamically allocate entries. */
> + ATOM_Tonga_MCLK_Dependency_Record entries[];
> /* Dynamically allocate entries. */
> } ATOM_Tonga_MCLK_Dependency_Table;
>
> typedef struct _ATOM_Tonga_SCLK_Dependency_Record { @@ -194,7
> +194,7 @@ typedef struct _ATOM_Tonga_SCLK_Dependency_Record {
> typedef struct _ATOM_Tonga_SCLK_Dependency_Table {
> UCHAR ucRevId;
> UCHAR ucNumEntries;
> /* Number of entries. */
> - ATOM_Tonga_SCLK_Dependency_Record entries[1];
>/* Dynamically allocate entries. */
> + ATOM_Tonga_SCLK_Dependency_Record entries[];
>/* Dynamically allocate entries. */
> } ATOM_Tonga_SCLK_Dependency_Table;
>
> typedef struct _ATOM_Polaris_SCLK_Dependency_Record { @@ -210,7
> +210,7 @@ typedef struct _ATOM_Polaris_SCLK_Dependency_Record {
> typedef struct _ATOM_Polaris_SCLK_Dependency_Table {
> UCHAR ucRevId;
> UCHAR ucNumEntries;
> /* Number of entries. */
> - ATOM_Polaris_SCLK_Dependency_Record entries[1];
>/* Dynamically allocate entries. */
> + ATOM_Polaris_SCLK_Dependency_Record entries[];
>/* Dynamically allocate entries. */
> } ATOM_Polaris_SCLK_Dependency_Table;
>
> typedef struct _ATOM_Tonga_PCIE_Record { @@ -222,7 +222,7 @@ typedef
> struct _ATOM_Tonga_PCIE_Record { typedef struct
> _ATOM_Tonga_PCIE_Table {
> UCHAR ucRevId;
> UCHAR ucNumEntries;
> /* Number of entries. */
> - ATOM_Tonga_PCIE_Record entries[1];
> /* Dynamically allocate entries. */
> + ATOM_Tonga_PCIE_Record entries[];
> /* Dynamically allocate entries. */
> } ATOM_Tonga_PCIE_Table;
>
> typedef struct _ATOM_Polaris10_PCIE_Record { @@ -235,7 +235,7 @@
> typedef struct _ATOM_Polaris10_PCIE_Record { typedef struct
> _ATOM_Polaris10_PCIE_Table {
> UCHAR ucRevId;
> UCHAR ucNumEntries; /* Number
> of entries. */
> - ATOM_Polaris10_PCIE_Record entries[1]; /*
> Dynamically
> allocate entries. */
> + ATOM_Polaris10_PCIE_Record entries[]; /*
> Dynamically
> allocate entries. */
> } ATOM_Polaris10_PCIE_Table;
>
>
> @@ -252,7 +252,7 @@ typedef struct
> _ATOM_Tonga_MM_Dependency_Record { typedef struct
> _ATOM_Tonga_MM_Dependency_Table {
> UCHAR ucRevId;
> UCHAR ucNumEntries;
> /* Number of entries. */
> - ATOM_Tonga_MM_Dependency_Recor
RE: [PATCH 0/5] Add the pci_get_base_class() helper and use it
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of Sui
> Jingfeng
> Sent: Friday, August 25, 2023 2:27 AM
> To: Bjorn Helgaas
> Cc: alsa-de...@alsa-project.org; Sui Jingfeng ;
> nouv...@lists.freedesktop.org; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; linux-
> p...@vger.kernel.org
> Subject: [PATCH 0/5] Add the pci_get_base_class() helper and use it
>
> From: Sui Jingfeng
>
> There is no function that can be used to get all PCI(e) devices in a system by
> matching against its the PCI base class code only, while keep the sub-class
> code
> and the programming interface ignored. Therefore, add the
> pci_get_base_class() function to suit the need.
>
> For example, if an application want to process all PCI(e) display devices in a
> system, it can achieve such goal by writing the code as following:
>
> pdev = NULL;
> do {
> pdev = pci_get_base_class(PCI_BASE_CLASS_DISPLAY, pdev);
> if (!pdev)
> break;
>
> do_something_for_pci_display_device(pdev);
> } while (1);
>
> Sui Jingfeng (5):
> PCI: Add the pci_get_base_class() helper
> ALSA: hda/intel: Use pci_get_base_class() to reduce duplicated code
> drm/nouveau: Use pci_get_base_class() to reduce duplicated code
> drm/amdgpu: Use pci_get_base_class() to reduce duplicated code
> drm/radeon: Use pci_get_base_class() to reduce duplicated code
>
Series is:
Reviewed-by: Alex Deucher
> drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 11 +++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 20 ---
> drivers/gpu/drm/nouveau/nouveau_acpi.c | 11 +++--
> drivers/gpu/drm/radeon/radeon_bios.c | 20 ---
> drivers/pci/search.c | 31
> include/linux/pci.h | 5
> sound/pci/hda/hda_intel.c| 16
> 7 files changed, 59 insertions(+), 55 deletions(-)
>
> --
> 2.34.1
RE: [PATCH AUTOSEL 5.10 3/3] drm/amdkfd: ignore crat by default
[Public] > -Original Message- > From: Sasha Levin > Sent: Tuesday, August 22, 2023 7:37 AM > To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org > Cc: Deucher, Alexander ; Kuehling, Felix > ; Koenig, Christian ; > Mike Lothian ; Sasha Levin ; Pan, > Xinhui ; airl...@gmail.com; dan...@ffwll.ch; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: [PATCH AUTOSEL 5.10 3/3] drm/amdkfd: ignore crat by default > > From: Alex Deucher > > [ Upstream commit a6dea2d64ff92851e68cd4e20a35f6534286e016 ] > > We are dropping the IOMMUv2 path, so no need to enable this. > It's often buggy on consumer platforms anyway. This is not needed for stable. Alex > > Reviewed-by: Felix Kuehling > Acked-by: Christian König > Tested-by: Mike Lothian > Signed-off-by: Alex Deucher > Signed-off-by: Sasha Levin > --- > drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > index 86b4dadf772e3..61fea0d268b96 100644 > --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > @@ -749,11 +749,7 @@ static bool kfd_ignore_crat(void) > if (ignore_crat) > return true; > > -#ifndef KFD_SUPPORT_IOMMU_V2 > ret = true; > -#else > - ret = false; > -#endif > > return ret; > } > -- > 2.40.1
RE: [PATCH AUTOSEL 6.1 10/10] drm/amdkfd: disable IOMMUv2 support for Raven
[Public]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, August 22, 2023 7:36 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ;
> Mike Lothian ; Sasha Levin ; Pan,
> Xinhui ; airl...@gmail.com; dan...@ffwll.ch; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH AUTOSEL 6.1 10/10] drm/amdkfd: disable IOMMUv2
> support for Raven
>
> From: Alex Deucher
>
> [ Upstream commit 091ae5473f96ced844af6ba39b94757359b12348 ]
>
> Use the dGPU path instead. There were a lot of platform issues with IOMMU
> in general on these chips due to windows not enabling IOMMU at the time.
> The dGPU path has been used for a long time with newer APUs and works
> fine. This also paves the way to simplify the driver significantly.
This is not needed for stable.
Alex
>
> Reviewed-by: Felix Kuehling
> Acked-by: Christian König
> Tested-by: Mike Lothian
> Signed-off-by: Alex Deucher
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> index 4cc5debdd119b..af18378e58d9f 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> @@ -185,11 +185,6 @@ static void kfd_device_info_init(struct kfd_dev *kfd,
>
> kfd_device_info_set_event_interrupt_class(kfd);
>
> - /* Raven */
> - if (gc_version == IP_VERSION(9, 1, 0) ||
> - gc_version == IP_VERSION(9, 2, 2))
> - kfd->device_info.needs_iommu_device = true;
> -
> if (gc_version < IP_VERSION(11, 0, 0)) {
> /* Navi2x+, Navi1x+ */
> if (gc_version == IP_VERSION(10, 3, 6)) @@ -287,7
> +282,6 @@ struct kfd_dev *kgd2kfd_probe(struct amdgpu_device *adev,
> bool vf)
> gfx_target_version = 9;
> f2g = _v9_kfd2kgd;
> break;
> -#ifdef KFD_SUPPORT_IOMMU_V2
> /* Raven */
> case IP_VERSION(9, 1, 0):
> case IP_VERSION(9, 2, 2):
> @@ -295,7 +289,6 @@ struct kfd_dev *kgd2kfd_probe(struct
> amdgpu_device *adev, bool vf)
> if (!vf)
> f2g = _v9_kfd2kgd;
> break;
> -#endif
> /* Vega12 */
> case IP_VERSION(9, 2, 1):
> gfx_target_version = 90004;
> --
> 2.40.1
RE: [PATCH AUTOSEL 5.15 6/6] drm/amdkfd: ignore crat by default
[Public] > -Original Message- > From: Sasha Levin > Sent: Tuesday, August 22, 2023 7:37 AM > To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org > Cc: Deucher, Alexander ; Kuehling, Felix > ; Koenig, Christian ; > Mike Lothian ; Sasha Levin ; Pan, > Xinhui ; airl...@gmail.com; dan...@ffwll.ch; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: [PATCH AUTOSEL 5.15 6/6] drm/amdkfd: ignore crat by default > > From: Alex Deucher > > [ Upstream commit a6dea2d64ff92851e68cd4e20a35f6534286e016 ] > > We are dropping the IOMMUv2 path, so no need to enable this. > It's often buggy on consumer platforms anyway. This is not needed for stable. Alex > > Reviewed-by: Felix Kuehling > Acked-by: Christian König > Tested-by: Mike Lothian > Signed-off-by: Alex Deucher > Signed-off-by: Sasha Levin > --- > drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > index e574aa32a111d..46dfd9baeb013 100644 > --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > @@ -1523,11 +1523,7 @@ static bool kfd_ignore_crat(void) > if (ignore_crat) > return true; > > -#ifndef KFD_SUPPORT_IOMMU_V2 > ret = true; > -#else > - ret = false; > -#endif > > return ret; > } > -- > 2.40.1
RE: [PATCH AUTOSEL 6.1 09/10] drm/amdkfd: disable IOMMUv2 support for KV/CZ
[Public]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, August 22, 2023 7:36 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ;
> Mike Lothian ; Sasha Levin ; Pan,
> Xinhui ; airl...@gmail.com; dan...@ffwll.ch; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH AUTOSEL 6.1 09/10] drm/amdkfd: disable IOMMUv2
> support for KV/CZ
>
> From: Alex Deucher
>
> [ Upstream commit 616f92d188ee7142a95a52068efdbea82645f859 ]
>
> Use the dGPU path instead. There were a lot of platform issues with IOMMU
> in general on these chips due to windows not enabling IOMMU at the time.
> The dGPU path has been used for a long time with newer APUs and works
> fine. This also paves the way to simplify the driver significantly.
This is not needed for stable.
Alex
>
> v2: use the dGPU queue manager functions
>
> Reviewed-by: Felix Kuehling
> Acked-by: Christian König
> Tested-by: Mike Lothian
> Signed-off-by: Alex Deucher
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 6 --
> drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 8 +---
> 2 files changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> index 27820f0a282d1..4cc5debdd119b 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> @@ -216,10 +216,6 @@ static void kfd_device_info_init(struct kfd_dev *kfd,
> asic_type != CHIP_TONGA)
> kfd->device_info.supports_cwsr = true;
>
> - if (asic_type == CHIP_KAVERI ||
> - asic_type == CHIP_CARRIZO)
> - kfd->device_info.needs_iommu_device = true;
> -
> if (asic_type != CHIP_HAWAII && !vf)
> kfd->device_info.needs_pci_atomics = true;
> }
> @@ -233,7 +229,6 @@ struct kfd_dev *kgd2kfd_probe(struct
> amdgpu_device *adev, bool vf)
> uint32_t gfx_target_version = 0;
>
> switch (adev->asic_type) {
> -#ifdef KFD_SUPPORT_IOMMU_V2
> #ifdef CONFIG_DRM_AMDGPU_CIK
> case CHIP_KAVERI:
> gfx_target_version = 7;
> @@ -246,7 +241,6 @@ struct kfd_dev *kgd2kfd_probe(struct
> amdgpu_device *adev, bool vf)
> if (!vf)
> f2g = _v8_kfd2kgd;
> break;
> -#endif
> #ifdef CONFIG_DRM_AMDGPU_CIK
> case CHIP_HAWAII:
> gfx_target_version = 70001;
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index c06ada0844ba1..5616a722578f5 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -2335,18 +2335,12 @@ struct device_queue_manager
> *device_queue_manager_init(struct kfd_dev *dev)
> }
>
> switch (dev->adev->asic_type) {
> - case CHIP_CARRIZO:
> - device_queue_manager_init_vi(>asic_ops);
> - break;
> -
> case CHIP_KAVERI:
> - device_queue_manager_init_cik(>asic_ops);
> - break;
> -
> case CHIP_HAWAII:
> device_queue_manager_init_cik_hawaii(>asic_ops);
> break;
>
> + case CHIP_CARRIZO:
> case CHIP_TONGA:
> case CHIP_FIJI:
> case CHIP_POLARIS10:
> --
> 2.40.1
RE: [PATCH AUTOSEL 6.1 08/10] drm/amdkfd: ignore crat by default
[Public] > -Original Message- > From: Sasha Levin > Sent: Tuesday, August 22, 2023 7:36 AM > To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org > Cc: Deucher, Alexander ; Kuehling, Felix > ; Koenig, Christian ; > Mike Lothian ; Sasha Levin ; Pan, > Xinhui ; airl...@gmail.com; dan...@ffwll.ch; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: [PATCH AUTOSEL 6.1 08/10] drm/amdkfd: ignore crat by default > > From: Alex Deucher > > [ Upstream commit a6dea2d64ff92851e68cd4e20a35f6534286e016 ] > > We are dropping the IOMMUv2 path, so no need to enable this. > It's often buggy on consumer platforms anyway. This is not needed for stable. Alex > > Reviewed-by: Felix Kuehling > Acked-by: Christian König > Tested-by: Mike Lothian > Signed-off-by: Alex Deucher > Signed-off-by: Sasha Levin > --- > drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > index e45c6bc8d10bb..a9fa4772b2d35 100644 > --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > @@ -1543,11 +1543,7 @@ static bool kfd_ignore_crat(void) > if (ignore_crat) > return true; > > -#ifndef KFD_SUPPORT_IOMMU_V2 > ret = true; > -#else > - ret = false; > -#endif > > return ret; > } > -- > 2.40.1
RE: [PATCH AUTOSEL 6.4 09/11] drm/amdkfd: ignore crat by default
[Public] > -Original Message- > From: Sasha Levin > Sent: Tuesday, August 22, 2023 7:36 AM > To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org > Cc: Deucher, Alexander ; Kuehling, Felix > ; Koenig, Christian ; > Mike Lothian ; Sasha Levin ; Pan, > Xinhui ; airl...@gmail.com; dan...@ffwll.ch; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: [PATCH AUTOSEL 6.4 09/11] drm/amdkfd: ignore crat by default > > From: Alex Deucher > > [ Upstream commit a6dea2d64ff92851e68cd4e20a35f6534286e016 ] > > We are dropping the IOMMUv2 path, so no need to enable this. > It's often buggy on consumer platforms anyway. > This is not needed for stable. Alex > Reviewed-by: Felix Kuehling > Acked-by: Christian König > Tested-by: Mike Lothian > Signed-off-by: Alex Deucher > Signed-off-by: Sasha Levin > --- > drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > index 475e470273540..ee0cc35d68a84 100644 > --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c > @@ -1543,11 +1543,7 @@ static bool kfd_ignore_crat(void) > if (ignore_crat) > return true; > > -#ifndef KFD_SUPPORT_IOMMU_V2 > ret = true; > -#else > - ret = false; > -#endif > > return ret; > } > -- > 2.40.1
RE: [PATCH AUTOSEL 6.4 11/11] drm/amdkfd: disable IOMMUv2 support for Raven
[Public]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, August 22, 2023 7:36 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ;
> Mike Lothian ; Sasha Levin ; Pan,
> Xinhui ; airl...@gmail.com; dan...@ffwll.ch; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH AUTOSEL 6.4 11/11] drm/amdkfd: disable IOMMUv2
> support for Raven
>
> From: Alex Deucher
>
> [ Upstream commit 091ae5473f96ced844af6ba39b94757359b12348 ]
>
> Use the dGPU path instead. There were a lot of platform issues with IOMMU
> in general on these chips due to windows not enabling IOMMU at the time.
> The dGPU path has been used for a long time with newer APUs and works
> fine. This also paves the way to simplify the driver significantly.
This is not needed for stable.
Alex
>
> Reviewed-by: Felix Kuehling
> Acked-by: Christian König
> Tested-by: Mike Lothian
> Signed-off-by: Alex Deucher
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> index 9c8197573dee7..224e057d2dbbf 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> @@ -185,11 +185,6 @@ static void kfd_device_info_init(struct kfd_dev *kfd,
>
> kfd_device_info_set_event_interrupt_class(kfd);
>
> - /* Raven */
> - if (gc_version == IP_VERSION(9, 1, 0) ||
> - gc_version == IP_VERSION(9, 2, 2))
> - kfd->device_info.needs_iommu_device = true;
> -
> if (gc_version < IP_VERSION(11, 0, 0)) {
> /* Navi2x+, Navi1x+ */
> if (gc_version == IP_VERSION(10, 3, 6)) @@ -283,7
> +278,6 @@ struct kfd_dev *kgd2kfd_probe(struct amdgpu_device *adev,
> bool vf)
> gfx_target_version = 9;
> f2g = _v9_kfd2kgd;
> break;
> -#ifdef KFD_SUPPORT_IOMMU_V2
> /* Raven */
> case IP_VERSION(9, 1, 0):
> case IP_VERSION(9, 2, 2):
> @@ -291,7 +285,6 @@ struct kfd_dev *kgd2kfd_probe(struct
> amdgpu_device *adev, bool vf)
> if (!vf)
> f2g = _v9_kfd2kgd;
> break;
> -#endif
> /* Vega12 */
> case IP_VERSION(9, 2, 1):
> gfx_target_version = 90004;
> --
> 2.40.1
RE: [PATCH AUTOSEL 6.4 10/11] drm/amdkfd: disable IOMMUv2 support for KV/CZ
[Public]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, August 22, 2023 7:36 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ;
> Mike Lothian ; Sasha Levin ; Pan,
> Xinhui ; airl...@gmail.com; dan...@ffwll.ch; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH AUTOSEL 6.4 10/11] drm/amdkfd: disable IOMMUv2
> support for KV/CZ
>
> From: Alex Deucher
>
> [ Upstream commit 616f92d188ee7142a95a52068efdbea82645f859 ]
>
> Use the dGPU path instead. There were a lot of platform issues with IOMMU
> in general on these chips due to windows not enabling IOMMU at the time.
> The dGPU path has been used for a long time with newer APUs and works
> fine. This also paves the way to simplify the driver significantly.
>
> v2: use the dGPU queue manager functions
This is not needed for stable.
Alex
>
> Reviewed-by: Felix Kuehling
> Acked-by: Christian König
> Tested-by: Mike Lothian
> Signed-off-by: Alex Deucher
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 6 --
> drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 8 +---
> 2 files changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> index 00f528eb98126..9c8197573dee7 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> @@ -224,10 +224,6 @@ static void kfd_device_info_init(struct kfd_dev *kfd,
> asic_type != CHIP_TONGA)
> kfd->device_info.supports_cwsr = true;
>
> - if (asic_type == CHIP_KAVERI ||
> - asic_type == CHIP_CARRIZO)
> - kfd->device_info.needs_iommu_device = true;
> -
> if (asic_type != CHIP_HAWAII && !vf)
> kfd->device_info.needs_pci_atomics = true;
> }
> @@ -240,7 +236,6 @@ struct kfd_dev *kgd2kfd_probe(struct
> amdgpu_device *adev, bool vf)
> uint32_t gfx_target_version = 0;
>
> switch (adev->asic_type) {
> -#ifdef KFD_SUPPORT_IOMMU_V2
> #ifdef CONFIG_DRM_AMDGPU_CIK
> case CHIP_KAVERI:
> gfx_target_version = 7;
> @@ -253,7 +248,6 @@ struct kfd_dev *kgd2kfd_probe(struct
> amdgpu_device *adev, bool vf)
> if (!vf)
> f2g = _v8_kfd2kgd;
> break;
> -#endif
> #ifdef CONFIG_DRM_AMDGPU_CIK
> case CHIP_HAWAII:
> gfx_target_version = 70001;
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index 7a95698d83f73..c73417e79745e 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -2335,18 +2335,12 @@ struct device_queue_manager
> *device_queue_manager_init(struct kfd_dev *dev)
> }
>
> switch (dev->adev->asic_type) {
> - case CHIP_CARRIZO:
> - device_queue_manager_init_vi(>asic_ops);
> - break;
> -
> case CHIP_KAVERI:
> - device_queue_manager_init_cik(>asic_ops);
> - break;
> -
> case CHIP_HAWAII:
> device_queue_manager_init_cik_hawaii(>asic_ops);
> break;
>
> + case CHIP_CARRIZO:
> case CHIP_TONGA:
> case CHIP_FIJI:
> case CHIP_POLARIS10:
> --
> 2.40.1
RE: [PATCH v5 06/11] drm/radeon: Use RMW accessors for changing LNKCTL
[Public]
> -Original Message-
> From: Ilpo Järvinen
> Sent: Monday, July 17, 2023 8:05 AM
> To: linux-...@vger.kernel.org; Bjorn Helgaas ; Lorenzo
> Pieralisi ; Rob Herring ;
> Krzysztof Wilczyński ; Emmanuel Grumbach
> ; Rafael J . Wysocki ;
> Heiner Kallweit ; Lukas Wunner ;
> Andy Shevchenko ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> ker...@vger.kernel.org
> Cc: Dean Luick ; Jonas Dreßler
> ; Ilpo Järvinen ;
> sta...@vger.kernel.org
> Subject: [PATCH v5 06/11] drm/radeon: Use RMW accessors for changing
> LNKCTL
>
> Don't assume that only the driver would be accessing LNKCTL. ASPM policy
> changes can trigger write to LNKCTL outside of driver's control.
> And in the case of upstream bridge, the driver does not even own the device
> it's changing the registers for.
>
> Use RMW capability accessors which do proper locking to avoid losing
> concurrent updates to the register value.
>
> Fixes: 8a7cd27679d0 ("drm/radeon/cik: add support for pcie gen1/2/3
> switching")
> Fixes: b9d305dfb66c ("drm/radeon: implement pcie gen2/3 support for SI")
> Suggested-by: Lukas Wunner
> Signed-off-by: Ilpo Järvinen
> Cc: sta...@vger.kernel.org
For this and the amdgpu patch:
Acked-by: Alex Deucher
I'm not sure if this is stable material however. Is there some issue today?
> ---
> drivers/gpu/drm/radeon/cik.c | 36 ++-
> drivers/gpu/drm/radeon/si.c | 37 ++--
> 2 files changed, 20 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 5819737c21c6..a6f3c811ceb8 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -9534,17 +9534,8 @@ static void cik_pcie_gen3_enable(struct
> radeon_device *rdev)
> u16 bridge_cfg2, gpu_cfg2;
> u32 max_lw, current_lw, tmp;
>
> - pcie_capability_read_word(root, PCI_EXP_LNKCTL,
> - _cfg);
> - pcie_capability_read_word(rdev->pdev,
> PCI_EXP_LNKCTL,
> - _cfg);
> -
> - tmp16 = bridge_cfg | PCI_EXP_LNKCTL_HAWD;
> - pcie_capability_write_word(root, PCI_EXP_LNKCTL,
> tmp16);
> -
> - tmp16 = gpu_cfg | PCI_EXP_LNKCTL_HAWD;
> - pcie_capability_write_word(rdev->pdev,
> PCI_EXP_LNKCTL,
> -tmp16);
> + pcie_capability_set_word(root, PCI_EXP_LNKCTL,
> PCI_EXP_LNKCTL_HAWD);
> + pcie_capability_set_word(rdev->pdev,
> PCI_EXP_LNKCTL,
> +PCI_EXP_LNKCTL_HAWD);
>
> tmp = RREG32_PCIE_PORT(PCIE_LC_STATUS1);
> max_lw = (tmp & LC_DETECTED_LINK_WIDTH_MASK)
> >> LC_DETECTED_LINK_WIDTH_SHIFT; @@ -9591,21 +9582,14 @@ static
> void cik_pcie_gen3_enable(struct radeon_device *rdev)
> msleep(100);
>
> /* linkctl */
> - pcie_capability_read_word(root,
> PCI_EXP_LNKCTL,
> - );
> - tmp16 &= ~PCI_EXP_LNKCTL_HAWD;
> - tmp16 |= (bridge_cfg &
> PCI_EXP_LNKCTL_HAWD);
> - pcie_capability_write_word(root,
> PCI_EXP_LNKCTL,
> -tmp16);
> -
> - pcie_capability_read_word(rdev->pdev,
> - PCI_EXP_LNKCTL,
> - );
> - tmp16 &= ~PCI_EXP_LNKCTL_HAWD;
> - tmp16 |= (gpu_cfg &
> PCI_EXP_LNKCTL_HAWD);
> - pcie_capability_write_word(rdev->pdev,
> -PCI_EXP_LNKCTL,
> -tmp16);
> + pcie_capability_clear_and_set_word(root,
> PCI_EXP_LNKCTL,
> +
> PCI_EXP_LNKCTL_HAWD,
> +bridge_cfg &
> +
> PCI_EXP_LNKCTL_HAWD);
> + pcie_capability_clear_and_set_word(rdev-
> >pdev, PCI_EXP_LNKCTL,
> +
> PCI_EXP_LNKCTL_HAWD,
> +gpu_cfg
Re: [PATCH] Documentation/gpu: Update amdgpu documentation
[AMD Official Use Only - General]
Reviewed-by: Alex Deucher
From: Lazar, Lijo
Sent: Tuesday, August 15, 2023 11:56 PM
To: amd-...@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; s...@canb.auug.org.au ;
airl...@redhat.com ; dri-devel@lists.freedesktop.org
Subject: [PATCH] Documentation/gpu: Update amdgpu documentation
7957ec80ef97 ("drm/amdgpu: Add FRU sysfs nodes only if needed") moved
the documentation for some of the sysfs nodes to amdgpu_fru_eeprom.c.
Update the documentation accordingly.
Signed-off-by: Lijo Lazar
---
Documentation/gpu/amdgpu/driver-misc.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/gpu/amdgpu/driver-misc.rst
b/Documentation/gpu/amdgpu/driver-misc.rst
index be131e963d87..26334e54447b 100644
--- a/Documentation/gpu/amdgpu/driver-misc.rst
+++ b/Documentation/gpu/amdgpu/driver-misc.rst
@@ -11,19 +11,19 @@ via sysfs
product_name
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
:doc: product_name
product_number
--
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
:doc: product_name
serial_number
-
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
:doc: serial_number
unique_id
--
2.25.1
RE: [PATCH v2] drm/amdgpu: Add error reporting code for the display core
[Public]
> -Original Message-
> From: Sui Jingfeng
> Sent: Sunday, June 11, 2023 11:24 AM
> To: Wentland, Harry ; Li, Sun peng (Leo)
> ; Siqueira, Rodrigo ;
> Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; Lee, Alvin
> ; Lei, Jun ; Zhuo, Qingqing (Lillian)
> ; Liu, Wenjing ; Tam,
> Samson ; Varone, Dillon
> ; Liu, HaoPing (Alan)
> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH v2] drm/amdgpu: Add error reporting code for the display
> core
>
> [why]
>
> Because the drm/amdgpu drivers do not work with Navi 10 [RX 5700] series
> GPUs on non-x86 platforms, this patch helps find out where the drivers fail.
> After applying his patch, the following error message can be found:
>
> [drm:dc_create [amdgpu]] *ERROR* dc_construct: failed to create resource
> pool [drm:dc_create [amdgpu]] *ERROR* dc_create: dc construct failed [drm]
> Display Core failed to initialize with v3.2.230!
Curious what the failure was on your platform. Resource create is mostly just
allocating structures.
Alex
>
> Signed-off-by: Sui Jingfeng
> ---
> drivers/gpu/drm/amd/display/dc/core/dc.c | 29
> 1 file changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 52564b93f7eb..d33b78aa3e58 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -951,7 +951,7 @@ static bool dc_construct(struct dc *dc,
> goto fail;
> }
>
> -dc_ctx = dc->ctx;
> + dc_ctx = dc->ctx;
>
> /* Resource should construct all asic specific resources.
>* This should be the only place where we need to parse the asic id
> @@ -990,16 +990,21 @@ static bool dc_construct(struct dc *dc,
> }
>
> dc->res_pool = dc_create_resource_pool(dc, init_params, dc_ctx-
> >dce_version);
> - if (!dc->res_pool)
> + if (!dc->res_pool) {
> + dm_error("%s: failed to create resource pool\n", __func__);
> goto fail;
> + }
>
> /* set i2c speed if not done by the respective dcnxxx__resource.c */
> if (dc->caps.i2c_speed_in_khz_hdcp == 0)
> dc->caps.i2c_speed_in_khz_hdcp = dc-
> >caps.i2c_speed_in_khz;
>
> dc->clk_mgr = dc_clk_mgr_create(dc->ctx, dc->res_pool->pp_smu, dc-
> >res_pool->dccg);
> - if (!dc->clk_mgr)
> + if (!dc->clk_mgr) {
> + dm_error("%s: failed to create clk manager\n", __func__);
> goto fail;
> + }
> +
> #ifdef CONFIG_DRM_AMD_DC_FP
> dc->clk_mgr->force_smu_not_present = init_params-
> >force_smu_not_present;
>
> @@ -1022,14 +1027,18 @@ static bool dc_construct(struct dc *dc,
> goto fail;
> }
>
> - if (!create_links(dc, init_params->num_virtual_links))
> + if (!create_links(dc, init_params->num_virtual_links)) {
> + dm_error("%s: failed to create links\n", __func__);
> goto fail;
> + }
>
> /* Create additional DIG link encoder objects if fewer than the
> platform
>* supports were created during link construction.
>*/
> - if (!create_link_encoders(dc))
> + if (!create_link_encoders(dc)) {
> + dm_error("%s: failed to create link encoders\n", __func__);
> goto fail;
> + }
>
> dc_resource_state_construct(dc, dc->current_state);
>
> @@ -1314,11 +1323,15 @@ struct dc *dc_create(const struct dc_init_data
> *init_params)
> return NULL;
>
> if (init_params->dce_environment == DCE_ENV_VIRTUAL_HW) {
> - if (!dc_construct_ctx(dc, init_params))
> + if (!dc_construct_ctx(dc, init_params)) {
> + DC_LOG_ERROR("%s: dc construct failed\n",
> __func__);
> goto destruct_dc;
> + }
> } else {
> - if (!dc_construct(dc, init_params))
> + if (!dc_construct(dc, init_params)) {
> + DC_LOG_ERROR("%s: dc construct failed\n",
> __func__);
> goto destruct_dc;
> + }
>
> full_pipe_count = dc->res_pool->pipe_count;
> if (dc->res_pool->underlay_pipe_index !=
> NO_UNDERLAY_PIPE) @@ -1349,8 +1362,6 @@ struct dc *dc_create(const
> struct dc_init_data *init_params)
>
> DC_LOG_DC("Display Core initialized\n");
>
> -
> -
> return dc;
>
> destruct_dc:
> --
> 2.25.1
RE: WARNING: CPU: 5 PID: 1464 at drivers/gpu/drm/ttm/ttm_bo.c:326 ttm_bo_release+0x27e/0x2d0 [ttm]
[Public]
+ Christian
> -Original Message-
> From: Borislav Petkov
> Sent: Saturday, June 3, 2023 1:48 PM
> To: amd-...@lists.freedesktop.org
> Cc: Deucher, Alexander ; dri-
> de...@lists.freedesktop.org; lkml
> Subject: WARNING: CPU: 5 PID: 1464 at drivers/gpu/drm/ttm/ttm_bo.c:326
> ttm_bo_release+0x27e/0x2d0 [ttm]
>
> Hi,
>
> this below triggers with the latest Linus tree:
>
> 51f269a6ecc7 ("Merge tag 'probes-fixes-6.4-rc4' of
> git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace")
>
> ...
> [ 16.173593] [drm] radeon kernel modesetting enabled.
> [ 16.173743] radeon :29:00.0: vgaarb: deactivate vga console
> [ 16.174300] MCE: In-kernel MCE decoding enabled.
> [ 16.175695] EDAC DEBUG: umc_read_base_mask: DCSB0[0]=0x0001
> reg: 0x5
> [ 16.175698] EDAC DEBUG: umc_read_base_mask:
> DCSB_SEC0[0]=0x reg: 0x50010
> [ 16.175700] EDAC DEBUG: umc_read_base_mask: DCSB0[1]=0x
> reg: 0x50004
> [ 16.175702] EDAC DEBUG: umc_read_base_mask:
> DCSB_SEC0[1]=0x reg: 0x50014
> [ 16.175703] EDAC DEBUG: umc_read_base_mask: DCSB0[2]=0x0201
> reg: 0x50008
> [ 16.175705] EDAC DEBUG: umc_read_base_mask:
> DCSB_SEC0[2]=0x reg: 0x50018
> [ 16.175706] EDAC DEBUG: umc_read_base_mask: DCSB0[3]=0x
> reg: 0x5000c
> [ 16.175707] EDAC DEBUG: umc_read_base_mask:
> DCSB_SEC0[3]=0x reg: 0x5001c
> [ 16.175709] EDAC DEBUG: umc_read_base_mask: DCSM0[0]=0x03fffdfe
> reg: 0x50020
> [ 16.175710] EDAC DEBUG: umc_read_base_mask:
> DCSM_SEC0[0]=0x reg: 0x50028
> [ 16.175712] EDAC DEBUG: umc_read_base_mask: DCSM0[1]=0x03fffdfe
> reg: 0x50024
> [ 16.175713] EDAC DEBUG: umc_read_base_mask:
> DCSM_SEC0[1]=0x reg: 0x5002c
> [ 16.175715] EDAC DEBUG: umc_read_base_mask: DCSB1[0]=0x0001
> reg: 0x15
> [ 16.175716] EDAC DEBUG: umc_read_base_mask:
> DCSB_SEC1[0]=0x reg: 0x150010
> [ 16.175718] EDAC DEBUG: umc_read_base_mask: DCSB1[1]=0x
> reg: 0x150004
> [ 16.175719] EDAC DEBUG: umc_read_base_mask:
> DCSB_SEC1[1]=0x reg: 0x150014
> [ 16.175720] EDAC DEBUG: umc_read_base_mask: DCSB1[2]=0x0201
> reg: 0x150008
> [ 16.175722] EDAC DEBUG: umc_read_base_mask:
> DCSB_SEC1[2]=0x reg: 0x150018
> [ 16.175723] EDAC DEBUG: umc_read_base_mask: DCSB1[3]=0x
> reg: 0x15000c
> [ 16.175725] EDAC DEBUG: umc_read_base_mask:
> DCSB_SEC1[3]=0x reg: 0x15001c
> [ 16.175726] EDAC DEBUG: umc_read_base_mask: DCSM1[0]=0x03fffdfe
> reg: 0x150020
> [ 16.175728] EDAC DEBUG: umc_read_base_mask:
> DCSM_SEC1[0]=0x reg: 0x150028
> [ 16.175729] EDAC DEBUG: umc_read_base_mask: DCSM1[1]=0x03fffdfe
> reg: 0x150024
> [ 16.175730] EDAC DEBUG: umc_read_base_mask:
> DCSM_SEC1[1]=0x reg: 0x15002c
> [ 16.175741] EDAC DEBUG: umc_determine_memory_type: UMC0 DIMM
> type: Unbuffered-DDR4
> [ 16.175742] EDAC DEBUG: umc_determine_memory_type: UMC1 DIMM
> type: Unbuffered-DDR4
> [ 16.177514] Console: switching to colour dummy device 80x25
> [ 16.177693] [drm] initializing kernel modesetting (CEDAR 0x1002:0x68E1
> 0x174B:0x3000 0x00).
> [ 16.177733] ATOM BIOS: AMD
> [ 16.177795] radeon :29:00.0: VRAM: 1024M 0x
> - 0x3FFF (1024M used)
> [ 16.177798] radeon :29:00.0: GTT: 1024M 0x4000 -
> 0x7FFF
> [ 16.177800] [drm] Detected VRAM RAM=1024M, BAR=256M
> [ 16.177802] [drm] RAM width 64bits DDR
> [ 16.177835] [drm] radeon: 1024M of VRAM memory ready
> [ 16.177836] [drm] radeon: 1024M of GTT memory ready.
> [ 16.177839] [drm] Loading CEDAR Microcode
> [ 16.179106] [drm] Internal thermal controller without fan control
> [ 16.199812] [drm] radeon: dpm initialized
> [ 16.200179] [drm] GART: num cpu pages 262144, num gpu pages 262144
> [ 16.200399] [drm] enabling PCIE gen 2 link speeds, disable with
> radeon.pcie_gen2=0
> [ 16.218135] [drm] PCIE GART of 1024M enabled (table at
> 0x0014C000).
> [ 16.218239] radeon :29:00.0: WB enabled
> [ 16.218240] radeon :29:00.0: fence driver on ring 0 use gpu addr
> 0x4c00
> [ 16.218242] radeon :29:00.0: fence driver on ring 3 use gpu addr
> 0x4c0c
> [ 16.218606] radeon :29:00.0: fence driver on ring 5 use gpu addr
> 0x0005c418
> [ 16.218657] radeon :29:00.0: radeon: MSI limited to 32-bit
> [ 16.218689] radeon :29:00.0: radeon: using MSI.
> [ 16.218707] [drm] radeon: irq initialized.
> [ 16.234730] [drm] ring test on 0 succeeded in 0 usecs
> [ 16.234738] [drm] ring test on 3 succeeded in 2 usecs
> [ 16.317725] r8169 :25:00.0 et
RE: [PATCH] drm/amdgpu: Log if device is unsupported
[AMD Official Use Only - General]
> -Original Message-
> From: Paul Menzel
> Sent: Monday, June 5, 2023 11:23 AM
> To: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter
> Cc: Paul Menzel ; amd-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] drm/amdgpu: Log if device is unsupported
>
> Since there is overlap in supported devices, both modules load, but only one
> will bind to a particular device depending on the model and user's
> configuration.
>
> amdgpu binds to all display class devices with VID 0x1002 and then
> determines whether or not to bind to a device based on whether the
> individual device is supported by the driver or not. Log that case, so users
> looking at the logs know what is going on.
>
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2608
> Signed-off-by: Paul Menzel
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 86fbb4138285..410ff918c350 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -2062,8 +2062,10 @@ static int amdgpu_pci_probe(struct pci_dev
> *pdev,
>
> /* skip devices which are owned by radeon */
> for (i = 0; i < ARRAY_SIZE(amdgpu_unsupported_pciidlist); i++) {
> - if (amdgpu_unsupported_pciidlist[i] == pdev->device)
> + if (amdgpu_unsupported_pciidlist[i] == pdev->device) {
> + DRM_INFO("This hardware is only supported by
> radeon.");
> return -ENODEV;
I think this will confuse users even more. As there will be a new "error"
message reported. I'd suggest either dropping the message in init per my
proposed patch or just leaving things as is.
Alex
> + }
> }
>
> if (amdgpu_aspm == -1 && !pcie_aspm_enabled(pdev))
> --
> 2.40.1
RE: [PATCH] drm/amd/pm: Replace all non-returning strlcpy with strscpy
[Public] > -Original Message- > From: Kees Cook > Sent: Monday, May 22, 2023 4:16 PM > To: Azeem Shaikh > Cc: Quan, Evan ; linux-harden...@vger.kernel.org; > amd-...@lists.freedesktop.org; linux-ker...@vger.kernel.org; Deucher, > Alexander ; Koenig, Christian > ; Pan, Xinhui ; David > Airlie ; Daniel Vetter ; dri- > de...@lists.freedesktop.org > Subject: Re: [PATCH] drm/amd/pm: Replace all non-returning strlcpy with > strscpy > > On Mon, May 22, 2023 at 03:52:45PM +, Azeem Shaikh wrote: > > strlcpy() reads the entire source buffer first. > > This read may exceed the destination size limit. > > This is both inefficient and can lead to linear read overflows if a > > source string is not NUL-terminated [1]. > > In an effort to remove strlcpy() completely [2], replace > > strlcpy() here with strscpy(). > > No return values were used, so direct replacement is safe. > > > > [1] > > > https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy > > [2] https://github.com/KSPP/linux/issues/89 > > > > Signed-off-by: Azeem Shaikh > > Reviewed-by: Kees Cook > Acked-by: Alex Deucher Ack to take this through whatever tree makes sense if you are trying to batch all of these up. Otherwise, I can pick them up. Alex
RE: [PATCH] drm/radeon: Replace all non-returning strlcpy with strscpy
[Public] > -Original Message- > From: Kees Cook > Sent: Monday, May 22, 2023 4:15 PM > To: Azeem Shaikh > Cc: Deucher, Alexander ; Koenig, Christian > ; Pan, Xinhui ; linux- > harden...@vger.kernel.org; amd-...@lists.freedesktop.org; linux- > ker...@vger.kernel.org; David Airlie ; Daniel Vetter > ; dri-devel@lists.freedesktop.org > Subject: Re: [PATCH] drm/radeon: Replace all non-returning strlcpy with > strscpy > > On Mon, May 22, 2023 at 03:50:32PM +, Azeem Shaikh wrote: > > strlcpy() reads the entire source buffer first. > > This read may exceed the destination size limit. > > This is both inefficient and can lead to linear read overflows if a > > source string is not NUL-terminated [1]. > > In an effort to remove strlcpy() completely [2], replace > > strlcpy() here with strscpy(). > > No return values were used, so direct replacement is safe. > > > > [1] > > > https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy > > [2] https://github.com/KSPP/linux/issues/89 > > > > Signed-off-by: Azeem Shaikh > > Reviewed-by: Kees Cook > Acked-by: Alex Deucher Ack to take this through whatever tree makes sense if you are trying to batch all of these up. Otherwise, I can pick them up. Alex
RE: [PATCH 04/11] drm/radeon: Use regular fbdev I/O helpers
[Public]
> -Original Message-
> From: Thomas Zimmermann
> Sent: Friday, May 12, 2023 4:42 AM
> To: dan...@ffwll.ch; airl...@gmail.com; maarten.lankho...@linux.intel.com;
> mrip...@kernel.org; javi...@redhat.com
> Cc: dri-devel@lists.freedesktop.org; linux-arm-ker...@lists.infradead.org;
> linux-samsung-...@vger.kernel.org; intel-...@lists.freedesktop.org; linux-
> arm-...@vger.kernel.org; freedr...@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org; linux-te...@vger.kernel.org; Thomas
> Zimmermann ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui
> Subject: [PATCH 04/11] drm/radeon: Use regular fbdev I/O helpers
>
> Use the regular fbdev helpers for framebuffer I/O instead of DRM's helpers.
> Radeon does not use damage handling, so DRM's fbdev helpers are mere
> wrappers around the fbdev code.
>
> Add CONFIG_DRM_RADEON_FBDEV_EMULATION to select the necessary
> Kconfig options automatically. Make fbdev emulation depend on the new
> config option.
>
> By using fbdev helpers directly within each DRM fbdev emulation, we can
> eventually remove DRM's wrapper functions entirely.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "Pan, Xinhui"
Feel free to take this through whatever tree makes sense.
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/Kconfig| 8
> drivers/gpu/drm/radeon/Makefile | 2 +-
> drivers/gpu/drm/radeon/radeon_fbdev.c | 9 -
> drivers/gpu/drm/radeon/radeon_mode.h | 2 +-
> 4 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/Kconfig
> b/drivers/gpu/drm/radeon/Kconfig index e19d77d58810..66b741d96cc4
> 100644
> --- a/drivers/gpu/drm/radeon/Kconfig
> +++ b/drivers/gpu/drm/radeon/Kconfig
> @@ -8,6 +8,7 @@ config DRM_RADEON
> select DRM_DISPLAY_DP_HELPER
> select DRM_DISPLAY_HELPER
> select DRM_KMS_HELPER
> + select DRM_RADEON_FBDEV_EMULATION if
> DRM_FBDEV_EMULATION
> select DRM_SUBALLOC_HELPER
> select DRM_TTM
> select DRM_TTM_HELPER
> @@ -39,3 +40,10 @@ config DRM_RADEON_USERPTR
> help
> This option selects CONFIG_MMU_NOTIFIER if it isn't already
> selected to enabled full userptr support.
> +
> +config DRM_RADEON_FBDEV_EMULATION
> + bool
> + depends on DRM_RADEON
> + select FB_CFB_COPYAREA
> + select FB_CFB_FILLRECT
> + select FB_CFB_IMAGEBLIT
> diff --git a/drivers/gpu/drm/radeon/Makefile
> b/drivers/gpu/drm/radeon/Makefile index a8734b7d0485..46c1446196a9
> 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -76,7 +76,7 @@ radeon-y += \
> vce_v1_0.o \
> vce_v2_0.o
>
> -radeon-$(CONFIG_DRM_FBDEV_EMULATION) += radeon_fbdev.o
> +radeon-$(CONFIG_DRM_RADEON_FBDEV_EMULATION) +=
> radeon_fbdev.o
> radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
> radeon-$(CONFIG_ACPI) += radeon_acpi.o
>
> diff --git a/drivers/gpu/drm/radeon/radeon_fbdev.c
> b/drivers/gpu/drm/radeon/radeon_fbdev.c
> index fe76e29910ef..dcabe527f9c0 100644
> --- a/drivers/gpu/drm/radeon/radeon_fbdev.c
> +++ b/drivers/gpu/drm/radeon/radeon_fbdev.c
> @@ -24,6 +24,7 @@
> * David Airlie
> */
>
> +#include
> #include
> #include
> #include
> @@ -193,11 +194,9 @@ static const struct fb_ops radeon_fbdev_fb_ops = {
> DRM_FB_HELPER_DEFAULT_OPS,
> .fb_open = radeon_fbdev_fb_open,
> .fb_release = radeon_fbdev_fb_release,
> - .fb_read = drm_fb_helper_cfb_read,
> - .fb_write = drm_fb_helper_cfb_write,
> - .fb_fillrect = drm_fb_helper_cfb_fillrect,
> - .fb_copyarea = drm_fb_helper_cfb_copyarea,
> - .fb_imageblit = drm_fb_helper_cfb_imageblit,
> + .fb_fillrect = cfb_fillrect,
> + .fb_copyarea = cfb_copyarea,
> + .fb_imageblit = cfb_imageblit,
> .fb_destroy = radeon_fbdev_fb_destroy, };
>
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index 1decdcec0264..c5a8e25a4c97 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -939,7 +939,7 @@ void dce4_program_fmt(struct drm_encoder
> *encoder); void dce8_program_fmt(struct drm_encoder *encoder);
>
> /* fbdev layer */
> -#if defined(CONFIG_DRM_FBDEV_EMULATION)
> +#if defined(CONFIG_DRM_RADEON_FBDEV_EMULATION)
> void radeon_fbdev_setup(struct radeon_device *rdev); void
> radeon_fbdev_set_suspend(struct radeon_device *rdev, int state); bool
> radeon_fbdev_robj_is_fb(struct radeon_device *rdev, struct radeon_bo
> *robj);
> --
> 2.40.1
RE: [PATCH] radeon: avoid double free in ci_dpm_init()
[Public]
> -Original Message-
> From: Nikita Zhandarovich
> Sent: Monday, April 3, 2023 2:28 PM
> To: Deucher, Alexander
> Cc: Nikita Zhandarovich ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> ker...@vger.kernel.org; lvc-proj...@linuxtesting.org
> Subject: [PATCH] radeon: avoid double free in ci_dpm_init()
>
> There are several calls to ci_dpm_fini() in ci_dpm_init() when there occur
> errors in functions like r600_parse_extended_power_table().
> This is harmful as it can lead to double free situations: for instance,
> r600_parse_extended_power_table() will call for
> r600_free_extended_power_table() as will ci_dpm_fini(), both of which will
> try to free resources.
> Other drivers do not call *_dpm_fini functions from their respective
> *_dpm_init calls - neither should cpm_dpm_init().
>
> Fix this by removing extra calls to ci_dpm_fini().
You can't just drop the calls to fini(). You'll need to properly unwind to
avoid leaking memory.
Alex
>
> Found by Linux Verification Center (linuxtesting.org) with static analysis
> tool
> SVACE.
>
> Fixes: cc8dbbb4f62a ("drm/radeon: add dpm support for CI dGPUs (v2)")
> Cc: sta...@vger.kernel.org
> Co-developed-by: Natalia Petrova
> Signed-off-by: Nikita Zhandarovich
>
> ---
> drivers/gpu/drm/radeon/ci_dpm.c | 20 +---
> 1 file changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c
> b/drivers/gpu/drm/radeon/ci_dpm.c index 8ef25ab305ae..7b77d4c93f1d
> 100644
> --- a/drivers/gpu/drm/radeon/ci_dpm.c
> +++ b/drivers/gpu/drm/radeon/ci_dpm.c
> @@ -5677,28 +5677,20 @@ int ci_dpm_init(struct radeon_device *rdev)
> pi->pcie_lane_powersaving.min = 16;
>
> ret = ci_get_vbios_boot_values(rdev, >vbios_boot_state);
> - if (ret) {
> - ci_dpm_fini(rdev);
> + if (ret)
> return ret;
> - }
>
> ret = r600_get_platform_caps(rdev);
> - if (ret) {
> - ci_dpm_fini(rdev);
> + if (ret)
> return ret;
> - }
>
> ret = r600_parse_extended_power_table(rdev);
> - if (ret) {
> - ci_dpm_fini(rdev);
> + if (ret)
> return ret;
> - }
>
> ret = ci_parse_power_table(rdev);
> - if (ret) {
> - ci_dpm_fini(rdev);
> + if (ret)
> return ret;
> - }
>
> pi->dll_default_on = false;
> pi->sram_end = SMC_RAM_END;
> @@ -5749,10 +5741,8 @@ int ci_dpm_init(struct radeon_device *rdev)
> kcalloc(4,
> sizeof(struct
> radeon_clock_voltage_dependency_entry),
> GFP_KERNEL);
> - if (!rdev-
> >pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries) {
> - ci_dpm_fini(rdev);
> + if (!rdev-
> >pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries)
> return -ENOMEM;
> - }
> rdev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.count = 4;
> rdev-
> >pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[0].clk = 0;
> rdev-
> >pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[0].v = 0;
RE: [Regression bisected] v6.3-rc4 Error scheduling IBs after resume from hibernate
[Public] > -Original Message- > From: Julian Wollrath > Sent: Thursday, March 30, 2023 10:08 AM > To: dri-devel@lists.freedesktop.org > Cc: Huang, Tim ; Deucher, Alexander > > Subject: [Regression bisected] v6.3-rc4 Error scheduling IBs after resume > from hibernate > > Hi, > > on an AMD Ryzen 5 PRO 4650U / Renoir (amdgpu: added device > 1002:1636) I the screen basically freezes and I get the following errors with > kernel v6.3-rc4 > > [ 26.214541] amdgpu :03:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] > *ERROR* IB test failed on gfx_low (-110). > [ 26.379624] [drm] ring 0 timeout to preempt ib > [ 27.387884] amdgpu :03:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] > *ERROR* IB test failed on gfx_high (-110). > [ 27.392945] [drm:process_one_work] *ERROR* ib ring test failed (-110). > [ 27.400370] amdgpu :03:00.0: amdgpu: couldn't schedule ib on ring > > [ 27.400384] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling > IBs (-22) > [ 44.440532] amdgpu :03:00.0: amdgpu: failed to write reg 28b4 wait reg > 28c6 > [ 61.177118] amdgpu :03:00.0: amdgpu: failed to write reg 1a6f4 wait reg > 1a706 > [ 61.189275] amdgpu :03:00.0: amdgpu: couldn't schedule ib on ring > > [ 61.189286] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling > IBs (-22) > > I bisected the issue, the first bad commit is > b589626674de94d977e81c99bf7905872b991197 reverting it on top of v6.3-rc4 > also fixes the issue. Fixed in: https://patchwork.freedesktop.org/patch/529751/ Alex > > > Best regards, > Julian Wollrath > > -- > () ascii ribbon campaign - against html e-mail > /\- against proprietary attachments
RE: [PULL] drm-misc-next
[Public] > -Original Message- > From: dim-tools On Behalf Of > John Paul Adrian Glaubitz > Sent: Monday, January 23, 2023 10:01 AM > To: tzimmerm...@suse.de > Cc: tvrtko.ursu...@linux.intel.com; dim-to...@lists.freedesktop.org; > daniel.vet...@ffwll.ch; intel-...@lists.freedesktop.org; dri- > de...@lists.freedesktop.org; rodrigo.v...@intel.com; airl...@gmail.com > Subject: Re: [PULL] drm-misc-next > > Hi Thomas! > > > Driver Changes: > > > > * Remove obsolete drivers for userspace modesetting i810, mga, r128, > >savage, sis, tdfx, via > > Is the Rage 128 GPU still supported via the generic modesetting driver? > > I'm asking because, we're still supporting PowerMacs in Debian Ports of > which some of those are sporting a Rage 128 GPU. Similar question applies to > the > i810 GPU used in some old ThinkPads, for example. These are not KMS drivers. They are just the kernel component needed for 3D rendering. These drivers have nothing to do with driving the displays on these cards. For display support you need to use the old Xorg DDXs for these cards or the relevant non-DRM fbdev drivers. Alex > > Thanks, > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist >`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
RE: [PATCH AUTOSEL 6.1 20/20] amdgpu: fix build on non-DCN platforms.
[AMD Official Use Only - General] > -Original Message- > From: Sasha Levin > Sent: Tuesday, January 31, 2023 10:00 AM > To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org > Cc: Dave Airlie ; Sasha Levin ; > Wentland, Harry ; Li, Sun peng (Leo) > ; Siqueira, Rodrigo ; > Deucher, Alexander ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch; Li, Roman ; > Wang, Chao-kai (Stylon) ; Pillai, Aurabindo > ; Zuo, Jerry ; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: [PATCH AUTOSEL 6.1 20/20] amdgpu: fix build on non-DCN > platforms. > > From: Dave Airlie > > [ Upstream commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587 ] > > This fixes the build here locally on my 32-bit arm build. > > Signed-off-by: Dave Airlie > Signed-off-by: Sasha Levin This patch is only applicable to kernel 6.1.x and newer. Alex > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index 15b408e3a705..d756a606b5e2 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -9411,6 +9411,8 @@ static int amdgpu_dm_atomic_check(struct > drm_device *dev, > bool lock_and_validation_needed = false; > struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state; #if > defined(CONFIG_DRM_AMD_DC_DCN) > + struct drm_dp_mst_topology_mgr *mgr; > + struct drm_dp_mst_topology_state *mst_state; > struct dsc_mst_fairness_vars vars[MAX_PIPES]; #endif > > -- > 2.39.0
Re: [PATCH] drm/amdgpu: cleanup coding style in amdgpu_amdkfd_gpuvm.c
[Public]
Yeah, seems to be a mix. I don't have a strong opinion as long as it has MIT.
Alex
From: Kuehling, Felix
Sent: Tuesday, September 6, 2022 9:46 AM
To: Jingyu Wang ; Deucher, Alexander
; Koenig, Christian ; Pan,
Xinhui ; airl...@linux.ie ;
dan...@ffwll.ch
Cc: amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org ;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH] drm/amdgpu: cleanup coding style in amdgpu_amdkfd_gpuvm.c
Am 2022-09-05 um 04:38 schrieb Jingyu Wang:
> Fix everything checkpatch.pl complained about in amdgpu_amdkfd_gpuvm.c
>
> Signed-off-by: Jingyu Wang
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index cbd593f7d553..eff596c60c89 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: MIT
I'm not sure if this is correct. We've used "GPL-2.0 OR MIT" in KFD. In
amdgpu there is currently a mix of licenses. Alex, do you want to make a
call on a consistent one to use in amdgpu?
Other than that, this patch is
Reviewed-by: Felix Kuehling
> /*
>* Copyright 2014-2018 Advanced Micro Devices, Inc.
>*
> @@ -1612,6 +1613,7 @@ size_t amdgpu_amdkfd_get_available_memory(struct
> amdgpu_device *adev)
>uint64_t reserved_for_pt =
>ESTIMATE_PT_SIZE(amdgpu_amdkfd_total_mem_size);
>size_t available;
> +
>spin_lock(_mem_limit.mem_limit_lock);
>available = adev->gmc.real_vram_size
>- adev->kfd.vram_used_aligned
> @@ -2216,7 +2218,7 @@ int amdgpu_amdkfd_gpuvm_get_vm_fault_info(struct
> amdgpu_device *adev,
> {
>if (atomic_read(>gmc.vm_fault_info_updated) == 1) {
>*mem = *adev->gmc.vm_fault_info;
> - mb();
> + mb(); /* make sure read happened */
>atomic_set(>gmc.vm_fault_info_updated, 0);
>}
>return 0;
>
> base-commit: e47eb90a0a9ae20b82635b9b99a8d0979b757ad8
Re: [PATCH v2] drm/amd/display: fix indentation in commit_planes_for_stream()
[Public] Acked-by: Alex Deucher From: Mahfooz, Hamza Sent: Thursday, September 1, 2022 10:15 AM To: linux-ker...@vger.kernel.org Cc: Mahfooz, Hamza ; Wentland, Harry ; Li, Sun peng (Leo) ; Siqueira, Rodrigo ; Deucher, Alexander ; Koenig, Christian ; Pan, Xinhui ; David Airlie ; Daniel Vetter ; Kazlauskas, Nicholas ; Lei, Jun ; Somasundaram, Meenakshikumar ; Lee, Alvin ; Leung, Martin ; Tam, Samson ; Hung, Alex ; Liu, Wenjing ; Aberback, Joshua ; amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org Subject: [PATCH v2] drm/amd/display: fix indentation in commit_planes_for_stream() Address the following warning: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3508:9: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] 3508 | if (update_type != UPDATE_TYPE_FAST) | ^~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3510:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’ 3510 | if (update_type != UPDATE_TYPE_FAST) | ^~ Signed-off-by: Hamza Mahfooz --- v2: implement feedback from Alvin --- drivers/gpu/drm/amd/display/dc/core/dc.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c index b49237390cce..9860bf38c547 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c @@ -3507,9 +3507,10 @@ static void commit_planes_for_stream(struct dc *dc, if (update_type != UPDATE_TYPE_FAST) dc->hwss.post_unlock_program_front_end(dc, context); - if (update_type != UPDATE_TYPE_FAST) - if (dc->hwss.commit_subvp_config) - dc->hwss.commit_subvp_config(dc, context); + + if (update_type != UPDATE_TYPE_FAST) + if (dc->hwss.commit_subvp_config) + dc->hwss.commit_subvp_config(dc, context); /* Since phantom pipe programming is moved to post_unlock_program_front_end, * move the SubVP lock to after the phantom pipes have been setup -- 2.37.2
RE: [PATCH] drm/amd/display: fix indentation in commit_planes_for_stream()
[AMD Official Use Only - General]
> -Original Message-
> From: Mahfooz, Hamza
> Sent: Wednesday, August 31, 2022 1:58 PM
> To: linux-ker...@vger.kernel.org
> Cc: Mahfooz, Hamza ; Wentland, Harry
> ; Li, Sun peng (Leo) ;
> Siqueira, Rodrigo ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; Kazlauskas,
> Nicholas ; Lei, Jun ;
> Somasundaram, Meenakshikumar
> ; Lee, Alvin
> ; Leung, Martin ; Tam,
> Samson ; Hung, Alex ;
> Aberback, Joshua ; Liu, Wenjing
> ; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Subject: [PATCH] drm/amd/display: fix indentation in
> commit_planes_for_stream()
>
> Address the following warning:
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3508:9: warning: this
> ‘if’ clause does not guard... [-Wmisleading-indentation]
> 3508 | if (update_type != UPDATE_TYPE_FAST)
> | ^~
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3510:17: note: ...this
> statement, but the latter is misleadingly indented as if it were guarded by
> the
> ‘if’
> 3510 | if (update_type != UPDATE_TYPE_FAST)
> | ^~
>
> Signed-off-by: Hamza Mahfooz
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/dc/core/dc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index b49237390cce..6c4948916e7e 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -3505,11 +3505,11 @@ static void commit_planes_for_stream(struct dc
> *dc,
> top_pipe_to_program-
> >stream_res.tg);
> }
>
> - if (update_type != UPDATE_TYPE_FAST)
> + if (update_type != UPDATE_TYPE_FAST) {
> dc->hwss.post_unlock_program_front_end(dc, context);
> - if (update_type != UPDATE_TYPE_FAST)
> - if (dc->hwss.commit_subvp_config)
> - dc->hwss.commit_subvp_config(dc,
> context);
> + if (dc->hwss.commit_subvp_config)
> + dc->hwss.commit_subvp_config(dc, context);
> + }
>
> /* Since phantom pipe programming is moved to
> post_unlock_program_front_end,
>* move the SubVP lock to after the phantom pipes have been setup
> --
> 2.37.2
RE: [PATCH v3 2/3] drm/amdgpu_dm: Rely on split out luminance calculation function
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of Jani
> Nikula
> Sent: Thursday, August 4, 2022 5:55 AM
> To: Jouni Högander ; dri-
> de...@lists.freedesktop.org; intel-...@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org
> Cc: Siqueira, Rodrigo ; Li, Roman
> ; Manasi Navare ; Mika
> Kahola ; Jouni Högander
> ; Wentland, Harry
>
> Subject: Re: [PATCH v3 2/3] drm/amdgpu_dm: Rely on split out luminance
> calculation function
>
> On Tue, 19 Jul 2022, Jouni Högander wrote:
> > Luminance range calculation was split out into drm_edid.c and is now
> > part of edid parsing. Rely on values calculated during edid parsing
> > and use these for caps->aux_max_input_signal and caps-
> >aux_min_input_signal.
>
> Harry, I'll merge patches 1 & 3 in this series through drm-misc-next, because
> I
> think they're good to go, and fix stuff in i915.
>
> Can I get your rb/ack to merge this patch as well, or do you want to take this
> later via your tree?
You can take this via drm-misc.
Acked-by: Alex Deucher
>
> BR,
> Jani.
>
>
> >
> > v2: Use values calculated during edid parsing
> >
> > Cc: Roman Li
> > Cc: Rodrigo Siqueira
> > Cc: Harry Wentland
> > Cc: Lyude Paul
> > Cc: Mika Kahola
> > Cc: Jani Nikula
> > Cc: Manasi Navare
> > Signed-off-by: Jouni Högander
> > ---
> > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 35
> > +++
> > 1 file changed, 4 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 3e83fed540e8..eb7abdeb8653 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -2903,15 +2903,12 @@ static struct drm_mode_config_helper_funcs
> > amdgpu_dm_mode_config_helperfuncs = {
> >
> > static void update_connector_ext_caps(struct amdgpu_dm_connector
> > *aconnector) {
> > - u32 max_avg, min_cll, max, min, q, r;
> > struct amdgpu_dm_backlight_caps *caps;
> > struct amdgpu_display_manager *dm;
> > struct drm_connector *conn_base;
> > struct amdgpu_device *adev;
> > struct dc_link *link = NULL;
> > - static const u8 pre_computed_values[] = {
> > - 50, 51, 52, 53, 55, 56, 57, 58, 59, 61, 62, 63, 65, 66, 68, 69,
> > - 71, 72, 74, 75, 77, 79, 81, 82, 84, 86, 88, 90, 92, 94, 96, 98};
> > + struct drm_luminance_range_info *luminance_range;
> > int i;
> >
> > if (!aconnector || !aconnector->dc_link) @@ -2933,8 +2930,6 @@
> > static void update_connector_ext_caps(struct amdgpu_dm_connector
> *aconnector)
> > caps = >backlight_caps[i];
> > caps->ext_caps = >dc_link->dpcd_sink_ext_caps;
> > caps->aux_support = false;
> > - max_avg = conn_base->hdr_sink_metadata.hdmi_type1.max_fall;
> > - min_cll = conn_base->hdr_sink_metadata.hdmi_type1.min_cll;
> >
> > if (caps->ext_caps->bits.oled == 1 /*||
> > caps->ext_caps->bits.sdr_aux_backlight_control == 1 || @@
> > -2946,31 +2941,9 @@ static void update_connector_ext_caps(struct
> amdgpu_dm_connector *aconnector)
> > else if (amdgpu_backlight == 1)
> > caps->aux_support = true;
> >
> > - /* From the specification (CTA-861-G), for calculating the maximum
> > -* luminance we need to use:
> > -* Luminance = 50*2**(CV/32)
> > -* Where CV is a one-byte value.
> > -* For calculating this expression we may need float point precision;
> > -* to avoid this complexity level, we take advantage that CV is divided
> > -* by a constant. From the Euclids division algorithm, we know that
> CV
> > -* can be written as: CV = 32*q + r. Next, we replace CV in the
> > -* Luminance expression and get 50*(2**q)*(2**(r/32)), hence we
> just
> > -* need to pre-compute the value of r/32. For pre-computing the
> values
> > -* We just used the following Ruby line:
> > -* (0...32).each {|cv| puts (50*2**(cv/32.0)).round}
> > -* The results of the above expressions can be verified at
> > -* pre_computed_values.
> > -*/
> > - q = max_avg >> 5;
> > - r = max_avg % 32;
> > - max = (1 << q) * pre_computed_values[r];
> > -
> > - // min luminance: maxLum * (CV/255)^2 / 100
> > - q = DIV_ROUND_CLOSEST(min_cll, 255);
> > - min = max * DIV_ROUND_CLOSEST((q * q), 100);
> > -
> > - caps->aux_max_input_signal = max;
> > - caps->aux_min_input_signal = min;
> > + luminance_range = _base->display_info.luminance_range;
> > + caps->aux_min_input_signal = luminance_range->min_luminance;
> > + caps->aux_max_input_signal = luminance_range->max_luminance;
> > }
> >
> > void amdgpu_dm_update_connector_after_detect(
>
> --
> Jani Nikula, Intel Open Source Graphics Center
RE: [PATCH] drm: amd: amdgpu: fix checkpatch warnings
[AMD Official Use Only - General]
> -Original Message-
> From: Deucher, Alexander
> Sent: Monday, June 27, 2022 2:18 PM
> To: Vijendar Mukunda ; broo...@kernel.org;
> alsa-de...@alsa-project.org; dri-devel@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org
> Cc: Dommati, Sunil-kumar ; David Airlie
> ; Hiregoudar, Basavaraj ;
> Pan, Xinhui ; open list ker...@vger.kernel.org>; Kai-Heng Feng ;
> Daniel Vetter ; Mukunda, Vijendar
> ; Koenig, Christian
>
> Subject: RE: [PATCH] drm: amd: amdgpu: fix checkpatch warnings
>
> [AMD Official Use Only - General]
>
> > -Original Message-
> > From: amd-gfx On Behalf Of
> > Vijendar Mukunda
> > Sent: Monday, June 27, 2022 8:59 AM
> > To: broo...@kernel.org; alsa-de...@alsa-project.org; dri-
> > de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> > Cc: Dommati, Sunil-kumar ; David Airlie
> > ; Hiregoudar, Basavaraj
> > ; Pan, Xinhui ;
> open
> > list ; Kai-Heng Feng
> > ; Daniel Vetter ;
> > Mukunda, Vijendar ; Deucher, Alexander
> > ; Koenig, Christian
> >
> > Subject: [PATCH] drm: amd: amdgpu: fix checkpatch warnings
> >
> > From: vijendar
> >
> > Fixed below checkpatch warnings and errors
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:131: CHECK: Comparison to
> NULL
> > could be written "apd"
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:150: CHECK: Comparison to
> NULL
> > could be written "apd"
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:196: CHECK: Prefer kernel
> type
> > 'u64' over 'uint64_t'
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:224: CHECK: Please don't use
> > multiple blank lines
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:226: CHECK: Comparison to
> NULL
> > could be written "!adev->acp.acp_genpd"
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:233: CHECK: Please don't use
> > multiple blank lines
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:239: CHECK: Alignment
> should
> > match open parenthesis
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:241: CHECK: Comparison to
> NULL
> > could be written "!adev->acp.acp_cell"
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:247: CHECK: Comparison to
> NULL
> > could be written "!adev->acp.acp_res"
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:253: CHECK: Comparison to
> NULL
> > could be written "!i2s_pdata"
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:350: CHECK: Alignment
> should
> > match open parenthesis
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:550: ERROR: that open brace
> {
> > should be on the previous line
> >
> > Signed-off-by: Vijendar Mukunda
>
> Reviewed-by: Alex Deucher
>
I'm also fine to have this go through the audio tree if it is a pre-requisite
for your jadeite audio series.
Alex
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 27
> > +
> > 1 file changed, 10 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> > index cc9c9f8b23b2..ba1605ff521f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> > @@ -128,7 +128,7 @@ static int acp_poweroff(struct generic_pm_domain
> > *genpd)
> > struct amdgpu_device *adev;
> >
> > apd = container_of(genpd, struct acp_pm_domain, gpd);
> > - if (apd != NULL) {
> > + if (apd) {
> > adev = apd->adev;
> > /* call smu to POWER GATE ACP block
> > * smu will
> > @@ -147,7 +147,7 @@ static int acp_poweron(struct generic_pm_domain
> > *genpd)
> > struct amdgpu_device *adev;
> >
> > apd = container_of(genpd, struct acp_pm_domain, gpd);
> > - if (apd != NULL) {
> > + if (apd) {
> > adev = apd->adev;
> > /* call smu to UNGATE ACP block
> > * smu will
> > @@ -193,7 +193,7 @@ static int acp_genpd_remove_device(struct device
> > *dev, void *data) static int acp_hw_init(void *handle) {
> > int r;
> > - uint64_t acp_base;
> > + u64 acp_base;
> > u32 val = 0;
> > u32 count = 0;
> > struct i2s_platform_data *i2s_pdata = NULL; @@ -220,37 +220,32
> @@
> > static int acp_hw_init(void *handle)
> > return -EINVAL;
> >
> > acp_base = adev->rmmio_base;
> > -
> > -
> > adev->acp.acp_genpd = kzalloc(sizeof(struct acp_pm_domain),
> > GFP_KERNEL);
> >
RE: [PATCH] drm: amd: amdgpu: fix checkpatch warnings
[AMD Official Use Only - General]
> -Original Message-
> From: amd-gfx On Behalf Of
> Vijendar Mukunda
> Sent: Monday, June 27, 2022 8:59 AM
> To: broo...@kernel.org; alsa-de...@alsa-project.org; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: Dommati, Sunil-kumar ; David Airlie
> ; Hiregoudar, Basavaraj ;
> Pan, Xinhui ; open list ker...@vger.kernel.org>; Kai-Heng Feng ;
> Daniel Vetter ; Mukunda, Vijendar
> ; Deucher, Alexander
> ; Koenig, Christian
>
> Subject: [PATCH] drm: amd: amdgpu: fix checkpatch warnings
>
> From: vijendar
>
> Fixed below checkpatch warnings and errors
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:131: CHECK: Comparison to
> NULL could be written "apd"
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:150: CHECK: Comparison to
> NULL could be written "apd"
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:196: CHECK: Prefer kernel
> type 'u64' over 'uint64_t'
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:224: CHECK: Please don't use
> multiple blank lines
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:226: CHECK: Comparison to
> NULL could be written "!adev->acp.acp_genpd"
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:233: CHECK: Please don't use
> multiple blank lines
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:239: CHECK: Alignment should
> match open parenthesis
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:241: CHECK: Comparison to
> NULL could be written "!adev->acp.acp_cell"
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:247: CHECK: Comparison to
> NULL could be written "!adev->acp.acp_res"
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:253: CHECK: Comparison to
> NULL could be written "!i2s_pdata"
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:350: CHECK: Alignment should
> match open parenthesis
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c:550: ERROR: that open brace {
> should be on the previous line
>
> Signed-off-by: Vijendar Mukunda
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 27 +
> 1 file changed, 10 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> index cc9c9f8b23b2..ba1605ff521f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> @@ -128,7 +128,7 @@ static int acp_poweroff(struct generic_pm_domain
> *genpd)
> struct amdgpu_device *adev;
>
> apd = container_of(genpd, struct acp_pm_domain, gpd);
> - if (apd != NULL) {
> + if (apd) {
> adev = apd->adev;
> /* call smu to POWER GATE ACP block
>* smu will
> @@ -147,7 +147,7 @@ static int acp_poweron(struct generic_pm_domain
> *genpd)
> struct amdgpu_device *adev;
>
> apd = container_of(genpd, struct acp_pm_domain, gpd);
> - if (apd != NULL) {
> + if (apd) {
> adev = apd->adev;
> /* call smu to UNGATE ACP block
>* smu will
> @@ -193,7 +193,7 @@ static int acp_genpd_remove_device(struct device
> *dev, void *data) static int acp_hw_init(void *handle) {
> int r;
> - uint64_t acp_base;
> + u64 acp_base;
> u32 val = 0;
> u32 count = 0;
> struct i2s_platform_data *i2s_pdata = NULL; @@ -220,37 +220,32
> @@ static int acp_hw_init(void *handle)
> return -EINVAL;
>
> acp_base = adev->rmmio_base;
> -
> -
> adev->acp.acp_genpd = kzalloc(sizeof(struct acp_pm_domain),
> GFP_KERNEL);
> - if (adev->acp.acp_genpd == NULL)
> + if (!adev->acp.acp_genpd)
> return -ENOMEM;
>
> adev->acp.acp_genpd->gpd.name = "ACP_AUDIO";
> adev->acp.acp_genpd->gpd.power_off = acp_poweroff;
> adev->acp.acp_genpd->gpd.power_on = acp_poweron;
> -
> -
> adev->acp.acp_genpd->adev = adev;
>
> pm_genpd_init(>acp.acp_genpd->gpd, NULL, false);
>
> - adev->acp.acp_cell = kcalloc(ACP_DEVS, sizeof(struct mfd_cell),
> - GFP_KERNEL);
> + adev->acp.acp_cell = kcalloc(ACP_DEVS, sizeof(struct mfd_cell),
> +GFP_KERNEL);
>
> - if (adev->acp.acp_cell == NULL) {
> + if (!adev->acp.acp_cell) {
> r = -ENOMEM;
> goto failure;
> }
>
> adev->acp.acp_res = kcalloc(5, sizeof(struct resource), GFP_KERNEL);
> - if (adev->acp.acp_res == NULL) {
> + if (!adev->acp.acp_res) {
> r = -ENOMEM;
>
Re: [PATCH AUTOSEL 5.17 13/23] drm/amd/display: undo clearing of z10 related function pointers
[Public]
DCN 3.1.6 needs it, but I don't know if yellow carp needs it. I think this is
only applicable to kernel 5.18. @Kazlauskas,
Nicholas<mailto:nicholas.kazlaus...@amd.com> can you verify?
Alex
From: VURDIGERENATARAJ, CHANDAN
Sent: Wednesday, May 18, 2022 8:36 AM
To: Sasha Levin ; linux-ker...@vger.kernel.org
; sta...@vger.kernel.org
Cc: Yang, Eric ; haonan.wa...@amd.com
; Li, Sun peng (Leo) ; Pan, Xinhui
; Siqueira, Rodrigo ;
amd-...@lists.freedesktop.org ; Koenig,
Christian ; airl...@linux.ie ;
dri-devel@lists.freedesktop.org ;
dan...@ffwll.ch ; wyatt.w...@amd.com ;
Deucher, Alexander ; mikita.lip...@amd.com
; Wentland, Harry ; Kazlauskas,
Nicholas ; Kotarac, Pavle
Subject: RE: [PATCH AUTOSEL 5.17 13/23] drm/amd/display: undo clearing of z10
related function pointers
Hi,
Is S0i3 verified for DCN 3.1.6 with this?
BR,
Chandan V N
>From: Eric Yang
>
>[ Upstream commit 9b9bd3f640640f94272a461b2dfe558f91b322c5 ]
>
> [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
>Acked-by: Pavle Kotarac
>Signed-off-by: Eric Yang
>Signed-off-by: Alex Deucher
>Signed-off-by: Sasha Levin
>---
> drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c | 5 -
> 1 file changed, 5 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c
>b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c
>index d7559e5a99ce..e708f07fe75a 100644
>--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c
>+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c
>@@ -153,9 +153,4 @@ void dcn31_hw_sequencer_construct(struct dc *dc)
>dc->hwss.init_hw = dcn20_fpga_init_hw;
>dc->hwseq->funcs.init_pipes = NULL;
>}
>- if (dc->debug.disable_z10) {
>- /*hw not support z10 or sw disable it*/
>- dc->hwss.z10_restore = NULL;
>- dc->hwss.z10_save_init = NULL;
>- }
> }
>--
>2.35.1
>
RE: RX 5500 XT: PCIe link speed stuck at Gen1 2.5GT/s by default
[Public] > -Original Message- > From: Bjorn Helgaas > Sent: Wednesday, March 30, 2022 7:45 AM > To: linux-...@vger.kernel.org > Cc: Deucher, Alexander ; Robert Hancock > ; dri-devel@lists.freedesktop.org > Subject: RX 5500 XT: PCIe link speed stuck at Gen1 2.5GT/s by default > > See > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.f > reedesktop.org%2Fdrm%2Famd%2F- > %2Fissues%2F1447data=04%7C01%7Calexander.deucher%40amd.com > %7C01b4e1eed4ac4c97ab0408da1242abe9%7C3dd8961fe4884e608e11a82 > d994e183d%7C0%7C0%7C637842374822556101%7CUnknown%7CTWFpbGZ > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn > 0%3D%7C3000sdata=elFgBq%2FoCfqIO98aaGeS3d1omBdJj%2BSH6HO > 13oNaBWM%3Dreserved=0 > > This report was against DRM, but I'm mentioning it here because we've been > talking about some link speed init issues lately, and AFAICT the gitlab > reports > don't show up anywhere in lore. > Just noticed this. The GPU driver calls pcie_bandwidth_available() to get the speed and link widths of the link to root port. The driver then limits the link speed and number of lanes to the max available on the link. There's no reason to run the link faster than the slowest link in the chain. For the most part this works fine because I think the PCIe spec envisions that the links will negotiate the fastest link available when the system comes up. But it seems that some platforms don't always do this. Maybe pcie_bandwidth_available() should return the max bandwidth based on the caps of the links rather than the current status. That said, I'm not sure how you would differentiate between the platforms that came up in a slow link t save power vs platforms that came up in a slow link because there was some problem negotiating a faster link or who, if anyone would be responsible for making sure the links are upgraded when needed. Alex > Robert Hancock reported: > > > I'm using a RX 5500 XT card on an Asus PRIME H270-PRO motherboard, > > Intel i5-7500 CPU, with kernel 5.10.9 under Fedora 33. I noticed that > > in Linux, "lspci -vv" always showed the GPU PCIe link running at > > 2.5GT/s link speed and never seemed to change regardless of the > > application being run, while in Windows, GPU-Z shows the link running > > at the max supported 8GT/s speed when under graphical load. > > > > It seems like the driver thinks that 2.5GT/s is the max allowable > > speed, based on the pp_dpm_pcie file: > > > > > cd > /sys/devices/pci:00/:00:01.0/:01:00.0/:02:00.0/:0 > 3:00.0/ > > > cat pp_dpm_pcie > > 0: 2.5GT/s, x8 81Mhz * > > 1: 2.5GT/s, x8 619Mhz * > > > > I'm assuming that something is going wrong with the PCIe link speed > > detection in the driver. Using the "amdgpu.pcie_gen_cap=0x70007" > > kernel command line option seems to result in the driver detecting the > > proper 8GT/s maximum speed. > > > > lspci -vv output from booting without overriding the speed is > > attached.
RE: [Bug 215958] New: thunderbolt3 egpu cannot disconnect cleanly
[Public] > -Original Message- > From: Bjorn Helgaas > Sent: Monday, May 9, 2022 12:23 PM > To: Linux PCI > Cc: r087...@yahoo.it; Deucher, Alexander > ; Koenig, Christian > ; Pan, Xinhui ; amd-gfx > mailing list ; dri-devel de...@lists.freedesktop.org> > Subject: Re: [Bug 215958] New: thunderbolt3 egpu cannot disconnect cleanly > > On Sun, May 8, 2022 at 3:29 PM wrote: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugz > > > illa.kernel.org%2Fshow_bug.cgi%3Fid%3D215958data=05%7C01%7Cal > exan > > > der.deucher%40amd.com%7C8bb8567427844b05e5f808da31d8435f%7C3d > d8961fe48 > > > 84e608e11a82d994e183d%7C0%7C0%7C637877102168668221%7CUnkno > wn%7CTWFpbGZ > > > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn > 0%3 > > > D%7C3000%7C%7C%7Csdata=PpcDBIpUW8vCX%2F4kM6Q8RjdgS1qw2 > uuWoWZXis4M > > dDQ%3Dreserved=0 > > > > Bug ID: 215958 > >Summary: thunderbolt3 egpu cannot disconnect cleanly > >Product: Drivers > >Version: 2.5 > > Kernel Version: 5.17.0-1003-oem #3-Ubuntu SMP PREEMPT > > Hardware: All > > OS: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: PCI > > Assignee: drivers_...@kernel-bugs.osdl.org > > Reporter: r087...@yahoo.it > > Regression: No > > I assume this is not a regression, right? If it is a regression, what > previous > kernel worked correctly? > > > I have an external egpu (Radeon 6600 RX) connected through > > thunderbolt3 to my Thinkpad X1 carbon 6th Gen.. When I disconnect the > > thunderbolt3 cable I get the following error in dmesg: > > > > [21874.194994] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.195006] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.195123] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.195129] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.195271] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.195276] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.195406] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.195411] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.195544] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:51 param:0x message:GetPptLimit? > > [21874.195550] amdgpu :0c:00.0: amdgpu: > > [smu_v11_0_get_current_power_limit] > > get PPT limit failed! > > [21874.195582] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.195587] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.227454] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.227463] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.227532] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.227536] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.227618] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.227621] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.227700] amdgpu :0c:00.0: amdgpu: SMU: > response:0x > > for > > index:18 param:0x0005 message:TransferTableSmu2Dram? > > [21874.227703] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.227784] amdgpu :0c:00.0: amdgpu: > > [smu_v11_0_get_current_power_limit] > > get PPT limit failed! > > [21874.227804] amdgpu :0c:00.0: amdgpu: Failed to export SMU > metrics table! > > [21874.514661] snd_hda_codec_hdmi hdaudioC1D0: Unable to sync > register > > 0x2f0d00. -5 [21874.568360] amdg
Re: [RFC v4 02/11] drm/amdgpu: Move scheduler init to after XGMI is ready
[Public]
If it applies cleanly, feel free to drop it in. I'll drop those patches for
drm-next since they are already in drm-misc.
Alex
From: amd-gfx on behalf of Andrey
Grodzovsky
Sent: Thursday, February 24, 2022 11:24 AM
To: Chen, JingWen ; Christian König
; dri-devel@lists.freedesktop.org
; amd-...@lists.freedesktop.org
Cc: Liu, Monk ; Chen, Horace ; Lazar,
Lijo ; Koenig, Christian ;
dan...@ffwll.ch
Subject: Re: [RFC v4 02/11] drm/amdgpu: Move scheduler init to after XGMI is
ready
No because all the patch-set including this patch was landed into
drm-misc-next and will reach amd-staging-drm-next on the next upstream
rebase i guess.
Andrey
On 2022-02-24 01:47, JingWen Chen wrote:
> Hi Andrey,
>
> Will you port this patch into amd-staging-drm-next?
>
> on 2/10/22 2:06 AM, Andrey Grodzovsky wrote:
>> All comments are fixed and code pushed. Thanks for everyone
>> who helped reviewing.
>>
>> Andrey
>>
>> On 2022-02-09 02:53, Christian König wrote:
>>> Am 09.02.22 um 01:23 schrieb Andrey Grodzovsky:
Before we initialize schedulers we must know which reset
domain are we in - for single device there iis a single
domain per device and so single wq per device. For XGMI
the reset domain spans the entire XGMI hive and so the
reset wq is per hive.
Signed-off-by: Andrey Grodzovsky
>>> One more comment below, with that fixed Reviewed-by: Christian König
>>> .
>>>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 45 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 34 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 +
3 files changed, 51 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 9704b0e1fd82..00123b0013d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2287,6 +2287,47 @@ static int amdgpu_device_fw_loading(struct
amdgpu_device *adev)
return r;
}
+static int amdgpu_device_init_schedulers(struct amdgpu_device *adev)
+{
+long timeout;
+int r, i;
+
+for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
+struct amdgpu_ring *ring = adev->rings[i];
+
+/* No need to setup the GPU scheduler for rings that don't need
it */
+if (!ring || ring->no_scheduler)
+continue;
+
+switch (ring->funcs->type) {
+case AMDGPU_RING_TYPE_GFX:
+timeout = adev->gfx_timeout;
+break;
+case AMDGPU_RING_TYPE_COMPUTE:
+timeout = adev->compute_timeout;
+break;
+case AMDGPU_RING_TYPE_SDMA:
+timeout = adev->sdma_timeout;
+break;
+default:
+timeout = adev->video_timeout;
+break;
+}
+
+r = drm_sched_init(>sched, _sched_ops,
+ ring->num_hw_submission, amdgpu_job_hang_limit,
+ timeout, adev->reset_domain.wq, ring->sched_score,
ring->name);
+if (r) {
+DRM_ERROR("Failed to create scheduler on ring %s.\n",
+ ring->name);
+return r;
+}
+}
+
+return 0;
+}
+
+
/**
* amdgpu_device_ip_init - run init for hardware IPs
*
@@ -2419,6 +2460,10 @@ static int amdgpu_device_ip_init(struct
amdgpu_device *adev)
}
}
+r = amdgpu_device_init_schedulers(adev);
+if (r)
+goto init_failed;
+
/* Don't init kfd if whole hive need to be reset during init */
if (!adev->gmc.xgmi.pending_reset)
amdgpu_amdkfd_device_init(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 45977a72b5dd..fa302540c69a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -457,8 +457,6 @@ int amdgpu_fence_driver_init_ring(struct amdgpu_ring
*ring,
atomic_t *sched_score)
{
struct amdgpu_device *adev = ring->adev;
-long timeout;
-int r;
if (!adev)
return -EINVAL;
@@ -478,36 +476,12 @@ int amdgpu_fence_driver_init_ring(struct amdgpu_ring
*ring,
spin_lock_init(>fence_drv.lock);
ring->fence_drv.fences = kcalloc(num_hw_submission * 2, sizeof(void
*),
GFP_KERNEL);
-if (!ring->fence_drv.fences)
-return -ENOMEM;
-/* No need to setup the GPU scheduler for rings that
RE: [PATCH v4 00/10] Add MEMORY_DEVICE_COHERENT for coherent device memory mapping
[Public] > -Original Message- > From: Sierra Guiza, Alejandro (Alex) > Sent: Thursday, January 27, 2022 6:21 PM > To: Andrew Morton > Cc: Kuehling, Felix ; linux...@kvack.org; > rcampb...@nvidia.com; linux-e...@vger.kernel.org; linux- > x...@vger.kernel.org; amd-...@lists.freedesktop.org; dri- > de...@lists.freedesktop.org; h...@lst.de; j...@nvidia.com; > jgli...@redhat.com; apop...@nvidia.com; wi...@infradead.org; Deucher, > Alexander > Subject: Re: [PATCH v4 00/10] Add MEMORY_DEVICE_COHERENT for > coherent device memory mapping > > Andrew, > We're somehow new on this procedure. Are you referring to rebase this > patch series to git://git.kernel.org/pub/scm/linux/kernel/git/next/linux- > next.git > <5.17-rc1 tag>? > > Regards, > Alex Sierra > > Alex Deucher, > Just a quick heads up. This patch series contains changes to the amdgpu > driver which we're planning to merge through Andrew's tree, If that's ok with > you. No problem. Thanks! Alex > > Regards, > Alex Sierra > > On 1/27/2022 4:32 PM, Andrew Morton wrote: > > On Wed, 26 Jan 2022 21:09:39 -0600 Alex Sierra > wrote: > > > >> This patch series introduces MEMORY_DEVICE_COHERENT, a type of > memory > >> owned by a device that can be mapped into CPU page tables like > >> MEMORY_DEVICE_GENERIC and can also be migrated like > >> MEMORY_DEVICE_PRIVATE. > > Some more reviewer input appears to be desirable here. > > > > I was going to tentatively add it to -mm and -next, but problems. > > 5.17-rc1's mm/migrate.c:migrate_vma_check_page() is rather different > > from the tree you patched. Please redo, refresh and resend? > >
Re: [PATCH v2 1/28] drm/amdgpu: fix that issue that the number of the crtc of the 3250c is not correct
[Public]
Reviewed-by: Alex Deucher
From: RyanLin
Sent: Thursday, January 27, 2022 10:47 PM
To: Wentland, Harry ; Li, Sun peng (Leo)
; Deucher, Alexander ; Koenig,
Christian ; david1.z...@amd.com
; airl...@linux.ie ; dan...@ffwll.ch
; seanp...@chromium.org ;
b...@basnieuwenhuizen.nl ; Kazlauskas, Nicholas
; sas...@kernel.org ;
markyac...@google.com ; victorchengchi...@amd.com
; ching-shih...@amd.corp-partner.google.com
; Siqueira, Rodrigo
; ddavenp...@chromium.org ;
amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org ;
linux-ker...@vger.kernel.org ; Li, Leon
Cc: Lin, Tsung-hua (Ryan)
Subject: [PATCH v2 1/28] drm/amdgpu: fix that issue that the number of the crtc
of the 3250c is not correct
v2:
- remove unnecessary comments and Id
[Why]
External displays take priority over internal display when there are fewer
display controllers than displays.
[How]
The root cause is because of that number of the crtc is not correct.
The number of the crtc on the 3250c is 3, but on the 3500c is 4.
>From the source code, we can see that number of the crtc has been fixed at 4.
Needs to set the num_crtc to 3 for 3250c platform.
Signed-off-by: RyanLin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 40c91b448f7d..455a2c45e8cd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2738,9 +2738,15 @@ static int dm_early_init(void *handle)
break;
#if defined(CONFIG_DRM_AMD_DC_DCN1_0)
case CHIP_RAVEN:
- adev->mode_info.num_crtc = 4;
- adev->mode_info.num_hpd = 4;
- adev->mode_info.num_dig = 4;
+ if (adev->rev_id >= 8) {
+ adev->mode_info.num_crtc = 3;
+ adev->mode_info.num_hpd = 3;
+ adev->mode_info.num_dig = 3;
+ } else {
+ adev->mode_info.num_crtc = 4;
+ adev->mode_info.num_hpd = 4;
+ adev->mode_info.num_dig = 4;
+ }
break;
#endif
#if defined(CONFIG_DRM_AMD_DC_DCN2_0)
--
2.25.1
Re: [PATCH] drm/amd/display: Fix memory leak
[Public]
Applied. Thanks!
From: Wentland, Harry
Sent: Friday, January 21, 2022 2:03 PM
To: Yongzhi Liu ; Li, Sun peng (Leo) ;
Siqueira, Rodrigo ; Deucher, Alexander
; Koenig, Christian ; Pan,
Xinhui ; airl...@linux.ie ;
dan...@ffwll.ch ; Lipski, Mikita ; Lin,
Wayne ; Kazlauskas, Nicholas ;
Zuo, Jerry ; anson.ja...@amd.com ;
eryk.b...@amd.com ; Pillai, Aurabindo
; Das, Nirmoy
Cc: amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org ;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH] drm/amd/display: Fix memory leak
On 2022-01-21 06:26, Yongzhi Liu wrote:
> [why]
> Resource release is needed on the error handling path
> to prevent memory leak.
>
> [how]
> Fix this by adding kfree on the error handling path.
>
> Signed-off-by: Yongzhi Liu
Reviewed-by: Harry Wentland
Harry
> ---
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 80
> --
> 1 file changed, 60 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index ded64d0..e463d46 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -227,8 +227,10 @@ static ssize_t dp_link_settings_read(struct file *f,
> char __user *buf,
>break;
>
>r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
>return r; /* r = -EFAULT */
> + }
>
>buf += 1;
>size -= 1;
> @@ -389,8 +391,10 @@ static ssize_t dp_phy_settings_read(struct file *f, char
> __user *buf,
>break;
>
>r = put_user((*(rd_buf + result)), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
>return r; /* r = -EFAULT */
> + }
>
>buf += 1;
>size -= 1;
> @@ -1359,8 +1363,10 @@ static ssize_t dp_dsc_clock_en_read(struct file *f,
> char __user *buf,
>break;
>}
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
>return -ENXIO;
> + }
>
>dsc = pipe_ctx->stream_res.dsc;
>if (dsc)
> @@ -1376,8 +1382,10 @@ static ssize_t dp_dsc_clock_en_read(struct file *f,
> char __user *buf,
>break;
>
>r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
>return r; /* r = -EFAULT */
> + }
>
>buf += 1;
>size -= 1;
> @@ -1546,8 +1554,10 @@ static ssize_t dp_dsc_slice_width_read(struct file *f,
> char __user *buf,
>break;
>}
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
>return -ENXIO;
> + }
>
>dsc = pipe_ctx->stream_res.dsc;
>if (dsc)
> @@ -1563,8 +1573,10 @@ static ssize_t dp_dsc_slice_width_read(struct file *f,
> char __user *buf,
>break;
>
>r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
>return r; /* r = -EFAULT */
> + }
>
>buf += 1;
>size -= 1;
> @@ -1731,8 +1743,10 @@ static ssize_t dp_dsc_slice_height_read(struct file
> *f, char __user *buf,
>break;
>}
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
>return -ENXIO;
> + }
>
>dsc = pipe_ctx->stream_res.dsc;
>if (dsc)
> @@ -1748,8 +1762,10 @@ static ssize_t dp_dsc_slice_height_read(struct file
> *f, char __user *buf,
>break;
>
>r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
>return r; /* r = -EFAULT */
> + }
>
>buf += 1;
>size -= 1;
> @@ -1912,8 +1928,10 @@ static ssize_t dp_dsc_bits_per_pixel_read(struct file
> *f, char __user *buf,
>break;
>}
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
>return -ENXIO;
Re: [PATCH 1/1] Add available memory ioctl for libhsakmt
[Public]
This is missing your signed-off-by. Additionally, for UAPI changes, we need a
link the patches for the userspace component that will make use of it.
Alex
From: amd-gfx on behalf of Daniel
Phillips
Sent: Monday, January 10, 2022 3:54 PM
To: amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org
Cc: Phillips, Daniel
Subject: [PATCH 1/1] Add available memory ioctl for libhsakmt
From: Daniel Phillips
Add an ioctl to inquire memory available for allocation by libhsakmt
per node, allowing for space consumed by page translation tables.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 +
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c| 14 ++
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c| 17 +
include/uapi/linux/kfd_ioctl.h | 14 --
4 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index fcbc8a9c9e06..64c6c36685d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -266,6 +266,7 @@ int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct
amdgpu_device *adev,
void amdgpu_amdkfd_gpuvm_release_process_vm(struct amdgpu_device *adev,
void *drm_priv);
uint64_t amdgpu_amdkfd_gpuvm_get_process_page_dir(void *drm_priv);
+size_t amdgpu_amdkfd_get_available_memory(struct amdgpu_device *adev);
int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
struct amdgpu_device *adev, uint64_t va, uint64_t size,
void *drm_priv, struct kgd_mem **mem,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 86a1a6c109d9..b7490a659173 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -190,6 +190,20 @@ static int amdgpu_amdkfd_reserve_mem_limit(struct
amdgpu_device *adev,
return ret;
}
+size_t amdgpu_amdkfd_get_available_memory(struct amdgpu_device *adev)
+{
+ uint64_t reserved_for_pt =
+ ESTIMATE_PT_SIZE(amdgpu_amdkfd_total_mem_size);
+ size_t available_memory;
+
+ spin_lock(_mem_limit.mem_limit_lock);
+ available_memory =
+ adev->gmc.real_vram_size -
+ adev->kfd.vram_used - reserved_for_pt;
+ spin_unlock(_mem_limit.mem_limit_lock);
+ return available_memory;
+}
+
static void unreserve_mem_limit(struct amdgpu_device *adev,
uint64_t size, u32 alloc_flag)
{
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 4bfc0c8ab764..5c2f6d97ff1c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -486,6 +486,20 @@ static int kfd_ioctl_get_queue_wave_state(struct file
*filep,
return r;
}
+static int kfd_ioctl_get_available_memory(struct file *filep,
+struct kfd_process *p, void *data)
+{
+ struct kfd_ioctl_get_available_memory_args *args = data;
+ struct kfd_dev *dev;
+
+ dev = kfd_device_by_id(args->gpu_id);
+ if (!dev)
+ return -EINVAL;
+
+ args->available = amdgpu_amdkfd_get_available_memory(dev->adev);
+ return 0;
+}
+
static int kfd_ioctl_set_memory_policy(struct file *filep,
struct kfd_process *p, void *data)
{
@@ -1959,6 +1973,9 @@ static const struct amdkfd_ioctl_desc amdkfd_ioctls[] = {
AMDKFD_IOCTL_DEF(AMDKFD_IOC_SET_XNACK_MODE,
kfd_ioctl_set_xnack_mode, 0),
+
+ AMDKFD_IOCTL_DEF(AMDKFD_IOC_AVAILABLE_MEMORY,
+ kfd_ioctl_get_available_memory, 0),
};
#define AMDKFD_CORE_IOCTL_COUNT ARRAY_SIZE(amdkfd_ioctls)
diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/kfd_ioctl.h
index af96af174dc4..94a99add2432 100644
--- a/include/uapi/linux/kfd_ioctl.h
+++ b/include/uapi/linux/kfd_ioctl.h
@@ -32,9 +32,10 @@
* - 1.4 - Indicate new SRAM EDC bit in device properties
* - 1.5 - Add SVM API
* - 1.6 - Query clear flags in SVM get_attr API
+ * - 1.7 - Add available_memory ioctl
*/
#define KFD_IOCTL_MAJOR_VERSION 1
-#define KFD_IOCTL_MINOR_VERSION 6
+#define KFD_IOCTL_MINOR_VERSION 7
struct kfd_ioctl_get_version_args {
__u32 major_version;/* from KFD */
@@ -98,6 +99,12 @@ struct kfd_ioctl_get_queue_wave_state_args {
__u32 pad;
};
+struct kfd_ioctl_get_available_memory_args {
+ __u64 available;/* from KFD */
+ __u32 gpu_id; /* to KFD */
+ __u32 pad;
+};
+
/* For kfd_ioctl_set_memory_policy_args.default_policy and alternate_policy */
#define KFD_IOC_CACHE_POLICY_COHERENT 0
#define KFD_IOC_CACHE_POLICY_NONCOHERENT 1
@@ -742,7 +749,10 @@ struct kfd_ioctl_set_xnack_mode_args {
#define
RE: [PATCH] drm/amd/pm: And destination bounds checking to struct copy
[Public]
> -Original Message-
> From: Koenig, Christian
> Sent: Monday, August 23, 2021 3:02 PM
> To: Kees Cook ; Lazar, Lijo
>
> Cc: Pan, Xinhui ; David Airlie ;
> Daniel Vetter ; Zhang, Hawking
> ; Xu, Feifei ; Gao, Likun
> ; Gu, JiaWei (Will) ; Quan,
> Evan ; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; Deucher, Alexander
> ; Tuikov, Luben
> ; Grodzovsky, Andrey
> ; Li, Dennis ;
> Sundararaju, Sathishkumar ; Kim,
> Jonathan ; Wang, Kevin(Yang)
> ; Nieto, David M ; Feng,
> Kenneth ; Lee Jones ;
> Clements, John ; linux-ker...@vger.kernel.org;
> linux-harden...@vger.kernel.org
> Subject: Re: [PATCH] drm/amd/pm: And destination bounds checking to
> struct copy
>
> Am 23.08.21 um 16:23 schrieb Kees Cook:
> >
> > On August 22, 2021 11:28:54 PM PDT, "Christian König"
> wrote:
> >>
> >> Am 19.08.21 um 22:14 schrieb Kees Cook:
> >>> [...]
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >>> index 96e895d6be35..4605934a4fb7 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >>> @@ -1446,4 +1446,29 @@ static inline int amdgpu_in_reset(struct
> amdgpu_device *adev)
> >>>{
> >>> return atomic_read(>in_gpu_reset);
> >>>}
> >>> +
> >>> +/**
> >>> + * memcpy_trailing - Copy the end of one structure into the middle
> >>> +of another
> >>> + *
> >>> + * @dst: Pointer to destination struct
> >>> + * @first_dst_member: The member name in @dst where the
> overwrite
> >>> +begins
> >>> + * @last_dst_member: The member name in @dst where the
> overwrite
> >>> +ends after
> >>> + * @src: Pointer to the source struct
> >>> + * @first_src_member: The member name in @src where the copy
> begins
> >>> + *
> >>> + */
> >>> +#define memcpy_trailing(dst, first_dst_member, last_dst_member,
> \
> >>> + src, first_src_member) \
> >> Please don't add a function like this into amdgpu.h, especially when
> >> it is only used by the SMU code.
> > Sure, I'm happy to move it. It wasn't clear to me which headers were
> considered "immutable". Which header should I put this in?
>
> I think amdgpu_smuio.h, but I'm not 100% sure. Alex do you have a better
> idea?
>
No, that's for the SMUIO callbacks for the IP block. Please use
drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
Alex
> We don't want to put anything new into amdgpu.h any more since this is
> basically only a legacy leftover.
>
> Thanks,
> Christian.
>
> >
> >> And please give it an amdgpu_ prefix so that we are not confusing it
> >> with a core function.
> > Sure, I will include that.
> >
> >> Apart from that looks good to me.
> > Thanks!
> >
> > -Kees
Re: [PATCH v3] drm/radeon: Call radeon_suspend_kms() in radeon_pci_shutdown() for Loongson64
[Public] Applied. Thanks. For whatever reason, I never got this patch and couldn't find it in patchwork. Alex From: Koenig, Christian Sent: Wednesday, June 23, 2021 4:25 AM To: Tiezhu Yang ; Deucher, Alexander Cc: airl...@linux.ie ; amd-...@lists.freedesktop.org ; dan...@ffwll.ch ; dri-devel@lists.freedesktop.org ; linux-ker...@vger.kernel.org ; lixuef...@loongson.cn ; lvjian...@loongson.cn Subject: Re: [PATCH v3] drm/radeon: Call radeon_suspend_kms() in radeon_pci_shutdown() for Loongson64 Looks good to me. Somebody could try to investigate further why that is necessary on the platform, but radeon is only in maintenance mode without new feature developed. Regards, Christian. Am 23.06.21 um 10:14 schrieb Tiezhu Yang: > Hi Alex and Christian, > > Any comments? > Can this patch be accepted or anything else I need to improve? > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fpatchwork%2Fpatch%2F1443649%2Fdata=04%7C01%7Cchristian.koenig%40amd.com%7C2162309822114d2e41b108d9361ef26c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637600328822651335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=2uxyAGk6sHO3lqw0FX6HITY%2Fbj%2BzEMfSIcqbzmiguMs%3Dreserved=0 > > > Thanks, > Tiezhu >
Re: [PATCH] drm/amdgpu: fix amdgpu_preempt_mgr_new()
[Public]
I've dropped it from my tree in that case.
From: Christian König
Sent: Monday, June 21, 2021 6:27 AM
To: Alex Deucher ; Kuehling, Felix
Cc: David Airlie ; Pan, Xinhui ;
kernel-janit...@vger.kernel.org ; Maling list
- DRI developers ; amd-gfx list
; Daniel Vetter ; Deucher,
Alexander ; Dave Airlie ;
Koenig, Christian ; Dan Carpenter
Subject: Re: [PATCH] drm/amdgpu: fix amdgpu_preempt_mgr_new()
Am 18.06.21 um 23:18 schrieb Alex Deucher:
> On Fri, Jun 18, 2021 at 11:40 AM Felix Kuehling
> wrote:
>> Am 2021-06-18 um 4:39 a.m. schrieb Christian König:
>>> Am 18.06.21 um 10:37 schrieb Dan Carpenter:
>>>> There is a reversed if statement in amdgpu_preempt_mgr_new() so it
>>>> always returns -ENOMEM.
>>>>
>>>> Fixes: 09b020bb05a5 ("Merge tag 'drm-misc-next-2021-06-09' of
>>>> git://anongit.freedesktop.org/drm/drm-misc into drm-next")
>>>> Signed-off-by: Dan Carpenter
>>> Most be some fallout from merging it with the TTM changes.
>>>
>>> Anyway, patch is Reviewed-by: Christian König
>> This is obviously not for amd-staging-drm-next. Christian, are you going
>> to apply it to the relevant branches?
> I've applied it to my drm-next branch.
I already pushed it to drm-misc-next last week.
Christian.
>
> Alex
>
>
>> Thanks,
>>Felix
>>
>>
>>> Thanks,
>>> Christian.
>>>
>>>> ---
>>>>drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 2 +-
>>>>1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
>>>> index f6aff7ce5160..d02c8637f909 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
>>>> @@ -71,7 +71,7 @@ static int amdgpu_preempt_mgr_new(struct
>>>> ttm_resource_manager *man,
>>>>struct amdgpu_preempt_mgr *mgr = to_preempt_mgr(man);
>>>> *res = kzalloc(sizeof(**res), GFP_KERNEL);
>>>> -if (*res)
>>>> +if (!*res)
>>>>return -ENOMEM;
>>>> ttm_resource_init(tbo, place, *res);
>> ___
>> amd-gfx mailing list
>> amd-...@lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7C096813db12f24172870508d9349f375a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637598680703030828%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2Ffg7TXDA9%2F%2Fjin8T5f3V11fAv3PVvtDFluNHnhwyOGM%3Dreserved=0
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7C096813db12f24172870508d9349f375a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637598680703030828%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2Ffg7TXDA9%2F%2Fjin8T5f3V11fAv3PVvtDFluNHnhwyOGM%3Dreserved=0
RE: [drm-rerere PATCH] nightly.conf: drop amd branches from drm-tip
[AMD Public Use] > -Original Message- > From: Jani Nikula > Sent: Wednesday, May 19, 2021 4:50 AM > To: dim-to...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org; > jani.nik...@intel.com; Deucher, Alexander > ; Koenig, Christian > ; Pan; Pan, Xinhui ; > Daniel Vetter > Subject: [drm-rerere PATCH] nightly.conf: drop amd branches from drm-tip > > We've had a stale repo for amd in drm-tip since around v4.15 i.e. for more > than three years. Nobody seems to notice or care. Drop the amd branches > from drm-tip. > > Having the current amd branches in drm-tip would be nice to have, if only to > have a common drm integration tree. However, maintaining that has a cost > due to the inevitable conflicts. We can add the branches back if and when > there's interest in sharing the burden. > > Cc: Alex Deucher > Cc: Christian König > Cc: Pan, Xinhui > Cc: Daniel Vetter > Signed-off-by: Jani Nikula Reviewed-by: Alex Deucher > --- > nightly.conf | 9 - > 1 file changed, 9 deletions(-) > > diff --git a/nightly.conf b/nightly.conf index 9211550ef75c..35fb1d9ba600 > 100644 > --- a/nightly.conf > +++ b/nightly.conf > @@ -40,12 +40,6 @@ git://anongit.freedesktop.org/drm-misc > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fano > ngit.freedesktop.org%2Fgit%2Fdrm%2Fdrm- > miscdata=04%7C01%7Calexander.deucher%40amd.com%7C5903896cf > 2e642afb05408d91aa30f6d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7 > C0%7C637570109906926805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w > LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000 > p;sdata=espN%2BoIX9SjLh2Py%2FkqlVsi0p9Ru%2Fet2M11XWqJ5eUQ%3D > mp;reserved=0 > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fano > ngit.freedesktop.org%2Fgit%2Fdrm%2Fdrm- > misc.gitdata=04%7C01%7Calexander.deucher%40amd.com%7C590389 > 6cf2e642afb05408d91aa30f6d%7C3dd8961fe4884e608e11a82d994e183d%7C0 > %7C0%7C637570109906926805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > amp;sdata=E5cwRH0Pr9JkIfIMNkNzjlLn5hN6k0inxBkk%2Bwhd1lk%3Dr > eserved=0 > " > -drm_tip_repos[drm-amd]=" > -ssh://git.freedesktop.org/git/drm/drm-amd > -git://anongit.freedesktop.org/drm/drm-amd > - > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fano > ngit.freedesktop.org%2Fgit%2Fdrm%2Fdrm- > amddata=04%7C01%7Calexander.deucher%40amd.com%7C5903896cf > 2e642afb05408d91aa30f6d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7 > C0%7C637570109906926805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w > LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000 > p;sdata=1kQe4t89CyANqRhNUpQ2RP3Ndz7A3sdd%2FiWZ7FmKHM4%3D > mp;reserved=0 > - > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fano > ngit.freedesktop.org%2Fgit%2Fdrm%2Fdrm- > amd.gitdata=04%7C01%7Calexander.deucher%40amd.com%7C590389 > 6cf2e642afb05408d91aa30f6d%7C3dd8961fe4884e608e11a82d994e183d%7C0 > %7C0%7C637570109906926805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > amp;sdata=vVqMWMbdJFHJW8j09tn1m7ItGSL0RmfeDbJZFWoYBf4%3D > p;reserved=0 > -" > drm_tip_repos[drm]=" > ssh://git.freedesktop.org/git/drm/drm > git://anongit.freedesktop.org/drm/drm > @@ -76,17 +70,14 @@ drm_tip_config=( > "drmdrm-fixes" > "drm-misc drm-misc-fixes" > "drm-intel drm-intel-fixes" > - "drm-amddrm-amd-fixes" > > "drmdrm-next" > "drm-misc drm-misc-next-fixes" > "drm-intel drm-intel-next-fixes" > - "drm-amddrm-amd-next-fixes" > > "drm-misc drm-misc-next" > "drm-intel drm-intel-next" > "drm-intel drm-intel-gt-next" > - "drm-amddrm-amd-next" > > "sound-upstream for-linus" > "sound-upstream for-next" > -- > 2.20.1
Re: [PATCH] drm/amdgpu: Unmap all MMIO mappings
[Public]
Reviewed-by: Alex Deucher
From: Grodzovsky, Andrey
Sent: Tuesday, May 18, 2021 10:01 AM
To: dri-devel@lists.freedesktop.org ;
amd-...@lists.freedesktop.org ;
linux-...@vger.kernel.org ;
ckoenig.leichtzumer...@gmail.com ;
daniel.vet...@ffwll.ch ; Wentland, Harry
Cc: ppaala...@gmail.com ; Deucher, Alexander
; gre...@linuxfoundation.org
; helg...@kernel.org ;
Kuehling, Felix
Subject: Re: [PATCH] drm/amdgpu: Unmap all MMIO mappings
Ping
Andrey
On 2021-05-17 3:31 p.m., Andrey Grodzovsky wrote:
> Access to those must be prevented post pci_remove
>
> v6: Drop BOs list, unampping VRAM BAR is enough.
> v8:
> Add condition of xgmi.connected_to_cpu to MTTR
> handling and remove MTTR handling from the old place.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 26 +++---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4
> 3 files changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index f7cca25c0fa0..8b50315d1fe1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3666,6 +3666,27 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>return r;
> }
>
> +static void amdgpu_device_unmap_mmio(struct amdgpu_device *adev)
> +{
> + /* Clear all CPU mappings pointing to this device */
> + unmap_mapping_range(adev->ddev.anon_inode->i_mapping, 0, 0, 1);
> +
> + /* Unmap all mapped bars - Doorbell, registers and VRAM */
> + amdgpu_device_doorbell_fini(adev);
> +
> + iounmap(adev->rmmio);
> + adev->rmmio = NULL;
> + if (adev->mman.aper_base_kaddr)
> + iounmap(adev->mman.aper_base_kaddr);
> + adev->mman.aper_base_kaddr = NULL;
> +
> + /* Memory manager related */
> + if (!adev->gmc.xgmi.connected_to_cpu) {
> + arch_phys_wc_del(adev->gmc.vram_mtrr);
> + arch_io_free_memtype_wc(adev->gmc.aper_base,
> adev->gmc.aper_size);
> + }
> +}
> +
> /**
>* amdgpu_device_fini - tear down the driver
>*
> @@ -3712,6 +3733,8 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
>amdgpu_device_ip_fini_early(adev);
>
>amdgpu_gart_dummy_page_fini(adev);
> +
> + amdgpu_device_unmap_mmio(adev);
> }
>
> void amdgpu_device_fini_sw(struct amdgpu_device *adev)
> @@ -3739,9 +3762,6 @@ void amdgpu_device_fini_sw(struct amdgpu_device *adev)
>}
>if ((adev->pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA)
>vga_client_register(adev->pdev, NULL, NULL, NULL);
> - iounmap(adev->rmmio);
> - adev->rmmio = NULL;
> - amdgpu_device_doorbell_fini(adev);
>
>if (IS_ENABLED(CONFIG_PERF_EVENTS))
>amdgpu_pmu_fini(adev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index 0adffcace326..8eabe3c9ad17 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -1107,10 +1107,6 @@ int amdgpu_bo_init(struct amdgpu_device *adev)
> void amdgpu_bo_fini(struct amdgpu_device *adev)
> {
>amdgpu_ttm_fini(adev);
> - if (!adev->gmc.xgmi.connected_to_cpu) {
> - arch_phys_wc_del(adev->gmc.vram_mtrr);
> - arch_io_free_memtype_wc(adev->gmc.aper_base,
> adev->gmc.aper_size);
> - }
> }
>
> /**
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 0d54e70278ca..58ad2fecc9e3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -1841,10 +1841,6 @@ void amdgpu_ttm_fini(struct amdgpu_device *adev)
>amdgpu_bo_free_kernel(>mman.discovery_memory, NULL, NULL);
>amdgpu_ttm_fw_reserve_vram_fini(adev);
>
> - if (adev->mman.aper_base_kaddr)
> - iounmap(adev->mman.aper_base_kaddr);
> - adev->mman.aper_base_kaddr = NULL;
> -
>amdgpu_vram_mgr_fini(adev);
>amdgpu_gtt_mgr_fini(adev);
>ttm_range_man_fini(>mman.bdev, AMDGPU_PL_GDS);
>
Re: [PATCH v6 04/16] drm/amdkfd: Split kfd suspend from devie exit
[AMD Public Use]
Typo in the subject: devie > device
Alex
From: Grodzovsky, Andrey
Sent: Monday, May 10, 2021 12:36 PM
To: dri-devel@lists.freedesktop.org ;
amd-...@lists.freedesktop.org ;
linux-...@vger.kernel.org ;
ckoenig.leichtzumer...@gmail.com ;
daniel.vet...@ffwll.ch ; Wentland, Harry
Cc: ppaala...@gmail.com ; Deucher, Alexander
; gre...@linuxfoundation.org
; helg...@kernel.org ;
Kuehling, Felix ; Grodzovsky, Andrey
Subject: [PATCH v6 04/16] drm/amdkfd: Split kfd suspend from devie exit
Helps to expdite HW related stuff to amdgpu_pci_remove
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_device.c| 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 5f6696a3c778..2b06dee9a0ce 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -170,7 +170,7 @@ void amdgpu_amdkfd_device_init(struct amdgpu_device *adev)
}
}
-void amdgpu_amdkfd_device_fini(struct amdgpu_device *adev)
+void amdgpu_amdkfd_device_fini_sw(struct amdgpu_device *adev)
{
if (adev->kfd.dev) {
kgd2kfd_device_exit(adev->kfd.dev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 14f68c028126..f8e10af99c28 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -127,7 +127,7 @@ void amdgpu_amdkfd_interrupt(struct amdgpu_device *adev,
const void *ih_ring_entry);
void amdgpu_amdkfd_device_probe(struct amdgpu_device *adev);
void amdgpu_amdkfd_device_init(struct amdgpu_device *adev);
-void amdgpu_amdkfd_device_fini(struct amdgpu_device *adev);
+void amdgpu_amdkfd_device_fini_sw(struct amdgpu_device *adev);
int amdgpu_amdkfd_submit_ib(struct kgd_dev *kgd, enum kgd_engine_type engine,
uint32_t vmid, uint64_t gpu_addr,
uint32_t *ib_cmd, uint32_t ib_len);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 357b9bf62a1c..ab6d2a43c9a3 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -858,10 +858,11 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd,
return kfd->init_complete;
}
+
+
void kgd2kfd_device_exit(struct kfd_dev *kfd)
{
if (kfd->init_complete) {
- kgd2kfd_suspend(kfd, false);
device_queue_manager_uninit(kfd->dqm);
kfd_interrupt_exit(kfd);
kfd_topology_remove_device(kfd);
--
2.25.1
RE: Radeon NI: GIT kernel with the nislands_smc commit doesn't boot on a Freescale P5040 board and P.A.Semi Nemo board
[AMD Public Use] + Gustavo, amd-gfx > -Original Message- > From: Christian Zigotzky > Sent: Friday, April 30, 2021 8:00 AM > To: gustavo...@kernel.org; Deucher, Alexander > > Cc: R.T.Dickinson ; Darren Stevens zone.net>; mad skateman ; linuxppc-dev > ; Olof Johansson ; > Maling list - DRI developers ; Michel > Dänzer ; Christian Zigotzky > Subject: Radeon NI: GIT kernel with the nislands_smc commit doesn't > boot on a Freescale P5040 board and P.A.Semi Nemo board > > Hello, > > The Nemo board (A-EON AmigaOne X1000) [1] and the FSL P5040 Cyrus+ > board (A-EON AmigaOne X5000) [2] with installed AMD Radeon HD6970 NI > graphics cards (Cayman XT) [3] don't boot with the latest git kernel > anymore after the commit "drm/radeon/nislands_smc.h: Replace > one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE > branch" [4]. > This git kernel boots in a virtual e5500 QEMU machine with a VirtIO-GPU [5]. > > I bisected today [6]. > > Result: drm/radeon/nislands_smc.h: Replace one-element array with > flexible-array member in struct NISLANDS_SMC_SWSTATE branch > (434fb1e7444a2efc3a4ebd950c7f771ebfcffa31) [4] is the first bad commit. > > I was able to revert this commit [7] and after a new compiling, the > kernel boots without any problems on my AmigaOnes. > > After that I created a patch for reverting this commit for new git test > kernels. > [3] > > The kernel compiles and boots with this patch on my AmigaOnes. Please > find attached the kernel config files. > > Please check the first bad commit. > > Thanks, > Christian > > [1] > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen. > wikipedia.org%2Fwiki%2FAmigaOne_X1000data=04%7C01%7Calexand > er.deucher%40amd.com%7C0622549383fb4320346b08d90bcf7be1%7C3dd89 > 61fe4884e608e11a82d994e183d%7C0%7C0%7C637553808670161651%7CUnkn > own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik > 1haWwiLCJXVCI6Mn0%3D%7C1000sdata=PNSrApUdMrku20hH7dEKlJJ > TBi7Qp5JOkqpA4MvKqdE%3Dreserved=0 > [2] > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki. > a miga.org%2Findex.php%3Ftitle%3DX5000data=04%7C01%7Calexander > .deucher%40amd.com%7C0622549383fb4320346b08d90bcf7be1%7C3dd8961f > e4884e608e11a82d994e183d%7C0%7C0%7C637553808670161651%7CUnknow > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha > WwiLCJXVCI6Mn0%3D%7C1000sdata=B8Uvhs25%2FP3RfnL1AgICN3Y4 > CEXeCE1yIoi3vvwvGto%3Dreserved=0 > [3] > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforu > m.hyperion- > entertainment.com%2Fviewtopic.php%3Ff%3D35%26t%3D4377data= > 04%7C01%7Calexander.deucher%40amd.com%7C0622549383fb4320346b08d > 90bcf7be1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63755380 > 8670161651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TokXplD > Tvg3%2BZMPLCgR1fs%2BN2X9MIfLXLW67MAM2Qsk%3Dreserved=0 > [4] > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit. > k ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git% > 2Fcommit%2F%3Fid%3D434fb1e7444a2efc3a4ebd950c7f771ebfcffa31d > ata=04%7C01%7Calexander.deucher%40amd.com%7C0622549383fb4320346 > b08d90bcf7be1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6375 > 53808670161651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=JC > M4xvPEnWdckcTPbQ2Ujv%2FAiMMsFMzzl4Pr%2FRPlcMQ%3Dreserve > d=0 > [5] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage - > drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev > user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw > root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci > -device usb- tablet -device virtio-keyboard-pci -smp 4 -vnc :1 [6] > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforu > m.hyperion- > entertainment.com%2Fviewtopic.php%3Fp%3D53074%23p53074data > =04%7C01%7Calexander.deucher%40amd.com%7C0622549383fb4320346b08 > d90bcf7be1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6375538 > 08670161651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ > IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=RXfSlY > A3bDEFas0%2Fk2vMWsl2l0nuhS2ecjZgSBLc%2Bs4%3Dreserved=0 > [7] git revert 434fb1e7444a2efc3a4ebd950c7f771ebfcffa3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/20] drm/amdgpu: Add error handling to amdgpu_dm_initialize_dp_connector()
[AMD Official Use Only - Internal Distribution Only]
I'm fine with having these changes go through drm-misc.
Alex
From: Lipski, Mikita
Sent: Wednesday, April 21, 2021 10:23 AM
To: Lyude Paul ; dri-devel@lists.freedesktop.org
; intel-...@lists.freedesktop.org
; nouv...@lists.freedesktop.org
; amd-...@lists.freedesktop.org
; Ville Syrjälä ;
Jani Nikula ; Rodrigo Vivi
; Thomas Zimmermann ; Thierry
Reding
Cc: Wang, Chao-kai (Stylon) ; Lipski, Mikita
; Park, Chris ; Brol, Eryk
; Li, Sun peng (Leo) ; Lakha,
Bhawanpreet ; Lin, Wayne ;
Siqueira, Rodrigo ; open list
; Kazlauskas, Nicholas
; Somasundaram, Meenakshikumar
; David Airlie ; Pillai,
Aurabindo ; Daniel Vetter ; Bas
Nieuwenhuizen ; Deucher, Alexander
; Cornij, Nikola ; Wentland,
Harry ; Koenig, Christian
Subject: Re: [PATCH v3 01/20] drm/amdgpu: Add error handling to
amdgpu_dm_initialize_dp_connector()
Thanks for the change!
Reviewed-by: Mikita Lipski
On 2021-04-19 6:55 p.m., Lyude Paul wrote:
> While working on moving i2c device registration into drm_dp_aux_init() - I
> realized that in order to do so we need to make sure that drivers calling
> drm_dp_aux_init() handle any errors it could possibly return. In the
> process of doing that, I noticed that the majority of AMD's code for DP
> connector creation doesn't attempt to do any real error handling.
>
> So, let's fix this and also cleanup amdgpu_dm_initialize_dp_connector()
> while we're at it. This way we can handle the error codes from
> drm_dp_aux_init().
>
> Signed-off-by: Lyude Paul
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++-
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 44 +++
> .../display/amdgpu_dm/amdgpu_dm_mst_types.h | 6 +--
> 3 files changed, 45 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index a0c8c41e4e57..fc5d315bbb05 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -7608,10 +7608,9 @@ static int amdgpu_dm_connector_init(struct
> amdgpu_display_manager *dm,
>
>aconnector->i2c = i2c;
>res = i2c_add_adapter(>base);
> -
>if (res) {
>DRM_ERROR("Failed to register hw i2c %d\n", link->link_index);
> - goto out_free;
> + goto fail_free;
>}
>
>connector_type = to_drm_connector_type(link->connector_signal);
> @@ -7625,8 +7624,7 @@ static int amdgpu_dm_connector_init(struct
> amdgpu_display_manager *dm,
>
>if (res) {
>DRM_ERROR("connector_init failed\n");
> - aconnector->connector_id = -1;
> - goto out_free;
> + goto fail_id;
>}
>
>drm_connector_helper_add(
> @@ -7643,15 +7641,22 @@ static int amdgpu_dm_connector_init(struct
> amdgpu_display_manager *dm,
>drm_connector_attach_encoder(
>>base, >base);
>
> - if (connector_type == DRM_MODE_CONNECTOR_DisplayPort
> - || connector_type == DRM_MODE_CONNECTOR_eDP)
> - amdgpu_dm_initialize_dp_connector(dm, aconnector,
> link->link_index);
> -
> -out_free:
> - if (res) {
> - kfree(i2c);
> - aconnector->i2c = NULL;
> + if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> + connector_type == DRM_MODE_CONNECTOR_eDP) {
> + res = amdgpu_dm_initialize_dp_connector(dm, aconnector,
> link->link_index);
> + if (res)
> + goto fail_cleanup;
>}
> +
> + return 0;
> +fail_cleanup:
> + drm_connector_cleanup(>base);
> +fail_id:
> + aconnector->connector_id = -1;
> +fail_free:
> + kfree(i2c);
> + aconnector->i2c = NULL;
> +
>return res;
> }
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 73cdb9fe981a..3dee9cce9c9e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -425,33 +425,39 @@ static const struct drm_dp_mst_topology_cbs dm_mst_cbs
> = {
>.add_connector = dm_dp_add_mst_connector,
> };
>
> -void amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
> -struct amdgpu_dm_connector *aconnector,
> -int link_index)
> +int amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
>
Re: [PATCH] drm/ttm: stop warning on TT shrinker failure
[AMD Official Use Only - Internal Distribution Only]
+ Leo
From: amd-gfx on behalf of Christian
König
Sent: Friday, March 19, 2021 10:08 AM
To: Liu, Leo ; amd-...@lists.freedesktop.org
; dri-devel@lists.freedesktop.org
Subject: [PATCH] drm/ttm: stop warning on TT shrinker failure
Don't print a warning when we fail to allocate a page for swapping things out.
Also rely on memalloc_nofs_save/memalloc_nofs_restore instead of GFP_NOFS.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_tt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 2f0833c98d2c..86fa3e82dacc 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -369,7 +369,7 @@ static unsigned long ttm_tt_shrinker_scan(struct shrinker
*shrink,
};
int ret;
- ret = ttm_bo_swapout(, GFP_NOFS);
+ ret = ttm_bo_swapout(, GFP_KERNEL | __GFP_NOWARN);
return ret < 0 ? SHRINK_EMPTY : ret;
}
@@ -389,10 +389,13 @@ static unsigned long ttm_tt_shrinker_count(struct
shrinker *shrink,
static int ttm_tt_debugfs_shrink_show(struct seq_file *m, void *data)
{
struct shrink_control sc = { .gfp_mask = GFP_KERNEL };
+ unsigned int flags;
fs_reclaim_acquire(GFP_KERNEL);
+ flags = memalloc_nofs_save();
seq_printf(m, "%lu/%lu\n", ttm_tt_shrinker_count(_shrinker, ),
ttm_tt_shrinker_scan(_shrinker, ));
+ memalloc_nofs_restore(flags);
fs_reclaim_release(GFP_KERNEL);
return 0;
--
2.25.1
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7C70aef4974dfe465a06a308d8eae08eb3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637517597539809703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kvyinv9FPakf76dvXF0pzfeCpclxAo3L4Ufkf6%2B6%2FCc%3Dreserved=0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/amd/display: Fix unused variable warning
[AMD Official Use Only - Internal Distribution Only] Reviewed-by: Alex Deucher From: Wei Yongjun Sent: Wednesday, February 24, 2021 4:49 AM To: Hulk Robot ; Wentland, Harry ; Li, Sun peng (Leo) ; Deucher, Alexander ; Koenig, Christian ; David Airlie ; Daniel Vetter ; Kazlauskas, Nicholas ; Siqueira, Rodrigo ; Pillai, Aurabindo ; Wang, Chao-kai (Stylon) ; Lakha, Bhawanpreet ; Bas Nieuwenhuizen ; Simon Ser ; Zhuo, Qingqing Cc: Wei Yongjun ; amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org ; linux-ker...@vger.kernel.org Subject: [PATCH -next] drm/amd/display: Fix unused variable warning GCC reports the following warning with W=1: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5439:33: warning: unused variable 'dm' [-Wunused-variable] 5439 | struct amdgpu_display_manager *dm = >dm; | ^~ This variable only used when CONFIG_DRM_AMD_DC_DCN is set, this commit fix the warning. Reported-by: Hulk Robot Signed-off-by: Wei Yongjun --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index e24a13fd2730..bda8d5f4e56a 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -5436,8 +5436,8 @@ static inline int dm_set_vblank(struct drm_crtc *crtc, bool enable) struct amdgpu_crtc *acrtc = to_amdgpu_crtc(crtc); struct amdgpu_device *adev = drm_to_adev(crtc->dev); struct dm_crtc_state *acrtc_state = to_dm_crtc_state(crtc->state); - struct amdgpu_display_manager *dm = >dm; #if defined(CONFIG_DRM_AMD_DC_DCN) + struct amdgpu_display_manager *dm = >dm; unsigned long flags; #endif int rc = 0; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/2] drm/amd/display: Fix the brightness read via aux
[AMD Public Use] > -Original Message- > From: Takashi Iwai > Sent: Saturday, February 6, 2021 7:29 AM > To: Alex Deucher > Cc: Deucher, Alexander ; Koenig, Christian > ; Li, Sun peng (Leo) ; > Wentland, Harry ; Maling list - DRI developers > ; amd-gfx list g...@lists.freedesktop.org> > Subject: Re: [PATCH 1/2] drm/amd/display: Fix the brightness read via aux > > On Fri, 05 Feb 2021 17:36:44 +0100, > Alex Deucher wrote: > > > > On Wed, Feb 3, 2021 at 7:42 AM Takashi Iwai wrote: > > > > > > The current code tries to read the brightness value via > > > dc_link_get_backlight_level() no matter whether it's controlled via > > > aux or not, and this results in a bogus value returned. > > > Fix it to read the current value via > > > dc_link_get_backlight_level_nits() for the aux. > > > > > > BugLink: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu > > > > gzilla.opensuse.org%2Fshow_bug.cgi%3Fid%3D1180749data=04%7C01 > %7 > > > > Calexander.deucher%40amd.com%7Ce5579cfe56f74b572f1508d8ca9ad0ac%7 > C3d > > > > d8961fe4884e608e11a82d994e183d%7C0%7C0%7C637482113562863043%7CU > nknow > > > > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha > Wwi > > > > LCJXVCI6Mn0%3D%7C1000sdata=HVtqM2r6oxSWd3XGGQZotO8wrvM > qCTcwfq1L > > > 2%2FeCmSE%3Dreserved=0 > > > BugLink: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi > > > tlab.freedesktop.org%2Fdrm%2Famd%2F- > %2Fissues%2F1438data=04%7C0 > > > > 1%7Calexander.deucher%40amd.com%7Ce5579cfe56f74b572f1508d8ca9ad0 > ac%7 > > > > C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637482113562863043% > 7CUnk > > > > nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > k1ha > > > > WwiLCJXVCI6Mn0%3D%7C1000sdata=TdYgwNJ%2FvkuoDLNb9ATFb1P > yznlp%2F > > > P8TLuYSR%2BVkNqY%3Dreserved=0 > > > Signed-off-by: Takashi Iwai > > > > This looks fine to me. FWIW, I have a similar patch set here: > > https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.f > > > reedesktop.org%2F~agd5f%2Flinux%2Flog%2F%3Fh%3Dbacklight_wip > data= > > > 04%7C01%7Calexander.deucher%40amd.com%7Ce5579cfe56f74b572f1508d8 > ca9ad0 > > > ac%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637482113562863 > 043%7CU > > > nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI > 6Ik1ha > > > WwiLCJXVCI6Mn0%3D%7C1000sdata=aoMSY0nvHjrLocUPJtdgckqIH7x > LUPbwpH0 > > ZjhuuJO8%3Dreserved=0 > > I'm fine to scratch mine as long as the issue gets fixed :) > > FWIW, the biggest problem so far was the aux channel backlight didn't work > as expected, the actual backlight isn't changed by the backlight sysfs write. > (And the sysfs read gives a bogus value, but it's not the cause of the non- > working backlight control.) > > Does the aux channel backlight really work with the current code? > Or is this rather a device-specific issue (e.g. broken BIOS) and we might need > to come up with a deny list or such? > @Kazlauskas, Nicholas, @Siqueira, Rodrigo Has there been any progress on the backlight fixes? Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances
[AMD Official Use Only - Internal Distribution Only]
I think the virt team probably wants it in amd-staging-drm-next so they can
start testing it. 5.12 is getting pretty tight. I'm not sure if there will be
another drm-misc PR or not for 5.12. Rebasing amd-staging-drm-next is turning
into a challenge. there are always a lot of regressions. I guess that is an
argument to rebase more often so we get better internal testing of it.
Alex
From: Koenig, Christian
Sent: Friday, February 5, 2021 9:53 AM
To: Deucher, Alexander ; Liu, Leo ;
amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances
The alternative is to wait till drm-misc-next is merged into drm-next, then
rebase amd-staging-drm-next on top of that (or directly drm-misc-next) and push
then.
Would give us at least a clean history. Question is rather if we want it in
5.12?
Christian.
Am 05.02.21 um 15:50 schrieb Deucher, Alexander:
[AMD Official Use Only - Internal Distribution Only]
Good question. I think push it to drm-misc-next for upstream. We can carry it
internally in amd-staging-drm-next for internal testing and I can coordinate
with drm-next. I think the amdgpu changes are pretty straightforward, so
shouldn't be too hard keep the merge straight. I dunno.
Alex
From: Christian König
<mailto:ckoenig.leichtzumer...@gmail.com>
Sent: Friday, February 5, 2021 4:58 AM
To: Liu, Leo <mailto:leo@amd.com>;
amd-...@lists.freedesktop.org<mailto:amd-...@lists.freedesktop.org>
<mailto:amd-...@lists.freedesktop.org>;
dri-devel@lists.freedesktop.org<mailto:dri-devel@lists.freedesktop.org>
<mailto:dri-devel@lists.freedesktop.org>;
Deucher, Alexander <mailto:alexander.deuc...@amd.com>
Subject: Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances
Alex how do we want to merge this?
I've just pushed the first patch to drm-misc-next since that needed a
rebase because it touches other drivers as well.
But the rest is really AMD specific and I'm not sure if the dependent
stuff is already in there as well.
So if I push it to drm-misc-next you will probably need to merge and if
I push it to amd-staging-drm-next somebody else might need to merge when
drm-misc-next is merged.
Ideas?
Christian.
Am 04.02.21 um 19:34 schrieb Leo Liu:
> The series are:
>
> Reviewed-and-Tested-by: Leo Liu <mailto:leo@amd.com>
>
>
> On 2021-02-04 9:44 a.m., Christian König wrote:
>> The VCN3 instances can do both decode as well as encode.
>>
>> Share the scheduler load balancing score and remove fixing encode to
>> only the second instance.
>>
>> Signed-off-by: Christian König
>> <mailto:christian.koe...@amd.com>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 1 +
>> drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 11 +++
>> 2 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> index 13aa417f6be7..d10bc4f0a05f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> @@ -211,6 +211,7 @@ struct amdgpu_vcn_inst {
>> void*saved_bo;
>> struct amdgpu_ringring_dec;
>> struct amdgpu_ringring_enc[AMDGPU_VCN_MAX_ENC_RINGS];
>> +atomic_tsched_score;
>> struct amdgpu_irq_srcirq;
>> struct amdgpu_vcn_regexternal;
>> struct amdgpu_bo*dpg_sram_bo;
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> index 239a4eb52c61..b33f513fd2ac 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> @@ -171,6 +171,7 @@ static int vcn_v3_0_sw_init(void *handle)
>> for (i = 0; i < adev->vcn.num_vcn_inst; i++) {
>> volatile struct amdgpu_fw_shared *fw_shared;
>> +
>> if (adev->vcn.harvest_config & (1 << i))
>> continue;
>> @@ -198,6 +199,8 @@ static int vcn_v3_0_sw_init(void *handle)
>> if (r)
>> return r;
>> +atomic_set(>vcn.inst[i].sched_score, 0);
>> +
>> ring = >vcn.inst[i].ring_dec;
>> ring->use_doorbell = true;
>> if (amdgpu_sriov_vf(adev)) {
>> @@ -209,7 +212,8 @@ static int vcn_v3_0_sw_init(void *handle)
>> ring->no_scheduler = true;
>> sprintf(ring->name, "vcn_dec_%d", i);
>> r = amdgpu_ring_init(adev, ring, 512,
>> >vcn.
Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances
[AMD Official Use Only - Internal Distribution Only]
Good question. I think push it to drm-misc-next for upstream. We can carry it
internally in amd-staging-drm-next for internal testing and I can coordinate
with drm-next. I think the amdgpu changes are pretty straightforward, so
shouldn't be too hard keep the merge straight. I dunno.
Alex
From: Christian König
Sent: Friday, February 5, 2021 4:58 AM
To: Liu, Leo ; amd-...@lists.freedesktop.org
; dri-devel@lists.freedesktop.org
; Deucher, Alexander
Subject: Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances
Alex how do we want to merge this?
I've just pushed the first patch to drm-misc-next since that needed a
rebase because it touches other drivers as well.
But the rest is really AMD specific and I'm not sure if the dependent
stuff is already in there as well.
So if I push it to drm-misc-next you will probably need to merge and if
I push it to amd-staging-drm-next somebody else might need to merge when
drm-misc-next is merged.
Ideas?
Christian.
Am 04.02.21 um 19:34 schrieb Leo Liu:
> The series are:
>
> Reviewed-and-Tested-by: Leo Liu
>
>
> On 2021-02-04 9:44 a.m., Christian König wrote:
>> The VCN3 instances can do both decode as well as encode.
>>
>> Share the scheduler load balancing score and remove fixing encode to
>> only the second instance.
>>
>> Signed-off-by: Christian König
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 1 +
>> drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 11 +++
>> 2 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> index 13aa417f6be7..d10bc4f0a05f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> @@ -211,6 +211,7 @@ struct amdgpu_vcn_inst {
>> void*saved_bo;
>> struct amdgpu_ringring_dec;
>> struct amdgpu_ringring_enc[AMDGPU_VCN_MAX_ENC_RINGS];
>> +atomic_tsched_score;
>> struct amdgpu_irq_srcirq;
>> struct amdgpu_vcn_regexternal;
>> struct amdgpu_bo*dpg_sram_bo;
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> index 239a4eb52c61..b33f513fd2ac 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> @@ -171,6 +171,7 @@ static int vcn_v3_0_sw_init(void *handle)
>> for (i = 0; i < adev->vcn.num_vcn_inst; i++) {
>> volatile struct amdgpu_fw_shared *fw_shared;
>> +
>> if (adev->vcn.harvest_config & (1 << i))
>> continue;
>> @@ -198,6 +199,8 @@ static int vcn_v3_0_sw_init(void *handle)
>> if (r)
>> return r;
>> +atomic_set(>vcn.inst[i].sched_score, 0);
>> +
>> ring = >vcn.inst[i].ring_dec;
>> ring->use_doorbell = true;
>> if (amdgpu_sriov_vf(adev)) {
>> @@ -209,7 +212,8 @@ static int vcn_v3_0_sw_init(void *handle)
>> ring->no_scheduler = true;
>> sprintf(ring->name, "vcn_dec_%d", i);
>> r = amdgpu_ring_init(adev, ring, 512,
>> >vcn.inst[i].irq, 0,
>> - AMDGPU_RING_PRIO_DEFAULT, NULL);
>> + AMDGPU_RING_PRIO_DEFAULT,
>> + >vcn.inst[i].sched_score);
>> if (r)
>> return r;
>> @@ -227,11 +231,10 @@ static int vcn_v3_0_sw_init(void *handle)
>> } else {
>> ring->doorbell_index =
>> (adev->doorbell_index.vcn.vcn_ring0_1 << 1) + 2 + j + 8 * i;
>> }
>> -if (adev->asic_type == CHIP_SIENNA_CICHLID && i != 1)
>> -ring->no_scheduler = true;
>> sprintf(ring->name, "vcn_enc_%d.%d", i, j);
>> r = amdgpu_ring_init(adev, ring, 512,
>> >vcn.inst[i].irq, 0,
>> - AMDGPU_RING_PRIO_DEFAULT, NULL);
>> + AMDGPU_RING_PRIO_DEFAULT,
>> + >vcn.inst[i].sched_score);
>> if (r)
>> return r;
>> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [pull] amdgpu, amdkfd drm-next-5.12
[AMD Public Use] > -Original Message- > From: Kuehling, Felix > Sent: Friday, January 29, 2021 5:33 PM > To: Alex Deucher ; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > airl...@gmail.com; daniel.vet...@ffwll.ch > Cc: Deucher, Alexander ; Pan, Xinhui > ; Koenig, Christian > Subject: Re: [pull] amdgpu, amdkfd drm-next-5.12 > > Am 2021-01-29 um 5:28 p.m. schrieb Alex Deucher: > > drm/amdgpu: Make contiguous pinning optional > > This one needs a follow-up fix, as it breaks pinning in GTT. Xinhui should > have > the fix ready very soon. You may want to hold this back until the fix lands. Ok. Ignore this PR for now. I'll send an updated one next week when the fix lands. Thanks, Alex > > Regards, > Felix > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: amdgpu does not support 3840x2160@30Hz on kaveri apu
[AMD Official Use Only - Internal Distribution Only] You might try enabling DC (the newer modesetting infrastructure). Append amdgpu.dc=1 to the kernel command line in grub. Alex From: Davide Corrado Sent: Saturday, January 2, 2021 1:50 PM To: Deucher, Alexander Cc: Koenig, Christian ; airl...@linux.ie ; dan...@ffwll.ch ; amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org ; linux-ker...@vger.kernel.org Subject: amdgpu does not support 3840x2160@30Hz on kaveri apu hello, I'd like to report this issue that I am having since I updated my display (samsung U28E590). The amdgpu does not support the native resolution of my new monitor, which is 3840x2160. Using a HDMI or DVI connection (I tried both, same results), the maximum supported refresh is 30Hz, so I'm stuck with that (don't have a displayport). The radeon module works fine, I'm having this issue just when I use amdgpu (which I'd like to, because performance is better). Some info of my hardware: cpu: AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G kernel version (I tried different ones and different linux distros, same results!): 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Monitor: Samsung U28E590. description: If I boot the system using amdgpu and no video mode selection, the system boots but I don't get a screen during boot and in wayland. I can connect using ssh, so the system is running fine, just no display; If I force a full HD resolution with "video:" in the kernel line, I can see the boot process but the screen disappears when wayland starts (because the default resolution is 3840x2160@30Hz). Using a full HD monitor results in no issues, so it must be related to this very 4k resolution. As I have already stated, radeon module works with the same software/hardware configuration. thanks you so much for your time :-) -- Davide Corrado UNIX Team Leader Via Abramo Lincoln, 25 20129 Milano Tel +39 3474259950 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bug] Radeon 3900XT not switch to graphic mode on kernel 5.10
[AMD Public Use] It looks like the driver is not able to access the firmware for some reason. Please make sure it is available in your initrd or compiled into the kernel depending on your config. Alex From: amd-gfx on behalf of Mikhail Gavrilov Sent: Sunday, December 27, 2020 11:58 AM To: amd-gfx list ; Linux List Kernel Mailing ; dri-devel Subject: Re: [bug] Radeon 3900XT not switch to graphic mode on kernel 5.10 On Sun, 27 Dec 2020 at 21:39, Mikhail Gavrilov wrote: > I suppose the root of cause my problem here: > > [3.961326] amdgpu :0b:00.0: Direct firmware load for > amdgpu/sienna_cichlid_sos.bin failed with error -2 > [3.961359] amdgpu :0b:00.0: amdgpu: failed to init sos firmware > [3.961433] [drm:psp_sw_init [amdgpu]] *ERROR* Failed to load psp firmware! > [3.961529] [drm:amdgpu_device_init.cold [amdgpu]] *ERROR* sw_init > of IP block failed -2 > [3.961549] amdgpu :0b:00.0: amdgpu: amdgpu_device_ip_init failed > [3.961569] amdgpu :0b:00.0: amdgpu: Fatal error during GPU init > [3.961911] amdgpu: probe of :0b:00.0 failed with error -2 > # dnf provides */sienna_cichlid_sos.bin Last metadata expiration check: 3:01:27 ago on Sun 27 Dec 2020 06:53:25 PM +05. linux-firmware-20201218-116.fc34.noarch : Firmware files used by the Linux kernel Repo: @System Matched from: Filename: /usr/lib/firmware/amdgpu/sienna_cichlid_sos.bin linux-firmware-20201218-116.fc34.noarch : Firmware files used by the Linux kernel Repo: rawhide Matched from: Filename: /usr/lib/firmware/amdgpu/sienna_cichlid_sos.bin # dnf install linux-firmware-20201218-116.fc34.noarch Last metadata expiration check: 3:02:11 ago on Sun 27 Dec 2020 06:53:25 PM +05. Package linux-firmware-20201218-116.fc34.noarch is already installed. Dependencies resolved. Nothing to do. Complete! Looks like firmware is present. So I didn't understand why the kernel cannot read firmware. -- Best Regards, Mike Gavrilov. ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7Cf76668be26de4be7d0af08d8aa88a8dc%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637446851228684932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=NOQO9oeX9gOmM7aOThep5kjURTTn14N5nNkhGx7rofQ%3Dreserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 5.4 006/130] drm/amd/display: Do not silently accept DCC for multiplane formats.
[AMD Public Use] I don't know if these fixes related to modifiers make sense in the pre-modifier code base. Bas, Nick? Alex From: amd-gfx on behalf of Sasha Levin Sent: Tuesday, December 22, 2020 9:16 PM To: linux-ker...@vger.kernel.org ; sta...@vger.kernel.org Cc: Sasha Levin ; dri-devel@lists.freedesktop.org ; amd-...@lists.freedesktop.org ; Bas Nieuwenhuizen ; Deucher, Alexander ; Kazlauskas, Nicholas Subject: [PATCH AUTOSEL 5.4 006/130] drm/amd/display: Do not silently accept DCC for multiplane formats. From: Bas Nieuwenhuizen [ Upstream commit b35ce7b364ec80b54f48a8fdf9fb74667774d2da ] Silently accepting it could result in corruption. Signed-off-by: Bas Nieuwenhuizen Reviewed-by: Alex Deucher Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index d2dd387c95d86..ce70c42a2c3ec 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2734,7 +2734,7 @@ fill_plane_dcc_attributes(struct amdgpu_device *adev, return 0; if (format >= SURFACE_PIXEL_FORMAT_VIDEO_BEGIN) - return 0; + return -EINVAL; if (!dc->cap_funcs.get_dcc_compression_cap) return -EINVAL; -- 2.27.0 ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7Cfb9f2581393f494acd1708d8a6e905fc%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63744286704415%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZYz1FjTl6SoWX1B91t0McdUai%2FzRF9C8uBmE%2BNQNod4%3Dreserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [kbuild-all] Re: [radeon-alex:amd-20.45 2127/2427] drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1880:39: sparse: sparse: incorrect type in argument 1 (different base types)
[AMD Official Use Only - Internal Distribution Only]
You can add amd-21.xx as well, since they will coming up next year. Maybe
amd-2*?
Alex
From: Rong Chen
Sent: Wednesday, December 16, 2020 3:48 AM
To: Deucher, Alexander ; Qinglang Miao
; kernel test robot
Cc: kbuild-...@lists.01.org ;
dri-devel@lists.freedesktop.org ; Felix
<"Xiong, "@ml01.01.org>
Subject: Re: [kbuild-all] Re: [radeon-alex:amd-20.45 2127/2427]
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1880:39: sparse:
sparse: incorrect type in argument 1 (different base types)
Hi Alex,
We have ignored the amd-20.xx branches:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fintel%2Flkp-tests%2Fcommit%2Facb8d1f213ec6841900e0d7e9737f8ea0960e4d3data=04%7C01%7CAlexander.Deucher%40amd.com%7C2f283fc47a6641db05cd08d8a19f7d80%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437053682479635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=U2aA%2B31wbSToDkIHiUrJWriNOPNNJ162W3F1HjYG6mc%3Dreserved=0
Best Regards,
Rong Chen
On 12/15/20 10:24 PM, Deucher, Alexander wrote:
>
> [AMD Public Use]
>
>
> The test robot should probably not be testing the amd-20.xx branches
> in the first place. They are just mirrors of our packaged drivers so
> they contain a bunch of stuff that will never go upstream like kernel
> compatibility layers and dkms support.
>
> Alex
>
>
> *From:* Qinglang Miao
> *Sent:* Tuesday, December 15, 2020 3:21 AM
> *To:* kernel test robot ; Deucher, Alexander
>
> *Cc:* kbuild-...@lists.01.org ;
> dri-devel@lists.freedesktop.org ;
> Xiong, Yang (Felix)
> *Subject:* Re: [radeon-alex:amd-20.45 2127/2427]
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1880:39:
> sparse: sparse: incorrect type in argument 1 (different base types)
> Hi Alex,
>
> I think it's not a valid report from kernel test robot, for __le16 ought
> to be the right type for cpu_to_le16. The sparse warnings seems not
> right so I did't try effort to reproduce it.
>
> otherwise, when I take a carful look at this patch, an unconditional
> braces exists and I'm not sure about its benefit.
>
> if (bp_params->flags.INTERLACE) {
> params.susModeMiscInfo.usAccess =
> cpu_to_le16(le16_to_cpu(params.susModeMiscInfo.usAccess) |
> ATOM_INTERLACE);
> {
> le16_add_cpu(_SyncOffset, 1);
> }
> }
>
> patch link:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2FCADnq5_PunHA1VHHj7VtEHG6o2Z_Z1WS325y_R9xO%2BgsV_JCOXw%40mail.gmail.com%2Fdata=04%7C01%7CAlexander.Deucher%40amd.com%7C2f283fc47a6641db05cd08d8a19f7d80%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437053682489591%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=loDpCZcwzSthBMwesVesMIEwtgf%2BGZoycOyTwBpqkfI%3Dreserved=0
>
> How do you think?
>
> 在 2020/12/15 14:44, kernel test robot 写道:
> > tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
> > head: a3950d94b046fb206e58fd3ec717f071c0203ba3
> > commit: c82b6c9ed412fb7009b02dd82e50ee24f451e9a8 [2127/2427]
> drm/amd/display: convert to use le16_add_cpu()
> > config: arc-randconfig-s031-20201214 (attached as .config)
> > compiler: arc-elf-gcc (GCC) 9.3.0
> > reproduce:
> > wget
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintel%2Flkp-tests%2Fmaster%2Fsbin%2Fmake.crossdata=04%7C01%7CAlexander.Deucher%40amd.com%7C2f283fc47a6641db05cd08d8a19f7d80%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437053682489591%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=a6yKdL%2BoYm1zc5fYftUrWwmas%2BOfrTjqpivV14xci1Y%3Dreserved=0
> -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # apt-get install sparse
> > # sparse version: v0.6.3-184-g1b896707-dirty
> > git remote add radeon-alex
> git://people.freedesktop.org/~agd5f/linux.git
> > git fetch --no-tags radeon-alex amd-20.45
> > git checkout c82b6c9ed412fb7009b02dd82e50ee24f451e9a8
> > # save the attached .config to linux build tree
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
> make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arc
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot
> >
> >
> > "sparse warnings: (new ones prefixed by >>)"
> >
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/c
RE: [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers
[AMD Public Use] > -Original Message- > From: Laurent Pinchart > Sent: Tuesday, December 15, 2020 9:15 PM > To: Koenig, Christian > Cc: Daniel Vetter ; Laurent Pinchart > ; dri- > de...@lists.freedesktop.org; Dave Airlie ; Greg Kroah- > Hartman ; Thomas Gleixner > ; Deucher, Alexander ; > Rob Clark ; Sean Paul ; Ben > Skeggs ; Gerd Hoffmann ; > Thierry Reding ; Eric Anholt ; > VMware Graphics ; Thomas > Hellstrom > Subject: Re: [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers > > Hi Christian, > > On Fri, Jul 17, 2020 at 04:05:42PM +0200, Christian König wrote: > > Am 17.07.20 um 04:27 schrieb Laurent Pinchart: > > > On Mon, Jun 22, 2020 at 11:29:33AM +0200, Daniel Vetter wrote: > > >> On Mon, Jun 22, 2020 at 09:58:44AM +0200, Christian König wrote: > > >>> Am 21.06.20 um 04:07 schrieb Laurent Pinchart: > > >>>> Most of the DRM drivers uAPI headers are licensed under the MIT > > >>>> license, and carry copies of the license with slight variations. > > >>>> Replace them with SPDX headers. > > >>> My personal opinion is that this is a really good idea, but my > > >>> professional is that we need the acknowledgment from our legal > department for this. > > >> I think official ack from amd on first patch, especially the .rst > > >> snippet, would be really good indeed. > > > Any update on this one ? > > > > Sorry totally forgot to forward this because I was waiting for split > > up patches. > > > > Going to do so right now. > > Has there been any update ? :-) AMD legal requires the full license. Alex > > > >>> Please separate that change into one for each > driver/company/maintainer. > > >>> Amdgpu, radeon, r128 can be one for example. > > > > > > I'll do so. > > > > > >> You can leave all the other legacy drivers in one patch (mga, > > >> savage, sis, via), since there's likely no one around anymore and > > >> will just boil down to drm maintainer ack from Dave > > >> > > >>>> Signed-off-by: Laurent Pinchart > > >>>> > > >>>> --- > > >>>>include/uapi/drm/amdgpu_drm.h | 19 +-- > > >>>>include/uapi/drm/i915_drm.h| 22 +- > > >>>>include/uapi/drm/mga_drm.h | 20 +--- > > >>>>include/uapi/drm/msm_drm.h | 20 +--- > > >>>>include/uapi/drm/nouveau_drm.h | 20 +--- > > >>>>include/uapi/drm/qxl_drm.h | 20 +--- > > >>>>include/uapi/drm/r128_drm.h| 20 +--- > > >>>>include/uapi/drm/radeon_drm.h | 20 +--- > > >>>>include/uapi/drm/savage_drm.h | 20 +--- > > >>>>include/uapi/drm/sis_drm.h | 21 + > > >>>>include/uapi/drm/tegra_drm.h | 19 +-- > > >>>>include/uapi/drm/v3d_drm.h | 20 +--- > > >>>>include/uapi/drm/vc4_drm.h | 20 +--- > > >>>>include/uapi/drm/vgem_drm.h| 22 +- > > >>>>include/uapi/drm/via_drm.h | 20 +--- > > >>>>include/uapi/drm/virtgpu_drm.h | 20 +--- > > >>>>include/uapi/drm/vmwgfx_drm.h | 21 + > > >>>>17 files changed, 17 insertions(+), 327 deletions(-) > > >>>> > > >>>> diff --git a/include/uapi/drm/amdgpu_drm.h > > >>>> b/include/uapi/drm/amdgpu_drm.h index > 4e873dcbe68f..c6adda72bec7 > > >>>> 100644 > > >>>> --- a/include/uapi/drm/amdgpu_drm.h > > >>>> +++ b/include/uapi/drm/amdgpu_drm.h > > >>>> @@ -1,3 +1,4 @@ > > >>>> +/* SPDX-License-Identifier: MIT */ > > >>>>/* amdgpu_drm.h -- Public header for the amdgpu driver -*- linux-c > -*- > > >>>> * > > >>>> * Copyright 2000 Precision Insight, Inc., Cedar Park, Texas. > > >>>> @@ -5,24 +6,6 @@ > > >>>> * Copyright 2002 Tungsten Graphics, Inc., Cedar Park, Texas. > > >>>> * Copyright 2014 Advanced Micro Devices, Inc. > > >>>> * > > >>>> - * Permission is hereby granted, free of cha
Re: [radeon-alex:amd-20.45 1953/2427] drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce60/dce60_clk_mgr.c:83:5: warning: no previous prototype for function 'dce60_get_dp_ref_freq_khz'
[AMD Public Use] this branch should be ignored by test robots. It's just a public mirror of our packaged driver source code. It contains kernel compatibility and dkms support which is not going upstream. Alex From: Mauro Rossi Sent: Tuesday, December 15, 2020 2:13 PM To: kernel test robot ; Deucher, Alexander Cc: kbuild-...@lists.01.org ; clang-built-li...@googlegroups.com ; ML dri-devel ; Xiong, Yang (Felix) Subject: Re: [radeon-alex:amd-20.45 1953/2427] drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce60/dce60_clk_mgr.c:83:5: warning: no previous prototype for function 'dce60_get_dp_ref_freq_khz' Hello, the mentioned branch requires the following commit, but it is already applied in 5.10 released kernel, so I really do not know what next step here. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8c4e4fd607b17973e54a7e9cc4c275b12ab7308e<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.git%2Fcommit%2F%3Fid%3D8c4e4fd607b17973e54a7e9cc4c275b12ab7308e=04%7C01%7Calexander.deucher%40amd.com%7C2ccddb80b2194b87979e08d8a12d78e3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637436563973465049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=4s%2Br5bporx1FuRLkI%2FJbJug4qPqKaIxwu6DJCaCG01U%3D=0> Mauro On Tue, Dec 15, 2020 at 11:24 AM kernel test robot mailto:l...@intel.com>> wrote: tree: git://people.freedesktop.org/~agd5f/linux.git<https://nam11.safelinks.protection.outlook.com/?url=http:%2F%2Fpeople.freedesktop.org%2F~agd5f%2Flinux.git=04%7C01%7Calexander.deucher%40amd.com%7C2ccddb80b2194b87979e08d8a12d78e3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637436563973475007%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=AwRdBRY9CLM5kV4FvQeKFMR1t8R6uEU%2BOvVLkhqQmwQ%3D=0> amd-20.45 head: a3950d94b046fb206e58fd3ec717f071c0203ba3 commit: e809646e73921328d66a2fbfddf067b9cdb30998 [1953/2427] drm/amd/display: enable SI support in the Kconfig (v2) config: x86_64-randconfig-a001-20201214 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fllvm%2Fllvm-project=04%7C01%7Calexander.deucher%40amd.com%7C2ccddb80b2194b87979e08d8a12d78e3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637436563973475007%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=pR0HOEIksASstlWPFMR8Eq9e6v%2BTPBQ8lhfPVy%2Bu1iI%3D=0> a29ecca7819a6ed4250d3689b12b1f664bb790d7) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintel%2Flkp-tests%2Fmaster%2Fsbin%2Fmake.cross=04%7C01%7Calexander.deucher%40amd.com%7C2ccddb80b2194b87979e08d8a12d78e3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637436563973484960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=J9LnzLuz5PGRhi4YFVdiTNq8sQUJ3igy%2FtJWq3BrsSE%3D=0> -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git<https://nam11.safelinks.protection.outlook.com/?url=http:%2F%2Fpeople.freedesktop.org%2F~agd5f%2Flinux.git=04%7C01%7Calexander.deucher%40amd.com%7C2ccddb80b2194b87979e08d8a12d78e3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637436563973484960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=a%2FwjGAjiR1C5wpjwPtmt%2BLkwVcix2gwFzsBvYB8PmDs%3D=0> git fetch --no-tags radeon-alex amd-20.45 git checkout e809646e73921328d66a2fbfddf067b9cdb30998 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot mailto:l...@intel.com>> All warnings (new ones prefixed by >>): >> drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce60/dce60_clk_mgr.c:83:5: >> warning: no previous prototype for function 'dce60_get_dp_ref_freq_khz' >> [-Wmissing-prototypes] int dce60_get_dp_ref_freq_khz(struct clk_mgr *clk_mgr_base) ^ drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce60/dce60_clk_mgr.c:83:1: note: declare 'static' if the function is not intended to be used outside of this translation unit int dce60_get_dp_ref_freq_khz(struct clk_mgr *clk_mgr_base) ^ static 1 warning generated. vim +/dce60_get_dp_ref_freq_khz +83 drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/
Re: [radeon-alex:amd-20.45 2127/2427] drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1880:39: sparse: sparse: incorrect type in argument 1 (different base types)
[AMD Public Use]
The test robot should probably not be testing the amd-20.xx branches in the
first place. They are just mirrors of our packaged drivers so they contain a
bunch of stuff that will never go upstream like kernel compatibility layers and
dkms support.
Alex
From: Qinglang Miao
Sent: Tuesday, December 15, 2020 3:21 AM
To: kernel test robot ; Deucher, Alexander
Cc: kbuild-...@lists.01.org ;
dri-devel@lists.freedesktop.org ; Xiong, Yang
(Felix)
Subject: Re: [radeon-alex:amd-20.45 2127/2427]
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1880:39: sparse:
sparse: incorrect type in argument 1 (different base types)
Hi Alex,
I think it's not a valid report from kernel test robot, for __le16 ought
to be the right type for cpu_to_le16. The sparse warnings seems not
right so I did't try effort to reproduce it.
otherwise, when I take a carful look at this patch, an unconditional
braces exists and I'm not sure about its benefit.
if (bp_params->flags.INTERLACE) {
params.susModeMiscInfo.usAccess =
cpu_to_le16(le16_to_cpu(params.susModeMiscInfo.usAccess) |
ATOM_INTERLACE);
{
le16_add_cpu(_SyncOffset, 1);
}
}
patch link:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2FCADnq5_PunHA1VHHj7VtEHG6o2Z_Z1WS325y_R9xO%2BgsV_JCOXw%40mail.gmail.com%2Fdata=04%7C01%7Calexander.deucher%40amd.com%7Cc9a5d9273f464451b1f808d8a0d271fe%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637436173010744629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=1TmtjBXJLf60sxq%2BH%2BVmMhnRV%2FuyIKQD2BYDVWMxmUA%3Dreserved=0
How do you think?
在 2020/12/15 14:44, kernel test robot 写道:
> tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
> head: a3950d94b046fb206e58fd3ec717f071c0203ba3
> commit: c82b6c9ed412fb7009b02dd82e50ee24f451e9a8 [2127/2427] drm/amd/display:
> convert to use le16_add_cpu()
> config: arc-randconfig-s031-20201214 (attached as .config)
> compiler: arc-elf-gcc (GCC) 9.3.0
> reproduce:
> wget
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintel%2Flkp-tests%2Fmaster%2Fsbin%2Fmake.crossdata=04%7C01%7Calexander.deucher%40amd.com%7Cc9a5d9273f464451b1f808d8a0d271fe%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637436173010754583%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=DCHDVGjiXhPDoCTofTf0pxHspdydDs1JXneGoSGPgFQ%3Dreserved=0
> -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # apt-get install sparse
> # sparse version: v0.6.3-184-g1b896707-dirty
> git remote add radeon-alex
> git://people.freedesktop.org/~agd5f/linux.git
> git fetch --no-tags radeon-alex amd-20.45
> git checkout c82b6c9ed412fb7009b02dd82e50ee24f451e9a8
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
> CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arc
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
>
> "sparse warnings: (new ones prefixed by >>)"
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:879:43:
> sparse: sparse: incorrect type in assignment (different base types) @@
> expected unsigned int [addressable] [assigned] [usertype] ulSymClock @@
> got restricted __le16 [usertype] @@
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:879:43:
> sparse: expected unsigned int [addressable] [assigned] [usertype]
> ulSymClock
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:879:43:
> sparse: got restricted __le16 [usertype]
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:956:40:
> sparse: sparse: incorrect type in assignment (different base types) @@
> expected unsigned short [addressable] [assigned] [usertype] usRefDiv @@
> got restricted __le16 [usertype] @@
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:956:40:
> sparse: expected unsigned short [addressable] [assigned] [usertype]
> usRefDiv
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:956:40:
> sparse: got restricted __le16 [usertype]
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:958:39:
> sparse: sparse: incorrect type in assignment (different base types) @@
> expected unsigned short [addressable] [assigned] [usertype] usFbDiv @@
> got restricted __le16 [usertype] @@
> drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:958:39:
> sparse: expected unsig
RE: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL
[AMD Public Use] > -Original Message- > From: Greg KH > Sent: Tuesday, November 3, 2020 1:53 AM > To: Koenig, Christian > Cc: Alex Deucher ; Deepak R Varma > ; David Airlie ; LKML ker...@vger.kernel.org>; Maling list - DRI developers de...@lists.freedesktop.org>; Melissa Wen ; > amd-gfx list ; Daniel Vetter > ; Daniel Vetter ; Deucher, > Alexander > Subject: Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or > NULL > > On Mon, Nov 02, 2020 at 09:06:21PM +0100, Christian König wrote: > > Am 02.11.20 um 20:43 schrieb Alex Deucher: > > > On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma > wrote: > > > > Initializing global variable to 0 or NULL is not necessary and > > > > should be avoided. Issue reported by checkpatch script as: > > > > ERROR: do not initialise globals to 0 (or NULL). > > > I agree that this is technically correct, but a lot of people don't > > > seem to know that so we get a lot of comments about this code for > > > the variables that are not explicitly set. Seems less confusing to > > > initialize them even if it not necessary. I don't have a > > > particularly strong opinion on it however. > > > > Agree with Alex. > > > > Especially for the module parameters we should have a explicit init > > value for documentation purposes, even when it is 0. > > Why is this one tiny driver somehow special compared to the entire rest of > the kernel? (hint, it isn't...) > > Please follow the normal coding style rules, there's no reason to ignore them > unless you like to constantly reject patches like this that get sent to you. > I'll apply the patch, but as a data point, this is the first time I've gotten a patch to make this change. I get several bug reports or patches every year to explicitly set values to global variables because users assume they are not initialized. So it will always be a trade off as to which patches you want to NACK. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 6/7] drm: Validate encoder->possible_crtcs
[AMD Public Use]
> -Original Message-
> From: amd-gfx On Behalf Of
> Daniel Vetter
> Sent: Monday, September 7, 2020 3:15 AM
> To: Jan Kiszka ; amd-gfx list g...@lists.freedesktop.org>; Wentland, Harry ;
> Kazlauskas, Nicholas
> Cc: dri-devel ; intel-gfx g...@lists.freedesktop.org>; Thomas Zimmermann
> ; Ville Syrjala
> Subject: Re: [PATCH v3 6/7] drm: Validate encoder->possible_crtcs
>
> On Sun, Sep 6, 2020 at 1:19 PM Jan Kiszka wrote:
> >
> > On 11.02.20 18:04, Daniel Vetter wrote:
> > > On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote:
> > >> From: Ville Syrjälä
> > >>
> > >> WARN if the encoder possible_crtcs is effectively empty or contains
> > >> bits for non-existing crtcs.
> > >>
> > >> v2: Move to drm_mode_config_validate() (Daniel)
> > >> Make the docs say we WARN when this is wrong (Daniel)
> > >> Extract full_crtc_mask()
> > >>
> > >> Cc: Thomas Zimmermann
> > >> Cc: Daniel Vetter
> > >> Signed-off-by: Ville Syrjälä
> > >
> > > When pushing the fixup needs to be applied before the validation
> > > patch here, because we don't want to anger the bisect gods.
> > >
> > > Reviewed-by: Daniel Vetter
> > >
> > > I think with the fixup we should be good enough with the existing
> > > nonsense in drivers. Fingers crossed.
> > > -Daniel
> > >
> > >
> > >> ---
> > >> drivers/gpu/drm/drm_mode_config.c | 27
> ++-
> > >> include/drm/drm_encoder.h | 2 +-
> > >> 2 files changed, 27 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_mode_config.c
> > >> b/drivers/gpu/drm/drm_mode_config.c
> > >> index afc91447293a..4c1b350ddb95 100644
> > >> --- a/drivers/gpu/drm/drm_mode_config.c
> > >> +++ b/drivers/gpu/drm/drm_mode_config.c
> > >> @@ -581,6 +581,29 @@ static void
> validate_encoder_possible_clones(struct drm_encoder *encoder)
> > >> encoder->possible_clones, encoder_mask); }
> > >>
> > >> +static u32 full_crtc_mask(struct drm_device *dev) {
> > >> +struct drm_crtc *crtc;
> > >> +u32 crtc_mask = 0;
> > >> +
> > >> +drm_for_each_crtc(crtc, dev)
> > >> +crtc_mask |= drm_crtc_mask(crtc);
> > >> +
> > >> +return crtc_mask;
> > >> +}
> > >> +
> > >> +static void validate_encoder_possible_crtcs(struct drm_encoder
> > >> +*encoder) {
> > >> +u32 crtc_mask = full_crtc_mask(encoder->dev);
> > >> +
> > >> +WARN((encoder->possible_crtcs & crtc_mask) == 0 ||
> > >> + (encoder->possible_crtcs & ~crtc_mask) != 0,
> > >> + "Bogus possible_crtcs: "
> > >> + "[ENCODER:%d:%s] possible_crtcs=0x%x (full crtc mask=0x%x)\n",
> > >> + encoder->base.id, encoder->name,
> > >> + encoder->possible_crtcs, crtc_mask); }
> > >> +
> > >> void drm_mode_config_validate(struct drm_device *dev) {
> > >> struct drm_encoder *encoder;
> > >> @@ -588,6 +611,8 @@ void drm_mode_config_validate(struct
> drm_device *dev)
> > >> drm_for_each_encoder(encoder, dev)
> > >> fixup_encoder_possible_clones(encoder);
> > >>
> > >> -drm_for_each_encoder(encoder, dev)
> > >> +drm_for_each_encoder(encoder, dev) {
> > >> validate_encoder_possible_clones(encoder);
> > >> +validate_encoder_possible_crtcs(encoder);
> > >> +}
> > >> }
> > >> diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
> > >> index 3741963b9587..b236269f41ac 100644
> > >> --- a/include/drm/drm_encoder.h
> > >> +++ b/include/drm/drm_encoder.h
> > >> @@ -142,7 +142,7 @@ struct drm_encoder {
> > >> * the bits for all _crtc objects this encoder can be connected
> > >> to
> > >> * before calling drm_dev_register().
> > >> *
> > >> - * In reality almost every driver gets this wrong.
> > >> + * You will get a WARN if you get this wrong in the driver.
> > >> *
> > >> * Note that since CRTC objects can't be hotplugged the assigned
> indices
> > >> * are stable and hence known before registering all objects.
> > >> --
> > >> 2.24.1
> > >>
> > >
> >
> > Triggers on an Advantech AIMB-228 (R1505G, 3 DP outputs):
>
> Adding amdgpu display folks.
I took a quick look at this and it looks like we limit the number of crtcs
later in the mode init process if the number of physical displays can't
actually use more crtcs. E.g., the physical board configuration would only
allow for 3 active displays even if the hardware technically supports 4 crtcs.
I presume that way we can just leave the additional hardware power gated all
the time.
Alex
> -Daniel
>
> >
> > [ 14.033246] [ cut here ]
> > [ 14.033248] Bogus possible_crtcs: [ENCODER:65:TMDS-65]
> possible_crtcs=0xf (full crtc mask=0x7)
> > [ 14.033279] WARNING: CPU: 0 PID: 282 at
> ../drivers/gpu/drm/drm_mode_config.c:622
> drm_mode_config_validate+0x17d/0x200 [drm]
> > [ 14.033279] Modules linked in: amdgpu(E+) mfd_core(E)
> snd_hda_codec_realtek(E) kvm_amd(E) gpu_sched(E) i2c_algo_bit(E) ttm(E)
>
Re: [PATCH 1/1] drm/ttm: fix offset in VMAs with a pg_offs in ttm_bo_vm_access
[AMD Public Use]
Christian, Can you cc stable when you apply it to drm-misc?
Alex
From: Kuehling, Felix
Sent: Wednesday, July 29, 2020 10:15 AM
To: Koenig, Christian ;
dri-devel@lists.freedesktop.org ;
amd-...@lists.freedesktop.org ; Deucher,
Alexander
Cc: Morichetti, Laurent
Subject: Re: [PATCH 1/1] drm/ttm: fix offset in VMAs with a pg_offs in
ttm_bo_vm_access
Am 2020-07-29 um 4:08 a.m. schrieb Christian König:
> Am 28.07.20 um 20:27 schrieb Felix Kuehling:
>> VMAs with a pg_offs that's offset from the start of the vma_node need
>> to adjust the offset within the BO accordingly. This matches the
>> offset calculation in ttm_bo_vm_fault_reserved.
>>
>> Signed-off-by: Felix Kuehling
>> Tested-by: Laurent Morichetti
>
> Reviewed-by: Christian König
>
> Going to pick that up for inclusion in drm-misc-next.
Thanks. I'll submit it to amd-staging-drm-next so it makes its way into
our DKMS branch quickly.
Alex, would you push this to drm-fixes?
Regards,
Felix
>
>> ---
>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> index 389128b8c4dd..60b41447bec8 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> @@ -405,8 +405,10 @@ static int ttm_bo_vm_access_kmap(struct
>> ttm_buffer_object *bo,
>> int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr,
>>void *buf, int len, int write)
>> {
>> -unsigned long offset = (addr) - vma->vm_start;
>> struct ttm_buffer_object *bo = vma->vm_private_data;
>> +unsigned long offset = (addr) - vma->vm_start +
>> +((vma->vm_pgoff - drm_vma_node_start(>base.vma_node))
>> + << PAGE_SHIFT);
>> int ret;
>> if (len < 1 || (offset + len) >> PAGE_SHIFT > bo->num_pages)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: add dmcub check on RENOIR
[AMD Public Use] Acked-by: Alex Deucher From: Aaron Ma Sent: Wednesday, July 8, 2020 4:16 AM To: Wentland, Harry ; Li, Sun peng (Leo) ; Deucher, Alexander ; Koenig, Christian ; airl...@linux.ie ; dan...@ffwll.ch ; amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org ; linux-ker...@vger.kernel.org ; mapen...@gmail.com ; aaron...@canonical.com Subject: [PATCH] drm/amd/display: add dmcub check on RENOIR RENOIR loads dmub fw not dmcu, check dmcu only will prevent loading iram, it breaks backlight control. Bug: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D208277data=02%7C01%7Calexander.deucher%40amd.com%7Cf922a1848f1f4cc4934f08d823174036%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637297930080282163sdata=limstWv5pwvdqDRpKoKpCZcutV4pmqhdqR7CFEimR2Q%3Dreserved=0 Signed-off-by: Aaron Ma --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 10ac8076d4f2..db5e0bb0d935 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -1358,7 +1358,7 @@ static int dm_late_init(void *handle) struct dmcu *dmcu = NULL; bool ret; - if (!adev->dm.fw_dmcu) + if (!adev->dm.fw_dmcu && !adev->dm.dmub_fw) return detect_mst_link_for_all_connectors(adev->ddev); dmcu = adev->dm.dc->res_pool->dmcu; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 5.6 33/50] drm/amdgpu: bump version for invalidate L2 before SDMA IBs
[AMD Public Use] Yes, please drop this patch for stable. Alex From: Marek Olšák Sent: Monday, May 18, 2020 6:35 PM To: Sasha Levin Cc: Linux Kernel Mailing List ; sta...@vger.kernel.org ; Pelloux-prayer, Pierre-eric ; Olsak, Marek ; amd-gfx mailing list ; dri-devel ; Deucher, Alexander ; Koenig, Christian Subject: Re: [PATCH AUTOSEL 5.6 33/50] drm/amdgpu: bump version for invalidate L2 before SDMA IBs Hi Sasha, I disagree with this. Bumping the driver version will have implications on other new features, because it's like an ABI barrier exposing new functionality. Marek On Thu, May 7, 2020 at 10:28 AM Sasha Levin mailto:sas...@kernel.org>> wrote: From: Marek Olšák mailto:marek.ol...@amd.com>> [ Upstream commit 9017a4897a20658f010bebea825262963c10afa6 ] This fixes GPU hangs due to cache coherency issues. Bump the driver version. Split out from the original patch. Signed-off-by: Marek Olšák mailto:marek.ol...@amd.com>> Reviewed-by: Christian König mailto:christian.koe...@amd.com>> Tested-by: Pierre-Eric Pelloux-Prayer mailto:pierre-eric.pelloux-pra...@amd.com>> Signed-off-by: Alex Deucher mailto:alexander.deuc...@amd.com>> Signed-off-by: Sasha Levin mailto:sas...@kernel.org>> --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 42f4febe24c6d..8d45a2b662aeb 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -85,9 +85,10 @@ * - 3.34.0 - Non-DC can flip correctly between buffers with different pitches * - 3.35.0 - Add drm_amdgpu_info_device::tcc_disabled_mask * - 3.36.0 - Allow reading more status registers on si/cik + * - 3.37.0 - L2 is invalidated before SDMA IBs, needed for correctness */ #define KMS_DRIVER_MAJOR 3 -#define KMS_DRIVER_MINOR 36 +#define KMS_DRIVER_MINOR 37 #define KMS_DRIVER_PATCHLEVEL 0 int amdgpu_vram_limit = 0; -- 2.20.1 ___ amd-gfx mailing list amd-...@lists.freedesktop.org<mailto:amd-...@lists.freedesktop.org> https://lists.freedesktop.org/mailman/listinfo/amd-gfx<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx=02%7C01%7Calexander.deucher%40amd.com%7C2bb4939b162b4d66d57708d7fb7bd608%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637254381604715852=uJEI0CDUeUbUGUgnhnobpKygBueEGg6UqwgzkEtIsh8%3D=0> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Optimized division operation to shift operation
[AMD Public Use] I've gone ahead and dropped the patch. Alex From: Koenig, Christian Sent: Wednesday, April 15, 2020 3:57 AM To: Jani Nikula ; Alex Deucher ; Bernard Zhao Cc: Sierra Guiza, Alejandro (Alex) ; Zeng, Oak ; Maling list - DRI developers ; David Airlie ; Kuehling, Felix ; LKML ; amd-gfx list ; ker...@vivo.com ; Huang, Ray ; Russell, Kent ; Deucher, Alexander ; Sam Ravnborg ; Yuan, Xiaojie Subject: Re: [PATCH] Optimized division operation to shift operation Am 15.04.20 um 09:41 schrieb Jani Nikula: > On Tue, 14 Apr 2020, Alex Deucher wrote: >> On Tue, Apr 14, 2020 at 9:05 AM Bernard Zhao wrote: >>> On some processors, the / operate will call the compiler`s div lib, >>> which is low efficient, We can replace the / operation with shift, >>> so that we can replace the call of the division library with one >>> shift assembly instruction. > This was applied already, and it's not in a driver I look after... but > to me this feels like something that really should be > justified. Using >> instead of / for multiples of 2 division mattered 20 > years ago, I'd be surprised if it still did on modern compilers. I have similar worries, especially since we replace the "/ (4 * 2)" with ">> 3" it's making the code just a bit less readable. And that the code runs exactly once while loading the driver and pushing the firmware into the hardware. So performance is completely irrelevant here. Regards, Christian. > > BR, > Jani. > > >>> Signed-off-by: Bernard Zhao >> Applied. thanks. >> >> Alex >> >>> --- >>> drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 4 ++-- >>> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 4 ++-- >>> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 4 ++-- >>> 3 files changed, 6 insertions(+), 6 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c >>> b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c >>> index b205039..66cd078 100644 >>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c >>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c >>> @@ -175,10 +175,10 @@ static int gmc_v6_0_mc_load_microcode(struct >>> amdgpu_device *adev) >>> amdgpu_ucode_print_mc_hdr(>header); >>> >>> adev->gmc.fw_version = le32_to_cpu(hdr->header.ucode_version); >>> - regs_size = le32_to_cpu(hdr->io_debug_size_bytes) / (4 * 2); >>> + regs_size = le32_to_cpu(hdr->io_debug_size_bytes) >> 3; >>> new_io_mc_regs = (const __le32 *) >>> (adev->gmc.fw->data + >>> le32_to_cpu(hdr->io_debug_array_offset_bytes)); >>> - ucode_size = le32_to_cpu(hdr->header.ucode_size_bytes) / 4; >>> + ucode_size = le32_to_cpu(hdr->header.ucode_size_bytes) >> 2; >>> new_fw_data = (const __le32 *) >>> (adev->gmc.fw->data + >>> le32_to_cpu(hdr->header.ucode_array_offset_bytes)); >>> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c >>> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c >>> index 9da9596..ca26d63 100644 >>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c >>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c >>> @@ -193,10 +193,10 @@ static int gmc_v7_0_mc_load_microcode(struct >>> amdgpu_device *adev) >>> amdgpu_ucode_print_mc_hdr(>header); >>> >>> adev->gmc.fw_version = le32_to_cpu(hdr->header.ucode_version); >>> - regs_size = le32_to_cpu(hdr->io_debug_size_bytes) / (4 * 2); >>> + regs_size = le32_to_cpu(hdr->io_debug_size_bytes) >> 3; >>> io_mc_regs = (const __le32 *) >>> (adev->gmc.fw->data + >>> le32_to_cpu(hdr->io_debug_array_offset_bytes)); >>> - ucode_size = le32_to_cpu(hdr->header.ucode_size_bytes) / 4; >>> + ucode_size = le32_to_cpu(hdr->header.ucode_size_bytes) >> 2; >>> fw_data = (const __le32 *) >>> (adev->gmc.fw->data + >>> le32_to_cpu(hdr->header.ucode_array_offset_bytes)); >>> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c >>> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c >>> index 27d83204..295039c 100644 >>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c >>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c >>> @@ -318,10 +318,10 @@ static int gmc_v8_0_tonga_mc_load_microcode(struct >>> amdgpu_device *adev) >>> amdgpu_ucode_print_mc_hdr(>header); >>
RE: mainline/master bisection: baseline.login on peach-pi
[AMD Official Use Only - Internal Distribution Only] > -Original Message- > From: Guillaume Tucker > Sent: Friday, April 3, 2020 10:14 AM > To: Michael J. Ruhl ; Shane Francis > ; Deucher, Alexander > > Cc: kerne...@groups.io; dri-devel@lists.freedesktop.org; linux- > ker...@vger.kernel.org; Tom Murphy ; Joerg Roedel > ; David Airlie ; Maarten Lankhorst > ; Daniel Vetter ; > Maxime Ripard ; Enric Balletbo i Serra > > Subject: Re: mainline/master bisection: baseline.login on peach-pi > > Please see the bisection report below about a boot failure. > > Reports aren't automatically sent to the public while we're trialing new > bisection features on kernelci.org but this one looks valid. > > This bisection was run with exynos_defconfig but the issue can also be > reproduced with multi_v7_defconfig. It doesn't appear to be affecting any > other platforms on kernelci.org. This looks like a DRM driver problem, the > kernel image boots fine without the modules installed. It actually started > failing on Tuesday in mainline. Fixed with this patch: https://patchwork.freedesktop.org/patch/359081/ Just trying to get this into 5.7 and stable. I was waiting for a 5.6 back merge to drm-misc-next-fixes, but I could send it as a separate PR if Dave or Daniel prefer. Alex > > Guillaume > > On 02/04/2020 19:38, kernelci.org bot wrote: > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > * This automated bisection report was sent to you on the basis * > > * that you may be involved with the breaking commit it has * > > * found. No manual investigation has been done to verify it, * > > * and the root cause of the problem may be somewhere else. * > > * * > > * If you do send a fix, please include this trailer:* > > * Reported-by: "kernelci.org bot" * > > * * > > * Hope this helps! * > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > > > mainline/master bisection: baseline.login on peach-pi > > > > Summary: > > Start: 56a451b780676 Merge tag 'ntb-5.7' of > git://github.com/jonmason/ntb > > Plain log: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstor > age.kernelci.org%2F%2Fmainline%2Fmaster%2Fv5.6-3277- > g56a451b78067%2Farm%2Fexynos_defconfig%2Fgcc-8%2Flab- > collabora%2Fbaseline-exynos5800-peach- > pi.txtdata=02%7C01%7Calexander.deucher%40amd.com%7Ca1d322a4 > f72744bfe14208d7d7d9398f%7C3dd8961fe4884e608e11a82d994e183d%7C0% > 7C0%7C637215200294572061sdata=pJ%2F8FHi6grBy4aGUuL%2F9%2Bj > %2FVqrWJfStjBCaDUnBoUMI%3Dreserved=0 > > HTML log: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstor > age.kernelci.org%2F%2Fmainline%2Fmaster%2Fv5.6-3277- > g56a451b78067%2Farm%2Fexynos_defconfig%2Fgcc-8%2Flab- > collabora%2Fbaseline-exynos5800-peach- > pi.htmldata=02%7C01%7Calexander.deucher%40amd.com%7Ca1d322 > a4f72744bfe14208d7d7d9398f%7C3dd8961fe4884e608e11a82d994e183d%7C0 > %7C0%7C637215200294572061sdata=pSoe45cMygTcp0UXe3DY%2F6jeI > EChQ5FwsPO32A4%2Bhh8%3Dreserved=0 > > Result: 42e67b479eab6 drm/prime: use dma length macro when > mapping sg > > > > Checks: > > revert: PASS > > verify: PASS > > > > Parameters: > > Tree: mainline > > URL: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.k > ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git& > amp;data=02%7C01%7Calexander.deucher%40amd.com%7Ca1d322a4f72744 > bfe14208d7d7d9398f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7 > C637215200294572061sdata=MW1XaSNAKSVByF8eOG2%2Bv59Mqjwi > 7Cu6QaU87AZbka8%3Dreserved=0 > > Branch: master > > Target: peach-pi > > CPU arch: arm > > Lab:lab-collabora > > Compiler: gcc-8 > > Config: exynos_defconfig > > Test case: baseline.login > > > > Breaking commit found: > > > > -- > > - commit 42e67b479eab6d26459b80b4867298232b0435e7 > > Author: Shane Francis > > Date: Wed Mar 25 09:07:39 2020 + > > > > drm/prime: use dma length macro when mapping sg > > > > As dma_map_sg can reorganize scatter-gather lists in a > > way that can cause some later segments to be empty we should > > always use the sg_dma_len macro to fetch the actual length. > > > > Th
RE: [PATCH] drm/amd/display: fix undefined struct member reference
> -Original Message-
> From: Kazlauskas, Nicholas
> Sent: Tuesday, December 10, 2019 3:56 PM
> To: Liu, Zhan ; Arnd Bergmann ;
> Wentland, Harry ; Li, Sun peng (Leo)
> ; Deucher, Alexander
> ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; David Airlie ; Daniel Vetter
>
> Cc: Liu, Charlene ; Yang, Eric
> ; linux-ker...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; Cornij, Nikola ;
> Laktyushkin, Dmytro ; dri-
> de...@lists.freedesktop.org; Lei, Jun ; Lakha,
> Bhawanpreet
> Subject: Re: [PATCH] drm/amd/display: fix undefined struct member
> reference
>
> On 2019-12-10 3:54 p.m., Liu, Zhan wrote:
> >
> >
> >> -Original Message-
> >> From: Arnd Bergmann
> >> Sent: 2019/December/10, Tuesday 3:31 PM
> >> To: Wentland, Harry ; Li, Sun peng (Leo)
> >> ; Deucher, Alexander
> ;
> >> Koenig, Christian ; Zhou, David(ChunMing)
> >> ; David Airlie ; Daniel Vetter
> >> ; Liu, Zhan
> >> Cc: Arnd Bergmann ; Laktyushkin, Dmytro
> >> ; Lakha, Bhawanpreet
> >> ; Lei, Jun ; Liu,
> >> Charlene ; Yang, Eric ;
> >> Cornij, Nikola ;
> >> amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> >> linux-ker...@vger.kernel.org
> >> Subject: [PATCH] drm/amd/display: fix undefined struct member
> >> reference
> >>
> >> An initialization was added for two optional struct members. One of
> >> these is always present in the dcn20_resource file, but the other one
> >> depends on CONFIG_DRM_AMD_DC_DSC_SUPPORT and causes a build
> failure
> >> if that is
> >> missing:
> >>
> >>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:926:1
> >> 4: error: excess elements in struct initializer [-Werror]
> >> .num_dsc = 5,
> >>
> >> Add another #ifdef around the assignment.
> >>
> >> Fixes: c3d03c5a196f ("drm/amd/display: Include num_vmid and num_dsc
> >> within NV14's resource caps")
> >> Signed-off-by: Arnd Bergmann
> >
> > Thank you for catching that On my side I kept that flag enabled all the
> time, so I didn't realize there was a warning hidden here.
> >
> > Reviewed-by: Zhan Liu
>
> What tree is this reported on?
>
> We dropped this flag whenever building DCN. Sounds like we're missing a
> patch if you're getting this.
>
> So this is a NAK from me for going into amd-staging-drm-next at least.
>
Those patches are not upstream yet. They are queued for 5.6. So we need this
patch for 5.5. I'll apply it.
Alex
> Nicholas Kazlauskas
>
> >
> >> ---
> >> drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> >> b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> >> index faab89d1e694..fdf93e6edf43 100644
> >> --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> >> +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> >> @@ -923,7 +923,9 @@ static const struct resource_caps res_cap_nv14 = {
> >>.num_dwb = 1,
> >>.num_ddc = 5,
> >>.num_vmid = 16,
> >> +#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
> >>.num_dsc = 5,
> >> +#endif
> >> };
> >>
> >> static const struct dc_debug_options debug_defaults_drv = {
> >> --
> >> 2.20.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
[AMD Official Use Only - Internal Distribution Only] Cherry pick whatever dependencies you need or pick the older version of the patch. Either way works. Alex From: Grodzovsky, Andrey Sent: Tuesday, December 3, 2019 2:57 PM To: Deucher, Alexander ; Deng, Emily Cc: dri-devel@lists.freedesktop.org ; amd-...@lists.freedesktop.org ; Koenig, Christian ; steven.pr...@arm.com Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job. I don't think i can apply this patch 'as is' as this has dependency on patch by Steven which also wasn't applied yet - 588b982 Steven Price6 weeks ago drm: Don't free jobs in wait_event_interruptible() Andrey On 12/3/19 2:44 PM, Deucher, Alexander wrote: [AMD Official Use Only - Internal Distribution Only] Please go ahead an apply whatever version is necessary for amd-staging-drm-next. Alex From: Grodzovsky, Andrey <mailto:andrey.grodzov...@amd.com> Sent: Tuesday, December 3, 2019 2:10 PM To: Deng, Emily <mailto:emily.d...@amd.com>; Deucher, Alexander <mailto:alexander.deuc...@amd.com> Cc: dri-devel@lists.freedesktop.org<mailto:dri-devel@lists.freedesktop.org> <mailto:dri-devel@lists.freedesktop.org>; amd-...@lists.freedesktop.org<mailto:amd-...@lists.freedesktop.org> <mailto:amd-...@lists.freedesktop.org>; Koenig, Christian <mailto:christian.koe...@amd.com>; steven.pr...@arm.com<mailto:steven.pr...@arm.com> <mailto:steven.pr...@arm.com> Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job. Yes - Christian just pushed it to drm-next-misc - I guess Alex/Christian didn't pull to amd-staging-drm-next yet. Andrey On 12/2/19 2:24 PM, Deng, Emily wrote: > [AMD Official Use Only - Internal Distribution Only] > > Hi Andrey, > Seems this patch is still not in amd-staging-drm-next? > > Best wishes > Emily Deng > > > >> -Original Message- >> From: Deng, Emily >> Sent: Tuesday, November 26, 2019 4:41 PM >> To: Grodzovsky, Andrey >> <mailto:andrey.grodzov...@amd.com> >> Cc: dri-devel@lists.freedesktop.org<mailto:dri-devel@lists.freedesktop.org>; >> amd-...@lists.freedesktop.org<mailto:amd-...@lists.freedesktop.org>; Koenig, >> Christian <mailto:christian.koe...@amd.com>; >> steven.pr...@arm.com<mailto:steven.pr...@arm.com> >> Subject: RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job. >> >> [AMD Official Use Only - Internal Distribution Only] >> >> Reviewed-by: Emily Deng <mailto:emily.d...@amd.com> >> >>> -Original Message- >>> From: Grodzovsky, Andrey >>> <mailto:andrey.grodzov...@amd.com> >>> Sent: Tuesday, November 26, 2019 7:37 AM >>> Cc: >>> dri-devel@lists.freedesktop.org<mailto:dri-devel@lists.freedesktop.org>; >>> amd-...@lists.freedesktop.org<mailto:amd-...@lists.freedesktop.org>; >>> Koenig, Christian >>> <mailto:christian.koe...@amd.com>; Deng, Emily >>> <mailto:emily.d...@amd.com>; >>> steven.pr...@arm.com<mailto:steven.pr...@arm.com> >>> Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job. >>> >>> Ping >>> >>> Andrey >>> >>> On 11/25/19 3:51 PM, Andrey Grodzovsky wrote: >>>> Problem: >>>> Due to a race between drm_sched_cleanup_jobs in sched thread and >>>> drm_sched_job_timedout in timeout work there is a possiblity that bad >>>> job was already freed while still being accessed from the timeout >>>> thread. >>>> >>>> Fix: >>>> Instead of just peeking at the bad job in the mirror list remove it >>>> from the list under lock and then put it back later when we are >>>> garanteed no race with main sched thread is possible which is after >>>> the thread is parked. >>>> >>>> v2: Lock around processing ring_mirror_list in drm_sched_cleanup_jobs. >>>> >>>> v3: Rebase on top of drm-misc-next. v2 is not needed anymore as >>>> drm_sched_get_cleanup_job already has a lock there. >>>> >>>> v4: Fix comments to relfect latest code in drm-misc. >>>> >>>> Signed-off-by: Andrey Grodzovsky >>>> <mailto:andrey.grodzov...@amd.com> >>>> Reviewed-by: Christian König >>>> <mailto:christian.koe...@amd.com> >>>> Tested-by: Emily Deng <mailto:emily.d...@amd.com> >>>> --- >>>>drivers/gpu/drm/scheduler/sched_main.c | 27 >>> +++ >>
Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
[AMD Official Use Only - Internal Distribution Only]
Please go ahead an apply whatever version is necessary for amd-staging-drm-next.
Alex
From: Grodzovsky, Andrey
Sent: Tuesday, December 3, 2019 2:10 PM
To: Deng, Emily ; Deucher, Alexander
Cc: dri-devel@lists.freedesktop.org ;
amd-...@lists.freedesktop.org ; Koenig,
Christian ; steven.pr...@arm.com
Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
Yes - Christian just pushed it to drm-next-misc - I guess Alex/Christian
didn't pull to amd-staging-drm-next yet.
Andrey
On 12/2/19 2:24 PM, Deng, Emily wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Andrey,
> Seems this patch is still not in amd-staging-drm-next?
>
> Best wishes
> Emily Deng
>
>
>
>> -Original Message-
>> From: Deng, Emily
>> Sent: Tuesday, November 26, 2019 4:41 PM
>> To: Grodzovsky, Andrey
>> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig,
>> Christian ; steven.pr...@arm.com
>> Subject: RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>>
>> [AMD Official Use Only - Internal Distribution Only]
>>
>> Reviewed-by: Emily Deng
>>
>>> -Original Message-
>>> From: Grodzovsky, Andrey
>>> Sent: Tuesday, November 26, 2019 7:37 AM
>>> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
>>> Koenig, Christian ; Deng, Emily
>>> ; steven.pr...@arm.com
>>> Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>>>
>>> Ping
>>>
>>> Andrey
>>>
>>> On 11/25/19 3:51 PM, Andrey Grodzovsky wrote:
>>>> Problem:
>>>> Due to a race between drm_sched_cleanup_jobs in sched thread and
>>>> drm_sched_job_timedout in timeout work there is a possiblity that bad
>>>> job was already freed while still being accessed from the timeout
>>>> thread.
>>>>
>>>> Fix:
>>>> Instead of just peeking at the bad job in the mirror list remove it
>>>> from the list under lock and then put it back later when we are
>>>> garanteed no race with main sched thread is possible which is after
>>>> the thread is parked.
>>>>
>>>> v2: Lock around processing ring_mirror_list in drm_sched_cleanup_jobs.
>>>>
>>>> v3: Rebase on top of drm-misc-next. v2 is not needed anymore as
>>>> drm_sched_get_cleanup_job already has a lock there.
>>>>
>>>> v4: Fix comments to relfect latest code in drm-misc.
>>>>
>>>> Signed-off-by: Andrey Grodzovsky
>>>> Reviewed-by: Christian König
>>>> Tested-by: Emily Deng
>>>> ---
>>>>drivers/gpu/drm/scheduler/sched_main.c | 27
>>> +++
>>>>1 file changed, 27 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>>>> b/drivers/gpu/drm/scheduler/sched_main.c
>>>> index 6774955..1bf9c40 100644
>>>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>>>> @@ -284,10 +284,21 @@ static void drm_sched_job_timedout(struct
>>> work_struct *work)
>>>> unsigned long flags;
>>>>
>>>> sched = container_of(work, struct drm_gpu_scheduler,
>>>> work_tdr.work);
>>>> +
>>>> + /* Protects against concurrent deletion in
>>> drm_sched_get_cleanup_job */
>>>> + spin_lock_irqsave(>job_list_lock, flags);
>>>> job = list_first_entry_or_null(>ring_mirror_list,
>>>>struct drm_sched_job, node);
>>>>
>>>> if (job) {
>>>> + /*
>>>> + * Remove the bad job so it cannot be freed by concurrent
>>>> + * drm_sched_cleanup_jobs. It will be reinserted back after
>>> sched->thread
>>>> + * is parked at which point it's safe.
>>>> + */
>>>> + list_del_init(>node);
>>>> + spin_unlock_irqrestore(>job_list_lock, flags);
>>>> +
>>>> job->sched->ops->timedout_job(job);
>>>>
>>>> /*
>>>> @@ -298,6 +309,8 @@ static void drm_sched_job_timedout(struct
>>> work_struct *work)
>>>> job->sched->ops->free_job(job);
>>>> sched->free_guilty = false;
>>
Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
I recently updated amd-staging-drm-next. Apply whatever makes sense for now
and it'll naturally fall out in the next rebase.
Alex
From: Grodzovsky, Andrey
Sent: Monday, November 25, 2019 7:09 PM
To: Deng, Emily
Cc: dri-devel@lists.freedesktop.org ;
amd-...@lists.freedesktop.org ; Koenig,
Christian ; steven.pr...@arm.com
; Deucher, Alexander
Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
Christian asked to submit it to drm-misc instead of our drm-next to avoid later
conflicts with Steven's patch which he mentioned in this thread which is not in
drm-next yet.
Christian, Alex, once this merged to drm-misc I guess we need to pull all
latest changes from there to drm-next so the issue Emily reported can be
avoided.
Andrey
From: Deng, Emily
Sent: 25 November 2019 16:44:36
To: Grodzovsky, Andrey
Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig,
Christian; steven.pr...@arm.com; Grodzovsky, Andrey
Subject: RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
[AMD Official Use Only - Internal Distribution Only]
Hi Andrey,
Seems you didn't submit this patch?
Best wishes
Emily Deng
>-Original Message-
>From: Andrey Grodzovsky
>Sent: Monday, November 25, 2019 12:51 PM
>Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig,
>Christian ; Deng, Emily
>; steven.pr...@arm.com; Grodzovsky, Andrey
>
>Subject: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>
>Problem:
>Due to a race between drm_sched_cleanup_jobs in sched thread and
>drm_sched_job_timedout in timeout work there is a possiblity that bad job
>was already freed while still being accessed from the timeout thread.
>
>Fix:
>Instead of just peeking at the bad job in the mirror list remove it from the
>list
>under lock and then put it back later when we are garanteed no race with
>main sched thread is possible which is after the thread is parked.
>
>v2: Lock around processing ring_mirror_list in drm_sched_cleanup_jobs.
>
>v3: Rebase on top of drm-misc-next. v2 is not needed anymore as
>drm_sched_get_cleanup_job already has a lock there.
>
>v4: Fix comments to relfect latest code in drm-misc.
>
>Signed-off-by: Andrey Grodzovsky
>Reviewed-by: Christian König
>Tested-by: Emily Deng
>---
> drivers/gpu/drm/scheduler/sched_main.c | 27
>+++
> 1 file changed, 27 insertions(+)
>
>diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>b/drivers/gpu/drm/scheduler/sched_main.c
>index 6774955..1bf9c40 100644
>--- a/drivers/gpu/drm/scheduler/sched_main.c
>+++ b/drivers/gpu/drm/scheduler/sched_main.c
>@@ -284,10 +284,21 @@ static void drm_sched_job_timedout(struct
>work_struct *work)
> unsigned long flags;
>
> sched = container_of(work, struct drm_gpu_scheduler,
>work_tdr.work);
>+
>+ /* Protects against concurrent deletion in
>drm_sched_get_cleanup_job */
>+ spin_lock_irqsave(>job_list_lock, flags);
> job = list_first_entry_or_null(>ring_mirror_list,
> struct drm_sched_job, node);
>
> if (job) {
>+ /*
>+ * Remove the bad job so it cannot be freed by concurrent
>+ * drm_sched_cleanup_jobs. It will be reinserted back after
>sched->thread
>+ * is parked at which point it's safe.
>+ */
>+ list_del_init(>node);
>+ spin_unlock_irqrestore(>job_list_lock, flags);
>+
> job->sched->ops->timedout_job(job);
>
> /*
>@@ -298,6 +309,8 @@ static void drm_sched_job_timedout(struct
>work_struct *work)
> job->sched->ops->free_job(job);
> sched->free_guilty = false;
> }
>+ } else {
>+ spin_unlock_irqrestore(>job_list_lock, flags);
> }
>
> spin_lock_irqsave(>job_list_lock, flags); @@ -370,6 +383,20
>@@ void drm_sched_stop(struct drm_gpu_scheduler *sched, struct
>drm_sched_job *bad)
> kthread_park(sched->thread);
>
> /*
>+ * Reinsert back the bad job here - now it's safe as
>+ * drm_sched_get_cleanup_job cannot race against us and release the
>+ * bad job at this point - we parked (waited for) any in progress
>+ * (earlier) cleanups and drm_sched_get_cleanup_job will not be
>called
>+ * now until the scheduler thread is unparked.
>+ */
>+ if (bad && bad->sched == sched)
>+ /*
>+ * Add at the head of the queue to reflect it was the earliest
>+ * job extracted.
>+ */
RE: [PATCH v2 0/7] PCI: Prefer pcie_capability_read_word()
> -Original Message- > From: amd-gfx On Behalf Of > Bjorn Helgaas > Sent: Thursday, November 21, 2019 9:02 AM > To: linux-...@vger.kernel.org > Cc: Zhou, David(ChunMing) ; Frederick Lawler > ; Dave Airlie ; linux- > ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; Bjorn Helgaas > ; amd-...@lists.freedesktop.org; Daniel Vetter > ; Alex Deucher ; Koenig, > Christian > Subject: [PATCH v2 0/7] PCI: Prefer pcie_capability_read_word() > > From: Bjorn Helgaas > > Use pcie_capability_read_word() and similar instead of using > pci_read_config_word() directly. Add #defines to replace some magic > numbers. Fix typos in use of Transmit Margin field. > > These are currently on my pci/misc branch for v5.5. Let me know if you see > any issues. > Series is: Reviewed-by: Alex Deucher > > Bjorn Helgaas (5): > PCI: Add #defines for Enter Compliance, Transmit Margin > drm/amdgpu: Correct Transmit Margin masks > drm/amdgpu: Replace numbers with PCI_EXP_LNKCTL2 definitions > drm/radeon: Correct Transmit Margin masks > drm/radeon: Replace numbers with PCI_EXP_LNKCTL2 definitions > > Frederick Lawler (2): > drm/amdgpu: Prefer pcie_capability_read_word() > drm/radeon: Prefer pcie_capability_read_word() > > drivers/gpu/drm/amd/amdgpu/cik.c | 95 +++ > drivers/gpu/drm/amd/amdgpu/si.c | 97 > drivers/gpu/drm/radeon/cik.c | 94 +++ > drivers/gpu/drm/radeon/si.c | 97 > include/uapi/linux/pci_regs.h| 2 + > 5 files changed, 243 insertions(+), 142 deletions(-) > > -- > 2.24.0.432.g9d3f5f5b63-goog > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd: Fix Kconfig indentation
Reviewed-by: Alex Deucher From: Krzysztof Kozlowski Sent: Thursday, November 21, 2019 8:29 AM To: linux-ker...@vger.kernel.org Cc: Krzysztof Kozlowski ; Deucher, Alexander ; Koenig, Christian ; Zhou, David(ChunMing) ; David Airlie ; Daniel Vetter ; amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org Subject: [PATCH] drm/amd: Fix Kconfig indentation Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^/\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski --- drivers/gpu/drm/amd/acp/Kconfig | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/acp/Kconfig b/drivers/gpu/drm/amd/acp/Kconfig index d968c2471412..19bae9100da4 100644 --- a/drivers/gpu/drm/amd/acp/Kconfig +++ b/drivers/gpu/drm/amd/acp/Kconfig @@ -2,11 +2,11 @@ menu "ACP (Audio CoProcessor) Configuration" config DRM_AMD_ACP - bool "Enable AMD Audio CoProcessor IP support" - depends on DRM_AMDGPU - select MFD_CORE - select PM_GENERIC_DOMAINS if PM - help + bool "Enable AMD Audio CoProcessor IP support" + depends on DRM_AMDGPU + select MFD_CORE + select PM_GENERIC_DOMAINS if PM + help Choose this option to enable ACP IP support for AMD SOCs. This adds the ACP (Audio CoProcessor) IP driver and wires it up into the amdgpu driver. The ACP block provides the DMA -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/r128: make ATI PCI GART part of its only user, r128
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, November 19, 2019 5:06 AM
> To: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula ; Deucher, Alexander
> ; Daniel Vetter ;
> Dave Airlie
> Subject: [PATCH] drm/r128: make ATI PCI GART part of its only user, r128
>
> The ATI Rage 128 driver has been the only user of ATI PCI GART code since
> Radeon dropped UMS support in commit 8333f607a631 ("drm/radeon:
> remove UMS support"). Clean up the drm top level directory, Kconfig and
> Makefile by making ati_pcigart.[ch] part of r128. Drop the
> CONFIG_DRM_ATI_PCIGART config option made redundant by the change.
>
> This reduces drm.ko module size slightly when legacy drivers are enabled,
> and moves the baggage to r128.ko instead.
>
> Cc: Alex Deucher
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Signed-off-by: Jani Nikula
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/Kconfig | 4
> drivers/gpu/drm/Makefile| 1 -
> drivers/gpu/drm/r128/Makefile | 2 +-
> drivers/gpu/drm/{ => r128}/ati_pcigart.c| 5 ++---
> {include/drm => drivers/gpu/drm/r128}/ati_pcigart.h | 0
> drivers/gpu/drm/r128/r128_drv.h | 3 ++-
> 6 files changed, 5 insertions(+), 10 deletions(-) rename drivers/gpu/drm/{
> => r128}/ati_pcigart.c (98%) rename {include/drm =>
> drivers/gpu/drm/r128}/ati_pcigart.h (100%)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index
> 76db8bc0dd1f..6d55a73d5d2b 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -297,9 +297,6 @@ config DRM_VKMS
>
> If M is selected the module will be called vkms.
>
> -config DRM_ATI_PCIGART
> -bool
> -
> source "drivers/gpu/drm/exynos/Kconfig"
>
> source "drivers/gpu/drm/rockchip/Kconfig"
> @@ -396,7 +393,6 @@ menuconfig DRM_LEGACY
> bool "Enable legacy drivers (DANGEROUS)"
> depends on DRM && MMU
> select DRM_VM
> - select DRM_ATI_PCIGART if PCI
> help
> Enable legacy DRI1 drivers. Those drivers expose unsafe and
> dangerous
> APIs to user-space, which can be used to circumvent access diff --git
> a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index
> 9f1c7c486f88..d9bcc9f2a0a4 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -25,7 +25,6 @@ drm-$(CONFIG_DRM_VM) += drm_vm.o
> drm-$(CONFIG_COMPAT) += drm_ioc32.o
> drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
> drm-$(CONFIG_DRM_GEM_SHMEM_HELPER) +=
> drm_gem_shmem_helper.o
> -drm-$(CONFIG_DRM_ATI_PCIGART) += ati_pcigart.o
> drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> drm-$(CONFIG_OF) += drm_of.o
> drm-$(CONFIG_AGP) += drm_agpsupport.o
> diff --git a/drivers/gpu/drm/r128/Makefile b/drivers/gpu/drm/r128/Makefile
> index ae8a1860c6b8..c07a069533ef 100644
> --- a/drivers/gpu/drm/r128/Makefile
> +++ b/drivers/gpu/drm/r128/Makefile
> @@ -3,7 +3,7 @@
> # Makefile for the drm device driver. This driver provides support for the
> #
> Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>
> -r128-y := r128_drv.o r128_cce.o r128_state.o r128_irq.o
> +r128-y := r128_drv.o r128_cce.o r128_state.o r128_irq.o ati_pcigart.o
>
> r128-$(CONFIG_COMPAT) += r128_ioc32.o
>
> diff --git a/drivers/gpu/drm/ati_pcigart.c
> b/drivers/gpu/drm/r128/ati_pcigart.c
> similarity index 98%
> rename from drivers/gpu/drm/ati_pcigart.c rename to
> drivers/gpu/drm/r128/ati_pcigart.c
> index 580aa2676358..9b4072f97215 100644
> --- a/drivers/gpu/drm/ati_pcigart.c
> +++ b/drivers/gpu/drm/r128/ati_pcigart.c
> @@ -33,11 +33,12 @@
>
> #include
>
> -#include
> #include
> #include
> #include
>
> +#include "ati_pcigart.h"
> +
> # define ATI_PCIGART_PAGE_SIZE 4096/**< PCI GART page
> size */
>
> static int drm_ati_alloc_pcigart_table(struct drm_device *dev, @@ -95,7
> +96,6 @@ int drm_ati_pcigart_cleanup(struct drm_device *dev, struct
> drm_ati_pcigart_info
>
> return 1;
> }
> -EXPORT_SYMBOL(drm_ati_pcigart_cleanup);
>
> int drm_ati_pcigart_init(struct drm_device *dev, struct drm_ati_pcigart_info
> *gart_info) { @@ -207,4 +207,3 @@ int drm_ati_pcigart_init(struct
> drm_device *dev, struct drm_ati_pcigart_info *ga
> gart_info->bus_addr = bus_address;
> return ret;
> }
> -EXPORT_SYMBOL(drm_ati_pcigart_init);
> diff --git a/include/drm/ati_pcigart.h b/drivers/gpu/drm/r128/ati_pcigart.h
> similarity index 100%
> rename from include/drm/ati_pcigart.h
>
RE: [PATCH V3 0/3] drm: replace magic numbers
> -Original Message- > From: amd-gfx On Behalf Of > Bjorn Helgaas > Sent: Tuesday, November 12, 2019 12:35 PM > To: Deucher, Alexander ; Koenig, Christian > ; Zhou, David(ChunMing) > ; David Airlie ; Daniel Vetter > > Cc: Frederick Lawler ; linux-...@vger.kernel.org; > Michel Dänzer ; linux-ker...@vger.kernel.org; dri- > de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; Bjorn Helgaas > ; Ilia Mirkin > Subject: [PATCH V3 0/3] drm: replace magic numbers > > From: Bjorn Helgaas > > amdgpu and radeon do a bit of mucking with the PCIe Link Control 2 register, > some of it using hard-coded magic numbers. The idea here is to replace > those with #defines. > > Since v2: > - Fix a gpu_cfg2 case in amdgpu/si.c that I had missed > - Separate out the functional changes for better bisection (thanks, > Michel!) > - Add #defines in a patch by themselves (so a GPU revert wouldn't break > other potential users) > - Squash all the magic number -> #define changes into one patch > > Since v1: > - Add my signed-off-by and Alex's reviewed-by. > Series is: Reviewed-by: Alex Deucher I'm happy to have it go through whatever tree is easiest for you. Thanks, Alex > Bjorn Helgaas (3): > PCI: Add #defines for Enter Compliance, Transmit Margin > drm: correct Transmit Margin masks > drm: replace numbers with PCI_EXP_LNKCTL2 definitions > > drivers/gpu/drm/amd/amdgpu/cik.c | 22 ++ > drivers/gpu/drm/amd/amdgpu/si.c | 22 ++ > drivers/gpu/drm/radeon/cik.c | 22 ++ > drivers/gpu/drm/radeon/si.c | 22 ++ > include/uapi/linux/pci_regs.h| 2 ++ > 5 files changed, 58 insertions(+), 32 deletions(-) > > -- > 2.24.0.rc1.363.gb1bccd3e3d-goog > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 0/2] drm: replace magic nuumbers
> -Original Message- > From: amd-gfx On Behalf Of > Bjorn Helgaas > Sent: Thursday, November 7, 2019 5:21 PM > To: Deucher, Alexander ; Koenig, Christian > ; Zhou, David(ChunMing) > ; David Airlie ; Daniel Vetter > > Cc: Bjorn Helgaas ; dri-devel@lists.freedesktop.org; > amd-...@lists.freedesktop.org; Frederick Lawler ; > linux-ker...@vger.kernel.org > Subject: [PATCH 0/2] drm: replace magic nuumbers > > From: Bjorn Helgaas > > amdgpu and radeon do a bit of mucking with the PCIe Link Control 2 register, > some of it using hard-coded magic numbers. The idea here is to replace > those with #defines. > > I haven't signed off on these because the first one actually changes the bits > involved because the existing code looks like it might have a typo. > But I have no way to know for sure. > It is a typo. Your patches look correct to me. The series is: Reviewed-by: Alex Deucher > I don't intend the Target Link Speed patch to change anything, so it should be > straightforward to review. > > Bjorn Helgaas (2): > drm: replace Compliance/Margin magic numbers with PCI_EXP_LNKCTL2 > definitions > drm: replace Target Link Speed magic numbers with PCI_EXP_LNKCTL2 > definitions > > drivers/gpu/drm/amd/amdgpu/cik.c | 22 ++ > drivers/gpu/drm/amd/amdgpu/si.c | 18 +++--- > drivers/gpu/drm/radeon/cik.c | 22 ++ > drivers/gpu/drm/radeon/si.c | 22 ++ > include/uapi/linux/pci_regs.h| 2 ++ > 5 files changed, 55 insertions(+), 31 deletions(-) > > -- > 2.24.0.rc1.363.gb1bccd3e3d-goog > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: release allocated memory
Maybe add a comment here in the code to avoid confusion in the future. Alex From: Koenig, Christian Sent: Saturday, September 21, 2019 7:32 AM To: Navid Emamdoost Cc: emamd...@umn.edu ; smcca...@umn.edu ; k...@umn.edu ; Deucher, Alexander ; Zhou, David(ChunMing) ; David Airlie ; Daniel Vetter ; Sam Ravnborg ; Rex Zhu ; amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org ; linux-ker...@vger.kernel.org Subject: Re: [PATCH] drm/amdgpu: release allocated memory Am 21.09.19 um 00:49 schrieb Navid Emamdoost: > In amdgpu_vmid_grab_idle, fences is being leaked in one execution path. > The missing kfree was added. NAK, the array is freed by the dma_fence_array. This is a double free. Regards, Christian. > > Signed-off-by: Navid Emamdoost > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c > index 57b3d8a9bef3..9063cd36fa94 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c > @@ -244,6 +244,7 @@ static int amdgpu_vmid_grab_idle(struct amdgpu_vm *vm, >r = amdgpu_sync_fence(adev, sync, >base, false); >dma_fence_put(ring->vmid_wait); >ring->vmid_wait = >base; > + kfree(fences); >return r; >} >kfree(fences); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v7 04/11] drm: revocation check at drm subsystem
> -Original Message- > From: Wentland, Harry > Sent: Wednesday, September 11, 2019 8:16 PM > To: Ramalingam C ; intel- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > daniel.vet...@intel.com > Cc: gwan-gyeong@intel.com; Kumar, Ranjeet > ; Deucher, Alexander > ; Lakha, Bhawanpreet > > Subject: Re: [PATCH v7 04/11] drm: revocation check at drm subsystem > > Adding a couple AMD guys. > > I know this is already merged but I have a few questions after some internal > discussions. > > On 2019-05-07 12:27 p.m., Ramalingam C wrote: > > On every hdcp revocation check request SRM is read from fw file > > /lib/firmware/display_hdcp_srm.bin > > > > According to section 5 of the HDCP 2.3 spec [1] a device compliant with HDCP > 2.0 and higher must be capable of storing and updating the SRM in non- > volatile memory. Section 5.2 describes how this SRM needs to be updated > when a new version is served alongside protected content. > > Isn't /lib/firmware intended for static firmware making updates to the folder > problematic for anyone but the system's package maintainer? I've heard /lib > might even be treated as read-only in certain environments. > This would mean it'd be impossible to support HDCP 2.x on those systems. > > Wouldn't it be easier to provide a sysfs entry for SRM that allows userspace > (e.g. system startup/shutdown scripts) to (a) retrieve the SRM from the > HDCP implementation for non-volatile storage and (b) to pass the SRM to the > HDCP implementation for revocation checking? Also, IIRC, for level 1 support, I think the srm parsing has to happen on something other than the CPU, so I'm not sure where need to do any parsing in software, at least for HDCP 2.x. Alex > > [1] > https://www.digital- > cp.com/sites/default/files/HDCP%20on%20HDMI%20Specification%20Rev2_ > 3.pdf > > Thanks, > Harry > > > SRM table is parsed and stored at drm_hdcp.c, with functions exported > > for the services for revocation check from drivers (which implements > > the HDCP authentication) > > > > This patch handles the HDCP1.4 and 2.2 versions of SRM table. > > > > v2: > > moved the uAPI to request_firmware_direct() [Daniel] > > v3: > > kdoc added. [Daniel] > > srm_header unified and bit field definitions are removed. [Daniel] > > locking improved. [Daniel] > > vrl length violation is fixed. [Daniel] > > v4: > > s/__swab16/be16_to_cpu [Daniel] > > be24_to_cpu is done through a global func [Daniel] > > Unused variables are removed. [Daniel] > > unchecked return values are dropped from static funcs [Daniel] > > > > Signed-off-by: Ramalingam C > > Acked-by: Satyeshwar Singh > > Reviewed-by: Daniel Vetter > > --- > > Documentation/gpu/drm-kms-helpers.rst | 6 + > > drivers/gpu/drm/Makefile | 2 +- > > drivers/gpu/drm/drm_hdcp.c| 333 > ++ > > drivers/gpu/drm/drm_internal.h| 4 + > > drivers/gpu/drm/drm_sysfs.c | 2 + > > include/drm/drm_hdcp.h| 24 ++ > > 6 files changed, 370 insertions(+), 1 deletion(-) create mode 100644 > > drivers/gpu/drm/drm_hdcp.c > > > > diff --git a/Documentation/gpu/drm-kms-helpers.rst > > b/Documentation/gpu/drm-kms-helpers.rst > > index 14102ae035dc..0fe726a6ee67 100644 > > --- a/Documentation/gpu/drm-kms-helpers.rst > > +++ b/Documentation/gpu/drm-kms-helpers.rst > > @@ -181,6 +181,12 @@ Panel Helper Reference .. kernel-doc:: > > drivers/gpu/drm/drm_panel_orientation_quirks.c > > :export: > > > > +HDCP Helper Functions Reference > > +=== > > + > > +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c > > + :export: > > + > > Display Port Helper Functions Reference > > === > > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index > > 72f5036d9bfa..dd02e9dec810 100644 > > --- a/drivers/gpu/drm/Makefile > > +++ b/drivers/gpu/drm/Makefile > > @@ -17,7 +17,7 @@ drm-y :=drm_auth.o drm_cache.o \ > > drm_plane.o drm_color_mgmt.o drm_print.o \ > > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ > > drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \ > > - drm_atomic_uapi.o > > + drm_atomic_uapi.o drm_hdcp.o > > > > drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o > > drm_context.o drm_dma.o drm_scatter.o drm_lock.o > > drm-$(CONFIG_DRM_
Re: [PATCH v2 3/3] drm/mgag200: Map fbdev framebuffer while it's being displayed
Please use C style comments rather than C++.
Alex
From: Thomas Zimmermann
Sent: Wednesday, September 4, 2019 7:56 AM
To: dan...@ffwll.ch ; nor...@tronnes.org ;
airl...@linux.ie ; rong.a.c...@intel.com
; feng.t...@intel.com ;
ying.hu...@intel.com ; s...@poorly.run ;
maxime.rip...@bootlin.com ;
maarten.lankho...@linux.intel.com ;
d...@stgolabs.net
Cc: dri-devel@lists.freedesktop.org ; Thomas
Zimmermann ; Dave Airlie ; Greg
Kroah-Hartman ; Thomas Gleixner
; Gerd Hoffmann ; Deucher, Alexander
; Koenig, Christian ; Sam
Ravnborg ; Daniel Vetter ; Huang,
Ray ; Bartlomiej Zolnierkiewicz ;
Michał Mirosław ; Armijn Hemel
Subject: [PATCH v2 3/3] drm/mgag200: Map fbdev framebuffer while it's being
displayed
The generic fbdev emulation will map and unmap the framebuffer's memory
if required. As consoles are most often updated while being on screen,
we map the fbdev buffer while it's being displayed. This avoids frequent
map/unmap operations in the fbdev code. The original fbdev code in mgag200
used the same trick to improve performance.
v2:
* fix typo in comment
Signed-off-by: Thomas Zimmermann
Fixes: 90f479ae51af ("drm/mgag200: Replace struct mga_fbdev with generic
framebuffer emulation")
Cc: Thomas Zimmermann
Cc: Noralf Trønnes
Cc: Dave Airlie
Cc: Greg Kroah-Hartman
Cc: Thomas Gleixner
Cc: Gerd Hoffmann
Cc: Alex Deucher
Cc: "Christian König"
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Huang Rui
Cc: Bartlomiej Zolnierkiewicz
Cc: "Michał Mirosław"
Cc: Armijn Hemel
Cc: Rong Chen
Cc: Feng Tang
Cc: Huang Ying
Cc: Davidlohr Bueso
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 5e778b5f1a10..7b95c59341f5 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -860,13 +860,20 @@ static int mga_crtc_do_set_base(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
int x, int y, int atomic)
{
+ struct drm_fb_helper *fb_helper = crtc->dev->fb_helper;
struct drm_gem_vram_object *gbo;
int ret;
s64 gpu_addr;
+ void *base;
if (!atomic && fb) {
gbo = drm_gem_vram_of_gem(fb->obj[0]);
drm_gem_vram_unpin(gbo);
+
+ // Unmap fbdev FB if it's not being displayed
+ // any longer.
+ if (fb == fb_helper->buffer->fb)
+ drm_gem_vram_kunmap(gbo);
}
gbo = drm_gem_vram_of_gem(crtc->primary->fb->obj[0]);
@@ -882,6 +889,14 @@ static int mga_crtc_do_set_base(struct drm_crtc *crtc,
mga_set_start_address(crtc, (u32)gpu_addr);
+ // Map fbdev FB while it's being displayed. This avoids frequent
+ // mapping and unmapping within the fbdev code.
+ if (crtc->primary->fb == fb_helper->buffer->fb) {
+ base = drm_gem_vram_kmap(gbo, true, NULL);
+ if (IS_ERR(base))
+ DRM_ERROR("failed to kmap fbcon\n");
+ }
+
return 0;
err_drm_gem_vram_unpin:
@@ -1403,9 +1418,14 @@ static void mga_crtc_disable(struct drm_crtc *crtc)
DRM_DEBUG_KMS("\n");
mga_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
if (crtc->primary->fb) {
+ struct drm_fb_helper *fb_helper = crtc->dev->fb_helper;
struct drm_framebuffer *fb = crtc->primary->fb;
struct drm_gem_vram_object *gbo =
drm_gem_vram_of_gem(fb->obj[0]);
+
+ // Unmap if it's the fbdev FB.
+ if (fb == fb_helper->buffer->fb)
+ drm_gem_vram_kunmap(gbo);
drm_gem_vram_unpin(gbo);
}
crtc->primary->fb = NULL;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/radeon: Bail earlier when radeon.cik_/si_support=0 is passed
> -Original Message- > From: Hans de Goede > Sent: Tuesday, September 10, 2019 5:36 AM > To: Michel Dänzer ; Deucher, Alexander > ; Koenig, Christian > ; Zhou, David(ChunMing) > > Cc: David Airlie ; dri-devel@lists.freedesktop.org; amd- > g...@lists.freedesktop.org; Daniel Vetter > Subject: Re: [PATCH] drm/radeon: Bail earlier when > radeon.cik_/si_support=0 is passed > > Hi, > > On 9/10/19 9:50 AM, Michel Dänzer wrote: > > On 2019-09-07 10:32 p.m., Hans de Goede wrote: > >> Bail from the pci_driver probe function instead of from the > >> drm_driver load function. > >> > >> This avoid /dev/dri/card0 temporarily getting registered and then > >> unregistered again, sending unwanted add / remove udev events to > >> userspace. > >> > >> Specifically this avoids triggering the (userspace) bug fixed by this > >> plymouth merge-request: > >> https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59 > >> > >> Note that despite that being an userspace bug, not sending > >> unnecessary udev events is a good idea in general. > >> > >> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490 > >> Signed-off-by: Hans de Goede > > > > Reviewed-by: Michel Dänzer > > Thank you for the review. I've drm push rights, but I guess that radeon/amd > GPU patches are collected by someone @AMD, so I do not need to / should > not push this myself, right? I'll pick this up later this week when I get home from travel. Thanks! Alex > > > amdgpu should be changed correspondingly as well. > > Good point. I'm currently travelling (@plumbers) I can do this when I'm back > home, but feel free to beat me to it (if you do please Cc me to avoid double > work). > > Regards, > > Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 1/9] drm_dp_cec: add connector info support.
Acked-by: Alex Deucher
From: Hans Verkuil
Sent: Thursday, August 22, 2019 4:08 AM
To: Dariusz Marcinkiewicz ; dri-devel@lists.freedesktop.org
; linux-me...@vger.kernel.org
Cc: David Airlie ; nouv...@lists.freedesktop.org
; Dhinakaran Pandiyan
; Koo, Anthony ; Francis,
David ; amd-...@lists.freedesktop.org
; Zuo, Jerry ; Ben Skeggs
; Li, Sun peng (Leo) ;
intel-...@lists.freedesktop.org ; Maxime
Ripard ; Rodrigo Vivi ; Sean Paul
; Thomas Lim ;
linux-ker...@vger.kernel.org ; Manasi Navare
; Deucher, Alexander ;
Koenig, Christian ; Ville Syrjälä
Subject: Re: [PATCH v7 1/9] drm_dp_cec: add connector info support.
Alex, Ville/Rodrigo, Ben,
Can you (hopefully) Ack this patch so that I can merge it?
Thank you!
Hans
On 8/14/19 12:44 PM, Dariusz Marcinkiewicz wrote:
> Pass the connector info to the CEC adapter. This makes it possible
> to associate the CEC adapter with the corresponding drm connector.
>
> Signed-off-by: Dariusz Marcinkiewicz
> Signed-off-by: Hans Verkuil
> Tested-by: Hans Verkuil
> ---
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
> drivers/gpu/drm/drm_dp_cec.c | 25 ---
> drivers/gpu/drm/i915/display/intel_dp.c | 4 +--
> drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +--
> include/drm/drm_dp_helper.h | 17 ++---
> 5 files changed, 27 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 16218a202b591..5ec14efd4d8cb 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -416,7 +416,7 @@ void amdgpu_dm_initialize_dp_connector(struct
> amdgpu_display_manager *dm,
>
>drm_dp_aux_register(>dm_dp_aux.aux);
>drm_dp_cec_register_connector(>dm_dp_aux.aux,
> - aconnector->base.name, dm->adev->dev);
> + >base);
>aconnector->mst_mgr.cbs = _mst_cbs;
>drm_dp_mst_topology_mgr_init(
>>mst_mgr,
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> index b15cee85b702b..b457c16c3a8bb 100644
> --- a/drivers/gpu/drm/drm_dp_cec.c
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -8,7 +8,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
>
> /*
> @@ -295,7 +297,10 @@ static void drm_dp_cec_unregister_work(struct
> work_struct *work)
> */
> void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> {
> - u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD;
> + struct drm_connector *connector = aux->cec.connector;
> + u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
> +CEC_CAP_CONNECTOR_INFO;
> + struct cec_connector_info conn_info;
>unsigned int num_las = 1;
>u8 cap;
>
> @@ -344,13 +349,17 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
>
>/* Create a new adapter */
>aux->cec.adap = cec_allocate_adapter(_dp_cec_adap_ops,
> - aux, aux->cec.name, cec_caps,
> + aux, connector->name, cec_caps,
> num_las);
>if (IS_ERR(aux->cec.adap)) {
>aux->cec.adap = NULL;
>goto unlock;
>}
> - if (cec_register_adapter(aux->cec.adap, aux->cec.parent)) {
> +
> + cec_fill_conn_info_from_drm(_info, connector);
> + cec_s_conn_info(aux->cec.adap, _info);
> +
> + if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
>cec_delete_adapter(aux->cec.adap);
>aux->cec.adap = NULL;
>} else {
> @@ -406,22 +415,20 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
> /**
> * drm_dp_cec_register_connector() - register a new connector
> * @aux: DisplayPort AUX channel
> - * @name: name of the CEC device
> - * @parent: parent device
> + * @connector: drm connector
> *
> * A new connector was registered with associated CEC adapter name and
> * CEC adapter parent device. After registering the name and parent
> * drm_dp_cec_set_edid() is called to check if the connector supports
> * CEC and to register a CEC adapter if that is the case.
> */
> -void drm_dp_cec_register_connector(struct drm_dp_aux *aux, const char *name,
> -struct device *parent)
> +void drm_dp_cec_register_connector
Re: [Regression] "drm/amdgpu: enable gfxoff again on raven series (v2)"
Maybe we can check if iommu is enabled in the driver and do the appropriate thing with respect to gfxoff, assuming this is not platform specific. Alex From: Huang, Ray Sent: Thursday, August 8, 2019 4:14 AM To: Michel Dänzer ; Kai-Heng Feng ; Olsak, Marek Cc: Zhou, David(ChunMing) ; LKML ; dri-devel@lists.freedesktop.org ; Anthony Wong ; amd-gfx list ; Deucher, Alexander ; Koenig, Christian Subject: RE: [Regression] "drm/amdgpu: enable gfxoff again on raven series (v2)" > -Original Message- > From: Michel Dänzer > Sent: Thursday, August 08, 2019 4:10 PM > To: Huang, Ray ; Kai-Heng Feng > > Cc: Zhou, David(ChunMing) ; LKML ker...@vger.kernel.org>; dri-devel@lists.freedesktop.org; Anthony Wong > ; amd-gfx list g...@lists.freedesktop.org>; Deucher, Alexander > ; Koenig, Christian > > Subject: Re: [Regression] "drm/amdgpu: enable gfxoff again on raven series > (v2)" > > On 2019-08-08 8:29 a.m., Huang, Ray wrote: > >> From: Kai-Heng Feng at 00:03, Huang, > >> Ray wrote: > >> > >>> May I know the all firmware version in your system? > > > > Seems to the issue we encountered with IOMMU enabled. Could you > please disable iommu in SBIOS or GRUB? > > The driver needs to work with the IOMMU enabled. If nothing else, ROCm > only works with IOMMU I think. > Yes. ROCm in APU required IOMMU v2. So far, I am asking Kai-Heng to do some tests to make sure the issue that was encountered by us before. (+ Marek) Thanks, Ray > > -- > Earthling Michel Dänzer | https://www.amd.com > Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd/kfd_mqd_manager_v10: Fix missing break in switch statement
We need to add a /*fall through */ comment then.
Alex
From: Liu, Shaoyun
Sent: Monday, July 22, 2019 11:14 AM
To: Gustavo A. R. Silva ; Cox, Philip
; Oded Gabbay ; Deucher, Alexander
; Koenig, Christian ;
Zhou, David(ChunMing) ; David Airlie ;
Daniel Vetter
Cc: amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org ;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH] drm/amdkfd/kfd_mqd_manager_v10: Fix missing break in
switch statement
This one properly in purpose , The mqd init for CP and COMPUTE will
have the same routine .
Regard
sshaoyun.liu
On 2019-07-21 6:59 p.m., Gustavo A. R. Silva wrote:
> Add missing break statement in order to prevent the code from falling
> through to case KFD_MQD_TYPE_COMPUTE.
>
> This bug was found thanks to the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Fixes: 14328aa58ce5 ("drm/amdkfd: Add navi10 support to amdkfd. (v3)")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c
> index 4f8a6ffc5775..1d8b13ad46f9 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c
> @@ -430,6 +430,7 @@ struct mqd_manager *mqd_manager_init_v10(enum
> KFD_MQD_TYPE type,
>switch (type) {
>case KFD_MQD_TYPE_CP:
>pr_debug("%s@%i\n", __func__, __LINE__);
> + break;
>case KFD_MQD_TYPE_COMPUTE:
>pr_debug("%s@%i\n", __func__, __LINE__);
>mqd->allocate_mqd = allocate_mqd;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: avoid 64-bit division
I'll just apply Arnd's patch. If the display team wants to adjust it later to
clarify the operation, they should go ahead as a follow up patch.
Thanks,
Alex
From: Abramov, Slava
Sent: Tuesday, July 9, 2019 12:31 PM
To: Arnd Bergmann; Wentland, Harry; Li, Sun peng (Leo); Deucher, Alexander;
Koenig, Christian; Zhou, David(ChunMing); David Airlie; Daniel Vetter
Cc: Liu, Charlene; Park, Chris; Cheng, Tony; Francis, David;
linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; Cornij, Nikola;
Laktyushkin, Dmytro; dri-devel@lists.freedesktop.org; Lei, Jun; Lakha,
Bhawanpreet; Koo, Anthony
Subject: Re: [PATCH] drm/amd/display: avoid 64-bit division
Hi Arnd!
Thanks for bisecting this issue.
I wonder whether you are going to commit your patch or planning to update it
and it's still in your work queue. We have one of our 32-bit builds failing
because of this issue, so that I would like either to fix it or wait to your
fix if it has chances to go upstream today.
Sincerely,
Slava Abramov
From: amd-gfx on behalf of Arnd
Bergmann
Sent: Monday, July 8, 2019 9:52:08 AM
To: Wentland, Harry; Li, Sun peng (Leo); Deucher, Alexander; Koenig, Christian;
Zhou, David(ChunMing); David Airlie; Daniel Vetter
Cc: Liu, Charlene; Park, Chris; Arnd Bergmann; Cheng, Tony; Francis, David;
linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; Cornij, Nikola;
Laktyushkin, Dmytro; dri-devel@lists.freedesktop.org; Lei, Jun; Lakha,
Bhawanpreet; Koo, Anthony
Subject: [PATCH] drm/amd/display: avoid 64-bit division
On 32-bit architectures, dividing a 64-bit integer in the kernel
leads to a link error:
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Change the two recently introduced instances to a multiply+shift
operation that is also much cheaper on 32-bit architectures.
We can do that here, since both of them are really 32-bit numbers
that change a few percent.
Fixes: bedbbe6af4be ("drm/amd/display: Move link functions from dc to dc_link")
Fixes: f18bc4e53ad6 ("drm/amd/display: update calculated bounding box logic for
NV")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 ++--
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index c17db5c144aa..8dbf759eba45 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -3072,8 +3072,8 @@ uint32_t dc_link_bandwidth_kbps(
* but the difference is minimal and is in a safe direction,
* which all works well around potential ambiguity of DP 1.4a
spec.
*/
- long long fec_link_bw_kbps = link_bw_kbps * 970LL;
- link_bw_kbps = (uint32_t)(fec_link_bw_kbps / 1000LL);
+ link_bw_kbps = mul_u64_u32_shr(BIT_ULL(32) * 970LL / 1000,
+ link_bw_kbps, 32);
}
#endif
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index b35327bafbc5..70ac8a95d2db 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -2657,7 +2657,7 @@ static void update_bounding_box(struct dc *dc, struct
_vcs_dpi_soc_bounding_box_
calculated_states[i].dram_speed_mts = uclk_states[i] * 16 /
1000;
// FCLK:UCLK ratio is 1.08
- min_fclk_required_by_uclk = ((unsigned long
long)uclk_states[i]) * 1080 / 100;
+ min_fclk_required_by_uclk = mul_u64_u32_shr(BIT_ULL(32) * 1080
/ 100, uclk_states[i], 32);
calculated_states[i].fabricclk_mhz =
(min_fclk_required_by_uclk < min_dcfclk) ?
min_dcfclk : min_fclk_required_by_uclk;
--
2.20.0
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Use msleep instead of udelay for 8ms wait
Reviewed-by: Alex Deucher From: amd-gfx on behalf of Harry Wentland Sent: Tuesday, June 25, 2019 10:00 AM To: airl...@gmail.com; natechancel...@gmail.com Cc: Zhou, David(ChunMing); Li, Sun peng (Leo); Koo, Anthony; linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Wentland, Harry; Deucher, Alexander; Lei, Jun; Lakha, Bhawanpreet; Koenig, Christian Subject: [PATCH] drm/amd/display: Use msleep instead of udelay for 8ms wait arm32's udelay only allows values up to 2000 microseconds. msleep does the trick for us here as there is no problem if this isn't microsecond accurate and takes a tad longer. Signed-off-by: Harry Wentland --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c index 4c31930f1cdf..f5d02f89b3f9 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c @@ -548,7 +548,7 @@ static void read_edp_current_link_settings_on_detect(struct dc_link *link) break; } - udelay(8000); + msleep(8); } ASSERT(status == DC_OK); -- 2.22.0 ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] mm/hmm: Only set FAULT_FLAG_ALLOW_RETRY for non-blocking
I reverted all the amdgpu HMM patches for 5.2 because they also depended on
this patch:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.2-wip=ce05ef71564f7cbe270cd4337c36ee720ea534db
which did not have a clear line of sight for 5.2 either.
Alex
From: amd-gfx on behalf of Kuehling,
Felix
Sent: Monday, May 13, 2019 3:36 PM
To: Jerome Glisse
Cc: linux...@kvack.org; airl...@gmail.com; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org; alex.deuc...@amd.com
Subject: Re: [PATCH 2/2] mm/hmm: Only set FAULT_FLAG_ALLOW_RETRY for
non-blocking
[CAUTION: External Email]
Hi Jerome,
Do you want me to push the patches to your branch? Or are you going to
apply them yourself?
Is your hmm-5.2-v3 branch going to make it into Linux 5.2? If so, do you
know when? I'd like to coordinate with Dave Airlie so that we can also
get that update into a drm-next branch soon.
I see that Linus merged Dave's pull request for Linux 5.2, which
includes the first changes in amdgpu using HMM. They're currently broken
without these two patches.
Thanks,
Felix
On 2019-05-10 4:14 p.m., Jerome Glisse wrote:
> [CAUTION: External Email]
>
> On Fri, May 10, 2019 at 07:53:24PM +, Kuehling, Felix wrote:
>> Don't set this flag by default in hmm_vma_do_fault. It is set
>> conditionally just a few lines below. Setting it unconditionally
>> can lead to handle_mm_fault doing a non-blocking fault, returning
>> -EBUSY and unlocking mmap_sem unexpectedly.
>>
>> Signed-off-by: Felix Kuehling
> Reviewed-by: Jérôme Glisse
>
>> ---
>> mm/hmm.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/hmm.c b/mm/hmm.c
>> index b65c27d5c119..3c4f1d62202f 100644
>> --- a/mm/hmm.c
>> +++ b/mm/hmm.c
>> @@ -339,7 +339,7 @@ struct hmm_vma_walk {
>> static int hmm_vma_do_fault(struct mm_walk *walk, unsigned long addr,
>>bool write_fault, uint64_t *pfn)
>> {
>> - unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_REMOTE;
>> + unsigned int flags = FAULT_FLAG_REMOTE;
>>struct hmm_vma_walk *hmm_vma_walk = walk->private;
>>struct hmm_range *range = hmm_vma_walk->range;
>>struct vm_area_struct *vma = walk->vma;
>> --
>> 2.17.1
>>
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 4.19 29/53] drm/amdkfd: Add picasso pci id
NACK. 4.19 did not contain support for picasso. Please drop this patch for
4.19.
Alex
From: amd-gfx on behalf of Sasha Levin
Sent: Friday, April 26, 2019 9:40 PM
To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
Cc: Deucher, Alexander; Sasha Levin; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Subject: [PATCH AUTOSEL 4.19 29/53] drm/amdkfd: Add picasso pci id
From: Alex Deucher
[ Upstream commit e7ad88553aa1d48e950ca9a4934d246c1bee4be4 ]
Picasso is a new raven variant.
Reviewed-by: Kent Russell
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 5aba50f63ac6..06d19bb89cfc 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -275,6 +275,7 @@ static const struct kfd_deviceid supported_devices[] = {
{ 0x9876, _device_info }, /* Carrizo */
{ 0x9877, _device_info }, /* Carrizo */
{ 0x15DD, _device_info }, /* Raven */
+ { 0x15D8, _device_info }, /* Raven */
#endif
{ 0x67A0, _device_info },/* Hawaii */
{ 0x67A1, _device_info },/* Hawaii */
--
2.19.1
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [radeon-alex:drm-next-5.2-wip 21/42] drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:756:32: error: 'HMM_PFN_VALID' undeclared; did you mean '_PAGE_VALID'?
The fixes are there; they are the subsequent commits, I guess I can squash them
in.
Alex
From: Kuehling, Felix
Sent: Wednesday, April 3, 2019 6:20 PM
To: Yang, Philip; Deucher, Alexander
Cc: dri-devel@lists.freedesktop.org; Koenig, Christian
Subject: Re: [radeon-alex:drm-next-5.2-wip 21/42]
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:756:32: error: 'HMM_PFN_VALID'
undeclared; did you mean '_PAGE_VALID'?
[dropping the robot]
I think Philip fixed those issues on amd-staging-drm-next. Either some
fixes are missing on drm-next-5.2-wip, or they are there but should be
squashed to avoid hitting these errors on intermediate builds.
Regards,
Felix
On 2019-04-03 2:26 p.m., kbuild test robot wrote:
> tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
> head: 5666aea3ea494d4dd96df8f092cab32dbeeac321
> commit: 95db8d6001df8966e3370a66c9f358925fbcc890 [21/42] drm/amdgpu: replace
> get_user_pages with HMM mirror helpers
> config: mips-allyesconfig (attached as .config)
> compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 95db8d6001df8966e3370a66c9f358925fbcc890
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=mips
>
> Note: the radeon-alex/drm-next-5.2-wip HEAD
> 5666aea3ea494d4dd96df8f092cab32dbeeac321 builds fine.
>It only hurts bisectibility.
>
> All errors (new ones prefixed by >>):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:713:19: error: field 'range' has
> incomplete type
> struct hmm_range range;
>^
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c: In function
> 'amdgpu_ttm_tt_get_user_pages':
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:738:7: error: dereferencing
> pointer to incomplete type 'struct hmm_range'
> range->vma = find_vma(mm, gtt->userptr);
>^~
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:756:32: error: 'HMM_PFN_VALID'
>>> undeclared (first use in this function); did you mean '_PAGE_VALID'?
> range->pfns[0] = range->flags[HMM_PFN_VALID];
> ^
> _PAGE_VALID
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:756:32: note: each undeclared
> identifier is reported only once for each function it appears in
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:758:22: error: 'HMM_PFN_WRITE'
> undeclared (first use in this function); did you mean 'HMM_PFN_VALID'?
> 0 : range->flags[HMM_PFN_WRITE];
> ^
> HMM_PFN_VALID
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:763:6: error: implicit
> declaration of function 'hmm_vma_fault'; did you mean 'hmm_mm_init'?
> [-Werror=implicit-function-declaration]
> r = hmm_vma_fault(range, true);
> ^
> hmm_mm_init
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:770:14: error: implicit
> declaration of function 'hmm_pfn_to_page'; did you mean '__pfn_to_page'?
> [-Werror=implicit-function-declaration]
>pages[i] = hmm_pfn_to_page(range, range->pfns[i]);
> ^~~
> __pfn_to_page
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c: In function
> 'amdgpu_ttm_tt_get_user_pages_done':
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:798:7: error: implicit
> declaration of function 'hmm_vma_range_done'; did you mean
> 'drm_vma_node_size'? [-Werror=implicit-function-declaration]
>r = hmm_vma_range_done(>range);
>^~
>drm_vma_node_size
> cc1: some warnings being treated as errors
>
> vim +756 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>
> 703
> 704 /*
> 705* TTM backend functions.
> 706*/
> 707 struct amdgpu_ttm_tt {
> 708 struct ttm_dma_tt ttm;
> 709 u64 offset;
> 710 uint64_tuserptr;
> 711 struct task_struct *usertask;
> 712 uint32_tuserflags;
> > 713 struct hmm_rangerange;
> 714 };
> 715
> 716 /**
> 717* amdgpu_ttm_tt_get_user_pages - get device accessible pages
> that back user
> 718* memory and start HMM tracking CPU page table update
> 719*
> 720* Calling function must call
> amdgpu_ttm_tt_userptr_range_done() once and only
> 721
Re: [PATCH] drm/amd/display: avoid passing enum as NULL pointer
Thanks for the patch. We already have the fix queued:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.2-wip=672e78cab819ebe31e3b9b8abac367be8a110472
Alex
From: Arnd Bergmann
Sent: Thursday, March 7, 2019 5:34 AM
To: Wentland, Harry; Li, Sun peng (Leo); Deucher, Alexander; Koenig, Christian;
Zhou, David(ChunMing)
Cc: Nick Desaulniers; Arnd Bergmann; David Airlie; Daniel Vetter; Koo, Anthony;
Cyr, Aric; Tatla, Harmanprit; Chalmers, Kenneth; Kumarasamy, Sivapiriyan; Kees
Cook; Bayan Zabihiyan; Cheng, Tony; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: [PATCH] drm/amd/display: avoid passing enum as NULL pointer
The mod_freesync_build_vrr_infopacket() function uses rather obscure
calling conventions, where an enum is passed in through a pointer,
and a NULL pointer is expected to behave the same way as the zero-value
(TRANSFER_FUNC_UNKNOWN).
Trying to build this with clang results in a warning:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4601:3: error:
expression which evaluates to zero treated
as a null pointer constant of type 'const enum color_transfer_func *'
[-Werror,-Wnon-literal-null-conversion]
Passing it by value instead of by reference makes the code simpler
and more conventional but should not change the behavior at all.
Fixes: c2791297013e ("drm/amd/display: Add color bit info to freesync
infoframe")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 7 +++
drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h | 2 +-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
index 94a84bc57c7a..6f32fe129880 100644
--- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
+++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
@@ -724,7 +724,7 @@ static void build_vrr_infopacket_v1(enum signal_type signal,
static void build_vrr_infopacket_v2(enum signal_type signal,
const struct mod_vrr_params *vrr,
- const enum color_transfer_func *app_tf,
+ const enum color_transfer_func app_tf,
struct dc_info_packet *infopacket)
{
unsigned int payload_size = 0;
@@ -732,8 +732,7 @@ static void build_vrr_infopacket_v2(enum signal_type signal,
build_vrr_infopacket_header_v2(signal, infopacket, _size);
build_vrr_infopacket_data(vrr, infopacket);
- if (app_tf != NULL)
- build_vrr_infopacket_fs2_data(*app_tf, infopacket);
+ build_vrr_infopacket_fs2_data(app_tf, infopacket);
build_vrr_infopacket_checksum(_size, infopacket);
@@ -757,7 +756,7 @@ void mod_freesync_build_vrr_infopacket(struct mod_freesync
*mod_freesync,
const struct dc_stream_state *stream,
const struct mod_vrr_params *vrr,
enum vrr_packet_type packet_type,
- const enum color_transfer_func *app_tf,
+ const enum color_transfer_func app_tf,
struct dc_info_packet *infopacket)
{
/* SPD info packet for FreeSync
diff --git a/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
b/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
index 4222e403b151..645793b924cf 100644
--- a/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
+++ b/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
@@ -145,7 +145,7 @@ void mod_freesync_build_vrr_infopacket(struct mod_freesync
*mod_freesync,
const struct dc_stream_state *stream,
const struct mod_vrr_params *vrr,
enum vrr_packet_type packet_type,
- const enum color_transfer_func *app_tf,
+ const enum color_transfer_func app_tf,
struct dc_info_packet *infopacket);
void mod_freesync_build_vrr_params(struct mod_freesync *mod_freesync,
--
2.20.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH libdrm] libdrm: Fix issue about differrent domainID but same BDF
> -Original Message-
> From: amd-gfx On Behalf Of Emil
> Velikov
> Sent: Monday, February 25, 2019 8:09 AM
> To: Alex Deucher
> Cc: Deng, Emily ; Maling list - DRI developers de...@lists.freedesktop.org>; amd-gfx list
> Subject: Re: [PATCH libdrm] libdrm: Fix issue about differrent domainID but
> same BDF
>
> Hi all,
>
> This patch causes unnecessary round trip by openning the nodes. As
> mentioned previously this could be trivially fixed [1].
>
> Even Emily acknowledged that [1], yet the sub-par fix was merged. Can we
> revert+fixup this properly?
>
Sorry, I totally missed your reply. I'm having Internet issues at the moment
so if you want to revert for now, I'll work with Emily to address your
suggestions later in the week or next. Emily, can you take a look at
addressing Emil's concerns with an updated patch?
Alex
> Thanks
> Emil
>
> [1] https://lists.freedesktop.org/archives/amd-gfx/2019-
> February/031573.html
>
> On Fri, 22 Feb 2019 at 21:05, Alex Deucher wrote:
> >
> > Pushed. Thanks!
> >
> > Alex
> >
> > On Thu, Feb 21, 2019 at 9:36 PM Deng, Emily
> wrote:
> > >
> > > Hi Alex,
> > > Please help, thanks.
> > >
> > > Best wishes
> > > Emily Deng
> > >
> > >
> > >
> > > >-Original Message-
> > > >From: Alex Deucher
> > > >Sent: Friday, February 22, 2019 12:13 AM
> > > >To: Deng, Emily ; Maling list - DRI developers
> > > >
> > > >Cc: amd-gfx list
> > > >Subject: Re: [PATCH libdrm] libdrm: Fix issue about differrent
> > > >domainID but same BDF
> > > >
> > > >On Thu, Feb 14, 2019 at 2:53 AM Emily Deng
> wrote:
> > > >>
> > > >> For multiple GPUs which has the same BDF, but has different
> > > >> domain ID, the drmOpenByBusid will return the wrong fd when startx.
> > > >>
> > > >> The reproduce sequence as below:
> > > >> 1. Call drmOpenByBusid to open Card0, then will return the right
> > > >> fd0, and the
> > > >> fd0 is master privilege;
> > > >> 2. Call drmOpenByBusid to open Card1. In function drmOpenByBusid,
> > > >> it will open Card0 first, this time, the fd1 for opening Card0 is
> > > >> not master privilege, and will call drmSetInterfaceVersion to
> > > >> identify the domain ID feature, as the fd1 is not master
> > > >> privilege, then drmSetInterfaceVersion will fail, and then won't
> > > >> compare domain ID, then
> > > >return the wrong fd for Card1.
> > > >>
> > > >> Solution:
> > > >> First loop search the best match fd about drm 1.4.
> > > >>
> > > >> Signed-off-by: Emily Deng
> > > >
> > > >Reviewed-by: Alex Deucher
> > > >
> > > >Do you need someone to commit this for you?
> > > >
> > > >Alex
> > > >
> > > >> ---
> > > >> xf86drm.c | 23 +++
> > > >> 1 file changed, 23 insertions(+)
> > > >>
> > > >> diff --git a/xf86drm.c b/xf86drm.c index 336d64d..b60e029 100644
> > > >> --- a/xf86drm.c
> > > >> +++ b/xf86drm.c
> > > >> @@ -584,11 +584,34 @@ static int drmOpenByBusid(const char
> > > >> *busid, int
> > > >type)
> > > >> if (base < 0)
> > > >> return -1;
> > > >>
> > > >> +/* We need to try for 1.4 first for proper PCI domain
> > > >> + support */
> > > >> drmMsg("drmOpenByBusid: Searching for BusID %s\n", busid);
> > > >> for (i = base; i < base + DRM_MAX_MINOR; i++) {
> > > >> fd = drmOpenMinor(i, 1, type);
> > > >> drmMsg("drmOpenByBusid: drmOpenMinor returns %d\n", fd);
> > > >> if (fd >= 0) {
> > > >> +sv.drm_di_major = 1;
> > > >> +sv.drm_di_minor = 4;
> > > >> +sv.drm_dd_major = -1;/* Don't care */
> > > >> +sv.drm_dd_minor = -1;/* Don't care */
> > > >> +if (!drmSetInterfaceVersion(fd, )) {
> > > >> +buf = drmGetBusid(fd);
> > > >> +drmMsg("drmOpenByBusid: drmGetBusid reports %s\n",
> buf);
> > > >> +if (buf && drmMatchBusID(buf, busid, 1)) {
> > > >> +drmFreeBusid(buf);
> > > >> +return fd;
> > > >> +}
> > > >> +if (buf)
> > > >> +drmFreeBusid(buf);
> > > >> +}
> > > >> +close(fd);
> > > >> +}
> > > >> +}
> > > >> +
> > > >> + for (i = base; i < base + DRM_MAX_MINOR; i++) {
> > > >> +fd = drmOpenMinor(i, 1, type);
> > > >> +drmMsg("drmOpenByBusid: drmOpenMinor returns %d\n", fd);
> > > >> +if (fd >= 0) {
> > > >> /* We need to try for 1.4 first for proper PCI domain
> > > >> support
> > > >> * and if that fails, we know the kernel is busted
> > > >> */
> > > >> --
> > > >> 2.7.4
> > > >>
> > > >> ___
> > > >> amd-gfx mailing list
> > > >> amd-...@lists.freedesktop.org
> > > >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> >
