<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/gpu/drm/i915/intel_fbdev.c, branch linux-5.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2019-04-24T00:47:56Z</updated>
<entry>
<title>Revert "drm/i915/fbdev: Actually configure untiled displays"</title>
<updated>2019-04-24T00:47:56Z</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2019-04-24T00:47:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9fa246256e09dc30820524401cdbeeaadee94025'/>
<id>urn:sha1:9fa246256e09dc30820524401cdbeeaadee94025</id>
<content type='text'>
This reverts commit d179b88deb3bf6fed4991a31fd6f0f2cad21fab5.

This commit is documented to break userspace X.org modesetting driver in certain configurations.

The X.org modesetting userspace driver is broken. No fixes are available yet. In order for this patch to be applied it either needs a config option or a workaround developed.

This has been reported a few times, saying it's a userspace problem is clearly against the regression rules.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109806
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v3.19+
</content>
</entry>
<entry>
<title>Merge v5.0 into drm-next</title>
<updated>2019-03-04T02:02:55Z</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2019-03-04T02:02:55Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2c3cd66f4c66b169c18a2dbebbc894681d282278'/>
<id>urn:sha1:2c3cd66f4c66b169c18a2dbebbc894681d282278</id>
<content type='text'>
There is a really hairy resolution involving amdgpu fixes, that I'd rather confirm here.

Also some misc fixes are landed by me, but the pr has them as well.

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/fbdev: Actually configure untiled displays</title>
<updated>2019-02-20T14:02:55Z</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2019-02-15T12:30:19Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d179b88deb3bf6fed4991a31fd6f0f2cad21fab5'/>
<id>urn:sha1:d179b88deb3bf6fed4991a31fd6f0f2cad21fab5</id>
<content type='text'>
If we skipped all the connectors that were not part of a tile, we would
leave conn_seq=0 and conn_configured=0, convincing ourselves that we
had stagnated in our configuration attempts. Avoid this situation by
starting conn_seq=ALL_CONNECTORS, and repeating until we find no more
connectors to configure.

Fixes: 754a76591b12 ("drm/i915/fbdev: Stop repeating tile configuration on stagnation")
Reported-by: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Reviewed-by: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190215123019.32283-1-chris@chris-wilson.co.uk
Cc: &lt;stable@vger.kernel.org&gt; # v3.19+
(cherry picked from commit d9b308b1f8a1acc0c3279f443d4fe0f9f663252e)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915: Block fbdev HPD processing during suspend</title>
<updated>2019-02-12T13:37:32Z</updated>
<author>
<name>Lyude Paul</name>
<email>lyude@redhat.com</email>
</author>
<published>2019-01-29T19:09:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e8a8fedd57fdcebf0e4f24ef0fc7e29323df8e66'/>
<id>urn:sha1:e8a8fedd57fdcebf0e4f24ef0fc7e29323df8e66</id>
<content type='text'>
When resuming, we check whether or not any previously connected
MST topologies are still present and if so, attempt to resume them. If
this fails, we disable said MST topologies and fire off a hotplug event
so that userspace knows to reprobe.

However, sending a hotplug event involves calling
drm_fb_helper_hotplug_event(), which in turn results in fbcon doing a
connector reprobe in the caller's thread - something we can't do at the
point in which i915 calls drm_dp_mst_topology_mgr_resume() since
hotplugging hasn't been fully initialized yet.

This currently causes some rather subtle but fatal issues. For example,
on my T480s the laptop dock connected to it usually disappears during a
suspend cycle, and comes back up a short while after the system has been
resumed. This guarantees pretty much every suspend and resume cycle,
drm_dp_mst_topology_mgr_set_mst(mgr, false); will be caused and in turn,
a connector hotplug will occur. Now it's Rute Goldberg time: when the
connector hotplug occurs, i915 reprobes /all/ of the connectors,
including eDP. However, eDP probing requires that we power on the panel
VDD which in turn, grabs a wakeref to the appropriate power domain on
the GPU (on my T480s, this is the PORT_DDI_A_IO domain). This is where
things start breaking, since this all happens before
intel_power_domains_enable() is called we end up leaking the wakeref
that was acquired and never releasing it later. Come next suspend/resume
cycle, this causes us to fail to shut down the GPU properly, which
causes it not to resume properly and die a horrible complicated death.

