On Tue, 2024-01-16 at 17:22 +0000, Conor Dooley wrote: > On Tue, Jan 16, 2024 at 08:21:15AM +0000, Jason-JH Lin (林睿祥) wrote: > > On Mon, 2024-01-15 at 17:23 +0000, Conor Dooley wrote: > > > On Fri, Jan 12, 2024 at 07:44:13AM +0000, Jason-JH Lin (林睿祥) > > > wrote: > > > > On Thu, 2024-01-11 at 17:31 +0000, Conor Dooley wrote: > > > > > On Wed, Jan 10, 2024 at 04:36:20PM +0000, Jason-JH Lin (林睿祥) > > > > > > 2. We'll have the secure CMDQ mailbox driver in the future > > > > > > patch > > > > > > [1]. > > > > > > It will request or reserve a mailbox channel, which is a > > > > > > dedicate > > > > > > GCE > > > > > > thread, as a secure IRQ handler. This GCE thread executes a > > > > > > looping > > > > > > instruction set that keeps waiting for the gce-event set > > > > > > from > > > > > > another > > > > > > GCE thread in the secure world. So we also need to tell the > > > > > > CMDQ > > > > > > driver > > > > > > what gce-event need to be waited. > > > > > > > > > > Ditto here, what level does this vary at? Do different SoCs > > > > > or > > > > > different > > > > > boards/platforms dictate the value? > > > > > > > > It's a SoC level, the SoC supports secure feature will need > > > > this > > > > property. > > > > > > > > > Could this channel be determined from the soc-specific > > > > > compatible? > > > > > > > > > > In other words, please explain in your commit message why > > > > > this > > > > > requires > > > > > a property and is not detectable from any existing mechanism. > > > > > From > > > > > reading this I don't know what is preventing the secure > > > > > mailbox > > > > > channel > > > > > from picking a "random" unused channel. > > > > > > > > The secure channel could be dedicated from the soc-specific > > > > compatible, > > > > but the event ID couldn't. > > > > > > > > The same event signal corresponding event ID may changes in > > > > different > > > > SoC. > > > > E.g. > > > > The HW event signal for CMDQ_EVENT_VDO0_MUTEX_STREAM_DONE_0 is > > > > corresponding to GCE event ID: 574 in MT8188, but it's > > > > corresponding to > > > > eventID: 597 in MT8195. > > > > > > Is it always 574 in MT8188 and always 597 in MT8195? > > > > > > > Yes, some gce-events are hardware bound and they can not change by > > software. For example, in MT8195, when VDO0_MUTEX is stream done, > > VDO_MUTEX will send an event signal to GCE, and the value of event > > ID:597 will be set to 1. In MT8188, the value of event ID: 574 will > > be > > set to 1 when VOD0_MUTEX is stream done. > > > > Some of gce-events are not hardware bound and they can change by > > software. For example, in MT8188, we can take the event ID: 855 > > that is > > not bound to any hardware to set its value to 1 when the driver in > > secure world completes a task. But in MT8195, the event ID: 855 is > > already bound to VDEC_LAT1, so we have to take another event ID to > > achieve the same purpose. > > This event ID can be change to any IDs that is not bound to any > > hardware > > and is not used in any software driver yet. > > We can see if the event ID is bound to the hardware or is used by > > software driver in the header > > include/de-bindings/mailbox/mediatek,mt8188-gce.h. > > I see. Bring this particular patch back with your future series that > adds support for the secure channel then. > OK, I'll move this particular patch to the future secure series that adds support for the secure channel. Thanks! Regards, Jason-JH.Lin > Thanks, > Conor.
