<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/meson, branch linux-4.20.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.20.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.20.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-02-27T09:09:48+00:00</updated>
<entry>
<title>drm/meson: add missing of_node_put</title>
<updated>2019-02-27T09:09:48+00:00</updated>
<author>
<name>Julia Lawall</name>
<email>Julia.Lawall@lip6.fr</email>
</author>
<published>2019-01-13T09:44:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9d719d77b5f4145cc3b5c6c452c0034fbff4c7d2'/>
<id>urn:sha1:9d719d77b5f4145cc3b5c6c452c0034fbff4c7d2</id>
<content type='text'>
[ Upstream commit f672b93e4a0a4947d2e1103ed8780e01e13eadb6 ]

Add an of_node_put when the result of of_graph_get_remote_port_parent is
not available.

An of_node_put is also needed when meson_probe_remote completes.  This was
present at the recursive call, but not in the call from meson_drv_probe.

The semantic match that finds this problem is as follows
(http://coccinelle.lip6.fr):

// &lt;smpl&gt;
@r exists@
local idexpression e;
expression x;
@@
e = of_graph_get_remote_port_parent(...);
... when != x = e
    when != true e == NULL
    when != of_node_put(e)
    when != of_fwnode_handle(e)
(
return e;
|
*return ...;
)
// &lt;/smpl&gt;

Signed-off-by: Julia Lawall &lt;Julia.Lawall@lip6.fr&gt;
Acked-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Signed-off-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/1547372691-28324-4-git-send-email-Julia.Lawall@lip6.fr
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/meson: Fix atomic mode switching regression</title>
<updated>2019-01-31T07:15:44+00:00</updated>
<author>
<name>Neil Armstrong</name>
<email>narmstrong@baylibre.com</email>
</author>
<published>2019-01-14T15:31:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ecb4e06baf40803ac063b54f2e9d88da5e9843f3'/>
<id>urn:sha1:ecb4e06baf40803ac063b54f2e9d88da5e9843f3</id>
<content type='text'>
commit ce0210c12433031aba3bbacd75f4c02ab77f2004 upstream.

Since commit 2bcd3ecab773 when switching mode from X11 (ubuntu mate for
example) the display gets blurry, looking like an invalid framebuffer width.

This commit fixed atomic crtc modesetting in a totally wrong way and
introduced a local unnecessary -&gt;enabled crtc state.

This commit reverts the crctc _begin() and _enable() changes and simply
adds drm_atomic_helper_commit_tail_rpm as helper.

Reported-by: Tony McKahan &lt;tonymckahan@gmail.com&gt;
Suggested-by: Daniel Vetter &lt;daniel@ffwll.ch&gt;
Fixes: 2bcd3ecab773 ("drm/meson: Fixes for drm_crtc_vblank_on/off support")
Signed-off-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
[narmstrong: fixed blank line issue from checkpatch]
Link: https://patchwork.freedesktop.org/patch/msgid/20190114153118.8024-1-narmstrong@baylibre.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/meson: add support for 1080p25 mode</title>
<updated>2018-11-26T21:14:28+00:00</updated>
<author>
<name>Christian Hewitt</name>
<email>christianshewitt@gmail.com</email>
</author>
<published>2018-11-21T09:39:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=31e1ab494559fb46de304cc6c2aed1528f94b298'/>
<id>urn:sha1:31e1ab494559fb46de304cc6c2aed1528f94b298</id>
<content type='text'>
This essential mode for PAL users is missing, so add it.

Fixes: 335e3713afb87 ("drm/meson: Add support for HDMI venc modes and settings")
Signed-off-by: Christian Hewitt &lt;christianshewitt@gmail.com&gt;
Acked-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Signed-off-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/1542793169-13008-1-git-send-email-christianshewitt@gmail.com
Signed-off-by: Sean Paul &lt;seanpaul@chromium.org&gt;
</content>
</entry>
<entry>
<title>drm/meson: Fix OOB memory accesses in meson_viu_set_osd_lut()</title>
<updated>2018-11-26T21:14:28+00:00</updated>
<author>
<name>Lyude Paul</name>
<email>lyude@redhat.com</email>
</author>
<published>2018-11-25T01:21:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=97b2a3180a559a33852ac0cd77904166069484fd'/>
<id>urn:sha1:97b2a3180a559a33852ac0cd77904166069484fd</id>
<content type='text'>
Currently on driver bringup with KASAN enabled, meson triggers an OOB
memory access as shown below:

[  117.904528] ==================================================================
[  117.904560] BUG: KASAN: global-out-of-bounds in meson_viu_set_osd_lut+0x7a0/0x890
[  117.904588] Read of size 4 at addr ffff20000a63ce24 by task systemd-udevd/498
[  117.904601]
[  118.083372] CPU: 4 PID: 498 Comm: systemd-udevd Not tainted 4.20.0-rc3Lyude-Test+ #20
[  118.091143] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
[  118.099768] Call trace:
[  118.102181]  dump_backtrace+0x0/0x3e8
[  118.105796]  show_stack+0x14/0x20
[  118.109083]  dump_stack+0x130/0x1c4
[  118.112539]  print_address_description+0x60/0x25c
[  118.117214]  kasan_report+0x1b4/0x368
[  118.120851]  __asan_report_load4_noabort+0x18/0x20
[  118.125566]  meson_viu_set_osd_lut+0x7a0/0x890
[  118.129953]  meson_viu_init+0x10c/0x290
[  118.133741]  meson_drv_bind_master+0x474/0x748
[  118.138141]  meson_drv_bind+0x10/0x18
[  118.141760]  try_to_bring_up_master+0x3d8/0x768
[  118.146249]  component_add+0x214/0x570
[  118.149978]  meson_dw_hdmi_probe+0x18/0x20 [meson_dw_hdmi]
[  118.155404]  platform_drv_probe+0x98/0x138
[  118.159455]  really_probe+0x2a0/0xa70
[  118.163070]  driver_probe_device+0x1b4/0x2d8
[  118.167299]  __driver_attach+0x200/0x280
[  118.171189]  bus_for_each_dev+0x10c/0x1a8
[  118.175144]  driver_attach+0x38/0x50
[  118.178681]  bus_add_driver+0x330/0x608
[  118.182471]  driver_register+0x140/0x388
[  118.186361]  __platform_driver_register+0xc8/0x108
[  118.191117]  meson_dw_hdmi_platform_driver_init+0x1c/0x1000 [meson_dw_hdmi]
[  118.198022]  do_one_initcall+0x12c/0x3bc
[  118.201883]  do_init_module+0x1fc/0x638
[  118.205673]  load_module+0x4b4c/0x6808
[  118.209387]  __se_sys_init_module+0x2e8/0x3c0
[  118.213699]  __arm64_sys_init_module+0x68/0x98
[  118.218100]  el0_svc_common+0x104/0x210
[  118.221893]  el0_svc_handler+0x48/0xb8
[  118.225594]  el0_svc+0x8/0xc
[  118.228429]
[  118.229887] The buggy address belongs to the variable:
[  118.235007]  eotf_33_linear_mapping+0x84/0xc0
[  118.239301]
[  118.240752] Memory state around the buggy address:
[  118.245522]  ffff20000a63cd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  118.252695]  ffff20000a63cd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  118.259850] &gt;ffff20000a63ce00: 00 00 00 00 04 fa fa fa fa fa fa fa 00 00 00 00
[  118.267000]                                ^
[  118.271222]  ffff20000a63ce80: 00 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
[  118.278393]  ffff20000a63cf00: 00 00 00 00 00 00 00 00 00 00 00 00 04 fa fa fa
[  118.285542] ==================================================================
[  118.292699] Disabling lock debugging due to kernel taint