(as a note: this only happens when there's both an eDP panel and MST
topology connected which is removed mid-suspend. One or the other seems
to always be OK).

We could try to fix the VDD wakeref leak, but this doesn't seem like
it's worth it at all since we aren't able to handle hotplug detection
while resuming anyway. So, let's go with a more robust solution inspired
by nouveau: block fbdev from handling hotplug events until we resume
fbdev. This allows us to still send sysfs hotplug events to be handled
later by user space while we're resuming, while also preventing us from
actually processing any hotplug events we receive until it's safe.

This fixes the wakeref leak observed on the T480s and as such, also
fixes suspend/resume with MST topologies connected on this machine.

Changes since v2:
* Don't call drm_fb_helper_hotplug_event() under lock, do it after lock
  (Chris Wilson)
* Don't call drm_fb_helper_hotplug_event() in
  intel_fbdev_output_poll_changed() under lock (Chris Wilson)
* Always set ifbdev-&gt;hpd_waiting (Chris Wilson)

Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: Todd Previte &lt;tprevite@gmail.com&gt;
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: Jani Nikula &lt;jani.nikula@linux.intel.com&gt;
Cc: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Cc: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Cc: Imre Deak &lt;imre.deak@intel.com&gt;
Cc: intel-gfx@lists.freedesktop.org
Cc: &lt;stable@vger.kernel.org&gt; # v3.17+
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190129191001.442-2-lyude@redhat.com
(cherry picked from commit fe5ec65668cdaa4348631d8ce1766eed43b33c10)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'drm-intel-next-2019-02-07' of git://anongit.freedesktop.org/drm/drm-intel into drm-next</title>
<updated>2019-02-11T03:41:59Z</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2019-02-11T03:41:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5ea3998d56346975c2701df18fb5b6e3ab5c8d9e'/>
<id>urn:sha1:5ea3998d56346975c2701df18fb5b6e3ab5c8d9e</id>
<content type='text'>
UAPI Changes:

- Expose RPCS (SSEU) configuration to userspace for Ice Lake
in order to allow userspace to reconfigure the subslice config
per context basis. (Tvrtko, Lionel)

Driver Changes:

- Execbuf and preemption improvements including selftests (Chris)
- Rename HAS_GMCH_DISPLAY/HAS_GMCH (Rodrigo)
- Debugfs error handling fix for robustness (Greg)
- Improve reg_rw traces (Ville)
- Push clear_intel_crtc_state onto the heap (Chris)
- Watermark fixes for Ice Lake (Ville)
- Fix enable count array size and bounds checking (Tvrtko)
- MST Fixes (Lyude)
- Prevent race and handle error on I915_GEM_MMAP (Joonas)
- Initial rework for an full atomic gamma mode (Ville)

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;

From: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190208165000.GA30314@intel.com
</content>
</entry>
<entry>
<title>drm/i915: Block fbdev HPD processing during suspend</title>
<updated>2019-02-06T19:54:25Z</updated>
<author>
<name>Lyude Paul</name>
<email>lyude@redhat.com</email>
</author>
<published>2019-01-29T19:09:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fe5ec65668cdaa4348631d8ce1766eed43b33c10'/>
<id>urn:sha1:fe5ec65668cdaa4348631d8ce1766eed43b33c10</id>
<content type='text'>
When resuming, we check whether or not any previously connected
MST topologies are still present and if so, attempt to resume them. If
this fails, we disable said MST topologies and fire off a hotplug event
so that userspace knows to reprobe.

However, sending a hotplug event involves calling
drm_fb_helper_hotplug_event(), which in turn results in fbcon doing a
connector reprobe in the caller's thread - something we can't do at the
point in which i915 calls drm_dp_mst_topology_mgr_resume() since
hotplugging hasn't been fully initialized yet.

This currently causes some rather subtle but fatal issues. For example,
on my T480s the laptop dock connected to it usually disappears during a
suspend cycle, and comes back up a short while after the system has been
resumed. This guarantees pretty much every suspend and resume cycle,
drm_dp_mst_topology_mgr_set_mst(mgr, false); will be caused and in turn,
a connector hotplug will occur. Now it's Rute Goldberg time: when the
connector hotplug occurs, i915 reprobes /all/ of the connectors,
including eDP. However, eDP probing requires that we power on the panel
VDD which in turn, grabs a wakeref to the appropriate power domain on
the GPU (on my T480s, this is the PORT_DDI_A_IO domain). This is where
things start breaking, since this all happens before
intel_power_domains_enable() is called we end up leaking the wakeref
that was acquired and never releasing it later. Come next suspend/resume
cycle, this causes us to fail to shut down the GPU properly, which
causes it not to resume properly and die a horrible complicated death.

(as a note: this only happens when there's both an eDP panel and MST
topology connected which is removed mid-suspend. One or the other seems
to always be OK).

We could try to fix the VDD wakeref leak, but this doesn't seem like
it's worth it at all since we aren't able to handle hotplug detection
while resuming anyway. So, let's go with a more robust solution inspired
by nouveau: block fbdev from handling hotplug events until we resume
fbdev. This allows us to still send sysfs hotplug events to be handled
later by user space while we're resuming, while also preventing us from
actually processing any hotplug events we receive until it's safe.

This fixes the wakeref leak observed on the T480s and as such, also
fixes suspend/resume with MST topologies connected on this machine.

Changes since v2:
* Don't call drm_fb_helper_hotplug_event() under lock, do it after lock
  (Chris Wilson)
* Don't call drm_fb_helper_hotplug_event() in
  intel_fbdev_output_poll_changed() under lock (Chris Wilson)
* Always set ifbdev-&gt;hpd_waiting (Chris Wilson)

Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: Todd Previte &lt;tprevite@gmail.com&gt;
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: Jani Nikula &lt;jani.nikula@linux.intel.com&gt;
Cc: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Cc: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Cc: Imre Deak &lt;imre.deak@intel.com&gt;
Cc: intel-gfx@lists.freedesktop.org
Cc: &lt;stable@vger.kernel.org&gt; # v3.17+
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190129191001.442-2-lyude@redhat.com
</content>
</entry>
<entry>
<title>Merge tag 'drm-misc-next-2019-02-01' of git://anongit.freedesktop.org/drm/drm-misc into drm-next</title>
<updated>2019-02-04T04:42:34Z</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2019-02-04T04:42:25Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=37fdaa3390cf3e0fde96941799543e85ea58f6ae'/>
<id>urn:sha1:37fdaa3390cf3e0fde96941799543e85ea58f6ae</id>
<content type='text'>
drm-misc-next for 5.1:

UAPI Changes:

Cross-subsystem Changes:

Core Changes:
  - Split out some part of drm_crtc_helper.h into drm_probe_helper.h
  - DRIVER_* flags improvements
  - New tasks on the TODO-list
  - Improvements to the documentation

Driver Changes:
  - Continual of drmP.h removal in multiple drivers
  - Removal of FBINFO_(FLAG_)DEFAULT in multiple drivers
  - sun4i: Addition of the A23 support, multiple fixes for the tiled
    formats
  - atmel-hlcdc: Fix of clipping and rotation properties
  - qxl: various BO-related improvements, prime and generic fbdev emulation
    support
  - dw-hdmi: Support for HDMI2.0 2160p modes and YUV420 output
  - New Sitronix ST7701 panel driver
  - New Kingdisplay KD097D04 panel driver
  - New LeMaker BL035-RGB-002 panel driver
  - New PDA 91-00156-A0 panel driver

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;

From: Maxime Ripard &lt;maxime.ripard@bootlin.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190201144749.t3abxvguhstu6bcl@flea
</content>
</entry>
<entry>
<title>drm: Split out drm_probe_helper.h</title>
<updated>2019-01-24T12:20:42Z</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2019-01-17T21:03:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fcd70cd36b9bf697122538c9e38e8cf954b2342b'/>
<id>urn:sha1:fcd70cd36b9bf697122538c9e38e8cf954b2342b</id>
<content type='text'>
Having the probe helper stuff (which pretty much everyone needs) in
the drm_crtc_helper.h file (which atomic drivers should never need) is
confusing. Split them out.

