Re: [pull] amdgpu, amdkfd drm-fixes-6.9

On Thu, 9 May 2024 at 09:00, Alex Deucher wrote: > > Hi Dave, Sima, > > Fixes for 6.9. > > The following changes since commit dd5a440a31fae6e459c0d627162825505361: > > Linux 6.9-rc7 (2024-05-05 14:06:01 -0700) > > are available in the Git repository at: > >

Re: [PATCH v4 13/15] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT

On Thu, 11 Apr 2024 at 17:32, Arnd Bergmann wrote: > > On Thu, Apr 11, 2024, at 09:15, Ard Biesheuvel wrote: > > On Thu, 11 Apr 2024 at 03:11, Samuel Holland > > wrote: > >> On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote: > >> > Samuel Holland writes: > >> > >> >> The short-term fix would

Re: [pull] amdgpu, amdkfd drm-fixes-6.8

/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_dpia_bw.c:548:24: error: arithmetic between different enumeration types ('const enum dc_link_rate' and 'const enum dc_lane_count') [-Werror,-Wenum-enum-conversion]

Re: [RFC PATCH 0/6] Supporting GMEM (generalized memory management) for external memory devices

On Tue, 28 Nov 2023 at 23:07, Christian König wrote: > > Am 28.11.23 um 13:50 schrieb Weixi Zhu: > > The problem: > > > > Accelerator driver developers are forced to reinvent external MM subsystems > > case by case, because Linux core MM only considers host memory resources. > > These reinvented

Re: Radeon regression in 6.6 kernel

> > On 12.11.23 01:46, Phillip Susi wrote: > > I had been testing some things on a post 6.6-rc5 kernel for a week or > > two and then when I pulled to a post 6.6 release kernel, I found that > > system suspend was broken. It seems that the radeon driver failed to > > suspend, leaving the display

Re: [pull] amdgpu drm-fixes-6.4

Hi Linus, Can you please pull this directly, Thanks, Dave. On Sat, 24 Jun 2023 at 07:18, Alex Deucher wrote: > > Hi Dave, Daniel, Linus, > > Last few fixes for 6.4. Dave already sent out the drm-fixes PR this week. > I was out of the office earlier in the week and just got this out now. > >

Re: [PATCH v4 0/9] drm: fdinfo memory stats

| 15 +++ > > drivers/gpu/drm/msm/msm_gpu.c | 2 - > > drivers/gpu/drm/msm/msm_gpu.h | 10 ++ > > include/drm/drm_drv.h | 7 + > > include/drm/drm_file.h | 51 +++ > > include/drm/drm_gem.h | 32 + > > 13 files changed, 378 insertions(+), 47 deletions(-) > > What is the expected merge plan for this series? msm-next? drm-misc? I'm fine with this going via drm-misc, Acked-by: Dave Airlie if that is the plan. Dave.

Re: [PATCH 0/8] AMDGPU usermode queues

On Sat, 4 Feb 2023 at 07:54, Shashank Sharma wrote: > > From: Shashank Sharma > > This patch series introduces AMDGPU usermode graphics queues. > User queues is a method of GPU workload submission into the graphics > hardware without any interaction with kernel/DRM schedulers. In this > method,

Re: [PATCH] drm/amdgpu/display/mst: fix an unused-variable warning

On Fri, 27 Jan 2023 at 07:06, Hamza Mahfooz wrote: > > On 1/26/23 11:35, Arnd Bergmann wrote: > > From: Arnd Bergmann > > > > The newly added code is in an #ifdef, so the variables that > > are only used in there cause a warning if CONFIG_DRM_AMD_DC_DCN > > is disabled: > > > >

Re: [PATCH 6/9] drm/qxl: stop using ttm_bo_wait

Acked-by: Dave Airlie On Fri, 16 Dec 2022 at 00:20, Christian König wrote: > > Am 25.11.22 um 11:21 schrieb Christian König: > > TTM is just wrapping core DMA functionality here, remove the mid-layer. > > No functional change. > > Any objections to this guys? > >

Re: [pull] amdgpu, amdkfd, radeon drm-next-6.2

arm32 build fails /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c: In function ‘disable_dangling_plane’: /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1134:46: error: ‘const struct timing_generator_funcs’ has no member

Re: [PATCH v2] drm/amdkfd: Try to schedule bottom half on same core

On Sat, 13 Aug 2022 at 04:11, Felix Kuehling wrote: > > > On 2022-08-12 09:55, Philip Yang wrote: > > > > On 2022-08-11 15:04, Felix Kuehling wrote: > >> On systems that support SMT (hyperthreading) schedule the bottom half of > >> the KFD interrupt handler on the same core. This makes it

