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
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
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
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
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
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.
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
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
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
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
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
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
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:
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=109022
--- Comment #22 from e88z4 ---
Created attachment 144472
--> https://bugs.freedesktop.org/attachment.cgi?id=144472=edit
apitrace log
Hi,
I attached the apitrace log being written to my standard output while replaying
my apitrace file in my
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:
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!
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
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
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
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=edit
Script to modify packages to be able to use with ubuntu 19.04
Initial version
--
You are receiving this mail
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://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
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
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
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
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
---
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
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
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
---
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.
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
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
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
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:
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:
> > >
> > >
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
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:
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.
> >
> >
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=edit
r300g: implement glsl shader caching.
And here's a preliminary patch. If it looks good enough to you, I'll send
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
>
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
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
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
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).
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,
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
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
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
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
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
>
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
>
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
> ---
>
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
>
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
> ---
>
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
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
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
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(+)
>
>
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: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
> ---
>
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.
>
>
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
___
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
On Thu, 6 Jun 2019 at 16:58, Ilia Mirkin wrote:
>
> On Thu, Jun 6, 2019 at 11:51 AM Emil Velikov wrote:
> >
> > On Mon, 3 Jun 2019 at 01:40, Ilia Mirkin wrote:
> > >
> > > Signed-off-by: Ilia Mirkin
> > > ---
> > > tests/modetest/modetest.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2
On Thu, Jun 6, 2019 at 11:51 AM Emil Velikov wrote:
>
> On Mon, 3 Jun 2019 at 01:40, Ilia Mirkin wrote:
> >
> > Signed-off-by: Ilia Mirkin
> > ---
> > tests/modetest/modetest.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tests/modetest/modetest.c
On Thu, 6 Jun 2019 at 16:54, Emil Velikov wrote:
>
> On Mon, 3 Jun 2019 at 01:40, Ilia Mirkin wrote:
> >
> > This series improves the pattern generation logic to support additional
> > formats, as well as a new "gradient" pattern (see patch comments on why
> > I found it useful).
> >
> >
On Mon, 3 Jun 2019 at 01:40, Ilia Mirkin wrote:
>
> This series improves the pattern generation logic to support additional
> formats, as well as a new "gradient" pattern (see patch comments on why
> I found it useful).
>
> Furthermore, these formats are piped through to modetest, including the
>
On Mon, 3 Jun 2019 at 01:40, Ilia Mirkin wrote:
>
> Signed-off-by: Ilia Mirkin
> ---
> tests/modetest/modetest.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index 9c85c07b..a1c81f6c 100644
> ---
Hi Daniel,
Thanks for the patch, and for the great explanation embedded to it.
I tested it here, and everything worked like a charm.
Is it ok if I push it to drm-misc?
Tested-by: Rodrigo Siqueira
Reviewed-by: Rodrigo Siqueira
On 06/06, Daniel Vetter wrote:
> In
>
> commit
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 -mm merged the basic hmm API skeleton I think running like
> > > this would get us
Le mer. 5 juin 2019 à 15:48, Sam Ravnborg a écrit :
>
> Stop using the deprecated drmP.h header file.
> Replaced with relevant forwards or headers files.
> Header files sorted in all files touched.
>
> Build tested with allyesconfig, allmodconfig for a number of
> architectures.
Applied on
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #46 from Talha Khan ---
Thanks for the update Ondrej. It seems that the patch may be in place. Since
I've updated my Fedora 30 system's kernel to 5.1.6, I haven't had to run dracut
to rebuild my initramfs. The raven_dmcu.bin file
Hi,
On 06/06/2019 13:58, 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 render
nodes, thus we can drop
Hi,
We observed the following error on an i.MX6D+ CPU during start of X.
As a result, the screen goes blank.
---
[ 3599.200886] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR*
[CRTC:30:crtc-0] flip_done timed out
[ 3610.080885] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
Enable the CMM units through the display unit extensional function control
group register DEFR7.
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_group.c | 8
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 +
2 files changed, 13 insertions(+)
diff --git
Add clock definitions for CMM units on Renesas R-Car Gen3 D3.
Signed-off-by: Jacopo Mondi
---
drivers/clk/renesas/r8a77995-cpg-mssr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/renesas/r8a77995-cpg-mssr.c
b/drivers/clk/renesas/r8a77995-cpg-mssr.c
index
Add clock definitions for CMM units on Renesas R-Car Gen3 E3.
Signed-off-by: Jacopo Mondi
---
drivers/clk/renesas/r8a77990-cpg-mssr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/renesas/r8a77990-cpg-mssr.c
b/drivers/clk/renesas/r8a77990-cpg-mssr.c
index
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-off-by: Jacopo Mondi
---
Documentation/devicetree/bindings/display/renesas,du.txt | 5 +
1 file changed,
1 - 100 of 212 matches
Mail list logo