To make sure I actually achieved the goal here I went through all
drivers. And indeed, all atomic drivers are now free of
drm_crtc_helper.h includes.

v2: Make it compile. There was so much compile fail on arm drivers
that I figured I'll better not include any of the acks on v1.

v3: Massive rebase because i915 has lost a lot of drmP.h includes, but
not all: Through drm_crtc_helper.h &gt; drm_modeset_helper.h -&gt; drmP.h
there was still one, which this patch largely removes. Which means
rolling out lots more includes all over.

This will also conflict with ongoing drmP.h cleanup by others I
expect.

v3: Rebase on top of atomic bochs.

v4: Review from Laurent for bridge/rcar/omap/shmob/core bits:
- (re)move some of the added includes, use the better include files in
  other places (all suggested from Laurent adopted unchanged).
- sort alphabetically

v5: Actually try to sort them, and while at it, sort all the ones I
touch.

v6: Rebase onto i915 changes.

v7: Rebase once more.

Acked-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Acked-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Cc: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Cc: Jani Nikula &lt;jani.nikula@linux.intel.com&gt;
Cc: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Acked-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Acked-by: Benjamin Gaignard &lt;benjamin.gaignard@linaro.org&gt;
Acked-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Acked-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Acked-by: Oleksandr Andrushchenko &lt;oleksandr_andrushchenko@epam.com&gt;
Acked-by: CK Hu &lt;ck.hu@mediatek.com&gt;
Acked-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Acked-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Acked-by: Liviu Dudau &lt;liviu.dudau@arm.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@intel.com&gt;
Cc: linux-arm-kernel@lists.infradead.org
Cc: virtualization@lists.linux-foundation.org
Cc: etnaviv@lists.freedesktop.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: intel-gfx@lists.freedesktop.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: spice-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-tegra@vger.kernel.org
Cc: xen-devel@lists.xen.org
Link: https://patchwork.freedesktop.org/patch/msgid/20190117210334.13234-1-daniel.vetter@ffwll.ch
</content>
</entry>
<entry>
<title>drm/i915/fb: Track rpm wakerefs</title>
<updated>2019-01-14T16:18:16Z</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2019-01-14T14:21:19Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1d264d91befc3131e68edc225fa49acb2f315f73'/>
<id>urn:sha1:1d264d91befc3131e68edc225fa49acb2f315f73</id>
<content type='text'>
Keep track of the rpm wakeref used for framebuffer access so that we can
cancel upon release and so more clearly identify leaks.

Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Jani Nikula &lt;jani.nikula@intel.com&gt;
Reviewed-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-11-chris@chris-wilson.co.uk
</content>
</entry>
<entry>
<title>drm/i915: Markup paired operations on wakerefs</title>
<updated>2019-01-14T16:17:53Z</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2019-01-14T14:21:10Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=16e4dd0342a804090fd0958bb271d3a6b57056ac'/>
<id>urn:sha1:16e4dd0342a804090fd0958bb271d3a6b57056ac</id>
<content type='text'>
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get functions to their rpm_put counterpart. This
makes the pairing explicit, and given the required wakeref cookie the
compiler can verify that we pass an initialised value to the rpm_put
(quite handy for double checking error paths).

For regular builds, the compiler should be able to eliminate the unused
local variables and the program growth should be minimal. Fwiw, it came
out as a net improvement as gcc was able to refactor rpm_get and
rpm_get_if_in_use together,

v2: Just s/rpm_put/rpm_put_unchecked/ everywhere, leaving the manual
mark up for smaller more targeted patches.
v3: Mention the cookie in Returns

Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Jani Nikula &lt;jani.nikula@intel.com&gt;
Cc: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Reviewed-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-2-chris@chris-wilson.co.uk
</content>
</entry>
</feed>
