On Thu, Jun 02, 2016 at 12:21:49PM +0200, Johannes Berg wrote:
> On Thu, 2016-06-02 at 10:16 +, Daniel Vetter wrote:
>
> > I still kinda like relayfs, except that it's not available in non-
> > debug builds. But so are plenty of other really interesting files we
> > have hidden in there.
> >
== Series Details ==
Series: Enable GuC on KBL
URL : https://patchwork.freedesktop.org/series/8174/
State : warning
== Summary ==
Series 8174v1 Enable GuC on KBL
http://patchwork.freedesktop.org/api/1.0/series/8174/revisions/1/mbox
Test core_auth:
Subgroup basic-auth:
On Wed, Jun 01, 2016 at 04:40:12PM +0200, Daniel Vetter wrote:
> On Wed, Jun 01, 2016 at 02:36:41PM +0200, Lukas Wunner wrote:
> > On Wed, May 25, 2016 at 03:43:42PM +0200, Daniel Vetter wrote:
> > > On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner wrote:
> > > > On Tue, May 24, 2016 at 11:30:42PM +
On Fri, 03 Jun 2016 00:05:46 +0300
Laurent Pinchart wrote:
> Hi Boris,
>
> Thank you for the patch.
>
> On Thursday 02 Jun 2016 16:31:28 Boris Brezillon wrote:
> > Adapt drm_pick_crtcs() and update_connector_routing() to fallback to
> > drm_atomic_helper_best_encoder() if funcs->best_encoder()
On Thu, 2 Jun 2016 23:57:02 +0200
Daniel Vetter wrote:
> On Thu, Jun 2, 2016 at 11:05 PM, Laurent Pinchart
> wrote:
> > Hi Boris,
> >
> > Thank you for the patch.
> >
> > On Thursday 02 Jun 2016 16:31:28 Boris Brezillon wrote:
> >> Adapt drm_pick_crtcs() and update_connector_routing() to fallb
On Thu, 02 Jun 2016 23:57:14 +0300
Laurent Pinchart wrote:
> Hi Boris,
>
> Thank you for the patch.
>
> On Thursday 02 Jun 2016 16:31:36 Boris Brezillon wrote:
> > All outputs have a 1:1 relationship between connectors and encoders,
> > and the driver is relying on the atomic helpers: we can dr
== Series Details ==
Series: drm/i915: Make infoframe code available to (e)DP ports
URL : https://patchwork.freedesktop.org/series/8183/
State : warning
== Summary ==
Series 8183v1 drm/i915: Make infoframe code available to (e)DP ports
http://patchwork.freedesktop.org/api/1.0/series/8183/revis
Arun Siluvery writes:
> [ text/plain ]
> This is a WA affecting pooled eu which is a bxt specific feature.
>
> Cc: Winiarski, Michal
> Cc: Zou, Nanhai
> Cc: Yang, Rong R
> Cc: Jeff McGee
> Signed-off-by: Arun Siluvery
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h
== Series Details ==
Series: BXT Pooled EU kernel support and WA patches
URL : https://patchwork.freedesktop.org/series/8200/
State : warning
== Summary ==
Series 8200v1 BXT Pooled EU kernel support and WA patches
http://patchwork.freedesktop.org/api/1.0/series/8200/revisions/1/mbox
Test gem_
On 6/2/2016 6:01 PM, Peter Antoine wrote:
This patch added the loading of the GuC for Kabylake.
It loads a 2.4 firmware.
^^ not anymore
Either we update the commit msg to say 9.14 (and let people know how
many releases we had), or just keep silent about it ;)
Signed-off-by: Pe
On to, 2016-06-02 at 12:36 -0400, Zhi Wang wrote:
> As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g
> host (GVT-g kernel device model), factor it out for better code structure.
>
> v3:
>
> Take Joonas's comments:
> - Use offsetof to calculate the member offset of PVINFO
On to, 2016-06-02 at 12:36 -0400, Zhi Wang wrote:
> v5:
> - Let functions take struct drm_i915_private *. (Tvrtko)
>
> - Fold vGPU related active check into the inner functions. (Kevin)
>
> Signed-off-by: Zhi Wang
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 11 ---
> drivers/gpu/drm/i
On to, 2016-06-02 at 12:36 -0400, Zhi Wang wrote:
> This patch introduces the very basic framework of GVT-g device model,
> includes basic prototypes, definitions, initialization.
>
> v6:
> - Refine introduction in Kconfig. (Chris)
> - The exposed API functions will take struct intel_gvt * instead
I'll remove the comment. :)
-Original Message-
From: Thierry, Michel
Sent: Friday, June 3, 2016 9:44 AM
To: Antoine, Peter ; intel-gfx@lists.freedesktop.org
Cc: Gordon, David S
Subject: Re: [PATCH 2/2] i915/guc: Add Kabylake GuC Loading
On 6/2/2016 6:01 PM, Peter Antoine wrote:
> This p
From: Ankitprasad Sharma
This patch verifies if the contents of the stolen backed object were
preserved across hibernation. This is to validate kernel changes related
to moving stolen-backed objects to shmem on hibernation.
v2: Added comment, Use igt_assert_eq() instead of igt_assert(), Made loo
From: Ankitprasad Sharma
Check for available stolen memory size before attempting to run
the stolen memory tests. This way we make sure that we do not
create objects from stolen memory without knowing the available size.
This checks if the kernel supports creation of stolen backed objects
before
From: Ville Syrjälä
Apparently some CHV boards failed to hook up the port presence straps
for HDMI ports as well (earlier we assumed this problem only affected
eDP ports). So let's check the VBT in addition to the strap, and if
either one claims that the port is present go ahead and register the
From: Ankitprasad Sharma
no_mmap subtest is expected to fail, but calling gem_mmap__cpu
will assert the returned value itself, which makes test fail.
Replacing gem_mmap__cpu by __gem_mmap__cpu and checking the
returned value.
Signed-off-by: Ankitprasad Sharma
---
tests/gem_stolen.c | 2 +-
1 f
On to, 2016-06-02 at 12:36 -0400, Zhi Wang wrote:
> From: Bing Niu
>
> This patch introduces host graphics memory partition when GVT-g
> is enabled.
>
> Under GVT-g, i915 host driver only owned limited graphics resources,
> others are managed by GVT-g resource allocator and kept for other vGPUs.
On to, 2016-06-02 at 12:36 -0400, Zhi Wang wrote:
> This patch introduces an option for configuring the ring buffer size
> of a LRC context after the context creation.
>
> Signed-off-by: Zhi Wang
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu
Arun Siluvery writes:
> [ text/plain ]
> Pooled EU is enabled by default for BXT but for fused down 2x6 parts it is
> advised to turn it off. But there is another HW issue in these parts (fused
> down 2x6 parts) before C0 that requires Pooled EU to be enabled as a
> workaround. In this case the p
On to, 2016-06-02 at 12:36 -0400, Zhi Wang wrote:
> Currently the addressing mode bit in context descriptor is statically
> generated from the configuration of system-wide PPGTT usage model.
>
> GVT-g will load the PPGTT shadow page table by itself and probably one
> guest is using a different add
Hi Daniel,
On Friday 03 Jun 2016 08:55:36 Daniel Vetter wrote:
> On Fri, Jun 03, 2016 at 01:54:44AM +0300, Laurent Pinchart wrote:
> > On Monday 30 May 2016 16:54:10 Daniel Vetter wrote:
> >> On Mon, May 30, 2016 at 11:58:27AM +0200, Maarten Lankhorst wrote:
> >>> Op 30-05-16 om 11:18 schreef Laur
On to, 2016-06-02 at 12:36 -0400, Zhi Wang wrote:
> This patch introduces an approach to track the execlist context status
> change.
>
> GVT-g uses GVT context as the "shadow context". The content inside GVT
> context will be copied back to guest after the context is idle. So GVT-g
> has to know t
On Fri, Jun 3, 2016 at 11:40 AM, Laurent Pinchart
wrote:
> On Friday 03 Jun 2016 08:55:36 Daniel Vetter wrote:
>> On Fri, Jun 03, 2016 at 01:54:44AM +0300, Laurent Pinchart wrote:
>> > On Monday 30 May 2016 16:54:10 Daniel Vetter wrote:
>> >> On Mon, May 30, 2016 at 11:58:27AM +0200, Maarten Lankh
On to, 2016-06-02 at 12:36 -0400, Zhi Wang wrote:
> This patch introduces the support of LRC context signle submission.
"single"
> As GVT context may come from different guests, which requires different
"require"
> configuration of render registers. It can't be combined into a dual ELSP
> submi
Hi Daniel,
On Friday 03 Jun 2016 11:45:56 Daniel Vetter wrote:
> On Fri, Jun 3, 2016 at 11:40 AM, Laurent Pinchart wrote:
> > On Friday 03 Jun 2016 08:55:36 Daniel Vetter wrote:
> >> On Fri, Jun 03, 2016 at 01:54:44AM +0300, Laurent Pinchart wrote:
> >>> On Monday 30 May 2016 16:54:10 Daniel Vette
On Fri, Jun 03, 2016 at 12:17:43PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Apparently some CHV boards failed to hook up the port presence straps
> for HDMI ports as well (earlier we assumed this problem only affected
> eDP ports). So let's check the VBT in addition t
On to, 2016-06-02 at 12:36 -0400, Zhi Wang wrote:
> GVT workload scheduler needs special host LRC contexts, the so called
> "shadow LRC context" to submit guest workload to host i915. During the
> guest workload submission, GVT fills the shadow LRC context with the
> content of guest LRC context: e
== Series Details ==
Series: drm/i915: Check VBT for port presence in addition to the strap on
VLV/CHV
URL : https://patchwork.freedesktop.org/series/8211/
State : warning
== Summary ==
Series 8211v1 drm/i915: Check VBT for port presence in addition to the strap on
VLV/CHV
http://patchwork.f
On Fri, Jun 03, 2016 at 10:56:24AM +0100, Chris Wilson wrote:
> On Fri, Jun 03, 2016 at 12:17:43PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Apparently some CHV boards failed to hook up the port presence straps
> > for HDMI ports as well (earlier we assumed this
On 6/3/2016 12:45 PM, Daniel Vetter wrote:
On Thu, Jun 02, 2016 at 12:21:49PM +0200, Johannes Berg wrote:
On Thu, 2016-06-02 at 10:16 +, Daniel Vetter wrote:
I still kinda like relayfs, except that it's not available in non-
debug builds. But so are plenty of other really interesting fil
Pooled EU is enabled by default for BXT but for fused down 2x6 parts it is
advised to turn it off. But there is another HW issue in these parts (fused
down 2x6 parts) before C0 that requires Pooled EU to be enabled as a
workaround. In this case the pool configuration changes depending upon
which su
This is a WA affecting pooled eu which is a bxt specific feature.
Reviewed-by: Mika Kuoppala
Cc: Winiarski, Michal
Cc: Zou, Nanhai
Cc: Yang, Rong R
Cc: Jeff McGee
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 6
On Fri, Jun 03, 2016 at 03:44:09PM +0530, Goel, Akash wrote:
>
>
> On 6/3/2016 12:45 PM, Daniel Vetter wrote:
> >On Thu, Jun 02, 2016 at 12:21:49PM +0200, Johannes Berg wrote:
> >>On Thu, 2016-06-02 at 10:16 +, Daniel Vetter wrote:
> >>
> >>>I still kinda like relayfs, except that it's not av
Hi,
Thanks for the feedback. Have you tried with drm-intel-nightly [1] to see if
this still happens?
[1] https://anongit.freedesktop.org/git/drm-intel.git
CC'ing the list. Maybe someone is aware of this. Seems there are bunch
of duplicates for it.
On Thu, Jun 02, 2016 at 09:06:05PM +0300, Vladi
On 03/06/16 09:51, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This patch verifies if the contents of the stolen backed object were
preserved across hibernation. This is to validate kernel changes related
to moving stolen-backed objects to shmem on hibernation.
v2: Added co
On 03/06/16 09:51, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
no_mmap subtest is expected to fail, but calling gem_mmap__cpu
will assert the returned value itself, which makes test fail.
Replacing gem_mmap__cpu by __gem_mmap__cpu and checking the
returned value.
Signed-off
== Series Details ==
Series: BXT Pooled EU kernel support and WA patches (rev3)
URL : https://patchwork.freedesktop.org/series/8200/
State : warning
== Summary ==
Series 8200v3 BXT Pooled EU kernel support and WA patches
http://patchwork.freedesktop.org/api/1.0/series/8200/revisions/3/mbox
Te
On 03/06/16 09:51, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
Check for available stolen memory size before attempting to run
the stolen memory tests. This way we make sure that we do not
create objects from stolen memory without knowing the available size.
This checks if
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Friday, June 03, 2016 5:47 PM
>
> On to, 2016-06-02 at 12:36 -0400, Zhi Wang wrote:
> > This patch introduces the support of LRC context signle submission.
>
> "single"
>
> > As GVT context may come from different guests, w
== Series Details ==
Series: series starting with [1/3] igt/gem_stolen: Verify contents of
stolen-backed objects across hibernation
URL : https://patchwork.freedesktop.org/series/8210/
State : failure
== Summary ==
Applying: igt/gem_stolen: Verify contents of stolen-backed objects across
hib
== Series Details ==
Series: series starting with [1/3] igt/gem_stolen: Verify contents of
stolen-backed objects across hibernation
URL : https://patchwork.freedesktop.org/series/8210/
State : failure
== Summary ==
Applying: igt/gem_stolen: Verify contents of stolen-backed objects across
hib
Kernel only need to add a register to HW whitelist, required for a
preemption related issue.
Reference: HSD#2131039
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/dr
== Series Details ==
Series: drm/i915/gen9: Add WaVFEStateAfterPipeControlwithMediaStateClear
URL : https://patchwork.freedesktop.org/series/8218/
State : failure
== Summary ==
Series 8218v1 drm/i915/gen9: Add WaVFEStateAfterPipeControlwithMediaStateClear
http://patchwork.freedesktop.org/api/1
== Series Details ==
Series: Framework to collect command stream gpu metrics using i915 perf (rev2)
URL : https://patchwork.freedesktop.org/series/6154/
State : failure
== Summary ==
Applying: drm/i915: Add ctx getparam ioctl parameter to retrieve ctx unique id
Applying: drm/i915: Expose OA sa
== Series Details ==
Series: Revert "sna: Refresh last detection timestamp on hotplug notifies"
URL : https://patchwork.freedesktop.org/series/7369/
State : failure
== Summary ==
Applying: Revert "sna: Refresh last detection timestamp on hotplug notifies"
fatal: sha1 information is lacking or
== Series Details ==
Series: drm/i915/gen9: Add WaVFEStateAfterPipeControlwithMediaStateClear
URL : https://patchwork.freedesktop.org/series/8218/
State : failure
== Summary ==
scripts/Makefile.clean:86: recipe for target 'drivers/staging/lustre/lnet/lnet'
failed
make[4]: *** [drivers/staging
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Friday, May 27, 2016 7:39 PM
>
> On pe, 2016-05-27 at 10:09 +, Tian, Kevin wrote:
> > Curious why leaking BIOS configuration to VM is a security problem…
> > Can someone elaborate this view?
> >
>
> Hi,
>
> It is a pote
On Fri, Jun 03, 2016 at 10:06:54AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Check VBT for port presence in addition to the strap on
> VLV/CHV
> URL : https://patchwork.freedesktop.org/series/8211/
> State : warning
>
> == Summary ==
>
> Series 8211v1 drm/i915: Chec
On Thu, May 19, 2016 at 03:50:36PM +0300, David Weinehall wrote:
> The atomic version of intel_pre_plane_update did not check
> for HAS_GMCH_DISPLAY before calling intel_set_memory_cxsr().
> While this doesn't cause any issues on its own (it will
> return without doing anything if the hardware does
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Friday, May 27, 2016 7:32 PM
>
> On pe, 2016-05-27 at 10:05 +, Wang, Zhi A wrote:
> > For me I think maybe i915 could save the snapshot for GVT, then GVT-g
> > patch the snapshot itself, then there won’t be leaking happen
On Fri, Jun 03, 2016 at 03:28:52PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 03, 2016 at 10:06:54AM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: Check VBT for port presence in addition to the strap on
> > VLV/CHV
> > URL : https://patchwork.freedesktop.org/series/8
From: Tvrtko Ursulin
Just a bunch of stale kerneldocs generating warnings when
building the docs. Mostly function parameters so not very
useful but still.
v2: Tidy.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 9 ++
On 02/06/16 21:21, Daniel Vetter wrote:
On Thu, Jun 02, 2016 at 04:19:48PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Just a bunch of stale kerneldocs generating warnings when
building the docs. Mostly function parameters so not very
useful but still.
Signed-off-by: Tvrtko Ursulin
Cc
On Fri, Jun 03, 2016 at 02:02:17PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Just a bunch of stale kerneldocs generating warnings when
> building the docs. Mostly function parameters so not very
> useful but still.
>
> v2: Tidy.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Daniel Vett
== Series Details ==
Series: drm/i915: Fix a buch of kerneldoc warnings (rev2)
URL : https://patchwork.freedesktop.org/series/8169/
State : warning
== Summary ==
Series 8169v2 drm/i915: Fix a buch of kerneldoc warnings
http://patchwork.freedesktop.org/api/1.0/series/8169/revisions/2/mbox
Test
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Allow everyone to call intel_panel_setup_backlight() (i.e. only take
effect if we have previously been initialised for use as a panel) and,
for paranoia, allow intel_panel_cleanup_backlight() to be called
multiple times.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/intel
As we now can call drm_connector_unregister() multiple times, provide a
failsafe unregister for a connector when cleaning it up.
v2: Add a WARN to catch any connectors that are still visible to
userspace when we come to destoy them.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
Cc: dri-de...@list
If a driver wants to more precisely control its initialisation and in
particular, defer registering its interfaces with userspace until after
everything is setup, it also needs to defer registering the connectors.
As some devices need more work during registration, add a callback so
that drivers ca
Protect against drivers that may try to register the connector more
than once, or who try to unregister it multiple times.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 9 +
include/drm/drm_cr
To complete the transition to manual control of load/unload, we need to
take over unloading from i915_pci_remove(). This allows us to correctly
order our unregister vs shutdown phases, which currently are inverted
due to the midlayer.
However, the unload sequence is still invalid as we shutdown th
Currently the backlight is being registered in the load phase (before
the display and its objects are registered). Move the backlight
registration into the analogous phase by performing it from the
connector registration, just after its creation.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
Currently the backlight is being unregistered in the unload phase (after
the display and its objects are unregistered). Move the backlight
unregistration into the analogous phase by performing it from the
connector unregistration, just prior to its deletion.
Signed-off-by: Chris Wilson
Cc: Jani N
When trying to split up the initialisation phase and the registration
phase, one immediate problem encountered is trying to use our own i2c
devices before registration with userspace (to read EDID during device
discovery). drm_dp_aux in particular only offers an interface for setting
up the device
In the very near future, we will perform the backlight setup
consistently during connector registration - moving the setup further
away from the intel_panel_init call and to where we no longer know the
associated pipe. To pass that information along we need to store it
during init.
Signed-off-by:
We now have a connector->func that serves the same purpose as our own
intel_connector->unregister vfunc allowing us to unwrap ourselves and
use drm_connector_register() (and friends) as the central function.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gp
The drm_dp_ax object is stored on the encoder, and freeing it from the
connector causes a use-after-free error since the encoder is destroy
first:
[ 112.356952]
==
[ 112.357065] BUG: KASAN: use-after-free in
intel_dp_connector_des
Setting up fbdev requires everything ready and registered (in particular
the connectors). In the next patch, we defer registration of the KMS
objects and unless we defer setting off fbdev, it may run before they are
registered and oops.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_d
Rather than have both drm_dp_aux lock within its transfer, and i2c to
lock around the transfer, use the same lock by filling in the locking
callbacks that i2c wants to use. We require our own hw_mutex as we
bypass i2c_transfer for drm_dp_dpcd_access().
Signed-off-by: Chris Wilson
Cc: Dave Airlie
The kernel context exists simply as a placeholder and should never be
executed with a render context. It does not need the golden render
state, as that will always be applied to a user context. By skipping the
initialisation we can avoid issues in attempting to program the golden
render context whe
The module init/exit routines are a wrapper around the PCI device
init/exit, so move them across.
Note that in order to avoid exporting the driver struct, instead of
manipulating driver.features inside i915_init we instead opt to simply
exit if i915.modeset is disabled.
Signed-off-by: Chris Wilso
In order to allow drivers to pack their privates and drm_device into one
struct (e.g. for subclassing), export the initialisation routines for
struct drm_device.
v2: Missed return ret. That error path had only one job to do!
v3: Cross-referencing drm_dev_init/drm_dev_alloc in kerneldoc, fix
missed
The contexts only pin space within the global GTT. Therefore forcing the
switch to the perma-pinned kernel context only has an effect when trying
to evict from and find room within the global GTT. We can then restrict
the switch to only when operating on the default context. This is mostly
a no-op
Defer connector registration from during construction to the driver
registration phase. This is important for ordering the action correctly,
e.g. not using debugfs before it is ready.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_dma.c | 2 ++
drivers/gpu/drm/i915/i915_drv.h
Some hardware requires a valid render context before it can initiate
rc6 power gating of the GPU; the default state of the GPU is not
sufficient and may lead to undefined behaviour. The first execution of
any batch will load the "golden render state", at which point it is safe
to enable rc6. As we
This is so that we have symmetry with intel_lrc.c and avoid a source of
if (i915.enable_execlists) layering violation within i915_gem_context.c -
that is we move the specific handling of the dev_priv->kernel_context
for legacy submission into the legacy submission code.
This depends upon the init/
Take control over allocating, loading and registering the driver from the
DRM midlayer by performing it manually from i915_pci_probe. This allows
us to carefully control the order of when we setup the hardware vs when
it becomes visible to third parties (including userspace). The current
ordering m
We only need to force a switch to the kernel context placeholder during
eviction. All other uses of i915_gpu_idle() just want to wait until
existing work on the GPU is idle. Rename i915_gpu_idle() to
i915_gem_wait_for_idle() to avoid any implications about "parking" the
context first.
v2: Tweak an
To reclaim a bit of space from i915_drv.c, we can move the routines that
just hook us into the PCI device tree into i915_pci.c
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.c | 443 +
Instead of flushing the outstanding enabling, remember the requested
frequency to apply when the powersave work runs.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 30 ++
drivers/gpu/drm/i915/i915_sysfs.c | 42 +++--
As the L3 remapping is applied before the next execution, there is no
need to wait until all previous uses are idle, the application will not
occur any sooner.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_sysfs.c | 7 ---
Select idle frequency during initialisation, then reset the last known
frequency when re-enabling. This allows us to preserve the user selected
frequency across resets.
Signed-off-by: Chris Wilson
Cc: ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 34 +-
1 f
Centralise backlight setup in the connector registration callback.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_crt.c | 1 +
drivers/gpu/drm/i915/intel_display.c | 6 ++
drivers/gpu/drm/i915/intel_dp.c | 6 ++
Currently debugfs files are created before the driver is even loads.
This gives the opportunity for userspace to open that interface and poke
around before the backing data structures are initialised - with the
possibility of oopsing or worse.
Move the creation of the debugfs files to our registra
During suspend (or module unload), if we have never accessed the engine
(i.e. userspace never submitted a batch to it), the engine is idle. Then
we attempt to idle the engine by forcing it to the default context,
which actually means we submit a render batch to setup the golden
context state and th
Baby step, update to_i915() conversion from drm_device to
drm_i915_private:
textdata bss dec hex filename
1108812 23207 416 1132435 114793 i915.ko (before)
1104999 23207 416 1128622 1138ae i915.ko (after)
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas
So, at the end of the last take, Ville pointed out that debugfs was
being initialised before our data structures were intact and so this
series acquired a flurry of patches to close that hole so we can
rely on RPS initialisation.
-Chris
___
Intel-gfx mai
When the GPU is reset or state lost through suspend, every default
legacy context needs to reload their state - both the golden render
state and the L3 mapping. Only context images explicitly saved to memory
(i.e. all execlists and non-default legacy contexts) will retain their
state across the res
With the introduction of a connector->func for callback from
drm_connector_register() we can move all the tasks that we want to do
upon registration into that callback. Later, this will allow us to
reorder the registration and defer it until after the device is setup
and ready for userspace.
Signe
Fix the failure mode where the display appears split, or shifted about
2/3 of the screen, and the color components are cycled. Turns out we
were missing the crucial BXT_DEFEATURE_DPI_FIFO_CTR bit in the
EOT_DISABLE register.
Per bspec, with the bit set, the "mipi_dpf_vblank_start" signal is
assert
On Fri, Jun 03, 2016 at 03:36:49PM +0100, Chris Wilson wrote:
> When trying to split up the initialisation phase and the registration
> phase, one immediate problem encountered is trying to use our own i2c
> devices before registration with userspace (to read EDID during device
> discovery). drm_dp
Introduced by 0e11befe442. openat(2) uses a relative path. Fix by
passing the correct fd.
Signed-off-by: Marius Vlad
CC: Chris Wilson
---
lib/igt_kms.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index b12a5b3..135c7b8 100644
--- a/lib/igt
On Fri, Jun 03, 2016 at 03:36:52PM +0100, Chris Wilson wrote:
> In the very near future, we will perform the backlight setup
> consistently during connector registration - moving the setup further
> away from the intel_panel_init call and to where we no longer know the
> associated pipe. To pass th
On Fri, Jun 03, 2016 at 03:36:48PM +0100, Chris Wilson wrote:
> Rather than have both drm_dp_aux lock within its transfer, and i2c to
> lock around the transfer, use the same lock by filling in the locking
> callbacks that i2c wants to use. We require our own hw_mutex as we
> bypass i2c_transfer fo
== Series Details ==
Series: series starting with [v3,01/33] drm: Export drm_dev_init() for
subclassing
URL : https://patchwork.freedesktop.org/series/8231/
State : warning
== Summary ==
Series 8231v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/8231/revisions/1
On Fri, Jun 03, 2016 at 06:04:36PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 03, 2016 at 03:36:52PM +0100, Chris Wilson wrote:
> > In the very near future, we will perform the backlight setup
> > consistently during connector registration - moving the setup further
> > away from the intel_panel_ini
On Fri, Jun 03, 2016 at 05:57:05PM +0300, Jani Nikula wrote:
> Fix the failure mode where the display appears split, or shifted about
> 2/3 of the screen, and the color components are cycled. Turns out we
> were missing the crucial BXT_DEFEATURE_DPI_FIFO_CTR bit in the
> EOT_DISABLE register.
>
>
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
1 - 100 of 237 matches
Mail list logo
