Date:   Thu, 23 Apr 2020 17:00:49 +0200
From:   Neil Armstrong <narmstrong@...libre.com>
To:     "H. Nikolaus Schaller" <hns@...delico.com>,
        Maxime Ripard <maxime@...no.tech>
Cc:     Mark Rutland <mark.rutland@....com>,
        Tony Lindgren <tony@...mide.com>,
        James Hogan <jhogan@...nel.org>,
        Jonathan Bakker <xc-racer2@...e.ca>,
        "open list:DRM PANEL DRIVERS" <dri-devel@...ts.freedesktop.org>,
        linux-mips@...r.kernel.org, Paul Cercueil <paul@...pouillou.net>,
        linux-samsung-soc@...r.kernel.org,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>,
        Paul Burton <paulburton@...nel.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        David Airlie <airlied@...ux.ie>, Chen-Yu Tsai <wens@...e.org>,
        Kukjin Kim <kgene@...nel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        linux-omap <linux-omap@...r.kernel.org>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Philipp Rossak <embed3d@...il.com>,
        OpenPVRSGX Linux Driver Group <openpvrsgx-devgroup@...ux.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Benoît Cousson <bcousson@...libre.com>,
        kernel@...a-handheld.com
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 22/04/2020 18:09, H. Nikolaus Schaller wrote:
> Hi Maxime,
> 
>> Am 22.04.2020 um 17:13 schrieb Maxime Ripard <maxime@...no.tech>:
>>
>> 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>:
>>>>>
>>>>> 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.
> 
> Hm. Now I am fully puzzled.
> You have no knowledge about this GPU but disagree with our proposal?
> Is it just gut feeling?
> 
> Anyways, we need to find a solution. Together.
> 
>>
>>> 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.
> 
> Well, I do not need inspiration, we need to come to an agreement about
> img,pvrsgx.yaml and we need some maintainer to finally pick it up.
> 
> I wonder how we can come to this stage.
> 
> If I look at vivante,gc.yaml or arm,mali-utgard.yaml I don't
> see big differences to what we propose and those I see seem to come
> from technical differences between sgx, vivante, mali etc. So there
> is no single scheme that fits all different gpu types.
> 
> 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

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

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.

Neil

> 
> BR and thanks,
> Nikolaus
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Powered by blists - more mailing lists