aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
AgeCommit message (Collapse)AuthorFilesLines
2020-12-15drm/panel: Move OMAP's DSI command mode panel driverSebastian Reichel1-637/+0
The panel driver is no longer using any OMAP specific APIs, so let's move it into the generic panel directory. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Cc: Thierry Reding <[email protected]> Cc: Sam Ravnborg <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: panel-dsi-cm: fix remove()Sebastian Reichel1-3/+0
Do not try to reset the panel after DSI has been detached, since the DSI clocks may have been disabled at this point. The panel will be disabled and unprepared before being removed and a reset will be done when being probed again. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: panel-dsi-cm: support unbindingSebastian Reichel1-3/+2
Now, that the driver implements the common DRM panel API the unbind no longer needs to be suppressed. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Acked-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: panel-dsi-cm: use DEVICE_ATTR_ROSebastian Reichel1-4/+4
Use DEVICE_ATTR_RO helper instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: convert to drm_panelSebastian Reichel1-126/+77
This converts the DSI module to expect common drm_panel display drivers instead of dssdev based ones. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: drop custom panel capability supportSebastian Reichel1-3/+0
Due to previous changes the DSI encoder gets the capabilities via DSI client's mode_flags and no longer needs the omapdss specific caps. The core code now checks if the DSI encoder is actually configured into command mode instead of just checking the panel capabilities. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: Reverse direction of the DSS device enable/disable operationsSebastian Reichel1-37/+37
Complete the direction reversal of the DSS device enable/disable operations started by commit 19b4200d8f4b ("drm/omap: Reverse direction of the DSS device enable/disable operations"). This effectively drops the requirement of calling DSS specific code from the DSI panel driver moving it a bit further to a standard drm_panel driver. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: move panel refresh function to hostSebastian Reichel1-68/+0
This moves the panel refresh/update function from the panel driver into the DSI host driver to prepare for common drm_panel support. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: do ULPS in host driverSebastian Reichel1-259/+7
Move ULPS handling into the DSI host controller, so that we no longer need a custom API for the DSI client. Note that for now ULPS is always disabled. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Acked-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: untangle ulps ops from enable/disableSebastian Reichel1-4/+4
Create a custom function pointer for ULPS and use it instead of reusing disable/enable functions for ULPS mode switch. This allows us to use the common disable/enable functions pointers for DSI. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: do bus locking in host driverSebastian Reichel1-43/+1
This moves the bus locking into the host driver and unexports the custom API in preparation for drm_panel support. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: drop custom enable_te() APISebastian Reichel1-3/+0
Instead of using the custom enable_te() API, this automatically enables/disables TE core support when a matching packet is sent to the panel. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: move TE GPIO handling into coreSebastian Reichel1-97/+7
In preparation for removing custom DSS calls from the DSI panel driver, this moves support for external tearing event GPIOs into the DSI host driver. This way tearing events are always handled in the core resulting in simplification of the panel drivers. The TE GPIO acquisition follows works in the same way as the exynos DSI implementation. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: lp/hs switching support for transfer()Sebastian Reichel1-3/+3
Integrate low-power / high-speed bus switching into transfer function and drop the omapdrm specific enable_hs() callback. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: panel-dsi-cm: use bulk regulator APISebastian Reichel1-44/+21
Use bulk regulator API to simplify the code. This also switches from _optional variant to normal variant, which will provide a dummy regulator (i.e. if some always-enabled regulator is not described in DT). Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: use pixel-format and mode from attachSebastian Reichel1-2/+0
In order to reduce the amount of custom functionality, this moves handling of pixel format and DSI mode from set_config() to dsi attach. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: drop useless sync()Sebastian Reichel1-18/+0
The DSI sync() function only locks the bus and then releases it again. Currently the only invocation is directly before update(), which locks the bus anyways. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: drop unused enable_te()Sebastian Reichel1-39/+0
enable_te() is not used, so the custom API can be dropped. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: drop unused get_te()Sebastian Reichel1-13/+0
The get_te() callback is not used, so we can drop the custom API. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: drop unused memory_read()Sebastian Reichel1-93/+0
memory_read is not used, so we can drop the code. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: panel-dsi-cm: use common MIPI DCS 1.3 definesSebastian Reichel1-5/+4
Drop local definition of common MIPI DCS 1.3 defines. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: panel-dsi-cm: drop hardcoded VCSebastian Reichel1-13/+7
Use dsi->channel everywhere, which originates from DT. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: request VC via mipi_dsi_attachSebastian Reichel1-9/+15
Drop custom request_vc/release_vc callbacks by using the generic mipi_dsi_attach/mipi_dsi_detach functions. To use mipi_dsi_attach() we need to fill in the mipi_dsi_device fields, and some of these fields overlap with the fields in omap_dss_dsi_config. In later patches the latter will get dropped. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: panel-dsi-cm: use DSI helpersSebastian Reichel1-107/+18
After converting the driver to mipi_dsi_device we can use the generic message helpers to simplify the driver a lot. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: introduce mipi_dsi_hostSebastian Reichel1-61/+60
This moves from custom platform driver infrastructure to mipi_dsi_host and mipi_dsi_device. Note, that this is a graduate step and the driver only uses the devices types and transfer function, but not yet the new device binding style or drm_panel. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: drop virtual channel logicSebastian Reichel1-8/+3
This drops the virtual channel logic. Afterwards DSI clients request their channel number and get the virtual channel with the same number or -EBUSY if already in use. The change here is not strictly speaking correct, as it combines the VC (DSI's "configuration block") and virtual channel ID (the ID sent in the DSI packets). But as we currently only support a single DSI command mode panel, this works fine: we always use VC0, and VC ID 0. This needs more work to support video mode panels, but that can be done after moving to DRM bridge and panel model, after which we can do that work with the proper APIs. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: panel-dsi-cm: convert to transfer APISebastian Reichel1-37/+95
This converts the panel-dsi-cm driver to use the transfer API instead of specific functions, so that the specific functions can be unexported and squashed into the generic transfer function. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Acked-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: use MIPI_DSI_FMT_* instead of OMAP_DSS_DSI_FMT_*Sebastian Reichel1-1/+1
This replaces OMAP specific enum for pixel format with common implementation. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: drop unused dsi.configure_pinsSebastian Reichel1-11/+0
The panel-dsi-cm's ddata->pin_config is always NULL, so this callback is never called. Instead the DSI encoder gets the pin configuration directly from DT. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-10drm: omapdrm: Replace HTTP links with HTTPS onesAlexander A. Klimov1-1/+1
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-17drm/omap: display: use devm_of_find_backlightSam Ravnborg1-10/+8
Look up backlight device using devm_of_find_backlight(). This simplifies the code and prevents us from hardcoding the node name in the driver. Signed-off-by: Sam Ravnborg <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Cc: Tomi Valkeinen <[email protected]> Cc: Zheng Bin <[email protected]> Cc: Kate Stewart <[email protected]> Cc: Enrico Weigelt <[email protected]> Cc: Allison Randal <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Kefeng Wang <[email protected]> Cc: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-26drm/omap: dss: Fix output next device lookup in DTLaurent Pinchart1-1/+1
The DSS core looks up the next device connected to an output by traversing the OF graph. It currently hardcodes the local port number to 0, which breaks any output with a different port number (SDI on OMAP3 and any DPI output but the first one). Fix this by repurposing the currently unused of_ports bitmask in omap_dss_device with an of_port output port number, and use it to traverse the OF graph. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-11drm/omap: use true,false for bool variableZheng Bin1-2/+2
Fixes coccicheck warning: drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c:681:1-15: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c:732:1-15: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <[email protected]> Signed-off-by: Zheng Bin <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-07-15Merge tag 'drm-next-2019-07-16' of git://anongit.freedesktop.org/drm/drmLinus Torvalds1-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) ...
2019-06-19treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner1-4/+1
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 <[email protected]> Reviewed-by: Enrico Weigelt <[email protected]> Reviewed-by: Kate Stewart <[email protected]> Reviewed-by: Allison Randal <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-06-10drm/omap: Use dev_get_drvdata()Kefeng Wang1-12/+6
Using dev_get_drvdata directly. Cc: Tomi Valkeinen <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Signed-off-by: Kefeng Wang <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2019-03-18drm/omap: Merge omap_dss_device type and output_type fieldsLaurent Pinchart1-0/+1
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 <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2019-03-18drm/omap: Pass drm_display_mode to .check_timings() and .set_timings()Laurent Pinchart1-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 <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2019-03-18drm/omap: panel-dsi-cm: Store source pointer internallyLaurent Pinchart1-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 <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2019-03-18drm/omap: Add a dss device operation flag for .get_modes()Laurent Pinchart1-0/+1
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 <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2019-03-18drm/omap: Merge display .get_modes() and .get_size() operationsLaurent Pinchart1-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 <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2019-03-18drm/omap: Expose DRM modes instead of timings in display devicesLaurent Pinchart1-4/+6
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 <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2019-03-18drm/omap: Reverse direction of the DSS device enable/disable operationsLaurent Pinchart1-16/+6
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 <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2019-03-18drm/omap: Remove enable checks from display .enable() and .remove()Laurent Pinchart1-6/+5
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 <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2019-03-18drm/omap: Move common display enable/disable code to encoderLaurent Pinchart1-18/+0
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 <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2018-09-03drm/omap: Move most omap_dss_driver operations to omap_dss_device_opsLaurent Pinchart1-4/+8
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 <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2018-09-03drm/omap: Reverse direction of DSS device (dis)connect operationsLaurent Pinchart1-32/+10
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 <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2018-09-03drm/omap: dss: Extend omapdss_of_find_source_for_first_ep() to sinksLaurent Pinchart1-3/+3
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 <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2018-09-03drm/omap: dss: Replace omap_dss_device port number with bitmaskLaurent Pinchart1-0/+1
The omap_dss_device port_num field stores the DT port number associated with the device. The field is used in different ways depending on the device type: - For DPI outputs, the port number is used as an identifier of the DPI instance - For sources, the port number is used to look up the omap_dss_device by DT port node As omap_dss_device instances are only looked up as sources by sinks, setting the field to the number of the source port works for both use cases. However, to enable looking up sinks, we need to record all the ports associated with an omap_dss_device. Do so by turning the port_num field into an of_ports bitmask. For DPI outputs the port number is additionally stored in the dpi_data structure as the output ID. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2018-09-03drm/omap: dss: Store dss_device pointer in omap_dss_deviceLaurent Pinchart1-1/+1
Storing the dss_device pointer in the omap_dss_device structure will allow accessing the dss_device from the dss_mgr API functions. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.