From: "H. Nikolaus Schaller" <hns@goldelico.com>
To: Maxime Ripard <mripard@kernel.org>
Cc: "Andrew Davis" <afd@ti.com>,
"Frank Binns" <frank.binns@imgtec.com>,
"Donald Robson" <donald.robson@imgtec.com>,
"Matt Coster" <matt.coster@imgtec.com>,
"Adam Ford" <aford173@gmail.com>,
"Ivaylo Dimitrov" <ivo.g.dimitrov.75@gmail.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Chen-Yu Tsai" <wens@csie.org>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Samuel Holland" <samuel@sholland.org>,
"Benoît Cousson" <bcousson@baylibre.com>,
"Tony Lindgren" <tony@atomide.com>, "Nishanth Menon" <nm@ti.com>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
"Tero Kristo" <kristo@kernel.org>,
"Paul Cercueil" <paul@crapouillou.net>,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev, linux-omap@vger.kernel.org,
linux-mips@vger.kernel.org
Subject: Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
Date: Thu, 21 Dec 2023 16:23:39 +0100 [thread overview]
Message-ID: <F2D7693E-7769-463A-97A8-BA952EB5320B@goldelico.com> (raw)
In-Reply-To: <nzqeqwof44e3nxjz6lsxmxcfh235unbu343br45esxh6vinskp@xvjydpxhvsuk>
> Am 21.12.2023 um 09:58 schrieb Maxime Ripard <mripard@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
next prev parent reply other threads:[~2023-12-21 15:24 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-04 18:22 [PATCH RFC 00/10] Device tree support for Imagination Series5 GPU Andrew Davis
2023-12-04 18:22 ` [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs Andrew Davis
2023-12-05 6:57 ` Maxime Ripard
2023-12-05 8:18 ` H. Nikolaus Schaller
2023-12-05 13:29 ` Maxime Ripard
2023-12-05 13:50 ` H. Nikolaus Schaller
2023-12-07 9:20 ` Maxime Ripard
2023-12-07 10:33 ` H. Nikolaus Schaller
2023-12-15 13:33 ` Maxime Ripard
2023-12-18 9:28 ` H. Nikolaus Schaller
2023-12-18 10:14 ` Maxime Ripard
2023-12-18 10:54 ` H. Nikolaus Schaller
2023-12-19 17:19 ` Andrew Davis
2023-12-21 9:02 ` Maxime Ripard
2023-12-21 8:58 ` Maxime Ripard
2023-12-21 15:23 ` H. Nikolaus Schaller [this message]
2023-12-05 7:10 ` Krzysztof Kozlowski
2023-12-05 7:56 ` Tony Lindgren
2023-12-05 8:03 ` Krzysztof Kozlowski
2023-12-05 8:10 ` Tony Lindgren
2023-12-05 8:16 ` Krzysztof Kozlowski
2023-12-05 8:30 ` Tony Lindgren
2023-12-05 8:45 ` Krzysztof Kozlowski
2023-12-05 9:02 ` Andreas Kemnade
2023-12-05 9:27 ` Krzysztof Kozlowski
2023-12-05 9:43 ` Andreas Kemnade
2023-12-07 6:38 ` Tony Lindgren
2023-12-05 8:17 ` H. Nikolaus Schaller
2023-12-05 17:33 ` Andrew Davis
2023-12-05 18:04 ` H. Nikolaus Schaller
2023-12-06 16:02 ` Conor Dooley
2023-12-06 16:15 ` Andrew Davis
2023-12-06 22:02 ` H. Nikolaus Schaller
2023-12-06 21:43 ` H. Nikolaus Schaller
2023-12-04 18:22 ` [PATCH RFC 02/10] ARM: dts: omap3: Add device tree entry for SGX GPU Andrew Davis
2023-12-04 18:22 ` [PATCH RFC 03/10] ARM: dts: omap4: " Andrew Davis
2023-12-04 18:22 ` [PATCH RFC 04/10] ARM: dts: omap5: " Andrew Davis
2023-12-04 18:22 ` [PATCH RFC 05/10] ARM: dts: AM33xx: " Andrew Davis
2023-12-04 18:22 ` [PATCH RFC 06/10] ARM: dts: AM437x: " Andrew Davis
2023-12-04 18:22 ` [PATCH RFC 07/10] ARM: dts: DRA7xx: " Andrew Davis
2023-12-04 18:22 ` [PATCH RFC 08/10] arm64: dts: ti: k3-am654-main: " Andrew Davis
2023-12-04 18:22 ` [PATCH RFC 09/10] ARM: dts: sun6i: " Andrew Davis
2023-12-04 18:22 ` [PATCH RFC 10/10] MIPS: DTS: jz4780: " Andrew Davis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F2D7693E-7769-463A-97A8-BA952EB5320B@goldelico.com \
--to=hns@goldelico.com \
--cc=afd@ti.com \
--cc=aford173@gmail.com \
--cc=bcousson@baylibre.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=donald.robson@imgtec.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=frank.binns@imgtec.com \
--cc=ivo.g.dimitrov.75@gmail.com \
--cc=jernej.skrabec@gmail.com \
--cc=kristo@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matt.coster@imgtec.com \
--cc=mripard@kernel.org \
--cc=nm@ti.com \
--cc=paul@crapouillou.net \
--cc=robh+dt@kernel.org \
--cc=samuel@sholland.org \
--cc=tony@atomide.com \
--cc=tzimmermann@suse.de \
--cc=vigneshr@ti.com \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).