* Re: Inline assembly queries [2]
From: Brad Boyer @ 2009-07-03 17:40 UTC (permalink / raw)
To: kernel mailz; +Cc: gcc-help, linuxppc-dev, linux-kernel
In-Reply-To: <abe8a1fd0907022344k2eb9874ejdbda3209a7cadf40@mail.gmail.com>
On Fri, Jul 03, 2009 at 12:14:41PM +0530, kernel mailz wrote:
> Thanks for responding to my previous mail. A few more queries
>
> a. What is the use of adding format specifiers in inline assembly
> like
> asm volatile("ld%U1%X1 %0,%1":"=r"(ret) : "m"(*ptr) : "memory");
The format specifiers limit which registers or addressing modes will
be chosen to access that parameter. For example, if you're using an
instruction that treats r0 as a literal 0 value, you can't use the
"r" specifier for that or you may see problems if it happens to allocate
r0 for that particular argument. For memory access, the "m" lets you
use any of the normal load/store patterns (which is why this particular
choice also requires the "%U1%X1" part to allow changing the instruction).
The system was setup for an older style chip like x86 or 68k with many
restrictions on which registers can be used where and large numbers of
different addressing modes for accessing memory. It's a little clumsy
for ppc by comparison to most other chips, but it's a fundamental part
of inline assembly processing in gcc.
> b. using m or Z with a memory address. I tried replacing m/Z but no change
> Is there some guideline ?
> gcc documentation says Z is obsolete. Is m/Z replaceable ?
No idea. I don't remember ever seeing 'Z' used in anything. Maybe somebody
else remembers what it used to mean.
Brad Boyer
flar@allandria.com
^ permalink raw reply
* Re: mpc52xx_uart.c - Port Overruns
From: Detlev Zundel @ 2009-07-03 11:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <c788c1220907021823y384b78c1x2bb9e0fc3268c0e0@mail.gmail.com>
Hi Damien,
> I am writing to ask about some particular behaviour we saw with the MPC5121 PSC
> UART, using the 2.6.24 Freescle BSP kernel, although examining the code of the
> linux-2.6-denx tree (git commit 7cb16ec2590815a67e5fb5c8994ead536613d922), the
> behavior is almost identical except for incrementing an overrrun counter.
>
> In particular, yesterday we observed a port overrun (from the overrun flags
> being set when looking with the BDI) on one of our PSC Ports. When it was
> observed, we saw that every second byte coming from the serial port was 0x00.
>
> Examining the interrupt routine of the mpc52xx_uart.c:
>
> static inline int
> mpc52xx_uart_int_rx_chars(struct uart_port *port)
> {
> <snip>
> tty_insert_flip_char(tty, ch, flag);
> if (status & MPC52xx_PSC_SR_OE) {
> /*
> * Overrun is special, since it's
> * reported immediately, and doesn't
> * affect the current character
> */
> tty_insert_flip_char(tty, 0, TTY_OVERRUN);
> port->icount.overrun++;
> }
> <snip>
> }
>
> So, from my deduction, it is inserting a 0x00 for every overrun error that
> occurs, however, the overrun flag is never cleared. Therefore fro every byte
> that is received, the overrup flag is still set and therefore we're observing
> the 0x00 being inserted for every "real" byte coming into the port
>
> Is there a particular reason why the overrun flag is not cleared? That is,
> parity, framing and breaks are acknowledged with:
>
> /* Clear error condition */
> out_8(&PSC(port)->command, MPC52xx_PSC_RST_ERR_STAT);
>
> But the overrun isn't cleared. Is there are particular reason why? Is
> userspace meant to detect this condition and reset the port? Was it
> automatically cleared on the 5200 when reading the status, but the 5121 is
> exhibiting strange behavior?
This is likely only forgotten in the driver. I remember fixing this in
our 2.4 kernel tree a long time ago[1].
Cheers
Detlev
[1] http://git.denx.de/?p=linuxppc_2_4_devel.git;a=commitdiff;h=00097a16641865b88568b807c9680b50c74bda84
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: [PATCH 1/2] ASoC: Fix mpc5200-psc-ac97 to ensure the data ready bit is cleared
From: Mark Brown @ 2009-07-03 9:59 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20090702175719.15773.58956.stgit@localhost.localdomain>
On Thu, Jul 02, 2009 at 11:57:19AM -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> When doing register reads, it is possible for there to be a stale
> data ready bit set which will cause subsequent reads to return
> prematurely with incorrect data. This patch fixes the issues by
> ensuring stale data is cleared before starting another transaction.
Applied both, thanks.
^ permalink raw reply
* Re: ppc405ex + gigabit ethernet
From: Lada Podivin @ 2009-07-03 9:09 UTC (permalink / raw)
To: Cote, Sylvain; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <579B119545DAEF4689C8FBEEFEC5793F01D4FF01A2D0@ATLMBX.verint.corp.verintsystems.com>
Hi Sylvain,
the interrupt coalescing sounds like good idea - I'm surprised this
feature is missing in the original ibm_newemac driver. You wrote you
had got this optimisation directly from AMCC. Is it part of any
framework? I'm just wondering how one can obtain it. I tried to find
any suitable patch but with no success - the old friend Google didn't
help this time :)
Thank you very much!
Lada
^ permalink raw reply
* Re: ppc405ex + gigabit ethernet
From: Lada Podivin @ 2009-07-03 8:22 UTC (permalink / raw)
To: LiuMing; +Cc: linuxppc-dev
In-Reply-To: <COL107-W5372858231522587839F1CB22F0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 64 bytes --]
Many thanks for all responses! Now I know all I need to know :)
[-- Attachment #2: Type: text/html, Size: 71 bytes --]
^ permalink raw reply
* Re: [Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces
From: K.Prasad @ 2009-07-03 8:11 UTC (permalink / raw)
To: David Gibson
Cc: Michael Neuling, Benjamin Herrenschmidt, linuxppc-dev, paulus,
Alan Stern, Roland McGrath
In-Reply-To: <20090619050409.GC17986@yookeroo.seuss>
On Fri, Jun 19, 2009 at 03:04:09PM +1000, David Gibson wrote:
> On Thu, Jun 18, 2009 at 11:50:45PM +0530, K.Prasad wrote:
> > On Wed, Jun 17, 2009 at 02:32:24PM +1000, David Gibson wrote:
> > > On Wed, Jun 10, 2009 at 02:38:06PM +0530, K.Prasad wrote:
> [snip]
With apologies for the long delay here's my response. Some work that was
required to push the generic breakpoint patches into mainline (which is
now pushed to 2.6.32 merge window) and the preparation of a paper kept me
away from responding. Also to add that I will be on a week long vacation
starting next week followed by travel to Linux Symposium and I will not
be able to actively respond to mails till the week beginning 20th of
this month.
But kindly drop in your comments as I would like to have the PPC64
patches ready well before the next merge window opens!
>
> Ah, right, yes. This seems a really non obvious control flow for a
> NULL triggered value to lead to EINVAL. I'd prefer:
>
> if (!bp->triggered)
> return -EINVAL
>
> /* Then the kernel address test */
>
> return arch_store_info(bp, tsk);
>
Ok. It is a minor change and I will do it.
> [snip]
> > > > + /* Verify if dar lies within the address range occupied by the symbol
> > > > + * being watched. Since we cannot get the symbol size for
> > > > + * user-space requests we skip this check in that case
> > > > + */
> > > > + if ((hbp_kernel_pos == 0) &&
> > > > + !((bp->info.address <= dar) &&
> > > > + (dar <= (bp->info.address + bp->info.symbolsize))))
> > > > + /*
> > > > + * This exception is triggered not because of a memory access on
> > > > + * the monitored variable but in the double-word address range
> > > > + * in which it is contained. We will consume this exception,
> > > > + * considering it as 'noise'.
> > > > + */
> > > > + goto out;
> > > > +
> > > > + (bp->triggered)(bp, regs);
> > >
> > > So this confuses me. You go to great efforts to step over the
> > > instruction to generate a SIGTRAP after the instruction, for
> > > consistency with x86. But that SIGTRAP is *never* used, since the
> > > only way to set userspace breakpoints is through ptrace at the moment.
> > > At the same time, the triggered function is called here before the
> > > instruction is executed, so not consistent with x86 anyway.
If the SIGTRAP generation code is in ptrace_triggered() then it would
benefit only ptrace (although it is the lone user of HW-breakpoints at
the moment). Given that SIGTRAP is the only means for the user-space to
detect a breakpoint 'hit' on one of its monitored addresses, we will
generate it for all cases by keeping the code in hw_breakpoint.c (and
not in ptrace_triggered()).
However I believe that your concern here is about the timing of the
SIGTRAP signal generation and I agree with it...please find further
comments about it below.
> > >
> > > It just seems strange to me that sending a SIGTRAP is a special case
> > > anyway. Why can't sending a SIGTRAP be just a particular triggered
> > > function.
> >
> > The consistency in the interface across architectures that I referred to
> > in my previous mail was w.r.t. continuous triggering of breakpoints and
> > not to implement a trigger-before or trigger-after behaviour across
> > architectures. In fact, this behaviour differs even on the same
> > processor depending upon the breakpoint type (trigger-before for
> > instructions and trigger-after for data in x86), and introducing
> > uniformity might be a) at the cost of loss of some unique & innovative
> > uses for each of them b) may not be always possible e.g. trigger-after
> > to trigger-before.
>
> Hrm. Well (a) is why I was suggesting an option to allow trigger
> before on powerpc. Plus, I don't see why you think (a) is important
> for the triggered function, but not for the timing of a SIGTRAP to
> userspace.
>
True that the timing of signal generation is inconsistent for user-space
when requested through ptrace vs requested through the interface. The
requirement for having a continuous breakpoint (as opposed to the
one-shot behaviour of ptrace) doesn't allow the signal to be delivered
in the time-window between the exception and the instruction execution.
I'm contemplating a few ways to work-arounds to ensure consistent signal
delivery timing. One such work-around would be like this:
hbp_handler(1)-->SIGTRAP-->signal_handler-->hbp_handler(2)-->
disable_hbp+enable_ss-->single_step_handler(3)-->enable_hbp+disable_ss
This method would take three exceptions for every breakpoint-hit (as
enumerated above) and will be expensive. Any alternative suggestions
with lower run-time overhead would greatly benefit the patch.
> As for (b), well there are already a bunch of things which can only be
> done on certain archs/processors, so I don't see that's anything
> really new.
Yes, the timing of SIGTRAP generation will remain dependant on the host
processor but the user should be allowed to receive breakpoints
continuously irrespective of the architecture. A one-shot behaviour only
on PPC64 (and only in user-space) doesn't seem nice.
>
> How do you handle continuous breakpoints in the trigger-before case
> (instruction breakpoints) on x86? Do you need to step over an
> instruction is the same manner as you do for powerpc? In this case
> where does x86 send the SIGTRAP?
>
Instructions breakpoints are trigger-before in x86 but the hardware
eases the task by providing RF flag (in EFLAGS register) that would
temporarily disable the instruction breakpoint while the causative
instruction is executed.
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
Thanks,
K.Prasad
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: add locking to mpc5200-psc-ac97 driver
From: Grant Likely @ 2009-07-03 7:12 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <4A4D05AB.1090306@evidence.eu.com>
On Thu, Jul 2, 2009 at 1:08 PM, michael<michael@evidence.eu.com> wrote:
> Hi,
>
> Grant Likely wrote:
>>
>> From: Grant Likely <grant.likely@secretlab.ca>
>>
>> AC97 bus register read/write hooks need to provide locking, but the
>> mpc5200-psc-ac97 driver does not. =A0This patch adds a mutex around
>> the register access routines.
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>>
>> =A0sound/soc/fsl/mpc5200_dma.c =A0 =A0 =A0| =A0 =A01 +
>> =A0sound/soc/fsl/mpc5200_dma.h =A0 =A0 =A0| =A0 =A01 +
>> =A0sound/soc/fsl/mpc5200_psc_ac97.c | =A0 13 ++++++++++++-
>> =A03 files changed, 14 insertions(+), 1 deletions(-)
>>
>>
>> diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
>> index efec33a..f0a2d40 100644
>> --- a/sound/soc/fsl/mpc5200_dma.c
>> +++ b/sound/soc/fsl/mpc5200_dma.c
>> @@ -456,6 +456,7 @@ int mpc5200_audio_dma_create(struct of_device *op)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -ENODEV;
>> =A0 =A0 =A0 =A0 =A0spin_lock_init(&psc_dma->lock);
>> + =A0 =A0 =A0 mutex_init(&psc_dma->mutex);
>> =A0 =A0 =A0 =A0psc_dma->id =3D be32_to_cpu(*prop);
>> =A0 =A0 =A0 =A0psc_dma->irq =3D irq;
>> =A0 =A0 =A0 =A0psc_dma->psc_regs =3D regs;
>> diff --git a/sound/soc/fsl/mpc5200_dma.h b/sound/soc/fsl/mpc5200_dma.h
>> index 2000803..8d396bb 100644
>> --- a/sound/soc/fsl/mpc5200_dma.h
>> +++ b/sound/soc/fsl/mpc5200_dma.h
>> @@ -55,6 +55,7 @@ struct psc_dma {
>> =A0 =A0 =A0 =A0unsigned int irq;
>> =A0 =A0 =A0 =A0struct device *dev;
>> =A0 =A0 =A0 =A0spinlock_t lock;
>> + =A0 =A0 =A0 struct mutex mutex;
>> =A0 =A0 =A0 =A0u32 sicr;
>> =A0 =A0 =A0 =A0uint sysclk;
>> =A0 =A0 =A0 =A0int imr;
>> diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c
>> b/sound/soc/fsl/mpc5200_psc_ac97.c
>> index 9b8503f..7eb5499 100644
>> --- a/sound/soc/fsl/mpc5200_psc_ac97.c
>> +++ b/sound/soc/fsl/mpc5200_psc_ac97.c
>> @@ -34,11 +34,14 @@ static unsigned short psc_ac97_read(struct snd_ac97
>> *ac97, unsigned short reg)
>> =A0 =A0 =A0 =A0int status;
>> =A0 =A0 =A0 =A0unsigned int val;
>> =A0+ =A0 =A0 =A0 mutex_lock(&psc_dma->mutex);
>> +
>> =A0 =A0 =A0 =A0/* Wait for command send status zero =3D ready */
>> =A0 =A0 =A0 =A0status =3D
>> spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) &
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MPC52xx_P=
SC_SR_CMDSEND), 100, 0);
>> =A0 =A0 =A0 =A0if (status =3D=3D 0) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pr_err("timeout on ac97 bus (rdy)\n");
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mutex_unlock(&psc_dma->mutex);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -ENODEV;
>>
>
> maybe define an err variable and and a goto out.
My first iteration did that, but after looking at it I decided I like
this better and it adds (slightly) fewer lines of code.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [spi-devel-general] [PATCH v4] powerpc/5200: Add mpc5200-spi (non-PSC) device driver
From: Grant Likely @ 2009-07-03 7:01 UTC (permalink / raw)
To: Wolfram Sang
Cc: linuxppc-dev, David Brownell, linux-kernel, spi-devel-general
In-Reply-To: <20090618142610.GC10629@pengutronix.de>
On Thu, Jun 18, 2009 at 8:26 AM, Wolfram Sang<w.sang@pengutronix.de> wrote:
>> There used to be a sysfs interface for dumping these, but it was an
>> ugly misuse. =A0I'd like to leave these in. =A0I still have the sysfs bi=
ts
>> in a private patch and I'm going to rework them for debugfs.
>
> Okay. Maybe a comment stating the future use will be nice.
okay
>> > But I wonder more about the usage of the SS pin and if this chipsel is=
needed
>> > at all (sadly I cannot test as I don't have any board with SPI connect=
ed to
>> > that device). You define the SS-pin as output, but do not set the SSOE=
-bit.
>> > More, you use the MODF-feature, so the SS-pin should be defined as inp=
ut?
>> > According to Table 17.3 in the PM, you have that pin defined as generi=
c purpose
>> > output.
>>
>> That's right. =A0The SS handling by the SPI device is completely
>> useless, so this driver uses it as a GPIO and asserts it manually.
>
> That definately needs a comment :D (perhaps with some more details if you=
know them).
>
>> The MODF irq is probably irrelevant, but I'd like to leave it in for
>> completeness.
>
> But it won't work if the pin is set to output, no?
yes
> Are you sure there are no side-effects?
I'm sure.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Inline assembly queries [2]
From: kernel mailz @ 2009-07-03 6:44 UTC (permalink / raw)
To: linuxppc-dev, gcc-help, linux-kernel
Hi,
Thanks for responding to my previous mail. A few more queries
a. What is the use of adding format specifiers in inline assembly
like
asm volatile("ld%U1%X1 %0,%1":"=r"(ret) : "m"(*ptr) : "memory");
b. using m or Z with a memory address. I tried replacing m/Z but no change
Is there some guideline ?
gcc documentation says Z is obsolete. Is m/Z replaceable ?
- Manish
^ permalink raw reply
* Re: [spi-devel-general] [PATCH -mm v4][POWERPC] mpc8xxx : allow SPI without cs.
From: David Brownell @ 2009-07-03 1:38 UTC (permalink / raw)
To: spi-devel-general, Rini van Zetten; +Cc: linuxppc-dev list
In-Reply-To: <4A3B9E38.9060004@arvoo.nl>
On Friday 19 June 2009, Rini van Zetten wrote:
> This patch adds the possibility to have a spi device without a cs.
Note that there's now the SPI_NO_CS bit in spi_device.mode
to describe this situation ... so no "-EEXIST" hackery should
ever tempt anyone again.
^ permalink raw reply
* RE: [PATCH 1/2] KVM/PPC: Fix PPC KVM e500_tlb.c build error
From: Liu Yu-B13201 @ 2009-07-03 1:35 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, Yang Shi, kvm-ppc, hollisb, kvm
In-Reply-To: <4A4C97C4.9090908@redhat.com>
=20
> -----Original Message-----
> From: Avi Kivity [mailto:avi@redhat.com]=20
> Sent: Thursday, July 02, 2009 7:20 PM
> To: Liu Yu-B13201
> Cc: Yang Shi; hollisb@us.ibm.com; kvm-ppc@vger.kernel.org;=20
> kvm@vger.kernel.org; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 1/2] KVM/PPC: Fix PPC KVM e500_tlb.c build error
>=20
> On 07/02/2009 06:09 AM, Liu Yu-B13201 wrote:
> > This fix is already accepted in kvm.git
> > =20
>=20
> What about the other? Is it needed?
>=20
No, it's already fixed by commit =
b57227e600f4ecc394d6ba3c2aaa558867b5addc.
^ permalink raw reply
* mpc52xx_uart.c - Port Overruns
From: Damien Dusha @ 2009-07-03 1:23 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]
Dear List,
I am writing to ask about some particular behaviour we saw with the MPC5121
PSC UART, using the 2.6.24 Freescle BSP kernel, although examining the code
of the linux-2.6-denx tree (git commit
7cb16ec2590815a67e5fb5c8994ead536613d922), the behavior is almost identical
except for incrementing an overrrun counter.
In particular, yesterday we observed a port overrun (from the overrun flags
being set when looking with the BDI) on one of our PSC Ports. When it was
observed, we saw that every second byte coming from the serial port was
0x00.
Examining the interrupt routine of the mpc52xx_uart.c:
static inline int
mpc52xx_uart_int_rx_chars(struct uart_port *port)
{
<snip>
tty_insert_flip_char(tty, ch, flag);
if (status & MPC52xx_PSC_SR_OE) {
/*
* Overrun is special, since it's
* reported immediately, and doesn't
* affect the current character
*/
tty_insert_flip_char(tty, 0, TTY_OVERRUN);
port->icount.overrun++;
}
<snip>
}
So, from my deduction, it is inserting a 0x00 for every overrun error that
occurs, however, the overrun flag is never cleared. Therefore fro every
byte that is received, the overrup flag is still set and therefore we're
observing the 0x00 being inserted for every "real" byte coming into the port
Is there a particular reason why the overrun flag is not cleared? That is,
parity, framing and breaks are acknowledged with:
/* Clear error condition */
out_8(&PSC(port)->command, MPC52xx_PSC_RST_ERR_STAT);
But the overrun isn't cleared. Is there are particular reason why? Is
userspace meant to detect this condition and reset the port? Was it
automatically cleared on the 5200 when reading the status, but the 5121 is
exhibiting strange behavior?
Best regards,
Damien Dusha.
[-- Attachment #2: Type: text/html, Size: 2075 bytes --]
^ permalink raw reply
* Re: Subject: [PATCH v8] spi: Add PPC4xx SPI driver
From: David Brownell @ 2009-07-03 0:44 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev@ozlabs.org, Stefan Roese
In-Reply-To: <4A44F643.3050505@harris.com>
On Friday 26 June 2009, Steven A. Falco wrote:
> +
> + /*
> + * If there are no chip selects at all, or if this is the special
> + * case of a non-existent (dummy) chip select, do nothing.
> + */
> +
> + if (!hw->master->num_chipselect || hw->gpios[cs] == -EEXIST)
> + return;
> +
I'm going to send this in, but please send a followup
patch making all this "non-existent (dummy) chip select"
stuff use the SPI_NO_CS flag.
> + /*
> + * A count of zero implies a single SPI device without any chip-select.
> + * Note that of_gpio_count counts all gpios assigned to this spi master.
> + * This includes both "null" gpio's and real ones.
> + */
^ permalink raw reply
* Re: Preemption question (4xx related)
From: Josh Boyer @ 2009-07-03 0:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Felix Radensky
In-Reply-To: <1246574460.7551.6.camel@pasglop>
On Fri, Jul 03, 2009 at 08:41:00AM +1000, Benjamin Herrenschmidt wrote:
>On Thu, 2009-07-02 at 07:12 -0400, Josh Boyer wrote:
>> On Thu, Jul 02, 2009 at 05:33:12PM +1000, Benjamin Herrenschmidt wrote:
>> >On Wed, 2009-07-01 at 20:14 -0400, Josh Boyer wrote:
>> >
>> >> I've toyed with that idea myself. I keep coming back to the fact that you need
>> >> a workload that would really leverage it, and I don't have one at the moment.
>> >
>> >To some extent that's true but just turning full preemption including
>> >kernel side with all the associated debug bits and lockdep should make a
>> >whole bunch of things show up even with ordinary workloads.
>>
>> I can look at doing that for ppc44x_defconfig. I'll be honest and say I don't
>> expect it to go well, particularly with lockdep :).
>>
>> >For 440 tend to boot an ubuntu distro off NFS root with all X & DRI 3D
>> >etc... and then run compiz :-)
>>
>> Yes. Because that's a totally realistic workload for a 440. I'm surprised you
>> don't have a p595 machine acting as your home router too! ;)
>
>It doesn't need to be realistic. In fact, a "realistic" workload is the
>worst thing to test with because it won't exercise all the "uncommon"
>code path which are the ones likely to bite.
>
>So yesm it's not a "realistic" workload, but it's a good "torture"
>workload to find bugs.
It was a joke. But yes, you make perfectly valid points :)
josh
^ permalink raw reply
* Re: Preemption question (4xx related)
From: Benjamin Herrenschmidt @ 2009-07-02 22:41 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Felix Radensky
In-Reply-To: <20090702111246.GG6189@zod.rchland.ibm.com>
On Thu, 2009-07-02 at 07:12 -0400, Josh Boyer wrote:
> On Thu, Jul 02, 2009 at 05:33:12PM +1000, Benjamin Herrenschmidt wrote:
> >On Wed, 2009-07-01 at 20:14 -0400, Josh Boyer wrote:
> >
> >> I've toyed with that idea myself. I keep coming back to the fact that you need
> >> a workload that would really leverage it, and I don't have one at the moment.
> >
> >To some extent that's true but just turning full preemption including
> >kernel side with all the associated debug bits and lockdep should make a
> >whole bunch of things show up even with ordinary workloads.
>
> I can look at doing that for ppc44x_defconfig. I'll be honest and say I don't
> expect it to go well, particularly with lockdep :).
>
> >For 440 tend to boot an ubuntu distro off NFS root with all X & DRI 3D
> >etc... and then run compiz :-)
>
> Yes. Because that's a totally realistic workload for a 440. I'm surprised you
> don't have a p595 machine acting as your home router too! ;)
It doesn't need to be realistic. In fact, a "realistic" workload is the
worst thing to test with because it won't exercise all the "uncommon"
code path which are the ones likely to bite.
So yesm it's not a "realistic" workload, but it's a good "torture"
workload to find bugs.
Cheers,
Ben.
^ permalink raw reply
* Re: RAMDISK on EP88xc
From: Mikhail Zaturenskiy @ 2009-07-02 21:57 UTC (permalink / raw)
To: Scott Wood; +Cc: Frank Svendsbøe, linuxppc-dev, Gary Thomas
In-Reply-To: <4A4D2B70.1030505@freescale.com>
>> Frank! That worked like a charm! I downloaded linux-2.6.26 source from
>> git.kernel.org, inserted the config options previously mentioned,
>> compiled ok, keeping U-Boot ramdisk and my DTS same it booted right up
>> and no more "slow motion" issue.
>
> If you have time, could you bisect to see when the slowdown was introduced?
I'm leaving in 5 minutes, but I'll try to find some time next week to
check this out.
Mikhail
^ permalink raw reply
* Re: Non-contiguous physical memory on 8572
From: Aaron Pace @ 2009-07-02 21:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4A4D2332.1060607@freescale.com>
On Thu, Jul 2, 2009 at 3:14 PM, Scott Wood<scottwood@freescale.com> wrote:
> Aaron Pace wrote:
>>
>> In MMU_init of arch/powerpc/mm/init_32.c, where the current code sets
>> lmb.memory.cnt to zero, I instead walk through the memory regions and
>> call lmb_reserve for each chunk of memory that lies in a 'hole'.
>> There are then some minor fixups to make sure that total_memory and
>> total_highmem get the right numbers. =A0This small change allows all
>> four gigabytes of memory to be accessed and used in my tests.
>>
>> Am I missing something obvious?
>
> The main downsides that I see are wasted memory for bookkeeping of the ho=
le
> (how acceptable this is depends on how large the hole is relative to the
> size of RAM -- it's a tradeoff against speed of looking up page structs),
> and that the reserved area may still be mapped in the TLB without the
> guarded bit set.
>
> -Scott
>
>
Ah, thanks for the response.
A couple of followup clarifications/questions, if you don't mind.
As far as wasted memory for bookkeeping, aren't the reserved regions
excluded from any zonelist/pagetable allocation? I'm looking through
to verify, but if you know off the top of your head where any extra
data would be required to keep track, I'd like to take a look to
further educate my memory manager understanding.
Secondly, can you elaborate on how/when the reserved area could be
mapped into the TLB? I don't by any means lay claim to a complete
understanding of this area, but aside from a direct ioremap/mmap call,
how would this area get mapped at all?
Thanks again,
Aaron
^ permalink raw reply
* Re: RAMDISK on EP88xc
From: Scott Wood @ 2009-07-02 21:49 UTC (permalink / raw)
To: Mikhail Zaturenskiy; +Cc: Frank Svendsbøe, linuxppc-dev, Gary Thomas
In-Reply-To: <97dd5fd20907021438ve8c72b9g168e4aa22e9f2f9f@mail.gmail.com>
Mikhail Zaturenskiy wrote:
>> This is very interesting. I recently experienced a similar problem when
>> upgrading from 2.6.26-rc6 to 2.6.31-rc1 (torvalds mainline kernel).
>>
>> I didn't had the time to figure out what was happening, so I went back to
>> 2.6.26-rc6. Just for the test, could you try to go back to 2.6.26 and see if
>> the problem remains?
>
> Frank! That worked like a charm! I downloaded linux-2.6.26 source from
> git.kernel.org, inserted the config options previously mentioned,
> compiled ok, keeping U-Boot ramdisk and my DTS same it booted right up
> and no more "slow motion" issue.
If you have time, could you bisect to see when the slowdown was introduced?
-Scott
^ permalink raw reply
* Re: RAMDISK on EP88xc
From: Mikhail Zaturenskiy @ 2009-07-02 21:38 UTC (permalink / raw)
To: Frank Svendsbøe; +Cc: linuxppc-dev, Gary Thomas
In-Reply-To: <1ba63b520907021338n3c0d6d33g11d4934ccc538a94@mail.gmail.com>
> This is very interesting. I recently experienced a similar problem when
> upgrading from 2.6.26-rc6 to 2.6.31-rc1 (torvalds mainline kernel).
>
> I didn't had the time to figure out what was happening, so I went back to
> 2.6.26-rc6. Just for the test, could you try to go back to 2.6.26 and see if
> the problem remains?
Frank! That worked like a charm! I downloaded linux-2.6.26 source from
git.kernel.org, inserted the config options previously mentioned,
compiled ok, keeping U-Boot ramdisk and my DTS same it booted right up
and no more "slow motion" issue.
Thanks! Now I just need to make myself a custom ramdisk.
^ permalink raw reply
* Re: Non-contiguous physical memory on 8572
From: Scott Wood @ 2009-07-02 21:14 UTC (permalink / raw)
To: Aaron Pace; +Cc: linuxppc-dev
In-Reply-To: <bc81dc640907021311y1395ed15l2d50cebb3749c29f@mail.gmail.com>
Aaron Pace wrote:
> In MMU_init of arch/powerpc/mm/init_32.c, where the current code sets
> lmb.memory.cnt to zero, I instead walk through the memory regions and
> call lmb_reserve for each chunk of memory that lies in a 'hole'.
> There are then some minor fixups to make sure that total_memory and
> total_highmem get the right numbers. This small change allows all
> four gigabytes of memory to be accessed and used in my tests.
>
> Am I missing something obvious?
The main downsides that I see are wasted memory for bookkeeping of the
hole (how acceptable this is depends on how large the hole is relative
to the size of RAM -- it's a tradeoff against speed of looking up page
structs), and that the reserved area may still be mapped in the TLB
without the guarded bit set.
-Scott
^ permalink raw reply
* Re: Non-contiguous physical memory on 8572
From: Kumar Gala @ 2009-07-02 21:05 UTC (permalink / raw)
To: Aaron Pace; +Cc: linuxppc-dev
In-Reply-To: <bc81dc640907021311y1395ed15l2d50cebb3749c29f@mail.gmail.com>
On Jul 2, 2009, at 3:11 PM, Aaron Pace wrote:
> Hello,
>
> I wrote to this list quite some time ago concerning a board that has 2
> gigs of ram mapped in at 0x0.0000.0000 - 0x0.7fff.ffff, and a second 2
> gigs of ram at 0x1.0000.0000 - 0x1.7fff.ffff. Kumar responded and
> mentioned that this wasn't currently supported in the powerpc
> architecture. I've had this on my 'curiosity' back burner to take a
> look at for some time.
> I found a little time to look at this, and what I discovered is that
> this seems to actually have been a fairly trivial problem to solve.
> I'd like to get some feedback on the method I used, if possible, to
> see if I've overlooked something blatantly obvious.
>
> In MMU_init of arch/powerpc/mm/init_32.c, where the current code sets
> lmb.memory.cnt to zero, I instead walk through the memory regions and
> call lmb_reserve for each chunk of memory that lies in a 'hole'.
> There are then some minor fixups to make sure that total_memory and
> total_highmem get the right numbers. This small change allows all
> four gigabytes of memory to be accessed and used in my tests.
>
> Am I missing something obvious?
> Would you like this in a patch for 32 or next, or is there a reason
> that this would not be desirable in the powerpc branch?
What you described is one possible solution. However when I was
thinking about support non-contiguous memory I was thinking about
doing at based on CONFIG_DISCONTIGMEM (see include/asm-generic/
memory_model.h). I think ppc64 supports SPARSEMEM which is a
variation on the them.
- k
^ permalink raw reply
* Re: RAMDISK on EP88xc
From: Frank Svendsbøe @ 2009-07-02 20:38 UTC (permalink / raw)
To: Mikhail Zaturenskiy; +Cc: linuxppc-dev, Gary Thomas
In-Reply-To: <97dd5fd20907021142i663de6aavc093fbd6ac5025c@mail.gmail.com>
On Thu, Jul 2, 2009 at 8:42 PM, Mikhail
Zaturenskiy<mzaturenskiy.st@gmail.com> wrote:
>> Just as an intermediate update on the issue, I've made progress and it
>> hangs later down the line, see below:
>> ************************************************************************=
************
>> Using Embedded Planet EP88xC machine description
>> Linux version 2.6.30-rc2-01402-gd4e2f68-dirty (devone@localhost.localdom=
ain) (gc
>> c version 4.2.2) #3 Thu Jul 2 11:00:54 CDT 2009
>> Found initrd at 0xc3dbb000:0xc3f6d056
>> Zone PFN ranges:
>> =A0DMA =A0 =A0 =A00x00000000 -> 0x00004000
>> =A0Normal =A0 0x00004000 -> 0x00004000
>> Movable zone start PFN for each node
>> early_node_map[1] active PFN ranges
>> =A0 =A00: 0x00000000 -> 0x00004000
>> MMU: Allocated 72 bytes of context maps for 16 contexts
>> Built 1 zonelists in Zone order, mobility grouping on. =A0Total pages: 1=
6256
>> Kernel command line: console=3DttyCPM0,9600n8 root=3D/dev/ram loglevel=
=3D7 init=3D/sbin/
>> init
>> NR_IRQS:512
>> PID hash table entries: 256 (order: 8, 1024 bytes)
>> Decrementer Frequency =3D 0x5f5e10
>> clocksource: timebase mult[28000000] shift[22] registered
>> console [ttyCPM0] enabled
>> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
>> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
>> Memory: 60716k/65536k available (2136k kernel code, 4752k reserved, 100k=
data, 9
>> 9k bss, 112k init)
>> SLUB: Genslabs=3D12, HWalign=3D16, Order=3D0-3, MinObjects=3D0, CPUs=3D1=
, Nodes=3D1
>> Calibrating delay loop... 12.39 BogoMIPS (lpj=3D61952)
>> Mount-cache hash table entries: 512
>> net_namespace: 296 bytes
>> NET: Registered protocol family 16
>> bio: create slab <bio-0> at 0
>> NET: Registered protocol family 2
>> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
>> TCP established hash table entries: 2048 (order: 2, 16384 bytes)
>> TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
>> TCP: Hash tables configured (established 2048 bind 2048)
>> TCP reno registered
>> NET: Registered protocol family 1
>> checking if image is initramfs...
>> rootfs image is not initramfs (no cpio magic); looks like an initrd
>> Freeing initrd memory: 1736k freed
>> msgmni has been set to 122
>> io scheduler noop registered
>> io scheduler deadline registered (default)
>> Generic RTC Driver v1.07
>> f0000a80.serial: ttyCPM0 at MMIO 0xc500ea80 (irq =3D 19) is a CPM UART
>> f0000a20.serial: ttyCPM1 at MMIO 0xc5016a20 (irq =3D 29) is a CPM UART
>> brd: module loaded
>> loop: module loaded
>> eth0: fs_enet: 00:00:00:00:00:00
>> eth1: fs_enet: 00:00:00:00:00:00
>> FEC MII Bus: probed
>> fe000000.flash: Found 2 x16 devices at 0x0 in 32-bit bank
>> =A0Amd/Fujitsu Extended Query Table at 0x0040
>> fe000000.flash: CFI does not contain boot bank location. Assuming top.
>> number of CFI chips: 1
>> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
>> TCP cubic registered
>> NET: Registered protocol family 17
>> RPC: Registered udp transport module.
>> RPC: Registered tcp transport module.
>> RAMDISK: gzip image found at block 0
>> VFS: Mounted root (ext2 filesystem) readonly on device 1:0.
>> Freeing unused kernel memory: 112k init
>> ************************************************************************=
************
>>
>> Now searching for cause, looks like it's "init" related...
>>
>
> Wow... I just found out that it's not actually "hanging" at this
> point.. it's just working in "slow motion"... I found out by leaving
> the machine and coming back half an hour later to find additional
> output and eventually even a prompt.
>
Hi Mikhail,
This is very interesting. I recently experienced a similar problem when
upgrading from 2.6.26-rc6 to 2.6.31-rc1 (torvalds mainline kernel).
I didn't had the time to figure out what was happening, so I went back to
2.6.26-rc6. Just for the test, could you try to go back to 2.6.26 and see i=
f
the problem remains?
- Frank
> Here is what's happening:
> *************************************************************************
> RAMDISK: gzip image found at block 0
> VFS: Mounted root (ext2 filesystem) on device 1:0.
> Freeing unused kernel memory: 112k init
>
> <4 minutes pass>
>
> init started: BusyBox v1.7.1 (2008-04-02 09:14:47 MEST)
>
> <2 minutes pass>
>
> starting pid 403, tty '': '/etc/rc.sh'
>
> < etc... >
> *************************************************************************
>
> I've tried a couple different ramdisk images (another one with a much
> older version of busybox), with similar results. Anybody have an idea
> about what's going on here?
>
^ permalink raw reply
* Non-contiguous physical memory on 8572
From: Aaron Pace @ 2009-07-02 20:11 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I wrote to this list quite some time ago concerning a board that has 2
gigs of ram mapped in at 0x0.0000.0000 - 0x0.7fff.ffff, and a second 2
gigs of ram at 0x1.0000.0000 - 0x1.7fff.ffff. Kumar responded and
mentioned that this wasn't currently supported in the powerpc
architecture. I've had this on my 'curiosity' back burner to take a
look at for some time.
I found a little time to look at this, and what I discovered is that
this seems to actually have been a fairly trivial problem to solve.
I'd like to get some feedback on the method I used, if possible, to
see if I've overlooked something blatantly obvious.
In MMU_init of arch/powerpc/mm/init_32.c, where the current code sets
lmb.memory.cnt to zero, I instead walk through the memory regions and
call lmb_reserve for each chunk of memory that lies in a 'hole'.
There are then some minor fixups to make sure that total_memory and
total_highmem get the right numbers. This small change allows all
four gigabytes of memory to be accessed and used in my tests.
Am I missing something obvious?
Would you like this in a patch for 32 or next, or is there a reason
that this would not be desirable in the powerpc branch?
Thanks,
Aaron
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: add locking to mpc5200-psc-ac97 driver
From: michael @ 2009-07-02 19:08 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <20090702175725.15773.37291.stgit@localhost.localdomain>
Hi,
Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> AC97 bus register read/write hooks need to provide locking, but the
> mpc5200-psc-ac97 driver does not. This patch adds a mutex around
> the register access routines.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> sound/soc/fsl/mpc5200_dma.c | 1 +
> sound/soc/fsl/mpc5200_dma.h | 1 +
> sound/soc/fsl/mpc5200_psc_ac97.c | 13 ++++++++++++-
> 3 files changed, 14 insertions(+), 1 deletions(-)
>
>
> diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
> index efec33a..f0a2d40 100644
> --- a/sound/soc/fsl/mpc5200_dma.c
> +++ b/sound/soc/fsl/mpc5200_dma.c
> @@ -456,6 +456,7 @@ int mpc5200_audio_dma_create(struct of_device *op)
> return -ENODEV;
>
> spin_lock_init(&psc_dma->lock);
> + mutex_init(&psc_dma->mutex);
> psc_dma->id = be32_to_cpu(*prop);
> psc_dma->irq = irq;
> psc_dma->psc_regs = regs;
> diff --git a/sound/soc/fsl/mpc5200_dma.h b/sound/soc/fsl/mpc5200_dma.h
> index 2000803..8d396bb 100644
> --- a/sound/soc/fsl/mpc5200_dma.h
> +++ b/sound/soc/fsl/mpc5200_dma.h
> @@ -55,6 +55,7 @@ struct psc_dma {
> unsigned int irq;
> struct device *dev;
> spinlock_t lock;
> + struct mutex mutex;
> u32 sicr;
> uint sysclk;
> int imr;
> diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c
> index 9b8503f..7eb5499 100644
> --- a/sound/soc/fsl/mpc5200_psc_ac97.c
> +++ b/sound/soc/fsl/mpc5200_psc_ac97.c
> @@ -34,11 +34,14 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg)
> int status;
> unsigned int val;
>
> + mutex_lock(&psc_dma->mutex);
> +
> /* Wait for command send status zero = ready */
> status = spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) &
> MPC52xx_PSC_SR_CMDSEND), 100, 0);
> if (status == 0) {
> pr_err("timeout on ac97 bus (rdy)\n");
> + mutex_unlock(&psc_dma->mutex);
> return -ENODEV;
>
maybe define an err variable and and a goto out.
Michael
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: add locking to mpc5200-psc-ac97 driver
From: Jon Smirl @ 2009-07-02 19:06 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <20090702175725.15773.37291.stgit@localhost.localdomain>
On Thu, Jul 2, 2009 at 1:57 PM, Grant Likely<grant.likely@secretlab.ca> wro=
te:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> AC97 bus register read/write hooks need to provide locking, but the
> mpc5200-psc-ac97 driver does not. =A0This patch adds a mutex around
> the register access routines.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Jon Smirl <jonsmirl@gmail.com>
> ---
>
> =A0sound/soc/fsl/mpc5200_dma.c =A0 =A0 =A0| =A0 =A01 +
> =A0sound/soc/fsl/mpc5200_dma.h =A0 =A0 =A0| =A0 =A01 +
> =A0sound/soc/fsl/mpc5200_psc_ac97.c | =A0 13 ++++++++++++-
> =A03 files changed, 14 insertions(+), 1 deletions(-)
>
>
> diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
> index efec33a..f0a2d40 100644
> --- a/sound/soc/fsl/mpc5200_dma.c
> +++ b/sound/soc/fsl/mpc5200_dma.c
> @@ -456,6 +456,7 @@ int mpc5200_audio_dma_create(struct of_device *op)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -ENODEV;
>
> =A0 =A0 =A0 =A0spin_lock_init(&psc_dma->lock);
> + =A0 =A0 =A0 mutex_init(&psc_dma->mutex);
> =A0 =A0 =A0 =A0psc_dma->id =3D be32_to_cpu(*prop);
> =A0 =A0 =A0 =A0psc_dma->irq =3D irq;
> =A0 =A0 =A0 =A0psc_dma->psc_regs =3D regs;
> diff --git a/sound/soc/fsl/mpc5200_dma.h b/sound/soc/fsl/mpc5200_dma.h
> index 2000803..8d396bb 100644
> --- a/sound/soc/fsl/mpc5200_dma.h
> +++ b/sound/soc/fsl/mpc5200_dma.h
> @@ -55,6 +55,7 @@ struct psc_dma {
> =A0 =A0 =A0 =A0unsigned int irq;
> =A0 =A0 =A0 =A0struct device *dev;
> =A0 =A0 =A0 =A0spinlock_t lock;
> + =A0 =A0 =A0 struct mutex mutex;
> =A0 =A0 =A0 =A0u32 sicr;
> =A0 =A0 =A0 =A0uint sysclk;
> =A0 =A0 =A0 =A0int imr;
> diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc=
_ac97.c
> index 9b8503f..7eb5499 100644
> --- a/sound/soc/fsl/mpc5200_psc_ac97.c
> +++ b/sound/soc/fsl/mpc5200_psc_ac97.c
> @@ -34,11 +34,14 @@ static unsigned short psc_ac97_read(struct snd_ac97 *=
ac97, unsigned short reg)
> =A0 =A0 =A0 =A0int status;
> =A0 =A0 =A0 =A0unsigned int val;
>
> + =A0 =A0 =A0 mutex_lock(&psc_dma->mutex);
> +
> =A0 =A0 =A0 =A0/* Wait for command send status zero =3D ready */
> =A0 =A0 =A0 =A0status =3D spin_event_timeout(!(in_be16(&psc_dma->psc_regs=
->sr_csr.status) &
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MPC52xx_PS=
C_SR_CMDSEND), 100, 0);
> =A0 =A0 =A0 =A0if (status =3D=3D 0) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pr_err("timeout on ac97 bus (rdy)\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mutex_unlock(&psc_dma->mutex);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -ENODEV;
> =A0 =A0 =A0 =A0}
>
> @@ -54,16 +57,19 @@ static unsigned short psc_ac97_read(struct snd_ac97 *=
ac97, unsigned short reg)
> =A0 =A0 =A0 =A0if (status =3D=3D 0) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pr_err("timeout on ac97 read (val) %x\n",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in_be16(&p=
sc_dma->psc_regs->sr_csr.status));
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mutex_unlock(&psc_dma->mutex);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -ENODEV;
> =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0/* Get the data */
> =A0 =A0 =A0 =A0val =3D in_be32(&psc_dma->psc_regs->ac97_data);
> =A0 =A0 =A0 =A0if (((val >> 24) & 0x7f) !=3D reg) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pr_err("reg echo error on ac97 read\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mutex_unlock(&psc_dma->mutex);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -ENODEV;
> =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0val =3D (val >> 8) & 0xffff;
>
> + =A0 =A0 =A0 mutex_unlock(&psc_dma->mutex);
> =A0 =A0 =A0 =A0return (unsigned short) val;
> =A0}
>
> @@ -72,16 +78,21 @@ static void psc_ac97_write(struct snd_ac97 *ac97,
> =A0{
> =A0 =A0 =A0 =A0int status;
>
> + =A0 =A0 =A0 mutex_lock(&psc_dma->mutex);
> +
> =A0 =A0 =A0 =A0/* Wait for command status zero =3D ready */
> =A0 =A0 =A0 =A0status =3D spin_event_timeout(!(in_be16(&psc_dma->psc_regs=
->sr_csr.status) &
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MPC52xx_PS=
C_SR_CMDSEND), 100, 0);
> =A0 =A0 =A0 =A0if (status =3D=3D 0) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pr_err("timeout on ac97 bus (write)\n");
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0/* Write data */
> =A0 =A0 =A0 =A0out_be32(&psc_dma->psc_regs->ac97_cmd,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0((reg & 0x7f) << 24) | (va=
l << 8));
> +
> + out:
> + =A0 =A0 =A0 mutex_unlock(&psc_dma->mutex);
> =A0}
>
> =A0static void psc_ac97_warm_reset(struct snd_ac97 *ac97)
>
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox