On Tuesday 02 September 2014 14:16:42 Ashwin Chaugule wrote: > On 28 August 2014 16:34, Ashwin Chaugule <ashwin.chaugule@xxxxxxxxxx> wrote: > > On 28 August 2014 06:15, Mark Brown <broonie@xxxxxxxxxx> wrote: > >> On Thu, Aug 28, 2014 at 10:39:01AM +0200, Arnd Bergmann wrote: > >>> On Wednesday 27 August 2014 20:09:02 Mark Brown wrote: > >> > >>> > That certainly looks like what it's doing. Probably also make the name > >>> > that gets passed in const while you're at it. > >> > >>> The mailbox API intentionally does not have an interface for > >>> that: you are supposed to get a reference to an mbox controller > >>> from a phandle or similar, not by knowing the name of the controller. > >> > >> Right, and what he's trying to work around here is that ACPI has chosen > >> to provide a generic binding for some mailboxes which isn't associated > >> with anything we represent as a device and he doesn't want to provide > >> that device as a Linux virtual thing. > > > > Just the idea of a table as a device, when it doesn't do any power > > management, hotplug or anything like a device seemed strange. But I'm > > open to ideas if we find a good solution. Its highly possible that I'm > > not seeing it the way you are because the driver subsystem internals > > are fairly new to me. > > > > 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. > > 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. Using platform_data would no be helpful, because there is no platform code to fill that out on ACPI based systems. > >>> Unfortunately, the three patches that Ashwin posted don't have a > >>> caller for this function, so I don't know what it's actually used for. > >>> Why do we need this function for pcc, and what are the names that > >>> can be passed here? > >> > >> AFAICT the names he's interested in will be defined by the ACPI specs. > >> It does seem like we should be providing a device for the controller and > >> then either using references in ACPI to look it up if they exist or a > >> lookup function for this particular namespace that goes and fetches the > >> device we created and looks up in its context. > > > > What is the comparison in this lookup function? A string or a struct > > device pointer? If it is the latter, how does the client get the > > reference to the controller struct device? One way would be to > > register the PCCT as a platform_device and the PCC client as its > > platform_driver. But I think that will restrict the number of PCC > > clients to who ever matches first. I suspect this is not what you're > > implying, so I'd appreciate some more help. > > I dont see a way to create a lookup table for PCC without storing the > name of the controller somewhere. The suggestion of creating a > platform device for the controller and client led to restricting only > one client to the controller. Can you please suggest how to move this > forward? I've forgotten the details, but I thought we had already worked it out when we discussed it the last time. What is the information available to the client driver? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
