linux-stable.git/drivers/gpu/drm/arm, branch linux-4.9.y

drm/arm/hdlcd: Allow a bit of clock tolerance

2019-07-10T07:55:30+00:00

[ Upstream commit 1c810739097fdeb31b393b67a0a1e3d7ffdd9f63 ]

On the Arm Juno platform, the HDLCD pixel clock is constrained to 250KHz
resolution in order to avoid the tiny System Control Processor spending
aeons trying to calculate exact PLL coefficients. This means that modes
like my oddball 1600x1200 with 130.89MHz clock get rejected since the
rate cannot be matched exactly. In practice, though, this mode works
quite happily with the clock at 131MHz, so let's relax the check to
allow a little bit of slop.

Signed-off-by: Robin Murphy 
Signed-off-by: Liviu Dudau 
Signed-off-by: Sasha Levin

drm: mali-dp: Call drm_crtc_vblank_reset on device init

2018-10-20T07:51:31+00:00

[ Upstream commit 69be1984ded00a11b1ed0888c6d8e4f35370372f ]

Currently, if userspace calls drm_wait_vblank before the crtc is
activated the crtc vblank_enable hook is called, which in case of
malidp driver triggers some warninngs. This happens because on
device init we don't inform the drm core about the vblank state
by calling drm_crtc_vblank_on/off/reset which together with
drm_vblank_get have some magic that prevents calling drm_vblank_enable
when crtc is off.

Signed-off-by: Alexandru Gheorghe 
Acked-by: Liviu Dudau 
Signed-off-by: Liviu Dudau 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm: mali-dp: Enable Global SE interrupts mask for DP500

2018-08-24T11:12:28+00:00

[ Upstream commit 89610dc2c235e7b02bb9fba0ce247e12d4dde7cd ]

In the situation that DE and SE aren’t shared the same interrupt number,
the Global SE interrupts mask bit MASK_IRQ_EN in MASKIRQ must be set, or
else other mask bits will not work and no SE interrupt will occur. This
patch enables MASK_IRQ_EN for SE to fix this problem.

Signed-off-by: Alison Wang 
Acked-by: Liviu Dudau 
Signed-off-by: Liviu Dudau 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm: mali-dp: fix Lx_CONTROL register fields clobber

2017-11-15T14:53:13+00:00

[ Upstream commit c7ffa59cf03c38b91d6ef01e42c1b52fd7a4f285 ]

When updating the rotation fields, one of the assignments zeroes out the
rest of the register fields, which include settings for chroma siting,
inverse gamma, AMBA AXI caching, and alpha blending.

Signed-off-by: Mihail Atanassov 
Signed-off-by: Liviu Dudau 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm: mali-dp: Fix transposed horizontal/vertical flip

2017-10-08T08:26:07+00:00

[ Upstream commit 7916efe5b57505080b3cebf5bdb228b4eda008ea ]

The horizontal and vertical flip flags were the wrong way around,
causing reflect-x to result in reflect-y being applied and vice-versa.
Fix them.

Fixes: ad49f8602fe8 ("drm/arm: Add support for Mali Display Processors")

Signed-off-by: Brian Starkey 
Signed-off-by: Liviu Dudau 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm: mali-dp: Fix destination size handling when rotating

2017-10-08T08:26:07+00:00

[ Upstream commit edabb3c4cd2d035bc93a3d67b25a304ea6217301 ]

The destination rectangle provided by userspace in the CRTC_X/Y/W/H
properties is already expressed as the dimensions after rotation.
This means we shouldn't swap the width and height ourselves when a
90/270 degree rotation is requested, so remove the code doing the swap.

Fixes: ad49f8602fe8 ("drm/arm: Add support for Mali Display Processors")

Signed-off-by: Brian Starkey 
Signed-off-by: Liviu Dudau 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm: hdlcd: Fix cleanup order

2016-11-25T15:51:57+00:00

If hdlcd_drm_bind() fails at drm_fbdev_cma_init(), its cleanup will call
drm_mode_config_cleanup() as if to balance drm_mode_config_reset(). The
net result is that drm_connector_cleanup() will clean up the active
connectors long before component_unbind_all() gets called, so when the
connector later tries to clean up itself after being unbound, Bad Things
can happen:

