On Fri, 2008-08-01 at 12:58 -0400, Alan Cox wrote: > > I know and I believe it should still be ok ... As I said, the chipset > > should use the PIO field in the register for PIO transfers. And if the > > above unknown bit is set, I suspect it's just going to increase the > > setup time a bit or something like that, which won't hurt other than > > perfs. > > What I do with some other drivers is set the PIO mode in the pio mode function > but defer DMA timing setup to bmdma_start/stop methods. Some chips need this > in the PC world and that works nicely. That would work too I suppose. I already need to tweak the DMA mode in dbmda_start because of a need on one of the variants of the cell to add 60ns to the setup time on UDMA reads. However, the search for timing is a bit of overhead I would have been happy to avoid there :-) Oh well, we'll see how things go, but in this area, I think my current code will work just fine. > > The reason is that I can only have 64K-4K per transfer (I don't think I > > can do 64K per DBDMA entry). So the above routine can potentially > > breakup, in the worst case scenario, the table into twice as many > > entries if they are all 64K precisely. > > See ata_sff_dumb_qc_prep - we have PC chips with the same bug! Yes well, this is an added bug of alignment restrictions which I don't have (ie, you can't cross 64K boundaries, I'm pretty sure I can :-) Anyway, setting the max segment size in the new dma params is what I need to do here. Cheers, Ben. > -- > "Engineers are 'small children' when it comes to product warning labels" > -- John Duino > > -- > To unsubscribe from this list: send the line "unsubscribe linux-ide" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
