linux-kernel - Re: [PATCH] gma500: Intel GMA500 staging driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTimPpr+OugTiPpYxNyS78vqActuURw-tnxJVxi18@mail.gmail.com>
Date:	Thu, 24 Feb 2011 09:51:04 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Alan Cox <alan@...ux.intel.com>
Cc:	greg@...ah.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] gma500: Intel GMA500 staging driver

On Tue, Feb 22, 2011 at 10:17 PM, Alan Cox <alan@...ux.intel.com> wrote:
> This is an initial staging driver for the GMA500. It's been stripped out
> of the PVR drivers and crunched together from various bits of code and
> different kernels.
>
> Currently it's unaccelerated but still pretty snappy even compositing with
> the frame buffer X server.
>
> Lots of work is needed to rework the ttm and bo interfaces from being
> ripped out and then 2D acceleration wants putting back for framebuffer and
> somehow eventually via DRM.
>
> There is no support for the parts without open source userspace (video
> accelerators, 3D) as per kernel policy.
>
> I'm not a DRM expert so if there is anyone with a GMA500 who actually knows
> something about DRI internals then help would be most welcome.
>

Okay I'm okay with this going into staging but we should work out a
plan for it going forward.

I don't have any poulsbo hw but if some were to appear I could
probably expend effort on this.

So where do we want to go my opinion is

a) remove all userspace interfaces and simplify ttm memory management usage.
b) add support to hook this up to the dumb ioctl so we can do trivial
generic front buffer allocation, so then a libkms + dumb kms
modesetting driver can work on it.
c) figure out how to add interface for acceleration users. Whether TTM
fence interfaces are required etc.

We could probably just add a GEM style buffer allocation interface but
we'd probably need to do a lot of RE first to figure out what best
suits the hardware, I'm pretty sure I've haven't heard any glowing
praise that the current interface suits the hw or is maintainable.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/