Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 04 2月, 2019 1 次提交
  3. 24 1月, 2019 1 次提交
  5. 05 12月, 2018 1 次提交
  7. 30 11月, 2018 2 次提交
  9. 29 11月, 2018 3 次提交
  11. 23 11月, 2018 2 次提交
  13. 03 11月, 2018 1 次提交
    • R
      drm: Add connector property to limit max bpc · 47e22ff1
      由 Radhakrishna Sripada 提交于 
      At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against connector limitations.

Creating a new connector property "max bpc" in order to limit the bpc.
xrandr can make use of this connector property to make sure that bpc does
not exceed the configured value. This property can be used by userspace to
set the bpc.

V2: Initialize max_bpc to satisfy kms_properties
V3: Move the property to drm_connector
V4: Split drm and i915 components(Ville)
V5: Make the property per connector(Ville)
V6: Compare the requested bpc to connector bpc(Daniel)
    Move the attach_property function to core(Ville)
V7: Fix checkpatch warnings
V8: Simplify the connector check code(Ville)
V9: Const display_info(Ville)
V10,V11: Fix CI issues.
V12: Add the Kernel documentation(Daniel)
V14: Crossreference the function name in the doc(Daniel)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kishore Kadiyala <kishore.kadiyala@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Sunpeng Li <sunpeng.li@amd.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181012184233.29250-1-radhakrishna.sripada@intel.com
      47e22ff1
  15. 19 10月, 2018 4 次提交
    • 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
    • L
      drm/atomic_helper: Disallow new modesets on unregistered connectors · e9655095
      由 Lyude Paul 提交于 
      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: NLyude Paul <lyude@redhat.com>
Reviewed-by: NDaniel 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: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      e9655095
    • L
      drm: Get ref on CRTC commit object when waiting for flip_done · 4364bcb2
      由 Leo Li 提交于 
      This fixes a general protection fault, caused by accessing the contents
of a flip_done completion object that has already been freed. It occurs
due to the preemption of a non-blocking commit worker thread W by
another commit thread X. X continues to clear its atomic state at the
end, destroying the CRTC commit object that W still needs. Switching
back to W and accessing the commit objects then leads to bad results.

Worker W becomes preemptable when waiting for flip_done to complete. At
this point, a frequently occurring commit thread X can take over. Here's
an example where W is a worker thread that flips on both CRTCs, and X
does a legacy cursor update on both CRTCs:

        ...
     1. W does flip work
     2. W runs commit_hw_done()
     3. W waits for flip_done on CRTC 1
     4. > flip_done for CRTC 1 completes
     5. W finishes waiting for CRTC 1
     6. W waits for flip_done on CRTC 2

     7. > Preempted by X
     8. > flip_done for CRTC 2 completes
     9. X atomic_check: hw_done and flip_done are complete on all CRTCs
    10. X updates cursor on both CRTCs
    11. X destroys atomic state
    12. X done

    13. > Switch back to W
    14. W waits for flip_done on CRTC 2
    15. W raises general protection fault

The error looks like so:

    general protection fault: 0000 [#1] PREEMPT SMP PTI
    **snip**
    Call Trace:
     lock_acquire+0xa2/0x1b0
     _raw_spin_lock_irq+0x39/0x70
     wait_for_completion_timeout+0x31/0x130
     drm_atomic_helper_wait_for_flip_done+0x64/0x90 [drm_kms_helper]
     amdgpu_dm_atomic_commit_tail+0xcae/0xdd0 [amdgpu]
     commit_tail+0x3d/0x70 [drm_kms_helper]
     process_one_work+0x212/0x650
     worker_thread+0x49/0x420
     kthread+0xfb/0x130
     ret_from_fork+0x3a/0x50
    Modules linked in: x86_pkg_temp_thermal amdgpu(O) chash(O)
    gpu_sched(O) drm_kms_helper(O) syscopyarea sysfillrect sysimgblt
    fb_sys_fops ttm(O) drm(O)

Note that i915 has this issue masked, since hw_done is signaled after
waiting for flip_done. Doing so will block the cursor update from
happening until hw_done is signaled, preventing the cursor commit from
destroying the state.

v2: The reference on the commit object needs to be obtained before
    hw_done() is signaled, since that's the point where another commit
    is allowed to modify the state. Assuming that the
    new_crtc_state->commit object still exists within flip_done() is
    incorrect.

    Fix by getting a reference in setup_commit(), and releasing it
    during default_clear().
Signed-off-by: NLeo Li <sunpeng.li@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1539611200-6184-1-git-send-email-sunpeng.li@amd.com
      4364bcb2
  17. 18 10月, 2018 1 次提交
    • L
      drm/atomic_helper: Stop modesets on unregistered connectors harder · 39b50c60
      由 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
      39b50c60
  19. 11 10月, 2018 1 次提交
    • L
      drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors · b5d29843
      由 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
      b5d29843
  21. 09 10月, 2018 1 次提交
  23. 06 10月, 2018 2 次提交
  25. 20 9月, 2018 1 次提交
  27. 09 9月, 2018 1 次提交
    • D
      drm: extract drm_atomic_uapi.c · 72fdb40c
      由 Daniel Vetter 提交于 
      This leaves all the commit/check and state handling in drm_atomic.c,
while pulling all the uapi glue and the huge ioctl itself into a
seprate file.

This seems to almost perfectly split the rather big drm_atomic.c file
into 2 equal sizes.

Also adjust the kerneldoc and type a very terse overview text.

v2: Rebase.

v3: Fix tiny typo.

v4:
- Fixup armada, newly converted atomic driver hooray!
- Fixup msm/dpu1, newly added too.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: intel-gfx@lists.freedesktop.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180905135711.28370-7-daniel.vetter@ffwll.ch
      72fdb40c
  29. 25 8月, 2018 1 次提交
    • L
      drm: Add per-plane pixel blend mode property · a5ec8332
      由 Lowry Li 提交于 
      Pixel blend modes represent the alpha blending equation
selection, describing how the pixels from the current
plane are composited with the background.

Adds a pixel_blend_mode to drm_plane_state and a
blend_mode_property to drm_plane, and related support
functions.

Defines three blend modes in drm_blend.h.

Changes since v1:
 - Moves the blending equation into the DOC comment
 - Refines the comments of drm_plane_create_blend_mode_property to not
   enumerate the #defines, but instead the string values
 - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha
Changes since v2:
 - Refines the comments of drm_plane_create_blend_mode_property:
      1) Puts the descriptions (after the ":") on a new line
      2) Adds explaining why @supported_modes need PREMUL as default
