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 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 09/01/2020 19:49, Mark Brown wrote:
> On Thu, Jan 09, 2020 at 04:53:02PM +0000, Steven Price wrote:
>> On 09/01/2020 16:28, Mark Brown wrote:
>>> On Thu, Jan 09, 2020 at 02:14:42PM +, Steven Price wrote:
>
>>>> I'm not sure if it's b
On 09/01/2020 16:56, Rob Herring wrote:
> On Wed, Jan 8, 2020 at 4:52 PM Nicolas Boichat wrote:
>>
>> On Wed, Jan 8, 2020 at 9:23 PM Mark Brown wrote:
>>>
>>> On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote:
>>>
Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
On 09/01/2020 17:27, Martin Blumenstingl wrote:
> On Thu, Jan 9, 2020 at 12:31 PM Steven Price wrote:
>>
>> On 07/01/2020 23:06, Martin Blumenstingl wrote:
>>> dev_pm_opp_set_rate() needs a reference to the regulator which should be
>>> updated when updating t
creation")
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Cc:
> Signed-off-by: Boris Brezillon
> Signed-off-by: Rob Herring
Reviewed-by: Steven Price
Thanks,
Steve
> ---
> With the actual changes committed this time...
>
On Thu, Jan 16, 2020 at 04:39:37PM +, Sasha Levin wrote:
> From: Steven Price
>
> [ Upstream commit 52282163dfa651849e905886845bcf6850dd83c2 ]
This commit is effectively already in 5.4. Confusingly there were two
versions of this upstream:
52282163dfa6 ("drm/panfrost: Add mis
On 14/01/2020 07:15, Nicolas Boichat wrote:
> Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
> regulator for their SRAM, let's add support for that.
>
> We extend the framework in a generic manner so that we could
> support more than 2 regulators, if required.
>
> Signed-off-by:
On 14/01/2020 07:16, Nicolas Boichat wrote:
> When there is a single power domain per device, the core will
> ensure the power domain is switched on (so it is technically
> equivalent to having not power domain specified at all).
>
> However, when there are multiple domains, as in MT8183 Bifrost
>
On 20/01/2020 17:03, Mark Brown wrote:
> On Mon, Jan 20, 2020 at 02:43:10PM +0000, Steven Price wrote:
>
>> From discussions offline, I think I've come round to the view that
>> having a "soft PDC" in device tree isn't the right solution. Device tree
>>
On 21/01/2020 04:37, Nicolas Boichat wrote:
On Tue, Jan 14, 2020 at 10:16 PM Mark Brown wrote:
On Tue, Jan 14, 2020 at 03:15:59PM +0800, Nicolas Boichat wrote:
- I couldn't find a way to detect the number of regulators in the
device tree, if we wanted to refuse to probe the device if t
ot that before! Thanks for fixing it.
Note commit bdefca2d8dc0 is actually in v5.5 and not (yet) in
drm-misc-next.
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_job.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers
On 04/02/2020 14:35, Boris Brezillon wrote:
> Jobs can be in-flight when the file descriptor is closed (either because
> the process did not terminate properly, or because it didn't wait for
> all GPU jobs to be finished), and apparently panfrost_job_close() does
> not cancel already running jobs.
dled the case where
job->base.s_fence->finished.error is non-zero. Is there a good reason to
drop that?
[1] https://patchwork.kernel.org/patch/11267153/
But this change on its own stands, so:
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
> 1 fi
On 05/02/2020 13:25, Robin Murphy wrote:
> On 05/02/2020 10:07 am, Tomeu Vizoso wrote:
>> If the exception type isn't one of the normal faults, don't try to map
>> and instead go straight to a terminal fault.
>
> "One of the the normal faults" seems a rather vague way of saying "a
> translation fa
On 05/02/2020 14:01, Boris Brezillon wrote:
> On Wed, 5 Feb 2020 13:39:21 +
> Steven Price wrote:
>
>> On 04/02/2020 14:35, Boris Brezillon wrote:
>>> Jobs can be in-flight when the file descriptor is closed (either because
>>> the process did not termina
On Wed, Feb 05, 2020 at 02:21:55PM +, Boris Brezillon wrote:
> On Wed, 5 Feb 2020 13:47:55 +
> Steven Price wrote:
>
> > On 04/02/2020 14:35, Boris Brezillon wrote:
> > > ->job_run() can return an ERR_PTR() if somethings fails. Let's
>
On 06/02/2020 14:13, Boris Brezillon wrote:
> We need to use the AS attached to the opened FD when dumping counters.
Indeed we do!
Reviewed-by: Steven Price
>
> Reported-by: Antonio Caggiano
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Cc
On 09/09/2019 16:51, Krzysztof Kozlowski wrote:
> There is no point to print deferred probe (and its failures to get
> resources) as an error.
>
> In case of multiple probe tries this would pollute the dmesg.
>
> Signed-off-by: Krzysztof Kozlowski
Looks like a good idea, however from what I can
o makes way for being able to submit multiple jobs per slot
which requires more values than the original boolean per slot.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 64 -
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 3 +-
drivers/g
de changes from
52282163dfa6 and e21dd290881b which would otherwise need reverting, see
the previous discussion[2].
[1] https://lore.kernel.org/lkml/20190904123032.23263-1-broo...@kernel.org/
[2] https://lore.kernel.org/lkml/ccd81530-2dbd-3c02-ca0a-1085b0066...@arm.com/
Steven Price (2):
drm/panfrost: U
Use dev_pm_opp_set_rate() instead of open coding the devfreq
integration, simplifying the code.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 62 -
drivers/gpu/drm/panfrost/panfrost_device.h | 2 -
2 files changed, 10 insertions(+), 54
On 07/09/2019 20:36, Daniel Vetter wrote:
> On Fri, Sep 6, 2019 at 2:42 PM Steven Price wrote:
>>
>> On 06/09/2019 12:10, Rob Herring wrote:
>>> On Thu, Sep 5, 2019 at 1:11 PM Steven Price wrote:
>>>>
>>>> When handling a GPU page fault addr_to
On 13/09/2019 12:17, Boris Brezillon wrote:
> The READ/WRITE flags are particularly useful if we want to avoid
> serialization of jobs that read from the same BO but never write to it.
> The NO_IMPLICIT_FENCE might be useful when the user knows the BO is
> shared but jobs are using different portio
On 13/09/2019 12:17, Boris Brezillon wrote:
> So we can choose to wait for all BO users, or just for writers.
>
> Signed-off-by: Boris Brezillon
Looks good to me:
Reviewed-by: Steven Price
Although I don't know if the term "writers" should be in the API or if
&quo
On 13/09/2019 13:29, Gerd Hoffmann wrote:
> Switch gem shmem helper to the new mmap() workflow,
> from &gem_driver.fops.mmap to &drm_gem_object_funcs.mmap.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_gem_shmem_helper.h | 6 ++
> drivers/gpu/drm/drm_gem_shmem_helper.c | 26
Hi,
I hit the below splat randomly with panfrost. From what I can tell this
is a more general issue which would affect other drivers.
8<-
[58604.913130] [ cut here ]
[58604.918590] WARNING: CPU: 1 PID: 1758 at kernel/sched/core.c:6556
__might_sleep+0x74/0x98
[5860
panfrost_gem_object with an
extra reference on it, preventing the BO from being freed until after
the page fault has been handled.
Signed-off-by: Steven Price
---
Changes since v1:
* Hold the mm_lock around drm_mm_for_each_node()
I've also posted a new IGT test for this:
https://patchwork.freedesktop.org/
s I might as well fix them!
Steve
On Thu, Sep 05, 2019 at 01:11:41PM +0100, Steven Price wrote:
When handling a GPU page fault addr_to_drm_mm_node() is used to
translate the GPU address to a buffer object. However it is possible for
the buffer object to be freed after the function has returned r
bs.
Thanks,
Steve
Regards,
Christian.
Am 13.09.19 um 16:50 schrieb Steven Price:
Hi,
I hit the below splat randomly with panfrost. From what I can tell this
is a more general issue which would affect other drivers.
8<-
[58604.913130] [ cut here ]
[58604.9185
On 17/09/2019 10:23, Gerd Hoffmann wrote:
> Switch gem shmem helper to the new mmap() workflow,
> from &gem_driver.fops.mmap to &drm_gem_object_funcs.mmap.
>
> v2: Fix vm_flags and vm_page_prot handling.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Steven Pr
sters. shmem gem objects surely don't need that ...
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/
On 17/09/2019 10:23, Gerd Hoffmann wrote:
> VM_IO is wrong here, shmem uses normal ram not io memory.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
&
On 17/09/2019 08:15, Boris Brezillon wrote:
> On Mon, 16 Sep 2019 17:20:28 -0500
> Rob Herring wrote:
>
>> On Fri, Sep 13, 2019 at 6:17 AM Boris Brezillon
>> wrote:
>>>
>>> The READ/WRITE flags are particularly useful if we want to avoid
>>> serialization of jobs that read from the same BO but n
ned-off-by: Krzysztof Kozlowski
Reviewed-by: Steven Price
>
> ---
>
> Changes since v1:
> 1. Remove second error message from calling panfrost_regulator_init().
> ---
> drivers/gpu/drm/panfrost/panfrost_device.c | 8
> 1 file changed, 4 insertions(+), 4 d
On 24/09/2019 10:55, Koenig, Christian wrote:
> Sorry for the delayed response, have been busy on other stuff last week.
>
> Am 17.09.19 um 14:46 schrieb Steven Price:
>> On 17/09/2019 09:42, Koenig, Christian wrote:
>>> Hi Steven,
>>>
>>> thought about t
On 25/09/2019 15:12, Koenig, Christian wrote:
> Am 25.09.19 um 16:06 schrieb Steven Price:
>> On 24/09/2019 10:55, Koenig, Christian wrote:
>>> Sorry for the delayed response, have been busy on other stuff last week.
>>>
>>> Am 17.09.19 um 14:46 schrieb St
p_job() and simply return a job for processing if
there is one. The caller can then call the free_job() callback outside
the wait_event_interruptible() where sleeping is possible before
re-checking and returning to sleep if necessary.
Signed-off-by: Steven Price
---
drivers/gpu/drm/scheduler/sched_m
On 25/09/2019 16:56, Grodzovsky, Andrey wrote:
> On 9/25/19 11:14 AM, Steven Price wrote:
>
>> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
>> it is called as the condition of wait_event_interruptible() it must not
>> sleep. Unfortunately some
On 25/09/2019 21:09, Grodzovsky, Andrey wrote:
>
> On 9/25/19 12:07 PM, Andrey Grodzovsky wrote:
>> On 9/25/19 12:00 PM, Steven Price wrote:
>>
>>> On 25/09/2019 16:56, Grodzovsky, Andrey wrote:
>>>> On 9/25/19 11:14 AM, Steven Price wrote:
>>>&
On 26/09/2019 08:07, Koenig, Christian wrote:
> Am 25.09.19 um 17:14 schrieb Steven Price:
>> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
>> it is called as the condition of wait_event_interruptible() it must not
>> sleep. Unfortunately some free c
p_job() and simply return a job for processing if
there is one. The caller can then call the free_job() callback outside
the wait_event_interruptible() where sleeping is possible before
re-checking and returning to sleep if necessary.
Signed-off-by: Steven Price
---
Changes from v1:
*
On 26/09/2019 10:54, Steven Price wrote:
> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
> it is called as the condition of wait_event_interruptible() it must not
> sleep. Unfortuantly some free callbacks (notibly for Panfrost) do sleep.
>
> Inste
p_job() and simply return a job for processing if
there is one. The caller can then call the free_job() callback outside
the wait_event_interruptible() where sleeping is possible before
re-checking and returning to sleep if necessary.
Signed-off-by: Steven Price
---
Changes from v2:
* Actually
On 26/09/2019 14:37, Koenig, Christian wrote:
> Am 26.09.19 um 14:31 schrieb Steven Price:
>> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
>> it is called as the condition of wait_event_interruptible() it must not
>> sleep. Unfortuantly some free c
p_job() and simply return a job for processing if
there is one. The caller can then call the free_job() callback outside
the wait_event_interruptible() where sleeping is possible before
re-checking and returning to sleep if necessary.
Signed-off-by: Steven Price
---
Changes from v3:
* drm_sched_main
On 26/09/2019 15:10, Qiang Yu wrote:
> By using shared drm helpers:
> 1. drm_gem_objects_lookup
> 2. drm_gem_(un)lock_reservations
> 3. drm_gem_shmem_helpers
> we can simplify lima driver a lot and benifit from updates to
> these functions.
>
> drm_gem_objects_lookup need a refine in order to be u
On 26/09/2019 16:14, Grodzovsky, Andrey wrote:
>
> On 9/26/19 10:16 AM, Steven Price wrote:
>> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
>> it is called as the condition of wait_event_interruptible() it must not
>> sleep. Unfortuantly some
On 26/09/2019 16:48, Grodzovsky, Andrey wrote:
>
> On 9/26/19 11:23 AM, Steven Price wrote:
>> On 26/09/2019 16:14, Grodzovsky, Andrey wrote:
>>> On 9/26/19 10:16 AM, Steven Price wrote:
>>>> drm_sched_cleanup_jobs() attempts to free finished jobs, however
On 27/09/2019 09:12, Neil Armstrong wrote:
> Hi Christian,
>
> In v5.3, running dEQP triggers the following kernel crash :
>
> [ 20.224982] Unable to handle kernel NULL pointer dereference at virtual
> address 0038
> [...]
> [ 20.291064] Hardware name: Khadas VIM2 (DT)
> [ 20.2
On 27/09/2019 10:55, Steven Price wrote:
[...]
> One obvious issue with the DRM scheduler is that there is a call to
> cancel_delayed_work() in drm_sched_stop() which to me looks like it
> should be cancel_delayed_work_sync() to ensure that the timeout handling
> has completed.
>
&
use user
space handles.
>
> v2:
> 1. add drm_gem_objects_lookup_user
> 2. remove none-zero check as all caller will check before
>calling this function
>
> Cc: Rob Herring
> Cc: Tomeu Vizoso
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Suggested-by: Rob
On 27/09/2019 14:46, Qiang Yu wrote:
> v2:
> use drm_gem_objects_lookup_user instead of
> drm_gem_objects_lookup.
>
> Cc: Eric Anholt
> Signed-off-by: Qiang Yu
Looks familiar :)
Nit: please write a commit message. But otherwise:
Reviewed-by: Steven Price
> ---
&
On 27/09/2019 12:48, Neil Armstrong wrote:
> Hi,
>
> On 27/09/2019 13:27, Neil Armstrong wrote:
>> Hi Steven,
>>
>> Thanks for your prompt reaction !
>>
>> On 27/09/2019 12:48, Steven Price wrote:
>>> On 27/09/2019 10:55, Steven Price wrote:
>>
On 30/09/2019 16:24, Robin Murphy wrote:
> Although going full "dma-coherent" ends badly due to GEM objects still
> being forcibly mapped non-cacheable, we can at least take advantage of
> Juno's ACE-lite integration to skip cache maintenance for pagetables.
>
> CC: Rob Herring
> CC: Tomeu Vizoso
On 20/11/2019 09:57, Andy Shevchenko wrote:
> New GCC warns about inappropriate use of strncpy():
>
> drivers/staging/fbtft/fbtft-core.c: In function ‘fbtft_framebuffer_alloc’:
> drivers/staging/fbtft/fbtft-core.c:665:2: warning: ‘strncpy’ specified bound
> 16 equals destination size [-Wstringop-
On 25/11/2019 14:10, Andrey Grodzovsky wrote:
> When the sched thread is parked we assume ring_mirror_list is
> not accessed from here.
FWIW I don't think this is necessary. kthread_park() will wait until the
thread is parked, at which point the thread is stuck in kthread_parkme()
until unparked.
On 25/11/2019 14:10, Andrey Grodzovsky wrote:
> Problem:
> Due to a race between drm_sched_cleanup_jobs in sched thread and
> drm_sched_job_timedout in timeout work there is a possiblity that
> bad job was already freed while still being accessed from the
> timeout thread.
>
> Fix:
> Instead of ju
On 28/11/2019 20:54, Robin Murphy wrote:
> When we have devfreq, also try to register a basic cooling device in
> case GPU workloads manage to hit thermal throttling thresholds.
>
> Signed-off-by: Robin Murphy
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfr
On 29/11/2019 13:26, Lucas Stach wrote:
> If the job submission fails with a NULL fence returned instead of an
> error pointer we must not try to convert this into an error. The error
> code in this case will be 0, which causes a warning splat from
> dma_fence_set_error().
>
> Also most drivers re
is Brezillon
This seems to be a limitation imposed by the gem_create_object()
callback - e.g. it's assumed that kfree() can be directly called on the
result. Useful to have the documentation though.
Reviewed-by: Steven Price
Steve
> ---
> Changes in v2:
> * Use the proper prefi
On 29/11/2019 13:59, Boris Brezillon wrote:
> If we don't do that, dma_fence_set_error() complains (called from
> drm_sched_main()).
>
> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
> Cc:
> Signed-off-by: Boris Brezillon
This might be worth doing, but actually it's not Panf
; Cc:
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfr
On 29/11/2019 13:59, Boris Brezillon wrote:
> We should release the reference we grabbed when an error occurs.
>
> Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations")
> Cc:
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
e_object().
>
> Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support")
> Cc:
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_gem.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 de
call panfrost_gem_open/close() where
> appropriate.
>
> Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation")
> Cc:
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
Steve
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c
On 29/11/2019 14:31, Boris Brezillon wrote:
> On Fri, 29 Nov 2019 14:19:50 +
> Steven Price wrote:
>
>> On 29/11/2019 13:59, Boris Brezillon wrote:
>>> If we don't do that, dma_fence_set_error() complains (called from
>>> drm_sched_main()).
>>&
On 29/11/2019 14:33, Boris Brezillon wrote:
> On Fri, 29 Nov 2019 14:24:48 +
> Steven Price wrote:
>
>> On 29/11/2019 13:59, Boris Brezillon wrote:
>>> If 2 threads change the MADVISE property of the same BO in parallel we
>>> might end up with an shmem->
On 29/11/2019 13:59, Boris Brezillon wrote:
> We don't want imported/exported BOs to be purges, as those are shared
s/purges/purged/
> with other processes that might still use them. We should also refuse
> to export a BO if it's been marked purgeable or has already been purged.
>
> Fixes: 013b6
On 29/11/2019 13:59, Boris Brezillon wrote:
> With the introduction of per-FD address space, the same BO can be mapped
> in different address space if the BO is globally visible (GEM_FLINK)
> and opened in different context. The current implementation does not
> take case into account, and attaches
this is
something that we want to support "forever" more. But if Mesa has
'always' been assuming this behaviour we might as well match.
Reviewed-by: Steven Price
Steve
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
> drivers/gpu/drm/panfrost/panfrost_g
On 29/11/2019 16:07, Boris Brezillon wrote:
> On Fri, 29 Nov 2019 15:48:15 +
> Steven Price wrote:
>
>> On 29/11/2019 13:59, Boris Brezillon wrote:
>>> Userspace might tag a BO purgeable while it's still referenced by GPU
>>> jobs. We need to make sur
On 02/12/2019 09:44, Daniel Vetter wrote:
> On Mon, Dec 2, 2019 at 10:13 AM Boris Brezillon
> wrote:
>>
>> On Mon, 2 Dec 2019 09:55:32 +0100
>> Daniel Vetter wrote:
>>
>>> On Fri, Nov 29, 2019 at 10:36:29PM +0100, Boris Brezillon wrote:
On Fri, 29 Nov 2019 21:14:59 +0100
Daniel Vetter
"regulator init failed %d\n", err);
> + if (err != -EPROBE_DEFER)
> + dev_err(pfdev->dev, "regulator init failed %d\n", err);
You could actually drop this dev_err() altogether -
panfrost_regulator_init() will always produce it's own
When modifying panfrost_devfreq_target() to support a device without a
regulator defined I missed the check on the error path. Let's add it.
Reported-by: Dan Carpenter
Fixes: e21dd290881b ("drm/panfrost: Enable devfreq to work without regulator")
Signed-off-by: Steven Price
---
/shmem: Add madvise state and purge helpers")
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Rob Herring
Looks good to me:
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/drm_gem_s
On 19/08/2019 17:12, Rob Herring wrote:
> This fixes 2 issues found by lockdep. First, drm_gem_shmem_purge()
> now uses mutex_trylock for the pages_lock to avoid a circular
> dependency.
NIT: This is in the previous patch.
> Second, it drops the call to panfrost_mmu_unmap() which takes several
>
; __arm64_sys_ioctl+0x1c/0x28
> el0_svc_common.constprop.0+0x90/0x168
> el0_svc_handler+0x28/0x78
> el0_svc+0x8/0xc
>
> Fixes: 68337d0b8644 ("drm/panfrost: Restructure the GEM object creation")
> Cc: Tomeu Vizoso
> Cc: David Airlie
> Cc: Daniel Vetter
>
sem){}, at: shrink_slab+0xbc/0x2c0
> #2: f31efa81 (&pfdev->shrinker_lock){+.+.}, at:
> panfrost_gem_shrinker_scan+0x34/0x180 [panfrost]
>
> Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers")
> Cc: Maarten Lankhorst
> Cc: Maxime R
On 23/08/2019 02:52, Rob Herring wrote:
> On Thu, Aug 22, 2019 at 4:32 AM Steven Price wrote:
>>
>> When modifying panfrost_devfreq_target() to support a device without a
>> regulator defined I missed the check on the error path. Let's add it.
>>
>>
On 23/08/2019 02:33, Rob Herring wrote:
> Add Steven Price and Alyssa Rosenzweig as reviewers as they have been the
> primary reviewers already.
>
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Cc: Tomeu Vizoso
> Signed-off-by: Rob Herring
Acked-by: Steven Price
Steve
On 23/08/2019 03:12, Rob Herring wrote:
Doing a pm_runtime_put as soon as a job is submitted is wrong as it should
not happen until the job completes. It works because we are relying on the
autosuspend timeout to keep the h/w enabled.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
pm_runtime_put_sync_suspend()
after the panfrost_device_fini() call.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
Reviewed-by: Steven Price
---
v2: new patch
drivers/gpu/drm/panfrost/panfrost_drv.c | 6 --
1
c: Daniel Vetter
Signed-off-by: Rob Herring
I thought I'd already given my R-b for this one, but just in case:
Reviewed-by: Steven Price
Steve
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 7 +--
include/drm/drm_gem_shmem_helper.h | 2 +-
2 files changed, 6 insertions(+), 3 de
ex_trylock() instead and bail if a BO is locked
already.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
Reviewed-by: Steven Price
---
v2: new patch
drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c | 11 +++
1 fi
awake.
This avoids taking any locks associated with resuming.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
---
v2: new patch
drivers/gpu/drm/panfrost/panfrost_mmu.c | 41 -
1 file changed, 20
associated with resuming.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
Reviewed-by: Steven Price
But one comment below...
---
v2: new patch
drivers/gpu/drm/panfrost/panfrost_mmu.c | 41 -
1 file
teven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
Reviewed-by: Steven Price
Although it might be worth trying to capture the justification about
this in a comment somewhere - there's been a fair bit of discussion
about this...
Steve
-
all the runtime PM calls into the probe() function so they are
> all in one place and are done after all initialization.
>
> Cc: Tomeu Vizoso
> Cc: Steven Price
> Cc: David Airlie
> Cc: Daniel Vetter
> Acked-by: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
Reviewed-b
ot;drm/panfrost: Add initial panfrost driver")
> Cc: Tomeu Vizoso
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Rob Herring
Reviewed-by: Steven Price
Steve
> ---
> v3:
> - Fix race between clearing pfdev-
)
> Suggested-by: Robin Murphy
> Cc: Tomeu Vizoso
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Rob Herring
Reviewed-by: Steven Price
Steve
> ---
> v3:
> - new patch
>
> drivers/gpu/drm/panfrost/
ng any locks associated with resuming which trigger
> lockdep warnings.
>
> Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support")
> Cc: Tomeu Vizoso
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Cc: David Airlie
> Cc: Daniel Vetter
> Signe
On 26/08/2019 23:33, Rob Herring wrote:
> In preparation to call mmu_hw_do_operation with the as_lock already held,
> Add a mmu_hw_do_operation_locked function.
>
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Cc: Tomeu Vizoso
> Cc
les if we are not suspended. As
> the tlb_inv_context() hook is only called when freeing the page tables and
> we do a flush before disabling the AS, lets remove the flush from
> tlb_inv_context and avoid any runtime PM issues.
>
> Fixes: 7282f7645d06 ("drm/panfrost: Implement
lready serialized by drm_sched.
>
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Cc: Tomeu Vizoso
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Rob Herring
Reviewed-b
On 28/08/2019 13:35, Rob Herring wrote:
> On Wed, Aug 28, 2019 at 5:55 AM Steven Price wrote:
>>
>> On 26/08/2019 23:33, Rob Herring wrote:
>>> Currently, page tables are freed without disabling the address space first.
>>> This probably is fine as we'll swit
On 26/08/2019 23:33, Rob Herring wrote:
> It's not entirely clear if this is required, but add a flush of GPU caches
> and TLBs before we change an address space to new page tables.
>
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Cc: To
On 05/09/2019 09:21, Rob Herring wrote:
> +Steven
>
> On Wed, Sep 4, 2019 at 1:30 PM Mark Brown wrote:
>>
>> The panfrost driver requests a supply using regulator_get_optional()
>> but both the name of the supply and the usage pattern suggest that it is
>> being used for the main power for the de
panfrost_gem_object with an
extra reference on it, preventing the BO from being freed until after
the page fault has been handled.
Signed-off-by: Steven Price
---
I've managed to trigger this, generating the following stack trace.
Unable to handle kernel NULL pointer dereference at virtual address 009
On 05/09/2019 13:40, Mark Brown wrote:
> On Thu, Sep 05, 2019 at 10:37:53AM +0100, Steven Price wrote:
>
>> Ah, I didn't realise that regulator_get() will return a dummy regulator
>> if none is provided in the DT. In theory that seems like a nicer
>> solution to my
301 - 400 of 972 matches
Mail list logo
