linux-kernel - Re: [PATCH v2 3/3] drm/panfrost: Add initial panfrost driver

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: <bb389964-13af-5de0-099c-27443844f18a@arm.com>
Date:   Tue, 2 Apr 2019 12:23:25 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Alyssa Rosenzweig <alyssa@...enzweig.io>
Cc:     Rob Herring <robh@...nel.org>, Lyude Paul <lyude@...hat.com>,
        Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        Eric Anholt <eric@...olt.net>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        Will Deacon <will.deacon@....com>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        David Airlie <airlied@...ux.ie>,
        iommu@...ts.linux-foundation.org, Daniel Vetter <daniel@...ll.ch>,
        "Marty E . Plummer" <hanetzer@...rtmail.com>,
        Sean Paul <sean@...rly.run>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 3/3] drm/panfrost: Add initial panfrost driver

On 02/04/2019 01:33, Alyssa Rosenzweig wrote:
>> the userspace definitely doesn't support T624
> 
> This is true, yes. Shouldn't be too hard to backport; if there's still
> interest in Midgard 1st/2nd gen, I suppose I can grab hardware and sort
> it out...

I'm quite likely the only person trying this on an Arm Juno board, and 
even then it's really only for giggles because I can :)  I guess there 
might be a fair few Odroid-XU3/XU4 (T628) users interested, though.

>> You probably want a dma_set_mask_and_coherent() call for your 'real' output
>> address size somewhere - the default 32-bit mask works out OK for RK3399,
>> but on systems with RAM above 4GB io-pgtable will get very unhappy about DMA
>> bounce-buffering.
> 
> Out of curiosity, are there Mali systems with >4GB RAM? That sounds
> awesome :)

Now that the "early-access Armv8 silicon" angle has well and truly 
expired, Juno is essentially a prototyping platform where the SoC just 
serves to (slowly) drive interesting things in FPGA cards, so although 
it may have 8GB of RAM, it's not all that exciting. There is one 
somewhat more realistic board I'm aware of, namely HiKey 970 with a G72 
and 6GB.

>> Any chance of resurrecting the generic "arm,mali-midgard" compatible? :P
> 
> ...Would that require editing everybody's DT file?

If they already have one of the strings from the current upstream 
binding, no - I only mean to suggest adding it as an additional 
last-level fallback. That would aid compatibility with downstream DTs, 
for example RK3288 which currently has zero overlap:

upstream: "rockchip,rk3288-mali", "arm,mali-t760";

downstream: "arm,malit764", "arm,malit76x", "arm,malit7xx", 
"arm,mali-midgard";

Similarly, it might be reasonable for panfrost_{gpu,mmu,job}_init() to 
retry platform_get_irq_byname() with uppercase interrupt names if the 
expected ones aren't found - obviously the upstream binding comes first 
and foremost, but I don't see any harm in quietly supporting bits of the 
downstream binding if it makes users' lives easier when switching 
between mainline and vendor kernels.

Cheers,
Robin.