It seems that when looping through the OSD EOTF LUT maps, we use the
same max iterator for OETF: 20. This is wrong though, since 20*2 is 40,
which means that we'll stop out of bounds on the EOTF maps.

But, this whole thing is already confusing enough to read through as-is,
so let's just replace all of the hardcoded sizes with
OSD_(OETF/EOTF)_LUT_SIZE / 2.

Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Cc: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Cc: Maxime Ripard &lt;maxime.ripard@bootlin.com&gt;
Cc: Carlo Caione &lt;carlo@caione.org&gt;
Cc: Kevin Hilman &lt;khilman@baylibre.com&gt;
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: &lt;stable@vger.kernel.org&gt; # v4.10+
Acked-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Signed-off-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20181125012117.31915-1-lyude@redhat.com
Signed-off-by: Sean Paul &lt;seanpaul@chromium.org&gt;
</content>
</entry>
<entry>
<title>drm/meson: Enable fast_io in meson_dw_hdmi_regmap_config</title>
<updated>2018-11-26T21:14:27+00:00</updated>
<author>
<name>Lyude Paul</name>
<email>lyude@redhat.com</email>
</author>
<published>2018-11-24T19:12:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=995b278e4723b26f8ebf0e7c119286d16c712747'/>
<id>urn:sha1:995b278e4723b26f8ebf0e7c119286d16c712747</id>
<content type='text'>
Seeing as we use this registermap in the context of our IRQ handlers, we
need to be using spinlocks for reading/writing registers so that we can
still read them from IRQ handlers without having to grab any mutexes and
accidentally sleep. We don't currently do this, as pointed out by
lockdep:

