GitLab

Currently the Mali DP version of atomic_commit_hw_done sets the
'go' bit (config_valid) before arming the vblank event to be sent
to userspace. As the comments for drm_crtc_arm_vblank_event() warn,
that is a sure recipe for sending the vblank event at the wrong
vblank interrupt. The correct way of handling this (as hinted by
the comments) is to send the vblank event from the IRQ handler
and only set the 'go' bit in the atomic_commit_hw_done() hook.

Currently the malidp_atomic_commit_hw_done() function still sends
the vblank event if the CRTC is disabled, due to IRQs being turned
off before the last commit which turns off the CRTC. That will be
sorted out in a future patch that will re-order the de-activation
of IRQs.
Reported-by: Alexandru-Cosmin Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>

HDLCD cannot turn off its primary plane and as such it should not
accept states where the CRTC is active but no primary fb is provided.

Discovered while playing with modetest and the HDLCD behind an active
SMMU which complained loudly that the driver was reading from invalid
memory.
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>

The plane cleanup handler currently calls drm_plane_helper_disable(),
which is a legacy helper function. Replace it with a call to
drm_atomic_helper_shutdown() at removal time.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The top-level error handler calls drm_mode_config_cleanup() which will
destroy all planes. There's no need to destroy them manually in lower
error handlers.

As plane cleanup is now handled entirely by drm_mode_config_cleanup(),
we must ensure that the plane .destroy() handler frees allocated memory
for the plane object that was freed by malidp_de_planes_destroy(). Do so
by replacing the call to devm_kfree() in the .destroy() handler by
kfree(). devm_kfree() is currently a no-op as the plane memory is
allocated with kzalloc(), not devm_kzalloc().
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The plane cleanup handler currently calls drm_plane_helper_disable(),
which is a legacy helper function. Replace it with a call to
drm_atomic_helper_shutdown() at removal time. The plane .destroy()
handler now consisting only of a call to drm_plane_cleanup(), replace it
with direct calls to that function.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The top-level error handler calls drm_mode_config_cleanup() which will
destroy all planes. There's no need to destroy them manually in lower
error handlers.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Mali dp needs to disable pixel alpha blending (use layer alpha blending) to
display color formats that do not contain alpha bits per pixel
Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com>

drm_format_info does not describe the number of bits used for the alpha
channel. That information is useful in a central place like drm_fourcc.c
where it can be queried by the drivers that want to determine if 'alpha
blending' is to be enabled or not.
Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>

In the case, when the user wants to scale and rotate a layer by 90/270
degrees, the scaling engine input dimensions' parameters ie width and
height needs to be swapped with respect to the layer's input dimensions.
This means scaling engine input height should be set to layer's input
width and scaling engine input width should be set to
layer's input height.
Signed-off-by: Ayan Halder <ayan.halder@arm.com>

Currently the scaling engine gets enabled for a plane where the input
size differs from the composition size. As rotation is done natively
by the plane's hardware layer, we don't need the scaling engine to be
enabled.
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>

Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.

Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>

Replace driver's code with the generic helpers that do the same thing
including the NULL check.

Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

We use "mc" without initializing it if scaling is not necessary.

