linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* tracking of PCI address space
@ 2009-04-08 20:53 Kumar Gala
  2009-04-08 21:49 ` Ira Snyder
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Kumar Gala @ 2009-04-08 20:53 UTC (permalink / raw)
  To: Jesse Barnes
  Cc: Linux Kernel Mailing List, linux-pci, Benjamin Herrenschmidt,
	Linux/PPC Development

I was wondering if we have anything that tracks regions associated  
with the "inbound" side of a pci_bus.

What I mean is on embedded PPC we have window/mapping registers for  
both inbound (accessing memory on the SoC) and outbound (access PCI  
device MMIO, IO etc).  The combination of the inbound & outbound  
convey what exists in the PCI address space vs CPU physical address  
space (and how to map from one to the other).  Today in the PPC land  
we only attach outbound windows to the pci_bus.  So technically the  
inbound side information (like what subset of physical memory is  
visible on the PCI bus) seems to be lost.

- k

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: tracking of PCI address space
  2009-04-08 20:53 tracking of PCI address space Kumar Gala
@ 2009-04-08 21:49 ` Ira Snyder
  2009-04-08 21:53   ` Kumar Gala
  2009-04-09  6:21 ` Benjamin Herrenschmidt
  2009-04-09  6:55 ` Grant Grundler
  2 siblings, 1 reply; 5+ messages in thread
From: Ira Snyder @ 2009-04-08 21:49 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Jesse Barnes, linux-pci, Benjamin Herrenschmidt,
	Linux Kernel Mailing List, Linux/PPC Development

On Wed, Apr 08, 2009 at 03:53:55PM -0500, Kumar Gala wrote:
> I was wondering if we have anything that tracks regions associated with 
> the "inbound" side of a pci_bus.
>
> What I mean is on embedded PPC we have window/mapping registers for both 
> inbound (accessing memory on the SoC) and outbound (access PCI device 
> MMIO, IO etc).  The combination of the inbound & outbound convey what 
> exists in the PCI address space vs CPU physical address space (and how to 
> map from one to the other).  Today in the PPC land we only attach 
> outbound windows to the pci_bus.  So technically the inbound side 
> information (like what subset of physical memory is visible on the PCI 
> bus) seems to be lost.
>

To the best of my knowledge there is no API to set inbound windows in
Linux. I've been implementing a virtio-over-PCI driver which needs the
inbound windows. I set them up myself during driver probe, using
get_immrbase() to get the IMMR registers. This board is a PCI Slave /
Agent, it doesn't even have PCI support compiled into the kernel.

Ira

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: tracking of PCI address space
  2009-04-08 21:49 ` Ira Snyder
@ 2009-04-08 21:53   ` Kumar Gala
  0 siblings, 0 replies; 5+ messages in thread
From: Kumar Gala @ 2009-04-08 21:53 UTC (permalink / raw)
  To: Ira Snyder
  Cc: Jesse Barnes, linux-pci, Benjamin Herrenschmidt,
	Linux Kernel Mailing List, Linux/PPC Development


On Apr 8, 2009, at 4:49 PM, Ira Snyder wrote:

> On Wed, Apr 08, 2009 at 03:53:55PM -0500, Kumar Gala wrote:
>> I was wondering if we have anything that tracks regions associated  
>> with
>> the "inbound" side of a pci_bus.
>>
>> What I mean is on embedded PPC we have window/mapping registers for  
>> both
>> inbound (accessing memory on the SoC) and outbound (access PCI device
>> MMIO, IO etc).  The combination of the inbound & outbound convey what
>> exists in the PCI address space vs CPU physical address space (and  
>> how to
>> map from one to the other).  Today in the PPC land we only attach
>> outbound windows to the pci_bus.  So technically the inbound side
>> information (like what subset of physical memory is visible on the  
>> PCI
>> bus) seems to be lost.
>>
>
> To the best of my knowledge there is no API to set inbound windows in
> Linux. I've been implementing a virtio-over-PCI driver which needs the
> inbound windows. I set them up myself during driver probe, using
> get_immrbase() to get the IMMR registers. This board is a PCI Slave /
> Agent, it doesn't even have PCI support compiled into the kernel.

I'm not concerned explicitly about setting up inbound windows, its  
more about have a consistent view of the PCI address space which may  
be different from the CPU physical address space.

I'm working on code to actually setup the inbound windows on 85xx/86xx  
class devices (based on dma-ranges property in the device tree).  As I  
was thinking about this I realized that the send of ranges/dma-ranges  
in the .dts and what we map to outbound vs inbound changes if we an  
agent or host.

- k

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: tracking of PCI address space
  2009-04-08 20:53 tracking of PCI address space Kumar Gala
  2009-04-08 21:49 ` Ira Snyder
