On 06/06/2024 01:49, Adrián Larumbe wrote:
> This patch series enables userspace utilities like gputop and nvtop to
> query a render context's fdinfo file and figure out rates of engine
> and memory utilisation.
>
> Previous discussion can be found at
>
-Yu Tsai
> Signed-off-by: AngeloGioacchino Del Regno
>
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/pa
On 05/06/2024 12:43, AngeloGioacchino Del Regno wrote:
> Il 05/06/24 11:18, Steven Price ha scritto:
>> On 04/06/2024 13:39, AngeloGioacchino Del Regno wrote:
>>> MediaTek MT8188 has a Mali-G57 MC3 (Valhall-JM): add a new
>>> compatible and platform data using the sam
On 04/06/2024 13:39, AngeloGioacchino Del Regno wrote:
> MediaTek MT8188 has a Mali-G57 MC3 (Valhall-JM): add a new
> compatible and platform data using the same supplies and the
> same power domain lists as MT8183 (one regulator, three power
> domains).
>
> Signed-off-by: AngeloGioacchino Del
On 03/06/2024 04:29, Chen-Yu Tsai wrote:
> On Fri, May 31, 2024 at 7:18 PM Frank Binns wrote:
>>
>> On Thu, 2024-05-30 at 16:35 +0800, Chen-Yu Tsai wrote:
>>> The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is part
>>> of the Series6XT, another variation of the Rogue family of GPUs.
On 10/05/2024 10:09, Jani Nikula wrote:
> libdrm does not like the empty string for driver date. Use "0" instead,
> which has been used by virtio previously.
>
> Reported-by: Steven Price
> Closes: https://lore.kernel.org/r/9d0cff47-308e-4b11-a9f3-4157dc26b...@arm.com
&g
On 10/05/2024 10:13, Jani Nikula wrote:
> On Thu, 09 May 2024, Steven Price wrote:
>> On 29/04/2024 17:43, Jani Nikula wrote:
>>> The driver date serves no useful purpose, because it's hardly ever
>>> updated. The information is misleading at best.
>>>
>&
On 29/04/2024 17:43, Jani Nikula wrote:
> The driver date serves no useful purpose, because it's hardly ever
> updated. The information is misleading at best.
>
> As described in Documentation/gpu/drm-internals.rst:
>
> The driver date, formatted as MMDD, is meant to identify the date
>
On 02/05/2024 19:38, Boris Brezillon wrote:
> This way get NULL derefs instead of use-after-free if the FW VM is
> referenced after the device has been unplugged.
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panthor/panthor_fw.c | 1 +
ble, although I hope this case doesn't happen in practice ;)
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panthor/panthor_device.c | 7 +--
> drivers/gpu/drm/panthor/panthor_sched.c | 19 ++-
> drivers/gpu/drm/panthor/panthor_sched.h | 2 +-
> 3 files
On 02/05/2024 19:38, Boris Brezillon wrote:
> Avoids use-after-free situations when panthor_fw_unplug() is called
> and the kernel BO was mapped to the FW VM.
>
> Signed-off-by: Boris Brezillon
It makes the code more readable too - I like it.
Reviewed-by: Steven Price
> ---
On 02/05/2024 19:38, Boris Brezillon wrote:
> If the FW reports an unrecoverable fault, we need to reset the GPU
> before we can start re-using it again.
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panthor/panthor_device.c | 1 +
anthor: Add the heap logical block")
> Reported-by: Eric Smith
> Signed-off-by: Boris Brezillon
> Tested-by: Eric Smith
Reviewed-by: Steven Price
Thanks,
Steve
> ---
> drivers/gpu/drm/panthor/panthor_heap.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
On 02/05/2024 16:40, Boris Brezillon wrote:
> Make sure the user is aware that drm_panthor_tiler_heap_destroy::handle
> must be a handle previously returned by
> DRM_IOCTL_PANTHOR_TILER_HEAP_CREATE.
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
&
On 02/05/2024 16:40, Boris Brezillon wrote:
> The heap ID is used to index the heap context pool, and allocating
> in the [1:MAX_HEAPS_PER_POOL] leads to an off-by-one. This was
> originally to avoid returning a zero heap handle, but given the handle
> is formed with (vm_id << 16) | heap_id, with
eate() kerneldoc
>
> Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
> Signed-off-by: Boris Brezillon
> Reviewed-by: Liviu Dudau
> Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panthor/panthor_heap.c | 8
> include/uapi/drm/pantho
On 02/05/2024 15:15, Boris Brezillon wrote:
> On Thu, 2 May 2024 15:03:51 +0100
> Steven Price wrote:
>
>> On 30/04/2024 12:28, Boris Brezillon wrote:
>>> ID 0 is reserved to encode 'no-tiler-heap', the heap ID range is
>>> [1:MAX_HEAPS_PER_POOL], which we occasi
On 30/04/2024 12:28, Boris Brezillon wrote:
> ID 0 is reserved to encode 'no-tiler-heap', the heap ID range is
> [1:MAX_HEAPS_PER_POOL], which we occasionally need to turn into an index
> in the [0:MAX_HEAPS_PER_POOL-1] when we want to access the context object.
This might be a silly question,
eldoc
>>
>> Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
>> Signed-off-by: Boris Brezillon
Other than the typo Adrián pointed out below...
Reviewed-by: Steven Price
>> ---
>> drivers/gpu/drm/panthor/panthor_heap.c | 8
>>
ount > 0" constraint while at it.
>
> v2:
> - Fix the check
>
> Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
Thanks,
Steve
> ---
> drivers/gpu/drm/panthor/panthor_heap.c | 3 +
or all kind of allocation
> failures
> - Document the panthor_heap_grow() semantics
>
> Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block")
> Signed-off-by: Antonino Maniscalco
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
Thanks,
Steve
> -
MCU_CONTROL register.
>
> Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block")
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panthor/panthor_fw.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
&
Hi Javier,
On 25/04/2024 10:22, Javier Martinez Canillas wrote:
> Steven Price writes:
>
> Hello Steven,
>
>> On 13/04/2024 12:49, Andy Yan wrote:
>>> From: Andy Yan
>>>
>>> The firmware in the rootfs will not be accessible until we
>>> a
On 25/04/2024 11:39, Boris Brezillon wrote:
> We can use upd_ctx.timedout_mask directly, and the faulty_slots update
> in the flush_caches_failed situation is never used.
>
> Suggested-by: Suggested-by: Steven Price
I'm obviously too full of suggestions! ;)
And you're doing a muc
On 25/04/2024 10:28, Steven Price wrote:
> On 25/04/2024 08:18, Boris Brezillon wrote:
>> It doesn't make sense to have a maximum number of chunks smaller than
>> the initial number of chunks attached to the context.
>>
>> Fix the uAPI header to reflect the
t; When an unknown state is detected, we trigger a reset, and consider the
> group as unusable after that point, to prevent the potential corruption
> from creeping in other places if we continue executing stuff on this
> context.
>
> Reported-by: Dan Carpenter
> Suggested-by:
On 25/04/2024 08:18, Boris Brezillon wrote:
> The field used to store the chunk size if 12 bits wide, and the encoding
NIT: ^^ is
> is chunk_size = chunk_header.chunk_size << 12, which gives us a
> theoretical [4k:8M] range. This range is further limited by
>
ves, and start over from where it stopped).
>
> Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block")
> Signed-off-by: Antonino Maniscalco
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
Although I think the real issue here is that we haven't clea
ount > 0" constraint while at it.
>
> Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panthor/panthor_heap.c | 3 +++
> include/uapi/drm/panthor_drm.h
On 13/04/2024 12:49, Andy Yan wrote:
> From: Andy Yan
>
> The firmware in the rootfs will not be accessible until we
> are in the SYSTEM_RUNNING state, so return EPROBE_DEFER until
> that point.
> This let the driver can load firmware when it is builtin.
The usual solution is that the firmware
On 10/04/2024 15:34, Dan Carpenter wrote:
> On Wed, Apr 10, 2024 at 03:11:52PM +0100, Steven Price wrote:
>> On 08/04/2024 08:35, Dan Carpenter wrote:
>>> Hello Boris Brezillon,
>>>
>>> Commit de8548813824 ("drm/panthor: Add the scheduler logical block&qu
On 08/04/2024 08:35, Dan Carpenter wrote:
> Hello Boris Brezillon,
>
> Commit de8548813824 ("drm/panthor: Add the scheduler logical block")
> from Feb 29, 2024 (linux-next), leads to the following Smatch static
> checker warning:
>
> drivers/gpu/drm/panthor/panthor_sched.c:1153
>
t;suspended_slots" is a u64 and "upd_ctx.timedout_mask". The
> mask clears out the top 32 bits which would likely be a bug if anything
> were stored there.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Steven Price
If you fancy a bit more clean-up then I think faulty_slots is comp
On 22/03/2024 16:45, Christian Hewitt wrote:
> Increase the timeout value to prevent system logs on Amlogic boards flooding
> with power transition warnings:
>
> [ 13.047638] panfrost ffe4.gpu: shader power transition timeout
> [ 13.048674] panfrost ffe4.gpu: l2 power transition
drm/panthor: Add the scheduler logical block")
> Signed-off-by: Nathan Chancellor
Reviewed-by: Steven Price
Thanks,
Steve
> ---
> drivers/gpu/drm/panthor/panthor_sched.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/p
ich we don't want.
>
> v3:
> - New patch
>
> Fixes: 5fe909cae118 ("drm/panthor: Add the device logical block")
> Signed-off-by: Boris Brezillon
LGTM
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panthor/panthor_device.h | 17 -
&g
On 16/03/2024 23:13, Adrián Larumbe wrote:
> If job accounting is disabled, then both fdinfo's drm-engine and drm-cycle
> key values will remain immutable. In that case, it makes more sense not to
> display them at all to avoid confusing user space profiling tools.
>
> Signed-off-by: Adrián
On 25/03/2024 13:57, Boris Brezillon wrote:
> Make sure we set suspended=true last to avoid generating an irq storm
> in the unlikely case where an IRQ happens between the suspended=true
> assignment and the _INT_MASK update.
>
> v2:
> - New patch
>
> Reported-by: St
On 25/03/2024 11:43, Boris Brezillon wrote:
> On Mon, 25 Mar 2024 11:17:24 +
> Steven Price wrote:
>
>> On 25/03/2024 10:41, Boris Brezillon wrote:
>>> panthor_xxx_irq_suspend() doesn't mask the interrupts if drm_dev_unplug()
>>> has been called,
On 25/03/2024 10:41, Boris Brezillon wrote:
> panthor_xxx_irq_suspend() doesn't mask the interrupts if drm_dev_unplug()
> has been called, which is always the case when our panthor_xxx_unplug()
> helpers are called. Fix that by introducing a panthor_xxx_unplug() helper
> that does what
://gitlab.freedesktop.org/mesa/mesa/-/issues/10835
> Signed-off-by: Boris Brezillon
Pesky 32 bit again ;)
Looks fine, although I'm wondering whether you'd consider squashing
something like the below on top? I think it helps contain the 32 bit
specific code to the one place. Either way:
Reviewed-by:
he impact to the rest of the system of a long wait
is less.
But 2ms doesn't sound an unreasonable timeout so:
Reviewed-by: Steven Price
> Fixes: 22aa1a209018 ("drm/panfrost: Really power off GPU cores in
> panfrost_gpu_power_off()")
> Signed-off-by: Christian Hewitt >
ime.
>
> v2:
> - Drop the #ifdef CONFIG_PM section around panthor_pm_ops's definition
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202403031944.eoimq8wk-...@intel.com/
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
(an
On 18/03/2024 14:49, Boris Brezillon wrote:
> On Mon, 18 Mar 2024 14:34:07 +
> Steven Price wrote:
>
>> On 18/03/2024 14:18, Boris Brezillon wrote:
>>> On Mon, 18 Mar 2024 13:49:52 +
>>> Steven Price wrote:
>>>
>>>> On 18/03/202
virt_to_pfn() isn't available on x86 (except to xen) so breaks
COMPILE_TEST builds. Avoid its use completely by instead storing the
struct page pointer allocated in panthor_device_init() and using
page_to_pfn() instead.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panthor/panthor_device.c
On 18/03/2024 14:18, Boris Brezillon wrote:
> On Mon, 18 Mar 2024 13:49:52 +
> Steven Price wrote:
>
>> On 18/03/2024 13:08, Boris Brezillon wrote:
>>> On Mon, 18 Mar 2024 11:31:05 +
>>> Steven Price wrote:
>>>
>>>> On 18/03/202
On 18/03/2024 13:08, Boris Brezillon wrote:
> On Mon, 18 Mar 2024 11:31:05 +
> Steven Price wrote:
>
>> On 18/03/2024 08:58, Boris Brezillon wrote:
>>> Putting a hard dependency on CONFIG_PM is not possible because of a
>>> circular dependency issue, and i
-off-by: Adrián Larumbe
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> ind
gt;
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202403031944.eoimq8wk-...@intel.com/
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
> Tested by faking CONFIG_PM=n in the driver (basically commenting
&
On 11/03/2024 13:36, Robin Murphy wrote:
> On 2024-03-11 1:22 pm, Boris Brezillon wrote:
>> On Mon, 11 Mar 2024 13:11:28 +
>> Robin Murphy wrote:
>>
>>> On 2024-03-11 11:52 am, Boris Brezillon wrote:
On Mon, 11 Mar 2024 13:49:56 +0200
Jani Nikula wrote:
> On Mon, 11 Mar
s drm engine and cycle calculations.
>
> Drop the debugfs knob and replace it with a sysfs file that accomplishes
> the same functionality, and document its ABI in a separate file.
>
> Signed-off-by: Adrián Larumbe
Reviewed-by: Steven Price
> ---
> .../testing/sysfs
s drm engine and cycle calculations.
>
> Drop the debugfs knob and replace it with a sysfs file that accomplishes
> the same functionality, and document its ABI in a separate file.
>
> Signed-off-by: Adrián Larumbe
I'm happy with this.
Reviewed-by: Steven Price
Boris: are y
should be easy to relax the CONFIG_PM condition in
the future if anyone has an actual need.
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panthor/Kconfig | 1 +
> drivers/gpu/drm/panthor/panthor_device.c | 2 --
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff
udes asm/page.h. I can find examples of both. Either way:
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panthor/panthor_device.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_device.c
> b/drivers/gpu/drm/panthor/panthor_device.c
On 04/03/2024 09:08, Boris Brezillon wrote:
> Missing '*' to have a valid kerneldoc prefix.
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202403031019.6jvroqgt-...@intel.com/
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
On 21/02/2024 16:12, Adrián Larumbe wrote:
> Debugfs isn't always available in production builds that try to squeeze
> every single byte out of the kernel image, but we still need a way to
> toggle the timestamp and cycle counter registers so that jobs can be
> profiled for fdinfo's drm engine and
va() allocate the drm_mm_node
> (embedded in panthor_kernel_bo now)
> - Adjust things to match the latest drm_gpuvm changes (extobj tracking,
> resv prep and more)
> - Drop the per-AS lock and use slots_lock (fixes a race on vm->as.id)
> - Set as.id to -1 when reusing an address
On 14/02/2024 17:33, Boris Brezillon wrote:
> On Mon, 12 Feb 2024 11:40:55 +
> Steven Price wrote:
>
>> On 22/01/2024 16:30, Boris Brezillon wrote:
>>> Tiler heap growing requires some kernel driver involvement: when the
>>> tiler runs out of heap memory,
ason
> - Account for drm_sched changes
> - Provide a panthor_queue_put_syncwait_obj()
> - Unconditionally return groups to their idle list in
> panthor_sched_suspend()
> - Condition of sched_queue_{,delayed_}work fixed to be only when a reset
> isn't pending or in progress.
> -
Hi Adrián,
On 14/02/2024 12:14, Adrián Larumbe wrote:
> A driver user expressed interest in being able to access engine usage stats
> through fdinfo when debugfs is not built into their kernel. In the current
> implementation, this wasn't possible, because it was assumed even for
> inflight jobs
rnel_bo abstraction for the heap context and heap
> chunks
> - Drop the panthor_heap_gpu_ctx struct as it is opaque to the driver
> - Ensure that the heap context is aligned to the GPU cache line size
> - Minor code tidy ups
>
> Co-developed-by: Steven Price
> Signed-off-by: Steven Pric
rop the per-AS lock and use slots_lock (fixes a race on vm->as.id)
> - Set as.id to -1 when reusing an address space from the LRU list
> - Drop misleading comment about page faults
> - Remove check for irq being assigned in panthor_mmu_unplug()
>
> Co-developed-by: Steven Price
>
r_fw_mem and be used everywhere we were
> using panthor_gem_create_and_map() before)
> - Adjust things to match drm_gpuvm changes
> - Change return of panthor_gem_create_with_handle() to int
>
> Co-developed-by: Steven Price
> Signed-off-by: Steven Price
> Signed-off-by: Boris Bre
t output registers that are
> not updated for protected interrupts).
> - Minor code tidy ups
>
> Cc: Alexey Sheplyakov # MIT+GPL2 relicensing
> Co-developed-by: Steven Price
> Signed-off-by: Steven Price
> Signed-off-by: Boris Brezillon
> Acked-by: Steven Price # MIT+GPL
On 26/01/2024 09:39, Boris Brezillon wrote:
> On Thu, 25 Jan 2024 16:47:24 +
> Steven Price wrote:
>
>> On 05/01/2024 18:46, Dmitry Osipenko wrote:
>>> To simplify the drm-shmem refcnt handling, we're moving away from
>>> the implicit get_pages() that is
ng to purge a BO that
> already had its pages released.
>
> Signed-off-by: Dmitry Osipenko
Reviewed-by: Steven Price
Although I don't like the condition in panfrost_gem_mapping_release()
for drm_gem_shmem_put_pages() and assigning NULL to bo->sgts - it feels
very fragile. See
Co-developed-by: Dmitry Osipenko
> Signed-off-by: Dmitry Osipenko
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
On 04/12/2023 17:33, Boris Brezillon wrote:
> Add an entry for the Panthor driver to the MAINTAINERS file.
>
> v3:
> - Add bindings document as an 'F:' line.
> - Add Steven and Liviu as co-maintainers.
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Steven Price
I'
e to be
> supported by this driver and which are for panfrost.
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Steven Price
> Acked-by: Steven Price # MIT+GPL2 relicensing,Arm
> Acked-by: Grant Likely # MIT+GPL2 relicensing,Linaro
> Acked-by: Boris Brezillon # M
nthor_submit_ctx_add_job().
> - Fix typos in comments.
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Steven Price
> Acked-by: Steven Price # MIT+GPL2 relicensing,Arm
> Acked-by: Grant Likely # MIT+GPL2 relicensing,Linaro
> Acked-by: Boris Brezillon # MIT+G
onditionally return groups to their idle list in
> panthor_sched_suspend()
> - Condition of sched_queue_{,delayed_}work fixed to be only when a reset
> isn't pending or in progress.
> - Several typos in comments fixed.
>
> Signed-off-by: Boris Brezillon
> Signed-off-by:
t; v3:
> - Add a FIXME for the heap OOM deadlock
Sadly I don't have any better solutions that what you've described in
the FIXME.
Other than the deadlock FIXME:
Reviewed-by: Steven Price
Steve
> - Use the panthor_kernel_bo abstraction for the heap context and heap
> chunks
gt; - Other minor code improvements.
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Steven Price
One typo below (I think it might even have been mine...), but otherwise
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panthor/panthor_fw.c | 1332 ++
a race on vm->as.id)
> - Set as.id to -1 when reusing an address space from the LRU list
> - Drop misleading comment about page faults
> - Remove check for irq being assigned in panthor_mmu_unplug()
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Steven Price
> Acked-by:
r_gem_create_with_handle() to int
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Steven Price
> Acked-by: Steven Price # MIT+GPL2 relicensing,Arm
> Acked-by: Grant Likely # MIT+GPL2 relicensing,Linaro
> Acked-by: Boris Brezillon # MIT+GPL2
> relicensing,Collabora
Looks
nterrupts).
> - Minor code tidy ups
>
> Cc: Alexey Sheplyakov # MIT+GPL2 relicensing
> Signed-off-by: Boris Brezillon
> Signed-off-by: Steven Price
> Acked-by: Steven Price # MIT+GPL2 relicensing,Arm
> Acked-by: Grant Likely # MIT+GPL2 relicensing,Linaro
> Acked-by: Boris Br
On 07/12/2023 08:56, Boris Brezillon wrote:
> On Thu, 7 Dec 2023 09:12:43 +0100
> Boris Brezillon wrote:
>
>> On Wed, 6 Dec 2023 16:55:42 +
>> Steven Price wrote:
>>
>>> On 04/12/2023 17:32, Boris Brezillon wrote:
>>>> The panthor driver
-way in
> panthor_device_reset_work()
> - Replace CSF_GPU_LATEST_FLUSH_ID_DEFAULT with a constant '1' and a
> comment to explain. Also remove setting the dummy flush ID on suspend.
> - Remove drm_WARN_ON() in panthor_exception_name()
> - Check pirq->suspended in panthor_xxx_irq_raw_handler
t doesn't exist post-CSF
> - Remove CSF_GPU_LATEST_FLUSH_ID_DEFAULT
> - Add GPU_L2_FEATURES_LINE_SIZE for extracting the GPU cache line size
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Steven Price
> Acked-by: Steven Price # MIT+GPL2 relicensing,Arm
> Acked-by: Grant
gt; -pedantic mode.
> - Drop property core_group_count as it can be easily calculated by the
> number of bits set in l2_present.
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Steven Price
NIT: I believe the signed-off lines should be like:
Co-developed-by: Steven
Sign
On 05/12/2023 08:48, Boris Brezillon wrote:
> Hi Steve,
>
> I forgot to mention that I intentionally dropped your R-b, because
> there was a gazillion of changes all over the place, and I thought it
> deserved a fresh review.
No problem, I'll re-review the patches. Thanks for getting the v3 out
ress the
> possible corner case of unintentional IRQ unmasking because of ISR
> execution after a call to synchronize_irq().
>
> At resume, clear each is_suspended bit in the reset path of JOB/MMU
> to allow unmasking the interrupts.
>
> Signed-off-by: AngeloGioacchino Del Regno
On 01/12/2023 11:14, Boris Brezillon wrote:
> On Fri, 1 Dec 2023 11:40:27 +0100
> AngeloGioacchino Del Regno
> wrote:
>
>> To make sure that we don't unintentionally perform any unclocked and/or
>> unpowered R/W operation on GPU registers, before turning off clocks and
>> regulators we must
> Signed-off-by: AngeloGioacchino Del Regno
>
Reviewed-by: Steven Price
Although this now makes the job IRQ look out of place - I'm not sure why
we have the struct panfrost_job_slot as a separately allocated structure
either. Anyway - that's irrelevant to this patch!
Steve
> ---
>
Fixes: 22aa1a209018 ("drm/panfrost: Really power off GPU cores in
> panfrost_gpu_power_off()")
> Signed-off-by: AngeloGioacchino Del Regno
>
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_gpu.c | 12
> 1 file changed, 8 insertions(+)
On 25/11/2023 20:52, Adrián Larumbe wrote:
> During recent development of the Mali CSF GPU Panthor driver, a user
> noticed that GPU frequency values as reported by fdinfo were
> incorrect. This was traced back to incorrect handling of frequency value
> updates. The same problem was seen in
Good catch - I'd not looked at the performance governor. I'd assumed
that one was "too simple to be wrong" ;)
Reviewed-by: Steven Price
>
> Signed-off-by: Adrián Larumbe
> Fixes: f11b0417eec2 ("drm/panfrost: Add fdinfo support GPU load metrics")
&
-counting system wide (both the
exporter and importer could show the memory usage). But I think we're
better off over-counting rather than under-counting.
Reviewed-by: Steven Price
> Signed-off-by: Adrián Larumbe
> Fixes: 9ccdac7aa822 ("drm/panfrost: Add fdinfo support for memory stats&qu
gt;> Il 21/11/23 16:34, Krzysztof Kozlowski ha scritto:
>>>>> On 08/11/2023 14:20, Steven Price wrote:
>>>>>> On 02/11/2023 14:15, AngeloGioacchino Del Regno wrote:
>>>>>>> The layout of the registers {TILER,SHADER,L2}_PWROFF_LO,
On 09/11/2023 10:25, AngeloGioacchino Del Regno wrote:
> Changes in v3:
> - Fixed the order of set_opp/opp_put in patch [5/6]
> - Clearly specified MediaTek SoC models in patches [4/6], [6/6]
> - Reordered clk_disable() for suspend in patch [3/6]
> - Fixed blank line removal and alignment in
es
> MT8186, MT8192, MT8195 were tested manually with over 100 suspend/resume
> cycles with GNOME DE (Mutter + Wayland).
>
> Signed-off-by: AngeloGioacchino Del Regno
>
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 6 +++---
> 1 file changed,
full suspend only on selected platforms.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_device.c | 19 ++-
> drivers/gpu/drm/panfrost/panfrost_device.h | 2 ++
> 2 files changed, 20 inser
resulting in a full system lockup.
>
> Doing this only for full system sleep never showed issues during my
> testing by suspending and resuming the system continuously for more
> than 100 cycles.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
Reviewed-by: Steve
cchino Del Regno
>
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_gpu.c | 13 ++---
> drivers/gpu/drm/panfrost/panfrost_regs.h | 1 +
> 2 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost
On 02/11/2023 14:26, AngeloGioacchino Del Regno wrote:
> Some platforms/SoCs can power off the GPU entirely by completely cutting
> off power, greatly enhancing battery time during system suspend: add a
> new pm_feature GPU_PM_VREG_OFF to allow turning off the GPU regulators
> during full suspend
On 02/11/2023 14:26, AngeloGioacchino Del Regno wrote:
> All of the MediaTek SoCs supported by Panfrost can completely cut power
> to the GPU during full system sleep without any user-noticeable delay
> in the resume operation, as shown by measurements taken on multiple
> MediaTek SoCs.
>
> As an
tem sleep .resume() handler and .runtime_resume() (so the time
> refers to T_Resume + T_Runtime_Resume):
>
> Average Panfrost-only system sleep resume time, before: ~28000ns
> Average Panfrost-only system sleep resume time, after: ~33500ns
>
> Signed-off-by: AngeloGioacchino Del
es & BIT(GPU_PM_CLK_DIS)) {
> + clk_disable(pfdev->clock);
> +
> + if (pfdev->bus_clock)
> + clk_disable(pfdev->bus_clock);
NIT: I would normally expect panfrost_device_resume() to have the
opposite order. I'm not sure if ther
M running: 73200ns
>
> After this commit:
>
> GDM: user selection up/down:26690ns
> GDM: Text Entry (typing user/password): 27917ns
> GNOME Desktop, idling, GKRELLM running: 25304ns
>
> Signed-off-by: AngeloGioacchino Del Regno
>
Reviewed-by: Ste
On 02/11/2023 14:26, AngeloGioacchino Del Regno wrote:
> Even though soft reset should ideally never fail, during development of
> some power management features I managed to get some bits wrong: this
> resulted in GPU soft reset failures, where the GPU was never able to
> recover, not even after
1 - 100 of 755 matches
Mail list logo