== Summary ==
Series 3540v1 drm/i915: Extract intel_encoder_has_connectors()
http://patchwork.freedesktop.org/api/1.0/series/3540/revisions/1/mbox/
Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE
Test kms_pipe_crc_basic:
Some bit rot there. I'll fix the numbering. Thanks for pointing it out.
I did keep the second, redundant, FDI RX disable in place to limit some closed
source driver changes. There is no downside to clearing bit 31 twice.
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@l
On Tue, Feb 09, 2016 at 12:19:15PM +, Lionel Landwerlin wrote:
> Patch based on a previous series by Shashank Sharma.
>
> v2: Update contributors
Is this patch actually necessary? If I recall correctly, _MMIO_PIPE()
will support any number of pipes if the delta between register offsets
for e
On Tue, Feb 09, 2016 at 12:19:14PM +, Lionel Landwerlin wrote:
> Patch based on a previous series by Shashank Sharma.
>
> v2: Register LUT size properties as range
>
> v3: Fix round in drm_color_lut_get_value() helper
> More docs on how degamma/gamma properties are used
>
> v4: Update co
On Mon, Feb 01, 2016 at 03:18:32PM +, Lionel Landwerlin wrote:
> Signed-off-by: Lionel Landwerlin
Given the patch headline and lack of commit message body, I expected
this to be pretty much a straight migration of the code between files
without other changes (aside from [un]static'ing of func
On Wed, Feb 17, 2016 at 8:18 AM, Daniel Vetter wrote:
> On Tue, Feb 16, 2016 at 09:26:35AM -0800, Andy Lutomirski wrote:
>> On Tue, Feb 16, 2016 at 9:12 AM, Andy Lutomirski wrote:
>> > On Tue, Feb 16, 2016 at 8:12 AM, Daniel Vetter wrote:
>> >> On Mon, Feb 15, 2016 at 06:58:33AM -0800, Andy Luto
I was going to merge here but I saw on patchwork we got some warnings
so I'm not sure they are only false positives or this is exactly what
this patches wants...
On Thu, 2016-02-11 at 12:43 +0200, Mika Kuoppala wrote:
> Patrik Jakobsson writes:
>
> > The DMC can incorrectly run off and allow DC
From: Alex Dai
There are several places in driver that a GEM object is mapped to kernel
virtual space. Now add a common function i915_gem_object_vmap to do the vmap
work for such use case.
Alex Dai (2):
drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space
drm/i915/guc: Simpl
From: Alex Dai
GuC client object is always pinned during its life cycle. We cache
the vmap of client object, which includes guc_process_desc, doorbell
and work queue. By doing so, we can simplify the code where driver
communicate with GuC.
As a result, this patch removes the kmap_atomic in wq_ch
From: Alex Dai
There are several places inside driver where a GEM object is mapped to
kernel virtual space. The mapping is either done for the whole object
or certain page range of it.
This patch introduces a function i915_gem_object_vmap to do such job.
Signed-off-by: Alex Dai
Cc: Dave Gordon
On Tue, Feb 16, 2016 at 7:50 AM, Daniel Vetter wrote:
> On Thu, Feb 11, 2016 at 09:00:47AM -0800, Rodrigo Vivi wrote:
>> Framecounter register is read-only so DMC cannot restore it
>> after exiting DC5 and DC6.
>>
>> Easiest way to go is to avoid the counter and use vblank
>> interruptions for thi
On Wed, Feb 17, 2016 at 06:18:21PM +0100, Daniel Vetter wrote:
> On Thu, Feb 04, 2016 at 12:06:57PM +, Derek Morton wrote:
> > Added extended wildcard support when specifying --run-subtest.
> >
> > Wildcard format is as specified in rfc3977 and the uwildmat() implementation
> > is taken from l
Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> Currently we perform our own wait in post_plane_update,
> but the atomic core performs another one in wait_for_vblanks.
> This means that 2 vblanks are done when a fb is changed,
> which is a bit overkill.
>
> Merge them by creating
On Mon, 15 Feb 2016, Deepak M wrote:
> The MIPI clock calculations for the addtional clock
> are revised from B0 stepping onwards, the bit definitions
> have changed compared to old stepping.
>
> v2: Fixing compilation warning.
> v3: Retained the old Macros (Jani)
>
> Signed-off-by: Deepak M
Rev
Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> Right now there's separate power domain handling for update_pipe and
> modesets. Unify this and only grab POWER_DOMAIN_MODESET once.
I would have split this in two separate commits: one for
POWER_DOMAIN_MODESET, and the other for kil
From: Ville Syrjälä
The reason for spcial casing 20MHz in the iclkip calculations is that
it would overflow the 7 bit divisor value. Let's rewrite the special
case to check for just that, and bump up auxdiv when needed. This makes
the code work for freqeuencies close to but not exactly 20MHz. The
From: Ville Syrjälä
Instead of assuming we've correctly set up SPLL to run at 270Mhz for
FDI, let's use the port_clock from pipe_config which should be what
we want. This would catch problems if someone misconfigures SPLL for
whatever reason.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i9
From: Ville Syrjälä
Imre's SNB had a crappy BIOS that failed to configure the hardware
correctly when hooked up to a 4K monitor, which then resulted in
lots of noise from i915 when it was trying to make sense of the bad
state. That spurred me to reorganize the FDI dotclock vs. encoder
dotclock sa
From: Ville Syrjälä
LPT/WPT-H are limited to max 180 MHz CRT dotclock. Most other platforms
have a limit of 350 MHz. Supposedly gen3 and gen4 go up to 400 MHz.
VLV is a bit special since the docs are poor. Supposedly the DAC
would be good up to 355 MHz, but currently we limit the DPLL to
270 MHz
From: Ville Syrjälä
Rather than assume the VGA dotclock is really the FDI based thing,
let's read out the real thing via iclkip, and after readout it'll
get to compare it with the FDI based number to make sure they're
in sync.
Cc: Paulo Zanoni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/
From: Ville Syrjälä
On HSW/BDW ddi_pll_sel is the actual register value. Let's dump
it in hex so that people migth actually understand what it says.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
From: Ville Syrjälä
Currently we check if the encoder's idea of dotclock agrees with what
we calculated based on the FDI parameters. We do this in the encoder
.get_config() hooks, which isn't so nice in case the BIOS (or some other
outside party) made a mess of the state and we're just trying to
From: Ville Syrjälä
We have an open coded loop which tries to see if the encoder has any
connectors linked to it. Let's extract that to a helper similar to
intel_crtc_has_encoders().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 22 --
1 file chang
On Wed, Feb 17, 2016 at 08:32:05AM +0100, Maarten Lankhorst wrote:
> Because we record connector_mask using 1 << drm_connector_index now
> the connector_mask should stay the same even when other connectors
> are removed. This was not the case with MST, in that case when removing
> a connector all o
On Tue, Feb 16, 2016 at 07:53:45PM +0200, Ander Conselvan de Oliveira wrote:
> The wait for other gens was added in commit 564ed191f5d8 ("drm/i915:
> gmch: fix stuck primary plane due to memory self-refresh mode") since
> that's necessary when disabling cxsr. However, cxsr disabling was later
> mov
Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> Use our newly created encoder_mask to iterate over the encoders.
As someone who was not paying attention to the discussion of the
previous patches related to this, I think it would be really good if
your commit message could tell me
On 02/17/2016 08:04 AM, Daniel Vetter wrote:
On Tue, Feb 16, 2016 at 08:47:07AM -0800, Yu Dai wrote:
>
>
> On 02/15/2016 07:23 AM, Dave Gordon wrote:
> >On 12/02/16 13:03, Tvrtko Ursulin wrote:
> >>
> >> On 11/02/16 23:09, yu@intel.com wrote:
> >>> From: Alex Dai
> >>>
> >>> GuC client obj
On Tue, Dec 08, 2015 at 04:47:55PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Bspec is confused w.r.t. the HSW/BDW FDI disable sequence. It lists
> FDI RX disable both as step 13 and step 18 in the sequence. But I dug
> up an old BUN mail from Art that moved the FDI RX
Hi Sourab,
As Sergio Martinez has started experimenting with this in gputop and
reported seeing lots of ENOSPC errors being reported when reading I had a
look into this and saw a few issues with how we check that there's data
available to read in command stream mode, and a I think there's a
possib
Used by production device:
Intel(R) Iris(TM) Graphics P555
Signed-off-by: Michał Winiarski
---
include/drm/i915_pciids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 9094599..9266c2c 100644
--- a/include/drm/i915_pciids.h
+++
On Wed, 17 Feb 2016, Daniel Vetter wrote:
> On Wed, Feb 17, 2016 at 11:25:49AM +0200, Jani Nikula wrote:
>> On Tue, 16 Feb 2016, Ander Conselvan de Oliveira
>> wrote:
>> > The wait for other gens was added in commit 564ed191f5d8 ("drm/i915:
>> > gmch: fix stuck primary plane due to memory self-r
On Thu, Feb 04, 2016 at 12:06:57PM +, Derek Morton wrote:
> Added extended wildcard support when specifying --run-subtest.
>
> Wildcard format is as specified in rfc3977 and the uwildmat() implementation
> is taken from libinn.
> See https://tools.ietf.org/html/rfc3977#section-4 for a descript
On Tue, Feb 16, 2016 at 09:44:55AM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Set cdclk based on the max required pixel clock based on VCO
> selected. Track boot vco instead of boot cdclk.
>
> The vco is now tracked at the atomic level and all CRTCs updated if
> the requir
On ke, 2016-02-17 at 15:47 +, Patchwork wrote:
> == Summary ==
>
> Series 3532v1 drm/i915/skl: Ensure HW is powered during DDB HW state
> readout
> http://patchwork.freedesktop.org/api/1.0/series/3532/revisions/1/mbox
> /
>
> Test drv_hangman:
> Subgroup error-state-basic:
>
On ke, 2016-02-17 at 16:55 +0200, Jani Nikula wrote:
> On Wed, 17 Feb 2016, Imre Deak wrote:
> > The assumption when adding the intel_display_power_is_enabled()
> > checks
> > was that if it returns success the power can't be turned off
> > afterwards
> > during the HW access, which is guaranteed
On Wed, Feb 17, 2016 at 05:33:51PM +0100, Daniel Vetter wrote:
> On Wed, Feb 17, 2016 at 05:14:57PM +0100, Peter Zijlstra wrote:
> > On Wed, Feb 17, 2016 at 05:13:21PM +0100, Daniel Vetter wrote:
> > > And for context we're hitting this on CI in a bunch of our machines, which
> >
> > What's CI ?
>
On Wed, Feb 17, 2016 at 05:14:57PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 17, 2016 at 05:13:21PM +0100, Daniel Vetter wrote:
> > And for context we're hitting this on CI in a bunch of our machines, which
>
> What's CI ?
Continuous integration, aka our own farm of machines dedicated to running
On Tue, Feb 16, 2016 at 06:47:21PM -0200, Paulo Zanoni wrote:
> These platforms should be fine now.
>
> FBC can allow very significant power savings for screen-on idle
> systems, but it is worth mentioning that a lot of people won't get
> significant power savings by enabling this feature because
On Wed, Feb 17, 2016 at 11:25:49AM +0200, Jani Nikula wrote:
> On Tue, 16 Feb 2016, Ander Conselvan de Oliveira
> wrote:
> > The wait for other gens was added in commit 564ed191f5d8 ("drm/i915:
> > gmch: fix stuck primary plane due to memory self-refresh mode") since
> > that's necessary when dis
On Tue, Feb 16, 2016 at 09:26:35AM -0800, Andy Lutomirski wrote:
> On Tue, Feb 16, 2016 at 9:12 AM, Andy Lutomirski wrote:
> > On Tue, Feb 16, 2016 at 8:12 AM, Daniel Vetter wrote:
> >> On Mon, Feb 15, 2016 at 06:58:33AM -0800, Andy Lutomirski wrote:
> >>> On Sun, Feb 14, 2016 at 6:59 PM, Andy Lu
On Wed, Feb 17, 2016 at 05:13:21PM +0100, Daniel Vetter wrote:
> And for context we're hitting this on CI in a bunch of our machines, which
What's CI ?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listi
On Wed, Feb 17, 2016 at 03:20:05PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 17, 2016 at 02:47:31PM +0200, Joonas Lahtinen wrote:
> > On ti, 2016-02-16 at 12:07 +0100, Peter Zijlstra wrote:
> > > On Tue, Feb 16, 2016 at 12:51:03PM +0200, Joonas Lahtinen wrote:
> > > > Quoting my original patch;
>
On Wed, Feb 17, 2016 at 02:20:49PM +0200, Imre Deak wrote:
> On ti, 2016-02-16 at 17:02 +0100, Daniel Vetter wrote:
> > On Fri, Feb 12, 2016 at 06:55:17PM +0200, Imre Deak wrote:
> > > The assumption when adding the intel_display_power_is_enabled()
> > > checks
> > > was that if it returns success
On Tue, Feb 16, 2016 at 08:47:07AM -0800, Yu Dai wrote:
>
>
> On 02/15/2016 07:23 AM, Dave Gordon wrote:
> >On 12/02/16 13:03, Tvrtko Ursulin wrote:
> >>
> >> On 11/02/16 23:09, yu@intel.com wrote:
> >>> From: Alex Dai
> >>>
> >>> GuC client object is always pinned during its life cycle. We
== Summary ==
Series 3532v1 drm/i915/skl: Ensure HW is powered during DDB HW state readout
http://patchwork.freedesktop.org/api/1.0/series/3532/revisions/1/mbox/
Test drv_hangman:
Subgroup error-state-basic:
incomplete -> PASS (snb-dellxps)
Test kms_flip:
Sub
Works perfectly, fixes the issues with MST over here.
Reviewed-by: Lyude
On Wed, 2016-02-17 at 08:32 +0100, Maarten Lankhorst wrote:
> Because we record connector_mask using 1 << drm_connector_index now
> the connector_mask should stay the same even when other connectors
> are removed. This was
Imre Deak writes:
> The assumption when adding the intel_display_power_is_enabled() checks
> was that if it returns success the power can't be turned off afterwards
> during the HW access, which is guaranteed by modeset locks. This isn't
> always true, so make sure we hold a dedicated reference f
== Summary ==
Series 3522v1 drm/i915/bxt: Initialize MIPI DSI for BXT
http://patchwork.freedesktop.org/api/1.0/series/3522/revisions/1/mbox/
Test drv_hangman:
Subgroup error-state-basic:
incomplete -> PASS (snb-dellxps)
Test kms_flip:
Subgroup basic-flip-vs-w
On Wed, 17 Feb 2016, Imre Deak wrote:
> The assumption when adding the intel_display_power_is_enabled() checks
> was that if it returns success the power can't be turned off afterwards
> during the HW access, which is guaranteed by modeset locks. This isn't
> always true, so make sure we hold a de
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
On ke, 2016-02-17 at 12:44 +, Patchwork wrote:
> == Summary ==
>
> Series 3372v3 drm/i915: add missing display power refs
> http://patchwork.freedesktop.org/api/1.0/series/3372/revisions/3/mbox
> /
>
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> dmesg-warn -> PASS
On Wed, Feb 17, 2016 at 02:47:31PM +0200, Joonas Lahtinen wrote:
> On ti, 2016-02-16 at 12:07 +0100, Peter Zijlstra wrote:
> > On Tue, Feb 16, 2016 at 12:51:03PM +0200, Joonas Lahtinen wrote:
> > > Quoting my original patch;
> > >
> > > "See the Bugzilla link for more details.
> >
> > If its not
From: Shashank Sharma
This patch contains following changes:
1. Add BXT MIPI display address base.
2. Call dsi_init from display_setup function.
v2: Rebased on latest nightly branch
v3 by Jani: init dsi after ddi
Signed-off-by: Shashank Sharma
Signed-off-by: Uma Shankar
Signed-off-by: Jani N
On 12/02/16 09:38, Derek Morton wrote:
Add subtests to test each ring to check batch buffers of a higher
priority will be executed before batch buffers of a lower priority.
Signed-off-by: Derek Morton
---
tests/gem_scheduler.c | 34 --
1 file changed, 28 ins
From: Uma Shankar
DSP CLK_GATE registers are specific to BYT and CHT.
Avoid programming the same for BXT platform.
v2: Rebased on latest drm nightly branch.
v3: Fixed Jani's review comments
Signed-off-by: Uma Shankar
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi.c | 11 +
On 12/02/16 09:38, Derek Morton wrote:
From: John Harrison
The GPU scheduler has added an execution priority level to the context
object. There is an IOCTL interface to allow user apps/libraries to
set this priority. This patch updates the context paramter IOCTL test
to include the new interfa
On Wed, 10 Feb 2016, Daniel Vetter wrote:
> On Fri, Jan 29, 2016 at 09:40:32AM +0200, Jani Nikula wrote:
>> Add two new subcommands for cherry-picking fixes from dinq to
>> drm-intel-fixes and drm-intel-next-fixes. The only difference in the
>> subcommands is the assert branch check to ensure the
On Mon, Jan 11, 2016 at 09:16:14AM +, Chris Wilson wrote:
> userptr requires mmu-notifier for full unprivileged support. Most
> systems have mmu-notifier support already enabled as a requirement for
> virtualisation support, but we should make the option for i915 to take
> advantage of mmu-noti
Hi,
On ma, 2016-02-15 at 22:54 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The size of the rotated ggtt mapping ought to include the size of the
> chroma plane as well. Not a huge deal since we don't expose NV12 (or any
> pother planar format for that matter) yet.
>
>
On ti, 2016-02-16 at 12:07 +0100, Peter Zijlstra wrote:
> On Tue, Feb 16, 2016 at 12:51:03PM +0200, Joonas Lahtinen wrote:
> > Quoting my original patch;
> >
> > "See the Bugzilla link for more details.
>
> If its not in the Changelog it doesn't exist. Patches should be self
> contained and not r
== Summary ==
Series 3372v3 drm/i915: add missing display power refs
http://patchwork.freedesktop.org/api/1.0/series/3372/revisions/3/mbox/
Test pm_rpm:
Subgroup basic-pci-d3-state:
dmesg-warn -> PASS (bsw-nuc-2)
bsw-nuc-2total:165 pass:136 dwarn:0 dfail
Hi,
first round of comments inline. A few things will probably have to
change based on the comments on the previous patch in the series so I'll
have a better look at the related logic once the new series is up.
Regards,
Daniele
On 12/02/16 09:38, Derek Morton wrote:
This is intended to tes
On ti, 2016-02-16 at 17:02 +0100, Daniel Vetter wrote:
> On Fri, Feb 12, 2016 at 06:55:17PM +0200, Imre Deak wrote:
> > The assumption when adding the intel_display_power_is_enabled()
> > checks
> > was that if it returns success the power can't be turned off
> > afterwards
> > during the HW access
We have many places in the code where we check if a given display power
domain is enabled and if so access registers backed by this power
domain. We assumed that some modeset lock will prevent the power
reference from vanishing in the middle of the HW access, but this
assumption doesn't always hold
Hi Maarten,
There will be no difference in execution based on ATOMIC client cap.
If it fails, the number of properties we receive is 2 (type and
rotation) whereas if ATOMIC client cap is set, we actually receive all
the supported atomic properties i.e. src_w,src_h etc.
We have added the retur
Used by production devices:
Intel(R) HD Graphics 510
Intel(R) HD Graphics 535
Intel(R) Iris(TM) Graphics 550
Intel(R) Iris(TM) Graphics P555
Signed-off-by: Michał Winiarski
---
intel/intel_chipset.h | 24
1 file changed, 16 insertions(+), 8 deletions(-)
== Summary ==
Series 3515v1 Use more atomic state in i915.
http://patchwork.freedesktop.org/api/1.0/series/3515/revisions/1/mbox/
Test gem_ringfill:
Subgroup basic-default-hang:
incomplete -> PASS (snb-dellxps)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
== Summary ==
Series 3514v1 drm/atomic: Allow for holes in connector state, v2.
http://patchwork.freedesktop.org/api/1.0/series/3514/revisions/1/mbox/
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test pm_rpm:
Subgroup
On 12/02/16 09:38, Derek Morton wrote:
Adds functions to create a number of different batch buffers to perform
several functions including:
Batch buffer which will run for a long duration to provide a delay on a
specified ring.
Function to calibrate the delay batch buffer to run for a specified
On Tue, 16 Feb 2016, Ander Conselvan de Oliveira
wrote:
> The wait for other gens was added in commit 564ed191f5d8 ("drm/i915:
> gmch: fix stuck primary plane due to memory self-refresh mode") since
> that's necessary when disabling cxsr. However, cxsr disabling was later
> moved to intel_pre_dis
== Summary ==
Series 3513v1 drm/i915: avoid dereferencing NULL pointer when failing to pin
global ctx
http://patchwork.freedesktop.org/api/1.0/series/3513/revisions/1/mbox/
Test gem_ringfill:
Subgroup basic-default-hang:
incomplete -> PASS (snb-dellxps)
Test gem_syn
On Tue, 16 Feb 2016, Patchwork wrote:
> == Summary ==
>
> Series 3477v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/3477/revisions/1/mbox/
>
> Test gem_ringfill:
> Subgroup basic-default-hang:
> incomplete -> PASS (snb-dellxps)
> Test
== Summary ==
Series 3500v1 drm/i915/fbc: enable FBC by default on HSW and BDW
http://patchwork.freedesktop.org/api/1.0/series/3500/revisions/1/mbox/
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-rte:
== Summary ==
Series 3496v1 drm/i915: Wait for vblank in i9xx_disable_crtc() for gen 2 only
http://patchwork.freedesktop.org/api/1.0/series/3496/revisions/1/mbox/
Test gem_ringfill:
Subgroup basic-default-hang:
incomplete -> PASS (snb-dellxps)
Test kms_flip:
This is another step in removing legacy state.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_fbdev.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/int
This is a resend to get the results from CI. The patches have been reviewed.
Maarten Lankhorst (5):
drm/i915: Use atomic state to obtain load detection crtc, v3.
drm/i915: Use atomic state for load detect in crt.
drm/i915: Use atomic state in tv load detection.
drm/i915: Use correct dpms f
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_tv.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index d21f75bda96e..6745bad5bff0 100644
--- a/drivers/
Instead of restoring dpms and a flag for whether a temp fb is allocated
duplicate
an atomic state before the new state is committed, and commit it the old state
in intel_release_load_detect_pipe.
Changes since v1:
- Use a real atomic state. (Ville)
Changes since v2:
- Do not preserve shared_dpll
With the conversion to atomic only on/off are still supported.
The rest is mapped to one of those, and when enable is called
DPMS_ON should be true.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_crt.c | 4 +---
1 file changed, 1 insertion(+), 3 delet
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_crt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index ad5dfabc452e..1e23e073dee9 100644
--- a/drivers/gpu
80 matches
Mail list logo
