Message-ID: <vqije2t5ckhvquisgioidjhjfc7km7ro5yqfavdx5y3hy4rzgj@w35xlablr2by>
Date: Wed, 17 Dec 2025 22:26:18 -0600
From: Bjorn Andersson <andersson@...nel.org>
To: Sricharan Ramabadhran <quic_srichara@...cinc.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, jassisinghbrar@...il.com, 
	robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org, 
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, 
	konradybcio@...nel.org, manivannan.sadhasivam@...aro.org, dmitry.baryshkov@...aro.org
Subject: Re: [PATCH V4 1/2] dt-bindings: mailbox: Document qcom,ipq5424-tmel

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@...cinc.com/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

Powered by blists - more mailing lists