kernel/linux.git/drivers/gpu/drm/omapdrm, branch v4.14.192

drm/omap: fix max fclk divider for omap36xx

2019-10-11T16:18:35+00:00

commit e2c4ed148cf3ec8669a1d90dc66966028e5fad70 upstream. The OMAP36xx and AM/DM37x TRMs say that the maximum divider for DSS fclk (in CM_CLKSEL_DSS) is 32. Experimentation shows that this is not correct, and using divider of 32 breaks DSS with a flood or underflows and sync losts. Dividers up to 31 seem to work fine. There is another patch to the DT files to limit the divider correctly, but as the DSS driver also needs to know the maximum divider to be able to iteratively find good rates, we also need to do the fix in the DSS driver. Signed-off-by: Tomi Valkeinen Cc: Adam Ford Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20191002122542.8449-1-tomi.valkeinen@ti.com Tested-by: Adam Ford Reviewed-by: Jyri Sarha Signed-off-by: Greg Kroah-Hartman

drm/omap: fix memory barrier bug in DMM driver

2018-11-21T08:24:03+00:00

[ Upstream commit 538f66ba204944470a653a4cccc5f8befdf97c22 ] A DMM timeout "timed out waiting for done" has been observed on DRA7 devices. The timeout happens rarely, and only when the system is under heavy load. Debugging showed that the timeout can be made to happen much more frequently by optimizing the DMM driver, so that there's almost no code between writing the last DMM descriptors to RAM, and writing to DMM register which starts the DMM transaction. The current theory is that a wmb() does not properly ensure that the data written to RAM is observable by all the components in the system. This DMM timeout has caused interesting (and rare) bugs as the error handling was not functioning properly (the error handling has been fixed in previous commits): * If a DMM timeout happened when a GEM buffer was being pinned for display on the screen, a timeout error would be shown, but the driver would continue programming DSS HW with broken buffer, leading to SYNCLOST floods and possible crashes. * If a DMM timeout happened when other user (say, video decoder) was pinning a GEM buffer, a timeout would be shown but if the user handled the error properly, no other issues followed. * If a DMM timeout happened when a GEM buffer was being released, the driver does not even notice the error, leading to crashes or hang later. This patch adds wmb() and readl() calls after the last bit is written to RAM, which should ensure that the execution proceeds only after the data is actually in RAM, and thus observable by DMM. The read-back should not be needed. Further study is required to understand if DMM is somehow special case and read-back is ok, or if DRA7's memory barriers do not work correctly. Signed-off-by: Tomi Valkeinen Signed-off-by: Peter Ujfalusi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/omap: handle alloc failures in omap_connector

2018-06-20T19:02:55+00:00

[ Upstream commit 47aaaec818dfd1009d1358974a2931f05dd57203 ] Handle memory allocation failures in omap_connector to avoid NULL derefs. Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20180502091159.7071-5-tomi.valkeinen@ti.com Reviewed-by: Benoit Parrot Reviewed-by: Peter Ujfalusi Signed-off-by: Sean Paul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/omap: check return value from soc_device_match

2018-06-20T19:02:55+00:00

[ Upstream commit 4d6cb5e2fee52af17001e92950f0894304706ee4 ] soc_device_match() can return NULL, so add a check and fail if soc_device_match() fails. Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20180502091159.7071-2-tomi.valkeinen@ti.com Reviewed-by: Benoit Parrot Reviewed-by: Peter Ujfalusi Signed-off-by: Sean Paul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/omap: fix possible NULL ref issue in tiler_reserve_2d

2018-06-20T19:02:55+00:00

[ Upstream commit 6a0f0c55619f0b82a677cab72e77c3444a5eee58 ] tiler_reserve_2d allocates memory but does not check if it got the memory. Add the check and return ENOMEM on failure. Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20180329104038.29154-2-tomi.valkeinen@ti.com Reviewed-by: Emil Velikov Reviewed-by: Laurent Pinchart Signed-off-by: Sean Paul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/omap: fix uninitialized ret variable

2018-06-20T19:02:55+00:00

[ Upstream commit 77eeac24b10fc84d3ffd5b11a897dff88dde244d ] audio_config function for both HDMI4 and HDMI5 return uninitialized value as the error code if the display is not currently enabled. For some reason this has not caused any issues. Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20180329104038.29154-1-tomi.valkeinen@ti.com Reviewed-by: Emil Velikov Reviewed-by: Laurent Pinchart Signed-off-by: Sean Paul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/omap: silence unititialized variable warning

2018-06-20T19:02:54+00:00

[ Upstream commit 4a9fbfcab19d3f71ad2bf0bcb653c4ee84e69c7f ] Smatch complains that "area_free" could be used without being initialized. This code is several years old and premusably works fine so this can't be a very serious bug. But it's easy enough to silence the warning. If "area_free" is false at the end of the function then we return -ENOMEM. Signed-off-by: Dan Carpenter Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20180418142937.GA13828@mwanda Signed-off-by: Sean Paul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm: omapdrm: dss: Move initialization code from component bind to probe

2018-05-30T05:52:37+00:00

[ Upstream commit 215003b4ae1d47035092fef73b6a22aa82037091 ] There's no reason to delay initialization of most of the driver (such as mapping memory I/O, getting clocks or enabling runtime PM) to the component master bind handler. This additionally fixes a real PM issue caused enabling runtime PM in the bind handler. The bind handler performs the following sequence of PM operations: pm_runtime_enable(dev); pm_runtime_get_sync(dev); ... (access the hardware to read the device revision) ... pm_runtime_put_sync(dev); If a failure occurs at this point, the error path calls pm_runtime_disable() to balance the pm_runtime_enable() call. To understand the problem, it should be noted that the bind handler is called when one of the component registers itself, which happens in the component's probe handler. Furthermore, as the components are children of the DSS, the device core calls pm_runtime_get_sync() on the DSS platform device before calling the component's probe handler. This increases the DSS power usage count but doesn't runtime resume the device, as runtime PM is disabled at that point. The bind handler is thus called with runtime PM disabled, with the device runtime suspended, but with the power usage count larger than 0. The pm_runtime_get_sync() call will thus further increase the power usage count and runtime resume the device. The pm_runtime_put_sync() handler will decrease the power usage count to a non-zero value and will thus not suspend the device. Finally, the pm_runtime_disable() call will disable runtime PM, preventing the pm_runtime_put() call in the device core from runtime suspending the device. The DSS device is thus left powered on. To fix this, move the initialization code from the bind handler to the probe handler. Signed-off-by: Laurent Pinchart Reviewed-by: Sebastian Reichel Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/omap: DMM: Check for DMM readiness after successful transaction commit

2018-03-24T10:01:25+00:00

[ Upstream commit b7ea6b286c4051e043f691781785e3c4672f014a ] Check the status of the DMM engine after it is reported that the transaction was completed as in rare cases the engine might not reached a working state. The wait_status() will print information in case the DMM is not reached the expected state and the dmm_txn_commit() will return with an error code to make sure that we are not continuing with a broken setup. Signed-off-by: Peter Ujfalusi Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

omapdrm: panel: fix compatible vendor string for td028ttec1

2018-03-24T10:01:25+00:00

[ Upstream commit c1b9d4c75cd549e08bd0596d7f9dcc20f7f6e8fa ] The vendor name was "toppoly" but other panels and the vendor list have defined it as "tpo". So let's fix it in driver and bindings. We keep the old definition in parallel to stay compatible with potential older DTB setup. Signed-off-by: H. Nikolaus Schaller Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman