Hi Paul,A few years back, I did a big research on the PowerVR GPUs. Back then I found an interesting TI datasheet. I forgot about this till I have seen the right buzz words. Sorry that I remembered it that late.
Am 22.04.2020 um 18:55 schrieb Paul Cercueil <paul@xxxxxxxxxxxxxxx>:
Hi Nikolaus,
Le mer. 22 avril 2020 Ã 18:09, H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> a Ãcrit :
Hi Maxime,
Am 22.04.2020 um 17:13 schrieb Maxime Ripard <maxime@xxxxxxxxxx>:Hm. Now I am fully puzzled.
On Wed, Apr 22, 2020 at 09:10:57AM +0200, H. Nikolaus Schaller wrote:
I can't, I don't have any knowledge about this GPU.Am 22.04.2020 um 08:58 schrieb Maxime Ripard <maxime@xxxxxxxxxx>:Can you please better explain this? With example or a description
It also allows to handle different number of clocks (A31 seems toI disagree. Every other GPU binding and driver is handling that just fine, and
need 4, Samsung, A83 and JZ4780 one) without changing the sgx bindings
or making big lists of conditionals. This variance would be handled
outside the sgx core bindings and driver.
the SGX is not special in any case here.
or a proposal?
You have no knowledge about this GPU but disagree with our proposal?
Is it just gut feeling?
Anyways, we need to find a solution. Together.
Well, I do not need inspiration, we need to come to an agreement aboutI simply do not have your experience with "every other GPU" as you have.If you need some inspiration, I guess you could look at the mali and vivante
And I admit that I can't read from your statement what we should do
to bring this topic forward.
So please make a proposal how it should be in your view.
bindings once you have an idea of what the GPU needs across the SoCs it's
integrated in.
img,pvrsgx.yaml and we need some maintainer to finally pick it up.
I wonder how we can come to this stage.
If I look at vivante,gc.yaml or arm,mali-utgard.yaml I don't
see big differences to what we propose and those I see seem to come
from technical differences between sgx, vivante, mali etc. So there
is no single scheme that fits all different gpu types.
One thing we can learn is that "core" seems to be a de facto standard
for the core clock-name. An alternative "gpu" is used by nvidia,gk20a.txt.
The Vivante GPU binding requires "bus", "core" and "shader" clocks. But if your SoC only has one clock for the GPU, there's nothing that prevents you from passing the very same clock as "bus", "core" and "shader". This is what we do on the Ingenic JZ4770 SoC.
Fine and good to know.
Well, for the SGX we so far only know a single "core" clock (with different
names). Only the A31 seems to be different.
Fortunately I finally found a little time to scan through the a31
user manual: http://dl.linux-sunxi.org/A31/A31%20User%20Manual%20V1.20.pdf
There are 3 clock dividers. And there is a single clock PLL8 dedicated to
the gpu. The clock dividers are called "gpu core", "gpu mem", "gpu hyd".
Then, there are dedicated clock gating registers. And idle/power status
registers.
Unfortunately, chapter "5.1. GPU" is almost empty and has no block diagram.
So I have no idea what "HYD" stands for. And if the memory and HYD clocks
are needed and how they should be initialized. If they are different ones
or can all be driven by PLL8 in parallel.
That scarce information makes it difficult to form a "proper" bindings
document out of it. Any can fit or be false.
At least there is something common with all other SGX implementations I
am aware of: there is a "core" clock.
So I'd suggest to get things moving forwards:
* we add a "core" clock-names to the bindings
* this can't be wrong for the A31 since it is defined in the data sheet
* we make it optional since the omap chips have a clock wrapper
* "core" is a name I think all architectures/drivers can live with
and can add later "shader", "bus" etc. if needed
* any additions for the A31 will be additions
If that sounds ok and nobody objects to it, I can submit a new patch
version for further review.
BR and thanks,
Nikolaus