On 03/09/2021 10:49, Steven Price wrote:
> It turns out that when locking a region, the region must be a naturally
> aligned power of 2. The upshot of this is that if the desired region
> crosses a 'large boundary' the region size must be increased
> significantly to ensure
On 20/09/2021 10:05, Wolfram Sang wrote:
> We should get 'driver_data' from 'struct device' directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
Reviewed-by: Steven Price
I'll push this to dr
eclared. Should it be static?
>
> drivers/gpu/drm/panfrost/panfrost_drv.c:642:12: warning: symbol
> 'mediatek_mt8183_pm_domains' was not declared. Should it be static?
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
Reviewed-by: Steven Price
I'll pus
On 29/09/2021 19:33, Lucas De Marchi wrote:
> Like the IS_ENABLED() counterpart, we can make IS_CONFIG_NONZERO() to
> return the right thing when the config is not defined rather than a
> build error, with the limitation that it can't be used on preprocessor
> context.
>
> The trick here is that m
e fine.
Yeah it looks like you're correct here - I've never looked closely into
exactly how pilot shaders work. It would appear that the DDK checks (in
user space) for the GPU-executable + GPU-writable condition and moans.
So this obviously isn't used by the DDK as it stands.
For the
On 01/10/2021 15:34, Boris Brezillon wrote:
> This lets the driver reduce shareability domain of the MMU mapping,
> which can in turn reduce access time and save power on cache-coherent
> systems.
>
> Signed-off-by: Boris Brezillon
This seems reasonable to me - it matches the kbase
BASE_MEM_COHE
lds by a version field which is mapped to
> a tuple internally
>
> v3:
> * Re-use panfrost_get_job_bos() and panfrost_get_job_in_syncs() in the
> old submit path
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost
dware NULL jobs then this
is clearly better.
A couple of minor points below, but as far as I can tell this is
functionally correct.
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 9 +++--
> drivers/gpu/drm/panfrost/panfrost_job.c | 6 ++
> inclu
On 04/10/2021 13:24, Boris Brezillon wrote:
> On Mon, 4 Oct 2021 12:30:42 +0100
> Steven Price wrote:
[...]
>>
>> It took me a while to convince myself that the reference counting for
>> the PM reference is correct. Before panfrost_job_hw_submit() always
>> returne
On 15/01/2022 16:06, Alexey Sheplyakov wrote:
> On a dual core group GPUs (such as T628) fragment shading can be
> performed over all cores (because a fragment shader job doesn't
> need coherency between threads), however vertex shading requires
> to be run on the same core group as the tiler (whic
M_KMS_CMA_HELPER option")
and with that...
Reviewed-by: Steven Price
Steve
> ---
> drivers/gpu/drm/arm/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
> index 58a242871b28..6e3f1d600541 100644
&
On 01/11/2021 05:20, Bert Schiettecatte wrote:
> Hi John
>
>> Coincidentally, I've been looking at Panfrost on RK3288 this week as
>> well! I'm testing it with a project that has been using the binary blob
>> driver for several years and unfortunately Panfrost seems to use ~15%
>> more CPU.
>> L
ligns the callback with its callers. Fixes the ingenic driver,
> which already returns an error pointer.
>
> Also update the callers to handle the involved types more strictly.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Steven Price
> ---
> There is an alternat
On 30/11/2021 14:25, Zhou Qingyang wrote:
> In komeda_plane_add(), komeda_get_layer_fourcc_list() is assigned to
> formats and used in drm_universal_plane_init().
> drm_universal_plane_init() passes formats to
> __drm_universal_plane_init(). __drm_universal_plane_init() further
> passes formats to
On 01/12/2021 21:15, Liviu Dudau wrote:
> On Wed, Dec 01, 2021 at 03:44:03PM +0000, Steven Price wrote:
>> On 30/11/2021 14:25, Zhou Qingyang wrote:
>>> In komeda_plane_add(), komeda_get_layer_fourcc_list() is assigned to
>>> formats and used
> the common code.
>
> Reported-by: Steven Price
> Signed-off-by: Liviu Dudau
Reviewed-by: Steven Price
Looks correct, although I note there is a path in
__drm_universal_plane_init() which doesn't clean up properly. I'll send
a patch for that too.
Thanks,
Steve
> ---
the function to avoid allocating those resources in the
first place.
Signed-off-by: Steven Price
---
drivers/gpu/drm/drm_plane.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 82afb854141b..fd0bf90fb
on: GPU interrupt
> + - description: Event interrupt
>
>interrupt-names:
> +minItems: 3
> items:
>- const: job
>- const: mmu
>- const: gpu
> + - const: event
FWIW: I think it's fair to add the "event" int
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
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 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 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 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
+ Boris
On 16/12/2021 12:08, Dan Carpenter wrote:
> Hi DRM Devs,
>
> In commit 7661809d493b ("mm: don't allow oversized kvmalloc() calls")
> from July, Linus added a WARN_ONCE() for "crazy" allocations over 2GB.
> I have a static checker warning for this and most of the warnings are
> from DRM io
On 16/12/2021 14:15, Boris Brezillon wrote:
> Hi Steve,
>
> On Thu, 16 Dec 2021 14:02:25 +
> Steven Price wrote:
>
>> + Boris
>>
>> On 16/12/2021 12:08, Dan Carpenter wrote:
>>> Hi DRM Devs,
>>>
>>> In commit 7661809d493b ("
impler.
Reported-by: Dan Carpenter
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 44 -
1 file changed, 14 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 96bb5a
On 16/12/2021 17:12, Rob Herring wrote:
> On Thu, Dec 16, 2021 at 10:16 AM Steven Price wrote:
>>
>> panfrost_copy_in_sync() takes the number of fences from user space
>> (in_sync_count) and used to kvmalloc() an array to hold that number of
>> fences before processing
On 16/12/2021 17:49, Alyssa Rosenzweig wrote:
>> This provides an easy method for user
>> space to trigger the OOM killer (by temporarily allocating large amounts
>> of kernel memory)
>
> panfrost user space has a lot of easy ways to trigger to the OOM killer
> unfortunately if this is someth
On 17/12/2021 09:10, Dan Carpenter wrote:
> On Fri, Dec 17, 2021 at 08:55:50AM +0000, Steven Price wrote:
>> However this one is harder to fix without setting an arbitrary cap on
>> the number of BOs during a sumbit. I'm not sure how other drivers handle
>> this - the
On 17/12/2021 09:28, Dan Carpenter wrote:
> On Fri, Dec 17, 2021 at 09:16:19AM +0000, Steven Price wrote:
>> On 17/12/2021 09:10, Dan Carpenter wrote:
>>> On Fri, Dec 17, 2021 at 08:55:50AM +, Steven Price wrote:
>>>> However this one is harder to fix witho
On 24/12/2021 08:56, Alexey Sheplyakov wrote:
> Hi,
>
> On 23.12.2021 18:11, Alyssa Rosenzweig wrote:
>>> The kernel driver itself can't guess which jobs need a such a strict
>>> affinity, so setting proper requirements is the responsibility of
>>> the userspace (Mesa). However the userspace is no
On 09/01/2022 16:37, Alyssa Rosenzweig wrote:
> Update a comment stating create_bo took no flags, since it now takes a
> bit mask of optional flags NOEXEC and HEAP.
>
> Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
I'll push this to drm-misc-next
been chosen as it gave the best
overall performance (although for individual test content this can
vary). AFAICT the performance impact isn't massive either.
> Applies on top of my feature clean up series which should go in first.
> (That's pure cleaunp, this is a behaviour change RF
: Set DMA masks earlier")
That commit just moved the code around, the actual missing error
handling dates from the very beginning (f3ba91228e8e ("drm/panfrost: Add
initial panfrost driver")). But I can fix that up when merging.
> Signed-off-by: Jiasheng Jiang
Reviewed-by: Steven
to the kernel, leaving only those which do affect the
> register-level operation of the chip.
>
> Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
(although it's a good thing kbase never did this cleanup - it's a useful
source of public information ;) )
Steve
&g
On 09/01/2022 17:09, Alyssa Rosenzweig wrote:
> Now that we only list features of interest to kernel space, lots of GPUs
> have the same feature bits. To cut down on the repetition in the file,
> merge feature lists that are identical between similar GPUs.
>
> Note that this leaves some unmerged i
On 10/01/2022 17:42, Alyssa Rosenzweig wrote:
>> Whether it's worth the effort depends on whether anyone really cares
>> about getting the full performance out of this particular GPU.
>>
>> At this stage I think the main UABI change would be to add the opposite
>> flag to kbase, (e.g. "PANFROST_JD_
On 12/01/2022 19:20, Alyssa Rosenzweig wrote:
>>> Now that we only list features of interest to kernel space, lots of GPUs
>>> have the same feature bits. To cut down on the repetition in the file,
>>> merge feature lists that are identical between similar GPUs.
>>>
>>> Note that this leaves some u
On 13/01/2022 10:01, Alexey Sheplyakov wrote:
> Hi, Steven!
>
> Thanks for such a detailed explanation of T628 peculiarities.
>
> On Wed, Jan 12, 2022 at 05:03:15PM +0000, Steven Price wrote:
>> On 10/01/2022 17:42, Alyssa Rosenzweig wrote:
>>>> Whether it'
NULL if userspace doesn't send a sync object
> ID for the out fence.
>
> Signed-off-by: Tomeu Vizoso
> Reported-by: Dan Carpenter
> Link: https://lists.freedesktop.org/archives/dri-devel/2019-May/217014.html
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panf
code.
CC: Alyssa Rosenzweig
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 94b0819ad50b
On 13/05/2019 15:47, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-05-13 15:39:21)
>> On Mon, May 13, 2019 at 03:32:44PM +0100, Steven Price wrote:
>>> panfrost_ioctl_mmap_bo() contains a reimplementation of
>>> drm_gem_dump_map_offset() but with a bug - it allows m
On 12/05/2019 14:38, Boris Brezillon wrote:
> On Sat, 11 May 2019 15:32:20 -0700
> Alyssa Rosenzweig wrote:
>
>> Hi all,
>>
>> As Steven Price explained, the "GPU top" kbase approach is often more
>> useful and accurate than per-draw timing.
>>
On 13/05/2019 09:17, Boris Brezillon wrote:
> panfrost_{job,mmu,gpu,reset}_fini() were missing.
>
> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/pan
On 13/05/2019 14:39, Boris Brezillon wrote:
> On Mon, 13 May 2019 13:48:08 +0100
> Steven Price wrote:
>
>> On 12/05/2019 14:38, Boris Brezillon wrote:
>>> On Sat, 11 May 2019 15:32:20 -0700
>>> Alyssa Rosenzweig wrote:
>>>
>>>> Hi
On 16/05/2019 12:19, Robin Murphy wrote:
[...]
> I was expecting to see a similar behaviour to my T620 (which I now
> assume was down to 64-bit job descriptors sort-of-but-not-quite working)
> but this does look a bit more fundamental - the fact that it's a level 1
> fault with VA == head == tail s
offset to drop _dumb
* Add a shmem helper
Steven Price (3):
drm/gem: Rename drm_gem_dumb_map_offset() to drm_gem_map_offset()
drm: shmem: Add drm_gem_shmem_map_offset() wrapper
drm/panfrost: Use drm_gem_shmem_map_offset()
drivers/gpu/drm/drm_dumb_buffers.c | 4 ++--
drive
drm_gem_dumb_map_offset() is a useful helper for non-dumb clients, so
rename it to remove the _dumb.
Signed-off-by: Steven Price
---
drivers/gpu/drm/drm_dumb_buffers.c | 4 ++--
drivers/gpu/drm/drm_gem.c | 6 +++---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 +--
include/drm
Provide a wrapper for drm_gem_map_offset() for clients of shmem. This
wrapper provides the correct semantics for the drm_gem_shmem_mmap()
callback.
Signed-off-by: Steven Price
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 20
include/drm/drm_gem_shmem_helper.h | 2 ++
2
On 14/05/2019 14:31, Rob Herring wrote:
> On Tue, May 14, 2019 at 5:48 AM Boris Brezillon
> wrote:
>>
>> Add a way to dump perf counters through debugfs. The implementation is
>> kept simple and has a number of limitations:
>>
>> * it's not designed for multi-user usage as the counter values are
>
.
CC: Alyssa Rosenzweig
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 94b0819ad50b..a261b59208d0
On 16/05/2019 21:26, Daniel Vetter wrote:
> On Thu, May 16, 2019 at 03:14:46PM +0100, Steven Price wrote:
>> Provide a wrapper for drm_gem_map_offset() for clients of shmem. This
>> wrapper provides the correct semantics for the drm_gem_shmem_mmap()
>> callback.
>>
>
drm_gem_dumb_map_offset() is a useful helper for non-dumb clients, so
rename it to remove the _dumb.
Signed-off-by: Steven Price
Acked-by: Alyssa Rosenzweig
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_dumb_buffers.c | 4 ++--
drivers/gpu/drm/drm_gem.c | 6
On 21/05/2019 19:23, Chris Wilson wrote:
> Quoting Rob Herring (2019-05-21 16:24:27)
>> On Mon, May 20, 2019 at 4:23 AM Steven Price wrote:
>>>
>>
>> You forgot to update the subject. I can fixup when applying, but I'd
>> like an ack from Chris on patch 1
anges since v1:
* Rename drm_gem_dumb_map_offset to drop _dumb
* Add a shmem helper
Steven Price (2):
drm/gem: Rename drm_gem_dumb_map_offset() to drm_gem_map_offset()
drm/panfrost: Use drm_gem_shmem_map_offset()
drivers/gpu/drm/drm_dumb_buffers.c | 4 ++--
drivers/gpu/drm/drm_gem.c |
.
CC: Alyssa Rosenzweig
Signed-off-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
On 05/04/2019 10:51, Robin Murphy wrote:
> Hi Steve,
>
> On 05/04/2019 10:42, Steven Price wrote:
>> First let me say congratulations to everyone working on Panfrost - it's
>> an impressive achievement!
>>
>> Full disclosure: I used to work on the Mali
rformance, but I haven't benchmarked
the difference between this and JS_CONFIG_START_MMU.
-----8<--
From e3f75c7f04e43238dfc579029b8c11fb6b4a0c18 Mon Sep 17 00:00:00 2001
From: Steven Price
Date: Thu, 4 Apr 2019 15:53:17 +0100
Subject: [PATCH] iommu: io-pgtable: IO_PGTABLE_QUIRK_TLB
On 05/04/2019 17:16, Alyssa Rosenzweig wrote:
>> I'm also somewhat surprised that you don't need loads of other
>> properties from the GPU - in particular knowing the number of shader
>> cores is useful for allocating the right amount of memory for TLS (and
>> can't be obtained purely from the GPU_
On 04/04/2019 16:20, Boris Brezillon wrote:
> Hello,
>
> This patch adds new ioctls to expose GPU counters to userspace.
> These will be used by the mesa driver (should be posted soon).
>
> A few words about the implementation: I followed the VC4/Etnaviv model
> where perf counters are retrieved
On 05/04/2019 11:36, Steven Price wrote:
> On 05/04/2019 10:51, Robin Murphy wrote:
>> Hi Steve,
>>
>> On 05/04/2019 10:42, Steven Price wrote:
>>> First let me say congratulations to everyone working on Panfrost - it's
>>> an impressive achievement!
&g
On 09/04/2019 17:15, Rob Herring wrote:
> On Tue, Apr 9, 2019 at 10:56 AM Tomeu Vizoso
> wrote:
>>
>> On Mon, 8 Apr 2019 at 23:04, Rob Herring wrote:
>>>
>>> On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
>>>>
>>>> On 01/04/2019
On 08/04/2019 22:04, Rob Herring wrote:
> On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
>>
>> On 01/04/2019 08:47, Rob Herring wrote:
>>> This adds the initial driver for panfrost which supports Arm Mali
>>> Midgard and Bifrost family of GPUs. Currently, o
David Airlie
> Cc: Daniel Vetter
> Cc: Lyude Paul
> Reviewed-by: Alyssa Rosenzweig
> Reviewed-by: Eric Anholt
> Signed-off-by: Marty E. Plummer
> Signed-off-by: Tomeu Vizoso
> Signed-off-by: Neil Armstrong
> Signed-off-by: Rob Herring
> ---
This looks like
s 1GB allocations on current h/w.
>
> Cc: Tomeu Vizoso
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Rob Herring
LGTM, and I see a nice speed up too!
Reviewed-by: Steven Price
___
dri-devel mailing list
dri-devel@lists.fre
On 15/04/2019 10:18, Daniel Vetter wrote:
> On Fri, Apr 05, 2019 at 05:42:33PM +0100, Steven Price wrote:
>> On 05/04/2019 17:16, Alyssa Rosenzweig wrote:
>>> acronym once ever and have it as a "??"), I'm not sure how to respond to
>>> that... We don
Signed-off-by: YueHaibing
Reviewed-by: Steven Price
Although while we're fixing sparse warnings, there's a few more in Panfrost:
-8<---
From 8aaf778262744cfbebb9b7f274ead9ba600526b0 Mon Sep 17 00:00:00 2001
From: Steven Price
Date: Wed, 17 Apr 2019 15:47:49 +0100
Subject:
p; MMU [=y]
Reported-by: kbuild test robot
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/Kconfig b/drivers/gpu/drm/panfrost/Kconfig
index 7f5e572daa2d..591611dc4e34 100644
--- a/drive
oes have a
"sparse" mechanism which might require something similar (but unlikely
to require faulting in).
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Cc: Tomeu Vizoso
> Signed-off-by: Rob Herring
> ---
>
> drivers/gpu/drm/panfrost/TODO
Sorry for the slow response, I've been on holiday for a few weeks.
On 20/06/2019 06:50, Tomeu Vizoso wrote:
> On Mon, 17 Jun 2019 at 16:56, Rob Herring wrote:
>>
>> On Sun, Jun 16, 2019 at 11:15 PM Tomeu Vizoso
>> wrote:
>>>
>>> On Fri, 14 Jun 2019 at 23:22, Rob Herring wrote:
On Wed,
On 10/06/2019 14:20, Rob Herring wrote:
[...]
> I wouldn't have expected AS_TRANSCFG_ADRMODE_LEGACY to work and if it
> did it was by chance. So I don't think it is something we want to
> support.
Actually legacy mode is supported on (most?) Bifrost GPUs. But best to
follow the lead of kbase here
dumb clients.
v2: https://lore.kernel.org/lkml/20190516141447.46839-1-steven.pr...@arm.com/
Changes since v2:
* Drop the shmem helper
v1: https://lore.kernel.org/lkml/20190513143244.16478-1-steven.pr...@arm.com/
Changes since v1:
* Rename drm_gem_dumb_map_offset to drop _dumb
* Add a shme
.
Signed-off-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index e34e86a7378a
drm_gem_dumb_map_offset() is a useful helper for non-dumb clients, so
rename it to remove the _dumb and add a comment that it can be used by
shmem clients.
Signed-off-by: Steven Price
---
drivers/gpu/drm/drm_dumb_buffers.c | 4 ++--
drivers/gpu/drm/drm_gem.c | 9
On 27/06/2019 17:38, Rob Herring wrote:
> On Thu, Jun 27, 2019 at 4:57 AM Steven Price wrote:
>>
>> Sorry for the slow response, I've been on holiday for a few weeks.
>
> Welcome back.
Thanks!
>>
>> On 20/06/2019 06:50, Tomeu Vizoso wrote:
>>> O
On 03/07/2019 16:59, Rob Herring wrote:
> On Wed, Jul 3, 2019 at 8:13 AM Steven Price wrote:
>>
>> On 03/07/2019 14:56, Boris Brezillon wrote:
>>> On Wed, 3 Jul 2019 07:45:32 -0600
>>> Rob Herring wrote:
>>>
>>>> On Wed, Jul 3, 2019 at 7:3
On 03/07/2019 14:56, Boris Brezillon wrote:
> On Wed, 3 Jul 2019 07:45:32 -0600
> Rob Herring wrote:
>
>> On Wed, Jul 3, 2019 at 7:34 AM Boris Brezillon
>> wrote:
>>>
>>> Exported BOs might be imported back, then mmap()-ed to be written
>>> too. Most drivers handle that by mmap()-ing the GEM han
On 03/07/2019 15:33, Boris Brezillon wrote:
> On Wed, 3 Jul 2019 15:13:25 +0100
> Steven Price wrote:
>
>> On 03/07/2019 14:56, Boris Brezillon wrote:
>>> On Wed, 3 Jul 2019 07:45:32 -0600
>>> Rob Herring wrote:
>>>
>>>> On W
() forwarding mechanism and update drivers to avoid using it.
However the user ABI must be maintained, so this existing mmap()
forwarding cannot be removed.
Signed-off-by: Steven Price
---
drivers/dma-buf/dma-buf.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff
On 03/07/2019 17:18, Daniel Vetter wrote:
> On Wed, Jul 3, 2019 at 6:11 PM Steven Price wrote:
[...]
>> In theory the exporter should do whatever is required to ensure that the
>> CPU is synchronised when a user space mapping exists. There are some
>> issues here though:
On 01/04/2019 09:09, Neil Armstrong wrote:
> Add the bindings for the Bifrost family of ARM Mali GPUs.
>
> The Bifrost GPU architecture is similar to the Midgard family,
> but with a different Shader Core & Execution Engine structures.
>
> Bindings are based on the Midgard family bindings, but th
t a time in order to utilize huge pages (if
> enabled). Currently, once we've mapped pages in, they are only unmapped
> if the BO is freed. Once we add shrinker support, we can unmap pages
> with the shrinker.
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murp
the base shmem object.
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
Hi Rob,
I couldn't work out what base this series should be applied to, but I've
tried manuall
as there is plenty of GPU VA space.
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 20 +++-
> drivers/gpu/drm/pa
On 17/07/2019 19:33, Rob Herring wrote:
> In preparation to create partial GPU mappings of BOs on page faults,
> split out the SG list handling of panfrost_mmu_map().
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzwe
On 19/07/2019 15:27, Rob Herring wrote:
> On Thu, Jul 18, 2019 at 9:03 AM Steven Price wrote:
>>
>> On 17/07/2019 19:33, Rob Herring wrote:
>>> The midgard/bifrost GPUs need to allocate GPU heap memory which is
>>> allocated on GPU page faults and not pinned in me
On 18/07/2019 18:03, Rob Herring wrote:
> On Thu, Jul 18, 2019 at 9:03 AM Steven Price wrote:
>>
>> On 17/07/2019 19:33, Rob Herring wrote:
>>> Executable buffers have an alignment restriction that they can't cross
>>> 16MB boundary as the GPU program c
On 19/07/2019 23:07, Rob Herring wrote:
> On Fri, Jul 19, 2019 at 4:39 AM Steven Price wrote:
>>
>> On 18/07/2019 18:03, Rob Herring wrote:
>>> On Thu, Jul 18, 2019 at 9:03 AM Steven Price wrote:
>>>>
>>>> On 17/07/2019 19:33, Rob Herring w
On 19/07/2019 23:22, Rob Herring wrote:
> On Thu, Jul 18, 2019 at 9:03 AM Steven Price wrote:
>>
>> On 17/07/2019 19:33, Rob Herring wrote:
>>> Setting the GPU VA when creating the GEM object doesn't allow for any
>>> conditional adjustments. In preparatio
On 22/07/2019 15:38, Simon Ser wrote:
> From: Simon Ser
>
> The VSDB parsing code contains a few len >= N checks, accessing db[N] on
> success. However if len == N, db[N] is out-of-bounds.
I'm not familiar with VSDB parsing, but there's a comment before the
function:
> * @len: length of the CE
On 22/07/2019 10:50, Robin Murphy wrote:
> On 19/07/2019 23:07, Rob Herring wrote:
>> On Fri, Jul 19, 2019 at 4:39 AM Steven Price
>> wrote:
>>>
>>> On 18/07/2019 18:03, Rob Herring wrote:
>>>> On Thu, Jul 18, 2019 at 9:03 AM Steven Price
>>>
On 22/07/2019 13:09, Robin Murphy wrote:
> On 22/07/2019 11:07, Steven Price wrote:
>> On 22/07/2019 10:50, Robin Murphy wrote:
>>> On 19/07/2019 23:07, Rob Herring wrote:
>>>> On Fri, Jul 19, 2019 at 4:39 AM Steven Price
>>>> wrote:
>>>>>
On 22/07/2019 17:18, Rob Herring wrote:
> On Mon, Jul 22, 2019 at 7:25 AM Robin Murphy wrote:
>>
>> On 22/07/2019 13:19, Steven Price wrote:
>> [...]
>>> Indeed, that case was just occurring to me too! How about:
>>>
>>> u64 next_seg = A
: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
drivers/gpu/drm/panfrost/panfrost_drv.c| 38 +++--
drivers/gpu/drm/panfrost/panfrost_gpu.c| 2 ++
include/uapi/drm/panfrost_drm.h| 39 ++
4 files changed, 77 insertions
ect, so just put pages if the pages array is populated.
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Eric Anholt
> Signed-off-by: Rob Herring
LGTM: Reviewed-by: Steven Price
> ---
> v2:
> - new
On 25/07/2019 17:13, Alyssa Rosenzweig wrote:
>> Either we should prevent mapping of HEAP objects
>
> I'm good with that. AFAIK, HEAP objects shouldn't be (CPU) mmapped
> anyway in normal use; if you need them mapped (for debugging etc), it's
> no big deal to just.. not set the HEAP flag in debug
On 25/07/2019 22:28, Rob Herring wrote:
On Thu, Jul 25, 2019 at 9:35 AM Steven Price wrote:
On 25/07/2019 15:59, Steven Price wrote:
[...]
It would appear that in the following call sgt==NULL:
ret = sg_alloc_table_from_pages(sgt, pages + page_offset
the base shmem object.
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 21 +++-
_PAGES, 0, SZ_2M, GFP_KERNEL);
Which means we've ended up with a BO with bo->sgt==NULL, bo->pages set
and bo->is_heap=true. My understanding is this should be impossible.
I haven't yet figured out how this happens - it seems to be just before
termination, so it might be a race wit
to the size of the BO. This shouldn't
> matter as there is plenty of GPU VA space.
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Acked-by: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
Reviewed-by: Steven Price
> ---
&
101 - 200 of 972 matches
Mail list logo
