Re: [Intel-gfx] [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Thu, Aug 23, 2018 at 6:14 AM, John Stultz wrote: > On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: >> Hey Noralf, all, >> I've been digging for a bit on the regression that this patch has >> tripped on the HiKey board as reported here: >> https://lkml.org/lkml/2018/8/16/81 >> >> The first issue was that the kirin driver was setting >> mode_config.max_width/height = 2048, which was causing errors as the >> the requested resolution was 1920x2160 (due to surfaceflinger >> requesting y*2 for page flipping). > > Hey Noralf, > Sorry, I know your probably sick of me. But I just wanted to circle > around on this little bit. So part of the issue I found earlier, was > that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support > Surfaceflinger's request for page flipping. This is what makes the Y > resolution 2160, which runs afoul of the new max_height check of 2048 > in the generic code. > > I was checking with Xinliang, who know the kirin display hardware, > about the max_height being set to 2048 to ensure bumping it up wasn't > a problem, but he said 2048x2048 was unfortunately not arbitrary, and > that was the hard limit of the display hardware. However, with > overalloc, the 1920x2160 res fbdev should still be ok, as only > 1920x1080 is actually displayed at one time. > > So it seems like we might need to multiply the max_height by the > overalloc factor when we are checking it in > drm_internal_framebuffer_create? > > Does that approach sound sane, or would folks prefer something different? I guess we could simply not check against the height limit when allocating framebuffers. But we've done that for userspace buffers since forever (they just allocate 2 buffers for page-flipping), so I have no idea what would all break if we'd suddenly lift this restriction. And whether we'd lift it for fbdev only or for everyone doesn't really make much of a difference, since either this works, or it doesn't (across all chips). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Avoid Gen10 watermark workarounds in Gen11
== Series Details == Series: drm/i915/icl: Avoid Gen10 watermark workarounds in Gen11 URL : https://patchwork.freedesktop.org/series/48601/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4700_full -> Patchwork__full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork__full that come from known issues: === IGT changes === Issues hit igt@gem_exec_await@wide-contexts: shard-glk: PASS -> FAIL (fdo#105900) igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#105363) igt@kms_flip@dpms-vs-vblank-race: shard-glk: PASS -> FAIL (fdo#103060) Possible fixes igt@kms_flip@modeset-vs-vblank-race: shard-snb: FAIL (fdo#103060) -> PASS fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4700 -> Patchwork_ CI_DRM_4700: b7d51b8e106cf75ee061244eff6281a9867e3651 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_: 578f56edabd27b85425f5533fe2ec1c0589108be @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: protect against division by zero.
On Thu, Aug 23, 2018 at 07:11:16AM +0200, Maarten Lankhorst wrote:
> Op 23-08-18 om 02:51 schreef Rodrigo Vivi:
> > Static analyzer tools thinks it is possible to have a division by zero
> > here.
> >
> > I don't believe we would really reach this path without any crtc enabled,
> > but may be good to protect against some unexpected path or behavior.
> >
> > Fixes: cf1f697acb04 ("drm/i915/skl: distribute DDB based on panel
> > resolution")
> > Cc: Chris Wilson
> > Cc: Mahesh Kumar
> > Cc: Maarten Lankhorst
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index d99e5fabe93c..fac6e159a640 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3878,6 +3878,12 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device
> > *dev,
> > pipe_width = hdisplay;
> > }
> >
> > + if (WARN_ON(total_width == 0)) {
> > + alloc->start = 0;
> > + alloc->end = 0;
> > + return;
> > + }
> > +
> > alloc->start = ddb_size * width_before_pipe / total_width;
> > alloc->end = ddb_size * (width_before_pipe + pipe_width) / total_width;
> > }
>
> It's actually quite impossible.. only way I can imagine if hw is already
> borked.
>
> It must be the case that we will set cstate->active, which implies
> cstate->enable,
> which implies a valid mode is set at least on the current crtc.
yeap... that's what I thought... but I decided to check just in case I missed
something.
>
> I don't think static analysis tools could deduce it, but definitely a false
> positive.
I'll mart that so...
>
> Also too generic commit message oneliner?
it just reflects the amount of confidence I had on the need of this ;)
just dropping it then.
thanks for the confirmation
>
> ~Maarten
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v4 7/8] drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
>-Original Message-
>From: Alexandru-Cosmin Gheorghe [mailto:Alexandru-
>cosmin.gheor...@arm.com]
>Sent: Tuesday, August 21, 2018 3:26 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>dcasta...@chromium.org; emil.l.veli...@gmail.com; seanp...@chromium.org;
>Syrjala, Ville ; Lankhorst, Maarten
>; n...@arm.com
>Subject: Re: [RFC v4 7/8] drm/i915: Implement Plane Gamma for Bdw and Gen9
>platforms
>
>Hi Uma,
>
>On Fri, Aug 17, 2018 at 07:48:50PM +0530, Uma Shankar wrote:
>> Implement Plane Gamma feature for BDW and Gen9 platforms.
>>
>> v2: Used newly added drm_color_lut_ext structure for enhanced
>> precision for Gamma LUT entries.
>>
>> v3: Rebase
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/i915/i915_pci.c | 5 +++-
>> drivers/gpu/drm/i915/i915_reg.h | 25
>> drivers/gpu/drm/i915/intel_color.c | 58
>
>> drivers/gpu/drm/i915/intel_display.c | 4 +++
>> drivers/gpu/drm/i915/intel_sprite.c | 4 +++
>> 5 files changed, 95 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_pci.c
>> b/drivers/gpu/drm/i915/i915_pci.c index e931b48..40de78c 100644
>> --- a/drivers/gpu/drm/i915/i915_pci.c
>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>> @@ -54,7 +54,10 @@
>> .cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET,
>> IVB_CURSOR_C_OFFSET }
>>
>> #define BDW_COLORS \
>> -.color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
>> +.color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }, \
>> +.plane_color = { .plane_degamma_lut_size = 0, \
>> + .plane_gamma_lut_size = 16 }
>> +
>> #define CHV_COLORS \
>> .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 } #define
>> GLK_COLORS \ diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h index 0c9f03d..2db6a84 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -172,6 +172,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t
>> reg) #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__) #define
>> _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
>>
>> +/* Plane Gamma Registers */
>> +#define _MMIO_PLANE_GAMC(plane, i, a, b) _MMIO(_PIPE(plane, a, b) +
>> +(i) * 4) #define _MMIO_PLANE_GAMC16(plane, i, a, b)
>> +_MMIO(_PIPE(plane, a, b) + (i) * 4)
>> +
>> #define __MASKED_FIELD(mask, value) ((mask) << 16 | (value))
>> #define _MASKED_FIELD(mask, value) ({
> \
>> if (__builtin_constant_p(mask))\
>> @@ -9713,6 +9717,27 @@ enum skl_power_gate {
>> #define PRE_CSC_GAMC_INDEX(pipe)_MMIO_PIPE(pipe,
>_PRE_CSC_GAMC_INDEX_A, _PRE_CSC_GAMC_INDEX_B)
>> #define PRE_CSC_GAMC_DATA(pipe) _MMIO_PIPE(pipe,
>_PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
>>
>> +/* Plane Gamma in Gen9+ */
>> +#define _PLANE_GAMC_1_A 0x701d0
>> +#define _PLANE_GAMC_1_B 0x711d0
>> +#define _PLANE_GAMC_2_A 0x702d0
>> +#define _PLANE_GAMC_2_B 0x712d0
>> +#define _PLANE_GAMC_1(pipe) _PIPE(pipe, _PLANE_GAMC_1_A,
>_PLANE_GAMC_1_B)
>> +#define _PLANE_GAMC_2(pipe) _PIPE(pipe, _PLANE_GAMC_2_A,
>_PLANE_GAMC_2_B)
>> +#define PLANE_GAMC(pipe, plane, i) \
>> +_MMIO_PLANE_GAMC(plane, i, _PLANE_GAMC_1(pipe),
>_PLANE_GAMC_2(pipe))
>> +
>> +#define _PLANE_GAMC16_1_A 0x70210
>> +#define _PLANE_GAMC16_1_B 0x71210
>> +#define _PLANE_GAMC16_2_A 0x70310
>> +#define _PLANE_GAMC16_2_B 0x71310
>> +#define _PLANE_GAMC16_1(pipe) _PIPE(pipe, _PLANE_GAMC16_1_A, \
>> + _PLANE_GAMC16_1_B)
>> +#define _PLANE_GAMC16_2(pipe) _PIPE(pipe, _PLANE_GAMC16_2_A, \
>> + _PLANE_GAMC16_2_B)
>> +#define PLANE_GAMC16(pipe, plane, i) _MMIO_PLANE_GAMC16(plane, i, \
>> +_PLANE_GAMC16_1(pipe),
>_PLANE_GAMC16_2(pipe))
>> +
>> /* pipe CSC & degamma/gamma LUTs on CHV */
>> #define _CGM_PIPE_A_CSC_COEFF01 (VLV_DISPLAY_BASE + 0x67900)
>> #define _CGM_PIPE_A_CSC_COEFF23 (VLV_DISPLAY_BASE + 0x67904)
>> diff --git a/drivers/gpu/drm/i915/intel_color.c
>> b/drivers/gpu/drm/i915/intel_color.c
>> index fb8402f..2b5c0cd 100644
>> --- a/drivers/gpu/drm/i915/intel_color.c
>> +++ b/drivers/gpu/drm/i915/intel_color.c
>> @@ -492,6 +492,59 @@ static void broadwell_load_luts(struct drm_crtc_state
>*state)
>> I915_WRITE(PREC_PAL_INDEX(pipe), 0); }
>>
>> +static void bdw_load_plane_gamma_lut(const struct drm_plane_state *state,
>> + u32 offset)
>> +{
>> +struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
>> +enum pipe pipe = to_intel_plane(state->plane)->pipe;
>> +enum plane_id plane = to_intel_plane(state->plane)->id;
>> +uint32_t i, lut_size =
>> +INTEL_INFO(dev_priv)-
>>plane_color.plane_gamma_lut_size;
>> +
>> +if (state->gamma_lut) {
>> +struct drm_color_lut_ext *lut =
>> +
Re: [Intel-gfx] [RFC v4 1/8] drm: Add Enhanced Gamma LUT precision structure
>-Original Message-
>From: Alexandru-Cosmin Gheorghe [mailto:Alexandru-
>cosmin.gheor...@arm.com]
>Sent: Tuesday, August 21, 2018 3:00 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>dcasta...@chromium.org; emil.l.veli...@gmail.com; seanp...@chromium.org;
>Syrjala, Ville ; Lankhorst, Maarten
>; n...@arm.com
>Subject: Re: [RFC v4 1/8] drm: Add Enhanced Gamma LUT precision structure
>
>Hi Uma,
>
>On Fri, Aug 17, 2018 at 07:48:44PM +0530, Uma Shankar wrote:
>> Existing LUT precision structure is having only 16 bit precision. This
>> is not enough for upcoming enhanced hardwares and advance usecases
>> like HDR processing. Hence added a new structure with 32 bit precision
>> values. Also added the code, for extracting the same from values
>> passed from userspace.
>>
>> v4: Rebase
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_plane.c | 19 +++
>> include/uapi/drm/drm_mode.h | 15 +++
>> 2 files changed, 34 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
>> index 6153cbd..cd71fd0 100644
>> --- a/drivers/gpu/drm/drm_plane.c
>> +++ b/drivers/gpu/drm/drm_plane.c
>> @@ -430,6 +430,25 @@ void drm_plane_force_disable(struct drm_plane
>> *plane) } EXPORT_SYMBOL(drm_plane_force_disable);
>>
>> +/*
>> + * Added to accommodate enhanced LUT precision.
>> + * Max LUT precision is 32 bits.
>> + */
>> +uint32_t drm_color_lut_extract_ext(uint32_t user_input, uint32_t
>> +bit_precision)
>
>You should declare this function in a header file as well.
Thanks Alexandru for the review. Sure, will fix that and resend.
>With that fixed
>Reviewed-by: Alexandru Gheorghe
>
>
>> +{
>> +uint32_t val = user_input;
>> +uint32_t max = 0x >> (32 - bit_precision);
>> +
>> +/* Round only if we're not using full precision. */
>> +if (bit_precision < 32) {
>> +val += 1UL << (32 - bit_precision - 1);
>> +val >>= 32 - bit_precision;
>> +}
>> +
>> +return clamp_val(val, 0, max);
>> +}
>> +EXPORT_SYMBOL(drm_color_lut_extract_ext);
>> +
>> /**
>> * drm_mode_plane_set_obj_prop - set the value of a property
>> * @plane: drm plane object to set property value for diff --git
>> a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index
>> 8d67243..874407b 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -629,6 +629,21 @@ struct drm_color_lut {
>> __u16 reserved;
>> };
>>
>> +/*
>> + * Creating 32 bit palette entries for better data
>> + * precision. This will be required for HDR and
>> + * similar color processing usecases.
>> + */
>> +struct drm_color_lut_ext {
>> +/*
>> + * Data is U0.32 fixed point format.
>> + */
>> +__u32 red;
>> +__u32 green;
>> +__u32 blue;
>> +__u32 reserved;
>> +};
>> +
>> #define DRM_MODE_PAGE_FLIP_EVENT 0x01 #define
>> DRM_MODE_PAGE_FLIP_ASYNC 0x02 #define
>> DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>Cheers,
>Alex G
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v4 3/8] drm: Add Plane CTM property
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Wednesday, August 22, 2018 6:36 PM
>To: Brian Starkey
>Cc: Lankhorst, Maarten ;
>dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; Shankar, Uma ;
>seanp...@chromium.org; Syrjala, Ville
>Subject: Re: [Intel-gfx] [RFC v4 3/8] drm: Add Plane CTM property
>
>On Wed, Aug 22, 2018 at 12:11:42PM +0100, Brian Starkey wrote:
>> Hi,
>>
>> On Wed, Aug 22, 2018 at 12:53:58PM +0300, Ville Syrjälä wrote:
>> >On Wed, Aug 22, 2018 at 08:40:19AM +, Lankhorst, Maarten wrote:
>> >> fre 2018-08-17 klockan 19:48 +0530 skrev Uma Shankar:
>> >> > Add a blob property for plane CSC usage.
>> >> >
>> >> > v2: Rebase
>> >> >
>> >> > v3: Fixed Sean, Paul's review comments. Moved the property from
>> >> > mode_config to drm_plane. Created a helper function to
>> >> > instantiate these properties and removed from
>> >> > drm_mode_create_standard_properties
>> >> > Added property documentation as suggested by Daniel, Vetter.
>> >> >
>> >> > v4: Rebase
>> >> >
>> >> > Signed-off-by: Uma Shankar
>> >> > ---
>> >> > Documentation/gpu/drm-kms.rst | 3 +++
>> >> > drivers/gpu/drm/drm_atomic.c| 10 ++
>> >> > drivers/gpu/drm/drm_atomic_helper.c | 4
>> >> > drivers/gpu/drm/drm_plane.c | 12
>> >> > include/drm/drm_plane.h | 15 +++
>> >> > 5 files changed, 44 insertions(+)
>> >> >
>> >> > diff --git a/Documentation/gpu/drm-kms.rst
>> >> > b/Documentation/gpu/drm- kms.rst index 8b10b12..16d6d8d 100644
>> >> > --- a/Documentation/gpu/drm-kms.rst
>> >> > +++ b/Documentation/gpu/drm-kms.rst
>> >> > @@ -560,6 +560,9 @@ Plane Color Management Properties ..
>> >> > kernel-doc:: drivers/gpu/drm/drm_plane.c
>> >> > :doc: degamma_lut_size_property
>> >> >
>> >> > +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
>> >> > + :doc: ctm_property
>> >> > +
>> >> > Tile Group Property
>> >> > ---
>> >> >
>> >> > diff --git a/drivers/gpu/drm/drm_atomic.c
>> >> > b/drivers/gpu/drm/drm_atomic.c index f8cad9b..ddda935 100644
>> >> > --- a/drivers/gpu/drm/drm_atomic.c
>> >> > +++ b/drivers/gpu/drm/drm_atomic.c
>> >> > @@ -917,6 +917,14 @@ static int
>> >> > drm_atomic_plane_set_property(struct
>> >> > drm_plane *plane,
>> >> > );
>> >> > state->color_mgmt_changed |= replaced;
>> >> > return ret;
>> >> > + } else if (property == plane->ctm_property) {
>> >> > + ret = drm_atomic_replace_property_blob_from_id(dev,
>> >> > + >ctm,
>> >> > + val,
>> >> > + sizeof(struct
>> >> > drm_color_ctm), -1,
>> >> > + );
>> >> > + state->color_mgmt_changed |= replaced;
>> >> > + return ret;
>> >> > } else if (plane->funcs->atomic_set_property) {
>> >> > return plane->funcs->atomic_set_property(plane,
>> >> > state,
>> >> > property, val);
>> >> > @@ -988,6 +996,8 @@ static int
>> >> > drm_atomic_plane_set_property(struct
>> >> > drm_plane *plane,
>> >> > } else if (property == plane->degamma_lut_property) {
>> >> > *val = (state->degamma_lut) ?
>> >> > state->degamma_lut->base.id : 0;
>> >> > + } else if (property == plane->ctm_property) {
>> >> > + *val = (state->ctm) ? state->ctm->base.id : 0;
>> >> > } else if (plane->funcs->atomic_get_property) {
>> >> > return plane->funcs->atomic_get_property(plane,
>> >> > state, property, val);
>> >> > } else {
>> >> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> >> > b/drivers/gpu/drm/drm_atomic_helper.c
>> >> > index 67c5b51..866181f 100644
>> >> > --- a/drivers/gpu/drm/drm_atomic_helper.c
>> >> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> >> > @@ -3616,6 +3616,9 @@ void
>> >> > __drm_atomic_helper_plane_duplicate_state(struct drm_plane
>> >> > *plane,
>> >> >
>> >> > if (state->degamma_lut)
>> >> > drm_property_blob_get(state->degamma_lut);
>> >> > + if (state->ctm)
>> >> > + drm_property_blob_get(state->ctm);
>> >> > +
>> >> > state->color_mgmt_changed = false; }
>> >> > EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
>> >> > @@ -3663,6 +3666,7 @@ void
>> >> > __drm_atomic_helper_plane_destroy_state(struct drm_plane_state
>> >> > *state)
>> >> > drm_crtc_commit_put(state->commit);
>> >> >
>> >> > drm_property_blob_put(state->degamma_lut);
>> >> > + drm_property_blob_put(state->ctm);
>> >> > }
>> >> > EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>> >> >
>> >> > diff --git a/drivers/gpu/drm/drm_plane.c
>> >> > b/drivers/gpu/drm/drm_plane.c index 03e0560..97520b1
Re: [Intel-gfx] [PATCH] drm/i915: protect against division by zero.
Op 23-08-18 om 02:51 schreef Rodrigo Vivi:
> Static analyzer tools thinks it is possible to have a division by zero
> here.
>
> I don't believe we would really reach this path without any crtc enabled,
> but may be good to protect against some unexpected path or behavior.
>
> Fixes: cf1f697acb04 ("drm/i915/skl: distribute DDB based on panel resolution")
> Cc: Chris Wilson
> Cc: Mahesh Kumar
> Cc: Maarten Lankhorst
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_pm.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index d99e5fabe93c..fac6e159a640 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3878,6 +3878,12 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device
> *dev,
> pipe_width = hdisplay;
> }
>
> + if (WARN_ON(total_width == 0)) {
> + alloc->start = 0;
> + alloc->end = 0;
> + return;
> + }
> +
> alloc->start = ddb_size * width_before_pipe / total_width;
> alloc->end = ddb_size * (width_before_pipe + pipe_width) / total_width;
> }
It's actually quite impossible.. only way I can imagine if hw is already borked.
It must be the case that we will set cstate->active, which implies
cstate->enable,
which implies a valid mode is set at least on the current crtc.
I don't think static analysis tools could deduce it, but definitely a false
positive.
Also too generic commit message oneliner?
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Avoid Gen10 watermark workarounds in Gen11
== Series Details ==
Series: drm/i915/icl: Avoid Gen10 watermark workarounds in Gen11
URL : https://patchwork.freedesktop.org/series/48601/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4700 -> Patchwork_ =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48601/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_ that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
fi-cfl-s3: PASS -> DMESG-FAIL (fdo#106560)
Possible fixes
igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
{fi-byt-clapper}: FAIL (fdo#103191, fdo#107362) -> PASS
Warnings
{igt@pm_rpm@module-reload}:
fi-cnl-psr: FAIL -> WARN (fdo#107602)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
== Participating hosts (53 -> 47) ==
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600
== Build changes ==
* Linux: CI_DRM_4700 -> Patchwork_
CI_DRM_4700: b7d51b8e106cf75ee061244eff6281a9867e3651 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_: 578f56edabd27b85425f5533fe2ec1c0589108be @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
578f56edabd2 drm/i915/icl: Avoid Gen10 watermark workarounds in Gen11
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: > Hey Noralf, all, > I've been digging for a bit on the regression that this patch has > tripped on the HiKey board as reported here: > https://lkml.org/lkml/2018/8/16/81 > > The first issue was that the kirin driver was setting > mode_config.max_width/height = 2048, which was causing errors as the > the requested resolution was 1920x2160 (due to surfaceflinger > requesting y*2 for page flipping). Hey Noralf, Sorry, I know your probably sick of me. But I just wanted to circle around on this little bit. So part of the issue I found earlier, was that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support Surfaceflinger's request for page flipping. This is what makes the Y resolution 2160, which runs afoul of the new max_height check of 2048 in the generic code. I was checking with Xinliang, who know the kirin display hardware, about the max_height being set to 2048 to ensure bumping it up wasn't a problem, but he said 2048x2048 was unfortunately not arbitrary, and that was the hard limit of the display hardware. However, with overalloc, the 1920x2160 res fbdev should still be ok, as only 1920x1080 is actually displayed at one time. So it seems like we might need to multiply the max_height by the overalloc factor when we are checking it in drm_internal_framebuffer_create? Does that approach sound sane, or would folks prefer something different? thanks -john ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/icl: Avoid Gen10 watermark workarounds in Gen11
== Series Details ==
Series: drm/i915/icl: Avoid Gen10 watermark workarounds in Gen11
URL : https://patchwork.freedesktop.org/series/48601/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
578f56edabd2 drm/i915/icl: Avoid Gen10 watermark workarounds in Gen11
-:38: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#38: FILE: drivers/gpu/drm/i915/intel_pm.c:4689:
+ res_blocks += fixed16_to_u32_round_up(
total: 0 errors, 0 warnings, 1 checks, 51 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/icl: Avoid Gen10 watermark workarounds in Gen11
Check added to skip the watermark workarounds intended for Gen10 and
below platforms in Gen11.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/intel_pm.c | 39 +++
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d99e5fa..1928fe0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4677,28 +4677,35 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
res_lines = div_round_up_fixed16(selected_result,
wp->plane_blocks_per_line);
- /* Display WA #1125: skl,bxt,kbl,glk */
- if (level == 0 && wp->rc_surface)
- res_blocks += fixed16_to_u32_round_up(wp->y_tile_minimum);
-
- /* Display WA #1126: skl,bxt,kbl,glk */
- if (level >= 1 && level <= 7) {
- if (wp->y_tiled) {
+ if (INTEL_GEN(dev_priv) < 11) {
+ /* Display WA #1125: skl,bxt,kbl,glk */
+ if (level == 0 && wp->rc_surface)
res_blocks += fixed16_to_u32_round_up(
wp->y_tile_minimum);
- res_lines += wp->y_min_scanlines;
- } else {
- res_blocks++;
+
+ /* Display WA #1126: skl,bxt,kbl,glk */
+ if (level >= 1 && level <= 7) {
+ if (wp->y_tiled) {
+ res_blocks += fixed16_to_u32_round_up(
+ wp->y_tile_minimum);
+ res_lines += wp->y_min_scanlines;
+ } else {
+ res_blocks++;
+ }
}
+ }
- /*
-* Make sure result blocks for higher latency levels are atleast
-* as high as level below the current level.
-* Assumption in DDB algorithm optimization for special cases.
-* Also covers Display WA #1125 for RC.
-*/
+ /*
+* Make sure result blocks for higher latency levels are atleast
+* as high as level below the current level.
+* Assumption in DDB algorithm optimization for special cases.
+* Also covers Display WA #1125 for RC.
+*/
+ if (level >= 1 && level <= 7) {
if (result_prev->plane_res_b > res_blocks)
res_blocks = result_prev->plane_res_b;
+ if (result_prev->plane_res_l > res_lines)
+ res_lines = result_prev->plane_res_l;
}
if (INTEL_GEN(dev_priv) >= 11) {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: protect against division by zero.
== Series Details == Series: drm/i915: protect against division by zero. URL : https://patchwork.freedesktop.org/series/48595/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4700_full -> Patchwork_9998_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9998_full that come from known issues: === IGT changes === Issues hit igt@gem_ppgtt@blt-vs-render-ctx0: shard-kbl: PASS -> INCOMPLETE (fdo#106023, fdo#103665) igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#102887, fdo#105363) Possible fixes igt@kms_flip@modeset-vs-vblank-race: shard-snb: FAIL (fdo#103060) -> PASS fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4700 -> Patchwork_9998 CI_DRM_4700: b7d51b8e106cf75ee061244eff6281a9867e3651 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9998: c2770c9f2c6f4af0b9917ece97ee8c2091c7b283 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9998/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: protect against division by zero.
== Series Details ==
Series: drm/i915: protect against division by zero.
URL : https://patchwork.freedesktop.org/series/48595/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4700 -> Patchwork_9998 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48595/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9998:
=== IGT changes ===
Warnings
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: DMESG-FAIL -> DMESG-WARN
== Known issues ==
Here are the changes found in Patchwork_9998 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
fi-skl-guc: PASS -> DMESG-FAIL (fdo#107174)
Possible fixes
igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
{fi-byt-clapper}: FAIL (fdo#107362, fdo#103191) -> PASS
{igt@kms_psr@primary_mmap_gtt}:
fi-cnl-psr: DMESG-WARN -> PASS
{igt@pm_rpm@module-reload}:
fi-cnl-psr: FAIL -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
== Participating hosts (53 -> 48) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4700 -> Patchwork_9998
CI_DRM_4700: b7d51b8e106cf75ee061244eff6281a9867e3651 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9998: c2770c9f2c6f4af0b9917ece97ee8c2091c7b283 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c2770c9f2c6f drm/i915: protect against division by zero.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9998/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: protect against division by zero.
== Series Details ==
Series: drm/i915: protect against division by zero.
URL : https://patchwork.freedesktop.org/series/48595/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4699 -> Patchwork_9997 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9997 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_9997, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48595/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9997:
=== IGT changes ===
Possible regressions
igt@drv_selftest@live_hangcheck:
fi-bxt-j4205: PASS -> DMESG-FAIL
{igt@pm_rpm@module-reload}:
fi-byt-j1900: NOTRUN -> DMESG-WARN
Warnings
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: DMESG-FAIL -> DMESG-WARN
== Known issues ==
Here are the changes found in Patchwork_9997 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_pipe_crc_basic@read-crc-pipe-b:
{fi-byt-clapper}: PASS -> FAIL (fdo#107362)
Possible fixes
igt@drv_selftest@live_coherency:
fi-gdg-551: DMESG-FAIL (fdo#107164) -> PASS
igt@drv_selftest@live_hangcheck:
fi-kbl-7560u: DMESG-FAIL (fdo#106560, fdo#106947) -> PASS
fi-skl-guc: DMESG-FAIL (fdo#106685, fdo#107174) -> PASS
igt@kms_chamelium@dp-edid-read:
fi-kbl-7500u: FAIL (fdo#103841) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106685 https://bugs.freedesktop.org/show_bug.cgi?id=106685
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
== Participating hosts (52 -> 48) ==
Additional (1): fi-byt-j1900
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4699 -> Patchwork_9997
CI_DRM_4699: 499f94dbe3632e59aa93d186cda836247523f23f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9997: 37263b7fe8497d0cbc7e2bbf552fe5ce0077c3fa @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
37263b7fe849 drm/i915: protect against division by zero.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9997/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/18] drm/i915: s/int plane/int color_plane/
On Thu, Jul 19, 2018 at 09:22:04PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To reduce the confusion between a drm plane and the planes of
> framebuffers let's desiginate the latter as "color plane".
what about fb_plane instead of color?
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 106
> ++-
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> 2 files changed, 56 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e6cb8238f257..bc2a712311ba 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1916,10 +1916,10 @@ static unsigned int intel_tile_size(const struct
> drm_i915_private *dev_priv)
> }
>
> static unsigned int
> -intel_tile_width_bytes(const struct drm_framebuffer *fb, int plane)
> +intel_tile_width_bytes(const struct drm_framebuffer *fb, int color_plane)
> {
> struct drm_i915_private *dev_priv = to_i915(fb->dev);
> - unsigned int cpp = fb->format->cpp[plane];
> + unsigned int cpp = fb->format->cpp[color_plane];
>
> switch (fb->modifier) {
> case DRM_FORMAT_MOD_LINEAR:
> @@ -1930,7 +1930,7 @@ intel_tile_width_bytes(const struct drm_framebuffer
> *fb, int plane)
> else
> return 512;
> case I915_FORMAT_MOD_Y_TILED_CCS:
> - if (plane == 1)
> + if (color_plane == 1)
> return 128;
> /* fall through */
> case I915_FORMAT_MOD_Y_TILED:
> @@ -1939,7 +1939,7 @@ intel_tile_width_bytes(const struct drm_framebuffer
> *fb, int plane)
> else
> return 512;
> case I915_FORMAT_MOD_Yf_TILED_CCS:
> - if (plane == 1)
> + if (color_plane == 1)
> return 128;
> /* fall through */
> case I915_FORMAT_MOD_Yf_TILED:
> @@ -1964,22 +1964,22 @@ intel_tile_width_bytes(const struct drm_framebuffer
> *fb, int plane)
> }
>
> static unsigned int
> -intel_tile_height(const struct drm_framebuffer *fb, int plane)
> +intel_tile_height(const struct drm_framebuffer *fb, int color_plane)
> {
> if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
> return 1;
> else
> return intel_tile_size(to_i915(fb->dev)) /
> - intel_tile_width_bytes(fb, plane);
> + intel_tile_width_bytes(fb, color_plane);
> }
>
> /* Return the tile dimensions in pixel units */
> -static void intel_tile_dims(const struct drm_framebuffer *fb, int plane,
> +static void intel_tile_dims(const struct drm_framebuffer *fb, int
> color_plane,
> unsigned int *tile_width,
> unsigned int *tile_height)
> {
> - unsigned int tile_width_bytes = intel_tile_width_bytes(fb, plane);
> - unsigned int cpp = fb->format->cpp[plane];
> + unsigned int tile_width_bytes = intel_tile_width_bytes(fb, color_plane);
> + unsigned int cpp = fb->format->cpp[color_plane];
>
> *tile_width = tile_width_bytes / cpp;
> *tile_height = intel_tile_size(to_i915(fb->dev)) / tile_width_bytes;
> @@ -1987,9 +1987,9 @@ static void intel_tile_dims(const struct
> drm_framebuffer *fb, int plane,
>
> unsigned int
> intel_fb_align_height(const struct drm_framebuffer *fb,
> - int plane, unsigned int height)
> + int color_plane, unsigned int height)
> {
> - unsigned int tile_height = intel_tile_height(fb, plane);
> + unsigned int tile_height = intel_tile_height(fb, color_plane);
>
> return ALIGN(height, tile_height);
> }
> @@ -2043,12 +2043,12 @@ static unsigned int intel_linear_alignment(const
> struct drm_i915_private *dev_pr
> }
>
> static unsigned int intel_surf_alignment(const struct drm_framebuffer *fb,
> - int plane)
> + int color_plane)
> {
> struct drm_i915_private *dev_priv = to_i915(fb->dev);
>
> /* AUX_DIST needs only 4K alignment */
> - if (plane == 1)
> + if (color_plane == 1)
> return 4096;
>
> switch (fb->modifier) {
> @@ -2178,13 +2178,13 @@ void intel_unpin_fb_vma(struct i915_vma *vma,
> unsigned long flags)
> i915_vma_put(vma);
> }
>
> -static int intel_fb_pitch(const struct drm_framebuffer *fb, int plane,
> +static int intel_fb_pitch(const struct drm_framebuffer *fb, int color_plane,
> unsigned int rotation)
> {
> if (drm_rotation_90_or_270(rotation))
> - return to_intel_framebuffer(fb)->rotated[plane].pitch;
> + return to_intel_framebuffer(fb)->rotated[color_plane].pitch;
> else
> - return fb->pitches[plane];
> + return fb->pitches[color_plane];
> }
>
> /*
> @@ -2195,11 +2195,11 @@ static int
Re: [Intel-gfx] [PATCH 12/18] drm/i915: Move display w/a #1175
On Thu, Jul 19, 2018 at 09:22:08PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move the display w/a #1175 to a better place. That place
> being the new skl+ specific plane->check() hook. This leaves
> the skl_check_plane_surface() stuff to deal with the gtt offset
> and src coordinate stuff as originally envisioned.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_display.c | 36
> +---
> drivers/gpu/drm/i915/intel_drv.h | 3 +--
> drivers/gpu/drm/i915/intel_sprite.c | 36
> +++-
> 3 files changed, 41 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2381b762d109..dbcc9a23eefa 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2986,20 +2986,14 @@ static bool skl_check_main_ccs_coordinates(struct
> intel_plane_state *plane_state
> return true;
> }
>
> -static int skl_check_main_surface(const struct intel_crtc_state *crtc_state,
> - struct intel_plane_state *plane_state)
> +static int skl_check_main_surface(struct intel_plane_state *plane_state)
> {
> - struct drm_i915_private *dev_priv =
> - to_i915(plane_state->base.plane->dev);
> const struct drm_framebuffer *fb = plane_state->base.fb;
> unsigned int rotation = plane_state->base.rotation;
> int x = plane_state->base.src.x1 >> 16;
> int y = plane_state->base.src.y1 >> 16;
> int w = drm_rect_width(_state->base.src) >> 16;
> int h = drm_rect_height(_state->base.src) >> 16;
> - int dst_x = plane_state->base.dst.x1;
> - int dst_w = drm_rect_width(_state->base.dst);
> - int pipe_src_w = crtc_state->pipe_src_w;
> int max_width = skl_max_plane_width(fb, 0, rotation);
> int max_height = 4096;
> u32 alignment, offset, aux_offset = plane_state->color_plane[1].offset;
> @@ -3010,24 +3004,6 @@ static int skl_check_main_surface(const struct
> intel_crtc_state *crtc_state,
> return -EINVAL;
> }
>
> - /*
> - * Display WA #1175: cnl,glk
> - * Planes other than the cursor may cause FIFO underflow and display
> - * corruption if starting less than 4 pixels from the right edge of
> - * the screen.
> - * Besides the above WA fix the similar problem, where planes other
> - * than the cursor ending less than 4 pixels from the left edge of the
> - * screen may cause FIFO underflow and display corruption.
> - */
> - if ((IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) &&
> - (dst_x + dst_w < 4 || dst_x > pipe_src_w - 4)) {
> - DRM_DEBUG_KMS("requested plane X %s position %d invalid (valid
> range %d-%d)\n",
> - dst_x + dst_w < 4 ? "end" : "start",
> - dst_x + dst_w < 4 ? dst_x + dst_w : dst_x,
> - 4, pipe_src_w - 4);
> - return -ERANGE;
> - }
> -
> intel_add_fb_offsets(, , plane_state, 0);
> offset = intel_plane_compute_aligned_offset(, , plane_state, 0);
> alignment = intel_surf_alignment(fb, 0);
> @@ -3089,8 +3065,7 @@ static int skl_check_main_surface(const struct
> intel_crtc_state *crtc_state,
> }
>
> static int
> -skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> -struct intel_plane_state *plane_state)
> +skl_check_nv12_surface(struct intel_plane_state *plane_state)
> {
> /* Display WA #1106 */
> if (plane_state->base.rotation !=
> @@ -3161,8 +3136,7 @@ static int skl_check_ccs_aux_surface(struct
> intel_plane_state *plane_state)
> return 0;
> }
>
> -int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
> - struct intel_plane_state *plane_state)
> +int skl_check_plane_surface(struct intel_plane_state *plane_state)
> {
> const struct drm_framebuffer *fb = plane_state->base.fb;
> unsigned int rotation = plane_state->base.rotation;
> @@ -3186,7 +3160,7 @@ int skl_check_plane_surface(const struct
> intel_crtc_state *crtc_state,
>* the main surface setup depends on it.
>*/
> if (fb->format->format == DRM_FORMAT_NV12) {
> - ret = skl_check_nv12_surface(crtc_state, plane_state);
> + ret = skl_check_nv12_surface(plane_state);
> if (ret)
> return ret;
> ret = skl_check_nv12_aux_surface(plane_state);
> @@ -3203,7 +3177,7 @@ int skl_check_plane_surface(const struct
> intel_crtc_state *crtc_state,
> plane_state->color_plane[1].y = 0;
> }
>
> - ret = skl_check_main_surface(crtc_state, plane_state);
> + ret = skl_check_main_surface(plane_state);
> if (ret)
> return ret;
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>
Re: [Intel-gfx] [PATCH v3] drm/i915/icl: implement the tc/legacy HPD {dis, }connect flows
On Wed, Aug 01, 2018 at 10:34:41AM -0700, Paulo Zanoni wrote:
> Unlike the other ports, TC ports are not available to use as soon as
> we get a hotplug. The TC PHYs can be shared between multiple
> controllers: display, USB, etc. As a result, handshaking through FIA
> is required around connect and disconnect to cleanly transfer
> ownership with the controller and set the type-C power state.
>
> This patch implements the flow sequences described by our
> specification. We opt to grab ownership of the ports as soon as we get
> the hotplugs in order to simplify the interactions and avoid surprises
> in the user space side. We may consider changing this in the future,
> once we improve our testing capabilities on this area.
>
> v2:
> * This unifies the DP and HDMI patches so we can discuss everything
>at once so people looking at random single patches can actually
>understand the direction.
> * I found out the spec was updated a while ago. There's a small
>difference in the connect flow and the patch was updated for that.
> * Our spec also now gives a good explanation on what is really
>happening. As a result, comments were added.
> * Add some more comments as requested by Rodrigo (Rodrigo).
> v3:
> * Downgrade a DRM_ERROR that shouldn't ever happen but we can't act
>on in case it does (Chris).
>
> BSpec: 21750, 4250.
> Cc: Animesh Manna
> Cc: Rodrigo Vivi
> Signed-off-by: Paulo Zanoni
sorry for taking so long...
thanks for the doc and all other changes.
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6 +++
> drivers/gpu/drm/i915/intel_dp.c | 110
> +-
> drivers/gpu/drm/i915/intel_hdmi.c | 11 ++--
> 3 files changed, 123 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1da1c7743785..a5f4dfe9ebdf 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -10750,4 +10750,10 @@ enum skl_power_gate {
> #define DP_LANE_ASSIGNMENT_MASK(tc_port) (0xf << ((tc_port) * 8))
> #define DP_LANE_ASSIGNMENT(tc_port, x) ((x) << ((tc_port) * 8))
>
> +#define PORT_TX_DFLEXDPPMS _MMIO(0x163890)
> +#define DP_PHY_MODE_STATUS_COMPLETED(tc_port) (1 << (tc_port))
> +
> +#define PORT_TX_DFLEXDPCSSS _MMIO(0x163894)
> +#define DP_PHY_MODE_STATUS_NOT_SAFE(tc_port) (1 << (tc_port))
> +
> #endif /* _I915_REG_H_ */
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index fec21aa3db93..86eded613456 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4818,6 +4818,104 @@ static void icl_update_tc_port_type(struct
> drm_i915_private *dev_priv,
> type_str);
> }
>
> +/*
> + * This function implements the first part of the Connect Flow described by
> our
> + * specification, Gen11 TypeC Programming chapter. The rest of the flow
> (reading
> + * lanes, EDID, etc) is done as needed in the typical places.
> + *
> + * Unlike the other ports, type-C ports are not available to use as soon as
> we
> + * get a hotplug. The type-C PHYs can be shared between multiple controllers:
> + * display, USB, etc. As a result, handshaking through FIA is required around
> + * connect and disconnect to cleanly transfer ownership with the controller
> and
> + * set the type-C power state.
> + *
> + * We could opt to only do the connect flow when we actually try to use the
> AUX
> + * channels or do a modeset, then immediately run the disconnect flow after
> + * usage, but there are some implications on this for a dynamic environment:
> + * things may go away or change behind our backs. So for now our driver is
> + * always trying to acquire ownership of the controller as soon as it gets an
> + * interrupt (or polls state and sees a port is connected) and only gives it
> + * back when it sees a disconnect. Implementation of a more fine-grained
> model
> + * will require a lot of coordination with user space and thorough testing
> for
> + * the extra possible cases.
> + */
> +static bool icl_tc_phy_connect(struct drm_i915_private *dev_priv,
> +struct intel_digital_port *dig_port)
> +{
> + enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
> + u32 val;
> +
> + if (dig_port->tc_type != TC_PORT_LEGACY &&
> + dig_port->tc_type != TC_PORT_TYPEC)
> + return true;
> +
> + val = I915_READ(PORT_TX_DFLEXDPPMS);
> + if (!(val & DP_PHY_MODE_STATUS_COMPLETED(tc_port))) {
> + DRM_DEBUG_KMS("DP PHY for TC port %d not ready\n", tc_port);
> + return false;
> + }
> +
> + /*
> + * This function may be called many times in a row without an HPD event
> + * in between, so try to avoid the write when we can.
> + */
> + val =
[Intel-gfx] [PATCH] drm/i915: protect against division by zero.
Static analyzer tools thinks it is possible to have a division by zero
here.
I don't believe we would really reach this path without any crtc enabled,
but may be good to protect against some unexpected path or behavior.
Fixes: cf1f697acb04 ("drm/i915/skl: distribute DDB based on panel resolution")
Cc: Chris Wilson
Cc: Mahesh Kumar
Cc: Maarten Lankhorst
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_pm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d99e5fabe93c..fac6e159a640 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3878,6 +3878,12 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device
*dev,
pipe_width = hdisplay;
}
+ if (WARN_ON(total_width == 0)) {
+ alloc->start = 0;
+ alloc->end = 0;
+ return;
+ }
+
alloc->start = ddb_size * width_before_pipe / total_width;
alloc->end = ddb_size * (width_before_pipe + pipe_width) / total_width;
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/psr: Add PSR mode/revision to debugfs
On Wed, 2018-08-22 at 11:32 -0700, Dhinakaran Pandiyan wrote: > > On Wed, 2018-08-22 at 10:23 -0700, Azhar Shaikh wrote: > > Log the PSR mode/revision (PSR1 or PSR2) in the debugfs file > > i915_edp_psr_status. > > > > Reviewed-by: Dhinakaran Pandiyan > > > Suggested-by: Dhinakaran Pandiyan > > Signed-off-by: Azhar Shaikh Thanks for writing this patch, I've pushed it. -DK > > --- > > Changes in v4: > > - Fix the rebase error in v3 of adding typecast to bool > > - in i915_edp_psr_status(), which is not needed > > > > Changes in v3: > > - rebased > > > > Changes in v2: > > - Fix checkpatch warning. > > - Add Reviewed-by: from v1 > > > > drivers/gpu/drm/i915/i915_debugfs.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > > b/drivers/gpu/drm/i915/i915_debugfs.c > > index 26b7e5276b15..544ec5cdfe9f 100644 > > --- a/drivers/gpu/drm/i915/i915_debugfs.c > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > > @@ -2708,6 +2708,8 @@ static int i915_edp_psr_status(struct > > seq_file > > *m, void *data) > > intel_runtime_pm_get(dev_priv); > > > > mutex_lock(_priv->psr.lock); > > + seq_printf(m, "PSR mode: %s\n", > > + dev_priv->psr.psr2_enabled ? "PSR2" : "PSR1"); > > seq_printf(m, "Enabled: %s\n", yesno(dev_priv- > > > psr.enabled)); > > > > seq_printf(m, "Busy frontbuffer bits: 0x%03x\n", > >dev_priv->psr.busy_frontbuffer_bits); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 06/18] drm/i915: Store the final plane stride in plane_state
On Fri, 2018-07-20 at 14:06 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's store the final plane stride in the plane state. This avoids
> having to pick betwen the normal vs. rotated stride during hardware
s/betwen/between
> programming. And once we get GTT remapping the plane stride will
> no longer match the fb stride so we'll need a place to store it
> anyway.
>
> v2: Keep checking fb->pitches[0] for cursor as later on we won't
> populate plane_state->color_plane[0].stride for invisible planes
> and we have been checking the cursor fb stride even for invisible
> planes
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 45 +-
> --
> drivers/gpu/drm/i915/intel_drv.h | 10 ++--
> drivers/gpu/drm/i915/intel_sprite.c | 12 +-
> 3 files changed, 45 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3aec789657b1..6184053fd385 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2202,7 +2202,7 @@ u32 intel_fb_xy_to_linear(int x, int y,
> {
> const struct drm_framebuffer *fb = state->base.fb;
> unsigned int cpp = fb->format->cpp[plane];
> - unsigned int pitch = fb->pitches[plane];
> + unsigned int pitch = state->color_plane[plane].stride;
>
> return y * pitch + x * cpp;
> }
> @@ -2259,11 +2259,11 @@ static u32 intel_adjust_tile_offset(int *x,
> int *y,
> static u32 intel_adjust_aligned_offset(int *x, int *y,
> const struct drm_framebuffer
> *fb, int plane,
> unsigned int rotation,
> +unsigned int pitch,
> u32 old_offset, u32 new_offset)
> {
> struct drm_i915_private *dev_priv = to_i915(fb->dev);
> unsigned int cpp = fb->format->cpp[plane];
> - unsigned int pitch = intel_fb_pitch(fb, plane, rotation);
>
> WARN_ON(new_offset > old_offset);
>
> @@ -2305,6 +2305,7 @@ static u32
> intel_plane_adjust_aligned_offset(int *x, int *y,
> {
> return intel_adjust_aligned_offset(x, y, state->base.fb, plane,
> state->base.rotation,
> +state-
> >color_plane[plane].stride,
> old_offset, new_offset);
> }
>
> @@ -2381,7 +2382,7 @@ static u32
> intel_plane_compute_aligned_offset(int *x, int *y,
> struct drm_i915_private *dev_priv = to_i915(intel_plane-
> >base.dev);
> const struct drm_framebuffer *fb = state->base.fb;
> unsigned int rotation = state->base.rotation;
> - int pitch = intel_fb_pitch(fb, plane, rotation);
> + int pitch = state->color_plane[plane].stride;
> u32 alignment;
>
> if (intel_plane->id == PLANE_CURSOR)
> @@ -2408,6 +2409,7 @@ static int intel_fb_offset_to_xy(int *x, int
> *y,
>
> intel_adjust_aligned_offset(x, y,
> fb, plane, DRM_MODE_ROTATE_0,
> + fb->pitches[0],
> fb->offsets[plane], 0);
>
> return 0;
> @@ -2849,6 +2851,9 @@ intel_find_initial_plane_obj(struct intel_crtc
> *intel_crtc,
> return;
>
> valid_fb:
> + intel_state->color_plane[0].stride =
> + intel_fb_pitch(fb, 0, intel_state->base.rotation);
> +
> mutex_lock(>struct_mutex);
> intel_state->vma =
> intel_pin_and_fence_fb_obj(fb,
> @@ -3166,6 +3171,9 @@ int skl_check_plane_surface(const struct
> intel_crtc_state *crtc_state,
> unsigned int rotation = plane_state->base.rotation;
> int ret;
>
> + plane_state->color_plane[0].stride = intel_fb_pitch(fb, 0,
> rotation);
> + plane_state->color_plane[1].stride = intel_fb_pitch(fb, 1,
> rotation);
> +
> if (rotation & DRM_MODE_REFLECT_X &&
> fb->modifier == DRM_FORMAT_MOD_LINEAR) {
> DRM_DEBUG_KMS("horizontal flip is not supported with
> linear surface formats\n");
> @@ -3301,10 +3309,14 @@ int i9xx_check_plane_surface(struct
> intel_plane_state *plane_state)
> {
> struct drm_i915_private *dev_priv =
> to_i915(plane_state->base.plane->dev);
> + const struct drm_framebuffer *fb = plane_state->base.fb;
> + unsigned int rotation = plane_state->base.rotation;
> int src_x = plane_state->base.src.x1 >> 16;
> int src_y = plane_state->base.src.y1 >> 16;
> u32 offset;
>
> + plane_state->color_plane[0].stride = intel_fb_pitch(fb, 0,
> rotation);
> +
> intel_add_fb_offsets(_x, _y, plane_state, 0);
>
> if (INTEL_GEN(dev_priv) >= 4)
> @@ -3315,7 +3327,6 @@ int i9xx_check_plane_surface(struct
> intel_plane_state *plane_state)
>
> /* HSW/BDW do this automagically in hardware */
>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Add PSR mode/revision to debugfs (rev4)
== Series Details == Series: drm/i915/psr: Add PSR mode/revision to debugfs (rev4) URL : https://patchwork.freedesktop.org/series/47902/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4697_full -> Patchwork_9996_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9996_full that come from known issues: === IGT changes === Issues hit igt@drv_suspend@shrink: shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#106886, fdo#103359) igt@gem_ctx_isolation@vcs1-s3: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@gem_ppgtt@blt-vs-render-ctx0: shard-kbl: INCOMPLETE (fdo#106023, fdo#103665) -> PASS fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4697 -> Patchwork_9996 CI_DRM_4697: b68c36de381756889dffa2c8de3206c8bf9a66d2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9996: ad40f970820c5021aaf10dab23fd53301a42c49c @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9996/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/18] drm/i915: Rename the plane_state->main/aux to plane_state->color_plane[]
On Thu, 2018-07-19 at 21:22 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make the main/aux surface stuff a bit more generic by using an array
> of structures. This will allow us to deal with both the main and aux
> surfaces with common code.
Nitpick: consider having a enum { SURFACE_MAIN = 0, SURFACE_AUX } and
use it instead of the magic numbers 0 and 1.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 56 ++--
>
> drivers/gpu/drm/i915/intel_drv.h | 6 +---
> drivers/gpu/drm/i915/intel_fbc.c | 4 +--
> drivers/gpu/drm/i915/intel_sprite.c | 29 ++-
> 4 files changed, 46 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 994685230b97..3aec789657b1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2946,9 +2946,9 @@ static bool
> skl_check_main_ccs_coordinates(struct intel_plane_state *plane_state
> const struct drm_framebuffer *fb = plane_state->base.fb;
> int hsub = fb->format->hsub;
> int vsub = fb->format->vsub;
> - int aux_x = plane_state->aux.x;
> - int aux_y = plane_state->aux.y;
> - u32 aux_offset = plane_state->aux.offset;
> + int aux_x = plane_state->color_plane[1].x;
> + int aux_y = plane_state->color_plane[1].y;
> + u32 aux_offset = plane_state->color_plane[1].offset;
> u32 alignment = intel_surf_alignment(fb, 1);
>
> while (aux_offset >= main_offset && aux_y <= main_y) {
> @@ -2971,9 +2971,9 @@ static bool
> skl_check_main_ccs_coordinates(struct intel_plane_state *plane_state
> if (aux_x != main_x || aux_y != main_y)
> return false;
>
> - plane_state->aux.offset = aux_offset;
> - plane_state->aux.x = aux_x;
> - plane_state->aux.y = aux_y;
> + plane_state->color_plane[1].offset = aux_offset;
> + plane_state->color_plane[1].x = aux_x;
> + plane_state->color_plane[1].y = aux_y;
>
> return true;
> }
> @@ -2994,7 +2994,7 @@ static int skl_check_main_surface(const struct
> intel_crtc_state *crtc_state,
> int pipe_src_w = crtc_state->pipe_src_w;
> int max_width = skl_max_plane_width(fb, 0, rotation);
> int max_height = 4096;
> - u32 alignment, offset, aux_offset = plane_state->aux.offset;
> + u32 alignment, offset, aux_offset = plane_state-
> >color_plane[1].offset;
>
> if (w > max_width || h > max_height) {
> DRM_DEBUG_KMS("requested Y/RGB source size %dx%d too
> big (limit %dx%d)\n",
> @@ -3067,15 +3067,15 @@ static int skl_check_main_surface(const
> struct intel_crtc_state *crtc_state,
> offs
> et, offset - alignment);
> }
>
> - if (x != plane_state->aux.x || y != plane_state->aux.y)
> {
> + if (x != plane_state->color_plane[1].x || y !=
> plane_state->color_plane[1].y) {
> DRM_DEBUG_KMS("Unable to find suitable display
> surface offset due to CCS\n");
> return -EINVAL;
> }
> }
>
> - plane_state->main.offset = offset;
> - plane_state->main.x = x;
> - plane_state->main.y = y;
> + plane_state->color_plane[0].offset = offset;
> + plane_state->color_plane[0].x = x;
> + plane_state->color_plane[0].y = y;
>
> return 0;
> }
> @@ -3125,9 +3125,9 @@ static int skl_check_nv12_aux_surface(struct
> intel_plane_state *plane_state)
> return -EINVAL;
> }
>
> - plane_state->aux.offset = offset;
> - plane_state->aux.x = x;
> - plane_state->aux.y = y;
> + plane_state->color_plane[1].offset = offset;
> + plane_state->color_plane[1].x = x;
> + plane_state->color_plane[1].y = y;
>
> return 0;
> }
> @@ -3152,9 +3152,9 @@ static int skl_check_ccs_aux_surface(struct
> intel_plane_state *plane_state)
> intel_add_fb_offsets(, , plane_state, 1);
> offset = intel_plane_compute_aligned_offset(, ,
> plane_state, 1);
>
> - plane_state->aux.offset = offset;
> - plane_state->aux.x = x * hsub + src_x % hsub;
> - plane_state->aux.y = y * vsub + src_y % vsub;
> + plane_state->color_plane[1].offset = offset;
> + plane_state->color_plane[1].x = x * hsub + src_x % hsub;
> + plane_state->color_plane[1].y = y * vsub + src_y % vsub;
>
> return 0;
> }
> @@ -3198,9 +3198,9 @@ int skl_check_plane_surface(const struct
> intel_crtc_state *crtc_state,
> if (ret)
> return ret;
> } else {
> - plane_state->aux.offset = ~0xfff;
> - plane_state->aux.x = 0;
> - plane_state->aux.y = 0;
> + plane_state->color_plane[1].offset = ~0xfff;
> + plane_state->color_plane[1].x = 0;
> + plane_state->color_plane[1].y = 0;
Re: [Intel-gfx] [PATCH] drm/i915: Add plane alpha blending support, v2.
On Wed, Aug 15, 2018 at 12:34:05PM +0200, Maarten Lankhorst wrote:
> Add plane alpha blending support with the different blend modes.
> This has been tested on a icl to show the correct results,
> on earlier platforms small rounding errors cause issues. But this
> already happens case with fully transparant or fully opaque RGB
> fb's.
>
> The recommended HW workaround is to disable alpha blending when the
> plane alpha is 0 (transparant, hide plane) or 0xff (opaque, disable blending).
> This is easy to implement on any platform, so just do that.
>
> The tests for userspace are also available, and pass on gen11.
>
> Changes since v1:
> - Change mistaken < 0xff0 to 0xff00.
> - Only set PLANE_KEYMSK_ALPHA_ENABLE when plane alpha < 0xff00, ignore blend
> mode.
> - Rework disabling FBC when per pixel alpha is used.
>
> Signed-off-by: Maarten Lankhorst
One question and one minor suggestion inline below, but otherwise,
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/i915_reg.h | 2 +
> drivers/gpu/drm/i915/intel_display.c | 58 +++-
> drivers/gpu/drm/i915/intel_fbc.c | 8
> drivers/gpu/drm/i915/intel_sprite.c | 23 ++-
> 5 files changed, 73 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3fa56b960ef2..29f75da5fa8c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -545,6 +545,8 @@ struct intel_fbc {
> int adjusted_y;
>
> int y;
> +
> + uint16_t pixel_blend_mode;
> } plane;
>
> struct {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 0c9f03dda569..93a1d87cdeb2 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6561,8 +6561,10 @@ enum {
> #define _PLANE_KEYVAL_2_A0x70294
> #define _PLANE_KEYMSK_1_A0x70198
> #define _PLANE_KEYMSK_2_A0x70298
> +#define PLANE_KEYMSK_ALPHA_ENABLE (1 << 31)
> #define _PLANE_KEYMAX_1_A0x701a0
> #define _PLANE_KEYMAX_2_A0x702a0
> +#define PLANE_KEYMAX_ALPHA_SHIFT24
> #define _PLANE_AUX_DIST_1_A 0x701c0
> #define _PLANE_AUX_DIST_2_A 0x702c0
> #define _PLANE_AUX_OFFSET_1_A0x701c4
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a0345e7d3c2b..aedad3674b0d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3167,6 +3167,12 @@ int skl_check_plane_surface(const struct
> intel_crtc_state *crtc_state,
> return -EINVAL;
> }
>
> + /* HW only has 8 bits pixel precision, disable plane if invisible */
> + if (!(plane_state->base.alpha >> 8)) {
> + plane_state->base.visible = false;
> + return 0;
> + }
> +
> if (!plane_state->base.visible)
> return 0;
>
> @@ -3512,30 +3518,39 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
> return 0;
> }
>
> -/*
> - * XXX: For ARBG/ABGR formats we default to expecting scanout buffers
> - * to be already pre-multiplied. We need to add a knob (or a different
> - * DRM_FORMAT) for user-space to configure that.
> - */
> -static u32 skl_plane_ctl_alpha(uint32_t pixel_format)
> +static u32 skl_plane_ctl_alpha(const struct intel_plane_state *plane_state)
> {
> - switch (pixel_format) {
> - case DRM_FORMAT_ABGR:
> - case DRM_FORMAT_ARGB:
> + if (!plane_state->base.fb->format->has_alpha)
> + return PLANE_CTL_ALPHA_DISABLE;
> +
> + switch (plane_state->base.pixel_blend_mode) {
> + case DRM_MODE_BLEND_PIXEL_NONE:
> + return PLANE_CTL_ALPHA_DISABLE;
> + case DRM_MODE_BLEND_PREMULTI:
> return PLANE_CTL_ALPHA_SW_PREMULTIPLY;
> + case DRM_MODE_BLEND_COVERAGE:
> + return PLANE_CTL_ALPHA_HW_PREMULTIPLY;
> default:
> - return PLANE_CTL_ALPHA_DISABLE;
> + MISSING_CASE(plane_state->base.pixel_blend_mode);
> + return 0;
Maybe just add the MISSING_CASE line before the current return? The
macro still expands to 0, so leaving that makes it slightly more clear
what the default fallback is. Same for the glk_ function below.
> }
> }
>
> -static u32 glk_plane_color_ctl_alpha(uint32_t pixel_format)
> +static u32 glk_plane_color_ctl_alpha(const struct intel_plane_state
> *plane_state)
> {
> - switch (pixel_format) {
> - case DRM_FORMAT_ABGR:
> - case DRM_FORMAT_ARGB:
> + if (!plane_state->base.fb->format->has_alpha)
> + return PLANE_COLOR_ALPHA_DISABLE;
> +
> + switch (plane_state->base.pixel_blend_mode) {
> + case
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Add PSR mode/revision to debugfs (rev4)
== Series Details ==
Series: drm/i915/psr: Add PSR mode/revision to debugfs (rev4)
URL : https://patchwork.freedesktop.org/series/47902/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4697 -> Patchwork_9996 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/47902/revisions/4/mbox/
== Known issues ==
Here are the changes found in Patchwork_9996 that come from known issues:
=== IGT changes ===
Issues hit
igt@gem_exec_suspend@basic-s3:
{fi-byt-clapper}: PASS -> INCOMPLETE (fdo#102657)
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#102614)
{igt@pm_rpm@module-reload}:
fi-cnl-psr: PASS -> WARN (fdo#107602)
Possible fixes
igt@debugfs_test@read_all_entries:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
igt@drv_selftest@live_coherency:
fi-gdg-551: DMESG-FAIL (fdo#107164) -> PASS
igt@drv_selftest@live_hangcheck:
fi-bxt-j4205: DMESG-FAIL (fdo#106560) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-skl-guc: FAIL (fdo#103191) -> PASS
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#102657 https://bugs.freedesktop.org/show_bug.cgi?id=102657
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
== Participating hosts (54 -> 47) ==
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-icl-u
== Build changes ==
* Linux: CI_DRM_4697 -> Patchwork_9996
CI_DRM_4697: b68c36de381756889dffa2c8de3206c8bf9a66d2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9996: ad40f970820c5021aaf10dab23fd53301a42c49c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ad40f970820c drm/i915/psr: Add PSR mode/revision to debugfs
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9996/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/18] drm/i915: Use pipe A primary plane .max_stride() as the global stride limit
On Thu, 2018-07-19 at 21:22 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's assume that the primary plane for pipe A has the highest max
> stride of all planes, and we'll use that as the global limit when
> creating a new framebuffer.
Well it was already assuming that but using the new max_stride hook is
way better.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 33 ++--
> -
> 1 file changed, 10 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a09e11e0596f..994685230b97 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14399,31 +14399,18 @@ static
> u32 intel_fb_pitch_limit(struct drm_i915_private *dev_priv,
>uint64_t fb_modifier, uint32_t pixel_format)
> {
> - u32 gen = INTEL_GEN(dev_priv);
> + struct intel_crtc *crtc;
> + struct intel_plane *plane;
>
> - if (gen >= 9) {
> - int cpp = drm_format_plane_cpp(pixel_format, 0);
> + /*
> + * We assume the primary plane for pipe A has
> + * the highest stride limits of them all.
> + */
> + crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A);
> + plane = to_intel_plane(crtc->base.primary);
>
> - /* "The stride in bytes must not exceed the of the size
> of 8K
> - * pixels and 32K bytes."
> - */
> - return min(8192 * cpp, 32768);
> - } else if (gen >= 5 && !HAS_GMCH_DISPLAY(dev_priv)) {
> - return 32*1024;
> - } else if (gen >= 4) {
> - if (fb_modifier == I915_FORMAT_MOD_X_TILED)
> - return 16*1024;
> - else
> - return 32*1024;
> - } else if (gen >= 3) {
> - if (fb_modifier == I915_FORMAT_MOD_X_TILED)
> - return 8*1024;
> - else
> - return 16*1024;
> - } else {
> - /* XXX DSPC is limited to 4k tiled */
> - return 8*1024;
> - }
> + return plane->max_stride(plane, pixel_format, fb_modifier,
> + DRM_MODE_ROTATE_0);
> }
>
> static int intel_framebuffer_init(struct intel_framebuffer
> *intel_fb,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/18] drm/i915: Add .max_stride() plane hook
On Wed, 2018-08-22 at 22:03 +, Souza, Jose wrote:
> On Thu, 2018-07-19 at 21:21 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Each plane may have different stride limitations. Let's add a new
> > plane function to retutn the maximum stride for each plane. There's
> > going to be some use for this outside the .atomic_check() stuff
> > hence
> > the separate hook.
>
> I just not checked the the spec for the VLV and CHV other than that
> LGTM but just take a look to the nitpick bellow:
>
> Reviewed-by: José Roberto de Souza
>
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 46
> >
> > drivers/gpu/drm/i915/intel_drv.h | 10
> > drivers/gpu/drm/i915/intel_sprite.c | 34
> > --
> > 3 files changed, 88 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 5f8304a11482..a09e11e0596f 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3210,6 +3210,31 @@ int skl_check_plane_surface(const struct
> > intel_crtc_state *crtc_state,
> > return 0;
> > }
> >
> > +unsigned int
> > +i9xx_plane_max_stride(struct intel_plane *plane,
> > + u32 pixel_format, u64 modifier,
> > + unsigned int rotation)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> > +
Reviwing 'drm/i915: Use pipe A primary plane .max_stride() as the
global stride limit' I notice that this case was not moved here:
} else if (gen >= 5 && !HAS_GMCH_DISPLAY(dev_priv)) {
return 32*1024;
}
Not relevant anymore?
> > + if (INTEL_GEN(dev_priv) >= 4) {
> > + if (modifier == I915_FORMAT_MOD_X_TILED)
> > + return 16*1024;
> > + else
> > + return 32*1024;
> > + } else if (INTEL_GEN(dev_priv) >= 3) {
> > + if (modifier == I915_FORMAT_MOD_X_TILED)
> > + return 8*1024;
> > + else
> > + return 16*1024;
> > + } else {
> > + if (plane->i9xx_plane == PLANE_C)
> > + return 4*1024;
> > + else
> > + return 8*1024;
> > + }
> > +}
> > +
> > static u32 i9xx_plane_ctl(const struct intel_crtc_state
> > *crtc_state,
> > const struct intel_plane_state *plane_state)
> > {
> > @@ -9672,6 +9697,14 @@ static int intel_check_cursor(struct
> > intel_crtc_state *crtc_state,
> > return 0;
> > }
> >
> > +static unsigned int
> > +i845_cursor_max_stride(struct intel_plane *plane,
> > + u32 pixel_format, u64 modifier,
> > + unsigned int rotation)
> > +{
> > + return 2048;
> > +}
> > +
> > static u32 i845_cursor_ctl(const struct intel_crtc_state
> > *crtc_state,
> >const struct intel_plane_state *plane_state)
> > {
> > @@ -9805,6 +9838,14 @@ static bool i845_cursor_get_hw_state(struct
> > intel_plane *plane,
> > return ret;
> > }
> >
> > +static unsigned int
> > +i9xx_cursor_max_stride(struct intel_plane *plane,
> > + u32 pixel_format, u64 modifier,
> > + unsigned int rotation)
> > +{
> > + return plane->base.dev->mode_config.cursor_width * 4;
> > +}
> > +
> > static u32 i9xx_cursor_ctl(const struct intel_crtc_state
> > *crtc_state,
> >const struct intel_plane_state *plane_state)
> > {
> > @@ -13699,6 +13740,7 @@ intel_primary_plane_create(struct
> > drm_i915_private *dev_priv, enum pipe pipe)
> > else
> > modifiers = skl_format_modifiers_noccs;
> >
> > + primary->max_stride = skl_plane_max_stride;
> > primary->update_plane = skl_update_plane;
> > primary->disable_plane = skl_disable_plane;
> > primary->get_hw_state = skl_plane_get_hw_state;
> > @@ -13709,6 +13751,7 @@ intel_primary_plane_create(struct
> > drm_i915_private *dev_priv, enum pipe pipe)
> > num_formats = ARRAY_SIZE(i965_primary_formats);
> > modifiers = i9xx_format_modifiers;
> >
> > + primary->max_stride = i9xx_plane_max_stride;
> > primary->update_plane = i9xx_update_plane;
> > primary->disable_plane = i9xx_disable_plane;
> > primary->get_hw_state = i9xx_plane_get_hw_state;
> > @@ -13719,6 +13762,7 @@ intel_primary_plane_create(struct
> > drm_i915_private *dev_priv, enum pipe pipe)
> > num_formats = ARRAY_SIZE(i8xx_primary_formats);
> > modifiers = i9xx_format_modifiers;
> >
> > + primary->max_stride = i9xx_plane_max_stride;
> > primary->update_plane = i9xx_update_plane;
> > primary->disable_plane = i9xx_disable_plane;
> > primary->get_hw_state = i9xx_plane_get_hw_state;
> > @@ -13826,11 +13870,13 @@
Re: [Intel-gfx] [PATCH 03/18] drm/i915: Add .max_stride() plane hook
On Thu, 2018-07-19 at 21:21 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Each plane may have different stride limitations. Let's add a new
> plane function to retutn the maximum stride for each plane. There's
> going to be some use for this outside the .atomic_check() stuff hence
> the separate hook.
I just not checked the the spec for the VLV and CHV other than that
LGTM but just take a look to the nitpick bellow:
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 46
>
> drivers/gpu/drm/i915/intel_drv.h | 10
> drivers/gpu/drm/i915/intel_sprite.c | 34 --
> 3 files changed, 88 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5f8304a11482..a09e11e0596f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3210,6 +3210,31 @@ int skl_check_plane_surface(const struct
> intel_crtc_state *crtc_state,
> return 0;
> }
>
> +unsigned int
> +i9xx_plane_max_stride(struct intel_plane *plane,
> + u32 pixel_format, u64 modifier,
> + unsigned int rotation)
> +{
> + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> +
> + if (INTEL_GEN(dev_priv) >= 4) {
> + if (modifier == I915_FORMAT_MOD_X_TILED)
> + return 16*1024;
> + else
> + return 32*1024;
> + } else if (INTEL_GEN(dev_priv) >= 3) {
> + if (modifier == I915_FORMAT_MOD_X_TILED)
> + return 8*1024;
> + else
> + return 16*1024;
> + } else {
> + if (plane->i9xx_plane == PLANE_C)
> + return 4*1024;
> + else
> + return 8*1024;
> + }
> +}
> +
> static u32 i9xx_plane_ctl(const struct intel_crtc_state *crtc_state,
> const struct intel_plane_state *plane_state)
> {
> @@ -9672,6 +9697,14 @@ static int intel_check_cursor(struct
> intel_crtc_state *crtc_state,
> return 0;
> }
>
> +static unsigned int
> +i845_cursor_max_stride(struct intel_plane *plane,
> +u32 pixel_format, u64 modifier,
> +unsigned int rotation)
> +{
> + return 2048;
> +}
> +
> static u32 i845_cursor_ctl(const struct intel_crtc_state
> *crtc_state,
> const struct intel_plane_state *plane_state)
> {
> @@ -9805,6 +9838,14 @@ static bool i845_cursor_get_hw_state(struct
> intel_plane *plane,
> return ret;
> }
>
> +static unsigned int
> +i9xx_cursor_max_stride(struct intel_plane *plane,
> +u32 pixel_format, u64 modifier,
> +unsigned int rotation)
> +{
> + return plane->base.dev->mode_config.cursor_width * 4;
> +}
> +
> static u32 i9xx_cursor_ctl(const struct intel_crtc_state
> *crtc_state,
> const struct intel_plane_state *plane_state)
> {
> @@ -13699,6 +13740,7 @@ intel_primary_plane_create(struct
> drm_i915_private *dev_priv, enum pipe pipe)
> else
> modifiers = skl_format_modifiers_noccs;
>
> + primary->max_stride = skl_plane_max_stride;
> primary->update_plane = skl_update_plane;
> primary->disable_plane = skl_disable_plane;
> primary->get_hw_state = skl_plane_get_hw_state;
> @@ -13709,6 +13751,7 @@ intel_primary_plane_create(struct
> drm_i915_private *dev_priv, enum pipe pipe)
> num_formats = ARRAY_SIZE(i965_primary_formats);
> modifiers = i9xx_format_modifiers;
>
> + primary->max_stride = i9xx_plane_max_stride;
> primary->update_plane = i9xx_update_plane;
> primary->disable_plane = i9xx_disable_plane;
> primary->get_hw_state = i9xx_plane_get_hw_state;
> @@ -13719,6 +13762,7 @@ intel_primary_plane_create(struct
> drm_i915_private *dev_priv, enum pipe pipe)
> num_formats = ARRAY_SIZE(i8xx_primary_formats);
> modifiers = i9xx_format_modifiers;
>
> + primary->max_stride = i9xx_plane_max_stride;
> primary->update_plane = i9xx_update_plane;
> primary->disable_plane = i9xx_disable_plane;
> primary->get_hw_state = i9xx_plane_get_hw_state;
> @@ -13826,11 +13870,13 @@ intel_cursor_plane_create(struct
> drm_i915_private *dev_priv,
> cursor->frontbuffer_bit = INTEL_FRONTBUFFER(pipe, cursor->id);
>
> if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) {
> + cursor->max_stride = i845_cursor_max_stride;
> cursor->update_plane = i845_update_cursor;
> cursor->disable_plane = i845_disable_cursor;
> cursor->get_hw_state = i845_cursor_get_hw_state;
>
Re: [Intel-gfx] [PATCH 02/18] drm/i915: s/tile_offset/aligned_offset/
On Thu, 2018-07-19 at 21:21 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rename some of the tile_offset() functions to aligned_offset() since
> they operate on both linear and tiled functions. And we'll include
> _plane_ in the name of all the variants that take a plane state.
> Should make it more clear which function to use where.
>
Maybe rename the title as it is not doing only
s/tile_offset/aligned_offset/ as described in the commit message and in
code.
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 123 ++---
> --
> drivers/gpu/drm/i915/intel_drv.h | 2 -
> 2 files changed, 63 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 8efff0c56920..5f8304a11482 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2229,13 +2229,13 @@ void intel_add_fb_offsets(int *x, int *y,
> }
> }
>
> -static u32 __intel_adjust_tile_offset(int *x, int *y,
> - unsigned int tile_width,
> - unsigned int tile_height,
> - unsigned int tile_size,
> - unsigned int pitch_tiles,
> - u32 old_offset,
> - u32 new_offset)
> +static u32 intel_adjust_tile_offset(int *x, int *y,
> + unsigned int tile_width,
> + unsigned int tile_height,
> + unsigned int tile_size,
> + unsigned int pitch_tiles,
> + u32 old_offset,
> + u32 new_offset)
> {
> unsigned int pitch_pixels = pitch_tiles * tile_width;
> unsigned int tiles;
> @@ -2256,12 +2256,12 @@ static u32 __intel_adjust_tile_offset(int *x,
> int *y,
> return new_offset;
> }
>
> -static u32 _intel_adjust_tile_offset(int *x, int *y,
> - const struct drm_framebuffer *fb,
> int plane,
> - unsigned int rotation,
> - u32 old_offset, u32 new_offset)
> +static u32 intel_adjust_aligned_offset(int *x, int *y,
> +const struct drm_framebuffer
> *fb, int plane,
> +unsigned int rotation,
> +u32 old_offset, u32 new_offset)
> {
> - const struct drm_i915_private *dev_priv = to_i915(fb->dev);
> + struct drm_i915_private *dev_priv = to_i915(fb->dev);
> unsigned int cpp = fb->format->cpp[plane];
> unsigned int pitch = intel_fb_pitch(fb, plane, rotation);
>
> @@ -2281,9 +2281,9 @@ static u32 _intel_adjust_tile_offset(int *x,
> int *y,
> pitch_tiles = pitch / (tile_width * cpp);
> }
>
> - __intel_adjust_tile_offset(x, y, tile_width,
> tile_height,
> -tile_size, pitch_tiles,
> -old_offset, new_offset);
> + intel_adjust_tile_offset(x, y, tile_width, tile_height,
> + tile_size, pitch_tiles,
> + old_offset, new_offset);
> } else {
> old_offset += *y * pitch + *x * cpp;
>
> @@ -2298,17 +2298,18 @@ static u32 _intel_adjust_tile_offset(int *x,
> int *y,
> * Adjust the tile offset by moving the difference into
> * the x/y offsets.
> */
> -static u32 intel_adjust_tile_offset(int *x, int *y,
> - const struct intel_plane_state
> *state, int plane,
> - u32 old_offset, u32 new_offset)
> +static u32 intel_plane_adjust_aligned_offset(int *x, int *y,
> + const struct
> intel_plane_state *state,
> + int plane,
> + u32 old_offset, u32
> new_offset)
> {
> - return _intel_adjust_tile_offset(x, y, state->base.fb, plane,
> - state->base.rotation,
> - old_offset, new_offset);
> + return intel_adjust_aligned_offset(x, y, state->base.fb, plane,
> +state->base.rotation,
> +old_offset, new_offset);
> }
>
> /*
> - * Computes the linear offset to the base tile and adjusts
> + * Computes the aligned offset to the base tile and adjusts
> * x, y. bytes per pixel is assumed to be a power-of-two.
> *
> * In the 90/270 rotated case, x and y are assumed
> @@ -2321,12 +2322,12 @@ static u32 intel_adjust_tile_offset(int *x,
> int *y,
> * used. This is why the user has
[Intel-gfx] ✓ Fi.CI.IGT: success for Possible use_mm() mis-uses
== Series Details == Series: Possible use_mm() mis-uses URL : https://patchwork.freedesktop.org/series/48584/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4697_full -> Patchwork_9995_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9995_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9995_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9995_full: === IGT changes === Warnings igt@kms_vblank@crtc-id: shard-snb: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9995_full that come from known issues: === IGT changes === Issues hit igt@gem_ctx_isolation@vcs1-s3: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@gem_exec_await@wide-contexts: shard-kbl: PASS -> FAIL (fdo#105900) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) shard-kbl: PASS -> FAIL (fdo#99912) fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4697 -> Patchwork_9995 CI_DRM_4697: b68c36de381756889dffa2c8de3206c8bf9a66d2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9995: 8fa6553a26506a13ffcdcaf4cd6523f49fb4c9db @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9995/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2] drm/i915: Add a small wrapper to check for CCS modifiers. (rev2)
== Series Details == Series: series starting with [v2] drm/i915: Add a small wrapper to check for CCS modifiers. (rev2) URL : https://patchwork.freedesktop.org/series/48524/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4697_full -> Patchwork_9994_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9994_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9994_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9994_full: === IGT changes === Possible regressions igt@gem_eio@reset-stress: shard-kbl: PASS -> FAIL == Known issues == Here are the changes found in Patchwork_9994_full that come from known issues: === IGT changes === Issues hit igt@gem_ctx_isolation@vcs1-s3: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: PASS -> INCOMPLETE (fdo#106023, fdo#103665) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4697 -> Patchwork_9994 CI_DRM_4697: b68c36de381756889dffa2c8de3206c8bf9a66d2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9994: 34f47ae1580b75ec1cdc1f5666caba114ca9743c @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9994/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Possible use_mm() mis-uses
== Series Details ==
Series: Possible use_mm() mis-uses
URL : https://patchwork.freedesktop.org/series/48584/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4697 -> Patchwork_9995 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48584/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9995:
=== IGT changes ===
Warnings
{igt@pm_rpm@module-reload}:
fi-cnl-psr: PASS -> SKIP
== Known issues ==
Here are the changes found in Patchwork_9995 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_pipe_crc_basic@read-crc-pipe-a:
{fi-byt-clapper}: PASS -> FAIL (fdo#107362)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
{fi-byt-clapper}: PASS -> FAIL (fdo#107362, fdo#103191)
Possible fixes
igt@debugfs_test@read_all_entries:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
igt@drv_selftest@live_coherency:
fi-gdg-551: DMESG-FAIL (fdo#107164) -> PASS
igt@drv_selftest@live_hangcheck:
fi-bxt-j4205: DMESG-FAIL (fdo#106560) -> PASS
igt@kms_frontbuffer_tracking@basic:
{fi-byt-clapper}: FAIL (fdo#103167) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-skl-guc: FAIL (fdo#103191) -> PASS
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
== Participating hosts (54 -> 49) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4697 -> Patchwork_9995
CI_DRM_4697: b68c36de381756889dffa2c8de3206c8bf9a66d2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9995: 8fa6553a26506a13ffcdcaf4cd6523f49fb4c9db @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8fa6553a2650 Possible use_mm() mis-uses
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9995/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 12:44 PM Felix Kuehling wrote: > > You're right, but that's a bit fragile and convoluted. I'll fix KFD to > handle this more robustly. See the attached (untested) patch. Yes, this patch that makes the whole "has to use current mm" or uses "get_task_mm()" looks good from a VM< worry standpoint. Thanks. > And > obviously that opaque pointer didn't work as intended. It just gets > promoted to an mm_struct * without a warning from the compiler. Maybe I > should change that to a long to make abuse easier to spot. Using a "void *" is actually just about the worst possible type for something that should be a cookie, because it silently translates to any pointer. "long" is actually not much better, becuase it will silently convert to any integer type. A good fairly type-safe cookie type is actually this: typedef volatile const struct no_such_struct *cookie_ptr_t; and now something of type "cookie_ptr_t" is actually very hard to convert to other types by mistake. Note that the "volatile const" is not just random noise - it's so that it won't even convert without warnings to things that take a "const void *" as an argument (like, say, the source of 'memcpy()'). So you almost _have_ to explicitly cast it to use it. Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Possible use_mm() mis-uses
== Series Details ==
Series: Possible use_mm() mis-uses
URL : https://patchwork.freedesktop.org/series/48584/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8fa6553a2650 Possible use_mm() mis-uses
-:114: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#114:
>>> * Opaque pointer to mm_struct. We don't hold a reference to
-:165: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit
<12+ chars of sha1> ("")' - ie: 'commit fatal: bad o
("3ac2307cf362c1aec")'
#165:
>From 05cdd85427c8ce6a05435df3ac2307cf362c1aec Mon Sep 17 00:00:00 2001
-:174: ERROR:GERRIT_CHANGE_ID: Remove Gerrit Change-Id's before submitting
upstream.
#174:
Change-Id: Id42976075adce45007c10481c6a8f29df67e54a9
total: 2 errors, 1 warnings, 0 checks, 80 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 10:58 PM Linus Torvalds wrote: > > On Wed, Aug 22, 2018 at 12:37 PM Oded Gabbay wrote: > > > > Having said that, I think we *are* protected by the mmu_notifier > > release because if the process suddenly dies, we will gracefully clean > > the process's data in our driver and on the H/W before returning to > > the mm core code. And before we return to the mm core code, we set the > > mm pointer to NULL. And the graceful cleaning should be serialized > > with the load_hqd uses. > > So I'm a bit nervous about the mmu_notifier model (and the largely > equivalent exit_aio() model for the USB gardget AIO uses). > > The reason I'm nervous about it is that the mmu_notifier() gets called > only after the mm_users count has already been decremented to zero > (and the exact same thing goes for exit_aio()). > > Now that's fine if you actually get rid of all accesses in > mmu_notifier_release() or in exit_aio(), because the page tables still > exist at that point - they are in the process of being torn down, but > they haven't been torn down yet. > > But for something like a kernel thread doing use_mm(), the thing that > worries me is a pattern something like this: > > kwork thread exit thread > > > mmput() -> > mm_users goes to zero > > use_mm(mmptr); > .. > > mmu_notifier_release(); > exit_mm() -> > exit_aio() > > and the pattern is basically the same regatdless of whether you use > mmu_notifier_release() or depend on some exit_aio() flushing your aio > work: the use_mm() can be called with a mm that has already had its > mm_users count decremented to zero, and that is now scheduled to be > free'd. > > Does it "work"? Yes. Kind of. At least if the mmu notifier and/or > exit_aio() actually makes sure to wait for any kwork thread thing. But > it's a bit of a worrisome pattern. > >Linus Yes, agreed, and that's why we will be on the safe side and eliminate this pattern from our code and make sure we won't add this pattern in the future. Oded ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915: Add a small wrapper to check for CCS modifiers. (rev2)
== Series Details ==
Series: series starting with [v2] drm/i915: Add a small wrapper to check for
CCS modifiers. (rev2)
URL : https://patchwork.freedesktop.org/series/48524/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4697 -> Patchwork_9994 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48524/revisions/2/mbox/
== Known issues ==
Here are the changes found in Patchwork_9994 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
{fi-kbl-8809g}: PASS -> DMESG-FAIL (fdo#106947, fdo#106560)
{igt@pm_rpm@module-reload}:
fi-cnl-psr: PASS -> WARN (fdo#107602)
Possible fixes
igt@debugfs_test@read_all_entries:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
igt@drv_selftest@live_coherency:
fi-gdg-551: DMESG-FAIL (fdo#107164) -> PASS
igt@drv_selftest@live_hangcheck:
fi-bxt-j4205: DMESG-FAIL (fdo#106560) -> PASS
igt@kms_frontbuffer_tracking@basic:
{fi-byt-clapper}: FAIL (fdo#103167) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-skl-guc: FAIL (fdo#103191) -> PASS
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
== Participating hosts (54 -> 48) ==
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600
== Build changes ==
* Linux: CI_DRM_4697 -> Patchwork_9994
CI_DRM_4697: b68c36de381756889dffa2c8de3206c8bf9a66d2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9994: 34f47ae1580b75ec1cdc1f5666caba114ca9743c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
34f47ae1580b drm/i915: Rename PLANE_CTL_DECOMPRESSION_ENABLE
d077a8e50b7f drm/i915: Add a small wrapper to check for CCS modifiers.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9994/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 12:37 PM Oded Gabbay wrote:
>
> Having said that, I think we *are* protected by the mmu_notifier
> release because if the process suddenly dies, we will gracefully clean
> the process's data in our driver and on the H/W before returning to
> the mm core code. And before we return to the mm core code, we set the
> mm pointer to NULL. And the graceful cleaning should be serialized
> with the load_hqd uses.
So I'm a bit nervous about the mmu_notifier model (and the largely
equivalent exit_aio() model for the USB gardget AIO uses).
The reason I'm nervous about it is that the mmu_notifier() gets called
only after the mm_users count has already been decremented to zero
(and the exact same thing goes for exit_aio()).
Now that's fine if you actually get rid of all accesses in
mmu_notifier_release() or in exit_aio(), because the page tables still
exist at that point - they are in the process of being torn down, but
they haven't been torn down yet.
But for something like a kernel thread doing use_mm(), the thing that
worries me is a pattern something like this:
kwork thread exit thread
mmput() ->
mm_users goes to zero
use_mm(mmptr);
..
mmu_notifier_release();
exit_mm() ->
exit_aio()
and the pattern is basically the same regatdless of whether you use
mmu_notifier_release() or depend on some exit_aio() flushing your aio
work: the use_mm() can be called with a mm that has already had its
mm_users count decremented to zero, and that is now scheduled to be
free'd.
Does it "work"? Yes. Kind of. At least if the mmu notifier and/or
exit_aio() actually makes sure to wait for any kwork thread thing. But
it's a bit of a worrisome pattern.
Linus
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible use_mm() mis-uses
On 2018-08-22 02:13 PM, Christian König wrote: > Adding Felix because the KFD part of amdgpu is actually his > responsibility. > > If I'm not completely mistaken the release callback of the > mmu_notifier should take care of that for amdgpu. You're right, but that's a bit fragile and convoluted. I'll fix KFD to handle this more robustly. See the attached (untested) patch. And obviously that opaque pointer didn't work as intended. It just gets promoted to an mm_struct * without a warning from the compiler. Maybe I should change that to a long to make abuse easier to spot. Regards, Felix > > Regards, > Christian. > > Am 22.08.2018 um 18:44 schrieb Linus Torvalds: >> Guys and gals, >> this is a *very* random list of people on the recipients list, but we >> had a subtle TLB shootdown issue in the VM, and that brought up some >> issues when people then went through the code more carefully. >> >> I think we have a handle on the TLB shootdown bug itself. But when >> people were discussing all the possible situations, one thing that >> came up was "use_mm()" that takes a mm, and makes it temporarily the >> mm for a kernel thread (until "unuse_mm()", duh). >> >> And it turns out that some of those uses are definitely wrong, some of >> them are right, and some of them are suspect or at least so overly >> complicated that it's hard for the VM people to know if they are ok. >> >> Basically, the rule for "use_mm()" is that the mm in question *has* to >> have a valid page table associated with it over the whole use_mm() -> >> unuse_mm() sequence. That may sound obvious, and I guess it actually >> is so obvious that there isn't even a comment about it, but the actual >> users are showing that it's sadly apparently not so obvious after all. >> >> There is one user that uses the "obviously correct" model: the vhost >> driver does a "mmget()" and "mmput()" pair around its use of it, >> thanks to vhost_dev_set_owner() doing a >> >> dev->mm = get_task_mm(current); >> >> to look up the mm, and then the teardown case does a >> >> if (dev->mm) >> mmput(dev->mm); >> dev->mm = NULL; >> >> This is the *right* sequence. A gold star to the vhost people. >> >> Sadly, the vhost people are the only ones who seem to get things >> unquestionably right. And some of those gold star people are also >> apparently involved in the cases that didn't get things right. >> >> An example of something that *isn't* right, is the i915 kvm interface, >> which does >> >> use_mm(kvm->mm); >> >> on an mm that was initialized in virt/kvm/kvm_main.c using >> >> mmgrab(current->mm); >> kvm->mm = current->mm; >> >> which is *not* right. Using "mmgrab()" does indeed guarantee the >> lifetime of the 'struct mm_struct' itself, but it does *not* guarantee >> the lifetime of the page tables. You need to use "mmget()" and >> "mmput()", which get the reference to the actual process address >> space! >> >> Now, it is *possible* that the kvm use is correct too, because kvm >> does register a mmu_notifier chain, and in theory you can avoid the >> proper refcounting by just making sure the mmu "release" notifier >> kills any existing uses, but I don't really see kvm doing that. Kvm >> does register a release notifier, but that just flushes the shadow >> page tables, it doesn't kill any use_mm() use by some i915 use case. >> >> So while the vhost use looks right, the kvm/i915 use looks definitely >> wrong. >> >> The other users of "use_mm()" and "unuse_mm()" are less >> black-and-white right vs wrong.. >> >> One of the complex ones is the amdgpu driver. It does a >> "use_mm(mmptr)" deep deep in the guts of a macro that ends up being >> used in fa few places, and it's very hard to tell if it's right. >> >> It looks almost certainly buggy (there is no mmget/mmput to get the >> refcount), but there _is_ a "release" mmu_notifier function and that >> one - unlike the kvm case - looks like it might actually be trying to >> flush the existing pending users of that mm. >> >> But on the whole, I'm suspicious of the amdgpu use. It smells. Jann >> Horn pointed out that even if it migth be ok due to the mmu_notifier, >> the comments are garbage: >> >>> Where "process" in the uniquely-named "struct queue" is a "struct >>> kfd_process"; that struct's definition has this comment in it: >>> >>> /* >>> * Opaque pointer to mm_struct. We don't hold a reference to >>> * it so it should never be dereferenced from here. This is >>> * only used for looking up processes by their mm. >>> */ >>> void *mm; >>> >>> So I think either that comment is wrong, or their code is wrong? >> so I'm chalking the amdgpu use up in the "broken" column. >> >> It's also actually quite hard to synchronze with some other kernel >> worker thread correctly, so just on general principles, if you use >> "use_mm()" it really really should be on something that you've >> properly gotten a
[Intel-gfx] [PULL] drm-misc-next-fixes
Hi Dave, A couple fixes for you that didn't quite make your -rc1 pull last week. I'm sending this since Gustavo is busy organizing linuxdev-br. drm-misc-next-fixes-2018-08-22: - Add an unprepare delay to the tv123wam panel (Sean) - Update seanpaul's email in MAINTAINERS (Sean) Cc: seanp...@chromium.org Cc: s...@poorly.run Cheers, Sean The following changes since commit 2ead1be54b22ccdc93d3030172993e363128f1b4: drm/vkms: Fix connector leak at the module removal (2018-07-28 16:09:39 -0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-08-22 for you to fetch changes up to 4acd8d01a2393f2145ad1db10b2d5c764582a98d: MAINTAINERS: drm-misc: Change seanpaul's email address (2018-08-16 11:48:24 -0400) - Add an unprepare delay to the tv123wam panel (Sean) - Update seanpaul's email in MAINTAINERS (Sean) Cc: seanp...@chromium.org Cc: s...@poorly.run Sean Paul (2): drm/panel: simple: tv123wam: Add unprepare delay MAINTAINERS: drm-misc: Change seanpaul's email address MAINTAINERS | 2 +- drivers/gpu/drm/panel/panel-simple.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Add a small wrapper to check for CCS modifiers.
Code looks cleaner with modifiers hidden inside this wrapper.
v2: Remove const qualifier (Ville)
Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 21 +++--
drivers/gpu/drm/i915/intel_display.h | 1 +
drivers/gpu/drm/i915/intel_sprite.c | 3 +--
3 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ad0f0e5389d9..85062d07b201 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2474,6 +2474,12 @@ intel_get_format_info(const struct drm_mode_fb_cmd2 *cmd)
}
}
+bool is_ccs_modifier(u64 modifier)
+{
+ return modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
+ modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
+}
+
static int
intel_fill_fb_info(struct drm_i915_private *dev_priv,
struct drm_framebuffer *fb)
@@ -2504,8 +2510,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
return ret;
}
- if ((fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
-fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) && i == 1) {
+ if (is_ccs_modifier(fb->modifier) && i == 1) {
int hsub = fb->format->hsub;
int vsub = fb->format->vsub;
int tile_width, tile_height;
@@ -3054,8 +3059,7 @@ static int skl_check_main_surface(const struct
intel_crtc_state *crtc_state,
* CCS AUX surface doesn't have its own x/y offsets, we must make sure
* they match with the main surface x/y offsets.
*/
- if (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
- fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) {
+ if (is_ccs_modifier(fb->modifier)) {
while (!skl_check_main_ccs_coordinates(plane_state, x, y,
offset)) {
if (offset == 0)
break;
@@ -3189,8 +3193,7 @@ int skl_check_plane_surface(const struct intel_crtc_state
*crtc_state,
ret = skl_check_nv12_aux_surface(plane_state);
if (ret)
return ret;
- } else if (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
- fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) {
+ } else if (is_ccs_modifier(fb->modifier)) {
ret = skl_check_ccs_aux_surface(plane_state);
if (ret)
return ret;
@@ -13399,8 +13402,7 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
- if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
- modifier == I915_FORMAT_MOD_Y_TILED_CCS)
+ if (is_ccs_modifier(modifier))
return true;
/* fall through */
case DRM_FORMAT_RGB565:
@@ -14596,8 +14598,7 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
* potential runtime errors at plane configuration time.
*/
if (IS_GEN9(dev_priv) && i == 0 && fb->width > 3840 &&
- (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
-fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS))
+ is_ccs_modifier(fb->modifier))
stride_alignment *= 4;
if (fb->pitches[i] & (stride_alignment - 1)) {
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index a04c5a495a2b..43f080c6538d 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -381,4 +381,5 @@ void intel_link_compute_m_n(int bpp, int nlanes,
struct intel_link_m_n *m_n,
bool reduce_m_n);
+bool is_ccs_modifier(u64 modifier);
#endif
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 774bfb03c5d9..c286dda625e4 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1409,8 +1409,7 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
- if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
- modifier == I915_FORMAT_MOD_Y_TILED_CCS)
+ if (is_ccs_modifier(modifier))
return true;
/* fall through */
case DRM_FORMAT_RGB565:
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 7:44 PM Linus Torvalds wrote: > One of the complex ones is the amdgpu driver. It does a > "use_mm(mmptr)" deep deep in the guts of a macro that ends up being > used in fa few places, and it's very hard to tell if it's right. > > It looks almost certainly buggy (there is no mmget/mmput to get the > refcount), but there _is_ a "release" mmu_notifier function and that > one - unlike the kvm case - looks like it might actually be trying to > flush the existing pending users of that mm. > > But on the whole, I'm suspicious of the amdgpu use. It smells. Jann > Horn pointed out that even if it migth be ok due to the mmu_notifier, > the comments are garbage: > > > Where "process" in the uniquely-named "struct queue" is a "struct > > kfd_process"; that struct's definition has this comment in it: > > > >/* > > * Opaque pointer to mm_struct. We don't hold a reference to > > * it so it should never be dereferenced from here. This is > > * only used for looking up processes by their mm. > > */ > >void *mm; > > > > So I think either that comment is wrong, or their code is wrong? > > so I'm chalking the amdgpu use up in the "broken" column. > Hello Linus, I looked at the amdkfd code and indeed the comment does not match the actual code because the mm pointer is clearly dereferenced directly in the macro you mentioned (read_user_wptr). That macro is used in the code path of loading a descriptor to the H/W (load_hqd). That function is called in several cases, where in some of them we are in the context of the calling process, but in others we are in a kernel thread context (hence the use_mm). That's why we check these two situations inside that macro and only do use_mm if we are in kernel thread. We need to fix that behavior and obviously make sure that in future code we don't cast this pointer to mm_struct* and derereference it directly. Actually, the original code had "mm_struct *mm" instead of "void *mm" in the structure, and I think the reason we changed it to void* is to "make sure" that we won't dereference it directly, but clearly that failed :( Having said that, I think we *are* protected by the mmu_notifier release because if the process suddenly dies, we will gracefully clean the process's data in our driver and on the H/W before returning to the mm core code. And before we return to the mm core code, we set the mm pointer to NULL. And the graceful cleaning should be serialized with the load_hqd uses. Felix, do you have anything to add here that I might have missed ? Thanks, Oded ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible use_mm() mis-uses
Hi Linus: Thanks for letting us know that. We would fix this ASAP. The kvmgt.c module is a part of GVT-g code. It's our fault that we didn't find this mis-uses, not i915 or KVM guys. Wish they would feel better after seeing this message. Thanks, Zhi. On 08/23/18 00:44, Linus Torvalds wrote: Guys and gals, this is a *very* random list of people on the recipients list, but we had a subtle TLB shootdown issue in the VM, and that brought up some issues when people then went through the code more carefully. I think we have a handle on the TLB shootdown bug itself. But when people were discussing all the possible situations, one thing that came up was "use_mm()" that takes a mm, and makes it temporarily the mm for a kernel thread (until "unuse_mm()", duh). And it turns out that some of those uses are definitely wrong, some of them are right, and some of them are suspect or at least so overly complicated that it's hard for the VM people to know if they are ok. Basically, the rule for "use_mm()" is that the mm in question *has* to have a valid page table associated with it over the whole use_mm() -> unuse_mm() sequence. That may sound obvious, and I guess it actually is so obvious that there isn't even a comment about it, but the actual users are showing that it's sadly apparently not so obvious after all. There is one user that uses the "obviously correct" model: the vhost driver does a "mmget()" and "mmput()" pair around its use of it, thanks to vhost_dev_set_owner() doing a dev->mm = get_task_mm(current); to look up the mm, and then the teardown case does a if (dev->mm) mmput(dev->mm); dev->mm = NULL; This is the *right* sequence. A gold star to the vhost people. Sadly, the vhost people are the only ones who seem to get things unquestionably right. And some of those gold star people are also apparently involved in the cases that didn't get things right. An example of something that *isn't* right, is the i915 kvm interface, which does use_mm(kvm->mm); on an mm that was initialized in virt/kvm/kvm_main.c using mmgrab(current->mm); kvm->mm = current->mm; which is *not* right. Using "mmgrab()" does indeed guarantee the lifetime of the 'struct mm_struct' itself, but it does *not* guarantee the lifetime of the page tables. You need to use "mmget()" and "mmput()", which get the reference to the actual process address space! Now, it is *possible* that the kvm use is correct too, because kvm does register a mmu_notifier chain, and in theory you can avoid the proper refcounting by just making sure the mmu "release" notifier kills any existing uses, but I don't really see kvm doing that. Kvm does register a release notifier, but that just flushes the shadow page tables, it doesn't kill any use_mm() use by some i915 use case. So while the vhost use looks right, the kvm/i915 use looks definitely wrong. The other users of "use_mm()" and "unuse_mm()" are less black-and-white right vs wrong.. One of the complex ones is the amdgpu driver. It does a "use_mm(mmptr)" deep deep in the guts of a macro that ends up being used in fa few places, and it's very hard to tell if it's right. It looks almost certainly buggy (there is no mmget/mmput to get the refcount), but there _is_ a "release" mmu_notifier function and that one - unlike the kvm case - looks like it might actually be trying to flush the existing pending users of that mm. But on the whole, I'm suspicious of the amdgpu use. It smells. Jann Horn pointed out that even if it migth be ok due to the mmu_notifier, the comments are garbage: Where "process" in the uniquely-named "struct queue" is a "struct kfd_process"; that struct's definition has this comment in it: /* * Opaque pointer to mm_struct. We don't hold a reference to * it so it should never be dereferenced from here. This is * only used for looking up processes by their mm. */ void *mm; So I think either that comment is wrong, or their code is wrong? so I'm chalking the amdgpu use up in the "broken" column. It's also actually quite hard to synchronze with some other kernel worker thread correctly, so just on general principles, if you use "use_mm()" it really really should be on something that you've properly gotten a mm refcount on with mmget(). Really. Even if you try to synchronize things. The two final cases are two uses in the USB gadget driver. Again, they don't have the proper mmget/mmput, but they may br ok simply because the uses are done for AIO, and the VM teardown is preceded by an AIO teardown, so the proper serialization may come in from that. Anyway, sorry for the long email, and the big list of participants and odd mailing lists, but I'd really like people to look at their "use_mm()" cases, and ask themselves if they have done enough to guarantee that the full mm exists. Again, "mmgrab()" is *not* enough on its own. You need either
Re: [Intel-gfx] Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 11:33 AM Linus Torvalds wrote: > > On Wed, Aug 22, 2018 at 11:21 AM Paolo Bonzini wrote: > > > > Yes, KVM is correct but the i915 bits are at least fishy. It's probably > > as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init > > and kvmgt_guest_exit, or maybe mmget_not_zero. > > Definitely mmget_not_zero(). If it was just mmgrab()'ed earlier, the > actual page tables might already be gone. Side note: we _could_ do the mmget_not_zero() inside use_mm() itself, if we just knew that the mm was at least mmgrab()'ed correctly. But for some of the uses, even that isn't clear. It's not entirely obvious that the "struct mm_struct" exists _at_all_ at that point, and that a mmget_not_zero() wouldn't just have some use-after-free access. Again, independent lifetime rules could show that this isn't the case (ie "exit_aio() is always called before exit_mmap(), and kill_ioctx() takes care of it all"), but it would be good to have the users of "use_mm()" actually verify their lifetime rules are correct and enforced. Because quite often, the lifetime rule might nbot be a mmu notifier or aio_exit at all, but just be "oh, the user won't exit until this is all done". But do you *control* the user? What if the user is buggy? Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/syncobj: Drop add/remove_callback from driver interface
On Wed, Aug 22, 2018 at 11:09:21AM -0500, Jason Ekstrand wrote:
> Fine with me.
>
> Reviewed-by: Jason Ekstrand
Thanks for the review, applied to drm-misc-next.
-Daniel
>
> On Wed, Aug 22, 2018 at 4:29 AM Daniel Vetter
> wrote:
>
> > This is used for handling future fences. Currently no driver use
> > these, and I think given the new timeline fence proposed by KHR it
> > would be better to have a more abstract interface for future fences.
> > Could be something simple like a struct dma_future_fence plus a
> > function to add a callback or wait for the fence to materialize.
> >
> > Then syncobj (and anything else really) could grow new functions to
> > expose these two drivers. Normal dma_fence would then keep the nice
> > guarantee that they will always signal (and through ordering, be
> > deadlock free). dma_future_fence would then be the tricky one.
> >
> > This also fixes sphinx complaining about the kerneldoc.
> >
> > Cc: Jason Ekstrand
> > Cc: Dave Airlie
> > Cc: Chris Wilson
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_syncobj.c | 15 ---
> > include/drm/drm_syncobj.h | 5 -
> > 2 files changed, 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> > index adb3cb27d31e..3a8837c49639 100644
> > --- a/drivers/gpu/drm/drm_syncobj.c
> > +++ b/drivers/gpu/drm/drm_syncobj.c
> > @@ -120,14 +120,6 @@ static int
> > drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
> > return ret;
> > }
> >
> > -/**
> > - * drm_syncobj_add_callback - adds a callback to syncobj::cb_list
> > - * @syncobj: Sync object to which to add the callback
> > - * @cb: Callback to add
> > - * @func: Func to use when initializing the drm_syncobj_cb struct
> > - *
> > - * This adds a callback to be called next time the fence is replaced
> > - */
> > void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
> > struct drm_syncobj_cb *cb,
> > drm_syncobj_func_t func)
> > @@ -136,13 +128,7 @@ void drm_syncobj_add_callback(struct drm_syncobj
> > *syncobj,
> > drm_syncobj_add_callback_locked(syncobj, cb, func);
> > spin_unlock(>lock);
> > }
> > -EXPORT_SYMBOL(drm_syncobj_add_callback);
> >
> > -/**
> > - * drm_syncobj_add_callback - removes a callback to syncobj::cb_list
> > - * @syncobj: Sync object from which to remove the callback
> > - * @cb: Callback to remove
> > - */
> > void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
> > struct drm_syncobj_cb *cb)
> > {
> > @@ -150,7 +136,6 @@ void drm_syncobj_remove_callback(struct drm_syncobj
> > *syncobj,
> > list_del_init(>node);
> > spin_unlock(>lock);
> > }
> > -EXPORT_SYMBOL(drm_syncobj_remove_callback);
> >
> > /**
> > * drm_syncobj_replace_fence - replace fence in a sync object.
> > diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
> > index 3980602472c0..e419c79ba94d 100644
> > --- a/include/drm/drm_syncobj.h
> > +++ b/include/drm/drm_syncobj.h
> > @@ -131,11 +131,6 @@ drm_syncobj_fence_get(struct drm_syncobj *syncobj)
> >
> > struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
> > u32 handle);
> > -void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
> > - struct drm_syncobj_cb *cb,
> > - drm_syncobj_func_t func);
> > -void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
> > -struct drm_syncobj_cb *cb);
> > void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
> >struct dma_fence *fence);
> > int drm_syncobj_find_fence(struct drm_file *file_private,
> > --
> > 2.18.0
> >
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 11:21 AM Paolo Bonzini wrote: > > Yes, KVM is correct but the i915 bits are at least fishy. It's probably > as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init > and kvmgt_guest_exit, or maybe mmget_not_zero. Definitely mmget_not_zero(). If it was just mmgrab()'ed earlier, the actual page tables might already be gone. Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/psr: Add PSR mode/revision to debugfs
On Wed, 2018-08-22 at 10:23 -0700, Azhar Shaikh wrote: > Log the PSR mode/revision (PSR1 or PSR2) in the debugfs file > i915_edp_psr_status. > Reviewed-by: Dhinakaran Pandiyan > Suggested-by: Dhinakaran Pandiyan > Signed-off-by: Azhar Shaikh > --- > Changes in v4: > - Fix the rebase error in v3 of adding typecast to bool > - in i915_edp_psr_status(), which is not needed > > Changes in v3: > - rebased > > Changes in v2: > - Fix checkpatch warning. > - Add Reviewed-by: from v1 > > drivers/gpu/drm/i915/i915_debugfs.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index 26b7e5276b15..544ec5cdfe9f 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -2708,6 +2708,8 @@ static int i915_edp_psr_status(struct seq_file > *m, void *data) > intel_runtime_pm_get(dev_priv); > > mutex_lock(_priv->psr.lock); > + seq_printf(m, "PSR mode: %s\n", > +dev_priv->psr.psr2_enabled ? "PSR2" : "PSR1"); > seq_printf(m, "Enabled: %s\n", yesno(dev_priv- > >psr.enabled)); > seq_printf(m, "Busy frontbuffer bits: 0x%03x\n", > dev_priv->psr.busy_frontbuffer_bits); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible use_mm() mis-uses
On 22/08/2018 18:44, Linus Torvalds wrote: > An example of something that *isn't* right, is the i915 kvm interface, > which does > > use_mm(kvm->mm); > > on an mm that was initialized in virt/kvm/kvm_main.c using > > mmgrab(current->mm); > kvm->mm = current->mm; > > which is *not* right. Using "mmgrab()" does indeed guarantee the > lifetime of the 'struct mm_struct' itself, but it does *not* guarantee > the lifetime of the page tables. You need to use "mmget()" and > "mmput()", which get the reference to the actual process address > space! > > Now, it is *possible* that the kvm use is correct too, because kvm > does register a mmu_notifier chain, and in theory you can avoid the > proper refcounting by just making sure the mmu "release" notifier > kills any existing uses, but I don't really see kvm doing that. Kvm > does register a release notifier, but that just flushes the shadow > page tables, it doesn't kill any use_mm() use by some i915 use case. Yes, KVM is correct but the i915 bits are at least fishy. It's probably as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init and kvmgt_guest_exit, or maybe mmget_not_zero. Paolo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Possible use_mm() mis-uses
Adding Felix because the KFD part of amdgpu is actually his responsibility. If I'm not completely mistaken the release callback of the mmu_notifier should take care of that for amdgpu. Regards, Christian. Am 22.08.2018 um 18:44 schrieb Linus Torvalds: Guys and gals, this is a *very* random list of people on the recipients list, but we had a subtle TLB shootdown issue in the VM, and that brought up some issues when people then went through the code more carefully. I think we have a handle on the TLB shootdown bug itself. But when people were discussing all the possible situations, one thing that came up was "use_mm()" that takes a mm, and makes it temporarily the mm for a kernel thread (until "unuse_mm()", duh). And it turns out that some of those uses are definitely wrong, some of them are right, and some of them are suspect or at least so overly complicated that it's hard for the VM people to know if they are ok. Basically, the rule for "use_mm()" is that the mm in question *has* to have a valid page table associated with it over the whole use_mm() -> unuse_mm() sequence. That may sound obvious, and I guess it actually is so obvious that there isn't even a comment about it, but the actual users are showing that it's sadly apparently not so obvious after all. There is one user that uses the "obviously correct" model: the vhost driver does a "mmget()" and "mmput()" pair around its use of it, thanks to vhost_dev_set_owner() doing a dev->mm = get_task_mm(current); to look up the mm, and then the teardown case does a if (dev->mm) mmput(dev->mm); dev->mm = NULL; This is the *right* sequence. A gold star to the vhost people. Sadly, the vhost people are the only ones who seem to get things unquestionably right. And some of those gold star people are also apparently involved in the cases that didn't get things right. An example of something that *isn't* right, is the i915 kvm interface, which does use_mm(kvm->mm); on an mm that was initialized in virt/kvm/kvm_main.c using mmgrab(current->mm); kvm->mm = current->mm; which is *not* right. Using "mmgrab()" does indeed guarantee the lifetime of the 'struct mm_struct' itself, but it does *not* guarantee the lifetime of the page tables. You need to use "mmget()" and "mmput()", which get the reference to the actual process address space! Now, it is *possible* that the kvm use is correct too, because kvm does register a mmu_notifier chain, and in theory you can avoid the proper refcounting by just making sure the mmu "release" notifier kills any existing uses, but I don't really see kvm doing that. Kvm does register a release notifier, but that just flushes the shadow page tables, it doesn't kill any use_mm() use by some i915 use case. So while the vhost use looks right, the kvm/i915 use looks definitely wrong. The other users of "use_mm()" and "unuse_mm()" are less black-and-white right vs wrong.. One of the complex ones is the amdgpu driver. It does a "use_mm(mmptr)" deep deep in the guts of a macro that ends up being used in fa few places, and it's very hard to tell if it's right. It looks almost certainly buggy (there is no mmget/mmput to get the refcount), but there _is_ a "release" mmu_notifier function and that one - unlike the kvm case - looks like it might actually be trying to flush the existing pending users of that mm. But on the whole, I'm suspicious of the amdgpu use. It smells. Jann Horn pointed out that even if it migth be ok due to the mmu_notifier, the comments are garbage: Where "process" in the uniquely-named "struct queue" is a "struct kfd_process"; that struct's definition has this comment in it: /* * Opaque pointer to mm_struct. We don't hold a reference to * it so it should never be dereferenced from here. This is * only used for looking up processes by their mm. */ void *mm; So I think either that comment is wrong, or their code is wrong? so I'm chalking the amdgpu use up in the "broken" column. It's also actually quite hard to synchronze with some other kernel worker thread correctly, so just on general principles, if you use "use_mm()" it really really should be on something that you've properly gotten a mm refcount on with mmget(). Really. Even if you try to synchronize things. The two final cases are two uses in the USB gadget driver. Again, they don't have the proper mmget/mmput, but they may br ok simply because the uses are done for AIO, and the VM teardown is preceded by an AIO teardown, so the proper serialization may come in from that. Anyway, sorry for the long email, and the big list of participants and odd mailing lists, but I'd really like people to look at their "use_mm()" cases, and ask themselves if they have done enough to guarantee that the full mm exists. Again, "mmgrab()" is *not* enough on its own. You need either "mmget()" or some lifetime guarantee. And if
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Fix context slice count configuration
== Series Details == Series: drm/i915/icl: Fix context slice count configuration URL : https://patchwork.freedesktop.org/series/48570/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4696_full -> Patchwork_9992_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9992_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9992_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9992_full: === IGT changes === Warnings igt@kms_cursor_legacy@cursorb-vs-flipa-toggle: shard-hsw: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9992_full that come from known issues: === IGT changes === Issues hit igt@gem_ctx_isolation@vcs1-s3: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_flip@modeset-vs-vblank-race: shard-apl: PASS -> FAIL (fdo#103060) Possible fixes igt@drv_suspend@shrink: shard-glk: FAIL (fdo#106886) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS +1 igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#102887, fdo#105363) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS shard-glk: FAIL (fdo#99912) -> PASS igt@perf@polling: shard-hsw: FAIL (fdo#102252) -> PASS igt@pm_rpm@system-suspend: shard-kbl: INCOMPLETE (fdo#107556, fdo#103665) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4696 -> Patchwork_9992 CI_DRM_4696: ced152c46fc90f7c1ac8963850d64c9f1ce652d6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9992: 5cf33a6a09d933f2cc8def1e8f43aa1812615aab @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9992/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add a small wrapper to check for CCS modifiers.
On Wed, 2018-08-22 at 12:48 +0300, Ville Syrjälä wrote:
> On Tue, Aug 21, 2018 at 06:50:52PM -0700, Dhinakaran Pandiyan wrote:
> > Code looks cleaner with modifiers hidden inside this wrapper.
> >
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 21 +++--
> > drivers/gpu/drm/i915/intel_display.h | 1 +
> > drivers/gpu/drm/i915/intel_sprite.c | 3 +--
> > 3 files changed, 13 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index ad0f0e5389d9..b98eab113330 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2474,6 +2474,12 @@ intel_get_format_info(const struct
> > drm_mode_fb_cmd2 *cmd)
> > }
> > }
> >
> > +bool is_ccs_modifier(const u64 modifier)
>
> const is rather pointless here IMO.
I thought of it as harmless documentation, will remove and send a v2.
>
> > +{
> > + return modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> > + modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
> > +}
>
> IIRC I had a similar thing in my gtt remapping series, though I
> didn't
> plug it into all the places that could have used it.
>
> Reviewed-by: Ville Syrjälä
>
Thanks for the reviews. We have to get your plane refactor series
merged soon, I'm hoping I can make some time to start reviewing it this
week.
-DK
> > +
> > static int
> > intel_fill_fb_info(struct drm_i915_private *dev_priv,
> >struct drm_framebuffer *fb)
> > @@ -2504,8 +2510,7 @@ intel_fill_fb_info(struct drm_i915_private
> > *dev_priv,
> > return ret;
> > }
> >
> > - if ((fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS
> > ||
> > -fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS)
> > && i == 1) {
> > + if (is_ccs_modifier(fb->modifier) && i == 1) {
> > int hsub = fb->format->hsub;
> > int vsub = fb->format->vsub;
> > int tile_width, tile_height;
> > @@ -3054,8 +3059,7 @@ static int skl_check_main_surface(const
> > struct intel_crtc_state *crtc_state,
> > * CCS AUX surface doesn't have its own x/y offsets, we
> > must make sure
> > * they match with the main surface x/y offsets.
> > */
> > - if (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> > - fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) {
> > + if (is_ccs_modifier(fb->modifier)) {
> > while
> > (!skl_check_main_ccs_coordinates(plane_state, x, y, offset)) {
> > if (offset == 0)
> > break;
> > @@ -3189,8 +3193,7 @@ int skl_check_plane_surface(const struct
> > intel_crtc_state *crtc_state,
> > ret = skl_check_nv12_aux_surface(plane_state);
> > if (ret)
> > return ret;
> > - } else if (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> > - fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) {
> > + } else if (is_ccs_modifier(fb->modifier)) {
> > ret = skl_check_ccs_aux_surface(plane_state);
> > if (ret)
> > return ret;
> > @@ -13399,8 +13402,7 @@ static bool
> > skl_plane_format_mod_supported(struct drm_plane *_plane,
> > case DRM_FORMAT_XBGR:
> > case DRM_FORMAT_ARGB:
> > case DRM_FORMAT_ABGR:
> > - if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
> > - modifier == I915_FORMAT_MOD_Y_TILED_CCS)
> > + if (is_ccs_modifier(modifier))
> > return true;
> > /* fall through */
> > case DRM_FORMAT_RGB565:
> > @@ -14596,8 +14598,7 @@ static int intel_framebuffer_init(struct
> > intel_framebuffer *intel_fb,
> > * potential runtime errors at plane configuration
> > time.
> > */
> > if (IS_GEN9(dev_priv) && i == 0 && fb->width >
> > 3840 &&
> > - (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS
> > ||
> > -fb->modifier ==
> > I915_FORMAT_MOD_Yf_TILED_CCS))
> > + is_ccs_modifier(fb->modifier))
> > stride_alignment *= 4;
> >
> > if (fb->pitches[i] & (stride_alignment - 1)) {
> > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > b/drivers/gpu/drm/i915/intel_display.h
> > index a04c5a495a2b..dbd8b1acf9d6 100644
> > --- a/drivers/gpu/drm/i915/intel_display.h
> > +++ b/drivers/gpu/drm/i915/intel_display.h
> > @@ -381,4 +381,5 @@ void intel_link_compute_m_n(int bpp, int
> > nlanes,
> > struct intel_link_m_n *m_n,
> > bool reduce_m_n);
> >
> > +bool is_ccs_modifier(const u64 modifier);
> > #endif
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index f7026e887fa9..b49adcd93892 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1407,8
[Intel-gfx] [PATCH v4] drm/i915/psr: Add PSR mode/revision to debugfs
Log the PSR mode/revision (PSR1 or PSR2) in the debugfs file i915_edp_psr_status. Suggested-by: Dhinakaran Pandiyan Signed-off-by: Azhar Shaikh --- Changes in v4: - Fix the rebase error in v3 of adding typecast to bool - in i915_edp_psr_status(), which is not needed Changes in v3: - rebased Changes in v2: - Fix checkpatch warning. - Add Reviewed-by: from v1 drivers/gpu/drm/i915/i915_debugfs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 26b7e5276b15..544ec5cdfe9f 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2708,6 +2708,8 @@ static int i915_edp_psr_status(struct seq_file *m, void *data) intel_runtime_pm_get(dev_priv); mutex_lock(_priv->psr.lock); + seq_printf(m, "PSR mode: %s\n", + dev_priv->psr.psr2_enabled ? "PSR2" : "PSR1"); seq_printf(m, "Enabled: %s\n", yesno(dev_priv->psr.enabled)); seq_printf(m, "Busy frontbuffer bits: 0x%03x\n", dev_priv->psr.busy_frontbuffer_bits); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Fix context slice count configuration
On 22/08/2018 18:07, Tvrtko Ursulin wrote:
On 22/08/2018 17:33, Lionel Landwerlin wrote:
On 22/08/2018 17:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Bitfield width for configuring the active slice count has grown in
Gen11
so we need to program the GEN8_R_PWR_CLK_STATE accordingly.
Current code was always requesting eight times the number of slices
(due
writting to a bitfield starting three bits higher than it should).
These
requests were luckily a) capped by the hardware to the available
number of
slices, and b) we haven't yet exported the code to ask for reduced
slice
configurations.
Due both of the above there was no impact from this incorrect
programming
but we should still fix it.
Signed-off-by: Tvrtko Ursulin
Bspec: 12247
Reported-by: tony...@intel.com
Suggested-by: Lionel Landwerlin
Cc: Lionel Landwerlin
Cc: tony...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 12
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 59d06d0055bb..640f7b774a26 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -344,6 +344,8 @@ static inline bool
i915_mmio_reg_valid(i915_reg_t reg)
#define GEN8_RPCS_S_CNT_ENABLE (1 << 18)
#define GEN8_RPCS_S_CNT_SHIFT 15
#define GEN8_RPCS_S_CNT_MASK (0x7 << GEN8_RPCS_S_CNT_SHIFT)
+#define GEN11_RPCS_S_CNT_SHIFT 12
+#define GEN11_RPCS_S_CNT_MASK (0x3f <<
GEN11_RPCS_S_CNT_SHIFT)
#define GEN8_RPCS_SS_CNT_ENABLE (1 << 11)
#define GEN8_RPCS_SS_CNT_SHIFT 8
#define GEN8_RPCS_SS_CNT_MASK (0x7 <<
GEN8_RPCS_SS_CNT_SHIFT)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..43b8b0675ba0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2501,10 +2501,14 @@ make_rpcs(struct drm_i915_private *dev_priv)
* enablement.
*/
if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
- rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
- GEN8_RPCS_S_CNT_SHIFT;
- rpcs |= GEN8_RPCS_ENABLE;
+ rpcs = hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask);
+
+ if (INTEL_GEN(dev_priv) >= 11)
+ rpcs <<= GEN11_RPCS_S_CNT_SHIFT;
+ else
+ rpcs <<= GEN8_RPCS_S_CNT_SHIFT;
+
+ rpcs |= GEN8_RPCS_ENABLE | GEN8_RPCS_S_CNT_ENABLE;
I don't know if you saw that wording in the documentation :
"
Note: In ICL, software programs this register as if GT consists of 2
slices with 4 subslices in each slice. Hardware maps this to the 1
slice/8-subslice physical layout.
"
My understanding is that it would make this function a bit more
complicated ;)
It also implies that on ICL you cannot select 3 subslices, which is
unfortunately what Tony was trying to do.
Maybe some opens need to be raised as to what's possible on ICL.
I interpreted the note in my head as "In ICL, _if_ _the_ software
programs.." so did not see a problem. Thought that would be just some
hidden/under the covers remapping hw would do. But I see now that was
wrong, and you are most likely right. I'll try to do some digging to
understand this better.
But for the second part of it, I don't see why 1x3 configuration would
be illegal. If software must assume hw is 2x4, even if in reality it
is 1x8, then 1x3 would still be legal, no?
We still seem to put a subslice number in the register for ICL (values
being 0b001, 0b010, 0b011 & 0b100).
My understanding is that the hardware will just multiply that value by 2
to map to the 1x8 underlying topology.
So if that's the case, you can't really do odd numbers... ¯\_(ツ)_/¯
I thought the cause of the hang on ICL was that when Tony was asking
for 1x3, the code was actually programming a request for 8x3 - which
is illegal (as in slice count must be 1 to enable subslice pg) and so
would fail to actually turn of the unwanted subslices.
But then I also though on ICL we deal with masks and not counts when
programming the hardware. Since apparently it is counts both for
slices and subslices, I am mightily confused as to how media-driver
would even theoretically be able to turn off a _specific_ (sub)slice?!
The fact that the feature needed isn't implemented at by the thread
dispatcher is really strange to me too.
It sounds like we're forced to use a bigger hammer than what we really need.
As to how that maps to the right subslices is also unknown to me.
The only explanation I have is that subslices with no VME samplers get
turn off first in the list of subslices to turn off.
Cheers,
-
Lionel
Regards,
Tvrtko
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH] drm/i915/icl: Fix context slice count configuration
On 22/08/2018 17:33, Lionel Landwerlin wrote:
On 22/08/2018 17:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Bitfield width for configuring the active slice count has grown in Gen11
so we need to program the GEN8_R_PWR_CLK_STATE accordingly.
Current code was always requesting eight times the number of slices (due
writting to a bitfield starting three bits higher than it should). These
requests were luckily a) capped by the hardware to the available
number of
slices, and b) we haven't yet exported the code to ask for reduced slice
configurations.
Due both of the above there was no impact from this incorrect programming
but we should still fix it.
Signed-off-by: Tvrtko Ursulin
Bspec: 12247
Reported-by: tony...@intel.com
Suggested-by: Lionel Landwerlin
Cc: Lionel Landwerlin
Cc: tony...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 12
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 59d06d0055bb..640f7b774a26 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -344,6 +344,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t
reg)
#define GEN8_RPCS_S_CNT_ENABLE (1 << 18)
#define GEN8_RPCS_S_CNT_SHIFT 15
#define GEN8_RPCS_S_CNT_MASK (0x7 << GEN8_RPCS_S_CNT_SHIFT)
+#define GEN11_RPCS_S_CNT_SHIFT 12
+#define GEN11_RPCS_S_CNT_MASK (0x3f << GEN11_RPCS_S_CNT_SHIFT)
#define GEN8_RPCS_SS_CNT_ENABLE (1 << 11)
#define GEN8_RPCS_SS_CNT_SHIFT 8
#define GEN8_RPCS_SS_CNT_MASK (0x7 << GEN8_RPCS_SS_CNT_SHIFT)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..43b8b0675ba0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2501,10 +2501,14 @@ make_rpcs(struct drm_i915_private *dev_priv)
* enablement.
*/
if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
- rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
- GEN8_RPCS_S_CNT_SHIFT;
- rpcs |= GEN8_RPCS_ENABLE;
+ rpcs = hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask);
+
+ if (INTEL_GEN(dev_priv) >= 11)
+ rpcs <<= GEN11_RPCS_S_CNT_SHIFT;
+ else
+ rpcs <<= GEN8_RPCS_S_CNT_SHIFT;
+
+ rpcs |= GEN8_RPCS_ENABLE | GEN8_RPCS_S_CNT_ENABLE;
I don't know if you saw that wording in the documentation :
"
Note: In ICL, software programs this register as if GT consists of 2
slices with 4 subslices in each slice. Hardware maps this to the 1
slice/8-subslice physical layout.
"
My understanding is that it would make this function a bit more
complicated ;)
It also implies that on ICL you cannot select 3 subslices, which is
unfortunately what Tony was trying to do.
Maybe some opens need to be raised as to what's possible on ICL.
I interpreted the note in my head as "In ICL, _if_ _the_ software
programs.." so did not see a problem. Thought that would be just some
hidden/under the covers remapping hw would do. But I see now that was
wrong, and you are most likely right. I'll try to do some digging to
understand this better.
But for the second part of it, I don't see why 1x3 configuration would
be illegal. If software must assume hw is 2x4, even if in reality it is
1x8, then 1x3 would still be legal, no?
I thought the cause of the hang on ICL was that when Tony was asking for
1x3, the code was actually programming a request for 8x3 - which is
illegal (as in slice count must be 1 to enable subslice pg) and so would
fail to actually turn of the unwanted subslices.
But then I also though on ICL we deal with masks and not counts when
programming the hardware. Since apparently it is counts both for slices
and subslices, I am mightily confused as to how media-driver would even
theoretically be able to turn off a _specific_ (sub)slice?!
Regards,
Tvrtko
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab
On Wed, Aug 22, 2018 at 05:37:22PM +0100, Daniel Stone wrote: > Hi Rodrigo, > > On Wed, 22 Aug 2018 at 17:06, Rodrigo Vivi wrote: > > On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote: > > > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote: > > > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > > > > drm-intel for the time being. Doing that migration in the same go is a > > > > bit much I think. Reassignment across bugzilla and gitlab will be an > > > > issue. > > > > > > Can you elaborate a bit on the issues here? The actual move-the-bugs > > > process has been pretty painless for the parts of xorg we've done so > > > far. > > > > I guess there is nothing against moving the bugs there. The concern is only > > on > > doing everything at once. > > > > I'm in favor of moving gits for now and after we are confident that > > everything is there and working we move the bugs. > > As Daniel alluded to, the only issue I really have is moving _all_ the > kernel repos at once. At the end of the year we'll have easy automatic > scaling thanks to the independent services being separated. As it is, > all the GitLab services (apart from CI runners) run on a single > machine, so we have limited options if it becomes overwhelmed with > load. > > Do you have a particular concern about the repos? no concerns from my side about the repos itself. From my committer perspective on libdrm, mesa the migration was really smooth. > e.g. what would you > check for to make sure things are 'there and working'? more in terms of other committers getting used to it, dim working for most of committers, links in documentations and wikis updated... but no concerns with the infra itself. > > > One question about the bugzilla: > > > > Will all the referrences on all commit messages get outdated after > > bugzilla is dead? > > Or bugzilla will stay up for referrence but closed for interaction? > > or all old closed stuff are always moved and bugzilla.fd.o as well and > > bugzilla.fd.o will be mirroring gitlab? > > When bugs are migrated from Bugzilla to GitLab, only open bugs are > migrated. Closed ones are left in place, as is; open ones have a > comment at the end saying that the bug has moved to GitLab, a URL > linking to the new GitLab issue, and telling them to please chase it > up there. > > Even when we move everyone completely off Bugzilla, we will keep it as > a read-only mirror forever. Even with Phabricator, which very few > people ever used, has had all its bugs and code review captured and > archived, so we can continue to preserve all the old content and > links, without having to run the actual service. Great! Thanks for all clarification, Rodrigo. > > Cheers, > Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Fix context slice count configuration
== Series Details ==
Series: drm/i915/icl: Fix context slice count configuration
URL : https://patchwork.freedesktop.org/series/48570/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4696 -> Patchwork_9992 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48570/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9992 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
{fi-byt-clapper}: PASS -> FAIL (fdo#107362, fdo#103191)
Possible fixes
igt@drv_selftest@live_hangcheck:
{fi-skl-iommu}: DMESG-FAIL (fdo#106560, fdo#107174) -> PASS
fi-kbl-7567u: DMESG-FAIL (fdo#106560, fdo#106947) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
{fi-byt-clapper}: FAIL (fdo#107362, fdo#103191) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
{fi-cfl-8109u}: INCOMPLETE (fdo#106070) -> PASS
Warnings
{igt@pm_rpm@module-reload}:
fi-cnl-psr: FAIL -> WARN (fdo#107602)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#106070 https://bugs.freedesktop.org/show_bug.cgi?id=106070
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
== Participating hosts (54 -> 46) ==
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-glk-j4005 fi-gdg-551
== Build changes ==
* Linux: CI_DRM_4696 -> Patchwork_9992
CI_DRM_4696: ced152c46fc90f7c1ac8963850d64c9f1ce652d6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9992: 5cf33a6a09d933f2cc8def1e8f43aa1812615aab @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5cf33a6a09d9 drm/i915/icl: Fix context slice count configuration
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9992/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V2 4/4] drm/crc: add pre_crc_read function
On Wed, Aug 22, 2018 at 12:37:05PM +0200, Maarten Lankhorst wrote:
> Op 21-08-18 om 10:38 schreef Mahesh Kumar:
> > This patch implements a callback function which will be called before
> > crc read. In this function driver can implement any preparation work
> > required for successfully reading CRC data.
> >
> > Changes Since V1:
> > - rebase
> >
> > Cc: dri-de...@lists.freedesktop.org
> > Signed-off-by: Mahesh Kumar
> After some discussion with David on whether this can be upstreamed, he NACK'd
> it.
> Because there are no upstream users for this callback, it cannot be included
> upstream.
> It would be removed by the first person to notice there are no in-kernel
> users using it.
It makes sense After I posted the review yesterday I started thinking
exactly
about this case... if would get easily removed in a clean-up for obvious
reasons...
> For the first 3 patches:
> Reviewed-by: Maarten Lankhorst
thanks. pushed all 3 to drm-misc-next.
> > drivers/gpu/drm/drm_debugfs_crc.c | 8
> > include/drm/drm_crtc.h| 14 ++
> > 2 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> > b/drivers/gpu/drm/drm_debugfs_crc.c
> > index 00e743153e94..e303c194c080 100644
> > --- a/drivers/gpu/drm/drm_debugfs_crc.c
> > +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> > @@ -274,6 +274,14 @@ static ssize_t crtc_crc_read(struct file *filep, char
> > __user *user_buf,
> > return 0;
> > }
> >
> > + if (crtc->funcs->pre_crc_read) {
> > + ret = crtc->funcs->pre_crc_read(crtc);
> > + if (ret) {
> > + spin_unlock_irq(>lock);
> > + return ret;
> > + }
> > + }
> > +
> > /* Nothing to read? */
> > while (crtc_crc_data_count(crc) == 0) {
> > if (filep->f_flags & O_NONBLOCK) {
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index b21437bc95bf..19c2bf63935e 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -761,6 +761,20 @@ struct drm_crtc_funcs {
> > */
> > int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
> > size_t *values_cnt);
> > + /**
> > +* @pre_crc_read:
> > +*
> > +* Driver callback for performing any preparation work required by
> > +* driver before reading CRC
> > +*
> > +* This callback is optional if the driver does not support CRC
> > +* generation or no prework is required before reading the crc
> > +*
> > +* RETURNS:
> > +*
> > +* 0 on success or a negative error code on failure.
> > +*/
> > + int (*pre_crc_read)(struct drm_crtc *crtc);
> > /**
> > * @get_crc_sources:
> > *
>
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Possible use_mm() mis-uses
Guys and gals, this is a *very* random list of people on the recipients list, but we had a subtle TLB shootdown issue in the VM, and that brought up some issues when people then went through the code more carefully. I think we have a handle on the TLB shootdown bug itself. But when people were discussing all the possible situations, one thing that came up was "use_mm()" that takes a mm, and makes it temporarily the mm for a kernel thread (until "unuse_mm()", duh). And it turns out that some of those uses are definitely wrong, some of them are right, and some of them are suspect or at least so overly complicated that it's hard for the VM people to know if they are ok. Basically, the rule for "use_mm()" is that the mm in question *has* to have a valid page table associated with it over the whole use_mm() -> unuse_mm() sequence. That may sound obvious, and I guess it actually is so obvious that there isn't even a comment about it, but the actual users are showing that it's sadly apparently not so obvious after all. There is one user that uses the "obviously correct" model: the vhost driver does a "mmget()" and "mmput()" pair around its use of it, thanks to vhost_dev_set_owner() doing a dev->mm = get_task_mm(current); to look up the mm, and then the teardown case does a if (dev->mm) mmput(dev->mm); dev->mm = NULL; This is the *right* sequence. A gold star to the vhost people. Sadly, the vhost people are the only ones who seem to get things unquestionably right. And some of those gold star people are also apparently involved in the cases that didn't get things right. An example of something that *isn't* right, is the i915 kvm interface, which does use_mm(kvm->mm); on an mm that was initialized in virt/kvm/kvm_main.c using mmgrab(current->mm); kvm->mm = current->mm; which is *not* right. Using "mmgrab()" does indeed guarantee the lifetime of the 'struct mm_struct' itself, but it does *not* guarantee the lifetime of the page tables. You need to use "mmget()" and "mmput()", which get the reference to the actual process address space! Now, it is *possible* that the kvm use is correct too, because kvm does register a mmu_notifier chain, and in theory you can avoid the proper refcounting by just making sure the mmu "release" notifier kills any existing uses, but I don't really see kvm doing that. Kvm does register a release notifier, but that just flushes the shadow page tables, it doesn't kill any use_mm() use by some i915 use case. So while the vhost use looks right, the kvm/i915 use looks definitely wrong. The other users of "use_mm()" and "unuse_mm()" are less black-and-white right vs wrong.. One of the complex ones is the amdgpu driver. It does a "use_mm(mmptr)" deep deep in the guts of a macro that ends up being used in fa few places, and it's very hard to tell if it's right. It looks almost certainly buggy (there is no mmget/mmput to get the refcount), but there _is_ a "release" mmu_notifier function and that one - unlike the kvm case - looks like it might actually be trying to flush the existing pending users of that mm. But on the whole, I'm suspicious of the amdgpu use. It smells. Jann Horn pointed out that even if it migth be ok due to the mmu_notifier, the comments are garbage: > Where "process" in the uniquely-named "struct queue" is a "struct > kfd_process"; that struct's definition has this comment in it: > >/* > * Opaque pointer to mm_struct. We don't hold a reference to > * it so it should never be dereferenced from here. This is > * only used for looking up processes by their mm. > */ >void *mm; > > So I think either that comment is wrong, or their code is wrong? so I'm chalking the amdgpu use up in the "broken" column. It's also actually quite hard to synchronze with some other kernel worker thread correctly, so just on general principles, if you use "use_mm()" it really really should be on something that you've properly gotten a mm refcount on with mmget(). Really. Even if you try to synchronize things. The two final cases are two uses in the USB gadget driver. Again, they don't have the proper mmget/mmput, but they may br ok simply because the uses are done for AIO, and the VM teardown is preceded by an AIO teardown, so the proper serialization may come in from that. Anyway, sorry for the long email, and the big list of participants and odd mailing lists, but I'd really like people to look at their "use_mm()" cases, and ask themselves if they have done enough to guarantee that the full mm exists. Again, "mmgrab()" is *not* enough on its own. You need either "mmget()" or some lifetime guarantee. And if you do have those lifetime guarantees, it would be really nice to get a good explanatory comment about said lifetime guarantees above the "use_mm()" call. Ok? Note that the lifetime rules are very important, because obviously use_mm() itself is never called
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/icl: Fix context slice count configuration
== Series Details == Series: drm/i915/icl: Fix context slice count configuration URL : https://patchwork.freedesktop.org/series/48570/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5cf33a6a09d9 drm/i915/icl: Fix context slice count configuration -:10: WARNING:TYPO_SPELLING: 'writting' may be misspelled - perhaps 'writing'? #10: writting to a bitfield starting three bits higher than it should). These total: 0 errors, 1 warnings, 0 checks, 26 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab
Hi Rodrigo, On Wed, 22 Aug 2018 at 17:06, Rodrigo Vivi wrote: > On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote: > > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote: > > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > > > drm-intel for the time being. Doing that migration in the same go is a > > > bit much I think. Reassignment across bugzilla and gitlab will be an > > > issue. > > > > Can you elaborate a bit on the issues here? The actual move-the-bugs > > process has been pretty painless for the parts of xorg we've done so > > far. > > I guess there is nothing against moving the bugs there. The concern is only on > doing everything at once. > > I'm in favor of moving gits for now and after we are confident that > everything is there and working we move the bugs. As Daniel alluded to, the only issue I really have is moving _all_ the kernel repos at once. At the end of the year we'll have easy automatic scaling thanks to the independent services being separated. As it is, all the GitLab services (apart from CI runners) run on a single machine, so we have limited options if it becomes overwhelmed with load. Do you have a particular concern about the repos? e.g. what would you check for to make sure things are 'there and working'? > One question about the bugzilla: > > Will all the referrences on all commit messages get outdated after > bugzilla is dead? > Or bugzilla will stay up for referrence but closed for interaction? > or all old closed stuff are always moved and bugzilla.fd.o as well and > bugzilla.fd.o will be mirroring gitlab? When bugs are migrated from Bugzilla to GitLab, only open bugs are migrated. Closed ones are left in place, as is; open ones have a comment at the end saying that the bug has moved to GitLab, a URL linking to the new GitLab issue, and telling them to please chase it up there. Even when we move everyone completely off Bugzilla, we will keep it as a read-only mirror forever. Even with Phabricator, which very few people ever used, has had all its bugs and code review captured and archived, so we can continue to preserve all the old content and links, without having to run the actual service. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab
Hi, On Wed, 22 Aug 2018 at 15:44, Daniel Vetter wrote: > On Wed, Aug 22, 2018 at 3:13 PM, Jani Nikula > wrote: > > Just a couple of concerns from drm/i915 perspective for starters: > > > > - Patchwork integration. I think we'll want to keep patchwork for at > > least intel-gfx etc. for the time being. IIUC the one thing we need is > > some server side hook to update patchwork on git push. > > > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > > drm-intel for the time being. Doing that migration in the same go is a > > bit much I think. Reassignment across bugzilla and gitlab will be an > > issue. > > Good points, forgot about both. Patchwork reading the mailing list > should keep working as-is, but the update hook needs looking into. All the hooks are retained. gitlab.fd.o pushes to git.fd.o, and git.fd.o still executes all the old hooks. This includes Patchwork, readthedocs, AppVeyor, and whatever else. > For merge requests I think best approach is to enable them very > selectively at first for testing out, and then making a per-subproject > decision whether they make sense. E.g. I think for maintainer-tools > integrating make check and the doc building into gitlab CI would be > sweet, and worth looking into gitlab merge requests just to automate > that. Again best left out of scope for the initial migration. You don't need MRs to do that. You can build a .gitlab-ci.yml file which will run make check or build the docs or whatever, and have that run on pushes. Anyone can then fork the repo, push their changes to that fork, and see the CI results from there. It's like Travis: the CI configuration is a (mutable) part of the codebase, not a separate 'thing' hanging off a specific repo. So if you write the CI pipeline first, you can have people running CI on push completely independently of switching the workflow to use MRs. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Fix context slice count configuration
On 22/08/2018 17:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Bitfield width for configuring the active slice count has grown in Gen11
so we need to program the GEN8_R_PWR_CLK_STATE accordingly.
Current code was always requesting eight times the number of slices (due
writting to a bitfield starting three bits higher than it should). These
requests were luckily a) capped by the hardware to the available number of
slices, and b) we haven't yet exported the code to ask for reduced slice
configurations.
Due both of the above there was no impact from this incorrect programming
but we should still fix it.
Signed-off-by: Tvrtko Ursulin
Bspec: 12247
Reported-by: tony...@intel.com
Suggested-by: Lionel Landwerlin
Cc: Lionel Landwerlin
Cc: tony...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 12
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 59d06d0055bb..640f7b774a26 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -344,6 +344,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define GEN8_RPCS_S_CNT_ENABLE (1 << 18)
#define GEN8_RPCS_S_CNT_SHIFT 15
#define GEN8_RPCS_S_CNT_MASK(0x7 << GEN8_RPCS_S_CNT_SHIFT)
+#define GEN11_RPCS_S_CNT_SHIFT 12
+#define GEN11_RPCS_S_CNT_MASK(0x3f << GEN11_RPCS_S_CNT_SHIFT)
#define GEN8_RPCS_SS_CNT_ENABLE (1 << 11)
#define GEN8_RPCS_SS_CNT_SHIFT 8
#define GEN8_RPCS_SS_CNT_MASK (0x7 << GEN8_RPCS_SS_CNT_SHIFT)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..43b8b0675ba0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2501,10 +2501,14 @@ make_rpcs(struct drm_i915_private *dev_priv)
* enablement.
*/
if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
- rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
- GEN8_RPCS_S_CNT_SHIFT;
- rpcs |= GEN8_RPCS_ENABLE;
+ rpcs = hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask);
+
+ if (INTEL_GEN(dev_priv) >= 11)
+ rpcs <<= GEN11_RPCS_S_CNT_SHIFT;
+ else
+ rpcs <<= GEN8_RPCS_S_CNT_SHIFT;
+
+ rpcs |= GEN8_RPCS_ENABLE | GEN8_RPCS_S_CNT_ENABLE;
I don't know if you saw that wording in the documentation :
"
Note: In ICL, software programs this register as if GT consists of 2
slices with 4 subslices in each slice. Hardware maps this to the 1
slice/8-subslice physical layout.
"
My understanding is that it would make this function a bit more
complicated ;)
It also implies that on ICL you cannot select 3 subslices, which is
unfortunately what Tony was trying to do.
Maybe some opens need to be raised as to what's possible on ICL.
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] RFC: Migration to Gitlab
Hi, On Wed, 22 Aug 2018 at 16:02, Emil Velikov wrote: > On 22 August 2018 at 12:44, Daniel Vetter wrote: > > I think it's time to brainstorm a bit about the gitlab migration. Basic > > reasons: > > > > - fd.o admins want to deprecate shell accounts and hand-rolled > > infrastructure, because it's a pain to keep secure > > > > - gitlab will allow us to add committers on our own, greatly > > simplifying that process (and offloading that task from fd.o admins). > > Random thought - I really wish the admins spoke early and louder about issues. > From infra to manpower and adhoc tool maintenance. I thought I mostly had it covered, but fair enough. What knowledge are you missing and how should it best be delivered? One first-order issue is that as documented at https://www.freedesktop.org/wiki/AccountRequests/ creating accounts requires manual admin intervention. You can also search the 'freedesktop.org' product on Bugzilla to see the amount of time we spend shuffling around GPG & SSH keys, which is about the worst possible use of my time. Many other people have had access to drive the ancient shell-script frontend to LDAP before, but for some reason they mostly aren't very enthusiastic about doing it all the time. In the mesa-dev@ thread about Mesa's migration, which is linked from my blog post, I went into quite a lot of detail about why Jenkins was not suitable to roll out across fd.o globally. That knowledge was gained from trial & error, which was a lot of time burnt. The end result is that we don't have any CI, except if people hang Travis/AppVeyor off GitHub mirrors. You've personally seen what's involved in setting up Git repository hooks so we can build docs. We can't give access to let people work on those, without giving them direct access to the literal Git repository itself on disk. The hooks mostly involve bespoke sets of rsync jobs and hand-managed SSH credentials and external services to build docs and so on and so forth. None of this is accessible to a newcomer who wants to make a non-code contribution: you have to find someone with access to the repo to go bash some shell scripts directly and hope you didn't screw it up. None of this is auditable, so if the repo mysteriously gets wiped, then hopefully there are some backups somewhere. But there definitely aren't any logs. Luckily we prevent most people from having access to most repositories via a mandatory 'shell' which only allows people to push Git; this was written by hand by us 12 years ago. What else? Our fork of Patchwork was until recently based on an ancient fork of Django, in a bespoke unreproducible production environment. Bugzilla is patched for spam and templates (making upgrades complex), yet we still have a surprising amount of spam pass through. There's no way to delete spam, but you have to manually move every bug to the 'spam' group, then go through and delete the user which involves copying & pasting the email and a few clicks per user. Mailman is patched to support Recaptcha, bringing more upgrade fun. ikiwiki breaks all the time because it's designed to have the public-access web server on the same host as the writeable Git repositories. Our servers are several years old and approaching life expiry, and we have no more spare disk. You can see in #freedesktop IRC the constant network connectivity issues people have to PSU almost every day. Our attempts to root-cause and solve those have got nowhere. I could go on, but the 'moved elsewhere' list in https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/2 indicates that we do have problems to solve, and that changing peoples' SSH keys for them isn't the best way for us to be spending the extremely limited time that we do have. > > For the full in-depth writeup of everything, see > > > > https://www.fooishbar.org/blog/gitlab-fdo-introduction/ If you haven't seen this, or the post it was linked from, they would be a good start: https://lists.freedesktop.org/archives/freedesktop/2018-July/000370.html There's also the long thread on mesa-dev a long time back which covers a lot of this ground already. > > - Figuring out the actual migration - we've been adding a pile of > > committers since fd.o LDAP was converted to gitlab once back in > > spring. We need to at least figure out how to move the new > > accounts/committers. > > As a observer, allow me to put some ideas. You've mostly covered them > all, my emphasis is to seriously stick with _one_ thing at a time. > Attempting to do multiple things in parallel will end up with > sub-optimal results. > > - (at random point) cleanup the committers list - people who have not > contributed in the last 1 year? libdrm was previously covered under the Mesa ACL. Here are the other committer lists, which you can see via 'getent group' on annarchy or another machine: amdkfd:x:922:fxkuehl,agd5f,deathsimple,danvet,jazhou,jbridgman,hwentland,tstdenis,gitlab-mirror,rui drm-meson:x:936:narmstrong drm:x:940:airlied,danvet
[Intel-gfx] [PATCH] drm/i915/icl: Fix context slice count configuration
From: Tvrtko Ursulin
Bitfield width for configuring the active slice count has grown in Gen11
so we need to program the GEN8_R_PWR_CLK_STATE accordingly.
Current code was always requesting eight times the number of slices (due
writting to a bitfield starting three bits higher than it should). These
requests were luckily a) capped by the hardware to the available number of
slices, and b) we haven't yet exported the code to ask for reduced slice
configurations.
Due both of the above there was no impact from this incorrect programming
but we should still fix it.
Signed-off-by: Tvrtko Ursulin
Bspec: 12247
Reported-by: tony...@intel.com
Suggested-by: Lionel Landwerlin
Cc: Lionel Landwerlin
Cc: tony...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 12
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 59d06d0055bb..640f7b774a26 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -344,6 +344,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define GEN8_RPCS_S_CNT_ENABLE (1 << 18)
#define GEN8_RPCS_S_CNT_SHIFT15
#define GEN8_RPCS_S_CNT_MASK (0x7 << GEN8_RPCS_S_CNT_SHIFT)
+#define GEN11_RPCS_S_CNT_SHIFT 12
+#define GEN11_RPCS_S_CNT_MASK(0x3f << GEN11_RPCS_S_CNT_SHIFT)
#define GEN8_RPCS_SS_CNT_ENABLE (1 << 11)
#define GEN8_RPCS_SS_CNT_SHIFT 8
#define GEN8_RPCS_SS_CNT_MASK(0x7 << GEN8_RPCS_SS_CNT_SHIFT)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..43b8b0675ba0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2501,10 +2501,14 @@ make_rpcs(struct drm_i915_private *dev_priv)
* enablement.
*/
if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
- rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
- GEN8_RPCS_S_CNT_SHIFT;
- rpcs |= GEN8_RPCS_ENABLE;
+ rpcs = hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask);
+
+ if (INTEL_GEN(dev_priv) >= 11)
+ rpcs <<= GEN11_RPCS_S_CNT_SHIFT;
+ else
+ rpcs <<= GEN8_RPCS_S_CNT_SHIFT;
+
+ rpcs |= GEN8_RPCS_ENABLE | GEN8_RPCS_S_CNT_ENABLE;
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix subslice configuration on Gen9LP
== Series Details == Series: drm/i915: Fix subslice configuration on Gen9LP URL : https://patchwork.freedesktop.org/series/48566/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4696_full -> Patchwork_9991_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9991_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9991_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9991_full: === IGT changes === Warnings igt@kms_cursor_legacy@cursorb-vs-flipa-toggle: shard-hsw: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9991_full that come from known issues: === IGT changes === Issues hit igt@gem_ctx_isolation@vcs1-s3: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@gem_exec_await@wide-contexts: shard-glk: PASS -> FAIL (fdo#105900) shard-kbl: PASS -> FAIL (fdo#105900) igt@kms_available_modes_crc@available_mode_test_crc: shard-kbl: NOTRUN -> FAIL (fdo#106641) Possible fixes igt@drv_suspend@shrink: shard-glk: FAIL (fdo#106886) -> PASS igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: INCOMPLETE (fdo#106023, fdo#103665) -> PASS +1 igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS +1 igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#102887, fdo#105363) -> PASS igt@perf@polling: shard-hsw: FAIL (fdo#102252) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106641 https://bugs.freedesktop.org/show_bug.cgi?id=106641 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4696 -> Patchwork_9991 CI_DRM_4696: ced152c46fc90f7c1ac8963850d64c9f1ce652d6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9991: 75e3f1910f813b2dff2ae2794d9e84e9f832188c @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9991/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/syncobj: Drop add/remove_callback from driver interface
Fine with me.
Reviewed-by: Jason Ekstrand
On Wed, Aug 22, 2018 at 4:29 AM Daniel Vetter
wrote:
> This is used for handling future fences. Currently no driver use
> these, and I think given the new timeline fence proposed by KHR it
> would be better to have a more abstract interface for future fences.
> Could be something simple like a struct dma_future_fence plus a
> function to add a callback or wait for the fence to materialize.
>
> Then syncobj (and anything else really) could grow new functions to
> expose these two drivers. Normal dma_fence would then keep the nice
> guarantee that they will always signal (and through ordering, be
> deadlock free). dma_future_fence would then be the tricky one.
>
> This also fixes sphinx complaining about the kerneldoc.
>
> Cc: Jason Ekstrand
> Cc: Dave Airlie
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_syncobj.c | 15 ---
> include/drm/drm_syncobj.h | 5 -
> 2 files changed, 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index adb3cb27d31e..3a8837c49639 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -120,14 +120,6 @@ static int
> drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
> return ret;
> }
>
> -/**
> - * drm_syncobj_add_callback - adds a callback to syncobj::cb_list
> - * @syncobj: Sync object to which to add the callback
> - * @cb: Callback to add
> - * @func: Func to use when initializing the drm_syncobj_cb struct
> - *
> - * This adds a callback to be called next time the fence is replaced
> - */
> void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
> struct drm_syncobj_cb *cb,
> drm_syncobj_func_t func)
> @@ -136,13 +128,7 @@ void drm_syncobj_add_callback(struct drm_syncobj
> *syncobj,
> drm_syncobj_add_callback_locked(syncobj, cb, func);
> spin_unlock(>lock);
> }
> -EXPORT_SYMBOL(drm_syncobj_add_callback);
>
> -/**
> - * drm_syncobj_add_callback - removes a callback to syncobj::cb_list
> - * @syncobj: Sync object from which to remove the callback
> - * @cb: Callback to remove
> - */
> void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
> struct drm_syncobj_cb *cb)
> {
> @@ -150,7 +136,6 @@ void drm_syncobj_remove_callback(struct drm_syncobj
> *syncobj,
> list_del_init(>node);
> spin_unlock(>lock);
> }
> -EXPORT_SYMBOL(drm_syncobj_remove_callback);
>
> /**
> * drm_syncobj_replace_fence - replace fence in a sync object.
> diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
> index 3980602472c0..e419c79ba94d 100644
> --- a/include/drm/drm_syncobj.h
> +++ b/include/drm/drm_syncobj.h
> @@ -131,11 +131,6 @@ drm_syncobj_fence_get(struct drm_syncobj *syncobj)
>
> struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
> u32 handle);
> -void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
> - struct drm_syncobj_cb *cb,
> - drm_syncobj_func_t func);
> -void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
> -struct drm_syncobj_cb *cb);
> void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
>struct dma_fence *fence);
> int drm_syncobj_find_fence(struct drm_file *file_private,
> --
> 2.18.0
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab
On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote: > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote: > > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > > drm-intel for the time being. Doing that migration in the same go is a > > bit much I think. Reassignment across bugzilla and gitlab will be an > > issue. > > Can you elaborate a bit on the issues here? The actual move-the-bugs > process has been pretty painless for the parts of xorg we've done so > far. I guess there is nothing against moving the bugs there. The concern is only on doing everything at once. I'm in favor of moving gits for now and after we are confident that everything is there and working we move the bugs. One question about the bugzilla: Will all the referrences on all commit messages get outdated after bugzilla is dead? Or bugzilla will stay up for referrence but closed for interaction? or all old closed stuff are always moved and bugzilla.fd.o as well and bugzilla.fd.o will be mirroring gitlab? Thanks, Rodrigo. > > - ajax > ___ > dim-tools mailing list > dim-to...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dim-tools ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix subslice configuration on Gen9LP
On 22/08/2018 16:27, Tvrtko Ursulin wrote:
On 22/08/2018 16:22, Lionel Landwerlin wrote:
On 22/08/2018 16:17, Tvrtko Ursulin wrote:
On 22/08/2018 16:08, Lionel Landwerlin wrote:
On 22/08/2018 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice
count power-
gating configuration register, the value to be written into it on
Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3 slices = 0x100
s/slice/subslice/
Also 0b001 etc... Not hexadecimal.
Oops, you're right.
And not the popcount of the enabled subslice mask as on other
platforms.
So on Gen9LP platforms we have been programming 0x11 into those
bits, but
the documentation does not explain what would that achieve. Could
it be
that we enable only two subslice on three sub-slice parts? Or
hardware
simply ignores it and sticks with the maximum configuration?
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Bspec: 12247
---
Could this actually be true or I am severely misreading the docs?
It does
not sound plausible to me this would have been missed all this time..
How to test in what configuration do these parts run before and
after this
patch?
---
drivers/gpu/drm/i915/intel_lrc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..cdfa962a1975 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2508,9 +2508,15 @@ make_rpcs(struct drm_i915_private *dev_priv)
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+ u8 val;
+
+ val = hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
+
+ if (IS_GEN9_LP(dev_priv))
+ val = BIT(val - 1);
Hmm... Are you breaking the 2 subslices setting here then?
(2 subslices = 0b10 which should be equal to
hweight8(subslice_mask) if I'm thinking right)
No and yes, I think.
subslice_mask = 0b011 => hweight = 2 => BIT(2 - 1) = BIT(1) = 0b010
into the register
In the same way, all together:
subslice_mask = 0b001 => hweight = 1 => BIT(0) = 0b001
subslice_mask = 0b011 => hweight = 2 => BIT(1) = 0b010
subslice_mask = 0b111 => hweight = 3 => BIT(2) = 0b100
Have I made a mistake somewhere?
Ah, yes! You're right :)
My eyes got tricked, thanks for finding this out.
At least half of the credit goes to you for linking to 12247 in scope
of one different thread!
With the comment fixed :
Reviewed-by: Lionel Landwerlin
Thanks!
Any ideas on how to test this? I'd like to commit message to be more
precise - have we been running with one slice too few? Or hardware
ignores the undocumented bit combination? Or even, is the
documentation perhaps incorrect?!
Yeah the tests that I wrote to test the API you're picking up use a
MI_PREDICATE where you can make a command (let's say
MI_STORE_REGISTER_MEM) conditional on the number of slice.
You can use that in a user batch an verify that memory has or hasn't
been written to.
That's only before Gen10 though.
I'm looking at whether something that is passed onto the EUs could map
back to the physical location.
Not sure if there is something...
-
Lionel
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915/kbl+: Enable IPC only for symmetric memory configurations
On Wed, Aug 22, 2018 at 06:32:33PM +0530, Kumar, Mahesh wrote:
> Hi,
>
>
> On 8/22/2018 12:26 AM, Rodrigo Vivi wrote:
> > On Tue, Aug 21, 2018 at 09:30:21PM +0530, Kumar, Mahesh wrote:
> > > Hi,
> > >
> > >
> > > On 8/21/2018 8:27 PM, Kumar, Mahesh wrote:
> > > > Hi,
> > > >
> > > >
> > > > On 8/17/2018 11:50 PM, Rodrigo Vivi wrote:
> > > > > On Thu, Jul 26, 2018 at 07:44:09PM +0530, Mahesh Kumar wrote:
> > > > > > IPC may cause underflows if not used with dual channel symmetric
> > > > > > memory configuration. Disable IPC for non symmetric configurations
> > > > > > in
> > > > > > affected platforms.
> > > > > > Display WA #1141
> > > > > >
> > > > > > Signed-off-by: Mahesh Kumar
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/i915_drv.c | 43
> > > > > > -
> > > > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > > > drivers/gpu/drm/i915/intel_pm.c | 2 +-
> > > > > > 3 files changed, 40 insertions(+), 6 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > > > index 86bc2e685522..2273664166bc 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > > > @@ -1141,21 +1141,47 @@ skl_dram_get_channel_info(struct
> > > > > > dram_channel_info *ch, u32 val)
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > +static bool
> > > > > > +intel_is_dram_ipc_capable(struct drm_i915_private *dev_priv,
> > > > > > + u32 val_ch0, u32 val_ch1,
> > > > > > + struct dram_channel_info *ch0)
> > > > > what about
> > > > > intel_is_dram_symmetric() ?
> > > > sounds good.
> > > > > > +{
> > > > > > + /* Display WA #1141: SKL:all KBL:all CNL:A CNL:B */
> > > > > move this to the wa call, not the the function check...
> > > > >
> > > > > > + if (INTEL_GEN(dev_priv) > 9 &&
> > > > > > + !IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0))
> > > > > please don't add CNL pre-prod wa
> > > > ok sure
> > > > > > + return true;
> > > > > > +
> > > > > > + if (!IS_KABYLAKE(dev_priv) && !IS_SKYLAKE(dev_priv))
> > > > > > + return true;
> > > > > actually remove all platforms checks here...
> > > > Agree will remove these checks, function will just return if memory is
> > > > symmetric.
> > > > > > +
> > > > > > + if (val_ch0 != val_ch1)
> > > > > > + return false;
> > > > > > +
> > > > > > + if (ch0->s_info.size == 0)
> > > > > > + return true;
> > > > > > + if (ch0->l_info.size == ch0->s_info.size &&
> > > > > > + ch0->l_info.width == ch0->s_info.width &&
> > > > > > + ch0->l_info.rank == ch0->s_info.rank)
> > > > > > + return true;
> > > > > > +
> > > > > > + return false;
> > > > > return (val_ch0 == val_ch1 && (ch0->s_info.size == 0 ||
> > > > > (ch0->l_info.size == ch0->s_info.size &&
> > > > > ch0->l_info.width == ch0->s_info.width &&
> > > > > ch0->l_info.rank == ch0->s_info.rank)))
> > > > >
> > > > > > +}
> > > > > > +
> > > > > > static int
> > > > > > skl_dram_get_channels_info(struct drm_i915_private *dev_priv)
> > > > > > {
> > > > > > struct dram_info *dram_info = _priv->dram_info;
> > > > > > struct dram_channel_info ch0, ch1;
> > > > > > - u32 val;
> > > > > > + u32 val_ch0, val_ch1;
> > > > > > int ret;
> > > > > >
> > > > > > - val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
> > > > > > - ret = skl_dram_get_channel_info(, val);
> > > > > > + val_ch0 = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
> > > > > > + ret = skl_dram_get_channel_info(, val_ch0);
> > > > > > if (ret == 0)
> > > > > > dram_info->num_channels++;
> > > > > >
> > > > > > - val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
> > > > > > - ret = skl_dram_get_channel_info(, val);
> > > > > > + val_ch1 = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
> > > > > > + ret = skl_dram_get_channel_info(, val_ch1);
> > > > > > if (ret == 0)
> > > > > > dram_info->num_channels++;
> > > > > >
> > > > > > @@ -1185,6 +1211,13 @@ skl_dram_get_channels_info(struct
> > > > > > drm_i915_private *dev_priv)
> > > > > > if (ch0.is_16gb_dimm || ch1.is_16gb_dimm)
> > > > > > dram_info->is_16gb_dimm = true;
> > > > > >
> > > > > > + if (intel_is_dram_ipc_capable(dev_priv, val_ch0, val_ch1,
> > > > > > ))
> > > > > > + dev_priv->ipc_capable_mem = true;
> > > > > > + else
> > > > > > + dev_priv->ipc_capable_mem = false;
> > > > > > +
> > > > > > + DRM_DEBUG_KMS("memory configuration is %sIPC capable\n",
> > > > > > + dev_priv->ipc_capable_mem ? "" : "not ");
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > index
Re: [Intel-gfx] [PATCH] drm/i915: Fix subslice configuration on Gen9LP
On 22/08/2018 16:22, Lionel Landwerlin wrote:
On 22/08/2018 16:17, Tvrtko Ursulin wrote:
On 22/08/2018 16:08, Lionel Landwerlin wrote:
On 22/08/2018 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count
power-
gating configuration register, the value to be written into it on
Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3 slices = 0x100
s/slice/subslice/
Also 0b001 etc... Not hexadecimal.
Oops, you're right.
And not the popcount of the enabled subslice mask as on other
platforms.
So on Gen9LP platforms we have been programming 0x11 into those
bits, but
the documentation does not explain what would that achieve. Could it be
that we enable only two subslice on three sub-slice parts? Or hardware
simply ignores it and sticks with the maximum configuration?
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Bspec: 12247
---
Could this actually be true or I am severely misreading the docs? It
does
not sound plausible to me this would have been missed all this time..
How to test in what configuration do these parts run before and
after this
patch?
---
drivers/gpu/drm/i915/intel_lrc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..cdfa962a1975 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2508,9 +2508,15 @@ make_rpcs(struct drm_i915_private *dev_priv)
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+ u8 val;
+
+ val = hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
+
+ if (IS_GEN9_LP(dev_priv))
+ val = BIT(val - 1);
Hmm... Are you breaking the 2 subslices setting here then?
(2 subslices = 0b10 which should be equal to hweight8(subslice_mask)
if I'm thinking right)
No and yes, I think.
subslice_mask = 0b011 => hweight = 2 => BIT(2 - 1) = BIT(1) = 0b010
into the register
In the same way, all together:
subslice_mask = 0b001 => hweight = 1 => BIT(0) = 0b001
subslice_mask = 0b011 => hweight = 2 => BIT(1) = 0b010
subslice_mask = 0b111 => hweight = 3 => BIT(2) = 0b100
Have I made a mistake somewhere?
Ah, yes! You're right :)
My eyes got tricked, thanks for finding this out.
At least half of the credit goes to you for linking to 12247 in scope of
one different thread!
With the comment fixed :
Reviewed-by: Lionel Landwerlin
Thanks!
Any ideas on how to test this? I'd like to commit message to be more
precise - have we been running with one slice too few? Or hardware
ignores the undocumented bit combination? Or even, is the documentation
perhaps incorrect?!
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix subslice configuration on Gen9LP
On 22/08/2018 16:17, Tvrtko Ursulin wrote:
On 22/08/2018 16:08, Lionel Landwerlin wrote:
On 22/08/2018 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count
power-
gating configuration register, the value to be written into it on
Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3 slices = 0x100
s/slice/subslice/
Also 0b001 etc... Not hexadecimal.
Oops, you're right.
And not the popcount of the enabled subslice mask as on other
platforms.
So on Gen9LP platforms we have been programming 0x11 into those
bits, but
the documentation does not explain what would that achieve. Could it be
that we enable only two subslice on three sub-slice parts? Or hardware
simply ignores it and sticks with the maximum configuration?
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Bspec: 12247
---
Could this actually be true or I am severely misreading the docs? It
does
not sound plausible to me this would have been missed all this time..
How to test in what configuration do these parts run before and
after this
patch?
---
drivers/gpu/drm/i915/intel_lrc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..cdfa962a1975 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2508,9 +2508,15 @@ make_rpcs(struct drm_i915_private *dev_priv)
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+ u8 val;
+
+ val = hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
+
+ if (IS_GEN9_LP(dev_priv))
+ val = BIT(val - 1);
Hmm... Are you breaking the 2 subslices setting here then?
(2 subslices = 0b10 which should be equal to hweight8(subslice_mask)
if I'm thinking right)
No and yes, I think.
subslice_mask = 0b011 => hweight = 2 => BIT(2 - 1) = BIT(1) = 0b010
into the register
In the same way, all together:
subslice_mask = 0b001 => hweight = 1 => BIT(0) = 0b001
subslice_mask = 0b011 => hweight = 2 => BIT(1) = 0b010
subslice_mask = 0b111 => hweight = 3 => BIT(2) = 0b100
Have I made a mistake somewhere?
Ah, yes! You're right :)
My eyes got tricked, thanks for finding this out.
With the comment fixed :
Reviewed-by: Lionel Landwerlin
Regards,
Tvrtko
+
rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
- rpcs |=
hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]) <<
- GEN8_RPCS_SS_CNT_SHIFT;
+ rpcs |= val << GEN8_RPCS_SS_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix subslice configuration on Gen9LP
On 22/08/2018 16:08, Lionel Landwerlin wrote:
On 22/08/2018 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count
power-
gating configuration register, the value to be written into it on Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3 slices = 0x100
s/slice/subslice/
Also 0b001 etc... Not hexadecimal.
Oops, you're right.
And not the popcount of the enabled subslice mask as on other platforms.
So on Gen9LP platforms we have been programming 0x11 into those bits, but
the documentation does not explain what would that achieve. Could it be
that we enable only two subslice on three sub-slice parts? Or hardware
simply ignores it and sticks with the maximum configuration?
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Bspec: 12247
---
Could this actually be true or I am severely misreading the docs? It does
not sound plausible to me this would have been missed all this time..
How to test in what configuration do these parts run before and after
this
patch?
---
drivers/gpu/drm/i915/intel_lrc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..cdfa962a1975 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2508,9 +2508,15 @@ make_rpcs(struct drm_i915_private *dev_priv)
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+ u8 val;
+
+ val = hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
+
+ if (IS_GEN9_LP(dev_priv))
+ val = BIT(val - 1);
Hmm... Are you breaking the 2 subslices setting here then?
(2 subslices = 0b10 which should be equal to hweight8(subslice_mask) if
I'm thinking right)
No and yes, I think.
subslice_mask = 0b011 => hweight = 2 => BIT(2 - 1) = BIT(1) = 0b010 into
the register
In the same way, all together:
subslice_mask = 0b001 => hweight = 1 => BIT(0) = 0b001
subslice_mask = 0b011 => hweight = 2 => BIT(1) = 0b010
subslice_mask = 0b111 => hweight = 3 => BIT(2) = 0b100
Have I made a mistake somewhere?
Regards,
Tvrtko
+
rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]) <<
- GEN8_RPCS_SS_CNT_SHIFT;
+ rpcs |= val << GEN8_RPCS_SS_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix subslice configuration on Gen9LP
On 22/08/2018 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count power-
gating configuration register, the value to be written into it on Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3 slices = 0x100
s/slice/subslice/
Also 0b001 etc... Not hexadecimal.
And not the popcount of the enabled subslice mask as on other platforms.
So on Gen9LP platforms we have been programming 0x11 into those bits, but
the documentation does not explain what would that achieve. Could it be
that we enable only two subslice on three sub-slice parts? Or hardware
simply ignores it and sticks with the maximum configuration?
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Bspec: 12247
---
Could this actually be true or I am severely misreading the docs? It does
not sound plausible to me this would have been missed all this time..
How to test in what configuration do these parts run before and after this
patch?
---
drivers/gpu/drm/i915/intel_lrc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..cdfa962a1975 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2508,9 +2508,15 @@ make_rpcs(struct drm_i915_private *dev_priv)
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+ u8 val;
+
+ val = hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
+
+ if (IS_GEN9_LP(dev_priv))
+ val = BIT(val - 1);
Hmm... Are you breaking the 2 subslices setting here then?
(2 subslices = 0b10 which should be equal to hweight8(subslice_mask) if
I'm thinking right)
+
rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]) <<
- GEN8_RPCS_SS_CNT_SHIFT;
+ rpcs |= val << GEN8_RPCS_SS_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] RFC: Migration to Gitlab
Hi Dan, On 22 August 2018 at 12:44, Daniel Vetter wrote: > Hi all, > > I think it's time to brainstorm a bit about the gitlab migration. Basic > reasons: > > - fd.o admins want to deprecate shell accounts and hand-rolled > infrastructure, because it's a pain to keep secure > > - gitlab will allow us to add committers on our own, greatly > simplifying that process (and offloading that task from fd.o admins). > Random thought - I really wish the admins spoke early and louder about issues. From infra to manpower and adhoc tool maintenance. > There's also some more benefits we might want to reap, like better CI > integration for basic build testing - no more "oops didn't build > drm-misc defconfigs" or "sry, forgot make check in maintainer-tools". > But that's all fully optional. > > For the full in-depth writeup of everything, see > > https://www.fooishbar.org/blog/gitlab-fdo-introduction/ > > I think now is also a good time, with mesa, xorg, wayland/weston and > others moved, to start thinking about how we'll move drm. There's a > few things to figure out though: > > - We probably want to split out maintainer-tools. That would address > the concern that there's 50+ committers to an auto-updating shell > script ... > > - We need to figure out how to handle the ACL trickery around drm-tip in > gitlab. > > - Probably good to stage the migration, with maintainer-tools, igt > leading. That will also make fd.o admins happy, who want to rework > their cloud infrastructure a bit before migrating the big kernel repos > over. > > - Figuring out the actual migration - we've been adding a pile of > committers since fd.o LDAP was converted to gitlab once back in > spring. We need to at least figure out how to move the new > accounts/committers. > As a observer, allow me to put some ideas. You've mostly covered them all, my emphasis is to seriously stick with _one_ thing at a time. Attempting to do multiple things in parallel will end up with sub-optimal results. - (at random point) cleanup the committers list - people who have not contributed in the last 1 year? - setup drm group, copy/migrate accounts - one could even reuse the existing credentials - move git repos to gitlab, the push URL change, cgit mirror preserves the normal fetch ones as well as PW hooks - work out how new accounts are handled - still in bugzilla, otherwise At this stage only workflow change is a) once-off account setup and b) pushURL update As a follow-up one can setup anything fancy. - migrate PW/other hooks - migrate bugs - if applicable - add new hooks - DRM docs, other - etc > - Similar, maintainer-tools needs to move. We probably want to move > all the dim maintained kernel repos in one go, to avoid headaches with > double-accounts needed for committers. > One should be able to create a separate repo for these. And then either: - one by one add the required features into the gitlab MR machinery, - or, wire the execution in pre/post merge stage. IIRC there are some upstream requests about the former. > - CI, linux-next and everyone else should be fine, since the > cgit/non-ssh paths will keep working (they'll be read-only mirrors). > Need to double-check that with everyone. > > - Some organization structure would be good. > > https://cgit.freedesktop.org/drm > > libdrm won't be part of the gitlab drm group because that's already > moved under mesa (and you can't symlink/mulit-home anymore on gitlab): > > https://gitlab.freedesktop.org/mesa/drm > > But there's also drm_hwcomposer, which we might want to migrate into > drm too - gitlab requires a containing group, and > drm_hwcomposer/drm_hwcomposer is a bit silly. > It did strike me a lot when drm_hwcomposer/drm_hwcomposer was introduced. Fortunately moving repos in gitlab is reasonably pain-free HTH Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix subslice configuration on Gen9LP
== Series Details ==
Series: drm/i915: Fix subslice configuration on Gen9LP
URL : https://patchwork.freedesktop.org/series/48566/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4696 -> Patchwork_9991 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48566/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9991:
=== IGT changes ===
Warnings
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: DMESG-FAIL -> DMESG-WARN
== Known issues ==
Here are the changes found in Patchwork_9991 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
fi-skl-guc: PASS -> DMESG-FAIL (fdo#107174)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713)
fi-cnl-psr: PASS -> DMESG-WARN (fdo#104951)
Possible fixes
igt@drv_selftest@live_hangcheck:
{fi-skl-iommu}: DMESG-FAIL (fdo#107174, fdo#106560) -> PASS
fi-kbl-7567u: DMESG-FAIL (fdo#106947, fdo#106560) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
{fi-byt-clapper}: FAIL (fdo#107362, fdo#103191) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
{fi-cfl-8109u}: INCOMPLETE (fdo#106070) -> PASS
Warnings
{igt@pm_rpm@module-reload}:
fi-cnl-psr: FAIL -> WARN (fdo#107602)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951
fdo#106070 https://bugs.freedesktop.org/show_bug.cgi?id=106070
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
== Participating hosts (54 -> 48) ==
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-glk-j4005
== Build changes ==
* Linux: CI_DRM_4696 -> Patchwork_9991
CI_DRM_4696: ced152c46fc90f7c1ac8963850d64c9f1ce652d6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9991: 75e3f1910f813b2dff2ae2794d9e84e9f832188c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
75e3f1910f81 drm/i915: Fix subslice configuration on Gen9LP
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9991/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gtt: Setup guards in scratch page (rev2)
== Series Details == Series: drm/i915/gtt: Setup guards in scratch page (rev2) URL : https://patchwork.freedesktop.org/series/48565/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4695_full -> Patchwork_9990_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9990_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9990_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9990_full: === IGT changes === Warnings igt@kms_chv_cursor_fail@pipe-a-128x128-right-edge: shard-snb: PASS -> SKIP +2 == Known issues == Here are the changes found in Patchwork_9990_full that come from known issues: === IGT changes === Issues hit igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363) -> PASS fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4695 -> Patchwork_9990 CI_DRM_4695: f352837700ec39dbaf00cdf727650851993d754b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9990: 39443beee0c02518071ab487cb3aa557dd9d5ce1 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9990/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab
On Wed, Aug 22, 2018 at 3:13 PM, Jani Nikula wrote: > On Wed, 22 Aug 2018, Daniel Vetter wrote: >> Hi all, >> >> I think it's time to brainstorm a bit about the gitlab migration. Basic >> reasons: >> >> - fd.o admins want to deprecate shell accounts and hand-rolled >> infrastructure, because it's a pain to keep secure >> >> - gitlab will allow us to add committers on our own, greatly >> simplifying that process (and offloading that task from fd.o admins). >> >> There's also some more benefits we might want to reap, like better CI >> integration for basic build testing - no more "oops didn't build >> drm-misc defconfigs" or "sry, forgot make check in maintainer-tools". >> But that's all fully optional. >> >> For the full in-depth writeup of everything, see >> >> https://www.fooishbar.org/blog/gitlab-fdo-introduction/ >> >> I think now is also a good time, with mesa, xorg, wayland/weston and >> others moved, to start thinking about how we'll move drm. There's a >> few things to figure out though: >> >> - We probably want to split out maintainer-tools. That would address >> the concern that there's 50+ committers to an auto-updating shell >> script ... >> >> - We need to figure out how to handle the ACL trickery around drm-tip in >> gitlab. >> >> - Probably good to stage the migration, with maintainer-tools, igt >> leading. That will also make fd.o admins happy, who want to rework >> their cloud infrastructure a bit before migrating the big kernel repos >> over. >> >> - Figuring out the actual migration - we've been adding a pile of >> committers since fd.o LDAP was converted to gitlab once back in >> spring. We need to at least figure out how to move the new >> accounts/committers. >> >> - Similar, maintainer-tools needs to move. We probably want to move >> all the dim maintained kernel repos in one go, to avoid headaches with >> double-accounts needed for committers. >> >> - CI, linux-next and everyone else should be fine, since the >> cgit/non-ssh paths will keep working (they'll be read-only mirrors). >> Need to double-check that with everyone. >> >> - Some organization structure would be good. >> >> https://cgit.freedesktop.org/drm >> >> libdrm won't be part of the gitlab drm group because that's already >> moved under mesa (and you can't symlink/mulit-home anymore on gitlab): >> >> https://gitlab.freedesktop.org/mesa/drm >> >> But there's also drm_hwcomposer, which we might want to migrate into >> drm too - gitlab requires a containing group, and >> drm_hwcomposer/drm_hwcomposer is a bit silly. >> >> Note: Access rights can be done at any level in the hierarchy, the >> organization is orthogonal to commit rights. >> >> - Anything else I've forgotten. >> >> A lot of this still needs to be figured out first. As a first step I'm >> looking for volunteers who want to join the fun, besides comments and >> thoughts on the overall topic of course. > > Just a couple of concerns from drm/i915 perspective for starters: > > - Patchwork integration. I think we'll want to keep patchwork for at > least intel-gfx etc. for the time being. IIUC the one thing we need is > some server side hook to update patchwork on git push. > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > drm-intel for the time being. Doing that migration in the same go is a > bit much I think. Reassignment across bugzilla and gitlab will be an > issue. Good points, forgot about both. Patchwork reading the mailing list should keep working as-is, but the update hook needs looking into. Disabling gitlab issues is a non-brainer, same with merge requests. Mesa is already doing that. For bugs I think it's best to entirely leave them out for now, and maybe reconsider when/if mesa has moved. Before that I don't think gitlab issues make any sense at all. For merge requests I think best approach is to enable them very selectively at first for testing out, and then making a per-subproject decision whether they make sense. E.g. I think for maintainer-tools integrating make check and the doc building into gitlab CI would be sweet, and worth looking into gitlab merge requests just to automate that. Again best left out of scope for the initial migration. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix subslice configuration on Gen9LP
On 22/08/18 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count power-
gating configuration register, the value to be written into it on Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3 slices = 0x100
And not the popcount of the enabled subslice mask as on other platforms.
So on Gen9LP platforms we have been programming 0x11 into those bits, but
the documentation does not explain what would that achieve. Could it be
that we enable only two subslice on three sub-slice parts? Or hardware
simply ignores it and sticks with the maximum configuration?
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Bspec: 12247
If it does turn out to be broken and this the correct fix then:
Fixes: 0cea6502bf9c ("drm/i915: Request full SSEU enablement on Gen9")
?
At that time code looked like:
+ if (INTEL_INFO(dev)->has_subslice_pg) {
+ rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
+ rpcs |= INTEL_INFO(dev)->subslice_per_slice <<
+ GEN8_RPCS_SS_CNT_SHIFT;
+ rpcs |= GEN8_RPCS_ENABLE;
+ }
So would had already most likely been broken.
Tvrtko
---
Could this actually be true or I am severely misreading the docs? It does
not sound plausible to me this would have been missed all this time..
How to test in what configuration do these parts run before and after this
patch?
---
drivers/gpu/drm/i915/intel_lrc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..cdfa962a1975 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2508,9 +2508,15 @@ make_rpcs(struct drm_i915_private *dev_priv)
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+ u8 val;
+
+ val = hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
+
+ if (IS_GEN9_LP(dev_priv))
+ val = BIT(val - 1);
+
rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]) <<
- GEN8_RPCS_SS_CNT_SHIFT;
+ rpcs |= val << GEN8_RPCS_SS_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix subslice configuration on Gen9LP
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count power-
gating configuration register, the value to be written into it on Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3 slices = 0x100
And not the popcount of the enabled subslice mask as on other platforms.
So on Gen9LP platforms we have been programming 0x11 into those bits, but
the documentation does not explain what would that achieve. Could it be
that we enable only two subslice on three sub-slice parts? Or hardware
simply ignores it and sticks with the maximum configuration?
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Bspec: 12247
---
Could this actually be true or I am severely misreading the docs? It does
not sound plausible to me this would have been missed all this time..
How to test in what configuration do these parts run before and after this
patch?
---
drivers/gpu/drm/i915/intel_lrc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 36050f085071..cdfa962a1975 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2508,9 +2508,15 @@ make_rpcs(struct drm_i915_private *dev_priv)
}
if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+ u8 val;
+
+ val = hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
+
+ if (IS_GEN9_LP(dev_priv))
+ val = BIT(val - 1);
+
rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]) <<
- GEN8_RPCS_SS_CNT_SHIFT;
+ rpcs |= val << GEN8_RPCS_SS_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab
On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote: > - Sticking to fdo bugzilla and disabling gitlab issues for at least > drm-intel for the time being. Doing that migration in the same go is a > bit much I think. Reassignment across bugzilla and gitlab will be an > issue. Can you elaborate a bit on the issues here? The actual move-the-bugs process has been pretty painless for the parts of xorg we've done so far. - ajax ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gtt: Setup guards in scratch page (rev2)
== Series Details ==
Series: drm/i915/gtt: Setup guards in scratch page (rev2)
URL : https://patchwork.freedesktop.org/series/48565/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4695 -> Patchwork_9990 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48565/revisions/2/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9990:
=== IGT changes ===
Possible regressions
{igt@pm_rpm@module-reload}:
fi-byt-j1900: NOTRUN -> DMESG-WARN
== Known issues ==
Here are the changes found in Patchwork_9990 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_coherency:
fi-gdg-551: PASS -> DMESG-FAIL (fdo#107164)
igt@drv_selftest@live_hangcheck:
fi-kbl-7560u: PASS -> DMESG-FAIL (fdo#106947, fdo#106560)
fi-skl-guc: PASS -> DMESG-FAIL (fdo#107174)
{igt@kms_psr@primary_page_flip}:
{fi-icl-u}: NOTRUN -> FAIL (fdo#107383) +3
{igt@pm_rpm@module-reload}:
fi-cnl-psr: PASS -> WARN (fdo#107602)
Possible fixes
igt@drv_selftest@live_hangcheck:
{fi-cfl-8109u}: DMESG-FAIL (fdo#106560) -> PASS
igt@kms_frontbuffer_tracking@basic:
{fi-byt-clapper}: FAIL (fdo#103167) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107383 https://bugs.freedesktop.org/show_bug.cgi?id=107383
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
== Participating hosts (52 -> 48) ==
Additional (2): fi-byt-j1900 fi-icl-u
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
== Build changes ==
* Linux: CI_DRM_4695 -> Patchwork_9990
CI_DRM_4695: f352837700ec39dbaf00cdf727650851993d754b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9990: 39443beee0c02518071ab487cb3aa557dd9d5ce1 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
39443beee0c0 drm/i915/gtt: Setup guards in scratch page
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9990/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gtt: Setup guards in scratch page
Quoting Mika Kuoppala (2018-08-22 14:27:14) > There have been cases where GPU engine has managed to run past > execbuffer ending due to reasons unknown at that time: > coherency problems, page table setup errors, hw glitches. You are trading an obvious error for a subtle one; if userspace got its batch wrong and doesn't die, the output will likely be wrong instead. mesa/src/intel/tools/intel_sanitize_gpu for how userspace could do this detection itself. You can intercept the execbuf, place a canary after the batch and report if the canary gets written. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gtt: Setup guards in scratch page (rev2)
== Series Details == Series: drm/i915/gtt: Setup guards in scratch page (rev2) URL : https://patchwork.freedesktop.org/series/48565/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/gtt: Setup guards in scratch page +drivers/gpu/drm/i915/i915_gem_gtt.c:1017:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1017:9: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gem_gtt.c:1017:9: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gem_gtt.c:1017:9: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gtt: Setup guards in scratch page
There have been cases where GPU engine has managed to run past
execbuffer ending due to reasons unknown at that time:
coherency problems, page table setup errors, hw glitches.
Let's try to contain a wild engine head by putting batch
buffer end commands into start and end of scratch page.
v2: add more signature
Cc: Chris Wilson
Cc: Matthew Auld
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4137af4bd8f5..3c617874ee7c 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -617,6 +617,24 @@ static void fill_page_dma_32(struct i915_address_space *vm,
fill_page_dma(vm, p, (u64)v << 32 | v);
}
+static void setup_scratch_page_guards(struct i915_address_space *vm)
+{
+ struct i915_page_dma const *p = >scratch_page;
+ u32 *scratch;
+ const unsigned int size = BIT(p->order) << PAGE_SHIFT;
+ const unsigned int last_idx = size / sizeof(*scratch) - 1;
+
+ scratch = kmap_atomic(p->page);
+
+ scratch[0] = MI_BATCH_BUFFER_END;
+ scratch[1] = MI_BATCH_BUFFER_END;
+
+ scratch[last_idx - 1] = MI_BATCH_BUFFER_END;
+ scratch[last_idx] = MI_BATCH_BUFFER_END;
+
+ kunmap_atomic(scratch);
+}
+
static int
setup_scratch_page(struct i915_address_space *vm, gfp_t gfp)
{
@@ -665,6 +683,9 @@ setup_scratch_page(struct i915_address_space *vm, gfp_t gfp)
vm->scratch_page.page = page;
vm->scratch_page.daddr = addr;
vm->scratch_page.order = order;
+
+ setup_scratch_page_guards(vm);
+
return 0;
unmap_page:
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gtt: Setup guards in scratch page
There have been cases where GPU engine has managed to run past
execbuffer ending due to reasons unknown at that time:
coherency problems, page table setup errors, hw glitches.
Let's try to contain a wild engine head by putting batch
buffer end commands into start and end of scratch page.
Leave two nops at start of page so it would catch the
eye on error dumps.
Cc: Chris Wilson
Cc: Matthew Auld
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4137af4bd8f5..56399dbf4558 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -617,6 +617,21 @@ static void fill_page_dma_32(struct i915_address_space *vm,
fill_page_dma(vm, p, (u64)v << 32 | v);
}
+static void setup_scratch_page_guards(struct i915_address_space *vm)
+{
+ struct i915_page_dma const *p = >scratch_page;
+ u32 *scratch;
+ const unsigned int size = BIT(p->order) << PAGE_SHIFT;
+ const unsigned int last_idx = size / sizeof(*scratch) - 1;
+
+ scratch = kmap_atomic(p->page);
+
+ scratch[2] = MI_BATCH_BUFFER_END;
+ scratch[last_idx] = MI_BATCH_BUFFER_END;
+
+ kunmap_atomic(scratch);
+}
+
static int
setup_scratch_page(struct i915_address_space *vm, gfp_t gfp)
{
@@ -665,6 +680,9 @@ setup_scratch_page(struct i915_address_space *vm, gfp_t gfp)
vm->scratch_page.page = page;
vm->scratch_page.daddr = addr;
vm->scratch_page.order = order;
+
+ setup_scratch_page_guards(vm);
+
return 0;
unmap_page:
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Correct CSB probing for engine state dumper
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-08-21 08:58:26)
>> Chris Wilson writes:
>>
>> > Since we no longer maintain our read position in the CSB pointers
>> > register, it always returns 0 and not where we last read up to. As a
>> > result the CSB probing in the state dumper starts from 0, either missing
>> > entries or showing stale one.
>> >
>> > Signed-off-by: Chris Wilson
>> > Cc: Mika Kuoppala
>> > ---
>> > drivers/gpu/drm/i915/intel_engine_cs.c | 24
>> > 1 file changed, 12 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
>> > b/drivers/gpu/drm/i915/intel_engine_cs.c
>> > index 8628567d8f6e..49b580c188eb 100644
>> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
>> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
>> > @@ -1345,20 +1345,20 @@ static void intel_engine_print_registers(const
>> > struct intel_engine_cs *engine,
>> >
>> > if (HAS_EXECLISTS(dev_priv)) {
>> > const u32 *hws =
>> > >status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
>> > - u32 ptr, read, write;
>> > unsigned int idx;
>> > + u8 read, write;
>> >
>> > drm_printf(m, "\tExeclist status: 0x%08x %08x\n",
>> > I915_READ(RING_EXECLIST_STATUS_LO(engine)),
>> > I915_READ(RING_EXECLIST_STATUS_HI(engine)));
>> >
>> > - ptr = I915_READ(RING_CONTEXT_STATUS_PTR(engine));
>> > - read = GEN8_CSB_READ_PTR(ptr);
>> > - write = GEN8_CSB_WRITE_PTR(ptr);
>> > - drm_printf(m, "\tExeclist CSB read %d [%d cached], write %d
>> > [%d from hws], tasklet queued? %s (%s)\n",
>> > -read, execlists->csb_head,
>> > -write,
>> > -intel_read_status_page(engine,
>> > intel_hws_csb_write_index(engine->i915)),
>> > + read = execlists->csb_head;
>> > + write = intel_read_status_page(engine,
>> > +
>> > intel_hws_csb_write_index(dev_priv));
>> > +
>> > + drm_printf(m, "\tExeclist CSB read %d, write %d [mmio:%d],
>> > tasklet queued? %s (%s)\n",
>> > +read, write,
>>
>> In here I was thinking that we want to keep the write as 32bit so it
>> would show weirdness in here with %d. But the odds of that to happen
>> with only in this status page entry...
>
> Hmm, it was u8 for automatically truncating execlists->csb_write...
> Oh, this should have been write = READ_ONCE(*execlists->csb_write);
>
> Mind if I make that change?
Please do.
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab
On Wed, 22 Aug 2018, Daniel Vetter wrote: > Hi all, > > I think it's time to brainstorm a bit about the gitlab migration. Basic > reasons: > > - fd.o admins want to deprecate shell accounts and hand-rolled > infrastructure, because it's a pain to keep secure > > - gitlab will allow us to add committers on our own, greatly > simplifying that process (and offloading that task from fd.o admins). > > There's also some more benefits we might want to reap, like better CI > integration for basic build testing - no more "oops didn't build > drm-misc defconfigs" or "sry, forgot make check in maintainer-tools". > But that's all fully optional. > > For the full in-depth writeup of everything, see > > https://www.fooishbar.org/blog/gitlab-fdo-introduction/ > > I think now is also a good time, with mesa, xorg, wayland/weston and > others moved, to start thinking about how we'll move drm. There's a > few things to figure out though: > > - We probably want to split out maintainer-tools. That would address > the concern that there's 50+ committers to an auto-updating shell > script ... > > - We need to figure out how to handle the ACL trickery around drm-tip in > gitlab. > > - Probably good to stage the migration, with maintainer-tools, igt > leading. That will also make fd.o admins happy, who want to rework > their cloud infrastructure a bit before migrating the big kernel repos > over. > > - Figuring out the actual migration - we've been adding a pile of > committers since fd.o LDAP was converted to gitlab once back in > spring. We need to at least figure out how to move the new > accounts/committers. > > - Similar, maintainer-tools needs to move. We probably want to move > all the dim maintained kernel repos in one go, to avoid headaches with > double-accounts needed for committers. > > - CI, linux-next and everyone else should be fine, since the > cgit/non-ssh paths will keep working (they'll be read-only mirrors). > Need to double-check that with everyone. > > - Some organization structure would be good. > > https://cgit.freedesktop.org/drm > > libdrm won't be part of the gitlab drm group because that's already > moved under mesa (and you can't symlink/mulit-home anymore on gitlab): > > https://gitlab.freedesktop.org/mesa/drm > > But there's also drm_hwcomposer, which we might want to migrate into > drm too - gitlab requires a containing group, and > drm_hwcomposer/drm_hwcomposer is a bit silly. > > Note: Access rights can be done at any level in the hierarchy, the > organization is orthogonal to commit rights. > > - Anything else I've forgotten. > > A lot of this still needs to be figured out first. As a first step I'm > looking for volunteers who want to join the fun, besides comments and > thoughts on the overall topic of course. Just a couple of concerns from drm/i915 perspective for starters: - Patchwork integration. I think we'll want to keep patchwork for at least intel-gfx etc. for the time being. IIUC the one thing we need is some server side hook to update patchwork on git push. - Sticking to fdo bugzilla and disabling gitlab issues for at least drm-intel for the time being. Doing that migration in the same go is a bit much I think. Reassignment across bugzilla and gitlab will be an issue. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v4 3/8] drm: Add Plane CTM property
On Wed, Aug 22, 2018 at 12:11:42PM +0100, Brian Starkey wrote:
> Hi,
>
> On Wed, Aug 22, 2018 at 12:53:58PM +0300, Ville Syrjälä wrote:
> >On Wed, Aug 22, 2018 at 08:40:19AM +, Lankhorst, Maarten wrote:
> >> fre 2018-08-17 klockan 19:48 +0530 skrev Uma Shankar:
> >> > Add a blob property for plane CSC usage.
> >> >
> >> > v2: Rebase
> >> >
> >> > v3: Fixed Sean, Paul's review comments. Moved the property from
> >> > mode_config to drm_plane. Created a helper function to instantiate
> >> > these properties and removed from drm_mode_create_standard_properties
> >> > Added property documentation as suggested by Daniel, Vetter.
> >> >
> >> > v4: Rebase
> >> >
> >> > Signed-off-by: Uma Shankar
> >> > ---
> >> > Documentation/gpu/drm-kms.rst | 3 +++
> >> > drivers/gpu/drm/drm_atomic.c| 10 ++
> >> > drivers/gpu/drm/drm_atomic_helper.c | 4
> >> > drivers/gpu/drm/drm_plane.c | 12
> >> > include/drm/drm_plane.h | 15 +++
> >> > 5 files changed, 44 insertions(+)
> >> >
> >> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-
> >> > kms.rst
> >> > index 8b10b12..16d6d8d 100644
> >> > --- a/Documentation/gpu/drm-kms.rst
> >> > +++ b/Documentation/gpu/drm-kms.rst
> >> > @@ -560,6 +560,9 @@ Plane Color Management Properties
> >> > .. kernel-doc:: drivers/gpu/drm/drm_plane.c
> >> > :doc: degamma_lut_size_property
> >> >
> >> > +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> >> > + :doc: ctm_property
> >> > +
> >> > Tile Group Property
> >> > ---
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_atomic.c
> >> > b/drivers/gpu/drm/drm_atomic.c
> >> > index f8cad9b..ddda935 100644
> >> > --- a/drivers/gpu/drm/drm_atomic.c
> >> > +++ b/drivers/gpu/drm/drm_atomic.c
> >> > @@ -917,6 +917,14 @@ static int drm_atomic_plane_set_property(struct
> >> > drm_plane *plane,
> >> > );
> >> > state->color_mgmt_changed |= replaced;
> >> > return ret;
> >> > +} else if (property == plane->ctm_property) {
> >> > +ret = drm_atomic_replace_property_blob_from_id(dev,
> >> > +>ctm,
> >> > +val,
> >> > +sizeof(struct
> >> > drm_color_ctm), -1,
> >> > +);
> >> > +state->color_mgmt_changed |= replaced;
> >> > +return ret;
> >> > } else if (plane->funcs->atomic_set_property) {
> >> > return plane->funcs->atomic_set_property(plane,
> >> > state,
> >> > property, val);
> >> > @@ -988,6 +996,8 @@ static int drm_atomic_plane_set_property(struct
> >> > drm_plane *plane,
> >> > } else if (property == plane->degamma_lut_property) {
> >> > *val = (state->degamma_lut) ?
> >> > state->degamma_lut->base.id : 0;
> >> > +} else if (property == plane->ctm_property) {
> >> > +*val = (state->ctm) ? state->ctm->base.id : 0;
> >> > } else if (plane->funcs->atomic_get_property) {
> >> > return plane->funcs->atomic_get_property(plane,
> >> > state, property, val);
> >> > } else {
> >> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> > b/drivers/gpu/drm/drm_atomic_helper.c
> >> > index 67c5b51..866181f 100644
> >> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> > @@ -3616,6 +3616,9 @@ void
> >> > __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
> >> >
> >> > if (state->degamma_lut)
> >> > drm_property_blob_get(state->degamma_lut);
> >> > +if (state->ctm)
> >> > +drm_property_blob_get(state->ctm);
> >> > +
> >> > state->color_mgmt_changed = false;
> >> > }
> >> > EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
> >> > @@ -3663,6 +3666,7 @@ void
> >> > __drm_atomic_helper_plane_destroy_state(struct drm_plane_state
> >> > *state)
> >> > drm_crtc_commit_put(state->commit);
> >> >
> >> > drm_property_blob_put(state->degamma_lut);
> >> > +drm_property_blob_put(state->ctm);
> >> > }
> >> > EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_plane.c
> >> > b/drivers/gpu/drm/drm_plane.c
> >> > index 03e0560..97520b1 100644
> >> > --- a/drivers/gpu/drm/drm_plane.c
> >> > +++ b/drivers/gpu/drm/drm_plane.c
> >> > @@ -489,6 +489,11 @@ int drm_mode_plane_set_obj_prop(struct drm_plane
> >> > *plane,
> >> > *
> >> > * degamma_lut_size_property:
> >> > * Range Property to indicate size of the plane degamma LUT.
> >> > + *
> >> > + * ctm_property:
> >> > + * Blob property which allows a userspace to provide CTM
> >> > coefficients
> >> > + * to do color space
Re: [Intel-gfx] [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option
Quoting Tvrtko Ursulin (2018-08-22 15:49:52) > > On 21/08/2018 13:06, Joonas Lahtinen wrote: > > Quoting Kukanova, Svetlana (2018-08-13 16:44:49) > >> Joonas, sorry for interfering; could you please explain more regarding the > >> options for tracing scheduling events better than tracepoints? > >> After scheduling moves to GuC tools will have to switch to something like > >> GuC-logging; but while kmd does scheduling isn't kernel-tracing the best > >> solution? > >> I know gpuvis is not the only attempt to use tracepoints for the same > >> purpose. > >> (there're trace.pl and S.E.A. and of course VTune though it probably is not > >> considered to be existing as it's not open source). > >> And assuming this movement towards GuC is it not too late to invent a > >> completely new way to provide tools with scheduling info from kmd? > >> Could we just improve the existing way and let it live its last > >> years\months? > > > > Hi, > > > > You actually mentioned the prime reason why we should not go and > > hastily make tracepoints a stable uAPI with regards to scheduling > > information. > > > > The scheduler's nature will be evolving when some of the scheduling > > decisions are moved to GuC and the way how we get the information > > will be changing at that point, so tracepoints will indeed be a > > very bad mechanism for providing the information. > > > > The kernel scheduler is definitely not going anywhere with the > > introduction of more hardware scheduling capabilities, so it is a > > misconception to think that the interface would need to be completely > > different for when GuC is enabled. To clarify, I meant to underline that there is not going to be a steep switching point where a transition from interface A to B, which Svetlana referred to, would happen naturally. The introduced interface will have to provide the information for years and kernel versions to come, and we already have a some data that tracepoints may not be the format of choice due to GuC. > On the last paragraph - even with the today's GuC i915 already loses > visibility of CSB interrupts. So there is already a big difference in > semantics of what request_in and request_out tracepoints mean. Put > preemption into the picture and we just don't know any more when > something started executing on the GPU, when it got preempted, > re-submitted etc. So I think it is fair to say that moving more of > scheduling into the GuC creates a problem for tools which want to > represent request execution timelines. Yes, for tools that depend on the tracepoints. That's why it is most likely best to introduce the information in some other form, but I am starting to sound like a broken record already :) Regards, Joonas > > Regards, > > Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] RFC: Migration to Gitlab
On Wed, Aug 22, 2018 at 01:44:56PM +0200, Daniel Vetter wrote: > Hi all, > > I think it's time to brainstorm a bit about the gitlab migration. Basic > reasons: > > - fd.o admins want to deprecate shell accounts and hand-rolled > infrastructure, because it's a pain to keep secure > > - gitlab will allow us to add committers on our own, greatly > simplifying that process (and offloading that task from fd.o admins). > > There's also some more benefits we might want to reap, like better CI > integration for basic build testing - no more "oops didn't build > drm-misc defconfigs" or "sry, forgot make check in maintainer-tools". > But that's all fully optional. > > For the full in-depth writeup of everything, see > > https://www.fooishbar.org/blog/gitlab-fdo-introduction/ > > I think now is also a good time, with mesa, xorg, wayland/weston and > others moved, to start thinking about how we'll move drm. There's a > few things to figure out though: > > - We probably want to split out maintainer-tools. That would address > the concern that there's 50+ committers to an auto-updating shell > script ... > /me laughs nervously > - We need to figure out how to handle the ACL trickery around drm-tip in > gitlab. > > - Probably good to stage the migration, with maintainer-tools, igt > leading. That will also make fd.o admins happy, who want to rework > their cloud infrastructure a bit before migrating the big kernel repos > over. > > - Figuring out the actual migration - we've been adding a pile of > committers since fd.o LDAP was converted to gitlab once back in > spring. We need to at least figure out how to move the new > accounts/committers. > > - Similar, maintainer-tools needs to move. We probably want to move > all the dim maintained kernel repos in one go, to avoid headaches with > double-accounts needed for committers. > > - CI, linux-next and everyone else should be fine, since the > cgit/non-ssh paths will keep working (they'll be read-only mirrors). > Need to double-check that with everyone. They can also pull the trees from git://gitlab.fd.o/blah as normal, just need to give them new pointers once we're stable. > > - Some organization structure would be good. > > https://cgit.freedesktop.org/drm > > libdrm won't be part of the gitlab drm group because that's already > moved under mesa (and you can't symlink/mulit-home anymore on gitlab): > > https://gitlab.freedesktop.org/mesa/drm > > But there's also drm_hwcomposer, which we might want to migrate into > drm too - gitlab requires a containing group, and > drm_hwcomposer/drm_hwcomposer is a bit silly. This seems fine to me. Our expansion plans likely aren't big enough to warrant a separate group. > > Note: Access rights can be done at any level in the hierarchy, the > organization is orthogonal to commit rights. > > - Anything else I've forgotten. > > A lot of this still needs to be figured out first. As a first step I'm > looking for volunteers who want to join the fun, besides comments and > thoughts on the overall topic of course. I'm pretty keen on getting this done, so I'll volunteer some cycles if there's something that needs doing. Sean > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option
On 22/08/2018 13:49, Tvrtko Ursulin wrote: On 21/08/2018 13:06, Joonas Lahtinen wrote: Quoting Kukanova, Svetlana (2018-08-13 16:44:49) Joonas, sorry for interfering; could you please explain more regarding the options for tracing scheduling events better than tracepoints? After scheduling moves to GuC tools will have to switch to something like GuC-logging; but while kmd does scheduling isn't kernel-tracing the best solution? I know gpuvis is not the only attempt to use tracepoints for the same purpose. (there're trace.pl and S.E.A. and of course VTune though it probably is not considered to be existing as it's not open source). And assuming this movement towards GuC is it not too late to invent a completely new way to provide tools with scheduling info from kmd? Could we just improve the existing way and let it live its last years\months? Hi, You actually mentioned the prime reason why we should not go and hastily make tracepoints a stable uAPI with regards to scheduling information. The scheduler's nature will be evolving when some of the scheduling decisions are moved to GuC and the way how we get the information will be changing at that point, so tracepoints will indeed be a very bad mechanism for providing the information. The kernel scheduler is definitely not going anywhere with the introduction of more hardware scheduling capabilities, so it is a misconception to think that the interface would need to be completely different for when GuC is enabled. On the last paragraph - even with the today's GuC i915 already loses visibility of CSB interrupts. So there is already a big difference in semantics of what request_in and request_out tracepoints mean. Put preemption into the picture and we just don't know any more when something started executing on the GPU, when it got preempted, re-submitted etc. So I think it is fair to say that moving more of scheduling into the GuC creates a problem for tools which want to represent request execution timelines. P.S. To clarify - which is exactly why we marked those tracpoints as low level and why it is problematic to rely on them. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915/kbl+: Enable IPC only for symmetric memory configurations
Hi,
On 8/22/2018 12:26 AM, Rodrigo Vivi wrote:
On Tue, Aug 21, 2018 at 09:30:21PM +0530, Kumar, Mahesh wrote:
Hi,
On 8/21/2018 8:27 PM, Kumar, Mahesh wrote:
Hi,
On 8/17/2018 11:50 PM, Rodrigo Vivi wrote:
On Thu, Jul 26, 2018 at 07:44:09PM +0530, Mahesh Kumar wrote:
IPC may cause underflows if not used with dual channel symmetric
memory configuration. Disable IPC for non symmetric configurations in
affected platforms.
Display WA #1141
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_drv.c | 43
-
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 2 +-
3 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 86bc2e685522..2273664166bc 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1141,21 +1141,47 @@ skl_dram_get_channel_info(struct
dram_channel_info *ch, u32 val)
return 0;
}
+static bool
+intel_is_dram_ipc_capable(struct drm_i915_private *dev_priv,
+ u32 val_ch0, u32 val_ch1,
+ struct dram_channel_info *ch0)
what about
intel_is_dram_symmetric() ?
sounds good.
+{
+ /* Display WA #1141: SKL:all KBL:all CNL:A CNL:B */
move this to the wa call, not the the function check...
+ if (INTEL_GEN(dev_priv) > 9 &&
+ !IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0))
please don't add CNL pre-prod wa
ok sure
+ return true;
+
+ if (!IS_KABYLAKE(dev_priv) && !IS_SKYLAKE(dev_priv))
+ return true;
actually remove all platforms checks here...
Agree will remove these checks, function will just return if memory is
symmetric.
+
+ if (val_ch0 != val_ch1)
+ return false;
+
+ if (ch0->s_info.size == 0)
+ return true;
+ if (ch0->l_info.size == ch0->s_info.size &&
+ ch0->l_info.width == ch0->s_info.width &&
+ ch0->l_info.rank == ch0->s_info.rank)
+ return true;
+
+ return false;
return (val_ch0 == val_ch1 && (ch0->s_info.size == 0 ||
(ch0->l_info.size == ch0->s_info.size &&
ch0->l_info.width == ch0->s_info.width &&
ch0->l_info.rank == ch0->s_info.rank)))
+}
+
static int
skl_dram_get_channels_info(struct drm_i915_private *dev_priv)
{
struct dram_info *dram_info = _priv->dram_info;
struct dram_channel_info ch0, ch1;
- u32 val;
+ u32 val_ch0, val_ch1;
int ret;
- val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
- ret = skl_dram_get_channel_info(, val);
+ val_ch0 = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
+ ret = skl_dram_get_channel_info(, val_ch0);
if (ret == 0)
dram_info->num_channels++;
- val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
- ret = skl_dram_get_channel_info(, val);
+ val_ch1 = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
+ ret = skl_dram_get_channel_info(, val_ch1);
if (ret == 0)
dram_info->num_channels++;
@@ -1185,6 +1211,13 @@ skl_dram_get_channels_info(struct
drm_i915_private *dev_priv)
if (ch0.is_16gb_dimm || ch1.is_16gb_dimm)
dram_info->is_16gb_dimm = true;
+ if (intel_is_dram_ipc_capable(dev_priv, val_ch0, val_ch1, ))
+ dev_priv->ipc_capable_mem = true;
+ else
+ dev_priv->ipc_capable_mem = false;
+
+ DRM_DEBUG_KMS("memory configuration is %sIPC capable\n",
+ dev_priv->ipc_capable_mem ? "" : "not ");
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 854f3c828e01..036d6554c017 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2112,6 +2112,7 @@ struct drm_i915_private {
bool chv_phy_assert[2];
bool ipc_enabled;
+ bool ipc_capable_mem;
I don't think we need to stage this...
With above changes storing this info is not needed, But we need to keep
a flag in dram_info to check if "memory is symmetric", Otherwise we need
to compute all the memory related info again.
-Mahesh
/* Used to save the pipe-to-encoder mapping for audio */
struct intel_encoder *av_enc_map[I915_MAX_PIPES];
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 2446f53adf21..39e400d5f555 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6097,7 +6097,7 @@ void intel_enable_ipc(struct
drm_i915_private *dev_priv)
u32 val;
/* Display WA #0477 WaDisableIPC: skl */
- if (IS_SKYLAKE(dev_priv)) {
+ if (IS_SKYLAKE(dev_priv) || !dev_priv->ipc_capable_mem) {
dev_priv->ipc_enabled = false;
This is not the WA 1141 for other platforms than SKL. Please only
keep skl here.
For the other WA add 4us across all watermark levels
/* Display WA #1141: skl,kbl,cfl */
if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) &&
intel_is_dram_symmetric())
levels += 4;
Adding 4us in latency is
Re: [Intel-gfx] [PATCH 4/4] drm/fb: Stop leaking physical address
On Wed, Aug 22, 2018 at 10:54:05AM +0200, Daniel Vetter wrote: > For buffer sharing, use dma-buf instead. We can't set smem_start to 0 > unconditionally since that's used by the fbdev mmap default > implementation. And we have plenty of userspace which would like to > keep that working. > > This might break legit userspace - if it does we need to look at a > case-by-cases basis how to handle that. Worst case I expect overrides > for only specific drivers, since anything remotely modern should be > using dma-buf/prime now (which is about 7 years old now for DRM > drivers). > > This issue was uncovered because Noralf's rework to implement a > generic fb_probe also implements it's own fb_mmap callback. Which > means smem_start didn't have to be set anymore, which blew up some > blob in userspace rather badly. > > Cc: Gustavo Padovan > Cc: Maarten Lankhorst > Cc: Sean Paul > Cc: David Airlie > Cc: John Stultz > Cc: Noralf Trønnes > Signed-off-by: Daniel Vetter After clarifying on IRC, I think this makes sense. The chance to break userspace requires a very specific configuration that I don't expect will be common. Acked-by: Sean Paul > --- > drivers/gpu/drm/drm_fb_helper.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index 4b0dd20bccb8..bcb78693c4f7 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -2673,6 +2673,8 @@ __drm_fb_helper_initial_config_and_unlock(struct > drm_fb_helper *fb_helper, > > info = fb_helper->fbdev; > info->var.pixclock = 0; > + /* don't leak any physical addresses to userspace */ > + info->flags |= FBINFO_HIDE_SMEM_START; > > /* Need to drop locks to avoid recursive deadlock in >* register_framebuffer. This is ok because the only thing left to do is > -- > 2.18.0 > -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v4 3/8] drm: Add Plane CTM property
ons 2018-08-22 klockan 12:11 +0100 skrev Brian Starkey:
> Hi,
>
> On Wed, Aug 22, 2018 at 12:53:58PM +0300, Ville Syrjälä wrote:
> > On Wed, Aug 22, 2018 at 08:40:19AM +, Lankhorst, Maarten wrote:
> > > fre 2018-08-17 klockan 19:48 +0530 skrev Uma Shankar:
> > > > Add a blob property for plane CSC usage.
> > > >
> > > > v2: Rebase
> > > >
> > > > v3: Fixed Sean, Paul's review comments. Moved the property from
> > > > mode_config to drm_plane. Created a helper function to
> > > > instantiate
> > > > these properties and removed from
> > > > drm_mode_create_standard_properties
> > > > Added property documentation as suggested by Daniel, Vetter.
> > > >
> > > > v4: Rebase
> > > >
> > > > Signed-off-by: Uma Shankar
> > > > ---
> > > > Documentation/gpu/drm-kms.rst | 3 +++
> > > > drivers/gpu/drm/drm_atomic.c| 10 ++
> > > > drivers/gpu/drm/drm_atomic_helper.c | 4
> > > > drivers/gpu/drm/drm_plane.c | 12
> > > > include/drm/drm_plane.h | 15 +++
> > > > 5 files changed, 44 insertions(+)
> > > >
> > > > diff --git a/Documentation/gpu/drm-kms.rst
> > > > b/Documentation/gpu/drm-
> > > > kms.rst
> > > > index 8b10b12..16d6d8d 100644
> > > > --- a/Documentation/gpu/drm-kms.rst
> > > > +++ b/Documentation/gpu/drm-kms.rst
> > > > @@ -560,6 +560,9 @@ Plane Color Management Properties
> > > > .. kernel-doc:: drivers/gpu/drm/drm_plane.c
> > > > :doc: degamma_lut_size_property
> > > >
> > > > +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> > > > + :doc: ctm_property
> > > > +
> > > > Tile Group Property
> > > > ---
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > > b/drivers/gpu/drm/drm_atomic.c
> > > > index f8cad9b..ddda935 100644
> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > @@ -917,6 +917,14 @@ static int
> > > > drm_atomic_plane_set_property(struct
> > > > drm_plane *plane,
> > > > );
> > > > state->color_mgmt_changed |= replaced;
> > > > return ret;
> > > > + } else if (property == plane->ctm_property) {
> > > > + ret =
> > > > drm_atomic_replace_property_blob_from_id(dev,
> > > > + >ctm,
> > > > + val,
> > > > + sizeof(struct
> > > > drm_color_ctm), -1,
> > > > + );
> > > > + state->color_mgmt_changed |= replaced;
> > > > + return ret;
> > > > } else if (plane->funcs->atomic_set_property) {
> > > > return plane->funcs-
> > > > >atomic_set_property(plane,
> > > > state,
> > > > property, val);
> > > > @@ -988,6 +996,8 @@ static int
> > > > drm_atomic_plane_set_property(struct
> > > > drm_plane *plane,
> > > > } else if (property == plane->degamma_lut_property) {
> > > > *val = (state->degamma_lut) ?
> > > > state->degamma_lut->base.id : 0;
> > > > + } else if (property == plane->ctm_property) {
> > > > + *val = (state->ctm) ? state->ctm->base.id : 0;
> > > > } else if (plane->funcs->atomic_get_property) {
> > > > return plane->funcs-
> > > > >atomic_get_property(plane,
> > > > state, property, val);
> > > > } else {
> > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > index 67c5b51..866181f 100644
> > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > @@ -3616,6 +3616,9 @@ void
> > > > __drm_atomic_helper_plane_duplicate_state(struct drm_plane
> > > > *plane,
> > > >
> > > > if (state->degamma_lut)
> > > > drm_property_blob_get(state->degamma_lut);
> > > > + if (state->ctm)
> > > > + drm_property_blob_get(state->ctm);
> > > > +
> > > > state->color_mgmt_changed = false;
> > > > }
> > > > EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
> > > > @@ -3663,6 +3666,7 @@ void
> > > > __drm_atomic_helper_plane_destroy_state(struct drm_plane_state
> > > > *state)
> > > > drm_crtc_commit_put(state->commit);
> > > >
> > > > drm_property_blob_put(state->degamma_lut);
> > > > + drm_property_blob_put(state->ctm);
> > > > }
> > > > EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_plane.c
> > > > b/drivers/gpu/drm/drm_plane.c
> > > > index 03e0560..97520b1 100644
> > > > --- a/drivers/gpu/drm/drm_plane.c
> > > > +++ b/drivers/gpu/drm/drm_plane.c
> > > > @@ -489,6 +489,11 @@ int drm_mode_plane_set_obj_prop(struct
> > > > drm_plane
> > > > *plane,
> > > > *
> > > > * degamma_lut_size_property:
> > > > * Range Property to indicate size of the plane degamma
> > > >
Re: [Intel-gfx] [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option
On 21/08/2018 13:06, Joonas Lahtinen wrote: Quoting Kukanova, Svetlana (2018-08-13 16:44:49) Joonas, sorry for interfering; could you please explain more regarding the options for tracing scheduling events better than tracepoints? After scheduling moves to GuC tools will have to switch to something like GuC-logging; but while kmd does scheduling isn't kernel-tracing the best solution? I know gpuvis is not the only attempt to use tracepoints for the same purpose. (there're trace.pl and S.E.A. and of course VTune though it probably is not considered to be existing as it's not open source). And assuming this movement towards GuC is it not too late to invent a completely new way to provide tools with scheduling info from kmd? Could we just improve the existing way and let it live its last years\months? Hi, You actually mentioned the prime reason why we should not go and hastily make tracepoints a stable uAPI with regards to scheduling information. The scheduler's nature will be evolving when some of the scheduling decisions are moved to GuC and the way how we get the information will be changing at that point, so tracepoints will indeed be a very bad mechanism for providing the information. The kernel scheduler is definitely not going anywhere with the introduction of more hardware scheduling capabilities, so it is a misconception to think that the interface would need to be completely different for when GuC is enabled. On the last paragraph - even with the today's GuC i915 already loses visibility of CSB interrupts. So there is already a big difference in semantics of what request_in and request_out tracepoints mean. Put preemption into the picture and we just don't know any more when something started executing on the GPU, when it got preempted, re-submitted etc. So I think it is fair to say that moving more of scheduling into the GuC creates a problem for tools which want to represent request execution timelines. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Simplify condition to keep DMC active during S0ix
== Series Details == Series: drm/i915: Simplify condition to keep DMC active during S0ix URL : https://patchwork.freedesktop.org/series/48556/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4695_full -> Patchwork_9989_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9989_full that come from known issues: === IGT changes === Issues hit igt@gem_ctx_isolation@vcs1-s3: shard-kbl: PASS -> INCOMPLETE (fdo#103665) Possible fixes igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363) -> PASS fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4695 -> Patchwork_9989 CI_DRM_4695: f352837700ec39dbaf00cdf727650851993d754b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9989: 2c35976d2b8127d127729694fe0295a61ee2d685 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9989/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Keep physical cursors pinned while in use
On Fri, Aug 17, 2018 at 09:24:05AM +0100, Chris Wilson wrote:
> The optimisation inherent in commit 6a2c4232ece1 ("drm/i915: Make the
> physical object coherent with GTT") relies on that once we allocated a
> cursor we would have coherent, zero overhead access to the scanout plane
> holding the cursor. That is we could then do the very frequent cursor
> updates X enjoys with no indirection or kernel involvement. However,
> that all hinges on the GGTT mmap of the cursor being pinned and not
> require refaulting on each access -- handling such a page fault likely
> requires the busy GGTT to be rearranged causing a stall. A very simple
> fix is then to handle the physical cursor exactly like other cursors and
> keep its vma pinned while active.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107600
I guess this wasn't the thing we wanted. But seems quite harmless to
me anyway, so
Reviewed-by: Ville Syrjälä
in case you still want to land it.
> References: 6a2c4232ece1 ("drm/i915: Make the physical object coherent with
> GTT")
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 592b847db88e..d47ec9fd4af4 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12966,8 +12966,11 @@ static int intel_plane_pin_fb(struct
> intel_plane_state *plane_state)
> INTEL_INFO(dev_priv)->cursor_needs_physical) {
> struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> const int align = intel_cursor_alignment(dev_priv);
> + int err;
>
> - return i915_gem_object_attach_phys(obj, align);
> + err = i915_gem_object_attach_phys(obj, align);
> + if (err)
> + return err;
> }
>
> vma = intel_pin_and_fence_fb_obj(fb,
> --
> 2.18.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Simplify condition to keep DMC active during S0ix
On Wed, Aug 22, 2018 at 02:26:02PM +0300, Imre Deak wrote:
> For S0ix we want to deinit power domains (and so deactivate the DMC
> firmware) exactly when the platform supports the DC9 state. To reach
> S0ix we need DC9 on these platforms (for which the DMC FW needs to be
> deactivated) while to reach S0ix on the rest of the DMC platforms we
> need DC6 (which needs the DMC FW to stay active).
>
> Simplify the condition accordingly so it will be automatically
> correct for upcoming DC9 platforms like ICL.
>
> Cc: Lucas De Marchi
> Cc: Michel Thierry
> Cc: Ville Syrjälä
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Cc: Chris Wilson
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index ff3fd8dbd2b4..1b10b7041513 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -3848,13 +3848,14 @@ void intel_power_domains_suspend(struct
> drm_i915_private *dev_priv,
> intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
>
> /*
> - * In case of firmware assisted context save/restore don't manually
> - * deinit the power domains. This also means the CSR/DMC firmware will
> - * stay active, it will power down any HW resources as required and
> - * also enable deeper system power states that would be blocked if the
> - * firmware was inactive.
> + * In case of suspend-to-idle (aka S0ix) on a DMC platform without DC9
> + * support don't manually deinit the power domains. This also means the
> + * CSR/DMC firmware will stay active, it will power down any HW
> + * resources as required and also enable deeper system power states
> + * that would be blocked if the firmware was inactive.
>*/
> - if (!IS_GEN9_LP(dev_priv) && suspend_mode == I915_DRM_SUSPEND_IDLE &&
> + if (!(dev_priv->csr.allowed_dc_mask & DC_STATE_EN_DC9) &&
> + suspend_mode == I915_DRM_SUSPEND_IDLE &&
> dev_priv->csr.dmc_payload != NULL) {
> intel_power_domains_verify_state(dev_priv);
> return;
> --
> 2.13.2
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Simplify condition to keep DMC active during S0ix
== Series Details ==
Series: drm/i915: Simplify condition to keep DMC active during S0ix
URL : https://patchwork.freedesktop.org/series/48556/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4695 -> Patchwork_9989 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48556/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9989:
=== IGT changes ===
Possible regressions
{igt@pm_rpm@module-reload}:
fi-byt-j1900: NOTRUN -> DMESG-WARN
Warnings
igt@drv_selftest@live_guc:
{fi-bdw-samus}: SKIP -> PASS +1
{igt@pm_rpm@module-reload}:
fi-hsw-4770r: PASS -> SKIP
== Known issues ==
Here are the changes found in Patchwork_9989 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_module_reload@basic-reload-inject:
fi-hsw-4770r: PASS -> DMESG-WARN (fdo#107425)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
{fi-byt-clapper}: PASS -> FAIL (fdo#103191, fdo#107362)
{igt@kms_psr@primary_page_flip}:
{fi-icl-u}: NOTRUN -> FAIL (fdo#107383) +3
Possible fixes
igt@drv_selftest@live_hangcheck:
{fi-bdw-samus}: DMESG-FAIL (fdo#106560) -> PASS
{fi-cfl-8109u}: DMESG-FAIL (fdo#106560) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107383 https://bugs.freedesktop.org/show_bug.cgi?id=107383
fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425
== Participating hosts (52 -> 49) ==
Additional (2): fi-byt-j1900 fi-icl-u
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4695 -> Patchwork_9989
CI_DRM_4695: f352837700ec39dbaf00cdf727650851993d754b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9989: 2c35976d2b8127d127729694fe0295a61ee2d685 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2c35976d2b81 drm/i915: Simplify condition to keep DMC active during S0ix
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9989/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] RFC: Migration to Gitlab
Hi all, I think it's time to brainstorm a bit about the gitlab migration. Basic reasons: - fd.o admins want to deprecate shell accounts and hand-rolled infrastructure, because it's a pain to keep secure - gitlab will allow us to add committers on our own, greatly simplifying that process (and offloading that task from fd.o admins). There's also some more benefits we might want to reap, like better CI integration for basic build testing - no more "oops didn't build drm-misc defconfigs" or "sry, forgot make check in maintainer-tools". But that's all fully optional. For the full in-depth writeup of everything, see https://www.fooishbar.org/blog/gitlab-fdo-introduction/ I think now is also a good time, with mesa, xorg, wayland/weston and others moved, to start thinking about how we'll move drm. There's a few things to figure out though: - We probably want to split out maintainer-tools. That would address the concern that there's 50+ committers to an auto-updating shell script ... - We need to figure out how to handle the ACL trickery around drm-tip in gitlab. - Probably good to stage the migration, with maintainer-tools, igt leading. That will also make fd.o admins happy, who want to rework their cloud infrastructure a bit before migrating the big kernel repos over. - Figuring out the actual migration - we've been adding a pile of committers since fd.o LDAP was converted to gitlab once back in spring. We need to at least figure out how to move the new accounts/committers. - Similar, maintainer-tools needs to move. We probably want to move all the dim maintained kernel repos in one go, to avoid headaches with double-accounts needed for committers. - CI, linux-next and everyone else should be fine, since the cgit/non-ssh paths will keep working (they'll be read-only mirrors). Need to double-check that with everyone. - Some organization structure would be good. https://cgit.freedesktop.org/drm libdrm won't be part of the gitlab drm group because that's already moved under mesa (and you can't symlink/mulit-home anymore on gitlab): https://gitlab.freedesktop.org/mesa/drm But there's also drm_hwcomposer, which we might want to migrate into drm too - gitlab requires a containing group, and drm_hwcomposer/drm_hwcomposer is a bit silly. Note: Access rights can be done at any level in the hierarchy, the organization is orthogonal to commit rights. - Anything else I've forgotten. A lot of this still needs to be figured out first. As a first step I'm looking for volunteers who want to join the fun, besides comments and thoughts on the overall topic of course. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Simplify condition to keep DMC active during S0ix
For S0ix we want to deinit power domains (and so deactivate the DMC
firmware) exactly when the platform supports the DC9 state. To reach
S0ix we need DC9 on these platforms (for which the DMC FW needs to be
deactivated) while to reach S0ix on the rest of the DMC platforms we
need DC6 (which needs the DMC FW to stay active).
Simplify the condition accordingly so it will be automatically
correct for upcoming DC9 platforms like ICL.
Cc: Lucas De Marchi
Cc: Michel Thierry
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Cc: Chris Wilson
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index ff3fd8dbd2b4..1b10b7041513 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -3848,13 +3848,14 @@ void intel_power_domains_suspend(struct
drm_i915_private *dev_priv,
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
/*
-* In case of firmware assisted context save/restore don't manually
-* deinit the power domains. This also means the CSR/DMC firmware will
-* stay active, it will power down any HW resources as required and
-* also enable deeper system power states that would be blocked if the
-* firmware was inactive.
+* In case of suspend-to-idle (aka S0ix) on a DMC platform without DC9
+* support don't manually deinit the power domains. This also means the
+* CSR/DMC firmware will stay active, it will power down any HW
+* resources as required and also enable deeper system power states
+* that would be blocked if the firmware was inactive.
*/
- if (!IS_GEN9_LP(dev_priv) && suspend_mode == I915_DRM_SUSPEND_IDLE &&
+ if (!(dev_priv->csr.allowed_dc_mask & DC_STATE_EN_DC9) &&
+ suspend_mode == I915_DRM_SUSPEND_IDLE &&
dev_priv->csr.dmc_payload != NULL) {
intel_power_domains_verify_state(dev_priv);
return;
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/syncobj: Drop add/remove_callback from driver interface
== Series Details ==
Series: drm/syncobj: Drop add/remove_callback from driver interface
URL : https://patchwork.freedesktop.org/series/48542/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4695_full -> Patchwork_9988_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_9988_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_9988_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
== Possible new issues ==
Here are the unknown changes that may have been introduced in
Patchwork_9988_full:
=== IGT changes ===
Warnings
igt@gem_ctx_param@root-set-no-zeromap-disabled:
shard-kbl: PASS -> ( 2 PASS ) +541
igt@gem_exec_big:
shard-apl: SKIP -> ( 2 SKIP ) +197
igt@gem_mocs_settings@mocs-reset-bsd2:
shard-snb: SKIP -> ( 2 SKIP ) +343
igt@gem_pread@stolen-uncached:
shard-kbl: SKIP -> ( 2 SKIP ) +207
igt@gem_pwrite@small-cpu-random:
shard-hsw: PASS -> ( 2 PASS ) +452
igt@kms_concurrent@pipe-d:
shard-hsw: SKIP -> ( 2 SKIP ) +239
igt@kms_frontbuffer_tracking@psr-rgb101010-draw-pwrite:
shard-glk: SKIP -> ( 2 SKIP ) +173
igt@kms_plane@plane-panning-bottom-right-pipe-a-planes:
shard-glk: PASS -> ( 2 PASS ) +440
igt@kms_rotation_crc@sprite-rotation-90-pos-100-0:
shard-apl: PASS -> ( 2 PASS ) +416
igt@syncobj_wait@invalid-wait-bad-flags:
shard-snb: PASS -> ( 2 PASS ) +348
== Known issues ==
Here are the changes found in Patchwork_9988_full that come from known issues:
=== IGT changes ===
Issues hit
igt@gem_ctx_isolation@vcs1-s3:
shard-kbl: PASS -> ( 2 INCOMPLETE ) (fdo#103665)
igt@kms_setmode@basic:
shard-apl: PASS -> FAIL (fdo#99912)
Possible fixes
igt@gem_ppgtt@blt-vs-render-ctx0:
shard-kbl: INCOMPLETE (fdo#103665, fdo#106023) -> PASS
Warnings
igt@gem_exec_schedule@pi-ringfull-bsd1:
shard-kbl: FAIL (fdo#103158) -> ( 2 FAIL ) (fdo#103158) +1
igt@gem_exec_schedule@pi-ringfull-render:
shard-apl: FAIL (fdo#103158) -> ( 2 FAIL ) (fdo#103158)
igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
shard-apl: FAIL (fdo#105458, fdo#106510) -> ( 2 FAIL )
(fdo#105458, fdo#106510)
igt@kms_flip@flip-vs-expired-vblank:
shard-glk: FAIL (fdo#105363) -> ( 1 FAIL, 1 PASS ) (fdo#102887,
fdo#105363)
igt@kms_rotation_crc@primary-rotation-180:
shard-snb: FAIL (fdo#103925) -> ( 2 FAIL ) (fdo#103925)
igt@kms_setmode@basic:
shard-kbl: FAIL (fdo#99912) -> ( 2 FAIL ) (fdo#99912)
igt@kms_sysfs_edid_timing:
shard-hsw: WARN (fdo#100047) -> ( 2 WARN ) (fdo#100047)
shard-glk: WARN (fdo#100047) -> ( 2 WARN ) (fdo#100047)
shard-kbl: FAIL (fdo#100047) -> ( 2 FAIL ) (fdo#100047)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
fdo#105458 https://bugs.freedesktop.org/show_bug.cgi?id=105458
fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
fdo#106510 https://bugs.freedesktop.org/show_bug.cgi?id=106510
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
== Participating hosts (5 -> 5) ==
No changes in participating hosts
== Build changes ==
* Linux: CI_DRM_4695 -> Patchwork_9988
CI_DRM_4695: f352837700ec39dbaf00cdf727650851993d754b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4608: 94ebd21177feedf03e8f6dd1e73dca1a6ec7a0ac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9988: 573052f7cbf140741e3689c403484e3182fe9f94 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9988/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
