Re: [PATCH 2/2] drm/vc4: Ensure interrupts are disabled

On Tue, Nov 14, 2017 at 8:44 PM, Eric Anholt <e...@anholt.net> wrote: > Stefan Schake <stsch...@gmail.com> writes: > >> On Tue, Nov 14, 2017 at 1:18 AM, Eric Anholt <e...@anholt.net> wrote: >>> Stefan Schake <stsch...@gmail.com> writes: >>> >

Re: [PATCH 2/2] drm/vc4: Ensure interrupts are disabled

On Tue, Nov 14, 2017 at 1:18 AM, Eric Anholt <e...@anholt.net> wrote: > Stefan Schake <stsch...@gmail.com> writes: > >> The overflow mem work callback vc4_overflow_mem_work reenables its >> associated interrupt upon completion. To ensure all interrupts are d

[PATCH 2/2] drm/vc4: Ensure interrupts are disabled

The overflow mem work callback vc4_overflow_mem_work reenables its associated interrupt upon completion. To ensure all interrupts are disabled when we return from vc4_irq_uninstall, we need to disable it again if cancel_work_sync indicated pending work. Signed-off-by: Stefan Schake <st

[PATCH 0/2] drm/vc4: Correctly uninstall interrupts

dereference but turned out to be unrelated. Tested with a Raspberry Pi CM 3 that was previously stuck in a boot loop due to the issue. With the patch applied, the NULL dereference was no longer observed through numerous resets. Stefan Schake (2): drm/vc4: Account for interrupts in flight drm/vc4

[PATCH 1/2] drm/vc4: Account for interrupts in flight

vc4_overflow_mem_work. Link: https://github.com/anholt/linux/issues/114 Signed-off-by: Stefan Schake <stsch...@gmail.com> Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.") --- drivers/gpu/drm/vc4/vc4_irq.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm

[PATCH] drm/vc4: Release fence after signalling

We were never releasing the initial fence reference that is obtained through dma_fence_init. Link: https://github.com/anholt/linux/issues/122 Fixes: cdec4d361323 ("drm/vc4: Expose dma-buf fences for V3D rendering.") Signed-off-by: Stefan Schake <stsch...@gmail.com> --- dri

Re: drm: vc4: WARNING: CPU: 2 PID: 172 at kernel/irq/chip.c:244 __irq_startup+0x9c/0xa8

On Sat, Dec 9, 2017 at 1:34 PM, Marc Zyngier wrote: > On Fri, 08 Dec 2017 22:44:27 +, > Stefan Wahren wrote: >> >> Hi, >> >> the commit 253696ccd613 ("drm/vc4: Account for interrupts in >> flight") triggers a warning during boot of Raspberry Pi 2 with >>

Re: [PATCH] drm/vc4: plane: Expand the lower bits using the LSB

On Tue, Apr 24, 2018 at 9:48 AM, Maxime Ripard wrote: > The vc4 HVS uses an internal RGB888 representation of the frames, and will > by default expand formats using a lower depth using zeros. > > This causes an issue when we try to use other compositing software such as

Re: [BUG] drm/vc4: vblank wait timed out

On Sat, May 5, 2018 at 1:47 PM, Stefan Wahren wrote: > Hi, > > after submit of the latest bcm2835 clock fixes, i thought this issue has been > fixed. But i've seen this issue with current mainline 4.17-rc3 > (bcm2835_defconfig) on Raspberry Pi 1 B (using U-Boot TFTP

Re: [PATCH hwc] drm_hwcomposer: Support assigning planes in ValidateDisplay

Hey Rob, On Fri, May 18, 2018 at 12:08 AM, Rob Herring wrote: > In order to assign planes to layers in ValidateDisplay, testing > compositing with a DRM atomic modeset test is needed as PresentDisplay > is too late. This means most of PresentDisplay needs to be run from >

Re: [PATCH] drm/vc4: Add a pad field to align drm_vc4_submit_cl to 64 bits.

On Tue, May 1, 2018 at 1:59 AM, Eric Anholt <e...@anholt.net> wrote: > I had originally asked Stefan Schake to drop the pad field from the > syncobj changes that just landed, because I couldn't come up with a > reason to align to 64 bits. > > Talking with Dave Airlie about

