[Openpvrsgx-devgroup] Building the 1.7.862890 branch for x86

[H. Nikolaus Schaller]

Hi Julius,

> Am 30.05.2024 um 22:57 schrieb Julius Schwartzenberg <julius.vrijheid at freedom.nl>:
> 
> On 30.05.24 15:25, H. Nikolaus Schaller wrote:
>> So please try letux-6.8-rc4. I have tested and can compile it for x86 with letux_defconfig.
>> MBP1320Nikolaus:master hns$ ls -l ./drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/*.mod
>> -rw-r--r--  1 hns  staff  3805 30 Mai 15:40 ./drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/pvrsrvkm_gma3600_sgx545_10141.mod
>> -rw-r--r--  1 hns  staff  3789 30 Mai 15:41 ./drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/pvrsrvkm_gma500_sgx535_126.mod
>> MBP1320Nikolaus:master hns$
> 
> Ah this seems interesting! I should be able to load up pvrsrvkm_gma3600_sgx545 on my hardware? How should I set CONFIG_DRM_GMA500?

Yes, the driver should load. If it works is a different question...

> 
> 
> 
>> Note that this is not configured for DDK 1.7 and does not contain your initial patches or mine (total of 9 patches) as pushed as work-pvrsrvkm-6.8-rc4-x86-1.7.862890.
>> I plan to integrate this next week and rebase to v6.9-rc2 (which is due for Sunday/Monday).
> 
> Yeah that seems fine. If I can get any version to run that would already be great.

I have now included the 1.7.862890 work so far and rebased to v6.10-rc1 and pushed:

	https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-pvrsrvkm-x86-1.7.862890
	https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/work-pvrsrvkm-x86-1.7.862890

There was a minor change needed in the __vmalloc stuff in 1.14 and 1.17. Not sure if it needs to be backported to 1.7 as well.
And I fixed a so far unnoticed warning from including bufferclass_ti/ instead of bufferclass_example/ in 1.17.

> 
> 
>>> but I think the first step would be to get something to work with a newer kernel at all. (At least boot up and find /proc/pvr existing and some userspace libs interacting with it.)
>> Yes, indeed. Such a big project needs some intermediate goals.
>> 1. make 1.7 compile with modern kernel
>> 2. make it work with modern kernel and old user-space
>> 3. try to craft a generic driver (which can be switched between 1.7 and 1.17 - or more variants)
>>    or skip this step since we can already build a gma500 or gma3600 kernel driver for DDK 1.17
> 
> Yes exactly!
> 
> 
>>>>> Hopefully we could simply move everything to the latest DDK instead? :)
>>>> Well it may be possible but isn't simple either :)
>>> 
>>> I am thinking we might have some luck with reaching out to Imagination once we are at a stage where we'd just need the right userspace code from their end :)
>> Well, maybe. I had asked them when they upstreamed the PVV Rougue (architecture after SGX) and they were not completely dismissive but indicated that it has no priority for them...
>> More rejecting were the Linux upstream maintainers. They did not even consider our experience as useful.
>> This leads to an additional step:
>> 4. ask to get more user-space blobs for 1.17
> 
> We should see if we can do it in a way to reduces the work for them. Maybe they will consider providing their code to us. I have some ideas.
> 
> 
>> I think you can simply remove compiling the "drv/" directory. On first glance it looks like different Poulsbo related HDMI and LVDS and other drivers.
>> There seeoms to be only psb_sgx.c/.h and psb_pvr_glue.c/.h which may relate.
> 
> Yes, I think they kept the psb naming, but I do think I need those pieces. I think this is what made it into the GMA500 driver that's in the upstream kernel,

Well, there is also some 2D driver for the same PVR SGX components. At least on some TI chips. Maybe it is related to this?

> but I disabled that one in favor of this driver. Would there be other code to drive the HDMI and LVDS if it's not this code?

Do you get video out (HDMI) without any SGX related drivers? If yes, then we likely do not need this code.

> 
> 
>> I just noticed that I have skipped them for the pvrsgx-history analysis, assuming that it is not really pvr related.
> 
> I guess it's also because we have just one version of these files? So there's no further history to analyze? Or did you come across these files also in other versions?

Yes, they are not included in the other pvrsgx packages so my assumption was, that they are only loosely related. But this may be different.

BR,
Nikolaus