drm/probe-helper: warn about negative .get_modes()

The .get_modes() callback is supposed to return the number of modes,
never a negative error code. If a negative value is returned, it'll just
be interpreted as a negative count, and added to previous calculations.

Document the rules, but handle the negative values gracefully with an
error message.

Cc: stable@vger.kernel.org
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/50208c866facc33226a3c77b82bb96aeef8ef310.1709913674.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm: Check polling initialized before enabling in drm_helper_probe_single_connector_modes

In function drm_helper_probe_single_connector_modes() when we enable
polling again, if it is already uninitialized, a warning is reported.
This patch fixes the warning message by checking if poll is initialized
before enabling it.

Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202401191128.db8423f1-oliver.sang@intel.com
Signed-off-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1706856224-9725-1-git-send-email-shradhagupta@linux.microsoft.com

drm: Check output polling initialized before disabling

In drm_kms_helper_poll_disable() check if output polling
support is initialized before disabling polling. If not flag
this as a warning.
Additionally in drm_mode_config_helper_suspend() and
drm_mode_config_helper_resume() calls, that re the callers of these
functions, avoid invoking them if polling is not initialized.
For drivers like hyperv-drm, that do not initialize connector
polling, if suspend is called without this check, it leads to
suspend failure with following stack
[ 770.719392] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 770.720592] printk: Suspending console(s) (use no_console_suspend to debug)
[ 770.948823] ------------[ cut here ]------------
[ 770.948824] WARNING: CPU: 1 PID: 17197 at kernel/workqueue.c:3162 __flush_work.isra.0+0x212/0x230
[ 770.948831] Modules linked in: rfkill nft_counter xt_conntrack xt_owner udf nft_compat crc_itu_t nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink vfat fat mlx5_ib ib_uverbs ib_core mlx5_core intel_rapl_msr intel_rapl_common kvm_amd ccp mlxfw kvm psample hyperv_drm tls drm_shmem_helper drm_kms_helper irqbypass pcspkr syscopyarea sysfillrect sysimgblt hv_balloon hv_utils joydev drm fuse xfs libcrc32c pci_hyperv pci_hyperv_intf sr_mod sd_mod cdrom t10_pi sg hv_storvsc scsi_transport_fc hv_netvsc serio_raw hyperv_keyboard hid_hyperv crct10dif_pclmul crc32_pclmul crc32c_intel hv_vmbus ghash_clmulni_intel dm_mirror dm_region_hash dm_log dm_mod
[ 770.948863] CPU: 1 PID: 17197 Comm: systemd-sleep Not tainted 5.14.0-362.2.1.el9_3.x86_64 #1
[ 770.948865] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022
[ 770.948866] RIP: 0010:__flush_work.isra.0+0x212/0x230
[ 770.948869] Code: 8b 4d 00 4c 8b 45 08 89 ca 48 c1 e9 04 83 e2 08 83 e1 0f 83 ca 02 89 c8 48 0f ba 6d 00 03 e9 25 ff ff ff 0f 0b e9 4e ff ff ff <0f> 0b 45 31 ed e9 44 ff ff ff e8 8f 89 b2 00 66 66 2e 0f 1f 84 00
[ 770.948870] RSP: 0018:ffffaf4ac213fb10 EFLAGS: 00010246
[ 770.948871] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8c992857
[ 770.948872] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff9aad82b00330
[ 770.948873] RBP: ffff9aad82b00330 R08: 0000000000000000 R09: ffff9aad87ee3d10
[ 770.948874] R10: 0000000000000200 R11: 0000000000000000 R12: ffff9aad82b00330
[ 770.948874] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
[ 770.948875] FS: 00007ff1b2f6bb40(0000) GS:ffff9aaf37d00000(0000) knlGS:0000000000000000
[ 770.948878] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 770.948878] CR2: 0000555f345cb666 CR3: 00000001462dc005 CR4: 0000000000370ee0
[ 770.948879] Call Trace:
[ 770.948880] <TASK>
[ 770.948881] ? show_trace_log_lvl+0x1c4/0x2df
[ 770.948884] ? show_trace_log_lvl+0x1c4/0x2df
[ 770.948886] ? __cancel_work_timer+0x103/0x190
[ 770.948887] ? __flush_work.isra.0+0x212/0x230
[ 770.948889] ? __warn+0x81/0x110
[ 770.948891] ? __flush_work.isra.0+0x212/0x230
[ 770.948892] ? report_bug+0x10a/0x140
[ 770.948895] ? handle_bug+0x3c/0x70
[ 770.948898] ? exc_invalid_op+0x14/0x70
[ 770.948899] ? asm_exc_invalid_op+0x16/0x20
[ 770.948903] ? __flush_work.isra.0+0x212/0x230
[ 770.948905] __cancel_work_timer+0x103/0x190
[ 770.948907] ? _raw_spin_unlock_irqrestore+0xa/0x30
[ 770.948910] drm_kms_helper_poll_disable+0x1e/0x40 [drm_kms_helper]
[ 770.948923] drm_mode_config_helper_suspend+0x1c/0x80 [drm_kms_helper]
[ 770.948933] ? __pfx_vmbus_suspend+0x10/0x10 [hv_vmbus]
[ 770.948942] hyperv_vmbus_suspend+0x17/0x40 [hyperv_drm]
[ 770.948944] ? __pfx_vmbus_suspend+0x10/0x10 [hv_vmbus]
[ 770.948951] dpm_run_callback+0x4c/0x140
[ 770.948954] __device_suspend_noirq+0x74/0x220
[ 770.948956] dpm_noirq_suspend_devices+0x148/0x2a0
[ 770.948958] dpm_suspend_end+0x54/0xe0
[ 770.948960] create_image+0x14/0x290
[ 770.948963] hibernation_snapshot+0xd6/0x200
[ 770.948964] hibernate.cold+0x8b/0x1fb
[ 770.948967] state_store+0xcd/0xd0
[ 770.948969] kernfs_fop_write_iter+0x124/0x1b0
[ 770.948973] new_sync_write+0xff/0x190
[ 770.948976] vfs_write+0x1ef/0x280
[ 770.948978] ksys_write+0x5f/0xe0
[ 770.948979] do_syscall_64+0x5c/0x90
[ 770.948981] ? syscall_exit_work+0x103/0x130
[ 770.948983] ? syscall_exit_to_user_mode+0x12/0x30
[ 770.948985] ? do_syscall_64+0x69/0x90
[ 770.948986] ? do_syscall_64+0x69/0x90
[ 770.948987] ? do_user_addr_fault+0x1d6/0x6a0
[ 770.948989] ? do_syscall_64+0x69/0x90
[ 770.948990] ? exc_page_fault+0x62/0x150
[ 770.948992] entry_SYSCALL_64_after_hwframe+0x72/0xdc
[ 770.948995] RIP: 0033:0x7ff1b293eba7
[ 770.949010] Code: 0b 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
[ 770.949011] RSP: 002b:00007ffde3912128 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 770.949012] RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007ff1b293eba7
[ 770.949013] RDX: 0000000000000005 RSI: 00007ffde3912210 RDI: 0000000000000004
[ 770.949014] RBP: 00007ffde3912210 R08: 000055d7dd4c9510 R09: 00007ff1b29b14e0
[ 770.949014] R10: 00007ff1b29b13e0 R11: 0000000000000246 R12: 0000000000000005
[ 770.949015] R13: 000055d7dd4c53e0 R14: 0000000000000005 R15: 00007ff1b29f69e0
[ 770.949016] </TASK>
[ 770.949017] ---[ end trace e6fa0618bfa2f31d ]---

Built-on: Rhel9, Ubuntu22
Signed-off-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1706856208-9617-1-git-send-email-shradhagupta@linux.microsoft.com

drm/probe-helper: remove unused drm_connector_helper_get_modes_from_ddc()

Remove the unused drm_connector_helper_get_modes_from_ddc()
function. Most drivers should probably have this functionality split to
detect and get modes parts, so the helper is not the best abstraction.

Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/60eb6b2db16747d3f9c12604b197f33da585c16e.1704473654.git.jani.nikula@intel.com

drm: Fix output poll work for drm_kms_helper_poll=n

If drm_kms_helper_poll=n the output poll work will only get scheduled
from drm_helper_probe_single_connector_modes() to handle a delayed
hotplug event. Since polling is disabled the work in this case should
just call drm_kms_helper_hotplug_event() w/o detecting the state of
connectors and rescheduling the work.

After commit d33a54e3991d after a delayed hotplug event above the
connectors did get re-detected in the poll work and the work got
re-scheduled periodically (since poll_running is also false if
drm_kms_helper_poll=n), in effect ignoring the drm_kms_helper_poll=n
kernel param.

Fix the above by calling only drm_kms_helper_hotplug_event() for a
delayed hotplug event if drm_kms_helper_hotplug_event=n, as was done
before d33a54e3991d.

Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: d33a54e3991d ("drm/probe_helper: sort out poll_running vs poll_enabled")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240301152243.1670573-1-imre.deak@intel.com

drm: Add an HPD poll helper to reschedule the poll work

Add a helper to reschedule drm_mode_config::output_poll_work after
polling has been enabled for a connector (and needing a reschedule,
since previously polling was disabled for all connectors and hence
output_poll_work was not running).

This is needed by the next patch fixing HPD polling on i915.

CC: stable@vger.kernel.org # 6.4+
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230822113015.41224-1-imre.deak@intel.com

drm: Add an HPD poll helper to reschedule the poll work

Add a helper to reschedule drm_mode_config::output_poll_work after
polling has been enabled for a connector (and needing a reschedule,
since previously polling was disabled for all connectors and hence
output_poll_work was not running).

This is needed by the next patch fixing HPD polling on i915.

CC: stable@vger.kernel.org # 6.4+
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230822113015.41224-1-imre.deak@intel.com
(cherry picked from commit fe2352fd64029918174de4b460dfe6df0c6911cd)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm: Add an HPD poll helper to reschedule the poll work

Add a helper to reschedule drm_mode_config::output_poll_work after
polling has been enabled for a connector (and needing a reschedule,
since previously polling was disabled for all connectors and hence
output_poll_work was not running).

This is needed by the next patch fixing HPD polling on i915.

CC: stable@vger.kernel.org # 6.4+
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230822113015.41224-1-imre.deak@intel.com
(cherry picked from commit fe2352fd64029918174de4b460dfe6df0c6911cd)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/probe-helper: Cancel previous job before starting new one

Currently we schedule a call to output_poll_execute from
drm_kms_helper_poll_enable for 10s in future. Later we try to replace
that in drm_helper_probe_single_connector_modes with a 0s schedule with
delayed_event set.

But as there is already a job in the queue this fails, and the immediate
job we wanted with delayed_event set doesn't occur until 10s later.

