https://bugs.freedesktop.org/show_bug.cgi?id=109246
--- Comment #14 from krutoiles...@gmail.com ---
I am actually experiencing simar issues. Two monitors using displayport to hdmi
cable to connect Vega 64 to the monitors. No xorg logs as it's under Wayland
but more than happy to test any suggestio
https://bugs.freedesktop.org/show_bug.cgi?id=109389
Paul Menzel changed:
What|Removed |Added
CC||pmenzel+bugs.freedesktop.or
On Fri, Jan 18, 2019 at 03:04:34PM -0800, Evan Green wrote:
> On Fri, Jan 18, 2019 at 12:24 PM Jordan Crouse wrote:
> >
> > Try to get the interconnect path for the GPU and vote for the maximum
> > bandwidth to support all frequencies. This is needed for performance.
> > Later we will want to scal
https://bugs.freedesktop.org/show_bug.cgi?id=108015
igo95...@yandex.ru changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 1/18/19 1:32 PM, Liam Mark wrote:
On Fri, 18 Jan 2019, Laura Abbott wrote:
On 1/18/19 10:37 AM, Liam Mark wrote:
Add support for configuring dma mapping attributes when mapping
and unmapping memory through dma_buf_map_attachment and
dma_buf_unmap_attachment.
Signed-off-by: Liam Mark
---
https://bugs.freedesktop.org/show_bug.cgi?id=109080
--- Comment #3 from network...@rkmail.ru ---
Looks just like Bug 104597
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.
On Fri, Jan 18, 2019 at 01:52:20PM -0800, Doug Anderson wrote:
> Hi,
>
> On Fri, Jan 18, 2019 at 12:24 PM Jordan Crouse wrote:
> >
> > Try to get the interconnect path for the GPU and vote for the maximum
> > bandwidth to support all frequencies. This is needed for performance.
> > Later we will
Hi,
On Fri, Jan 18, 2019 at 10:06 AM Doug Anderson wrote:
> It's be nice if whoever is planning to
> land this could indicate whether they'd prefer Jordan send a new
> version to handle the API change or if the relevant maintainer can
> just do the fixup when the patch lands.
Breadcrumbs: Jordan
Hi,
On Fri, Jan 18, 2019 at 12:24 PM Jordan Crouse wrote:
>
> Try to get the interconnect path for the GPU and vote for the maximum
> bandwidth to support all frequencies. This is needed for performance.
> Later we will want to scale the bandwidth based on the frequency to
> also optimize for pow
https://bugs.freedesktop.org/show_bug.cgi?id=109389
--- Comment #1 from Paul Menzel ---
*** Bug 109390 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=109390
Paul Menzel changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=109390
Bug ID: 109390
Summary: memory leak in `amdgpu_bo_create()`
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=109389
Bug ID: 109389
Summary: memory leak in `amdgpu_bo_create()`
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
On 1/18/19 10:37 AM, Liam Mark wrote:
Add support for configuring dma mapping attributes when mapping
and unmapping memory through dma_buf_map_attachment and
dma_buf_unmap_attachment.
Signed-off-by: Liam Mark
---
include/linux/dma-buf.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/
https://bugs.freedesktop.org/show_bug.cgi?id=109388
--- Comment #1 from Alex Deucher ---
Please attach your dmesg output and xorg log (if using X). Possibly a
duplicate of bug 109375.
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=109375
--- Comment #4 from Alex Deucher ---
Should be fixed with:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=35dad45d5cad3c9ca8d6a338cbf668cd7ea86469
--
You are receiving this mail because:
You are the assignee for
On 1/18/19 12:43 PM, Andrew F. Davis wrote:
On 1/18/19 2:31 PM, Laura Abbott wrote:
On 1/17/19 8:13 AM, 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:
https://bugzilla.kernel.org/show_bug.cgi?id=201727
--- Comment #16 from Alex Deucher (alexdeuc...@gmail.com) ---
should be fixed with:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1c1eba86339c8517814863bc7dd21e2661a84e77
--
You are receiving this mail because:
Yo
On 1/18/19 2:31 PM, Laura Abbott wrote:
> On 1/17/19 8:13 AM, 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,
https://bugs.freedesktop.org/show_bug.cgi?id=108992
--- Comment #28 from Alex Deucher ---
Should be fixed with this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1c1eba86339c8517814863bc7dd21e2661a84e77
--
You are receiving this mail because:
You are the
On 1/18/19 10:37 AM, Liam Mark wrote:
Often userspace doesn't know when the kernel will be calling dma_buf_detach
on the buffer.
If userpace starts its CPU access at the same time as the sg list is being
freed it could end up accessing the sg list after it has been freed.
Thread A
https://bugs.freedesktop.org/show_bug.cgi?id=109388
Bug ID: 109388
Summary: Lenovo E585 ryzen 2500u, regression with power saving
in 5.0-rc1
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=109388
chris changed:
What|Removed |Added
Summary|Lenovo E585 ryzen 2500u,|Lenovo E585 ryzen 2500u,
|reg
https://bugzilla.kernel.org/show_bug.cgi?id=202261
Johannes Hirte (johannes.hi...@datenkhaos.de) changed:
What|Removed |Added
Status|NEW |RESOLVED
On 1/17/19 8:13 AM, 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 2019, Andrew F. Davis wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=108992
--- Comment #27 from chris ---
Still the same issue with kernel 5.0-rc1. Any plan on when to tackle that issue
?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
On Fri, Jan 18, 2019 at 01:24:18PM -0700, Jordan Crouse wrote:
> Try to get the interconnect path for the GPU and vote for the maximum
> bandwidth to support all frequencies. This is needed for performance.
> Later we will want to scale the bandwidth based on the frequency to
> also optimize for po
Try to get the interconnect path for the GPU and vote for the maximum
bandwidth to support all frequencies. This is needed for performance.
Later we will want to scale the bandwidth based on the frequency to
also optimize for power but that will require some device tree
infrastructure that does not
On 1/18/19 12:37 PM, Liam Mark wrote:
> The ION begin_cpu_access and end_cpu_access functions use the
> dma_sync_sg_for_cpu and dma_sync_sg_for_device APIs to perform cache
> maintenance.
>
> Currently it is possible to apply cache maintenance, via the
> begin_cpu_access and end_cpu_access APIs, t
On 1/16/19 8:05 AM, Andrew F. Davis wrote:
On 1/15/19 12:58 PM, Laura Abbott wrote:
On 1/15/19 9:47 AM, Andrew F. Davis wrote:
On 1/14/19 8:39 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
Hello all,
This is a set of (hopefully) non-controversial cleanups for the ION
fr
On 1/18/19 1:59 AM, Greg Kroah-Hartman wrote:
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 bel
On 1/16/19 9:12 AM, Andrew F. Davis wrote:
On 1/16/19 9:28 AM, Brian Starkey wrote:
Hi Andrew,
On Fri, Jan 11, 2019 at 12:05:20PM -0600, Andrew F. Davis wrote:
The heap name can be used for debugging but otherwise does not seem
to be required and no other part of the code will fail if left NUL
On Fri, 2019-01-18 at 20:32 +0100, Mathieu Malaterre wrote:
> Using strncpy() is less than perfect since the destination buffers do not
> need to be NUL terminated. Replace strncpy() with memcpy() to address a
> warning triggered by gcc using W=1 and optimize the code a bit.
>
> This commit remove
https://bugs.freedesktop.org/show_bug.cgi?id=109384
fabi...@keemail.me changed:
What|Removed |Added
Attachment #143154|dmesh with DC off |dmesg with DC off
descriptio
On 1/18/19 12:37 PM, Liam Mark wrote:
> Often userspace doesn't know when the kernel will be calling dma_buf_detach
> on the buffer.
> If userpace starts its CPU access at the same time as the sg list is being
> freed it could end up accessing the sg list after it has been freed.
>
> Thread A
On Fri, Jan 18, 2019 at 1:06 PM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Dec 20, 2018 at 9:30 AM Jordan Crouse wrote:
> >
> > Try to get the interconnect path for the GPU and vote for the maximum
> > bandwidth to support all frequencies. This is needed for performance.
> > Later we will want to s
Attached series is the first 2 patches we already discussed about ring
mirror list handling racing with all your comments fixed (still not
committed). The third patch is a prototype based on the first 2 patches
and on our discussion.
Please take a look.
Andrey
On 01/18/2019 01:32 PM, Koenig,
https://bugzilla.kernel.org/show_bug.cgi?id=201795
--- Comment #12 from thomas.lassdiesonner...@gmx.de ---
@fin4478
Read. I use rolling. I won't use wip stuff.
@Michael Dänzer
The bug is still there with Kernel 4.20.1 and 4.19.14.
With 4.14.92 everything is fine.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=109384
--- Comment #5 from fabi...@keemail.me ---
Created attachment 143155
--> https://bugs.freedesktop.org/attachment.cgi?id=143155&action=edit
dmesg with DC on
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=109384
--- Comment #4 from fabi...@keemail.me ---
Created attachment 143154
--> https://bugs.freedesktop.org/attachment.cgi?id=143154&action=edit
dmesh with DC off
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=109384
--- Comment #3 from fabi...@keemail.me ---
Created attachment 143153
--> https://bugs.freedesktop.org/attachment.cgi?id=143153&action=edit
Xorg.1 log with DC on
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=109384
--- Comment #2 from fabi...@keemail.me ---
Created attachment 143152
--> https://bugs.freedesktop.org/attachment.cgi?id=143152&action=edit
Xorg.0 log with DC on
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=109384
--- Comment #1 from fabi...@keemail.me ---
Created attachment 143151
--> https://bugs.freedesktop.org/attachment.cgi?id=143151&action=edit
Xorg.1 log with DC off
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=109384
Bug ID: 109384
Summary: Bad DisplayPort enumeration and wrong refresh rate
with Hawaii chip
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linu
Am 18.01.19 um 18:34 schrieb Grodzovsky, Andrey:
>
> On 01/18/2019 12:10 PM, Koenig, Christian wrote:
>> Am 18.01.19 um 16:21 schrieb Grodzovsky, Andrey:
>>> On 01/18/2019 04:25 AM, Koenig, Christian wrote:
[SNIP]
Re-arming the timeout should probably have a much reduced value
>>>
On Fri, Jan 18, 2019 at 03:51:10PM +0100, Paul Kocialkowski wrote:
> 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 us
Hi,
On Thu, Dec 20, 2018 at 9:30 AM Jordan Crouse wrote:
>
> Try to get the interconnect path for the GPU and vote for the maximum
> bandwidth to support all frequencies. This is needed for performance.
> Later we will want to scale the bandwidth based on the frequency to
> also optimize for powe
Refactor the ratelimit printk to a helper macro and implement
DRM_DEV_INFO_RATELIMITED and DRM_DEV_ERROR_RATELIMITED using the helper.
Signed-off-by: Kristian H. Kristensen
---
include/drm/drm_print.h | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --gi
Otherwise we get hard to track down "Purging: 123123 bytes" messages in
the log.
Signed-off-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gem_shrinker.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c
b/drivers/gpu/drm/msm/
The pull request you sent on Fri, 18 Jan 2019 13:38:44 +0100:
> https://github.com/bzolnier/linux.git tags/fbdev-v5.0-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2a8cbf2a02784efc02f709310e20c4ebc9ea
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wi
The pull request you sent on Fri, 18 Jan 2019 15:44:48 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-01-18-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c3653ebdf89315a3a683f03b8b181942e452d603
Thank you!
--
Deet-doot-dot, I am a bot.
https:/
Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is
formatted in IEEE-754 half-precision float (binary16) 1:5:10
MSb-sign:exponent:fraction form.
This patch attempts to address the feedback provided when 2 of these
formats were previosly proposed:
https://patchwork.kernel.o
This series defines new formats and adds implementation to the i915 driver.
Since posting v1 I have removed the pixel normalize property, as it's not needed
for basic functionality. Also, I have been working on adding support to
userspace.
I have submitted an RFC to Mesa to make use of the new for
64 bpp half float formats are supported on hdr planes only and are subject
to the following restrictions:
* 90/270 rotation not supported
* Yf Tiling not supported
* Frame Buffer Compression not supported
* Color Keying not supported
v2:
- Drop handling pixel normalize register
- Don't use
On Wed, Jan 9, 2019 at 1:59 AM Hsin-Yi, Wang wrote:
>
> Move mipi_dsi_dcs_set_display_off() from innolux_panel_disable()
> to innolux_panel_unprepare(), so they are consistent with
> innolux_panel_enable() and innolux_panel_prepare().
>
> This also fixes some mode check and irq timeout issue in MT
Hi,
On Wed, Jan 9, 2019 at 9:52 AM Jayant Shekhar wrote:
> @@ -127,7 +153,11 @@ static int dpu_mdss_enable(struct msm_mdss *mdss)
> {
> struct dpu_mdss *dpu_mdss = to_dpu_mdss(mdss);
> struct dss_module_power *mp = &dpu_mdss->mp;
> - int ret;
> + int ret, i;
> +
On 01/18/2019 12:10 PM, Koenig, Christian wrote:
> Am 18.01.19 um 16:21 schrieb Grodzovsky, Andrey:
>> On 01/18/2019 04:25 AM, Koenig, Christian wrote:
>>> [SNIP]
>>> Re-arming the timeout should probably have a much reduced value
>>> when the job hasn't changed. E.g. something like a few
https://bugs.freedesktop.org/show_bug.cgi?id=109080
--- Comment #2 from Boyuan Zhang ---
Hi Rafal,
First of all, sorry for getting back to you late. I somehow missed this
message.
I took a look of your reported issue, but I got a little it confused here. So
you saw color corruptions when playin
On 1/17/19 7:11 PM, Liam Mark wrote:
> 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
On Fri, Jan 18, 2019 at 5:32 PM Ville Syrjälä
wrote:
>
> On Fri, Jan 18, 2019 at 04:49:44PM +0100, Daniel Vetter wrote:
> > On Fri, Jan 18, 2019 at 01:20:20PM +0100, Gerd Hoffmann wrote:
> > > Signed-off-by: Gerd Hoffmann
> >
> > We already do all reasonable overflow checks in drm_mode_create_dum
Am 18.01.19 um 16:21 schrieb Grodzovsky, Andrey:
>
> On 01/18/2019 04:25 AM, Koenig, Christian wrote:
>> [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 pro
On 1/17/19 7:04 PM, Liam Mark wrote:
> 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
On Fri, Jan 18, 2019 at 04:49:44PM +0100, Daniel Vetter wrote:
> On Fri, Jan 18, 2019 at 01:20:20PM +0100, Gerd Hoffmann wrote:
> > Signed-off-by: Gerd Hoffmann
>
> We already do all reasonable overflow checks in drm_mode_create_dumb(). If
> you don't trust them I think would be better time spent
On 1/18/19 3:59 AM, Greg Kroah-Hartman wrote:
> 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
On Fri, Jan 18, 2019 at 01:20:20PM +0100, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
We already do all reasonable overflow checks in drm_mode_create_dumb(). If
you don't trust them I think would be better time spent typing an igt to
test this than adding redundant check in all drivers.
On Thu, Jan 17, 2019 at 10:02 AM Jagan Teki wrote:
>
> On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard
> wrote:
> >
> > On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote:
> > > > > > > > Again, I cannot help you without the datasheet for the panels
> > > > > > > > you're
> > > > > > > >
https://bugs.freedesktop.org/show_bug.cgi?id=109290
Martin Peres changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #7 from Martin Peres
https://bugs.freedesktop.org/show_bug.cgi?id=109303
Martin Peres changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #4 from Martin Peres
Hi Sam,
Thank you for the patch.
On Sat, Jan 12, 2019 at 08:32:51PM +0100, Sam Ravnborg wrote:
> With the removal of drmP.h from drm_modeset_helper.h
> the drmP.h are no longer included by any include files
> in include/drm.
> The drmP.h file is thus only included explicit
> either in .c files or
Hi Sam,
Thank you for the patch.
On Sat, Jan 12, 2019 at 08:32:50PM +0100, Sam Ravnborg wrote:
> The use of drmP.h is discouraged and removal of it from
> drm_modeset_helper.h caused rcar-du to fail to build.
>
> This patch introduce the necessary fixes to prepare for the
> drmP.h removal from d
On 01/18/2019 04:25 AM, Koenig, Christian wrote:
> [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 jus
Hi Sam,
Thank you for the patch.
On Sat, Jan 12, 2019 at 08:32:45PM +0100, Sam Ravnborg wrote:
> In the quest to get rid of drmP.h move the newly
> added EXPORT_SYMBOL_FOR_TESTS_ONLY to drm_util.h.
Would it make sense to move it to drm_internal.h as it's really for
internal use of the DRM core ?
Hi Sam,
Thank you for the patch.
On Sat, Jan 12, 2019 at 08:32:44PM +0100, Sam Ravnborg wrote:
> Move drm_can_sleep() out of drmP.h to allow users
> to get rid of the drmP.h include.
>
> There was no header file that was a good match for this helper function.
> So add this to drm_util with the r
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 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
Acked-by: Maxime Ripard
---
drivers/gpu/drm/su
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
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/
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 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
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
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
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 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
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 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
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
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:
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 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
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
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
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
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
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
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
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
1 - 100 of 191 matches
Mail list logo
