Subject: Re: SATA hang on 8315E triggered by heavy flash write?

From: Anthony Foiani <[email-masked]>
Date: Mon, 27 May 2013 18:29:57 -0600

Shaohio --

Once again, thanks for the reply.

Xie Shaohui-B21989 <[email-masked]> writes:

> it seems [recovery or lack of recovery is] not due to speed limiting
> code, 1.5Gbps is still used to recover link.

Right, I noticed this in my later email on this topic.

> for the speed limit issue, I checked 3.4.rc7 kernel, there seems a
> place can be used to limit the speed for 8315:
>
> 	if (!of_device_is_compatible(ofdev->dev.of_node, "fsl,mpc8315-sata")) {
> 		temp = ioread32(csr_base + TRANSCFG);
> 		temp = temp & 0xffffffe0;
> 		iowrite32(temp | TRANSCFG_RX_WATER_MARK, csr_base + TRANSCFG);
> 	} else {
> 		/* the speed limitation code for 8315 may can be put here.
> 		* just move the original code which wrapped by "#ifdef CONFIG_MPC8315_DS" here.
> 		* please let me know if you will give a try. */
> 	}

It's not clear that all uses of the MPC8315 SATA controller have this
problem.  It obviously occured on the 8315DS, but apparently that
board never made it to production; it might or might not happen on the
8315ERDB; and it clearly happens on my vendor's board.

Given this lack of knowledge, Scott Wood was very hesitant to
implement any far-reaching changes, because we could not pin down
exactly what had to be tested.

My original patch:

  http://article.gmane.org/gmane.linux.ports.ppc.embedded/58710

did the speed limiting directly in the sata_fsl code; Jeff Garzik
mentioned that there was some existing infrastructure for this, and I
inferred that he would prefer that I use it.

So that's what my final patch does, and it's keyed off a single OF
value.

There's a small chance that I'll have the opportunity to move the
project to 3.9 (especially if that release gets declared
long-term-stable).  Even then, I unfortunately won't have the
bandwidth to pursue getting any of these approaches into mainline.
The best I can do is get them onto the lists so that others might be
able to benefit later.

Either way, thanks again.  I'll try to put together a package for my
vendor to test with; once I have demonstrated that there is a problem
with their hardware, they have been gracious about accepting that
result and pursuing it with Freescale if necessary.

Thanks again for your help!

Best regards,
Anthony Foiani