On 29/09/16 09:30, Westerberg, Mika wrote:
> On Wed, Sep 28, 2016 at 05:50:00PM -0400, Giacomo Comes wrote:
>> On Mon, Sep 26, 2016 at 12:52:11PM +0300, Westerberg, Mika wrote:
>>> On Mon, Sep 26, 2016 at 11:57:04AM +0300, Jani Nikula wrote:
On Wed, 21 Sep 2016, Giacomo Comes wrote:
> Hi,
This reverts 'commit 3708d5e082c3 ("drm/i915: start adding dp mst audio")'
because it breaks MST multi-monitor setups on some platforms.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97907
Signed-off-by: Dhinakaran Pandiyan
Reported-by: Kim Lidström
Cc: Libin Yang
Cc: Lyude
Cc: Jani Nikul
On Tue, Sep 27, 2016 at 08:07:01PM +0300, Jani Nikula wrote:
> On Tue, 27 Sep 2016, Manasi Navare wrote:
> > On Mon, Sep 26, 2016 at 04:39:34PM +0300, Jani Nikula wrote:
> >> On Fri, 16 Sep 2016, Manasi Navare wrote:
> >> > According to the DisplayPort Spec, in case of Clock Recovery failure
> >>
On Wed, Sep 28, 2016 at 05:50:00PM -0400, Giacomo Comes wrote:
> On Mon, Sep 26, 2016 at 12:52:11PM +0300, Westerberg, Mika wrote:
> > On Mon, Sep 26, 2016 at 11:57:04AM +0300, Jani Nikula wrote:
> > > On Wed, 21 Sep 2016, Giacomo Comes wrote:
> > > > Hi,
> > > > I hope this is the appropriate pla
== Series Details ==
Series: drm: Add frame CRC debugfs files only for drivers that have CRTC
URL : https://patchwork.freedesktop.org/series/13053/
State : success
== Summary ==
Series 13053v1 drm: Add frame CRC debugfs files only for drivers that have CRTC
https://patchwork.freedesktop.org/ap
vgem does not do modeset, looping through non-existent CRTC's while
registering drm_minor in
'commit 48c787899882 ("drm: Add API for capturing frame CRCs")'
caused kernel oops. So, let's add CRC debugfs files
only for those drivers that do modeset.
Signed-off-by: Dhinakaran Pandiyan
Cc:
== Series Details ==
Series: drm: Restore lost drm_framebuffer_unreference in
drm_mode_page_flip_ioctl
URL : https://patchwork.freedesktop.org/series/13045/
State : success
== Summary ==
Series 13045v1 drm: Restore lost drm_framebuffer_unreference in
drm_mode_page_flip_ioctl
https://patchwor
On Wed, Sep 28, 2016 at 10:14:45AM +0300, Jani Nikula wrote:
> On Wed, 28 Sep 2016, Manasi Navare wrote:
> > On Tue, Sep 27, 2016 at 04:39:38PM +0300, Jani Nikula wrote:
> >> On Mon, 26 Sep 2016, Jani Nikula wrote:
> >> > On Fri, 16 Sep 2016, Manasi Navare wrote:
> >> >> While configuring the pi
Commit 43968d7b806d ("drm: Extract drm_plane.[hc]") was not the simple
cut'n'paste we presumed, somehow it introduced a leak of the page flip
target's framebuffer.
Fixes: 43968d7b806d ("drm: Extract drm_plane.[hc]")
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Sean Paul
---
drivers/gpu/dr
On Mon, Sep 26, 2016 at 12:52:11PM +0300, Westerberg, Mika wrote:
> On Mon, Sep 26, 2016 at 11:57:04AM +0300, Jani Nikula wrote:
> > On Wed, 21 Sep 2016, Giacomo Comes wrote:
> > > Hi,
> > > I hope this is the appropriate place to ask what follows.
> > > If not please point me to the right place.
On Wed, Sep 28, 2016 at 9:51 AM, wrote:
> From: Ville Syrjälä
>
> Rebased the series (previous version [1]) mostly due to code
> shuffling. i915 specific bits still need to be eyeballed by someone.
>
> Series available here:
> git://github.com/vsyrjala/linux.git hdmi_sink_tmds_limit_4
>
> [1] ht
On Wed, Sep 28, 2016 at 04:23:50PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Once we know we need to take new forcewakes, that being
> a slow operation, it does not make sense to inline that
> code into every mmio accessor.
>
> Move it to a separate function and save some code.
>
On Wed, Sep 28, 2016 at 01:25:44PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> They are completely identical to gen6_write* ones.
iirc, the difference used to be mmiodebug.
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Techn
== Series Details ==
Series: drm/i915: Cleanup i915_gem_request_add_to_client (rev3)
URL : https://patchwork.freedesktop.org/series/12959/
State : success
== Summary ==
Series 12959v3 drm/i915: Cleanup i915_gem_request_add_to_client
https://patchwork.freedesktop.org/api/1.0/series/12959/revisi
On Wed, Sep 28, 2016 at 05:48:23PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Several things we can clean up in this function:
>
> * Request and file passed in cannot be NULL. There is
>a single caller which makes it impossible so change
>that condition to a GEM_BUG_ON inst
From: Tvrtko Ursulin
Several things we can clean up in this function:
* Request and file passed in cannot be NULL. There is
a single caller which makes it impossible so change
that condition to a GEM_BUG_ON instead of a WARN
with a return code.
* Same is true for req->file_priv which
On Wed, Sep 28, 2016 at 10:38:37AM +0300, Jani Nikula wrote:
> On Wed, 28 Sep 2016, Manasi Navare wrote:
> > On Mon, Sep 26, 2016 at 04:41:27PM +0300, Jani Nikula wrote:
> >> On Fri, 16 Sep 2016, Manasi Navare wrote:
> >> > While configuring the pipe during modeset, it should use
> >> > max clock
== Series Details ==
Series: Misc forcewake patches (rev2)
URL : https://patchwork.freedesktop.org/series/13016/
State : success
== Summary ==
Series 13016v2 Misc forcewake patches
https://patchwork.freedesktop.org/api/1.0/series/13016/revisions/2/mbox/
fi-bdw-5557u total:33 pass:26
From: Tvrtko Ursulin
Once we know we need to take new forcewakes, that being
a slow operation, it does not make sense to inline that
code into every mmio accessor.
Move it to a separate function and save some code.
v2: Be explicit with noinline and remove stale comment.
(Chris Wilson)
Sign
== Series Details ==
Series: drm/edid: Clean up display_info stuff (rev2)
URL : https://patchwork.freedesktop.org/series/10580/
State : warning
== Summary ==
Series 10580v2 drm/edid: Clean up display_info stuff
https://patchwork.freedesktop.org/api/1.0/series/10580/revisions/2/mbox/
Test kms_
On Wed, Sep 28, 2016 at 02:32:19PM +0300, Ander Conselvan De Oliveira wrote:
> On Mon, 2016-09-26 at 11:30 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it
> > forbidden to set it for LVDS/CRT as well.
From: Ville Syrjälä
Reduce the eyesore with a local variable.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
in
From: Ville Syrjälä
Instead of parsing parts of the CEA extension block in two places
to determine supported color formats and whatnot, let's just
consolidate it to one function. This also makes it possible to neatly
flatten drm_assign_hdmi_deep_color_info().
Signed-off-by: Ville Syrjälä
Acked-
From: Ville Syrjälä
Clear out stale audio latency information (potentially from a previous
EDID) before constructing the ELD from the EDID.
Signed-off-by: Ville Syrjälä
Acked-by: Christian König
---
drivers/gpu/drm/drm_edid.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/
From: Ville Syrjälä
We have the drm_display_info for storing information about the sink, so
let's move dvi_dual and max_tmds_clock in there.
v2: Deal with superfluous code shuffling
Document dvi_dual and max_tmds_clock too
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Ville Syrjäl
From: Ville Syrjälä
We generally store clocks in kHz, so let's do that for the
HDMI max TMDS clock value as well. Less surpising.
v2: Deal with superfluous code shuffling
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Ville Syrjälä
Reviewed-by: Christian König (v1)
---
drivers/gpu/d
From: Ville Syrjälä
We already pass the connector to drm_add_display_info() and
drm_assign_hdmi_deep_color_info(), so passing the
connector->display_info also is pointless.
Signed-off-by: Ville Syrjälä
Acked-by: Christian König
---
drivers/gpu/drm/drm_edid.c | 8
1 file changed, 4 in
From: Ville Syrjälä
Clear out old max_tmds_clock and dvi_dual information (possibly from a
previous EDID) before parsing the current EDID. Tne current EDID might
not even have these in its HDMI VSDB, which would mean that we'd leave
the old stale values in place.
Signed-off-by: Ville Syrjälä
Ac
From: Ville Syrjälä
It's not a good idea to leave stale cea_rev in the drm_display_info. The
current EDID might not even have a CEA ext block in which case we'd end
up leaving the stale value in place.
Signed-off-by: Ville Syrjälä
Acked-by: Christian König
---
drivers/gpu/drm/drm_edid.c | 1 +
From: Ville Syrjälä
drm_edid_to_eld() is just mean to cook up the ELD for the audio driver,
so having it parse non-audio related stuff seems just wrong, and
potentially could lead to that information not being even filled out
if the function doesn't even get called. Let's move that stuff to the
p
From: Ville Syrjälä
It's perfectly legal for the sink to support 12bpc only for
some lower resolution modes, while the higher resolution modes
can only be used with 8bpc. So let's take the sink's max TMDS clock
into account before we go and decide that a particular mode can
be used with 12bpc.
S
From: Ville Syrjälä
Rebased the series (previous version [1]) mostly due to code
shuffling. i915 specific bits still need to be eyeballed by someone.
Series available here:
git://github.com/vsyrjala/linux.git hdmi_sink_tmds_limit_4
[1] https://lists.freedesktop.org/archives/dri-devel/2016-Augus
On ke, 2016-09-28 at 13:25 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> They are completely identical to gen6_write* ones.
Seems to be true.
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
On ti, 2016-09-27 at 10:44 +0100, Tvrtko Ursulin wrote:
> -int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
> - struct drm_file *file)
> +void i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
> + str
== Series Details ==
Series: Misc forcewake patches
URL : https://patchwork.freedesktop.org/series/13016/
State : warning
== Summary ==
Series 13016v1 Misc forcewake patches
https://patchwork.freedesktop.org/api/1.0/series/13016/revisions/1/mbox/
Test kms_pipe_crc_basic:
Subgroup nonb
On Wed, Sep 28, 2016 at 01:25:46PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Once we know we need to take new forcewakes, that being
> a slow operation, it does not make sense to inline that
> code into every mmio accessor.
>
> Move it to a separate function and save some code.
>
From: Tvrtko Ursulin
They are completely identical to gen6_write* ones.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_uncore.c | 25 +
1 file changed, 1 insertion(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i91
From: Tvrtko Ursulin
Apart from 2/3 which I already sent yesterday, there are
two new patches here and the end result of the series is
approximately 3KiB reduction in i915.ko text size.
Tvrtko Ursulin (3):
drm/i915: Remove redundant hsw_write* mmio functions
drm/i915: Keep track of active fo
From: Tvrtko Ursulin
There are current places in the code, and there will be more in the
future, which iterate the forcewake domains to find out which ones
are currently active.
To save them from doing this iteration, we can cheaply keep a mask
of active domains in dev_priv->uncore.fw_domains_ac
From: Tvrtko Ursulin
Once we know we need to take new forcewakes, that being
a slow operation, it does not make sense to inline that
code into every mmio accessor.
Move it to a separate function and save some code.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_uncore.c | 25 +++
On Wed, 28 Sep 2016, Manasi Navare wrote:
> From: "Navare, Manasi D"
>
> Replace dev with dev_priv and INTEL_INFO with INTEL_GEN
>
> v1:
> * Rebased on drm-nightly (Jani Nikula)
> * Separated from the link training patch series
>
> Signed-off-by: Manasi Navare
> Reviewed-by: Mika Kahola
Pushed
On Wed, Sep 28, 2016 at 02:32:19PM +0300, Ander Conselvan De Oliveira wrote:
> On Mon, 2016-09-26 at 11:30 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it
> > forbidden to set it for LVDS/CRT as well.
On Mon, 2016-09-26 at 11:30 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it
> forbidden to set it for LVDS/CRT as well. So let's also set it on
> CRT to make it possible to share the DPLL between HDMI and C
== Series Details ==
Series: drm/i915: Cleanup i915_gem_request_add_to_client (rev2)
URL : https://patchwork.freedesktop.org/series/12959/
State : failure
== Summary ==
Series 12959v2 drm/i915: Cleanup i915_gem_request_add_to_client
https://patchwork.freedesktop.org/api/1.0/series/12959/revisi
== Series Details ==
Series: drm/i915: Cleanup i915_gem_request_add_to_client (rev2)
URL : https://patchwork.freedesktop.org/series/12959/
State : warning
== Summary ==
Series 12959v2 drm/i915: Cleanup i915_gem_request_add_to_client
https://patchwork.freedesktop.org/api/1.0/series/12959/revisi
From: Tvrtko Ursulin
Several things we can clean up in this function:
* Request and file passed in cannot be NULL. There is
a single caller which makes it impossible so change
that condition to a GEM_BUG_ON instead of a WARN
with a return code.
* Same is true for req->file_priv which
On Wed, 28 Sep 2016, Manasi Navare wrote:
> On Mon, Sep 26, 2016 at 04:41:27PM +0300, Jani Nikula wrote:
>> On Fri, 16 Sep 2016, Manasi Navare wrote:
>> > While configuring the pipe during modeset, it should use
>> > max clock and max lane count and reduce the bpp until
>> > the requested mode ra
On Wed, 28 Sep 2016, Manasi Navare wrote:
> On Tue, Sep 27, 2016 at 04:39:38PM +0300, Jani Nikula wrote:
>> On Mon, 26 Sep 2016, Jani Nikula wrote:
>> > On Fri, 16 Sep 2016, Manasi Navare wrote:
>> >> While configuring the pipe during modeset, it should use
>> >> max clock and max lane count and
48 matches
Mail list logo
