Re: [PATCH] omap3-sgx-modules, libgles-omap3: add version 4.06.00.01

[Denys Dmytriyenko <denis@denix.org>]

On Thu, May 03, 2012 at 07:17:32PM +0200, Koen Kooi wrote:
> 
> Op 3 mei 2012, om 19:05 heeft Denys Dmytriyenko het volgende geschreven:
> 
> > On Thu, May 03, 2012 at 07:05:13PM +0200, Koen Kooi wrote:
> >> 
> >> 
> >> Op 3 mei 2012 om 19:02 heeft Denys Dmytriyenko <denis@denix.org> het volgende geschreven:
> >> 
> >>> On Thu, May 03, 2012 at 09:26:51AM +0200, Koen Kooi wrote:
> >>>> 
> >>>> Op 3 mei 2012, om 08:33 heeft Denys Dmytriyenko het volgende geschreven:
> >>>> 
> >>>>> From: Denys Dmytriyenko <denys@ti.com>
> >>>>> 
> >>>>> * Ported from Arago
> >>>>> * Added version 4.06.00.01 of the Graphics SDK which supports Power Management
> >>>>> features for the AM335x
> >>>>> * Use a variable PLATFORM for the directory structure since newer SDKs use
> >>>>> LinuxARMV7 and older SDKs use LinuxOMAP3
> >>>>> * Modifiy rc.pvr to check return of the insmod of pvrsrvkm. If this driver
> >>>>> fails to load the devmem2 read access can put the system in a state where
> >>>>> it will not come out of suspend.
> >>>> 
> >>>> I keep bringing this up every few months: what's the plan to add the 
> >>>> necessary hooks to the kernel module to export the core revision in sysfs 
> >>>> instead of using devmem2? The kernel module knows about the right memory 
> >>>> addressed and turns on the clocks it needs. And better: we can get rid of 
> >>>> bogus ES revisions like 'ES8' since that's exactly the same core as 'ES6' 
> >>>> from a userspace point of view.
> >>> 
> >>> Thanks, I will forward your questions and suggestions to the Graphics team. 
> >>> Meanwhile, do you have any comments about the patch?
> >> 
> >> X11 support needs to get redone completely for this one, dri and all :(
> > 
> > I haven't looked at X11 support - what's wrong with it?
> 
> You need to rebuild the omap3-sgx-modules with DRI support, install the 
> extra modules, etc. Then you need to install the xorg module and hope the 
> ABIs match, install a xorg.conf snippet, etc, etc.
> 
> The best way forward is to have the gfx team rebuild the X stuff against the 
> X we have in OE, not the one IMGtec delivers.

That's a worthy goal, but may be difficult to achieve in a short time. You've 
been on the inside, you know all the limitations...

What's the best alternative for now?

-- 
Denys