On Tue, May 21, 2024 at 2:12 PM Daniel Vetter wrote:
>
> On Sat, May 18, 2024 at 10:46:01AM +0200, Tomeu Vizoso wrote:
> > Hi,
> >
> > I would like to use the chance at the next Plumbers to discuss the
> > present challenges related to ML accelerators in mainline.
&g
On Fri, May 10, 2024 at 10:34 AM Lucas Stach wrote:
>
> Hi Tomeu,
>
> Am Mittwoch, dem 24.04.2024 um 08:37 +0200 schrieb Tomeu Vizoso:
> > If we expose a render node for NPUs without rendering capabilities, the
> > userspace stack will offer it to compositors and applic
Hi Lucas,
On Fri, May 10, 2024 at 10:34 AM Lucas Stach wrote:
>
> Hi Tomeu,
>
> Am Mittwoch, dem 24.04.2024 um 08:37 +0200 schrieb Tomeu Vizoso:
> > If we expose a render node for NPUs without rendering capabilities, the
> > userspace stack will offer it to comp
Hi,
I would like to use the chance at the next Plumbers to discuss the
present challenges related to ML accelerators in mainline.
I'm myself more oriented towards edge-oriented deployments, and don't
know enough about how these accelerators are being used in the cloud
(and maybe desktop?) to
Oded, Dave,
Do you have an opinion on this?
Thanks,
Tomeu
On Fri, Apr 26, 2024 at 8:10 AM Tomeu Vizoso wrote:
>
> On Thu, Apr 25, 2024 at 8:59 PM Jeffrey Hugo wrote:
> >
> > On 4/24/2024 12:37 AM, Tomeu Vizoso wrote:
> > > If we expose a render node for NPUs wit
On Thu, Apr 25, 2024 at 8:59 PM Jeffrey Hugo wrote:
>
> On 4/24/2024 12:37 AM, Tomeu Vizoso wrote:
> > If we expose a render node for NPUs without rendering capabilities, the
> > userspace stack will offer it to compositors and applications for
> > rendering, wh
from a render node. What needs to be
> done
> on the userspace side?
Doesn't seem that bad, here is a proof of concept:
https://gitlab.freedesktop.org/tomeu/mesa/-/tree/teflon-accel
Thanks for taking a look.
Tomeu
> > Signed-off-by: Tomeu Vizoso
> > Cc: Oded Gabbay
>
> Review
with an accel node.
Signed-off-by: Tomeu Vizoso
Cc: Oded Gabbay
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 46 ++-
1 file changed, 38 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index
Agreed, thanks for doing this, Christian.
Reviewed-by: Tomeu Vizoso
Cheers,
Tomeu
On Sat, Apr 20, 2024 at 3:41 PM Christian Gmeiner
wrote:
>
> From: Christian Gmeiner
>
> This reverts commit 1dccdba084897443d116508a8ed71e0ac8a031a4.
>
> In userspace a different approach
too.
>
> Fixes: 4078a1186dd3 ("drm/etnaviv: update hwdb selection logic")
> Cc: sta...@vger.kernel.org
Oops.
Reviewed-by: Tomeu Vizoso
Cheers,
Tomeu
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
> drivers/gpu/drm/etn
These ones will be needed to make use fo the NN and TP units in the NPUs
based on Vivante IP.
Signed-off-by: Tomeu Vizoso
Acked-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 20
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 12
drivers/gpu/drm
These ones will be needed to make use fo the NN and TP units in the NPUs
based on Vivante IP.
Also fix the number of NN cores in the VIPNano-qi.
Signed-off-by: Tomeu Vizoso
---
v2: Update a few chipspecs that I had missed before. (Christian)
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 20
These ones will be needed to make use fo the NN and TP units in the NPUs
based on Vivante IP.
Also fix the number of NN cores in the VIPNano-qi.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 20
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 12
intf(m, "\t pixel_pipes: %d\n",
gpu->identity.pixel_pipes);
seq_printf(m, "\t vertex_output_buffer_size: %d\n",
Hi Lucas,
That looks good to me.
Reviewed-by: Tomeu Vizoso
Cheers,
Tomeu
On 2/1/23 14:26, Lucas Stach wrote:
Hi Tomeu,
Am Donnerstag, dem 01.12.2022 um 11:30 +0100 schrieb Tomeu Vizoso:
This is a compute-only module marketed towards AI and vision
acceleration. This particular version can be found on the Amlogic A311D
SoC.
The feature bits are taken from the Khadas
This is a compute-only module marketed towards AI and vision
acceleration. This particular version can be found on the Amlogic A311D
SoC.
The feature bits are taken from the Khadas downstream kernel driver
6.4.4.3.310723AAA.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/etnaviv
Userspace is still not making full use of the hardware, so we don't know
yet if changes to the UAPI won't be needed. Warn about it.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
We will use these for differentiating between GPUs and NPUs, as the
downstream driver does.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 3 +++
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 4
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv
)
Regards,
Tomeu
Tomeu Vizoso (8):
dt-bindings: reset: meson-g12a: Add missing NNA reset
dt-bindings: power: Add G12A NNA power domain
soc: amlogic: meson-pwrc: Add NNA power domain for A311D
arm64: dts: Add DT node for the VIPNano-QI on the A311D
drm/etnaviv: Add nn_core_count to chip feature
This is a compute-only module marketed towards AI and vision
acceleration. This particular version can be found on the Amlogic A311D
SoC.
The feature bits are taken from the Khadas downstream kernel driver
6.4.4.3.310723AAA.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/etnaviv
Userspace is still not making full use of the hardware, so we don't know
yet if changes to the UAPI won't be needed. Warn about it.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
We will use these for differentiating between GPUs and NPUs, as the
downstream driver does.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 3 +++
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 4
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv
://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18986
v2: Move reference to RESET_NNA to npu node (Neil)
v3: Fix indentation mistake (Neil)
v4: Add warning when etnaviv probes on a NPU (Lucas)
v5: Reorder HWDB commit to be the last (Lucas)
Regards,
Tomeu
Tomeu Vizoso (7):
dt-bindings: reset: meson-g12a: Add
We will use these for differentiating between GPUs and NPUs, as the
downstream driver does.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 3 +++
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 5 +
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv
Userspace is still not making full use of the hardware, so we don't know
yet if changes to the UAPI won't be needed. Warn about it.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
This is a compute-only module marketed towards AI and vision
acceleration. This particular version can be found on the Amlogic A311D
SoC.
The feature bits are taken from the Khadas downstream kernel driver
6.4.4.3.310723AAA.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/etnaviv
://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18986
v2: Move reference to RESET_NNA to npu node (Neil)
v3: Fix indentation mistake (Neil)
v4: Add warning when etnaviv probes on a NPU
Regards,
Tomeu
Tomeu Vizoso (7):
dt-bindings: reset: meson-g12a: Add missing NNA reset
dt-bindings: power: Add G12A NNA power
This is a compute-only module marketed towards AI and vision
acceleration. This particular version can be found on the Amlogic A311D
SoC.
The feature bits are taken from the Khadas downstream kernel driver
6.4.4.3.310723AAA.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/etnaviv
://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18986
v2: Move reference to RESET_NNA to npu node (Neil)
v3: Fix indentation mistake (Neil)
Regards,
Tomeu
Tomeu Vizoso (5):
dt-bindings: reset: meson-g12a: Add missing NNA reset
dt-bindings: power: Add G12A NNA power domain
soc: amlogic: meson-pwrc: Add NNA
This is a compute-only module marketed towards AI and vision
acceleration. This particular version can be found on the Amlogic A311D
SoC.
The feature bits are taken from the Khadas downstream kernel driver
6.4.4.3.310723AAA.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/etnaviv
://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18986
Regards,
Tomeu
Tomeu Vizoso (5):
dt-bindings: reset: meson-g12a: Add missing NNA reset
dt-bindings: power: Add NNA power domain
soc: amlogic: meson-pwrc: Add NNA power domain for A311D
arm64: dts: Add DT node for the VIPNano-QI on the A311D
drm
This is a compute-only module marketed towards AI and vision
acceleration. This particular version can be found on the Amlogic A311D
SoC.
The feature bits are taken from the Khadas downstream kernel driver
6.4.4.3.310723AAA.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/etnaviv
Hi,
This series adds support for the Verisilicon VIPNano-QI NPU in the A311D
as in the VIM3 board.
The IP is very closeley based on previous Vivante GPUs, so the etnaviv
driver works basically unchanged.
Regards,
Tomeu
Tomeu Vizoso (6):
dt-bindings: reset: meson-g12a: Add missing NNA reset
on top of latest drm-next
- Lower priority of LAVA jobs to not impact Mesa CI as much
- Update docs
v7:
- Rebase on top of latest drm-next
Signed-off-by: Tomeu Vizoso
Reviewed-by: Neil Armstrong
Reviewed-by: Rob Clark
---
Documentation/gpu/automated_testing.rst | 86
on top of latest drm-next
- Lower priority of LAVA jobs to not impact Mesa CI as much
- Update docs
Signed-off-by: Tomeu Vizoso
Reviewed-by: Neil Armstrong
Reviewed-by: Rob Clark
---
Documentation/gpu/automated_testing.rst | 86 +++
drivers/gpu/drm/ci/amdgpu-stoney
in the GitLab UI
Signed-off-by: Tomeu Vizoso
Reviewed-by: Neil Armstrong
---
Documentation/gpu/automated_testing.rst | 84 ++
drivers/gpu/drm/ci/amdgpu-stoney-fails.txt | 13 +++
drivers/gpu/drm/ci/amdgpu-stoney-flakes.txt | 20 +
drivers/gpu/drm/ci/amdgpu-stoney
-by: Tomeu Vizoso
Reviewed-by: Neil Armstrong
---
Documentation/gpu/automated_testing.rst | 84 ++
drivers/gpu/drm/ci/amdgpu-stoney-fails.txt| 13 +++
drivers/gpu/drm/ci/amdgpu-stoney-flakes.txt | 20 +
drivers/gpu/drm/ci/amdgpu-stoney-skips.txt| 2 +
drivers/gpu
Thanks, this fixes the DRM driver on 5.19-rc2 on the rk3288-veyron-jaq.
Tested-by: Tomeu Vizoso
Cheers,
Tomeu
On Wed, Jun 15, 2022 at 5:52 PM Steven Price wrote:
> Since commit 1ea2a07a532b ("iommu: Add DMA ownership management
> interfaces") the Rockchip display drive
On 5/17/22 11:18 AM, Neil Armstrong wrote:
On 17/05/2022 10:16, Tomeu Vizoso wrote:
And use it to store expectations about what the DRM drivers are
supposed to pass in the IGT test suite.
Also include a configuration file that points to the out-of-tree CI
scripts.
By storing the test
from expected results file, to reduce the
size of in-tree files
- Add docs about how to deal with outages in automated testing labs
- Specify the exact SHA of the CI scripts to be used
Signed-off-by: Tomeu Vizoso
---
Documentation/gpu/automated_testing.rst | 84 +++
drivers/gpu
On 5/11/22 7:46 PM, Rob Clark wrote:
On Wed, May 11, 2022 at 10:12 AM Daniel Vetter wrote:
On Tue, 10 May 2022 at 22:26, Rob Clark wrote:
On Tue, May 10, 2022 at 12:39 PM Jessica Zhang
wrote:
On 5/10/2022 7:13 AM, Tomeu Vizoso wrote:
And use it to store expectations about what
On 5/11/22 3:20 PM, Rob Clark wrote:
On Tue, May 10, 2022 at 11:15 PM Tomeu Vizoso
wrote:
And use it to store expectations about what the drm/msm driver is
supposed to pass in the IGT test suite.
Also include a configuration file that points to the out-of-tree CI
scripts.
By storing
tests that are going to skip on all boards
v3:
- Remove tracking of dmesg output during test execution
Signed-off-by: Tomeu Vizoso
---
Documentation/gpu/msm_automated_testing.rst | 70 +
drivers/gpu/drm/msm/ci/gitlab-ci.yml | 11 ++
drivers/gpu/drm/msm/ci/msm.testlist
On 5/10/22 9:39 PM, Jessica Zhang wrote:
On 5/10/2022 7:13 AM, Tomeu Vizoso wrote:
+igt@kms_atomic_interruptible@legacy-setmode@pipe-a-edp-1
+igt@kms_atomic_interruptible@atomic-setmode@pipe-a-edp-1
+igt@kms_atomic_interruptible@legacy-dpms@pipe-a-edp-1
+igt@kms_atomic_interruptible@legacy
tests that are going to skip on all boards
Signed-off-by: Tomeu Vizoso
---
Documentation/gpu/msm_automated_testing.rst | 70 +
drivers/gpu/drm/msm/ci/gitlab-ci.yml | 11 ++
drivers/gpu/drm/msm/ci/msm.testlist | 148 ++
.../gpu/drm/msm/ci
know when a code change
breaks those expectations.
This will allow all contributors to drm/msm to reuse the infrastructure
already in gitlab.freedesktop.org to test the driver on several
generations of the hardware.
Signed-off-by: Tomeu Vizoso
---
Documentation/gpu/msm_automated_testing.rst
On 12/16/21 6:49 PM, 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 something we want
Hi Alyssa,
Will this be enough to implement GL_TIMESTAMP and GL_TIME_ELAPSED queries?
Guess the DDK implements these as WRITE_VALUE jobs, and there's also a
soft job BASE_JD_REQ_SOFT_DUMP_CPU_GPU_TIME that I guess is used for
glGet*(GL_TIMESTAMP). Other DRM drivers use an ioctl for that
On 1/13/21 7:06 AM, Nicolas Boichat wrote:
Hi!
Follow-up on the v5 [1], things have gotten significantly
better in the last 9 months, thanks to the efforts on Bifrost
support by the Collabora team (and probably others I'm not
aware of).
I've been testing this series on a MT8183/kukui device,
On 1/7/21 9:49 AM, Nicolas Boichat wrote:
On Thu, Jan 7, 2021 at 4:31 PM Tomeu Vizoso wrote:
On 1/7/21 9:26 AM, Nicolas Boichat wrote:
GPUs with more than a single regulator (e.g. G72 on MT8183) will
require platform-specific handling, disable devfreq for now.
Signed-off-by: Nicolas Boichat
On 1/7/21 9:26 AM, Nicolas Boichat wrote:
GPUs with more than a single regulator (e.g. G72 on MT8183) will
require platform-specific handling, disable devfreq for now.
Signed-off-by: Nicolas Boichat
---
Changes in v7:
- Fix GPU ID in commit message
Changes in v6:
- New change
Looks good, thanks!
Reviewed-by: Tomeu Vizoso
On Fri, 30 Oct 2020 at 15:59, Steven Price wrote:
> When unloading the call to pm_runtime_put_sync_suspend() will attempt to
> turn the GPU cores off, however panfrost_device_fini() will have turned
> the clocks off. This leads to the
Hi Clément,
Have just noticed that my Pine H64 board hangs when I try to set the
performance governor for the GPU devfreq.
Is this a known bug?
Thanks,
Tomeu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Mon, 5 Oct 2020 at 08:44, Tomeu Vizoso wrote:
>
> On Fri, 19 Jun 2020 at 11:00, Steven Price wrote:
> >
> > On 11/06/2020 09:58, Tomeu Vizoso wrote:
> > > Mesa now supports some Bifrost devices, so enable it.
> > >
> > > Signed-off-by: To
On Fri, 19 Jun 2020 at 11:00, Steven Price 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
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.
That's bizarre -- this should really be the
Hi Rob,
Do you think we could make all these generic? Visualization tools will need
to do some processing so these can be neatly presented and it could be far
more convenient if people wouldn't need to add code for each GPU driver.
Maybe we could put all these tracepoints in DRM core as they
Mesa now supports some Bifrost devices, so enable it.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 882fecc33fdb..8ff8e140f91e
Bifrost devices do support the flush reduction feature, so on first job
submit we were trying to read the register while still powered off.
If the GPU is powered off, the feature doesn't bring any benefit, so
don't try to read.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/panfrost
On 5/29/20 2:38 PM, Clément Péron wrote:
Hi Steven
On Thu, 28 May 2020 at 15:22, Steven Price wrote:
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
On 5/10/20 6:55 PM, Clément Péron wrote:
Hi,
This serie cleans and adds regulator support to Panfrost devfreq.
This is mostly based on comment for the freshly introduced lima
devfreq.
We need to add regulator support because on Allwinner the GPU OPP
table defines both frequencies and voltages.
On Wed, 12 Feb 2020 at 21:22, Rob Herring wrote:
>
> From: Tomeu Vizoso
>
> If the exception type isn't a translation fault, don't try to map and
> instead go straight to a terminal fault.
>
> Otherwise, we can get flooded by kernel warnings and further faults.
>
>
On 2/10/20 4:39 AM, Nicolas Boichat wrote:
On Fri, Feb 7, 2020 at 4:13 PM Tomeu Vizoso wrote:
On 2/7/20 8:42 AM, Nicolas Boichat wrote:
On Fri, Feb 7, 2020 at 2:18 PM Tomeu Vizoso wrote:
Some more changes are still required to get devfreq working, and of course
I do not have a userspace
On 2/7/20 8:42 AM, Nicolas Boichat wrote:
On Fri, Feb 7, 2020 at 2:18 PM Tomeu Vizoso wrote:
On 2/7/20 6:26 AM, Nicolas Boichat wrote:
Hi!
Follow-up on the v3: https://patchwork.kernel.org/cover/11331343/.
The main purpose of this series is to upstream the dts change and the
binding
On 2/7/20 6:26 AM, Nicolas Boichat wrote:
Hi!
Follow-up on the v3: https://patchwork.kernel.org/cover/11331343/.
The main purpose of this series is to upstream the dts change and the
binding document, but I wanted to see how far I could probe the GPU, to
check that the binding is indeed
If the exception type isn't one of the normal faults, don't try to map
and instead go straight to a terminal fault.
Otherwise, we can get flooded by kernel warnings and further faults.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 5 +++--
1 file changed, 3
When deferring the probe because of a missing regulator, we were calling
pm_runtime_disable even if pm_runtime_enable wasn't called.
Move the call to pm_runtime_disable to the right place.
Signed-off-by: Tomeu Vizoso
Reported-by: Chen-Yu Tsai
Cc: Robin Murphy
Fixes: f4a3c6a44b35 (&quo
When deferring the probe because of a missing regulator, we were calling
pm_runtime_disable even if pm_runtime_enable wasn't called.
Move the call to pm_runtime_disable to the right place.
Signed-off-by: Tomeu Vizoso
Fixes: f4a3c6a44b35 ("drm/panfrost: Disable PM on probe failure")
On 10/7/19 6:09 AM, Neil Armstrong wrote:
Hi Steven,
On 07/10/2019 14:50, Steven Price wrote:
Panfrost uses multiple schedulers (one for each slot, so 2 in reality),
and on a timeout has to stop all the schedulers to safely perform a
reset. However more than one scheduler can trigger a timeout
. This also deletes the code changes from
52282163dfa6 and e21dd290881b which would otherwise need reverting, see
the previous discussion[2].
Both patches look great.
Reviewed-by: Tomeu Vizoso
Thanks!
Tomeu
[1] https://lore.kernel.org/lkml/20190904123032.23263-1-broo...@kernel.org/
[2] https
On 8/23/19 3:33 AM, 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: Tomeu Vizoso
---
MAINTAINERS | 2 ++
1 file
On 8/16/19 11:31 AM, Steven Price wrote:
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.
I like this in principle, but upon some quick testing I found that Mesa
is around 10%
On 8/9/19 5:01 AM, Rob Herring wrote:
On Thu, Aug 8, 2019 at 5:11 PM Alyssa Rosenzweig
wrote:
@@ -448,6 +453,7 @@ static irqreturn_t panfrost_job_irq_handler(int irq, void
*data)
}
if (status & JOB_INT_MASK_DONE(j)) {
+
On 8/5/19 11:10 PM, Rob Herring wrote:
On Mon, Aug 5, 2019 at 10:10 AM Tomeu Vizoso wrote:
On 8/2/19 9:51 PM, Rob Herring wrote:
This series adds new BO allocation flags PANFROST_BO_HEAP and
PANFROST_BO_NOEXEC. The heap allocations are paged in on GPU page faults.
Tomeu reports he has
On 8/2/19 9:51 PM, Rob Herring wrote:
This series adds new BO allocation flags PANFROST_BO_HEAP and
PANFROST_BO_NOEXEC. The heap allocations are paged in on GPU page faults.
Tomeu reports he has tested this in the panfrost CI.
All seems to be working fine:
On 8/2/19 9:57 PM, Rob Herring wrote:
There's a few features the driver supports which we forgot to remove, so
remove them now.
Cc: Tomeu Vizoso
Cc: Boris Brezillon
Signed-off-by: Rob Herring
---
drivers/gpu/drm/panfrost/TODO | 9 -
1 file changed, 9 deletions(-)
diff --git
On 7/25/19 5:52 AM, Yue Hu wrote:
From: Yue Hu
Since governor name is defined by DEVFREQ framework internally, use the
macro definition instead of using the name directly.
Signed-off-by: Yue Hu
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/msm/msm_gpu.c | 3 ++-
drivers
On Tue, 23 Jul 2019 at 09:14, Alyssa Rosenzweig wrote:
>
> > A fair bit of the complexity of kbase comes from trying to avoid the
> > possibility of one process DoSing another by submitting malicious jobs.
>
> ...and yet it was still doable so easily (by accident, with buggy jobs
> instead of
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, Jun 12, 2019 at 6:55 AM Tomeu Vizoso
> > > wrote:
> >
On Fri, 14 Jun 2019 at 23:22, Rob Herring wrote:
>
> On Wed, Jun 12, 2019 at 6:55 AM Tomeu Vizoso wrote:
> >
> > On Mon, 10 Jun 2019 at 19:06, Rob Herring wrote:
> > >
> > > The midgard/bifrost GPUs need to allocate GPU memory which is allocated
> > >
On Mon, 10 Jun 2019 at 18:58, Rob Herring wrote:
>
> In order to increase the chances of using 2MB pages, we need to align the
> GPU VA mapping to 2MB. Only do this if the object size is 2MB or more.
>
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Tomeu Vizoso
> Si
ill give this patch some testing tomorrow.
Thanks,
Tomeu
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Cc: Tomeu Vizoso
> Signed-off-by: Rob Herring
> ---
>
> drivers/gpu/drm/panfrost/TODO | 2 -
> drivers/gpu/drm/panfrost/panfrost_drv.c
Signed-off-by: Tomeu Vizoso
---
tests/panfrost_submit.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/tests/panfrost_submit.c b/tests/panfrost_submit.c
index 5770dc24a42b..13ce85b73d9e 100644
--- a/tests/panfrost_submit.c
+++ b/tests
T720 GPUs and older don't have support for MFBD, so use the SFBD structs
instead.
We don't know yet how to hang the GPU with SFBD descriptors, so for now
skip that test.
Signed-off-by: Tomeu Vizoso
---
lib/igt_panfrost.c | 71 +-
lib/igt_panfrost.h
On Wed, 29 May 2019 at 19:38, Robin Murphy wrote:
>
> On 29/05/2019 16:09, Tomeu Vizoso wrote:
> > On Tue, 21 May 2019 at 18:11, Clément Péron wrote:
> >>
> > [snip]
> >> [ 345.204813] panfrost 180.gpu: mmu irq status=1
> >> [ 345.209617] panf
On 6/5/19 8:48 PM, Ezequiel Garcia wrote:
Panfrost depends on the simple_ondemand governor, and therefore
it's a required configuration. Select it.
Fixes: f3617b449d ("drm/panfrost: Select devfreq")
Signed-off-by: Ezequiel Garcia
Good one, had totally forgotten about it.
Reviewed
On Mon, 3 Jun 2019 at 19:24, Clément Péron wrote:
>
> Hi,
>
>
> On Fri, 31 May 2019 at 14:13, Neil Armstrong wrote:
> >
> > On 31/05/2019 14:09, Tomeu Vizoso wrote:
> > > On Fri, 31 May 2019 at 14:03, Neil Armstrong
> > > wrote:
> > >>
On Wed, 29 May 2019 at 11:18, Boris Brezillon
wrote:
>
> mmu_ops->unmap() will fail when called on a BO that has not been
> previously mapped, and the error path in panfrost_ioctl_create_bo()
> can call drm_gem_object_put_unlocked() (which in turn calls
> panfrost_mmu_unmap()) on a BO that has
On Fri, 31 May 2019 at 14:03, Neil Armstrong wrote:
>
> Hi Tomeu,
>
> On 31/05/2019 13:59, Tomeu Vizoso wrote:
> > On Wed, 29 May 2019 at 23:29, Clément Péron wrote:
> >>
> >> Hi,
> >>
> >> I have rebase my kernel on latest 5
On Wed, 29 May 2019 at 19:38, Robin Murphy wrote:
>
> On 29/05/2019 16:09, Tomeu Vizoso wrote:
> > On Tue, 21 May 2019 at 18:11, Clément Péron wrote:
> >>
> > [snip]
> >> [ 345.204813] panfrost 180.gpu: mmu irq status=1
> >> [ 345.209617] panf
On Wed, 29 May 2019 at 23:29, Clément Péron wrote:
>
> Hi,
>
> I have rebase my kernel on latest 5.2-rc2, and my panfrost driver is
> no more probing.
>
> The issue is coming from f3617b449d0bcf3b5d80a97f51498dcf7463cf7e
> drm/panfrost: Select devfreq
>
> Currently, there is some logic
On Wed, 29 May 2019 at 15:00, Robin Murphy wrote:
>
> Hi Tomeu, Rob,
>
> On 28/05/2019 08:03, Tomeu Vizoso wrote:
> > Robin, Steven,
> >
> > would you or someone else at Arm be able to run the IGT tests [0] on
> > 5.2-rc2 with this patch on top?
> >
&
On Tue, 21 May 2019 at 18:11, Clément Péron wrote:
>
[snip]
> [ 345.204813] panfrost 180.gpu: mmu irq status=1
> [ 345.209617] panfrost 180.gpu: Unhandled Page fault in AS0 at VA
> 0x02400400
>From what I can see here, 0x02400400 points to the first byte
of the first
Robin, Steven,
would you or someone else at Arm be able to run the IGT tests [0] on
5.2-rc2 with this patch on top?
I don't have any hw with Bifrost and am not planning to work on the
userspace any time soon, but I think it would be good to at least
check that the kernel doesn't have any obvious
On 5/14/19 5:36 PM, Ezequiel Garcia wrote:
On Tue, 2019-05-14 at 08:38 -0500, Rob Herring wrote:
On Mon, May 13, 2019 at 12:56 PM Ezequiel Garcia wrote:
Currently, there is some logic to make devfreq optional,
but it fails to cover some cases such as !CONFIG_PM_DEVFREQ.
Fails how?
-by: Tomeu Vizoso
Reported-by: Dan Carpenter
Link: https://lists.freedesktop.org/archives/dri-devel/2019-May/217014.html
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost
On Wed, 24 Apr 2019 at 15:20, Daniel Vetter wrote:
>
> On Wed, Apr 24, 2019 at 03:13:53PM +0200, Tomeu Vizoso wrote:
> > So userspace can get feedback on any error conditions, instead of going
> > ahead and things breaking later.
> >
> > Signed-off-by: Tome
So userspace can get feedback on any error conditions, instead of going
ahead and things breaking later.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 35 +
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm
If a job times out in slot 0 while a reset is performed because a job
timed out in slot 1, the drm-sched core can get into a deadlock.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/panfrost/panfrost_device.c | 1 +
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
drivers/gpu/drm/panfrost
Both patches are:
Reviewed-by: Tomeu Vizoso
Thanks!
On 4/17/19 4:51 PM, Steven Price wrote:
On 16/04/2019 16:00, Yue Haibing wrote:
From: YueHaibing
Fix sparse warning:
drivers/gpu/drm/panfrost/panfrost_gem.c:17:6:
warning: symbol 'panfrost_gem_free_object' was not declared. Should
1 - 100 of 397 matches
Mail list logo