[    4.121888] Unable to handle kernel NULL pointer dereference at
virtual address 00000000
[    4.129951] pgd = ffffff80091e0000
[    4.133345] [00000000] *pgd=00000009ffffe003, *pud=00000009ffffe003,
*pmd=0000000000000000
[    4.141613] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[    4.147144] Modules linked in:
[    4.150188] CPU: 0 PID: 122 Comm: kworker/u12:2 Not tainted
4.8.0-rc2+ #989
[    4.157097] Hardware name: ARM Juno development board (r1) (DT)
[    4.162981] Workqueue: deferwq deferred_probe_work_func
[    4.168173] task: ffffffc975d93200 task.stack: ffffffc975dac000
[    4.174055] PC is at drm_connector_cleanup+0x58/0x1c0
[    4.179074] LR is at tda998x_unbind+0x24/0x40
[    4.183401] pc : [] lr : []
pstate: 00000045
[    4.190750] sp : ffffffc975dafa10
[    4.194041] x29: ffffffc975dafa10 x28: ffffffc9768152a8
[    4.199325] x27: ffffffc97ff46450 x26: ffffff8008d99000
[    4.204608] x25: dead000000000100 x24: dead000000000200
[    4.209891] x23: ffffffc976bf91e8 x22: 0000000000000000
[    4.215172] x21: ffffffc976bf9170 x20: ffffffc976bf9170
[    4.220454] x19: ffffffc976bf9018 x18: 0000000000000000
[    4.225737] x17: 0000000074ce71ee x16: 000000008ff5d35f
[    4.231019] x15: ffffffc97681e91c x14: ffffffffffffffff
[    4.236301] x13: ffffffc97681e185 x12: 0000000000000038
[    4.241583] x11: 0101010101010101 x10: 0000000000000000
[    4.246866] x9 : 0000000040000000 x8 : 0000000000210d00
[    4.252148] x7 : ffffffc97fea8c00 x6 : 000000000000001b
[    4.257430] x5 : ffffff80084b7b8c x4 : 0000000000000080
[    4.262712] x3 : ffffff8008504128 x2 : ffffffc975df3800
[    4.267993] x1 : 0000000000000000 x0 : 0000000000000000
...
[    4.750937] [] drm_connector_cleanup+0x58/0x1c0
[    4.756990] [] tda998x_unbind+0x24/0x40
[    4.762354] [] component_unbind.isra.4+0x28/0x50
[    4.768492] [] component_unbind_all+0xcc/0xd8
[    4.774373] [] hdlcd_drm_bind+0x234/0x418
[    4.779909] [] try_to_bring_up_master+0x140/0x1a0
[    4.786133] [] component_add+0x98/0x170
[    4.791496] [] tda998x_probe+0x18/0x20
[    4.796774] [] i2c_device_probe+0x164/0x258
[    4.802481] [] driver_probe_device+0x204/0x2b0
[    4.808447] [] __device_attach_driver+0x9c/0xf8
[    4.814498] [] bus_for_each_drv+0x58/0x98
[    4.820033] [] __device_attach+0xc4/0x138
[    4.825567] [] device_initial_probe+0x10/0x18
[    4.831446] [] bus_probe_device+0x94/0xa0
[    4.836981] [] deferred_probe_work_func+0x78/0xb0
[    4.843207] [] process_one_work+0x118/0x378
[    4.848914] [] worker_thread+0x48/0x498
[    4.854276] [] kthread+0xd0/0xe8
[    4.859036] [] ret_from_fork+0x10/0x40
[    4.864314] Code: f2fbd5b9 f2fbd5b8 f8478ee0 eb17001f (f9400013)
[    4.870472] ---[ end trace a643cfe4ce1d838b ]---

Fix this by moving the drm_mode_config_cleanup() much later such that it
correctly balances drm_mode_config_init().

Suggested-by: Russell King 
Signed-off-by: Robin Murphy 
Signed-off-by: Liviu Dudau

drm/arm: hdlcd: fix plane base address update

2016-11-22T14:09:06+00:00

While testing HDMI with Xorg on the Juno board, I find that when Xorg
starts up or shuts down, the display is shifted significantly to the
right and wrapped in the active region.  (No sync bars are visible.)
The timings are correct, it behaves as if the start address has been
shifted many pixels _into_ the framebuffer.

This occurs whenever the display mode size is changed - using xrandr
in Xorg shows that changing the resolution triggers the problem
almost every time, but changing the refresh rate does not.

Using devmem2 to disable and re-enable the HDLCD resolves the issue,
and repeated disable/enable cycles do not make the issue re-appear.
Further debugging shows that we try to update the controller
configuration while enabled.

Alwys ensure that the HDLCD is disabled prior to updating the
controller timings, and use drm_crtc_vblank_off()/drm_crtc_vblank_on()
so that DRM knows whether it can expect vblank interrupts.

Signed-off-by: Russell King 
Signed-off-by: Liviu Dudau

drm: Don't swallow error codes in drm_dev_alloc()

2016-09-22T11:03:48+00:00

There are many reasons other than ENOMEM that drm_dev_init() can
fail. Return ERR_PTR rather than NULL to be able to distinguish
these in the caller.

Signed-off-by: Tom Gundersen 
Signed-off-by: Sean Paul 
Link: http://patchwork.freedesktop.org/patch/msgid/20160921145919.13754-2-teg@jklm.no

drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane commit

2016-08-29T09:29:37+00:00

Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
of the helper drm_atomic_helper_commit_planes() if the relevant display
controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
when the CRTC is disabled. The helper would skip the ->atomic_disable
call for a plane if the CRTC of the old plane state needs a modesetting
operation. Of course, the drivers need to disable the planes in their CRTC
disable callbacks since no one else would do that.

Suggested-by: Daniel Vetter 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Russell King 
Cc: Peter Senna Tschudin 
Cc: Lucas Stach 
Signed-off-by: Liu Ying 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1472461923-14364-1-git-send-email-gnuiyl@gmail.com