[PATCH 5/7] arm64: dts: renesas: eagle: Enable DU

Enable DU for Renesas R-Car V3M Eagle board. Signed-off-by: Jacopo Mondi --- arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts

Re: [PATCH v4] drm/i915/dp: Send DPCD ON for MST before phy_up

On Fri, 2018-04-06 at 14:52 -0400, Lyude Paul wrote: > When doing a modeset where the sink is transitioning from D3 to D0 , it > would sometimes be possible for the initial power_up_phy() to start > timing out. This would only be observed in the last action before the > sink went into D3 mode

[PATCH v2.1 09/15] v4l: vsp1: Move DRM pipeline output setup code to a function

In order to make the vsp1_du_setup_lif() easier to read, and for symmetry with the DRM pipeline input setup, move the pipeline output setup code to a separate function. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham

[PATCH v7 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

Document Thine THC63LVD1024 LVDS decoder device tree bindings. Signed-off-by: Jacopo Mondi Reviewed-by: Andrzej Hajda Reviewed-by: Niklas Söderlund Reviewed-by: Laurent Pinchart

[PATCH 4/7] arm64: dts: renesas: r8a77970: add the LVDS instance

From: Niklas Söderlund Add the LVDS device to r8a77970.dtsi in a disabled state. Also connect the it to the LVDS output of the DU. While at it align the endpoint name of the du to du_out_lvds0 which is used in other Renesas DTS files to describe this link.

[PATCH v7 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge

Hello, this new version moves the driver and its bindings to use semi-standard names for powerdown and output enable GPIOs, as result of the discussion with Laurent, Vladimir and Rob. I kept the actual pin names in the bindings description for reference, even if there are no huge ambiguities

[PATCH 7/7] arm64: dts: renesas: eagle: Add ADV7511W and HDMI output

From: Niklas Söderlund Enable HDMI output adding the HDMI connector and the ADV7511W, connected to THC63LVD1024 LVDS decoder output. Signed-off-by: Niklas Söderlund Signed-off-by: Jacopo Mondi

Re: [RfC PATCH] Add udmabuf misc device

On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko wrote: > On 04/06/2018 02:57 PM, Gerd Hoffmann wrote: > > Hi, > > > >>>I fail to see any common ground for xen-zcopy and udmabuf ... > >>Does the above mean you can assume that xen-zcopy and udmabuf > >>can co-exist as two

RE: [PATCH 6/7] drm/vmwgfx: Stop using plane->fb in atomic_enable()

> > From: Ville Syrjälä > > Instead of looking at the (soon to be deprecated) plane->fb we'll > examing plane->state->fb instead. We can do this because > vmw_du_crtc_atomic_check() prevents us from enabling a crtc > without the primary plane also being enabled. >

RE: [PATCH 5/7] drm/vmwgfx: Stop updating plane->fb

This makes sense once we got rid of plane->fb Will this go to drm-next? Could you please CC me so that I can do some testing myself. Thanks. Reviewed-by: Deepak Rawat > > From: Ville Syrjälä > > We want to get rid of plane->fb on atomic

Re: [PATCH v4] drm/i915/dp: Send DPCD ON for MST before phy_up

On Fri, 2018-04-06 at 12:48 -0700, Laura Abbott wrote: > On 04/06/2018 11:52 AM, Lyude Paul wrote: > > When doing a modeset where the sink is transitioning from D3 to D0 , it > > would sometimes be possible for the initial power_up_phy() to start > > timing out. This would only be observed in the

[PATCH v4] drm/i915/dp: Send DPCD ON for MST before phy_up

When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial power_up_phy() to start timing out. This would only be observed in the last action before the sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought

Re: AMD graphics performance regression in 4.15 and later

Hi Christian, On 04/09/2018 07:48 AM, Christian König wrote: > Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin: >> Hi Christian, >> >> Is there a way to turn off these huge pages at boot-time/run-time? > > Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE. Any reason why echo never

[PATCH v7 2/2] drm: bridge: Add thc63lvd1024 LVDS decoder driver

Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel output converter. Signed-off-by: Jacopo Mondi Reviewed-by: Andrzej Hajda Reviewed-by: Niklas Söderlund ---

[PATCH 2/7] arm64: dts: renesas: r8a77970: add VSPD support

From: Sergei Shtylyov Describe VSPD0 in the R8A77970 device tree; it will be used by DU in the next patch... Based on the original (and large) patch by Daisuke Matsushita . Signed-off-by: Vladimir Barinov

[PATCH 2/2] media: omapfb: relax compilation if COMPILE_TEST

The dependency of DRM_OMAP = n can be relaxed for just compilation test. This allows building the omap3isp driver with allyesconfig on ARM. Signed-off-by: Mauro Carvalho Chehab --- drivers/video/fbdev/omap2/omapfb/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 3/7] arm64: dts: renesas: r8a77970: add DU support

From: Sergei Shtylyov Define the generic R8A77970 part of the DU device node. Based on the original (and large) patch by Daisuke Matsushita . Signed-off-by: Vladimir Barinov

[PATCH 1/7] arm64: dts: renesas: r8a77970: add FCPVD support

From: Sergei Shtylyov Describe FCPVD0 in the R8A77970 device tree; it will be used by VSPD0 in the next patch... Based on the original (and large) patch by Daisuke Matsushita . Signed-off-by: Vladimir Barinov

RE: [PATCH 4/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_update_implicit_fb()

Reviewed-by: Deepak Rawat > > From: Ville Syrjälä > > The only caller of vmw_kms_update_implicit_fb() is the page_flip > hook which itself gets called with the plane mutex already held. > Hence we can look at plane->state safely. Toss in a

[Bug 105869] clang crashes when compiling OpenCL kernel

https://bugs.freedesktop.org/show_bug.cgi?id=105869 --- Comment #7 from Jan Vesely --- (In reply to Lyberta from comment #6) > I'm 100% sure it is PulseWave because that's the only kernel I use to one of > my programs and it still crashes at cl::Program::build. Is the

Re: [PATCH 5/7] drm/vmwgfx: Stop updating plane->fb

On Fri, Apr 06, 2018 at 07:14:51PM +, Deepak Singh Rawat wrote: > This makes sense once we got rid of plane->fb > > Will this go to drm-next? The plan is to push to drm-misc-next once we get all the ducks in a row. > Could you please CC > me so that I can do some testing myself. Thanks.

[Bug 105869] clang crashes when compiling OpenCL kernel

https://bugs.freedesktop.org/show_bug.cgi?id=105869 --- Comment #9 from Lyberta --- Created attachment 138664 --> https://bugs.freedesktop.org/attachment.cgi?id=138664=edit OpenCL dump.link-0.ll -- You are receiving this mail because: You are the assignee for the

[Bug 105869] clang crashes when compiling OpenCL kernel

https://bugs.freedesktop.org/show_bug.cgi?id=105869 --- Comment #10 from Lyberta --- Created attachment 138665 --> https://bugs.freedesktop.org/attachment.cgi?id=138665=edit OpenCL dump.ll -- You are receiving this mail because: You are the assignee for the

[PATCH 6/7] arm64: dts: renesas: eagle: Add LVDS decoder

The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS decoder, connected to the on-chip LVDS encoder output on one side and to the not-yet-described HDMI encoder ADV7511W on the other one. As the decoder does not need any configuration it has been so-far omitted from DTS. Now that a

[PATCH v7 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge

Hello, this series enables HDMI display on V3M Eagle board. The series is based on Geert's "renesas-drivers-2018-04-03-v4.16" with THC63LVD1024 driver on top (cfr. my in review series: "[PATCH v7 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge") This series includes some preliminary

Re: [PATCH 1/7] drm/arc: Stop consulting plane->fb

Hi Ville, On Thu, 2018-04-05 at 22:50 +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We want to stop using plane->fb with atomic driver, so stop looking at > it. > > I have no idea what this code is trying to achieve. There is no > corresponding check in

Re: AMD graphics performance regression in 4.15 and later

Hi Christian, Is there a way to turn off these huge pages at boot-time/run-time? Right now the recent kernels are making Firefox pretty much unusable for me. I've been able to revert the patch from 4.15 but it's not really a long-term solution. You mention that the purpose of the patch is to

Re: [PATCH v2 15/19] omap2: omapfb: allow building it with COMPILE_TEST

Hi Mauro, I love your patch! Perhaps something to improve: [auto build test WARNING on linuxtv-media/master] [also build test WARNING on v4.16 next-20180406] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

[Bug 105869] clang crashes when compiling OpenCL kernel

https://bugs.freedesktop.org/show_bug.cgi?id=105869 --- Comment #8 from Lyberta --- Created attachment 138663 --> https://bugs.freedesktop.org/attachment.cgi?id=138663=edit OpenCL dump.cl -- You are receiving this mail because: You are the assignee for the

Re: [PATCH 8/8] drm/arm/malidp: Added the late system pm functions

On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote: > On Tue, Mar 27, 2018 at 11:59 AM, Ayan Halder wrote: > > On Tue, Mar 27, 2018 at 10:29:03AM +0200, Daniel Vetter wrote: > >> On Mon, Mar 26, 2018 at 06:03:20PM +0100, Ayan Kumar Halder wrote: > >> >

Re: [PATCH v4] drm/i915/dp: Send DPCD ON for MST before phy_up

On Fri, Apr 06, 2018 at 12:28:30PM -0700, Dhinakaran Pandiyan wrote: > > > > On Fri, 2018-04-06 at 14:52 -0400, Lyude Paul wrote: > > When doing a modeset where the sink is transitioning from D3 to D0 , it > > would sometimes be possible for the initial power_up_phy() to start > > timing out.

Re: [PATCH v4] drm/i915/dp: Send DPCD ON for MST before phy_up

On 04/06/2018 11:52 AM, Lyude Paul wrote: When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial power_up_phy() to start timing out. This would only be observed in the last action before the sink went into D3 mode was

[PATCH v2.1 06/15] v4l: vsp1: Move DRM atomic commit pipeline setup to separate function

The DRM pipeline setup code used at atomic commit time is similar to the setup code used when enabling the pipeline. Move it to a separate function in order to share it. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham

[PATCH] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

crtc_queue_syncobj creates a new syncobj that will get signaled at a specified vblank sequence count. crtc_get_syncobj returns the time and vblank sequence count when the syncobj was signaled. The pair of these allows use of syncobjs instead of events for monitoring vblank activity.

[PATCH 0/1] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

(This is an RFC on whether this pair of ioctls seems reasonable. The code compiles, but I haven't tested it as I'm away from home this weekend.) I'm rewriting my implementation of the Vulkan EXT_display_control extension, which provides a way to signal a Vulkan fence at vblank time. I had

Re: [PATCH] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

On Fri, Apr 6, 2018 at 4:56 PM, Keith Packard wrote: > crtc_queue_syncobj creates a new syncobj that will get signaled at a > specified vblank sequence count. > > crtc_get_syncobj returns the time and vblank sequence count when the > syncobj was signaled. > > The pair of these

[Bug 105934] Gpu Hang after two compute dispatches on Intel HD 5500

https://bugs.freedesktop.org/show_bug.cgi?id=105934 Bug ID: 105934 Summary: Gpu Hang after two compute dispatches on Intel HD 5500 Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status:

[PATCH v5] drm/i915/dp: Send DPCD ON for MST before phy_up

When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial power_up_phy() to start timing out. This would only be observed in the last action before the sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought

[Bug 104391] DC R9 285 HDMI audio regression since drm/amd/display: try to find matching audio inst for enc inst first

https://bugs.freedesktop.org/show_bug.cgi?id=104391 Charlene changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment

Re: [PATCH] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

Jason Ekstrand writes: > Is the given sequence number guaranteed to be hit in finite time? Certainly, it's a finite value... However, realistically, it's just like all of the other vblank interfaces where you can specify a crazy sequence and block for a very long time.

Re: [PATCH] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

On Fri, Apr 6, 2018 at 7:51 PM, Keith Packard wrote: > Jason Ekstrand writes: > > > Is the given sequence number guaranteed to be hit in finite time? > > Certainly, it's a finite value... > > However, realistically, it's just like all of the other vblank

Re: [Intel-gfx] [PATCH 11/13] drm/omapdrm: Nuke omap_framebuffer_get_next_connector()

On 05/04/18 19:50, Daniel Vetter wrote: > On Thu, Apr 05, 2018 at 06:13:58PM +0300, Ville Syrjala wrote: >> From: Ville Syrjälä >> >> omap_framebuffer_get_next_connector() uses plane->fb which we want to >> deprecate for atomic drivers. As

Re: [PATCH v2] Add udmabuf misc device

Am 06.04.2018 um 11:33 schrieb Gerd Hoffmann: Hi, The pages backing a DMA-buf are not allowed to move (at least not without a patch set I'm currently working on), but for certain MM operations to work correctly you must be able to modify the page tables entries and move the pages backing

Re: [PATCH v7 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge

Sorry for the mess subject should have been Subject: [PATCH 0/7] V3M-Eagle display enablement I copied the wrong one from another cover letter... On Fri, Apr 06, 2018 at 03:08:05PM +0200, Jacopo Mondi wrote: > Hello, >this series enables HDMI display on V3M Eagle board. > > The series

Re: [PATCH 3/4] drm/virtio: remove drm_dev_set_unique workaround

Hi, > What I could see as justified is a loud comment in drm_virtio_init(), > just above the call to drm_dev_set_unique(), explaining why it is > necessary to set "unique" manually. The reason is that virtio-vga > technically has "virtio_bus", not "pci_bus_type", for bus type, and so > the

Re: [PATCH 3/4] drm/virtio: remove drm_dev_set_unique workaround

On 04/04/18 19:29, Laszlo Ersek wrote: > Hi Emil, > > On 04/03/18 19:13, Emil Velikov wrote: >> On 29 March 2018 at 12:17, Laszlo Ersek wrote: >>> On 03/28/18 16:35, Emil Velikov wrote: On 28 March 2018 at 11:27, Laszlo Ersek wrote: > On 03/28/18

Re: [PATCH v7 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

Hi Jacopo, Thank you for the patch. On Friday, 6 April 2018 15:41:56 EEST Jacopo Mondi wrote: > Document Thine THC63LVD1024 LVDS decoder device tree bindings. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Andrzej Hajda > Reviewed-by: Niklas

Re: [PATCH v7 2/2] drm: bridge: Add thc63lvd1024 LVDS decoder driver

Hi Jacopo, Thank you for the patch. On Friday, 6 April 2018 15:41:57 EEST Jacopo Mondi wrote: > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel > output converter. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Andrzej Hajda

Re: [PATCH 10/10] drm/msm/gpu: Add the buffer objects from the submit to the crash dump

Hi Jordan, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on robclark/msm-next] [also build test WARNING on next-20180406] [cannot apply to v4.16] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [RfC PATCH] Add udmabuf misc device

On 04/06/2018 02:57 PM, Gerd Hoffmann wrote: Hi, I fail to see any common ground for xen-zcopy and udmabuf ... Does the above mean you can assume that xen-zcopy and udmabuf can co-exist as two different solutions? Well, udmabuf route isn't fully clear yet, but yes. See also gvt (intel

Re: [PATCH 3/4] drm/virtio: remove drm_dev_set_unique workaround

Hi Laszlo, On 6 April 2018 at 13:15, Laszlo Ersek wrote: > On 04/04/18 19:29, Laszlo Ersek wrote: >> Hi Emil, >> >> On 04/03/18 19:13, Emil Velikov wrote: >>> On 29 March 2018 at 12:17, Laszlo Ersek wrote: On 03/28/18 16:35, Emil Velikov wrote: >

Re: AMD graphics performance regression in 4.15 and later

Hi Jean, yeah, that is a known problem. Using huge pages improves the performance because of better TLB usage, but for the cost of higher allocation overhead. What we found is that firefox is doing something rather strange by allocating large textures and then just trowing them away again

Re: [RfC PATCH] Add udmabuf misc device

On 04/06/2018 12:07 PM, Gerd Hoffmann wrote: Hi, * The general interface should be able to express sharing from any guest:guest, not just guest:host. Arbitrary G:G sharing might be something some hypervisors simply aren't able to support, but the userspace API itself

Re: [PATCH 3/9] drm/tve200: Use simple_display_pipe prepare_fb helper

On Thu, Apr 5, 2018 at 5:44 PM, Daniel Vetter wrote: > Signed-off-by: Daniel Vetter > Cc: Linus Walleij Elegant! Reviewed-by: Linus Walleij Yours, Linus Walleij

Re: [PATCH 02/10] drm: drm_printer: Add printer for devcoredump

Quoting Jordan Crouse (2018-04-05 23:00:48) > +struct drm_print_iterator { > + void *data; > + > + ssize_t start; > + ssize_t offset; > + ssize_t remain; > +}; Neat, we should be able to use to replace struct drm_i915_error_state_buf (or at least the seq_file side). -Chris

Re: [PATCH 02/10] drm: drm_printer: Add printer for devcoredump

Quoting Chris Wilson (2018-04-06 11:42:25) > Quoting Jordan Crouse (2018-04-05 23:00:48) > > +struct drm_print_iterator { > > + void *data; > > + > > + ssize_t start; > > + ssize_t offset; > > + ssize_t remain; > > +}; > > Neat, we should be able to use to replace struct >

Re: [RfC PATCH] Add udmabuf misc device

On Fri, Apr 06, 2018 at 10:52:21AM +0100, Daniel Stone wrote: > Hi Gerd, > > On 14 March 2018 at 08:03, Gerd Hoffmann wrote: > >> Either mlock account (because it's mlocked defacto), and get_user_pages > >> won't do that for you. > >> > >> Or you write the full-blown userptr

Re: [PATCH 04/10] drm/msm/gpu: Convert the GPU show function to use the GPU state

Quoting Jordan Crouse (2018-04-05 23:00:50) > diff --git a/drivers/gpu/drm/msm/msm_debugfs.c > b/drivers/gpu/drm/msm/msm_debugfs.c > index ba74cb4f94df..fd535dab3d5b 100644 > --- a/drivers/gpu/drm/msm/msm_debugfs.c > +++ b/drivers/gpu/drm/msm/msm_debugfs.c > @@ -25,13 +25,22 @@ static int

[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

https://bugzilla.kernel.org/show_bug.cgi?id=199101 Paweł (pawel.p...@gmail.com) changed: What|Removed |Added CC||pawel.p...@gmail.com ---

Re: [RfC PATCH] Add udmabuf misc device

On 04/06/2018 12:07 PM, Gerd Hoffmann wrote: I'm not sure we can create something which works on both kvm and xen. The memory management model is quite different ... On xen the hypervisor manages all memory. Guests can allow other guests to access specific pages (using grant tables). In

Re: [RfC PATCH] Add udmabuf misc device

Hi, > > I fail to see any common ground for xen-zcopy and udmabuf ... > Does the above mean you can assume that xen-zcopy and udmabuf > can co-exist as two different solutions? Well, udmabuf route isn't fully clear yet, but yes. See also gvt (intel vgpu), where the hypervisor interface is

Re: [Intel-gfx] [Freedreno] [PATCH 01/10] include: Move ascii85 functions from i915 to linux/ascii85.h

Quoting Jordan Crouse (2018-04-05 23:06:53) > On Thu, Apr 05, 2018 at 04:00:47PM -0600, Jordan Crouse wrote: > > The i915 DRM driver very cleverly used ascii85 encoding for their > > GPU state file. Move the encode functions to a general header file to > > support other drivers that might be

Re: [PATCH 03/10] drm/msm/gpu: Capture the state of the GPU

Quoting Jordan Crouse (2018-04-05 23:00:49) > +struct msm_gpu_state { > + struct timeval time; My recommendation would be to make this a kreffed struct. You already have multiple uncoordinated consumers so managing the lifetime would seem to be a point of concern? -Chris

Re: GPU/DRM issue with DSI commands on msm 8916

Hi, On Thursday 05 April 2018 08:28 PM, Daniel Mack wrote: Hi, I'm having issues with the GPU/DRM drivers on a msm8916 based platform which is very similar to the DragonBoard 410c. In my setup, a DSI display is directly connected to the SoC, and the video link is stable. However, when the

Re: [PATCH 1/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 04/03/2018 12:47 PM, Daniel Vetter wrote: On Thu, Mar 29, 2018 at 04:19:31PM +0300, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko +static int to_refs_grant_foreign_access(struct xen_gem_object *xen_obj) +{ + grant_ref_t priv_gref_head;

Re: [RfC PATCH] Add udmabuf misc device

On 04/06/2018 03:11 AM, Matt Roper wrote: On Thu, Apr 05, 2018 at 10:32:04PM +0200, Daniel Vetter wrote: Pulling this out of the shadows again. We now also have xen-zcopy from Oleksandr and the hyper dmabuf stuff from Matt and Dongwong. At least from the intel side there seems to be the idea

Re: [PATCH 0/9] implicit fencing clarification

Hi, Daniel! It seems that this series misses xen-front's "Use simple_display_pipe prepare_fb helper" change? Thank you, Oleksandr On 04/05/2018 06:44 PM, Daniel Vetter wrote: Hi all, Somewhat motivated (but only really tangentially) by the dirtyfb discussion with Rob and Thomas I started

Re: AMD graphics performance regression in 4.15 and later

Hi Jean, found the bug reports. Here is the original bug report from the kernel: https://bugzilla.kernel.org/show_bug.cgi?id=198511 And here is an fdo bug report where we tried to investigate the root cause, but didn't had time for that yet:

[Bug 105911] DVI-D monitor connected to DVI-I output not detected (regression from kernel 4.14.32 to kernel 4.16.0 using graphic core)

https://bugs.freedesktop.org/show_bug.cgi?id=105911 --- Comment #6 from Matthias Nagel --- (In reply to Michel Dänzer from comment #5) > Note that with the 4.16 kernel, Xorg doesn't use the xorg.conf Section > Monitor for the second DVI output, because it has a

Re: [RfC PATCH] Add udmabuf misc device

Hi Gerd, On 14 March 2018 at 08:03, Gerd Hoffmann wrote: >> Either mlock account (because it's mlocked defacto), and get_user_pages >> won't do that for you. >> >> Or you write the full-blown userptr implementation, including mmu_notifier >> support (see i915 or amdgpu), but

Re: [PATCH 07/10] drm/msm/adreno: Convert the show/crash file format

Quoting Jordan Crouse (2018-04-05 23:00:53) > Convert the format of the 'show' debugfs file and the crash > dump to a format resembling YAML. This should be easier to > parse and be more flexible for future changes and expansions. > > Signed-off-by: Jordan Crouse +1,

Re: [PATCH v2 15/19] omap2: omapfb: allow building it with COMPILE_TEST

Hi Mauro, I love your patch! Perhaps something to improve: [auto build test WARNING on linuxtv-media/master] [also build test WARNING on v4.16 next-20180406] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

[Bug 105911] DVI-D monitor connected to DVI-I output not detected (regression from kernel 4.14.32 to kernel 4.16.0 using graphic core)

https://bugs.freedesktop.org/show_bug.cgi?id=105911 Michel Dänzer changed: What|Removed |Added CC|

[Bug 105911] DVI-D monitor connected to DVI-I output not detected (regression from kernel 4.14.32 to kernel 4.16.0 using graphic core)

https://bugs.freedesktop.org/show_bug.cgi?id=105911 --- Comment #7 from Michel Dänzer --- (In reply to Matthias Nagel from comment #6) > > BTW, does it still work with the 4.16 kernel and amdgpu.dc=0? > > Yes it does. (But of course with a wrong layout, because DVI-I is

Re: [PATCH v2 15/19] omap2: omapfb: allow building it with COMPILE_TEST

On 05/04/18 23:29, Mauro Carvalho Chehab wrote: > This driver builds cleanly with COMPILE_TEST, and it is > needed in order to allow building drivers/media omap2 > driver. > > So, change the logic there to allow building it. > > Signed-off-by: Mauro Carvalho Chehab >

[radeon-alex:drm-next-4.18-wip 21/83] drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2725:1: warning: the frame size of 1028 bytes is larger than 1024 bytes

tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.18-wip head: 18f0a58d75166238d433efce0215b078d0b38e25 commit: 16052f0791cc439eefc9fdfb784db44044ad948e [21/83] drm/amd/display: fix Polaris 12 bw bounding box config: i386-randconfig-b0-04061423 (attached as .config) compiler:

Re: [PATCH 3/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()

/0day-ci/linux/commits/Ville-Syrjala/drm-arc-Stop-consulting-plane-fb/20180406-155056 base: git://people.freedesktop.org/~airlied/linux.git drm-next config: x86_64-randconfig-x010-201813 (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config

[Bug 105911] DVI-D monitor connected to DVI-I output not detected (regression from kernel 4.14.32 to kernel 4.16.0 using graphic core)

https://bugs.freedesktop.org/show_bug.cgi?id=105911 --- Comment #8 from Matthias Nagel --- > Really? It's surprising that the output name would change even with DC > disabled. Sorry, my fault. I tampered with the xorg.conf to match it the new naming with DC enabled.

Re: [RfC PATCH] Add udmabuf misc device

Hi, > > * The general interface should be able to express sharing from any > > guest:guest, not just guest:host. Arbitrary G:G sharing might be > > something some hypervisors simply aren't able to support, but the > > userspace API itself shouldn't make assumptions or restrict

Re: [PATCH v2] Add udmabuf misc device

Hi, > The pages backing a DMA-buf are not allowed to move (at least not without a > patch set I'm currently working on), but for certain MM operations to work > correctly you must be able to modify the page tables entries and move the > pages backing them around. > > For example try to use

AMD graphics performance regression in 4.15 and later

Hi, I noticed a serious graphics performance regression between 4.14 and 4.15. It is most noticeable with Firefox (tried FF57 through FF60) and causes scrolling to be really choppy/sluggish. I've confirmed that the problem is also there on 4.16, while 4.13 works fine. After a bisection, I've

Re: [PATCH 2/9] drm: Move simple_display_pipe prepare_fb helper into gem fb helpers

Den 05.04.2018 17.44, skrev Daniel Vetter: There's nothing tinydrm specific to this, and there's a few more copies of the same in various other drivers. Signed-off-by: Daniel Vetter Cc: Gustavo Padovan Cc: Maarten Lankhorst

[Bug 99403] Graphical glitches in witcher-1 with wine nine and r600g (rv740).

https://bugs.freedesktop.org/show_bug.cgi?id=99403 --- Comment #7 from i...@yahoo.com --- It's not driver specific bug. I should have followed the hint that there is a registry entry to workaround this problem with wined3d. It turns out that this registry entry is specifically for this bug. The

Re: [PATCH] drm: clarify adjusted_mode for a bridge connected to a crtc

Hi Laurent, On 04/06/2018 04:53 PM, Laurent Pinchart wrote: > Hi Philippe, > > Thank you for the patch. > > On Monday, 26 February 2018 14:16:04 EEST Philippe Cornu wrote: >> This patch clarifies the adjusted_mode documentation >> for a bridge directly connected to a crtc. >> >> Signed-off-by:

Re: [PATCH 5/7] arm64: dts: renesas: eagle: Enable DU

Hi again, On Friday, 6 April 2018 16:45:16 EEST Laurent Pinchart wrote: > On Friday, 6 April 2018 16:08:10 EEST Jacopo Mondi wrote: > > Enable DU for Renesas R-Car V3M Eagle board. > > > > Signed-off-by: Jacopo Mondi > > --- > > > >

[Bug 105911] DVI-D monitor connected to DVI-I output not detected (regression from kernel 4.14.32 to kernel 4.16.0 using graphic core)

https://bugs.freedesktop.org/show_bug.cgi?id=105911 --- Comment #9 from Harry Wentland --- Can you capture the 4.16 dmesg with DC again with the amdgpu.dc_log=1 module option? Do you see any activity on dmesg with dc_log=1 when you hotplug the non-detected display? --

Re: [PATCH 7/7] arm64: dts: renesas: eagle: Add ADV7511W and HDMI output

Hi Laurent, On Fri, Apr 06, 2018 at 04:51:11PM +0300, Laurent Pinchart wrote: > Hi Jacopo, > > Thank you for the patch. > > On Friday, 6 April 2018 16:08:12 EEST Jacopo Mondi wrote: > > From: Niklas Söderlund > > > > Enable HDMI output adding the HDMI

Re: AMD graphics performance regression in 4.15 and later

Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin: Hi Christian, Is there a way to turn off these huge pages at boot-time/run-time? Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE. Alternatively you can avoid enabling CONFIG_SWIOTLB which will avoid the slow DMA path as well.

Re: [PATCH v7 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

Hi Jacopo, (CC'ing Mark Brown) On Friday, 6 April 2018 17:25:58 EEST jacopo mondi wrote: > On Fri, Apr 06, 2018 at 04:15:35PM +0300, Laurent Pinchart wrote: > > On Friday, 6 April 2018 15:41:56 EEST Jacopo Mondi wrote: > >> Document Thine THC63LVD1024 LVDS decoder device tree bindings. > >> >

Re: [PATCH 2/7] arm64: dts: renesas: r8a77970: add VSPD support

On Friday, 6 April 2018 16:08:07 EEST Jacopo Mondi wrote: > From: Sergei Shtylyov > > Describe VSPD0 in the R8A77970 device tree; it will be used by DU in > the next patch... > > Based on the original (and large) patch by Daisuke Matsushita >

Re: [PATCH 4/7] arm64: dts: renesas: r8a77970: add the LVDS instance

Hi Jacopo, Thank you for the patch. On Friday, 6 April 2018 16:08:09 EEST Jacopo Mondi wrote: > From: Niklas Söderlund > > Add the LVDS device to r8a77970.dtsi in a disabled state. Also connect > the it to the LVDS output of the DU. While at it align the

[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

https://bugzilla.kernel.org/show_bug.cgi?id=199101 --- Comment #15 from Harry Wentland (harry.wentl...@amd.com) --- We reproduced the issue and have someone looking into it. -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH 2/2 v2] drm/pl111: Enable device-specific assigned memory

The Versatile Express has 8 MB of dedicated video RAM (VRAM) on the motherboard, which is what we should be using for the PL111 if available. On this platform, the memory backplane is constructed so that only this memory will work properly with the CLCD on the motherboard, using any other memory

[PATCH 1/2 v2] drm/pl111: Support the Versatile Express

The Versatile Express uses a special configuration controller deeply embedded in the system motherboard FPGA to multiplex the two to three (!) CLCD instances out to the single SiI9022 bridge. Set up an extra file with the logic to probe to the FPGA mux register on the system controller bus, then

Re: [PATCH 6/7] arm64: dts: renesas: eagle: Add LVDS decoder

Hi Jacopo, Thank you for the patch. On Friday, 6 April 2018 16:08:11 EEST Jacopo Mondi wrote: > The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS > decoder, connected to the on-chip LVDS encoder output on one side > and to the not-yet-described HDMI encoder ADV7511W on the other

Re: [PATCH v7 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge

Hi Jacopo, On Friday, 6 April 2018 16:08:05 EEST Jacopo Mondi wrote: > Hello, >this series enables HDMI display on V3M Eagle board. > > The series is based on Geert's "renesas-drivers-2018-04-03-v4.16" with > THC63LVD1024 driver on top (cfr. my in review series: > "[PATCH v7 0/2] drm: Add

Re: [PATCH v7 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge

Hi Laurent, On Fri, Apr 06, 2018 at 04:53:43PM +0300, Laurent Pinchart wrote: > Hi Jacopo, > > On Friday, 6 April 2018 16:08:05 EEST Jacopo Mondi wrote: > > Hello, > >this series enables HDMI display on V3M Eagle board. > > > > The series is based on Geert's "renesas-drivers-2018-04-03-v4.16"

Re: [PATCH 3/7] arm64: dts: renesas: r8a77970: add DU support

Hi Jacopo, Thank you for the patch. On Friday, 6 April 2018 16:08:08 EEST Jacopo Mondi wrote: > From: Sergei Shtylyov > > Define the generic R8A77970 part of the DU device node. > > Based on the original (and large) patch by Daisuke Matsushita >

Re: [PATCH 1/7] arm64: dts: renesas: r8a77970: add FCPVD support

Hi Jacopo, Thank you for the patch. On Friday, 6 April 2018 16:08:06 EEST Jacopo Mondi wrote: > From: Sergei Shtylyov > > Describe FCPVD0 in the R8A77970 device tree; it will be used by VSPD0 in > the next patch... > > Based on the original (and large)

Re: [PATCH 5/7] arm64: dts: renesas: eagle: Enable DU

Hi Jacopo, Thank you for the patch. On Friday, 6 April 2018 16:08:10 EEST Jacopo Mondi wrote: > Enable DU for Renesas R-Car V3M Eagle board. > > Signed-off-by: Jacopo Mondi > --- > arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 11 +++ > 1 file changed, 11

  1   2   >