[GIT PULL FOR v4.8] R-Car DU fixes

Hi Dave, The following changes since commit a0877f52035280370707bdefeddc6faa6478b892: Merge tag 'topic/drm-misc-2016-06-15' of git://anongit.freedesktop.org/drm- intel into drm-next (2016-06-16 05:49:32 +1000) are available in the git repository at: git://linuxtv.org/pinchartl/media.git

[Bug 96600] [RV630]: a lot of artifacts appears on a screen playing some videos through VDPAU with hardware acceleration

. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/73f560e1/attachment.html>

[Bug 96600] [RV630]: a lot of artifacts appears on a screen playing some videos through VDPAU with hardware acceleration

org/archives/dri-devel/attachments/20160620/095335af/attachment.html>

[Intel-gfx] [PATCH 07/16] drm: Clean up drm_crtc.h

On Fri, Jun 17, 2016 at 08:53:11AM +0100, Chris Wilson wrote: > On Fri, Jun 17, 2016 at 09:33:25AM +0200, Daniel Vetter wrote: > > - Group declarations for separate files (drm_bridge.c, drm_edid.c) > > - Move declarations only used within drm.ko to drm_crtc_internal.h > > - drm_property_type_valid

[Intel-gfx] [PATCH] drm: fix send_vblank_event use-after-free error

On Mon, Jun 20, 2016 at 05:42:46PM +0100, Matthew Auld wrote: > The drm_pending_event can be freed by drm_send_event_locked, as a > result we should call trace_drm_vblank_event_delivered before this > to avoid hitting a user-after-free error when accessing the pid member: > > [ 378.438497] BUG:

[PATCH] i915/fbc: Disable on HSW by default for now

Em Sex, 2016-06-10 às 08:44 +0200, Stefan Richter escreveu: > On Jun 09 Zanoni, Paulo R wrote: > > > > Em Qui, 2016-06-09 às 11:58 -0400, Lyude escreveu: > > > > > > From https://bugs.freedesktop.org/show_bug.cgi?id=96461 : > > > > > > This was kind of a difficult bug to track down. If you're

[PATCH v3] drm/vgem: Enable dmabuf interface for export

Enable the standard GEM dma-buf interface provided by the DRM core, but only for exporting the VGEM object. This allows passing around the VGEM objects created from the dumb interface and using them as sources elsewhere. Creating a VGEM object for a foriegn handle is not supported. v2: With

[PATCH v3 1/3] dmabuf

On Mon, Jun 20, 2016 at 09:04:32PM +0100, Chris Wilson wrote: Eek, appologies. This was meant to git-send-email -v3 but mangled into -3 instead. -Chris -- Chris Wilson, Intel Open Source Technology Centre

[PATCH v3 3/3] meh

--- drivers/gpu/drm/i915/i915_debugfs.c| 162 +--- drivers/gpu/drm/i915/i915_drv.h| 84 ++--- drivers/gpu/drm/i915/i915_gem.c| 144 +++ drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +- drivers/gpu/drm/i915/i915_gem_request.c|

[PATCH v3 2/3] drm: Prevent NULL deref in drm_name_info()

If a driver does not have a parent, or never sets the unique name for itself, then we may proceed to chase a NULL dereference through debugfs/.../name. Testcase: igt/vgem_basic/debugfs Signed-off-by: Chris Wilson Cc: Daniel Vetter --- drivers/gpu/drm/drm_info.c | 21 ++--- 1

[PATCH v3 1/3] dmabuf

--- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/i915_gem_dmabuf.c index 49e7ff9840bd..c3f177231f6a 100644 --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c +++

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

ext part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/9348a018/attachment-0001.html>

[PATCH] drm: Prevent NULL deref in drm_name_info()

If a driver does not have a parent, or never sets the unique name for itself, then we may proceed to chase a NULL dereference through debugfs/.../name. Testcase: igt/vgem_basic/debugfs Signed-off-by: Chris Wilson Cc: Daniel Vetter --- drivers/gpu/drm/drm_info.c | 21 ++--- 1

[Bug 96602] [radeonsi] Dreamfall Chapters: one shader fails to compile, minor visual corruption

ng this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/4e11efc1/attachment-0001.html>

[PATCH 21/22] arm64: dts: msm8916: Add display support

