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/
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/
On Tue, Aug 13, 2002 at 08:34:03AM -0700, Matt Porter wrote:
On Fri, Aug 09, 2002 at 02:26:05PM +1000, David Gibson wrote:
quoted
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.
Agreed. I see the use of a single "ocp" bus as a transitional step.
My first concern was toget something working - as a proof of concept,
and so that we can have working support for ocp devices with an
interface that is less broken that the current ocp code.
Using a single bus makes it easier to import the devices from the
existing core_ocp structure while we port the drivers to the driverfs
way of thinking.
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/