Re: [Resend PATCH 5/5] IA64/PCI/ACPI: Rework PCI root bridge ACPI resource conversion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/24/2013 06:39 AM, Bjorn Helgaas wrote:
[+cc Greg]

On Fri, Oct 18, 2013 at 08:44:12PM +0800, Lan Tianyu wrote:
On 10/18/2013 04:33 AM, Bjorn Helgaas wrote:
On Thu, Oct 17, 2013 at 12:09 AM, Lan Tianyu <tianyu.lan@xxxxxxxxx> wrote:
On 2013年10月17日 07:55, Bjorn Helgaas wrote:
On Fri, Oct 11, 2013 at 08:19:01PM +0800, tianyu.lan@xxxxxxxxx wrote:

I wonder if it would make sense to make
acpi_dev_resource_address_space() ignore addr.translation_offset for
IO resources.  Or maybe ignore it if the _TTP (type translation) bit
is set?

I wonder why current code doesn't check _TTP? The code in the
add_io_space() seems to think _TTP is always set, right?

I think it's an oversight, and you should fix it.  I suggest that you
ignore the _TRA value when _TTP is set.  Obviously this only applies
to I/O port resources, since _TTP is only defined in the I/O Resource
Flag (Table 6-185 in ACPI 5.0 spec).

_TTP is also defined in the Memory Resource flag, Please have a look at
Table 6-184 in the ACPI 5.0 Spec.

I am not sure how to deal with _TTP unsetting io resource? _TTP unsetting mean the resource is IO on the primary side and also IO on the secondary side.


Mike, is there any chance you could collect an acpidump from an
rx7620 or similar ia64 system?  In particular, I want to see a
multi-node system where we have several PCI domains, and whether it
sets the _TTP bits.

Greg collected an acpidump from an HP system that uses these I/O port
ranges.  Unfortunately the system wasn't running Linux, so it's an EFI
dump, not the usual one we get from the "pmtools" package.  But I
think it has the information we want.

It's huge, and I put some of the relevant parts of it here:
https://bugzilla.kernel.org/show_bug.cgi?id=63581  Here's a sample
that shows the _TTP bit is set for the I/O aperture:

     Device E000 (\_SB_.N000.E000)
       Name _SEG (\_SB_.N000.E000._SEG)
         0x01
       Name _CRS (\_SB_.N000.E001._CRS)
         Buffer
           0x0092
           ByteList <0x88 0x0d 0x00 0x02 0x0e 0x00 0x00 0x00
                     0x00 0x00 0xff 0x00 0x00 0x00 0x00 0x01

                     0x8a 0x2b 0x00 0x01 0x0c 0x33 0x00 0x00
                     0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
                     0x00 0x00 0x00 0x00 0x00 0x00 0xff 0xff
                     0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
                     0x00 0xd0 0x00 0x04 0x00 0x00 0x00 0x00
                     0x01 0x00 0x00 0x00 0x00 0x00

Byte 0: 0x8a (QWORD address space descriptor)
Byte 3: Resource Type = 0x01 (I/O range)
Byte 5: Type Specific Flags = 0x33 (_TRS, _TTP, _RNG = 3)

           QWORD Address Space Descriptor:
              Type: I/O
              Flags:  Sparse, Translate, ISA I/O addresses, Non-ISA I/O addresses
              GRA: 0x0000000000000000
              MIN: 0x0000000000000000  MAX: 0x000000000000ffff
              TRA: 0x00000400d0000000  LEN: 0x0000000000010000
              MAX address fixed
              MIN address fixed
              Address positively decoded
              Device produces and consumes this resource

Bjorn


--
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




[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux