Hi, Thanks a lot for working on that. On Tue, Jan 16, 2024 at 07:11:41PM +0530, Devarsh Thakkar wrote: > 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. So, just to make sure we're on the same page. 1) means Linux drives the whole display engine, but can lend planes to the R5? How does that work, is Linux aware of the workload being there (plane size, format, etc) ? And 2) would mean that the display engine is under the R5 control and Linux only gets to fill the plane and let the firmware know of what it wants? If so, do we even need the tidss driver in the second case? We could just write a fwkms driver of some sorts that could be used by multiple implementations of the same "defer to firmware" logic. > 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. I'm also not entirely sure that the device tree is the right path there. Surely the firmware capabilities will evolve over time, while the device tree won't. Is there some way to make it discoverable at probe time by the driver? Maxime
Attachment:
signature.asc
Description: PGP signature
