Hi Mark, On 28 August 2014 06:10, Mark Brown <broonie@xxxxxxxxxx> wrote: > 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: >> >> "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 -- 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
