[PATCH] dma-buf/sw_sync: put fence reference from the fence creation

On Wed, Oct 26, 2016 at 06:59:59PM -0200, Gustavo Padovan wrote: > From: Gustavo Padovan > > Once sw_sync_ioctl_create_fence() returns we no longer have the > *pt pointer to the fence base object thus we need to put the reference > we have from the fence creation to keep a correct reference

[PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

undantly > pinning state for the sake of tracking the ID for streams that don't end up > needing it. > I started to try out moving the specific_ctx_id and vma pointer (new) to the stream, and also looked at initializing them together with the stream->ctx reference, but I'm not really happy with how it's looking. The specific_ctx_id and pinning are only for the render context, since the OA unit is only well integrated with the render engine, which makes me more inclined to consider them OA stream specific, not something we want/need for all streams (considering that Sourab enables multiple streams in his series). Btw, for reference, my patches for gen8+ can also end up making use of the INVALID_CTX_ID define (when overwriting the undefined ctx_id field in HW reports when the report's ctx-id is flagged as invalid by the OA unit.) so we maybe don't want to worry to much about removing the need for it here. - Robert -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/1eabdc8e/attachment.html>

[PATCH 4/4] drm/dp/mst: Check peer device type before attempting EDID read

On Wed, Oct 26, 2016 at 11:31:55AM -0700, Carlos Santa wrote: > On Wed, 2016-10-26 at 02:05 -0700, ville.syrjala at linux.intel.com wrote: > > From: Ville Syrjälä > > > > Only certain types of pdts have the DDC bus registered, so check for > > that before we attempt the EDID read. Othwewise we

[PATCH 04/20] drm/ast: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

On Wed, Oct 26, 2016 at 8:47 PM, Stefan Lengfeld wrote: > > On Tue, Oct 25, 2016 at 04:57:37PM +0200, Daniel Vetter wrote: >> On Thu, Sep 29, 2016 at 10:48:40PM +0200, Stefan Christ wrote: >> > Cc: Dave Airlie >> > Signed-off-by: Stefan Christ >> > --- >> > drivers/gpu/drm/ast/ast_fb.c | 6

[PATCH 04/20] drm/ast: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

Hi Daniel, On Tue, Oct 25, 2016 at 04:57:37PM +0200, Daniel Vetter wrote: > On Thu, Sep 29, 2016 at 10:48:40PM +0200, Stefan Christ wrote: > > Cc: Dave Airlie > > Signed-off-by: Stefan Christ > > --- > > drivers/gpu/drm/ast/ast_fb.c | 6 +- > > 1 file changed, 1 insertion(+), 5

[Bug 98238] witcher 2: objects are black when changing lod

attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/916db7d3/attachment.html>

[Bug 98298] System freezes 380X

will inform you. -- You 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/20161026/cc24c2ad/attachment.html>

[Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

On Wed, Oct 26, 2016 at 05:42:23PM +0100, Robert Bragg wrote: > On Wed, Oct 26, 2016 at 4:37 PM, Ville Syrjälä < > ville.syrjala at linux.intel.com> wrote: > > > On Wed, Oct 26, 2016 at 04:17:45PM +0100, Robert Bragg wrote: > > > On 26 Oct 2016 9:54 a.m., "Chris Wilson" > > wrote: > > > > > >

[Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

on. > > > > I'm a sell out and just use Gmail... sorry. I can't really see myself > > changing, though I do wish Google weren't so pedantic about forcing > > wrapping without any option to change that behaviour. I suspect you > > wouldn't be happy with me sending html emails, which has been Google's > > default response to this complaint afik. > > > > Maybe it's gmail users causing trouble on the Mesa list too. > > > > - Robert > > > > P.S please don't think lesser of me due to my misguided MUA choices. > > I think I'll just reserve the right to ignore any mail with bad quoting. Okey, fwiw, at least my patches sent out via git send-email should be fine, so maybe just ignore my replies to feedback - which I promise not to exploit to achieve 'consensus' through silence. - Robert -- Sent from Gmail on Android, in a spare moment at a VR for Immersive Theatre meet up. > > -- > Ville Syrjälä > Intel OTC -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/92ecba19/attachment-0001.html>

[PATCH] drm/i915/vlv: Prevent enabling hpd polling in late suspend

On Wed, Oct 26, 2016 at 12:36:09PM -0400, Lyude wrote: > One of the CI machines began to run into issues with the hpd poller > suddenly waking up in the midst of the late suspend phase. It looks like > this is getting caused by the fact we now deinitialize power wells in > late suspend, which

[PATCH] x86/pat, mm: Make track_pfn_insert() return void

On Mon, Oct 24, 2016 at 04:31:45PM +1000, Dave Airlie wrote: > A recent change to the mm code in: > 87744ab3832b83ba71b931f86f9cfdb000d07da5 > mm: fix cache mode tracking in vm_insert_mixed() While we're at it, let's simplify that track_pfn_insert() thing: --- >From

[RFC PATCH v2 7/9] drm: atomic: factor out common out-fence operations

2016-10-26 Brian Starkey : > Some parts of setting up the CRTC out-fence can be re-used for > writeback out-fences. Factor this out into a separate function. > > Signed-off-by: Brian Starkey > --- > drivers/gpu/drm/drm_atomic.c | 64 > +++--- > 1 file

[RFC PATCH v2 9/9] drm: mali-dp: Add writeback out-fence support

2016-10-26 Brian Starkey : > If userspace has asked for an out-fence for the writeback, we add a > fence to malidp_mw_job, to be signaled when the writeback job has > completed. > > Signed-off-by: Brian Starkey > --- > drivers/gpu/drm/arm/malidp_hw.c |5 - >

[RFC PATCH v2 8/9] drm: writeback: Add out-fences for writeback connectors

2016-10-26 Brian Starkey : > Add the OUT_FENCE_PTR property to writeback connectors, to enable > userspace to get a fence which will signal once the writeback is > complete. > > A timeline is added to drm_connector for use by the writeback > out-fences. It is up to drivers to check for a fence

[PATCH 2/2] ARM: bus: da8xx-mstpri: new driver

Create the driver for the da8xx master peripheral priority configuration and implement support for writing to the three Master Priority registers on da850 SoCs. Signed-off-by: Bartosz Golaszewski --- .../devicetree/bindings/bus/ti,da850-mstpri.txt| 20 ++ drivers/bus/Kconfig

[PATCH 1/2] ARM: memory: da8xx-ddrctl: new driver

Create a new driver for the da8xx DDR2/mDDR controller and implement support for writing to the Peripheral Bus Burst Priority Register. Signed-off-by: Bartosz Golaszewski --- .../memory-controllers/ti-da8xx-ddrctl.txt | 20 +++ drivers/memory/Kconfig | 8 +

[PATCH 0/2] ARM: da850: new drivers for better LCDC support

This series adds two new drivers in order to better support the LCDC rev1 present on the da850 boards. The first patch adds a new memory driver which allows to write to the DDR2/mDDR memory controller present on the da8xx SoCs. Since the memory controller region is not mapped by anyone else, I

[RFC PATCH v2 7/9] drm: atomic: factor out common out-fence operations

2016-10-26 Brian Starkey : > Some parts of setting up the CRTC out-fence can be re-used for > writeback out-fences. Factor this out into a separate function. > > Signed-off-by: Brian Starkey > --- > drivers/gpu/drm/drm_atomic.c | 64 > +++--- > 1 file

[PATCH v2] drm: Print some debug/error info during DP dual mode detect

There's at least one LSPCON device that occasionally returns an unexpected adaptor ID which leads to a failed detect. Print some debug info to help debugging this and future cases. Also print an error for an unexpected adaptor ID, so users can report it. v2: - s/adapter/adaptor/ and add code

[PATCH] MAINTAINERS: drop dri-devel list for i915

In practice, none of the i915 developers Cc dri-devel for strictly i915 specific patches. Make MAINTAINERS reflect reality, and reduce random i915 specific noise on dri-devel. Also, we have a fairly large crowd reading and responding on intel-gfx, and we're pretty good at involving dri-devel when

[PATCH] MAINTAINERS: update Sync File Framework files

From: Gustavo Padovan Signed-off-by: Gustavo Padovan --- MAINTAINERS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e60e0a1..10f1bc0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3913,8 +3913,10 @@ R:

[PATCH] dma-buf/sw_sync: put fence reference from the fence creation

From: Gustavo Padovan Once sw_sync_ioctl_create_fence() returns we no longer have the *pt pointer to the fence base object thus we need to put the reference we have from the fence creation to keep a correct reference accounting. Signed-off-by: Gustavo Padovan

[PATCH v2 3/4] drm/dp/mst: Clear port->pdt when tearing down the i2c adapter

On Wed, Oct 26, 2016 at 04:02:57PM +0200, Daniel Vetter wrote: > On Wed, Oct 26, 2016 at 04:35:50PM +0300, Ville Syrjälä wrote: > > On Wed, Oct 26, 2016 at 04:30:33PM +0300, ville.syrjala at linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > The i2c adapter is only relevant

[Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

On Wed, Oct 26, 2016 at 05:42:23PM +0100, Robert Bragg wrote: > On Wed, Oct 26, 2016 at 4:37 PM, Ville Syrjälä < > ville.syrjala at linux.intel.com> wrote: > > > On Wed, Oct 26, 2016 at 04:17:45PM +0100, Robert Bragg wrote: > > > On 26 Oct 2016 9:54 a.m., "Chris Wilson" > > wrote: > > > > > >

[PATCH] drm: Don't force all planes to be added to the state due to zpos

On Wed, Oct 26, 2016 at 04:09:00PM +0200, Benjamin Gaignard wrote: > I have just tested it on my board, no regression :-) > > Acked-by: Benjamin Gaignard > > 2016-10-25 22:53 GMT+02:00 Sean Paul : > > On Tue, Oct 25, 2016 at 10:43 AM, Ville Syrjälä > > wrote: > >> On Mon, Oct 10, 2016 at

[Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

On Wed, Oct 26, 2016 at 04:17:45PM +0100, Robert Bragg wrote: > On 26 Oct 2016 9:54 a.m., "Chris Wilson" wrote: > > > > On Wed, Oct 26, 2016 at 12:51:58AM +0100, Robert Bragg wrote: > > >On Tue, Oct 25, 2016 at 10:35 PM, Matthew Auld > > ><[1]matthew.william.auld at gmail.com> wrote: > >

[PATCH] drm: Print some debug/error info during DP dual mode detect

On Wed, 2016-10-26 at 18:10 +0300, Ville Syrjälä wrote: > On Wed, Oct 26, 2016 at 05:50:08PM +0300, Imre Deak wrote: > > There's at least one LSPCON device that occasionally returns an unexpected > > adaptor ID which leads to a failed detect. Print some debug info to help > > debugging this and

[PATCH] drm: rcar-du: Fix R-Car Gen3 crash when VSP is disabled

Hi Geert, On Wed, Oct 26, 2016 at 4:31 PM, Geert Uytterhoeven wrote: > On Wed, Oct 26, 2016 at 5:31 AM, Magnus Damm wrote: >> From: Magnus Damm >> >> For the DU to operate on R-Car Gen3 hardware a combination of DU >> and VSP devices are required. Since the DU

[PATCH] drm: Print some debug/error info during DP dual mode detect

On Wed, Oct 26, 2016 at 05:50:08PM +0300, Imre Deak wrote: > There's at least one LSPCON device that occasionally returns an unexpected > adaptor ID which leads to a failed detect. Print some debug info to help > debugging this and future cases. Also print an error for an unexpected > adaptor ID,

[Bug 98417] TTM broken on 4.9-rc2

tps://lists.freedesktop.org/archives/dri-devel/attachments/20161026/20346fc7/attachment.html>

[Bug 98417] TTM broken on 4.9-rc2

. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/13db3d93/attachment.html>

[Bug 98417] TTM broken on 4.9-rc2

minimal set, tied to this machine only) as built-in. -- You 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/20161026/d7d1e

[PATCH] drm: Print some debug/error info during DP dual mode detect

There's at least one LSPCON device that occasionally returns an unexpected adaptor ID which leads to a failed detect. Print some debug info to help debugging this and future cases. Also print an error for an unexpected adaptor ID, so users can report it. Cc: dri-devel at lists.freedesktop.org Cc:

[Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

; > Considering Matt's comments too, I'm thinking I'll put the pinning and > > specific_ctx_id initialization together with setting stream->ctx, keeping > > the state together under the stream. It's going to potentially mean > > redundantly pinning the ctx for the sake of the ID in the future for > > streams that don't really need it, but I think it's probably not worth > > worrying about that. > > > > - Robert > > > > > -Chris > > > > > > -- > > > Chris Wilson, Intel Open Source Technology Centre > > > ___ > > Intel-gfx mailing list > > Intel-gfx at lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > -- > Ville Syrjälä > Intel OTC > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/da381dcd/attachment-0001.html>

[PATCH v3 2/4] drm/fb-helper: Keep references for the current set of used connectors

From: Ville Syrjälä The fbdev helper code keeps around two lists of connectors. One is the list of all connectors it could use, and that list already holds references for all the connectors. However the other list, or rather lists, is the one actively being used.

[PATCH v3] drm/mediatek: fixed the calc method of data rate per lane

Hi, Jitao: On Wed, 2016-10-26 at 16:59 +0800, Jitao Shi wrote: > Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx, > Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this > signal will cause h-time larger than normal and reduce FPS. > Need to

[PATCH v5 3/9] drm/hisilicon/hibmc: Add support for frame buffer

Hi Daniel, Thansk for reviewing! 在 2016/10/26 13:56, Daniel Vetter 写道: > On Wed, Oct 26, 2016 at 10:37:00AM +0800, Rongrong Zou wrote: >> Add support for fbdev and kms fb management. >> >> Signed-off-by: Rongrong Zou > > Small drive-by comment below. > >> diff --git

[RFC] mesa: drop current draw/read buffer when ctx is released

So, not quite sure if this is the *correct* solution, but it is at least *a* solution to a problem with android wallpaper vs mesa that I've been debugging. Basically, what happens is: EGLSurface tmpSurface = mEgl.eglCreatePbufferSurface(mEglDisplay, mEglConfig, attribs);

[PATCH v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO

On Thu, Oct 20, 2016 at 11:43:37AM +0800, Chen-Yu Tsai wrote: > Some rgb-to-vga bridges have an enable GPIO, either directly tied to > an enable pin on the bridge IC, or indirectly controlling a power > switch. > > Add support for it. > > Signed-off-by: Chen-Yu Tsai > --- >

[PATCH v2 2/4] drm/fb-helper: Keep references for the current set of used connectors

On Wed, Oct 26, 2016 at 02:54:45PM +0100, Chris Wilson wrote: > On Wed, Oct 26, 2016 at 04:31:20PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrjälä > > > > The fbdev helper code keeps around two lists of connectors. One is the > > list of all connectors it could use,

[PATCH v2] drm/mediatek: fixed the calc method of data rate per lane

On Wed, 2016-10-26 at 14:41 +0800, CK Hu wrote: > Hi, Jitao: > > On Tue, 2016-10-25 at 13:40 +0800, Jitao Shi wrote: > > Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx, > > Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this > > signal will cause

[git pull] drm/x86 pat regression fix.

Hi Linus, This is a standalone pull request for the fix for a regression introduced in -rc1 by a change to vm_insert_mixed to start using the PAT range tracking to validate page protections. With this fix in place, all the VRAM mappings for GPU drivers ended up at UC instead of WC. There are

[PATCH 0/4] drm: Fix MST oopses in fbdev restore

On Wed, Oct 26, 2016 at 12:05:51PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > This series would appear to be enough to avoid kernel oopses when trying > to restore the fbdev setup after a MST device has been yanked. > > Apparently we still have some problems

[PATCH v2 3/4] drm/dp/mst: Clear port->pdt when tearing down the i2c adapter

On Wed, Oct 26, 2016 at 04:30:33PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > The i2c adapter is only relevant for some peer device types, so > let's clear the pdt if it's still the same as the old_pdt when we > tear down the i2c adapter. > > I don't really like

[PATCH 1/8] drm: bridge: Add LVDS encoder driver

On Wed, Oct 19, 2016 at 05:25:36PM +0300, Laurent Pinchart wrote: > The LVDS encoder driver is a DRM bridge driver that supports the > parallel to LVDS encoders that don't require any configuration. The > driver thus doesn't interact with the device, but creates an LVDS > connector for the panel

[PATCH v2 2/4] drm/fb-helper: Keep references for the current set of used connectors

From: Ville Syrjälä The fbdev helper code keeps around two lists of connectors. One is the list of all connectors it could use, and that list already holds references for all the connectors. However the other list, or rather lists, is the one actively being used.

[PATCH v2 3/4] drm/dp/mst: Clear port->pdt when tearing down the i2c adapter

From: Ville Syrjälä The i2c adapter is only relevant for some peer device types, so let's clear the pdt if it's still the same as the old_pdt when we tear down the i2c adapter. I don't really like this design pattern of updating port->whatever before doing the

[PATCH 3/7] drm/i915: Set link status property for DP connector

This defines a helper function to set the property value. This will be used to set the link status to Bad in case of link training failures. Cc: dri-devel at lists.freedesktop.org Cc: Jani Nikula Cc: Daniel Vetter Cc: Ville Syrjala Cc: Chris Wilson Signed-off-by: Manasi Navare ---

[PATCH 2/7] drm: Add a new connector property for link status

A new default connector property is added for keeping track of whether the link is good (link training passed) or link is bad (link training failed). If the link status property is not good, then userspace should fire off a new modeset at the current mode even if there have not been any changes

[PATCH 1/7] drm: Define a work struct for scheduling a uevent for modeset retry

This work struct will be used to schedule a uevent on a separate thread. This will be scheduled after a link train failure during modeset to indicate a modeset retry request. It will get executed after the current modeset is complete and all locks are released. This was required to avoid deadlock.

[PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

;ctx, keeping the state together under the stream. It's going to potentially mean redundantly pinning the ctx for the sake of the ID in the future for streams that don't really need it, but I think it's probably not worth worrying about that. - Robert > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/74d1f24a/attachment.html>

[Intel-gfx] [PATCH 1/2] drm: Add a new connector property for link status

On Wed, Oct 26, 2016 at 02:11:00PM +0100, Chris Wilson wrote: > On Wed, Oct 26, 2016 at 02:17:16PM +0300, Ville Syrjälä wrote: > > On Wed, Oct 26, 2016 at 12:51:41PM +0300, Jani Nikula wrote: > > > On Wed, 26 Oct 2016, Chris Wilson wrote: > > > > On Wed, Oct 26, 2016 at 07:52:26AM +0200, Daniel

[PATCH 1/2] x86/io: add interface to reserve io memtype for a resource range. (v1.1)

>> >> Is anything on a driver to be able to tell when this is actually needed ? >> How will driver developers know? Can you add a bit of documentation to >> the API? If its transitive towards a secondary solution indicating so >> would help driver developers. > > I'll plug the io-mapping stuff

[PATCH] drm: Don't force all planes to be added to the state due to zpos

I have just tested it on my board, no regression :-) Acked-by: Benjamin Gaignard 2016-10-25 22:53 GMT+02:00 Sean Paul : > On Tue, Oct 25, 2016 at 10:43 AM, Ville Syrjälä > wrote: >> On Mon, Oct 10, 2016 at 03:19:47PM +0300, ville.syrjala at linux.intel.com >> wrote: >>> From: Ville

[PATCH 4/4] drm/dp/mst: Check peer device type before attempting EDID read

On Wed, Oct 26, 2016 at 02:55:14PM +0200, Daniel Vetter wrote: > On Wed, Oct 26, 2016 at 12:05:55PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrjälä > > > > Only certain types of pdts have the DDC bus registered, so check for > > that before we attempt the EDID read.

[PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

r-engine stream and that could be relaxed further with non-oa metric stream types. With multiple streams we'll still only be able to programmer a single ctx id in oacontol. Conceptually to me, other stream types could be associated with different contexts (if they don't depend on the OA unit) so to me stream->ctx isn't necessarily OA unit state. It probably could be played around with, but right now we don't track OA specific state in the stream. For the ID it's just semantics to say it's OA state, and we could consider that it's maybe generally useful to track the ID, even for future non-oa streams. That might mean potentially redundantly pinning state for the sake of tracking the ID for streams that don't end up needing it. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/22bf9802/attachment.html>

[PATCH v2 3/4] drm/dp/mst: Clear port->pdt when tearing down the i2c adapter

On Wed, Oct 26, 2016 at 04:35:50PM +0300, Ville Syrjälä wrote: > On Wed, Oct 26, 2016 at 04:30:33PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrjälä > > > > The i2c adapter is only relevant for some peer device types, so > > let's clear the pdt if it's still the same

[PATCH 3/4] drm/dp/mst: Clear port->pdt when tearing down the i2c adapter

On Wed, Oct 26, 2016 at 02:53:01PM +0200, Daniel Vetter wrote: > On Wed, Oct 26, 2016 at 12:05:54PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrjälä > > > > The i2c adapter is only relevant for some peer device types, so > > let's clear the pdt if it's still the same

[PATCH v2] drm: Print some debug/error info during DP dual mode detect

On Wed, Oct 26, 2016 at 12:29 PM, Imre Deak wrote: > There's at least one LSPCON device that occasionally returns an unexpected > adaptor ID which leads to a failed detect. Print some debug info to help > debugging this and future cases. Also print an error for an unexpected > adaptor ID, so

[PATCH] drm: mark drm_of_component_match_add dummy inline

On Wed, Oct 26, 2016 at 4:57 AM, Arnd Bergmann wrote: > The newly added drm_of_component_match_add helper is defined as > 'static' in a header when CONFIG_OF is disabled, causing a warning > each time the header is included: > > In file included from

[Bug 98333] 4K @ 60Hz over HDMI 2.0 not working with AMDGPU-DAL

or the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/b4f61d99/attachment.html>

[PATCH 5/5] drm/i915/gen9: only add the planes actually affected by ddb changes

From: Paulo Zanoni commit be5c571b2ff3a164d2e14ccc100cb5b2b3d3fb7c upstream We were previously adding all the planes owned by the CRTC even when the ddb partitioning didn't change for them. As a consequence, a lot of functions were being called when we were just moving

[PATCH 4/5] drm/i915/skl: Don't try to update plane watermarks if they haven't changed

commit ccebc23b57c313229526dc76383ce82f5e0b9001 upstream i915 sometimes needs to disable planes in the middle of an atomic commit, and then reenable them later in the same commit. Because of this, we can't make the assumption that the state of the plane actually changed. Since the state of the

[PATCH 3/5] drm/i915/skl: Update DDB values atomically with wms/plane attrs

commit 27082493e9c6371b05370a619ab9d2877c5f4726 upstream Now that we can hook into update_crtcs and control the order in which we update CRTCs at each modeset, we can finish the final step of fixing Skylake's watermark handling by performing DDB updates at the same time as plane updates and

[PATCH 2/5] drm/i915: Move CRTC updating in atomic_commit into it's own hook

commit 896e5bb022bce64e29ce2e1b2fc2a7476d311a15 upstream Since we have to write ddb allocations at the same time as we do other plane updates, we're going to need to be able to control the order in which we execute modesets on each pipe. The easiest way to do this is to just factor this section

[PATCH 1/5] drm/i915/skl: Update plane watermarks atomically during plane updates

commit c145d3be1c313184be71d2629fd575561b7e38d4 upstream Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values

[PATCH 0/5] drm/i915/skl: Backport watermark fixes for 4.8.y

Now that these have finally made it into 4.9, it's time to finally backport these fixes. Skylake has been a mess in multi-monitor setups for a while now because up until recently we've been updating the watermarks on Skylake just like we would for previous generations of Intel GPUs. This means

[PATCH 2/4] drm/fb-helper: Keep references for the current set of used connectors

On Wed, Oct 26, 2016 at 10:52:24AM +0100, Chris Wilson wrote: > On Wed, Oct 26, 2016 at 12:05:53PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrjälä > > > > The fbdev helper code keeps around two lists of connectors. One is the > > list of all connectors it could use,

[PATCH 1/4] dma-buf/fence: make timeout handling in fence_default_wait consistent

Am 26.10.2016 um 10:49 schrieb Chris Wilson: > On Tue, Oct 25, 2016 at 02:25:08PM +0200, Christian König wrote: >> From: Christian König >> >> Kernel functions taking a timeout usually return 1 on success even >> when they get a zero timeout. > Which? The canonical example of schedule_timeout()

[RFC PATCH v2 1/9] drm: Add writeback connector type

On Wed, Oct 26, 2016 at 01:42:42PM +0100, Brian Starkey wrote: > On Wed, Oct 26, 2016 at 01:00:21PM +0200, Daniel Vetter wrote: > > On Wed, Oct 26, 2016 at 09:55:00AM +0100, Brian Starkey wrote: > > > diff --git a/drivers/gpu/drm/drm_writeback.c > > > b/drivers/gpu/drm/drm_writeback.c > > > new

[PATCH v5 3/9] drm/hisilicon/hibmc: Add support for frame buffer

On Wed, Oct 26, 2016 at 05:19:31PM +0800, Rongrong Zou wrote: > Hi Daniel, > > Thansk for reviewing! > > 在 2016/10/26 13:56, Daniel Vetter 写道: > > On Wed, Oct 26, 2016 at 10:37:00AM +0800, Rongrong Zou wrote: > > > Add support for fbdev and kms fb management. > > > > > > Signed-off-by:

[PATCH 4/4] drm/dp/mst: Check peer device type before attempting EDID read

On Wed, Oct 26, 2016 at 12:05:55PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > Only certain types of pdts have the DDC bus registered, so check for > that before we attempt the EDID read. Othwewise we risk playing around > with an i2c adapter that doesn't actually

[PATCH v2 2/4] drm/fb-helper: Keep references for the current set of used connectors

On Wed, Oct 26, 2016 at 04:31:20PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > The fbdev helper code keeps around two lists of connectors. One is the > list of all connectors it could use, and that list already holds > references for all the connectors. However

[PATCH 3/4] drm/dp/mst: Clear port->pdt when tearing down the i2c adapter

On Wed, Oct 26, 2016 at 12:05:54PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > The i2c adapter is only relevant for some peer device types, so > let's clear the pdt if it's still the same as the old_pdt when we > tear down the i2c adapter. > > I don't really like

[PATCH v2] drm/mediatek: fixed the calc method of data rate per lane

Hi, Jitao: On Tue, 2016-10-25 at 13:40 +0800, Jitao Shi wrote: > Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx, > Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this > signal will cause h-time larger than normal and reduce FPS. > Need to

[PATCH] drm/exynos/hdmi: refactor infoframe code

Use core helpers to generate infoframes and generate vendor frame if necessary. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_hdmi.c | 141 ++- drivers/gpu/drm/exynos/regs-hdmi.h | 2 + 2 files changed, 42 insertions(+), 101 deletions(-)

[Intel-gfx] [PATCH 1/2] drm: Add a new connector property for link status

On Wed, Oct 26, 2016 at 04:15:39PM +0300, Ville Syrjälä wrote: > On Wed, Oct 26, 2016 at 02:11:00PM +0100, Chris Wilson wrote: > > On Wed, Oct 26, 2016 at 02:17:16PM +0300, Ville Syrjälä wrote: > > > On Wed, Oct 26, 2016 at 12:51:41PM +0300, Jani Nikula wrote: > > > > On Wed, 26 Oct 2016,

[Intel-gfx] [PATCH 1/2] drm: Add a new connector property for link status

On Wed, Oct 26, 2016 at 12:51:41PM +0300, Jani Nikula wrote: > On Wed, 26 Oct 2016, Chris Wilson wrote: > > On Wed, Oct 26, 2016 at 07:52:26AM +0200, Daniel Vetter wrote: > >> I'd go further and just always create this as one of the standard > >> properties (and always attach it to the connector,

[Intel-gfx] [PATCH 1/2] drm: Add a new connector property for link status

On Wed, Oct 26, 2016 at 02:17:16PM +0300, Ville Syrjälä wrote: > On Wed, Oct 26, 2016 at 12:51:41PM +0300, Jani Nikula wrote: > > On Wed, 26 Oct 2016, Chris Wilson wrote: > > > On Wed, Oct 26, 2016 at 07:52:26AM +0200, Daniel Vetter wrote: > > >> I'd go further and just always create this as

[RFC PATCH v2 8/9] drm: writeback: Add out-fences for writeback connectors

Hi Gustavo, It would be great if you could cast your eye over this one as-well. My intention was to be as similar to the CRTC out-fences as possible. Thanks, Brian On Wed, Oct 26, 2016 at 09:55:07AM +0100, Brian Starkey wrote: >Add the OUT_FENCE_PTR property to writeback connectors, to enable

[RFC PATCH v2 1/9] drm: Add writeback connector type

On Wed, Oct 26, 2016 at 01:00:21PM +0200, Daniel Vetter wrote: >On Wed, Oct 26, 2016 at 09:55:00AM +0100, Brian Starkey wrote: >> Writeback connectors represent writeback engines which can write the >> CRTC output to a memory framebuffer. Add a writeback connector type and >> related support

[PATCH v5 3/3] drm/bridge: add Silicon Image SiI8620 driver

On 10/10/2016 01:09 PM, Andrzej Hajda wrote: > SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. > It is controlled via I2C bus. Its interaction with other > devices in video pipeline is performed mainly on HW level. > The only interaction it does on device driver level is >

[PATCH v4 2/3] dt-bindings: add Silicon Image SiI8620 bridge bindings

On 10/07/2016 12:32 PM, Andrzej Hajda wrote: > SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. It is controlled > via I2C bus. queued to drm-misc. Thanks, Archit > > Signed-off-by: Andrzej Hajda > Acked-by: Rob Herring > --- > .../bindings/video/bridge/sil-sii8620.txt |

[PATCH v4 1/3] video: add header file for Mobile High-Definition Link (MHL) interface

On 10/07/2016 12:32 PM, Andrzej Hajda wrote: > This header adds definitions specific to MHL protocol. queued to drm-misc. Thanks, Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

[PATCH] drm/nouveau: fix notify data leak

There is no reason to not free the notify data if the NTFY_DEL ioctl failed. As nvif_notify_fini() is also called from the cleanup path of nvif_notify_init(), the notifier may not have been successfully created at that point. But it should also be the right thing to just free the data in the

[RFC PATCH v2 8/9] drm: writeback: Add out-fences for writeback connectors

On Wed, Oct 26, 2016 at 09:55:07AM +0100, Brian Starkey wrote: > Add the OUT_FENCE_PTR property to writeback connectors, to enable > userspace to get a fence which will signal once the writeback is > complete. > > A timeline is added to drm_connector for use by the writeback > out-fences. It is

[PATCH 2/2] drm/msm: Don't provide 'is_enabled' PLL clk_ops

On 10/26/2016 01:58 AM, Stephen Boyd wrote: > On 10/25, Archit Taneja wrote: >> The DSI/HDMI PLLs in MSM require resources like interface clocks, power >> domains to be enabled before we can access their registers. >> >> The clock framework doesn't have a mechanism at the moment where we can >>

[RFC PATCH v2 7/9] drm: atomic: factor out common out-fence operations

On Wed, Oct 26, 2016 at 09:55:06AM +0100, Brian Starkey wrote: > Some parts of setting up the CRTC out-fence can be re-used for > writeback out-fences. Factor this out into a separate function. > > Signed-off-by: Brian Starkey Cc: Gustavo here pls, probably best if he reviews this one. -Daniel

[RFC PATCH v2 1/9] drm: Add writeback connector type

On Wed, Oct 26, 2016 at 09:55:00AM +0100, Brian Starkey wrote: > Writeback connectors represent writeback engines which can write the > CRTC output to a memory framebuffer. Add a writeback connector type and > related support functions. > > Drivers should initialize a writeback connector with >

[Intel-gfx] [PATCH 1/2] drm: Add a new connector property for link status

On Wed, 26 Oct 2016, Chris Wilson wrote: > On Wed, Oct 26, 2016 at 07:52:26AM +0200, Daniel Vetter wrote: >> I'd go further and just always create this as one of the standard >> properties (and always attach it to the connector, like edid), and only >> expose helpers to set the link status to

[Bug 117181] graphic glitches for Kernel > 4.2 Intel HD 5xx and skylake

https://bugzilla.kernel.org/show_bug.cgi?id=117181 Jani Nikula changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[PATCH] drm/i915/vlv: Prevent enabling hpd polling in late suspend

One of the CI machines began to run into issues with the hpd poller suddenly waking up in the midst of the late suspend phase. It looks like this is getting caused by the fact we now deinitialize power wells in late suspend, which means that intel_hpd_poll_init() gets called in late suspend

[PATCH] drm: rcar-du: Fix R-Car Gen3 crash when VSP is disabled

From: Magnus Damm For the DU to operate on R-Car Gen3 hardware a combination of DU and VSP devices are required. Since the DU driver also supports earlier generations hardware the VSP portion is enabled via Kconfig. The arm64 defconfig is as of v4.9-rc1 having the DU

[RFC PATCH v2 7/9] drm: atomic: factor out common out-fence operations

Hi Gustavo, As Daniel rightly pointed out you would likely be interested in this patch. This is on-top of your v5 patch-set, with the bug-fixes I mentioned before. I haven't dropped the fence_get(), as I figured you're probably going to rebase your patches on top of the fence_get() in

[PATCH 4/4] drm/dp/mst: Check peer device type before attempting EDID read

From: Ville Syrjälä Only certain types of pdts have the DDC bus registered, so check for that before we attempt the EDID read. Othwewise we risk playing around with an i2c adapter that doesn't actually exist. Cc: stable at vger.kernel.org Cc: Carlos Santa Cc:

[PATCH 3/4] drm/dp/mst: Clear port->pdt when tearing down the i2c adapter

From: Ville Syrjälä The i2c adapter is only relevant for some peer device types, so let's clear the pdt if it's still the same as the old_pdt when we tear down the i2c adapter. I don't really like this design pattern of updating port->whatever before doing the

[PATCH 2/4] drm/fb-helper: Keep references for the current set of used connectors

From: Ville Syrjälä The fbdev helper code keeps around two lists of connectors. One is the list of all connectors it could use, and that list already holds references for all the connectors. However the other list, or rather lists, is the one actively being used.

[PATCH 1/4] drm/fb-helper: Fix connector ref leak on error

From: Ville Syrjälä We need to drop the connector references already taken when we abort in the middle of drm_fb_helper_single_add_all_connectors() Cc: stable at vger.kernel.org Cc: Carlos Santa Cc: Kirill A. Shutemov Tested-by: Carlos Santa Tested-by: Kirill

[PATCH 0/4] drm: Fix MST oopses in fbdev restore

From: Ville Syrjälä This series would appear to be enough to avoid kernel oopses when trying to restore the fbdev setup after a MST device has been yanked. Apparently we still have some problems left in actually reacting properly to the changed situation, but at

[RFC] dma-buf/fence-array: signal from wq

On Sun, Oct 16, 2016 at 2:54 PM, Chris Wilson wrote: > On Sun, Oct 16, 2016 at 02:29:51PM -0400, Rob Clark wrote: >> On Sun, Oct 16, 2016 at 1:49 PM, Chris Wilson >> wrote: >> > On Sun, Oct 16, 2016 at 12:39:35PM -0400, Rob Clark wrote: >> >> This is the alternative approach for solving a

  1   2   >