Should we not get the HuC patches merged before we amend them?
Peter.
-Original Message-
From: Gordon, David S
Sent: Wednesday, August 10, 2016 4:25 PM
To: Tvrtko Ursulin ;
Intel-gfx@lists.freedesktop.org
Cc: Ursulin, Tvrtko ; Vivi, Rodrigo
; Antoine, Peter ; Thierry,
Michel
Subject:
On Tue, Jul 05, 2016 at 06:35:47PM +0530, Shashank Sharma wrote:
> This patch adds lspcon support in dp_dual_mode helper.
> lspcon is essentially a dp->hdmi dongle with dual personality.
>
> LS mode: It works as a passive dongle, by level shifting DP++
> signals to HDMI signals, in LS mode.
> PCON
No functional change, code clean up and improved debug.
Chris suggested this code snippet while reviewing, I just made this into a
patch.
Credits-to: Chris Wilson
Cc: Chris Wilson
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_audio.c | 28
1 fi
No functional change, just clean up.
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_audio.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 9465f54..587d53a 100644
--
No functional change, just clean up. Debug messages now print out clock
units. Additionally, the configuration bits, which are 1:1 mapped to the
clock frequency and don't convey much information are not printed out.
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_audio.c | 20 +
On Wed, Aug 10, 2016 at 12:41:57PM -0700, Dhinakaran Pandiyan wrote:
> DP MST provides the capability to send multiple video and audio streams
> through a single port. This requires the API's between i915 and audio
> drivers to distinguish between multiple audio capable displays that can be
> conne
== Series Details ==
Series: drm/i915/dp: DP audio API changes for MST (rev3)
URL : https://patchwork.freedesktop.org/series/10571/
State : failure
== Summary ==
Applying: drm/i915/dp: DP audio API changes for MST
fatal: sha1 information is lacking or useless
(drivers/gpu/drm/i915/intel_audio
On Wed, 2016-08-10 at 17:21 +0300, Ville Syrjälä wrote:
> On Tue, Aug 09, 2016 at 01:58:33PM -0700, Dhinakaran Pandiyan wrote:
> > DP MST provides the capability to send multiple video and audio streams
> > through a single port. This requires the API's between i915 and audio
> > drivers to disting
DP MST provides the capability to send multiple video and audio streams
through a single port. This requires the API's between i915 and audio
drivers to distinguish between multiple audio capable displays that can be
connected to a port. Currently only the port identity is shared in the
APIs. This
Just FYI: 1.23 with 4.8-rc1 always causes unrecoverable i915 crashes
on my machine as soon as X loads (divide error: ). I don't know if
it's just my machine, but there already is a bug report about this on
Bugzilla.
The interesting thing is: patching the kernel to load 1.26 instead of
1.23 res
== Series Details ==
Series: drm/i915: Store number of active engines in device info
URL : https://patchwork.freedesktop.org/series/10921/
State : failure
== Summary ==
Series 10921v1 drm/i915: Store number of active engines in device info
http://patchwork.freedesktop.org/api/1.0/series/10921/
== Series Details ==
Series: drm/i915/guc: Consolidate firmware major-minor to one place (rev2)
URL : https://patchwork.freedesktop.org/series/9318/
State : warning
== Summary ==
Series 9318v2 drm/i915/guc: Consolidate firmware major-minor to one place
http://patchwork.freedesktop.org/api/1.0/
On Wed, 10 Aug 2016 16:04:37 +0200
Daniel Vetter wrote:
> On Wed, Aug 10, 2016 at 01:52:45PM +0200, Boris Brezillon wrote:
> > On Wed, 10 Aug 2016 14:41:52 +0300
> > Ville Syrjälä wrote:
> >
> > > On Wed, Aug 10, 2016 at 11:25:03AM +0200, Boris Brezillon wrote:
> > > > On Wed, 10 Aug 2016 1
== Series Details ==
Series: Reclassify messages from GuC loader/submission
URL : https://patchwork.freedesktop.org/series/10918/
State : failure
== Summary ==
Series 10918v1 Reclassify messages from GuC loader/submission
http://patchwork.freedesktop.org/api/1.0/series/10918/revisions/1/mbox
== Series Details ==
Series: drm/i915: Restore DMC required version for Skylake (1.26) (rev2)
URL : https://patchwork.freedesktop.org/series/10889/
State : failure
== Summary ==
Series 10889v2 drm/i915: Restore DMC required version for Skylake (1.26)
http://patchwork.freedesktop.org/api/1.0/se
On 10/08/16 11:26, Daniel Vetter wrote:
On Tue, Aug 09, 2016 at 10:57:13PM -0700, Rodrigo Vivi wrote:
On Tue, Aug 9, 2016 at 1:48 AM, Jani Nikula wrote:
On Tue, 09 Aug 2016, Daniel Klaffenbach wrote:
Hi,
which one is the correct DMC version to load for Linux 4.8-rc1? The
binary blob in linu
On Wed, Aug 10, 2016 at 04:22:10PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Until now code was calling hweight32 to figure out the
> number from device_info->ring_mask at runtime. Instead
> we can cache it at engine init time and use directly.
And calling hweight32() rather than h
On 10/08/16 16:22, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Until now code was calling hweight32 to figure out the
number from device_info->ring_mask at runtime. Instead
we can cache it at engine init time and use directly.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugf
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> First part is just a bit of rst fallout to make drm doc builds warning free.
> But
> then I started to split out parts of drm_crtc into their own files.
> framebuffers
> and connectors are done, next up on my plans are encoders, and then the
On Tue, Aug 9, 2016 at 9:50 AM, Daniel Vetter wrote:
> Move the documentation into Documentation/gpu, link it up and pull in
> the kernel doc.
>
> No actual text changes except that I did polish the kerneldoc a bit,
> especially for vga_client_register().
>
> v2: Remove some rst from vga-switchero
On 10/08/16 16:16, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Currently to change the firmware one has to update the exported
module firmware string and the major-minor versions used for
verification after load. Consolidate that to a single place
defining correct major and minor versions per pl
On 10/08/16 15:41, Rodrigo Vivi wrote:
With commit 4aa7fb9c ("drm/i915/dmc: Step away from symbolic
links") we started loading the firmware version directly
instead of symbolic links.
With this VERSION_REQUIRED variables changed the meaning
from minimal required to exact version required. Along
From: Tvrtko Ursulin
Until now code was calling hweight32 to figure out the
number from device_info->ring_mask at runtime. Instead
we can cache it at engine init time and use directly.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> - Shuffle docs from drm-kms.rst into the structure docs where it makes
> sense.
> - Put the remaining bits into a new overview section.
>
> One thing I've changed is around probing: Old docs says that you
> _must_ use the probe helpers, whic
We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common under
Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
1 file changed, 7 insertions(+), 1
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> We seem to have a bit a mess in how to describe the bus formats, with
> a multitude of competing ways. Might be best to consolidate it all and
> use MEDIA_BUS_FMT_ also for the hdmi color formats and high color
> modes.
>
> Also move all the d
From: Tvrtko Ursulin
Currently to change the firmware one has to update the exported
module firmware string and the major-minor versions used for
verification after load. Consolidate that to a single place
defining correct major and minor versions per platform.
v2: Rebased for KBL.
Signed-off-b
On Tue, Aug 09, 2016 at 03:41:23PM +0200, Daniel Vetter wrote:
> - Move the intro section into a DOC comment, and update it slightly.
> - kernel-doc for struct drm_framebuffer!
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-kms.rst | 26 +--
> drivers/gpu/drm/drm_fram
Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
and one eliminated completely.
v2: different permutation of levels :)
v3: convert a couple of "this shouldn't happen" messages to WARN()
Signed-off-by: Dave Gordon
Reviewed-b
Re-enables GuC loading and submission by default on suitable
platforms, since it's Intel's Plan of Record that GuC submission
shall be used where available.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/d
Various downgrading, upgrading, or general reorganisation of the
messages emitted by the GuC code. Mostly:
* "can't happen" cases (inconsistencies/misconfiguration) are ERRORs
* recoverable (ignored) errors are downgraded to WARNINGs
* important auxiliary messages about failure or mode change are N
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> They're only used internally within the dp helpers. Also nuke the
> kerneldoc (we only document the driver interface in the drm shared
> functions). And move the header file from the public include/
> directory to the source files into drm_crt
== Series Details ==
Series: more drm doc work (rev2)
URL : https://patchwork.freedesktop.org/series/10844/
State : failure
== Summary ==
LD net/ipv6/ipv6.o
CC drivers/acpi/acpica/uterror.o
CC drivers/acpi/acpica/uteval.o
CC drivers/acpi/acpica/utglobal.o
CC
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> Also start with drm_modeset.h with the core bits, since we need
> to untangle this mess somehow. That allows us to move the drm_modes.h
> include to the right spot, except for the temporary connector status
> enum. That will get fixed as soon
== Series Details ==
Series: Finally fix watermarks (rev8)
URL : https://patchwork.freedesktop.org/series/10276/
State : failure
== Summary ==
Series 10276v8 Finally fix watermarks
http://patchwork.freedesktop.org/api/1.0/series/10276/revisions/8/mbox
Test gem_exec_suspend:
Subgroup b
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> - Move the intro section into a DOC comment, and update it slightly.
> - kernel-doc for struct drm_framebuffer!
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-kms.rst | 26 +--
> drivers/gpu/drm/drm_framebuffer.c
On Wed, Aug 10, 2016 at 4:23 PM, Sean Paul wrote:
> Is there a reason we create drm_kms_helper.c/h in patch 2 and then
> rename it in patch 3? Could you squash this?
My own incompetence ;-) It's already squashed here in my tree.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (
With commit 4aa7fb9c ("drm/i915/dmc: Step away from symbolic
links") we started loading the firmware version directly
instead of symbolic links.
With this VERSION_REQUIRED variables changed the meaning
from minimal required to exact version required. Along
with this change we started using the lat
== Series Details ==
Series: drm/i915: Fix nesting of rps.mutex and struct_mutex during powersave
init
URL : https://patchwork.freedesktop.org/series/10909/
State : failure
== Summary ==
Series 10909v1 drm/i915: Fix nesting of rps.mutex and struct_mutex during
powersave init
http://patchwork
If we're enabling a pipe, we'll need to modify the watermarks on all
active planes. Since those planes won't be added to the state on
their own, we need to add them ourselves.
Signed-off-by: Lyude
Reviewed-by: Matt Roper
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Radhak
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full
Rebased version of https://patchwork.freedesktop.org/series/10276/ . No changes
Lyude (5):
drm/i915/skl: Add support for the SAGV, fix underrun hangs
drm/i915/skl: Update plane watermarks atomically during plane updates
drm/i915/skl: Ensure pipes with changed wms get added to the state
drm
From: Matt Roper
When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw. However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
o
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 watermark updates.
The first major change in this patch is skl_
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 watermark updates.
The first major change in this patch is skl_
From: Matt Roper
When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw. However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
o
If we're enabling a pipe, we'll need to modify the watermarks on all
active planes. Since those planes won't be added to the state on
their own, we need to add them ourselves.
Signed-off-by: Lyude
Reviewed-by: Matt Roper
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Radhak
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 of intel_atomic_commit_tail()
(intel_atomic_commit() for sta
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 written to them won't take effect until said registers are
"ar
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 of intel_atomic_commit_tail()
(intel_atomic_commit() for sta
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 written to them won't take effect until said registers are
"ar
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full
Rebased version of https://patchwork.freedesktop.org/series/10276/ . No changes
Lyude (5):
drm/i915/skl: Add support for the SAGV, fix underrun hangs
drm/i915/skl: Update plane watermarks atomically during plane updates
drm/i915/skl: Ensure pipes with changed wms get added to the state
drm
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> While reviewing docs I spotted that we have a few functions that
> really just don't fit into their containing helper library section.
> Extract them and shovel them all into a new library for random one-off
> aux stuff.
>
> Signed-off-by: Dan
On Tue, Aug 09, 2016 at 01:58:33PM -0700, Dhinakaran Pandiyan wrote:
> DP MST provides the capability to send multiple video and audio streams
> through a single port. This requires the API's between i915 and audio
> drivers to distinguish between multiple audio capable displays that can be
> conne
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Mark unmappable GGTT entries as
PIN_HIGH
URL : https://patchwork.freedesktop.org/series/10907/
State : failure
== Summary ==
Series 10907v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/10907/re
On Wed, Aug 10, 2016 at 01:52:45PM +0200, Boris Brezillon wrote:
> On Wed, 10 Aug 2016 14:41:52 +0300
> Ville Syrjälä wrote:
>
> > On Wed, Aug 10, 2016 at 11:25:03AM +0200, Boris Brezillon wrote:
> > > On Wed, 10 Aug 2016 12:09:41 +0300
> > > Ville Syrjälä wrote:
> > >
> > > > On Wed, Aug 10,
From: Ville Syrjälä
Add another mode which changes the DSPARB registers at specific
scanlines, to determine if the individual bits get latches only
on the vblank of the relevant pipe, of if other pipes would cause
premature latching to happen when their vblank happens first.
The results I got on
On Wed, Aug 10, 2016 at 01:58:24PM +0100, Chris Wilson wrote:
> During intel_gt_powersave_init() we take the RPS mutex to ensure that
> all locking requirements are met as we talk to the punit, but we also
> require the struct_mutex for allocating a slice of the global GTT for a
> power context on
On ke, 2016-08-10 at 12:08 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [CI,v3,1/6] drm/i915: Merge the PPS
> register definitions
> URL : https://patchwork.freedesktop.org/series/10901/
> State : failure
>
> == Summary ==
>
> Series 10901v1 Series without co
On Wed, Aug 10, 2016 at 03:19:34PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Not only does it make for good documentation and debugging aide, but it is
> > also vital for when we want to unwind requests - such as when throwing away
> > an incomplete request.
> >
> > Signed-off-by:
During intel_gt_powersave_init() we take the RPS mutex to ensure that
all locking requirements are met as we talk to the punit, but we also
require the struct_mutex for allocating a slice of the global GTT for a
power context on Valleyview. struct_mutex must be the outer lock here,
as we nest rps.m
request->batch_obj is only set by execbuffer for the convenience of
debugging hangs. By moving that operation to the callsite, we can
simplify all other callers and future patches. We also move the
complications of reference handling of the request->batch_obj next to
where the active tracking is se
We allocate a few objects into the GGTT that we never need to access via
the mappable aperture (such as contexts, status pages). We can request
that these are bound high in the VM to increase the amount of mappable
aperture available. However, anything that may be frequently pinned
(such as logical
On ke, 2016-08-10 at 12:26 +0100, Dave Gordon wrote:
> On 10/08/16 06:57, Rodrigo Vivi wrote:
> > With commit 4aa7fb9c ("drm/i915/dmc: Step away from symbolic
> > links") we started loading the firmware version directly
> > instead of symbolic links.
>
> However the pathnames in the patch context
On Wed, Aug 10, 2016 at 11:46:25AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Handle fb->offsets[] and rewrite fb rotation handling to be
> more generic (v5)
> URL : https://patchwork.freedesktop.org/series/10895/
> State : failure
>
> == Summary ==
>
> Series 10895v
== Series Details ==
Series: series starting with [1/9] drm/i915: Cache kmap between relocations
URL : https://patchwork.freedesktop.org/series/10904/
State : failure
== Summary ==
Applying: drm/i915: Cache kmap between relocations
fatal: sha1 information is lacking or useless
(drivers/gpu/dr
== Series Details ==
Series: drm/i915: Cleanup DisplayPort AUX channel initialization
URL : https://patchwork.freedesktop.org/series/10902/
State : failure
== Summary ==
Series 10902v1 drm/i915: Cleanup DisplayPort AUX channel initialization
http://patchwork.freedesktop.org/api/1.0/series/1090
Chris Wilson writes:
> Not only does it make for good documentation and debugging aide, but it is
> also vital for when we want to unwind requests - such as when throwing away
> an incomplete request.
>
> Signed-off-by: Chris Wilson
> Link:
> http://patchwork.freedesktop.org/patch/msgid/1470414
Hi,
On 04-08-16 23:03, Takashi Iwai wrote:
[dropped stable ML and add a few other relevant people to Cc]
On Thu, 04 Aug 2016 20:05:27 +0200,
Takashi Iwai wrote:
On Thu, 04 Aug 2016 18:44:11 +0200,
Daniel Vetter wrote:
On Wed, Aug 03, 2016 at 05:09:00PM +0100, Chris Wilson wrote:
On Haswell
== Series Details ==
Series: series starting with [CI,v3,1/6] drm/i915: Merge the PPS register
definitions
URL : https://patchwork.freedesktop.org/series/10901/
State : failure
== Summary ==
Series 10901v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/10901/revis
On 08/09/2016 04:08 PM, Daniel Vetter wrote:
> On Tue, Aug 9, 2016 at 3:59 PM, Thomas Hellstrom
> wrote:
>> Hmm.
>>
>> I don't have a strong opinion on this, but IMO the original idea of
>> allowing a user-space driver to optimize away the dirty calls isn't a
>> bad one.
>> Since the xf86-video-v
On Wed, 10 Aug 2016 13:52:45 +0200
Boris Brezillon wrote:
> On Wed, 10 Aug 2016 14:41:52 +0300
> Ville Syrjälä wrote:
>
> > On Wed, Aug 10, 2016 at 11:25:03AM +0200, Boris Brezillon wrote:
> > > On Wed, 10 Aug 2016 12:09:41 +0300
> > > Ville Syrjälä wrote:
> > >
> > > > On Wed, Aug 10,
There is an improbable, but not impossible, case that if we leave the
pages unpin as we operate on the object, then somebody may steal the
lock and change the cache domains after we have already inspected them.
(Whilst here, avail ourselves of the opportunity to take a couple of
steps to make the
If we cannot pin the entire object into the mappable region of the GTT,
try to pin a single page instead. This is much more likely to succeed,
and prevents us falling back to the clflush slow path.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 61 ++
With in the introduction of the reloc page cache, we are just one step
away from refactoring the relocation write functions into one. Not only
does it tidy the code (slightly), but it greatly simplifies the control
logic much to gcc's satisfaction.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm
If we want to read the pages directly via the CPU, we have to be sure
that we have to flush the writes via the GTT (as the CPU can not see
the address aliasing).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/dr
This is a companion to i915_gem_obj_prepare_shmem_read() that prepares
the backing storage for direct writes. It first serialises with the GPU,
pins the backing storage and then indicates what clfushes are required in
order for the writes to be coherent.
Whilst here, fix support for ancient CPUs w
Execbuf suffers from a coherency problem which in theory is handled by
the prepare for direct access implemented by pwrite. The issue being not
only is that function non-existent (implemented inline for pwrite) it is
missing a barrier or two.
-Chris
___
If we quickly switch from writing through the GTT to a read of the
physical page directly with the CPU (e.g. performing relocations through
the GTT and then running the command parser), we can observe that the
writes are not visible to the CPU. It is not a coherency problem, as
extensive investigat
As we cannot access the backing pages behind stolen objects, we should
not attempt to do so for relocations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu
When doing relocations, we have to obtain a mapping to the page
containing the target address. This is either a kmap or iomap depending
on GPU and its cache coherency. Neighbouring relocation entries are
typically within the same page and so we can cache our kmapping between
them and avoid those pe
Since we know the write domain, we can drop the local variable and make
the code look a tiny bit simpler.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers
On Wed, 10 Aug 2016 14:41:52 +0300
Ville Syrjälä wrote:
> On Wed, Aug 10, 2016 at 11:25:03AM +0200, Boris Brezillon wrote:
> > On Wed, 10 Aug 2016 12:09:41 +0300
> > Ville Syrjälä wrote:
> >
> > > On Wed, Aug 10, 2016 at 10:35:22AM +0200, Boris Brezillon wrote:
> > > > Hi Ville,
> > > >
>
== Series Details ==
Series: drm/i915: Handle fb->offsets[] and rewrite fb rotation handling to be
more generic (v5)
URL : https://patchwork.freedesktop.org/series/10895/
State : failure
== Summary ==
Series 10895v1 drm/i915: Handle fb->offsets[] and rewrite fb rotation handling
to be more g
On Wed, Aug 10, 2016 at 11:25:03AM +0200, Boris Brezillon wrote:
> On Wed, 10 Aug 2016 12:09:41 +0300
> Ville Syrjälä wrote:
>
> > On Wed, Aug 10, 2016 at 10:35:22AM +0200, Boris Brezillon wrote:
> > > Hi Ville,
> > >
> > > On Fri, 22 Jul 2016 18:47:01 +0300
> > > ville.syrj...@linux.intel.com w
Let's remove reference to "struct intel_connector *connector"
from intel_dp_aux_init() function as it is no longer required.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/dr
On Wed, Aug 10, 2016 at 02:02:43PM +0300, Ville Syrjälä wrote:
> On Wed, Aug 10, 2016 at 12:04:32PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 10, 2016 at 12:23:21PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > We convert the fb->offsets[] into x/y offse
On ke, 2016-08-10 at 11:52 +0100, Chris Wilson wrote:
> On Wed, Aug 10, 2016 at 01:32:29PM +0300, Joonas Lahtinen wrote:
> >
> > On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> > >
> > > @@ -309,12 +310,30 @@ void i915_error_printf(struct
> > > drm_i915_error_state_buf *e, const char *f,
On Wed, Aug 10, 2016 at 12:03:08PM +0200, Daniel Vetter wrote:
> On Wed, Aug 10, 2016 at 12:23:20PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > With NV12 we have two color planes to deal with so we must compute the
> > surface and x/y offsets for the second plane a
On 10/08/16 06:57, Rodrigo Vivi wrote:
With commit 4aa7fb9c ("drm/i915/dmc: Step away from symbolic
links") we started loading the firmware version directly
instead of symbolic links.
However the pathnames in the patch context below are still the symlink
names -- is this correct? Or did some m
== Series Details ==
Series: drm/i915: Restore DMC required version for Skylake (1.26)
URL : https://patchwork.freedesktop.org/series/10889/
State : failure
== Summary ==
Series 10889v1 drm/i915: Restore DMC required version for Skylake (1.26)
http://patchwork.freedesktop.org/api/1.0/series/10
On Wed, Aug 10, 2016 at 11:48:56AM +0200, Daniel Vetter wrote:
> On Wed, Aug 10, 2016 at 12:23:17PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Minimize the resulting X coordinate after intel_adjust_tile_offset() is
> > done with it's offset adjustment. This allows
In the preceeding patches we made sure that:
- the LVDS encoder takes care of reiniting both the LVDS register
and its PPS
- the eDP encoder takes care of reiniting its PPS
- the PPS register unlocking workaround is applied explicitly whenever
the PPS context is lost
Based on the above we can safe
These two flags mean the same thing, so remove the duplication.
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 1 -
drivers/gpu/drm/i915/intel_dp.c | 6 +++---
drivers/gpu/drm/i915/intel_lvds.c | 4 ++--
3 files changed, 5 insertions(+), 6 deletion
Atm, we apply this workaround somewhat inconsistently at the following
points: driver loading, LVDS init, eDP PPS init, system resume. As this
workaround also affects registers other than PPS (timing, PLL) a more
consistent way is to apply it early after the PPS HW context is known to
be lost: driv
Similarly to the previous patch, initialize the PPS from the DP
encoder's resume hook. Note that as opposed to LVDS we can't do this
during encoder enabling, since we need the PPS for DP detection as well.
The PPS init code is now the same for init and resume, so factor out a
new intel_dp_pps_init(
Atm the LVDS encoder depends on the PPS HW context being saved/restored
from generic suspend/resume code. Since the PPS is specific to the LVDS
and eDP encoders a cleaner way is to reinitialize it during encoder
enabling, so do this here for LVDS. Follow-up patches will init the PPS
for the eDP enc
The PPS registers are pretty much the same everywhere, the differences
being:
- Register fields appearing, disappearing from one platform to the
next: panel-reset-on-powerdown, backlight-on, panel-port,
register-unlock
- Different register base addresses
- Different number of PPS instances: 2 o
1 - 100 of 163 matches
Mail list logo
