linux-kernel - Re: [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200422151328.2oyqz7gqkbunmd6o@gilmour.lan>
Date:   Wed, 22 Apr 2020 17:13:28 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     Tony Lindgren <tony@...mide.com>,
        Philipp Rossak <embed3d@...il.com>,
        Jonathan Bakker <xc-racer2@...e.ca>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Benoît Cousson <bcousson@...libre.com>,
        Paul Cercueil <paul@...pouillou.net>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Paul Burton <paulburton@...nel.org>,
        James Hogan <jhogan@...nel.org>, Kukjin Kim <kgene@...nel.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Chen-Yu Tsai <wens@...e.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        "open list:DRM PANEL DRIVERS" <dri-devel@...ts.freedesktop.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-omap <linux-omap@...r.kernel.org>,
        OpenPVRSGX Linux Driver Group <openpvrsgx-devgroup@...ux.org>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>, kernel@...a-handheld.com,
        linux-mips@...r.kernel.org,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        linux-samsung-soc@...r.kernel.org
Subject: Re: [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the
 PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more)

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@...no.tech>:
> > 
> > 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@...mide.com>:
> >>> 
> >>> * Maxime Ripard <maxime@...no.tech> [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

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)