From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Widawsky Subject: Re: [PATCH] drm/mm: Don't WARN if drm_mm_reserve_node Date: Tue, 8 Apr 2014 10:21:44 -0700 Message-ID: <20140408172144.GB21168@intel.com> References: <1396905920-30049-1-git-send-email-daniel.vetter@ffwll.ch> <20140407221313.3c65dd3a@jbarnes-t420> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20140407221313.3c65dd3a@jbarnes-t420> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Jesse Barnes Cc: Daniel Vetter , Intel Graphics Development , DRI Development , Dave Airlie List-Id: intel-gfx@lists.freedesktop.org On Mon, Apr 07, 2014 at 10:13:13PM -0700, Jesse Barnes wrote: > On Mon, 7 Apr 2014 23:25:20 +0200 > Daniel Vetter wrote: > > > Jesse's BIOS fb reconstruction code actually relies on the -ENOSPC > > return value to detect overlapping framebuffers (which the bios uses > > always when lighting up more than one screen). All this fanciness > > happens in intel_alloc_plane_obj in intel_display.c. > > > > Since no one else uses this we can savely remove the WARN without > > repercursions. > > > > Reported-by: Ben Widawsky > > Cc: Ben Widawsky > > Cc: Jesse Barnes > > Cc: Dave Airlie > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/drm_mm.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c > > index a2d45b748f86..e4dfd5c3b15e 100644 > > --- a/drivers/gpu/drm/drm_mm.c > > +++ b/drivers/gpu/drm/drm_mm.c > > @@ -192,8 +192,6 @@ int drm_mm_reserve_node(struct drm_mm *mm, struct drm_mm_node *node) > > return 0; > > } > > > > - WARN(1, "no hole found for node 0x%lx + 0x%lx\n", > > - node->start, node->size); > > return -ENOSPC; > > } > > EXPORT_SYMBOL(drm_mm_reserve_node); > > Yeah thanks, pushing this has been on my list for weeks now... I am not convinced this is the correct solution. At least the way we used this interface, it isn't meant to ever fail. I also didn't look into exactly why we depend an ENOSPC return. That sounds fragile to me, especially for a public interface. Obviously it makes the WARN go away, and we have only one other user of the interface, so it's correct. So if both of you are happy, I won't stand in the way. -- Ben Widawsky, Intel Open Source Technology Center