On 2024-05-07 07:58, Thomas Zimmermann wrote:
Implement struct drm_client_funcs with the respective helpers and
remove the custom code from the emulation. The generic helpers are
equivalent in functionality.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/radeon/radeon_fbdev.c | 66
Am 2022-12-10 um 09:12 schrieb Christian König:
Am 10.12.22 um 07:15 schrieb Felix Kuehling:
On 2022-11-25 05:21, Christian König wrote:
We already fallback to a dummy BO with no backing store when we
allocate GDS,GWS and OA resources and to GTT when we allocate VRAM.
Drop all those
On 2022-11-25 05:21, Christian König wrote:
We already fallback to a dummy BO with no backing store when we
allocate GDS,GWS and OA resources and to GTT when we allocate VRAM.
Drop all those workarounds and generalize this for GTT as well. This
fixes ENOMEM issues with runaway applications
is
not about freeing ttm_resources but about freeing the BOs. But it
affects freeing of ghost_objs that are holding the ttm_resources being
freed.
If those assumptions all make sense, patches 1-3 are
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers
Am 2021-10-19 um 7:36 a.m. schrieb Christian König:
> Am 13.10.21 um 16:07 schrieb Daniel Vetter:
>> On Tue, Oct 05, 2021 at 01:37:26PM +0200, Christian König wrote:
>>> Simplifying the code a bit.
>>>
>>> Signed-off-by: Christian König
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14
changes yet.
Is there another DRM branch or repository that you're referring to with
drm-tip?
Regards,
Felix
>
> Regards,
> Christian.
>
> Am 08.06.21 um 07:37 schrieb Felix Kuehling:
>> Hi Christian,
>>
>> I based amdgpu_preempt_mgr on amdgpu_gtt_mgr and now I'm looking a
Hi Christian,
I based amdgpu_preempt_mgr on amdgpu_gtt_mgr and now I'm looking at what
changed there. Looks like I'll need to create a dummy node in
amdgpu_preempt_mgr_new to satisfy TTM, and free it in
amdgpu_preempt_mgr_del.
Thanks,
Felix
Am 2021-06-07 um 10:50 p.m. schrieb Stephen
Am 2020-06-23 um 3:39 a.m. schrieb Daniel Vetter:
> On Fri, Jun 12, 2020 at 1:35 AM Felix Kuehling wrote:
>> Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe:
>>> On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote:
>>>>> I still have my doubts
Am 2020-06-19 um 3:55 p.m. schrieb Jason Gunthorpe:
> On Fri, Jun 19, 2020 at 03:48:49PM -0400, Felix Kuehling wrote:
>> Am 2020-06-19 um 2:18 p.m. schrieb Jason Gunthorpe:
>>> On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
>>>> On Fri, Jun 19, 2
Am 2020-06-19 um 2:18 p.m. schrieb Jason Gunthorpe:
> On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
>> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
>>> On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
>>>
The madness is only that device B's
Am 2020-06-19 um 3:11 p.m. schrieb Alex Deucher:
> On Fri, Jun 19, 2020 at 2:09 PM Jerome Glisse wrote:
>> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
>>> On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
>>>
The madness is only that device B's mmu notifier
Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe:
> On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote:
>>> I still have my doubts about allowing fence waiting from within shrinkers.
>>> IMO ideally they should use a trywait approach, in order to allow memory
>>> allocation during
t sweeps over its pfns array a couple of times anyhow.
>
> Signed-off-by: Jason Gunthorpe
> Signed-off-by: Christoph Hellwig
Hi Jason,
I pointed out a typo in the documentation inline. Other than that, the
series is
Acked-by: Felix Kuehling
I'll try to build it and run so
functions a kthread_ prefix to better document the
> use case.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 4 +--
> drivers/gpu/drm/i915/gvt/kvmgt.c | 4 +--
> drivers/usb/gadget/funct
ise contains very low-level MM bits.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Felix Kuehling
Thanks for cleaning up the unnecessary includes in amdgpu.
Regards,
Felix
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 1 +
> .../drm/amd/amdgpu/amdgpu_amdkfd_arc
Am 2020-04-04 um 5:40 a.m. schrieb Christoph Hellwig:
> Use the proper API instead.
>
> Fixes: 70539bd795002 ("drm/amd: Update MEC HQD loading code for KFD")
> Signed-off-by: Christoph Hellwig
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdg
Ok?
>>
>> Note that the lifetime rules are very important, because obviously
>> use_mm() itself is never called in the context of the process that has
>> the mm. By definition, we're in a kernel thread and it uses somebody
>> elses mm. So it's important to show that that "
On 2018-06-22 11:24 AM, Michal Hocko wrote:
> On Fri 22-06-18 17:13:02, Christian König wrote:
>> Hi Michal,
>>
>> [Adding Felix as well]
>>
>> Well first of all you have a misconception why at least the AMD graphics
>> driver need to be able to sleep in an MMU notifier: We need to sleep because
On 2018-04-18 05:24 AM, Alexey Brodkin wrote:
> After commit ad67b74 ("printk: hash addresses printed with %p")
> pointers are being hashed when printed. However, this makes
> debug output completely useless. Switch to %px in order to see the
> unadorned kernel pointers.
My understanding of the
On 2017-08-31 03:00 PM, Jerome Glisse wrote:
> I was not saying you should not use mmu_notifier. For achieving B you need
> mmu_notifier. Note that if you do like ODP/KVM then you do not need to
> pin page.
I would like that. I've thought about it before. The one problem I
couldn't figure out is,
On 2017-08-31 09:59 AM, Jerome Glisse wrote:
> [Adding Intel folks as they might be interested in this discussion]
>
> On Wed, Aug 30, 2017 at 05:51:52PM -0400, Felix Kuehling wrote:
>> Hi Jérôme,
>>
>> I have some questions about the potential range-start-end race you
21 matches
Mail list logo