And that call acts as if connector state has changed, reprobing modes.
This has a side effect of waking up a display that has been blanked.

Make sure we cancel the old job before submitting the immediate one.

Fixes: 162b6a57ac50 ("drm/probe-helper: don't lose hotplug event")
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
[Maxime: Switched to mod_delayed_work]
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20230127154052.452524-1-maxime@cerno.tech

drm/probe_helper: sort out poll_running vs poll_enabled

There are two flags attemting to guard connector polling:
poll_enabled and poll_running. While poll_enabled semantics is clearly
defined and fully adhered (mark that drm_kms_helper_poll_init() was
called and not finalized by the _fini() call), the poll_running flag
doesn't have such clearliness.

This flag is used only in drm_helper_probe_single_connector_modes() to
guard calling of drm_kms_helper_poll_enable, it doesn't guard the
drm_kms_helper_poll_fini(), etc. Change it to only be set if the polling
is actually running. Tie HPD enablement to this flag.

This fixes the following warning reported after merging the HPD series:

Hot plug detection already enabled
WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_bridge.c:1257 drm_bridge_hpd_enable+0x94/0x9c [drm]
Modules linked in: videobuf2_memops snd_soc_simple_card snd_soc_simple_card_utils fsl_imx8_ddr_perf videobuf2_common snd_soc_imx_spdif adv7511 etnaviv imx8m_ddrc imx_dcss mc cec nwl_dsi gov
CPU: 2 PID: 9 Comm: kworker/u8:0 Not tainted 6.2.0-rc2-15208-g25b283acd578 #6
Hardware name: NXP i.MX8MQ EVK (DT)
Workqueue: events_unbound deferred_probe_work_func
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_bridge_hpd_enable+0x94/0x9c [drm]
lr : drm_bridge_hpd_enable+0x94/0x9c [drm]
sp : ffff800009ef3740
x29: ffff800009ef3740 x28: ffff000009331f00 x27: 0000000000001000
x26: 0000000000000020 x25: ffff800001148ed8 x24: ffff00000a8fe000
x23: 00000000fffffffd x22: ffff000005086348 x21: ffff800001133ee0
x20: ffff00000550d800 x19: ffff000005086288 x18: 0000000000000006
x17: 0000000000000000 x16: ffff8000096ef008 x15: 97ffff2891004260
x14: 2a1403e194000000 x13: 97ffff2891004260 x12: 2a1403e194000000
x11: 7100385f29400801 x10: 0000000000000aa0 x9 : ffff800008112744
x8 : ffff000000250b00 x7 : 0000000000000003 x6 : 0000000000000011
x5 : 0000000000000000 x4 : ffff0000bd986a48 x3 : 0000000000000001
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000000250000
Call trace:
drm_bridge_hpd_enable+0x94/0x9c [drm]
drm_bridge_connector_enable_hpd+0x2c/0x3c [drm_kms_helper]
drm_kms_helper_poll_enable+0x94/0x10c [drm_kms_helper]
drm_helper_probe_single_connector_modes+0x1a8/0x510 [drm_kms_helper]
drm_client_modeset_probe+0x204/0x1190 [drm]
__drm_fb_helper_initial_config_and_unlock+0x5c/0x4a4 [drm_kms_helper]
drm_fb_helper_initial_config+0x54/0x6c [drm_kms_helper]
drm_fbdev_client_hotplug+0xd0/0x140 [drm_kms_helper]
drm_fbdev_generic_setup+0x90/0x154 [drm_kms_helper]
dcss_kms_attach+0x1c8/0x254 [imx_dcss]
dcss_drv_platform_probe+0x90/0xfc [imx_dcss]
platform_probe+0x70/0xcc
really_probe+0xc4/0x2e0
__driver_probe_device+0x80/0xf0
driver_probe_device+0xe0/0x164
__device_attach_driver+0xc0/0x13c
bus_for_each_drv+0x84/0xe0
__device_attach+0xa4/0x1a0
device_initial_probe+0x1c/0x30
bus_probe_device+0xa4/0xb0
deferred_probe_work_func+0x90/0xd0
process_one_work+0x200/0x474
worker_thread+0x74/0x43c
kthread+0xfc/0x110
ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---

Reported-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Fixes: c8268795c9a9 ("drm/probe-helper: enable and disable HPD on connectors")
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Acked-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Tested-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Tested-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230124104548.3234554-2-dmitry.baryshkov@linaro.org

drm/probe_helper: extract two helper functions

Extract drm_kms_helper_enable_hpd() and drm_kms_helper_disable_hpd(),
two helpers that enable and disable HPD handling on all device's
connectors.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230124104548.3234554-1-dmitry.baryshkov@linaro.org

drm/probe_helper: sort out poll_running vs poll_enabled

There are two flags attemting to guard connector polling:
poll_enabled and poll_running. While poll_enabled semantics is clearly
defined and fully adhered (mark that drm_kms_helper_poll_init() was
called and not finalized by the _fini() call), the poll_running flag
doesn't have such clearliness.

This flag is used only in drm_helper_probe_single_connector_modes() to
guard calling of drm_kms_helper_poll_enable, it doesn't guard the
drm_kms_helper_poll_fini(), etc. Change it to only be set if the polling
is actually running. Tie HPD enablement to this flag.

This fixes the following warning reported after merging the HPD series:

Hot plug detection already enabled
WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_bridge.c:1257 drm_bridge_hpd_enable+0x94/0x9c [drm]
Modules linked in: videobuf2_memops snd_soc_simple_card snd_soc_simple_card_utils fsl_imx8_ddr_perf videobuf2_common snd_soc_imx_spdif adv7511 etnaviv imx8m_ddrc imx_dcss mc cec nwl_dsi gov
CPU: 2 PID: 9 Comm: kworker/u8:0 Not tainted 6.2.0-rc2-15208-g25b283acd578 #6
Hardware name: NXP i.MX8MQ EVK (DT)
Workqueue: events_unbound deferred_probe_work_func
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_bridge_hpd_enable+0x94/0x9c [drm]
lr : drm_bridge_hpd_enable+0x94/0x9c [drm]
sp : ffff800009ef3740
x29: ffff800009ef3740 x28: ffff000009331f00 x27: 0000000000001000
x26: 0000000000000020 x25: ffff800001148ed8 x24: ffff00000a8fe000
x23: 00000000fffffffd x22: ffff000005086348 x21: ffff800001133ee0
x20: ffff00000550d800 x19: ffff000005086288 x18: 0000000000000006
x17: 0000000000000000 x16: ffff8000096ef008 x15: 97ffff2891004260
x14: 2a1403e194000000 x13: 97ffff2891004260 x12: 2a1403e194000000
x11: 7100385f29400801 x10: 0000000000000aa0 x9 : ffff800008112744
x8 : ffff000000250b00 x7 : 0000000000000003 x6 : 0000000000000011
x5 : 0000000000000000 x4 : ffff0000bd986a48 x3 : 0000000000000001
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000000250000
Call trace:
drm_bridge_hpd_enable+0x94/0x9c [drm]
drm_bridge_connector_enable_hpd+0x2c/0x3c [drm_kms_helper]
drm_kms_helper_poll_enable+0x94/0x10c [drm_kms_helper]
drm_helper_probe_single_connector_modes+0x1a8/0x510 [drm_kms_helper]
drm_client_modeset_probe+0x204/0x1190 [drm]
__drm_fb_helper_initial_config_and_unlock+0x5c/0x4a4 [drm_kms_helper]
drm_fb_helper_initial_config+0x54/0x6c [drm_kms_helper]
drm_fbdev_client_hotplug+0xd0/0x140 [drm_kms_helper]
drm_fbdev_generic_setup+0x90/0x154 [drm_kms_helper]
dcss_kms_attach+0x1c8/0x254 [imx_dcss]
dcss_drv_platform_probe+0x90/0xfc [imx_dcss]
platform_probe+0x70/0xcc
really_probe+0xc4/0x2e0
__driver_probe_device+0x80/0xf0
driver_probe_device+0xe0/0x164
__device_attach_driver+0xc0/0x13c
bus_for_each_drv+0x84/0xe0
__device_attach+0xa4/0x1a0
device_initial_probe+0x1c/0x30
bus_probe_device+0xa4/0xb0
deferred_probe_work_func+0x90/0xd0
process_one_work+0x200/0x474
worker_thread+0x74/0x43c
kthread+0xfc/0x110
ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---

Reported-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Fixes: c8268795c9a9 ("drm/probe-helper: enable and disable HPD on connectors")
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Acked-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Tested-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Tested-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230124104548.3234554-2-dmitry.baryshkov@linaro.org
(cherry picked from commit d33a54e3991dfce88b4fc6d9c3360951c2c5660d)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

drm/probe_helper: extract two helper functions

Extract drm_kms_helper_enable_hpd() and drm_kms_helper_disable_hpd(),
two helpers that enable and disable HPD handling on all device's
connectors.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230124104548.3234554-1-dmitry.baryshkov@linaro.org
(cherry picked from commit cbf143b282c64e59559cc8351c0b5b1ab4bbdcbe)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

drm/edid: add separate drm_edid_connector_add_modes()

The original goal with drm_edid_connector_update() was to have a single
call for updating the connector and adding probed modes, in this order,
but that turned out to be problematic. Drivers that need to update the
connector in the .detect() callback would end up updating the probed
modes as well. Turns out the callback may be called so many times that
the probed mode list fills up without bounds, and this is amplified by
add_alternate_cea_modes() duplicating the CEA modes on every call,
actually running out of memory on some machines.

Kudos to Imre Deak <imre.deak@intel.com> for explaining this to me.

Go back to having separate drm_edid_connector_update() and
drm_edid_connector_add_modes() calls. The former may be called from
.detect(), .force(), or .get_modes(), but the latter only from
.get_modes().

Unlike drm_add_edid_modes(), have drm_edid_connector_add_modes() update
the probed modes from the EDID property instead of the passed in
EDID. This is mainly to enforce two things:

1) drm_edid_connector_update() must be called before
drm_edid_connector_add_modes().

Display info and quirks are needed for parsing the modes, and we
don't want to call update_display_info() again to ensure the info is
available, like drm_add_edid_modes() does.

2) The same EDID is used for both updating the connector and adding the
probed modes.

Fortunately, the change is easy, because no driver has actually adopted
drm_edid_connector_update(). Not even i915, and that's mainly because of
the problem described above.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e86fff1579f14ebf6334692526c8f6831cd02cac.1674144945.git.jani.nikula@intel.com

drm/probe-helper: enable and disable HPD on connectors

Introduce two drm_connector_helper_funcs: enable_hpd() and disable_hpd().
They are called by drm_kms_helper_poll_enable() and
drm_kms_helper_poll_disable() (and thus drm_kms_helper_poll_init() and
drm_kms_helper_poll_fini()) respectively.

