Messages in this thread |  | | Subject | Re: [PATCH 0/6] mailbox: arm_mhu: add support for subchannels | From | Sudeep Holla <> | Date | Fri, 5 May 2017 12:23:15 +0100 |
| |
On 05/05/17 12:12, Jassi Brar wrote: > On Wed, May 3, 2017 at 2:51 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
[...]
>> >> I don't quite get this. There are only 3 signals as you mentioned above. >> Yes there are 2^32 possible values for the register, but how can that be >> used ? >> > _Your_ protocol don't use more than 32 values, that doesn't mean other > protocols don't either. >
Please read what I quoted from the spec. "..the MHU drives the signal using a 32-bit register, with all 32 bits logically ORed together. The MHU 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 for each 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."
It is designed exactly for the above use-case. It was designed to fit PCC in ACPI which allows what I am doing with this series.
It's very similar to many PMIC drivers we have. Though set of PMIC events are bundled into single register and interrupt doesn't mean they need to be support as event. E.g. look at mc13xxx, wm831x,...etc
I am not trying to fit the changes to our use-case. I would counter argue that you did so when you push the driver. Since it's very clear for the spec that the individual bits can be accessed atomically, it was designed to be used as doorbell and not as a message carrier register. I am fine if it can be used in that way but don't disagree to support the use-case for which it was designed.
-- Regards, Sudeep
|  |