summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/omapdrm/displays
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'drm-next-2019-07-16' of git://anongit.freedesktop.org/drm/drmLinus Torvalds2019-07-151-12/+6
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm updates from Dave Airlie: "The biggest thing in this is the AMD Navi GPU support, this again contains a bunch of header files that are large. These are the new AMD RX5700 GPUs that just recently became available. New drivers: - ST-Ericsson MCDE driver - Ingenic JZ47xx SoC UAPI change: - HDR source metadata property Core: - HDR inforframes and EDID parsing - drm hdmi infoframe unpacking - remove prime sg_table caching into dma-buf - New gem vram helpers to reduce driver code - Lots of drmP.h removal - reservation fencing fix - documentation updates - drm_fb_helper_connector removed - mode name command handler rewrite fbcon: - Remove the fbcon notifiers ttm: - forward progress fixes dma-buf: - make mmap call optional - debugfs refcount fixes - dma-fence free with pending signals fix - each dma-buf gets an inode Panels: - Lots of additional panel bindings amdgpu: - initial navi10 support - avoid hw reset - HDR metadata support - new thermal sensors for vega asics - RAS fixes - use HMM rather than MMU notifier - xgmi topology via kfd - SR-IOV fixes - driver reload fixes - DC use a core bpc attribute - Aux fixes for DC - Bandwidth calc updates for DC - Clock handling refactor - kfd VEGAM support vmwgfx: - Coherent memory support changes i915: - HDR Support - HDMI i2c link - Icelake multi-segmented gamma support - GuC firmware update - Mule Creek Canyon PCH support for EHL - EHL platform updtes - move i915.alpha_support to i915.force_probe - runtime PM refactoring - VBT parsing refactoring - DSI fixes - struct mutex dependency reduction - GEM code reorg mali-dp: - Komeda driver features msm: - dsi vs EPROBE_DEFER fixes - msm8998 snapdragon 835 support - a540 gpu support - mdp5 and dpu interconnect support exynos: - drmP.h removal tegra: - misc fixes tda998x: - audio support improvements - pixel repeated mode support - quantisation range handling corrections - HDMI vendor info fix armada: - interlace support fix - overlay/video plane register handling refactor - add gamma support rockchip: - RX3328 support panfrost: - expose perf counters via hidden ioctls vkms: - enumerate CRC sources list ast: - rework BO handling mgag200: - rework BO handling dw-hdmi: - suspend/resume support rcar-du: - R8A774A1 Soc Support - LVDS dual-link mode support - Additional formats - Misc fixes omapdrm: - DSI command mode display support stm - fb modifier support - runtime PM support sun4i: - use vmap ops vc4: - binner bo binding rework v3d: - compute shader support - resync/sync fixes - job management refactoring lima: - NULL pointer in irq handler fix - scheduler default timeout virtio: - fence seqno support - trace events bochs: - misc fixes tc458767: - IRQ/HDP handling sii902x: - HDMI audio support atmel-hlcdc: - misc fixes meson: - zpos support" * tag 'drm-next-2019-07-16' of git://anongit.freedesktop.org/drm/drm: (1815 commits) Revert "Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux into drm-next" Revert "mm: adjust apply_to_pfn_range interface for dropped token." mm: adjust apply_to_pfn_range interface for dropped token. drm/amdgpu/navi10: add uclk activity sensor drm/amdgpu: properly guard the generic discovery code drm/amdgpu: add missing documentation on new module parameters drm/amdgpu: don't invalidate caches in RELEASE_MEM, only do the writeback drm/amd/display: avoid 64-bit division drm/amdgpu/psp11: simplify the ucode register logic drm/amdgpu: properly guard DC support in navi code drm/amd/powerplay: vega20: fix uninitialized variable use drm/amd/display: dcn20: include linux/delay.h amdgpu: make pmu support optional drm/amd/powerplay: Zero initialize current_rpm in vega20_get_fan_speed_percent drm/amd/powerplay: Zero initialize freq in smu_v11_0_get_current_clk_freq drm/amd/powerplay: Use memset to initialize metrics structs drm/amdgpu/mes10.1: Fix header guard drm/amd/powerplay: add temperature sensor support for navi10 drm/amdgpu: fix scheduler timeout calc drm/amdgpu: Prepare for hmm_range_register API change (v2) ...
| * Merge v5.2-rc5 into drm-nextDaniel Vetter2019-06-192-10/+2
| |\ | | | | | | | | | | | | | | | | | | Maarten needs -rc4 backmerged so he can pull in the fbcon notifier removal topic branch into drm-misc-next. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/omap: Use dev_get_drvdata()Kefeng Wang2019-06-101-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using dev_get_drvdata directly. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | | treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner2019-06-197-28/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | | treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 234Thomas Gleixner2019-06-192-24/+2
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not see http www gnu org licenses extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 503 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Enrico Weigelt <info@metux.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190602204653.811534538@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152Thomas Gleixner2019-05-302-10/+2
|/ | | | | | | | | | | | | | | | | | | | | Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner2019-05-211-0/+1
| | | | | | | | | | | | | | Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/omap: panel-tpo-td028ttec1: add backlight supportAndreas Kemnade2019-03-181-0/+10
| | | | | | | | | | | | This panel has a backlight, so fetch it from devicetree using the corresponding property as documented in panel-common.txt. It is implemented the same way as in panel-dpi.c This ensures the backlight is also disabled when the display is turned off like when doing xset dpms force off. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Remove panel-dpi driverLaurent Pinchart2019-03-183-206/+0
| | | | | | | | | | Panels are now supported through the drm_panel infrastructure, remove the omapdrm-specific driver. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Remove TFP410 and DVI connector driversLaurent Pinchart2019-03-184-446/+0
| | | | | | | | | | Those components are supported by the drm_bridge infrastructure, remove the omapdrm-specific driver. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flagsLaurent Pinchart2019-03-187-14/+21
| | | | | | | | | | | | | | | | | | The DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and DRM_BUS_FLAG_SYNC_(POS|NEG)EDGE flags are deprecated in favour of the new DRM_BUS_FLAG_PIXDATA_(DRIVE|SAMPLE)_(POS|NEG)EDGE and new DRM_BUS_FLAG_SYNC_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags. Replace them through the code. This effectively changes the value of the .sampling_edge bridge timings field in the dumb-vga-dac driver. This is safe to do as no driver consumes these values yet. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Stefan Agner <stefan@agner.ch> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Merge omap_dss_device type and output_type fieldsLaurent Pinchart2019-03-1814-3/+11
| | | | | | | | | | | | | | | | | | | | | | The omap_dss_device type and output_type fields differ mostly for historical reasons. The output_type field is required for all devices but the display at the end of the pipeline, and must be set to OMAP_DISPLAY_TYPE_NONE for the latter. The type field is required for all devices but the internal encoder, for which it is ignored. The only reason why the output_type field must be set to OMAP_DISPLAY_TYPE_NONE for the display at the end of the pipeline is to identify omap_dss_device instances corresponding to displays. This is not documented and confusing. Clean the code by adding a new display field to the omap_dss_device structure to identify displays, and merge the type and output_type fields. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Pass drm_display_mode to .check_timings() and .set_timings()Laurent Pinchart2019-03-181-4/+4
| | | | | | | | | | | | | | | | | | The omap_dss_device .check_timings() and .set_timings() operations operate on struct videomode, while the DRM API operates on struct drm_display_mode. This forces conversion from to videomode in the callers. While that's not a problem per se, it creates a difference with the drm_bridge API. Replace the videomode parameter to the .check_timings() and .set_timings() operations with a drm_display_mode. This pushed the conversion to videomode down to the DSS devices in some cases. If needed they will be converted to operate on drm_display_mode natively. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: panel-dsi-cm: Store source pointer internallyLaurent Pinchart2019-03-181-26/+29
| | | | | | | | | | The source pointer will be removed to the omap_dss_device structure. Store it internally in the DSI panel driver data. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Add a dss device operation flag for .get_modes()Laurent Pinchart2019-03-188-0/+8
| | | | | | | | | | | | Instead of manually iterating over the dss devices in the pipeline to find the first one that implements the .get_modes() operation, add a new operation flag for .get_modes() and use the omap_connector_find_device() helper function to locate the right dss device. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Merge display .get_modes() and .get_size() operationsLaurent Pinchart2019-03-181-11/+3
| | | | | | | | | | | Now that the .get_modes() operations takes a drm_connector and fills it with modes, it becomes easy to fill display information in the same operation without requiring a separate .get_size() opearation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Expose DRM modes instead of timings in display devicesLaurent Pinchart2019-03-188-32/+34
| | | | | | | | | | | | | | | | omap_dss_device operations expose fixed video timings through a .get_timings() operation that return a single timing for the device. To prepare for the move to drm_bridge, modify the API to instead add DRM modes directly to the connector. As this puts more burden on display devices, we also create a helper function for panels to add a single DRM mode from the panel video timings. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Reverse direction of the DSS device enable/disable operationsLaurent Pinchart2019-03-1814-260/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | The omapdrm and omapdss drivers are architectured based on display pipelines made of multiple components handled from sink (display) to source (DSS output). This is incompatible with the DRM bridge and panel APIs that handle components from source to sink. Reconcile the omapdrm and omapdss drivers with the DRM bridge and panel model by reversing the direction of the DSS device .enable() and .disable() operations. This completes the move to the DRM bridge model, with the notable exception of the DSI pipelines that will require more work. We also adapt the omapdss shutdown handler dss_shutdown() to shut down all active pipelines starting from the pipeline output device instead of the display device. As a consequence the for_each_dss_display() macro isn't used and can be removed, and the omapdss_device_get_next() function underlying the macro can be simplified to search for output devices only. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Remove enable checks from display .enable() and .remove()Laurent Pinchart2019-03-1813-58/+25
| | | | | | | | | | | | | | | | | | | | | | | The displays (connectors, panels and encoders) bail out from their .enable() and .disable() handlers if the dss device is already enabled or disabled. Those safety checks are not needed when the functions are called through the omapdss_device_ops, as the .enable() and .disable() handlers are called from the DRM atomic helpers that already guarantee that no double enabling or disabling can occur. However, the handlers are also called directly from the .remove() handler. While this shouldn't be needed either as the modules can't be removed as long as the device is in use, it's still a good practice to disable the device explicitly. There is currently a safety check in .remove() in some drivers but not all of them. Remove the safety checks from the .enable() and .disable() handlers, and add missing ones in the .remove() handler. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Remove connection checks from display .enable() and .remove()Laurent Pinchart2019-03-183-18/+0
| | | | | | | | | | | | | | | | | | | | | | | | | The displays (connectors, panels and encoders) return an error from their .enable() handler when the dss device is not connected. They also disconnect the dss device explicitly from their .remove() handler if it is still connected. Those safety checks are not needed: - The .enable() handler is called from code paths that access the dss devices chain from the display device, which is set to NULL when the device isn't connected. - The .remove() handler can only be called when unloading the module as the driver has the suppress_bind_attrs attribute set, and a reference to the module is taken when constructing the dss devices chain, so the module can only be unloaded when the dss device is disconnected. Remove the safety checks. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: Move common display enable/disable code to encoderLaurent Pinchart2019-03-1811-158/+5
| | | | | | | | | | | | | | | All .enable() and .disable() handlers for panels and connectors share common code that validates and updates the device's state. Move it to common locations in the omap_encoder_enable() and omap_encoder_disable() handlers. The enabled check in the .disable() handler is left untouched, it will be addressed separately. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: fix bus_flags for panel-dpiTomi Valkeinen2018-12-031-0/+1
| | | | | | | | | | | | | | | | | panel-dpi used to convey the bus-flags via the videomode, but recent changes changed the use of videomode to DRM's drm_display_mode which does not contain bus-flags. This broke panel-dpi, which didn't explicitly store the bus-flags into dssdev->bus_flags. Fix this by setting dssdev->bus_flags. Also change the bus_flags type to u32, as that is the type used in the DRM framework, and we would get a warning with drm_bus_flags_from_videomode() otherwise. Fixes: 3fbda31e814868d8477ddf52d74b7b8f596578e8 ("drm/omap: Split mode fixup and mode set from encoder enable") Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: H. Nikolaus Schaller <hns@goldelico.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181126092447.11864-1-tomi.valkeinen@ti.com Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
* drm/omap: Don't call .set_timings() operation recursivelyLaurent Pinchart2018-09-0313-122/+0
| | | | | | | | | | | 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: 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: Don't call .check_timings() operation recursivelyLaurent Pinchart2018-09-0313-119/+0
| | | | | | | | | | | | 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-038-46/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 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-0313-13/+13
| | | | | | | | | 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: Don't call HDMI mode and infoframe operations recursivelyLaurent Pinchart2018-09-032-41/+0
| | | | | | | | | | | | 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: Don't call EDID read operation recursivelyLaurent Pinchart2018-09-033-34/+5
| | | | | | | | | | | | 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-032-12/+2
| | | | | | | | | | | | | | | 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-033-76/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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-033-24/+7
| | | | | | | | | | | 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-033-40/+38
| | | | | | | | | | | | | 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-033-5/+7
| | | | | | | | | | | | 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: Move most omap_dss_driver operations to omap_dss_device_opsLaurent Pinchart2018-09-0312-43/+50
| | | | | | | | | | | | | | | | | | 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>
* drm/omap: encoder-tfp410: Convert to the GPIO descriptors APILaurent Pinchart2018-09-031-38/+13
| | | | | | | | | | | | 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. 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: connector-hdmi: Convert to the GPIO descriptors APILaurent Pinchart2018-09-031-37/+20
| | | | | | | | | 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: dss: Remove omap_dss_driver .[gs]et_mirror operationsLaurent Pinchart2018-09-031-23/+2
| | | | | | | | | | The .get_mirror() and .set_mirror() omap_dss_driver operations are implemented by the panel-tpo-td043mtea1 driver but are never used. Remove them. 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: Reverse direction of DSS device (dis)connect operationsLaurent Pinchart2018-09-0314-338/+75
| | | | | | | | | | | | | | The omapdrm and omapdss drivers are architectured based on display pipelines made of multiple components handled from sink (display) to source (DSS output). This is incompatible with the DRM bridge and panel APIs that handle components from source to sink. To reconcile the omapdrm and omapdss drivers with the DRM bridge and panel model, we need to reverse the direction of the DSS device operations. Start with the connect and disconnect operations. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* drm/omap: dss: Acquire next dssdev at probe timeLaurent Pinchart2018-09-033-0/+27
| | | | | | | | | | Look up the next dssdev at probe time based on device tree links for all DSS outputs and encoders. This will be used to reverse the order of the dssdev connect and disconnect call chains. 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: displays: Don't cast dssdev to panel data unnecessarilyLaurent Pinchart2018-09-032-6/+4
| | | | | | | | | | The connect handle of the analog TV and HDMI connectors casts the dssdev to panel data only to then access fields of the panel data that are also present in the dssdev. Remove the cast and use dssdev directly. 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: Extend omapdss_of_find_source_for_first_ep() to sinksLaurent Pinchart2018-09-0314-36/+36
| | | | | | | | | | | | | | | | | | | | | | The omapdss_of_find_source_for_first_ep() function locates the source corresponding to the first endpoint of the first port of a device node. We can easily extend it to locate sinks as well by passing the port number as a parameter. This will be useful to find sinks in encoders drivers. Extend the function and rename it to omapdss_of_find_connected_device() to reflect its new extended purpose. Additionally, it is useful to differentiate between failures to return the connected device because no link exists in the device tree for the requested port, or because the connected device as described in the device tree is invalid or not probed yet. Return NULL in the first case and an error code in the second case, and update the callers 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-10 13:48:31 +0000