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@vger...
More majordomo info at  http://vger.kernel.org/majordomo-info.html