[   18.403770] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908
[   18.406744] in_atomic(): 1, irqs_disabled(): 128, pid: 68, name: kworker/u17:0
[   18.413864] INFO: lockdep is turned off.
[   18.417675] irq event stamp: 12
[   18.420778] hardirqs last  enabled at (11): [&lt;ffff000008a4f57c&gt;] _raw_spin_unlock_irq+0x2c/0x60
[   18.429510] hardirqs last disabled at (12): [&lt;ffff000008a48914&gt;] __schedule+0xc4/0xa60
[   18.437345] softirqs last  enabled at (0): [&lt;ffff0000080b55e0&gt;] copy_process.isra.4.part.5+0x4d8/0x1c50
[   18.446684] softirqs last disabled at (0): [&lt;0000000000000000&gt;]           (null)
[   18.453979] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: G        W  O      4.20.0-rc3Lyude-Test+ #9
[   18.469839] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
[   18.480037] Workqueue: hci0 hci_power_on [bluetooth]
[   18.487138] Call trace:
[   18.494192]  dump_backtrace+0x0/0x1b8
[   18.501280]  show_stack+0x14/0x20
[   18.508361]  dump_stack+0xbc/0xf4
[   18.515427]  ___might_sleep+0x140/0x1d8
[   18.522515]  __might_sleep+0x50/0x88
[   18.529582]  __mutex_lock+0x60/0x870
[   18.536621]  mutex_lock_nested+0x1c/0x28
[   18.543660]  regmap_lock_mutex+0x10/0x18
[   18.550696]  regmap_read+0x38/0x70
[   18.557727]  dw_hdmi_hardirq+0x58/0x138 [dw_hdmi]
[   18.564804]  __handle_irq_event_percpu+0xac/0x410
[   18.571891]  handle_irq_event_percpu+0x34/0x88
[   18.578982]  handle_irq_event+0x48/0x78
[   18.586051]  handle_fasteoi_irq+0xac/0x160
[   18.593061]  generic_handle_irq+0x24/0x38
[   18.599989]  __handle_domain_irq+0x60/0xb8
[   18.606857]  gic_handle_irq+0x50/0xa0
[   18.613659]  el1_irq+0xb4/0x130
[   18.620394]  debug_lockdep_rcu_enabled+0x2c/0x30
[   18.627111]  schedule+0x38/0xa0
[   18.633781]  schedule_timeout+0x3a8/0x510
[   18.640389]  wait_for_common+0x15c/0x180
[   18.646905]  wait_for_completion+0x14/0x20
[   18.653319]  mmc_wait_for_req_done+0x28/0x168
[   18.659693]  mmc_wait_for_req+0xa8/0xe8
[   18.665978]  mmc_wait_for_cmd+0x64/0x98
[   18.672180]  mmc_io_rw_direct_host+0x94/0x130
[   18.678385]  mmc_io_rw_direct+0x10/0x18
[   18.684516]  sdio_enable_func+0xe8/0x1d0
[   18.690627]  btsdio_open+0x24/0xc0 [btsdio]
[   18.696821]  hci_dev_do_open+0x64/0x598 [bluetooth]
[   18.703025]  hci_power_on+0x50/0x270 [bluetooth]
[   18.709163]  process_one_work+0x2a0/0x6e0
[   18.715252]  worker_thread+0x40/0x448
[   18.721310]  kthread+0x12c/0x130
[   18.727326]  ret_from_fork+0x10/0x1c
[   18.735555] ------------[ cut here ]------------
[   18.741430] do not call blocking ops when !TASK_RUNNING; state=2 set at [&lt;000000006265ec59&gt;] wait_for_common+0x140/0x180
[   18.752417] WARNING: CPU: 0 PID: 68 at kernel/sched/core.c:6096 __might_sleep+0x7c/0x88
[   18.760553] Modules linked in: dm_mirror dm_region_hash dm_log dm_mod
btsdio bluetooth snd_soc_hdmi_codec dw_hdmi_i2s_audio ecdh_generic
brcmfmac brcmutil cfg80211 rfkill ir_nec_decoder meson_dw_hdmi(O)
dw_hdmi rc_geekbox meson_rng meson_ir ao_cec rng_core rc_core cec
leds_pwm efivars nfsd ip_tables x_tables crc32_generic f2fs uas
meson_gxbb_wdt pwm_meson efivarfs ipv6
[   18.799469] CPU: 0 PID: 68 Comm: kworker/u17:0 Tainted: G        W  O      4.20.0-rc3Lyude-Test+ #9
[   18.808858] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
[   18.818045] Workqueue: hci0 hci_power_on [bluetooth]
[   18.824088] pstate: 80000085 (Nzcv daIf -PAN -UAO)
[   18.829891] pc : __might_sleep+0x7c/0x88
[   18.835722] lr : __might_sleep+0x7c/0x88
[   18.841256] sp : ffff000008003cb0
[   18.846751] x29: ffff000008003cb0 x28: 0000000000000000
[   18.852269] x27: ffff00000938e000 x26: ffff800010283000
[   18.857726] x25: ffff800010353280 x24: ffff00000868ef50
[   18.863166] x23: 0000000000000000 x22: 0000000000000000
[   18.868551] x21: 0000000000000000 x20: 000000000000038c
[   18.873850] x19: ffff000008cd08c0 x18: 0000000000000010
[   18.879081] x17: ffff000008a68cb0 x16: 0000000000000000
[   18.884197] x15: 0000000000aaaaaa x14: 0e200e200e200e20
[   18.889239] x13: 0000000000000001 x12: 00000000ffffffff
[   18.894261] x11: ffff000008adfa48 x10: 0000000000000001
[   18.899517] x9 : ffff0000092a0158 x8 : 0000000000000000
[   18.904674] x7 : ffff00000812136c x6 : 0000000000000000
[   18.909895] x5 : 0000000000000000 x4 : 0000000000000001
[   18.915080] x3 : 0000000000000007 x2 : 0000000000000007
[   18.920269] x1 : 99ab8e9ebb6c8500 x0 : 0000000000000000
[   18.925443] Call trace:
[   18.929904]  __might_sleep+0x7c/0x88
[   18.934311]  __mutex_lock+0x60/0x870
[   18.938687]  mutex_lock_nested+0x1c/0x28
[   18.943076]  regmap_lock_mutex+0x10/0x18
[   18.947453]  regmap_read+0x38/0x70
[   18.951842]  dw_hdmi_hardirq+0x58/0x138 [dw_hdmi]
[   18.956269]  __handle_irq_event_percpu+0xac/0x410
[   18.960712]  handle_irq_event_percpu+0x34/0x88
[   18.965176]  handle_irq_event+0x48/0x78
[   18.969612]  handle_fasteoi_irq+0xac/0x160
[   18.974058]  generic_handle_irq+0x24/0x38
[   18.978501]  __handle_domain_irq+0x60/0xb8
[   18.982938]  gic_handle_irq+0x50/0xa0
[   18.987351]  el1_irq+0xb4/0x130
[   18.991734]  debug_lockdep_rcu_enabled+0x2c/0x30
[   18.996180]  schedule+0x38/0xa0
[   19.000609]  schedule_timeout+0x3a8/0x510
[   19.005064]  wait_for_common+0x15c/0x180
[   19.009513]  wait_for_completion+0x14/0x20
[   19.013951]  mmc_wait_for_req_done+0x28/0x168
[   19.018402]  mmc_wait_for_req+0xa8/0xe8
[   19.022809]  mmc_wait_for_cmd+0x64/0x98
[   19.027177]  mmc_io_rw_direct_host+0x94/0x130
[   19.031563]  mmc_io_rw_direct+0x10/0x18
[   19.035922]  sdio_enable_func+0xe8/0x1d0
[   19.040294]  btsdio_open+0x24/0xc0 [btsdio]
[   19.044742]  hci_dev_do_open+0x64/0x598 [bluetooth]
[   19.049228]  hci_power_on+0x50/0x270 [bluetooth]
[   19.053687]  process_one_work+0x2a0/0x6e0
[   19.058143]  worker_thread+0x40/0x448
[   19.062608]  kthread+0x12c/0x130
[   19.067064]  ret_from_fork+0x10/0x1c
[   19.071513] irq event stamp: 12
[   19.075937] hardirqs last  enabled at (11): [&lt;ffff000008a4f57c&gt;] _raw_spin_unlock_irq+0x2c/0x60
[   19.083560] hardirqs last disabled at (12): [&lt;ffff000008a48914&gt;] __schedule+0xc4/0xa60
[   19.091401] softirqs last  enabled at (0): [&lt;ffff0000080b55e0&gt;] copy_process.isra.4.part.5+0x4d8/0x1c50
[   19.100801] softirqs last disabled at (0): [&lt;0000000000000000&gt;]           (null)
[   19.108135] ---[ end trace 38c4920787b88c75 ]---

