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: <20200421112129.zjmkmzo3aftksgka@gilmour.lan>
Date:   Tue, 21 Apr 2020 13:21:29 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     Philipp Rossak <embed3d@...il.com>
Cc:     "H. Nikolaus Schaller" <hns@...delico.com>,
        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>,
        Tony Lindgren <tony@...mide.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)

Hi,

On Tue, Apr 21, 2020 at 11:57:33AM +0200, Philipp Rossak wrote:
> 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.

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.

> 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?

I'm really not sure what makes you think that this should be modelled as a
clock?

> > > 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?

This is what we done for the Mali. The devicetree binding was first done for the
out-of-tree driver, and then lima/panfrost reused it.

The key thing here is to have enough confidence about how the hardware works so
that you can accurately describe it.

Maxime

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