similar to: [PATCH] drm: Print unadorned pointers

A new hsakmt release 1.0.0 is now available. This is the first official release of hsakmt with the new numbering system and generated from the new git repository at cgit.freedesktop.org/amd/hsakmt This release works with upstream amdkfd from kernel version 3.19 and above, although not all features are supported by all kernel versions. With regard to H/W, it supports AMD's Kaveri and

These duplicate includes have been found with scripts/checkincludes.pl but they have been removed manually to avoid removing false positives. Signed-off-by: Pravin Shedge <pravin.shedge4linux at gmail.com> --- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 1 - drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 1 - drivers/gpu/drm/amd/amdgpu/vce_v3_0.c

A new pixman release 0.32.8 is now available. This is a stable release that contains an important bug fix (buffer overflow), which can affect 32-bit systems. I recommend to all the distributions that still use the 0.32.x version to upgrade to this release as soon as possible. For those distributions that already moved to the new 0.33.2 version, I will release in the coming weeks a new

A new pixman development release 0.33.6 is now available. This is the final release candidate leading up to the 0.34 stable release. The stable release is expected to be announced at the end of January 2016. >From this point forward, only bug fixes can be accepted to the 0.34 release. This release contains two minor fixes over the previous release (0.33.4): - Fix detection of

A new pixman release 0.33.4 is now available. This is a release candidate leading up to a stable release (0.34.0). The stable release is expected to be made around January 2016. The main changes are (see the git log below for full list of commits): - Important security fix to prevent stack buffer overflow - POWER: New fast-paths and optimizations to existing fast-paths - ARMv6: New fast-path

A new pixman release 0.33.2 is now available. This is a release candidate for a stable 0.34.0 release. This release comes after little more than 1 year since the previous release (0.32.6). Therefore, the git log is quite long and there are multiple changes, fixes and enhancements. The main changes are: - ARMv6 - Many fast paths implementations were added - PPC64/PPC64LE - Fix all outstanding

A new pixman release 0.34.0 is now available. This is a major release, following three development releases in the past six months. It contains all the changes detailed in the last three development releases in the 0.33 series. Please note that this release doesn't contain any changes since the previous development version (0.33.6) was released. For those who didn't follow the

On Mon, Nov 12, 2018 at 04:01:14PM +0100, Maarten Lankhorst wrote: > We already have __drm_atomic_helper_connector_reset() and > __drm_atomic_helper_plane_reset(), extend this to crtc as well. > > Most drivers already have a gpu reset hook, correct it. > Nouveau already implemented its own __drm_atomic_helper_crtc_reset(), > convert it to the common one. > >

Den 22.03.2018 16.22, skrev Ville Syrjala: > From: Ville Syrj?l? <ville.syrjala at linux.intel.com> > > I really just wanted to fix i915 to re-enable its planes afer load > detection (a two line patch). This is what I actually ended up with > after I ran into a framebuffer refcount leak with said two line patch. > > I've tested this on a few i915 boxes and so far

Hi Oded, sorry for the late response, somehow this mail slipped through. On 2/6/23 15:48, Oded Gabbay wrote: > On Thu, Jan 19, 2023 at 7:24 AM Matthew Brost <matthew.brost at intel.com> wrote: >> Is this not an application issue? Millions of mappings seems a bit >> absurd to me. > If I look at the most extreme case for AI, assuming 256GB of HBM > memory and page

The NULL initialization of the pointers assigned by kzalloc() first is not necessary, because if the kzalloc() failed, the pointers will be assigned NULL, otherwise it works as usual. so remove it. Signed-off-by: Ruan Jinjie <ruanjinjie at huawei.com> --- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

The NULL initialization of the pointers assigned by kzalloc() first is not necessary, because if the kzalloc() failed, the pointers will be assigned NULL, otherwise it works as usual. so remove it. Signed-off-by: Ruan Jinjie <ruanjinjie at huawei.com> --- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

The NULL initialization of the pointers assigned by kzalloc() first is not necessary, because if the kzalloc() failed, the pointers will be assigned NULL, otherwise it works as usual. so remove it. Signed-off-by: Ruan Jinjie <ruanjinjie at huawei.com> --- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Am 09.08.23 um 05:44 schrieb Ruan Jinjie: > The NULL initialization of the pointers assigned by kzalloc() first is > not necessary, because if the kzalloc() failed, the pointers will be > assigned NULL, otherwise it works as usual. so remove it. > > Signed-off-by: Ruan Jinjie <ruanjinjie at huawei.com> Reviewed-by: Christian K?nig <christian.koenig at amd.com> for this

Am 09.08.23 um 05:44 schrieb Ruan Jinjie: > The NULL initialization of the pointers assigned by kzalloc() first is > not necessary, because if the kzalloc() failed, the pointers will be > assigned NULL, otherwise it works as usual. so remove it. > > Signed-off-by: Ruan Jinjie <ruanjinjie at huawei.com> Reviewed-by: Christian K?nig <christian.koenig at amd.com> for this

Am 09.08.23 um 05:44 schrieb Ruan Jinjie: > The NULL initialization of the pointers assigned by kzalloc() first is > not necessary, because if the kzalloc() failed, the pointers will be > assigned NULL, otherwise it works as usual. so remove it. > > Signed-off-by: Ruan Jinjie <ruanjinjie at huawei.com> Reviewed-by: Christian K?nig <christian.koenig at amd.com> for this

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> I really just wanted to fix i915 to re-enable its planes afer load detection (a two line patch). This is what I actually ended up with after I ran into a framebuffer refcount leak with said two line patch. I've tested this on a few i915 boxes and so far it's looking good. Everything else is just compile tested. Entire series

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> I really just wanted to fix i915 to re-enable its planes afer load detection (a two line patch). This is what I actually ended up with after I ran into a framebuffer refcount leak with said two line patch. I've tested this on a few i915 boxes and so far it's looking good. Everything else is just compile tested. Entire series

Hi Jason, I did quick test after merging amd-staging-drm-next with the mmu_notifier branch, which includes this set changes. The test result has different failures, app stuck intermittently, GUI no display etc. I am understanding the changes and will try to figure out the cause. Regards, Philip On 2019-10-28 4:10 p.m., Jason Gunthorpe wrote: > From: Jason Gunthorpe <jgg at

We already have __drm_atomic_helper_connector_reset() and __drm_atomic_helper_plane_reset(), extend this to crtc as well. Most drivers already have a gpu reset hook, correct it. Nouveau already implemented its own __drm_atomic_helper_crtc_reset(), convert it to the common one. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> Cc: Harry Wentland <harry.wentland at