On Fri, Jun 14, 2024 at 2:07 PM Robin Murphy wrote:
>
> On 2024-06-13 10:38 pm, Sebastian Reichel wrote:
> > Hi,
> >
> > On Thu, Jun 13, 2024 at 11:34:02AM GMT, Tomeu Vizoso wrote:
> >> On Thu, Jun 13, 2024 at 11:24 AM Tomeu Vizoso
> >> wrote:
>
On Thu, Jun 13, 2024 at 11:38 PM Sebastian Reichel
wrote:
>
> Hi,
>
> On Thu, Jun 13, 2024 at 11:34:02AM GMT, Tomeu Vizoso wrote:
> > On Thu, Jun 13, 2024 at 11:24 AM Tomeu Vizoso wrote:
> > > On Thu, Jun 13, 2024 at 2:05 AM Sebastian Reichel
> > > wrote:
&
On Wed, Jun 26, 2024 at 9:26 PM Daniel Stone wrote:
>
> On Wed, 26 Jun 2024 at 18:52, Daniel Vetter wrote:
> > On Wed, Jun 26, 2024 at 11:39:01AM +0100, Daniel Stone wrote:
> > > On Wed, 26 Jun 2024 at 09:28, Lucas Stach wrote:
> > > > So we are kind of stuck here between breaking one or the oth
Hi Lucas,
Do you have any idea on how not to break userspace if we expose a render node?
Cheers,
Tomeu
On Wed, Jun 12, 2024 at 4:26 PM Tomeu Vizoso wrote:
>
> On Mon, May 20, 2024 at 1:19 PM Daniel Stone wrote:
> >
> > Hi,
> >
> > On Mon, 20 May 2024 at 08:39,
On Thu, Jun 13, 2024 at 11:24 AM Tomeu Vizoso wrote:
>
> On Thu, Jun 13, 2024 at 2:05 AM Sebastian Reichel
> wrote:
> >
> > Hi,
> >
> > On Wed, Jun 12, 2024 at 03:52:55PM GMT, Tomeu Vizoso wrote:
> > > IOMMUs with multiple base addresses
On Thu, Jun 13, 2024 at 2:05 AM Sebastian Reichel
wrote:
>
> Hi,
>
> On Wed, Jun 12, 2024 at 03:52:55PM GMT, Tomeu Vizoso wrote:
> > IOMMUs with multiple base addresses can also have multiple power
> > domains.
> >
> > The base framework only takes ca
On Mon, May 20, 2024 at 1:19 PM Daniel Stone wrote:
>
> Hi,
>
> On Mon, 20 May 2024 at 08:39, Tomeu Vizoso wrote:
> > On Fri, May 10, 2024 at 10:34 AM Lucas Stach wrote:
> > > Am Mittwoch, dem 24.04.2024 um 08:37 +0200 schrieb Tomeu Vizoso:
> > > > If w
same IOCTLs from the Etnaviv driver.
Signed-off-by: Tomeu Vizoso
---
drivers/accel/rocket/rocket_drv.c | 2 ++
drivers/accel/rocket/rocket_gem.c | 68 +++
drivers/accel/rocket/rocket_gem.h | 7 +++-
include/uapi/drm/rocket_accel.h | 20 +++-
4
Using the DRM GPU scheduler infrastructure, with a scheduler for each
core.
Userspace can decide for a series of tasks to be executed sequentially
in the same core, so SRAM locality can be taken advantage of.
The job submission code was intially based on Panfrost.
Signed-off-by: Tomeu Vizoso
This uses the SHMEM DRM helpers and we map right away to the CPU and NPU
sides, as all buffers are expected to be accessed from both.
Signed-off-by: Tomeu Vizoso
---
drivers/accel/rocket/Makefile | 3 +-
drivers/accel/rocket/rocket_drv.c | 7 +++-
drivers/accel/rocket/rocket_gem.c | 68
See Chapter 36 "RKNN" from the RK3588 TRM (Part 1).
This is a derivative of NVIDIA's NVDLA, but with its own front-end
processor.
Mostly taken from downstream.
Signed-off-by: Tomeu Vizoso
---
arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 53 +++
1 f
Enable the nodes added in a previous commit to the rk3588s device tree.
Signed-off-by: Tomeu Vizoso
---
arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
b/arch/arm64/boot/dts
Add the bindings for the Neural Processing Unit IP from Rockchip.
Signed-off-by: Tomeu Vizoso
---
.../devicetree/bindings/npu/rockchip,rknn.yaml | 123 +
1 file changed, 123 insertions(+)
diff --git a/Documentation/devicetree/bindings/npu/rockchip,rknn.yaml
b
the DT.
This is needed by the IOMMU used by the NPU in the RK3588.
Signed-off-by: Tomeu Vizoso
---
drivers/iommu/rockchip-iommu.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index
So far, seems to be fully compatible with the one in the RK3568.
The bindings already had this compatible, but the driver didn't
advertise it.
Signed-off-by: Tomeu Vizoso
---
drivers/iommu/rockchip-iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/rockchip-iomm
/mesa/mesa/-/merge_requests/29698
Signed-off-by: Tomeu Vizoso
---
Tomeu Vizoso (9):
iommu/rockchip: Add compatible for rockchip,rk3588-iommu
iommu/rockchip: Attach multiple power domains
dt-bindings: mailbox: rockchip,rknn: Add bindings
arm64: dts: rockchip: Add nodes for
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 Thu, May 23, 2024 at 8:35 AM Jacek Lawrynowicz
wrote:
>
> Hi,
>
> On 21.05.2024 17:10, Jeffrey Hugo wrote:
> > On 5/21/2024 8:41 AM, Tomeu Vizoso wrote:
> >> On Tue, May 21, 2024 at 2:12 PM Daniel Vetter wrote:
> >>>
> >>> On Sat, M
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 composit
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 tell
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
away 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
&
and retry 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_d
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
d increment the minor version 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 |
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/etn
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/etn
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/etn
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
ebase 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
ebase 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-s
ailures 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/amd
ff-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 +
driver
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
pass 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 +++
driver
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 the
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 the
ecute 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.tes
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
ecute 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/m
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 instea
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, wi
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
drivers/g
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
https://lists.freedesktop.org/mail
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 (
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 faster
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 seem
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/dr
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 de
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 correct
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
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
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&q
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
() misuse. 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
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% slow
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)) {
+ panfrost_mmu_as_put(p
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:
https://gitlab.freedesktop.org/tomeu
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 --
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 mali
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
GPUs will be the most interesting to support...
Will 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 |
1 - 100 of 416 matches
Mail list logo
