Hi,
Am 18.02.2019 um 10:29 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
I have pushed these four branches:
letux/latest-pvr ddk1.14.3699939 from TI/IMG moved to drivers/staging/pvr rebased on v5.0-rc7
letux/omap-pvr-soc-glue my patch set for omap3/am335x infrastructure (clocks, resets, hwmods, DT nodes) rebased on v5.0-rc7
letux/omap-pvr ddk1.9/10 from TI moved to drivers/staging/pvr adjusted to compile in-kernel and work together with omap-pvr-soc-glue
letux/omap-pvr-demo some demo scripts
My plan is to git mirror those as our Letux kernel work is going on.
Generally I see it as a reservoir of ideas and patches that can be cherry-picked into our new master branch.
For example, if we agree to start work on ddk1.14.3699939 we can merge this into master.
I have cross-ported and generalised the in-kernel-makefile magic (to produce multiple kernel modules from single tree) into the /latest-pvr tree. And I have cross-ported the kernel API fixes for ~v4.10..v5.0 (TI did alreadymigrate to v4.9).
Now it compiles for all the omap variants (omap3,4,5). Sunxi is missing some asm header file and jz4780 is missing some uaccess_kernel() function in an asm header. Should not be too difficult to find replacements or API changes. Compile for Intel is not tested.
I have not done significant functional tests or debugging, just compile tests. But I already get this (on omap3!):
root@letux:~# modprobe -c | fgrep pvr alias of:N*T*Cti,omap_am335x_sgx530_125 pvr_omap_am335x_sgx530_125 alias of:N*T*Cti,omap_am335x_sgx530_125C* pvr_omap_am335x_sgx530_125 alias of:N*T*Cti,omap_am43xx_sgx544_112 pvr_omap_am43xx_sgx544_112 alias of:N*T*Cti,omap_am43xx_sgx544_112C* pvr_omap_am43xx_sgx544_112 alias of:N*T*Cti,omap_am57xx_sgx544_116 pvr_omap_am57xx_sgx544_116 alias of:N*T*Cti,omap_am57xx_sgx544_116C* pvr_omap_am57xx_sgx544_116 alias of:N*T*Cti,omap_omap3630_sgx530_125 pvr_omap_omap3630_sgx530_125 alias of:N*T*Cti,omap_omap3630_sgx530_125C* pvr_omap_omap3630_sgx530_125 alias of:N*T*Cti,omap_omap3_sgx530_121 pvr_omap_omap3_sgx530_121 alias of:N*T*Cti,omap_omap3_sgx530_121C* pvr_omap_omap3_sgx530_121 alias of:N*T*Cti,omap_omap4430_sgx540_120 pvr_omap_omap4430_sgx540_120 alias of:N*T*Cti,omap_omap4430_sgx540_120C* pvr_omap_omap4430_sgx540_120 alias of:N*T*Cti,omap_omap4460_sgx540_120 pvr_omap_omap4460_sgx540_120 alias of:N*T*Cti,omap_omap4460_sgx540_120C* pvr_omap_omap4460_sgx540_120 alias of:N*T*Cti,omap_omap4470_sgx544_112 pvr_omap_omap4470_sgx544_112 alias of:N*T*Cti,omap_omap4470_sgx544_112C* pvr_omap_omap4470_sgx544_112 alias of:N*T*Cti,omap_omap5_sgx544_116 pvr_omap_omap5_sgx544_116 alias of:N*T*Cti,omap_omap5_sgx544_116C* pvr_omap_omap5_sgx544_116 alias symbol:PVRGetBufferClassJTable pvr_omap_omap5_sgx544_116 alias symbol:PVRGetDisplayClassJTable pvr_omap_omap5_sgx544_116 root@letux:~# modprobe pvr_omap_omap3630_sgx530_125 [14375.354827] pvr_omap_omap3630_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned.
^^^ should be done by a proper compatible = "ti,omap_omap3630_sgx530_125" in the DT
root@letux:~# ls -l /proc/pvr total 0 -r--r--r-- 1 root root 0 Feb 24 17:39 nodes -r--r--r-- 1 root root 0 Feb 24 17:39 queue -r--r--r-- 1 root root 0 Feb 24 17:39 version rroot@letux:~# cat /proc/pvr/version Version SGX_DDK sgxddk MAIN@3699939 (release) omap_sgx System Version String: None root@letux:~# pvrsrvctl --start --no-module pvrsrvctl: SrvInit failed (already initialized?) (err=4) root@letux:~#
So it doesn't look completely broken. At least it does not trigger kernel panics or warnings for missing clocks or reset controllers.
For trying this tree, please check out (you may have to merge in the branch letux/omap-pvr-soc-glue)
https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/latest...
BTW: there was a slightly newer 1.14.3759903 tree (we have 1.14.3699939) at https://elinux.org/CI20-SGX_kernel_module but the files are no longer accessible. And there were links to user-space binaries for the jz4780. Maybe we can find a copy and someone with jz4780 hardware willing to contribute here.
Regarding the mailing list, how do we proceed?
I think this is very important since it seems as recipients have been lost in some replies.
So far I see these options:
a) use linux-omap@vger.kernel.org b) try again to get a dedicated list at vger.kernel.org c) use a different host c1) use the letux-kernel@openphoenux.org c2) I can create a new list at openphoenux.org c3) different proposal
What are your preferences or suggestions?
BR, Nikolaus