As for the property name, I'd prefer fsl,sata-speed-limit or fsl,sata-
max-generation. Shaohui, do the driver bits look OK?
[S.H] The driver part is OK.
I also tested it on p5040, the SATA worked as expected.
Best Regards,
Shaohui Xie
___
Scott Wood scottw...@freescale.com writes:
On Fri, 2013-08-23 at 17:41 -0600, Anthony Foiani wrote:
In my original patch [...] I used fsl,sata-max-gen. I thought
Jeff disliked it, so I changed it be more generic -- but maybe I
misread his complaint. (And while his opinions are still
Bcc:
Subject: Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
Reply-To:
In-Reply-To: g7gj9smnc@dworkin.scrye.com
On Wed, May 08, 2013 at 06:04:39AM -0600, Anthony Foiani wrote:
Anthony Foiani t...@scrye.com writes:
Maybe I need to call ata_set_sata_spd as well. Can I do
Scott Wood scottw...@freescale.com writes:
--- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
This should go in Documentation/devicetree/bindings/ata/fsl-sata.txt.
Ok, will change.
As for the property name, I'd prefer
On Fri, 2013-08-23 at 17:41 -0600, Anthony Foiani wrote:
Scott Wood scottw...@freescale.com writes:
--- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
This should go in
Anthony Foiani t...@scrye.com writes:
Maybe I need to call ata_set_sata_spd as well. Can I do that before
discovery, or should it be a part of the port_start callback? And
if the latter, shouldn't it be handled within the ata core, instead
of expecting each host driver to do that call?
My
Jeff --
Thanks for the quick reply -- sorry that it took me a few days to get
back to you.
[Also, apologies if anyone gets a dupe -- I'm working on a new mail
configuration, and while I did test it, something went sideways the
first time I tried to send this.]
Jeff Garzik writes:
Regarding
On 04/30/2013 09:06:56 PM, Anthony Foiani wrote:
Scott --
On 04/30/2013 06:42 PM, Scott Wood wrote:
I just meant that, for whatever boards you would have put this in
the device tree, put it in platform code instead (if the platform
file supports more than one board type, then check the
On 05/01/2013 06:35:38 PM, Anthony Foiani wrote:
Scott --
Thanks again for the quick reply.
On 05/01/2013 12:05 PM, Scott Wood wrote:
On 04/30/2013 09:06:56 PM, Anthony Foiani wrote:
Instead of a new property name, I would instead check for my
specific board type (let's call it a foo-8315)
Apologies for resurrecting a very old thread, but...
On 05/30/2012 02:14 PM, Anthony Foiani wrote:
Maybe someone who knows devtree really well could crank that out in a
few minutes... but I'm not that person. :)
Well, I wasn't last year, but this year I decided that I didn't care.
Took me
On 04/30/2013 01:41:49 AM, Anthony Foiani wrote:
Apologies for resurrecting a very old thread, but...
On 05/30/2012 02:14 PM, Anthony Foiani wrote:
Maybe someone who knows devtree really well could crank that out in a
few minutes... but I'm not that person. :)
Well, I wasn't last year, but
On 04/30/2013 02:41 AM, Anthony Foiani wrote:
Apologies for resurrecting a very old thread, but...
On 05/30/2012 02:14 PM, Anthony Foiani wrote:
Maybe someone who knows devtree really well could crank that out in a
few minutes... but I'm not that person. :)
Well, I wasn't last year, but
Scott --
Thanks for the quick reply / review!
On 04/30/2013 12:15 PM, Scott Wood wrote:
[The devtree approach] might be OK for a new board, but adding it now
means that people using existing device trees won't get the
workaround. It might be better to just put the knowledge in platform
On 04/30/2013 07:34:39 PM, Anthony Foiani wrote:
Scott --
Thanks for the quick reply / review!
On 04/30/2013 12:15 PM, Scott Wood wrote:
[The devtree approach] might be OK for a new board, but adding it
now means that people using existing device trees won't get the
workaround. It might
Scott --
On 04/30/2013 06:42 PM, Scott Wood wrote:
I just meant that, for whatever boards you would have put this in the
device tree, put it in platform code instead (if the platform file
supports more than one board type, then check the compatible at the
top of the device tree).
I think I
On Wed, May 30, 2012 at 6:57 AM, Scott Wood scottw...@freescale.com wrote:
On 05/29/2012 05:07 PM, Anthony Foiani wrote:
Scott Wood scottw...@freescale.com writes:
CONFIG_MPC831x_RDB doesn't mean that you're running on such a board,
only that the kernel supports those boards. It should be a
Li Yang le...@freescale.com writes:
The original code was there before I touched the driver. So
unfortunately I also don't know the history of the problem.
Alas.
Judging from the comment in code and current test result I guess it
is a board related issue.
I wonder if anyone on the 8315_DS
Scott Wood scottw...@freescale.com writes:
Board information is available from the device tree, and from
platform code that was selected based on the device tree.
You're right, of course; I was focusing on discovery/probing, and
completely forgot about provided information.
However, as I just
On 05/30/2012 03:14 PM, Anthony Foiani wrote:
Scott Wood scottw...@freescale.com writes:
Board information is available from the device tree, and from
platform code that was selected based on the device tree.
You're right, of course; I was focusing on discovery/probing, and
completely
Scott Wood scottw...@freescale.com writes:
We currently support building one kernel that supports a bunch of
different boards. The hardcoding of this workaround was harmless so
far because it was conditional on a symbol that was never defined,
but now you'll be enabling this workaround on
On 05/26/2012 01:53 AM, Anthony Foiani wrote:
Li Yang-R58472 r58...@freescale.com writes:
Thanks for bringing [CONFIG_MPC8315_DS] up again. Looks like we do
have a problem here.
My impression is that the simplest fix is Adrian's patch, which simply
keys off CONFIG_MPC831x_RDB. It's not
Scott Wood scottw...@freescale.com writes:
CONFIG_MPC831x_RDB doesn't mean that you're running on such a board,
only that the kernel supports those boards. It should be a runtime
test.
Point taken.
If that SATA check is CPU/SOC-based, then it should be easy enough to
test. The cpuinfo for
On 05/29/2012 05:07 PM, Anthony Foiani wrote:
Scott Wood scottw...@freescale.com writes:
CONFIG_MPC831x_RDB doesn't mean that you're running on such a board,
only that the kernel supports those boards. It should be a runtime
test.
Point taken.
If that SATA check is CPU/SOC-based, then
Li Yang-R58472 r58...@freescale.com writes:
Thanks for bringing [CONFIG_MPC8315_DS] up again. Looks like we do
have a problem here.
My impression is that the simplest fix is Adrian's patch, which simply
keys off CONFIG_MPC831x_RDB. It's not very satisfying, but I'll take
working vs. rare
-Original Message-
From: Anthony Foiani [mailto:t...@scrye.com]
Sent: Friday, May 18, 2012 1:08 AM
To: linuxppc-dev@lists.ozlabs.org
Cc: ashish kalra; Li Yang-R58472; Jeff Garzik; Robert P.J.Day; Adrian
Bunk
Subject: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
25 matches
Mail list logo
