[Openpvrsgx-devgroup] Building the 1.7.862890 branch for x86

[H. Nikolaus Schaller]

Hi Julius,

> Am 30.05.2024 um 14:23 schrieb Julius Schwartzenberg <julius.vrijheid at freedom.nl>:
> 
> On 28.05.24 15:57, H. Nikolaus Schaller wrote:
>> Hm. To me it appeared that you are on the right one. But there are two branches:
>> a) letux/pvrsrvkm-1.7.862890 - which is (currently) based on upstream v6.8-rc4
>> b) pvrsrvkm-6.8-rc4 - which merges everything into a full branch, including the core driver and letux_defconfig
> 
> I was using a, but I'm struggling with how I could use b. Could it be that it misses glue needed for Cedarview? I guess something would still need to be ported. I enabled all PowerVR related options I found in `make menuconfig` but the compilation didn't seem to pass the driver code.

Ah, my fault. It should be simply some upstream Linux (v6.8-rc4) in this case plus all PVRSGX related commits.
But something may be missing.

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$ 

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

> 
> 
>>> The CONFIG variable used by my branch is the one that Intel's developers chose (CONFIG_DRM_INTEL_CDV).
>> Ah, I see. Well, we have a scheme that tries to combine all architectures and therefor isn't focussed on Intel&Cedarview.
> 
> For now I continued again with my prior branch with the added Cedarview bits. It would be great to move things into a tree that combines all architectures,

Well, the tree we have covers all architectures but may be incomplete for some or not debugged or simply not working because of missing user space.

Currently we get different kernel modules as

MODULE := pvrsrvkm_$(SOC)_$(SGX)_$(SGX_REV)

The processor architecture is already separated by ARCH= when calling the (cross) compiler.

And the DDK version is separated by the file path.
Adding it to the module name would be possible but makes it more hard-coded to run the correct modprobe. Or on some SoC the device tree defines which SGX to use.
So we decided against and leave it to different CONFIG options. And with the far goal it becomes irrelevant.

> 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

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

> 
> After solving some more compilation issues, I'm now running into build errors that seem to be in Intel Cedarview specific parts:
> 
>> drivers/gpu/drm/pvrsgx/1.7.862890/drv/psb_gtt.h:56:30: error: field ‘hash’ has incomplete type
>>   56 |         struct drm_open_hash hash;
>>      |                              ^~~~
>> drivers/gpu/drm/pvrsgx/1.7.862890/drv/psb_gtt.h:62:30: error: field ‘ht’ has incomplete type
>>   62 |         struct drm_open_hash ht;
>>      |                              ^~
>> drivers/gpu/drm/pvrsgx/1.7.862890/drv/psb_gtt.h:64:30: error: field ‘item’ has incomplete type
>>   64 |         struct drm_hash_item item;
>>      |                              ^~~~
>> drivers/gpu/drm/pvrsgx/1.7.862890/drv/psb_gtt.h:69:30: error: field ‘item’ has incomplete type
>>   69 |         struct drm_hash_item item;
>>      |                              ^~~~
>> drivers/gpu/drm/pvrsgx/1.7.862890/drv/psb_drv.h:41:10: fatal error: ttm/ttm_object.h: Немає такого файла або каталогу

Oops... Well, "psb" seems to be an abbreviation for "Poulsbo".
And indeed psb_drv.h: #define DRIVER_DESC "drm driver for the Intel GMA500"

>>   41 | #include "ttm/ttm_object.h"
>>      |          ^~~~~~~~~~~~~~~~~~
> 
> I guess I need to look at how other drivers solved these issues.

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.

I just noticed that I have skipped them for the pvrsgx-history analysis, assuming that it is not really pvr related.

BR,
Nikolaus