On 2017-04-25 14:30, Mika Westerberg wrote:
> 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.
>
Ah, now I recall: I think we discussed this before, but for a case were
we would need to patch an existing element that contains one wrong value
- that won't work. This case should, though. I'll give that a try.
Thanks,
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