Re: [PATCH] Revert "drm/amdgpu: add drm buddy support to amdgpu"

On Fri, 5 Aug 2022 at 01:53, Mike Lothian wrote: > > Hi > > When is this relanding? It should be in Linus tree now enabled. Dave.

gcc 12.1.1 warnings around display writeback

I recently finally got my build box updated to a modern gcc, and I started seeing /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c: In function ‘dc_stream_remove_writeback’:

[PATCH] drm/amdgpu/cs: make commands with 0 chunks illegal behaviour.

From: Dave Airlie Submitting a cs with 0 chunks, causes an oops later, found trying to execute the wrong userspace driver. MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo [172536.665184] BUG: kernel NULL pointer dereference, address: 01d8 [172536.665188] #PF: supervisor read access

Re: [PATCH] drm/amdgpu: fix drm-next merge fallout

On Tue, 3 May 2022 at 23:03, Alex Deucher wrote: > > On Tue, May 3, 2022 at 2:36 AM Christian König > wrote: > > > > That hunk somehow got missing while solving the conflict between the TTM > > and AMDGPU changes for drm-next. > > > > Signed-off-by: Christian König > > Acked-by: Alex Deucher >

Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

On Tue, 15 Mar 2022 at 00:23, Alex Deucher wrote: > > On Fri, Mar 11, 2022 at 3:30 AM Pekka Paalanen wrote: > > > > On Thu, 10 Mar 2022 11:56:41 -0800 > > Rob Clark wrote: > > > > > For something like just notifying a compositor that a gpu crash > > > happened, perhaps drm_event is more

Re: [pull] amdgpu, amdkfd drm-next-5.18

On Thu, 10 Mar 2022 at 08:16, Alex Deucher wrote: > > On Wed, Mar 9, 2022 at 5:12 PM Dave Airlie wrote: > > > > On Tue, 8 Mar 2022 at 06:08, Alex Deucher wrote: > > > > > > Hi Dave, Daniel, > > > > > > Same PR as last week, just fixed up a

Re: [pull] amdgpu, amdkfd drm-next-5.18

On Tue, 8 Mar 2022 at 06:08, Alex Deucher wrote: > > Hi Dave, Daniel, > > Same PR as last week, just fixed up a bad Fixes tag. > > The following changes since commit 38a15ad9488e21cad8f42d3befca20f91e5b2874: > > Merge tag 'amd-drm-next-5.18-2022-02-25' of >

Re: [pull] amdgpu, amdkfd drm-next-5.18

On Tue, 1 Mar 2022 at 03:11, Alex Deucher wrote: > > On Mon, Feb 28, 2022 at 1:55 AM Dave Airlie wrote: > > > > On Sat, 26 Feb 2022 at 04:35, Alex Deucher > > wrote: > > > > > > Hi Dave, Daniel, > > > > > > New st

Re: [pull] amdgpu, amdkfd drm-next-5.18

On Sat, 26 Feb 2022 at 04:35, Alex Deucher wrote: > > Hi Dave, Daniel, > > New stuff for 5.18. > > The following changes since commit b63c54d978236dd6014cf2ffba96d626e97c915c: > > drm/amdkfd: Use proper enum in pm_unmap_queues_v9() (2022-02-17 15:59:06 > -0500) > > are available in the Git

Re: [PATCH] drm/amdkfd: enable heavy-weight TLB flush on Arcturus

On Wed, 19 Jan 2022 at 06:14, Eric Huang wrote: > > I understand Alex's concern. I think usually we only check the version > when a feature is only available in a specific version, and other > version or newer version doesn't have. > > In case of FW fix, we assume the driver and FWs have to be

Re: [pull] amdgpu drm-fixes-5.16

On Thu, 30 Dec 2021 at 01:51, Alex Deucher wrote: > > Hi Dave, Daniel, Just FYI on merging this into tip I got a conflict I'm not sure what answer is right. fixes has: ee2698cf79cc759a397c61086c758d4cc85938bf Author: Angus Wang Date: Thu Dec 9 17:27:01 2021 -0500 drm/amd/display:

Re: [pull] amdgpu, amdkfd drm-next-5.17

Hey, dim: 3be2709660dc ("drm/amdgpu: Call amdgpu_device_unmap_mmio() if device is unplugged to prevent crash in GPU initialization failure"): committer Signed-off-by missing. is missing your sob as you committed it. Please fix it up. Thanks, Dave.

Re: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread

On Thu, 2 Sept 2021 at 01:20, Alex Deucher wrote: > > On Wed, Sep 1, 2021 at 6:19 AM Liu, Monk wrote: > > > > [AMD Official Use Only] > > > > Daniel > > > > From the link you share it looks you(or someone else) have quite a bunch > > patches that changes DRM_SCHED or even amdgpu, by that case