Changes since v3:
 - Refines drm_plane_create_blend_mode_property(). drm_property_add_enum()
   can calculate the index itself just fine, so no point in having the
   caller pass it in.
 - Since the current DRM assumption is that alpha is premultiplied
   as default, define DRM_MODE_BLEND_PREMULTI as 0 will be better.
 - Refines some comments.
Changes since v4:
 - Adds comments in drm_blend.h.
 - Removes setting default value in drm_plane_create_blend_mode_property()
   as it is already in __drm_atomic_helper_plane_reset().
 - Fixes to use state->pixel_blend_mode instead of using
   plane->state->pixel_blend_mode in reset function.
 - Rebases on drm-misc-next.
Reviewed-by: NLiviu Dudau <liviu.dudau@arm.com>
Signed-off-by: NLowry Li <lowry.li@arm.com>
Signed-off-by: NAyan Kumar Halder <ayan.halder@arm.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/245734/
      a5ec8332
  31. 06 8月, 2018 1 次提交
  33. 26 7月, 2018 2 次提交
  35. 14 7月, 2018 1 次提交
  37. 07 7月, 2018 4 次提交
  39. 06 7月, 2018 1 次提交
  41. 02 7月, 2018 2 次提交
  43. 20 6月, 2018 1 次提交
    • B
      drm: Add writeback connector type · 935774cd
      由 Brian Starkey 提交于 
      Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer. Add a writeback connector type and
related support functions.

Drivers should initialize a writeback connector with
drm_writeback_connector_init() which takes care of setting up all the
writeback-specific details on top of the normal functionality of
drm_connector_init().

Writeback connectors have a WRITEBACK_FB_ID property, used to set the
output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
supported writeback formats to userspace.

When a framebuffer is attached to a writeback connector with the
WRITEBACK_FB_ID property, it is used only once (for the commit in which
it was included), and userspace can never read back the value of
WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
attached to a CRTC.

Changes since v1:
 - Added drm_writeback.c + documentation
 - Added helper to initialize writeback connector in one go
 - Added core checks
 - Squashed into a single commit
 - Dropped the client cap
 - Writeback framebuffers are no longer persistent

Changes since v2:
 Daniel Vetter:
 - Subclass drm_connector to drm_writeback_connector
 - Relax check to allow CRTC to be set without an FB
 - Add some writeback_ prefixes
 - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
 Gustavo Padovan:
 - Add drm_writeback_job to handle writeback signalling centrally

Changes since v3:
 - Rebased
 - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS

Chances since v4:
 - Embed a drm_encoder inside the drm_writeback_connector to
   reduce the amount of boilerplate code required from the drivers
   that are using it.

Changes since v5:
 - Added Rob Clark's atomic_commit() vfunc to connector helper
   funcs, so that writeback jobs are committed from atomic helpers
 - Updated create_writeback_properties() signature to return an
   error code rather than a boolean false for failure.
 - Free writeback job with the connector state rather than when
   doing the cleanup_work()

Changes since v7:
 - fix extraneous use of out_fence that is only introduced in a
   subsequent patch.

Changes since v8:
 - whitespace changes pull from subsequent patch

Changes since v9:
 - Revert the v6 changes that free the writeback job in the connector
   state cleanup and return to doing it in the cleanup_work() function
Signed-off-by: NBrian Starkey <brian.starkey@arm.com>
[rebased and fixed conflicts]
Signed-off-by: NMihail Atanassov <mihail.atanassov@arm.com>
[rebased and added atomic_commit() vfunc for writeback jobs]
Signed-off-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NLiviu Dudau <liviu.dudau@arm.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/229037/
      935774cd
  45. 12 6月, 2018 1 次提交
  47. 04 5月, 2018 1 次提交
  49. 18 4月, 2018 1 次提交
  51. 17 4月, 2018 1 次提交
  53. 30 3月, 2018 1 次提交