Fixes: 28ce675b ("drm: mali-dp: Add plane upscaling support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

Mali DP hardware needs pitch line sizes aligned to the bus burst
size for reads, so take that into consideration when allocating dumb
buffers. If the layer is rotated then the stride size requirement is
even larger for some hardware versions, so allocate for the worst case
scenario. Update the ->dumb_create() hook to a driver specific function
that sets the correct pitch size.
Reported-by: Ayan Halder <ayan.halder@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>

Rotated planes need a pitch size that is aligned to 8 bytes
for older DP500 and DP550 and at least 64 bytes for DP650. Replace
the malidp_hw_pitch_valid() function with one that calculates
the correct pitch alignment to take into account rotation.
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>

Prior to commit b0aa06e9a7fd ("drm/fb-helper: Support deferred setup"),
if no output is connected at framebuffer setup time, we get a default
1024x768 mode that is going to be used when we first connect a monitor.
After the commit, on first connection after deferred setup, we probe
the monitor and get the preferred resolution, but no mode get set
because the drm_fb_helper_hotplug_event() function returns early
when the setup has been deferred. That is different from what happens
on a second re-connect of the monitor, when the native mode get set.

Create a more consistent behaviour by checking in the
drm_fb_helper_hotplug_event() function if the deferred setup is still
active. If not, that means we now have a valid framebuffer that can be
used for setting the correct mode.

Fixes: b0aa06e9a7fd ("drm/fb-helper: Support deferred setup")
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>

For testing purposes only.
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>

Allow stage 1 contexts to default to short-descriptor format if
supported and all DRAM is 32-bit-addressable.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>

Keep track of the allocation details too.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>

Dump IOVA usage via debugfs.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>

Also enable the SMMU in front of the HDLCD device.
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

Add support for the FPGA V2F-1XV7 Coretile that can be loaded with
a Mali-DP instance.
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

Internally Mali DP uses an RGB pipeline so video layers that support
YUV input buffers need to convert the input data to RGB. The YUV
buffers can have various encodings and this patch introduces support
for BT.601, BT.709 and BT.2020 encodings, both limited and full ranges.

This patch adds support for specifying the color encoding of the
input buffers for the planes that are backed by the video layers
and programs the YUV2RGB coefficients into hardware based on the
selected encoding.
Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
[updated to use standard properties]
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>

Add a standard optional properties to support different non RGB color
encodings in DRM planes. COLOR_ENCODING select the supported non RGB
color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects
the value ranges within the selected color encoding. The properties
are stored to drm_plane object to allow different set of supported
encoding for different planes on the device.
Signed-off-by: Jyri Sarha <jsarha@ti.com>

Mali-DP has a memory writeback engine which can be used to write the
composition result to a memory buffer. Expose this functionality as a
DRM writeback connector on supported hardware.

Changes since v1:
 Daniel Vetter:
 - Don't require a modeset when writeback routing changes
 - Make writeback connector always disconnected

Changes since v2:
 - Rebase onto new drm_writeback_connector
 - Add reset callback, allocating subclassed state
 Daniel Vetter:
 - Squash out-fence support into this commit
 Gustavo Padovan:
 - Don't signal fence directly from driver (and drop malidp_mw_job)

Changes since v3:
 - Modifications to fit with Mali-DP commit tail changes
Signed-off-by: Brian Starkey <brian.starkey@arm.com>
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>

Add a layer bit for the SE memory-write, and add it to the pixel format
matrix for DP550/DP650.
Signed-off-by: Brian Starkey <brian.starkey@arm.com>
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>

Mali-DP display processors are able to write the composition result to a
memory buffer via the SE.

Add entry points in the HAL for enabling/disabling this feature, and
implement support for it on DP650 and DP550. DP500 acts differently and
so is omitted from this change.

Changes since v3:
 - Fix missing vsync interrupt for DP550
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Brian Starkey <brian.starkey@arm.com>
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>

Add the WRITEBACK_OUT_FENCE_PTR property to writeback connectors, to
enable userspace to get a fence which will signal once the writeback is
complete. It is not allowed to request an out-fence without a
framebuffer attached to the connector.

A timeline is added to drm_writeback_connector for use by the writeback
out-fences.

In the case of a commit failure or DRM_MODE_ATOMIC_TEST_ONLY, the fence
is set to -1.

Changes from v2:
 - Rebase onto Gustavo Padovan's v9 explicit sync series
 - Change out_fence_ptr type to s32 __user *
 - Set *out_fence_ptr to -1 in drm_atomic_connector_set_property
 - Store fence in drm_writeback_job
 Gustavo Padovan:
 - Move out_fence_ptr out of connector_state
 - Signal fence from drm_writeback_signal_completion instead of
   in driver directly

Changes from v3:
 - Rebase onto 7e9081c5 drm/fence: fix memory overwrite when setting out_fence fd
   (change out_fence_ptr to s32 __user *, for real this time.)
 - Update documentation around WRITEBACK_OUT_FENCE_PTR
Signed-off-by: Brian Starkey <brian.starkey@arm.com>
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>

Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer. Add a writeback connector type and
related support functions.

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

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

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

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

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

Changes since v3:
 - Rebased
 - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS
Signed-off-by: Brian Starkey <brian.starkey@arm.com>
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>

When enabling lockdep debugging on Juno platform with HDLCD and TDA998x
I get the following warning from the system:

[   25.990733] ======================================================
[   25.998637] WARNING: possible circular locking dependency detected
[   26.006531] 4.13.0-rc1-00284-g28c0a682ecbf-dirty #17 Not tainted
[   26.014246] ------------------------------------------------------
[   26.022142] kworker/1:2/140 is trying to acquire lock:
[   26.029001]  (&priv->audio_mutex){+.+.+.}, at: [<ffff000000d0319c>] tda998x_encoder_mode_set+0x12c/0x5a0 [tda998x]
[   26.041100]
[   26.041100] but task is already holding lock:
[   26.050436]  (crtc_ww_class_mutex){+.+.+.}, at: [<ffff000000eaefe4>] drm_modeset_lock+0x64/0xf8 [drm]
[   26.061531]
[   26.061531] which lock already depends on the new lock.
[   26.061531]
[   26.075063]
[   26.075063] the existing dependency chain (in reverse order) is:
[   26.086031]
[   26.086031] -> #2 (crtc_ww_class_mutex){+.+.+.}:
[   26.095657]        __lock_acquire+0x18a0/0x19b8
[   26.101918]        lock_acquire+0xd0/0x2b0
[   26.107731]        __ww_mutex_lock.constprop.3+0x90/0xe78
[   26.114817]        ww_mutex_lock+0x54/0xe0
[   26.120672]        drm_modeset_lock+0x64/0xf8 [drm]
[   26.127253]        drm_helper_probe_single_connector_modes+0x7c/0x6b8 [drm_kms_helper]
[   26.136829]        tda998x_connector_fill_modes+0x44/0xa8 [tda998x]
[   26.144797]        drm_setup_crtcs+0x19c/0xba0 [drm_kms_helper]
[   26.152429]        drm_fb_helper_initial_config+0x70/0x440 [drm_kms_helper]
[   26.161097]        drm_fbdev_cma_init_with_funcs+0x94/0x168 [drm_kms_helper]
[   26.169857]        drm_fbdev_cma_init+0x38/0x50 [drm_kms_helper]
[   26.177559]        hdlcd_drm_bind+0x1f8/0x4a8 [hdlcd]
[   26.184310]        try_to_bring_up_master+0x180/0x1e0
[   26.191043]        component_master_add_with_match+0xb0/0x108
[   26.198458]        hdlcd_probe+0x58/0x80 [hdlcd]
[   26.204735]        platform_drv_probe+0x60/0xc0
[   26.210913]        driver_probe_device+0x23c/0x2e8
[   26.217350]        __driver_attach+0xd4/0xd8
[   26.223256]        bus_for_each_dev+0x5c/0xa8
[   26.229232]        driver_attach+0x30/0x40
[   26.234917]        bus_add_driver+0x1d8/0x248
[   26.240831]        driver_register+0x6c/0x118
[   26.246715]        __platform_driver_register+0x54/0x60
[   26.253461]        0xffff000000e1b018
[   26.258644]        do_one_initcall+0x44/0x138
[   26.264503]        do_init_module+0x64/0x1d4
[   26.270238]        load_module+0x1f90/0x2590
[   26.275957]        SyS_finit_module+0xb0/0xc8
[   26.281765]        __sys_trace_return+0x0/0x4
[   26.281767]
[   26.281767] -> #1 (crtc_ww_class_acquire){+.+.+.}:
[   26.281778]        __lock_acquire+0x18a0/0x19b8
[   26.281782]        lock_acquire+0xd0/0x2b0
[   26.281877]        drm_modeset_acquire_init+0xa8/0xe0 [drm]
[   26.281921]        drm_helper_probe_single_connector_modes+0x48/0x6b8 [drm_kms_helper]
[   26.281929]        tda998x_connector_fill_modes+0x44/0xa8 [tda998x]
[   26.281970]        drm_setup_crtcs+0x19c/0xba0 [drm_kms_helper]
[   26.282009]        drm_fb_helper_initial_config+0x70/0x440 [drm_kms_helper]
[   26.282049]        drm_fbdev_cma_init_with_funcs+0x94/0x168 [drm_kms_helper]
[   26.282088]        drm_fbdev_cma_init+0x38/0x50 [drm_kms_helper]
[   26.282095]        hdlcd_drm_bind+0x1f8/0x4a8 [hdlcd]
[   26.282099]        try_to_bring_up_master+0x180/0x1e0
[   26.282104]        component_master_add_with_match+0xb0/0x108
[   26.282110]        hdlcd_probe+0x58/0x80 [hdlcd]
[   26.282114]        platform_drv_probe+0x60/0xc0
[   26.282117]        driver_probe_device+0x23c/0x2e8
[   26.282121]        __driver_attach+0xd4/0xd8
[   26.282124]        bus_for_each_dev+0x5c/0xa8
[   26.282127]        driver_attach+0x30/0x40
[   26.282130]        bus_add_driver+0x1d8/0x248
[   26.282134]        driver_register+0x6c/0x118
[   26.282138]        __platform_driver_register+0x54/0x60
[   26.282141]        0xffff000000e1b018
[   26.282145]        do_one_initcall+0x44/0x138
[   26.282149]        do_init_module+0x64/0x1d4
[   26.282152]        load_module+0x1f90/0x2590
[   26.282156]        SyS_finit_module+0xb0/0xc8
[   26.282159]        __sys_trace_return+0x0/0x4
[   26.282161]
[   26.282161] -> #0 (&priv->audio_mutex){+.+.+.}:
[   26.282172]        print_circular_bug+0x80/0x2e0
[   26.282176]        __lock_acquire+0x15a8/0x19b8
[   26.282180]        lock_acquire+0xd0/0x2b0
[   26.282184]        __mutex_lock+0x78/0x8e0
[   26.282188]        mutex_lock_nested+0x3c/0x50
[   26.282196]        tda998x_encoder_mode_set+0x12c/0x5a0 [tda998x]
[   26.282237]        drm_atomic_helper_commit_modeset_disables+0x328/0x3a0 [drm_kms_helper]
[   26.282251]        malidp_atomic_commit_tail+0x44/0x6b0 [mali_dp]
[   26.282292]        commit_tail+0x4c/0x80 [drm_kms_helper]
[   26.282333]        drm_atomic_helper_commit+0xe8/0x180 [drm_kms_helper]
[   26.282427]        drm_atomic_commit+0x54/0x70 [drm]
[   26.282467]        restore_fbdev_mode_atomic+0x1f0/0x220 [drm_kms_helper]
[   26.282507]        restore_fbdev_mode+0x38/0x188 [drm_kms_helper]
[   26.282547]        drm_fb_helper_restore_fbdev_mode_unlocked+0x44/0xd0 [drm_kms_helper]
[   26.282586]        drm_fb_helper_set_par+0x34/0x80 [drm_kms_helper]
[   26.282625]        drm_fb_helper_hotplug_event.part.19+0x94/0xb0 [drm_kms_helper]
[   26.282665]        drm_fb_helper_hotplug_event+0x2c/0x48 [drm_kms_helper]
[   26.282704]        drm_fbdev_cma_hotplug_event+0x24/0x30 [drm_kms_helper]
[   26.282716]        malidp_output_poll_changed+0x24/0x30 [mali_dp]
[   26.282757]        drm_kms_helper_hotplug_event+0x34/0x40 [drm_kms_helper]
[   26.282797]        output_poll_execute+0x1a0/0x1f0 [drm_kms_helper]
[   26.282803]        process_one_work+0x280/0x790
[   26.282808]        worker_thread+0x48/0x450
[   26.282812]        kthread+0x138/0x140
[   26.282815]        ret_from_fork+0x10/0x40
[   26.282817]
[   26.282817] other info that might help us debug this:
[   26.282817]
[   26.282819] Chain exists of:
[   26.282819]   &priv->audio_mutex --> crtc_ww_class_acquire --> crtc_ww_class_mutex
[   26.282819]
[   26.282830]  Possible unsafe locking scenario:
[   26.282830]
[   26.282832]        CPU0                    CPU1
[   26.282834]        ----                    ----
[   26.282835]   lock(crtc_ww_class_mutex);
[   26.282840]                                lock(crtc_ww_class_acquire);
[   26.282845]                                lock(crtc_ww_class_mutex);
[   26.282850]   lock(&priv->audio_mutex);
[   26.282854]
[   26.282854]  *** DEADLOCK ***
[   26.282854]
[   26.282858] 5 locks held by kworker/1:2/140:
[   26.282859]  #0:  ("events"){.+.+.+}, at: [<ffff0000080f8500>] process_one_work+0x1d8/0x790
[   26.282871]  #1:  ((&(&dev->mode_config.output_poll_work)->work)){+.+.+.}, at: [<ffff0000080f8500>] process_one_work+0x1d8/0x790
[   26.282883]  #2:  (&helper->lock){+.+.+.}, at: [<ffff000000c0631c>] drm_fb_helper_restore_fbdev_mode_unlocked+0x3c/0xd0 [drm_kms_helper]
[   26.282929]  #3:  (crtc_ww_class_acquire){+.+.+.}, at: [<ffff000000c02d80>] restore_fbdev_mode_atomic+0x38/0x220 [drm_kms_helper]
[   26.282976]  #4:  (crtc_ww_class_mutex){+.+.+.}, at: [<ffff000000eaefe4>] drm_modeset_lock+0x64/0xf8 [drm]
[   26.283077]
[   26.283077] stack backtrace:
[   26.283082] CPU: 1 PID: 140 Comm: kworker/1:2 Not tainted 4.13.0-rc1-00284-g28c0a682ecbf-dirty #17
[   26.283084] Hardware name: ARM Juno development board (r0) (DT)
[   26.283127] Workqueue: events output_poll_execute [drm_kms_helper]
[   26.283131] Call trace:
[   26.283137] [<ffff00000808a778>] dump_backtrace+0x0/0x268
[   26.283142] [<ffff00000808aabc>] show_stack+0x24/0x30
[   26.283146] [<ffff000008aa36a8>] dump_stack+0xbc/0xf4
[   26.283151] [<ffff00000812f454>] print_circular_bug+0x1d4/0x2e0
[   26.283155] [<ffff000008132480>] __lock_acquire+0x15a8/0x19b8
[   26.283159] [<ffff000008133008>] lock_acquire+0xd0/0x2b0
[   26.283163] [<ffff000008aba060>] __mutex_lock+0x78/0x8e0
[   26.283168] [<ffff000008aba904>] mutex_lock_nested+0x3c/0x50
[   26.283176] [<ffff000000d0319c>] tda998x_encoder_mode_set+0x12c/0x5a0 [tda998x]
[   26.283217] [<ffff000000c00050>] drm_atomic_helper_commit_modeset_disables+0x328/0x3a0 [drm_kms_helper]
[   26.283230] [<ffff000000f1bd0c>] malidp_atomic_commit_tail+0x44/0x6b0 [mali_dp]
[   26.283271] [<ffff000000c0045c>] commit_tail+0x4c/0x80 [drm_kms_helper]
[   26.283312] [<ffff000000c00630>] drm_atomic_helper_commit+0xe8/0x180 [drm_kms_helper]
[   26.283406] [<ffff000000eb1604>] drm_atomic_commit+0x54/0x70 [drm]
[   26.283447] [<ffff000000c02f38>] restore_fbdev_mode_atomic+0x1f0/0x220 [drm_kms_helper]
[   26.283487] [<ffff000000c03cf0>] restore_fbdev_mode+0x38/0x188 [drm_kms_helper]
[   26.283526] [<ffff000000c06324>] drm_fb_helper_restore_fbdev_mode_unlocked+0x44/0xd0 [drm_kms_helper]
[   26.283566] [<ffff000000c0619c>] drm_fb_helper_set_par+0x34/0x80 [drm_kms_helper]
[   26.283606] [<ffff000000c0627c>] drm_fb_helper_hotplug_event.part.19+0x94/0xb0 [drm_kms_helper]
[   26.283645] [<ffff000000c062c4>] drm_fb_helper_hotplug_event+0x2c/0x48 [drm_kms_helper]
[   26.283685] [<ffff000000c07124>] drm_fbdev_cma_hotplug_event+0x24/0x30 [drm_kms_helper]
[   26.283697] [<ffff000000f1b44c>] malidp_output_poll_changed+0x24/0x30 [mali_dp]
[   26.283738] [<ffff000000bf5264>] drm_kms_helper_hotplug_event+0x34/0x40 [drm_kms_helper]
[   26.283779] [<ffff000000bf5480>] output_poll_execute+0x1a0/0x1f0 [drm_kms_helper]
[   26.283784] [<ffff0000080f85a8>] process_one_work+0x280/0x790
[   26.283788] [<ffff0000080f8b00>] worker_thread+0x48/0x450
[   26.283792] [<ffff000008100430>] kthread+0x138/0x140
[   26.283796] [<ffff000008083710>] ret_from_fork+0x10/0x40

This looks like it has been introduced by 'commit 02efac0f ("drm/i2c:
tda998x: remove complexity from tda998x_audio_get_eld()")'.

Fix the warning by dropping the use of local audio_mutex and switch to
taking the modeset connection_mutex in tda998x_audio_get_eld() for
avoidance of race conditions with drm_helper_probe_single_connector_modes()
updating the ELD data.

v2: Change to taking the modeset connection_mutex rather than changing
the time when audio_mutex lock was taken, as suggested by Russell King.
v3: Drop the bespoke drm_modeset_acquire_ctx, it is not needed.
(suggested by Daniel Vetter)
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes: 02efac0f ("drm/i2c: tda998x: remove complexity from tda998x_audio_get_eld()")

The IPMMU driver still uses initcalls to do its initialisation, while
other IOMMU drivers have moved to probe deferal mechanism. Update
the IPMMU driver so that it can use modern driver probing which allows
for it to be compiled together with other IOMMU drivers and not
trying at boot time to replace bus masters for platforms that don't
use IPMMU.
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <damm+renesas@opensource.se>
Cc: Alex Williamson <alex.williamson@redhat.com>

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Early in boot Linux patches memset and memcpy to branch to platform
optimized versions of these routines.  The NG4 (Niagra 4) versions are
currently used on all platforms starting from T4.  Recently, there were M7
optimized routines added into UEK4 but not into mainline yet.  So, even
with M7 optimized routines NG4 are still going to be used on T4, T5, M5,
and M6 processors.

While investigating how to improve initialization time of dentry_hashtable
which is 8G long on M6 ldom with 7T of main memory, I noticed that
memset() does not reset all the memory in this array, after studying the
code, I realized that NG4memset() branches use %icc register instead of
%xcc to check compare, so if value of length is over 32-bit long, which is
true for 8G array, these routines fail to work properly.

The fix is to replace all %icc with %xcc in these routines.  (Alternative
is to use %ncc, but this is misleading, as the code already has sparcv9
only instructions, and cannot be compiled on 32-bit).

This is important to fix this bug, because even older T4-4 can have 2T of
memory, and there are large memory proportional data structures in kernel
which can be larger than 4G in size.  The failing of memset() is silent
and corruption is hard to detect.

Link: http://lkml.kernel.org/r/1488432825-92126-2-git-send-email-pasha.tatashin@oracle.comSigned-off-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Reviewed-by: Babu Moger <babu.moger@oracle.com>
Cc: Babu Moger <babu.moger@amd.com>
Cc: David Miller <davem@davemloft.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

The single caller passes a string to delta_ipc_open, which copies with a
fixed size larger than the string.  So it copies some random data after
the original string the ro segment.

If the string was at the end of a page it may fault.

Just copy the string with a normal strcpy after clearing the field.

Found by a LTO build (which errors out)
because the compiler inlines the functions and can resolve
the string sizes and triggers the compile time checks in memcpy.

In function `memcpy',
    inlined from `delta_ipc_open.constprop' at linux/drivers/media/platform/sti/delta/delta-ipc.c:178:0,
    inlined from `delta_mjpeg_ipc_open' at linux/drivers/media/platform/sti/delta/delta-mjpeg-dec.c:227:0,
    inlined from `delta_mjpeg_decode' at linux/drivers/media/platform/sti/delta/delta-mjpeg-dec.c:403:0:
/home/andi/lsrc/linux/include/linux/string.h:337:0: error: call to `__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
    __read_overflow2();

Link: http://lkml.kernel.org/r/20171222001212.1850-1-andi@firstfloor.orgSigned-off-by: Andi Kleen <ak@linux.intel.com>
Cc: Hugues FRUCHET <hugues.fruchet@st.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

We should propogate the error code here but we accidentally return
success.

Link: http://lkml.kernel.org/r/20180109092919.ndrvscdllrmzz6jo@mwanda
Fixes: 946086abeddf ("mqueue: switch to on-demand creation of internal mount")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>