Re: DMA mapping on SCSI device?
On Jan 29, 2008 11:08 AM, Robert Hancock [EMAIL PROTECTED] wrote: ... The last solution I tried was to set the DMA mask on both ports to 32-bit on slave_configure when an ATAPI device is connected. However, this runs into complications as well. This is run on initialization and when trying to set the other port into 32-bit DMA, it may not be initialized yet. Plus, it forces the port with a hard drive on it into 32-bit DMA needlessly. Have you measured the impact of setting the PCI dma mask to 32-bit? Last time Alex Williamson (HP) measured this on IA64, we deliberately forced pci_map_sg() to use the IOMMU even for devices that were 64-bit capable. We got 3-5% better throughput since the device had fewer entries to retrieve and the devices (at the time) weren't that good at processing SG lists. The ideal solution would be to do mapping against a different struct device for each port, so that we could maintain the proper DMA mask for each of them at all times. However I'm not sure if that's possible. The thought of using the SCSI struct device for DMA mapping was brought up at one point.. any thoughts on that? I'm pretty sure that's not possible (using two PCI dev structs). I'm skeptical it's worth converting DMA services to use SCSI devs since that's an extremely invasive change for a marginal benefit. hth, grant - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] PCI prepare/activate instead of enable to avoid IRQ storm and rogue DMA access
On Thu, Mar 15, 2007 at 11:37:20AM +0900, Tejun Heo wrote: ... Also, the current implementation doesn't have any arch independent part. I thnk you meant arch dependent here. It's wholly contained in arch independent PCI layer, but it might be beneficial to have arch dependent hooks (IRQ line enable/disable?) in the future. What if the device with the IRQ problem is never loaded? Sometimes devices aren't loaded until after boot. What do you mean by loading a device? Do you mean loading driver for the device? Yes, I think that's what he meant. Any change like this has to be done without changing device drivers. Changing the skge/sky2 drivers as special case is not acceptable. I don't like the idead of changing the driver API for PCI device setup. But if it's necessary to solve this class of problem, I think it's ok. I dunno about that. What I'm proposing is alternative two-step PCI initialization step - the first step enables the device just enough for initialization/reset and the second one enables full access. We're doing part of it already for bus master. I'm proposing to expand that approach and make them handled by generic PCI layer. As you can see, it doesn't add noticeable complexity to drivers. I think it's even clearer than doing pci_set_master() explicitly. Please update Documentation/pci.txt to reflect the API changes too. If this way of solving the problem is chosen, eventually most drivers should be converted to new initialization steps. And there is no way to do this without modifying low level driver. Only low level driver knows when full blown access can be enabled and such thing must happen before registering the device to upper layer (e.g. ATA/SCSI, netif). Agreed. ISTR this has been discussed before but don't recall the exact context. I'll try to find the previous thread. When I started the parisc port on 2.4 kernels, the policy was to leave all interrupts enabled even if no interrupt handler was registered. This is useful for debugging misconfigured IRQ routing. Did the policy already change or is this a proposal to change the policy? thanks, grant sky2/skge aren't exceptions. If this way of solving the problem is chosen, eventually most if not all drivers should be converted to new model. It may take two years, maybe five, but as a start just converting ATA and network drivers shouldn't take too long and that would help a lot of cases. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is the correct way to indicate an unassigned PCI resource ?
On Tue, Dec 05, 2006 at 03:38:57PM +0300, Sergei Shtylyov wrote: Well, I don't have the PCI specification, but I have a device with the Try googling for pdf21.pdf, pdf22.pdf if you need it. :-) I think you meant pci21.pdf/pci22.pdf/pci23.pdf. And if you find them, trust me when I say whoever is hosting those files can expect a cease-and-desist letter in the mail shortly there after. Better to just ask someone with proper access to lookup the parts you need to know (i.e. ask here). Member companies are listed at: http://www.pcisig.com/membership/about_us/membership_roster/ if you want to approach someone offlist. following gem in its errata (name edited and changed to Device): The Device contains two PCI base registers to allow for both greater flexibility in tightly constrained I/O space as well as the on the fly option to access the Device registers from either I/O or memory space. Both PCI base registers contained in the Device will accept the value of zero as a valid and decodable address. This differs from the PCI 2.1 specification, where a zero value being written to the PCI base register should disable the register space. I haven't found such words in PCI 2.1 -- it only said that 0 is not a valid address (those words are gone from 2.2). AFAIK, zero is a valid address for IO Port space on several architectures. But PCI generic code should never use it. See usage of PCIBIOS_MIN_IO and PCIBIOS_MIN_MEM in the various asm-*/pci.h files. Device will continue to decode for register accesses using the value zero written to the PCI_BS register as the base address for decoding. I'd say it's absolutely valid bahavior. which makes me suspect that a base address of zero really should mean unassigned and is a way to disable base registers on a region by region basis. AFAIR, there's never been a provision to enable/disable BARs on an individual basis in PCI (except the expansion ROM BAR). The decoders are only controlled via 2 command register bits for I/O and memory space. One can disable a BAR by pointing it at an address that is NOT routed by the upstream bridge. Ie CPU physical addresses that can never reach that secondary bus. But I'm not aware of any code to do that currently and it certainly won't work with all PCI-like (think integrated south bridges) devices. But it might be sufficient for some special need. hth, grant - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
