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
On 01/10/2020 16:49, Boris Brezillon wrote:
On Thu, 1 Oct 2020 15:49:39 +0100
Steven Price wrote:
On 01/10/2020 15:01, Boris Brezillon wrote:
If more than two or more jobs end up timeout-ing concurrently, only one
of them (the one attached to the scheduler acquiring the lock) is fully
very
quickly open, submit a job and close you could trigger this (i.e. if
drm_sched_main() never actually enters the while loop).
You should CC some other folk as this doesn't just affect Panfrost.
Reviewed-by: Steven Price
---
This is something I noticed while debugging anothe
On 01/10/2020 15:01, Boris Brezillon wrote:
If more than two or more jobs end up timeout-ing concurrently, only one
of them (the one attached to the scheduler acquiring the lock) is fully
handled. The other one remains in a dangling state where it's no longer
part of the scheduling queue, but sti
On 01/10/2020 12:25, Daniel Vetter wrote:
On Thu, Oct 1, 2020 at 12:58 PM Steven Price wrote:
On 21/09/2020 14:10, Qinglang Miao wrote:
Simplify the return expression.
Signed-off-by: Qinglang Miao
Reviewed-by: Steven Price
As committer/maintainer for this please indicate whether
On 21/09/2020 14:10, Qinglang Miao wrote:
Simplify the return expression.
Signed-off-by: Qinglang Miao
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panfrost
On 21/09/2020 14:10, Qinglang Miao wrote:
Simplify the return expression.
Signed-off-by: Qinglang Miao
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panfrost
On 21/09/2020 08:52, Neil Armstrong wrote:
Hi Steven, Rob,
Should I send a v3 with the commit log fixes ?
No need, I've fixed it up and pushed to drm-misc-next.
Thanks,
Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.
On 17/09/2020 11:51, Tomeu Vizoso wrote:
On 9/17/20 12:38 PM, Steven Price wrote:
On 16/09/2020 18:46, Rob Herring wrote:
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig
wrote:
So I get a performance regression with the dma-coherent approach,
even if it's
clearly the cleaner.
T
On 16/09/2020 18:46, Rob Herring wrote:
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig
wrote:
So I get a performance regression with the dma-coherent approach, even if it's
clearly the cleaner.
That's bizarre -- this should really be the faster of the two.
Coherency may not be free. C
e still need to ensure that
the GPU uses the appropriate cacheable outer-shareable attributes in
order to generate the requisite snoop signals, and that CPU mappings
don't create a mismatch by using a non-cacheable type either.
Signed-off-by: Robin Murphy
LGTM
Reviewed-by: Steven Price
-
th the SoC is not
publicly documented we do not know what does these
values, but they permit having a fully functional GPU running with Panfrost.
Signed-off-by: Neil Armstrong
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 11 +++
drivers/gpu/drm/panfrost/p
On 16/09/2020 16:01, Neil Armstrong wrote:
This adds the required GPU quirks, including the quirk in the PWR registers at
the GPU
reset time and the IOMMU quirk for shareability issues observed on G52 in
Amlogic G12B SoCs.
Signed-off-by: Neil Armstrong
Reviewed-by: Steven Price
mit this.
Signed-off-by: Neil Armstrong
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.h | 3 +++
drivers/gpu/drm/panfrost/panfrost_gpu.c| 4
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/
On 09/09/2020 13:29, Steven Price wrote:
The GPU 'CONFIG' registers used to work around hardware issues are
cleared on reset so need to be programmed every time the GPU is reset.
However panfrost_device_reset() failed to do this.
To avoid this in future instead move t
On 03/09/2020 14:59, Robin Murphy wrote:
Since all we do with scatterlists is map them in the MMU, we don't have
any hardware constraints on how they're laid out. Let the DMA layer know
so it won't warn when DMA API debugging is enabled.
Signed-off-by: Robin Murphy
Applied to drm-misc-next
S
er_on() so that the
regsiters are always programmed just before the cores are powered.
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --g
Subject: s/BROKEN_NS/BROKEN_SH/
Steve
On 08/09/2020 16:18, Neil Armstrong wrote:
The coherency integration of the IOMMU in the Mali-G52 found in the Amlogic
G12B SoCs
is broken and leads to constant and random faults from the IOMMU.
Disabling shareability completely fixes the issue.
Signed-o
On 08/09/2020 16:18, Neil Armstrong wrote:
The T820, G31 & G52 GPUs integratewd by Amlogic in the respective GXM, G12A/SM1
& G12B
SoCs needs a quirk in the PWR registers at the GPU reset time.
Since the documentation of the GPU cores are not public, we do not know what
does these
values, but t
On 08/09/2020 16:18, Neil Armstrong wrote:
The T820, G31 & G52 GPUs integratewd by Amlogic in the respective GXM, G12A/SM1
& G12B
SoCs needs a quirk in the PWR registers at the GPU reset time.
This adds a callback in the device compatible struct of permit this.
Signed-off-by: Neil Armstrong
-
On 08/09/2020 16:18, Neil Armstrong wrote:
Add a pgtbl_quirks entry in the compatible specific table to permit specyfying
IOMMU
quirks for platforms.
Signed-off-by: Neil Armstrong
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.h | 3 +++
drivers/gpu/drm
On 03/09/2020 14:59, Robin Murphy wrote:
Since all we do with scatterlists is map them in the MMU, we don't have
any hardware constraints on how they're laid out. Let the DMA layer know
so it won't warn when DMA API debugging is enabled.
Signed-off-by: Robin Murphy
Reviewed-b
On 09/07/2020 15:03, Clément Péron wrote:
Rename goto labels in device_init it will be easier to maintain.
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Clément Péron
Nice clean up, thanks. As you noted this needs rebasing as the
"regulator init" message has gone.
Reviewed-
x27;s not totally illogic to move
the devfreq_init() and devfreq_fini() here.
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.c | 12 +++-
drivers/gpu/drm/panfrost/panfrost_drv.c
On 09/07/2020 16:44, Rob Herring wrote:
On Sun, Jun 14, 2020 at 12:27 AM Navid Emamdoost
wrote:
in panfrost_job_hw_submit, pm_runtime_get_sync is called which
increments the counter even in case of failure, leading to incorrect
ref count. In case of failure, decrement the ref count before retu
On 09/07/2020 09:48, Christian König wrote:
Am 08.07.20 um 18:19 schrieb Daniel Vetter:
On Wed, Jul 8, 2020 at 6:11 PM Daniel Vetter wrote:
On Wed, Jul 8, 2020 at 5:05 PM Christian König
wrote:
Am 08.07.20 um 17:01 schrieb Daniel Vetter:
On Wed, Jul 8, 2020 at 4:37 PM Christian König
wrote
On 11/06/2020 09:58, Tomeu Vizoso wrote:
Mesa now supports some Bifrost devices, so enable it.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Steven Price
I've also dug out my Hikey960 (from the box it's been in since lock down
started), so I'll see if I can get things running o
-by: Tomeu Vizoso
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index f2c1ddc41a9b..e0f190e43813 10
On 17/06/2020 20:57, Rob Herring wrote:
On Wed, Jun 17, 2020 at 8:36 AM Steven Price wrote:
On 17/06/2020 15:15, Krzysztof Kozlowski wrote:
On Wed, May 27, 2020 at 04:43:34PM -0400, Alyssa Rosenzweig wrote:
Reviewed-by: Alyssa Rosenzweig
On Wed, May 27, 2020 at 10:05:44PM +0200, Krzysztof
) as an error. Also there is no need to print regulator errors
twice.
In case of multiple probe tries this would pollute the dmesg.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Steven Price
---
Changes since v2:
1. Rebase
2. Add Steven's review
Changes since v1:
1. Remove second
Denis Efremov
Reviewed-by: Steven Price
Thanks,
Steve
---
Change in v2:
- kvfree() fixed in panfrost_gem_free_object(), thanks to Steven Price
drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_mmu.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
On 05/06/2020 19:52, Denis Efremov wrote:
Use kvfree() to free bo->sgts, because the memory is allocated with
kvmalloc_array().
Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations")
Cc: sta...@vger.kernel.org
Signed-off-by: Denis Efremov
Well spotted, but there's another
On 29/05/2020 13:35, Clément Péron wrote:
Hi Robin,
On Fri, 29 May 2020 at 14:20, Robin Murphy wrote:
On 2020-05-10 17:55, Clément Péron wrote:
Convert busy_count to a simple int protected by spinlock.
A little more reasoning might be nice.
I have follow the modification requested for li
On 28/05/2020 14:38, Rohan Garg wrote:
Introduce tests to cover the new generic labeling ioctl's
being reviewed here [1].
Signed-off-by: Rohan Garg
[1] https://patchwork.freedesktop.org/series/77267/
Signed-off-by: Rohan Garg
A few comments below.
---
include/drm-uapi/drm.h| 23 ++
On 10/05/2020 17:55, Clément Péron wrote:
Later we will introduce devfreq probing regulator if they
are present. As regulator should be probe only one time we
need to get this logic in the device_init().
panfrost_device is already taking care of devfreq_resume()
and devfreq_suspend(), so it's no
On 10/05/2020 17:55, Clément Péron wrote:
Introduce a boolean to know if opp table has been added.
With this, we can call panfrost_devfreq_fini() in case of error
and release what has been initialised.
Signed-off-by: Clément Péron
LGTM:
Reviewed-by: Steven Price
---
drivers/gpu/drm
looks like it should work - thanks for doing this!
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 19 +++
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 2 ++
drivers/gpu/drm/panfrost/panfrost_device.c | 11 +++
3 files changed, 28 inser
On 10/05/2020 17:55, Clément Péron wrote:
We will later introduce regulators managed by OPP.
Only alloc regulators when it's needed. This also help use
to release the regulators only when they are allocated.
Signed-off-by: Clément Péron
LGTM:
Reviewed-by: Steven Price
---
driver
On 10/05/2020 17:55, Clément Péron wrote:
Instead of expecting an error from dev_pm_opp_of_add_table()
do a simple device_property_present() check.
Signed-off-by: Clément Péron
I'm not sure I understand why this is better. We seem to have more code
to do roughly the same thing just with the
On 10/05/2020 17:55, Clément Péron wrote:
Some SoCs have several clocks defined and the OPP core
needs to know the exact name of the clk to use.
Set the clock name to "core".
Signed-off-by: Clément Péron
This is unfortunately a regression for the RK3288. The device tree
binding doesn't req
ld be safe. As you note this wouldn't work
without devfreq anyway.
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_job.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 79
On 10/05/2020 17:55, Clément Péron wrote:
Introduce a proper panfrost_devfreq to deal with devfreq variables.
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 76 -
drivers/gpu/drm/panfrost/panfrost_devfreq.h
On 10/05/2020 17:55, Clément Péron wrote:
This declaration can be avoided so change it.
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 38 ++---
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a
On 10/05/2020 17:55, Clément Péron wrote:
Convert busy_count to a simple int protected by spinlock.
Signed-off-by: Clément Péron
Looks like a fairly mechanical cleanup.
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 43 +++--
drivers/gpu
On 10/05/2020 17:55, Clément Péron wrote:
Don't include not required headers and sort them.
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gp
On 22/05/2020 14:41, Dinghao Liu wrote:
The caller expects panfrost_job_hw_submit() to increase
runtime PM usage counter. The refcount decrement on the
error branch of WARN_ON() will break the counter balance
and needs to be removed.
Signed-off-by: Dinghao Liu
Reviewed-by: Steven Price
ll to
panfrost_devfreq_record_idle() even if it is cleaning up multiple jobs.
Move the call inside the loop to ensure that the number of
_record_idle() calls matches the number of _record_busy() calls.
Fixes: 9e62b885f715 ("drm/panfrost: Simplify devfreq utilisation tracking")
Signed-off-by: Steven Price
---
On 21/05/2020 08:00, dinghao@zju.edu.cn wrote:
Hi Steve,
There are two bailing out points in panfrost_job_hw_submit(): one is
the error path beginning from pm_runtime_get_sync(), the other one is
the error path beginning from WARN_ON() in the if statement. The pm
imbalance fixed in this patc
On 20/05/2020 12:05, Dinghao Liu wrote:
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
Actually I think we have the opposi
drivers one by one,
dropping the suffix.
v2: add missing space after function name (Jani)
Signed-off-by: Emil Velikov
Acked-by: Sam Ravnborg (v1)
NIT: The subject is wrong: s/drm_object_put/drm_gem_object_put/
With that fixed:
Reviewed-by: Steven Price
Steve
---
include/drm/drm_gem.h
.
Done via the following script:
__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
sed -i "s/$__from/$__to/g" $__file;
done
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Signed-off-by: Emil Velikov
Acked-by: Sam Ravnb
Airlie
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
Acked-by: Sam Ravnborg (v1)
NIT: The subject is wrong: s/drm_object_put/drm_gem_object_put/
With that fixed:
Reviewed-by: Steven Price
Steve
---
Documentation/gpu/drm-mm.rst | 2 +-
drivers/gpu/drm/drm_client.c
subject is wrong: s/drm_object_put/drm_gem_object_put/
Otherwise with that fixes LTGM:
Reviewed-By: Steven Price
Steve
---
drivers/gpu/drm/drm_gem.c | 6 +++---
drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 ++--
drivers/gpu/drm/msm/msm_drv.c | 2 +-
dri
common dma-mapping wrappers operating
directly on the struct sg_table objects and adjust references to the
nents and orig_nents respectively.
Signed-off-by: Marek Szyprowski
The change looks good to me:
Reviewed-by: Steven Price
Although I would have appreciated the commit message being modifie
On 02/05/2020 23:07, Clément Péron wrote:
Hi Steven,
On Tue, 14 Apr 2020 at 15:10, Steven Price wrote:
Hi Clément,
On 13/04/2020 18:28, Clément Péron wrote:
Hi Steven,
Getting a backtrace from the two occurrences, I see one added from:
(debugfs_create_dir) from
nsider adding:
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Even better would be the wrappers you mention in the cover letter! ;)
Reviewed-by: Steven Price
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v2 00/21] DRM: fix struct sg_table
On 14/04/2020 20:16, Clément Péron wrote:
Hi Mark,
On Tue, 14 Apr 2020 at 20:55, Mark Brown wrote:
On Tue, Apr 14, 2020 at 08:20:23PM +0200, Clément Péron wrote:
Hi Liam and Mark,
You might want to flag stuff like this in the subject line, I very
nearly deleted this without opening it sinc
Hi Clément,
On 13/04/2020 18:28, Clément Péron wrote:
Hi Steven,
On Mon, 13 Apr 2020 at 18:35, Clément Péron wrote:
Hi Steven,
On Mon, 13 Apr 2020 at 17:55, Steven Price wrote:
On 13/04/2020 15:31, Clément Péron wrote:
Hi,
On Mon, 13 Apr 2020 at 16:18, Clément Péron wrote:
Hi
On 13/04/2020 15:31, Clément Péron wrote:
Hi,
On Mon, 13 Apr 2020 at 16:18, Clément Péron wrote:
Hi Steven,
On Mon, 13 Apr 2020 at 15:18, Steven Price wrote:
On 11/04/2020 21:06, Clément Péron wrote:
OPP table can defined both frequency and voltage.
Register the mali regulator if it
On 11/04/2020 21:06, Clément Péron wrote:
OPP table can defined both frequency and voltage.
Register the mali regulator if it exist.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 34 ++---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
On 11/04/2020 21:06, Clément Péron wrote:
In case of failure we need to remove OPP table.
Use Linux classic error handling with goto usage.
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 16
1 file changed, 12
On 12/03/2020 16:37, Jason Gunthorpe wrote:
On Thu, Mar 12, 2020 at 04:16:33PM +, Steven Price wrote:
Actually, while you are looking at this, do you think we should be
adding at least READ_ONCE in the pagewalk.c walk_* functions? The
multiple references of pmd, pud, etc without locking
On 12/03/2020 15:11, Jason Gunthorpe wrote:
On Thu, Mar 12, 2020 at 02:40:08PM +, Steven Price wrote:
On 12/03/2020 14:27, Jason Gunthorpe wrote:
On Thu, Mar 12, 2020 at 10:28:13AM +, Steven Price wrote:
By refactoring to deal with the !pud_huge(pud) || !pud_devmap(pud)
condition
On 12/03/2020 14:27, Jason Gunthorpe wrote:
On Thu, Mar 12, 2020 at 10:28:13AM +, Steven Price wrote:
By refactoring to deal with the !pud_huge(pud) || !pud_devmap(pud)
condition early it's possible to remove the 'ret' variable and remove a
level of indentation from half the
By refactoring to deal with the !pud_huge(pud) || !pud_devmap(pud)
condition early it's possible to remove the 'ret' variable and remove a
level of indentation from half the function making the code easier to
read.
No functional change.
Signed-off-by: Steven Price
---
Thanks to
ewalk: add p4d_entry() and pgd_entry()")
Cc: Steven Price
Signed-off-by: Jason Gunthorpe
Sorry about that, thanks for fixing.
Reviewed-by: Steven Price
---
mm/hmm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 9e8f
LL parameter indicates that the power model is simplified and
> created based on DT 'dynamic-power-coefficient', voltage and frequency.
>
> Signed-off-by: Lukasz Luba
LGTM!
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 2 +-
> 1
On Fri, Mar 06, 2020 at 02:13:08PM +, Rob Herring wrote:
> On Thu, Mar 5, 2020 at 8:34 PM Nick Fan wrote:
> >
> > Sorry for my late reply.
> > I have checked internally.
> > The MT8183_POWER_DOMAIN_MFG_2D is just a legacy name, not really 2D
> > domain.
> >
> > If the naming too confusing, we
On 28/02/2020 09:40, Marek Szyprowski wrote:
> Signed-off-by: Marek Szyprowski
Reviewed-by: Steven Price
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 22/02/2020 19:42, Martin Blumenstingl wrote:
> Hi Steven,
>
> On Sun, Jan 12, 2020 at 1:16 AM Martin Blumenstingl
> wrote:
>>
[...]
>>
>>
>> Martin Blumenstingl (3):
>> drm/panfrost: enable devfreq based the "operating-points-v2" property
>> drm/panfrost: call dev_pm_opp_of_remove_table()
b.freedesktop.org/panfrost/mali_kbase/blob/master/driver/product/kernel/drivers/gpu/arm/midgard/backend/gpu/mali_kbase_js_backend.c#L156
>
> Only compile tested.
I've done some quick testing on a Firefly RK3288. But I don't have any
(handy) tests to trigger non-TRANSLATION_FAUL
MT8183 Bifrost
> GPU, we need to handle them in driver code.
>
> Signed-off-by: Nicolas Boichat
LGTM!
Reviewed-by: Steven Price
Thanks,
Steve
>
> ---
>
> The downstream driver we use on chromeos-4.19 currently uses 2
> additional devices in device tree to accomo
501 - 600 of 835 matches
Mail list logo
