Re: Using the generic host PCIe driver

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

 



On 01/03/2017 22:57, Bjorn Helgaas wrote:

> On Wed, Mar 01, 2017 at 07:05:26PM +0100, Mason wrote:
> 
>> Another thing I don't understand... According to this reference:
>> http://elinux.org/Device_Tree_Usage#PCI_Address_Translation
>>
>> The "ranges" prop starts with:
>>
>>     phys.hi  cell: npt000ss bbbbbbbb dddddfff rrrrrrrr
>>     phys.mid cell: hhhhhhhh hhhhhhhh hhhhhhhh hhhhhhhh
>>     phys.low cell: llllllll llllllll llllllll llllllll
>>
>> So I thought it might be possible to specify bbbbbbbb = 0x01
>> to mean "I want to assign memory only to bus 1, don't assign
>> any memory to bus 0". Am I mistaken?
> 
> I don't really understand the "bbbbbbbb" field in that range.  The
> bridge has a "bus-ranges" property that defines the PCI bus numbers
> below the bridge.  As I understand it, the first number in bus-ranges
> is the root bus (the bus immediately below the host bridge).  Is
> "bbbbbbbb" supposed to be identical to the that root bus number?  If
> so, it seems redundant, so why does the "bbbbbbbb" field even exist?
> 
> If "bbbbbbbb" can be different from the root bus number, I don't know
> what it means.  The host bridge translates CPU physical addresses to
> PCI bus address on the root bus (the PCI bus immediately below the
> bridge).  Once on the PCI side, the correspondence of memory addresses
> to bus numbers is controlled completely by PCI-to-PCI bridges,
> independent of what DT contains.

The answer (probably) lies in
PCI Bus Binding to: IEEE Std 1275-1994
Standard for Boot (Initialization Configuration) Firmware, Revision 2.1
[What does "to" mean in "PCI Bus Binding to"? Is it a typo?]

> 12. Use of the "ranges" property
> 
> The "ranges" property of Open Firmware represents how address
> transformation is done across bus bridges. The "ranges" property
> conveys this information for PCI, but the use of the property is not
> as straightforward as on some other busses.
> 
> In particular, the phys.hi fields of the child address spaces in the
> "ranges" property for PCI does not contain the same information as
> "reg" property entries within PCI nodes. The only information that is
> present in "ranges" phys.hi entries are the non-relocatable,
> prefetchable and the PCI address space bits for which the entry
> applies. I.e., only the n, p and ss bits are present; the bbbbbbbb,
> ddddd, fff and rrrrrrrr fields are 0.
> 
> When an address is to be mapped through a PCI bus bridge node, the
> phys.hi value of the address to be mapped and the child field of a
> "ranges" entry should be masked so that only the ss bits are
> compared. I.e., the only portion of phys.hi that should participate
> in the range determination is the address space indicator (the ss bits).

So my bbbbbbbb = 0x01 attempt was non-sensical (as I expected).

For now, I have "hidden" the root's BAR0 from the system with:

	if (bus->number == 0 && where == PCI_BASE_ADDRESS_0) {
		*val = 0;
		return PCIBIOS_SUCCESSFUL;
	}

Regards.



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux