Sam Ravnborg
2b33e19195
drm/panel: ilitek-ili9881c: use drm_panel backlight support
...
Use the backlight support in drm_panel to simplify the driver
Signed-off-by: Sam Ravnborg <sam@ravnborg.org >
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Thierry Reding <thierry.reding@gmail.com >
Cc: Sam Ravnborg <sam@ravnborg.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20191207140353.23967-10-sam@ravnborg.org
2019-12-09 22:57:26 +01:00
Sam Ravnborg
e3e4944faa
drm/panel: feiyang-fy07024di26a30d: use drm_panel backlight support
...
Use the backlight support in drm_panel to simplify the driver
Signed-off-by: Sam Ravnborg <sam@ravnborg.org >
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Jagan Teki <jagan@amarulasolutions.com >
Cc: Thierry Reding <thierry.reding@gmail.com >
Cc: Sam Ravnborg <sam@ravnborg.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20191207140353.23967-9-sam@ravnborg.org
2019-12-09 22:57:26 +01:00
Sam Ravnborg
aa6c43644b
drm/panel: drop drm_device from drm_panel
...
The panel drivers used drm_panel.drm for two purposes:
1) Argument to drm_mode_duplicate()
2) drm->dev was used in error messages
The first usage is replaced with drm_connector.dev
- drm_connector is already connected to a drm_device
and we have a valid connector
The second usage is replaced with drm_panel.dev
- this makes drivers more consistent in their dev argument
used for dev_err() and friends
With these replacements there are no more uses of drm_panel.drm,
so it is removed from struct drm_panel.
With this change drm_panel_attach() and drm_panel_detach()
no longer have any use as they are empty functions.
v2:
- editorial correction in changelog (Laurent)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org >
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Reviewed-by: Linus Walleij <linus.walleij@linaro.org >
Cc: Thierry Reding <thierry.reding@gmail.com >
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com >
Cc: Sam Ravnborg <sam@ravnborg.org >
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Cc: Maxime Ripard <mripard@kernel.org >
Cc: David Airlie <airlied@linux.ie >
Cc: Daniel Vetter <daniel@ffwll.ch >
Cc: Linus Walleij <linus.walleij@linaro.org >
Cc: Jagan Teki <jagan@amarulasolutions.com >
Cc: Stefan Mavrodiev <stefan@olimex.com >
Cc: Robert Chiras <robert.chiras@nxp.com >
Cc: "Guido Günther" <agx@sigxcpu.org >
Cc: Purism Kernel Team <kernel@puri.sm >
Link: https://patchwork.freedesktop.org/patch/msgid/20191207140353.23967-8-sam@ravnborg.org
2019-12-09 22:57:26 +01:00
Sam Ravnborg
06c4a9c2ae
drm/panel: decouple connector from drm_panel
...
To facilitate moving connector creation to display drivers,
decouple the drm_connector from drm_panel.
This patch adds a connector argument to drm_panel_get_modes().
All users of drm_panel_get_modes() already had the connector
available, so updating users was trivial.
With this patch drm_panel no longer keeps a reference to the drm_connector.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org >
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Reviewed-by: Linus Walleij <linus.walleij@linaro.org >
Acked-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com >
Cc: Thierry Reding <thierry.reding@gmail.com >
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com >
Cc: Sam Ravnborg <sam@ravnborg.org >
Cc: Andrzej Hajda <a.hajda@samsung.com >
Cc: Neil Armstrong <narmstrong@baylibre.com >
Cc: Jonas Karlman <jonas@kwiboo.se >
Cc: Jernej Skrabec <jernej.skrabec@siol.net >
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Cc: Maxime Ripard <mripard@kernel.org >
Cc: David Airlie <airlied@linux.ie >
Cc: Daniel Vetter <daniel@ffwll.ch >
Cc: Inki Dae <inki.dae@samsung.com >
Cc: Joonyoung Shim <jy0922.shim@samsung.com >
Cc: Seung-Woo Kim <sw0312.kim@samsung.com >
Cc: Kyungmin Park <kyungmin.park@samsung.com >
Cc: Kukjin Kim <kgene@kernel.org >
Cc: Krzysztof Kozlowski <krzk@kernel.org >
Cc: Stefan Agner <stefan@agner.ch >
Cc: Alison Wang <alison.wang@nxp.com >
Cc: Philipp Zabel <p.zabel@pengutronix.de >
Cc: Shawn Guo <shawnguo@kernel.org >
Cc: Sascha Hauer <s.hauer@pengutronix.de >
Cc: Pengutronix Kernel Team <kernel@pengutronix.de >
Cc: Fabio Estevam <festevam@gmail.com >
Cc: NXP Linux Team <linux-imx@nxp.com >
Cc: CK Hu <ck.hu@mediatek.com >
Cc: Matthias Brugger <matthias.bgg@gmail.com >
Cc: Marek Vasut <marex@denx.de >
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com >
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com >
Cc: Sandy Huang <hjc@rock-chips.com >
Cc: "Heiko Stübner" <heiko@sntech.de >
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org >
Cc: Vincent Abriou <vincent.abriou@st.com >
Cc: Chen-Yu Tsai <wens@csie.org >
Cc: Jonathan Hunter <jonathanh@nvidia.com >
Cc: Torsten Duwe <duwe@lst.de >
Cc: Vasily Khoruzhick <anarsoul@gmail.com >
Cc: Icenowy Zheng <icenowy@aosc.io >
Cc: Sean Paul <seanpaul@chromium.org >
Cc: Linus Walleij <linus.walleij@linaro.org >
Cc: Boris Brezillon <boris.brezillon@collabora.com >
Cc: Hariprasad Kelam <hariprasad.kelam@gmail.com >
Cc: Alexios Zavras <alexios.zavras@intel.com >
Cc: Brian Masney <masneyb@onstation.org >
Cc: Rob Clark <robdclark@chromium.org >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: Allison Randal <allison@lohutok.net >
Cc: Shayenne Moura <shayenneluzmoura@gmail.com >
Cc: Abhinav Kumar <abhinavk@codeaurora.org >
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-tegra@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20191207140353.23967-7-sam@ravnborg.org
2019-12-09 22:57:26 +01:00
Sam Ravnborg
0ce8ddd8e0
drm/panel: add drm_connector argument to get_modes()
...
Today the bridge creates the drm_connector, but that is planned
to be moved to the display drivers.
To facilitate this, update drm_panel_funcs.get_modes() to
take drm_connector as an argument.
All panel drivers implementing get_modes() are updated.
v2:
- drop accidental change (Laurent)
- update docs for get_modes (Laurent)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org >
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Reviewed-by: Linus Walleij <linus.walleij@linaro.org >
Cc: Thierry Reding <thierry.reding@gmail.com >
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Cc: Maxime Ripard <mripard@kernel.org >
Cc: David Airlie <airlied@linux.ie >
Cc: Daniel Vetter <daniel@ffwll.ch >
Cc: Linus Walleij <linus.walleij@linaro.org >
Cc: Jagan Teki <jagan@amarulasolutions.com >
Cc: Stefan Mavrodiev <stefan@olimex.com >
Cc: Robert Chiras <robert.chiras@nxp.com >
Cc: "Guido Günther" <agx@sigxcpu.org >
Cc: Purism Kernel Team <kernel@puri.sm >
Link: https://patchwork.freedesktop.org/patch/msgid/20191207140353.23967-6-sam@ravnborg.org
2019-12-09 22:57:26 +01:00
Sam Ravnborg
d383fb5f8a
drm: get drm_bridge_panel connector via helper
...
The drm_connector created by drm_panel_bridge was accessed
via drm_panel.connector.
Avoid the detour around drm_panel by providing a simple get method.
This avoids direct access to the connector field in drm_panel in
the two users.
The change is done in preparation for removal of drm_panel.connector.
Update pl111 and tve200 to use the new helper.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org >
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Reviewed-by: Linus Walleij <linus.walleij@linaro.org >
Cc: Andrzej Hajda <a.hajda@samsung.com >
Cc: Neil Armstrong <narmstrong@baylibre.com >
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com >
Cc: Jonas Karlman <jonas@kwiboo.se >
Cc: Jernej Skrabec <jernej.skrabec@siol.net >
Cc: Eric Anholt <eric@anholt.net >
Cc: Linus Walleij <linus.walleij@linaro.org >
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Cc: Maxime Ripard <mripard@kernel.org >
Cc: David Airlie <airlied@linux.ie >
Cc: Daniel Vetter <daniel@ffwll.ch >
Link: https://patchwork.freedesktop.org/patch/msgid/20191207140353.23967-5-sam@ravnborg.org
2019-12-09 22:57:26 +01:00
Sam Ravnborg
0fe1564bd6
drm/panel: simple: use drm_panel backlight support
...
Use drm_panel infrastructure for backlight.
Replace direct calls with drm_panel_*() calls
to utilize the drm_panel support.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org >
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Thierry Reding <thierry.reding@gmail.com >
Cc: Sam Ravnborg <sam@ravnborg.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20191207140353.23967-4-sam@ravnborg.org
2019-12-09 22:57:26 +01:00
Sam Ravnborg
152dbdeab1
drm/panel: add backlight support
...
Panels often support backlight as specified in a device tree.
Update the drm_panel infrastructure to support this to
simplify the drivers.
With this the panel driver just needs to add the following to the
probe() function:
err = drm_panel_of_backlight(panel);
if (err)
return err;
Then drm_panel will handle all the rest.
There is one caveat with the backlight support.
If drm_panel_(enable|disable) are called multiple times
in a row then backlight_(enable|disable) will be called multiple times.
The above will happen when a panel drivers unconditionally
calls drm_panel_disable() in their shutdown() function,
whan the panel is already disabled and then shutdown() is called.
Reading the backlight code it seems safe to call
the backlight_(enable|disable) several times.
v3:
- Improve comments, fix grammar (Laurent)
- Do not fail in drm_panel_of_backlight() if no DT support (Laurent)
- Log if backlight_(enable|disable) fails (Laurent)
- Improve drm_panel_of_backlight() docs
- Updated changelog with backlight analysis (triggered by Laurent)
v2:
- Drop test of CONFIG_DRM_PANEL in header-file (Laurent)
- do not enable backlight if ->enable() returns an error
Signed-off-by: Sam Ravnborg <sam@ravnborg.org >
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Thierry Reding <thierry.reding@gmail.com >
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Cc: Maxime Ripard <maxime.ripard@bootlin.com >
Cc: Sean Paul <sean@poorly.run >
Cc: David Airlie <airlied@linux.ie >
Cc: Daniel Vetter <daniel@ffwll.ch >
Link: https://patchwork.freedesktop.org/patch/msgid/20191207140353.23967-3-sam@ravnborg.org
2019-12-09 22:57:26 +01:00
Sam Ravnborg
5dce87a919
drm/drm_panel: no error when no callback
...
The callbacks in drm_panel_funcs are optional, so do not
return an error just because no callback is assigned.
v2:
- Document what functions in drm_panel_funcs are optional (Laurent)
- Return -EOPNOTSUPP if get_modes() is not assigned (Laurent)
(Sam: -EOPNOTSUPP seems to best error code in this situation)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org >
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Cc: Maxime Ripard <mripard@kernel.org >
Cc: Thierry Reding <thierry.reding@gmail.com >
Cc: Sam Ravnborg <sam@ravnborg.org >
Cc: David Airlie <airlied@linux.ie >
Cc: Daniel Vetter <daniel@ffwll.ch >
Link: https://patchwork.freedesktop.org/patch/msgid/20191207140353.23967-2-sam@ravnborg.org
2019-12-09 22:57:26 +01:00
Daniele Ceraolo Spurio
3c9abe886a
drm/i915/guc: kill the GuC client
...
We now only use 1 client without any plan to add more. The client is
also only holding information about the WQ and the process desc, so we
can just move those in the intel_guc structure and always use stage_id
0.
v2: fix comment (John)
v3: fix the comment for real, fix kerneldoc
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: John Harrison <John.C.Harrison@Intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Reviewed-by: John Harrison <John.C.Harrison@Intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191205220243.27403-4-daniele.ceraolospurio@intel.com
2019-12-09 13:55:50 -08:00
Daniele Ceraolo Spurio
e9362e1336
drm/i915/guc: kill doorbell code and selftests
...
Instead of relying on the workqueue, the upcoming reworked GuC
submission flow will offer the host driver indipendent control over
the execution status of each context submitted to GuC. As part of this,
the doorbell usage model has been reworked, with each doorbell being
paired to a single lrc and a doorbell ring representing new work
available for that specific context. This mechanism, however, limits
the number of contexts that can be registered with GuC to the number of
doorbells, which is an undesired limitation. To avoid this limitation,
we requested the GuC team to also provide a H2G that will allow the host
to notify the GuC of work available for a specified lrc, so we can use
that mechanism instead of relying on the doorbells. We can therefore drop
the doorbell code we currently have, also given the fact that in the
unlikely case we'd want to switch back to using doorbells we'd have to
heavily rework it.
The workqueue will still have a use in the new interface to pass special
commands, so that code has been retained for now.
With the doorbells gone and the GuC client becoming even simpler, the
existing GuC selftests don't give us any meaningful coverage so we can
remove them as well. Some selftests might come with the new code, but
they will look different from what we have now so if doesn't seem worth
it to keep the file around in the meantime.
v2: fix comments and commit message (John)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: John Harrison <John.C.Harrison@Intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Reviewed-by: John Harrison <John.C.Harrison@Intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191205220243.27403-3-daniele.ceraolospurio@intel.com
2019-12-09 13:55:44 -08:00
Daniele Ceraolo Spurio
18c094b304
drm/i915/guc: add a helper to allocate and map guc vma
...
We already have a couple of use-cases in the code and another one will
come in one of the later patches in the series.
v2: use the new function for the CT object as well
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: John Harrison <John.C.Harrison@Intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk > #v1
Reviewed-by: John Harrison <John.C.Harrison@Intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191205220243.27403-2-daniele.ceraolospurio@intel.com
2019-12-09 13:54:33 -08:00
Daniele Ceraolo Spurio
d54dc6eede
drm/i915/guc: Drop leftover preemption code
...
Remove unused enums and ctx_save_restore_disabled() function, leftover
from the legacy preemption removal.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: John Harrison <John.C.Harrison@Intel.com >
Cc: Matthew Brost <matthew.brost@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20191205220243.27403-1-daniele.ceraolospurio@intel.com
2019-12-09 13:54:28 -08:00
Chuhong Yuan
4286dc07e6
drm/gma500: add a missed gma_power_end in error path
...
oaktrail_lvds_mode_set() misses a gma_power_end() in an error path.
Add the call to fix it.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com >
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191209085747.16057-1-hslester96@gmail.com
2019-12-09 21:30:03 +01:00
Ville Syrjälä
67e1d5ed85
drm/i915/hdcp: Nuke intel_hdcp_transcoder_config()
...
intel_hdcp_transcoder_config() is clobbering some globally visible
state in .compute_config(). That is a big no no as .compute_config()
is supposed to have no visible side effects when either the commit
fails or it's just a TEST_ONLY commit.
Inline this stuff into intel_hdcp_enable() so that the state only
gets modified when we actually commit the state to the hardware.
Cc: Ramalingam C <ramalingam.c@intel.com >
Cc: Jani Nikula <jani.nikula@intel.com >
Cc: Uma Shankar <uma.shankar@intel.com >
Fixes: 39e2df090cville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-2-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com >
2019-12-09 17:49:39 +02:00
Ville Syrjälä
e10ad9c697
drm/i915/fbc: Reallocate cfb if we need more of it
...
The code assumes we can omit the cfb allocation once fbc
has been enabled once. That's nonsense. Let's try to
reallocate it if we need to.
The code is still a mess, but maybe this is enough to get
fbc going in some cases where it initially underallocates
the cfb and there's no full modeset to fix it up.
Cc: Daniel Drake <drake@endlessm.com >
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com >
Cc: Jian-Hong Pan <jian-hong@endlessm.com >
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-15-ville.syrjala@linux.intel.com
Tested-by: Daniel Drake <drake@endlessm.com >
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2019-12-09 16:10:59 +02:00
Ville Syrjälä
34cddbc03b
drm/i915/fbc: Enable fbc by default on glk+ once again
...
Now that we have the glk+ w/a for back to back fbc disable + plane
update in place we can once more enable fbc on glk+ by default.
Cc: Daniel Drake <drake@endlessm.com >
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com >
Cc: Jian-Hong Pan <jian-hong@endlessm.com >
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-14-ville.syrjala@linux.intel.com
Tested-by: Daniel Drake <drake@endlessm.com >
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2019-12-09 16:10:59 +02:00
Ville Syrjälä
07fd0df822
drm/i915/fbc: Wait for vblank after FBC disable on glk+
...
On glk+ the hardware gets confused if we disable FBC while
it's recompressing and we perform a plane update during the
same frame. The result is that top of the screen gets corrupted.
We can avoid that by giving the hardware enough time to finish
the FBC disable before we touch the plane registers. Ie. we need
an extra vblank wait after FBC disable.
v2: Don't do the vblank wait if we never activated FBC in hw
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191128150338.12490-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2019-12-09 16:10:58 +02:00
Ville Syrjälä
6252bb78fc
drm/i915/fbc: Start using flip nuke
...
The hardware automagically nukes the cfb on flip. We can use
that whenever the plane/crtc configuration doesn't change too
much. Let's hook that up.
We'll need this for glk+ since we need to introduce an extra
vblank wait after FBC disable. As we're currently disabling
FBC around all plane updates we'd slow them down by an extra
frame. Not a great user experience when your fps is always
capped at vrefres/2. With flip nuke we don't need the extra
vblank wait.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-12-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2019-12-09 16:10:58 +02:00
Ville Syrjälä
c866a0e416
drm/i915/fbc: Nuke fbc.enabled
...
fbc.enabled == (fbc.crtc != NULL), so let's just nuke fbc.enabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-11-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2019-12-09 16:10:58 +02:00
Ville Syrjälä
31ce20c247
drm/i915/fbc: s/gen9 && !glk/gen9_bc || bxt/
...
Replace the 'gen9 && !glk' with the slightly more obvious
'gen9_bc || bxt'.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-10-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2019-12-09 16:10:58 +02:00
Ville Syrjälä
30016696c2
drm/i915/fbc: Make fence_id optional for i965gm
...
i965gm no longer needs the fence for scanout so we should be
do what we do for ctg+ and only configure a fence for FBC
when we have one.
In theory this should do nothing atm on account of
intel_fbc_can_activate() requiring the fence, but since
we do this for g4x+ let's do it for i965gm as well. We
may want to relax the requirements at some point and allow
FBC without a fence.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-9-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2019-12-09 16:10:58 +02:00
Ville Syrjälä
97a978e2d3
drm/i915/fbc: Store fence_id directly in fbc cache/params
...
Rather than playing around with vma+flags let's just grab
the fence id from within and stash that directly in the fbc
cache/params.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-8-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2019-12-09 16:10:58 +02:00
Ville Syrjälä
8bdbe1befd
drm/i915/fbc: Track plane visibility
...
Currently the code (ab)uses cache->vma to indicate the plane
visibility. I want to nuke that so let's add a dedicated boolean
for this.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-7-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2019-12-09 16:10:58 +02:00
Ville Syrjälä
6f745ba696
drm/i915/fbc: Precompute gen9 cfb stride w/a
...
Precompute the override cfb stride value so that we can check
it when determining if flip nuke can be used or not.
The hardware has 13 bits for this, so we can shrink the storage
to u16 while at it.
v2: Don't explode when crtc_state->enable_fbc lies to us
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-6-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2019-12-09 16:10:58 +02:00
Ville Syrjälä
644398586f
drm/i915/fbc: Remove the FBC_RT_BASE setup for ILK/SNB
...
We don't want to use the FBC hardware render tracking so let's not
enable it. To use the hw tracking properly we'd anyway need to
integrate this into the command submissing path as the register is
context saved, and if rendering happens via the ppgtt we'd have
to configure it with the ppgtt address instead of the ggtt address.
Easier to use software tracking instead.
Note that on pre-ilk we can't actually disable render tracking.
However we can't rely on it because it requires that DSPSURF to
match the render target address, and since we play tricks
with DSPSURF that may not be the case. Hence we shall rely on
software render tracking on all platforms.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-5-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2019-12-09 16:10:58 +02:00
Ville Syrjälä
04da7b9f9a
drm/i915: Relocate intel_crtc_active()
...
Move intel_crtc_active() next to its only remaining
user (pre-g4x wm code).
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-4-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2019-12-09 16:10:58 +02:00
Ville Syrjälä
fb2d8e0cd4
drm/i915/fbc: Nuke bogus single pipe fbc1 restriction
...
Not sure where the single pipe only restriction came for fbc1.
Nothing I can see that would prevent this.
v2: Nuke no_fbc_on_multiple_pipes() too
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-3-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2019-12-09 16:10:58 +02:00
Ville Syrjälä
cd8c021b36
drm/i915/fbc: Disable fbc by default on all glk+
...
We're missing a workaround in the fbc code for all glk+ platforms
which can cause corruption around the top of the screen. So
enabling fbc by default is a bad idea. I'm not keen to backport
the w/a so let's start by disabling fbc by default on all glk+.
We'll lift the restriction once the w/a is in place.
Cc: stable@vger.kernel.org
Cc: Daniel Drake <drake@endlessm.com >
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com >
Cc: Jian-Hong Pan <jian-hong@endlessm.com >
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-2-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
2019-12-09 16:10:58 +02:00
Chris Wilson
36deeddcd3
drm/i915/gt: Save irqstate around virtual_context_destroy
...
As virtual_context_destroy() may be called from a request signal, it may
be called from inside an irq-off section, and so we need to do a full
save/restore of the irq state rather than blindly re-enable irqs upon
unlocking.
<4> [110.024262] WARNING: inconsistent lock state
<4> [110.024277] 5.4.0-rc8-CI-CI_DRM_7489+ #1 Tainted: G U
<4> [110.024292] --------------------------------
<4> [110.024305] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
<4> [110.024323] kworker/0:0/5 [HC0[0]:SC0[0]:HE1:SE1] takes:
<4> [110.024338] ffff88826a0c7a18 (&(&rq->lock)->rlock){?.-.}, at: i915_request_retire+0x221/0x930 [i915]
<4> [110.024592] {IN-HARDIRQ-W} state was registered at:
<4> [110.024612] lock_acquire+0xa7/0x1c0
<4> [110.024627] _raw_spin_lock_irqsave+0x33/0x50
<4> [110.024788] intel_engine_breadcrumbs_irq+0x38c/0x600 [i915]
<4> [110.024808] irq_work_run_list+0x49/0x70
<4> [110.024824] irq_work_run+0x26/0x50
<4> [110.024839] smp_irq_work_interrupt+0x44/0x1e0
<4> [110.024855] irq_work_interrupt+0xf/0x20
<4> [110.024871] __do_softirq+0xb7/0x47f
<4> [110.024885] irq_exit+0xba/0xc0
<4> [110.024898] do_IRQ+0x83/0x160
<4> [110.024910] ret_from_intr+0x0/0x1d
<4> [110.024922] irq event stamp: 172864
<4> [110.024938] hardirqs last enabled at (172863): [<ffffffff819ea214>] _raw_spin_unlock_irq+0x24/0x50
<4> [110.024963] hardirqs last disabled at (172864): [<ffffffff819e9fba>] _raw_spin_lock_irq+0xa/0x40
<4> [110.024988] softirqs last enabled at (172812): [<ffffffff81c00385>] __do_softirq+0x385/0x47f
<4> [110.025012] softirqs last disabled at (172797): [<ffffffff810b829a>] irq_exit+0xba/0xc0
<4> [110.025031]
other info that might help us debug this:
<4> [110.025049] Possible unsafe locking scenario:
<4> [110.025065] CPU0
<4> [110.025075] ----
<4> [110.025084] lock(&(&rq->lock)->rlock);
<4> [110.025099] <Interrupt>
<4> [110.025109] lock(&(&rq->lock)->rlock);
<4> [110.025124]
*** DEADLOCK ***
<4> [110.025144] 4 locks held by kworker/0:0/5:
<4> [110.025156] #0 : ffff88827588f528 ((wq_completion)events){+.+.}, at: process_one_work+0x1de/0x620
<4> [110.025187] #1 : ffffc9000006fe78 ((work_completion)(&engine->retire_work)){+.+.}, at: process_one_work+0x1de/0x620
<4> [110.025219] #2 : ffff88825605e270 (&kernel#2){+.+.}, at: engine_retire+0x57/0xe0 [i915]
<4> [110.025405] #3 : ffff88826a0c7a18 (&(&rq->lock)->rlock){?.-.}, at: i915_request_retire+0x221/0x930 [i915]
<4> [110.025634]
stack backtrace:
<4> [110.025653] CPU: 0 PID: 5 Comm: kworker/0:0 Tainted: G U 5.4.0-rc8-CI-CI_DRM_7489+ #1
<4> [110.025675] Hardware name: /NUC7i5BNB, BIOS BNKBL357.86A.0054.2017.1025.1822 10/25/2017
<4> [110.025856] Workqueue: events engine_retire [i915]
<4> [110.025872] Call Trace:
<4> [110.025891] dump_stack+0x71/0x9b
<4> [110.025907] mark_lock+0x49a/0x500
<4> [110.025926] ? print_shortest_lock_dependencies+0x200/0x200
<4> [110.025946] mark_held_locks+0x49/0x70
<4> [110.025962] ? _raw_spin_unlock_irq+0x24/0x50
<4> [110.025978] lockdep_hardirqs_on+0xa2/0x1c0
<4> [110.025995] _raw_spin_unlock_irq+0x24/0x50
<4> [110.026171] virtual_context_destroy+0xc5/0x2e0 [i915]
<4> [110.026376] __active_retire+0xb4/0x290 [i915]
<4> [110.026396] dma_fence_signal_locked+0x9e/0x1b0
<4> [110.026613] i915_request_retire+0x451/0x930 [i915]
<4> [110.026766] retire_requests+0x4d/0x60 [i915]
<4> [110.026919] engine_retire+0x63/0xe0 [i915]
Fixes: b1e3177bd16d06779e86chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191205145934.663183-1-chris@chris-wilson.co.uk
(cherry picked from commit 6f7ac82853joonas.lahtinen@linux.intel.com >
2019-12-09 16:00:48 +02:00
Umesh Nerlige Ramappa
ccdeed4970
drm/i915/perf: Configure OAR for specific context
...
Gen12 supports saving/restoring render counters per context. Apply OAR
configuration only for the context that is passed in to perf.
v2:
- Fix OACTXCONTROL value to only stop/resume counters.
- Remove gen12_update_reg_state_unlocked as power state is already
applied by the caller.
v3: (Lionel)
- Move register initialization into the array
- Assume a valid oa_config in enable_metric_set
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com >
Fixes: 00a7f0d715lionel.g.landwerlin@intel.com >
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191206194339.31356-2-umesh.nerlige.ramappa@intel.com
2019-12-09 15:38:17 +02:00
Umesh Nerlige Ramappa
322d56aa31
drm/i915/perf: Allow non-privileged access when OA buffer is not sampled
...
SAMPLE_OA_REPORT enables sampling of OA reports from the OA buffer.
Since reports from OA buffer had system wide visibility, collecting
samples from the OA buffer was a privileged operation on previous
platforms. Prior to TGL, it was also necessary to sample the OA buffer
to normalize reports from MI REPORT PERF COUNT.
TGL has a dedicated OAR unit to sample perf reports for a specific
render context. This removes the necessity to sample OA buffer.
- If not sampling the OA buffer, allow non-privileged access. An earlier
patch allows the non-privilege access:
https://patchwork.freedesktop.org/patch/337716/?series=68582&rev=1
- Clear up the path for non-privileged access in this patch
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com >
Fixes: 00a7f0d715lionel.g.landwerlin@intel.com >
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191206194339.31356-1-umesh.nerlige.ramappa@intel.com
2019-12-09 15:38:16 +02:00
Chris Wilson
d3e483526c
drm/i915: Change i915_vma_unbind() to report -EAGAIN on activity
...
If someone else acquires the i915_vma before we complete our wait and
unbind it, we currently error out with -EBUSY. Use -EAGAIN instead so
that if necessary the caller is prepared to try again.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/683
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Matthew Auld <matthew.auld@intel.com >
Reviewed-by: Matthew Auld <matthew.auld@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191208161252.3015727-2-chris@chris-wilson.co.uk
2019-12-09 11:49:57 +00:00
Chris Wilson
16c46fd505
drm/i915/gem: Avoid rcu_barrier() from shrinker paths
...
As i915_gem_object_unbind() waits on an rcu_barrier() to flush vm
releases (and destruction of their bound vma), we have to be careful not
to invoke that barrier from beneath the shrinker:
<4> [430.222671] WARNING: possible circular locking dependency detected
<4> [430.222673] 5.4.0-rc8-CI-CI_DRM_7508+ #1 Tainted: G U
<4> [430.222675] ------------------------------------------------------
<4> [430.222677] gem_pwrite/2317 is trying to acquire lock:
<4> [430.222678] ffffffff82248218 (rcu_state.barrier_mutex){+.+.}, at: rcu_barrier+0x23/0x190
<4> [430.222685]
but task is already holding lock:
<4> [430.222687] ffffffff82263a40 (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.117+0x0/0x30
<4> [430.222691]
which lock already depends on the new lock.
<4> [430.222693]
the existing dependency chain (in reverse order) is:
<4> [430.222695]
-> #2 (fs_reclaim){+.+.}:
<4> [430.222698] fs_reclaim_acquire.part.117+0x24/0x30
<4> [430.222702] kmem_cache_alloc_trace+0x2a/0x2c0
<4> [430.222705] intel_cpuc_prepare+0x37/0x1a0
<4> [430.222709] cpuhp_invoke_callback+0x9b/0x9d0
<4> [430.222712] _cpu_up+0xa2/0x140
<4> [430.222714] do_cpu_up+0x61/0xa0
<4> [430.222718] smp_init+0x57/0x96
<4> [430.222722] kernel_init_freeable+0xac/0x1c7
<4> [430.222725] kernel_init+0x5/0x100
<4> [430.222728] ret_from_fork+0x24/0x50
<4> [430.222729]
-> #1 (cpu_hotplug_lock.rw_sem){++++}:
<4> [430.222733] cpus_read_lock+0x34/0xd0
<4> [430.222734] rcu_barrier+0xaa/0x190
<4> [430.222736] kernel_init+0x21/0x100
<4> [430.222737] ret_from_fork+0x24/0x50
<4> [430.222739]
-> #0 (rcu_state.barrier_mutex){+.+.}:
<4> [430.222742] __lock_acquire+0x1328/0x15d0
<4> [430.222743] lock_acquire+0xa7/0x1c0
<4> [430.222746] __mutex_lock+0x9a/0x9d0
<4> [430.222747] rcu_barrier+0x23/0x190
<4> [430.222850] i915_gem_object_unbind+0x264/0x3d0 [i915]
<4> [430.222882] i915_gem_shrink+0x297/0x5f0 [i915]
<4> [430.222912] i915_gem_shrink_all+0x38/0x60 [i915]
<4> [430.222934] i915_drop_caches_set+0x1f0/0x240 [i915]
<4> [430.222938] simple_attr_write+0xb0/0xd0
<4> [430.222941] full_proxy_write+0x51/0x80
<4> [430.222943] vfs_write+0xb9/0x1d0
<4> [430.222944] ksys_write+0x9f/0xe0
<4> [430.222946] do_syscall_64+0x4f/0x210
<4> [430.222948] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [430.222950]
other info that might help us debug this:
<4> [430.222952] Chain exists of:
rcu_state.barrier_mutex --> cpu_hotplug_lock.rw_sem --> fs_reclaim
<4> [430.222955] Possible unsafe locking scenario:
<4> [430.222957] CPU0 CPU1
<4> [430.222958] ---- ----
<4> [430.222960] lock(fs_reclaim);
<4> [430.222961] lock(cpu_hotplug_lock.rw_sem);
<4> [430.222963] lock(fs_reclaim);
<4> [430.222964] lock(rcu_state.barrier_mutex);
<4> [430.222966]
*** DEADLOCK ***
<4> [430.222968] 3 locks held by gem_pwrite/2317:
<4> [430.222969] #0 : ffff88849e2d9408 (sb_writers#14){.+.+}, at: vfs_write+0x1a4/0x1d0
<4> [430.222973] #1 : ffff888496976db0 (&attr->mutex){+.+.}, at: simple_attr_write+0x36/0xd0
<4> [430.222976] #2 : ffffffff82263a40 (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.117+0x0/0x30
<4> [430.222980]
stack backtrace:
<4> [430.222982] CPU: 1 PID: 2317 Comm: gem_pwrite Tainted: G U 5.4.0-rc8-CI-CI_DRM_7508+ #1
<4> [430.222985] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.2321.A08.1909162051 09/16/2019
<4> [430.222989] Call Trace:
<4> [430.222992] dump_stack+0x71/0x9b
<4> [430.222995] check_noncircular+0x19b/0x1c0
<4> [430.222998] ? __lock_acquire+0x1328/0x15d0
<4> [430.222999] __lock_acquire+0x1328/0x15d0
<4> [430.223001] ? mark_held_locks+0x49/0x70
<4> [430.223003] lock_acquire+0xa7/0x1c0
<4> [430.223005] ? rcu_barrier+0x23/0x190
<4> [430.223008] __mutex_lock+0x9a/0x9d0
<4> [430.223009] ? rcu_barrier+0x23/0x190
<4> [430.223011] ? rcu_barrier+0x23/0x190
<4> [430.223013] ? find_held_lock+0x2d/0x90
<4> [430.223045] ? i915_gem_object_unbind+0x24a/0x3d0 [i915]
<4> [430.223048] ? rcu_barrier+0x23/0x190
<4> [430.223049] rcu_barrier+0x23/0x190
<4> [430.223081] i915_gem_object_unbind+0x264/0x3d0 [i915]
<4> [430.223119] i915_gem_shrink+0x297/0x5f0 [i915]
Closes: https://gitlab.freedesktop.org/drm/intel/issues/743
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Matthew Auld <matthew.auld@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191208161252.3015727-1-chris@chris-wilson.co.uk
2019-12-09 10:49:38 +00:00
Chris Wilson
7240497850
drm/i915: Flesh out device_info pretty printer
...
Include all the number fields for describing the GT, as well as the
current boolean flags, primarily for inclusion in error states.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Andi Shyti <andi.shyti@intel.com >
Reviewed-by: Andi Shyti <andi.shyti@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191207182937.2583002-1-chris@chris-wilson.co.uk
2019-12-09 09:58:51 +00:00
Chris Wilson
8d65859a4c
drm/i915/gem: Comment on inability to check args.pad for MMAP_OFFSET
...
Since we didn't check and insist that args.pad must be zero for MMAP_GTT
historically, we cannot insert a check now as old userspace may be
feeding in garbage. As such the lack of check is enshrined into the ABI,
so add a comment to remind us we cannot add the check later.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191207222644.2830129-1-chris@chris-wilson.co.uk
2019-12-09 09:57:57 +00:00
Boris Brezillon
f3fdbc721b
drm/bridge: Clarify the atomic enable/disable hooks semantics
...
The [pre_]enable/[post_]disable hooks are passed the old atomic state.
Update the doc and rename the arguments to make it clear.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com >
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191203141515.3597631-8-boris.brezillon@collabora.com
2019-12-09 10:08:56 +01:00
Boris Brezillon
05193dc381
drm/bridge: Make the bridge chain a double-linked list
...
So that each element in the chain can easily access its predecessor.
This will be needed to support bus format negotiation between elements
of the bridge chain.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com >
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com >
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191203141515.3597631-5-boris.brezillon@collabora.com
2019-12-09 10:03:01 +01:00
Boris Brezillon
35a61fe921
drm: Stop accessing encoder->bridge directly
...
We are about to replace the single-linked bridge list by a double-linked
one based on list.h, leading to the suppression of the encoder->bridge
field. But before we can do that we must provide a
drm_bridge_chain_get_first_bridge() bridge helper and patch all drivers
and core helpers to use it instead of directly accessing encoder->bridge.
Note that we still have 2 drivers (VC4 and Exynos) manipulating the
encoder->bridge field directly because they need to cut the bridge chain
in order to control the enable/disable sequence. This is definitely
not something we want to encourage, so let's keep those 2 oddities
around until we find a better solution.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com >
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191203141515.3597631-4-boris.brezillon@collabora.com
2019-12-09 10:02:45 +01:00
Boris Brezillon
fadf872d9d
drm/bridge: Introduce drm_bridge_get_next_bridge()
...
And use it in drivers accessing the bridge->next field directly.
This is part of our attempt to make the bridge chain a double-linked list
based on the generic list helpers.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com >
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com >
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191203141515.3597631-3-boris.brezillon@collabora.com
2019-12-09 10:02:22 +01:00
Boris Brezillon
ea099adfdf
drm/bridge: Rename bridge helpers targeting a bridge chain
...
Change the prefix of bridge helpers targeting a bridge chain from
drm_bridge_ to drm_bridge_chain_ to better reflect the fact that
the operation will happen on all elements of chain, starting at the
bridge passed in argument.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com >
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com >
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191203141515.3597631-2-boris.brezillon@collabora.com
2019-12-09 10:01:39 +01:00
Martin Blumenstingl
43cb86799f
drm: meson: venc: cvbs: fix CVBS mode matching
...
With commit 222ec1618cstable@vger.kernel.org >
Fixes: 222ec1618cbbbe775ec5martin.blumenstingl@googlemail.com >
Acked-by: Neil Armstrong <narmstrong@baylibre.com >
[narmstrong: squashed with drm: meson: venc: cvbs: deduplicate the meson_cvbs_mode lookup code]
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191208171832.1064772-3-martin.blumenstingl@googlemail.com
2019-12-09 08:30:13 +01:00
Dave Airlie
781d5eb4b4
Merge tag 'drm-misc-fixes-2019-11-25' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
...
- A fix for a memory leak in the dma-buf support
- One in mcde DSI support that leads to a pointer dereference
Signed-off-by: Dave Airlie <airlied@redhat.com >
From: Maxime Ripard <maxime@cerno.tech >
Link: https://patchwork.freedesktop.org/patch/msgid/20191125094336.GA14723@gilmour.lan
2019-12-09 17:13:19 +10:00
Yongqiang Niu
92c17f6043
drm/mediatek: Fix can't get component for external display plane.
...
The original logic is ok for primary display, but will not find out
component for external display.
For example, plane->index is 6 for external display, but there are only
2 layer nr in external display, and this condition will never happen:
if (plane->index < (count + mtk_ddp_comp_layer_nr(comp)))
Fix this by using the offset of the plane to mtk_crtc->planes as index,
instead of plane->index.
Fixes: d6b53f6835yongqiang.niu@mediatek.com >
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org >
Signed-off-by: CK Hu <ck.hu@mediatek.com >
2019-12-09 09:29:05 +08:00
Pi-Hsun Shih
13b0ba33d7
drm/mediatek: Check return value of mtk_drm_ddp_comp_for_plane.
...
The mtk_drm_ddp_comp_for_plane can return NULL, but the usage doesn't
check for it. Add check for it.
Fixes: d6b53f6835pihsun@chromium.org >
Signed-off-by: CK Hu <ck.hu@mediatek.com >
2019-12-09 09:29:05 +08:00
Chris Wilson
d634110007
drm/i915/gt: Turn vm off then on again for gen7 mm switch
...
"Have you tried switching it off and on again?"
Set the size of the mm to 0 to disable all PD cachelines, before
enabling the whole mm again. Let's see if that tricks the TLB into
reloading.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191208143648.2986669-1-chris@chris-wilson.co.uk
2019-12-08 15:19:02 +00:00
Chris Wilson
ca5930b181
drm/i915/gtt: Account for preallocation in asserts
...
Our asserts allow for the PDEs to be allocated concurrently, but we did
not account for the aliasing-ppgtt to be preallocated on top.
Testcase: igt/gem_ppgtt #bsw
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191207221453.2802627-1-chris@chris-wilson.co.uk
2019-12-07 23:59:19 +00:00
Chris Wilson
8b1c78e06e
drm/i915: Avoid calling i915_gem_object_unbind holding object lock
...
In the extreme case, we may wish to wait on an rcu-barrier to reap stale
vm to purge the last of the object bindings. However, we are not allowed
to use rcu_barrier() beneath the dma_resv (i.e. object) lock and do not
take lightly the prospect of unlocking a mutex deep in the bowels of the
routine. i915_gem_object_unbind() itself does not need the object lock,
and it turns out the callers do not need to the unbind as part of a
locked sequence around set-cache-level, so rearrange the code to avoid
taking the object lock in the callers.
<4> [186.816311] ======================================================
<4> [186.816313] WARNING: possible circular locking dependency detected
<4> [186.816316] 5.4.0-rc8-CI-CI_DRM_7486+ #1 Tainted: G U
<4> [186.816318] ------------------------------------------------------
<4> [186.816320] perf_pmu/1321 is trying to acquire lock:
<4> [186.816322] ffff88849487c4d8 (&mm->mmap_sem#2){++++}, at: __might_fault+0x39/0x90
<4> [186.816331]
but task is already holding lock:
<4> [186.816333] ffffe8ffffa05008 (&cpuctx_mutex){+.+.}, at: perf_event_ctx_lock_nested+0xa9/0x1b0
<4> [186.816339]
which lock already depends on the new lock.
<4> [186.816341]
the existing dependency chain (in reverse order) is:
<4> [186.816343]
-> #6 (&cpuctx_mutex){+.+.}:
<4> [186.816349] __mutex_lock+0x9a/0x9d0
<4> [186.816352] perf_event_init_cpu+0xa4/0x140
<4> [186.816357] perf_event_init+0x19d/0x1cd
<4> [186.816362] start_kernel+0x372/0x4f4
<4> [186.816365] secondary_startup_64+0xa4/0xb0
<4> [186.816381]
-> #5 (pmus_lock){+.+.}:
<4> [186.816385] __mutex_lock+0x9a/0x9d0
<4> [186.816387] perf_event_init_cpu+0x6b/0x140
<4> [186.816404] cpuhp_invoke_callback+0x9b/0x9d0
<4> [186.816406] _cpu_up+0xa2/0x140
<4> [186.816409] do_cpu_up+0x61/0xa0
<4> [186.816411] smp_init+0x57/0x96
<4> [186.816413] kernel_init_freeable+0xac/0x1c7
<4> [186.816416] kernel_init+0x5/0x100
<4> [186.816419] ret_from_fork+0x24/0x50
<4> [186.816421]
-> #4 (cpu_hotplug_lock.rw_sem){++++}:
<4> [186.816424] cpus_read_lock+0x34/0xd0
<4> [186.816427] rcu_barrier+0xaa/0x190
<4> [186.816429] kernel_init+0x21/0x100
<4> [186.816431] ret_from_fork+0x24/0x50
<4> [186.816433]
-> #3 (rcu_state.barrier_mutex){+.+.}:
<4> [186.816436] __mutex_lock+0x9a/0x9d0
<4> [186.816438] rcu_barrier+0x23/0x190
<4> [186.816502] i915_gem_object_unbind+0x3a6/0x400 [i915]
<4> [186.816537] i915_gem_object_set_cache_level+0x32/0x90 [i915]
<4> [186.816571] i915_gem_object_pin_to_display_plane+0x5d/0x160 [i915]
<4> [186.816612] intel_pin_and_fence_fb_obj+0x9e/0x200 [i915]
<4> [186.816679] intel_plane_pin_fb+0x3f/0xd0 [i915]
<4> [186.816717] intel_prepare_plane_fb+0x130/0x520 [i915]
<4> [186.816722] drm_atomic_helper_prepare_planes+0x85/0x110
<4> [186.816761] intel_atomic_commit+0xc6/0x350 [i915]
<4> [186.816764] drm_atomic_helper_update_plane+0xed/0x110
<4> [186.816768] setplane_internal+0x97/0x190
<4> [186.816770] drm_mode_setplane+0xcd/0x190
<4> [186.816773] drm_ioctl_kernel+0xa7/0xf0
<4> [186.816775] drm_ioctl+0x2e1/0x390
<4> [186.816778] do_vfs_ioctl+0xa0/0x6f0
<4> [186.816780] ksys_ioctl+0x35/0x60
<4> [186.816782] __x64_sys_ioctl+0x11/0x20
<4> [186.816785] do_syscall_64+0x4f/0x210
<4> [186.816787] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [186.816789]
-> #2 (reservation_ww_class_mutex){+.+.}:
<4> [186.816793] __ww_mutex_lock.constprop.15+0xc3/0x1090
<4> [186.816795] ww_mutex_lock+0x39/0x70
<4> [186.816798] dma_resv_lockdep+0x10e/0x1f7
<4> [186.816800] do_one_initcall+0x58/0x2ff
<4> [186.816802] kernel_init_freeable+0x137/0x1c7
<4> [186.816804] kernel_init+0x5/0x100
<4> [186.816806] ret_from_fork+0x24/0x50
<4> [186.816808]
-> #1 (reservation_ww_class_acquire){+.+.}:
<4> [186.816811] dma_resv_lockdep+0xec/0x1f7
<4> [186.816813] do_one_initcall+0x58/0x2ff
<4> [186.816815] kernel_init_freeable+0x137/0x1c7
<4> [186.816817] kernel_init+0x5/0x100
<4> [186.816819] ret_from_fork+0x24/0x50
<4> [186.816820]
-> #0 (&mm->mmap_sem#2){++++}:
<4> [186.816824] __lock_acquire+0x1328/0x15d0
<4> [186.816826] lock_acquire+0xa7/0x1c0
<4> [186.816828] __might_fault+0x63/0x90
<4> [186.816831] _copy_to_user+0x1e/0x80
<4> [186.816834] perf_read+0x200/0x2b0
<4> [186.816836] vfs_read+0x96/0x160
<4> [186.816838] ksys_read+0x9f/0xe0
<4> [186.816839] do_syscall_64+0x4f/0x210
<4> [186.816841] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [186.816843]
other info that might help us debug this:
<4> [186.816846] Chain exists of:
&mm->mmap_sem#2 --> pmus_lock --> &cpuctx_mutex
<4> [186.816849] Possible unsafe locking scenario:
<4> [186.816851] CPU0 CPU1
<4> [186.816853] ---- ----
<4> [186.816854] lock(&cpuctx_mutex);
<4> [186.816856] lock(pmus_lock);
<4> [186.816858] lock(&cpuctx_mutex);
<4> [186.816860] lock(&mm->mmap_sem#2);
<4> [186.816861]
*** DEADLOCK ***
Closes: https://gitlab.freedesktop.org/drm/intel/issues/728
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Andi Shyti <andi.shyti@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191206105527.1130413-5-chris@chris-wilson.co.uk
2019-12-07 19:27:36 +00:00
Matthew Brost
a22198a934
drm/i915/guc: Update uncore access path in flush_ggtt_writes
...
The preferred way to access the uncore is through the GT structure.
Update the GuC function, flush_ggtt_writes, to use this path.
Signed-off-by: Matthew Brost <matthew.brost@intel.com >
Signed-off-by: John Harrison <john.c.harrison@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20191207010033.24667-1-John.C.Harrison@Intel.com
2019-12-07 16:56:13 +00:00
Chris Wilson
aef8207992
drm/i915/gem: Pin gen6_ppgtt prior to constructing the request
...
All pinning must be done prior to i915_request_create, to avoid
timeline->mutex inversions.
Here we slightly abuse the context_barrier_task stages to utilise the
'skip' decision as an opportunity to acquire the pin on the new ppgtt.
Consider it s/skip/prepare/. At the moment, we only have on user of
context_barrier_task, so it might be worth breaking it down for the
specific task of set-vm and refactor it later if we find a second
purpose.
<4> [402.377487] WARNING: possible circular locking dependency detected
<4> [402.377493] 5.4.0-rc8-CI-CI_DRM_7491+ #1 Tainted: G U
<4> [402.377497] ------------------------------------------------------
<4> [402.377502] gem_exec_parall/2506 is trying to acquire lock:
<4> [402.377507] ffff888403cdac70 (&kernel#2){+.+.}, at: i915_request_create+0x16/0x1c0 [i915]
<4> [402.377593]
but task is already holding lock:
<4> [402.377597] ffff88835efad550 (&ppgtt->pin_mutex){+.+.}, at: gen6_ppgtt_pin+0x4d/0x110 [i915]
<4> [402.377660]
which lock already depends on the new lock.
<4> [402.377664]
the existing dependency chain (in reverse order) is:
<4> [402.377668]
-> #1 (&ppgtt->pin_mutex){+.+.}:
<4> [402.377674] __mutex_lock+0x9a/0x9d0
<4> [402.377713] gen6_ppgtt_pin+0x4d/0x110 [i915]
<4> [402.377756] emit_ppgtt_update+0x1dc/0x370 [i915]
<4> [402.377801] context_barrier_task+0x176/0x310 [i915]
<4> [402.377844] ctx_setparam+0x400/0xb10 [i915]
<4> [402.377886] i915_gem_context_setparam_ioctl+0xc8/0x160 [i915]
<4> [402.377891] drm_ioctl_kernel+0xa7/0xf0
<4> [402.377895] drm_ioctl+0x2e1/0x390
<4> [402.377899] do_vfs_ioctl+0xa0/0x6f0
<4> [402.377903] ksys_ioctl+0x35/0x60
<4> [402.377906] __x64_sys_ioctl+0x11/0x20
<4> [402.377910] do_syscall_64+0x4f/0x210
<4> [402.377914] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [402.377917]
-> #0 (&kernel#2){+.+.}:
<4> [402.377923] __lock_acquire+0x1328/0x15d0
<4> [402.377926] lock_acquire+0xa7/0x1c0
<4> [402.377930] __mutex_lock+0x9a/0x9d0
<4> [402.377977] i915_request_create+0x16/0x1c0 [i915]
<4> [402.378013] intel_engine_flush_barriers+0x4c/0x100 [i915]
<4> [402.378062] i915_ggtt_pin+0x7d/0x130 [i915]
<4> [402.378108] gen6_ppgtt_pin+0x9c/0x110 [i915]
<4> [402.378148] ring_context_pin+0x2e/0xc0 [i915]
<4> [402.378183] __intel_context_do_pin+0x6b/0x190 [i915]
<4> [402.378226] i915_gem_do_execbuffer+0x180c/0x26b0 [i915]
<4> [402.378268] i915_gem_execbuffer2_ioctl+0x11b/0x460 [i915]
<4> [402.378272] drm_ioctl_kernel+0xa7/0xf0
<4> [402.378275] drm_ioctl+0x2e1/0x390
<4> [402.378279] do_vfs_ioctl+0xa0/0x6f0
<4> [402.378282] ksys_ioctl+0x35/0x60
<4> [402.378286] __x64_sys_ioctl+0x11/0x20
<4> [402.378289] do_syscall_64+0x4f/0x210
<4> [402.378292] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [402.378295]
other info that might help us debug this:
<4> [402.378299] Possible unsafe locking scenario:
<4> [402.378302] CPU0 CPU1
<4> [402.378305] ---- ----
<4> [402.378307] lock(&ppgtt->pin_mutex);
<4> [402.378310] lock(&kernel#2);
<4> [402.378314] lock(&ppgtt->pin_mutex);
<4> [402.378317] lock(&kernel#2);
<4> [402.378320]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Andi Shyti <andi.shyti@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20191206105527.1130413-4-chris@chris-wilson.co.uk
2019-12-06 23:38:54 +00:00
