drm/tidss: Add support for display sharing
commit 665c17837dc8bed27e8d63388f8f7f7a85c0cd94 from git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git Display subsystem present in TI Keystone family of devices supports sharing of display between multiple hosts as it provides separate register space (common* region) for each host to programming display controller and also a unique interrupt line for each host. This adds support for display sharing, by allowing partitioning of resources either at video port level or at video plane level as described below : 1) Linux can own (i.e have write access) completely one or more of video ports along with corresponding resources (viz. overlay managers, video planes) used by Linux in context of those video ports. Even if Linux is owning these video ports it can still share this video port with a remote core which can own one or more video planes associated with this video port. 2) Linux owns one or more of the video planes with video port (along with corresponding overlay manager) associated with these planes being owned and controlled by a remote core. Linux still has read-only access to the associated video port and overlay managers so that it can parse the settings made by remote core. For both the cases, the resources used in context of processing core running Linux along with ownership information are exposed by user as part of device-tree blob and driver uses an updated feature list tailored for this shared mode accordingly. The driver also auto-populates matching overlay managers and output types from shared video port list provided in device-tree blob. In dispc_feature struct remove const access specfier for output_type array as it is required to be updated dynamically in run-time for shared mode. For 2) where Linux is only owning a set of video planes with corresponding video port and overlay manager controlled by a remote core, separate set of CRTC callbacks are used which just latch on to the preset mode set by remote core, thus avoiding any reconfiguration of associated video ports, overlay managers and clocks. For this case, it is also checked that Linux controlled video planes don't exceed screen size set by remote core while running the display. Display clocks and OLDI related fields are also not populated for this scenario as remote core is owning those resources. For 1), where Linux owns only a set of video port and associated planes with rest of resources owned completely by remote cores, only those set of resources are exposed to Linux and programmed using traditional CRTC helpers and rest of video ports and associated resources are removed from feature list accordingly. Signed-off-by:Devarsh Thakkar <devarsht@ti.com> Signed-off-by:
Xulin Sun <xulin.sun@windriver.com>
Loading
Please register or sign in to comment