RE: MPC8641D PEX: programming OWBAR in Endpoint mode?

[David Hagood <david.hagood@gmail.com>]

On Thu, 2010-09-23 at 05:21 +0200, Chen, Tiejun wrote:
> > I can get the device to show up on the host's PCI bus, I can 
> 
> This only ensure you can access the PCIe configure space.
Not quite: I can also read the BARs that I program, and the memory
behind them on the PPC.
> 
> > program the inbound ATMUs such that the BARS are updated when 
> > the host (re-)scans them, but I cannot for the life of me get
> 
> What value are configured to IntBound REGs?
I can program them at run time via sysfs on the PPC's side, so there is
no single set of values. However, I am pointing them at the PPC's RAM
space, and as I stated above, I can read the PPC's RAM from the host
side via the BARs.

> How do you configure OWS of PEXOWAR?
> 
> I means you still access that if OWS is match the whole target memory
> size even when '0' is as the internal platform address.
As I understand it, not if the OWS is not correctly mapped on the PPC
side - the PEX outbound ATMU's OWBAR must be mapped to a region of the
PPCs address space that is also mapped to PEX in the LAW. The LAW does
NOT indicate that PPC address 0 is mapped to the PEX.

> 
> Out_be32 should be fine for atmu REGs. And also you can refe to the
> function, setup_pci_atmu & setup_one_atmu, on the file,
> arch/powerpc/sysdev/fsl_pci.c, to know how to access atmu REGs. Often
> you should disable them, configure then enable/invoke atmu antry as
> normal configuring sequent.
I have tried disabling the outbound ATMU when I program it, with no
change.
I have looked at the functions you mention, and that is a part of my
confusion, as they aren't doing anything different than I am.
> 
> Additionally I'm a bit afraid your initial phase :) As you know PCIe
> would be used as RC mode on Freescale PowerPC kernel. So I don't know if
> you also drop this path on your kernel to conflict each other :) 
I have tried doing this under a kernel built without PCI support with no
change.