Devarsh Thakkar <devarsht@xxxxxx> writes: Hello Devarsh and Maxime, > Hi Maxime, > > On 14/03/24 20:04, Maxime Ripard wrote: >> Hi, >> >> On Wed, Feb 14, 2024 at 09:17:12PM +0530, Devarsh Thakkar wrote: >>> On 13/02/24 19:34, Maxime Ripard wrote: >>>> On Thu, Feb 08, 2024 at 06:26:17PM +0530, Devarsh Thakkar wrote: >>>>> On 26/01/24 17:45, Maxime Ripard wrote: >>>>>> 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) ? >>>>>> >>>>> >>>>> Well, there is no dynamic procedure being followed for lending. The >>>>> partitioning scheme is decided and known before hand, and the remote >>>>> core firmware updated and compiled accordingly, and similarly the >>>>> device-tree overlay for Linux is also updated with partitioning >>>>> information before bootup. >>>>> >>>>> What would happen here is that Linux will know before-hand this >>>>> partitioning information via device-tree properties and won't enumerate >>>>> the plane owned by RTOS, but it will enumerate the rest of the display >>>>> components and initialize the DSS, after which user can load the DSS >>>>> firmware on remote core and this firmware will only have control of >>>>> plane as it was compiled with that configuration. >>>> >>>> Right. If the RTOS is in control of a single plane, how it is expected >>>> to deal with Linux shutting the CRTC down, or enforcing a configuration >>>> that isn't compatible with what the RTOS expects (like a plane with a >>>> higher zpos masking its plane), what is the mechanism to reconcile it? >>>> >>> >>> Just for the note, for this "RTOS control single plane" mode, we don't have a >>> firmware available to test (right now we are only supporting example for "RTOS >>> controlling the display mode" as shared here [1]) and hence this is not >>> validated but the idea was to keep dt-bindings generic enough to support them >>> in future and that's why I referred to it here. >>> If I understand you correctly, for now the only real use case is when the the RTOS owns / manages the complete display pipeline and Linux can only own video planes. The opposite is supported by the DSS hardware (thanks to its feature that allows partitioning the register space and having multiple per-host IRQs) but it's not a real use case yet. The reason why this case is added to the DT binding is as you said for flexiblity and make the design future-proof. >>> separate irq >>> Coming back to your questions, with the current scheme the Linux (tidss) would >>> be expected to make sure the CRTC being shared with RTOS is never shutdown and >>> the RTOS plane should never gets masked. >> >> I'm probably missing something then here, but if the Linux side of >> things is expected to keep the current configuration and keep it active >> for it to work, what use-case would it be useful for? >> > > It's just one of the partitioning possibilities that I mentioned here, that > Linux is in control of DSS as a whole and the user want the other host (be it > RTOS or any other core) to control a single plane. For e.g it could be Linux > (with GPU rendering) displaying the graphics and RTOS overlaying a real time > clock or any other signs which need to be displayed in real-time. > But more than the use-case this is inspired by the fact that we want to be > flexible and support in the linux driver whatever partitioning scheme > possibilities are there which are supported in hardware and we let user decide > on the partitioning scheme. > A possible use case here could be if Linux is safer than the other host owning a single plane, right? Then in that case the RTOS could fail but the display pipeline won't be teared down. That is, if your safety tell-tales would be driven by Linux and having other OS dislay the GPU-rendered QT based application on another plane. But as said, for now that's a theorethical use case since the one you mentioned is the opposite. [....] >>> >>>> It's not just about interrupts, it's also about how your arbitrate >>>> between what Linux wants and what the RTOS wants. Like if the RTOS still >>>> wants to output something but Linux wants to disable it, how do you >>>> reconcile the two? >>>> >>> >>> The scheme involves static partitioning of display resource which are assigned >>> compile-time to RTOS and Linux. Here the RTOS firmware is compiled with >>> specific ownership/display resources as desired by user and this assignment >>> stays intact. >>> >>> If there is a more complex use-case which requires dynamic >>> assignment/arbitration of resources then I agree those require some sort of >>> IPC scheme but this is not what we target with these series. This series is >>> simply to support static partitioning feature (separate register space, >>> separate irq, firewalling support etc) of TI DSS hardware across the multiple >>> hosts and there are use-cases too for which this scheme suffices. >> >> I think you're right and we have a misunderstanding. My initial >> assumption was that it was to prevent the Linux side of sides from >> screwing up the output if it was to crash. >> >> But it looks like it's not the main point of this series, so could you >> share some use-cases you're trying to address? >> > > The end use-case we have demonstrated right now with this series is a > proof-of-concept display cluster use-case where RTOS boots early on MCU core > (launched at bootloader stage) and initializes the display (using the global > common0 register space and irq) and starts displaying safety tell-tales on one > plane, and once Linux boots up on application processor, > Linux (using common1 register space and irq) controls the other plane with GPU > rendering using a QT based application. And yes, we also support the scenario > where Linux crashes but RTOS being the DSS master and in control of DSS power, > clock domain and global register space is not impacted by the crash. You mention 2 scenarios but are actually the same? Or did I misunderstand? In both cases the RTOS own the display pipeline and Linux can just display using a single plane. That's why I think that agree with Maxime, that a fwkms could be a simpler solution to your use case instead of adding all this complexity to the DSS driver. Yes, I understand the HW supports all this flexibility but there's no real use case yet (you mentioned that don't even have firmware for this single plane owned by the RTOS in the R5F case). The DT binding for a fwkms driver would be trivial, in fact maybe we might even leverage simpledrm for this case and not require a new driver at all. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
