This is needed because we want to reset those devices in device-agnostic
code such as lima_sched.
In particular, masking irqs will be useful before a hard reset to
prevent race conditions.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_bcast.c | 12
drivers/gpu/drm/lima
by masking the irqs at the
beginning of the timeout handler, at which point we give up on waiting
for that job entirely.
The irqs will be enabled again at the next hard reset which is already
done as a recovery by the timeout handler.
Signed-off-by: Erico Nunes
Reviewed-by: Qiang Yu
---
drivers/gpu/drm
he timeout
handler, so add it to this check too.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_sched.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index 00b19adfc888..66841503a618 100644
--- a/drivers/gp
v1 reference:
https://patchwork.freedesktop.org/series/131902/
Changes v1 -> v2:
- Split synchronize_irq of pp bcast irq change into (new) patch 2.
Erico Nunes (3):
drm/lima: add mask irq callback to gp and pp
drm/lima: include pp bcast irq in timeout handler check
drm/lima: mask i
Create a simple data struct to hold compatible data so that we don't
have to do the casts to void pointer to hold data.
Fixes the following warning:
drivers/gpu/drm/lima/lima_drv.c:387:13: error: cast to smaller integer
type 'enum lima_gpu_id' from 'const void *'
Signed-off-by: Erico Nunes
clocks.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_gp.c | 2 ++
drivers/gpu/drm/lima/lima_mmu.c | 5 +
drivers/gpu/drm/lima/lima_pp.c | 4
3 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/lima/lima_gp.c b/drivers/gpu/drm/lima/lima_gp.c
index 6b354e2fb61d
*'
[-Werror,-Wvoid-pointer-to-enum-cast]
which we have received as a repeated report from the kernel test bot to
the lima mailing list.
The warning only reproduces with recent clang on aarch64, but the patch
does get rid of it and there seem to be no more warnings for W=1.
Erico Nunes (2):
drm/lima: fix
This is needed because we want to reset those devices in device-agnostic
code such as lima_sched.
In particular, masking irqs will be useful before a hard reset to
prevent race conditions.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_bcast.c | 12
drivers/gpu/drm/lima
by masking the irqs at the
beginning of the timeout handler, at which point we give up on waiting
for that job entirely.
The irqs will be enabled again at the next hard reset which is already
done as a recovery by the timeout handler.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_sched.c | 7
after hours of test time. After masking the pp bcast irq as
well I was not able to reproduce it anymore even on Mali-450, so I think
that was the missing bit for it.
Erico Nunes (2):
drm/lima: add mask irq callback to gp and pp
drm/lima: mask irqs in timeout path before hard reset
drivers
is not supported" on PLL_GPU. So I
think this is really needed for a reliable GPU experience on A64.
Acked-by: Erico Nunes
Thanks
Erico
Hello,
On Mon, Feb 26, 2024 at 6:29 PM Jernej Škrabec wrote:
>
> Dne ponedeljek, 26. februar 2024 ob 08:13:42 CET je Frank Oltmanns napisal(a):
> > It seems to me that all options for changing the GPU's rate in a stable
> > manner have been exhausted. There seems to be no common interpretation
>
Hi,
On Mon, Feb 19, 2024 at 9:38 PM Adam Ford wrote:
> /usr/share/vulkan/explicit_layer.d/VkLayer_MESA_overlay.json
> ERROR:loader_validate_instance_extensions: Instance
> extension VK_KHR_wayland_surface not supported by available ICDs or
> enabled layers.
> Failed to create Vulkan
On Wed, Jan 24, 2024 at 1:38 PM Qiang Yu wrote:
>
> On Wed, Jan 24, 2024 at 11:00 AM Erico Nunes wrote:
> >
> > There are several unexplained and unreproduced cases of rendering
> > timeouts with lima, for which one theory is high IRQ latency coming from
> >
Some debug messages carried the ip name, or included "lima", or
included both the ip name and then the numbered ip name again.
Make the messages more consistent by always looking up and showing
the ip name first.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_gp.c
an issue in
the recovery path.
Panfrost already does some special handling to account for such
"spurious timeouts", it makes sense to have this in lima too to reduce
the chance that it hit users.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_sc
infinite loop shaders, and these don't
seem to happen very often in real applications.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index
This is required for reliable hard resets. Otherwise, doing a hard reset
while a task is still running (such as a task which is being stopped by
the drm_sched timeout handler) may result in random mmu write timeouts
or lockups which cause the entire gpu to hang.
Signed-off-by: Erico Nunes
flag when doing the hard reset so that we don't
get that message.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_gp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/lima/lima_gp.c b/drivers/gpu/drm/lima/lima_gp.c
index 8dd501b7a3d0..b9a06e701a33 100644
that there are reliability improvements to the lima timeout
recovery handling, drop the guilty contexts to let the application keep
running in this case.
Signed-off-by: Erico Nunes
Acked-by: Christian König
Reviewed-by: Vasily Khoruzhick
---
drivers/gpu/drm/lima/lima_ctx.c | 2 +-
drivers
This is required for reliable hard resets. Otherwise, doing a hard reset
while a task is still running (such as a task which is being stopped by
the drm_sched timeout handler) may result in random mmu write timeouts
or lockups which cause the entire gpu to hang.
Signed-off-by: Erico Nunes
n v2. Since I broadened the work to not only focus
in pp anymore, I also included the change to the other blocks as well.
- Collected some reviews and acks in unmodified patches.
Erico Nunes (8):
drm/lima: reset async_reset on pp hard reset
drm/lima: reset async_reset on gp hard reset
drm/lima: se
flag when doing the hard reset so that we don't
get that message.
Signed-off-by: Erico Nunes
Reviewed-by: Vasily Khoruzhick
---
drivers/gpu/drm/lima/lima_pp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/lima/lima_pp.c b/drivers/gpu/drm/lima/lima_pp.c
index
On Fri, Jan 19, 2024 at 2:50 AM Qiang Yu wrote:
>
> On Thu, Jan 18, 2024 at 7:14 PM Erico Nunes wrote:
> >
> > On Thu, Jan 18, 2024 at 2:36 AM Qiang Yu wrote:
> > >
> > > So this is caused by same job trigger both done and timeout handling?
> > >
On Sun, Jan 21, 2024 at 12:20 PM Qiang Yu wrote:
>
> On Sun, Jan 21, 2024 at 5:56 PM Hillf Danton wrote:
> >
> > On Wed, 17 Jan 2024 04:12:10 +0100 Erico Nunes
> > >
> > > @@ -401,9 +399,33 @@ static enum drm_gpu_sched_stat
> > > lima
On Thu, Jan 18, 2024 at 3:01 AM Qiang Yu wrote:
>
> Do we need same for GP?
I don't have an issue reproducer for gp so far, but the hardware does
have the same bit and the mali driver does it for both gp and pp, so I
think we can also add it to gp.
On Thu, Jan 18, 2024 at 3:46 AM Qiang Yu wrote:
>
> On Wed, Jan 17, 2024 at 11:12 AM Erico Nunes wrote:
> > diff --git a/drivers/gpu/drm/lima/lima_sched.h
> > b/drivers/gpu/drm/lima/lima_sched.h
> > index 6a11764d87b3..34050facb110 100644
> > --- a/drivers/gpu/d
On Thu, Jan 18, 2024 at 2:36 AM Qiang Yu wrote:
>
> So this is caused by same job trigger both done and timeout handling?
> I think a better way to solve this is to make sure only one handler
> (done or timeout) process the job instead of just making lima_pm_idle()
> unique.
It's not very clear
flag when doing the hard reset so that we don't
get that message.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_pp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/lima/lima_pp.c b/drivers/gpu/drm/lima/lima_pp.c
index a5c95bed08c0..a8f8f63b8295 100644
Make the messages more consistent by showing the pp name.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_pp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_pp.c b/drivers/gpu/drm/lima/lima_pp.c
index ac097dd75072..d9e178d6645d
to ensure we can never run
into this case.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_sched.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index c3bf8cda8498..66317296d831 100644
--- a/drivers
that there are reliability improvements to the lima timeout
recovery handling, drop the guilty contexts to let the application keep
running in this case.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_ctx.c | 2 +-
drivers/gpu/drm/lima/lima_ctx.h | 1 -
drivers/gpu/drm/lima
This is required for reliable hard resets. Otherwise, doing a hard reset
while a task is still running (such as a task which is being stopped by
the drm_sched timeout handler) may result in random mmu write timeouts
or lockups which cause the entire gpu to hang.
Signed-off-by: Erico Nunes
an issue in
the recovery path.
Panfrost already does some special handling to account for such
"spurious timeouts", it makes sense to have this in lima too to reduce
the chance that it hit users.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_sc
timeouts in the background.
Different applications trigger resets independently but none of them
cause the GPU to hang or the game to stop working.
Erico Nunes (6):
drm/lima: fix devfreq refcount imbalance for job timeouts
drm/lima: reset async_reset on pp hard reset
drm/lima: set bus_stop bi
started since the rework in
commit 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")
where some specific types of applications may hang indefinitely.
Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")
Signed-off-by: Erico Nunes
---
, so account for it
in the ctx_mgr.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_ctx.c | 30 +-
drivers/gpu/drm/lima/lima_ctx.h | 3 +++
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/lima/lima_ctx.c b/drivers/gpu/drm/lima
To track if fds are pointing to the same execution context and export
the expected information to fdinfo, similar to what is done in other
drivers.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_device.h | 3 +++
drivers/gpu/drm/lima/lima_drv.c| 12
drivers/gpu/drm
This exposes an accumulated active time per client via the fdinfo
infrastructure per execution engine, following
Documentation/gpu/drm-usage-stats.rst.
In lima, the exposed execution engines are gp and pp.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_drv.c | 31
|
4154 glxgears |▏ ||▎ |
3661 firefox |▏ ||▏ |
Erico Nunes (3):
drm/lima: add usage counting method to ctx_mgr
drm/lima: allocate unique id per drm_file
drm/lima: add
On Thu, Oct 27, 2022 at 10:05 AM Viresh Kumar wrote:
> Acked-by: Viresh Kumar
Thanks.
Could someone take a final look and apply this? I don't have drm-misc
commit rights.
Erico
arately so it is not
undone in case of a missing optional regulator.
Fixes: d8c32d3971e4 ("drm/lima: Migrate to dev_pm_opp_set_config()")
Signed-off-by: Erico Nunes
---
v2: revert back to using devm_pm_opp_set_clkname and
devm_pm_opp_set_regulators
---
drivers/gpu/drm/lima
Hello,
On Wed, Oct 26, 2022 at 11:36 AM Viresh Kumar wrote:
> You can directly call devm_pm_opp_set_clkname() and
> devm_pm_opp_set_regulators(), like it was done before my patch, for
> single configurations. So basically a simple revert of my commit, with
> additional comments you added above.
arately so it is not
undone in case of a missing optional regulator.
Fixes: d8c32d3971e4 ("drm/lima: Migrate to dev_pm_opp_set_config()")
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_devfreq.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --g
On Wed, Apr 13, 2022 at 12:05 PM Steven Price wrote:
>
> On 11/04/2022 23:15, Dmitry Osipenko wrote:
> > Interrupt context can't sleep. Drivers like Panfrost and MSM are taking
> > mutex when job is released, and thus, that code can sleep. This results
> > into "BUG: scheduling while atomic" if
On Wed, Apr 13, 2022 at 8:05 AM Dmitry Osipenko
wrote:
>
> On 4/13/22 01:59, Erico Nunes wrote:
> > On Tue, Apr 12, 2022 at 9:41 PM Andrey Grodzovsky
> > wrote:
> >>
> >>
> >> On 2022-04-12 14:20, Dmitry Osipenko wrote:
> >>> On 4/12/22 1
On Tue, Apr 12, 2022 at 9:41 PM Andrey Grodzovsky
wrote:
>
>
> On 2022-04-12 14:20, Dmitry Osipenko wrote:
> > On 4/12/22 19:51, Andrey Grodzovsky wrote:
> >> On 2022-04-11 18:15, Dmitry Osipenko wrote:
> >>> Interrupt context can't sleep. Drivers like Panfrost and MSM are taking
> >>> mutex when
is usually not going to be available at all.
The message can be misleading and creates confusion in bug reports.
We can avoid that code path and that particular message when the user
has not explicitly set the max_error_tasks parameter to enable the
feature.
Signed-off-by: Erico Nunes
Reviewed-by
is usually not going to be available at all.
The message can be misleading and creates confusion in bug reports.
We can avoid that code path and that particular message when the user
has not explicitly set the max_error_tasks parameter to enable the
feature.
Signed-off-by: Erico Nunes
---
ma_ip *ip)
> {
> + /* PP has been reset by individual PP resume */
> + ip->data.async_reset = false;
> return 0;
> }
>
> --
Reviewed-by: Erico Nunes
This fixes the issue reported at
https://gitlab.freedesktop.org/lima/linux/-/issues/34 .
__
whether we have an
> > "unwedge" pinctrl state even though on most flows through the driver
> > the unwedge state will just be NULL.
> >
> > Fix it so that we consistently use NULL for no unwedge state.
> >
> > Fixes: 50f9495efe30 ("drm/bridg
Hi,
updating my Pine64+ to the latest drm-misc-next today (427231bc6d5)
started giving me the BUG and Oops below. It's consistently
reproduceable. Without KASAN I still get the Oops.
I was able to bisect it to [50f9495efe308eb25fd921ea7c8c8143ddeeae30]
drm/bridge/synopsys: dw-hdmi: Add "unwedge"
On Fri, May 17, 2019 at 10:43 PM Grodzovsky, Andrey
wrote:
> On 5/17/19 3:35 PM, Erico Nunes wrote:
> > Lima currently defaults to an "infinite" timeout. Setting a 500ms
> > default timeout like most other drm_sched users do fixed the leak for
> > me.
>
>
Hello,
I have recently observed a memory leak issue with lima using
drm-misc-next, which I initially reported here:
https://gitlab.freedesktop.org/lima/linux/issues/24
It is an easily reproduceable memory leak which I was able to bisect to commit:
5918045c4ed4 drm/scheduler: rework job
On Tue, May 21, 2019 at 8:47 AM Koenig, Christian
wrote:
>
> Am 21.05.19 um 01:16 schrieb Erico Nunes:
> > [CAUTION: External Email]
> >
> > After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
> > only deleted when the timeout handler
eaks.
Add the handling for the (timeout == MAX_SCHEDULE_TIMEOUT) case in
drm_sched_cleanup_jobs.
Signed-off-by: Erico Nunes
Cc: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drive
On Tue, May 21, 2019 at 12:51 AM Erico Nunes wrote:
>
> After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
> only deleted when the timeout handler is able to be cancelled
> successfully.
>
> In case no timeout handler is running (timeout == MAX_SCHE
eaks.
Add the handling for the (timeout == MAX_SCHEDULE_TIMEOUT) case in
drm_sched_cleanup_jobs.
Signed-off-by: Erico Nunes
Cc: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drive
00ms value was chosen as it is the current value for all other
embedded gpu drivers using drm sched.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_drv.c | 2 +-
drivers/gpu/drm/lima/lima_sched.c | 11 ---
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gp
59 matches
Mail list logo
