Re: [PATCH 2/9] ide: fix ide_intr() for non-PCI devices and CONFIG_BLK_DEV_IDEPCI=y
Bartlomiej Zolnierkiewicz wrote: 'hwif-pci_dev !hwif-pci_dev-vendor' condition is never true, check for 'hwif-chipset != ide_pci' instead. Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] Acked-by: Sergei Shtylyov [EMAIL PROTECTED] MBR, Sergei - 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 7/9] icside: use hwif-dev
Bartlomiej Zolnierkiewicz wrote: * Setup hwif-dev in icside_setup(). * Use hwif-dev instead of state-dev in icside_build_sglist(), icside_dma_end(), icside_dma_start() and icside_dma_setup(). * Remove no longer needed 'dev' field from struct icside_state. Cc: Russell King [EMAIL PROTECTED] Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] Acked-by: Sergei Shtylyov [EMAIL PROTECTED] MBR, Sergei PS: Russel, that was only an eyes check, the last word is yours. :-) - 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] trm290: do hook dma_host_{on,off} methods (take 2)
Hello. Bartlomiej Zolnierkiewicz wrote: Using default methods caused the chip's DMA PRD count registers, inadvertently starting DMA! While fixing it, also do: nasty, this could possibly explain the following trm290.c hack: Frankly speaking, I'm not sure it's that destructive: the register in question is accessed by inw()/outw() while the genric code would only spoil it by inb(). So, I don't know if this would be access to the same register as outw() does (that write starts DMA, and it is a number of 32-bit words in PRD table - 1). Actually, the PRD address is loaded by 32-bit write at address 2 bytes below the one in question, and so overlaps our register -- the chip must be looking at byte enables when deciding what register is addressed). ... #if 0 /* play it safe for now */ IDE_HFLAG_TRUST_BIOS_FOR_DMA | #endif ... - get rid of the 'ide_' prefixes in several functions for which the prefix in the method's name has been 'ide_' ectomized already; - align the code hooking the IDE DMA methods in init_hwif_trm290()... --- Fixed the header, added 'static' to the new method definitions. The patch is against Linus' kernel tree... Signed-off-by: Sergei Shtylyov [EMAIL PROTECTED] applied The next patch is cooking... :-) WBR, Sergei - 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] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v3)
Robert Hancock wrote: Jeff Garzik wrote: Robert Hancock wrote: This fixes some problems with ATAPI devices on nForce4 controllers in ADMA mode on systems with memory located above 4GB. We need to delay setting the 64-bit DMA mask until the PRD table and padding buffer are allocated so that they don't get allocated above 4GB and break legacy mode (which is needed for ATAPI devices). Signed-off-by: Robert Hancock [EMAIL PROTECTED] This is a bit nasty :/ I would consider setting the consistent DMA mask to 32-bit, and setting the overall mask to 64-bit. Seems like that would solve the problem? The issue with that is that it would also constrain the ADMA CPB/PRD table allocation to 32-bit, which I'd rather avoid having to do. There are dual-socket Opteron boxes like HP xw9300 that use this controller, and limiting the allocation to 32-bit could force a non-optimal node allocation for the table memory. These type of devices really want a version of dma_alloc_coherent that allows overriding the DMA mask for specific allocations to make this cleaner. I'm sure this isn't the only device that has different DMA mask requirements for different consistent memory allocations.. This patch does has the advantage of being confirmed to fix the reporter's problem (https://bugzilla.redhat.com/show_bug.cgi?id=351451) which there's something to be said for this late in the .24-rc series.. Also, does this need to be rebased on top of what I just pushed upstream? It don't think so.. this change is independent from the sata_nv: don't use legacy DMA in ADMA mode (v3) patch you just merged. This bug fix is still outstanding. I haven't heard any more comments on this one recently.. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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