Re: [PATCH] drm/tegra: hub: Use state directly

On Wed, Apr 18, 2018 at 12:40 PM, Stefan Schake <stsch...@gmail.com> wrote: > Using drm_atomic_get_private_obj_state after state has been swapped > will return old state. > > Fixes: 0281c4149021 ("drm/tegra: hub: Use private object for global state") > Sign

[PATCH] drm/vc4: Move IRQ enable to PM path

we know there was a previous disable invocation during suspend. Fixes: 253696ccd613 ("drm/vc4: Account for interrupts in flight") Signed-off-by: Stefan Schake <stsch...@gmail.com> --- I tested replacing the enable/disable dance with just synchronize_irq, but that only made the o

[RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available

platforms (e.g. VC4) a background color fill has a cycle cost for the hardware composer and is not enabled by default. Instead, userland can request a background color through a CRTC property. Use this property to specify the implicit black background Android expects. Signed-off-by: Stefan Schake <st

Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available

Hey Robert, On Thu, Feb 22, 2018 at 11:04 AM, Robert Foss <robert.f...@collabora.com> wrote: > Hey Stefan, > > On 02/22/2018 04:54 AM, Stefan Schake wrote: >> >> Android assumes an implicit black background layer is always present >> behind all layers it specifie

Re: [PATCH v3 1/8] drm/blend: Add a generic alpha property

On Fri, Feb 16, 2018 at 7:20 PM, Ville Syrjälä wrote: > On Fri, Feb 16, 2018 at 06:39:29PM +0100, Maxime Ripard wrote: >> Some drivers duplicate the logic to create a property to store a per-plane >> alpha. >> >> This is especially useful if we ever want to support

Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available

Hey Eric, On Thu, Feb 22, 2018 at 9:47 PM, Eric Anholt <e...@anholt.net> wrote: > Stefan Schake <stsch...@gmail.com> writes: > >> Android assumes an implicit black background layer is always present >> behind all layers it specifies for composition. drm

Re: drm_hwcomposer: Question about buffer importer

Hey Andrii, On Tue, Mar 6, 2018 at 4:48 PM, Andrii Chepurnyi wrote: > > Could you please suggest me how to overcome that situation with buffers > registration/deregistration? I think drm_hwcomposer would be the wrong place to do any sort of caching. There is a Gralloc

Re: [PATCH 1/3] drm/vc4: Set premultiplied for alpha formats

On Tue, Mar 6, 2018 at 8:35 PM, Eric Anholt <e...@anholt.net> wrote: > Stefan Schake <stsch...@gmail.com> writes: > >> Alpha formats in DRM are assumed to be premultiplied, so we should be >> setting the PREMULT bit in the plane configuration for HVS. >> &g

Re: [PATCH v3 1/8] drm/blend: Add a generic alpha property

Hey, On Wed, Feb 21, 2018 at 2:04 PM, Maxime Ripard wrote: > > What is the behaviour of the tegra engine when it has both a > pixel-alpha and a plane-alpha? > > Atmel at least will drop one (but I'm not sure which one anymore). Sorry, I have no more on the Tegra

Re: [PATCH hwc v1] [RFC] drm_hwcomposer: Flatten composition using writeback connector

Hey Alexandru, On Tue, Mar 13, 2018 at 5:21 PM, Alexandru Gheorghe wrote: > This patchset tries to add support for using writeback connector to > flatten a scene when it doesn't change for a while. This idea had > been floated around on IRC here [1] and here

[PATCH v2 3/4] drm/vc4: Move plane state to header

We need to reference it from the CRTC to make a decision for enabling background color fill. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/vc4/vc4_drv.h | 60 + drivers/gpu/drm/vc4/vc4_plane.

[PATCH v2 4/4] drm/vc4: Enable background color fill when necessary

Using the hint from the plane state, we turn on the background color to avoid display corruption from planes blending with the background. Changes from v1: - Use needs_bg_fill from plane state Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/vc4/vc4_crtc.

[PATCH v2 0/4] drm/vc4: Improve alpha format plane support

the has_alpha confusion and moves needs_bg_fill into the plane state. This unfortunately necessitated moving the plane state to a header where it can be referenced from vc4_crtc. Stefan Schake (4): drm/vc4: Set premultiplied for alpha formats drm/vc4: Check if plane requires background fill

[PATCH v2 1/4] drm/vc4: Set premultiplied for alpha formats

Alpha formats in DRM are assumed to be premultiplied, so we should be setting the PREMULT bit in the plane configuration for HVS. Changes from v1: - Use correct has_alpha Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/vc4/vc4_plane.c | 3 ++- drivers/gpu/d

[PATCH v2 2/4] drm/vc4: Check if plane requires background fill

Considering a single plane only, we have to enable background color when the plane has an alpha format and could be blending from the background or when it doesn't cover the entire screen. Changes from v1: - Drop unrelated change - Move needs_bg_fill to plane state Signed-off-by: Stefan Schake

Re: [PATCH] drm/vc4: Add some missing HVS register definitions.

cussed. > > Signed-off-by: Eric Anholt <e...@anholt.net> > Cc: Stefan Schake <stsch...@gmail.com> > --- > drivers/gpu/drm/vc4/vc4_regs.h | 96 > ++ > 1 file changed, 96 insertions(+) > > diff --git a/drivers/gpu/dr

[PATCH v3 0/4] drm/vc4: Atomic color management support

for the DRM property. Eric Anholt (1): drm/vc4: Add some missing HVS register definitions. Stefan Schake (3): drm/vc4: Expose gamma as atomic property drm/vc4: Move CRTC state to header drm/vc4: Add CTM support drivers/gpu/drm/vc4/vc4_crtc.c | 74 -- drivers/gpu/drm/vc4

[PATCH v3 4/4] drm/vc4: Add CTM support

with scalars that we can't approximate without integer bits. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- v3: New in the series drivers/gpu/drm/vc4/vc4_crtc.c | 6 +- drivers/gpu/drm/vc4/vc4_drv.h | 3 + drivers/gpu/drm/vc4/vc4_kms.c | 167 - 3

[PATCH v3 3/4] drm/vc4: Move CRTC state to header

We need to access the channel for configuring our CTM hardware. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- v3: New in the series drivers/gpu/drm/vc4/vc4_crtc.c | 33 - drivers/gpu/drm/vc4/vc4_drv.h | 33 + 2

[PATCH v3 1/4] drm/vc4: Add some missing HVS register definitions.

holt.net> Cc: Stefan Schake <stsch...@gmail.com> Acked-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/vc4/vc4_regs.h | 96 ++ 1 file changed, 96 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_re

[PATCH v3 2/4] drm/vc4: Expose gamma as atomic property

We are an atomic driver so the gamma LUT should also be exposed as a CRTC property through the DRM atomic color management. This will also take care of the legacy path for us. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- v2: Use drm_color_lut_size for LUT length v3: Disable gam

[PATCH] drm/tegra: hub: Use state directly

Using drm_atomic_get_private_obj_state after state has been swapped will return old state. Fixes: 0281c4149021 ("drm/tegra: hub: Use private object for global state") Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/tegra/hub.c | 5 ++--- 1 file changed, 2

[PATCH] drm/vc4: Add support for plane alpha

The HVS supports mixing fixed alpha with per-pixel alpha or setting a fixed plane alpha in case there is no per-pixel information. This allows us to support the generic DRM plane alpha property. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/vc4/vc4_plane.

Re: [PATCH] drm/vc4: Add support for plane alpha

On Sat, Apr 21, 2018 at 1:45 AM, Eric Anholt <e...@anholt.net> wrote: > Stefan Schake <stsch...@gmail.com> writes: > >> The HVS supports mixing fixed alpha with per-pixel alpha or >> setting a fixed plane alpha in case there is no per-pixel information. >> This

[PATCH v2] drm/vc4: Add support for plane alpha

The HVS supports mixing fixed alpha with per-pixel alpha or setting a fixed plane alpha in case there is no per-pixel information. This allows us to support the generic DRM plane alpha property. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- v2: Non-opaque plane alpha can t

[PATCH 3/4] drm/vc4: Export fence through syncobj

Allow specifying a syncobj on render job submission where we store the fence for the job. This gives userland flexible access to the fence. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/vc4/vc4_gem.c | 38 +++--- include/uapi/drm/vc4

[PATCH 1/4] drm/vc4: Enable syncobj support

This doesn't require any additional functionality from the driver but is a prerequisite to userland calling the syncobj ioctls. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/vc4/vc4_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drive

[PATCH 4/4] drm/vc4: Add parameter for syncobj support

This allows runtime detection of syncobj submission support. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/vc4/vc4_drv.c | 1 + include/uapi/drm/vc4_drm.h| 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/d

[PATCH 0/4] drm/vc4: Syncobj import export

://patchwork.freedesktop.org/series/42081/ Stefan Schake (4): drm/vc4: Enable syncobj support drm/vc4: Syncobj import support drm/vc4: Export fence through syncobj drm/vc4: Add parameter for syncobj support drivers/gpu/drm/vc4/vc4_drv.c | 4 ++- drivers/gpu/drm/vc4/vc4_drv.h | 2 ++ drivers/gpu/drm

[PATCH 2/4] drm/vc4: Syncobj import support

Allow userland to specify a syncobj that is waited on before a render job starts processing. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/vc4/vc4_drv.h | 2 ++ drivers/gpu/drm/vc4/vc4_gem.c | 33 +++-- include/uapi/drm/vc4_drm.h

[PATCH v4 1/2] drm/vc4: Add CTM support

with scalars that we can't approximate without integer bits. Signed-off-by: Stefan Schake <stsch...@gmail.com> Signed-off-by: Eric Anholt <e...@anholt.net> --- Eric, I removed your r-b since there were a bunch more changes. v4: Handle CTM disabling in check

[PATCH v4 2/2] drm/vc4: Add CTM registers to debugfs

Now that we set the OLED* registers to do CTM, it's helpful to have them in the register dump. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- v4: new in the series. drivers/gpu/drm/vc4/vc4_hvs.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_h

[PATCH v2 1/3] drm/vc4: Syncobj import support

Allow userland to specify a syncobj that is waited on before a render job starts processing. v2: Use 0 as invalid syncobj to drop flag (Eric) Drop extra newline (Eric) Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/vc4/vc4_drv.h | 1 + drivers/gpu/drm/vc4/vc4

[PATCH v2 3/3] drm/vc4: Enable syncobj support

This doesn't require any additional functionality from the driver but is a prerequisite to userland calling the syncobj ioctls. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/vc4/vc4_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drive

[PATCH v2 2/3] drm/vc4: Export fence through syncobj

Allow specifying a syncobj on render job submission where we store the fence for the job. This gives userland flexible access to the fence. v2: Use 0 as invalid syncobj to drop flag (Eric) Don't reintroduce the padding (Eric) Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drive

[PATCH v2 0/3] drm/vc4: Syncobj import export

fence fd support in Mesa. Userspace implementation is under review and available here: https://patchwork.freedesktop.org/series/42081/ Stefan Schake (3): drm/vc4: Syncobj import support drm/vc4: Export fence through syncobj drm/vc4: Enable syncobj support drivers/gpu/drm/vc4/vc4_drv.c | 3

Re: [RFC][PATCH 2/2] drm_hwcomposer: Fall back to client compositon if the gl precompostior fails

On Tue, Apr 24, 2018 at 10:09 AM, Alexandru-Cosmin Gheorghe wrote: > On Mon, Apr 23, 2018 at 05:06:44PM -0700, John Stultz wrote: >> If the gl precompositor isn't being used, we cannot accept >> every layer as a device composited layer. >> >> Thus this patch

[PATCH v2 1/4] drm/vc4: Add some missing HVS register definitions.

holt.net> Cc: Stefan Schake <stsch...@gmail.com> --- v2: New in the series. Included here to keep kbuild robot happy and give the full picture. drivers/gpu/drm/vc4/vc4_regs.h | 96 ++ 1 file changed, 96 insertions(+) diff --git a/drivers/gpu/drm/vc4

[PATCH v2 4/4] drm/vc4: Restrict active CTM to one CRTC

We only have one hardware block to do the CTM and need to reject attempts to enable it for multiple CRTCs simultaneously. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- v2: No change drivers/gpu/drm/vc4/vc4_crtc.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/d

[PATCH v2 1/3] drm/vc4: Expose gamma as atomic property

We are an atomic driver so the gamma LUT should also be exposed as a CRTC property through the DRM atomic color management. This will also take care of the legacy path for us. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- v2: Use drm_color_lut_size for LUT length drivers/gpu/d

[PATCH v2 3/4] drm/vc4: Add color transformation matrix (CTM) support

The hardware supports a CTM with S0.9 values. We therefore only allow a value of 1.0 or fractional only and reject all others with integer parts. This restriction is mostly inconsequential in practice since commonly used transformation matrices have all scalars <= 1.0. Signed-off-by: Ste

[PATCH v2 0/4] drm/vc4: Atomic color management support

. The latter seems good enough for the various color corrections Android offers. Eric Anholt (1): drm/vc4: Add some missing HVS register definitions. Stefan Schake (3): drm/vc4: Expose gamma as atomic property drm/vc4: Add color transformation matrix (CTM) support drm/vc4: Restrict active

Re: [PATCH v2 4/4] drm/vc4: Restrict active CTM to one CRTC

Hey Daniel, On Sun, Mar 25, 2018 at 10:01 AM, Daniel Stone <dan...@fooishbar.org> wrote: > Hi Stefan, > > On 25 March 2018 at 02:52, Stefan Schake <stsch...@gmail.com> wrote: >> +static int vc4_crtc_get_ctm_fifo(struct vc4_dev *vc4) >> +{ >> + return

[PATCH 0/3] drm/vc4: Atomic color management support

in hardware. The latter still seem good enough for the various color corrections Android offers. Stefan Schake (3): drm/vc4: Expose gamma as atomic property drm/vc4: Add color transformation matrix (CTM) support drm/vc4: Restrict active CTM to one CRTC drivers/gpu/drm/vc4/vc4_crtc.c | 124

[PATCH 1/3] drm/vc4: Expose gamma as atomic property

We are an atomic driver so the gamma LUT should also be exposed as a CRTC property through the DRM atomic color management. This will also take care of the legacy path for us. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/vc4/vc4_crtc.c | 24 +

[PATCH 2/3] drm/vc4: Add color transformation matrix (CTM) support

The hardware supports a CTM with S0.9 values. We therefore only allow a value of 1.0 or fractional only and reject all others with integer parts. This restriction is mostly inconsequential in practice since commonly used transformation matrices have all scalars <= 1.0. Signed-off-by: Ste

[PATCH 3/3] drm/vc4: Restrict active CTM to one CRTC

We only have one hardware block to do the CTM and need to reject attempts to enable it for multiple CRTCs simultaneously. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/vc4/vc4_crtc.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/d

[PATCH libdrm] android: Add missing include exports

They were set for the static library but not the shared variant. Cc: John Stultz <john.stu...@linaro.org> Signed-off-by: Stefan Schake <stsch...@gmail.com> --- Android.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Android.mk b/Android.mk index 8611c5e..1b

Re: [RFC][PATCH] drm_hwcomposer: Rework platformdrmgeneric.cpp to use libdrm's gralloc handle

Hey John, On Fri, Mar 16, 2018 at 10:48 PM, John Stultz wrote: > LOCAL_C_INCLUDES := \ > - external/drm_gralloc \ > + external/libdrm/android \ > system/core/libsync This shouldn't be necessary if libdrm correctly exports its headers, but it seems

Re: [RFC][PATCH] libdrm: gralloc_handle.h: Fix build issue with Android

Hey John, On Fri, Mar 16, 2018 at 10:48 PM, John Stultz wrote: > In trying to integrate the new gralloc_handle.h with the > drm_hwcomposer, I started seeing the following compilation > errors: > > In file included from external/drm_hwcomposer/platformdrmgeneric.cpp:28: >

Re: [PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86/x86_64

Hey John, On Wed, Mar 14, 2018 at 5:47 PM, John Stultz wrote: > When building AOSP after updating libdrm project to the > freedesktop/master branch, I've seen the following build errors: > > external/libdrm/intel/Android.mk: error: libdrm_intel > (SHARED_LIBRARIES

Re: [PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86/x86_64

On Tue, Mar 20, 2018 at 2:49 AM, John Stultz <john.stu...@linaro.org> wrote: > On Tue, Mar 20, 2018 at 6:55 AM, Stefan Schake <stsch...@gmail.com> wrote: >> Hey John, >> >> On Wed, Mar 14, 2018 at 5:47 PM, John Stultz <john.stu...@linaro.org> wrote: >&

Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available

Hey Rob, On Wed, Feb 28, 2018 at 11:53 AM, Robert Foss wrote: > Hey, > > Stefan: Are you looking at an entirely kernel side fix now, or are you > pushing this series forward? I've sent out a kernel side fix for this: https://patchwork.freedesktop.org/patch/207667/

[PATCH] drm/vc4: Ignore alpha on primary plane

We allow alpha formats on the primary plane but a partially transparent framebuffer will cause a corrupted display. With this change black pixels are output instead, in line with the behavior for other DRM drivers. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- Test program is ava

Re: [PATCH] drm/vc4: Ignore alpha on primary plane

Hey Ville, On Fri, Mar 2, 2018 at 3:43 PM, Ville Syrjälä wrote: > On Fri, Mar 02, 2018 at 04:39:22PM +0200, Ville Syrjälä wrote: >> If you want the plane to always be opaque you shouldn't expose any >> formats with alpha. >> >> Also what happens if one disables the

Re: [PATCH] drm/vc4: Ignore alpha on primary plane

On Fri, Mar 2, 2018 at 4:21 PM, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > On Fri, Mar 02, 2018 at 04:06:58PM +0100, Stefan Schake wrote: >> Hey Ville, >> >> On Fri, Mar 2, 2018 at 3:43 PM, Ville Syrjälä >> <ville.syrj...@linux.intel.com> wrote:

Re: [PATCH] drm/vc4: Ignore alpha on primary plane

On Mon, Mar 5, 2018 at 10:15 PM, Eric Anholt <e...@anholt.net> wrote: > Stefan Schake <stsch...@gmail.com> writes: > >> We allow alpha formats on the primary plane but a partially transparent >> framebuffer will cause a corrupted display. With this change blac

[PATCH 3/3] drm/vc4: Enable background color fill when necessary

Using the hint from the plane state, we turn on the background color to avoid display corruption from planes blending with the background. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/vc4/vc4_crtc.c | 22 ++ 1 file changed, 22 insertions(+)

[PATCH 2/3] drm/vc4: Check if plane requires background fill

Considering a single plane only, we have to enable background color when the plane has an alpha format and could be blending from the background or when it doesn't cover the entire screen. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/vc4/vc4_drv.h | 6 ++ d

[PATCH 1/3] drm/vc4: Set premultiplied for alpha formats

Alpha formats in DRM are assumed to be premultiplied, so we should be setting the PREMULT bit in the plane configuration for HVS. Signed-off-by: Stefan Schake <stsch...@gmail.com> --- drivers/gpu/drm/vc4/vc4_plane.c | 3 ++- drivers/gpu/drm/vc4/vc4_regs.h | 1 + 2 files changed, 3 inse

[PATCH 0/3] drm/vc4: Improve alpha format plane support

background color fill. This series follows the changes suggested by Eric Anholt in a previous patch discussion: https://patchwork.freedesktop.org/patch/207667/ A simple test program for the display corruption issue is available: https://github.com/stschake/vc4-alpha-test Stefan Schake (3): drm

Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available

Hey Maarten, On Fri, Jun 29, 2018 at 12:05 PM, Maarten Lankhorst wrote: > Op 22-02-18 om 04:54 schreef Stefan Schake: >> Android assumes an implicit black background layer is always present >> behind all layers it specifies for composition. drm_hwcomposer currently >>