So, fix this by enabling the fast_io option in our regmap config so that
regmap uses spinlocks for locking instead of mutexes.

Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Fixes: 3f68be7d8e96 ("drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY")
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Cc: Carlo Caione &lt;carlo@caione.org&gt;
Cc: Kevin Hilman &lt;khilman@baylibre.com&gt;
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: &lt;stable@vger.kernel.org&gt; # v4.12+
Acked-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Signed-off-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20181124191238.28276-1-lyude@redhat.com
Signed-off-by: Sean Paul &lt;seanpaul@chromium.org&gt;
</content>
</entry>
<entry>
<title>drm/meson: Fixes for drm_crtc_vblank_on/off support</title>
<updated>2018-11-26T21:14:27+00:00</updated>
<author>
<name>Neil Armstrong</name>
<email>narmstrong@baylibre.com</email>
</author>
<published>2018-11-22T16:01:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2bcd3ecab773f73211c45bb1430bb52ac641f271'/>
<id>urn:sha1:2bcd3ecab773f73211c45bb1430bb52ac641f271</id>
<content type='text'>
Since Linux 4.17, calls to drm_crtc_vblank_on/off are mandatory, and we get
a warning when ctrc is disabled :
" driver forgot to call drm_crtc_vblank_off()"

But, the vsync IRQ was not totally disabled due the transient hardware
state and specific interrupt line, thus adding proper IRQ masking from
the HHI system control registers.

