<html><body><p>
<pre>
On Tue, 2024-05-28 at 15:59 +0100, Conor Dooley wrote:
> On Tue, May 28, 2024 at 02:38:46PM +0000, Jason-JH Lin (林睿祥) wrote:
> > Hi Conor,
> >
> > On Mon, 2024-05-27 at 18:36 +0100, Conor Dooley wrote:
> > > On Sun, May 26, 2024 at 10:44:37PM +0800, Jason-JH.Lin wrote:
> > > > 1. Add mboxes property to define a GCE loopping thread as a
> > > > secure
> > > > IRQ
> > > > handler.
> > > > The CMDQ secure driver requests a mbox channel and sends a
> > > > looping
> > > > command to the GCE thread. The looping command will wait for a
> > > > secure
> > > > packet done event signal from secure world and then jump back
> > > > to
> > > > the
> > > > first instuction. Each time it waits for an event, it notifies
> > > > the
> > > > CMDQ driver to perform the same action as the IRQ handler.
> > > >
> > > > 2. Add gce-events property from gce-props.yaml to define a
> > > > secure packet done signal in secure world.
> > > > There are 1024 events IDs for GCE to use to execute
> > > > instructions in
> > > > the specific event happened. These events could be signaled by
> > > > HW
> > > > or SW
> > > > and their value would be different in different SoC because of
> > > > HW
> > > > event
> > > > IDs distribution range from 0 to 1023.
> > > > If we set a static event ID: 855 for mt8188, it might be
> > > > conflict
> > > > the
> > > > event ID original set in mt8195.
> > >
> > > Two different SoCs, two different compatibles, no problem.
> > > I'm almost certain you previously told me that the firmware
> > > changing
> > > could result in a different event ID, but I see no mention of
> > > that
> > > here.
> >
> > Yes, it could be, but we don't use it that way.
> >
> > > The commit messages makes it seem like this can be determined by
> > > the
> > > compatible, so either give me a commit message that explains why
> > > the
> > > compatible is not sufficient or drop the patch.
> > >
> >
> > Yes, this can be determined by compatible in CMDQ mailbox driver,
> > so I think it's possible to put this in the CMDQ mailbox driver
> > data
> > and configure by different SoC.
> >
> > The problem is these events are defined in include/dt-
> > bindings/mailbox/mediatek,mt8188-gce.h and include/dt-
> > bindings/gce/mt8195-gce.h.
> > I can only use them in their mt8188.dts or mt8195.dts.
> >
> > If I want to use the same event define in 2 different headers in
> > the
> > same CMDQ mailbox driver, I think I just can parse their dts to get
> > the
> > corresponding one.
> > Do you know how to generally deal with this problem?
> > Or I can just use the number of event ID in driver data without the
> > event define in dt-bindings header.
>
> I don't think I really understand the problem. You get the
> channelid/event data from the match data, right? Is the problem that
> both files define the same "word" to mean different numbers?

Yes, I mean the same "event define" with different event ID numbers in
different SoC headers.

> In that
> case, just define the numbers locally in the driver, you don't need
> to
> include a binding header when there's no data sharing between dts and
> kernel.

OK, I'll do that and drop this patch.
Thanks~

Regards,
Jason-JH.Lin


</pre>
</p></body></html><!--type:text--><!--{--><pre>************* MEDIATEK Confidentiality Notice ********************
The information contained in this e-mail message (including any 
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be 
conveyed only to the designated recipient(s). Any use, dissemination, 
distribution, printing, retaining or copying of this e-mail (including its 
attachments) by unintended recipient(s) is strictly prohibited and may 
be unlawful. If you are not an intended recipient of this e-mail, or believe 
that you have received this e-mail in error, please notify the sender 
immediately (by replying to this e-mail), delete any and all copies of 
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!
</pre><!--}-->