| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The MCDE DSI link hardware which is modeled like a bridge
in DRM, connected further to the panel bridge, creating
a pipeline.
We have been using the .pre_enable(), .enable(),
.disable() and .post_disable() callbacks from the bridge
to set this up in a chained manner: first the display
controller goes online and then in successive order
each bridge in the pipeline. Inside DRM it works
like this:
drm_atomic_helper_commit_tail()
drm_atomic_helper_commit_modeset_enables()
struct drm_crtc_helper_funcs .atomic_enable()
struct drm_simple_display_pipe_funcs .enable()
MCDE display enable call
drm_atomic_bridge_chain_enable()
struct drm_bridge_funcs .pre_enable()
mcde_dsi_bridge_pre_enable()
panel_bridge_pre_enable()
struct drm_panel_funcs .prepare()
struct drm_bridge_funcs .enable()
mcde_dsi_bridge_enable()
panel_bridge_enable()
struct drm_panel_funcs .enable()
A similar sequence is executed for disabling.
Unfortunately this is not what the hardware needs: at
a certain stage in the enablement of the display
controller the DSI link needs to come up to support
video mode, else something (like a FIFO flow) locks
up the hardware and we never get picture.
Fix this by simply leaving the pre|enable and
post|disable callbacks unused, and establish two
cross-calls from the display controller to bring up
the DSI link at the right place in the display
bring-up sequence and vice versa in the shutdown
sequence.
For command mode displays, it works just fine to
also enable the display flow early. The only time
we hold it back right now is in one-shot mode,
on-demand display updates.
When combined with the previous patch and some patches
for the S6E63M0 display controller to support DSI
mode, this gives working display on the Samsung
GT-I8190 (Golden) phone. It has also been tested working
on the Samsung GT-S7710 (Skomer) phone.
Signed-off-by: Linus Walleij <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Cc: [email protected]
Cc: Stephan Gerhold <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
To make sure that the MCDE is in a reasonable state during
set-up, perform a reset by power cycling the block by dropping
the on-chip regulator reference after probe. The display
subsystem (DSS) has no dedicated reset line so dropping
the EPOD regulator is the only real way of resetting it.
We introduce code to enable and disable the regulator in
the display enable/disable callbacks.
We move the generic MCDE setup such as muxing of DPI
signals and masking of interrupts to the display
handling.
When we drop the power to the whole display subsystem, not
only MCDE but also the DSI links lose their state. Therefore
we move the DSI block reset and hardware initialization
code to the mcde_dsi_bridge_pre_enable() callback so this
happens every time we start up the bridge, as we may have
lost the power.
We move the final disablement of the interrupts and
clocks to the mcde_dsi_bridge_post_disable() callback
rather than have it in the mcde_dsi_bridge_disable()
callback, as some control messages may still be sent
over the DSI host after the bridge has been shut down.
This (together with a patch for the corresponding
panel) makes the Samsung GT-S7710 successfully disable
and re-enable its display, cutting all power while
disabled and re-initializing the hardware when coming
back up.
Acked-by: Daniel Vetter <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Cc: [email protected]
Cc: Stephan Gerhold <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The pixel fetcher FIFO depth was just hardcoded to 48
which works fine as long as the framebuffer is 32BPP
and the DSI output is RGB888.
We will need more elaborate handling for some buffer
formats and displays, so start to improve this function
by setting reasonable defaults for 32, 24 and 16 BPP
framebuffers.
Signed-off-by: Linus Walleij <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Cc: [email protected]
Cc: Stephan Gerhold <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Revamp the way that the flow of data to the display is
defined.
I realized that the hardware supports something like
5 different modes of flow: oneshot, command with TE IRQ,
command with BTA (bus turn around) and TE IRQ, video
with TE IRQ and video without TE IRQ instead synchronizing
to the output of the MCDE DSI formatter.
Like before the selection of the type of flow is done
from the DSI driver when we attach it to the MCDE and we
get to know what the display wants.
The new video mode synchronization method from the MCDE DSI
formatter is used on some upstream devices such as Golden.
This is the new default for video mode: stateless panels
do not as a rule generate TE IRQs.
Another semantic change is that we stop sending
a TE request before every command when sending data to
a display in command mode: this should only be explicitly
requested when using BTA, according to the vendor driver.
This has been tested and works fine with the command mode
displays I have. (All that are supported upstream.)
Reported-by: Stephan Gerhold <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Reviewed-by: Stephan Gerhold <[email protected]>
Cc: Stephan Gerhold <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The function mcde_display_send_one_frame() has a historical
name that stems from being implemented when the driver
only supported single frame updates.
Rename it mcde_start_flow() so that it reflects the current
usage.
Signed-off-by: Linus Walleij <[email protected]>
Reviewed-by: Stephan Gerhold <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Whenever a display update was sent, apart from updating
the memory base address, we called mcde_display_send_one_frame()
which also sent a command to the display requesting the TE IRQ
and enabling the FIFO.
When continuous updates are running this is wrong: we need
to only send this to start the flow to the display on
the very first update. This lead to the display pipeline
locking up and crashing.
Check if the flow is already running and in that case
do not call mcde_display_send_one_frame().
This fixes crashes on the Samsung GT-S7710 (Skomer).
Signed-off-by: Linus Walleij <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Acked-by: Stephan Gerhold <[email protected]>
Cc: Stephan Gerhold <[email protected]>
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Unable to handle kernel NULL pointer dereference at virtual address 00000918
pgd = (ptrval)
[00000918] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-15001-gfa384b50b96b-dirty #514
Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support)
PC is at mcde_display_enable+0x78/0x7c0
LR is at mcde_display_enable+0x78/0x7c0
Fix this by using to_mcde() as in other functions.
Fixes: fd7ee85cfe7b ("drm/mcde: Don't use drm_device->dev_private")
Signed-off-by: Linus Walleij <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Cc: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
v2: Move misplaced removal of double-assignment to this patch (Sam)
Reviewed-by: Linus Walleij <[email protected]> (v1)
Acked-by: Sam Ravnborg <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Linus Walleij <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Disabling the display using MCDE currently results in a warning
together with a delay caused by some timeouts:
mcde a0350000.mcde: MCDE display is disabled
------------[ cut here ]------------
WARNING: CPU: 0 PID: 20 at drivers/gpu/drm/drm_atomic_helper.c:2258 drm_atomic_helper_commit_hw_done+0xe0/0xe4
Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support)
Workqueue: events drm_mode_rmfb_work_fn
[<c010f468>] (unwind_backtrace) from [<c010b54c>] (show_stack+0x10/0x14)
[<c010b54c>] (show_stack) from [<c079dd90>] (dump_stack+0x84/0x98)
[<c079dd90>] (dump_stack) from [<c011d1b0>] (__warn+0xb8/0xd4)
[<c011d1b0>] (__warn) from [<c011d230>] (warn_slowpath_fmt+0x64/0xc4)
[<c011d230>] (warn_slowpath_fmt) from [<c0413048>] (drm_atomic_helper_commit_hw_done+0xe0/0xe4)
[<c0413048>] (drm_atomic_helper_commit_hw_done) from [<c04159cc>] (drm_atomic_helper_commit_tail_rpm+0x44/0x6c)
[<c04159cc>] (drm_atomic_helper_commit_tail_rpm) from [<c0415f5c>] (commit_tail+0x50/0x10c)
[<c0415f5c>] (commit_tail) from [<c04160dc>] (drm_atomic_helper_commit+0xbc/0x128)
[<c04160dc>] (drm_atomic_helper_commit) from [<c0430790>] (drm_framebuffer_remove+0x390/0x428)
[<c0430790>] (drm_framebuffer_remove) from [<c0430860>] (drm_mode_rmfb_work_fn+0x38/0x48)
[<c0430860>] (drm_mode_rmfb_work_fn) from [<c01368a8>] (process_one_work+0x1f0/0x43c)
[<c01368a8>] (process_one_work) from [<c0136d48>] (worker_thread+0x254/0x55c)
[<c0136d48>] (worker_thread) from [<c013c014>] (kthread+0x124/0x150)
[<c013c014>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
Exception stack(0xeb14dfb0 to 0xeb14dff8)
dfa0: 00000000 00000000 00000000 00000000
dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
---[ end trace 314909bcd4c7d50c ]---
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:32:crtc-0] flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:34:DSI-1] flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:31:plane-0] flip_done timed out
The reason for this is that there is a vblank event pending, but we
never handle it after disabling the vblank interrupts.
Check if there is an vblank event pending when disabling the display,
and clear it by sending a fake vblank event in that case.
Signed-off-by: Stephan Gerhold <[email protected]>
Tested-by: Linus Walleij <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The MCDE driver differentiates only between "te_sync"
(for hardware TE0 sync) and software sync
(i.e. manually triggered updates) at the moment.
However, none of these options work correctly for video mode panels.
Therefore, we need to make some changes to make them work correctly:
- Select hardware sync coming from the (DSI) formatter.
- Keep the FIFO permanently enabled (otherwise MCDE will stop
feeding data to the panel).
- Skip manual software sync (this is not necessary in video mode).
Automatically detect if the connected panel is using video mode
and enable the necessary changes in that case.
Signed-off-by: Stephan Gerhold <[email protected]>
Tested-by: Linus Walleij <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
At the moment, vblank handling is only enabled together with
TE synchronization. However, the vblank IRQ is also working with
on displays without TE synchronization (e.g. DSI video mode panels).
It seems like the vblank IRQ is actually generated by the
MCDE hardware for the channel.
Therefore, the vblank handling should be working correctly in
all the cases and we can enable it unconditionally.
Signed-off-by: Stephan Gerhold <[email protected]>
Tested-by: Linus Walleij <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We never set "vblank" to "false".
Current versions of GCC will initialize it to zero automatically at
certain optimization levels so that's probably why this didn't show up
in testing.
Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/20190529113458.GG19119@mwanda
|
|
Some further compile problems appeared while merging the
patch, fix them up.
Signed-off-by: Sam Ravnborg <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This adds a new DRM driver for the ST-Ericsson Multi Channel
Display Engine, MCDE display controller.
This hardware has three independent DSI hosts and can composit
and display several memory buffers onto an LCD display. It
was developed for several years inside of ST-Ericsson and
shipped with a few million mobile phones from Sony and Samsung,
as well as with the Snowball community development board.
The driver is currently pretty rudimentary but supports a
simple framebuffer so we can get penguins and graphics when
using these SoCs.
Acked-by: Daniel Vetter <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|