The last change fixes a race condition introduced by calling the added
drm_crtc_vblank_on/off when an HPD event occurs from the HDMI connector,
triggering a WARN_ON() in the _atomic_begin() callback when the CRTC
is disabled, thus also triggering a WARN_ON() in drm_vblank_put() :

WARNING: CPU: 0 PID: 1185 at drivers/gpu/drm/meson/meson_crtc.c:157 meson_crtc_atomic_begin+0x78/0x80
[...]
Call trace:
  meson_crtc_atomic_begin+0x78/0x80
  drm_atomic_helper_commit_planes+0x140/0x218
  drm_atomic_helper_commit_tail+0x38/0x80
  commit_tail+0x7c/0x80
  drm_atomic_helper_commit+0xdc/0x150
  drm_atomic_commit+0x54/0x60
  restore_fbdev_mode_atomic+0x198/0x238
  restore_fbdev_mode+0x6c/0x1c0
  drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xf0
  drm_fb_helper_set_par+0x34/0x60
  drm_fb_helper_hotplug_event.part.28+0xb8/0xc8
  drm_fbdev_client_hotplug+0xa4/0xe0
  drm_client_dev_hotplug+0x90/0xe0
  drm_kms_helper_hotplug_event+0x3c/0x48
  drm_helper_hpd_irq_event+0x134/0x168
  dw_hdmi_top_thread_irq+0x3c/0x50
[...]
WARNING: CPU: 0 PID: 1185 at drivers/gpu/drm/drm_vblank.c:1026 drm_vblank_put+0xb4/0xc8
[...]
 Call trace:
  drm_vblank_put+0xb4/0xc8
  drm_crtc_vblank_put+0x24/0x30
  drm_atomic_helper_wait_for_vblanks.part.9+0x130/0x2b8
  drm_atomic_helper_commit_tail+0x68/0x80
[...]

The issue is that vblank need to be enabled in any occurrence of :
- atomic_enable()
- atomic_begin() and state-&gt;enable == true, which was not the case

Moving the CRTC enable code to a common function and calling in one of
these occurrence solves this race condition and makes sure vblank is
enabled in each call to _atomic_begin() from the HPD event leading to
drm_atomic_helper_commit_planes().

To Summarize :
- Make sure that the CRTC code will call the drm_crtc_vblank_on()/off()
- *Really* mask the Vsync IRQ
- Initialize and enable vblank at the first
  atomic_begin()/_atomic_enable()

