On Mon, 25 Jan 2016, Gerd Hoffmann wrote:
> The test for the qemu q35 south bridge added by commit
> "39bfcd52 drm/i915: more virtual south bridge detection"
> also matches on real hardware. Having the check for
> virtual systems last in the list is not enough to avoid
> that ...
>
> Refine the c
On Fri, 29 Jan 2016, Mat Martineau wrote:
> No functional change
>
> Signed-off-by: Mat Martineau
Fixes: f8d03ea0053b ("drm/i915: increase the tries for HDMI hotplug live status
checking")
Pushed to drm-intel-next-queued, thanks for the patch.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_h
Arun Siluvery writes:
> From: Dave Gordon
>
> Also decode and output CSB entries, in time order
>
Traditionally we have had the decoding burden in
igt/tools/intel_error_decode.
Is there reason not to follow that pattern?
-Mika
> For: VIZ-2021
> Signed-off-by: Dave Gordon
> ---
> drivers/gp
On Fri, 29 Jan 2016, Pankaj Chavan wrote:
> Any help in resolving this would be appreciated. Is there a pointer to
> an existing bug report/mailing list email?
Please file a bug at [1], add drm.debug=14 module parameter, attach
dmesg from boot to trying to use the display on the dock.
BR,
Jani.
Co-Author : Marius Vlad
So far we have had only two commit styles, COMMIT_LEGACY
and COMMIT_UNIVERSAL. This patch adds another commit style
COMMIT_ATOMIC which makes use of drmModeAtomicCommit()
Signed-off-by: Mayuresh Gharpure
---
lib/igt_kms.c | 317 ++
On Fr, 2016-01-29 at 09:59 +0200, Jani Nikula wrote:
> On Mon, 25 Jan 2016, Gerd Hoffmann wrote:
> > The test for the qemu q35 south bridge added by commit
> > "39bfcd52 drm/i915: more virtual south bridge detection"
> > also matches on real hardware. Having the check for
> > virtual systems last
tim.g...@intel.com writes:
> From: Tim Gore
>
> WaIncreaseDefaultTLBEntries increases the number of TLB
> entries available for GPGPU workloads and gives significant
> ( > 10% ) performance gain for some OCL benchmarks.
> Put this in a new function that can be a place for
> workarounds that are G
On Tuesday 26 January 2016 06:52 PM, Ander Conselvan De Oliveira wrote:
On Tue, 2016-01-19 at 16:07 +0530, Shubhangi Shrivastava wrote:
Current DP detection has DPCD operations split across
intel_dp_hpd_pulse and intel_dp_detect which contains
duplicates as well. Also intel_dp_detect is called
On Fri, 29 Jan 2016, Gerd Hoffmann wrote:
> On Fr, 2016-01-29 at 09:59 +0200, Jani Nikula wrote:
>> On Mon, 25 Jan 2016, Gerd Hoffmann wrote:
>> > The test for the qemu q35 south bridge added by commit
>> > "39bfcd52 drm/i915: more virtual south bridge detection"
>> > also matches on real hardwar
From: Daniele Ceraolo Spurio
gem_require_ring will submit an execbuf using the provided flags and
skip the test if the ioctl fails. This test is however designed to catch
issues with the ioctl, so it should fail if the ioctl fails on a ring
that the HW possesses.
Instead of using gem_require_rin
Signed-off-by: Gerd Hoffmann
---
depends on
http://mid.gmane.org/1453739846-3549-1-git-send-email-robb...@gentoo.org
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
ind
Hi Gerd,
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v4.5-rc1 next-20160129]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Gerd-Hoffmann/drm-i915-use-defines-for
Hi Gerd,
[auto build test WARNING on drm-intel/for-linux-next]
[cannot apply to v4.5-rc1 next-20160129]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Gerd-Hoffmann/drm-i915-use-defines-for
On 29/01/2016 08:17, Mika Kuoppala wrote:
Arun Siluvery writes:
From: Dave Gordon
Also decode and output CSB entries, in time order
Traditionally we have had the decoding burden in
igt/tools/intel_error_decode.
Is there reason not to follow that pattern?
I have not use error_decode muc
== Summary ==
Series 2822v2 Series without cover letter
Apply patch:
http://patchwork.freedesktop.org/api/1.0/series/2822/revisions/2/mbox/
Applying: drm/vblank: Use drm_event_reserve_init
Applying: drm: Clean up pending events in the core
Applying: drm: Nuke vblank event file cleanup code
Applyi
On 29/01/2016 07:52, Mika Kuoppala wrote:
Arun Siluvery writes:
From Gen8 onwards we apply ctx workarounds using special batch buffers that
execute during save/restore, good to have them in error state.
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drive
Mesa uses it as Intel(R) Iris Graphics 550 (Skylake GT3e)
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 f970209..eb198d0 100644
--- a/include/drm/i915_pciids.h
+++ b/in
== Summary ==
Series 2901v1 drm/i915/bxt: update list of PCIIDs
http://patchwork.freedesktop.org/api/1.0/series/2901/revisions/1/mbox/
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_pipe_crc_basic:
Subgroup nonb
== Summary ==
Series 2850v2 drm/i915: Capture revision id in error state
http://patchwork.freedesktop.org/api/1.0/series/2850/revisions/2/mbox/
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_force_connector_basic:
== Summary ==
HEAD is now at 5de97b2 drm-intel-nightly: 2016y-01m-29d-07h-32m-09s UTC
integration manifest
Applying: drm/i915: tidy up initialisation failure paths (legacy)
Applying: drm/i915: tidy up initialisation failure paths (GEM & LRC)
Applying: drm/i915: unmap the correct page in intel_log
On Fri, Jan 29, 2016 at 09:21:33AM +, daniele.ceraolospu...@intel.com wrote:
> From: Daniele Ceraolo Spurio
>
> gem_require_ring will submit an execbuf using the provided flags and
> skip the test if the ioctl fails. This test is however designed to catch
> issues with the ioctl, so it should
== Summary ==
Series 2906v1 Capture more useful details in error state
http://patchwork.freedesktop.org/api/1.0/series/2906/revisions/1/mbox/
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass -> FAIL (ilk-hp8440p)
Test kms_pipe_crc_basic:
Subgroup
On 29/01/2016 10:27, Patchwork wrote:
== Summary ==
Series 2850v2 drm/i915: Capture revision id in error state
http://patchwork.freedesktop.org/api/1.0/series/2850/revisions/2/mbox/
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass -> DMESG-WARN (ilk-hp8440p) UNST
Hi Dan,
On 28/01/16 22:30, Dan Carpenter wrote:
Hello Tvrtko Ursulin,
The patch de1add360522: "drm/i915: Decouple execbuf uAPI from
internal implementation" from Jan 15, 2016, leads to the following
static checker warning:
drivers/gpu/drm/i915/i915_gem_execbuffer.c:1411 eb_select_ring
On 29/01/16 10:58, Chris Wilson wrote:
On Fri, Jan 29, 2016 at 09:21:33AM +, daniele.ceraolospu...@intel.com wrote:
From: Daniele Ceraolo Spurio
gem_require_ring will submit an execbuf using the provided flags and
skip the test if the ioctl fails. This test is however designed to catch
i
== Summary ==
Series 2907v1 drm/i915: Check DDI max lanes after applying BXT workaround
http://patchwork.freedesktop.org/api/1.0/series/2907/revisions/1/mbox/
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
skip -> PASS (byt-nuc)
bdw-nuci7tot
== Summary ==
Series 2908v1 drm/i915/skl: Fix DMC load on Skylake J0 and K0
http://patchwork.freedesktop.org/api/1.0/series/2908/revisions/1/mbox/
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
skip -> PASS (byt-nuc)
bdw-nuci7total:156 pass
On Fri, Jan 29, 2016 at 11:16:37AM +, Daniele Ceraolo Spurio wrote:
>
>
> On 29/01/16 10:58, Chris Wilson wrote:
> >On Fri, Jan 29, 2016 at 09:21:33AM +, daniele.ceraolospu...@intel.com
> >wrote:
> >>From: Daniele Ceraolo Spurio
> >>
> >>gem_require_ring will submit an execbuf using the
On Fri, Jan 29, 2016 at 09:49:07AM +0200, Mika Kuoppala wrote:
> Arun Siluvery writes:
>
> > From: Dave Gordon
> >
> > At present, execlist status/ctx_id and CSBs, not the submission queue
> >
> > For: VIZ-2021
> > Signed-off-by: Dave Gordon
> > ---
> > drivers/gpu/drm/i915/i915_drv.h |
On Thu, Jan 28, 2016 at 07:01:21PM +, Arun Siluvery wrote:
> From: Dave Gordon
>
> For: VIZ-2021
> Signed-off-by: Dave Gordon
What information does this actually provide over and above the hw is not
executing the ring we expect? How have you used this, how do you plan
to?
As it stands addi
== Summary ==
Series 2919v1 drm/i915/skl: Add missing SKL GT3 id
http://patchwork.freedesktop.org/api/1.0/series/2919/revisions/1/mbox/
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
skip -> PASS (byt-nuc)
Subgroup read-crc-pipe-a:
On 29/01/16 11:35, Chris Wilson wrote:
On Fri, Jan 29, 2016 at 11:16:37AM +, Daniele Ceraolo Spurio wrote:
On 29/01/16 10:58, Chris Wilson wrote:
On Fri, Jan 29, 2016 at 09:21:33AM +, daniele.ceraolospu...@intel.com wrote:
From: Daniele Ceraolo Spurio
gem_require_ring will submit
On Fri, 2016-01-29 at 14:31 +0530, Shubhangi Shrivastava wrote:
>
> On Tuesday 26 January 2016 06:52 PM, Ander Conselvan De Oliveira wrote:
> > On Tue, 2016-01-19 at 16:07 +0530, Shubhangi Shrivastava wrote:
> > > Current DP detection has DPCD operations split across
> > > intel_dp_hpd_pulse and i
On Fri, Jan 29, 2016 at 11:58:14AM +, Daniele Ceraolo Spurio wrote:
>
>
> On 29/01/16 11:35, Chris Wilson wrote:
> >On Fri, Jan 29, 2016 at 11:16:37AM +, Daniele Ceraolo Spurio wrote:
> >>
> >>On 29/01/16 10:58, Chris Wilson wrote:
> >>>On Fri, Jan 29, 2016 at 09:21:33AM +, daniele.ce
Hi,
I have spoken to Dave. I do not want to implement multiple --run-subtest as it
is not something I require and I do not think it is worth adding unless someone
has a specific need for it. However I understand that whatever is done should
not make that harder in the future to add multiple --r
On 29/01/2016 11:45, Chris Wilson wrote:
On Fri, Jan 29, 2016 at 09:49:07AM +0200, Mika Kuoppala wrote:
Arun Siluvery writes:
From: Dave Gordon
At present, execlist status/ctx_id and CSBs, not the submission queue
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_dr
On 28/01/16 12:57, Dave Gordon wrote:
On 28/01/16 11:05, Derek Morton wrote:
Added support for specifying arbitary lists of subtests to run, or
to exclude from being run if prefixed by ^ or !.
subtest1,subtest2 Will run subtest1 and subtest2
^subtest1,subtest2 or !subtest1,subtest2 will run all
On Fri, Jan 29, 2016 at 12:02:26AM +, Chris Bainbridge wrote:
> Hi,
>
> I'm using 4.5-rc1 and before that 4.4. Twice in the past month I've
> rebooted and the root btrfs partition has become corrupted and
> unbootable. I was wondering if the cause could be i915 and if so is
> there any better
On Fri, Jan 29, 2016 at 12:25:02PM +, Arun Siluvery wrote:
> On 29/01/2016 11:45, Chris Wilson wrote:
> >On Fri, Jan 29, 2016 at 09:49:07AM +0200, Mika Kuoppala wrote:
> >>Arun Siluvery writes:
> >>
> >>>From: Dave Gordon
> >>>
> >>>At present, execlist status/ctx_id and CSBs, not the submiss
Hi,
I still do not see FB_ID set to 0 when disabling the plane in
igt_atomic_prepare_plane_commit().
See
http://lists.freedesktop.org/archives/intel-gfx/2016-January/085790.html
On Fri, Jan 29, 2016 at 02:17:11PM +0530, Mayuresh Gharpure wrote:
> Co-Author : Marius Vlad
Atm we wouldn't catch these errors or on the error path we would end up
with a division-by-zero, fix this up.
Caught by Coverity.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_pm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.
While not being able to enable MSI interrupts may be a normal
circumstance, for debugging it may still be a useful information, so
emit an info about this.
Caught by Coverity.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_dma.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-
Caught by Coverity.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_tv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 948cbff..5034b00 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/in
While we are calling intel_dp_aux_transfer() with msg->size=0 whenever
msg->buffer is NULL, passing NULL to memcpy() is undefined according to
the ISO C standard. I haven't found any notes about this in the GNU C's
or the kernel's documentation of the function and can't imagine what it
would do wit
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
== Summary ==
Series 2922v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/2922/revisions/1/mbox/
bdw-nuci7total:156 pass:147 dwarn:0 dfail:0 fail:0 skip:9
bdw-ultratotal:159 pass:147 dwarn:0 dfail:0 fail:0 skip:12
bsw-nuc-2
On Fri, Jan 29, 2016 at 02:52:26PM +0200, Imre Deak wrote:
> While we are calling intel_dp_aux_transfer() with msg->size=0 whenever
> msg->buffer is NULL, passing NULL to memcpy() is undefined according to
> the ISO C standard. I haven't found any notes about this in the GNU C's
> or the kernel's d
Hi,
TL;DR Overall, we have same problem as with the scheduler series, there
is too much placeholder stuff for easy review. Just squash enough code
into one commit so it actually does something logical that can be
reviewed and then extend it later. Then it can be reviewed and pushed.
Just splitting
On Fri, Jan 29, 2016 at 02:52:27PM +0200, Imre Deak wrote:
> Atm we wouldn't catch these errors or on the error path we would end up
> with a division-by-zero, fix this up.
>
> Caught by Coverity.
>
> Signed-off-by: Imre Deak
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/intel_pm
On Fri, Jan 29, 2016 at 02:52:28PM +0200, Imre Deak wrote:
> While not being able to enable MSI interrupts may be a normal
> circumstance, for debugging it may still be a useful information, so
> emit an info about this.
>
> Caught by Coverity.
>
> Signed-off-by: Imre Deak
Reviewed-by: David We
On Fri, Jan 29, 2016 at 02:52:29PM +0200, Imre Deak wrote:
> Caught by Coverity.
>
> Signed-off-by: Imre Deak
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/intel_tv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/i
Arun Siluvery writes:
> From: Tomas Elf
>
> TDR = Timeout Detection and Recovery.
>
> This change introduces support for TDR-style per-engine reset as an initial,
> less intrusive hang recovery option to be attempted before falling back to the
> legacy full GPU reset recovery mode if necessary.
On Thu, Jan 28, 2016 at 03:09:37PM -0800, Matt Roper wrote:
> In commit bfb9faab8 we added a workaround for some BXT BIOS that fail to
> properly initialize the DDI_A_4_LANES bit of the control register (4
> lanes is the only valid configuration on BXT since there is no DDI E to
> share with). A r
Michał Winiarski writes:
> Mesa uses it as Intel(R) Iris Graphics 550 (Skylake GT3e)
>
Apparently this is not only we are missing:
0x1923
0x1902
0x1906
Could you please add these also.
Thanks,
-Mika
> Signed-off-by: Michał Winiarski
> ---
> include/drm/i915_pciids.h | 1 +
> 1 file change
On Fri, Jan 29, 2016 at 03:57:09PM +0200, Joonas Lahtinen wrote:
> Hi,
>
> TL;DR Overall, we have same problem as with the scheduler series, there
> is too much placeholder stuff for easy review. Just squash enough code
> into one commit so it actually does something logical that can be
> reviewed
As we add the VMA to the request early, it may be cancelled during
execbuf reservation. This will leave the context object pointing to a
dangling request; i915_wait_request() simply skips the wait and so we
may unbind the object whilst it is still active.
However, if at any point we make a change
commit 033908aed5a596f6202c848c6bbc8a40fb1a8490
Author: Dave Gordon
Date: Thu Dec 10 18:51:23 2015 +
drm/i915: mark GEM object pages dirty when mapped & written by the CPU
introduced a check into i915_gem_object_get_dirty_pages() that returned
a NULL pointer when called with a bad obje
intel_rcs_ctx_init() can be interrupted by a signal (if it has to wait
upon a full ring to advance). Don't emit an error for this.
Testcase: igt/gem_concurrent_blit
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
On Friday, January 29, 2016 12:24 AM, Jani Nikula
wrote:
>
>
>
>Please file a bug at [1], add drm.debug=14 module parameter, attach
>dmesg from boot to trying to use the display on the dock.
>
Thanks, will do so once I get back to work on Monday.
Pankaj
Used by production devices:
Intel(R) HD Graphics 510 (Skylake GT1)
Intel(R) Iris Graphics 540 (Skylake GT3e)
Intel(R) Iris Graphics 550 (Skylake GT3e)
v2: More ids
Cc: Mika Kuoppala
Signed-off-by: Michał Winiarski
---
include/drm/i915_pciids.h | 3 +++
1 file changed, 3 insertions(
RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6
setup registers. If those are not setup Driver should not enable RC6.
For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values
to know if BIOS has enabled HW/SW RC6.
This will also enable user to control RC6 using B
From: Ville Syrjälä
Add a few helpers to get the dimensions of the chroma plane(s).
v2: Add kernel-doc (Daniel)
v3: Fix kerneldoc "Returns:" style (Daniel)
Uninline the functions and check for num_planes (Daniel)
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by:
Most of the patch is to change the tile/untile functions so they can
work with Y-major tiling.
We're also skipping on BLT for Y-tiling. Some parts of the spec
suggest this doesn't work and some parts of the spec suggest it will
work. Since I couldn't make it work, SKIP for now.
Signed-off-by: Pau
This is the program that's supposed to test lib/igt_draw. We just
added Y tiling support for the library, so add the tests now.
Signed-off-by: Paulo Zanoni
---
tests/kms_draw_crc.c | 55 ++--
1 file changed, 40 insertions(+), 15 deletions(-)
diff
The interesting thing is that if we don't do this, we still get a
Y tiled framebuffer, but there won't be a fence around it, which makes
the GTT mmaps less interesting. Is this a Kernel bug?
Signed-off-by: Paulo Zanoni
---
lib/igt_fb.c | 39 ---
1 file changed
On Fri, Jan 29, 2016 at 04:46:30PM -0200, Paulo Zanoni wrote:
> The interesting thing is that if we don't do this, we still get a
> Y tiled framebuffer, but there won't be a fence around it, which makes
> the GTT mmaps less interesting. Is this a Kernel bug?
I think some tests currently depend on
From: Nick Hoath
Swap the order of context & engine cleanup, so that contexts are cleaned
up first, and *then* engines. This is a more sensible order anyway, but
in particular has become necessary since the 'intel_ring_initialized()
must be simple and inline' patch, which now uses ring->dev as an
1. add call to i915_gem_context_fini() to deallocate the default
context(s) if the call to init_rings() fails, so that we don't
leak the context in that situation.
2. remove useless code in intel_logical_ring_cleanup(), presumably
copypasted from legacy ringbuffer version at creation.
Si
1. Fix intel_cleanup_ring_buffer() to handle the error cleanup
case where the ringbuffer has been allocated but map-and-pin
failed. Unpin it iff it's previously been mapped-and-pinned.
2. Fix the error path in intel_init_ring_buffer(), which already
called intel_destroy_ringbuffer_obj(),
The kunmap() call here didn't match the corresponding kmap().
The kmap()ing was changed with the introduction of the GuC-compatible
layout of context objects and the introduction of "LRC_PPHWSP_PN", in
d167519 drm/i915: Integrate GuC-based command submission
but the corresponding kunmap() was
Various things can go wrong during initialisation and teardown, but they
usually don't, so the error-handling paths go largely untested. This
collection of patches fixes some things I recently noticed. Some might
lead to a kernel OOPS, but mostly they're leaks and other inconsistencies.
Includes
In legacy ringbuffer mode, the HWSP is a separate GEM object with its
own pinning and reference counts. In LRC mode, however, it's not;
instead its part of the default context object. The LRC-mode setup &
teardown code therefore needs to handle this specially; the presence
of the two bugs fixed in
In LRC mode, the HWSP is part of the default context object, and
therefore does not exist independently. Worse, it doesn't contribute
to the refcount on the default context object either.
Currently, the default context is deallocated in intel_lr_context_free(),
but the HWSP kmapping is not torn do
Em Sex, 2016-01-29 às 00:07 +, Rodrigo Vivi escreveu:
> Thanks for all the explanation.
>
> Makes sense now and everything looks fine for me.
>
> Reviewed-by: Rodrigo Vivi
Thanks Rodrigo and Maarten for the reviews.
The CI part was discussed offline with Daniel, so I just pushed the
patche
The recent introduction of a new caller of dev_priv->fbc.deactivate()
is a good example of why we need unexport those functions. Anything
outside intel_fbc.c should only call the functions exported by
intel_fbc.c, so in order to enforce that, kill the function pointers
stored inside dev_priv->fbc a
FBC is already deactivated at this point.
Besides, nothing should be calling these lower-level function
pointers. A few months ago, the only caller of
dev_priv->fbc.deactivate was intel_pipe_set_base_atomic(), which was
the kgdboc function. But the following commit added it to the SKL
function:
Now that we have top-level gen-independent hw_activate and
hw_deactivate functions, set fbc->active directly from them, removing
the duplicated code.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
di
77 matches
Mail list logo
