Message ID | 1439694148-35783-1-git-send-email-michel.thierry@intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Sun, Aug 16, 2015 at 04:02:28AM +0100, Michel Thierry wrote: > The adj_start calculation for DRM_MM_CREATE_TOP should happen after > mm->color_adjust. There was an inconsistency between > drm_mm_insert_helper_range > and drm_mm_insert_helper, as the later was already updating after > color_adjust. > > Didn't spot it before, as color_adjust is only done in systems without > LLC. But I'm not aware of anybody using this test case yet. > > Signed-off-by: Michel Thierry <michel.thierry@intel.com> I sent this patch a few years ago, when I was using a top-down allocator before llc and I have a similar patch in my tree which I kept meaning to polish up and warn you about before PIN_HIGH. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> -Chris
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Task id: 7208
-------------------------------------Summary-------------------------------------
Platform Delta drm-intel-nightly Series Applied
ILK -1 302/302 301/302
SNB 315/315 315/315
IVB 336/336 336/336
BYT -1 283/283 282/283
HSW 378/378 378/378
-------------------------------------Detailed-------------------------------------
Platform Test drm-intel-nightly Series Applied
*ILK igt@kms_flip@rcs-wf_vblank-vs-dpms-interruptible PASS(1) DMESG_WARN(1)
*BYT igt@gem_partial_pwrite_pread@reads-uncached PASS(1) FAIL(1)
Note: You need to pay more attention to line start with '*'
On Sun, Aug 16, 2015 at 08:52:54AM +0100, Chris Wilson wrote: > On Sun, Aug 16, 2015 at 04:02:28AM +0100, Michel Thierry wrote: > > The adj_start calculation for DRM_MM_CREATE_TOP should happen after > > mm->color_adjust. There was an inconsistency between > > drm_mm_insert_helper_range > > and drm_mm_insert_helper, as the later was already updating after > > color_adjust. > > > > Didn't spot it before, as color_adjust is only done in systems without > > LLC. But I'm not aware of anybody using this test case yet. > > > > Signed-off-by: Michel Thierry <michel.thierry@intel.com> > > I sent this patch a few years ago, when I was using a top-down > allocator before llc and I have a similar patch in my tree which I kept > meaning to polish up and warn you about before PIN_HIGH. > > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Applied to drm-misc, thanks. -Daniel
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index 3427b11..04de6fd 100644 --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -267,12 +267,12 @@ static void drm_mm_insert_helper_range(struct drm_mm_node *hole_node, if (adj_end > end) adj_end = end; - if (flags & DRM_MM_CREATE_TOP) - adj_start = adj_end - size; - if (mm->color_adjust) mm->color_adjust(hole_node, color, &adj_start, &adj_end); + if (flags & DRM_MM_CREATE_TOP) + adj_start = adj_end - size; + if (alignment) { u64 tmp = adj_start; unsigned rem;
The adj_start calculation for DRM_MM_CREATE_TOP should happen after mm->color_adjust. There was an inconsistency between drm_mm_insert_helper_range and drm_mm_insert_helper, as the later was already updating after color_adjust. Didn't spot it before, as color_adjust is only done in systems without LLC. But I'm not aware of anybody using this test case yet. Signed-off-by: Michel Thierry <michel.thierry@intel.com> --- drivers/gpu/drm/drm_mm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)