Author: Tony Lindgren Date: To: H. Nikolaus Schaller CC: Merlijn Wajer, Paweł Chmiel, Philipp Rossak, moaz korena, Ivaylo Dimitrov, Filip Matijević, Adam Ford, Tomi Valkeinen, linux-omap, kernel, Discussions about the Letux Kernel, maemo-leste, Linux Kernel Mailing List Subject: Re: [maemo-leste] Lay common foundation to make PVR/SGX work
without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
* H. Nikolaus Schaller <hns@???> [190814 10:34]: >
> > Am 14.08.2019 um 11:47 schrieb Tony Lindgren <tony@???>:
> >
> > * H. Nikolaus Schaller <hns@???> [190814 08:57]:
> >> I also have pushed good news to
> >>
> >>
> >> 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
> >>
> >>
> >> 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:
>
>
> 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.
::
Re: [maemo-leste] Lay common founda…
