Stefan Richter wrote: > Benjamin Herrenschmidt wrote: >> 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.) > > 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.
Not sure this is a very good idea. This seems rather likely to fail on x86_64 machines with >4GB of RAM for example.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
