On Fri, Oct 17, 2014 at 08:05:08AM -0700, Rodrigo Vivi wrote:
> Current chv spec teels we can only use either 16 or 32 bits as precision.
>
> Although in the past VLV went from 16/32 to 32/64 and spec might not be
> updated,
> these precision values brings stability and fixes some issues Wayne wa
From: Sonika Jindal
v2: Reading DP_EDP_REV, only when DISPLAY_CONTROL_CAPABLE field is set
(Satheesh)
v3: Moving the utility function to drm_dp_helper (Daniel)
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/drm_dp_helper.c | 15 +++
include/drm/drm_dp_helper.h |2 ++
This is just a second round of the previous series, cleaned up the
problems pointed out (except property hotplug - bigger problem),
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
From: Dave Airlie
Logical ports are never going to have EDID changes,
they are used for the internal ports on MST monitors.
We cache the EDIDs from these to save time at MST probe.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_mst_topology.c | 20 ++--
drivers/gpu/drm/
From: Dave Airlie
A tile group is an identifier shared by a single monitor,
DisplayID topology has 8 bytes we can use for this, just
use those for now until something else comes up in the
future. We assign these to an idr and use the idr to
tell userspace what connectors are in the same tile grou
From: Dave Airlie
These are just taken from the DisplayID v1.3 spec, and the
DDC spec.
v2: use __packed (Jani)
Signed-off-by: Dave Airlie
---
include/drm/drm_displayid.h | 76 +
include/drm/drm_edid.h | 2 ++
2 files changed, 78 insertions(+)
From: Dave Airlie
This takes the tiling info from the connector and
exposes it to userspace, as a blob object in a
connector property.
The contents of the blob is ABI.
v2: add property + function documentation.
Signed-off-by: Dave Airlie
---
Documentation/DocBook/drm.tmpl | 9 +++-
From: Dave Airlie
This creates a tile group from DisplayID block, and
stores the pieces of parsed info from the DisplayID block
into the connector.
v2: add missing signoff, add new connector bits to docs.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 5 ++
drivers/gpu/drm/drm_
From: Dave Airlie
This adds fbdev/con support for tiled monitors, so that we
only set a mode on the correct half of the monitor, or
span the two halves if needed.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_fb_helper.c| 122 +++--
drivers/gpu/drm/i915
> Don't you need a kref_get_unless_zero here since we only destroy the idr
> entry after the refcount dropped to zero? Or is there some magic thing
> that prevents this like another mutex (in which case some mutex assert in
> get/put would be good)?
This does all happen under mode_config.mutex but
From: Dave Airlie
These two didn't get documented properly, do so.
Pointed out by Daniel.
Signed-off-by: Dave Airlie
---
Documentation/DocBook/drm.tmpl | 9 -
drivers/gpu/drm/drm_crtc.c | 10 ++
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Tuesday, October 21, 2014 4:29 AM
> To: He, Shuang
> Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander
> Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915: Make intel_pi
> Aside: We don't handle hpd for port A anyway, so for most panels this
> doesn't matter all that much. Or we'd have piles more bug reports I think.
>
https://bugzilla.redhat.com/show_bug.cgi?id=1118448
probably like this.
Dave.
___
Intel-gfx mailing l
> -Original Message-
> From: Daniel, Thomas
> Sent: Tuesday, October 21, 2014 8:46 PM
> To: Daniel Vetter; He, Shuang
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/bdw: Clean up execlist queue items
> in
>
>
>
> > -Original Message-
> > From:
There's no users left after the conversion to calculate clocks before
disabling crtcs during mode set.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 3 ---
drivers/gpu/drm/i915/intel_display.c | 11 ---
2 files changed, 14 deletions(-)
diff --gi
Now that shared DPLLs configuration is staged, there's no need to track
the current ones in the new pipe_config since those are released before
making the new pipe_config effective.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed,
On Tue, 2014-10-21 at 15:41 +0300, Ville Syrjälä wrote:
> On Wed, Sep 10, 2014 at 06:17:00PM +0300, Imre Deak wrote:
> > If the device is suspended already through the switcheroo interface we
> > shouldn't suspend it again. We have the corresponding check for S3
> > suspend already, add it for S4 f
On Tue, Oct 21, 2014 at 04:08:21PM +0300, Imre Deak wrote:
> On Tue, 2014-10-21 at 15:41 +0300, Ville Syrjälä wrote:
> > On Wed, Sep 10, 2014 at 06:17:00PM +0300, Imre Deak wrote:
> > > If the device is suspended already through the switcheroo interface we
> > > shouldn't suspend it again. We have
On 21 October 2014 23:38, Daniel Vetter wrote:
> Hi Dave,
>
> drm-intel-next-2014-10-03:
> - first batch of skl stage 1 enabling
> - fixes from Rodrigo to the PSR, fbc and sink crc code
> - kerneldoc for the frontbuffer tracking code, runtime pm code and the basic
> interrupt enable/disable func
Tested-by: Wayne Boyer
Before this patch I was getting pipe underrun errors on pipe A and pipe C
when
running various workloads. Shortly after the errors, the screens would go
black
and could not be recovered without rebooting.
With this patch I don't get the underrun errors and the machine has
Mika Kuoppala writes:
> If we build the workaround list in ring initialization
> and decouple it from the actual writing of values, we
> gain the ability to decide where and how we want to apply
> the values.
>
> The advantage of this will become more clear when
> we need to initialize workaround
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_display.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 610de3f..9475271 100644
--- a/drivers/gpu/dr
Regression from:
commit be4710a541b517b5f8663448bffed5656d59b47b
Author: Thomas Wood
Date: Fri Oct 10 11:20:35 2014 +0100
lib: add common min and max macros
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85218
Tested-by: Guo Jinxian
Signed-off-by: Mika Kuoppala
---
lib/igt_aux.
This series changes the mode set sequence so that the clock and PLL
logic that was done in the *_crtc_mode_set() hooks is done before
disabling crtcs. This avoids having to restore the old configuration
in the case of failure, since the hardware was never touched.
Ander Conselvan de Oliveira (8):
On Thu, Sep 11, 2014 at 07:15:27AM -0700, Jesse Barnes wrote:
> On Thu, 11 Sep 2014 14:59:35 +0300
> Imre Deak wrote:
>
> > On Thu, 2014-09-11 at 08:49 +0100, Chris Wilson wrote:
> > > On Wed, Sep 10, 2014 at 06:17:01PM +0300, Imre Deak wrote:
> > > > Since correctness wins over optimal code and
The new struct will be used in a follow up patch to allow a current and
a staged config to exist for the same shared DPLL.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_debugfs.c | 13
drivers/gpu/drm/i915/i915_drv.h | 8 +++--
drivers/gpu/drm/i915/int
Read and verify workaround list before and after the
reset/resume. In addition wait for the gpu before reading
through mmio, so that the rc context gets properly loaded
before we read.
Cc: Arun Siluvery
Signed-off-by: Mika Kuoppala
---
tests/gem_workarounds.c | 127 ++---
On Tue, 2014-10-21 at 16:42 +0300, Ville Syrjälä wrote:
> On Wed, Sep 10, 2014 at 06:17:09PM +0300, Imre Deak wrote:
> > This will hopefully make it easier to navigate the code without the need
> > to consult the full PM documentation.
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm
On Wed, Sep 10, 2014 at 06:17:09PM +0300, Imre Deak wrote:
> This will hopefully make it easier to navigate the code without the need
> to consult the full PM documentation.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_drv.c | 13 +
> 1 file changed, 13 insertions(+
On Wed, Sep 10, 2014 at 06:17:07PM +0300, Imre Deak wrote:
> The suspend_late handler saves some registers and powers off the device,
> so it doesn't have a big overhead. Calling it at S4 poweroff_late time
> makes the power off handling identical to the S3 suspend and S4 freeze
> handling, so do t
On Wed, Sep 10, 2014 at 06:16:53PM +0300, Imre Deak wrote:
> The first part of the patchset (1-6) fixes an S4 bug on VLV introduced
> recently. The rest unifies the various S3/S4 handlers, which are in
> practice the same. The only real difference - besides some unused code -
> is that during S3 su
On Thu, Oct 16, 2014 at 04:13:38PM +0100, Michel Thierry wrote:
> Otherwise we will get WARNs when we read context status registers and
> the machine is suspended.
>
> Testcase: igt/pm_rpm/debugfs-read
> Signed-off-by: Michel Thierry
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vet
On Tue, Oct 21, 2014 at 03:01:49PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If we don't enable audio runtime PM, the audio driver won't release
> its reference, the refcount won't ever become zero, so we will never
> actually runtime suspend. So move this code from pm_rpm.c to
> igt_au
On Tue, Oct 21, 2014 at 02:58:08PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Otherwise, a simple "cat" to the debugfs file can make the machine use
> much more power than needed, and prevent it from runtime suspending.
>
> Related commit:
>
> commit 8452e1d173a16d9812422a2272c4ab0
On Mon, Oct 20, 2014 at 01:20:50PM +0300, Imre Deak wrote:
> On Fri, 2014-10-17 at 16:01 -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > As far as I understand, intel_uncore_early_sanitize() was supposed to
> > be ran before any register access, but currently
> > intel_resume_prepare()
From: Paulo Zanoni
If we don't enable audio runtime PM, the audio driver won't release
its reference, the refcount won't ever become zero, so we will never
actually runtime suspend. So move this code from pm_rpm.c to
igt_aux.c, so kms_flip - and any other IGT test case using RPM - can
benefit fro
From: Paulo Zanoni
Otherwise, a simple "cat" to the debugfs file can make the machine use
much more power than needed, and prevent it from runtime suspending.
Related commit:
commit 8452e1d173a16d9812422a2272c4ab0f0ba81057
Author: Mika Kuoppala
Date: Tue Oct 7 17:21:26 2014 +0300
On Tue, Oct 21, 2014 at 06:16:26PM +0200, Daniel Vetter wrote:
> On Fri, Oct 17, 2014 at 01:37:11PM +0800, Yu Zhang wrote:
> > Intel GVT-g (previously known as XenGT), is a complete GPU
> > virtualization solution with mediated pass-through for 4th
> > generation Intel Core processors - Haswell pla
On Thu, Oct 16, 2014 at 02:24:27PM +0800, Yu Zhang wrote:
> In the virtualized environment, forcewake operations are not
> necessory for the driver, because mmio accesses will be trapped
> and emulated by the host side, and real forcewake operations are
> also done in the host. New mmio write handl
On Fri, Oct 17, 2014 at 01:37:11PM +0800, Yu Zhang wrote:
> Intel GVT-g (previously known as XenGT), is a complete GPU
> virtualization solution with mediated pass-through for 4th
> generation Intel Core processors - Haswell platform. This
> technology presents a virtual full-fledged GPU to each Vi
On Fri, Oct 17, 2014 at 12:08:38PM +0300, Jani Nikula wrote:
> On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > I managed to fumble the per spline PCS DW11 register defines in:
> > commit 9d4f193b077c1973add53e40ff9410a3371900af
>
> Looks like commit 570e
On Tue, Oct 21, 2014 at 01:52:46PM -0200, Paulo Zanoni wrote:
> 2014-10-21 13:18 GMT-02:00 Daniel Vetter :
> > On Tue, Oct 14, 2014 at 04:12:22PM -0300, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> If the signal helper is active, the usleep() calls return earlier, and
> >> we may end up r
On Fri, Oct 17, 2014 at 09:08:28AM -0700, Todd Previte wrote:
>
> On 10/17/2014 1:43 AM, Ville Syrjälä wrote:
> >On Thu, Oct 16, 2014 at 12:38:55PM -0700, Todd Previte wrote:
> >>On 10/16/2014 10:46 AM, ville.syrj...@linux.intel.com wrote:
> >>>From: Ville Syrjälä
> >>>
> >>>Turning vdd on/off ca
On Thu, Oct 16, 2014 at 12:39:29PM -0700, Todd Previte wrote:
>
> On 10/16/2014 10:46 AM, ville.syrj...@linux.intel.com wrote:
> >From: Ville Syrjälä
> >
> >Sometimes we seem to get utter garbage from DPCD reads. The resulting
> >buffer is filled with the same byte, and the operation completed wi
2014-10-21 13:18 GMT-02:00 Daniel Vetter :
> On Tue, Oct 14, 2014 at 04:12:22PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> If the signal helper is active, the usleep() calls return earlier, and
>> we may end up returning false way before the 10s timeout, failing the
>> subtests. This c
On Thu, Oct 16, 2014 at 12:24:42PM -0700, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> libva uses chained batch buffers in a way that the command parser
> can't generally handle. Fortunately, libva doesn't need to write
> registers from batch buffers in the way that mesa does, so thi
On Fri, Oct 17, 2014 at 08:26:13PM +0300, Mika Kuoppala wrote:
> Jani Nikula writes:
>
> > On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
> >> From: Ville Syrjälä
> >>
> >> Only ports B and C have the power sequencer and backlight controls,
> >> so complain if we ever try to register
On Fri, Oct 17, 2014 at 05:17:16PM -0400, Dave Jones wrote:
> Just hit this while fuzz-testing, (curiously, no graphics
> related stuff was happening, X isn't even loaded on that box).
>
> dmar: DRHD: handling fault status reg 2
> dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 7ff0
On Fri, Oct 17, 2014 at 06:42:03PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> For some yet-undiscovered reason, when IPS gets enabled, the pipe CRC
> changes. Since hsw_enable_ips() doesn't really guarantees to enable
> IPS (it depends on package C-states), we can't really predict if IPS
On Wed, Oct 15, 2014 at 02:52:41PM -0700, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> The size of the batch buffer passed to the kernel is significantly
> larger than the size of the batch buffer passed to the function. A
> proposed optimization as part of the batch copy kernel seri
On Fri, Oct 17, 2014 at 02:18:34PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 15, 2014 at 02:15:04PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > In its current place, it just segfaults while trying to access the
> > CRTC structures:
> >
> > [ 9132.421681] Call Trace:
> > [ 9132.4217
On Tue, Oct 14, 2014 at 04:12:22PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If the signal helper is active, the usleep() calls return earlier, and
> we may end up returning false way before the 10s timeout, failing the
> subtests. This currently happens on the kms_flip RPM interruptibl
On Tue, Oct 14, 2014 at 12:28:39PM +0100, Chris Wilson wrote:
> After setting up the copy operations, add a hanging batch. This should
> mean that we complete the copy and the compare then races against the
> GEM reset. Hopefully, this will catch driver bugs where the target
> object is no longer a
On Mon, Oct 13, 2014 at 12:40:48AM +0800, Chia-I Wu wrote:
> On Sun, Oct 12, 2014 at 1:21 AM, Chia-I Wu wrote:
>
> > When timeout_ns is negative, it really means to wait indefinitely instead
> > of
> > returning immediately. But since userspace can no longer rely on that, I
> > am
> > not sure i
On Fri, Oct 17, 2014 at 11:41:12AM -0700, Todd Previte wrote:
> V2 changes:
> - Moved the intel_dp_enable_port() call out of intel_dp_enable() and placed
> it
> before the calls to intel_dp_enable() and vlv_wait_port_ready()
> - Cleaned up a spacing issues with the code indents
> - Amended the
On Fri, Oct 10, 2014 at 06:10:41PM +0300, Jani Nikula wrote:
> On Fri, 10 Oct 2014, Chris Wilson wrote:
> > On Fri, Oct 10, 2014 at 05:53:32PM +0300, Jani Nikula wrote:
> >> Follow-up to
> >> commit dbbe91279511d6a18a521b953a3c139e4787e660
> >> Author: Chris Wilson
> >> Date: Sat Aug 9 19:18:43
On Thu, Oct 09, 2014 at 12:57:45PM -0700, Jesse Barnes wrote:
> From: Kristian Høgsberg
>
> The BIOS may set a native mode that doesn't quite match the preferred
> mode timings. It should be ok to use however if it uses the same size,
> so try to avoid a mode set in that case.
>
> Signed-off-by
On Thu, Oct 09, 2014 at 12:57:44PM -0700, Jesse Barnes wrote:
> From: Kristian Høgsberg
>
> Like mode_equal but w/o the clock checks. Useful for checking if modes
> are close enough to re-use to avoid a boot time mode set for example.
>
> Signed-off-by: Kristian Høgsberg
> Signed-off-by: Jesse
On Thu, Oct 09, 2014 at 12:57:43PM -0700, Jesse Barnes wrote:
> Some machines (like MBAs) might use a tiled framebuffer but not enable
> display swizzling at boot time. We want to preserve that configuration
> if possible to prevent a boot time mode set. On IVB+ it shouldn't
> affect performance
On Thu, Oct 09, 2014 at 09:39:01AM -0700, Todd Previte wrote:
> Link training for Displayport can fail in many ways and at multiple different
> points
> during the training process. Previously, errors were logged but no additional
> action
> was taken based on them. Consequently, training attempt
Hi Dave,
drm-intel-next-2014-10-03:
- first batch of skl stage 1 enabling
- fixes from Rodrigo to the PSR, fbc and sink crc code
- kerneldoc for the frontbuffer tracking code, runtime pm code and the basic
interrupt enable/disable functions
- smaller stuff all over
drm-intel-next-2014-09-19:
- b
It is possible for a mode set to fail if there aren't shared DPLLS that
match the new configuration requirement or other errors in clock
computation. If that step is executed after disabling crtcs, in the
failure case the hardware configuration is changed and needs to be
restored. Doing those thing
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_display.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9475271..9e92ad6 100644
--- a/drivers/gpu/drm/i9
This will be used in a follow up patch to properly release shared DPLLs
without relying on the shared_dpll field in pipe_config.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +--
drivers/gpu/drm/i915/i915_drv.h | 4 +--
drivers/gpu/drm/i915/inte
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_ddi.c | 2 --
drivers/gpu/drm/i915/intel_display.c | 9 -
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 7b8c4b8..b42d76
On Mon, Oct 20, 2014 at 05:13:45PM +0100, Siluvery, Arun wrote:
> On 07/10/2014 15:21, Mika Kuoppala wrote:
> >If we build the workaround list in ring initialization
> >and decouple it from the actual writing of values, we
> >gain the ability to decide where and how we want to apply
> >the values.
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, October 21, 2014 1:14 PM
> To: He, Shuang
> Cc: intel-gfx@lists.freedesktop.org; Daniel, Thomas
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/bdw: Clean up execlist queue
On Tue, Oct 21, 2014 at 2:27 PM, Daniel Vetter wrote:
> There's some simple merge conflicts with current upstream but nothing
> serious really, I can push out a merge point if you want to. As usual
> -nightly has the solution for you to peek at.
Sorrry I've lied, there's an annoying conflict that
On Wed, Sep 10, 2014 at 06:17:00PM +0300, Imre Deak wrote:
> If the device is suspended already through the switcheroo interface we
> shouldn't suspend it again. We have the corresponding check for S3
> suspend already, add it for S4 freeze and poweroff too.
>
> Note that there is still the proble
On Wed, Sep 10, 2014 at 06:16:54PM +0300, Imre Deak wrote:
> During S4 freeze we don't call intel_suspend_complete(), which would
> save the gunit HW state, but during S4 thaw/restore events we call
> intel_resume_prepare() which restores it, thus ending up in a corrupted
> HW state.
>
> Fix this
Hi Dave,
So -rc1 is out the door and the first i915 pull request for 3.19 in your
inbox ;-)
Due to the early drm-next merge window we've already accumulated two
testing cycles instead of the usual one, but somehow there wasn't too much
going on really.
drm-intel-next-2014-10-03:
- first batch of
On Tue, Oct 21, 2014 at 02:40:37PM +0300, Jani Nikula wrote:
> The whole file is only built with CONFIG_COMPAT=y.
>
> Signed-off-by: Jani Nikula
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Tue, Oct 21, 2014 at 01:32:44AM -0700, shuang...@intel.com wrote:
> Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang...@intel.com)
> -Summary-
> Platform: baseline_drm_intel_nightly_pass_rate->patch_ap
On Tue, Oct 21, 2014 at 12:00:30PM +0530, Singh, Gaurav K wrote:
>
> On 9/24/2014 2:57 PM, Jani Nikula wrote:
> >On Wed, 24 Sep 2014, Gaurav K Singh wrote:
> >>Signed-off-by: Gaurav K Singh
> >>Signed-off-by: Shobhit Kumar
> >>---
> >> drivers/gpu/drm/i915/i915_reg.h|1 +
> >>
On Tue, Oct 21, 2014 at 02:56:46PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 10, 2014 at 06:16:55PM +0300, Imre Deak wrote:
> > The legacy DRM suspend logic (effective in UMS) doesn't handle any S4 thaw
> > events so we don't need to care about it either. Only S3 suspend and S4
> > freeze events ar
On Tue, Oct 21, 2014 at 02:36:41PM +0800, Yao Cheng wrote:
> Setup minimum required resources during i915_driver_load:
> 1. Create a platform device to share MMIO/IRQ resources
> 2. Make the platform device child of i915 device for runtime PM.
> 3. Create IRQ chip to forward the VED irqs.
> VED dri
On Wed, Sep 10, 2014 at 06:16:55PM +0300, Imre Deak wrote:
> The legacy DRM suspend logic (effective in UMS) doesn't handle any S4 thaw
> events so we don't need to care about it either. Only S3 suspend and S4
> freeze events are handled. Leave an assert behind to be sure.
>
> Signed-off-by: Imre
The whole file is only built with CONFIG_COMPAT=y.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_ioc32.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_ioc32.c
b/drivers/gpu/drm/i915/i915_ioc32.c
index 2e0613e26251..176de6322e4d 100644
--- a/drivers/gp
On Tue, Oct 21, 2014 at 02:36:41PM +0800, Yao Cheng wrote:
> Setup minimum required resources during i915_driver_load:
> 1. Create a platform device to share MMIO/IRQ resources
> 2. Make the platform device child of i915 device for runtime PM.
> 3. Create IRQ chip to forward the VED irqs.
> VED dri
Hi,
Some time ago I've raised an issue, that only 32bits of TIMESTAMP are being
exposed to userspace on x86_64, you suggested that we need to stay compatible
with old (and new) userspace and proposed adding a new param that can can be
accessed via getparam.
However, after checking beignet and mes
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
BYT: pass/total=19/19->3/19
PNV: pass/total=2/2->1/2
ILK: pas
81 matches
Mail list logo
