On 07.06.2019 06:45, Andrey Smirnov wrote:
> We don't need 8 byte array, DP_LINK_STATUS_SIZE (6) should be
> enough. This also gets rid of a magic number as a bonus.
>
> Signed-off-by: Andrey Smirnov
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> Cc: Andrzej Hajda
> Cc: Laurent Pinchart
> Cc
On 07.06.2019 06:45, Andrey Smirnov wrote:
> tc_get_display_props() never reads more than a byte via AUX, so
> there's no need to reserve 8 for that purpose. No function change
> intended.
>
> Signed-off-by: Andrey Smirnov
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> Cc: Andrzej Hajda
> Cc:
From: "Ong, Hean Loong"
Driver for Intel FPGA Video and Image Processing Suite Frame Buffer II.
The driver only supports the Intel Arria10 devkit and its variants.
This driver can be either loaded staticlly or in modules.
The OF device tree binding is located at:
Documentation/devicetree/bindings
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #46 from Richard Thier ---
In comparison this is the unpatched 19.x originally (10 sec):
-> 12466 (any) ioctl calls
-> 3111 DRM_IOCTL_RADEON_GEM_CREATE
-> 3112 DRM_IOCTL_GEM_CLOSE
^^Sorry these values were bad, it is not this much
From: Ong Hean Loong
Intel FPGA Video and Image Processing Suite Frame Buffer II
driver config for Arria 10 devkit and its variants
Signed-off-by: Ong, Hean Loong
---
arch/arm/configs/socfpga_defconfig | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/configs/socfpga_defconf
From: Hean-Loong Ong
The FPGA FrameBuffer Soft IP could be seen as the GPU and the DRM driver
patch here is allocating memory for information to be streamed from the
ARM/Linux to the display port.
Basically the driver just wraps the information such as the pixels to be
drawn by the Sodt IP Fram
From: "Ong, Hean Loong"
Device tree binding for Intel FPGA Video and Image Processing Suite.
The bindings would set the max width, max height,
bits per pixel and memory port width.
The device tree binding only supports the Intel
Arria10 devkit and its variants. Vendor name retained as altr.
Revi
From: Hean-Loong Ong
The FPGA FrameBuffer Soft IP could be seen as the GPU and the DRM driver
patch here is allocating memory for information to be streamed from the
ARM/Linux to the display port.
Basically the driver just wraps the information such as the pixels to be
drawn by the Sodt IP Fram
From: "Ong, Hean Loong"
Device tree binding for Intel FPGA Video and Image Processing Suite.
The bindings would set the max width, max height,
bits per pixel and memory port width.
The device tree binding only supports the Intel
Arria10 devkit and its variants. Vendor name retained as altr.
Revi
On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
> Guys, this discussion is getting heated for no reason. Let's put
> personal frustrations aside and discuss the issue on its merits:
>
> Maxime Ripard writes:
> > On Wed, Jun 05, 2019 at 12:13:17PM +0200, Torsten Duwe wrote:
> > > On Tu
On 07.06.2019 06:45, Andrey Smirnov wrote:
> We never pass anything but 100 as timeout_ms to tc_aux_wait_busy(), so
> we may as well hardcode that value and simplify function's signature.
>
> Signed-off-by: Andrey Smirnov
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> Cc: Andrzej Hajda
> Cc:
On 07.06.2019 06:45, Andrey Smirnov wrote:
> tc_wait_pll_lock() is always called as a follow-up for updating
> PLLUPDATE and PLLEN bit of a given PLL control register. To simplify
> things, merge the two operation into a single helper function
> tc_pllupdate_pllen() and convert the rest of the code
On 07.06.2019 06:45, Andrey Smirnov wrote:
> Move common code converting clock rate to an appropriate constant and
> configuring SYS_PLLPARAM register into a separate routine and convert
> the rest of the code to use it. No functional change intended.
>
> Signed-off-by: Andrey Smirnov
> Reviewed-b
On 07.06.2019 06:45, Andrey Smirnov wrote:
> Transfer size of zero means a request to do an address-only
> transfer. Since the HW support this, we probably shouldn't be just
> ignoring such requests. While at it allow DP_AUX_I2C_MOT flag to pass
> through, since it is supported by the HW as well.
>
On 07.06.2019 06:45, Andrey Smirnov wrote:
> Don't assume that requested data transfer size is the same as amount
> of data that was transferred. Change the code to get that information
> from DP0_AUXSTATUS instead.
>
> Since the check for AUX_BUSY in tc_aux_get_status() is pointless (it
> will alw
Hey Dave,
This is a bit more than I'd like to be pushing at this point in a
cycle, but it's a fairly important issue. There's been numerous
reports of more recent GP10[2467] boards failing to load, and I've
worked with NVIDIA FW engineers and tracked this down to the FW we've
been using not prope
Simplify AUX data write by dropping index arithmetic and shifting and
replacing it with a call to a helper function that does two things:
1. Copies user-provided data into a write buffer
2. Transfers contents of the write buffer to up to 4 32-bit
registers on the chip
Note that sep
A very unfortunate aspect of tc_write()/tc_read() macro helpers is
that they capture quite a bit of context around them and thus require
the caller to have magic variables 'ret' and 'tc' as well as label
'err'. That makes a number of code paths rather counter-intuitive and
somewhat clunky, for exam
According to the datasheet tc358767 can transfer up to 16 bytes via
its AUX channel, so the artificial limit of 8 appears to be too
low. However only up to 15-bytes seem to be actually supported and
trying to use 16-byte transfers results in transfers failing
sporadically (with bogus status in case
tc_wait_pll_lock() is always called as a follow-up for updating
PLLUPDATE and PLLEN bit of a given PLL control register. To simplify
things, merge the two operation into a single helper function
tc_pllupdate_pllen() and convert the rest of the code to use it. No
functional change intended.
Signed-
Move common code converting clock rate to an appropriate constant and
configuring SYS_PLLPARAM register into a separate routine and convert
the rest of the code to use it. No functional change intended.
Signed-off-by: Andrey Smirnov
Reviewed-by: Laurent Pinchart
Cc: Archit Taneja
Cc: Andrzej Ha
Don't assume that requested data transfer size is the same as amount
of data that was transferred. Change the code to get that information
from DP0_AUXSTATUS instead.
Since the check for AUX_BUSY in tc_aux_get_status() is pointless (it
will always called after tc_aux_wait_busy()) and there's only
Simplify tc_set_video_mode() by replacing explicit shifting using
macros from . No functional change intended.
Signed-off-by: Andrey Smirnov
Reviewed-by: Andrzej Hajda
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Cc: Andrey Gusakov
Cc: Philipp Zabel
Cc: Cory Tusar
Cc: Chris He
Implementation of tc_poll_timeout() is almost a 100% copy-and-paste of
the code for regmap_read_poll_timeout(). Replace copied code with a
call to the original. While at it change tc_poll_timeout to accept
"struct tc_data *" instead of "struct regmap *" for brevity. No
functional change intended.
tc_get_display_props() never reads more than a byte via AUX, so
there's no need to reserve 8 for that purpose. No function change
intended.
Signed-off-by: Andrey Smirnov
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Cc: Andrey Gusakov
Cc: Philipp Zabel
Cc: Cory Tusar
Cc: Chris H
Transfer size of zero means a request to do an address-only
transfer. Since the HW support this, we probably shouldn't be just
ignoring such requests. While at it allow DP_AUX_I2C_MOT flag to pass
through, since it is supported by the HW as well.
Signed-off-by: Andrey Smirnov
Cc: Andrzej Hajda
C
We never pass anything but 100 as timeout_ms to tc_aux_wait_busy(), so
we may as well hardcode that value and simplify function's signature.
Signed-off-by: Andrey Smirnov
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Cc: Andrey Gusakov
Cc: Philipp Zabel
Cc: Cory Tusar
Cc: Chris
Everyone:
This series contains various improvements (at least in my mind) and
fixes that I made to tc358767 while working with the code of the
driver. Hopefuly each patch is self explanatory.
Feedback is welcome!
Thanks,
Andrey Smirnov
Changes since [v3]:
- Collected Reviewed-bys from Andr
Replace explicit polling loop with equivalent call to
tc_poll_timeout() for brevity. No functional change intended.
Signed-off-by: Andrey Smirnov
Reviewed-by: Andrzej Hajda
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Cc: Andrey Gusakov
Cc: Philipp Zabel
Cc: Cory Tusar
Cc: Chr
Replace explicit polling in tc_link_training() with equivalent call to
tc_poll_timeout() for simplicity. No functional change intended (not
including slightly altered debug output).
Signed-off-by: Andrey Smirnov
Reviewed-by: Andrzej Hajda
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Tomi Valkein
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #8 from Rolf ---
@Andrew, I have an ASUS Radeon VII 16GB.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.o
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #7 from Rolf ---
@Andrew, thank you for the script. I will give it a try shortly. As an aside, I
noticed that someone changed the component from AMDgpu to AMDgpu-pro. I was not
installing pro. Will your script work with a standard in
https://bugs.freedesktop.org/show_bug.cgi?id=109022
--- Comment #22 from e88z4 ---
Created attachment 144472
--> https://bugs.freedesktop.org/attachment.cgi?id=144472&action=edit
apitrace log
Hi,
I attached the apitrace log being written to my standard output while replaying
my apitrace file
This adds a CMA heap, which allows userspace to allocate
a dma-buf of contiguous memory out of a CMA region.
This code is an evolution of the Android ION implementation, so
thanks to its original author and maintainters:
Benjamin Gaignard, Laura Abbott, and others!
Cc: Laura Abbott
Cc: Benjami
Add generic helper dmabuf ops for dma heaps, so we can reduce
the amount of duplicative code for the exported dmabufs.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
C
Here is another pass at the dma-buf heaps patchset Andrew and I
have been working on which tries to destage a fair chunk of ION
functionality.
The patchset implements per-heap devices which can be opened
directly and then an ioctl is used to allocate a dmabuf from the
heap.
The interface is simil
This patch adds system heap to the dma-buf heaps framework.
This allows applications to get a page-allocator backed dma-buf
for non-contiguous memory.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cr
From: "Andrew F. Davis"
This framework allows a unified userspace interface for dma-buf
exporters, allowing userland to allocate specific types of memory
for use in dma-buf sharing.
Each heap is given its own device node, which a user can allocate
a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
Add very trivial allocation and import test for dma-heaps,
utilizing the vgem driver as a test importer.
A good chunk of this code taken from:
tools/testing/selftests/android/ion/ionmap_test.c
Originally by Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #6 from Andrew Shark ---
Created attachment 144471
--> https://bugs.freedesktop.org/attachment.cgi?id=144471&action=edit
Script to modify packages to be able to use with ubuntu 19.04
Initial version
--
You are receiving this mai
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #45 from Marek Olšák ---
Yeah that looks good.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://
https://bugzilla.kernel.org/show_bug.cgi?id=201539
artheg (art...@gmail.com) changed:
What|Removed |Added
CC||art...@gmail.com
--- Comment
Hey Linus,
A small bit more lively this week but not majorly so. I'm away in
Japan next week for family holiday, so I'll be pretty disconnected,
I've asked Daniel to do fixes for the week while I'm out.
core:
- Allow fb changes in async commits (drivers as well)
udmabuf:
- Unmap scatterlist when
On Thu, 6 Jun 2019 at 21:00, Emil Velikov wrote:
>
> On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
> >
> > From: Emil Velikov
> >
> > The authentication can be circumvented, by design, by using the render
> > node.
> >
> > From the driver POV there is no distinction between primary and rende
Hi,
On Thu, Jun 6, 2019 at 9:42 AM Sean Paul wrote:
>
> On Tue, Jun 04, 2019 at 01:42:07PM -0700, Douglas Anderson wrote:
> > On Rockchip rk3288-based Chromebooks when you do a suspend/resume
> > cycle:
> >
> > 1. You lose the ability to detect an HDMI device being plugged in.
> >
> > 2. If you'r
This patch implements the necessary functions to add writeback support
for vkms. This feature is useful for testing compositors if you don’t
have hardware with writeback support.
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/Makefile | 9 +-
drivers/gpu/drm/vkms/vkms_crtc.c
When vkms calls drm_universal_plane_init(), it sets 0 for the
possible_crtcs parameter which works well for a single encoder and
connector; however, this approach is not flexible and does not fit well
for vkms. This commit adds an index parameter for vkms_plane_init()
which makes code flexible and
This patchset introduces the writeback connector to vkms. The first
patch is required for enabling the virtual encoder to be compatible with
the crtc when we have multiple encoders. The second patch adds the
required implementation to enable writeback in the vkms. With this
patchset, vkms can succe
The issue we have is that the crc worker might fall behind. We've
tried to handle this by tracking both the earliest frame for which it
still needs to compute a crc, and the last one. Plus when the
crtc_state changes, we have a new work item, which are all run in
order due to the ordered workqueue
irqs are already off.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vkms/vkms_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index b6987d90805f..48a793ba4030 100644
--- a/drivers/gpu/drm/vkms/
No need to have them multiple times.
Signed-off-by: Daniel Vetter
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Cc: Daniel Vetter
---
drivers/gpu/drm/vkms/vkms_drv.h | 8
drivers/gpu/drm/vkms/vkms_plane.c | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drive
The crc computation worker needs to be able to get at some data
structures and framebuffer mappings, while potentially more atomic
updates are going on. The solution thus far is to copy relevant bits
around, but that's very tedious.
Here's a new approach, which tries to be more clever, but relies
The crc core code can cope with some late crc, the race is kinda
unavoidable. So no need to flush pending workers, they'll complete in
time.
Signed-off-by: Daniel Vetter
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Cc: Daniel Vetter
---
drivers/gpu/drm/vkms/vkms_crc.c | 3 ---
1 file changed, 3 d
Plus add a comment about what it actually protects. It's very little.
Signed-off-by: Daniel Vetter
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Cc: Daniel Vetter
---
drivers/gpu/drm/vkms/vkms_crc.c | 4 ++--
drivers/gpu/drm/vkms/vkms_crtc.c | 6 +++---
drivers/gpu/drm/vkms/vkms_drv.h | 5 +++--
The worker is always in process context, no need for the _irqsafe
version. Same for the set_source callback, that's only called from the
debugfs handler in a syscall.
Cc: Shayenne Moura
Cc: Rodrigo Siqueira
Signed-off-by: Daniel Vetter
Cc: Haneen Mohammed
Cc: Daniel Vetter
---
drivers/gpu/dr
We're now guaranteed to no longer race against prepare_fb/cleanup_fb,
which means we can access ->vaddr without having to hold a lock.
Before the previous patches it was fairly easy to observe the cursor
->vaddr being invalid, but that's now gone, so we can upgrade to a
full WARN_ON.
Signed-off-b
Just prep work, more will be done here in following patches.
Signed-off-by: Daniel Vetter
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Cc: Daniel Vetter
---
drivers/gpu/drm/vkms/vkms_drv.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_drv
Hi all,
This here is the first part of a rework for the vkms crc worker. I think
this should fix all the locking/races/use-after-free issues I spotted in
the code. There's more work we can do in the future as a follow-up:
- directly access vkms_plane_state->base in the crc worker, with this
app
Currently we flush pending crc workers very late in the commit flow,
when we destry all the old crtc states. Unfortunately at that point
the framebuffers are already unpinned (and our vaddr possible gone),
so this isn't good. Also, the plane_states we need might also already
be cleaned up, since cl
I. was. blind.
Caught with vkms, which has some really slow crc computation function.
Fixes: 1882018a70e0 ("drm/crc-debugfs: User irqsafe spinlock in
drm_crtc_add_crc_entry")
Cc: Rodrigo Siqueira
Cc: Tomeu Vizoso
Cc: Emil Velikov
Cc: Benjamin Gaignard
Cc: Ville Syrjälä
Signed-off-by: Daniel
On Thu, Jun 6, 2019 at 10:20 PM James Hilliard
wrote:
>
> Imported from https://git.tizen.org/cgit/kernel/kernel-mfld-blackbay/
>
> This is currently not functional and based off of an older version of
> the gma500 driver. From the commit log this was written by Intel, is
> anyone aware of a more
On Thu, 2019-06-06 at 19:41 +, Li, Sun peng (Leo) wrote:
>
> On 2019-06-03 3:28 p.m., Lyude Paul wrote:
> > > I'm reproducing this just by reloading i915 on a machine with some MST
> > > displays connected. I uploaded a copy of the script that I use to do
> > > this
> > > here:
> > >
> > > ht
Hi James.
I have no clue on the origin of this patch.
But just to mke sure we do not hit the tree with some trivial issues
here goes...
Sam
On Thu, Jun 06, 2019 at 02:20:32PM -0600, James Hilliard wrote:
> Imported from https://git.tizen.org/cgit/kernel/kernel-mfld-blackbay/
>
> This is
Imported from https://git.tizen.org/cgit/kernel/kernel-mfld-blackbay/
This is currently not functional and based off of an older version of
the gma500 driver. From the commit log this was written by Intel, is
anyone aware of a more up to date version?
I'm looking to see if this would be a decent
On 06/06/2019 05:22 PM, Jacopo Mondi wrote:
> Add device tree bindings documentation for the Renesas R-Car Display
> Unit Color Management Module.
>
> CMM is the image enhancement module available on each R-Car DU video
> channel on Gen2 and Gen3 SoCs (V3H and V3M excluded).
>
> Signed-off-by: J
Hi Laurent, Jacopo,
On Thu, Jun 6, 2019 at 8:50 PM Laurent Pinchart
wrote:
> On Thu, Jun 06, 2019 at 04:22:03PM +0200, Jacopo Mondi wrote:
> > Update the 'vsps' property structure in the documentation example to
> > reflect what's actually implemented in the device tree sources.
> >
> > Signed-of
Hi Jason,
On Thu, 6 Jun 2019 15:25:49 + Jason Gunthorpe wrote:
>
> On Mon, May 27, 2019 at 04:12:47PM -0300, Jason Gunthorpe wrote:
> > On Sat, May 25, 2019 at 03:52:10PM -0700, Andrew Morton wrote:
> > > On Fri, 24 May 2019 09:44:55 -0300 Jason Gunthorpe wrote:
> > >
> > > > Now that -
On Thu, Jun 6, 2019 at 3:34 AM Andrzej Hajda wrote:
>
> On 05.06.2019 09:04, Andrey Smirnov wrote:
> > A very unfortunate aspect of tc_write()/tc_read() macro helpers is
> > that they capture quite a bit of context around them and thus require
> > the caller to have magic variables 'ret' and 'tc'
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #44 from Rui Salvaterra ---
Created attachment 144469
--> https://bugs.freedesktop.org/attachment.cgi?id=144469&action=edit
r300g: implement glsl shader caching.
And here's a preliminary patch. If it looks good enough to you, I'll
On 2019-06-03 3:28 p.m., Lyude Paul wrote:
>> I'm reproducing this just by reloading i915 on a machine with some MST
>> displays connected. I uploaded a copy of the script that I use to do this
>> here:
>>
>> https://people.freedesktop.org/~lyudess/archive/06-03-2019/unloadgpumod.sh
> oops-almost
On Thu, Jun 6, 2019 at 1:08 AM Andrzej Hajda wrote:
>
> On 05.06.2019 09:04, Andrey Smirnov wrote:
> > Replace explicit polling in tc_link_training() with equivalent call to
> > tc_poll_timeout() for simplicity. No functional change intended (not
> > including slightly altered debug output).
> >
>
[resent with correct address for Alex]
On 2019-06-06 11:11 a.m., Jason Gunthorpe wrote:
> On Fri, May 10, 2019 at 07:53:21PM +, Kuehling, Felix wrote:
>> These problems were found in AMD-internal testing as we're working on
>> adopting HMM. They are rebased against glisse/hmm-5.2-v3. We'd lik
Thanks for the quick follow-up to Sam.
Drop the word "actually" from the patch subject line.
It's generally helpful to generate a 2nd version of the patch with '-v
2', and to leave a description what v2 changed.
Also CC anyone who previously commented.
On 2019-06-05 2:35 p.m., Dingchen Zhang wr
On 2019-06-06 11:11 a.m., Jason Gunthorpe wrote:
> On Fri, May 10, 2019 at 07:53:21PM +, Kuehling, Felix wrote:
>> These problems were found in AMD-internal testing as we're working on
>> adopting HMM. They are rebased against glisse/hmm-5.2-v3. We'd like to get
>> them applied to a mainline Li
https://bugs.freedesktop.org/show_bug.cgi?id=110822
Gobinda Joy changed:
What|Removed |Added
Summary|booting with kernel version |[Bisected]Booting with
Hi Laurent,
On Thu, Jun 06, 2019 at 07:58:57PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Thu, Jun 06, 2019 at 04:22:05PM +0200, Jacopo Mondi wrote:
> > Add clock definitions for CMM units on Renesas R-Car Gen3 H3.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
>
Hi Jacopo,
On Thu, Jun 6, 2019 at 4:21 PM Jacopo Mondi wrote:
> Add device tree bindings documentation for the Renesas R-Car Display
> Unit Color Management Module.
>
> CMM is the image enhancement module available on each R-Car DU video
> channel on Gen2 and Gen3 SoCs (V3H and V3M excluded).
R-
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #43 from Rui Salvaterra ---
Hi, everyone!
I finally did it, I was able to point the envvars in the right direction,
tested Marek's patch and it seems to be working nicely. Compiz feels much
snappier, indeed. Feel free to add,
Teste
Neil Armstrong writes:
> The G12A Primary plane was disabled by writing in the OSD1 configuration
> registers, but this caused the plane blender to stall instead of continuing
> blended only the overlay plane.
grammar nit: "...instead of continuing to blend only the overlay plane."
> Fix this b
Neil Armstrong writes:
> The primary plane disable logic is flawed, when the primary plane is
> disabled, it is re-enabled in the vsync irq when another plane is updated.
>
> Handle the plane disabling correctly by handling the primary plane
> enable flag in the primary plane update & disable cal
Neil Armstrong writes:
> With the YUV420 handling, we can dynamically setup the HDMI output
> pixel format depending on the mode and connector info.
> So now, we can output in YUV444, which is the native video pipeline
> format, directly to the HDMI Sink if it's supported without
> necessarily in
Neil Armstrong writes:
> This patch adds support for the YUV420 output from the Amlogic Meson SoCs
> Video Processing Unit to the HDMI Controller.
>
> The YUV420 is obtained by generating a YUV444 pixel stream like
> the classic HDMI display modes, but then the Video Encoder output
> can be confi
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:13PM +0200, Jacopo Mondi wrote:
> Add CMM units to Renesas R-Car D3 device tree and reference them from
> the Display Unit they are connected to.
>
> While at it, re-sort the du device node properties to match the ordering
> found
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:12PM +0200, Jacopo Mondi wrote:
> Add CMM units to Renesas R-Car E3 device tree and reference them from
> the Display Unit they are connected to.
>
> While at it, re-sort the du device node properties to match the ordering
> found
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:11PM +0200, Jacopo Mondi wrote:
> Add CMM units to Renesas R-Car M3-N device tree and reference them from
> the Display Unit they are connected to.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> arch/ar
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:10PM +0200, Jacopo Mondi wrote:
> Add CMM units to Renesas R-Car H3 device tree and reference them from
> the Display Unit they are connected to.
>
> While at it, re-sort the du device node properties to match the ordering
> found
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:09PM +0200, Jacopo Mondi wrote:
> Add CMM units to Renesas R-Car M3-W device tree and reference them from
> the Display Unit they are connected to.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> arch/ar
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:08PM +0200, Jacopo Mondi wrote:
> Add clock definitions for CMM units on Renesas R-Car Gen3 D3.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> drivers/clk/renesas/r8a77995-cpg-mssr.c | 2 ++
> 1 file ch
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:07PM +0200, Jacopo Mondi wrote:
> Add clock definitions for CMM units on Renesas R-Car Gen3 E3.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> drivers/clk/renesas/r8a77990-cpg-mssr.c | 2 ++
> 1 file ch
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:06PM +0200, Jacopo Mondi wrote:
> Add clock definitions for CMM units on Renesas R-Car Gen3 M3-N.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> drivers/clk/renesas/r8a77965-cpg-mssr.c | 3 +++
> 1 file
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:05PM +0200, Jacopo Mondi wrote:
> Add clock definitions for CMM units on Renesas R-Car Gen3 H3.
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/clk/renesas/r8a7795-cpg-mssr.c | 4
> 1 file changed, 4 insertions(+)
>
> diff
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:03PM +0200, Jacopo Mondi wrote:
> Update the 'vsps' property structure in the documentation example to
> reflect what's actually implemented in the device tree sources.
>
> Signed-off-by: Jacopo Mondi
> ---
> Documentation/devic
Neil Armstrong writes:
> Add immutable zpos property to primary and overlay planes to specify
> the current fixed zpos position.
>
> Fixes: f9a2348196d1 ("drm/meson: Support Overlay plane for video rendering")
> Signed-off-by: Neil Armstrong
Reviewed-by: Kevin Hilman
__
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:02PM +0200, Jacopo Mondi wrote:
> Document the newly added 'cmms' property which accepts a list of phandle
> and channel index pairs that point to the CMM units available for each
> Display Unit output video channel.
>
> Signed-of
Neil Armstrong writes:
> Add missing XBGR & ABGR formats variants from the primary plane.
>
> Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
> Signed-off-by: Neil Armstrong
Reviewed-by: Kevin Hilman
___
dri-deve
Hi Jacopo,
Thank you for the patch.
On Thu, Jun 06, 2019 at 04:22:01PM +0200, Jacopo Mondi wrote:
> Add device tree bindings documentation for the Renesas R-Car Display
> Unit Color Management Module.
>
> CMM is the image enhancement module available on each R-Car DU video
> channel on Gen2 and
Neil Armstrong writes:
> Signed-off-by: Neil Armstrong
Reviewed-by: Kevin Hilman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Jun 04, 2019 at 01:42:07PM -0700, Douglas Anderson wrote:
> On Rockchip rk3288-based Chromebooks when you do a suspend/resume
> cycle:
>
> 1. You lose the ability to detect an HDMI device being plugged in.
>
> 2. If you're using the i2c bus built in to dw_hdmi then it stops
> working.
>
On Tue, Jun 04, 2019 at 01:42:06PM -0700, Douglas Anderson wrote:
> On Rockchip rk3288-based Chromebooks when you do a suspend/resume
> cycle:
>
> 1. You lose the ability to detect an HDMI device being plugged in.
>
> 2. If you're using the i2c bus built in to dw_hdmi then it stops
> working.
>
Neil Armstrong writes:
> The Amlogic G12A HDMI PLL needs some specific settings to lock with
> different fractional values for the 5,4GHz mode.
>
> Handle the 1000/1001 variation fractional case here to avoid having
> the PLL in an non lockable state.
>
> Fixes: 202b9808f8ed ("drm/meson: Add G12A
1 - 100 of 225 matches
Mail list logo
