== Series Details ==
Series: drm/i915/gem: Remove stolen node before releasing the region
URL : https://patchwork.freedesktop.org/series/85727/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9585_full -> Patchwork_19320_full
== Series Details ==
Series: drm/i915/selftests: Allow huge_gem_object to kick the shrinker
URL : https://patchwork.freedesktop.org/series/85729/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9586 -> Patchwork_19321
On Mon, 2021-01-11 at 13:41 +0530, Anshuman Gupta wrote:
> Add support for multiple mst stream in hdcp port data
> which will be used by RepeaterAuthStreamManage msg and
> HDCP 2.2 security f/w for m' validation.
>
> Security f/w doesn't have any provision to mark the stream_type
> for each
== Series Details ==
Series: drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr
4:4:4 (rev2)
URL : https://patchwork.freedesktop.org/series/85715/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9585_full -> Patchwork_19319_full
On Fri, Dec 04, 2020 at 05:08:33PM -0800, Aditya Swarup wrote:
> ADL-S requires TC pins to set up ddc for Combo PHY B, C, D and E.
> Combo PHY A still uses the old ddc pin mapping.
>
> From VBT, ddc pin info suggests the following mapping:
> VBT DRIVER
> DDI
On Fri, Dec 04, 2020 at 05:08:34PM -0800, Aditya Swarup wrote:
> - ADL-S driver internal mapping uses PORT D, E, F, G for Combo phy B, C, D
> and E.
> - Add ADLS specific port mappings for vbt port dvo settings.
> - Select appropriate AUX CH specific to ADLS based on port mapping.
The aux stuff
On Fri, Dec 04, 2020 at 05:08:32PM -0800, Aditya Swarup wrote:
> Initialize display outputs for ADL-S. ADL-S has 5 display
> outputs -> 1 eDP, 2 HDMI and 2 DP++ outputs.
>
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Imre Deak
> Cc: Matt Roper
> Cc: Lucas De Marchi
> Signed-off-by: Aditya
On Fri, Dec 04, 2020 at 05:08:30PM -0800, Aditya Swarup wrote:
> Add changes for configuring DPLL for ADL-S
> - Reusing DG1 DPLL 2 & DPLL 3 for ADL-S
> - Extend CNL macro to choose DPLL_ENABLE
> for ADL-S.
> - Select CFGCR0 and CFGCR1 for ADL-S plls.
>
> On BSpec: 53720 PLL arrangement dig for
On Mon, Jan 11, 2021 at 05:30:00PM -0800, Matt Roper wrote:
On Mon, Jan 11, 2021 at 07:21:55PM -0500, Rodrigo Vivi wrote:
On Fri, Jan 08, 2021 at 05:39:22PM +0530, Tejas Upadhyay wrote:
> We have TGP PCH support for Tigerlake and Rocketlake. Similarly
> now TGP PCH can be used with Cometlake
On Fri, Dec 04, 2020 at 05:08:29PM -0800, Aditya Swarup wrote:
> From: Anusha Srivatsa
>
> Alderlake-S has 5 combo phys, add reg definitions for
> combo phys and update the port to phy helper for ADL-S.
>
> v2:
> - Change IS_GEN() >= 12 to IS_TIGERLAKE() in intel_phy_is_tc()
> and return false
== Series Details ==
Series: drm/i915/gem: Remove stolen node before releasing the region
URL : https://patchwork.freedesktop.org/series/85727/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9585 -> Patchwork_19320
Summary
== Series Details ==
Series: drm/i915/gem: Remove stolen node before releasing the region
URL : https://patchwork.freedesktop.org/series/85727/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
23d74dcb0825 drm/i915/gem: Remove stolen node before releasing the region
-:10:
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/gt: Limit VFE threads based on GT
URL : https://patchwork.freedesktop.org/series/85726/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9584_full -> Patchwork_19318_full
On Mon, Jan 11, 2021 at 10:13:15PM +0200, Jani Nikula wrote:
On Fri, 08 Jan 2021, Matt Roper wrote:
On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup wrote:
TGL adds another level of indirection for applying WA based on stepping
information rather than PCI REVID. So change TGL_REVID
A new fi-cml-dallium CI machine has 8G and apparently plenty free, yet
fails some selftests with ENOMEM. The failures all seem to be from
huge_gem_object which does not try very hard to allocate memory,
skipping reclaim entirely. Let's try a bit harder and direct reclaim
before failing.
== Series Details ==
Series: drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr
4:4:4 (rev2)
URL : https://patchwork.freedesktop.org/series/85715/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9585 -> Patchwork_19319
If this stolen object holds the last reference to the region, we need to
remove our drm_mm_node before freeing the region's drm_mm.
<4> [431.679591] Memory manager not clean during takedown.
<4> [431.679633] WARNING: CPU: 0 PID: 110 at drivers/gpu/drm/drm_mm.c:999
drm_mm_takedown+0x51/0x100
<4>
On Mon, Jan 11, 2021 at 07:21:55PM -0500, Rodrigo Vivi wrote:
> On Fri, Jan 08, 2021 at 05:39:22PM +0530, Tejas Upadhyay wrote:
> > We have TGP PCH support for Tigerlake and Rocketlake. Similarly
> > now TGP PCH can be used with Cometlake CPU.
> >
> > Changes since V3 :
> > - Rebased to top
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/gt: Limit VFE threads based on GT
URL : https://patchwork.freedesktop.org/series/85726/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9584 -> Patchwork_19318
On Fri, Jan 08, 2021 at 05:39:22PM +0530, Tejas Upadhyay wrote:
> We have TGP PCH support for Tigerlake and Rocketlake. Similarly
> now TGP PCH can be used with Cometlake CPU.
>
> Changes since V3 :
> - Rebased to top drm-tip commit
> - dev_priv replaced with i915 for new API
>
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/gt: Limit VFE threads based on GT
URL : https://patchwork.freedesktop.org/series/85726/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e2979c887600 drm/i915/gt: Limit VFE threads based on GT
5c4e9fc2dcd5
Hi Rodrigo,
Quoted from Joonas at
https://patchwork.freedesktop.org/patch/412397/?series=84620=19
" Generally the trend on the GT side is to contain in a .c file if there are
no shared users like these. So they should be at this spot, yet the rest
of the review comments apply."
So I think the
On 1/11/21 12:57 PM, Matt Roper wrote:
> On Mon, Jan 11, 2021 at 10:18:45PM +0200, Jani Nikula wrote:
>> On Mon, 11 Jan 2021, Jani Nikula wrote:
>>> On Fri, 08 Jan 2021, Matt Roper wrote:
On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup wrote:
> TGL adds another level of
The clear-residuals mitigation is a relatively heavy hammer and under some
circumstances the user may wish to forgo the context isolation in order
to meet some performance requirement. Introduce a generic module
parameter to allow selectively enabling/disabling different mitigations.
To disable
The mitigation is required for all gen7 platforms, now that it does not
cause GPU hangs, restore it for Ivybridge and Baytrail.
Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Prathap Kumar Valsan
Cc: Akeem G Abodunrin
MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the
range [0, n-1] where n is #EU * (#threads/EU) with the number of threads
based on plaform and the number of EU based on the number of slices and
subslices. This is a fixed number per platform/gt, so appropriately
limit the number
Hi Rodrigo,
I removed the debug print print_hex_dump() in this patch, this change will
reflect at rev20.
Regarding to the Chris's question for mutex, actually what I'm doing the
similar with the existing hdcp_comp_added and hdcp_comp_mutex in
== Series Details ==
Series: Use TGL stepping info and add ADLS platform changes (rev2)
URL : https://patchwork.freedesktop.org/series/85639/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9581_full -> Patchwork_19317_full
Hi Rodrigo,
Regarding to Chris comment in v4:
>> +config DRM_I915_PXP
>> + bool "Enable Intel PXP support for Intel Gen12+ platform"
>> + depends on DRM_I915
>> + select INTEL_MEI_PXP
>
>Doesn't exist.
>
>Kconfig dependency resolution is not recursive; you probably will need a
Quoting Tvrtko Ursulin (2021-01-11 17:12:57)
>
> On 11/01/2021 16:27, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2021-01-11 16:19:40)
> >>
> >> On 11/01/2021 10:57, Chris Wilson wrote:
> >>> During igt_reset_nop_engine, it was observed that an unexpected failed
> >>> engine reset lead to us
Hello,
I see, based on Joonas and Rodrigo's feedback.
I made the modification as below, I will still keep the macro in this .c
instead of i915_reg.h, and this change will be reflected in rev20.
/* KCR register definitions */
#define KCR_INIT_MMIO(0x320f0)
-#define
On Mon, Jan 11, 2021 at 11:39 AM Bas Nieuwenhuizen
wrote:
>
> On Mon, Jan 11, 2021 at 4:02 PM Alex Deucher wrote:
> >
> > On Sat, Jan 9, 2021 at 9:11 PM Bas Nieuwenhuizen
> > wrote:
> > >
> > > With modifiers one can actually have different format_info structs
> > > for the same format, which
On Mon, Jan 11, 2021 at 12:57:43PM -0800, Matt Roper wrote:
On Mon, Jan 11, 2021 at 10:18:45PM +0200, Jani Nikula wrote:
On Mon, 11 Jan 2021, Jani Nikula wrote:
> On Fri, 08 Jan 2021, Matt Roper wrote:
>> On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup wrote:
>>> TGL adds another
Quoting Abodunrin, Akeem G (2021-01-11 20:58:42)
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of Chris
> > Wilson
> > Sent: Sunday, January 10, 2021 7:04 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: sta...@vger.kernel.org; Chris Wilson
> > Subject: [Intel-gfx] [PATCH
> -Original Message-
> From: Chris Wilson
> Sent: Monday, January 11, 2021 1:03 PM
> To: Abodunrin, Akeem G ; intel-
> g...@lists.freedesktop.org
> Cc: stable@ ; Randy Wright
>
> Subject: Re: [Intel-gfx] [PATCH 1/3] drm/i915/gt: Limit VFE threads based on
> GT
>
> Quoting Abodunrin,
On Mon, Jan 11, 2021 at 08:51:23PM +, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2021-01-11 17:35:12)
> > On Sun, Jan 10, 2021 at 03:03:54PM +, Chris Wilson wrote:
> > > MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the
> > > range [0, n-1] where n is #EU * (#threads/EU)
Quoting Abodunrin, Akeem G (2021-01-11 20:25:34)
> > static void
> > batch_get_defaults(struct drm_i915_private *i915, struct batch_vals *bv) {
> > if (IS_HASWELL(i915)) {
> > - bv->max_primitives = 280;
> > - bv->max_urb_entries = MAX_URB_ENTRIES;
> > +
> -Original Message-
> From: Intel-gfx On Behalf Of Chris
> Wilson
> Sent: Sunday, January 10, 2021 7:04 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: sta...@vger.kernel.org; Chris Wilson
> Subject: [Intel-gfx] [PATCH 03/11] drm/i915: Allow the sysadmin to override
> security
On Mon, Jan 11, 2021 at 10:18:45PM +0200, Jani Nikula wrote:
> On Mon, 11 Jan 2021, Jani Nikula wrote:
> > On Fri, 08 Jan 2021, Matt Roper wrote:
> >> On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup wrote:
> >>> TGL adds another level of indirection for applying WA based on stepping
>
On Wed, 6 Jan 2021 at 01:46, Maarten Lankhorst
wrote:
>
> Instead of doing what we do currently, which will never work with
> PROVE_LOCKING, do the same as AMD does, and something similar to
> relocation slowpath. When all locks are dropped, we acquire the
> pages for pinning. When the locks are
Quoting Rodrigo Vivi (2021-01-11 17:35:12)
> On Sun, Jan 10, 2021 at 03:03:54PM +, Chris Wilson wrote:
> > MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the
> > range [0, n-1] where n is #EU * (#threads/EU) with the number of threads
> > based on plaform and the number of EU
Acked-by: Dave Airlie
burn with the fire.
Dave.
On Wed, 6 Jan 2021 at 01:46, Maarten Lankhorst
wrote:
>
> We should not allow this any more, as it will break with the new userptr
> implementation, it could still be made to work, but there's no point in
> doing so.
>
> Inspection of the
> -Original Message-
> From: Chris Wilson
> Sent: Saturday, January 09, 2021 7:50 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Mika Kuoppala
> ; Kumar Valsan, Prathap
> ; Abodunrin, Akeem G
> ; Bloomfield, Jon
>
> Subject: [PATCH 2/3] drm/i915/gt: Restore
> -Original Message-
> From: Chris Wilson
> Sent: Saturday, January 09, 2021 7:49 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Mika Kuoppala
> ; Kumar Valsan, Prathap
> ; Abodunrin, Akeem G
> ; Bloomfield, Jon
> ; Vivi, Rodrigo ; Randy
> Wright ; sta...@vger.kernel.org
On 1/11/21 12:13 PM, Jani Nikula wrote:
> On Fri, 08 Jan 2021, Matt Roper wrote:
>> On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup wrote:
>>> TGL adds another level of indirection for applying WA based on stepping
>>> information rather than PCI REVID. So change TGL_REVID enum into
>>>
On Mon, 11 Jan 2021, Jani Nikula wrote:
> On Fri, 08 Jan 2021, Matt Roper wrote:
>> On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup wrote:
>>> TGL adds another level of indirection for applying WA based on stepping
>>> information rather than PCI REVID. So change TGL_REVID enum into
>>>
== Series Details ==
Series: Use TGL stepping info and add ADLS platform changes (rev2)
URL : https://patchwork.freedesktop.org/series/85639/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9581 -> Patchwork_19317
Summary
On Fri, 08 Jan 2021, Matt Roper wrote:
> On Fri, Jan 08, 2021 at 03:18:52PM -0800, Aditya Swarup wrote:
>> TGL adds another level of indirection for applying WA based on stepping
>> information rather than PCI REVID. So change TGL_REVID enum into
>> stepping enum and use PCI REVID as index into
== Series Details ==
Series: Use TGL stepping info and add ADLS platform changes (rev2)
URL : https://patchwork.freedesktop.org/series/85639/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5e2bd50d9a37 drm/i915/tgl: Use TGL stepping info for applying WAs
-:197:
On 1/8/21 4:20 PM, Matt Roper wrote:
> On Fri, Jan 08, 2021 at 03:18:53PM -0800, Aditya Swarup wrote:
>> From: Caz Yokoyama
>>
>> - Add the initial platform information for Alderlake-S.
>> - Specify ppgtt_size value
>> - Add dma_mask_size
>> - Add ADLS REVIDs
>> - HW tracking(Selective Update
v1:
1. Change TGL REVID enums/macros to TGL stepping info to apply TGL WAs.
2. Add ADL-S platform info and PCI IDs and add TGL style stepping macros
for applying WAs.
v2:
- Replace macros with PCI IDs based on Matt Roper's suggestion.
Aditya Swarup (1):
drm/i915/tgl: Use TGL stepping info
From: Caz Yokoyama
- Add the initial platform information for Alderlake-S.
- Specify ppgtt_size value
- Add dma_mask_size
- Add ADLS REVIDs
- HW tracking(Selective Update Tracking Enable) has been
removed from ADLS. Disable PSR2 till we enable software/
manual tracking.
v2:
- Add support
TGL adds another level of indirection for applying WA based on stepping
information rather than PCI REVID. So change TGL_REVID enum into
stepping enum and use PCI REVID as index into revid to stepping table to
fetch correct display and GT stepping for application of WAs as
suggested by Matt Roper.
On Mon, 11 Jan 2021, Jani Nikula wrote:
> On Fri, 08 Jan 2021, Lyude Paul wrote:
>> Reviewed-by: Lyude Paul
>>
>> Let me know when you've pushed this upstream and I'll go ahead and send out a
>> rebased version of my backlight series.
>
> Pushed, thanks for the review.
>
> I'm hoping to do more
On Mon, 11 Jan 2021, Jani Nikula wrote:
> On Thu, 07 Jan 2021, Lyude Paul wrote:
>> This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
>> these quirks were added because of the issues with using the eDP
>> backlight interfaces on certain laptop panels, which made it
On Thu, 07 Jan 2021, Lyude Paul wrote:
> This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
> these quirks were added because of the issues with using the eDP
> backlight interfaces on certain laptop panels, which made it impossible
> to properly probe for DPCD backlight
On Thu, 07 Jan 2021, Lyude Paul wrote:
> Since we now support controlling panel backlights through DPCD using
> both the standard VESA interface, and Intel's proprietary HDR backlight
> interface, we should allow the user to be able to explicitly choose
> between one or the other in the event
On Thu, 07 Jan 2021, Lyude Paul wrote:
> So-recently a bunch of laptops on the market have started using DPCD
> backlight controls instead of the traditional DDI backlight controls.
> Originally we thought we had this handled by adding VESA backlight
> control support to i915, but the story ended
On Thu, 07 Jan 2021, Lyude Paul wrote:
> Currently, every different type of backlight hook that i915 supports is
> pretty straight forward - you have a backlight, probably through PWM
> (but maybe DPCD), with a single set of platform-specific hooks that are
> used for controlling it.
>
> HDR
== Series Details ==
Series: drm/i915: Async flips for all ilk+ platforms (rev2)
URL : https://patchwork.freedesktop.org/series/85627/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9580_full -> Patchwork_19315_full
Summary
On Thu, Jan 07, 2021 at 08:20:25PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Some new eDP panels don't like to operate at the max parameters, and
> instead we need to go for an optimal confiugration. That unfortunately
> doesn't work with older eDP panels which are generally only
On Fri, 08 Jan 2021, Zhenyu Wang wrote:
> Hi,
>
> Here's one gvt fixes for VFIO edid on APL/BXT with virtual display
> hotplug fixed that feature is enabled again.
Thanks, merged to drm-intel-fixes.
BR,
Jani.
>
> Thanks.
> --
> The following changes since commit
== Series Details ==
Series: drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr
4:4:4
URL : https://patchwork.freedesktop.org/series/85715/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9580 -> Patchwork_19316
On Sun, Jan 10, 2021 at 03:03:56PM +, Chris Wilson wrote:
> The clear-residuals mitigation is a relatively heavy hammer and under some
> circumstances the user may wish to forgo the context isolation in order
> to meet some performance requirement. Introduce a generic module
> parameter to
On 1/8/21 2:25 PM, Matt Roper wrote:
DG1's vswing tables are the same for eDP and HDMI but have slight
differences from ICL/TGL for DP.
v2:
- Use a "_hbr2_hbr3" suffix on the table name to make it more clear
that the same table is used for both HBR2 and HBR3 link rates.
(Swathi)
On Sun, Jan 10, 2021 at 03:03:55PM +, Chris Wilson wrote:
> The mitigation is required for all gen7 platforms, now that it does not
> cause GPU hangs, restore it for Ivybridge and Baytrail.
>
> Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
> Signed-off-by: Chris
On Sun, Jan 10, 2021 at 03:03:54PM +, Chris Wilson wrote:
> MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the
> range [0, n-1] where n is #EU * (#threads/EU) with the number of threads
> based on plaform and the number of EU based on the number of slices and
> subslices. This
> -Original Message-
> From: Chris Wilson
> Sent: Sunday, January 10, 2021 7:04 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Joonas Lahtinen
> ; Bloomfield, Jon
> ; Vivi, Rodrigo ;
> sta...@vger.kernel.org
> Subject: [PATCH 03/11] drm/i915: Allow the sysadmin to override
== Series Details ==
Series: drm/i915: Async flips for all ilk+ platforms (rev2)
URL : https://patchwork.freedesktop.org/series/85627/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9580 -> Patchwork_19315
Summary
---
On 11/01/2021 16:27, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2021-01-11 16:19:40)
On 11/01/2021 10:57, Chris Wilson wrote:
During igt_reset_nop_engine, it was observed that an unexpected failed
engine reset lead to us busywaiting on the stop-ring semaphore (set
during the reset
From: Ville Syrjälä
Let's not enable the 4:4:4->4:2:0 conversion bit in the DFP unless we're
actually outputting YCbCr 4:4:4. It would appear some protocol
converters blindy consult this bit even when the source is outputting
RGB, resulting in a visual mess.
Closes:
On Mon, Jan 11, 2021 at 4:02 PM Alex Deucher wrote:
>
> On Sat, Jan 9, 2021 at 9:11 PM Bas Nieuwenhuizen
> wrote:
> >
> > With modifiers one can actually have different format_info structs
> > for the same format, which now matters for AMDGPU since we convert
> > implicit modifiers to explicit
From: Ville Syrjälä
Add support for async flips on vlv/chv. Unlike all the other
platforms vlv/chv do not use the async flip bit in DSPCNTR and
instead we select between async vs. sync flips based on the
surface address register. The normal DSPSURF generates sync
flips DSPADDR_VLV generates
From: Ville Syrjälä
Add support for async flips on ivb/hsw. Again no need for any
workarounds and just have to deal with the interrupt bits being
shuffled around a bit.
Cc: Karthik B S
Cc: Vandita Kulkarni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c| 24
From: Ville Syrjälä
Add support for async flips on ivb/hsw. Unlike bdw+ we don't need
any workarounds to disable async flips. Apart from that the only
real difference from the bdw implementation is the location of the
flip_done interrupt bits.
Cc: Karthik B S
Cc: Vandita Kulkarni
From: Ville Syrjälä
Only assign the plane->async_flip() vfunc when the plane supports
async flips. For now we keep this artificially limited to the primary
plane since thats the only thing the legacy page flip uapi can target
and there is no async flip support in the atomic uapi yet.
Cc:
From: Ville Syrjälä
Implement async flip support for BDW. The implementation is
similar to the skl+ code. And just like skl/bxt/glk bdw also
needs the disable w/a, thus we need to plumb the desired state
of the async flip all the way down to i9xx_plane_ctl_crtc().
According to the spec we do
From: Ville Syrjälä
On some platforms we need to trigger an extra async flip with
the async flip bit disabled, and then wait for the next vblank
until the async flip bit off state will actually latch.
Currently the w/a is just open coded for skl+ universal planes.
Instead of doing that lets
From: Ville Syrjälä
Set up the async flip PLANE_CTL bit directly in the
.async_flip() hook. Neither .update_plane() nor .disable_plane()
ever need to set this so having it done by skl_plane_ctl_crtc()
is rather pointless.
Cc: Karthik B S
Cc: Vandita Kulkarni
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Prepare for more platforms with async flip support by turning
the flip_done interrupt enable/disable into plane vfuncs.
Cc: Karthik B S
Cc: Vandita Kulkarni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 42 +--
From: Ville Syrjälä
Drop the pointless extra parens.
Cc: Karthik B S
Cc: Vandita Kulkarni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
From: Ville Syrjälä
Limit pre-skl plane stride to below 4k or 8k pixels (depending on
the platform). We do this in order guarantee that TILEOFF/OFFSET.x
does not get too big.
Currently this is not a problem as we align SURF to 4k, and so
TILEOFF/OFFSET only have to deal with a single tile's
From: Ville Syrjälä
Inform us if we're buggy and are about to exceed the size of the
bitfields in the plane TILEOFF/OFFSET registers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c| 7 +++
drivers/gpu/drm/i915/display/intel_display.c | 4
2 files
From: Ville Syrjälä
Second attempt at hooking up async flips for everyone,
this time taking care to keep the plane src coordinates
below the limits of the TILEOFF/OFFSET register.
Ville Syrjälä (11):
drm/i915: WARN if plane src coords are too big
drm/i915: Limit plane stride to below
Quoting Tvrtko Ursulin (2021-01-11 16:19:40)
>
> On 11/01/2021 10:57, Chris Wilson wrote:
> > During igt_reset_nop_engine, it was observed that an unexpected failed
> > engine reset lead to us busywaiting on the stop-ring semaphore (set
> > during the reset preparations) on the first request
On 11/01/2021 10:57, Chris Wilson wrote:
During igt_reset_nop_engine, an engine reset unexpectedly failed. For the
next time this happens, mention which engine that was.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 --
1 file changed, 4
On 11/01/2021 10:57, Chris Wilson wrote:
During igt_reset_nop_engine, it was observed that an unexpected failed
engine reset lead to us busywaiting on the stop-ring semaphore (set
during the reset preparations) on the first request afterwards. There was
no explicit MI_ARB_CHECK in this
Quoting Tvrtko Ursulin (2021-01-11 16:03:48)
>
> On 11/01/2021 10:57, Chris Wilson wrote:
> > On the off chance that we need to arbitrate before launching the
> > payload, perform the check after we signal the request is ready to
> > start. Assuming instantaneous processing of the CS event, the
On 11/01/2021 10:57, Chris Wilson wrote:
On the off chance that we need to arbitrate before launching the
payload, perform the check after we signal the request is ready to
start. Assuming instantaneous processing of the CS event, the request
will then be treated as having started when we make
Quoting Tvrtko Ursulin (2021-01-11 15:53:47)
>
> On 11/01/2021 10:57, Chris Wilson wrote:
> > Braswell's pdp workaround is full of dragons, that may be being angered
> > when they are interrupted. Let's not take that risk and disable
> > arbitrartion during the update.
> >
> > Signed-off-by:
On 11/01/2021 10:57, Chris Wilson wrote:
Braswell's pdp workaround is full of dragons, that may be being angered
when they are interrupted. Let's not take that risk and disable
arbitrartion during the update.
Signed-off-by: Chris Wilson
---
Hi Dan,
On Mon, Jan 11, 2021 at 05:18:08PM +0300, Dan Carpenter wrote:
> This error path should return a negative error code instead of success.
>
> Fixes: c92724de6db1 ("drm/i915/selftests: Try to detect rollback during
> batchbuffer preemption")
> Signed-off-by: Dan Carpenter
> Reviewed-by:
On Sat, Jan 9, 2021 at 9:11 PM Bas Nieuwenhuizen
wrote:
>
> With modifiers one can actually have different format_info structs
> for the same format, which now matters for AMDGPU since we convert
> implicit modifiers to explicit modifiers with multiple planes.
>
> I checked other drivers and it
Quoting Patchwork (2021-01-11 14:52:15)
> == Series Details ==
>
> Series: drm/i915/selftests: Fix some error codes (rev2)
> URL : https://patchwork.freedesktop.org/series/85704/
> State : failure
>
> == Summary ==
>
> Applying: drm/i915: selftest_lrc: Fix error code in live_preempt_user()
>
== Series Details ==
Series: drm/i915/selftests: Fix some error codes (rev2)
URL : https://patchwork.freedesktop.org/series/85704/
State : failure
== Summary ==
Applying: drm/i915: selftest_lrc: Fix error code in live_preempt_user()
Using index info to reconstruct a base tree...
M
On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote:
> On Fri, Jan 08, 2021 at 08:20:43PM +, Paul Cercueil wrote:
> > Hi Thomas,
> >
> > 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit.
> >
> > Any idea what could be happening?
>
> not yet, kernel
> Am 10.01.2021 um 12:35 schrieb Paul Cercueil :
>
> Hi Thomas,
>
> Le sam. 9 janv. 2021 à 1:33, Thomas Bogendoerfer
> a écrit :
>> On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote:
>>> On Fri, Jan 08, 2021 at 08:20:43PM +, Paul Cercueil wrote:
>>> > Hi Thomas,
>>> >
Hi Thomas,
Le sam. 9 janv. 2021 à 1:33, Thomas Bogendoerfer
a écrit :
On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote:
On Fri, Jan 08, 2021 at 08:20:43PM +, Paul Cercueil wrote:
> Hi Thomas,
>
> 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this
Hi Thomas,
5.11 does not boot anymore on Ingenic SoCs, I bisected it to this
commit.
Any idea what could be happening?
Cheers,
-Paul
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
On Fri, Jan 08, 2021 at 08:20:43PM +, Paul Cercueil wrote:
> Hi Thomas,
>
> 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit.
>
> Any idea what could be happening?
not yet, kernel crash log of a Malta QEMU is below.
Thomas.
Kernel bug detected[#1]:
CPU: 0 PID: 1
1 - 100 of 134 matches
Mail list logo
