On Wed, Apr 22, 2020 at 09:10:57AM +0200, H. Nikolaus Schaller wrote: > > Am 22.04.2020 um 08:58 schrieb Maxime Ripard <maxime@xxxxxxxxxx>: > > > > On Tue, Apr 21, 2020 at 07:29:32PM +0200, H. Nikolaus Schaller wrote: > >> > >>> Am 21.04.2020 um 16:15 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: > >>> > >>> * Maxime Ripard <maxime@xxxxxxxxxx> [200421 11:22]: > >>>> On Tue, Apr 21, 2020 at 11:57:33AM +0200, Philipp Rossak wrote: > >>>>> 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. > >>>> > >>>> No, it can do much more than that. It's a framework to control the SoCs power > >>>> domains, so clocks might be a part of it, but most of the time it's going to be > >>>> about powering up a particular device. > >>> > >>> 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? > >> > >> > >> I am currently in strong favour of a) being standard because it > >> makes the pvr-drv.c simpler and really generic (independent of > >> wrapping into any SoC). > >> > >> This will likely avoid problems if we find more SoC with yet another > >> scheme how the SGX clocks are wrapped. > >> > >> 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. > > > > I disagree. Every other GPU binding and driver is handling that just fine, and > > the SGX is not special in any case here. > > Can you please better explain this? With example or a description > or a proposal? I can't, I don't have any knowledge about this GPU. > I simply do not have your experience with "every other GPU" as you have. > 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. If you need some inspiration, I guess you could look at the mali and vivante bindings once you have an idea of what the GPU needs across the SoCs it's integrated in. Maxime
Attachment:
signature.asc
Description: PGP signature
