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
---
drivers/gpu/drm/vc4/vc4_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dr
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
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
---
drivers/gpu/drm/vc4/vc4_
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
---
drivers/gpu/drm/vc4/vc4_drv.h | 1 +
drivers/gpu/drm/vc4/vc4_gem.c | 30
On Wed, Apr 18, 2018 at 12:40 PM, Stefan Schake 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")
> Signed-off-by: Stefan Schake
>
On Tue, May 1, 2018 at 1:59 AM, Eric Anholt 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 the new v3d drive
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 Boot). Strangly i
> couldn't
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
> pixman that seems to be f
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
> ValidateDisplay, so refa
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
>> pun
gt; Signed-off-by: Eric Anholt
> Cc: Stefan Schake
> ---
> 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_regs.h
> index b9749cb240
We need to access the channel for configuring our CTM hardware.
Signed-off-by: Stefan Schake
---
v3: New in the series
drivers/gpu/drm/vc4/vc4_crtc.c | 33 -
drivers/gpu/drm/vc4/vc4_drv.h | 33 +
2 files changed, 33 insertions
From: Eric Anholt
At least the RGBA expand field we should have been setting, because we
aren't expanding correctly for 565 -> . Other registers are ones
that may be interesting for various projects that have been discussed.
Signed-off-by: Eric Anholt
Cc: Stefan Schake
Acked-by
r 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/dr
scalars that we can't approximate without integer bits.
Signed-off-by: Stefan Schake
---
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 files changed
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
---
v2: Use drm_color_lut_size for LUT length
v3: Disable gamma lut when gamma_lut is NULL
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
---
drivers/gpu/drm/tegra/hub.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletion
scalars that we can't approximate without integer bits.
Signed-off-by: Stefan Schake
Signed-off-by: Eric Anholt
---
Eric, I removed your r-b since there were a bunch more changes.
v4: Handle CTM disabling in check
Don't use drm_atomic_get_private_obj_state in commit
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
---
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_hvs.c b/drivers/gpu/dr
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
---
drivers/gpu/drm/vc4/vc4_plane.c | 14 +-
drivers/gpu
On Sat, Apr 21, 2018 at 1:45 AM, Eric Anholt wrote:
> Stefan Schake 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 allows us to support the generic DRM plane alph
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
---
v2: Non-opaque plane alpha can trigger the background blending issue
://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
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
---
drivers/gpu/drm/vc4/vc4_gem.c | 38 +++---
include/uapi/drm/vc4_drm.h| 13
Allow userland to specify a syncobj that is waited on before a render job
starts processing.
Signed-off-by: Stefan Schake
---
drivers/gpu/drm/vc4/vc4_drv.h | 2 ++
drivers/gpu/drm/vc4/vc4_gem.c | 33 +++--
include/uapi/drm/vc4_drm.h| 9 +
3 files
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
---
drivers/gpu/drm/vc4/vc4_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dr
This allows runtime detection of syncobj submission support.
Signed-off-by: Stefan Schake
---
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/drm/vc4/vc4_drv.c
index 806c8004b793
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 adds some extra logic in the validate f
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 usage flag for framebuffers
On Tue, Mar 6, 2018 at 8:35 PM, Eric Anholt wrote:
> Stefan Schake writes:
>
>> 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
>> ---
>
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 beyond that commit. But I did hav
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
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
---
drivers/gpu/drm/vc4/vc4_plane.c | 3 ++-
drivers/gpu/drm/vc4/vc4_regs.h | 1 +
2 files
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 S
We need to reference it from the CRTC to make a decision for enabling
background color fill.
Signed-off-by: Stefan Schake
---
drivers/gpu/drm/vc4/vc4_drv.h | 60 +
drivers/gpu/drm/vc4/vc4_plane.c | 60 -
2 files
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
---
drivers/gpu/drm/vc4/vc4_crtc.c | 25 +
1
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 [2].
>
> 2. Heuristic for triggering t
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
---
drivers/gpu/drm/vc4/vc4_crtc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu
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
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
---
drivers/gpu/drm/vc4/vc4_crtc.c | 24 +---
1 file changed, 13
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
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:
> external/libdrm/android/g
They were set for the static library but not the shared variant.
Cc: John Stultz
Signed-off-by: Stefan Schake
---
Android.mk | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Android.mk b/Android.mk
index 8611c5e..1b77c53 100644
--- a/Android.mk
+++ b/Android.mk
@@ -53,7
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 that it only did for the st
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 android-arm64) missing libpciacc
On Tue, Mar 20, 2018 at 2:49 AM, John Stultz wrote:
> On Tue, Mar 20, 2018 at 6:55 AM, Stefan Schake wrote:
>> Hey John,
>>
>> On Wed, Mar 14, 2018 at 5:47 PM, John Stultz wrote:
>>> When building AOSP after updating libdrm project to the
>>> freedesktop
From: Eric Anholt
At least the RGBA expand field we should have been setting, because we
aren't expanding correctly for 565 -> . Other registers are ones
that may be interesting for various projects that have been discussed.
Signed-off-by: Eric Anholt
Cc: Stefan Schake
---
v2: Ne
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
---
v2: No change
drivers/gpu/drm/vc4/vc4_crtc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/vc4
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
---
v2: Use drm_color_lut_size for LUT length
drivers/gpu/drm/vc4/vc4_crtc.c | 24
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
dware. 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 a
Hey Daniel,
On Sun, Mar 25, 2018 at 10:01 AM, Daniel Stone wrote:
> Hi Stefan,
>
> On 25 March 2018 at 02:52, Stefan Schake wrote:
>> +static int vc4_crtc_get_ctm_fifo(struct vc4_dev *vc4)
>> +{
>> + return VC4_GET_FIE
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 extra protocols for
>> Wayland l
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
Hey Robert,
On Thu, Feb 22, 2018 at 11:04 AM, Robert Foss 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 specifies for composition. drm_hw
Hey Eric,
On Thu, Feb 22, 2018 at 9:47 PM, Eric Anholt wrote:
> Stefan Schake writes:
>
>> Android assumes an implicit black background layer is always present
>> behind all layers it specifies for composition. drm_hwcomposer currently
>> punts responsibility for this to
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
---
Test program is available at https://github.com
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/
So I guess for now this can b
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 primary plane? Or does the driv
On Fri, Mar 2, 2018 at 4:21 PM, Ville Syrjälä
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ä
>> wrote:
>> > On Fri, Mar 02, 2018 at 04:39:22PM +0200, Ville Syrjälä w
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
---
drivers/gpu/drm/vc4/vc4_drv.h | 6 ++
drivers/gpu/dr
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
---
drivers/gpu/drm/vc4/vc4_plane.c | 3 ++-
drivers/gpu/drm/vc4/vc4_regs.h | 1 +
2 files changed, 3 insertions(+), 1 deletion
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
---
drivers/gpu/drm/vc4/vc4_crtc.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm
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
On Mon, Mar 5, 2018 at 10:15 PM, Eric Anholt wrote:
> Stefan Schake writes:
>
>> 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 th
vc4_overflow_mem_work.
Link: https://github.com/anholt/linux/issues/114
Signed-off-by: Stefan Schake
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/vc4/vc4_irq.c b/drivers/g
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
---
drivers
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
On Tue, Nov 14, 2017 at 1:18 AM, Eric Anholt wrote:
> Stefan Schake writes:
>
>> 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
On Tue, Nov 14, 2017 at 8:44 PM, Eric Anholt wrote:
> Stefan Schake writes:
>
>> On Tue, Nov 14, 2017 at 1:18 AM, Eric Anholt wrote:
>>> Stefan Schake writes:
>>>
>>>> The overflow mem work callback vc4_overflow_mem_work reenables its
>>>&g
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
---
drivers/gpu/drm/vc4/vc4
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
>> multi_v7_defconfig:
>>
>> [7.962699
On Fri, Dec 8, 2017 at 11:44 PM, Stefan Wahren wrote:
> Hi,
>
> the commit 253696ccd613 ("drm/vc4: Account for interrupts in flight")
> triggers a warning during boot of Raspberry Pi 2 with multi_v7_defconfig:
>
> [7.962699] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi
> mapping o
we
know there was a previous disable invocation during suspend.
Fixes: 253696ccd613 ("drm/vc4: Account for interrupts in flight")
Signed-off-by: Stefan Schake
---
I tested replacing the enable/disable dance with just synchronize_irq,
but that only made the original kernel OOPS
74 matches
Mail list logo
