Re: [PATCH V4 1/2] dt-bindings: mailbox: Document qcom,ipq5424-tmel

[Kathiravan Thirumoorthy]

On 12/18/2025 9:56 AM, Bjorn Andersson wrote:

Thanks Bjorn for the comments. I will be taking over this series since 
Sricharan is moved to other team. I will review and get back to your 
comments post new year vacation. Thanks.

> On Tue, Apr 15, 2025 at 04:38:44PM +0530, Sricharan Ramabadhran wrote:
> > On 4/1/2025 12:59 PM, Sricharan Ramabadhran wrote:
> > > On 3/28/2025 1:32 PM, Krzysztof Kozlowski wrote:
> > > > On Thu, Mar 27, 2025 at 11:47:49PM +0530, Sricharan R wrote:
> > > > > +properties:
> > > > > +  compatible:
> > > > > +    items:
> > > > > +      - enum:
> > > > > +          - qcom,ipq5424-tmel
> > > > blank line
> > > ok
> > >
> > > > > +  reg:
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  interrupts:
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  mboxes:
> > > > > +    maxItems: 1
> > > > Why mbox is having an mbox? This does not look right and suggest the
> > > > block is misrepresented. I read the diagram and description two times
> > > > and still do not see how this fits there.
> > > TMEL/QMP secure functionalities are exposed to clients (like rproc) by
> > > registering TMEL as mailbox controller. The IPC bit to communicate with
> > > the TMEL/QMP controller itself is handled by the apcs mailbox. Hence
> > > it looks like a mbox inside mbox.
> > >
> > > Alternatively, would it be fine to fold the IPC bit handling in this
> > > driver itself for doing the regmap_write (instead of connecting to
> > > apcs mailbox separately) ?
> The APCS provides the interface for triggering interrupts on the remote
> processors, and mailbox with NULL messages is how we expose this to the
> clients. On some platforms this mechanism is exposed in the form of IPCC
> instead, i.e. another mailbox provider.
>
> It might not be a mailbox, but it's the closest thing we had and it's
> what we use everywhere else.
>
> > > Also, there are couple of other ways of designing this as well.
> > > Earlier i mentioned this in the RFC post [1] for getting the design
> > > sorted out.
> > >
> > > [1] https://lore.kernel.org/lkml/20241205080633.2623142-1-
> > > quic_srichara@xxxxxxxxxxx/T/
> > >
> > > -------------------------------------------------------------
> > > Had the below mentioned in the RFC earlier.
> > >
> > > The intention of posting this is to get the design reviewed/corrected
> > > since there are also other possible ways of having this SS support like:
> > >
> > > a) Make TMEL QMP as a 'rpmsg' driver and clients can connect using
> > >      rmpsg_send
> > >
> > > b) Keep TMEL APIs seperately in drivers/firmware which would export APIs
> > >      and QMP mailbox seperately.
> > >      Clients can then call the exported APIS.
> > >
> > > c) Combine both TMEL and QMP as mailbox (this is the approach used here)
> > Hi Krysztof,
> >
> > Can you kindly provide your suggestion on how to proceed for the above ?
> > Would want to align on the design approach before posting the next
> > version.
> How does the TME QMP interface differ from the QMP implementation in
> drivers/qcom/qcom_aoss.c?
>
> In the AOSS QMP case we determined that there was no benefit to
> abstracting this interface through the mailbox API - and a _hardware_
> mailbox doesn't take variable length strings as input...
>
>
> The concept of posting variable length messages onto a communication
> channel resembles rpmsg, but at least the AOSS QMP is a single-channel
> mechanism and there's no mapping to "rpmsg clients" in this model.
>
> Will the TMEL QMP interface be used by anything but the TMEL driver? Why
> should the TMEL and QMP drivers be separated?
>
> Why is the mailbox API the proper abstraction of the TMEL interface?
>
> Regards,
> Bjorn