On Wed, Aug 14, 2019 at 8:16 AM Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > * H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [190814 10:34]: > > > > > Am 14.08.2019 um 11:47 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: > > > > > > * H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [190814 08:57]: > > >> I also have pushed good news to > > >> > > >> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr > > >> > > >> Thanks to the help from the Pyra community, I was able to get a (binary) reference > > >> implementation using DRM that works on Pyra/OMAP5. At least the gles1test1. > > >> > > >> With that reference setup I was able to fix my Makefiles for the staging/pvr implementation. > > >> > > >> I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the LetuxOS kernel tree) > > >> on the Pyra. > > >> > > >> In which areas does this tree go beyond the TI SDK/IMG DDK 1.14? > > >> > > >> * includes internal API fixes for kernels up to v5.3 > > >> * lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for inclusion in linux-next > > >> * has Kconfig and Makefiles for in-kernel configuration (no separate build system) > > >> * builds separate kernel modules for omap3430, omap3630, am335x, omap4, omap5, dra7 etc. > > >> pvrsrvkm > > >> e.g. pvrsrvkm_omap_omap5_sgx544_116 > > >> * the correct kernel module is automatically probed by matching .compatible in device tree > > >> so that the code is multi-platform friendly > > >> * includes SoC integration for OMAP3/4/5 and has some preliminary bindings documentation > > >> * code base should also support JZ4780/CI20 and some Intel Atom processors (CedarView, Poulsbo) > > >> * has got a ToDo to describe what should be done during staging phase > > >> > > >> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pvr/drivers/staging/pvr/TODO > > >> > > >> My plans for the next steps are: > > >> > > >> * do more testing (e.g. X11, kmscube) > > >> * check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, OpenPandora) > > >> * try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline kernels and I am > > >> missing the user-space libraries for MIPS). > > > > > > That sounds good to me, just one comment. Before getting these into > > > staging, I'd like to have omap variants use proper interconnect > > > target module in devicetree like we already have in omap4.dtsi > > > as target-module@56000000. This should simplify things further > > > as the module child device driver(s) can just enable things with > > > runtime PM and we can leave out all the legacy hwmod platform data > > > that sounds like you're still carrying. > > > > Yes, there is still a lot of SoC-glue included: > > > > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-pvr-soc-glue > > > > It would indeed be a good move to simplify and reduce the glue code > > and make it more maintainable / stable / identical on different platforms. > > OK yeah all that should just disappear :) > > > > I have patches here to add similar interconnect target modules for > > > at least omap34xx, omap36xx, omap5, and am335x that I'll try to post > > > later on today to play with. For am335x, things still depend on the > > > recentely posted prm rstctrl patches. I'm not sure if I already > > > did a dts patch for dra7 yet, need to check. > > > > I assume it is not yet in linux-next... So something for v5.5 or later. > > Well I just posted some sgx interconnect target module patches. We might > still have them in v5.4 assuming people manage to review and test them. Nikolaus, I tested Tony's change and I can confirm that I can read the value when enabled. Should I apply his patches to your branch before I test, or is it go too to go as-is? I've got an AM3517, OMAP35 and a DM3730. I am not sure if the AM3517 is even on the radar, but it has an sgx530 as well. adam > > Regards, > > Tony
