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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D1D14684-2532-46A4-ADA0-2F88F4D2228E@goldelico.com>
Date:   Fri, 15 May 2020 09:18:33 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Paul Cercueil <paul@...pouillou.net>,
        Paul Burton <paulburton@...nel.org>
Cc:     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>,
        Ralf Baechle <ralf@...ux-mips.org>,
        James Hogan <jhogan@...nel.org>, Kukjin Kim <kgene@...nel.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Maxime Ripard <mripard@...nel.org>,
        Chen-Yu Tsai <wens@...e.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Jonathan Bakker <xc-racer2@...e.ca>,
        Philipp Rossak <embed3d@...il.com>,
        "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 v7 01/12] dt-bindings: add img,pvrsgx.yaml for Imagination GPUs

Hi Paul & Paul,

> Am 03.05.2020 um 18:41 schrieb H. Nikolaus Schaller <hns@...delico.com>:
> 
> Hi Paul and Paul,
> 
>> Am 03.05.2020 um 16:18 schrieb Paul Cercueil <paul@...pouillou.net>:
>> 
>> 
>> 
>> Le dim. 3 mai 2020 à 15:31, H. Nikolaus Schaller <hns@...delico.com> a écrit :
>>> Hi Paul,
>>>> Am 03.05.2020 um 14:52 schrieb Paul Cercueil <paul@...pouillou.net>:
>>>>>> It's possible to forbid the presence of the 'clocks' property on some implementations, and require it on others.
>>>>> To be precise we have to specify the exact number of clocks (between 0 and 4) for every architecture.
>>>>> This also contradicts my dream to get rid of the architecture specific components in the long run. My dream (because I can't tell how it can be done) is that we can one day develop something which just needs compatible = img,530 or imp,540 or img,544. Then we can't make the number clocks depend on the implementation any more.
>>>> As we said before, the number of clocks is a property of the GPU and *not* its integration into the SoC.
>>> Well, it is a not very well documented property of the GPU. We have no data sheet of the standalone GPU. Only several SoC data sheets which give some indications.
>> 
>> Maybe we can nicely ask them?
> 
> There is some (old) answer here:
> 
> https://github.com/MIPS/CI20_linux/blob/ci20-v3.18/arch/mips/boot/dts/jz4780.dtsi#L63
> 
>> I expect Paul Burton to have some contacts at ImgTec. Asking for a doc would be too much, but maybe they can help a bit with the DT bindings.
> 
> Good idea! It is definitively worth to try. Therefore I have moved him from CC: to To:

Do we already have an idea if we can get into contact and get help from ImgTec for this topic or if we have to live with what we have?

BR and thanks,
Nikolaus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