* H. Nikolaus Schaller hns@goldelico.com [200421 17:31]:
Am 21.04.2020 um 16:15 schrieb Tony Lindgren tony@atomide.com: Note that on omaps there are actually SoC module specific registers.
Ah, I see. This is of course a difference that the TI glue logic has its own registers in the same address range as the sgx and this can't be easily handled by a common sgx driver.
This indeed seems to be unique with omap.
And there can be multiple devices within a single target module on omaps. So the extra dts node and device is justified there.
For other SoCs, the SGX clocks are probably best handled directly in pvr-drv.c PM runtime functions unless a custom hardware wrapper with SoC specific registers exists.
That is why we need to evaluate what the better strategy is.
So we have a) omap which has a custom wrapper around the sgx b) others without, i.e. an empty (or pass-through) wrapper
Which one do we make the "standard" and which one the "exception"? What are good reasons for either one?
The wrapper is already handled by the ti-sysc binding, the sgx binding should be standard with optional clocks.
See for example the standard 8250 uart for am335x with:
$ git grep -B20 -A10 uart0 arch/arm/boot/dts/am33xx-l4.dtsi
The 8250 device configuration is described in the standard 8250 dts binding, and the am335x module in the ti-sysc binding. The are separate devices :)
So for the sgx binding, you can just leave out TI specific module wrapper completely from the example.
It also allows to handle different number of clocks (A31 seems to 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.
Well if other SoCs implement genpd domains etc, that's then again part of a separate binding and not part of the sgx binding.
Regards,
Tony