Re: [PATCH v10 0/4] drm/panfrost: Add support for mt8183 GPU

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,

Re: [PATCH v7 3/4] drm/panfrost: devfreq: Disable devfreq when num_supplies > 1

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

Re: [PATCH v7 3/4] drm/panfrost: devfreq: Disable devfreq when num_supplies > 1

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

devfreq and panfrost on Allwinner H6

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

Re: [PATCH 2/2] panfrost: Add compatible string for bifrost

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

Re: [PATCH 2/2] panfrost: Add compatible string for bifrost

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

[PATCH 1/2] panfrost: Make sure GPU is powered on when reading GPU_LATEST_FLUSH_ID

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

[PATCH 2/2] panfrost: Add compatible string for bifrost

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

Re: [PATCH 08/15] drm/panfrost: move devfreq_init()/fini() in device

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

Re: [PATCH 00/15][RFC] Add regulator devfreq support to Panfrost

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.

[PATCH 1/2] ARM: multi_v7_defconfig: add Panfrost driver

With the goal of making it easier for CI services such as KernelCI to run tests for it. Signed-off-by: Tomeu Vizoso --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index

[PATCH 2/2] arm64: defconfig: add Panfrost driver

With the goal of making it easier for CI services such as KernelCI to run tests for it. Signed-off-by: Tomeu Vizoso --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 4d583514258c..d588ceb9aa3c

Re: [PATCH v6 0/6] Allwinner H6 Mali GPU support

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

Re: [PATCH] arm64: dts: allwinner: Add GPU operating points for H6

On Wed, 29 May 2019 at 17:37, Clément Péron wrote: > > Hi Tomeu, > > On Wed, 29 May 2019 at 17:33, Tomeu Vizoso wrote: > > > > The GPU driver needs them to change the clock frequency and regulator > > voltage depending on the load. > > As requested by Ma

[PATCH] arm64: dts: allwinner: Add GPU operating points for H6

The GPU driver needs them to change the clock frequency and regulator voltage depending on the load. Signed-off-by: Tomeu Vizoso Cc: Clément Péron --- Feel free to pick up this patch if you are going to keep pushing this series forward. Thanks, Tomeu --- arch/arm64/boot/dts/allwinner

Re: [GIT PULL] Thermal-SoC management changes for v5.2-rc1

On Fri, 24 May 2019 at 15:54, Eduardo Valentin wrote: > > Hello, > > On Fri, May 24, 2019 at 10:23:09AM +0200, Tomeu Vizoso wrote: > > On Fri, 24 May 2019 at 04:40, Eduardo Valentin wrote: > > > > > > On Thu, May 23, 2019 at 11:46:47AM +0200, To

Re: [GIT PULL] Thermal-SoC management changes for v5.2-rc1

On Fri, 24 May 2019 at 04:40, Eduardo Valentin wrote: > > On Thu, May 23, 2019 at 11:46:47AM +0200, Tomeu Vizoso wrote: > > Hi Eduardo, > > > > I saw that for 5.1 [0] you included a kernelci boot report for your > > tree, but not for 5.2. Have you found an

Re: [GIT PULL] Thermal-SoC management changes for v5.2-rc1

Hi Eduardo, I saw that for 5.1 [0] you included a kernelci boot report for your tree, but not for 5.2. Have you found anything that should be improved in KernelCI for it to be more useful to maintainers like you? [0] https://lore.kernel.org/lkml/20190306161207.GA7365@localhost.localdomain/ I

Re: [PATCH] drm/panfrost: Add sanity checks to submit IOCTL

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

Re: [PATCH] PM / devfreq: Return -ENODEV from try_then_request_governor

On Tue, 23 Apr 2019 at 11:56, Enric Balletbo i Serra wrote: > > Hi Tomeu, > > On 23/4/19 10:11, Tomeu Vizoso wrote: > > Callers don't expect it to return NULL, but an error code. > > > > Fixes Oops such as the one below, when one tries to set a governor that >

