the VRAM backend.
> >
> > Signed-off-by: Christian König
> > Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3501
> > Fixes: e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour")
>
> Cc: stable
>
> Reviewed-by: Alex Deucher
Cc: sta...@vger.kernel.org
Tested-by: Dave Airlie
Dave.
On Wed, 24 Jul 2024 at 23:32, Alex Deucher wrote:
>
> On Wed, Jul 24, 2024 at 4:00 AM Christian König
> wrote:
> >
> > Otherwise we won't get correct access to the IB.
> >
> > Signed-off-by: Christian König
>
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3501
> Fixes: e362b7c8f8c7 ("
On Thu, 25 Jul 2024 at 09:09, Dave Airlie wrote:
>
> On Wed, 24 Jul 2024 at 23:32, Alex Deucher wrote:
> >
> > On Wed, Jul 24, 2024 at 4:00 AM Christian König
> > wrote:
> > >
> > > Otherwise we won't get correct access to the IB.
> > &
On Wed, 24 Jul 2024 at 23:32, Alex Deucher wrote:
>
> On Wed, Jul 24, 2024 at 4:00 AM Christian König
> wrote:
> >
> > Otherwise we won't get correct access to the IB.
> >
> > Signed-off-by: Christian König
>
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3501
> Fixes: e362b7c8f8c7 ("
From: Dave Airlie
This is a partial revert of drm/amdgpu: Modify the contiguous flags behaviour.
This broke VCN AV1 decoding on radv video on GFX11.
On VCN4 only the first VCN block has AV1 decode support, so the kernel has
a hacky heurisitic to work out from the submitted IB if it's AV1
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:
>
> https://gitlab.freedesktop.org/a
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 b
/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]
link_cap->li
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 M
>
> 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 d
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.
>
> Th
em.c | 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.
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, a
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:
> >
> > drivers/gpu/drm/am
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?
>
>
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 n
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 possible
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.
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’:
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/core
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 in
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
>
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 suitable
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
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
> https://gitlab.freedesktop.org/agd5f/
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
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 repo
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 syn
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: Changed
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.
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 be
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 t
x init into drm_dp_aux_init(), 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:
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
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
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
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
> arch/x86/mm/i
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 'amd
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)
>
>
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 explai
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
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,
> I
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.
> > Sur
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 l
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, ADEV_TO_DR
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
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|
On Thu, 6 Aug 2020 at 23:51, Christian König
wrote:
>
> The names get/put are associated with reference counting
> in the Linux kernel, use alloc/free instead.
>
Sounds good,
Reviewed-by: Dave Airlie
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/am
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
>
> >> 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
> >> enablin
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
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 gen
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
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 signed-off-by.
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 ca
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.
>
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)
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
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 inclu
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.
>
> Sign
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) EVENT_WRITE_EO
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
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
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
amdgpu crashes
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.
___
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
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
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:
se the patch doesn't make sense.
With that fixed:
Reviewed-by: Dave Airlie
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 par
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 to be
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 such
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
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 i
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"
> S
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/s
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 +++
>
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
wrote:
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 docum
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
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: F
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 Danie
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
ux/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
> 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
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’:
/home/airlied/devel/kernel/dim/src/drivers/
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:
> > > >
> >
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
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
> -
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 va
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 p
main one,
I've 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
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 pull
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 pull
gt;> are registered with the DRM_MAJOR.
> >> 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
tainer/commiter 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.
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 Bernste
typo in subject.
On 10 July 2018 at 10:37, Harry Wentland wrote:
> From: Hersen Wu
>
> [Why]
> when hw team does phy parameters tuning, there is need to force dp
> link rate or lane count grater than the values from dp receiver to
> check dp tx. current debufs limit link rate, lane count no mo
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 sup
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
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 spinloc
1 - 100 of 399 matches
Mail list logo
