Hi Andy,
I spent some time studying/reading what you wrote, but I still don't
understand how to leverage meta-acpi.
>From what I understand from the following discussion in the thread,
ADS5593 could be used,
so we can keep using it and don't have to introduce PRP0001 in the table, right?
Here is the ADS5593 asl code, but I have no idea how to re-use it
after it's been modified,
the only way I know is to override the ACPI tables via initrd[1].
Could you share some examples in real cases that I can follow?
Thanks.
1. Documentation/admin-guide/acpi/initrd_table_override.rst
Andy Shevchenko <andy.shevchenko@xxxxxxxxx> 於 2020年8月31日 週一 下午8:48寫道：
>
> On Mon, Aug 31, 2020 at 3:45 PM Andy Shevchenko
> <andy.shevchenko@xxxxxxxxx> wrote:
> > On Mon, Aug 31, 2020 at 2:28 PM AceLan Kao <acelan.kao@xxxxxxxxxxxxx> wrote:
> > > This patch is mainly for Advantech's UNO-420[1] which is a x86-based platform.
> > > This platform is more like a development platform for customers to
> > > customize their products,
> > > so, specify the channel modes in ACPI table is not generic enough,
> > > that's why William submit this patch.
> > >
> > > Are there other ways to specify or pass values to the module without
> > > using module parameters?
> > > It's good if we can leverage sysfs, but I don't know if there is one
> > > for this scenario.
> >
> > Can we provide DT bindings for that and use then in ACPI? ACPI has a
> > possibility to reuse DT properties and compatible strings [1]. As far
> > as I can see the driver uses fwnode API, so it supports ACPI case
> > already [2]. So, what prevents you to utilize 'adi,mode' property?
> >
> > Also, we accept examples of ASL excerpt in meta-acpi project [3]. It
> > has already plenty of examples [4] how to use PRP0001 for DIY /
> > development boards.
> >
> > So, take all together I think this patch is simple redundant.
>
> One more useful link is SO answers on the topic:
> https://stackoverflow.com/search?tab=newest&q=prp0001
>
> > [1]: https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id
> > [2]: https://elixir.bootlin.com/linux/v5.9-rc3/source/Documentation/devicetree/bindings/iio/dac/ad5592r.txt
> > [3]: https://github.com/westeri/meta-acpi
> > [4]: https://github.com/westeri/meta-acpi/tree/master/recipes-bsp/acpi-tables/samples
> >
> > P.S. Jonathan, it seems this driver has artificial ACPI HID. We
> > probably have to remove it. However, ADS is indeed reserved for Analog
> > Devices in PNP registry. Can we have AD's official answer on this?
> > Cc'ing additional AD people.
> >
> > > 1. https://www.advantech.com/products/9a0cc561-8fc2-4e22-969c-9df90a3952b5/uno-420/mod_2d6a546b-39e3-4bc4-bbf4-ac89e6b7667c
>
> --
> With Best Regards,
> Andy Shevchenko
Scope (_SB.I2C1)
{
Device (I2CG)
{
Name (_HID, "ADS5593") // _HID: Hardware ID
Device (IOP0)
{
Name (_ADR, Zero) // _ADR: Address
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x03)
{
Package (0x02)
{
"reg",
Zero
},
Package (0x02)
{
"adi,mode",
0x08
},
Package (0x02)
{
"adi,off-state",
Zero
}
}
})
}
Device (IOP1)
{
Name (_ADR, Zero) // _ADR: Address
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x03)
{
Package (0x02)
{
"reg",
One
},
Package (0x02)
{
"adi,mode",
0x03
},
Package (0x02)
{
"adi,off-state",
Zero
}
}
})
}
Device (IOP2)
{
Name (_ADR, 0x02) // _ADR: Address
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x03)
{
Package (0x02)
{
"reg",
0x02
},
Package (0x02)
{
"adi,mode",
0x02
},
Package (0x02)
{
"adi,off-state",
Zero
}
}
})
}
Device (IOP3)
{
Name (_ADR, 0x03) // _ADR: Address
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x03)
{
Package (0x02)
{
"reg",
0x03
},
Package (0x02)
{
"adi,mode",
One
},
Package (0x02)
{
"adi,off-state",
Zero
}
}
})
}
Device (IOP4)
{
Name (_ADR, 0x04) // _ADR: Address
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x03)
{
Package (0x02)
{
"reg",
0x04
},
Package (0x02)
{
"adi,mode",
0x08
},
Package (0x02)
{
"adi,off-state",
Zero
}
}
})
}
Device (IOP5)
{
Name (_ADR, 0x05) // _ADR: Address
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x03)
{
Package (0x02)
{
"reg",
0x05
},
Package (0x02)
{
"adi,mode",
0x03
},
Package (0x02)
{
"adi,off-state",
Zero
}
}
})
}
Device (IOP6)
{
Name (_ADR, 0x06) // _ADR: Address
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x03)
{
Package (0x02)
{
"reg",
0x06
},
Package (0x02)
{
"adi,mode",
0x02
},
Package (0x02)
{
"adi,off-state",
Zero
}
}
})
}
Device (IOP7)
{
Name (_ADR, 0x07) // _ADR: Address
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x03)
{
Package (0x02)
{
"reg",
0x07
},
Package (0x02)
{
"adi,mode",
One
},
Package (0x02)
{
"adi,off-state",
Zero
}
}
})
}
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (RBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0010, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.D022",
0x00, ResourceConsumer, , Exclusive,
)
})
Return (RBUF) /* \_SB_.I2C1.I2CG._CRS.RBUF */
}
}
}
