On Thu, 2007-05-24 at 02:02 -0400, Jeff Garzik wrote: > MMIO has always been like this (libata-core.c): > > /* software reset. causes dev0 to be selected */ > iowrite8(ap->ctl, ioaddr->ctl_addr); > udelay(20); /* FIXME: flush */ > iowrite8(ap->ctl | ATA_SRST, ioaddr->ctl_addr); > udelay(20); /* FIXME: flush */ > iowrite8(ap->ctl, ioaddr->ctl_addr); Yup, one of the things my patch adds is a mmio_flush optional hook that I added in there just before the udelay's. > The problem is mainly in finding registers you can read without side > effects or confusing the controller which might also be doing in-silicon > reset procedures. > > The above is not correct per PCI posting, hence the FIXME, but it works > so far for all tested cases. Yes. For most MMIO controllers, reading the PRD table base address is probably a good enough way to acheive this. > The timing is irrelevant for SATA (this merely triggers a FIS to be > sent). Most of PATA is not MMIO, so this problem is avoided. Thus the > potential affected cases are PATA MMIO, which is largely PDC and SiI, IIRC. > > Ben's patch got merged because it does not change the status quo. This > warrants looking at -- its a core problem as shown above -- but it > requires thinking and testing on a problematic platform :) Maybe we can > read a PCI config register or innocuous vendor-specific register, for > the flush, on the few cases where it matters. I'm adding a hook for that with a generic sff version that controllers like sil can use that just reads the dbdma prd table pointer. Now there is still the question of wether the taskfile read for the 400ns delay in ata_pause is correct or not.. Cheers, Ben. - 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
