On Wed, Aug 27, 2014 at 05:49:53PM -0400, Ashwin Chaugule wrote: > On 27 August 2014 15:09, Mark Brown <broonie@xxxxxxxxxx> wrote: > > On Wed, Aug 27, 2014 at 09:07:15AM -0400, Ashwin Chaugule wrote: > > The messiness is orthogonal to my comment here - either it's legal to > > request a mailbox without a device or it isn't, it shouldn't depend on a > > random kernel configuration option for a particular mailbox driver which > > it is. > Fair enough. This was just to show that PCC is unfortunately not a > good candidate as a generic mailbox controller. That seems to be a very big leap... > >> "device" out of something that isn't. The PCCT, which is used as a > >> mailbox controller here, is a table and not a peripheral device. To > >> treat this as a device (without faking it by manually putting together > >> a struct device), would require adding a DSDT entry which is really a > >> wrong place for it. Are there examples today where drivers manually > >> create a struct driver and struct device and match them internally? > >> (i.e. w/o using the generic driver subsystem) > > Arguably that's what things like cpufreq end up doing, though people > > tend to just shove a device into DT. Are you sure there isn't any > > device at all in ACPI that you could hang this off, looking at my > > desktop I see rather a lot of apparently synthetic ACPI devices with > > names starting LNX including for example LNXSYSTM:00? > Those are special HIDs defined in the ACPI spec and none of those can > be used to back a device for the PCCT itself, since they're unrelated > to the PCC protocol. The PCCT is defined in the spec as a separate > table and if supported, should be visible in your system in the > PCCT.dsl file. Just for the sake of the Mailbox framework, trying to > represent the PCCT (which is a table) as a mailbox controller device, > would require registering a special HID. That in turn would make an > otherwise OS agnostic thing very Linux specific. OK, but then there's always the option of just having some code that runs on init and instantiates a device if it sees the appropriate thing in the ACPI tables in a similar manner to how HIDs are handled. It's a small amount of work but it will generally make life easier if there is a struct device. > > If PCC is described by ACPI tables how would non-ACPI users be able to > > use it? > Whoever wants to do that, would need to come up with DT bindings that > describe something similar to the PCCT contents. They could possibly > ignore the ACPI specific bits like signature, asl compiler details > etc. (which are only used by ACPI table parsers) and provide the rest > of it. Its essentially an array of structures that point to various > shared memory regions, each of which is owned by a PCC client and > shared with the firmware. The intercommunication between client and > firmware is via a doorbell, which is also described in these entries > and can be implemented as an SGI or similar. Of course most likely such a binding would involve creating a device that owns the mailboxes so this'd be fairly straightforward...
Attachment:
signature.asc
Description: Digital signature
