All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Rob Herring <robherring2@gmail.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Shawn Guo <shawn.guo@freescale.com>,
	Sascha Hauer <kernel@pengutronix.de>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>, Tejun Heo <tj@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	linux-ide@vger.kernel.org
Subject: Re: [PATCH RFC 5/5] ahci_imx: add disable for spread-spectrum
Date: Wed, 16 Apr 2014 23:57:21 +0100	[thread overview]
Message-ID: <20140416225721.GP24070@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CAL_JsqK_BbhXs0gcn=w=1KPKOD0HZzmYx5zAaS5_z=UvQDPNjw@mail.gmail.com>

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@arm.linux.org.uk> 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.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC 5/5] ahci_imx: add disable for spread-spectrum
Date: Wed, 16 Apr 2014 23:57:21 +0100	[thread overview]
Message-ID: <20140416225721.GP24070@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CAL_JsqK_BbhXs0gcn=w=1KPKOD0HZzmYx5zAaS5_z=UvQDPNjw@mail.gmail.com>

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@arm.linux.org.uk> 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.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

  reply	other threads:[~2014-04-16 22:58 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-16  8:42 [PATCH 0/5] imx ahci DT updates + cubox-i eSATA support Russell King - ARM Linux
2014-04-16  8:42 ` Russell King - ARM Linux
2014-04-16  8:43 ` [PATCH RFC 1/5] ata: ahci_imx: warn when disabling ahci link Russell King
2014-04-16  8:43   ` Russell King
2014-04-16  8:43 ` [PATCH RFC 2/5] ata: ahci_imx: avoid reprobing ahci_imx driver when using DT Russell King
2014-04-16  8:43   ` Russell King
2014-04-17  8:45   ` Shawn Guo
2014-04-17  8:45     ` Shawn Guo
2014-04-17 18:37     ` Russell King - ARM Linux
2014-04-17 18:37       ` Russell King - ARM Linux
2014-04-16  8:43 ` [PATCH RFC 3/5] ata: ahci_imx: allow hardware parameters to be specified in DT Russell King
2014-04-16  8:43   ` Russell King
     [not found] ` <20140416084227.GD24070-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2014-04-16  8:43   ` [PATCH RFC 4/5] ARM: cubox-i: add eSATA DT configuration Russell King
2014-04-16  8:43     ` Russell King
2014-04-16  8:43 ` [PATCH RFC 5/5] ahci_imx: add disable for spread-spectrum Russell King
2014-04-16  8:43   ` Russell King
2014-04-16 22:46   ` Rob Herring
2014-04-16 22:46     ` Rob Herring
2014-04-16 22:57     ` Russell King - ARM Linux [this message]
2014-04-16 22:57       ` Russell King - ARM Linux
2014-04-16 23:02       ` Russell King - ARM Linux
2014-04-16 23:02         ` Russell King - ARM Linux
2014-06-06 16:40         ` Russell King - ARM Linux
2014-06-06 16:40           ` Russell King - ARM Linux
2014-06-06 19:50           ` Rob Herring
2014-06-06 19:50             ` Rob Herring
2014-06-17  9:47             ` Russell King - ARM Linux
2014-06-17  9:47               ` Russell King - ARM Linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140416225721.GP24070@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=robherring2@gmail.com \
    --cc=shawn.guo@freescale.com \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.