On 21/06/2021 15:02, Boris Brezillon wrote:
> From: Steven Price
>
> The hardware has a set of '_NEXT' registers that can hold a second job
> while the first is executing. Make use of these registers to enqueue a
> second job per slot.
>
> v2:
> * Make sure n
On 21/06/2021 14:39, Boris Brezillon wrote:
> panfrost_reset() does not directly signal fences, but
> panfrost_scheduler_start() does, when calling drm_sched_start().
I have to admit to not fully understanding dma_fence_begin_signalling()
- but I thought the idea was that it should have a relative
On 21/06/2021 14:39, Boris Brezillon wrote:
> If the fence creation fail, we can return the error pointer directly.
> The core will update the fence error accordingly.
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost
On 21/06/2021 14:39, Boris Brezillon wrote:
> If the process who submitted these jobs decided to close the FD before
> the jobs are done it probably means it doesn't care about the result.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_job.c | 33 +++
On 21/06/2021 14:39, Boris Brezillon wrote:
> If we can recover from a fault without a reset there's no reason to
> issue one.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_device.c | 9 ++
> drivers/gpu/drm/panfrost/panfrost_device.h | 2 ++
> drivers/gpu/dr
On 21/06/2021 14:39, Boris Brezillon wrote:
> Do the exception -> string translation using a table so we can add extra
> fields if we need to. While at it add an error field to ease the
> exception -> error conversion which we'll need if we want to set the
> fence error to something that reflects t
On 21/06/2021 14:39, Boris Brezillon wrote:
> Things are unlikely to resolve until we reset the GPU. Let's not wait
> for other faults/timeout to happen to trigger this reset.
>
> Signed-off-by: Boris Brezillon
This one still haunts me... ;)
Reviewed-by: Steven Price
> --
On 21/06/2021 14:39, Boris Brezillon wrote:
> Expose a helper to trigger a GPU reset so we can easily trigger reset
> operations outside the job timeout handler.
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/pan
On 21/06/2021 14:39, Boris Brezillon wrote:
> If we don't do that, we have to wait for the job timeout to expire
> before the fault jobs gets killed.
>
> Signed-off-by: Boris Brezillon
Don't we need to do something here to allow recovery of the MMU context
in the future? panfrost_mmu_disable() w
On 21/06/2021 15:49, Boris Brezillon wrote:
> On Mon, 21 Jun 2021 15:34:35 +0100
> Steven Price wrote:
>
>> On 21/06/2021 14:38, Boris Brezillon wrote:
>>> Exception types will be defined as an enum in panfrost_drm.h so userspace
>>> and use the same definit
On 21/06/2021 14:38, Boris Brezillon wrote:
> Job headers contain an exception type field which might be read and
> converted to a human readable string by tracing tools. Let's expose
> the exception type as an enum so we share the same definition.
>
> Signed-off-by: Boris Brezillon
> ---
> incl
On 21/06/2021 14:38, Boris Brezillon wrote:
> Currently unused. We'll add it back if we need per-GPU definitions.
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
Side note: we could use the definitions such as JS_STATUS_EVENT_ACTIVE
in panfrost_exception_name() rat
On 21/06/2021 14:38, Boris Brezillon wrote:
> Exception types will be defined as an enum in panfrost_drm.h so userspace
> and use the same definitions if needed.
s/and/can/ ?
While it is (currently) unused in the kernel, this is a hardware value
so I'm not sure why it's worth removing this and no
od between
issuing the hard-stop and actually having completed all jobs in the context.
But equally to be fair I've been cherry-picking this patch myself for
quite some time, so we should just merge it and improve from there. So
you can have my:
Reviewed-by: Steven Price
ng you can send a properly formatted
patch to the list.
PPS. I'm still not receiving your emails directly. I don't think it's a
problem at my end because I'm receiving other emails, but if you can
somehow fix the problem you're likely to receive a faster response.
> ??
ngs[i] will set to NULL,and the
> while will be continue,so if job->mappings[i] is NULL,the following
> can not be NULL.
I agree that with the above code the panfrost_job_cleanup() would need
changing. But we don't (currently) have this code upstream, so this
change doesn't make s
On 17/06/2021 09:04, ChunyouTang wrote:
> From: ChunyouTang
>
> The 'break' can cause 'Memory manager not clean during takedown'
>
> It cannot use break to finish the circulation,it should use
>
> continue to traverse the circulation.it should put every mapping
>
> which is not NULL.
You don'
On 17/06/2021 07:20, ChunyouTang wrote:
> From: ChunyouTang
>
> of the low 8 bits.
Please don't split the subject like this. The first line of the commit
should be a (very short) summary of the patch. Then a blank line and
then a longer description of what the purpose of the patch is and why
it'
clearly this
is something we need to fix.
Thanks,
Steve
> atomic_dec(&job->mappings[i]->obj->gpu_usecount);
> panfrost_gem_mapping_put(job->mappings[i]);
>
>
> Thank you!
>
>
>
> ?? Fri, 11 Jun 2021 11:
On 08/06/2021 15:38, Wei Yongjun wrote:
> Fix the missing clk_disable_unprepare() before return
> from panfrost_clk_init() in the error handling case.
>
> Fixes: b681af0bc1cc ("drm: panfrost: add optional bus_clock")
> Reported-by: Hulk Robot
> Signed-off-by: Wei Y
atus & 0xFF),
>> address);
>
> So I change it according to what you said?
Yes, please send a v2.
Thanks,
Steve
> ?? Thu, 10 Jun 2021 11:41:52 +0100
> Steven Price :
>
>> The subject should have the prefix "drm/panfrost" and should
The subject should have the prefix "drm/panfrost" and should mention
what the patch is changing (not just the filename).
On 09/06/2021 07:38, ChunyouTang wrote:
> From: tangchunyou
>
> The GPU exception fault status register(0x3C),the low 8 bit is the
> EXCEPTION_TYPE.We can see the description
sc-next.
Thanks,
Steve
> chip, and perhaps others.
>
> v2: Fix typo from copy-paste fail.
>
> v3: Bump the UABI version. This commit was cherry-picked from another
> series so chalking this up to a rebase fail.
>
> Signed-off-by: Alyssa Rosenzweig
> R
o chalking this up to a rebase fail.
I'd like to say third time's the charm, but...
>
> Signed-off-by: Alyssa Rosenzweig
> Cc: Rob Herring
> Cc: Tomeu Vizoso
> Cc: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
> drivers/gpu/drm/p
On 02/06/2021 19:51, Daniel Vetter wrote:
> On Wed, Jun 02, 2021 at 03:06:50PM +0100, Steven Price wrote:
>> On 21/05/2021 10:09, Daniel Vetter wrote:
[...]
>>> + if (!xa_empty(&job->deps))
>>> + return xa_erase(&job->deps, job->last
duler people for this too.
>
> Cc: "Christian König"
> Cc: Luben Tuikov
> Cc: Alex Deucher
> Cc: Lee Jones
> Cc: Steven Price
> Cc: Rob Herring
> Cc: Tomeu Vizoso
> Cc: Alyssa Rosenzweig
> Cc: Sumit Semwal
> Cc: linux-me...@vger.kernel.org
>
On 27/05/2021 21:38, alyssa.rosenzw...@collabora.com wrote:
> From: Alyssa Rosenzweig
>
> If a job requires cycle counters or timestamps, we must enable cycle
> counting just before issuing the job, and disable as soon as the job
> completes.
>
> Since this extends the UABI, we bump the driver m
On 27/05/2021 21:38, alyssa.rosenzw...@collabora.com wrote:
> From: Alyssa Rosenzweig
>
> Wrap the underlying CYCLE_COUNT_START/STOP commands in a safe interface
> that ensures the commands are only issued where required by guarding
> behind an atomic counter. In particular, we need to be careful
On 27/05/2021 21:38, alyssa.rosenzw...@collabora.com wrote:
> From: Alyssa Rosenzweig
>
> Add additional values of GPU_COMMAND required to enable and disable the
> cycle (and timestamp) counters. Values from mali_kbase.
>
> Signed-off-by: Alyssa Rosenzweig
Reviewe
On 27/05/2021 21:38, alyssa.rosenzw...@collabora.com wrote:
> From: Alyssa Rosenzweig
>
> Extend the Panfrost UABI with a new job requirement for cycle counters
> (and GPU timestamps, by extension). This requirement is used in
> userspace to implement ARB_shader_clock, an OpenGL extension reporti
eap allocations")
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> b/drivers/gpu/drm/panfrost/panfrost_mmu
On 14/05/2021 15:48, Neil Armstrong wrote:
> On 13/05/2021 16:55, Ezequiel Garcia wrote:
>> Hi Neil,
>>
>> On Mon, 26 Apr 2021 at 06:59, Neil Armstrong wrote:
>>>
>>> Hi,
>>>
>>> On 21/04/2021 07:28, Nicolas Boichat wrote:
Hi!
This is just a rebase of the v11, untested (but it seems
printing here to simplify code and reduce the
binary size.
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
Reviewed-by: Steven Price
I'll push to drm-misc-next.
Thanks,
Steve
---
drivers/gpu/drm/panfrost/panfrost_device.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gp
or to return a failure code from panfrost_job_hw_submit() and
report the failure back to the DRM scheduler. This means there's no need
to wait for the scheduler to timeout on the job and the failure can be
handled immediately.
Signed-off-by: Steven Price
---
This hopefully will also stop future
On 11/05/2021 07:29, Zou Wei wrote:
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Reported-by: Hulk Robot
Signed-off-by
On 26/04/2021 17:37, Claire Chang wrote:
On Fri, Apr 23, 2021 at 7:34 PM Steven Price wrote:
[...]
But even then if it's not and we have the situation where debugfs==NULL
then the debugfs_create_dir() here will cause a subsequent attempt in
swiotlb_create_debugfs() to fail (directory al
On 22/04/2021 09:14, Claire Chang wrote:
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Signed-off-by: Claire Chang
---
include/linux/device.h | 4 +++
include/linux/swiotlb.h | 3 +-
kernel/dma/swiotlb.c| 80 ++
n top of struct drm_sched_job. So there may be scope for cleaning
up Panfrost afterwards even if your work doesn't directly affect it.
Thanks,
Steve
Best,
Jack
-Original Message-----
From: Steven Price
Sent: Monday, March 22, 2021 11:29 PM
To: Zhang, Jack (Jian) ;
On 15/03/2021 05:23, Zhang, Jack (Jian) wrote:
[AMD Public Use]
Hi, Rob/Tomeu/Steven,
Would you please help to review this patch for panfrost driver?
Thanks,
Jack Zhang
-Original Message-
From: Jack Zhang
Sent: Monday, March 15, 2021 1:21 PM
To: dri-devel@lists.freedesktop.org; amd-.
On 11/03/2021 09:25, Boris Brezillon wrote:
Hello,
I've been playing with Vulkan lately and struggled quite a bit to
implement VkQueueSubmit with the submit ioctl we have. There are
several limiting factors that can be worked around if we really have to,
but I think it'd be much easier and futur
el Lezcano
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 14 +-
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 3 ---
2 files changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/dr
On 23/02/2021 15:51, Neil Roberts wrote:
These two patches fix a problem with the madvise purging code for the
shmem helpers where the mmaping for a purged buffer wouldn't get
invalidated correctly. This presumably ends up as a security hole
where the mapping can be accessed from user-space to re
On 04/03/2021 12:50, Daniel Lezcano wrote:
Currently the default behavior is to manually having the devfreq
backend to register themselves as a devfreq cooling device.
There are no so many and actually it makes more sense to register the
devfreq device when adding it.
Consequently, every devfre
from other buffers
v2: Don't check whether the unsigned page_offset is less than 0.
Cc: sta...@vger.kernel.org
Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers")
Signed-off-by: Neil Roberts
Reviewed-by: Steven Price
---
drivers/gpu/drm/drm_gem
purge helpers")
Signed-off-by: Neil Roberts
Reviewed-by: Steven Price
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_help
On 19/02/2021 15:13, Daniel Vetter wrote:
On Fri, Feb 19, 2021 at 01:36:06PM +, Steven Price wrote:
On 18/02/2021 18:20, Daniel Vetter wrote:
On Thu, Feb 18, 2021 at 6:16 PM Rob Herring wrote:
On Thu, Feb 18, 2021 at 10:51 AM Steven Price wrote:
On 18/02/2021 16:38, Rob Herring wrote
On 18/02/2021 18:20, Daniel Vetter wrote:
On Thu, Feb 18, 2021 at 6:16 PM Rob Herring wrote:
On Thu, Feb 18, 2021 at 10:51 AM Steven Price wrote:
On 18/02/2021 16:38, Rob Herring wrote:
On Thu, Feb 18, 2021 at 10:15 AM Steven Price wrote:
On 18/02/2021 15:45, Alyssa Rosenzweig wrote
On 18/02/2021 16:38, Rob Herring wrote:
On Thu, Feb 18, 2021 at 10:15 AM Steven Price wrote:
On 18/02/2021 15:45, Alyssa Rosenzweig wrote:
Yeah plus Cc: stable for backporting and I think an igt or similar for
panfrost to check this works correctly would be pretty good too. Since
if it took
On 18/02/2021 15:45, Alyssa Rosenzweig wrote:
Yeah plus Cc: stable for backporting and I think an igt or similar for
panfrost to check this works correctly would be pretty good too. Since
if it took us over 1 year to notice this bug it's pretty clear that
normal testing doesn't catch this. So ver
On 17/02/2021 16:59, Neil Roberts wrote:
When mmapping the shmem, it would previously adjust the pgoff in the
vm_area_struct to remove the fake offset that is added to be able to
identify the buffer. This patch removes the adjustment and makes the
fault handler use the vm_fault address to calcula
On 05/02/2021 11:17, Boris Brezillon wrote:
Doing a hw-irq -> threaded-irq round-trip is counter-productive, stay
in the threaded irq handler as long as we can.
v2:
* Rework the loop to avoid a goto
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfr
want an unsigned long pointer
as input and just dumbly casting leads to out-of-bounds accesses.
This fixes that.
Signed-off-by: Carsten Haitzler
Looks fine to me:
Reviewed-by: Steven Price
---
.../drm/arm/display/include/malidp_utils.h| 3 ---
.../drm/arm/display/komeda
On 03/02/2021 14:45, Rob Herring wrote:
On Mon, Feb 1, 2021 at 2:21 AM Boris Brezillon
wrote:
Doing a hw-irq -> threaded-irq round-trip is counter-productive, stay
in the threaded irq handler as long as we can.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 7
On 01/02/2021 12:59, Boris Brezillon wrote:
On Mon, 1 Feb 2021 12:13:49 +
Steven Price wrote:
On 01/02/2021 08:21, Boris Brezillon wrote:
Doing a hw-irq -> threaded-irq round-trip is counter-productive, stay
in the threaded irq handler as long as we can.
Signed-off-by: Boris Brezil
Back-to-back MMU faults should (hopefully) be
fairly uncommon.
Regardless:
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu
("drm/panfrost: Add support for GPU heap allocations")
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drive
: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations")
Signed-off-by: Boris Brezillon
Good catch (although this oddly rings a bell - so perhaps it was me you
discussed it with before)
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 4 ++-
NIT: This is the second version of this patch so should have "[PATCH
v2]" in the subject.
On 27/01/2021 12:34, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is buried inside the
dp_for_each_set_bit() macro (that passes on to for_each
On 22/01/2021 10:00, Lukasz Luba wrote:
On 1/22/21 8:21 AM, Steven Price wrote:
On 21/01/2021 17:04, Lukasz Luba wrote:
The simple_ondemand devfreq governor uses two thresholds to decide about
the frequency change: upthreshold, downdifferential. These two tunable
change the behavior of the
On 22/01/2021 10:11, Lukasz Luba wrote:
On 1/21/21 5:15 PM, Daniel Lezcano wrote:
On 21/01/2021 18:04, Lukasz Luba wrote:
The simple_ondemand devfreq governor uses two thresholds to decide about
the frequency change: upthreshold, downdifferential. These two tunable
change the behavior of the
% threshold more easily (AFAICT kbase
uses the default 90/5 thresholds), but this seems like a reasonable
change for now.
Reviewed-by: Steven Price
Thanks,
Steve
[1] When I get some time I need to rework the "queue jobs on the
hardware"[2] patch I posted ages ago. Last time it actua
On 21/01/2021 12:22, Carsten Haitzler wrote:
On 1/20/21 3:44 PM, Steven Price wrote:
On 18/01/2021 14:20, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is bueried inside the
NIT: s/bueried/buried/
Yup. typo not spotted by me
: Christian Gmeiner
Cc: Qiang Yu
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Eric Anholt
Reported-by: kernel test robot
Signed-off-by: Luben Tuikov
Acked-by: Steven Price
___
dri-devel mailing list
dri-dev
On 18/01/2021 14:20, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is bueried inside the
NIT: s/bueried/buried/
dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that
calls the bit stuff. These bit functions want an
On 13/01/2021 06:07, Nicolas Boichat wrote:
Add support for MT8183's G72 Bifrost.
Signed-off-by: Nicolas Boichat
Reviewed-by: Tomeu Vizoso
LGTM
Reviewed-by: Steven Price
---
(no changes since v7)
Changes in v7:
- Fix GPU ID in commit message
Changes in v6:
- Context conf
thout taking care of those constraints.
Disable devfreq for now on those GPUs.
Signed-off-by: Nicolas Boichat
Reviewed-by: Tomeu Vizoso
Thanks for the clarification in the commit message.
Reviewed-by: Steven Price
---
(no changes since v9)
Changes in v9:
- Explain why devfreq needs
On 05/01/2021 16:41, Lukasz Luba wrote:
Devfreq framework supports 2 modes for monitoring devices.
Use delayed timer as default instead of deferrable timer
in order to monitor the GPU status regardless of CPU idle.
Signed-off-by: Lukasz Luba
Looks reasonable to me.
Reviewed-by: Steven Price
On 05/01/2021 05:36, Nick Fan wrote:
Add a basic GPU node for mt8192.
Signed-off-by: Nick Fan
---
This patch depends on Mediatek power and regulator support.
Listed as following.
[1]https://lore.kernel.org/patchwork/patch/1336293/
[2]https://patchwork.kernel.org/project/linux-mediatek/list/?s
On 05/01/2021 00:11, Nicolas Boichat wrote:
GPUs with more than a single regulator (e.g. G-57 on MT8183) will
require platform-specific handling, disable devfreq for now.
Can you explain what actually goes wrong here? AFAICT the existing code
does support controlling multiple regulators - but
On 01/01/2021 16:54, Yangtao Li wrote:
Use devm_pm_opp_* API to simplify code, and remove opp_table
from panfrost_devfreq.
Signed-off-by: Yangtao Li
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 34 ++---
drivers/gpu/drm/panfrost
On 11/12/2020 21:44, Luben Tuikov wrote:
On 2020-12-10 4:46 a.m., Steven Price wrote:
On 10/12/2020 02:14, Luben Tuikov wrote:
This patch does not change current behaviour.
The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the task (job
Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Eric Anholt
Reported-by: kernel test robot
This reported-by seems a little odd for this patch.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 6 +++--
drivers/gpu/drm/etnaviv/etnaviv_sched
)
+ if (!old_st ||
+ memcmp(&(to_compiz_st(old_st)->cins[idx]), cin, sizeof(*cin)))
c_st->changed_active_inputs |= BIT(idx);
Even better, you can move the WARN_ON into the if:
if (WARN_ON(!old_st) || ...
Either way:
Reviewed-by
On 27/11/2020 11:00, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
ret is not actually read after this (only written in one case then
returned), so this assign line is useless. This removes that assignment.
Signed-off-by: Carsten Haitzler
Reviewed-by: Steven Price
On 27/11/2020 09:44, Qinglang Miao wrote:
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to putting operation will result in a
reference leak here.
A new function pm_runtime_resume_and_get is introduced in
[0] to keep usage counter balanced. So We fix the referenc
y: Robin Murphy
LGTM
Reviewed-by: Steven Price
---
Reviewing the Mediatek TLB optimisation patches just left me thinking
"why do we even have this?"... Panfrost folks, this has zero functional
impact to you, merely wants an ack for straying outside drivers/iommu.
Robin.
driver
On 25/11/2020 11:15, Lucas Stach wrote:
Am Mittwoch, den 25.11.2020, 11:04 + schrieb Steven Price:
On 25/11/2020 03:17, Luben Tuikov wrote:
The job timeout handler now returns status
indicating back to the DRM layer whether the job
was successfully cancelled or whether more time
should be
On 25/11/2020 03:17, Luben Tuikov wrote:
Add a "done" list to which all completed jobs are added
to be freed. The drm_sched_job_done() callback is the
producer of jobs to this list.
Add a "done" thread which consumes from the done list
and frees up jobs. Now, the main scheduler thread only
pushe
On 25/11/2020 03:17, Luben Tuikov wrote:
The job timeout handler now returns status
indicating back to the DRM layer whether the job
was successfully cancelled or whether more time
should be given to the job to complete.
I'm not sure I understand in what circumstances you would want to give
th
- Simplify panfrost_scheduler_stop() (Steven Price)
- Always restart the queue in panfrost_scheduler_start() even if
the status is corrupted (Steven Price)
v4:
- Rework the logic to prevent a race between drm_sched_start()
(reset work) and drm_sched_job_timedout() (timeout work)
- Drop Steven's R-b
On 06/11/2020 07:03, Viresh Kumar wrote:
The dev_pm_opp_put_*() APIs now accepts a NULL opp_table pointer and so
there is no need for us to carry the extra check. Drop them.
Signed-off-by: Viresh Kumar
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 6
- Simplify panfrost_scheduler_stop() (Steven Price)
- Always restart the queue in panfrost_scheduler_start() even if
the status is corrupted (Steven Price)
v4:
- Rework the logic to prevent a race between drm_sched_start()
(reset work) and drm_sched_job_timedout() (timeout work)
- Drop Steven's R-b
x27;s R-b
v2:
- Use atomic_cmpxchg() to conditionally schedule the reset work (Steven Price)
Fixes: 1a11a88cfd9a ("drm/panfrost: Fix job timeout handling")
Cc:
Signed-off-by: Boris Brezillon
Hi Boris,
A couple of nits below, but otherwise looks good.
---
drivers/gpu/drm/panfrost/panfr
On 03/11/2020 01:48, Yejune Deng wrote:
devm_reset_control_array_get_optional_exclusive() looks more readable
Signed-off-by: Yejune Deng
Reviewed-by: Steven Price
Thanks, I'll push this to drm-misc-next.
Steve
---
drivers/gpu/drm/panfrost/panfrost_device.c | 2 +-
1 file chang
On 02/11/2020 09:33, Zou Wei wrote:
Fixes the following W=1 kernel build warning:
./panfrost_job.c:617:28: warning: unused variable ‘js’ [-Wunused-variable]
struct panfrost_job_slot *js = pfdev->js;
^~
Reported-by: Hulk Robot
Signed-off-by: Zou Wei
Boris post
On 02/11/2020 08:54, Yejune Deng wrote:
Some dts hasn't no reset node, is should ok.
Signed-off-by: Yejune Deng
---
drivers/gpu/drm/panfrost/panfrost_device.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/
;)
Cc:
Cc: Christian Hewitt
Reported-by: Christian Hewitt
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_gem.c | 4 +---
drivers/gpu/drm/panfrost/panfrost_gem.h | 2 +-
drivers/gpu/drm/panfrost/panfrost_gem_shrin
orrupt the queue mutex on
open/close")
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
My bad, I didn't notice this warning when rebasing Steven's patch on
top of drm-misc-next :-/
Partly my fault - I think I forgot to rebase the patch on drm-misc-next
befor
ended using pm_runtime_set_suspended(). And also
include this on the error path in panfrost_probe().
Fixes: aebe8c22a912 ("drm/panfrost: Fix possible suspend in panfrost_remove")
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 5 +++--
1 file changed, 3 i
pxchg() to conditionally schedule the reset work (Steven Privce)
Fixes: 1a11a88cfd9a ("drm/panfrost: Fix job timeout handling")
Cc:
Signed-off-by: Boris Brezillon
LGTM!
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.c | 1 -
drivers/gpu/drm/panfrost/pan
On 30/10/2020 10:28, Boris Brezillon wrote:
On Fri, 30 Oct 2020 10:00:07 +
Steven Price wrote:
On 30/10/2020 07:08, Boris Brezillon wrote:
We've fixed many races in panfrost_job_timedout() but some remain.
Instead of trying to fix it again, let's simplify the logic and move
On 30/10/2020 07:08, Boris Brezillon wrote:
We've fixed many races in panfrost_job_timedout() but some remain.
Instead of trying to fix it again, let's simplify the logic and move
the reset bits to a separate work scheduled when one of the queue
reports a timeout.
Fixes: 1a11a88cfd9a ("drm/panfr
it
belongs.
Fixes: 1a11a88cfd9a ("drm/panfrost: Fix job timeout handling")
Signed-off-by: Steven Price
Reviewed-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_job.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfros
On 26/10/2020 15:32, Boris Brezillon wrote:
In our last attempt to fix races in the panfrost_job_timedout() path we
overlooked the case where a re-submitted job immediately triggers a
fault. This lead to a situation where we try to stop a scheduler that's
not resumed yet and lose the 'timedout' e
: Add initial panfrost driver")
Suggested-by: Steven Price
Signed-off-by: Christian Hewitt
Reviewed-by: Steven Price
I'll push this to drm-misc-next-fixes so it should coincide with the
Bifrost support already in drm-misc-next.
Steve
---
drivers/gpu/drm/panfrost/panfrost_gpu.c |
- Stop the scheduler before returning from panfrost_job_timedout()
- Call cancel_delayed_work_sync() after drm_sched_stop() to make sure
no timeout handlers are in flight when we reset the GPU (Steven Price)
- Make sure we release the reset lock before restarting the
schedulers (Steven Price)
outer shareable domain, and so
even when snoop signals are wired up, they are only emitted for outer
shareable accesses. As such, setting the TTBR_SHARE_OUTER bit does
indeed get coherent pagetable walks working nicely for the coherent
T620 in the Arm Juno SoC.
Reviewed-by: Steven Price
Tested-by:
On 05/10/2020 09:39, Boris Brezillon wrote:
On Mon, 5 Oct 2020 09:34:06 +0100
Steven Price wrote:
On 05/10/2020 09:15, Boris Brezillon wrote:
Hi Robin, Neil,
On Wed, 16 Sep 2020 10:26:43 +0200
Neil Armstrong wrote:
Hi Robin,
On 16/09/2020 01:51, Robin Murphy wrote:
According to a
On 05/10/2020 09:15, Boris Brezillon wrote:
Hi Robin, Neil,
On Wed, 16 Sep 2020 10:26:43 +0200
Neil Armstrong wrote:
Hi Robin,
On 16/09/2020 01:51, Robin Murphy wrote:
According to a downstream commit I found in the Khadas vendor kernel,
the GPU on G12b is wired up for ACE-lite, so (now tha
_work_sync() after drm_sched_stop() to make sure
no timeout handlers are in flight when we reset the GPU (Steven Price)
- Make sure we release the reset lock before restarting the
schedulers (Steven Price)
Signed-off-by: Boris Brezillon
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfr
401 - 500 of 806 matches
Mail list logo
