> Am 21.12.2023 um 09:58 schrieb Maxime Ripard <mripard@xxxxxxxxxx>: > > 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
