On 11 November 2014 18:32, Ashwin Chaugule <ashwin.chaugule@xxxxxxxxxx> wrote: > On 10 November 2014 23:04, Jassi Brar <jaswinder.singh@xxxxxxxxxx> wrote: > >> I don't mean that by 'bad design'. >> Ashwin asked what if a client wants the channel from, say, second >> instance of PCC instead of first (both are same controllers because >> they check for same signature). > > 2 channels from 2 "different" controllers. e.g. Non-PCC controllers, > which don't have a "subspace" signature field like PCC does. > OK, even that I think I explained already, but here it goes again ... For Mailbox framework, there already has be some direct understanding between the client and controller driver. For ex, the controller defines the format of the payload packet and the client simply provides the pointer, to payload in SharedMemory, as "data" to mailbox api to be transmitted. This packet structure will usually be defined in a header common to client and controller driver. [I almost feel embarrassed to repeat this common rant] Just like payload format, the 'signature' will also be declared by controller and used by clients. For PCC controller, we conveniently use the signature (0x50434300 | Type) defined by the ACPI (we could chose some other coding as well). Another controller of a different class will choose a different signature, say (0xdead0000 | 16bitsCode).... much like we take care while defining a new DT binding that the 'compatible' string doesn't collide with that of another device. Since we don't have DT bindings to map clients onto controller:channel, the client will have to convey the controller:channel information itself... which will be 0x50434301 for HW-Reduced-Comm(type-1) channel of PCC(0x50434300). So the responsibility lies with the client to specify correct signature while requesting a channel. There is nothing to stop a client from specifying a wrong signature, just like there is nothing to stop it from executing BUG() In even simpler terms.... I prefer controller specific encoding(0x50434300) instead of controller specific api (pcc_mbox_request_channel). For a different class of controller, it is much cleaner to define a new encoding as compared to another xyz_mbox_request_channel() api. >> >>> From an ACPI point of view the context is the fact >>> that this is a PCC channel (there's a globally unique namespace for PCC >>> channels) but Linux wants a struct device for the client to represent >>> the context with a mapping table of some kind behind that to do the >>> lookup. >>> >>> There's nothing in the ACPI description of the channel or controller to >>> tie it to the client device, and there's nothing preventing some other >>> mailbox mechanism that gets added to an ACPI system from reusing similar >>> names (bear in mind that idiomatic naming for ACPI appears to be three >>> or four character strings). If we have a PCC channel "FOO" and some new >>> mailbox type which also defines "FOO" the controllers aren't really >>> going to be able to tell them apart just on the string. >>> >> ACPI does specify a PCC specific signature (0x50434300) for its >> channels. Any channel is identified by doing OR of that signature and >> the index of channel/subspace in the array of 256. > > This is true only for PCC. Another class of controllers may not even > have such a signature. The only thing you can be sure of is that they > will have the 4 letter table identifier string e.g. PCCT. > As I said, the PCC controller driver chooses to use ACPI defined signature. Likewise a different class controller may take some value from its specification or simply use random unique value... whatever suits it. -Jassi -- 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
