linux-kernel - Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 14 Aug 2019 12:33:36 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Merlijn Wajer <merlijn@...zup.org>,
        Paweł Chmiel <pawel.mikolaj.chmiel@...il.com>,
        Philipp Rossak <embed3d@...il.com>,
        moaz korena <moaz@...ena.xyz>,
        Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
        Filip Matijević <filip.matijevic.pz@...il.com>,
        Adam Ford <aford173@...il.com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        linux-omap <linux-omap@...r.kernel.org>,
        kernel@...a-handheld.com,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>, maemo-leste@...ts.dyne.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5


> Am 14.08.2019 um 11:47 schrieb Tony Lindgren <tony@...mide.com>:
> 
> * H. Nikolaus Schaller <hns@...delico.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@...00000. 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.

> 
> 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.

BR and thanks,
Nikolaus