Graphics memory management in ARM/Embedded Linux

[Jerome Glisse]

On Thu, Apr 21, 2011 at 6:11 AM, Tom Cooksey <tomcooksey at gmail.com> wrote:
>
> On Wed, Apr 20, 2011 at 9:12 PM, Matt Turner <mattst88 at gmail.com> wrote:
>>
>> 2011/4/20 Tom Cooksey <tomcooksey at gmail.com>:
>> > So while I agree re-inventing something just for the sake of it is bad,
>> > that's not what's happening.
>>
>> > In fact, I think there's a good chance TTM will
>> > be ripped out, stuck into its own driver (with its own device node
>> > /dev/ttm)
>> > and extended to meet everyone's requirements.
>>
>> I'm having a hard time understanding how these two seemingly
>> contradictory sentences fit one after another. Are you saying that
>> this new project will be modifying TTM and sticking it in its own
>> driver with its own device node?
>>
>
> If this is something you're interested in, why not pop onto the mailing list
> and join the discussion? Take a look at the patches being proposed and give
> feedback. It sounds like you have understanding of TTM which people in that
> community might not have. Go help them out.
>
> Also, I've briefly described my thoughts of what they could do, but you're
> getting 3rd-hand information from someone who's no idea how TTM or even GEM
> works and has no idea what the community's goals are. I'm probably wrong
> (very likely in fact), go find out for yourself! :-)
>
>
>
> Cheers,
>
> Tom
>

I spend lot of time fixing ttm, and ttm is not a good solution, it's
design is too complex, there is too much race thus i wouldn't advice
any one using it. My believe is that a memory manager should be a lot
simpler somethings like drm_mm with couple more stuff and that's it.
Not the complex piece of ever moving memory and ever validating and
ever lock intertwining ttm is (we are getting report of ttm bugs and
some of them looks like deep race happening once every cycle of the
moons ...).

Cheers,
Jerome