lkml.org 
[lkml]   [2013]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Resend PATCH 5/5] IA64/PCI/ACPI: Rework PCI root bridge ACPI resource conversion
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@intel.com> wrote:
>>>> On 2013年10月17日 07:55, Bjorn Helgaas wrote:
>>>>> On Fri, Oct 11, 2013 at 08:19:01PM +0800, tianyu.lan@intel.com 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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2013-10-26 19:21    [W:0.130 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site