Reviewed-by: Lyude
On Wed, 2016-08-31 at 17:20 -0700, Dhinakaran Pandiyan wrote:
> Now that we have the port enum stored in intel_encoder, use that instead of
> dereferencing intel_dig_port. Saves us a few locals.
>
> struct intel_encoder variables have been renamed to be consistent and
> convey
This series lays the groundwork for more DP MST audio work that will
follow.
Rebased and fixed typos this time.
v2:
Different solution replacing the enc_to_dig_port() fix (Ville, Lyude).
No changes to MST audio enabling and move audio_connector patches.
Reordered the patches (Lyude)
v3:
Differen
From: Libin Yang
(This patch is developed by Dave Airlie originally)
This patch adds support for DP MST audio in i915.
Enable audio codec when DP MST is enabled if has_audio flag is set.
Disable audio codec when DP MST is disabled if has_audio flag is set.
Another separated patches to support
Storing the port enum in intel_encoder makes it convenient to know the
port attached to an encoder. Moving the port information up from
intel_digital_port to intel_encoder avoids unecessary intel_digital_port
access and handles MST encoders cleanly without requiring conditional
checks for them (tha
With DP MST, a digital_port can carry more than one audio stream. Hence,
more than one audio_connector needs to be attached to intel_digital_port in
such cases. However, each stream is associated with an unique encoder. So,
instead of creating an array of audio_connectors per port, move
audio_conne
Now that we have the port enum stored in intel_encoder, use that instead of
dereferencing intel_dig_port. Saves us a few locals.
struct intel_encoder variables have been renamed to be consistent and
convey type information.
v2:
Fix incorrect 'enum port' member names - s/attached_port/port
Signed
On Wed, 2016-08-31 at 21:51 +, Zanoni, Paulo R wrote:
> Hi
>
> Em Qua, 2016-08-31 às 14:43 -0700, James Bottomley escreveu:
> > On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote:
> > >
> > > On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote:
> > > >
> > > > We seem to have an x
Hi
Em Qua, 2016-08-31 às 14:43 -0700, James Bottomley escreveu:
> On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote:
> >
> > On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote:
> > >
> > > We seem to have an xrandr regression with skylake now. What's
> > > happening is that I can g
On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote:
> On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote:
> > We seem to have an xrandr regression with skylake now. What's
> > happening is that I can get output on to a projector, but the
> > system is losing video when I change the xr
On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote:
> We seem to have an xrandr regression with skylake now. What's
> happening is that I can get output on to a projector, but the system
> is losing video when I change the xrandr sessions (like going from a
> --above b to a --same-as b).
Le 30/08/16 à 21:28, Paolo Stivanin a écrit :
Hello,
nope, also after suspend nothing changed.
I also tried using evtest before and after the patch and I got the same
result: nothing shows up when I press FN+F8/F9 (brightness)
Hello,
Tested on an asus ux305FA, work only after fresh boot, not w
Hi Dave,
More -misc stuff
- moar drm_crtc.c split up&documentation
- some fixes for the simple kms helpers (Andrea)
- I included all the dri1 patches from David - we're not removing any code
or drivers, and it seems to have worked as a wake-up call to motivate a
few more people to upstream kms
The data in this struct is provided both by getting the
slice/subslice/eu features available on a given platform and the actual
runtime state of these same features which depends on the HW's current
power saving state.
Atm members of this struct are duplicated in sseu_dev_status and
intel_device_i
Reviewed-by: Robert Bragg
Reviewed-by: Ben Widawsky
Tested-by: Ben Widawsky
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
drivers/gpu/drm/i915/intel_device_info.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/dri
Currently when checking for fused off EUs we may ignore the EU count in
an enabled slice if there is any disabled slice preceding the enabled
one (with a lower slice ID). Perhaps this can't happen in reality, but
there is no reason to have this assumption built-in, the code is clearer
without it.
Move all slice/subslice/eu related properties to the sseu_dev_info
struct.
No functional change.
v2:
- s/info/sseu/ based on the new struct name. (Ben)
Reviewed-by: Robert Bragg (v1)
Reviewed-by: Ben Widawsky (v1)
Tested-by: Ben Widawsky (v1)
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i91
Reviewed-by: Robert Bragg
Reviewed-by: Ben Widawsky
Tested-by: Ben Widawsky
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_debugfs.c | 64 -
1 file changed, 34 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/driver
In an upcoming patch we'll need the actual mask of slices in addition to
their count, so replace the count field with a mask.
v2:
- Use hweight8() on u8 typed vars instead of hweight32(). (Ben)
Reviewed-by: Robert Bragg (v1)
Reviewed-by: Ben Widawsky (v1)
Tested-by: Ben Widawsky (v1)
Signed-of
In an upcoming patch we'll need the actual mask of subslices in addition
to their count, so convert the subslice_per_slice field to a mask.
Also we can easily calculate subslice_total from the other fields, so
instead of storing a cached version of this, add a helper to calculate
it.
v2:
- Use hwe
This is v2 of [1] rebased on latest -nightly and addressing the comments
from Ben. It's needed by the per-slice/-subslice INSTDONE readout
patchset from Ben that I'm planning to send as a follow-up to this.
[1]
https://lists.freedesktop.org/archives/intel-gfx/2015-October/078543.html
Imre Deak (7
Just pure code movement, cleanup and polish will happen in later
patches.
v2: Don't forget all the ioctl! To extract those cleanly I decided to
put check_src_coords into drm_framebuffer.c (and give it a
drm_framebuffer_ prefix), since that just checks framebuffer
constraints.
Signed-off-by: Danie
Again move it from the unmaintainable csv into DOC free-form overview
sections.
Cc: Lionel Landwerlin
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst| 12 +
Documentation/gpu/kms-properties.csv | 5
drivers/gpu/drm/drm_color_mgmt.c | 48 +
Big thing is untangling and carefully documenting the different uapi
types of planes. I also sprinkled a few more cross references around
to make this easier to discover.
As usual, remove the kerneldoc for internal functions which are not
exported. Aside: We should probably go OCD on all the ioctl
Imo zpos, rotatation, blending eq (once we have it) and all that
should be in drm_blend.c, since those are all about how exactly the
pixels are rendered onto the CRTC's visible area. Also noticed that
one exported function accidentally ended up in drm_crtc_internal.h,
move it to the right place too
For both the new degamm/lut/gamma atomic combo, and the old legacy
gamma tables.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_color_mgmt.c| 248
drivers/gpu/drm/drm_crtc.c | 220 --
We don't want to burry the bridge structures kerneldoc in drm_crtc.h.
Cc: Archit Taneja
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 7 ++
drivers/gpu/drm/drm_bridge.c | 5 +-
include/drm/drm_bridge.h | 218 ++
We removed it in
commit 6ab10b76ff6252bd9be0849c40f5865e39a29961
Author: Daniel Vetter
Date: Fri Aug 12 22:48:45 2016 +0200
drm/kms: Nuke dirty_info property
Signed-off-by: Daniel Vetter
---
Documentation/gpu/kms-properties.csv | 1 -
1 file changed, 1 deletion(-)
diff --git a/Document
Some were still left in drm_crtc.h. Also include drm_edid.h in the
rst files.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 3 +++
include/drm/drm_crtc.h| 30 +-
include/drm/drm_edid.h| 30 +++
Hi all,
It's not entirely done yet, there's a few (very small bits) left in drm_crtc.c
which aren't for struct drm_crtc. But I figured it's better to keep things in
manageable pieces.
More important this now contains my proposal for how to best document (atomic)
property extensions. I grouped and
Now that there's less stuff in there I noticed that I overlooked them.
Sprinkle some docs over them while at it.
Signed-off-by: Daniel Vetter
---
include/drm/drm_connector.h | 24 ++--
include/drm/drm_crtc.h| 32
include/drm/drm_enco
Try to spec a bit more precisely how they all fit together, now that
at least the code is for all the additional properties is in one
place.
Also remove the entries for the standardized properties from the
table, because that thing is supremely unmaintaineable.
Cc: Ville Syrjälä
Cc: Sean Paul
C
Hi,
In this series, I'm not equalizing watermarks among planes of all
CRTC's, these patches equalizing it only among Planes of single CRTC
from DDB pool allocated for that CRTC, which doesn't require wait_for_vblank
So it'll not affect the FPS.
On Wednesday 31 August 2016 07:08 PM, Maarten Lan
earlier implementation of "DDB writing" was using this flag before
wait_for_vblank if we need to expand the DDB & it overlap with other
pipe's DDB.
In that case, I observed on corner case requiring a cd-clock change,
intel_update_watermarks was waiting for vblank, when it was called from
haswel
Em Ter, 2016-08-30 às 19:32 +, Zanoni, Paulo R escreveu:
> Hi
>
> Em Seg, 2016-08-29 às 18:05 +0530, Kumar, Mahesh escreveu:
> >
> > This patch enables Transition WM for SKL+ platforms.
> >
> > Transition WM are used if IPC is enabled, to decide, number of
> > blocks
> > to be fetched before
Hey,
Op 29-08-16 om 14:35 schreef Kumar, Mahesh:
> This patch implements new DDB allocation algorithm as per HW team
> suggestion. This algo takecare of scenario where we allocate less DDB
> for the planes with lower relative pixel rate, but they require more DDB
> to work.
> It also takes care of
On ti, 2016-08-30 at 11:00 +0100, Chris Wilson wrote:
> +static void store_dword(int fd, unsigned ring,
> + uint32_t target, uint32_t offset, uint32_t value)
> +{
I'd prefer a library function (as you obviously copied this from
gem_exec_store.c), as we have more similar functio
On ke, 2016-08-31 at 10:11 +0100, Chris Wilson wrote:
> With the last user of this convenience wrapper gone, we can kill the
> wrapper and in the process make the lookup function static.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Sourc
== Series Details ==
Series: series starting with [1/9] drm: Add reference counting to
drm_atomic_state
URL : https://patchwork.freedesktop.org/series/11818/
State : failure
== Summary ==
Series 11818v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/11818/revision
On Sat, 2016-08-27 at 14:33 +0100, Matthew Auld wrote:
> Currently it's entirely possible to go through the link training step
> without first determining the lane_count, which is silly since we end
> up
> doing a bunch of aux transfers of size = 0, as highlighted by
> WARN_ON(!msg->buffer != !msg-
On 30/08/2016 09:18, Chris Wilson wrote:
Drive final request submission from a callback from the fence. This way
the request is queued until all dependencies are resolved, at which
point it is handed to the backend for queueing to hardware. At this
point, no dependencies are set on the request, s
Op 29-08-16 om 14:35 schreef Kumar, Mahesh:
> Set the intel_crtc->active flag after pipe/crtc is actually active in
> haswell_crtc_enable function.
>
> Signed-off-by: Kumar, Mahesh
I think more state needs to be pre-calculated, rather than touching
intel_crtc->active.
Something like using the .in
Since an fb may have multiple VMA (due to rotations etc), we need to
wait a vblank and unpin the old VMA not if the fb itself is changed, but
if the underlying VMA is changed.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 10 +++---
1 file changed, 7 insertions(+), 3
drm_atomic_state has a complicated single owner model that tracks the
single reference from allocation through to destruction on another
thread - or perhaps on a local error path. We can simplify this tracking
by using reference counting (at a cost of a few more atomics). This is
even more benefici
The current meaning of whether an object has a GGTT vma is very
ill-defined (and note we don't check for any partials either), it just
means that at some point it was in the GGTT but it may not be now. The
information we really care about here is whether it is taking up
precious mappable aperture s
In the next patch, a few rearrangements are made to make these static.
First, we move them so the changes are not lost in the noise.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 239 ++-
1 file changed, 120 insertions(+), 119 deletions(-)
The generic atomic helper likes to skip a prepare_plane_fb() if it
decides that the plane->fb is unchanged. This is wrong for us for a
couple of reasons:
- if the pipe is reconfigured (i.e. a size change) but the framebuffer
is untouched, we still have to flush any rendering prior to the
re
With the last user of this convenience wrapper gone, we can kill the
wrapper and in the process make the lookup function static.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 12
drivers/gpu/drm/i915/i915_gem_gtt.c | 24
2 files chang
With atomic plane states we are able to track an allocation right from
preparation, during use and through to the final free after being
swapped out for a new plane. We can couple the VMA we pin for the
framebuffer (and its rotation) to this lifetime and avoid all the clumsy
lookups in between.
Si
Just a quick tidy now to make the next patch neater.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 43 +---
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_
Now that we subclass our request from struct fence, we start using the
common primitives more freely and so avoid hand-rolling routines already
provided for by the helpers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 3 --
drivers/gpu/drm/i915/intel_display.c
On ti, 2016-08-30 at 12:18 +0100, Chris Wilson wrote:
> Now that we have fences in place to drive request submission, we can
> employ those to queue requests after their dependencies as opposed to
> stalling in the middle of an execbuf ioctl. (However, we still choose to
> spin before enabling the
From: aknautiy
Idleness DRRS:
By default the DRRS state will be at DRRS_HIGH_RR. When a Display
content is Idle for more than 1Sec Idleness will be declared and
DRRS_LOW_RR will be invoked, changing the refresh rate to the
lower most refresh rate supported by the p
52 matches
Mail list logo
