* H. Nikolaus Schaller hns@goldelico.com [190212 20:00]:
Am 11.02.2019 um 16:18 schrieb Tony Lindgren tony@atomide.com: And just to add some notes I've already mentioned before, there's nothing stopping us from having a generic mainline kernel module for slow 2d acceleration based on what we already have for sgx540 in drivers/gpu/drm/gma500/psb_drv.c.
If anybody is interested in that, grep for PSB_RSGX32 and PSB_WSGX32 in the mainline kernel tree. That way at least the generic parts for regulators, clocking, and interrupt handling could be upstreamed. I think only the SoC specific wrapper hardware is different, the SGX code should be generic.
Interesting. But to me it seems to be completely orthogonal to the SGX DDK. And since it is an Intel GMA, there is probably much different clock and register integration into an Intel processor than for OMAP or other SoC.
To me it seems just the wrapper IP is different. If you look at drivers/gpu/drm/gma500/accel_2d.c it seems to be only accessing the sgx registers based on a quick glance. So it's already quite generic.
Also there's the rule of thumb requirement Tomi mentioned earlier. That is the driver must provide actual hardware acceleration and not just a way of enabling out-of-tree binary blobs if I recall.
So from that point of view a generic sgx 2d acceleration driver to drivers/gpu is probably a better place to start upstreaming rather than try to stuff vendor specific hacks on top of imagination hacks into drivers staging :)
Sure it won't help with the 3d parts except we then have the clocks and interrupts etc handled in a generic way. And then the 3d parts in theory should become generic too and with much less of a diffstat..
Regards,
Tony