lkml.org 
[lkml]   [2011]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 3/3] Add NumaChip quirk
On Tue, Oct 25, 2011 at 12:09 PM, Arne Georg Gleditsch
<arne.gleditsch@numascale.com> wrote:
> On 25. okt. 2011 19:33, Steffen Persvold wrote:
>> On 10/25/2011 19:15, Bjorn Helgaas wrote:
>>> NumaChip sounds like an exception because you know you never care
>>> about using those BARs.  But I'm curious -- it looks like Linux didn't
>>> even try to assign resources to them.  I thought something in the
>>> pci_assign_unassigned_resources() path would have tried to do
>>> something with them.  If we *did* assign resources to those BARs, I
>>> assume nothing would break, since there's no driver that actually uses
>>> them.  Right?
>>>
>>
>> Correct, the BARs are there and if something sensible were written to
>> them (and MemorySpace was enabled in the Command register) NumaChip
>> *would* respond to mmio accesses to that address range.
>
> A minor point: adjusting the BARs would not strictly speaking be
> sufficient for the NumaChip to respond, as it would never see these
> accesses unless the [MMIO address range]->[HyperTransport node/link]
> registers of the CPU NorthBridges were also updated with the relevant
> ranges.  This is a bit messy, but in a way much the same issue as when
> secondary southbridges are connected to secondary CPUs in any other
> HyperTransport-based system.

The [MMIO address range]->[HyperTransport node/link] registers you're
talking about are the implementation side of the PCI host bridge
abstraction. You should have an ACPI host bridge device (PNP0A03 or
PNP0A08) that describes the apertures, and if Linux assigns resources
to the BARs, it will only use areas inside the apertures. If there's
no available space in the apertures, we just leave the device alone
(maybe this explains why we didn't assign anything).

> Perhaps an alternative to this NumaChip-specific quirk would be to
> special-case BARs belonging to "PCI" devices 00:18 - 00:1f in AMD
> Opteron systems.  These always indicate coherent HT devices and fiddling
> with the CPU NB maps are going to be required if anything is changed
> regarding the BAR assignments here.

I don't think there's a need to special-case these AMD BARs. If the
BIOS programs them correctly (inside a PCI host bridge aperture
reported via ACPI), Linux won't touch them.

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: 2011-10-25 22:05    [W:1.456 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site