<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/gpu, branch linux-4.15.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.15.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.15.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2018-04-19T06:55:07Z</updated>
<entry>
<title>drm/i915/edp: Do not do link training fallback or prune modes on EDP</title>
<updated>2018-04-19T06:55:07Z</updated>
<author>
<name>Manasi Navare</name>
<email>manasi.d.navare@intel.com</email>
</author>
<published>2017-10-12T19:13:38Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7b3f3fa2bdeb7c2e240dac86561da10160b22f86'/>
<id>urn:sha1:7b3f3fa2bdeb7c2e240dac86561da10160b22f86</id>
<content type='text'>
commit a306343bcd7df89d9d45a601929e26866e7b7a81 upstream.

In case of eDP because the panel has a fixed mode, the link rate
and lane count at which it is trained corresponds to the link BW
required to support the native resolution of the panel. In case of
panles with lower resolutions where fewer lanes are hooked up internally,
that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
So it is pointless to fallback to lower link rate/lane count in case
of link training failure on eDP connector since the lower link BW
will not support the native resolution of the panel and we cannot
prune the preferred mode on the eDP connector.

In case of Link training failure on the eDP panel, something is wrong
in the HW internally and hence driver errors out with a loud
and clear DRM_ERROR message.

v2:
* Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)

Cc: Clinton Taylor &lt;clinton.a.taylor@intel.com&gt;
Cc: Jim Bride &lt;jim.bride@linux.intel.com&gt;
Cc: Jani Nikula &lt;jani.nikula@linux.intel.com&gt;
Cc: Ville Syrjala &lt;ville.syrjala@linux.intel.com&gt;
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Manasi Navare &lt;manasi.d.navare@intel.com&gt;
Reviewed-by: Ville Syrjala &lt;ville.syrjala@linux.intel.com&gt;
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=103369
Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/1507835618-23051-1-git-send-email-manasi.d.navare@intel.com
(cherry picked from commit c0cfb10d9e1de490e36d3b9d4228c0ea0ca30677)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915/cnp: Properly handle VBT ddc pin out of bounds.</title>
<updated>2018-04-12T10:31:14Z</updated>
<author>
<name>Rodrigo Vivi</name>
<email>rodrigo.vivi@intel.com</email>
</author>
<published>2018-01-25T22:25:24Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d3839c26e68deb3dc946796bd16cb58e714e3f5e'/>
<id>urn:sha1:d3839c26e68deb3dc946796bd16cb58e714e3f5e</id>
<content type='text'>
commit 6e3322c226f15bc1838007f5a75566f1482b8e40 upstream.

If the table result is out of bounds on the array map
there is something really wrong with VBT pin so we don't
return that vbt_pin, but only return 0 instead.

This basically reverts commit 'a8e6f3888b05 ("drm/i915/cnp:
Ignore VBT request for know invalid DDC pin.")'

