Re: [Intel-gfx] [PATCH v11 08/42] drm/i915: MEI interface definition
On 2/8/2019 1:18 AM, Daniel Vetter wrote:
On Thu, Feb 07, 2019 at 08:40:08PM +0100, Daniel Vetter wrote:
On Thu, Feb 07, 2019 at 02:33:57AM +0530, Ramalingam C wrote:
Defining the mei-i915 interface functions and initialization of
the interface.
v2:
Adjust to the new interface changes. [Tomas]
Added further debug logs for the failures at MEI i/f.
port in hdcp_port data is equipped to handle -ve values.
v3:
mei comp is matched for global i915 comp master. [Daniel]
In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel]
mei wrappers are adjusted as per the i/f change [Daniel]
v4:
port initialization is done only at hdcp2_init only [Danvet]
v5:
I915 registers a subcomponent to be matched with mei_hdcp [Daniel]
v6:
HDCP_disable for all connectors incase of comp_unbind.
Tear down HDCP comp interface at i915_unload [Daniel]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.c| 1 +
drivers/gpu/drm/i915/i915_drv.h| 7 +
drivers/gpu/drm/i915/intel_connector.c | 2 +
drivers/gpu/drm/i915/intel_drv.h | 6 +
drivers/gpu/drm/i915/intel_hdcp.c | 423 -
include/drm/i915_component.h | 3 +
6 files changed, 441 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7de90701f6f1..9c4218b5d153 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -904,6 +904,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv)
mutex_init(&dev_priv->av_mutex);
mutex_init(&dev_priv->wm.wm_mutex);
mutex_init(&dev_priv->pps_mutex);
+ mutex_init(&dev_priv->hdcp_comp_mutex);
i915_memcpy_init_early(dev_priv);
intel_runtime_pm_init_early(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a2293152cb6a..e3d030b73b5b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include "i915_fixed.h"
#include "i915_params.h"
@@ -2043,6 +2044,12 @@ struct drm_i915_private {
struct i915_pmu pmu;
+ struct i915_hdcp_comp_master *hdcp_master;
+ bool hdcp_comp_added;
+
+ /* Mutex to protect the above hdcp component related values. */
+ struct mutex hdcp_comp_mutex;
+
/*
* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
* will be rejected. Instead look for a better place.
diff --git a/drivers/gpu/drm/i915/intel_connector.c
b/drivers/gpu/drm/i915/intel_connector.c
index ee16758747c5..66ed3ee5998a 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -88,6 +88,8 @@ void intel_connector_destroy(struct drm_connector *connector)
kfree(intel_connector->detect_edid);
+ intel_hdcp_cleanup(intel_connector);
+
if (!IS_ERR_OR_NULL(intel_connector->edid))
kfree(intel_connector->edid);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 030d962697dd..b5c54c688256 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
struct drm_printer;
@@ -385,6 +386,9 @@ struct intel_hdcp_shim {
/* Detects panel's hdcp capability. This is optional for HDMI. */
int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
bool *hdcp_capable);
+
+ /* HDCP adaptation(DP/HDMI) required on the port */
+ enum hdcp_wired_protocol protocol;
};
struct intel_hdcp {
@@ -405,6 +409,7 @@ struct intel_hdcp {
* content can flow only through a link protected by HDCP2.2.
*/
u8 content_type;
+ struct hdcp_port_data port_data;
};
struct intel_connector {
@@ -2070,6 +2075,7 @@ int intel_hdcp_disable(struct intel_connector *connector);
int intel_hdcp_check_link(struct intel_connector *connector);
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
bool intel_hdcp_capable(struct intel_connector *connector);
+void intel_hdcp_cleanup(struct intel_connector *connector);
/* intel_psr.c */
#define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 7b1097d79fb8..79f8979b9150 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -7,8 +7,10 @@
*/
#include
+#include
#include
#include
+#include
#include "intel_drv.h"
#include "i915_reg.h"
@@ -832,6 +834,360 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
}
+static __attribute__((unused)) int
+hdcp2_prepare_ake_init(struct int
Re: [Intel-gfx] [PATCH v2 07/13] drm/i915: Populate gamma_mode for all platforms
Op 07-02-2019 om 17:27 schreef Ville Syrjälä:
> On Thu, Feb 07, 2019 at 04:49:47PM +0100, Maarten Lankhorst wrote:
>> Op 05-02-2019 om 17:08 schreef Ville Syrjala:
>>> From: Ville Syrjälä
>>>
>>> On pre-HSW gamma mode is configured via PIPECONF. The bits are
>>> the same except shifted up, so we can reuse just store them in
>>> crtc_state->gamma_mode in the HSW+ way, allowing us to share
>>> some code later.
>>>
>>> Signed-off-by: Ville Syrjälä
>>> ---
>>> drivers/gpu/drm/i915/i915_reg.h | 10 -
>>> drivers/gpu/drm/i915/intel_color.c | 60 +---
>>> drivers/gpu/drm/i915/intel_display.c | 14 ++-
>>> 3 files changed, 66 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>>> b/drivers/gpu/drm/i915/i915_reg.h
>>> index ede54fdc1676..4a17e519 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -5590,9 +5590,15 @@ enum {
>>> #define PIPECONF_SINGLE_WIDE 0
>>> #define PIPECONF_PIPE_UNLOCKED 0
>>> #define PIPECONF_PIPE_LOCKED (1 << 25)
>>> -#define PIPECONF_PALETTE 0
>>> -#define PIPECONF_GAMMA (1 << 24)
>>> #define PIPECONF_FORCE_BORDER(1 << 25)
>>> +#define PIPECONF_GAMMA_MODE_MASK_I9XX(1 << 24) /* gmch */
>>> +#define PIPECONF_GAMMA_MODE_MASK_ILK (3 << 24) /* ilk-ivb */
>>> +#define PIPECONF_GAMMA_MODE_8BIT (0 << 24) /* gmch,ilk-ivb */
>>> +#define PIPECONF_GAMMA_MODE_10BIT(1 << 24) /* gmch,ilk-ivb */
>>> +#define PIPECONF_GAMMA_MODE_12BIT(2 << 24) /* ilk-ivb */
>>> +#define PIPECONF_GAMMA_MODE_SPLIT(3 << 24) /* ivb */
>>> +#define PIPECONF_GAMMA_MODE(x) ((x)<<24) /* pass in GAMMA_MODE_MODE_*
>>> */
>>> +#define PIPECONF_GAMMA_MODE_SHIFT24
>>> #define PIPECONF_INTERLACE_MASK (7 << 21)
>>> #define PIPECONF_INTERLACE_MASK_HSW (3 << 21)
>>> /* Note that pre-gen3 does not support interlaced display directly. Panel
>>> diff --git a/drivers/gpu/drm/i915/intel_color.c
>>> b/drivers/gpu/drm/i915/intel_color.c
>>> index 2a371eed8061..e7dd07490c68 100644
>>> --- a/drivers/gpu/drm/i915/intel_color.c
>>> +++ b/drivers/gpu/drm/i915/intel_color.c
>>> @@ -351,6 +351,32 @@ static void i9xx_load_luts(const struct
>>> intel_crtc_state *crtc_state)
>>> i9xx_load_luts_internal(crtc_state, crtc_state->base.gamma_lut);
>>> }
>>>
>>> +static void i9xx_color_commit(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 pipe pipe = crtc->pipe;
>>> + u32 val;
>>> +
>>> + val = I915_READ(PIPECONF(pipe));
>>> + val &= ~PIPECONF_GAMMA_MODE_MASK_I9XX;
>>> + val |= PIPECONF_GAMMA_MODE(crtc_state->gamma_mode);
>>> + I915_WRITE(PIPECONF(pipe), val);
>>> +}
>>> +
>>> +static void ilk_color_commit(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 pipe pipe = crtc->pipe;
>>> + u32 val;
>>> +
>>> + val = I915_READ(PIPECONF(pipe));
>>> + val &= ~PIPECONF_GAMMA_MODE_MASK_ILK;
>>> + val |= PIPECONF_GAMMA_MODE(crtc_state->gamma_mode);
>>> + I915_WRITE(PIPECONF(pipe), val);
>>> +}
>>> +
>>> static void hsw_color_commit(const struct intel_crtc_state *crtc_state)
>>> {
>>> struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
>>> @@ -585,8 +611,7 @@ void intel_color_commit(const struct intel_crtc_state
>>> *crtc_state)
>>> {
>>> struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
>>>
>>> - if (dev_priv->display.color_commit)
>>> - dev_priv->display.color_commit(crtc_state);
>>> + dev_priv->display.color_commit(crtc_state);
>>> }
>>>
>>> static int check_lut_size(const struct drm_property_blob *lut, int
>>> expected)
>>> @@ -649,20 +674,25 @@ void intel_color_init(struct intel_crtc *crtc)
>>>
>>> drm_mode_crtc_set_gamma_size(&crtc->base, 256);
>>>
>>> - if (IS_CHERRYVIEW(dev_priv)) {
>>> - dev_priv->display.load_luts = cherryview_load_luts;
>>> - } else if (IS_HASWELL(dev_priv)) {
>>> - dev_priv->display.load_luts = i9xx_load_luts;
>>> - dev_priv->display.color_commit = hsw_color_commit;
>>> - } else if (IS_BROADWELL(dev_priv) || IS_GEN9_BC(dev_priv) ||
>>> - IS_BROXTON(dev_priv)) {
>>> - dev_priv->display.load_luts = broadwell_load_luts;
>>> - dev_priv->display.color_commit = hsw_color_commit;
>>> - } else if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
>>> - dev_priv->display.load_luts = glk_load_luts;
>>> - dev_priv->display.color_commit = hsw_color_commit;
>>> + if (HAS_GMCH_DISPLAY(dev_priv)) {
>>> + if (IS_CHERRYVIEW(dev_priv))
>>> + dev_priv->display.load_luts = cherryview_load_luts;
>>> +
Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree
On Fri, Feb 8, 2019 at 2:38 AM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from drivers/gpu/drm/arm/display/komeda/komeda_drv.c:13:
> drivers/gpu/drm/arm/display/komeda/komeda_kms.h:87:20: error: field 'base'
> has incomplete type
> struct drm_device base;
> ^~~~
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c: In function
> 'komeda_parse_pipe_dt':
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c:27:3: error: implicit
> declaration of function 'DRM_ERROR'; did you mean 'DRM_IOR'?
> [-Werror=implicit-function-declaration]
>DRM_ERROR("get aclk for pipeline %d failed!\n", pipe_id);
>^
>DRM_IOR
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c: In function
> 'komeda_dev_create':
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c:127:2: error: implicit
> declaration of function 'DRM_INFO'; did you mean 'DRM_IO'?
> [-Werror=implicit-function-declaration]
> DRM_INFO("Found ARM Mali-D%x version r%dp%d\n",
> ^~~~
> DRM_IO
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c: In function
> 'komeda_dev_destroy':
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c:170:3: error: implicit
> declaration of function 'devm_iounmap'; did you mean 'pci_iounmap'?
> [-Werror=implicit-function-declaration]
>devm_iounmap(dev, mdev->reg_base);
>^~~~
>pci_iounmap
>
> and lots more ...
>
> Probably caused by commit
>
> e3b01f0d576a ("drm: remove drmP.h from drm_modeset_helper.h")
>
> I have used the drm-misc tree from next-20190207 for today.
Yup.
Sam, can you pls take a look at what komeda needs? you need to
manually merge together drm-misc-next and drm-next first I think.
Dave, Maxime, Liviu: Heads up, drm-misc-next + drm-next will colide.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm tree
On Fri, Feb 08, 2019 at 12:27:44PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> drivers/gpu/drm/i915/intel_display.c
>
> between commit:
>
> 9f58892ea996 ("drm/i915: Pull all the reset functionality together into
> i915_reset.c")
>
> from the drm tree and commit:
>
> d0e93599d396 ("drm/i915: prepare for drmP.h removal from
> drm_modeset_helper.h")
>
> from the drm-misc tree.
>
> I fixed it up (I think I got the right include files in the right order in
> the end - see below and please check the final result) and can carry the
> fix as necessary. This is now fixed as far as linux-next is concerned,
> but any non trivial conflicts should be mentioned to your upstream
> maintainer when your tree is submitted for merging. You may also want
> to consider cooperating with the maintainer of the conflicting tree to
> minimise any particularly complex conflicts.
There isn't a "below" afaics
-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
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_schedule: Rebuild signal handler in child
Quoting Chris Wilson (2019-02-07 23:03:08)
> Make sure that the SIGARLM handler is captured so that we don't
> accidentally shoot ourselves in the foot instead of merely waking up the
> execbuf.
>
> Signed-off-by: Chris Wilson
Warming up the context ahead of time is reasonable for super low SKUs.
But the SIGALRM handler should be inherted, so that's a red herring.
With the commit message and title adjusted for warming up the context:
Reviewed-by: Joonas Lahtinen
Regards, Joonas
> ---
> tests/i915/gem_exec_schedule.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
> index 0462ce84f..d11e57363 100644
> --- a/tests/i915/gem_exec_schedule.c
> +++ b/tests/i915/gem_exec_schedule.c
> @@ -1087,6 +1087,7 @@ static void test_pi_ringfull(int fd, unsigned int
> engine)
> unsigned int last, count;
> struct itimerval itv;
> IGT_CORK_HANDLE(c);
> + uint32_t vip;
> bool *result;
>
> result = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
> @@ -1101,9 +1102,16 @@ static void test_pi_ringfull(int fd, unsigned int
> engine)
> execbuf.buffers_ptr = to_user_pointer(&obj[1]);
> execbuf.buffer_count = 1;
> execbuf.flags = engine;
> +
> + /* Warm up both (hi/lo) contexts */
> execbuf.rsvd1 = gem_context_create(fd);
> - gem_context_set_priority(fd, execbuf.rsvd1, MIN_PRIO);
> + gem_context_set_priority(fd, execbuf.rsvd1, MAX_PRIO);
> + gem_execbuf(fd, &execbuf);
> + gem_sync(fd, obj[1].handle);
> + vip = execbuf.rsvd1;
>
> + execbuf.rsvd1 = gem_context_create(fd);
> + gem_context_set_priority(fd, execbuf.rsvd1, MIN_PRIO);
> gem_execbuf(fd, &execbuf);
> gem_sync(fd, obj[1].handle);
>
> @@ -1147,14 +1155,12 @@ static void test_pi_ringfull(int fd, unsigned int
> engine)
> igt_fork(child, 1) {
> result[0] = true;
>
> - igt_debug("Creating HP context\n");
> - execbuf.rsvd1 = gem_context_create(fd);
> - gem_context_set_priority(fd, execbuf.rsvd1, MAX_PRIO);
> -
> + igt_debug("Waking parent\n");
> kill(getppid(), SIGALRM);
> sched_yield();
> result[1] = true;
>
> + sigaction(SIGALRM, &sa, NULL);
> itv.it_value.tv_sec = 0;
> itv.it_value.tv_usec = 1;
> setitimer(ITIMER_REAL, &itv, NULL);
> @@ -1163,8 +1169,8 @@ static void test_pi_ringfull(int fd, unsigned int
> engine)
> * able to add ourselves to *our* ring without interruption.
> */
> igt_debug("HP child executing\n");
> + execbuf.rsvd1 = vip;
> result[2] = __execbuf(fd, &execbuf) == 0;
> - gem_context_destroy(fd, execbuf.rsvd1);
> }
>
> /* Relinquish CPU just to allow child to create a context */
> @@ -1186,6 +1192,7 @@ static void test_pi_ringfull(int fd, unsigned int
> engine)
> igt_waitchildren();
>
> gem_context_destroy(fd, execbuf.rsvd1);
> + gem_context_destroy(fd, vip);
> gem_close(fd, obj[1].handle);
> gem_close(fd, obj[0].handle);
> munmap(result, 4096);
> --
> 2.20.1
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
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] i915/gem_exec_schedule: Rebuild signal handler in child
Quoting Joonas Lahtinen (2019-02-08 08:59:53) > Quoting Chris Wilson (2019-02-07 23:03:08) > > Make sure that the SIGARLM handler is captured so that we don't > > accidentally shoot ourselves in the foot instead of merely waking up the > > execbuf. > > > > Signed-off-by: Chris Wilson > > Warming up the context ahead of time is reasonable for super low SKUs. > > But the SIGALRM handler should be inherted, so that's a red herring. It wasn't. child 0 died with signal 14, Alarm clock -> hit SIG_DFL -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm tree
Hi Daniel, On Fri, 8 Feb 2019 09:53:33 +0100 Daniel Vetter wrote: > > There isn't a "below" afaics Oops :-( However the merge diff is not very enlightening in this case anyway. It makes more sense to look at the final result when I finish up in a while. -- Cheers, Stephen Rothwell pgp1k3F5j0fL9.pgp Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/8] drm/i915: Force the GPU reset upon wedging
Chris Wilson writes:
> When declaring the GPU wedged, we do need to hit the GPU with the reset
> hammer so that its state matches our presumed state during cleanup. If
> the reset fails, it fails, and we may be unhappy but wedged. However, if
> we are testing our wedge/unwedged handling, the desync carries over into
> the next test and promptly explodes.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=106702
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reset.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reset.c
> b/drivers/gpu/drm/i915/i915_reset.c
> index c67d6c2a09a2..64f26e17243a 100644
> --- a/drivers/gpu/drm/i915/i915_reset.c
> +++ b/drivers/gpu/drm/i915/i915_reset.c
> @@ -532,9 +532,6 @@ typedef int (*reset_func)(struct drm_i915_private *,
>
> static reset_func intel_get_gpu_reset(struct drm_i915_private *i915)
> {
> - if (!i915_modparams.reset)
> - return NULL;
> -
> if (INTEL_GEN(i915) >= 8)
> return gen8_reset_engines;
> else if (INTEL_GEN(i915) >= 6)
> @@ -599,6 +596,9 @@ bool intel_has_gpu_reset(struct drm_i915_private *i915)
> if (USES_GUC(i915))
> return false;
>
> + if (!i915_modparams.reset)
> + return NULL;
> +
I first thought there was no functional change
in this but it is play with get and has.
Part of the reset code complexity is the
deep nesting of 'reset' used on all
layers and you need effort to distinguish
what is prepping, driver resetting and
gpu resetting. But it is not all bad
as we have now 'gpu' popping up in places
where the actual hw is involved.
Reviewed-by: Mika Kuoppala
> return intel_get_gpu_reset(i915);
> }
>
> @@ -824,7 +824,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
> reset_prepare_engine(engine);
>
> /* Even if the GPU reset fails, it should still stop the engines */
> - if (INTEL_GEN(i915) >= 5)
> + if (!INTEL_INFO(i915)->gpu_reset_clobbers_display)
> intel_gpu_reset(i915, ALL_ENGINES);
>
> for_each_engine(engine, i915, id) {
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm tree
On Fri, Feb 8, 2019 at 10:26 AM Stephen Rothwell wrote: > > Hi Daniel, > > On Fri, 8 Feb 2019 09:53:33 +0100 Daniel Vetter wrote: > > > > There isn't a "below" afaics > > Oops :-( However the merge diff is not very enlightening in this case > anyway. It makes more sense to look at the final result when I finish > up in a while. Yeah conflict isn't too bad either, and we have it in the drm rr-cache already. So not worried, just wanted to check whether there's more. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/i915: Uninterruptibly drain the timelines on unwedging
Chris Wilson writes:
> On wedging, we mark all executing requests as complete and all pending
> requests completed as soon as they are ready. Before unwedging though we
> wish to flush those pending requests prior to restoring default
> execution, and so we must wait. Do so interruptibly as we do not provide
uninterruptibly?
> the EINTR gracefully back to userspace in this case but persistent in
be persistent?
We lost the gracefullness due to not having the interruptible
mutex wait on reset path anymore?
-Mika
> the permanently wedged start without restarting the syscall.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_reset.c | 28
> 1 file changed, 8 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reset.c
> b/drivers/gpu/drm/i915/i915_reset.c
> index 64f26e17243a..c4fcb450bd80 100644
> --- a/drivers/gpu/drm/i915/i915_reset.c
> +++ b/drivers/gpu/drm/i915/i915_reset.c
> @@ -862,7 +862,6 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
> {
> struct i915_gpu_error *error = &i915->gpu_error;
> struct i915_timeline *tl;
> - bool ret = false;
>
> if (!test_bit(I915_WEDGED, &error->flags))
> return true;
> @@ -887,30 +886,20 @@ bool i915_gem_unset_wedged(struct drm_i915_private
> *i915)
> mutex_lock(&i915->gt.timelines.mutex);
> list_for_each_entry(tl, &i915->gt.timelines.active_list, link) {
> struct i915_request *rq;
> - long timeout;
>
> rq = i915_active_request_get_unlocked(&tl->last_request);
> if (!rq)
> continue;
>
> /*
> - * We can't use our normal waiter as we want to
> - * avoid recursively trying to handle the current
> - * reset. The basic dma_fence_default_wait() installs
> - * a callback for dma_fence_signal(), which is
> - * triggered by our nop handler (indirectly, the
> - * callback enables the signaler thread which is
> - * woken by the nop_submit_request() advancing the seqno
> - * and when the seqno passes the fence, the signaler
> - * then signals the fence waking us up).
> + * All internal dependencies (i915_requests) will have
> + * been flushed by the set-wedge, but we may be stuck waiting
> + * for external fences. These should all be capped to 10s
> + * (I915_FENCE_TIMEOUT) so this wait should not be unbounded
> + * in the worst case.
>*/
> - timeout = dma_fence_default_wait(&rq->fence, true,
> - MAX_SCHEDULE_TIMEOUT);
> + dma_fence_default_wait(&rq->fence, false, MAX_SCHEDULE_TIMEOUT);
> i915_request_put(rq);
> - if (timeout < 0) {
> - mutex_unlock(&i915->gt.timelines.mutex);
> - goto unlock;
> - }
> }
> mutex_unlock(&i915->gt.timelines.mutex);
>
> @@ -931,11 +920,10 @@ bool i915_gem_unset_wedged(struct drm_i915_private
> *i915)
>
> smp_mb__before_atomic(); /* complete takeover before enabling execbuf */
> clear_bit(I915_WEDGED, &i915->gpu_error.flags);
> - ret = true;
> -unlock:
> +
> mutex_unlock(&i915->gpu_error.wedge_mutex);
>
> - return ret;
> + return true;
> }
>
> static int do_reset(struct drm_i915_private *i915, unsigned int stalled_mask)
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/8] drm/i915: Force the GPU reset upon wedging
Quoting Mika Kuoppala (2019-02-08 09:31:48)
> Chris Wilson writes:
>
> > When declaring the GPU wedged, we do need to hit the GPU with the reset
> > hammer so that its state matches our presumed state during cleanup. If
> > the reset fails, it fails, and we may be unhappy but wedged. However, if
> > we are testing our wedge/unwedged handling, the desync carries over into
> > the next test and promptly explodes.
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=106702
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/i915_reset.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reset.c
> > b/drivers/gpu/drm/i915/i915_reset.c
> > index c67d6c2a09a2..64f26e17243a 100644
> > --- a/drivers/gpu/drm/i915/i915_reset.c
> > +++ b/drivers/gpu/drm/i915/i915_reset.c
> > @@ -532,9 +532,6 @@ typedef int (*reset_func)(struct drm_i915_private *,
> >
> > static reset_func intel_get_gpu_reset(struct drm_i915_private *i915)
> > {
> > - if (!i915_modparams.reset)
> > - return NULL;
> > -
> > if (INTEL_GEN(i915) >= 8)
> > return gen8_reset_engines;
> > else if (INTEL_GEN(i915) >= 6)
> > @@ -599,6 +596,9 @@ bool intel_has_gpu_reset(struct drm_i915_private *i915)
> > if (USES_GUC(i915))
> > return false;
> >
> > + if (!i915_modparams.reset)
> > + return NULL;
> > +
>
> I first thought there was no functional change
> in this but it is play with get and has.
>
> Part of the reset code complexity is the
> deep nesting of 'reset' used on all
> layers and you need effort to distinguish
> what is prepping, driver resetting and
> gpu resetting. But it is not all bad
> as we have now 'gpu' popping up in places
> where the actual hw is involved.
The nice part about this is that it reduces the number of places that
are affected by the parameter to just i915_reset() (oh, and the
I915_PARAM query for has_gpu_reset). Should be far less surprising in
future.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: build warning after merge of the drm-misc tree
Hi Stephen,
On Fri, Feb 08, 2019 at 12:32:04PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c: In function 'sun6i_dsi_probe':
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1053:9: warning: 'ret' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
> return ret;
> ^~~
>
> Introduced by commit
>
> bb3b6fcb6849 ("sun6i: dsi: Convert to generic phy handling")
I just pushed a fix for this, thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
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] [igt-dev] [PATCH i-g-t] i915/gem_exec_schedule: Rebuild signal handler in child
+ Petri for the fact that igt_fork is actually igt_forkoontula and messes up set up signal handlers when transitioning to child. Quoting Chris Wilson (2019-02-08 11:01:55) > Quoting Joonas Lahtinen (2019-02-08 08:59:53) > > Quoting Chris Wilson (2019-02-07 23:03:08) > > > Make sure that the SIGARLM handler is captured so that we don't > > > accidentally shoot ourselves in the foot instead of merely waking up the > > > execbuf. > > > > > > Signed-off-by: Chris Wilson > > > > Warming up the context ahead of time is reasonable for super low SKUs. > > > > But the SIGALRM handler should be inherted, so that's a red herring. > > It wasn't. > > child 0 died with signal 14, Alarm clock Ugh, I'm just running a miniature version locally and it *does* get inherited here. Add a big fat "/* FIXME: IGT should not mess the SIGALRM handler */" above the line, and keep the R-b, then. Regards, Joonas > > -> hit SIG_DFL > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Wait for old resets before applying debugfs/i915_wedged
Chris Wilson writes:
> Since we use the debugfs to recover the device after modifying the
> i915.reset parameter, we need to be sure that we apply the reset and not
> piggy-back onto a concurrent one in order for the parameter to take
> effect.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index a6fd157b1637..8a488ffc8b7d 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3874,13 +3874,9 @@ i915_wedged_set(void *data, u64 val)
> {
> struct drm_i915_private *i915 = data;
>
> - /*
> - * There is no safeguard against this debugfs entry colliding
> - * with the hangcheck calling same i915_handle_error() in
> - * parallel, causing an explosion. For now we assume that the
> - * test harness is responsible enough not to inject gpu hangs
> - * while it is writing to 'i915_wedged'
> - */
> + /* Flush any previous reset before applying for a new one */
> + wait_event(i915->gpu_error.reset_queue,
> +!test_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags));
You removed the comment and yes this makes us wait on our turn
to flip the switch. But the hangcheck vs this race still holds.
Now even if they would two pile on this switch...there should be
no harm as in that case we see two log entries
resulting in a one reset.
Reviewed-by: Mika Kuoppala
-Mika
>
> i915_handle_error(i915, val, I915_ERROR_CAPTURE,
> "Manually set wedged engine mask = %llx", val);
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/i915: Uninterruptibly drain the timelines on unwedging
Quoting Mika Kuoppala (2019-02-08 09:46:01) > Chris Wilson writes: > > > On wedging, we mark all executing requests as complete and all pending > > requests completed as soon as they are ready. Before unwedging though we > > wish to flush those pending requests prior to restoring default > > execution, and so we must wait. Do so interruptibly as we do not provide > > uninterruptibly? > > > the EINTR gracefully back to userspace in this case but persistent in > > be persistent? > > We lost the gracefullness due to not having the interruptible > mutex wait on reset path anymore? No. We never had graceful handling, as we could never propagate the EINTR from unwedge back to userspace so it became EIO instead. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Wait for old resets before applying debugfs/i915_wedged
Quoting Mika Kuoppala (2019-02-08 09:56:59)
> Chris Wilson writes:
>
> > Since we use the debugfs to recover the device after modifying the
> > i915.reset parameter, we need to be sure that we apply the reset and not
> > piggy-back onto a concurrent one in order for the parameter to take
> > effect.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
> > 1 file changed, 3 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index a6fd157b1637..8a488ffc8b7d 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -3874,13 +3874,9 @@ i915_wedged_set(void *data, u64 val)
> > {
> > struct drm_i915_private *i915 = data;
> >
> > - /*
> > - * There is no safeguard against this debugfs entry colliding
> > - * with the hangcheck calling same i915_handle_error() in
> > - * parallel, causing an explosion. For now we assume that the
> > - * test harness is responsible enough not to inject gpu hangs
> > - * while it is writing to 'i915_wedged'
> > - */
> > + /* Flush any previous reset before applying for a new one */
> > + wait_event(i915->gpu_error.reset_queue,
> > +!test_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags));
>
> You removed the comment and yes this makes us wait on our turn
> to flip the switch. But the hangcheck vs this race still holds.
Concurrent resets have been safe for yonks... But what I realised
about our piggy-backing of the 2 resets into one meant that if the value
of the i915.reset modparam changed we didn't run with the updated value.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [IGT] tools/intel_gpu_top: Add support for stdout logging
From: Tvrtko Ursulin
Two new output modes are added: listing of text data to standard out (-l
on the command line), and dumping of JSON formatted records (-J), also to
standard out.
The first mode is selected automatically when non-interactive standard out
is detected.
Signed-off-by: Tvrtko Ursulin
References: https://bugs.freedesktop.org/show_bug.cgi?id=108689
Cc: Eero Tamminen
Cc: 3.1...@ukr.net
---
man/intel_gpu_top.rst | 9 +-
tools/intel_gpu_top.c | 742 +++---
2 files changed, 630 insertions(+), 121 deletions(-)
diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index 19c712307d28..d5bda093c8e8 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -7,9 +7,9 @@ Display a top-like summary of Intel GPU usage
-
.. include:: defs.rst
:Author: IGT Developers
-:Date: 2018-04-04
+:Date: 2019-02-08
:Version: |PACKAGE_STRING|
-:Copyright: 2009,2011,2012,2016,2018 Intel Corporation
+:Copyright: 2009,2011,2012,2016,2018,2019 Intel Corporation
:Manual section: |MANUAL_SECTION|
:Manual group: |MANUAL_GROUP|
@@ -31,6 +31,11 @@ OPTIONS
-s
Refresh period in milliseconds.
+-l
+List text data to standard out.
+
+-J
+Output JSON formatted data to standard output.
-h
Show help text.
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index b923c3cfbe97..1313e0d46b5e 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -1,5 +1,5 @@
/*
- * Copyright © 2007-2018 Intel Corporation
+ * Copyright © 2007-2019 Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -19,10 +19,6 @@
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE.
- *
- * Authors:
- *Eric Anholt
- *Eugeni Dodonov
*/
#include
@@ -41,6 +37,7 @@
#include
#include
#include
+#include
#include "igt_perf.h"
@@ -59,6 +56,7 @@ struct pmu_counter {
struct engine {
const char *name;
const char *display_name;
+ const char *short_name;
unsigned int class;
unsigned int instance;
@@ -142,6 +140,22 @@ static const char *class_display_name(unsigned int class)
}
}
+static const char *class_short_name(unsigned int class)
+{
+ switch (class) {
+ case I915_ENGINE_CLASS_RENDER:
+ return "RCS";
+ case I915_ENGINE_CLASS_COPY:
+ return "BCS";
+ case I915_ENGINE_CLASS_VIDEO:
+ return "VCS";
+ case I915_ENGINE_CLASS_VIDEO_ENHANCE:
+ return "VECS";
+ default:
+ return "UNKN";
+ }
+}
+
static int engine_cmp(const void *__a, const void *__b)
{
const struct engine *a = (struct engine *)__a;
@@ -227,7 +241,6 @@ static struct engines *discover_engines(void)
ret = ENOBUFS;
break;
}
- ret = 0;
engine->display_name = strdup(buf);
if (!engine->display_name) {
@@ -235,6 +248,20 @@ static struct engines *discover_engines(void)
break;
}
+ ret = snprintf(buf, sizeof(buf), "%s/%u",
+ class_short_name(engine->class),
+ engine->instance);
+ if (ret < 0 || ret == sizeof(buf)) {
+ ret = ENOBUFS;
+ break;
+ }
+
+ engine->short_name = strdup(buf);
+ if (!engine->short_name) {
+ ret = errno;
+ break;
+ }
+
engines->num_engines++;
engines = realloc(engines, sizeof(struct engines) +
engines->num_engines * sizeof(struct engine));
@@ -242,6 +269,8 @@ static struct engines *discover_engines(void)
ret = errno;
break;
}
+
+ ret = 0;
}
if (ret) {
@@ -551,7 +580,7 @@ static uint64_t pmu_read_multi(int fd, unsigned int num,
uint64_t *val)
return buf[1];
}
-static double __pmu_calc(struct pmu_pair *p, double d, double t, double s)
+static double pmu_calc(struct pmu_pair *p, double d, double t, double s)
{
double v;
@@ -576,30 +605,6 @@ static void fill_str(char *buf, unsigned int bufsz, char
c, unsigned int num)
*buf = 0;
}
-static void pmu_calc(struct pmu_counter *cnt,
-char *buf, unsigned int bufsz,
-unsigned int width, unsigned width_dec,
-double d, double t, double s)
-{
- double val;
- int len;
-
- assert(bufsz >= (width + width_dec + 1));
-
- if (!cnt->pres
Re: [Intel-gfx] [igt-dev] [IGT] tools/intel_gpu_top: Add support for stdout logging
Quoting Tvrtko Ursulin (2019-02-08 10:26:12) > From: Tvrtko Ursulin > > Two new output modes are added: listing of text data to standard out (-l > on the command line), and dumping of JSON formatted records (-J), also to > standard out. Any chance of interactive with yaml^W json to file? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] components: multiple components for a device
On Fri, Feb 08, 2019 at 12:27:57AM +0100, Daniel Vetter wrote:
> Component framework is extended to support multiple components for
> a struct device. These will be matched with different masters based on
> its sub component value.
>
> We are introducing this, as I915 needs two different components
> with different subcomponent value, which will be matched to two
> different component masters(Audio and HDCP) based on the subcomponent
> values.
>
> v2: Add documenation.
>
> v3: Rebase on top of updated documenation.
>
> v4: Review from Rafael:
> - Remove redundant "This" from kerneldoc (also in the previous patch)
> - Streamline the logic in find_component() a bit.
>
> Signed-off-by: Daniel Vetter (v1 code)
> Signed-off-by: Ramalingam C (v1 commit message)
> Cc: Ramalingam C
> Cc: Greg Kroah-Hartman
> Cc: Russell King
> Cc: Rafael J. Wysocki
> Cc: Jaroslav Kysela
> Cc: Takashi Iwai
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Signed-off-by: Daniel Vetter
> ---
> drivers/base/component.c | 158 +-
> include/linux/component.h | 10 ++-
> 2 files changed, 129 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/base/component.c b/drivers/base/component.c
> index 1624c2a892a5..7dbc41cccd58 100644
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -47,6 +47,7 @@ struct component;
> struct component_match_array {
> void *data;
> int (*compare)(struct device *, void *);
> + int (*compare_typed)(struct device *, int, void *);
> void (*release)(struct device *, void *);
> struct component *component;
> bool duplicate;
> @@ -74,6 +75,7 @@ struct component {
> bool bound;
>
> const struct component_ops *ops;
> + int subcomponent;
> struct device *dev;
> };
>
> @@ -158,7 +160,7 @@ static struct master *__master_find(struct device *dev,
> }
>
> static struct component *find_component(struct master *master,
> - int (*compare)(struct device *, void *), void *compare_data)
> + struct component_match_array *mc)
> {
> struct component *c;
>
> @@ -166,7 +168,11 @@ static struct component *find_component(struct master
> *master,
> if (c->master && c->master != master)
> continue;
>
> - if (compare(c->dev, compare_data))
> + if (mc->compare && mc->compare(c->dev, mc->data))
> + return c;
> +
> + if (mc->compare_typed &&
> + mc->compare_typed(c->dev, c->subcomponent, mc->data))
> return c;
> }
>
> @@ -192,7 +198,7 @@ static int find_components(struct master *master)
> if (match->compare[i].component)
> continue;
>
> - c = find_component(master, mc->compare, mc->data);
> + c = find_component(master, mc);
> if (!c) {
> ret = -ENXIO;
> break;
> @@ -327,29 +333,12 @@ static int component_match_realloc(struct device *dev,
> return 0;
> }
>
> -/**
> - * component_match_add_release - add a component match with release callback
> - * @master: device with the aggregate driver
> - * @matchptr: pointer to the list of component matches
> - * @release: release function for @compare_data
> - * @compare: compare function to match against all components
> - * @compare_data: opaque pointer passed to the @compare function
> - *
> - * Adds a new component match to the list stored in @matchptr, which the
> @master
> - * aggregate driver needs to function. The list of component matches pointed
> to
> - * by @matchptr must be initialized to NULL before adding the first match.
> - *
> - * The allocated match list in @matchptr is automatically released using devm
> - * actions, where upon @release will be called to free any references held by
> - * @compare_data, e.g. when @compare_data is a &device_node that must be
> - * released with of_node_put().
> - *
> - * See also component_match_add().
> - */
> -void component_match_add_release(struct device *master,
> +static void __component_match_add(struct device *master,
> struct component_match **matchptr,
> void (*release)(struct device *, void *),
> - int (*compare)(struct device *, void *), void *compare_data)
> + int (*compare)(struct device *, void *),
> + int (*compare_typed)(struct device *, int, void *),
> + void *compare_data)
> {
> struct component_match *match = *matchptr;
>
> @@ -381,13 +370,69 @@ void component_match_add_release(struct device *master,
> }
>
> match->compare[match->num].compare = compare;
> + match->compare[match->num].compare_typed = compare_typed;
> match->compare[match->num].release = release;
> match->compare[match->num].data = compare_data;
> match->compare[match->num].component = NULL;
> match->num++;
> }
> +
> +/**
> + * component_match_add_release - add a component matc
Re: [Intel-gfx] [igt-dev] [IGT] tools/intel_gpu_top: Add support for stdout logging
Quoting Tvrtko Ursulin (2019-02-08 10:26:12)
> +static unsigned int json_indent_level;
> +
> +static const char *json_indent[] = {
> + "",
> + "\t",
> + "\t\t",
> + "\t\t\t",
> + "\t\t\t\t",
> + "\t\t\t\t\t",
> +};
> +
> +#define ARRAY_SIZE(arr) (sizeof(arr)/sizeof(arr[0]))
> +
> +static unsigned int json_prev_struct_members;
> +static unsigned int json_struct_members;
> +
> +static void
> +json_open_struct(const char *name)
> +{
> + assert(json_indent_level < ARRAY_SIZE(json_indent));
> +
> + json_prev_struct_members = json_struct_members;
> + json_struct_members = 0;
> +
> + if (name)
> + printf("%s%s\"%s\": {\n",
> + json_prev_struct_members ? ",\n" : "",
> + json_indent[json_indent_level],
> + name);
"%*s", json_indent_level, "\t\t\t\t\t\t"
Ok, that seems to tally with what I expect the output to look like.
> +static unsigned int stdout_level;
Ah, stdout == plain old output.
> +static int
> +print_header(struct engines *engines, double t,
> +int lines, int con_w, int con_h, bool *consumed)
> +{
> + struct pmu_counter fake_pmu = {
> + .present = true,
> + .val.cur = 1,
> + };
> + struct cnt_item period_items[] = {
> + { &fake_pmu, 0, 0, 1.0, 1.0, t * 1e3, "duration" },
> + { NULL, 0, 0, 0.0, 0.0, 0.0, "unit", "ms" },
> + { },
> + };
> + struct cnt_group period_group = {
> + .name = "period",
> + .items = period_items,
> + };
> + struct cnt_item freq_items[] = {
> + { &engines->freq_req, 4, 0, 1.0, t, 1, "requested", "req" },
> + { &engines->freq_act, 4, 0, 1.0, t, 1, "actual", "act" },
> + { NULL, 0, 0, 0.0, 0.0, 0.0, "unit", "MHz" },
> + { },
> + };
> + struct cnt_group freq_group = {
> + .name = "frequency",
> + .display_name = "Freq MHz",
> + .items = freq_items,
> + };
> + struct cnt_item irq_items[] = {
> + { &engines->irq, 8, 0, 1.0, t, 1, "count", "/s" },
> + { NULL, 0, 0, 0.0, 0.0, 0.0, "unit", "irq/s" },
> + { },
> + };
> + struct cnt_group irq_group = {
> + .name = "interrupts",
> + .display_name = "IRQ",
> + .items = irq_items,
> + };
> + struct cnt_item rc6_items[] = {
> + { &engines->rc6, 3, 0, 1e9, t, 100, "value", "%" },
> + { NULL, 0, 0, 0.0, 0.0, 0.0, "unit", "%" },
> + { },
> + };
> + struct cnt_group rc6_group = {
> + .name = "rc6",
> + .display_name = "RC6",
> + .items = rc6_items,
> + };
> + struct cnt_item power_items[] = {
> + { &engines->rapl, 4, 2, 1.0, t, engines->rapl_scale, "value",
> + "W" },
> + { NULL, 0, 0, 0.0, 0.0, 0.0, "unit", "W" },
> + { },
> + };
> + struct cnt_group power_group = {
> + .name = "power",
> + .display_name = "Power",
> + .items = power_items,
> + };
> + struct cnt_group *groups[] = {
> + &period_group,
> + &freq_group,
> + &irq_group,
> + &rc6_group,
> + &power_group,
> + NULL
> + };
> +
> + if (output_mode != JSON)
> + memmove(&groups[0], &groups[1],
> + sizeof(groups) - sizeof(groups[0]));
> +
> + pops->open_struct(NULL);
> +
> + *consumed = print_groups(groups);
> +
> + if (output_mode == INTERACTIVE) {
> + printf("\033[H\033[J");
> +
> + if (lines++ < con_h)
> + printf("intel-gpu-top - %s/%s MHz; %s%% RC6; %s %s;
> %s irqs/s\n",
> + freq_items[1].buf, freq_items[0].buf,
> + rc6_items[0].buf, power_items[0].buf,
> + engines->rapl_unit,
> + irq_items[0].buf);
I would suggest a timestamp (time of day) if room.
Hang on, I don't recall seeing a timestamp amongst the output?
Looks very, very neat.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [IGT] tools/intel_gpu_top: Add support for stdout logging
On 08/02/2019 10:33, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-02-08 10:26:12) From: Tvrtko Ursulin Two new output modes are added: listing of text data to standard out (-l on the command line), and dumping of JSON formatted records (-J), also to standard out. Any chance of interactive with yaml^W json to file? If you cannot do with shell redirection then sure, it shouldn't be hard to add. YAML, if it follows the same patterns as JSON, also should be easy like a handful of lines. And the latter.. I need some feedback from the users on how they plan to use it. This implementation outputs records, but if you Ctrl-C-it you get the last incomplete. And you probably need to wrap everything in [ ] to make an array of these records. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [IGT] tools/intel_gpu_top: Add support for stdout logging
Quoting Tvrtko Ursulin (2019-02-08 10:52:19) > > On 08/02/2019 10:33, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-02-08 10:26:12) > >> From: Tvrtko Ursulin > >> > >> Two new output modes are added: listing of text data to standard out (-l > >> on the command line), and dumping of JSON formatted records (-J), also to > >> standard out. > > > > Any chance of interactive with yaml^W json to file? > > If you cannot do with shell redirection then sure, it shouldn't be hard > to add. > > YAML, if it follows the same patterns as JSON, also should be easy like > a handful of lines. > > And the latter.. I need some feedback from the users on how they plan to > use it. This implementation outputs records, but if you Ctrl-C-it you > get the last incomplete. And you probably need to wrap everything in [ ] > to make an array of these records. signal(SIGINT, close_output) ? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [IGT] tools/intel_gpu_top: Add support for stdout logging
On 08/02/2019 10:57, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-02-08 10:52:19) On 08/02/2019 10:33, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-02-08 10:26:12) From: Tvrtko Ursulin Two new output modes are added: listing of text data to standard out (-l on the command line), and dumping of JSON formatted records (-J), also to standard out. Any chance of interactive with yaml^W json to file? If you cannot do with shell redirection then sure, it shouldn't be hard to add. YAML, if it follows the same patterns as JSON, also should be easy like a handful of lines. And the latter.. I need some feedback from the users on how they plan to use it. This implementation outputs records, but if you Ctrl-C-it you get the last incomplete. And you probably need to wrap everything in [ ] to make an array of these records. signal(SIGINT, close_output) ? I guess.. wanted to keep it simple but this is probably warranted. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_scheduler: Disable alarm before exiting child
Still the blighted
Starting subtest: pi-ringfull-bsd
child 0 died with signal 14, Alarm clock
Subtest pi-ringfull-bsd: FAIL (0.133s)
So let's make sure our timer cannot fire later on during exit.
References https://bugs.freedesktop.org/show_bug.cgi?id=109584
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
tests/i915/gem_exec_schedule.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index d11e57363..00f9528a3 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -1153,7 +1153,9 @@ static void test_pi_ringfull(int fd, unsigned int engine)
bind_to_cpu(0);
igt_fork(child, 1) {
- result[0] = true;
+ int err;
+
+ result[0] = vip != execbuf.rsvd1;
igt_debug("Waking parent\n");
kill(getppid(), SIGALRM);
@@ -1170,12 +1172,18 @@ static void test_pi_ringfull(int fd, unsigned int
engine)
*/
igt_debug("HP child executing\n");
execbuf.rsvd1 = vip;
- result[2] = __execbuf(fd, &execbuf) == 0;
+ err = __execbuf(fd, &execbuf);
+ igt_debug("HP execbuf returned %d\n", err);
+
+ memset(&itv, 0, sizeof(itv));
+ setitimer(ITIMER_REAL, &itv, NULL);
+
+ result[2] = err == 0;
}
/* Relinquish CPU just to allow child to create a context */
sleep(1);
- igt_assert_f(result[0], "HP context (child) not created");
+ igt_assert_f(result[0], "HP context (child) not created\n");
igt_assert_f(!result[1], "Child released too early!\n");
/* Parent sleeps waiting for ringspace, releasing child */
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] components: multiple components for a device
On Fri, Feb 08, 2019 at 12:27:57AM +0100, Daniel Vetter wrote: > Component framework is extended to support multiple components for > a struct device. These will be matched with different masters based on > its sub component value. > > We are introducing this, as I915 needs two different components > with different subcomponent value, which will be matched to two > different component masters(Audio and HDCP) based on the subcomponent > values. > > v2: Add documenation. > > v3: Rebase on top of updated documenation. > > v4: Review from Rafael: > - Remove redundant "This" from kerneldoc (also in the previous patch) > - Streamline the logic in find_component() a bit. > > Signed-off-by: Daniel Vetter (v1 code) > Signed-off-by: Ramalingam C (v1 commit message) > Cc: Ramalingam C > Cc: Greg Kroah-Hartman > Cc: Russell King > Cc: Rafael J. Wysocki > Cc: Jaroslav Kysela > Cc: Takashi Iwai > Cc: Rodrigo Vivi > Cc: Jani Nikula > Signed-off-by: Daniel Vetter Reviewed-by: Greg Kroah-Hartman ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] component: Add documentation
On Fri, Feb 08, 2019 at 12:27:56AM +0100, Daniel Vetter wrote: > While typing these I think doing an s/component_master/aggregate/ > would be useful: > - it's shorter :-) > - I think component/aggregate is much more meaningful naming than > component/puppetmaster or something like that. At least to my > English ear "aggregate" emphasizes much more the "assemble a pile of > things into something bigger" aspect, and there's not really much > of a control hierarchy between aggregate and constituing components. > > But that's way more than a quick doc typing exercise ... > > Thanks to Ram for commenting on an initial draft of these docs. > > v2: Review from Rafael: > - git add Documenation/driver-api/component.rst > - lots of polish to the wording + spelling fixes. > > v3: Review from Russell: > - s/framework/helper > - clarify the documentation for component_match_add functions. > > v4: Remove a few superflous "This". > > Reviewed-by: Rafael J. Wysocki > Cc: "C, Ramalingam" > Cc: Greg Kroah-Hartman > Cc: Russell King > Cc: Rafael J. Wysocki > Cc: Jaroslav Kysela > Cc: Takashi Iwai > Cc: Rodrigo Vivi > Cc: Jani Nikula > Signed-off-by: Daniel Vetter Thanks for doing this! Reviewed-by: Greg Kroah-Hartman ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [IGT 2/2] tools/intel_gpu_top: Add file output capability
From: Tvrtko Ursulin
A new -o command switch enables logging to a file.
Signed-off-by: Tvrtko Ursulin
References: https://bugs.freedesktop.org/show_bug.cgi?id=108689
Cc: Eero Tamminen
Cc: 3.1...@ukr.net
Cc: Chris Wilson
---
man/intel_gpu_top.rst | 18 -
tools/intel_gpu_top.c | 63 ---
2 files changed, 52 insertions(+), 29 deletions(-)
diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index d5bda093c8e8..1313ef0bde5f 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -28,16 +28,20 @@ The tool gathers data using perf performance counters (PMU)
exposed by i915 and
OPTIONS
===
--s
-Refresh period in milliseconds.
+-h
+Show help text.
+
+-J
+Output JSON formatted data.
-l
-List text data to standard out.
+List plain text data.
--J
-Output JSON formatted data to standard output.
--h
-Show help text.
+-o
+Output to the specified file instead of standard output.
+
+-s
+Refresh period in milliseconds.
LIMITATIONS
===
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 807d518aaf87..ecbabfb3bc75 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -702,10 +702,11 @@ usage(const char *appname)
"Usage: %s [parameters]\n"
"\n"
"\tThe following parameters are optional:\n\n"
- "\t[-s ] Refresh period in milliseconds (default
%ums).\n"
- "\t[-l]List data to standard out.\n"
- "\t[-J]JSON data to standard out.\n"
"\t[-h]Show this help text.\n"
+ "\t[-J]Output JSON formatted data.\n"
+ "\t[-l]List plain text data.\n"
+ "\t[-o ] Output to specified file.\n"
+ "\t[-s ] Refresh period in milliseconds (default
%ums).\n"
"\n",
appname, DEFAULT_PERIOD_MS);
}
@@ -752,6 +753,8 @@ static const char *json_indent[] = {
static unsigned int json_prev_struct_members;
static unsigned int json_struct_members;
+FILE *out;
+
static void
json_open_struct(const char *name)
{
@@ -761,14 +764,14 @@ json_open_struct(const char *name)
json_struct_members = 0;
if (name)
- printf("%s%s\"%s\": {\n",
- json_prev_struct_members ? ",\n" : "",
- json_indent[json_indent_level],
- name);
+ fprintf(out, "%s%s\"%s\": {\n",
+ json_prev_struct_members ? ",\n" : "",
+ json_indent[json_indent_level],
+ name);
else
- printf("%s\n%s{\n",
- json_prev_struct_members ? "," : "",
- json_indent[json_indent_level]);
+ fprintf(out, "%s\n%s{\n",
+ json_prev_struct_members ? "," : "",
+ json_indent[json_indent_level]);
json_indent_level++;
}
@@ -778,7 +781,7 @@ json_close_struct(void)
{
assert(json_indent_level > 0);
- printf("\n%s}", json_indent[--json_indent_level]);
+ fprintf(out, "\n%s}", json_indent[--json_indent_level]);
if (json_indent_level == 0)
fflush(stdout);
@@ -790,17 +793,17 @@ json_add_member(const struct cnt_group *parent, struct
cnt_item *item,
{
assert(json_indent_level < ARRAY_SIZE(json_indent));
- printf("%s%s\"%s\": ",
+ fprintf(out, "%s%s\"%s\": ",
json_struct_members ? ",\n" : "",
json_indent[json_indent_level], item->name);
json_struct_members++;
if (!strcmp(item->name, "unit"))
- printf("\"%s\"", item->unit);
+ fprintf(out, "\"%s\"", item->unit);
else
- printf("%f",
- pmu_calc(&item->pmu->val, item->d, item->t, item->s));
+ fprintf(out, "%f",
+ pmu_calc(&item->pmu->val, item->d, item->t, item->s));
return 1;
}
@@ -823,8 +826,8 @@ stdout_close_struct(void)
assert(stdout_level > 0);
if (--stdout_level == 0) {
stdout_lines++;
- printf("\n");
- fflush(stdout);
+ fputs("\n", out);
+ fflush(out);
}
}
@@ -856,10 +859,10 @@ stdout_add_member(const struct cnt_group *parent, struct
cnt_item *item,
grp_tot += 1 + it->fmt_d + (it->fmt_dd ? 1 : 0);
}
- printf("%*s ", grp_tot - 1, parent->display_name);
+ fprintf(out, "%*s ", grp_tot - 1, parent->display_name);
return 0;
} else if (headers == 2) {
- printf("%*s ", fmt_tot, item->unit ?: item->name);
+ fprintf(out, "%*s ", fmt_tot, item->unit ?: item->name);
return 0;
}
@@ -869,7 +87
[Intel-gfx] [IGT 1/2] tools/intel_gpu_top: Add support for stdout logging
From: Tvrtko Ursulin
Two new output modes are added: listing of text data to standard out (-l
on the command line), and dumping of JSON formatted records (-J), also to
standard out.
The first mode is selected automatically when non-interactive standard out
is detected.
Example of text output:
Freq MHz IRQ RC6 Power IMC MiB/s RCS/0 BCS/0
VCS/0 VCS/1 VECS/0
req act /s % W rd wr % se wa % se wa
% se wa % se wa % se wa
000 0 0.00360 00.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
350 3500 100 0.00 35 20.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
350 3500 100 0.00 34 20.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
350 3500 100 0.00143 60.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
350 3500 100 0.00169 70.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
350 3500 100 0.00169 70.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
Example of JSON output:
{
"period": {
"duration": 1002.525224,
"unit": "ms"
},
"frequency": {
"requested": 349.118398,
"actual": 349.118398,
"unit": "MHz"
},
"interrupts": {
"count": 0.00,
"unit": "irq/s"
},
"rc6": {
"value": 99.897752,
"unit": "%"
},
"power": {
"value": 0.00,
"unit": "W"
},
"imc-bandwidth": {
"reads": 149.683843,
"writes": 6.104093,
"unit": "MiB/s"
},
"engines": {
"Render/3D/0": {
"busy": 0.00,
"sema": 0.00,
"wait": 0.00,
"unit": "%"
},
"Blitter/0": {
"busy": 0.00,
"sema": 0.00,
"wait": 0.00,
"unit": "%"
},
"Video/0": {
"busy": 0.00,
"sema": 0.00,
"wait": 0.00,
"unit": "%"
},
"Video/1": {
"busy": 0.00,
"sema": 0.00,
"wait": 0.00,
"unit": "%"
},
"VideoEnhance/0": {
"busy": 0.00,
"sema": 0.00,
"wait": 0.00,
"unit": "%"
}
}
}
v2:
* Show example output in commit message.
* Install signal handler to complete output on SIGINT. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
References: https://bugs.freedesktop.org/show_bug.cgi?id=108689
Cc: Eero Tamminen
Cc: 3.1...@ukr.net
Cc: Chris Wilson
---
man/intel_gpu_top.rst | 9 +-
tools/intel_gpu_top.c | 761 +++---
2 files changed, 650 insertions(+), 120 deletions(-)
diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index 19c712307d28..d5bda093c8e8 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -7,9 +7,9 @@ Display a top-like summary of Intel GPU usage
-
.. include:: defs.rst
:Author: IGT Developers
-:Date: 2018-04-04
+:Date: 2019-02-08
:Version: |PACKAGE_STRING|
-:Copyright: 2009,2011,2012,2016,2018 Intel Corporation
+:Copyright: 2009,2011,2012,2016,2018,2019 Intel Corporation
:Manual section: |MANUAL_SECTION|
:Manual group: |MANUAL_GROUP|
@@ -31,6 +31,11 @@ OPTIONS
-s
Refresh period in milliseconds.
+-l
+List text data to standard out.
+
+-J
+Output JSON formatted data to standard output.
-h
Show help text.
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index b923c3cfbe97..807d518aaf87 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -1,5 +1,5 @@
/*
- * Copyright © 2007-2018 Intel Corporation
+ * Copyright © 2007-2019 Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -19,10 +19,6 @@
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE.
- *
- * Authors:
- *Eric Anholt
- *Eugeni Dodonov
*/
#include
@@ -41,6 +37,8 @@
#
Re: [Intel-gfx] [IGT 1/2] tools/intel_gpu_top: Add support for stdout logging
Quoting Tvrtko Ursulin (2019-02-08 12:03:50)
> From: Tvrtko Ursulin
>
> Two new output modes are added: listing of text data to standard out (-l
> on the command line), and dumping of JSON formatted records (-J), also to
> standard out.
>
> The first mode is selected automatically when non-interactive standard out
> is detected.
>
> Example of text output:
>
> Freq MHz IRQ RC6 Power IMC MiB/s RCS/0 BCS/0
>VCS/0 VCS/1 VECS/0
> req act /s % W rd wr % se wa % se wa
>% se wa % se wa % se wa
>000 0 0.00360 00.00 0 00.00 0 0
> 0.00 0 00.00 0 00.00 0 0
> 350 3500 100 0.00 35 20.00 0 00.00 0 0
> 0.00 0 00.00 0 00.00 0 0
> 350 3500 100 0.00 34 20.00 0 00.00 0 0
> 0.00 0 00.00 0 00.00 0 0
> 350 3500 100 0.00143 60.00 0 00.00 0 0
> 0.00 0 00.00 0 00.00 0 0
> 350 3500 100 0.00169 70.00 0 00.00 0 0
> 0.00 0 00.00 0 00.00 0 0
> 350 3500 100 0.00169 70.00 0 00.00 0 0
> 0.00 0 00.00 0 00.00 0 0
>
> Example of JSON output:
>
> {
> "period": {
> "duration": 1002.525224,
> "unit": "ms"
> },
> "frequency": {
> "requested": 349.118398,
> "actual": 349.118398,
> "unit": "MHz"
> },
> "interrupts": {
> "count": 0.00,
> "unit": "irq/s"
> },
> "rc6": {
> "value": 99.897752,
> "unit": "%"
> },
> "power": {
> "value": 0.00,
> "unit": "W"
> },
> "imc-bandwidth": {
> "reads": 149.683843,
> "writes": 6.104093,
> "unit": "MiB/s"
> },
> "engines": {
> "Render/3D/0": {
Stale output? Didn't you switch to the bspec names?
"${class}${instance}": {
> + ret = snprintf(buf, sizeof(buf), "%s/%u",
"%s/%u", we don't use a slash separator elsewhere?
> + class_short_name(engine->class),
> + engine->instance);
> + if (ret < 0 || ret == sizeof(buf)) {
> + ret = ENOBUFS;
> + break;
> + }
> +
> + engine->short_name = strdup(buf);
asprintf(&engine->short_name ...);
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [IGT 2/2] tools/intel_gpu_top: Add file output capability
Quoting Tvrtko Ursulin (2019-02-08 12:03:51)
> From: Tvrtko Ursulin
>
> A new -o command switch enables logging to a file.
>
> Signed-off-by: Tvrtko Ursulin
> References: https://bugs.freedesktop.org/show_bug.cgi?id=108689
> Cc: Eero Tamminen
> Cc: 3.1...@ukr.net
> Cc: Chris Wilson
> - if (output_mode == INTERACTIVE && isatty(1) != 1)
> + if (output_mode == INTERACTIVE && (output_path || isatty(1) != 1))
> output_mode = STDOUT;
>
> + if (output_path) {
if (output_path && strcmp(output_path, "-")) { ?
"-o -" is common enough for forcing output even on the terminal.
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
>> >> >-Original Message-
>> >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>> >> >Sent: Tuesday, February 5, 2019 10:02 PM
>> >> >To: Shankar, Uma
>> >> >Cc: intel-gfx@lists.freedesktop.org;
>> >> >dri-de...@lists.freedesktop.org; Syrjala, Ville
>> >> >; Lankhorst, Maarten
>> >> >
>> >> >Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace
>> >> >property
>> >> >
>> >> >On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote:
>> >> >> Create a new connector property to program colorspace to sink devices.
>> >> >> Modern sink devices support more than 1 type of colorspace like
>> >> >> 601, 709, BT2020 etc. This helps to switch based on content type
>> >> >> which is to be displayed. The decision lies with compositors as
>> >> >> to in which scenarios, a particular colorspace will be picked.
>> >> >>
>> >> >> This will be helpful mostly to switch to higher gamut
>> >> >> colorspaces like
>> >> >> BT2020 when the media content is encoded as BT2020. Thereby
>> >> >> giving a good visual experience to users.
>> >> >>
>> >> >> The expectation from userspace is that it should parse the EDID
>> >> >> and get supported colorspaces. Use this property and switch to
>> >> >> the one supported. Sink supported colorspaces should be
>> >> >> retrieved by userspace from EDID and driver will not explicitly expose
>them.
>> >> >>
>> >> >> Basically the expectation from userspace is:
>> >> >> - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
>> >> >>colorspace
>> >> >> - Set this new property to let the sink know what it
>> >> >>converted the CRTC output to.
>> >> >>
>> >> >> v2: Addressed Maarten and Ville's review comments. Enhanced the
>> >> >> colorspace enum to incorporate both HDMI and DP supported
>colorspaces.
>> >> >> Also, added a default option for colorspace.
>> >> >>
>> >> >> v3: Removed Adobe references from enum definitions as per Ville,
>> >> >> Hans Verkuil and Jonas Karlman suggestions. Changed Default to
>> >> >> an unset state where driver will assign the colorspace is not
>> >> >> chosen by user, suggested by Ville and Maarten. Addressed other
>> >> >> misc review comments from Maarten. Split the changes to have
>> >> >> separate colorspace property for DP and HDMI.
>> >> >>
>> >> >> v4: Addressed Chris and Ville's review comments, and created a
>> >> >> common colorspace property for DP and HDMI, filtered the list
>> >> >> based on the colorspaces supported by the respective protocol standard.
>> >> >>
>> >> >> v5: Made the property creation helper accept enum list based on
>> >> >> platform capabilties as suggested by Shashank. Consolidated HDMI
>> >> >> and DP property creation in the common helper.
>> >> >>
>> >> >> v6: Addressed Shashank's review comments.
>> >> >>
>> >> >> v7: Added defines instead of enum in uapi as per Brian Starkey's
>> >> >> suggestion in order to go with string matching at userspace.
>> >> >> Updated the commit message to add more details as well kernel docs.
>> >> >>
>> >> >> v8: Addressed Maarten's review comments.
>> >> >>
>> >> >> v9: Removed macro defines from uapi as per Brian Starkey and
>> >> >> Daniel Stone's comments and moved to drm include file. Moved
>> >> >> back to older design with exposing all HDMI colorspaces to
>> >> >> userspace since infoframe capability is there even on legacy
>> >> >> platforms, as per Ville's review comments.
>> >> >>
>> >> >> v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>> >> >>
>> >> >> v11: Addressed Ville's review comments. Updated the Macro naming
>> >> >> and added DCI-P3 colorspace as well defined in CEA 861.G spec.
>> >> >>
>> >> >> Signed-off-by: Uma Shankar
>> >> >> Acked-by: Jani Nikula
>> >> >> Reviewed-by: Shashank Sharma
>> >> >> Reviewed-by: Maarten Lankhorst
>> >> >>
>> >> >> ---
>> >> >> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
>> >> >> drivers/gpu/drm/drm_connector.c | 78
>> >> >+++
>> >> >> include/drm/drm_connector.h | 50 +
>> >> >> 3 files changed, 132 insertions(+)
>> >> >>
>> >> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> >> >> b/drivers/gpu/drm/drm_atomic_uapi.c
>> >> >> index 9a1f41a..9b5d44f 100644
>> >> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> >> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> >> >> @@ -746,6 +746,8 @@ static int
>> >> >> drm_atomic_connector_set_property(struct
>> >> >drm_connector *connector,
>> >> >>return -EINVAL;
>> >> >>}
>> >> >>state->content_protection = val;
>> >> >> + } else if (property == connector->colorspace_property) {
>> >> >> + state->colorspace = val;
>> >> >>} else if (property == config->writeback_fb_id_property) {
>> >> >>struct drm_framebuffer *fb =
>drm_framebuffer_lookup(dev,
>> >> >NULL, val);
>> >> >>int ret =
>drm_atomic_set_writeback_fb_for_connector(state,
>> >> >fb); @@
>> >> >> -814,
Re: [Intel-gfx] [PATCH 13/13] drm/i915: Remove the fragile array index -> link rate mapping
On Thu, Feb 07, 2019 at 03:11:59PM -0800, Lucas De Marchi wrote:
> On Thu, Feb 7, 2019 at 9:33 AM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > Rather than try to maintain some magic relationship between the link
> > rates and the index into the wrpll params array let's just store
> > the link rate in the array itself. Much less fragile.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_dpll_mgr.c | 136 +-
> > 1 file changed, 68 insertions(+), 68 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > index 78dd28aa123c..9aacd19aede1 100644
> > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > @@ -2417,47 +2417,69 @@ static const struct intel_dpll_mgr cnl_pll_mgr = {
> > .dump_hw_state = cnl_dump_hw_state,
> > };
> >
> > +struct icl_combo_pll_params {
> > + int clock;
>
> isn't clock confusing here since we have the reference clock and here
> is the link rate?
This is PLL code. There is no such thing as link rate in a PLL.
>
> > + struct skl_wrpll_params wrpll;
>
> humn... since we will look for the clock to lookup the entry, we could
> go one step further and
> join the 2 tables:
>
> struct icl_combo_pll_params {
>int clock;
>struct skl_wrpll_params wrpll[2];
> };
That would add another magic array index. Which wouldn't be consistent
with the tbt pll params. We'd have to add some kind of enum for the
index and the convert all of these. I certainly don't care enough to
do that myself.
>
> > +};
> > +
> > /*
> > * These values alrea already adjusted: they're the bits we write to the
> > * registers, not the logical values.
> > */
> > -static const struct skl_wrpll_params icl_dp_combo_pll_24MHz_values[] = {
> > - { .dco_integer = 0x151, .dco_fraction = 0x4000, /* [0]: 5.4
> > */
> > - .pdiv = 0x2 /* 3 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0},
> > - { .dco_integer = 0x151, .dco_fraction = 0x4000, /* [1]: 2.7
> > */
> > - .pdiv = 0x2 /* 3 */, .kdiv = 2, .qdiv_mode = 0, .qdiv_ratio = 0},
> > - { .dco_integer = 0x151, .dco_fraction = 0x4000, /* [2]:
> > 1.62 */
> > - .pdiv = 0x4 /* 5 */, .kdiv = 2, .qdiv_mode = 0, .qdiv_ratio = 0},
> > - { .dco_integer = 0x151, .dco_fraction = 0x4000, /* [3]:
> > 3.24 */
> > - .pdiv = 0x4 /* 5 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0},
> > - { .dco_integer = 0x168, .dco_fraction = 0x, /* [4]:
> > 2.16 */
> > - .pdiv = 0x1 /* 2 */, .kdiv = 2, .qdiv_mode = 1, .qdiv_ratio = 2},
> > - { .dco_integer = 0x168, .dco_fraction = 0x, /* [5]:
> > 4.32 */
> > - .pdiv = 0x1 /* 2 */, .kdiv = 2, .qdiv_mode = 0, .qdiv_ratio = 0},
> > - { .dco_integer = 0x195, .dco_fraction = 0x, /* [6]:
> > 6.48 */
> > - .pdiv = 0x2 /* 3 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0},
> > - { .dco_integer = 0x151, .dco_fraction = 0x4000, /* [7]: 8.1
> > */
> > - .pdiv = 0x1 /* 2 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio = 0},
> > +static const struct icl_combo_pll_params icl_dp_combo_pll_24MHz_values[] =
> > {
> > + { 54,
> > + { .dco_integer = 0x151, .dco_fraction = 0x4000, /*
> > [0]: 5.4 */
> > + .pdiv = 0x2 /* 3 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio =
> > 0, }, },
>
> I'm almost always for designated initializer, but in this table that
> comes directly from spec, wouldn't
> be easier to read by skipping the initializer and just aligning the
> numbers? IMO the lines below seem
> easier to read:
>
> static const struct skl_wrpll_params icl_dp_combo_pll_24MHz_values[] = {
> /* clock, dco_int, dco_frac, kdiv, qdiv_mode, qdiv_ratio */
> { 5400, { 0x151,0x4000,1,0, 0 } },
> ...
> }
With the comment it might be OK. But it'll certainly cause cscope to
miss stuff if you look for eg. qdiv_mode by name. So not sure if it's
better or worse tbh.
>
> Lucas De Marchi
>
> > + { 27,
> > + { .dco_integer = 0x151, .dco_fraction = 0x4000, /*
> > [1]: 2.7 */
> > + .pdiv = 0x2 /* 3 */, .kdiv = 2, .qdiv_mode = 0, .qdiv_ratio =
> > 0, }, },
> > + { 162000,
> > + { .dco_integer = 0x151, .dco_fraction = 0x4000, /*
> > [2]: 1.62 */
> > + .pdiv = 0x4 /* 5 */, .kdiv = 2, .qdiv_mode = 0, .qdiv_ratio =
> > 0, }, },
> > + { 324000,
> > + { .dco_integer = 0x151, .dco_fraction = 0x4000, /*
> > [3]: 3.24 */
> > + .pdiv = 0x4 /* 5 */, .kdiv = 1, .qdiv_mode = 0, .qdiv_ratio =
> > 0, }, },
> > + { 216000,
> > + { .dco_integer = 0x168, .dco_fraction = 0x, /*
> > [4]: 2.16 */
> > + .pdiv = 0x1 /* 2 */, .kdiv = 2, .qdiv_mode = 1, .qdiv_ratio =
>
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_scheduler: Disable alarm before exiting child
Quoting Chris Wilson (2019-02-08 13:41:09)
> Still the blighted
>
> Starting subtest: pi-ringfull-bsd
> child 0 died with signal 14, Alarm clock
> Subtest pi-ringfull-bsd: FAIL (0.133s)
>
> So let's make sure our timer cannot fire later on during exit.
This starts to reek like broken libc.
The patch below is just next level of paranoia, so:
Reviewed-by: Joonas Lahtinen
Regards, Joonas
>
> References https://bugs.freedesktop.org/show_bug.cgi?id=109584
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> ---
> tests/i915/gem_exec_schedule.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
> index d11e57363..00f9528a3 100644
> --- a/tests/i915/gem_exec_schedule.c
> +++ b/tests/i915/gem_exec_schedule.c
> @@ -1153,7 +1153,9 @@ static void test_pi_ringfull(int fd, unsigned int
> engine)
> bind_to_cpu(0);
>
> igt_fork(child, 1) {
> - result[0] = true;
> + int err;
> +
> + result[0] = vip != execbuf.rsvd1;
>
> igt_debug("Waking parent\n");
> kill(getppid(), SIGALRM);
> @@ -1170,12 +1172,18 @@ static void test_pi_ringfull(int fd, unsigned int
> engine)
> */
> igt_debug("HP child executing\n");
> execbuf.rsvd1 = vip;
> - result[2] = __execbuf(fd, &execbuf) == 0;
> + err = __execbuf(fd, &execbuf);
> + igt_debug("HP execbuf returned %d\n", err);
> +
> + memset(&itv, 0, sizeof(itv));
> + setitimer(ITIMER_REAL, &itv, NULL);
> +
> + result[2] = err == 0;
> }
>
> /* Relinquish CPU just to allow child to create a context */
> sleep(1);
> - igt_assert_f(result[0], "HP context (child) not created");
> + igt_assert_f(result[0], "HP context (child) not created\n");
> igt_assert_f(!result[1], "Child released too early!\n");
>
> /* Parent sleeps waiting for ringspace, releasing child */
> --
> 2.20.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
Regards Shashank > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Shankar, Uma > Sent: Friday, February 8, 2019 5:45 PM > To: Ville Syrjälä > Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville > ; dri- > de...@lists.freedesktop.org; Lankhorst, Maarten > Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property > > >> >> >-Original Message- > >> >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > >> >> >Sent: Tuesday, February 5, 2019 10:02 PM > >> >> >To: Shankar, Uma > >> >> >Cc: intel-gfx@lists.freedesktop.org; > >> >> >dri-de...@lists.freedesktop.org; Syrjala, Ville > >> >> >; Lankhorst, Maarten > >> >> > > >> >> >Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace > >> >> >property > >> >> > > >> >> >On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote: > >> >> >> Create a new connector property to program colorspace to sink > >> >> >> devices. > >> >> >> Modern sink devices support more than 1 type of colorspace like > >> >> >> 601, 709, BT2020 etc. This helps to switch based on content > >> >> >> type which is to be displayed. The decision lies with > >> >> >> compositors as to in which scenarios, a particular colorspace will > >> >> >> be picked. > >> >> >> > >> >> >> This will be helpful mostly to switch to higher gamut > >> >> >> colorspaces like > >> >> >> BT2020 when the media content is encoded as BT2020. Thereby > >> >> >> giving a good visual experience to users. > >> >> >> > >> >> >> The expectation from userspace is that it should parse the EDID > >> >> >> and get supported colorspaces. Use this property and switch to > >> >> >> the one supported. Sink supported colorspaces should be > >> >> >> retrieved by userspace from EDID and driver will not explicitly > >> >> >> expose > >them. > >> >> >> > >> >> >> Basically the expectation from userspace is: > >> >> >> - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink > >> >> >>colorspace > >> >> >> - Set this new property to let the sink know what it > >> >> >>converted the CRTC output to. > >> >> >> > >> >> >> v2: Addressed Maarten and Ville's review comments. Enhanced the > >> >> >> colorspace enum to incorporate both HDMI and DP supported > >colorspaces. > >> >> >> Also, added a default option for colorspace. > >> >> >> > >> >> >> v3: Removed Adobe references from enum definitions as per > >> >> >> Ville, Hans Verkuil and Jonas Karlman suggestions. Changed > >> >> >> Default to an unset state where driver will assign the > >> >> >> colorspace is not chosen by user, suggested by Ville and > >> >> >> Maarten. Addressed other misc review comments from Maarten. > >> >> >> Split the changes to have separate colorspace property for DP and > >> >> >> HDMI. > >> >> >> > >> >> >> v4: Addressed Chris and Ville's review comments, and created a > >> >> >> common colorspace property for DP and HDMI, filtered the list > >> >> >> based on the colorspaces supported by the respective protocol > >> >> >> standard. > >> >> >> > >> >> >> v5: Made the property creation helper accept enum list based on > >> >> >> platform capabilties as suggested by Shashank. Consolidated > >> >> >> HDMI and DP property creation in the common helper. > >> >> >> > >> >> >> v6: Addressed Shashank's review comments. > >> >> >> > >> >> >> v7: Added defines instead of enum in uapi as per Brian > >> >> >> Starkey's suggestion in order to go with string matching at > >> >> >> userspace. > >> >> >> Updated the commit message to add more details as well kernel docs. > >> >> >> > >> >> >> v8: Addressed Maarten's review comments. > >> >> >> > >> >> >> v9: Removed macro defines from uapi as per Brian Starkey and > >> >> >> Daniel Stone's comments and moved to drm include file. Moved > >> >> >> back to older design with exposing all HDMI colorspaces to > >> >> >> userspace since infoframe capability is there even on legacy > >> >> >> platforms, as per Ville's review comments. > >> >> >> > >> >> >> v10: Fixed sparse warnings, updated the RB from Maarten and Jani's > >> >> >> ack. > >> >> >> > >> >> >> v11: Addressed Ville's review comments. Updated the Macro > >> >> >> naming and added DCI-P3 colorspace as well defined in CEA 861.G spec. > >> >> >> > >> >> >> Signed-off-by: Uma Shankar > >> >> >> Acked-by: Jani Nikula > >> >> >> Reviewed-by: Shashank Sharma > >> >> >> Reviewed-by: Maarten Lankhorst > >> >> >> > >> >> >> --- > >> >> >> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ > >> >> >> drivers/gpu/drm/drm_connector.c | 78 > >> >> >+++ > >> >> >> include/drm/drm_connector.h | 50 + > >> >> >> 3 files changed, 132 insertions(+) > >> >> >> > >> >> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c > >> >> >> b/drivers/gpu/drm/drm_atomic_uapi.c > >> >> >> index 9a1f41a..9b5d44f 100644 > >> >> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c > >> >> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c > >> >>
[Intel-gfx] [PATCH 2/3] drm/i915/opregion: rvda is relative from opregion base in opregion 2.1+
Starting from opregion version 2.1 (roughly corresponding to ICL+) the
RVDA field is relative from the beginning of opregion, not absolute
address.
Fix the error path while at it.
v2: Make relative vs. absolute conditional on the opregion version,
bumped for the purpose. Turned out there are machines relying on
absolute RVDA in the wild.
Fixes: 04ebaadb9f2d ("drm/i915/opregion: handle VBT sizes bigger than 6 KB")
Cc: Ville Syrjälä
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_opregion.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 7e4152d97c45..c7d523da6631 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -121,7 +121,8 @@ struct opregion_asle {
u64 fdss;
u32 fdsp;
u32 stat;
- u64 rvda; /* Physical address of raw vbt data */
+ u64 rvda; /* Physical (2.0) or relative from opregion (2.1+)
+* address of raw VBT data. */
u32 rvds; /* Size of raw vbt data */
u8 rsvd[58];
} __packed;
@@ -961,9 +962,24 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
if (opregion->header->opregion_ver >= OPREGION_VERSION(2, 0) &&
opregion->asle && opregion->asle->rvda && opregion->asle->rvds) {
- opregion->rvda = memremap(opregion->asle->rvda,
- opregion->asle->rvds,
+
+ resource_size_t rvda = opregion->asle->rvda;
+
+ /*
+* opregion 2.0: rvda is the physical VBT address.
+*
+* opregion 2.1+: rvda is unsigned, relative offset from
+* opregion base, and should never point within opregion.
+*/
+ if (opregion->header->opregion_ver >= OPREGION_VERSION(2, 1)) {
+ WARN_ON(rvda < OPREGION_SIZE);
+
+ rvda += asls;
+ }
+
+ opregion->rvda = memremap(rvda, opregion->asle->rvds,
MEMREMAP_WB);
+
vbt = opregion->rvda;
vbt_size = opregion->asle->rvds;
if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
@@ -973,6 +989,8 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
goto out;
} else {
DRM_DEBUG_KMS("Invalid VBT in ACPI OpRegion (RVDA)\n");
+ memunmap(opregion->rvda);
+ opregion->rvda = NULL;
}
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/opregion: fix version check
The u32 version field encodes major version in the high word. We've been
checking for version >= 0.2.
Add opregion version logging while at it.
Fixes: 04ebaadb9f2d ("drm/i915/opregion: handle VBT sizes bigger than 6 KB")
Cc: Ville Syrjälä
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_opregion.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 30ae96c5c97c..7e4152d97c45 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -46,6 +46,9 @@
#define OPREGION_ASLE_EXT_OFFSET 0x1C00
#define OPREGION_SIGNATURE "IntelGraphicsMem"
+
+#define OPREGION_VERSION(major, minor) (((major) << 16) | (minor))
+
#define MBOX_ACPI (1<<0)
#define MBOX_SWSCI (1<<1)
#define MBOX_ASLE (1<<2)
@@ -924,6 +927,10 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
opregion->header = base;
opregion->lid_state = base + ACPI_CLID;
+ DRM_DEBUG_DRIVER("ACPI OpRegion version %u.%u\n",
+opregion->header->opregion_ver >> 16,
+opregion->header->opregion_ver & 0x);
+
mboxes = opregion->header->mboxes;
if (mboxes & MBOX_ACPI) {
DRM_DEBUG_DRIVER("Public ACPI methods supported\n");
@@ -952,8 +959,8 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
if (dmi_check_system(intel_no_opregion_vbt))
goto out;
- if (opregion->header->opregion_ver >= 2 && opregion->asle &&
- opregion->asle->rvda && opregion->asle->rvds) {
+ if (opregion->header->opregion_ver >= OPREGION_VERSION(2, 0) &&
+ opregion->asle && opregion->asle->rvda && opregion->asle->rvds) {
opregion->rvda = memremap(opregion->asle->rvda,
opregion->asle->rvds,
MEMREMAP_WB);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] HACK: drm/i915/opregion: ICL should have opregion 2.1+ and relative rvda
Temporary CI workaround before proper opregion version bump propagates
to the machines.
Cc: Ville Syrjälä
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_opregion.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index c7d523da6631..e90be277ac21 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -971,7 +971,8 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
* opregion 2.1+: rvda is unsigned, relative offset from
* opregion base, and should never point within opregion.
*/
- if (opregion->header->opregion_ver >= OPREGION_VERSION(2, 1)) {
+ if (opregion->header->opregion_ver >= OPREGION_VERSION(2, 1) ||
+ IS_ICELAKE(dev_priv)) {
WARN_ON(rvda < OPREGION_SIZE);
rvda += asls;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
On Fri, Feb 08, 2019 at 12:36:25PM +, Sharma, Shashank wrote: > Regards > Shashank > > > -Original Message- > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > > Of > > Shankar, Uma > > Sent: Friday, February 8, 2019 5:45 PM > > To: Ville Syrjälä > > Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville > > ; dri- > > de...@lists.freedesktop.org; Lankhorst, Maarten > > > > Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property > > > > >> >> >-Original Message- > > >> >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > > >> >> >Sent: Tuesday, February 5, 2019 10:02 PM > > >> >> >To: Shankar, Uma > > >> >> >Cc: intel-gfx@lists.freedesktop.org; > > >> >> >dri-de...@lists.freedesktop.org; Syrjala, Ville > > >> >> >; Lankhorst, Maarten > > >> >> > > > >> >> >Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace > > >> >> >property > > >> >> > > > >> >> >On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote: > > >> >> >> Create a new connector property to program colorspace to sink > > >> >> >> devices. > > >> >> >> Modern sink devices support more than 1 type of colorspace like > > >> >> >> 601, 709, BT2020 etc. This helps to switch based on content > > >> >> >> type which is to be displayed. The decision lies with > > >> >> >> compositors as to in which scenarios, a particular colorspace will > > >> >> >> be picked. > > >> >> >> > > >> >> >> This will be helpful mostly to switch to higher gamut > > >> >> >> colorspaces like > > >> >> >> BT2020 when the media content is encoded as BT2020. Thereby > > >> >> >> giving a good visual experience to users. > > >> >> >> > > >> >> >> The expectation from userspace is that it should parse the EDID > > >> >> >> and get supported colorspaces. Use this property and switch to > > >> >> >> the one supported. Sink supported colorspaces should be > > >> >> >> retrieved by userspace from EDID and driver will not explicitly > > >> >> >> expose > > >them. > > >> >> >> > > >> >> >> Basically the expectation from userspace is: > > >> >> >> - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink > > >> >> >>colorspace > > >> >> >> - Set this new property to let the sink know what it > > >> >> >>converted the CRTC output to. > > >> >> >> > > >> >> >> v2: Addressed Maarten and Ville's review comments. Enhanced the > > >> >> >> colorspace enum to incorporate both HDMI and DP supported > > >colorspaces. > > >> >> >> Also, added a default option for colorspace. > > >> >> >> > > >> >> >> v3: Removed Adobe references from enum definitions as per > > >> >> >> Ville, Hans Verkuil and Jonas Karlman suggestions. Changed > > >> >> >> Default to an unset state where driver will assign the > > >> >> >> colorspace is not chosen by user, suggested by Ville and > > >> >> >> Maarten. Addressed other misc review comments from Maarten. > > >> >> >> Split the changes to have separate colorspace property for DP and > > >> >> >> HDMI. > > >> >> >> > > >> >> >> v4: Addressed Chris and Ville's review comments, and created a > > >> >> >> common colorspace property for DP and HDMI, filtered the list > > >> >> >> based on the colorspaces supported by the respective protocol > > >> >> >> standard. > > >> >> >> > > >> >> >> v5: Made the property creation helper accept enum list based on > > >> >> >> platform capabilties as suggested by Shashank. Consolidated > > >> >> >> HDMI and DP property creation in the common helper. > > >> >> >> > > >> >> >> v6: Addressed Shashank's review comments. > > >> >> >> > > >> >> >> v7: Added defines instead of enum in uapi as per Brian > > >> >> >> Starkey's suggestion in order to go with string matching at > > >> >> >> userspace. > > >> >> >> Updated the commit message to add more details as well kernel docs. > > >> >> >> > > >> >> >> v8: Addressed Maarten's review comments. > > >> >> >> > > >> >> >> v9: Removed macro defines from uapi as per Brian Starkey and > > >> >> >> Daniel Stone's comments and moved to drm include file. Moved > > >> >> >> back to older design with exposing all HDMI colorspaces to > > >> >> >> userspace since infoframe capability is there even on legacy > > >> >> >> platforms, as per Ville's review comments. > > >> >> >> > > >> >> >> v10: Fixed sparse warnings, updated the RB from Maarten and Jani's > > >> >> >> ack. > > >> >> >> > > >> >> >> v11: Addressed Ville's review comments. Updated the Macro > > >> >> >> naming and added DCI-P3 colorspace as well defined in CEA 861.G > > >> >> >> spec. > > >> >> >> > > >> >> >> Signed-off-by: Uma Shankar > > >> >> >> Acked-by: Jani Nikula > > >> >> >> Reviewed-by: Shashank Sharma > > >> >> >> Reviewed-by: Maarten Lankhorst > > >> >> >> > > >> >> >> --- > > >> >> >> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ > > >> >> >> drivers/gpu/drm/drm_connector.c | 78 > > >> >> >+++ > > >> >> >> include/drm/drm_connector.h | 50 + > > >> >> >> 3
Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
Regards
Shashank
On 2/8/2019 6:22 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 12:36:25PM +, Sharma, Shashank wrote:
Regards
Shashank
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Shankar, Uma
Sent: Friday, February 8, 2019 5:45 PM
To: Ville Syrjälä
Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville ;
dri-
de...@lists.freedesktop.org; Lankhorst, Maarten
Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Tuesday, February 5, 2019 10:02 PM
To: Shankar, Uma
Cc: intel-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org; Syrjala, Ville
; Lankhorst, Maarten
Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace
property
On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote:
Create a new connector property to program colorspace to sink devices.
Modern sink devices support more than 1 type of colorspace like
601, 709, BT2020 etc. This helps to switch based on content
type which is to be displayed. The decision lies with
compositors as to in which scenarios, a particular colorspace will be picked.
This will be helpful mostly to switch to higher gamut
colorspaces like
BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to
the one supported. Sink supported colorspaces should be
retrieved by userspace from EDID and driver will not explicitly
expose
them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced the
colorspace enum to incorporate both HDMI and DP supported
colorspaces.
Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the
colorspace is not chosen by user, suggested by Ville and
Maarten. Addressed other misc review comments from Maarten.
Split the changes to have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated
HDMI and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian
Starkey's suggestion in order to go with string matching at userspace.
Updated the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and
Daniel Stone's comments and moved to drm include file. Moved
back to older design with exposing all HDMI colorspaces to
userspace since infoframe capability is there even on legacy
platforms, as per Ville's review comments.
v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v11: Addressed Ville's review comments. Updated the Macro
naming and added DCI-P3 colorspace as well defined in CEA 861.G spec.
Signed-off-by: Uma Shankar
Acked-by: Jani Nikula
Reviewed-by: Shashank Sharma
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 78
+++
include/drm/drm_connector.h | 50 +
3 files changed, 132 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9a1f41a..9b5d44f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int
drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == connector->colorspace_property) {
+ state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb =
drm_framebuffer_lookup(dev,
NULL, val);
int ret =
drm_atomic_set_writeback_fb_for_connector(state,
fb); @@
-814,6 +816,8 @@ static int
drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == connector->colorspace_property) {
+ *val = state->co
Re: [Intel-gfx] Fixes that failed to apply to v5.0-rc5
On Tue, Feb 05, 2019 at 03:42:05PM +0200, Jani Nikula wrote:
>
> The following commits have been marked as Cc: stable or fixing something
> in v5.0-rc5 or earlier, but failed to cherry-pick to
> drm-intel-fixes. Please see if they are worth backporting, and please do
> so if they are.
>
> Failed to cherry-pick:
> b14c06ec0249 ("drm/i915/cnl: Fix CNL macros for Voltage Swing programming")
b14c06ec0249 is dependent on
265a2a6255f5 drm/i915/icl: combo port vswing programming changes per BSPEC
https://patchwork.freedesktop.org/patch/268514/
How should I go about the backport to drm-intel-fixes?
> 32db0b6501d9 ("drm/i915: Don't try to use the hardware frame counter with
> i965gm TV output")
>
> Cherry-pick fine but fail to build:
> 7bed8adcd9f8 ("drm/i915: Try to sanitize bogus DPLL state left over by broken
> SNB BIOSen")
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Regards,
Aditya Swarup
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
On Fri, Feb 08, 2019 at 06:36:39PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > On 2/8/2019 6:22 PM, Ville Syrjälä wrote: > > On Fri, Feb 08, 2019 at 12:36:25PM +, Sharma, Shashank wrote: > >> Regards > >> Shashank > >> > >>> -Original Message- > >>> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On > >>> Behalf Of > >>> Shankar, Uma > >>> Sent: Friday, February 8, 2019 5:45 PM > >>> To: Ville Syrjälä > >>> Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville > >>> ; dri- > >>> de...@lists.freedesktop.org; Lankhorst, Maarten > >>> > >>> Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property > >>> > -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Tuesday, February 5, 2019 10:02 PM > To: Shankar, Uma > Cc: intel-gfx@lists.freedesktop.org; > dri-de...@lists.freedesktop.org; Syrjala, Ville > ; Lankhorst, Maarten > > Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace > property > > On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote: > > Create a new connector property to program colorspace to sink > > devices. > > Modern sink devices support more than 1 type of colorspace like > > 601, 709, BT2020 etc. This helps to switch based on content > > type which is to be displayed. The decision lies with > > compositors as to in which scenarios, a particular colorspace will > > be picked. > > > > This will be helpful mostly to switch to higher gamut > > colorspaces like > > BT2020 when the media content is encoded as BT2020. Thereby > > giving a good visual experience to users. > > > > The expectation from userspace is that it should parse the EDID > > and get supported colorspaces. Use this property and switch to > > the one supported. Sink supported colorspaces should be > > retrieved by userspace from EDID and driver will not explicitly > > expose > them. > > Basically the expectation from userspace is: > > - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink > > colorspace > > - Set this new property to let the sink know what it > > converted the CRTC output to. > > > > v2: Addressed Maarten and Ville's review comments. Enhanced the > > colorspace enum to incorporate both HDMI and DP supported > colorspaces. > > Also, added a default option for colorspace. > > > > v3: Removed Adobe references from enum definitions as per > > Ville, Hans Verkuil and Jonas Karlman suggestions. Changed > > Default to an unset state where driver will assign the > > colorspace is not chosen by user, suggested by Ville and > > Maarten. Addressed other misc review comments from Maarten. > > Split the changes to have separate colorspace property for DP and > > HDMI. > > > > v4: Addressed Chris and Ville's review comments, and created a > > common colorspace property for DP and HDMI, filtered the list > > based on the colorspaces supported by the respective protocol > > standard. > > > > v5: Made the property creation helper accept enum list based on > > platform capabilties as suggested by Shashank. Consolidated > > HDMI and DP property creation in the common helper. > > > > v6: Addressed Shashank's review comments. > > > > v7: Added defines instead of enum in uapi as per Brian > > Starkey's suggestion in order to go with string matching at > > userspace. > > Updated the commit message to add more details as well kernel docs. > > > > v8: Addressed Maarten's review comments. > > > > v9: Removed macro defines from uapi as per Brian Starkey and > > Daniel Stone's comments and moved to drm include file. Moved > > back to older design with exposing all HDMI colorspaces to > > userspace since infoframe capability is there even on legacy > > platforms, as per Ville's review comments. > > > > v10: Fixed sparse warnings, updated the RB from Maarten and Jani's > > ack. > > > > v11: Addressed Ville's review comments. Updated the Macro > > naming and added DCI-P3 colorspace as well defined in CEA 861.G > > spec. > > > > Signed-off-by: Uma Shankar > > Acked-by: Jani Nikula > > Reviewed-by: Shashank Sharma > > Reviewed-by: Maarten Lankhorst > > > > --- > > drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ > > drivers/gpu/drm/drm_connector.c | 78 > +++ >
Re: [Intel-gfx] [IGT 1/2] tools/intel_gpu_top: Add support for stdout logging
Hi,
On 8.2.2019 14.03, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Two new output modes are added: listing of text data to standard out (-l
on the command line), and dumping of JSON formatted records (-J), also to
standard out.
The first mode is selected automatically when non-interactive standard out
is detected.
Example of text output:
Freq MHz IRQ RC6 Power IMC MiB/s RCS/0 BCS/0
VCS/0 VCS/1 VECS/0
req act /s % W rd wr % se wa % se wa
% se wa % se wa % se wa
000 0 0.00360 00.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
350 3500 100 0.00 35 20.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
350 3500 100 0.00 34 20.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
350 3500 100 0.00143 60.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
350 3500 100 0.00169 70.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
350 3500 100 0.00169 70.00 0 00.00 0 0
0.00 0 00.00 0 00.00 0 0
Looks nice!
If you add '#' to the start of the header lines, one could use something
like the attached shell script to convert the saved output to SVG graphs
with GnuPlot.
Before including the script to igt, it would need to be modified to
adapt to the number of engines, but maybe intel_gpu_top itself could
generate the gnuplot control file when it exits, if given e.g. --gnuplot
argument?
- Eero
Example of JSON output:
{
"period": {
"duration": 1002.525224,
"unit": "ms"
},
"frequency": {
"requested": 349.118398,
"actual": 349.118398,
"unit": "MHz"
},
"interrupts": {
"count": 0.00,
"unit": "irq/s"
},
"rc6": {
"value": 99.897752,
"unit": "%"
},
"power": {
"value": 0.00,
"unit": "W"
},
"imc-bandwidth": {
"reads": 149.683843,
"writes": 6.104093,
"unit": "MiB/s"
},
"engines": {
"Render/3D/0": {
"busy": 0.00,
"sema": 0.00,
"wait": 0.00,
"unit": "%"
},
"Blitter/0": {
"busy": 0.00,
"sema": 0.00,
"wait": 0.00,
"unit": "%"
},
"Video/0": {
"busy": 0.00,
"sema": 0.00,
"wait": 0.00,
"unit": "%"
},
"Video/1": {
"busy": 0.00,
"sema": 0.00,
"wait": 0.00,
"unit": "%"
},
"VideoEnhance/0": {
"busy": 0.00,
"sema": 0.00,
"wait": 0.00,
"unit": "%"
}
}
}
v2:
* Show example output in commit message.
* Install signal handler to complete output on SIGINT. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
References: https://bugs.freedesktop.org/show_bug.cgi?id=108689
Cc: Eero Tamminen
Cc: 3.1...@ukr.net
Cc: Chris Wilson
---
man/intel_gpu_top.rst | 9 +-
tools/intel_gpu_top.c | 761 +++---
2 files changed, 650 insertions(+), 120 deletions(-)
diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index 19c712307d28..d5bda093c8e8 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -7,9 +7,9 @@ Display a top-like summary of Intel GPU usage
-
.. include:: defs.rst
:Author: IGT Developers
-:Date: 2018-04-04
+:Date: 2019-02-08
:Version: |PACKAGE_STRING|
-:Copyright: 2009,2011,2012,2016,2018 Intel Corporation
+:Copyright: 2009,2011,2012,2016,2018,2019 Intel Corporation
:Manual section: |MANUAL_SECTION|
:Manual group: |MANUAL_GROUP|
@@ -31,6 +31,11 @@ OPTIONS
-s
Refresh period in milliseconds.
+-l
+List text data to standard out.
+
+-J
+Output JSON formatted data to standard output.
-h
Show help text.
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index b923c3cfbe97..807d518aaf87 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -1,
[Intel-gfx] [PATCH] drm/i915: Protect i915_active iterators from the shrinker
If we allocate while iterating the rbtree of active nodes, we may hit
the shrinker and so retire the i915_active reap the rbtree. Modifying
the rbtree as we iterate is not good behaviour, so acquire the
i915_active first to keep the tree intact whenever we allocate.
Fixes: a42375af0a30 ("drm/i915: Release the active tracker tree upon idling")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_active.c | 36 +-
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index 215b6ff8aa73..db7bb5bd5add 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -163,17 +163,25 @@ int i915_active_ref(struct i915_active *ref,
struct i915_request *rq)
{
struct i915_active_request *active;
+ int err = 0;
+
+ /* Prevent reaping in case we malloc/wait while building the tree */
+ i915_active_acquire(ref);
active = active_instance(ref, timeline);
- if (IS_ERR(active))
- return PTR_ERR(active);
+ if (IS_ERR(active)) {
+ err = PTR_ERR(active);
+ goto out;
+ }
if (!i915_active_request_isset(active))
ref->count++;
__i915_active_request_set(active, rq);
GEM_BUG_ON(!ref->count);
- return 0;
+out:
+ i915_active_release(ref);
+ return err;
}
bool i915_active_acquire(struct i915_active *ref)
@@ -223,19 +231,25 @@ int i915_request_await_active_request(struct i915_request
*rq,
int i915_request_await_active(struct i915_request *rq, struct i915_active *ref)
{
struct active_node *it, *n;
- int ret;
+ int err = 0;
- ret = i915_request_await_active_request(rq, &ref->last);
- if (ret)
- return ret;
+ /* await allocates and so we need to avoid hitting the shrinker */
+ if (i915_active_acquire(ref))
+ goto out; /* was idle */
+
+ err = i915_request_await_active_request(rq, &ref->last);
+ if (err)
+ goto out;
rbtree_postorder_for_each_entry_safe(it, n, &ref->tree, node) {
- ret = i915_request_await_active_request(rq, &it->base);
- if (ret)
- return ret;
+ err = i915_request_await_active_request(rq, &it->base);
+ if (err)
+ goto out;
}
- return 0;
+out:
+ i915_active_release(ref);
+ return err;
}
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915: preparations for enabling P010, P012, P016 formats
From: Juha-Pekka Heikkila
Preparations for enabling P010, P012 and P016 formats. These
formats will extend NV12 for larger bit depths.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 27 +--
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 14 +++---
drivers/gpu/drm/i915/intel_sprite.c | 22 +++---
5 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index db09659..dd6c096 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -135,7 +135,7 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
new_crtc_state->active_planes |= BIT(plane->id);
if (new_plane_state->base.visible &&
- new_plane_state->base.fb->format->format == DRM_FORMAT_NV12)
+ is_planar_yuv_format(new_plane_state->base.fb->format->format))
new_crtc_state->nv12_planes |= BIT(plane->id);
if (new_plane_state->base.visible || old_plane_state->base.visible)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ccb6163..0345d04 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2677,6 +2677,12 @@ int skl_format_to_fourcc(int format, bool rgb_order,
bool alpha)
return DRM_FORMAT_RGB565;
case PLANE_CTL_FORMAT_NV12:
return DRM_FORMAT_NV12;
+ case PLANE_CTL_FORMAT_P010:
+ return DRM_FORMAT_P010;
+ case PLANE_CTL_FORMAT_P012:
+ return DRM_FORMAT_P012;
+ case PLANE_CTL_FORMAT_P016:
+ return DRM_FORMAT_P016;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3176,7 +3182,7 @@ int skl_check_plane_surface(struct intel_plane_state
*plane_state)
* Handle the AUX surface first since
* the main surface setup depends on it.
*/
- if (fb->format->format == DRM_FORMAT_NV12) {
+ if (is_planar_yuv_format(fb->format->format)) {
ret = skl_check_nv12_aux_surface(plane_state);
if (ret)
return ret;
@@ -3600,6 +3606,12 @@ static u32 skl_plane_ctl_format(u32 pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+ case DRM_FORMAT_P010:
+ return PLANE_CTL_FORMAT_P010;
+ case DRM_FORMAT_P012:
+ return PLANE_CTL_FORMAT_P012;
+ case DRM_FORMAT_P016:
+ return PLANE_CTL_FORMAT_P016;
default:
MISSING_CASE(pixel_format);
}
@@ -5036,9 +5048,9 @@ u16 skl_scaler_calc_phase(int sub, int scale, bool
chroma_cosited)
return 0;
}
- if (format && format->format == DRM_FORMAT_NV12 &&
+ if (format && is_planar_yuv_format(format->format) &&
(src_h < SKL_MIN_YUV_420_SRC_H || src_w < SKL_MIN_YUV_420_SRC_W)) {
- DRM_DEBUG_KMS("NV12: src dimensions not met\n");
+ DRM_DEBUG_KMS("Planar YUV: src dimensions not met\n");
return -EINVAL;
}
@@ -5112,7 +5124,7 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
/* Pre-gen11 and SDR planes always need a scaler for planar formats. */
if (!icl_is_hdr_plane(intel_plane) &&
- fb && fb->format->format == DRM_FORMAT_NV12)
+ fb && is_planar_yuv_format(fb->format->format))
need_scaler = true;
ret = skl_update_scaler(crtc_state, force_detach,
@@ -5149,6 +5161,9 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_P010:
+ case DRM_FORMAT_P012:
+ case DRM_FORMAT_P016:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format
0x%x\n",
@@ -11134,7 +11149,7 @@ static int icl_check_nv12_planes(struct
intel_crtc_state *crtc_state)
}
if (!linked_state) {
- DRM_DEBUG_KMS("Need %d free Y planes for NV12\n",
+ DRM_DEBUG_KMS("Need %d free Y planes for planar YUV\n",
hweight8(crtc_state->nv12_planes));
return -EINVAL;
@@ -13767,7 +13782,7 @@ static void fb_obj_bump_render_priority(struct
drm_i915_gem_object *obj)
*or
*cdclk/crtc_clock
*/
- mult = pixel_format == DRM_FORMAT_NV12 ? 2 : 3;
+ mult = is_planar_yuv_format(pixel_format) ? 2
[Intel-gfx] [PATCH 2/7] drm/i915: Add P010, P012, P016 plane control definitions
From: Juha-Pekka Heikkila
Add needed plane control flag definitions for P010, P012 and
P016 formats.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 638a586..5d4cbe7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6557,8 +6557,11 @@ enum {
#define PLANE_CTL_FORMAT_YUV422 (0 << 24)
#define PLANE_CTL_FORMAT_NV12(1 << 24)
#define PLANE_CTL_FORMAT_XRGB_2101010(2 << 24)
+#define PLANE_CTL_FORMAT_P010(3 << 24)
#define PLANE_CTL_FORMAT_XRGB_ (4 << 24)
+#define PLANE_CTL_FORMAT_P012(5 << 24)
#define PLANE_CTL_FORMAT_XRGB_16161616F (6 << 24)
+#define PLANE_CTL_FORMAT_P016(7 << 24)
#define PLANE_CTL_FORMAT_AYUV(8 << 24)
#define PLANE_CTL_FORMAT_INDEXED (12 << 24)
#define PLANE_CTL_FORMAT_RGB_565 (14 << 24)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control definitions
From: Swati Sharma
Added needed plane control flag definitions for Y2xx and Y4xx (10, 12 and
16 bits)
Signed-off-by: Swati Sharma
Reviewed-by: Juha-Pekka Heikkila
---
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 5d4cbe7..cf80c5d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6567,6 +6567,12 @@ enum {
#define PLANE_CTL_FORMAT_RGB_565 (14 << 24)
#define ICL_PLANE_CTL_FORMAT_MASK(0x1f << 23)
#define PLANE_CTL_PIPE_CSC_ENABLE(1 << 23) /* Pre-GLK */
+#define PLANE_CTL_FORMAT_Y210 (1 << 23)
+#define PLANE_CTL_FORMAT_Y212 (3 << 23)
+#define PLANE_CTL_FORMAT_Y216 (5 << 23)
+#define PLANE_CTL_FORMAT_Y410 (7 << 23)
+#define PLANE_CTL_FORMAT_Y412 (9 << 23)
+#define PLANE_CTL_FORMAT_Y416 (0xb << 23)
#define PLANE_CTL_KEY_ENABLE_MASK(0x3 << 21)
#define PLANE_CTL_KEY_ENABLE_SOURCE (1 << 21)
#define PLANE_CTL_KEY_ENABLE_DESTINATION (2 << 21)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
From: Swati Sharma
The following pixel formats are packed format that follows 4:2:2
chroma sampling. For memory represenation each component is
allocated 16 bits each. Thus each pixel occupies 32bit.
Y210: For each component, valid data occupies MSB 10 bits.
LSB 6 bits are filled with zeroes.
Y212: For each component, valid data occupies MSB 12 bits.
LSB 4 bits are filled with zeroes.
Y216: For each component valid data occupies 16 bits,
doesn't require any padding bits.
First 16 bits stores the Y value and the next 16 bits stores one
of the chroma samples alternatively. The first luma sample will
be accompanied by first U sample and second luma sample is
accompanied by the first V sample.
The following pixel formats are packed format that follows 4:4:4
chroma sampling. Channels are arranged in the order UYVA in
increasing memory order.
Y410: Each color component occupies 10 bits and X component
takes 2 bits, thus each pixel occupies 32 bits.
Y412: Each color component is 16 bits where valid data
occupies MSB 12 bits. LSB 4 bits are filled with zeroes.
Thus, each pixel occupies 64 bits.
Y416: Each color component occupies 16 bits for valid data,
doesn't require any padding bits. Thus, each pixel
occupies 64 bits.
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/drm_fourcc.c | 6 ++
include/uapi/drm/drm_fourcc.h | 18 +-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index d45a3a4..16cbeea 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -229,6 +229,12 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
{ .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
{ .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_Y210,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y212,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y216,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y410,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y412,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y416,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y0L0,.depth = 0,
.num_planes = 1,
.char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
.hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 073bbea..5535669 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -151,7 +151,23 @@
#define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /*
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
-#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /*
[31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* [31:0]
X:Y:Cb:Cr 8:8:8:8 little endian */
+
+/*
+ * packed Y2xx indicate for each component, xx valid data occupy msb
+ * 16-xx padding occupy lsb
+ */
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian per 2 Y pixels */
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
Y0:x:Cb0:x:Y1:x:Cr1:x 12:4:12:4:12:4:12:4 little endian per 2 Y pixels */
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian per 2 Y pixels */
+
+/*
+ * packed Y4xx indicate for each component, xx valid data occupy msb
+ * 16-xx padding occupy lsb except Y410
+ */
+#define DRM_FORMAT_Y410 fourcc_code('Y', '4', '1', '0') /* [31:0]
X:V:Y:U 2:10:10:10 little endian */
+#define DRM_FORMAT_Y412 fourcc_code('Y', '4', '1', '2') /* [63:0]
X:x:V:x:Y:x:U:x 12:4:12:4:12:4:12:4 little endian */
+#define DRM_FORMAT_Y416 fourcc_code('Y', '4', '1', '6') /* [63:0]
X:V:Y:U
[Intel-gfx] [PATCH 7/7] drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for universal planes
From: Swati Sharma
In this patch, apart from enabling Y2xx and Y4xx pixel formats
P0xx pixel formats are added too for ICL.
Signed-off-by: Swati Sharma
Reviewed-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/intel_display.c | 30 ++
drivers/gpu/drm/i915/intel_sprite.c | 60 +++-
2 files changed, 89 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0345d04..dc1685c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2683,6 +2683,18 @@ int skl_format_to_fourcc(int format, bool rgb_order,
bool alpha)
return DRM_FORMAT_P012;
case PLANE_CTL_FORMAT_P016:
return DRM_FORMAT_P016;
+ case PLANE_CTL_FORMAT_Y210:
+ return DRM_FORMAT_Y210;
+ case PLANE_CTL_FORMAT_Y212:
+ return DRM_FORMAT_Y212;
+ case PLANE_CTL_FORMAT_Y216:
+ return DRM_FORMAT_Y216;
+ case PLANE_CTL_FORMAT_Y410:
+ return DRM_FORMAT_Y410;
+ case PLANE_CTL_FORMAT_Y412:
+ return DRM_FORMAT_Y412;
+ case PLANE_CTL_FORMAT_Y416:
+ return DRM_FORMAT_Y416;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3612,6 +3624,18 @@ static u32 skl_plane_ctl_format(u32 pixel_format)
return PLANE_CTL_FORMAT_P012;
case DRM_FORMAT_P016:
return PLANE_CTL_FORMAT_P016;
+ case DRM_FORMAT_Y210:
+ return PLANE_CTL_FORMAT_Y210;
+ case DRM_FORMAT_Y212:
+ return PLANE_CTL_FORMAT_Y212;
+ case DRM_FORMAT_Y216:
+ return PLANE_CTL_FORMAT_Y216;
+ case DRM_FORMAT_Y410:
+ return PLANE_CTL_FORMAT_Y410;
+ case DRM_FORMAT_Y412:
+ return PLANE_CTL_FORMAT_Y412;
+ case DRM_FORMAT_Y416:
+ return PLANE_CTL_FORMAT_Y416;
default:
MISSING_CASE(pixel_format);
}
@@ -5164,6 +5188,12 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_P010:
case DRM_FORMAT_P012:
case DRM_FORMAT_P016:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
+ case DRM_FORMAT_Y410:
+ case DRM_FORMAT_Y412:
+ case DRM_FORMAT_Y416:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format
0x%x\n",
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index a120266..af147e7 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1803,6 +1803,27 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device
*dev, void *data,
DRM_FORMAT_VYUY,
};
+static const uint32_t icl_plane_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_Y210,
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_Y216,
+ DRM_FORMAT_Y410,
+ DRM_FORMAT_Y412,
+ DRM_FORMAT_Y416,
+};
+
static const u32 skl_planar_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -1838,6 +1859,31 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device
*dev, void *data,
DRM_FORMAT_P016,
};
+static const uint32_t icl_planar_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_P010,
+ DRM_FORMAT_P012,
+ DRM_FORMAT_P016,
+ DRM_FORMAT_Y210,
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_Y216,
+ DRM_FORMAT_Y410,
+ DRM_FORMAT_Y412,
+ DRM_FORMAT_Y416,
+};
+
static const u64 skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1980,6 +2026,12 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_P010:
case DRM_FORMAT_P012:
case DRM_FORMAT_P016:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
+ case DRM_FORMAT_Y410:
+ case DRM_FORMAT_Y412:
+ case DRM_FORMAT_Y416:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
@@ -2120,13 +2172,19 @@ struct intel_plane *
plane->update_slave = icl_update_slave;
[Intel-gfx] [PATCH 4/7] drm/i915: enable P010, P012, P016 formats for primary and sprite planes
From: Juha-Pekka Heikkila
Enabling of P010, P012 and P016 formats. These formats will
extend NV12 for larger bit depths.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/intel_sprite.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index d4e436a..a120266 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1819,6 +1819,25 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device
*dev, void *data,
DRM_FORMAT_NV12,
};
+static const uint32_t glk_planar_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_P010,
+ DRM_FORMAT_P012,
+ DRM_FORMAT_P016,
+};
+
static const u64 skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -2101,8 +2120,13 @@ struct intel_plane *
plane->update_slave = icl_update_slave;
if (skl_plane_has_planar(dev_priv, pipe, plane_id)) {
- formats = skl_planar_formats;
- num_formats = ARRAY_SIZE(skl_planar_formats);
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
+ formats = glk_planar_formats;
+ num_formats = ARRAY_SIZE(glk_planar_formats);
+ } else {
+ formats = skl_planar_formats;
+ num_formats = ARRAY_SIZE(skl_planar_formats);
+ }
} else {
formats = skl_plane_formats;
num_formats = ARRAY_SIZE(skl_plane_formats);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm: Add P010, P012, P016 format definitions and fourcc
From: Juha-Pekka Heikkila
Add P010 definition, semi-planar yuv format where each component
is 16 bits 10 msb containing color value. First come Y plane [10:6]
followed by 2x2 subsampled Cr:Cb plane [10:6:10:6]
Add P012 definition, semi-planar yuv format where each component
is 16 bits 12 msb containing color value. First come Y plane [12:4]
followed by 2x2 subsampled Cr:Cb plane [12:4:12:4]
Add P016 definition, semi-planar yuv format where each component
is 16 bits. First come Y plane followed by 2x2 subsampled Cr:Cb
plane [16:16]
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 10 ++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index d90ee03..d45a3a4 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -226,6 +226,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_XYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
{ .format = DRM_FORMAT_Y0L0,.depth = 0,
.num_planes = 1,
.char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
.hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 93a341d..073bbea 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -196,6 +196,16 @@
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
+ * 2 plane YCbCr
+ * index 0 = Y plane, [15:0] Y little endian where Pxxx indicate
+ * component xxx msb Y [xxx:16-xxx]
+ * index 1 = Cr:Cb plane, [31:0] Cr:Cb little endian [xxx:16-xxx:xxx:16-xxx]
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane, 10 bit per channel */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cr:Cb plane, 12 bit per channel */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cr:Cb plane, 16 bit per channel */
+
+/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
* index 1: Cb plane, [7:0] Cb
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/7] Enable P0xx (planar), Y2xx and Y4xx (packed) pixel formats
From: Swati Sharma In this patch series, Juha Pekka's patch series for Gen10+ P0xx formats https://patchwork.freedesktop.org/series/56053/ is combined with Swati's https://patchwork.freedesktop.org/series/55035/ for Gen11+ pixel formats (Y2xx and Y4xx). P0xx pixel formats are enabled from GLK whereas Y2xx and Y4xx are enabled from ICL platform. These patches enable planar formats YUV420-P010, P012 and P016 (Intial 4 patches of Juha) for GLK+ platform and packed format YUV422-Y210, Y212 and Y216 and YUV444-Y410, Y412, Y416 for 10, 12 and 16 bits for ICL+ platforms. IGT validating all these pixel formats written by Maarten Lankhorst https://patchwork.freedesktop.org/patch/284508/ IGT needs libraries for pixman and cairo to support more than 8bpc. Need cairo >= 1.17.2 and pixman-1 >= 0.36.0. Tested with custom cairo and pixman. P0xx and Y2xx successfully validated for HDR planes, SDR planes having CRC mismatch (known bug for all YUV formats). IGT for Y410 and Y416 is alpha enabled whereas kernel patches are non-alpha; depending upon review comments will make changes either in IGT or kernel. TODO: IGT for Y412 yet to be written Juha-Pekka Heikkila (4): drm: Add P010, P012, P016 format definitions and fourcc drm/i915: Add P010, P012, P016 plane control definitions drm/i915: preparations for enabling P010, P012, P016 formats drm/i915: enable P010, P012, P016 formats for primary and sprite planes Swati Sharma (3): drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control definitions drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for universal planes drivers/gpu/drm/drm_fourcc.c | 9 +++ drivers/gpu/drm/i915/i915_reg.h | 9 +++ drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 57 ++-- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 14 ++-- drivers/gpu/drm/i915/intel_sprite.c | 108 -- include/uapi/drm/drm_fourcc.h | 28 +++- 8 files changed, 208 insertions(+), 20 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/2] drm/drv: Rework drm_dev_unplug() (was: Remove drm_dev_unplug())
This series makes drm_dev_unplug() compatible with the upcoming devm_drm_dev_init(), fixes a double drm_dev_unregister() situation and simplifies the drm_device ref handling wrt to the last fd closed after unregister. The first version of this patchset removed drm_dev_unplug(), see here for the discussion as to why it is kept for the time being: [2/6] drm/drv: Prepare to remove drm_dev_unplug() https://patchwork.freedesktop.org/patch/282902/ Noralf. Noralf Trønnes (2): drm: Fix drm_release() and device unplug drm/drv: drm_dev_unplug(): Move out drm_dev_put() call drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + drivers/gpu/drm/drm_drv.c | 5 - drivers/gpu/drm/drm_file.c | 6 ++ drivers/gpu/drm/udl/udl_drv.c | 1 + drivers/gpu/drm/xen/xen_drm_front.c | 1 + 5 files changed, 5 insertions(+), 9 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm: Fix drm_release() and device unplug
If userspace has open fd(s) when drm_dev_unplug() is run, it will result
in drm_dev_unregister() being called twice. First in drm_dev_unplug() and
then later in drm_release() through the call to drm_put_dev().
Since userspace already holds a ref on drm_device through the drm_minor,
it's not necessary to add extra ref counting based on no open file
handles. Instead just drm_dev_put() unconditionally in drm_dev_unplug().
We now have this:
- Userpace holds a ref on drm_device as long as there's open fd(s)
- The driver holds a ref on drm_device as long as it's bound to the
struct device
When both sides are done with drm_device, it is released.
Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
Reviewed-by: Daniel Vetter
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_drv.c | 6 +-
drivers/gpu/drm/drm_file.c | 6 ++
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 381581b01d48..05bbc2b622fc 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -376,11 +376,7 @@ void drm_dev_unplug(struct drm_device *dev)
synchronize_srcu(&drm_unplug_srcu);
drm_dev_unregister(dev);
-
- mutex_lock(&drm_global_mutex);
- if (dev->open_count == 0)
- drm_dev_put(dev);
- mutex_unlock(&drm_global_mutex);
+ drm_dev_put(dev);
}
EXPORT_SYMBOL(drm_dev_unplug);
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 46f48f245eb5..3f20f598cd7c 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -479,11 +479,9 @@ int drm_release(struct inode *inode, struct file *filp)
drm_file_free(file_priv);
- if (!--dev->open_count) {
+ if (!--dev->open_count)
drm_lastclose(dev);
- if (drm_dev_is_unplugged(dev))
- drm_put_dev(dev);
- }
+
mutex_unlock(&drm_global_mutex);
drm_minor_release(minor);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/drv: drm_dev_unplug(): Move out drm_dev_put() call
This makes it possible to use drm_dev_unplug() with the upcoming
devm_drm_dev_init() which will do drm_dev_put() in its release callback.
Cc: Alex Deucher
Cc: Christian König
Cc: David (ChunMing) Zhou
Cc: Dave Airlie
Cc: Sean Paul
Cc: Oleksandr Andrushchenko
Cc: Daniel Vetter
Signed-off-by: Noralf Trønnes
---
I will take this through drm-misc-next.
Noralf.
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
drivers/gpu/drm/drm_drv.c | 1 -
drivers/gpu/drm/udl/udl_drv.c | 1 +
drivers/gpu/drm/xen/xen_drm_front.c | 1 +
4 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index a1bb3773087b..d1f37ba3c118 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -971,6 +971,7 @@ amdgpu_pci_remove(struct pci_dev *pdev)
DRM_ERROR("Device removal is currently not supported outside of
fbcon\n");
drm_dev_unplug(dev);
+ drm_dev_put(dev);
pci_disable_device(pdev);
pci_set_drvdata(pdev, NULL);
}
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 05bbc2b622fc..b04982101fcb 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -376,7 +376,6 @@ void drm_dev_unplug(struct drm_device *dev)
synchronize_srcu(&drm_unplug_srcu);
drm_dev_unregister(dev);
- drm_dev_put(dev);
}
EXPORT_SYMBOL(drm_dev_unplug);
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 22cd2d13e272..53b7b8c04bc6 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -107,6 +107,7 @@ static void udl_usb_disconnect(struct usb_interface
*interface)
udl_fbdev_unplug(dev);
udl_drop_usb(dev);
drm_dev_unplug(dev);
+ drm_dev_put(dev);
}
/*
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 3e78a832d7f9..84aa4d61dc42 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -582,6 +582,7 @@ static void xen_drm_drv_fini(struct xen_drm_front_info
*front_info)
drm_kms_helper_poll_fini(dev);
drm_dev_unplug(dev);
+ drm_dev_put(dev);
front_info->drm_info = NULL;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
Regards
Shashank
On 2/8/2019 7:00 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 06:36:39PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/8/2019 6:22 PM, Ville Syrjälä wrote:
On Fri, Feb 08, 2019 at 12:36:25PM +, Sharma, Shashank wrote:
Regards
Shashank
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Shankar, Uma
Sent: Friday, February 8, 2019 5:45 PM
To: Ville Syrjälä
Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville ;
dri-
de...@lists.freedesktop.org; Lankhorst, Maarten
Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Tuesday, February 5, 2019 10:02 PM
To: Shankar, Uma
Cc: intel-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org; Syrjala, Ville
; Lankhorst, Maarten
Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace
property
On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote:
Create a new connector property to program colorspace to sink devices.
Modern sink devices support more than 1 type of colorspace like
601, 709, BT2020 etc. This helps to switch based on content
type which is to be displayed. The decision lies with
compositors as to in which scenarios, a particular colorspace will be picked.
This will be helpful mostly to switch to higher gamut
colorspaces like
BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to
the one supported. Sink supported colorspaces should be
retrieved by userspace from EDID and driver will not explicitly
expose
them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced the
colorspace enum to incorporate both HDMI and DP supported
colorspaces.
Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the
colorspace is not chosen by user, suggested by Ville and
Maarten. Addressed other misc review comments from Maarten.
Split the changes to have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated
HDMI and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian
Starkey's suggestion in order to go with string matching at userspace.
Updated the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and
Daniel Stone's comments and moved to drm include file. Moved
back to older design with exposing all HDMI colorspaces to
userspace since infoframe capability is there even on legacy
platforms, as per Ville's review comments.
v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v11: Addressed Ville's review comments. Updated the Macro
naming and added DCI-P3 colorspace as well defined in CEA 861.G spec.
Signed-off-by: Uma Shankar
Acked-by: Jani Nikula
Reviewed-by: Shashank Sharma
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 78
+++
include/drm/drm_connector.h | 50 +
3 files changed, 132 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9a1f41a..9b5d44f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int
drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == connector->colorspace_property) {
+ state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb =
drm_framebuffer_lookup(dev,
NULL, val);
int ret =
drm_atomic_set_writeback_fb_for_connector(state,
fb); @@
-814,6 +816,8 @@ static int
drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/opregion: fix version check
== Series Details ==
Series: series starting with [1/3] drm/i915/opregion: fix version check
URL : https://patchwork.freedesktop.org/series/56395/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d6761937ae7b drm/i915/opregion: fix version check
7b8f0501093b drm/i915/opregion: rvda is relative from opregion base in opregion
2.1+
-:35: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a
separate line
#35: FILE: drivers/gpu/drm/i915/intel_opregion.c:125:
+* address of raw VBT data. */
-:45: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#45: FILE: drivers/gpu/drm/i915/intel_opregion.c:965:
opregion->asle && opregion->asle->rvda && opregion->asle->rvds) {
+
total: 0 errors, 1 warnings, 1 checks, 43 lines checked
b611b8f9a275 HACK: drm/i915/opregion: ICL should have opregion 2.1+ and
relative rvda
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/3] drm/fourcc: Add 64 bpp half float formats
Op 06-02-2019 om 19:02 schreef Kevin Strasser:
> Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is
> formatted in IEEE-754 half-precision float (binary16) 1:5:10
> MSb-sign:exponent:fraction form.
>
> This patch attempts to address the feedback provided when 2 of these
> formats were previosly proposed:
> https://patchwork.kernel.org/patch/10072545/
>
> v2:
> - Fixed cpp (Ville)
> - Added detail pixel formatting (Ville)
> - Ordered formats in header (Ville)
>
> Cc: Tina Zhang
> Cc: Uma Shankar
> Cc: Shashank Sharma
> Cc: Ville Syrjälä
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Kevin Strasser
> Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_fourcc.c | 4
> include/uapi/drm/drm_fourcc.h | 11 +++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index d90ee03..c866452 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -198,6 +198,10 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_ABGR,.depth = 32,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_RGBA,.depth = 32,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_BGRA,.depth = 32,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> + { .format = DRM_FORMAT_XRGB16161616F, .depth = 48,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
> + { .format = DRM_FORMAT_XBGR16161616F, .depth = 48,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
> + { .format = DRM_FORMAT_ARGB16161616F, .depth = 64,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> + { .format = DRM_FORMAT_ABGR16161616F, .depth = 64,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_RGB888_A8, .depth = 32,
> .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_BGR888_A8, .depth = 32,
> .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_XRGB_A8, .depth = 32,
> .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
Hmmm, from include/drm/drm_fourcc.h
* @depth:
*
* Color depth (number of bits per pixel excluding padding bits),
* valid for a subset of RGB formats only. This is a legacy field, do
* not use in new code and set to 0 for new formats.
*/
u8 depth;
Otherwise looks good. :)
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 93a341d..d323c73 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -144,6 +144,17 @@ extern "C" {
> #define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /*
> [31:0] R:G:B:A 10:10:10:2 little endian */
> #define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /*
> [31:0] B:G:R:A 10:10:10:2 little endian */
>
> +/*
> + * Floating point 64bpp RGB
> + * IEEE 754-2008 binary16 half-precision float
> + * [15:0] sign:exponent:mantissa 1:5:10
> + */
> +#define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H') /* [63:0]
> x:R:G:B 16:16:16:16 little endian */
> +#define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H') /* [63:0]
> x:B:G:R 16:16:16:16 little endian */
> +
> +#define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0]
> A:R:G:B 16:16:16:16 little endian */
> +#define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0]
> A:B:G:R 16:16:16:16 little endian */
> +
> /* packed YCbCr */
> #define DRM_FORMAT_YUYV fourcc_code('Y', 'U', 'Y', 'V') /*
> [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
> #define DRM_FORMAT_YVYU fourcc_code('Y', 'V', 'Y', 'U') /*
> [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/opregion: fix version check
== Series Details ==
Series: series starting with [1/3] drm/i915/opregion: fix version check
URL : https://patchwork.freedesktop.org/series/56395/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5567 -> Patchwork_12175
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12175 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12175, 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/56395/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12175:
### IGT changes ###
Possible regressions
* igt@gem_exec_suspend@basic-s3:
- fi-apl-guc: PASS -> DMESG-WARN
Known issues
Here are the changes found in Patchwork_12175 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: PASS -> FAIL [fdo#103182] +1
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: PASS -> WARN [fdo#109380]
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: PASS -> FAIL [fdo#104008]
Possible fixes
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
Participating hosts (49 -> 44)
--
Missing(5): fi-kbl-soraka fi-hsw-4770r fi-ilk-m540 fi-byt-squawks
fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5567 -> Patchwork_12175
CI_DRM_5567: 5725867972123d46f4a4d382ed5fa2eb0348b00c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4815: 947301563259726b65ce47d3a3fe37931ed42efe @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12175: b611b8f9a27553340cc1e7d736be3ba5fc9a19d1 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b611b8f9a275 HACK: drm/i915/opregion: ICL should have opregion 2.1+ and
relative rvda
7b8f0501093b drm/i915/opregion: rvda is relative from opregion base in opregion
2.1+
d6761937ae7b drm/i915/opregion: fix version check
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12175/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/i915: Serialise resets with wedging
Chris Wilson writes:
> Prevent concurrent set-wedge with ongoing resets (and vice versa) by
> taking the same wedge_mutex around both operations.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reset.c | 68 ++-
> 1 file changed, 40 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reset.c
> b/drivers/gpu/drm/i915/i915_reset.c
> index c4fcb450bd80..9494b015185a 100644
> --- a/drivers/gpu/drm/i915/i915_reset.c
> +++ b/drivers/gpu/drm/i915/i915_reset.c
> @@ -794,17 +794,14 @@ static void nop_submit_request(struct i915_request
> *request)
> intel_engine_queue_breadcrumbs(engine);
> }
>
> -void i915_gem_set_wedged(struct drm_i915_private *i915)
> +static void __i915_gem_set_wedged(struct drm_i915_private *i915)
> {
> struct i915_gpu_error *error = &i915->gpu_error;
> struct intel_engine_cs *engine;
> enum intel_engine_id id;
>
> - mutex_lock(&error->wedge_mutex);
> - if (test_bit(I915_WEDGED, &error->flags)) {
> - mutex_unlock(&error->wedge_mutex);
> + if (test_bit(I915_WEDGED, &error->flags))
> return;
> - }
>
> if (GEM_SHOW_DEBUG() && !intel_engines_are_idle(i915)) {
> struct drm_printer p = drm_debug_printer(__func__);
> @@ -853,12 +850,18 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
> set_bit(I915_WEDGED, &error->flags);
>
> GEM_TRACE("end\n");
> - mutex_unlock(&error->wedge_mutex);
> +}
>
> - wake_up_all(&error->reset_queue);
> +void i915_gem_set_wedged(struct drm_i915_private *i915)
> +{
> + struct i915_gpu_error *error = &i915->gpu_error;
> +
> + mutex_lock(&error->wedge_mutex);
> + __i915_gem_set_wedged(i915);
> + mutex_unlock(&error->wedge_mutex);
> }
>
> -bool i915_gem_unset_wedged(struct drm_i915_private *i915)
> +static bool __i915_gem_unset_wedged(struct drm_i915_private *i915)
> {
> struct i915_gpu_error *error = &i915->gpu_error;
> struct i915_timeline *tl;
> @@ -869,8 +872,6 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
> if (!i915->gt.scratch) /* Never full initialised, recovery impossible */
> return false;
>
> - mutex_lock(&error->wedge_mutex);
> -
> GEM_TRACE("start\n");
>
> /*
> @@ -921,11 +922,21 @@ bool i915_gem_unset_wedged(struct drm_i915_private
> *i915)
> smp_mb__before_atomic(); /* complete takeover before enabling execbuf */
> clear_bit(I915_WEDGED, &i915->gpu_error.flags);
>
> - mutex_unlock(&i915->gpu_error.wedge_mutex);
> -
> return true;
> }
>
> +bool i915_gem_unset_wedged(struct drm_i915_private *i915)
> +{
> + struct i915_gpu_error *error = &i915->gpu_error;
> + bool result;
> +
> + mutex_lock(&error->wedge_mutex);
> + result = __i915_gem_unset_wedged(i915);
> + mutex_unlock(&error->wedge_mutex);
> +
> + return result;
> +}
> +
> static int do_reset(struct drm_i915_private *i915, unsigned int stalled_mask)
> {
> int err, i;
> @@ -975,7 +986,7 @@ void i915_reset(struct drm_i915_private *i915,
> GEM_BUG_ON(!test_bit(I915_RESET_BACKOFF, &error->flags));
>
> /* Clear any previous failed attempts at recovery. Time to try again. */
> - if (!i915_gem_unset_wedged(i915))
> + if (!__i915_gem_unset_wedged(i915))
> return;
>
> if (reason)
> @@ -1037,7 +1048,7 @@ void i915_reset(struct drm_i915_private *i915,
>*/
> add_taint(TAINT_WARN, LOCKDEP_STILL_OK);
> error:
> - i915_gem_set_wedged(i915);
> + __i915_gem_set_wedged(i915);
> goto finish;
> }
>
> @@ -1129,7 +1140,9 @@ static void i915_reset_device(struct drm_i915_private
> *i915,
> i915_wedge_on_timeout(&w, i915, 5 * HZ) {
> intel_prepare_reset(i915);
>
> + mutex_lock(&error->wedge_mutex);
> i915_reset(i915, engine_mask, reason);
> + mutex_unlock(&error->wedge_mutex);
>
> intel_finish_reset(i915);
> }
> @@ -1197,6 +1210,7 @@ void i915_handle_error(struct drm_i915_private *i915,
> unsigned long flags,
> const char *fmt, ...)
> {
> + struct i915_gpu_error *error = &i915->gpu_error;
> struct intel_engine_cs *engine;
> intel_wakeref_t wakeref;
> unsigned int tmp;
> @@ -1233,20 +1247,19 @@ void i915_handle_error(struct drm_i915_private *i915,
>* Try engine reset when available. We fall back to full reset if
>* single reset fails.
>*/
> - if (intel_has_reset_engine(i915) &&
> - !i915_terminally_wedged(&i915->gpu_error)) {
> + if (intel_has_reset_engine(i915) && !i915_terminally_wedged(error)) {
> for_each_engine_masked(engine, i915, engine_mask, tmp) {
> BUILD_BUG_ON(I915_RESET_MODESET >= I915_RESET_ENGINE);
> if (test_and_set_bit(I915_RESET_ENGIN
Re: [Intel-gfx] [PATCH v2 2/2] drm/drv: drm_dev_unplug(): Move out drm_dev_put() call
On 2/8/19 4:01 PM, Noralf Trønnes wrote:
This makes it possible to use drm_dev_unplug() with the upcoming
devm_drm_dev_init() which will do drm_dev_put() in its release callback.
Cc: Alex Deucher
Cc: Christian König
Cc: David (ChunMing) Zhou
Cc: Dave Airlie
Cc: Sean Paul
Cc: Oleksandr Andrushchenko
Cc: Daniel Vetter
Signed-off-by: Noralf Trønnes
---
I will take this through drm-misc-next.
Noralf.
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
drivers/gpu/drm/drm_drv.c | 1 -
drivers/gpu/drm/udl/udl_drv.c | 1 +
drivers/gpu/drm/xen/xen_drm_front.c | 1 +
4 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index a1bb3773087b..d1f37ba3c118 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -971,6 +971,7 @@ amdgpu_pci_remove(struct pci_dev *pdev)
DRM_ERROR("Device removal is currently not supported outside of fbcon\n");
drm_dev_unplug(dev);
+ drm_dev_put(dev);
pci_disable_device(pdev);
pci_set_drvdata(pdev, NULL);
}
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 05bbc2b622fc..b04982101fcb 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -376,7 +376,6 @@ void drm_dev_unplug(struct drm_device *dev)
synchronize_srcu(&drm_unplug_srcu);
drm_dev_unregister(dev);
- drm_dev_put(dev);
}
EXPORT_SYMBOL(drm_dev_unplug);
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 22cd2d13e272..53b7b8c04bc6 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -107,6 +107,7 @@ static void udl_usb_disconnect(struct usb_interface
*interface)
udl_fbdev_unplug(dev);
udl_drop_usb(dev);
drm_dev_unplug(dev);
+ drm_dev_put(dev);
}
/*
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 3e78a832d7f9..84aa4d61dc42 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -582,6 +582,7 @@ static void xen_drm_drv_fini(struct xen_drm_front_info
*front_info)
drm_kms_helper_poll_fini(dev);
drm_dev_unplug(dev);
+ drm_dev_put(dev);
Acked-by: Oleksandr Andrushchenko
front_info->drm_info = NULL;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
On Fri, Feb 08, 2019 at 07:36:24PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > On 2/8/2019 7:00 PM, Ville Syrjälä wrote: > > On Fri, Feb 08, 2019 at 06:36:39PM +0530, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >> On 2/8/2019 6:22 PM, Ville Syrjälä wrote: > >>> On Fri, Feb 08, 2019 at 12:36:25PM +, Sharma, Shashank wrote: > Regards > Shashank > > > -Original Message- > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On > > Behalf Of > > Shankar, Uma > > Sent: Friday, February 8, 2019 5:45 PM > > To: Ville Syrjälä > > Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville > > ; dri- > > de...@lists.freedesktop.org; Lankhorst, Maarten > > > > Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property > > > >> -Original Message- > >> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > >> Sent: Tuesday, February 5, 2019 10:02 PM > >> To: Shankar, Uma > >> Cc: intel-gfx@lists.freedesktop.org; > >> dri-de...@lists.freedesktop.org; Syrjala, Ville > >> ; Lankhorst, Maarten > >> > >> Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace > >> property > >> > >> On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote: > >>> Create a new connector property to program colorspace to sink > >>> devices. > >>> Modern sink devices support more than 1 type of colorspace like > >>> 601, 709, BT2020 etc. This helps to switch based on content > >>> type which is to be displayed. The decision lies with > >>> compositors as to in which scenarios, a particular colorspace > >>> will be picked. > >>> > >>> This will be helpful mostly to switch to higher gamut > >>> colorspaces like > >>> BT2020 when the media content is encoded as BT2020. Thereby > >>> giving a good visual experience to users. > >>> > >>> The expectation from userspace is that it should parse the EDID > >>> and get supported colorspaces. Use this property and switch to > >>> the one supported. Sink supported colorspaces should be > >>> retrieved by userspace from EDID and driver will not explicitly > >>> expose > >> them. > >>> Basically the expectation from userspace is: > >>>- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink > >>> colorspace > >>>- Set this new property to let the sink know what it > >>> converted the CRTC output to. > >>> > >>> v2: Addressed Maarten and Ville's review comments. Enhanced the > >>> colorspace enum to incorporate both HDMI and DP supported > >> colorspaces. > >>> Also, added a default option for colorspace. > >>> > >>> v3: Removed Adobe references from enum definitions as per > >>> Ville, Hans Verkuil and Jonas Karlman suggestions. Changed > >>> Default to an unset state where driver will assign the > >>> colorspace is not chosen by user, suggested by Ville and > >>> Maarten. Addressed other misc review comments from Maarten. > >>> Split the changes to have separate colorspace property for DP and > >>> HDMI. > >>> > >>> v4: Addressed Chris and Ville's review comments, and created a > >>> common colorspace property for DP and HDMI, filtered the list > >>> based on the colorspaces supported by the respective protocol > >>> standard. > >>> > >>> v5: Made the property creation helper accept enum list based on > >>> platform capabilties as suggested by Shashank. Consolidated > >>> HDMI and DP property creation in the common helper. > >>> > >>> v6: Addressed Shashank's review comments. > >>> > >>> v7: Added defines instead of enum in uapi as per Brian > >>> Starkey's suggestion in order to go with string matching at > >>> userspace. > >>> Updated the commit message to add more details as well kernel > >>> docs. > >>> > >>> v8: Addressed Maarten's review comments. > >>> > >>> v9: Removed macro defines from uapi as per Brian Starkey and > >>> Daniel Stone's comments and moved to drm include file. Moved > >>> back to older design with exposing all HDMI colorspaces to > >>> userspace since infoframe capability is there even on legacy > >>> platforms, as per Ville's review comments. > >>> > >>> v10: Fixed sparse warnings, updated the RB from Maarten and > >>> Jani's ack. > >>> > >>> v11: Addressed Ville's review comments. Updated the Macro > >>> naming and added DCI-P3 colorspace as well defined in CEA 861.G > >>> spe
[Intel-gfx] [PATCH i-g-t 1/2] kms_fence_pin_leak: Ask for the GPU before use
Check that the GPU even exists before submitting a batch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109589 Signed-off-by: Chris Wilson --- tests/kms_fence_pin_leak.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/kms_fence_pin_leak.c b/tests/kms_fence_pin_leak.c index 62c52b627..e6c8b33c3 100644 --- a/tests/kms_fence_pin_leak.c +++ b/tests/kms_fence_pin_leak.c @@ -201,6 +201,7 @@ igt_simple_main igt_skip_on_simulation(); data.drm_fd = drm_open_driver_master(DRIVER_INTEL); + igt_require_gem(data.drm_fd); data.devid = intel_get_drm_devid(data.drm_fd); -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] kms_fence_pin_leak: Move beneath i915/
kms_fence_pin_leak tests smooth sharp edges that are i915 specific (and
requires using GEM to do so). It doesn't belong in the general paddock
of all driver tests, so move it into the i915/ stable.
Signed-off-by: Chris Wilson
Cc: Arkadiusz Hiler
Cc: Petri Latvala
---
tests/Makefile.sources| 5 -
tests/{ => i915}/kms_fence_pin_leak.c | 0
tests/meson.build | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
rename tests/{ => i915}/kms_fence_pin_leak.c (100%)
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index a234fa5dd..8565f100a 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -40,7 +40,6 @@ TESTS_progs = \
kms_dp_dsc \
kms_draw_crc \
kms_fbcon_fbt \
- kms_fence_pin_leak \
kms_flip \
kms_flip_event_leak \
kms_flip_tiling \
@@ -98,6 +97,10 @@ TESTS_progs = \
vgem_slow \
$(NULL)
+TESTS_progs += \
+ i915/kms_fence_pin_leak \
+ $(NULL)
+
TESTS_progs += gem_bad_reloc
gem_bad_reloc_SOURCES = i915/gem_bad_reloc.c
diff --git a/tests/kms_fence_pin_leak.c b/tests/i915/kms_fence_pin_leak.c
similarity index 100%
rename from tests/kms_fence_pin_leak.c
rename to tests/i915/kms_fence_pin_leak.c
diff --git a/tests/meson.build b/tests/meson.build
index 0f12df26d..1c4f9ec36 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -27,7 +27,6 @@ test_progs = [
'kms_dp_dsc',
'kms_draw_crc',
'kms_fbcon_fbt',
- 'kms_fence_pin_leak',
'kms_flip',
'kms_flip_event_leak',
'kms_flip_tiling',
@@ -99,6 +98,7 @@ i915_progs = [
'fb_tiling',
'getparams_basic',
'hangman',
+ 'kms_fence_pin_leak',
'missed_irq',
'module_load',
'query',
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v4 0/5] DC states igt tests patch series
Hi, On Fri, Feb 01, 2019 at 09:42:57PM +0530, Anshuman Gupta wrote: > This patch series adds new tests to validate Display C states. > DC states like DC5 and DC6 are validated during PSR entry/exit > and during DPMS on/off cycle. > Sending new revision of patch series after addressing review comments. IGT patches should be sent to so they are tested in CI. > > Jyoti Yadav (5): > lib/igt_pm: Moves Dmc_loaded() function into library > tests/pm_dc: Added new test to verify Display C States > tests/pm_dc: Added test for DC6 during PSR > tests/pm_dc: Added test for DC5 during DPMS > tests/pm_dc: Added test for DC6 during DPMS > > lib/igt_pm.c | 28 ++ > lib/igt_pm.h | 1 + > tests/Makefile.sources | 1 + > tests/meson.build | 1 + > tests/pm_dc.c | 259 > + > tests/pm_rpm.c | 17 +--- > 6 files changed, 291 insertions(+), 16 deletions(-) > create mode 100644 tests/pm_dc.c > > -- > 2.7.4 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v4 1/5] lib/igt_pm: Moves Dmc_loaded() function into library
On Fri, Feb 01, 2019 at 09:42:58PM +0530, Anshuman Gupta wrote:
> From: Jyoti Yadav
>
> It will be used by new test pm_dc.c which will validate Display C States.
> So moving the same to igt_pm library.
>
> v2: Simplify the comment section.
> v3: Remove . from the subject line.
> v4: Rebased and addressed the review comments.
Listing the actual changes would make review easier.
>
> Signed-off-by: Jyoti Yadav
> Signed-off-by: Anshuman Gupta
> ---
> lib/igt_pm.c | 28
> lib/igt_pm.h | 1 +
> tests/pm_rpm.c | 17 +
> 3 files changed, 30 insertions(+), 16 deletions(-)
>
> diff --git a/lib/igt_pm.c b/lib/igt_pm.c
> index 4902723..8b87c58 100644
> --- a/lib/igt_pm.c
> +++ b/lib/igt_pm.c
> @@ -38,6 +38,7 @@
> #include "drmtest.h"
> #include "igt_pm.h"
> #include "igt_aux.h"
> +#include "igt_sysfs.h"
>
> /**
> * SECTION:igt_pm
> @@ -620,3 +621,30 @@ bool igt_wait_for_pm_status(enum igt_runtime_pm_status
> status)
> {
> return igt_wait(igt_get_runtime_pm_status() == status, 1, 100);
> }
> +
> +/**
> + * dmc_loaded:
> + * @debugfs: fd to the debugfs dir.
> +
> + * Check whether DMC FW is loaded or not. DMC FW is require for few Display C
> + * states like DC5 and DC6. FW does the Context Save and Restore during
> Display
> + * C States entry and exit.
> + *
> + * Returns:
> + * True if DMC FW is loaded otherwise false.
> + */
> +bool igt_pm_dmc_loaded(int debugfs)
> +{
> + igt_require(debugfs != -1);
> + char buf[15];
> + int len;
> +
> + len = igt_sysfs_read(debugfs, "i915_dmc_info", buf, sizeof(buf) - 1);
> + if (len < 0)
> + return true; /* no CSR support, no DMC requirement */
> +
> + buf[len] = '\0';
> +
> + igt_info("DMC: %s\n", buf);
> + return strstr(buf, "fw loaded: yes");
> +}
> diff --git a/lib/igt_pm.h b/lib/igt_pm.h
> index 10cc679..70d2380 100644
> --- a/lib/igt_pm.h
> +++ b/lib/igt_pm.h
> @@ -50,5 +50,6 @@ bool igt_setup_runtime_pm(void);
> void igt_restore_runtime_pm(void);
> enum igt_runtime_pm_status igt_get_runtime_pm_status(void);
> bool igt_wait_for_pm_status(enum igt_runtime_pm_status status);
> +bool igt_pm_dmc_loaded(int debugfs);
>
> #endif /* IGT_PM_H */
> diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
> index be296f5..2d7cb5e 100644
> --- a/tests/pm_rpm.c
> +++ b/tests/pm_rpm.c
> @@ -710,21 +710,6 @@ static void setup_pc8(void)
> has_pc8 = true;
> }
>
> -static bool dmc_loaded(void)
> -{
> - char buf[15];
> - int len;
> -
> - len = igt_sysfs_read(debugfs, "i915_dmc_info", buf, sizeof(buf) - 1);
> - if (len < 0)
> - return true; /* no CSR support, no DMC requirement */
> -
> - buf[len] = '\0';
> -
> - igt_info("DMC: %s\n", buf);
> - return strstr(buf, "fw loaded: yes");
> -}
> -
> static void dump_file(int dir, const char *filename)
> {
> char *contents;
> @@ -761,7 +746,7 @@ static bool setup_environment(void)
> igt_info("Runtime PM support: %d\n", has_runtime_pm);
> igt_info("PC8 residency support: %d\n", has_pc8);
> igt_require(has_runtime_pm);
> - igt_require(dmc_loaded());
> + igt_require(igt_pm_dmc_loaded(debugfs));
>
> out:
> disable_all_screens(&ms_data);
> --
> 2.7.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't claim an unstarted request was guilty
Chris Wilson writes:
> If we haven't even begun executing the payload of the stalled request,
> then we should not claim that its userspace context was guilty of
> submitting a hanging batch.
>
> v2: Check for context corruption before trying to restart.
> v3: Preserve semaphores on skipping requests (need to keep the timelines
> intact).
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 42 +--
> drivers/gpu/drm/i915/selftests/igt_spinner.c | 9 +++-
> .../gpu/drm/i915/selftests/intel_hangcheck.c | 6 +++
> 3 files changed, 53 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 5e98fd79bd9d..e3134a635926 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1387,6 +1387,10 @@ static int gen8_emit_init_breadcrumb(struct
> i915_request *rq)
> *cs++ = rq->fence.seqno - 1;
>
> intel_ring_advance(rq, cs);
> +
> + /* Record the updated position of the request's payload */
> + rq->infix = intel_ring_offset(rq, cs);
> +
> return 0;
> }
>
> @@ -1878,6 +1882,23 @@ static void execlists_reset_prepare(struct
> intel_engine_cs *engine)
> spin_unlock_irqrestore(&engine->timeline.lock, flags);
> }
>
> +static bool lrc_regs_ok(const struct i915_request *rq)
> +{
> + const struct intel_ring *ring = rq->ring;
> + const u32 *regs = rq->hw_context->lrc_reg_state;
> +
> + /* Quick spot check for the common signs of context corruption */
> +
> + if (regs[CTX_RING_BUFFER_CONTROL + 1] !=
> + (RING_CTL_SIZE(ring->size) | RING_VALID))
> + return false;
You been noticing this with ctx corruption? Well now
thinking about it, we have had reports where on init,
on some trouble, the valid vanishes.
> +
> + if (regs[CTX_RING_BUFFER_START + 1] != i915_ggtt_offset(ring->vma))
> + return false;
> +
Seen this on bugzilla reports too. Are there more
in your sleeve or is this a compromise on complexity
and performance? Checking on a sane actual head too?
The heuristics of it bothers me some as we will
get false positives.
So in effect, when we get one, we just move ahead
after an extra reset as we got it all wrong?
> + return true;
> +}
> +
> static void execlists_reset(struct intel_engine_cs *engine, bool stalled)
> {
> struct intel_engine_execlists * const execlists = &engine->execlists;
> @@ -1912,6 +1933,21 @@ static void execlists_reset(struct intel_engine_cs
> *engine, bool stalled)
> if (!rq)
> goto out_unlock;
>
> + /*
> + * If this request hasn't started yet, e.g. it is waiting on a
> + * semaphore, we need to avoid skipping the request or else we
> + * break the signaling chain. However, if the context is corrupt
> + * the request will not restart and we will be stuck with a wedged
> + * device. It is quite often the case that if we issue a reset
> + * while the GPU is loading the context image, that context image
> + * becomes corrupt.
> + *
> + * Otherwise, if we have not started yet, the request should replay
> + * perfectly and we do not need to flag the result as being erroneous.
> + */
> + if (!i915_request_started(rq) && lrc_regs_ok(rq))
> + goto out_unlock;
> +
> /*
>* If the request was innocent, we leave the request in the ELSP
>* and will try to replay it on restarting. The context image may
> @@ -1924,7 +1960,7 @@ static void execlists_reset(struct intel_engine_cs
> *engine, bool stalled)
>* image back to the expected values to skip over the guilty request.
>*/
> i915_reset_request(rq, stalled);
> - if (!stalled)
> + if (!stalled && lrc_regs_ok(rq))
Extend the ctx validator usage for on guilty engines, well why not.
-Mika
> goto out_unlock;
>
> /*
> @@ -1942,8 +1978,8 @@ static void execlists_reset(struct intel_engine_cs
> *engine, bool stalled)
> engine->context_size - PAGE_SIZE);
> }
>
> - /* Move the RING_HEAD onto the breadcrumb, past the hanging batch */
> - rq->ring->head = intel_ring_wrap(rq->ring, rq->postfix);
> + /* Rerun the request; its payload has been neutered (if guilty). */
> + rq->ring->head = intel_ring_wrap(rq->ring, rq->head);
> intel_ring_update_space(rq->ring);
>
> execlists_init_reg_state(regs, rq->gem_context, engine, rq->ring);
> diff --git a/drivers/gpu/drm/i915/selftests/igt_spinner.c
> b/drivers/gpu/drm/i915/selftests/igt_spinner.c
> index 9ebd9225684e..86354e51bdd3 100644
> --- a/drivers/gpu/drm/i915/selftests/igt_spinner.c
> +++ b/drivers/gpu/drm/i915/selftests/igt_spinner.c
> @@ -142,10 +142,17 @@ igt_spinner_create_request(struct igt_spinner *spin,
> *batch++ = upper_32_bits(vma->node.start);
> *batch++ = MI_BATCH_BUFFER_END; /* not reached */
>
> - i915_g
Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/icl: Implement half float formats
Op 06-02-2019 om 19:02 schreef Kevin Strasser: > 64 bpp half float formats are supported on hdr planes only and are subject > to the following restrictions: > * 90/270 rotation not supported > * Yf Tiling not supported > * Frame Buffer Compression not supported > * Color Keying not supported > > v2: > - Drop handling pixel normalize register > - Don't use icl_is_hdr_plane too early > > v3: > - Use refactored icl_is_hdr_plane (Ville) > - Use u32 instead of uint32_t (Ville) > > Cc: Uma Shankar > Cc: Shashank Sharma > Cc: Ville Syrjälä > Cc: David Airlie > Cc: Daniel Vetter > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Kevin Strasser > Reviewed-by: Ville Syrjälä > --- For the whole series, with the depth change to patch 1: Reviewed-by: Maarten Lankhorst ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 0/3] Support 64 bpp half float formats
Op 06-02-2019 om 19:02 schreef Kevin Strasser: > This series defines new formats and adds implementation to the i915 driver. > Since posting v1 I have removed the pixel normalize property, as it's not > needed > for basic functionality. Also, I have been working on adding support to > userspace, but we can't land any patches until drm_fourcc.h has been updated > here. > > I have submitted a series to Mesa to make use of the RGBA ordered formats: > https://patchwork.freedesktop.org/series/54759/ > > My igt branch is reworked to drop usage of pixel normalize and includes use > of f16c intrinsics to speed up conversion: > https://gitlab.freedesktop.org/strassek/igt-gpu-tools/commits/fp16 > > I also have a libdrm branch with fp16 coverage added to modetest: > https://gitlab.freedesktop.org/strassek/drm/commits/fp16 > > To serve as a smoke test of the whole stack I have a modified version of > kmscube: > https://gitlab.freedesktop.org/strassek/kmscube/commits/fp16 > > Kevin Strasser (3): > drm/fourcc: Add 64 bpp half float formats > drm/i915: Refactor icl_is_hdr_plane > drm/i915/icl: Implement half float formats > > drivers/gpu/drm/drm_fourcc.c | 4 ++ > drivers/gpu/drm/i915/intel_atomic.c | 3 +- > drivers/gpu/drm/i915/intel_display.c | 27 - > drivers/gpu/drm/i915/intel_drv.h | 7 ++-- > drivers/gpu/drm/i915/intel_sprite.c | 73 > +++- > include/uapi/drm/drm_fourcc.h| 11 ++ > 6 files changed, 110 insertions(+), 15 deletions(-) > It's nice that the igt parts are almost done. I think this might need rebasing on top of I'm glad there are tests, but the internal accuracy of the CAIRO_FORMAT_RGB24 is only 8 bits, so it wouldn't test this properly. Fortunately we will start using CAIRO_FORMAT_RGB96F and RGBA128F soon. :) See https://patchwork.freedesktop.org/patch/284507/ We should be able to convert native float to half float with an intrinsic. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v4 2/5] tests/pm_dc: Added new test to verify Display C States
On Fri, Feb 01, 2019 at 09:42:59PM +0530, Anshuman Gupta wrote:
> From: Jyoti Yadav
>
> Currently this test validates DC5 upon PSR entry for supported platforms.
> Added new file for compilation inside Makefile and Meson.
>
> v2: Used the debugfs entry for DC counters instead of Registers.
> Used shorter names for variables.
> Introduced timeout to read DC counters.
> v3: one second timeout is introduced to read DC counters.
> Skip the subtest if counters are not available for that platform.
> v4: Rebased, addressed the review comment and spell correction.
>
> Signed-off-by: Jyoti Yadav
> Signed-off-by: Anshuman Gupta
> ---
> tests/Makefile.sources | 1 +
> tests/meson.build | 1 +
> tests/pm_dc.c | 205
> +
> 3 files changed, 207 insertions(+)
> create mode 100644 tests/pm_dc.c
>
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 34b7e44..07b9787 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -80,6 +80,7 @@ TESTS_progs = \
> pm_lpsp \
> pm_rc6_residency \
> pm_rpm \
> + pm_dc \
> pm_rps \
> pm_sseu \
> prime_busy \
> diff --git a/tests/meson.build b/tests/meson.build
> index 25b4614..3070a3e 100644
> --- a/tests/meson.build
> +++ b/tests/meson.build
> @@ -66,6 +66,7 @@ test_progs = [
> 'pm_lpsp',
> 'pm_rc6_residency',
> 'pm_rpm',
> + 'pm_dc',
> 'pm_rps',
> 'pm_sseu',
> 'prime_busy',
> diff --git a/tests/pm_dc.c b/tests/pm_dc.c
> new file mode 100644
> index 000..d59be94
> --- /dev/null
> +++ b/tests/pm_dc.c
> @@ -0,0 +1,205 @@
> +/*
> + * Copyright © 2018 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + */
> +
> +#include "igt.h"
> +#include "igt_sysfs.h"
> +#include "igt_psr.h"
> +#include
> +#include
> +#include
> +#include
> +#include "intel_bufmgr.h"
> +#include "intel_io.h"
> +#include "limits.h"
> +
> +
> +typedef struct {
> + int drm_fd;
> + int debugfs_fd;
> + uint32_t devid;
> + igt_display_t display;
> + struct igt_fb fb_white;
> + enum psr_mode op_psr_mode;
> + drmModeModeInfo *mode;
> + igt_output_t *output;
> +} data_t;
> +
> +/* DC State Flags */
> +#define CHECK_DC51
> +#define CHECK_DC62
> +
> +static void setup_output(data_t *data)
> +{
> + igt_display_t *display = &data->display;
> + igt_output_t *output;
> + enum pipe pipe;
> +
> + for_each_pipe_with_valid_output(display, pipe, output) {
> + drmModeConnectorPtr c = output->config.connector;
> +
> + if (c->connector_type != DRM_MODE_CONNECTOR_eDP)
> + continue;
> +
> + igt_output_set_pipe(output, pipe);
> + data->output = output;
> + data->mode = igt_output_get_mode(output);
> +
> + return;
> + }
> +}
> +
> +static void display_fini(data_t *data)
> +{
> + igt_display_fini(&data->display);
> +}
> +
> +static bool edp_psr_sink_support(data_t *data)
> +{
> + char buf[512];
> +
> + igt_debugfs_simple_read(data->debugfs_fd, "i915_edp_psr_status",
> + buf, sizeof(buf));
> +
> + return strstr(buf, "Sink_Support: yes\n");
> +}
> +
> +static void cleanup(data_t *data)
> +{
> + igt_plane_t *primary;
> +
> + primary = igt_output_get_plane_type(data->output,
> + DRM_PLANE_TYPE_PRIMARY);
> + igt_plane_set_fb(primary, NULL);
> + igt_display_commit(&data->display);
> + igt_remove_fb(data->drm_fd, &data->fb_white);
> +}
> +
> +static void setup_primary(data_t *data)
> +{
> + igt_plane_t *primary;
> +
> + primary = igt_output_get_plane_type(data->output,
> + DRM_PLANE_TYPE_PRIMARY);
> + igt_plane_set_fb(primary, N
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Protect i915_active iterators from the shrinker
== Series Details ==
Series: drm/i915: Protect i915_active iterators from the shrinker
URL : https://patchwork.freedesktop.org/series/56401/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5567 -> Patchwork_12176
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56401/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12176 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#109485]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1
* igt@pm_rpm@basic-rte:
- fi-bsw-kefka: PASS -> FAIL [fdo#108800]
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
Participating hosts (49 -> 45)
--
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5567 -> Patchwork_12176
CI_DRM_5567: 5725867972123d46f4a4d382ed5fa2eb0348b00c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4815: 947301563259726b65ce47d3a3fe37931ed42efe @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12176: 181afb7298dc8711773c304572ab39cd75fff5f6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
181afb7298dc drm/i915: Protect i915_active iterators from the shrinker
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12176/
___
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/2] kms_fence_pin_leak: Move beneath i915/
On Fri, Feb 08, 2019 at 02:44:58PM +, Chris Wilson wrote:
> kms_fence_pin_leak tests smooth sharp edges that are i915 specific (and
> requires using GEM to do so). It doesn't belong in the general paddock
> of all driver tests, so move it into the i915/ stable.
>
> Signed-off-by: Chris Wilson
> Cc: Arkadiusz Hiler
> Cc: Petri Latvala
Acked-by: Petri Latvala
> ---
> tests/Makefile.sources| 5 -
> tests/{ => i915}/kms_fence_pin_leak.c | 0
> tests/meson.build | 2 +-
> 3 files changed, 5 insertions(+), 2 deletions(-)
> rename tests/{ => i915}/kms_fence_pin_leak.c (100%)
>
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index a234fa5dd..8565f100a 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -40,7 +40,6 @@ TESTS_progs = \
> kms_dp_dsc \
> kms_draw_crc \
> kms_fbcon_fbt \
> - kms_fence_pin_leak \
> kms_flip \
> kms_flip_event_leak \
> kms_flip_tiling \
> @@ -98,6 +97,10 @@ TESTS_progs = \
> vgem_slow \
> $(NULL)
>
> +TESTS_progs += \
> + i915/kms_fence_pin_leak \
> + $(NULL)
> +
> TESTS_progs += gem_bad_reloc
> gem_bad_reloc_SOURCES = i915/gem_bad_reloc.c
>
> diff --git a/tests/kms_fence_pin_leak.c b/tests/i915/kms_fence_pin_leak.c
> similarity index 100%
> rename from tests/kms_fence_pin_leak.c
> rename to tests/i915/kms_fence_pin_leak.c
> diff --git a/tests/meson.build b/tests/meson.build
> index 0f12df26d..1c4f9ec36 100644
> --- a/tests/meson.build
> +++ b/tests/meson.build
> @@ -27,7 +27,6 @@ test_progs = [
> 'kms_dp_dsc',
> 'kms_draw_crc',
> 'kms_fbcon_fbt',
> - 'kms_fence_pin_leak',
> 'kms_flip',
> 'kms_flip_event_leak',
> 'kms_flip_tiling',
> @@ -99,6 +98,7 @@ i915_progs = [
> 'fb_tiling',
> 'getparams_basic',
> 'hangman',
> + 'kms_fence_pin_leak',
> 'missed_irq',
> 'module_load',
> 'query',
> --
> 2.20.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v4 5/5] tests/pm_dc: Added test for DC6 during DPMS
On Fri, Feb 01, 2019 at 09:43:02PM +0530, Anshuman Gupta wrote:
> From: Jyoti Yadav
>
> Added new subtest for DC6 entry during DPMS on/off cycle.
> During DPMS on/off cycle DC6 counter is incremented.
>
> v2: Renamed the subtest name.
> v3: Rebased.
> v4: Rebased and address review comment.
>
> Signed-off-by: Jyoti Yadav
> Signed-off-by: Anshuman Gupta
> ---
> tests/pm_dc.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/tests/pm_dc.c b/tests/pm_dc.c
> index 05f1363..244665d 100644
> --- a/tests/pm_dc.c
> +++ b/tests/pm_dc.c
> @@ -241,6 +241,15 @@ int main(int argc, char *argv[])
> test_dc_state_dpms(&data, CHECK_DC5);
> }
>
> + igt_subtest("dc6-dpms") {
> + /* Check DC6 counter is available for the platform.
> + * Skip the test if counter is not available.
> + */
> + read_dc_counter(data.drm_fd, CHECK_DC6);
> + test_dc_state_dpms(&data, CHECK_DC6);
> + //cleanup(&data);
Some debugging left-over above. That makes me think, why do the PSR
subtests do a modeset while the dpms ones don't? I think there is no
reason to make them behave differently.
> + }
> +
> igt_fixture {
> close(data.debugfs_fd);
> display_fini(&data);
> --
> 2.7.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't claim an unstarted request was guilty
Quoting Mika Kuoppala (2019-02-08 14:47:13)
> Chris Wilson writes:
>
> > If we haven't even begun executing the payload of the stalled request,
> > then we should not claim that its userspace context was guilty of
> > submitting a hanging batch.
> >
> > v2: Check for context corruption before trying to restart.
> > v3: Preserve semaphores on skipping requests (need to keep the timelines
> > intact).
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c | 42 +--
> > drivers/gpu/drm/i915/selftests/igt_spinner.c | 9 +++-
> > .../gpu/drm/i915/selftests/intel_hangcheck.c | 6 +++
> > 3 files changed, 53 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 5e98fd79bd9d..e3134a635926 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -1387,6 +1387,10 @@ static int gen8_emit_init_breadcrumb(struct
> > i915_request *rq)
> > *cs++ = rq->fence.seqno - 1;
> >
> > intel_ring_advance(rq, cs);
> > +
> > + /* Record the updated position of the request's payload */
> > + rq->infix = intel_ring_offset(rq, cs);
> > +
> > return 0;
> > }
> >
> > @@ -1878,6 +1882,23 @@ static void execlists_reset_prepare(struct
> > intel_engine_cs *engine)
> > spin_unlock_irqrestore(&engine->timeline.lock, flags);
> > }
> >
> > +static bool lrc_regs_ok(const struct i915_request *rq)
> > +{
> > + const struct intel_ring *ring = rq->ring;
> > + const u32 *regs = rq->hw_context->lrc_reg_state;
> > +
> > + /* Quick spot check for the common signs of context corruption */
> > +
> > + if (regs[CTX_RING_BUFFER_CONTROL + 1] !=
> > + (RING_CTL_SIZE(ring->size) | RING_VALID))
> > + return false;
>
> You been noticing this with ctx corruption? Well now
> thinking about it, we have had reports where on init,
> on some trouble, the valid vanishes.
Yes, it's why we've been copying the default context over guilty for a
long time (pretty much since live_hangcheck became a thing iirc).
> > +
> > + if (regs[CTX_RING_BUFFER_START + 1] != i915_ggtt_offset(ring->vma))
> > + return false;
> > +
>
> Seen this on bugzilla reports too. Are there more
> in your sleeve or is this a compromise on complexity
> and performance? Checking on a sane actual head too?
No, I can't remember seeing this, just loosing CTL. But I do recall that
at one point it seemed the whole reg state was zero, but that is foggy
memory.
> The heuristics of it bothers me some as we will
> get false positives.
They cannot be false positives! If we restore to a batch setup like
this, it will hang -- which is why we explicitly reset them.
> So in effect, when we get one, we just move ahead
> after an extra reset as we got it all wrong?
Yup. The context is corrupt, we replace it with a sane one and hope
nobody notices. Mesa does notice though
> > + return true;
> > +}
> > +
> > static void execlists_reset(struct intel_engine_cs *engine, bool stalled)
> > {
> > struct intel_engine_execlists * const execlists = &engine->execlists;
> > @@ -1912,6 +1933,21 @@ static void execlists_reset(struct intel_engine_cs
> > *engine, bool stalled)
> > if (!rq)
> > goto out_unlock;
> >
> > + /*
> > + * If this request hasn't started yet, e.g. it is waiting on a
> > + * semaphore, we need to avoid skipping the request or else we
> > + * break the signaling chain. However, if the context is corrupt
> > + * the request will not restart and we will be stuck with a wedged
> > + * device. It is quite often the case that if we issue a reset
> > + * while the GPU is loading the context image, that context image
> > + * becomes corrupt.
> > + *
> > + * Otherwise, if we have not started yet, the request should replay
> > + * perfectly and we do not need to flag the result as being erroneous.
> > + */
> > + if (!i915_request_started(rq) && lrc_regs_ok(rq))
> > + goto out_unlock;
> > +
> > /*
> >* If the request was innocent, we leave the request in the ELSP
> >* and will try to replay it on restarting. The context image may
> > @@ -1924,7 +1960,7 @@ static void execlists_reset(struct intel_engine_cs
> > *engine, bool stalled)
> >* image back to the expected values to skip over the guilty request.
> >*/
> > i915_reset_request(rq, stalled);
> > - if (!stalled)
> > + if (!stalled && lrc_regs_ok(rq))
>
> Extend the ctx validator usage for on guilty engines, well why not.
We forcibly reset anyway.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
Op 08-02-2019 om 14:47 schreef swati2.sha...@intel.com:
> From: Swati Sharma
>
> The following pixel formats are packed format that follows 4:2:2
> chroma sampling. For memory represenation each component is
> allocated 16 bits each. Thus each pixel occupies 32bit.
>
> Y210: For each component, valid data occupies MSB 10 bits.
> LSB 6 bits are filled with zeroes.
> Y212: For each component, valid data occupies MSB 12 bits.
> LSB 4 bits are filled with zeroes.
> Y216: For each component valid data occupies 16 bits,
> doesn't require any padding bits.
>
> First 16 bits stores the Y value and the next 16 bits stores one
> of the chroma samples alternatively. The first luma sample will
> be accompanied by first U sample and second luma sample is
> accompanied by the first V sample.
>
> The following pixel formats are packed format that follows 4:4:4
> chroma sampling. Channels are arranged in the order UYVA in
> increasing memory order.
>
> Y410: Each color component occupies 10 bits and X component
> takes 2 bits, thus each pixel occupies 32 bits.
> Y412: Each color component is 16 bits where valid data
> occupies MSB 12 bits. LSB 4 bits are filled with zeroes.
> Thus, each pixel occupies 64 bits.
> Y416: Each color component occupies 16 bits for valid data,
> doesn't require any padding bits. Thus, each pixel
> occupies 64 bits.
>
> Signed-off-by: Swati Sharma
> ---
> drivers/gpu/drm/drm_fourcc.c | 6 ++
> include/uapi/drm/drm_fourcc.h | 18 +-
> 2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index d45a3a4..16cbeea 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -229,6 +229,12 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_P010,.depth = 0,
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
> { .format = DRM_FORMAT_P012,.depth = 0,
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
> { .format = DRM_FORMAT_P016,.depth = 0,
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
> + { .format = DRM_FORMAT_Y210,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_Y212,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_Y216,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_Y410,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_Y412,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_Y416,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_Y0L0,.depth = 0,
> .num_planes = 1,
> .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
> .block_h = { 2, 0, 0 },
> .hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 073bbea..5535669 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -151,7 +151,23 @@
> #define DRM_FORMAT_VYUY fourcc_code('V', 'Y', 'U', 'Y') /*
> [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
>
> #define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /*
> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> -#define DRM_FORMAT_XYUV fourcc_code('X', 'Y', 'U', 'V') /*
> [31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
> +#define DRM_FORMAT_XYUV fourcc_code('X', 'Y', 'U', 'V') /* [31:0]
> X:Y:Cb:Cr 8:8:8:8 little endian */
> +
> +/*
> + * packed Y2xx indicate for each component, xx valid data occupy msb
> + * 16-xx padding occupy lsb
> + */
> +#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
> Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian per 2 Y pixels */
> +#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
> Y0:x:Cb0:x:Y1:x:Cr1:x 12:4:12:4:12:4:12:4 little endian per 2 Y pixels */
> +#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
> Y0:Cb0:Y1:Cr1 16:16:16:16 little endian per 2 Y pixels */
> +
> +/*
> + * packed Y4xx indicate for each component, xx valid data occupy msb
> + * 16-xx padding occupy lsb except Y410
> + */
> +#define DRM_FORMAT_Y410 fourcc_code('Y', '4', '1', '0') /* [31:0]
> X:V:Y:U 2:10:10:10 little endian */
> +#define DRM_FORMAT_Y
Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
>-Original Message- >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] >Sent: Friday, February 8, 2019 8:08 PM >To: Sharma, Shashank >Cc: Shankar, Uma ; intel-gfx@lists.freedesktop.org; >Syrjala, Ville ; dri-de...@lists.freedesktop.org; >Lankhorst, >Maarten >Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property > >On Fri, Feb 08, 2019 at 07:36:24PM +0530, Sharma, Shashank wrote: >> Regards >> >> Shashank >> >> On 2/8/2019 7:00 PM, Ville Syrjälä wrote: >> > On Fri, Feb 08, 2019 at 06:36:39PM +0530, Sharma, Shashank wrote: >> >> Regards >> >> >> >> Shashank >> >> >> >> On 2/8/2019 6:22 PM, Ville Syrjälä wrote: >> >>> On Fri, Feb 08, 2019 at 12:36:25PM +, Sharma, Shashank wrote: >> Regards >> Shashank >> >> > -Original Message- >> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] >> > On Behalf Of Shankar, Uma >> > Sent: Friday, February 8, 2019 5:45 PM >> > To: Ville Syrjälä >> > Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville >> > ; dri- de...@lists.freedesktop.org; >> > Lankhorst, Maarten >> > Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace >> > property >> > >> >> -Original Message- >> >> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] >> >> Sent: Tuesday, February 5, 2019 10:02 PM >> >> To: Shankar, Uma >> >> Cc: intel-gfx@lists.freedesktop.org; >> >> dri-de...@lists.freedesktop.org; Syrjala, Ville >> >> ; Lankhorst, Maarten >> >> >> >> Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace >> >> property >> >> >> >> On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote: >> >>> Create a new connector property to program colorspace to sink >devices. >> >>> Modern sink devices support more than 1 type of colorspace >> >>> like 601, 709, BT2020 etc. This helps to switch based on >> >>> content type which is to be displayed. The decision lies >> >>> with compositors as to in which scenarios, a particular >> >>> colorspace will >be picked. >> >>> >> >>> This will be helpful mostly to switch to higher gamut >> >>> colorspaces like >> >>> BT2020 when the media content is encoded as BT2020. >> >>> Thereby giving a good visual experience to users. >> >>> >> >>> The expectation from userspace is that it should parse the >> >>> EDID and get supported colorspaces. Use this property and >> >>> switch to the one supported. Sink supported colorspaces >> >>> should be retrieved by userspace from EDID and driver will >> >>> not explicitly expose >> >> them. >> >>> Basically the expectation from userspace is: >> >>>- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink >> >>> colorspace >> >>>- Set this new property to let the sink know what it >> >>> converted the CRTC output to. >> >>> >> >>> v2: Addressed Maarten and Ville's review comments. >> >>> Enhanced the colorspace enum to incorporate both HDMI and >> >>> DP supported >> >> colorspaces. >> >>> Also, added a default option for colorspace. >> >>> >> >>> v3: Removed Adobe references from enum definitions as per >> >>> Ville, Hans Verkuil and Jonas Karlman suggestions. Changed >> >>> Default to an unset state where driver will assign the >> >>> colorspace is not chosen by user, suggested by Ville and >> >>> Maarten. Addressed other misc review comments from Maarten. >> >>> Split the changes to have separate colorspace property for DP and >HDMI. >> >>> >> >>> v4: Addressed Chris and Ville's review comments, and >> >>> created a common colorspace property for DP and HDMI, >> >>> filtered the list based on the colorspaces supported by the >> >>> respective >protocol standard. >> >>> >> >>> v5: Made the property creation helper accept enum list >> >>> based on platform capabilties as suggested by Shashank. >> >>> Consolidated HDMI and DP property creation in the common helper. >> >>> >> >>> v6: Addressed Shashank's review comments. >> >>> >> >>> v7: Added defines instead of enum in uapi as per Brian >> >>> Starkey's suggestion in order to go with string matching at >> >>> userspace. >> >>> Updated the commit message to add more details as well kernel >> >>> docs. >> >>> >> >>> v8: Addressed Maarten's review comments. >> >>> >> >>> v9: Removed macro defines from uapi as per Brian Starkey >> >>> and Daniel Stone's comments and moved to drm include file. >> >>> Moved back to older design with exposing all HDMI >> >>> colo
Re: [Intel-gfx] [PATCH 5/8] drm/i915: Uninterruptibly drain the timelines on unwedging
Chris Wilson writes: > Quoting Mika Kuoppala (2019-02-08 09:46:01) >> Chris Wilson writes: >> >> > On wedging, we mark all executing requests as complete and all pending >> > requests completed as soon as they are ready. Before unwedging though we >> > wish to flush those pending requests prior to restoring default >> > execution, and so we must wait. Do so interruptibly as we do not provide >> >> uninterruptibly? >> >> > the EINTR gracefully back to userspace in this case but persistent in >> >> be persistent? >> >> We lost the gracefullness due to not having the interruptible >> mutex wait on reset path anymore? > > No. We never had graceful handling, as we could never propagate the > EINTR from unwedge back to userspace so it became EIO instead. Now I managed to entertain atleast myself. I try to find a deeper meaning so hard on this... and there it is, in plain sight: the return code is not used. I really did read it before but obviously no rampup in powerstate was involved. Reviewed-by: Mika Kuoppala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/opregion: fix version check
On Fri, 08 Feb 2019, Jani Nikula wrote:
> The u32 version field encodes major version in the high word. We've been
> checking for version >= 0.2.
>
> Add opregion version logging while at it.
>
> Fixes: 04ebaadb9f2d ("drm/i915/opregion: handle VBT sizes bigger than 6 KB")
> Cc: Ville Syrjälä
> Cc: Imre Deak
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_opregion.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 30ae96c5c97c..7e4152d97c45 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -46,6 +46,9 @@
> #define OPREGION_ASLE_EXT_OFFSET 0x1C00
>
> #define OPREGION_SIGNATURE "IntelGraphicsMem"
> +
> +#define OPREGION_VERSION(major, minor) (((major) << 16) | (minor))
> +
> #define MBOX_ACPI (1<<0)
> #define MBOX_SWSCI (1<<1)
> #define MBOX_ASLE (1<<2)
> @@ -924,6 +927,10 @@ int intel_opregion_setup(struct drm_i915_private
> *dev_priv)
> opregion->header = base;
> opregion->lid_state = base + ACPI_CLID;
>
> + DRM_DEBUG_DRIVER("ACPI OpRegion version %u.%u\n",
> + opregion->header->opregion_ver >> 16,
> + opregion->header->opregion_ver & 0x);
> +
This is ridiculous and maddening. On our CI APL this prints [1]:
<7>[7.029368] [drm:intel_opregion_setup [i915]] ACPI OpRegion version 512.0
Yes, version 512.0.
Digging into it, I found one random version of the opregion spec that
has:
Bits [31:16] - Major Version Number
Bits [23:0] - Minor Version Number
The minor is supposed to be [15:0]. But this APL (maybe others, need to
investigate) has the major version encoded to bits 31:24.
This obviously screws up the opregion version check in patch 2 as well,
leading to relative RVDA being used.
Absolutely disgusting.
BR,
Jani.
[1]
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12175/fi-apl-guc/boot0.log
> mboxes = opregion->header->mboxes;
> if (mboxes & MBOX_ACPI) {
> DRM_DEBUG_DRIVER("Public ACPI methods supported\n");
> @@ -952,8 +959,8 @@ int intel_opregion_setup(struct drm_i915_private
> *dev_priv)
> if (dmi_check_system(intel_no_opregion_vbt))
> goto out;
>
> - if (opregion->header->opregion_ver >= 2 && opregion->asle &&
> - opregion->asle->rvda && opregion->asle->rvds) {
> + if (opregion->header->opregion_ver >= OPREGION_VERSION(2, 0) &&
> + opregion->asle && opregion->asle->rvda && opregion->asle->rvds) {
> opregion->rvda = memremap(opregion->asle->rvda,
> opregion->asle->rvds,
> MEMREMAP_WB);
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/opregion: fix version check
On Fri, Feb 08, 2019 at 05:09:51PM +0200, Jani Nikula wrote:
> On Fri, 08 Feb 2019, Jani Nikula wrote:
> > The u32 version field encodes major version in the high word. We've been
> > checking for version >= 0.2.
> >
> > Add opregion version logging while at it.
> >
> > Fixes: 04ebaadb9f2d ("drm/i915/opregion: handle VBT sizes bigger than 6 KB")
> > Cc: Ville Syrjälä
> > Cc: Imre Deak
> > Signed-off-by: Jani Nikula
> > ---
> > drivers/gpu/drm/i915/intel_opregion.c | 11 +--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > b/drivers/gpu/drm/i915/intel_opregion.c
> > index 30ae96c5c97c..7e4152d97c45 100644
> > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > @@ -46,6 +46,9 @@
> > #define OPREGION_ASLE_EXT_OFFSET 0x1C00
> >
> > #define OPREGION_SIGNATURE "IntelGraphicsMem"
> > +
> > +#define OPREGION_VERSION(major, minor) (((major) << 16) | (minor))
> > +
> > #define MBOX_ACPI (1<<0)
> > #define MBOX_SWSCI (1<<1)
> > #define MBOX_ASLE (1<<2)
> > @@ -924,6 +927,10 @@ int intel_opregion_setup(struct drm_i915_private
> > *dev_priv)
> > opregion->header = base;
> > opregion->lid_state = base + ACPI_CLID;
> >
> > + DRM_DEBUG_DRIVER("ACPI OpRegion version %u.%u\n",
> > +opregion->header->opregion_ver >> 16,
> > +opregion->header->opregion_ver & 0x);
> > +
>
> This is ridiculous and maddening. On our CI APL this prints [1]:
>
> <7>[7.029368] [drm:intel_opregion_setup [i915]] ACPI OpRegion version
> 512.0
>
> Yes, version 512.0.
>
> Digging into it, I found one random version of the opregion spec that
> has:
>
> Bits [31:16] - Major Version Number
> Bits [23:0] - Minor Version Number
>
> The minor is supposed to be [15:0]. But this APL (maybe others, need to
> investigate) has the major version encoded to bits 31:24.
>
> This obviously screws up the opregion version check in patch 2 as well,
> leading to relative RVDA being used.
Maybe you should use another version field to decode this version field.
Just kidding:)
>
> Absolutely disgusting.
>
>
> BR,
> Jani.
>
>
> [1]
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12175/fi-apl-guc/boot0.log
>
>
> > mboxes = opregion->header->mboxes;
> > if (mboxes & MBOX_ACPI) {
> > DRM_DEBUG_DRIVER("Public ACPI methods supported\n");
> > @@ -952,8 +959,8 @@ int intel_opregion_setup(struct drm_i915_private
> > *dev_priv)
> > if (dmi_check_system(intel_no_opregion_vbt))
> > goto out;
> >
> > - if (opregion->header->opregion_ver >= 2 && opregion->asle &&
> > - opregion->asle->rvda && opregion->asle->rvds) {
> > + if (opregion->header->opregion_ver >= OPREGION_VERSION(2, 0) &&
> > + opregion->asle && opregion->asle->rvda && opregion->asle->rvds) {
> > opregion->rvda = memremap(opregion->asle->rvda,
> > opregion->asle->rvds,
> > MEMREMAP_WB);
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/i915: Uninterruptibly drain the timelines on unwedging
Quoting Mika Kuoppala (2019-02-08 15:07:55) > Chris Wilson writes: > > > Quoting Mika Kuoppala (2019-02-08 09:46:01) > >> Chris Wilson writes: > >> > >> > On wedging, we mark all executing requests as complete and all pending > >> > requests completed as soon as they are ready. Before unwedging though we > >> > wish to flush those pending requests prior to restoring default > >> > execution, and so we must wait. Do so interruptibly as we do not provide > >> > >> uninterruptibly? > >> > >> > the EINTR gracefully back to userspace in this case but persistent in > >> > >> be persistent? > >> > >> We lost the gracefullness due to not having the interruptible > >> mutex wait on reset path anymore? > > > > No. We never had graceful handling, as we could never propagate the > > EINTR from unwedge back to userspace so it became EIO instead. > > Now I managed to entertain atleast myself. > I try to find a deeper meaning so hard on this... > > and there it is, in plain sight: the return code > is not used. I really did read it before > but obviously no rampup in powerstate was involved. Exactly. A task for the future would be to use killable here, let the user die and leave the machine wedged. But that requires a bit more effort :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable P0xx (planar), Y2xx and Y4xx (packed) pixel formats
== Series Details ==
Series: Enable P0xx (planar), Y2xx and Y4xx (packed) pixel formats
URL : https://patchwork.freedesktop.org/series/56402/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
38dc7fc809e3 drm: Add P010, P012, P016 format definitions and fourcc
-:28: WARNING:LONG_LINE: line over 100 characters
#28: FILE: drivers/gpu/drm/drm_fourcc.c:229:
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
-:29: WARNING:LONG_LINE: line over 100 characters
#29: FILE: drivers/gpu/drm/drm_fourcc.c:230:
+ { .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
-:30: WARNING:LONG_LINE: line over 100 characters
#30: FILE: drivers/gpu/drm/drm_fourcc.c:231:
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
-:48: WARNING:LONG_LINE_COMMENT: line over 100 characters
#48: FILE: include/uapi/drm/drm_fourcc.h:204:
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane, 10 bit per channel */
-:49: WARNING:LONG_LINE_COMMENT: line over 100 characters
#49: FILE: include/uapi/drm/drm_fourcc.h:205:
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cr:Cb plane, 12 bit per channel */
-:50: WARNING:LONG_LINE_COMMENT: line over 100 characters
#50: FILE: include/uapi/drm/drm_fourcc.h:206:
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cr:Cb plane, 16 bit per channel */
total: 0 errors, 6 warnings, 0 checks, 25 lines checked
f74a10ecf9d5 drm/i915: Add P010, P012, P016 plane control definitions
b1b27b4ea1a4 drm/i915: preparations for enabling P010, P012, P016 formats
a2b1c9c3bdb9 drm/i915: enable P010, P012, P016 formats for primary and sprite
planes
-:20: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#20: FILE: drivers/gpu/drm/i915/intel_sprite.c:1835:
+static const uint32_t glk_planar_formats[] = {
total: 0 errors, 0 warnings, 1 checks, 40 lines checked
920311db8b32 drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
-:47: WARNING:LONG_LINE: line over 100 characters
#47: FILE: drivers/gpu/drm/drm_fourcc.c:232:
+ { .format = DRM_FORMAT_Y210,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
-:48: WARNING:LONG_LINE: line over 100 characters
#48: FILE: drivers/gpu/drm/drm_fourcc.c:233:
+ { .format = DRM_FORMAT_Y212,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
-:49: WARNING:LONG_LINE: line over 100 characters
#49: FILE: drivers/gpu/drm/drm_fourcc.c:234:
+ { .format = DRM_FORMAT_Y216,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
-:50: WARNING:LONG_LINE: line over 100 characters
#50: FILE: drivers/gpu/drm/drm_fourcc.c:235:
+ { .format = DRM_FORMAT_Y410,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
-:51: WARNING:LONG_LINE: line over 100 characters
#51: FILE: drivers/gpu/drm/drm_fourcc.c:236:
+ { .format = DRM_FORMAT_Y412,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
-:52: WARNING:LONG_LINE: line over 100 characters
#52: FILE: drivers/gpu/drm/drm_fourcc.c:237:
+ { .format = DRM_FORMAT_Y416,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
-:65: WARNING:LONG_LINE_COMMENT: line over 100 characters
#65: FILE: include/uapi/drm/drm_fourcc.h:154:
+#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* [31:0]
X:Y:Cb:Cr 8:8:8:8 little endian */
-:71: WARNING:LONG_LINE_COMMENT: line over 100 characters
#71: FILE: include/uapi/drm/drm_fourcc.h:160:
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian per 2 Y pixels */
-:72: WARNING:LONG_LINE_COMMENT: line over 100 characters
#72: FILE: include/uapi/drm/drm_fourcc.h:161:
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
Y0:x:Cb0:x:Y1:x:Cr1:x 12:4:12:4:12:4:12:4 little endian per 2 Y pixels */
-:73: WARNING:LONG_LINE_COMMENT: line over 100 characters
#73: FILE: include/uapi/drm/drm_fourcc.h:162:
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian per 2 Y pixels */
-:79: WARNING:LONG_LINE_COMMENT: line over 100 characters
#79: FILE: include/uapi/drm/drm_fourcc.h:168:
+#define DRM_FORMAT_Y410 fourcc_code('Y', '4', '1', '0') /* [31:0]
X:V:Y:U 2:10:10:10 little endian */
-:80: WARNING:LONG_LINE_COMMENT: line over 100 characters
#
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable P0xx (planar), Y2xx and Y4xx (packed) pixel formats
== Series Details == Series: Enable P0xx (planar), Y2xx and Y4xx (packed) pixel formats URL : https://patchwork.freedesktop.org/series/56402/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm: Add P010, P012, P016 format definitions and fourcc Okay! Commit: drm/i915: Add P010, P012, P016 plane control definitions Okay! Commit: drm/i915: preparations for enabling P010, P012, P016 formats -O:drivers/gpu/drm/i915/intel_display.c:13835:21: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_display.c:13835:21: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_display.c:13850:21: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_display.c:13850:21: warning: expression using sizeof(void) Commit: drm/i915: enable P010, P012, P016 formats for primary and sprite planes Okay! Commit: drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc Okay! Commit: drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control definitions Okay! Commit: drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for universal planes Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] components: multiple components for a device
On Fri, Feb 08, 2019 at 10:28:49AM +, Russell King - ARM Linux admin wrote:
> On Fri, Feb 08, 2019 at 12:27:57AM +0100, Daniel Vetter wrote:
> > Component framework is extended to support multiple components for
> > a struct device. These will be matched with different masters based on
> > its sub component value.
> >
> > We are introducing this, as I915 needs two different components
> > with different subcomponent value, which will be matched to two
> > different component masters(Audio and HDCP) based on the subcomponent
> > values.
> >
> > v2: Add documenation.
> >
> > v3: Rebase on top of updated documenation.
> >
> > v4: Review from Rafael:
> > - Remove redundant "This" from kerneldoc (also in the previous patch)
> > - Streamline the logic in find_component() a bit.
> >
> > Signed-off-by: Daniel Vetter (v1 code)
> > Signed-off-by: Ramalingam C (v1 commit message)
> > Cc: Ramalingam C
> > Cc: Greg Kroah-Hartman
> > Cc: Russell King
> > Cc: Rafael J. Wysocki
> > Cc: Jaroslav Kysela
> > Cc: Takashi Iwai
> > Cc: Rodrigo Vivi
> > Cc: Jani Nikula
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/base/component.c | 158 +-
> > include/linux/component.h | 10 ++-
> > 2 files changed, 129 insertions(+), 39 deletions(-)
> >
> > diff --git a/drivers/base/component.c b/drivers/base/component.c
> > index 1624c2a892a5..7dbc41cccd58 100644
> > --- a/drivers/base/component.c
> > +++ b/drivers/base/component.c
> > @@ -47,6 +47,7 @@ struct component;
> > struct component_match_array {
> > void *data;
> > int (*compare)(struct device *, void *);
> > + int (*compare_typed)(struct device *, int, void *);
> > void (*release)(struct device *, void *);
> > struct component *component;
> > bool duplicate;
> > @@ -74,6 +75,7 @@ struct component {
> > bool bound;
> >
> > const struct component_ops *ops;
> > + int subcomponent;
> > struct device *dev;
> > };
> >
> > @@ -158,7 +160,7 @@ static struct master *__master_find(struct device *dev,
> > }
> >
> > static struct component *find_component(struct master *master,
> > - int (*compare)(struct device *, void *), void *compare_data)
> > + struct component_match_array *mc)
> > {
> > struct component *c;
> >
> > @@ -166,7 +168,11 @@ static struct component *find_component(struct master
> > *master,
> > if (c->master && c->master != master)
> > continue;
> >
> > - if (compare(c->dev, compare_data))
> > + if (mc->compare && mc->compare(c->dev, mc->data))
> > + return c;
> > +
> > + if (mc->compare_typed &&
> > + mc->compare_typed(c->dev, c->subcomponent, mc->data))
> > return c;
> > }
> >
> > @@ -192,7 +198,7 @@ static int find_components(struct master *master)
> > if (match->compare[i].component)
> > continue;
> >
> > - c = find_component(master, mc->compare, mc->data);
> > + c = find_component(master, mc);
> > if (!c) {
> > ret = -ENXIO;
> > break;
> > @@ -327,29 +333,12 @@ static int component_match_realloc(struct device *dev,
> > return 0;
> > }
> >
> > -/**
> > - * component_match_add_release - add a component match with release
> > callback
> > - * @master: device with the aggregate driver
> > - * @matchptr: pointer to the list of component matches
> > - * @release: release function for @compare_data
> > - * @compare: compare function to match against all components
> > - * @compare_data: opaque pointer passed to the @compare function
> > - *
> > - * Adds a new component match to the list stored in @matchptr, which the
> > @master
> > - * aggregate driver needs to function. The list of component matches
> > pointed to
> > - * by @matchptr must be initialized to NULL before adding the first match.
> > - *
> > - * The allocated match list in @matchptr is automatically released using
> > devm
> > - * actions, where upon @release will be called to free any references held
> > by
> > - * @compare_data, e.g. when @compare_data is a &device_node that must be
> > - * released with of_node_put().
> > - *
> > - * See also component_match_add().
> > - */
> > -void component_match_add_release(struct device *master,
> > +static void __component_match_add(struct device *master,
> > struct component_match **matchptr,
> > void (*release)(struct device *, void *),
> > - int (*compare)(struct device *, void *), void *compare_data)
> > + int (*compare)(struct device *, void *),
> > + int (*compare_typed)(struct device *, int, void *),
> > + void *compare_data)
> > {
> > struct component_match *match = *matchptr;
> >
> > @@ -381,13 +370,69 @@ void component_match_add_release(struct device
> > *master,
> > }
> >
> > match->compare[match->num].compare = compare;
> > + match->compare[match->num].compare_typed
Re: [Intel-gfx] [RFC 1/6] drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11
Op 31-01-2019 om 22:10 schreef Gwan-gyeong Mun: > Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to > HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and > HDMI ports. > > Signed-off-by: Gwan-gyeong Mun > --- > drivers/gpu/drm/i915/intel_dp.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 681e88405ada..ad7382d3be86 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -6923,6 +6923,9 @@ intel_dp_init_connector(struct intel_digital_port > *intel_dig_port, > connector->interlace_allowed = true; > connector->doublescan_allowed = 0; > > + if (INTEL_GEN(dev_priv) >= 11) > + connector->ycbcr_420_allowed = true; > + > intel_encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port); > > intel_dp_aux_init(intel_dp); This should probably be done as last patch (6/6). Otherwise looks good. Reviewed-by: Maarten Lankhorst ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] component: Add documentation
On Fri, Feb 08, 2019 at 12:51:23PM +0100, Greg Kroah-Hartman wrote: > On Fri, Feb 08, 2019 at 12:27:56AM +0100, Daniel Vetter wrote: > > While typing these I think doing an s/component_master/aggregate/ > > would be useful: > > - it's shorter :-) > > - I think component/aggregate is much more meaningful naming than > > component/puppetmaster or something like that. At least to my > > English ear "aggregate" emphasizes much more the "assemble a pile of > > things into something bigger" aspect, and there's not really much > > of a control hierarchy between aggregate and constituing components. > > > > But that's way more than a quick doc typing exercise ... > > > > Thanks to Ram for commenting on an initial draft of these docs. > > > > v2: Review from Rafael: > > - git add Documenation/driver-api/component.rst > > - lots of polish to the wording + spelling fixes. > > > > v3: Review from Russell: > > - s/framework/helper > > - clarify the documentation for component_match_add functions. > > > > v4: Remove a few superflous "This". > > > > Reviewed-by: Rafael J. Wysocki > > Cc: "C, Ramalingam" > > Cc: Greg Kroah-Hartman > > Cc: Russell King > > Cc: Rafael J. Wysocki > > Cc: Jaroslav Kysela > > Cc: Takashi Iwai > > Cc: Rodrigo Vivi > > Cc: Jani Nikula > > Signed-off-by: Daniel Vetter > > Thanks for doing this! > > Reviewed-by: Greg Kroah-Hartman Thanks for reviewing (obviously includes Rafael and Russell too)! For merging I see two options: - All through drm-intel, but will only land in 5.2 because the feature cut-off has already happened for i915. So a bit awkward. - Topic branch with the 2 component patches plus the snd-hda/drm-i915 patch, so that you/Takashi/drm can pull it in as needed. The drm component doc patch (3/4 in this series) I can pull in later on. Greg/Takashi, any preferences? 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
Re: [Intel-gfx] [RFC 6/6] drm/i915/dp: Update pipe_bpp for DP YCbCr4:2:0 outputs
Op 31-01-2019 om 22:10 schreef Gwan-gyeong Mun:
> pipe_bpp value was assumed RGB therefore it was multiplied with 3.
> But YCbCr 4:2:0 requires multiplier value to 1.5 therefore it divides
> pipe_bpp to 2.
> - RGB bpp = bpc x 3
> - YCbCr 4:2:0 bpp = bpc x 1.5
>
> Signed-off-by: Gwan-gyeong Mun
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 7 +-
> drivers/gpu/drm/i915/intel_dp.c | 41 ++--
> 2 files changed, 40 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index c6aed2b06a59..7f56aa7842c1 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1696,6 +1696,7 @@ void intel_ddi_set_pipe_settings(const struct
> intel_crtc_state *crtc_state)
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> u32 temp;
> + int bpp;
>
> if (!intel_crtc_has_dp_encoder(crtc_state))
> return;
> @@ -1707,7 +1708,11 @@ void intel_ddi_set_pipe_settings(const struct
> intel_crtc_state *crtc_state)
> if (crtc_state->limited_color_range)
> temp |= TRANS_MSA_CEA_RANGE;
>
> - switch (crtc_state->pipe_bpp) {
> + bpp = crtc_state->pipe_bpp;
> + if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> + bpp *= 2;
> +
> + switch (bpp) {
> case 18:
> temp |= TRANS_MSA_6_BPC;
> break;
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 3a9a5a3c33a9..734c5743e03f 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1761,12 +1761,13 @@ static int intel_dp_compute_bpp(struct intel_dp
> *intel_dp,
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> struct intel_connector *intel_connector = intel_dp->attached_connector;
> int bpp, bpc;
> + int bpp_divider = pipe_config->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR420 ? 2 : 1;
>
> bpp = pipe_config->pipe_bpp;
> bpc = drm_dp_downstream_max_bpc(intel_dp->dpcd,
> intel_dp->downstream_ports);
>
> if (bpc > 0)
> - bpp = min(bpp, 3*bpc);
> + bpp = min(bpp, 3*bpc/bpp_divider);
>
> if (intel_dp_is_edp(intel_dp)) {
> /* Get bpp from vbt only for panels that dont have bpp in edid
> */
> @@ -1787,12 +1788,14 @@ intel_dp_adjust_compliance_config(struct intel_dp
> *intel_dp,
> struct intel_crtc_state *pipe_config,
> struct link_config_limits *limits)
> {
> + int bpp_divider = pipe_config->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR420 ? 2 : 1;
> +
> /* For DP Compliance we override the computed bpp for the pipe */
> if (intel_dp->compliance.test_data.bpc != 0) {
> - int bpp = 3 * intel_dp->compliance.test_data.bpc;
> + int bpp = 3 * intel_dp->compliance.test_data.bpc / bpp_divider;
>
> limits->min_bpp = limits->max_bpp = bpp;
> - pipe_config->dither_force_disable = bpp == 6 * 3;
> + pipe_config->dither_force_disable = bpp == 6 * 3 / bpp_divider;
>
> DRM_DEBUG_KMS("Setting pipe_bpp to %d\n", bpp);
> }
> @@ -1826,8 +1829,9 @@ intel_dp_compute_link_config_wide(struct intel_dp
> *intel_dp,
> struct drm_display_mode *adjusted_mode =
> &pipe_config->base.adjusted_mode;
> int bpp, clock, lane_count;
> int mode_rate, link_clock, link_avail;
> + int bpp_divider = pipe_config->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR420 ? 2 : 1;
>
> - for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> + for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3 /
> bpp_divider) {
> mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> bpp);
>
> @@ -1862,8 +1866,9 @@ intel_dp_compute_link_config_fast(struct intel_dp
> *intel_dp,
> struct drm_display_mode *adjusted_mode =
> &pipe_config->base.adjusted_mode;
> int bpp, clock, lane_count;
> int mode_rate, link_clock, link_avail;
> + int bpp_divider = pipe_config->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR420 ? 2 : 1;
>
> - for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> + for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3 /
> bpp_divider) {
> mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> bpp);
>
> @@ -2009,6 +2014,7 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
> struct link_config_limits limits;
> int common_len;
> int ret;
> + int bpp_divider = pipe_config->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR420 ? 2 : 1;
>
> common_len = intel_dp_common_len_ra
Re: [Intel-gfx] [RFC 4/6] drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry Format
Op 31-01-2019 om 22:10 schreef Gwan-gyeong Mun:
> Function intel_pixel_encoding_setup_vsc handles vsc header and data block
> setup for pixel encoding / colorimetry format.
>
> Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
> for pixel encoding / colorimetry format as per dp 1.4a spec,
> section 2.2.5.7.1, table 2-119: VSC SDP Header Bytes, section 2.2.5.7.5,
> table 2-120:VSC SDP Payload for DB16 through DB18.
>
> Signed-off-by: Gwan-gyeong Mun
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 1 +
> drivers/gpu/drm/i915/intel_dp.c | 72
> drivers/gpu/drm/i915/intel_drv.h | 2 +
> 3 files changed, 75 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ca705546a0ab..8969f03393b8 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3400,6 +3400,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
> *encoder,
>
> intel_edp_backlight_on(crtc_state, conn_state);
> intel_psr_enable(intel_dp, crtc_state);
> + intel_dp_ycbcr_420_enable(intel_dp, crtc_state);
> intel_edp_drrs_enable(intel_dp, crtc_state);
>
> if (crtc_state->has_audio)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index a61aff23c8b2..3a9a5a3c33a9 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4402,6 +4402,78 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp
> *intel_dp,
> return 0;
> }
>
> +static void
> +intel_pixel_encoding_setup_vsc(struct intel_dp *intel_dp,
> +const struct intel_crtc_state *crtc_state)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct dp_vsc_sdp vsc_sdp;
> +
> + if (!intel_dp->attached_connector->base.ycbcr_420_allowed) return;
> +
Newline missing?
> + /* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119 */
> + memset(&vsc_sdp, 0, sizeof(vsc_sdp));
> + vsc_sdp.sdp_header.HB0 = 0;
> + vsc_sdp.sdp_header.HB1 = 0x7;
> +
> + /* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
> + * Colorimetry Format indication. A DP Source device is allowed
> + * to indicate the pixel encoding/colorimetry format to the DP Sink
> + * device with VSC SDP only when the DP Sink device supports it
> + * (i.e., VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in the
> register
> + * DPRX_FEATURE_ENUMERATION_LIST (DPCD Address 02210h, bit 3) is set to
> 1)
> + */
> + vsc_sdp.sdp_header.HB2 = 0x5;
> +
> + /* VSC SDP supporting 3D stereo, + PSR2, + Pixel Encoding/
> + * Colorimetry Format indication (HB2 = 05h).
> + */
> + vsc_sdp.sdp_header.HB3 = 0x13;
> + /* YCbCr 420 = 3h DB16[7:4] ITU-R BT.601 = 0h, ITU-R BT.709 = 1h
> + * DB16[3:0] DP 1.4a spec, Table 2-120
> + */
> +
> + /* https://patchwork.freedesktop.org/patch/166830/ i915 implementations
> + * uses BT.709 color space
> + */
I think we should refer to commit ids instead of patchwork. :)
> + vsc_sdp.DB16 = 0x3 << 4; /* 0x3 << 4 , YCbCr 420*/
> + vsc_sdp.DB16 |= 0x1; /* 0x1, ITU-R BT.709 */
But speaking of patchwork, might be nice to setup a VSC for not yuv420 as well.
This could be used for https://patchwork.freedesktop.org/series/47132/
:)
> + /* For pixel encoding formats YCbCr444, YCbCr422, YCbCr420, and Y Only,
> + * the following Component Bit Depth values are defined:
> + * 001b = 8bpc.
> + * 010b = 10bpc.
> + * 011b = 12bpc.
> + * 100b = 16bpc.
> + */
> + vsc_sdp.DB17 = 0x1;
> +
> + /*
> + * Content Type (Bits 2:0)
> + * 000b = Not defined.
> + * 001b = Graphics.
> + * 010b = Photo.
> + * 011b = Video.
> + * 100b = Game
> + * All other values are RESERVED.
> + * Note: See CTA-861-G for the definition and expected
> + * processing by a stream sink for the above contect types.
> + */
> + vsc_sdp.DB18 = 0;
> +
> + intel_dig_port->write_infoframe(&intel_dig_port->base,
> + crtc_state, DP_SDP_VSC, &vsc_sdp, sizeof(vsc_sdp));
> +}
> +
This should probably be less hardcoded in the future, but looks ok for now.
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable P0xx (planar), Y2xx and Y4xx (packed) pixel formats
== Series Details ==
Series: Enable P0xx (planar), Y2xx and Y4xx (packed) pixel formats
URL : https://patchwork.freedesktop.org/series/56402/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5567 -> Patchwork_12177
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56402/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12177 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@pm_rpm@basic-rte:
- fi-byt-j1900: PASS -> FAIL [fdo#108800]
Possible fixes
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (49 -> 45)
--
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5567 -> Patchwork_12177
CI_DRM_5567: 5725867972123d46f4a4d382ed5fa2eb0348b00c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4815: 947301563259726b65ce47d3a3fe37931ed42efe @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12177: d370590c113c75c3e9ad5f138ad903c3ca628eec @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d370590c113c drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for
universal planes
1160d89040e9 drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control
definitions
920311db8b32 drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
a2b1c9c3bdb9 drm/i915: enable P010, P012, P016 formats for primary and sprite
planes
b1b27b4ea1a4 drm/i915: preparations for enabling P010, P012, P016 formats
f74a10ecf9d5 drm/i915: Add P010, P012, P016 plane control definitions
38dc7fc809e3 drm: Add P010, P012, P016 format definitions and fourcc
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12177/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't claim an unstarted request was guilty
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-02-08 14:47:13)
>> Chris Wilson writes:
>>
>> > If we haven't even begun executing the payload of the stalled request,
>> > then we should not claim that its userspace context was guilty of
>> > submitting a hanging batch.
>> >
>> > v2: Check for context corruption before trying to restart.
>> > v3: Preserve semaphores on skipping requests (need to keep the timelines
>> > intact).
>> >
>> > Signed-off-by: Chris Wilson
>> > ---
>> > drivers/gpu/drm/i915/intel_lrc.c | 42 +--
>> > drivers/gpu/drm/i915/selftests/igt_spinner.c | 9 +++-
>> > .../gpu/drm/i915/selftests/intel_hangcheck.c | 6 +++
>> > 3 files changed, 53 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
>> > b/drivers/gpu/drm/i915/intel_lrc.c
>> > index 5e98fd79bd9d..e3134a635926 100644
>> > --- a/drivers/gpu/drm/i915/intel_lrc.c
>> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> > @@ -1387,6 +1387,10 @@ static int gen8_emit_init_breadcrumb(struct
>> > i915_request *rq)
>> > *cs++ = rq->fence.seqno - 1;
>> >
>> > intel_ring_advance(rq, cs);
>> > +
>> > + /* Record the updated position of the request's payload */
>> > + rq->infix = intel_ring_offset(rq, cs);
>> > +
>> > return 0;
>> > }
>> >
>> > @@ -1878,6 +1882,23 @@ static void execlists_reset_prepare(struct
>> > intel_engine_cs *engine)
>> > spin_unlock_irqrestore(&engine->timeline.lock, flags);
>> > }
>> >
>> > +static bool lrc_regs_ok(const struct i915_request *rq)
>> > +{
>> > + const struct intel_ring *ring = rq->ring;
>> > + const u32 *regs = rq->hw_context->lrc_reg_state;
>> > +
>> > + /* Quick spot check for the common signs of context corruption */
>> > +
>> > + if (regs[CTX_RING_BUFFER_CONTROL + 1] !=
>> > + (RING_CTL_SIZE(ring->size) | RING_VALID))
>> > + return false;
>>
>> You been noticing this with ctx corruption? Well now
>> thinking about it, we have had reports where on init,
>> on some trouble, the valid vanishes.
>
> Yes, it's why we've been copying the default context over guilty for a
> long time (pretty much since live_hangcheck became a thing iirc).
>
>> > +
>> > + if (regs[CTX_RING_BUFFER_START + 1] != i915_ggtt_offset(ring->vma))
>> > + return false;
>> > +
>>
>> Seen this on bugzilla reports too. Are there more
>> in your sleeve or is this a compromise on complexity
>> and performance? Checking on a sane actual head too?
>
> No, I can't remember seeing this, just loosing CTL. But I do recall that
> at one point it seemed the whole reg state was zero, but that is foggy
> memory.
I might mix this with the failed init where the start was
bogus/stale. Looked like after the hang, the hardware just
swapped to a previous ctx without any provocation.
Regardless of the reason, this will guard the
restart.
>
>> The heuristics of it bothers me some as we will
>> get false positives.
>
> They cannot be false positives! If we restore to a batch setup like
> this, it will hang -- which is why we explicitly reset them.
>
>> So in effect, when we get one, we just move ahead
>> after an extra reset as we got it all wrong?
>
> Yup. The context is corrupt, we replace it with a sane one and hope
> nobody notices. Mesa does notice though
We tell them about our shortcomings, if they choose to listen.
Reviewed-by: Mika Kuoppala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
On Fri, Feb 08, 2019 at 03:03:34PM +, Shankar, Uma wrote: > > > >-Original Message- > >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > >Sent: Friday, February 8, 2019 8:08 PM > >To: Sharma, Shashank > >Cc: Shankar, Uma ; intel-gfx@lists.freedesktop.org; > >Syrjala, Ville ; dri-de...@lists.freedesktop.org; > >Lankhorst, > >Maarten > >Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property > > > >On Fri, Feb 08, 2019 at 07:36:24PM +0530, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >> On 2/8/2019 7:00 PM, Ville Syrjälä wrote: > >> > On Fri, Feb 08, 2019 at 06:36:39PM +0530, Sharma, Shashank wrote: > >> >> Regards > >> >> > >> >> Shashank > >> >> > >> >> On 2/8/2019 6:22 PM, Ville Syrjälä wrote: > >> >>> On Fri, Feb 08, 2019 at 12:36:25PM +, Sharma, Shashank wrote: > >> Regards > >> Shashank > >> > >> > -Original Message- > >> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] > >> > On Behalf Of Shankar, Uma > >> > Sent: Friday, February 8, 2019 5:45 PM > >> > To: Ville Syrjälä > >> > Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville > >> > ; dri- de...@lists.freedesktop.org; > >> > Lankhorst, Maarten > >> > Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace > >> > property > >> > > >> >> -Original Message- > >> >> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > >> >> Sent: Tuesday, February 5, 2019 10:02 PM > >> >> To: Shankar, Uma > >> >> Cc: intel-gfx@lists.freedesktop.org; > >> >> dri-de...@lists.freedesktop.org; Syrjala, Ville > >> >> ; Lankhorst, Maarten > >> >> > >> >> Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace > >> >> property > >> >> > >> >> On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote: > >> >>> Create a new connector property to program colorspace to sink > >devices. > >> >>> Modern sink devices support more than 1 type of colorspace > >> >>> like 601, 709, BT2020 etc. This helps to switch based on > >> >>> content type which is to be displayed. The decision lies > >> >>> with compositors as to in which scenarios, a particular > >> >>> colorspace will > >be picked. > >> >>> > >> >>> This will be helpful mostly to switch to higher gamut > >> >>> colorspaces like > >> >>> BT2020 when the media content is encoded as BT2020. > >> >>> Thereby giving a good visual experience to users. > >> >>> > >> >>> The expectation from userspace is that it should parse the > >> >>> EDID and get supported colorspaces. Use this property and > >> >>> switch to the one supported. Sink supported colorspaces > >> >>> should be retrieved by userspace from EDID and driver will > >> >>> not explicitly expose > >> >> them. > >> >>> Basically the expectation from userspace is: > >> >>>- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink > >> >>> colorspace > >> >>>- Set this new property to let the sink know what it > >> >>> converted the CRTC output to. > >> >>> > >> >>> v2: Addressed Maarten and Ville's review comments. > >> >>> Enhanced the colorspace enum to incorporate both HDMI and > >> >>> DP supported > >> >> colorspaces. > >> >>> Also, added a default option for colorspace. > >> >>> > >> >>> v3: Removed Adobe references from enum definitions as per > >> >>> Ville, Hans Verkuil and Jonas Karlman suggestions. Changed > >> >>> Default to an unset state where driver will assign the > >> >>> colorspace is not chosen by user, suggested by Ville and > >> >>> Maarten. Addressed other misc review comments from Maarten. > >> >>> Split the changes to have separate colorspace property for DP > >> >>> and > >HDMI. > >> >>> > >> >>> v4: Addressed Chris and Ville's review comments, and > >> >>> created a common colorspace property for DP and HDMI, > >> >>> filtered the list based on the colorspaces supported by the > >> >>> respective > >protocol standard. > >> >>> > >> >>> v5: Made the property creation helper accept enum list > >> >>> based on platform capabilties as suggested by Shashank. > >> >>> Consolidated HDMI and DP property creation in the common > >> >>> helper. > >> >>> > >> >>> v6: Addressed Shashank's review comments. > >> >>> > >> >>> v7: Added defines instead of enum in uapi as per Brian > >> >>> Starkey's suggestion in order to go with string matching at > >> >>> userspace. > >> >>> Updated the commit message to add more details as well kernel > >> >>> docs. >
Re: [Intel-gfx] [PATCH 2/4] components: multiple components for a device
On Fri, Feb 8, 2019 at 4:23 PM Daniel Vetter wrote:
>
> On Fri, Feb 08, 2019 at 10:28:49AM +, Russell King - ARM Linux admin
> wrote:
> > On Fri, Feb 08, 2019 at 12:27:57AM +0100, Daniel Vetter wrote:
> > > Component framework is extended to support multiple components for
> > > a struct device. These will be matched with different masters based on
> > > its sub component value.
> > >
> > > We are introducing this, as I915 needs two different components
> > > with different subcomponent value, which will be matched to two
> > > different component masters(Audio and HDCP) based on the subcomponent
> > > values.
> > >
> > > v2: Add documenation.
> > >
> > > v3: Rebase on top of updated documenation.
> > >
> > > v4: Review from Rafael:
> > > - Remove redundant "This" from kerneldoc (also in the previous patch)
> > > - Streamline the logic in find_component() a bit.
> > >
> > > Signed-off-by: Daniel Vetter (v1 code)
> > > Signed-off-by: Ramalingam C (v1 commit message)
> > > Cc: Ramalingam C
> > > Cc: Greg Kroah-Hartman
> > > Cc: Russell King
> > > Cc: Rafael J. Wysocki
> > > Cc: Jaroslav Kysela
> > > Cc: Takashi Iwai
> > > Cc: Rodrigo Vivi
> > > Cc: Jani Nikula
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/base/component.c | 158 +-
> > > include/linux/component.h | 10 ++-
> > > 2 files changed, 129 insertions(+), 39 deletions(-)
> > >
> > > diff --git a/drivers/base/component.c b/drivers/base/component.c
> > > index 1624c2a892a5..7dbc41cccd58 100644
> > > --- a/drivers/base/component.c
> > > +++ b/drivers/base/component.c
> > > @@ -47,6 +47,7 @@ struct component;
> > > struct component_match_array {
> > > void *data;
> > > int (*compare)(struct device *, void *);
> > > + int (*compare_typed)(struct device *, int, void *);
> > > void (*release)(struct device *, void *);
> > > struct component *component;
> > > bool duplicate;
> > > @@ -74,6 +75,7 @@ struct component {
> > > bool bound;
> > >
> > > const struct component_ops *ops;
> > > + int subcomponent;
> > > struct device *dev;
> > > };
> > >
> > > @@ -158,7 +160,7 @@ static struct master *__master_find(struct device
> > > *dev,
> > > }
> > >
> > > static struct component *find_component(struct master *master,
> > > - int (*compare)(struct device *, void *), void *compare_data)
> > > + struct component_match_array *mc)
> > > {
> > > struct component *c;
> > >
> > > @@ -166,7 +168,11 @@ static struct component *find_component(struct
> > > master *master,
> > > if (c->master && c->master != master)
> > > continue;
> > >
> > > - if (compare(c->dev, compare_data))
> > > + if (mc->compare && mc->compare(c->dev, mc->data))
> > > + return c;
> > > +
> > > + if (mc->compare_typed &&
> > > + mc->compare_typed(c->dev, c->subcomponent, mc->data))
> > > return c;
> > > }
> > >
> > > @@ -192,7 +198,7 @@ static int find_components(struct master *master)
> > > if (match->compare[i].component)
> > > continue;
> > >
> > > - c = find_component(master, mc->compare, mc->data);
> > > + c = find_component(master, mc);
> > > if (!c) {
> > > ret = -ENXIO;
> > > break;
> > > @@ -327,29 +333,12 @@ static int component_match_realloc(struct device
> > > *dev,
> > > return 0;
> > > }
> > >
> > > -/**
> > > - * component_match_add_release - add a component match with release
> > > callback
> > > - * @master: device with the aggregate driver
> > > - * @matchptr: pointer to the list of component matches
> > > - * @release: release function for @compare_data
> > > - * @compare: compare function to match against all components
> > > - * @compare_data: opaque pointer passed to the @compare function
> > > - *
> > > - * Adds a new component match to the list stored in @matchptr, which the
> > > @master
> > > - * aggregate driver needs to function. The list of component matches
> > > pointed to
> > > - * by @matchptr must be initialized to NULL before adding the first
> > > match.
> > > - *
> > > - * The allocated match list in @matchptr is automatically released using
> > > devm
> > > - * actions, where upon @release will be called to free any references
> > > held by
> > > - * @compare_data, e.g. when @compare_data is a &device_node that must be
> > > - * released with of_node_put().
> > > - *
> > > - * See also component_match_add().
> > > - */
> > > -void component_match_add_release(struct device *master,
> > > +static void __component_match_add(struct device *master,
> > > struct component_match **matchptr,
> > > void (*release)(struct device *, void *),
> > > - int (*compare)(struct device *, void *), void *compare_data)
> > > + int (*compare)(struct device *, void *),
> > > + int (*compare_typed)(struct device *, int, void *
[Intel-gfx] [CI 1/7] drm/i915: Defer removing fence register tracking to rpm wakeup
Currently, we may simultaneously release the fence register from both
fence_update() and i915_gem_restore_fences(). This is dangerous, so
defer the bookkeeping entirely to i915_gem_restore_fences() when the
device is asleep.
Reported-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 62 ---
1 file changed, 32 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index e037e94792f3..be89bd95ab7c 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -210,6 +210,7 @@ static int fence_update(struct drm_i915_fence_reg *fence,
struct i915_vma *vma)
{
intel_wakeref_t wakeref;
+ struct i915_vma *old;
int ret;
if (vma) {
@@ -229,49 +230,55 @@ static int fence_update(struct drm_i915_fence_reg *fence,
return ret;
}
- if (fence->vma) {
- struct i915_vma *old = fence->vma;
-
+ old = xchg(&fence->vma, NULL);
+ if (old) {
ret = i915_active_request_retire(&old->last_fence,
&old->obj->base.dev->struct_mutex);
- if (ret)
+ if (ret) {
+ fence->vma = old;
return ret;
+ }
i915_vma_flush_writes(old);
- }
- if (fence->vma && fence->vma != vma) {
- /* Ensure that all userspace CPU access is completed before
+ /*
+* Ensure that all userspace CPU access is completed before
* stealing the fence.
*/
- GEM_BUG_ON(fence->vma->fence != fence);
- i915_vma_revoke_mmap(fence->vma);
-
- fence->vma->fence = NULL;
- fence->vma = NULL;
+ if (old != vma) {
+ GEM_BUG_ON(old->fence != fence);
+ i915_vma_revoke_mmap(old);
+ old->fence = NULL;
+ }
list_move(&fence->link, &fence->i915->mm.fence_list);
}
- /* We only need to update the register itself if the device is awake.
+ /*
+* We only need to update the register itself if the device is awake.
* If the device is currently powered down, we will defer the write
* to the runtime resume, see i915_gem_restore_fences().
+*
+* This only works for removing the fence register, on acquisition
+* the caller must hold the rpm wakeref. The fence register must
+* be cleared before we can use any other fences to ensure that
+* the new fences do not overlap the elided clears, confusing HW.
*/
wakeref = intel_runtime_pm_get_if_in_use(fence->i915);
- if (wakeref) {
- fence_write(fence, vma);
- intel_runtime_pm_put(fence->i915, wakeref);
+ if (!wakeref) {
+ GEM_BUG_ON(vma);
+ return 0;
}
- if (vma) {
- if (fence->vma != vma) {
- vma->fence = fence;
- fence->vma = vma;
- }
+ fence_write(fence, vma);
+ fence->vma = vma;
+ if (vma) {
+ vma->fence = fence;
list_move_tail(&fence->link, &fence->i915->mm.fence_list);
}
+ intel_runtime_pm_put(fence->i915, wakeref);
return 0;
}
@@ -473,9 +480,10 @@ void i915_gem_restore_fences(struct drm_i915_private
*dev_priv)
{
int i;
+ rcu_read_lock(); /* keep obj alive as we dereference */
for (i = 0; i < dev_priv->num_fence_regs; i++) {
struct drm_i915_fence_reg *reg = &dev_priv->fence_regs[i];
- struct i915_vma *vma = reg->vma;
+ struct i915_vma *vma = READ_ONCE(reg->vma);
GEM_BUG_ON(vma && vma->fence != reg);
@@ -483,18 +491,12 @@ void i915_gem_restore_fences(struct drm_i915_private
*dev_priv)
* Commit delayed tiling changes if we have an object still
* attached to the fence, otherwise just clear the fence.
*/
- if (vma && !i915_gem_object_is_tiled(vma->obj)) {
- GEM_BUG_ON(!reg->dirty);
- GEM_BUG_ON(i915_vma_has_userfault(vma));
-
- list_move(®->link, &dev_priv->mm.fence_list);
- vma->fence = NULL;
+ if (vma && !i915_gem_object_is_tiled(vma->obj))
vma = NULL;
- }
fence_write(reg, vma);
- reg->vma = vma;
}
+ rcu_read_unlock();
}
/**
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.fr
[Intel-gfx] [CI 4/7] drm/i915: Uninterruptibly drain the timelines on unwedging
On wedging, we mark all executing requests as complete and all pending
requests completed as soon as they are ready. Before unwedging though we
wish to flush those pending requests prior to restoring default
execution, and so we must wait. Do so uninterruptibly as we do not provide
the EINTR gracefully back to userspace in this case but persists in
keeping the permanently wedged state without restarting the syscall.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reset.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 64f26e17243a..c4fcb450bd80 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -862,7 +862,6 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
{
struct i915_gpu_error *error = &i915->gpu_error;
struct i915_timeline *tl;
- bool ret = false;
if (!test_bit(I915_WEDGED, &error->flags))
return true;
@@ -887,30 +886,20 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
mutex_lock(&i915->gt.timelines.mutex);
list_for_each_entry(tl, &i915->gt.timelines.active_list, link) {
struct i915_request *rq;
- long timeout;
rq = i915_active_request_get_unlocked(&tl->last_request);
if (!rq)
continue;
/*
-* We can't use our normal waiter as we want to
-* avoid recursively trying to handle the current
-* reset. The basic dma_fence_default_wait() installs
-* a callback for dma_fence_signal(), which is
-* triggered by our nop handler (indirectly, the
-* callback enables the signaler thread which is
-* woken by the nop_submit_request() advancing the seqno
-* and when the seqno passes the fence, the signaler
-* then signals the fence waking us up).
+* All internal dependencies (i915_requests) will have
+* been flushed by the set-wedge, but we may be stuck waiting
+* for external fences. These should all be capped to 10s
+* (I915_FENCE_TIMEOUT) so this wait should not be unbounded
+* in the worst case.
*/
- timeout = dma_fence_default_wait(&rq->fence, true,
-MAX_SCHEDULE_TIMEOUT);
+ dma_fence_default_wait(&rq->fence, false, MAX_SCHEDULE_TIMEOUT);
i915_request_put(rq);
- if (timeout < 0) {
- mutex_unlock(&i915->gt.timelines.mutex);
- goto unlock;
- }
}
mutex_unlock(&i915->gt.timelines.mutex);
@@ -931,11 +920,10 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
smp_mb__before_atomic(); /* complete takeover before enabling execbuf */
clear_bit(I915_WEDGED, &i915->gpu_error.flags);
- ret = true;
-unlock:
+
mutex_unlock(&i915->gpu_error.wedge_mutex);
- return ret;
+ return true;
}
static int do_reset(struct drm_i915_private *i915, unsigned int stalled_mask)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 7/7] drm/i915: Don't claim an unstarted request was guilty
If we haven't even begun executing the payload of the stalled request,
then we should not claim that its userspace context was guilty of
submitting a hanging batch.
v2: Check for context corruption before trying to restart.
v3: Preserve semaphores on skipping requests (need to keep the timelines
intact).
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 42 +--
drivers/gpu/drm/i915/selftests/igt_spinner.c | 7
.../gpu/drm/i915/selftests/intel_hangcheck.c | 6 +++
3 files changed, 52 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 5e98fd79bd9d..1b567a3f006a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1387,6 +1387,10 @@ static int gen8_emit_init_breadcrumb(struct i915_request
*rq)
*cs++ = rq->fence.seqno - 1;
intel_ring_advance(rq, cs);
+
+ /* Record the updated position of the request's payload */
+ rq->infix = intel_ring_offset(rq, cs);
+
return 0;
}
@@ -1878,6 +1882,23 @@ static void execlists_reset_prepare(struct
intel_engine_cs *engine)
spin_unlock_irqrestore(&engine->timeline.lock, flags);
}
+static bool lrc_regs_ok(const struct i915_request *rq)
+{
+ const struct intel_ring *ring = rq->ring;
+ const u32 *regs = rq->hw_context->lrc_reg_state;
+
+ /* Quick spot check for the common signs of context corruption */
+
+ if (regs[CTX_RING_BUFFER_CONTROL + 1] !=
+ (RING_CTL_SIZE(ring->size) | RING_VALID))
+ return false;
+
+ if (regs[CTX_RING_BUFFER_START + 1] != i915_ggtt_offset(ring->vma))
+ return false;
+
+ return true;
+}
+
static void execlists_reset(struct intel_engine_cs *engine, bool stalled)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -1912,6 +1933,21 @@ static void execlists_reset(struct intel_engine_cs
*engine, bool stalled)
if (!rq)
goto out_unlock;
+ /*
+* If this request hasn't started yet, e.g. it is waiting on a
+* semaphore, we need to avoid skipping the request or else we
+* break the signaling chain. However, if the context is corrupt
+* the request will not restart and we will be stuck with a wedged
+* device. It is quite often the case that if we issue a reset
+* while the GPU is loading the context image, that the context
+* image becomes corrupt.
+*
+* Otherwise, if we have not started yet, the request should replay
+* perfectly and we do not need to flag the result as being erroneous.
+*/
+ if (!i915_request_started(rq) && lrc_regs_ok(rq))
+ goto out_unlock;
+
/*
* If the request was innocent, we leave the request in the ELSP
* and will try to replay it on restarting. The context image may
@@ -1924,7 +1960,7 @@ static void execlists_reset(struct intel_engine_cs
*engine, bool stalled)
* image back to the expected values to skip over the guilty request.
*/
i915_reset_request(rq, stalled);
- if (!stalled)
+ if (!stalled && lrc_regs_ok(rq))
goto out_unlock;
/*
@@ -1942,8 +1978,8 @@ static void execlists_reset(struct intel_engine_cs
*engine, bool stalled)
engine->context_size - PAGE_SIZE);
}
- /* Move the RING_HEAD onto the breadcrumb, past the hanging batch */
- rq->ring->head = intel_ring_wrap(rq->ring, rq->postfix);
+ /* Rerun the request; its payload has been neutered (if guilty). */
+ rq->ring->head = intel_ring_wrap(rq->ring, rq->head);
intel_ring_update_space(rq->ring);
execlists_init_reg_state(regs, rq->gem_context, engine, rq->ring);
diff --git a/drivers/gpu/drm/i915/selftests/igt_spinner.c
b/drivers/gpu/drm/i915/selftests/igt_spinner.c
index 9ebd9225684e..d0b93a3fbc54 100644
--- a/drivers/gpu/drm/i915/selftests/igt_spinner.c
+++ b/drivers/gpu/drm/i915/selftests/igt_spinner.c
@@ -144,6 +144,13 @@ igt_spinner_create_request(struct igt_spinner *spin,
i915_gem_chipset_flush(spin->i915);
+ if (engine->emit_init_breadcrumb &&
+ rq->timeline->has_initial_breadcrumb) {
+ err = engine->emit_init_breadcrumb(rq);
+ if (err)
+ goto cancel_rq;
+ }
+
err = engine->emit_bb_start(rq, vma->node.start, PAGE_SIZE, 0);
cancel_rq:
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index 4886fac12628..92475596ff40 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -242,6 +242,12 @@ hang_create_request(struct hang *h, struct intel_engine_cs
*engine)
*batch++ = MI_BATCH_BUFFER_END; /* not reached */
[Intel-gfx] [CI 2/7] drm/i915: Revoke mmaps and prevent access to fence registers across reset
Previously, we were able to rely on the recursive properties of
struct_mutex to allow us to serialise revoking mmaps and reacquiring the
FENCE registers with them being clobbered over a global device reset.
I then proceeded to throw out the baby with the bath water in order to
pursue a struct_mutex-less reset.
Perusing LWN for alternative strategies, the dilemma on how to serialise
access to a global resource on one side was answered by
https://lwn.net/Articles/202847/ -- Sleepable RCU:
1 int readside(void) {
2 int idx;
3 rcu_read_lock();
4 if (nomoresrcu) {
5 rcu_read_unlock();
6 return -EINVAL;
7 }
8 idx = srcu_read_lock(&ss);
9 rcu_read_unlock();
10 /* SRCU read-side critical section. */
11 srcu_read_unlock(&ss, idx);
12 return 0;
13 }
14
15 void cleanup(void)
16 {
17 nomoresrcu = 1;
18 synchronize_rcu();
19 synchronize_srcu(&ss);
20 cleanup_srcu_struct(&ss);
21 }
No more worrying about stop_machine, just an uber-complex mutex,
optimised for reads, with the overhead pushed to the rare reset path.
However, we do run the risk of a deadlock as we allocate underneath the
SRCU read lock, and the allocation may require a GPU reset, causing a
dependency cycle via the in-flight requests. We resolve that by declaring
the driver wedged and cancelling all in-flight rendering.
v2: Use expedited rcu barriers to match our earlier timing
characteristics.
v3: Try to annotate locking contexts for sparse
v4: Reduce selftest lock duration to avoid a reset deadlock with fences
v5: s/srcu/reset_backoff_srcu/
v6: Remove more stale comments
Testcase: igt/gem_mmap_gtt/hang
Fixes: eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 +-
drivers/gpu/drm/i915/i915_drv.h | 18 +--
drivers/gpu/drm/i915/i915_gem.c | 56 +++--
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 36 ++
drivers/gpu/drm/i915/i915_gpu_error.h | 39 ++-
drivers/gpu/drm/i915/i915_reset.c | 110 +++---
drivers/gpu/drm/i915/i915_reset.h | 4 +
drivers/gpu/drm/i915/intel_drv.h | 3 -
.../gpu/drm/i915/selftests/intel_hangcheck.c | 5 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
10 files changed, 117 insertions(+), 167 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 20a49cc4a9a1..7d291a6ad21d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1281,14 +1281,11 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
intel_wakeref_t wakeref;
enum intel_engine_id id;
+ seq_printf(m, "Reset flags: %lx\n", dev_priv->gpu_error.flags);
if (test_bit(I915_WEDGED, &dev_priv->gpu_error.flags))
- seq_puts(m, "Wedged\n");
+ seq_puts(m, "\tWedged\n");
if (test_bit(I915_RESET_BACKOFF, &dev_priv->gpu_error.flags))
- seq_puts(m, "Reset in progress: struct_mutex backoff\n");
- if (waitqueue_active(&dev_priv->gpu_error.wait_queue))
- seq_puts(m, "Waiter holding struct mutex\n");
- if (waitqueue_active(&dev_priv->gpu_error.reset_queue))
- seq_puts(m, "struct_mutex blocked for reset\n");
+ seq_puts(m, "\tDevice (global) reset in progress\n");
if (!i915_modparams.enable_hangcheck) {
seq_puts(m, "Hangcheck disabled\n");
@@ -3873,9 +3870,6 @@ i915_wedged_set(void *data, u64 val)
* while it is writing to 'i915_wedged'
*/
- if (i915_reset_backoff(&i915->gpu_error))
- return -EAGAIN;
-
i915_handle_error(i915, val, I915_ERROR_CAPTURE,
"Manually set wedged engine mask = %llx", val);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4a423753a71c..380b994fe5dc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3001,7 +3001,12 @@ i915_gem_obj_finish_shmem_access(struct
drm_i915_gem_object *obj)
i915_gem_object_unpin_pages(obj);
}
-int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
+static inline int __must_check
+i915_mutex_lock_interruptible(struct drm_device *dev)
+{
+ return mutex_lock_interruptible(&dev->struct_mutex);
+}
+
int i915_gem_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
@@ -3018,21 +3023,11 @@ int __must_check i915_gem_set_global_seqno(struct
drm_device *dev, u32 seqno);
struct i915_request *
i915_gem_find_active_request(struct intel_engine_cs *engine);
-static inline boo
[Intel-gfx] [CI 6/7] drm/i915: Serialise resets with wedging
Prevent concurrent set-wedge with ongoing resets (and vice versa) by
taking the same wedge_mutex around both operations.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reset.c | 68 ++-
1 file changed, 40 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index c4fcb450bd80..9494b015185a 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -794,17 +794,14 @@ static void nop_submit_request(struct i915_request
*request)
intel_engine_queue_breadcrumbs(engine);
}
-void i915_gem_set_wedged(struct drm_i915_private *i915)
+static void __i915_gem_set_wedged(struct drm_i915_private *i915)
{
struct i915_gpu_error *error = &i915->gpu_error;
struct intel_engine_cs *engine;
enum intel_engine_id id;
- mutex_lock(&error->wedge_mutex);
- if (test_bit(I915_WEDGED, &error->flags)) {
- mutex_unlock(&error->wedge_mutex);
+ if (test_bit(I915_WEDGED, &error->flags))
return;
- }
if (GEM_SHOW_DEBUG() && !intel_engines_are_idle(i915)) {
struct drm_printer p = drm_debug_printer(__func__);
@@ -853,12 +850,18 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
set_bit(I915_WEDGED, &error->flags);
GEM_TRACE("end\n");
- mutex_unlock(&error->wedge_mutex);
+}
- wake_up_all(&error->reset_queue);
+void i915_gem_set_wedged(struct drm_i915_private *i915)
+{
+ struct i915_gpu_error *error = &i915->gpu_error;
+
+ mutex_lock(&error->wedge_mutex);
+ __i915_gem_set_wedged(i915);
+ mutex_unlock(&error->wedge_mutex);
}
-bool i915_gem_unset_wedged(struct drm_i915_private *i915)
+static bool __i915_gem_unset_wedged(struct drm_i915_private *i915)
{
struct i915_gpu_error *error = &i915->gpu_error;
struct i915_timeline *tl;
@@ -869,8 +872,6 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
if (!i915->gt.scratch) /* Never full initialised, recovery impossible */
return false;
- mutex_lock(&error->wedge_mutex);
-
GEM_TRACE("start\n");
/*
@@ -921,11 +922,21 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
smp_mb__before_atomic(); /* complete takeover before enabling execbuf */
clear_bit(I915_WEDGED, &i915->gpu_error.flags);
- mutex_unlock(&i915->gpu_error.wedge_mutex);
-
return true;
}
+bool i915_gem_unset_wedged(struct drm_i915_private *i915)
+{
+ struct i915_gpu_error *error = &i915->gpu_error;
+ bool result;
+
+ mutex_lock(&error->wedge_mutex);
+ result = __i915_gem_unset_wedged(i915);
+ mutex_unlock(&error->wedge_mutex);
+
+ return result;
+}
+
static int do_reset(struct drm_i915_private *i915, unsigned int stalled_mask)
{
int err, i;
@@ -975,7 +986,7 @@ void i915_reset(struct drm_i915_private *i915,
GEM_BUG_ON(!test_bit(I915_RESET_BACKOFF, &error->flags));
/* Clear any previous failed attempts at recovery. Time to try again. */
- if (!i915_gem_unset_wedged(i915))
+ if (!__i915_gem_unset_wedged(i915))
return;
if (reason)
@@ -1037,7 +1048,7 @@ void i915_reset(struct drm_i915_private *i915,
*/
add_taint(TAINT_WARN, LOCKDEP_STILL_OK);
error:
- i915_gem_set_wedged(i915);
+ __i915_gem_set_wedged(i915);
goto finish;
}
@@ -1129,7 +1140,9 @@ static void i915_reset_device(struct drm_i915_private
*i915,
i915_wedge_on_timeout(&w, i915, 5 * HZ) {
intel_prepare_reset(i915);
+ mutex_lock(&error->wedge_mutex);
i915_reset(i915, engine_mask, reason);
+ mutex_unlock(&error->wedge_mutex);
intel_finish_reset(i915);
}
@@ -1197,6 +1210,7 @@ void i915_handle_error(struct drm_i915_private *i915,
unsigned long flags,
const char *fmt, ...)
{
+ struct i915_gpu_error *error = &i915->gpu_error;
struct intel_engine_cs *engine;
intel_wakeref_t wakeref;
unsigned int tmp;
@@ -1233,20 +1247,19 @@ void i915_handle_error(struct drm_i915_private *i915,
* Try engine reset when available. We fall back to full reset if
* single reset fails.
*/
- if (intel_has_reset_engine(i915) &&
- !i915_terminally_wedged(&i915->gpu_error)) {
+ if (intel_has_reset_engine(i915) && !i915_terminally_wedged(error)) {
for_each_engine_masked(engine, i915, engine_mask, tmp) {
BUILD_BUG_ON(I915_RESET_MODESET >= I915_RESET_ENGINE);
if (test_and_set_bit(I915_RESET_ENGINE + engine->id,
-&i915->gpu_error.flags))
+&error->flags))
[Intel-gfx] [CI 3/7] drm/i915: Force the GPU reset upon wedging
When declaring the GPU wedged, we do need to hit the GPU with the reset
hammer so that its state matches our presumed state during cleanup. If
the reset fails, it fails, and we may be unhappy but wedged. However, if
we are testing our wedge/unwedged handling, the desync carries over into
the next test and promptly explodes.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106702
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reset.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index c67d6c2a09a2..64f26e17243a 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -532,9 +532,6 @@ typedef int (*reset_func)(struct drm_i915_private *,
static reset_func intel_get_gpu_reset(struct drm_i915_private *i915)
{
- if (!i915_modparams.reset)
- return NULL;
-
if (INTEL_GEN(i915) >= 8)
return gen8_reset_engines;
else if (INTEL_GEN(i915) >= 6)
@@ -599,6 +596,9 @@ bool intel_has_gpu_reset(struct drm_i915_private *i915)
if (USES_GUC(i915))
return false;
+ if (!i915_modparams.reset)
+ return NULL;
+
return intel_get_gpu_reset(i915);
}
@@ -824,7 +824,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
reset_prepare_engine(engine);
/* Even if the GPU reset fails, it should still stop the engines */
- if (INTEL_GEN(i915) >= 5)
+ if (!INTEL_INFO(i915)->gpu_reset_clobbers_display)
intel_gpu_reset(i915, ALL_ENGINES);
for_each_engine(engine, i915, id) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 5/7] drm/i915: Wait for old resets before applying debugfs/i915_wedged
Since we use the debugfs to recover the device after modifying the
i915.reset parameter, we need to be sure that we apply the reset and not
piggy-back onto a concurrent one in order for the parameter to take
effect.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7d291a6ad21d..13bdf326287b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3862,13 +3862,9 @@ i915_wedged_set(void *data, u64 val)
{
struct drm_i915_private *i915 = data;
- /*
-* There is no safeguard against this debugfs entry colliding
-* with the hangcheck calling same i915_handle_error() in
-* parallel, causing an explosion. For now we assume that the
-* test harness is responsible enough not to inject gpu hangs
-* while it is writing to 'i915_wedged'
-*/
+ /* Flush any previous reset before applying for a new one */
+ wait_event(i915->gpu_error.reset_queue,
+ !test_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags));
i915_handle_error(i915, val, I915_ERROR_CAPTURE,
"Manually set wedged engine mask = %llx", val);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] component: Add documentation
On Fri, Feb 8, 2019 at 4:29 PM Daniel Vetter wrote: > > On Fri, Feb 08, 2019 at 12:51:23PM +0100, Greg Kroah-Hartman wrote: > > On Fri, Feb 08, 2019 at 12:27:56AM +0100, Daniel Vetter wrote: > > > While typing these I think doing an s/component_master/aggregate/ > > > would be useful: > > > - it's shorter :-) > > > - I think component/aggregate is much more meaningful naming than > > > component/puppetmaster or something like that. At least to my > > > English ear "aggregate" emphasizes much more the "assemble a pile of > > > things into something bigger" aspect, and there's not really much > > > of a control hierarchy between aggregate and constituing components. > > > > > > But that's way more than a quick doc typing exercise ... > > > > > > Thanks to Ram for commenting on an initial draft of these docs. > > > > > > v2: Review from Rafael: > > > - git add Documenation/driver-api/component.rst > > > - lots of polish to the wording + spelling fixes. > > > > > > v3: Review from Russell: > > > - s/framework/helper > > > - clarify the documentation for component_match_add functions. > > > > > > v4: Remove a few superflous "This". > > > > > > Reviewed-by: Rafael J. Wysocki > > > Cc: "C, Ramalingam" > > > Cc: Greg Kroah-Hartman > > > Cc: Russell King > > > Cc: Rafael J. Wysocki > > > Cc: Jaroslav Kysela > > > Cc: Takashi Iwai > > > Cc: Rodrigo Vivi > > > Cc: Jani Nikula > > > Signed-off-by: Daniel Vetter > > > > Thanks for doing this! > > > > Reviewed-by: Greg Kroah-Hartman > > Thanks for reviewing (obviously includes Rafael and Russell too)! > > For merging I see two options: > - All through drm-intel, but will only land in 5.2 because the feature > cut-off has already happened for i915. So a bit awkward. > - Topic branch with the 2 component patches plus the snd-hda/drm-i915 > patch, so that you/Takashi/drm can pull it in as needed. The drm > component doc patch (3/4 in this series) I can pull in later on. > > Greg/Takashi, any preferences? Just realized that for the mei side of this series I need a topic branch anyway, so topic branch it is. I'll prep that so that CI can beat on it over the w/e, and we can rebase the i915/mei series on top, and then send out the topic pull to everyone early next week. You can then all decide whether you need it or not. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/drv: Rework drm_dev_unplug() (was: Remove drm_dev_unplug())
== Series Details ==
Series: drm/drv: Rework drm_dev_unplug() (was: Remove drm_dev_unplug())
URL : https://patchwork.freedesktop.org/series/56404/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5567 -> Patchwork_12178
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56404/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12178 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: PASS -> WARN [fdo#109380]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#109485]
Possible fixes
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
Participating hosts (49 -> 44)
--
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-glk-j4005
Build changes
-
* Linux: CI_DRM_5567 -> Patchwork_12178
CI_DRM_5567: 5725867972123d46f4a4d382ed5fa2eb0348b00c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4815: 947301563259726b65ce47d3a3fe37931ed42efe @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12178: 20393ed4cb4a1398dba9733930bb8618f4974f6e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
20393ed4cb4a drm/drv: drm_dev_unplug(): Move out drm_dev_put() call
77e99b422efe drm: Fix drm_release() and device unplug
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12178/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/7] drm/i915: Defer removing fence register tracking to rpm wakeup
== Series Details == Series: series starting with [CI,1/7] drm/i915: Defer removing fence register tracking to rpm wakeup URL : https://patchwork.freedesktop.org/series/56412/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Defer removing fence register tracking to rpm wakeup Okay! Commit: drm/i915: Revoke mmaps and prevent access to fence registers across reset -drivers/gpu/drm/i915/i915_gem.c:986:39: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gem.c:986:39: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:986:39: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:986:39: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_reset.c:1303:5: warning: context imbalance in 'i915_reset_trylock' - different lock contexts for basic block -drivers/gpu/drm/i915/selftests/../i915_drv.h:3577:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3571:16: warning: expression using sizeof(void) Commit: drm/i915: Force the GPU reset upon wedging Okay! Commit: drm/i915: Uninterruptibly drain the timelines on unwedging Okay! Commit: drm/i915: Wait for old resets before applying debugfs/i915_wedged Okay! Commit: drm/i915: Serialise resets with wedging Okay! Commit: drm/i915: Don't claim an unstarted request was guilty Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