On 6/20/2016 6:34 PM, Rob Herring wrote: > On Thu, Jun 16, 2016 at 05:06:46PM +0530, Archit Taneja wrote: >> The MSM8916 SoC contains a MDP5 based display block, and one DSI output. >> Add the top level MDSS DT node, and the MDP5, DSI and DSI PHY children >> sub-blocks. Establish the link

[Bug 92059] [radeonsi, apitrace] Missing textures and geometry in "Middle-earth: Shadow of Mordor"

ing this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/eddc6b50/attachment.html>

[PATCH 1/3] drm: Add callbacks for late registering

On Mon, Jun 20, 2016 at 04:30:36PM +0100, Chris Wilson wrote: > On Mon, Jun 20, 2016 at 05:22:55PM +0200, Benjamin Gaignard wrote: > > Like what has been done for connectors add callbacks on encoder, > > crtc and plane to let driver do actions after drm device registration. > > > >

[PATCH 3/3] drm: sti: rework init sequence

Hi Benjamin, On 20 June 2016 at 16:22, Benjamin Gaignard wrote: > + > + drm_dev_set_unique(ddev, dev_name(dev)); > + Daniel Vetter has a series in flight [1] which should make this obsolete (wrong actually). There were a couple of minor issues, but I'd expect it to be complete some time

[RFC PATCH 12/13] arm64: tegra: Add sor-safe clock to DPAUX binding

Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/77b38ced/attachment.sig>

[RFC PATCH 11/13] arm64: tegra: Add SOR power-domain node

gra124 and earlier the HDMI output is driven by a separate IP block that's not at all related to SOR, and I haven't found any evidence that it would be in the SOR power partition either. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/259513f5/attachment.sig>

[RFC PATCH 04/13] drm/tegra: Add sor-safe clock for DPAUX on Tegra210

egra124-dpaux", .data = > > _dpaux_soc }, > > { }, > > }; > > OK. I wonder if we should call it 'has_safe_clock' because this clock > does not exist for tegra124 AFAICT. #bikeshed ;-) has_safe_clock is fine with me, too. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/eb942b43/attachment.sig>

[PATCH 3/3] dma-buf: remove dma_buf_debugfs_create_file()

On 20 June 2016 at 15:31, Daniel Vetter wrote: > On Sun, Jun 19, 2016 at 02:31:31PM +0200, Mathias Krause wrote: >> [...] >> With no users left, we can remove dma_buf_debugfs_create_file(). >> >> While at it, simplify the error handling in dma_buf_init_debugfs() >> slightly. >> >> Signed-off-by:

[Bug 96600] [RV630]: a lot of artifacts appears on a screen playing some videos through VDPAU with hardware acceleration

are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/be41d398/attachment.html>

[PATCH 6/6] Documentation/DocBook: remove gpu.tmpl

The gpu documentation has now been converted to reStructuredText files under Documentation/gpu. Remove the obsolete DocBook template. Also remove it from MAINTAINERS. Good riddance. Signed-off-by: Jani Nikula --- Documentation/DocBook/Makefile |2 +- Documentation/DocBook/gpu.tmpl | 3528

[PATCH 5/6] Documentation/gpu: convert the KMS properties table to CSV

Pandoc really did a bad job of converting the big KMS properties table to RST. Instead, put the properties into a separate plain text CSV file, and include it in the RST file. The generated output isn't very pretty, but at least the information is there, and it's stored in a format that's easier

[PATCH 4/6] Documentation/gpu: use recommended order of heading markers

While splitting the document up, the headings "shifted" from what pandoc generated. Use the following order for headings for consistency: == Document title == First = Second -- Third ~ Leave the lower level headings as they are; I think those are less

[PATCH 3/6] MAINTAINERS: add Documentation/gpu and Documentation/gpu/i915.rst

We'll want to keep an eye on what's going on in these files. Signed-off-by: Jani Nikula --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index cb88f724e07c..ce9c23dd02c6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3857,6 +3857,7 @@ F:

[PATCH 2/6] Documentation/gpu: split up the gpu documentation

Make the gpu documentation easier to manage by splitting to separate files. Again, this is just the split, no real edits. Signed-off-by: Jani Nikula --- Documentation/gpu/drm-internals.rst | 1998 +++ Documentation/gpu/drm-userland-interfaces.rst | 91 +

