On Thu, Dec 17, 2020 at 04:06:38PM -0500, Andrey Grodzovsky wrote:
>
> On 12/17/20 3:48 PM, Daniel Vetter wrote:
> > On Thu, Dec 17, 2020 at 9:38 PM Andrey Grodzovsky
> > wrote:
> > >
> > > On 12/17/20 3:10 PM, Christian König wrote:
> > > > [SN
>>> - handle fbcon somehow. I think shutting it all down should work out.
> >>>>>>> - worst case keep the system backing storage around for shared dma-buf
> >>>>>>> until the other non-dynamic driver releases it. for vram we require
> >>>
On Thu, Dec 17, 2020 at 8:19 PM Andrey Grodzovsky
wrote:
>
>
> On 12/17/20 7:01 AM, Daniel Vetter wrote:
> > On Wed, Dec 16, 2020 at 07:20:02PM -0500, Andrey Grodzovsky wrote:
> >> On 12/16/20 6:15 PM, Daniel Vetter wrote:
> >>> On Wed, Dec 16, 2020 at 7:
On Wed, Dec 16, 2020 at 07:20:02PM -0500, Andrey Grodzovsky wrote:
>
> On 12/16/20 6:15 PM, Daniel Vetter wrote:
> > On Wed, Dec 16, 2020 at 7:26 PM Andrey Grodzovsky
> > wrote:
> > >
> > > On 12/16/20 12:12 PM, Daniel Vetter wrote:
> > > >
On Wed, Dec 16, 2020 at 7:26 PM Andrey Grodzovsky
wrote:
>
>
> On 12/16/20 12:12 PM, Daniel Vetter wrote:
> > On Wed, Dec 16, 2020 at 5:18 PM Christian König
> > wrote:
> >> Am 16.12.20 um 17:13 schrieb Andrey Grodzovsky:
> >>> On 12/16/20 9:21 AM,
On Wed, Dec 16, 2020 at 11:39 PM Alex Deucher wrote:
>
> On Wed, Dec 16, 2020 at 5:28 PM Daniel Vetter wrote:
> >
> > On Wed, Dec 16, 2020 at 02:24:20PM -0500, Alex Deucher wrote:
> > > Hi Dave, Daniel,
> > >
> > > Fixes for 5.11.
&
gt; diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h
> index f7d731797d3f..0235bfb246e5 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h
> +++ b/drivers/gpu/drm/amd/display/am
/include/atomfirmware.h | 1 +
> drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h| 1 +
> drivers/gpu/drm/amd/pm/inc/smu_types.h | 4 +-
> drivers/gpu/drm/amd/pm/inc/smu_v11_0_7_ppsmc.h | 6 +-
> drivers/gpu/drm/amd/pm/inc/smu_v11_5_ppsmc.h |
On Wed, Dec 16, 2020 at 6:12 PM Daniel Vetter wrote:
>
> On Wed, Dec 16, 2020 at 5:18 PM Christian König
> wrote:
> >
> > Am 16.12.20 um 17:13 schrieb Andrey Grodzovsky:
> > >
> > > On 12/16/20 9:21 AM, Daniel Vetter wrote:
> > >> On Wed, De
On Wed, Dec 16, 2020 at 5:18 PM Christian König
wrote:
>
> Am 16.12.20 um 17:13 schrieb Andrey Grodzovsky:
> >
> > On 12/16/20 9:21 AM, Daniel Vetter wrote:
> >> On Wed, Dec 16, 2020 at 9:04 AM Christian König
> >> wrote:
> >>> Am 15.12.20
point all these cpu ptes to some other place.
-Daniel
>
> Christian.
>
> > I loaded the driver with vm_update_mode=3
> > meaning all VM updates done using CPU and hasn't seen any OOPs after
> > removing the device. I guess i can test it more by allocating GTT and
> > VRAM BOs
> > and trying
On Mon, Dec 14, 2020 at 02:20:39PM -0500, Alex Deucher wrote:
> On Mon, Dec 14, 2020 at 2:17 PM Daniel Vetter wrote:
> >
> > I guess Christian didn't compile test amdkfd.
> >
> > Fixes: e11bfb99d6ec ("drm/ttm: cleanup BO size handling v3")
> > Cc:
I guess Christian didn't compile test amdkfd.
Fixes: e11bfb99d6ec ("drm/ttm: cleanup BO size handling v3")
Cc: Christian König
Cc: Huang Rui (v1)
Cc: Daniel Vetter
Cc: Felix Kuehling
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu
]
> > > >
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: amd-gfx On Behalf Of
> > > >> Daniel Vetter
> > > >> Sent: Monday, September 7, 2020 3:15 AM
> > > >> T
On Thu, Dec 03, 2020 at 03:06:20AM +, Zack Rusin wrote:
>
>
> > On Dec 2, 2020, at 11:03, Daniel Vetter wrote:
> >
> > On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin wrote:
> >>
> >>
> >>
> >>> On Dec 2, 2020, at 09:27, Thomas
t. If you're OK with that, I'd merge the vmwgfx patch through
> > drm-misc-next as well.
>
> Sounds good. I’ll make sure to rebase our latest patch set on top of it when
> it’s in. Thanks!
btw if you want to avoid multi-tree coordination headaches, we can
also m
On Fri, Nov 27, 2020 at 11:04:55AM -0500, Andrey Grodzovsky wrote:
>
> On 11/27/20 9:59 AM, Daniel Vetter wrote:
> > On Wed, Nov 25, 2020 at 02:34:44PM -0500, Andrey Grodzovsky wrote:
> > > On 11/25/20 11:36 AM, Daniel Vetter wrote:
> > > > On Wed, Nov 25, 20
On Fri, Nov 27, 2020 at 03:49:31PM +0100, Christian König wrote:
> Am 27.11.20 um 15:46 schrieb Daniel Vetter:
> > On Fri, Nov 27, 2020 at 3:10 PM Christian König
> > wrote:
> > > Am 27.11.20 um 09:31 schrieb Dave Airlie:
> > > > Oops sorry for delay LGTM
>
On Wed, Nov 25, 2020 at 12:39:47PM -0500, Andrey Grodzovsky wrote:
>
> On 11/25/20 4:04 AM, Daniel Vetter wrote:
> > On Tue, Nov 24, 2020 at 11:27 PM Andrey Grodzovsky
> > wrote:
> > >
> > > On 11/24/20 9:49 AM, Daniel Vetter wrote:
> > > >
On Wed, Nov 25, 2020 at 02:34:44PM -0500, Andrey Grodzovsky wrote:
>
> On 11/25/20 11:36 AM, Daniel Vetter wrote:
> > On Wed, Nov 25, 2020 at 01:57:40PM +0100, Christian König wrote:
> > > Am 25.11.20 um 11:40 schrieb Daniel Vetter:
> > > > On Tue, Nov 24, 20
On Fri, Nov 27, 2020 at 3:10 PM Christian König
wrote:
>
> Am 27.11.20 um 09:31 schrieb Dave Airlie:
> > Oops sorry for delay LGTM
> >
> > Reviewed-by: Dave Airlie
>
> Thanks.
>
> >
> > On Fri, 27 Nov 2020 at 02:34, Daniel Vetter wrote:
> &g
eds Fixes: 28a68f828266 ("drm/radeon/ttm: use multihop")
Btw
$ dim fixes [sha1]
generates that for you plus nice cc list of offenders. With the Fixes
line added:
Reviewed-by: Daniel Vetter
At least I'm hanging onto the illusion that I understand what you did here :-)
-Daniel
> --
On Thu, Nov 26, 2020 at 11:15 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 25.11.20 um 17:32 schrieb Daniel Vetter:
> > [...]
> > I guess full locking is required :-/ I'm not exactly sure how to make this
> > happen with the current plethora of helpers ... I thin
cept integrated gpu which have A) a coherent
fabric with the gpu and B) that fabric is actually faster for
rendering in general, not just for dedicated buffers allocated for
down/upload.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
__
On Wed, Nov 25, 2020 at 01:57:40PM +0100, Christian König wrote:
> Am 25.11.20 um 11:40 schrieb Daniel Vetter:
> > On Tue, Nov 24, 2020 at 05:44:07PM +0100, Christian König wrote:
> > > Am 24.11.20 um 17:22 schrieb Andrey Grodzovsky:
> > > > On 11/24/20 2:41 AM, Chris
On Wed, Nov 25, 2020 at 12:38:01PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 25.11.20 um 11:36 schrieb Daniel Vetter:
> > On Wed, Nov 25, 2020 at 11:13:13AM +0100, Christian König wrote:
> > > Am 25.11.20 um 09:37 schrieb Thomas Zimmermann:
> > > > Hi
&
On Tue, Nov 24, 2020 at 10:51:57AM -0500, Andrey Grodzovsky wrote:
>
> On 11/24/20 9:53 AM, Daniel Vetter wrote:
> > On Sat, Nov 21, 2020 at 12:21:18AM -0500, Andrey Grodzovsky wrote:
> > > Some of the stuff in amdgpu_device_fini such as HW interrupts
> > > disable a
> >
> > While we can't control user application accesses to the mapped buffers
> > explicitly and hence we use page fault rerouting
> > I am thinking that in this case we may be able to sprinkle
> > drm_dev_enter/exit in any such sensitive pla
On Wed, Nov 25, 2020 at 11:13:13AM +0100, Christian König wrote:
> Am 25.11.20 um 09:37 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 24.11.20 um 15:09 schrieb Daniel Vetter:
> > > On Tue, Nov 24, 2020 at 02:56:51PM +0100, Thomas Zimmermann wrote:
> > > >
On Tue, Nov 24, 2020 at 11:27 PM Andrey Grodzovsky
wrote:
>
>
> On 11/24/20 9:49 AM, Daniel Vetter wrote:
> > On Sat, Nov 21, 2020 at 12:21:20AM -0500, Andrey Grodzovsky wrote:
> >> Avoids NULL ptr due to kobj->sd being unset on device removal.
> >>
&
pu_ras.c
> @@ -2142,9 +2142,12 @@ int amdgpu_ras_pre_fini(struct amdgpu_device *adev)
> {
> struct amdgpu_ras *con = amdgpu_ras_get_context(adev);
>
> + //DRM_ERROR("adev 0x%llx", (long long unsigned int)adev);
> +
> if (!con)
> return 0;
>
> +
> /* Need disable ras on all IPs here before ip [hw/sw]fini */
> amdgpu_ras_disable_all_features(adev, 0);
> amdgpu_ras_recovery_fini(adev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> index 7112137..074f36b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> @@ -107,7 +107,8 @@ struct amdgpu_fence_driver {
> };
>
> int amdgpu_fence_driver_init(struct amdgpu_device *adev);
> -void amdgpu_fence_driver_fini(struct amdgpu_device *adev);
> +void amdgpu_fence_driver_fini_early(struct amdgpu_device *adev);
> +void amdgpu_fence_driver_fini_late(struct amdgpu_device *adev);
> void amdgpu_fence_driver_force_completion(struct amdgpu_ring *ring);
>
> int amdgpu_fence_driver_init_ring(struct amdgpu_ring *ring,
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
up(&adev->dev->kobj, &fw_attr_group);
> + if (!drm_dev_is_unplugged(&adev->ddev))
> + sysfs_remove_group(&adev->dev->kobj, &fw_attr_group);
> }
>
> static int amdgpu_ucode_init_single_fw(struct amdgpu_device *adev,
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
drey Grodzovsky
>
> Reviewed-by: Christian König
Was wondering for a moment whether this should be in drm_dev_unregister
instead, but then it's only one part of the coin really. So
Reviewed-by: Daniel Vetter
>
> > ---
> > drivers/gpu/drm/drm_drv.c | 3 +++
> > 1 fi
b67f695c4f2#n394
>
> >
> > Please note that the reservation lock you need to take here is part of
> > the GEM object.
> >
> > Usually we design things in the way that the code needs to take a lock
> > which prote
On Thu, Nov 19, 2020 at 10:02:28AM -0500, Andrey Grodzovsky wrote:
>
> On 11/19/20 2:55 AM, Christian König wrote:
> > Am 18.11.20 um 17:20 schrieb Andrey Grodzovsky:
> > >
> > > On 11/18/20 7:01 AM, Christian König wrote:
> > > > Am 18.11.20 um 08:39 sc
On Tue, Nov 17, 2020 at 9:07 PM Andrey Grodzovsky
wrote:
>
>
> On 11/17/20 2:49 PM, Daniel Vetter wrote:
> > On Tue, Nov 17, 2020 at 02:18:49PM -0500, Andrey Grodzovsky wrote:
> >> On 11/17/20 1:52 PM, Daniel Vetter wrote:
> >>> On Tue, Nov 17, 2020 at 01:38
On Tue, Nov 17, 2020 at 02:18:49PM -0500, Andrey Grodzovsky wrote:
>
> On 11/17/20 1:52 PM, Daniel Vetter wrote:
> > On Tue, Nov 17, 2020 at 01:38:14PM -0500, Andrey Grodzovsky wrote:
> > > On 6/22/20 5:53 AM, Daniel Vetter wrote:
> > > > On Sun, Jun 21,
On Tue, Nov 17, 2020 at 01:38:14PM -0500, Andrey Grodzovsky wrote:
>
> On 6/22/20 5:53 AM, Daniel Vetter wrote:
> > On Sun, Jun 21, 2020 at 02:03:08AM -0400, Andrey Grodzovsky wrote:
> > > No point to try recovery if device is gone, just messes up things.
> > >
On Sat, Nov 14, 2020 at 10:51 AM Daniel Vetter wrote:
>
> On Sat, Nov 14, 2020 at 9:41 AM Christian König
> wrote:
> >
> > Am 13.11.20 um 21:52 schrieb Andrey Grodzovsky:
> > >
> > > On 6/22/20 1:50 PM, Daniel Vetter wrote:
> > >> On Mon, Ju
On Sat, Nov 14, 2020 at 9:41 AM Christian König
wrote:
>
> Am 13.11.20 um 21:52 schrieb Andrey Grodzovsky:
> >
> > On 6/22/20 1:50 PM, Daniel Vetter wrote:
> >> On Mon, Jun 22, 2020 at 7:45 PM Christian König
> >> wrote:
> >>> Am 22.06.20 um 16:3
On Thu, Nov 12, 2020 at 9:07 PM Simon Ser wrote:
>
> CC Daniel Vetter and Bas, see below…
>
> On Thursday, November 12, 2020 8:56 PM, Kazlauskas, Nicholas
> wrote:
>
> > Reviewed-by: Nicholas kazlauskasnicholas.kazlaus...@amd.com
>
> Thanks for the re
On Wed, Nov 11, 2020 at 11:19:04PM -0500, Andrey Grodzovsky wrote:
>
> On 6/22/20 5:48 AM, Daniel Vetter wrote:
> > On Sun, Jun 21, 2020 at 02:03:04AM -0400, Andrey Grodzovsky wrote:
> > > Some of the stuff in amdgpu_device_fini such as HW interrupts
> > > disable a
bles as __maybe_unused
> > > gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function
> > > 'analogix_dp_start_aux_transaction'
> >
> > As commented on the other patches, the subject prefixes on most of these
> > look wrong, but it
ightmare. And when an oops happens, this might be the only thing that
manages to get the oops to the user.
Unless someone really starts caring about fbcon acceleration I really
wouldn't bother. Ok maybe it also matters for fbdev, but the problem is
that the page fault intercepting alone is
iewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_drv.c | 85 -
drivers
fences_ioctl,
> DRM_AUTH|DRM_RENDER_ALLOW),
> - DRM_IOCTL_DEF_DRV(AMDGPU_GEM_METADATA, amdgpu_gem_metadata_ioctl,
> DRM_AUTH|DRM_RENDER_ALLOW),
> - DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl,
> DRM_AUTH|DRM_RENDER_ALLOW),
> - DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl,
> DRM_AUTH|DRM_RENDER_ALLOW),
> - DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl,
> DRM_AUTH|DRM_RENDER_ALLOW),
> - DRM_IOCTL_DEF_DRV(AMDGPU_FREESYNC, amdgpu_display_freesync_ioctl,
> DRM_MASTER)
> -};
> -const int amdgpu_max_kms_ioctl = ARRAY_SIZE(amdgpu_ioctls_kms);
> -
> /*
> * Debugfs info
> */
> --
> 2.29.2.154.g7f7ebe054a
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
-
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 4 ++-
> 3 files changed, 32 insertions(+), 29 deletions(-)
>
> --
> 2.29.2.154.g7f7ebe054a
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On Tue, Nov 03, 2020 at 04:54:50PM -0500, Alex Deucher wrote:
> Use the per device drm driver feature flags rather than the
> global one. This way we can make the drm driver struct const.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Daniel Vetter
Can we merge this through drm-mi
igned-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_drv.c | 85 -
drivers/gpu/drm/radeon/ra
On Fri, Oct 30, 2020 at 10:15:21AM +0100, Daniel Vetter wrote:
> On Fri, Oct 30, 2020 at 09:25:18AM +0100, Greg KH wrote:
> > On Fri, Oct 30, 2020 at 09:00:04AM +0100, Christian König wrote:
> > > Am 30.10.20 um 08:57 schrieb Deepak R Varma:
> > > > On Fri, Oct 30,
have two-stage cleanup
1. drm_dev_unregister (or drm_connector_unregisters, those are the only
two hotunpluggable things we have) unregister all the uapi interfaces.
This deletes all the sysfs and debugfs files.
2. Once all the references to the underlying object disappear from the
kernel, we free u
igned-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_drv.c | 85 -
drivers/gpu/drm/radeon/ra
aro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 ---
1 file changed, 8 insertions(+), 3
ists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_sw_fence_work.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.c
b/drivers/gpu/drm/i
amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/dri
rick only in tdr, it is rather intrusive.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel
nel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/a
ktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 549a
Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++
1 file changed, 6 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
nux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 +-
driver
But obviosly no expert on drm scheduler.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
-
lissa Wen
Reviewed-by: Rodrigo Siqueira
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vette
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_vblank.c | 8 +
dgpu_atombios.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4 ++--
> 5 files changed, 10 insertions
On Thu, Oct 22, 2020 at 11:18 AM Thomas Zimmermann wrote:
>
> Hi
>
> On 22.10.20 10:49, Daniel Vetter wrote:
> > On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote:
> >> Kernel DRM clients now store their framebuffer address in an instance
> >>
On Thu, Oct 22, 2020 at 10:37:56AM +0200, Thomas Zimmermann wrote:
> Hi
>
> On 22.10.20 10:05, Daniel Vetter wrote:
> > On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote:
> >> At least sparc64 requires I/O-specific access to framebuffers. This
> >>
fer_vmap() receive a copy of the value in
> the call's supplied arguments. It can be accessed and modified with
> dma_buf_map interfaces.
>
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Daniel Vetter
> Tested-by: Sam Ravnborg
&g
en without dependencies on the fbdev module. Some of the
> +helpers could further benefit from using struct dma_buf_map instead of
> +raw pointers.
> +
> +Contact: Thomas Zimmermann , Daniel Vetter
> +
> +Level: Advanced
> +
> +
> drm_framebuffer_funcs and drm_mode_conf
> > > /**
> > > > * ttm_bo_mmap_obj - mmap memory backed by a ttm buffer object.
> > > > *
> > > > diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
> > > > index fd1aba545fdf..2e8bbecb5091 100644
> > > > --- a/in
pers to map an invidual page (again using the
dma_buf_map stuff).
I'll let Christian with the details, but at a high level this is
definitely
Acked-by: Daniel Vetter
Thanks a lot for doing all this.
-Daniel
>
> >
> > Signed-off-by: Thomas
On Fri, Oct 09, 2020 at 12:49:44PM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> These kmap() calls in the gpu stack are localized to a single thread.
> To avoid the over head of global PKRS updates use the new kmap_thread()
> call.
>
> Cc: David Airlie
>
On Thu, Oct 8, 2020 at 11:25 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 02.10.20 um 20:44 schrieb Daniel Vetter:
> > On Fri, Oct 2, 2020 at 8:05 PM Daniel Vetter wrote:
> >>
> >> On Tue, Sep 29, 2020 at 05:14:36PM +0200, Thomas Zimmermann wrote:
> >>&g
On Wed, Oct 7, 2020 at 3:25 PM Christian König wrote:
>
> Am 07.10.20 um 15:20 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 07.10.20 um 15:10 schrieb Daniel Vetter:
> >> On Wed, Oct 7, 2020 at 2:57 PM Thomas Zimmermann
> >> wrote:
> >>> Hi
On Wed, Oct 7, 2020 at 2:57 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 02.10.20 um 11:58 schrieb Daniel Vetter:
> > On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote:
> >> On Wed, Sep 30, 2020 at 2:34 PM Christian König
> >> wrote:
> >&g
On Tue, Sep 29, 2020 at 05:14:37PM +0200, Thomas Zimmermann wrote:
> Instances of struct dma_buf_map should be useful throughout DRM's
> memory management code. Furthermore, several drivers can now use
> generic fbdev emulation.
>
> Signed-off-by: Thomas Zimmermann
Ack
On Fri, Oct 2, 2020 at 8:05 PM Daniel Vetter wrote:
>
> On Tue, Sep 29, 2020 at 05:14:36PM +0200, Thomas Zimmermann wrote:
> > At least sparc64 requires I/O-specific access to framebuffers. This
> > patch updates the fbdev console accordingly.
> >
> > For dri
nctionality, the type could be generalized
> - * and moved to a more prominent header file.
> + * .. code-block:: c
> + *
> + * const void *src = ...; // source buffer
> + * size_t len = ...; // length of src
> + *
> + * dma_buf_map_memcpy_to(&map, src, len);
> +
t; @@ -141,9 +142,9 @@ struct drm_client_buffer {
> struct drm_gem_object *gem;
>
> /**
> - * @vaddr: Virtual address for the buffer
> + * @map: Virtual address for the buffer
>*/
> - void *vaddr;
> +
rns 0 on success or a negative errno code otherwise.
> */
> int drm_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct dma_buf_map *map)
> {
> struct drm_gem_object *obj = dma_buf->priv;
> - void *vaddr;
>
> - vaddr = drm_gem_vmap(obj);
> - if (IS_ERR
On Tue, Sep 29, 2020 at 05:14:33PM +0200, Thomas Zimmermann wrote:
> This patch replaces the vmap/vunmap's use of raw pointers in GEM object
> functions with instances of struct dma_buf_map. GEM backends are
> converted as well.
>
> For most GEM backends, this simply change the returned type. GEM
On Fri, Oct 2, 2020 at 1:30 PM Christian König
wrote:
>
> Am 02.10.20 um 11:58 schrieb Daniel Vetter:
> > On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote:
> >> On Wed, Sep 30, 2020 at 2:34 PM Christian König
> >> wrote:
> >>> Am 30.09.20
On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote:
> On Wed, Sep 30, 2020 at 2:34 PM Christian König
> wrote:
> >
> > Am 30.09.20 um 11:47 schrieb Daniel Vetter:
> > > On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
> > >&
On Tue, Sep 29, 2020 at 05:14:31PM +0200, Thomas Zimmermann wrote:
> The parameters map and is_iomem are always of the same value. Removed them
> to prepares the function for conversion to struct dma_buf_map.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
andard definition of a THP, and allows DMA-BUF-importing
> >>> drivers to make sense of the pages within.
> >>>
> >>> I would like to propose making these allocations compound, but based on
> >>> patch history, it looks li
On Wed, Sep 30, 2020 at 2:34 PM Christian König
wrote:
>
> Am 30.09.20 um 11:47 schrieb Daniel Vetter:
> > On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
> >> Am 30.09.20 um 10:19 schrieb Thomas Zimmermann:
> >>> Hi
> >>>
>
> > > > + * .. code-block:: c
> > > > > > + *
> > > > > > + * dma_buf_map_set_vaddr_iomem(&map. 0xdeadbeaf);
> > > > > > + *
> > > > > > * Test if a mapping is valid with either dma_buf_map_is_set(
map->is_iomem = false;
> > }
> >
> > +/**
> > + * dma_buf_map_set_vaddr_iomem - Sets a dma-buf mapping structure to an
> > address in I/O memory
> > + * @map: The dma-buf mapping structure
> > + * @vaddr_iomem: An I/O-memory address
don't use
dma_resv_lock for any of this unfortunately. And I guess that would need
to be fixed first.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On Fri, Sep 18, 2020 at 01:12:21PM -0400, Rodrigo Vivi wrote:
> On Fri, Sep 18, 2020 at 11:03:12AM -0400, Alex Deucher wrote:
> > On Fri, Sep 18, 2020 at 9:25 AM Daniel Vetter
> > wrote:
> > >
> > > Hi all,
> > >
> > > These are the left
)
Signed-off-by: Daniel Vetter
---
.../gpu/drm/i915/selftests/mock_gem_device.c | 39 +--
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index ac600d395c8f
no longer needed for automatic
cleanup (CI). Update commit message to match.
- print correct error in pr_err (Matt)
v6: Remove now unused err variable (CI).
Cc: Matthew Auld
Reviewed-by: Maarten Lankhorst (v3)
Cc: Maarten Lankhorst
Reviewed-by: Matthew Auld (v4)
Signed-off-by: Daniel Vetter
no longer needed for automatic
cleanup (CI). Update commit message to match.
- print correct error in pr_err (Matt)
Cc: Matthew Auld
Reviewed-by: Maarten Lankhorst (v3)
Cc: Maarten Lankhorst
Reviewed-by: Matthew Auld (v4)
Signed-off-by: Daniel Vetter
---
.../gpu/drm/i915/selftests
On Fri, Sep 18, 2020 at 8:31 PM Matthew Auld
wrote:
>
> On Fri, 18 Sep 2020 at 19:22, Daniel Vetter wrote:
> >
> > On Fri, Sep 18, 2020 at 7:50 PM Matthew Auld
> > wrote:
> > >
> > > On Fri, 18 Sep 2020 at 14:25, Daniel Vetter
> > > wrote:
&
On Fri, Sep 18, 2020 at 7:50 PM Matthew Auld
wrote:
>
> On Fri, 18 Sep 2020 at 14:25, Daniel Vetter wrote:
> >
> > The big change is device_add so that device_del can auto-cleanup
> > devres resources. This allows us to use devm_drm_dev_alloc, which
> > removes
We can now also delete drm_dev_init, now that vkms, vgem and i915
selftests are resolved.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 41 +++---
drivers/gpu/drm/drm_internal.h | 1 +
drivers/gpu/drm/drm_managed.c | 13 ---
include/drm
)
Cc: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
.../gpu/drm/i915/selftests/mock_gem_device.c | 44 +++
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index
Just some prep work before we rework the lifetime handling, which
requires replacing all the drm_dev_put in selftests by something else.
v2: Don't go with a static inline, upsets the header tests and
separation.
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
drivers/gp
ector when
the DRM device's parent's devres "action" callback
is called to free the container device (amdgpu_device),
which embeds the DRM dev.
Signed-off-by: Luben Tuikov
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd
atch (and the resulting confusion
with outdated docs) is held up another round.
Cheers, Daniel
Daniel Vetter (3):
drm/i915/selftest: Create mock_destroy_device
drm/i915/selftests: align more to real device lifetimes
drm/dev: Remove drm_dev_init
Luben Tuikov (1):
drm/amdgpu: Convert to u
On Wed, Sep 16, 2020 at 11:27:27AM -0400, Kazlauskas, Nicholas wrote:
> On 2020-09-16 5:12 a.m., Daniel Vetter wrote:
> > On Fri, Sep 11, 2020 at 10:59:23AM -0400, Rodrigo Siqueira wrote:
> > > Debug issues related to display can be a challenge due to the complexity
> >
401 - 500 of 1318 matches
Mail list logo
