Hi Mark,
On 28 August 2014 06:10, Mark Brown broonie@kernel.org wrote:
On Wed, Aug 27, 2014 at 05:49:53PM -0400, Ashwin Chaugule wrote:
On 27 August 2014 15:09, Mark Brown broonie@kernel.org wrote:
On Wed, Aug 27, 2014 at 09:07:15AM -0400, Ashwin Chaugule wrote:
"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.
I need to give this a try. AFAICS, the HIDs get their device created by the driver subsystem. This would require manually creating one and I didn't see existing examples. Thinking of a table as a device (virtual/real) seemed weird to me, especially since we're seemingly only using it for ref counts here. But it sounds like this is an acceptable thing.
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...
With DT, yes, it seems to be a bit more straightforward.
Thanks, Ashwin