On Thu, Apr 2, 2015 at 2:07 AM, Mika Westerberg
<mika.westerberg@xxxxxxxxxxxxxxx> wrote:
> On Wed, Apr 01, 2015 at 10:01:45AM -0700, Feng Kan wrote:
>> On Wed, Apr 1, 2015 at 12:45 AM, Mika Westerberg
>> <mika.westerberg@xxxxxxxxxxxxxxx> wrote:
>> > On Tue, Mar 31, 2015 at 02:18:00PM -0700, Feng Kan wrote:
>> >> This will add support for ACPI parsing of the mboxes attribute
>> >> when booting with ACPI table. The client will have a attribute
>> >> mimic the dts call "mboxes". In the ACPI case, the client will
>> >> mark "mboxes" with the ACPI HID of the mbox it wishes to use.
>> >>
>> >> Name (_DSD, Package () {
>> >> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> >> Package () {
>> >> Package (2) {"mboxes", "ACPIHID"},
>> >> }
>> >> })
>> >
>> > Instead of this, why not match against the DT compatible property?
>> >
>> > Name (_HID, "PRP0001")
>> >
>> > Name (_DSD, Package () {
>> > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> > Package () {
>> > Package (2) {"compatible", "your-dt-compatible-string"},
>> > }
>> > })
>> I think my description was not clear enough. The _DSD section is not
>> meant to identify the mailbox driver, but used by the acpi node that will
>> request the mailbox channel. The dts version would be as below.
>>
>> mailbox: {
>> }
>>
>> user-mbox: {
>> mboxes: <&mailbox 0>
>> }
>>
>> The mboxes attribute in the user of the mbox has to specify the HID of the
>> mbox in order to retrieve channel pointer.
>
> Okay, then I think you can use reference instead of _HID, like
>
> // The mailbox device
> Device (MLBX) {
> }
>
> // User-mbox device
> Device (USBX) {
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {"mboxes", Package () {^^MLBX, 0}}),
> }
> })
> }
Thanks, will try this. A side question on your previous reply. Would you
prefer a new driver using the PRP0001 or an actual proper HID.
--
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
