> User space shouldn't care too much - other than the size of buffers
> allocated being rounded up to the CPU's page size. At least the Panfrost
> user/kernel ABI has sizes in bytes not pages (unlike kbase).
We've been rounding everything up to the nearest 4k in mesa, out of old
habit from kbase.
This is definitely helpful!
My one concern is, supposing userspace really does need all of this
information, is it wasteful to have to do 30+ ioctls just to get this?
kbase had a single ioctl to grab all of the properties, whether
userspace wanted them or not. I'm not sure if that's better -- the
> I think this ship already sailed when we added the first one with
> GPU_ID. Also, at least etnaviv works the same way.
Fair enough then!
Reviewed-by: Alyssa Rosenzweig
signature.asc
Description: PGP signature
> Sorry, I was being sloppy again![1] I meant CPU mmapped.
No worries, just wanted to check :)
> Apparently the blob in some cases creates a SAME_VA GROW_ON_GPF buffer -
> since SAME_VA means permanently mapped on the CPU this translated to
> mmapping a HEAP object. Why it does this I've no idea
> Either we should prevent mapping of HEAP objects
I'm good with that. AFAIK, HEAP objects shouldn't be (CPU) mmapped
anyway in normal use; if you need them mapped (for debugging etc), it's
no big deal to just.. not set the HEAP flag in debug builds.
Or do you mean GPU mapping?
signature.asc
De
This series is:
Acked-by: Alyssa Rosenzweig
On Wed, Jul 24, 2019 at 07:09:56PM -0600, Rob Herring wrote:
> This series adds new BO allocation flags PANFROST_BO_HEAP and
> PANFROST_BO_NOEXEC. The heap allocations are paged in on GPU page faults.
>
> This is based on drm-misc-next.
So on 64 bit user space we upgrade everything to
> be SAME_VA - which means the GPU VA space just follows the CPU VA (similar
> to HMM).
I'll let Rob chime in on this one. Thank you for the detailed write-up!
-Alyssa
signature.asc
Description: PGP signature
___
> In any case, per process AS is a prerequisite to all this.
Oh, I hadn't realized that was still a todo. In the meantime, what's the
implication of shipping without it? (I.e. in which threat model are
users vulnerable without it?) Malicious userspace process snooping on
other framebuffers (on X11
at just represents a number. Using the
numbers directly means we can compare them in a natural way. Also, using
a major/minor split like Steven suggested can help with semantic
versioning.
Cheers,
Alyssa
>drivers/gpu/drm/panfrost/panfrost_dump.c: In function 'panfrost_core_dump':
> >> drivers/gpu/drm/panfrost/panfrost_dump.c:115:20: error: 'struct
> >> panfrost_job' has no member named 'file_priv'
> 115 | as_nr = job->file_priv->mmu->as;
> |^~
FWIW --
Hi Rong Chen,
Sorry for the noise -- I think that was meant for Adrian!
Apologies,
Alyssa
On Wed, Jun 22, 2022 at 10:30:00AM +0800, Chen, Rong A wrote:
>
>
> On 6/21/2022 10:32 PM, Alyssa Rosenzweig wrote:
> > > drivers/gpu/drm/panfrost/panfrost_d
> > > + iter.start = __vmalloc(file_size, GFP_KERNEL | __GFP_NOWARN |
> > > + __GFP_NORETRY);
> > > + if (!iter.start) {
> > > + dev_warn(pfdev->dev, "failed to allocate devcoredump file\n");
> > > + return;
> > > + }
> > > ...
> > > + memset(iter.hdr, 0, iter.data -
> + js_as_offset = slot * 0x80;
JS_SLOT_STRIDE
> + slot = panfrost_job_get_slot(job);
> + slot = slot ? slot : 0;
`slot = slot ? slot : 0` is a no-op. Delete the line.
> + if (!IS_ERR(page))
> + *bomap++ = cpu_to_le64(p
x27;t seem big on unsigned, if this were
mesa it would return unsigned. Returning u8 or u32 seems reasonable at
any rate.
> >As a general note, I'd appreciate breaking out the panfrost_regs.h
> >changes into a separate patch, as they are a logically separate clean
> >up to make room for this patch. Thanks.
>
> Done in v4.
Thanks!
Alyssa
Reviewed-by: Alyssa Rosenzweig
On Wed, Jun 22, 2022 at 03:36:15PM +0100, Adri??n Larumbe wrote:
> Each Panfrost job has its own job slot and MMU address space set of
> registers, which are selected with a job-specific index.
>
> Turn the shift and stride used for selection of the ri
From: Alyssa Rosenzweig
The IDVS group size feature was missing. It is used on some Bifrost and
Valhall GPUs, and is the last kernel-relevant Bifrost feature we're
missing.
This feature adds an extra IDVS group size field to the JM_CONFIG
register. In kbase, the value is configurable vi
From: Alyssa Rosenzweig
This patch series adds preliminary support for Mali "Valhall" GPUs into
the Panfrost kernel driver. The series has been tested on the Mali-G57
on a MediaTek MT8192 system. However, that system requires additional
MediaTek-specific patches [1] as well as core
From: Alyssa Rosenzweig
>From the kernel's perspective, pre-CSF Valhall is more or less
compatible with Bifrost, although they differ to userspace. Add a
compatible for Valhall to the existing Bifrost bindings documentation.
Signed-off-by: Alyssa Rosenzweig
Cc: devicet...@vger.ke
From: Alyssa Rosenzweig
Logically, this function is free of side effects, so any pointers it
takes should be const. Needed to avoid a warning in the next patch.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_issues.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion
From: Alyssa Rosenzweig
Some Valhall GPUs require resets when encountering bus faults due to
occlusion query writes. Add the issue bit for this and handle it.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_device.c | 9 +++--
drivers/gpu/drm/panfrost
From: Alyssa Rosenzweig
TTRX_3485 requires the infamous "dummy job" workaround. I have this
workaround implemented in a local branch, but I have not yet hit a case
that requires it so I cannot test whether the implementation is correct.
In the mean time, add the quirk bit so we ca
From: Alyssa Rosenzweig
Add handling for the HW_ISSUE_TTRX_2968_TTRX_3162 quirk. Logic ported
from kbase. kbase lists this workaround as used on Mali-G57.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_gpu.c| 3 +++
drivers/gpu/drm/panfrost/panfrost_issues.h | 3
From: Alyssa Rosenzweig
L2_MMU_CONFIG is an implementation-defined register. Different Mali GPUs
define slightly different MAX_READS and MAX_WRITES fields, which
throttle outstanding reads and writes when set to non-zero values. When
left as zero, reads and writes are not throttled.
Both kbase
From: Alyssa Rosenzweig
Add the HW_FEATURE_CLEAN_ONLY_SAFE bit based on kbase. When I actually
tried to port the logic from kbase, trivial jobs raised Data Invalid
Faults, so this may depend on other coherency details. It's still useful
to have the bit to record the feature bit when addin
From: Alyssa Rosenzweig
Add the features, issues, and GPU ID for Mali-G57, a first-generation
Valhall GPU. Other first- and second-generation Valhall GPUs should be
similar.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_features.h | 12
drivers/gpu/drm
From: Alyssa Rosenzweig
The most important Valhall-specific quirks have been handled, so add the
Valhall compatible and probe.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panfrost
> > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> > b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> > index 63a08f3f321d..48aeabd2ed68 100644
> > --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> > +++ b/Documentation/devicetree/bindin
re bit when adding new models.
> >
> > Signed-off-by: Alyssa Rosenzweig
>
> Reviewed-by: Steven Price
>
> Sadly I don't have the hardware to try this out on, but it should be a
> simple case of the below (untested):
>
> 8<
> diff --gi
> > index b8865fc9efce..1a0dc7f7f857 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_issues.h
> > +++ b/drivers/gpu/drm/panfrost/panfrost_issues.h
> > @@ -258,6 +258,11 @@ enum panfrost_hw_issue {
> >
> > #define hw_issues_g76 0
> >
> > +#define hw_issues_g57 (\
> > + BIT_ULL(HW_ISSUE_TTR
On Mon, Feb 14, 2022 at 04:23:18PM +, Steven Price wrote:
> On 11/02/2022 20:27, alyssa.rosenzw...@collabora.com wrote:
> > From: Alyssa Rosenzweig
> >
> > Some Valhall GPUs require resets when encountering bus faults due to
> > occlusion query writes. Add the is
> > TTRX_3485 requires the infamous "dummy job" workaround. I have this
> > workaround implemented in a local branch, but I have not yet hit a case
> > that requires it so I cannot test whether the implementation is correct.
> > In the mean time, add the quirk bit so we can document which platforms
-MediaTek devices, this saves a small amount of memory.
Suggested-by: AngeloGioacchino Del Regno
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_device.c | 14 ++
drivers/gpu/drm/panfrost/panfrost_device.h | 5 ++---
2 files changed, 12 insertions(+), 7 deletions
mali_kbase hardcodes MAX_PM_DOMAINS (=5 for the mt8192 kernel). I have
no real objection to it but Angelo did. Maybe should've marked this RFC.
On Mon, Feb 14, 2022 at 03:31:32PM -0500, Alyssa Rosenzweig wrote:
> MT8192 requires 5 power domains. Rather than bump MAX_PM_DOMAINS and
> w
> I'd do the oneliner changing it to 5 and be done with it. That being
> said, we have plenty of examples of doing this both ways, so whatever
> makes people happy.
Excellent, that's the patch I wrote originally :-)
Dropping this patch, unless Angelo (or someone else) strongly objects.
> -static size_t get_pgsize(u64 addr, size_t size)
> +static size_t get_pgsize(u64 addr, size_t size, size_t *count)
> {
> - if (addr & (SZ_2M - 1) || size < SZ_2M)
> - return SZ_4K;
> + size_t blk_offset = -addr % SZ_2M;
addr is unsigned. if this is correct, it's magic.
Acked-by: Alyssa Rosenzweig
n MediaTek integration issues.)
In terms of userspace, Mesa has almost all the required code for GLES3.1
conformance and is just missing a few patches to merge for remaining
features.
v2 addresses minor issues found in v1, but no major changes.
Alyssa Rosenzweig (9):
dt-bindings: Add compatible
rt, add a
specific compatible for the MediaTek MT8192, which instantiates a
Mali-G57.
v2: Change compatible to arm,mali-valhall-jm (Daniel Stone).
Signed-off-by: Alyssa Rosenzweig
CC: devicet...@vger.kernel.org
---
.../bindings/gpu/arm,mali-bifrost.yaml| 25 +++
Logically, this function is free of side effects, so any pointers it
takes should be const. Needed to avoid a warning in the next patch.
Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_issues.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Some Valhall GPUs require resets when encountering bus faults due to
occlusion query writes. Add the issue bit for this and handle it.
Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.c | 9 +++--
drivers/gpu/drm/panfrost
Add handling for the HW_ISSUE_TTRX_2968_TTRX_3162 quirk. Logic ported
from kbase. kbase lists this workaround as used on Mali-G57.
Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_gpu.c| 3 +++
drivers/gpu/drm/panfrost/panfrost_issues.h | 3
o new
Mali GPUs, which have different layouts for the L2_MMU_CONFIG register.
Signed-off-by: Alyssa Rosenzweig
Suggested-by: Steven Price
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/dr
ff-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_features.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_features.h
b/drivers/gpu/drm/panfrost/panfrost_features.h
index 36fadcf9634e..1a8bdebc86a3 100644
--- a/drivers/gp
TTRX_3485.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_features.h | 12
drivers/gpu/drm/panfrost/panfrost_gpu.c | 3 +++
drivers/gpu/drm/panfrost/panfrost_issues.h | 9 +
3 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm
The most important Valhall-specific quirks have been handled, so add the
Valhall compatible and probe.
v2: Use arm,mali-valhall-jm compatible.
Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
1 file changed, 1 insertion(+)
diff
need it in the future.
Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_issues.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_issues.h
b/drivers/gpu/drm/panfrost/panfrost_issues.h
index e35807e4b743..4d
Acked-by: Alyssa Rosenzweig
On Fri, May 27, 2022 at 02:50:40AM +0300, Dmitry Osipenko wrote:
> Replace Panfrost's memory shrinker with a generic drm-shmem memory
> shrinker.
>
> Tested-by: Steven Price
> Signed-off-by: Dmitry Osipenko
> ---
> drivers
Acked-by: Alyssa Rosenzweig
On Fri, May 27, 2022 at 02:50:22AM +0300, Dmitry Osipenko wrote:
> Calling madvise IOCTL twice on BO causes memory shrinker list corruption
> and crashes kernel because BO is already on the list and it's added to
> the list again, while BO should be rem
On Tue, Aug 23, 2022 at 11:42:33AM +0100, Robin Murphy wrote:
> On 2022-08-23 03:51, Alyssa Rosenzweig wrote:
> > > -static size_t get_pgsize(u64 addr, size_t size)
> > > +static size_t get_pgsize(u64 addr, size_t size, size_t *count)
> > > {
> > > -
Have we checked that this actually fixes the Mesa build? If so, R-b.
> Commit 730c2bf4ad39 ("drm/panfrost: Add support for devcoredump")
> introduces one such union, breaking the Mesa build.
>
> Give it a name, and also rename pan_reg_hdr structure because it will
> always be prefixed by the unio
ps://gitlab.freedesktop.org/mesa/mesa/-/issues/7195
> >>>
> >>> Signed-off-by: Adri??n Larumbe
> >
> >> Ouch! It's frustrating how C++ isn't quite a superset of C. However I
> >> think we can solve this with a simpler patch, I'd appre
Tentative r-b, but we *do* need to make a decision on how we want to
handle endianness. I don't have strong feelings but the results of that
discussion should go in the commit message.
On Tue, Sep 20, 2022 at 10:15:45PM +0100, Adri??n Larumbe wrote:
> __le32 and __l64 endian-specific types aren't
> > Or of course we could just actually use native endian and detect from
> > the magic which endian is in use. That would require ripping out the
> > cpu_to_lexx() calls in Linux and making the user space tool more
> > intelligent. I'm happy with that, but it's pushing the complexity onto Mesa.
>
Reviewed-by: Alyssa Rosenzweig
On Fri, Jul 29, 2022 at 03:46:09PM +0100, Adri??n Larumbe wrote:
> Each Panfrost job has its own job slot and MMU address space set of
> registers, which are selected with a job-specific index.
>
> Turn the shift and stride used for selection of the ri
On Fri, Dec 13, 2019 at 03:31:45PM +, Robin Murphy wrote:
> On 13/12/2019 2:32 pm, Alyssa Rosenzweig wrote:
> > > TBH it would probably be sufficient to save the bother of allocating
> > > strings and just settle on "panfrost-{gpu,job,mmu}", since upstream
> &
> TBH it would probably be sufficient to save the bother of allocating
> strings and just settle on "panfrost-{gpu,job,mmu}", since upstream
> users are unlikely to ever come across a system with more than one
> Mali in it ;)
Agreed.
Wait, you said *upstream*? Are there oh no
signature
> (Feedback for kernel patches on the same day, am I dreaming??)
That's panfrost!
> > Agreed, while the current implementation may be confusing it is at least
> > self-consistent. TBH it would probably be sufficient to save the bother
> > of allocating strings and just settle on "panfrost-{gpu,
Reviewed-by: Alyssa Rosenzweig
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
If so much code is being duplicated over, I'm wondering if it makes
sense for us to move some of the common devfreq code to core DRM
helpers?
On Sun, Dec 15, 2019 at 10:12:22PM +0100, Martin Blumenstingl wrote:
> This is my attempt at adding devfreq (and cooling device) support to
> the lima drive
Patches 1,2,3,6 are:
Reviewed-by: Alyssa Rosenzweig
The remaining patches in the series are Acked-by.
Reportedly the kernel should work on certain Bifrost boards more or less
as-is, but I'm not positive about the details. It's possible some of
these are G72-specific or M
A-b
On Thu, Jan 09, 2020 at 01:31:04PM +, Steven Price wrote:
> Explict management of the GPU's core stacks is only necessary in the
> case of a broken integration with the PDC. Since there are no known
> platforms which have such a broken integration let's remove the explict
> control from th
> + for (i = 0; i < ARRAY_SIZE(pfdev->pm_domain_devs); i++) {
> + if (!pfdev->pm_domain_devs[i])
> + break;
I'm not totally familiar with this code, but should this be a break or
just a continue?
signature.asc
Description: PGP signature
__
Acked-by: Alyssa Rosenzweig
On Wed, Feb 12, 2020 at 02:22:36PM -0600, Rob Herring wrote:
> From: Tomeu Vizoso
>
> If the exception type isn't a translation fault, don't try to map and
> instead go straight to a terminal fault.
>
> Otherwise, we can get flooded by
Reviewed-by: Alyssa Rosenzweig
On Fri, Feb 28, 2020 at 10:40:26AM +0100, Marek Szyprowski wrote:
> Signed-off-by: Marek Szyprowski
> ---
> v2:
> - fixed build warning
> ---
> drivers/gpu/drm/panfrost/panfrost_device.c | 26 +++---
> 1 file changed, 18 inser
Series has my r-b :)
On Fri, Mar 06, 2020 at 12:13:41PM +0800, Nicolas Boichat wrote:
> Hi!
>
> Follow-up on the v4: https://patchwork.kernel.org/cover/11369777/, some
> of the core patches got merged already (thanks Rob!).
>
> The main purpose of this series is to upstream the dts change and th
Reviewed-by: Alyssa Rosenzweig
On Wed, Mar 18, 2020 at 11:45:48AM +, Lukasz Luba wrote:
> Register devfreq cooling device and attempt to register Energy Model. This
> will add the devfreq device to the Energy Model framework. It will create
> a dedicated and unified data structures
Reviewed-by: Alyssas Rosenzweig , thank
you!
On Mon, Feb 03, 2020 at 03:27:24PM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/panfrost/panfrost_job.c: In function 'panfrost_job_cleanup':
> drivers/gpu/drm/panfrost/panfrost_job.c:278:31: warning:
>
Patch 2 is `Reviewed-by: Alyssa Rosenzweig
`
On Tue, Feb 04, 2020 at 03:35:04PM +0100, Boris Brezillon wrote:
> ->job_run() can return an ERR_PTR() if somethings fails. Let's
> propagate the error returned by panfrost_fence_create() instead of
> returning NULL.
>
> Signed-
Reviewed-by: Alyssa Rosenzweig
Although it might be nice to
#define TRANSLATION_FAULT_LEVEL1 0xC1
...
#define TRANSLATION_FAULT_LEVEL4 0xC4
and then use semantic names instead of magic values. Minimally maybe add
a comment explaining that.
On Wed, Feb 05, 2020 at 11
I'm conflicted on this series.
On the one hand, userspace should obviously not be able to crash the
kernel. So the crash should be fixed in one way or another.
On the other hand, userspace really has to supply all the BOs it uses
for correctness. I realize the DDK doesn't do this but... it probab
Patch 1 is:
Acked-by: Alyssa Rosenzweig
Patch 2 is:
Reviewed-by: Alyssa Rosenzweig
Good stuff as always!
On Thu, Sep 12, 2019 at 12:28:04PM +0100, Steven Price wrote:
> Instead of tracking per-slot utilisation track a single value for the
> entire GPU. Ultimately it d
> > + /**
> > +* Pointer to a u32 array of &drm_panfrost_submit_bo_desc objects. This
> > +* field is meant to replace &drm_panfrost_submit.bo_handles which did
> > +* not provide enough information to relax synchronization between
> > +* jobs that only only read the BO they share
Alright; I'm not familiar with patchwork but sounds good.
On Mon, Sep 16, 2019 at 05:36:24PM -0500, Rob Herring wrote:
> On Fri, Sep 13, 2019 at 12:43 PM Alyssa Rosenzweig
> wrote:
> >
> > Patch 1 is:
> >
> > Acked-by: Alyssa Rosenzweig
> >
&g
Reviewed-by: Alyssa Rosenzweig
On Mon, Nov 18, 2019 at 05:30:02PM +, Steven Price wrote:
> Currently when setting a frequency in panfrost_devfreq_target the
> returned frequency is the actual frequency that the clock driver reports
> (the return of clk_get_rate()). However,
Reviewed-by: Alyssa Rosenzweig
On Fri, Nov 29, 2019 at 02:56:14PM +0100, Boris Brezillon wrote:
> I've spent hours chasing a memory corruption that was caused by
> insertion of an extra field field before ->base. Let's document the
> fact that base has to
Series acked-by: Alyssa Rosenzweig
On Fri, Nov 29, 2019 at 02:59:00PM +0100, Boris Brezillon wrote:
> Hello,
>
> I've recently come to test a 5.4 kernel on a rk3288 platform (T760),
> and, as reported by many people on #panfrost, I've hit a page-fault
> storm whe
Not sure if this was already pushed but:
Acked-by: Alyssa Rosenzweig
On Thu, Nov 28, 2019 at 08:54:27PM +, Robin Murphy wrote:
> When we have devfreq, also try to register a basic cooling device in
> case GPU workloads manage to hit thermal throttling thresholds.
>
> S
Pardon the pun, but
Reviewed-by: Alyssa Rosenzweig
(or a-b if you prefer, of course!)
On Thu, Aug 22, 2019 at 08:33:57PM -0500, Rob Herring wrote:
> Add Steven Price and Alyssa Rosenzweig as reviewers as they have been the
> primary reviewers already.
>
> Cc: Steven Price
handled, adding descriptions based on the
workarounds in the latest kbase release.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_issues.h | 81 ++
1 file changed, 81 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_issues.h
b/drivers/gpu
A-b from me; let's see what others say.
On Mon, Aug 26, 2019 at 05:33:09PM -0500, Rob Herring wrote:
> With further testing of recent changes with lockdep identified some
> locking issues. Avoiding lockdep issues means we need to avoid some
> locks in panfrost_mmu_unmap which in turn means avoidin
e the MMU interrupts locally.
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
> ---
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 20 +++-
> 1 file changed,
> > Just to clarify about the `retained` flag: if userspace does a
> > madvise(WILLNEED) and we find out that retained=0, what's supposed to
> > happen?
> >
> > Should userspace evict the BO from its local cache and allocate one
> > fresh?
>
> Yes. Just like msm/freedreno.
Got it. In that case, t
> +/* madvise provides a way to tell the kernel in case a buffers contents
> + * can be discarded under memory pressure, which is useful for userspace
> + * bo cache where we want to optimistically hold on to buffer allocate
> + * and potential mmap, but allow the pages to be discarded under memory
> > It's not obvious to me when it actually needs to be enabled. Besides the
> > errata, it's only when... device_nr=1 for a compute-only job in kbase?
> >
> > I'm afraid I don't know nearly enough about how kbase plumbs CL to grok
> > the signifiance...
>
> Figuring out the nr_core_groups was the
> Why don't we just go ahead and enable JS2?
It's not obvious to me when it actually needs to be enabled. Besides the
errata, it's only when... device_nr=1 for a compute-only job in kbase?
I'm afraid I don't know nearly enough about how kbase plumbs CL to grok
the signifiance...
signature.asc
D
are unknown as they were not
added to kbase until after kbase began stripping these comments.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_issues.h | 80 ++
1 file changed, 80 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_issues.h
b
this hint.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/TODO | 3 ---
drivers/gpu/drm/panfrost/panfrost_job.c | 4 +++-
include/uapi/drm/panfrost_drm.h | 8
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/TODO b
Ah-ha! Thank you for the detailed explanation; this makes a lot more
sense now :)
> In practice all this only really matters on the T62x GPU. All other GPUs
> have only one core group[1]. So it only really makes sense to use JS2 on
> the T62x where you want to use both JS1 and JS2 to run two indep
> @@ -448,6 +453,7 @@ static irqreturn_t panfrost_job_irq_handler(int irq, void
> *data)
> }
>
> if (status & JOB_INT_MASK_DONE(j)) {
> + panfrost_mmu_as_put(pfdev,
> &pfdev->jobs[j]->file_priv->mmu);
> panfrost_devfreq_recor
some
> re-initialization on reset, so rework its call. In the process, we
> hide the address space details within the MMU code in preparation to
> support multiple address spaces.
>
> Cc: Tomeu Vizoso
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Robin Murphy
> Cc: Steven Pric
s.
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Reviewed-by: Steven Price
> Acked-by: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
> ---
> Steven, Alyssa, I kept your tags, but please take another look as things
> moved around a bit here.
>
&
workaround of an issue whose cause is
still unknown (Stephen). Errata which pertain to newer models
unsupported by the mainline driver, for which Arm has not yet released
errata information, have been removed from the issue list as the kernel
need not concern itself with these.
Signed-off-by: Alyssa
Acked-by: Alyssa Rosenzweig
On Tue, Aug 13, 2019 at 09:01:15AM -0600, Rob Herring wrote:
> Up until now, a single shared GPU address space was used. This is not
> ideal as there's no protection between processes and doesn't work for
> supporting the same GPU/CPU VA featur
From: Alyssa Rosenzweig
Mali has hardware cycle counters (and GPU timestamps) available for
profiling. These are exposed in various ways:
- Kernel: As CYCLE_COUNT and TIMESTAMP registers
- Job chain: As WRITE_VALUE descriptors
- Shader (Midgard): As LD_SPECIAL selectors
- Shader (Bifrost): As
From: Alyssa Rosenzweig
Add additional values of GPU_COMMAND required to enable and disable the
cycle (and timestamp) counters. Values from mali_kbase.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_regs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers
From: Alyssa Rosenzweig
Extend the Panfrost UABI with a new job requirement for cycle counters
(and GPU timestamps, by extension). This requirement is used in
userspace to implement ARB_shader_clock, an OpenGL extension reporting
the GPU cycle count within a shader. The same mechanism will be
From: Alyssa Rosenzweig
Wrap the underlying CYCLE_COUNT_START/STOP commands in a safe interface
that ensures the commands are only issued where required by guarding
behind an atomic counter. In particular, we need to be careful about
races between multiple in-flight jobs, where only some require
From: Alyssa Rosenzweig
If a job requires cycle counters or timestamps, we must enable cycle
counting just before issuing the job, and disable as soon as the job
completes.
Since this extends the UABI, we bump the driver minor version and date.
That lets userspace detect cycle counter support
> The main outstanding questing is the proper name. Performance monitoring
> ("PERMON") is the name used by kbase, but it's jargon-y and risks
> confusion with performance counters, an orthogonal mechanism. Cycle
> count is more descriptive and matches the actual hardware name, but
> obscures that
se an ioctl for that instead.
For anything implemented as WRITE_VALUE jobs, this is necessary and
sufficient on the kernel side. If an out-of-band soft job or ioctl is
truly needed (I haven't looked), of course that needs additional piping.
Thanks,
Alyssa
101 - 200 of 323 matches
Mail list logo