@ 2009-04-09  6:21 ` Benjamin Herrenschmidt
  2009-04-09  6:55 ` Grant Grundler
  2 siblings, 0 replies; 5+ messages in thread
From: Benjamin Herrenschmidt @ 2009-04-09  6:21 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Jesse Barnes, Linux Kernel Mailing List, linux-pci,
	Linux/PPC Development

On Wed, 2009-04-08 at 15:53 -0500, Kumar Gala wrote:
> I was wondering if we have anything that tracks regions associated  
> with the "inbound" side of a pci_bus.
> 
> What I mean is on embedded PPC we have window/mapping registers for  
> both inbound (accessing memory on the SoC) and outbound (access PCI  
> device MMIO, IO etc).  The combination of the inbound & outbound  
> convey what exists in the PCI address space vs CPU physical address  
> space (and how to map from one to the other).  Today in the PPC land  
> we only attach outbound windows to the pci_bus.  So technically the  
> inbound side information (like what subset of physical memory is  
> visible on the PCI bus) seems to be lost.

On powerpc, we do keep track of the offset, but that's about it.

Tracking inbound ranges is very platform specific though. You can have
multiple inbound windows with different translations, in some cases some
via iommu and some not, or windows aliasing the same target memory but
with different attributes, etc...

I don't think there's that much interest in trying to create generic
code to keep track.

Ben.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: tracking of PCI address space
  2009-04-08 20:53 tracking of PCI address space Kumar Gala
  2009-04-08 21:49 ` Ira Snyder
  2009-04-09  6:21 ` Benjamin Herrenschmidt
@ 2009-04-09  6:55 ` Grant Grundler
  2 siblings, 0 replies; 5+ messages in thread
From: Grant Grundler @ 2009-04-09  6:55 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Jesse Barnes, Linux Kernel Mailing List, linux-pci,
	Benjamin Herrenschmidt, Linux/PPC Development

On Wed, Apr 08, 2009 at 03:53:55PM -0500, Kumar Gala wrote:
> I was wondering if we have anything that tracks regions associated with 
> the "inbound" side of a pci_bus.
>
> What I mean is on embedded PPC we have window/mapping registers for both 
> inbound (accessing memory on the SoC) and outbound (access PCI device 
> MMIO, IO etc).  The combination of the inbound & outbound convey what 
> exists in the PCI address space vs CPU physical address space (and how to 
> map from one to the other).

Most PCI Host bus controllers will negatively decode the outbound ranges
for inbound traffic.

PARISC and IA64 have extra registers to play some games with that. But
routing between PCI bus controllers to make them look like a single PCI
segment was the main intent of that. I've not found any other uses
to subvert that.

>  Today in the PPC land we only attach 
> outbound windows to the pci_bus.  So technically the inbound side 
> information (like what subset of physical memory is visible on the PCI 
> bus) seems to be lost.

What did you need inbound "routing map" for?

thanks,
grant

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2009-04-09  6:56 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-08 20:53 tracking of PCI address space Kumar Gala
2009-04-08 21:49 ` Ira Snyder
2009-04-08 21:53   ` Kumar Gala
2009-04-09  6:21 ` Benjamin Herrenschmidt
2009-04-09  6:55 ` Grant Grundler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).