Skip to content

L
linux
Switch branch/tag
  1. 02 Nov, 2018 3 commits
  3. 01 Nov, 2018 6 commits
  5. 30 Oct, 2018 2 commits
  7. 29 Oct, 2018 7 commits
    • Douglas Anderson's avatar
      drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1 · 8f054b6f
      Douglas Anderson authored 
      As far as I can tell the panel that was added in commit da50bd42
("drm/panel: simple: Add Innolux TV123WAM panel driver support")
wasn't actually an Innolux TV123WAM but was actually an Innolux
P120ZDG-BF1.

As far as I can tell the Innolux TV123WAM isn't a real panel and but
it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
Let's unmosh.

Here's my evidence:

* Searching for TV123WAM on the Internet turns up a TI panel.  While
  it's possible that an Innolux panel has the same model number as the
  TI Panel, it seems a little doubtful.  Looking up the datasheet from
  the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.

* As far as I know, the patch adding the Innolux Panel was supposed to
  be for the board that's sitting in front of me as I type this
  (support for that board is not yet upstream).  On the back of that
  panel I see Innolux P120ZDZ-EZ1 rev B1.

* Someone pointed me at a datasheet that's supposed to be for the
  panel in front of me (sorry, I can't share the datasheet).  That
  datasheet has the string "p120zdg-bf1"

* If I search for "P120ZDG-BF1" on the Internet I get hits for panels
  that are 2160x1440.  They don't have datasheets, but the fact that
  the resolution matches is a good sign.

In any case, let's update the name and also the physical size to match
the correct panel.

Fixes: da50bd42 ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
Cc: Sandeep Panda <spanda@codeaurora.org>
Reviewed-by: default avatarAbhinav Kumar <abhinavk@codeaurora.org>
Reviewed-by: default avatarSean Paul <sean@poorly.run>
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-6-dianders@chromium.org
      8f054b6f
    • Douglas Anderson's avatar
      dt-bindings: drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1 · c0e9ab24
      Douglas Anderson authored 
      As far as I can tell the bindings that were added in commit
9c04400f ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
bindings") weren't actually for Innolux TV123WAM but were actually for
Innolux P120ZDG-BF1.

As far as I can tell the Innolux TV123WAM isn't a real panel and but
it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
Let's unmosh.

Here's my evidence:

* Searching for TV123WAM on the Internet turns up a TI panel.  While
  it's possible that an Innolux panel has the same model number as the
  TI Panel, it seems a little doubtful.  Looking up the datasheet from
  the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.

* As far as I know, the patch adding the Innolux Panel was supposed to
  be for the board that's sitting in front of me as I type this
  (support for that board is not yet upstream).  On the back of that
  panel I see Innolux P120ZDZ-EZ1 rev B1.

* Someone pointed me at a datasheet that's supposed to be for the
  panel in front of me (sorry, I can't share the datasheet).  That
  datasheet has the string "p120zdg-bf1"

* If I search for "P120ZDG-BF1" on the Internet I get hits for panels
  that are 2160x1440.  They don't have datasheets, but the fact that
  the resolution matches is a good sign.

While we doing the rename, also mention that no-hpd can be used with
this panel.  See the previous patch in this series ("drm/panel:
simple: Add "no-hpd" delay for Innolux TV123WAM").

Fixes: 9c04400f ("dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings")
Cc: Sandeep Panda <spanda@codeaurora.org>
Reviewed-by: default avatarRob Herring <robh@kernel.org>
Reviewed-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-5-dianders@chromium.org
      c0e9ab24
    • Douglas Anderson's avatar
      drm/bridge: ti-sn65dsi86: Remove the mystery delay · c2bfc223
      Douglas Anderson authored 
      Let's solve the mystery of commit bf1178c9 ("drm/bridge:
ti-sn65dsi86: Add mystery delay to enable()").  Specifically the
reason we needed that mystery delay is that we weren't paying
attention to HPD.

Looking at the datasheet for the same panel that was tested for the
original commit, I see there's a timing "t3" that times from power on
to the aux channel being operational.  This time is specced as 0 - 200
ms.  The datasheet says that the aux channel is operational at exactly
the same time that HPD is asserted.

Scoping the signals on this board showed that HPD was asserted 84 ms
after power was asserted.  That very closely matches the magic 70 ms
delay that we had.  ...and actually, in my testing the 70 ms wasn't
quite enough of a delay and some percentage of the time the display
didn't come up until I bumped it to 100 ms (presumably 84 ms would
have worked too).

To solve this, we tried to hook up the HPD signal in the bridge.
...but in doing so we found that that the bridge didn't report that
HPD was asserted until ~280 ms after we powered it (!).  This is
explained by looking at the sn65dsi86 datasheet section "8.4.5.1 HPD
(Hot Plug/Unplug Detection)".  Reading there we see that the bridge
isn't even intended to report HPD until 100 ms after it's asserted.
...but that would have left us at 184 ms.  The extra 100 ms
(presumably) comes from this part in the datasheet:

> The HPD state machine operates off an internal ring oscillator. The
> ring oscillator frequency will vary [ ... ]. The min/max range in
> the HPD State Diagram refers to the possible times based off
> variation in the ring oscillator frequency.

Given that the 280 ms we'll end up delaying if we hook up HPD is
_slower_ than the 200 ms we could just hardcode, for now we'll solve
the problem by just hardcoding a 200 ms delay in the panel driver
using the patch in this series ("drm/panel: simple: Support panels
with HPD where HPD isn't connected").

If we later find a panel that needs to use this bridge where we need
HPD then we'll have to come up with some new code to handle it.  Given
the silly debouncing in the bridge chip, though, it seems unlikely.

One last note is that I tried to solve this through another way: In
ti_sn_bridge_enable() I tried to use various combinations of
dp_dpcd_writeb() and dp_dpcd_readb() to detect when the aux channel
was up.  In theory that would let me detect _exactly_ when I could
continue and do link training.  Unfortunately even if I did an aux
transfer w/out waiting I couldn't see any errors.  Possibly I could
keep looping over link training until it came back with success, but
that seemed a little overly hacky to me.
Reviewed-by: default avatarSean Paul <sean@poorly.run>
Reviewed-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-4-dianders@chromium.org
      c2bfc223
    • Douglas Anderson's avatar
      drm/panel: simple: Add "no-hpd" delay for Innolux TV123WAM · 625d3b5c
      Douglas Anderson authored 
      If the HPD signal isn't hooked up to this panel we need a 200 ms
delay.  In the datasheet this is shown as the maximum time that HPD
will take to be asserted after power is given to the panel.
Reviewed-by: default avatarSean Paul <sean@poorly.run>
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-3-dianders@chromium.org
      625d3b5c
    • Douglas Anderson's avatar
      drm/panel: simple: Support panels with HPD where HPD isn't connected · 2ed3e951
      Douglas Anderson authored 
      Some eDP panels that are designed to be always connected to a board
use their HPD signal to signal that they've finished powering on and
they're ready to be talked to.

However, for various reasons it's possible that the HPD signal from
the panel isn't actually hooked up.  In the case where the HPD isn't
hooked up you can look at the timing diagram on the panel datasheet
and insert a delay for the maximum amount of time that the HPD might
take to come up.

Let's add support in simple-panel for this concept.

At the moment we will co-opt the existing "prepare" delay to keep
track of the delay and we'll use a boolean to specify that a given
panel should only apply the delay if the "no-hpd" property was
specified.
Reviewed-by: default avatarSean Paul <sean@poorly.run>
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-2-dianders@chromium.org
      2ed3e951
    • Douglas Anderson's avatar
      dt-bindings: drm/panel: simple: Add no-hpd property · cb028e49
      Douglas Anderson authored 
      Some eDP panels that are designed to be always connected to a board
use their HPD signal to signal that they've finished powering on and
they're ready to be talked to.

However, for various reasons it's possible that the HPD signal from
the panel isn't actually hooked up.  In the case where the HPD isn't
hooked up you can look at the timing diagram on the panel datasheet
and insert a delay for the maximum amount of time that the HPD might
take to come up.

Let's add a property in the device tree for this concept.
Reviewed-by: default avatarSean Paul <sean@poorly.run>
Reviewed-by: default avatarRob Herring <robh@kernel.org>
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-1-dianders@chromium.org
      cb028e49
    • Lee, Shawn C's avatar
      drm/edid: Add 6 bpc quirk for BOE panel. · 922dceff
      Lee, Shawn C authored 
      BOE panel (ID: 0x0771) that reports "DFP 1.x compliant TMDS".
But it's 6bpc panel only instead of 8 bpc.

Add panel ID to edid quirk list and set 6 bpc as default to
work around this issue.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Signed-off-by: default avatarLee, Shawn C <shawn.c.lee@intel.com&gt;>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1540792173-7288-1-git-send-email-shawn.c.lee@intel.com
      922dceff
  9. 26 Oct, 2018 3 commits
  11. 25 Oct, 2018 7 commits
  13. 24 Oct, 2018 2 commits
  15. 22 Oct, 2018 6 commits
  17. 19 Oct, 2018 4 commits
    • Lyude Paul's avatar
      drm/nouveau: Fix nv50_mstc->best_encoder() · 7b0f61e9
      Lyude Paul authored 
      As mentioned in the previous commit, we currently prevent new modesets
on recently-removed MST connectors by returning no encoder from our
->best_encoder() callback once the MST port has disappeared. This is
wrong however, because it prevents legacy modesetting users from being
able to disable CRTCs on MST connectors after the connector's respective
topology has disappeared.

So, fix this by instead by just always returning a valid encoder.

Changes since v2:
- Remove usage of atomic MST helper for now, since that got replaced
  with a much simpler solution
Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: default avatarBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-3-lyude@redhat.com
(cherry picked from commit e87b0bbc)
Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      7b0f61e9
    • Lyude Paul's avatar
      drm/atomic_helper: Stop modesets on unregistered connectors harder · de9f8eea
      Lyude Paul authored 
      Unfortunately, it appears our fix in:
commit b5d29843 ("drm/atomic_helper: Allow DPMS On<->Off changes
for unregistered connectors")

Which attempted to work around the problems introduced by:
commit 4d802739 ("drm/atomic_helper: Disallow new modesets on
unregistered connectors")

Is still not the right solution, as modesets can still be triggered
outside of drm_atomic_set_crtc_for_connector().

So in order to fix this, while still being careful that we don't break
modesets that a driver may perform before being registered with
userspace, we replace connector->registered with a tristate member,
connector->registration_state. This allows us to keep track of whether
or not a connector is still initializing and hasn't been exposed to
userspace, is currently registered and exposed to userspace, or has been
legitimately removed from the system after having once been present.

Using this info, we can prevent userspace from performing new modesets
on unregistered connectors while still allowing the driver to perform
modesets on unregistered connectors before the driver has finished being
registered.

Changes since v1:
- Fix WARN_ON() in drm_connector_cleanup() that CI caught with this
  patchset in igt@drv_module_reload@basic-reload-inject and
  igt@drv_module_reload@basic-reload by checking if the connector is
  registered instead of unregistered, as calling drm_connector_cleanup()
  on a connector that hasn't been registered with userspace yet should
  stay valid.
- Remove unregistered_connector_check(), and just go back to what we
  were doing before in commit 4d802739 ("drm/atomic_helper: Disallow
  new modesets on unregistered connectors") except replacing
  READ_ONCE(connector->registered) with drm_connector_is_unregistered().
  This gets rid of the behavior of allowing DPMS On<->Off, but that should
  be fine as it's more consistent with the UAPI we had before - danvet
- s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet
- Update documentation, fix some typos.

Fixes: b5d29843 ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
(cherry picked from commit 39b50c60)
Fixes: e9655095 ("drm/atomic_helper: Disallow new modesets on unregistered connectors")
Fixes: 34ca26a9 ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
Cc: stable@vger.kernel.org
Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      de9f8eea
    • Lyude Paul's avatar
      drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors · 34ca26a9
      Lyude Paul authored 
      It appears when testing my previous fix for some of the legacy
modesetting issues with MST, I misattributed some kernel splats that
started appearing on my machine after a rebase as being from upstream.
But it appears they actually came from my patch series:

[    2.980512] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:65:eDP-1]
[    2.980516] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CONNECTOR:65:eDP-1] is not registered
[    2.980516] ------------[ cut here ]------------
[    2.980519] Could not determine valid watermarks for inherited state
[    2.980553] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915]
[    2.980556] Modules linked in: i915(O+) i2c_algo_bit drm_kms_helper(O) syscopyarea sysfillrect sysimgblt fb_sys_fops drm(O) intel_rapl x86_pkg_temp_thermal iTCO_wdt wmi_bmof coretemp crc32_pclmul psmouse i2c_i801 mei_me mei i2c_core lpc_ich mfd_core tpm_tis tpm_tis_core wmi tpm thinkpad_acpi pcc_cpufreq video ehci_pci crc32c_intel serio_raw ehci_hcd xhci_pci xhci_hcd
[    2.980577] CPU: 3 PID: 551 Comm: systemd-udevd Tainted: G           O      4.19.0-rc7Lyude-Test+ #1
[    2.980579] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET63WW (1.27 ) 11/10/2016
[    2.980605] RIP: 0010:intel_modeset_init+0x14d7/0x19f0 [i915]
[    2.980607] Code: 89 df e8 ec 27 02 00 e9 24 f2 ff ff be 03 00 00 00 48 89 df e8 da 27 02 00 e9 26 f2 ff ff 48 c7 c7 c8 d1 34 a0 e8 23 cf dc e0 <0f> 0b e9 7c fd ff ff f6 c4 04 0f 85 37 f7 ff ff 48 8b 83 60 08 00
[    2.980611] RSP: 0018:ffffc90000287988 EFLAGS: 00010282
[    2.980614] RAX: 0000000000000000 RBX: ffff88031b488000 RCX: 0000000000000006
[    2.980617] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff880321ad54d0
[    2.980620] RBP: ffffc90000287a10 R08: 000000000000040a R09: 0000000000000065
[    2.980623] R10: ffff88030ebb8f00 R11: ffffffff81416590 R12: ffff88031b488000
[    2.980626] R13: ffff88031b4883a0 R14: ffffc900002879a8 R15: ffff880319099800
[    2.980630] FS:  00007f475620d180(0000) GS:ffff880321ac0000(0000) knlGS:0000000000000000
[    2.980633] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    2.980636] CR2: 00007f9ef28018a0 CR3: 000000031b72c001 CR4: 00000000003606e0
[    2.980639] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    2.980642] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    2.980645] Call Trace:
[    2.980675]  i915_driver_load+0xb0e/0xdc0 [i915]
[    2.980681]  ? kernfs_add_one+0xe7/0x130
[    2.980709]  i915_pci_probe+0x46/0x60 [i915]
[    2.980715]  pci_device_probe+0xd4/0x150
[    2.980719]  really_probe+0x243/0x3b0
[    2.980722]  driver_probe_device+0xba/0x100
[    2.980726]  __driver_attach+0xe4/0x110
[    2.980729]  ? driver_probe_device+0x100/0x100
[    2.980733]  bus_for_each_dev+0x74/0xb0
[    2.980736]  driver_attach+0x1e/0x20
[    2.980739]  bus_add_driver+0x159/0x230
[    2.980743]  ? 0xffffffffa0393000
[    2.980746]  driver_register+0x70/0xc0
[    2.980749]  ? 0xffffffffa0393000
[    2.980753]  __pci_register_driver+0x57/0x60
[    2.980780]  i915_init+0x55/0x58 [i915]
[    2.980785]  do_one_initcall+0x4a/0x1c4
[    2.980789]  ? do_init_module+0x27/0x210
[    2.980793]  ? kmem_cache_alloc_trace+0x131/0x190
[    2.980797]  do_init_module+0x60/0x210
[    2.980800]  load_module+0x2063/0x22e0
[    2.980804]  ? vfs_read+0x116/0x140
[    2.980807]  ? vfs_read+0x116/0x140
[    2.980811]  __do_sys_finit_module+0xbd/0x120
[    2.980814]  ? __do_sys_finit_module+0xbd/0x120
[    2.980818]  __x64_sys_finit_module+0x1a/0x20
[    2.980821]  do_syscall_64+0x5a/0x110
[    2.980824]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[    2.980826] RIP: 0033:0x7f4754e32879
[    2.980828] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f7 45 2c 00 f7 d8 64 89 01 48
[    2.980831] RSP: 002b:00007fff43fd97d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[    2.980834] RAX: ffffffffffffffda RBX: 0000559a44ca64f0 RCX: 00007f4754e32879
[    2.980836] RDX: 0000000000000000 RSI: 00007f475599f4cd RDI: 0000000000000018
[    2.980838] RBP: 00007f475599f4cd R08: 0000000000000000 R09: 0000000000000000
[    2.980839] R10: 0000000000000018 R11: 0000000000000246 R12: 0000000000000000
[    2.980841] R13: 0000559a44c92fd0 R14: 0000000000020000 R15: 0000000000000000
[    2.980881] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915]
[    2.980884] ---[ end trace 5eb47a76277d4731 ]---

