Re: [PATCH 14/15] gma500: nuke the PSB debug stuff

[Daniel Vetter]

On Mon, Jun 13, 2011 at 04:44:03PM +0100, Alan Cox wrote:
> > Given that I've mucked around in drm_mm quite a bit I'd be very interested
> > in your opinion about what's weird in it (and presumably what could be
> > improved). Can you elaborate?
> 
> Mostly the API, which is also somewhat poorly documented. I've not dug
> into the internals beyond trying to figure out how to use it. Looking at
> the users the API is non-obvious, the interface involves a mix of calls
> and digging deep into struct internals.

Well, I've rewritten the api but that transition is not yet complete, i.e.
the new interface is there, but no driver is converted yet. The old api
has a two-step allocation (search_free + get_block) and frees allocated
ranges with put_block. The new api has just insert_node and remove_node,
struct drm_mm_node must be allocated by the caller (to get rid of the racy
preallocation scheme and allow embedding of drm_mm_node).

There's also the lru scanning helpers (only used by intel). Under specific
conditions (should be all documented in comments) this can be used as an
eviction roaster.

Generally only node->start should be used by drivers, otherwise
drm_mm_node should be opaque. At least that's the idea.

btw, old conversion patches for i915 to the new interface are at:

http://cgit.freedesktop.org/~danvet/drm/log/?h=embed-gtt-space

When creating the new interfaces I've tried to document them. Ideas to
improve that highly welcome.

> I'd have expected an API that had allocate/free type methods and exposed
> the needed information directly or very easily not one that has drivers
> doing. drm_sman seems to be attempt in that direction but its also rather
> odd with interfaces like

Should be fixed, see above ;-)

[snip]

> Possibly drm_sman and friends should just wrap whatever simple native
> allocator exists on the OS ?

Well, drm_mm has some graphics specific magic (range restricted scans and
the eviction helpers). But simpler stuff like sman is imo just "drm likes
to reinvent the wheel". Unfortunately I don't have the hw, so I haven't
dared to touch it (the snippet you've posted is a prime example why).

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel@xxxxxxxx
Mobile: +41 (0)79 365 57 48
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/