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

[Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>]

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@quicinc.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
>