Messages in this thread | | | Date | Thu, 14 May 2015 09:25:24 +0100 | From | Sudeep Holla <> | Subject | Re: [PATCH 1/4] mailbox: add support for System Control and Power Interface(SCPI) protocol |
| |
On 14/05/15 08:30, Jassi Brar wrote: > On Thu, May 14, 2015 at 12:32 PM, Jassi Brar <jassisinghbrar@gmail.com> wrote: >> >> BTW is scpi_protocol.c meant/tested to work over arm_mhu.c? The spec >> says so but I don't see how because you pass 'struct scpi_xfer*' as >> the message whereas arm_mhu.c expects u32* >>
Yes it's tested using arm_mhu.c, and I have even sent updates to the binding that's incomplete as of now and *must* be pulled into v4.1. Please make sure it gets in. Otherwise clocks are optional but the driver fails to probe without that. I was initially wondering why the MHU probe is not called.
scpi_xfer has the slot as first element which will have the right doorbell bit(in this case slot#0) set always.
> It seems your remote doesn't interpret the value in STAT register... > so it just works.
Not exactly. If you look at Figure 2-1 in the spec, it shows how STAT (along with SET/CLEAR) is used to identify the protocol. The remote can implement multiple protocol. E.g. SCPI(on Slot#0 - main topic of this series), ACPI(PCC/CPPC say on Slot#1), ABC(on Slot#X)...etc.
> However the SCPI spec recommends seeing STAT register as '31 slots' > ... maybe we should try to support that. >
Correct but only Slot#0 is used for SCPI.
Regards, Sudeep
| |