On Tue, Oct 27, 2015 at 12:30:31PM +0000, Shevchenko, Andriy wrote:
> On Mon, 2015-10-26 at 08:51 +0000, Zha, Qipeng wrote:
> > > So the ASL you provided was not what the Linux kernel is seeing,
> > > correct?
> >
> > > Can you please provide a DSDT disassembly from the running Linux
> > > system please, such as:
> >
> > > # cp /sys/firmware/acpi/tables/DSDT DSDT.dat # iasl -d DSDT.dat
> >
> > > Then find this device in DSDT.dsl and paste it here please.
> >
> > Sorry for late feedback, got dsdt from lab machine since my board
> > got broken,
> > Please check.
> >
> > Scope (\_SB)
> > {
> > Device (IPC1)
> > {
> > Name (_ADR, Zero) // _ADR: Address
> > Name (_HID, "INT34D2") // _HID: Hardware ID
> > Name (_CID, "INT34D2") // _CID: Compatible ID
> > Name (_DDN, "Intel(R) IPCI controller ") // _DDN:
> > DOS Device Name
> > Name (_UID, One) // _UID: Unique ID
> > Name (RBUF, ResourceTemplate ()
> > {
> > Memory32Fixed (ReadWrite,
> > 0x00000000, // Address Base
> > 0x00002000, // Address Length
> > _Y08)
> > Memory32Fixed (ReadWrite,
> > 0x00000000, // Address Base
> > 0x00000004, // Address Length
> > _Y09)
> > Memory32Fixed (ReadWrite,
> > 0x00000000, // Address Base
> > 0x00000040, // Address Length
> > _Y0A)
> > IO (Decode16,
> > 0x0400, // Range Minimum
> > 0x0480, // Range Maximum
> > 0x04, // Alignment
> > 0x80, // Length
> > )
> > Memory32Fixed (ReadWrite,
> > 0x00000000, // Address Base
> > 0x00002000, // Address Length
> > _Y0B)
> > Interrupt (ResourceConsumer, Level, ActiveLow,
> > Exclusive, ,, )
> > {
> > 0x00000028,
> > }
> > })
> > Method (_CRS, 0, NotSerialized) // _CRS: Current
> > Resource Settings
> > {
> > CreateDWordField (RBUF, \_SB.IPC1._Y08._BAS,
> > B0BA) // _BAS: Base Address
> > CreateDWordField (RBUF, \_SB.IPC1._Y08._LEN,
> > B0LN) // _LEN: Length
> > Store (DD1A, B0BA)
> > Store (DD1L, B0LN)
>
> dd1a, dd1l has been stored to Resource 0
>
> > CreateDWordField (RBUF, \_SB.IPC1._Y09._BAS,
> > BM01) // _BAS: Base Address
> > CreateDWordField (RBUF, \_SB.IPC1._Y09._LEN,
> > BML1) // _LEN: Length
> > CreateDWordField (RBUF, \_SB.IPC1._Y0A._BAS,
> > BM02) // _BAS: Base Address
> > CreateDWordField (RBUF, \_SB.IPC1._Y0A._LEN,
> > BML2) // _LEN: Length
> > Store (BMDA, BM01)
> > Store (0x04, BML1)
> > Store (BMIA, BM02)
> > Store (0x40, BML2)
>
> bmda, 0x04 -> Resource 1
> bmia, 0x40 -> Resource 2
>
> > CreateDWordField (RBUF, \_SB.IPC1._Y0B._BAS,
> > B1BA) // _BAS: Base Address
> > CreateDWordField (RBUF, \_SB.IPC1._Y0B._LEN,
> > B1LN) // _LEN: Length
> > Store (DD3A, B1BA)
> > Store (DD3L, B1LN)
>
> dd3a, dd3l -> Resource 3
>
>
> Can you create a temporary method in the ->probe() of this driver to
> iterate over resources and print them out? Or tell the values BIOS set
> per values dd1a, dd1l, dd3a, dd3l, bmda, bmia.
>
> AFAIU you are using only resources 0 and 1. Can you put here small
> description of what each resource is meant for? (I guess couple of them
> to P-Unit, and couple related to what you are trying to get, right?)
While the driver code merges the ranges of res0 and res1:
line 244-245:
addr = ioremap_nocache(res0->start,
resource_size(res0) + resource_size(res1));
It appears that we're using very little of this:
punit_ipcdev->base[BIOS_IPC] = addr;
addr += MAILBOX_REGISTER_SPACE;
punit_ipcdev->base[GTDRIVER_IPC] = addr;
addr += MAILBOX_REGISTER_SPACE;
punit_ipcdev->base[ISPDRIVER_IPC] = addr;
MAILBOX_REGISTER_SPACE is 0x10, but I don't know how long ISPDRIVER_IPC is
expected to be, but it apears to be 4 bytes. This would mean we're using a total
of 0x24 starting res0->start. res0 has a length of 0x2000 per the ASL above, and
we're only referencing 0x24 of it.
Why, then, do we merge the lengths of res0 and res1, presumably to 0x2004, when
we only use 0x24?
Or, am I misreading this?
Also, Qipeng, you mentioned earlier that the firmware reported a length of 0x4B
I believe? I don't see that in this ASL.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
