Re: [PATCH v3 1/3] Mailbox: Add support for PCC mailbox and channels

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3116 bytes --]

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:

> > 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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]