> 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
___
Li
Scott Wood 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
> > respected, new
On Fri, 2013-08-23 at 17:41 -0600, Anthony Foiani wrote:
> Scott Wood 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.
>
>
Scott Wood 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 "fsl,sata-speed-
Bcc:
Subject: Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
Reply-To:
In-Reply-To:
On Wed, May 08, 2013 at 06:04:39AM -0600, Anthony Foiani wrote:
> Anthony Foiani writes:
> > Maybe I need to call ata_set_sata_spd as well. Can I do that before
> > discovery, or shou
Anthony Foiani 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 final versi
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 th
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) i
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 compa
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 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 be
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
code.
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 this
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 th
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 ab
Scott Wood 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 any kernel that simply
On 05/30/2012 03:14 PM, Anthony Foiani wrote:
> Scott Wood 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 "prov
Scott Wood 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 mentioned in my rep
Li Yang 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 project knows w
On Wed, May 30, 2012 at 6:57 AM, Scott Wood wrote:
> On 05/29/2012 05:07 PM, Anthony Foiani wrote:
>> Scott Wood 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.
On 05/29/2012 05:07 PM, Anthony Foiani wrote:
> Scott Wood 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 b
Scott Wood 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 my board is:
# cat
On 05/26/2012 01:53 AM, Anthony Foiani wrote:
> Li Yang-R58472 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 satisfy
Li Yang-R58472 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 lockups at boot".
> -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