Re: [PATCH 0/7] libdrm tests for hot-unplug feature

On Fri, 4 Jun 2021 at 07:20, Alex Deucher wrote: > > Please open a gitlab MR for these. > I'd really prefer these tests all get migrated out of here into igt. I don't think libdrm_amdgpu really should have tests that test the kernel level infrastructure. I know some people at AMD had issues in

Re: [Nouveau] [PATCH v4 00/17] drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers

since I think I've > found a much better solution to tegra's issues: > https://patchwork.freedesktop.org/series/89420/ I've given this a general once over, seems like a good plan and since it's mostly mechanical. for the series: Reviewed-by: Dave Airlie Dave. _

Re: [pull] amdgpu, radeon, ttm, sched drm-next-5.13

her: > >>>> On Wed, Apr 7, 2021 at 3:23 AM Dave Airlie wrote: > >>>>> On Wed, 7 Apr 2021 at 06:54, Alex Deucher > >>>>> wrote: > >>>>>> On Fri, Apr 2, 2021 at 12:22 PM Christian König > >>>>>> wrote: &g

Re: [pull] amdgpu, radeon, ttm, sched drm-next-5.13

On Wed, 7 Apr 2021 at 06:54, Alex Deucher wrote: > > On Fri, Apr 2, 2021 at 12:22 PM Christian König > wrote: > > > > Hey Alex, > > > > the TTM and scheduler changes should already be in the drm-misc-next > > branch (not 100% sure about the TTM patch, need to double check next week). > > > > The

Re: [pull] amdgpu, amdkfd, radeon drm-next-5.12

I think this is due to this pull, on arm32. /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_srv.c: In function ‘dmub_srv_hw_init’: /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_srv.c:519:44: warning: cast from pointer

Re: [PATCH] drm/ttm: ioremap buffer according to TTM mem caching setting

On Wed, 3 Mar 2021 at 08:45, Zeng, Oak wrote: > > [AMD Official Use Only - Internal Distribution Only] > > > Hi Daniel, Thomas, Dan, > > > > Does below message mean the calling ioremap_cache failed intel’s driver > build? I can see both ioremap_cache and ioremap_wc are defined in >

Re: [pull] amdgpu, amdkfd drm-next-5.12

On Thu, 4 Feb 2021 at 14:57, Alex Deucher wrote: > > Hi Dave, Daniel, > > More fixes for 5.12. Same PR from last week with the issue Felix reported > fixed and a few more additional fixes on top. > > The following changes since commit a6b8720c2f85143561c3453e1cf928a2f8586ac0: > > Merge tag

Re: [pull] amdgpu drm-next-5.12

On Fri, 15 Jan 2021 at 07:22, Alex Deucher wrote: > > Hi Dave, Daniel, > > More new stuff for 5.12. > > The following changes since commit 044a48f420b9d3c19a135b821c34de5b2bee4075: > > drm/amdgpu: fix DRM_INFO flood if display core is not supported (bug > 210921) (2021-01-08 15:18:57 -0500) >

Re: [PATCH] drm/radeon: fix check order in radeon_bo_move

Oops sorry for delay LGTM Reviewed-by: Dave Airlie On Fri, 27 Nov 2020 at 02:34, Daniel Vetter wrote: > > On Wed, Nov 25, 2020 at 3:34 PM Christian König > wrote: > > > > Reorder the code to fix checking if blitting is available. > > Might be good to

Re: [PATCH 01/11] drm/ttm: add ttm_bo_pin()/ttm_bo_unpin() v2

On Tue, 22 Sep 2020 at 23:32, Christian König wrote: > > As an alternative to the placement flag add a > pin count to the ttm buffer object. These all look good to me, nice cleanup. For the series: Reviewed-by: Dave Airlie ___ amd-gfx mai

Re: General protection fault: RIP: 0010:free_block+0xdc/0x1f0

cc'ing some more people. On Tue, 15 Sep 2020 at 23:07, Paul Menzel wrote: > > Dear Andrew folks, dear Linux folks, > > > With Linux 5.9-rc4 on a Dell OptiPlex 5080 with Intel Core i7-10700 CPU > @ 2.90GHz, and external > > 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, >

Re: [PATCH] radeon: Use only a single work queue thread for crt

On Sun, 6 Sep 2020 at 18:54, Christian König wrote: > > Am 03.08.19 um 02:09 schrieb Andi Kleen: > > From: Andi Kleen > > > > I got tired of seeing a lot of radeon-crt kernel threads in ps on my > > workstation, one for each CPU and one for each display, which never use any > > CPU time. > >

