On Thu, Apr 23, 2020 at 05:45:55PM +0200, H. Nikolaus Schaller wrote:
Am 23.04.2020 um 17:00 schrieb Neil Armstrong narmstrong@baylibre.com:
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.
Usually IPs needs a few clocks:
- pclk or apb or reg: the clock clocking the "slave" bus to serve the registers
- axi or bus or ahb: the bus clocking the the "master" bus to get data from system memory
- core: the actual clock feeding the GPU logic
And the sgx544 seems to have two such clocks.
Sometimes you have a single clock for slave and master bus.
But you can also have separate clocks for shader cores, .. this depends on the IP and it's architecture. The IP can also have memories with separate clocks, etc...
Indeed.
But all these clocks can be source by an unique clock on a SoC, but different on another SoC, this is why it's important to list them all, even optional.
You'll certainly have at least a reset signal, and a power domain, these should exist and be optional.
Well, they exist only as hints in block diagrams of some SoC data sheets (so we do not know if they represent the imagination definitions) and the current driver code doesn't make use of it. Still the gpu core works.
So I do not see any urgent need to add a complete list to the bindings now.
Unless some special SoC integration makes use of them. Then it is IMHO easier to extend the bindings by a follow-up patch than now thinking about all potential options and bloating the bindings with things we (the open source community) doesn't and can't know.
My goal is to keep the bindings as minimalistic as possible. And reset lines and power domains are (at least for those we have in the works) not needed to make working systems.
Therefore, for clocks I also would start with a minimalistic approach for a single optional GPU core clock and leave out reset and power completely.
Like I said above, the DT is considered an ABI and you'll have to maintain backward compatibility (ie, newer kernel running with older DT). Therefore, you won't be able to require a new clock, reset or power-domain later on for example.
I guess the question I'm really asking is: since you don't really know how the hardware is integrated at the moment, why should we have that discussion *now*. It's really not suprising that you don't know yet, so I'm not sure why we need to rush in the bindings.
Maxime