This allows DRM drivers to rely on drm_kms_helper_poll for enabling and
disabling HPD detection rather than doing that manually.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20221102180705.459294-3-dmitry.baryshkov@linaro.org

drm/poll-helper: merge drm_kms_helper_poll_disable() and _fini()

Merge drm_kms_helper_poll_disable() and drm_kms_helper_poll_fini() code
into a common helper function.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20221102180705.459294-2-dmitry.baryshkov@linaro.org

drm/probe-helper: Provide a TV get_modes helper

Most of the TV connectors will need a similar get_modes implementation
that will, depending on the drivers' capabilities, register the 480i and
576i modes.

That implementation will also need to set the preferred flag and order
the modes based on the driver and users preferrence.

This is especially important to guarantee that a userspace stack such as
Xorg can start and pick up the preferred mode while maintaining a
working output.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Tested-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Acked-in-principle-or-something-like-that-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-12-256dad125326@cerno.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/fb-helper: Remove unnecessary include statements

Remove include statements for <drm/drm_fb_helper.h> where it is not
required (i.e., most of them). In a few places include other header
files that are required by the source code.

v3:
* fix amdgpu include statements
* fix rockchip include statements

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-23-tzimmermann@suse.de

drm/edid: rename drm_add_override_edid_modes() to drm_edid_override_connector_update()

Follow the naming of both EDID override functions as well as
drm_edid_connector_update(). This also matches better what the function
does; a combination of EDID property update and add modes. Indeed it
should later be converted to call drm_edid_connector_update().

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ba12957e0488654e8db010a3ff1534079caec972.1666614699.git.jani.nikula@intel.com

drm/probe-helper: Add drm_crtc_helper_mode_valid_fixed()

Add drm_crtc_helper_mode_valid_fixed(), which validates a given mode
against a display hardware's mode. Convert simpledrm and use it in a
few other drivers with static modes.

v4:
* remove empty line after opening brace
v2:
* rename 'static' and 'hw' to 'fixed' everywhere

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220905141648.22013-3-tzimmermann@suse.de

drm/probe-helper: Add drm_connector_helper_get_modes_fixed()

Add drm_connector_helper_get_modes_fixed(), which duplicates a single
display mode for a connector. Convert drivers.

v2:
* rename 'static' and 'hw' to 'fixed' everywhere
* fix typo 'there' to 'their' (Sam)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220905141648.22013-2-tzimmermann@suse.de

drm/probe-helper: add drm_connector_helper_get_modes()

Add a helper function to be used as the "default" .get_modes()
hook. This also works as an example of what the driver .get_modes()
hooks are supposed to do regarding the new drm_edid_read*() and
drm_edid_connector_update() calls.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d985449ed4b95971490ab7c09d2d59b58a892769.1656494768.git.jani.nikula@intel.com

drm/probe-helper: abstract .get_modes() connector helper call

Abstract the .get_modes() connector helper call, including the
override/firmware EDID fallback, for clarity.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a4de51efc246e4f5bcbf7b84d66bb49aaf7fd974.1654674560.git.jani.nikula@intel.com

drm/probe-helper: Default to 640x480 if no EDID on DP

If we're unable to read the EDID for a display because it's corrupt /
bogus / invalid then we'll add a set of standard modes for the
display. Since we have no true information about the connected
display, these modes are essentially guesses but better than nothing.
At the moment, none of the modes returned is marked as preferred, but
the modes are sorted such that the higher resolution modes are listed
first.

When userspace sees these modes presented by the kernel it needs to
figure out which one to pick. At least one userspace, ChromeOS [1]
seems to use the rules (which seem pretty reasonable):
1. Try to pick the first mode marked as preferred.
2. Try to pick the mode which matches the first detailed timing
descriptor in the EDID.
3. If no modes were marked as preferred then pick the first mode.

Unfortunately, userspace's rules combined with what the kernel is
doing causes us to fail section 4.2.2.6 (EDID Corruption Detection) of
the DP 1.4a Link CTS. That test case says that, while it's OK to allow
some implementation-specific fall-back modes if the EDID is bad that
userspace should _default_ to 640x480.

Let's fix this by marking 640x480 as default for DP in the no-EDID
case.

NOTES:
- In the discussion around v3 of this patch [2] there was talk about
solving this in userspace and I even implemented a patch that would
have solved this for ChromeOS, but then the discussion turned back
to solving this in the kernel.
- Also in the discussion of v3 [2] it was requested to limit this
change to just DP since folks were worried that it would break some
subtle corner case on VGA or HDMI.

[1] https://source.chromium.org/chromium/chromium/src/+/a051f741d0a15caff2251301efe081c30e0f4a96:ui/ozone/platform/drm/common/drm_util.cc;l=488
[2] https://lore.kernel.org/r/20220513130533.v3.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220601112302.v4.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid

drm/probe-helper: For DP, add 640x480 if all other modes are bad

As per Displayport spec section 5.2.1.2 ("Video Timing Format") says
that all detachable sinks shall support 640x480 @60Hz as a fail safe
mode.

A DP compliance test expected us to utilize the above fact when all
modes it presented to the DP source were not achievable. It presented
only modes that would be achievable with more lanes and/or higher
speeds than we had available and expected that when we couldn't do
that then we'd fall back to 640x480 even though it didn't advertise
this size.

In order to pass the compliance test (and also support any users who
might fall into a similar situation with their display), we need to
add 640x480 into the list of modes. However, we don't want to add
640x480 all the time. Despite the fact that the DP spec says all sinks
_shall support_ 640x480, they're not guaranteed to support it
_well_. Continuing to read the spec you can see that the display is
not required to really treat 640x480 equal to all the other modes. It
doesn't need to scale or anything--just display the pixels somehow for
failsafe purposes. It should also be noted that it's not hard to find
a display hooked up via DisplayPort that _doesn't_ support 640x480 at
all. The HP ZR30w screen I'm sitting in front of has a native DP port
and doesn't work at 640x480. I also plugged in a tiny 800x480 HDMI
display via a DP to HDMI adapter and that screen definitely doesn't
support 640x480.

As a compromise solution, let's only add the 640x480 mode if:
* We're on DP.
* All other modes have been pruned.

This acknowledges that 640x480 might not be the best mode to use but,
since sinks are _supposed_ to support it, we will at least fall back
to it if there's nothing else.

Note that we _don't_ add higher resolution modes like 1024x768 in this
case. We only add those modes for a failed EDID read where we have no
idea what's going on. In the case where we've pruned all modes then
instead we only want 640x480 which is the only defined "Fail Safe"
resolution.

This patch originated in response to Kuogee Hsieh's patch [1].

[1] https://lore.kernel.org/r/1650671124-14030-1-git-send-email-quic_khsieh@quicinc.com

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220511155749.v3.2.I4ac7f55aa446699f8c200a23c10463256f6f439f@changeid

drm/probe-helper: Add helper for drm_helper_probe_single_connector_modes()

The drm_helper_probe_single_connector_modes() is a bit long. Let's
break a chunk off to update and validate modes. This helps avoid one
goto and also will allow us to more easily call the helper a second
time in a future patch without adding looping or another goto.

This change is intended to be a no-op change--just code movement.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220511155749.v3.1.I2dd93486c6952bd52f2020904de0133970d11b29@changeid

drm/mgag200: Implement connector's get_modes with helper

Provide drm_connector_helper_get_modes_from_ddc() to implement the
connector's get_modes callback. The new helper updates the connector
from DDC-provided EDID data.

v2:
* clear property if EDID is NULL in helper

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Tested-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220516134343.6085-4-tzimmermann@suse.de

drm/probe-helper: use drm_kms_helper_connector_hotplug_event

If an hotplug event only updates a single connector, use
drm_kms_helper_connector_hotplug_event instead of
drm_kms_helper_hotplug_event.

Changes in v4:
- Simplify loop logic (Ville, Sam)
- Update drm_connector_helper_hpd_irq_event (Maxime)

Signed-off-by: Simon Ser <contact@emersion.fr>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018084707.32253-6-contact@emersion.fr

drm/probe-helper: add drm_kms_helper_connector_hotplug_event

This function is the same as drm_kms_helper_hotplug_event, but takes
a connector instead of a device.

Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018084707.32253-3-contact@emersion.fr

drm/probe-helper: Create a HPD IRQ event helper for a single connector

The drm_helper_hpd_irq_event() function is iterating over all the
connectors when an hotplug event is detected.

During that iteration, it will call each connector detect function and
figure out if its status changed.

Finally, if any connector changed, it will notify the user-space and the
clients that something changed on the DRM device.

This is supposed to be used for drivers that don't have a hotplug
interrupt for individual connectors. However, drivers that can use an
interrupt for a single connector are left in the dust and can either
reimplement the logic used during the iteration for each connector or
use that helper and iterate over all connectors all the time.

Since both are suboptimal, let's create a helper that will only perform
the status detection on a single connector.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210914101724.266570-2-maxime@cerno.tech

drm/probe-helper: Document drm_helper_hpd_irq_event() return value

The documentation of the drm_helper_hpd_irq_event() function didn't
document the value that function was returning. Add that part as well.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210914101724.266570-1-maxime@cerno.tech

drm: Fix typo in comments

fix typo for drm

v1->v2:
respin with the change "iff ==> implies that"

Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210730132729.376-1-caihuoqing@baidu.com

drm/probe-helper: Check epoch counter in output_poll_execute()

drm_helper_hpd_irq_event() checks the epoch counter to determine
connector status change. This was introduced in
commit 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector").
Do the same for output_poll_execute() so it can detect other changes
beside connection status value changes.

v2:
- Add Fixes tag (Daniel)

Fixes: 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector")
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210313112545.37527-3-noralf@tronnes.org

drm: Add default modes for connectors in unknown state

The DRM CRTC helpers add default modes to connectors in the connected
state if no mode can be retrieved from the connector. This behaviour is
useful for VGA or DVI outputs that have no connected DDC bus. However,
in such cases, the status of the output usually can't be retrieved and
is reported as connector_status_unknown.

Extend the addition of default modes to connectors in an unknown state
to support outputs that can retrieve neither the modes nor the
connection status.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/probe_helper: Add drm_connector_helper_funcs.mode_valid_ctx

This is just an atomic version of mode_valid, which is intended to be
used for situations where a driver might need to check the atomic state
of objects other than the connector itself. One such example is with
MST, where the maximum possible bandwidth on a connector can change
dynamically irregardless of the display configuration.

