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] [day] [month] [year] [list]
Date:   Mon, 23 Sep 2019 15:33:25 +0100
From:   Steven Price <steven.price@....com>
To:     Alyssa Rosenzweig <alyssa.rosenzweig@...labora.com>,
        Nicolas Boichat <drinkcat@...omium.org>
Cc:     Mark Rutland <mark.rutland@....com>, devicetree@...r.kernel.org,
        Dominik Behr <dbehr@...omium.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Douglas Anderson <dianders@...omium.org>,
        Rob Herring <robh+dt@...nel.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>,
        Boris Brezillon <boris.brezillon@...labora.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Nick Fan <nick.fan@...iatek.com>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] arm64: dts: mt8183: Add node for the Mali GPU

On 19/09/2019 13:32, Alyssa Rosenzweig wrote:
>>> By the time MT8183 shows up in more concrete devices, it will, certainly
>>> in kernel-space and likely in userspace as well. At present, the DDK can
>>> be modified to run on top of the in-tree Mali drivers, i.e. "Bifrost on
>>> mainline linux-next (+ page table/compatible patches), with blob
>>> userspace".

Actually most(?) Bifrost GPUs support the "legacy" 'LPAE-ish' page table
format. So the only kernel change *required* is adding the compatible
string (and any SoC-specific quirks).

The support for "blob-on-Panfrost" is currently an experimental internal
investigation. So I can't make any promises about it ever being released
publicly.

>>> While the open userspace isn't ready here quite yet, I would definitely
>>> encourage upstream kernel for ChromeOS, since then there's no need to
>>> maintain the out-of-tree GPU driver.
>>
>> That's an interesting idea, I had no idea, thanks for the info!
>>
>> Would that work with midgard as well? We have released hardware with
>> RK3288/3399, so it might be nice to experiment with these first.
> 
> Yes, the above would work with Midgard as well with no changes needed.
> Ping Steven about thtat (CC'd).

Indeed since it's the same kernel driver the same compatibility layer
can be used to run Midgard DDK blob on Panfrost. Although given the
progress that has already occurred with the Mesa Panfrost user space you
might be able to simply switch to a completely open stack (available now).

Again I'm afraid I'm not in a position to give any guarantees that my
prototype blob-on-Panfrost work will actually be released or timescales
of when. However since the current focus internally is on newer GPUs I'm
less confident that there will be interest for Midgard DDK on Panfrost.

Steve

>>> More immediately, per Rob's review, it's important that the bindings
>>> accepted upstream work with the in-tree Bifrost driver. Conceptually,
>>> once Mesa supports Bifrost, if I install Debian on a MT8183 board,
>>> everything should just work. I shouldn't need MT-specific changes / need
>>> to change names for the DT. Regardless of which kernel driver you end up
>>> using, minimally sharing the DT is good for everyone :-)
>>
>> Yes. I'll try to dig further with MTK, but this may take some time.
> 
> Thank you!
> 
> 
> _______________________________________________
> 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