Cc: stable@vger.kernel.org # 4.17+
Signed-off-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Reviewed-by: Lyude Paul &lt;lyude@redhat.com&gt;
[fixed typos+added cc for stable]
Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20181122160103.10993-1-narmstrong@baylibre.com
Signed-off-by: Sean Paul &lt;seanpaul@chromium.org&gt;
</content>
</entry>
<entry>
<title>drm/meson: venc: dmt mode must use encp</title>
<updated>2018-11-13T09:52:33+00:00</updated>
<author>
<name>Jorge Ramirez-Ortiz</name>
<email>jorge.ramirez.ortiz@gmail.com</email>
</author>
<published>2018-11-12T18:41:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=adf59dd2408c4536d490bee649784f0465562444'/>
<id>urn:sha1:adf59dd2408c4536d490bee649784f0465562444</id>
<content type='text'>
The video mode for DMT is only populated to support encp.

Signed-off-by: Jorge Ramirez-Ortiz &lt;jorge.ramirez.ortiz@gmail.com&gt;
Acked-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Signed-off-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/1542048069-22603-1-git-send-email-jramirez@baylibre.com
</content>
</entry>
<entry>
<title>drm/meson: Make DMT timings parameters and pixel clock generic</title>
<updated>2018-07-16T09:14:59+00:00</updated>
<author>
<name>Neil Armstrong</name>
<email>narmstrong@baylibre.com</email>
</author>
<published>2018-07-16T07:40:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3273fc63e1ed4866fe10a582f4203f2aa142b216'/>
<id>urn:sha1:3273fc63e1ed4866fe10a582f4203f2aa142b216</id>
<content type='text'>
Remove the modes timings tables for DMT modes and calculate the HW
paremeters from the modes timings.

Switch the DMT modes pixel clock calculation out of the static frequency
list to a generic calculation from a range of possible PLL dividers.

This patch is an intermediate step towards usage of the Common Clock
Framwework for PLL setup, by reworking the code to have common
sel_pll() function called by the CEA (HDMI) freq setup and the generic
DMT frequencies setup, we should be able to simply call clk_set_rate()
on the PLL clock handle in a near future.

The CEA (HDMI) and CVBS modes needs very specific clock paths that CCF will
never be able to determine by itself, so there is still some work to do for
a full handoff to CCF handling the clocks.

This setup permits setting non-CEA modes like :
- 1600x900-60Hz
- 1280x1024-75Hz
- 1280x1024-60Hz
- 1440x900-60Hz
- 1366x768-60Hz
- 1280x800-60Hz
- 1152x864-75Hz
- 1024x768-75Hz
- 1024x768-70Hz
- 1024x768-60Hz
- 832x624-75Hz
- 800x600-75Hz
- 800x600-72Hz
- 800x600-60Hz
- 640x480-75Hz
- 640x480-73Hz
- 640x480-67Hz

Signed-off-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Acked-by: Jerome Brunet &lt;jbrunet@baylibre.com&gt;
[narmstrong: fixed trivial checkpatch issues]
Link: https://patchwork.freedesktop.org/patch/msgid/1531726814-14638-1-git-send-email-narmstrong@baylibre.com
</content>
</entry>
<entry>
<title>drm: drop _mode_ from drm_mode_connector_attach_encoder</title>
<updated>2018-07-13T16:40:27+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2018-07-09T08:40:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cde4c44d8769c1be16074c097592c46c7d64092b'/>
<id>urn:sha1:cde4c44d8769c1be16074c097592c46c7d64092b</id>
<content type='text'>
Again to align with the usual prefix of just drm_connector_. Again
done with sed + manual fixup for indent issues.

Reviewed-by: Sean Paul &lt;seanpaul@chromium.org&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-7-daniel.vetter@ffwll.ch
</content>
</entry>
<entry>
<title>drm/meson: Fix an un-handled error path in 'meson_drv_bind_master()'</title>
<updated>2018-06-26T08:22:29+00:00</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2018-06-11T16:53:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=01a9e9493fb3f65c07077d59cf8ba8b6d2e0463e'/>
<id>urn:sha1:01a9e9493fb3f65c07077d59cf8ba8b6d2e0463e</id>
<content type='text'>
If 'platform_get_resource_byname()' fails, we should release some resources
before leaving, as already done in the other error handling path of the
function.

Fixes: acaa3f13b8dd ("drm/meson: Fix potential NULL dereference in meson_drv_bind_master()")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Acked-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Signed-off-by: Neil Armstrong &lt;narmstrong@baylibre.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180611165335.24542-1-christophe.jaillet@wanadoo.fr
</content>
</entry>
</feed>
