Re: [PATCH 2/6] Documentation: devicetree: add bindings to support ARM MHU subchannels

[Sudeep Holla <sudeep.holla@arm.com>]

On 08/05/17 17:10, Rob Herring wrote:
> +Bjorn
> 
> On Tue, May 02, 2017 at 02:55:49PM +0100, Sudeep Holla wrote:
>> The ARM MHU has mechanism to assert interrupt signals to facilitate
>> inter-processor message based communication. It drives the signal using
>> a 32-bit register, with all 32-bits logically ORed together. It also
>> enables software to set, clear and check the status of each of the bits
>> of this register independently. Each bit of the register can be
>> associated with a type of event that can contribute to raising the
>> interrupt thereby allowing it to be used as independent subchannels.
>>
>> Since the first version of this binding can't support sub-channels,
>> this patch extends the existing binding to support them.
>>
>> Cc: Alexey Klimov <alexey.klimov@arm.com>
>> Cc: Jassi Brar <jaswinder.singh@linaro.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: devicetree@vger.kernel.org
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>>  .../devicetree/bindings/mailbox/arm-mhu.txt        | 44 ++++++++++++++++++++--
>>  1 file changed, 41 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mailbox/arm-mhu.txt b/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
>> index 4971f03f0b33..86a66f7918e2 100644
>> --- a/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
>> +++ b/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
>> @@ -10,21 +10,40 @@ STAT register and the remote clears it after having read the data.
>>  The last channel is specified to be a 'Secure' resource, hence can't be
>>  used by Linux running NS.
>>  
>> +The MHU drives the interrupt signal using a 32-bit register, with all
>> +32-bits logically ORed together. It provides a set of registers to
>> +enable software to set, clear and check the status of each of the bits
>> +of this register independently. The use of 32 bits per interrupt line
>> +enables software to provide more information about the source of the
>> +interrupt. For example, each bit of the register can be associated with
>> +a type of event that can contribute to raising the interrupt.
> 
> Sounds like a doorbell? (i.e. a single bit mailbox). Bjorn is doing 
> something similar for QCom h/w. I guess the difference here is you have 
> 32 sources and 1 output. It seems to me these should be described 
> similarly.
> 

Indeed single bit doorbell, but 32 of them joined together.
OK, I will have a look at that Bjorn series.

>> +
>>  Mailbox Device Node:
>>  ====================
>>  
>>  Required properties:
>>  --------------------
>> -- compatible:		Shall be "arm,mhu" & "arm,primecell"
>> +- compatible:		Shall be "arm,primecell" and one of the below:
>> +			"arm,mhu" - if the controller doesn't support
>> +				    subchannels
>> +			"arm,mhu-v2" - if the controller supports subchannels
> 
> How do I know if I have v2? This correlates to an IP version or 
> IP configuration or ?
> 

No, it's the same IP, just that initial binding was pushed not to
support the single bit doorbell functionality of the IP. Jassi was/is
against that. I have just quoted the specification above.

-- 
Regards,
Sudeep