Re: [Intel-gfx] [PATCH 08/10] drm/crc: Cleanup crtc_crc_open function
Hi Mahesh,
Thank you for the patch.
On Monday, 2 July 2018 14:07:27 EEST Mahesh Kumar wrote:
> This patch make changes to allocate crc-entries buffer before
> enabling CRC generation.
> It moves all the failure check early in the function before setting
> the source or memory allocation.
> Now set_crc_source takes only two variable inputs, values_cnt we
> already gets as part of verify_crc_source.
>
> Signed-off-by: Mahesh Kumar
> Cc: dri-de...@lists.freedesktop.org
> Reviewed-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 3 +-
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 4 +-
> drivers/gpu/drm/drm_debugfs_crc.c | 52 ---
> drivers/gpu/drm/i915/intel_drv.h | 3 +-
> drivers/gpu/drm/i915/intel_pipe_crc.c | 4 +-
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 5 +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 6 +--
> include/drm/drm_crtc.h | 3 +-
> 8 files changed, 30 insertions(+), 50 deletions(-)
[snip]
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> b/drivers/gpu/drm/drm_debugfs_crc.c index f4d76528d24c..739a813b4b09 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -124,11 +124,9 @@ static ssize_t crc_control_write(struct file *file,
> const char __user *ubuf, if (source[len] == '\n')
> source[len] = '\0';
>
> - if (crtc->funcs->verify_crc_source) {
> - ret = crtc->funcs->verify_crc_source(crtc, source, _cnt);
> - if (ret)
> - return ret;
> - }
> + ret = crtc->funcs->verify_crc_source(crtc, source, _cnt);
> + if (ret)
> + return ret;
>
> spin_lock_irq(>lock);
>
> @@ -193,12 +191,15 @@ static int crtc_crc_open(struct inode *inode, struct
> file *filep) return ret;
> }
>
> - if (crtc->funcs->verify_crc_source) {
> - ret = crtc->funcs->verify_crc_source(crtc, crc->source,
> - _cnt);
> - if (ret)
> - return ret;
> - }
> + ret = crtc->funcs->verify_crc_source(crtc, crc->source, _cnt);
> + if (ret)
> + return ret;
> +
> + if (WARN_ON(values_cnt > DRM_MAX_CRC_NR))
> + return -EINVAL;
> +
> + if (WARN_ON(values_cnt == 0))
> + return -EINVAL;
>
> spin_lock_irq(>lock);
> if (!crc->opened)
> @@ -210,30 +211,22 @@ static int crtc_crc_open(struct inode *inode, struct
> file *filep) if (ret)
> return ret;
>
> - ret = crtc->funcs->set_crc_source(crtc, crc->source, _cnt);
> - if (ret)
> - goto err;
> -
> - if (WARN_ON(values_cnt > DRM_MAX_CRC_NR)) {
> - ret = -EINVAL;
> - goto err_disable;
> - }
> -
> - if (WARN_ON(values_cnt == 0)) {
> - ret = -EINVAL;
> - goto err_disable;
> - }
> -
> entries = kcalloc(DRM_CRC_ENTRIES_NR, sizeof(*entries), GFP_KERNEL);
> if (!entries) {
> ret = -ENOMEM;
> - goto err_disable;
> + goto err;
> }
If you moved allocation before the !crc->opened check, you could group the two
code blocks protected by the crc->lock.
> spin_lock_irq(>lock);
> crc->entries = entries;
> crc->values_cnt = values_cnt;
> + spin_unlock_irq(>lock);
>
> + ret = crtc->funcs->set_crc_source(crtc, crc->source);
> + if (ret)
> + goto err;
> +
> + spin_lock_irq(>lock);
> /*
>* Only return once we got a first frame, so userspace doesn't have to
>* guess when this particular piece of HW will be ready to start
> @@ -250,7 +243,7 @@ static int crtc_crc_open(struct inode *inode, struct
> file *filep) return 0;
>
> err_disable:
> - crtc->funcs->set_crc_source(crtc, NULL, _cnt);
> + crtc->funcs->set_crc_source(crtc, NULL);
> err:
> spin_lock_irq(>lock);
> crtc_crc_cleanup(crc);
> @@ -262,9 +255,8 @@ static int crtc_crc_release(struct inode *inode, struct
> file *filep) {
> struct drm_crtc *crtc = filep->f_inode->i_private;
> struct drm_crtc_crc *crc = >crc;
> - size_t values_cnt;
>
> - crtc->funcs->set_crc_source(crtc, NULL, _cnt);
> + crtc->funcs->set_crc_source(crtc, NULL);
>
> spin_lock_irq(>lock);
> crtc_crc_cleanup(crc);
> @@ -370,7 +362,7 @@ int drm_debugfs_crtc_crc_add(struct drm_crtc *crtc)
> {
> struct dentry *crc_ent, *ent;
>
> - if (!crtc->funcs->set_crc_source)
> + if (!crtc->funcs->set_crc_source || !crtc->funcs->verify_crc_source)
> return 0;
>
> crc_ent = debugfs_create_dir("crc", crtc->debugfs_entry);
[snip]
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/10] drm: crc: Introduce verify_crc_source callback
Hi,
Thanks for the review,
On 7/10/2018 4:56 PM, Laurent Pinchart wrote:
Hi Mahesh,
Thank you for the patch.
On Monday, 2 July 2018 14:07:20 EEST Mahesh Kumar wrote:
This patch adds a new callback function "verify_crc_source" which will
be used during setting the crc source in control node and while opening
data node for crc reading. This will help in avoiding setting of wrong
string for source.
Why do you need to verify the source in the open() operation ? Isn't it enough
to verify it in the write() handler ? The answer to this question might lie in
patch 08/10, in which case I'd add the .verify_crc_source() call in open() in
that patch, not here.
Yes, final goal is achieved by patch 08/10. But if crc_read is called
before setting the source, it may have wrong source set in that case I
wanted to return early at least for the drivers implemented
verify_crc_source. If you still think otherwise I will modify
accordingly in next series.
-Mahesh
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_debugfs_crc.c | 15 +++
include/drm/drm_crtc.h| 15 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c index 9f8312137cad..c6a725b79ac6 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -87,6 +87,8 @@ static ssize_t crc_control_write(struct file *file, const
char __user *ubuf, struct drm_crtc *crtc = m->private;
struct drm_crtc_crc *crc = >crc;
char *source;
+ size_t values_cnt;
+ int ret = 0;
if (len == 0)
return 0;
@@ -104,6 +106,12 @@ static ssize_t crc_control_write(struct file *file,
const char __user *ubuf, if (source[len] == '\n')
source[len] = '\0';
+ if (crtc->funcs->verify_crc_source) {
+ ret = crtc->funcs->verify_crc_source(crtc, source, _cnt);
+ if (ret)
+ return ret;
+ }
+
spin_lock_irq(>lock);
if (crc->opened) {
@@ -167,6 +175,13 @@ static int crtc_crc_open(struct inode *inode, struct
file *filep) return ret;
}
+ if (crtc->funcs->verify_crc_source) {
+ ret = crtc->funcs->verify_crc_source(crtc, crc->source,
+_cnt);
+ if (ret)
+ return ret;
+ }
+
spin_lock_irq(>lock);
if (!crc->opened)
crc->opened = true;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 23eddbccab10..1a6dcbf91744 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -661,6 +661,21 @@ struct drm_crtc_funcs {
*/
int (*set_crc_source)(struct drm_crtc *crtc, const char *source,
size_t *values_cnt);
+ /**
+* @verify_crc_source:
+*
+* verifies the source of CRC checksums of frames before setting the
+* source for CRC and during crc open.
+*
+* This callback is optional if the driver does not support any CRC
+* generation functionality.
+*
+* RETURNS:
+*
+* 0 on success or a negative error code on failure.
+*/
+ int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
+size_t *values_cnt);
/**
* @atomic_print_state:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/12] mm: use for_each_if
LGTM: Reviewed-by: Pavel Tatashin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] kernel.h: Add for_each_if()
On Tue, Jul 10 2018, Daniel Vetter wrote:
> On Mon, Jul 09, 2018 at 04:30:01PM -0700, Andrew Morton wrote:
>> On Mon, 9 Jul 2018 18:25:09 +0200 Daniel Vetter
>> wrote:
>>
>> > To avoid compilers complainig about ambigious else blocks when putting
>> > an if condition into a for_each macro one needs to invert the
>> > condition and add a dummy else. We have a nice little convenience
>> > macro for that in drm headers, let's move it out. Subsequent patches
>> > will roll it out to other places.
>> >
>> > The issue the compilers complain about are nested if with an else
>> > block and no {} to disambiguate which if the else belongs to. The C
>> > standard is clear, but in practice people forget:
>> >
>> > if (foo)
>> >if (bar)
>> >/* something */
>> >else
>> >/* something else
>>
>> um, yeah, don't do that. Kernel coding style is very much to do
>>
>> if (foo) {
>> if (bar)
>> /* something */
>> else
>> /* something else
>> }
>>
>> And if not doing that generates a warning then, well, do that.
>>
>> > The same can happen in a for_each macro when it also contains an if
>> > condition at the end, except the compiler message is now really
>> > confusing since there's only 1 if:
>> >
>> > for_each_something()
>> >if (bar)
>> >/* something */
>> >else
>> >/* something else
>> >
>> > The for_each_if() macro, by inverting the condition and adding an
>> > else, avoids the compiler warning.
>>
>> Ditto.
>>
>> > Motivated by a discussion with Andy and Yisheng, who want to add
>> > another for_each_macro which would benefit from for_each_if() instead
>> > of hand-rolling it.
>>
>> Ditto.
>>
>> > v2: Explain a bit better what this is good for, after the discussion
>> > with Peter Z.
>>
>> Presumably the above was discussed in whatever-thread-that-was.
>
> So there's a bunch of open coded versions of this already in kernel
> headers (at least the ones I've found). Not counting the big pile of
> existing users in drm. They are all wrong and should be reverted to a
> plain if? That why there's a bunch more patches in this series.
>
> And yes I made it clear in the discussion that if you sprinkle enough {}
> there's no warning, should have probably captured this here.
>
> Aka a formal Nack-pls-keep-your-stuff-in-drm: would be appreciated so I
> can stop bothering with this.
I think is it problematic to have macros like
#define for_each_foo(...) for (..) if ()
because
for_each_foo(...)
if (x) ; else ..;
is handled badly.
So in that sense, your work seems like a good thing.
However it isn't clear to me that you need a new macro.
The above macro could simply be changed to
#define for_each_foo(...) for (..) if (!);else
Clearly people don't always think to do this, but would adding a macro
help people to think?
If we were to have a macro, it isn't clear to me that for_each_if() is a
good name.
Every other macro I've seen that starts "for_each_" causes the body to
loop. This one doesn't. If someone doesn't know what for_each_if()
does and sees it in code, they are unlikely to jump to the right
conclusion.
I would suggest that "__if" would be a better choice. I think most
people would guess that means "like 'if', but a bit different", which is
fairly accurate.
I think the only sure way to avoid bad macros being written is to teach
some static checker to warn about any macro with a dangling "if".
Possibly checkpatch.pl could do that (but I'm not volunteering).
I do agree that it would be good to do something, and if people find
for_each_fi() to actually reduce the number of poorly written macros,
then I don't object to it.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/10] drm: crc: Introduce get_crc_sources callback
Hi,
thanks for the review.
On 7/10/2018 4:52 PM, Laurent Pinchart wrote:
Hi Mahesh,
Thank you for the patch.
On Monday, 2 July 2018 14:07:21 EEST Mahesh Kumar wrote:
This patch introduce a callback function "get_crc_sources" which
will be called during read of control node. It is an optional
callback function and if driver implements this callback, driver
should print list of available CRC sources in seq_file privided
as an input to the callback.
The commit message seems to be outdated, the callback doesn't take a seq_file
anymore.
ops, will update.
Changes Since V1: (Daniel)
- return const pointer to an array of crc sources list
- do validation of sources in CRC-core
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_debugfs_crc.c | 20 +++-
include/drm/drm_crtc.h| 16
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c index c6a725b79ac6..f4d76528d24c 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -67,9 +67,27 @@
static int crc_control_show(struct seq_file *m, void *data)
{
struct drm_crtc *crtc = m->private;
+ size_t count;
Count it only used within the if () {} block, you can declare it there.
agree.
+
+ if (crtc->funcs->get_crc_sources) {
+ const char *const *sources = crtc->funcs->get_crc_sources(crtc,
+ );
+ size_t values_cnt;
+ int i;
I only takes positive values, it can be an unsigned int.
ok
+
+ if (count <= 0 || !sources)
count is a size_t, it can't be negative.
The .get_crc_sources() documentation doesn't clearly specify whether sources
should always be NULL when count is zero. I advise updating the documentation,
and possibly updating this check accordingly.
ok will update.
+ goto out;
+
+ seq_puts(m, "[");
+ for (i = 0; i < count; i++)
+ if (!crtc->funcs->verify_crc_source(crtc, sources[i],
+ _cnt))
I assume that you verify sources one by one here to avoid having to create a
list of sources dynamically in the .get_crc_sources() callback ? If so, I
think the .get_crc_sources() callback should document that.
You should also document that .verify_crc_source() is required when
get_crc_sources() is provided.
ok sure.
+ seq_printf(m, "%s ", sources[i]);
+ seq_puts(m, "] ");
This assumes that source names can't include a space. Isn't that too
restrictive ? Shouldn't a different separator be used ? How about one source
name per line ?
what about comma separated as I'm putting names inside square-brackets?
Additionally, shouldn't the active source be marked ?
active source is again printed by the code in next few lines. output
will be of following format.
[space separated list of valid sources] active_source
-Mahesh
+ }
+out:
seq_printf(m, "%s\n", crtc->crc.source);
-
return 0;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 1a6dcbf91744..ffaec138aeee 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -676,6 +676,22 @@ struct drm_crtc_funcs {
*/
int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
size_t *values_cnt);
+ /**
+* @get_crc_sources:
+*
+* Driver callback for getting a list of all the available sources for
+* CRC generation.
+*
+* This callback is optional if the driver does not support exporting of
+* possible CRC sources list. CRC-core does the verification of sources.
+*
+* RETURNS:
+*
+* a constant character pointer to the list of all the available CRC
+* sources
+*/
+ const char *const *(*get_crc_sources)(struct drm_crtc *crtc,
+ size_t *count);
/**
* @atomic_print_state:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/10] Revert "drm: crc: Wait for a frame before returning from open()"
Hi Mahesh, Thank you for the patch. On Monday, 2 July 2018 14:07:28 EEST Mahesh Kumar wrote: > This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680. > > Don't wait for first CRC during crtc_crc_open. It avoids one frame wait > during open. If application want to wait after read call, it can use > poll/read blocking read() call. > > Suggested-by: Ville Syrjälä > Signed-off-by: Mahesh Kumar > Cc: dri-de...@lists.freedesktop.org > Cc: Tomeu Vizoso Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/drm_debugfs_crc.c | 16 > 1 file changed, 16 deletions(-) > > diff --git a/drivers/gpu/drm/drm_debugfs_crc.c > b/drivers/gpu/drm/drm_debugfs_crc.c index 739a813b4b09..add35b77165b 100644 > --- a/drivers/gpu/drm/drm_debugfs_crc.c > +++ b/drivers/gpu/drm/drm_debugfs_crc.c > @@ -226,24 +226,8 @@ static int crtc_crc_open(struct inode *inode, struct > file *filep) if (ret) > goto err; > > - spin_lock_irq(>lock); > - /* > - * Only return once we got a first frame, so userspace doesn't have to > - * guess when this particular piece of HW will be ready to start > - * generating CRCs. > - */ > - ret = wait_event_interruptible_lock_irq(crc->wq, > - crtc_crc_data_count(crc), > - crc->lock); > - spin_unlock_irq(>lock); > - > - if (ret) > - goto err_disable; > - > return 0; > > -err_disable: > - crtc->funcs->set_crc_source(crtc, NULL); > err: > spin_lock_irq(>lock); > crtc_crc_cleanup(crc); -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/10] drm: crc: Introduce pre_crc_read function
Hi Mahesh,
Thank you for the patch.
On Monday, 2 July 2018 14:07:29 EEST Mahesh Kumar wrote:
> This patch implements a callback function "pre_crc_read" which will
> be called before crc read. In this function driver can implement and
> preparation work required for successfully reading CRC data.
Reviewing this is difficult with a user. Could you submit a patch that makes
use of this callback in a driver ?
> Signed-off-by: Mahesh Kumar
> Cc: dri-de...@lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_debugfs_crc.c | 8
> include/drm/drm_crtc.h| 14 ++
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> b/drivers/gpu/drm/drm_debugfs_crc.c index add35b77165b..7aeed89f934a 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -272,6 +272,14 @@ static ssize_t crtc_crc_read(struct file *filep, char
> __user *user_buf, return 0;
> }
>
> + if (crtc->funcs->pre_crc_read) {
> + ret = crtc->funcs->pre_crc_read(crtc);
> + if (ret) {
> + spin_unlock_irq(>lock);
> + return ret;
> + }
> + }
> +
> /* Nothing to read? */
> while (crtc_crc_data_count(crc) == 0) {
> if (filep->f_flags & O_NONBLOCK) {
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 81780325f36f..7e2eab9c2f52 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -691,6 +691,20 @@ struct drm_crtc_funcs {
>*/
> const char *const *(*get_crc_sources)(struct drm_crtc *crtc,
> size_t *count);
> + /**
> + * @pre_crc_read:
> + *
> + * Driver callback for performing any preparation work required by
> + * driver before reading CRC
> + *
> + * This callback is optional if the driver does not support CRC
> + * generation or no prework is required before reading the crc
> + *
> + * RETURNS:
> + *
> + * 0 on success or a negative error code on failure.
> + */
> + int (*pre_crc_read)(struct drm_crtc *crtc);
>
> /**
>* @atomic_print_state:
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/10] drm: crc: Introduce verify_crc_source callback
Hi Mahesh,
On Tuesday, 10 July 2018 14:54:11 EEST Kumar, Mahesh wrote:
> On 7/10/2018 4:56 PM, Laurent Pinchart wrote:
> > On Monday, 2 July 2018 14:07:20 EEST Mahesh Kumar wrote:
> >> This patch adds a new callback function "verify_crc_source" which will
> >> be used during setting the crc source in control node and while opening
> >> data node for crc reading. This will help in avoiding setting of wrong
> >> string for source.
> >
> > Why do you need to verify the source in the open() operation ? Isn't it
> > enough to verify it in the write() handler ? The answer to this question
> > might lie in patch 08/10, in which case I'd add the .verify_crc_source()
> > call in open() in that patch, not here.
>
> Yes, final goal is achieved by patch 08/10. But if crc_read is called
> before setting the source, it may have wrong source set in that case I
> wanted to return early at least for the drivers implemented
> verify_crc_source. If you still think otherwise I will modify
> accordingly in next series.
I don't disagree with you, but I don't think this issue is new. As I got a bit
confused as to why the call is needed in open() (there's no explanation in
this patch), I think fixing the problem in 08/10 would be better.
> >> Signed-off-by: Mahesh Kumar
> >> Cc: dri-de...@lists.freedesktop.org
> >> Reviewed-by: Maarten Lankhorst
> >> ---
> >>
> >> drivers/gpu/drm/drm_debugfs_crc.c | 15 +++
> >> include/drm/drm_crtc.h| 15 +++
> >> 2 files changed, 30 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> >> b/drivers/gpu/drm/drm_debugfs_crc.c index 9f8312137cad..c6a725b79ac6
> >> 100644
> >> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> >> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> >> @@ -87,6 +87,8 @@ static ssize_t crc_control_write(struct file *file,
> >> const
> >> char __user *ubuf, struct drm_crtc *crtc = m->private;
> >>
> >>struct drm_crtc_crc *crc = >crc;
> >>char *source;
> >>
> >> + size_t values_cnt;
> >> + int ret = 0;
> >>
> >>if (len == 0)
> >>
> >>return 0;
> >>
> >> @@ -104,6 +106,12 @@ static ssize_t crc_control_write(struct file *file,
> >> const char __user *ubuf, if (source[len] == '\n')
> >>
> >>source[len] = '\0';
> >>
> >> + if (crtc->funcs->verify_crc_source) {
> >> + ret = crtc->funcs->verify_crc_source(crtc, source, _cnt);
> >> + if (ret)
> >> + return ret;
> >> + }
> >> +
> >>
> >>spin_lock_irq(>lock);
> >>
> >>if (crc->opened) {
> >>
> >> @@ -167,6 +175,13 @@ static int crtc_crc_open(struct inode *inode, struct
> >> file *filep) return ret;
> >>
> >>}
> >>
> >> + if (crtc->funcs->verify_crc_source) {
> >> + ret = crtc->funcs->verify_crc_source(crtc, crc->source,
> >> + _cnt);
> >> + if (ret)
> >> + return ret;
> >> + }
> >> +
> >>
> >>spin_lock_irq(>lock);
> >>if (!crc->opened)
> >>
> >>crc->opened = true;
> >>
> >> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> >> index 23eddbccab10..1a6dcbf91744 100644
> >> --- a/include/drm/drm_crtc.h
> >> +++ b/include/drm/drm_crtc.h
> >> @@ -661,6 +661,21 @@ struct drm_crtc_funcs {
> >>
> >> */
> >>
> >>int (*set_crc_source)(struct drm_crtc *crtc, const char *source,
> >>
> >> size_t *values_cnt);
> >>
> >> + /**
> >> + * @verify_crc_source:
> >> + *
> >> + * verifies the source of CRC checksums of frames before setting the
> >> + * source for CRC and during crc open.
> >> + *
> >> + * This callback is optional if the driver does not support any CRC
> >> + * generation functionality.
> >> + *
> >> + * RETURNS:
> >> + *
> >> + * 0 on success or a negative error code on failure.
> >> + */
> >> + int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
> >> + size_t *values_cnt);
> >>
> >>/**
> >>
> >> * @atomic_print_state:
--
Regards,
Laurent Pinchart
___
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: Flush the residual parking on emergency shutdown
On 10 July 2018 at 10:44, Chris Wilson wrote: > On unwinding following a critical failure inside GEM init, we also need > to be sure to flush the workers before unloading the module. > > Testcase: igt/drv_module_reload/basic-reload-inject > Signed-off-by: Chris Wilson For the series: Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/11] drm/i915: Stop tracking MRU activity on VMA
Quoting Tvrtko Ursulin (2018-07-10 13:19:51)
>
> On 09/07/2018 14:02, Chris Wilson wrote:
> > Our goal is to remove struct_mutex and replace it with fine grained
> > locking. One of the thorny issues is our eviction logic for reclaiming
> > space for an execbuffer (or GTT mmaping, among a few other examples).
> > While eviction itself is easy to move under a per-VM mutex, performing
> > the activity tracking is less agreeable. One solution is not to do any
> > MRU tracking and do a simple coarse evaluation during eviction of
> > active/inactive, with a loose temporal ordering of last
> > insertion/evaluation. That keeps all the locking constrained to when we
> > are manipulating the VM itself, neatly avoiding the tricky handling of
> > possible recursive locking during execbuf and elsewhere.
> >
> > Note that discarding the MRU is unlikely to impact upon our efficiency
> > to reclaim VM space (where we think a LRU model is best) as our
> > current strategy is to use random idle replacement first before doing
> > a search, and over time the use of softpinned 48b per-ppGTT is growing
> > (thereby eliminating any need to perform any eviction searches, in
> > theory at least).
>
> It's a big change to eviction logic but also mostly affects GGTT which
> is diminishing in significance. But we still probably need some real
> world mmap_gtt users to benchmark and general 3d pre-ppgtt.
mmap_gtt is not really significant here as we use random replacement
almost exclusively for them.
Any workload that relies on thrashing is a lost cause more or less; we
can not implement an optimal eviction strategy (no fore knowledge) and
even MRU is suggested by some of the literature as not being a good
strategy for graphics (the evidence in games are that the MRU reused
surfaces in a frame are typically use-once whereas the older surfaces
are typically used at the start of each frame; it is those use once
surfaces that then distort the MRU into making a bad prediction).
Fwiw, you will never get a demo with a >GTT working set that isn't a
slideshow, simply because we don't have the memory bw :-p
(Those machines have ~6GB/s main memory bw, a few fold higher while
in the LLC cache, but not enough to sustain ~180GB/s for the example,
even ignoring all the other ratelimiting steps.)
> > diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
> > b/drivers/gpu/drm/i915/i915_gem_evict.c
> > index 02b83a5ed96c..6a3608398d2a 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> > @@ -127,14 +127,10 @@ i915_gem_evict_something(struct i915_address_space
> > *vm,
> > struct drm_i915_private *dev_priv = vm->i915;
> > struct drm_mm_scan scan;
> > struct list_head eviction_list;
> > - struct list_head *phases[] = {
> > - >inactive_list,
> > - >active_list,
> > - NULL,
> > - }, **phase;
> > struct i915_vma *vma, *next;
> > struct drm_mm_node *node;
> > enum drm_mm_insert_mode mode;
> > + struct i915_vma *active;
> > int ret;
> >
> > lockdep_assert_held(>i915->drm.struct_mutex);
> > @@ -170,17 +166,31 @@ i915_gem_evict_something(struct i915_address_space
> > *vm,
> >*/
> > if (!(flags & PIN_NONBLOCK))
> > i915_retire_requests(dev_priv);
> > - else
> > - phases[1] = NULL;
> >
>
> There are comments around here referring to active/inactive lists which
> will need updating/removing.
>
> > search_again:
> > + active = NULL;
> > INIT_LIST_HEAD(_list);
> > - phase = phases;
> > - do {
> > - list_for_each_entry(vma, *phase, vm_link)
> > - if (mark_free(, vma, flags, _list))
> > - goto found;
> > - } while (*++phase);
> > + list_for_each_entry_safe(vma, next, >bound_list, vm_link) {
> > + if (i915_vma_is_active(vma)) {
> > + if (vma == active) {
> > + if (flags & PIN_NONBLOCK)
> > + break;
> > +
> > + active = ERR_PTR(-EAGAIN);
> > + }
> > +
> > + if (active != ERR_PTR(-EAGAIN)) {
> > + if (!active)
> > + active = vma;
> > +
> > + list_move_tail(>vm_link,
> > >bound_list);
> > + continue;
> > + }
> > + }
> > +
> > + if (mark_free(, vma, flags, _list))
> > + goto found;
> > + }
>
> This loop need a narrative to explain the process.
active/inactive doesn't cover it?
The comments still make sense to me explaining the code flow. There's
only the conceptual juggle that the two lists are combined into one.
> > @@ -996,10 +993,8 @@ int i915_vma_move_to_active(struct i915_vma *vma,
> >* add the active reference
Re: [Intel-gfx] [PATCH 01/10] drm: crc: Introduce verify_crc_source callback
Hi Mahesh,
Thank you for the patch.
On Monday, 2 July 2018 14:07:20 EEST Mahesh Kumar wrote:
> This patch adds a new callback function "verify_crc_source" which will
> be used during setting the crc source in control node and while opening
> data node for crc reading. This will help in avoiding setting of wrong
> string for source.
Why do you need to verify the source in the open() operation ? Isn't it enough
to verify it in the write() handler ? The answer to this question might lie in
patch 08/10, in which case I'd add the .verify_crc_source() call in open() in
that patch, not here.
> Signed-off-by: Mahesh Kumar
> Cc: dri-de...@lists.freedesktop.org
> Reviewed-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_debugfs_crc.c | 15 +++
> include/drm/drm_crtc.h| 15 +++
> 2 files changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> b/drivers/gpu/drm/drm_debugfs_crc.c index 9f8312137cad..c6a725b79ac6 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -87,6 +87,8 @@ static ssize_t crc_control_write(struct file *file, const
> char __user *ubuf, struct drm_crtc *crtc = m->private;
> struct drm_crtc_crc *crc = >crc;
> char *source;
> + size_t values_cnt;
> + int ret = 0;
>
> if (len == 0)
> return 0;
> @@ -104,6 +106,12 @@ static ssize_t crc_control_write(struct file *file,
> const char __user *ubuf, if (source[len] == '\n')
> source[len] = '\0';
>
> + if (crtc->funcs->verify_crc_source) {
> + ret = crtc->funcs->verify_crc_source(crtc, source, _cnt);
> + if (ret)
> + return ret;
> + }
> +
> spin_lock_irq(>lock);
>
> if (crc->opened) {
> @@ -167,6 +175,13 @@ static int crtc_crc_open(struct inode *inode, struct
> file *filep) return ret;
> }
>
> + if (crtc->funcs->verify_crc_source) {
> + ret = crtc->funcs->verify_crc_source(crtc, crc->source,
> + _cnt);
> + if (ret)
> + return ret;
> + }
> +
> spin_lock_irq(>lock);
> if (!crc->opened)
> crc->opened = true;
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 23eddbccab10..1a6dcbf91744 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -661,6 +661,21 @@ struct drm_crtc_funcs {
>*/
> int (*set_crc_source)(struct drm_crtc *crtc, const char *source,
> size_t *values_cnt);
> + /**
> + * @verify_crc_source:
> + *
> + * verifies the source of CRC checksums of frames before setting the
> + * source for CRC and during crc open.
> + *
> + * This callback is optional if the driver does not support any CRC
> + * generation functionality.
> + *
> + * RETURNS:
> + *
> + * 0 on success or a negative error code on failure.
> + */
> + int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
> + size_t *values_cnt);
>
> /**
>* @atomic_print_state:
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/10] drm: crc: Introduce get_crc_sources callback
Hi Mahesh,
Thank you for the patch.
On Monday, 2 July 2018 14:07:21 EEST Mahesh Kumar wrote:
> This patch introduce a callback function "get_crc_sources" which
> will be called during read of control node. It is an optional
> callback function and if driver implements this callback, driver
> should print list of available CRC sources in seq_file privided
> as an input to the callback.
The commit message seems to be outdated, the callback doesn't take a seq_file
anymore.
> Changes Since V1: (Daniel)
> - return const pointer to an array of crc sources list
> - do validation of sources in CRC-core
>
> Signed-off-by: Mahesh Kumar
> Cc: dri-de...@lists.freedesktop.org
> Reviewed-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_debugfs_crc.c | 20 +++-
> include/drm/drm_crtc.h| 16
> 2 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> b/drivers/gpu/drm/drm_debugfs_crc.c index c6a725b79ac6..f4d76528d24c 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -67,9 +67,27 @@
> static int crc_control_show(struct seq_file *m, void *data)
> {
> struct drm_crtc *crtc = m->private;
> + size_t count;
Count it only used within the if () {} block, you can declare it there.
> +
> + if (crtc->funcs->get_crc_sources) {
> + const char *const *sources = crtc->funcs->get_crc_sources(crtc,
> + );
> + size_t values_cnt;
> + int i;
I only takes positive values, it can be an unsigned int.
> +
> + if (count <= 0 || !sources)
count is a size_t, it can't be negative.
The .get_crc_sources() documentation doesn't clearly specify whether sources
should always be NULL when count is zero. I advise updating the documentation,
and possibly updating this check accordingly.
> + goto out;
> +
> + seq_puts(m, "[");
> + for (i = 0; i < count; i++)
> + if (!crtc->funcs->verify_crc_source(crtc, sources[i],
> + _cnt))
I assume that you verify sources one by one here to avoid having to create a
list of sources dynamically in the .get_crc_sources() callback ? If so, I
think the .get_crc_sources() callback should document that.
You should also document that .verify_crc_source() is required when
get_crc_sources() is provided.
> + seq_printf(m, "%s ", sources[i]);
> + seq_puts(m, "] ");
This assumes that source names can't include a space. Isn't that too
restrictive ? Shouldn't a different separator be used ? How about one source
name per line ?
Additionally, shouldn't the active source be marked ?
> + }
>
> +out:
> seq_printf(m, "%s\n", crtc->crc.source);
> -
> return 0;
> }
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 1a6dcbf91744..ffaec138aeee 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -676,6 +676,22 @@ struct drm_crtc_funcs {
>*/
> int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
>size_t *values_cnt);
> + /**
> + * @get_crc_sources:
> + *
> + * Driver callback for getting a list of all the available sources for
> + * CRC generation.
> + *
> + * This callback is optional if the driver does not support exporting of
> + * possible CRC sources list. CRC-core does the verification of sources.
> + *
> + * RETURNS:
> + *
> + * a constant character pointer to the list of all the available CRC
> + * sources
> + */
> + const char *const *(*get_crc_sources)(struct drm_crtc *crtc,
> + size_t *count);
>
> /**
>* @atomic_print_state:
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib: Require working GEM (!wedged) to allow hang injection
As we ordinarily use a spinning batch to trigger a hang, we cannot do so without execbuf. On the other hand, if we do a manual reset of the wedged driver, we expect it to remain wedged and for the reset to fail; failing the test. Even if we remove the igt_assert(!wedged), the test is suspect as we don't know if the reset took place and so do not know if the conditions the test is trying to setup apply. Signed-off-by: Chris Wilson --- lib/igt_gt.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/lib/igt_gt.c b/lib/igt_gt.c index 4569fd36b..89b318ae6 100644 --- a/lib/igt_gt.c +++ b/lib/igt_gt.c @@ -162,6 +162,13 @@ igt_hang_t igt_allow_hang(int fd, unsigned ctx, unsigned flags) }; unsigned ban; + /* +* If the driver is already wedged, we don't expect it to be able +* to recover from reset and for it to remain wedged. It's hard to +* say even if we do hang/reset making the test suspect. +*/ + igt_require_gem(fd); + igt_assert(igt_sysfs_set_parameter (fd, "reset", "%d", INT_MAX /* any reset method */)); -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/10] drm/rcar-du/crc: Implement verify_crc_source callback
Hi Mahesh,
Thank you for the patch.
On Monday, 2 July 2018 14:07:24 EEST Mahesh Kumar wrote:
> This patch implements "verify_crc_source" callback function for
> rcar drm driver.
>
> Signed-off-by: Mahesh Kumar
> Cc: dri-de...@lists.freedesktop.org
> Reviewed-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 40 +++
> 1 file changed, 40 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 15dc9caa128b..24eeaa7e14d7
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -756,6 +756,45 @@ static void rcar_du_crtc_disable_vblank(struct drm_crtc
> *crtc) rcrtc->vblank_enable = false;
> }
>
> +static int rcar_du_crtc_verify_crc_source(struct drm_crtc *crtc,
> + const char *source_name,
> + size_t *values_cnt)
> +{
> + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> + unsigned int index = 0;
> + unsigned int i;
> + int ret;
> +
> + /*
> + * Parse the source name. Supported values are "plane%u" to compute the
> + * CRC on an input plane (%u is the plane ID), and "auto" to compute the
> + * CRC on the composer (VSP) output.
> + */
> + if (!source_name || !strcmp(source_name, "auto")) {
> + goto out;
> + } else if (strstarts(source_name, "plane")) {
> + ret = kstrtouint(source_name + strlen("plane"), 10, );
> + if (ret < 0)
> + return ret;
> +
> + for (i = 0; i < rcrtc->vsp->num_planes; ++i) {
> + if (index == rcrtc->vsp->planes[i].plane.base.id) {
> + index = i;
> + break;
> + }
> + }
> +
> + if (i >= rcrtc->vsp->num_planes)
> + return -EINVAL;
> + } else {
> + return -EINVAL;
> + }
> +
> +out:
> + *values_cnt = 1;
> + return 0;
This duplicates lots of code from the rcar_du_crtc_set_crc_source() function.
Could you please extract it to a shared function ?
Could you please also implement support for the .get_crc_sources() operation ?
I think doing so might show limitations in the current API, namely the fact
that the list will need to be dynamically created for this driver.
> +}
> +
> static int rcar_du_crtc_set_crc_source(struct drm_crtc *crtc,
> const char *source_name,
> size_t *values_cnt)
> @@ -861,6 +900,7 @@ static const struct drm_crtc_funcs crtc_funcs_gen3 = {
> .enable_vblank = rcar_du_crtc_enable_vblank,
> .disable_vblank = rcar_du_crtc_disable_vblank,
> .set_crc_source = rcar_du_crtc_set_crc_source,
> + .verify_crc_source = rcar_du_crtc_verify_crc_source,
> };
>
> /*
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/10] drm: crc: Introduce get_crc_sources callback
Hi Mahesh,
On Tuesday, 10 July 2018 15:01:38 EEST Kumar, Mahesh wrote:
> On 7/10/2018 4:52 PM, Laurent Pinchart wrote:
> > Hi Mahesh,
> > On Monday, 2 July 2018 14:07:21 EEST Mahesh Kumar wrote:
> >> This patch introduce a callback function "get_crc_sources" which
> >> will be called during read of control node. It is an optional
> >> callback function and if driver implements this callback, driver
> >> should print list of available CRC sources in seq_file privided
> >> as an input to the callback.
> >
> > The commit message seems to be outdated, the callback doesn't take a
> > seq_file anymore.
>
> ops, will update.
>
> >> Changes Since V1: (Daniel)
> >>
> >> - return const pointer to an array of crc sources list
> >> - do validation of sources in CRC-core
> >>
> >> Signed-off-by: Mahesh Kumar
> >> Cc: dri-de...@lists.freedesktop.org
> >> Reviewed-by: Maarten Lankhorst
> >> ---
> >>
> >> drivers/gpu/drm/drm_debugfs_crc.c | 20 +++-
> >> include/drm/drm_crtc.h| 16
> >> 2 files changed, 35 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> >> b/drivers/gpu/drm/drm_debugfs_crc.c index c6a725b79ac6..f4d76528d24c
> >> 100644
> >> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> >> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> >> @@ -67,9 +67,27 @@
> >>
> >> static int crc_control_show(struct seq_file *m, void *data)
> >> {
> >>
> >>struct drm_crtc *crtc = m->private;
> >>
> >> + size_t count;
> >
> > Count it only used within the if () {} block, you can declare it there.
>
> agree.
>
> >> +
> >> + if (crtc->funcs->get_crc_sources) {
> >> + const char *const *sources = crtc->funcs->get_crc_sources(crtc,
> >> + );
> >> + size_t values_cnt;
> >> + int i;
> >
> > I only takes positive values, it can be an unsigned int.
>
> ok
>
> >> +
> >> + if (count <= 0 || !sources)
> >
> > count is a size_t, it can't be negative.
> >
> > The .get_crc_sources() documentation doesn't clearly specify whether
> > sources should always be NULL when count is zero. I advise updating the
> > documentation, and possibly updating this check accordingly.
>
> ok will update.
>
> >> + goto out;
> >> +
> >> + seq_puts(m, "[");
> >> + for (i = 0; i < count; i++)
> >> + if (!crtc->funcs->verify_crc_source(crtc, sources[i],
> >> + _cnt))
> >
> > I assume that you verify sources one by one here to avoid having to create
> > a list of sources dynamically in the .get_crc_sources() callback ? If so,
> > I think the .get_crc_sources() callback should document that.
> >
> > You should also document that .verify_crc_source() is required when
> > get_crc_sources() is provided.
>
> ok sure.
>
> >> + seq_printf(m, "%s ", sources[i]);
> >> + seq_puts(m, "] ");
> >
> > This assumes that source names can't include a space. Isn't that too
> > restrictive ? Shouldn't a different separator be used ? How about one
> > source name per line ?
>
> what about comma separated as I'm putting names inside square-brackets?
>
> > Additionally, shouldn't the active source be marked ?
>
> active source is again printed by the code in next few lines. output
> will be of following format.
> [space separated list of valid sources] active_source
I had missed that, my bad.
The proposed format seems a bit hackish to me, in the sense that it forbids
both spaces and brackets in source names. One source per line would fix both
and be easy to parse. We would then need to mark the active source, which
could be done by adding a marker to the corresponding line (maybe a * at the
end of the line ?).
> >> + }
> >>
> >> +out:
> >>seq_printf(m, "%s\n", crtc->crc.source);
> >> -
> >>return 0;
> >> }
[snip]
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/10] drm: crc: Introduce get_crc_sources callback
Hi,
On 7/10/2018 5:39 PM, Laurent Pinchart wrote:
Hi Mahesh,
On Tuesday, 10 July 2018 15:01:38 EEST Kumar, Mahesh wrote:
On 7/10/2018 4:52 PM, Laurent Pinchart wrote:
Hi Mahesh,
On Monday, 2 July 2018 14:07:21 EEST Mahesh Kumar wrote:
This patch introduce a callback function "get_crc_sources" which
will be called during read of control node. It is an optional
callback function and if driver implements this callback, driver
should print list of available CRC sources in seq_file privided
as an input to the callback.
The commit message seems to be outdated, the callback doesn't take a
seq_file anymore.
ops, will update.
Changes Since V1: (Daniel)
- return const pointer to an array of crc sources list
- do validation of sources in CRC-core
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_debugfs_crc.c | 20 +++-
include/drm/drm_crtc.h| 16
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c index c6a725b79ac6..f4d76528d24c
100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -67,9 +67,27 @@
static int crc_control_show(struct seq_file *m, void *data)
{
struct drm_crtc *crtc = m->private;
+ size_t count;
Count it only used within the if () {} block, you can declare it there.
agree.
+
+ if (crtc->funcs->get_crc_sources) {
+ const char *const *sources = crtc->funcs->get_crc_sources(crtc,
+ );
+ size_t values_cnt;
+ int i;
I only takes positive values, it can be an unsigned int.
ok
+
+ if (count <= 0 || !sources)
count is a size_t, it can't be negative.
The .get_crc_sources() documentation doesn't clearly specify whether
sources should always be NULL when count is zero. I advise updating the
documentation, and possibly updating this check accordingly.
ok will update.
+ goto out;
+
+ seq_puts(m, "[");
+ for (i = 0; i < count; i++)
+ if (!crtc->funcs->verify_crc_source(crtc, sources[i],
+ _cnt))
I assume that you verify sources one by one here to avoid having to create
a list of sources dynamically in the .get_crc_sources() callback ? If so,
I think the .get_crc_sources() callback should document that.
You should also document that .verify_crc_source() is required when
get_crc_sources() is provided.
ok sure.
+ seq_printf(m, "%s ", sources[i]);
+ seq_puts(m, "] ");
This assumes that source names can't include a space. Isn't that too
restrictive ? Shouldn't a different separator be used ? How about one
source name per line ?
what about comma separated as I'm putting names inside square-brackets?
Additionally, shouldn't the active source be marked ?
active source is again printed by the code in next few lines. output
will be of following format.
[space separated list of valid sources] active_source
I had missed that, my bad.
The proposed format seems a bit hackish to me, in the sense that it forbids
both spaces and brackets in source names. One source per line would fix both
and be easy to parse. We would then need to mark the active source, which
could be done by adding a marker to the corresponding line (maybe a * at the
end of the line ?).
sounds good, will do that.
-Mahesh
+ }
+out:
seq_printf(m, "%s\n", crtc->crc.source);
-
return 0;
}
[snip]
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/10] drm: crc: Introduce verify_crc_source callback
Hi,
On 7/10/2018 5:40 PM, Laurent Pinchart wrote:
Hi Mahesh,
On Tuesday, 10 July 2018 14:54:11 EEST Kumar, Mahesh wrote:
On 7/10/2018 4:56 PM, Laurent Pinchart wrote:
On Monday, 2 July 2018 14:07:20 EEST Mahesh Kumar wrote:
This patch adds a new callback function "verify_crc_source" which will
be used during setting the crc source in control node and while opening
data node for crc reading. This will help in avoiding setting of wrong
string for source.
Why do you need to verify the source in the open() operation ? Isn't it
enough to verify it in the write() handler ? The answer to this question
might lie in patch 08/10, in which case I'd add the .verify_crc_source()
call in open() in that patch, not here.
Yes, final goal is achieved by patch 08/10. But if crc_read is called
before setting the source, it may have wrong source set in that case I
wanted to return early at least for the drivers implemented
verify_crc_source. If you still think otherwise I will modify
accordingly in next series.
I don't disagree with you, but I don't think this issue is new. As I got a bit
confused as to why the call is needed in open() (there's no explanation in
this patch), I think fixing the problem in 08/10 would be better.
ok sure :)
-Mahesh
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_debugfs_crc.c | 15 +++
include/drm/drm_crtc.h| 15 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c index 9f8312137cad..c6a725b79ac6
100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -87,6 +87,8 @@ static ssize_t crc_control_write(struct file *file,
const
char __user *ubuf, struct drm_crtc *crtc = m->private;
struct drm_crtc_crc *crc = >crc;
char *source;
+ size_t values_cnt;
+ int ret = 0;
if (len == 0)
return 0;
@@ -104,6 +106,12 @@ static ssize_t crc_control_write(struct file *file,
const char __user *ubuf, if (source[len] == '\n')
source[len] = '\0';
+ if (crtc->funcs->verify_crc_source) {
+ ret = crtc->funcs->verify_crc_source(crtc, source, _cnt);
+ if (ret)
+ return ret;
+ }
+
spin_lock_irq(>lock);
if (crc->opened) {
@@ -167,6 +175,13 @@ static int crtc_crc_open(struct inode *inode, struct
file *filep) return ret;
}
+ if (crtc->funcs->verify_crc_source) {
+ ret = crtc->funcs->verify_crc_source(crtc, crc->source,
+_cnt);
+ if (ret)
+ return ret;
+ }
+
spin_lock_irq(>lock);
if (!crc->opened)
crc->opened = true;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 23eddbccab10..1a6dcbf91744 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -661,6 +661,21 @@ struct drm_crtc_funcs {
*/
int (*set_crc_source)(struct drm_crtc *crtc, const char *source,
size_t *values_cnt);
+ /**
+* @verify_crc_source:
+*
+* verifies the source of CRC checksums of frames before setting the
+* source for CRC and during crc open.
+*
+* This callback is optional if the driver does not support any CRC
+* generation functionality.
+*
+* RETURNS:
+*
+* 0 on success or a negative error code on failure.
+*/
+ int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
+size_t *values_cnt);
/**
* @atomic_print_state:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/11] drm/i915: Stop tracking MRU activity on VMA
On 09/07/2018 14:02, Chris Wilson wrote:
Our goal is to remove struct_mutex and replace it with fine grained
locking. One of the thorny issues is our eviction logic for reclaiming
space for an execbuffer (or GTT mmaping, among a few other examples).
While eviction itself is easy to move under a per-VM mutex, performing
the activity tracking is less agreeable. One solution is not to do any
MRU tracking and do a simple coarse evaluation during eviction of
active/inactive, with a loose temporal ordering of last
insertion/evaluation. That keeps all the locking constrained to when we
are manipulating the VM itself, neatly avoiding the tricky handling of
possible recursive locking during execbuf and elsewhere.
Note that discarding the MRU is unlikely to impact upon our efficiency
to reclaim VM space (where we think a LRU model is best) as our
current strategy is to use random idle replacement first before doing
a search, and over time the use of softpinned 48b per-ppGTT is growing
(thereby eliminating any need to perform any eviction searches, in
theory at least).
It's a big change to eviction logic but also mostly affects GGTT which
is diminishing in significance. But we still probably need some real
world mmap_gtt users to benchmark and general 3d pre-ppgtt.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 10 +---
drivers/gpu/drm/i915/i915_gem_evict.c | 56 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 15 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 26 +
drivers/gpu/drm/i915/i915_gem_shrinker.c | 8 ++-
drivers/gpu/drm/i915/i915_gem_stolen.c| 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 37 ++--
drivers/gpu/drm/i915/i915_vma.c | 9 +--
.../gpu/drm/i915/selftests/i915_gem_evict.c | 4 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
10 files changed, 68 insertions(+), 101 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b35cbfd16c9c..3bc2d40e6e0f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -251,10 +251,7 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void
*data,
pinned = ggtt->vm.reserved;
mutex_lock(>struct_mutex);
- list_for_each_entry(vma, >vm.active_list, vm_link)
- if (i915_vma_is_pinned(vma))
- pinned += vma->node.size;
- list_for_each_entry(vma, >vm.inactive_list, vm_link)
+ list_for_each_entry(vma, >vm.bound_list, vm_link)
if (i915_vma_is_pinned(vma))
pinned += vma->node.size;
mutex_unlock(>struct_mutex);
@@ -1684,13 +1681,10 @@ static void i915_gem_object_bump_inactive_ggtt(struct
drm_i915_gem_object *obj)
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
for_each_ggtt_vma(vma, obj) {
- if (i915_vma_is_active(vma))
- continue;
-
if (!drm_mm_node_allocated(>node))
continue;
- list_move_tail(>vm_link, >vm->inactive_list);
+ list_move_tail(>vm_link, >vm->bound_list);
}
i915 = to_i915(obj->base.dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 02b83a5ed96c..6a3608398d2a 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -127,14 +127,10 @@ i915_gem_evict_something(struct i915_address_space *vm,
struct drm_i915_private *dev_priv = vm->i915;
struct drm_mm_scan scan;
struct list_head eviction_list;
- struct list_head *phases[] = {
- >inactive_list,
- >active_list,
- NULL,
- }, **phase;
struct i915_vma *vma, *next;
struct drm_mm_node *node;
enum drm_mm_insert_mode mode;
+ struct i915_vma *active;
int ret;
lockdep_assert_held(>i915->drm.struct_mutex);
@@ -170,17 +166,31 @@ i915_gem_evict_something(struct i915_address_space *vm,
*/
if (!(flags & PIN_NONBLOCK))
i915_retire_requests(dev_priv);
- else
- phases[1] = NULL;
There are comments around here referring to active/inactive lists which
will need updating/removing.
search_again:
+ active = NULL;
INIT_LIST_HEAD(_list);
- phase = phases;
- do {
- list_for_each_entry(vma, *phase, vm_link)
- if (mark_free(, vma, flags, _list))
- goto found;
- } while (*++phase);
+ list_for_each_entry_safe(vma, next, >bound_list, vm_link) {
+ if (i915_vma_is_active(vma)) {
+ if (vma == active) {
+ if (flags & PIN_NONBLOCK)
+ break;
+
+ active = ERR_PTR(-EAGAIN);
+
Re: [Intel-gfx] [PATCH 08/11] drm/i915: Move fence-reg interface to i915_gem_fence_reg.h
Chris Wilson writes:
> Since we have a header file for i915_gem_fence_reg, let's use it for the
> interface prototypes currently hidden away in the huge i915_drv.h
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_drv.h | 15 ---
> drivers/gpu/drm/i915/i915_gem_fence_reg.h | 16
> drivers/gpu/drm/i915/i915_vma.h | 2 +-
> 3 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f05a0b7e4baf..ea2de36540da 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -70,7 +70,6 @@
>
> #include "i915_gem.h"
> #include "i915_gem_context.h"
> -#include "i915_gem_fence_reg.h"
> #include "i915_gem_object.h"
> #include "i915_gem_gtt.h"
> #include "i915_gpu_error.h"
> @@ -3193,20 +3192,6 @@ i915_vm_to_ppgtt(struct i915_address_space *vm)
> return container_of(vm, struct i915_hw_ppgtt, vm);
> }
>
> -/* i915_gem_fence_reg.c */
> -struct drm_i915_fence_reg *
> -i915_reserve_fence(struct drm_i915_private *dev_priv);
> -void i915_unreserve_fence(struct drm_i915_fence_reg *fence);
> -
> -void i915_gem_revoke_fences(struct drm_i915_private *dev_priv);
> -void i915_gem_restore_fences(struct drm_i915_private *dev_priv);
> -
> -void i915_gem_detect_bit_6_swizzle(struct drm_i915_private *dev_priv);
> -void i915_gem_object_do_bit_17_swizzle(struct drm_i915_gem_object *obj,
> -struct sg_table *pages);
> -void i915_gem_object_save_bit_17_swizzle(struct drm_i915_gem_object *obj,
> - struct sg_table *pages);
> -
> static inline struct i915_gem_context *
> __i915_gem_context_lookup_rcu(struct drm_i915_file_private *file_priv, u32
> id)
> {
> diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.h
> b/drivers/gpu/drm/i915/i915_gem_fence_reg.h
> index c8f1d0cdfa90..c510f8efc1bb 100644
> --- a/drivers/gpu/drm/i915/i915_gem_fence_reg.h
> +++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.h
> @@ -27,7 +27,10 @@
>
> #include
>
> +struct sg_table;
> +
> struct drm_i915_private;
> +struct drm_i915_gem_object;
> struct i915_ggtt;
> struct i915_vma;
>
> @@ -55,4 +58,17 @@ struct drm_i915_fence_reg {
>
> void i915_ggtt_init_fences(struct i915_ggtt *ggtt);
>
> +struct drm_i915_fence_reg *
> +i915_reserve_fence(struct drm_i915_private *i915);
> +void i915_unreserve_fence(struct drm_i915_fence_reg *fence);
> +
> +void i915_gem_revoke_fences(struct drm_i915_private *i915);
> +void i915_gem_restore_fences(struct drm_i915_private *i915);
> +
> +void i915_gem_detect_bit_6_swizzle(struct drm_i915_private *i915);
> +void i915_gem_object_do_bit_17_swizzle(struct drm_i915_gem_object *obj,
> +struct sg_table *pages);
> +void i915_gem_object_save_bit_17_swizzle(struct drm_i915_gem_object *obj,
> + struct sg_table *pages);
> +
> #endif
> diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
> index 422d90c686b5..925af79cc6d6 100644
> --- a/drivers/gpu/drm/i915/i915_vma.h
> +++ b/drivers/gpu/drm/i915/i915_vma.h
> @@ -31,12 +31,12 @@
> #include
>
> #include "i915_gem_gtt.h"
> -#include "i915_gem_fence_reg.h"
> #include "i915_gem_object.h"
>
> #include "i915_request.h"
>
> enum i915_cache_level;
> +struct drm_i915_fence_reg;
>
> /**
> * A VMA represents a GEM BO that is bound into an address space. Therefore,
> a
> --
> 2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for ICELAKE DSI DRIVER (rev5)
== Series Details == Series: ICELAKE DSI DRIVER (rev5) URL : https://patchwork.freedesktop.org/series/44823/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4462 -> Patchwork_9603 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/44823/revisions/5/mbox/ == Known issues == Here are the changes found in Patchwork_9603 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: PASS -> DMESG-WARN (fdo#105128, fdo#107139) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 == Participating hosts (47 -> 40) == Missing(7): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-byt-squawks fi-bsw-cyan fi-kbl-guc fi-ctg-p8600 == Build changes == * Linux: CI_DRM_4462 -> Patchwork_9603 CI_DRM_4462: d4e71d9d380fd82c93708cc29704a011dc9948ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4544: 764160f214cd916ddb79408b9f28ac0ad2df40e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9603: e04c020b54297b15e459bc86b3355202107738ea @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e04c020b5429 drm/i915/icl: Configure DSI transcoders 0120accb0f10 drm/i915/icl: Define TRANS_DSI_FUNC_CONF register 2fa57a5edb01 drm/i915/icl: Add macros for MMIO of DSI transcoder registers 77e315ff7682 drm/i915/icl: Get DSI transcoder for a given port 4140659db9be drm/i915/icl: Program TA_TIMING_PARAM registers d6b44b4626d5 drm/i915/icl: Define TA_TIMING_PARAM registers 647b5964795f drm/i915/icl: Program DSI clock and data lane timing params 5f50bd44df15 drm/i915/icl: Define data/clock lanes dphy timing registers c76c29dcd686 drm/i915/icl: Program T_INIT_MASTER registers e255c1a37c33 drm/i915/icl: Define T_INIT_MASTER registers 392c529052c6 drm/i915/icl: Enable DDI Buffer c677ebaee69e drm/i915/icl: DSI vswing programming sequence 30f4f160de53 drm/i915/icl: Configure lane sequencing of combo phy transmitter == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9603/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/11] drm/i915: Tidy i915_gem_suspend()
Chris Wilson writes:
> In the next patch, we will make a fairly minor change to flush
> outstanding resets before suspend. In order to keep churn to a minimum
> in that functional patch, we fix up the comments and coding style now.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c | 50 +
> 1 file changed, 26 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index b730a53b426b..6a1bb88b5730 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5029,32 +5029,32 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
> mutex_unlock(>drm.struct_mutex);
> }
>
> -int i915_gem_suspend(struct drm_i915_private *dev_priv)
> +int i915_gem_suspend(struct drm_i915_private *i915)
> {
> - struct drm_device *dev = _priv->drm;
> int ret;
>
> GEM_TRACE("\n");
>
> - intel_runtime_pm_get(dev_priv);
> - intel_suspend_gt_powersave(dev_priv);
> + intel_runtime_pm_get(i915);
> + intel_suspend_gt_powersave(i915);
>
> - mutex_lock(>struct_mutex);
> + mutex_lock(>drm.struct_mutex);
>
> - /* We have to flush all the executing contexts to main memory so
> + /*
> + * We have to flush all the executing contexts to main memory so
>* that they can saved in the hibernation image. To ensure the last
>* context image is coherent, we have to switch away from it. That
> - * leaves the dev_priv->kernel_context still active when
> + * leaves the i915->kernel_context still active when
>* we actually suspend, and its image in memory may not match the GPU
>* state. Fortunately, the kernel_context is disposable and we do
>* not rely on its state.
>*/
> - if (!i915_terminally_wedged(_priv->gpu_error)) {
> - ret = i915_gem_switch_to_kernel_context(dev_priv);
> + if (!i915_terminally_wedged(>gpu_error)) {
> + ret = i915_gem_switch_to_kernel_context(i915);
> if (ret)
> goto err_unlock;
>
> - ret = i915_gem_wait_for_idle(dev_priv,
> + ret = i915_gem_wait_for_idle(i915,
>I915_WAIT_INTERRUPTIBLE |
>I915_WAIT_LOCKED |
>I915_WAIT_FOR_IDLE_BOOST,
> @@ -5062,33 +5062,35 @@ int i915_gem_suspend(struct drm_i915_private
> *dev_priv)
> if (ret && ret != -EIO)
> goto err_unlock;
>
> - assert_kernel_context_is_current(dev_priv);
> + assert_kernel_context_is_current(i915);
> }
> - mutex_unlock(>struct_mutex);
> + mutex_unlock(>drm.struct_mutex);
>
> - intel_uc_suspend(dev_priv);
> + intel_uc_suspend(i915);
>
> - cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
> - cancel_delayed_work_sync(_priv->gt.retire_work);
> + cancel_delayed_work_sync(>gpu_error.hangcheck_work);
> + cancel_delayed_work_sync(>gt.retire_work);
>
> - /* As the idle_work is rearming if it detects a race, play safe and
> + /*
> + * As the idle_work is rearming if it detects a race, play safe and
>* repeat the flush until it is definitely idle.
>*/
> - drain_delayed_work(_priv->gt.idle_work);
> + drain_delayed_work(>gt.idle_work);
>
> - /* Assert that we sucessfully flushed all the work and
> + /*
> + * Assert that we successfully flushed all the work and
>* reset the GPU back to its idle, low power state.
>*/
> - WARN_ON(dev_priv->gt.awake);
> - if (WARN_ON(!intel_engines_are_idle(dev_priv)))
> - i915_gem_set_wedged(dev_priv); /* no hope, discard everything */
> + WARN_ON(i915->gt.awake);
> + if (WARN_ON(!intel_engines_are_idle(i915)))
> + i915_gem_set_wedged(i915); /* no hope, discard everything */
>
> - intel_runtime_pm_put(dev_priv);
> + intel_runtime_pm_put(i915);
> return 0;
>
> err_unlock:
> - mutex_unlock(>struct_mutex);
> - intel_runtime_pm_put(dev_priv);
> + mutex_unlock(>drm.struct_mutex);
> + intel_runtime_pm_put(i915);
> return ret;
> }
>
> --
> 2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Flush the residual parking on emergency shutdown
== Series Details == Series: series starting with [1/2] drm/i915: Flush the residual parking on emergency shutdown URL : https://patchwork.freedesktop.org/series/46251/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4461 -> Patchwork_9602 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/46251/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9602 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: PASS -> DMESG-WARN (fdo#105128, fdo#107139) Possible fixes igt@prime_vgem@basic-fence-flip: fi-ilk-650: FAIL (fdo#104008) -> PASS fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 == Participating hosts (47 -> 41) == Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 == Build changes == * Linux: CI_DRM_4461 -> Patchwork_9602 CI_DRM_4461: 078a032f90cfd680ca2efe07b77ca86cc2ba2a87 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4544: 764160f214cd916ddb79408b9f28ac0ad2df40e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9602: 208ab527743feb29b7e5c5127d019c85e2e22eb6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 208ab527743f drm/i915: Cleanup modesetting on load-error path 0a8605b6848b drm/i915: Flush the residual parking on emergency shutdown == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9602/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use crtc_state->has_psr instead of CAN_PSR for pipe update (rev4)
== Series Details == Series: drm/i915: Use crtc_state->has_psr instead of CAN_PSR for pipe update (rev4) URL : https://patchwork.freedesktop.org/series/46104/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4458_full -> Patchwork_9600_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9600_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9600_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_9600_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: PASS -> SKIP igt@gem_exec_schedule@deep-vebox: shard-kbl: SKIP -> PASS +2 == Known issues == Here are the changes found in Patchwork_9600_full that come from known issues: === IGT changes === Issues hit igt@gem_ppgtt@blt-vs-render-ctx0: shard-kbl: PASS -> INCOMPLETE (fdo#103665, fdo#106023) igt@kms_flip@dpms-vs-vblank-race-interruptible: shard-glk: PASS -> FAIL (fdo#103060) igt@kms_rotation_crc@sprite-rotation-180: shard-hsw: PASS -> FAIL (fdo#103925) igt@pm_rpm@system-suspend: shard-kbl: PASS -> INCOMPLETE (fdo#103665) Possible fixes igt@gem_exec_big: shard-hsw: INCOMPLETE (fdo#103540) -> PASS igt@kms_flip@2x-dpms-vs-vblank-race-interruptible: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip@2x-flip-vs-absolute-wf_vblank: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#103822, fdo#107161) -> PASS +1 igt@kms_flip_tiling@flip-y-tiled: shard-glk: FAIL (fdo#107161) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#107161 https://bugs.freedesktop.org/show_bug.cgi?id=107161 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4458 -> Patchwork_9600 CI_DRM_4458: dbed4c29cc0cd0225aae60c57ac2f4a738bb5a17 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4544: 764160f214cd916ddb79408b9f28ac0ad2df40e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9600: 1e1602d46abafb8f5722c411d653376f6b2e3c83 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9600/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for ICELAKE DSI DRIVER (rev5)
== Series Details ==
Series: ICELAKE DSI DRIVER (rev5)
URL : https://patchwork.freedesktop.org/series/44823/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
30f4f160de53 drm/i915/icl: Configure lane sequencing of combo phy transmitter
c677ebaee69e drm/i915/icl: DSI vswing programming sequence
-:33: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#33: FILE: drivers/gpu/drm/i915/icl_dsi.c:39:
+ for_each_dsi_port(port, intel_dsi->ports) {
+
total: 0 errors, 0 warnings, 1 checks, 132 lines checked
392c529052c6 drm/i915/icl: Enable DDI Buffer
e255c1a37c33 drm/i915/icl: Define T_INIT_MASTER registers
c76c29dcd686 drm/i915/icl: Program T_INIT_MASTER registers
5f50bd44df15 drm/i915/icl: Define data/clock lanes dphy timing registers
-:31: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#31: FILE: drivers/gpu/drm/i915/i915_reg.h:10089:
+#define CLK_PREP_TIME(x) (x << 28)
-:33: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#33: FILE: drivers/gpu/drm/i915/i915_reg.h:10091:
+#define CLK_ZERO_TIME(x) (x << 20)
-:35: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#35: FILE: drivers/gpu/drm/i915/i915_reg.h:10093:
+#define CLK_PRE_TIME(x) (x << 16)
-:37: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#37: FILE: drivers/gpu/drm/i915/i915_reg.h:10095:
+#define CLK_POST_TIME(x) (x << 8)
-:39: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#39: FILE: drivers/gpu/drm/i915/i915_reg.h:10097:
+#define CLK_TRAIL_TIME(x) (x << 0)
-:52: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#52: FILE: drivers/gpu/drm/i915/i915_reg.h:10110:
+#define HS_PREP_TIME(x) (x << 24)
-:54: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#54: FILE: drivers/gpu/drm/i915/i915_reg.h:10112:
+#define HS_ZERO_TIME(x) (x << 16)
-:56: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#56: FILE: drivers/gpu/drm/i915/i915_reg.h:10114:
+#define HS_TRAIL_TIME(x) (x << 8)
-:58: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#58: FILE: drivers/gpu/drm/i915/i915_reg.h:10116:
+#define HS_EXIT_TIME(x) (x << 0)
total: 0 errors, 0 warnings, 9 checks, 46 lines checked
647b5964795f drm/i915/icl: Program DSI clock and data lane timing params
-:80: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#80: FILE: drivers/gpu/drm/i915/intel_dsi_vbt.c:631:
+ ths_prepare_ns = max(mipi_config->ths_prepare,
+ mipi_config->tclk_prepare);
-:114: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#114: FILE: drivers/gpu/drm/i915/intel_dsi_vbt.c:655:
+ clk_zero_cnt = DIV_ROUND_UP(
-:128: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#128: FILE: drivers/gpu/drm/i915/intel_dsi_vbt.c:669:
+ hs_zero_cnt = DIV_ROUND_UP(
-:190: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#190: FILE: drivers/gpu/drm/i915/intel_dsi_vbt.c:727:
+ prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * ui_den,
+ ui_num * mul);
-:196: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#196: FILE: drivers/gpu/drm/i915/intel_dsi_vbt.c:731:
+ DRM_DEBUG_KMS("prepare count too high %u\n",
+ prepare_cnt);
-:201: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#201: FILE: drivers/gpu/drm/i915/intel_dsi_vbt.c:736:
+ exit_zero_cnt = DIV_ROUND_UP(
-:226: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#226: FILE: drivers/gpu/drm/i915/intel_dsi_vbt.c:748:
+ if (exit_zero_cnt < (55 * ui_den / ui_num) &&
+ (55 * ui_den) % ui_num)
-:231: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#231: FILE: drivers/gpu/drm/i915/intel_dsi_vbt.c:753:
+ DRM_DEBUG_KMS("exit zero count too high %u\n",
+ exit_zero_cnt);
-:250: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#250: FILE: drivers/gpu/drm/i915/intel_dsi_vbt.c:764:
+ DRM_DEBUG_KMS("clock zero count too high %u\n",
+ clk_zero_cnt);
total: 0 errors, 0 warnings, 9 checks, 293 lines checked
d6b44b4626d5 drm/i915/icl: Define TA_TIMING_PARAM registers
-:31: CHECK:MACRO_ARG_PRECEDENCE:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for ICELAKE DSI DRIVER (rev5)
== Series Details == Series: ICELAKE DSI DRIVER (rev5) URL : https://patchwork.freedesktop.org/series/44823/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/icl: Configure lane sequencing of combo phy transmitter Okay! Commit: drm/i915/icl: DSI vswing programming sequence Okay! Commit: drm/i915/icl: Enable DDI Buffer Okay! Commit: drm/i915/icl: Define T_INIT_MASTER registers Okay! Commit: drm/i915/icl: Program T_INIT_MASTER registers Okay! Commit: drm/i915/icl: Define data/clock lanes dphy timing registers Okay! Commit: drm/i915/icl: Program DSI clock and data lane timing params -O:drivers/gpu/drm/i915/intel_dsi_vbt.c:644:26: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_dsi_vbt.c:644:26: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_dsi_vbt.c:686:25: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_dsi_vbt.c:686:25: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_dsi_vbt.c:718:37: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_dsi_vbt.c:718:37: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_dsi_vbt.c:629:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_dsi_vbt.c:629:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_dsi_vbt.c:630:26: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_dsi_vbt.c:630:26: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_dsi_vbt.c:802:37: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_dsi_vbt.c:802:37: warning: expression using sizeof(void) Commit: drm/i915/icl: Define TA_TIMING_PARAM registers Okay! Commit: drm/i915/icl: Program TA_TIMING_PARAM registers Okay! Commit: drm/i915/icl: Get DSI transcoder for a given port Okay! Commit: drm/i915/icl: Add macros for MMIO of DSI transcoder registers Okay! Commit: drm/i915/icl: Define TRANS_DSI_FUNC_CONF register Okay! Commit: drm/i915/icl: Configure DSI transcoders Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/10] drm/rcar-du/crc: Implement verify_crc_source callback
Hi,
thanks foe the review.
On 7/10/2018 5:07 PM, Laurent Pinchart wrote:
Hi Mahesh,
Thank you for the patch.
On Monday, 2 July 2018 14:07:24 EEST Mahesh Kumar wrote:
This patch implements "verify_crc_source" callback function for
rcar drm driver.
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 40 +++
1 file changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 15dc9caa128b..24eeaa7e14d7
100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -756,6 +756,45 @@ static void rcar_du_crtc_disable_vblank(struct drm_crtc
*crtc) rcrtc->vblank_enable = false;
}
+static int rcar_du_crtc_verify_crc_source(struct drm_crtc *crtc,
+ const char *source_name,
+ size_t *values_cnt)
+{
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ unsigned int index = 0;
+ unsigned int i;
+ int ret;
+
+ /*
+* Parse the source name. Supported values are "plane%u" to compute the
+* CRC on an input plane (%u is the plane ID), and "auto" to compute the
+* CRC on the composer (VSP) output.
+*/
+ if (!source_name || !strcmp(source_name, "auto")) {
+ goto out;
+ } else if (strstarts(source_name, "plane")) {
+ ret = kstrtouint(source_name + strlen("plane"), 10, );
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < rcrtc->vsp->num_planes; ++i) {
+ if (index == rcrtc->vsp->planes[i].plane.base.id) {
+ index = i;
+ break;
+ }
+ }
+
+ if (i >= rcrtc->vsp->num_planes)
+ return -EINVAL;
+ } else {
+ return -EINVAL;
+ }
+
+out:
+ *values_cnt = 1;
+ return 0;
This duplicates lots of code from the rcar_du_crtc_set_crc_source() function.
Could you please extract it to a shared function ?
Agree, it duplicates the code but "index" is needed by set_crc_source call
anyway will create a wrapper to avoid duplication of code.
Could you please also implement support for the .get_crc_sources() operation ?
I think doing so might show limitations in the current API, namely the fact
that the list will need to be dynamically created for this driver.
for that I think rcar_du_crtc_create function can build a dynamic list
during initializing crtc functions, unless plane can be dynamically
allocated to any CRTC. this is the place where I need input from maintainer.
-Mahesh
+}
+
static int rcar_du_crtc_set_crc_source(struct drm_crtc *crtc,
const char *source_name,
size_t *values_cnt)
@@ -861,6 +900,7 @@ static const struct drm_crtc_funcs crtc_funcs_gen3 = {
.enable_vblank = rcar_du_crtc_enable_vblank,
.disable_vblank = rcar_du_crtc_disable_vblank,
.set_crc_source = rcar_du_crtc_set_crc_source,
+ .verify_crc_source = rcar_du_crtc_verify_crc_source,
};
/*
___
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: Flush the residual parking on emergency shutdown
Quoting Matthew Auld (2018-07-10 13:34:02) > On 10 July 2018 at 10:44, Chris Wilson wrote: > > On unwinding following a critical failure inside GEM init, we also need > > to be sure to flush the workers before unloading the module. > > > > Testcase: igt/drv_module_reload/basic-reload-inject > > Signed-off-by: Chris Wilson > > For the series: > Reviewed-by: Matthew Auld Thanks, we should be able to fix drv_module_reload now to stop the errors creeping back in. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 0/8] drm: Add generic fbdev emulation
Den 03.07.2018 18.03, skrev Noralf Trønnes: This patchset adds generic fbdev emulation for drivers that supports GEM based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An API is begun to support in-kernel clients in general. I've squashed the client patches to ease review. All patches have ack's and rb's so I'll apply this next week unless something more comes up. It's taken me 6 months to get this done so I look forward to getting it applied. Thanks a lot Daniel for helping me make this happen! Noralf. Changes since version 4: - Squash the two client patches to ease review. - Remove drm_client_put() doc references. - Remove drm_client_funcs->release, it's use went away in version 3. - Add drm_client_dev_hotplug() doc Changes since version 3: - drm/cma-helper: Use the generic fbdev emulation: Fix error path - Remove setting .lastclose in new tinydrm driver ili9341 Changes since version 2: - Applied first 3 patches to drm-misc-next - Drop client reference counting and only allow the driver to release clients. Noralf Trønnes (8): drm: Begin an API for in-kernel clients drm/fb-helper: Add generic fbdev emulation .fb_probe function drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap drm/cma-helper: Use the generic fbdev emulation drm/debugfs: Add internal client debugfs file drm/fb-helper: Finish the generic fbdev emulation drm/tinydrm: Use drm_fbdev_generic_setup() drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs() Series applied to drm-misc, thanks for reviewing. Noralf. Documentation/gpu/drm-client.rst| 12 + Documentation/gpu/index.rst | 1 + drivers/gpu/drm/Makefile| 2 +- drivers/gpu/drm/drm_client.c| 415 drivers/gpu/drm/drm_debugfs.c | 7 + drivers/gpu/drm/drm_drv.c | 8 + drivers/gpu/drm/drm_fb_cma_helper.c | 379 +++-- drivers/gpu/drm/drm_fb_helper.c | 316 - drivers/gpu/drm/drm_file.c | 3 + drivers/gpu/drm/drm_probe_helper.c | 3 + drivers/gpu/drm/pl111/pl111_drv.c | 2 + drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 3 +- drivers/gpu/drm/tinydrm/ili9225.c | 1 - drivers/gpu/drm/tinydrm/ili9341.c | 1 - drivers/gpu/drm/tinydrm/mi0283qt.c | 1 - drivers/gpu/drm/tinydrm/st7586.c| 1 - drivers/gpu/drm/tinydrm/st7735r.c | 1 - include/drm/drm_client.h| 139 ++ include/drm/drm_device.h| 21 ++ include/drm/drm_fb_cma_helper.h | 6 - include/drm/drm_fb_helper.h | 38 +++ 21 files changed, 1007 insertions(+), 353 deletions(-) create mode 100644 Documentation/gpu/drm-client.rst create mode 100644 drivers/gpu/drm/drm_client.c create mode 100644 include/drm/drm_client.h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib: Require working GEM (!wedged) to allow hang injection
Chris Wilson writes: > As we ordinarily use a spinning batch to trigger a hang, we cannot do so > without execbuf. On the other hand, if we do a manual reset of the > wedged driver, we expect it to remain wedged and for the reset to fail; by 'manual' you are referring to '-1' on i915_wedged debugfs entry? -Mika > failing the test. Even if we remove the igt_assert(!wedged), the test is > suspect as we don't know if the reset took place and so do not know if > the conditions the test is trying to setup apply. > > Signed-off-by: Chris Wilson > --- > lib/igt_gt.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/lib/igt_gt.c b/lib/igt_gt.c > index 4569fd36b..89b318ae6 100644 > --- a/lib/igt_gt.c > +++ b/lib/igt_gt.c > @@ -162,6 +162,13 @@ igt_hang_t igt_allow_hang(int fd, unsigned ctx, unsigned > flags) > }; > unsigned ban; > > + /* > + * If the driver is already wedged, we don't expect it to be able > + * to recover from reset and for it to remain wedged. It's hard to > + * say even if we do hang/reset making the test suspect. > + */ > + igt_require_gem(fd); > + > igt_assert(igt_sysfs_set_parameter > (fd, "reset", "%d", INT_MAX /* any reset method */)); > > -- > 2.18.0 > > ___ > 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 08/10] drm/crc: Cleanup crtc_crc_open function
Hi,
Thanks for the review.
On 7/10/2018 5:19 PM, Laurent Pinchart wrote:
Hi Mahesh,
Thank you for the patch.
On Monday, 2 July 2018 14:07:27 EEST Mahesh Kumar wrote:
This patch make changes to allocate crc-entries buffer before
enabling CRC generation.
It moves all the failure check early in the function before setting
the source or memory allocation.
Now set_crc_source takes only two variable inputs, values_cnt we
already gets as part of verify_crc_source.
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 3 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 4 +-
drivers/gpu/drm/drm_debugfs_crc.c | 52 ---
drivers/gpu/drm/i915/intel_drv.h | 3 +-
drivers/gpu/drm/i915/intel_pipe_crc.c | 4 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 5 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 6 +--
include/drm/drm_crtc.h | 3 +-
8 files changed, 30 insertions(+), 50 deletions(-)
[snip]
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c index f4d76528d24c..739a813b4b09 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -124,11 +124,9 @@ static ssize_t crc_control_write(struct file *file,
const char __user *ubuf, if (source[len] == '\n')
source[len] = '\0';
- if (crtc->funcs->verify_crc_source) {
- ret = crtc->funcs->verify_crc_source(crtc, source, _cnt);
- if (ret)
- return ret;
- }
+ ret = crtc->funcs->verify_crc_source(crtc, source, _cnt);
+ if (ret)
+ return ret;
spin_lock_irq(>lock);
@@ -193,12 +191,15 @@ static int crtc_crc_open(struct inode *inode, struct
file *filep) return ret;
}
- if (crtc->funcs->verify_crc_source) {
- ret = crtc->funcs->verify_crc_source(crtc, crc->source,
-_cnt);
- if (ret)
- return ret;
- }
+ ret = crtc->funcs->verify_crc_source(crtc, crc->source, _cnt);
+ if (ret)
+ return ret;
+
+ if (WARN_ON(values_cnt > DRM_MAX_CRC_NR))
+ return -EINVAL;
+
+ if (WARN_ON(values_cnt == 0))
+ return -EINVAL;
spin_lock_irq(>lock);
if (!crc->opened)
@@ -210,30 +211,22 @@ static int crtc_crc_open(struct inode *inode, struct
file *filep) if (ret)
return ret;
- ret = crtc->funcs->set_crc_source(crtc, crc->source, _cnt);
- if (ret)
- goto err;
-
- if (WARN_ON(values_cnt > DRM_MAX_CRC_NR)) {
- ret = -EINVAL;
- goto err_disable;
- }
-
- if (WARN_ON(values_cnt == 0)) {
- ret = -EINVAL;
- goto err_disable;
- }
-
entries = kcalloc(DRM_CRC_ENTRIES_NR, sizeof(*entries), GFP_KERNEL);
if (!entries) {
ret = -ENOMEM;
- goto err_disable;
+ goto err;
}
If you moved allocation before the !crc->opened check, you could group the two
code blocks protected by the crc->lock.
agree, will update in next version.
-Mahesh
spin_lock_irq(>lock);
crc->entries = entries;
crc->values_cnt = values_cnt;
+ spin_unlock_irq(>lock);
+ ret = crtc->funcs->set_crc_source(crtc, crc->source);
+ if (ret)
+ goto err;
+
+ spin_lock_irq(>lock);
/*
* Only return once we got a first frame, so userspace doesn't have to
* guess when this particular piece of HW will be ready to start
@@ -250,7 +243,7 @@ static int crtc_crc_open(struct inode *inode, struct
file *filep) return 0;
err_disable:
- crtc->funcs->set_crc_source(crtc, NULL, _cnt);
+ crtc->funcs->set_crc_source(crtc, NULL);
err:
spin_lock_irq(>lock);
crtc_crc_cleanup(crc);
@@ -262,9 +255,8 @@ static int crtc_crc_release(struct inode *inode, struct
file *filep) {
struct drm_crtc *crtc = filep->f_inode->i_private;
struct drm_crtc_crc *crc = >crc;
- size_t values_cnt;
- crtc->funcs->set_crc_source(crtc, NULL, _cnt);
+ crtc->funcs->set_crc_source(crtc, NULL);
spin_lock_irq(>lock);
crtc_crc_cleanup(crc);
@@ -370,7 +362,7 @@ int drm_debugfs_crtc_crc_add(struct drm_crtc *crtc)
{
struct dentry *crc_ent, *ent;
- if (!crtc->funcs->set_crc_source)
+ if (!crtc->funcs->set_crc_source || !crtc->funcs->verify_crc_source)
return 0;
crc_ent = debugfs_create_dir("crc", crtc->debugfs_entry);
[snip]
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib: Require working GEM (!wedged) to allow hang injection
Quoting Mika Kuoppala (2018-07-10 14:13:39) > Chris Wilson writes: > > > As we ordinarily use a spinning batch to trigger a hang, we cannot do so > > without execbuf. On the other hand, if we do a manual reset of the > > wedged driver, we expect it to remain wedged and for the reset to fail; > > by 'manual' you are referring to '-1' on i915_wedged debugfs entry? Yes, igt_force_gpu_reset() as opposed to igt_hang_ring(). -Chris ___ 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: Constrain mock_gtt tests to fit within RAM
== Series Details == Series: drm/i915/selftests: Constrain mock_gtt tests to fit within RAM URL : https://patchwork.freedesktop.org/series/46247/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4460_full -> Patchwork_9601_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9601_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9601_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_9601_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-vebox: shard-kbl: SKIP -> PASS +1 igt@pm_rc6_residency@rc6-accuracy: shard-kbl: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_9601_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: shard-kbl: PASS -> DMESG-FAIL (fdo#107174, fdo#106560, fdo#106947) igt@kms_flip@plain-flip-fb-recreate: shard-glk: PASS -> FAIL (fdo#100368) Possible fixes igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#102887) -> PASS igt@kms_flip_tiling@flip-x-tiled: shard-glk: FAIL (fdo#107161) -> PASS +1 igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS igt@perf@blocking: shard-hsw: FAIL (fdo#102252) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 fdo#107161 https://bugs.freedesktop.org/show_bug.cgi?id=107161 fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4460 -> Patchwork_9601 CI_DRM_4460: 23203a4c2a0e96b19cfb35bed4ad7dcf1ff854fc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4544: 764160f214cd916ddb79408b9f28ac0ad2df40e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9601: 3d30c324a9ba8b7065775a949bd92c29034b2b2c @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9601/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib: Require working GEM (!wedged) to allow hang injection
Chris Wilson writes: > As we ordinarily use a spinning batch to trigger a hang, we cannot do so > without execbuf. On the other hand, if we do a manual reset of the > wedged driver, we expect it to remain wedged and for the reset to fail; > failing the test. Even if we remove the igt_assert(!wedged), the test is > suspect as we don't know if the reset took place and so do not know if > the conditions the test is trying to setup apply. > > Signed-off-by: Chris Wilson > --- > lib/igt_gt.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/lib/igt_gt.c b/lib/igt_gt.c > index 4569fd36b..89b318ae6 100644 > --- a/lib/igt_gt.c > +++ b/lib/igt_gt.c > @@ -162,6 +162,13 @@ igt_hang_t igt_allow_hang(int fd, unsigned ctx, unsigned > flags) > }; > unsigned ban; > > + /* > + * If the driver is already wedged, we don't expect it to be able > + * to recover from reset and for it to remain wedged. It's hard to > + * say even if we do hang/reset making the test suspect. > + */ > + igt_require_gem(fd); This will do a manual reset for a wedged driver, trying to rectify the situation. But we are on a more solid ground after it. Reviewed-by: Mika Kuoppala > + > igt_assert(igt_sysfs_set_parameter > (fd, "reset", "%d", INT_MAX /* any reset method */)); > > -- > 2.18.0 > > ___ > 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 i-g-t] lib: Require working GEM (!wedged) to allow hang injection
Quoting Mika Kuoppala (2018-07-10 14:30:15) > Chris Wilson writes: > > > As we ordinarily use a spinning batch to trigger a hang, we cannot do so > > without execbuf. On the other hand, if we do a manual reset of the > > wedged driver, we expect it to remain wedged and for the reset to fail; > > failing the test. Even if we remove the igt_assert(!wedged), the test is > > suspect as we don't know if the reset took place and so do not know if > > the conditions the test is trying to setup apply. > > > > Signed-off-by: Chris Wilson > > --- > > lib/igt_gt.c | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/lib/igt_gt.c b/lib/igt_gt.c > > index 4569fd36b..89b318ae6 100644 > > --- a/lib/igt_gt.c > > +++ b/lib/igt_gt.c > > @@ -162,6 +162,13 @@ igt_hang_t igt_allow_hang(int fd, unsigned ctx, > > unsigned flags) > > }; > > unsigned ban; > > > > + /* > > + * If the driver is already wedged, we don't expect it to be able > > + * to recover from reset and for it to remain wedged. It's hard to > > + * say even if we do hang/reset making the test suspect. > > + */ > > + igt_require_gem(fd); > > This will do a manual reset for a wedged driver, trying to rectify the > situation. But we are on a more solid ground after it. Hmm, true. Need to wait to make sure it doesn't interfere with gem_eio and its ilk. I think it remains sensible to verify that we have a working GEM driver before testing, but there will be a time when we need something not quite so heavy handed. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/intel_dsi: Read back pclk set by GOP and use that as pclk
Hi,
On 07/09/2018 08:14 PM, Ville Syrjälä wrote:
On Sat, Jul 07, 2018 at 08:32:16AM +0200, Hans de Goede wrote:
Any kind of hack that involves reading out the hardware state should go
into something like intel_sanitize_encoder(). Actually by that time we
have already read out the hw state, so it shouldn't require any
modifications to the existing dsi code itself.
I do not think that intel_sanitize encoder is the right place to do this:
* I don't want to modify the read-back state, I want to modify our
calculated "new/ideal" state to match the read-back state
I wasn't suggesting that. What I meant is that you already have the
state there to look so you don't have to hack the readout functions
to function without a state being around.
That said, we do already have intel_encoder_current_mode() which is doing
something similar to what you're proposing. So probably should just
try to reuse that.
Ah yes that should work and will allow me to drop 2 of the 3 preparation
patches (I still need the patch which initializes the encoder enough that
it can be passed to get_hw_state() from intel_dsi_init_vbt().
So something like this ? :
From 82db375919be9b95e680dc5b1f660d5ef1efcc94 Mon Sep 17 00:00:00 2001
From: Hans de Goede
Date: Tue, 10 Jul 2018 08:59:27 +0200
Subject: [PATCH] drm/i915/intel_dsi: Read back pclk set by GOP and use that as
pclk
On BYT and CHT the GOP sometimes initializes the pclk at a (slightly)
different frequency then the pclk which we've calculated.
This commit makes the DSI code read-back the pclk set by the GOP and
if that is within a reasonable margin of the calculated pclk, uses
that instead.
This fixes the first modeset being a full modeset instead of a
fast modeset on systems where the GOP pclk is different.
Changes in v2:
-Use intel_encoder_current_mode() to get the pclk setup by the GOP
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 4d6ffa7b3e7b..828d5ac0dfef 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -506,6 +506,7 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
struct mipi_config *mipi_config = dev_priv->vbt.dsi.config;
struct mipi_pps_data *pps = dev_priv->vbt.dsi.pps;
struct drm_display_mode *mode = dev_priv->vbt.lfp_lvds_vbt_mode;
+ struct drm_display_mode *curr;
u32 bpp;
u32 tlpx_ns, extra_byte_count, bitrate, tlpx_ui;
u32 ui_num, ui_den;
@@ -583,6 +584,23 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
} else
burst_mode_ratio = 100;
+ /*
+* On BYT / CRC the GOP sometimes picks a slightly different pclk,
+* read back the GOP configured pclk and prefer it over ours.
+*/
+ if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+ curr = intel_encoder_current_mode(_dsi->base);
+ if (curr) {
+ DRM_DEBUG_KMS("Calculated pclk %d GOP %d\n",
+ pclk, curr->clock);
+ if (curr->clock >= (pclk * 9 / 10) &&
+ curr->clock <= (pclk * 11 / 10))
+ pclk = curr->clock;
+
+ kfree(curr);
+ }
+ }
+
intel_dsi->burst_mode_ratio = burst_mode_ratio;
intel_dsi->pclk = pclk;
Note this is untested as I'm travelling at the moment. I will test
this when I'm back home and send out a v2.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Constrain mock_gtt tests to fit within RAM
Be pessimistic and presume that we actually allocate every page we
exercise via the mock_gtt (e.g. for gvt). In which case we have to keep
our working case under the available physical memory to prevent oom.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 600a3bcbd3d6..8e2e269db97e 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1244,6 +1244,7 @@ static int exercise_mock(struct drm_i915_private *i915,
u64 hole_start, u64 hole_end,
unsigned long end_time))
{
+ const u64 limit = totalram_pages << PAGE_SHIFT;
struct i915_gem_context *ctx;
struct i915_hw_ppgtt *ppgtt;
IGT_TIMEOUT(end_time);
@@ -1256,7 +1257,7 @@ static int exercise_mock(struct drm_i915_private *i915,
ppgtt = ctx->ppgtt;
GEM_BUG_ON(!ppgtt);
- err = func(i915, >vm, 0, ppgtt->vm.total, end_time);
+ err = func(i915, >vm, 0, min(ppgtt->vm.total, limit), end_time);
mock_context_close(ctx);
return err;
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Constrain mock_gtt tests to fit within RAM
On 10 July 2018 at 09:04, Chris Wilson wrote: > Be pessimistic and presume that we actually allocate every page we > exercise via the mock_gtt (e.g. for gvt). In which case we have to keep > our working case under the available physical memory to prevent oom. > > Signed-off-by: Chris Wilson > Cc: Matthew Auld Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] kernel.h: Add for_each_if()
On Mon, Jul 09, 2018 at 04:30:01PM -0700, Andrew Morton wrote:
> On Mon, 9 Jul 2018 18:25:09 +0200 Daniel Vetter
> wrote:
>
> > To avoid compilers complainig about ambigious else blocks when putting
> > an if condition into a for_each macro one needs to invert the
> > condition and add a dummy else. We have a nice little convenience
> > macro for that in drm headers, let's move it out. Subsequent patches
> > will roll it out to other places.
> >
> > The issue the compilers complain about are nested if with an else
> > block and no {} to disambiguate which if the else belongs to. The C
> > standard is clear, but in practice people forget:
> >
> > if (foo)
> > if (bar)
> > /* something */
> > else
> > /* something else
>
> um, yeah, don't do that. Kernel coding style is very much to do
>
> if (foo) {
> if (bar)
> /* something */
> else
> /* something else
> }
>
> And if not doing that generates a warning then, well, do that.
>
> > The same can happen in a for_each macro when it also contains an if
> > condition at the end, except the compiler message is now really
> > confusing since there's only 1 if:
> >
> > for_each_something()
> > if (bar)
> > /* something */
> > else
> > /* something else
> >
> > The for_each_if() macro, by inverting the condition and adding an
> > else, avoids the compiler warning.
>
> Ditto.
>
> > Motivated by a discussion with Andy and Yisheng, who want to add
> > another for_each_macro which would benefit from for_each_if() instead
> > of hand-rolling it.
>
> Ditto.
>
> > v2: Explain a bit better what this is good for, after the discussion
> > with Peter Z.
>
> Presumably the above was discussed in whatever-thread-that-was.
So there's a bunch of open coded versions of this already in kernel
headers (at least the ones I've found). Not counting the big pile of
existing users in drm. They are all wrong and should be reverted to a
plain if? That why there's a bunch more patches in this series.
And yes I made it clear in the discussion that if you sprinkle enough {}
there's no warning, should have probably captured this here.
Aka a formal Nack-pls-keep-your-stuff-in-drm: would be appreciated so I
can stop bothering with this.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/selftests: Constrain mock_gtt tests to fit within RAM
== Series Details == Series: drm/i915/selftests: Constrain mock_gtt tests to fit within RAM URL : https://patchwork.freedesktop.org/series/46247/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/selftests: Constrain mock_gtt tests to fit within RAM +drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:1260:41: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:1260:41: warning: expression using sizeof(void) ___ 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/selftests: Constrain mock_gtt tests to fit within RAM
== Series Details ==
Series: drm/i915/selftests: Constrain mock_gtt tests to fit within RAM
URL : https://patchwork.freedesktop.org/series/46247/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4460 -> Patchwork_9601 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/46247/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9601 that come from known issues:
=== IGT changes ===
Issues hit
igt@gem_exec_suspend@basic-s4-devices:
{fi-kbl-8809g}: NOTRUN -> INCOMPLETE (fdo#107139)
igt@prime_vgem@basic-fence-flip:
fi-ilk-650: PASS -> FAIL (fdo#104008)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139
== Participating hosts (45 -> 42) ==
Additional (2): fi-skl-guc fi-kbl-8809g
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4460 -> Patchwork_9601
CI_DRM_4460: 23203a4c2a0e96b19cfb35bed4ad7dcf1ff854fc @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4544: 764160f214cd916ddb79408b9f28ac0ad2df40e0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9601: 3d30c324a9ba8b7065775a949bd92c29034b2b2c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3d30c324a9ba drm/i915/selftests: Constrain mock_gtt tests to fit within RAM
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9601/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Filter out both physical address swizzles
On 9 July 2018 at 20:49, Chris Wilson wrote: > In our swizzling selftests, we cannot predict the physical address of > the target page (at least not simply!) and so skip bit17 swizzles. > However, there are two bit17 swizzle modes and we only skipped on, with we only skipped one > the second being observed on the lab gdg causing the test to fail, > as soon as we hit a page with bit17 set it its address. "set it its address"? > > Testcase: igt/drv_selftest/live_objects #gdg > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Filter out both physical address swizzles
Quoting Matthew Auld (2018-07-10 09:46:13) > On 9 July 2018 at 20:49, Chris Wilson wrote: > > In our swizzling selftests, we cannot predict the physical address of > > the target page (at least not simply!) and so skip bit17 swizzles. > > However, there are two bit17 swizzle modes and we only skipped on, with > > we only skipped one > > > the second being observed on the lab gdg causing the test to fail, > > as soon as we hit a page with bit17 set it its address. > > "set it its address"? set in its address > > > > > Testcase: igt/drv_selftest/live_objects #gdg > > Signed-off-by: Chris Wilson > Reviewed-by: Matthew Auld Thanks for the proofreading /o\ -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Constrain mock_gtt tests to fit within RAM
Quoting Matthew Auld (2018-07-10 09:27:10) > On 10 July 2018 at 09:04, Chris Wilson wrote: > > Be pessimistic and presume that we actually allocate every page we > > exercise via the mock_gtt (e.g. for gvt). In which case we have to keep > > our working case under the available physical memory to prevent oom. > > > > Signed-off-by: Chris Wilson > > Cc: Matthew Auld > Reviewed-by: Matthew Auld Ta, fingers crossed this stops the gvt flip-flops on mock_gtt. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Kill resource streamer
== Series Details == Series: Kill resource streamer URL : https://patchwork.freedesktop.org/series/46224/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4458_full -> Patchwork_9599_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9599_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9599_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_9599_full: === IGT changes === Possible regressions igt@gem_exec_params@rs-invalid-gen: shard-snb: PASS -> FAIL igt@gem_exec_params@rs-invalid-on-vebox-ring: shard-hsw: PASS -> FAIL +2 igt@perf_pmu@event-wait-rcs0: shard-glk: PASS -> FAIL +11 igt@perf_pmu@semaphore-wait-idle-bcs0: shard-kbl: PASS -> FAIL +13 igt@perf_pmu@semaphore-wait-vcs0: shard-apl: PASS -> FAIL +11 Warnings igt@gem_exec_schedule@deep-vebox: shard-kbl: SKIP -> PASS +2 igt@gem_mocs_settings@mocs-rc6-bsd1: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9599_full that come from known issues: === IGT changes === Issues hit igt@drv_suspend@shrink: shard-glk: PASS -> INCOMPLETE (fdo#103359, k.org#198133) igt@kms_vblank@pipe-c-ts-continuation-suspend: shard-hsw: PASS -> FAIL (fdo#104894) igt@perf@blocking: shard-hsw: PASS -> FAIL (fdo#102252) Possible fixes igt@gem_exec_big: shard-hsw: INCOMPLETE (fdo#103540) -> PASS igt@kms_flip@2x-dpms-vs-vblank-race-interruptible: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip_tiling@flip-y-tiled: shard-glk: FAIL (fdo#107161) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#104894 https://bugs.freedesktop.org/show_bug.cgi?id=104894 fdo#107161 https://bugs.freedesktop.org/show_bug.cgi?id=107161 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4458 -> Patchwork_9599 CI_DRM_4458: dbed4c29cc0cd0225aae60c57ac2f4a738bb5a17 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4544: 764160f214cd916ddb79408b9f28ac0ad2df40e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9599: 526eac8de54b23e00a6293cb7ff185a2b1530156 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9599/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Flush the residual parking on emergency shutdown
On unwinding following a critical failure inside GEM init, we also need
to be sure to flush the workers before unloading the module.
Testcase: igt/drv_module_reload/basic-reload-inject
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/intel_display.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b35cbfd16c9c..737580907c0c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5548,6 +5548,8 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
WARN_ON(i915_gem_suspend(dev_priv));
i915_gem_suspend_late(dev_priv);
+ i915_gem_drain_workqueue(dev_priv);
+
mutex_lock(_priv->drm.struct_mutex);
intel_uc_fini_hw(dev_priv);
err_uc_init:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8f3199b06d1f..7998e70a3174 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15890,6 +15890,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
+ flush_workqueue(dev_priv->modeset_wq);
+
flush_work(_priv->atomic_helper.free_work);
WARN_ON(!llist_empty(_priv->atomic_helper.free_list));
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Cleanup modesetting on load-error path
After handling a critical failure initialising GEM we need to unwind the
modesetting setup.
Testcase: igt/drv_module_reload/basic-reload-inject
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 39b097a91512..e3dfa74d45ad 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -682,7 +682,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
ret = i915_gem_init(dev_priv);
if (ret)
- goto cleanup_irq;
+ goto cleanup_modeset;
intel_setup_overlay(dev_priv);
@@ -702,6 +702,8 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (i915_gem_suspend(dev_priv))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
i915_gem_fini(dev_priv);
+cleanup_modeset:
+ intel_modeset_cleanup(dev);
cleanup_irq:
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev_priv);
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 09/13] drm/i915/icl: Program TA_TIMING_PARAM registers
This patch programs D-PHY timing parameters for the
bus turn around flow(in escape clocks) only if dsi link
frequency <=800 MHz using DPHY_TA_TIMING_PARAM and its
identical register DSI_TA_TIMING_PARAM (inside DSI
Controller within the Display Core).
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/icl_dsi.c | 21 +
drivers/gpu/drm/i915/intel_dsi.h | 1 +
drivers/gpu/drm/i915/intel_dsi_vbt.c | 1 +
3 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index 832772d..8fd5284 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -302,6 +302,27 @@ static void gen11_dsi_setup_dphy_timings(struct
intel_encoder *encoder)
I915_WRITE(DSI_DATA_TIMING_PARAM(port),
intel_dsi->dphy_data_lane_reg);
}
+
+ /*
+* If DSI link operating at or below an 800 MHz,
+* TA_SURE should be override and programmed to
+* a value '0' inside TA_PARAM_REGISTERS otherwise
+* leave all fields at HW default values.
+*/
+ if (intel_dsi->bitrate_khz <= KHz(800)) {
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(DPHY_TA_TIMING_PARAM(port));
+ tmp &= ~TA_SURE_TIME_MASK;
+ tmp |= (TA_SURE_OVERRIDE | TA_SURE_TIME(0));
+ I915_WRITE(DPHY_TA_TIMING_PARAM(port), tmp);
+
+ /* shadow register inside display core */
+ tmp = I915_READ(DSI_TA_TIMING_PARAM(port));
+ tmp &= ~TA_SURE_TIME_MASK;
+ tmp |= (TA_SURE_OVERRIDE | TA_SURE_TIME(0));
+ I915_WRITE(DSI_TA_TIMING_PARAM(port), tmp);
+ }
+ }
}
static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 9fd8526..25e7396 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -101,6 +101,7 @@ struct intel_dsi {
u16 init_count;
u32 pclk;
+ u32 bitrate_khz;
u16 burst_mode_ratio;
/* all delays in ms */
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 428290d..a9a98a4 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -589,6 +589,7 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
intel_dsi->pclk = pclk;
bitrate = (pclk * bpp) / intel_dsi->lane_count;
+ intel_dsi->bitrate_khz = bitrate;
switch (intel_dsi->escape_clk_div) {
case 0:
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 08/13] drm/i915/icl: Define TA_TIMING_PARAM registers
This patch defines DSI_TA_TIMING_PARAM and
DPHY_TA_TIMING_PARAM registers used in
dphy programming.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0dbdd57..1d13ba9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10115,6 +10115,20 @@ enum skl_power_gate {
#define HS_EXIT_OVERRIDE (1 << 7)
#define HS_EXIT_TIME(x) (x << 0)
+#define _DPHY_TA_TIMING_PARAM_00x162188
+#define _DPHY_TA_TIMING_PARAM_10x6c188
+#define DPHY_TA_TIMING_PARAM(port) _MMIO_PORT(port,\
+ _DPHY_TA_TIMING_PARAM_0,\
+ _DPHY_TA_TIMING_PARAM_1)
+#define _DSI_TA_TIMING_PARAM_0 0x6b098
+#define _DSI_TA_TIMING_PARAM_1 0x6b898
+#define DSI_TA_TIMING_PARAM(port) _MMIO_PORT(port,\
+ _DSI_TA_TIMING_PARAM_0,\
+ _DSI_TA_TIMING_PARAM_1)
+#define TA_SURE_OVERRIDE (1 << 31)
+#define TA_SURE_TIME(x) (x << 16)
+#define TA_SURE_TIME_MASK (0x1f << 16)
+
/* bits 31:0 */
#define _MIPIA_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb084)
#define _MIPIC_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb884)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 10/13] drm/i915/icl: Get DSI transcoder for a given port
This patch adds a helper function to retrieve DSI
transcoder for a given DSI port using newly defined
enum names for DSI transcoders.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/icl_dsi.c | 9 +
drivers/gpu/drm/i915/intel_display.h | 6 --
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index 8fd5284..243f434 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -27,6 +27,15 @@
#include "intel_dsi.h"
+static enum transcoder __attribute__((unused)) dsi_port_to_transcoder(
+ enum port port)
+{
+ if (port == PORT_A)
+ return TRANSCODER_DSI_0;
+ else
+ return TRANSCODER_DSI_1;
+}
+
static void dsi_program_swing_and_deemphasis(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index ca5a10f..de1bc9d 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -43,8 +43,10 @@ enum transcoder {
TRANSCODER_B,
TRANSCODER_C,
TRANSCODER_EDP,
- TRANSCODER_DSI_A,
- TRANSCODER_DSI_C,
+ TRANSCODER_DSI_0,
+ TRANSCODER_DSI_1,
+ TRANSCODER_DSI_A = TRANSCODER_DSI_0,/* legacy DSI */
+ TRANSCODER_DSI_C = TRANSCODER_DSI_1,/* legacy DSI */
I915_MAX_TRANSCODERS
};
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 12/13] drm/i915/icl: Define TRANS_DSI_FUNC_CONF register
This patch defines transcoder function configuration
registers and its bitfields for both DSI ports.
Used while programming/enabling DSI transcoder.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 47 +
1 file changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 62bc76e..71ce6ba 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10134,6 +10134,53 @@ enum skl_power_gate {
#define TA_SURE_TIME(x) (x << 16)
#define TA_SURE_TIME_MASK (0x1f << 16)
+/* DSI transcoder configuration */
+#define _DSI_TRANS_FUNC_CONF_0 0x6b030
+#define _DSI_TRANS_FUNC_CONF_1 0x6b830
+#define DSI_TRANS_FUNC_CONF(tc)_MMIO_DSI(tc, \
+ _DSI_TRANS_FUNC_CONF_0,\
+ _DSI_TRANS_FUNC_CONF_1)
+#define OP_MODE(x)(x << 28)
+#define OP_MODE_MASK (0x3 << 28)
+#define CMD_MODE_NO_GATE 0x0
+#define CMD_MODE_TE_GATE 0x1
+#define VIDEO_MODE_SYNC_EVENT 0x2
+#define VIDEO_MODE_SYNC_PULSE 0x3
+#define LINK_READY(1 << 20)
+#define PIX_FMT(x)(x << 16)
+#define PIX_FMT_MASK (0x3 << 16)
+#define PIX_FMT_RGB5650x0
+#define PIX_FMT_RGB666_PACKED 0x1
+#define PIX_FMT_RGB666_LOOSE 0x2
+#define PIX_FMT_RGB8880x3
+#define PIX_FMT_RGB101010 0x4
+#define PIX_FMT_RGB121212 0x5
+#define PIX_FMT_COMPRESSED0x6
+#define BGR_TRANSMISSION (1 << 15)
+#define PIX_VIRT_CHAN(x) (x << 12)
+#define PIX_VIRT_CHAN_MASK(0x3 << 12)
+#define PIX_BUF_THRESHOLD(x) ((x & 0x3) << 10)
+#define PIX_BUF_THRESHOLD_MASK(0x3 << 10)
+#define PIX_BUF_THRESHOLD_1_4 0x0
+#define PIX_BUF_THRESHOLD_1_2 0x1
+#define PIX_BUF_THRESHOLD_3_4 0x2
+#define PIX_BUF_THRESHOLD_FULL0x3
+#define CONTINUOUS_CLK(x) (x << 8)
+#define CONTINUOUS_CLK_MASK (0x3 << 8)
+#define CLK_ENTER_LP_AFTER_DATA 0x0
+#define CLK_HS_OR_LP 0x2
+#define CLK_HS_CONTINUOUS 0x3
+#define LINK_CALIBRATION(x) (x << 4)
+#define LINK_CALIBRATION_MASK (0x3 << 4)
+#define CALIBRATION_DISABLED 0x0
+#define CALIBRATION_ENABLED_INITIAL_ONLY 0x2
+#define CALIBRATION_ENABLED_INITIAL_PERIODIC 0x3
+#define S3D_ORIENTATION(x)(x << 1)
+#define S3D_ORIENTATION_MASK (0x1 << 1)
+#define S3D_ORIENTATION_PORTRAIT 0x0
+#define S3D_ORIENTATION_LANDSCAPE 0x1
+#define EOTP_DISABLED (1 << 0)
+
/* bits 31:0 */
#define _MIPIA_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb084)
#define _MIPIC_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb884)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 06/13] drm/i915/icl: Define data/clock lanes dphy timing registers
This patch defines DSI_CLK_TIMING_PARAM, DPHY_CLK_TIMING_PARAM,
DSI_DATA_TIMING_PARAM, DPHY_DATA_TIMING_PARAM register used in
dphy programming.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 40
1 file changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6129372..0dbdd57 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10075,6 +10075,46 @@ enum skl_power_gate {
_ICL_DSI_T_INIT_MASTER_0,\
_ICL_DSI_T_INIT_MASTER_1)
+#define _DPHY_CLK_TIMING_PARAM_0 0x162180
+#define _DPHY_CLK_TIMING_PARAM_1 0x6c180
+#define DPHY_CLK_TIMING_PARAM(port)_MMIO_PORT(port,\
+ _DPHY_CLK_TIMING_PARAM_0,\
+ _DPHY_CLK_TIMING_PARAM_1)
+#define _DSI_CLK_TIMING_PARAM_00x6b080
+#define _DSI_CLK_TIMING_PARAM_10x6b880
+#define DSI_CLK_TIMING_PARAM(port) _MMIO_PORT(port,\
+ _DSI_CLK_TIMING_PARAM_0,\
+ _DSI_CLK_TIMING_PARAM_1)
+#define CLK_PREP_OVERRIDE (1 << 31)
+#define CLK_PREP_TIME(x) (x << 28)
+#define CLK_ZERO_OVERRIDE (1 << 27)
+#define CLK_ZERO_TIME(x) (x << 20)
+#define CLK_PRE_OVERRIDE (1 << 19)
+#define CLK_PRE_TIME(x) (x << 16)
+#define CLK_POST_OVERRIDE (1 << 15)
+#define CLK_POST_TIME(x) (x << 8)
+#define CLK_TRAIL_OVERRIDE(1 << 7)
+#define CLK_TRAIL_TIME(x) (x << 0)
+
+#define _DPHY_DATA_TIMING_PARAM_0 0x162184
+#define _DPHY_DATA_TIMING_PARAM_1 0x6c184
+#define DPHY_DATA_TIMING_PARAM(port) _MMIO_PORT(port,\
+ _DPHY_DATA_TIMING_PARAM_0,\
+ _DPHY_DATA_TIMING_PARAM_1)
+#define _DSI_DATA_TIMING_PARAM_0 0x6B084
+#define _DSI_DATA_TIMING_PARAM_1 0x6B884
+#define DSI_DATA_TIMING_PARAM(port)_MMIO_PORT(port,\
+ _DSI_DATA_TIMING_PARAM_0,\
+ _DSI_DATA_TIMING_PARAM_1)
+#define HS_PREP_OVERRIDE (1 << 31)
+#define HS_PREP_TIME(x) (x << 24)
+#define HS_ZERO_OVERRIDE (1 << 23)
+#define HS_ZERO_TIME(x) (x << 16)
+#define HS_TRAIL_OVERRIDE (1 << 15)
+#define HS_TRAIL_TIME(x) (x << 8)
+#define HS_EXIT_OVERRIDE (1 << 7)
+#define HS_EXIT_TIME(x) (x << 0)
+
/* bits 31:0 */
#define _MIPIA_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb084)
#define _MIPIC_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb884)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 01/13] drm/i915/icl: Configure lane sequencing of combo phy transmitter
This patch set the loadgen select and latency optimization for
aux and transmit lanes of combo phy transmitters. It will be
used for MIPI DSI HS operations.
v2: Rebase
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/icl_dsi.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index 13830e4..a571339 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -105,10 +105,48 @@ static void gen11_dsi_power_up_lanes(struct intel_encoder
*encoder)
}
}
+static void gen11_dsi_config_phy_lanes_sequence(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
+ enum port port;
+ u32 tmp;
+ int lane;
+
+ /* Step 4b(i) set loadgen select for transmit and aux lanes */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(ICL_PORT_TX_DW4_AUX(port));
+ tmp &= ~LOADGEN_SELECT;
+ I915_WRITE(ICL_PORT_TX_DW4_AUX(port), tmp);
+ for (lane = 0; lane <= 3; lane++) {
+ tmp = I915_READ(ICL_PORT_TX_DW4_LN(port, lane));
+ tmp &= ~LOADGEN_SELECT;
+ if (lane != 2)
+ tmp |= LOADGEN_SELECT;
+ I915_WRITE(ICL_PORT_TX_DW4_LN(port, lane), tmp);
+ }
+ }
+
+ /* Step 4b(ii) set latency optimization for transmit and aux lanes */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(ICL_PORT_TX_DW2_AUX(port));
+ tmp &= ~FRC_LATENCY_OPTIM_MASK;
+ tmp |= FRC_LATENCY_OPTIM_VAL(0x5);
+ I915_WRITE(ICL_PORT_TX_DW2_AUX(port), tmp);
+ tmp = I915_READ(ICL_PORT_TX_DW2_LN0(port));
+ tmp &= ~FRC_LATENCY_OPTIM_MASK;
+ tmp |= FRC_LATENCY_OPTIM_VAL(0x5);
+ I915_WRITE(ICL_PORT_TX_DW2_GRP(port), tmp);
+ }
+}
+
static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
{
/* step 4a: power up all lanes of the DDI used by DSI */
gen11_dsi_power_up_lanes(encoder);
+
+ /* step 4b: configure lane sequencing of the Combo-PHY transmitters */
+ gen11_dsi_config_phy_lanes_sequence(encoder);
}
static void __attribute__((unused))
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 00/13] ICELAKE DSI DRIVER
From ICELAKE platform onwards, new MIPI DSI IP controller is integrated to GPU/Display Engine and same could be extended for future Intel platforms as well. DSI IP controller supports MIPI DSI 1.3 and DPHY 1.2 specification. So, a new DSI driver has been added inside I915. Given below patches are the part of new DSI driver which implements BSPEC sequence till transcoder configuration. Rest of the patches published to GITHUB and latest snapshot can be downloaded using: #git clone https://github.com/madhavchauhan/Intel-DSI-Driver.git v2: Addressed review comments from Jani N for Patches 1-6 and rebase for some other few patches. v3: Renamed intel_dsi_new.c to gen11_dsi.c as per discussion with Jani, Daniel, Ville. Also addressed review comments for couple of patches. v4: Rename gen11_dsi.c to icl_dsi.c (Ville). No functional changes. v5: Rebase on drm-tip after initial 7 patches got merged. Madhav Chauhan (13): drm/i915/icl: Configure lane sequencing of combo phy transmitter drm/i915/icl: DSI vswing programming sequence drm/i915/icl: Enable DDI Buffer drm/i915/icl: Define T_INIT_MASTER registers drm/i915/icl: Program T_INIT_MASTER registers drm/i915/icl: Define data/clock lanes dphy timing registers drm/i915/icl: Program DSI clock and data lane timing params drm/i915/icl: Define TA_TIMING_PARAM registers drm/i915/icl: Program TA_TIMING_PARAM registers drm/i915/icl: Get DSI transcoder for a given port drm/i915/icl: Add macros for MMIO of DSI transcoder registers drm/i915/icl: Define TRANS_DSI_FUNC_CONF register drm/i915/icl: Configure DSI transcoders drivers/gpu/drm/i915/i915_reg.h | 112 drivers/gpu/drm/i915/icl_dsi.c | 324 +++ drivers/gpu/drm/i915/intel_display.h | 6 +- drivers/gpu/drm/i915/intel_dsi.h | 7 + drivers/gpu/drm/i915/intel_dsi_vbt.c | 202 -- 5 files changed, 593 insertions(+), 58 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 11/13] drm/i915/icl: Add macros for MMIO of DSI transcoder registers
This patch adds _MMIO_DSI and _DSI_TRANS macros for accessing
DSI transcoder registers.
Credits-to: Jani N
Cc: Jani Nikula
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1d13ba9..62bc76e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9576,6 +9576,11 @@ enum skl_power_gate {
#define _MIPI_PORT(port, a, c) (((port) == PORT_A) ? a : c)/* ports A and
C only */
#define _MMIO_MIPI(port, a, c) _MMIO(_MIPI_PORT(port, a, c))
+/* gen11 DSI */
+#define _DSI_TRANS(tc, dsi0, dsi1) (((tc) == TRANSCODER_DSI_0) ? \
+(dsi0) : (dsi1))
+#define _MMIO_DSI(tc, dsi0, dsi1) _MMIO(_DSI_TRANS(tc, dsi0, dsi1))
+
#define MIPIO_TXESC_CLK_DIV1 _MMIO(0x160004)
#define GLK_TX_ESC_CLK_DIV1_MASK 0x3FF
#define MIPIO_TXESC_CLK_DIV2 _MMIO(0x160008)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 04/13] drm/i915/icl: Define T_INIT_MASTER registers
This patch defines DSI_T_INIT_MASTER register for DSI ports
0/1 which will be used in dphy programming.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0424e45..6129372 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10069,6 +10069,12 @@ enum skl_power_gate {
#define PREPARE_COUNT_SHIFT 0
#define PREPARE_COUNT_MASK(0x3f << 0)
+#define _ICL_DSI_T_INIT_MASTER_0 0x6b088
+#define _ICL_DSI_T_INIT_MASTER_1 0x6b888
+#define ICL_DSI_T_INIT_MASTER(port)_MMIO_PORT(port,\
+ _ICL_DSI_T_INIT_MASTER_0,\
+ _ICL_DSI_T_INIT_MASTER_1)
+
/* bits 31:0 */
#define _MIPIA_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb084)
#define _MIPIC_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb884)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 13/13] drm/i915/icl: Configure DSI transcoders
This patch programs DSI operation mode, pixel format,
BGR info, link calibration etc for the DSI transcoder.
This patch also extract BGR info of the DSI panel from
VBT and save it inside struct intel_dsi which used for
configuring DSI transcoder.
v2: Rebase
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/icl_dsi.c | 87 +++-
drivers/gpu/drm/i915/intel_dsi.h | 3 ++
drivers/gpu/drm/i915/intel_dsi_vbt.c | 1 +
3 files changed, 89 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index 243f434..be20d3f 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -27,8 +27,7 @@
#include "intel_dsi.h"
-static enum transcoder __attribute__((unused)) dsi_port_to_transcoder(
- enum port port)
+static enum transcoder dsi_port_to_transcoder(enum port port)
{
if (port == PORT_A)
return TRANSCODER_DSI_0;
@@ -334,6 +333,87 @@ static void gen11_dsi_setup_dphy_timings(struct
intel_encoder *encoder)
}
}
+static void gen11_dsi_configure_transcoder(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
+ u32 tmp;
+ enum port port;
+ enum transcoder dsi_trans;
+
+ for_each_dsi_port(port, intel_dsi->ports) {
+ dsi_trans = dsi_port_to_transcoder(port);
+ tmp = I915_READ(DSI_TRANS_FUNC_CONF(dsi_trans));
+
+ if (intel_dsi->eotp_pkt == 0)
+ tmp |= EOTP_DISABLED;
+ else
+ tmp &= ~EOTP_DISABLED;
+
+ /* enable link calibration if freq > 1.5Gbps */
+ if (intel_dsi->bitrate_khz >= (1500 * 1000)) {
+ tmp &= ~LINK_CALIBRATION_MASK;
+ tmp |= LINK_CALIBRATION(
+ CALIBRATION_ENABLED_INITIAL_ONLY);
+ }
+
+ /* configure continuous clock */
+ tmp &= ~CONTINUOUS_CLK_MASK;
+ if (intel_dsi->clock_stop)
+ tmp |= CONTINUOUS_CLK(CLK_ENTER_LP_AFTER_DATA);
+ else
+ tmp |= CONTINUOUS_CLK(CLK_HS_CONTINUOUS);
+
+ /* configure buffer threshold limit to minimum */
+ tmp &= ~PIX_BUF_THRESHOLD_MASK;
+ tmp |= PIX_BUF_THRESHOLD(PIX_BUF_THRESHOLD_1_4);
+
+ /* set virtual channel to '0' */
+ tmp &= ~PIX_VIRT_CHAN_MASK;
+ tmp |= PIX_VIRT_CHAN(0x0);
+
+ /* program BGR transmission */
+ if (intel_dsi->bgr_enabled)
+ tmp |= BGR_TRANSMISSION;
+
+ /* select pixel format */
+ tmp &= ~PIX_FMT_MASK;
+
+ switch (intel_dsi->pixel_format) {
+ case MIPI_DSI_FMT_RGB888:
+ tmp |= PIX_FMT(PIX_FMT_RGB888);
+ break;
+ case MIPI_DSI_FMT_RGB666:
+ tmp |= PIX_FMT(PIX_FMT_RGB666_LOOSE);
+ break;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ tmp |= PIX_FMT(PIX_FMT_RGB666_PACKED);
+ break;
+ case MIPI_DSI_FMT_RGB565:
+ tmp |= PIX_FMT(PIX_FMT_RGB565);
+ break;
+ default:
+ DRM_ERROR("DSI pixel format unsupported\n");
+ }
+
+ /* program DSI operation mode */
+ if (intel_dsi->operation_mode == INTEL_DSI_VIDEO_MODE) {
+ tmp &= ~OP_MODE_MASK;
+ if (intel_dsi->video_mode_format ==
+ VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE) {
+ tmp |= OP_MODE(VIDEO_MODE_SYNC_PULSE);
+ } else if (intel_dsi->video_mode_format ==
+ VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS) {
+ tmp |= OP_MODE(VIDEO_MODE_SYNC_EVENT);
+ } else {
+ DRM_ERROR("DSI Video Mode unsupported\n");
+ }
+ }
+
+ I915_WRITE(DSI_TRANS_FUNC_CONF(dsi_trans), tmp);
+ }
+}
+
static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
{
/* step 4a: power up all lanes of the DDI used by DSI */
@@ -350,6 +430,9 @@ static void gen11_dsi_enable_port_and_phy(struct
intel_encoder *encoder)
/* step 4e: setup D-PHY timings */
gen11_dsi_setup_dphy_timings(encoder);
+
+ /* Step (4h, 4i, 4j, 4k): Configure transcoder */
+ gen11_dsi_configure_transcoder(encoder);
}
static void __attribute__((unused))
diff --git a/drivers/gpu/drm/i915/intel_dsi.h
[Intel-gfx] [PATCH v5 02/13] drm/i915/icl: DSI vswing programming sequence
This patch setup voltage swing before enabling
combo PHY DDI (shared with DSI).
Note that DSI voltage swing programming is for
high speed data buffers. HW automatically handles
the voltage swing for the low power data buffers.
v2: Rebase
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/icl_dsi.c | 114 +
1 file changed, 114 insertions(+)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index a571339..dc16c1f 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -27,6 +27,65 @@
#include "intel_dsi.h"
+static void dsi_program_swing_and_deemphasis(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
+ enum port port;
+ u32 tmp;
+ int lane;
+
+ for_each_dsi_port(port, intel_dsi->ports) {
+
+ /* Bspec: set scaling mode to 0x6 */
+ tmp = I915_READ(ICL_PORT_TX_DW5_LN0(port));
+ tmp |= SCALING_MODE_SEL(6);
+ I915_WRITE(ICL_PORT_TX_DW5_GRP(port), tmp);
+ tmp = I915_READ(ICL_PORT_TX_DW5_AUX(port));
+ tmp |= SCALING_MODE_SEL(6);
+ I915_WRITE(ICL_PORT_TX_DW5_AUX(port), tmp);
+ tmp = I915_READ(ICL_PORT_TX_DW5_LN0(port));
+ tmp |= TAP2_DISABLE | TAP3_DISABLE;
+ I915_WRITE(ICL_PORT_TX_DW5_GRP(port), tmp);
+ tmp = I915_READ(ICL_PORT_TX_DW5_AUX(port));
+ tmp |= TAP2_DISABLE | TAP3_DISABLE;
+ I915_WRITE(ICL_PORT_TX_DW5_AUX(port), tmp);
+
+ /*
+* swing and scaling values are taken from DSI
+* table under vswing programming sequence for
+* combo phy ddi in BSPEC.
+* program swing values
+*/
+ tmp = I915_READ(ICL_PORT_TX_DW2_LN0(port));
+ tmp |= SWING_SEL_UPPER(0x2);
+ tmp |= SWING_SEL_LOWER(0x2);
+ tmp |= RCOMP_SCALAR(0x98);
+ I915_WRITE(ICL_PORT_TX_DW2_GRP(port), tmp);
+ tmp = I915_READ(ICL_PORT_TX_DW2_AUX(port));
+ tmp |= SWING_SEL_UPPER(0x2);
+ tmp |= SWING_SEL_LOWER(0x2);
+ tmp |= RCOMP_SCALAR(0x98);
+ I915_WRITE(ICL_PORT_TX_DW2_AUX(port), tmp);
+
+ /* program scaling values */
+ tmp = I915_READ(ICL_PORT_TX_DW4_AUX(port));
+ tmp |= POST_CURSOR_1(0x0);
+ tmp |= POST_CURSOR_2(0x0);
+ tmp |= CURSOR_COEFF(0x18);
+ I915_WRITE(ICL_PORT_TX_DW4_AUX(port), tmp);
+
+ for (lane = 0; lane <= 3; lane++) {
+ /* Bspec: must not use GRP register for write */
+ tmp = I915_READ(ICL_PORT_TX_DW4_LN(port, lane));
+ tmp |= POST_CURSOR_1(0x0);
+ tmp |= POST_CURSOR_2(0x0);
+ tmp |= CURSOR_COEFF(0x18);
+ I915_WRITE(ICL_PORT_TX_DW4_LN(port, lane), tmp);
+ }
+ }
+}
+
static void gen11_dsi_program_esc_clk_div(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
@@ -140,6 +199,58 @@ static void gen11_dsi_config_phy_lanes_sequence(struct
intel_encoder *encoder)
}
}
+static void gen11_dsi_voltage_swing_program_seq(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
+ u32 tmp;
+ enum port port;
+
+ /* Step C.1:clear common keeper enable bit */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(ICL_PORT_PCS_DW1_LN0(port));
+ tmp &= ~COMMON_KEEPER_EN;
+ I915_WRITE(ICL_PORT_PCS_DW1_GRP(port), tmp);
+ tmp = I915_READ(ICL_PORT_PCS_DW1_AUX(port));
+ tmp &= ~COMMON_KEEPER_EN;
+ I915_WRITE(ICL_PORT_PCS_DW1_AUX(port), tmp);
+ }
+
+ /*
+* Step C.3: Set SUS Clock Config bitfield to 11b
+* Note: Step C.2 (loadgen select program) is done
+* as part of lane phy sequence configuration
+*/
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(ICL_PORT_CL_DW5(port));
+ tmp |= SUS_CLOCK_CONFIG;
+ I915_WRITE(ICL_PORT_CL_DW5(port), tmp);
+ }
+
+ /* Step C.4: Clear training enable to change swing values */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(ICL_PORT_TX_DW5_LN0(port));
+ tmp &= ~TX_TRAINING_EN;
+ I915_WRITE(ICL_PORT_TX_DW5_GRP(port), tmp);
+ tmp = I915_READ(ICL_PORT_TX_DW5_AUX(port));
+ tmp &= ~TX_TRAINING_EN;
+
[Intel-gfx] [PATCH v5 05/13] drm/i915/icl: Program T_INIT_MASTER registers
This patch programs the time (in escape clocks) to drive
the link in the initialization (i.e. LP-11) state.
v2: Rebase
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/icl_dsi.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index 41faa19..bc27e34 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -270,6 +270,22 @@ static void gen11_dsi_enable_ddi_buffer(struct
intel_encoder *encoder)
}
}
+static void gen11_dsi_setup_dphy_timings(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
+ u32 tmp;
+ enum port port;
+
+ /* Program T-INIT master registers */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(ICL_DSI_T_INIT_MASTER(port));
+ tmp &= ~MASTER_INIT_TIMER_MASK;
+ tmp |= intel_dsi->init_count;
+ I915_WRITE(ICL_DSI_T_INIT_MASTER(port), tmp);
+ }
+}
+
static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
{
/* step 4a: power up all lanes of the DDI used by DSI */
@@ -283,6 +299,9 @@ static void gen11_dsi_enable_port_and_phy(struct
intel_encoder *encoder)
/* step 4d: enable DDI buffer */
gen11_dsi_enable_ddi_buffer(encoder);
+
+ /* step 4e: setup D-PHY timings */
+ gen11_dsi_setup_dphy_timings(encoder);
}
static void __attribute__((unused))
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 03/13] drm/i915/icl: Enable DDI Buffer
This patch enables DDI buffer by writing to DDI_BUF_CTL
register and wait for DDI status to be *not idle* for a
port.
v2: Rebase
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/icl_dsi.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index dc16c1f..41faa19 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -251,6 +251,25 @@ static void gen11_dsi_voltage_swing_program_seq(struct
intel_encoder *encoder)
}
}
+static void gen11_dsi_enable_ddi_buffer(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
+ u32 tmp;
+ enum port port;
+
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(DDI_BUF_CTL(port));
+ tmp |= DDI_BUF_CTL_ENABLE;
+ I915_WRITE(DDI_BUF_CTL(port), tmp);
+
+ if (wait_for_us(!(I915_READ(DDI_BUF_CTL(port)) &
+ DDI_BUF_IS_IDLE),
+ 500))
+ DRM_ERROR("DDI port:%c buffer idle\n", port_name(port));
+ }
+}
+
static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
{
/* step 4a: power up all lanes of the DDI used by DSI */
@@ -261,6 +280,9 @@ static void gen11_dsi_enable_port_and_phy(struct
intel_encoder *encoder)
/* step 4c: configure voltage swing and skew */
gen11_dsi_voltage_swing_program_seq(encoder);
+
+ /* step 4d: enable DDI buffer */
+ gen11_dsi_enable_ddi_buffer(encoder);
}
static void __attribute__((unused))
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 07/13] drm/i915/icl: Program DSI clock and data lane timing params
This patch programs D-PHY timing parameters for the
clock and data lane (in escape clocks) of DSI
controller (DSI port 0 and 1).
These programmed timings would be used by DSI Controller
to calculate link transition latencies of the data and
clock lanes.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/icl_dsi.c | 18
drivers/gpu/drm/i915/intel_dsi.h | 3 +
drivers/gpu/drm/i915/intel_dsi_vbt.c | 200 +--
3 files changed, 165 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index bc27e34..832772d 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -284,6 +284,24 @@ static void gen11_dsi_setup_dphy_timings(struct
intel_encoder *encoder)
tmp |= intel_dsi->init_count;
I915_WRITE(ICL_DSI_T_INIT_MASTER(port), tmp);
}
+
+ /* Program DPHY clock lanes timings */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ I915_WRITE(DPHY_CLK_TIMING_PARAM(port), intel_dsi->dphy_reg);
+
+ /* shadow register inside display core */
+ I915_WRITE(DSI_CLK_TIMING_PARAM(port), intel_dsi->dphy_reg);
+ }
+
+ /* Program DPHY data lanes timings */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ I915_WRITE(DPHY_DATA_TIMING_PARAM(port),
+ intel_dsi->dphy_data_lane_reg);
+
+ /* shadow register inside display core */
+ I915_WRITE(DSI_DATA_TIMING_PARAM(port),
+ intel_dsi->dphy_data_lane_reg);
+ }
}
static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index ad7c1cb..9fd8526 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -85,6 +85,9 @@ struct intel_dsi {
u32 port_bits;
u32 bw_timer;
u32 dphy_reg;
+
+ /* data lanes dphy timing */
+ u32 dphy_data_lane_reg;
u32 video_frmt_cfg_bits;
u16 lp_byte_clk;
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index ac83d6b..428290d 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -509,7 +509,9 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
u32 bpp;
u32 tlpx_ns, extra_byte_count, bitrate, tlpx_ui;
u32 ui_num, ui_den;
- u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt, trail_cnt;
+ u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt, trail_cnt, hs_zero_cnt;
+ u32 tclk_pre_cnt, tclk_post_cnt;
+ u32 tclk_pre_ns, tclk_post_ns;
u32 ths_prepare_ns, tclk_trail_ns;
u32 tclk_prepare_clkzero, ths_prepare_hszero;
u32 lp_to_hs_switch, hs_to_lp_switch;
@@ -624,76 +626,157 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
tclk_prepare_clkzero = mipi_config->tclk_prepare_clkzero;
ths_prepare_hszero = mipi_config->ths_prepare_hszero;
-
+ tclk_trail_ns = max(mipi_config->tclk_trail, mipi_config->ths_trail);
+ ths_prepare_ns = max(mipi_config->ths_prepare,
+ mipi_config->tclk_prepare);
/*
* B060
* LP byte clock = TLPX/ (8UI)
*/
intel_dsi->lp_byte_clk = DIV_ROUND_UP(tlpx_ns * ui_den, 8 * ui_num);
- /* DDR clock period = 2 * UI
-* UI(sec) = 1/(bitrate * 10^3) (bitrate is in KHZ)
-* UI(nsec) = 10^6 / bitrate
-* DDR clock period (nsec) = 2 * UI = (2 * 10^6)/ bitrate
-* DDR clock count = ns_value / DDR clock period
-*
+ /*
* For GEMINILAKE dphy_param_reg will be programmed in terms of
* HS byte clock count for other platform in HS ddr clock count
*/
mul = IS_GEMINILAKE(dev_priv) ? 8 : 2;
- ths_prepare_ns = max(mipi_config->ths_prepare,
-mipi_config->tclk_prepare);
- /* prepare count */
- prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * ui_den, ui_num * mul);
+ if (IS_ICELAKE(dev_priv)) {
+ /*
+* prepare cnt in escape clocks
+* this field represents a hexadecimal value with a precision
+* of 1.2 – i.e. the most significant bit is the integer
+* and the least significant 2 bits are fraction bits.
+* so, the field can represent a range of 0.25 to 1.75
+*/
+ prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * 4, tlpx_ns);
+
+ /* clk zero count in escape clocks */
+ clk_zero_cnt = DIV_ROUND_UP(
+ (tclk_prepare_clkzero - ths_prepare_ns),
+ tlpx_ns);
+
+ /* trail cnt in escape clocks*/
+ trail_cnt =
Re: [Intel-gfx] [PATCH 2/2] drm/i915: kill resource streamer
Quoting Lucas De Marchi (2018-07-10 01:06:58)
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 1932bc227942..a5eec97a40fe 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -2221,19 +2221,8 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> if (!eb.engine)
> return -EINVAL;
>
> - if (args->flags & I915_EXEC_RESOURCE_STREAMER) {
> - if (!HAS_RESOURCE_STREAMER(eb.i915)) {
> - DRM_DEBUG("RS is only allowed for Haswell and Gen8 -
> Gen10\n");
> - return -EINVAL;
> - }
> - if (eb.engine->id != RCS) {
> - DRM_DEBUG("RS is not available on %s\n",
> -eb.engine->name);
> - return -EINVAL;
> - }
> -
> - eb.batch_flags |= I915_DISPATCH_RS;
> - }
> + if (args->flags & I915_EXEC_RESOURCE_STREAMER)
> + DRM_DEBUG("RS is removed from all Gens: ignoring.\n");
return -EINVAL;
If userspace set up its batch on the assumption that RS is enabled, it
will fail.
> @@ -2657,10 +2656,7 @@ static void execlists_init_reg_state(u32 *regs,
>
> CTX_REG(regs, CTX_CONTEXT_CONTROL, RING_CONTEXT_CONTROL(engine),
> _MASKED_BIT_DISABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT |
> - CTX_CTRL_ENGINE_CTX_SAVE_INHIBIT) |
> - _MASKED_BIT_ENABLE(CTX_CTRL_INHIBIT_SYN_CTX_SWITCH |
Bring back INHIBIT_SYNC_CTX_SWITCH.
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 7f5634ce8e88..179e0477dbc6 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -449,6 +449,7 @@ typedef struct drm_i915_irq_wait {
> #define I915_PARAM_SUBSLICE_TOTAL 33
> #define I915_PARAM_EU_TOTAL 34
> #define I915_PARAM_HAS_GPU_RESET35
> +/* Deprecated: do not use */
Don't bother. As written it implies all subsequent param are deprecated.
Userspace knows simply by the query return.
> #define I915_PARAM_HAS_RESOURCE_STREAMER 36
> #define I915_PARAM_HAS_EXEC_SOFTPIN 37
> #define I915_PARAM_HAS_POOLED_EU38
___
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: Filter out both physical address swizzles
== Series Details == Series: drm/i915/selftests: Filter out both physical address swizzles URL : https://patchwork.freedesktop.org/series/46214/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4456_full -> Patchwork_9597_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9597_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9597_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_9597_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP +3 == Known issues == Here are the changes found in Patchwork_9597_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#106509, fdo#105454) igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105189) Possible fixes igt@drv_selftest@live_workarounds: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@kms_flip@2x-dpms-vs-vblank-race-interruptible: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip@flip-vs-panning-vs-hang: shard-snb: DMESG-WARN (fdo#103821) -> PASS igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#107161) -> PASS +1 igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS shard-hsw: FAIL (fdo#99912) -> PASS shard-kbl: FAIL (fdo#99912) -> PASS fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#107161 https://bugs.freedesktop.org/show_bug.cgi?id=107161 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4456 -> Patchwork_9597 CI_DRM_4456: bba42f28e4944fa7ac6ea7c2269504877faef851 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4544: 764160f214cd916ddb79408b9f28ac0ad2df40e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9597: eaaef26f8bc26046db89f474aa0048e903e4db11 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9597/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote: > On Wed 27-06-18 09:44:21, Michal Hocko wrote: > > This is the v2 of RFC based on the feedback I've received so far. The > > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly > > because I have no idea how. > > > > Any further feedback is highly appreciated of course. > > Any other feedback before I post this as non-RFC? From mlx5 perspective, who is primary user of umem_odp.c your change looks ok. Thanks signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] benchmarks/wsim: Simulate and interpret .wsim
Quoting Tvrtko Ursulin (2018-05-11 09:31:52) > > On 11/05/2018 08:11, Chris Wilson wrote: > > A little tool I've been meaning to write for a while... Convert the > > .wsim into their dag and find the longest chains and evaluate them on an > > simulated machine. > > Very cool! Would you care to ack it in its current form, knowing that we will fix it whenever we find a corner case interesting enough to study? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/7] Remove parameter aliases with another argument
On Sat, Jul 07, 2018 at 08:22:25PM -0300, Rodrigo Siqueira wrote:
> This commit fixes the following GCC warning:
>
> warning: passing argument 2 to restrict-qualified parameter aliases with
> argument 1 [-Wrestrict]
> return (readlink (buf, buf, sizeof (buf)) != -1 &&
>
> This commit fixes the GCC warning by creating a second buffer only to
> keep the path.
>
> Signed-off-by: Rodrigo Siqueira
> ---
> lib/igt_core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/lib/igt_core.c b/lib/igt_core.c
> index 3313050c..fa22f12d 100644
> --- a/lib/igt_core.c
> +++ b/lib/igt_core.c
> @@ -1169,10 +1169,10 @@ bool igt_can_fail(void)
>
> static bool run_under_gdb(void)
> {
> - char buf[1024];
> + char pathname[1024], buf[1024];
1024 for pathname is quite an overshoot. We stash at most
"/proc/%d/exec" where %d should be at most 21 or so.
> - sprintf(buf, "/proc/%d/exe", getppid());
> - return (readlink (buf, buf, sizeof (buf)) != -1 &&
> + sprintf(pathname, "/proc/%d/exe", getppid());
> + return (readlink (pathname, buf, sizeof (buf)) != -1 &&
^ while we are here we can get rid of that space
> strncmp(basename(buf), "gdb", 3) == 0);
> }
>
> --
> 2.18.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/7] Cast void * pointer used in arithmetic to uint32_t*
On Sat, Jul 07, 2018 at 08:22:38PM -0300, Rodrigo Siqueira wrote:
> This commit fixes the GCC warning:
>
> warning: pointer of type ‘void *’ used in arithmetic [-Wpointer-arith]
> memset(ptr + offsets[0], full_range ? 0x00 : 0x10,
> ^
> warning: pointer of type ‘void *’ used in arithmetic [-Wpointer-arith]
> memset(ptr + offsets[1], 0x80,
>
> This commit cast the ptr pointer, which is a void *, to uint32_t * in
> the pointer arithmetic operation.
This will change semantics, as according to GNU C standard[1], void
pointers have a size of 1 for all arithmetical purposes.
So you should be using uint8_t (or char) pointer instead.
[1]: http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html
> Signed-off-by: Rodrigo Siqueira
> ---
> lib/igt_fb.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/lib/igt_fb.c b/lib/igt_fb.c
> index ae71d967..ca905038 100644
> --- a/lib/igt_fb.c
> +++ b/lib/igt_fb.c
> @@ -410,9 +410,11 @@ static int create_bo_for_fb(int fd, int width, int
> height,
>
> switch (format->drm_id) {
> case DRM_FORMAT_NV12:
> - memset(ptr + offsets[0], full_range ? 0x00 :
> 0x10,
> + memset(((uint32_t *)ptr) + offsets[0],
> +full_range ? 0x00 : 0x10,
> calculated_stride * height);
> - memset(ptr + offsets[1], 0x80,
> + memset(((uint32_t *)ptr) + offsets[1],
> +0x80,
> calculated_stride * height/2);
> break;
> case DRM_FORMAT_YUYV:
> --
> 2.18.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 4/7] Fix truncate string in the snprintf
On Sat, Jul 07, 2018 at 08:23:17PM -0300, Rodrigo Siqueira wrote:
> This patch fix the following GCC warning:
>
> intel_reg.c: In function ‘dump_decode’:
> warning: ‘snprintf’ output may be truncated before the last format character
> [-Wformat-truncation=]
>snprintf(decode, sizeof(decode), "\n%s", bin);
> intel_reg.c:203:3: note: ‘snprintf’ output between 2 and 1025 bytes into a
> destination of size 1024
> [..]
That's an odd error.
Line 203:
snprintf(decode, sizeof(decode), "\n%s", bin);
man snprintf states:
The functions snprintf() and vsnprintf() write at most size
bytes (including the terminating null byte ('\0')) to str.
So this should be truncated correctly. Am I missing something?
I'll set up gcc 8.1 tomorrow and poke around.
> Signed-off-by: Rodrigo Siqueira
> ---
> tools/intel_reg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/intel_reg.c b/tools/intel_reg.c
> index ddff2794..15ebb86a 100644
> --- a/tools/intel_reg.c
> +++ b/tools/intel_reg.c
> @@ -180,7 +180,7 @@ static void to_binary(char *buf, size_t buflen, uint32_t
> val)
>
> static void dump_decode(struct config *config, struct reg *reg, uint32_t val)
> {
> - char decode[1024];
> + char decode[2060];
> char tmp[1024];
> char bin[1024];
>
> --
> 2.18.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Tue 10-07-18 16:40:40, Leon Romanovsky wrote: > On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote: > > On Wed 27-06-18 09:44:21, Michal Hocko wrote: > > > This is the v2 of RFC based on the feedback I've received so far. The > > > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly > > > because I have no idea how. > > > > > > Any further feedback is highly appreciated of course. > > > > Any other feedback before I post this as non-RFC? > > From mlx5 perspective, who is primary user of umem_odp.c your change looks ok. Can I assume your Acked-by? Thanks for your review! -- Michal Hocko SUSE Labs ___ 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 2/7] Cast void * pointer used in arithmetic to uint32_t*
On Tue, Jul 10, 2018 at 03:09:25PM +0100, Chris Wilson wrote: > Quoting Arkadiusz Hiler (2018-07-10 14:58:49) > > On Sat, Jul 07, 2018 at 08:22:38PM -0300, Rodrigo Siqueira wrote: > > > This commit fixes the GCC warning: > > > > > > warning: pointer of type ‘void *’ used in arithmetic [-Wpointer-arith] > > > memset(ptr + offsets[0], full_range ? 0x00 : 0x10, > > > ^ > > > warning: pointer of type ‘void *’ used in arithmetic [-Wpointer-arith] > > > memset(ptr + offsets[1], 0x80, > > > > > > This commit cast the ptr pointer, which is a void *, to uint32_t * in > > > the pointer arithmetic operation. > > > > This will change semantics, as according to GNU C standard[1], void > > pointers have a size of 1 for all arithmetical purposes. > > > > So you should be using uint8_t (or char) pointer instead. > > Please just fix the compiler flags, we want close compatibility with the > kernel coding standards which explicitly allow void arithmetic for the > simplicity it lends to writing code. > -Chris Fair point. We don't rise the error with meson, so it is not a change in the gcc defaults. Somehow autotools manage to end up adding -Wpointer-arith to BASE_CFLAGS. I don't think we should invest time into making autotools behave, since it's going to be dropped completely. Hopefully this will happen sooner than later. -- Cheers, Arek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Unwind HW init after GVT setup failure
Quoting Chris Wilson (2018-07-10 15:38:21) > Following intel_gvt_init() failure, we missed unwinding our setup > leaving pointers dangling past the module unload. For our example, the > pm_qos: > > [ 441.057615] top: 6b3baf1c, n: 54d8ef33, p: 97cdf1a2 >prev: 54d8ef33, n: 97cdf1a2, p: > 6b3baf1c >next: 97cdf1a2, n: 6de8fc8b, p: > 81087253 > [ 441.057627] WARNING: CPU: 4 PID: 9277 at lib/plist.c:42 > plist_check_prev_next+0x2d/0x40 > [ 441.057628] Modules linked in: i915(+) vgem snd_hda_codec_hdmi > snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal > intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel > snd_hda_codec snd_hwdep snd_hda_core e1000e snd_pcm mei_me mei prime_numbers > [last unloaded: i915] > [ 441.057652] CPU: 4 PID: 9277 Comm: drv_selftest Tainted: G U > 4.18.0-rc4-CI-CI_DRM_4464+ #1 > [ 441.057653] Hardware name: System manufacturer System Product Name/Z170 > PRO GAMING, BIOS 3402 04/26/2017 > [ 441.057656] RIP: 0010:plist_check_prev_next+0x2d/0x40 > [ 441.057657] Code: 08 48 39 f0 74 2b 49 89 f0 48 8b 4f 08 50 ff 32 52 48 89 > fe 41 ff 70 08 48 8b 17 48 c7 c7 d8 ae 14 82 4d 8b 08 e8 63 0e 76 ff <0f> 0b > 48 83 c4 20 c3 48 39 10 75 d0 f3 c3 0f 1f 44 00 00 41 54 55 > [ 441.057717] RSP: 0018:c93a3a68 EFLAGS: 00010082 > [ 441.057720] RAX: RBX: 8802193978c0 RCX: > 0002 > [ 441.057721] RDX: 8002 RSI: 820c65a4 RDI: > > [ 441.057722] RBP: 8802193978c0 R08: R09: > 0001 > [ 441.057724] R10: c93a3a70 R11: R12: > 82243de0 > [ 441.057725] R13: 82243de0 R14: 88021a6c78c0 R15: > 77359400 > [ 441.057726] FS: 7fc23a4a9980() GS:880236d0() > knlGS: > [ 441.057728] CS: 0010 DS: ES: CR0: 80050033 > [ 441.057729] CR2: 563e4503d038 CR3: 000138f86005 CR4: > 003606e0 > [ 441.057730] DR0: DR1: DR2: > > [ 441.057731] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 441.057732] Call Trace: > [ 441.057736] plist_check_list+0x2e/0x40 > [ 441.057738] plist_add+0x23/0x130 > [ 441.057743] pm_qos_update_target+0x1bd/0x2f0 > [ 441.057771] i915_driver_load+0xec4/0x1060 [i915] > [ 441.057775] ? trace_hardirqs_on_caller+0xe0/0x1b0 > [ 441.057800] i915_pci_probe+0x29/0x90 [i915] > [ 441.057804] pci_device_probe+0xa1/0x130 > [ 441.057807] driver_probe_device+0x306/0x480 > [ 441.057810] __driver_attach+0xdb/0x100 > [ 441.057812] ? driver_probe_device+0x480/0x480 > [ 441.057813] ? driver_probe_device+0x480/0x480 > [ 441.057816] bus_for_each_dev+0x74/0xc0 > [ 441.057819] bus_add_driver+0x15f/0x250 > [ 441.057821] ? 0xa0696000 > [ 441.057823] driver_register+0x56/0xe0 > [ 441.057825] ? 0xa0696000 > [ 441.057827] do_one_initcall+0x58/0x370 > [ 441.057830] ? do_init_module+0x1d/0x1ea > [ 441.057832] ? rcu_read_lock_sched_held+0x6f/0x80 > [ 441.057834] ? kmem_cache_alloc_trace+0x282/0x2e0 > [ 441.057838] do_init_module+0x56/0x1ea > [ 441.057841] load_module+0x2435/0x2b20 > [ 441.057852] ? __se_sys_finit_module+0xd3/0xf0 > [ 441.057854] __se_sys_finit_module+0xd3/0xf0 > [ 441.057861] do_syscall_64+0x55/0x190 > [ 441.057863] entry_SYSCALL_64_after_hwframe+0x49/0xbe > [ 441.057865] RIP: 0033:0x7fc239d75839 > [ 441.057866] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 > f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d > 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48 > [ 441.057927] RSP: 002b:7fffb7825d38 EFLAGS: 0246 ORIG_RAX: > 0139 > [ 441.057930] RAX: ffda RBX: 563e45035dd0 RCX: > 7fc239d75839 > [ 441.057931] RDX: RSI: 563e4502f8a0 RDI: > 0004 > [ 441.057932] RBP: 563e4502f8a0 R08: 0004 R09: > > [ 441.057933] R10: 7fffb7825ea0 R11: 0246 R12: > > [ 441.057934] R13: 563e4502f690 R14: R15: > 003f > [ 441.057940] irq event stamp: 231338 > [ 441.057943] hardirqs last enabled at (231337): [] > _raw_spin_unlock_irqrestore+0x4c/0x60 > [ 441.057944] hardirqs last disabled at (231338): [] > _raw_spin_lock_irqsave+0xd/0x50 > [ 441.057947] softirqs last enabled at (231024): [] > __do_softirq+0x34f/0x505 > [ 441.057949] softirqs last disabled at (231005): [] > irq_exit+0xa9/0xc0 > [ 441.057951] WARNING: CPU: 4 PID: 9277 at lib/plist.c:42 > plist_check_prev_next+0x2d/0x40 > > v2: Add a load failure point to intel_gvt_init() so that we always > exercise this path in future. Bugzilla:
[Intel-gfx] [PATCH v2] drm/i915: Unwind HW init after GVT setup failure
Following intel_gvt_init() failure, we missed unwinding our setup leaving pointers dangling past the module unload. For our example, the pm_qos: [ 441.057615] top: 6b3baf1c, n: 54d8ef33, p: 97cdf1a2 prev: 54d8ef33, n: 97cdf1a2, p: 6b3baf1c next: 97cdf1a2, n: 6de8fc8b, p: 81087253 [ 441.057627] WARNING: CPU: 4 PID: 9277 at lib/plist.c:42 plist_check_prev_next+0x2d/0x40 [ 441.057628] Modules linked in: i915(+) vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core e1000e snd_pcm mei_me mei prime_numbers [last unloaded: i915] [ 441.057652] CPU: 4 PID: 9277 Comm: drv_selftest Tainted: G U 4.18.0-rc4-CI-CI_DRM_4464+ #1 [ 441.057653] Hardware name: System manufacturer System Product Name/Z170 PRO GAMING, BIOS 3402 04/26/2017 [ 441.057656] RIP: 0010:plist_check_prev_next+0x2d/0x40 [ 441.057657] Code: 08 48 39 f0 74 2b 49 89 f0 48 8b 4f 08 50 ff 32 52 48 89 fe 41 ff 70 08 48 8b 17 48 c7 c7 d8 ae 14 82 4d 8b 08 e8 63 0e 76 ff <0f> 0b 48 83 c4 20 c3 48 39 10 75 d0 f3 c3 0f 1f 44 00 00 41 54 55 [ 441.057717] RSP: 0018:c93a3a68 EFLAGS: 00010082 [ 441.057720] RAX: RBX: 8802193978c0 RCX: 0002 [ 441.057721] RDX: 8002 RSI: 820c65a4 RDI: [ 441.057722] RBP: 8802193978c0 R08: R09: 0001 [ 441.057724] R10: c93a3a70 R11: R12: 82243de0 [ 441.057725] R13: 82243de0 R14: 88021a6c78c0 R15: 77359400 [ 441.057726] FS: 7fc23a4a9980() GS:880236d0() knlGS: [ 441.057728] CS: 0010 DS: ES: CR0: 80050033 [ 441.057729] CR2: 563e4503d038 CR3: 000138f86005 CR4: 003606e0 [ 441.057730] DR0: DR1: DR2: [ 441.057731] DR3: DR6: fffe0ff0 DR7: 0400 [ 441.057732] Call Trace: [ 441.057736] plist_check_list+0x2e/0x40 [ 441.057738] plist_add+0x23/0x130 [ 441.057743] pm_qos_update_target+0x1bd/0x2f0 [ 441.057771] i915_driver_load+0xec4/0x1060 [i915] [ 441.057775] ? trace_hardirqs_on_caller+0xe0/0x1b0 [ 441.057800] i915_pci_probe+0x29/0x90 [i915] [ 441.057804] pci_device_probe+0xa1/0x130 [ 441.057807] driver_probe_device+0x306/0x480 [ 441.057810] __driver_attach+0xdb/0x100 [ 441.057812] ? driver_probe_device+0x480/0x480 [ 441.057813] ? driver_probe_device+0x480/0x480 [ 441.057816] bus_for_each_dev+0x74/0xc0 [ 441.057819] bus_add_driver+0x15f/0x250 [ 441.057821] ? 0xa0696000 [ 441.057823] driver_register+0x56/0xe0 [ 441.057825] ? 0xa0696000 [ 441.057827] do_one_initcall+0x58/0x370 [ 441.057830] ? do_init_module+0x1d/0x1ea [ 441.057832] ? rcu_read_lock_sched_held+0x6f/0x80 [ 441.057834] ? kmem_cache_alloc_trace+0x282/0x2e0 [ 441.057838] do_init_module+0x56/0x1ea [ 441.057841] load_module+0x2435/0x2b20 [ 441.057852] ? __se_sys_finit_module+0xd3/0xf0 [ 441.057854] __se_sys_finit_module+0xd3/0xf0 [ 441.057861] do_syscall_64+0x55/0x190 [ 441.057863] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 441.057865] RIP: 0033:0x7fc239d75839 [ 441.057866] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48 [ 441.057927] RSP: 002b:7fffb7825d38 EFLAGS: 0246 ORIG_RAX: 0139 [ 441.057930] RAX: ffda RBX: 563e45035dd0 RCX: 7fc239d75839 [ 441.057931] RDX: RSI: 563e4502f8a0 RDI: 0004 [ 441.057932] RBP: 563e4502f8a0 R08: 0004 R09: [ 441.057933] R10: 7fffb7825ea0 R11: 0246 R12: [ 441.057934] R13: 563e4502f690 R14: R15: 003f [ 441.057940] irq event stamp: 231338 [ 441.057943] hardirqs last enabled at (231337): [] _raw_spin_unlock_irqrestore+0x4c/0x60 [ 441.057944] hardirqs last disabled at (231338): [] _raw_spin_lock_irqsave+0xd/0x50 [ 441.057947] softirqs last enabled at (231024): [] __do_softirq+0x34f/0x505 [ 441.057949] softirqs last disabled at (231005): [] irq_exit+0xa9/0xc0 [ 441.057951] WARNING: CPU: 4 PID: 9277 at lib/plist.c:42 plist_check_prev_next+0x2d/0x40 v2: Add a load failure point to intel_gvt_init() so that we always exercise this path in future. Signed-off-by: Chris Wilson Cc: Matthew Auld Cc: Michał Winiarski --- drivers/gpu/drm/i915/i915_drv.c | 10 +++--- drivers/gpu/drm/i915/intel_gvt.c | 3 +++ 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/7] Cast void * pointer used in arithmetic to uint32_t*
Quoting Arkadiusz Hiler (2018-07-10 14:58:49) > On Sat, Jul 07, 2018 at 08:22:38PM -0300, Rodrigo Siqueira wrote: > > This commit fixes the GCC warning: > > > > warning: pointer of type ‘void *’ used in arithmetic [-Wpointer-arith] > > memset(ptr + offsets[0], full_range ? 0x00 : 0x10, > > ^ > > warning: pointer of type ‘void *’ used in arithmetic [-Wpointer-arith] > > memset(ptr + offsets[1], 0x80, > > > > This commit cast the ptr pointer, which is a void *, to uint32_t * in > > the pointer arithmetic operation. > > This will change semantics, as according to GNU C standard[1], void > pointers have a size of 1 for all arithmetical purposes. > > So you should be using uint8_t (or char) pointer instead. Please just fix the compiler flags, we want close compatibility with the kernel coding standards which explicitly allow void arithmetic for the simplicity it lends to writing code. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Unwind HW init after GVT setup failure
Following intel_gvt_init() failure, we missed unwinding our setup leaving pointers dangling past the module unload. For our example, the pm_qos: [ 441.057615] top: 6b3baf1c, n: 54d8ef33, p: 97cdf1a2 prev: 54d8ef33, n: 97cdf1a2, p: 6b3baf1c next: 97cdf1a2, n: 6de8fc8b, p: 81087253 [ 441.057627] WARNING: CPU: 4 PID: 9277 at lib/plist.c:42 plist_check_prev_next+0x2d/0x40 [ 441.057628] Modules linked in: i915(+) vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core e1000e snd_pcm mei_me mei prime_numbers [last unloaded: i915] [ 441.057652] CPU: 4 PID: 9277 Comm: drv_selftest Tainted: G U 4.18.0-rc4-CI-CI_DRM_4464+ #1 [ 441.057653] Hardware name: System manufacturer System Product Name/Z170 PRO GAMING, BIOS 3402 04/26/2017 [ 441.057656] RIP: 0010:plist_check_prev_next+0x2d/0x40 [ 441.057657] Code: 08 48 39 f0 74 2b 49 89 f0 48 8b 4f 08 50 ff 32 52 48 89 fe 41 ff 70 08 48 8b 17 48 c7 c7 d8 ae 14 82 4d 8b 08 e8 63 0e 76 ff <0f> 0b 48 83 c4 20 c3 48 39 10 75 d0 f3 c3 0f 1f 44 00 00 41 54 55 [ 441.057717] RSP: 0018:c93a3a68 EFLAGS: 00010082 [ 441.057720] RAX: RBX: 8802193978c0 RCX: 0002 [ 441.057721] RDX: 8002 RSI: 820c65a4 RDI: [ 441.057722] RBP: 8802193978c0 R08: R09: 0001 [ 441.057724] R10: c93a3a70 R11: R12: 82243de0 [ 441.057725] R13: 82243de0 R14: 88021a6c78c0 R15: 77359400 [ 441.057726] FS: 7fc23a4a9980() GS:880236d0() knlGS: [ 441.057728] CS: 0010 DS: ES: CR0: 80050033 [ 441.057729] CR2: 563e4503d038 CR3: 000138f86005 CR4: 003606e0 [ 441.057730] DR0: DR1: DR2: [ 441.057731] DR3: DR6: fffe0ff0 DR7: 0400 [ 441.057732] Call Trace: [ 441.057736] plist_check_list+0x2e/0x40 [ 441.057738] plist_add+0x23/0x130 [ 441.057743] pm_qos_update_target+0x1bd/0x2f0 [ 441.057771] i915_driver_load+0xec4/0x1060 [i915] [ 441.057775] ? trace_hardirqs_on_caller+0xe0/0x1b0 [ 441.057800] i915_pci_probe+0x29/0x90 [i915] [ 441.057804] pci_device_probe+0xa1/0x130 [ 441.057807] driver_probe_device+0x306/0x480 [ 441.057810] __driver_attach+0xdb/0x100 [ 441.057812] ? driver_probe_device+0x480/0x480 [ 441.057813] ? driver_probe_device+0x480/0x480 [ 441.057816] bus_for_each_dev+0x74/0xc0 [ 441.057819] bus_add_driver+0x15f/0x250 [ 441.057821] ? 0xa0696000 [ 441.057823] driver_register+0x56/0xe0 [ 441.057825] ? 0xa0696000 [ 441.057827] do_one_initcall+0x58/0x370 [ 441.057830] ? do_init_module+0x1d/0x1ea [ 441.057832] ? rcu_read_lock_sched_held+0x6f/0x80 [ 441.057834] ? kmem_cache_alloc_trace+0x282/0x2e0 [ 441.057838] do_init_module+0x56/0x1ea [ 441.057841] load_module+0x2435/0x2b20 [ 441.057852] ? __se_sys_finit_module+0xd3/0xf0 [ 441.057854] __se_sys_finit_module+0xd3/0xf0 [ 441.057861] do_syscall_64+0x55/0x190 [ 441.057863] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 441.057865] RIP: 0033:0x7fc239d75839 [ 441.057866] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48 [ 441.057927] RSP: 002b:7fffb7825d38 EFLAGS: 0246 ORIG_RAX: 0139 [ 441.057930] RAX: ffda RBX: 563e45035dd0 RCX: 7fc239d75839 [ 441.057931] RDX: RSI: 563e4502f8a0 RDI: 0004 [ 441.057932] RBP: 563e4502f8a0 R08: 0004 R09: [ 441.057933] R10: 7fffb7825ea0 R11: 0246 R12: [ 441.057934] R13: 563e4502f690 R14: R15: 003f [ 441.057940] irq event stamp: 231338 [ 441.057943] hardirqs last enabled at (231337): [] _raw_spin_unlock_irqrestore+0x4c/0x60 [ 441.057944] hardirqs last disabled at (231338): [] _raw_spin_lock_irqsave+0xd/0x50 [ 441.057947] softirqs last enabled at (231024): [] __do_softirq+0x34f/0x505 [ 441.057949] softirqs last disabled at (231005): [] irq_exit+0xa9/0xc0 [ 441.057951] WARNING: CPU: 4 PID: 9277 at lib/plist.c:42 plist_check_prev_next+0x2d/0x40 Signed-off-by: Chris Wilson Cc: Matthew Auld Cc: Michał Winiarski --- drivers/gpu/drm/i915/i915_drv.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index e3dfa74d45ad..3eba3d1ab5b8 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1154,8 +1154,6 @@ static int
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/7] Cast void * pointer used in arithmetic to uint32_t*
Quoting Arkadiusz Hiler (2018-07-10 15:38:26) > On Tue, Jul 10, 2018 at 03:09:25PM +0100, Chris Wilson wrote: > > Quoting Arkadiusz Hiler (2018-07-10 14:58:49) > > > On Sat, Jul 07, 2018 at 08:22:38PM -0300, Rodrigo Siqueira wrote: > > > > This commit fixes the GCC warning: > > > > > > > > warning: pointer of type ‘void *’ used in arithmetic [-Wpointer-arith] > > > > memset(ptr + offsets[0], full_range ? 0x00 : 0x10, > > > > ^ > > > > warning: pointer of type ‘void *’ used in arithmetic [-Wpointer-arith] > > > > memset(ptr + offsets[1], 0x80, > > > > > > > > This commit cast the ptr pointer, which is a void *, to uint32_t * in > > > > the pointer arithmetic operation. > > > > > > This will change semantics, as according to GNU C standard[1], void > > > pointers have a size of 1 for all arithmetical purposes. > > > > > > So you should be using uint8_t (or char) pointer instead. > > > > Please just fix the compiler flags, we want close compatibility with the > > kernel coding standards which explicitly allow void arithmetic for the > > simplicity it lends to writing code. > > -Chris > > Fair point. > > We don't rise the error with meson, so it is not a change in the gcc > defaults. Somehow autotools manage to end up adding -Wpointer-arith to > BASE_CFLAGS. iirc, it's pulled in from xorg-macros. Maybe just tack a -Wnopointer-arith onto the end, or sed away. -Chris ___ 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: Unwind HW init after GVT setup failure
== Series Details == Series: drm/i915: Unwind HW init after GVT setup failure URL : https://patchwork.freedesktop.org/series/46263/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4464 -> Patchwork_9604 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/46263/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9604 that come from known issues: === IGT changes === Issues hit igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@gem_exec_suspend@basic-s3: fi-snb-2520m: FAIL (fdo#106825) -> PASS fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#106825 https://bugs.freedesktop.org/show_bug.cgi?id=106825 == Participating hosts (47 -> 42) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4464 -> Patchwork_9604 CI_DRM_4464: a780443701a33d312793c7f388d4e4fc33711b9c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4545: c3035d8cb11459f186f712d9c7ebb6734fc99831 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9604: 6dca4d696a363b230691772d04a6ce93e09640ec @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6dca4d696a36 drm/i915: Unwind HW init after GVT setup failure == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9604/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Flush the residual parking on emergency shutdown
== Series Details == Series: series starting with [1/2] drm/i915: Flush the residual parking on emergency shutdown URL : https://patchwork.freedesktop.org/series/46251/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4461_full -> Patchwork_9602_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9602_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9602_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_9602_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP igt@gem_exec_schedule@deep-vebox: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9602_full that come from known issues: === IGT changes === Issues hit igt@gem_ppgtt@blt-vs-render-ctx0: shard-kbl: PASS -> INCOMPLETE (fdo#106023, fdo#103665) igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: PASS -> FAIL (fdo#105703) igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#106509) igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: PASS -> FAIL (fdo#107161) +1 igt@kms_flip_tiling@flip-y-tiled: shard-glk: PASS -> FAIL (fdo#107161, fdo#103822) Possible fixes igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: FAIL (fdo#105454, fdo#106509) -> PASS igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#105189) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS Warnings igt@kms_sysfs_edid_timing: shard-hsw: WARN (fdo#100047) -> FAIL (fdo#100047) fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#107161 https://bugs.freedesktop.org/show_bug.cgi?id=107161 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4461 -> Patchwork_9602 CI_DRM_4461: 078a032f90cfd680ca2efe07b77ca86cc2ba2a87 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4544: 764160f214cd916ddb79408b9f28ac0ad2df40e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9602: 208ab527743feb29b7e5c5127d019c85e2e22eb6 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9602/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Unwind HW init after GVT setup failure (rev2)
== Series Details == Series: drm/i915: Unwind HW init after GVT setup failure (rev2) URL : https://patchwork.freedesktop.org/series/46263/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4464 -> Patchwork_9605 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9605 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9605, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/46263/revisions/2/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9605: === IGT changes === Possible regressions igt@gem_exec_suspend@basic-s4-devices: fi-snb-2600:PASS -> INCOMPLETE == Known issues == Here are the changes found in Patchwork_9605 that come from known issues: === IGT changes === Issues hit igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#102614, fdo#106103) Possible fixes igt@gem_exec_suspend@basic-s3: fi-snb-2520m: FAIL (fdo#106825) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 fdo#106825 https://bugs.freedesktop.org/show_bug.cgi?id=106825 == Participating hosts (47 -> 42) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4464 -> Patchwork_9605 CI_DRM_4464: a780443701a33d312793c7f388d4e4fc33711b9c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4545: c3035d8cb11459f186f712d9c7ebb6734fc99831 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9605: 49ecec9f0ea055f41c3296e84e108a53fdc1303a @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 49ecec9f0ea0 drm/i915: Unwind HW init after GVT setup failure == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9605/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] benchmarks/wsim: Simulate and interpret .wsim
On 10/07/2018 16:40, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-07-10 16:38:14) On 10/07/2018 14:47, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-11 09:31:52) On 11/05/2018 08:11, Chris Wilson wrote: A little tool I've been meaning to write for a while... Convert the .wsim into their dag and find the longest chains and evaluate them on an simulated machine. Very cool! Would you care to ack it in its current form, knowing that we will fix it whenever we find a corner case interesting enough to study? I think just a little bit more polish is needed. I've just tried it out and polish I can see is: 1. -h / --help with just a brief comment on what the tool does and usage. 2. Lead stats displayed for each cmdline argument with parsed filename. 3. Replace result section names "Single client", "Simulated clients" and item names "total/ideal/packed" with a more descriptive text which would hopefully be somewhat self-explanatory what the numbers represent. 4. Report garbage input (and unknown wsim commands) instead of reporting some numbers for instance for ./sim_wsim README :) 5. #ifdef 0 graphviz ? add --graphviz cmddline option? 6. Oh.. and meson makefiles.. :) But if it was upstream, you would just contribute those improvements yourself. So you are saying that this is just not useful? No, just that I think we have to have some minimum standard before we can make it upstream. If you want I can implement these bits and send a v3. Then it will just be a matter of finding a third person to review it since we will both be authors. :) Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT
Matt, is the new revision already submitted to the M-L?
Manasi
On Tue, Jun 26, 2018 at 07:54:19AM -0700, Atwood, Matthew S wrote:
> ill uprev by EOD
>
> From: Navare, Manasi D
> Sent: Monday, June 25, 2018 5:39 PM
> To: Atwood, Matthew S
> Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo; ble...@chromium.org;
> Zanoni, Paulo R
> Subject: Re: [Intel-gfx] [PATCH] drm/dp: implement
> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT
>
> What is the status of this patch?
> I am hitting this issue with one of the DP 1.4 sinks where the correct
> values of DPCD are present at this new offset of 0x2200 else I see
> bad values for REV and Max_link_rate etc..
> So we absolutely need this for DP 1.4 sinks.
>
> Manasi
>
> On Wed, May 16, 2018 at 09:33:42AM -0700, matthew.s.atw...@intel.com wrote:
> > From: Matt Atwood
> >
> > According to DP spec (2.9.3.1 of DP 1.4) if
> > EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
> > 02200h through 0220Fh shall contain the DPRX's true capability. These
> > values will match 0h through Fh, except for DPCD_REV,
> > MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.
> >
> > Read from DPCD once for all 3 values as this is an expensive operation.
> > Spec mentions that all of address space 02200h through 0220Fh should
> > contain the right information however currently only 3 values can
> > differ.
> >
> > There is no address space in the intel_dp->dpcd struct for addresses
> > 02200h through 0220Fh, and since so much of the data is a identical,
> > simply overwrite the values stored in 0h through Fh with the
> > values that can be overwritten from addresses 02200h through 0220Fh
> >
> > Signed-off-by: Matt Atwood
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 14 ++
> > include/drm/drm_dp_helper.h | 5 +++--
> > 2 files changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index dde92e4af5d3..899ebc5cece6 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3738,6 +3738,20 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
> >sizeof(intel_dp->dpcd)) < 0)
> > return false; /* aux transfer failed */
> >
> > + if (intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT &&
> > + intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14) {
> > + uint8_t dpcd_ext[16];
> > +
> > + if (drm_dp_dpcd_read(_dp->aux, DP_DP13_DPCD_REV,
> > + _ext, sizeof(dpcd_ext)) < 0)
> > + return false; /* aux transfer failed */
> > +
> > + intel_dp->dpcd[DP_DPCD_REV] = dpcd_ext[DP_DPCD_REV];
> > + intel_dp->dpcd[DP_MAX_LINK_RATE] = dpcd_ext[DP_MAX_LINK_RATE];
> > + intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] =
> > + dpcd_ext[DP_DOWNSTREAMPORT_PRESENT];
> > + }
> > DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd),
> > intel_dp->dpcd);
> >
> > return intel_dp->dpcd[DP_DPCD_REV] != 0;
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index c01564991a9f..757bd5913f3d 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -123,8 +123,9 @@
> > # define DP_FRAMING_CHANGE_CAP (1 << 1)
> > # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or
> > higher */
> >
> > -#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */
> > -# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */
> > +#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */
> > +# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */
> > +# define DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT (1 << 7)/* XXX 1.2? */
> >
> > #define DP_ADAPTER_CAP 0x00f /* 1.2 */
> > # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
> > --
> > 2.17.0
> >
> > ___
> > 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] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote: > On Tue 10-07-18 16:40:40, Leon Romanovsky wrote: > > On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote: > > > On Wed 27-06-18 09:44:21, Michal Hocko wrote: > > > > This is the v2 of RFC based on the feedback I've received so far. The > > > > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly > > > > because I have no idea how. > > > > > > > > Any further feedback is highly appreciated of course. > > > > > > Any other feedback before I post this as non-RFC? > > > > From mlx5 perspective, who is primary user of umem_odp.c your change looks > > ok. > > Can I assume your Acked-by? I didn't have a chance to test it because it applies on our rdma-next, but fails to compile. Thanks > > Thanks for your review! > -- > Michal Hocko > SUSE Labs > signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Add IOCTL Param to control data port coherency.
On 2018-07-09 18:37, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-07-09 17:28:02)
On 09/07/2018 14:20, Tomasz Lis wrote:
+static int i915_gem_context_clear_data_port_coherent(struct i915_gem_context
*ctx)
+{
+ int ret;
+
+ ret = intel_lr_context_modify_data_port_coherency(ctx, false);
+ if (!ret)
+ __clear_bit(CONTEXT_DATA_PORT_COHERENT, >flags);
+ return ret;
Is there a good reason you allow userspace to keep emitting unlimited
number of commands which actually do not change the status? If not
please consider gating the command emission with
test_and_set_bit/test_and_clear_bit. Hm.. apart even with that they
could keep toggling ad infinitum with no real work in between. Has it
been considered to only save the desired state in set param and then
emit it, if needed, before next execbuf? Minor thing in any case, just
curious since I wasn't following the threads.
The first patch tried to add a bit to execbuf, and having been
mistakenly down that road before, we asked if there was any alternative.
(Now if you've also been following execbuf3 conversations, having a
packet for privileged LRI is definitely something we want.)
Setting the value in the context register is precisely what we want to
do, and trivially serialised with execbuf since we have to serialise
reservation of ring space, i.e. the normal rules of request generation.
(execbuf is just a client and nothing special). From that point of view,
we only care about frequency, if it is very frequent it should be
controlled by userspace inside the batch (but it can't due to there
being dangerous bits inside the reg aiui). At the other end of the
scale, is context_setparam for set-once. And there should be no
inbetween as that requires costly batch flushes.
-Chris
Joonas did brought that concern in his review; here it is, with my response:
On 2018-06-21 15:47, Lis, Tomasz wrote:
On 2018-06-21 08:39, Joonas Lahtinen wrote:
I'm thinking we should set this value when it has changed, when we
insert the
requests into the command stream. So if you change back and forth, while
not emitting any requests, nothing really happens. If you change the
value and
emit a request, we should emit a LRI before the jump to the commands.
Similary if you keep setting the value to the value it already was in,
nothing will happen, again.
When I considered that, my way of reasoning was:
If we execute the flag changing buffer right away, it may be sent to
hardware faster if there is no job in progress.
If we use the lazy way, and trigger the change just before submission
- there will be additional conditions in submission code, plus the
change will be made when there is another job pending (though it's not
a considerable payload to just switch a flag).
If user space switches the flag back and forth without much sense,
then there is something wrong with the user space driver, and it
shouldn't be up to kernel to fix that.
This is why I chosen the current approach. But I can change it if you
wish.
So while I think the current solution is better from performance
standpoint, but I will change it if you request that.
-Tomasz
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/11] drm/i915: Stop tracking MRU activity on VMA
On 10/07/2018 13:37, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-07-10 13:19:51)
On 09/07/2018 14:02, Chris Wilson wrote:
Our goal is to remove struct_mutex and replace it with fine grained
locking. One of the thorny issues is our eviction logic for reclaiming
space for an execbuffer (or GTT mmaping, among a few other examples).
While eviction itself is easy to move under a per-VM mutex, performing
the activity tracking is less agreeable. One solution is not to do any
MRU tracking and do a simple coarse evaluation during eviction of
active/inactive, with a loose temporal ordering of last
insertion/evaluation. That keeps all the locking constrained to when we
are manipulating the VM itself, neatly avoiding the tricky handling of
possible recursive locking during execbuf and elsewhere.
Note that discarding the MRU is unlikely to impact upon our efficiency
to reclaim VM space (where we think a LRU model is best) as our
current strategy is to use random idle replacement first before doing
a search, and over time the use of softpinned 48b per-ppGTT is growing
(thereby eliminating any need to perform any eviction searches, in
theory at least).
It's a big change to eviction logic but also mostly affects GGTT which
is diminishing in significance. But we still probably need some real
world mmap_gtt users to benchmark and general 3d pre-ppgtt.
mmap_gtt is not really significant here as we use random replacement
almost exclusively for them.
You mean ggtt mmaps can be kicked out by someone doing random
replacement, but mmap_gtt faults cannot necessarily kick out other ggtt
vmas using random replacement. In which case today it falls back to LRU
so I think there is still something to verify if we want to be 100% nice.
Challenge is knowing such workloads. From memory transcode jobs used to
be quite heavy in this respect when there are many many contexts and
each uses some large mmap_gtt. I know the message was move away from
mmap_gtt, and I don't know if that has been done yet, but maybe there
are other similar ones.
Or also GVT with it's reduced aperture space will run eviction more in
its more constrained ggtt space. So anything running under there could
show the effect as amplified.
Any workload that relies on thrashing is a lost cause more or less; we
can not implement an optimal eviction strategy (no fore knowledge) and
even MRU is suggested by some of the literature as not being a good
strategy for graphics (the evidence in games are that the MRU reused
surfaces in a frame are typically use-once whereas the older surfaces
are typically used at the start of each frame; it is those use once
surfaces that then distort the MRU into making a bad prediction).
Fwiw, you will never get a demo with a >GTT working set that isn't a
slideshow, simply because we don't have the memory bw :-p
(Those machines have ~6GB/s main memory bw, a few fold higher while
in the LLC cache, but not enough to sustain ~180GB/s for the example,
even ignoring all the other ratelimiting steps.)
I agree with that.
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 02b83a5ed96c..6a3608398d2a 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -127,14 +127,10 @@ i915_gem_evict_something(struct i915_address_space *vm,
struct drm_i915_private *dev_priv = vm->i915;
struct drm_mm_scan scan;
struct list_head eviction_list;
- struct list_head *phases[] = {
- >inactive_list,
- >active_list,
- NULL,
- }, **phase;
struct i915_vma *vma, *next;
struct drm_mm_node *node;
enum drm_mm_insert_mode mode;
+ struct i915_vma *active;
int ret;
lockdep_assert_held(>i915->drm.struct_mutex);
@@ -170,17 +166,31 @@ i915_gem_evict_something(struct i915_address_space *vm,
*/
if (!(flags & PIN_NONBLOCK))
i915_retire_requests(dev_priv);
- else
- phases[1] = NULL;
There are comments around here referring to active/inactive lists which
will need updating/removing.
search_again:
+ active = NULL;
INIT_LIST_HEAD(_list);
- phase = phases;
- do {
- list_for_each_entry(vma, *phase, vm_link)
- if (mark_free(, vma, flags, _list))
- goto found;
- } while (*++phase);
+ list_for_each_entry_safe(vma, next, >bound_list, vm_link) {
+ if (i915_vma_is_active(vma)) {
+ if (vma == active) {
+ if (flags & PIN_NONBLOCK)
+ break;
+
+ active = ERR_PTR(-EAGAIN);
+ }
+
+ if (active != ERR_PTR(-EAGAIN)) {
+ if (!active)
+ active = vma;
+
+ list_move_tail(>vm_link, >bound_list);
+
Re: [Intel-gfx] [PATCH v2] drm/i915: Unwind HW init after GVT setup failure
On Tue, Jul 10, 2018 at 03:38:21PM +0100, Chris Wilson wrote: > Following intel_gvt_init() failure, we missed unwinding our setup > leaving pointers dangling past the module unload. For our example, the > pm_qos: > > [ 441.057615] top: 6b3baf1c, n: 54d8ef33, p: 97cdf1a2 >prev: 54d8ef33, n: 97cdf1a2, p: > 6b3baf1c >next: 97cdf1a2, n: 6de8fc8b, p: > 81087253 > [ 441.057627] WARNING: CPU: 4 PID: 9277 at lib/plist.c:42 > plist_check_prev_next+0x2d/0x40 > [ 441.057628] Modules linked in: i915(+) vgem snd_hda_codec_hdmi > snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal > intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel > snd_hda_codec snd_hwdep snd_hda_core e1000e snd_pcm mei_me mei prime_numbers > [last unloaded: i915] > [ 441.057652] CPU: 4 PID: 9277 Comm: drv_selftest Tainted: G U > 4.18.0-rc4-CI-CI_DRM_4464+ #1 > [ 441.057653] Hardware name: System manufacturer System Product Name/Z170 > PRO GAMING, BIOS 3402 04/26/2017 > [ 441.057656] RIP: 0010:plist_check_prev_next+0x2d/0x40 > [ 441.057657] Code: 08 48 39 f0 74 2b 49 89 f0 48 8b 4f 08 50 ff 32 52 48 89 > fe 41 ff 70 08 48 8b 17 48 c7 c7 d8 ae 14 82 4d 8b 08 e8 63 0e 76 ff <0f> 0b > 48 83 c4 20 c3 48 39 10 75 d0 f3 c3 0f 1f 44 00 00 41 54 55 > [ 441.057717] RSP: 0018:c93a3a68 EFLAGS: 00010082 > [ 441.057720] RAX: RBX: 8802193978c0 RCX: > 0002 > [ 441.057721] RDX: 8002 RSI: 820c65a4 RDI: > > [ 441.057722] RBP: 8802193978c0 R08: R09: > 0001 > [ 441.057724] R10: c93a3a70 R11: R12: > 82243de0 > [ 441.057725] R13: 82243de0 R14: 88021a6c78c0 R15: > 77359400 > [ 441.057726] FS: 7fc23a4a9980() GS:880236d0() > knlGS: > [ 441.057728] CS: 0010 DS: ES: CR0: 80050033 > [ 441.057729] CR2: 563e4503d038 CR3: 000138f86005 CR4: > 003606e0 > [ 441.057730] DR0: DR1: DR2: > > [ 441.057731] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 441.057732] Call Trace: > [ 441.057736] plist_check_list+0x2e/0x40 > [ 441.057738] plist_add+0x23/0x130 > [ 441.057743] pm_qos_update_target+0x1bd/0x2f0 > [ 441.057771] i915_driver_load+0xec4/0x1060 [i915] > [ 441.057775] ? trace_hardirqs_on_caller+0xe0/0x1b0 > [ 441.057800] i915_pci_probe+0x29/0x90 [i915] > [ 441.057804] pci_device_probe+0xa1/0x130 > [ 441.057807] driver_probe_device+0x306/0x480 > [ 441.057810] __driver_attach+0xdb/0x100 > [ 441.057812] ? driver_probe_device+0x480/0x480 > [ 441.057813] ? driver_probe_device+0x480/0x480 > [ 441.057816] bus_for_each_dev+0x74/0xc0 > [ 441.057819] bus_add_driver+0x15f/0x250 > [ 441.057821] ? 0xa0696000 > [ 441.057823] driver_register+0x56/0xe0 > [ 441.057825] ? 0xa0696000 > [ 441.057827] do_one_initcall+0x58/0x370 > [ 441.057830] ? do_init_module+0x1d/0x1ea > [ 441.057832] ? rcu_read_lock_sched_held+0x6f/0x80 > [ 441.057834] ? kmem_cache_alloc_trace+0x282/0x2e0 > [ 441.057838] do_init_module+0x56/0x1ea > [ 441.057841] load_module+0x2435/0x2b20 > [ 441.057852] ? __se_sys_finit_module+0xd3/0xf0 > [ 441.057854] __se_sys_finit_module+0xd3/0xf0 > [ 441.057861] do_syscall_64+0x55/0x190 > [ 441.057863] entry_SYSCALL_64_after_hwframe+0x49/0xbe > [ 441.057865] RIP: 0033:0x7fc239d75839 > [ 441.057866] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 > f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d > 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48 > [ 441.057927] RSP: 002b:7fffb7825d38 EFLAGS: 0246 ORIG_RAX: > 0139 > [ 441.057930] RAX: ffda RBX: 563e45035dd0 RCX: > 7fc239d75839 > [ 441.057931] RDX: RSI: 563e4502f8a0 RDI: > 0004 > [ 441.057932] RBP: 563e4502f8a0 R08: 0004 R09: > > [ 441.057933] R10: 7fffb7825ea0 R11: 0246 R12: > > [ 441.057934] R13: 563e4502f690 R14: R15: > 003f > [ 441.057940] irq event stamp: 231338 > [ 441.057943] hardirqs last enabled at (231337): [] > _raw_spin_unlock_irqrestore+0x4c/0x60 > [ 441.057944] hardirqs last disabled at (231338): [] > _raw_spin_lock_irqsave+0xd/0x50 > [ 441.057947] softirqs last enabled at (231024): [] > __do_softirq+0x34f/0x505 > [ 441.057949] softirqs last disabled at (231005): [] > irq_exit+0xa9/0xc0 > [ 441.057951] WARNING: CPU: 4 PID: 9277 at lib/plist.c:42 > plist_check_prev_next+0x2d/0x40 > > v2: Add a load failure point to intel_gvt_init() so that we always > exercise this path in future. > > Signed-off-by: Chris Wilson > Cc:
[Intel-gfx] ✓ Fi.CI.IGT: success for ICELAKE DSI DRIVER (rev5)
== Series Details == Series: ICELAKE DSI DRIVER (rev5) URL : https://patchwork.freedesktop.org/series/44823/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4462_full -> Patchwork_9603_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9603_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9603_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_9603_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-vebox: shard-kbl: SKIP -> PASS +1 == Known issues == Here are the changes found in Patchwork_9603_full that come from known issues: === IGT changes === Issues hit igt@gem_exec_schedule@pi-ringfull-blt: shard-glk: NOTRUN -> FAIL (fdo#103158) igt@gem_mmap_gtt@coherency: shard-glk: NOTRUN -> FAIL (fdo#100587) igt@gem_ppgtt@blt-vs-render-ctx0: shard-kbl: PASS -> INCOMPLETE (fdo#103665, fdo#106023) igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#105454, fdo#106509) igt@kms_flip@2x-flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#102887) igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: PASS -> FAIL (fdo#107161, fdo#103822) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#107161, fdo#103822) -> PASS fdo#100587 https://bugs.freedesktop.org/show_bug.cgi?id=100587 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#107161 https://bugs.freedesktop.org/show_bug.cgi?id=107161 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4462 -> Patchwork_9603 CI_DRM_4462: d4e71d9d380fd82c93708cc29704a011dc9948ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4544: 764160f214cd916ddb79408b9f28ac0ad2df40e0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9603: e04c020b54297b15e459bc86b3355202107738ea @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9603/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] benchmarks/wsim: Simulate and interpret .wsim
On 10/07/2018 14:47, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-11 09:31:52) On 11/05/2018 08:11, Chris Wilson wrote: A little tool I've been meaning to write for a while... Convert the .wsim into their dag and find the longest chains and evaluate them on an simulated machine. Very cool! Would you care to ack it in its current form, knowing that we will fix it whenever we find a corner case interesting enough to study? I think just a little bit more polish is needed. I've just tried it out and polish I can see is: 1. -h / --help with just a brief comment on what the tool does and usage. 2. Lead stats displayed for each cmdline argument with parsed filename. 3. Replace result section names "Single client", "Simulated clients" and item names "total/ideal/packed" with a more descriptive text which would hopefully be somewhat self-explanatory what the numbers represent. 4. Report garbage input (and unknown wsim commands) instead of reporting some numbers for instance for ./sim_wsim README :) 5. #ifdef 0 graphviz ? add --graphviz cmddline option? 6. Oh.. and meson makefiles.. :) Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Add IOCTL Param to control data port coherency.
On 2018-07-09 18:28, Tvrtko Ursulin wrote: On 09/07/2018 14:20, Tomasz Lis wrote: The patch adds a parameter to control the data port coherency functionality on a per-context level. When the IOCTL is called, a command to switch data port coherency state is added to the ordered list. All prior requests are executed on old coherency settings, and all exec requests after the IOCTL will use new settings. Rationale: The OpenCL driver develpers requested a functionality to control cache coherency at data port level. Keeping the coherency at that level is disabled by default due to its performance costs. OpenCL driver is planning to enable it for a small subset of submissions, when such functionality is required. Below are answers to basic question explaining background of the functionality and reasoning for the proposed implementation: 1. Why do we need a coherency enable/disable switch for memory that is shared between CPU and GEN (GPU)? Memory coherency between CPU and GEN, while being a great feature that enables CL_MEM_SVM_FINE_GRAIN_BUFFER OCL capability on Intel GEN architecture, adds overhead related to tracking (snooping) memory inside different cache units (L1$, L2$, L3$, LLC$, etc.). At the same time, minority of modern OCL applications actually use CL_MEM_SVM_FINE_GRAIN_BUFFER (and hence require memory coherency between CPU and GPU). The goal of coherency enable/disable switch is to remove overhead of memory coherency when memory coherency is not needed. 2. Why do we need a global coherency switch? In order to support I/O commands from within EUs (Execution Units), Intel GEN ISA (GEN Instruction Set Assembly) contains dedicated "send" instructions. These send instructions provide several addressing models. One of these addressing models (named "stateless") provides most flexible I/O using plain virtual addresses (as opposed to buffer_handle+offset models). This "stateless" model is similar to regular memory load/store operations available on typical CPUs. Since this model provides I/O using arbitrary virtual addresses, it enables algorithmic designs that are based on pointer-to-pointer (e.g. buffer of pointers) concepts. For instance, it allows creating tree-like data structures such as: | NODE1 | | uint64_t data | +| | NODE* | NODE*| ++---+ / \ / \ | NODE2 | | NODE3 | | uint64_t data | | uint64_t data | +| +| | NODE* | NODE*| | NODE* | NODE*| ++---+ ++---+ Please note that pointers inside such structures can point to memory locations in different OCL allocations - e.g. NODE1 and NODE2 can reside in one OCL allocation while NODE3 resides in a completely separate OCL allocation. Additionally, such pointers can be shared with CPU (i.e. using SVM - Shared Virtual Memory feature). Using pointers from different allocations doesn't affect the stateless addressing model which even allows scattered reading from different allocations at the same time (i.e. by utilizing SIMD-nature of send instructions). When it comes to coherency programming, send instructions in stateless model can be encoded (at ISA level) to either use or disable coherency. However, for generic OCL applications (such as example with tree-like data structure), OCL compiler is not able to determine origin of memory pointed to by an arbitrary pointer - i.e. is not able to track given pointer back to a specific allocation. As such, it's not able to decide whether coherency is needed or not for specific pointer (or for specific I/O instruction). As a result, compiler encodes all stateless sends as coherent (doing otherwise would lead to functional issues resulting from data corruption). Please note that it would be possible to workaround this (e.g. based on allocations map and pointer bounds checking prior to each I/O instruction) but the performance cost of such workaround would be many times greater than the cost of keeping coherency always enabled. As such, enabling/disabling memory coherency at GEN ISA level is not feasible and alternative method is needed. Such alternative solution is to have a global coherency switch that allows disabling coherency for single (though entire) GPU submission. This is beneficial because this way we: * can enable (and pay for) coherency only in submissions that actually need coherency (submissions that use CL_MEM_SVM_FINE_GRAIN_BUFFER resources) * don't care about coherency at GEN ISA granularity (no performance impact) 3. Will coherency switch be used frequently? There are scenarios that will require frequent toggling
Re: [Intel-gfx] [PATCH i-g-t] benchmarks/wsim: Simulate and interpret .wsim
Quoting Tvrtko Ursulin (2018-07-10 16:38:14) > > On 10/07/2018 14:47, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-05-11 09:31:52) > >> > >> On 11/05/2018 08:11, Chris Wilson wrote: > >>> A little tool I've been meaning to write for a while... Convert the > >>> .wsim into their dag and find the longest chains and evaluate them on an > >>> simulated machine. > >> > >> Very cool! > > > > Would you care to ack it in its current form, knowing that we will fix > > it whenever we find a corner case interesting enough to study? > > I think just a little bit more polish is needed. I've just tried it out > and polish I can see is: > > 1. -h / --help with just a brief comment on what the tool does and usage. > > 2. Lead stats displayed for each cmdline argument with parsed filename. > > 3. Replace result section names "Single client", "Simulated clients" and > item names "total/ideal/packed" with a more descriptive text which would > hopefully be somewhat self-explanatory what the numbers represent. > > 4. Report garbage input (and unknown wsim commands) instead of reporting > some numbers for instance for ./sim_wsim README :) > > 5. #ifdef 0 graphviz ? add --graphviz cmddline option? > > 6. Oh.. and meson makefiles.. :) But if it was upstream, you would just contribute those improvements yourself. So you are saying that this is just not useful? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Unwind HW init after GVT setup failure
Quoting Michał Winiarski (2018-07-10 16:44:05) > On Tue, Jul 10, 2018 at 03:38:21PM +0100, Chris Wilson wrote: > > Following intel_gvt_init() failure, we missed unwinding our setup > > leaving pointers dangling past the module unload. For our example, the > > pm_qos: > > > > [ 441.057615] top: 6b3baf1c, n: 54d8ef33, p: > > 97cdf1a2 > >prev: 54d8ef33, n: 97cdf1a2, p: > > 6b3baf1c > >next: 97cdf1a2, n: 6de8fc8b, p: > > 81087253 > > [ 441.057627] WARNING: CPU: 4 PID: 9277 at lib/plist.c:42 > > plist_check_prev_next+0x2d/0x40 > > [ 441.057628] Modules linked in: i915(+) vgem snd_hda_codec_hdmi > > snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal > > intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel > > snd_hda_codec snd_hwdep snd_hda_core e1000e snd_pcm mei_me mei > > prime_numbers [last unloaded: i915] > > [ 441.057652] CPU: 4 PID: 9277 Comm: drv_selftest Tainted: G U > >4.18.0-rc4-CI-CI_DRM_4464+ #1 > > [ 441.057653] Hardware name: System manufacturer System Product Name/Z170 > > PRO GAMING, BIOS 3402 04/26/2017 > > [ 441.057656] RIP: 0010:plist_check_prev_next+0x2d/0x40 > > [ 441.057657] Code: 08 48 39 f0 74 2b 49 89 f0 48 8b 4f 08 50 ff 32 52 48 > > 89 fe 41 ff 70 08 48 8b 17 48 c7 c7 d8 ae 14 82 4d 8b 08 e8 63 0e 76 ff > > <0f> 0b 48 83 c4 20 c3 48 39 10 75 d0 f3 c3 0f 1f 44 00 00 41 54 55 > > [ 441.057717] RSP: 0018:c93a3a68 EFLAGS: 00010082 > > [ 441.057720] RAX: RBX: 8802193978c0 RCX: > > 0002 > > [ 441.057721] RDX: 8002 RSI: 820c65a4 RDI: > > > > [ 441.057722] RBP: 8802193978c0 R08: R09: > > 0001 > > [ 441.057724] R10: c93a3a70 R11: R12: > > 82243de0 > > [ 441.057725] R13: 82243de0 R14: 88021a6c78c0 R15: > > 77359400 > > [ 441.057726] FS: 7fc23a4a9980() GS:880236d0() > > knlGS: > > [ 441.057728] CS: 0010 DS: ES: CR0: 80050033 > > [ 441.057729] CR2: 563e4503d038 CR3: 000138f86005 CR4: > > 003606e0 > > [ 441.057730] DR0: DR1: DR2: > > > > [ 441.057731] DR3: DR6: fffe0ff0 DR7: > > 0400 > > [ 441.057732] Call Trace: > > [ 441.057736] plist_check_list+0x2e/0x40 > > [ 441.057738] plist_add+0x23/0x130 > > [ 441.057743] pm_qos_update_target+0x1bd/0x2f0 > > [ 441.057771] i915_driver_load+0xec4/0x1060 [i915] > > [ 441.057775] ? trace_hardirqs_on_caller+0xe0/0x1b0 > > [ 441.057800] i915_pci_probe+0x29/0x90 [i915] > > [ 441.057804] pci_device_probe+0xa1/0x130 > > [ 441.057807] driver_probe_device+0x306/0x480 > > [ 441.057810] __driver_attach+0xdb/0x100 > > [ 441.057812] ? driver_probe_device+0x480/0x480 > > [ 441.057813] ? driver_probe_device+0x480/0x480 > > [ 441.057816] bus_for_each_dev+0x74/0xc0 > > [ 441.057819] bus_add_driver+0x15f/0x250 > > [ 441.057821] ? 0xa0696000 > > [ 441.057823] driver_register+0x56/0xe0 > > [ 441.057825] ? 0xa0696000 > > [ 441.057827] do_one_initcall+0x58/0x370 > > [ 441.057830] ? do_init_module+0x1d/0x1ea > > [ 441.057832] ? rcu_read_lock_sched_held+0x6f/0x80 > > [ 441.057834] ? kmem_cache_alloc_trace+0x282/0x2e0 > > [ 441.057838] do_init_module+0x56/0x1ea > > [ 441.057841] load_module+0x2435/0x2b20 > > [ 441.057852] ? __se_sys_finit_module+0xd3/0xf0 > > [ 441.057854] __se_sys_finit_module+0xd3/0xf0 > > [ 441.057861] do_syscall_64+0x55/0x190 > > [ 441.057863] entry_SYSCALL_64_after_hwframe+0x49/0xbe > > [ 441.057865] RIP: 0033:0x7fc239d75839 > > [ 441.057866] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 > > 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 > > <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48 > > [ 441.057927] RSP: 002b:7fffb7825d38 EFLAGS: 0246 ORIG_RAX: > > 0139 > > [ 441.057930] RAX: ffda RBX: 563e45035dd0 RCX: > > 7fc239d75839 > > [ 441.057931] RDX: RSI: 563e4502f8a0 RDI: > > 0004 > > [ 441.057932] RBP: 563e4502f8a0 R08: 0004 R09: > > > > [ 441.057933] R10: 7fffb7825ea0 R11: 0246 R12: > > > > [ 441.057934] R13: 563e4502f690 R14: R15: > > 003f > > [ 441.057940] irq event stamp: 231338 > > [ 441.057943] hardirqs last enabled at (231337): [] > > _raw_spin_unlock_irqrestore+0x4c/0x60 > > [ 441.057944] hardirqs last disabled at (231338): [] > > _raw_spin_lock_irqsave+0xd/0x50 > > [ 441.057947] softirqs last enabled at (231024): [] > > __do_softirq+0x34f/0x505 > > [ 441.057949] softirqs last disabled at (231005): [] > >
Re: [Intel-gfx] [PATCH 1/2] drm/i915/icl: move has_resource_streamer to GEN11_FEATURES
On 09/07/18 17:06, Lucas De Marchi wrote:
Resource streamer has been removed on GEN11 so move it to the FEATURES
macro.
Signed-off-by: Lucas De Marchi
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/i915_pci.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 3f0c612d42e7..1932bc227942 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2223,7 +2223,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (args->flags & I915_EXEC_RESOURCE_STREAMER) {
if (!HAS_RESOURCE_STREAMER(eb.i915)) {
- DRM_DEBUG("RS is only allowed for Haswell, Gen8 and
above\n");
+ DRM_DEBUG("RS is only allowed for Haswell and Gen8 -
Gen10\n");
return -EINVAL;
}
if (eb.engine->id != RCS) {
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 55543f1b0236..c03ba0fe0845 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -593,13 +593,13 @@ static const struct intel_device_info
intel_cannonlake_info = {
GEN(11), \
.ddb_size = 2048, \
.has_csr = 0, \
+ .has_resource_streamer = 0, \
.has_logical_ring_elsq = 1
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
PLATFORM(INTEL_ICELAKE),
.is_alpha_support = 1,
- .has_resource_streamer = 0,
.ring_mask = RENDER_RING | BLT_RING | VEBOX_RING | BSD_RING | BSD3_RING,
};
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Look for an active kernel context before switching
On Thu, May 24, 2018 at 03:51:23PM +0100, Chris Wilson wrote:
> Quoting Mika Kuoppala (2018-05-24 15:40:47)
> > Chris Wilson writes:
> >
> > > We were not very carefully checking to see if an older request on the
> > > engine was an earlier switch-to-kernel-context before deciding to emit a
> > > new switch. The end result would be that we could get into a permanent
> > > loop of trying to emit a new request to perform the switch simply to
> > > flush the existing switch.
> > >
> > > What we need is a means of tracking the completion of each timeline
> > > versus the kernel context, that is to detect if a more recent request
> > > has been submitted that would result in a switch away from the kernel
> > > context. To realise this, we need only to look in our syncmap on the
> > > kernel context and check that we have synchronized against all active
> > > rings.
> > >
> > > v2: Since all ringbuffer clients currently share the same timeline, we do
> > > have to use the gem_context to distinguish clients.
> > >
> > > As a bonus, include all the tracing used to debug the death inside
> > > suspend.
> > >
> > > v3: Test, test, test. Construct a selftest to exercise and assert the
> > > expected behaviour that multiple switch-to-contexts do not emit
> > > redundant requests.
> > >
> > > Reported-by: Mika Kuoppala
> > > Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual
> > > timelines")
> > > Signed-off-by: Chris Wilson
> > > Cc: Mika Kuoppala
> > > ---
> > > drivers/gpu/drm/i915/i915_gem.c | 7 +
> > > drivers/gpu/drm/i915/i915_gem.h | 3 +
> > > drivers/gpu/drm/i915/i915_gem_context.c | 86 +--
> > > drivers/gpu/drm/i915/i915_request.c | 5 +-
> > > .../gpu/drm/i915/selftests/i915_gem_context.c | 144 ++
> > > .../drm/i915/selftests/i915_mock_selftests.h | 1 +
> > > 6 files changed, 231 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index 03874b50ada9..05f44ca35a06 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -3703,6 +3703,9 @@ static int wait_for_engines(struct drm_i915_private
> > > *i915)
> > >
> > > int i915_gem_wait_for_idle(struct drm_i915_private *i915, unsigned int
> > > flags)
> > > {
> > > + GEM_TRACE("flags=%x (%s)\n",
> > > + flags, flags & I915_WAIT_LOCKED ? "locked" : "unlocked");
> > > +
> > > /* If the device is asleep, we have no requests outstanding */
> > > if (!READ_ONCE(i915->gt.awake))
> > > return 0;
> > > @@ -3719,6 +3722,7 @@ int i915_gem_wait_for_idle(struct drm_i915_private
> > > *i915, unsigned int flags)
> > > return err;
> > > }
> > > i915_retire_requests(i915);
> > > + GEM_BUG_ON(i915->gt.active_requests);
> > >
> > > return wait_for_engines(i915);
> > > } else {
> > > @@ -4901,6 +4905,7 @@ static void assert_kernel_context_is_current(struct
> > > drm_i915_private *i915)
> > > struct intel_engine_cs *engine;
> > > enum intel_engine_id id;
> > >
> > > + GEM_BUG_ON(i915->gt.active_requests);
> > > for_each_engine(engine, i915, id) {
> > >
> > > GEM_BUG_ON(__i915_gem_active_peek(>timeline.last_request));
> > > GEM_BUG_ON(engine->last_retired_context->gem_context !=
> > > kctx);
> > > @@ -4932,6 +4937,8 @@ int i915_gem_suspend(struct drm_i915_private
> > > *dev_priv)
> > > struct drm_device *dev = _priv->drm;
> > > int ret;
> > >
> > > + GEM_TRACE("\n");
> > > +
> > > intel_runtime_pm_get(dev_priv);
> > > intel_suspend_gt_powersave(dev_priv);
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.h
> > > b/drivers/gpu/drm/i915/i915_gem.h
> > > index 5bf24cfc218c..62ee4e385365 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.h
> > > +++ b/drivers/gpu/drm/i915/i915_gem.h
> > > @@ -63,9 +63,12 @@ struct drm_i915_private;
> > > #if IS_ENABLED(CONFIG_DRM_I915_TRACE_GEM)
> > > #define GEM_TRACE(...) trace_printk(__VA_ARGS__)
> > > #define GEM_TRACE_DUMP() ftrace_dump(DUMP_ALL)
> > > +#define GEM_TRACE_DUMP_ON(expr) \
> > > + do { if (expr) ftrace_dump(DUMP_ALL); } while (0)
> > > #else
> > > #define GEM_TRACE(...) do { } while (0)
> > > #define GEM_TRACE_DUMP() do { } while (0)
> > > +#define GEM_TRACE_DUMP_ON(expr) BUILD_BUG_ON_INVALID(expr)
> > > #endif
> > >
> > > #define I915_NUM_ENGINES 8
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > > b/drivers/gpu/drm/i915/i915_gem_context.c
> > > index b69b18ef8120..45393f6e0208 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > > @@ -576,30 +576,72 @@ last_request_on_engine(struct i915_timeline
> > > *timeline,
> > > {
> > > struct i915_request *rq;
> > >
> > > -
[Intel-gfx] [PATCH v5] drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.
From: Clint Taylor
On GLK NUC platforms the HDMI retiming buffer needs additional disabled
time to correctly sync to a faster incoming signal.
When measured on a scope the highspeed lines of the HDMI clock turn off
for ~400uS during a normal resolution change. The HDMI retimer on the
GLK NUC appears to require at least a full frame of quiet time before a
new faster clock can be correctly sync'd. Wait 100ms due to msleep
inaccuracies while waiting for a completed frame. Add a quirk to the
driver for GLK boards that use ITE66317 HDMI retimers.
V2: Add more devices to the quirk list
V3: Delay increased to 100ms, check to confirm crtc type is HDMI.
V4: crtc type check extended to include _DDI and whitespace fixes
v5: Fix white spaces, remove the macro for delay. Revert the crtc type
check introduced in v4.
Cc: Imre Deak
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105887
Signed-off-by: Clint Taylor
Tested-by: Daniel Scheller
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 13 +++--
drivers/gpu/drm/i915/intel_display.c | 20 +++-
drivers/gpu/drm/i915/intel_drv.h | 3 +--
4 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eeb002a47032..2b859cbdc1ac 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -650,6 +650,7 @@ enum intel_sbi_destination {
#define QUIRK_BACKLIGHT_PRESENT (1<<3)
#define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
#define QUIRK_INCREASE_T12_DELAY (1<<6)
+#define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
struct intel_fbdev;
struct intel_fbc_work;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 32838ed89ee7..e4caa902d88e 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1808,15 +1808,24 @@ void intel_ddi_enable_transcoder_func(const struct
intel_crtc_state *crtc_state)
I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
}
-void intel_ddi_disable_transcoder_func(struct drm_i915_private *dev_priv,
- enum transcoder cpu_transcoder)
+void intel_ddi_disable_transcoder_func(const struct intel_crtc_state
*crtc_state)
{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
i915_reg_t reg = TRANS_DDI_FUNC_CTL(cpu_transcoder);
uint32_t val = I915_READ(reg);
val &= ~(TRANS_DDI_FUNC_ENABLE | TRANS_DDI_PORT_MASK |
TRANS_DDI_DP_VC_PAYLOAD_ALLOC);
val |= TRANS_DDI_PORT_NONE;
I915_WRITE(reg, val);
+
+ if (dev_priv->quirks & QUIRK_INCREASE_DDI_DISABLED_TIME &&
+ intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
+ DRM_DEBUG_KMS("Quirk Increase DDI disabled time\n");
+ /* Quirk time at 100ms for reliable operation */
+ msleep(100);
+ }
}
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7998e70a3174..e14d2e9fb673 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5837,7 +5837,7 @@ static void haswell_crtc_disable(struct intel_crtc_state
*old_crtc_state,
intel_ddi_set_vc_payload_alloc(old_crtc_state, false);
if (!transcoder_is_dsi(cpu_transcoder))
- intel_ddi_disable_transcoder_func(dev_priv, cpu_transcoder);
+ intel_ddi_disable_transcoder_func(old_crtc_state);
if (INTEL_GEN(dev_priv) >= 9)
skylake_scaler_disable(intel_crtc);
@@ -14849,6 +14849,17 @@ static void quirk_increase_t12_delay(struct drm_device
*dev)
DRM_INFO("Applying T12 delay quirk\n");
}
+/* GeminiLake NUC HDMI outputs require additional off time
+ * this allows the onboard retimer to correctly sync to signal
+ */
+static void quirk_increase_ddi_disabled_time(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ dev_priv->quirks |= QUIRK_INCREASE_DDI_DISABLED_TIME;
+ DRM_INFO("Applying Increase DDI Disabled quirk\n");
+}
+
struct intel_quirk {
int device;
int subsystem_vendor;
@@ -14935,6 +14946,13 @@ static struct intel_quirk intel_quirks[] = {
/* Toshiba Satellite P50-C-18C */
{ 0x191B, 0x1179, 0xF840, quirk_increase_t12_delay },
+
+ /* GeminiLake NUC */
+ { 0x3185, 0x8086, 0x2072, quirk_increase_ddi_disabled_time },
+ { 0x3184, 0x8086, 0x2072, quirk_increase_ddi_disabled_time },
+ /* ASRock ITX*/
+ { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
+ { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
};
static void
Re: [Intel-gfx] [PATCH] drm/i915: Look for an active kernel context before switching
Quoting Rodrigo Vivi (2018-07-10 20:59:26) > Hi Chris, this failed the cherry-pick for drm-intel-fixes, but looking > to the log it seems something we want there right?! It didn't become crucial until a later patch: commit 4dfacb0bcbee79fa2ef4b2e9e64a8f8a28598934 Author: Chris Wilson Date: Thu May 31 09:22:43 2018 +0100 drm/i915: Switch to kernel context before idling at runtime Before that patch we just occasionally emitted one more request that we strictly required (bumping suspend times by a few microseconds). With that patch, we would hit an infinite loop unless we applied the fix. So while it did fix a recent bug, impact is minimal. -Chris ___ 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/glk: Add Quirk for GLK NUC HDMI port issues. (rev5)
== Series Details ==
Series: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev5)
URL : https://patchwork.freedesktop.org/series/6/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4467 -> Patchwork_9606 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/6/revisions/5/mbox/
== Known issues ==
Here are the changes found in Patchwork_9606 that come from known issues:
=== IGT changes ===
Warnings
igt@gem_exec_suspend@basic-s4-devices:
{fi-kbl-8809g}: DMESG-WARN (fdo#107139) -> INCOMPLETE (fdo#107139)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139
== Participating hosts (47 -> 41) ==
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600
== Build changes ==
* Linux: CI_DRM_4467 -> Patchwork_9606
CI_DRM_4467: d43ac253ef86f6c89e4e69130baa2c5021a95696 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4546: e8905e756cf3640c66541e963ff97f8af2d98936 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9606: 068faa878cfc4d3d66bd22cd8bb3af4f7b6e96ba @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
068faa878cfc drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9606/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Look for an active kernel context before switching
On Tue, Jul 10, 2018 at 09:09:07PM +0100, Chris Wilson wrote: > Quoting Rodrigo Vivi (2018-07-10 20:59:26) > > Hi Chris, this failed the cherry-pick for drm-intel-fixes, but looking > > to the log it seems something we want there right?! > > It didn't become crucial until a later patch: > > commit 4dfacb0bcbee79fa2ef4b2e9e64a8f8a28598934 > Author: Chris Wilson > Date: Thu May 31 09:22:43 2018 +0100 > > drm/i915: Switch to kernel context before idling at runtime > > Before that patch we just occasionally emitted one more request that we > strictly required (bumping suspend times by a few microseconds). With > that patch, we would hit an infinite loop unless we applied the fix. > > So while it did fix a recent bug, impact is minimal. Cool then. Thanks for the explanation. > -Chris > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-next for 4.19
Hi Dave,
This is probably the last big pull targeting 4.19.
I will probably send another small one by the end of this week and
if possible another smaller one by next one.
Here goes drm-intel-next-2018-07-09:
Higlights here goes to many PSR fixes and improvements; to the Ice lake work
with
power well support and begin of DSI support addition. Also there were many
improvements
on execlists and interrupts for minimal latency on command submission; and many
fixes
on selftests, mostly caught by our CI.
General driver:
- Clean-up on aux irq (Lucas)
- Mark expected switch fall-through for dealing with static analysis tools
(Gustavo)
Gem:
- Different fixes for GuC (Chris, Anusha, Michal)
- Avoid self-relocation BIAS if no relocation (Chris)
- Improve debugging cases in on EINVAL return and vma allocation (Chris)
- Fixes and improvements on context destroying and freeing (Chris)
- Wait for engines to idle before retiring (Chris)
- Many improvements on execlists and interrupts for minimal latency on command
submission (Chris)
- Many fixes in selftests, specially on cases highlighted on CI (Chris)
- Other fixes and improvements around GGTT (Chris)
- Prevent background reaping of active objects (Chris)
Display:
- Parallel modeset cleanup to fix driver reset (Chris)
- Get AUX power domain for DP main link (Imre)
- Clean-up on PSR unused func pointers (Rodrigo)
- Many PSR/PSR2 fixes and improvements (DK, Jose, Tarun)
- Add a PSR1 live status (Vathsala)
- Replace old drm_*_{un/reference} with put,get functions (Thomas)
- FBC fixes (Maarten)
- Abstract and document the usage of picking macros (Jani)
- Remove unnecessary check for unsupported modifiers for NV12. (DK)
- Interrupt fixes for display (Ville)
- Clean up on sdvo code (Ville)
- Clean up on current DSI code (Jani)
- Remove support for legacy debugfs crc interface (Maarten)
- Simplify get_encoder_power_domains (Imre)
Icelake:
- MG PLL fixes (Imre)
- Add hw workaround for alpha blending (Vandita)
- Add power well support (Imre)
- Add Interrupt Support (Anusha)
- Start to add support for DSI on Ice Lake (Madhav)
Thanks,
Rodrigo.
The following changes since commit e1cacec9d50d7299893eeab2d895189f3db625da:
drm/i915: Update DRIVER_DATE to 20180620 (2018-06-20 14:10:48 -0700)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2018-07-09
for you to fetch changes up to 82edc7e8b8c06151bdc653935bc13b83e2f0fcfa:
drm/i915: Update DRIVER_DATE to 20180709 (2018-07-09 15:39:27 -0700)
Higlights here goes to many PSR fixes and improvements; to the Ice lake work
with
power well support and begin of DSI support addition. Also there were many
improvements
on execlists and interrupts for minimal latency on command submission; and many
fixes
on selftests, mostly caught by our CI.
General driver:
- Clean-up on aux irq (Lucas)
- Mark expected switch fall-through for dealing with static analysis tools
(Gustavo)
Gem:
- Different fixes for GuC (Chris, Anusha, Michal)
- Avoid self-relocation BIAS if no relocation (Chris)
- Improve debugging cases in on EINVAL return and vma allocation (Chris)
- Fixes and improvements on context destroying and freeing (Chris)
- Wait for engines to idle before retiring (Chris)
- Many improvements on execlists and interrupts for minimal latency on command
submission (Chris)
- Many fixes in selftests, specially on cases highlighted on CI (Chris)
- Other fixes and improvements around GGTT (Chris)
- Prevent background reaping of active objects (Chris)
Display:
- Parallel modeset cleanup to fix driver reset (Chris)
- Get AUX power domain for DP main link (Imre)
- Clean-up on PSR unused func pointers (Rodrigo)
- Many PSR/PSR2 fixes and improvements (DK, Jose, Tarun)
- Add a PSR1 live status (Vathsala)
- Replace old drm_*_{un/reference} with put,get functions (Thomas)
- FBC fixes (Maarten)
- Abstract and document the usage of picking macros (Jani)
- Remove unnecessary check for unsupported modifiers for NV12. (DK)
- Interrupt fixes for display (Ville)
- Clean up on sdvo code (Ville)
- Clean up on current DSI code (Jani)
- Remove support for legacy debugfs crc interface (Maarten)
- Simplify get_encoder_power_domains (Imre)
Icelake:
- MG PLL fixes (Imre)
- Add hw workaround for alpha blending (Vandita)
- Add power well support (Imre)
- Add Interrupt Support (Anusha)
- Start to add support for DSI on Ice Lake (Madhav)
Anusha Srivatsa (2):
drm/i915/guc: Remove USES_GUC_SUBMISSION for ads programming
drm/i915/icp: Add Interrupt Support
Chris Wilson (65):
drm/i915: Disable bh around call to tasklet
drm/i915: Ignore applying the self-relocation BIAS if no relocations
drm/i915: Redefine EINVAL for debugging
drm/i915: Defer modeset cleanup to a secondary task
drm/i915/execlists: Check for ce->state before destroy
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev5)
== Series Details == Series: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev5) URL : https://patchwork.freedesktop.org/series/6/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. -drivers/gpu/drm/i915/selftests/../i915_drv.h:3652:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3653:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev5)
== Series Details == Series: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev5) URL : https://patchwork.freedesktop.org/series/6/ State : warning == Summary == $ dim checkpatch origin/drm-tip 068faa878cfc drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. -:36: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #36: FILE: drivers/gpu/drm/i915/i915_drv.h:653: +#define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7) ^ total: 0 errors, 0 warnings, 1 checks, 80 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave, Things are calm around drm-intel and we have only 1 fix for hotplug irq on old platforms for this round. I saw that you already send the pull request for 4.18-rc5 So I think this could wait for the next week. But up to you. Here goes drm-intel-fixes-2018-07-10: - Fix hotplug irq ack on i965/g4x (Ville) Thanks, Rodrigo. The following changes since commit 1e4b044d22517cae7047c99038abb23243ca: Linux 4.18-rc4 (2018-07-08 16:34:02 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-07-10 for you to fetch changes up to 96a85cc517a9ee4ae5e8d7f5a36cba05023784eb: drm/i915: Fix hotplug irq ack on i965/g4x (2018-07-09 14:36:47 -0700) - Fix hotplug irq ack on i965/g4x (Ville) Ville Syrjälä (1): drm/i915: Fix hotplug irq ack on i965/g4x drivers/gpu/drm/i915/i915_irq.c | 32 ++-- 1 file changed, 30 insertions(+), 2 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] x86/gpu: reserve ICL's graphics stolen memory
On Wed, Jul 04, 2018 at 07:50:42AM +0200, Ingo Molnar wrote: > > * Rodrigo Vivi wrote: > > > > Cc: Thomas Gleixner > > > > > > Cc: Ingo Molnar > > > > > > Cc: H. Peter Anvin > > > > > > Cc: x...@kernel.org > > > > > > guys, could we push this through drm-intel? ack? > > > nack? comments? > > > > Is there any concern with this patch? > > any ack for push this through drm-intel? > > or any nack with explanations please? > > > > I'd like to push this for 4.19 because this is > > one of the patches that blocks us on using drm-tip > > on ICL. > > Sorry - no objections, and I suppose it will be all tested properly before > going > upstream: > > Acked-by: Ingo Molnar series pushed to drm-intel-next-queued... Probably landing on 4.19 still Thanks for patches, reviews and acks, specially x86 one. > > Thanks, > > Ingo > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev5)
== Series Details == Series: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev5) URL : https://patchwork.freedesktop.org/series/6/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4467_full -> Patchwork_9606_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9606_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9606_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_9606_full: === IGT changes === Possible regressions igt@kms_universal_plane@cursor-fb-leak-pipe-a: shard-apl: PASS -> FAIL Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP igt@pm_rc6_residency@rc6-accuracy: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9606_full that come from known issues: === IGT changes === Issues hit igt@kms_atomic_transition@plane-all-modeset-transition-fencing: shard-glk: PASS -> INCOMPLETE (fdo#103359, k.org#198133) +1 igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#106509, fdo#105454) +1 Possible fixes igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#105363) -> PASS igt@kms_flip@2x-plain-flip-fb-recreate-interruptible: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_flip@dpms-vs-vblank-race: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#107161) -> PASS igt@kms_flip_tiling@flip-x-tiled: shard-glk: FAIL (fdo#107161, fdo#103822) -> PASS +1 igt@kms_rotation_crc@sprite-rotation-180: shard-hsw: FAIL (fdo#103925) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS shard-kbl: FAIL (fdo#99912) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#107161 https://bugs.freedesktop.org/show_bug.cgi?id=107161 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4467 -> Patchwork_9606 CI_DRM_4467: d43ac253ef86f6c89e4e69130baa2c5021a95696 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4546: e8905e756cf3640c66541e963ff97f8af2d98936 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9606: 068faa878cfc4d3d66bd22cd8bb3af4f7b6e96ba @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9606/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