Also this properly fixes commit 9c3b2689d01f ("drm/i915/cnl:
Map VBT DDC Pin to BSpec DDC Pin.")

v2: Do in a way that we don't break other platforms. (Jani)

v3: Keep debug message (Jani)

v4: Don't mess with 0 mapping was noticed by Jani and
    addressed with a simple solution suggested by Lucas
    that makes this even simpler.

Fixes: a8e6f3888b05 ("drm/i915/cnp: Ignore VBT request for know invalid DDC pin.")
Fixes: 9c3b2689d01f ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.")
Cc: Radhakrishna Sripada &lt;radhakrishna.sripada@intel.com&gt;
Cc: Jani Nikula &lt;jani.nikula@intel.com&gt;
Cc: Kai Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Cc: Lucas De Marchi &lt;lucas.demarchi@intel.com&gt;
Suggested-by: Lucas De Marchi &lt;lucas.demarchi@intel.com&gt;
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Reviewed-by: Lucas De Marchi &lt;lucas.demarchi@intel.com&gt;
Tested-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180125222524.22059-1-rodrigo.vivi@intel.com
(cherry picked from commit 3393ce1ed8fc43dbdb83952facaf04e644ca1d54)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915/cnp: Ignore VBT request for know invalid DDC pin.</title>
<updated>2018-04-12T10:31:13Z</updated>
<author>
<name>Rodrigo Vivi</name>
<email>rodrigo.vivi@intel.com</email>
</author>
<published>2018-01-23T17:40:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1710c3baec145592701009a19a1bcdaee3adfdea'/>
<id>urn:sha1:1710c3baec145592701009a19a1bcdaee3adfdea</id>
<content type='text'>
commit f24c606c21a8cb6f75adc20edcd80b6d851991bf upstream.

Let's ignore VBT request if the pin is clearly wrong.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104139
Cc: Kai Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180123174050.4261-1-rodrigo.vivi@intel.com
Reviewed-by: Radhakrishna Sripada &lt;radhakrishna.sripada@intel.com&gt;
(cherry picked from commit a8e6f3888b05c1e7b685800a3371ce050720368f)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/amd/powerplay: fix memory leakage when reload (v2)</title>
<updated>2018-04-12T10:31:12Z</updated>
<author>
<name>Yintian Tao</name>
<email>yttao@amd.com</email>
</author>
<published>2018-01-04T03:45:23Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b2320552d1f538bc7d6ac74e899a8ab4bb2a82d4'/>
<id>urn:sha1:b2320552d1f538bc7d6ac74e899a8ab4bb2a82d4</id>
<content type='text'>
[ Upstream commit a25513e7b9b15c318ec44113682e988829aef746 ]

add smu_free_memory when smu fini to prevent memory leakage

v2: squash in typo fix (Yintian) and warning (Harry)

Signed-off-by: Yintian Tao &lt;yttao@amd.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/msm: Fix NULL deref in adreno_load_gpu</title>
<updated>2018-04-12T10:31:05Z</updated>
<author>
<name>Archit Taneja</name>
<email>architt@codeaurora.org</email>
</author>
<published>2017-12-22T10:11:13Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3ca14535c781c54b25b0e786c43fefe12b58f14b'/>
<id>urn:sha1:3ca14535c781c54b25b0e786c43fefe12b58f14b</id>
<content type='text'>
[ Upstream commit 9dcfbc182f1aac0aa5ea194733d21e67dd2ba1fd ]

The msm/kms driver should work even if there is no GPU device specified
in DT. Currently, we get a NULL dereference crash in adreno_load_gpu
since the driver assumes that priv-&gt;gpu_pdev is non-NULL.

Perform an additional check on priv-&gt;gpu_pdev before trying to retrieve
the msm_gpu pointer from it.

v2: Incorporate Jordan's comments:
- Simplify the check to share the same error message.
- Use dev_err_once() to avoid an error message every time we open the
  drm device fd.

Fixes: eec874ce5ff1 (drm/msm/adreno: load gpu at probe/bind time)

Signed-off-by: Archit Taneja &lt;architt@codeaurora.org&gt;
Acked-by: Jordan Crouse &lt;jcrouse@codeaurora.org&gt;
Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>clk: divider: fix incorrect usage of container_of</title>
<updated>2018-04-12T10:31:03Z</updated>
<author>
<name>Jerome Brunet</name>
<email>jbrunet@baylibre.com</email>
</author>
<published>2017-12-21T16:30:54Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=34e1b76c57d0d088fa3a8c1128296f982b225015'/>
<id>urn:sha1:34e1b76c57d0d088fa3a8c1128296f982b225015</id>
<content type='text'>
[ Upstream commit 12a26c298d2a8b1cab498533fa65198e49e3afd3 ]

divider_recalc_rate() is an helper function used by clock divider of
different types, so the structure containing the 'hw' pointer is not
always a 'struct clk_divider'

At the following line:
&gt; div = _get_div(table, val, flags, divider-&gt;width);

in several cases, the value of 'divider-&gt;width' is garbage as the actual
structure behind this memory is not a 'struct clk_divider'

Fortunately, this width value is used by _get_val() only when
CLK_DIVIDER_MAX_AT_ZERO flag is set. This has never been the case so
far when the structure is not a 'struct clk_divider'. This is probably
why we did not notice this bug before

Fixes: afe76c8fd030 ("clk: allow a clk divider with max divisor when zero")
Signed-off-by: Jerome Brunet &lt;jbrunet@baylibre.com&gt;
Acked-by: Alexandre Belloni &lt;alexandre.belloni@free-electrons.com&gt;
Acked-by: Sylvain Lemieux &lt;slemieux.tyco@gmail.com&gt;
Signed-off-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.</title>
<updated>2018-04-08T12:27:36Z</updated>
<author>
<name>Dhinakaran Pandiyan</name>
<email>dhinakaran.pandiyan@intel.com</email>
</author>
<published>2018-03-14T05:48:25Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7b2dcf7cc45609dbfc2dde7d501d2694093928a9'/>
<id>urn:sha1:7b2dcf7cc45609dbfc2dde7d501d2694093928a9</id>
<content type='text'>
commit b1e314462bba76660eec62760bb2e87f28f58866 upstream.

If bios sets up an MST output and hardware state readout code sees this is
an SST configuration, when disabling the encoder we end up calling
-&gt;post_disable_dp() hook instead of the MST version. Consequently, we write
to the DP_SET_POWER dpcd to set it D3 state. Further along when we try
enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up
the MST hub. This results in continuous link training failures which keep
the system busy delaying boot. We could identify bios MST boot discrepancy
and handle it accordingly but a simple way to solve this is to write to the
DP_SET_POWER dpcd for MST too.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470
Cc: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Cc: Jani Nikula &lt;jani.nikula@intel.com&gt;
Reviewed-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Reported-by: Laura Abbott &lt;labbott@redhat.com&gt;
Cc: stable@vger.kernel.org
Fixes: 5ea2355a100a ("drm/i915/mst: Use MST sideband message transactions for dpms control")
Tested-by: Laura Abbott &lt;labbott@redhat.com&gt;
Signed-off-by: Dhinakaran Pandiyan &lt;dhinakaran.pandiyan@intel.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180314054825.1718-1-dhinakaran.pandiyan@intel.com
(cherry picked from commit ad260ab32a4d94fa974f58262f8000472d34fd5b)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Dhinakaran Pandiyan &lt;dhinakaran.pandiyan@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm: udl: Properly check framebuffer mmap offsets</title>
<updated>2018-03-28T16:23:00Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2018-03-21T15:45:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=01592437b0ec953300acf8be765721a62e0786b7'/>
<id>urn:sha1:01592437b0ec953300acf8be765721a62e0786b7</id>
<content type='text'>
commit 3b82a4db8eaccce735dffd50b4d4e1578099b8e8 upstream.

The memmap options sent to the udl framebuffer driver were not being
checked for all sets of possible crazy values.  Fix this up by properly
bounding the allowed values.

Reported-by: Eyal Itkin &lt;eyalit@checkpoint.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180321154553.GA18454@kroah.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm: Reject getfb for multi-plane framebuffers</title>
<updated>2018-03-28T16:22:59Z</updated>
<author>
<name>Daniel Stone</name>
<email>daniels@collabora.com</email>
</author>
<published>2018-03-20T22:58:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1554edbbb723218abc57bafb24a0c32102a1ba89'/>
<id>urn:sha1:1554edbbb723218abc57bafb24a0c32102a1ba89</id>
<content type='text'>
commit b24791fe00f8b089d5b10cb7bcc4e1ae88b4831b upstream.

getfb can only return a single plane, so reject attempts to use it with
multi-plane framebuffers.

Signed-off-by: Daniel Stone &lt;daniels@collabora.com&gt;
Reported-by: Daniel van Vugt &lt;daniel.van.vugt@canonical.com&gt;
Reviewed-by: Rob Clark &lt;robdclark@gmail.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Fixes: 308e5bcbdb10 ("drm: add an fb creation ioctl that takes a pixel format v5")
Cc: stable@vger.kernel.org # v3.3+
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105518
Link: https://patchwork.freedesktop.org/patch/msgid/20180320225839.30905-1-daniels@collabora.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/amd/display: Add one to EDID's audio channel count when passing to DC</title>
<updated>2018-03-28T16:22:59Z</updated>
<author>
<name>Harry Wentland</name>
<email>harry.wentland@amd.com</email>
</author>
<published>2018-03-07T18:45:33Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f6b53a429e65b5a68a20001d339cd5d1a14230a8'/>
<id>urn:sha1:f6b53a429e65b5a68a20001d339cd5d1a14230a8</id>
<content type='text'>
commit 731a373698c9675d5aed8a30d8c9861bea9c41a2 upstream.

DC takes channel count to mean the actual count. cea_sad's channels
represent it as number of channels - 1.

Signed-off-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Reviewed-by: Tony Cheng &lt;Tony.Cheng@amd.com&gt;
Acked-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
