Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"

On Tue, 2007-08-07 at 00:22 +0200, Stefan Richter wrote:

Benjamin Herrenschmidt wrote:

quoted

Oh and, don't do the set_dma_mask() in sbp2, it has nothing to do there.
It should be in the ohci1394 driver.

That's not quite right.  OHCI-1394 implementations can go beyond 4GB bus
address space.  (Although I don't know if there are such implementations
available.  At least there are two implementations which can set the
so-called Physical Range bigger than 4GB.)

Hrm..

Sbp2 however requires that everything which it DMA-maps resides in the
Physical Range of the controller.  This way the CPU is not involved in
most of the data transfers.  The OHCI-1394 controller acts as bus bridge
between IEEE 1394 bus and local bus, with a 1:1 mapping of IEEE 1394 bus
addresses to and from local bus addresses --- but not in the whole 48
bits white IEEE 1394 bus address range, only in the
implementation-dependent Physical Range.  The minimum Physical Range
that all OHCI-1394 implementations guarantee is 4GB.  I could actually
have set a bigger mask in sbp2 when the controller supports a
programmable bigger range.

So that's the story why that dma_set_mask went into sbp2:  Sbp2 wants
mappings in a _subset_ of the OHCI-1394 controllers DMA range.

Anyway.  For now I will simply go with what 2.6.23-rc has and what
2.6.21 had:  No dma_set_mask anywhere in the 1394 subsystem.  We can
revisit this whenever an actual need arises.

Ok, I see your point, however, the problem is that at this stage, in
linux, you really can only set the dma mask on the pci device of the
ohci. That means that sbp2 will effectively change the ohci's DMA mask
for all OHCI operations...

Architectures like powerpc (and possibly others) need to track what
iommu/bridge/etc... a device is on for proper mapping and provide
different DMA operations for different busses. Thus, only devices that
have properly been "setup" by the architecture for DMA can use the DMA
operations.

So while ideally, sbp2 should set the dma mask on itself (or rather on
the sbp2 device) and then use that device for dma mapping operations,
this will not work.

Now, we could try to devise a generic API for use by things such as
ieee1394 to "make DMA'able" sub devices of a pci device with local dma
masks. At least for powerpc, it wouldn't be too hard, but other archs
might have issues if they do things like test for the bus_type.

Cheers,
Ben.