> Correct, libata does call corresponding interface and the functions
> are defined for the cpu. But this architecture is buggy. It is
> necessary to clean (write back) complete cache before DMA write
> operation even if the corresponding range is already cleaned,
> otherwise few bytes in the written block are corrupted at random
> offset. I've spent many days playing with dma interface and even
> calculating md5sum of every written block before I had to accept this
> fact.
In which case you ultimately want to fix the architecture defintions for
the DMA cohrency really but thats a side issue as it doesn't explain the
MWDMA problem. The source you posted has MWDMA undefined which makes me
wonder if it matches the binary your dmesg is from. It's also possible
some of the other fixes in that code are relevant to MWDMA - certainly
your driver looks sane.
> controller switches to a specific DVD-LOADER mode as soon as kernel
> sends any command to the slave device, so they had to patch sources
> and add a strange looking command
>
> OUT_BYTE((head|drive->select.all) & ~(1<<4), IDE_SELECT_REG);
>
> everywhere the slave device is accessed to cheat the controller and
> let it believe it talks to the master. Slave device remains active
> because it was already selected but the controller assumes we are
> talking to the master and does not switch to DVD-LOADER mode.
That can be done in a libata driver by providing your own exec_command
functions but again could wait. Try something like
static void my_sff_exec_command(struct ata_port *ap, const struct
ata_taskfile *tf)
{
iowrite8(tf->command, ap->ioaddr.command_addr);
if (tf->flags & ATA_TFLAG_DEVICE)
iowrite8(tf->device & ~ATA_DEV1, ap->ioaddr.device_addr);
ata_sff_pause(ap);
}
.sff_exec_command = my_sff_exec_command,
--
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
