[Intel-gfx] [PATCH] drm/i915: Adding YUV444 packed format support for skl+
From: Stanislav Lisovskiy
PLANE_CTL_FORMAT_AYUV is already supported, according to hardware specification.
v2: Edited commit message, removed redundant whitespaces.
v3: Fixed fallthrough logic for the format switch cases.
v4: Yet again fixed fallthrough logic, to reuse code from other case
labels.
v5: Started to use XYUV instead of AYUV, as we don't use alpha.
v6: Removed unneeded initializer for new XYUV format.
v7: Added scaling support for DRM_FORMAT_XYUV
v8: Edited commit message to be more clear about skl+, renamed
PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this format
doesn't support per-pixel alpha. Fixed minor code issues.
v9: Moved DRM format check to proper place in intel_framebuffer_init.
v10: Added missing XYUV format to sprite planes for skl+.
v11: Changed DRM_FORMAT_XYUV to be DRM_FORMAT_XYUV.
v12: Fixed rebase conflicts
V13: Rebased.
v12:
Reviewed-by: Ville Syrjälä
Signed-off-by: Stanislav Lisovskiy
Signed-off-by: Bob Paauwe
---
drivers/gpu/drm/i915/display/intel_display.c | 5 +
drivers/gpu/drm/i915/display/intel_sprite.c | 3 +++
drivers/gpu/drm/i915/i915_reg.h | 2 +-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 12bb8f951edf..7b9fb9e7893d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2978,6 +2978,8 @@ int skl_format_to_fourcc(int format, bool rgb_order, bool
alpha)
return DRM_FORMAT_RGB565;
case PLANE_CTL_FORMAT_NV12:
return DRM_FORMAT_NV12;
+ case PLANE_CTL_FORMAT_XYUV:
+ return DRM_FORMAT_XYUV;
case PLANE_CTL_FORMAT_P010:
return DRM_FORMAT_P010;
case PLANE_CTL_FORMAT_P012:
@@ -3988,6 +3990,8 @@ static u32 skl_plane_ctl_format(u32 pixel_format)
case DRM_FORMAT_XRGB16161616F:
case DRM_FORMAT_ARGB16161616F:
return PLANE_CTL_FORMAT_XRGB_16161616F;
+ case DRM_FORMAT_XYUV:
+ return PLANE_CTL_FORMAT_XYUV;
case DRM_FORMAT_YUYV:
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_YUYV;
case DRM_FORMAT_YVYU:
@@ -5581,6 +5585,7 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_XYUV:
case DRM_FORMAT_P010:
case DRM_FORMAT_P012:
case DRM_FORMAT_P016:
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 7a7078d0ba23..b30809b28e17 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -2015,6 +2015,7 @@ static const u32 skl_plane_formats[] = {
DRM_FORMAT_YVYU,
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
+ DRM_FORMAT_XYUV,
};
static const u32 skl_planar_formats[] = {
@@ -2031,6 +2032,7 @@ static const u32 skl_planar_formats[] = {
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
DRM_FORMAT_NV12,
+ DRM_FORMAT_XYUV,
};
static const u32 glk_planar_formats[] = {
@@ -2273,6 +2275,7 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_XYUV:
case DRM_FORMAT_P010:
case DRM_FORMAT_P012:
case DRM_FORMAT_P016:
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bf37ecebc82f..20cdffc23a95 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6656,7 +6656,7 @@ enum {
#define PLANE_CTL_FORMAT_P012(5 << 24)
#define PLANE_CTL_FORMAT_XRGB_16161616F (6 << 24)
#define PLANE_CTL_FORMAT_P016(7 << 24)
-#define PLANE_CTL_FORMAT_AYUV(8 << 24)
+#define PLANE_CTL_FORMAT_XYUV(8 << 24)
#define PLANE_CTL_FORMAT_INDEXED (12 << 24)
#define PLANE_CTL_FORMAT_RGB_565 (14 << 24)
#define ICL_PLANE_CTL_FORMAT_MASK(0x1f << 23)
--
2.21.0
___
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: Show the logical context ring state on dumping
On Sun, 2019-09-15 at 21:37 +0100, Chris Wilson wrote:
> Include the active context register state when dumping the engine.
>
> Suggested-by: Mika Kuoppala
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Stuart Summers
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index a8014c59b388..3c176b0f4b45 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1404,6 +1404,11 @@ void intel_engine_dump(struct intel_engine_cs
> *engine,
> rq->timeline->hwsp_offset);
>
> print_request_ring(m, rq);
> +
> + if (rq->hw_context->lrc_reg_state) {
> + drm_printf(m, "Logical Ring Context:\n");
> + hexdump(m, rq->hw_context->lrc_reg_state,
> PAGE_SIZE);
> + }
> }
> spin_unlock_irqrestore(>active.lock, flags);
>
smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND] drm/i915: stop conflating HAS_DISPLAY() and disabled display
On Mon, 16 Sep 2019, Chris Wilson wrote:
> Quoting Jani Nikula (2019-09-16 10:29:01)
>> Stop setting ->pipe_mask to zero when display is disabled, allowing us
>> to have different code paths for not actually having display hardware,
>> and having display hardware disabled. This lets us develop those two
>> avenues independently.
>>
>> There are no functional changes for when there is no display. However,
>> all uses of for_each_pipe() and for_each_pipe_masked() will start
>> running for the disabled display case. Put one of the more significant
>> ones behind checks for INTEL_DISPLAY_ENABLED(), otherwise the cases
>> should not be hit with disabled display, or they seem benign. Fingers
>> crossed.
>>
>> All in all, this might not be the ideal solution. In fact we may have
>> had something along the lines of this in the past, but we ended up
>> conflating the two cases. Possibly even by recommendation by yours
>> truly; I did not dare dig up that part of the history. But the perfect
>> is the enemy of the good, this is a straightforward change, and lets us
>> get actual work done in both fronts without interfering with each other.
>>
>> Cc: Chris Wilson
>> Cc: José Roberto de Souza
>> Cc: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/display/intel_display.c | 12 +++-
>> drivers/gpu/drm/i915/intel_device_info.c | 8 ++--
>> 2 files changed, 9 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index e75945a53e06..ac24f96582ca 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -16281,11 +16281,13 @@ int intel_modeset_init(struct drm_device *dev)
>> INTEL_NUM_PIPES(dev_priv),
>> INTEL_NUM_PIPES(dev_priv) > 1 ? "s" : "");
>>
>> - for_each_pipe(dev_priv, pipe) {
>> - ret = intel_crtc_init(dev_priv, pipe);
>> - if (ret) {
>> - drm_mode_config_cleanup(dev);
>> - return ret;
>> + if (HAS_DISPLAY(dev_priv) && INTEL_DISPLAY_ENABLED(dev_priv)) {
>> + for_each_pipe(dev_priv, pipe) {
>> + ret = intel_crtc_init(dev_priv, pipe);
>
> What direction are you planning to take, avoid enabling anything related
> to display? My worry is that in
>
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/fi-bsw-kefka/igt@i915_selftest@live_gt_timelines.html
>
> we still see weird events like
>
> <7> [444.313823] [drm:i915_redisable_vga_power_on [i915]] Something enabled
> VGA plane, disabling it
>
> and I'm not sure how you intend to curtail that. (Or if that's even
> possible.)
The main goal here (in this specific patch) is to decouple disabled but
existing display from non-existing display. That lets us develop the two
cases independently, and I acknowledge I may have been simple minded
enough at some point to believe they could be put in the same bucket.
This patch tries to do the decoupling with the least amount of
functional changes to the disabled display case (no matter how broken
the status quo is), but also without sprinkling INTEL_DISPLAY_ENABLED()
checks at every for_each_display{,_masked}. Some arbitrarily chosen
balance.
After this, I'm hoping we can develop the cases independently, without
each of them stomping on the other's feet. Who knows, maybe the next
patch should revert the hunk you quote above. I do know I'm not signing
up for fixing everything about the disabled display path, at least right
away, but the point is to remove obstacles.
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] [RESEND] drm/i915: stop conflating HAS_DISPLAY() and disabled display
On Mon, Sep 16, 2019 at 05:05:10PM +0300, Jani Nikula wrote:
> On Mon, 16 Sep 2019, Chris Wilson wrote:
> > Quoting Jani Nikula (2019-09-16 10:29:01)
> >> Stop setting ->pipe_mask to zero when display is disabled, allowing us
> >> to have different code paths for not actually having display hardware,
> >> and having display hardware disabled. This lets us develop those two
> >> avenues independently.
> >>
> >> There are no functional changes for when there is no display. However,
> >> all uses of for_each_pipe() and for_each_pipe_masked() will start
> >> running for the disabled display case. Put one of the more significant
> >> ones behind checks for INTEL_DISPLAY_ENABLED(), otherwise the cases
> >> should not be hit with disabled display, or they seem benign. Fingers
> >> crossed.
> >>
> >> All in all, this might not be the ideal solution. In fact we may have
> >> had something along the lines of this in the past, but we ended up
> >> conflating the two cases. Possibly even by recommendation by yours
> >> truly; I did not dare dig up that part of the history. But the perfect
> >> is the enemy of the good, this is a straightforward change, and lets us
> >> get actual work done in both fronts without interfering with each other.
> >>
> >> Cc: Chris Wilson
> >> Cc: José Roberto de Souza
> >> Cc: Ville Syrjälä
> >> Signed-off-by: Jani Nikula
> >> ---
> >> drivers/gpu/drm/i915/display/intel_display.c | 12 +++-
> >> drivers/gpu/drm/i915/intel_device_info.c | 8 ++--
> >> 2 files changed, 9 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> >> b/drivers/gpu/drm/i915/display/intel_display.c
> >> index e75945a53e06..ac24f96582ca 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >> @@ -16281,11 +16281,13 @@ int intel_modeset_init(struct drm_device *dev)
> >> INTEL_NUM_PIPES(dev_priv),
> >> INTEL_NUM_PIPES(dev_priv) > 1 ? "s" : "");
> >>
> >> - for_each_pipe(dev_priv, pipe) {
> >> - ret = intel_crtc_init(dev_priv, pipe);
> >> - if (ret) {
> >> - drm_mode_config_cleanup(dev);
> >> - return ret;
> >> + if (HAS_DISPLAY(dev_priv) && INTEL_DISPLAY_ENABLED(dev_priv)) {
> >> + for_each_pipe(dev_priv, pipe) {
> >> + ret = intel_crtc_init(dev_priv, pipe);
> >
> > What direction are you planning to take, avoid enabling anything related
> > to display? My worry is that in
> >
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/fi-bsw-kefka/igt@i915_selftest@live_gt_timelines.html
> >
> > we still see weird events like
> >
> > <7> [444.313823] [drm:i915_redisable_vga_power_on [i915]] Something enabled
> > VGA plane, disabling it
> >
> > and I'm not sure how you intend to curtail that. (Or if that's even
> > possible.)
>
> The main goal here (in this specific patch) is to decouple disabled but
> existing display from non-existing display. That lets us develop the two
> cases independently, and I acknowledge I may have been simple minded
> enough at some point to believe they could be put in the same bucket.
What's the actual use case for the "disabled but existing display"?
So far I've thought that the only use case is regression testing
of the "hw has no display" case on hw which in fact has a display.
If we have separate codepaths we can't do that effectively. At
which point we might as well get rid of the "disable display"
capability entirely.
But maybe I'm missing something...
--
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 1/4] dma-buf: change DMA-buf locking convention
Ping? Any further comment on this or can't we merge at least the locking
change?
Christian.
Am 11.09.19 um 12:53 schrieb Christian König:
Am 03.09.19 um 10:05 schrieb Daniel Vetter:
On Thu, Aug 29, 2019 at 04:29:14PM +0200, Christian König wrote:
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
For compatibility we cache the DMA-buf mapping as soon as
exporter/importer disagree on the dynamic handling.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 90
---
include/linux/dma-buf.h | 51 +-
2 files changed, 133 insertions(+), 8 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 433d91d710e4..65052d52602b 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -525,6 +525,10 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
+ if (WARN_ON(exp_info->ops->cache_sgt_mapping &&
+ exp_info->ops->dynamic_mapping))
+ return ERR_PTR(-EINVAL);
+
if (!try_module_get(exp_info->owner))
return ERR_PTR(-ENOENT);
@@ -645,10 +649,11 @@ void dma_buf_put(struct dma_buf *dmabuf)
EXPORT_SYMBOL_GPL(dma_buf_put);
/**
- * dma_buf_attach - Add the device to dma_buf's attachments list;
optionally,
+ * dma_buf_dynamic_attach - Add the device to dma_buf's attachments
list; optionally,
* calls attach() of dma_buf_ops to allow device-specific attach
functionality
- * @dmabuf: [in] buffer to attach device to.
- * @dev: [in] device to be attached.
+ * @dmabuf: [in] buffer to attach device to.
+ * @dev: [in] device to be attached.
+ * @dynamic_mapping: [in] calling convention for map/unmap
*
* Returns struct dma_buf_attachment pointer for this attachment.
Attachments
* must be cleaned up by calling dma_buf_detach().
@@ -662,8 +667,9 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* accessible to @dev, and cannot be moved to a more suitable
place. This is
* indicated with the error code -EBUSY.
*/
-struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
+struct dma_buf_attachment *
+dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
+ bool dynamic_mapping)
{
struct dma_buf_attachment *attach;
int ret;
@@ -677,6 +683,7 @@ struct dma_buf_attachment *dma_buf_attach(struct
dma_buf *dmabuf,
attach->dev = dev;
attach->dmabuf = dmabuf;
+ attach->dynamic_mapping = dynamic_mapping;
mutex_lock(>lock);
@@ -685,16 +692,64 @@ struct dma_buf_attachment
*dma_buf_attach(struct dma_buf *dmabuf,
if (ret)
goto err_attach;
}
+ dma_resv_lock(dmabuf->resv, NULL);
list_add(>node, >attachments);
+ dma_resv_unlock(dmabuf->resv);
mutex_unlock(>lock);
+ /* When either the importer or the exporter can't handle dynamic
+ * mappings we cache the mapping here to avoid issues with the
+ * reservation object lock.
+ */
+ if (dma_buf_attachment_is_dynamic(attach) !=
+ dma_buf_is_dynamic(dmabuf)) {
+ struct sg_table *sgt;
+
+ if (dma_buf_is_dynamic(attach->dmabuf))
+ dma_resv_lock(attach->dmabuf->resv, NULL);
+
+ sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
Now we're back to enforcing DMA_BIDI, which works nicely around the
locking pain, but apparently upsets the arm-soc folks who want to
control
this better.
Take another look at dma_buf_map_attachment(), we still try to get the
caching there for ARM.
What we do here is to bidirectionally map the buffer to avoid the
locking hydra when importer and exporter disagree on locking.
So the ARM folks can easily avoid that by switching to dynamic locking
for both.
Regards,
Christian.
That's why your previous version moved the caching into
map/unmap_sg, which resurrected the locking hydra.
I think we're going a bit in circles here, and I don't have a good idea
either :-/
-Daniel
+ if (!sgt)
+ sgt = ERR_PTR(-ENOMEM);
+ if (IS_ERR(sgt)) {
+ ret = PTR_ERR(sgt);
+ goto err_unlock;
+ }
+ if (dma_buf_is_dynamic(attach->dmabuf))
+ dma_resv_unlock(attach->dmabuf->resv);
+ attach->sgt = sgt;
+ attach->dir = DMA_BIDIRECTIONAL;
+ }
+
return attach;
err_attach:
kfree(attach);
mutex_unlock(>lock);
return ERR_PTR(ret);
+
+err_unlock:
+ if (dma_buf_is_dynamic(attach->dmabuf))
+ dma_resv_unlock(attach->dmabuf->resv);
+
+ dma_buf_detach(dmabuf, attach);
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(dma_buf_dynamic_attach);
+
+/**
+ * dma_buf_attach - Wrapper for dma_buf_dynamic_attach
+ * @dmabuf: [in] buffer to attach device to.
+ * @dev: [in] device to be attached.
+ *
+ *
Re: [Intel-gfx] [PATCH AUTOSEL 5.2 13/23] drm/i915/userptr: Acquire the page lock around set_page_dirty()
Den 03-09-2019 kl. 19:24, skrev Sasha Levin:
From: Chris Wilson
[ Upstream commit aa56a292ce623734ddd30f52d73f527d1f3529b5 ]
set_page_dirty says:
For pages with a mapping this should be done under the page lock
for the benefit of asynchronous memory errors who prefer a
consistent dirty state. This rule can be broken in some special
cases, but should be better not to.
Under those rules, it is only safe for us to use the plain set_page_dirty
calls for shmemfs/anonymous memory. Userptr may be used with real
mappings and so needs to use the locked version (set_page_dirty_lock).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317
Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory
(userptr) ioctl")
References: 6dcc693bc57f ("ext4: warn when page is dirtied without buffers")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: sta...@vger.kernel.org
Reviewed-by: Tvrtko Ursulin
Link:
https://patchwork.freedesktop.org/patch/msgid/20190708140327.26825-1-ch...@chris-wilson.co.uk
(cherry picked from commit cb6d7c7dc7ff8cace666ddec66334117a6068ce2)
Signed-off-by: Jani Nikula
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 8079ea3af1039..b1fc15c7f5997 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -678,7 +678,15 @@ i915_gem_userptr_put_pages(struct drm_i915_gem_object *obj,
for_each_sgt_page(page, sgt_iter, pages) {
if (obj->mm.dirty)
- set_page_dirty(page);
+ /*
+* As this may not be anonymous memory (e.g. shmem)
+* but exist on a real mapping, we have to lock
+* the page in order to dirty it -- holding
+* the page reference is not sufficient to
+* prevent the inode from being truncated.
+* Play safe and take the lock.
+*/
+ set_page_dirty_lock(page);
mark_page_accessed(page);
put_page(page);
Please drop this one from all 5.2 and 4.19 stable queues
It has now been reverted in Linus tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=505a8ec7e11ae5236c4a154a1e24ef49a8349600
--
Thomas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND] drm/i915: stop conflating HAS_DISPLAY() and disabled display
Quoting Jani Nikula (2019-09-16 10:29:01) > Stop setting ->pipe_mask to zero when display is disabled, allowing us > to have different code paths for not actually having display hardware, > and having display hardware disabled. This lets us develop those two > avenues independently. > > There are no functional changes for when there is no display. However, > all uses of for_each_pipe() and for_each_pipe_masked() will start > running for the disabled display case. Put one of the more significant > ones behind checks for INTEL_DISPLAY_ENABLED(), otherwise the cases > should not be hit with disabled display, or they seem benign. Fingers > crossed. > > All in all, this might not be the ideal solution. In fact we may have > had something along the lines of this in the past, but we ended up > conflating the two cases. Possibly even by recommendation by yours > truly; I did not dare dig up that part of the history. But the perfect > is the enemy of the good, this is a straightforward change, and lets us > get actual work done in both fronts without interfering with each other. > > Cc: Chris Wilson > Cc: José Roberto de Souza > Cc: Ville Syrjälä > Signed-off-by: Jani Nikula It doesn't fall over, which is impressive enough. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND] drm/i915: stop conflating HAS_DISPLAY() and disabled display
Quoting Ville Syrjälä (2019-09-16 15:27:40) > On Mon, Sep 16, 2019 at 05:05:10PM +0300, Jani Nikula wrote: > > The main goal here (in this specific patch) is to decouple disabled but > > existing display from non-existing display. That lets us develop the two > > cases independently, and I acknowledge I may have been simple minded > > enough at some point to believe they could be put in the same bucket. > > What's the actual use case for the "disabled but existing display"? There are 2 reasons why I have it enabled for the live gem selftests. Not setting up the display makes module reload faster, and the other reason is that I hoped to avoid any spurious interactions (random hotplug events) in the middle of the stress tests. The latter usecase I would suggest applies to headless servers, where we want to minimise random events. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 07/10] drm/i915/dsb: function to trigger workload execution of DSB.
On Thu, 12 Sep 2019, "Sharma, Shashank" wrote:
> On 9/12/2019 7:09 PM, Jani Nikula wrote:
>> On Thu, 12 Sep 2019, "Sharma, Shashank" wrote:
>>> On 9/12/2019 12:41 AM, Animesh Manna wrote:
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commit function will trigger the execution of the batch buffer. All
the registers will be updated simultaneously.
v1: Initial version.
v2: Optimized code few places. (Chris)
v3: USed DRM_ERROR for dsb head/tail programming failure. (Shashank)
Cc: Imre Deak
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dsb.c | 42
drivers/gpu/drm/i915/display/intel_dsb.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 2 ++
3 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 2b0ffc0afb74..eea86afb0583 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -212,3 +212,45 @@ void intel_dsb_reg_write(struct intel_dsb *dsb,
i915_reg_t reg, u32 val)
(DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
i915_mmio_reg_offset(reg);
}
+
+void intel_dsb_commit(struct intel_dsb *dsb)
+{
+ struct intel_crtc *crtc = container_of(dsb, typeof(*crtc), dsb);
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ enum pipe pipe = crtc->pipe;
+ u32 tail;
+
+ if (!dsb->free_pos)
+ return;
+
+ if (!intel_dsb_enable_engine(dsb))
+ goto reset;
+
+ if (is_dsb_busy(dsb)) {
+ DRM_ERROR("HEAD_PTR write failed - dsb engine is busy.\n");
+ goto reset;
+ }
+ I915_WRITE(DSB_HEAD(pipe, dsb->id), i915_ggtt_offset(dsb->vma));
+
+ tail = ALIGN(dsb->free_pos * 4, CACHELINE_BYTES);
+ if (tail > dsb->free_pos * 4)
+ memset(>cmd_buf[dsb->free_pos], 0,
+ (tail - dsb->free_pos * 4));
+
+ if (is_dsb_busy(dsb)) {
+ DRM_ERROR("TAIL_PTR write failed - dsb engine is busy.\n");
+ goto reset;
+ }
+ DRM_DEBUG_KMS("DSB execution started - head 0x%x, tail 0x%x\n",
+i915_ggtt_offset(dsb->vma), tail);
+ I915_WRITE(DSB_TAIL(pipe, dsb->id), i915_ggtt_offset(dsb->vma) + tail);
+ if (wait_for(!is_dsb_busy(dsb), 1)) {
+ DRM_ERROR("Timed out waiting for DSB workload completion.\n");
+ goto reset;
+ }
+
+reset:
+ dsb->free_pos = 0;
+ intel_dsb_disable_engine(dsb);
>>> I am still not very convince if a commit function should be void, I
>>> would still want it to return success or failure, so that we would know
>>> if the last operation was successful or not.
>>>
>>> I would wait Jani N to comment here, on what he feels about this.
>> The question becomes, what do you *do* with the return value? If none of
>> the callers are going to use it, don't return it.
>
> I was thinking we should check the return value of the DSB commit (if
> not writes), so that we would be aware that the register programming
> failed, and later even can think about a fallback method. Too ambitious ?
Easy to add later if needed, I think.
BR,
Jani.
>
> - Shashank
>
>> BR,
>> Jani.
>>
>>> - Shashank
>>>
+}
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
b/drivers/gpu/drm/i915/display/intel_dsb.h
index 9b2522f20bfb..7389c8c5b665 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.h
+++ b/drivers/gpu/drm/i915/display/intel_dsb.h
@@ -43,5 +43,6 @@ void intel_dsb_put(struct intel_dsb *dsb);
void intel_dsb_reg_write(struct intel_dsb *dsb, i915_reg_t reg, u32
val);
void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t reg,
u32 val);
+void intel_dsb_commit(struct intel_dsb *dsb);
#endif
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 2dbaa49f5c74..c77b5066d8dd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11687,6 +11687,8 @@ enum skl_power_gate {
#define _DSBSL_INSTANCE_BASE0x70B00
#define DSBSL_INSTANCE(pipe, id)(_DSBSL_INSTANCE_BASE + \
(pipe) * 0x1000 + (id) * 100)
+#define DSB_HEAD(pipe, id)_MMIO(DSBSL_INSTANCE(pipe, id)
+ 0x0)
+#define DSB_TAIL(pipe, id)_MMIO(DSBSL_INSTANCE(pipe, id)
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
On Mon, Sep 16, 2019 at 07:34:32PM +, Souza, Jose wrote: > Someone with drm-misc commit access could push this? > Sure will push this series. Manasi > Thanks > > On Sun, 2019-09-15 at 11:36 +, Patchwork wrote: > > == Series Details == > > > > Series: series starting with [CI,1/2] drm/connector: Share with non- > > atomic drivers the function to get the single encoder > > URL : https://patchwork.freedesktop.org/series/66701/ > > State : success > > > > == Summary == > > > > CI Bug Log - changes from CI_DRM_6894_full -> Patchwork_14412_full > > > > > > Summary > > --- > > > > **SUCCESS** > > > > No regressions found. > > > > > > > > Known issues > > > > > > Here are the changes found in Patchwork_14412_full that come from > > known issues: > > > > ### IGT changes ### > > > > Issues hit > > > > * igt@gem_exec_schedule@preempt-contexts-bsd2: > > - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) +14 > > similar issues > >[1]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb1/igt@gem_exec_sched...@preempt-contexts-bsd2.html > >[2]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb7/igt@gem_exec_sched...@preempt-contexts-bsd2.html > > > > * igt@gem_exec_schedule@preemptive-hang-bsd: > > - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +3 > > similar issues > >[3]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb6/igt@gem_exec_sched...@preemptive-hang-bsd.html > >[4]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html > > > > * igt@i915_pm_rpm@modeset-stress-extra-wait: > > - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([fdo#105763] > > / [fdo#106538]) > >[5]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk7/igt@i915_pm_...@modeset-stress-extra-wait.html > >[6]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk8/igt@i915_pm_...@modeset-stress-extra-wait.html > > > > * igt@i915_suspend@fence-restore-tiled2untiled: > > - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) > > +3 similar issues > >[7]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html > >[8]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html > > > > * igt@kms_cursor_crc@pipe-b-cursor-alpha-transparent: > > - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) > >[9]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-snb5/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > >[10]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-snb7/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > > > > * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: > > - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) > >[11]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > >[12]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > > > > * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: > > - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#105363]) > >[13]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > >[14]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > > > > * igt@kms_flip@basic-flip-vs-modeset: > > - shard-apl: [PASS][15] -> [INCOMPLETE][16] > > ([fdo#103927]) > >[15]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl7/igt@kms_f...@basic-flip-vs-modeset.html > >[16]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl3/igt@kms_f...@basic-flip-vs-modeset.html > > > > * igt@kms_flip@flip-vs-expired-vblank-interruptible: > > - shard-apl: [PASS][17] -> [FAIL][18] ([fdo#105363]) > >[17]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html > >[18]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html > > > > * igt@kms > > _frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite: > > - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +7 > > similar issues > >[19]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html > >[20]: > >
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Suspend pre-parser across GTT invalidations
On 9/16/19 1:54 PM, Chris Wilson wrote: Quoting Daniele Ceraolo Spurio (2019-09-16 21:37:26) On 9/14/19 1:25 AM, Chris Wilson wrote: Before we execute a batch, we must first issue any and all TLB invalidations so that batch picks up the new page table entries. Tigerlake's preparser is weakening our post-sync CS_STALL inside the invalidate pipe-control and allowing the loading of the batch buffer before we have setup its page table (and so it loads the wrong page and executes indefinitely). Signed-off-by: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Mika Kuoppala --- Suggestions welcome as this does not seem intended behaviour, so I suspect there is a strong pipecontrol flag we are missing. When I discussed the pre-parser with the HW team the feedback I got was that the only way to make sure we don't race the memory update is to either leave enough CL of space or turn the parser off like you did below. That discussion was about actual physical memory access though and not TLB. Anyway, turning off the parser around the pipe control, if it fixes the problem, shouldn't be too bad since the main performance advantage of the parser is expected inside the user batch. The alternative would probably be to stop invalidating the TLBs from within the ring and switch to MMIO invalidations when lite-restoring a new request in the ring (the CS will implicitly stop the parser and invalidate everything on a full ctx switch). I also only observe the effect on rcs0 atm. Does that tie in with the preparser theory? i.e. that either the MI_FLUSH_DW is a strong barrier or the preparser is rcs0 only. (Strictly speaking I haven't yet run the igt_cs_tlb test on tgl/bcs0 so I am basing the above off the igt test results that pass on bcs0 but consistently failed on rcs0.) -Chris AFAIK the pre-parser is part of the core CS logic, which should be the same on all engines (although the new behavior was mainly required for RCS workloads). The specs also don't mention a different behavior on MI_FLUSH. It might just be a timing thing, since I'd expect the MI_FLUSH to be faster to execute compared to the pipe control and thus less instructions will be accumulated in the pre-fetch FIFO in the meantime, also considering that we have 2 calls close to each other (one from the breadcrumb fini of the previous request). Daniele ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND] drm/i915: stop conflating HAS_DISPLAY() and disabled display
On Mon, 16 Sep 2019, Ville Syrjälä wrote:
> On Mon, Sep 16, 2019 at 05:05:10PM +0300, Jani Nikula wrote:
>> On Mon, 16 Sep 2019, Chris Wilson wrote:
>> > Quoting Jani Nikula (2019-09-16 10:29:01)
>> >> Stop setting ->pipe_mask to zero when display is disabled, allowing us
>> >> to have different code paths for not actually having display hardware,
>> >> and having display hardware disabled. This lets us develop those two
>> >> avenues independently.
>> >>
>> >> There are no functional changes for when there is no display. However,
>> >> all uses of for_each_pipe() and for_each_pipe_masked() will start
>> >> running for the disabled display case. Put one of the more significant
>> >> ones behind checks for INTEL_DISPLAY_ENABLED(), otherwise the cases
>> >> should not be hit with disabled display, or they seem benign. Fingers
>> >> crossed.
>> >>
>> >> All in all, this might not be the ideal solution. In fact we may have
>> >> had something along the lines of this in the past, but we ended up
>> >> conflating the two cases. Possibly even by recommendation by yours
>> >> truly; I did not dare dig up that part of the history. But the perfect
>> >> is the enemy of the good, this is a straightforward change, and lets us
>> >> get actual work done in both fronts without interfering with each other.
>> >>
>> >> Cc: Chris Wilson
>> >> Cc: José Roberto de Souza
>> >> Cc: Ville Syrjälä
>> >> Signed-off-by: Jani Nikula
>> >> ---
>> >> drivers/gpu/drm/i915/display/intel_display.c | 12 +++-
>> >> drivers/gpu/drm/i915/intel_device_info.c | 8 ++--
>> >> 2 files changed, 9 insertions(+), 11 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> >> b/drivers/gpu/drm/i915/display/intel_display.c
>> >> index e75945a53e06..ac24f96582ca 100644
>> >> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> >> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> >> @@ -16281,11 +16281,13 @@ int intel_modeset_init(struct drm_device *dev)
>> >> INTEL_NUM_PIPES(dev_priv),
>> >> INTEL_NUM_PIPES(dev_priv) > 1 ? "s" : "");
>> >>
>> >> - for_each_pipe(dev_priv, pipe) {
>> >> - ret = intel_crtc_init(dev_priv, pipe);
>> >> - if (ret) {
>> >> - drm_mode_config_cleanup(dev);
>> >> - return ret;
>> >> + if (HAS_DISPLAY(dev_priv) && INTEL_DISPLAY_ENABLED(dev_priv)) {
>> >> + for_each_pipe(dev_priv, pipe) {
>> >> + ret = intel_crtc_init(dev_priv, pipe);
>> >
>> > What direction are you planning to take, avoid enabling anything related
>> > to display? My worry is that in
>> >
>> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/fi-bsw-kefka/igt@i915_selftest@live_gt_timelines.html
>> >
>> > we still see weird events like
>> >
>> > <7> [444.313823] [drm:i915_redisable_vga_power_on [i915]] Something
>> > enabled VGA plane, disabling it
>> >
>> > and I'm not sure how you intend to curtail that. (Or if that's even
>> > possible.)
>>
>> The main goal here (in this specific patch) is to decouple disabled but
>> existing display from non-existing display. That lets us develop the two
>> cases independently, and I acknowledge I may have been simple minded
>> enough at some point to believe they could be put in the same bucket.
>
> What's the actual use case for the "disabled but existing display"?
>
> So far I've thought that the only use case is regression testing
> of the "hw has no display" case on hw which in fact has a display.
> If we have separate codepaths we can't do that effectively. At
> which point we might as well get rid of the "disable display"
> capability entirely.
The problem seems to be that we simply can't have the same code paths,
with e.g. bios enabling display hw behind our backs. And patching either
code path with just one knob causes problems to the other. So I want to
decouple the two to make our lives easier for the immediate future.
If we can think of better ways to do this, and better utilize shared
code paths, the decoupling doesn't really prevent us from doing that
either. One idea was probing, then disabling everything, and either
using -EPROBE_DEFER or reprobing and then pretending there is no
display.
But right now this is getting in the way. Need to unblock work. Later we
can re-evaluate whether we need display disable or not and how to best
support it.
Pushed the patch, thanks for review. Does not have to mean end of
discussion though.
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
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Adding YUV444 packed format support for skl+
== Series Details ==
Series: drm/i915: Adding YUV444 packed format support for skl+
URL : https://patchwork.freedesktop.org/series/66770/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6902 -> Patchwork_14420
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/
Known issues
Here are the changes found in Patchwork_14420 that come from known issues:
### IGT changes ###
Issues hit
* igt@vgem_basic@unload:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/fi-icl-u3/igt@vgem_ba...@unload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/fi-icl-u3/igt@vgem_ba...@unload.html
Possible fixes
* igt@gem_basic@bad-close:
- fi-icl-u3: [DMESG-WARN][3] ([fdo#107724]) -> [PASS][4] +2
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/fi-icl-u3/igt@gem_ba...@bad-close.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/fi-icl-u3/igt@gem_ba...@bad-close.html
* igt@gem_ctx_create@basic-files:
- fi-bxt-dsi: [INCOMPLETE][5] ([fdo#103927]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/fi-bxt-dsi/igt@gem_ctx_cre...@basic-files.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/fi-bxt-dsi/igt@gem_ctx_cre...@basic-files.html
* igt@gem_ctx_switch@rcs0:
- fi-icl-u2: [INCOMPLETE][7] ([fdo#107713]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/fi-icl-u2/igt@gem_ctx_swi...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/fi-icl-u2/igt@gem_ctx_swi...@rcs0.html
- {fi-icl-guc}: [INCOMPLETE][9] ([fdo#107713]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/fi-icl-guc/igt@gem_ctx_swi...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/fi-icl-guc/igt@gem_ctx_swi...@rcs0.html
* igt@gem_exec_fence@nb-await-default:
- {fi-tgl-u}: [WARN][11] -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/fi-tgl-u/igt@gem_exec_fe...@nb-await-default.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/fi-tgl-u/igt@gem_exec_fe...@nb-await-default.html
* igt@i915_module_load@reload-no-display:
- {fi-icl-u4}:[DMESG-WARN][13] ([fdo#105602]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/fi-icl-u4/igt@i915_module_l...@reload-no-display.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/fi-icl-u4/igt@i915_module_l...@reload-no-display.html
* igt@i915_selftest@live_reset:
- {fi-icl-dsi}: [INCOMPLETE][15] ([fdo#107713]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/fi-icl-dsi/igt@i915_selftest@live_reset.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/fi-icl-dsi/igt@i915_selftest@live_reset.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][17] ([fdo#111407]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (56 -> 49)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6902 -> Patchwork_14420
CI-20190529: 20190529
CI_DRM_6902: e4f20f2795ecceb54918a57067cb5638d5cd2360 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5185: f02123bfa6ec6baf8ca67459cf4d8b4ea588ca08 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14420: 37a24a45ac0a83c43e71a29311e9a23f1c6ef5b9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
37a24a45ac0a drm/i915: Adding YUV444 packed format support for skl+
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
Someone with drm-misc commit access could push this? Thanks On Sun, 2019-09-15 at 11:36 +, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,1/2] drm/connector: Share with non- > atomic drivers the function to get the single encoder > URL : https://patchwork.freedesktop.org/series/66701/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_6894_full -> Patchwork_14412_full > > > Summary > --- > > **SUCCESS** > > No regressions found. > > > > Known issues > > > Here are the changes found in Patchwork_14412_full that come from > known issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_exec_schedule@preempt-contexts-bsd2: > - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) +14 > similar issues >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb1/igt@gem_exec_sched...@preempt-contexts-bsd2.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb7/igt@gem_exec_sched...@preempt-contexts-bsd2.html > > * igt@gem_exec_schedule@preemptive-hang-bsd: > - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +3 > similar issues >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb6/igt@gem_exec_sched...@preemptive-hang-bsd.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html > > * igt@i915_pm_rpm@modeset-stress-extra-wait: > - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([fdo#105763] > / [fdo#106538]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk7/igt@i915_pm_...@modeset-stress-extra-wait.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk8/igt@i915_pm_...@modeset-stress-extra-wait.html > > * igt@i915_suspend@fence-restore-tiled2untiled: > - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) > +3 similar issues >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html > > * igt@kms_cursor_crc@pipe-b-cursor-alpha-transparent: > - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-snb5/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-snb7/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > > * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: > - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > > * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: > - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#105363]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > > * igt@kms_flip@basic-flip-vs-modeset: > - shard-apl: [PASS][15] -> [INCOMPLETE][16] > ([fdo#103927]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl7/igt@kms_f...@basic-flip-vs-modeset.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl3/igt@kms_f...@basic-flip-vs-modeset.html > > * igt@kms_flip@flip-vs-expired-vblank-interruptible: > - shard-apl: [PASS][17] -> [FAIL][18] ([fdo#105363]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html > > * igt@kms > _frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite: > - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +7 > similar issues >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html > > * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: > - shard-skl: [PASS][21] -> [INCOMPLETE][22] > ([fdo#104108]) >[21]: >
Re: [Intel-gfx] [PATCH 15/19] drm/i915: Simplify skl_max_scale()
Patches 13, 14 and this 15 look ok to me. Those num/den combos in 13 I
cannot bet my head on but the plumbing look all ok.
Also if on 1..8 some patch wasn't pushed yet, those are all
Reviewed-by: Juha-Pekka Heikkila
Ville Syrjala kirjoitti 8.7.2019 klo 15.53:
From: Ville Syrjälä
Now that the planes declare their minimum cdclk requirements properly
we don't need to check the cdclk in skl_max_scale() anymore. Just check
against the maximum downscale ratio, and move the code next to it's
only caller.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 38
drivers/gpu/drm/i915/display/intel_sprite.c | 12 ++-
drivers/gpu/drm/i915/intel_drv.h | 2 --
3 files changed, 11 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1e67fbe50476..489620ef476b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14525,44 +14525,6 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
mutex_unlock(_priv->drm.struct_mutex);
}
-int
-skl_max_scale(const struct intel_crtc_state *crtc_state,
- const struct drm_format_info *format)
-{
- struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- int max_scale;
- int crtc_clock, max_dotclk, tmpclk1, tmpclk2;
-
- if (!crtc_state->base.enable)
- return DRM_PLANE_HELPER_NO_SCALING;
-
- crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
- max_dotclk =
to_intel_atomic_state(crtc_state->base.state)->cdclk.logical.cdclk;
-
- if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
- max_dotclk *= 2;
-
- if (WARN_ON_ONCE(!crtc_clock || max_dotclk < crtc_clock))
- return DRM_PLANE_HELPER_NO_SCALING;
-
- /*
-* skl max scale is lower of:
-*close to 3 but not 3, -1 is for that purpose
-*or
-*cdclk/crtc_clock
-*/
- if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv) ||
- !drm_format_info_is_yuv_semiplanar(format))
- tmpclk1 = 0x3 - 1;
- else
- tmpclk1 = 0x2 - 1;
- tmpclk2 = (1 << 8) * ((max_dotclk << 8) / crtc_clock);
- max_scale = min(tmpclk1, tmpclk2);
-
- return max_scale;
-}
-
static void intel_begin_crtc_commit(struct intel_atomic_state *state,
struct intel_crtc *crtc)
{
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index a07887279e1a..0ffbec8291ee 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -2089,6 +2089,16 @@ static int skl_plane_check_nv12_rotation(const struct
intel_plane_state *plane_s
return 0;
}
+static int skl_plane_max_scale(struct drm_i915_private *dev_priv,
+ const struct drm_framebuffer *fb)
+{
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv) ||
+ !drm_format_info_is_yuv_semiplanar(fb->format))
+ return 0x3 - 1;
+ else
+ return 0x2 - 1;
+}
+
static int skl_plane_check(struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state)
{
@@ -2106,7 +2116,7 @@ static int skl_plane_check(struct intel_crtc_state
*crtc_state,
/* use scaler when colorkey is not required */
if (!plane_state->ckey.flags && intel_fb_scalable(fb)) {
min_scale = 1;
- max_scale = skl_max_scale(crtc_state, fb->format);
+ max_scale = skl_plane_max_scale(dev_priv, fb);
}
ret = drm_atomic_helper_check_plane_state(_state->base,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 999ad3166cd1..02eeaec86997 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1620,8 +1620,6 @@ void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
u16 skl_scaler_calc_phase(int sub, int scale, bool chroma_center);
int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state);
-int skl_max_scale(const struct intel_crtc_state *crtc_state,
- const struct drm_format_info *format);
static inline u32 intel_plane_ggtt_offset(const struct intel_plane_state *state)
{
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Suspend pre-parser across GTT invalidations
On 9/14/19 1:25 AM, Chris Wilson wrote: Before we execute a batch, we must first issue any and all TLB invalidations so that batch picks up the new page table entries. Tigerlake's preparser is weakening our post-sync CS_STALL inside the invalidate pipe-control and allowing the loading of the batch buffer before we have setup its page table (and so it loads the wrong page and executes indefinitely). Signed-off-by: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Mika Kuoppala --- Suggestions welcome as this does not seem intended behaviour, so I suspect there is a strong pipecontrol flag we are missing. When I discussed the pre-parser with the HW team the feedback I got was that the only way to make sure we don't race the memory update is to either leave enough CL of space or turn the parser off like you did below. That discussion was about actual physical memory access though and not TLB. Anyway, turning off the parser around the pipe control, if it fixes the problem, shouldn't be too bad since the main performance advantage of the parser is expected inside the user batch. The alternative would probably be to stop invalidating the TLBs from within the ring and switch to MMIO invalidations when lite-restoring a new request in the ring (the CS will implicitly stop the parser and invalidate everything on a full ctx switch). Daniele --- drivers/gpu/drm/i915/gt/intel_lrc.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index a3f0e4999744..a9e690c303cc 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -2796,11 +2796,14 @@ static int gen11_emit_flush_render(struct i915_request *request, flags |= PIPE_CONTROL_QW_WRITE; flags |= PIPE_CONTROL_GLOBAL_GTT_IVB; - cs = intel_ring_begin(request, 6); + cs = intel_ring_begin(request, 8); if (IS_ERR(cs)) return PTR_ERR(cs); + *cs++ = MI_ARB_CHECK | 1 << 8 | 1; cs = gen8_emit_pipe_control(cs, flags, scratch_addr); + *cs++ = MI_ARB_CHECK | 1 << 8; + intel_ring_advance(request, cs); } ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Suspend pre-parser across GTT invalidations
Quoting Daniele Ceraolo Spurio (2019-09-16 21:37:26) > > > On 9/14/19 1:25 AM, Chris Wilson wrote: > > Before we execute a batch, we must first issue any and all TLB > > invalidations so that batch picks up the new page table entries. > > Tigerlake's preparser is weakening our post-sync CS_STALL inside the > > invalidate pipe-control and allowing the loading of the batch buffer > > before we have setup its page table (and so it loads the wrong page and > > executes indefinitely). > > > > Signed-off-by: Chris Wilson > > Cc: Daniele Ceraolo Spurio > > Cc: Mika Kuoppala > > --- > > Suggestions welcome as this does not seem intended behaviour, so I > > suspect there is a strong pipecontrol flag we are missing. > > When I discussed the pre-parser with the HW team the feedback I got was > that the only way to make sure we don't race the memory update is to > either leave enough CL of space or turn the parser off like you did > below. That discussion was about actual physical memory access though > and not TLB. > Anyway, turning off the parser around the pipe control, if it fixes the > problem, shouldn't be too bad since the main performance advantage of > the parser is expected inside the user batch. The alternative would > probably be to stop invalidating the TLBs from within the ring and > switch to MMIO invalidations when lite-restoring a new request in the > ring (the CS will implicitly stop the parser and invalidate everything > on a full ctx switch). I also only observe the effect on rcs0 atm. Does that tie in with the preparser theory? i.e. that either the MI_FLUSH_DW is a strong barrier or the preparser is rcs0 only. (Strictly speaking I haven't yet run the igt_cs_tlb test on tgl/bcs0 so I am basing the above off the igt test results that pass on bcs0 but consistently failed on rcs0.) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
On Mon, 2019-09-16 at 12:39 -0700, Manasi Navare wrote: > On Mon, Sep 16, 2019 at 07:34:32PM +, Souza, Jose wrote: > > Someone with drm-misc commit access could push this? > > > > Sure will push this series. Thanks Manasi > > Manasi > > > Thanks > > > > On Sun, 2019-09-15 at 11:36 +, Patchwork wrote: > > > == Series Details == > > > > > > Series: series starting with [CI,1/2] drm/connector: Share with > > > non- > > > atomic drivers the function to get the single encoder > > > URL : https://patchwork.freedesktop.org/series/66701/ > > > State : success > > > > > > == Summary == > > > > > > CI Bug Log - changes from CI_DRM_6894_full -> > > > Patchwork_14412_full > > > > > > > > > Summary > > > --- > > > > > > **SUCCESS** > > > > > > No regressions found. > > > > > > > > > > > > Known issues > > > > > > > > > Here are the changes found in Patchwork_14412_full that come > > > from > > > known issues: > > > > > > ### IGT changes ### > > > > > > Issues hit > > > > > > * igt@gem_exec_schedule@preempt-contexts-bsd2: > > > - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) > > > +14 > > > similar issues > > >[1]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb1/igt@gem_exec_sched...@preempt-contexts-bsd2.html > > >[2]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb7/igt@gem_exec_sched...@preempt-contexts-bsd2.html > > > > > > * igt@gem_exec_schedule@preemptive-hang-bsd: > > > - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) > > > +3 > > > similar issues > > >[3]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb6/igt@gem_exec_sched...@preemptive-hang-bsd.html > > >[4]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html > > > > > > * igt@i915_pm_rpm@modeset-stress-extra-wait: > > > - shard-glk: [PASS][5] -> [DMESG-WARN][6] > > > ([fdo#105763] > > > / [fdo#106538]) > > >[5]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk7/igt@i915_pm_...@modeset-stress-extra-wait.html > > >[6]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk8/igt@i915_pm_...@modeset-stress-extra-wait.html > > > > > > * igt@i915_suspend@fence-restore-tiled2untiled: > > > - shard-apl: [PASS][7] -> [DMESG-WARN][8] > > > ([fdo#108566]) > > > +3 similar issues > > >[7]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html > > >[8]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html > > > > > > * igt@kms_cursor_crc@pipe-b-cursor-alpha-transparent: > > > - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) > > >[9]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-snb5/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > > >[10]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-snb7/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > > > > > > * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: > > > - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) > > >[11]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > > >[12]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > > > > > > * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: > > > - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#105363]) > > >[13]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > > >[14]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > > > > > > * igt@kms_flip@basic-flip-vs-modeset: > > > - shard-apl: [PASS][15] -> [INCOMPLETE][16] > > > ([fdo#103927]) > > >[15]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl7/igt@kms_f...@basic-flip-vs-modeset.html > > >[16]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl3/igt@kms_f...@basic-flip-vs-modeset.html > > > > > > * igt@kms_flip@flip-vs-expired-vblank-interruptible: > > > - shard-apl: [PASS][17] -> [FAIL][18] ([fdo#105363]) > > >[17]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html > > >[18]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html > > > > > > * igt@kms > > >
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Adding YUV444 packed format support for skl+
== Series Details == Series: drm/i915: Adding YUV444 packed format support for skl+ URL : https://patchwork.freedesktop.org/series/66770/ State : warning == Summary == $ dim checkpatch origin/drm-tip 37a24a45ac0a drm/i915: Adding YUV444 packed format support for skl+ -:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #9: PLANE_CTL_FORMAT_AYUV is already supported, according to hardware specification. total: 0 errors, 1 warnings, 0 checks, 52 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/perf: Add support for report sizes that are not power of 2
On Sun, Sep 15, 2019 at 02:24:41PM +0300, Lionel Landwerlin wrote:
On 14/09/2019 02:06, Umesh Nerlige Ramappa wrote:
OA perf unit supports non-power of 2 report sizes. Enable support for
these sizes in the driver.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 59
1 file changed, 21 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 50b6d154fd46..482fca3da7de 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -450,7 +450,7 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
u32 gtt_offset = i915_ggtt_offset(stream->oa_buffer.vma);
int report_size = stream->oa_buffer.format_size;
unsigned long flags;
- u32 hw_tail;
+ u32 hw_tail, aging_tail;
u64 now;
/* We have to consider the (unlikely) possibility that read() errors
@@ -459,16 +459,17 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
*/
spin_lock_irqsave(>oa_buffer.ptr_lock, flags);
- hw_tail = dev_priv->perf.ops.oa_hw_tail_read(stream);
+ hw_tail = dev_priv->perf.ops.oa_hw_tail_read(stream) - gtt_offset;
+ aging_tail = stream->oa_buffer.aging_tail - gtt_offset;
/* The tail pointer increases in 64 byte increments,
* not in report_size steps...
*/
- hw_tail &= ~(report_size - 1);
+ hw_tail = OA_TAKEN(hw_tail, (OA_TAKEN(hw_tail, aging_tail) %
report_size));
I'm struggling to parse this line above and I'm not 100% sure it's correct.
Could add a comment to explain what is going on?
The aging tail is always pointing to the boundary of a report whereas
the hw_tail is advancing in 64 byte increments.
The innermost OA_TAKEN is returning the number of bytes between the
hw_tail and the aging_tail. The modulo is getting the size of the
partial report (if any).
The outermost OA_TAKEN is subtracting the size of partial report from
the hw_tail to get a hw_tail that points to the boundary of the last
full report.
The value of hw_tail would be the same as from the deleted line of code
above this line.
Thanks,
Umesh
Thanks,
-Lionel
now = ktime_get_mono_fast_ns();
- if (hw_tail == stream->oa_buffer.aging_tail) {
+ if (hw_tail == aging_tail) {
/* If the HW tail hasn't move since the last check and the HW
* tail has been aging for long enough, declare it the new
* tail.
@@ -486,8 +487,6 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
* a read() in progress.
*/
head = stream->oa_buffer.head - gtt_offset;
-
- hw_tail -= gtt_offset;
tail = hw_tail;
/* Walk the stream backward until we find at least 2 reports
@@ -613,7 +612,18 @@ static int append_oa_sample(struct i915_perf_stream
*stream,
buf += sizeof(header);
if (sample_flags & SAMPLE_OA_REPORT) {
- if (copy_to_user(buf, report, report_size))
+ u8 *oa_buf_end = stream->oa_buffer.vaddr + OA_BUFFER_SIZE;
+ int report_size_partial = oa_buf_end - report;
+
+ if (report_size_partial < report_size) {
+ if (copy_to_user(buf, report, report_size_partial))
+ return -EFAULT;
+ buf += report_size_partial;
+
+ if (copy_to_user(buf, stream->oa_buffer.vaddr,
+ report_size - report_size_partial))
+ return -EFAULT;
+ } else if (copy_to_user(buf, report, report_size))
return -EFAULT;
}
@@ -682,8 +692,8 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* only be incremented by multiples of the report size (notably also
* all a power of two).
*/
- if (WARN_ONCE(head > OA_BUFFER_SIZE || head % report_size ||
- tail > OA_BUFFER_SIZE || tail % report_size,
+ if (WARN_ONCE(head > OA_BUFFER_SIZE ||
+ tail > OA_BUFFER_SIZE,
"Inconsistent OA buffer pointers: head = %u, tail = %u\n",
head, tail))
return -EIO;
@@ -697,20 +707,6 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
u32 ctx_id;
u32 reason;
- /*
-* All the report sizes factor neatly into the buffer
-* size so we never expect to see a report split
-* between the beginning and end of the buffer.
-*
-* Given the initial alignment check a misalignment
-* here would imply a driver bug that would result
-* in an overrun.
-*/
-
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/display/icl: Bump up the hdisplay and vdisplay as per transcoder limits
On Fri, Sep 13, 2019 at 03:36:39PM +0200, Maarten Lankhorst wrote:
> Hey,
>
> Op 29-07-2019 om 21:17 schreef Manasi Navare:
> > Hi Ville,
> >
> > Thanks for your review, so do we want to merge this as is or
> > do we need some function to reject the 8K mode on ICL in
> > intel_dp_mode_valid()?
> >
> > Manasi
>
> I've pushed this series as-is because it blocks my bigjoiner work. We should
> probably reject modes in the connector specific functions if we can't handle
> it. :)
Thanks Maarten. So in case of intel_dp_mode_valid() for example the 8K mode
will be rejected if big joiner not supported correct?
Manasi
>
>
> >
> > On Fri, Jul 12, 2019 at 11:29:38PM +0300, Ville Syrjälä wrote:
> >> On Fri, Jul 12, 2019 at 01:22:13PM -0700, Manasi Navare wrote:
> >>> On ICL+, the vertical limits for the transcoders are increased to 8192
> >>> and horizontal limits are bumped to 16K so bump up
> >>> limits in intel_mode_valid()
> >>>
> >>> v4:
> >>> * Increase the hdisplay to 16K (Ville)
> >>> v3:
> >>> * Supported starting ICL (Ville)
> >>> * Use the higher limits from TRANS_VTOTAL register (Ville)
> >>> v2:
> >>> * Checkpatch warning (Manasi)
> >>>
> >>> Cc: Maarten Lankhorst
> >>> Cc: Ville Syrjälä
> >>> Signed-off-by: Manasi Navare
> >> Reviewed-by: Ville Syrjälä
> >>
> >>> ---
> >>> drivers/gpu/drm/i915/display/intel_display.c | 9 +++--
> >>> 1 file changed, 7 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> >>> b/drivers/gpu/drm/i915/display/intel_display.c
> >>> index f07081815b80..15006764862b 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_display.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >>> @@ -15764,8 +15764,13 @@ intel_mode_valid(struct drm_device *dev,
> >>> DRM_MODE_FLAG_CLKDIV2))
> >>> return MODE_BAD;
> >>>
> >>> - if (INTEL_GEN(dev_priv) >= 9 ||
> >>> - IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv)) {
> >>> + if (INTEL_GEN(dev_priv) >= 11) {
> >>> + hdisplay_max = 16384;
> >>> + vdisplay_max = 8192;
> >>> + htotal_max = 16384;
> >>> + vtotal_max = 8192;
> >>> + } else if (INTEL_GEN(dev_priv) >= 9 ||
> >>> +IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv)) {
> >>> hdisplay_max = 8192; /* FDI max 4096 handled elsewhere */
> >>> vdisplay_max = 4096;
> >>> htotal_max = 8192;
> >>> --
> >>> 2.19.1
> >> --
> >> 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 2/2] drm/mm: Pack allocated/scanned boolean into a bitfield
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
>Of Chris Wilson
>Sent: Sunday, September 15, 2019 2:46 PM
>To: dri-de...@lists.freedesktop.org
>Cc: intel-gfx@lists.freedesktop.org
>Subject: [PATCH 2/2] drm/mm: Pack allocated/scanned boolean into a bitfield
>
>The ulterior motive to switching the booleans over to bitops is to
>allow use of the allocated flag as a bitlock.
>
>Signed-off-by: Chris Wilson
>---
> drivers/gpu/drm/drm_mm.c | 36 +++
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 6 ++--
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 2 +-
> drivers/gpu/drm/i915/i915_gem.c | 16 -
> drivers/gpu/drm/i915/i915_gem_evict.c | 2 +-
> drivers/gpu/drm/i915/i915_vma.c | 2 +-
> drivers/gpu/drm/i915/i915_vma.h | 4 +--
> drivers/gpu/drm/selftests/test-drm_mm.c | 14
> drivers/gpu/drm/vc4/vc4_crtc.c| 2 +-
> drivers/gpu/drm/vc4/vc4_hvs.c | 2 +-
> drivers/gpu/drm/vc4/vc4_plane.c | 4 +--
> include/drm/drm_mm.h | 7 ++--
> 12 files changed, 52 insertions(+), 45 deletions(-)
>
>diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
>index 4581c5387372..211967006cec 100644
>--- a/drivers/gpu/drm/drm_mm.c
>+++ b/drivers/gpu/drm/drm_mm.c
>@@ -174,7 +174,7 @@ static void drm_mm_interval_tree_add_node(struct
>drm_mm_node *hole_node,
>
> node->__subtree_last = LAST(node);
>
>- if (hole_node->allocated) {
>+ if (drm_mm_node_allocated(hole_node)) {
> rb = _node->rb;
> while (rb) {
> parent = rb_entry(rb, struct drm_mm_node, rb);
>@@ -424,9 +424,9 @@ int drm_mm_reserve_node(struct drm_mm *mm,
>struct drm_mm_node *node)
>
> node->mm = mm;
>
>+ __set_bit(DRM_MM_NODE_ALLOCATED_BIT, >flags);
Maybe a silly question(s), but you appear to be mixing atomic bit ops
(clear_ and test_) with non-atomic bit ops __xxx_bit().
Should that be a concern? Should that be mention in the commit?
Mike
> list_add(>node_list, >node_list);
> drm_mm_interval_tree_add_node(hole, node);
>- node->allocated = true;
> node->hole_size = 0;
>
> rm_hole(hole);
>@@ -543,9 +543,9 @@ int drm_mm_insert_node_in_range(struct drm_mm *
>const mm,
> node->color = color;
> node->hole_size = 0;
>
>+ __set_bit(DRM_MM_NODE_ALLOCATED_BIT, >flags);
> list_add(>node_list, >node_list);
> drm_mm_interval_tree_add_node(hole, node);
>- node->allocated = true;
>
> rm_hole(hole);
> if (adj_start > hole_start)
>@@ -561,6 +561,11 @@ int drm_mm_insert_node_in_range(struct drm_mm
>* const mm,
> }
> EXPORT_SYMBOL(drm_mm_insert_node_in_range);
>
>+static inline bool drm_mm_node_scanned_block(const struct
>drm_mm_node *node)
>+{
>+ return test_bit(DRM_MM_NODE_SCANNED_BIT, >flags);
>+}
>+
> /**
> * drm_mm_remove_node - Remove a memory node from the allocator.
> * @node: drm_mm_node to remove
>@@ -574,8 +579,8 @@ void drm_mm_remove_node(struct drm_mm_node
>*node)
> struct drm_mm *mm = node->mm;
> struct drm_mm_node *prev_node;
>
>- DRM_MM_BUG_ON(!node->allocated);
>- DRM_MM_BUG_ON(node->scanned_block);
>+ DRM_MM_BUG_ON(!drm_mm_node_allocated(node));
>+ DRM_MM_BUG_ON(drm_mm_node_scanned_block(node));
>
> prev_node = list_prev_entry(node, node_list);
>
>@@ -584,11 +589,12 @@ void drm_mm_remove_node(struct
>drm_mm_node *node)
>
> drm_mm_interval_tree_remove(node, >interval_tree);
> list_del(>node_list);
>- node->allocated = false;
>
> if (drm_mm_hole_follows(prev_node))
> rm_hole(prev_node);
> add_hole(prev_node);
>+
>+ clear_bit_unlock(DRM_MM_NODE_ALLOCATED_BIT, >flags);
> }
> EXPORT_SYMBOL(drm_mm_remove_node);
>
>@@ -605,7 +611,7 @@ void drm_mm_replace_node(struct drm_mm_node
>*old, struct drm_mm_node *new)
> {
> struct drm_mm *mm = old->mm;
>
>- DRM_MM_BUG_ON(!old->allocated);
>+ DRM_MM_BUG_ON(!drm_mm_node_allocated(old));
>
> *new = *old;
>
>@@ -622,8 +628,7 @@ void drm_mm_replace_node(struct drm_mm_node
>*old, struct drm_mm_node *new)
> >holes_addr);
> }
>
>- old->allocated = false;
>- new->allocated = true;
>+ clear_bit_unlock(DRM_MM_NODE_ALLOCATED_BIT, >flags);
> }
> EXPORT_SYMBOL(drm_mm_replace_node);
>
>@@ -731,9 +736,9 @@ bool drm_mm_scan_add_block(struct drm_mm_scan
>*scan,
> u64 adj_start, adj_end;
>
> DRM_MM_BUG_ON(node->mm != mm);
>- DRM_MM_BUG_ON(!node->allocated);
>- DRM_MM_BUG_ON(node->scanned_block);
>- node->scanned_block = true;
>+ DRM_MM_BUG_ON(!drm_mm_node_allocated(node));
>+ DRM_MM_BUG_ON(drm_mm_node_scanned_block(node));
>+ __set_bit(DRM_MM_NODE_SCANNED_BIT, >flags);
>
[Intel-gfx] [PATCH] drm/i915: fix SFC reset flow
Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not match the HW commitment. The expectation from
the HW is that SW will not try to lock the SFC if the engine is not
using it and if we do that the behavior is undefined; on ICL the HW
ends up to returning the ack and ignoring our lock request, but this is
not guaranteed and we shouldn't expect it going forward.
Reported-by: Owen Zhang
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_reset.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 8327220ac558..900958804bd5 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -352,13 +352,15 @@ static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
}
/*
-* Tell the engine that a software reset is going to happen. The engine
-* will then try to force lock the SFC (if currently locked, it will
-* remain so until we tell the engine it is safe to unlock; if currently
-* unlocked, it will ignore this and all new lock requests). If SFC
-* ends up being locked to the engine we want to reset, we have to reset
-* it as well (we will unlock it once the reset sequence is completed).
+* If the engine is using a SFC, tell the engine that a software reset
+* is going to happen. The engine will then try to force lock the SFC.
+* If SFC ends up being locked to the engine we want to reset, we have
+* to reset it as well (we will unlock it once the reset sequence is
+* completed).
*/
+ if (!(intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit))
+ return 0;
+
rmw_set_fw(uncore, sfc_forced_lock, sfc_forced_lock_bit);
if (__intel_wait_for_register_fw(uncore,
@@ -366,10 +368,13 @@ static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
sfc_forced_lock_ack_bit,
sfc_forced_lock_ack_bit,
1000, 0, NULL)) {
- DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
+ /* did we race the unlock? */
+ if (intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit)
+ DRM_ERROR("Wait for SFC forced lock ack failed\n");
return 0;
}
+ /* The HW could return the ack even if the sfc is not in use */
if (intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit)
return sfc_reset_bit;
@@ -382,6 +387,7 @@ static void gen11_unlock_sfc(struct intel_engine_cs *engine)
u8 vdbox_sfc_access = RUNTIME_INFO(engine->i915)->vdbox_sfc_access;
i915_reg_t sfc_forced_lock;
u32 sfc_forced_lock_bit;
+ u32 lock;
switch (engine->class) {
case VIDEO_DECODE_CLASS:
@@ -401,7 +407,10 @@ static void gen11_unlock_sfc(struct intel_engine_cs
*engine)
return;
}
- rmw_clear_fw(uncore, sfc_forced_lock, sfc_forced_lock_bit);
+ lock = intel_uncore_read_fw(uncore, sfc_forced_lock);
+ if (lock & sfc_forced_lock_bit)
+ intel_uncore_write_fw(uncore, sfc_forced_lock,
+ lock & ~sfc_forced_lock_bit);
}
static int gen11_reset_engines(struct intel_gt *gt,
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Handle connector tile support only for modes that match tile size
DRM Fb driver expects multiple CRTCs if it sees connector->has_tile
is set, but we need to handle tile support and look for multiple CRTCs
only for the modes that match the tile size. The other modes should
be able to be displayed without tile support or uisng single CRTC.
This patch adds the check to match the tile size with requested mode
to handle the tile support.
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Jani Nikula
Cc: Dave Airlie
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/drm_fb_helper.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a7ba5b4902d6..ab11e86dd6d5 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1613,7 +1613,9 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
for (j = 0; j < mode_set->num_connectors; j++) {
struct drm_connector *connector =
mode_set->connectors[j];
- if (connector->has_tile) {
+ if (connector->has_tile &&
+ desired_mode->hdisplay == connector->tile_h_size &&
+ desired_mode->vdisplay == connector->tile_v_size) {
lasth = (connector->tile_h_loc ==
(connector->num_h_tile - 1));
lastv = (connector->tile_v_loc ==
(connector->num_v_tile - 1));
/* cloning to multiple tiles is just
crazy-talk, so: */
--
2.19.1
___
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: Handle connector tile support only for modes that match tile size
== Series Details ==
Series: drm: Handle connector tile support only for modes that match tile size
URL : https://patchwork.freedesktop.org/series/66784/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6905 -> Patchwork_14424
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14424/
Known issues
Here are the changes found in Patchwork_14424 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-icl-u2: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] /
[fdo#109100])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14424/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [PASS][3] -> [DMESG-FAIL][4] ([fdo#08])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14424/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@kms_addfb_basic@bad-pitch-256:
- fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724]) +2
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-icl-u3/igt@kms_addfb_ba...@bad-pitch-256.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14424/fi-icl-u3/igt@kms_addfb_ba...@bad-pitch-256.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][7] ([fdo#107718]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14424/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724] / [fdo#111214]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-icl-u3/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14424/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@i915_selftest@live_reset:
- {fi-icl-dsi}: [INCOMPLETE][11] ([fdo#107713]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-icl-dsi/igt@i915_selftest@live_reset.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14424/fi-icl-dsi/igt@i915_selftest@live_reset.html
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: [DMESG-WARN][13] ([fdo#106387]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14424/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][15] ([fdo#111407]) -> [FAIL][16] ([fdo#111096])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14424/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (55 -> 47)
--
Additional (1): fi-apl-guc
Missing(9): fi-icl-u4 fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-icl-y fi-icl-guc fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6905 -> Patchwork_14424
CI-20190529: 20190529
CI_DRM_6905: bd6c56f50d15b22e2348488769580e8a6a378f6b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5186: 0008b3e1b2cf7a73b1e995031c9a73fc97b35aad @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14424: 3228f41bde9d4e23f38511c53187f170902abfe1 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3228f41bde9d drm: Handle connector tile support only for modes that match tile
size
== Logs ==
For more details see:
[Intel-gfx] [PATCH] drm/i915/cml: Add second PCH ID for CMP
The CMP PCH ID we have in the driver is correct for the CML-U machines we have
in our CI system, but the CML-S and CML-H CI machines appear to use a
different PCH ID, leading our driver to detect no PCH for them.
Cc: Rodrigo Vivi
Cc: Anusha Srivatsa
References: 729ae330a0f2e2 ("drm/i915/cml: Introduce Comet Lake PCH")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111461
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pch.c | 1 +
drivers/gpu/drm/i915/intel_pch.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pch.c b/drivers/gpu/drm/i915/intel_pch.c
index fa864d8f2b73..15f8bff141f9 100644
--- a/drivers/gpu/drm/i915/intel_pch.c
+++ b/drivers/gpu/drm/i915/intel_pch.c
@@ -69,6 +69,7 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
unsigned short id)
WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv));
return PCH_CNP;
case INTEL_PCH_CMP_DEVICE_ID_TYPE:
+ case INTEL_PCH_CMP2_DEVICE_ID_TYPE:
DRM_DEBUG_KMS("Found Comet Lake PCH (CMP)\n");
WARN_ON(!IS_COFFEELAKE(dev_priv));
/* CometPoint is CNP Compatible */
diff --git a/drivers/gpu/drm/i915/intel_pch.h b/drivers/gpu/drm/i915/intel_pch.h
index e6a2d65f19c6..c29c81ec7971 100644
--- a/drivers/gpu/drm/i915/intel_pch.h
+++ b/drivers/gpu/drm/i915/intel_pch.h
@@ -41,6 +41,7 @@ enum intel_pch {
#define INTEL_PCH_CNP_DEVICE_ID_TYPE 0xA300
#define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE0x9D80
#define INTEL_PCH_CMP_DEVICE_ID_TYPE 0x0280
+#define INTEL_PCH_CMP2_DEVICE_ID_TYPE 0x0680
#define INTEL_PCH_ICP_DEVICE_ID_TYPE 0x3480
#define INTEL_PCH_MCC_DEVICE_ID_TYPE 0x4B00
#define INTEL_PCH_MCC2_DEVICE_ID_TYPE 0x3880
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cml: Add second PCH ID for CMP
HI,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Matt
> Roper
> Sent: tiistai 17. syyskuuta 2019 3.35
> To: Lucas De Marchi
> Cc: Intel Graphics
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/cml: Add second PCH ID for CMP
>
> On Mon, Sep 16, 2019 at 05:26:10PM -0700, Lucas De Marchi wrote:
> > On Mon, Sep 16, 2019 at 4:33 PM Matt Roper
> wrote:
> > >
> > > The CMP PCH ID we have in the driver is correct for the CML-U
> > > machines we have in our CI system, but the CML-S and CML-H CI
> > > machines appear to use a
> >
> > CML-S is back to life, but CML-H is still failing. Is CML-H actually
> > using the same PCH?
> >
>
> According to the CI's lspci output for each machine, CML-S has 0x0681 and
> CML-H
> has 0x068C. We only care about the upper 9 bits, so a DEVICE_ID_TYPE of
> 0x0680
> should handle both of them.
>
> It looks like CML-H wasn't even attempted by CI (no failure for igt@runner
> like we
> had before, just no results at all for anything).
> The CI BAT email say it wasn't a participating host (along with a handful of
> others),
> but I'm not sure what leads to that --- does it just mean the platform has
> been
> temporarily taken offline?
No, it probably just did not boot properly or something else, Tomi?
It did something:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14423/fi-cml-h/ ...
>
>
> Matt
>
> > Lucas De Marchi
> >
> > > different PCH ID, leading our driver to detect no PCH for them.
> > >
> > > Cc: Rodrigo Vivi
> > > Cc: Anusha Srivatsa
> > > References: 729ae330a0f2e2 ("drm/i915/cml: Introduce Comet Lake
> > > PCH")
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111461
> > > Signed-off-by: Matt Roper
> > > ---
> > > drivers/gpu/drm/i915/intel_pch.c | 1 +
> > > drivers/gpu/drm/i915/intel_pch.h | 1 +
> > > 2 files changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_pch.c
> > > b/drivers/gpu/drm/i915/intel_pch.c
> > > index fa864d8f2b73..15f8bff141f9 100644
> > > --- a/drivers/gpu/drm/i915/intel_pch.c
> > > +++ b/drivers/gpu/drm/i915/intel_pch.c
> > > @@ -69,6 +69,7 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
> unsigned short id)
> > > WARN_ON(!IS_CANNONLAKE(dev_priv) &&
> > > !IS_COFFEELAKE(dev_priv));
> > > return PCH_CNP;
> > > case INTEL_PCH_CMP_DEVICE_ID_TYPE:
> > > + case INTEL_PCH_CMP2_DEVICE_ID_TYPE:
> > > DRM_DEBUG_KMS("Found Comet Lake PCH (CMP)\n");
> > > WARN_ON(!IS_COFFEELAKE(dev_priv));
> > > /* CometPoint is CNP Compatible */ diff --git
> > > a/drivers/gpu/drm/i915/intel_pch.h
> > > b/drivers/gpu/drm/i915/intel_pch.h
> > > index e6a2d65f19c6..c29c81ec7971 100644
> > > --- a/drivers/gpu/drm/i915/intel_pch.h
> > > +++ b/drivers/gpu/drm/i915/intel_pch.h
> > > @@ -41,6 +41,7 @@ enum intel_pch {
> > > #define INTEL_PCH_CNP_DEVICE_ID_TYPE 0xA300
> > > #define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE0x9D80
> > > #define INTEL_PCH_CMP_DEVICE_ID_TYPE 0x0280
> > > +#define INTEL_PCH_CMP2_DEVICE_ID_TYPE 0x0680
> > > #define INTEL_PCH_ICP_DEVICE_ID_TYPE 0x3480
> > > #define INTEL_PCH_MCC_DEVICE_ID_TYPE 0x4B00
> > > #define INTEL_PCH_MCC2_DEVICE_ID_TYPE 0x3880
> > > --
> > > 2.21.0
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >
> >
> > --
> > Lucas De Marchi
>
> --
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
> (916) 356-2795
> ___
> 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 2/3] drm/i915/perf: Add support for report sizes that are not power of 2
On Mon, 16 Sep 2019 12:17:54 -0700, Umesh Nerlige Ramappa wrote: > > On Sun, Sep 15, 2019 at 02:24:41PM +0300, Lionel Landwerlin wrote: > > On 14/09/2019 02:06, Umesh Nerlige Ramappa wrote: > >> OA perf unit supports non-power of 2 report sizes. Enable support for > >> these sizes in the driver. > >> > >> Signed-off-by: Umesh Nerlige Ramappa > >> --- > >> drivers/gpu/drm/i915/i915_perf.c | 59 > >> 1 file changed, 21 insertions(+), 38 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/i915_perf.c > >> b/drivers/gpu/drm/i915/i915_perf.c > >> index 50b6d154fd46..482fca3da7de 100644 > >> --- a/drivers/gpu/drm/i915/i915_perf.c > >> +++ b/drivers/gpu/drm/i915/i915_perf.c > >> @@ -450,7 +450,7 @@ static bool oa_buffer_check_unlocked(struct > >> i915_perf_stream *stream) > >>u32 gtt_offset = i915_ggtt_offset(stream->oa_buffer.vma); > >>int report_size = stream->oa_buffer.format_size; > >>unsigned long flags; > >> - u32 hw_tail; > >> + u32 hw_tail, aging_tail; > >>u64 now; > >>/* We have to consider the (unlikely) possibility that read() errors > >> @@ -459,16 +459,17 @@ static bool oa_buffer_check_unlocked(struct > >> i915_perf_stream *stream) > >> */ > >>spin_lock_irqsave(>oa_buffer.ptr_lock, flags); > >> - hw_tail = dev_priv->perf.ops.oa_hw_tail_read(stream); > >> + hw_tail = dev_priv->perf.ops.oa_hw_tail_read(stream) - gtt_offset; > >> + aging_tail = stream->oa_buffer.aging_tail - gtt_offset; > >>/* The tail pointer increases in 64 byte increments, > >> * not in report_size steps... > >> */ > >> - hw_tail &= ~(report_size - 1); > >> + hw_tail = OA_TAKEN(hw_tail, (OA_TAKEN(hw_tail, aging_tail) % > >> report_size)); > > > > > > I'm struggling to parse this line above and I'm not 100% sure it's correct. > > > > Could add a comment to explain what is going on? > > The aging tail is always pointing to the boundary of a report whereas > the hw_tail is advancing in 64 byte increments. > > The innermost OA_TAKEN is returning the number of bytes between the > hw_tail and the aging_tail. The modulo is getting the size of the > partial report (if any). > > The outermost OA_TAKEN is subtracting the size of partial report from > the hw_tail to get a hw_tail that points to the boundary of the last > full report. > > The value of hw_tail would be the same as from the deleted line of code > above this line. Looks like aging_tail should not be needed (it is complicating the expression and is not there in the original expression). All we need is a "circular modulus". For example would the following work? if (hw_tail < report_size) hw_tail += OA_BUFFER_SIZE; hw_tail = rounddown(hw_tail, report_size); Another way (if we want to avoid the division) would be to maintain a cached copy of hw_tail in SW which is successively (and circularly) incremented by report_size till it catches up with hw_tail read from HW. But probably the first method above is simpler. ___ 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 SFC reset flow
== Series Details ==
Series: drm/i915: fix SFC reset flow
URL : https://patchwork.freedesktop.org/series/66779/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6904 -> Patchwork_14421
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/
Known issues
Here are the changes found in Patchwork_14421 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_addfb_basic@bad-pitch-999:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/fi-icl-u3/igt@kms_addfb_ba...@bad-pitch-999.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/fi-icl-u3/igt@kms_addfb_ba...@bad-pitch-999.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#111407])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-bxt-dsi: [INCOMPLETE][5] ([fdo#103927]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/fi-bxt-dsi/igt@gem_ctx_cre...@basic-files.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/fi-bxt-dsi/igt@gem_ctx_cre...@basic-files.html
* igt@kms_busy@basic-flip-c:
- fi-skl-6770hq: [SKIP][7] ([fdo#109271] / [fdo#109278]) -> [PASS][8]
+2 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/fi-skl-6770hq/igt@kms_b...@basic-flip-c.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/fi-skl-6770hq/igt@kms_b...@basic-flip-c.html
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6770hq: [SKIP][9] ([fdo#109271]) -> [PASS][10] +23 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
* igt@prime_vgem@basic-fence-flip:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/fi-icl-u3/igt@prime_v...@basic-fence-flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/fi-icl-u3/igt@prime_v...@basic-fence-flip.html
Warnings
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-guc: [SKIP][13] ([fdo#109271]) -> [FAIL][14] ([fdo#107707])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107707]: https://bugs.freedesktop.org/show_bug.cgi?id=107707
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111562]: https://bugs.freedesktop.org/show_bug.cgi?id=111562
[fdo#111597]: https://bugs.freedesktop.org/show_bug.cgi?id=111597
Participating hosts (54 -> 48)
--
Additional (2): fi-icl-u4 fi-pnv-d510
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-apl-guc fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6904 -> Patchwork_14421
CI-20190529: 20190529
CI_DRM_6904: ebd25d396bc39c10a4b6947fc42d1bb12ef36cd9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5186: 0008b3e1b2cf7a73b1e995031c9a73fc97b35aad @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14421: 2cea2a30eedfc2cf93d4ca59d7dc191bd779293c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2cea2a30eedf drm/i915: fix SFC reset flow
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/guc: Enable guc logging on guc log relay write
Creating and opening the GuC log relay file enables and starts
the relay potentially before the caller is ready to consume logs.
Change the behavior so that relay starts only on an explicit call
to the write function (with a value of '1'). Other values flush
the log relay as before.
v2: Style changes and fix typos. Add guc_log_relay_stop()
function. (Daniele)
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Robert M. Fosha
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 53 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 4 +-
drivers/gpu/drm/i915/i915_debugfs.c| 22 +++--
3 files changed, 62 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 36332064de9c..e26c7748358b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -226,7 +226,7 @@ static void guc_read_update_log_buffer(struct intel_guc_log
*log)
mutex_lock(>relay.lock);
- if (WARN_ON(!intel_guc_log_relay_enabled(log)))
+ if (WARN_ON(!intel_guc_log_relay_created(log)))
goto out_unlock;
/* Get the pointer to shared GuC log buffer */
@@ -361,6 +361,7 @@ void intel_guc_log_init_early(struct intel_guc_log *log)
{
mutex_init(>relay.lock);
INIT_WORK(>relay.flush_work, capture_logs_work);
+ log->relay.started = false;
}
static int guc_log_relay_create(struct intel_guc_log *log)
@@ -546,7 +547,7 @@ int intel_guc_log_set_level(struct intel_guc_log *log, u32
level)
return ret;
}
-bool intel_guc_log_relay_enabled(const struct intel_guc_log *log)
+bool intel_guc_log_relay_created(const struct intel_guc_log *log)
{
return log->relay.buf_addr;
}
@@ -560,7 +561,7 @@ int intel_guc_log_relay_open(struct intel_guc_log *log)
mutex_lock(>relay.lock);
- if (intel_guc_log_relay_enabled(log)) {
+ if (intel_guc_log_relay_created(log)) {
ret = -EEXIST;
goto out_unlock;
}
@@ -585,6 +586,21 @@ int intel_guc_log_relay_open(struct intel_guc_log *log)
mutex_unlock(>relay.lock);
+ return 0;
+
+out_relay:
+ guc_log_relay_destroy(log);
+out_unlock:
+ mutex_unlock(>relay.lock);
+
+ return ret;
+}
+
+int intel_guc_log_relay_start(struct intel_guc_log *log)
+{
+ if (log->relay.started)
+ return -EEXIST;
+
guc_log_enable_flush_events(log);
/*
@@ -594,14 +610,9 @@ int intel_guc_log_relay_open(struct intel_guc_log *log)
*/
queue_work(system_highpri_wq, >relay.flush_work);
- return 0;
-
-out_relay:
- guc_log_relay_destroy(log);
-out_unlock:
- mutex_unlock(>relay.lock);
+ log->relay.started = true;
- return ret;
+ return 0;
}
void intel_guc_log_relay_flush(struct intel_guc_log *log)
@@ -610,6 +621,9 @@ void intel_guc_log_relay_flush(struct intel_guc_log *log)
struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
intel_wakeref_t wakeref;
+ if (!log->relay.started)
+ return;
+
/*
* Before initiating the forceful flush, wait for any pending/ongoing
* flush to complete otherwise forceful flush may not actually happen.
@@ -623,18 +637,33 @@ void intel_guc_log_relay_flush(struct intel_guc_log *log)
guc_log_capture_logs(log);
}
-void intel_guc_log_relay_close(struct intel_guc_log *log)
+/*
+ * Stops the relay log. Called from intel_guc_log_relay_close(), so no
+ * possibility of race with start/flush since relay_write cannot race
+ * relay_close.
+ */
+static void guc_log_relay_stop(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ if (!log->relay.started)
+ return;
+
guc_log_disable_flush_events(log);
intel_synchronize_irq(i915);
flush_work(>relay.flush_work);
+ log->relay.started = false;
+}
+
+void intel_guc_log_relay_close(struct intel_guc_log *log)
+{
+ guc_log_relay_stop(log);
+
mutex_lock(>relay.lock);
- GEM_BUG_ON(!intel_guc_log_relay_enabled(log));
+ GEM_BUG_ON(!intel_guc_log_relay_created(log));
guc_log_unmap(log);
guc_log_relay_destroy(log);
mutex_unlock(>relay.lock);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
index 6f764879acb1..c252c022c5fc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
@@ -47,6 +47,7 @@ struct intel_guc_log {
struct i915_vma *vma;
struct {
void *buf_addr;
+ bool started;
struct work_struct flush_work;
struct rchan *channel;
struct mutex lock;
@@ -65,8 +66,9 @@ int
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cml: Add second PCH ID for CMP
== Series Details ==
Series: drm/i915/cml: Add second PCH ID for CMP
URL : https://patchwork.freedesktop.org/series/66782/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6905 -> Patchwork_14423
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14423/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14423:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_chamelium@dp-hpd-fast:
- {fi-cml-s}: NOTRUN -> [SKIP][1] +8 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14423/fi-cml-s/igt@kms_chamel...@dp-hpd-fast.html
Known issues
Here are the changes found in Patchwork_14423 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-icl-u3: [PASS][2] -> [INCOMPLETE][3] ([fdo#107713] /
[fdo#109100])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14423/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html
Possible fixes
* igt@gem_ctx_switch@rcs0:
- fi-icl-u2: [INCOMPLETE][4] ([fdo#107713]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-icl-u2/igt@gem_ctx_swi...@rcs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14423/fi-icl-u2/igt@gem_ctx_swi...@rcs0.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][6] ([fdo#107718]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14423/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- {fi-icl-u4}:[DMESG-WARN][8] ([fdo#105602]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-icl-u4/igt@i915_module_l...@reload.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14423/fi-icl-u4/igt@i915_module_l...@reload.html
* igt@i915_selftest@live_reset:
- {fi-icl-dsi}: [INCOMPLETE][10] ([fdo#107713]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-icl-dsi/igt@i915_selftest@live_reset.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14423/fi-icl-dsi/igt@i915_selftest@live_reset.html
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: [DMESG-WARN][12] ([fdo#106387]) -> [PASS][13] +1
similar issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14423/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#106350]: https://bugs.freedesktop.org/show_bug.cgi?id=106350
[fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#111562]: https://bugs.freedesktop.org/show_bug.cgi?id=111562
[fdo#111597]: https://bugs.freedesktop.org/show_bug.cgi?id=111597
Participating hosts (55 -> 48)
--
Additional (1): fi-apl-guc
Missing(8): fi-ilk-m540 fi-cml-h fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6905 -> Patchwork_14423
CI-20190529: 20190529
CI_DRM_6905: bd6c56f50d15b22e2348488769580e8a6a378f6b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5186: 0008b3e1b2cf7a73b1e995031c9a73fc97b35aad @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14423: 96520eb9d5e861f7c8c51e387121a9dd133efebb @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
96520eb9d5e8 drm/i915/cml: Add second PCH ID for CMP
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14423/index.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 drm/i915: Adding YUV444 packed format support for skl+
== Series Details == Series: drm/i915: Adding YUV444 packed format support for skl+ URL : https://patchwork.freedesktop.org/series/66770/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6902_full -> Patchwork_14420_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14420_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14420_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_14420_full: ### IGT changes ### Possible regressions * igt@kms_plane@pixel-format-pipe-b-planes: - shard-skl: [PASS][1] -> [FAIL][2] +13 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/shard-skl8/igt@kms_pl...@pixel-format-pipe-b-planes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/shard-skl4/igt@kms_pl...@pixel-format-pipe-b-planes.html - shard-kbl: [PASS][3] -> [FAIL][4] +13 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/shard-kbl3/igt@kms_pl...@pixel-format-pipe-b-planes.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/shard-kbl1/igt@kms_pl...@pixel-format-pipe-b-planes.html * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping: - shard-glk: [PASS][5] -> [FAIL][6] +13 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/shard-glk9/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/shard-glk9/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html * igt@kms_plane_scaling@pipe-b-scaler-with-pixel-format: - shard-apl: [PASS][7] -> [FAIL][8] +13 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/shard-apl5/igt@kms_plane_scal...@pipe-b-scaler-with-pixel-format.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/shard-apl3/igt@kms_plane_scal...@pipe-b-scaler-with-pixel-format.html Known issues Here are the changes found in Patchwork_14420_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@fifo-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#111325]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/shard-iclb6/igt@gem_exec_sched...@fifo-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/shard-iclb1/igt@gem_exec_sched...@fifo-bsd.html * igt@gem_mmap_gtt@big-copy-odd: - shard-hsw: [PASS][11] -> [INCOMPLETE][12] ([fdo#103540]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/shard-hsw1/igt@gem_mmap_...@big-copy-odd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/shard-hsw1/igt@gem_mmap_...@big-copy-odd.html * igt@i915_pm_rpm@system-suspend: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([fdo#104108] / [fdo#107807]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/shard-skl4/igt@i915_pm_...@system-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/shard-skl9/igt@i915_pm_...@system-suspend.html * igt@kms_draw_crc@draw-method-xrgb-blt-untiled: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#103184] / [fdo#103232] / [fdo#108472]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/shard-skl1/igt@kms_draw_...@draw-method-xrgb-blt-untiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/shard-skl10/igt@kms_draw_...@draw-method-xrgb-blt-untiled.html * igt@kms_flip@flip-vs-expired-vblank: - shard-glk: [PASS][17] -> [FAIL][18] ([fdo#105363]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/shard-glk3/igt@kms_f...@flip-vs-expired-vblank.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/shard-glk6/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#105363]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/shard-skl9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/shard-skl7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][21] -> [INCOMPLETE][22] ([fdo#103665]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6902/shard-kbl4/igt@kms_frontbuffer_track...@fbc-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14420/shard-kbl2/igt@kms_frontbuffer_track...@fbc-suspend.html *
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/cml: Add second PCH ID for CMP
== Series Details ==
Series: drm/i915/cml: Add second PCH ID for CMP
URL : https://patchwork.freedesktop.org/series/66782/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
96520eb9d5e8 drm/i915/cml: Add second PCH ID for CMP
-:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#6:
The CMP PCH ID we have in the driver is correct for the CML-U machines we have
-:12: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 729ae330a0f2 ("drm/i915/cml:
Introduce Comet Lake PCH")'
#12:
References: 729ae330a0f2e2 ("drm/i915/cml: Introduce Comet Lake PCH")
total: 1 errors, 1 warnings, 0 checks, 14 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
Thanks for the patch and reviews, pushed to drm-misc Regards Manasi On Mon, Sep 16, 2019 at 02:12:14PM -0700, Souza, Jose wrote: > On Mon, 2019-09-16 at 12:39 -0700, Manasi Navare wrote: > > On Mon, Sep 16, 2019 at 07:34:32PM +, Souza, Jose wrote: > > > Someone with drm-misc commit access could push this? > > > > > > > Sure will push this series. > > Thanks Manasi > > > > > Manasi > > > > > Thanks > > > > > > On Sun, 2019-09-15 at 11:36 +, Patchwork wrote: > > > > == Series Details == > > > > > > > > Series: series starting with [CI,1/2] drm/connector: Share with > > > > non- > > > > atomic drivers the function to get the single encoder > > > > URL : https://patchwork.freedesktop.org/series/66701/ > > > > State : success > > > > > > > > == Summary == > > > > > > > > CI Bug Log - changes from CI_DRM_6894_full -> > > > > Patchwork_14412_full > > > > > > > > > > > > Summary > > > > --- > > > > > > > > **SUCCESS** > > > > > > > > No regressions found. > > > > > > > > > > > > > > > > Known issues > > > > > > > > > > > > Here are the changes found in Patchwork_14412_full that come > > > > from > > > > known issues: > > > > > > > > ### IGT changes ### > > > > > > > > Issues hit > > > > > > > > * igt@gem_exec_schedule@preempt-contexts-bsd2: > > > > - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) > > > > +14 > > > > similar issues > > > >[1]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb1/igt@gem_exec_sched...@preempt-contexts-bsd2.html > > > >[2]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb7/igt@gem_exec_sched...@preempt-contexts-bsd2.html > > > > > > > > * igt@gem_exec_schedule@preemptive-hang-bsd: > > > > - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) > > > > +3 > > > > similar issues > > > >[3]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb6/igt@gem_exec_sched...@preemptive-hang-bsd.html > > > >[4]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html > > > > > > > > * igt@i915_pm_rpm@modeset-stress-extra-wait: > > > > - shard-glk: [PASS][5] -> [DMESG-WARN][6] > > > > ([fdo#105763] > > > > / [fdo#106538]) > > > >[5]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk7/igt@i915_pm_...@modeset-stress-extra-wait.html > > > >[6]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk8/igt@i915_pm_...@modeset-stress-extra-wait.html > > > > > > > > * igt@i915_suspend@fence-restore-tiled2untiled: > > > > - shard-apl: [PASS][7] -> [DMESG-WARN][8] > > > > ([fdo#108566]) > > > > +3 similar issues > > > >[7]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html > > > >[8]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html > > > > > > > > * igt@kms_cursor_crc@pipe-b-cursor-alpha-transparent: > > > > - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) > > > >[9]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-snb5/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > > > >[10]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-snb7/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > > > > > > > > * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: > > > > - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) > > > >[11]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > > > >[12]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > > > > > > > > * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: > > > > - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#105363]) > > > >[13]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > > > >[14]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > > > > > > > > * igt@kms_flip@basic-flip-vs-modeset: > > > > - shard-apl: [PASS][15] -> [INCOMPLETE][16] > > > > ([fdo#103927]) > > > >[15]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl7/igt@kms_f...@basic-flip-vs-modeset.html > > > >[16]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl3/igt@kms_f...@basic-flip-vs-modeset.html > > > > > > > > * igt@kms_flip@flip-vs-expired-vblank-interruptible: > > > > - shard-apl: [PASS][17] -> [FAIL][18]
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Enable guc logging on guc log relay write (rev3)
== Series Details ==
Series: drm/i915/guc: Enable guc logging on guc log relay write (rev3)
URL : https://patchwork.freedesktop.org/series/66502/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6905 -> Patchwork_14422
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14422 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14422, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14422/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14422:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_gem_contexts:
- fi-skl-guc: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-skl-guc/igt@i915_selftest@live_gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14422/fi-skl-guc/igt@i915_selftest@live_gem_contexts.html
Known issues
Here are the changes found in Patchwork_14422 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-icl-u3: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] /
[fdo#109100])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14422/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [PASS][5] -> [DMESG-WARN][6] ([fdo#102614])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14422/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@gem_ctx_switch@rcs0:
- fi-icl-u2: [INCOMPLETE][7] ([fdo#107713]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-icl-u2/igt@gem_ctx_swi...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14422/fi-icl-u2/igt@gem_ctx_swi...@rcs0.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14422/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live_reset:
- {fi-icl-dsi}: [INCOMPLETE][11] ([fdo#107713]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-icl-dsi/igt@i915_selftest@live_reset.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14422/fi-icl-dsi/igt@i915_selftest@live_reset.html
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: [DMESG-WARN][13] ([fdo#106387]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14422/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][15] ([fdo#111407]) -> [FAIL][16] ([fdo#111096])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6905/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14422/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{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#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#106350]: https://bugs.freedesktop.org/show_bug.cgi?id=106350
[fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111562]: https://bugs.freedesktop.org/show_bug.cgi?id=111562
[fdo#111597]: https://bugs.freedesktop.org/show_bug.cgi?id=111597
Participating hosts (55 -> 48)
--
Additional (1): fi-apl-guc
Missing
Re: [Intel-gfx] [PATCH] drm/i915/cml: Add second PCH ID for CMP
On Mon, Sep 16, 2019 at 4:33 PM Matt Roper wrote:
>
> The CMP PCH ID we have in the driver is correct for the CML-U machines we have
> in our CI system, but the CML-S and CML-H CI machines appear to use a
CML-S is back to life, but CML-H is still failing. Is CML-H actually
using the same PCH?
Lucas De Marchi
> different PCH ID, leading our driver to detect no PCH for them.
>
> Cc: Rodrigo Vivi
> Cc: Anusha Srivatsa
> References: 729ae330a0f2e2 ("drm/i915/cml: Introduce Comet Lake PCH")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111461
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_pch.c | 1 +
> drivers/gpu/drm/i915/intel_pch.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pch.c
> b/drivers/gpu/drm/i915/intel_pch.c
> index fa864d8f2b73..15f8bff141f9 100644
> --- a/drivers/gpu/drm/i915/intel_pch.c
> +++ b/drivers/gpu/drm/i915/intel_pch.c
> @@ -69,6 +69,7 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
> unsigned short id)
> WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv));
> return PCH_CNP;
> case INTEL_PCH_CMP_DEVICE_ID_TYPE:
> + case INTEL_PCH_CMP2_DEVICE_ID_TYPE:
> DRM_DEBUG_KMS("Found Comet Lake PCH (CMP)\n");
> WARN_ON(!IS_COFFEELAKE(dev_priv));
> /* CometPoint is CNP Compatible */
> diff --git a/drivers/gpu/drm/i915/intel_pch.h
> b/drivers/gpu/drm/i915/intel_pch.h
> index e6a2d65f19c6..c29c81ec7971 100644
> --- a/drivers/gpu/drm/i915/intel_pch.h
> +++ b/drivers/gpu/drm/i915/intel_pch.h
> @@ -41,6 +41,7 @@ enum intel_pch {
> #define INTEL_PCH_CNP_DEVICE_ID_TYPE 0xA300
> #define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE0x9D80
> #define INTEL_PCH_CMP_DEVICE_ID_TYPE 0x0280
> +#define INTEL_PCH_CMP2_DEVICE_ID_TYPE 0x0680
> #define INTEL_PCH_ICP_DEVICE_ID_TYPE 0x3480
> #define INTEL_PCH_MCC_DEVICE_ID_TYPE 0x4B00
> #define INTEL_PCH_MCC2_DEVICE_ID_TYPE 0x3880
> --
> 2.21.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cml: Add second PCH ID for CMP
On Mon, Sep 16, 2019 at 05:26:10PM -0700, Lucas De Marchi wrote:
> On Mon, Sep 16, 2019 at 4:33 PM Matt Roper wrote:
> >
> > The CMP PCH ID we have in the driver is correct for the CML-U machines we
> > have
> > in our CI system, but the CML-S and CML-H CI machines appear to use a
>
> CML-S is back to life, but CML-H is still failing. Is CML-H actually
> using the same PCH?
>
According to the CI's lspci output for each machine, CML-S has 0x0681
and CML-H has 0x068C. We only care about the upper 9 bits, so a
DEVICE_ID_TYPE of 0x0680 should handle both of them.
It looks like CML-H wasn't even attempted by CI (no failure for
igt@runner like we had before, just no results at all for anything).
The CI BAT email say it wasn't a participating host (along with a
handful of others), but I'm not sure what leads to that --- does it just
mean the platform has been temporarily taken offline?
Matt
> Lucas De Marchi
>
> > different PCH ID, leading our driver to detect no PCH for them.
> >
> > Cc: Rodrigo Vivi
> > Cc: Anusha Srivatsa
> > References: 729ae330a0f2e2 ("drm/i915/cml: Introduce Comet Lake PCH")
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111461
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/intel_pch.c | 1 +
> > drivers/gpu/drm/i915/intel_pch.h | 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pch.c
> > b/drivers/gpu/drm/i915/intel_pch.c
> > index fa864d8f2b73..15f8bff141f9 100644
> > --- a/drivers/gpu/drm/i915/intel_pch.c
> > +++ b/drivers/gpu/drm/i915/intel_pch.c
> > @@ -69,6 +69,7 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
> > unsigned short id)
> > WARN_ON(!IS_CANNONLAKE(dev_priv) &&
> > !IS_COFFEELAKE(dev_priv));
> > return PCH_CNP;
> > case INTEL_PCH_CMP_DEVICE_ID_TYPE:
> > + case INTEL_PCH_CMP2_DEVICE_ID_TYPE:
> > DRM_DEBUG_KMS("Found Comet Lake PCH (CMP)\n");
> > WARN_ON(!IS_COFFEELAKE(dev_priv));
> > /* CometPoint is CNP Compatible */
> > diff --git a/drivers/gpu/drm/i915/intel_pch.h
> > b/drivers/gpu/drm/i915/intel_pch.h
> > index e6a2d65f19c6..c29c81ec7971 100644
> > --- a/drivers/gpu/drm/i915/intel_pch.h
> > +++ b/drivers/gpu/drm/i915/intel_pch.h
> > @@ -41,6 +41,7 @@ enum intel_pch {
> > #define INTEL_PCH_CNP_DEVICE_ID_TYPE 0xA300
> > #define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE0x9D80
> > #define INTEL_PCH_CMP_DEVICE_ID_TYPE 0x0280
> > +#define INTEL_PCH_CMP2_DEVICE_ID_TYPE 0x0680
> > #define INTEL_PCH_ICP_DEVICE_ID_TYPE 0x3480
> > #define INTEL_PCH_MCC_DEVICE_ID_TYPE 0x4B00
> > #define INTEL_PCH_MCC2_DEVICE_ID_TYPE 0x3880
> > --
> > 2.21.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Lucas De Marchi
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
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 SFC reset flow
== Series Details == Series: drm/i915: fix SFC reset flow URL : https://patchwork.freedesktop.org/series/66779/ State : success == Summary == CI Bug Log - changes from CI_DRM_6904_full -> Patchwork_14421_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14421_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_capture@capture-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/shard-iclb3/igt@gem_exec_capt...@capture-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/shard-iclb2/igt@gem_exec_capt...@capture-bsd.html * igt@gem_exec_schedule@fifo-bsd1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +16 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/shard-iclb2/igt@gem_exec_sched...@fifo-bsd1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/shard-iclb5/igt@gem_exec_sched...@fifo-bsd1.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([fdo#108686]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/shard-glk1/igt@gem_tiled_swapp...@non-threaded.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/shard-glk4/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/shard-apl7/igt@gem_workarou...@suspend-resume-context.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/shard-apl1/igt@gem_workarou...@suspend-resume-context.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/shard-snb1/igt@i915_pm_rc6_reside...@rc6-accuracy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/shard-snb4/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@i915_selftest@live_hangcheck: - shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713] / [fdo#108569]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/shard-iclb3/igt@i915_selftest@live_hangcheck.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/shard-iclb3/igt@i915_selftest@live_hangcheck.html * igt@kms_cursor_crc@pipe-c-cursor-128x128-random: - shard-apl: [PASS][13] -> [INCOMPLETE][14] ([fdo#103927]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/shard-apl2/igt@kms_cursor_...@pipe-c-cursor-128x128-random.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/shard-apl3/igt@kms_cursor_...@pipe-c-cursor-128x128-random.html * igt@kms_cursor_crc@pipe-c-cursor-size-change: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#103232]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/shard-skl4/igt@kms_cursor_...@pipe-c-cursor-size-change.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-size-change.html * igt@kms_draw_crc@draw-method-xrgb-pwrite-ytiled: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#103184] / [fdo#103232] / [fdo#108222]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/shard-skl10/igt@kms_draw_...@draw-method-xrgb-pwrite-ytiled.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/shard-skl9/igt@kms_draw_...@draw-method-xrgb-pwrite-ytiled.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-pwrite: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-pwrite.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-rte: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103167] / [fdo#110378]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-rte.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14421/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-rte.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6904/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [24]:
[Intel-gfx] [PATCH v10 8/9] drm/i915/gvt: GVTg support ppgtt pv optimization
This patch handles ppgtt update from g2v notification.
It read out ppgtt pte entries from guest pte tables page and
convert them to host pfns.
It creates local ppgtt tables and insert the content pages
into the local ppgtt tables directly, which does not track
the usage of guest page table and removes the cost of write
protection from the original shadow page mechansim.
v0: RFC.
v1: rebase.
v2: rebase.
v3: report pv pggtt cap to guest.
v4: renamed VGPU_PVMMIO with VGPU_PVCAP for name consistance, no PV
support if gfx vtd enabled.
v5: rebase.
v6: rebase.
v7: added command transport buffer support.
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/gvt/gtt.c | 298
drivers/gpu/drm/i915/gvt/gtt.h | 11 ++
drivers/gpu/drm/i915/gvt/gvt.h | 4 +
drivers/gpu/drm/i915/gvt/handlers.c | 127 ++-
drivers/gpu/drm/i915/gvt/vgpu.c | 2 +
5 files changed, 441 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 4b04af5..c944ac2 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -1771,6 +1771,25 @@ static int ppgtt_handle_guest_write_page_table_bytes(
return 0;
}
+static void invalidate_mm_pv(struct intel_vgpu_mm *mm)
+{
+ struct intel_vgpu *vgpu = mm->vgpu;
+ struct intel_gvt *gvt = vgpu->gvt;
+ struct intel_gvt_gtt *gtt = >gtt;
+ struct intel_gvt_gtt_pte_ops *ops = gtt->pte_ops;
+ struct intel_gvt_gtt_entry se;
+
+ i915_vm_put(>ppgtt->vm);
+
+ ppgtt_get_shadow_root_entry(mm, , 0);
+ if (!ops->test_present())
+ return;
+ se.val64 = 0;
+ ppgtt_set_shadow_root_entry(mm, , 0);
+
+ mm->ppgtt_mm.shadowed = false;
+}
+
static void invalidate_ppgtt_mm(struct intel_vgpu_mm *mm)
{
struct intel_vgpu *vgpu = mm->vgpu;
@@ -1783,6 +1802,11 @@ static void invalidate_ppgtt_mm(struct intel_vgpu_mm *mm)
if (!mm->ppgtt_mm.shadowed)
return;
+ if (VGPU_PVCAP(mm->vgpu, PV_PPGTT_UPDATE)) {
+ invalidate_mm_pv(mm);
+ return;
+ }
+
for (index = 0; index < ARRAY_SIZE(mm->ppgtt_mm.shadow_pdps); index++) {
ppgtt_get_shadow_root_entry(mm, , index);
@@ -1800,6 +1824,26 @@ static void invalidate_ppgtt_mm(struct intel_vgpu_mm *mm)
mm->ppgtt_mm.shadowed = false;
}
+static int shadow_mm_pv(struct intel_vgpu_mm *mm)
+{
+ struct intel_vgpu *vgpu = mm->vgpu;
+ struct intel_gvt *gvt = vgpu->gvt;
+ struct intel_gvt_gtt_entry se;
+
+ mm->ppgtt = i915_ppgtt_create(gvt->dev_priv);
+ if (IS_ERR(mm->ppgtt)) {
+ gvt_vgpu_err("fail to create ppgtt for pdp 0x%llx\n",
+ px_dma(mm->ppgtt->pd));
+ return PTR_ERR(mm->ppgtt);
+ }
+
+ se.type = GTT_TYPE_PPGTT_ROOT_L4_ENTRY;
+ se.val64 = px_dma(mm->ppgtt->pd);
+ ppgtt_set_shadow_root_entry(mm, , 0);
+ mm->ppgtt_mm.shadowed = true;
+
+ return 0;
+}
static int shadow_ppgtt_mm(struct intel_vgpu_mm *mm)
{
@@ -1814,6 +1858,9 @@ static int shadow_ppgtt_mm(struct intel_vgpu_mm *mm)
if (mm->ppgtt_mm.shadowed)
return 0;
+ if (VGPU_PVCAP(mm->vgpu, PV_PPGTT_UPDATE))
+ return shadow_mm_pv(mm);
+
mm->ppgtt_mm.shadowed = true;
for (index = 0; index < ARRAY_SIZE(mm->ppgtt_mm.guest_pdps); index++) {
@@ -2825,3 +2872,254 @@ void intel_vgpu_reset_gtt(struct intel_vgpu *vgpu)
intel_vgpu_destroy_all_ppgtt_mm(vgpu);
intel_vgpu_reset_ggtt(vgpu, true);
}
+
+#define GEN8_PDE_SHIFT 21
+#define GEN8_PML4E_SHIFT 39
+#define GEN8_PDPE_SHIFT30
+#define GEN8_PML4E_SIZE(1UL << GEN8_PML4E_SHIFT)
+#define GEN8_PML4E_SIZE_MASK (~(GEN8_PML4E_SIZE - 1))
+#define GEN8_PDPE_SIZE (1UL << GEN8_PDPE_SHIFT)
+#define GEN8_PDPE_SIZE_MASK(~(GEN8_PDPE_SIZE - 1))
+#define GEN8_PDE_SIZE (1UL << GEN8_PDE_SHIFT)
+#define GEN8_PDE_SIZE_MASK (~(GEN8_PDE_SIZE - 1))
+
+#define pml4_addr_end(addr, end) \
+({ unsigned long __boundary = \
+ ((addr) + GEN8_PML4E_SIZE) & GEN8_PML4E_SIZE_MASK; \
+ (__boundary < (end)) ? __boundary : (end); \
+})
+
+#define pdp_addr_end(addr, end)
\
+({ unsigned long __boundary = \
+ ((addr) + GEN8_PDPE_SIZE) & GEN8_PDPE_SIZE_MASK; \
+ (__boundary < (end)) ? __boundary : (end); \
+})
+
+#define pd_addr_end(addr, end) \
+({ unsigned long __boundary = \
+ ((addr) + GEN8_PDE_SIZE) & GEN8_PDE_SIZE_MASK; \
+ (__boundary < (end)) ? __boundary : (end); \
+})
+
+struct ppgtt_walk {
+ unsigned long *mfns;
+ int mfn_index;
+ unsigned long *pt;
+};
+
[Intel-gfx] [PATCH v10 9/9] drm/i915/gvt: GVTg support context submission pv optimization
implemented context submission pv optimizaiton within GVTg.
GVTg to read context submission data (elsp_data) from the shared_page
directly without trap cost and eliminate execlist HW behavior emulation
without injecting context switch interrupt to guest under PV
submisison mechanism.
v0: RFC.
v1: rebase.
v2: rebase.
v3: report pv context submission cap and handle VGT_G2V_ELSP_SUBMIT
g2v pv notification.
v4: eliminate execlist HW emulation and don't inject context switch
interrupt to guest under PV submisison mechanism.
v5: rebase.
v6: rebase.
v7: rebase.
v8: addressed v7 pv submission comments.
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/gvt/execlist.c | 6 ++
drivers/gpu/drm/i915/gvt/handlers.c | 30 +-
drivers/gpu/drm/i915/gvt/vgpu.c | 2 ++
3 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/execlist.c
b/drivers/gpu/drm/i915/gvt/execlist.c
index f21b8fb..e52bfd6 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -382,6 +382,9 @@ static int prepare_execlist_workload(struct
intel_vgpu_workload *workload)
int ring_id = workload->ring_id;
int ret;
+ if (VGPU_PVCAP(vgpu, PV_SUBMISSION))
+ return 0;
+
if (!workload->emulate_schedule_in)
return 0;
@@ -429,6 +432,9 @@ static int complete_execlist_workload(struct
intel_vgpu_workload *workload)
goto out;
}
+ if (VGPU_PVCAP(vgpu, PV_SUBMISSION))
+ goto out;
+
ret = emulate_execlist_ctx_schedule_out(execlist, >ctx_desc);
out:
intel_vgpu_unpin_mm(workload->shadow_mm);
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index 7176831..5dc37e8 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -1810,6 +1810,31 @@ static int mmio_read_from_hw(struct intel_vgpu *vgpu,
return intel_vgpu_default_mmio_read(vgpu, offset, p_data, bytes);
}
+static int handle_pv_submission(struct intel_vgpu *vgpu, int ring_id)
+{
+ struct intel_vgpu_execlist *execlist;
+ u32 hw_id = vgpu->gvt->dev_priv->engine[ring_id]->hw_id;
+ u32 base = PV_ELSP_OFF + hw_id * sizeof(struct pv_submission);
+ u32 desc_off = offsetof(struct pv_submission, descs);
+ u32 submitted_off = offsetof(struct pv_submission, submitted);
+ bool submitted = false;
+ int ret;
+
+ execlist = >submission.execlist[ring_id];
+ desc_off += base;
+ if (intel_gvt_read_shared_page(vgpu, desc_off,
+ >elsp_dwords.data, 16))
+ return -EINVAL;
+
+ ret = intel_vgpu_submit_execlist(vgpu, ring_id);
+ if (ret)
+ gvt_vgpu_err("fail submit workload on ring %d\n", ring_id);
+
+ submitted_off += base;
+ ret = intel_gvt_write_shared_page(vgpu, submitted_off, , 1);
+ return ret;
+}
+
static int elsp_mmio_write(struct intel_vgpu *vgpu, unsigned int offset,
void *p_data, unsigned int bytes)
{
@@ -1821,8 +1846,11 @@ static int elsp_mmio_write(struct intel_vgpu *vgpu,
unsigned int offset,
if (WARN_ON(ring_id < 0 || ring_id >= I915_NUM_ENGINES))
return -EINVAL;
- execlist = >submission.execlist[ring_id];
+ if (VGPU_PVCAP(vgpu, PV_SUBMISSION) &&
+ data == PV_ACTION_ELSP_SUBMISSION)
+ return handle_pv_submission(vgpu, ring_id);
+ execlist = >submission.execlist[ring_id];
execlist->elsp_dwords.data[3 - execlist->elsp_dwords.index] = data;
if (execlist->elsp_dwords.index == 3) {
ret = intel_vgpu_submit_execlist(vgpu, ring_id);
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index e8a957a..236ba04 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -51,6 +51,8 @@ void populate_pvinfo_page(struct intel_vgpu *vgpu)
if (!intel_vtd_active())
vgpu_vreg_t(vgpu, vgtif_reg(pv_caps)) = PV_PPGTT_UPDATE;
+ vgpu_vreg_t(vgpu, vgtif_reg(pv_caps)) |= PV_SUBMISSION;
+
vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.mappable_gmadr.base)) =
vgpu_aperture_gmadr_base(vgpu);
vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.mappable_gmadr.size)) =
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 3/9] drm/i915: vgpu pv command buffer support
based on the shared memory setup between guest and GVT, the simple
pv command buffer ring was introduced by this patch used to perform
guest-2-gvt single direction communication.
v1: initial support, added to address i915 PV v6 patch set comment.
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/i915_pvinfo.h | 1 +
drivers/gpu/drm/i915/i915_vgpu.c | 193 +
drivers/gpu/drm/i915/i915_vgpu.h | 66 +
3 files changed, 260 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h
b/drivers/gpu/drm/i915/i915_pvinfo.h
index 3c63603..db9eebb 100644
--- a/drivers/gpu/drm/i915/i915_pvinfo.h
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -49,6 +49,7 @@ enum vgt_g2v_type {
VGT_G2V_EXECLIST_CONTEXT_CREATE,
VGT_G2V_EXECLIST_CONTEXT_DESTROY,
VGT_G2V_SHARED_PAGE_SETUP,
+ VGT_G2V_PV_SEND_TRIGGER,
VGT_G2V_MAX,
};
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 68fecfd..6e29a52 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -322,6 +322,187 @@ int intel_vgt_balloon(struct i915_ggtt *ggtt)
* i915 vgpu PV support for Linux
*/
+/**
+ * wait_for_desc_update - Wait for the command buffer descriptor update.
+ * @desc: buffer descriptor
+ * @fence: response fence
+ * @status:placeholder for status
+ *
+ * GVT will update command buffer descriptor with new fence and status
+ * after processing the command identified by the fence. Wait for
+ * specified fence and then read from the descriptor status of the
+ * command.
+ *
+ * Return:
+ * * 0 response received (status is valid)
+ * * -ETIMEDOUT no response within hardcoded timeout
+ * * -EPROTO no response, CT buffer is in error
+ */
+static int wait_for_desc_update(struct vgpu_pv_ct_buffer_desc *desc,
+ u32 fence, u32 *status)
+{
+ int err;
+
+#define done (READ_ONCE(desc->fence) == fence)
+ err = wait_for_us(done, 5);
+ if (err)
+ err = wait_for(done, 10);
+#undef done
+
+ if (unlikely(err)) {
+ DRM_ERROR("CT: fence %u failed; reported fence=%u\n",
+ fence, desc->fence);
+ }
+
+ *status = desc->status;
+ return err;
+}
+
+/**
+ * DOC: CTB Guest to GVT request
+ *
+ * Format of the CTB Guest to GVT request message is as follows::
+ *
+ * ++-+-+-+-+
+ * | msg[0] | [1] | [2] | ... | [n-1] |
+ * ++-+-+-+-+
+ * | MESSAGE | MESSAGE PAYLOAD |
+ * + HEADER +-+-+-+-+
+ * ||0|1| ... |n|
+ * ++=+=+=+=+
+ * | len >= 1 | FENCE | request specific data |
+ * +--+-+-+-+-+-+
+ *
+ * ^-len---^
+ */
+static int pv_command_buffer_write(struct i915_virtual_gpu_pv *pv,
+ const u32 *action, u32 len /* in dwords */, u32 fence)
+{
+ struct vgpu_pv_ct_buffer_desc *desc = pv->ctb.desc;
+ u32 head = desc->head / 4; /* in dwords */
+ u32 tail = desc->tail / 4; /* in dwords */
+ u32 size = desc->size / 4; /* in dwords */
+ u32 used; /* in dwords */
+ u32 header;
+ u32 *cmds = pv->ctb.cmds;
+ unsigned int i;
+
+ GEM_BUG_ON(desc->size % 4);
+ GEM_BUG_ON(desc->head % 4);
+ GEM_BUG_ON(desc->tail % 4);
+ GEM_BUG_ON(tail >= size);
+
+ /*
+* tail == head condition indicates empty.
+*/
+ if (tail < head)
+ used = (size - head) + tail;
+ else
+ used = tail - head;
+
+ /* make sure there is a space including extra dw for the fence */
+ if (unlikely(used + len + 1 >= size))
+ return -ENOSPC;
+
+ /*
+* Write the message. The format is the following:
+* DW0: header (including action code)
+* DW1: fence
+* DW2+: action data
+*/
+ header = (len << PV_CT_MSG_LEN_SHIFT) |
+(PV_CT_MSG_WRITE_FENCE_TO_DESC) |
+(action[0] << PV_CT_MSG_ACTION_SHIFT);
+
+ cmds[tail] = header;
+ tail = (tail + 1) % size;
+
+ cmds[tail] = fence;
+ tail = (tail + 1) % size;
+
+ for (i = 1; i < len; i++) {
+ cmds[tail] = action[i];
+ tail = (tail + 1) % size;
+ }
+
+ /* now update desc tail (back in bytes) */
+ desc->tail = tail * 4;
+ GEM_BUG_ON(desc->tail > desc->size);
+
+ return 0;
+}
+
+static u32 pv_get_next_fence(struct i915_virtual_gpu_pv *pv)
+{
+ /* For now it's trivial */
+ return ++pv->next_fence;
+}
+
+static int pv_send(struct drm_i915_private
[Intel-gfx] [PATCH v10 4/9] drm/i915: vgpu ppgtt update pv optimization
This patch extends vgpu ppgtt g2v notification to notify host
GVT-g of ppgtt update from guest including alloc_4lvl, clear_4lv4
and insert_4lvl.
These updates use the shared memory page to pass struct pv_ppgtt_update
from guest to GVT which is used for pv optimiation implemeation within
host GVT side.
This patch also add one new pv_caps level to control ppgtt update.
Use PV_PPGTT_UPDATE to control this level of pv optimization.
v0: RFC.
v1: rebased.
v2: added pv callbacks for vm.{allocate_va_range, insert_entries,
clear_range} within ppgtt.
v3: rebased, disable huge page ppgtt support when using PVMMIO ppgtt
update due to complex and performance impact.
v4: moved alloc/insert/clear_4lvl pv callbacks into i915_vgpu_pv.c and
added a single intel_vgpu_config_pv_caps() for vgpu pv callbacks setup.
v5: rebase.
v6: rebase.
v7: rebase.
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/i915_gem.c | 3 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 8
drivers/gpu/drm/i915/i915_vgpu.c| 79 +
drivers/gpu/drm/i915/i915_vgpu.h| 25
5 files changed, 120 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2da9544..1ade8e0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1309,7 +1309,8 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
int ret;
/* We need to fallback to 4K pages if host doesn't support huge gtt. */
- if (intel_vgpu_active(dev_priv) && !intel_vgpu_has_huge_gtt(dev_priv))
+ if ((intel_vgpu_active(dev_priv) && !intel_vgpu_has_huge_gtt(dev_priv))
+ || intel_vgpu_enabled_pv_caps(dev_priv, PV_PPGTT_UPDATE))
mkwrite_device_info(dev_priv)->page_sizes =
I915_GTT_PAGE_SIZE_4K;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e62e9d1..00b187a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1015,7 +1015,7 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
return start;
}
-static void gen8_ppgtt_clear(struct i915_address_space *vm,
+void gen8_ppgtt_clear(struct i915_address_space *vm,
u64 start, u64 length)
{
GEM_BUG_ON(!IS_ALIGNED(start, BIT_ULL(GEN8_PTE_SHIFT)));
@@ -1126,7 +1126,7 @@ static int __gen8_ppgtt_alloc(struct i915_address_space *
const vm,
return ret;
}
-static int gen8_ppgtt_alloc(struct i915_address_space *vm,
+int gen8_ppgtt_alloc(struct i915_address_space *vm,
u64 start, u64 length)
{
u64 from;
@@ -1326,7 +1326,7 @@ static void gen8_ppgtt_insert_huge(struct i915_vma *vma,
} while (iter->sg);
}
-static void gen8_ppgtt_insert(struct i915_address_space *vm,
+void gen8_ppgtt_insert(struct i915_address_space *vm,
struct i915_vma *vma,
enum i915_cache_level cache_level,
u32 flags)
@@ -1517,8 +1517,10 @@ static struct i915_ppgtt *gen8_ppgtt_create(struct
drm_i915_private *i915)
ppgtt->vm.allocate_va_range = gen8_ppgtt_alloc;
ppgtt->vm.clear_range = gen8_ppgtt_clear;
- if (intel_vgpu_active(i915))
+ if (intel_vgpu_active(i915)) {
+ intel_vgpu_config_pv_caps(i915, PV_PPGTT_UPDATE, ppgtt);
gen8_ppgtt_notify_vgt(ppgtt, true);
+ }
ppgtt->vm.cleanup = gen8_ppgtt_cleanup;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 8fd2234..f5536bf 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -588,6 +588,14 @@ static inline void i915_vm_put(struct i915_address_space
*vm)
void gen6_ppgtt_unpin(struct i915_ppgtt *base);
void gen6_ppgtt_unpin_all(struct i915_ppgtt *base);
+void gen8_ppgtt_clear(struct i915_address_space *vm,
+ u64 start, u64 length);
+void gen8_ppgtt_insert(struct i915_address_space *vm,
+ struct i915_vma *vma,
+ enum i915_cache_level cache_level, u32 flags);
+int gen8_ppgtt_alloc(struct i915_address_space *vm,
+ u64 start, u64 length);
+
void i915_gem_suspend_gtt_mappings(struct drm_i915_private *dev_priv);
void i915_gem_restore_gtt_mappings(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 6e29a52..e458892 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -96,6 +96,9 @@ void i915_detect_vgpu(struct drm_i915_private *dev_priv)
dev_priv->vgpu.active = true;
mutex_init(_priv->vgpu.lock);
+ /* guest driver PV capability */
+ dev_priv->vgpu.pv_caps = PV_PPGTT_UPDATE;
+
if (!intel_vgpu_check_pv_caps(dev_priv,
[Intel-gfx] [PATCH v10 5/9] drm/i915: vgpu context submission pv optimization
It is performance optimization to override the actual submisison backend
in order to eliminate execlists csb process and reduce mmio trap numbers
for workload submission without context switch interrupt by talking with
GVT via PV submisison notification mechanism between guest and GVT.
Use PV_SUBMISSION to control this level of pv optimization.
v0: RFC.
v1: rebase.
v2: added pv ops for pv context submission. to maximize code resuse,
introduced 2 more ops (submit_ports & preempt_context) instead of 1 op
(set_default_submission) in engine structure. pv version of
submit_ports and preempt_context implemented.
v3:
1. to reduce more code duplication, code refactor and replaced 2 ops
"submit_ports & preempt_contex" from v2 by 1 ops "write_desc"
in engine structure. pv version of write_des implemented.
2. added VGT_G2V_ELSP_SUBMIT for g2v pv notification.
v4: implemented pv elsp submission tasklet as the backend workload
submisison by talking to GVT with PV notificaiton mechanism and renamed
VGT_G2V_ELSP_SUBMIT to VGT_G2V_PV_SUBMISIION.
v5: addressed v4 comments from Chris, intel_pv_submission.c added.
v6: addressed v5 comments from Chris, replaced engine id by hw_id.
v7: rebase.
v8: addressed v7 comments from Chris.
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c| 12 +-
drivers/gpu/drm/i915/i915_vgpu.c | 18 +-
drivers/gpu/drm/i915/i915_vgpu.h | 15 ++
drivers/gpu/drm/i915/intel_pv_submission.c | 300 +
5 files changed, 341 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_pv_submission.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 658b930..f500cf1 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -250,7 +250,7 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
selftests/igt_spinner.o
# virtual gpu code
-i915-y += i915_vgpu.o
+i915-y += i915_vgpu.o intel_pv_submission.o
ifeq ($(CONFIG_DRM_I915_GVT),y)
i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index a3f0e49..5587aff 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2933,10 +2933,14 @@ void intel_execlists_set_default_submission(struct
intel_engine_cs *engine)
engine->unpark = NULL;
engine->flags |= I915_ENGINE_SUPPORTS_STATS;
- if (!intel_vgpu_active(engine->i915)) {
- engine->flags |= I915_ENGINE_HAS_SEMAPHORES;
- if (HAS_LOGICAL_RING_PREEMPTION(engine->i915))
- engine->flags |= I915_ENGINE_HAS_PREEMPTION;
+ engine->flags |= I915_ENGINE_HAS_SEMAPHORES;
+ if (HAS_LOGICAL_RING_PREEMPTION(engine->i915))
+ engine->flags |= I915_ENGINE_HAS_PREEMPTION;
+
+ if (intel_vgpu_active(engine->i915)) {
+ engine->flags &= ~I915_ENGINE_HAS_SEMAPHORES;
+ engine->flags &= ~I915_ENGINE_HAS_PREEMPTION;
+ intel_vgpu_config_pv_caps(engine->i915, PV_SUBMISSION, engine);
}
if (INTEL_GEN(engine->i915) >= 12) /* XXX disabled for debugging */
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index e458892..a488b68 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -97,7 +97,7 @@ void i915_detect_vgpu(struct drm_i915_private *dev_priv)
mutex_init(_priv->vgpu.lock);
/* guest driver PV capability */
- dev_priv->vgpu.pv_caps = PV_PPGTT_UPDATE;
+ dev_priv->vgpu.pv_caps = PV_PPGTT_UPDATE | PV_SUBMISSION;
if (!intel_vgpu_check_pv_caps(dev_priv, shared_area)) {
DRM_INFO("Virtual GPU for Intel GVT-g detected.\n");
@@ -389,6 +389,7 @@ void intel_vgpu_config_pv_caps(struct drm_i915_private
*dev_priv,
enum pv_caps cap, void *data)
{
struct i915_ppgtt *ppgtt;
+ struct intel_engine_cs *engine;
if (!intel_vgpu_enabled_pv_caps(dev_priv, cap))
return;
@@ -399,6 +400,11 @@ void intel_vgpu_config_pv_caps(struct drm_i915_private
*dev_priv,
ppgtt->vm.insert_entries = gen8_ppgtt_insert_4lvl_pv;
ppgtt->vm.clear_range = gen8_ppgtt_clear_4lvl_pv;
}
+
+ if (cap == PV_SUBMISSION) {
+ engine = (struct intel_engine_cs *)data;
+ vgpu_set_pv_submission(engine);
+ }
}
/**
@@ -594,6 +600,8 @@ static int intel_vgpu_setup_shared_page(struct
drm_i915_private *dev_priv,
u64 gpa;
u16 ver_maj, ver_min;
int ret = 0;
+ int i;
+ u32 size;
/* We allocate 1 page shared between guest and GVT for data exchange.
* ___.
@@ -666,6 +674,14 @@ static int intel_vgpu_setup_shared_page(struct
drm_i915_private *dev_priv,
pv->notify = intel_vgpu_pv_notify_mmio;
[Intel-gfx] [PATCH v10 7/9] drm/i915/gvt: GVTg handle shared_page setup
GVTg implemented shared_page setup operation and read_shared_page
functionality based on hypervisor_read_gpa().
the shared_page_gpa was passed from guest driver through PVINFO
shared_page_gpa register.
v0: RFC.
v1: rebase.
v2: rebase.
v3: added shared_page_gpa check and if read_gpa failure, return zero
memory and handle VGT_G2V_SHARED_PAGE_SETUP g2v notification
v4: rebase.
v5: rebase.
v6: rebase, added PV version support.
v7: rebase.
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/gvt/gvt.h | 8 ++-
drivers/gpu/drm/i915/gvt/handlers.c | 20 +
drivers/gpu/drm/i915/gvt/vgpu.c | 43 +
3 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index b47c6ac..71213e0 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -49,6 +49,7 @@
#include "fb_decoder.h"
#include "dmabuf.h"
#include "page_track.h"
+#include "i915_vgpu.h"
#define GVT_MAX_VGPU 8
@@ -229,6 +230,8 @@ struct intel_vgpu {
struct completion vblank_done;
u32 scan_nonprivbb;
+ u64 shared_page_gpa;
+ bool shared_page_enabled;
};
/* validating GM healthy status*/
@@ -690,7 +693,10 @@ static inline void intel_gvt_mmio_set_in_ctx(
void intel_gvt_debugfs_remove_vgpu(struct intel_vgpu *vgpu);
void intel_gvt_debugfs_init(struct intel_gvt *gvt);
void intel_gvt_debugfs_clean(struct intel_gvt *gvt);
-
+int intel_gvt_read_shared_page(struct intel_vgpu *vgpu,
+ unsigned int offset, void *buf, unsigned long len);
+int intel_gvt_write_shared_page(struct intel_vgpu *vgpu,
+ unsigned int offset, void *buf, unsigned long len);
#include "trace.h"
#include "mpt.h"
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index aceb16f..eb09003 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -1195,6 +1195,8 @@ static int pvinfo_mmio_read(struct intel_vgpu *vgpu,
unsigned int offset,
case 0x78010: /* vgt_caps */
case 0x7881c:
case _vgtif_reg(pv_caps):
+ case _vgtif_reg(shared_page_gpa):
+ case _vgtif_reg(shared_page_gpa) + 4:
break;
default:
invalid_read = true;
@@ -1212,6 +1214,9 @@ static int handle_g2v_notification(struct intel_vgpu
*vgpu, int notification)
enum intel_gvt_gtt_type root_entry_type = GTT_TYPE_PPGTT_ROOT_L4_ENTRY;
struct intel_vgpu_mm *mm;
u64 *pdps;
+ unsigned long gpa, gfn;
+ u16 ver_major = PV_MAJOR;
+ u16 ver_minor = PV_MINOR;
pdps = (u64 *)_vreg64_t(vgpu, vgtif_reg(pdp[0]));
@@ -1225,6 +1230,19 @@ static int handle_g2v_notification(struct intel_vgpu
*vgpu, int notification)
case VGT_G2V_PPGTT_L3_PAGE_TABLE_DESTROY:
case VGT_G2V_PPGTT_L4_PAGE_TABLE_DESTROY:
return intel_vgpu_put_ppgtt_mm(vgpu, pdps);
+ case VGT_G2V_SHARED_PAGE_SETUP:
+ gpa = vgpu_vreg64_t(vgpu, vgtif_reg(shared_page_gpa));
+ gfn = gpa >> PAGE_SHIFT;
+ if (!intel_gvt_hypervisor_is_valid_gfn(vgpu, gfn)) {
+ vgpu_vreg_t(vgpu, vgtif_reg(pv_caps)) = 0;
+ return 0;
+ }
+ vgpu->shared_page_gpa = gpa;
+ vgpu->shared_page_enabled = true;
+
+ intel_gvt_write_shared_page(vgpu, 0, _major, 2);
+ intel_gvt_write_shared_page(vgpu, 2, _minor, 2);
+ break;
case VGT_G2V_EXECLIST_CONTEXT_CREATE:
case VGT_G2V_EXECLIST_CONTEXT_DESTROY:
case 1: /* Remove this in guest driver. */
@@ -1281,6 +1299,8 @@ static int pvinfo_mmio_write(struct intel_vgpu *vgpu,
unsigned int offset,
case _vgtif_reg(pdp[3].hi):
case _vgtif_reg(execlist_context_descriptor_lo):
case _vgtif_reg(execlist_context_descriptor_hi):
+ case _vgtif_reg(shared_page_gpa):
+ case _vgtif_reg(shared_page_gpa) + 4:
break;
case _vgtif_reg(rsv5[0])..._vgtif_reg(rsv5[3]):
invalid_write = true;
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index 9e00979..811edbb 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -63,6 +63,8 @@ void populate_pvinfo_page(struct intel_vgpu *vgpu)
vgpu_vreg_t(vgpu, vgtif_reg(cursor_x_hot)) = UINT_MAX;
vgpu_vreg_t(vgpu, vgtif_reg(cursor_y_hot)) = UINT_MAX;
+ vgpu_vreg64_t(vgpu, vgtif_reg(shared_page_gpa)) = 0;
+
gvt_dbg_core("Populate PVINFO PAGE for vGPU %d\n", vgpu->id);
gvt_dbg_core("aperture base [GMADR] 0x%llx size 0x%llx\n",
vgpu_aperture_gmadr_base(vgpu), vgpu_aperture_sz(vgpu));
@@ -591,3 +593,44 @@ void intel_gvt_reset_vgpu(struct intel_vgpu *vgpu)
intel_gvt_reset_vgpu_locked(vgpu, true, 0);
mutex_unlock(>vgpu_lock);
[Intel-gfx] [PATCH v10 6/9] drm/i915/gvt: GVTg handle pv_caps PVINFO register
implement pv_caps PVINFO register handler in GVTg to
control different level pv optimization within guest.
report VGT_CAPS_PV capability in pvinfo page for guest.
v0: RFC.
v1: rebase.
v2: rebase.
v3: renamed enable_pvmmio to pvmmio_caps which is used for host
pv caps.
v4: renamed pvmmio_caps to pv_caps.
v5: rebase.
v6: rebase.
v7: rebase.
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/gvt/handlers.c | 4
drivers/gpu/drm/i915/gvt/vgpu.c | 3 +++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index 45a9124..aceb16f 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -1194,6 +1194,7 @@ static int pvinfo_mmio_read(struct intel_vgpu *vgpu,
unsigned int offset,
break;
case 0x78010: /* vgt_caps */
case 0x7881c:
+ case _vgtif_reg(pv_caps):
break;
default:
invalid_read = true;
@@ -1264,6 +1265,9 @@ static int pvinfo_mmio_write(struct intel_vgpu *vgpu,
unsigned int offset,
case _vgtif_reg(g2v_notify):
handle_g2v_notification(vgpu, data);
break;
+ case _vgtif_reg(pv_caps):
+ DRM_INFO("vgpu id=%d pv caps =0x%x\n", vgpu->id, data);
+ break;
/* add xhot and yhot to handled list to avoid error log */
case _vgtif_reg(cursor_x_hot):
case _vgtif_reg(cursor_y_hot):
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index d5a6e4e..9e00979 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -47,6 +47,7 @@ void populate_pvinfo_page(struct intel_vgpu *vgpu)
vgpu_vreg_t(vgpu, vgtif_reg(vgt_caps)) = VGT_CAPS_FULL_PPGTT;
vgpu_vreg_t(vgpu, vgtif_reg(vgt_caps)) |= VGT_CAPS_HWSP_EMULATION;
vgpu_vreg_t(vgpu, vgtif_reg(vgt_caps)) |= VGT_CAPS_HUGE_GTT;
+ vgpu_vreg_t(vgpu, vgtif_reg(vgt_caps)) |= VGT_CAPS_PV;
vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.mappable_gmadr.base)) =
vgpu_aperture_gmadr_base(vgpu);
@@ -529,6 +530,7 @@ void intel_gvt_reset_vgpu_locked(struct intel_vgpu *vgpu,
bool dmlr,
struct intel_gvt *gvt = vgpu->gvt;
struct intel_gvt_workload_scheduler *scheduler = >scheduler;
intel_engine_mask_t resetting_eng = dmlr ? ALL_ENGINES : engine_mask;
+ int pv_caps = vgpu_vreg_t(vgpu, vgtif_reg(pv_caps));
gvt_dbg_core("--\n");
gvt_dbg_core("resseting vgpu%d, dmlr %d, engine_mask %08x\n",
@@ -560,6 +562,7 @@ void intel_gvt_reset_vgpu_locked(struct intel_vgpu *vgpu,
bool dmlr,
intel_vgpu_reset_mmio(vgpu, dmlr);
populate_pvinfo_page(vgpu);
+ vgpu_vreg_t(vgpu, vgtif_reg(pv_caps)) = pv_caps;
intel_vgpu_reset_display(vgpu);
if (dmlr) {
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 2/9] drm/i915: vgpu shared memory setup for pv optimization
To enable vgpu pv features, we need to setup a shared memory page
which will be used for data exchange directly accessed between both
guest and backend i915 driver to avoid emulation trap cost.
guest i915 will allocate this page memory and then pass it's physical
address to backend i915 driver through PVINFO register so that backend i915
driver can access this shared page meory without any trap cost with the
help form hyperviser's read guest gpa functionality.
guest i915 will send VGT_G2V_SHARED_PAGE_SETUP notification to host GVT
once shared memory setup finished.
the layout of the shared_page also defined as well in this patch which
is used for pv features implementation.
v0: RFC.
v1: addressed RFC comment to move both shared_page_lock and shared_page
to i915_virtual_gpu structure.
v2: packed i915_virtual_gpu structure.
v3: added SHARED_PAGE_SETUP g2v notification for pv shared_page setup
v4: added intel_vgpu_setup_shared_page() in i915_vgpu_pv.c.
v5: per engine desc data in shared memory.
v6: added version support in shared memory (Zhenyu).
v7: added new function i915_destroy_vgpu to free shared memory.
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/i915_drv.c| 2 +
drivers/gpu/drm/i915/i915_drv.h| 4 +-
drivers/gpu/drm/i915/i915_pvinfo.h | 5 +-
drivers/gpu/drm/i915/i915_vgpu.c | 95 ++
drivers/gpu/drm/i915/i915_vgpu.h | 18
5 files changed, 122 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0dfcb40..b1f95d0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1637,6 +1637,8 @@ static void i915_driver_release(struct drm_device *dev)
disable_rpm_wakeref_asserts(rpm);
+ i915_destroy_vgpu(dev_priv);
+
i915_gem_driver_release(dev_priv);
i915_ggtt_driver_release(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 19fbbef..b3c0849 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -973,7 +973,9 @@ struct i915_virtual_gpu {
bool active;
u32 caps;
u32 pv_caps;
-};
+
+ struct i915_virtual_gpu_pv *pv;
+} __packed;
/* used in computing the new watermarks state */
struct intel_wm_config {
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h
b/drivers/gpu/drm/i915/i915_pvinfo.h
index ad398b4..3c63603 100644
--- a/drivers/gpu/drm/i915/i915_pvinfo.h
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -48,6 +48,7 @@ enum vgt_g2v_type {
VGT_G2V_PPGTT_L4_PAGE_TABLE_DESTROY,
VGT_G2V_EXECLIST_CONTEXT_CREATE,
VGT_G2V_EXECLIST_CONTEXT_DESTROY,
+ VGT_G2V_SHARED_PAGE_SETUP,
VGT_G2V_MAX,
};
@@ -112,7 +113,9 @@ struct vgt_if {
u32 pv_caps;
- u32 rsv7[0x200 - 25];/* pad to one page */
+ u64 shared_page_gpa;
+
+ u32 rsv7[0x200 - 27];/* pad to one page */
} __packed;
#define vgtif_offset(x) (offsetof(struct vgt_if, x))
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 981959b..68fecfd 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -107,6 +107,17 @@ void i915_detect_vgpu(struct drm_i915_private *dev_priv)
pci_iounmap(pdev, shared_area);
}
+void i915_destroy_vgpu(struct drm_i915_private *dev_priv)
+{
+ struct i915_virtual_gpu_pv *pv = dev_priv->vgpu.pv;
+
+ if (!intel_vgpu_active(dev_priv) || !pv)
+ return;
+
+ __free_page(virt_to_page(pv->shared_page));
+ kfree(pv);
+}
+
bool intel_vgpu_has_full_ppgtt(struct drm_i915_private *dev_priv)
{
return dev_priv->vgpu.caps & VGT_CAPS_FULL_PPGTT;
@@ -311,6 +322,84 @@ int intel_vgt_balloon(struct i915_ggtt *ggtt)
* i915 vgpu PV support for Linux
*/
+/*
+ * shared_page setup for VGPU PV features
+ */
+static int intel_vgpu_setup_shared_page(struct drm_i915_private *dev_priv,
+ void __iomem *shared_area)
+{
+ void __iomem *addr;
+ struct i915_virtual_gpu_pv *pv;
+ struct gvt_shared_page *base;
+ u64 gpa;
+ u16 ver_maj, ver_min;
+ int ret = 0;
+
+ /* We allocate 1 page shared between guest and GVT for data exchange.
+* ___.
+* |head | |
+* |___|.. PAGE/8
+* |PV ELSP|
+* :___PAGE/4
+* |desc (SEND)|
+* | |
+* :___PAGE/2
+* |cmds (SEND)|
+* | |
+* | |
+* | |
+* | |
+*
[Intel-gfx] [PATCH v10 1/9] drm/i915: introduced vgpu pv capability
pv capability for vgpu was introduced by pv_caps in struct
i915_virtual_gpu and a new pv_caps register for host GVT
was defined in struct vgt_if for vgpu pv optimization.
both of them are used to control different feature pv optimization
supported and implemented by both guest and host.
These fields are default zero, no any pv feature enabled.
it also adds VGT_CAPS_PV capability BIT for guest to check GVTg
can support PV feature or not.
v0: RFC, introudced enable_pvmmio module parameter.
v1: addressed RFC comment to remove enable_pvmmio module parameter
by pv capability check.
v2: rebase.
v3: distinct pv caps from guest and host. renamed enable_pvmmio to
pvmmio_caps which is used for host pv caps.
v4: consolidated all pv related functons into a single file i915_vgpu.c
and renamed pvmmio to pv_caps.
v5: refined PV user-facing message and print pv_caps under debugfs.
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pvinfo.h | 5 -
drivers/gpu/drm/i915/i915_vgpu.c| 43 -
drivers/gpu/drm/i915/i915_vgpu.h| 9
5 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 43db500..e404c3c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -66,6 +66,8 @@ static int i915_capabilities(struct seq_file *m, void *data)
seq_printf(m, "gen: %d\n", INTEL_GEN(dev_priv));
seq_printf(m, "platform: %s\n", intel_platform_name(info->platform));
seq_printf(m, "pch: %d\n", INTEL_PCH_TYPE(dev_priv));
+ if (intel_vgpu_active(dev_priv))
+ seq_printf(m, "vgpu pv_caps: 0x%x\n", dev_priv->vgpu.pv_caps);
msg = "n/a";
#ifdef CONFIG_INTEL_IOMMU
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bf60088..19fbbef 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -99,6 +99,7 @@
#include "i915_irq.h"
#include "intel_gvt.h"
+#include "i915_pvinfo.h"
/* General customization:
*/
@@ -971,6 +972,7 @@ struct i915_virtual_gpu {
struct mutex lock; /* serialises sending of g2v_notify command pkts */
bool active;
u32 caps;
+ u32 pv_caps;
};
/* used in computing the new watermarks state */
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h
b/drivers/gpu/drm/i915/i915_pvinfo.h
index 683e97a..ad398b4 100644
--- a/drivers/gpu/drm/i915/i915_pvinfo.h
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -57,6 +57,7 @@ enum vgt_g2v_type {
#define VGT_CAPS_FULL_PPGTTBIT(2)
#define VGT_CAPS_HWSP_EMULATIONBIT(3)
#define VGT_CAPS_HUGE_GTT BIT(4)
+#define VGT_CAPS_PVBIT(5)
struct vgt_if {
u64 magic; /* VGT_MAGIC */
@@ -109,7 +110,9 @@ struct vgt_if {
u32 execlist_context_descriptor_lo;
u32 execlist_context_descriptor_hi;
- u32 rsv7[0x200 - 24];/* pad to one page */
+ u32 pv_caps;
+
+ u32 rsv7[0x200 - 25];/* pad to one page */
} __packed;
#define vgtif_offset(x) (offsetof(struct vgt_if, x))
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 968be26..981959b 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -95,7 +95,13 @@ void i915_detect_vgpu(struct drm_i915_private *dev_priv)
dev_priv->vgpu.active = true;
mutex_init(_priv->vgpu.lock);
- DRM_INFO("Virtual GPU for Intel GVT-g detected.\n");
+
+ if (!intel_vgpu_check_pv_caps(dev_priv, shared_area)) {
+ DRM_INFO("Virtual GPU for Intel GVT-g detected.\n");
+ goto out;
+ }
+
+ DRM_INFO("Virtual GPU for Intel GVT-g detected with PV Optimized.\n");
out:
pci_iounmap(pdev, shared_area);
@@ -300,3 +306,38 @@ int intel_vgt_balloon(struct i915_ggtt *ggtt)
DRM_ERROR("VGT balloon fail\n");
return ret;
}
+
+/*
+ * i915 vgpu PV support for Linux
+ */
+
+/**
+ * intel_vgpu_check_pv_caps - detect virtual GPU PV capabilities
+ * @dev_priv: i915 device private
+ *
+ * This function is called at the initialization stage, to detect VGPU
+ * PV capabilities
+ *
+ * If guest wants to enable pv_caps, it needs to config it explicitly
+ * through vgt_if interface from gvt layer.
+ */
+bool intel_vgpu_check_pv_caps(struct drm_i915_private *dev_priv,
+ void __iomem *shared_area)
+{
+ u32 gvt_pvcaps;
+ u32 pvcaps = 0;
+
+ if (!intel_vgpu_has_pv_caps(dev_priv))
+ return false;
+
+ /* PV capability negotiation between PV guest and GVT */
+ gvt_pvcaps = readl(shared_area + vgtif_offset(pv_caps));
+ pvcaps = dev_priv->vgpu.pv_caps & gvt_pvcaps;
+ dev_priv->vgpu.pv_caps = pvcaps;
+ writel(pvcaps, shared_area + vgtif_offset(pv_caps));
+
[Intel-gfx] [PATCH v10 0/9] i915 vgpu PV to improve vgpu performance
To improve vgpu performance, it could implement some PV optimization such as to reduce the mmio access trap numbers or eliminate certain piece of HW emulation within guest driver to reduce vm exit/vm enter cost. the solutions in this patch set are implemented two PV optimizations based on the shared memory region between guest and GVTg for data communication. The shared memory region is allocated by guest driver and this region's memory guest physical address will be passed to GVTg through PVINFO register and later GVTg can access this region directly without trap cost to achieve data exchange purpose between guest and GVTg. in this patch set, 2 kind of PV optimization implemented controlled by pv_caps PVINO register with different pv bit. 1. workload PV submission (context submission): reduce 4 traps to 1 trap and eliminated execlists HW behaviour emulation. 2. ppgtt PV update: eliminate the cost of ppgtt write protection. based on the experiment, for small workloads, specifally, glxgears with vblank_mode off, the average performance gain on single vgpu is 30~50%. for large workload such as media and 3D, the average performance gain is about 4%. based on the PV mechanism, it could achive more vgpu feature optimization such as globle GTT update, display plane and water mark update. v0: RFC patch set v1: addressed RFC review comments v2: addressed v1 review comments, added pv callbacks for pv operations v3: 1. addressed v2 review comments, removed pv callbacks code duplication in v2 and unified pv calls under g2v notification register. different g2v pv notifications defined. 2. dropped pv master irq feature due to hard conflict with recnet i915 change and take time to rework. v4: 1. addressed v3 review comments. 2. extended workload PV submission by skip execlists HW behaviour emulation and context switch interrupt injection. v5: 1. addressed v4 review comments from Chris for pv submission. 2. per-engine communication between PV guest and host. v6: 1. addressed v5 review comments from Chris for pv submission. 2. addressed v5 review comments from Zhenyu for PV version support. v7: 1. addessed v6 review comments from Chris starting to use pv cmd buffer communication between pv guest and GVT. v8: addressed v7 review comments from Chris to refine pv submssion code. v9: refined PV user-facing message and to free PV shared memory in i915_destroy_vgpu. v10: rebased to 5.3.0-rc8 and conducted the IGT BAT test and i915 live test with PV feature. No regression introduced by PV features. for IGT BAT test (fast-feedback.testlist), there are 225 cases in total (162 pass, 12 fail, 42 skip) for both vGPU with/without PV features. for i915 live test, PV features do not bring regression as well. there is a number of cases failed for vGPU live test which include intel_workarounds_live_selftests, intel_hangcheck_live_selftests, igt_vm_isolation, i915_gem_object_blt_live_selftests, preempt, live_virtual_* and required further analysis, not contributed by the PV patches. Xiaolin Zhang (9): drm/i915: introduced vgpu pv capability drm/i915: vgpu shared memory setup for pv optimization drm/i915: vgpu pv command buffer support drm/i915: vgpu ppgtt update pv optimization drm/i915: vgpu context submission pv optimization drm/i915/gvt: GVTg handle pv_caps PVINFO register drm/i915/gvt: GVTg handle shared_page setup drm/i915/gvt: GVTg support ppgtt pv optimization drm/i915/gvt: GVTg support context submission pv optimization drivers/gpu/drm/i915/Makefile | 2 +- drivers/gpu/drm/i915/gt/intel_lrc.c| 12 +- drivers/gpu/drm/i915/gvt/execlist.c| 6 + drivers/gpu/drm/i915/gvt/gtt.c | 298 drivers/gpu/drm/i915/gvt/gtt.h | 11 + drivers/gpu/drm/i915/gvt/gvt.h | 12 +- drivers/gpu/drm/i915/gvt/handlers.c| 181 +++- drivers/gpu/drm/i915/gvt/vgpu.c| 50 drivers/gpu/drm/i915/i915_debugfs.c| 2 + drivers/gpu/drm/i915/i915_drv.c| 2 + drivers/gpu/drm/i915/i915_drv.h| 6 +- drivers/gpu/drm/i915/i915_gem.c| 3 +- drivers/gpu/drm/i915/i915_gem_gtt.c| 10 +- drivers/gpu/drm/i915/i915_gem_gtt.h| 8 + drivers/gpu/drm/i915/i915_pvinfo.h | 9 +- drivers/gpu/drm/i915/i915_vgpu.c | 426 - drivers/gpu/drm/i915/i915_vgpu.h | 133 + drivers/gpu/drm/i915/intel_pv_submission.c | 300 18 files changed, 1455 insertions(+), 16 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_pv_submission.c -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 4/7] drm/i915/dp: Attach colorspace property
It attaches the colorspace connector property to a DisplayPort connector.
Based on colorspace change, modeset will be triggered to switch to a new
colorspace.
Based on colorspace property value create a VSC SDP packet with appropriate
colorspace. This would help to enable wider color gamut like BT2020 on a
sink device.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 3a8aef1c6036..7fe22b37474d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6448,6 +6448,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
else if (INTEL_GEN(dev_priv) >= 5)
drm_connector_attach_max_bpc_property(connector, 6, 12);
+ intel_attach_colorspace_property(connector);
+
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 2/7] drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA
When BT.2020 Colorimetry output is used for DP, we should program BT.2020
Colorimetry to MSA and VSC SDP. It adds output_colorspace to
intel_crtc_state struct as a place holder of pipe's output colorspace.
In order to distinguish needed colorimetry for VSC SDP, it adds
intel_dp_needs_vsc_sdp function.
If the output colorspace requires vsc sdp or output format is YCbCr 4:2:0,
it uses MSA with VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of
Color Encoding Format and Content Color Gamut] while sending
BT.2020 Colorimetry signals we should program MSA MISC1 fields which
indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
v2: Remove useless parentheses
v3: Addressed review comments from Ville
- In order to checking output format and output colorspace on
intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state struct
value.
- Remove a pointless variable.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 7 +++--
.../drm/i915/display/intel_display_types.h| 3 ++
drivers/gpu/drm/i915/display/intel_dp.c | 29 ++-
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
4 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 98d69febd8e3..8dc030650801 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1737,11 +1737,12 @@ void intel_ddi_set_pipe_settings(const struct
intel_crtc_state *crtc_state)
/*
* As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
* of Color Encoding Format and Content Color Gamut] while sending
-* YCBCR 420 signals we should program MSA MISC1 fields which
-* indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
+* YCBCR 420, HDR BT.2020 signals we should program MSA MISC1 fields
+* which indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
*/
- if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ if (intel_dp_needs_vsc_sdp(crtc_state))
temp |= TRANS_MSA_USE_VSC_SDP;
+
I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index d5cc4b810d9e..4108570907d4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -971,6 +971,9 @@ struct intel_crtc_state {
/* Output format RGB/YCBCR etc */
enum intel_output_format output_format;
+ /* Output colorspace sRGB/BT.2020 etc */
+ u32 output_colorspace;
+
/* Output down scaling is done in LSPCON device */
bool lspcon_downsampling;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index a2a0214f771a..3a8aef1c6036 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2187,6 +2187,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->has_pch_encoder = true;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
+ pipe_config->output_colorspace = intel_conn_state->base.colorspace;
+
if (lspcon->active)
lspcon_ycbcr420_config(_connector->base, pipe_config);
else
@@ -4448,6 +4450,31 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp
*intel_dp,
return 0;
}
+bool
+intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state)
+{
+ /*
+* As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
+* of Color Encoding Format and Content Color Gamut], in order to
+* sending YCBCR 420 or HDR BT.2020 signals we should use DP VSC SDP.
+*/
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ return true;
+
+ switch (crtc_state->output_colorspace) {
+ case DRM_MODE_COLORIMETRY_SYCC_601:
+ case DRM_MODE_COLORIMETRY_OPYCC_601:
+ case DRM_MODE_COLORIMETRY_BT2020_YCC:
+ case DRM_MODE_COLORIMETRY_BT2020_RGB:
+ case DRM_MODE_COLORIMETRY_BT2020_CYCC:
+ return true;
+ default:
+ break;
+ }
+
+ return false;
+}
+
static void
intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
@@ -4576,7 +4603,7 @@ void intel_dp_vsc_enable(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
- if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420)
+ if (!intel_dp_needs_vsc_sdp(crtc_state))
return;
intel_dp_setup_vsc_sdp(intel_dp, crtc_state, conn_state);
diff --git
[Intel-gfx] [PATCH v8 1/7] drm/i915/dp: Extend program of VSC Header and DB for Colorimetry Format
It refactors and renames a function which handled vsc sdp header and data
block setup for supporting colorimetry format.
Function intel_dp_setup_vsc_sdp handles vsc sdp header and data block
setup for pixel encoding / colorimetry format.
In order to use colorspace information of a connector, it adds an argument
of drm_connector_state type.
Setup VSC header and data block in function intel_dp_setup_vsc_sdp for
pixel encoding / colorimetry format as per dp 1.4a spec, section 2.2.5.7.1,
table 2-119: VSC SDP Header Bytes, section 2.2.5.7.5,
table 2-120: VSC SDP Payload for DB16 through DB18.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.h | 2 -
drivers/gpu/drm/i915/display/intel_dp.c | 68
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
4 files changed, 60 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3e6394139964..98d69febd8e3 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3623,7 +3623,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
*encoder,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
- intel_dp_ycbcr_420_enable(intel_dp, crtc_state);
+ intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index f4ddde171655..409544e0e2f8 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -526,8 +526,6 @@ void intel_dp_get_m_n(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
void intel_dp_set_m_n(const struct intel_crtc_state *crtc_state,
enum link_m_n_set m_n);
-void intel_dp_ycbcr_420_enable(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state);
int intel_dotclock_calculate(int link_freq, const struct intel_link_m_n *m_n);
bool bxt_find_best_dpll(struct intel_crtc_state *crtc_state,
struct dpll *best_clock);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d09133a958e1..a2a0214f771a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4449,8 +4449,9 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
}
static void
-intel_pixel_encoding_setup_vsc(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state)
+intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct dp_sdp vsc_sdp = {};
@@ -4471,13 +4472,55 @@ intel_pixel_encoding_setup_vsc(struct intel_dp
*intel_dp,
*/
vsc_sdp.sdp_header.HB3 = 0x13;
- /*
-* YCbCr 420 = 3h DB16[7:4] ITU-R BT.601 = 0h, ITU-R BT.709 = 1h
-* DB16[3:0] DP 1.4a spec, Table 2-120
-*/
- vsc_sdp.db[16] = 0x3 << 4; /* 0x3 << 4 , YCbCr 420*/
- /* RGB->YCBCR color conversion uses the BT.709 color space. */
- vsc_sdp.db[16] |= 0x1; /* 0x1, ITU-R BT.709 */
+ /* DP 1.4a spec, Table 2-120 */
+ switch (crtc_state->output_format) {
+ case INTEL_OUTPUT_FORMAT_YCBCR444:
+ vsc_sdp.db[16] = 0x1 << 4; /* YCbCr 444 : DB16[7:4] = 1h */
+ break;
+ case INTEL_OUTPUT_FORMAT_YCBCR420:
+ vsc_sdp.db[16] = 0x3 << 4; /* YCbCr 420 : DB16[7:4] = 3h */
+ break;
+ case INTEL_OUTPUT_FORMAT_RGB:
+ default:
+ /* RGB: DB16[7:4] = 0h */
+ break;
+ }
+
+ switch (conn_state->colorspace) {
+ case DRM_MODE_COLORIMETRY_BT709_YCC:
+ vsc_sdp.db[16] |= 0x1;
+ break;
+ case DRM_MODE_COLORIMETRY_XVYCC_601:
+ vsc_sdp.db[16] |= 0x2;
+ break;
+ case DRM_MODE_COLORIMETRY_XVYCC_709:
+ vsc_sdp.db[16] |= 0x3;
+ break;
+ case DRM_MODE_COLORIMETRY_SYCC_601:
+ vsc_sdp.db[16] |= 0x4;
+ break;
+ case DRM_MODE_COLORIMETRY_OPYCC_601:
+ vsc_sdp.db[16] |= 0x5;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_CYCC:
+ case DRM_MODE_COLORIMETRY_BT2020_RGB:
+ vsc_sdp.db[16] |= 0x6;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_YCC:
+ vsc_sdp.db[16] |= 0x7;
+ break;
+ case
[Intel-gfx] [PATCH v8 5/7] drm/i915: Add new GMP register size for GEN11
According to Bspec, GEN11 and prior GEN11 have different register size for
HDR Metadata Infoframe SDP packet. It adds new VIDEO_DIP_GMP_DATA_SIZE for
GEN11. And it makes handle different register size for
HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN
platforms. It addresses Uma's review comments.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 10 --
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index c500fc9154c8..287999b31217 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -189,13 +189,19 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
}
}
-static int hsw_dip_data_size(unsigned int type)
+static int hsw_dip_data_size(struct drm_i915_private *dev_priv,
+unsigned int type)
{
switch (type) {
case DP_SDP_VSC:
return VIDEO_DIP_VSC_DATA_SIZE;
case DP_SDP_PPS:
return VIDEO_DIP_PPS_DATA_SIZE;
+ case HDMI_PACKET_TYPE_GAMUT_METADATA:
+ if (INTEL_GEN(dev_priv) >= 11)
+ return VIDEO_DIP_GMP_DATA_SIZE;
+ else
+ return VIDEO_DIP_DATA_SIZE;
default:
return VIDEO_DIP_DATA_SIZE;
}
@@ -514,7 +520,7 @@ static void hsw_write_infoframe(struct intel_encoder
*encoder,
int i;
u32 val = I915_READ(ctl_reg);
- data_size = hsw_dip_data_size(type);
+ data_size = hsw_dip_data_size(dev_priv, type);
val &= ~hsw_infoframe_enable(type);
I915_WRITE(ctl_reg, val);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bf37ecebc82f..ff7f32b59363 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4677,6 +4677,7 @@ enum {
* (Haswell and newer) to see which VIDEO_DIP_DATA byte corresponds to each
byte
* of the infoframe structure specified by CEA-861. */
#define VIDEO_DIP_DATA_SIZE 32
+#define VIDEO_DIP_GMP_DATA_SIZE 36
#define VIDEO_DIP_VSC_DATA_SIZE 36
#define VIDEO_DIP_PPS_DATA_SIZE 132
#define VIDEO_DIP_CTL _MMIO(0x61170)
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 0/7] drm/i915/dp: Support for DP HDR outputs
Support for HDR10 video was introduced in DisplayPort 1.4. On GLK+ platform, in order to use DisplayPort HDR10, we need to support BT.2020 colorimetry and HDR Static metadata. It implements the CTA-861-G standard for transport of static HDR metadata. It enables writing of HDR metadata infoframe SDP to the panel. The HDR Metadata will be provided by userspace compositors, based on blending policies and passed to the driver through a blob property. And It refactors, renames and extends a function which handled vsc sdp header and data block setup for supporting colorimetry format. And It attaches the colorspace connector property and HDR metadata property to a DisplayPort connector. These patches tested on below test environment. Test Environment: - Tested System: GLK and Gen11 platform. - Monitor: Dell UP2718Q 4K HDR Monitor. - In order to test DP HDR10, test environment uses patched Kodi-gbm, patched Media driver and HDR10 video. You can find these on below. [patched Kodi-gbm] - repo: https://github.com/Kwiboo/xbmc/tree/drmprime-hdr [download 4K HDR video file] - link: https://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/ [Media Driver for GLK] - repo https://gitlab.freedesktop.org/emersion/intel-vaapi-driver master branch [Media Driver for ICL] - repo: https://github.com/harishkrupo/media-driver/tree/p010_composite v2: - Add a missed blank line after function declaration. - Remove useless parentheses. - Minor style fix. v3: - Remove not handled return values from intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma] - Add handling of different register size for HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN platforms [Uma] - Add new colorimetry options for DP 1.4a spec. [Ville] - Separate set of colorimetry enum values for DP. [Ville] - In order to checking output format and output colorspace on intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state stucture.[Ville] - Remove a pointless variable. [Ville] v4: - Add additional comments to struct drm_prop_enum_list. - Polishing an enum string of struct drm_prop_enum_list. v5: - Change definitions of DRM_MODE_COLORIMETRYs to follow HDMI prefix and DP abbreviations. - Add missed variables on dp_colorspaces. - Fix typo. [Uma] v6: - Addressed review comments from Ilia and Ville Split drm_mode_create_colorspace_property() to DP and HDMI connector. Becasue between HDMI and DP have different colorspaces, it renames drm_mode_create_colorspace_property() function to drm_mode_create_hdmi_colorspace_property() function for HDMI connector. And it adds drm_mode_create_dp_colorspace_property() function for creating of DP colorspace property. In order to apply changed and added drm api, i915 driver has channged. v7: - Fix typo [Jani Saarinen] - Fix white space. v8: - Addressed review comments from Ville Drop colorimetries which have another way to distinguish or which would not be used. Gwan-gyeong Mun (7): drm/i915/dp: Extend program of VSC Header and DB for Colorimetry Format drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA drm: Add DisplayPort colorspace property drm/i915/dp: Attach colorspace property drm/i915: Add new GMP register size for GEN11 drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata drm/i915/dp: Attach HDR metadata property to DP connector drivers/gpu/drm/drm_connector.c | 101 +++-- .../gpu/drm/i915/display/intel_connector.c| 21 +- drivers/gpu/drm/i915/display/intel_ddi.c | 10 +- drivers/gpu/drm/i915/display/intel_display.h | 2 - .../drm/i915/display/intel_display_types.h| 3 + drivers/gpu/drm/i915/display/intel_dp.c | 193 -- drivers/gpu/drm/i915/display/intel_dp.h | 7 + drivers/gpu/drm/i915/display/intel_hdmi.c | 10 +- drivers/gpu/drm/i915/i915_reg.h | 1 + include/drm/drm_connector.h | 7 +- 10 files changed, 313 insertions(+), 42 deletions(-) -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 3/7] drm: Add DisplayPort colorspace property
Because between HDMI and DP have different colorspaces, it renames
drm_mode_create_colorspace_property() function to
drm_mode_create_hdmi_colorspace_property() function for HDMI connector.
And it adds drm_mode_create_dp_colorspace_property() function for creating
of DP colorspace property.
In order to apply changed and added drm api, i915 driver has channged.
v3: Addressed review comments from Ville
- Add new colorimetry options for DP 1.4a spec.
- Separate set of colorimetry enum values for DP.
v4: Add additional comments to struct drm_prop_enum_list.
Polishing an enum string of struct drm_prop_enum_list
v5: Change definitions of DRM_MODE_COLORIMETRYs to follow HDMI prefix and
DP abbreviations.
Add missed variables on dp_colorspaces.
Fix typo. [Uma]
v6: Addressed review comments from Ilia and Ville
- Split drm_mode_create_colorspace_property() to DP and HDMI connector.
v7: Fix typo [Jani Saarinen]
Fix white space.
v8: Addressed review comments from Ville
- Drop colorimetries which have another way to distinguish or which
would not be used.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_connector.c | 101 +++---
.../gpu/drm/i915/display/intel_connector.c| 21 +++-
include/drm/drm_connector.h | 7 +-
3 files changed, 108 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4c766624b20d..57c97949081a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -882,6 +882,38 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
= {
{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
};
+/*
+ * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel
Encoding/Colorimetry
+ * Format Table 2-120
+ */
+static const struct drm_prop_enum_list dp_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ { DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED, "RGB_Wide_Gamut_Fixed_Point" },
+ /* Colorimetry based on scRGB (IEC 61966-2-2) */
+ { DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT, "RGB_Wide_Gamut_Floating_Point"
},
+ /* Colorimetry based on IEC 61966-2-5 */
+ { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
+ /* Colorimetry based on SMPTE RP 431-2 */
+ { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+ { DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
+ { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+};
+
/**
* DOC: standard connector properties
*
@@ -1674,7 +1706,6 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
* DOC: standard connector properties
*
* Colorspace:
- * drm_mode_create_colorspace_property - create colorspace property
* This property helps select a suitable colorspace based on the sink
* capability. Modern sink devices support wider gamut like BT2020.
* This helps switch to BT2020 mode if the BT2020 encoded video stream
@@ -1694,32 +1725,68 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
* - This property is just to inform sink what colorspace
*source is trying to drive.
*
+ * Because between HDMI and DP have different colorspaces,
+ * drm_mode_create_hdmi_colorspace_property() is used for HDMI connector and
+ * drm_mode_create_dp_colorspace_property() is used for DP connector.
+ */
+
+/**
+ * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace property
+ * @connector: connector to create the Colorspace property on.
+ *
* Called by a driver the first time it's needed, must be attached to desired
- * connectors.
+ * HDMI connectors.
+ *
+ * Returns:
+ * Zero on success, negative errono on failure.
*/
-int drm_mode_create_colorspace_property(struct drm_connector *connector)
+int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
- struct drm_property *prop;
- if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
- connector->connector_type ==
[Intel-gfx] [PATCH v8 6/7] drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata
Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP
header and data block setup for HDR Static Metadata. It enables writing of
HDR metadata infoframe SDP to panel. Support for HDR video was introduced
in DisplayPort 1.4. It implements the CTA-861-G standard for transport of
static HDR metadata. The HDR Metadata will be provided by userspace
compositors, based on blending policies and passed to the driver through
a blob property.
Because each of GEN11 and prior GEN11 have different register size for
HDR Metadata Infoframe SDP packet, it adds and uses different register
size.
Setup Infoframe SDP header and data block in function
intel_dp_setup_hdr_metadata_infoframe_sdp for HDR Static Metadata as per
dp 1.4 spec and CTA-861-F spec.
As per DP 1.4 spec, 2.2.2.5 SDP Formats. It enables Dynamic Range and
Mastering Infoframe for HDR content, which is defined in CTA-861-F spec.
According to DP 1.4 spec and CEA-861-F spec Table 5, in order to transmit
static HDR metadata, we have to use Non-audio INFOFRAME SDP v1.3.
++---+
| [ Packet Type Value ] | [ Packet Type ] |
++---+
| 80h + Non-audio INFOFRAME Type | CEA-861-F Non-audio INFOFRAME |
++---+
| [Transmission Timing] |
++
| As per CEA-861-F for INFOFRAME, including CEA-861.3 within |
| which Dynamic Range and Mastering INFOFRAME are defined|
++
v2: Add a missed blank line after function declaration.
v3: Remove not handled return values from
intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma]
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 89
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
3 files changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 8dc030650801..306f6f9f0204 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3625,6 +3625,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
*encoder,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
+ intel_dp_hdr_metadata_enable(intel_dp, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7fe22b37474d..abbf1d5c54c4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4599,6 +4599,83 @@ intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
crtc_state, DP_SDP_VSC, _sdp, sizeof(vsc_sdp));
}
+static void
+intel_dp_setup_hdr_metadata_infoframe_sdp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state
*crtc_state,
+ const struct drm_connector_state
*conn_state)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_i915_private *dev_priv =
to_i915(intel_dig_port->base.base.dev);
+ struct dp_sdp infoframe_sdp = {};
+ struct hdmi_drm_infoframe drm_infoframe = {};
+ const int infoframe_size = HDMI_INFOFRAME_HEADER_SIZE +
HDMI_DRM_INFOFRAME_SIZE;
+ unsigned char buf[HDMI_INFOFRAME_HEADER_SIZE + HDMI_DRM_INFOFRAME_SIZE];
+ ssize_t len;
+ int ret;
+
+ ret = drm_hdmi_infoframe_set_hdr_metadata(_infoframe, conn_state);
+ if (ret) {
+ DRM_DEBUG_KMS("couldn't set HDR metadata in infoframe\n");
+ return;
+ }
+
+ len = hdmi_drm_infoframe_pack_only(_infoframe, buf, sizeof(buf));
+ if (len < 0) {
+ DRM_DEBUG_KMS("buffer size is smaller than hdr metadata
infoframe\n");
+ return;
+ }
+
+ if (len != infoframe_size) {
+ DRM_DEBUG_KMS("wrong static hdr metadata size\n");
+ return;
+ }
+
+ /*
+* Set up the infoframe sdp packet for HDR static metadata.
+* Prepare VSC Header for SU as per DP 1.4a spec,
+* Table 2-100 and Table 2-101
+*/
+
+ /* Packet ID, 00h for non-Audio INFOFRAME */
+ infoframe_sdp.sdp_header.HB0 = 0;
+ /*
+* Packet Type 80h + Non-audio INFOFRAME Type value
+* HDMI_INFOFRAME_TYPE_DRM: 0x87,
+*/
+ infoframe_sdp.sdp_header.HB1 = drm_infoframe.type;
+ /*
+* Least Significant Eight Bits of (Data Byte
[Intel-gfx] [PATCH v8 7/7] drm/i915/dp: Attach HDR metadata property to DP connector
It attaches HDR metadata property to DP connector on GLK+.
It enables HDR metadata infoframe sdp on GLK+ to be used to send
HDR metadata to DP sink.
v2: Minor style fix
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index abbf1d5c54c4..4084b06fcbfc 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6539,6 +6539,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_colorspace_property(connector);
+ if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
+ drm_object_attach_property(>base,
+
connector->dev->mode_config.hdr_output_metadata_property,
+ 0);
+
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 3/7] drm: Add DisplayPort colorspace property
On Fri, 2019-09-13 at 22:13 +0300, Ville Syrjälä wrote:
> On Thu, Sep 12, 2019 at 02:33:34PM +0300, Gwan-gyeong Mun wrote:
> > Because between HDMI and DP have different colorspaces, it renames
> > drm_mode_create_colorspace_property() function to
> > drm_mode_create_hdmi_colorspace_property() function for HDMI
> > connector.
> > And it adds drm_mode_create_dp_colorspace_property() function for
> > creating
> > of DP colorspace property.
> > In order to apply changed and added drm api, i915 driver has
> > channged.
> >
> > v3: Addressed review comments from Ville
> > - Add new colorimetry options for DP 1.4a spec.
> > - Separate set of colorimetry enum values for DP.
> > v4: Add additional comments to struct drm_prop_enum_list.
> > Polishing an enum string of struct drm_prop_enum_list
> > v5: Change definitions of DRM_MODE_COLORIMETRYs to follow HDMI
> > prefix and
> > DP abbreviations.
> > Add missed variables on dp_colorspaces.
> > Fix typo. [Uma]
> > v6: Addressed review comments from Ilia and Ville
> >- Split drm_mode_create_colorspace_property() to DP and HDMI
> > connector.
> > v7: Fix typo [Jani Saarinen]
> > Fix white space.
> >
> > Signed-off-by: Gwan-gyeong Mun
> > Reviewed-by: Uma Shankar
> > ---
> > drivers/gpu/drm/drm_connector.c | 110
> > +++---
> > .../gpu/drm/i915/display/intel_connector.c| 21 +++-
> > include/drm/drm_connector.h | 11 +-
> > 3 files changed, 121 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 4c766624b20d..656f72c1b3d7 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -882,6 +882,47 @@ static const struct drm_prop_enum_list
> > hdmi_colorspaces[] = {
> > { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater"
> > },
> > };
> >
> > +/*
> > + * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel
> > Encoding/Colorimetry
> > + * Format Table 2-120
> > + */
> > +static const struct drm_prop_enum_list dp_colorspaces[] = {
> > + /* For Default case, driver will set the colorspace */
> > + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> > + /* Colorimetry based on sRGB (IEC 61966-2-1) */
> > + { DRM_MODE_COLORIMETRY_CEA_RGB, "CEA_RGB" },
>
> We already have other mechanism for the CEA vs. IT RGB.
> I don't think we want to add another one. So I'd drop this.
>
> > + { DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED,
> > "RGB_Wide_Gamut_Fixed_Point" },
> > + /* Colorimetry based on scRGB (IEC 61966-2-2) */
> > + { DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT,
> > "RGB_Wide_Gamut_Floating_Point" },
> > + /* Colorimetry based on IEC 61966-2-5 */
> > + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> > + /* Colorimetry based on SMPTE RP 431-2 */
> > + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
> > + { DRM_MODE_COLORIMETRY_RGB_CUSTOM_COLOR_PROFILE,
> > "RGB_Custom_Color_Profile" },
>
> I'd also drop this since we have no way to supply the profile anyway.
>
> > + /* Colorimetry based on ITU-R BT.2020 */
> > + { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> > + { DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
> > + { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
> > + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> > + { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
> > + /* High Definition Colorimetry based on IEC 61966-2-4 */
> > + { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
> > + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> > + { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
> > + /* Colorimetry based on IEC 61966-2-5 [33] */
> > + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
> > + /* Colorimetry based on ITU-R BT.2020 */
> > + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> > + /* Colorimetry based on ITU-R BT.2020 */
> > + { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> > + /*
> > +* Colorimetry based on Digital Imaging and Communications in
> > Medicine
> > +* (DICOM) Part 14: Grayscale Standard Display Function
> > +*/
> > + { DRM_MODE_COLORIMETRY_Y_ONLY_DICOM_P14_GRAYSCALE,
> > "Y_ONLY_DICOM_Part_14_Grayscale" },
> > + { DRM_MODE_COLORIMETRY_RAW_CUSTOM_COLOR_PROFILE,
> > "Raw_Custom_Color_Profile" },
>
> And these last two seem rather esoteric as well. I don't think any
> driver supports RAW/Y stuff so I'd drop them too.
>
Ville, thank you for reviewing and check in detail.
I'll drop them which you commented.
> > +};
> > +
> > /**
> > * DOC: standard connector properties
> > *
> > @@ -1674,7 +1715,6 @@
> > EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
> > * DOC: standard connector properties
> > *
> > * Colorspace:
> > - * drm_mode_create_colorspace_property - create colorspace
> > property
> > * This property helps select a suitable colorspace based on
> > the sink
> > * capability.
Re: [Intel-gfx] [PATCH 2/3] drm/i915/perf: Add support for report sizes that are not power of 2
On Sun, 15 Sep 2019 04:24:41 -0700, Lionel Landwerlin wrote: > > On 14/09/2019 02:06, Umesh Nerlige Ramappa wrote: > > OA perf unit supports non-power of 2 report sizes. Enable support for > > these sizes in the driver. > > > > Signed-off-by: Umesh Nerlige Ramappa > > --- > > drivers/gpu/drm/i915/i915_perf.c | 59 > > 1 file changed, 21 insertions(+), 38 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_perf.c > > b/drivers/gpu/drm/i915/i915_perf.c > > index 50b6d154fd46..482fca3da7de 100644 > > --- a/drivers/gpu/drm/i915/i915_perf.c > > +++ b/drivers/gpu/drm/i915/i915_perf.c > > @@ -450,7 +450,7 @@ static bool oa_buffer_check_unlocked(struct > > i915_perf_stream *stream) > > u32 gtt_offset = i915_ggtt_offset(stream->oa_buffer.vma); > > int report_size = stream->oa_buffer.format_size; > > unsigned long flags; > > - u32 hw_tail; > > + u32 hw_tail, aging_tail; > > u64 now; > > /* We have to consider the (unlikely) possibility that read() > > errors > > @@ -459,16 +459,17 @@ static bool oa_buffer_check_unlocked(struct > > i915_perf_stream *stream) > > */ > > spin_lock_irqsave(>oa_buffer.ptr_lock, flags); > > - hw_tail = dev_priv->perf.ops.oa_hw_tail_read(stream); > > + hw_tail = dev_priv->perf.ops.oa_hw_tail_read(stream) - gtt_offset; > > + aging_tail = stream->oa_buffer.aging_tail - gtt_offset; > > /* The tail pointer increases in 64 byte increments, > > * not in report_size steps... > > */ > > - hw_tail &= ~(report_size - 1); > > + hw_tail = OA_TAKEN(hw_tail, (OA_TAKEN(hw_tail, aging_tail) % > > report_size)); > > > I'm struggling to parse this line above and I'm not 100% sure it's correct. > > Could add a comment to explain what is going on? Also for efficiency perhaps the modulo (%) should be replaced by a increment, compare and wraparound? Thanks! -- Ashutosh ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: introduce INTEL_DISPLAY_ENABLED()
On Fri, 13 Sep 2019, Jani Nikula wrote:
> Prepare for making a distinction between not having display and having
> disabled display. Add INTEL_DISPLAY_ENABLED() and use it where
> HAS_DISPLAY() is used after intel_device_info_runtime_init(). This is
> initially duplication, as disabling display still leads to ->pipe_mask =
> 0 and HAS_DISPLAY() being false.
>
> Note that ever since i915.display_disable was introduced, it has not
> affected PCH detection even if it uses HAS_DISPLAY(), as display disable
> happens after that.
>
> Since INTEL_DISPLAY_ENABLED() will not make sense unless HAS_DISPLAY()
> is true, include a warning for catching misuses making decisions on
> INTEL_DISPLAY_ENABLED() when HAS_DISPLAY() is false.
>
> v2: Remove INTEL_DISPLAY_ENABLED() check from intel_detect_pch() (Chris)
Pushed, thanks for the review.
BR,
Jani.
>
> Cc: Chris Wilson
> Cc: José Roberto de Souza
> Cc: Ville Syrjälä
> Reviewed-by: José Roberto de Souza
> Acked-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_bios.c| 2 +-
> drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_fbdev.c | 2 +-
> drivers/gpu/drm/i915/display/intel_gmbus.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.c | 8
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> 6 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index efb39f350b19..1def550c68c8 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1833,7 +1833,7 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
> const struct bdb_header *bdb;
> u8 __iomem *bios = NULL;
>
> - if (!HAS_DISPLAY(dev_priv)) {
> + if (!HAS_DISPLAY(dev_priv) || !INTEL_DISPLAY_ENABLED(dev_priv)) {
> DRM_DEBUG_KMS("Skipping VBT init due to disabled display.\n");
> return;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index a19f8c73f2e0..2c0cb32235c0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15366,7 +15366,7 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
>
> intel_pps_init(dev_priv);
>
> - if (!HAS_DISPLAY(dev_priv))
> + if (!HAS_DISPLAY(dev_priv) || !INTEL_DISPLAY_ENABLED(dev_priv))
> return;
>
> if (INTEL_GEN(dev_priv) >= 12) {
> @@ -17273,7 +17273,7 @@ intel_display_capture_error_state(struct
> drm_i915_private *dev_priv)
>
> BUILD_BUG_ON(ARRAY_SIZE(transcoders) != ARRAY_SIZE(error->transcoder));
>
> - if (!HAS_DISPLAY(dev_priv))
> + if (!HAS_DISPLAY(dev_priv) || !INTEL_DISPLAY_ENABLED(dev_priv))
> return NULL;
>
> error = kzalloc(sizeof(*error), GFP_ATOMIC);
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
> b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index d59eee5c5d9c..68338669f054 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -444,7 +444,7 @@ int intel_fbdev_init(struct drm_device *dev)
> struct intel_fbdev *ifbdev;
> int ret;
>
> - if (WARN_ON(!HAS_DISPLAY(dev_priv)))
> + if (WARN_ON(!HAS_DISPLAY(dev_priv) || !INTEL_DISPLAY_ENABLED(dev_priv)))
> return -ENODEV;
>
> ifbdev = kzalloc(sizeof(struct intel_fbdev), GFP_KERNEL);
> diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c
> b/drivers/gpu/drm/i915/display/intel_gmbus.c
> index d6775a005726..3d4d19ac1d14 100644
> --- a/drivers/gpu/drm/i915/display/intel_gmbus.c
> +++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
> @@ -836,7 +836,7 @@ int intel_gmbus_setup(struct drm_i915_private *dev_priv)
> unsigned int pin;
> int ret;
>
> - if (!HAS_DISPLAY(dev_priv))
> + if (!HAS_DISPLAY(dev_priv) || !INTEL_DISPLAY_ENABLED(dev_priv))
> return 0;
>
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 0dfcb40f3162..9904f762f4bb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -338,7 +338,7 @@ static int i915_driver_modeset_probe(struct drm_device
> *dev)
> if (i915_inject_probe_failure(dev_priv))
> return -ENODEV;
>
> - if (HAS_DISPLAY(dev_priv)) {
> + if (HAS_DISPLAY(dev_priv) && INTEL_DISPLAY_ENABLED(dev_priv)) {
> ret = drm_vblank_init(_priv->drm,
> INTEL_NUM_PIPES(dev_priv));
> if (ret)
> @@ -389,7 +389,7 @@ static int i915_driver_modeset_probe(struct drm_device
> *dev)
>
> intel_overlay_setup(dev_priv);
>
> - if (!HAS_DISPLAY(dev_priv))
> + if
Re: [Intel-gfx] drivers/gpu/drm/i915/display/intel_display.c:3934 skl_plane_stride() error: testing array offset 'color_plane' after use.
On Sat, 14 Sep 2019, Dan Carpenter wrote:
> tree:
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: a7f89616b7376495424f682b6086e0c391a89a1d
> commit: df0566a641f959108c152be748a0a58794280e0e drm/i915: move modesetting
> core code under display/
> date: 3 months ago
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot
> Reported-by: Dan Carpenter
>
> New smatch warnings:
> drivers/gpu/drm/i915/display/intel_display.c:3934 skl_plane_stride() error:
> testing array offset 'color_plane' after use.
> drivers/gpu/drm/i915/display/intel_display.c:16328 intel_sanitize_encoder()
> error: we previously assumed 'crtc' could be null (see line 16318)
Odd, what changed to provoke the warnings now? Or is the smatch test
new?
Anyway, Cc: Ville & intel-gfx.
BR,
Jani.
>
> git remote add linus
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
> git remote update linus
> git checkout df0566a641f959108c152be748a0a58794280e0e
> vim +/color_plane +3934 drivers/gpu/drm/i915/display/intel_display.c
>
> b3cf5c06ca5001 drivers/gpu/drm/i915/intel_display.c Ville Syrjälä 2018-09-25
> 3926
> df79cf44191029 drivers/gpu/drm/i915/intel_display.c Ville Syrjälä 2018-09-11
> 3927 u32 skl_plane_stride(const struct intel_plane_state *plane_state,
> 5d2a19507cb665 drivers/gpu/drm/i915/intel_display.c Ville Syrjälä 2018-09-07
> 3928 int color_plane)
> d21967740f4b7d drivers/gpu/drm/i915/intel_display.c Ville Syrjälä 2016-01-28
> 3929 {
> df79cf44191029 drivers/gpu/drm/i915/intel_display.c Ville Syrjälä 2018-09-11
> 3930const struct drm_framebuffer *fb = plane_state->base.fb;
> df79cf44191029 drivers/gpu/drm/i915/intel_display.c Ville Syrjälä 2018-09-11
> 3931unsigned int rotation = plane_state->base.rotation;
> 5d2a19507cb665 drivers/gpu/drm/i915/intel_display.c Ville Syrjälä 2018-09-07
> 3932u32 stride = plane_state->color_plane[color_plane].stride;
>
> ^^^
> Out of bounds read?
>
> 1b500535c513ac drivers/gpu/drm/i915/intel_display.c Ville Syrjälä 2017-03-07
> 3933
> 5d2a19507cb665 drivers/gpu/drm/i915/intel_display.c Ville Syrjälä 2018-09-07
> @3934if (color_plane >= fb->format->num_planes)
>
> ^
> Tested too late.
>
> 1b500535c513ac drivers/gpu/drm/i915/intel_display.c Ville Syrjälä 2017-03-07
> 3935return 0;
> 1b500535c513ac drivers/gpu/drm/i915/intel_display.c Ville Syrjälä 2017-03-07
> 3936
> b3cf5c06ca5001 drivers/gpu/drm/i915/intel_display.c Ville Syrjälä 2018-09-25
> 3937return stride / skl_plane_stride_mult(fb, color_plane, rotation);
> d21967740f4b7d drivers/gpu/drm/i915/intel_display.c Ville Syrjälä 2016-01-28
> 3938 }
> d21967740f4b7d drivers/gpu/drm/i915/intel_display.c Ville Syrjälä 2016-01-28
> 3939
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] dma-fence: Serialise signal enabling (dma_fence_enable_sw_signaling)
== Series Details == Series: series starting with [1/2] dma-fence: Serialise signal enabling (dma_fence_enable_sw_signaling) URL : https://patchwork.freedesktop.org/series/66726/ State : success == Summary == CI Bug Log - changes from CI_DRM_6896_full -> Patchwork_14415_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14415_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@in-order-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-iclb3/igt@gem_exec_sched...@in-order-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14415/shard-iclb2/igt@gem_exec_sched...@in-order-bsd.html * igt@gem_exec_schedule@preempt-other-bsd1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +15 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-iclb1/igt@gem_exec_sched...@preempt-other-bsd1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14415/shard-iclb8/igt@gem_exec_sched...@preempt-other-bsd1.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-apl8/igt@i915_susp...@fence-restore-tiled2untiled.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14415/shard-apl8/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_color@pipe-a-ctm-green-to-red: - shard-skl: [PASS][7] -> [FAIL][8] ([fdo#107201]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-skl10/igt@kms_co...@pipe-a-ctm-green-to-red.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14415/shard-skl9/igt@kms_co...@pipe-a-ctm-green-to-red.html * igt@kms_cursor_crc@pipe-c-cursor-alpha-opaque: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#103232]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-alpha-opaque.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14415/shard-skl10/igt@kms_cursor_...@pipe-c-cursor-alpha-opaque.html * igt@kms_cursor_legacy@pipe-a-forked-bo: - shard-apl: [PASS][11] -> [INCOMPLETE][12] ([fdo#103927]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-apl2/igt@kms_cursor_leg...@pipe-a-forked-bo.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14415/shard-apl1/igt@kms_cursor_leg...@pipe-a-forked-bo.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#105363]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-skl3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14415/shard-skl5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-blt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14415/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-blt.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14415/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [fdo#110403]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14415/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103166]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-iclb3/igt@kms_plane_low...@pipe-a-tiling-y.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14415/shard-iclb6/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109642] / [fdo#111068]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-iclb2/igt@kms_psr2_su@page_flip.html [24]:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Show the logical context ring state on dumping
== Series Details == Series: series starting with [1/2] drm/i915: Show the logical context ring state on dumping URL : https://patchwork.freedesktop.org/series/66729/ State : success == Summary == CI Bug Log - changes from CI_DRM_6896_full -> Patchwork_14416_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_6896_full and Patchwork_14416_full: ### New IGT tests (1) ### * igt@i915_selftest@live_gt_lrc: - Statuses : 6 pass(s) - Exec time: [0.41, 2.06] s Known issues Here are the changes found in Patchwork_14416_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@preempt-bsd1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) +15 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-iclb1/igt@gem_exec_sched...@preempt-bsd1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14416/shard-iclb8/igt@gem_exec_sched...@preempt-bsd1.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +6 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-iclb3/igt@gem_exec_sched...@preempt-other-chain-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14416/shard-iclb4/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-apl8/igt@i915_susp...@fence-restore-tiled2untiled.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14416/shard-apl6/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_color@pipe-a-ctm-green-to-red: - shard-skl: [PASS][7] -> [FAIL][8] ([fdo#107201]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-skl10/igt@kms_co...@pipe-a-ctm-green-to-red.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14416/shard-skl7/igt@kms_co...@pipe-a-ctm-green-to-red.html * igt@kms_cursor_crc@pipe-b-cursor-256x85-sliding: - shard-apl: [PASS][9] -> [INCOMPLETE][10] ([fdo#103927]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-apl4/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14416/shard-apl1/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html * igt@kms_cursor_crc@pipe-c-cursor-alpha-opaque: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#103232]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-alpha-opaque.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14416/shard-skl10/igt@kms_cursor_...@pipe-c-cursor-alpha-opaque.html * igt@kms_flip@dpms-vs-vblank-race-interruptible: - shard-apl: [PASS][13] -> [FAIL][14] ([fdo#111609]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-apl4/igt@kms_f...@dpms-vs-vblank-race-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14416/shard-apl4/igt@kms_f...@dpms-vs-vblank-race-interruptible.html * igt@kms_flip@flip-vs-suspend: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#109507]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-skl1/igt@kms_f...@flip-vs-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14416/shard-skl9/igt@kms_f...@flip-vs-suspend.html * igt@kms_flip@modeset-vs-vblank-race: - shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([fdo#107713]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-iclb4/igt@kms_f...@modeset-vs-vblank-race.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14416/shard-iclb7/igt@kms_f...@modeset-vs-vblank-race.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-blt: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-blt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14416/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-blt.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([fdo#104108]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-skl9/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14416/shard-skl5/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html *
Re: [Intel-gfx] drivers/gpu/drm/i915/display/intel_display.c:3934 skl_plane_stride() error: testing array offset 'color_plane' after use.
On Mon, Sep 16, 2019 at 10:31:35AM +0300, Jani Nikula wrote: > On Sat, 14 Sep 2019, Dan Carpenter wrote: > > tree: > > https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git > > master > > head: a7f89616b7376495424f682b6086e0c391a89a1d > > commit: df0566a641f959108c152be748a0a58794280e0e drm/i915: move modesetting > > core code under display/ > > date: 3 months ago > > > > If you fix the issue, kindly add following tag > > Reported-by: kbuild test robot > > Reported-by: Dan Carpenter > > > > New smatch warnings: > > drivers/gpu/drm/i915/display/intel_display.c:3934 skl_plane_stride() error: > > testing array offset 'color_plane' after use. > > drivers/gpu/drm/i915/display/intel_display.c:16328 intel_sanitize_encoder() > > error: we previously assumed 'crtc' could be null (see line 16318) > > Odd, what changed to provoke the warnings now? Or is the smatch test > new? > It looks like the cross function DB is out of data slightly. Maybe because the file moved? On my system Smatch knows that color_plane is 0-1 and plane_state->color_plane[] is a two element array so it doesn't print the warning. This is just a sanity check which is never triggered. Should the sanity check be move? What was originally intended? It's hard to say. regards, dan carpenter ___ 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/selftests: Exercise CS TLB invalidation
== Series Details == Series: drm/i915/selftests: Exercise CS TLB invalidation URL : https://patchwork.freedesktop.org/series/66718/ State : success == Summary == CI Bug Log - changes from CI_DRM_6896_full -> Patchwork_14414_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14414_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-apl6/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14414/shard-apl1/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_eio@in-flight-immediate: - shard-glk: [PASS][3] -> [FAIL][4] ([fdo#105957]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-glk1/igt@gem_...@in-flight-immediate.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14414/shard-glk8/igt@gem_...@in-flight-immediate.html * igt@gem_exec_parallel@basic: - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-iclb5/igt@gem_exec_paral...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14414/shard-iclb7/igt@gem_exec_paral...@basic.html * igt@gem_exec_schedule@fifo-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#111325]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-iclb6/igt@gem_exec_sched...@fifo-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14414/shard-iclb1/igt@gem_exec_sched...@fifo-bsd.html * igt@gem_exec_schedule@preempt-other-bsd1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +23 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-iclb1/igt@gem_exec_sched...@preempt-other-bsd1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14414/shard-iclb7/igt@gem_exec_sched...@preempt-other-bsd1.html * igt@kms_color@pipe-a-ctm-green-to-red: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#107201]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-skl10/igt@kms_co...@pipe-a-ctm-green-to-red.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14414/shard-skl2/igt@kms_co...@pipe-a-ctm-green-to-red.html * igt@kms_cursor_crc@pipe-c-cursor-alpha-opaque: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#103232]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-alpha-opaque.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14414/shard-skl4/igt@kms_cursor_...@pipe-c-cursor-alpha-opaque.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][15] -> [FAIL][16] ([fdo#105767]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14414/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_cursor_legacy@pipe-a-forked-bo: - shard-apl: [PASS][17] -> [INCOMPLETE][18] ([fdo#103927]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-apl2/igt@kms_cursor_leg...@pipe-a-forked-bo.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14414/shard-apl1/igt@kms_cursor_leg...@pipe-a-forked-bo.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14414/shard-iclb3/igt@kms_frontbuffer_track...@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-rte: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103167] / [fdo#110378]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-rte.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14414/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-rte.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6896/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14414/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb:
Re: [Intel-gfx] [PATCH 07/14] drm/i915/tgl: Add support for dkl pll write
On Fri, 13 Sep 2019, Lucas De Marchi wrote:
> On Fri, Sep 13, 2019 at 3:33 PM José Roberto de Souza
> wrote:
>>
>> From: Vandita Kulkarni
>>
>> Add a new function to write to dkl phy pll registers. As per the
>> bspec all the registers are read modify write.
>>
>> Signed-off-by: Vandita Kulkarni
>> Signed-off-by: José Roberto de Souza
>> Signed-off-by: Lucas De Marchi
>> ---
>> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 65 ++-
>> 1 file changed, 64 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>> index 424f9213c80d..afc9b609b63d 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>> @@ -3293,7 +3293,70 @@ static void icl_mg_pll_write(struct drm_i915_private
>> *dev_priv,
>> static void dkl_pll_write(struct drm_i915_private *dev_priv,
>> struct intel_shared_dpll *pll)
>> {
>> - /* TODO */
>> + struct intel_dpll_hw_state *hw_state = >state.hw_state;
>> + enum tc_port tc_port = icl_pll_id_to_tc_port(pll->info->id);
>> + u32 val;
>> +
>> + /*
>> +* All registers programmed here have the same HIP_INDEX_REG even
>> +* though on different building block
>> +*/
>> + I915_WRITE(HIP_INDEX_REG(tc_port), 0x2);
>> +
>> + /* All the registers are RMW */
>
> I wish we could use intel_uncore_rmw() here to make this comment go
> away and make it simpler
> in general. But I understand the conversion to use uncore should still
> not be done in display. Should we add
> I195_RMW() meanwhile or it's not worth it? +Jani.
We have tons of code like this in display/ and in the big picture this
makes no difference. Please let's not add I915_RMW or anything such
while we do have a path forward with intel_de_{read,write,rwm}. It just
hasn't happened yet.
BR,
Jani.
>
> Lucas De Marchi
>
>> + val = I915_READ(DKL_REFCLKIN_CTL(tc_port));
>> + val &= ~MG_REFCLKIN_CTL_OD_2_MUX_MASK;
>> + val |= hw_state->mg_refclkin_ctl;
>> + I915_WRITE(DKL_REFCLKIN_CTL(tc_port), val);
>> +
>> + val = I915_READ(DKL_CLKTOP2_CORECLKCTL1(tc_port));
>> + val &= ~MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK;
>> + val |= hw_state->mg_clktop2_coreclkctl1;
>> + I915_WRITE(DKL_CLKTOP2_CORECLKCTL1(tc_port), val);
>> +
>> + val = I915_READ(DKL_CLKTOP2_HSCLKCTL(tc_port));
>> + val &= ~(MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL_MASK |
>> + MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL_MASK |
>> + MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK |
>> + MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK);
>> + val |= hw_state->mg_clktop2_hsclkctl;
>> + I915_WRITE(DKL_CLKTOP2_HSCLKCTL(tc_port), val);
>> +
>> + val = I915_READ(DKL_PLL_DIV0(tc_port));
>> + val &= ~(DKL_PLL_DIV0_INTEG_COEFF_MASK |
>> + DKL_PLL_DIV0_PROP_COEFF_MASK |
>> + DKL_PLL_DIV0_FBPREDIV_MASK |
>> + DKL_PLL_DIV0_FBDIV_INT_MASK);
>> + val |= hw_state->mg_pll_div0;
>> + I915_WRITE(DKL_PLL_DIV0(tc_port), val);
>> +
>> + val = I915_READ(DKL_PLL_DIV1(tc_port));
>> + val &= ~(DKL_PLL_DIV1_IREF_TRIM_MASK |
>> +DKL_PLL_DIV1_TDC_TARGET_CNT_MASK);
>> + val |= hw_state->mg_pll_div1;
>> + I915_WRITE(DKL_PLL_DIV1(tc_port), val);
>> +
>> + val = I915_READ(DKL_PLL_SSC(tc_port));
>> + val &= ~(DKL_PLL_SSC_IREF_NDIV_RATIO_MASK |
>> + DKL_PLL_SSC_STEP_LEN_MASK |
>> + DKL_PLL_SSC_STEP_NUM_MASK |
>> + DKL_PLL_SSC_EN);
>> + val |= hw_state->mg_pll_ssc;
>> + I915_WRITE(DKL_PLL_SSC(tc_port), val);
>> +
>> + val = I915_READ(DKL_PLL_BIAS(tc_port));
>> + val &= ~(DKL_PLL_BIAS_FRAC_EN_H |
>> + DKL_PLL_BIAS_FBDIV_FRAC_MASK);
>> + val |= hw_state->mg_pll_bias;
>> + I915_WRITE(DKL_PLL_BIAS(tc_port), val);
>> +
>> + val = I915_READ(DKL_PLL_TDC_COLDST_BIAS(tc_port));
>> + val &= ~(DKL_PLL_TDC_SSC_STEP_SIZE_MASK |
>> + DKL_PLL_TDC_FEED_FWD_GAIN_MASK);
>> + val |= hw_state->mg_pll_tdc_coldst_bias;
>> + I915_WRITE(DKL_PLL_TDC_COLDST_BIAS(tc_port), val);
>> +
>> + POSTING_READ(DKL_PLL_TDC_COLDST_BIAS(tc_port));
>> }
>>
>> static void icl_pll_power_enable(struct drm_i915_private *dev_priv,
>> --
>> 2.23.0
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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] [PATCH 2/9] drm/print: add drm_debug_enabled()
On Fri, 13 Sep 2019, Eric Engestrom wrote:
> On Friday, 2019-09-13 14:51:39 +0300, Jani Nikula wrote:
>> Add helper to check if a drm debug category is enabled. Convert drm core
>> to use it. No functional changes.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
>> drivers/gpu/drm/drm_dp_mst_topology.c | 6 +++---
>> drivers/gpu/drm/drm_edid.c| 2 +-
>> drivers/gpu/drm/drm_edid_load.c | 2 +-
>> drivers/gpu/drm/drm_mipi_dbi.c| 4 ++--
>> drivers/gpu/drm/drm_print.c | 4 ++--
>> drivers/gpu/drm/drm_vblank.c | 6 +++---
>> include/drm/drm_print.h | 5 +
>> 8 files changed, 18 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> b/drivers/gpu/drm/drm_atomic_uapi.c
>> index 5a5b42db6f2a..6576cd997cbd 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -1406,7 +1406,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
>> ret = drm_atomic_nonblocking_commit(state);
>> } else {
>> -if (unlikely(drm_debug & DRM_UT_STATE))
>> +if (unlikely(drm_debug_enabled(DRM_UT_STATE)))
>> drm_atomic_print_state(state);
>>
>> ret = drm_atomic_commit(state);
>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
>> b/drivers/gpu/drm/drm_dp_mst_topology.c
>> index 97216099a718..f47c5b6b51f7 100644
>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
>> @@ -1180,7 +1180,7 @@ static int drm_dp_mst_wait_tx_reply(struct
>> drm_dp_mst_branch *mstb,
>> }
>> }
>> out:
>> -if (unlikely(ret == -EIO && drm_debug & DRM_UT_DP)) {
>> +if (unlikely(ret == -EIO && drm_debug_enabled(DRM_UT_DP))) {
>> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>>
>> drm_dp_mst_dump_sideband_msg_tx(, txmsg);
>> @@ -2321,7 +2321,7 @@ static int process_single_tx_qlock(struct
>> drm_dp_mst_topology_mgr *mgr,
>> idx += tosend + 1;
>>
>> ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx);
>> -if (unlikely(ret && drm_debug & DRM_UT_DP)) {
>> +if (unlikely(ret && drm_debug_enabled(DRM_UT_DP))) {
>> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>>
>> drm_printf(, "sideband msg failed to send\n");
>> @@ -2388,7 +2388,7 @@ static void drm_dp_queue_down_tx(struct
>> drm_dp_mst_topology_mgr *mgr,
>> mutex_lock(>qlock);
>> list_add_tail(>next, >tx_msg_downq);
>>
>> -if (unlikely(drm_debug & DRM_UT_DP)) {
>> +if (unlikely(drm_debug_enabled(DRM_UT_DP))) {
>> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>>
>> drm_dp_mst_dump_sideband_msg_tx(, txmsg);
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 12c783f4d956..58dad4d24cd4 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -1551,7 +1551,7 @@ static void connector_bad_edid(struct drm_connector
>> *connector,
>> {
>> int i;
>>
>> -if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
>> +if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS))
>> return;
>>
>> dev_warn(connector->dev->dev,
>> diff --git a/drivers/gpu/drm/drm_edid_load.c
>> b/drivers/gpu/drm/drm_edid_load.c
>> index d38b3b255926..37d8ba3ddb46 100644
>> --- a/drivers/gpu/drm/drm_edid_load.c
>> +++ b/drivers/gpu/drm/drm_edid_load.c
>> @@ -175,7 +175,7 @@ static void *edid_load(struct drm_connector *connector,
>> const char *name,
>> u8 *edid;
>> int fwsize, builtin;
>> int i, valid_extensions = 0;
>> -bool print_bad_edid = !connector->bad_edid_counter || (drm_debug &
>> DRM_UT_KMS);
>> +bool print_bad_edid = !connector->bad_edid_counter ||
>> drm_debug_enabled(DRM_UT_KMS);
>>
>> builtin = match_string(generic_edid_name, GENERIC_EDIDS, name);
>> if (builtin >= 0) {
>> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
>> index f8154316a3b0..ccfb5b33c5e3 100644
>> --- a/drivers/gpu/drm/drm_mipi_dbi.c
>> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
>> @@ -783,7 +783,7 @@ static int mipi_dbi_spi1e_transfer(struct mipi_dbi *dbi,
>> int dc,
>> int i, ret;
>> u8 *dst;
>>
>> -if (drm_debug & DRM_UT_DRIVER)
>> +if (drm_debug_enabled(DRM_UT_DRIVER))
>> pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
>> __func__, dc, max_chunk);
>>
>> @@ -907,7 +907,7 @@ static int mipi_dbi_spi1_transfer(struct mipi_dbi *dbi,
>> int dc,
>> max_chunk = dbi->tx_buf9_len;
>> dst16 = dbi->tx_buf9;
>>
>> -if (drm_debug & DRM_UT_DRIVER)
>> +if (drm_debug_enabled(DRM_UT_DRIVER))
>> pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
>> __func__, dc,
[Intel-gfx] [RESEND] drm/i915: stop conflating HAS_DISPLAY() and disabled display
Stop setting ->pipe_mask to zero when display is disabled, allowing us
to have different code paths for not actually having display hardware,
and having display hardware disabled. This lets us develop those two
avenues independently.
There are no functional changes for when there is no display. However,
all uses of for_each_pipe() and for_each_pipe_masked() will start
running for the disabled display case. Put one of the more significant
ones behind checks for INTEL_DISPLAY_ENABLED(), otherwise the cases
should not be hit with disabled display, or they seem benign. Fingers
crossed.
All in all, this might not be the ideal solution. In fact we may have
had something along the lines of this in the past, but we ended up
conflating the two cases. Possibly even by recommendation by yours
truly; I did not dare dig up that part of the history. But the perfect
is the enemy of the good, this is a straightforward change, and lets us
get actual work done in both fronts without interfering with each other.
Cc: Chris Wilson
Cc: José Roberto de Souza
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 12 +++-
drivers/gpu/drm/i915/intel_device_info.c | 8 ++--
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e75945a53e06..ac24f96582ca 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16281,11 +16281,13 @@ int intel_modeset_init(struct drm_device *dev)
INTEL_NUM_PIPES(dev_priv),
INTEL_NUM_PIPES(dev_priv) > 1 ? "s" : "");
- for_each_pipe(dev_priv, pipe) {
- ret = intel_crtc_init(dev_priv, pipe);
- if (ret) {
- drm_mode_config_cleanup(dev);
- return ret;
+ if (HAS_DISPLAY(dev_priv) && INTEL_DISPLAY_ENABLED(dev_priv)) {
+ for_each_pipe(dev_priv, pipe) {
+ ret = intel_crtc_init(dev_priv, pipe);
+ if (ret) {
+ drm_mode_config_cleanup(dev);
+ return ret;
+ }
}
}
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 727089dcd280..728c881718a2 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -894,12 +894,8 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
runtime->num_sprites[pipe] = 1;
}
- if (i915_modparams.disable_display) {
- DRM_INFO("Display disabled (module parameter)\n");
- info->pipe_mask = 0;
- } else if (HAS_DISPLAY(dev_priv) &&
- (IS_GEN_RANGE(dev_priv, 7, 8)) &&
- HAS_PCH_SPLIT(dev_priv)) {
+ if (HAS_DISPLAY(dev_priv) && IS_GEN_RANGE(dev_priv, 7, 8) &&
+ HAS_PCH_SPLIT(dev_priv)) {
u32 fuse_strap = I915_READ(FUSE_STRAP);
u32 sfuse_strap = I915_READ(SFUSE_STRAP);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt/kms_frontbuffer_tracking: Skip over IGT_DRAW_BLT when there's no BLT
On Sun, Sep 15, 2019 at 10:39:48AM +0100, Chris Wilson wrote:
> If the blitter is not available, we cannot use it as a source for dirty
> rectangles. We shall have to rely on the other engines to create GPU
> dirty instead.
>
> v2: Try using lots of subgroup+fixtures
>
> Signed-off-by: Chris Wilson
Reviewed-by: Petri Latvala
> ---
> tests/kms_frontbuffer_tracking.c | 58 ++--
> 1 file changed, 56 insertions(+), 2 deletions(-)
>
> diff --git a/tests/kms_frontbuffer_tracking.c
> b/tests/kms_frontbuffer_tracking.c
> index c788b59ee..eaa4b6ef1 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -3022,6 +3022,9 @@ static void basic_subtest(const struct test_mode *t)
> fb1 = params->primary.fb;
>
> for (r = 0, method = 0; method < IGT_DRAW_METHOD_COUNT; method++, r++) {
> + if (method == IGT_DRAW_BLT && !gem_has_blitter(drm.fd))
> + continue;
> +
> if (r == pattern->n_rects) {
> params->primary.fb = (params->primary.fb == fb1) ?
> : fb1;
>
> @@ -3248,10 +3251,11 @@ static const char *flip_str(enum flip_type flip)
> continue; \
> if (!opt.show_hidden && t.fbs == FBS_SHARED && \
> (t.plane == PLANE_CUR || t.plane == PLANE_SPR))\
> - continue;
> + continue; \
> + igt_subtest_group {
>
>
> -#define TEST_MODE_ITER_END } } } } } }
> +#define TEST_MODE_ITER_END } } } } } } }
>
> struct option long_options[] = {
> { "no-status-check", 0, 0, 's'},
> @@ -3297,6 +3301,10 @@ igt_main_args("", long_options, help_str, opt_handler,
> NULL)
> }
>
> TEST_MODE_ITER_BEGIN(t)
> + igt_fixture {
> + if (t.method == IGT_DRAW_BLT)
> + gem_require_blitter(drm.fd);
> + }
> igt_subtest_f("%s-%s-%s-%s-%s-draw-%s",
> feature_str(t.feature),
> pipes_str(t.pipes),
> @@ -3313,6 +3321,11 @@ igt_main_args("", long_options, help_str, opt_handler,
> NULL)
> (!opt.show_hidden && t.method != IGT_DRAW_BLT))
> continue;
>
> + igt_fixture {
> + if (t.method == IGT_DRAW_BLT)
> + gem_require_blitter(drm.fd);
> + }
> +
> for (t.flip = 0; t.flip < FLIP_COUNT; t.flip++)
> igt_subtest_f("%s-%s-%s-%s-%sflip-%s",
> feature_str(t.feature),
> @@ -3331,6 +3344,11 @@ igt_main_args("", long_options, help_str, opt_handler,
> NULL)
> (t.feature & FEATURE_FBC) == 0)
> continue;
>
> + igt_fixture {
> + if (t.method == IGT_DRAW_BLT)
> + gem_require_blitter(drm.fd);
> + }
> +
> igt_subtest_f("%s-%s-%s-fliptrack",
> feature_str(t.feature),
> pipes_str(t.pipes),
> @@ -3344,6 +3362,11 @@ igt_main_args("", long_options, help_str, opt_handler,
> NULL)
> t.plane == PLANE_PRI)
> continue;
>
> + igt_fixture {
> + if (t.method == IGT_DRAW_BLT)
> + gem_require_blitter(drm.fd);
> + }
> +
> igt_subtest_f("%s-%s-%s-%s-%s-move",
> feature_str(t.feature),
> pipes_str(t.pipes),
> @@ -3367,6 +3390,11 @@ igt_main_args("", long_options, help_str, opt_handler,
> NULL)
> t.plane != PLANE_SPR)
> continue;
>
> + igt_fixture {
> + if (t.method == IGT_DRAW_BLT)
> + gem_require_blitter(drm.fd);
> + }
> +
> igt_subtest_f("%s-%s-%s-%s-%s-fullscreen",
> feature_str(t.feature),
> pipes_str(t.pipes),
> @@ -3383,6 +3411,11 @@ igt_main_args("", long_options, help_str, opt_handler,
> NULL)
> (!opt.show_hidden && t.fbs != FBS_INDIVIDUAL))
> continue;
>
> + igt_fixture {
> + if (t.method == IGT_DRAW_BLT)
> + gem_require_blitter(drm.fd);
> + }
> +
> igt_subtest_f("%s-%s-%s-%s-multidraw",
> feature_str(t.feature),
> pipes_str(t.pipes),
> @@ -3399,6 +3432,11 @@ igt_main_args("", long_options, help_str, opt_handler,
> NULL)
> t.method != IGT_DRAW_MMAP_GTT)
> continue;
>
> + igt_fixture {
> +
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Verify the engine after acquiring the active.lock
== Series Details ==
Series: drm/i915: Verify the engine after acquiring the active.lock
URL : https://patchwork.freedesktop.org/series/66753/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6898 -> Patchwork_14419
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14419 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14419, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14419/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14419:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-8700k: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6898/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14419/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
Known issues
Here are the changes found in Patchwork_14419 that come from known issues:
### IGT changes ###
Issues hit
* igt@core_auth@basic-auth:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6898/fi-icl-u3/igt@core_a...@basic-auth.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14419/fi-icl-u3/igt@core_a...@basic-auth.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#111407])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6898/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14419/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_basic@create-fd-close:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6898/fi-icl-u3/igt@gem_ba...@create-fd-close.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14419/fi-icl-u3/igt@gem_ba...@create-fd-close.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6898/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14419/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live_execlists:
- fi-icl-u2: [INCOMPLETE][11] ([fdo#107713]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6898/fi-icl-u2/igt@i915_selftest@live_execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14419/fi-icl-u2/igt@i915_selftest@live_execlists.html
* igt@kms_addfb_basic@invalid-set-prop-any:
- {fi-icl-dsi}: [DMESG-WARN][13] ([fdo#106107]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6898/fi-icl-dsi/igt@kms_addfb_ba...@invalid-set-prop-any.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14419/fi-icl-dsi/igt@kms_addfb_ba...@invalid-set-prop-any.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][15] ([fdo#102614]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6898/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14419/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
{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#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111562]: https://bugs.freedesktop.org/show_bug.cgi?id=111562
[fdo#111597]: https://bugs.freedesktop.org/show_bug.cgi?id=111597
Participating hosts (55 -> 48)
--
Additional (1): fi-hsw-4770r
Missing(8): fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6898 -> Patchwork_14419
CI-20190529: 20190529
CI_DRM_6898:
Re: drivers/gpu/drm/i915/display/intel_display.c:3934 skl_plane_stride() error: testing array offset 'color_plane' after use.
On Mon, Sep 16, 2019 at 10:59:13AM +0300, Dan Carpenter wrote: > On Mon, Sep 16, 2019 at 10:31:35AM +0300, Jani Nikula wrote: > > On Sat, 14 Sep 2019, Dan Carpenter wrote: > > > tree: > > > https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git > > > master > > > head: a7f89616b7376495424f682b6086e0c391a89a1d > > > commit: df0566a641f959108c152be748a0a58794280e0e drm/i915: move > > > modesetting core code under display/ > > > date: 3 months ago > > > > > > If you fix the issue, kindly add following tag > > > Reported-by: kbuild test robot > > > Reported-by: Dan Carpenter > > > > > > New smatch warnings: > > > drivers/gpu/drm/i915/display/intel_display.c:3934 skl_plane_stride() > > > error: testing array offset 'color_plane' after use. The code looks fine to me. int color_plane is 0 or 1 so we know the color_plane[] array is has enough elements. But if fb->num_planes==1 we don't actually want to look at color_plane[1]. > > > drivers/gpu/drm/i915/display/intel_display.c:16328 > > > intel_sanitize_encoder() error: we previously assumed 'crtc' could be > > > null (see line 16318) If crtc_state!=NULL then crtc!=NULL. Looks safe to me. > > > > Odd, what changed to provoke the warnings now? Or is the smatch test > > new? > > > > It looks like the cross function DB is out of data slightly. Maybe > because the file moved? On my system Smatch knows that color_plane is > 0-1 and plane_state->color_plane[] is a two element array so it doesn't > print the warning. > > This is just a sanity check which is never triggered. Should the sanity > check be move? What was originally intended? It's hard to say. > > regards, > dan carpenter -- Ville Syrjälä Intel
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: stop conflating HAS_DISPLAY() and disabled display
== Series Details == Series: drm/i915: stop conflating HAS_DISPLAY() and disabled display URL : https://patchwork.freedesktop.org/series/66749/ State : success == Summary == CI Bug Log - changes from CI_DRM_6897_full -> Patchwork_14418_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14418_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-iclb2/igt@gem_exec_balan...@smoke.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/shard-iclb5/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@preempt-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-iclb5/igt@gem_exec_sched...@preempt-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/shard-iclb4/igt@gem_exec_sched...@preempt-bsd.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-kbl: [PASS][5] -> [SKIP][6] ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-kbl1/igt@i915_pm_rc6_reside...@rc6-accuracy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/shard-kbl2/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-apl2/igt@i915_susp...@fence-restore-tiled2untiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/shard-apl2/igt@i915_susp...@fence-restore-tiled2untiled.html - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-kbl3/igt@i915_susp...@fence-restore-tiled2untiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/shard-kbl2/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a: - shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-iclb3/igt@kms_b...@extended-pageflip-modeset-hang-oldfb-render-a.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/shard-iclb7/igt@kms_b...@extended-pageflip-modeset-hang-oldfb-render-a.html * igt@kms_color@pipe-a-ctm-green-to-red: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#107201]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-skl7/igt@kms_co...@pipe-a-ctm-green-to-red.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/shard-skl3/igt@kms_co...@pipe-a-ctm-green-to-red.html * igt@kms_flip@flip-vs-expired-vblank: - shard-glk: [PASS][15] -> [FAIL][16] ([fdo#105363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-glk9/igt@kms_f...@flip-vs-expired-vblank.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/shard-glk1/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-suspend: - shard-hsw: [PASS][17] -> [INCOMPLETE][18] ([fdo#103540]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-hsw8/igt@kms_f...@flip-vs-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/shard-hsw1/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103167] / [fdo#110378]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-iclb5/igt@kms_frontbuffer_track...@fbc-1p-rte.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-rte.html * igt@kms_frontbuffer_tracking@psr-1p-pri-indfb-multidraw: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#103167]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-skl7/igt@kms_frontbuffer_track...@psr-1p-pri-indfb-multidraw.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/shard-skl3/igt@kms_frontbuffer_track...@psr-1p-pri-indfb-multidraw.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][25]
Re: [Intel-gfx] [PATCH 13/21] drm/i915: Pull i915_vma_pin under the vm->mutex
Quoting Tvrtko Ursulin (2019-09-16 11:13:23)
>
> On 02/09/2019 05:02, Chris Wilson wrote:
> > Replace the struct_mutex requirement for pinning the i915_vma with the
> > local vm->mutex instead. Note that the vm->mutex is tainted by the
> > shrinker (we require unbinding from inside fs-reclaim) and so we cannot
> > allocate while holding that mutex. Instead we have to preallocate
> > workers to do allocate and apply the PTE updates after we have we
> > reserved their slot in the drm_mm (using fences to order the PTE writes
> > with the GPU work and with later unbind).
>
> Can you put some paragraphs into the commit describing the
> infrastructure changes? Like changes to active tracker at least.
You mean the addition of the preallocated node?
> Then commentary on effects on shrinker, fences, object management,
> execbuf, basically all major parts of the code which have now been
> fundamentally improved or changed. It would help with review. It's a
> chunky patch/change and I think it needs some theory of operation text.
Off the top of my held, they are all just lock switches. The funky stuff
lies around avoiding introducing a kref for i915_vma and that requires a
whole bunch of trylocks to avoid double-frees. (I did plan on having a
kref here, but that leads to rewriting object page tracking which is in
its own quagmire.)
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> > index f99920652751..9e72b42a86f5 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> > @@ -152,6 +152,17 @@ static void clear_pages_dma_fence_cb(struct dma_fence
> > *fence,
> > irq_work_queue(>irq_work);
> > }
> >
> > +static int move_to_active(struct i915_vma *vma, struct i915_request *rq)
> > +{
> > + int err;
> > +
> > + err = i915_request_await_active(rq, >active);
> > + if (err)
> > + return err;
> > +
> > + return i915_active_ref(>active, rq->timeline, rq);
> > +}
> > +
> > static void clear_pages_worker(struct work_struct *work)
> > {
> > struct clear_pages_work *w = container_of(work, typeof(*w), work);
> > @@ -211,7 +222,7 @@ static void clear_pages_worker(struct work_struct *work)
> >* keep track of the GPU activity within this vma/request, and
> >* propagate the signal from the request to w->dma.
> >*/
> > - err = i915_active_ref(>active, rq->timeline, rq);
> > + err = move_to_active(vma, rq);
>
> What is happening here? It wasn't sufficiently ordered before or
> something changes with this patch?
We are introducing an independent ordering constraints. The clear page
worker is itself interwined with the obj->resv but one part of the
operation must be serialised with the asynchronous binding, and we don't
want that async binding to affect the object globally. So the clear-page
workers opencodes the awaits from i915_vma_move_to_active, but does not
want to partake in the fence export (as the operations is already in the
obj->resv).
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index f1c0e5d958f3..653f7275306a 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -313,8 +313,6 @@ static void i915_gem_context_free(struct
> > i915_gem_context *ctx)
> > GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
> >
> > release_hw_id(ctx);
> > - if (ctx->vm)
> > - i915_vm_put(ctx->vm);
>
> Contexts no longer hold a reference to vm? Only vmas?
Dropped earlier on close rather than final put...
> > @@ -379,9 +377,13 @@ void i915_gem_context_release(struct kref *ref)
> >
> > static void context_close(struct i915_gem_context *ctx)
> > {
> > + i915_gem_context_set_closed(ctx);
> > +
> > + if (ctx->vm)
> > + i915_vm_close(ctx->vm);
>
> But now closed context mean closed vm, but what about shared vms? Is
> open/close_vm now counted?
Yes. vm->open_count. This is all to avoid double-free of the vma from
object-close and vm-close. But closing earlier tidies up the vm release
and restores some earlier behaviour to avoid unbinding from a dead vm.
> > - ret = i915_vma_bind(vma, cache_level, PIN_UPDATE);
> > + /* Wait for an earlier async bind */
> > + ret = i915_active_wait(>active);
> > + if (ret)
> > + return ret;
> > +
> > + ret = i915_vma_bind(vma, cache_level, PIN_UPDATE,
> > NULL);
>
> Waiting should not be implied in the bind? I am assuming at least there
> will be many callers to bind and like this all of them will have to know
> to do i915_active_wait first?
Not really, imo, i915_vma_bind() is a special case as it is the
low-level operation. And we only need the sync here as we plan to
[Intel-gfx] [PATCH] drm/i915: Verify the engine after acquiring the active.lock
When using virtual engines, the rq->engine is not stable until we hold
the engine->active.lock (as the virtual engine may be exchanged with the
sibling). Since commit 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
we may retire a request concurrently with resubmitting it to HW, we need
to be extra careful to verify we are holding the correct lock for the
request's active list. This is similar to the issue we saw with
rescheduling the virtual requests, see sched_lock_engine().
Or else:
<4> [876.736126] list_add corruption. prev->next should be next
(8883f931a1f8), but was dead0100. (prev=888361ffa610).
<4> [876.736136] WARNING: CPU: 2 PID: 21 at lib/list_debug.c:28
__list_add_valid+0x4d/0x70
<4> [876.736137] Modules linked in: i915(+) amdgpu gpu_sched ttm vgem
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp
x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_intel_nhlt
snd_hda_codec snd_hwdep snd_hda_core ghash_clmulni_intel e1000e cdc_ether
usbnet mii snd_pcm ptp pps_core mei_me mei prime_numbers btusb btrtl btbcm
btintel bluetooth ecdh_generic ecc [last unloaded: i915]
<4> [876.736154] CPU: 2 PID: 21 Comm: ksoftirqd/2 Tainted: G U
5.3.0-CI-CI_DRM_6898+ #1
<4> [876.736156] Hardware name: Intel Corporation Ice Lake Client
Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS
ICLSFWR1.R00.3183.A00.1905020411 05/02/2019
<4> [876.736157] RIP: 0010:__list_add_valid+0x4d/0x70
<4> [876.736159] Code: c3 48 89 d1 48 c7 c7 20 33 0e 82 48 89 c2 e8 4a 4a bc ff
0f 0b 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 70 33 0e 82 e8 33 4a bc ff <0f> 0b 31
c0 c3 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 c0 33 0e 82 e8
<4> [876.736160] RSP: 0018:c918bd30 EFLAGS: 00010082
<4> [876.736162] RAX: RBX: 888361ffc840 RCX:
0104
<4> [876.736163] RDX: 8104 RSI: RDI:
<4> [876.736164] RBP: c918bd68 R08: R09:
0001
<4> [876.736165] R10: aed95de3 R11: 7fe927eb R12:
888361ffca10
<4> [876.736166] R13: 888361ffa610 R14: 888361ffc880 R15:
8883f931a1f8
<4> [876.736168] FS: () GS:88849fd0()
knlGS:
<4> [876.736169] CS: 0010 DS: ES: CR0: 80050033
<4> [876.736170] CR2: 7f093a9173c0 CR3: 0003bba08005 CR4:
00760ee0
<4> [876.736171] PKRU: 5554
<4> [876.736172] Call Trace:
<4> [876.736226] __i915_request_submit+0x152/0x370 [i915]
<4> [876.736263] __execlists_submission_tasklet+0x6da/0x1f50 [i915]
<4> [876.736293] ? execlists_submission_tasklet+0x29/0x50 [i915]
<4> [876.736321] execlists_submission_tasklet+0x34/0x50 [i915]
<4> [876.736325] tasklet_action_common.isra.5+0x47/0xb0
<4> [876.736328] __do_softirq+0xd8/0x4ae
<4> [876.736332] ? smpboot_thread_fn+0x23/0x280
<4> [876.736334] ? smpboot_thread_fn+0x6b/0x280
<4> [876.736336] run_ksoftirqd+0x2b/0x50
<4> [876.736338] smpboot_thread_fn+0x1d3/0x280
<4> [876.736341] ? sort_range+0x20/0x20
<4> [876.736343] kthread+0x119/0x130
<4> [876.736345] ? kthread_park+0xa0/0xa0
<4> [876.736347] ret_from_fork+0x24/0x50
<4> [876.736353] irq event stamp: 2290145
<4> [876.736356] hardirqs last enabled at (2290144): []
__slab_free+0x3e8/0x500
<4> [876.736358] hardirqs last disabled at (2290145): []
_raw_spin_lock_irqsave+0xd/0x50
<4> [876.736360] softirqs last enabled at (2290114): []
__do_softirq+0x33e/0x4ae
<4> [876.736361] softirqs last disabled at (2290119): []
run_ksoftirqd+0x2b/0x50
<4> [876.736363] WARNING: CPU: 2 PID: 21 at lib/list_debug.c:28
__list_add_valid+0x4d/0x70
<4> [876.736364] ---[ end trace 3e58d6c7356c65bf ]---
<4> [876.736406] [ cut here ]
<4> [876.736415] list_del corruption. prev->next should be 888361ffca10,
but was 88840ac2c730
<4> [876.736421] WARNING: CPU: 2 PID: 5490 at lib/list_debug.c:53
__list_del_entry_valid+0x79/0x90
<4> [876.736422] Modules linked in: i915(+) amdgpu gpu_sched ttm vgem
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp
x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_intel_nhlt
snd_hda_codec snd_hwdep snd_hda_core ghash_clmulni_intel e1000e cdc_ether
usbnet mii snd_pcm ptp pps_core mei_me mei prime_numbers btusb btrtl btbcm
btintel bluetooth ecdh_generic ecc [last unloaded: i915]
<4> [876.736433] CPU: 2 PID: 5490 Comm: i915_selftest Tainted: G U W
5.3.0-CI-CI_DRM_6898+ #1
<4> [876.736435] Hardware name: Intel Corporation Ice Lake Client
Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS
ICLSFWR1.R00.3183.A00.1905020411 05/02/2019
<4> [876.736436] RIP: 0010:__list_del_entry_valid+0x79/0x90
<4> [876.736438] Code: 0b 31 c0 c3 48 89 fe 48 c7 c7 30 34 0e 82 e8 ae 49 bc ff
0f 0b 31 c0 c3 48 89 f2 48 89 fe 48 c7 c7 68 34 0e 82 e8 97 49 bc ff <0f> 0b 31
c0 c3 48 c7 c7 a8 34 0e 82 e8 86 49 bc ff 0f 0b 31 c0 c3
<4> [876.736439] RSP: 0018:c93ef758 EFLAGS:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Verify the engine after acquiring the active.lock
== Series Details == Series: drm/i915: Verify the engine after acquiring the active.lock URL : https://patchwork.freedesktop.org/series/66753/ State : warning == Summary == $ dim checkpatch origin/drm-tip b5756156fe80 drm/i915: Verify the engine after acquiring the active.lock -:16: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #16: <4> [876.736126] list_add corruption. prev->next should be next (8883f931a1f8), but was dead0100. (prev=888361ffa610). total: 0 errors, 1 warnings, 0 checks, 37 lines checked ___ 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/dp: Support for DP HDR outputs (rev8)
== Series Details == Series: drm/i915/dp: Support for DP HDR outputs (rev8) URL : https://patchwork.freedesktop.org/series/65656/ State : success == Summary == CI Bug Log - changes from CI_DRM_6897_full -> Patchwork_14417_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14417_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110841]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-iclb7/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-iclb3/igt@gem_exec_sched...@wide-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/shard-iclb4/igt@gem_exec_sched...@wide-bsd.html * igt@gem_softpin@noreloc-s3: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#104108]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-skl1/igt@gem_soft...@noreloc-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/shard-skl1/igt@gem_soft...@noreloc-s3.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-apl7/igt@gem_workarou...@suspend-resume-context.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/shard-apl8/igt@gem_workarou...@suspend-resume-context.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-kbl1/igt@gem_workarou...@suspend-resume-fd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/shard-kbl2/igt@gem_workarou...@suspend-resume-fd.html * igt@kms_color@pipe-a-ctm-green-to-red: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#107201]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-skl7/igt@kms_co...@pipe-a-ctm-green-to-red.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/shard-skl3/igt@kms_co...@pipe-a-ctm-green-to-red.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-pwrite: - shard-iclb: [PASS][15] -> [INCOMPLETE][16] ([fdo#107713]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-iclb5/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-pwrite.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/shard-iclb7/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-pwrite.html * igt@kms_frontbuffer_tracking@psr-1p-pri-indfb-multidraw: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#103167]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-skl7/igt@kms_frontbuffer_track...@psr-1p-pri-indfb-multidraw.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/shard-skl3/igt@kms_frontbuffer_track...@psr-1p-pri-indfb-multidraw.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-skl7/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/shard-skl3/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_psr@psr2_basic: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-iclb2/igt@kms_psr@psr2_basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/shard-iclb8/igt@kms_psr@psr2_basic.html * igt@kms_sequence@queue-idle: - shard-hsw: [PASS][23] -> [INCOMPLETE][24] ([fdo#103540]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/shard-hsw8/igt@kms_seque...@queue-idle.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/shard-hsw6/igt@kms_seque...@queue-idle.html * igt@prime_busy@hang-bsd2: - shard-iclb: [PASS][25] -> [SKIP][26]
Re: [Intel-gfx] [PATCH 2/9] drm/print: add drm_debug_enabled()
On Monday, 2019-09-16 11:53:24 +0300, Jani Nikula wrote:
> On Fri, 13 Sep 2019, Eric Engestrom wrote:
> > On Friday, 2019-09-13 14:51:39 +0300, Jani Nikula wrote:
> >> Add helper to check if a drm debug category is enabled. Convert drm core
> >> to use it. No functional changes.
> >>
> >> Signed-off-by: Jani Nikula
> >> ---
> >> drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
> >> drivers/gpu/drm/drm_dp_mst_topology.c | 6 +++---
> >> drivers/gpu/drm/drm_edid.c| 2 +-
> >> drivers/gpu/drm/drm_edid_load.c | 2 +-
> >> drivers/gpu/drm/drm_mipi_dbi.c| 4 ++--
> >> drivers/gpu/drm/drm_print.c | 4 ++--
> >> drivers/gpu/drm/drm_vblank.c | 6 +++---
> >> include/drm/drm_print.h | 5 +
> >> 8 files changed, 18 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> >> b/drivers/gpu/drm/drm_atomic_uapi.c
> >> index 5a5b42db6f2a..6576cd997cbd 100644
> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> @@ -1406,7 +1406,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> >>} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
> >>ret = drm_atomic_nonblocking_commit(state);
> >>} else {
> >> - if (unlikely(drm_debug & DRM_UT_STATE))
> >> + if (unlikely(drm_debug_enabled(DRM_UT_STATE)))
> >>drm_atomic_print_state(state);
> >>
> >>ret = drm_atomic_commit(state);
> >> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> >> b/drivers/gpu/drm/drm_dp_mst_topology.c
> >> index 97216099a718..f47c5b6b51f7 100644
> >> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> >> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> >> @@ -1180,7 +1180,7 @@ static int drm_dp_mst_wait_tx_reply(struct
> >> drm_dp_mst_branch *mstb,
> >>}
> >>}
> >> out:
> >> - if (unlikely(ret == -EIO && drm_debug & DRM_UT_DP)) {
> >> + if (unlikely(ret == -EIO && drm_debug_enabled(DRM_UT_DP))) {
> >>struct drm_printer p = drm_debug_printer(DBG_PREFIX);
> >>
> >>drm_dp_mst_dump_sideband_msg_tx(, txmsg);
> >> @@ -2321,7 +2321,7 @@ static int process_single_tx_qlock(struct
> >> drm_dp_mst_topology_mgr *mgr,
> >>idx += tosend + 1;
> >>
> >>ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx);
> >> - if (unlikely(ret && drm_debug & DRM_UT_DP)) {
> >> + if (unlikely(ret && drm_debug_enabled(DRM_UT_DP))) {
> >>struct drm_printer p = drm_debug_printer(DBG_PREFIX);
> >>
> >>drm_printf(, "sideband msg failed to send\n");
> >> @@ -2388,7 +2388,7 @@ static void drm_dp_queue_down_tx(struct
> >> drm_dp_mst_topology_mgr *mgr,
> >>mutex_lock(>qlock);
> >>list_add_tail(>next, >tx_msg_downq);
> >>
> >> - if (unlikely(drm_debug & DRM_UT_DP)) {
> >> + if (unlikely(drm_debug_enabled(DRM_UT_DP))) {
> >>struct drm_printer p = drm_debug_printer(DBG_PREFIX);
> >>
> >>drm_dp_mst_dump_sideband_msg_tx(, txmsg);
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 12c783f4d956..58dad4d24cd4 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -1551,7 +1551,7 @@ static void connector_bad_edid(struct drm_connector
> >> *connector,
> >> {
> >>int i;
> >>
> >> - if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
> >> + if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS))
> >>return;
> >>
> >>dev_warn(connector->dev->dev,
> >> diff --git a/drivers/gpu/drm/drm_edid_load.c
> >> b/drivers/gpu/drm/drm_edid_load.c
> >> index d38b3b255926..37d8ba3ddb46 100644
> >> --- a/drivers/gpu/drm/drm_edid_load.c
> >> +++ b/drivers/gpu/drm/drm_edid_load.c
> >> @@ -175,7 +175,7 @@ static void *edid_load(struct drm_connector
> >> *connector, const char *name,
> >>u8 *edid;
> >>int fwsize, builtin;
> >>int i, valid_extensions = 0;
> >> - bool print_bad_edid = !connector->bad_edid_counter || (drm_debug &
> >> DRM_UT_KMS);
> >> + bool print_bad_edid = !connector->bad_edid_counter ||
> >> drm_debug_enabled(DRM_UT_KMS);
> >>
> >>builtin = match_string(generic_edid_name, GENERIC_EDIDS, name);
> >>if (builtin >= 0) {
> >> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c
> >> b/drivers/gpu/drm/drm_mipi_dbi.c
> >> index f8154316a3b0..ccfb5b33c5e3 100644
> >> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> >> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> >> @@ -783,7 +783,7 @@ static int mipi_dbi_spi1e_transfer(struct mipi_dbi
> >> *dbi, int dc,
> >>int i, ret;
> >>u8 *dst;
> >>
> >> - if (drm_debug & DRM_UT_DRIVER)
> >> + if (drm_debug_enabled(DRM_UT_DRIVER))
> >>pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
> >> __func__, dc, max_chunk);
> >>
> >> @@ -907,7 +907,7 @@ static int mipi_dbi_spi1_transfer(struct mipi_dbi
> >> *dbi, int dc,
> >>max_chunk = dbi->tx_buf9_len;
> >>dst16 = dbi->tx_buf9;
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Support for DP HDR outputs (rev8)
== Series Details ==
Series: drm/i915/dp: Support for DP HDR outputs (rev8)
URL : https://patchwork.freedesktop.org/series/65656/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6897 -> Patchwork_14417
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/
Known issues
Here are the changes found in Patchwork_14417 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@vgem_basic@unload:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/fi-icl-u3/igt@vgem_ba...@unload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/fi-icl-u3/igt@vgem_ba...@unload.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- {fi-icl-u4}:[INCOMPLETE][5] ([fdo#107713] / [fdo#109100]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/fi-icl-u4/igt@gem_ctx_cre...@basic-files.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/fi-icl-u4/igt@gem_ctx_cre...@basic-files.html
* igt@gem_ctx_switch@legacy-render:
- {fi-icl-guc}: [INCOMPLETE][7] ([fdo#107713] / [fdo#111381]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
* {igt@i915_selftest@live_gt_timelines}:
- fi-bsw-kefka: [DMESG-WARN][9] ([fdo#111373]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/fi-bsw-kefka/igt@i915_selftest@live_gt_timelines.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/fi-bsw-kefka/igt@i915_selftest@live_gt_timelines.html
* igt@vgem_basic@dmabuf-fence-before:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/fi-icl-u3/igt@vgem_ba...@dmabuf-fence-before.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/fi-icl-u3/igt@vgem_ba...@dmabuf-fence-before.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#111373]: https://bugs.freedesktop.org/show_bug.cgi?id=111373
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
Participating hosts (55 -> 49)
--
Additional (1): fi-apl-guc
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6897 -> Patchwork_14417
CI-20190529: 20190529
CI_DRM_6897: 8ee6ca77b45a87f294a219eca4b467425a3ddc73 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5183: 6ddc1a143495baa68dbc909f2a8819ec03c31c8e @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14417: 48a622358b97aa4ec3bc1b260dc59b21a909b425 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
48a622358b97 drm/i915/dp: Attach HDR metadata property to DP connector
c59fcbc86ed9 drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static
Metadata
b28948dd22ab drm/i915: Add new GMP register size for GEN11
048ad15b79e8 drm/i915/dp: Attach colorspace property
b9e3151ed335 drm: Add DisplayPort colorspace property
2d996a4de847 drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA
643d69f4c283 drm/i915/dp: Extend program of VSC Header and DB for Colorimetry
Format
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14417/index.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: stop conflating HAS_DISPLAY() and disabled display
== Series Details ==
Series: drm/i915: stop conflating HAS_DISPLAY() and disabled display
URL : https://patchwork.freedesktop.org/series/66749/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6897 -> Patchwork_14418
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/
Known issues
Here are the changes found in Patchwork_14418 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@bad-open:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/fi-icl-u3/igt@gem_flink_ba...@bad-open.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/fi-icl-u3/igt@gem_flink_ba...@bad-open.html
* igt@gem_mmap_gtt@basic:
- fi-glk-dsi: [PASS][5] -> [INCOMPLETE][6] ([fdo#103359] /
[k.org#198133])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/fi-glk-dsi/igt@gem_mmap_...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/fi-glk-dsi/igt@gem_mmap_...@basic.html
* igt@i915_selftest@live_reset:
- fi-icl-u2: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/fi-icl-u2/igt@i915_selftest@live_reset.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/fi-icl-u2/igt@i915_selftest@live_reset.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- {fi-icl-u4}:[INCOMPLETE][9] ([fdo#107713] / [fdo#109100]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/fi-icl-u4/igt@gem_ctx_cre...@basic-files.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/fi-icl-u4/igt@gem_ctx_cre...@basic-files.html
* igt@gem_ctx_switch@legacy-render:
- {fi-icl-guc}: [INCOMPLETE][11] ([fdo#107713] / [fdo#111381]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_exec_fence@nb-await-default:
- {fi-tgl-u}: [FAIL][13] ([fdo#111562] / [fdo#111597]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/fi-tgl-u/igt@gem_exec_fe...@nb-await-default.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/fi-tgl-u/igt@gem_exec_fe...@nb-await-default.html
* {igt@i915_selftest@live_gt_timelines}:
- fi-bsw-kefka: [DMESG-WARN][15] ([fdo#111373]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/fi-bsw-kefka/igt@i915_selftest@live_gt_timelines.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/fi-bsw-kefka/igt@i915_selftest@live_gt_timelines.html
* igt@vgem_basic@dmabuf-fence-before:
- fi-icl-u3: [DMESG-WARN][17] ([fdo#107724]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6897/fi-icl-u3/igt@vgem_ba...@dmabuf-fence-before.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/fi-icl-u3/igt@vgem_ba...@dmabuf-fence-before.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#111373]: https://bugs.freedesktop.org/show_bug.cgi?id=111373
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111562]: https://bugs.freedesktop.org/show_bug.cgi?id=111562
[fdo#111597]: https://bugs.freedesktop.org/show_bug.cgi?id=111597
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (55 -> 49)
--
Additional (1): fi-apl-guc
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6897 -> Patchwork_14418
CI-20190529: 20190529
CI_DRM_6897: 8ee6ca77b45a87f294a219eca4b467425a3ddc73 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5183: 6ddc1a143495baa68dbc909f2a8819ec03c31c8e
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt/kms_frontbuffer_tracking: Skip over IGT_DRAW_BLT when there's no BLT
Quoting Petri Latvala (2019-09-16 13:06:04) > On Sun, Sep 15, 2019 at 10:39:48AM +0100, Chris Wilson wrote: > > If the blitter is not available, we cannot use it as a source for dirty > > rectangles. We shall have to rely on the other engines to create GPU > > dirty instead. > > > > v2: Try using lots of subgroup+fixtures > > > > Signed-off-by: Chris Wilson > > > Reviewed-by: Petri Latvala Sadly, it needs a bit massaging of the underlying library to avoid using the blitter it seems. Or I've missed a method == IGT_DRAW_BLT. (But iirc there's some paths where the fb lib uses the blitter to detile.) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/9] drm/print: add drm_debug_enabled()
On Mon, 16 Sep 2019, Eric Engestrom wrote:
> On Monday, 2019-09-16 11:53:24 +0300, Jani Nikula wrote:
>> On Fri, 13 Sep 2019, Eric Engestrom wrote:
>> > On Friday, 2019-09-13 14:51:39 +0300, Jani Nikula wrote:
>> >> Add helper to check if a drm debug category is enabled. Convert drm core
>> >> to use it. No functional changes.
>> >>
>> >> Signed-off-by: Jani Nikula
>> >> ---
>> >> drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
>> >> drivers/gpu/drm/drm_dp_mst_topology.c | 6 +++---
>> >> drivers/gpu/drm/drm_edid.c| 2 +-
>> >> drivers/gpu/drm/drm_edid_load.c | 2 +-
>> >> drivers/gpu/drm/drm_mipi_dbi.c| 4 ++--
>> >> drivers/gpu/drm/drm_print.c | 4 ++--
>> >> drivers/gpu/drm/drm_vblank.c | 6 +++---
>> >> include/drm/drm_print.h | 5 +
>> >> 8 files changed, 18 insertions(+), 13 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> >> b/drivers/gpu/drm/drm_atomic_uapi.c
>> >> index 5a5b42db6f2a..6576cd997cbd 100644
>> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> >> @@ -1406,7 +1406,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>> >> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
>> >> ret = drm_atomic_nonblocking_commit(state);
>> >> } else {
>> >> - if (unlikely(drm_debug & DRM_UT_STATE))
>> >> + if (unlikely(drm_debug_enabled(DRM_UT_STATE)))
>> >> drm_atomic_print_state(state);
>> >>
>> >> ret = drm_atomic_commit(state);
>> >> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
>> >> b/drivers/gpu/drm/drm_dp_mst_topology.c
>> >> index 97216099a718..f47c5b6b51f7 100644
>> >> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
>> >> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
>> >> @@ -1180,7 +1180,7 @@ static int drm_dp_mst_wait_tx_reply(struct
>> >> drm_dp_mst_branch *mstb,
>> >> }
>> >> }
>> >> out:
>> >> - if (unlikely(ret == -EIO && drm_debug & DRM_UT_DP)) {
>> >> + if (unlikely(ret == -EIO && drm_debug_enabled(DRM_UT_DP))) {
>> >> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>> >>
>> >> drm_dp_mst_dump_sideband_msg_tx(, txmsg);
>> >> @@ -2321,7 +2321,7 @@ static int process_single_tx_qlock(struct
>> >> drm_dp_mst_topology_mgr *mgr,
>> >> idx += tosend + 1;
>> >>
>> >> ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx);
>> >> - if (unlikely(ret && drm_debug & DRM_UT_DP)) {
>> >> + if (unlikely(ret && drm_debug_enabled(DRM_UT_DP))) {
>> >> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>> >>
>> >> drm_printf(, "sideband msg failed to send\n");
>> >> @@ -2388,7 +2388,7 @@ static void drm_dp_queue_down_tx(struct
>> >> drm_dp_mst_topology_mgr *mgr,
>> >> mutex_lock(>qlock);
>> >> list_add_tail(>next, >tx_msg_downq);
>> >>
>> >> - if (unlikely(drm_debug & DRM_UT_DP)) {
>> >> + if (unlikely(drm_debug_enabled(DRM_UT_DP))) {
>> >> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>> >>
>> >> drm_dp_mst_dump_sideband_msg_tx(, txmsg);
>> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> >> index 12c783f4d956..58dad4d24cd4 100644
>> >> --- a/drivers/gpu/drm/drm_edid.c
>> >> +++ b/drivers/gpu/drm/drm_edid.c
>> >> @@ -1551,7 +1551,7 @@ static void connector_bad_edid(struct drm_connector
>> >> *connector,
>> >> {
>> >> int i;
>> >>
>> >> - if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
>> >> + if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS))
>> >> return;
>> >>
>> >> dev_warn(connector->dev->dev,
>> >> diff --git a/drivers/gpu/drm/drm_edid_load.c
>> >> b/drivers/gpu/drm/drm_edid_load.c
>> >> index d38b3b255926..37d8ba3ddb46 100644
>> >> --- a/drivers/gpu/drm/drm_edid_load.c
>> >> +++ b/drivers/gpu/drm/drm_edid_load.c
>> >> @@ -175,7 +175,7 @@ static void *edid_load(struct drm_connector
>> >> *connector, const char *name,
>> >> u8 *edid;
>> >> int fwsize, builtin;
>> >> int i, valid_extensions = 0;
>> >> - bool print_bad_edid = !connector->bad_edid_counter || (drm_debug &
>> >> DRM_UT_KMS);
>> >> + bool print_bad_edid = !connector->bad_edid_counter ||
>> >> drm_debug_enabled(DRM_UT_KMS);
>> >>
>> >> builtin = match_string(generic_edid_name, GENERIC_EDIDS, name);
>> >> if (builtin >= 0) {
>> >> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c
>> >> b/drivers/gpu/drm/drm_mipi_dbi.c
>> >> index f8154316a3b0..ccfb5b33c5e3 100644
>> >> --- a/drivers/gpu/drm/drm_mipi_dbi.c
>> >> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
>> >> @@ -783,7 +783,7 @@ static int mipi_dbi_spi1e_transfer(struct mipi_dbi
>> >> *dbi, int dc,
>> >> int i, ret;
>> >> u8 *dst;
>> >>
>> >> - if (drm_debug & DRM_UT_DRIVER)
>> >> + if (drm_debug_enabled(DRM_UT_DRIVER))
>> >> pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
>> >>__func__, dc, max_chunk);
>> >>
>> >> @@ -907,7 +907,7 @@ static int
Re: [Intel-gfx] [PATCH v8 1/7] drm/i915/tgl: Add DC3CO required register and bits
On 9/13/2019 1:53 PM, Anshuman Gupta wrote:
Adding following definition to i915_reg.h
1. DC_STATE_EN register DC3CO bit fields and masks.
2. Transcoder EXITLINE register and its bit fields and mask.
v1: Use of REG_BIT and using extra space for EXITLINE_ macro
definition. [Animesh]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_reg.h | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bf37ecebc82f..6bfebab9a441 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4138,6 +4138,7 @@ enum {
#define _VTOTAL_A 0x6000c
#define _VBLANK_A 0x60010
#define _VSYNC_A 0x60014
+#define _EXITLINE_A0x60018
#define _PIPEASRC 0x6001c
#define _BCLRPAT_A0x60020
#define _VSYNCSHIFT_A 0x60028
@@ -4184,11 +4185,16 @@ enum {
#define VTOTAL(trans) _MMIO_TRANS2(trans, _VTOTAL_A)
#define VBLANK(trans) _MMIO_TRANS2(trans, _VBLANK_A)
#define VSYNC(trans) _MMIO_TRANS2(trans, _VSYNC_A)
+#define EXITLINE(trans)_MMIO_TRANS2(trans, _EXITLINE_A)
#define BCLRPAT(trans)_MMIO_TRANS2(trans, _BCLRPAT_A)
#define VSYNCSHIFT(trans) _MMIO_TRANS2(trans, _VSYNCSHIFT_A)
#define PIPESRC(trans)_MMIO_TRANS2(trans, _PIPEASRC)
#define PIPE_MULT(trans) _MMIO_TRANS2(trans, _PIPE_MULT_A)
+#define EXITLINE_ENABLE REG_BIT(31)
+#define EXITLINE_MASKREG_GENMASK(12, 0)
+#define EXITLINE_SHIFT 0
+
/*
* HSW+ eDP PSR registers
*
@@ -10118,6 +10124,8 @@ enum skl_power_gate {
/* GEN9 DC */
#define DC_STATE_EN _MMIO(0x45504)
#define DC_STATE_DISABLE 0
+#define DC_STATE_EN_DC3CO REG_BIT(30)
+#define DC_STATE_DC3CO_STATUS REG_BIT(29)
#define DC_STATE_EN_UPTO_DC5 (1 << 0)
#define DC_STATE_EN_DC9 (1 << 3)
#define DC_STATE_EN_UPTO_DC6 (2 << 0)
The purpose of adding the register is not clear by looking at this patch.
Commit description can be improved if register definition want to keep
as separate patch.
With improved commit description,
Can add Reviewed-by: Animesh Manna
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 2/7] drm/i915/tgl: Add DC3CO mask to allowed_dc_mask and gen9_dc_mask
On 9/13/2019 1:53 PM, Anshuman Gupta wrote:
Enable dc3co state in enable_dc module param and add dc3co
enable mask to allowed_dc_mask and gen9_dc_mask.
v1: Adding enable_dc=3,4 options to enable DC3CO with DC5 and DC6
independently. [Animesh]
v2: Using a switch statement for cleaner code. [Animesh]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_power.c| 29 +++
drivers/gpu/drm/i915/i915_params.c| 3 +-
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index ce88a27229ef..24cd9320ad4c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -698,7 +698,11 @@ static u32 gen9_dc_mask(struct drm_i915_private *dev_priv)
u32 mask;
mask = DC_STATE_EN_UPTO_DC5;
- if (INTEL_GEN(dev_priv) >= 11)
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ mask |= DC_STATE_EN_DC3CO | DC_STATE_EN_UPTO_DC6
+ | DC_STATE_EN_DC9;
+ else if (IS_GEN(dev_priv, 11))
mask |= DC_STATE_EN_UPTO_DC6 | DC_STATE_EN_DC9;
else if (IS_GEN9_LP(dev_priv))
mask |= DC_STATE_EN_DC9;
@@ -3927,14 +3931,17 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
int requested_dc;
int max_dc;
- if (INTEL_GEN(dev_priv) >= 11) {
- max_dc = 2;
+ if (INTEL_GEN(dev_priv) >= 12) {
+ max_dc = 4;
/*
* DC9 has a separate HW flow from the rest of the DC states,
* not depending on the DMC firmware. It's needed by system
* suspend/resume, so allow it unconditionally.
*/
mask = DC_STATE_EN_DC9;
+ } else if (IS_GEN(dev_priv, 11)) {
+ max_dc = 2;
+ mask = DC_STATE_EN_DC9;
} else if (IS_GEN(dev_priv, 10) || IS_GEN9_BC(dev_priv)) {
max_dc = 2;
mask = 0;
@@ -3953,7 +3960,7 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
requested_dc = enable_dc;
} else if (enable_dc == -1) {
requested_dc = max_dc;
- } else if (enable_dc > max_dc && enable_dc <= 2) {
+ } else if (enable_dc > max_dc && enable_dc <= 4) {
DRM_DEBUG_KMS("Adjusting requested max DC state (%d->%d)\n",
enable_dc, max_dc);
requested_dc = max_dc;
@@ -3962,10 +3969,20 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
requested_dc = max_dc;
}
- if (requested_dc > 1)
+ switch (requested_dc) {
+ case 4:
+ mask |= DC_STATE_EN_DC3CO | DC_STATE_EN_UPTO_DC6;
+ break;
+ case 3:
+ mask |= DC_STATE_EN_DC3CO | DC_STATE_EN_UPTO_DC5;
+ break;
+ case 2:
mask |= DC_STATE_EN_UPTO_DC6;
- if (requested_dc > 0)
+ break;
+ case 1:
mask |= DC_STATE_EN_UPTO_DC5;
+ break;
+ }
DRM_DEBUG_KMS("Allowed DC state mask %02x\n", mask);
diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c
index 296452f9efe4..4f1806f65040 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -46,7 +46,8 @@ i915_param_named(modeset, int, 0400,
i915_param_named_unsafe(enable_dc, int, 0400,
"Enable power-saving display C-states. "
- "(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6)");
+ "(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6; "
+ "3=up to DC5 with DC3CO; 4=up to DC6 with DC3CO)");
i915_param_named_unsafe(enable_fbc, int, 0600,
"Enable frame buffer compression for power savings "
Changes looks ok to me.
Can add Reviewed-by: Animesh Manna
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND] drm/i915: stop conflating HAS_DISPLAY() and disabled display
Quoting Jani Nikula (2019-09-16 10:29:01)
> Stop setting ->pipe_mask to zero when display is disabled, allowing us
> to have different code paths for not actually having display hardware,
> and having display hardware disabled. This lets us develop those two
> avenues independently.
>
> There are no functional changes for when there is no display. However,
> all uses of for_each_pipe() and for_each_pipe_masked() will start
> running for the disabled display case. Put one of the more significant
> ones behind checks for INTEL_DISPLAY_ENABLED(), otherwise the cases
> should not be hit with disabled display, or they seem benign. Fingers
> crossed.
>
> All in all, this might not be the ideal solution. In fact we may have
> had something along the lines of this in the past, but we ended up
> conflating the two cases. Possibly even by recommendation by yours
> truly; I did not dare dig up that part of the history. But the perfect
> is the enemy of the good, this is a straightforward change, and lets us
> get actual work done in both fronts without interfering with each other.
>
> Cc: Chris Wilson
> Cc: José Roberto de Souza
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 12 +++-
> drivers/gpu/drm/i915/intel_device_info.c | 8 ++--
> 2 files changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e75945a53e06..ac24f96582ca 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -16281,11 +16281,13 @@ int intel_modeset_init(struct drm_device *dev)
> INTEL_NUM_PIPES(dev_priv),
> INTEL_NUM_PIPES(dev_priv) > 1 ? "s" : "");
>
> - for_each_pipe(dev_priv, pipe) {
> - ret = intel_crtc_init(dev_priv, pipe);
> - if (ret) {
> - drm_mode_config_cleanup(dev);
> - return ret;
> + if (HAS_DISPLAY(dev_priv) && INTEL_DISPLAY_ENABLED(dev_priv)) {
> + for_each_pipe(dev_priv, pipe) {
> + ret = intel_crtc_init(dev_priv, pipe);
What direction are you planning to take, avoid enabling anything related
to display? My worry is that in
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14418/fi-bsw-kefka/igt@i915_selftest@live_gt_timelines.html
we still see weird events like
<7> [444.313823] [drm:i915_redisable_vga_power_on [i915]] Something enabled VGA
plane, disabling it
and I'm not sure how you intend to curtail that. (Or if that's even
possible.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
