> Am 12.02.2019 um 23:24 schrieb Philipp Rossak <embed3d@xxxxxxxxx>: > > Hey all, > > On 12.02.19 21:51, Tony Lindgren wrote: >> Hi, >> * H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [190212 20:03]: >>>> Am 11.02.2019 um 07:51 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>: >>>> What would be the process to get something into staging? Who decides about >>>> staging generally? Should we just forward this discussion to Greg for comment? >>> >>> One thing already got my attention: we need to prefix all commit messages with e.g. >>> "staging: pvr: " so that they can be distinguished on LKML. I'll prepare that >>> for the next version of our Letux tree. >> After thinking about this a bit, I think a shared out-of-tree >> repo is the best place to start rather than try to stuff a >> pile of sgx and vendor specific hacks into staging. Currently >> we don't even know what all needs to be different for various >> SoCs for example. >> And for upstream merging, a minimal generic accelerated 2d >> sgx driver that works across several SoCs is probably the >> best place to start. This would make the clock and interrupt >> handling generic with just SoC specific glue layer. >> Regards, >> Tony > Thanks for adding me to that thread! Welcome! > > I'm looking now into that PVR SGX driver since a while. I already reworked that old "opensource" driver to work with a quite new kernel (4.16 or 4.17) [But that code got lost]. > For the sunxi devices this was only a short coding session to get that running. For OMAP this might be easier/faster since the general linux situation is better. > > I'm not sure if we are able to provide a generic driver since there are different userspace versions that are only compatible with their own kernel driver. Not all compile flags for the kernel driver work with all userspace lib versions, at least on sunxi. Be aware that there are also different versions of those GPU ip cores and all have different features and bug fixes. Regarding that the DDK contains a lot of compile switches (#if for all bug fixes/errata). And different SoC and version glue are handled by code in different eurasia_km / services4 / system subdirectories. > > If you reach a good state with that driver, I can try to port that to sunxi. Is there any good/cheap OMAP4/5 Devboard you can recommend? > > Don't expect any support from TI or IMG. TI can't support a project like this, since they don't own the code and IMG is not willing to support. > > An other big issue is the leaked SGX source code [1]. So I think it would be better to start a clean room reverse engineering project. I'm already working on that. Yes, I remember that, but since it covers the user-space libs and firmware, we don't have to care about that for the kernel driver project. Aiming at a clean room implementation would be very useful of course. BR, Nikolaus > > > Regards, > > Philipp > > [1]: https://libv.livejournal.com/26972.html
