lkml.org 
[lkml]   [2019]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
* H. Nikolaus Schaller <hns@goldelico.com> [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.

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.

Regards,

Tony

\
 
 \ /
  Last update: 2019-08-14 11:49    [W:0.040 / U:0.500 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site