Nice job!
Patches 1-2 are Acked-by: Alyssa Rosenzweig
Patch 3 is Reviewed-by: Alyssa Rosenzweig
Excited to see this mainlined!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 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...
> You probably want a dma_set_mask_and_coherent() call for your 'real' output
> address size
> + /*
> + * In v4 HW we have one tiler per core group, with the number
> + * of core groups being equal to the number of L2 caches. Other
> + * HW versions just have one tiler and the number of L2 caches
> + * can be extracted from the mem_features field.
> + */
> memcmp() does not account for the case where 2 jobs contain exactly the
> same perfmons but in a different order. This being said, it's rather
> unlikely to happen, so maybe we can accept the perf penalty for that
> case.
If you say so!
> Yes, all numbers above 0xfff are bifrost GPUs. I'll add
+1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> You can extend ioctl structs safely. When older userspace passes theirs
> in, it has the shorter length encoded in the cmd. The kernel allocates
> the newest version's space, copies in the shorter struct, and
> zero-extends the rest.
Understood, thank you!
> I'm also somewhat surprised that you don't need loads of other
> properties from the GPU - in particular knowing the number of shader
> cores is useful for allocating the right amount of memory for TLS (and
> can't be obtained purely from the GPU_ID).
Since I have no idea what TLS is (and in my
> Since one of the primary use cases is to draw pretty graphs of the
> system load [1], this "per-job" information isn't all that relevant (and
> minimal performance overhead is important). And if you want to monitor
> just one application it is usually easiest to ensure that it is the only
>
> Sorry - "Thread Local Storage" - e.g. registers spilled to memory from a
> shader program.
Gotcha, thank you. Register spilling isn't implemented yet, so I haven't
run into this. (Partially because the blob's RA is very good so it's
somewhat nontrivial to get it to spill... not that I've tried,
FORMAT_MOD_ARM_GPU(mode) \
> + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_DEVICE_GPU, mode)
> +
Although Utgard does not support AFBC, both Midgard and Bifrost natively
support AFBC for both texturing and rendering. Separating "AFBC" from
"GPU" is incorrect.
It's oka
> Then DRM_FORMAT_MOD_ARM_TYPE_GPU? I really don't know what's the
> official name for this kind of format, so have to name it with the
> device. Any better
> suggestion?
Maybe DRM_FORMAT_MOD_ARM_TYPE_TILED? I wonder if the Mali-DP folks have
a suggestion.
> Is tiled buffer rendering not reverse
> If you think Midgard/Bifrost is compatible with AFBC and don't have it's
> own format, and name "device" is improper, I can rename
> DRM_FORMAT_MOD_ARM_DEVICE_AFBC to DRM_FORMAT_MOD_ARM_TYPE_AFBC
> DRM_FORMAT_MOD_ARM_DEVICE_GPU to DRM_FORMAT_MOD_ARM_TYPE_UTGARD
That name is misleading, too.
> It was given to me and a bunch of other ARM kernel devs, but I think
> it was in production by then. It's an A01 rev which matches this:
>
> https://www.notebookcheck.net/Samsung-Chromebook-XE303C12-A01US.84022.0.html
>
> The only other rev is a UK version.
Wacky. Something seems decidedly
> bitmasks in the kernel use unsigned long arrays. A strange choice
> which I guess was either because it predated 64-bit or enables atomic
> ops which tend to be on the native size. So this just fixes the size
> to 64-bits for 32 and 64 bit systems.
Bizarre, but if that's the standard, then OK.
> We don't know if this is a "category" per-se, or just a single Utgard
> tiling format - as discussed I'm trying to get an answer for that.
FWIW, as I think I mentioned on an message, this format is used on
Midgard as well, and presumably also Bifrost.
On Midgard, when a texture is uploaded
> You might want to re-use the exisiting modifier
> AFBC_FORMAT_MOD_BLOCK_SIZE_16x16.
>
> I would suggest you to have a look at the exisiting AFBC modifiers
> (denoted by AFBC_FORMAT_MOD_XXX ) and let us know if there is
> something you cannot reuse.
So, the "tiled" format in question (that
Oh my onions, it's really here! It's really coming! It's really here!
> + DRM driver for ARM Mali Midgard (t6xx, t7xx, t8xx) and
> + Bifrost (G3x, G5x, G7x) GPUs.
Nitpick: the model names should maybe be capitalized? Or at least, the
T/G should be consistent? I'm not sure what
> 1. Does AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 without any
> AFBC_FORMAT_MOD_XXX uncompressed format just reorder the pixels
> in one 16x16 block same way as GPU "tiled" format? Or just no reorder
> (linear)?
>
> 2. Is there any unreleased AFBC_FORMAT_MOD_XXX bit for this GPU
> "tiled" format?
I
"AGTB" is jargon-y, but then again, so is "AFBC"... Unless Arm wants to
publish the actual name for the format, this works :)
Thank you for the clarification (in the other emails)
Reviewed-by: Alyssa Rosenzweig
___
dri-devel ma
> AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 denotes the superblock size to be
> used only in case of AFBC buffers.
> For non compressed tiled format, none of the AFBC_FORMAT_MOD_XXX
> should be used.
Alright, understood. Thank you for the clarification :)
___
> I really think to write a decent vulkan driver, you need to take
> arrays of in sync,
Vulkan? What's that? ;)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > Another one: What's the plan with extending this to panfrost? Or are the
> > architectures for command submission totally different, and we'll need
> > separate kernel drivers for utgard/midgard/bifrost?
> + Alyssa & Rob
> There is a gitlab issue about sharing kernel driver:
>
Acked-by: Alyssa Rosenzweig
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi all,
As Steven Price explained, the "GPU top" kbase approach is often more
useful and accurate than per-draw timing.
For a 3D game inside a GPU-accelerated desktop, the games' counters
*should* include desktop overhead. This external overhead does affect
the game's performance, especially if
Woohoo! Patches 1-3 are R-b; patch 4 is A-b. Exciting progress! Hoping
to hear what Rob and Steven think :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> This being said, I think I'll go for a simple debugfs-based iface to
> unblock Alyssa. debugfs is not part of the stable-ABI and I guess we
> can agree on explicitly marking it as "unstable" so that when we settle
> on a generic interface to expose such counters we can get rid of the
> old one.
Providing maintainers more aware of the substance review it and ok it,
patches 1-2 are:
Acked-by: Alyssa Rosenzweig
Patch 3 should be:
Reviewed-by: Alyssa Rosenzweig
> Since the same discussion is happening with etnaviv: Why exactly does mesa
> need to mmap imported buffers?
The golden question!
Seemingly, (one of the) reasons is that the state tracker does
colourspace conversion in software if the winsys wants a format that the
driver doesn't advertise.
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 feature. Most im
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
gt; 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.
>
> drive
for the 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
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
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
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
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
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 _panfrost_submit_bo_desc objects. This
> > +* field is meant to replace _panfrost_submit.bo_handles which did
> > +* not provide enough information to relax synchronization between
> > +* jobs that only only read the BO they share. When
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
> >
>
> 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
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, 15
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
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
> 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
> > 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
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
> @@ -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,
> >jobs[j]->file_priv->mmu);
>
> +/* 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
> > 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,
> #define PANFROST_BO_NOEXEC 1
> +#define PANFROST_BO_HEAP 2
Bikeshedding, but I don't like this name. There are, I think, multiple
GPU-mapped buffers (at least in Panfrost -- I don't know how the blob
manages memory) that can be considered heaps of sorts. Some of those are
just regular
> 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.
> While I agree an executable heap is pretty weird, I'd prefer making this
> explicit - i.e. failing the allocation if the flags don't make sense.
The only use case for an executable heap I can think of is an attacker
trying to exploit a GPU-side heap overflow, and that's seriously
stretching it
This patch is:
Acked-by: Alyssa Rosenzweig
On Wed, Jul 17, 2019 at 12:33:50PM -0600, Rob Herring wrote:
> Executable buffers have an alignment restriction that they can't cross
> 16MB boundary as the GPU program counter is 24-bits. This restriction is
> currently not handled an
> A fair bit of the complexity of kbase comes from trying to avoid the
> possibility of one process DoSing another by submitting malicious jobs.
...and yet it was still doable so easily (by accident, with buggy jobs
instead of malicious jobs) sigh...
Still is on the mainline kernel (e.g.
> Seems like almost 4GB executable
> buffer should be enough for anyone(TM).
(TM) indeed. For stats, Panfrost right now uses a single 16MB shader
buffer per context and never reallocates.
I have never seen it run out of space, not even once on a conformance
test.
Mali shader binaries are small
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
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-ne
> 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
> 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
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.
>
>
> 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
> (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
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
> &
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
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
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()). Howev
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 be the
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 when running
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
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 kernel wa
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
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-off-b
> + 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
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 MT-specific
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
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
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
A-b
On Fri, May 22, 2020 at 04:36:53PM +0100, Steven Price wrote:
> The calls to panfrost_devfreq_record_busy() and
> panfrost_devfreq_record_idle() must be balanced to ensure that the
> devfreq utilisation is correctly reported. But there are two cases where
> this doesn't work correctly.
>
>
Reviewed-by: Alyssa Rosenzweig
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
> b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> index e0f190e43813..6d17d3cbd1df 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> @@ -30
Reviewed-by: Alyssa Rosenzweig
> This adds the required GPU quirks, including the quirk in the PWR registers
> at the GPU
> reset time and the IOMMU quirk for shareability issues observed on G52 in
> Amlogic G12B SoCs.
>
> Signed-off-by: Neil Armstrong
> ---
>
> Since the documentation of the GPU cores are not public, we do not know what
> does these
> values, but they permit having a fully functional GPU running with Panfrost.
Since this is Amlogic magic, not specifically GPU, I'd rephrase this as
"Since the Amlogic's integration of the GPU cores
> So I get a performance regression with the dma-coherent approach, even if it's
> clearly the cleaner.
That's bizarre -- this should really be the faster of the two.
signature.asc
Description: PGP signature
___
dri-devel mailing list
series r-b, nice!
On Wed, Sep 16, 2020 at 05:01:44PM +0200, Neil Armstrong wrote:
> The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM,
> G12A/SM1 & G12B
> SoCs needs a quirk in the PWR registers at the GPU reset time.
>
> This serie adds the necessary quirks for the Amlogic
Series is:
Acked-by: Alyssa Rosenzweig
On Tue, Sep 22, 2020 at 03:16:47PM +0100, Robin Murphy wrote:
> Hi all,
>
> Here's a quick v2 with the tags so far picked up and some inline
> commentary about the shareability domains for the pagetable code.
>
> Robin.
>
> The DDK blob has the ability to mark only certain areas of memory as
> coherent for performance reasons. For simple things like kmscube I would
> expect that it's basically write-only from the CPU and almost all memory the
> GPU touches isn't touched by the CPU. I.e. coherency isn't helping and
Reviewed-by: Alyssa Rosenzweig
On Wed, May 27, 2020 at 10:05:44PM +0200, Krzysztof Kozlowski wrote:
> There is no point to print deferred probe (and its failures to get
> resources) as an error. Also there is no need to print regulator errors
> twice.
>
> In case of multi
to bring-up of AFBC in Mesa
(in the Panfrost driver), no open userspace respected modifier
reporting. As such, this change is not expected to affect broken
userspaces.
Tested on RK3399 with Panfrost and Weston.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 11
> ...and in merging my code with Alyssa's new panfrost format modifier
> support, I see panfrost does the opposite of this and treats a format
> modifier list of only INVALID as "don't care". I modeled the new nouveau
> behavior on the Iris driver. Now I'm not sure which is correct :-(
and
Acked-by: Alyssa Rosenzweig
On Sun, Jun 14, 2020 at 01:27:30AM -0500, Navid Emamdoost wrote:
> in panfrost_job_hw_submit, pm_runtime_get_sync is called which
> increments the counter even in case of failure, leading to incorrect
> ref count. In case of failure, decrement the ref cou
Acked-by: Alyssa Rosenzweig
On Sun, Jun 14, 2020 at 01:36:19AM -0500, Navid Emamdoost wrote:
> in panfrost_perfcnt_enable_locked, pm_runtime_get_sync is called which
> increments the counter even in case of failure, leading to incorrect
> ref count. In case of failure, decrement the
Patches 1-12 are
Reviewed-by: Alyssa Rosenzweig
Thank you!
On Sat, Jul 04, 2020 at 12:25:21PM +0200, Clément Péron wrote:
> Hi,
>
> This serie cleans and adds regulator support to Panfrost devfreq.
> This is mostly based on comment for the freshly introduced lima
> d
Both patches are Reviewed-by: Alyssa Rosenzweig
On Thu, Jun 11, 2020 at 10:58:43AM +0200, Tomeu Vizoso wrote:
> Bifrost devices do support the flush reduction feature, so on first job
> submit we were trying to read the register while still powered off.
>
> If the GPU is
> Add support for MT8183's G-57 Bifrost.
G72
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> GPUs with more than a single regulator (e.g. G-57 on MT8183) will
G72
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Panfrost hunks
Acked-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
> + /* Right now, none of the GPU we support need a reset, but this
> + * might change (e.g. Valhall GPUs require a when a BUS_FAULT occurs).
s/a/one/
> Jobs can be in-flight when the file descriptor is closed (either because
> the process did not terminate properly, or because it didn't wait for
> all GPU jobs to be finished), and apparently panfrost_job_close() does
> not cancel already running jobs. Let's refcount the MMU context object
> so
> Also that feature was only introduced in t76x. So relying on that would
> sadly kill off support for t60x, t62x and t72x (albeit I'm not sure how
> 'supported' these are with Mesa anyway).
t60x and t62x are not supported, but t720 very much is (albeit GLES2
only, versus t760+ getting GLES3.1
1 - 100 of 242 matches
Mail list logo