The cause of this appears to be due to the fact that if there's
pre-existing display state that was set by the BIOS when i915 loads, it
will attempt to perform a modeset before the driver is registered with
userspace. Since this happens before the driver's registered with
userspace, it's connectors are also unregistered and thus-states which
would turn on DPMS on a connector end up getting rejected since the
connector isn't registered.

These bugs managed to get past Intel's CI partially due to the fact it
never ran a full test on my patches for some reason, but also because
all of the tests unload the GPU once before running. Since this bug is
only really triggered when the drivers tries to perform a modeset before
it's been fully registered with userspace when coming from whatever
display configuration the firmware left us with, it likely would never
have been picked up by CI in the first place.

After some discussion with vsyrjala, we decided the best course of
action would be to just move the unregistered connector checks out of
update_connector_routing() and into drm_atomic_set_crtc_for_connector().
The reason for this being that legacy modesetting isn't going to be
expecting failures anywhere (at least this is the case with X), so
ideally we want to ensure that any DPMS changes will still work even on
unregistered connectors. Instead, we now only reject new modesets which
would change the current CRTC assigned to an unregistered connector
unless no new CRTC is being assigned to replace the connector's previous
one.
Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
Reported-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Fixes: 4d802739 ("drm/atomic_helper: Disallow new modesets on unregistered connectors")
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181009204424.21462-1-lyude@redhat.com
(cherry picked from commit b5d29843)
Fixes: e9655095 ("drm/atomic_helper: Disallow new modesets on unregistered connectors")
Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      34ca26a9
    • Lyude Paul's avatar
      drm/atomic_helper: Disallow new modesets on unregistered connectors · e9655095
      Lyude Paul authored 
      With the exception of modesets which would switch the DPMS state of a
connector from on to off, we want to make sure that we disallow all
modesets which would result in enabling a new monitor or a new mode
configuration on a monitor if the connector for the display in question
is no longer registered. This allows us to stop userspace from trying to
enable new displays on connectors for an MST topology that were just
removed from the system, without preventing userspace from disabling
DPMS on those connectors.

Changes since v5:
- Fix typo in comment, nothing else
Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-2-lyude@redhat.com
(cherry picked from commit 4d802739)
Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      e9655095
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7