From: Robin Murphy <robin.murphy@arm.com> To: Alyssa Rosenzweig <alyssa@rosenzweig.io> Cc: Rob Herring <robh@kernel.org>, Lyude Paul <lyude@redhat.com>, Tomeu Vizoso <tomeu.vizoso@collabora.com>, Eric Anholt <eric@anholt.net>, Maxime Ripard <maxime.ripard@bootlin.com>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Neil Armstrong <narmstrong@baylibre.com>, Will Deacon <will.deacon@arm.com>, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, David Airlie <airlied@linux.ie>, iommu@lists.linux-foundation.org, Daniel Vetter <daniel@ffwll.ch>, "Marty E . Plummer" <hanetzer@startmail.com>, Sean Paul <sean@poorly.run>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 3/3] drm/panfrost: Add initial panfrost driver Date: Tue, 2 Apr 2019 12:23:25 +0100 [thread overview] Message-ID: <bb389964-13af-5de0-099c-27443844f18a@arm.com> (raw) In-Reply-To: <20190402003326.GB12934@rosenzweig.io> 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.
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com> To: Alyssa Rosenzweig <alyssa@rosenzweig.io> Cc: Rob Herring <robh@kernel.org>, Lyude Paul <lyude@redhat.com>, Tomeu Vizoso <tomeu.vizoso@collabora.com>, Neil Armstrong <narmstrong@baylibre.com>, Maxime Ripard <maxime.ripard@bootlin.com>, Will Deacon <will.deacon@arm.com>, David Airlie <airlied@linux.ie>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Eric Anholt <eric@anholt.net>, iommu@lists.linux-foundation.org, Daniel Vetter <daniel@ffwll.ch>, "Marty E . Plummer" <hanetzer@startmail.com>, Sean Paul <sean@poorly.run>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 3/3] drm/panfrost: Add initial panfrost driver Date: Tue, 2 Apr 2019 12:23:25 +0100 [thread overview] Message-ID: <bb389964-13af-5de0-099c-27443844f18a@arm.com> (raw) In-Reply-To: <20190402003326.GB12934@rosenzweig.io> 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-04-02 11:23 UTC|newest] Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-01 7:47 [PATCH v2 0/3] Initial Panfrost driver Rob Herring 2019-04-01 7:47 ` Rob Herring 2019-04-01 7:47 ` [PATCH v3 1/3] iommu: io-pgtable: Add ARM Mali midgard MMU page table format Rob Herring 2019-04-01 7:47 ` Rob Herring 2019-04-01 7:47 ` Rob Herring 2019-04-01 19:11 ` Robin Murphy 2019-04-01 19:11 ` Robin Murphy 2019-04-05 10:02 ` Robin Murphy 2019-04-05 10:02 ` Robin Murphy 2019-04-05 10:02 ` Robin Murphy 2019-04-11 13:15 ` Joerg Roedel 2019-04-11 13:15 ` Joerg Roedel 2019-04-11 13:15 ` Joerg Roedel 2019-04-05 9:42 ` Steven Price 2019-04-05 9:42 ` Steven Price 2019-04-05 9:42 ` Steven Price 2019-04-05 9:51 ` Robin Murphy 2019-04-05 9:51 ` Robin Murphy 2019-04-05 10:36 ` Steven Price 2019-04-05 10:36 ` Steven Price 2019-04-08 8:56 ` Steven Price 2019-04-08 8:56 ` Steven Price 2019-04-08 8:56 ` Steven Price 2019-04-01 7:47 ` [PATCH v2 2/3] drm: Add a drm_gem_objects_lookup helper Rob Herring 2019-04-01 7:47 ` Rob Herring 2019-04-01 13:06 ` Daniel Vetter 2019-04-01 13:06 ` Daniel Vetter 2019-04-01 13:48 ` Chris Wilson 2019-04-01 13:48 ` Chris Wilson 2019-04-01 13:48 ` Chris Wilson 2019-04-01 15:43 ` Eric Anholt 2019-04-01 15:43 ` Eric Anholt 2019-04-01 15:43 ` Eric Anholt 2019-04-08 20:09 ` Rob Herring 2019-04-08 20:09 ` Rob Herring 2019-04-08 20:09 ` Rob Herring 2019-04-09 16:55 ` Eric Anholt 2019-04-09 16:55 ` Eric Anholt 2019-04-09 16:55 ` Eric Anholt 2019-04-09 16:55 ` Eric Anholt 2019-04-01 16:59 ` Rob Herring 2019-04-01 16:59 ` Rob Herring 2019-04-01 18:22 ` Eric Anholt 2019-04-01 18:22 ` Eric Anholt 2019-04-01 18:22 ` Eric Anholt 2019-04-01 7:47 ` [PATCH v2 3/3] drm/panfrost: Add initial panfrost driver Rob Herring 2019-04-01 8:24 ` Neil Armstrong 2019-04-01 8:24 ` Neil Armstrong 2019-04-01 19:17 ` Robin Murphy 2019-04-01 19:17 ` Robin Murphy 2019-04-01 16:02 ` Eric Anholt 2019-04-01 16:02 ` Eric Anholt 2019-04-01 19:12 ` Robin Murphy 2019-04-01 19:12 ` Robin Murphy 2019-04-01 19:12 ` Robin Murphy 2019-04-02 0:33 ` Alyssa Rosenzweig 2019-04-02 0:33 ` Alyssa Rosenzweig 2019-04-02 11:23 ` Robin Murphy [this message] 2019-04-02 11:23 ` Robin Murphy 2019-04-03 4:57 ` Rob Herring 2019-04-03 4:57 ` Rob Herring 2019-04-03 4:57 ` Rob Herring 2019-04-05 12:57 ` Robin Murphy 2019-04-05 12:57 ` Robin Murphy 2019-04-05 12:57 ` Robin Murphy 2019-04-05 12:30 ` Steven Price 2019-04-05 16:16 ` Alyssa Rosenzweig 2019-04-05 16:16 ` Alyssa Rosenzweig 2019-04-05 16:16 ` Alyssa Rosenzweig 2019-04-05 16:42 ` Steven Price 2019-04-05 16:42 ` Steven Price 2019-04-05 16:42 ` Steven Price 2019-04-05 16:53 ` Alyssa Rosenzweig 2019-04-05 16:53 ` Alyssa Rosenzweig 2019-04-05 16:53 ` Alyssa Rosenzweig 2019-04-15 9:18 ` Daniel Vetter 2019-04-15 9:18 ` Daniel Vetter 2019-04-15 9:18 ` Daniel Vetter 2019-04-15 9:30 ` Steven Price 2019-04-15 9:30 ` Steven Price 2019-04-15 9:30 ` Steven Price 2019-04-16 7:51 ` Daniel Vetter 2019-04-16 7:51 ` Daniel Vetter 2019-04-16 7:51 ` Daniel Vetter 2019-04-16 7:51 ` Daniel Vetter 2019-04-08 21:04 ` Rob Herring 2019-04-08 21:04 ` Rob Herring 2019-04-08 21:04 ` Rob Herring 2019-04-08 21:04 ` Rob Herring 2019-04-09 15:56 ` Tomeu Vizoso 2019-04-09 15:56 ` Tomeu Vizoso 2019-04-09 15:56 ` Tomeu Vizoso 2019-04-09 15:56 ` Tomeu Vizoso 2019-04-09 16:15 ` Rob Herring 2019-04-09 16:15 ` Rob Herring 2019-04-09 16:15 ` Rob Herring 2019-04-09 16:15 ` Rob Herring 2019-04-10 10:28 ` Steven Price 2019-04-10 10:28 ` Steven Price 2019-04-10 10:28 ` Steven Price 2019-04-10 10:28 ` Steven Price 2019-04-10 10:19 ` Steven Price 2019-04-10 10:19 ` Steven Price 2019-04-10 10:19 ` Steven Price 2019-04-10 10:19 ` Steven Price 2019-04-10 11:50 ` Tomeu Vizoso 2019-04-10 11:50 ` Tomeu Vizoso 2019-04-10 11:50 ` Tomeu Vizoso 2019-04-10 11:50 ` Tomeu Vizoso 2019-04-01 15:05 ` [PATCH v2 0/3] Initial Panfrost driver Alyssa Rosenzweig 2019-04-01 15:05 ` Alyssa Rosenzweig 2019-04-01 15:05 ` Alyssa Rosenzweig
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bb389964-13af-5de0-099c-27443844f18a@arm.com \ --to=robin.murphy@arm.com \ --cc=airlied@linux.ie \ --cc=alyssa@rosenzweig.io \ --cc=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=eric@anholt.net \ --cc=hanetzer@startmail.com \ --cc=iommu@lists.linux-foundation.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lyude@redhat.com \ --cc=maarten.lankhorst@linux.intel.com \ --cc=maxime.ripard@bootlin.com \ --cc=narmstrong@baylibre.com \ --cc=robh@kernel.org \ --cc=sean@poorly.run \ --cc=tomeu.vizoso@collabora.com \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.