Changes since v1:
* Use new drm logging functions
* Make some corrections in the mode_valid_ctx kdoc
* Return error codes or 0 from ->mode_valid_ctx() on fail, and store the
drm_mode_status in an additional function parameter
Changes since v2:
* Don't accidentally assign ret to mode->status on success, or we'll
squash legitimate mode validation results
* Don't forget to assign MODE_OK to status in drm_connector_mode_valid()
if we have no callbacks
* Drop leftover hunk in drm_modes.h around enum drm_mode_status
Changes since v3:
* s/return ret/return 0/ in drm_mode_validate_pipeline()
* Minor cleanup in drm_connector_mode_valid()

Tested-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Cc: Lee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200713170746.254388-2-lyude@redhat.com

drm: Introduce epoch counter to drm_connector

This counter will be used by drm_helper_probe_detect caller to determine
if anything had changed(including edid, connection status and etc).
Hardware specific driver detect hooks are responsible for updating this
counter when some change is detected to notify the drm part,
which can trigger for example hotplug event.

Also now call drm_connector_update_edid_property
right after we get edid always to make sure there is a
unified way to handle edid change, without having to
change tons of source code as currently
drm_connector_update_edid_property is called only in
certain cases like reprobing and not right after edid is
actually updated.

v2: Added documentation for the new counter. Rename change_counter to
epoch_counter.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105540

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630002700.5451-3-kunal1.joshi@intel.com

drm: bridge: Pass drm_display_info to drm_bridge_funcs .mode_valid()

When validating a mode, bridges may need to do so in the context of a
display, as specified by drm_display_info. An example is the meson
dw-hdmi bridge that needs to consider the YUV 4:2:0 output format to
perform clock calculations.

Bridges that need the display info currently retrieve it from the
drm_connector created by the bridge. This gets in the way of moving
connector creation out of bridge drivers. To make this possible, pass
the drm_display_info to drm_bridge_funcs .mode_valid().

Changes to the bridge drivers have been performed with the following
coccinelle semantic patch and have been compile-tested.

@ rule1 @
identifier funcs;
identifier fn;
@@
struct drm_bridge_funcs funcs = {
...,
.mode_valid = fn
};

@ depends on rule1 @
identifier rule1.fn;
identifier bridge;
identifier mode;
@@
enum drm_mode_status fn(
struct drm_bridge *bridge,
+ const struct drm_display_info *info,
const struct drm_display_mode *mode
)
{
...
}

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Guido Günther <agx@sigxcpu.org> # for the nwl-dsi part:
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200526011505.31884-11-laurent.pinchart+renesas@ideasonboard.com

drm: Nuke mode->vrefresh

Get rid of mode->vrefresh and just calculate it on demand. Saves
a bit of space and avoids the cached value getting out of sync
with reality.

Mostly done with cocci, with the following manual fixups:
- Remove the now empty loop in drm_helper_probe_single_connector_modes()
- Fix __MODE() macro in ch7006_mode.c
- Fix DRM_MODE_ARG() macro in drm_modes.h
- Remove leftover comment from samsung_s6d16d0_mode
- Drop the TODO

@@
@@
struct drm_display_mode {
...
- int vrefresh;
...
};

@@
identifier N;
expression E;
@@
struct drm_display_mode N = {
- .vrefresh = E
};

@@
identifier N;
expression E;
@@
struct drm_display_mode N[...] = {
...,
{
- .vrefresh = E
}
,...
};

@@
expression E;
@@
{
DRM_MODE(...),
- .vrefresh = E,
}

@@
identifier M, R;
@@
int drm_mode_vrefresh(const struct drm_display_mode *M)
{
...
- if (M->vrefresh > 0)
- R = M->vrefresh;
- else
if (...) {
...
}
...
}

@@
struct drm_display_mode *p;
expression E;
@@
(
- p->vrefresh = E;
|
- p->vrefresh
+ drm_mode_vrefresh(p)
)

@@
struct drm_display_mode s;
expression E;
@@
(
- s.vrefresh = E;
|
- s.vrefresh
+ drm_mode_vrefresh(&s)
)

@@
expression E;
@@
- drm_mode_vrefresh(E) ? drm_mode_vrefresh(E) : drm_mode_vrefresh(E)
+ drm_mode_vrefresh(E)

@find_substruct@
identifier X;
identifier S;
@@
struct X {
...
struct drm_display_mode S;
...
};

@@
identifier find_substruct.S;
expression E;
identifier I;
@@
{
.S = {
- .vrefresh = E
}
}

@@
identifier find_substruct.S;
identifier find_substruct.X;
expression E;
identifier I;
@@
struct X I[...] = {
...,
.S = {
- .vrefresh = E
}
,...
};

v2: Drop TODO
v3: Rebase
v4: Rebase

Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Jerry Han <hanxu5@huaqin.corp-partner.google.com>
Cc: Icenowy Zheng <icenowy@aosc.io>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Stefan Mavrodiev <stefan@olimex.com>
Cc: Robert Chiras <robert.chiras@nxp.com>
Cc: "Guido Günther" <agx@sigxcpu.org>
Cc: Purism Kernel Team <kernel@puri.sm>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: linux-amlogic@lists.infradead.org
Cc: nouveau@lists.freedesktop.org
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-4-ville.syrjala@linux.intel.com

drm: Add DRM_MODE_TYPE_USERDEF flag to probed modes matching a video= argument

drm_helper_probe_add_cmdline_mode() prefers using a probed mode matching
a video= argument over calculating our own timings for the user specified
mode using CVT or GTF.

But userspace code which is auto-configuring the mode may want to know that
the user has specified that mode on the kernel commandline so that it can
pick that mode over the mode which is marked as DRM_MODE_TYPE_PREFERRED.

This commit sets the DRM_MODE_TYPE_USERDEF flag on the matching mode, just
as we would do on the user-specified mode when no matching probed mode is
found.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200221173313.510235-2-hdegoede@redhat.com

drm: Stop accessing encoder->bridge directly

We are about to replace the single-linked bridge list by a double-linked
one based on list.h, leading to the suppression of the encoder->bridge
field. But before we can do that we must provide a
drm_bridge_chain_get_first_bridge() bridge helper and patch all drivers
and core helpers to use it instead of directly accessing encoder->bridge.

Note that we still have 2 drivers (VC4 and Exynos) manipulating the
encoder->bridge field directly because they need to cut the bridge chain
in order to control the enable/disable sequence. This is definitely
not something we want to encourage, so let's keep those 2 oddities
around until we find a better solution.

Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203141515.3597631-4-boris.brezillon@collabora.com

drm/bridge: Rename bridge helpers targeting a bridge chain

Change the prefix of bridge helpers targeting a bridge chain from
drm_bridge_ to drm_bridge_chain_ to better reflect the fact that
the operation will happen on all elements of chain, starting at the
bridge passed in argument.

Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203141515.3597631-2-boris.brezillon@collabora.com

drm/connector: Allow max possible encoders to attach to a connector

Currently we restrict the number of encoders that can be linked to
a connector to 3, increase it to match the maximum number of encoders
that can be initialized(32).

To more effiently do that lets switch from an array of encoder ids to
bitmask.

v2: Fixing missed return on amdgpu_dm_connector_to_encoder()

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: dri-devel@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190913232857.389834-2-jose.souza@intel.com

drm: Stop including drm_bridge.h from drm_crtc.h

We are about to add a drm_bridge_state that inherits from
drm_private_state which is defined in drm_atomic.h. Problem is,
drm_atomic.h includes drm_crtc.h which in turn includes drm_bridge.h,
leading to "drm_private_state has incomplete type" error.

Let's force all users of the drm_bridge API to explicitly include
drm_bridge.h.

Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190826152649.13820-2-boris.brezillon@collabora.com

drm: add fallback override/firmware EDID modes workaround

We've moved the override and firmware EDID (simply "override EDID" from
now on) handling to the low level drm_do_get_edid() function in order to
transparently use the override throughout the stack. The idea is that
you get the override EDID via the ->get_modes() hook.

Unfortunately, there are scenarios where the DDC probe in drm_get_edid()
called via ->get_modes() fails, although the preceding ->detect()
succeeds.

In the case reported by Paul Wise, the ->detect() hook,
intel_crt_detect(), relies on hotplug detect, bypassing the DDC. In the
case reported by Ilpo Järvinen, there is no ->detect() hook, which is
interpreted as connected. The subsequent DDC probe reached via
->get_modes() fails, and we don't even look at the override EDID,
resulting in no modes being added.

Because drm_get_edid() is used via ->detect() all over the place, we
can't trivially remove the DDC probe, as it leads to override EDID
effectively meaning connector forcing. The goal is that connector
forcing and override EDID remain orthogonal.

Generally, the underlying problem here is the conflation of ->detect()
and ->get_modes() via drm_get_edid(). The former should just detect, and
the latter should just get the modes, typically via reading the EDID. As
long as drm_get_edid() is used in ->detect(), it needs to retain the DDC
probe. Or such users need to have a separate DDC probe step first.

The EDID caching between ->detect() and ->get_modes() done by some
drivers is a further complication that prevents us from making
drm_do_get_edid() adapt to the two cases.

Work around the regression by falling back to a separate attempt at
getting the override EDID at drm_helper_probe_single_connector_modes()
level. With a working DDC and override EDID, it'll never be called; the
override EDID will come via ->get_modes(). There will still be a failing
DDC probe attempt in the cases that require the fallback.

v2:
- Call drm_connector_update_edid_property (Paul)
- Update commit message about EDID caching (Daniel)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107583
Reported-by: Paul Wise <pabs3@bonedaddy.net>
Cc: Paul Wise <pabs3@bonedaddy.net>
References: http://mid.mail-archive.com/alpine.DEB.2.20.1905262211270.24390@whs-18.cs.helsinki.fi
Reported-by: Ilpo Järvinen <ilpo.jarvinen@cs.helsinki.fi>
Cc: Ilpo Järvinen <ilpo.jarvinen@cs.helsinki.fi>
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
References: 15f080f08d48 ("drm/edid: respect connector force for drm_get_edid ddc probe")
Fixes: 53fd40a90f3c ("drm: handle override and firmware EDID at drm_do_get_edid() level")
Cc: <stable@vger.kernel.org> # v4.15+ 56a2b7f2a39a drm/edid: abstract override/firmware EDID retrieval
Cc: <stable@vger.kernel.org> # v4.15+
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harish Chegondi <harish.chegondi@intel.com>
Tested-by: Paul Wise <pabs3@bonedaddy.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190610093054.28445-1-jani.nikula@intel.com

drm: Flush output polling on shutdown

We need to mark the output polling as disabled to prevent concurrent
irqs from queuing new work as shutdown the probe -- causing that work to
execute after we have freed the structs:

<4> [341.846490] DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock))
<4> [341.846497] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50
<4> [341.846508] Modules linked in: i915(-) vgem thunderbolt snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm mcs7830 btusb usbnet btrtl mii btbcm btintel bluetooth ecdh_generic ecc mei_me mei prime_numbers i2c_hid pinctrl_sunrisepoint pinctrl_intel [last unloaded: i915]
<4> [341.846546] CPU: 3 PID: 3300 Comm: i915_module_loa Tainted: G U 5.2.0-rc2-CI-CI_DRM_6175+ #1
<4> [341.846553] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018
<4> [341.846560] RIP: 0010:mutex_destroy+0x49/0x50
<4> [341.846565] Code: 00 00 5b c3 e8 a8 9f 3b 00 85 c0 74 ed 8b 05 3e 55 23 01 85 c0 75 e3 48 c7 c6 00 d0 08 82 48 c7 c7 a8 aa 07 82 e8 e7 08 fa ff <0f> 0b eb cc 0f 1f 00 48 b8 11 11 11 11 11 11 11 11 48 89 76 20 48
<4> [341.846578] RSP: 0018:ffffc900006cfdb0 EFLAGS: 00010286
<4> [341.846583] RAX: 0000000000000000 RBX: ffff88826759a168 RCX: 0000000000000000
<4> [341.846589] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffffffff8112844c
<4> [341.846595] RBP: ffff8882708fa548 R08: 0000000000000000 R09: 0000000000039600
<4> [341.846601] R10: 0000000000000000 R11: 0000000000000ce4 R12: ffffffffa07de1e0
<4> [341.846607] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffa07de2d0
<4> [341.846613] FS: 00007f62b5ae0e40(0000) GS:ffff888276380000(0000) knlGS:0000000000000000
<4> [341.846620] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4> [341.846626] CR2: 000055a4e064f4a0 CR3: 0000000266b16006 CR4: 00000000003606e0
<4> [341.846632] Call Trace:
<4> [341.846639] drm_fb_helper_fini.part.17+0xb3/0x100
<4> [341.846682] intel_fbdev_fini+0x20/0x80 [i915]
<4> [341.846722] intel_modeset_cleanup+0x9a/0x140 [i915]
<4> [341.846750] i915_driver_unload+0xa3/0x100 [i915]
<4> [341.846778] i915_pci_remove+0x19/0x30 [i915]
<4> [341.846784] pci_device_remove+0x36/0xb0
<4> [341.846790] device_release_driver_internal+0xd3/0x1b0
<4> [341.846795] driver_detach+0x3f/0x80
<4> [341.846800] bus_remove_driver+0x53/0xd0
<4> [341.846805] pci_unregister_driver+0x25/0xa0
<4> [341.846843] i915_exit+0x16/0x1c [i915]
<4> [341.846849] __se_sys_delete_module+0x162/0x210
<4> [341.846855] ? trace_hardirqs_off_thunk+0x1a/0x1c
<4> [341.846859] ? do_syscall_64+0xd/0x1c0
<4> [341.846864] do_syscall_64+0x55/0x1c0
<4> [341.846869] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [341.846875] RIP: 0033:0x7f62b51871b7
<4> [341.846881] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48
<4> [341.846897] RSP: 002b:00007ffe7a227138 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
<4> [341.846904] RAX: ffffffffffffffda RBX: 00007ffe7a2272b0 RCX: 00007f62b51871b7
<4> [341.846910] RDX: 0000000000000001 RSI: 0000000000000800 RDI: 0000557cd6b55948
<4> [341.846916] RBP: 0000557cd6b558e0 R08: 0000557cd6b5594c R09: 00007ffe7a227160
<4> [341.846922] R10: 00007ffe7a226134 R11: 0000000000000206 R12: 0000000000000000
<4> [341.846927] R13: 00007ffe7a227820 R14: 0000000000000000 R15: 0000000000000000
<4> [341.846936] irq event stamp: 3547847
<4> [341.846940] hardirqs last enabled at (3547847): [<ffffffff819aad2c>] _raw_spin_unlock_irqrestore+0x4c/0x60
<4> [341.846949] hardirqs last disabled at (3547846): [<ffffffff819aab9d>] _raw_spin_lock_irqsave+0xd/0x50
<4> [341.846957] softirqs last enabled at (3547376): [<ffffffff81c0033a>] __do_softirq+0x33a/0x4b9
<4> [341.846966] softirqs last disabled at (3547367): [<ffffffff810b6379>] irq_exit+0xa9/0xc0
<4> [341.846973] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50
<4> [341.846980] ---[ end trace ba94ca8952ba970e ]---
<7> [341.866547] [drm:intel_dp_detect [i915]] MST support? port A: no, sink: no, modparam: yes
<7> [341.890480] [drm:drm_add_display_info] non_desktop set to 0
<7> [341.890530] [drm:drm_add_edid_modes] ELD: no CEA Extension found
<7> [341.890537] [drm:drm_add_display_info] non_desktop set to 0
<7> [341.890578] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:86:eDP-1] probed modes :
<7> [341.890589] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 60 373250 3200 3248 3280 3360 1800 1803 1808 1852 0x48 0xa
<7> [341.890602] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 48 298600 3200 3248 3280 3360 1800 1803 1808 1852 0x40 0xa
<4> [341.890628] general protection fault: 0000 [#1] PREEMPT SMP PTI
<4> [341.890636] CPU: 0 PID: 508 Comm: kworker/0:4 Tainted: G U W 5.2.0-rc2-CI-CI_DRM_6175+ #1
<4> [341.890646] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018
<4> [341.890655] Workqueue: events output_poll_execute
<4> [341.890663] RIP: 0010:drm_setup_crtcs+0x13e/0xbe0
<4> [341.890669] Code: 00 41 8b 44 24 58 85 c0 0f 8e f9 01 00 00 44 8b 6c 24 20 44 8b 74 24 28 31 db 31 ed 49 8b 44 24 60 48 63 d5 44 89 ee 83 c5 01 <48> 8b 04 d0 44 89 f2 48 8b 38 48 8b 87 88 01 00 00 48 8b 40 20 e8
<4> [341.890686] RSP: 0018:ffffc9000033fd40 EFLAGS: 00010202
<4> [341.890692] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000002 RCX: 0000000000000000
<4> [341.890700] RDX: 0000000000000001 RSI: 0000000000000c80 RDI: 00000000ffffffff
<4> [341.890707] RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
<4> [341.890715] R10: 0000000000000c80 R11: 0000000000000000 R12: ffff888267599fe8
<4> [341.890722] R13: 0000000000000c80 R14: 0000000000000708 R15: 0000000000000007
<4> [341.890730] FS: 0000000000000000(0000) GS:ffff888276200000(0000) knlGS:0000000000000000
<4> [341.890739] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4> [341.890745] CR2: 000055a4e064f4a0 CR3: 000000026d234003 CR4: 00000000003606f0
<4> [341.890752] Call Trace:
<4> [341.890760] drm_fb_helper_hotplug_event.part.24+0x89/0xb0
<4> [341.890768] drm_kms_helper_hotplug_event+0x21/0x30
<4> [341.890774] output_poll_execute+0x9d/0x1a0
<4> [341.890782] process_one_work+0x245/0x610
<4> [341.890790] worker_thread+0x37/0x380
<4> [341.890796] ? process_one_work+0x610/0x610
<4> [341.890802] kthread+0x119/0x130
<4> [341.890808] ? kthread_park+0x80/0x80
<4> [341.890815] ret_from_fork+0x3a/0x50

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109964
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190603135910.15979-2-chris@chris-wilson.co.uk

drm: drop use of drmP.h in drm/*

The use of the drmP.h header file is deprecated.
Remove use from all files in drm/*
so people do not look there and follow a bad example.

Build tested allyesconfig,allmodconfig on x86, arm etc.
Including alpha that is as always more challenging than
the rest.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Link: https://patchwork.freedesktop.org/patch/msgid/20190526173535.32701-8-sam@ravnborg.org

drm: Split out drm_probe_helper.h

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 > drm_modeset_helper.h -> 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 <harry.wentland@amd.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
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

drm: drop _mode_ from remaining connector functions

Since there's very few callers of these I've decided to do them all in
one patch. With this the unecessarily long drm_mode_connector_ prefix
is gone from the codebase! The only exception being struct
drm_mode_connector_set_property, which is part of the uapi so can't be
renamed.

Again done with sed+some manual fixups for indent issues.

Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-8-daniel.vetter@ffwll.ch

drm: drop _mode_ from update_edit_property()

Just makes it longer, and for most things in drm_connector.[hc] we
just use the drm_connector_ prefix. Done with sed + a bit of manual
fixup for the indenting.

Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-6-daniel.vetter@ffwll.ch

drm: Begin an API for in-kernel clients

This the beginning of an API for in-kernel clients.
First out is a way to get a framebuffer backed by a dumb buffer.

Only GEM drivers are supported.
The original idea of using an exported dma-buf was dropped because it
also creates an anonomous file descriptor which doesn't work when the
buffer is created from a kernel thread. The easy way out is to use
drm_driver.gem_prime_vmap to get the virtual address, which requires a
GEM object. This excludes the vmwgfx driver which is the only non-GEM
driver apart from the legacy ones. A solution for vmwgfx will have to be
worked out later if it wants to support the client API which it probably
will when we have a bootsplash client.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180703160354.59955-2-noralf@tronnes.org

drm: Add drm_connector_for_each_possible_encoder()

Add a convenience macro for iterating connector->encoder_ids[].
Isolates the users from the implementation details.

Note that we don't seem to pass the file_priv down to drm_encoder_find()
because encoders apparently don't get leased. No idea why
drm_encoder_finc() even takes the file_priv actually.

Also use ARRAY_SIZE() when populating the array to avoid spreading
knowledge about the array size all over.

v2: Hide the drm_encoder_find() in the macro, and
rename the macro appropriately (Daniel)
v3: Fix kernel docs (Daniel)

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180628131315.14156-4-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Allow determining if current task is output poll worker

Introduce a helper to determine if the current task is an output poll
worker.

This allows us to fix a long-standing deadlock in several DRM drivers
wherein the ->runtime_suspend callback waits for the output poll worker
to finish and the worker in turn calls a ->detect callback which waits
for runtime suspend to finish. The ->detect callback is invoked from
multiple call sites and waiting for runtime suspend to finish is the
correct thing to do except if it's executing in the context of the
worker.

v2: Expand kerneldoc to specifically mention deadlock between
output poll worker and autosuspend worker as use case. (Lyude)

Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/3549ce32e7f1467102e70d3e9cbf70c46bfe108e.1518593424.git.lukas@wunner.de

drm/modes: Provide global mode_valid hook

Allow drivers to provide a device wide .mode_valid() hook in addition to
the already existing crtc/encoder/bridge/connector hooks. This can be
used to validate device/driver wide constraings without having to add
those to the other hooks. And since we call this hook also for user
modes later on in the modeset we don't have to worry about anything the
hook has already rejected.

I also have some further ideas for this hook. Eg. we could replace the
drm_mode_set_crtcinfo(HALVE_V) call in drm_mode_convert_umode()/etc.
with a driver specific variant via this hook. At least on i915 we would
like to pass CRTC_STEREO_DOUBLE to that function instead, and then
we could safely use the crtc_ timings in all our .mode_valid() hooks,
which would allow us to reuse those hooks for validating the
adjusted_mode during a modeset.

v2: Fix the language fails in the kernel docs (Daniel)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-10-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/probe-helper: Fix drm_kms_helper_poll_enable() docs

Fix docs to reflect code and drm_kms_helper_poll_disable() docs by saying
that calling drm_kms_helper_poll_enable() is fine even if output polling
is not enabled.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171106191812.38927-2-noralf@tronnes.org

drm: Pass struct drm_file * to __drm_mode_object_find [v2]

This will allow __drm_mode_object_file to be extended to perform
access control checks based on the file in use.

v2: Also fix up vboxvideo driver in staging

[airlied: merging early as this is an API change]

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: handle override and firmware EDID at drm_do_get_edid() level

Handle debugfs override edid and firmware edid at the low level to
transparently and completely replace the real edid. Previously, we
practically only used the modes from the override EDID, and none of the
other data, such as audio parameters.

This change also prevents actual EDID reads when the EDID is to be
overridden, but retains the DDC probe. This is useful if the reason for
preferring override EDID are problems with reading the data, or
corruption of the data.

Move firmware EDID loading from helper to core, as the functionality
moves to lower level as well. This will result in a change of module
parameter from drm_kms_helper.edid_firmware to drm.edid_firmware, which
arguably makes more sense anyway.

Some future work remains related to override and firmware EDID
validation. Like before, no validation is done for override EDID. The
firmware EDID is validated separately in the loader. Some unification
and deduplication would be in order, to validate all of them at the
drm_do_get_edid() level, like "real" EDIDs.

v2: move firmware loading to core

v3: rebase, commit message refresh

Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1e8a710bcac46e5136c1a7b430074893c81f364a.1505203831.git.jani.nikula@intel.com

drm: add helper to validate YCBCR420 modes

YCBCR420 modes are supported only on HDMI 2.0 capable sources.
This patch adds:
- A drm helper to validate YCBCR420-only mode on a particular
connector. This function will help pruning the YCBCR420-only
modes from the connector's modelist.
- A bool variable (ycbcr_420_allowed) in the drm connector structure.
While handling the EDID from HDMI 2.0 sinks, its important to know
if the source is capable of handling YCBCR420 output, so that no
YCBCR 420 modes will be listed for sources which can't handle it.
A driver should set this variable if it wants to see YCBCR420 modes
in the modedb.

V5: Introduced the patch in series.
V6: Squashed two patches (validate YCBCR420 and add YCBCR420
identifier)
V7: Addressed review comments from Vile:
- Move this patch before we add 420 modes from EDID.
- No need for drm_valid_cea_vic() check, function back to non-static.
- Update MODE_STATUS with NO_420 condition.
- Introduce y420_vdb_modes variable in this patch

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-6-git-send-email-shashank.sharma@intel.com
[vsyrjala: Drop the now bogus EXPORT_SYMBOL(drm_valid_cea_vic)]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm: Use new mode_valid() helpers in connector probe helper

This changes the connector probe helper function to use the new
encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid()
helper callbacks to validate the modes.

The new callbacks are optional so the behaviour remains the same
if they are not implemented. If they are, then the code loops
through all the connector's encodersXbridgesXcrtcs and calls the
callback.

If at least a valid encoderXbridgeXcrtc combination is found which
accepts the mode then the function returns MODE_OK.

Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Carlos Palminha <palminha@synopsys.com>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Changes v3->v4:
- Change function name (Laurent)
Changes v2->v3:
- Call also bridge->mode_valid (Daniel)
Changes v1->v2:
- Use new helpers suggested by Ville
- Change documentation (Daniel)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/d4e3ba87d822fa92f1b8773e441b9a02af3bde71.1495720737.git.joabreu@synopsys.com

drm: Add drm_{crtc/encoder/connector}_mode_valid()

Add a new helper to call crtc->mode_valid, connector->mode_valid
and encoder->mode_valid callbacks.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Cc: Carlos Palminha <palminha@synopsys.com>
Cc: Dave Airlie <airlied@linux.ie>

Changes v2->v3:
- Move helpers to drm_probe_helper.c (Daniel)
- Squeeze patches that introduce helpers into a single
one (Daniel)

Signed-off-by: Jose Abreu <joabreu@synopsys.com>
[danvet: Make it compile when CONFIG_DRM_DP_AUX_CHARDEV is selected.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/b55c8bd029da219ff04e39086025c115731a49b1.1495720737.git.joabreu@synopsys.com

drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes, v4.

mode_valid() called from drm_helper_probe_single_connector_modes()
may need to look at connector->state because what a valid mode is may
depend on connector properties being set. For example some HDMI modes
might be rejected when a connector property forces the connector
into DVI mode.

Some implementations of detect() already lock all state,
so we have to pass an acquire_ctx to them to prevent a deadlock.

This means changing the function signature of detect() slightly,
and passing the acquire_ctx for locking multiple crtc's.
For the callbacks, it will always be non-zero. To allow callers
not to worry about this, drm_helper_probe_detect_ctx is added
which might handle -EDEADLK for you.

Changes since v1:
- Always set ctx parameter.
Changes since v2:
- Always take connection_mutex when probing.
Changes since v3:
- Remove the ctx from intel_dp_long_pulse, and add
WARN_ON(!connection_mutex) (danvet)
- Update docs to clarify the locking situation. (danvet)

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1491504920-4017-1-git-send-email-maarten.lankhorst@linux.intel.com

drm/doc: Small markup fixup

Drive-by cleanup.

Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170404095304.17599-11-daniel.vetter@ffwll.ch

drm: Rename connector list iterator API

Currently the functions that initialize and tear down a connector
iterator use the _get() and _put() suffixes. However, these suffixes
are typically used by reference counting functions.

Make these function names a little more consistent by changing the
suffixes to _begin() and _end(), which is a fairly common pattern in
the rest of the Linux kernel.

Suggested-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170228144643.5668-8-thierry.reding@gmail.com

scripts/spelling.txt: add "againt" pattern and fix typo instances

Fix typos and add the following to the scripts/spelling.txt:

againt||against

While we are here, fix the "capabilites" as well in the touched hunk in
drivers/gpu/drm/drm_probe_helper.c.

Link: http://lkml.kernel.org/r/1481573103-11329-13-git-send-email-yamada.masahiro@socionext.com
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

drm: move edid property update and add modes out of edid firmware loader

Make the firmware loader more generic and generally useful.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487344854-18777-2-git-send-email-jani.nikula@intel.com

Reinstate "drm/probe-helpers: Drop locking from poll_enable""

This reverts commit 54a07c7bb0da0343734c78212bbe9f3735394962,
and reinstates the original.

[airlied: this might be a bad plan for git].

commit 3846fd9b86001bea171943cc3bb9222cb6da6b42
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jan 11 10:01:17 2017 +0100

drm/probe-helpers: Drop locking from poll_enable

It was only needed to protect the connector_list walking, see

commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jul 9 23:44:26 2015 +0200

drm/probe-helper: Grab mode_config.mutex in poll_init/enable

Unfortunately the commit message of that patch fails to mention that
the new locking check was for the connector_list.

But that requirement disappeared in

commit c36a3254f7857f1ad9badbe3578ccc92be541a8e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Dec 15 16:58:43 2016 +0100

drm: Convert all helpers to drm_connector_list_iter

and so we can drop this again.

This fixes a locking inversion on nouveau, where the rpm code needs to
re-enable. But in other places the rpm_get() calls are nested within
the big modeset locks.

While at it, also improve the kerneldoc for these two functions a
notch.

v2: Update the kerneldoc even more to explain that these functions
can't be called concurrently, or bad things happen (Chris).

Revert "drm/probe-helpers: Drop locking from poll_enable"

This reverts commit 3846fd9b86001bea171943cc3bb9222cb6da6b42.

There were some precursor commits missing for this around connector
locking, we should probably merge Lyude's nouveau avoid the problem patch.

drm/kms-helpers: Use recommened kerneldoc for struct member refs

I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).

Also some minor drive-by polish where it makes sense, I read a lot
of docs ...

v2: Comments from Gustavo.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Rewiewed-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-2-daniel.vetter@ffwll.ch

drm/probe-helpers: Drop locking from poll_enable

It was only needed to protect the connector_list walking, see

commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jul 9 23:44:26 2015 +0200

drm/probe-helper: Grab mode_config.mutex in poll_init/enable

Unfortunately the commit message of that patch fails to mention that
the new locking check was for the connector_list.

But that requirement disappeared in

commit c36a3254f7857f1ad9badbe3578ccc92be541a8e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Dec 15 16:58:43 2016 +0100

drm: Convert all helpers to drm_connector_list_iter

and so we can drop this again.

This fixes a locking inversion on nouveau, where the rpm code needs to
re-enable. But in other places the rpm_get() calls are nested within
the big modeset locks.

While at it, also improve the kerneldoc for these two functions a
notch.

v2: Update the kerneldoc even more to explain that these functions
can't be called concurrently, or bad things happen (Chris).

Cc: Dave Airlie <airlied@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Lyude <lyude@redhat.com>
Reviewed-by: Lyude <lyude@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111090117.5134-1-daniel.vetter@ffwll.ch

drm: Schedule the output_poll_work with 1s delay if we have delayed event

Instead of scheduling the work to handle the initial delayed event, use 1s
delay.

This delay should not be needed, but Optimus/nouveau will fail in a
mysterious way if the delayed event is handled as soon as possible like it
is done in drm_helper_probe_single_connector_modes() in case the poll
was enabled before.

Reverting 339fd36238dd would give back the 10 sec (!) delay to handle the
delayed event. Adding 1sec delay to the poll_work is enough to work around
the issue in Optimus setups and gives shorter response on handling the
initial delayed event.

Fixes: 339fd36238dd ("drm: drm_probe_helper: Fix output_poll_work scheduling")
Cc: stable@vger.kernel.org # v4.9
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
[danvet: Add FIXME to the comment to make it stick out more.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170109143158.21917-1-peter.ujfalusi@ti.com

drm/doc: use preferred struct reference in kernel-doc

sed -e 's/\( \* .*\)struct &\([_a-z]*\)/\1\&struct \2/' -i

Originally I wasnt a friend of this style because I thought a
line-break between the "&struct" and "foo" part would break it. But a
quick test shows that " * &struct \n * foo\n" works pefectly well with
current kernel-doc. So time to mass-apply these changes!

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1483044517-5770-6-git-send-email-daniel.vetter@ffwll.ch

drm: Convert all helpers to drm_connector_list_iter

Mostly nothing special (except making sure that really all error paths
and friends call iter_put).

v2: Don't forget the raw connector_list walking in
drm_helper_move_panel_connectors_to_head. That one unfortunately can't
be converted to the iterator helpers, but since it's just some list
splicing best to just wrap the entire thing up in one critical
section.

v3: Bail out after iter_put (Harry).

Cc: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161215155843.13408-1-daniel.vetter@ffwll.ch

drm: Don't block the kworker waiting for mode_config.mutex in output_poll()

If we cannot acquire the mode_config.mutex immediately, just back off and
queue a new attempt after the poll interval. This is mostly to stop the
hung task spam when the system is deadlocked, but it will also lessen
the load (in such extreme cases).

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
[danvet:s/lock/mutex/ per Eric's comment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161206113715.30382-1-chris@chris-wilson.co.uk

drm: Make the connector .detect() callback optional

Many drivers (21 to be exact) create connectors that are always
connected (for instance to an LVDS or DSI panel). Instead of forcing
them to implement a dummy .detect() handler, make the callback optional
and consider the connector as always connected in that case.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Jyri Sarha <jsarha@ti.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Vincent Abriou <vincent.abriou@st.com>
Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
[seanpaul fixed small conflict in rcar-du/rcar_du_lvdscon.c]
Signed-off-by: Sean Paul <seanpaul@chromium.org>

drm: drm_probe_helper: Fix output_poll_work scheduling

drm_kms_helper_poll_enable_locked() should check if we have delayed event
pending and if we have, schedule the work to run without delay.

Currently the output_poll_work is only scheduled if any of the connectors
have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
already registered to be handled. The detection will be delayd by
DRM_OUTPUT_POLL_PERIOD in any case.
Furthermore if none of the connectors are marked as POLL_CONNECT or
POLL_DISCONNECT because all connectors are either POLL_HPD or they are
always connected: the output_poll_work will not run at all even if we
have delayed event marked.

When none of the connectors require polling, their initial status change
from unknown to connected/disconnected is not going to be handled until
the first kms application starts or if we have fb console enabled.

Note that in general the output poll work should be enabled already
when this happens, but at driver load usually the first probe happens
before the output polling is enabled. This patch fixes this case.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
[danvet: Note when exactly this is an issue, since the probe code
schedules the poll work itself already.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160831110905.31289-1-peter.ujfalusi@ti.com

drm: Only create a cmdline mode if no probed modes match

The intention of using video=<connector>:<mode> is primarily to select
the user's preferred resolution at startup. Currently we always create a
new mode irrespective of whether the monitor has a native mode at the
desired resolution. This has the issue that we may then select the fake
mode rather the native mode during fb_helper->inital_config() and so
if the fake mode is invalid we then end up with a loss of signal. Oops.
This invalid fake mode would also be exported to userspace, who
potentially may make the same mistake.

To avoid this issue, we filter out the added command line mode if we
detect the desired resolution (and clock if specified) amongst the
probed modes. This fixes the immediate problem of adding a duplicate
mode, but perhaps more generically we should avoid adding a GTF mode if
the monitor has an EDID that is not GTF-compatible, or similarly for
CVT.

Was meant to fix a regression from

commit eaf99c749d43ae74ac7ffece5512f3c73f01dfd2
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Aug 6 10:08:32 2014 +0200

drm: Perform cmdline mode parsing during connector initialisation

but Radek explained that the original bug is no longer reproducible on
latest kernels.

v2: Explicitly delete our earlier cmdline mode
v3: Mode pruning should now be sufficient to delete stale cmdline modes
v4: Compute the vrefresh for the probed mode

Reported-by: Radek Dostál <rd@radekdostal.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Radek Dostál <rd@radekdostal.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Cc: Julia Lemire <jlemire@matrox.com>
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Drop cc: stable since no longer a pressing bugfix, just
nice-to-have.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1464774651-20376-1-git-send-email-chris@chris-wilson.co.uk

drm: probe_helper: Hide ugly ifdef

Push the ifdef to the drm_edid.h and create a stub, for the
DRM_LOAD_EDID_FIRMWARE=n case. This removes some clutter in
the code, making it more readable.

Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1461087638-16959-1-git-send-email-ezequiel@vanguardiasur.com.ar

drm: Don't overwrite UNVERFIED mode status to OK

The way the mode probing works is this:
1. All modes currently on the mode list are marked as UNVERIFIED
2. New modes are on the probed_modes list (they start with
status OK)
3. Modes are moved from the probed_modes list to the actual
mode list. If a mode already on the mode list is deemed
to match one of the probed modes, the duplicate is dropped
and the mode status updated to OK. After this the
probed_modes list will be empty.
4. All modes on the mode list are verified to not violate any
constraints. Any that do are marked as such.
5. Any mode left with a non-OK status is pruned from the list,
with an appropriate debug message.

What all this means is that any mode on the original list that
didn't have a duplicate on the probed_modes list, should be left
with status UNVERFIED (or previously could have been left with
some other status, but never OK).

I broke that in
commit 05acaec334fc ("drm: Reorganize probed mode validation")
by always assigning something to the mode->status during the validation
step. So any mode from the old list that still passed the validation
would be left on the list with status OK in the end.

Fix this by not doing the basic mode validation unless the mode
already has status OK (meaning it came from the probed_modes list,
or at least a duplicate of it was on that list). This way we will
correctly prune away any mode from the old mode list that didn't
appear on the probed_modes list.

Cc: stable@vger.kernel.org
Cc: Adam Jackson <ajax@redhat.com>
Fixes: 05acaec334fc ("drm: Reorganize probed mode validation")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449177255-9515-2-git-send-email-ville.syrjala@linux.intel.com
Testcase: igt/kms_force_connector_basic/prune-stale-modes
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93332
[danvet: Also applying to drm-misc to avoid too much conflict hell -
there's a big pile of patches from Ville on top of this one.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Expand the drm_helper_probe_single_connector_modes() docs

Describe the procedure that drm_helper_probe_single_connector_modes()
uses to do it's work in the kernel-doc comment.

Caveat: Looks like crap and trying to reverse engineer the documentation
tools is not something I want to do.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449782037-19722-3-git-send-email-ville.syrjala@linux.intel.com

drm: Allow override_edid to override the firmware EDID

IMO the override_edid should override any default EDID for the
connector, whether that came in via the connector helper ->get_modes()
vfunc or via the firmware EDID mechanism.

Cc: Thomas Wood <thomas.wood@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449782037-19722-2-git-send-email-ville.syrjala@linux.intel.com

drm: Drop drm_helper_probe_single_connector_modes_nomerge()

Now that the mode type bit merge logic is fixed to only merge
between new probed modes, hopefully we can eliminat the special
case for qxl and virtio. That is make the merge the mode type
bits from all matching new probed modes, just like every other
driver.

qxl and virtio got excluded from the merging in
commit 3fbd6439e463 ("drm: copy mode type in drm_mode_connector_list_update()")
commit abce1ec9b08a ("Revert "drm: copy mode type in drm_mode_connector_list_update()"")
commit b87577b7c768 ("drm: try harder to avoid regression when merging mode bits")

Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Resolve conflicts with doc updates.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Rename MODE_UNVERIFIED to MODE_STALE

MODE_UNVERIFIED actually means that the mode came from a previous probe,
and if the new probe doesn't produce a matching mode it will get pruned
from the list. Rename the flag to MODE_STALE to better convey the
meaning.

v2: Rebased due to conflicts with Daniel's doc stuff

Cc: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449779948-10906-1-git-send-email-ville.syrjala@linux.intel.com

drm: Don't overwrite UNVERFIED mode status to OK

The way the mode probing works is this:
1. All modes currently on the mode list are marked as UNVERIFIED
2. New modes are on the probed_modes list (they start with
status OK)
3. Modes are moved from the probed_modes list to the actual
mode list. If a mode already on the mode list is deemed
to match one of the probed modes, the duplicate is dropped
and the mode status updated to OK. After this the
probed_modes list will be empty.
4. All modes on the mode list are verified to not violate any
constraints. Any that do are marked as such.
5. Any mode left with a non-OK status is pruned from the list,
with an appropriate debug message.

What all this means is that any mode on the original list that
didn't have a duplicate on the probed_modes list, should be left
with status UNVERFIED (or previously could have been left with
some other status, but never OK).

I broke that in
commit 05acaec334fc ("drm: Reorganize probed mode validation")
by always assigning something to the mode->status during the validation
step. So any mode from the old list that still passed the validation
would be left on the list with status OK in the end.

Fix this by not doing the basic mode validation unless the mode
already has status OK (meaning it came from the probed_modes list,
or at least a duplicate of it was on that list). This way we will
correctly prune away any mode from the old mode list that didn't
appear on the probed_modes list.

Cc: stable@vger.kernel.org
Cc: Adam Jackson <ajax@redhat.com>
Fixes: 05acaec334fc ("drm: Reorganize probed mode validation")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449177255-9515-2-git-send-email-ville.syrjala@linux.intel.com
Testcase: igt/kms_force_connector_basic/prune-stale-modes
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93332
[danvet: Also applying to drm-misc to avoid too much conflict hell -
there's a big pile of patches from Ville on top of this one.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Merge helper docbook into kerneldoc comments

Duplication is bad, luckily both help texts highlighted different
issues so the kerneldoc gained quite a bit!

While at it also sprinkle more references to the vtable structs around
and make it clear that legacy CRTC helpers are deprecated and which
functions to use instead.

v2: Spelling fixes and polish (Thierry).

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-6-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Thierry Reding <treding@nvidia.com>

drm: Reorganize helper vtables and their docs

Currently we have 4 helper libraries (probe, crtc, plane & atomic)
that all use the same helper vtables. And that's by necessity since we
don't want to litter the core structs with one ops pointer per helper
library. Also often the reuse the same hooks (like atomic does, to
facilite conversion from existing drivers using crtc and plane
helpers).

Given all that it doesn't make sense to put the docs for these next to
specific helpers. Instead extract them into a new header file and
section in the docbook, and add references to them everywhere.

Unfortunately kernel-doc complains when an include directive doesn't
find anything (and it does by dumping crap into the output file). We
have to remove the now empty includes to avoid that, instead of leaving
them in for future proofing.

v2: More OCD in ordering functions.

v3: Spelling plus collate copyright headers properly.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-4-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Thierry Reding <treding@nvidia.com>

drm: keep connector status change logging human readable

We've had human readable connector status change debug logging since

commit ed7951dc13aad4a14695ec8122e9f0e2ef25d39e
Author: Lespiau, Damien <damien.lespiau@intel.com>
Date: Fri May 10 12:36:42 2013 +0000

drm: Make the HPD status updates debug logs more readable

but

commit 162b6a57ac50eec236530a16c071ffa50e87362a
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jan 21 08:45:21 2015 +0100

drm/probe-helper: don't lose hotplug event

added a new one with just the numbers. Fix it.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449144003-2877-1-git-send-email-jani.nikula@intel.com

drm/sysfs: Send out uevent when connector->force changes

To avoid even more code duplication punt this all to the probe worker,
which needs some slight adjustment to also generate a uevent when the
status has changed to due connector->force.

v2: Instead of running the output_poll_work (which is kinda the wrong
thing and a layering violation since it's an internal of the probe
helpers), or calling ->detect (which is again a layering violation
since it's used only by probe helpers) just call the official
->fill_modes function, like a GET_CONNECTOR ioctl call.

v3: Restore the accidentally removed forced-probe for echo "detect" >
force.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447951610-12622-22-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Add a non-locking version of drm_kms_helper_poll_enable(), v2

drm_kms_helper_poll_enable() was converted to lock the mode_config
mutex in commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
("drm/probe-helper: Grab mode_config.mutex in poll_init/enable").

This disregarded the cases where this function is called from a context
where this mutex is already locked.

Add a non-locking version as well.

Changes since v1:
- use function name suffix '_locked' for the function that
is to be called from a locked context.

Signed-off-by: Egbert Eich <eich@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/probe-helper: Grab mode_config.mutex in poll_init/enable

So on first looks this seems superflous since drivers should ensure
correct ordering to not make this a problem. Otoh ordering constraints
between hdp, fbdev load and enabling polling are already tricky on
some hardware and it helps to be more robust.

But the real goal is to just shut up a locking WARN_ON I'd like to
add, which means init code gets some additional locks just for
uniformity.

v2: Also grab the lock for the public poll_enable, not just poll_init
which is used for resume, with the same justification.

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm: Add modeset object iterators

And roll them out across drm_* files. The point here isn't code
prettification (it helps with that too) but that some of these lists
aren't static any more. And having macros will gives us a convenient
place to put locking checks into.

I didn't add an iterator for props since that's only used by a
list_for_each_entry_safe in the driver teardown code.

Search&replace was done with the below cocci spatch. Note that there's
a bunch more places that didn't match and which would need some manual
changes, but I've intentially left these out for this mostly automated
patch.

iterator name drm_for_each_crtc;
struct drm_crtc *crtc;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
+ drm_for_each_crtc (crtc, dev) {
...
}

@@
iterator name drm_for_each_encoder;
struct drm_encoder *encoder;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
+ drm_for_each_encoder (encoder, dev) {
...
}

@@
iterator name drm_for_each_fb;
struct drm_framebuffer *fb;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(fb, &dev->mode_config.fb_list, head) {
+ drm_for_each_fb (fb, dev) {
...
}

@@
iterator name drm_for_each_connector;
struct drm_connector *connector;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ drm_for_each_connector (connector, dev) {
...
}

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

DRM: Don't re-poll connector for disconnect

DRM probe should not repoll a connector if it is already
connected and the DRM_CONNECTOR_POLL_DISCONNECT flag is not set.

Signed-off-by: Josef Holzmayr <holzmayr@rsi-elektrotechnik.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/drm: constify all struct drm_*_helper funcs pointers

They are not to be modified.

Generated using the semantic patch:

@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)

@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_encoder_helper_funcs *
)

@@
@@
(
const struct drm_connector_helper_funcs *
|
- struct drm_connector_helper_funcs *
+ const struct drm_connector_helper_funcs *
)

@@
@@
(
const struct drm_plane_helper_funcs *
|
- struct drm_plane_helper_funcs *
+ const struct drm_plane_helper_funcs *
)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/edid: set ELD for firmware and debugfs override EDIDs

If the user supplies EDID through firmware or debugfs override, the
driver callbacks are bypassed and the connector ELD does not get
updated, and audio fails. Set ELD for firmware and debugfs EDIDs too.

There should be no harm in gratuitously doing this for non HDMI/DP
connectors, as it's still up to the driver to use the ELD, if any.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82349
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=80691
Reported-by: Emil <emilsvennesson@gmail.com>
Reported-by: Rob Engle <grenoble@gmail.com>
Tested-by: Jolan Luff <jolan@gormsby.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/probe-helper: clamp unknown connector status in the poll work

On some chipset we try to avoid possibly invasive output detection
methods (like load detect which can cause flickering elsewhere) in the
output poll work. Drivers could hence return unknown when a previous
full ->detect call returned a different state.

This change will generate a hotplug event, forcing userspace to do a
full scan. This in turn updates the connector->status field so that we
will _again_ get a state change when the hotplug work re-runs in 10
seconds.

To avoid this ping-pong loop detect this situation and clamp the
connector state to the old value.

Patch is inspired by a patch from Knut Peterson. Knut's patch
completely ignored connector state changes if either the old or new
status was unknown, which seemed to be a bit too agressive to me.

v2: Rebased onto the drm_probe_helper.c extraction.

References: http://lists.freedesktop.org/archives/dri-devel/2012-August/025975.html
Cc: Knut Petersen <Knut_Petersen@t-online.de>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/probe-helper: don't lose hotplug event

There's a race window (small for hpd, 10s large for polled outputs)
where userspace could sneak in with an unrelated connnector probe
ioctl call and eat the hotplug event (since neither the hpd nor the
poll code see a state change).

To avoid this, check whether the connector state changes in all other
->detect calls (in the current helper code that's only probe_single)
and if that's the case, fire off a hotplug event. Note that we can't
directly call the hotplug event handler, since that expects that no
locks are held (due to reentrancy with the fb code to update the kms
console).

Also, this requires that drivers using the probe_single helper
function set up the poll work. All current drivers do that already,
and with the reworked hpd handling there'll be no downside to
unconditionally setting up the poll work any more.

v2: Review from Rob Clark
- Don't bail out of the output poll work immediately if it's disabled
to make sure we deliver the delayed hoptplug events. Instead just
jump to the tail.
- Don't scheduel the work when it's not set up. Would be a driver bug
since using probe helpers for anything dynamic without them
initialized makes them all noops.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Perform basic sanity checks on probed modes

Make sure the timings of probed modes at least pass some very basic
sanity checks.

The checks include:
- clock,hdisplay,vdisplay are non zero
- sync pulse fits within the blanking period
- htotal,vtotal are big enough

I have not checked all the drivers to see if the modes the generate
might violate these constraints. I'm hoping not, because that would mean
either abandoning the idea of doing this from the core code, or fixing
the drivers.

I'm not entirely sure about limiting the sync pulse to the blanking
period. Intel hardware doesn't support such things, but some other
hardware might. However at least HDMI doesn't allow having sync pulse
edges within the active period, so I'm thinking the check is probably
OK to have in the common code.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Reorganize probed mode validation

Make drm_mode_validate_size() and drm_mode_validate_flag() deal with a
single mode instead of having each iterate through the mode list.

The hope is that in the future we might be able to share various mode
validation functions between modeset and get_modes.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Fix DRM_FORCE_ON_DIGITAL use

A connector may be forced on from the command line via video=
command line setting. The digital output of dual-mode connectors
can also be specifically selected and forced on; eg., 'video=DVI-I-2:D'.
However, in this case, the connector->status will be mistakenly set to
connector_status_disconnected, and the connector will not be mode set.

Fix the connector->status when connector->force is DRM_FORCE_ON_DIGITAL.

Note that this seems to have been broken ever since the introduction
of the connector forcing support in

commit d50ba256b5f1478e15accfcfda9b72fd7a661364
Author: Dave Airlie <airlied@linux.ie>
Date: Wed Sep 23 14:44:08 2009 +1000

drm/kms: start adding command line interface using fb.

Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
[danvet: Add note about that this never worked.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Perform cmdline mode parsing during connector initialisation

i915.ko has a custom fbdev initialisation routine that aims to preserve
the current mode set by the BIOS, unless overruled by the user. The
user's wishes are determined by what, if any, mode is specified on the
command line (via the video= parameter). However, that command line mode
is first parsed by drm_fb_helper_initial_config() which is called after
i915.ko's custom initial_config() as a fallback method. So in order for
us to honour it, we need to move the cmdline parser earlier. If we
perform the connector cmdline parsing as soon as we initialise the
connector, that cmdline mode and forced status is then available even if
the fbdev helper is not compiled in or never called.

We also then expose the cmdline user mode in the connector mode lists.

v2: Rebase after connector->name upheaval.

v3: Adapt mga200 to look for the cmdline mode in the new place. Nicely
simplifies things while at that.

v4: Fix checkpatch.

v5: Select FB_CMDLINE to adapt to the changed fbdev patch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)
Cc: dri-devel@lists.freedesktop.org
Cc: Julia Lemire <jlemire@matrox.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/debugfs: add an "edid_override" file per connector

Add a file to debugfs for each connector to allow the EDID to be
overridden.

v2: Copy ubuf before accessing it and reject invalid length data. (David
Herrmann)
Ensure override_edid is reset when a new EDID value is written.
(David Herrmann)
Fix the debugfs file permissions. (David Herrmann)

Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: replace drm_get_connector_name() with direct name field use

Generated using semantic patch:

@@
expression E;
@@

- drm_get_connector_name(E)
+ E->name

[airlied: regenerated]

Acked-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: try harder to avoid regression when merging mode bits

For QXL hw we really want the bits to be replaced as we change
the preferred mode on the fly, and the same goes for virgl when
I get to it, however the original fix for this seems to have caused
a wierd regression on Intel G33 that in a stunning display of failure
at opposition to his normal self, Daniel failed to diagnose.

So we are left doing this, ugly ugly ugly ugly, Daniel you fixed
that G33 yet?, ugly, ugly.

Tested-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: make mode_valid callback optional

Many drm connectors do not need mode validation.
The patch makes this callback optional and removes dumb implementations.

v2: Rebase:
- imx move to a shared (but still dummy) ->mode_valid implementation.
- probe helpers have been extracted to drm_probe_helper.c

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Split out drm_probe_helper.c from drm_crtc_helper.c

This is leftover stuff from my previous doc round which I kinda wanted
to do but didn't yet due to rebase hell.

The modeset helpers and the probing helpers a independent and e.g.
i915 uses the probing stuff but has its own modeset infrastructure. It
hence makes to split this up. While at it add a DOC: comment for the
probing libraray.

It would be rather neat to pull some of the DocBook documenting these
two helpers into in-line DOC: comments. But unfortunately kerneldoc
doesn't support markdown or something similar to make nice-looking
documentation, so the current state is better.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>