601315
Best regards,
--
Alyssa Rosenzweig
tbdrm depend on X86
commit: de5fbbe1531f645c8b56098be8d1faf31e46f7f0
Best regards,
--
Alyssa Rosenzweig
verse host ordering.
> It makes the 4 variants [hnbl] consistent with the generic printing
> of IPv4 addresses.
>
> [...]
Applied, thanks!
[1/1] vsprintf: Use %p4chR instead of %p4cn for reading data in reversed host
ordering
commit: 37eed892cc5ff36aeee59bb78f6aa417a44030a9
Best regards,
--
Alyssa Rosenzweig
> DRM drivers are selecting drm helpers so do the same for
> DRM_DEBUG_DP_MST_TOPOLOGY_REFS.
> Fixes following circular dependency reported on x86 for the downstream
> Asahi Linux tree:
>
> [...]
Applied, thanks!
[1/1] drm: Select DRM_KMS_HELPER from DRM_DEBUG_DP_MST_TOPOL
p: Remove pointless irq_lock spin lock
(no commit info)
Best regards,
--
Alyssa Rosenzweig
Le Tue, Apr 29, 2025 at 01:39:43PM +0200, Petr Mladek a écrit :
> On Mon 2025-04-28 22:38:13, Aditya Garg wrote:
> >
> >
> > On 28-04-2025 10:30 pm, Alyssa Rosenzweig wrote:
> > > Acked-by: Alyssa Rosenzweig
> > >
> > > Since the other patc
Acked-by: Alyssa Rosenzweig
Since the other patches went thru drm-misc-next, I guess this should
too?
Le Mon , Apr 28, 2025 at 02:31:32PM +0200, Petr Mladek a écrit :
> The generic FourCC format always prints the data using the big endian
> order. It is generic because it allows to re
Reviewed-by: Alyssa Rosenzweig
Le Mon , Apr 28, 2025 at 01:37:14PM +0200, Janne Grunau via B4 Relay a écrit :
> From: Janne Grunau
>
> drm_crtc_vblank_get() may fail when it's called before
> drm_crtc_vblank_on() on a resetted CRTC. This occurs in
> drm_crtc_helper_funcs&#
> BTW, is there a piece of doc explaining the rational behind this
> dma_fence contract, or is it just the usual informal knowledge shared
> among DRM devs over IRC/email threads :-) ?
>
> To be honest, I'm a bit unhappy with this "it's part of the dma_fence
> contract" explanation, because I have
Steven wanted non-Mali eyes, so with my Imaginapple hat on...
> +All lot of embedded GPUs are using tile-based rendering instead of immediate
s/All lot of/Many/
> +- Complex geometry pipelines: if you throw geometry/tesselation/mesh shaders
> + it gets even trickier to guess the number of primi
This needs your Signed-off-by too as you are the submitter
Le Tue, Apr 22, 2025 at 01:41:52PM -0300, Daniel Almeida a écrit :
> From: Asahi Lina
>
> This is just for basic usage in the DRM shmem abstractions for implied
> locking, not intended as a full DMA Reservation abstraction yet.
>
> Sign
etbdrm: use %p4cl instead of %p4cc
commit: a49ce9cc85a82d5c5d65186f5a8fda0ebfcff571
Best regards,
--
Alyssa Rosenzweig
> Any change needed or just because some other maintainer manages this?
> Although Tbh, I really don't care about backporting since T2 Mac users are
> still using patched kernels provided by us. I'd rather free my mind in
> getting this done.
I'm just too new to kernel to do nontrivial merges.
I didn't realize this was so subtle with the backporting. I don't think
I can take this on, sorry.
Le Mon, Apr 21, 2025 at 06:40:23PM +0530, Aditya Garg a écrit :
>
>
> On 21-04-2025 06:38 pm, Aditya Garg wrote:
> >
> >
> > On 21-04-2025 06:37 pm, Alyssa
> On 21-04-2025 05:35 pm, Alyssa Rosenzweig wrote:
> >> Can I have a feedback from some DRM maintainer on this? AFAIK merge window
> >> is over for some time now. It's been more than a week and last time when I
> >> submitted, it just stayed in the mailing list
> Can I have a feedback from some DRM maintainer on this? AFAIK merge window is
> over for some time now. It's been more than a week and last time when I
> submitted, it just stayed in the mailing list without any feedback.
DRM hides the merge window from committers so that's not super relevant.
Reviewed-by: Alyssa Rosenzweig
Le Wed , Apr 16, 2025 at 10:25:27PM +0200, Janne Grunau via B4 Relay a écrit :
> From: Janne Grunau
>
> The lock is used in the interrupt handler so use spin_lock_irqsave to
> disable interrupts and avoid deadlocks with the irq handler.
>
> F
Reviewed-by: Alyssa Rosenzweig
Le Wed , Apr 16, 2025 at 10:25:30PM +0200, Janne Grunau via B4 Relay a écrit :
> From: Janne Grunau
>
> Interrupt handlers run with interrupts disabled so it is not necessary
> to protect them against reentrancy.
>
> Signed-off-by: Janne Grunau
Reviewed-by: Alyssa Rosenzweig
Le Wed , Apr 16, 2025 at 10:25:29PM +0200, Janne Grunau via B4 Relay a écrit :
> From: Janne Grunau
>
> Calling drm_crtc_vblank_on() drm_crtc_helper_funcs' atomic_enable is
> expected to enable vblank interrupts. It may have been avoided
> - spin_lock_irqsave(&crtc->dev->event_lock, flags);
> if (crtc->state->event) {
> - drm_crtc_vblank_get(crtc);
> - adp->event = crtc->state->event;
> + spin_lock_irqsave(&crtc->dev->event_lock, flags);
> +
> + if (drm_crtc_vblank_get(crtc)
> This is preferable to driver changes since keeps the device powered on
> if the adpdrm module is not available during boot.
Struggling to parse this sentence, do you mean to say:
> Driver changes are preferred, since that patch keeps the device
> powered on if the adpdrm module is not available
Reviewed-by: Alyssa Rosenzweig
Reviewed-by: Alyssa Rosenzweig
Le Fri , Apr 11, 2025 at 01:55:20AM +0200, Danilo Krummrich a écrit :
> In the Rust DRM device abstraction we need to allocate a struct
> drm_device.
>
> Currently, there are two options, the deprecated drm_dev_alloc() (which
> does not support s
Reviewed-by: Alyssa Rosenzweig
Le Fri , Apr 11, 2025 at 01:55:27AM +0200, Danilo Krummrich a écrit :
> Add the DRM Rust source files to the DRM DRIVERS maintainers entry.
>
> Signed-off-by: Danilo Krummrich
> ---
> MAINTAINERS | 2 ++
> 1 file changed, 2 insertions(+)
To the best of my ability, this is
Reviewed-by: Alyssa Rosenzweig
although this is rather above my current Rust abilities.
> +match T::open(unsafe { &*obj }, file) {
> +Err(e) => e.to_errno(),
> +Ok(()) => 0,
> +}
incidentally this would be
pointer to a `struct drm_file`.
`raw_file` is a valid pointer..
With those comments fixed, this is
Reviewed-by: Alyssa Rosenzweig
---
Tangential food-for-thought: might be possible to introduce a helper to
kernel::error::Result to make the error handling here more
ergonomic, but I don't kno
Reviewed-by: Alyssa Rosenzweig
> +/// # Safety
> +///
> +/// `ptr` must be a valid poiner to a `struct device` embedded in `Self`.
pointer
With that fixed,
Reviewed-by: Alyssa Rosenzweig
t that the handler
returns Result and sizeof(u32) <= sizeof(ffi:c_int)). But I don't
know how to do that in Rust so no action required unless you have a
better idea ;)
---
Anyway, with those two comments updated, this patch is
Reviewed-by: Alyssa Rosenzweig
Thanks!
> I'm still trying to see if we can emulate/have incremental-rendering on
> JM hardware
I guess since we don't advertise vertex shader side effects... Lol,
maybe that could work...
> Actually, CSF stands in the way of re-allocating memory to other
> contexts, because once we've allocated memory to a tiler heap, the FW
> manages this pool of chunks, and recycles them. Mesa can intercept
> the "returned chunks" and collect those chunks instead of re-assiging
> then to the tiler
> 2. Device Lost
> --
>
> At this point we're left with no other choice than to kill the context.
> And userspace should be able to cope with VK_DEVICE_LOST (hopefully zink
> does), but it will probably not cope well with an entire strom of these
> just to get the first frame out.
>
>
Reviewed-by: Alyssa Rosenzweig
Le Thu , Apr 10, 2025 at 11:50:01PM +0530, Aditya Garg a écrit :
> From: Aditya Garg
>
> The appletbdrm driver is exclusively for Touch Bars on x86 Intel Macs.
> The M1 Macs have a separate driver. So, lets avoid compiling it for
> othe
> > > In Panfrost and Lima, we don't have this concept of "incremental
> > > rendering", so when we fail the allocation, we just fail the GPU job
> > > with an unhandled GPU fault.
> >
> > To be honest I think that this is enough to mark those two drivers as
> > broken. It's documented that thi
-off-by: Asahi Lina
Acked-by: Simona Vetter
Reviewed-by: Neal Gompa
Reviewed-by: Janne Grunau
Signed-off-by: Alyssa Rosenzweig
---
Changes in v7:
- Drop non-arrayed binds. This simplifies both kernel and Mesa handling,
at a trivial perf cost (Faith).
- Minor comment fixes.
- Link to v6:
https
On Tue, 08 Apr 2025 16:54:14 -0400, Alyssa Rosenzweig wrote:
> This adds the UAPI for the Asahi driver targeting the GPU in the Apple
> M1 and M2 series systems on chip. The UAPI design is based on other
> modern Vulkan-capable drivers, including Xe and Panthor. Memory
> management
Reviewed-by: Alyssa Rosenzweig
Le Mon , Apr 07, 2025 at 07:07:54PM +0530, Aditya Garg a écrit :
> From: Aditya Garg
>
> Due to lack of a proper printk format, %p4cc was being used instead of
> %p4cl for the purpose of printing FourCCs. But the disadvange was that
> they were bei
> > > +/**
> > > + * @user_timestamp_frequency_hz: Timebase frequency for user
> timestamps
> > > + */
> > > +__u64 user_timestamp_frequency_hz;
> >
> > Why is this different? What are user timestamps and how are they different
> from GPU timestamps?
In v4, I've
> > https://github.com/alyssarosenzweig/linux/commits/agx-uapi-v5 contains
> > the DRM driver implementing this proposed UAPI.
> >
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33984 contains
> > the Mesa patches to implement this proposed UAPI.
> >
> > That Linux and Mesa branch to
-off-by: Asahi Lina
Acked-by: Simona Vetter
Reviewed-by: Neal Gompa
Reviewed-by: Janne Grunau
Signed-off-by: Alyssa Rosenzweig
---
Changes in v6:
- Rename vm_user_* to vm_* for clarity (Janne).
- Improve lots of comments.
- Drop a few unused global params that are unlikely to ever be used by
> > +/**
> > + * struct drm_asahi_params_global - Global parameters.
> > + *
> > + * This struct may be queried by drm_asahi_get_params.
> > + */
> > +struct drm_asahi_params_global {
> > + /** @features: Feature bits from drm_asahi_feature */
> > + __u64 features;
> > +
> > + /** @gpu_genera
> > > +struct drm_asahi_queue_create {
> > > +/** @flags: MBZ */
> > > +__u32 flags;
> > > +
> > > +/** @vm_id: The ID of the VM this queue is bound to */
> > > +__u32 vm_id;
> > > +
> > > +/** @queue_caps: Bitmask of DRM_ASAHI_QUEUE_CAP_* */
> > > +
-off-by: Asahi Lina
Acked-by: Simona Vetter
Signed-off-by: Alyssa Rosenzweig
---
Changes in v5:
- Rename GEM_BIND to VM_BIND and make it take an array of bind ops. This
significantly decreases the # of kernel<-->user roundtrips with Vulkan
sparse binding. The uAPI here is lifted directl
> +/**
> + * @DRM_ASAHI_BIND_SINGLE_PAGE: Map a single page of the BO
> repeatedly
> + * across the VA range.
> + *
> + * This is useful to fill a VA range with scratch pages or zero
> pages.
> + * It is intended as a mechanism
> I'm good with this. There's a slim possibility that upstream may
> evolve in ways that make the current UAPI tricky to implement.
> However, given that it's based on prior art from the nouveau, Intel,
> and panfrost teams and that you've been shipping it in production for
> a while, I think that
-off-by: Asahi Lina
Acked-by: Simona Vetter
Signed-off-by: Alyssa Rosenzweig
---
Changes in v4:
- get_time now returns time in nanoseconds, timer_frequency_hz dropped.
This hides an extra time domain from userspace for no real downside.
- Added lots more comments answering questions Faith raised
> > > +/**
> > > + * enum drm_asahi_bind_op - Bind operation
> > > + */
> > > +enum drm_asahi_bind_op {
> > > +/** @DRM_ASAHI_BIND_OP_BIND: Bind a BO to a GPU VMA range */
> > > +DRM_ASAHI_BIND_OP_BIND = 0,
> > > +
> > > +/** @DRM_ASAHI_BIND_OP_UNBIND: Unbind a GP
> Since this is a deparature from our usual requirement that all pieces
> should be ready before landing anything we had discussion whether this is
> an acceptable one-off exception for special circumstance. Thanks a lot to
> Alyssa for driving this. The very much summarized consensus is that due t
gitlab.freedesktop.org downtime.
That Linux and Mesa branch together give a complete graphics/compute
stack on top of this UAPI.
Co-developed-by: Asahi Lina
Signed-off-by: Asahi Lina
Signed-off-by: Alyssa Rosenzweig
---
Changes in v3:
- Merge load/store/partial fields for depth/stencil as discussed with
Faith
ommit info)
Best regards,
--
Alyssa Rosenzweig
On Mon, 10 Mar 2025 15:28:02 -0400, Alyssa Rosenzweig wrote:
> Apple GPUs support non-linear "GPU-tiled" image layouts. Add modifiers
> for these layouts. Mesa requires these modifiers to share non-linear
> buffers across processes, but no other userspace or kernel support is
gitlab.freedesktop.org downtime.
That Linux and Mesa branch together give a complete graphics/compute
stack on top of this UAPI.
Co-developed-by: Asahi Lina
Signed-off-by: Asahi Lina
Signed-off-by: Alyssa Rosenzweig
---
Changes in v2:
- Flatten submits. Previously, the submit ioctl pointed to an array of
s hardware
blocks (e.g. with the display controller). There are other layouts for
that but we don't support them either in userspace or kernelspace yet
(even downstream), so we don't add modifiers here.
Acked-by: Faith Ekstrand
Reviewed-by: Sven Peter
Signed-off-by: Alyssa Rosenzwei
series looks ok to me. Who is pushing this to drm-misc-next? (I can if
nobody else does)
: Asahi Lina
Signed-off-by: Alyssa Rosenzweig
---
Documentation/gpu/driver-uapi.rst |5 +
MAINTAINERS |1 +
include/uapi/drm/asahi_drm.h | 1153 +
3 files changed, 1159 insertions(+)
diff --git a/Documentation/gpu/driver-uapi.rst
> > +/**
> > + * struct drm_asahi_gem_bind - Arguments passed to
> > + * DRM_IOCTL_ASAHI_GEM_BIND
> > + */
> > +struct drm_asahi_gem_bind {
> > + /** @op: Bind operation (enum drm_asahi_bind_op) */
> > + __u32 op;
> > +
> > + /** @flags: One or more of ASAHI_BIND_* (BIND only) */
> Yeah it's because you applied the whole patchset, and discarded/skipped
> patch 3 & 4 afterwards, so b4 gets confused.
>
> Next time specify which patch you want to apply with -P 1,2,5
> and b4 with know which patch you applied and generate a good ty patch.
Ah nice, didn't know about -P, thanks
> > > All patches are reviewed, can we funnel patches 1, 2 & 5 via
> > > drm-misc-next now ?
> >
> > I'm planning to do so today, just need to get dim setup first :)
>
> Nice! As a heads up, it would be really-really nice if you can send any
> kind of 'applied' message. If you are using 'dim b4-
Er... I only applied 1, 2, and 5. Patch 3 was already merged, and patch
4 is going in via arm soc. I am, new to b4, sorry!
Le Wed, Mar 05, 2025 at 08:43:51AM -0500, Alyssa Rosenzweig a écrit :
>
> On Mon, 24 Feb 2025 12:02:15 +0100, Sasha Finkelstein wrote:
> > This patch series adds
or.
> ./drivers/gpu/drm/adp/adp_drv.c:476:2-9: line 476 is redundant because
> platform_get_irq() already prints an error.
>
>
> [...]
Applied, thanks!
[1/1] drm: adp: Remove unnecessary print function dev_err()
commit: e4c0fd3f965533cd2b38200ca73625afd602d39b
Best regards,
--
Alyssa Rosenzweig
)
[4/5] arm64: dts: apple: Add touchbar screen nodes
(no commit info)
[5/5] MAINTAINERS: Add entries for touchbar display driver
commit: 4d2a877cc0efefa815648f1ed5f5b2b796f55bab
Best regards,
--
Alyssa Rosenzweig
> > Sasha Finkelstein (5):
> >dt-bindings: display: Add Apple pre-DCP display controller
> >drm: adp: Add Apple Display Pipe driver
> >drm: panel: Add a panel driver for the Summit display
> >arm64: dts: apple: Add touchbar screen nodes
> >MAINTAINERS: Add en
blocks (e.g. with the display controller). There are other layouts for
that but we don't support them either in userspace or kernelspace yet
(even downstream), so we don't add modifiers here.
Signed-off-by: Alyssa Rosenzweig
---
Changes in v3:
- Condense comments for clarity and concision.
> > These layouts are notably not used for interchange across hardware
> > blocks (e.g. with the display controller). There are other layouts for
> > that but we don't support them either in userspace or kernelspace yet
> > (even downstream), so we don't add modifiers here.
>
> Yeah, when those ha
blocks (e.g. with the display controller). There are other layouts for
that but we don't support them either in userspace or kernelspace yet
(even downstream), so we don't add modifiers here.
Signed-off-by: Alyssa Rosenzweig
---
Changes in v2:
- Rename "Twiddled" to "GPU-t
> > +/*
> > + * Apple twiddled and compressed layout.
> > + *
> > + * This is the main lossless image compression layout supported by Apple
> > GPUs.
> > + *
> > + * The image is divided into tiles that are internally twiddled. In
> > addition to
>
> Does the compressed format uses the same the
;re not adding them here.
Signed-off-by: Alyssa Rosenzweig
---
include/uapi/drm/drm_fourcc.h | 31 +++
1 file changed, 31 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index
e41a3cec6a9ed18760f3b0c88ba437c9aba3dd4f..6c289fc1
R-b, thanks
On Wed, Feb 08, 2023 at 04:48:16PM -0300, Ma??ra Canal wrote:
> As panfrost_copy_in_sync() performs the same steps as
> drm_sched_job_add_syncobj_dependency(), replace the open-coded
> implementation in Panfrost in order to simply, using the DRM function.
>
> Signed-off-by: Ma??ra Can
> > > +struct drm_pancsf_gpu_info {
> > > +#define DRM_PANCSF_ARCH_MAJOR(x) ((x) >> 28)
> > > +#define DRM_PANCSF_ARCH_MINOR(x) (((x) >> 24) & 0xf)
> > > +#define DRM_PANCSF_ARCH_REV(x) (((x) >> 20) & 0xf)
> > > +#define DRM_PANCSF_PRODUCT_MAJOR(x) (((
> > Mali v10 (second Valhal iteration) and later GPUs replaced the Job
> > Manager block by a command stream based interface called CSF (for
> > Command Stream Frontend). This interface is not only turning the job
> > chain based submission model into a command stream based one, but also
> > introd
> Among the people present in this discussion, the consensus was that we
> should delete them.
I wasn't present but +1 from me.
> > For one thing, setting that up would be a lot of up front infrastructure
> > work. I'm not sure how to even pull that off when Xe is still
> > out-of-tree and i915 development plunges on upstream as ever.
> >
> > For another, realistically, the overlap between supported platforms is
> > going
Sounds like a nice clean up :-)
Acked-by: Alyssa Rosenzweig
On Tue, Nov 29, 2022 at 07:19:32PM +, Paul Cercueil wrote:
> Use the EXPORT_GPL_RUNTIME_DEV_PM_OPS() and pm_ptr() macros to handle
> the PM callbacks.
>
> These macros allow the PM functions to be automaticall
Reviewed-by: Alyssa Rosenzweig
On Thu, Nov 03, 2022 at 11:40:36AM +, Steven Price wrote:
> Commit 72655fb942c1 ("drm/panfrost: replace endian-specific types with
> native ones") accidentally reverted part of the parent commit
> 7228d9d79248 ("drm/panfrost: Remove
Series is
Reviewed-by: Alyssa Rosenzweig
Thank you for this, please push to the appropriate trees so we can fix
the Mesa build.
On Mon, Oct 17, 2022 at 11:46:00AM +0100, Steven Price wrote:
> The Panfrost DRM interface to user space is uesd in Mesa for targets
> other than C
> > 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.
>
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
On Tue, Sep 20, 2022 at 02:26:52PM +0100, Steven Price wrote:
> On 19/09/2022 07:44, Adri??n Larumbe wrote:
> > Hi Steven,
> >
> > On 13.09.2022 09:45, Steven Price wrote:
> >> On 12/09/2022 17:44, Adri??n Larumbe wrote:
> >>> Building Mesa's Perfetto requires including the panfrost drm uAPI heade
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
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)
> > > {
> > > -
> -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.
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
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
> Sorry about this blunder.
>
> >> + slot = panfrost_job_get_slot(job);
> >> + slot = slot ? slot : 0;
> >
> >`slot = slot ? slot : 0` is a no-op. Delete the line.
>
> I think what I meant here was 'slot = (slot >= 0) ? slot : 0;' but for some
> reason I blundered again. The point of this was e
> + 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
> > > + 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 -
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
>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 Adrian,
Great work on the devcoredump support! This is really cool to see coming
along, thank you! I've left a few notes below:
> + if (panfrost_dump_registers[i] >= JS_HEAD_LO(0) &&
> + panfrost_dump_registers[i] <= JS_CONFIG_NEXT(0))
> + js_as_
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
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
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
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
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
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
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
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
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
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
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 +++
1 - 100 of 310 matches
Mail list logo
