On 18/01/19 00:04, Rob Herring wrote:
> Mesa/libdrm already has lots of code to open the correct devices and
> not care about minor numbers. What's the problem here?
Well, maybe the problem is that I don't know how to do this =).
So, if we have multiple DRM devices, how does one manage those?
It
On Thu, 2019-01-17 at 11:09 +, Russell King - ARM Linux admin
wrote:
> On Tue, Dec 18, 2018 at 04:37:40PM +0100, Lubomir Rintel wrote:
> > It needs to be enabled (at least on MMP2) in order for the register
> > writes to LCDC to work.
>
> Dove also has an AXI clock input to the LCDC, but it is
Sandy, Heiko,
On Thu, 30 Aug 2018, Heiko Stuebner wrote:
> +++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c
> @@ -0,0 +1,173 @@
> +//SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author:
> + * Sandy Huang
> + *
> + * This software is licen
In commit dd220a00e8bd ("drm/radeon/kms: add support for streamout v7")
case statements were added without a terminating break statement. This
commit adds the missing break. This was discovered during a compilation
with W=1.
This commit removes the following warning:
drivers/gpu/drm/radeon/ever
On Wed, 2019-01-09 at 17:54 +0100, Matthias Brugger wrote:
>
> On 04/01/2019 08:03, chunhui dai wrote:
> > fix the rate and divder of hdmi phy for MT2701.
>
> This is a bug? Then we would need a fixes tag.
yes, we would add the tag in V2.
> Otherwise you should explain in the commit, that you n
On Fri, Jan 11, 2019 at 8:31 PM Souptick Joarder wrote:
>
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be generalized b
On Thu, 17 Jan 2019, Andrew F. Davis wrote:
> On 1/16/19 4:54 PM, Liam Mark wrote:
> > On Wed, 16 Jan 2019, Andrew F. Davis wrote:
> >
> >> On 1/16/19 9:19 AM, Brian Starkey wrote:
> >>> Hi :-)
> >>>
> >>> On Tue, Jan 15, 2019 at 12:40:16PM -0600, Andrew F. Davis wrote:
> On 1/15/19 12:38 PM
On Thu, 17 Jan 2019, Andrew F. Davis wrote:
> On 1/16/19 4:48 PM, Liam Mark wrote:
> > On Wed, 16 Jan 2019, Andrew F. Davis wrote:
> >
> >> On 1/15/19 1:05 PM, Laura Abbott wrote:
> >>> On 1/15/19 10:38 AM, Andrew F. Davis wrote:
> On 1/15/19 11:45 AM, Liam Mark wrote:
> > On Tue, 15 Jan
On 2019-01-16 17:45, Bartlomiej Zolnierkiewicz wrote:
> On 01/07/2019 11:35 AM, Peter Rosin wrote:
>> Right. So, here's an update...
>>
>> Again, it would probably be best if this went in before 5.0 is released.
>>
>> Changes since v1:
>> - rename from fbcon=center-logo option to fbcon=logo-pos:cen
On Fri, Dec 21, 2018 at 11:33:56AM +0100, Vincent Guittot wrote:
> From: Thara Gopinath
>
> This patch replaces jiffies based accounting for runtime_active_time
> and runtime_suspended_time with ktime base accounting. This makes the
> runtime debug counters inline with genpd and other pm subsytem
We have two *_CLASS_DEVICE kernel config options (LCD_CLASS_DEVICE
and BACKLIGHT_LCD_DEVICE) that do the same job.
The patch removes useless BACKLIGHT_LCD_SUPPORT option
and converts LCD_CLASS_DEVICE into a menu.
Signed-off-by: Alexander Shiyan
---
arch/unicore32/Kconfig| 1 -
drive
Rodrigo,
On Wed, 16 May 2018, Rodrigo Siqueira wrote:
All files added by this commit have inconsistent license information:
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -0,0 +1,35 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * This program is free software; you can redist
This patch removes dependencies on BACKLIGHT_CLASS_DEVICE for items
that are already placed under #if BACKLIGHT_CLASS_DEVICE.
Signed-off-by: Alexander Shiyan
---
drivers/video/backlight/Kconfig | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/driver
On Thu, 2019-01-10 at 16:28 +0800, CK Hu wrote:
> Hi, Chunhui:
>
> On Fri, 2019-01-04 at 15:03 +0800, chunhui dai wrote:
> > move the setting of fixed divider from enable/disable
> > to the function of setting rate.
>
> Please describe more about _WHY_ of this patch. Does it fix any bug, or
> enh
On Thu, 2019-01-17 at 10:55 +, Russell King - ARM Linux admin
wrote:
> On Tue, Dec 18, 2018 at 04:37:26PM +0100, Lubomir Rintel wrote:
> > here are patches that make the Armada DRM work on an OLPC XO-1.75.
> > They build on patches previously submitted by Russel King (included here for
> > comp
On Thu, Jan 17, 2019 at 10:30:01AM +0100, h...@lst.de wrote:
> On Wed, Jan 16, 2019 at 10:24:36AM -0700, Jason Gunthorpe wrote:
> > The fact is there is 0 industry interest in using RDMA on platforms
> > that can't do HW DMA cache coherency - the kernel syscalls required to
> > do the cache flushin
Hi,
this Patchset does not hang on Bananapi R2, but does not show anything on
FB-Console...seems anything is missing
https://github.com/frank-w/BPI-R2-4.14/tree/4.20-fbdev
dmesg | grep 'fb\|framebuffer'
[0.00] Linux version 4.20.0-rc7-bpi-r2-fbdev (frank@frank-N56VZ) (gcc
version 7.3.0
On 2019/1/3 6:36, Laura Abbott wrote:
On 12/24/18 12:19 AM, Qing Xia wrote:
Now, as Google's user guide, if userspace need clean ION buffer's
cache, they should call ioctl(fd, DMA_BUF_IOCTL_SYNC, sync). Then
we found that ion_dma_buf_begin_cpu_access/ion_dma_buf_end_cpu_access
will do ION buff
On 11.01.2019 16:18, Peter Rosin wrote:
> Hi!
>
> I'm not sure if I should have added the texas chips to the lvds_encoder_match
> list in the driver, right next to the thine,thc63lvdm83d entry, but ended
> up not doing that. That can always be added later, if needed...
>
> Changes since v3:
> - ret
On 15.01.2019 13:33, Neil Armstrong wrote:
> Add support for TMDS Clock > 3.4GHz for HDMI2.0 display modes.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 23 +++
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu
[SNIP]
Re-arming the timeout should probably have a much reduced value
when the job hasn't changed. E.g. something like a few ms.
>
> Now i got thinking about non hanged job in progress (job A) and let's
> say it's a long job , it just started executing but due to time out of
> another
Am Donnerstag, den 17.01.2019, 13:20 +0100 schrieb Daniel Vetter:
[...]
>
> > I don't think it is addressed here.
> >
> > Can anyone please explain to me what happens in more detail?
>
> My understanding (and this might be wrong, Russell, Andrzej, ... pls
> correct) is that the following sequenc
Hi Andrzej,
On 18/01/2019 10:13, Andrzej Hajda wrote:
> On 15.01.2019 13:33, Neil Armstrong wrote:
>> Add support for TMDS Clock > 3.4GHz for HDMI2.0 display modes.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_dw_hdmi.c | 23 +++
>> 1 file changed
On Fri, Jan 11, 2019 at 12:05:09PM -0600, Andrew F. Davis wrote:
> Hello all,
>
> This is a set of (hopefully) non-controversial cleanups for the ION
> framework and current set of heaps. These were found as I start to
> familiarize myself with the framework to help in whatever way I
> can in gett
On Fri, Jan 11, 2019 at 12:05:21PM -0600, Andrew F. Davis wrote:
> When enabled the helpers functions for creating carveout and chunk heaps
> should have declarations in the ION header.
Why? No one calls these from what I can tell.
Which makes me believe we should just delete the
drivers/staging
On Fri, Jan 18, 2019 at 10:37 AM Lucas Stach wrote:
>
> Am Donnerstag, den 17.01.2019, 13:20 +0100 schrieb Daniel Vetter:
> [...]
> >
> > > I don't think it is addressed here.
> > >
> > > Can anyone please explain to me what happens in more detail?
> >
> > My understanding (and this might be wrong
Hi Laurent,
On 11/01/19 05:51, Laurent Pinchart wrote:
> Hook up drm_bridge support in the omapdrm driver. Despite the recent
> extensive preparation work, this is a rather intrusive change, as the
> management of outputs needs to be adapted through the driver to handle
> both omap_dss_device and
Hi Guenter,
Le Thursday 17 Jan 2019 à 14:16:28 (-0800), Guenter Roeck a écrit :
> On Fri, Dec 21, 2018 at 11:33:56AM +0100, Vincent Guittot wrote:
> > From: Thara Gopinath
> >
> > This patch replaces jiffies based accounting for runtime_active_time
> > and runtime_suspended_time with ktime base
On Fri, 18 Jan 2019 at 11:42, Vincent Guittot
wrote:
>
> Hi Guenter,
>
> Le Thursday 17 Jan 2019 à 14:16:28 (-0800), Guenter Roeck a écrit :
> > On Fri, Dec 21, 2018 at 11:33:56AM +0100, Vincent Guittot wrote:
> > > From: Thara Gopinath
> > >
> > > This patch replaces jiffies based accounting for
On Thu, Jan 17, 2019 at 11:16 PM Guenter Roeck wrote:
>
> On Fri, Dec 21, 2018 at 11:33:56AM +0100, Vincent Guittot wrote:
> > From: Thara Gopinath
> >
> > This patch replaces jiffies based accounting for runtime_active_time
> > and runtime_suspended_time with ktime base accounting. This makes th
On Fri, Jan 18, 2019 at 11:53 AM Vincent Guittot
wrote:
>
> On Fri, 18 Jan 2019 at 11:42, Vincent Guittot
> wrote:
> >
> > Hi Guenter,
> >
> > Le Thursday 17 Jan 2019 à 14:16:28 (-0800), Guenter Roeck a écrit :
> > > On Fri, Dec 21, 2018 at 11:33:56AM +0100, Vincent Guittot wrote:
> > > > From: T
On Fri, Jan 18, 2019 at 11:03 AM Rafael J. Wysocki wrote:
>
> On Fri, Jan 18, 2019 at 10:37 AM Lucas Stach wrote:
> >
> > Am Donnerstag, den 17.01.2019, 13:20 +0100 schrieb Daniel Vetter:
> > [...]
> > >
> > > > I don't think it is addressed here.
> > > >
> > > > Can anyone please explain to me w
On Tue, Jan 8, 2019 at 10:22 AM Andrzej Hajda wrote:
> Of course it was tested on Exynos as this is HW I work on. Linus Walleij
> has also reported in this thread that device links have different issue
> - circular dependencies (last few emails in this lengthy thread). My
> response explains it i
On Fri, Jan 18, 2019 at 12:06 PM Daniel Vetter wrote:
>
> On Fri, Jan 18, 2019 at 11:03 AM Rafael J. Wysocki wrote:
> >
> > On Fri, Jan 18, 2019 at 10:37 AM Lucas Stach wrote:
> > >
> > > Am Donnerstag, den 17.01.2019, 13:20 +0100 schrieb Daniel Vetter:
> > > [...]
> > > >
> > > > > I don't thin
On Thu, Jan 17, 2019 at 04:59:49PM +0100, Daniel Vetter wrote:
> On Thu, Jan 17, 2019 at 3:54 PM Liviu Dudau wrote:
> >
> > On Thu, Jan 17, 2019 at 01:32:15PM +0100, Daniel Vetter wrote:
> > > On Thu, Jan 17, 2019 at 1:26 PM Liviu Dudau wrote:
> > > >
> > > > On Thu, Jan 17, 2019 at 12:52:16PM +0
On Fri, Jan 18, 2019 at 12:17 PM Rafael J. Wysocki wrote:
>
> On Fri, Jan 18, 2019 at 12:06 PM Daniel Vetter wrote:
> >
> > On Fri, Jan 18, 2019 at 11:03 AM Rafael J. Wysocki
> > wrote:
> > >
> > > On Fri, Jan 18, 2019 at 10:37 AM Lucas Stach
> > > wrote:
> > > >
> > > > Am Donnerstag, den 17
From: Frediano Ziglio
Instead of relaying on surface type use the actual placement.
This allow to have different placement for a single type of
surface.
Signed-off-by: Frediano Ziglio
[ kraxel: rebased, adapted to upstream changes ]
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_d
Drop pointless indirection, remove the mem_slots array and index
variables, drop dynamic allocation. Store memslots in qxl_device
instead.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h | 15 +
drivers/gpu/drm/qxl/qxl_kms.c | 72 +-
So, here is the all-in-one package of all my qxl changes. Some of these
changes have been on the list before, some not. Summary:
(1) A collection of misc ttm bugfixes and cleanups.
(2) Move some allocations from VRAM to PRIV domain, to reduce VRAM
memory pressure. Should help especially
slot_id_bits and slot_gen_bits can be read directly from qxlrom instead.
va_slot_mask is never used anywhere.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h | 3 ---
drivers/gpu/drm/qxl/qxl_kms.c | 10 ++
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/dr
Switch qxl over to the new generic fbdev emulation.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 7 ---
drivers/gpu/drm/qxl/qxl_drv.c | 2 ++
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qx
Generic fbdev emulation needs this. Also: We must keep track of the
number of mappings now, so we don't unmap early in case two users want a
kmap of the same bo. Add a sanity check to destroy callback to make
sure kmap/kunmap is balanced.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qx
Track which bo is used as primary surface. With that in place we don't
need the primary_created flag any more, we can just check the primary bo
pointer instead.
Also verify we don't already have a primary surface in
qxl_io_create_primary().
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/
The shadow bo is used as qxl surface, so allocate it as
QXL_GEM_DOMAIN_SURFACE. Should usually be allocated in
PRIV ttm domain then, so this reduces VRAM memory pressure.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
qdev->monitors_config->max_allowed is effectively set by the
qxl.num_heads module parameter, stored in the qxl_num_crtc variable.
Lets get rid of the indirection and use the variable qxl_num_crtc
directly. The kernel doesn't need to dereference pointers each time it
needs the value, and when readi
Not used, is always NULL.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 3 +--
drivers/gpu/drm/qxl/qxl_cmd.c| 14 ++
drivers/gpu/drm/qxl/qxl_object.c | 2 +-
3 files changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/dr
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h | 1 -
drivers/gpu/drm/qxl/qxl_cmd.c | 7 +++
drivers/gpu/drm/qxl/qxl_display.c | 2 +-
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 27e
Without that ttm offsets are not unique, they can refer to objects
in both VRAM and PRIV memory (aka main and surfaces slot).
One of those "why things didn't blow up without this" moments.
Probably offset conflicts are rare enough by pure luck.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/q
The qxl device supports only a single active framebuffer ("primary
surface" in spice terminology). In multihead configurations are handled
by defining rectangles within the primary surface for each head/crtc.
Userspace which uses the qxl ioctl interface (xorg qxl driver) is aware
of this limitati
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_dumb.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_dumb.c b/drivers/gpu/drm/qxl/qxl_dumb.c
index 272d19b677..bed6d06ee4 100644
--- a/drivers/gpu/drm/qxl/qxl_dumb.c
+++ b/drivers/gpu
The cursor must be set again after creating the primary surface.
Also drop the error message.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl
qxl surfaces (used for framebuffers and gem objects) can live in both
VRAM and PRIV ttm domains. Update placement setup to include both.
Put PRIV first in the list so it is preferred, so VRAM will have more
room for objects which must be allocated there.
Signed-off-by: Gerd Hoffmann
---
drivers
dumb buffers are used as qxl surfaces, so allocate them as
QXL_GEM_DOMAIN_SURFACE. Should usually be allocated in
PRIV ttm domain then, so this reduces VRAM memory pressure.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_dumb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 38c5a8b1df..7eabf4a9ed 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -30
Lovely diffstat, thanks to the new generic fbdev emulation.
drm/qxl/Makefile |2
drm/qxl/qxl_draw.c | 232
drm/qxl/qxl_drv.h | 21 ---
drm/qxl/qxl_fb.c | 300 -
Signed-off-by: Gerd Hoffmann
Add a helper functions to check video modes. Also add a helper to check
framebuffer buffer objects, using the former for consistency. That way
we should not fail in qxl_primary_atomic_check() because video modes
which are too big will not be added to the mode list in the first place.
Signed-off-
Pass the shadow bo to qxl_io_create_primary() instead of expecting
qxl_io_create_primary to check bo->shadow. Set is_primary flag on the
shadow bo. Move the is_primary tracking into qxl_io_create_primary()
and qxl_io_destroy_primary() functions.
That simplifies primary surface tracking and the w
Add all standard modes from the kernel's video mode data base.
Keep a few non-standard modes in the qxl mode list.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/q
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_prime.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_prime.c b/drivers/gpu/drm/qxl/qxl_prime.c
index 708378844c..22e1faf047 100644
--- a/drivers/gpu/drm/qxl/qxl_prime.c
+++ b/drivers
Add a helper function to add custom video modes to a connector.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 84 +++
1 file changed, 49 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qx
Hi Thomas,
Am Freitag, 18. Januar 2019, 01:40:03 CET schrieb Thomas Gleixner:
> On Thu, 30 Aug 2018, Heiko Stuebner wrote:
> > +++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c
> > @@ -0,0 +1,173 @@
> > +//SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) Fuzhou Rockchip Electronics Co.L
Hi Linus,
Please pull fbdev fixes for v5.0-rc3 (please see the signed tag
description for details).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
The following changes since commit 399382f8018204407174f0229b4087d40e1cdc82:
drm/nouveau: fix incor
https://bugs.freedesktop.org/show_bug.cgi?id=109380
--- Comment #2 from CI Bug Log ---
The CI Bug Log issue associated to this bug has been updated.
### New filters associated
* CHAMELIUM: igt@kms_chamelium@*suspend* - warn - Last errno: 113, No route to
host
-
https://intel-gfx-ci.01.org/tre
https://bugs.freedesktop.org/show_bug.cgi?id=109380
Martin Peres changed:
What|Removed |Added
Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
On Fri, Jan 18, 2019 at 12:38 PM Rafael J. Wysocki wrote:
>
> On Fri, Jan 18, 2019 at 12:17 PM Rafael J. Wysocki wrote:
> >
> > On Fri, Jan 18, 2019 at 12:06 PM Daniel Vetter wrote:
> > >
> > > On Fri, Jan 18, 2019 at 11:03 AM Rafael J. Wysocki
> > > wrote:
> > > >
> > > > On Fri, Jan 18, 2019
https://bugs.freedesktop.org/show_bug.cgi?id=109382
Bug ID: 109382
Summary: RX Vega M GL performance and stuttering issues
Product: Mesa
Version: 18.3
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
S
On Fri, Jan 18, 2019 at 10:10:53AM +, Priit Laes wrote:
> > > > > > It doesn't look related to the clock rate itself, since it doesn't
> > > > > > change between the two cases. However, in one case the DDC clock is
> > > > > > enabled and in the other it's disabled.
> > > > > >
> > > > > > Was
https://bugzilla.kernel.org/show_bug.cgi?id=202217
Haxk20 (haxk...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
+CC: Hans
On 17.01.2019 20:47, Ville Syrjälä wrote:
> On Fri, Dec 14, 2018 at 01:10:16PM +0100, Christoph Manszewski wrote:
>> Range setting makes sense for YCbCr and RGB buffers. Current
>> drm_color_range enum labels suggest use with YCbCr buffers.
>> Create enum labels without colorspace specif
It is often useful to check whether the DRM format info retrieved from
the DRM framebuffer matches a specific YUV planes disposition.
This introduces helpers to quickly check that a provided format info
matches a YUV format with a specific disposition, in commonly-used
terminology.
The intent of
Checking for the number of planes is not sufficient to en ensure that
the format is a packed YUV422.
Use explicit fourcc helpers for the check instead.
Signed-off-by: Paul Kocialkowski
Acked-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 3 ++-
1 file changed, 2 insertions(+), 1
This is the final step to indicate to the core that our driver
supports framebuffer modifiers.
Signed-off-by: Paul Kocialkowski
Acked-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/
From: Maxime Ripard
The FIR filters phase depend on the SoC, so let's move it to our quirks
structure instead of removing them.
Signed-off-by: Maxime Ripard
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 28 --
drivers/gpu/drm/sun4i/sun4i
This introduces specific definitions for vendor Allwinner and its
associated tiled format modifier. This modifier is used for the output
format of the VPU, that can be imported directly with the display
engine hardware supported by the sun4i-drm driver.
Signed-off-by: Paul Kocialkowski
Reviewed-b
This adds the appropriate device-tree compatible and quirk data for
hooking frontend support for the A20. It supports the FIR coefficients
ready bit but not the access control bit. It also takes different phase
values than the A33 for these coefficients.
The compatible is already used in the A10 d
This introduces support for packed YUV formats with 4:2:2 sampling using
the frontend. Definitions are introduced for the data format and pixel
sequence input format register values.
Signed-off-by: Paul Kocialkowski
Acked-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 22 +++
This series implements support for YUV formats using the display engine
frontend in the sun4i DRM driver, with various fixes along the way.
Scaling is supported for every format handled by the frontend.
The tiling mode used by the VPU on Allwinner platforms is also supported
by this series and a d
From: Maxime Ripard
The COEF_RDY bit is used to tell the hardware that new FIR filters
coefficients have been written to the registers and that the hardware
should take them into account starting next frame.
Signed-off-by: Maxime Ripard
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun
Both the backend and the frontend need the BT.601 CSC coefficients for
YUV to RGB conversion. Since the backend has a dependency on the
frontend (and not the other way round), move the coefficients there
so that both can access them without having to duplicate them.
Signed-off-by: Paul Kocialkowsk
This introduces stride and offset configuration for the VPU tiling mode.
Stride is calculated differently than it is for linear formats and an
offset is calculated, for which new register definitions are introduced.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 49
This adds the appropriate device-tree compatible for hooking frontend
support for the A20. Since the hardware is very similar to the A10, it
shares the same quirks (which were already introduced).
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 4
1 file change
This introduces a list of supported modifiers for the driver, that
includes the Allwinner tiled modifier, as well as a format_mod_supported
callback.
The callback uses both the backend and frontend helpers to indicate
per-format modifier support (including for the linear modifier).
Signed-off-by:
The helper returning the input mode needs to know the number of planes
for the provided format. Passing the fourcc requires iterating through
the format info list in order to return the number of planes.
Pass the DRM format info structure directly instead to all helpers
related to configuring the
This introduces the data input mode definitions for the tiled YUV mode,
that are used in the input mode helper if tiling is requested.
The modifier is passed to the helper from the framebuffer to determine
if tiling is requested.
Only semiplanar and planar YUV formats are supported for tiling mod
In prevision of adding support for YUV formats, set the YUV to RGB
colorspace conversion coefficients if required and don't bypass the
CSC engine when converting.
The BT601 coefficients from the A33 BSP are copied over from the backend
code. Because of module inter-dependency, we can't have the fr
Semi-planar YUV formats use two distinct planes, one for luminance and
one for chrominance. To add support for them, we need to configure the
second line stride and buffer address registers to setup the second YUV
plane.
New definitions are introduced to configure the input format register
for the
On Fri, Jan 18, 2019 at 03:34:18PM +0100, Andrzej Hajda wrote:
> +CC: Hans
>
> On 17.01.2019 20:47, Ville Syrjälä wrote:
> > On Fri, Dec 14, 2018 at 01:10:16PM +0100, Christoph Manszewski wrote:
> >> Range setting makes sense for YCbCr and RGB buffers. Current
> >> drm_color_range enum labels sugg
Since all the RGB input formats have the same value for the DATA_FMT
field of the INPUT_FMT register, we can group them when the format is
known to be RGB. Here, we assume that a non-YUV format is RGB, because
the hardware does not support any other colorspace than RGB and YUV.
Use the DRM format
From: Maxime Ripard
The COEF_RDY bit isn't found in all the SoCs featuring some variant of the
frontend.
Add it to our quirks structure.
Signed-off-by: Maxime Ripard
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 9 +
drivers/gpu/drm/sun4i/sun4i_fronten
This introduces a helper to check whether a frontend input format
supports tiling mode. This helper is used when tiling is requested in
the frontend format support helper.
Only semiplanar and planar YUV formats are supported by the hardware.
Signed-off-by: Paul Kocialkowski
Acked-by: Maxime Ripa
From: Maxime Ripard
The ACCESS_CTRL bit is not found on all the variants of the frontend, so
let's introduce a structure that will hold whether or not we need to set
it, and associate it with the compatible.
This will be extended for further similar quirks later on.
Signed-off-by: Maxime Ripard
Display engine drivers often need to distinguish between different types of
YUV sub-sampling. This introduces helpers to check for common sub-sampling
ratios in their commonly-used denomination from the DRM format info.
Signed-off-by: Paul Kocialkowski
Reviewed-by: Maxime Ripard
---
include/drm
Planar YUV formats come with 3 distinct planes, which requires
configuring the frontend line stride and address registers for the
third plane.
Our hardware only supports the YUV planes order and in order to support
formats with a YVU plane order, a helper is introduced to indicate
whether to inver
From: Maxime Ripard
Unlike what is currently being done, the ACCESS_CTRL bit documentation asks
that this bit should be set before modifying any register. The code in the
BSP also does this, so make sure we do this as well.
Signed-off-by: Maxime Ripard
Signed-off-by: Paul Kocialkowski
---
dri
Display engine drivers often need to distinguish between different types of
YUV sub-sampling. This introduces helpers to check for common sub-sampling
ratios in their commonly-used denomination from the DRM format info.
Signed-off-by: Paul Kocialkowski
Reviewed-by: Maxime Ripard
---
include/drm
It is often useful to check whether the DRM format info retrieved from
the DRM framebuffer matches a specific YUV planes disposition.
This introduces helpers to quickly check that a provided format info
matches a YUV format with a specific disposition, in commonly-used
terminology.
The intent of
Checking for the number of planes is not sufficient to en ensure that
the format is a packed YUV422.
Use explicit fourcc helpers for the check instead.
Signed-off-by: Paul Kocialkowski
Acked-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 3 ++-
1 file changed, 2 insertions(+), 1
The helper returning the input mode needs to know the number of planes
for the provided format. Passing the fourcc requires iterating through
the format info list in order to return the number of planes.
Pass the DRM format info structure directly instead to all helpers
related to configuring the
This series implements support for YUV formats using the display engine
frontend in the sun4i DRM driver, with various fixes along the way.
Scaling is supported for every format handled by the frontend.
The tiling mode used by the VPU on Allwinner platforms is also supported
by this series and a d
Since all the RGB input formats have the same value for the DATA_FMT
field of the INPUT_FMT register, we can group them when the format is
known to be RGB. Here, we assume that a non-YUV format is RGB, because
the hardware does not support any other colorspace than RGB and YUV.
Use the DRM format
1 - 100 of 191 matches
Mail list logo
