Re: 440 PCI adapter card DMA question

Re: 440 PCI adapter card DMA question

[Matt Porter]

[Please, always start a new mail when starting a new thread.  Don't
 reply to an old one and change the subject, it messes up people
 using mailbox threading.]

On Fri, Aug 16, 2002 at 11:39:15AM -0700, Khai Trinh wrote:
> On one of your response email to me, you said the
> 440GP maps PCI<->PLB 1:1 and I can use the PCI bus
> address directly as a PLB address to program the 440GP
> DMA controller.
>
> The thing is that the DMA high and low register only
> allows 36-bit programming whereas the PCI bus address
> given to me by the Host is 64-bit.

I was answering with respect to the Ebony PCI-X host bridge
configuration.

> Don't I have to manually setup the PCI-PLB mapping
> before I can program the DMA controller? OR the 440
> kernel has already handle that?

The PCI-X host bridge configuration in the Ebony port is
implemented for host operation only (i.e. it has set up
windows and controls BAR assignment within a controlled
PCI address space).  If you need a special translation
for your particular adapter application, you will need
to modify that setup accordingly.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: First steps to OCP device model integration

[Matt Porter]

On Fri, Aug 09, 2002 at 02:26:05PM +1000, David Gibson wrote:
>
> THe patch below implements the first steps in transitioning the
> handling of 4xx OCP devices to the unfied device model (in 2.5).  So
> far the code just registers an ocp bus and registers each device
> described in core_ocp on that bus.  The next step is to convert the
> actual device drivers so that that they register with the unified
> driver tree rather than through the old ocp_register() mechanism.

Hi David,

I don't have any concerns about your patch as a starting point,
but I'd like to talk about where we are going with driverfs
integration of proprietary on-chip buses (4xx and other SoCs).
This "first steps" patch shows you registering OCP as a bus
with a name of "Onchip Peripheral Bus".  This seems to trivialize
the bus hierarchy on 4xx and part of the point of driverfs is
to see where devices are located in the physical bus structure
(since management of them may vary based on their location).
I would expect to see "PLB", "OPB", and "ExtBus" registered
for 4xx for correctness.  They may all use the same bus ops
in a reference board implementation (not making use of the EBC
in most cases), but somebody could have some FPGA-based peripherals
hanging from the EBC which require board-specific PM ops and thus
it would be desirable to see and manage at least the External Bus
separately in driverfs.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

440 PCI adapter card DMA question

[Khai Trinh]

Matt,

Welcome back to the ppc mailing list. I would like
your answer to my question really bad on the topic of
mapping the PCI bus DMA address to the PLB address
space for setting up the 440GP DMA. I don't have the
email I sent you anymore.

On one of your response email to me, you said the
440GP maps PCI<->PLB 1:1 and I can use the PCI bus
address directly as a PLB address to program the 440GP
DMA controller.

The thing is that the DMA high and low register only
allows 36-bit programming whereas the PCI bus address
given to me by the Host is 64-bit.

Don't I have to manually setup the PCI-PLB mapping
before I can program the DMA controller? OR the 440
kernel has already handle that?

Your comment and response are very important and
appreciated...

Thanks again,
--Khai


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/