[PATCH 1/6] Documentation/gpu: add new gpu.rst converted from DocBook gpu.tmpl

This is the first step towards converting the DocBook gpu.tmpl to Sphinx and reStructuredText, the new kernel documentation tool and markup. Use Jon's "cheesy conversion script" in Documentation/sphinx/tmplcvt to do the rough conversion. Do the manual edits in follow-up patches. Add a new

[PATCH 0/6] Documentation: convert DocBook gpu.tmpl to reStructuredText

Hi all, this series converts the DocBook gpu.tmpl to reStructuredText, now that we have Sphinx support merged to docs-next and drm-next. I haven't really touched the content, this is just a fairly mechanical conversion and split up of the document. I'm sure there are small issues here and there,

[PATCH] drm: fix send_vblank_event use-after-free error

The drm_pending_event can be freed by drm_send_event_locked, as a result we should call trace_drm_vblank_event_delivered before this to avoid hitting a user-after-free error when accessing the pid member: [ 378.438497] BUG: KASAN: use-after-free in send_vblank_event+0xf0/0x310 [drm] at addr

[Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

I guess at least > >> gallium and mali are doing the same thing. No idea if that is the > >> same thing that i965 does. > > > > Hi, > > > > Quentin did some tests for me, and the results are... not what I would > > have expected: > > https://phabricator.freedesktop.org/T7475#88454 > > > > RadeonSI works like Intel, but Nouveau does the opposite. I think the > > Nouveau way is correct by the spec, which makes everyone else (intel, > > radeonsi, weston-simple-dmabuf-v4l) get it wrong. Unfortunately, two > > wrongs make a right, so when weston-simple-dmabuf-v4l hardcodes Y_INVERT > > as set, it'll come out the right way on intel and radeon. > > oh, wow.. that seems quite odd that two different gallium drivers have > different results, since I'd have expected this to be completely > handled by mesa/st.. now I'm somewhat curious. Hi, after a head-scratching session on #dri-devel and a little bit on #wayland too, I'm ready to punt that off as a bad test. It is quite possible the machine running nouveau had a webcam that really produces upside-down images. weston-simple-dmabuf-v4l does not understand that. Apparently mpv OTOH does. How, maybe there is an answer in V4L2 API, but I haven't looked it up yet. If we look at the Vivid tests, the results are consistent and expected. All intel, nouveau and radeon work the same way. > > And it is wrong for weston-simple-dmabuf-v4l to set Y_INVERT, that I > > believe is clear. It is only there because of the "oops, it's > > upside-down" syndrome, AFAIK. > > > >> > After all, using GL with windows and FBOs and stuff you very often find > >> > yourself upside down, and I suspect people have got the habit of just > >> > flipping it if it does not look right the first time. See e.g. the > >> > row-order of data going into glTexImage2D... > >> > > >> > If the answer is "oops, well, dmabuf import is semantically y-flipping > >> > when it should not, but we cannot fix it because that would break > >> > everyone", I would be happy with that. I just want confirmation before > >> > flipping the flip flag. :-) > > > > So many bugs that accidentally counter each other... Seems like we can conclude this by saying that a dmabuf imported via EGL as a GL texture will have the origin at top-left, instead of what the GL spec says. Thanks, pq -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/62207ab8/attachment.sig>

[Bug 96588] [regression] [amdgpu] Errors scheduling IBs

TML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/6da0/attachment-0001.html>

[PATCH 3/3] drm: sti: rework init sequence

Use drm_dev_alloc() and drm_dev_register() instead of .load() To simplify init sequence only create fbdev when requested in output_poll_changed(). Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/sti/sti_drv.c | 140 + drivers/gpu/drm/sti/sti_drv.h

[PATCH 2/3] drm: sti: use late_register and early_unregister callbacks

Make sti driver use register callback to move debugfs initialization out of sub-components creation. This will allow to convert driver .load() to drm_dev_alloc() and drm_dev_register(). Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/sti/sti_compositor.c | 20

[PATCH 1/3] drm: Add callbacks for late registering

Like what has been done for connectors add callbacks on encoder, crtc and plane to let driver do actions after drm device registration. Correspondingly, add callbacks called before unregister drm device. Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/drm_drv.c | 42

[PATCH 0/3] Add callbacks for late registering

late_register() and early_unregister() callbacks have been introduced for connectors, let do the same for encoders, crcts and planes. Like for the previously introduced functions they are called right after drm device registration and before unregistration. Those new callbacks allow to defer

[PATCH 1/1] drm/amdgpu: initialize amdgpu_cgs_acpi_eval_object result value

On Sat, Jun 18, 2016 at 4:55 PM, Nicolas Iooss wrote: > amdgpu_cgs_acpi_eval_object() returned the value of variable "result" > without initializing it first. > > This bug has been found by compiling the kernel with clang. The > compiler complained: > >

[patch] drm/amdgpu: precedence bug in amdgpu_device_init()

On Sat, Jun 18, 2016 at 4:38 AM, Dan Carpenter wrote: > ! has higher precedence than bitwise & so we need to add parenthesis > for this to work as intended. > > Fixes: 048765ad5af7 ('amdgpu: fix asic initialization for virtualized > environments (v2)') > Signed-off-by: Dan Carpenter Applied.

[PATCH v2 3/3] drm/i915: Enable polling when we don't have hpd

As a forewarning: I have confirmed the CRT hpd loops Vsyrjala has mentioned, and they are triggered by this patch. I'm working on a patch for this atm. On Mon, 2016-06-20 at 16:57 -0400, Lyude wrote: > Unfortunately, there's two situations where we lose hpd right now: > - Runtime suspend > - When

[PATCH v2 3/3] drm/i915: Enable polling when we don't have hpd

Unfortunately, there's two situations where we lose hpd right now: - Runtime suspend - When we've shut off all of the power wells on Valleyview/Cherryview While it would be nice if this didn't cause issues, this has the ability to get us in some awkward states where a user won't be able to get

[RFC v3 4/5] drm/mediatek: add support for Mediatek SoC MT2701

Hi CK, Thanks for your comments. On Mon, 2016-06-13 at 13:56 +0800, CK Hu wrote: > Hi, YT: > > Some comments inline. > > On Thu, 2016-06-09 at 00:03 +0800, YT Shen wrote: > > This patch add support for the Mediatek MT2701 DISP subsystem. > > There is only one OVL engine in MT2701. > > > >

[RFC v3 3/5] drm/mediatek: add shadow register support

Hi CK, On Mon, 2016-06-13 at 14:43 +0800, CK Hu wrote: > Hi, YT: > > One comment inline. > > On Thu, 2016-06-09 at 00:03 +0800, YT Shen wrote: > > We need to acquire mutex before using the resources, > > and need to release it after finished. > > So we don't need to write registers in the

[PATCH 3/3] drm: sti: rework init sequence

On Mon, Jun 20, 2016 at 05:22:57PM +0200, Benjamin Gaignard wrote: > static int sti_bind(struct device *dev) > { > - return drm_platform_init(_driver, to_platform_device(dev)); > + struct drm_device *ddev; > + int ret; > + > + ddev = drm_dev_alloc(_driver, dev); > + if

DRM DMA Engine

Hi Ilia, Thanks for your answer. On 16-06-2016 13:39, Ilia Mirkin wrote: > On Thu, Jun 16, 2016 at 8:09 AM, Jose Abreu > wrote: >> Hi Daniel, >> >> Sorry to bother you again. I promise this is the last time :) >> >> On 15-06-2016 11:15, Daniel Vetter wrote: >>> On Wed, Jun 15, 2016 at 11:48

[PATCH 1/3] drm: Add callbacks for late registering

On Mon, Jun 20, 2016 at 05:22:55PM +0200, Benjamin Gaignard wrote: > Like what has been done for connectors add callbacks on encoder, > crtc and plane to let driver do actions after drm device registration. > > Correspondingly, add callbacks called before unregister drm device. > >

[PATCH 0/3] Fixes for HPD

On Fri, Jun 17, 2016 at 06:04:11PM -0400, Lyude wrote: > Forgot to mention, Ville: if you could get me an example of how to get > vlv into an infinite loop with these patches I'd appreciate that. I > haven't been able to reproduce this at all with the Valleyview machine > I've got here. Whether

[PULL] drm/bridge: sii902x driver

Hi Dave, This pull request contains 2 patches adding support for the sii902x bridge. Regards, Boris The following changes since commit a0877f52035280370707bdefeddc6faa6478b892: Merge tag 'topic/drm-misc-2016-06-15' of git://anongit.freedesktop.org/drm-intel into drm-next (2016-06-16

[Bug 96600] [RV630]: a lot of artifacts appears on a screen playing some videos through VDPAU with hardware acceleration

. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/5a51eb30/attachment-0001.html>

[Bug 96600] [RV630]: a lot of artifacts appears on a screen playing some videos through VDPAU hardware acceleration

part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/868f22e2/attachment.html>

[Bug 96600] [RV630]: a lot of artifacts appears on a screen playing some videos through VDPAU

art -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/5c7c5429/attachment.html>

[Bug 96600] [RV630]: a lot of artifacts appears on a screen playing some videos through VDPAU

art -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/2d9c444d/attachment.html>

[Bug 96600] [RV630]: a lot of artifacts appears on a screen playing some videos through VDPAU

art -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/209ba5da/attachment.html>

[Bug 96600] [RV630]: a lot of artifacts appears on a screen playing some videos through VDPAU

art -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/fe71f9f8/attachment.html>

[Bug 96600] [RV630]: a lot of artifacts appears on a screen playing some videos through VDPAU

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/b5ad2084/attachment.html>

[Bug 96600] [RV630]: a lot of artifacts appears on a screen playing some videos through VDPAU

bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/eb1ba05b/attachment-0001.html>

[Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

e doing the same thing. No idea if that is the > same thing that i965 does. Hi, Quentin did some tests for me, and the results are... not what I would have expected: https://phabricator.freedesktop.org/T7475#88454 RadeonSI works like Intel, but Nouveau does the opposite. I think the Nouveau way is correct by the spec, which makes everyone else (intel, radeonsi, weston-simple-dmabuf-v4l) get it wrong. Unfortunately, two wrongs make a right, so when weston-simple-dmabuf-v4l hardcodes Y_INVERT as set, it'll come out the right way on intel and radeon. And it is wrong for weston-simple-dmabuf-v4l to set Y_INVERT, that I believe is clear. It is only there because of the "oops, it's upside-down" syndrome, AFAIK. > > After all, using GL with windows and FBOs and stuff you very often find > > yourself upside down, and I suspect people have got the habit of just > > flipping it if it does not look right the first time. See e.g. the > > row-order of data going into glTexImage2D... > > > > If the answer is "oops, well, dmabuf import is semantically y-flipping > > when it should not, but we cannot fix it because that would break > > everyone", I would be happy with that. I just want confirmation before > > flipping the flip flag. :-) So many bugs that accidentally counter each other... Thanks, pq -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/4765adc5/attachment.sig>

[PATCH 3/3] dma-buf: remove dma_buf_debugfs_create_file()

On Sun, Jun 19, 2016 at 02:31:31PM +0200, Mathias Krause wrote: > There is only a single user of dma_buf_debugfs_create_file() and that > one got the function pointer cast wrong. With that one fixed, there is > no need to have a wrapper for debugfs_create_file(), just call it > directly. > > With

[PATCH 1/3] dma-buf: propagate errors from dma_buf_describe() on debugfs read

On Sun, Jun 19, 2016 at 02:31:29PM +0200, Mathias Krause wrote: > The callback function dma_buf_describe() returns an int not void so the > function pointer cast in dma_buf_show() is wrong. dma_buf_describe() can > also fail when acquiring the mutex gets interrupted so always returning > 0 in

[PATCH 12/16] drm: Lobotomize set_busid nonsense for !pci drivers

On 17 June 2016 at 08:33, Daniel Vetter wrote: > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > @@ -522,7 +522,6 @@ static struct drm_driver kms_driver = { > .preclose = amdgpu_driver_preclose_kms, > .postclose =

[PATCH 23/27] drm: Replace fb_helper->atomic with mode_config->atomic_commit

On Mon, Jun 20, 2016 at 01:55:57PM +0800, Ying Liu wrote: > On Mon, Jun 13, 2016 at 10:01 PM, Daniel Vetter wrote: > > On Mon, Jun 13, 2016 at 05:26:28PM +0800, Ying Liu wrote: > >> On Mon, Jun 13, 2016 at 3:58 PM, Daniel Vetter wrote: > >> > On Sun, Jun 12, 2016 at 05:01:27PM +0800, Ying Liu

[RFC PATCH 2/2] devicetree: Add ANX7688 transmitter binding

ANX7688 is a transmitter to support DisplayPort over USB-C for smartphone and tablets. This binding only describes the HDMI to DP component of the chip. Signed-off-by: Nicolas Boichat --- .../devicetree/bindings/video/bridge/anx7688.txt | 32 ++ 1 file changed, 32

[RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

ANX7688 is a HDMI to DP converter (as well as USB-C port controller), that has an internal microcontroller. The only reason a Linux kernel driver is necessary is to reject resolutions that require more bandwidth than what is available on the DP side. DP bandwidth and lane count are reported by

[Intel-gfx] [PATCH 3/3] drm/i915: Enable polling when we don't have hpd

On Fri, Jun 17, 2016 at 05:58:24PM -0400, Lyude wrote: > Unfortunately, there's two situations where we lose hpd right now: > - Runtime suspend > - When we've shut off all of the power wells on Valleyview/Cherryview > > While it would be nice if this didn't cause issues, this has the > ability to

[PATCH 09/16] drm/vgem: Stop calling drm_drv_set_unique

On Mon, Jun 20, 2016 at 12:42:55PM +0100, Chris Wilson wrote: > On Fri, Jun 17, 2016 at 09:33:27AM +0200, Daniel Vetter wrote: > > With the previous patch this is now redudant, the core always > > sets a reasonable dev->unique string. > > > > Cc: Sean Paul > > Signed-off-by: Daniel Vetter > >

i915 and Intel NUC DN2820FYK

(please keep me on Cc, I'm not subscribed to the list) Hello, while trying to use the NUC DN2820FYK [1], screen goes black as soon i915 is loaded. The NUC is connected by HDMI to a 1920x1080 display. Works normally while on the BIOS (upgraded to the latest one just in case today) and while on

[RFC PATCH] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

The 100c08 scratch page is mapped using dma_map_page() before the TTM layer has had a chance to set the DMA mask. This means we are still running with the default of 32 when this code executes, and this causes problems for platforms with no memory below 4 GB (such as AMD Seattle) So move the

[PATCH 10/16] drm: Don't call drm_dev_set_unique from platform drivers

Am Freitag, den 17.06.2016, 09:33 +0200 schrieb Daniel Vetter: > Since > > commit e112e593b215c394c0303dbf0534db0928e87967 > Author: Nicolas Iooss > Date: Fri Dec 11 11:20:28 2015 +0100 > > drm: use dev_name as default unique name in drm_dev_alloc() > > we're using a reasonable default

[PATCH 3/5] drm/imx: imx-ldb: detach panel on unbind

Am Freitag, den 17.06.2016, 12:13 +0200 schrieb Lucas Stach: > Make sure to leave a clean panel state behind and allow to > properly attach to the panel again on a rebind. > > Signed-off-by: Lucas Stach > --- > drivers/gpu/drm/imx/imx-ldb.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff

[PATCH 5/5] drm/imx: don't destroy mode objects manually on driver unbind

Am Freitag, den 17.06.2016, 12:13 +0200 schrieb Lucas Stach: > Instead let drm_mode_config_cleanup() do the work when taking down > the master device. This requires all cleanup functions to be > properly hooked up to the mode object .destroy callback. > > Signed-off-by: Lucas Stach > --- >

[GIT PULL v2] drm/mediatek: MT8173 HDMI support

Hi Dave, please consider merging this tag, which contains the v16 MT8173 HDMI patches I sent on 2016-05-26, rebased onto v4.7-rc2, with two warnings fixed. regards Philipp The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b: Linux 4.7-rc2 (2016-06-05 14:31:26 -0700)

[PATCH 23/27] drm: Replace fb_helper->atomic with mode_config->atomic_commit

On Mon, Jun 13, 2016 at 10:01 PM, Daniel Vetter wrote: > On Mon, Jun 13, 2016 at 05:26:28PM +0800, Ying Liu wrote: >> On Mon, Jun 13, 2016 at 3:58 PM, Daniel Vetter wrote: >> > On Sun, Jun 12, 2016 at 05:01:27PM +0800, Ying Liu wrote: >> >> On Wed, Jun 8, 2016 at 8:19 PM, Daniel Vetter >> >>

[PATCH 02/20] clk: multiplier: Prevent the multiplier from under / over flowing

Quoting Maxime Ripard (2016-05-16 05:47:02) > In the current multiplier base clock implementation, if the > CLK_SET_RATE_PARENT flag isn't set, the code will not make sure that the > multiplier computed remains within the boundaries of our clock. > > This means that if the clock we want to reach

[PATCH 5/7] staging/android: prepare sw_sync files for de-staging

2016-06-20 Joe Perches : > On Mon, 2016-06-20 at 12:53 -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Fix paths in the comments. > > Why is it useful to have the path or filename embedded > in the file at > all? I just kept it as is. Thinking about this now I don't see this

[PATCH 01/20] clk: fixed-factor: Pass clk rates change to the parent

Quoting Maxime Ripard (2016-06-20 01:54:58) > On Fri, Jun 17, 2016 at 04:05:33PM -0700, Michael Turquette wrote: > > Quoting Maxime Ripard (2016-05-16 05:47:01) > > > A fixed factor clock, if it needs to change its rate, by definition do not > > > have any choice but to modify its parent rate. > >

[PATCH 7/7] staging/android: remove sync framework TODO

From: Gustavo Padovan Sync Framework was de-staged to drivers/dma-buf/, so remove it entries in the TODO file. Signed-off-by: Gustavo Padovan --- drivers/staging/android/TODO | 8 1 file changed, 8 deletions(-) diff --git

[PATCH 6/7] dma-buf/sw_sync: de-stage SW_SYNC

From: Gustavo Padovan SW_SYNC allows to run tests on the sync_file framework via debugfs on /sync/sw_sync Opening and closing the file triggers creation and release of a sync timeline. To create fences on this timeline the SW_SYNC_IOC_CREATE_FENCE ioctl should

[PATCH 5/7] staging/android: prepare sw_sync files for de-staging

From: Gustavo Padovan Fix paths in the comments. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync_debug.c | 2 +- drivers/staging/android/sync_debug.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 4/7] staging/android: move trace/sync.h to sync_trace.h

From: Gustavo Padovan The common behaviour for trace headers is to have them in the same folder they are used, instead of creating a special trace/ directory. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sw_sync.c | 2 +-

[PATCH 3/7] staging/android: do not let userspace trigger WARN_ON

From: Gustavo Padovan Closing the timeline without waiting all fences to signal is not a critical failure, it is just bad usage from userspace so avoid calling WARN_ON in this case. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sw_sync.c | 2 +- 1

[PATCH 2/7] staging/android: display sync_pt name on debugfs

From: Gustavo Padovan When creating a sync_pt the name received wasn't used anywhere. Now we add it to the sync info debug output to make it easier to indetify the userspace name of that sync pt. Signed-off-by: Gustavo Padovan ---

[PATCH 1/7] staging/android: remove doc from sw_sync

From: Gustavo Padovan SW_SYNC should never be used by other pieces of the kernel apart from sync_debug as it is only a Sync File Validation Framework, so hide any info to avoid confuse this with a standard kernel internal API. Signed-off-by: Gustavo Padovan ---

[PATCH 0/7] de-stage SW_SYNC validation frawework

From: Gustavo Padovan Hi Greg, This is the last step in the Sync Framwork de-stage task. It de-stage the SW_SYNC validation framework and the sync_debug info debugfs file. The first 3 patches are clean up and improvements and the rest is preparation to de-stage

[PATCH 2/2] drm/etnaviv: remove generic GPU init failure reporting

2016-06-17 12:42 GMT+02:00 Lucas Stach : > The GPU init path now reports any errors which might occur more accurately > than what is possible with the generic "something failed" message. > > Remove the generic reporting, so we don't log an error into dmesg anymore > if any of the GPU cores are

[PATCH 1/2] drm/etnaviv: improve error reporting in GPU init path

2016-06-17 12:42 GMT+02:00 Lucas Stach : > Print error messages that mention the exact cause of the failure on > all paths which may fail the GPU init. > > Signed-off-by: Lucas Stach Reviewed-by: Christian Gmeiner > --- > drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 10 -- > 1 file

[PATCH 09/16] drm/vgem: Stop calling drm_drv_set_unique

On Fri, Jun 17, 2016 at 09:33:27AM +0200, Daniel Vetter wrote: > With the previous patch this is now redudant, the core always > sets a reasonable dev->unique string. > > Cc: Sean Paul > Signed-off-by: Daniel Vetter Will this fix: [ 4442.886507]

[PATCH 2/2] drm/sun4i: Send vblank event when the CRTC is disabled

So far, we were missing to send the vblank event when disabling the CRTC, making us never report the last vblank event. This was causing a time out on the page flip, which should be solved now. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_crtc.c | 8 1 file changed, 8

[PATCH 1/2] drm/sun4i: Report proper vblank

The sun4i display engine doesn't have any vblank counter. Use the proper helper for that. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c

[RFC PATCH 07/13] dt-bindings: i2c: Add support for 'i2c-bus' subnode

On 17/06/16 17:45, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Fri, Jun 17, 2016 at 05:30:54PM +0100, Mark Rutland wrote: >> On Fri, Jun 17, 2016 at 01:03:41PM +0100, Jon Hunter wrote: >>> The I2C driver core for boards using device-tree assumes any subnode of >>> an I2C

[PATCH] drm/hisilicon: add select HISI_KIRIN_DW_DSI

From: Guodong Xu Add select HISI_KIRIN_DW_DSI to Kconfig. The DRM driver depends on dsi sub-driver. Signed-off-by: Zoltan Kuscsik --- drivers/gpu/drm/hisilicon/kirin/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig

[Bug 96588] [regression] [amdgpu] Errors scheduling IBs

: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/e572dabb/attachment.html>

[RFC PATCH 10/13] drm/tegra: Add pinctrl support for DPAUX

On 17/06/16 17:37, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Fri, Jun 17, 2016 at 01:03:44PM +0100, Jon Hunter wrote: >> The DPAUX pins are shared with an internal I2C controller. To allow >> these pins to be muxed to the I2C controller, register a pinctrl device >> for the

[PATCH 4/7] drm/hisilicon: Remove redundant calls to drm_connector_register_all()

Hi, On 17 June 2016 at 16:25, Chris Wilson wrote: > Up to now, the recommendation was for drivers to call drm_dev_register() > followed by drm_connector_register_all(). Now that > drm_connector_register() is safe against multiple invocations, we can > move drm_connector_register_all() to

[Bug 120591] BUG() in dmesg after loading nouveau module

https://bugzilla.kernel.org/show_bug.cgi?id=120591 --- Comment #7 from Dmitrii Tcvetkov --- Thank you for advice, I've sent the patch, mail awaits moderation. -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 96588] [regression] [amdgpu] Errors scheduling IBs

art -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/a42735c2/attachment.html>

[PATCH v7 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

Add support for the JDI LT070ME05000 WUXGA DSI panel used in Nexus 7 2013 devices. Programming sequence for the panel is was originally found in the android-msm-flo-3.4-lollipop-release branch from: https://android.googlesource.com/kernel/msm.git And video mode setting is from

[PATCH v2 1/2] drm/dsi: Implement dcs set/get display brightness

Provide a small convenience wrapper that set/get the display brightness value Cc: John Stultz Cc: Sumit Semwal Cc: Archit Taneja Cc: Rob Clark Cc: Jani Nikula Cc: Thierry Reding Signed-off-by: Vinay Simha BN --- v1: *tested in nexus7 2nd gen. v2: * implemented jani review comments

[Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

thing. No idea if that is the > same thing that i965 does. Thanks, pq > > BR, > -R > > > After all, using GL with windows and FBOs and stuff you very often find > > yourself upside down, and I suspect people have got the habit of just > > flipping it if it does not look right the first time. See e.g. the > > row-order of data going into glTexImage2D... > > > > If the answer is "oops, well, dmabuf import is semantically y-flipping > > when it should not, but we cannot fix it because that would break > > everyone", I would be happy with that. I just want confirmation before > > flipping the flip flag. :-) > > > > > > Thanks, > > pq -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160620/36fa23e5/attachment.sig>

[PATCH v2] gpu: host1x: hw: intr_hw: Remove create_workqueue

On Sat, Jun 18, 2016 at 02:36:32PM +0530, Bhaktipriya Shridhar wrote: > System workqueues have been able to handle high level of concurrency > for a long time now and there's no reason to use dedicated workqueues > just to gain concurrency. Since the workqueue host->intr_wq is involved > in sync

[GIT PULL] Allwinner sun4i DRM fixes for 4.7

org/archives/dri-devel/attachments/20160620/4826954f/attachment.sig>

  1   2   >