Hello, Mark. Mark Lord wrote:
Well, I've spent much of the day porting to the new interfaces, and then trying to get things working again.
Heh... sorry about the trouble.
One port multiplier card turned out to be totally dead. It was never found (today) by libata, and got quite hot for some reason. Since it is probably now toast, I've set it aside. The other port multiplier here is different, and was not used in the first round of tests. So far, it gets detected by libata,
>
but I'm temporarily stuck on the old issue of libata not finding any of the connected drives. So I probably don't have the myriad of pre/hard/soft/pmp/post reset handlers configured just right yet.
Which PMP are you using? SIMG one or marvell one?
To establish some kind of baseline, I'm going to reimplement the pmp_read/write hooks I used to have, and see if things come alive again with those. And then figure out again what has to change to get rid of them. Tejun: Do you have any recommendations on exactly what should be in mv_pmp_softreset() and mv_softreset() and mv_hardreset() under this scheme? My basic attempt was to try this: No prereset or postreset handlers of any kind.
Yes.
mv_hardreset(): as in the hardreset rework patch (yet to be picked up by Jeff), plus a call to mv_select_pmp(link->ap, SATA_PMP_CTRL_PORT) before the sata_link_hardreset() wrapper loop.
Yes.
mv_softreset(): First do mv_select_pmp(link->ap, SATA_PMP_CTRL_PORT), and then call ata_sff_softreset(). mv_pmp_softreset(): First do mv_select_pmp(link->ap, link->pmp), and then call ata_sff_softreset().
You can just use mv_select_pmp(link->ap, sata_srst_pmp(link)) in mv_softreset() and use it for both mv_softreset() and mv_pmp_softreset().
Resets of the pmp ports always fail with SRST failed (errno=-16).
Hmm... That's -EBUSY. I'll continue on the reply of the other mail. -- tejun -- 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
