å 2009-05-23åç 13:47 +0200ïBartlomiej ZolnierkiewiczåéïUse the driver drivers/ata/pata_cs5536.c, unfortunately it also have the same issue.
On Saturday 23 May 2009 09:11:42 yanh wrote:
å 2009-05-22äç 20:32 +0200ïBartlomiej ZolnierkiewiczåéïThen it should use the new & shiny :) native cs5536 IDE host driver
On Thursday 21 May 2009 00:12:46 wuzhangjin@xxxxxxxxx wrote:In loongson2f yeeloong machines, the ide controller is AMD cs5536, or
From: Wu Zhangjin <wuzhangjin@xxxxxxxxx>Sadly, the patch description lacks all the important information.
This is originally from the to-mips branch from
http://dev.lemote.com/code/linux_loongson
What is the original problem that this fixup tries to address?
Is it limited to amd74xx controllers?
say amd74xx, and the hard drives is Fujistu.
instead of legacy support in amd74xx...
While debuging the hard disk suspned and resume, the ide irq can not beAFAICS the only change that the fixup would cause for suspend/resume paths
cleared. I guess this is a fake interrupt, hence the clear irq action
can not be finished.
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);
--->right.
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?
the cs5536 pata driver have some geode platform dependent codes. We canThis patch is to fix this issue. Maybe other controller and drives alsoProbably moving it to a generic quirk_drives list later will be useful...
have this issue, but I am not sure.
Anyway this fixup needs to be ported to / verified with cs5536 first.
just ignore it, but the performance is poor(using hdparm to test it),
which only get 22+ MB/s. we find it only use udma2. However if using
amd74xx driver, it can set udma5, and the speed can reach to 50+ MB/s.
we will test whether this driver is working well without this patch.
Anyway, thanks your advice.
Thanks.
Bart