On Tue, Apr 25, 2017 at 02:17:23PM +0200, Jan Kiszka wrote:
> I'm not ACPI guru: How do we come from a SSDT to information that is
> carried in the DSDT so far? How can we overload wrong information in the
> built in DSDT this way? I'm all ears if we could fix our (and also the
> Galileo) quirks like that!
SSDT stands for Secondary System Description table which basically adds
stuff to DSDT (the main table). Main use for SSDTs is to add devices but
you can also amend an existing device in DSDT by adding methods and so
forth.
In case of Galileo the SPI1 host controller happens to miss _CRS method
so we can use SSDT like below to add that method there:
Scope (\_SB.PCI0.SPI1)
{
Name (_CRS, ResourceTemplate () {
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
"\\_SB.PCI0.GIP0.GPO", 0) {2} // MUX6_IO
})
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {
"cs-gpios", Package () {^SPI1, 0, 0, 0},
},
}
})
}
This effectively means that once the table is parsed we find the SPI1
device with two new methods, _CRS and _DSD and the kernel is happy to
handle the rest.
Important thing here is the
Scope (\_SB.PCI0.SPI1)
which allows us to reference an object in DSDT.
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
