Hi,
On 20.04.20 09:38, Maxime Ripard wrote:
Hi,
On Fri, Apr 17, 2020 at 02:09:06PM +0200, Philipp Rossak wrote:
I'm a bit skeptical on that one since it doesn't even list the
interrupts connected to the GPU that the binding mandates.
I think he left it out for a future update.
But best he comments himself.
I'm currently working on those bindings. They are now 90% done, but they are
not finished till now. Currently there is some mainline support missing to
add the full binding. The A83T and also the A31/A31s have a GPU Power Off
Gating Register in the R_PRCM module, that is not supported right now in
Mainline. The Register need to be written when the GPU is powered on and
off.
@Maxime: I totally agree on your point that a demo needs to be provided
before the related DTS patches should be provided. That's the reason why I
added the gpu placeholder patches.
Do you have an idea how a driver for the R_PRCM stuff can look like? I'm not
that experienced with the clock driver framework.
It looks like a power-domain to me, so you'd rather plug that into the genpd
framework.
I had a look on genpd and I'm not really sure if that fits.
It is basically some bit that verify that the clocks should be enabled
or disabled. I think this is better placed somewhere in the clocking
framework.
I see there more similarities to the gating stuff.
Do you think it is suitable to implement it like the clock gating?
The big question is right now how to proceed with the A83T and A31s patches.
I see there three options, which one do you prefer?:
1. Provide now placeholder patches and send new patches, if everything is
clear and other things are mainlined
2. Provide now patches as complete as possible and provide later patches to
complete them when the R_PRCM things are mainlined
3. Leave them out, till the related work is mainlined and the bindings are
final.
Like I said, the DT *has* to be backward-compatible, so for any DT patch that
you are asking to be merged, you should be prepared to support it indefinitely
and be able to run from it, and you won't be able to change the bindings later
on.
I agree on your points. But is this also suitable to drivers that are
currently off tree and might be merged in one or two years?
Since this GPU IP core is very flexible and the SOC manufactures can
configure it on their needs, I think the binding will extend in the future.
For example the SGX544 GPU is available in different configurations: there
is a SGX544 core and SGX544MPx core. The x stands for the count of the USSE
(Universal Scalable Shader Engine) cores. For example the GPU in the A83T is
a MP1 and the A31/A31s a MP2.
Mali is in the same situation and it didn't cause much trouble.
Good to know.
In addition to that some of the GPU's have also a 2D engine.
In the same memory region, running from the same interrupts, or is it a
completely separate IP that happens to be sold by the same vendor?
What I know till now this is part of the PowerVR IP and not separated.
So it should use the same memory region, clocks and interrupts.
Cheers
Philipp
