On Wed, Mar 19, 2014 at 05:42:27PM +0900, Michel Dänzer wrote:
On Die, 2014-03-18 at 11:01 +0100, Daniel Vetter wrote:
On Tue, Mar 18, 2014 at 09:58:14AM +0900, Michel Dänzer wrote:
From: Michel Dänzer michel.daenzer@amd.com
entry->size is the size of the node, not the size of the hole after it. So the code would actually find the hole which can satisfy the constraints and which is preceded by the smallest node, not the smallest hole satisfying the constraints.
Reported-by: "Huang, FrankR" FrankR.Huang@amd.com Signed-off-by: Michel Dänzer michel.daenzer@amd.com
But drm-next just gained my kerneldoc patch for drm_mm, so can you please respin your patch and update the docs too?
What kind of update are you thinking of?
you've changed the function parameters, which breaks the kerneldoc. v2 is ok in that regard.
While at it ... could you perhaps smash a bit of kerneldoc on top of enum drm_mm_search_flags, I seem to have missed it. With that this is
Reviewed-by: Daniel Vetter daniel.vetter@ffwll.ch
Thanks, but I'm afraid I'll have to pass on that. I'm just submitting a fix for a problem Frank stumbled upon. I don't have the time right now, nor the particular inclination to clean up the surrounding code.
I've made a note to add the missing kerneldoc, still some patches left over.
Meanwhile, I've submitted a less invasive v2 fix.
Reviewed-by: Daniel Vetter daniel.vetter@ffwll.ch on that one.
BTW, do you think the fix would interact properly with coloring?
Coloring only adjusts start/end so won't affect the size of the hole. If you really see benefits from best_match then I guess you could look into pessimising holes which need to be split, presuming radeon has a pile of alignment or otherwise constrained buffers.
Cheers, Daniel