From: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Alan Cox <alan@linux.intel.com>,
greg@kroah.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] gma500: Intel GMA500 staging driver
Date: Tue, 22 Feb 2011 23:59:41 +0100 [thread overview]
Message-ID: <4D643FDD.703@gmail.com> (raw)
In-Reply-To: <20110222154002.GB9720@srcf.ucam.org>
On 02/22/2011 04:40 PM, Matthew Garrett wrote:
> On Tue, Feb 22, 2011 at 12:17:46PM +0000, Alan Cox 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.
>> +++ b/drivers/staging/gma500/psb_intel_sdvo.c
> Does PSB really support SDVO? I thought by that period the only thing
> it'd be used for was plug-in SDVO cards, which doesn't seem so likely
> with PSB.
>
The Fit-PC2 needs SDVO for its DVI/HDMI output. The SDVO chip is likely
put directly on the PCB.
I tried to write my own driver for the gma500 (called it i500) which had
all the SDVO stuff in place,
but I never sorted out the TTM stuff so it's been gathering dust for
quite some time now.
>> diff --git a/drivers/staging/gma500/psb_ttm_fence.c b/drivers/staging/gma500/psb_ttm_fence.c
> This really looks like it's intended to be core TTM functionality, so it
> should probably go past dri-devel.
>
> This is definitely the best gma500 driver we've seen yet, but it seems
> like there's two directions it can go. If the intention for now is to
> provide a kernel-quality unaccelerated 2D driver then there's a *lot*
> more code that can just be ripped out. If we want the acceleration to
> work then there's an argument that we should be abstracting that into a
> more generic SGX layer that other drivers can make use of. Does omapfb
> have any acceleration? If so, is there anything we can build on there?
From what I can see, omapfb doesn't have any acceleration,
and yes, it would be very nice to have a generic SGX layer.
Cheers
Patrik Jakobsson
next prev parent reply other threads:[~2011-02-22 22:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-22 12:17 [PATCH] gma500: Intel GMA500 staging driver Alan Cox
2011-02-22 14:44 ` Greg KH
2011-02-22 14:51 ` Alan Cox
2011-02-22 15:40 ` Matthew Garrett
2011-02-22 16:17 ` Alan Cox
2011-02-22 22:59 ` Patrik Jakobsson [this message]
2011-02-22 17:09 ` Arnd Bergmann
2011-02-22 17:43 ` Alan Cox
2011-02-23 23:51 ` Dave Airlie
2011-02-24 0:01 ` Greg KH
2011-02-24 12:10 ` Alan Cox
2011-03-01 3:40 ` Dave Airlie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D643FDD.703@gmail.com \
--to=patrik.r.jakobsson@gmail.com \
--cc=alan@linux.intel.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.