Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Fix doorbell id selection
On ke, 2017-05-31 at 00:21 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/guc: Fix doorbell id selection > URL : https://patchwork.freedesktop.org/series/25076/ > State : success Merged. Thanks for the patch and review. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix doorbell id selection
On ti, 2017-05-30 at 17:19 -0700, Daniele Ceraolo Spurio wrote:
>
> On 30/05/17 17:05, Michel Thierry wrote:
> >
> > We are passing parameters in the wrong order to find next zero bit, and
> > when it doesn't find anything it returns size (offset in the code), which
> > is always zero.
> >
> > For reference the function is defined as:
> > find_next_bit( *addr, size, offset )
> >
> > The incorrect parameter order was added by commit abddffdf3620e
> > ("drm/i915/guc: Sanitize GuC client initialization"). Luckily, currently
> > we only use a single guc client and a single doorbell, which happens to be
> > zero; therefore it isn't necessary to backport this fix (which would be for
> > v4.12).
Whoops, a good catch.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Always recompute watermarks when distrust_bios_wm is set
On some systems there can be a race condition in which no crtc state is
added to the first atomic commit. This results in all crtc's having a
null DDB allocation, causing a FIFO underrun on any update until the
first modeset.
Reported-by: Maarten Lankhorst
Inspired-by: Mahesh Kumar
Signed-off-by: Maarten Lankhorst
Fixes: 98d39494d375 ("drm/i915/gen9: Compute DDB allocation at atomic
check time (v4)")
Cc: # v4.8+
Cc: Mahesh Kumar
Cc: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a488e068c3d6..8daa382b47f3 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5037,10 +5037,27 @@ skl_compute_wm(struct drm_atomic_state *state)
struct drm_crtc_state *cstate;
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct skl_wm_values *results = &intel_state->wm_results;
+ struct drm_device *dev = state->dev;
struct skl_pipe_wm *pipe_wm;
bool changed = false;
int ret, i;
+ if (to_i915(dev)->wm.distrust_bios_wm) {
+ changed = true;
+
+ /*
+* The first commit after driver load must update the ddb
+* allocations, so make sure we at least hold a lock to
+* inspect the state required for watermark updates.
+*
+* Below we'll grab the required crtc state.
+*/
+ ret = drm_modeset_lock(&dev->mode_config.connection_mutex,
+ state->acquire_ctx);
+ if (ret)
+ return ret;
+ }
+
/*
* If this transaction isn't actually touching any CRTC's, don't
* bother with watermark calculation. Note that if we pass this
@@ -5051,6 +5068,7 @@ skl_compute_wm(struct drm_atomic_state *state)
*/
for_each_new_crtc_in_state(state, crtc, cstate, i)
changed = true;
+
if (!changed)
return 0;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/37] drm: Extract drm_vblank.[hc]
On Mon, May 29, 2017 at 12:36:54PM -0700, Stefan Agner wrote: > On 2017-05-24 07:51, Daniel Vetter wrote: > > drm_irq.c contains both the irq helper library (optional) and the > > vblank support (optional, but part of the modeset uapi, and doesn't > > require the use of the irq helpers at all. > > > > Split this up for more clarity of the scope of the individual bits. > > > > Signed-off-by: Daniel Vetter > > --- > > Documentation/gpu/drm-kms.rst |4 +- > > drivers/gpu/drm/drm_irq.c | 1623 > > +--- > > drivers/gpu/drm/drm_vblank.c | 1645 > > + > > include/drm/drmP.h|5 +- > > include/drm/drm_file.h|1 + > > include/drm/drm_irq.h | 158 +--- > > include/drm/drm_prime.h |2 + > > include/drm/drm_vblank.h | 181 + > > 8 files changed, 1857 insertions(+), 1762 deletions(-) > > create mode 100644 drivers/gpu/drm/drm_vblank.c > > create mode 100644 include/drm/drm_vblank.h > > > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > > index bfecd21a8cdf..2d77c9580164 100644 > > --- a/Documentation/gpu/drm-kms.rst > > +++ b/Documentation/gpu/drm-kms.rst > > @@ -612,8 +612,8 @@ operation handler. > > Vertical Blanking and Interrupt Handling Functions Reference > > > > > > -.. kernel-doc:: include/drm/drm_irq.h > > +.. kernel-doc:: include/drm/drm_vblank.h > > :internal: > > > > -.. kernel-doc:: drivers/gpu/drm/drm_irq.c > > +.. kernel-doc:: drivers/gpu/drm/drm_vblank.c > > Is that removing drm_irq from kernel-docs? Why? At least the C files > seems to contain valid kernel docs... Get's fixed in the next patch again, where I re-add them when rewriting all the irq docs. Thats why I said these two patches depend upon each another :-) I can shuffle the include hunk of the rewrite into this patch if you think it's better, but I figured renaming/splitting separate from rewriting the docs is good. > > > :export: > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c > > index c7debaad67f8..28d736c3fcb4 100644 > > --- a/drivers/gpu/drm/drm_irq.c > > +++ b/drivers/gpu/drm/drm_irq.c > > > > > /** > > * drm_irq_install - install IRQ handler > > @@ -571,7 +176,7 @@ int drm_irq_uninstall(struct drm_device *dev) > > > > WARN_ON(drm_core_check_feature(dev, DRIVER_MODESET)); > > > > - vblank_disable_and_save(dev, i); > > + drm_vblank_disable_and_save(dev, i); > > This leads to: > > drivers/gpu/drm/drm_irq.c: In function 'drm_irq_uninstall': > drivers/gpu/drm/drm_irq.c:179:4: error: implicit declaration of function > 'drm_vblank_disable_and_save' [-Werror=implicit-function-declaration] > > drm_vblank_disable_and_save(dev, i); > ^ > > Since you moved the function to drm_vblank.c, I guess you have to add a > deceleration in drm_vblank.h? Oops, misplaced hunk, a later patch adds it to drm_internal.h. I'll fix that up. -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] [PATCH] drm/i915/gvt: remove redundant -Wall
On 2017.05.21 00:15:27 -0700, Nick Desaulniers wrote: > This flag is already set in the top level Makefile of the kernel. > > Also, by having set CONFIG_DRM_I915_GVT, thereby appending -Wall to > ccflags, you undo all the -Wno-* cflags previously set in the Make > variable KBUILD_CFLAGS. > > For example: > > cc foo.c -Wall -Wno-format -Wall > > resets -Wformat. > > Signed-off-by: Nick Desaulniers > --- > I verified that -Wall was redundant by compiling with V=1: > make V=1 -j4 drivers/gpu/drm/i915/i915_gem_request.o > > drivers/gpu/drm/i915/gvt/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gvt/Makefile > b/drivers/gpu/drm/i915/gvt/Makefile > index b123c20e2097..f5486cb94818 100644 > --- a/drivers/gpu/drm/i915/gvt/Makefile > +++ b/drivers/gpu/drm/i915/gvt/Makefile > @@ -3,6 +3,6 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o > trace_points.o firmware.o \ > interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \ > execlist.o scheduler.o sched_policy.o render.o cmd_parser.o > > -ccflags-y+= -I$(src) -I$(src)/$(GVT_DIR) -Wall > +ccflags-y+= -I$(src) -I$(src)/$(GVT_DIR) > i915-y += $(addprefix $(GVT_DIR)/, > $(GVT_SOURCE)) > obj-$(CONFIG_DRM_I915_GVT_KVMGT) += $(GVT_DIR)/kvmgt.o > -- Pushed, thanks! -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix backlight invert for non-zero minimum brightness
When we started following the backlight minimum brightness in
6dda730e55f4 ("drm/i915: respect the VBT minimum backlight brightness")
we overlooked the brightness invert quirk. Even if we invert the
brightness, we need to take the min limit into account. We probably
missed this because the invert has only been required on gen4 for proper
operation.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101127
Fixes: 6dda730e55f4 ("drm/i915: respect the VBT minimum backlight brightness")
Cc: Daniel Vetter
Cc: # v3.17+
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index cb50c527401f..bcde9f34527a 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -469,7 +469,7 @@ static u32 intel_panel_compute_brightness(struct
intel_connector *connector,
if (i915.invert_brightness > 0 ||
dev_priv->quirks & QUIRK_INVERT_BRIGHTNESS) {
- return panel->backlight.max - val;
+ return panel->backlight.max - val + panel->backlight.min;
}
return val;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Fix locking in drm_atomic_helper_resume
In the conversion to drop drm_modeset_lock_all and the magic implicit
context I failed to realize that _resume starts out with a pile of
state copies, but not with the locks. And hence drm_atomic_commit
won't grab these for us.
v2: Add locking checks in helpers to make sure we catch this in the
future. Note we can only require the locks in the atomic_check phase,
not in the commit phase. But since any commit is guaranteed to first
run the checks (even for the resume stuff where we use stored
duplicated old state) this should give us full coverage. Requested by
Maarten.
Cc: Jyri Sarha
Fixes: a5b8444e289c ("drm/atomic-helper: remove modeset_lock_all from
helper_resume")
Cc: Maarten Lankhorst
Reviewed-by: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Signed-off-by: Daniel Vetter
---
Needs to be applied to drm-misc-fixes for 4.12. Jyri, testing from you
would also be great, just to confirm.
-Daniel
---
drivers/gpu/drm/drm_atomic_helper.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index af07368846e0..285fab6d1a90 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -508,6 +508,8 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
bool has_connectors =
!!new_crtc_state->connector_mask;
+ WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
+
if (!drm_mode_equal(&old_crtc_state->mode,
&new_crtc_state->mode)) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] mode changed\n",
crtc->base.id, crtc->name);
@@ -551,6 +553,8 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
for_each_oldnew_connector_in_state(state, connector,
old_connector_state, new_connector_state, i) {
const struct drm_connector_helper_funcs *funcs =
connector->helper_private;
+
WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
+
/*
* This only sets crtc->connectors_changed for routing changes,
* drivers must set crtc->connectors_changed themselves when
@@ -650,6 +654,8 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
for_each_oldnew_plane_in_state(state, plane, old_plane_state,
new_plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
+ WARN_ON(!drm_modeset_is_locked(&plane->mutex));
+
funcs = plane->helper_private;
drm_atomic_helper_plane_changed(state, old_plane_state,
new_plane_state, plane);
@@ -2669,7 +2675,12 @@ int drm_atomic_helper_resume(struct drm_device *dev,
drm_modeset_acquire_init(&ctx, 0);
while (1) {
+ err = drm_modeset_lock_all_ctx(dev, &ctx);
+ if (err)
+ goto out;
+
err = drm_atomic_helper_commit_duplicated_state(state, &ctx);
+out:
if (err != -EDEADLK)
break;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/37] drm/exynos: Drop drm_vblank_cleanup
On Tue, May 30, 2017 at 09:03:34AM +0900, Inki Dae wrote: > Hi Daniel, > > 2017년 05월 24일 23:51에 Daniel Vetter 이(가) 쓴 글: > > Only in the load failure path, where the hardware is quiet anyway. > > > > Cc: Inki Dae > > Cc: Joonyoung Shim > > Cc: Seung-Woo Kim > > Cc: Kyungmin Park > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c > > b/drivers/gpu/drm/exynos/exynos_drm_drv.c > > index 50294a7bd29d..1c814b9342af 100644 > > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c > > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c > > @@ -376,7 +376,7 @@ static int exynos_drm_bind(struct device *dev) > > /* Probe non kms sub drivers and virtual display driver. */ > > ret = exynos_drm_device_subdrv_probe(drm); > > if (ret) > > - goto err_cleanup_vblank; > > + goto err_unbind_all; > > With this change shouldn't you post the patch to remove drm_vblank_init and > setup vblank stuff in drm_crtc_init together? > I couldn't find the relevant patch on your patch series[1]. No, drm_vblank_cleanup is already called in the core. The only reason to call it in the driver is to fall back from kms to ums when irq setup somehow failed, then you need to disable vblank support again. The only driver which ever needed this was radeon, and radeon long ago lost ums support. drm_vblank_cleanup is already called for you, and most drivers don't even do this cleanup call. But somehow a lot of people copied from radeon without understanding what it does. Looking at the last patch in this series might help a bit in understanding the history here. Can you pls reevaluate the patch? Thanks, Daniel > As of now, I think resource leak would happen with this patch only. > > Thanks, > Inki Dae > > [1] http://www.spinics.net/lists/dri-devel/msg142387.html > > > > > drm_mode_config_reset(drm); > > > > @@ -407,8 +407,6 @@ static int exynos_drm_bind(struct device *dev) > > exynos_drm_fbdev_fini(drm); > > drm_kms_helper_poll_fini(drm); > > exynos_drm_device_subdrv_remove(drm); > > -err_cleanup_vblank: > > - drm_vblank_cleanup(drm); > > err_unbind_all: > > component_unbind_all(drm->dev, drm); > > err_mode_config_cleanup: > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: fix backlight invert for non-zero minimum brightness
== Series Details == Series: drm/i915: fix backlight invert for non-zero minimum brightness URL : https://patchwork.freedesktop.org/series/25085/ State : success == Summary == Series 25085v1 drm/i915: fix backlight invert for non-zero minimum brightness https://patchwork.freedesktop.org/api/1.0/series/25085/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:441s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:438s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:585s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:512s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:487s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:481s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:434s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:413s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:416s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:496s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:464s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:468s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:456s fi-skl-6700hqtotal:278 pass:239 dwarn:0 dfail:1 fail:17 skip:21 time:433s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:465s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:500s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:434s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:537s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:411s d6dcb2fc7dc2ca874a0f0063f21fcca6a3e61fac drm-tip: 2017y-05m-31d-07h-35m-12s UTC integration manifest 294ea2a drm/i915: fix backlight invert for non-zero minimum brightness == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4837/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 23/37] drm/imx: Drop drm_vblank_cleanup
On Mon, May 29, 2017 at 01:07:40PM +0200, Philipp Zabel wrote: > Hi Daniel, > > On Wed, 2017-05-24 at 16:51 +0200, Daniel Vetter wrote: > > It's only done in the driver load error path, where vblanks don't need > > to be quiescent anyway. And that's all drm_vblank_cleanup does, since > > the core will release the vblank allocations on its own already. So > > drop it. > > Thank you for cleaning this up and improving the docs. > From the function name and kerneldoc comment, it was really not clear > that this function is already called in the drm_device release path. > > I think the comment is slightly misleading though, as drm_vblank_cleanup > does call kfree(dev->vblank). Yeah I got a bit sloppy with the commit message. Since this is error code resetting ->num_crtcs doesn't do anything useful, and the kfree happens anyway (because the core calls drm_vblank_cleanup for you). That only leaves the timer shutdown, and the timer can't run yet here at this point. Hence this does nothing useful (except move the kfree around). > > > Cc: Philipp Zabel > > Signed-off-by: Daniel Vetter > > > > --- > > drivers/gpu/drm/imx/imx-drm-core.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > > b/drivers/gpu/drm/imx/imx-drm-core.c > > index 50add2f9e250..95e2181963d9 100644 > > --- a/drivers/gpu/drm/imx/imx-drm-core.c > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > > @@ -278,7 +278,7 @@ static int imx_drm_bind(struct device *dev) > > /* Now try and bind all our sub-components */ > > ret = component_bind_all(dev, drm); > > if (ret) > > - goto err_vblank; > > + goto err_kms; > > > > drm_mode_config_reset(drm); > > > > @@ -316,8 +316,6 @@ static int imx_drm_bind(struct device *dev) > > err_unbind: > > #endif > > component_unbind_all(drm->dev, drm); > > -err_vblank: > > - drm_vblank_cleanup(drm); > > err_kms: > > drm_mode_config_cleanup(drm); > > err_unref: > > As I understand, the drm_dev_unref(drm) that follows this causes > drm_dev_release -> drm_dev_fini -> drm_vblank_cleanup to be called, so > > Acked-by: Philipp Zabel Thanks, applied, as I did all the other patches which gathered an ack or r-b already. -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] [PATCH 19/37] drm/fsl: Drop drm_vblank_cleanup
On Tue, May 30, 2017 at 02:17:04PM -0700, Stefan Agner wrote: > On 2017-05-26 00:00, Daniel Vetter wrote: > > On Thu, May 25, 2017 at 10:18 AM, Stefan Agner wrote: > >> On 2017-05-24 07:51, Daniel Vetter wrote: > >>> Again cleanup before irq disabling doesn't really stop the races, > >>> so just drop it. Proper fix would be to put drm_atomic_helper_shutdown > >>> before everything gets cleaned up. > >> > >> Hm, I already use the non-atomic drm_crtc_force_disable_all before, I > >> think that fixed the races I saw. > >> > >> But I guess what you are saying instead of using > >> drm_crtc_force_disable_all I should use drm_atomic_helper_shutdown...? > > > > Yes. I thought I audited all existing users of the legacy > > force_disable (it won't work correctly for atomic drivers), but > > somehow I missed the one in fsl. See > > > > commit 18dddadc78c91a91b546acc48506c24f5f840c4f > > Author: Daniel Vetter > > Date: Tue Mar 21 17:41:49 2017 +0100 > > > > drm/atomic: Introduce drm_atomic_helper_shutdown > > > > Ok, I see. > > Since this leads to a change just a few lines above this patch, it has > potential for merge conflict. Can I take this change through my tree? Yeah, it'll probably take until 4.14 anyway until I get them all in and finally can remove drm_vblank_cleanup from the driver-exported set of functions. Just make sure it does get into 4.13 pls. -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] [PATCH v6 0/6] drm/i915/gvt: Dma-buf support for GVT-g
On Wed, 2017-05-31 at 02:29 +, Chen, Xiaoguang wrote: > Hi Gerd, > > It is based on 4.12.0-rc1 Applies, good. But then fails to build: error: ‘struct vfio_vgpu_dmabuf_info’ has no member named ‘resv’ gvt/kvmgt.c:611:11: note: in expansion of macro ‘offsetofend’ minsz = offsetofend(struct vfio_vgpu_dmabuf_info, resv); /me wonders how this was tested ... cheers, Gerd ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH v3 5/5] ACPI: button: Always notify kernel space using _LID returning value
Hi,
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [RFC PATCH v3 5/5] ACPI: button: Always notify kernel space
> using _LID returning value
>
> Hi Lv,
>
> On May 27 2017 or thereabouts, Lv Zheng wrote:
> > Both nouveau and i915, the only 2 kernel space lid notification listeners,
> > invoke acpi_lid_open() API to obtain _LID returning value instead of using
> > the notified value.
> >
> > So this patch moves this logic from listeners to lid driver, always notify
> > kernel space listeners using _LID returning value.
> >
> > This is a no-op cleanup, but facilitates administrators to configure to
> > notify kernel drivers with faked lid init states via command line
> > "button.lid_notify_init_state=Y".
> >
> > Cc:
> > Cc:
> > Cc: Benjamin Tissoires
> > Cc: Peter Hutterer
> > Signed-off-by: Lv Zheng
> > ---
> > drivers/acpi/button.c | 16 ++--
> > drivers/gpu/drm/i915/intel_lvds.c | 2 +-
> > 2 files changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> > index 4abf8ae..e047d34 100644
> > --- a/drivers/acpi/button.c
> > +++ b/drivers/acpi/button.c
> > @@ -119,6 +119,9 @@ static u8 lid_init_state = ACPI_BUTTON_LID_INIT_OPEN;
> > static unsigned long lid_report_interval __read_mostly = 500;
> > module_param(lid_report_interval, ulong, 0644);
> > MODULE_PARM_DESC(lid_report_interval, "Interval (ms) between lid key
> > events");
> > +static bool lid_notify_init_state __read_mostly = false;
> > +module_param(lid_notify_init_state, bool, 0644);
> > +MODULE_PARM_DESC(lid_notify_init_state, "Notify init lid state to kernel
> > drivers after
> boot/resume");
> >
> > /*
> > --
> >FS Interface (/proc)
> > @@ -224,6 +227,15 @@ static void acpi_lid_notify_state(struct acpi_device
> > *device,
> > if (state)
> > pm_wakeup_event(&device->dev, 0);
> >
> > + if (!lid_notify_init_state) {
> > + /*
> > +* There are cases "state" is not a _LID return value, so
> > +* correct it before notification.
> > +*/
> > + if (!bios_notify &&
> > + lid_init_state != ACPI_BUTTON_LID_INIT_METHOD)
> > + state = acpi_lid_evaluate_state(device);
> > + }
> > acpi_lid_notifier_call(device, state);
> > }
> >
> > @@ -572,10 +584,10 @@ static int param_set_lid_init_state(const char *val,
> > struct kernel_param *kp)
> >
> > if (!strncmp(val, "open", sizeof("open") - 1)) {
> > lid_init_state = ACPI_BUTTON_LID_INIT_OPEN;
> > - pr_info("Notify initial lid state as open\n");
> > + pr_info("Notify initial lid state to users space as open and
> > kernel drivers with _LID
> return value\n");
> > } else if (!strncmp(val, "method", sizeof("method") - 1)) {
> > lid_init_state = ACPI_BUTTON_LID_INIT_METHOD;
> > - pr_info("Notify initial lid state with _LID return value\n");
> > + pr_info("Notify initial lid state to user/kernel space with
> > _LID return value\n");
> > } else if (!strncmp(val, "ignore", sizeof("ignore") - 1)) {
> > lid_init_state = ACPI_BUTTON_LID_INIT_IGNORE;
> > pr_info("Do not notify initial lid state\n");
> > diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> > b/drivers/gpu/drm/i915/intel_lvds.c
> > index 9ca4dc4..8ca9080 100644
> > --- a/drivers/gpu/drm/i915/intel_lvds.c
> > +++ b/drivers/gpu/drm/i915/intel_lvds.c
> > @@ -548,7 +548,7 @@ static int intel_lid_notify(struct notifier_block *nb,
> > unsigned long val,
> > /* Don't force modeset on machines where it causes a GPU lockup */
> > if (dmi_check_system(intel_no_modeset_on_lid))
> > goto exit;
> > - if (!acpi_lid_open()) {
> > + if (!val) {
> > /* do modeset on next lid open event */
> > dev_priv->modeset_restore = MODESET_ON_LID_OPEN;
> > goto exit;
>
> This last hunk should really be in its own patch because the intel GPU
> folks would need to apply the rest of the series for their CI suite, and
> also because there is no reason for this change to be alongside any
> other acpi/button.c change.
OK, I'll drop i915 related changes.
However I can see cleanup chances in button.c.
I feel I should at least do minimal tunings in button driver to allow future
improvements.
Cheers,
Lv
> Cheers,
> Benjamin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 0/6] drm/i915/gvt: Dma-buf support for GVT-g
Hi Gerd, I found this problem once I sent the patches :( I checked the uapi definitions and found it is usually called pad to do the aligning. So I changed the 'resv' to 'pad' in the patch but forgot to update it in the last patch and did not test after the "small" change. Next time I will test even when the change is very small. I will change this in the next version. Sorry for the mistake. >-Original Message- >From: Gerd Hoffmann [mailto:kra...@redhat.com] >Sent: Wednesday, May 31, 2017 4:59 PM >To: Chen, Xiaoguang ; >alex.william...@redhat.com; ch...@chris-wilson.co.uk; intel- >g...@lists.freedesktop.org; linux-ker...@vger.kernel.org; >zhen...@linux.intel.com; Lv, Zhiyuan ; intel-gvt- >d...@lists.freedesktop.org; Wang, Zhi A ; Tian, Kevin > >Subject: Re: [PATCH v6 0/6] drm/i915/gvt: Dma-buf support for GVT-g > >On Wed, 2017-05-31 at 02:29 +, Chen, Xiaoguang wrote: >> Hi Gerd, >> >> It is based on 4.12.0-rc1 > >Applies, good. >But then fails to build: > >error: ‘struct vfio_vgpu_dmabuf_info’ has no member named ‘resv’ > >gvt/kvmgt.c:611:11: note: in expansion of macro ‘offsetofend’ > minsz = offsetofend(struct vfio_vgpu_dmabuf_info, resv); > >/me wonders how this was tested ... > >cheers, > Gerd ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/doc: Improve ioctl/fops docs a bit more
I spotted a markup issue, plus adding the descriptions in drm_driver.
Plus a few more links while at it.
I'm still mildly unhappy with the split between fops and ioctls, but I
still think having the ioctls in the uapi chapter makes more sense. Oh
well ...
v2: Rebase.
v3: Move misplace hunk to the right patch.
Cc: Stefan Agner
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-internals.rst | 2 ++
Documentation/gpu/drm-uapi.rst | 2 ++
drivers/gpu/drm/drm_file.c | 7 ++-
drivers/gpu/drm/drm_ioctl.c | 5 -
include/drm/drm_drv.h | 18 ++
5 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/drm-internals.rst
b/Documentation/gpu/drm-internals.rst
index babfb6143bd9..d218dd29221a 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -243,6 +243,8 @@ drivers.
Open/Close, File Operations and IOCTLs
==
+.. _drm_driver_fops:
+
File Operations
---
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 858457567d3d..679373b4a03f 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -160,6 +160,8 @@ other hand, a driver requires shared state between clients
which is
visible to user-space and accessible beyond open-file boundaries, they
cannot support render nodes.
+.. _drm_driver_ioctl:
+
IOCTL Support on Device Nodes
=
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index caad93dab54b..6631f61b66ca 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -75,7 +75,7 @@ DEFINE_MUTEX(drm_global_mutex);
* for drivers which use the CMA GEM helpers it's drm_gem_cma_mmap().
*
* No other file operations are supported by the DRM userspace API. Overall the
- * following is an example #file_operations structure::
+ * following is an example &file_operations structure::
*
* static const example_drm_fops = {
* .owner = THIS_MODULE,
@@ -92,6 +92,11 @@ DEFINE_MUTEX(drm_global_mutex);
* For plain GEM based drivers there is the DEFINE_DRM_GEM_FOPS() macro, and
for
* CMA based drivers there is the DEFINE_DRM_GEM_CMA_FOPS() macro to make this
* simpler.
+ *
+ * The driver's &file_operations must be stored in &drm_driver.fops.
+ *
+ * For driver-private IOCTL handling see the more detailed discussion in
+ * :ref:`IOCTL support in the userland interfaces chapter`.
*/
static int drm_open_helper(struct file *filp, struct drm_minor *minor);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index a423bf60e230..3690706f051d 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -683,7 +683,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
*
* DRM driver private IOCTL must be in the range from DRM_COMMAND_BASE to
* DRM_COMMAND_END. Finally you need an array of &struct drm_ioctl_desc to wire
- * up the handlers and set the access rights:
+ * up the handlers and set the access rights::
*
* static const struct drm_ioctl_desc my_driver_ioctls[] = {
* DRM_IOCTL_DEF_DRV(MY_DRIVER_OPERATION, my_driver_operation,
@@ -692,6 +692,9 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
*
* And then assign this to the &drm_driver.ioctls field in your driver
* structure.
+ *
+ * See the separate chapter on :ref:`file operations` for how
+ * the driver-specific IOCTLs are wired up.
*/
/**
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 5d06c68bb00b..ebb41688581b 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -486,8 +486,26 @@ struct drm_driver {
char *date;
u32 driver_features;
+
+ /**
+* @ioctls:
+*
+* Array of driver-private IOCTL description entries. See the chapter on
+* :ref:`IOCTL support in the userland interfaces
+* chapter` for the full details.
+*/
+
const struct drm_ioctl_desc *ioctls;
+ /** @num_ioctls: Number of entries in @ioctls. */
int num_ioctls;
+
+ /**
+* @fops:
+*
+* File operations for the DRM device node. See the discussion in
+* :ref:`file operations` for in-depth coverage and
+* some examples.
+*/
const struct file_operations *fops;
/* Everything below here is for legacy driver, never use! */
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/doc: Polish irq helper documentation
Pull a (much shorter) overview into drm_irq.c, and instead put the callback documentation into in-line comments in drm_drv.h. v2: Move the include stanzas back to the split-up patch (Stefan). Cc: Stefan Agner Reviewed-by: Stefan Agner Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-internals.rst | 54 - drivers/gpu/drm/drm_irq.c | 30 + drivers/gpu/drm/drm_vblank.c| 3 +++ include/drm/drmP.h | 9 +-- include/drm/drm_drv.h | 33 +-- 5 files changed, 66 insertions(+), 63 deletions(-) diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index dd28e39cf966..bece92258647 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -149,60 +149,6 @@ Device Instance and Driver Handling Driver Load --- -IRQ Registration - - -The DRM core tries to facilitate IRQ handler registration and -unregistration by providing :c:func:`drm_irq_install()` and -:c:func:`drm_irq_uninstall()` functions. Those functions only -support a single interrupt per device, devices that use more than one -IRQs need to be handled manually. - -Managed IRQ Registration - - -:c:func:`drm_irq_install()` starts by calling the irq_preinstall -driver operation. The operation is optional and must make sure that the -interrupt will not get fired by clearing all pending interrupt flags or -disabling the interrupt. - -The passed-in IRQ will then be requested by a call to -:c:func:`request_irq()`. If the DRIVER_IRQ_SHARED driver feature -flag is set, a shared (IRQF_SHARED) IRQ handler will be requested. - -The IRQ handler function must be provided as the mandatory irq_handler -driver operation. It will get passed directly to -:c:func:`request_irq()` and thus has the same prototype as all IRQ -handlers. It will get called with a pointer to the DRM device as the -second argument. - -Finally the function calls the optional irq_postinstall driver -operation. The operation usually enables interrupts (excluding the -vblank interrupt, which is enabled separately), but drivers may choose -to enable/disable interrupts at a different time. - -:c:func:`drm_irq_uninstall()` is similarly used to uninstall an -IRQ handler. It starts by waking up all processes waiting on a vblank -interrupt to make sure they don't hang, and then calls the optional -irq_uninstall driver operation. The operation must disable all hardware -interrupts. Finally the function frees the IRQ by calling -:c:func:`free_irq()`. - -Manual IRQ Registration -''' - -Drivers that require multiple interrupt handlers can't use the managed -IRQ registration functions. In that case IRQs must be registered and -unregistered manually (usually with the :c:func:`request_irq()` and -:c:func:`free_irq()` functions, or their :c:func:`devm_request_irq()` and -:c:func:`devm_free_irq()` equivalents). - -When manually registering IRQs, drivers must not set the -DRIVER_HAVE_IRQ driver feature flag, and must not provide the -irq_handler driver operation. They must set the :c:type:`struct -drm_device ` irq_enabled field to 1 upon -registration of the IRQs, and clear it to 0 after unregistering the -IRQs. IRQ Helper Library ~~ diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 28d736c3fcb4..3b04c25100ae 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -62,19 +62,39 @@ #include "drm_internal.h" /** + * DOC: irq helpers + * + * The DRM core provides very simple support helpers to enable IRQ handling on a + * device through the drm_irq_install() and drm_irq_uninstall() functions. This + * only supports devices with a single interrupt on the main device stored in + * &drm_device.dev and set as the device paramter in drm_dev_alloc(). + * + * These IRQ helpers are strictly optional. Drivers which roll their own only + * need to set &drm_device.irq_enabled to signal the DRM core that vblank + * interrupts are working. Since these helpers don't automatically clean up the + * requested interrupt like e.g. devm_request_irq() they're not really + * recommended. + */ + +/** * drm_irq_install - install IRQ handler * @dev: DRM device * @irq: IRQ number to install the handler for * * Initializes the IRQ related data. Installs the handler, calling the driver - * irq_preinstall() and irq_postinstall() functions before and after the - * installation. + * &drm_driver.irq_preinstall and &drm_driver.irq_postinstall functions before + * and after the installation. * * This is the simplified helper interface provided for drivers with no special * needs. Drivers which need to install interrupt handlers for multiple * interrupts must instead set &drm_device.irq_enabled to signal the DRM core * that vblank interrupts are available. * + * @irq must match the interrupt number
[Intel-gfx] [PATCH 1/3] drm/i915: Encapsulate the pwm_device in a pwm_info structure
pwm_info helps in encapsulating the PWM period_ns values and will form
basis of adding new pwm devices which can then be genrically used by
initializing proper pwm_info structure in the backlight setup call.
v2: Rebase on latest code. Add BZ details
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96571
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90075
Cc: cbroo...@gmail.com
Cc: jani.nik...@linux.intel.com
Tested-by: Lluís Batlle i Rossell
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/intel_drv.h | 8 ++-
drivers/gpu/drm/i915/intel_panel.c | 47 +++---
2 files changed, 36 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cc13706..17af59c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -263,6 +263,12 @@ struct intel_encoder {
const struct drm_connector *audio_connector;
};
+struct intel_pwm_info {
+ struct pwm_device *dev;
+ unsigned int period_ns;
+ char *name;
+};
+
struct intel_panel {
struct drm_display_mode *fixed_mode;
struct drm_display_mode *downclock_mode;
@@ -282,7 +288,7 @@ struct intel_panel {
/* PWM chip */
bool util_pin_active_low; /* bxt+ */
u8 controller; /* bxt+ only */
- struct pwm_device *pwm;
+ struct intel_pwm_info *pwm;
struct backlight_device *device;
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index c8103f8..d56d1c2 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -37,6 +37,13 @@
#define CRC_PMIC_PWM_PERIOD_NS 21333
+/* CRC PMIC based PWM Information */
+struct intel_pwm_info crc_pwm_info = {
+ .period_ns = CRC_PMIC_PWM_PERIOD_NS,
+ .name = "pwm_backlight",
+ .dev = NULL,
+};
+
void
intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
@@ -536,10 +543,11 @@ static u32 bxt_get_backlight(struct intel_connector
*connector)
static u32 pwm_get_backlight(struct intel_connector *connector)
{
struct intel_panel *panel = &connector->panel;
+ struct intel_pwm_info *pwm = panel->backlight.pwm;
int duty_ns;
- duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);
- return DIV_ROUND_UP(duty_ns * 100, CRC_PMIC_PWM_PERIOD_NS);
+ duty_ns = pwm_get_duty_cycle(pwm->dev);
+ return DIV_ROUND_UP(duty_ns * 100, pwm->period_ns);
}
static u32 intel_panel_get_backlight(struct intel_connector *connector)
@@ -628,9 +636,10 @@ static void bxt_set_backlight(struct intel_connector
*connector, u32 level)
static void pwm_set_backlight(struct intel_connector *connector, u32 level)
{
struct intel_panel *panel = &connector->panel;
- int duty_ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
+ struct intel_pwm_info *pwm = panel->backlight.pwm;
+ int duty_ns = DIV_ROUND_UP(level * pwm->period_ns, 100);
- pwm_config(panel->backlight.pwm, duty_ns, CRC_PMIC_PWM_PERIOD_NS);
+ pwm_config(pwm->dev, duty_ns, pwm->period_ns);
}
static void
@@ -799,11 +808,12 @@ static void bxt_disable_backlight(struct intel_connector
*connector)
static void pwm_disable_backlight(struct intel_connector *connector)
{
struct intel_panel *panel = &connector->panel;
+ struct intel_pwm_info *pwm = panel->backlight.pwm;
/* Disable the backlight */
- pwm_config(panel->backlight.pwm, 0, CRC_PMIC_PWM_PERIOD_NS);
+ pwm_config(pwm->dev, 0, pwm->period_ns);
usleep_range(2000, 3000);
- pwm_disable(panel->backlight.pwm);
+ pwm_disable(pwm->dev);
}
void intel_panel_disable_backlight(struct intel_connector *connector)
@@ -1090,7 +1100,7 @@ static void pwm_enable_backlight(struct intel_connector
*connector)
{
struct intel_panel *panel = &connector->panel;
- pwm_enable(panel->backlight.pwm);
+ pwm_enable(panel->backlight.pwm->dev);
intel_panel_actually_set_backlight(connector, panel->backlight.level);
}
@@ -1649,12 +1659,13 @@ static int pwm_setup_backlight(struct intel_connector
*connector,
{
struct drm_device *dev = connector->base.dev;
struct intel_panel *panel = &connector->panel;
+ struct intel_pwm_info *pwm = &crc_pwm_info;
int retval;
/* Get the PWM chip for backlight control */
- panel->backlight.pwm = pwm_get(dev->dev, "pwm_backlight");
- if (IS_ERR(panel->backlight.pwm)) {
- DRM_ERROR("Failed to own the pwm chip\n");
+ pwm->dev = pwm_get(dev->dev, pwm->name);
+ if (IS_ERR(pwm->dev)) {
+ DRM_ERROR("Failed to own the pwm chip: %s\n", pwm->name);
panel->backlight.pwm = NULL;
return -ENODEV;
}
@@ -1663,13 +1674,12 @@
[Intel-gfx] [PATCH 0/3] Reviving the PWM_LPSS patches yet again
Hi All, Its been long since I have been sitting on these after I had received Tested-by for the same by Lluís for atleast the backlight working fine. The related bugs are - https://bugs.freedesktop.org/show_bug.cgi?id=96571 https://bugs.freedesktop.org/show_bug.cgi?id=90075 Rebased the code on latest code and sending again. Still display was not working on devices referenced in these bugs but backlight control was tested to be working at that time. DSI issues of panel display not comming up is tracked separately at - https://bugs.freedesktop.org/show_bug.cgi?id=96923 and should be again tested with latest drm-tip. Module ordering problem remains still and for testing we should for now enable LPSS_PWM as in built with i915 as module. Regards Shobhit Shobhit Kumar (3): drm/i915: Encapsulate the pwm_device in a pwm_info structure pwm: lpss: Add intel-gfx as consumer device in lookup table drm/i915: Add support for LPSS PWM on devices that support it drivers/gpu/drm/i915/intel_drv.h | 8 - drivers/gpu/drm/i915/intel_panel.c | 61 +++--- drivers/pwm/pwm-lpss-platform.c| 12 3 files changed, 62 insertions(+), 19 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Add support for LPSS PWM on devices that support it
v2: Add bugzilla links
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96571
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90075
Cc: cbroo...@gmail.com
Cc: jani.nik...@linux.intel.com
Tested-by: Lluís Batlle i Rossell
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/intel_panel.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index d56d1c2..4d84c561 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -36,6 +36,7 @@
#include "intel_drv.h"
#define CRC_PMIC_PWM_PERIOD_NS 21333
+#define LPSS_PWM_PERIOD_NS 10240
/* CRC PMIC based PWM Information */
struct intel_pwm_info crc_pwm_info = {
@@ -44,6 +45,13 @@ struct intel_pwm_info crc_pwm_info = {
.dev = NULL,
};
+/* LPSS based PWM Information */
+struct intel_pwm_info lpss_pwm_info = {
+ .period_ns = LPSS_PWM_PERIOD_NS,
+ .name = "pwm_lpss",
+ .dev = NULL,
+};
+
void
intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
@@ -1658,10 +1666,16 @@ static int pwm_setup_backlight(struct intel_connector
*connector,
enum pipe pipe)
{
struct drm_device *dev = connector->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = &connector->panel;
- struct intel_pwm_info *pwm = &crc_pwm_info;
+ struct intel_pwm_info *pwm;
int retval;
+ if (dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC)
+ pwm = &crc_pwm_info;
+ else /* PPS_BLC_SOC */
+ pwm = &lpss_pwm_info;
+
/* Get the PWM chip for backlight control */
pwm->dev = pwm_get(dev->dev, pwm->name);
if (IS_ERR(pwm->dev)) {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] pwm: lpss: Add intel-gfx as consumer device in lookup table
v2: Rebase on latest code and correct the device name in
lookup table (viric)
Remove lookup table on driver remove
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96571
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90075
Cc: cbroo...@gmail.com
Cc: jani.nik...@linux.intel.com
Tested-by: Lluís Batlle i Rossell
Signed-off-by: Shobhit Kumar
---
drivers/pwm/pwm-lpss-platform.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/pwm/pwm-lpss-platform.c b/drivers/pwm/pwm-lpss-platform.c
index 5d6ed15..f157a6d 100644
--- a/drivers/pwm/pwm-lpss-platform.c
+++ b/drivers/pwm/pwm-lpss-platform.c
@@ -40,6 +40,11 @@ static const struct pwm_lpss_boardinfo pwm_lpss_bxt_info = {
.bypass = true,
};
+/* PWM consumed by the Intel GFX */
+static struct pwm_lookup lpss_pwm_lookup[] = {
+ PWM_LOOKUP("80860F09:00", 0, ":00:02.0", "pwm_lpss", 0,
PWM_POLARITY_NORMAL),
+};
+
static int pwm_lpss_probe_platform(struct platform_device *pdev)
{
const struct pwm_lpss_boardinfo *info;
@@ -60,6 +65,9 @@ static int pwm_lpss_probe_platform(struct platform_device
*pdev)
platform_set_drvdata(pdev, lpwm);
+ /* Register intel-gfx device as allowed consumer */
+ pwm_add_table(lpss_pwm_lookup, ARRAY_SIZE(lpss_pwm_lookup));
+
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
@@ -71,6 +79,10 @@ static int pwm_lpss_remove_platform(struct platform_device
*pdev)
struct pwm_lpss_chip *lpwm = platform_get_drvdata(pdev);
pm_runtime_disable(&pdev->dev);
+
+ /* remove lookup table */
+ pwm_remove_table(lpss_pwm_lookup, ARRAY_SIZE(lpss_pwm_lookup));
+
return pwm_lpss_remove(lpwm);
}
--
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: fix backlight invert for non-zero minimum brightness
On Wed, May 31, 2017 at 11:33:55AM +0300, Jani Nikula wrote:
> When we started following the backlight minimum brightness in
> 6dda730e55f4 ("drm/i915: respect the VBT minimum backlight brightness")
> we overlooked the brightness invert quirk. Even if we invert the
> brightness, we need to take the min limit into account. We probably
> missed this because the invert has only been required on gen4 for proper
> operation.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101127
> Fixes: 6dda730e55f4 ("drm/i915: respect the VBT minimum backlight brightness")
> Cc: Daniel Vetter
> Cc: # v3.17+
Not sure the cc: stable is justified, but makes sense otherwise
Reviewed-by: Daniel Vetter
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_panel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index cb50c527401f..bcde9f34527a 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -469,7 +469,7 @@ static u32 intel_panel_compute_brightness(struct
> intel_connector *connector,
>
> if (i915.invert_brightness > 0 ||
> dev_priv->quirks & QUIRK_INVERT_BRIGHTNESS) {
> - return panel->backlight.max - val;
> + return panel->backlight.max - val + panel->backlight.min;
> }
>
> return val;
> --
> 2.11.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Use a cached mapping for the physical HWS
On Mon, May 22, 2017 at 12:55:14PM +0100, Chris Wilson wrote:
> Older gen use a physical address for the hardware status page, for which
> we use cache-coherent writes. As the writes are into the cpu cache, we use
> a normal WB mapped page to read the HWS, used for our seqno tracking.
>
> Anecdotally, I observed lost breadcrumbs writes into the HWS on i965gm,
> which so far have not reoccurred with this patch. How reliable that
> evidence is remains to be seen.
>
> v2: Explicitly pass the expected physical address to the hw
> v3: Also remember the wild writes we once had for HWS above 4G.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Joonas Lahtinen
I'm still not sold on the story, but as a cleanup it seems a ok idea.
Getting rid of the drm dma api wrappers is definitely good, since
drm-the-OS-abstraction is dead.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 -
> drivers/gpu/drm/i915/intel_ringbuffer.c | 29 +++--
> 2 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 90787e0084f2..1a7961ef4399 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2109,7 +2109,6 @@ struct drm_i915_private {
> struct i915_gem_context *kernel_context;
> struct intel_engine_cs *engine[I915_NUM_ENGINES];
>
> - struct drm_dma_handle *status_page_dmah;
> struct resource mch_res;
>
> /* protects the irq masks */
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index c32a4ba9579f..26808f2bf748 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -340,11 +340,14 @@ gen7_render_ring_flush(struct drm_i915_gem_request
> *req, u32 mode)
> static void ring_setup_phys_status_page(struct intel_engine_cs *engine)
> {
> struct drm_i915_private *dev_priv = engine->i915;
> + struct page *page = virt_to_page(engine->status_page.page_addr);
> + phys_addr_t phys = PFN_PHYS(page_to_pfn(page));
> u32 addr;
>
> - addr = dev_priv->status_page_dmah->busaddr;
> + addr = lower_32_bits(phys);
> if (INTEL_GEN(dev_priv) >= 4)
> - addr |= (dev_priv->status_page_dmah->busaddr >> 28) & 0xf0;
> + addr |= (phys >> 28) & 0xf0;
> +
> I915_WRITE(HWS_PGA, addr);
> }
>
> @@ -1000,12 +1003,10 @@ i915_emit_bb_start(struct drm_i915_gem_request *req,
>
> static void cleanup_phys_status_page(struct intel_engine_cs *engine)
> {
> - struct drm_i915_private *dev_priv = engine->i915;
> -
> - if (!dev_priv->status_page_dmah)
> + if (!engine->status_page.page_addr)
> return;
>
> - drm_pci_free(&dev_priv->drm, dev_priv->status_page_dmah);
> + __free_page(virt_to_page(engine->status_page.page_addr));
> engine->status_page.page_addr = NULL;
> }
>
> @@ -1091,17 +1092,17 @@ static int init_status_page(struct intel_engine_cs
> *engine)
>
> static int init_phys_status_page(struct intel_engine_cs *engine)
> {
> - struct drm_i915_private *dev_priv = engine->i915;
> -
> - GEM_BUG_ON(engine->id != RCS);
> + struct page *page;
>
> - dev_priv->status_page_dmah =
> - drm_pci_alloc(&dev_priv->drm, PAGE_SIZE, PAGE_SIZE);
> - if (!dev_priv->status_page_dmah)
> + /* Though the HWS register does support 36bit addresses, historically
> + * we have had hangs and corruption reported due to wild writes if
> + * the HWS is placed above 4G.
> + */
> + page = alloc_page(GFP_KERNEL | __GFP_DMA32 | __GFP_ZERO);
> + if (!page)
> return -ENOMEM;
>
> - engine->status_page.page_addr = dev_priv->status_page_dmah->vaddr;
> - memset(engine->status_page.page_addr, 0, PAGE_SIZE);
> + engine->status_page.page_addr = page_address(page);
>
> return 0;
> }
> --
> 2.11.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 4/9] drm: Parse Colorimetry data block from EDID
CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from
panel.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 24
include/drm/drm_connector.h |2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 14f2740..c9b9c3c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3375,6 +3375,28 @@ static void fixup_detailed_cea_mode_clock(struct
drm_display_mode *mode)
mode->clock = clock;
}
+static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)
+{
+ if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != COLORIMETRY_DATA_BLOCK)
+ return false;
+
+ return true;
+}
+
+static void
+drm_parse_colorimetry_data_block(struct drm_connector *connector, const u8 *db)
+{
+ struct drm_hdmi_info *info = &connector->display_info.hdmi;
+ uint16_t len;
+
+ len = cea_db_payload_len(db);
+ info->colorimetry = db[2];
+}
+
+
static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
{
if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
@@ -4055,6 +4077,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
drm_parse_hdmi_forum_vsdb(connector, db);
if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, db);
+ if (cea_db_is_hdmi_colorimetry_data_block(db))
+ drm_parse_colorimetry_data_block(connector, db);
}
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index c99d737..c2b0798 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -137,6 +137,8 @@ struct drm_scdc {
struct drm_hdmi_info {
/** @scdc: sink's scdc support and capabilities */
struct drm_scdc scdc;
+ /* Colorimerty info from EDID */
+ u32 colorimetry;
};
/**
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 1/9] drm: Add HDR source metadata property
This patch adds a blob property to get HDR metadata
information from userspace. This will be send as part
of AVI Infoframe to panel.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_connector.c |7 +++
include/drm/drm_connector.h | 11 +++
include/drm/drm_mode_config.h |6 ++
include/uapi/drm/drm_mode.h | 22 ++
4 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5cd61af..1b36fa2 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -789,6 +789,13 @@ int drm_connector_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.link_status_property = prop;
+ prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+ "HDR_SOURCE_METADATA", 0);
+
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.hdr_source_metadata_property = prop;
+
return 0;
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index d8bb25f..c99d737 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -342,6 +342,13 @@ struct drm_connector_state {
* upscaling, mostly used for built-in panels.
*/
unsigned int scaling_mode;
+
+ /**
+* @metadata_blob_ptr:
+* DRM blob property for HDR metadata
+*/
+ struct drm_property_blob *hdr_source_metadata_blob_ptr;
+ bool hdr_metadata_changed : 1;
};
/**
@@ -877,6 +884,10 @@ struct drm_connector {
uint8_t num_h_tile, num_v_tile;
uint8_t tile_h_loc, tile_v_loc;
uint16_t tile_h_size, tile_v_size;
+
+ /* HDR metdata */
+ struct hdr_static_metadata *hdr_panel_metadata;
+ struct hdr_static_metadata *hdr_source_metadata;
};
#define obj_to_connector(x) container_of(x, struct drm_connector, base)
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 4298171..9ca49ea 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -741,6 +741,12 @@ struct drm_mode_config {
*/
struct drm_property *suggested_y_property;
+ /**
+* hdr_metadata_property: Connector property containing hdr metatda
+* This will be provided by userspace compositors based on HDR content
+*/
+ struct drm_property *hdr_source_metadata_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 403339f..920ea2a 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -590,6 +590,28 @@ struct drm_color_lut {
__u16 reserved;
};
+enum supported_eotf_type {
+ TRADITIONAL_GAMMA_SDR = 0,
+ TRADITIONA_GAMMA_HDR,
+ SMPTE_ST2084,
+ FUTURE_EOTF
+};
+
+/* HDR Metadata */
+struct hdr_static_metadata {
+ uint16_t eotf;
+ uint16_t type;
+ uint16_t display_primaries_x[3];
+ uint16_t display_primaries_y[3];
+ uint16_t white_point_x;
+ uint16_t white_point_y;
+ uint16_t max_mastering_display_luminance;
+ uint16_t min_mastering_display_luminance;
+ uint16_t max_fall;
+ uint16_t max_cll;
+ uint16_t min_cll;
+};
+
#define DRM_MODE_PAGE_FLIP_EVENT 0x01
#define DRM_MODE_PAGE_FLIP_ASYNC 0x02
#define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 0/9] Add HDR Metadata Parsing and handling in DRM layer
This patch series enables HDR support in drm. It basically defines HDR metadata structures, property to pass content (after blending) metadata from user space compositors to driver. Dynamic Range and Mastering infoframe creation and sending. ToDo: 1. We need to get the color framework in place for all planes which support HDR content in hardware. 2. UserSpace/Compositors: Blending policies and metadata blob creation and passing to driver. Please review and share your feedbacks/suggestions. Note: The intention for these patches is to get a design feedback on the uapi changes, generic property design and infoframe handling. This cannot get merged as of now without the userspace support in place. This series is not yet tested. Uma Shankar (9): drm: Add HDR source metadata property drm: Add CEA extended tag blocks and HDR bitfield macros drm: Parse HDR metadata info from EDID drm: Parse Colorimetry data block from EDID drm/i915: Attach HDR metadata property to connector drm: Add HDR capabilty field to plane structure drm: Implement HDR source metadata set and get property handling drm: Enable HDR infoframe support drm/i915: Write HDR infoframe and send to panel drivers/gpu/drm/drm_atomic.c| 15 drivers/gpu/drm/drm_atomic_helper.c |6 ++ drivers/gpu/drm/drm_connector.c |7 ++ drivers/gpu/drm/drm_edid.c | 151 +++ drivers/gpu/drm/i915/intel_hdmi.c | 27 +++ drivers/video/hdmi.c| 138 include/drm/drm_connector.h | 13 +++ include/drm/drm_edid.h |4 + include/drm/drm_mode_config.h |6 ++ include/drm/drm_plane.h |3 + include/linux/hdmi.h| 21 + include/uapi/drm/drm_mode.h | 22 + 12 files changed, 413 insertions(+) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 9/9] drm/i915: Write HDR infoframe and send to panel
Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdmi.c | 25 +
drivers/video/hdmi.c |2 +-
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index d8b53d0..91e0399 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -453,6 +453,27 @@ static void intel_write_infoframe(struct drm_encoder
*encoder,
intel_hdmi->write_infoframe(encoder, crtc_state, frame->any.type,
buffer, len);
}
+/* Set Dynamic Range and Mastering Infoframe */
+static void intel_hdmi_set_drm_infoframe(struct drm_encoder *encoder,
+const struct intel_crtc_state
*crtc_state,
+const struct drm_connector_state
*conn_state)
+{
+ union hdmi_infoframe frame;
+ struct hdr_static_metadata *hdr_metadata;
+ int ret;
+
+ hdr_metadata = (struct hdr_static_metadata *)
+ conn_state->hdr_source_metadata_blob_ptr->data;
+
+ ret = drm_hdmi_infoframe_set_hdr_metadata(&frame.drm, hdr_metadata);
+ if (ret < 0) {
+ DRM_ERROR("couldn't set HDR metadata in infoframe\n");
+ return;
+ }
+
+ intel_write_infoframe(encoder, crtc_state, &frame);
+}
+
static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
const struct intel_crtc_state
*crtc_state)
{
@@ -840,6 +861,10 @@ static void hsw_set_infoframes(struct drm_encoder *encoder,
intel_hdmi_set_avi_infoframe(encoder, crtc_state);
intel_hdmi_set_spd_infoframe(encoder, crtc_state);
intel_hdmi_set_hdmi_infoframe(encoder, crtc_state);
+
+ /* Set Dynamic Range and Mastering Infoframe if supported and changed */
+ if (conn_state->hdr_metadata_changed)
+ intel_hdmi_set_drm_infoframe(encoder, crtc_state, conn_state);
}
void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 2740f40..8d06ea2 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -421,7 +421,7 @@ int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe
*frame)
* error code on failure.
*/
ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe *frame, void *buffer,
-size_t size)
+ size_t size)
{
u8 *ptr = buffer;
size_t length;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 5/9] drm/i915: Attach HDR metadata property to connector
Attach HDR metadata property to connector object. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_hdmi.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 41267ff..d8b53d0 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1734,6 +1734,8 @@ static void intel_hdmi_destroy(struct drm_connector *connector) intel_attach_broadcast_rgb_property(connector); intel_attach_aspect_ratio_property(connector); connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; + drm_object_attach_property(&connector->base, + connector->dev->mode_config.hdr_source_metadata_property, 0); } /* -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 7/9] drm: Implement HDR source metadata set and get property handling
HDR source metadata set and get property implemented in this
patch. The blob data is received from userspace and saved in
connector state, the same is returned as blob in get property
call to userspace.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic.c| 15 +++
drivers/gpu/drm/drm_atomic_helper.c |6 ++
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index e163701..c0007c1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1140,6 +1140,8 @@ int drm_atomic_connector_set_property(struct
drm_connector *connector,
{
struct drm_device *dev = connector->dev;
struct drm_mode_config *config = &dev->mode_config;
+ bool replaced = false;
+ int ret;
if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, val);
@@ -1188,6 +1190,14 @@ int drm_atomic_connector_set_property(struct
drm_connector *connector,
*/
if (state->link_status != DRM_LINK_STATUS_GOOD)
state->link_status = val;
+ } else if (property == config->hdr_source_metadata_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->hdr_source_metadata_blob_ptr,
+ val,
+ -1,
+ &replaced);
+ state->hdr_metadata_changed |= replaced;
+ return ret;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
} else if (property == connector->scaling_mode_property) {
@@ -1210,6 +1220,8 @@ static void drm_atomic_connector_print_state(struct
drm_printer *p,
drm_printf(p, "connector[%u]: %s\n", connector->base.id,
connector->name);
drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name :
"(null)");
+ drm_printf(p, "\thdr_metadata_changed=%d\n",
+ state->hdr_metadata_changed);
if (connector->funcs->atomic_print_state)
connector->funcs->atomic_print_state(p, state);
@@ -1272,6 +1284,9 @@ static void drm_atomic_connector_print_state(struct
drm_printer *p,
*val = state->picture_aspect_ratio;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
+ } else if (property == config->hdr_source_metadata_property) {
+ *val = (state->hdr_source_metadata_blob_ptr) ?
+ state->hdr_source_metadata_blob_ptr->base.id : 0;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 93b0221..1406441 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3436,6 +3436,10 @@ void drm_atomic_helper_connector_reset(struct
drm_connector *connector)
memcpy(state, connector->state, sizeof(*state));
if (state->crtc)
drm_connector_get(connector);
+ if (state->hdr_source_metadata_blob_ptr)
+ drm_property_blob_get(state->hdr_source_metadata_blob_ptr);
+
+ state->hdr_metadata_changed = false;
}
EXPORT_SYMBOL(__drm_atomic_helper_connector_duplicate_state);
@@ -3562,6 +3566,8 @@ struct drm_atomic_state *
{
if (state->crtc)
drm_connector_put(state->connector);
+ if (state->hdr_source_metadata_blob_ptr)
+ drm_property_blob_put(state->hdr_source_metadata_blob_ptr);
}
EXPORT_SYMBOL(__drm_atomic_helper_connector_destroy_state);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 2/9] drm: Add CEA extended tag blocks and HDR bitfield macros
Add bit field and macro for extended tag in CEA block. Also, declare macros for HDR metadata block. Signed-off-by: Uma Shankar --- drivers/gpu/drm/drm_edid.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 2e55599..4dee139 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -2572,6 +2572,22 @@ static int drm_cvt_modes(struct drm_connector *connector, #define EDID_CEA_YCRCB422 (1 << 4) #define EDID_CEA_VCDB_QS (1 << 6) +#define DATA_BLOCK_EXTENDED_TAG0x07 +#define VIDEO_CAPABILITY_DATA_BLOCK0x0 +#define VSVD_DATA_BLOCK0x1 +#define COLORIMETRY_DATA_BLOCK 0x5 +#define HDR_STATIC_METADATA_BLOCK 0x6 + +/* HDR Metadata Block: Bit fields */ +#define SUPPORTED_EOTF_MASK0x3f +#define TRADITIONAL_GAMMA_SDR (0x1 << 0) +#define TRADITIONAL_GAMMA_HDR (0x1 << 1) +#define SMPTE_ST2084 (0x1 << 2) +#define FUTURE_EOTF(0x1 << 3) +#define RESERVED_EOTF (0x3 << 4) + +#define STATIC_METADATA_TYPE1 (0x1 << 0) + /* * Search EDID for CEA extension block. */ -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 3/9] drm: Parse HDR metadata info from EDID
HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 58
1 file changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4dee139..14f2740 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3375,6 +3375,62 @@ static void fixup_detailed_cea_mode_clock(struct
drm_display_mode *mode)
mode->clock = clock;
}
+static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
+{
+ if (cea_db_tag(db) != DATA_BLOCK_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != HDR_STATIC_METADATA_BLOCK)
+ return false;
+
+ return true;
+}
+
+static uint16_t eotf_supported(const u8 *edid_ext)
+{
+ uint16_t val = 0;
+
+ if (edid_ext[2] & TRADITIONAL_GAMMA_SDR)
+ val |= TRADITIONAL_GAMMA_SDR;
+ if (edid_ext[2] & TRADITIONAL_GAMMA_HDR)
+ val |= TRADITIONAL_GAMMA_HDR;
+ if (edid_ext[2] & SMPTE_ST2084)
+ val |= SMPTE_ST2084;
+
+ return val;
+}
+
+static uint16_t hdr_metadata_type(const u8 *edid_ext)
+{
+ uint16_t val = 0;
+
+ if (edid_ext[3] & STATIC_METADATA_TYPE1)
+ val |= STATIC_METADATA_TYPE1;
+
+ return val;
+}
+
+static void
+drm_parse_hdr_metadata_block(struct drm_connector *connector, const u8 *db)
+{
+ uint16_t len;
+
+ len = cea_db_payload_len(db);
+ connector->hdr_panel_metadata->eotf = eotf_supported(db);
+ connector->hdr_panel_metadata->type = hdr_metadata_type(db);
+
+ if (len == 6) {
+ connector->hdr_panel_metadata->max_cll = db[4];
+ connector->hdr_panel_metadata->max_fall = db[5];
+ connector->hdr_panel_metadata->min_cll = db[6];
+ } else if (len == 5) {
+ connector->hdr_panel_metadata->max_cll = db[4];
+ connector->hdr_panel_metadata->max_fall = db[5];
+ } else if (len == 4)
+ connector->hdr_panel_metadata->max_cll = db[4];
+
+}
+
static void
drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)
{
@@ -3997,6 +4053,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
drm_parse_hdmi_vsdb_video(connector, db);
if (cea_db_is_hdmi_forum_vsdb(db))
drm_parse_hdmi_forum_vsdb(connector, db);
+ if (cea_db_is_hdmi_hdr_metadata_block(db))
+ drm_parse_hdr_metadata_block(connector, db);
}
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_setmode: increase MAX_CRTCS to 6
On Tue, May 30, 2017 at 04:01:40PM -0400, Harry Wentland wrote:
> AMD GPUs can have 6 CRTCs.
>
> This requires us to allocate the combinations on the heap.
>
> Signed-off-by: Harry Wentland
I think just dynamically allocating stuff directly and dropping the
#define would be even neater ... GetResources can tell us how much of each
exists.
-Daniel
> ---
> tests/kms_setmode.c | 25 +++--
> 1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
> index 430568a1c24e..847ad650d27f 100644
> --- a/tests/kms_setmode.c
> +++ b/tests/kms_setmode.c
> @@ -35,11 +35,13 @@
> #include "intel_bufmgr.h"
>
> #define MAX_CONNECTORS 10
> -#define MAX_CRTCS 3
> +#define MAX_CRTCS 6
>
> /* max combinations with repetitions */
> +/* MAX_CONNECTORS ^ MAX_CRTCS */
> +/* TODO should really be MAX_CONNECTORS ^ MAX_CONNECTORS ??? */
> #define MAX_COMBINATION_COUNT \
> - (MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS)
> + (MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS *
> MAX_CONNECTORS * MAX_CONNECTORS)
> #define MAX_COMBINATION_ELEMS MAX_CRTCS
>
> static int drm_fd;
> @@ -743,22 +745,25 @@ static void get_combinations(int n, int k, bool
> allow_repetitions,
> static void test_combinations(const struct test_config *tconf,
> int connector_count)
> {
> - struct combination_set connector_combs;
> - struct combination_set crtc_combs;
> + struct combination_set *connector_combs;
> + struct combination_set *crtc_combs;
> struct connector_config *cconfs;
> int i;
>
> if (connector_count > 2 && (tconf->flags & TEST_STEALING))
> return;
>
> + connector_combs = malloc(sizeof(*connector_combs));
> + crtc_combs = malloc(sizeof(*crtc_combs));
> +
> get_combinations(tconf->resources->count_connectors, connector_count,
> - false, &connector_combs);
> + false, connector_combs);
> get_combinations(tconf->resources->count_crtcs, connector_count,
> - true, &crtc_combs);
> + true, crtc_combs);
>
> igt_info("Testing: %s %d connector combinations\n", tconf->name,
>connector_count);
> - for (i = 0; i < connector_combs.count; i++) {
> + for (i = 0; i < connector_combs->count; i++) {
> int *connector_idxs;
> int ret;
> int j;
> @@ -766,14 +771,14 @@ static void test_combinations(const struct test_config
> *tconf,
> cconfs = malloc(sizeof(*cconfs) * connector_count);
> igt_assert(cconfs);
>
> - connector_idxs = &connector_combs.items[i].elems[0];
> + connector_idxs = &connector_combs->items[i].elems[0];
> ret = get_connectors(tconf->resources, connector_idxs,
>connector_count, cconfs);
> if (ret < 0)
> goto free_cconfs;
>
> - for (j = 0; j < crtc_combs.count; j++) {
> - int *crtc_idxs = &crtc_combs.items[j].elems[0];
> + for (j = 0; j < crtc_combs->count; j++) {
> + int *crtc_idxs = &crtc_combs->items[j].elems[0];
> ret = assign_crtc_to_connectors(tconf, crtc_idxs,
> connector_count,
> cconfs);
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 6/9] drm: Add HDR capabilty field to plane structure
Hardware may have HDR capability on certain plane
engines. Enabling the same in drm plane structure
so that this can be communicated to user space.
Each drm driver should set this flag to true for planes
which support HDR.
Signed-off-by: Uma Shankar
---
include/drm/drm_plane.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 9ab3e70..96d8f55 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -498,6 +498,9 @@ struct drm_plane {
enum drm_plane_type type;
+ /* Value of true:1 means HDR is supported */
+ bool hdr_supported;
+
/**
* @index: Position inside the mode_config.list, can be used as an array
* index. It is invariant over the lifetime of the plane.
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 8/9] drm: Enable HDR infoframe support
Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.
The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 53 +
drivers/video/hdmi.c | 138
include/drm/drm_edid.h |4 ++
include/linux/hdmi.h | 21 +++
4 files changed, 216 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c9b9c3c..3b99284 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4428,6 +4428,59 @@ void drm_set_preferred_mode(struct drm_connector
*connector,
EXPORT_SYMBOL(drm_set_preferred_mode);
/**
+ * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI AVI infoframe with
+ * HDR metadata from userspace
+ * @frame: HDMI AVI infoframe
+ * @hdr_source_metadata: hdr_source_metadata info from userspace
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int
+drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
+ void *hdr_metadata)
+{
+ struct hdr_static_metadata *hdr_source_metadata;
+ int err, i;
+
+ if (!frame || !hdr_metadata)
+ return -EINVAL;
+
+ err = hdmi_drm_infoframe_init(frame);
+ if (err < 0)
+ return err;
+
+ hdr_source_metadata = (struct hdr_static_metadata *)hdr_metadata;
+
+ frame->length = sizeof(struct hdr_static_metadata);
+
+
+ frame->eotf = hdr_source_metadata->eotf;
+ frame->type = hdr_source_metadata->type;
+
+ for (i = 0; i < 3; i++) {
+ frame->display_primaries_x[i] =
+ hdr_source_metadata->display_primaries_x[i];
+ frame->display_primaries_y[i] =
+ hdr_source_metadata->display_primaries_y[i];
+ }
+
+ frame->white_point_x = hdr_source_metadata->white_point_x;
+ frame->white_point_y = hdr_source_metadata->white_point_y;
+
+ frame->max_mastering_display_luminance =
+ hdr_source_metadata->max_mastering_display_luminance;
+ frame->min_mastering_display_luminance =
+ hdr_source_metadata->min_mastering_display_luminance;
+
+ frame->max_cll = hdr_source_metadata->max_cll;
+ frame->max_fall = hdr_source_metadata->max_fall;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
+
+
+/**
* drm_hdmi_avi_infoframe_from_display_mode() - fill an HDMI AVI infoframe with
* data from a DRM display mode
* @frame: HDMI AVI infoframe
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1cf907e..2740f40 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -388,6 +388,103 @@ ssize_t hdmi_vendor_infoframe_pack(struct
hdmi_vendor_infoframe *frame,
}
EXPORT_SYMBOL(hdmi_vendor_infoframe_pack);
+/**
+ * hdmi_drm_infoframe_init() - initialize an HDMI Dynaminc Range and
+ * mastering infoframe
+ * @frame: HDMI DRM infoframe
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame)
+{
+ memset(frame, 0, sizeof(*frame));
+
+ frame->type = HDMI_INFOFRAME_TYPE_DRM;
+ frame->version = 1;
+
+ return 0;
+}
+EXPORT_SYMBOL(hdmi_drm_infoframe_init);
+
+/**
+ * hdmi_drm_infoframe_pack() - write HDMI DRM infoframe to binary buffer
+ * @frame: HDMI DRM infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Packs the information contained in the @frame structure into a binary
+ * representation that can be written into the corresponding controller
+ * registers. Also computes the checksum as required by section 5.3.5 of
+ * the HDMI 1.4 specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe *frame, void *buffer,
+size_t size)
+{
+ u8 *ptr = buffer;
+ size_t length;
+
+ length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
+
+ if (size < length)
+ return -ENOSPC;
+
+ memset(buffer, 0, size);
+
+ ptr[0] = frame->type;
+ ptr[1] = frame->version;
+ ptr[2] = frame->length;
+ ptr[3] = 0; /* checksum */
+
+ /* start infoframe payload */
+ ptr += HDMI_INFOFRAME_HEADER_SIZE;
+
+ ptr[0] = frame->eotf;
+ ptr[1] = frame->metadata_type;
+
+ ptr[2] = frame->display_primaries_x[0] & 0xff;
+ ptr[3] = frame->display_primaries_x[0] >> 8;
+
+ ptr[4] = frame->display_primaries_x[1] & 0xff;
+ ptr[5] = frame->display_primaries_x[1] >> 8;
+
+ ptr[6] = fr
Re: [Intel-gfx] [RFC 0/9] Add HDR Metadata Parsing and handling in DRM layer
On Wed, May 31, 2017 at 03:40:48PM +0530, Uma Shankar wrote: > This patch series enables HDR support in drm. > It basically defines HDR metadata structures, > property to pass content (after blending) metadata from user space > compositors to driver. > > Dynamic Range and Mastering infoframe creation and sending. > > ToDo: > 1. We need to get the color framework in place for all planes >which support HDR content in hardware. > 2. UserSpace/Compositors: Blending policies and metadata blob >creation and passing to driver. This is the key, before we have the userspace there's not much point in reviewing the details of the kernel interface, nor the implementation. -Daniel > > Please review and share your feedbacks/suggestions. > > Note: The intention for these patches is to get a design feedback on the uapi > changes, > generic property design and infoframe handling. This cannot get merged as of > now without > the userspace support in place. This series is not yet tested. > > Uma Shankar (9): > drm: Add HDR source metadata property > drm: Add CEA extended tag blocks and HDR bitfield macros > drm: Parse HDR metadata info from EDID > drm: Parse Colorimetry data block from EDID > drm/i915: Attach HDR metadata property to connector > drm: Add HDR capabilty field to plane structure > drm: Implement HDR source metadata set and get property handling > drm: Enable HDR infoframe support > drm/i915: Write HDR infoframe and send to panel > > drivers/gpu/drm/drm_atomic.c| 15 > drivers/gpu/drm/drm_atomic_helper.c |6 ++ > drivers/gpu/drm/drm_connector.c |7 ++ > drivers/gpu/drm/drm_edid.c | 151 > +++ > drivers/gpu/drm/i915/intel_hdmi.c | 27 +++ > drivers/video/hdmi.c| 138 > include/drm/drm_connector.h | 13 +++ > include/drm/drm_edid.h |4 + > include/drm/drm_mode_config.h |6 ++ > include/drm/drm_plane.h |3 + > include/linux/hdmi.h| 21 + > include/uapi/drm/drm_mode.h | 22 + > 12 files changed, 413 insertions(+) > > -- > 1.7.9.5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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] [PULL] topic/e1000e-fix
From: Daniel Vetter Date: Tue, 30 May 2017 22:15:42 +0200 > If the e1000e maintainer wants to coalesce or not return statements > this simple way, that's imo on him to change the color as needed. That's not how things work. If the maintainer wants you to style things a certain way, either you do it that way or your patch isn't accepted. Thanks. ___ 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: Fix locking in drm_atomic_helper_resume (rev2)
== Series Details == Series: drm: Fix locking in drm_atomic_helper_resume (rev2) URL : https://patchwork.freedesktop.org/series/25018/ State : success == Summary == Series 25018v2 drm: Fix locking in drm_atomic_helper_resume https://patchwork.freedesktop.org/api/1.0/series/25018/revisions/2/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:440s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:432s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:582s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:511s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:490s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:484s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:432s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:411s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:415s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:496s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:461s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:463s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:573s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:462s fi-skl-6700hqtotal:278 pass:239 dwarn:0 dfail:1 fail:17 skip:21 time:433s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:470s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:500s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:436s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:533s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:398s 4aa1d46d3b24bbe545cdf7cbd407c18f5cd5e43d drm-tip: 2017y-05m-31d-08h-58m-36s UTC integration manifest 826a58f drm: Fix locking in drm_atomic_helper_resume == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4838/ ___ 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: more doc work&cleanup, mostly vblank related (rev4)
== Series Details == Series: drm: more doc work&cleanup, mostly vblank related (rev4) URL : https://patchwork.freedesktop.org/series/24877/ State : success == Summary == Series 24877v4 drm: more doc work&cleanup, mostly vblank related https://patchwork.freedesktop.org/api/1.0/series/24877/revisions/4/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:441s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:437s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:582s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:513s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:490s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:487s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:432s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:416s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:419s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:498s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:462s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:463s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:570s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:461s fi-skl-6700hqtotal:278 pass:239 dwarn:0 dfail:1 fail:17 skip:21 time:430s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:465s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:502s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:436s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:537s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:401s 4aa1d46d3b24bbe545cdf7cbd407c18f5cd5e43d drm-tip: 2017y-05m-31d-08h-58m-36s UTC integration manifest 5e6b8bd drm/doc: vblank cleanup fe65d6d drm/doc: Drop empty include for drm_color_mgmt.h 2ba5557 drm/doc: Polish irq helper documentation 7c77f48 drm: Extract drm_vblank.[hc] 0664adb drm/doc: Improve ioctl/fops docs a bit more 9a401b4 drm/pci: Deprecate drm_pci_init/exit completely 8340653 drm: Remove drm_driver->set_busid hook 820600a drm/udl: Remove dummy busid callback == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4839/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dvo: fix debug logging on unknown DID
Print DID not VID on the DID error path. Looks like a copy-paste error
from the VID error path. Clarify and clean up error logging, making them
distinguishable from each other, while at it.
Reported-by: Petru Mihancea
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101243
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/dvo_ch7xxx.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ch7xxx.c
b/drivers/gpu/drm/i915/dvo_ch7xxx.c
index 44b3159f2fe8..7aeeffd2428b 100644
--- a/drivers/gpu/drm/i915/dvo_ch7xxx.c
+++ b/drivers/gpu/drm/i915/dvo_ch7xxx.c
@@ -217,9 +217,8 @@ static bool ch7xxx_init(struct intel_dvo_device *dvo,
name = ch7xxx_get_id(vendor);
if (!name) {
- DRM_DEBUG_KMS("ch7xxx not detected; got 0x%02x from %s "
- "slave %d.\n",
- vendor, adapter->name, dvo->slave_addr);
+ DRM_DEBUG_KMS("ch7xxx not detected; got VID 0x%02x from %s
slave %d.\n",
+ vendor, adapter->name, dvo->slave_addr);
goto out;
}
@@ -229,9 +228,8 @@ static bool ch7xxx_init(struct intel_dvo_device *dvo,
devid = ch7xxx_get_did(device);
if (!devid) {
- DRM_DEBUG_KMS("ch7xxx not detected; got 0x%02x from %s "
- "slave %d.\n",
- vendor, adapter->name, dvo->slave_addr);
+ DRM_DEBUG_KMS("ch7xxx not detected; got DID 0x%02x from %s
slave %d.\n",
+ device, adapter->name, dvo->slave_addr);
goto out;
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Reviving the PWM_LPSS patches yet again
== Series Details == Series: Reviving the PWM_LPSS patches yet again URL : https://patchwork.freedesktop.org/series/25090/ State : success == Summary == Series 25090v1 Reviving the PWM_LPSS patches yet again https://patchwork.freedesktop.org/api/1.0/series/25090/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:444s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:438s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:584s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:515s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:489s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:487s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:429s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:410s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:417s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:496s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:461s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:463s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:570s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:460s fi-skl-6700hqtotal:278 pass:239 dwarn:0 dfail:1 fail:17 skip:21 time:426s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:462s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:498s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:441s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:532s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:401s 4aa1d46d3b24bbe545cdf7cbd407c18f5cd5e43d drm-tip: 2017y-05m-31d-08h-58m-36s UTC integration manifest 64799fa drm/i915: Add support for LPSS PWM on devices that support it ca89437 pwm: lpss: Add intel-gfx as consumer device in lookup table 20ba8a2 drm/i915: Encapsulate the pwm_device in a pwm_info structure == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4840/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] igt/gem_fence_upload: Stabilise the test for CI
From: Tvrtko Ursulin
Most of the subtest were failing on my SKL GT2 and on the
various CI systems as well. Try to fix that by different
tweaks per subtests:
performance:
We cannot say how big the performance drop will be once the
fences are contented, just that there will be one, so modify
the assert accordingly.
thread-performance-*:
Similar to "performance", but also the peak performance to
compare against seems to be num_cpu dependant which the
biggest aggregate throughput with num_cpu clients.
Also, writes are much faster than reads which was making
the "-write" subtest a bit unstable. Increased the number
of iterations to hopefully stabilise this.
thread-contention:
Same as "performance" - we don't know how big the drop to
expect.
wc-contention:
This subtest should not expect a tiled performance drop since
CPU WC maps are under test. Change a few things:
1.
Number of iterations was to small causing result instability.
2.
There seems to be a performance valley with num_threads ==
num_cpus so do a pre-warm step in those cases which seem to fix
it.
3.
Only assert that the final step is slower than the reference,
and for the reference take the single thred result which looks
to be the fastest.
4.
Check that linear vs tiled results in each step are within
15% tolerance to verify the above attempts to stabilise the
test.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
tests/gem_fence_upload.c | 51 +++-
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/tests/gem_fence_upload.c b/tests/gem_fence_upload.c
index 7d9acdc0fcb3..d656d4ea70f8 100644
--- a/tests/gem_fence_upload.c
+++ b/tests/gem_fence_upload.c
@@ -103,7 +103,7 @@ static void performance(void)
errno = 0;
igt_assert(linear[1] > 0.75 * linear[0]);
- igt_assert(tiled[1] > 0.75 * tiled[0]);
+ igt_assert(tiled[1] < tiled[0]);
}
struct thread_performance {
@@ -155,7 +155,8 @@ static const char *direction_string(unsigned mask)
}
static void thread_performance(unsigned mask)
{
- const int loops = 4096;
+ const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
+ const int loops = (mask & READ) ? 4096 : 32768;
int n, count;
int fd, num_fences;
double linear[2], tiled[2];
@@ -164,9 +165,11 @@ static void thread_performance(unsigned mask)
num_fences = gem_available_fences(fd);
igt_require(num_fences > 0);
+ igt_require(num_fences > ncpus);
for (count = 2; count < 4*num_fences; count *= 2) {
const int nthreads = (mask & READ ? count : 0) + (mask & WRITE
? count : 0);
+ const int idx = ncpus != count;
struct timeval start, end;
struct thread_performance readers[count];
struct thread_performance writers[count];
@@ -209,8 +212,8 @@ static void thread_performance(unsigned mask)
}
gettimeofday(&end, NULL);
- linear[count != 2] = nthreads * loops / elapsed(&start, &end) /
(OBJECT_SIZE / 4096);
- igt_info("%s rate for %d linear surfaces, %d threads:
%7.3fMiB/s\n", direction_string(mask), count, nthreads, linear[count != 2]);
+ linear[idx] = nthreads * loops / elapsed(&start, &end) /
(OBJECT_SIZE / 4096);
+ igt_info("%s rate for %d linear surfaces, %d threads:
%7.3fMiB/s\n", direction_string(mask), count, nthreads, linear[idx]);
for (n = 0; n < count; n++)
gem_set_tiling(fd, handle[n], I915_TILING_X, 1024);
@@ -230,8 +233,8 @@ static void thread_performance(unsigned mask)
}
gettimeofday(&end, NULL);
- tiled[count != 2] = nthreads * loops / elapsed(&start, &end) /
(OBJECT_SIZE / 4096);
- igt_info("%s rate for %d tiled surfaces, %d threads:
%7.3fMiB/s\n", direction_string(mask), count, nthreads, tiled[count != 2]);
+ tiled[idx] = nthreads * loops / elapsed(&start, &end) /
(OBJECT_SIZE / 4096);
+ igt_info("%s rate for %d tiled surfaces, %d threads:
%7.3fMiB/s\n", direction_string(mask), count, nthreads, tiled[idx]);
for (n = 0; n < count; n++) {
munmap(ptr[n], OBJECT_SIZE);
@@ -241,7 +244,7 @@ static void thread_performance(unsigned mask)
errno = 0;
igt_assert(linear[1] > 0.75 * linear[0]);
- igt_assert(tiled[1] > 0.75 * tiled[0]);
+ igt_assert(tiled[1] < tiled[0]);
}
struct thread_contention {
@@ -329,13 +332,13 @@ static void thread_contention(void)
errno = 0;
igt_assert(linear[1] > 0.75 * linear[0]);
- igt_assert(tiled[1] > 0.75 * tiled[0]);
+ igt_assert(tiled[1] < tiled[0]);
}
static void wc_contention(void)
{
- const int loops = 4096;
- int n, count;
+ const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
+ int n, count, order;
int fd,
[Intel-gfx] ✓ Fi.CI.BAT: success for Add HDR Metadata Parsing and handling in DRM layer
== Series Details == Series: Add HDR Metadata Parsing and handling in DRM layer URL : https://patchwork.freedesktop.org/series/25091/ State : success == Summary == Series 25091v1 Add HDR Metadata Parsing and handling in DRM layer https://patchwork.freedesktop.org/api/1.0/series/25091/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:447s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:437s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:565s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:510s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:483s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:482s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:430s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:406s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:417s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:501s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:464s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:469s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:568s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:460s fi-skl-6700hqtotal:278 pass:239 dwarn:0 dfail:1 fail:17 skip:21 time:439s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:463s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:507s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:435s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:531s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:407s 4aa1d46d3b24bbe545cdf7cbd407c18f5cd5e43d drm-tip: 2017y-05m-31d-08h-58m-36s UTC integration manifest 80ea7eb drm/i915: Write HDR infoframe and send to panel bb69a3f drm: Enable HDR infoframe support 1b963db drm: Implement HDR source metadata set and get property handling 911c67e drm: Add HDR capabilty field to plane structure 8e5e780 drm/i915: Attach HDR metadata property to connector 0add68b drm: Parse Colorimetry data block from EDID c3de98a drm: Parse HDR metadata info from EDID d3b603b drm: Add CEA extended tag blocks and HDR bitfield macros 64003ce drm: Add HDR source metadata property == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4841/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Always recompute watermarks when distrust_bios_wm is set
Hi,
On Wednesday 31 May 2017 01:26 PM, Maarten Lankhorst wrote:
On some systems there can be a race condition in which no crtc state is
added to the first atomic commit. This results in all crtc's having a
null DDB allocation, causing a FIFO underrun on any update until the
first modeset.
Reported-by: Maarten Lankhorst
Inspired-by: Mahesh Kumar
Signed-off-by: Maarten Lankhorst
Fixes: 98d39494d375 ("drm/i915/gen9: Compute DDB allocation at atomic
check time (v4)")
Cc: # v4.8+
Cc: Mahesh Kumar
Cc: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a488e068c3d6..8daa382b47f3 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5037,10 +5037,27 @@ skl_compute_wm(struct drm_atomic_state *state)
struct drm_crtc_state *cstate;
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct skl_wm_values *results = &intel_state->wm_results;
+ struct drm_device *dev = state->dev;
struct skl_pipe_wm *pipe_wm;
bool changed = false;
int ret, i;
+ if (to_i915(dev)->wm.distrust_bios_wm) {
+ changed = true;
+
+ /*
+* The first commit after driver load must update the ddb
+* allocations, so make sure we at least hold a lock to
+* inspect the state required for watermark updates.
+*
+* Below we'll grab the required crtc state.
+*/
+ ret = drm_modeset_lock(&dev->mode_config.connection_mutex,
+ state->acquire_ctx);
Do we need to get lock here?
We will anyway go ahead & get the connection_mutex lock during
skl_compute_ddb based on distruct_bios_wm flag.
-Mahesh
+ if (ret)
+ return ret;
+ }
+
/*
* If this transaction isn't actually touching any CRTC's, don't
* bother with watermark calculation. Note that if we pass this
@@ -5051,6 +5068,7 @@ skl_compute_wm(struct drm_atomic_state *state)
*/
for_each_new_crtc_in_state(state, crtc, cstate, i)
changed = true;
+
if (!changed)
return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] lib/kms: Force a full reprobe if we find a bad link
On 26/05/17 14:48, Chris Wilson wrote: If we do a shallow probe of the connector and it reports the link failed previous (link-status != GOOD), force a full probe of the connector to give the kernel a chance to validate the mode list. Sounds good, but will this make the tests SKIP if no modes are available? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dvo: fix debug logging on unknown DID
== Series Details == Series: drm/i915/dvo: fix debug logging on unknown DID URL : https://patchwork.freedesktop.org/series/25093/ State : failure == Summary == Series 25093v1 drm/i915/dvo: fix debug logging on unknown DID https://patchwork.freedesktop.org/api/1.0/series/25093/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test gem_sync: Subgroup basic-store-all: pass -> FAIL (fi-ivb-3770) fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:445s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:438s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:577s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:509s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:488s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:479s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:434s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:420s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:425s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:493s fi-ivb-3770 total:278 pass:259 dwarn:0 dfail:0 fail:1 skip:18 time:466s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:465s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:565s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:456s fi-skl-6700hqtotal:278 pass:239 dwarn:0 dfail:1 fail:17 skip:21 time:426s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:464s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:498s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:436s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:538s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:403s 4aa1d46d3b24bbe545cdf7cbd407c18f5cd5e43d drm-tip: 2017y-05m-31d-08h-58m-36s UTC integration manifest 1f3deb5 drm/i915/dvo: fix debug logging on unknown DID == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4842/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup
Hi Daniel, On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote: > IRQs are properly shut down, so it almost works as race-free shutdown. > Except the irq is stopped after the vblank stuff, so boom anyway. > Proper way would be to call drm_atomic_helper_shutdown before any of > the kms things gets stopped. So no harm in removing the > drm_vblank_cleanup here really. Slightly confused on the implied message in the commit text: is "Proper way would be to call drm_atomic_helper_shutdown" a hint? A promise of a future patch? A message to the future us on how to fix things if they blow up? If calling drm_atomic_helper_shutdown() is the proper thing to do, why does the patch (and the series) avoids doing that? Lack of understanding of the driver's internal workings? Then I want to help, if I can understand the new direction. Best regards, Liviu > > Same story for both hdlcd and mali. > > v2: Move misplaced malidp hunk to this patch (Liviu). > > Cc: Liviu Dudau > Cc: Brian Starkey > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/arm/hdlcd_drv.c | 2 -- > drivers/gpu/drm/arm/malidp_drv.c | 2 -- > 2 files changed, 4 deletions(-) > > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c > index 0f49c4b12772..345c8357b273 100644 > --- a/drivers/gpu/drm/arm/hdlcd_drv.c > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c > @@ -340,7 +340,6 @@ static int hdlcd_drm_bind(struct device *dev) > } > err_fbdev: > drm_kms_helper_poll_fini(drm); > - drm_vblank_cleanup(drm); > err_vblank: > pm_runtime_disable(drm->dev); > err_pm_active: > @@ -368,7 +367,6 @@ static void hdlcd_drm_unbind(struct device *dev) > } > drm_kms_helper_poll_fini(drm); > component_unbind_all(dev, drm); > - drm_vblank_cleanup(drm); > pm_runtime_get_sync(drm->dev); > drm_irq_uninstall(drm); > pm_runtime_put_sync(drm->dev); > diff --git a/drivers/gpu/drm/arm/malidp_drv.c > b/drivers/gpu/drm/arm/malidp_drv.c > index 0d3eb537d08b..01b13d219917 100644 > --- a/drivers/gpu/drm/arm/malidp_drv.c > +++ b/drivers/gpu/drm/arm/malidp_drv.c > @@ -652,7 +652,6 @@ static int malidp_bind(struct device *dev) > drm_kms_helper_poll_fini(drm); > fbdev_fail: > pm_runtime_get_sync(dev); > - drm_vblank_cleanup(drm); > vblank_fail: > malidp_se_irq_fini(drm); > malidp_de_irq_fini(drm); > @@ -692,7 +691,6 @@ static void malidp_unbind(struct device *dev) > } > drm_kms_helper_poll_fini(drm); > pm_runtime_get_sync(dev); > - drm_vblank_cleanup(drm); > malidp_se_irq_fini(drm); > malidp_de_irq_fini(drm); > component_unbind_all(dev, drm); > -- > 2.11.0 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Always recompute watermarks when distrust_bios_wm is set
Op 31-05-17 om 12:42 schreef Mahesh Kumar:
> Hi,
>
>
> On Wednesday 31 May 2017 01:26 PM, Maarten Lankhorst wrote:
>> On some systems there can be a race condition in which no crtc state is
>> added to the first atomic commit. This results in all crtc's having a
>> null DDB allocation, causing a FIFO underrun on any update until the
>> first modeset.
>>
>> Reported-by: Maarten Lankhorst
>> Inspired-by: Mahesh Kumar
>> Signed-off-by: Maarten Lankhorst
>> Fixes: 98d39494d375 ("drm/i915/gen9: Compute DDB allocation at atomic
>> check time (v4)")
>> Cc: # v4.8+
>> Cc: Mahesh Kumar
>> Cc: Matt Roper
>> ---
>> drivers/gpu/drm/i915/intel_pm.c | 18 ++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index a488e068c3d6..8daa382b47f3 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -5037,10 +5037,27 @@ skl_compute_wm(struct drm_atomic_state *state)
>> struct drm_crtc_state *cstate;
>> struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
>> struct skl_wm_values *results = &intel_state->wm_results;
>> +struct drm_device *dev = state->dev;
>> struct skl_pipe_wm *pipe_wm;
>> bool changed = false;
>> int ret, i;
>> +if (to_i915(dev)->wm.distrust_bios_wm) {
>> +changed = true;
>> +
>> +/*
>> + * The first commit after driver load must update the ddb
>> + * allocations, so make sure we at least hold a lock to
>> + * inspect the state required for watermark updates.
>> + *
>> + * Below we'll grab the required crtc state.
>> + */
>> +ret = drm_modeset_lock(&dev->mode_config.connection_mutex,
>> + state->acquire_ctx);
> Do we need to get lock here?
> We will anyway go ahead & get the connection_mutex lock during
> skl_compute_ddb based on distruct_bios_wm flag.
Oh right, missed that one, yeah ignore it. :)
I'll send the original patch again, thanks for catching.
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup
On Wed, May 31, 2017 at 12:57 PM, Liviu Dudau wrote: > On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote: >> IRQs are properly shut down, so it almost works as race-free shutdown. >> Except the irq is stopped after the vblank stuff, so boom anyway. >> Proper way would be to call drm_atomic_helper_shutdown before any of >> the kms things gets stopped. So no harm in removing the >> drm_vblank_cleanup here really. > > Slightly confused on the implied message in the commit text: is "Proper way > would be to call drm_atomic_helper_shutdown" a hint? A promise of a future > patch? A message to the future us on how to fix things if they blow up? > > If calling drm_atomic_helper_shutdown() is the proper thing to do, why does > the > patch (and the series) avoids doing that? Lack of understanding of the > driver's > internal workings? Then I want to help, if I can understand the new direction. Yes, I wanted to not make things worse. If you look at the overall result (especially last patch) I'm also trying to better document stuff in the vblank area, but summarized, if you want to make sure that vblank processing has stopped, you need to call drm_vblank_off on each active crtc. The simplest way to get that is by using drm_atomic_helper_shutdown(). Calling drm_vblank_cleanup doesn't really do anything useful (see the last patch for the only valid usecase there ever was). -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 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup
On Wed, May 31, 2017 at 01:03:34PM +0200, Daniel Vetter wrote: > On Wed, May 31, 2017 at 12:57 PM, Liviu Dudau wrote: > > On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote: > >> IRQs are properly shut down, so it almost works as race-free shutdown. > >> Except the irq is stopped after the vblank stuff, so boom anyway. > >> Proper way would be to call drm_atomic_helper_shutdown before any of > >> the kms things gets stopped. So no harm in removing the > >> drm_vblank_cleanup here really. > > > > Slightly confused on the implied message in the commit text: is "Proper way > > would be to call drm_atomic_helper_shutdown" a hint? A promise of a future > > patch? A message to the future us on how to fix things if they blow up? > > > > If calling drm_atomic_helper_shutdown() is the proper thing to do, why does > > the > > patch (and the series) avoids doing that? Lack of understanding of the > > driver's > > internal workings? Then I want to help, if I can understand the new > > direction. > > Yes, I wanted to not make things worse. If you look at the overall > result (especially last patch) I'm also trying to better document > stuff in the vblank area, but summarized, if you want to make sure > that vblank processing has stopped, you need to call drm_vblank_off on > each active crtc. The simplest way to get that is by using > drm_atomic_helper_shutdown(). Calling drm_vblank_cleanup doesn't > really do anything useful (see the last patch for the only valid > usecase there ever was). OK, so there should be a follow up patch adding drm_atomic_helper_shutdown(). I guess I need to call dibs on it? :) Best regards, Liviu > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 5/6] drm/i915/gvt: Dmabuf support for GVT-g
On Sat, 2017-05-27 at 16:38 +0800, Xiaoguang Chen wrote:
> + if (plane_id == PLANE_PRIMARY) {
Should be DRM_PLANE_TYPE_PRIMARY (likewise for the cursor).
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t] GEM features into feat_profile.json
Hello,
I went through the gem_* tests from intel-gpu-tools and categorized
them into roughly categories "X | X robustness | X performance" ready
to be added to the feat_profile.json.
Lets open a discussion which ones should go where. I tried to place a
single test to under only one category and I'm kind of hopeful that
we'll have the ability to add "depends_on" to create super features in
the future, instead of placing a single test under multiple categories.
I didn't check all the subtests nor wildcard matching with other tests,
this is just all the test names placed under some categories.
Regards, Joonas
PS. I'm still bit unsure where to place gem_spin_batch.c while tests
gem_pipe_control_store_loop, gem_bad_address, gem_bad_batch,
gem_bad_blit, gem_bad_length and gem_bad_reloc seem more like hardware
sanity checks.
---
"Driver API" : {
"include_tests": "gem_basic",
},
"Driver API robustness" : {
"include_tests": "gem_close_race|gem_fd_exhaustion|gem_eio",
},
"Basic IOCTLs": {
"include_tests": "gem_create|gem_busy|gem_unref_active_buffers",
},
"R/W contention" : {
"include_tests":
"gem_gtt_cpu_tlb|gem_pread_after_blit|gem_pwrite_snooped|gem_readwrite|gem_caching|gem_exec_flush|gem_stress",
},
"R/W concurrency" : {
"include_tests":
"gem_concurrent_all|gem_concurrent_blit|gem_exec_parallel|gem_partial_pwrite_pread",
},
"Relocations" : {
"include_tests": "gem_exec_reloc|gem_cpu_reloc|gem_persistent_relocs",
},
"Relocations robustness" : {
"include_tests":
"gem_exec_faulting_reloc|gem_exec_bad_domains|gem_reloc_overflow|gem_reloc_vs_gpu",
},
"Command streamer robustness" : {
"include_tests": "gem_cs_tlb|gem_cs_prefetch",
},
"Contexts" : {
"include_tests": "gem_ctx_basic|gem_ctx_exec|gem_ctx_param",
},
"Context robustness" : {
"include_tests":
"gem_ctx_create|gem_ctx_bad_destroy|gem_ctx_bad_exec|gem_ctx_switch|gem_ctx_thrash",
},
"Interrupts robustness" : {
"include_tests": "gem_double_irq_loop|gem_ring_sync_loop|gem_sync",
},
"Eviction" : {
"include_tests": "gem_evict|gem_exec_gttfill|gem_shrink",
},
"Execbuf IOCTL" : {
"include_tests":
"gem_exec_basic|gem_exec_alignment|gem_exec_lut_handle|gem_lut_handle",
},
"Execbuf IOCTL performance" : {
"include_tests":
"gem_exec_blt|gem_exec_create|gem_exec_latency|gem_exec_nop|gem_exec_reuse",
},
"Execbuf IOCTL robustness" : {
"include_tests":
"gem_exec_params|gem_fenced_exec_thrash|gem_exec_whisper",
},
"Suspend and resume" : {
"include_tests": "gem_exec_suspend",
},
"Scheduler" : {
"include_tests": "gem_exec_schedule",
},
"Asynchronous execution" : {
"include_tests": "gem_exec_async",
},
"Command parser" : {
"include_tests": "gem_exec_parse",
},
"Fences, implicit" : {
"include_tests": "gem_exec_await",
},
"Fences, explicit" : {
"include_tests": "gem_exec_fence",
},
"Tiling" : {
"include_tests":
"gem_fence_upload|gem_set_tiling_vs_blt|gem_set_tiling_vs_gtt|gem_set_tiling_vs_pwrite|gem_tiled_pread_basic|gem_tiled_pread_pwrite|gem_tiled_wb|gem_tiled_wc|gem_tiling_max_stride",
},
"Tiling robustness" : {
"include_tests":
"gem_fence_thrash|gem_gtt_hog|gem_render_tiled_blits|gem_threaded_access_tiled|gem_tiled_blits|gem_tiled_fence_blits|gem_tiled_swapping|gem_tiled_partial_pwrite_pread|gem_unfence_active_buffers",
},
"GGTT contention" : {
"include_tests": "gem_gtt_hog|gem_linear_blits",
},
"Global objects" : {
"include_tests": "gem_flink_basic",
},
"Global objects robustness" : {
"include_tests": "gem_flink_race",
},
"Workloads" : {
"include_tests": "gem_storedw_batches_loop|gem_storedw_loop",
},
"Workloads, GPGPU" : {
"include_tests": "gem_gpgpu_fill",
},
"Workloads, media" : {
"include_tests": "gem_media_fill",
},
"Workloads, render" : {
"include_tests": "gem_render_copy",
},
"Workloads robustness, render" : {
"include_tests": "gem_render_copy_redux|gem_render_linear_blits",
},
"Workloads robustness" : {
"include_tests": "gem_ringfill",
},
"GGTT performance" : {
"include_tests": "gem_gtt_speed",
},
"Hang recovery" : {
"include_tests": "gem_hang|gem_hangcheck_forcewake|gem_exec_capture",
},
"Large object support" : {
"include_tests": "gem_exec_big|gem_largeobject",
},
"Purging objects" : {
"include_tests": "gem_madvise",
},
"mmap IOCTL" : {
"include_tests": "gem_mmap|gem_mmap_gtt|gem_mmap_wc",
},
"mmap IOCTL robustness" : {
"include_tests": "gem_mmap_offset_exhaustion",
},
"MOCS" : {
"include_tests": "gem_mocs_settings",
},
"Secure batches robustness" : {
"include_
[Intel-gfx] [PATCH v15 01/14] drm/i915: Record both min/max eu_per_subslice in sseu_dev_info
From: Chris Wilson
When we query the available eu on each subslice, we currently only
report the max. It would also be useful to report the minimum found as
well.
When we set RPCS (power gating over the EU), we can also specify both
the min and max number of eu to configure on each slice; currently we
just set it to a single value, but the flexibility may be beneficial in
future.
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 36 +++-
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_device_info.c | 32 +---
drivers/gpu/drm/i915/intel_lrc.c | 4 ++--
4 files changed, 50 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3b088685a553..9bdf2bd59fbb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4497,6 +4497,7 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_cache_sharing_fops,
static void cherryview_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
{
+ unsigned int min_eu_per_subslice, max_eu_per_subslice;
int ss_max = 2;
int ss;
u32 sig1[ss_max], sig2[ss_max];
@@ -4506,6 +4507,9 @@ static void cherryview_sseu_device_status(struct
drm_i915_private *dev_priv,
sig2[0] = I915_READ(CHV_POWER_SS0_SIG2);
sig2[1] = I915_READ(CHV_POWER_SS1_SIG2);
+ min_eu_per_subslice = ~0u;
+ max_eu_per_subslice = 0;
+
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4520,14 +4524,18 @@ static void cherryview_sseu_device_status(struct
drm_i915_private *dev_priv,
((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
((sig2[ss] & CHV_EU311_PG_ENABLE) ? 0 : 2);
sseu->eu_total += eu_cnt;
- sseu->eu_per_subslice = max_t(unsigned int,
- sseu->eu_per_subslice, eu_cnt);
+ min_eu_per_subslice = min(min_eu_per_subslice, eu_cnt);
+ max_eu_per_subslice = max(max_eu_per_subslice, eu_cnt);
}
+
+ sseu->min_eu_per_subslice = min_eu_per_subslice;
+ sseu->max_eu_per_subslice = max_eu_per_subslice;
}
static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
{
+ unsigned int min_eu_per_subslice, max_eu_per_subslice;
int s_max = 3, ss_max = 4;
int s, ss;
u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
@@ -4553,6 +4561,9 @@ static void gen9_sseu_device_status(struct
drm_i915_private *dev_priv,
GEN9_PGCTL_SSB_EU210_ACK |
GEN9_PGCTL_SSB_EU311_ACK;
+ min_eu_per_subslice = ~0u;
+ max_eu_per_subslice = 0;
+
for (s = 0; s < s_max; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
@@ -4578,11 +4589,14 @@ static void gen9_sseu_device_status(struct
drm_i915_private *dev_priv,
eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &
eu_mask[ss%2]);
sseu->eu_total += eu_cnt;
- sseu->eu_per_subslice = max_t(unsigned int,
- sseu->eu_per_subslice,
- eu_cnt);
+
+ min_eu_per_subslice = min(min_eu_per_subslice, eu_cnt);
+ max_eu_per_subslice = max(max_eu_per_subslice, eu_cnt);
}
}
+
+ sseu->min_eu_per_subslice = min_eu_per_subslice;
+ sseu->max_eu_per_subslice = max_eu_per_subslice;
}
static void broadwell_sseu_device_status(struct drm_i915_private *dev_priv,
@@ -4595,9 +4609,11 @@ static void broadwell_sseu_device_status(struct
drm_i915_private *dev_priv,
if (sseu->slice_mask) {
sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask;
- sseu->eu_per_subslice =
- INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
- sseu->eu_total = sseu->eu_per_subslice *
+ sseu->min_eu_per_subslice =
+ INTEL_INFO(dev_priv)->sseu.min_eu_per_subslice;
+ sseu->max_eu_per_subslice =
+ INTEL_INFO(dev_priv)->sseu.max_eu_per_subslice;
+ sseu->eu_total = sseu->max_eu_per_subslice *
sseu_subslice_total(sseu);
/* subtract fused off EU(s) from enabled slice(s) */
@@ -4628,8 +4644,8 @@ static void i915_print_sseu_info(struct seq_file *m, bool
is_available_info,
hweight8(sseu->subslice_mask));
seq_printf(m, "
[Intel-gfx] [PATCH v15 03/14] drm/i915: Record the sseu configuration per-context & engine
From: Chris Wilson
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configuration per context & engine (Chris)
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 19 ---
drivers/gpu/drm/i915/i915_gem_context.c | 6 ++
drivers/gpu/drm/i915/i915_gem_context.h | 21 +
drivers/gpu/drm/i915/intel_lrc.c| 23 +--
4 files changed, 36 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a9ce0da656dd..1c1ce2a5f30a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -780,25 +780,6 @@ struct intel_csr {
func(overlay_needs_physical); \
func(supports_tv);
-struct sseu_dev_info {
- u8 slice_mask;
- u8 subslice_mask;
- u8 eu_total;
- u8 min_eu_per_subslice;
- u8 max_eu_per_subslice;
- u8 min_eu_in_pool;
- /* For each slice, which subslice(s) has(have) 7 EUs (bitfield)? */
- u8 subslice_7eu[3];
- u8 has_slice_pg:1;
- u8 has_subslice_pg:1;
- u8 has_eu_pg:1;
-};
-
-static inline unsigned int sseu_subslice_total(const struct sseu_dev_info
*sseu)
-{
- return hweight8(sseu->slice_mask) * hweight8(sseu->subslice_mask);
-}
-
/* Keep in gen based order, and chronological order within a gen */
enum intel_platform {
INTEL_PLATFORM_UNINITIALIZED = 0,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index c5d1666d7071..60d0bbf0ae2b 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -184,6 +184,8 @@ __create_hw_context(struct drm_i915_private *dev_priv,
struct drm_i915_file_private *file_priv)
{
struct i915_gem_context *ctx;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
int ret;
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
@@ -229,6 +231,10 @@ __create_hw_context(struct drm_i915_private *dev_priv,
* is no remap info, it will be a NOP. */
ctx->remap_slice = ALL_L3_SLICES(dev_priv);
+ /* On all engines, use the whole device by default */
+ for_each_engine(engine, dev_priv, id)
+ ctx->engine[id].sseu = INTEL_INFO(dev_priv)->sseu;
+
i915_gem_context_set_bannable(ctx);
ctx->ring_size = 4 * PAGE_SIZE;
ctx->desc_template =
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index 4af2ab94558b..e8247e2f6011 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -39,6 +39,25 @@ struct i915_hw_ppgtt;
struct i915_vma;
struct intel_ring;
+struct sseu_dev_info {
+ u8 slice_mask;
+ u8 subslice_mask;
+ u8 eu_total;
+ u8 min_eu_per_subslice;
+ u8 max_eu_per_subslice;
+ u8 min_eu_in_pool;
+ /* For each slice, which subslice(s) has(have) 7 EUs (bitfield)? */
+ u8 subslice_7eu[3];
+ u8 has_slice_pg:1;
+ u8 has_subslice_pg:1;
+ u8 has_eu_pg:1;
+};
+
+static inline unsigned int sseu_subslice_total(const struct sseu_dev_info
*sseu)
+{
+ return hweight8(sseu->slice_mask) * hweight8(sseu->subslice_mask);
+}
+
#define DEFAULT_CONTEXT_HANDLE 0
/**
@@ -151,6 +170,8 @@ struct i915_gem_context {
u64 lrc_desc;
int pin_count;
bool initialised;
+ /** sseu: Control eu/slice partitioning */
+ struct sseu_dev_info sseu;
} engine[I915_NUM_ENGINES];
/** ring_size: size for allocating the per-engine ring buffer */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index fec66204fe88..78fb1f452891 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1810,8 +1810,7 @@ int logical_xcs_ring_init(struct intel_engine_cs *engine)
return logical_ring_init(engine);
}
-static u32
-make_rpcs(struct drm_i915_private *dev_priv)
+static u32 make_rpcs(const struct sseu_dev_info *sseu)
{
u32 rpcs = 0;
@@ -1821,25 +1820,21 @@ make_rpcs(struct drm_i915_private *dev_priv)
* must make an explicit request through RPCS for full
* enablement.
*/
- if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
+ if (sseu->has_slice_pg) {
rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
- GEN8_RPCS_S_CNT_SHIFT;
+ rpcs |= hweight8(sseu->slice_mask) << GEN8_RPCS_S_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
- if (INTEL_INFO(dev_pri
[Intel-gfx] [PATCH v15 00/14] Enable OA unit for Gen 8 and 9 in i915 perf
Hi, A quick update with a couple of fixes in patch 13 & 14. No changes in the other patches. Cheers, Chris Wilson (3): drm/i915: Record both min/max eu_per_subslice in sseu_dev_info drm/i915: Program RPCS for Broadwell drm/i915: Record the sseu configuration per-context & engine Lionel Landwerlin (6): drm/i915/perf: rework mux configurations queries drm/i915: add KBL GT2/GT3 check macros drm/i915/perf: add KBL support drm/i915/perf: add GLK support drm/i915/perf: reprogram NOA muxes at the beginning of each workload drm/i915/perf: notify sseu configuration changes Robert Bragg (5): drm/i915/perf: Add 'render basic' Gen8+ OA unit configs drm/i915/perf: Add OA unit support for Gen 8+ drm/i915/perf: Add more OA configs for BDW, CHV, SKL + BXT drm/i915/perf: per-gen timebase for checking sample freq drm/i915/perf: remove perf.hook_lock drivers/gpu/drm/i915/Makefile| 11 +- drivers/gpu/drm/i915/i915_debugfs.c | 36 +- drivers/gpu/drm/i915/i915_drv.h | 125 +- drivers/gpu/drm/i915/i915_gem_context.c |9 + drivers/gpu/drm/i915/i915_gem_context.h | 42 + drivers/gpu/drm/i915/i915_oa_bdw.c | 5376 ++ drivers/gpu/drm/i915/i915_oa_bdw.h | 40 + drivers/gpu/drm/i915/i915_oa_bxt.c | 2690 +++ drivers/gpu/drm/i915/i915_oa_bxt.h | 40 + drivers/gpu/drm/i915/i915_oa_chv.c | 2873 drivers/gpu/drm/i915/i915_oa_chv.h | 40 + drivers/gpu/drm/i915/i915_oa_glk.c | 2602 +++ drivers/gpu/drm/i915/i915_oa_glk.h | 40 + drivers/gpu/drm/i915/i915_oa_hsw.c | 263 +- drivers/gpu/drm/i915/i915_oa_hsw.h |4 +- drivers/gpu/drm/i915/i915_oa_kblgt2.c| 2991 + drivers/gpu/drm/i915/i915_oa_kblgt2.h| 40 + drivers/gpu/drm/i915/i915_oa_kblgt3.c| 3040 + drivers/gpu/drm/i915/i915_oa_kblgt3.h| 40 + drivers/gpu/drm/i915/i915_oa_sklgt2.c| 3479 +++ drivers/gpu/drm/i915/i915_oa_sklgt2.h| 40 + drivers/gpu/drm/i915/i915_oa_sklgt3.c| 3039 + drivers/gpu/drm/i915/i915_oa_sklgt3.h| 40 + drivers/gpu/drm/i915/i915_oa_sklgt4.c| 3093 + drivers/gpu/drm/i915/i915_oa_sklgt4.h| 40 + drivers/gpu/drm/i915/i915_perf.c | 1642 - drivers/gpu/drm/i915/i915_reg.h | 22 + drivers/gpu/drm/i915/intel_device_info.c | 32 +- drivers/gpu/drm/i915/intel_lrc.c | 39 +- drivers/gpu/drm/i915/intel_lrc.h |2 + drivers/gpu/drm/i915/intel_ringbuffer.c |3 + include/uapi/drm/i915_drm.h | 49 +- 32 files changed, 31531 insertions(+), 291 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.c create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.h create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.c create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.h create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.c create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.h create mode 100644 drivers/gpu/drm/i915/i915_oa_glk.c create mode 100644 drivers/gpu/drm/i915/i915_oa_glk.h create mode 100644 drivers/gpu/drm/i915/i915_oa_kblgt2.c create mode 100644 drivers/gpu/drm/i915/i915_oa_kblgt2.h create mode 100644 drivers/gpu/drm/i915/i915_oa_kblgt3.c create mode 100644 drivers/gpu/drm/i915/i915_oa_kblgt3.h create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.c create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.h create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.c create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.h create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.c create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.h -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v15 02/14] drm/i915: Program RPCS for Broadwell
From: Chris Wilson Currently we only configure the power gating for Skylake and above, but the configuration should equally apply to Broadwell and Braswell. Even though, there is not as much variation as for later generations, we want to expose control over the configuration to userspace and may want to opt out of the "always-enabled" setting. Signed-off-by: Chris Wilson Signed-off-by: Lionel Landwerlin Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_lrc.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 9a279a559a0f..fec66204fe88 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1816,13 +1816,6 @@ make_rpcs(struct drm_i915_private *dev_priv) u32 rpcs = 0; /* -* No explicit RPCS request is needed to ensure full -* slice/subslice/EU enablement prior to Gen9. - */ - if (INTEL_GEN(dev_priv) < 9) - return 0; - - /* * Starting in Gen9, render power gating can leave * slice/subslice/EU in a partially enabled state. We * must make an explicit request through RPCS for full -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v15 06/14] drm/i915/perf: Add OA unit support for Gen 8+
From: Robert Bragg
Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all
share (more-or-less) the same OA unit design.
Of particular note in comparison to Haswell: some OA unit HW config
state has become per-context state and as a consequence it is somewhat
more complicated to manage synchronous state changes from the cpu while
there's no guarantee of what context (if any) is currently actively
running on the gpu.
The periodic sampling frequency which can be particularly useful for
system-wide analysis (as opposed to command stream synchronised
MI_REPORT_PERF_COUNT commands) is perhaps the most surprising state to
have become per-context save and restored (while the OABUFFER
destination is still a shared, system-wide resource).
This support for gen8+ takes care to consider a number of timing
challenges involved in synchronously updating per-context state
primarily by programming all config state from the cpu and updating all
current and saved contexts synchronously while the OA unit is still
disabled.
The driver intentionally avoids depending on command streamer
programming to update OA state considering the lack of synchronization
between the automatic loading of OACTXCONTROL state (that includes the
periodic sampling state and enable state) on context restore and the
parsing of any general purpose BB the driver can control. I.e. this
implementation is careful to avoid the possibility of a context restore
temporarily enabling any out-of-date periodic sampling state. In
addition to the risk of transiently-out-of-date state being loaded
automatically; there are also internal HW latencies involved in the
loading of MUX configurations which would be difficult to account for
from the command streamer (and we only want to enable the unit when once
the MUX configuration is complete).
Since the Gen8+ OA unit design no longer supports clock gating the unit
off for a single given context (which effectively stopped any progress
of counters while any other context was running) and instead supports
tagging OA reports with a context ID for filtering on the CPU, it means
we can no longer hide the system-wide progress of counters from a
non-privileged application only interested in metrics for its own
context. Although we could theoretically try and subtract the progress
of other contexts before forwarding reports via read() we aren't in a
position to filter reports captured via MI_REPORT_PERF_COUNT commands.
As a result, for Gen8+, we always require the
dev.i915.perf_stream_paranoid to be unset for any access to OA metrics
if not root.
v5: Drain submitted requests when enabling metric set to ensure no
lite-restore erases the context image we just updated (Lionel)
v6: In addition to drain, switch to kernel context & update all
context in place (Chris)
v7: Add missing mutex_unlock() if switching to kernel context fails
(Matthew)
v8: Simplify OA period/flex-eu-counters programming by using the
batchbuffer instead of modifying ctx-image (Lionel)
v9: Back to updating the context image (due to erroneous testing,
batchbuffer programming the OA unit doesn't actually work)
(Lionel)
Pin context before updating context image (Chris)
Drop MMIO programming now that we switch to a kernel context with
right values in initial context image (Chris)
v10: Just pin_map the contexts we want to modify or let the
configuration happen on first use (Chris)
v11: Update kernel context OA config through the batchbuffer rather
than on the fly ctx-image update (Lionel)
v12: Rework OA context registers update again by swithing away from
user contexts and reconfiguring the kernel context through the
batchbuffer and updating all the other contexts' context image.
Also take care to lock slice/subslice configuration when OA is
on. (Lionel)
v13: Request rpcs updates on all engine when updating the OA config
(Lionel)
v14: Drop any kind of rpcs management now that we monitor sseu
configuration changes in a later patch (Lionel)
Remove usleep after programming the NOA configs on Gen8+, this
doesn't seem to be needed (Lionel)
Signed-off-by: Robert Bragg
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld \o/
---
drivers/gpu/drm/i915/i915_drv.h | 45 +-
drivers/gpu/drm/i915/i915_perf.c | 1005 +++---
drivers/gpu/drm/i915/i915_reg.h | 22 +
drivers/gpu/drm/i915/intel_lrc.c |2 +
drivers/gpu/drm/i915/intel_lrc.h |2 +
include/uapi/drm/i915_drm.h | 19 +-
6 files changed, 1000 insertions(+), 95 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a9aaff0f15e0..f59cbe99e4b4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1998,9 +1998,17 @@ struct i915_oa_ops {
void (*init_oa_buffer)(struct drm_i915_private *dev_priv);
/**
-* @enable_metric_set: Applies any MUX configuration t
[Intel-gfx] [PATCH v15 05/14] drm/i915/perf: Add 'render basic' Gen8+ OA unit configs
From: Robert Bragg
Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
render metrics on Broadwell, Cherryview, Skylake and Broxton. These are
auto generated from an XML description of metric sets, currently
maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scripts/i915-perf-kernelgen.py
$ make -C gputop-data -f Makefile.xml WHITELIST=RenderBasic
v2: add newlines to debug messages + fix comment (Matthew Auld)
Signed-off-by: Robert Bragg
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 8 +-
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/i915_oa_bdw.c| 392 ++
drivers/gpu/drm/i915/i915_oa_bdw.h| 40
drivers/gpu/drm/i915/i915_oa_bxt.c| 248 +
drivers/gpu/drm/i915/i915_oa_bxt.h| 40
drivers/gpu/drm/i915/i915_oa_chv.c| 238 +
drivers/gpu/drm/i915/i915_oa_chv.h| 40
drivers/gpu/drm/i915/i915_oa_sklgt2.c | 238 +
drivers/gpu/drm/i915/i915_oa_sklgt2.h | 40
drivers/gpu/drm/i915/i915_oa_sklgt3.c | 249 +
drivers/gpu/drm/i915/i915_oa_sklgt3.h | 40
drivers/gpu/drm/i915/i915_oa_sklgt4.c | 260 ++
drivers/gpu/drm/i915/i915_oa_sklgt4.h | 40
14 files changed, 1876 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 16dccf550412..49a628cdef9e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -129,7 +129,13 @@ i915-y += i915_vgpu.o
# perf code
i915-y += i915_perf.o \
- i915_oa_hsw.o
+ i915_oa_hsw.o \
+ i915_oa_bdw.o \
+ i915_oa_chv.o \
+ i915_oa_sklgt2.o \
+ i915_oa_sklgt3.o \
+ i915_oa_sklgt4.o \
+ i915_oa_bxt.o
ifeq ($(CONFIG_DRM_I915_GVT),y)
i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1c0e6f9803bc..a9aaff0f15e0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2397,12 +2397,14 @@ struct drm_i915_private {
int metrics_set;
- const struct i915_oa_reg *mux_regs[1];
- int mux_regs_lens[1];
+ const struct i915_oa_reg *mux_regs[2];
+ int mux_regs_lens[2];
int n_mux_configs;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
+ const struct i915_oa_reg *flex_regs;
+ int flex_regs_len;
struct {
struct i915_vma *vma;
diff --git a/drivers/gpu/drm/i915/i915_oa_bdw.c
b/drivers/gpu/drm/i915/i915_oa_bdw.c
new file mode 100644
index ..9a11c03b4ecb
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_bdw.c
@@ -0,0 +1,392 @@
+/*
+ * Autogenerated file by GPU Top : https://github.com/rib/gputop
+ * DO NOT EDIT manually!
+ *
+ *
+ * Copyright (c) 2015 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 SOFTWA
[Intel-gfx] [PATCH v15 12/14] drm/i915/perf: add GLK support
Add OA support for Geminilake (pretty much identical to Broxton), and
also add the associated OA configurations.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile |3 +-
drivers/gpu/drm/i915/i915_oa_glk.c | 2602
drivers/gpu/drm/i915/i915_oa_glk.h | 40 +
drivers/gpu/drm/i915/i915_perf.c | 17 +-
4 files changed, 2659 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_oa_glk.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_glk.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 033a2df01dbe..f8227318dcaf 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -137,7 +137,8 @@ i915-y += i915_perf.o \
i915_oa_sklgt4.o \
i915_oa_bxt.o \
i915_oa_kblgt2.o \
- i915_oa_kblgt3.o
+ i915_oa_kblgt3.o \
+ i915_oa_glk.o
ifeq ($(CONFIG_DRM_I915_GVT),y)
i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_oa_glk.c
b/drivers/gpu/drm/i915/i915_oa_glk.c
new file mode 100644
index ..2f356d51bff8
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_glk.c
@@ -0,0 +1,2602 @@
+/*
+ * Autogenerated file by GPU Top : https://github.com/rib/gputop
+ * DO NOT EDIT manually!
+ *
+ *
+ * Copyright (c) 2015 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
+
+#include "i915_drv.h"
+#include "i915_oa_glk.h"
+
+enum metric_set_id {
+ METRIC_SET_ID_RENDER_BASIC = 1,
+ METRIC_SET_ID_COMPUTE_BASIC,
+ METRIC_SET_ID_RENDER_PIPE_PROFILE,
+ METRIC_SET_ID_MEMORY_READS,
+ METRIC_SET_ID_MEMORY_WRITES,
+ METRIC_SET_ID_COMPUTE_EXTENDED,
+ METRIC_SET_ID_COMPUTE_L3_CACHE,
+ METRIC_SET_ID_HDC_AND_SF,
+ METRIC_SET_ID_L3_1,
+ METRIC_SET_ID_RASTERIZER_AND_PIXEL_BACKEND,
+ METRIC_SET_ID_SAMPLER,
+ METRIC_SET_ID_TDL_1,
+ METRIC_SET_ID_TDL_2,
+ METRIC_SET_ID_COMPUTE_EXTRA,
+ METRIC_SET_ID_TEST_OA,
+};
+
+int i915_oa_n_builtin_metric_sets_glk = 15;
+
+static const struct i915_oa_reg b_counter_config_render_basic[] = {
+ { _MMIO(0x2710), 0x },
+ { _MMIO(0x2714), 0x0080 },
+ { _MMIO(0x2720), 0x },
+ { _MMIO(0x2724), 0x0080 },
+ { _MMIO(0x2740), 0x },
+};
+
+static const struct i915_oa_reg flex_eu_config_render_basic[] = {
+ { _MMIO(0xe458), 0x5004 },
+ { _MMIO(0xe558), 0x00010003 },
+ { _MMIO(0xe658), 0x00012011 },
+ { _MMIO(0xe758), 0x00015014 },
+ { _MMIO(0xe45c), 0x00051050 },
+ { _MMIO(0xe55c), 0x00053052 },
+ { _MMIO(0xe65c), 0x00055054 },
+};
+
+static const struct i915_oa_reg mux_config_render_basic[] = {
+ { _MMIO(0x9888), 0x166c00f0 },
+ { _MMIO(0x9888), 0x12120280 },
+ { _MMIO(0x9888), 0x12320280 },
+ { _MMIO(0x9888), 0x11930317 },
+ { _MMIO(0x9888), 0x159303df },
+ { _MMIO(0x9888), 0x3f900c00 },
+ { _MMIO(0x9888), 0x419000a0 },
+ { _MMIO(0x9888), 0x002d1000 },
+ { _MMIO(0x9888), 0x062d4000 },
+ { _MMIO(0x9888), 0x082d5000 },
+ { _MMIO(0x9888), 0x0a2d1000 },
+ { _MMIO(0x9888), 0x0c2e0800 },
+ { _MMIO(0x9888), 0x0e2e5900 },
+ { _MMIO(0x9888), 0x0a4c8000 },
+ { _MMIO(0x9888), 0x0c4c8000 },
+ { _MMIO(0x9888), 0x0e4c4000 },
+ { _MMIO(0x9888), 0x064e8000 },
+ { _MMIO(0x9888), 0x084e8000 },
+ { _MMIO(0x9888), 0x0a4e2000 },
+ { _MMIO(0x9888), 0x1c4f0010 },
+ { _MMIO(0x9888), 0x0a6c0053 },
+ { _MMIO(0x9888), 0x106c },
+ { _MMIO(0x9888), 0x1c6c },
+ { _MMIO(0x9888), 0x1a0fcc00 },
+ { _MMIO(0x9888), 0x1c0f0002 },
+ { _MMIO(0x9888), 0x1c2c0040 },
+ { _MMIO(0x9888), 0x00101000 },
+ { _MMIO(0x9888), 0x04101000 },
+ { _MMIO(0x9888), 0x001140
[Intel-gfx] [PATCH v15 04/14] drm/i915/perf: rework mux configurations queries
Gen8+ might have mux configurations per slices/subslices. Depending on
whether slices/subslices have been fused off, only part of the
configuration needs to be applied. This change reworks the mux
configurations query mechanism to allow more than one set of registers
to be programmed.
v2: s/n_mux_regs/n_mux_configs/ (Matthew)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h| 6 +-
drivers/gpu/drm/i915/i915_oa_hsw.c | 215 -
drivers/gpu/drm/i915/i915_oa_hsw.h | 4 +-
drivers/gpu/drm/i915/i915_perf.c | 7 +-
4 files changed, 151 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1c1ce2a5f30a..1c0e6f9803bc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2397,8 +2397,10 @@ struct drm_i915_private {
int metrics_set;
- const struct i915_oa_reg *mux_regs;
- int mux_regs_len;
+ const struct i915_oa_reg *mux_regs[1];
+ int mux_regs_lens[1];
+ int n_mux_configs;
+
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index 4ddf756add31..8c13e0880e53 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -1,5 +1,7 @@
/*
- * Autogenerated file, DO NOT EDIT manually!
+ * Autogenerated file by GPU Top : https://github.com/rib/gputop
+ * DO NOT EDIT manually!
+ *
*
* Copyright (c) 2015 Intel Corporation
*
@@ -109,12 +111,21 @@ static const struct i915_oa_reg mux_config_render_basic[]
= {
{ _MMIO(0x25428), 0x00042049 },
};
-static const struct i915_oa_reg *
+static int
get_render_basic_mux_config(struct drm_i915_private *dev_priv,
- int *len)
+ const struct i915_oa_reg **regs,
+ int *lens)
{
- *len = ARRAY_SIZE(mux_config_render_basic);
- return mux_config_render_basic;
+ int n = 0;
+
+ BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs) < 1);
+ BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs_lens) < 1);
+
+ regs[n] = mux_config_render_basic;
+ lens[n] = ARRAY_SIZE(mux_config_render_basic);
+ n++;
+
+ return n;
}
static const struct i915_oa_reg b_counter_config_compute_basic[] = {
@@ -172,12 +183,21 @@ static const struct i915_oa_reg
mux_config_compute_basic[] = {
{ _MMIO(0x25428), 0x0c03 },
};
-static const struct i915_oa_reg *
+static int
get_compute_basic_mux_config(struct drm_i915_private *dev_priv,
-int *len)
+const struct i915_oa_reg **regs,
+int *lens)
{
- *len = ARRAY_SIZE(mux_config_compute_basic);
- return mux_config_compute_basic;
+ int n = 0;
+
+ BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs) < 1);
+ BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs_lens) < 1);
+
+ regs[n] = mux_config_compute_basic;
+ lens[n] = ARRAY_SIZE(mux_config_compute_basic);
+ n++;
+
+ return n;
}
static const struct i915_oa_reg b_counter_config_compute_extended[] = {
@@ -221,12 +241,21 @@ static const struct i915_oa_reg
mux_config_compute_extended[] = {
{ _MMIO(0x25428), 0x },
};
-static const struct i915_oa_reg *
+static int
get_compute_extended_mux_config(struct drm_i915_private *dev_priv,
- int *len)
+ const struct i915_oa_reg **regs,
+ int *lens)
{
- *len = ARRAY_SIZE(mux_config_compute_extended);
- return mux_config_compute_extended;
+ int n = 0;
+
+ BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs) < 1);
+ BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs_lens) < 1);
+
+ regs[n] = mux_config_compute_extended;
+ lens[n] = ARRAY_SIZE(mux_config_compute_extended);
+ n++;
+
+ return n;
}
static const struct i915_oa_reg b_counter_config_memory_reads[] = {
@@ -281,12 +310,21 @@ static const struct i915_oa_reg mux_config_memory_reads[]
= {
{ _MMIO(0x25428), 0x },
};
-static const struct i915_oa_reg *
+static int
get_memory_reads_mux_config(struct drm_i915_private *dev_priv,
- int *len)
+ const struct i915_oa_reg **regs,
+ int *lens)
{
- *len = ARRAY_SIZE(mux_config_memory_reads);
- return mux_config_memory_reads;
+ int n = 0;
+
+ BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs) < 1);
+ BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs_lens) < 1);
+
+ regs[n] = mux_config_memory_reads;
+
[Intel-gfx] [PATCH v15 13/14] drm/i915/perf: reprogram NOA muxes at the beginning of each workload
Dynamic slices/subslices shutdown will effectivelly loose the NOA
configuration uploaded in the slices/subslices. When i915 perf is in
use, we therefore need to reprogram it.
v2: Make sure we handle configs with more register writes than the max
MI_LOAD_REGISTER_IMM can do (Lionel)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_perf.c| 77 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 ++
3 files changed, 82 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c3acb0e9eb5d..499b2f9aa4be 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2400,6 +2400,7 @@ struct drm_i915_private {
const struct i915_oa_reg *mux_regs[6];
int mux_regs_lens[6];
int n_mux_configs;
+ int total_n_mux_regs;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
@@ -3535,6 +3536,7 @@ int i915_perf_open_ioctl(struct drm_device *dev, void
*data,
void i915_oa_init_reg_state(struct intel_engine_cs *engine,
struct i915_gem_context *ctx,
uint32_t *reg_state);
+int i915_oa_emit_noa_config_locked(struct drm_i915_gem_request *req);
/* i915_gem_evict.c */
int __must_check i915_gem_evict_something(struct i915_address_space *vm,
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c281847eb56b..4229c74baa22 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1438,11 +1438,24 @@ static void config_oa_regs(struct drm_i915_private
*dev_priv,
}
}
+static void count_total_mux_regs(struct drm_i915_private *dev_priv)
+{
+ int i;
+
+ dev_priv->perf.oa.total_n_mux_regs = 0;
+ for (i = 0; i < dev_priv->perf.oa.n_mux_configs; i++) {
+ dev_priv->perf.oa.total_n_mux_regs +=
+ dev_priv->perf.oa.mux_regs_lens[i];
+ }
+}
+
static int hsw_enable_metric_set(struct drm_i915_private *dev_priv)
{
int ret = i915_oa_select_metric_set_hsw(dev_priv);
int i;
+ count_total_mux_regs(dev_priv);
+
if (ret)
return ret;
@@ -1756,6 +1769,8 @@ static int gen8_enable_metric_set(struct drm_i915_private
*dev_priv)
int ret = dev_priv->perf.oa.ops.select_metric_set(dev_priv);
int i;
+ count_total_mux_regs(dev_priv);
+
if (ret)
return ret;
@@ -2094,6 +2109,68 @@ void i915_oa_init_reg_state(struct intel_engine_cs
*engine,
gen8_update_reg_state_unlocked(ctx, reg_state);
}
+int i915_oa_emit_noa_config_locked(struct drm_i915_gem_request *req)
+{
+ struct drm_i915_private *dev_priv = req->i915;
+ int max_loads = 125;
+ int n_load, n_registers, n_loaded_register;
+ int i, j;
+ u32 *cs;
+
+ lockdep_assert_held(&dev_priv->drm.struct_mutex);
+
+ if (!IS_GEN(dev_priv, 8, 9))
+ return 0;
+
+ /* Perf not supported or not enabled. */
+ if (!dev_priv->perf.initialized ||
+ !dev_priv->perf.oa.exclusive_stream)
+ return 0;
+
+ n_registers = dev_priv->perf.oa.total_n_mux_regs;
+ n_load = (n_registers / max_loads) +
+(n_registers % max_loads) == 0;
+
+ cs = intel_ring_begin(req,
+ 3 * 2 + /* MI_LOAD_REGISTER_IMM for chicken
registers */
+ n_load + /* MI_LOAD_REGISTER_IMM for mux
registers */
+ n_registers * 2 + /* offset & value for mux
registers*/
+ 1 /* NOOP */);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ *cs++ = MI_LOAD_REGISTER_IMM(1);
+ *cs++ = i915_mmio_reg_offset(GDT_CHICKEN_BITS);
+ *cs++ = 0xA0;
+
+ n_loaded_register = 0;
+ for (i = 0; i < dev_priv->perf.oa.n_mux_configs; i++) {
+ const struct i915_oa_reg *mux_regs =
+ dev_priv->perf.oa.mux_regs[i];
+ const int mux_regs_len = dev_priv->perf.oa.mux_regs_lens[i];
+
+ for (j = 0; j < mux_regs_len; j++) {
+ if ((n_loaded_register % max_loads) == 0) {
+ n_load = min(n_registers - n_loaded_register,
max_loads);
+ *cs++ = MI_LOAD_REGISTER_IMM(n_load);
+ }
+
+ *cs++ = i915_mmio_reg_offset(mux_regs[j].addr);
+ *cs++ = mux_regs[j].value;
+ n_loaded_register++;
+ }
+ }
+
+ *cs++ = MI_LOAD_REGISTER_IMM(1);
+ *cs++ = i915_mmio_reg_offset(GDT_CHICKEN_BITS);
+ *cs++ = 0x80;
+
+ *cs++ = MI_NOOP;
+ intel_ring_advance(req, cs);
+
+
[Intel-gfx] [PATCH v15 14/14] drm/i915/perf: notify sseu configuration changes
This adds the ability for userspace to request that the kernel track &
record sseu configuration changes. These changes are inserted into the
perf stream so that userspace can interpret the OA reports using the
configuration applied at the time the OA reports where generated.
v2: Handle timestamps wrapping around 32bits (Lionel)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 45
drivers/gpu/drm/i915/i915_gem_context.c | 3 +
drivers/gpu/drm/i915/i915_gem_context.h | 21 ++
drivers/gpu/drm/i915/i915_perf.c| 459 ++--
drivers/gpu/drm/i915/intel_lrc.c| 7 +-
include/uapi/drm/i915_drm.h | 30 +++
6 files changed, 538 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 499b2f9aa4be..b2e4df1efb12 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1963,6 +1963,12 @@ struct i915_perf_stream {
struct i915_gem_context *ctx;
/**
+* @has_sseu: Whether the stream emits SSEU configuration changes
+* reports.
+*/
+ bool has_sseu;
+
+ /**
* @enabled: Whether the stream is currently enabled, considering
* whether the stream was opened in a disabled state and based
* on `I915_PERF_IOCTL_ENABLE` and `I915_PERF_IOCTL_DISABLE` calls.
@@ -2493,6 +2499,44 @@ struct drm_i915_private {
const struct i915_oa_format *oa_formats;
int n_builtin_sets;
} oa;
+
+ struct {
+ /**
+* Buffer containing change reports of the SSEU
+* configuration.
+*/
+ struct i915_vma *vma;
+ u8 *vaddr;
+
+ /**
+* Scheduler write to the head, and the perf driver
+* reads from tail.
+*/
+ u32 head;
+ u32 tail;
+
+ /**
+* Is the sseu buffer enabled.
+*/
+ bool enabled;
+
+ /**
+* Whether the buffer overflown.
+*/
+ bool overflow;
+
+ /**
+* Keeps track of how many times the OA unit has been
+* enabled. This number is used to discard stale
+* @perf_sseu in @i915_gem_context.
+*/
+ atomic64_t enable_no;
+
+ /**
+* Lock writes & tail pointer updates on this buffer.
+*/
+ spinlock_t ptr_lock;
+ } sseu_buffer;
} perf;
/* Abstract the submission mechanism (legacy ringbuffer or execlists)
away */
@@ -3537,6 +3581,7 @@ void i915_oa_init_reg_state(struct intel_engine_cs
*engine,
struct i915_gem_context *ctx,
uint32_t *reg_state);
int i915_oa_emit_noa_config_locked(struct drm_i915_gem_request *req);
+void i915_perf_emit_sseu_config(struct drm_i915_gem_request *req);
/* i915_gem_evict.c */
int __must_check i915_gem_evict_something(struct i915_address_space *vm,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 60d0bbf0ae2b..368bb527a75a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -510,6 +510,9 @@ mi_set_context(struct drm_i915_gem_request *req, u32 flags)
if (IS_ERR(cs))
return PTR_ERR(cs);
+ /* Notify perf of possible change in SSEU configuration. */
+ i915_perf_emit_sseu_config(req);
+
/* WaProgramMiArbOnOffAroundMiSetContext:ivb,vlv,hsw,bdw,chv */
if (INTEL_GEN(dev_priv) >= 7) {
*cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index e8247e2f6011..9c005be4933a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -194,6 +194,27 @@ struct i915_gem_context {
/** remap_slice: Bitmask of cache lines that need remapping */
u8 remap_slice;
+
+ /**
+* @oa_sseu: last SSEU configuration notified to userspace
+*
+* SSEU configuration changes are notified to userspace through the
+* perf infrastructure. We keep track here of the last notified
+* configuration for a given context since configuration can change
+* per engine.
+*/
+ struct sseu_dev_info perf_sseu;
+
+ /**
+* @perf_enable_no: last perf enable identifier
+*
+* Userspa
[Intel-gfx] [PATCH v15 08/14] drm/i915/perf: per-gen timebase for checking sample freq
From: Robert Bragg
An oa_exponent_to_ns() utility and per-gen timebase constants where
recently removed when updating the tail pointer race condition WA, and
this restores those so we can update the _PROP_OA_EXPONENT validation
done in read_properties_unlocked() to not assume we have a 12.5MHz
timebase as we did for Haswell.
Accordingly the oa_sample_rate_hard_limit value that's referenced by
proc_dointvec_minmax defining the absolute limit for the OA sampling
frequency is now initialized to (timestamp_frequency / 2) instead of the
6.25MHz constant for Haswell.
v2:
Specify frequency of 19.2MHz for BXT (Ville)
Initialize oa_sample_rate_hard_limit per-gen too (Lionel)
Signed-off-by: Robert Bragg
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_perf.c | 39 ---
2 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 45c86b2ec968..4446d42ef0ab 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2395,6 +2395,7 @@ struct drm_i915_private {
bool periodic;
int period_exponent;
+ int timestamp_frequency;
int metrics_set;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 9f524a0ec727..4fab9974b1b8 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -288,10 +288,12 @@ static u32 i915_perf_stream_paranoid = true;
/* For sysctl proc_dointvec_minmax of i915_oa_max_sample_rate
*
- * 160ns is the smallest sampling period we can theoretically program the OA
- * unit with on Haswell, corresponding to 6.25MHz.
+ * The highest sampling frequency we can theoretically program the OA unit
+ * with is always half the timestamp frequency: E.g. 6.25Mhz for Haswell.
+ *
+ * Initialized just before we register the sysctl parameter.
*/
-static int oa_sample_rate_hard_limit = 625;
+static int oa_sample_rate_hard_limit;
/* Theoretically we can program the OA unit to sample every 160ns but don't
* allow that by default unless root...
@@ -2613,6 +2615,12 @@ i915_perf_open_ioctl_locked(struct drm_i915_private
*dev_priv,
return ret;
}
+static u64 oa_exponent_to_ns(struct drm_i915_private *dev_priv, int exponent)
+{
+ return div_u64(10ULL * (2ULL << exponent),
+ dev_priv->perf.oa.timestamp_frequency);
+}
+
/**
* read_properties_unlocked - validate + copy userspace stream open properties
* @dev_priv: i915 device instance
@@ -2709,16 +2717,13 @@ static int read_properties_unlocked(struct
drm_i915_private *dev_priv,
}
/* Theoretically we can program the OA unit to sample
-* every 160ns but don't allow that by default unless
-* root.
-*
-* On Haswell the period is derived from the exponent
-* as:
-*
-* period = 80ns * 2^(exponent + 1)
+* e.g. every 160ns for HSW, 167ns for BDW/SKL or 104ns
+* for BXT. We don't allow such high sampling
+* frequencies by default unless root.
*/
+
BUILD_BUG_ON(sizeof(oa_period) != 8);
- oa_period = 80ull * (2ull << value);
+ oa_period = oa_exponent_to_ns(dev_priv, value);
/* This check is primarily to ensure that oa_period <=
* UINT32_MAX (before passing to do_div which only
@@ -2974,6 +2979,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.ops.oa_hw_tail_read =
gen7_oa_hw_tail_read;
+ dev_priv->perf.oa.timestamp_frequency = 1250;
+
dev_priv->perf.oa.oa_formats = hsw_oa_formats;
dev_priv->perf.oa.n_builtin_sets =
@@ -2989,6 +2996,9 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
if (IS_GEN8(dev_priv)) {
dev_priv->perf.oa.ctx_oactxctrl_offset = 0x120;
dev_priv->perf.oa.ctx_flexeu0_offset = 0x2ce;
+
+ dev_priv->perf.oa.timestamp_frequency = 1250;
+
dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<25);
if (IS_BROADWELL(dev_priv)) {
@@ -3005,6 +3015,9 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
} else if (IS_GEN9(dev_priv)) {
dev_priv->perf.oa.ctx_oactxctrl_offset = 0x128;
dev_priv->perf.oa.ctx_flexeu0_offset = 0x3de;
+
+ dev_priv->perf.oa.timestamp_
[Intel-gfx] [PATCH v15 09/14] drm/i915/perf: remove perf.hook_lock
From: Robert Bragg
In earlier iterations of the i915-perf driver we had a number of
callbacks/hooks from other parts of the i915 driver to e.g. notify us
when a legacy context was pinned and these could run asynchronously with
respect to the stream file operations and might also run in atomic
context.
dev_priv->perf.hook_lock had been for serialising access to state needed
within these callbacks, but as the code has evolved some of the hooks
have gone away or are implemented to avoid needing to lock any state.
The remaining use of this lock was actually redundant considering how
the gen7 oacontrol state used to be updated as part of a context pin
hook.
Signed-off-by: Robert Bragg
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/i915_perf.c | 32 ++--
2 files changed, 10 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4446d42ef0ab..20e9bb14aab4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2376,8 +2376,6 @@ struct drm_i915_private {
struct mutex lock;
struct list_head streams;
- spinlock_t hook_lock;
-
struct {
struct i915_perf_stream *exclusive_stream;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 4fab9974b1b8..9e5307bbaab1 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1810,9 +1810,17 @@ static void gen8_disable_metric_set(struct
drm_i915_private *dev_priv)
gen8_configure_all_contexts(dev_priv, false);
}
-static void gen7_update_oacontrol_locked(struct drm_i915_private *dev_priv)
+static void gen7_oa_enable(struct drm_i915_private *dev_priv)
{
- lockdep_assert_held(&dev_priv->perf.hook_lock);
+ /* Reset buf pointers so we don't forward reports from before now.
+*
+* Think carefully if considering trying to avoid this, since it
+* also ensures status flags and the buffer itself are cleared
+* in error paths, and we have checks for invalid reports based
+* on the assumption that certain fields are written to zeroed
+* memory which this helps maintains.
+*/
+ gen7_init_oa_buffer(dev_priv);
if (dev_priv->perf.oa.exclusive_stream->enabled) {
struct i915_gem_context *ctx =
@@ -1835,25 +1843,6 @@ static void gen7_update_oacontrol_locked(struct
drm_i915_private *dev_priv)
I915_WRITE(GEN7_OACONTROL, 0);
}
-static void gen7_oa_enable(struct drm_i915_private *dev_priv)
-{
- unsigned long flags;
-
- /* Reset buf pointers so we don't forward reports from before now.
-*
-* Think carefully if considering trying to avoid this, since it
-* also ensures status flags and the buffer itself are cleared
-* in error paths, and we have checks for invalid reports based
-* on the assumption that certain fields are written to zeroed
-* memory which this helps maintains.
-*/
- gen7_init_oa_buffer(dev_priv);
-
- spin_lock_irqsave(&dev_priv->perf.hook_lock, flags);
- gen7_update_oacontrol_locked(dev_priv);
- spin_unlock_irqrestore(&dev_priv->perf.hook_lock, flags);
-}
-
static void gen8_oa_enable(struct drm_i915_private *dev_priv)
{
u32 report_format = dev_priv->perf.oa.oa_buffer.format;
@@ -3069,7 +3058,6 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
INIT_LIST_HEAD(&dev_priv->perf.streams);
mutex_init(&dev_priv->perf.lock);
- spin_lock_init(&dev_priv->perf.hook_lock);
spin_lock_init(&dev_priv->perf.oa.oa_buffer.ptr_lock);
oa_sample_rate_hard_limit =
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v15 10/14] drm/i915: add KBL GT2/GT3 check macros
Add macros to detect GT2/GT3 skus so we can apply the proper OA configuration later. Signed-off-by: Lionel Landwerlin Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_drv.h | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 20e9bb14aab4..c3acb0e9eb5d 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2803,6 +2803,10 @@ intel_info(const struct drm_i915_private *dev_priv) (INTEL_DEVID(dev_priv) & 0x00F0) == 0x0020) #define IS_SKL_GT4(dev_priv) (IS_SKYLAKE(dev_priv) && \ (INTEL_DEVID(dev_priv) & 0x00F0) == 0x0030) +#define IS_KBL_GT2(dev_priv) (IS_KABYLAKE(dev_priv) && \ +(INTEL_DEVID(dev_priv) & 0x00F0) == 0x0010) +#define IS_KBL_GT3(dev_priv) (IS_KABYLAKE(dev_priv) && \ +(INTEL_DEVID(dev_priv) & 0x00F0) == 0x0020) #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/11] drm/edid: Complete CEA modedb(VIC 1-107)
On Tue, May 30, 2017 at 09:56:56PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 5/30/2017 9:48 PM, Ville Syrjälä wrote:
> > On Tue, May 30, 2017 at 05:43:41PM +0530, Shashank Sharma wrote:
> >> CEA-861-F specs defines new video modes to be used with
> >> HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
> >> 1-107.
> >>
> >> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> >> to be able to parse new CEA modes using the existing methods, we have
> >> to complete the modedb (VIC=65 onwards).
> >>
> >> This patch adds:
> >> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> >> - Newly added 4k modes (from VIC=93 to VIC=107).
> > Still missing the "native bit" handling.
> I tried searching the native bit handling in the code, but I could not
> get any thing. We are typically doing a (vic & 127) and that's all.
And that's not really correct. We shouldn't discard the msb until we've
checked that we're in the correct range of VICs that have the native
bit. drm_display_mode_from_vic_index() is the place where we should be
checking this I think.
> Can you please point out a bit here ?
>
> - Shashank
> >> The patch was originaly discussed and reviewed here:
> >> https://patchwork.freedesktop.org/patch/135810/
> >>
> >> Cc: Ville Syrjala
> >> Cc: Jose Abreu
> >> Cc: Andrzej Hajda
> >> Cc: Alex Deucher
> >> Cc: Harry Wentland
> >>
> >> V2: Rebase
> >>
> >> Reviewed-by: Jose Abreu
> >> Reviewed-by: Alex Deucher
> >> Acked-by: Harry Wentland
> >> Signed-off-by: Shashank Sharma
> >> ---
> >> drivers/gpu/drm/drm_edid.c | 215
> >> +
> >> 1 file changed, 215 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 8b23435..c3fa3a1 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -1006,6 +1006,221 @@ static const struct drm_display_mode
> >> edid_cea_modes[] = {
> >> 2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> >> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> >> + /* 65 - 1280x720@24Hz */
> >> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> >> + 3080, 3300, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> + /* 66 - 1280x720@25Hz */
> >> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> >> + 3740, 3960, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> + /* 67 - 1280x720@30Hz */
> >> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
> >> + 3080, 3300, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> + /* 68 - 1280x720@50Hz */
> >> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
> >> + 1760, 1980, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> + /* 69 - 1280x720@60Hz */
> >> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> >> + 1430, 1650, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> + /* 70 - 1280x720@100Hz */
> >> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
> >> + 1760, 1980, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> + /* 71 - 1280x720@120Hz */
> >> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
> >> + 1430, 1650, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> + /* 72 - 1920x1080@24Hz */
> >> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
> >> + 2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> + /* 73 - 1920x1080@25Hz */
> >> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
> >> + 2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> + /* 74 -
Re: [Intel-gfx] [PATCH v2 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames
On Tue, May 30, 2017 at 10:00:12PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 5/30/2017 9:43 PM, Ville Syrjälä wrote:
> > On Tue, May 30, 2017 at 05:43:40PM +0530, Shashank Sharma wrote:
> >> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> >> For any other mode, the VIC filed in AVI infoframes should be 0.
> >> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> >> extended to (VIC 1-107).
> >>
> >> This patch adds a bool input variable, which indicates if the connected
> >> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
> >> HDMI 2.0 VIC to a HDMI 1.4 sink.
> >>
> >> This patch touches all drm drivers, who are callers of this function
> >> drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
> >> no change in current behavior, is_hdmi2 is kept as false.
> >>
> >> In case of I915 driver, this patch checks the connector->display_info
> >> to check if the connected display is HDMI 2.0.
> >>
> >> Cc: Ville Syrjala
> >> Cc: Jose Abreu
> >> Cc: Andrzej Hajda
> >> Cc: Alex Deucher
> >> Cc: Daniel Vetter
> >>
> >> PS: This patch touches a few lines in few files, which were
> >> already above 80 char, so checkpatch gives 80 char warning again.
> >> - gpu/drm/omapdrm/omap_encoder.c
> >> - gpu/drm/i915/intel_sdvo.c
> >>
> >> V2: Rebase, Added r-b from Andrzej
> >>
> >> Reviewed-by: Andrzej Hajda
> >> Signed-off-by: Shashank Sharma
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +-
> >> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +-
> >> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
> >> drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++-
> >> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> >> drivers/gpu/drm/drm_edid.c| 12 +++-
> >> drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
> >> drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
> >> drivers/gpu/drm/i915/intel_hdmi.c | 5 -
> >> drivers/gpu/drm/i915/intel_sdvo.c | 3 ++-
> >> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> >> drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++-
> >> drivers/gpu/drm/radeon/radeon_audio.c | 2 +-
> >> drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
> >> drivers/gpu/drm/sti/sti_hdmi.c| 2 +-
> >> drivers/gpu/drm/tegra/hdmi.c | 2 +-
> >> drivers/gpu/drm/tegra/sor.c | 2 +-
> >> drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +-
> >> drivers/gpu/drm/zte/zx_hdmi.c | 2 +-
> >> include/drm/drm_edid.h| 3 ++-
> >> 21 files changed, 38 insertions(+), 21 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> >> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> >> index 3c62c45..4923ddc 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> >> @@ -1864,7 +1864,7 @@ static void dce_v10_0_afmt_setmode(struct
> >> drm_encoder *encoder,
> >>dce_v10_0_audio_write_sad_regs(encoder);
> >>dce_v10_0_audio_write_latency_fields(encoder, mode);
> >>
> >> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> >> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> >>if (err < 0) {
> >>DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> >>return;
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> >> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> >> index c8ed0fa..4101684 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> >> @@ -1848,7 +1848,7 @@ static void dce_v11_0_afmt_setmode(struct
> >> drm_encoder *encoder,
> >>dce_v11_0_audio_write_sad_regs(encoder);
> >>dce_v11_0_audio_write_latency_fields(encoder, mode);
> >>
> >> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> >> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> >>if (err < 0) {
> >>DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> >>return;
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> >> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> >> index 3e90c19..a7f6b32 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> >> @@ -1747,7 +1747,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder
> >> *encoder,
> >>dce_v8_0_audio_write_sad_regs(encoder);
> >>dce_v8_0_audio_write_latency_fields(encoder, mode);
> >>
> >> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> >> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> >>if (err < 0) {
> >>DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> >>return;
> >> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> >> b/drivers/gpu/drm/bridge/a
Re: [Intel-gfx] [PATCH igt] lib/kms: Force a full reprobe if we find a bad link
On Wed, May 31, 2017 at 01:40:00PM +0300, Martin Peres wrote: > On 26/05/17 14:48, Chris Wilson wrote: > >If we do a shallow probe of the connector and it reports the link failed > >previous (link-status != GOOD), force a full probe of the connector to > >give the kernel a chance to validate the mode list. > > Sounds good, but will this make the tests SKIP if no modes are available? I'm actually not sure what will happen if the mode is removed. I think the tests are just using the first mode in the list? At the moment I hope just to stop turning a single failure into many, it is still a bug that the link training failed and was not recovered. Alternatively, we can ask why isn't the kernel taking the corrective action when presented with a new setcrtc? I'm not sure what the correct approach here should be, just what is the contract the kernel is expecting of userspace? Should that contract apply to new clients unaware of the earlier error? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] igt/gem_fence_upload: Stabilise the test for CI
On Wed, May 31, 2017 at 11:28:07AM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Most of the subtest were failing on my SKL GT2 and on the > various CI systems as well. Try to fix that by different > tweaks per subtests: > > performance: > > We cannot say how big the performance drop will be once the > fences are contented, just that there will be one, so modify > the assert accordingly. No. The goal is that the contention is not noticeable. Asserting that contention is inevitable is baking in a kernel bug instead of fixing the kernel. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 05/11] drm: create hdmi output property
On Tue, May 30, 2017 at 10:18:19PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 5/30/2017 10:06 PM, Ville Syrjälä wrote:
> > On Tue, May 30, 2017 at 05:43:44PM +0530, Shashank Sharma wrote:
> >> HDMI displays can support various output types, based on
> >> the color space and subsampling type. The possible
> >> outputs from a HDMI 2.0 monitor could be:
> >> - RGB
> >> - YCBCR 444
> >> - YCBCR 422
> >> - YCBCR 420
> >>
> >> This patch adds a drm property, using which, a userspace
> > I think we should add the 4:2:0 only mode support first since that
> > doesn't require new uapi. The uapi stuff probably needs more careful
> > thought as we might want to consider exposing more of the
> > colorimetry stuff supported by the HDMI infoframes, and DP MSA MISC
> > and VSC SDP.
> I was coming from the opposite school of thought. I was thinking
> 420_only modes should
> be handled carefully, whereas 420_also doesnt need any uapi (This patch
> series contains
> 420_also and doesnt modify the UAPI) due to following reasons:
>
> assume there is a mode 3840x2160@60 appears to be in 2 different EDIDs,
> in first EDID as a 420_only mode
> and in other as 420_also mode.
> - If we add a 420_also mode in the mode_list, userspace might pick it
> for the modeset as favorite, as most of the
> 420 modes are 4k modes.
> - Now, if userspace doesn't set the hdmi_output property to YCBCR420,
> and sends a modeset on this mode:
> - the modeset will be successful in case of a 420_also mode, as it
> can be supported in RGB/YUV444 also.
> - the modeset will fail in case of 420_only mode, as this mode
> cant be supported in any other hdmi output format.
>
> In this case, addition of 420_only mode, in the connectors->modes list
> should be done, only when the driver is ready to
> handle the YCBCR420 output, or we have to inform userspace about these
> modes which need the hdmi_ouput property to
> be set with the modeset, which might in turn need an uabi.
>
> Does it make a case ?
What I think we want is to automagically enable 4:2:0 output if
userspace picks a 4:2:0 only mode, regardless of the property value.
And in fact this way we don't even need the property to enable the
use of 4:2:0 only modes. Which is great because it means current
userspace can start to use those modes without any code changes.
> - Shashank
> >> can specify its preference, for the HDMI output type.
> >> The output type enums are similar to the mentioned outputs
> >> above. To handle various subsampling of YCBCR output types,
> >> this property allows two special cases:
> >> - DRM_HDMI_OUTPUT_YCBCR_HQ
> >> This indicates preferred output should be YCBCR output, with highest
> >> subsampling rate by the source/sink, which can be typically:
> >> - ycbcr444
> >> - ycbcr422
> >> - ycbcr420
> >> - DRM_HDMI_OUTPUT_YCBCR_LQ
> >> This indicates preferred output should be YCBCR output, with lowest
> >> subsampling rate supported by source/sink, which can be:
> >> - ycbcr420
> >> - ycbcr422
> >> - ycbcr444
> >>
> >> Default value of the property is set to 0 = RGB, so no changes if you
> >> dont set the property.
> >>
> >> V2: Added description for the new variable to address build warning
> >>
> >> Cc: Ville Syrjala
> >> Cc: Jose Abreu
> >> Cc: Daniel Vetter
> >> Signed-off-by: Shashank Sharma
> >> ---
> >> drivers/gpu/drm/drm_atomic.c| 2 ++
> >> drivers/gpu/drm/drm_atomic_helper.c | 4
> >> drivers/gpu/drm/drm_connector.c | 32
> >> include/drm/drm_connector.h | 18 ++
> >> include/drm/drm_mode_config.h | 5 +
> >> 5 files changed, 61 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >> index e163701..8c4e040 100644
> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> @@ -1192,6 +1192,8 @@ int drm_atomic_connector_set_property(struct
> >> drm_connector *connector,
> >>state->picture_aspect_ratio = val;
> >>} else if (property == connector->scaling_mode_property) {
> >>state->scaling_mode = val;
> >> + } else if (property == config->hdmi_output_property) {
> >> + state->hdmi_output = val;
> >>} else if (connector->funcs->atomic_set_property) {
> >>return connector->funcs->atomic_set_property(connector,
> >>state, property, val);
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index 636e561..86b1780 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -567,6 +567,10 @@ drm_atomic_helper_check_modeset(struct drm_device
> >> *dev,
> >>if (old_connector_state->link_status !=
> >>new_connector_state->link_status)
> >>new_crtc_state->connectors_changed = true;
> >> +
> >
Re: [Intel-gfx] [RFC i-g-t] GEM features into feat_profile.json
On Wed, May 31, 2017 at 03:23:12PM +0300, Joonas Lahtinen wrote: > Hello, > > I went through the gem_* tests from intel-gpu-tools and categorized > them into roughly categories "X | X robustness | X performance" ready > to be added to the feat_profile.json. > > Lets open a discussion which ones should go where. I tried to place a > single test to under only one category and I'm kind of hopeful that > we'll have the ability to add "depends_on" to create super features in > the future, instead of placing a single test under multiple categories. > > I didn't check all the subtests nor wildcard matching with other tests, > this is just all the test names placed under some categories. You seem to have assigned them exclusively to one category or another, most tests belong to a few of these categories. More when you consider a subtest may be targetting a completely different aspect. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 05/11] drm: create hdmi output property
Regards
Shashank
On 5/31/2017 6:16 PM, Ville Syrjälä wrote:
On Tue, May 30, 2017 at 10:18:19PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 5/30/2017 10:06 PM, Ville Syrjälä wrote:
On Tue, May 30, 2017 at 05:43:44PM +0530, Shashank Sharma wrote:
HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
- RGB
- YCBCR 444
- YCBCR 422
- YCBCR 420
This patch adds a drm property, using which, a userspace
I think we should add the 4:2:0 only mode support first since that
doesn't require new uapi. The uapi stuff probably needs more careful
thought as we might want to consider exposing more of the
colorimetry stuff supported by the HDMI infoframes, and DP MSA MISC
and VSC SDP.
I was coming from the opposite school of thought. I was thinking
420_only modes should
be handled carefully, whereas 420_also doesnt need any uapi (This patch
series contains
420_also and doesnt modify the UAPI) due to following reasons:
assume there is a mode 3840x2160@60 appears to be in 2 different EDIDs,
in first EDID as a 420_only mode
and in other as 420_also mode.
- If we add a 420_also mode in the mode_list, userspace might pick it
for the modeset as favorite, as most of the
420 modes are 4k modes.
- Now, if userspace doesn't set the hdmi_output property to YCBCR420,
and sends a modeset on this mode:
- the modeset will be successful in case of a 420_also mode, as it
can be supported in RGB/YUV444 also.
- the modeset will fail in case of 420_only mode, as this mode
cant be supported in any other hdmi output format.
In this case, addition of 420_only mode, in the connectors->modes list
should be done, only when the driver is ready to
handle the YCBCR420 output, or we have to inform userspace about these
modes which need the hdmi_ouput property to
be set with the modeset, which might in turn need an uabi.
Does it make a case ?
What I think we want is to automagically enable 4:2:0 output if
userspace picks a 4:2:0 only mode, regardless of the property value.
And in fact this way we don't even need the property to enable the
use of 4:2:0 only modes. Which is great because it means current
userspace can start to use those modes without any code changes.
I was worried about this sitution:
- There is one 420_only mode (38x21@60) in EDID
- We added a 420_only mode in the list, which userspace can see (but
cant differentiate between non-420 or 420 mode)
- Userspace triggers a modeset on this, but the driver doesn't support
YCBCR420 output yet, as source doesn't support it yet.
In this case, we will cause modeset failure for each driver which doesnt
support HDMI 2.0.
So if we have to make a 420_only mode visible to userspace, we have to
indicate somehow that its 420_only mode.
Do you think so ?
- Shashank
- Shashank
can specify its preference, for the HDMI output type.
The output type enums are similar to the mentioned outputs
above. To handle various subsampling of YCBCR output types,
this property allows two special cases:
- DRM_HDMI_OUTPUT_YCBCR_HQ
This indicates preferred output should be YCBCR output, with highest
subsampling rate by the source/sink, which can be typically:
- ycbcr444
- ycbcr422
- ycbcr420
- DRM_HDMI_OUTPUT_YCBCR_LQ
This indicates preferred output should be YCBCR output, with lowest
subsampling rate supported by source/sink, which can be:
- ycbcr420
- ycbcr422
- ycbcr444
Default value of the property is set to 0 = RGB, so no changes if you
dont set the property.
V2: Added description for the new variable to address build warning
Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Daniel Vetter
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic.c| 2 ++
drivers/gpu/drm/drm_atomic_helper.c | 4
drivers/gpu/drm/drm_connector.c | 32
include/drm/drm_connector.h | 18 ++
include/drm/drm_mode_config.h | 5 +
5 files changed, 61 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index e163701..8c4e040 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1192,6 +1192,8 @@ int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
+ } else if (property == config->hdmi_output_property) {
+ state->hdmi_output = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 636e561..86b1780 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -
Re: [Intel-gfx] [PATCH i-g-t] igt/gem_fence_upload: Stabilise the test for CI
On 31/05/2017 13:45, Chris Wilson wrote: On Wed, May 31, 2017 at 11:28:07AM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Most of the subtest were failing on my SKL GT2 and on the various CI systems as well. Try to fix that by different tweaks per subtests: performance: We cannot say how big the performance drop will be once the fences are contented, just that there will be one, so modify the assert accordingly. No. The goal is that the contention is not noticeable. Asserting that contention is inevitable is baking in a kernel bug instead of fixing the kernel. Bug in the case of this specific subtest? I see now that it is different that the others in a way that it goes through objects cyclically so maybe really shouldn't be so hardly impacted by the oversubscribe of fences. Need to look into what's happening there. But what about the other subtests? Comments on those? Threaded one certainly cannot be shielded from the oversubscription. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] lib/kms: Force a full reprobe if we find a bad link
On 31/05/17 15:42, Chris Wilson wrote: On Wed, May 31, 2017 at 01:40:00PM +0300, Martin Peres wrote: On 26/05/17 14:48, Chris Wilson wrote: If we do a shallow probe of the connector and it reports the link failed previous (link-status != GOOD), force a full probe of the connector to give the kernel a chance to validate the mode list. Sounds good, but will this make the tests SKIP if no modes are available? I'm actually not sure what will happen if the mode is removed. I think the tests are just using the first mode in the list? At the moment I hope just to stop turning a single failure into many, it is still a bug that the link training failed and was not recovered. Alternatively, we can ask why isn't the kernel taking the corrective action when presented with a new setcrtc? No, this is not a kernel bug, it is a failure that the userspace has to handle because the kernel can't do shit about this. I'm not sure what the correct approach here should be, just what is the contract the kernel is expecting of userspace? Should that contract apply to new clients unaware of the earlier error? Right, IGT assumes that if a mode is already set, it can be set again. However, this assumption has been broken when the link-status patches landed. On a hotplug event, IGT should do a full reprobe, select one mode from the list and use it. If no modes can be set and the test is trying to set one, then the test should just SKIP. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC i-g-t] GEM features into feat_profile.json
On ke, 2017-05-31 at 13:58 +0100, Chris Wilson wrote: > On Wed, May 31, 2017 at 03:23:12PM +0300, Joonas Lahtinen wrote: > > > > Hello, > > > > I went through the gem_* tests from intel-gpu-tools and categorized > > them into roughly categories "X | X robustness | X performance" ready > > to be added to the feat_profile.json. > > > > Lets open a discussion which ones should go where. I tried to place a > > single test to under only one category and I'm kind of hopeful that > > we'll have the ability to add "depends_on" to create super features in > > the future, instead of placing a single test under multiple categories. > > > > I didn't check all the subtests nor wildcard matching with other tests, > > this is just all the test names placed under some categories. > > You seem to have assigned them exclusively to one category or another, > most tests belong to a few of these categories. More when you consider a > subtest may be targetting a completely different aspect. Yes, that's what I meant to say :) Subtests should probably be matched by another pattern like "\btiled\b", "\bflink\b" etc. Ultimately there would be a resolver which would re-assign the subtests: "Global objects" would then get: "include_subtests": "flink", Which would steal subtests with /\bflink\b/ from tests. Do we agree that one subtest would be assigned to one category only, or do you want to see duplication even at that level? Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ 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: Short-circuit i915_gem_wait_for_idle() if already idle
Chris Wilson writes:
> If the device is asleep (no GT wakeref), we know the GPU is already idle.
> If we add an early return, we can avoid touching registers and checking
> hw state outside of the assumed GT wakelock. This prevents causing such
> errors whilst debugging:
>
> [ 2613.401647] RPM wakelock ref not held during HW access
> [ 2613.401684] [ cut here ]
> [ 2613.401720] WARNING: CPU: 5 PID: 7739 at
> drivers/gpu/drm/i915/intel_drv.h:1787 gen6_read32+0x21f/0x2b0 [i915]
> [ 2613.401731] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi
> x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek coretemp
> snd_hda_codec_generic crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
> snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mii mei_me lpc_ich mei
> prime_numbers [last unloaded: i915]
> [ 2613.401823] CPU: 5 PID: 7739 Comm: drv_missed_irq Tainted: G U
> 4.12.0-rc2-CI-CI_DRM_421+ #1
> [ 2613.401825] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12
> 02/15/2016
> [ 2613.401840] task: 880409e3a740 task.stack: c900084dc000
> [ 2613.401861] RIP: 0010:gen6_read32+0x21f/0x2b0 [i915]
> [ 2613.401863] RSP: 0018:c900084dfce8 EFLAGS: 00010292
> [ 2613.401869] RAX: 002a RBX: 8804016a8000 RCX:
> 0006
> [ 2613.401871] RDX: 0006 RSI: 81cbf2d9 RDI:
> 81c9e3a7
> [ 2613.401874] RBP: c900084dfd18 R08: 880409e3afc8 R09:
>
> [ 2613.401877] R10: 8a1c483f R11: R12:
> 209c
> [ 2613.401879] R13: 0001 R14: 8804016a8000 R15:
> 8804016ac150
> [ 2613.401882] FS: 7f39ef3dd8c0() GS:88041fb4()
> knlGS:
> [ 2613.401885] CS: 0010 DS: ES: CR0: 80050033
> [ 2613.401887] CR2: 023717c8 CR3: 0002e7b34000 CR4:
> 001406e0
> [ 2613.401889] Call Trace:
> [ 2613.401912] intel_engine_is_idle+0x76/0x90 [i915]
> [ 2613.401931] i915_gem_wait_for_idle+0xe6/0x1e0 [i915]
> [ 2613.401951] fault_irq_set+0x40/0x90 [i915]
> [ 2613.401970] i915_ring_test_irq_set+0x42/0x50 [i915]
> [ 2613.401976] simple_attr_write+0xc7/0xe0
> [ 2613.401981] full_proxy_write+0x4f/0x70
> [ 2613.401987] __vfs_write+0x23/0x120
> [ 2613.401992] ? rcu_read_lock_sched_held+0x75/0x80
> [ 2613.401996] ? rcu_sync_lockdep_assert+0x2a/0x50
> [ 2613.401999] ? __sb_start_write+0xfa/0x1f0
> [ 2613.402004] vfs_write+0xc5/0x1d0
> [ 2613.402008] ? trace_hardirqs_on_caller+0xe7/0x1c0
> [ 2613.402013] SyS_write+0x44/0xb0
> [ 2613.402020] entry_SYSCALL_64_fastpath+0x1c/0xb1
> [ 2613.402022] RIP: 0033:0x7f39eded6670
> [ 2613.402025] RSP: 002b:7fffdcdcb1a8 EFLAGS: 0246 ORIG_RAX:
> 0001
> [ 2613.402030] RAX: ffda RBX: 81470203 RCX:
> 7f39eded6670
> [ 2613.402033] RDX: 0001 RSI: 0041bc33 RDI:
> 0006
> [ 2613.402036] RBP: c900084dff88 R08: 7f39ef3dd8c0 R09:
> 0001
> [ 2613.402038] R10: R11: 0246 R12:
> 0041bc33
> [ 2613.402041] R13: 0006 R14: R15:
>
> [ 2613.402046] ? __this_cpu_preempt_check+0x13/0x20
> [ 2613.402052] Code: 01 9b fa e0 0f ff e9 28 fe ff ff 80 3d 6a dd 0e 00 00 0f
> 85 29 fe ff ff 48 c7 c7 48 19 29 a0 c6 05 56 dd 0e 00 01 e8 da 9a fa e0 <0f>
> ff e9 0f fe ff ff b9 01 00 00 00 ba 01 00 00 00 44 89 e6 48
> [ 2613.402199] ---[ end trace 31f0cfa93ab632bf ]---
>
> Fixes: Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as
> part of i915_gem_wait_for_idle()")
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Tvrtko Ursulin
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 7ab47a84671f..2ce915a1b607 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3348,6 +3348,10 @@ int i915_gem_wait_for_idle(struct drm_i915_private
> *i915, unsigned int flags)
> {
> int ret;
>
> + /* If the device is asleep, we have no requests outstanding */
> + if (!i915->gt.awake)
> + return 0;
> +
> if (flags & I915_WAIT_LOCKED) {
> struct i915_gem_timeline *tl;
>
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Check the ring is empty when declaring the engines are idle
Chris Wilson writes: > As another precaution when testing whether the CS engine is actually > idle, also inspect the ring's HEAD/TAIL registers, which should be equal > when there are no commands left to execute by the GPU. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > --- > drivers/gpu/drm/i915/intel_engine_cs.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c > b/drivers/gpu/drm/i915/intel_engine_cs.c > index 699f2d3861c7..bc38bd128b76 100644 > --- a/drivers/gpu/drm/i915/intel_engine_cs.c > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c > @@ -1212,6 +1212,11 @@ static bool ring_is_idle(struct intel_engine_cs > *engine) > > intel_runtime_pm_get(dev_priv); > > + /* First check that no commands are left in the ring */ > + if ((I915_READ_HEAD(engine) & HEAD_ADDR) != > + (I915_READ_TAIL(engine) & TAIL_ADDR)) > + idle = false; > + You are already certain that is not idle so why not goto out? -Mika > /* No bit for gen2, so assume the CS parser is idle */ > if (INTEL_GEN(dev_priv) > 2 && !(I915_READ_MODE(engine) & MODE_IDLE)) > idle = false; > -- > 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Hold a wakeref for probing the ring registers
Chris Wilson writes:
> Allow intel_engine_is_idle() to be called outside of the GT wakeref by
> acquiring the device runtime pm for ourselves. This allows the function
> to act as check after we assume the engine is idle and we release the GT
> wakeref held whilst we have requests.
>
> [ 2613.401647] RPM wakelock ref not held during HW access
> [ 2613.401684] [ cut here ]
> [ 2613.401720] WARNING: CPU: 5 PID: 7739 at
> drivers/gpu/drm/i915/intel_drv.h:1787 gen6_read32+0x21f/0x2b0 [i915]
> [ 2613.401731] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi
> x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek coretemp
> snd_hda_codec_generic crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
> snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mii mei_me lpc_ich mei
> prime_numbers [last unloaded: i915]
> [ 2613.401823] CPU: 5 PID: 7739 Comm: drv_missed_irq Tainted: G U
> 4.12.0-rc2-CI-CI_DRM_421+ #1
> [ 2613.401825] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12
> 02/15/2016
> [ 2613.401840] task: 880409e3a740 task.stack: c900084dc000
> [ 2613.401861] RIP: 0010:gen6_read32+0x21f/0x2b0 [i915]
> [ 2613.401863] RSP: 0018:c900084dfce8 EFLAGS: 00010292
> [ 2613.401869] RAX: 002a RBX: 8804016a8000 RCX:
> 0006
> [ 2613.401871] RDX: 0006 RSI: 81cbf2d9 RDI:
> 81c9e3a7
> [ 2613.401874] RBP: c900084dfd18 R08: 880409e3afc8 R09:
>
> [ 2613.401877] R10: 8a1c483f R11: R12:
> 209c
> [ 2613.401879] R13: 0001 R14: 8804016a8000 R15:
> 8804016ac150
> [ 2613.401882] FS: 7f39ef3dd8c0() GS:88041fb4()
> knlGS:
> [ 2613.401885] CS: 0010 DS: ES: CR0: 80050033
> [ 2613.401887] CR2: 023717c8 CR3: 0002e7b34000 CR4:
> 001406e0
> [ 2613.401889] Call Trace:
> [ 2613.401912] intel_engine_is_idle+0x76/0x90 [i915]
> [ 2613.401931] i915_gem_wait_for_idle+0xe6/0x1e0 [i915]
> [ 2613.401951] fault_irq_set+0x40/0x90 [i915]
> [ 2613.401970] i915_ring_test_irq_set+0x42/0x50 [i915]
> [ 2613.401976] simple_attr_write+0xc7/0xe0
> [ 2613.401981] full_proxy_write+0x4f/0x70
> [ 2613.401987] __vfs_write+0x23/0x120
> [ 2613.401992] ? rcu_read_lock_sched_held+0x75/0x80
> [ 2613.401996] ? rcu_sync_lockdep_assert+0x2a/0x50
> [ 2613.401999] ? __sb_start_write+0xfa/0x1f0
> [ 2613.402004] vfs_write+0xc5/0x1d0
> [ 2613.402008] ? trace_hardirqs_on_caller+0xe7/0x1c0
> [ 2613.402013] SyS_write+0x44/0xb0
> [ 2613.402020] entry_SYSCALL_64_fastpath+0x1c/0xb1
> [ 2613.402022] RIP: 0033:0x7f39eded6670
> [ 2613.402025] RSP: 002b:7fffdcdcb1a8 EFLAGS: 0246 ORIG_RAX:
> 0001
> [ 2613.402030] RAX: ffda RBX: 81470203 RCX:
> 7f39eded6670
> [ 2613.402033] RDX: 0001 RSI: 0041bc33 RDI:
> 0006
> [ 2613.402036] RBP: c900084dff88 R08: 7f39ef3dd8c0 R09:
> 0001
> [ 2613.402038] R10: R11: 0246 R12:
> 0041bc33
> [ 2613.402041] R13: 0006 R14: R15:
>
> [ 2613.402046] ? __this_cpu_preempt_check+0x13/0x20
> [ 2613.402052] Code: 01 9b fa e0 0f ff e9 28 fe ff ff 80 3d 6a dd 0e 00 00 0f
> 85 29 fe ff ff 48 c7 c7 48 19 29 a0 c6 05 56 dd 0e 00 01 e8 da 9a fa e0 <0f>
> ff e9 0f fe ff ff b9 01 00 00 00 ba 01 00 00 00 44 89 e6 48
> [ 2613.402199] ---[ end trace 31f0cfa93ab632bf ]---
>
> Fixes: 5400367a864d ("drm/i915: Ensure the engine is idle before manually
> changing HWS")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Joonas Lahtinen
> Cc: Tvrtko Ursulin
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 413bfd8d4bf4..699f2d3861c7 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1205,6 +1205,22 @@ int intel_ring_workarounds_emit(struct
> drm_i915_gem_request *req)
> return 0;
> }
>
> +static bool ring_is_idle(struct intel_engine_cs *engine)
> +{
> + struct drm_i915_private *dev_priv = engine->i915;
> + bool idle = true;
> +
> + intel_runtime_pm_get(dev_priv);
> +
> + /* No bit for gen2, so assume the CS parser is idle */
> + if (INTEL_GEN(dev_priv) > 2 && !(I915_READ_MODE(engine) & MODE_IDLE))
> + idle = false;
> +
> + intel_runtime_pm_put(dev_priv);
> +
> + return idle;
> +}
> +
> /**
> * intel_engine_is_idle() - Report if the engine has finished process all
> work
> * @engine: the intel_engine_cs
> @@ -1237,7 +1253,7 @@ bool intel_engine_is_idle(struct intel_engine_cs
> *engine)
> return false;
>
> /* Ring stopped? */
> - if (INTEL_GEN(de
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_setmode: increase MAX_CRTCS to 6
On 2017-05-31 05:37 AM, Daniel Vetter wrote:
On Tue, May 30, 2017 at 04:01:40PM -0400, Harry Wentland wrote:
AMD GPUs can have 6 CRTCs.
This requires us to allocate the combinations on the heap.
Signed-off-by: Harry Wentland
I think just dynamically allocating stuff directly and dropping the
#define would be even neater ... GetResources can tell us how much of each
exists.
-Daniel
Agreed. I'll send out a v3 later.
Harry
---
tests/kms_setmode.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
index 430568a1c24e..847ad650d27f 100644
--- a/tests/kms_setmode.c
+++ b/tests/kms_setmode.c
@@ -35,11 +35,13 @@
#include "intel_bufmgr.h"
#define MAX_CONNECTORS 10
-#define MAX_CRTCS 3
+#define MAX_CRTCS 6
/* max combinations with repetitions */
+/* MAX_CONNECTORS ^ MAX_CRTCS */
+/* TODO should really be MAX_CONNECTORS ^ MAX_CONNECTORS ??? */
#define MAX_COMBINATION_COUNT \
- (MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS)
+ (MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS * MAX_CONNECTORS *
MAX_CONNECTORS * MAX_CONNECTORS)
#define MAX_COMBINATION_ELEMS MAX_CRTCS
static int drm_fd;
@@ -743,22 +745,25 @@ static void get_combinations(int n, int k, bool
allow_repetitions,
static void test_combinations(const struct test_config *tconf,
int connector_count)
{
- struct combination_set connector_combs;
- struct combination_set crtc_combs;
+ struct combination_set *connector_combs;
+ struct combination_set *crtc_combs;
struct connector_config *cconfs;
int i;
if (connector_count > 2 && (tconf->flags & TEST_STEALING))
return;
+ connector_combs = malloc(sizeof(*connector_combs));
+ crtc_combs = malloc(sizeof(*crtc_combs));
+
get_combinations(tconf->resources->count_connectors, connector_count,
-false, &connector_combs);
+false, connector_combs);
get_combinations(tconf->resources->count_crtcs, connector_count,
-true, &crtc_combs);
+true, crtc_combs);
igt_info("Testing: %s %d connector combinations\n", tconf->name,
connector_count);
- for (i = 0; i < connector_combs.count; i++) {
+ for (i = 0; i < connector_combs->count; i++) {
int *connector_idxs;
int ret;
int j;
@@ -766,14 +771,14 @@ static void test_combinations(const struct test_config
*tconf,
cconfs = malloc(sizeof(*cconfs) * connector_count);
igt_assert(cconfs);
- connector_idxs = &connector_combs.items[i].elems[0];
+ connector_idxs = &connector_combs->items[i].elems[0];
ret = get_connectors(tconf->resources, connector_idxs,
connector_count, cconfs);
if (ret < 0)
goto free_cconfs;
- for (j = 0; j < crtc_combs.count; j++) {
- int *crtc_idxs = &crtc_combs.items[j].elems[0];
+ for (j = 0; j < crtc_combs->count; j++) {
+ int *crtc_idxs = &crtc_combs->items[j].elems[0];
ret = assign_crtc_to_connectors(tconf, crtc_idxs,
connector_count,
cconfs);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] lib/kms: Force a full reprobe if we find a bad link
On Wed, May 31, 2017 at 04:44:41PM +0300, Martin Peres wrote: > On 31/05/17 15:42, Chris Wilson wrote: > >On Wed, May 31, 2017 at 01:40:00PM +0300, Martin Peres wrote: > >>On 26/05/17 14:48, Chris Wilson wrote: > >>>If we do a shallow probe of the connector and it reports the link failed > >>>previous (link-status != GOOD), force a full probe of the connector to > >>>give the kernel a chance to validate the mode list. > >> > >>Sounds good, but will this make the tests SKIP if no modes are available? > > > >I'm actually not sure what will happen if the mode is removed. I think > >the tests are just using the first mode in the list? At the moment I > >hope just to stop turning a single failure into many, it is still a bug > >that the link training failed and was not recovered. Alternatively, we > >can ask why isn't the kernel taking the corrective action when presented > >with a new setcrtc? > > No, this is not a kernel bug, it is a failure that the userspace has > to handle because the kernel can't do shit about this. Have you demonstrated that the kernel is beyond reproach when it failed the link training? Nothing changed in the connection and it works most of the time, so why did the kernel accept the failure. Even if we temporarily force a change of modes that is poor UX that I see no reason why it should not have been prevented in the first place. > >I'm not sure what the correct approach here should be, just what is the > >contract the kernel is expecting of userspace? Should that contract > >apply to new clients unaware of the earlier error? > > Right, IGT assumes that if a mode is already set, it can be set > again. However, this assumption has been broken when the link-status > patches landed. > > On a hotplug event, IGT should do a full reprobe, select one mode > from the list and use it. If no modes can be set and the test is > trying to set one, then the test should just SKIP. There is no hotplug event when a new client starts so how is igt meant to even know that it was supposed to pick up the pieces for the kernel. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Check the ring is empty when declaring the engines are idle
On Tue, May 30, 2017 at 03:33:41PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > As another precaution when testing whether the CS engine is actually
> > idle, also inspect the ring's HEAD/TAIL registers, which should be equal
> > when there are no commands left to execute by the GPU.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/intel_engine_cs.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index 699f2d3861c7..bc38bd128b76 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -1212,6 +1212,11 @@ static bool ring_is_idle(struct intel_engine_cs
> > *engine)
> >
> > intel_runtime_pm_get(dev_priv);
> >
> > + /* First check that no commands are left in the ring */
> > + if ((I915_READ_HEAD(engine) & HEAD_ADDR) !=
> > + (I915_READ_TAIL(engine) & TAIL_ADDR))
> > + idle = false;
> > +
>
> You are already certain that is not idle so why not goto out?
In this case I could argue that extra path for the jump is not worth it.
It saves a mmio read, yes, but will any one notice?
It boils down to is it easier to read as:
static bool ring_is_idle(struct intel_engine_cs *engine)
{
struct drm_i915_private *dev_priv = engine->i915;
bool idle = false;
intel_runtime_pm_get(dev_priv);
/* First check that no commands are left in the ring */
if ((I915_READ_HEAD(engine) & HEAD_ADDR) !=
(I915_READ_TAIL(engine) & TAIL_ADDR))
goto busy;
/* No bit for gen2, so assume the CS parser is idle */
if (INTEL_GEN(dev_priv) > 2 && !(I915_READ_MODE(engine) & MODE_IDLE))
goto busy;
idle = true;
busy:
intel_runtime_pm_put(dev_priv);
return idle;
}
First instinct would be no because of the goto.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Check the ring is empty when declaring the engines are idle
Chris Wilson writes:
> On Tue, May 30, 2017 at 03:33:41PM +0300, Mika Kuoppala wrote:
>> Chris Wilson writes:
>>
>> > As another precaution when testing whether the CS engine is actually
>> > idle, also inspect the ring's HEAD/TAIL registers, which should be equal
>> > when there are no commands left to execute by the GPU.
>> >
>> > Signed-off-by: Chris Wilson
>> > Cc: Mika Kuoppala
>> > ---
>> > drivers/gpu/drm/i915/intel_engine_cs.c | 5 +
>> > 1 file changed, 5 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
>> > b/drivers/gpu/drm/i915/intel_engine_cs.c
>> > index 699f2d3861c7..bc38bd128b76 100644
>> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
>> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
>> > @@ -1212,6 +1212,11 @@ static bool ring_is_idle(struct intel_engine_cs
>> > *engine)
>> >
>> >intel_runtime_pm_get(dev_priv);
>> >
>> > + /* First check that no commands are left in the ring */
>> > + if ((I915_READ_HEAD(engine) & HEAD_ADDR) !=
>> > + (I915_READ_TAIL(engine) & TAIL_ADDR))
>> > + idle = false;
>> > +
>>
>> You are already certain that is not idle so why not goto out?
>
> In this case I could argue that extra path for the jump is not worth it.
> It saves a mmio read, yes, but will any one notice?
and one write :P
> It boils down to is it easier to read as:
>
Sold. It is easier to read as is. 3/3 is
Reviewed-by: Mika Kuoppala
> static bool ring_is_idle(struct intel_engine_cs *engine)
> {
> struct drm_i915_private *dev_priv = engine->i915;
> bool idle = false;
>
> intel_runtime_pm_get(dev_priv);
>
> /* First check that no commands are left in the ring */
> if ((I915_READ_HEAD(engine) & HEAD_ADDR) !=
> (I915_READ_TAIL(engine) & TAIL_ADDR))
> goto busy;
>
> /* No bit for gen2, so assume the CS parser is idle */
> if (INTEL_GEN(dev_priv) > 2 && !(I915_READ_MODE(engine) & MODE_IDLE))
> goto busy;
>
> idle = true;
> busy:
> intel_runtime_pm_put(dev_priv);
>
> return idle;
> }
>
> First instinct would be no because of the goto.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC i-g-t] GEM features into feat_profile.json
On Wed, May 31, 2017 at 04:45:16PM +0300, Joonas Lahtinen wrote: > On ke, 2017-05-31 at 13:58 +0100, Chris Wilson wrote: > > On Wed, May 31, 2017 at 03:23:12PM +0300, Joonas Lahtinen wrote: > > > > > > Hello, > > > > > > I went through the gem_* tests from intel-gpu-tools and categorized > > > them into roughly categories "X | X robustness | X performance" ready > > > to be added to the feat_profile.json. > > > > > > Lets open a discussion which ones should go where. I tried to place a > > > single test to under only one category and I'm kind of hopeful that > > > we'll have the ability to add "depends_on" to create super features in > > > the future, instead of placing a single test under multiple categories. > > > > > > I didn't check all the subtests nor wildcard matching with other tests, > > > this is just all the test names placed under some categories. > > > > You seem to have assigned them exclusively to one category or another, > > most tests belong to a few of these categories. More when you consider a > > subtest may be targetting a completely different aspect. > > Yes, that's what I meant to say :) Subtests should probably be matched > by another pattern like "\btiled\b", "\bflink\b" etc. > > Ultimately there would be a resolver which would re-assign the > subtests: > > "Global objects" would then get: > > "include_subtests": "flink", > > Which would steal subtests with /\bflink\b/ from tests. Do we agree > that one subtest would be assigned to one category only, or do you > want to see duplication even at that level? I see duplication everywhere. It's more a concept of tags as opposed to categories. The use of such a system would be as "give me all the tests that exercise relocation" "give me all the tests that use a context" "give me all the tests that exercise contention on $mutex" "give me all the tests that exercise file.c:line / this patch set" The last one especially. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization
On Wed, May 03, 2017 at 11:41:29AM +0300, Imre Deak wrote: > On Tue, May 02, 2017 at 03:27:04PM +, Patchwork wrote: > > == Series Details == > > > > Series: series starting with [v4,1/2] PCI / PM: Add needs_resume flag to > > avoid suspend complete optimization > > URL : https://patchwork.freedesktop.org/series/23803/ > > State : success > > > > == Summary == > > Pushed these two patches to topic/core-for-CI for now as agreed with > Jani. I added the missing Testcase: tag while appyling. We have now 1/2 that was merged via the PCI tree and I moved now patch 2/2 from core-for-CI to -dinq. Updated Chris' r-b to v4 as agreed on IRC. Thanks for the review and testing. --Imre > > > > Series 23803v1 Series without cover letter > > https://patchwork.freedesktop.org/api/1.0/series/23803/revisions/1/mbox/ > > > > Test gem_exec_suspend: > > Subgroup basic-s4-devices: > > pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 > > > > fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 > > > > fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 > > time:430s > > fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 > > time:430s > > fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 > > time:572s > > fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 > > time:505s > > fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 > > time:556s > > fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 > > time:489s > > fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 > > time:483s > > fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 > > time:404s > > fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 > > time:419s > > fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 > > time:417s > > fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > > time:491s > > fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > > time:486s > > fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > > time:463s > > fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 > > time:562s > > fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 > > time:452s > > fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 > > time:573s > > fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 > > time:457s > > fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 > > time:495s > > fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 > > time:428s > > fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 > > time:532s > > fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 > > time:412s > > > > 310077224306c08a82476bb616de679715e83485 drm-tip: 2017y-05m-02d-12h-04m-57s > > UTC integration manifest > > f4a0cab drm/i915: Prevent the system suspend complete optimization > > 58b9cf9 PCI / PM: Add needs_resume flag to avoid suspend complete > > optimization > > > > == Logs == > > > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4599/ > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib: Moving gem_execbuf_wr to ioctl_wrappers
On Thu, May 25, 2017 at 11:25:54AM +0100, Tvrtko Ursulin wrote:
>
> On 25/05/2017 08:40, Lukasz Fiedorowicz wrote:
> > gem_execbuf_wr was duplicated in multiple places.
> > Moving everything to lib/
> >
> > Signed-off-by: Lukasz Fiedorowicz
> > ---
> > benchmarks/gem_busy.c| 16
> > benchmarks/gem_latency.c | 16
> > benchmarks/gem_wsim.c| 16
> > lib/ioctl_wrappers.c | 33 +
> > lib/ioctl_wrappers.h | 2 ++
> > tests/gem_exec_fence.c | 16
> > tests/gem_exec_nop.c | 16
> > 7 files changed, 35 insertions(+), 80 deletions(-)
> >
> > diff --git a/benchmarks/gem_busy.c b/benchmarks/gem_busy.c
> > index bda3e13..c1cee6c 100644
> > --- a/benchmarks/gem_busy.c
> > +++ b/benchmarks/gem_busy.c
> > @@ -45,8 +45,6 @@
> > #include "intel_chipset.h"
> > #include "igt_stats.h"
> >
> > -#define LOCAL_IOCTL_I915_GEM_EXECBUFFER2_WR
> > DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER2, struct
> > drm_i915_gem_execbuffer2)
> > -
> > #define LOCAL_I915_EXEC_NO_RELOC (1<<11)
> > #define LOCAL_I915_EXEC_HANDLE_LUT (1<<12)
> >
> > @@ -73,20 +71,6 @@ static bool gem_busy(int fd, uint32_t handle)
> > return busy.busy != 0;
> > }
> >
> > -static int __gem_execbuf_wr(int fd, struct drm_i915_gem_execbuffer2
> > *execbuf)
> > -{
> > - int err = 0;
> > - if (igt_ioctl(fd, LOCAL_IOCTL_I915_GEM_EXECBUFFER2_WR, execbuf))
> > - err = -errno;
> > - errno = 0;
> > - return err;
> > -}
> > -
> > -static void gem_execbuf_wr(int fd, struct drm_i915_gem_execbuffer2
> > *execbuf)
> > -{
> > - igt_assert_eq(__gem_execbuf_wr(fd, execbuf), 0);
> > -}
> > -
> > static bool gem_wait__busy(int fd, uint32_t handle)
> > {
> > struct drm_i915_gem_wait wait;
> > diff --git a/benchmarks/gem_latency.c b/benchmarks/gem_latency.c
> > index 7975ade..6cb16ba 100644
> > --- a/benchmarks/gem_latency.c
> > +++ b/benchmarks/gem_latency.c
> > @@ -45,8 +45,6 @@
> > #include
> > #include "drm.h"
> >
> > -#define LOCAL_IOCTL_I915_GEM_EXECBUFFER2_WR
> > DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER2, struct
> > drm_i915_gem_execbuffer2)
> > -
> > #define LOCAL_I915_EXEC_FENCE_IN (1<<16)
> > #define LOCAL_I915_EXEC_FENCE_OUT (1<<17)
> >
> > @@ -103,20 +101,6 @@ inline static uint32_t read_timestamp(void)
> > }
> > #endif
> >
> > -static int __gem_execbuf_wr(int _fd, struct drm_i915_gem_execbuffer2
> > *execbuf)
> > -{
> > - int err = 0;
> > - if (igt_ioctl(_fd, LOCAL_IOCTL_I915_GEM_EXECBUFFER2_WR, execbuf))
> > - err = -errno;
> > - errno = 0;
> > - return err;
> > -}
> > -
> > -static void gem_execbuf_wr(int _fd, struct drm_i915_gem_execbuffer2
> > *execbuf)
> > -{
> > - igt_assert_eq(__gem_execbuf_wr(_fd, execbuf), 0);
> > -}
> > -
> > struct consumer {
> > pthread_t thread;
> >
> > diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
> > index b366a5d..485de15 100644
> > --- a/benchmarks/gem_wsim.c
> > +++ b/benchmarks/gem_wsim.c
> > @@ -1481,22 +1481,6 @@ static void init_status_page(struct workload *wrk,
> > unsigned int flags)
> > }
> > }
> >
> > -#define LOCAL_IOCTL_I915_GEM_EXECBUFFER2_WR
> > DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER2, struct
> > drm_i915_gem_execbuffer2)
> > -
> > -static int __gem_execbuf_wr(int gemfd, struct drm_i915_gem_execbuffer2
> > *execbuf)
> > -{
> > - int err = 0;
> > - if (igt_ioctl(gemfd, LOCAL_IOCTL_I915_GEM_EXECBUFFER2_WR, execbuf))
> > - err = -errno;
> > - errno = 0;
> > - return err;
> > -}
> > -
> > -static void gem_execbuf_wr(int gemfd, struct drm_i915_gem_execbuffer2
> > *execbuf)
> > -{
> > - igt_assert_eq(__gem_execbuf_wr(gemfd, execbuf), 0);
> > -}
> > -
> > static void
> > do_eb(struct workload *wrk, struct w_step *w, enum intel_engine_id engine,
> >unsigned int flags)
> > diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
> > index 48bdcc5..0816a7b 100644
> > --- a/lib/ioctl_wrappers.c
> > +++ b/lib/ioctl_wrappers.c
> > @@ -624,6 +624,39 @@ void gem_execbuf(int fd, struct
> > drm_i915_gem_execbuffer2 *execbuf)
> > igt_assert_eq(__gem_execbuf(fd, execbuf), 0);
> > }
> >
> > +#define LOCAL_IOCTL_I915_GEM_EXECBUFFER2_WR \
> > +DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER2, struct
> > drm_i915_gem_execbuffer2)
> > +
> > +/**
> > + * __gem_execbuf_wr:
> > + * @fd: open i915 drm file descriptor
> > + * @execbuf: execbuffer data structure
> > + *
> > + * This wraps the EXECBUFFER2_WR ioctl, which submits a batchbuffer for
> > the gpu to
> > + * run. This is allowed to fail, with -errno returned.
> > + */
> > +int __gem_execbuf_wr(int fd, struct drm_i915_gem_execbuffer2 *execbuf)
> > +{
> > + int err = 0;
> > + if (igt_ioctl(fd, LOCAL_IOCTL_I915_GEM_EXECBUFFER2_WR, execbuf))
> > + err = -errno;
> > + errno = 0;
> > + return err;
> > +}
> > +
> > +/**
> >
Re: [Intel-gfx] [PATCH igt] lib/kms: Force a full reprobe if we find a bad link
On 31/05/17 16:55, Chris Wilson wrote: On Wed, May 31, 2017 at 04:44:41PM +0300, Martin Peres wrote: On 31/05/17 15:42, Chris Wilson wrote: On Wed, May 31, 2017 at 01:40:00PM +0300, Martin Peres wrote: On 26/05/17 14:48, Chris Wilson wrote: If we do a shallow probe of the connector and it reports the link failed previous (link-status != GOOD), force a full probe of the connector to give the kernel a chance to validate the mode list. Sounds good, but will this make the tests SKIP if no modes are available? I'm actually not sure what will happen if the mode is removed. I think the tests are just using the first mode in the list? At the moment I hope just to stop turning a single failure into many, it is still a bug that the link training failed and was not recovered. Alternatively, we can ask why isn't the kernel taking the corrective action when presented with a new setcrtc? No, this is not a kernel bug, it is a failure that the userspace has to handle because the kernel can't do shit about this. Have you demonstrated that the kernel is beyond reproach when it failed the link training? Nothing changed in the connection and it works most of the time, so why did the kernel accept the failure. Even if we temporarily force a change of modes that is poor UX that I see no reason why it should not have been prevented in the first place. Sorry, this is not what I meant. What I meant is that the kernel is allowed to have this behaviour. I agree though that in the case of the skl bug, it is quite likely that the kernel is doing something dodgy, but this is another bug. IGT should learn to cope with modes disappearing. I'm not sure what the correct approach here should be, just what is the contract the kernel is expecting of userspace? Should that contract apply to new clients unaware of the earlier error? Right, IGT assumes that if a mode is already set, it can be set again. However, this assumption has been broken when the link-status patches landed. On a hotplug event, IGT should do a full reprobe, select one mode from the list and use it. If no modes can be set and the test is trying to set one, then the test should just SKIP. There is no hotplug event when a new client starts so how is igt meant to even know that it was supposed to pick up the pieces for the kernel. Yes. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] topic/dp-quirks for v4.12
Hi Dave, this series, based on v4.12-rc3, starts a DP sink/branch device specific quirk database, and uses it to handle conflicting requirements on the DP Mvid/Nvid main stream attributes by different sinks. v4.12 has a Mvid/Nvid fix for a common USB Type-C DP adapter (the DA200), which unfortunately regresses an eDP display. Handle the DA200 as a quirk. Reverting the DA200 fix in v4.12 would presumably have a wider impact than not reverting, but can't have the regression either. This was tested by Clint on (at least) the DA200, and Rafael on the regressing eDP display. BR, Jani. The following changes since commit 5ed02dbb497422bf225783f46e6eadd237d23d6b: Linux 4.12-rc3 (2017-05-28 17:20:53 -0700) are available in the git repository at: git://anongit.freedesktop.org/git/drm-intel tags/topic/dp-quirks-2017-05-31 for you to fetch changes up to b31e85eda38c58cae986162ae2c462b53b0a2065: drm/i915: Detect USB-C specific dongles before reducing M and N (2017-05-29 13:43:47 +0300) DP sink specific quirks Jani Nikula (4): drm/dp: add helper for reading DP sink/branch device desc from DPCD drm/i915: use drm DP helper to read DPCD desc drm/dp: start a DPCD based DP sink/branch device quirk database drm/i915: Detect USB-C specific dongles before reducing M and N drivers/gpu/drm/drm_dp_helper.c | 83 drivers/gpu/drm/i915/i915_drv.h | 3 +- drivers/gpu/drm/i915/intel_display.c | 22 ++ drivers/gpu/drm/i915/intel_dp.c | 45 +-- drivers/gpu/drm/i915/intel_dp_mst.c | 5 ++- drivers/gpu/drm/i915/intel_drv.h | 13 +- drivers/gpu/drm/i915/intel_lspcon.c | 2 +- include/drm/drm_dp_helper.h | 51 ++ 8 files changed, 166 insertions(+), 58 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] topic/e1000e-fix
From: Daniel Vetter Date: Wed, 31 May 2017 08:10:45 +0200 > On Wed, May 31, 2017 at 7:54 AM, Daniel Vetter wrote: >> On Wed, May 31, 2017 at 1:06 AM, Dave Airlie wrote: >>> On 31 May 2017 at 08:10, David Miller wrote: From: Daniel Vetter Date: Tue, 30 May 2017 22:15:42 +0200 > If the e1000e maintainer wants to coalesce or not return statements > this simple way, that's imo on him to change the color as needed. That's not how things work. If the maintainer wants you to style things a certain way, either you do it that way or your patch isn't accepted. >> >> Consider this pull a regression report, pls handle it. > > And I guess I pile of more cc, to make this regression report > complete. I mean you got the backtrace, bisect and a proposed fix, and > the almost-whitespace change demanded is something gcc does in its > sleep. I'd understand a request to retest if it would be a real > functional change, but in this situation I have no idea why this > regression just can't be fixed already. And we can't understand why respinning with the requested change is less work than making several postings such as this one. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915/opregion: let user specify override VBT via firmware load
Sometimes it would be most enlightening to debug systems by replacing
the VBT to be used. For example, in the referenced bug the BIOS provides
different VBT depending on the boot mode (UEFI vs. legacy). It would be
interesting to try the failing boot mode with the VBT from the working
boot, and see if that makes a difference.
Add a module parameter to load the VBT using the firmware loader, not
unlike the EDID firmware mechanism.
As a starting point for experimenting, one can pick up the BIOS provided
VBT from /sys/kernel/debug/dri/0/i915_opregion/i915_vbt.
v2: clarify firmware load return value check (Bob)
v3: kfree the loaded firmware blob
References: https://bugs.freedesktop.org/show_bug.cgi?id=97822#c83
Reviewed-by: Bob Paauwe
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_params.c| 4
drivers/gpu/drm/i915/i915_params.h| 1 +
drivers/gpu/drm/i915/intel_opregion.c | 45 +++
4 files changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bde554eb2257..b200faa177ca 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -641,6 +641,7 @@ struct intel_opregion {
u32 swsci_sbcb_sub_functions;
struct opregion_asle *asle;
void *rvda;
+ void *vbt_firmware;
const void *vbt;
u32 vbt_size;
u32 *lid_state;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e363d076..6d5d334f50b1 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -115,6 +115,10 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type,
"Override/Ignore selection of SDVO panel mode in the VBT "
"(-2=ignore, -1=auto [default], index in VBT BIOS table)");
+module_param_named_unsafe(vbt_firmware, i915.vbt_firmware, charp, 0400);
+MODULE_PARM_DESC(vbt_firmware,
+"Load VBT from specified file under /lib/firmware");
+
module_param_named_unsafe(reset, i915.reset, bool, 0600);
MODULE_PARM_DESC(reset, "Attempt GPU resets (default: true)");
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 34148cc8637c..0aeb106e06af 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -28,6 +28,7 @@
#include /* for __read_mostly */
#define I915_PARAMS_FOR_EACH(func) \
+ func(char *, vbt_firmware); \
func(int, modeset); \
func(int, panel_ignore_lid); \
func(int, semaphores); \
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index d44465190dc1..a71b1c42aad8 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -27,6 +27,7 @@
#include
#include
+#include
#include
#include
@@ -829,6 +830,10 @@ void intel_opregion_unregister(struct drm_i915_private
*dev_priv)
memunmap(opregion->rvda);
opregion->rvda = NULL;
}
+ if (opregion->vbt_firmware) {
+ kfree(opregion->vbt_firmware);
+ opregion->vbt_firmware = NULL;
+ }
opregion->header = NULL;
opregion->acpi = NULL;
opregion->swsci = NULL;
@@ -912,6 +917,43 @@ static const struct dmi_system_id intel_no_opregion_vbt[]
= {
{ }
};
+static int intel_load_vbt_firmware(struct drm_i915_private *dev_priv)
+{
+ struct intel_opregion *opregion = &dev_priv->opregion;
+ const struct firmware *fw = NULL;
+ const char *name = i915.vbt_firmware;
+ int ret;
+
+ if (!name || !*name)
+ return -ENOENT;
+
+ ret = request_firmware(&fw, name, &dev_priv->drm.pdev->dev);
+ if (ret) {
+ DRM_ERROR("Requesting VBT firmware \"%s\" failed (%d)\n",
+ name, ret);
+ return ret;
+ }
+
+ if (intel_bios_is_valid_vbt(fw->data, fw->size)) {
+ opregion->vbt_firmware = kmemdup(fw->data, fw->size,
GFP_KERNEL);
+ if (opregion->vbt_firmware) {
+ DRM_DEBUG_KMS("Found valid VBT firmware \"%s\"\n",
name);
+ opregion->vbt = opregion->vbt_firmware;
+ opregion->vbt_size = fw->size;
+ ret = 0;
+ } else {
+ ret = -ENOMEM;
+ }
+ } else {
+ DRM_DEBUG_KMS("Invalid VBT firmware \"%s\"\n", name);
+ ret = -EINVAL;
+ }
+
+ release_firmware(fw);
+
+ return ret;
+}
+
int intel_opregion_setup(struct drm_i915_private *dev_priv)
{
struct intel_opregion *opregion = &dev_priv->opregion;
@@ -974,6 +1016,9 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
if (mboxes & MBOX_ASLE_EXT)
DRM_DEBUG_DRIVER("ASLE extension supported\n");
+ if (intel_
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/opregion: let user specify override VBT via firmware load
== Series Details == Series: drm/i915/opregion: let user specify override VBT via firmware load URL : https://patchwork.freedesktop.org/series/25105/ State : success == Summary == Series 25105v1 drm/i915/opregion: let user specify override VBT via firmware load https://patchwork.freedesktop.org/api/1.0/series/25105/revisions/1/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:439s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:432s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:574s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:516s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:486s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:480s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:429s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:413s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:415s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:487s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:465s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:463s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:567s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:462s fi-skl-6700hqtotal:278 pass:239 dwarn:0 dfail:1 fail:17 skip:21 time:436s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:467s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:502s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:434s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:536s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:405s 593aae9587d79f8a823a36f4e6cc12e23b547d07 drm-tip: 2017y-05m-31d-14h-36m-16s UTC integration manifest 58e54f2 drm/i915/opregion: let user specify override VBT via firmware load == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4843/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/11] drm/edid: Complete CEA modedb(VIC 1-107)
Regards
Shashank
On 5/31/2017 6:09 PM, Ville Syrjälä wrote:
On Tue, May 30, 2017 at 09:56:56PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 5/30/2017 9:48 PM, Ville Syrjälä wrote:
On Tue, May 30, 2017 at 05:43:41PM +0530, Shashank Sharma wrote:
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onwards).
This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).
Still missing the "native bit" handling.
I tried searching the native bit handling in the code, but I could not
get any thing. We are typically doing a (vic & 127) and that's all.
And that's not really correct. We shouldn't discard the msb until we've
checked that we're in the correct range of VICs that have the native
bit. drm_display_mode_from_vic_index() is the place where we should be
checking this I think.
Yep, Even I looked into these function only for the native mode
processing, But looks like
all its doing is:
vic = (video_db[video_index] & 127);
- Shashank
Can you please point out a bit here ?
- Shashank
The patch was originaly discussed and reviewed here:
https://patchwork.freedesktop.org/patch/135810/
Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Andrzej Hajda
Cc: Alex Deucher
Cc: Harry Wentland
V2: Rebase
Reviewed-by: Jose Abreu
Reviewed-by: Alex Deucher
Acked-by: Harry Wentland
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 215
+
1 file changed, 215 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8b23435..c3fa3a1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1006,6 +1006,221 @@ static const struct drm_display_mode edid_cea_modes[] =
{
2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 65 - 1280x720@24Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+ 3080, 3300, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 66 - 1280x720@25Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+ 3740, 3960, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 67 - 1280x720@30Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+ 3080, 3300, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 68 - 1280x720@50Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+ 1760, 1980, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 69 - 1280x720@60Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+ 1430, 1650, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 70 - 1280x720@100Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+ 1760, 1980, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 71 - 1280x720@120Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+ 1430, 1650, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 72 - 1920x1080@24Hz */
+ { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+ 2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 73 - 1920x1080@25Hz */
+ { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+ 2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_
Re: [Intel-gfx] [PATCH v2 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames
Regards
Shashank
On 5/31/2017 6:11 PM, Ville Syrjälä wrote:
On Tue, May 30, 2017 at 10:00:12PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 5/30/2017 9:43 PM, Ville Syrjälä wrote:
On Tue, May 30, 2017 at 05:43:40PM +0530, Shashank Sharma wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.
This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.
In case of I915 driver, this patch checks the connector->display_info
to check if the connected display is HDMI 2.0.
Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Andrzej Hajda
Cc: Alex Deucher
Cc: Daniel Vetter
PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c
V2: Rebase, Added r-b from Andrzej
Reviewed-by: Andrzej Hajda
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++-
drivers/gpu/drm/bridge/sii902x.c | 2 +-
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
drivers/gpu/drm/drm_edid.c| 12 +++-
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
drivers/gpu/drm/i915/intel_hdmi.c | 5 -
drivers/gpu/drm/i915/intel_sdvo.c | 3 ++-
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++-
drivers/gpu/drm/radeon/radeon_audio.c | 2 +-
drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
drivers/gpu/drm/sti/sti_hdmi.c| 2 +-
drivers/gpu/drm/tegra/hdmi.c | 2 +-
drivers/gpu/drm/tegra/sor.c | 2 +-
drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +-
drivers/gpu/drm/zte/zx_hdmi.c | 2 +-
include/drm/drm_edid.h| 3 ++-
21 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 3c62c45..4923ddc 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1864,7 +1864,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder
*encoder,
dce_v10_0_audio_write_sad_regs(encoder);
dce_v10_0_audio_write_latency_fields(encoder, mode);
- err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+ err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index c8ed0fa..4101684 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1848,7 +1848,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder
*encoder,
dce_v11_0_audio_write_sad_regs(encoder);
dce_v11_0_audio_write_latency_fields(encoder, mode);
- err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+ err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 3e90c19..a7f6b32 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1747,7 +1747,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder
*encoder,
dce_v8_0_audio_write_sad_regs(encoder);
dce_v8_0_audio_write_latency_fields(encoder, mode);
- err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+ err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a8236..f9b77b8 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1097,7 +1097,8 @@ static void anx78xx_bridge_mode_set(struct drm_bridge
*bridge,
mutex_lock(&anx78xx->lock);
- err = drm_hdmi_avi_infoframe_from_display_mode(&frame, adjusted
[Intel-gfx] [PATCH] drm/i915: Always recompute watermarks when distrust_bios_wm is set, v2.
On some systems there can be a race condition in which no crtc state is
added to the first atomic commit. This results in all crtc's having a
null DDB allocation, causing a FIFO underrun on any update until the
first modeset.
Changes since v1:
- Do not take the connection_mutex, this is already done below.
Reported-by: Maarten Lankhorst
Inspired-by: Mahesh Kumar
Signed-off-by: Maarten Lankhorst
Fixes: 98d39494d375 ("drm/i915/gen9: Compute DDB allocation at atomic
check time (v4)")
Cc: # v4.8+
Cc: Mahesh Kumar
Cc: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 936eef1634c7..fce4bc5ccc99 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4819,11 +4819,19 @@ skl_compute_wm(struct drm_atomic_state *state)
struct drm_crtc_state *cstate;
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct skl_wm_values *results = &intel_state->wm_results;
+ struct drm_device *dev = state->dev;
struct skl_pipe_wm *pipe_wm;
bool changed = false;
int ret, i;
/*
+* When we distrust bios wm we always need to recompute to set the
+* expected DDB allocations for each CRTC.
+*/
+ if (to_i915(dev)->wm.distrust_bios_wm)
+ changed = true;
+
+ /*
* If this transaction isn't actually touching any CRTC's, don't
* bother with watermark calculation. Note that if we pass this
* test, we're guaranteed to hold at least one CRTC state mutex,
@@ -4833,6 +4841,7 @@ skl_compute_wm(struct drm_atomic_state *state)
*/
for_each_new_crtc_in_state(state, crtc, cstate, i)
changed = true;
+
if (!changed)
return 0;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] topic/e1000e-fix
On Wed, 31 May 2017, David Miller wrote: > And we can't understand why respinning with the requested change is > less work than making several postings such as this one. When our CI hits tons of non-drm issues every merge window, I imagine our developers can start to get a little frustrated trying to get them fixed. Especially so when valid fixes like this get blocked by silly bikesheds from developers who don't even seem to have very many contributions upstream, and the maintainers don't respond. We have enough on our plates trying to get our own stuff fixed. While I understand why our developers aren't willing to jump through all the hoops, updated patch follows. Please let's move on. BR, Jani. Chris Wilson (1): e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails
From: Chris Wilson
An error during suspend (e100e_pm_suspend),
[ 429.994338] ACPI : EC: event blocked
[ 429.994633] e1000e: EEE TX LPI TIMER: 0011
[ 430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e] returns -2
[ 430.955454] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -2
[ 430.955458] PM: Device :00:19.0 failed to suspend async: error -2
[ 430.955581] PM: Some devices failed to suspend, or early wake event detected
[ 430.957709] ACPI : EC: event unblocked
lead to complete failure:
[ 432.585002] [ cut here ]
[ 432.585013] WARNING: CPU: 3 PID: 8372 at kernel/irq/manage.c:1478
__free_irq+0x9f/0x280
[ 432.585015] Trying to free already-free IRQ 20
[ 432.585016] Modules linked in: cdc_ncm usbnet x86_pkg_temp_thermal
intel_powerclamp coretemp mii crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel
snd_hda_codec snd_hwdep lpc_ich snd_hda_core snd_pcm mei_me mei sdhci_pci sdhci
i915 mmc_core e1000e ptp pps_core prime_numbers
[ 432.585042] CPU: 3 PID: 8372 Comm: kworker/u16:40 Tainted: G U
4.10.0-rc8-CI-Patchwork_3870+ #1
[ 432.585044] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 )
07/02/2012
[ 432.585050] Workqueue: events_unbound async_run_entry_fn
[ 432.585051] Call Trace:
[ 432.585058] dump_stack+0x67/0x92
[ 432.585062] __warn+0xc6/0xe0
[ 432.585065] warn_slowpath_fmt+0x4a/0x50
[ 432.585070] ? _raw_spin_lock_irqsave+0x49/0x60
[ 432.585072] __free_irq+0x9f/0x280
[ 432.585075] free_irq+0x34/0x80
[ 432.585089] e1000_free_irq+0x65/0x70 [e1000e]
[ 432.585098] e1000e_pm_freeze+0x7a/0xb0 [e1000e]
[ 432.585106] e1000e_pm_suspend+0x21/0x30 [e1000e]
[ 432.585113] pci_pm_suspend+0x71/0x140
[ 432.585118] dpm_run_callback+0x6f/0x330
[ 432.585122] ? pci_pm_freeze+0xe0/0xe0
[ 432.585125] __device_suspend+0xea/0x330
[ 432.585128] async_suspend+0x1a/0x90
[ 432.585132] async_run_entry_fn+0x34/0x160
[ 432.585137] process_one_work+0x1f4/0x6d0
[ 432.585140] ? process_one_work+0x16e/0x6d0
[ 432.585143] worker_thread+0x49/0x4a0
[ 432.585145] kthread+0x107/0x140
[ 432.585148] ? process_one_work+0x6d0/0x6d0
[ 432.585150] ? kthread_create_on_node+0x40/0x40
[ 432.585154] ret_from_fork+0x2e/0x40
[ 432.585156] ---[ end trace 6712df7f8c4b9124 ]---
The unwind failures stems from commit 2800209994f8 ("e1000e: Refactor PM
flows"), but it may be a later patch that introduced the non-recoverable
behaviour.
Fixes: 2800209994f8 ("e1000e: Refactor PM flows")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847
Cc: Tvrtko Ursulin
Cc: Jeff Kirsher
Cc: Dave Ertman
Cc: Bruce Allan
Cc: intel-wired-...@lists.osuosl.org
Cc: net...@vger.kernel.org
Signed-off-by: Chris Wilson
[Jani: bikeshed repainted]
Signed-off-by: Jani Nikula
---
drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index b3679728caac..5cad688be609 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6630,12 +6630,17 @@ static int e1000e_pm_thaw(struct device *dev)
static int e1000e_pm_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
+ int rc;
e1000e_flush_lpic(pdev);
e1000e_pm_freeze(dev);
- return __e1000_shutdown(pdev, false);
+ rc = __e1000_shutdown(pdev, false);
+ if (rc)
+ e1000e_pm_thaw(dev);
+
+ return rc;
}
static int e1000e_pm_resume(struct device *dev)
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Get rid of the enable_guc_loading module parameter
On 05/18/2017 05:41 PM, Michal Wajdeczko wrote:
On Fri, May 05, 2017 at 01:23:17PM +, Oscar Mateo wrote:
The decission to enable GuC loading shouldn't be left to the user.
Provided the HW supports the GuC, there are only two reasons to load it:
- The user has requested GuC submission.
- We have a HuC firmware available (so we need the GuC to validate it).
We leave the enable_guc_submission parameter untouched ("auto", "never",
"if supported", "required") but make its behavior a little bit more
consistent. Also, if not really required, we do not try to fetch any
firmware.
Cc: Anusha Srivatsa
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 --
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 16 +
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/i915_params.c | 6
drivers/gpu/drm/i915/i915_params.h | 2 --
drivers/gpu/drm/i915/intel_guc_loader.c | 48 +++
drivers/gpu/drm/i915/intel_huc.c| 5 +--
drivers/gpu/drm/i915/intel_uc.c | 58 +
drivers/gpu/drm/i915/intel_uc.h | 4 +--
drivers/gpu/drm/i915/intel_uncore.c | 3 +-
13 files changed, 82 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 870c470..e030b41 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2366,8 +2366,10 @@ static int i915_huc_load_status_info(struct seq_file *m,
void *data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct intel_uc_fw *huc_fw = &dev_priv->huc.fw;
- if (!HAS_HUC_UCODE(dev_priv))
+ if (!HAS_GUC(dev_priv)) {
+ seq_puts(m, "No HuC support in HW\n");
return 0;
+ }
seq_puts(m, "HuC firmware status:\n");
seq_printf(m, "\tpath: %s\n", huc_fw->path);
@@ -2399,8 +2401,10 @@ static int i915_guc_load_status_info(struct seq_file *m,
void *data)
struct intel_uc_fw *guc_fw = &dev_priv->guc.fw;
u32 tmp, i;
- if (!HAS_GUC_UCODE(dev_priv))
+ if (!HAS_GUC(dev_priv)) {
+ seq_puts(m, "No GuC support in HW\n");
return 0;
+ }
seq_printf(m, "GuC firmware status:\n");
seq_printf(m, "\tpath: %s\n",
@@ -2504,7 +2508,7 @@ static int i915_guc_info(struct seq_file *m, void *data)
if (!guc->execbuf_client) {
seq_printf(m, "GuC submission %s\n",
- HAS_GUC_SCHED(dev_priv) ?
+ HAS_GUC(dev_priv) ?
"disabled" :
"not supported");
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 72fb47a..006ed91 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -996,7 +996,7 @@ static void intel_sanitize_options(struct drm_i915_private
*dev_priv)
i915.semaphores = intel_sanitize_semaphores(dev_priv, i915.semaphores);
DRM_DEBUG_DRIVER("use GPU semaphores? %s\n", yesno(i915.semaphores));
- intel_uc_sanitize_options(dev_priv);
+ intel_guc_sanitize_submission(dev_priv);
}
/**
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b20ed16..5d00120 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2921,15 +2921,17 @@ static inline struct scatterlist *__sg_next(struct
scatterlist *sg)
#define HAS_RUNTIME_PM(dev_priv) ((dev_priv)->info.has_runtime_pm)
#define HAS_64BIT_RELOC(dev_priv) ((dev_priv)->info.has_64bit_reloc)
+#define HAS_GUC(dev_priv) ((dev_priv)->info.has_guc)
+#define HAS_GUC_UCODE(dev_priv)((dev_priv)->guc.fw.path != NULL)
+#define HAS_HUC_UCODE(dev_priv)((dev_priv)->huc.fw.path != NULL)
+
/*
- * For now, anything with a GuC requires uCode loading, and then supports
- * command submission once loaded. But these are logically independent
- * properties, so we have separate macros to test them.
+ * Only two things require us to load the GuC firmware: either we want
+ * to enable GuC submission or we need it to to validate a HuC firmware
*/
-#define HAS_GUC(dev_priv) ((dev_priv)->info.has_guc)
-#define HAS_GUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
-#define HAS_GUC_SCHED(dev_priv)(HAS_GUC(dev_priv))
-#define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
+#define NEEDS_GUC_LOADING(dev_priv) \
+ (HAS_GUC(dev_priv) && \
+ (i915.enable_guc_submission || HAS_HUC_UCODE(dev_priv)))
#define HAS_RESOURCE_STREAMER(dev_priv) ((dev_priv)->info.has_resource_streamer)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/d
Re: [Intel-gfx] [PULL] topic/e1000e-fix
On Wed, May 31, 2017 at 5:08 PM, David Miller wrote: > From: Daniel Vetter > Date: Wed, 31 May 2017 08:10:45 +0200 > >> On Wed, May 31, 2017 at 7:54 AM, Daniel Vetter >> wrote: >>> On Wed, May 31, 2017 at 1:06 AM, Dave Airlie wrote: On 31 May 2017 at 08:10, David Miller wrote: > From: Daniel Vetter > Date: Tue, 30 May 2017 22:15:42 +0200 > >> If the e1000e maintainer wants to coalesce or not return statements >> this simple way, that's imo on him to change the color as needed. > > That's not how things work. > > If the maintainer wants you to style things a certain way, either you > do it that way or your patch isn't accepted. >>> >>> Consider this pull a regression report, pls handle it. >> >> And I guess I pile of more cc, to make this regression report >> complete. I mean you got the backtrace, bisect and a proposed fix, and >> the almost-whitespace change demanded is something gcc does in its >> sleep. I'd understand a request to retest if it would be a real >> functional change, but in this situation I have no idea why this >> regression just can't be fixed already. > > And we can't understand why respinning with the requested change is > less work than making several postings such as this one. I guess next time around we should do even less, i.e. report the regression + bisect and then escalate this until the netdev folks fix it on their own? Like Jani said every -rc1 a pile of our CI machines keel over, and unfortunately this patch here isn't the only one which seems to not really move anywhere. -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 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup
On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote: > IRQs are properly shut down, so it almost works as race-free shutdown. > Except the irq is stopped after the vblank stuff, so boom anyway. > Proper way would be to call drm_atomic_helper_shutdown before any of > the kms things gets stopped. So no harm in removing the > drm_vblank_cleanup here really. > > Same story for both hdlcd and mali. > > v2: Move misplaced malidp hunk to this patch (Liviu). > > Cc: Liviu Dudau > Cc: Brian Starkey > Signed-off-by: Daniel Vetter On the assumption that a subsequent patch will fix the issue highlighted in the commit message (doesn't have to be part of this series): Acked-by: Liviu Dudau I'm assuming that you are going to carry this patch through one of your trees, so I will not pull it into mali-dp tree. Thanks, Liviu > --- > drivers/gpu/drm/arm/hdlcd_drv.c | 2 -- > drivers/gpu/drm/arm/malidp_drv.c | 2 -- > 2 files changed, 4 deletions(-) > > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c > index 0f49c4b12772..345c8357b273 100644 > --- a/drivers/gpu/drm/arm/hdlcd_drv.c > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c > @@ -340,7 +340,6 @@ static int hdlcd_drm_bind(struct device *dev) > } > err_fbdev: > drm_kms_helper_poll_fini(drm); > - drm_vblank_cleanup(drm); > err_vblank: > pm_runtime_disable(drm->dev); > err_pm_active: > @@ -368,7 +367,6 @@ static void hdlcd_drm_unbind(struct device *dev) > } > drm_kms_helper_poll_fini(drm); > component_unbind_all(dev, drm); > - drm_vblank_cleanup(drm); > pm_runtime_get_sync(drm->dev); > drm_irq_uninstall(drm); > pm_runtime_put_sync(drm->dev); > diff --git a/drivers/gpu/drm/arm/malidp_drv.c > b/drivers/gpu/drm/arm/malidp_drv.c > index 0d3eb537d08b..01b13d219917 100644 > --- a/drivers/gpu/drm/arm/malidp_drv.c > +++ b/drivers/gpu/drm/arm/malidp_drv.c > @@ -652,7 +652,6 @@ static int malidp_bind(struct device *dev) > drm_kms_helper_poll_fini(drm); > fbdev_fail: > pm_runtime_get_sync(dev); > - drm_vblank_cleanup(drm); > vblank_fail: > malidp_se_irq_fini(drm); > malidp_de_irq_fini(drm); > @@ -692,7 +691,6 @@ static void malidp_unbind(struct device *dev) > } > drm_kms_helper_poll_fini(drm); > pm_runtime_get_sync(dev); > - drm_vblank_cleanup(drm); > malidp_se_irq_fini(drm); > malidp_de_irq_fini(drm); > component_unbind_all(dev, drm); > -- > 2.11.0 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup
On Wed, May 31, 2017 at 1:22 PM, Liviu Dudau wrote: > On Wed, May 31, 2017 at 01:03:34PM +0200, Daniel Vetter wrote: >> On Wed, May 31, 2017 at 12:57 PM, Liviu Dudau wrote: >> > On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote: >> >> IRQs are properly shut down, so it almost works as race-free shutdown. >> >> Except the irq is stopped after the vblank stuff, so boom anyway. >> >> Proper way would be to call drm_atomic_helper_shutdown before any of >> >> the kms things gets stopped. So no harm in removing the >> >> drm_vblank_cleanup here really. >> > >> > Slightly confused on the implied message in the commit text: is "Proper way >> > would be to call drm_atomic_helper_shutdown" a hint? A promise of a future >> > patch? A message to the future us on how to fix things if they blow up? >> > >> > If calling drm_atomic_helper_shutdown() is the proper thing to do, why >> > does the >> > patch (and the series) avoids doing that? Lack of understanding of the >> > driver's >> > internal workings? Then I want to help, if I can understand the new >> > direction. >> >> Yes, I wanted to not make things worse. If you look at the overall >> result (especially last patch) I'm also trying to better document >> stuff in the vblank area, but summarized, if you want to make sure >> that vblank processing has stopped, you need to call drm_vblank_off on >> each active crtc. The simplest way to get that is by using >> drm_atomic_helper_shutdown(). Calling drm_vblank_cleanup doesn't >> really do anything useful (see the last patch for the only valid >> usecase there ever was). > > OK, so there should be a follow up patch adding drm_atomic_helper_shutdown(). > I guess > I need to call dibs on it? :) I googled what "to call dibs on smth" means and still can't figure out what you mean here. Can you pls explain? Thanks, 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 2/3] pwm: lpss: Add intel-gfx as consumer device in lookup table
Hi Shobhit, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on v4.12-rc3 next-20170531] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Shobhit-Kumar/drm-i915-Encapsulate-the-pwm_device-in-a-pwm_info-structure/20170531-222631 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-randconfig-i0-201722 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): >> ERROR: "pwm_add_table" [drivers/pwm/pwm-lpss-platform.ko] undefined! >> ERROR: "pwm_remove_table" [drivers/pwm/pwm-lpss-platform.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/37] drm/hdlcd|mali: Drop drm_vblank_cleanup
On Wed, May 31, 2017 at 06:41:05PM +0200, Daniel Vetter wrote: > On Wed, May 31, 2017 at 1:22 PM, Liviu Dudau wrote: > > On Wed, May 31, 2017 at 01:03:34PM +0200, Daniel Vetter wrote: > >> On Wed, May 31, 2017 at 12:57 PM, Liviu Dudau wrote: > >> > On Wed, May 24, 2017 at 04:51:51PM +0200, Daniel Vetter wrote: > >> >> IRQs are properly shut down, so it almost works as race-free shutdown. > >> >> Except the irq is stopped after the vblank stuff, so boom anyway. > >> >> Proper way would be to call drm_atomic_helper_shutdown before any of > >> >> the kms things gets stopped. So no harm in removing the > >> >> drm_vblank_cleanup here really. > >> > > >> > Slightly confused on the implied message in the commit text: is "Proper > >> > way > >> > would be to call drm_atomic_helper_shutdown" a hint? A promise of a > >> > future > >> > patch? A message to the future us on how to fix things if they blow up? > >> > > >> > If calling drm_atomic_helper_shutdown() is the proper thing to do, why > >> > does the > >> > patch (and the series) avoids doing that? Lack of understanding of the > >> > driver's > >> > internal workings? Then I want to help, if I can understand the new > >> > direction. > >> > >> Yes, I wanted to not make things worse. If you look at the overall > >> result (especially last patch) I'm also trying to better document > >> stuff in the vblank area, but summarized, if you want to make sure > >> that vblank processing has stopped, you need to call drm_vblank_off on > >> each active crtc. The simplest way to get that is by using > >> drm_atomic_helper_shutdown(). Calling drm_vblank_cleanup doesn't > >> really do anything useful (see the last patch for the only valid > >> usecase there ever was). > > > > OK, so there should be a follow up patch adding > > drm_atomic_helper_shutdown(). I guess > > I need to call dibs on it? :) > > I googled what "to call dibs on smth" means and still can't figure out > what you mean here. Can you pls explain? Means I put my name on it. Urban dictionary on "call dibs" gives it a very gender specific usage, my intent was to convey the message that I will take it on my TODO list. Best regards, Liviu > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t 0/1] Introducing HW focused tests
The IGT test suite aims at testing the functionalities of the i915
graphics driver. Because of an increasing effort to move development and
validation to the early stages in the development of new platforms, it
is necessary to provide some form of coverage for scenarios where the
driver assumes the HW will have a determined behaviour.
This patch introduces a more HW focused test that will send 'bad commands'
to the GPU and expect they are dealt with accordingly. Since the test will
not exercise i915 as such but rather rely on the HW to manage the issue, it
is not suitable to be merged in the current IGT tests. A new folder,
'tests_hw' has been created to host such tests.
This is not intended to introduce an exhaustive test of the Intel GEN hardware,
but, rather, as an attempt to instigate a discussion on what should be the
proper procedure for managing and maintaining HW focused tests.
Cc: Latvala Petri
Antonio Argenziano (1):
tests/gem_bad_address: Fix and update gem_bad_address
Makefile.am | 4 ++
configure.ac | 11 ++
tests_hw/Makefile.am | 36 ++
tests_hw/Makefile.sources | 8
{tests => tests_hw}/gem_bad_address.c | 69 ---
5 files changed, 98 insertions(+), 30 deletions(-)
create mode 100644 tests_hw/Makefile.am
create mode 100644 tests_hw/Makefile.sources
rename {tests => tests_hw}/gem_bad_address.c (50%)
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
