summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/omapdrm
Commit message (Collapse)AuthorAgeFilesLines
* drm/omap: fix use of freed memoryTomi Valkeinen2018-10-021-1/+2
| | | | | | | | | | | | | | | omap_connector_destroy() does: kfree(omap_connector); omapdss_device_put(omap_connector->output); omapdss_device_put(omap_connector->display); Fix this by moving the kfree after the omapdss_device_puts. This bug was introduced in 949ea2ef3fed4e1d0f9b80ec21ed81a9833ac248 Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
* drm/omap: Replace drm_dev_unref with drm_dev_putThomas Zimmermann2018-10-021-2/+2
| | | | | | | | | This patch unifies the naming of DRM functions for reference counting of struct drm_device. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Replace drm_gem_object_unreference_unlocked with put functionThomas Zimmermann2018-10-024-5/+5
| | | | | | | | | This patch unifies the naming of DRM functions for reference counting of struct drm_gem_object. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Replace drm_gem_object_{un/reference} with put,get functionsThomas Zimmermann2018-10-021-1/+1
| | | | | | | | | This patch unifies the naming of DRM functions for reference counting of struct drm_gem_object. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Substitute format_is_yuv() with format->is_yuvAyan Kumar Halder2018-10-021-16/+10
| | | | | | | | | drm_format_info table has a field 'is_yuv' to denote if the format is yuv or not. The driver is expected to use this instead of having a function for the same purpose. Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: partial workaround for DRA7xx DMM errata i878Tomi Valkeinen2018-10-022-2/+154
| | | | | | | | | | | | | | | | | Errata i878 says that MPU should not be used to access RAM and DMM at the same time. As it's not possible to prevent MPU accessing RAM, we need to access DMM via a proxy. This patch changes DMM driver to access DMM registers via sDMA. Instead of doing a normal readl/writel call to read/write a register, we use sDMA to copy 4 bytes from/to the DMM registers. This patch provides only a partial workaround for i878, as not only DMM register reads/writes are affected, but also accesses to the DMM mapped buffers (framebuffers, usually). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
* drm/omap: dmm_tiler: Fix interrupt request/free sequence during probe/removePeter Ujfalusi2018-10-021-20/+22
| | | | | | | | | | | The interrupts should be enabled after the driver initialization to avoid early interrupts while the driver is not yet ready to handle them. On removal the interrupts must be disabled before other resources are released, freed up. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: dmm_tiler: No need to check if irq is valid in omap_dmm_removePeter Ujfalusi2018-10-021-2/+1
| | | | | | | The driver probe would fail if the irq is not available. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: fix memory barrier bug in DMM driverTomi Valkeinen2018-10-021-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
* drm/omap: remove set but not used variable 'frame_height'YueHaibing2018-10-021-6/+3
| | | | | | | | | | | | Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/omapdrm/dss/dispc.c: In function 'dispc_ovl_setup_common': drivers/gpu/drm/omapdrm/dss/dispc.c:2627:19: warning: variable 'frame_height' set but not used [-Wunused-but-set-variable] Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Use ERR_CAST directly instead of ERR_PTR(PTR_ERR())zhong jiang2018-10-021-1/+1
| | | | | | | | | We prefer to use ERR_CAST to do so. The issue is detected with the help of Coccinelle. Signed-off-by: zhong jiang <zhongjiang@huawei.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: remove unused header tcm-sita.hCorentin Labbe2018-10-021-93/+0
| | | | | | | | tcm-sita.h is unused since commit 0d6fa53fd805 ("drm/omap: Use bitmaps for TILER placement") Let's remove it. Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Don't call .set_timings() operation recursivelyLaurent Pinchart2018-09-0319-144/+8
| | | | | | | | | | | Instead of calling the .set_timings() operation recursively from the display device backwards, iterate over the devices manually in the DRM encoder code. This moves the complexity to a single central location and simplifies the logic in omap_dss_device drivers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Store CRTC timings in .set_timings() operationLaurent Pinchart2018-09-036-16/+12
| | | | | | | | | | | | The video timings are stored in the CRTC structure by the omap_crtc_dss_set_timings() function, called by dss_mgr_set_timings() from the .enable() operation of the internal encoders. This instead belongs to the .set_timings() code paths. Move the omap_crtc_dss_set_timings() calls accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: venc: Fixup video mode in .check_timings() operationLaurent Pinchart2018-09-031-15/+8
| | | | | | | | | | | The VENC encoder modifies the requested video mode to match the NTSC or PAL timings (or reject the video mode completely) in the .set_timings() operation. This should be performed in the .check_timings() operation instead. Move the fixup. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: sdi: Fixup video mode in .check_timings() operationLaurent Pinchart2018-09-031-15/+22
| | | | | | | | | | | The SDI encoder modifies the pixel clock of the requested video mode to take the limitations of the PLL into account in the .enable() operation. This should be performed in the .check_timings() operation instead. Move the fixup. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: hdmi: Constify video mode and related pointersLaurent Pinchart2018-09-035-13/+13
| | | | | | | | | | Constify many pointers to struct videomode, as well as pointers to container structures, to ensure the video mode isn't modified after the .check_timings() operation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: dsi: Fixup video mode in .set_config() operationLaurent Pinchart2018-09-031-13/+14
| | | | | | | | | | | | | The DSI encoder modifies the passed videomode to take the requirements of the internal DISPC-DSI bus into account in the .enable_video_output() operation. This should be performed in the .check_timings() operation instead. There is however no .check_timings() operation as the DSI encoder uses a custom API, so move it to the closest match which is the .set_config() operation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: dpi: Don't fixup video mode in dpi_set_mode()Laurent Pinchart2018-09-031-11/+1
| | | | | | | | | The video mode is aleady fixed up by the .check_timings() operation, there's no need to repeat that when enabling the DPI output. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Call dispc timings check operation directlyLaurent Pinchart2018-09-039-50/+32
| | | | | | | | | | | | Instead of call the dispc timings check function dispc_mgr_timings_ok() from the internal encoders .check_timings() operation, expose it through the dispc ops (after renaming it to check_timings) and call it directly from omapdrm. This allows removal of now empty omap_dss_device .check_timings() operations. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Split mode fixup and mode set from encoder enableLaurent Pinchart2018-09-031-69/+79
| | | | | | | | | | | | | | | | | | | The encoder enable operation currently performs mode fixup and mode setting for all omap_dss_device instances in the display pipeline. There are dedicated encoder operations for those operations (respectively .atomic_check() and .mode_set()), but they are not used for this purpose. Move the mode fixup code to .atomic_check() and the mode set code .mode_set() to better fit the KMS model. The bus flags fixup has to happen at .mode_set() time as there is no place to store the bus flags in the atomic state structures. This could be solved by extending one of the state structures, but as the goal is to replace the fixup by direct usage of bus flags through the driver, that would be pointless. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Move bus flag hack to encoder implementationLaurent Pinchart2018-09-032-47/+43
| | | | | | | | | | | | | | | | | The bus flags stored in omap_dss_device instances are used to fixup the video mode before setting it, to honour constraints that can't be expressed through drm_display_mode. The fixup occurs in the CRTC mode set operation and the resulting video mode is stored internally in the CRTC. It is then used next by omap_encoder_enable() to apply mode fixups for the omap_dss_device instances in omap_encoder_update(). Move the hack to the omap_encoder_update() function right before applying the omap_dss_device fixups, in order to group all fixups together. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: panels: Don't modify fixed timingsLaurent Pinchart2018-09-037-21/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Panels drivers store their timings in a device data structure field that is initialized at probe time, either from hardcoded values or from firmware-supplied values. Those timings are then reported through the .get_timings() operation to construct the panel display mode. The panel timings are further modified by the .set_timings() operation, which is called with the timings retrieved by .get_timings(), and mangled by .check_timings(). The latter potentially adjusts the pixel clock only. Conceptually, modifying the panel timings is wrong, as the timings are an intrinsic property of the panel and should thus be fixed. Furthermore, modifying them this way at runtime can result in display modes reported to userspace varying between calls, which is also wrong. There's no actual need to store the mangled pixel clock value in the timings. Don't modify the panel timings in the .set_timings() operation, just forward it to the previous device in the display pipeline. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Remove .get_timings() operation from display connectorsLaurent Pinchart2018-09-033-94/+0
| | | | | | | | | | | | | | | | | | | | The analog TV, DVI and HDMI connectors all report timing information through the .get_timings() information. For analog TV outputs the information is queried from the encoder, so the operation is unused. Remove it. For HDMI outputs the display pipeline provides EDID capability, so the operation is unused as well. Remove it. For DVI outputs the operation is also unused if the pipeline provides EDID capability. Otherwise (when the DDC bus is not connected) we shouldn't hardcode a single mode, but instead report no mode and let the KMS core add default modes. This is achieved by removing the operation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Query timing information from analog TV encoderLaurent Pinchart2018-09-032-9/+37
| | | | | | | | | | | | | | | | Timings for the TV output are currently reported by the analog TV connector. This has the disadvantage of having to handle timing-related operations in a connector omap_dss_device that has, at the hardware level, no knowledge of any timing information. Implement the .get_timings() operation in the venc driver, and get timings from the first component in the pipeline that implements the operatation. This switches the duty of reporting analog TV timings from the connector to the encoder. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Don't call .check_timings() operation recursivelyLaurent Pinchart2018-09-0315-139/+32
| | | | | | | | | | | | The .check_timings() operation is called recursively from the display device back to the output device. Most components just forward the operation to the previous component in the chain, resulting in lots of duplicated pass-through functions. To avoid that, iterate over the components manually. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Store bus flags in the omap_dss_device structureLaurent Pinchart2018-09-0312-66/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Source components in the display pipeline need to configure their output signals polarities and clock driving edge based on the requirements of the sink component. Those requirements are currently shared across the whole pipeline in the flags of a videomode structure, instead of being local to each bus. This both prevents multiple buses from having different configurations (when the hardware supports it), and makes it difficult to move from videomode to drm_display_mode as the latter doesn't contain bus polarities and clock edge flags. Add a bus_flags field to the omap_dss_device structure and move the DISPLAY_FLAGS_DE_(LOW|HIGH), DISPLAY_FLAGS_PIXDATA_(POS|NEG)EDGE and DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE videomode flags to bus_flags in all external encoders, connectors and panels. The videomode flags are still used internally for internal encoders, this will be addressed in a second step. The related videomode flags in the default mode of the DVI connector can simply be dropped, as they are always overridden by the TFP410 driver. Note that this results in both the DISPLAY_FLAGS_SYNC_POSEDGE and DISPLAY_FLAGS_SYNC_NEGEDGE flags being set, which is invalid, but only the former is tested for when programming the DISPC, so the DVI connector flags are effectively overridden by the TFP410 flags. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Don't store video mode internally for external encodersLaurent Pinchart2018-09-033-15/+0
| | | | | | | | | | The omap_dss_device .set_timings() operation for external encoders stores the video mode in the device data structure. That mode is then never used again. Drop it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Remove unneeded fallback for missing .check_timings()Laurent Pinchart2018-09-032-38/+3
| | | | | | | | | | | | | | | The .check_timings() operation is present in all panels and connectors. The fallback that uses .get_timings() in the absence of .check_timings() is thus unneeded. While it could be argued that the fallback implements a useful check that should be extended to cover all fixed-resolution panels, the code is currently unused and gets in the way of the ongoing refactoring. Remove it, a similar feature can always be added later. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Remove duplicate calls to .set_timings() operationLaurent Pinchart2018-09-0313-28/+0
| | | | | | | | | | | | The omap_dss_device .set_timings() operations are called directly from omap_encoder_update(), and indirectly from the omap_dss_device .enable() operation. The latter is called from omap_encoder_enable(), right after calling omap_encoder_update(). The .set_timings() operation it thus called twice in a row. Fix it by removing the indirect call. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Make the video_mode pointer to .set_timings() constLaurent Pinchart2018-09-0319-19/+19
| | | | | | | | | The .set_timings() operations of the omap_dss_device instances don't need to modify the passed timings. Make the pointer const. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: encoder-tfp410: Don't fix timings in .set_timings() handlerLaurent Pinchart2018-09-031-2/+0
| | | | | | | | | | Both the .check_timings() and .set_timings() handlers call tfp410_fix_timings() to fix the timing's flags. As .check_timings() is always called before .set_timings(), there's no need to fix the flags twice. Remove the tfp410_fix_timings() call from .set_timings(). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: dss: hdmi: Rename hdmi_display_(set|check)_timing() functionsLaurent Pinchart2018-09-032-12/+12
| | | | | | | | | | | The two functions implement the .set_timings() and .check_timings() operations. Rename them to hdmi_disply_set_timings() and hdmi_display_check_timings() respectively to match the operations names and make searching the source code easier. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Determine connector type directly in omap_connector.cLaurent Pinchart2018-09-033-30/+31
| | | | | | | | | | | | Instead of determining the connector type from the type of the display's omap_dss_device and passing it to the omap_connector_init() function, move the type determination code to omap_connector.c and remove the type argument to the connector init function. This moves code to a more natural location, making the driver easier to read. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Pass both output and display omap_dss_device to connector initLaurent Pinchart2018-09-033-16/+21
| | | | | | | | | | | | | The drm_connector implementation requires access to the omap_dss_device corresponding to the display, which is passed to its initialization function and stored internally. Refactoring of the timings operations will require access to the output omap_dss_device. To prepare for that, pass it to the connector initialization function and store it internally as well. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Don't call HDMI mode and infoframe operations recursivelyLaurent Pinchart2018-09-033-42/+1
| | | | | | | | | | | | The HDMI mode (.set_hdmi_mode()) and infoframe (.set_infoframe()) operations are called recursively from the display device back to the HDMI encoder. This isn't required, as all components other than the HDMI encoder just forward the operation to the previous component in the chain. Call the operations directly on the HDMI encoder. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Pass both output and display omap_dss_device to encoder initLaurent Pinchart2018-09-033-9/+13
| | | | | | | | | | | | | The drm_encoder implementation requires access to the omap_dss_device corresponding to the display, which is passed to its initialization function and stored internally. Clean up of the HDMI mode and infoframe handling will require access to the output omap_dss_device. To prepare for that, pass it to the encoder initialization function and store it internally as well. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Get from CRTC to display device directlyLaurent Pinchart2018-09-033-31/+4
| | | | | | | | | | | | | | | The CRTC mode set implementation needs to access the omap_dss_device for the pipeline display. To do so, it iterates over all pipelines to find the one that contains an encoder corresponding to the CRTC, and request the display device from the encoder. That's a very complicated dance when the CRTC has a direct pipeline pointer already, and the pipeline contains a pointer to the display device. Replace the convoluted code with direct access. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Don't call EDID read operation recursivelyLaurent Pinchart2018-09-036-77/+65
| | | | | | | | | | | | Instead of calling the EDID read operation (.read_edid()) recursively from the display device back to the first device that provides EDID read support, iterate over the devices manually in the DRM connector code. This moves the complexity to a single central location and simplifies the logic in omap_dss_device drivers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Move HPD disconnection handling to omap_connectorLaurent Pinchart2018-09-033-18/+29
| | | | | | | | | | | | | | | On HDMI outputs, CEC support requires notification of HPD signal deassertion. The HPD signal can be handled by various omap_dss_device instances in the pipeline, and all of them forward HPD events to the OMAP4 internal HDMI encoder. Knowledge of the DSS internals need to be removed from the omap_dss_device instances in order to migrate to drm_bridge. To do so, move HPD handling for CEC to the omap_connector. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Merge HPD enable operation with HPD callback registrationLaurent Pinchart2018-09-037-97/+35
| | | | | | | | | | | | | | | | | | | | | | | | The omap_dss_device .enable_hpd() and .disable_hpd() are used to enable and disable hot-plug detection at omapdrm probe and remove time. This is required to avoid reporting hot-plug detection events before the DRM infrastructure is ready to accept them, as that could result in crashes or other malfunction. Hot-plug event reporting is conditioned by both HPD being enabled through the .enable_hpd() operation and by the HPD callback being registered though the .register_hpd_cb() operation. We thus don't need a separate enable operation if we can guarantee that callbacks won't be registered too early. HPD callbacks are registered at connector initialization time, which is too early to start reporting HPD events. There's however nothing blocking a move of callback registration to a later time when the omapdrm driver calls the HPD enable operations. Do so, and remove the HPD enable operation completely from omap_dss_device drivers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Remove unneeded safety checks in the HPD operationsLaurent Pinchart2018-09-035-40/+14
| | | | | | | | | | | The HPD-related omap_dss_device operations are now only called when the device supports HPD. There's no need to duplicate that check in the omap_dss_device drivers. The .register_hpd_cb() operation can as a result be turned into a void operation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Don't call HPD registration operations recursivelyLaurent Pinchart2018-09-034-69/+88
| | | | | | | | | | | | | Instead of calling the hot-plug detection callback registration operations (.register_hpd_cb() and .unregister_hpd_cb()) recursively from the display device back to the first device that provides hot plug detection support, iterate over the devices manually in the DRM connector code. This moves the complexity to a single central location and simplifies the logic in omap_dss_device drivers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Don't call .detect() operation recursivelyLaurent Pinchart2018-09-034-18/+30
| | | | | | | | | | | | Instead of calling the .detect() operation recursively from the display device back to the first device that provides hot plug detection support, iterate over the devices manually in the DRM connector .detect() implementation. This moves the complexity to a single central location and simplifies the logic in omap_dss_device drivers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: dss: Add device operations flagsLaurent Pinchart2018-09-031-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | When an omap_dss_device operation can be implemented in multiple places in a chain of devices, it is important to find out which device to address to perfom the operation. This is currently done by calling the operation on the display device at the end of the chain, and recursively delagating the operation to the previous device if it can't be performed locally. The drawback of this approach is an increased complexity in omap_dss_device drivers. In order to simplify the drivers, we will switch from a recursive model to an interative model, centralizing the complexity in a single location. This requires knowing which operations an omap_dss_device supports at runtime. We can already test which operations are implemented by checking the operation pointer, but implemented operations can require resources whose availability varies between systems. For instance a hot-plug signal from a connector can be wired to a GPIO or to a bridge chip. Add operation flags that can be set in the omap_dss_device structure by drivers to signal support for operations. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Move most omap_dss_driver operations to omap_dss_device_opsLaurent Pinchart2018-09-0321-137/+106
| | | | | | | | | | | | | | | | | | omap_dss_device instances have two ops structures, omap_dss_driver and omap_dss_device_ops. The former is used for devices at the end of the pipeline (a.k.a. display devices), and the latter for intermediate devices. Having two sets of operations isn't convenient as code that iterates over omap_dss_device instances need to take them both into account. There's currently a reasonably small amount of such code, but more will be introduced to move the driver away from recursive operations. To simplify current and future code, move all operations that are not specific to the display device to the omap_dss_device_ops. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: panel-tpo-td043mtea1: Convert to the GPIO descriptors APILaurent Pinchart2018-09-031-38/+14
| | | | | | | | | | | | | | | | The GPIO descriptor API is favoured over the plain GPIO API for consumer drivers. Using it simplifies the driver code. As the descriptor API handles the active-low flag internally we need to invert the polarity of all GPIO operations in the driver. Rename the nreset_gpio field to reset_gpio to reflect that. The reset GPIO is mandatory, so drop conditional tests through the driver. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: panel-tpo-td028ttec1: Drop unneeded linux/gpio.h headerLaurent Pinchart2018-09-031-1/+0
| | | | | | | | | The driver doesn't use GPIOs and thus doesn't need to include the linux/gpio.h header. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: panel-sony-acx565akm: Convert to the GPIO descriptors APILaurent Pinchart2018-09-031-35/+21
| | | | | | | | | The GPIO descriptor API is favoured over the plain GPIO API for consumer drivers. Using it simplifies the driver code. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: panel-nec-nl8048hl11: Convert to the GPIO descriptors APILaurent Pinchart2018-09-031-43/+11
| | | | | | | | | | | | The GPIO descriptor API is favoured over the plain GPIO API for consumer drivers. Using it simplifies the driver code. The reset GPIO is mandatory, so drop conditional tests through the driver. The qvga GPIO is unused, so drop it completely. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-19 06:50:59 +0000