From: Dave Airlie
Signed-off-by: Dave Airlie
---
include/drm/drm_crtc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 297e527..6279989 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2606,7 +2606,7
From: Dave Airlie
Don't just free the connector when we get the destroy callback.
Drop a reference to it, and set it's mst_port to NULL so
no more mst work is done on it.
v2: core mst accepts NULLs fine. Cleanup EDID code properly.
v3: drop the extra reference we were taking.
Reviewed-by: Dani
From: Dave Airlie
Take a reference when setting a crtc on a connecter,
also take one when duplicating if a crtc is set,
and drop one on destroy if a crtc is set.
v2: take Daniel Stone's advice and simplify the
ref/unref dances, also take care of NULL as connector
to state reset.
Signed-off-by:
From: Dave Airlie
This just takes a reference on the connector when we set a mode
in the non-atomic paths.
v2: Follow Daniel Stone's suggestions on when to take/drop
references.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc_helper.c | 19 +++
1 file changed, 19 inser
From: Dave Airlie
This takes a reference count when fbdev adds the connector,
and drops it when it removes the connector.
It also drops the now unneeded code to find connectors
and remove the from the modeset as they are reference counted.
v2: drop references when removing all connectors at end
From: Dave Airlie
This uses the previous changes to add reference counts
to drm connector objects.
v2: move fbdev changes to their own patch.
add some kerneldoc
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_atomic.c | 19 +--
drivers/gpu/drm/dr
On Monday 02 May 2016 06:34 PM, Chris Wilson wrote:
On Mon, May 02, 2016 at 02:10:29PM +0530, Praveen Paneri wrote:
i915_gem_shrink() will scan the bound list only if device is not
suspended but in OOM failure scenario it becomes absolutely necessary
to release as much memory as possible. Also
Hi Rob,
Today's linux-next merge of the drm-msm tree got a conflict in:
drivers/gpu/drm/msm/msm_atomic.c
between commit:
a3ccfb9feb46 ("drm/msm: Rename async to nonblock.")
from the drm-misc tree and commit:
afadc4bb9380 ("drm/msm: remove fence_cbs")
from the drm-msm tree.
I fixed it
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/intel_display.c
between commits:
f7e5838bb37d ("drm/i915: Simplify reset_counter handling during atomic
modesetting")
from the drm-intel tree and commit:
81072bfd13f2 ("drm/i915: Rename async
On Mon, May 02, 2016 at 11:11:31AM -0400, Lyude Paul wrote:
> I gave a short try at fixing MST audio, but it definitely looks like it's
> going
> to require quite a bit of troubleshooting and a few more patches :(.
>
> Since I can't find an immediate fix to actually make MST audio work I'm
> tot
On 05/02/2016 04:20 AM, Daniel Vetter wrote:
On Thu, Apr 28, 2016 at 11:57:21AM -0400, Robert Foss wrote:
On 04/28/2016 10:41 AM, Daniel Vetter wrote:
On Thu, Apr 28, 2016 at 10:07:41AM -0400, Robert Foss wrote:
On 04/28/2016 04:02 AM, Daniel Vetter wrote:
On Tue, Apr 26, 2016 at 01:08:
From: Ville Syrjälä
DP dual mode type 1 DVI adaptors aren't required to implement any
registers, so it's a bit hard to detect them. The best way would
be to check the state of the CONFIG1 pin, but we have no way to
do that. So as a last resort, check the VBT to see if the HDMI
port is in fact a d
From: Ville Syrjälä
Try to detect the max TMDS clock limit for the DP++ adaptor (if any)
and take it into account when checking the port clock.
Note that as with the sink (HDMI vs. DVI) TMDS clock limit we'll ignore
the adaptor TMDS clock limit in the modeset path, in case users are
already "ove
From: Ville Syrjälä
To save a bit of power, let's try to turn off the TMDS output buffers
in DP++ adaptors when we're not driving the port.
v2: Let's not forget DDI, toss in a debug message while at it
v3: Just do the TMDS output control based on adaptor type. With the
helper getting passed
From: Ville Syrjälä
Add a helper which aids in the identification of DP dual mode
(aka. DP++) adaptors. There are several types of adaptors
specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI
Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors
may go as high as 300MHz
From: Ville Syrjälä
Here's a respin of my DP++ adaptor support series [1]. Pardon for taking
forever with this. Presumably we want to get this into stable to fix the
regression from HDMI 12bpc support.
I've tried to account for a bunch of Paulo's review comments
I also tried to make the helper
On Mon, May 02, 2016 at 09:40:45PM +0300, Ville Syrjälä wrote:
> On Mon, May 02, 2016 at 11:01:19PM +0530, Thulasimani, Sivakumar wrote:
> > basic question, the old code had linear_offset calculated first and then
> > x & y
> > were updated if rotation was set. the new code looks better since we
On Mon, May 02, 2016 at 11:01:19PM +0530, Thulasimani, Sivakumar wrote:
> sorry for the huge delay in reviewing this series, have just started on
> this and could review only the first
> patch for today, hopefully i'll continue on this everyday this week :).
> replying as a detached thread since
On Monday, May 2, 2016 3:40:14 PM PDT Daniel Stone wrote:
> This commit broke Weston/KMS, and presumably also xf86-video-modesetting.
For me, xf86-video-modesetting, and xf86-video-intel/SNA+DRI3 both work
fine with Y-tiling enabled. However, it does break UXA+DRI3.
I'm curious why xf86-video-mo
On Fri, Apr 29, 2016 at 06:28:14PM -0700, Manasi Navare wrote:
> From: Jim Bride
>
> For DP compliance we need to be able to control the output color
> type for the pipe associated with the DP port. To do this we rely
> on the intel_dp_test_force_bpc debugfs file and the associated value
> stored
sorry for the huge delay in reviewing this series, have just started on
this and could review only the first
patch for today, hopefully i'll continue on this everyday this week :).
replying as a detached thread since
i lost the mails as part original series so please forgive for the
detached re
On Mon, May 02, 2016 at 05:32:53PM +0100, Chris Wilson wrote:
> On Mon, May 02, 2016 at 04:24:30PM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm: Restore double clflush on the last partial cacheline (rev2)
> > URL : https://patchwork.freedesktop.org/series/6573/
> > State
On Mon, May 02, 2016 at 04:24:30PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm: Restore double clflush on the last partial cacheline (rev2)
> URL : https://patchwork.freedesktop.org/series/6573/
> State : failure
>
> == Summary ==
>
> Series 6573v2 drm: Restore double clflus
== Series Details ==
Series: drm: Restore double clflush on the last partial cacheline (rev2)
URL : https://patchwork.freedesktop.org/series/6573/
State : failure
== Summary ==
Series 6573v2 drm: Restore double clflush on the last partial cacheline
http://patchwork.freedesktop.org/api/1.0/seri
This effectively reverts
commit afcd950cafea6e27b739fe7772cbbeed37d05b8b
Author: Chris Wilson
Date: Wed Jun 10 15:58:01 2015 +0100
drm: Avoid the double clflush on the last cache line in
drm_clflush_virt_range()
as we have observed issues with serialisation of the clflush operations
on B
I gave a short try at fixing MST audio, but it definitely looks like it's going
to require quite a bit of troubleshooting and a few more patches :(.
Since I can't find an immediate fix to actually make MST audio work I'm totally
in favor of reverting the MST audio support for the time being
On Th
This commit broke Weston/KMS, and presumably also xf86-video-modesetting.
In order to use Y-tiled buffers, the kernel requires the tiling mode to
be explicitly named through the I915_FORMAT_MOD_Y_TILED AddFB2 modifier;
it disallows any attempt to infer the buffer's tiling mode.
As the GBM API doe
On Mon, May 02, 2016 at 05:33:49PM +0300, Jani Nikula wrote:
> On Mon, 04 Apr 2016, Shashank Sharma wrote:
> > From: Ville Syrjälä
> >
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > MIME-Version: 1.0
> > Content-Type: text/plain; char
On Tue, Apr 26, 2016 at 04:34:05PM +0200, Daniel Vetter wrote:
> On Tue, Apr 26, 2016 at 04:11:33PM +0200, Maarten Lankhorst wrote:
> > Userspace calls the atomic ioctl with DRM_MODE_ATOMIC_NONBLOCK
> > when it doesn't want the ioctl to block for completion.
> >
> > In the kernel it's called async
On Mon, 04 Apr 2016, Shashank Sharma wrote:
> This patch adds a new file for lspcon with
> some basic stuff like:
> - Some read/wrire addresses for lspcon device
> - Basic read/write functions, using i2c over aux channel
> - Utility functions to get lspcon/encoder/connector
>
> Signed-off-by: Shas
On Mon, 04 Apr 2016, Shashank Sharma wrote:
> From: Ville Syrjälä
>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> DP dual mode type 1 DVI adaptor
On Mon, Apr 04, 2016 at 05:31:46PM +0530, Shashank Sharma wrote:
> This patch adds lspcon's internal functions, which work
> on the probe layer, and indicate the working status of
> lspcon, which are mostly:
>
> probe: A lspcon device is probed only once, during boot
> time, as its always present
On ma, 2016-05-02 at 10:28 +0200, Daniel Vetter wrote:
> On Thu, Apr 28, 2016 at 08:15:24PM +0300, Imre Deak wrote:
> > On to, 2016-04-28 at 16:48 +0200, Daniel Vetter wrote:
> > > On Thu, Apr 28, 2016 at 11:38:55AM +0300, Imre Deak wrote:
> > > > On to, 2016-04-28 at 10:17 +0200, Daniel Vetter wro
On Mon, Apr 04, 2016 at 05:31:44PM +0530, Shashank Sharma wrote:
> This patch adds support for LSPCON devices in dp++ adaptor
> helper layer. LSPCON is DP++ type-2 adaptor with some customized
> functionalities, to provide additional features in Intel Gen9 HW.
>
> LSPCON needs I2C-over-aux support
On Tue, 26 Apr 2016, Jani Nikula wrote:
> From: Deepak M
>
> These fields in VBT indicates the PWM source which
> is used and also the controller number.
>
> v2 by Jani: check for out of bounds access, some renames, change default
> type, etc.
>
> v3 by Jani: s/INTEL_BACKLIGHT_CABC/INTEL_BACKLIGH
On Mon, Apr 04, 2016 at 05:31:42PM +0530, Shashank Sharma wrote:
> This patch adds a new file for lspcon with
> some basic stuff like:
> - Some read/wrire addresses for lspcon device
> - Basic read/write functions, using i2c over aux channel
> - Utility functions to get lspcon/encoder/connector
>
On Mon, May 02, 2016 at 02:10:29PM +0530, Praveen Paneri wrote:
> i915_gem_shrink() will scan the bound list only if device is not
> suspended but in OOM failure scenario it becomes absolutely necessary
> to release as much memory as possible. Also in allocation failure from
> vmap address space, i
Chris Wilson writes:
> [ text/plain ]
> This effectively reverts
>
> commit afcd950cafea6e27b739fe7772cbbeed37d05b8b
> Author: Chris Wilson
> Date: Wed Jun 10 15:58:01 2015 +0100
>
> drm: Avoid the double clflush on the last cache line in
> drm_clflush_virt_range()
>
> as we have observed
Calculate the DDB blocks needed to satisfy the current atomic
transaction at atomic check time. This is a prerequisite to calculating
SKL watermarks during the 'check' phase and rejecting any configurations
that we can't find valid watermarks for.
Due to the nature of DDB allocation, it's possibl
On Mon, May 02, 2016 at 10:28:50AM +0200, Daniel Vetter wrote:
> On Thu, Apr 28, 2016 at 08:15:24PM +0300, Imre Deak wrote:
> > On to, 2016-04-28 at 16:48 +0200, Daniel Vetter wrote:
> > > On Thu, Apr 28, 2016 at 11:38:55AM +0300, Imre Deak wrote:
> > > > On to, 2016-04-28 at 10:17 +0200, Daniel Ve
Op 02-05-16 om 11:22 schreef Patrik Jakobsson:
> On Tue, Apr 19, 2016 at 09:52:28AM +0200, Maarten Lankhorst wrote:
>> This will be required to allow more than 1 update in the future.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/i915_debugfs.c | 90 +
On Mon, May 02, 2016 at 10:51:31AM +0200, Daniel Vetter wrote:
> Imo the low-level irq clearing should all be done in the relevant irq
> setup code in i915_irq.c. Atm we just forgot to do that. I guess you can
> have a bikeshed whether the enginer IMR enable/disable functions should be
> together w
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix modeset handling during gpu
reset, v2.
URL : https://patchwork.freedesktop.org/series/6600/
State : failure
== Summary ==
Series 6600v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/6600/revisi
On Tue, Apr 19, 2016 at 09:52:28AM +0200, Maarten Lankhorst wrote:
> This will be required to allow more than 1 update in the future.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 90 +-
> drivers/gpu/drm/i915/i915_drv.h |
== Series Details ==
Series: series starting with [1/2] drm/i915: Unbind objects in shrinker only if
device is runtime active
URL : https://patchwork.freedesktop.org/series/6598/
State : success
== Summary ==
Series 6598v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/s
On 5/2/2016 2:38 PM, Shubhangi Shrivastava wrote:
This patch is intended to read test values only. Call to
intel_dp_start_link_train will be in upcoming patch "Lane count change
detection", which I will be posting after this patch series..
On Tuesday 26 April 2016 09:39 AM, Navare, Manasi D
On Fri, Apr 29, 2016 at 05:31:18PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> When the crtc is enabled but !active, we should still compute the
> watermarks as if the planes were visible. That would make it more
> likely that the we can later transition to active withou
On Fri, Apr 29, 2016 at 03:35:43PM +0300, Jani Nikula wrote:
> On Fri, 29 Apr 2016, Ville Syrjälä wrote:
> > On Fri, Apr 29, 2016 at 01:12:33PM +0300, Ville Syrjälä wrote:
> >> On Fri, Apr 29, 2016 at 12:36:35PM +0300, Jani Nikula wrote:
> >> > We also don't read the border bits in i9xx_get_pfit_c
It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.
drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impo
This patch is intended to read test values only. Call to
intel_dp_start_link_train will be in upcoming patch "Lane count change
detection", which I will be posting after this patch series..
On Tuesday 26 April 2016 09:39 AM, Navare, Manasi D wrote:
The automated test request for link training
Hi Dave, i915 fixes for 4.6. A bit more than I'd like at this stage, but
OTOH they're all stable material.
BR,
Jani.
The following changes since commit 02da2d72174c61988eb4456b53f405e3ebdebce4:
Linux 4.6-rc5 (2016-04-24 16:17:05 -0700)
are available in the git repository at:
git://anongit
On Thu, Apr 28, 2016 at 07:36:32PM +0100, Dave Gordon wrote:
> On 28/04/16 18:48, Patchwork wrote:
> >== Series Details ==
> >
> >Series: series starting with [1/2] drm/i915: introduce & use
> >i915_gem_object_mark_dirty()
> >URL : https://patchwork.freedesktop.org/series/6491/
> >State : warnin
On May 1, 2016 6:04 PM, "Kenneth Graunke" wrote:
>
> On Sunday, May 1, 2016 9:51:00 AM PDT Emil Velikov wrote:
> > On 28 April 2016 at 19:13, Eric Engestrom
wrote:
> > > On Mon, Apr 25, 2016 at 05:08:18PM +0100, Emil Velikov wrote:
> > >> On 21 April 2016 at 11:24, Eric Engestrom
> wrote:
> > >>
Add force_reset_modeset_test as a parameter to force the modeset path during
gpu reset.
This allows a IGT test to set the knob and trigger a hang to force the gpu
reset,
even on platforms that wouldn't otherwise require it.
Changes since v1:
- Split out fix to separate commit.
Changes since v2:
This function would call drm_modeset_lock_all, while the suspend/resume
functions already have their own locking. Fix this by factoring out
__intel_display_resume, and calling the atomic helpers for duplicating
atomic state and disabling all crtc's during suspend.
Changes since v1:
- Deal with -ED
On Thu, Apr 28, 2016 at 05:24:31PM +0100, Chris Wilson wrote:
> We have sufficient evidence from igt to support that semaphores are in
> a working state. Enabling semaphores now for legacy provides a better
> comparison of execlists against legacy ring submission.
>
> Signed-off-by: Chris Wilson
On Fri, Apr 29, 2016 at 11:22:59AM +0100, Chris Wilson wrote:
> On Fri, Apr 29, 2016 at 11:11:20AM +0100, Tvrtko Ursulin wrote:
> >
> > On 29/04/16 11:00, Chris Wilson wrote:
> > >On Fri, Apr 29, 2016 at 10:50:02AM +0100, Tvrtko Ursulin wrote:
> > >>
> > >>On 29/04/16 10:39, Chris Wilson wrote:
>
== Series Details ==
Series: drm/gem: support BO freeing without dev->struct_mutex
URL : https://patchwork.freedesktop.org/series/6527/
State : failure
== Summary ==
Series 6527v1 drm/gem: support BO freeing without dev->struct_mutex
http://patchwork.freedesktop.org/api/1.0/series/6527/revisio
== Series Details ==
Series: drm/gem: support BO freeing without dev->struct_mutex
URL : https://patchwork.freedesktop.org/series/6527/
State : failure
== Summary ==
Series 6527v1 drm/gem: support BO freeing without dev->struct_mutex
http://patchwork.freedesktop.org/api/1.0/series/6527/revisio
Finally all the core gem and a lot of drivers are entirely free of
dev->struct_mutex depencies, and we can start to have an entirely
lockless unref path.
To make sure that no one who touches the core code accidentally breaks
existing drivers which still require dev->struct_mutex I've made the
migh
i915_gem_shrink() will scan the bound list only if device is not
suspended but in OOM failure scenario it becomes absolutely necessary
to release as much memory as possible. Also in allocation failure from
vmap address space, it is incumbent on the Driver to reap all its
vmaps. So, adding rpm get/p
When the system is running low on memory, gem shrinker is invoked.
In this process objects will be unbounded from GTT and unbinding process
will require access to GTT(GTTADR) and also to fence register potentially.
That requires a resume of gfx device, if suspended, in the shrinker path.
Considerin
On Thu, Apr 28, 2016 at 08:15:24PM +0300, Imre Deak wrote:
> On to, 2016-04-28 at 16:48 +0200, Daniel Vetter wrote:
> > On Thu, Apr 28, 2016 at 11:38:55AM +0300, Imre Deak wrote:
> > > On to, 2016-04-28 at 10:17 +0200, Daniel Vetter wrote:
> > > > Also, you're guaranateeing that opencl/libva don't
On Thu, Apr 28, 2016 at 11:57:21AM -0400, Robert Foss wrote:
>
>
> On 04/28/2016 10:41 AM, Daniel Vetter wrote:
> >On Thu, Apr 28, 2016 at 10:07:41AM -0400, Robert Foss wrote:
> >>
> >>
> >>On 04/28/2016 04:02 AM, Daniel Vetter wrote:
> >>>On Tue, Apr 26, 2016 at 01:08:35PM -0400, Robert Foss wro
On Fri, Apr 29, 2016 at 11:31:44AM +0200, Linus Walleij wrote:
> On Fri, Apr 22, 2016 at 9:38 PM, wrote:
>
> > From: Ville Syrjälä
> >
> > GPIO lookup tables are supposed to be zero terminated. Let's do that
> > and avoid accidentally walking off the end.
> >
> > Cc: Shobhit Kumar
> > Cc: Samu
On Sun, Apr 24, 2016 at 10:53:27AM -, Patchwork wrote:
> == Series Details ==
>
> Series: mfd: intel_soc_pmic_core: Terminate panel control GPIO lookup table
> correctly
> URL : https://patchwork.freedesktop.org/series/6186/
> State : failure
>
> == Summary ==
>
> Series 6186v1 mfd: intel
On Sat, 30 Apr 2016, Josh Litherland wrote:
> Hoping someone can point me in the right direction to understanding
> how intel_connector->panel.fixed_mode gets probed, as it's referenced
> in function "intel_dp_mode_valid" at drivers/gpu/drm/i915/intel_dp.c.
>
> I am working with a panel hooked up
67 matches
Mail list logo