Re: [PATCH] drm/ttm: fix broken merge between drm-next and drm-misc-next

s this problem now? only in drm-tip or have we baked the broken mere already? If it's baked then 'Reviewed-by: Dave Airlie ` If it's not baked, then please use the dim howto to put a fixup in the right place. Dave. ___ amd-gfx mailing list amd-gfx@lis

Re: [PATCH 2/2] drm/amdgpu: Embed drm_device into amdgpu_device

On Wed, 19 Aug 2020 at 04:23, Alex Deucher wrote: > > On Fri, Aug 14, 2020 at 9:25 PM Luben Tuikov wrote: > > > > Embed struct drm_device into struct amdgpu_device. > > Modify the macro DRM_TO_ADEV() > > accordingly. Introduce a new macro to yield the > > DRM device from amdgpu_device,

Re: [PATCH 3/3] drm/radeon: drop superflous AGP handling

On Thu, 6 Aug 2020 at 23:51, Christian König wrote: > > The object flags created in radeon_ttm_placement_from_domain take care that > we use the correct caching for AGP, this is just superflous. > > Signed-off-by: Christian König Reviewed-by: Dave Airlie > --- > d

Re: [PATCH 2/3] drm/ttm: give resource functions their own [ch] files

On Thu, 6 Aug 2020 at 23:51, Christian König wrote: > > This is a separate object we work within TTM. Reviewed-by: Dave Airlie > > Signed-off-by: Christian König > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|

Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

On Tue, 21 Jul 2020 at 18:47, Thomas Hellström (Intel) wrote: > > > On 7/21/20 9:45 AM, Christian König wrote: > > Am 21.07.20 um 09:41 schrieb Daniel Vetter: > >> On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel) > >> wrote: > >>> Hi, > >>> > >>> On 7/9/20 2:33 PM, Daniel Vetter

Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

> > >> That's also why I'm not positive on the "no hw preemption, only > >> scheduler" case: You still have a dma_fence for the batch itself, > >> which means still no userspace controlled synchronization or other > >> form of indefinite batches allowed. So not getting us any closer to > >>

Re: [PATCH 1/1] drm/amdkfd: Add IPC API

On Tue, 14 Jul 2020 at 14:09, Felix Kuehling wrote: > > Am 2020-07-13 um 11:28 p.m. schrieb Dave Airlie: > > On Tue, 14 Jul 2020 at 13:14, Felix Kuehling wrote: > >> This allows exporting and importing buffers. The API generates handles > >> that can be used

Re: [PATCH 1/1] drm/amdkfd: Add IPC API

On Tue, 14 Jul 2020 at 13:14, Felix Kuehling wrote: > > This allows exporting and importing buffers. The API generates handles > that can be used with the HIP IPC API, i.e. big numbers rather than > file descriptors. First up why? I get the how. > + * @share_handle is a 128 bit random number

Re: [PATCH 01/25] dma-fence: basic lockdep annotations

t two can be merged without causing any pain. Feel > free to add my ab on them. > > And the third one can go in immediately as well. Acked-by: Dave Airlie for the first 2 + indefinite explains. Dave. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu, amdkfd, radeon drm-next-5.9

commit 5fa689e66bf406ef3a1afe03d0139d90b0b13773 Author: Likun Gao Commit: Alex Deucher drm/amdgpu/powerplay: add smu block for sienna_cichlid Add SMU block for sienna_cichlid with psp load type. Signed-off-by: Likun Gao Reviewed-by: Jack Xiao Spot the missing

Re: [PATCH 03/18] dma-fence: basic lockdep annotations

On Thu, 11 Jun 2020 at 18:01, Chris Wilson wrote: > > Quoting Daniel Vetter (2020-06-04 09:12:09) > > Design is similar to the lockdep annotations for workers, but with > > some twists: > > > > - We use a read-lock for the execution/worker/completion side, so that > > this explicit annotation

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Tue, 12 May 2020 at 06:28, Alex Deucher wrote: > > On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir wrote: > > > > On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote: > > > Hi guys, > > > > > Well let's face it AGP is a total headache to maintain and dead for at > > > least 10+ years. >

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Sat, 29 Feb 2020 at 05:34, Eric Anholt wrote: > > On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie wrote: > > > > On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote: > > > > > > On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote: > > > > b)

Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote: > > On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote: > > b) we probably need to take a large step back here. > > > > Look at this from a sponsor POV, why would I give X.org/fd.o > > sponsorship money that they are

Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Fri, 28 Feb 2020 at 07:27, Daniel Vetter wrote: > > Hi all, > > You might have read the short take in the X.org board meeting minutes > already, here's the long version. > > The good news: gitlab.fd.o has become very popular with our > communities, and is used extensively. This especially

Re: [PATCH 2/2] drm/amdgpu/display: use msleep rather than udelay for HDCP

Hey, I've pulled in these two patches to drm-next directly because my arm test build was broken. Dave. On Wed, 18 Dec 2019 at 06:47, Alex Deucher wrote: > > ARM has a 2000us limit for udelay. Switch to msleep. This code > executes in a worker thread so shouldn't be an atomic context. > >

Re: GART write flush error on SI w/ amdgpu

On Wed, 21 Jun 2017 at 00:03, Marek Olšák wrote: > > On Tue, Jun 20, 2017 at 1:46 PM, Christian König > wrote: > > Am 20.06.2017 um 12:34 schrieb Marek Olšák: > >> > >> BTW, I noticed the flush sequence in the kernel is wrong. The correct > >> flush sequence should be: > >> > >> 1)

Re: [PATCH] drm/amdgpu: move pci handling out of pm ops

On Fri, 22 Nov 2019 at 06:05, Alex Deucher wrote: > > On Thu, Nov 21, 2019 at 2:53 PM Dave Airlie wrote: > > > > On Fri, 22 Nov 2019 at 02:55, Alex Deucher wrote: > > > > > > The documentation says the that PCI core handles this > > > for you

Re: [PATCH] drm/amdgpu: move pci handling out of pm ops

On Fri, 22 Nov 2019 at 02:55, Alex Deucher wrote: > > The documentation says the that PCI core handles this > for you unless you choose to implement it. Just rely > on the PCI core to handle the pci specific bits. > > Signed-off-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdgpu/amdgpu.h

radeon backtrace on fedora 31

5.3.4-300.fc31.x86_64 seems to be new. https://retrace.fedoraproject.org/faf/reports/2726149/ Dave. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/amdgpu: Add modeset module option

shes on load, and you want to debug them, people boot with nomodeset and then modprobe amdgpu modeset=1 to get the crash in a running system. This works for numerous other drivers, I'm not sure why amdgpu needs to be the odd one out. Reviewed-by: Dave Airlie Dave. __

Re: [PATCH] radeon: add option so DVI always respect HPD over DDC

On Mon, 9 Sep 2019 at 08:52, Deucher, Alexander wrote: > > > -Original Message- > > From: amd-gfx On Behalf Of > > Dave Airlie > > Sent: Sunday, September 1, 2019 11:09 PM > > To: amd-gfx@lists.freedesktop.org > > Subject: [PATCH] radeon: add op

Re: [PATCH v2 15/27] drm/dp_mst: Cleanup drm_dp_send_link_address() a bit

e work inside them, and can wrap lines even less. Then > finally, rearrange variable declarations a bit. > > Cc: Juston Li > Cc: Imre Deak > Cc: Ville Syrjälä > Cc: Harry Wentland > Cc: Daniel Vetter > Signed-off-by: Lyude Paul Reviewed-by: Dave Airlie _

Re: [PATCH v2 11/27] drm/dp_mst: Constify guid in drm_dp_get_mst_branch_by_guid()

On Wed, 4 Sep 2019 at 06:48, Lyude Paul wrote: > > And it's helper, we'll be using this in just a moment. > Reviewed-by: Dave Airlie > Cc: Juston Li > Cc: Imre Deak > Cc: Ville Syrjälä > Cc: Harry Wentland > Cc: Daniel Vetter > Signed-off-by: Lyude Pau

Re: [PATCH v2 06/27] drm/dp_mst: Combine redundant cases in drm_dp_encode_sideband_req()

se the patch doesn't make sense. With that fixed: Reviewed-by: Dave Airlie

Re: [pull] amdgpu drm-next-5.4

On Sat, 31 Aug 2019 at 07:27, Alex Deucher wrote: > > Hi Dave, Daniel, > > Mostly bug fixes. The big addition is display support for renoir > which is new for 5.4. I realize it's a bit late to add it but the > rest of the code for renoir is already in so it would be nice to > get the display

[PATCH] radeon: add option so DVI always respect HPD over DDC

From: Dave Airlie Purelink FX-D120 (DVI over fibre extendeders) drive the HPD line low on the GPU side when the monitor side device is unplugged or loses the connection. However the GPU side device seems to cache EDID in this case. Per DVI spec the HPD line must be driven in order for EDID

Re: [PATCH 14/17] drm/amd/display: Isolate DSC module from driver dependencies

On Thu, 29 Aug 2019 at 07:04, Bhawanpreet Lakha wrote: > > From: Bayan Zabihiyan > > [Why] > Edid Utility wishes to include DSC module from driver instead > of doing it's own logic which will need to be updated every time > someone modifies the driver logic. > > [How] > Modify some functions

Re: [pull] amdgpu, amdkfd, radeon, ttm drm-next-5.4

On Wed, 7 Aug 2019 at 06:03, Alex Deucher wrote: > > Hi Dave, Daniel, > > The big updates here are support for new asics (navi14, navi12, arcturus). Thanks Alex, but due to the readq/writeq this break my local validation builds which means we need to land a fix for that somehow first. Also this

Re: between commits d7d170a8e357 and 22051d9c4a57 begins issue page allocation failure in gnome-shell process

On Wed, 31 Jul 2019 at 05:34, Mikhail Gavrilov wrote: > > Is anyone here? Is everyone so busy what is wrong? > RC2 is still affected by this issue and unusable for every day because > opening a video in totem player cause DE a hang with a lot of > messages: > This looks like dc_state got a size

Re: The issue with page allocation 5.3 rc1-rc2 (seems drm culprit here)

On Mon, 5 Aug 2019 at 08:23, Mikhail Gavrilov wrote: > > Hi folks, > Two weeks ago when commit 22051d9c4a57 coming to my system. > Started happen randomly errors: > "gnome-shell: page allocation failure: order:4, > mode:0x40cc0(GFP_KERNEL|__GFP_COMP), > nodemask=(null),cpuset=/,mems_allowed=0" >

Re: [pull] amdgpu, radeon, amdkfd drm-next-5.3

On Thu, 27 Jun 2019 at 13:07, Dave Airlie wrote: > > Thanks, > > I've pulled this, but it introduced one warning > > /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c: In > function ‘vcn_v2_0_start_dpg_mode’: > /home/airlied/devel/kernel/dim/src/dr

Re: [PATCH 08/24] drm/amd/display: add audio related regs

On Fri, 7 Jun 2019 at 06:55, Bhawanpreet Lakha wrote: > > From: Charlene Liu > > Signed-off-by: Charlene Liu > Reviewed-by: Chris Park > Acked-by: Bhawanpreet Lakha > --- > drivers/gpu/drm/amd/display/dc/dce/dce_audio.c | 4 +--- > drivers/gpu/drm/amd/display/dc/dce/dce_audio.h | 7 +++ >

Re: arm32 build failure after abe882a39a9c ("drm/amd/display: fix issue with eDP not detected on driver load")

Hi Alex, please resolve this ASAP, I cannot pull your tree without this fixed as it breaks my arm builds here. an 8 second delay there seems pointless and arbitary, an 8 sec delay there without a comment, seems like a lack of review. Dave. On Tue, 18 Jun 2019 at 11:12, Nathan Chancellor

Re: [pull] amdgpu, ttm drm-next-5.3

On Thu, 6 Jun 2019 at 05:12, Alex Deucher wrote: > > Hi Dave, Daniel, > > More new stuff for 5.3: > > amdgpu: > - Revert timeline support until KHR is ready > - Various driver reload fixes > - Refactor clock handling in DC > - Aux fixes for DC > - Bandwidth calculation updates for DC > - Fix

Re: [PATCH 6/8] drm/amdkfd: New IOCTL to allocate queue GWS

On Sat, 1 Jun 2019 at 06:04, Kuehling, Felix wrote: > > On 2019-05-30 11:13 p.m., Dave Airlie wrote: > > On Sat, 25 May 2019 at 05:48, Kuehling, Felix > > wrote: > >> On 2019-05-23 6:41 p.m., Zeng, Oak wrote: > >>> Add a new kfd ioctl to allocate queue GW

Re: [PATCH 6/8] drm/amdkfd: New IOCTL to allocate queue GWS

On Sat, 25 May 2019 at 05:48, Kuehling, Felix wrote: > > On 2019-05-23 6:41 p.m., Zeng, Oak wrote: > > Add a new kfd ioctl to allocate queue GWS. Queue > > GWS is released on queue destroy. > > > > Change-Id: I60153c26a577992ad873e4292e759e5c3d5bbd15 > > Signed-off-by: Oak Zeng > > Reviewed-by:

Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

On Wed, 29 May 2019 at 02:47, Emil Velikov wrote: > > On 2019/05/28, Koenig, Christian wrote: > > Am 28.05.19 um 18:10 schrieb Emil Velikov: > > > On 2019/05/28, Daniel Vetter wrote: > > >> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian > > >> wrote: > > >>> Am 28.05.19 um 09:38 schrieb

Re: [Intel-gfx] [PATCH v2] drm: prefix header search paths with $(srctree)/

Daniel, drm-misc-next-fixes? Dave. On Fri, 26 Apr 2019 at 12:25, wrote: > > Hi Dave, > > > -Original Message- > > From: Dave Airlie [mailto:airl...@gmail.com] > > Sent: Friday, April 26, 2019 11:19 AM > > To: Yamada, Masahiro/山田 真弘 > > Cc: David

Re: [Intel-gfx] [PATCH v2] drm: prefix header search paths with $(srctree)/

m/linux/kernel/git/masahiroy/linux-kbuild.git > > build-test > > > Is somebody taking care of this? > Are you expecting this to be merged in the drm tree? if so please indicate that when posting. I'd assumed this would go via kbuild tree. If the later, Acked-by: Dave Airlie Dave. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/9] drm/syncobj: add new drm_syncobj_add_point interface v4

> Well, I've got commit rights as well. > > Going to remove the warning, add your rb and push everything if nobody > objects in the next hour or so. So this got committed and is in my -next tree, but where is the userspace and igt tests? There needs to be a functional mesa userspace and a set of

Re: [pull] amdgpu, amdkfd, ttm drm-next-5.2

On Fri, 29 Mar 2019 at 03:44, Alex Deucher wrote: > > Hi Dave, Daniel, > > New stuff for 5.2: 32-bit arm build: /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c: In function ‘smu_v11_0_notify_memory_pool_location’:

Re: [pull] amdgpu, amdkfd, ttm, sched drm-next-5.1

On Tue, 5 Feb 2019 at 04:35, Alex Deucher wrote: > > On Sun, Feb 3, 2019 at 11:57 PM Dave Airlie wrote: > > > > On Mon, 4 Feb 2019 at 13:27, Dave Airlie wrote: > > > > > > On Sat, 26 Jan 2019 at 09:15, Alex Deucher wrote: > > > > > >

Re: [pull] amdgpu, amdkfd, ttm, sched drm-next-5.1

On Mon, 4 Feb 2019 at 13:27, Dave Airlie wrote: > > On Sat, 26 Jan 2019 at 09:15, Alex Deucher wrote: > > > > Hi Dave, Daniel, > > > > New stuff for 5.1. > > amdgpu: > > - DC bandwidth formula updates > > - Support for DCC on scanout surfaces &g

Re: [pull] amdgpu, amdkfd, ttm, sched drm-next-5.1

On Sat, 26 Jan 2019 at 09:15, Alex Deucher wrote: > > Hi Dave, Daniel, > > New stuff for 5.1. > amdgpu: > - DC bandwidth formula updates > - Support for DCC on scanout surfaces > - Support for multiple IH rings on soc15 asics > - Fix xgmi locking > - Add sysfs interface to get pcie usage stats >

Re: [PATCH] drm/amdkfd: Fix if preprocessor statement above kfd_fill_iolink_info_for_cpu

Alex, can you get this into next and resend the pull? I don't like adding warnings. Dave. On Fri, 1 Feb 2019 at 06:10, Kuehling, Felix wrote: > > Thank you, Nathan. I applied your patch to amd-staging-drm-next. > > Sorry for the late response. I'm catching up with my email backlog after > a

Re: [pull] amdgpu drm-next-4.21

On Thu, 13 Dec 2018 at 07:13, Alex Deucher wrote: > > Hi Dave, > > Updates for 4.21: > - Powerplay updates for newer polaris variants > - Add cursor plane update fast path > - Enable gpu reset by default on CI parts > - Fix config with KFD/HSA not enabled > - Misc bug fixes > Either this or the

Re: [Intel-gfx] [PATCH] RFC: Make igts for cross-driver stuff mandatory?

no idea what a baseline IGT test run looks like on non-intel hw, how useful is it? Acked-by: Dave Airlie ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [pull] amdgpu/kfd, radeon, ttm, scheduler drm-next-4.20

On Thu, 20 Sep 2018 at 14:03, Dave Airlie wrote: > > On my 32-bit arm build > > MODPOST 1797 modules > ERROR: "__aeabi_uldivmod" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! > > Somebody added a ul/ul without using the do_div stuff. > > I won't

Re: [pull] amdgpu/kfd, radeon, ttm, scheduler drm-next-4.20

On my 32-bit arm build MODPOST 1797 modules ERROR: "__aeabi_uldivmod" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! Somebody added a ul/ul without using the do_div stuff. I won't pull this until it's fixed. Dave. On Sat, 15 Sep 2018 at 01:52, Alex Deucher wrote: > > Hi Dave, > > First

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

R. > >> So I still think the patch is the way to go. If people are concerned that > >> also fbdev file descriptors are allowed, perhaps there are other sysfs > >> traits we can look at? > > Somewhat out of curiosity, but why do you have to overwrite all of drm? > > amdgpu seems to be able to pull their stunt off without ... > > -Daniel > > At the time we launched the standalone vmwgfx, the DRM <-> driver > interface was moving considerably more rapidly than the DRM <-> kernel > interface. I think that's still the case. Hence less work for us. Also > meant we can install the full driver stack with latest features on > fairly old VMs without backported DRM functionality. > I think this should be fine for 99% of drm usage, there may be corner cases in wierd places, but I can't point to any that really matter (maybe strace?) Acked-by: Dave Airlie Dave. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm] Add basic CONTRIBUTING file

roles > ("Owner" and "Developer" in gitlab-speak). This should avoid > conflating libdrm roles with mesa roles, useful for those pushing to > libdrm as primarily kernel contributors. Fine with me, Acked-by: Dave Airlie Dave. ___

Re: [PATCH 38/54] drm/amd/display: Expose bunch of functions from dcn10_hw_sequencer

This has some whitespace changes that don't seem to be related, please get people to be a bit more careful. (though I do realise this could be magic ifdef stuff that got ripped out :-) Dave. On 10 July 2018 at 10:37, Harry Wentland wrote: > From: Eric Bernstein > > Signed-off-by: Eric

Re: [PATCH 1/2] drm/amdgpu: switch firmware path for CIK parts

On 3 July 2018 at 05:36, Alex Deucher wrote: > Use separate firmware path for amdgpu to avoid conflicts > with radeon on CIK parts. > Won't that cause a chicken and egg problem, new kernel with old firmware package will suddenly start failing, or do we not really care since in theory we don't

Re: [PATCH 5/5] drm: drop drm_pcie_get_speed_cap_mask and drm_pcie_get_max_link_width

p them. > > Signed-off-by: Alex Deucher Reviewed-by: Dave Airlie Dave. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: replace mutex with spin_lock (V2)

On 31 May 2018 at 20:02, Shirish S wrote: > mutex's lead to sleeps which should be avoided in > atomic context. > Hence this patch replaces it with the spin_locks. > > Below is the stack trace: I'm not sure I really like this series of patches, going around replacing ATOMIC and mutex with

Re: [PATCH 04/21] drm/amdgpu: Add GFXv9 kfd2kgd interface functions

> +static int kgd_hqd_load(struct kgd_dev *kgd, void *mqd, uint32_t pipe_id, > + uint32_t queue_id, uint32_t __user *wptr, > + uint32_t wptr_shift, uint32_t wptr_mask, > + struct mm_struct *mm) > +{ > + struct amdgpu_device

4.17-rc3 oops and cpu blocked

I was running latest drm-next kernel + radv with sdma support + Vulkan CTS dEQP-VK.synchronization.internally_synchronized_objects.pipeline_cache_compute caused the below explosion to happen, Dave. [ 2119.182156] [ cut here ] [ 2119.182158] kernel BUG at

Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE

> > > Yes, I fixed the original false positive messages myself with the swiotlb > maintainer and I was CCed in fixing the recent fallout from Chris changes as > well. So do we have a good summary of where this at now? I'm getting reports on 4.16.4 still displaying these, what hammer do I need to

Re: New KFD ioctls: taking the skeletons out of the closet

On 7 March 2018 at 08:44, Felix Kuehling wrote: > Hi all, > > Christian raised two potential issues in a recent KFD upstreaming code > review that are related to the KFD ioctl APIs: > > 1. behaviour of -ERESTARTSYS > 2. transactional nature of KFD ioctl definitions, or

Re: [PATCH 04/37] drm/amdgpu: Implement get_local_mem_info

On 9 December 2017 at 14:08, Felix Kuehling wrote: > From: Harish Kasiviswanathan > > Implement new kgd-kfd interface function get_local_mem_info. > > Signed-off-by: Harish Kasiviswanathan > Signed-off-by:

Re: Initial release of AMD Open Source Driver for Vulkan

On 22 December 2017 at 21:03, Mao, David wrote: > We are pleased to announce the initial release of AMD Open Source Driver for > Vulkan. > > > > The AMD Open Source Driver for Vulkan is an open-source Vulkan driver for > Radeon graphics adapters on Linux. It is built on top of

[PATCH] amdgpu/dc: fix indentation warning from smatch.

From: Dave Airlie <airl...@redhat.com> This fixes all the current smatch: warn: inconsistent indenting Signed-off-by: Dave Airlie <airl...@redhat.com> --- drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 2 +- .../gpu/drm/amd/display/dc/bios/command_table2.c | 18 ++

  1   2   3   4   >