2014-12-08 23:09:10 +07:00
/*
* Copyright © 2014 Intel Corporation
*
* Permission is hereby granted , free of charge , to any person obtaining a
* copy of this software and associated documentation files ( the " Software " ) ,
* to deal in the Software without restriction , including without limitation
* the rights to use , copy , modify , merge , publish , distribute , sublicense ,
* and / or sell copies of the Software , and to permit persons to whom the
* Software is furnished to do so , subject to the following conditions :
*
* The above copyright notice and this permission notice ( including the next
* paragraph ) shall be included in all copies or substantial portions of the
* Software .
*
* THE SOFTWARE IS PROVIDED " AS IS " , WITHOUT WARRANTY OF ANY KIND , EXPRESS OR
* IMPLIED , INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY ,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT . IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM , DAMAGES OR OTHER
* LIABILITY , WHETHER IN AN ACTION OF CONTRACT , TORT OR OTHERWISE , ARISING
* FROM , OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE .
*/
2014-12-08 21:46:31 +07:00
/**
* DOC : Frame Buffer Compression ( FBC )
*
* FBC tries to save memory bandwidth ( and so power consumption ) by
* compressing the amount of memory used by the display . It is total
* transparent to user space and completely handled in the kernel .
2014-12-08 23:09:10 +07:00
*
* The benefits of FBC are mostly visible with solid backgrounds and
2014-12-08 21:46:31 +07:00
* variation - less patterns . It comes from keeping the memory footprint small
* and having fewer memory pages opened and accessed for refreshing the display .
2014-12-08 23:09:10 +07:00
*
2014-12-08 21:46:31 +07:00
* i915 is responsible to reserve stolen memory for FBC and configure its
* offset on proper registers . The hardware takes care of all
* compress / decompress . However there are many known cases where we have to
* forcibly disable it to allow proper screen updates .
2014-12-08 23:09:10 +07:00
*/
2019-01-18 04:03:34 +07:00
# include <drm/drm_fourcc.h>
2014-12-08 21:46:31 +07:00
# include "i915_drv.h"
2019-12-13 20:34:52 +07:00
# include "i915_trace.h"
2020-02-27 21:44:06 +07:00
# include "i915_vgpu.h"
2019-08-06 18:39:33 +07:00
# include "intel_display_types.h"
2019-04-05 18:00:08 +07:00
# include "intel_fbc.h"
2019-04-05 18:00:09 +07:00
# include "intel_frontbuffer.h"
2014-12-08 21:46:31 +07:00
2015-09-15 01:20:03 +07:00
/*
* In some platforms where the CRTC ' s x : 0 / y : 0 coordinates doesn ' t match the
* frontbuffer ' s x : 0 / y : 0 coordinates we lie to the hardware about the plane ' s
* origin so the x and y offsets can actually fit the registers . As a
* consequence , the fence doesn ' t really start exactly at the display plane
* address we program because it starts at the real start of the buffer , so we
* have to take this into consideration here .
*/
2017-10-18 03:08:11 +07:00
static unsigned int get_crtc_fence_y_offset ( struct intel_fbc * fbc )
2015-09-15 01:20:03 +07:00
{
2017-10-18 03:08:11 +07:00
return fbc - > state_cache . plane . y - fbc - > state_cache . plane . adjusted_y ;
2015-09-15 01:20:03 +07:00
}
drm/i915: alloc/free the FBC CFB during enable/disable
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.
I thought about three different approaches to solve this, and they all
have downsides.
The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.
The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
disable and other calls in the middle of the wait.
Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.
The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow - see
igt's kms_frontbuffer_tracking test, fbc-stridechange subtest. It
could be possible to implement a way to free+alloc the CFB during said
stride change, but it would involve a lot of book-keeping - exactly as
mentioned above - just for on case, so for now I'll keep it simple and
just deactivate FBC. Besides, we may not even need to disable FBC
since we do CFB over-allocation.
Note from Chris: "Starting a fullscreen client that covers a single
monitor in a multi-monitor setup will trigger a change in stride on
one of the CRTCs (the monitors will be flipped independently).". It
shouldn't be a huge problem if we lose FBC on multi-monitor setups
since these setups already have problems reaching deep PC states
anyway.
v2: Rebase after changing the patch order.
v3:
- Remove references to the stride change case being "uncommon" and
paste Chris' example.
- Rebase after a change in a previous patch.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
2015-10-16 00:19:21 +07:00
/*
* For SKL + , the plane source size used by the hardware is based on the value we
* write to the PLANE_SIZE register . For BDW - , the hardware looks at the value
* we wrote to PIPESRC .
*/
2019-11-28 03:12:19 +07:00
static void intel_fbc_get_plane_source_size ( const struct intel_fbc_state_cache * cache ,
drm/i915: alloc/free the FBC CFB during enable/disable
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.
I thought about three different approaches to solve this, and they all
have downsides.
The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.
The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
disable and other calls in the middle of the wait.
Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.
The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow - see
igt's kms_frontbuffer_tracking test, fbc-stridechange subtest. It
could be possible to implement a way to free+alloc the CFB during said
stride change, but it would involve a lot of book-keeping - exactly as
mentioned above - just for on case, so for now I'll keep it simple and
just deactivate FBC. Besides, we may not even need to disable FBC
since we do CFB over-allocation.
Note from Chris: "Starting a fullscreen client that covers a single
monitor in a multi-monitor setup will trigger a change in stride on
one of the CRTCs (the monitors will be flipped independently).". It
shouldn't be a huge problem if we lose FBC on multi-monitor setups
since these setups already have problems reaching deep PC states
anyway.
v2: Rebase after changing the patch order.
v3:
- Remove references to the stride change case being "uncommon" and
paste Chris' example.
- Rebase after a change in a previous patch.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
2015-10-16 00:19:21 +07:00
int * width , int * height )
{
if ( width )
2017-04-01 01:00:56 +07:00
* width = cache - > plane . src_w ;
drm/i915: alloc/free the FBC CFB during enable/disable
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.
I thought about three different approaches to solve this, and they all
have downsides.
The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.
The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
disable and other calls in the middle of the wait.
Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.
The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow - see
igt's kms_frontbuffer_tracking test, fbc-stridechange subtest. It
could be possible to implement a way to free+alloc the CFB during said
stride change, but it would involve a lot of book-keeping - exactly as
mentioned above - just for on case, so for now I'll keep it simple and
just deactivate FBC. Besides, we may not even need to disable FBC
since we do CFB over-allocation.
Note from Chris: "Starting a fullscreen client that covers a single
monitor in a multi-monitor setup will trigger a change in stride on
one of the CRTCs (the monitors will be flipped independently).". It
shouldn't be a huge problem if we lose FBC on multi-monitor setups
since these setups already have problems reaching deep PC states
anyway.
v2: Rebase after changing the patch order.
v3:
- Remove references to the stride change case being "uncommon" and
paste Chris' example.
- Rebase after a change in a previous patch.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
2015-10-16 00:19:21 +07:00
if ( height )
2017-04-01 01:00:56 +07:00
* height = cache - > plane . src_h ;
drm/i915: alloc/free the FBC CFB during enable/disable
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.
I thought about three different approaches to solve this, and they all
have downsides.
The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.
The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
disable and other calls in the middle of the wait.
Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.
The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow - see
igt's kms_frontbuffer_tracking test, fbc-stridechange subtest. It
could be possible to implement a way to free+alloc the CFB during said
stride change, but it would involve a lot of book-keeping - exactly as
mentioned above - just for on case, so for now I'll keep it simple and
just deactivate FBC. Besides, we may not even need to disable FBC
since we do CFB over-allocation.
Note from Chris: "Starting a fullscreen client that covers a single
monitor in a multi-monitor setup will trigger a change in stride on
one of the CRTCs (the monitors will be flipped independently).". It
shouldn't be a huge problem if we lose FBC on multi-monitor setups
since these setups already have problems reaching deep PC states
anyway.
v2: Rebase after changing the patch order.
v3:
- Remove references to the stride change case being "uncommon" and
paste Chris' example.
- Rebase after a change in a previous patch.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
2015-10-16 00:19:21 +07:00
}
2016-01-19 20:35:42 +07:00
static int intel_fbc_calculate_cfb_size ( struct drm_i915_private * dev_priv ,
2019-11-28 03:12:19 +07:00
const struct intel_fbc_state_cache * cache )
drm/i915: alloc/free the FBC CFB during enable/disable
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.
I thought about three different approaches to solve this, and they all
have downsides.
The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.
The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
disable and other calls in the middle of the wait.
Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.
The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow - see
igt's kms_frontbuffer_tracking test, fbc-stridechange subtest. It
could be possible to implement a way to free+alloc the CFB during said
stride change, but it would involve a lot of book-keeping - exactly as
mentioned above - just for on case, so for now I'll keep it simple and
just deactivate FBC. Besides, we may not even need to disable FBC
since we do CFB over-allocation.
Note from Chris: "Starting a fullscreen client that covers a single
monitor in a multi-monitor setup will trigger a change in stride on
one of the CRTCs (the monitors will be flipped independently).". It
shouldn't be a huge problem if we lose FBC on multi-monitor setups
since these setups already have problems reaching deep PC states
anyway.
v2: Rebase after changing the patch order.
v3:
- Remove references to the stride change case being "uncommon" and
paste Chris' example.
- Rebase after a change in a previous patch.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
2015-10-16 00:19:21 +07:00
{
int lines ;
2016-01-19 20:35:42 +07:00
intel_fbc_get_plane_source_size ( cache , NULL , & lines ) ;
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
if ( IS_GEN ( dev_priv , 7 ) )
drm/i915: alloc/free the FBC CFB during enable/disable
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.
I thought about three different approaches to solve this, and they all
have downsides.
The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.
The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
disable and other calls in the middle of the wait.
Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.
The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow - see
igt's kms_frontbuffer_tracking test, fbc-stridechange subtest. It
could be possible to implement a way to free+alloc the CFB during said
stride change, but it would involve a lot of book-keeping - exactly as
mentioned above - just for on case, so for now I'll keep it simple and
just deactivate FBC. Besides, we may not even need to disable FBC
since we do CFB over-allocation.
Note from Chris: "Starting a fullscreen client that covers a single
monitor in a multi-monitor setup will trigger a change in stride on
one of the CRTCs (the monitors will be flipped independently).". It
shouldn't be a huge problem if we lose FBC on multi-monitor setups
since these setups already have problems reaching deep PC states
anyway.
v2: Rebase after changing the patch order.
v3:
- Remove references to the stride change case being "uncommon" and
paste Chris' example.
- Rebase after a change in a previous patch.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
2015-10-16 00:19:21 +07:00
lines = min ( lines , 2048 ) ;
2016-10-21 22:55:45 +07:00
else if ( INTEL_GEN ( dev_priv ) > = 8 )
lines = min ( lines , 2560 ) ;
drm/i915: alloc/free the FBC CFB during enable/disable
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.
I thought about three different approaches to solve this, and they all
have downsides.
The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.
The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
disable and other calls in the middle of the wait.
Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.
The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow - see
igt's kms_frontbuffer_tracking test, fbc-stridechange subtest. It
could be possible to implement a way to free+alloc the CFB during said
stride change, but it would involve a lot of book-keeping - exactly as
mentioned above - just for on case, so for now I'll keep it simple and
just deactivate FBC. Besides, we may not even need to disable FBC
since we do CFB over-allocation.
Note from Chris: "Starting a fullscreen client that covers a single
monitor in a multi-monitor setup will trigger a change in stride on
one of the CRTCs (the monitors will be flipped independently).". It
shouldn't be a huge problem if we lose FBC on multi-monitor setups
since these setups already have problems reaching deep PC states
anyway.
v2: Rebase after changing the patch order.
v3:
- Remove references to the stride change case being "uncommon" and
paste Chris' example.
- Rebase after a change in a previous patch.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
2015-10-16 00:19:21 +07:00
/* Hardware needs the full buffer stride, not just the active area. */
2016-01-19 20:35:42 +07:00
return lines * cache - > fb . stride ;
drm/i915: alloc/free the FBC CFB during enable/disable
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.
I thought about three different approaches to solve this, and they all
have downsides.
The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.
The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
disable and other calls in the middle of the wait.
Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.
The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow - see
igt's kms_frontbuffer_tracking test, fbc-stridechange subtest. It
could be possible to implement a way to free+alloc the CFB during said
stride change, but it would involve a lot of book-keeping - exactly as
mentioned above - just for on case, so for now I'll keep it simple and
just deactivate FBC. Besides, we may not even need to disable FBC
since we do CFB over-allocation.
Note from Chris: "Starting a fullscreen client that covers a single
monitor in a multi-monitor setup will trigger a change in stride on
one of the CRTCs (the monitors will be flipped independently).". It
shouldn't be a huge problem if we lose FBC on multi-monitor setups
since these setups already have problems reaching deep PC states
anyway.
v2: Rebase after changing the patch order.
v3:
- Remove references to the stride change case being "uncommon" and
paste Chris' example.
- Rebase after a change in a previous patch.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
2015-10-16 00:19:21 +07:00
}
2015-10-15 03:45:36 +07:00
static void i8xx_fbc_deactivate ( struct drm_i915_private * dev_priv )
2014-12-08 23:09:10 +07:00
{
u32 fbc_ctl ;
/* Disable compression */
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
fbc_ctl = intel_de_read ( dev_priv , FBC_CONTROL ) ;
2014-12-08 23:09:10 +07:00
if ( ( fbc_ctl & FBC_CTL_EN ) = = 0 )
return ;
fbc_ctl & = ~ FBC_CTL_EN ;
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , FBC_CONTROL , fbc_ctl ) ;
2014-12-08 23:09:10 +07:00
/* Wait for compressing bit to clear */
2019-08-16 08:23:43 +07:00
if ( intel_de_wait_for_clear ( dev_priv , FBC_STATUS ,
FBC_STAT_COMPRESSING , 10 ) ) {
drm/i915/fbc: convert to drm_device based logging macros.
This replaces the uses of the printk based drm logging macros with the
struct drm_device based logging macros in i915/display/intel_fbc.c.
This transformation was done using the following coccinelle semantic
patch that matches based on the existence of a drm_i915_private device
pointer:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
New checkpatch warnings were addressed manually.
v2 by Jani:
- also convert pr_info_once to drm based logging
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Wambui Karuga <wambui.karugax@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/32a92f1d4e4d01131605b17bec831517e39c5902.1583766715.git.jani.nikula@intel.com
2020-03-10 15:52:41 +07:00
drm_dbg_kms ( & dev_priv - > drm , " FBC idle timed out \n " ) ;
2014-12-08 23:09:10 +07:00
return ;
}
}
2015-12-24 03:28:11 +07:00
static void i8xx_fbc_activate ( struct drm_i915_private * dev_priv )
2014-12-08 23:09:10 +07:00
{
2015-12-24 03:28:11 +07:00
struct intel_fbc_reg_params * params = & dev_priv - > fbc . params ;
2014-12-08 23:09:10 +07:00
int cfb_pitch ;
int i ;
u32 fbc_ctl ;
2015-02-05 17:04:27 +07:00
/* Note: fbc.threshold == 1 for i8xx */
2015-12-24 03:28:11 +07:00
cfb_pitch = params - > cfb_size / FBC_LL_SIZE ;
if ( params - > fb . stride < cfb_pitch )
cfb_pitch = params - > fb . stride ;
2014-12-08 23:09:10 +07:00
/* FBC_CTL wants 32B or 64B units */
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
if ( IS_GEN ( dev_priv , 2 ) )
2014-12-08 23:09:10 +07:00
cfb_pitch = ( cfb_pitch / 32 ) - 1 ;
else
cfb_pitch = ( cfb_pitch / 64 ) - 1 ;
/* Clear old tags */
for ( i = 0 ; i < ( FBC_LL_SIZE / 32 ) + 1 ; i + + )
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , FBC_TAG ( i ) , 0 ) ;
2014-12-08 23:09:10 +07:00
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
if ( IS_GEN ( dev_priv , 4 ) ) {
2014-12-08 23:09:10 +07:00
u32 fbc_ctl2 ;
/* Set it up... */
2019-11-28 03:12:16 +07:00
fbc_ctl2 = FBC_CTL_FENCE_DBL | FBC_CTL_IDLE_IMM ;
2017-11-18 02:19:10 +07:00
fbc_ctl2 | = FBC_CTL_PLANE ( params - > crtc . i9xx_plane ) ;
2019-11-28 03:12:16 +07:00
if ( params - > fence_id > = 0 )
fbc_ctl2 | = FBC_CTL_CPU_FENCE ;
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , FBC_CONTROL2 , fbc_ctl2 ) ;
intel_de_write ( dev_priv , FBC_FENCE_OFF ,
params - > crtc . fence_y_offset ) ;
2014-12-08 23:09:10 +07:00
}
/* enable it... */
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
fbc_ctl = intel_de_read ( dev_priv , FBC_CONTROL ) ;
2014-12-08 23:09:10 +07:00
fbc_ctl & = 0x3fff < < FBC_CTL_INTERVAL_SHIFT ;
fbc_ctl | = FBC_CTL_EN | FBC_CTL_PERIODIC ;
2015-07-08 01:26:04 +07:00
if ( IS_I945GM ( dev_priv ) )
2014-12-08 23:09:10 +07:00
fbc_ctl | = FBC_CTL_C3_IDLE ; /* 945 needs special SR handling */
fbc_ctl | = ( cfb_pitch & 0xff ) < < FBC_CTL_STRIDE_SHIFT ;
2019-11-28 03:12:16 +07:00
if ( params - > fence_id > = 0 )
fbc_ctl | = params - > fence_id ;
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , FBC_CONTROL , fbc_ctl ) ;
2014-12-08 23:09:10 +07:00
}
2015-10-15 03:45:36 +07:00
static bool i8xx_fbc_is_active ( struct drm_i915_private * dev_priv )
2014-12-08 23:09:10 +07:00
{
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
return intel_de_read ( dev_priv , FBC_CONTROL ) & FBC_CTL_EN ;
2014-12-08 23:09:10 +07:00
}
2015-12-24 03:28:11 +07:00
static void g4x_fbc_activate ( struct drm_i915_private * dev_priv )
2014-12-08 23:09:10 +07:00
{
2015-12-24 03:28:11 +07:00
struct intel_fbc_reg_params * params = & dev_priv - > fbc . params ;
2014-12-08 23:09:10 +07:00
u32 dpfc_ctl ;
2017-11-18 02:19:10 +07:00
dpfc_ctl = DPFC_CTL_PLANE ( params - > crtc . i9xx_plane ) | DPFC_SR_EN ;
2016-11-19 02:53:04 +07:00
if ( params - > fb . format - > cpp [ 0 ] = = 2 )
2014-12-08 23:09:10 +07:00
dpfc_ctl | = DPFC_CTL_LIMIT_2X ;
else
dpfc_ctl | = DPFC_CTL_LIMIT_1X ;
2019-11-28 03:12:15 +07:00
if ( params - > fence_id > = 0 ) {
dpfc_ctl | = DPFC_CTL_FENCE_EN | params - > fence_id ;
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , DPFC_FENCE_YOFF ,
params - > crtc . fence_y_offset ) ;
2016-08-19 22:54:24 +07:00
} else {
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , DPFC_FENCE_YOFF , 0 ) ;
2016-08-19 22:54:24 +07:00
}
2014-12-08 23:09:10 +07:00
/* enable it... */
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , DPFC_CONTROL , dpfc_ctl | DPFC_CTL_EN ) ;
2014-12-08 23:09:10 +07:00
}
2015-10-15 03:45:36 +07:00
static void g4x_fbc_deactivate ( struct drm_i915_private * dev_priv )
2014-12-08 23:09:10 +07:00
{
u32 dpfc_ctl ;
/* Disable compression */
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
dpfc_ctl = intel_de_read ( dev_priv , DPFC_CONTROL ) ;
2014-12-08 23:09:10 +07:00
if ( dpfc_ctl & DPFC_CTL_EN ) {
dpfc_ctl & = ~ DPFC_CTL_EN ;
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , DPFC_CONTROL , dpfc_ctl ) ;
2014-12-08 23:09:10 +07:00
}
}
2015-10-15 03:45:36 +07:00
static bool g4x_fbc_is_active ( struct drm_i915_private * dev_priv )
2014-12-08 23:09:10 +07:00
{
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
return intel_de_read ( dev_priv , DPFC_CONTROL ) & DPFC_CTL_EN ;
2014-12-08 23:09:10 +07:00
}
2015-11-05 02:10:45 +07:00
/* This function forces a CFB recompression through the nuke operation. */
static void intel_fbc_recompress ( struct drm_i915_private * dev_priv )
2014-12-08 23:09:10 +07:00
{
2019-12-13 20:34:52 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
trace_intel_fbc_nuke ( fbc - > crtc ) ;
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , MSG_FBC_REND_STATE , FBC_REND_NUKE ) ;
intel_de_posting_read ( dev_priv , MSG_FBC_REND_STATE ) ;
2014-12-08 23:09:10 +07:00
}
2015-12-24 03:28:11 +07:00
static void ilk_fbc_activate ( struct drm_i915_private * dev_priv )
2014-12-08 23:09:10 +07:00
{
2015-12-24 03:28:11 +07:00
struct intel_fbc_reg_params * params = & dev_priv - > fbc . params ;
2014-12-08 23:09:10 +07:00
u32 dpfc_ctl ;
2015-06-30 20:53:05 +07:00
int threshold = dev_priv - > fbc . threshold ;
2014-12-08 23:09:10 +07:00
2017-11-18 02:19:10 +07:00
dpfc_ctl = DPFC_CTL_PLANE ( params - > crtc . i9xx_plane ) ;
2016-11-19 02:53:04 +07:00
if ( params - > fb . format - > cpp [ 0 ] = = 2 )
2015-06-30 20:53:05 +07:00
threshold + + ;
2014-12-08 23:09:10 +07:00
2015-06-30 20:53:05 +07:00
switch ( threshold ) {
2014-12-08 23:09:10 +07:00
case 4 :
case 3 :
dpfc_ctl | = DPFC_CTL_LIMIT_4X ;
break ;
case 2 :
dpfc_ctl | = DPFC_CTL_LIMIT_2X ;
break ;
case 1 :
dpfc_ctl | = DPFC_CTL_LIMIT_1X ;
break ;
}
2016-08-19 22:54:24 +07:00
2019-11-28 03:12:15 +07:00
if ( params - > fence_id > = 0 ) {
2016-08-19 22:54:24 +07:00
dpfc_ctl | = DPFC_CTL_FENCE_EN ;
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
if ( IS_GEN ( dev_priv , 5 ) )
2019-11-28 03:12:15 +07:00
dpfc_ctl | = params - > fence_id ;
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
if ( IS_GEN ( dev_priv , 6 ) ) {
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , SNB_DPFC_CTL_SA ,
SNB_CPU_FENCE_ENABLE | params - > fence_id ) ;
intel_de_write ( dev_priv , DPFC_CPU_FENCE_OFFSET ,
params - > crtc . fence_y_offset ) ;
2016-08-19 22:54:24 +07:00
}
} else {
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
if ( IS_GEN ( dev_priv , 6 ) ) {
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , SNB_DPFC_CTL_SA , 0 ) ;
intel_de_write ( dev_priv , DPFC_CPU_FENCE_OFFSET , 0 ) ;
2016-08-19 22:54:24 +07:00
}
}
2014-12-08 23:09:10 +07:00
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , ILK_DPFC_FENCE_YOFF ,
params - > crtc . fence_y_offset ) ;
2014-12-08 23:09:10 +07:00
/* enable it... */
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , ILK_DPFC_CONTROL , dpfc_ctl | DPFC_CTL_EN ) ;
2014-12-08 23:09:10 +07:00
2015-11-05 02:10:45 +07:00
intel_fbc_recompress ( dev_priv ) ;
2014-12-08 23:09:10 +07:00
}
2015-10-15 03:45:36 +07:00
static void ilk_fbc_deactivate ( struct drm_i915_private * dev_priv )
2014-12-08 23:09:10 +07:00
{
u32 dpfc_ctl ;
/* Disable compression */
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
dpfc_ctl = intel_de_read ( dev_priv , ILK_DPFC_CONTROL ) ;
2014-12-08 23:09:10 +07:00
if ( dpfc_ctl & DPFC_CTL_EN ) {
dpfc_ctl & = ~ DPFC_CTL_EN ;
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , ILK_DPFC_CONTROL , dpfc_ctl ) ;
2014-12-08 23:09:10 +07:00
}
}
2015-10-15 03:45:36 +07:00
static bool ilk_fbc_is_active ( struct drm_i915_private * dev_priv )
2014-12-08 23:09:10 +07:00
{
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
return intel_de_read ( dev_priv , ILK_DPFC_CONTROL ) & DPFC_CTL_EN ;
2014-12-08 23:09:10 +07:00
}
2015-12-24 03:28:11 +07:00
static void gen7_fbc_activate ( struct drm_i915_private * dev_priv )
2014-12-08 23:09:10 +07:00
{
2015-12-24 03:28:11 +07:00
struct intel_fbc_reg_params * params = & dev_priv - > fbc . params ;
2014-12-08 23:09:10 +07:00
u32 dpfc_ctl ;
2015-06-30 20:53:05 +07:00
int threshold = dev_priv - > fbc . threshold ;
2014-12-08 23:09:10 +07:00
2017-08-11 01:30:33 +07:00
/* Display WA #0529: skl, kbl, bxt. */
2019-11-28 03:12:17 +07:00
if ( IS_GEN9_BC ( dev_priv ) | | IS_BROXTON ( dev_priv ) ) {
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
u32 val = intel_de_read ( dev_priv , CHICKEN_MISC_4 ) ;
2017-08-11 01:30:33 +07:00
val & = ~ ( FBC_STRIDE_OVERRIDE | FBC_STRIDE_MASK ) ;
2019-11-28 03:12:13 +07:00
if ( params - > gen9_wa_cfb_stride )
2017-08-11 01:30:33 +07:00
val | = FBC_STRIDE_OVERRIDE | params - > gen9_wa_cfb_stride ;
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , CHICKEN_MISC_4 , val ) ;
2017-08-11 01:30:33 +07:00
}
2015-06-13 00:36:21 +07:00
dpfc_ctl = 0 ;
2015-07-08 01:26:04 +07:00
if ( IS_IVYBRIDGE ( dev_priv ) )
2017-11-18 02:19:10 +07:00
dpfc_ctl | = IVB_DPFC_CTL_PLANE ( params - > crtc . i9xx_plane ) ;
2015-06-13 00:36:21 +07:00
2016-11-19 02:53:04 +07:00
if ( params - > fb . format - > cpp [ 0 ] = = 2 )
2015-06-30 20:53:05 +07:00
threshold + + ;
2014-12-08 23:09:10 +07:00
2015-06-30 20:53:05 +07:00
switch ( threshold ) {
2014-12-08 23:09:10 +07:00
case 4 :
case 3 :
dpfc_ctl | = DPFC_CTL_LIMIT_4X ;
break ;
case 2 :
dpfc_ctl | = DPFC_CTL_LIMIT_2X ;
break ;
case 1 :
dpfc_ctl | = DPFC_CTL_LIMIT_1X ;
break ;
}
2019-11-28 03:12:15 +07:00
if ( params - > fence_id > = 0 ) {
2016-08-19 22:54:24 +07:00
dpfc_ctl | = IVB_DPFC_CTL_FENCE_EN ;
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , SNB_DPFC_CTL_SA ,
SNB_CPU_FENCE_ENABLE | params - > fence_id ) ;
intel_de_write ( dev_priv , DPFC_CPU_FENCE_OFFSET ,
params - > crtc . fence_y_offset ) ;
2020-03-07 01:58:33 +07:00
} else if ( dev_priv - > ggtt . num_fences ) {
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , SNB_DPFC_CTL_SA , 0 ) ;
intel_de_write ( dev_priv , DPFC_CPU_FENCE_OFFSET , 0 ) ;
2016-08-19 22:54:24 +07:00
}
2014-12-08 23:09:10 +07:00
if ( dev_priv - > fbc . false_color )
dpfc_ctl | = FBC_CTL_FALSE_COLOR ;
2015-07-08 01:26:04 +07:00
if ( IS_IVYBRIDGE ( dev_priv ) ) {
2014-12-08 23:09:10 +07:00
/* WaFbcAsynchFlipDisableFbcQueue:ivb */
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , ILK_DISPLAY_CHICKEN1 ,
intel_de_read ( dev_priv , ILK_DISPLAY_CHICKEN1 ) | ILK_FBCQ_DIS ) ;
2015-09-15 01:20:01 +07:00
} else if ( IS_HASWELL ( dev_priv ) | | IS_BROADWELL ( dev_priv ) ) {
2014-12-08 23:09:10 +07:00
/* WaFbcAsynchFlipDisableFbcQueue:hsw,bdw */
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , CHICKEN_PIPESL_1 ( params - > crtc . pipe ) ,
intel_de_read ( dev_priv , CHICKEN_PIPESL_1 ( params - > crtc . pipe ) ) | HSW_FBCQ_DIS ) ;
2014-12-08 23:09:10 +07:00
}
2019-09-05 06:02:40 +07:00
if ( INTEL_GEN ( dev_priv ) > = 11 )
/* Wa_1409120013:icl,ehl,tgl */
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , ILK_DPFC_CHICKEN ,
ILK_DPFC_CHICKEN_COMP_DUMMY_PIXEL ) ;
2019-06-13 01:36:31 +07:00
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , ILK_DPFC_CONTROL , dpfc_ctl | DPFC_CTL_EN ) ;
2015-09-15 01:20:00 +07:00
2015-11-05 02:10:45 +07:00
intel_fbc_recompress ( dev_priv ) ;
2014-12-08 23:09:10 +07:00
}
2016-01-30 03:57:39 +07:00
static bool intel_fbc_hw_is_active ( struct drm_i915_private * dev_priv )
{
2016-11-11 23:57:41 +07:00
if ( INTEL_GEN ( dev_priv ) > = 5 )
2016-01-30 03:57:39 +07:00
return ilk_fbc_is_active ( dev_priv ) ;
else if ( IS_GM45 ( dev_priv ) )
return g4x_fbc_is_active ( dev_priv ) ;
else
return i8xx_fbc_is_active ( dev_priv ) ;
}
static void intel_fbc_hw_activate ( struct drm_i915_private * dev_priv )
{
2016-01-30 03:57:40 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
2019-12-13 20:34:52 +07:00
trace_intel_fbc_activate ( fbc - > crtc ) ;
2016-01-30 03:57:40 +07:00
fbc - > active = true ;
2019-11-28 22:03:38 +07:00
fbc - > activated = true ;
2016-01-30 03:57:40 +07:00
2016-11-11 23:57:41 +07:00
if ( INTEL_GEN ( dev_priv ) > = 7 )
2016-01-30 03:57:39 +07:00
gen7_fbc_activate ( dev_priv ) ;
2016-11-11 23:57:41 +07:00
else if ( INTEL_GEN ( dev_priv ) > = 5 )
2016-01-30 03:57:39 +07:00
ilk_fbc_activate ( dev_priv ) ;
else if ( IS_GM45 ( dev_priv ) )
g4x_fbc_activate ( dev_priv ) ;
else
i8xx_fbc_activate ( dev_priv ) ;
}
static void intel_fbc_hw_deactivate ( struct drm_i915_private * dev_priv )
{
2016-01-30 03:57:40 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
2019-12-13 20:34:52 +07:00
trace_intel_fbc_deactivate ( fbc - > crtc ) ;
2016-01-30 03:57:40 +07:00
fbc - > active = false ;
2016-11-11 23:57:41 +07:00
if ( INTEL_GEN ( dev_priv ) > = 5 )
2016-01-30 03:57:39 +07:00
ilk_fbc_deactivate ( dev_priv ) ;
else if ( IS_GM45 ( dev_priv ) )
g4x_fbc_deactivate ( dev_priv ) ;
else
i8xx_fbc_deactivate ( dev_priv ) ;
}
2014-12-08 21:46:31 +07:00
/**
2015-10-15 03:45:36 +07:00
* intel_fbc_is_active - Is FBC active ?
2015-07-08 01:26:04 +07:00
* @ dev_priv : i915 device instance
2014-12-08 21:46:31 +07:00
*
* This function is used to verify the current state of FBC .
2016-06-02 04:40:36 +07:00
*
2014-12-08 21:46:31 +07:00
* FIXME : This should be tracked in the plane config eventually
2016-06-02 04:40:36 +07:00
* instead of queried at runtime for most callers .
2014-12-08 21:46:31 +07:00
*/
2015-10-15 03:45:36 +07:00
bool intel_fbc_is_active ( struct drm_i915_private * dev_priv )
2014-12-08 23:09:10 +07:00
{
2015-10-15 03:45:36 +07:00
return dev_priv - > fbc . active ;
2014-12-08 23:09:10 +07:00
}
2018-01-26 05:41:22 +07:00
static void intel_fbc_deactivate ( struct drm_i915_private * dev_priv ,
const char * reason )
2015-07-03 05:25:10 +07:00
{
2016-01-12 02:44:36 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
drm/i915/display/fbc: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128181603.27767-11-pankaj.laxminarayan.bharadiya@intel.com
2020-01-29 01:15:52 +07:00
drm_WARN_ON ( & dev_priv - > drm , ! mutex_is_locked ( & fbc - > lock ) ) ;
2015-07-03 05:25:10 +07:00
2016-01-12 02:44:36 +07:00
if ( fbc - > active )
2016-01-30 03:57:39 +07:00
intel_fbc_hw_deactivate ( dev_priv ) ;
2018-01-26 05:41:22 +07:00
fbc - > no_fbc_reason = reason ;
2015-10-14 05:13:25 +07:00
}
2015-07-08 01:26:04 +07:00
static int find_compression_threshold ( struct drm_i915_private * dev_priv ,
2015-07-03 05:25:08 +07:00
struct drm_mm_node * node ,
2019-11-28 03:12:13 +07:00
unsigned int size ,
unsigned int fb_cpp )
2015-07-03 05:25:08 +07:00
{
int compression_threshold = 1 ;
int ret ;
2015-09-15 01:19:57 +07:00
u64 end ;
/* The FBC hardware for BDW/SKL doesn't have access to the stolen
* reserved range size , so it always assumes the maximum ( 8 mb ) is used .
* If we enable FBC using a CFB on that memory range we ' ll get FIFO
* underruns , even if that range is not reserved by the BIOS . */
2017-01-24 01:32:37 +07:00
if ( IS_BROADWELL ( dev_priv ) | | IS_GEN9_BC ( dev_priv ) )
2017-12-11 22:18:18 +07:00
end = resource_size ( & dev_priv - > dsm ) - 8 * 1024 * 1024 ;
2015-09-15 01:19:57 +07:00
else
2016-12-15 20:23:55 +07:00
end = U64_MAX ;
2015-07-03 05:25:08 +07:00
/* HACK: This code depends on what we will do in *_enable_fbc. If that
* code changes , this code needs to change as well .
*
* The enable_fbc code will attempt to use one of our 2 compression
* thresholds , therefore , in that case , we only have 1 resort .
*/
/* Try to over-allocate to reduce reallocations and fragmentation. */
2015-09-15 01:19:57 +07:00
ret = i915_gem_stolen_insert_node_in_range ( dev_priv , node , size < < = 1 ,
4096 , 0 , end ) ;
2015-07-03 05:25:08 +07:00
if ( ret = = 0 )
return compression_threshold ;
again :
/* HW's ability to limit the CFB is 1:4 */
if ( compression_threshold > 4 | |
( fb_cpp = = 2 & & compression_threshold = = 2 ) )
return 0 ;
2015-09-15 01:19:57 +07:00
ret = i915_gem_stolen_insert_node_in_range ( dev_priv , node , size > > = 1 ,
4096 , 0 , end ) ;
2016-11-11 23:57:41 +07:00
if ( ret & & INTEL_GEN ( dev_priv ) < = 4 ) {
2015-07-03 05:25:08 +07:00
return 0 ;
} else if ( ret ) {
compression_threshold < < = 1 ;
goto again ;
} else {
return compression_threshold ;
}
}
2019-11-28 03:12:13 +07:00
static int intel_fbc_alloc_cfb ( struct drm_i915_private * dev_priv ,
unsigned int size , unsigned int fb_cpp )
2015-07-03 05:25:08 +07:00
{
2016-01-12 02:44:36 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
2015-07-03 05:25:08 +07:00
struct drm_mm_node * uninitialized_var ( compressed_llb ) ;
2019-11-28 03:12:13 +07:00
int ret ;
drm/i915: alloc/free the FBC CFB during enable/disable
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.
I thought about three different approaches to solve this, and they all
have downsides.
The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.
The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
disable and other calls in the middle of the wait.
Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.
The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow - see
igt's kms_frontbuffer_tracking test, fbc-stridechange subtest. It
could be possible to implement a way to free+alloc the CFB during said
stride change, but it would involve a lot of book-keeping - exactly as
mentioned above - just for on case, so for now I'll keep it simple and
just deactivate FBC. Besides, we may not even need to disable FBC
since we do CFB over-allocation.
Note from Chris: "Starting a fullscreen client that covers a single
monitor in a multi-monitor setup will trigger a change in stride on
one of the CRTCs (the monitors will be flipped independently).". It
shouldn't be a huge problem if we lose FBC on multi-monitor setups
since these setups already have problems reaching deep PC states
anyway.
v2: Rebase after changing the patch order.
v3:
- Remove references to the stride change case being "uncommon" and
paste Chris' example.
- Rebase after a change in a previous patch.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
2015-10-16 00:19:21 +07:00
drm/i915/display/fbc: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128181603.27767-11-pankaj.laxminarayan.bharadiya@intel.com
2020-01-29 01:15:52 +07:00
drm_WARN_ON ( & dev_priv - > drm ,
drm_mm_node_allocated ( & fbc - > compressed_fb ) ) ;
drm/i915: alloc/free the FBC CFB during enable/disable
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.
I thought about three different approaches to solve this, and they all
have downsides.
The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.
The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
disable and other calls in the middle of the wait.
Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.
The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow - see
igt's kms_frontbuffer_tracking test, fbc-stridechange subtest. It
could be possible to implement a way to free+alloc the CFB during said
stride change, but it would involve a lot of book-keeping - exactly as
mentioned above - just for on case, so for now I'll keep it simple and
just deactivate FBC. Besides, we may not even need to disable FBC
since we do CFB over-allocation.
Note from Chris: "Starting a fullscreen client that covers a single
monitor in a multi-monitor setup will trigger a change in stride on
one of the CRTCs (the monitors will be flipped independently).". It
shouldn't be a huge problem if we lose FBC on multi-monitor setups
since these setups already have problems reaching deep PC states
anyway.
v2: Rebase after changing the patch order.
v3:
- Remove references to the stride change case being "uncommon" and
paste Chris' example.
- Rebase after a change in a previous patch.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
2015-10-16 00:19:21 +07:00
2016-01-12 02:44:36 +07:00
ret = find_compression_threshold ( dev_priv , & fbc - > compressed_fb ,
2015-07-03 05:25:08 +07:00
size , fb_cpp ) ;
if ( ! ret )
goto err_llb ;
else if ( ret > 1 ) {
2018-07-07 02:04:24 +07:00
drm_info_once ( & dev_priv - > drm ,
" Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS. \n " ) ;
2015-07-03 05:25:08 +07:00
}
2016-01-12 02:44:36 +07:00
fbc - > threshold = ret ;
2015-07-03 05:25:08 +07:00
2016-11-11 23:57:41 +07:00
if ( INTEL_GEN ( dev_priv ) > = 5 )
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , ILK_DPFC_CB_BASE ,
fbc - > compressed_fb . start ) ;
2015-07-08 01:26:04 +07:00
else if ( IS_GM45 ( dev_priv ) ) {
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , DPFC_CB_BASE ,
fbc - > compressed_fb . start ) ;
2015-07-03 05:25:08 +07:00
} else {
compressed_llb = kzalloc ( sizeof ( * compressed_llb ) , GFP_KERNEL ) ;
if ( ! compressed_llb )
goto err_fb ;
ret = i915_gem_stolen_insert_node ( dev_priv , compressed_llb ,
4096 , 4096 ) ;
if ( ret )
goto err_fb ;
2016-01-12 02:44:36 +07:00
fbc - > compressed_llb = compressed_llb ;
2015-07-03 05:25:08 +07:00
2020-03-06 16:47:35 +07:00
GEM_BUG_ON ( range_overflows_end_t ( u64 , dev_priv - > dsm . start ,
fbc - > compressed_fb . start ,
U32_MAX ) ) ;
GEM_BUG_ON ( range_overflows_end_t ( u64 , dev_priv - > dsm . start ,
fbc - > compressed_llb - > start ,
U32_MAX ) ) ;
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , FBC_CFB_BASE ,
dev_priv - > dsm . start + fbc - > compressed_fb . start ) ;
intel_de_write ( dev_priv , FBC_LL_BASE ,
dev_priv - > dsm . start + compressed_llb - > start ) ;
2015-07-03 05:25:08 +07:00
}
drm/i915/fbc: convert to drm_device based logging macros.
This replaces the uses of the printk based drm logging macros with the
struct drm_device based logging macros in i915/display/intel_fbc.c.
This transformation was done using the following coccinelle semantic
patch that matches based on the existence of a drm_i915_private device
pointer:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
New checkpatch warnings were addressed manually.
v2 by Jani:
- also convert pr_info_once to drm based logging
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Wambui Karuga <wambui.karugax@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/32a92f1d4e4d01131605b17bec831517e39c5902.1583766715.git.jani.nikula@intel.com
2020-03-10 15:52:41 +07:00
drm_dbg_kms ( & dev_priv - > drm ,
" reserved %llu bytes of contiguous stolen space for FBC, threshold: %d \n " ,
fbc - > compressed_fb . size , fbc - > threshold ) ;
2015-07-03 05:25:08 +07:00
return 0 ;
err_fb :
kfree ( compressed_llb ) ;
2016-01-12 02:44:36 +07:00
i915_gem_stolen_remove_node ( dev_priv , & fbc - > compressed_fb ) ;
2015-07-03 05:25:08 +07:00
err_llb :
2017-02-23 19:20:37 +07:00
if ( drm_mm_initialized ( & dev_priv - > mm . stolen ) )
drm/i915/fbc: convert to drm_device based logging macros.
This replaces the uses of the printk based drm logging macros with the
struct drm_device based logging macros in i915/display/intel_fbc.c.
This transformation was done using the following coccinelle semantic
patch that matches based on the existence of a drm_i915_private device
pointer:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
New checkpatch warnings were addressed manually.
v2 by Jani:
- also convert pr_info_once to drm based logging
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Wambui Karuga <wambui.karugax@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/32a92f1d4e4d01131605b17bec831517e39c5902.1583766715.git.jani.nikula@intel.com
2020-03-10 15:52:41 +07:00
drm_info_once ( & dev_priv - > drm , " not enough stolen space for compressed buffer (need %d more bytes), disabling. Hint: you may be able to increase stolen memory size in the BIOS to avoid this. \n " , size ) ;
2015-07-03 05:25:08 +07:00
return - ENOSPC ;
}
2015-07-08 01:26:04 +07:00
static void __intel_fbc_cleanup_cfb ( struct drm_i915_private * dev_priv )
2015-07-03 05:25:08 +07:00
{
2016-01-12 02:44:36 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
2020-05-04 01:00:34 +07:00
if ( WARN_ON ( intel_fbc_hw_is_active ( dev_priv ) ) )
return ;
2020-01-30 20:51:36 +07:00
if ( ! drm_mm_node_allocated ( & fbc - > compressed_fb ) )
return ;
2016-01-12 02:44:36 +07:00
if ( fbc - > compressed_llb ) {
i915_gem_stolen_remove_node ( dev_priv , fbc - > compressed_llb ) ;
kfree ( fbc - > compressed_llb ) ;
2015-07-03 05:25:08 +07:00
}
2020-01-30 20:51:36 +07:00
i915_gem_stolen_remove_node ( dev_priv , & fbc - > compressed_fb ) ;
2015-07-03 05:25:08 +07:00
}
2015-07-08 01:26:04 +07:00
void intel_fbc_cleanup_cfb ( struct drm_i915_private * dev_priv )
2015-07-03 05:25:10 +07:00
{
2016-01-12 02:44:36 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
2019-12-13 20:34:51 +07:00
if ( ! HAS_FBC ( dev_priv ) )
2015-07-04 01:40:54 +07:00
return ;
2016-01-12 02:44:36 +07:00
mutex_lock ( & fbc - > lock ) ;
2015-07-08 01:26:04 +07:00
__intel_fbc_cleanup_cfb ( dev_priv ) ;
2016-01-12 02:44:36 +07:00
mutex_unlock ( & fbc - > lock ) ;
2015-07-03 05:25:10 +07:00
}
2015-09-15 01:19:56 +07:00
static bool stride_is_valid ( struct drm_i915_private * dev_priv ,
2020-04-29 17:10:23 +07:00
u64 modifier , unsigned int stride )
2015-09-15 01:19:56 +07:00
{
2018-01-16 22:53:31 +07:00
/* This should have been caught earlier. */
drm/i915/display/fbc: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128181603.27767-11-pankaj.laxminarayan.bharadiya@intel.com
2020-01-29 01:15:52 +07:00
if ( drm_WARN_ON_ONCE ( & dev_priv - > drm , ( stride & ( 64 - 1 ) ) ! = 0 ) )
2018-01-16 22:53:31 +07:00
return false ;
2015-09-15 01:19:56 +07:00
/* Below are the additional FBC restrictions. */
2018-01-16 22:53:31 +07:00
if ( stride < 512 )
return false ;
2015-09-15 01:19:56 +07:00
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
if ( IS_GEN ( dev_priv , 2 ) | | IS_GEN ( dev_priv , 3 ) )
2015-09-15 01:19:56 +07:00
return stride = = 4096 | | stride = = 8192 ;
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
if ( IS_GEN ( dev_priv , 4 ) & & ! IS_G4X ( dev_priv ) & & stride < 2048 )
2015-09-15 01:19:56 +07:00
return false ;
2020-04-29 17:10:23 +07:00
/* Display WA #1105: skl,bxt,kbl,cfl,glk */
if ( IS_GEN ( dev_priv , 9 ) & &
modifier = = DRM_FORMAT_MOD_LINEAR & & stride & 511 )
return false ;
2015-09-15 01:19:56 +07:00
if ( stride > 16384 )
return false ;
return true ;
}
2016-01-19 20:35:42 +07:00
static bool pixel_format_is_valid ( struct drm_i915_private * dev_priv ,
2019-01-16 16:15:19 +07:00
u32 pixel_format )
2015-09-22 05:48:06 +07:00
{
2016-01-19 20:35:42 +07:00
switch ( pixel_format ) {
2015-09-22 05:48:06 +07:00
case DRM_FORMAT_XRGB8888 :
case DRM_FORMAT_XBGR8888 :
return true ;
case DRM_FORMAT_XRGB1555 :
case DRM_FORMAT_RGB565 :
/* 16bpp not supported on gen2 */
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
if ( IS_GEN ( dev_priv , 2 ) )
2015-09-22 05:48:06 +07:00
return false ;
/* WaFbcOnly1to1Ratio:ctg */
if ( IS_G4X ( dev_priv ) )
return false ;
return true ;
default :
return false ;
}
}
2020-03-20 04:15:35 +07:00
static bool rotation_is_valid ( struct drm_i915_private * dev_priv ,
u32 pixel_format , unsigned int rotation )
{
if ( INTEL_GEN ( dev_priv ) > = 9 & & pixel_format = = DRM_FORMAT_RGB565 & &
drm_rotation_90_or_270 ( rotation ) )
return false ;
else if ( INTEL_GEN ( dev_priv ) < = 4 & & ! IS_G4X ( dev_priv ) & &
rotation ! = DRM_MODE_ROTATE_0 )
return false ;
return true ;
}
2015-10-02 05:57:12 +07:00
/*
* For some reason , the hardware tracking starts looking at whatever we
* programmed as the display plane base address register . It does not look at
* the X and Y offset registers . That ' s why we look at the crtc - > adjusted { x , y }
* variables instead of just looking at the pipe / plane size .
*/
static bool intel_fbc_hw_tracking_covers_screen ( struct intel_crtc * crtc )
2015-09-23 22:52:24 +07:00
{
2016-07-04 17:34:36 +07:00
struct drm_i915_private * dev_priv = to_i915 ( crtc - > base . dev ) ;
2016-01-19 20:35:42 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
2015-10-02 05:57:12 +07:00
unsigned int effective_w , effective_h , max_w , max_h ;
2015-09-23 22:52:24 +07:00
2018-12-05 07:48:23 +07:00
if ( INTEL_GEN ( dev_priv ) > = 10 | | IS_GEMINILAKE ( dev_priv ) ) {
max_w = 5120 ;
max_h = 4096 ;
} else if ( INTEL_GEN ( dev_priv ) > = 8 | | IS_HASWELL ( dev_priv ) ) {
2015-09-23 22:52:24 +07:00
max_w = 4096 ;
max_h = 4096 ;
2016-11-11 23:57:41 +07:00
} else if ( IS_G4X ( dev_priv ) | | INTEL_GEN ( dev_priv ) > = 5 ) {
2015-09-23 22:52:24 +07:00
max_w = 4096 ;
max_h = 2048 ;
} else {
max_w = 2048 ;
max_h = 1536 ;
}
2016-01-19 20:35:42 +07:00
intel_fbc_get_plane_source_size ( & fbc - > state_cache , & effective_w ,
& effective_h ) ;
2017-10-18 03:08:07 +07:00
effective_w + = fbc - > state_cache . plane . adjusted_x ;
effective_h + = fbc - > state_cache . plane . adjusted_y ;
2015-10-02 05:57:12 +07:00
return effective_w < = max_w & & effective_h < = max_h ;
2015-09-23 22:52:24 +07:00
}
2020-03-20 04:15:35 +07:00
static bool tiling_is_valid ( struct drm_i915_private * dev_priv ,
uint64_t modifier )
{
switch ( modifier ) {
case DRM_FORMAT_MOD_LINEAR :
if ( INTEL_GEN ( dev_priv ) > = 9 )
return true ;
return false ;
case I915_FORMAT_MOD_X_TILED :
case I915_FORMAT_MOD_Y_TILED :
return true ;
default :
return false ;
}
}
2016-06-14 19:24:20 +07:00
static void intel_fbc_update_state_cache ( struct intel_crtc * crtc ,
2019-11-28 02:05:53 +07:00
const struct intel_crtc_state * crtc_state ,
const struct intel_plane_state * plane_state )
2014-12-08 23:09:10 +07:00
{
2016-07-04 17:34:36 +07:00
struct drm_i915_private * dev_priv = to_i915 ( crtc - > base . dev ) ;
2016-01-12 02:44:36 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
2016-01-19 20:35:42 +07:00
struct intel_fbc_state_cache * cache = & fbc - > state_cache ;
2019-10-31 18:26:07 +07:00
struct drm_framebuffer * fb = plane_state - > hw . fb ;
2017-01-16 22:21:27 +07:00
2019-11-28 03:12:14 +07:00
cache - > plane . visible = plane_state - > uapi . visible ;
if ( ! cache - > plane . visible )
return ;
2014-12-08 23:09:10 +07:00
2019-10-31 18:26:02 +07:00
cache - > crtc . mode_flags = crtc_state - > hw . adjusted_mode . flags ;
2016-01-19 20:35:42 +07:00
if ( IS_HASWELL ( dev_priv ) | | IS_BROADWELL ( dev_priv ) )
2017-01-27 02:50:31 +07:00
cache - > crtc . hsw_bdw_pixel_rate = crtc_state - > pixel_rate ;
2016-01-19 20:35:42 +07:00
2019-10-31 18:26:07 +07:00
cache - > plane . rotation = plane_state - > hw . rotation ;
2017-04-01 01:00:56 +07:00
/*
* Src coordinates are already rotated by 270 degrees for
* the 90 / 270 degree plane rotation cases ( to match the
* GTT mapping ) , hence no need to account for rotation here .
*/
2019-10-31 18:26:08 +07:00
cache - > plane . src_w = drm_rect_width ( & plane_state - > uapi . src ) > > 16 ;
cache - > plane . src_h = drm_rect_height ( & plane_state - > uapi . src ) > > 16 ;
2018-09-07 22:24:04 +07:00
cache - > plane . adjusted_x = plane_state - > color_plane [ 0 ] . x ;
cache - > plane . adjusted_y = plane_state - > color_plane [ 0 ] . y ;
2019-10-31 18:26:08 +07:00
cache - > plane . y = plane_state - > uapi . src . y1 > > 16 ;
2016-01-19 20:35:42 +07:00
2019-10-31 18:26:07 +07:00
cache - > plane . pixel_blend_mode = plane_state - > hw . pixel_blend_mode ;
2018-08-15 17:34:05 +07:00
2016-11-19 02:53:04 +07:00
cache - > fb . format = fb - > format ;
2016-01-19 20:35:42 +07:00
cache - > fb . stride = fb - > pitches [ 0 ] ;
2020-03-20 04:15:35 +07:00
cache - > fb . modifier = fb - > modifier ;
2017-01-16 22:21:27 +07:00
drm/i915/display/fbc: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128181603.27767-11-pankaj.laxminarayan.bharadiya@intel.com
2020-01-29 01:15:52 +07:00
drm_WARN_ON ( & dev_priv - > drm , plane_state - > flags & PLANE_HAS_FENCE & &
! plane_state - > vma - > fence ) ;
2019-11-28 03:12:15 +07:00
if ( plane_state - > flags & PLANE_HAS_FENCE & &
plane_state - > vma - > fence )
cache - > fence_id = plane_state - > vma - > fence - > id ;
else
cache - > fence_id = - 1 ;
2016-01-19 20:35:42 +07:00
}
2019-11-28 03:12:22 +07:00
static bool intel_fbc_cfb_size_changed ( struct drm_i915_private * dev_priv )
{
struct intel_fbc * fbc = & dev_priv - > fbc ;
return intel_fbc_calculate_cfb_size ( dev_priv , & fbc - > state_cache ) >
fbc - > compressed_fb . size * fbc - > threshold ;
}
drm/i915/display: Deactive FBC in fastsets when disabled by parameter
Most of the kms_frontbuffer_tracking tests disables the feature being
tested, draw, get the CRC then enable the feature, draw again, get the
CRC and check if it matches.
Some times it is able to do that with a fastset, so
intel_pre_plane_update() is executed but intel_fbc_can_flip_nuke() was
not checking if FBC is now enabled in this CRTC leaving FBC active and
causing the warning bellow in __intel_fbc_disable()
[IGT] kms_frontbuffer_tracking: starting subtest fbc-1p-pri-indfb-multidraw
Setting dangerous option enable_fbc - tainting kernel
i915 0000:00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR debug to f
i915 0000:00:02.0: [drm:intel_psr_debug_set [i915]] Invalid debug mask f
i915 0000:00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR debug to 1
i915 0000:00:02.0: [drm:intel_atomic_check [i915]] [CONNECTOR:215:eDP-1] Limiting display bpp to 24 instead of EDID bpp 24, requested bpp 36, max platform bpp 36
[drm:intel_dp_compute_config [i915]] DP link computation with max lane count 2 max rate 270000 max bpp 24 pixel clock 138120KHz
[drm:intel_dp_compute_config [i915]] Force DSC en = 0
[drm:intel_dp_compute_config [i915]] DP lane count 2 clock 270000 bpp 24
[drm:intel_dp_compute_config [i915]] DP link rate required 414360 available 540000
i915 0000:00:02.0: [drm:intel_atomic_check [i915]] hw max bpp: 24, pipe bpp: 24, dithering: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] [CRTC:91:pipe A] enable: yes [fastset]
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] active: yes, output_types: EDP (0x100), output format: RGB
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] cpu_transcoder: EDP, pipe bpp: 24, dithering: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] dp m_n: lanes: 2; gmch_m: 6436858, gmch_n: 8388608, link_m: 268202, link_n: 524288, tu: 64
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] audio: 0, infoframes: 0, infoframes enabled: 0x0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] requested mode:
[drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] adjusted mode:
[drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa
[drm:intel_dump_pipe_config [i915]] crtc timings: 138120 1920 1968 2018 2052 1080 1084 1086 1122, type: 0x48 flags: 0xa
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] port clock: 270000, pipe src size: 1920x1080, pixel rate 138120
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] linetime: 119, ips linetime: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] num_scalers: 2, scaler_users: 0x0, scaler_id: -1
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] pch pfit: pos: 0x00000000, size: 0x00000000, disabled, force thru: no
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] ips: 0, double wide: 0
[drm:icl_dump_hw_state [i915]] dpll_hw_state: cfgcr0: 0x1c001a5, cfgcr1: 0x8b, mg_refclkin_ctl: 0x0, hg_clktop2_coreclkctl1: 0x0, mg_clktop2_hsclkctl: 0x0, mg_pll_div0: 0x0, mg_pll_div2: 0x0, mg_pll_lf: 0x0, mg_pll_frac_lock: 0x0, mg_pll_ssc: 0x0, mg_pll_bias: 0x0, mg_pll_tdc_coldst_bias: 0x0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] csc_mode: 0x0 gamma_mode: 0x0 gamma_enable: 0 csc_enable: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] MST master transcoder: <invalid>
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] [PLANE:31:plane 1A] fb: [FB:262] 1920x1080 format = XR24 little-endian (0x34325258), visible: yes
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] rotation: 0x1, scaler: -1
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] src: 1920.000000x1080.000000+0.000000+0.000000 dst: 1920x1080+0+0
i915 0000:00:02.0: [drm:intel_psr_disable_locked [i915]] Disabling PSR1
i915 0000:00:02.0: [drm:intel_ddi_update_pipe [i915]] Panel doesn't support DRRS
------------[ cut here ]------------
i915 0000:00:02.0: drm_WARN_ON(fbc->active)
WARNING: CPU: 4 PID: 1175 at drivers/gpu/drm/i915/display/intel_fbc.c:973 __intel_fbc_disable+0xa5/0x130 [i915]
Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul snd_hda_intel crc32_pclmul snd_intel_dspcfg snd_hda_codec ghash_clmulni_intel snd_hwdep snd_hda_core cdc_ether e1000e usbnet mii snd_pcm ptp mei_me pps_core mei thunderbolt intel_lpss_pci prime_numbers
CPU: 4 PID: 1175 Comm: kms_frontbuffer Tainted: G U 5.5.0-CI-Trybot_5651+ #1
Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019
RIP: 0010:__intel_fbc_disable+0xa5/0x130 [i915]
Code: 8b 67 50 4d 85 e4 0f 84 8f 00 00 00 e8 44 33 30 e1 48 c7 c1 72 f6 4c a0 4c 89 e2 48 89 c6 48 c7 c7 42 f6 4c a0 e8 0b 9d ce e0 <0f> 0b eb 90 48 8b 7b 18 4c 8b 67 50 4d 85 e4 74 6d e8 15 33 30 e1
RSP: 0018:ffffc90000613b68 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff8884799d0000 RCX: 0000000000000006
RDX: 0000000000001905 RSI: ffff888495dac970 RDI: ffffffff823731a1
RBP: ffff88847c05d000 R08: ffff888495dac970 R09: 0000000000000000
R10: ffffc90000613b88 R11: 0000000000000000 R12: ffff88849bba7e40
R13: ffff8884799d0000 R14: ffff888498564000 R15: 0000000000000000
FS: 00007f8157f08300(0000) GS:ffff8884a0000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffdbfea2eb8 CR3: 000000049d1cc001 CR4: 0000000000760ee0
PKRU: 55555554
Call Trace:
intel_fbc_disable+0x4a/0x50 [i915]
intel_update_crtc+0x12c/0x1d0 [i915]
skl_commit_modeset_enables+0x14d/0x600 [i915]
intel_atomic_commit_tail+0x30d/0x1480 [i915]
? queue_work_on+0x31/0x70
? intel_atomic_commit_ready+0x3f/0x48 [i915]
? __i915_sw_fence_complete+0x1a0/0x250 [i915]
intel_atomic_commit+0x312/0x390 [i915]
intel_psr_fastset_force+0x119/0x150 [i915]
i915_edp_psr_debug_set+0x53/0x70 [i915]
simple_attr_write+0xb0/0xd0
full_proxy_write+0x51/0x80
vfs_write+0xb9/0x1d0
ksys_write+0x9f/0xe0
do_syscall_64+0x4f/0x220
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f8157240281
Code: c3 0f 1f 84 00 00 00 00 00 48 8b 05 59 8d 20 00 c3 0f 1f 84 00 00 00 00 00 8b 05 8a d1 20 00 85 c0 75 16 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 41 54 55 49 89 d4 53
RSP: 002b:00007ffdbfea59d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f8157240281
RDX: 0000000000000003 RSI: 00007f8157901152 RDI: 0000000000000008
RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f8157901152
R13: 0000000000000008 R14: 00005589d298dce0 R15: 0000000000000000
irq event stamp: 55208
hardirqs last enabled at (55207): [<ffffffff8112f3fc>] vprintk_emit+0xcc/0x330
hardirqs last disabled at (55208): [<ffffffff81001ca0>] trace_hardirqs_off_thunk+0x1a/0x1c
softirqs last enabled at (54926): [<ffffffff81e00385>] __do_softirq+0x385/0x47f
softirqs last disabled at (54915): [<ffffffff810ba15a>] irq_exit+0xba/0xc0
---[ end trace afa50c52e5a512bb ]---
[drm:__intel_fbc_disable [i915]] Disabling FBC on pipe A
i915 0000:00:02.0: [drm:verify_connector_state [i915]] [CONNECTOR:215:eDP-1]
i915 0000:00:02.0: [drm:intel_atomic_commit_tail [i915]] [CRTC:91:pipe A]
[drm:intel_ddi_get_config [i915]] [ENCODER:214:DDI A] Fec status: 0
i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.150 [i915]] DPLL 0
v2:
using intel_fbc_can_enable() instead of crtc_state->enable_fbc (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306185833.53984-1-jose.souza@intel.com
2020-03-07 01:58:32 +07:00
static bool intel_fbc_can_enable ( struct drm_i915_private * dev_priv )
{
struct intel_fbc * fbc = & dev_priv - > fbc ;
if ( intel_vgpu_active ( dev_priv ) ) {
fbc - > no_fbc_reason = " VGPU is active " ;
return false ;
}
2020-06-18 22:04:02 +07:00
if ( ! dev_priv - > params . enable_fbc ) {
drm/i915/display: Deactive FBC in fastsets when disabled by parameter
Most of the kms_frontbuffer_tracking tests disables the feature being
tested, draw, get the CRC then enable the feature, draw again, get the
CRC and check if it matches.
Some times it is able to do that with a fastset, so
intel_pre_plane_update() is executed but intel_fbc_can_flip_nuke() was
not checking if FBC is now enabled in this CRTC leaving FBC active and
causing the warning bellow in __intel_fbc_disable()
[IGT] kms_frontbuffer_tracking: starting subtest fbc-1p-pri-indfb-multidraw
Setting dangerous option enable_fbc - tainting kernel
i915 0000:00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR debug to f
i915 0000:00:02.0: [drm:intel_psr_debug_set [i915]] Invalid debug mask f
i915 0000:00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR debug to 1
i915 0000:00:02.0: [drm:intel_atomic_check [i915]] [CONNECTOR:215:eDP-1] Limiting display bpp to 24 instead of EDID bpp 24, requested bpp 36, max platform bpp 36
[drm:intel_dp_compute_config [i915]] DP link computation with max lane count 2 max rate 270000 max bpp 24 pixel clock 138120KHz
[drm:intel_dp_compute_config [i915]] Force DSC en = 0
[drm:intel_dp_compute_config [i915]] DP lane count 2 clock 270000 bpp 24
[drm:intel_dp_compute_config [i915]] DP link rate required 414360 available 540000
i915 0000:00:02.0: [drm:intel_atomic_check [i915]] hw max bpp: 24, pipe bpp: 24, dithering: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] [CRTC:91:pipe A] enable: yes [fastset]
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] active: yes, output_types: EDP (0x100), output format: RGB
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] cpu_transcoder: EDP, pipe bpp: 24, dithering: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] dp m_n: lanes: 2; gmch_m: 6436858, gmch_n: 8388608, link_m: 268202, link_n: 524288, tu: 64
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] audio: 0, infoframes: 0, infoframes enabled: 0x0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] requested mode:
[drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] adjusted mode:
[drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa
[drm:intel_dump_pipe_config [i915]] crtc timings: 138120 1920 1968 2018 2052 1080 1084 1086 1122, type: 0x48 flags: 0xa
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] port clock: 270000, pipe src size: 1920x1080, pixel rate 138120
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] linetime: 119, ips linetime: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] num_scalers: 2, scaler_users: 0x0, scaler_id: -1
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] pch pfit: pos: 0x00000000, size: 0x00000000, disabled, force thru: no
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] ips: 0, double wide: 0
[drm:icl_dump_hw_state [i915]] dpll_hw_state: cfgcr0: 0x1c001a5, cfgcr1: 0x8b, mg_refclkin_ctl: 0x0, hg_clktop2_coreclkctl1: 0x0, mg_clktop2_hsclkctl: 0x0, mg_pll_div0: 0x0, mg_pll_div2: 0x0, mg_pll_lf: 0x0, mg_pll_frac_lock: 0x0, mg_pll_ssc: 0x0, mg_pll_bias: 0x0, mg_pll_tdc_coldst_bias: 0x0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] csc_mode: 0x0 gamma_mode: 0x0 gamma_enable: 0 csc_enable: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] MST master transcoder: <invalid>
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] [PLANE:31:plane 1A] fb: [FB:262] 1920x1080 format = XR24 little-endian (0x34325258), visible: yes
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] rotation: 0x1, scaler: -1
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] src: 1920.000000x1080.000000+0.000000+0.000000 dst: 1920x1080+0+0
i915 0000:00:02.0: [drm:intel_psr_disable_locked [i915]] Disabling PSR1
i915 0000:00:02.0: [drm:intel_ddi_update_pipe [i915]] Panel doesn't support DRRS
------------[ cut here ]------------
i915 0000:00:02.0: drm_WARN_ON(fbc->active)
WARNING: CPU: 4 PID: 1175 at drivers/gpu/drm/i915/display/intel_fbc.c:973 __intel_fbc_disable+0xa5/0x130 [i915]
Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul snd_hda_intel crc32_pclmul snd_intel_dspcfg snd_hda_codec ghash_clmulni_intel snd_hwdep snd_hda_core cdc_ether e1000e usbnet mii snd_pcm ptp mei_me pps_core mei thunderbolt intel_lpss_pci prime_numbers
CPU: 4 PID: 1175 Comm: kms_frontbuffer Tainted: G U 5.5.0-CI-Trybot_5651+ #1
Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019
RIP: 0010:__intel_fbc_disable+0xa5/0x130 [i915]
Code: 8b 67 50 4d 85 e4 0f 84 8f 00 00 00 e8 44 33 30 e1 48 c7 c1 72 f6 4c a0 4c 89 e2 48 89 c6 48 c7 c7 42 f6 4c a0 e8 0b 9d ce e0 <0f> 0b eb 90 48 8b 7b 18 4c 8b 67 50 4d 85 e4 74 6d e8 15 33 30 e1
RSP: 0018:ffffc90000613b68 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff8884799d0000 RCX: 0000000000000006
RDX: 0000000000001905 RSI: ffff888495dac970 RDI: ffffffff823731a1
RBP: ffff88847c05d000 R08: ffff888495dac970 R09: 0000000000000000
R10: ffffc90000613b88 R11: 0000000000000000 R12: ffff88849bba7e40
R13: ffff8884799d0000 R14: ffff888498564000 R15: 0000000000000000
FS: 00007f8157f08300(0000) GS:ffff8884a0000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffdbfea2eb8 CR3: 000000049d1cc001 CR4: 0000000000760ee0
PKRU: 55555554
Call Trace:
intel_fbc_disable+0x4a/0x50 [i915]
intel_update_crtc+0x12c/0x1d0 [i915]
skl_commit_modeset_enables+0x14d/0x600 [i915]
intel_atomic_commit_tail+0x30d/0x1480 [i915]
? queue_work_on+0x31/0x70
? intel_atomic_commit_ready+0x3f/0x48 [i915]
? __i915_sw_fence_complete+0x1a0/0x250 [i915]
intel_atomic_commit+0x312/0x390 [i915]
intel_psr_fastset_force+0x119/0x150 [i915]
i915_edp_psr_debug_set+0x53/0x70 [i915]
simple_attr_write+0xb0/0xd0
full_proxy_write+0x51/0x80
vfs_write+0xb9/0x1d0
ksys_write+0x9f/0xe0
do_syscall_64+0x4f/0x220
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f8157240281
Code: c3 0f 1f 84 00 00 00 00 00 48 8b 05 59 8d 20 00 c3 0f 1f 84 00 00 00 00 00 8b 05 8a d1 20 00 85 c0 75 16 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 41 54 55 49 89 d4 53
RSP: 002b:00007ffdbfea59d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f8157240281
RDX: 0000000000000003 RSI: 00007f8157901152 RDI: 0000000000000008
RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f8157901152
R13: 0000000000000008 R14: 00005589d298dce0 R15: 0000000000000000
irq event stamp: 55208
hardirqs last enabled at (55207): [<ffffffff8112f3fc>] vprintk_emit+0xcc/0x330
hardirqs last disabled at (55208): [<ffffffff81001ca0>] trace_hardirqs_off_thunk+0x1a/0x1c
softirqs last enabled at (54926): [<ffffffff81e00385>] __do_softirq+0x385/0x47f
softirqs last disabled at (54915): [<ffffffff810ba15a>] irq_exit+0xba/0xc0
---[ end trace afa50c52e5a512bb ]---
[drm:__intel_fbc_disable [i915]] Disabling FBC on pipe A
i915 0000:00:02.0: [drm:verify_connector_state [i915]] [CONNECTOR:215:eDP-1]
i915 0000:00:02.0: [drm:intel_atomic_commit_tail [i915]] [CRTC:91:pipe A]
[drm:intel_ddi_get_config [i915]] [ENCODER:214:DDI A] Fec status: 0
i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.150 [i915]] DPLL 0
v2:
using intel_fbc_can_enable() instead of crtc_state->enable_fbc (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306185833.53984-1-jose.souza@intel.com
2020-03-07 01:58:32 +07:00
fbc - > no_fbc_reason = " disabled per module param or by default " ;
return false ;
}
if ( fbc - > underrun_detected ) {
fbc - > no_fbc_reason = " underrun detected " ;
return false ;
}
return true ;
}
2016-01-19 20:35:42 +07:00
static bool intel_fbc_can_activate ( struct intel_crtc * crtc )
{
2016-07-04 17:34:36 +07:00
struct drm_i915_private * dev_priv = to_i915 ( crtc - > base . dev ) ;
2016-01-19 20:35:42 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
struct intel_fbc_state_cache * cache = & fbc - > state_cache ;
drm/i915/display: Deactive FBC in fastsets when disabled by parameter
Most of the kms_frontbuffer_tracking tests disables the feature being
tested, draw, get the CRC then enable the feature, draw again, get the
CRC and check if it matches.
Some times it is able to do that with a fastset, so
intel_pre_plane_update() is executed but intel_fbc_can_flip_nuke() was
not checking if FBC is now enabled in this CRTC leaving FBC active and
causing the warning bellow in __intel_fbc_disable()
[IGT] kms_frontbuffer_tracking: starting subtest fbc-1p-pri-indfb-multidraw
Setting dangerous option enable_fbc - tainting kernel
i915 0000:00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR debug to f
i915 0000:00:02.0: [drm:intel_psr_debug_set [i915]] Invalid debug mask f
i915 0000:00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR debug to 1
i915 0000:00:02.0: [drm:intel_atomic_check [i915]] [CONNECTOR:215:eDP-1] Limiting display bpp to 24 instead of EDID bpp 24, requested bpp 36, max platform bpp 36
[drm:intel_dp_compute_config [i915]] DP link computation with max lane count 2 max rate 270000 max bpp 24 pixel clock 138120KHz
[drm:intel_dp_compute_config [i915]] Force DSC en = 0
[drm:intel_dp_compute_config [i915]] DP lane count 2 clock 270000 bpp 24
[drm:intel_dp_compute_config [i915]] DP link rate required 414360 available 540000
i915 0000:00:02.0: [drm:intel_atomic_check [i915]] hw max bpp: 24, pipe bpp: 24, dithering: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] [CRTC:91:pipe A] enable: yes [fastset]
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] active: yes, output_types: EDP (0x100), output format: RGB
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] cpu_transcoder: EDP, pipe bpp: 24, dithering: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] dp m_n: lanes: 2; gmch_m: 6436858, gmch_n: 8388608, link_m: 268202, link_n: 524288, tu: 64
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] audio: 0, infoframes: 0, infoframes enabled: 0x0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] requested mode:
[drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] adjusted mode:
[drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa
[drm:intel_dump_pipe_config [i915]] crtc timings: 138120 1920 1968 2018 2052 1080 1084 1086 1122, type: 0x48 flags: 0xa
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] port clock: 270000, pipe src size: 1920x1080, pixel rate 138120
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] linetime: 119, ips linetime: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] num_scalers: 2, scaler_users: 0x0, scaler_id: -1
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] pch pfit: pos: 0x00000000, size: 0x00000000, disabled, force thru: no
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] ips: 0, double wide: 0
[drm:icl_dump_hw_state [i915]] dpll_hw_state: cfgcr0: 0x1c001a5, cfgcr1: 0x8b, mg_refclkin_ctl: 0x0, hg_clktop2_coreclkctl1: 0x0, mg_clktop2_hsclkctl: 0x0, mg_pll_div0: 0x0, mg_pll_div2: 0x0, mg_pll_lf: 0x0, mg_pll_frac_lock: 0x0, mg_pll_ssc: 0x0, mg_pll_bias: 0x0, mg_pll_tdc_coldst_bias: 0x0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] csc_mode: 0x0 gamma_mode: 0x0 gamma_enable: 0 csc_enable: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] MST master transcoder: <invalid>
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] [PLANE:31:plane 1A] fb: [FB:262] 1920x1080 format = XR24 little-endian (0x34325258), visible: yes
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] rotation: 0x1, scaler: -1
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] src: 1920.000000x1080.000000+0.000000+0.000000 dst: 1920x1080+0+0
i915 0000:00:02.0: [drm:intel_psr_disable_locked [i915]] Disabling PSR1
i915 0000:00:02.0: [drm:intel_ddi_update_pipe [i915]] Panel doesn't support DRRS
------------[ cut here ]------------
i915 0000:00:02.0: drm_WARN_ON(fbc->active)
WARNING: CPU: 4 PID: 1175 at drivers/gpu/drm/i915/display/intel_fbc.c:973 __intel_fbc_disable+0xa5/0x130 [i915]
Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul snd_hda_intel crc32_pclmul snd_intel_dspcfg snd_hda_codec ghash_clmulni_intel snd_hwdep snd_hda_core cdc_ether e1000e usbnet mii snd_pcm ptp mei_me pps_core mei thunderbolt intel_lpss_pci prime_numbers
CPU: 4 PID: 1175 Comm: kms_frontbuffer Tainted: G U 5.5.0-CI-Trybot_5651+ #1
Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019
RIP: 0010:__intel_fbc_disable+0xa5/0x130 [i915]
Code: 8b 67 50 4d 85 e4 0f 84 8f 00 00 00 e8 44 33 30 e1 48 c7 c1 72 f6 4c a0 4c 89 e2 48 89 c6 48 c7 c7 42 f6 4c a0 e8 0b 9d ce e0 <0f> 0b eb 90 48 8b 7b 18 4c 8b 67 50 4d 85 e4 74 6d e8 15 33 30 e1
RSP: 0018:ffffc90000613b68 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff8884799d0000 RCX: 0000000000000006
RDX: 0000000000001905 RSI: ffff888495dac970 RDI: ffffffff823731a1
RBP: ffff88847c05d000 R08: ffff888495dac970 R09: 0000000000000000
R10: ffffc90000613b88 R11: 0000000000000000 R12: ffff88849bba7e40
R13: ffff8884799d0000 R14: ffff888498564000 R15: 0000000000000000
FS: 00007f8157f08300(0000) GS:ffff8884a0000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffdbfea2eb8 CR3: 000000049d1cc001 CR4: 0000000000760ee0
PKRU: 55555554
Call Trace:
intel_fbc_disable+0x4a/0x50 [i915]
intel_update_crtc+0x12c/0x1d0 [i915]
skl_commit_modeset_enables+0x14d/0x600 [i915]
intel_atomic_commit_tail+0x30d/0x1480 [i915]
? queue_work_on+0x31/0x70
? intel_atomic_commit_ready+0x3f/0x48 [i915]
? __i915_sw_fence_complete+0x1a0/0x250 [i915]
intel_atomic_commit+0x312/0x390 [i915]
intel_psr_fastset_force+0x119/0x150 [i915]
i915_edp_psr_debug_set+0x53/0x70 [i915]
simple_attr_write+0xb0/0xd0
full_proxy_write+0x51/0x80
vfs_write+0xb9/0x1d0
ksys_write+0x9f/0xe0
do_syscall_64+0x4f/0x220
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f8157240281
Code: c3 0f 1f 84 00 00 00 00 00 48 8b 05 59 8d 20 00 c3 0f 1f 84 00 00 00 00 00 8b 05 8a d1 20 00 85 c0 75 16 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 41 54 55 49 89 d4 53
RSP: 002b:00007ffdbfea59d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f8157240281
RDX: 0000000000000003 RSI: 00007f8157901152 RDI: 0000000000000008
RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f8157901152
R13: 0000000000000008 R14: 00005589d298dce0 R15: 0000000000000000
irq event stamp: 55208
hardirqs last enabled at (55207): [<ffffffff8112f3fc>] vprintk_emit+0xcc/0x330
hardirqs last disabled at (55208): [<ffffffff81001ca0>] trace_hardirqs_off_thunk+0x1a/0x1c
softirqs last enabled at (54926): [<ffffffff81e00385>] __do_softirq+0x385/0x47f
softirqs last disabled at (54915): [<ffffffff810ba15a>] irq_exit+0xba/0xc0
---[ end trace afa50c52e5a512bb ]---
[drm:__intel_fbc_disable [i915]] Disabling FBC on pipe A
i915 0000:00:02.0: [drm:verify_connector_state [i915]] [CONNECTOR:215:eDP-1]
i915 0000:00:02.0: [drm:intel_atomic_commit_tail [i915]] [CRTC:91:pipe A]
[drm:intel_ddi_get_config [i915]] [ENCODER:214:DDI A] Fec status: 0
i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.150 [i915]] DPLL 0
v2:
using intel_fbc_can_enable() instead of crtc_state->enable_fbc (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306185833.53984-1-jose.souza@intel.com
2020-03-07 01:58:32 +07:00
if ( ! intel_fbc_can_enable ( dev_priv ) )
return false ;
2019-11-28 03:12:14 +07:00
if ( ! cache - > plane . visible ) {
fbc - > no_fbc_reason = " primary plane not visible " ;
return false ;
}
2016-09-13 20:38:57 +07:00
/* We don't need to use a state cache here since this information is
* global for all CRTC .
*/
if ( fbc - > underrun_detected ) {
fbc - > no_fbc_reason = " underrun detected " ;
return false ;
}
2017-11-15 01:32:58 +07:00
if ( cache - > crtc . mode_flags & DRM_MODE_FLAG_INTERLACE ) {
drm/i915/fbc: don't print no_fbc_reason to dmesg
Our dmesg messages started being misleading after we converted to the
enable+activate model: we always print "Disabling FBC", even when
we're just deactivating it. So, for example, when I boot my machine
and do "dmesg | grep -i fbc", I see:
[drm:intel_fbc_enable] Enabling FBC on pipe A
[drm:set_no_fbc_reason] Disabling FBC: framebuffer not tiled or fenced
but then, if I read the debugfs file, I will see:
$ sudo cat i915_fbc_status
FBC enabled
Compressing: yes
so we can conclude that dmesg is misleading, since FBC is actually
enabled. What happened is that we deactivated FBC due to fbcon not
being tiled, but when we silently reactivated it when the display
manager started. We don't print activation messages since there may be
way too many of these operations per second during normal desktop
usage.
One possible solution would be to change set_no_fbc_reason to
correctly differentiate between disable and deactivation, but we
removed support from printing activation/deactivation messages in the
past because they were too frequent. So instead of doing this, let's
just not print anything on dmesg, and leave the debugfs file if the
user needs to investigate something. We already print when we enable
and disable FBC anyway on a given pipe, so this should already help
triaging bugs.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-22-git-send-email-paulo.r.zanoni@intel.com
2016-01-19 20:35:54 +07:00
fbc - > no_fbc_reason = " incompatible mode " ;
2016-01-19 20:35:35 +07:00
return false ;
2014-12-08 23:09:10 +07:00
}
2015-11-05 02:10:49 +07:00
if ( ! intel_fbc_hw_tracking_covers_screen ( crtc ) ) {
drm/i915/fbc: don't print no_fbc_reason to dmesg
Our dmesg messages started being misleading after we converted to the
enable+activate model: we always print "Disabling FBC", even when
we're just deactivating it. So, for example, when I boot my machine
and do "dmesg | grep -i fbc", I see:
[drm:intel_fbc_enable] Enabling FBC on pipe A
[drm:set_no_fbc_reason] Disabling FBC: framebuffer not tiled or fenced
but then, if I read the debugfs file, I will see:
$ sudo cat i915_fbc_status
FBC enabled
Compressing: yes
so we can conclude that dmesg is misleading, since FBC is actually
enabled. What happened is that we deactivated FBC due to fbcon not
being tiled, but when we silently reactivated it when the display
manager started. We don't print activation messages since there may be
way too many of these operations per second during normal desktop
usage.
One possible solution would be to change set_no_fbc_reason to
correctly differentiate between disable and deactivation, but we
removed support from printing activation/deactivation messages in the
past because they were too frequent. So instead of doing this, let's
just not print anything on dmesg, and leave the debugfs file if the
user needs to investigate something. We already print when we enable
and disable FBC anyway on a given pipe, so this should already help
triaging bugs.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-22-git-send-email-paulo.r.zanoni@intel.com
2016-01-19 20:35:54 +07:00
fbc - > no_fbc_reason = " mode too large for compression " ;
2016-01-19 20:35:35 +07:00
return false ;
2014-12-08 23:09:10 +07:00
}
2015-09-23 22:52:24 +07:00
2020-03-20 04:15:35 +07:00
/* The use of a CPU fence is one of two ways to detect writes by the
* CPU to the scanout and trigger updates to the FBC .
*
* The other method is by software tracking ( see
* intel_fbc_invalidate / flush ( ) ) , it will manually notify FBC and nuke
* the current compressed buffer and recompress it .
2016-08-18 23:17:06 +07:00
*
* Note that is possible for a tiled surface to be unmappable ( and
2020-03-20 04:15:35 +07:00
* so have no fence associated with it ) due to aperture constraints
2016-08-18 23:17:06 +07:00
* at the time of pinning .
2018-02-21 23:02:35 +07:00
*
* FIXME with 90 / 270 degree rotation we should use the fence on
* the normal GTT view ( the rotated view doesn ' t even have a
* fence ) . Would need changes to the FBC fence Y offset as well .
2020-03-20 04:15:35 +07:00
* For now this will effectively disable FBC with 90 / 270 degree
2018-02-21 23:02:35 +07:00
* rotation .
2014-12-08 23:09:10 +07:00
*/
2020-03-20 04:15:35 +07:00
if ( INTEL_GEN ( dev_priv ) < 9 & & cache - > fence_id < 0 ) {
2016-08-25 01:00:53 +07:00
fbc - > no_fbc_reason = " framebuffer not tiled or fenced " ;
return false ;
2014-12-08 23:09:10 +07:00
}
2020-03-20 04:15:35 +07:00
if ( ! rotation_is_valid ( dev_priv , cache - > fb . format - > format ,
cache - > plane . rotation ) ) {
drm/i915/fbc: don't print no_fbc_reason to dmesg
Our dmesg messages started being misleading after we converted to the
enable+activate model: we always print "Disabling FBC", even when
we're just deactivating it. So, for example, when I boot my machine
and do "dmesg | grep -i fbc", I see:
[drm:intel_fbc_enable] Enabling FBC on pipe A
[drm:set_no_fbc_reason] Disabling FBC: framebuffer not tiled or fenced
but then, if I read the debugfs file, I will see:
$ sudo cat i915_fbc_status
FBC enabled
Compressing: yes
so we can conclude that dmesg is misleading, since FBC is actually
enabled. What happened is that we deactivated FBC due to fbcon not
being tiled, but when we silently reactivated it when the display
manager started. We don't print activation messages since there may be
way too many of these operations per second during normal desktop
usage.
One possible solution would be to change set_no_fbc_reason to
correctly differentiate between disable and deactivation, but we
removed support from printing activation/deactivation messages in the
past because they were too frequent. So instead of doing this, let's
just not print anything on dmesg, and leave the debugfs file if the
user needs to investigate something. We already print when we enable
and disable FBC anyway on a given pipe, so this should already help
triaging bugs.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-22-git-send-email-paulo.r.zanoni@intel.com
2016-01-19 20:35:54 +07:00
fbc - > no_fbc_reason = " rotation unsupported " ;
2016-01-19 20:35:35 +07:00
return false ;
2014-12-08 23:09:10 +07:00
}
2020-03-20 04:15:35 +07:00
if ( ! tiling_is_valid ( dev_priv , cache - > fb . modifier ) ) {
fbc - > no_fbc_reason = " tiling unsupported " ;
return false ;
}
2020-04-29 17:10:23 +07:00
if ( ! stride_is_valid ( dev_priv , cache - > fb . modifier , cache - > fb . stride ) ) {
drm/i915/fbc: don't print no_fbc_reason to dmesg
Our dmesg messages started being misleading after we converted to the
enable+activate model: we always print "Disabling FBC", even when
we're just deactivating it. So, for example, when I boot my machine
and do "dmesg | grep -i fbc", I see:
[drm:intel_fbc_enable] Enabling FBC on pipe A
[drm:set_no_fbc_reason] Disabling FBC: framebuffer not tiled or fenced
but then, if I read the debugfs file, I will see:
$ sudo cat i915_fbc_status
FBC enabled
Compressing: yes
so we can conclude that dmesg is misleading, since FBC is actually
enabled. What happened is that we deactivated FBC due to fbcon not
being tiled, but when we silently reactivated it when the display
manager started. We don't print activation messages since there may be
way too many of these operations per second during normal desktop
usage.
One possible solution would be to change set_no_fbc_reason to
correctly differentiate between disable and deactivation, but we
removed support from printing activation/deactivation messages in the
past because they were too frequent. So instead of doing this, let's
just not print anything on dmesg, and leave the debugfs file if the
user needs to investigate something. We already print when we enable
and disable FBC anyway on a given pipe, so this should already help
triaging bugs.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-22-git-send-email-paulo.r.zanoni@intel.com
2016-01-19 20:35:54 +07:00
fbc - > no_fbc_reason = " framebuffer stride not supported " ;
2016-01-19 20:35:35 +07:00
return false ;
2015-09-15 01:19:56 +07:00
}
2016-11-19 02:53:04 +07:00
if ( ! pixel_format_is_valid ( dev_priv , cache - > fb . format - > format ) ) {
drm/i915/fbc: don't print no_fbc_reason to dmesg
Our dmesg messages started being misleading after we converted to the
enable+activate model: we always print "Disabling FBC", even when
we're just deactivating it. So, for example, when I boot my machine
and do "dmesg | grep -i fbc", I see:
[drm:intel_fbc_enable] Enabling FBC on pipe A
[drm:set_no_fbc_reason] Disabling FBC: framebuffer not tiled or fenced
but then, if I read the debugfs file, I will see:
$ sudo cat i915_fbc_status
FBC enabled
Compressing: yes
so we can conclude that dmesg is misleading, since FBC is actually
enabled. What happened is that we deactivated FBC due to fbcon not
being tiled, but when we silently reactivated it when the display
manager started. We don't print activation messages since there may be
way too many of these operations per second during normal desktop
usage.
One possible solution would be to change set_no_fbc_reason to
correctly differentiate between disable and deactivation, but we
removed support from printing activation/deactivation messages in the
past because they were too frequent. So instead of doing this, let's
just not print anything on dmesg, and leave the debugfs file if the
user needs to investigate something. We already print when we enable
and disable FBC anyway on a given pipe, so this should already help
triaging bugs.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-22-git-send-email-paulo.r.zanoni@intel.com
2016-01-19 20:35:54 +07:00
fbc - > no_fbc_reason = " pixel format is invalid " ;
2016-01-19 20:35:35 +07:00
return false ;
2015-09-22 05:48:06 +07:00
}
2018-08-15 17:34:05 +07:00
if ( cache - > plane . pixel_blend_mode ! = DRM_MODE_BLEND_PIXEL_NONE & &
cache - > fb . format - > has_alpha ) {
fbc - > no_fbc_reason = " per-pixel alpha blending is incompatible with FBC " ;
return false ;
}
2015-09-15 01:19:59 +07:00
/* WaFbcExceedCdClockThreshold:hsw,bdw */
if ( ( IS_HASWELL ( dev_priv ) | | IS_BROADWELL ( dev_priv ) ) & &
2017-02-08 01:33:45 +07:00
cache - > crtc . hsw_bdw_pixel_rate > = dev_priv - > cdclk . hw . cdclk * 95 / 100 ) {
drm/i915/fbc: don't print no_fbc_reason to dmesg
Our dmesg messages started being misleading after we converted to the
enable+activate model: we always print "Disabling FBC", even when
we're just deactivating it. So, for example, when I boot my machine
and do "dmesg | grep -i fbc", I see:
[drm:intel_fbc_enable] Enabling FBC on pipe A
[drm:set_no_fbc_reason] Disabling FBC: framebuffer not tiled or fenced
but then, if I read the debugfs file, I will see:
$ sudo cat i915_fbc_status
FBC enabled
Compressing: yes
so we can conclude that dmesg is misleading, since FBC is actually
enabled. What happened is that we deactivated FBC due to fbcon not
being tiled, but when we silently reactivated it when the display
manager started. We don't print activation messages since there may be
way too many of these operations per second during normal desktop
usage.
One possible solution would be to change set_no_fbc_reason to
correctly differentiate between disable and deactivation, but we
removed support from printing activation/deactivation messages in the
past because they were too frequent. So instead of doing this, let's
just not print anything on dmesg, and leave the debugfs file if the
user needs to investigate something. We already print when we enable
and disable FBC anyway on a given pipe, so this should already help
triaging bugs.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-22-git-send-email-paulo.r.zanoni@intel.com
2016-01-19 20:35:54 +07:00
fbc - > no_fbc_reason = " pixel rate is too big " ;
2016-01-19 20:35:35 +07:00
return false ;
2015-09-15 01:19:59 +07:00
}
drm/i915: alloc/free the FBC CFB during enable/disable
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.
I thought about three different approaches to solve this, and they all
have downsides.
The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.
The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
disable and other calls in the middle of the wait.
Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.
The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow - see
igt's kms_frontbuffer_tracking test, fbc-stridechange subtest. It
could be possible to implement a way to free+alloc the CFB during said
stride change, but it would involve a lot of book-keeping - exactly as
mentioned above - just for on case, so for now I'll keep it simple and
just deactivate FBC. Besides, we may not even need to disable FBC
since we do CFB over-allocation.
Note from Chris: "Starting a fullscreen client that covers a single
monitor in a multi-monitor setup will trigger a change in stride on
one of the CRTCs (the monitors will be flipped independently).". It
shouldn't be a huge problem if we lose FBC on multi-monitor setups
since these setups already have problems reaching deep PC states
anyway.
v2: Rebase after changing the patch order.
v3:
- Remove references to the stride change case being "uncommon" and
paste Chris' example.
- Rebase after a change in a previous patch.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
2015-10-16 00:19:21 +07:00
/* It is possible for the required CFB size change without a
* crtc - > disable + crtc - > enable since it is possible to change the
* stride without triggering a full modeset . Since we try to
* over - allocate the CFB , there ' s a chance we may keep FBC enabled even
* if this happens , but if we exceed the current CFB size we ' ll have to
* disable FBC . Notice that it would be possible to disable FBC , wait
* for a frame , free the stolen node , then try to reenable FBC in case
* we didn ' t get any invalidate / deactivate calls , but this would require
* a lot of tracking just for a specific case . If we conclude it ' s an
* important case , we can implement it later . */
2019-11-28 03:12:22 +07:00
if ( intel_fbc_cfb_size_changed ( dev_priv ) ) {
drm/i915/fbc: don't print no_fbc_reason to dmesg
Our dmesg messages started being misleading after we converted to the
enable+activate model: we always print "Disabling FBC", even when
we're just deactivating it. So, for example, when I boot my machine
and do "dmesg | grep -i fbc", I see:
[drm:intel_fbc_enable] Enabling FBC on pipe A
[drm:set_no_fbc_reason] Disabling FBC: framebuffer not tiled or fenced
but then, if I read the debugfs file, I will see:
$ sudo cat i915_fbc_status
FBC enabled
Compressing: yes
so we can conclude that dmesg is misleading, since FBC is actually
enabled. What happened is that we deactivated FBC due to fbcon not
being tiled, but when we silently reactivated it when the display
manager started. We don't print activation messages since there may be
way too many of these operations per second during normal desktop
usage.
One possible solution would be to change set_no_fbc_reason to
correctly differentiate between disable and deactivation, but we
removed support from printing activation/deactivation messages in the
past because they were too frequent. So instead of doing this, let's
just not print anything on dmesg, and leave the debugfs file if the
user needs to investigate something. We already print when we enable
and disable FBC anyway on a given pipe, so this should already help
triaging bugs.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-22-git-send-email-paulo.r.zanoni@intel.com
2016-01-19 20:35:54 +07:00
fbc - > no_fbc_reason = " CFB requirements changed " ;
2016-01-19 20:35:35 +07:00
return false ;
}
2018-03-01 20:44:57 +07:00
/*
* Work around a problem on GEN9 + HW , where enabling FBC on a plane
* having a Y offset that isn ' t divisible by 4 causes FIFO underrun
* and screen flicker .
*/
2019-12-13 20:34:48 +07:00
if ( INTEL_GEN ( dev_priv ) > = 9 & &
2018-03-01 20:44:57 +07:00
( fbc - > state_cache . plane . adjusted_y & 3 ) ) {
fbc - > no_fbc_reason = " plane Y offset is misaligned " ;
return false ;
}
2016-01-19 20:35:35 +07:00
return true ;
}
2015-12-24 03:28:11 +07:00
static void intel_fbc_get_reg_params ( struct intel_crtc * crtc ,
struct intel_fbc_reg_params * params )
{
2016-07-04 17:34:36 +07:00
struct drm_i915_private * dev_priv = to_i915 ( crtc - > base . dev ) ;
2016-01-19 20:35:42 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
struct intel_fbc_state_cache * cache = & fbc - > state_cache ;
2015-12-24 03:28:11 +07:00
/* Since all our fields are integer types, use memset here so the
* comparison function can rely on memcmp because the padding will be
* zero . */
memset ( params , 0 , sizeof ( * params ) ) ;
2019-11-28 03:12:15 +07:00
params - > fence_id = cache - > fence_id ;
2017-01-16 22:21:27 +07:00
2015-12-24 03:28:11 +07:00
params - > crtc . pipe = crtc - > pipe ;
2017-11-18 02:19:15 +07:00
params - > crtc . i9xx_plane = to_intel_plane ( crtc - > base . primary ) - > i9xx_plane ;
2017-10-18 03:08:11 +07:00
params - > crtc . fence_y_offset = get_crtc_fence_y_offset ( fbc ) ;
2015-12-24 03:28:11 +07:00
2016-11-19 02:53:04 +07:00
params - > fb . format = cache - > fb . format ;
2016-01-19 20:35:42 +07:00
params - > fb . stride = cache - > fb . stride ;
2015-12-24 03:28:11 +07:00
2016-01-19 20:35:42 +07:00
params - > cfb_size = intel_fbc_calculate_cfb_size ( dev_priv , cache ) ;
2017-08-11 01:30:33 +07:00
2019-11-28 03:12:13 +07:00
params - > gen9_wa_cfb_stride = cache - > gen9_wa_cfb_stride ;
2019-11-28 03:12:14 +07:00
params - > plane_visible = cache - > plane . visible ;
2015-12-24 03:28:11 +07:00
}
2019-11-28 03:12:19 +07:00
static bool intel_fbc_can_flip_nuke ( const struct intel_crtc_state * crtc_state )
{
struct intel_crtc * crtc = to_intel_crtc ( crtc_state - > uapi . crtc ) ;
struct drm_i915_private * dev_priv = to_i915 ( crtc - > base . dev ) ;
const struct intel_fbc * fbc = & dev_priv - > fbc ;
const struct intel_fbc_state_cache * cache = & fbc - > state_cache ;
const struct intel_fbc_reg_params * params = & fbc - > params ;
if ( drm_atomic_crtc_needs_modeset ( & crtc_state - > uapi ) )
return false ;
if ( ! params - > plane_visible )
return false ;
if ( ! intel_fbc_can_activate ( crtc ) )
return false ;
if ( params - > fb . format ! = cache - > fb . format )
return false ;
if ( params - > fb . stride ! = cache - > fb . stride )
return false ;
if ( params - > cfb_size ! = intel_fbc_calculate_cfb_size ( dev_priv , cache ) )
return false ;
if ( params - > gen9_wa_cfb_stride ! = cache - > gen9_wa_cfb_stride )
return false ;
return true ;
}
2019-12-13 20:34:50 +07:00
bool intel_fbc_pre_update ( struct intel_atomic_state * state ,
struct intel_crtc * crtc )
2016-01-19 20:35:35 +07:00
{
2019-12-13 20:34:50 +07:00
struct intel_plane * plane = to_intel_plane ( crtc - > base . primary ) ;
const struct intel_crtc_state * crtc_state =
intel_atomic_get_new_crtc_state ( state , crtc ) ;
const struct intel_plane_state * plane_state =
intel_atomic_get_new_plane_state ( state , plane ) ;
2016-07-04 17:34:36 +07:00
struct drm_i915_private * dev_priv = to_i915 ( crtc - > base . dev ) ;
2016-01-12 02:44:36 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
2018-01-26 05:41:22 +07:00
const char * reason = " update pending " ;
2019-11-28 22:03:38 +07:00
bool need_vblank_wait = false ;
2016-01-19 20:35:35 +07:00
2019-12-13 20:34:51 +07:00
if ( ! plane - > has_fbc | | ! plane_state )
2019-12-13 20:34:50 +07:00
return need_vblank_wait ;
2016-01-19 20:35:44 +07:00
mutex_lock ( & fbc - > lock ) ;
2016-01-19 20:35:35 +07:00
2019-11-28 03:12:18 +07:00
if ( fbc - > crtc ! = crtc )
2016-01-19 20:35:44 +07:00
goto unlock ;
2016-01-19 20:35:35 +07:00
2016-06-14 19:24:20 +07:00
intel_fbc_update_state_cache ( crtc , crtc_state , plane_state ) ;
2018-06-25 23:37:57 +07:00
fbc - > flip_pending = true ;
2016-01-19 20:35:42 +07:00
2019-11-28 22:03:38 +07:00
if ( ! intel_fbc_can_flip_nuke ( crtc_state ) ) {
2019-11-28 03:12:19 +07:00
intel_fbc_deactivate ( dev_priv , reason ) ;
2019-11-28 22:03:38 +07:00
/*
* Display WA # 1198 : glk +
* Need an extra vblank wait between FBC disable and most plane
* updates . Bspec says this is only needed for plane disable , but
* that is not true . Touching most plane registers will cause the
* corruption to appear . Also SKL / derivatives do not seem to be
* affected .
*
* TODO : could optimize this a bit by sampling the frame
* counter when we disable FBC ( if it was already done earlier )
* and skipping the extra vblank wait before the plane update
* if at least one frame has already passed .
*/
if ( fbc - > activated & &
( INTEL_GEN ( dev_priv ) > = 10 | | IS_GEMINILAKE ( dev_priv ) ) )
need_vblank_wait = true ;
fbc - > activated = false ;
}
2016-01-19 20:35:44 +07:00
unlock :
mutex_unlock ( & fbc - > lock ) ;
2019-11-28 22:03:38 +07:00
return need_vblank_wait ;
2016-01-19 20:35:43 +07:00
}
2018-03-05 19:36:08 +07:00
/**
* __intel_fbc_disable - disable FBC
* @ dev_priv : i915 device instance
*
* This is the low level function that actually disables FBC . Callers should
* grab the FBC lock .
*/
static void __intel_fbc_disable ( struct drm_i915_private * dev_priv )
{
struct intel_fbc * fbc = & dev_priv - > fbc ;
struct intel_crtc * crtc = fbc - > crtc ;
drm/i915/display/fbc: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128181603.27767-11-pankaj.laxminarayan.bharadiya@intel.com
2020-01-29 01:15:52 +07:00
drm_WARN_ON ( & dev_priv - > drm , ! mutex_is_locked ( & fbc - > lock ) ) ;
drm_WARN_ON ( & dev_priv - > drm , ! fbc - > crtc ) ;
drm_WARN_ON ( & dev_priv - > drm , fbc - > active ) ;
2018-03-05 19:36:08 +07:00
drm/i915/fbc: convert to drm_device based logging macros.
This replaces the uses of the printk based drm logging macros with the
struct drm_device based logging macros in i915/display/intel_fbc.c.
This transformation was done using the following coccinelle semantic
patch that matches based on the existence of a drm_i915_private device
pointer:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
New checkpatch warnings were addressed manually.
v2 by Jani:
- also convert pr_info_once to drm based logging
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Wambui Karuga <wambui.karugax@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/32a92f1d4e4d01131605b17bec831517e39c5902.1583766715.git.jani.nikula@intel.com
2020-03-10 15:52:41 +07:00
drm_dbg_kms ( & dev_priv - > drm , " Disabling FBC on pipe %c \n " ,
pipe_name ( crtc - > pipe ) ) ;
2018-03-05 19:36:08 +07:00
__intel_fbc_cleanup_cfb ( dev_priv ) ;
fbc - > crtc = NULL ;
}
2016-01-19 20:35:44 +07:00
static void __intel_fbc_post_update ( struct intel_crtc * crtc )
2016-01-19 20:35:43 +07:00
{
2016-07-04 17:34:36 +07:00
struct drm_i915_private * dev_priv = to_i915 ( crtc - > base . dev ) ;
2016-01-19 20:35:43 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
drm/i915/display/fbc: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128181603.27767-11-pankaj.laxminarayan.bharadiya@intel.com
2020-01-29 01:15:52 +07:00
drm_WARN_ON ( & dev_priv - > drm , ! mutex_is_locked ( & fbc - > lock ) ) ;
2016-01-19 20:35:43 +07:00
2019-11-28 03:12:18 +07:00
if ( fbc - > crtc ! = crtc )
2016-01-19 20:35:43 +07:00
return ;
2018-06-25 23:37:57 +07:00
fbc - > flip_pending = false ;
2020-06-18 22:04:02 +07:00
if ( ! dev_priv - > params . enable_fbc ) {
2018-03-05 19:36:08 +07:00
intel_fbc_deactivate ( dev_priv , " disabled at runtime per module param " ) ;
__intel_fbc_disable ( dev_priv ) ;
return ;
}
2016-01-12 02:44:36 +07:00
intel_fbc_get_reg_params ( crtc , & fbc - > params ) ;
2015-12-24 03:28:11 +07:00
2018-06-25 23:37:57 +07:00
if ( ! intel_fbc_can_activate ( crtc ) )
2014-12-08 23:09:10 +07:00
return ;
2019-11-28 03:12:19 +07:00
if ( ! fbc - > busy_bits )
2018-06-25 23:37:58 +07:00
intel_fbc_hw_activate ( dev_priv ) ;
2019-11-28 03:12:19 +07:00
else
2018-06-25 23:37:57 +07:00
intel_fbc_deactivate ( dev_priv , " frontbuffer write " ) ;
2015-07-03 05:25:10 +07:00
}
2019-12-13 20:34:50 +07:00
void intel_fbc_post_update ( struct intel_atomic_state * state ,
struct intel_crtc * crtc )
2015-07-03 05:25:10 +07:00
{
2016-07-04 17:34:36 +07:00
struct drm_i915_private * dev_priv = to_i915 ( crtc - > base . dev ) ;
2019-12-13 20:34:50 +07:00
struct intel_plane * plane = to_intel_plane ( crtc - > base . primary ) ;
const struct intel_plane_state * plane_state =
intel_atomic_get_new_plane_state ( state , plane ) ;
2016-01-12 02:44:36 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
2015-10-14 05:13:25 +07:00
2019-12-13 20:34:51 +07:00
if ( ! plane - > has_fbc | | ! plane_state )
2019-12-13 20:34:50 +07:00
return ;
2016-01-12 02:44:36 +07:00
mutex_lock ( & fbc - > lock ) ;
2016-01-19 20:35:44 +07:00
__intel_fbc_post_update ( crtc ) ;
2016-01-12 02:44:36 +07:00
mutex_unlock ( & fbc - > lock ) ;
2014-12-08 23:09:10 +07:00
}
2016-01-19 20:35:40 +07:00
static unsigned int intel_fbc_get_frontbuffer_bit ( struct intel_fbc * fbc )
{
2019-11-28 03:12:18 +07:00
if ( fbc - > crtc )
2016-01-19 20:35:40 +07:00
return to_intel_plane ( fbc - > crtc - > base . primary ) - > frontbuffer_bit ;
else
return fbc - > possible_framebuffer_bits ;
}
2015-02-14 02:23:46 +07:00
void intel_fbc_invalidate ( struct drm_i915_private * dev_priv ,
unsigned int frontbuffer_bits ,
enum fb_op_origin origin )
{
2016-01-12 02:44:36 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
2015-02-14 02:23:46 +07:00
2019-12-13 20:34:51 +07:00
if ( ! HAS_FBC ( dev_priv ) )
2015-07-04 01:40:54 +07:00
return ;
2016-01-19 20:35:39 +07:00
if ( origin = = ORIGIN_GTT | | origin = = ORIGIN_FLIP )
2015-02-14 02:23:46 +07:00
return ;
2016-01-12 02:44:36 +07:00
mutex_lock ( & fbc - > lock ) ;
2015-07-03 05:25:10 +07:00
2016-01-19 20:35:40 +07:00
fbc - > busy_bits | = intel_fbc_get_frontbuffer_bit ( fbc ) & frontbuffer_bits ;
2015-02-14 02:23:46 +07:00
2019-11-28 03:12:18 +07:00
if ( fbc - > crtc & & fbc - > busy_bits )
2018-01-26 05:41:22 +07:00
intel_fbc_deactivate ( dev_priv , " frontbuffer write " ) ;
2015-07-03 05:25:10 +07:00
2016-01-12 02:44:36 +07:00
mutex_unlock ( & fbc - > lock ) ;
2015-02-14 02:23:46 +07:00
}
void intel_fbc_flush ( struct drm_i915_private * dev_priv ,
2015-07-15 02:29:10 +07:00
unsigned int frontbuffer_bits , enum fb_op_origin origin )
2015-02-14 02:23:46 +07:00
{
2016-01-12 02:44:36 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
2019-12-13 20:34:51 +07:00
if ( ! HAS_FBC ( dev_priv ) )
2015-07-04 01:40:54 +07:00
return ;
2016-01-12 02:44:36 +07:00
mutex_lock ( & fbc - > lock ) ;
2015-02-14 02:23:46 +07:00
2016-01-12 02:44:36 +07:00
fbc - > busy_bits & = ~ frontbuffer_bits ;
2015-02-14 02:23:46 +07:00
2016-04-05 04:17:15 +07:00
if ( origin = = ORIGIN_GTT | | origin = = ORIGIN_FLIP )
goto out ;
2019-11-28 03:12:18 +07:00
if ( ! fbc - > busy_bits & & fbc - > crtc & &
2016-01-19 20:35:40 +07:00
( frontbuffer_bits & intel_fbc_get_frontbuffer_bit ( fbc ) ) ) {
2016-01-19 20:35:39 +07:00
if ( fbc - > active )
2015-11-11 23:46:22 +07:00
intel_fbc_recompress ( dev_priv ) ;
2018-06-25 23:37:57 +07:00
else if ( ! fbc - > flip_pending )
2016-01-19 20:35:44 +07:00
__intel_fbc_post_update ( fbc - > crtc ) ;
2015-07-15 02:29:10 +07:00
}
2015-07-03 05:25:10 +07:00
2016-04-05 04:17:15 +07:00
out :
2016-01-12 02:44:36 +07:00
mutex_unlock ( & fbc - > lock ) ;
2015-02-14 02:23:46 +07:00
}
2016-01-19 20:35:50 +07:00
/**
* intel_fbc_choose_crtc - select a CRTC to enable FBC on
* @ dev_priv : i915 device instance
* @ state : the atomic state structure
*
* This function looks at the proposed state for CRTCs and planes , then chooses
* which pipe is going to have FBC by setting intel_crtc_state - > enable_fbc to
* true .
*
* Later , intel_fbc_enable is going to look for state - > enable_fbc and then maybe
* enable FBC for the chosen CRTC . If it does , it will set dev_priv - > fbc . crtc .
*/
void intel_fbc_choose_crtc ( struct drm_i915_private * dev_priv ,
2017-11-18 02:19:14 +07:00
struct intel_atomic_state * state )
2016-01-19 20:35:50 +07:00
{
struct intel_fbc * fbc = & dev_priv - > fbc ;
2017-11-18 02:19:14 +07:00
struct intel_plane * plane ;
struct intel_plane_state * plane_state ;
2016-11-11 23:57:39 +07:00
bool crtc_chosen = false ;
2016-11-11 23:57:36 +07:00
int i ;
2016-01-19 20:35:50 +07:00
mutex_lock ( & fbc - > lock ) ;
2016-11-11 23:57:39 +07:00
/* Does this atomic commit involve the CRTC currently tied to FBC? */
if ( fbc - > crtc & &
2017-11-18 02:19:14 +07:00
! intel_atomic_get_new_crtc_state ( state , fbc - > crtc ) )
2016-01-19 20:35:50 +07:00
goto out ;
2016-11-11 23:57:37 +07:00
if ( ! intel_fbc_can_enable ( dev_priv ) )
goto out ;
2016-01-19 20:35:50 +07:00
/* Simply choose the first CRTC that is compatible and has a visible
* plane . We could go for fancier schemes such as checking the plane
* size , but this would just affect the few platforms that don ' t tie FBC
* to pipe or plane A . */
2017-11-18 02:19:14 +07:00
for_each_new_intel_plane_in_state ( state , plane , plane_state , i ) {
struct intel_crtc_state * crtc_state ;
2019-10-31 18:26:07 +07:00
struct intel_crtc * crtc = to_intel_crtc ( plane_state - > hw . crtc ) ;
2016-01-19 20:35:50 +07:00
2018-02-22 00:31:01 +07:00
if ( ! plane - > has_fbc )
2016-01-19 20:35:50 +07:00
continue ;
2019-10-31 18:26:08 +07:00
if ( ! plane_state - > uapi . visible )
2016-11-11 23:57:35 +07:00
continue ;
2017-11-18 02:19:14 +07:00
crtc_state = intel_atomic_get_new_crtc_state ( state , crtc ) ;
2016-01-19 20:35:50 +07:00
2017-11-18 02:19:14 +07:00
crtc_state - > enable_fbc = true ;
2016-11-11 23:57:38 +07:00
crtc_chosen = true ;
2016-11-11 23:57:36 +07:00
break ;
2016-01-19 20:35:50 +07:00
}
2016-11-11 23:57:38 +07:00
if ( ! crtc_chosen )
fbc - > no_fbc_reason = " no suitable CRTC for FBC " ;
2016-01-19 20:35:50 +07:00
out :
mutex_unlock ( & fbc - > lock ) ;
}
2015-10-15 20:44:46 +07:00
/**
* intel_fbc_enable : tries to enable FBC on the CRTC
* @ crtc : the CRTC
2020-01-27 02:56:54 +07:00
* @ state : corresponding & drm_crtc_state for @ crtc
2015-10-15 20:44:46 +07:00
*
2016-01-19 20:35:50 +07:00
* This function checks if the given CRTC was chosen for FBC , then enables it if
2016-01-19 20:35:52 +07:00
* possible . Notice that it doesn ' t activate FBC . It is valid to call
* intel_fbc_enable multiple times for the same pipe without an
* intel_fbc_disable in the middle , as long as it is deactivated .
2015-10-15 20:44:46 +07:00
*/
2019-12-13 20:34:50 +07:00
void intel_fbc_enable ( struct intel_atomic_state * state ,
struct intel_crtc * crtc )
2015-10-15 20:44:46 +07:00
{
2016-07-04 17:34:36 +07:00
struct drm_i915_private * dev_priv = to_i915 ( crtc - > base . dev ) ;
2019-12-13 20:34:50 +07:00
struct intel_plane * plane = to_intel_plane ( crtc - > base . primary ) ;
const struct intel_crtc_state * crtc_state =
intel_atomic_get_new_crtc_state ( state , crtc ) ;
const struct intel_plane_state * plane_state =
intel_atomic_get_new_plane_state ( state , plane ) ;
2016-01-12 02:44:36 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
2019-11-28 03:12:13 +07:00
struct intel_fbc_state_cache * cache = & fbc - > state_cache ;
2015-10-15 20:44:46 +07:00
2019-12-13 20:34:51 +07:00
if ( ! plane - > has_fbc | | ! plane_state )
2019-12-13 20:34:50 +07:00
return ;
2016-01-12 02:44:36 +07:00
mutex_lock ( & fbc - > lock ) ;
2015-10-15 20:44:46 +07:00
2019-11-28 03:12:18 +07:00
if ( fbc - > crtc ) {
2019-11-28 03:12:22 +07:00
if ( fbc - > crtc ! = crtc | |
! intel_fbc_cfb_size_changed ( dev_priv ) )
goto out ;
2015-10-15 20:44:46 +07:00
2019-11-28 03:12:22 +07:00
__intel_fbc_disable ( dev_priv ) ;
}
2016-01-19 20:35:50 +07:00
drm/i915/display/fbc: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128181603.27767-11-pankaj.laxminarayan.bharadiya@intel.com
2020-01-29 01:15:52 +07:00
drm_WARN_ON ( & dev_priv - > drm , fbc - > active ) ;
2015-10-15 20:44:46 +07:00
2016-06-14 19:24:20 +07:00
intel_fbc_update_state_cache ( crtc , crtc_state , plane_state ) ;
2019-11-28 03:12:13 +07:00
/* FIXME crtc_state->enable_fbc lies :( */
if ( ! cache - > plane . visible )
goto out ;
if ( intel_fbc_alloc_cfb ( dev_priv ,
intel_fbc_calculate_cfb_size ( dev_priv , cache ) ,
2019-12-13 20:34:50 +07:00
plane_state - > hw . fb - > format - > cpp [ 0 ] ) ) {
2019-11-28 03:12:22 +07:00
cache - > plane . visible = false ;
drm/i915/fbc: don't print no_fbc_reason to dmesg
Our dmesg messages started being misleading after we converted to the
enable+activate model: we always print "Disabling FBC", even when
we're just deactivating it. So, for example, when I boot my machine
and do "dmesg | grep -i fbc", I see:
[drm:intel_fbc_enable] Enabling FBC on pipe A
[drm:set_no_fbc_reason] Disabling FBC: framebuffer not tiled or fenced
but then, if I read the debugfs file, I will see:
$ sudo cat i915_fbc_status
FBC enabled
Compressing: yes
so we can conclude that dmesg is misleading, since FBC is actually
enabled. What happened is that we deactivated FBC due to fbcon not
being tiled, but when we silently reactivated it when the display
manager started. We don't print activation messages since there may be
way too many of these operations per second during normal desktop
usage.
One possible solution would be to change set_no_fbc_reason to
correctly differentiate between disable and deactivation, but we
removed support from printing activation/deactivation messages in the
past because they were too frequent. So instead of doing this, let's
just not print anything on dmesg, and leave the debugfs file if the
user needs to investigate something. We already print when we enable
and disable FBC anyway on a given pipe, so this should already help
triaging bugs.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-22-git-send-email-paulo.r.zanoni@intel.com
2016-01-19 20:35:54 +07:00
fbc - > no_fbc_reason = " not enough stolen memory " ;
drm/i915: alloc/free the FBC CFB during enable/disable
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.
I thought about three different approaches to solve this, and they all
have downsides.
The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.
The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
disable and other calls in the middle of the wait.
Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.
The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow - see
igt's kms_frontbuffer_tracking test, fbc-stridechange subtest. It
could be possible to implement a way to free+alloc the CFB during said
stride change, but it would involve a lot of book-keeping - exactly as
mentioned above - just for on case, so for now I'll keep it simple and
just deactivate FBC. Besides, we may not even need to disable FBC
since we do CFB over-allocation.
Note from Chris: "Starting a fullscreen client that covers a single
monitor in a multi-monitor setup will trigger a change in stride on
one of the CRTCs (the monitors will be flipped independently).". It
shouldn't be a huge problem if we lose FBC on multi-monitor setups
since these setups already have problems reaching deep PC states
anyway.
v2: Rebase after changing the patch order.
v3:
- Remove references to the stride change case being "uncommon" and
paste Chris' example.
- Rebase after a change in a previous patch.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/
2015-10-16 00:19:21 +07:00
goto out ;
}
2019-11-28 03:12:17 +07:00
if ( ( IS_GEN9_BC ( dev_priv ) | | IS_BROXTON ( dev_priv ) ) & &
2019-12-13 20:34:50 +07:00
plane_state - > hw . fb - > modifier ! = I915_FORMAT_MOD_X_TILED )
2019-11-28 03:12:13 +07:00
cache - > gen9_wa_cfb_stride =
DIV_ROUND_UP ( cache - > plane . src_w , 32 * fbc - > threshold ) * 8 ;
else
cache - > gen9_wa_cfb_stride = 0 ;
drm/i915/fbc: convert to drm_device based logging macros.
This replaces the uses of the printk based drm logging macros with the
struct drm_device based logging macros in i915/display/intel_fbc.c.
This transformation was done using the following coccinelle semantic
patch that matches based on the existence of a drm_i915_private device
pointer:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
New checkpatch warnings were addressed manually.
v2 by Jani:
- also convert pr_info_once to drm based logging
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Wambui Karuga <wambui.karugax@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/32a92f1d4e4d01131605b17bec831517e39c5902.1583766715.git.jani.nikula@intel.com
2020-03-10 15:52:41 +07:00
drm_dbg_kms ( & dev_priv - > drm , " Enabling FBC on pipe %c \n " ,
pipe_name ( crtc - > pipe ) ) ;
2016-01-12 02:44:36 +07:00
fbc - > no_fbc_reason = " FBC enabled but not active yet \n " ;
2015-10-15 20:44:46 +07:00
2016-01-12 02:44:36 +07:00
fbc - > crtc = crtc ;
2015-10-15 20:44:46 +07:00
out :
2016-01-12 02:44:36 +07:00
mutex_unlock ( & fbc - > lock ) ;
2015-10-15 20:44:46 +07:00
}
/**
2016-01-19 20:35:46 +07:00
* intel_fbc_disable - disable FBC if it ' s associated with crtc
2015-10-15 20:44:46 +07:00
* @ crtc : the CRTC
*
* This function disables FBC if it ' s associated with the provided CRTC .
*/
2016-01-19 20:35:46 +07:00
void intel_fbc_disable ( struct intel_crtc * crtc )
2015-10-15 20:44:46 +07:00
{
2016-07-04 17:34:36 +07:00
struct drm_i915_private * dev_priv = to_i915 ( crtc - > base . dev ) ;
2019-12-13 20:34:51 +07:00
struct intel_plane * plane = to_intel_plane ( crtc - > base . primary ) ;
2016-01-12 02:44:36 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
2015-10-15 20:44:46 +07:00
2019-12-13 20:34:51 +07:00
if ( ! plane - > has_fbc )
2015-10-15 20:44:46 +07:00
return ;
2016-01-12 02:44:36 +07:00
mutex_lock ( & fbc - > lock ) ;
2016-07-05 16:28:34 +07:00
if ( fbc - > crtc = = crtc )
2015-10-15 20:44:46 +07:00
__intel_fbc_disable ( dev_priv ) ;
2016-01-12 02:44:36 +07:00
mutex_unlock ( & fbc - > lock ) ;
2015-10-15 20:44:46 +07:00
}
/**
2016-01-19 20:35:46 +07:00
* intel_fbc_global_disable - globally disable FBC
2015-10-15 20:44:46 +07:00
* @ dev_priv : i915 device instance
*
* This function disables FBC regardless of which CRTC is associated with it .
*/
2016-01-19 20:35:46 +07:00
void intel_fbc_global_disable ( struct drm_i915_private * dev_priv )
2015-10-15 20:44:46 +07:00
{
2016-01-12 02:44:36 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
2019-12-13 20:34:51 +07:00
if ( ! HAS_FBC ( dev_priv ) )
2015-10-15 20:44:46 +07:00
return ;
2016-01-12 02:44:36 +07:00
mutex_lock ( & fbc - > lock ) ;
2019-11-28 03:12:18 +07:00
if ( fbc - > crtc ) {
drm/i915/display/fbc: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128181603.27767-11-pankaj.laxminarayan.bharadiya@intel.com
2020-01-29 01:15:52 +07:00
drm_WARN_ON ( & dev_priv - > drm , fbc - > crtc - > active ) ;
2015-10-15 20:44:46 +07:00
__intel_fbc_disable ( dev_priv ) ;
2018-03-05 19:36:08 +07:00
}
2016-01-12 02:44:36 +07:00
mutex_unlock ( & fbc - > lock ) ;
2015-10-15 20:44:46 +07:00
}
2016-09-13 20:38:57 +07:00
static void intel_fbc_underrun_work_fn ( struct work_struct * work )
{
struct drm_i915_private * dev_priv =
container_of ( work , struct drm_i915_private , fbc . underrun_work ) ;
struct intel_fbc * fbc = & dev_priv - > fbc ;
mutex_lock ( & fbc - > lock ) ;
/* Maybe we were scheduled twice. */
2019-11-28 03:12:18 +07:00
if ( fbc - > underrun_detected | | ! fbc - > crtc )
2016-09-13 20:38:57 +07:00
goto out ;
drm/i915/fbc: convert to drm_device based logging macros.
This replaces the uses of the printk based drm logging macros with the
struct drm_device based logging macros in i915/display/intel_fbc.c.
This transformation was done using the following coccinelle semantic
patch that matches based on the existence of a drm_i915_private device
pointer:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
New checkpatch warnings were addressed manually.
v2 by Jani:
- also convert pr_info_once to drm based logging
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Wambui Karuga <wambui.karugax@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/32a92f1d4e4d01131605b17bec831517e39c5902.1583766715.git.jani.nikula@intel.com
2020-03-10 15:52:41 +07:00
drm_dbg_kms ( & dev_priv - > drm , " Disabling FBC due to FIFO underrun. \n " ) ;
2016-09-13 20:38:57 +07:00
fbc - > underrun_detected = true ;
2018-01-26 05:41:22 +07:00
intel_fbc_deactivate ( dev_priv , " FIFO underrun " ) ;
2016-09-13 20:38:57 +07:00
out :
mutex_unlock ( & fbc - > lock ) ;
}
2018-03-28 17:05:26 +07:00
/*
* intel_fbc_reset_underrun - reset FBC fifo underrun status .
* @ dev_priv : i915 device instance
*
* See intel_fbc_handle_fifo_underrun_irq ( ) . For automated testing we
* want to re - enable FBC after an underrun to increase test coverage .
*/
int intel_fbc_reset_underrun ( struct drm_i915_private * dev_priv )
{
int ret ;
cancel_work_sync ( & dev_priv - > fbc . underrun_work ) ;
ret = mutex_lock_interruptible ( & dev_priv - > fbc . lock ) ;
if ( ret )
return ret ;
if ( dev_priv - > fbc . underrun_detected ) {
drm/i915/fbc: convert to drm_device based logging macros.
This replaces the uses of the printk based drm logging macros with the
struct drm_device based logging macros in i915/display/intel_fbc.c.
This transformation was done using the following coccinelle semantic
patch that matches based on the existence of a drm_i915_private device
pointer:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
New checkpatch warnings were addressed manually.
v2 by Jani:
- also convert pr_info_once to drm based logging
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Wambui Karuga <wambui.karugax@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/32a92f1d4e4d01131605b17bec831517e39c5902.1583766715.git.jani.nikula@intel.com
2020-03-10 15:52:41 +07:00
drm_dbg_kms ( & dev_priv - > drm ,
" Re-allowing FBC after fifo underrun \n " ) ;
2018-03-28 17:05:26 +07:00
dev_priv - > fbc . no_fbc_reason = " FIFO underrun cleared " ;
}
dev_priv - > fbc . underrun_detected = false ;
mutex_unlock ( & dev_priv - > fbc . lock ) ;
return 0 ;
}
2016-09-13 20:38:57 +07:00
/**
* intel_fbc_handle_fifo_underrun_irq - disable FBC when we get a FIFO underrun
* @ dev_priv : i915 device instance
*
* Without FBC , most underruns are harmless and don ' t really cause too many
* problems , except for an annoying message on dmesg . With FBC , underruns can
* become black screens or even worse , especially when paired with bad
* watermarks . So in order for us to be on the safe side , completely disable FBC
* in case we ever detect a FIFO underrun on any pipe . An underrun on any pipe
* already suggests that watermarks may be bad , so try to be as safe as
* possible .
*
* This function is called from the IRQ handler .
*/
void intel_fbc_handle_fifo_underrun_irq ( struct drm_i915_private * dev_priv )
{
struct intel_fbc * fbc = & dev_priv - > fbc ;
2019-12-13 20:34:51 +07:00
if ( ! HAS_FBC ( dev_priv ) )
2016-09-13 20:38:57 +07:00
return ;
/* There's no guarantee that underrun_detected won't be set to true
* right after this check and before the work is scheduled , but that ' s
* not a problem since we ' ll check it again under the work function
* while FBC is locked . This check here is just to prevent us from
* unnecessarily scheduling the work , and it relies on the fact that we
* never switch underrun_detect back to false after it ' s true . */
if ( READ_ONCE ( fbc - > underrun_detected ) )
return ;
schedule_work ( & fbc - > underrun_work ) ;
}
2016-04-14 02:01:09 +07:00
/*
* The DDX driver changes its behavior depending on the value it reads from
* i915 . enable_fbc , so sanitize it by translating the default value into either
* 0 or 1 in order to allow it to know what ' s going on .
*
* Notice that this is done at driver initialization and we still allow user
* space to change the value during runtime without sanitizing it again . IGT
* relies on being able to change i915 . enable_fbc at runtime .
*/
static int intel_sanitize_fbc_option ( struct drm_i915_private * dev_priv )
{
2020-06-18 22:04:02 +07:00
if ( dev_priv - > params . enable_fbc > = 0 )
return ! ! dev_priv - > params . enable_fbc ;
2016-04-14 02:01:09 +07:00
2016-08-04 14:43:53 +07:00
if ( ! HAS_FBC ( dev_priv ) )
return 0 ;
2016-12-23 19:23:58 +07:00
if ( IS_BROADWELL ( dev_priv ) | | INTEL_GEN ( dev_priv ) > = 9 )
2016-04-14 02:01:09 +07:00
return 1 ;
return 0 ;
}
2016-08-04 14:43:53 +07:00
static bool need_fbc_vtd_wa ( struct drm_i915_private * dev_priv )
{
/* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt */
2017-05-25 19:16:12 +07:00
if ( intel_vtd_active ( ) & &
2016-08-04 14:43:53 +07:00
( IS_SKYLAKE ( dev_priv ) | | IS_BROXTON ( dev_priv ) ) ) {
drm/i915/fbc: convert to drm_device based logging macros.
This replaces the uses of the printk based drm logging macros with the
struct drm_device based logging macros in i915/display/intel_fbc.c.
This transformation was done using the following coccinelle semantic
patch that matches based on the existence of a drm_i915_private device
pointer:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
New checkpatch warnings were addressed manually.
v2 by Jani:
- also convert pr_info_once to drm based logging
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Wambui Karuga <wambui.karugax@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/32a92f1d4e4d01131605b17bec831517e39c5902.1583766715.git.jani.nikula@intel.com
2020-03-10 15:52:41 +07:00
drm_info ( & dev_priv - > drm ,
" Disabling framebuffer compression (FBC) to prevent screen flicker with VT-d enabled \n " ) ;
2016-08-04 14:43:53 +07:00
return true ;
}
return false ;
}
2014-12-08 21:46:31 +07:00
/**
* intel_fbc_init - Initialize FBC
* @ dev_priv : the i915 device
*
* This function might be called during PM init process .
*/
2014-12-08 23:09:10 +07:00
void intel_fbc_init ( struct drm_i915_private * dev_priv )
{
2016-01-12 02:44:36 +07:00
struct intel_fbc * fbc = & dev_priv - > fbc ;
2015-02-14 02:23:46 +07:00
2016-09-13 20:38:57 +07:00
INIT_WORK ( & fbc - > underrun_work , intel_fbc_underrun_work_fn ) ;
2016-01-12 02:44:36 +07:00
mutex_init ( & fbc - > lock ) ;
fbc - > active = false ;
2015-07-03 05:25:10 +07:00
2019-09-12 00:59:26 +07:00
if ( ! drm_mm_initialized ( & dev_priv - > mm . stolen ) )
mkwrite_device_info ( dev_priv ) - > display . has_fbc = false ;
2016-08-04 14:43:53 +07:00
if ( need_fbc_vtd_wa ( dev_priv ) )
2018-12-01 06:20:48 +07:00
mkwrite_device_info ( dev_priv ) - > display . has_fbc = false ;
2016-08-04 14:43:53 +07:00
2020-06-18 22:04:02 +07:00
dev_priv - > params . enable_fbc = intel_sanitize_fbc_option ( dev_priv ) ;
drm/i915/fbc: convert to drm_device based logging macros.
This replaces the uses of the printk based drm logging macros with the
struct drm_device based logging macros in i915/display/intel_fbc.c.
This transformation was done using the following coccinelle semantic
patch that matches based on the existence of a drm_i915_private device
pointer:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}
New checkpatch warnings were addressed manually.
v2 by Jani:
- also convert pr_info_once to drm based logging
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Wambui Karuga <wambui.karugax@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/32a92f1d4e4d01131605b17bec831517e39c5902.1583766715.git.jani.nikula@intel.com
2020-03-10 15:52:41 +07:00
drm_dbg_kms ( & dev_priv - > drm , " Sanitized enable_fbc value: %d \n " ,
2020-06-18 22:04:02 +07:00
dev_priv - > params . enable_fbc ) ;
2016-04-14 02:01:09 +07:00
2014-12-08 23:09:10 +07:00
if ( ! HAS_FBC ( dev_priv ) ) {
2016-01-12 02:44:36 +07:00
fbc - > no_fbc_reason = " unsupported by this chipset " ;
2014-12-08 23:09:10 +07:00
return ;
}
2016-01-30 03:57:39 +07:00
/* This value was pulled out of someone's hat */
2016-11-11 23:57:41 +07:00
if ( INTEL_GEN ( dev_priv ) < = 4 & & ! IS_GM45 ( dev_priv ) )
drm/i915/fbc: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com
2020-01-24 20:25:37 +07:00
intel_de_write ( dev_priv , FBC_CONTROL ,
500 < < FBC_CTL_INTERVAL_SHIFT ) ;
2014-12-08 23:09:10 +07:00
2015-11-05 02:10:52 +07:00
/* We still don't have any sort of hardware state readout for FBC, so
2015-10-15 03:45:36 +07:00
* deactivate it in case the BIOS activated it to make sure software
* matches the hardware state . */
2016-01-30 03:57:39 +07:00
if ( intel_fbc_hw_is_active ( dev_priv ) )
intel_fbc_hw_deactivate ( dev_priv ) ;
2014-12-08 23:09:10 +07:00
}