On Thu, Jun 10, 2010 at 5:14 PM, Mark Brown
wrote:
> On 10 Jun 2010, at 23:07, Grant Likely wrote:
>
>> To me, this seems firmly in the realm of silicon bug workaround.
>> Considering that the pins aren't relocatable (ie, the GPIO numbers
>> never change), I've got no problem having the GPIO reset
On Wed, Jun 9, 2010 at 4:30 AM, Mark Brown
wrote:
> On Wed, Jun 09, 2010 at 08:13:30AM +0200, Wolfgang Denk wrote:
>> In message
>> you wrote:
>
>> > Would making a change in uboot be a better solution? Eric, can you
>> > verify if changing uboot also fixes the problem?
>
>> To me it seems bette
On 10 Jun 2010, at 23:07, Grant Likely wrote:
> To me, this seems firmly in the realm of silicon bug workaround.
> Considering that the pins aren't relocatable (ie, the GPIO numbers
> never change), I've got no problem having the GPIO reset logic added
> to arch/powerpc/platforms/52xx and hard cod
On Wed, Jun 09, 2010 at 10:41:23AM -0400, Jon Smirl wrote:
> On Wed, Jun 9, 2010 at 10:32 AM, Mark Brown
> > Please include this quote in the changelog for the patch, if this a
> > documented workaround from the vendor that's a very different thing to
> > something that you've found happens to wor
On Wed, Jun 9, 2010 at 10:32 AM, Mark Brown
wrote:
> On Wed, Jun 09, 2010 at 10:21:40AM -0400, Eric Millbrandt wrote:
>
> [Please fix your MUA to word wrap paragraphs to within 80 characters,
> I've reflowed the text below.]
>
>> From the MPC5200B user manual:
>> "Some AC97 devices goes to a test
On Wed, Jun 09, 2010 at 10:21:40AM -0400, Eric Millbrandt wrote:
[Please fix your MUA to word wrap paragraphs to within 80 characters,
I've reflowed the text below.]
> From the MPC5200B user manual:
> "Some AC97 devices goes to a test mode, if the Sync line is high
> during the Res line is low (r
> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: Wednesday, June 09, 2010 06:31
> To: Wolfgang Denk
> Cc: Jon Smirl; Eric Millbrandt; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 0/2] mpc5200 ac97 gpio reset
--snip--
&
> -Original Message-
> From: Jon Smirl [mailto:jonsm...@gmail.com]
> Sent: Wednesday, June 09, 2010 08:22
> To: Wolfgang Denk
> Cc: Eric Millbrandt; Mark Brown; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 0/2] mpc5200 ac97 gpio reset
>
> On Wed, Jun 9, 2
On Wed, Jun 9, 2010 at 2:13 AM, Wolfgang Denk wrote:
> Dear Jon Smirl,
>
> In message you
> wrote:
>>
>> Would making a change in uboot be a better solution? Eric, can you
>> verify if changing uboot also fixes the problem?
>
> To me it seems better if the driver itself does what needs to be don
On Wed, Jun 09, 2010 at 08:13:30AM +0200, Wolfgang Denk wrote:
> In message you
> wrote:
> > Would making a change in uboot be a better solution? Eric, can you
> > verify if changing uboot also fixes the problem?
> To me it seems better if the driver itself does what needs to be done
> instead
Dear Jon Smirl,
In message you
wrote:
>
> Would making a change in uboot be a better solution? Eric, can you
> verify if changing uboot also fixes the problem?
To me it seems better if the driver itself does what needs to be done
instead of relying on specific settings that may or may not be do
On Tue, Jun 8, 2010 at 12:46 PM, Eric Millbrandt
wrote:
> These patches reimplement the reset fuction in the ac97 to use gpio pins
> instead of using the mpc5200 ac97 reset functionality in the psc. This
> avoids a problem in which attached ac97 devices go into "test" mode appear
> unresponsive.
These patches reimplement the reset fuction in the ac97 to use gpio pins
instead of using the mpc5200 ac97 reset functionality in the psc. This
avoids a problem in which attached ac97 devices go into "test" mode appear
unresponsive.
These patches were tested on a pcm030 baseboard and on custom ha
13 matches
Mail list logo
