Hi Arnd,
On 2 September 2014 15:22, Arnd Bergmann arnd@arndb.de wrote:
Suppose we create a platform_device for the PCCT (mailbox controller) and another one for the PCC client (mailbox client). How should the PCC client(s) identify the mailbox controller without passing a name? In DT, the "mboxes" field in the client DT entry is all strings with mailbox controller names.
No, it's not a string at all, it's a phandle, which is more like a pointer. We intentionally never match by a global string at all, because those might not be unique.
Ok. With PCC, I dont see a way to do this sort of pointer matching.
The "index" in mbox_request_channel() picks up one set of strings. How should this work with PCC? Should we use the PCC client platform_device->dev->platform_data to store mailbox controller strings?
I didn't think there was more than one PCC provider, why do you even need a string?
For the general case in ACPI, there should be a similar way of looking up mailbox providers to what we have in DT, but if I understand you correctly, the PCC specification does not allow that.
Right. At least not in a way DT does. PCC clients know if something needs to be written/read via PCC mailbox and can identify a PCC subspace. (i.e. Mailbox channel). The PCC mailbox is uniquely identified/defined in the spec.
#define ACPI_ADR_SPACE_PLATFORM_COMM (acpi_adr_space_type) 10
So we could use this ID instead of a string and use that to look up the PCC controller for a PCC client.
Using platform_data would no be helpful, because there is no platform code to fill that out on ACPI based systems.
Right. So the question is how do we work around the "mbox->dev" and "client->dev" expectations in the Mailbox framework for PCC, given that these tables aren't backed by "struct devices" ?
Thanks, Ashwin