Graphics memory management in ARM/Embedded Linux
jesse.barker at linaro.org
Wed Apr 20 14:18:11 PDT 2011
On Wed, Apr 20, 2011 at 1: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?
The overall goal is to identify a set of requirements based upon the
use cases encountered by the (admittedly primarily ARM-based) embedded
space - typically involving video, DPSs and graphics - define API,
configuration, mapping and allocation behaviors and come up with a
matching solution. No one wants to reinvent the wheel unless it's
absolutely necessary (and it typically isn't), but SoC vendors and
software partners are encountering problems that they haven't been
able to solve with the current upstream mechanisms. Initially, we're
primarily concerned with making sure we're asking the right questions
and identifying the right people to ask and answer them. Everything
will be done publicly and in the mainline. No forking, no revolution,
just problem solving. If it turns out that someone else has beaten us
to it, that's great.
More information about the wayland-devel