1. 06 11月, 2018 2 次提交
  2. 01 11月, 2018 6 次提交
  3. 31 10月, 2018 2 次提交
  4. 29 10月, 2018 5 次提交
    • D
      drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1 · 8f054b6f
      Douglas Anderson 提交于
      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: NAbhinav Kumar <abhinavk@codeaurora.org>
      Reviewed-by: NSean Paul <sean@poorly.run>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-6-dianders@chromium.org
      8f054b6f
    • D
      drm/bridge: ti-sn65dsi86: Remove the mystery delay · c2bfc223
      Douglas Anderson 提交于
      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: NSean Paul <sean@poorly.run>
      Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-4-dianders@chromium.org
      c2bfc223
    • D
      drm/panel: simple: Add "no-hpd" delay for Innolux TV123WAM · 625d3b5c
      Douglas Anderson 提交于
      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: NSean Paul <sean@poorly.run>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-3-dianders@chromium.org
      625d3b5c
    • D
      drm/panel: simple: Support panels with HPD where HPD isn't connected · 2ed3e951
      Douglas Anderson 提交于
      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: NSean Paul <sean@poorly.run>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-2-dianders@chromium.org
      2ed3e951
    • L
      drm/edid: Add 6 bpc quirk for BOE panel. · 922dceff
      Lee, Shawn C 提交于
      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: NLee, Shawn C <shawn.c.lee@intel.com&gt;>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/1540792173-7288-1-git-send-email-shawn.c.lee@intel.com
      922dceff
  5. 27 10月, 2018 3 次提交
  6. 26 10月, 2018 3 次提交
  7. 25 10月, 2018 4 次提交
  8. 24 10月, 2018 5 次提交
  9. 23 10月, 2018 6 次提交
  10. 19 10月, 2018 4 次提交
    • B
      drm/sun4i: Fix an ulong overflow in the dotclock driver · e84cb605
      Boris Brezillon 提交于
      The calculated ideal rate can easily overflow an unsigned long, thus
      making the best div selection buggy as soon as no ideal match is found
      before the overflow occurs.
      
      Fixes: 4731a72d ("drm/sun4i: request exact rates to our parents")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
      Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>
      Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181018100250.12565-1-boris.brezillon@bootlin.com
      e84cb605
    • L
      drm/nouveau: Fix nv50_mstc->best_encoder() · 7b0f61e9
      Lyude Paul 提交于
      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: NLyude Paul <lyude@redhat.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NBen 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: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      7b0f61e9
    • L
      drm/atomic_helper: Stop modesets on unregistered connectors harder · de9f8eea
      Lyude Paul 提交于
      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: NLyude Paul <lyude@redhat.com>
      Reviewed-by: NDaniel 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: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      de9f8eea
    • L
      drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors · 34ca26a9
      Lyude Paul 提交于
      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: NLyude Paul <lyude@redhat.com>
      Reported-by: NVille 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: NVille 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: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      34ca26a9