On Saturday 23 May 2009 09:11:42 yanh wrote: > 在 2009-05-22五的 20:32 +0200，Bartlomiej Zolnierkiewicz写道： > > On Thursday 21 May 2009 00:12:46 wuzhangjin@xxxxxxxxx wrote: > > > From: Wu Zhangjin <wuzhangjin@xxxxxxxxx> > > > > > > This is originally from the to-mips branch from > > > http://dev.lemote.com/code/linux_loongson > > > > Sadly, the patch description lacks all the important information. > > > > What is the original problem that this fixup tries to address? > > > > Is it limited to amd74xx controllers? > > In loongson2f yeeloong machines, the ide controller is AMD cs5536, or > say amd74xx, and the hard drives is Fujistu. Then it should use the new & shiny :) native cs5536 IDE host driver instead of legacy support in amd74xx... > While debuging the hard disk suspned and resume, the ide irq can not be > cleared. I guess this is a fake interrupt, hence the clear irq action > can not be finished. AFAICS the only change that the fixup would cause for suspend/resume paths is the one in ide_config_drive_speed() which is called during resume to set transfer mode on the drive: tp_ops->write_devctl(hwif, ATA_NIEN | ATA_DEVCTL_OBS); memset(&tf, 0, sizeof(tf)); tf.feature = SETFEATURES_XFER; tf.nsect = speed; tp_ops->tf_load(drive, &tf, IDE_VALID_FEATURE | IDE_VALID_NSECT); tp_ops->exec_command(hwif, ATA_CMD_SET_FEATURES); ---> if (drive->quirk_list == 2) tp_ops->write_devctl(hwif, ATA_DEVCTL_OBS); ---> error = __ide_wait_stat(drive, drive->ready_stat, ATA_BUSY | ATA_DRQ | ATA_ERR, WAIT_CMD, &stat); Please tell me I if understand the issue correctly: if the above quirk is not executed we end up with spurious IRQs, right? > This patch is to fix this issue. Maybe other controller and drives also > have this issue, but I am not sure. Probably moving it to a generic quirk_drives list later will be useful... Anyway this fixup needs to be ported to / verified with cs5536 first. Thanks. Bart -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
