On 10/16/24 08:31, Krzysztof Kozlowski wrote:
> On 16/10/2024 01:14, Samuel Holland wrote:
>>> + reg-names:
>>> + items:
>>> + - const: local
>>> + - const: remote-icu0
>>> + - const: remote-icu1
>>> + - const: remote-icu2
>>> +
>>> + interrupts:
>>> + maxItems: 1
>>> +
>>> + '#mbox-cells':
>>> + const: 2
>>> + description: |
>>> + Specifies the number of cells needed to encode the mailbox specifier.
>>> + The mailbox specifier consists of two cells:
>>> + - Destination CPU ID.
>>> + - Type, which can be one of the following:
>>> + - 0:
>>> + - TX & RX channels share the same channel.
>>> + - Equipped with 7 info registers to facilitate data sharing.
>>> + - Supports IRQ for signaling.
>>> + - 1:
>>> + - TX & RX operate as doorbell channels.
>>> + - Does not have dedicated info registers.
>>> + - Lacks ACK support.
>>
>> It appears that these types are not describing hardware, but the protocol used
>> by the Linux driver to glue two unidirectional hardware channels together to
>> make a virtual bidirectional channel. This is really the responsibility of the
>> mailbox client to know what protocol it needs, not the devicetree.
>>
>
> Hm, where is the DTS with consumers of this mailbox provider?
The DTS with consumers of this mailbox provider is not included in this
series. Since the mailbox users depend on this driver being upstreamed,
I decided to submit this driver first to gather feedback on whether it
can be accepted upstream. If successful, I will follow up with another
series for the aon driver, which will use this mailbox to send commands
to the E902 core, such as powering the GPU on or off.
The consumer DTS would look something like this:
aon: aon {
compatible = "thead,th1520-aon";
mbox-names = "aon";
mboxes = <&mbox_910t 1 0>;
status = "okay";
pd: light-aon-pd {
compatible = "thead,light-aon-pd";
#power-domain-cells = <1>;
};
};
Thanks,
Michał
>
> Best regards,
> Krzysztof
>
>
