* Re: Wrong looking statement in cpm_common.c
From: Scott Wood @ 2009-05-26 17:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1243224033.24376.18.camel@pasglop>
On Mon, May 25, 2009 at 02:00:33PM +1000, Benjamin Herrenschmidt wrote:
> Hi Scott !
>
> There's this pearl in cpm_common.c :
>
> void __init udbg_init_cpm(void)
> {
> if (cpm_udbg_txdesc) {
> #ifdef CONFIG_CPM2
> setbat(1, 0xf0000000, 0xf0000000, 1024*1024, PAGE_KERNEL_NCG);
> #endif
> udbg_putc = udbg_putc_cpm;
> }
> }
>
> Now, last I looked, 0xf0000000 (virtual) lands about right in the middle
> of the vmalloc space... so unless there's code somewhere that I missed
> that reserves that region of virtual space for use by that crap above,
> I think somebody is in trouble :-)
:-(
> Additionally, that's the last user of setbat that I can find outside
> of the linear mapping setup proper, so scott, once you've fixed that
> I'll happily make setbat static once for all. We -can- still provide
> a facility for using BATs for early ioremap's but that should be done
> properly, not by whacking setbat with random hard wired virtual
> addresses.
Any suggestions for how to do it properly?
-Scott
^ permalink raw reply
* Re: drivers/video/logo/logo_linux_mono.c build error
From: Andrew Morton @ 2009-05-26 17:26 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: sfr, linuxppc-dev
In-Reply-To: <alpine.LRH.2.00.0905261352140.4897@vixen.sonytel.be>
On Tue, 26 May 2009 13:52:34 +0200 (CEST) Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > But logo_linux_mono_data is referenced by
> >
> > const struct linux_logo logo_linux_mono __initconst = {
> > .type = LINUX_LOGO_MONO,
> > .width = 80,
> > .height = 80,
> > .data = logo_linux_mono_data
> > };
> >
> > only, which is also __initconst? Where does the section type conflict come
> > from?
>
> Do you have any follow-up info on this one?
Nope, sorry. I've been offline for over a week and I only build
powerpc kernels occasionally.
If it's still there, I'll hit it again and I'll take a closer look.
^ permalink raw reply
* Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE
From: Albert Herranz @ 2009-05-26 17:13 UTC (permalink / raw)
To: linuxppc-dev list, Benjamin Herrenschmidt; +Cc: Kumar Gala, Ilya Yanok
--- El lun, 25/5/09, Benjamin Herrenschmidt <benh@kernel.crashing.org> escr=
ibi=F3:=0A=0A> (Please, Kumar, have a good look,=0A> especially my change t=
o FIXMAP_TOP,=0A> was there any reason it wasn't a constant in the first=0A=
> place ?)=0A> =0A> This is going to .30 if nobody hollers. I've done some=
=0A> testing here=0A> and it seems to be fine, but more eyes at this stage =
are=0A> much welcome.=0A=0ATested-by: Albert Herranz <albert_herranz@yahoo.=
es>=0A=0ABoots fine and works on the Nintendo Wii.=0A=0AThanks,=0AAlbert=0A=
=0A=0A=0A=0A
^ permalink raw reply
* Re: [alsa-devel] [PATCH V4 2/5] Main rewite of the mpc5200 audio DMA code
From: Timur Tabi @ 2009-05-26 17:08 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, Mark Brown
In-Reply-To: <9e4733910905260953i6337f8a9xc3cd1ff490cd3540@mail.gmail.com>
On Tue, May 26, 2009 at 11:53 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> Put in the V5 version this one has this in the h file:
>
> -int psc_dma_trigger(struct snd_pcm_substream *substream, int cmd,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct snd_soc_dai *=
dai);
> +/* whack this after Timur's patch is merged in to
> arch/powerpc/include/asm/delay.h */
> +#define spin_event_timeout(condition, timeout, delay, rc) =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 \
> +{ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 \
> + =A0 =A0 =A0 unsigned long __loops =3D tb_ticks_per_usec * timeout; =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0\
> + =A0 =A0 =A0 unsigned long __start =3D get_tbl(); =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> + =A0 =A0 =A0 while ((rc =3D (condition)) && (tb_ticks_since(__start) <=
=3D __loops)) \
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (delay) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(delay); =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 else =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
\
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cpu_relax(); =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> +}
> +/* whack this after Timur's patch is merged in to
> arch/powerpc/include/asm/delay.h */
It won't be that simple. V9 of my patch changes the number of
parameters, so not only will you need to whack this copy of the macro,
you'll also need to change the callers.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/2 v8] powerpc: introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-05-26 17:03 UTC (permalink / raw)
To: Geoff Thorpe; +Cc: linuxppc-dev, smaclennan
In-Reply-To: <4A1C16DF.9090802@freescale.com>
Geoff Thorpe wrote:
> So from this user's perspective (FWIW), it would come as a surprise if
> the return value reflected the evaluated expression rather than what
> happened w.r.t. the spin/timeout.
It shouldn't come as a surprise because I've thoroughly documented the behavior. I also think returning the actual value of the expression is better than a return code. Remember, the primary purpose of this macro is to wait for a hardware register to change. Contrast this to wait_event_xxx, which usually queries a variable. Therefore, the hardware register may set multiple bits. For instance, you could do this:
ret = spin_event_timeout(in_be32(x) & 0x14, ...);
if (ret & 0x10)
do something here
if (ret & 0x04)
do something else here
I think the ability to do this is more important than making the code as similar as possible to wait_event_xxx.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [alsa-devel] [PATCH V4 2/5] Main rewite of the mpc5200 audio DMA code
From: Grant Likely @ 2009-05-26 16:56 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, Mark Brown, timur
In-Reply-To: <9e4733910905260953i6337f8a9xc3cd1ff490cd3540@mail.gmail.com>
On Tue, May 26, 2009 at 10:53 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Tue, May 26, 2009 at 12:51 PM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
>> On Tue, May 26, 2009 at 5:01 AM, Mark Brown
>> <broonie@opensource.wolfsonmicro.com> wrote:
>>> On Mon, May 25, 2009 at 06:15:09PM -0400, Jon Smirl wrote:
>>>> Rewrite the mpc5200 audio DMA code to support both I2S and AC97.
>>>>
>>>> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
>>>
>>> Grant, I'm OK with that if you are?
>>
>> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> Put in the V5 version this one has this in the h file:
>
> -int psc_dma_trigger(struct snd_pcm_substream *substream, int cmd,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct snd_soc_dai *=
dai);
> +/* whack this after Timur's patch is merged in to
> arch/powerpc/include/asm/delay.h */
> +#define spin_event_timeout(condition, timeout, delay, rc) =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 \
> +{ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 \
> + =A0 =A0 =A0 unsigned long __loops =3D tb_ticks_per_usec * timeout; =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0\
> + =A0 =A0 =A0 unsigned long __start =3D get_tbl(); =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> + =A0 =A0 =A0 while ((rc =3D (condition)) && (tb_ticks_since(__start) <=
=3D __loops)) \
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (delay) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(delay); =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 else =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
\
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cpu_relax(); =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> +}
> +/* whack this after Timur's patch is merged in to
> arch/powerpc/include/asm/delay.h */
sure, no problem if it will grease the merge.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [alsa-devel] [PATCH V4 2/5] Main rewite of the mpc5200 audio DMA code
From: Jon Smirl @ 2009-05-26 16:53 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, Mark Brown, timur
In-Reply-To: <fa686aa40905260951g5115007fo3ef5eb1fb90998f3@mail.gmail.com>
On Tue, May 26, 2009 at 12:51 PM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Tue, May 26, 2009 at 5:01 AM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
>> On Mon, May 25, 2009 at 06:15:09PM -0400, Jon Smirl wrote:
>>> Rewrite the mpc5200 audio DMA code to support both I2S and AC97.
>>>
>>> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
>>
>> Grant, I'm OK with that if you are?
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Put in the V5 version this one has this in the h file:
-int psc_dma_trigger(struct snd_pcm_substream *substream, int cmd,
- struct snd_soc_dai *dai);
+/* whack this after Timur's patch is merged in to
arch/powerpc/include/asm/delay.h */
+#define spin_event_timeout(condition, timeout, delay, rc) \
+{ \
+ unsigned long __loops = tb_ticks_per_usec * timeout; \
+ unsigned long __start = get_tbl(); \
+ while ((rc = (condition)) && (tb_ticks_since(__start) <= __loops)) \
+ if (delay) \
+ udelay(delay); \
+ else \
+ cpu_relax(); \
+}
+/* whack this after Timur's patch is merged in to
arch/powerpc/include/asm/delay.h */
>
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [alsa-devel] [PATCH V4 2/5] Main rewite of the mpc5200 audio DMA code
From: Grant Likely @ 2009-05-26 16:51 UTC (permalink / raw)
To: Mark Brown; +Cc: linuxppc-dev, alsa-devel, timur
In-Reply-To: <20090526110120.GA8969@sirena.org.uk>
On Tue, May 26, 2009 at 5:01 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, May 25, 2009 at 06:15:09PM -0400, Jon Smirl wrote:
>> Rewrite the mpc5200 audio DMA code to support both I2S and AC97.
>>
>> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
>
> Grant, I'm OK with that if you are?
Acked-by: Grant Likely <grant.likely@secretlab.ca>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/2 v8] powerpc: introduce macro spin_event_timeout()
From: Jon Smirl @ 2009-05-26 16:27 UTC (permalink / raw)
To: Geoff Thorpe; +Cc: linuxppc-dev, Timur Tabi, smaclennan
In-Reply-To: <4A1C16DF.9090802@freescale.com>
On Tue, May 26, 2009 at 12:20 PM, Geoff Thorpe
<Geoff.Thorpe@freescale.com> wrote:
> Timur Tabi wrote:
>> On Mon, May 25, 2009 at 12:46 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>>
>>> I just tried using this. The !rc has the effect of making the error
>>> return be zero instead the normal not zero.
>>
>> You're confused. =A0It's not a "return code", it's a return value. =A0I
>> guess I should have called the parameter "ret" instead of "rc", but I
>> didn't expect people to get confused.
>>
>> 'rc' is the value of the expression when the loop terminates. =A0That's
>> what makes the most sense, because the developer will want to know
>> what that value is. =A0If you're expression happens to rely on negative
>> logic (e.g. wait until a bit is cleared), then of course it's going to
>> appear "backwards" when you test it.
>
> I've just been going through some hassles associated with wait_event
> variants and their return codes.
>
> Eg. wait_event_interruptible()'s return value is documented as; "The
> function will return -ERESTARTSYS if it was interrupted by a signal and
> 0 if @condition evaluated to true." And wait_event_timeout()'s return
> value is; "The function returns 0 if the @timeout elapsed, and the
> remaining jiffies if the condition evaluated to true before the timeout
> elapsed."
>
> In all cases it seems, they don't return the what the expression
> evaluates to, but instead return an indication about the wait outcome.
> This is why I've taken to doing things like;
> =A0 wait_event_***(queue, !(ret =3D try_something()));
That's a good trick, if you want the result of the condition pass the
assignment in.
That frees up the return value to indicate the error of the time out expiri=
ng.
I'd really like to keep a consistent if(rc!=3D0)error; model.
> So from this user's perspective (FWIW), it would come as a surprise if
> the return value reflected the evaluated expression rather than what
> happened w.r.t. the spin/timeout.
>
> Cheers,
> Geoff
>
>
>
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 1/2 v8] powerpc: introduce macro spin_event_timeout()
From: Geoff Thorpe @ 2009-05-26 16:20 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, smaclennan
In-Reply-To: <ed82fe3e0905252027y198e78ct821753acacb1bdb1@mail.gmail.com>
Timur Tabi wrote:
> On Mon, May 25, 2009 at 12:46 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>
>> I just tried using this. The !rc has the effect of making the error
>> return be zero instead the normal not zero.
>
> You're confused. It's not a "return code", it's a return value. I
> guess I should have called the parameter "ret" instead of "rc", but I
> didn't expect people to get confused.
>
> 'rc' is the value of the expression when the loop terminates. That's
> what makes the most sense, because the developer will want to know
> what that value is. If you're expression happens to rely on negative
> logic (e.g. wait until a bit is cleared), then of course it's going to
> appear "backwards" when you test it.
I've just been going through some hassles associated with wait_event
variants and their return codes.
Eg. wait_event_interruptible()'s return value is documented as; "The
function will return -ERESTARTSYS if it was interrupted by a signal and
0 if @condition evaluated to true." And wait_event_timeout()'s return
value is; "The function returns 0 if the @timeout elapsed, and the
remaining jiffies if the condition evaluated to true before the timeout
elapsed."
In all cases it seems, they don't return the what the expression
evaluates to, but instead return an indication about the wait outcome.
This is why I've taken to doing things like;
wait_event_***(queue, !(ret = try_something()));
So from this user's perspective (FWIW), it would come as a surprise if
the return value reflected the evaluated expression rather than what
happened w.r.t. the spin/timeout.
Cheers,
Geoff
^ permalink raw reply
* [PATCH 1/2] [PATCH 1/2 v9] powerpc: introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-05-26 15:21 UTC (permalink / raw)
To: linuxppc-dev, galak, benh, jonsmirl, arnd, geert.uytterhoeven
In-Reply-To: <1243351302-32062-1-git-send-email-timur@freescale.com>
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns the result of the condition when the loop
was terminated.
This primary purpose of this macro is to poll on a hardware register until a
status bit changes. The timeout ensures that the loop still terminates if the
bit doesn't change as expected. This macro makes it easier for driver
developers to perform this kind of operation properly.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
v9: changed the macro to return the value, instead of having it passed in
arch/powerpc/include/asm/delay.h | 36 ++++++++++++++++++++++++++++++++++++
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/delay.h b/arch/powerpc/include/asm/delay.h
index f9200a6..1e2eb41 100644
--- a/arch/powerpc/include/asm/delay.h
+++ b/arch/powerpc/include/asm/delay.h
@@ -2,8 +2,11 @@
#define _ASM_POWERPC_DELAY_H
#ifdef __KERNEL__
+#include <asm/time.h>
+
/*
* Copyright 1996, Paul Mackerras.
+ * Copyright (C) 2009 Freescale Semiconductor, Inc. All rights reserved.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -30,5 +33,38 @@ extern void udelay(unsigned long usecs);
#define mdelay(n) udelay((n) * 1000)
#endif
+/**
+ * spin_event_timeout - spin until a condition gets true or a timeout elapses
+ * @condition: a C expression to evalate
+ * @timeout: timeout, in microseconds
+ * @delay: the number of microseconds to delay between each evaluation of
+ * @condition
+ *
+ * The process spins until the condition evaluates to true (non-zero) or the
+ * timeout elapses. The return value of this macro is the value of
+ * @condition when the loop terminates. This allows you to determine the cause
+ * of the loop terminates. If the return value is zero, then you know a
+ * timeout has occurred.
+ *
+ * This primary purpose of this macro is to poll on a hardware register
+ * until a status bit changes. The timeout ensures that the loop still
+ * terminates even if the bit never changes. The delay is for devices that
+ * need a delay in between successive reads.
+ *
+ * gcc will optimize out the if-statement if @delay is a constant.
+ */
+#define spin_event_timeout(condition, timeout, delay) \
+({ \
+ typeof(condition) __ret; \
+ unsigned long __loops = tb_ticks_per_usec * timeout; \
+ unsigned long __start = get_tbl(); \
+ while (!(__ret = (condition)) && (tb_ticks_since(__start) <= __loops)) \
+ if (delay) \
+ udelay(delay); \
+ else \
+ cpu_relax(); \
+ __ret; \
+})
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DELAY_H */
--
1.6.0.6
^ permalink raw reply related
* [PATCH 2/2] [PATCH 2/2 v2] qe: add polling timeout to qe_issue_cmd()
From: Timur Tabi @ 2009-05-26 15:21 UTC (permalink / raw)
To: linuxppc-dev, galak, benh, jonsmirl, arnd, geert.uytterhoeven
In-Reply-To: <1243351302-32062-2-git-send-email-timur@freescale.com>
The qe_issue_cmd() function (Freescale PowerPC QUICC Engine library) polls on
a register until a status bit changes, but does not include a timeout to
handle the situation if the bit never changes. Change the code to use the new
spin_event_timeout() macro, which simplifies polling on a register without
a timeout.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This patch depends on my previous patch, "powerpc: introduce macro
spin_event_timeout()".
arch/powerpc/sysdev/qe_lib/qe.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 01bce37..05bdd43 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -111,6 +111,7 @@ int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input)
{
unsigned long flags;
u8 mcn_shift = 0, dev_shift = 0;
+ u32 ret;
spin_lock_irqsave(&qe_lock, flags);
if (cmd == QE_RESET) {
@@ -138,11 +139,13 @@ int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input)
}
/* wait for the QE_CR_FLG to clear */
- while(in_be32(&qe_immr->cp.cecr) & QE_CR_FLG)
- cpu_relax();
+ ret = spin_event_timeout((in_be32(&qe_immr->cp.cecr) & QE_CR_FLG) == 0,
+ 100, 0);
+ /* On timeout (e.g. failure), the expression will be false (ret == 0),
+ otherwise it will be true (ret == 1). */
spin_unlock_irqrestore(&qe_lock, flags);
- return 0;
+ return ret == 1;
}
EXPORT_SYMBOL(qe_issue_cmd);
--
1.6.0.6
^ permalink raw reply related
* [PATCH 0/2] [V2] introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-05-26 15:21 UTC (permalink / raw)
To: linuxppc-dev, galak, benh, jonsmirl, arnd, geert.uytterhoeven
Introduce the spin_event_timeout() macro, and update the QE library to use it.
This version changes 'ret' to a return value of the macro instead of a
variable that's passed as a parameter.
^ permalink raw reply
* RE: Initialize DBCR0 for PPC440 targets
From: John Linn @ 2009-05-26 15:11 UTC (permalink / raw)
To: srikanth krishnakar; +Cc: Linuxppc-dev
In-Reply-To: <6213bc560905242351r7682dcb2m898beef8b334e010@mail.gmail.com>
> -----Original Message-----
> From: srikanth krishnakar [mailto:skrishnakar@gmail.com]
> Sent: Monday, May 25, 2009 12:51 AM
> To: John Linn
> Cc: Linuxppc-dev@ozlabs.org
> Subject: Re: Initialize DBCR0 for PPC440 targets
> =
> Hi John,
> =
> I am not finding any conclusion of the plan to add DBCR0
> initialization code to head_44x.S after this discussion :
There was no conclusion and I haven't had time yet to chase it further.
> =
> http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049=
044.html#a23049044
> =
> Can you please comment ?
> =
> Thanks,
> -Srikanth Krishnakar
> =
> On Mon, May 25, 2009 at 12:09 PM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
> > On Mon, May 25, 2009 at 12:30 AM, srikanth krishnakar
> > <skrishnakar@gmail.com> wrote:
> >> Hello Grant,
> >>
> >> Is there any conclusion of the below discussion:
> >>
> >> http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23=
049044.html
> >>
> >> Xilinx target (virtex5) hangs (while running GDBServer & KGDB) without=
> >> the DBCR0 initialization.
> >>
> >> Can you please comment on this ?
> >
> > IIRC, John Linn was hacking on a patch. =A0Search the mailing list
> > archives for DBCR0.
> >
> > g.
> >
> > --
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> >
> =
> =
> =
> --
> "The Good You Do, The Best You GET"
> =
> Regards
> Srikanth Krishnakar
> **********************
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [alsa-devel] [PATCH V5 1/5] powerpc: introduce macro spin_event_timeout()
From: Mark Brown @ 2009-05-26 14:53 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, timur
In-Reply-To: <9e4733910905260612v40a70ad8haeb4c916a1a758b5@mail.gmail.com>
On Tue, May 26, 2009 at 09:12:10AM -0400, Jon Smirl wrote:
> On Tue, May 26, 2009 at 9:03 AM, Mark Brown
> > As previously mentioned you need to submit any changes you want to make
> > here as incremental patches against the PowerPC tree rather than as an
> > entire new patch. ?If you are forwarding on copies of the patch you
> > really ought to preserve Timur's authorship too with a From line in the
> > mail.
> I have reverted back to TImur's original patch so you can just drop
> this patch if that is easier for you.
> You'll just need to coordinate the landing so that things land in the
> right order.
Like I say, since it's a new driver I'm just going to ignore the
ordering since it'll sort itself out in the merge window and we're
rather close to that. Worst case something that doesn't build isn't
that much different from something that isn't there in terms of
usability.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
From: Wolfgang Grandegger @ 2009-05-26 14:23 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, devicetree-discuss, arnd, netdev
In-Reply-To: <20090526.022508.238274281.davem@davemloft.net>
David Miller wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Tue, 26 May 2009 10:10:30 +0100
>
>> On Monday 25 May 2009, Wolfgang Grandegger wrote:
>>>> Right, that makes sense. However, most drivers use the field to store the
>>>> physical address, not the iomap token. Maybe there should be a new field
>>>> in struct sja1000_priv for the virtual address, but that would be a change
>>>> to the base driver, not just to the OF portion.
>>> Is that common practice? If yes, I will add a member to store the
>>> virtual address to struct sja1000_priv.
>> I grepped through the network driver for usage of ->base_addr, and
>> it's somewhat inconsistent. The majority of the users use it for
>> a physical address, but there are also a few that use it for the
>> __iomem token.
>>
>> Casts between unsigned long and qualified (__iomem, __user, const, ...)
>> pointers do not cause a warning, but can easily lead to bugs when
>> another user casts to an unqualified pointer.
>
> It's such a baroque thing, there is no reason to set it at all if you
> ask me. It's only use is to allow ISA and similar primitive bus
> devices to have their I/O ports changed via ifconfig.
OK, I see, there are good reasons not to (mis-)use dev->base_addr. I
will prepare a patch for the SJA1000 CAN drivers.
Wolfgang.
^ permalink raw reply
* Re: [PATCH V4 1/5] The macro spin_event_timeout() takes a condition and timeout value
From: Timur Tabi @ 2009-05-26 14:20 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: alsa-devel, linuxppc-dev, Geert Uytterhoeven, broonie
In-Reply-To: <200905261349.49832.arnd@arndb.de>
Arnd Bergmann wrote:
> On Tuesday 26 May 2009, Geert Uytterhoeven wrote:
>> However, you can still improve useability by making the macro return the rc,
>> instead of letting the caller pass it, cfr. wait_event_timeout() and friends.
I had that originally, but somewhere during the seven revisions of my macro, it got lost.
I'll post a v9 soon. This version will take 3 parameters and return __ret, so Jon will need to change his code (sorry).
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH V5 3/5] AC97 driver for mpc5200
From: Timur Tabi @ 2009-05-26 14:09 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <20090526123410.17472.15251.stgit@terra>
Jon Smirl wrote:
> +static void psc_ac97_warm_reset(struct snd_ac97 *ac97)
> +{
> + int rc;
> + struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs;
> +
> + out_be32(®s->sicr, psc_dma->sicr | MPC52xx_PSC_SICR_AWR);
> + spin_event_timeout(0, 3, 0, rc);
I still think you should use udelay() here. spin_event_timeout(<constant>) will just reduce to a udelay() call anyway. In addition, there's no "event" that you're waiting for.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH V5 1/5] powerpc: introduce macro spin_event_timeout()
From: Jon Smirl @ 2009-05-26 13:12 UTC (permalink / raw)
To: Mark Brown; +Cc: linuxppc-dev, alsa-devel, timur
In-Reply-To: <20090526130301.GE8969@sirena.org.uk>
On Tue, May 26, 2009 at 9:03 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Tue, May 26, 2009 at 08:34:06AM -0400, Jon Smirl wrote:
>> The macro spin_event_timeout() takes a condition and timeout value
>> (in microseconds) as parameters. =A0It spins until either the condition =
is true
>> or the timeout expires. =A0It returns the result of the condition when t=
he loop
>> was terminated.
>
> As previously mentioned you need to submit any changes you want to make
> here as incremental patches against the PowerPC tree rather than as an
> entire new patch. =A0If you are forwarding on copies of the patch you
> really ought to preserve Timur's authorship too with a From line in the
> mail.
I have reverted back to TImur's original patch so you can just drop
this patch if that is easier for you.
You'll just need to coordinate the landing so that things land in the
right order.
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH V5 1/5] powerpc: introduce macro spin_event_timeout()
From: Mark Brown @ 2009-05-26 13:03 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, timur
In-Reply-To: <20090526123406.17472.79948.stgit@terra>
On Tue, May 26, 2009 at 08:34:06AM -0400, Jon Smirl wrote:
> The macro spin_event_timeout() takes a condition and timeout value
> (in microseconds) as parameters. It spins until either the condition is true
> or the timeout expires. It returns the result of the condition when the loop
> was terminated.
As previously mentioned you need to submit any changes you want to make
here as incremental patches against the PowerPC tree rather than as an
entire new patch. If you are forwarding on copies of the patch you
really ought to preserve Timur's authorship too with a From line in the
mail.
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Ian Campbell @ 2009-05-26 12:51 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: FUJITA Tomonori, linuxppc-dev@ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <4A173B72.5000201@goop.org>
On Fri, 2009-05-22 at 19:55 -0400, Jeremy Fitzhardinge wrote:
> Ian Campbell wrote:
> > On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote:
> >
> >> I can work with that, but it's going to be a bit inefficient, as I
> >> actually need the dma_addr_t, not the phys_addr_t, so I'll have to
> >> convert. In every case, this is a conversion I've already done and
> >> that I need in the calling code as well.
> >>
> >
> > Does
> >
> > dma_addr_t dma_map_range(struct device *hwdev, phys_addr_t addr,
> > size_t size);
> >
> > work for you?
> >
> > If the range does not need mapping then it returns the dma address, if
> > you needed to calculate the dma address anyway to figure out if mapping
> > is required then this is fine. If the range does need mapping then it
> > returns NULL.
> >
>
> My only concern is whether dma_addr_t == 0 is actually equivalent to
> NULL. That is, can we be sure that address 0 will never be used?
It seems not, ~0UL might have been an option, but...
> Taking dma_alloc_coherent as a model, we could have something like:
>
> int dma_map_range(struct device *hwdev, phys_addr_t addr, size_t size, dma_addr_t *dma_addrp);
>
>
> where *dma_addrp is set if the function returns success (bool return
> type might be clearer).
... this sounds like a good idea to me.
Ian.
^ permalink raw reply
* Re: [PATCH v5 0/4] Series short description
From: Roderick Colenbrander @ 2009-05-26 12:50 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <c8485d470905260541t65e35d86l8c676a2b016c0ff8@mail.gmail.com>
On Tue, May 26, 2009 at 2:41 PM, Roderick Colenbrander
<thunderbird2k@gmail.com> wrote:
> On Mon, May 25, 2009 at 10:47 PM, Roderick Colenbrander
> <thunderbird2k@gmail.com> wrote:
>> On Mon, May 25, 2009 at 4:41 PM, Grant Likely <grant.likely@secretlab.ca=
> wrote:
>>> Repost of ml510 series. =A0This time against 2.6.30-rc7 and with the .d=
ts
>>> file included.
>>>
>>> g.
>>>
>>> --
>>> Grant Likely, B.Sc. P.Eng.
>>> Secret Lab Technologies Ltd.
>>>
>>
>> Thanks, I will check it out tomorrow.
>>
>> Roderick
>>
>
> Hi,
>
> I have tested the ml510 patches. The code works properly but I had to
> make a few slight changes to get it functioning. The most important
> change was in xilinx_intc driver. For level interrupts the ack command
> was removed during the xilinx_intc rewrite which caused a null pointer
> derefence in the i8259 cascade code. I have now changed it to:
> /* Let xilinx_intc end the interrupt */
> desc->chip->mask(irq);
> desc->chip->unmask(irq);
>
> This seems to work properly. Further the driver now also has proper
> level support, so i think my dts file has some errors. The pci
> interrupts (a/b/c/d) are all active low, so they need to be changed to
> '3' for the sense level. Further the i8259 is active high which needs
> to be set to 2 instead of 3.
>
> Further I have tested the need for the outb to 0x4d0/0x4d1. Removing
> those lines causes interrupt timeouts and ide won't function.
> Freescale does the same in arch/powerpc/platforms/fsl_uli1575.c (which
> is a much newer version of this chipset) in quirk_final_uli1575 but
> they are doing it for some more interrupts. I think this code should
> be done using a similar quirk in virtex_ml510.c
>
> Roderick
>
I have just tested the following and it seemed to work fine.
static void __devinit ml510_ali_quirk_final(struct pci_dev *dev)
{
/* Program irq 7 (usb/audio), 14/15 (ide) to level sensitive */
/* This looks like a dirty hack to me --gcl */
outb(0xc0, 0x4d0);
outb(0xc0, 0x4d1);
}
DECLARE_PCI_FIXUP_FINAL(0x10b9, 0x1533, ml510_ali_quirk_final);
I'm not sure what is preferred level or edge interrupts as the ide
controller can be programmed to both (I would just have to write to
config register 0x44 and 0x75).
Roderick
^ permalink raw reply
* Re: [PATCH V4 1/5] The macro spin_event_timeout() takes a condition and timeout value
From: Arnd Bergmann @ 2009-05-26 12:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geert Uytterhoeven, alsa-devel, Timur Tabi, broonie
In-Reply-To: <alpine.LRH.2.00.0905261348160.4897@vixen.sonytel.be>
On Tuesday 26 May 2009, Geert Uytterhoeven wrote:
> However, you can still improve useability by making the macro return the rc,
> instead of letting the caller pass it, cfr. wait_event_timeout() and friends.
Either that, or it should at least use the do { ... } while (0) construct
to make the macro a statement. All multi-line macros need to either
use ({ ... }) or do { ... } while (0) to make sure they behave well.
Arnd <><
^ permalink raw reply
* Re: [PATCH v5 0/4] Series short description
From: Roderick Colenbrander @ 2009-05-26 12:41 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <c8485d470905251347m4e3b7022u4f0324dfc154cfb2@mail.gmail.com>
On Mon, May 25, 2009 at 10:47 PM, Roderick Colenbrander
<thunderbird2k@gmail.com> wrote:
> On Mon, May 25, 2009 at 4:41 PM, Grant Likely <grant.likely@secretlab.ca>=
wrote:
>> Repost of ml510 series. =A0This time against 2.6.30-rc7 and with the .dt=
s
>> file included.
>>
>> g.
>>
>> --
>> Grant Likely, B.Sc. P.Eng.
>> Secret Lab Technologies Ltd.
>>
>
> Thanks, I will check it out tomorrow.
>
> Roderick
>
Hi,
I have tested the ml510 patches. The code works properly but I had to
make a few slight changes to get it functioning. The most important
change was in xilinx_intc driver. For level interrupts the ack command
was removed during the xilinx_intc rewrite which caused a null pointer
derefence in the i8259 cascade code. I have now changed it to:
/* Let xilinx_intc end the interrupt */
desc->chip->mask(irq);
desc->chip->unmask(irq);
This seems to work properly. Further the driver now also has proper
level support, so i think my dts file has some errors. The pci
interrupts (a/b/c/d) are all active low, so they need to be changed to
'3' for the sense level. Further the i8259 is active high which needs
to be set to 2 instead of 3.
Further I have tested the need for the outb to 0x4d0/0x4d1. Removing
those lines causes interrupt timeouts and ide won't function.
Freescale does the same in arch/powerpc/platforms/fsl_uli1575.c (which
is a much newer version of this chipset) in quirk_final_uli1575 but
they are doing it for some more interrupts. I think this code should
be done using a similar quirk in virtex_ml510.c
Roderick
^ permalink raw reply
* [PATCH V5 5/5] Fabric bindings for STAC9766 on the Efika
From: Jon Smirl @ 2009-05-26 12:34 UTC (permalink / raw)
To: grant.likely, linuxppc-dev, alsa-devel, broonie, timur
In-Reply-To: <20090526123235.17472.73912.stgit@terra>
Fabric bindings for STAC9766 AC97 codec on the Efika.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
sound/soc/fsl/Kconfig | 8 +++
sound/soc/fsl/Makefile | 1
sound/soc/fsl/efika-audio-fabric.c | 90 ++++++++++++++++++++++++++++++++++++
3 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/fsl/efika-audio-fabric.c
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 79579ae..f571c6e 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -47,3 +47,11 @@ config SND_MPC52xx_SOC_PCM030
help
Say Y if you want to add support for sound on the Phytec pcm030 baseboard.
+config SND_MPC52xx_SOC_EFIKA
+ tristate "SoC AC97 Audio support for bbplan Efika and STAC9766"
+ depends on PPC_EFIKA
+ select SND_SOC_MPC5200_AC97
+ select SND_SOC_STAC9766
+ help
+ Say Y if you want to add support for sound on the Efika.
+
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 66d88c8..a83a739 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -17,4 +17,5 @@ obj-$(CONFIG_SND_SOC_MPC5200_AC97) += mpc5200_psc_ac97.o
# MPC5200 Machine Support
obj-$(CONFIG_SND_MPC52xx_SOC_PCM030) += pcm030-audio-fabric.o
+obj-$(CONFIG_SND_MPC52xx_SOC_EFIKA) += efika-audio-fabric.o
diff --git a/sound/soc/fsl/efika-audio-fabric.c b/sound/soc/fsl/efika-audio-fabric.c
new file mode 100644
index 0000000..85b0e75
--- /dev/null
+++ b/sound/soc/fsl/efika-audio-fabric.c
@@ -0,0 +1,90 @@
+/*
+ * Efika driver for the PSC of the Freescale MPC52xx
+ * configured as AC97 interface
+ *
+ * Copyright 2008 Jon Smirl, Digispeaker
+ * Author: Jon Smirl <jonsmirl@gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/device.h>
+#include <linux/delay.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/dma-mapping.h>
+
+#include <sound/core.h>
+#include <sound/pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/initval.h>
+#include <sound/soc.h>
+#include <sound/soc-of-simple.h>
+
+#include "mpc5200_dma.h"
+#include "mpc5200_psc_ac97.h"
+#include "../codecs/stac9766.h"
+
+static struct snd_soc_device device;
+static struct snd_soc_card card;
+
+static struct snd_soc_dai_link efika_fabric_dai[] = {
+{
+ .name = "AC97",
+ .stream_name = "AC97 Analog",
+ .codec_dai = &stac9766_dai[STAC9766_DAI_AC97_ANALOG],
+ .cpu_dai = &psc_ac97_dai[MPC5200_AC97_NORMAL],
+},
+{
+ .name = "AC97",
+ .stream_name = "AC97 IEC958",
+ .codec_dai = &stac9766_dai[STAC9766_DAI_AC97_DIGITAL],
+ .cpu_dai = &psc_ac97_dai[MPC5200_AC97_SPDIF],
+},
+};
+
+static __init int efika_fabric_init(void)
+{
+ struct platform_device *pdev;
+ int rc;
+
+ if (!machine_is_compatible("bplan,efika"))
+ return -ENODEV;
+
+ card.platform = &mpc5200_audio_dma_platform;
+ card.name = "Efika";
+ card.dai_link = efika_fabric_dai;
+ card.num_links = ARRAY_SIZE(efika_fabric_dai);
+
+ device.card = &card;
+ device.codec_dev = &soc_codec_dev_stac9766;
+
+ pdev = platform_device_alloc("soc-audio", 1);
+ if (!pdev) {
+ pr_err("efika_fabric_init: platform_device_alloc() failed\n");
+ return -ENODEV;
+ }
+
+ platform_set_drvdata(pdev, &device);
+ device.dev = &pdev->dev;
+
+ rc = platform_device_add(pdev);
+ if (rc) {
+ pr_err("efika_fabric_init: platform_device_add() failed\n");
+ return -ENODEV;
+ }
+ return 0;
+}
+
+module_init(efika_fabric_init);
+
+
+MODULE_AUTHOR("Jon Smirl <jonsmirl@gmail.com>");
+MODULE_DESCRIPTION(DRV_NAME ": mpc5200 Efika fabric driver");
+MODULE_LICENSE("GPL");
+
^ permalink raw reply related
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