[PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

[H. Nikolaus Schaller]

> Am 21.12.2023 um 09:58 schrieb Maxime Ripard <mripard at kernel.org>:
> 
> Cool, so what you're saying is that your plan is to support those GPUs
> upstream in the imagination driver?

Yes, I would like to see PowerVR Series 5 SGX supported upstream since there
are still so many devices in the wild which could use it. The most advanced
being the Pyra handheld gaming computer but there are omap4 based phones
or other omap3/amm335x based devices.

And the only reason the OpenPVRSGX group was founded (BTW not by me, I am just
maintaining the code and running a mailing list because it was rejected to host
it on vger.kernel.org), was to make that happen.

From the GitHub description:
	This is about shaping existing GPL Linux kernel drivers for the PVR/SGX5
	architecture so that they can become accepted into drivers/staging

But nobody can currently tell if it can be integrated with the recently upstreamed
Rogue driver (I wouldn't call that *the* imagination driver) or if it better stays
a separate driver because the first would need touching closed user-space code
and GPU firmware.

And nobody knows who is capable and willing to work on it. It depends on access to
(confidential) documentation and available time to make such a big task a rewarding
project. And discussions like this one are not at all encouraging to even try.

>> Now, IMHO all the pros and cons are on the table and the question is
>> who makes a decision how to go.
> 
> You haven't listed any pro so far, you're claiming that the one I raise
> are irrelevant.

I have listed some "pros" for "single file" but you apparently don't see
them as such. I can't change that. The main argument is that a single file is
simpler than two files duplicating parts, which are apparently the same
(integration of PVR architectures into SoC doesn't differ very much: shared
register block, DMA memory, clocks, resets etc.).
Yours is that two files duplicating such common things is "more convenient".
I just wonder for whom.

But it seems as if the IMHO second best solution has already been chosen.
So let it be.

>> Then the currently-out-of-tree driver for the sgx5 can be reworked in
>> less than half an hour without loosing functionality.
> 
> Again, you're making it harder than it needs to be for no particular
> reason other than the potential file name clash that can be addressed.

What I want to avoid is a situation that upstream activities do not take the
existing and working out-of-tree SGX driver into account and make porting
(not even speaking of upstreaming) that driver more difficult than necessary
and force device tree files to contain redundant information nobody will need
and use. You can of course ignore experience and suggestions of people
who have worked on an SGX driver for a while. But that is the reason why I
participate in this discussion and raise my voice.

Now, I am looking forward to a v2 of this patch.

BR,
Nikolaus