On Fri, Jun 6, 2014 at 11:40 AM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Thu, Apr 17, 2014 at 12:02:26AM +0100, Russell King - ARM Linux wrote: >> On Wed, Apr 16, 2014 at 11:57:21PM +0100, Russell King - ARM Linux wrote: >> > On Wed, Apr 16, 2014 at 05:46:47PM -0500, Rob Herring wrote: >> > > On Wed, Apr 16, 2014 at 3:43 AM, Russell King >> > > <rmk+kernel@xxxxxxxxxxxxxxxx> wrote: >> > > > Spread-spectrum doesn't work with Cubox-i hardware, so we have to >> > > > disable this feature. Add a DT property so that platforms can >> > > > indicate that this feature should not be enabled. >> > > >> > > This is for spread-spectrum tx or rx? Transmit SS is optional to >> > > support, but the receiver must support SS. Otherwise random drives >> > > won't work which makes for a good user experience. Is this really a >> > > board quirk rather than a Si issue? >> > >> > No idea. This bit controls clock generation, and one reason given to >> > disable it is if the reference clock being supplied is already spread >> > spectrum. I don't think that applies here. It doesn't say which >> > clock(s) this is applied to - I would guess it's the transmit clock. >> > >> > All I know is that with SS enabled, the drive is not detected, and >> > SolidRun's original port disables SS. Disabling SS allows the external >> > drive to be detected. >> > >> > I have no capability to check the eye pattern, so I've no idea if >> > there's a problem with the electrical setup which stops SS from >> > working. All I know is with the parameters I give here (which are >> > those which SolidRun's original port uses) and with SS disabled, >> > it works. >> >> I'll correct that - it _is_ detected with SS enabled, but things go >> awry very quickly with errors, which then result in corrupted IDENTIFY >> responses, the link dropping back to 1.5Gbps, more errors and corruption >> and eventually the SATA layer gives up and declares the port dead. > > Rob, > > Can I take your lack of reply on this as meaning that you don't have > any objections against these new DT properties for this driver - if > so, can I have your ack for these properties please? Yes, they are okay. I'll ack the documentation once that is done. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
