@timur
hi,
Audio card (wm8776) cannot work in full duplex, CPU is FSL P1022.
The PCB design about audio card reference FSL P1022 development board, and
palying or recording is OK separately.
My question is whether P1022 audio driver cannot support full duplex?
The following is my test method.
On Thu, 2014-05-29 at 19:39 +1000, Stephen Rothwell wrote:
> Hi Michael,
>
> On Thu, 29 May 2014 19:32:52 +1000 Stephen Rothwell
> wrote:
> >
> > On Thu, 29 May 2014 18:50:29 +1000 Michael Ellerman
> > wrote:
> > >
> > > __attribute__ ((unused))
> > >
> > > Signed-off-by: Michael Ellerman
>
On Thu, 2014-05-29 at 19:32 +1000, Stephen Rothwell wrote:
> Hi Michael,
>
> On Thu, 29 May 2014 18:50:29 +1000 Michael Ellerman
> wrote:
> >
> > __attribute__ ((unused))
> >
> > Signed-off-by: Michael Ellerman
>
> So this was the only use of CONFIG_PPC_A2 ... so more cleanup
> possible :-)
>
On Fri, 2014-05-30 at 13:44 +1000, Alexey Kardashevskiy wrote:
>
> It is pseries, not real HW. Does phyp allow multiple real host PEs on
> the same virtual PHB?
I don't know how recent pHyp versions do it. I think they pretty much
have a PE == 1 virtual PHB so you might be right there.
On older
On 05/29/2014 07:58 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2014-05-28 at 22:49 +1000, Gavin Shan wrote:
>>
>> I will remove those "address" related macros in next revision because it's
>> user-level bussiness, not related to host kernel any more.
>>
>> If the user is QEMU + guest, we need the
On ia64 and ppc64, the function pointer does not point the
entry address of the function, but the address of function
discriptor (which contains the entry address and misc
data.) Since the kprobes passes the function pointer stored
by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for
initalizi
(2014/05/30 4:13), Suzuki K. Poulose wrote:
>> @@ -2042,7 +2043,8 @@ static int __init populate_kprobe_blacklist(unsigned
>> long *start,
>> unsigned long offset = 0, size = 0;
>>
>> for (iter = start; iter < end; iter++) {
>> -if (!kallsyms_lookup_size_offset(*iter, &size,
Hi abdoulaye,
On Fri, 30 May 2014 01:16:22 +0200 abdoulaye berthe wrote:
>
> The aim of this patch is to make gpiochip_remove() behavior consistent,
> especially when issuing a remove request while the chipio chip is
> still requested. A patch has been submitted to change the return value of
> gp
On Thu, May 29, 2014 at 11:54:52PM +0200, abdoulaye berthe wrote:
> Signed-off-by: abdoulaye berthe
Why?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Signed-off-by: Scott Wood
Reported-by: Ed Swarthout
---
arch/powerpc/include/asm/reg_booke.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/reg_booke.h
b/arch/powerpc/include/asm/reg_booke.h
index 163c3b0..4155120 100644
--- a/arch/powerpc/include/a
Hi David,
The aim of this patch is to make gpiochip_remove() behavior consistent,
especially when issuing a remove request while the chipio chip is
still requested. A patch has been submitted to change the return value of
gpiochip_remove() from int to void. This one updates users of the return
valu
Commit 82d86de25b9c99db546e17c6f7ebf9a691da557e "TLB lock recursive"
introduced a bug whereby cpu 0 uses the same value for "lock held" as
is used to indicate that the lock is free. This means that cpu 1 can
acquire the lock whenever it wants, regardless of whether cpu 0 has it
locked, which in tu
On Fri, 2014-05-23 at 14:22 -0500, John Donnelly wrote:
> The failing code snippet :
>
> void ttwu_activate(struct rq *rq, struct task_struct *p, int en_flags)
> {
> c0088b90: 7c 08 02 a6 mflrr0
> c0088b94: 90 01 00 04 stw r0,4(r1)
> c0088b98: 4b f8 87 29 bl
On 05/29/2014 02:54 PM, abdoulaye berthe wrote:
Did you forget a changelog explaining why this is either needed, or even
a good idea? I joined the conversation late and don't know why you are
doing this.
Thanks,
David Daney
Signed-off-by: abdoulaye berthe
---
arch/arm/common/scoop.c
On Thu, 2014-05-29 at 23:27 +0200, Alexander Graf wrote:
> On 29.05.14 09:45, Michael Neuling wrote:
> >>> +/* Values for 2nd argument to H_SET_MODE */
> >>> +#define H_SET_MODE_RESOURCE_SET_CIABR1
> >>> +#define H_SET_MODE_RESOURCE_SET_DAWR2
> >>> +#define H_SET_MODE_RESOURCE_ADDR_
Not involved in 8xx activities for years, update MAINTAINERS
to reflect it.
Signed-off-by: Marcelo Tosatti
diff --git a/MAINTAINERS b/MAINTAINERS
index c47d268..ed7b606 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5349,7 +5349,6 @@ F:arch/powerpc/*/*/*virtex*
LINUX FOR POWERPC EMBE
On 29.05.14 09:45, Michael Neuling wrote:
+/* Values for 2nd argument to H_SET_MODE */
+#define H_SET_MODE_RESOURCE_SET_CIABR1
+#define H_SET_MODE_RESOURCE_SET_DAWR2
+#define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE3
+#define H_SET_MODE_RESOURCE_LE4
Much better, but
On Mon, 2014-05-26 at 15:20 -0700, shiva7 wrote:
> shiva7 wrote
> > Thanks again Scott.
> /
> >> Any idea whether the DBCR0 BRT bit actually works(??),
> >
> >> Do you have reason to believe that it might not?
> /
> >
> > I'm facing a strange problem which was not there on server processor. Let
On 05/27/2014 12:01 PM, Masami Hiramatsu wrote:
> On ia64 and ppc64, the function pointer does not point the
> entry address of the function, but the address of function
> discriptor (which contains the entry address and misc
> data.) Since the kprobes passes the function pointer stored
> by NOKPRO
On Thu, 2014-05-29 at 20:39 +0200, Paul Bolle wrote:
> That's why I included the people (and lists) maintaining PPC8XX and
> PPC.
And of those people Marcelo might consider replacing the bouncing
knack.org address with a redhat.com address. Provided Marcelo still
cares about PPC8XX, that is. But p
On Thu, 2014-05-29 at 20:39 +0200, Paul Bolle wrote:
> On Thu, 2014-05-29 at 13:20 -0500, Scott Wood wrote:
> > On Sat, 2014-05-24 at 09:36 +0200, Paul Bolle wrote:
> > > This driver contains checks for four Kconfig macros. But the related
> > > Kconfig symbols have never been part of the tree. Rem
On Thu, 2014-05-29 at 13:20 -0500, Scott Wood wrote:
> On Sat, 2014-05-24 at 09:36 +0200, Paul Bolle wrote:
> > This driver contains checks for four Kconfig macros. But the related
> > Kconfig symbols have never been part of the tree. Remove these checks
> > and the code they hide.
> >
> > Signed-
On Sat, 2014-05-24 at 09:36 +0200, Paul Bolle wrote:
> This driver contains checks for four Kconfig macros. But the related
> Kconfig symbols have never been part of the tree. Remove these checks
> and the code they hide.
>
> Signed-off-by: Paul Bolle
> ---
> Untested.
>
> This has been an issue
Hi Michael,
On Thu, 29 May 2014 19:32:52 +1000 Stephen Rothwell
wrote:
>
> On Thu, 29 May 2014 18:50:29 +1000 Michael Ellerman
> wrote:
> >
> > __attribute__ ((unused))
> >
> > Signed-off-by: Michael Ellerman
>
> So this was the only use of CONFIG_PPC_A2 ... so more cleanup
> possible :-)
Hi Michael,
On Thu, 29 May 2014 18:50:29 +1000 Michael Ellerman wrote:
>
> __attribute__ ((unused))
>
> Signed-off-by: Michael Ellerman
So this was the only use of CONFIG_PPC_A2 ... so more cleanup
possible :-)
I always appreciate negative work :-)
--
Cheers,
Stephen Rothwell
From: Joe Perches
> On Wed, 2014-05-28 at 17:11 -0500, Cody P Schafer wrote:
> > On Wed, May 28, 2014 at 5:05 PM, Cody P Schafer wrote:
> > > On Wed, May 28, 2014 at 3:45 AM, David Laight
> > > wrote:
> > >> From: Cody P Schafer
> > >>> Rather manually specifying the size of the integer to be co
> > +/* Values for 2nd argument to H_SET_MODE */
> > +#define H_SET_MODE_RESOURCE_SET_CIABR1
> > +#define H_SET_MODE_RESOURCE_SET_DAWR2
> > +#define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE3
> > +#define H_SET_MODE_RESOURCE_LE4
>
>
> Much better, but I think you want to
27 matches
Mail list logo