[PATCH] PM / devfreq: Return -ENODEV from try_then_request_governor

) [] (kernfs_fop_write) from [] (__vfs_write+0x2c/0x17c) [] (__vfs_write) from [] (vfs_write+0xa4/0x184) [] (vfs_write) from [] (ksys_write+0x4c/0xac) [] (ksys_write) from [] (ret_fast_syscall+0x0/0x28) Signed-off-by: Tomeu Vizoso Fixes: 23c7b54ca1cd ("PM / devfreq: Fix devfreq_add_device() when dr

[PATCH v4] arm64: dts: rockchip: Add DT for nanopc-t4

and NanoPi NEO4. Signed-off-by: Tomeu Vizoso --- v2: - Rename compatible from friendlyelec to friendlyarm, to match existing bindings - Remove superfluous node spi1 v3: - Rewrite regulator tree to match the schematics (Heiko) - Sort top-level nodes alphabetically (Heiko) - Used

[PATCH v4] arm64: dts: rockchip: Add DT for nanopc-t4

and NanoPi NEO4. Signed-off-by: Tomeu Vizoso --- v2: - Rename compatible from friendlyelec to friendlyarm, to match existing bindings - Remove superfluous node spi1 v3: - Rewrite regulator tree to match the schematics (Heiko) - Sort top-level nodes alphabetically (Heiko) - Used

[PATCH v3] arm64: dts: rockchip: Add DT for nanopc-t4

and NanoPi NEO4. Signed-off-by: Tomeu Vizoso --- v2: - Rename compatible from friendlyelec to friendlyarm, to match existing bindings - Remove superfluous node spi1 v3: - Rewrite regulator tree to match the schematics (Heiko) - Sort top-level nodes alphabetically (Heiko) - Used

[PATCH v3] arm64: dts: rockchip: Add DT for nanopc-t4

and NanoPi NEO4. Signed-off-by: Tomeu Vizoso --- v2: - Rename compatible from friendlyelec to friendlyarm, to match existing bindings - Remove superfluous node spi1 v3: - Rewrite regulator tree to match the schematics (Heiko) - Sort top-level nodes alphabetically (Heiko) - Used

[PATCH v2] arm64: dts: rockchip: Add DT for nanopc-t4

and NanoPi NEO4. Signed-off-by: Tomeu Vizoso --- v2: - Rename compatible from friendlyelec to friendlyarm, to match existing bindings - Remove superfluous node spi1 --- .../devicetree/bindings/arm/rockchip.txt | 4 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot

[PATCH v2] arm64: dts: rockchip: Add DT for nanopc-t4

and NanoPi NEO4. Signed-off-by: Tomeu Vizoso --- v2: - Rename compatible from friendlyelec to friendlyarm, to match existing bindings - Remove superfluous node spi1 --- .../devicetree/bindings/arm/rockchip.txt | 4 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot

[PATCH] arm64: dts: rockchip: Add DT for nanopc-t4

and NanoPi NEO4. Signed-off-by: Tomeu Vizoso --- .../devicetree/bindings/arm/rockchip.txt | 4 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3399-nanopc-t4.dts| 18 + .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 782 ++ 4 files changed

[PATCH] arm64: dts: rockchip: Add DT for nanopc-t4

and NanoPi NEO4. Signed-off-by: Tomeu Vizoso --- .../devicetree/bindings/arm/rockchip.txt | 4 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3399-nanopc-t4.dts| 18 + .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 782 ++ 4 files changed

Re: [PATCH v4] usb: dwc2: dwc2_vbus_supply_init: fix error check

gt;> >>> On 4/10/2018 4:28 PM, Heiko Stuebner wrote: >>>> Am Montag, 26. März 2018, 11:00:01 CEST schrieb Tomeu Vizoso: >>>>> devm_regulator_get_optional returns -ENODEV if the regulator isn't >>>>> there, so if that's the case we have to make sure no

Re: [PATCH v4] usb: dwc2: dwc2_vbus_supply_init: fix error check

, Heiko Stuebner wrote: >>>> Am Montag, 26. März 2018, 11:00:01 CEST schrieb Tomeu Vizoso: >>>>> devm_regulator_get_optional returns -ENODEV if the regulator isn't >>>>> there, so if that's the case we have to make sure not to leave -ENODEV >>>>

Re: [PATCH v8 07/14] ARM: dts: rockchip: add clocks in iommu nodes

Hi there, in today's linux-next, the DRM driver fails to probe because the iommu driver fails to find the aclk. I need to apply this patch for things to work again. Thanks, Tomeu On 23 March 2018 at 08:38, Jeffy Chen wrote: > Add clocks in iommu nodes, since we are

Re: [PATCH v8 07/14] ARM: dts: rockchip: add clocks in iommu nodes

Hi there, in today's linux-next, the DRM driver fails to probe because the iommu driver fails to find the aclk. I need to apply this patch for things to work again. Thanks, Tomeu On 23 March 2018 at 08:38, Jeffy Chen wrote: > Add clocks in iommu nodes, since we are going to control clocks in

Re: [PATCH v4] usb: dwc2: dwc2_vbus_supply_init: fix error check

Hi Minas, On 04/05/2018 09:54 AM, Minas Harutyunyan wrote: Hi Tomeu, On 3/26/2018 1:01 PM, Tomeu Vizoso wrote: devm_regulator_get_optional returns -ENODEV if the regulator isn't there, so if that's the case we have to make sure not to leave -ENODEV in the regulator pointer. Also, make sure

Re: [PATCH v4] usb: dwc2: dwc2_vbus_supply_init: fix error check

Hi Minas, On 04/05/2018 09:54 AM, Minas Harutyunyan wrote: Hi Tomeu, On 3/26/2018 1:01 PM, Tomeu Vizoso wrote: devm_regulator_get_optional returns -ENODEV if the regulator isn't there, so if that's the case we have to make sure not to leave -ENODEV in the regulator pointer. Also, make sure

Re: [PATCH v4] usb: dwc2: dwc2_vbus_supply_init: fix error check

Could this patch be picked up, please? Thanks, Tomeu On 26 March 2018 at 13:51, Heiko Stübner <he...@sntech.de> wrote: > Am Montag, 26. März 2018, 11:00:01 CEST schrieb Tomeu Vizoso: >> devm_regulator_get_optional returns -ENODEV if the regulator isn't >> there, so if th

Re: [PATCH v4] usb: dwc2: dwc2_vbus_supply_init: fix error check

Could this patch be picked up, please? Thanks, Tomeu On 26 March 2018 at 13:51, Heiko Stübner wrote: > Am Montag, 26. März 2018, 11:00:01 CEST schrieb Tomeu Vizoso: >> devm_regulator_get_optional returns -ENODEV if the regulator isn't >> there, so if that's the case we ha

[PATCH v4] usb: dwc2: dwc2_vbus_supply_init: fix error check

. Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus supply") Cc: Amelie Delaunay <amelie.delau...@st.com> Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com> --- v2: Only overwrite the error in the pointer after checking it (Heiko Stübner <he.

[PATCH v4] usb: dwc2: dwc2_vbus_supply_init: fix error check

. Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus supply") Cc: Amelie Delaunay Signed-off-by: Tomeu Vizoso --- v2: Only overwrite the error in the pointer after checking it (Heiko Stübner ) v3: Remove hunks that shouldn't be in this patch v4: Don't overwrite

[PATCH] usb: hub: Reduce warning to notice on power loss

Currently we warn the user when the root hub lost power after resume, but the user cannot do anything about it so it should probably be a notice. This will reduce the noise in the console during suspend and resume, which is already quite significant in many systems. Signed-off-by: Tomeu Vizoso

[PATCH] usb: hub: Reduce warning to notice on power loss

Currently we warn the user when the root hub lost power after resume, but the user cannot do anything about it so it should probably be a notice. This will reduce the noise in the console during suspend and resume, which is already quite significant in many systems. Signed-off-by: Tomeu Vizoso

[PATCH v1] printk: change message to pr_info

To allow userspace to prevent this message from appearing in the console by changing the log priority. This matches other informative messages that the power subsystem emits when the system changes power states. Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com> --- kernel/printk/pr

[PATCH v1] printk: change message to pr_info

To allow userspace to prevent this message from appearing in the console by changing the log priority. This matches other informative messages that the power subsystem emits when the system changes power states. Signed-off-by: Tomeu Vizoso --- kernel/printk/printk.c | 2 +- 1 file changed, 1

Re: [PATCH v3] usb: dwc2: dwc2_vbus_supply_init: fix error check

On 03/22/2018 02:26 PM, Heiko Stübner wrote: Am Donnerstag, 22. März 2018, 14:14:51 CET schrieb Tomeu Vizoso: devm_regulator_get_optional returns -ENODEV if the regulator isn't there, so if that's the case we have to make sure not to leave -ENODEV in the regulator pointer. Also, make sure we

Re: [PATCH v3] usb: dwc2: dwc2_vbus_supply_init: fix error check

On 03/22/2018 02:26 PM, Heiko Stübner wrote: Am Donnerstag, 22. März 2018, 14:14:51 CET schrieb Tomeu Vizoso: devm_regulator_get_optional returns -ENODEV if the regulator isn't there, so if that's the case we have to make sure not to leave -ENODEV in the regulator pointer. Also, make sure we

[PATCH v3] usb: dwc2: dwc2_vbus_supply_init: fix error check

. Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus supply") Cc: Amelie Delaunay <amelie.delau...@st.com> Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com> --- v2: Only overwrite the error in the pointer after checking it (Heiko Stübner <he.

[PATCH v3] usb: dwc2: dwc2_vbus_supply_init: fix error check

. Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus supply") Cc: Amelie Delaunay Signed-off-by: Tomeu Vizoso --- v2: Only overwrite the error in the pointer after checking it (Heiko Stübner ) v3: Remove hunks that shouldn't be in this patch --- drivers/usb/

[PATCH v2] usb: dwc2: dwc2_vbus_supply_init: fix error check

. Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus supply") Cc: Amelie Delaunay <amelie.delau...@st.com> Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com> --- v2: Only overwrite the error in the pointer after checking it (Heiko Stübner <he

[PATCH v2] usb: dwc2: dwc2_vbus_supply_init: fix error check

. Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus supply") Cc: Amelie Delaunay Signed-off-by: Tomeu Vizoso --- v2: Only overwrite the error in the pointer after checking it (Heiko Stübner ) --- arch/arm/configs/multi_v7_defconfig | 3 +++ drivers/usb/

[PATCH] usb: dwc2: dwc2_vbus_supply_init: fix error check

. Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus supply") Cc: Amelie Delaunay <amelie.delau...@st.com> Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com> --- drivers/usb/dwc2/hcd.c | 13 - 1 file changed, 8 insertions(+), 5 de

[PATCH] usb: dwc2: dwc2_vbus_supply_init: fix error check

. Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus supply") Cc: Amelie Delaunay Signed-off-by: Tomeu Vizoso --- drivers/usb/dwc2/hcd.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/h

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 02/12/2018 12:45 PM, Gerd Hoffmann wrote: 4. QEMU pops data+buffers from the virtqueue, looks up shmem FD for each resource, sends data + FDs to the compositor with SCM_RIGHTS >>> >>> BTW: Is there a 1:1 relationship between buffers and shmem blocks? Or >>> does the wayland protocol

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 02/12/2018 12:45 PM, Gerd Hoffmann wrote: 4. QEMU pops data+buffers from the virtqueue, looks up shmem FD for each resource, sends data + FDs to the compositor with SCM_RIGHTS >>> >>> BTW: Is there a 1:1 relationship between buffers and shmem blocks? Or >>> does the wayland protocol

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 02/12/2018 12:45 PM, Gerd Hoffmann wrote: Hi, (a) software rendering: client allocates shared memory buffer, renders into it, then passes a file handle for that shmem block together with some meta data (size, format, ...) to the wayland server. (b) gpu rendering:

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 02/12/2018 12:45 PM, Gerd Hoffmann wrote: Hi, (a) software rendering: client allocates shared memory buffer, renders into it, then passes a file handle for that shmem block together with some meta data (size, format, ...) to the wayland server. (b) gpu rendering:

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 02/12/2018 03:27 PM, Gerd Hoffmann wrote: On Mon, Feb 12, 2018 at 03:00:24PM +0100, Tomeu Vizoso wrote: On 02/12/2018 12:52 PM, Gerd Hoffmann wrote: Hi, can we reach agreement on whether vsock should be involved in this? I think the best approach would be to have guest proxy

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 02/12/2018 03:27 PM, Gerd Hoffmann wrote: On Mon, Feb 12, 2018 at 03:00:24PM +0100, Tomeu Vizoso wrote: On 02/12/2018 12:52 PM, Gerd Hoffmann wrote: Hi, can we reach agreement on whether vsock should be involved in this? I think the best approach would be to have guest proxy

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 02/12/2018 12:52 PM, Gerd Hoffmann wrote: Hi, can we reach agreement on whether vsock should be involved in this? I think the best approach would be to have guest proxy and host proxy use vsock for the wayland protocol. Use a wayland protocol extension to reference the buffers in

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 02/12/2018 12:52 PM, Gerd Hoffmann wrote: Hi, can we reach agreement on whether vsock should be involved in this? I think the best approach would be to have guest proxy and host proxy use vsock for the wayland protocol. Use a wayland protocol extension to reference the buffers in

Re: [PATCH v3 1/2] drm/virtio: Add window server support

Hi Gerd and Stefan, can we reach agreement on whether vsock should be involved in this? Thanks, Tomeu On 02/07/2018 10:49 AM, Tomeu Vizoso wrote: On 02/06/2018 03:23 PM, Gerd Hoffmann wrote:    Hi, Hmm?  I'm assuming the wayland client (in the guest) talks to the wayland proxy, using

Re: [PATCH v3 1/2] drm/virtio: Add window server support

Hi Gerd and Stefan, can we reach agreement on whether vsock should be involved in this? Thanks, Tomeu On 02/07/2018 10:49 AM, Tomeu Vizoso wrote: On 02/06/2018 03:23 PM, Gerd Hoffmann wrote:    Hi, Hmm?  I'm assuming the wayland client (in the guest) talks to the wayland proxy, using

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 02/06/2018 03:23 PM, Gerd Hoffmann wrote: Hi, Hmm? I'm assuming the wayland client (in the guest) talks to the wayland proxy, using the wayland protocol, like it would talk to a wayland display server. Buffers must be passed from client to server/proxy somehow, probably using fd

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 02/06/2018 03:23 PM, Gerd Hoffmann wrote: Hi, Hmm? I'm assuming the wayland client (in the guest) talks to the wayland proxy, using the wayland protocol, like it would talk to a wayland display server. Buffers must be passed from client to server/proxy somehow, probably using fd

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 02/07/2018 02:09 AM, Michael S. Tsirkin wrote: On Tue, Feb 06, 2018 at 03:23:02PM +0100, Gerd Hoffmann wrote: Creation of shareable buffer by guest - 1. Client requests virtio driver to create a buffer suitable for sharing with host

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 02/07/2018 02:09 AM, Michael S. Tsirkin wrote: On Tue, Feb 06, 2018 at 03:23:02PM +0100, Gerd Hoffmann wrote: Creation of shareable buffer by guest - 1. Client requests virtio driver to create a buffer suitable for sharing with host

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 02/05/2018 05:03 PM, Gerd Hoffmann wrote: On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote: On 02/05/2018 01:20 PM, Gerd Hoffmann wrote: Hi, Why not use virtio-vsock to run the wayland protocol? I don't like the idea to duplicate something with very simliar functionality

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 02/05/2018 05:03 PM, Gerd Hoffmann wrote: On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote: On 02/05/2018 01:20 PM, Gerd Hoffmann wrote: Hi, Why not use virtio-vsock to run the wayland protocol? I don't like the idea to duplicate something with very simliar functionality

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 02/05/2018 01:20 PM, Gerd Hoffmann wrote: Hi, Why not use virtio-vsock to run the wayland protocol? I don't like the idea to duplicate something with very simliar functionality in virtio-gpu. The reason for abandoning that approach was the type of objects that could be shared via

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 02/05/2018 01:20 PM, Gerd Hoffmann wrote: Hi, Why not use virtio-vsock to run the wayland protocol? I don't like the idea to duplicate something with very simliar functionality in virtio-gpu. The reason for abandoning that approach was the type of objects that could be shared via

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 1 February 2018 at 17:36, Gerd Hoffmann wrote: Hi, Sorry for joining the party late. Had a broken finger and was offline for a bunch of weeks (and a buif backlog afterwards ...). Hi, no problem, hope it's fine now. This is to allow clients running within VMs to be

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On 1 February 2018 at 17:36, Gerd Hoffmann wrote: Hi, Sorry for joining the party late. Had a broken finger and was offline for a bunch of weeks (and a buif backlog afterwards ...). Hi, no problem, hope it's fine now. This is to allow clients running within VMs to be able to communicate

[PATCH v3 2/2] drm/virtio: Handle buffers from the compositor

When retrieving queued messages from the compositor in the host for clients in the guest, handle buffers that may be passed. These buffers should have been mapped to the guest's address space, for example via the KVM_SET_USER_MEMORY_REGION ioctl. Signed-off-by: Tomeu Vizoso <tomeu.

[PATCH v3 2/2] drm/virtio: Handle buffers from the compositor

When retrieving queued messages from the compositor in the host for clients in the guest, handle buffers that may be passed. These buffers should have been mapped to the guest's address space, for example via the KVM_SET_USER_MEMORY_REGION ioctl. Signed-off-by: Tomeu Vizoso --- drivers/gpu

[PATCH v3 1/2] drm/virtio: Add window server support

absence of winsrv support in QEMU (Dave Airlie) Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com> --- drivers/gpu/drm/virtio/virtgpu_drv.c | 1 + drivers/gpu/drm/virtio/virtgpu_drv.h | 39 - drivers/gpu/drm/virtio/virtgpu_ioctl.c | 165 +++ drivers/gpu/drm/

[PATCH v3 1/2] drm/virtio: Add window server support

absence of winsrv support in QEMU (Dave Airlie) Signed-off-by: Tomeu Vizoso --- drivers/gpu/drm/virtio/virtgpu_drv.c | 1 + drivers/gpu/drm/virtio/virtgpu_drv.h | 39 - drivers/gpu/drm/virtio/virtgpu_ioctl.c | 165 +++ drivers/gpu/drm/virtio/virtgpu_kms.c | 66

[PATCH v3 0/2] drm/virtio: Add window server support

to the host part of a resource, so the extra copy in TRANSFER_TO_HOST isn't needed. Have pushed the QEMU counterpart to this branch, though it isn't as polished atm: https://gitlab.collabora.com/tomeu/qemu/commits/winsrv-wip Thanks, Tomeu Tomeu Vizoso (2): drm/virtio: Add window server support drm

[PATCH v3 0/2] drm/virtio: Add window server support

to the host part of a resource, so the extra copy in TRANSFER_TO_HOST isn't needed. Have pushed the QEMU counterpart to this branch, though it isn't as polished atm: https://gitlab.collabora.com/tomeu/qemu/commits/winsrv-wip Thanks, Tomeu Tomeu Vizoso (2): drm/virtio: Add window server support drm

Re: [PATCH] drm/virtio: Add window server support

On 01/12/2018 05:11 AM, Dave Airlie wrote: this work is based on the virtio_wl driver in the ChromeOS kernel by Zach Reizner, currently at: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c There's two features missing in this patch when

Re: [PATCH] drm/virtio: Add window server support

On 01/12/2018 05:11 AM, Dave Airlie wrote: this work is based on the virtio_wl driver in the ChromeOS kernel by Zach Reizner, currently at: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c There's two features missing in this patch when

Re: [PATCH] drm/virtio: Add window server support

On 28 December 2017 at 12:53, Tomeu Vizoso <tomeu.viz...@collabora.com> wrote: > This is to allow clients running within VMs to be able to communicate > with a compositor in the host. Clients will use the communication > protocol that the compositor supports, and virtio-

Re: [PATCH] drm/virtio: Add window server support

On 28 December 2017 at 12:53, Tomeu Vizoso wrote: > This is to allow clients running within VMs to be able to communicate > with a compositor in the host. Clients will use the communication > protocol that the compositor supports, and virtio-gpu will assist with > making buffers avail

Re: [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv

On 26 December 2017 at 19:19, Matt Roper wrote: > On Wed, Dec 20, 2017 at 10:59:57AM +0100, Daniel Vetter wrote: >> On Tue, Dec 19, 2017 at 03:27:31PM -0800, Dongwon Kim wrote: >> > I forgot to include this brief information about this patch series. >> > >> > This patch

Re: [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv

On 26 December 2017 at 19:19, Matt Roper wrote: > On Wed, Dec 20, 2017 at 10:59:57AM +0100, Daniel Vetter wrote: >> On Tue, Dec 19, 2017 at 03:27:31PM -0800, Dongwon Kim wrote: >> > I forgot to include this brief information about this patch series. >> > >> > This patch series contains the

[PATCH] drm/virtio: Add window server support

-by: Tomeu Vizoso <tomeu.viz...@collabora.com> Cc: Zach Reizner <za...@google.com> --- Hi, this work is based on the virtio_wl driver in the ChromeOS kernel by Zach Reizner, currently at: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio

[PATCH] drm/virtio: Add window server support

-by: Tomeu Vizoso Cc: Zach Reizner --- Hi, this work is based on the virtio_wl driver in the ChromeOS kernel by Zach Reizner, currently at: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c There's two features missing in this patch when

[PATCH] drm/virtio: Add window server support

tested with Wayland clients that make use of wl_shm to pass buffers to the compositor, but is expected to work similarly for X clients that make use of MIT-SHM with FD passing. Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com> Cc: Zach Reizner <za...@google.com> --- Hi, this w

[PATCH] drm/virtio: Add window server support

tested with Wayland clients that make use of wl_shm to pass buffers to the compositor, but is expected to work similarly for X clients that make use of MIT-SHM with FD passing. Signed-off-by: Tomeu Vizoso Cc: Zach Reizner --- Hi, this work is based on the virtio_wl driver in the ChromeOS kernel

[PATCH] drm/virtio: Don't return invalid caps on timeout

If the wait timeouts, the caps are probably invalid and we shouldn't be passing them to userspace. Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com> --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_ioct

[PATCH] drm/virtio: Don't return invalid caps on timeout

If the wait timeouts, the caps are probably invalid and we shouldn't be passing them to userspace. Signed-off-by: Tomeu Vizoso --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio

Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

And now with the correct email. Sorry about that, Tomeu On 16 November 2017 at 10:16, Tomeu Vizoso <to...@tomeuvizoso.net> wrote: > Adding regress...@leemhuis.info to CC so this regression is tracked. > > Regards, > > Tomeu > > On 8 November 2017 at 09:37, Tomeu Vi

Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

And now with the correct email. Sorry about that, Tomeu On 16 November 2017 at 10:16, Tomeu Vizoso wrote: > Adding regress...@leemhuis.info to CC so this regression is tracked. > > Regards, > > Tomeu > > On 8 November 2017 at 09:37, Tomeu Vizoso wrote: >> On 6

Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

Adding regress...@leemhuis.info to CC so this regression is tracked. Regards, Tomeu On 8 November 2017 at 09:37, Tomeu Vizoso <to...@tomeuvizoso.net> wrote: > On 6 November 2017 at 23:01, Tom Lendacky <thomas.lenda...@amd.com> wrote: >> On 11/6/2017 3:41 PM, H. Peter Anvin

Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

Adding regress...@leemhuis.info to CC so this regression is tracked. Regards, Tomeu On 8 November 2017 at 09:37, Tomeu Vizoso wrote: > On 6 November 2017 at 23:01, Tom Lendacky wrote: >> On 11/6/2017 3:41 PM, H. Peter Anvin wrote: >>> >>> On 11/06/17 12:17, Tom Len

Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

c_id(). >>> >>> Add a boolean variable that is set to true when the MP-table is found. >>> Use this variable for testing if the MP-table was found so that even a >>> value of 0 for mpf_base will result in continued parsing of the MP-table. >>> >>> R

Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

> Add a boolean variable that is set to true when the MP-table is found. >>> Use this variable for testing if the MP-table was found so that even a >>> value of 0 for mpf_base will result in continued parsing of the MP-table. >>> >>> Reported-by: Tomeu Vizoso >>

Re: [PATCH v10 20/38] x86, mpparse: Use memremap to map the mpf and mpc data

On 3 November 2017 at 16:31, Tom Lendacky <thomas.lenda...@amd.com> wrote: > On 11/3/2017 10:12 AM, Tomeu Vizoso wrote: >> >> On 17 July 2017 at 23:10, Tom Lendacky <thomas.lenda...@amd.com> wrote: >>> >>> The SMP MP-table is built by UEFI

Re: [PATCH v10 20/38] x86, mpparse: Use memremap to map the mpf and mpc data

On 3 November 2017 at 16:31, Tom Lendacky wrote: > On 11/3/2017 10:12 AM, Tomeu Vizoso wrote: >> >> On 17 July 2017 at 23:10, Tom Lendacky wrote: >>> >>> The SMP MP-table is built by UEFI and placed in memory in a decrypted >>> state. These tables

Re: [PATCH v10 20/38] x86, mpparse: Use memremap to map the mpf and mpc data

On 17 July 2017 at 23:10, Tom Lendacky wrote: > The SMP MP-table is built by UEFI and placed in memory in a decrypted > state. These tables are accessed using a mix of early_memremap(), > early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses > to use

Re: [PATCH v10 20/38] x86, mpparse: Use memremap to map the mpf and mpc data

On 17 July 2017 at 23:10, Tom Lendacky wrote: > The SMP MP-table is built by UEFI and placed in memory in a decrypted > state. These tables are accessed using a mix of early_memremap(), > early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses > to use

Re: [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts

On 29 March 2017 at 23:34, J. Bruce Fields <bfie...@redhat.com> wrote: > On Wed, Mar 29, 2017 at 05:27:23PM +0200, Tomeu Vizoso wrote: >> Labelling of files in a NFSv4.2 currently fails with ENOTSUPP because >> the mount point doesn't have SBLABEL_MNT. >> >>

  1   2   3   4   5   6   7   8   9   10   >