* Re: [PATCH 0/2] mpc52xx: stop drivers from accessing clock config directly
From: Grant Likely @ 2007-10-24 20:14 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-dev
In-Reply-To: <20071024191206.GD3369@nd47.coderock.org>
On 10/24/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> On 24/10/07 12:24 -0600, Grant Likely wrote:
> > Domen,
> >
> > Here's a real solution to the problem. I've somewhat tested this on
> > the lite5200b. Can you give it a spin on efika and see if SPI still
> > works for you?
>
> My test case was lite5200b too, I don't think I ever tried SPI on
> efika.
> (Are even the right pins on irda connector, or is a necessary line
> missing?)
Hmm, I guess that's right. Can you at least make sure it still boots
on Efika? Some of the clock detection stuff has changed so I want to
make sure it still boots.
Are you setup to do your SPI test easily on you lite5200b? When I say
"somewhat" tested; I mean I probed the driver and it didn't crash.
:-) I haven't tried to run traffic over it.
Can you check that on your system? If not, can you email me what
setup/programs you used for testing? I know very little about the SPI
infrastructure.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: New time code miscalculates cpu usage
From: Sergei Shtylyov @ 2007-10-24 20:17 UTC (permalink / raw)
To: Olof Johansson; +Cc: paulus, linuxppc-dev
In-Reply-To: <20071016202525.GA11837@lixom.net>
Hello.
Olof Johansson wrote:
> Not sure when this started happening, but I wanted to report it. I'll
> start bisecting in a day or two if noone else has gotten around to
> looking at it:
> $ echo "int main(void) { while(1); }" > test.c ; gcc test.c
> $ time ./a.out & sleep 2 ; killall a.out
> real 0m2.008s
> user 0m4.014s
> sys 0m0.002s
>
> Seen on POWER5 and PA6T, haven't tried anything else yet.
I'm not surprised -- the kernel accounts twice for each tick.
WBR, Sergei
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Grant Likely @ 2007-10-24 20:28 UTC (permalink / raw)
To: Matt Mackall; +Cc: gdb, linuxppc-embedded
In-Reply-To: <20071024194640.GB19691@waste.org>
On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> I'm trying to debug a trivial statically-linked hello world program on
> a Xilinx PPC 405 and I'm seeing the following behavior:
>
<snip>
>
> Any suggestions?
http://thread.gmane.org/gmane.linux.ports.ppc.embedded/11202
I was fighting with a similar problem almost 2 years ago. Looks like
it might be related. At some point the problem seemed to go away and
I determined what the root cause was. :-(
I haven't been using gdb lately, so I don't know if it's the same
problem. Nobody I had talked to had seen the issue on other 405
platforms. It could very well be something virtex-specific.
That's not much help, but maybe it will give you some clues.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Matt Mackall @ 2007-10-24 20:42 UTC (permalink / raw)
To: Grant Likely; +Cc: gdb, linuxppc-embedded
In-Reply-To: <fa686aa40710241328x77435cc1lf09cac730b0ce5ac@mail.gmail.com>
On Wed, Oct 24, 2007 at 02:28:14PM -0600, Grant Likely wrote:
> On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> > I'm trying to debug a trivial statically-linked hello world program on
> > a Xilinx PPC 405 and I'm seeing the following behavior:
> >
> <snip>
> >
> > Any suggestions?
>
> http://thread.gmane.org/gmane.linux.ports.ppc.embedded/11202
>
> I was fighting with a similar problem almost 2 years ago. Looks like
> it might be related. At some point the problem seemed to go away and
> I determined what the root cause was. :-(
>
> I haven't been using gdb lately, so I don't know if it's the same
> problem. Nobody I had talked to had seen the issue on other 405
> platforms. It could very well be something virtex-specific.
Could be the same problem, but I'm seeing only your symptom 3 so far.
I've tried throwing some larger hammers at the problem. Flushing all
of the dcache and icache (flush_dcache_all and
flush_instruction_cache) isn't helping. But printk(".") does!
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Grant Likely @ 2007-10-24 20:46 UTC (permalink / raw)
To: Matt Mackall; +Cc: gdb, linuxppc-embedded
In-Reply-To: <20071024204215.GC19691@waste.org>
On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> On Wed, Oct 24, 2007 at 02:28:14PM -0600, Grant Likely wrote:
> > On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> > > I'm trying to debug a trivial statically-linked hello world program on
> > > a Xilinx PPC 405 and I'm seeing the following behavior:
> > >
> > <snip>
> > >
> > > Any suggestions?
> >
> > http://thread.gmane.org/gmane.linux.ports.ppc.embedded/11202
> >
> > I was fighting with a similar problem almost 2 years ago. Looks like
> > it might be related. At some point the problem seemed to go away and
> > I determined what the root cause was. :-(
> >
> > I haven't been using gdb lately, so I don't know if it's the same
> > problem. Nobody I had talked to had seen the issue on other 405
> > platforms. It could very well be something virtex-specific.
>
> Could be the same problem, but I'm seeing only your symptom 3 so far.
>
> I've tried throwing some larger hammers at the problem. Flushing all
> of the dcache and icache (flush_dcache_all and
> flush_instruction_cache) isn't helping. But printk(".") does!
It's really true; printk *is* the most valuable tool kernel hackers
have for debugging.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 0/2] mpc52xx: stop drivers from accessing clock config directly
From: Domen Puncer @ 2007-10-24 20:54 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40710241314w2dbe0863ja15746614cff0dd@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]
On 24/10/07 14:14 -0600, Grant Likely wrote:
> On 10/24/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> > On 24/10/07 12:24 -0600, Grant Likely wrote:
> > > Domen,
> > >
> > > Here's a real solution to the problem. I've somewhat tested this on
> > > the lite5200b. Can you give it a spin on efika and see if SPI still
> > > works for you?
> >
> > My test case was lite5200b too, I don't think I ever tried SPI on
> > efika.
> > (Are even the right pins on irda connector, or is a necessary line
> > missing?)
>
> Hmm, I guess that's right. Can you at least make sure it still boots
> on Efika? Some of the clock detection stuff has changed so I want to
> make sure it still boots.
OK. I'll do that tomorrow.
>
> Are you setup to do your SPI test easily on you lite5200b? When I say
> "somewhat" tested; I mean I probed the driver and it didn't crash.
> :-) I haven't tried to run traffic over it.
Sorry, lite5200b is resting these days. :-(
>
> Can you check that on your system? If not, can you email me what
> setup/programs you used for testing? I know very little about the SPI
> infrastructure.
For userspace part I used something like: Documentation/spi/spidev
And for kernel the attached, to fill get binded to spidev driver.
Domen
>
> Thanks,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
--
Domen Puncer | Research & Development
.............................................................................................
Telargo d.o.o. | Zagrebška cesta 20 | 2000 Maribor | Slovenia
.............................................................................................
www.telargo.com
[-- Attachment #2: spidev_test_devices --]
[-- Type: text/plain, Size: 1502 bytes --]
---
drivers/spi/Makefile | 1 +
drivers/spi/spi_test_devices.c | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+)
Index: work-powerpc.git/drivers/spi/Makefile
===================================================================
--- work-powerpc.git.orig/drivers/spi/Makefile
+++ work-powerpc.git/drivers/spi/Makefile
@@ -35,3 +35,4 @@ obj-$(CONFIG_SPI_SPIDEV) += spidev.o
# SPI slave drivers (protocol for that link)
# ... add above this line ...
+obj-m += spi_test_devices.o
Index: work-powerpc.git/drivers/spi/spi_test_devices.c
===================================================================
--- /dev/null
+++ work-powerpc.git/drivers/spi/spi_test_devices.c
@@ -0,0 +1,38 @@
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/spi/spi.h>
+
+static struct spi_board_info spi_info[7];
+static struct spi_device *spidev[7];
+static int testdev_init(void)
+{
+ struct spi_board_info *info;
+ int i;
+
+ for (i=0; i<7; i++) {
+ struct spi_master *master;
+
+ info = &spi_info[i];
+ //info->max_speed_hz = 2*1000000;
+ info->max_speed_hz = 100000;
+ //info->max_speed_hz = 1*1000000;
+ strcpy(info->modalias, "spidev");
+
+ master = spi_busnum_to_master(i);
+ if (master)
+ spidev[i] = spi_new_device(master, info);
+ }
+ return 0;
+}
+
+static void testdev_exit(void)
+{
+ /* there is no _remove? */
+ /*for (i=0; i<7; i++) {
+ }*/
+}
+
+module_init(testdev_init);
+module_exit(testdev_exit);
+
+MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: David Daney @ 2007-10-24 20:34 UTC (permalink / raw)
To: Matt Mackall; +Cc: gdb, linuxppc-embedded
In-Reply-To: <20071024194640.GB19691@waste.org>
Matt Mackall wrote:
> I'm trying to debug a trivial statically-linked hello world program on
> a Xilinx PPC 405 and I'm seeing the following behavior:
>
> With direct gdb on target, I can set a breakpoint at main, run, and
> the breakpoint is triggered.
>
> With gdbserver and gdb with "target remote localhost:1234", the above
> still works.
>
> With gdb on target redirected to a PC and tunneled back
> to the target, everything still works.
>
> With gdb on a PC, execution continues past the breakpoint. Comparing
> the gdb protocol streams here and and on the previous (working) case
> are identical up to the point of hitting the breakpoint (which never
> happens in the latter case).
>
> Raising the load on the PC to 4 and running gdb under nice -n 19 makes
> things work again. So this begins to look like a kernel cache or
> timing bug rather than a problem with the PC tool. It appears that the
> breakpoint written to the executable at continue time is not visible
> to the CPU at execute time.
>
> My first suspicion was a dcache/icache coherency issue in
> copy_to_user_page, so I added flush_dcache_icache_page(page) here to
> no avail. On closer inspection, it looks like both icache and dcache
> are already being flushed by flush_icache_user_range().
>
First of all I have never used a similar configuration so this may be
totally off base. But...
If the icache is virtually indexed, then I think there are only two ways
to invalidate it. The first is from the context of the debugged process
where the page is mapped at the location the target program will see it.
If you try to invalidate from the context of the debugger, the page
will most likely not be mapped at the virtual address of the target
program so you might have to invalidate the *entire* icache.
David Daney
^ permalink raw reply
* i2c-mpc.c driver issues
From: Tjernlund @ 2007-10-24 21:06 UTC (permalink / raw)
To: i2c; +Cc: linuxppc-dev
While browsing the i2c-mpc.c driver I noticed some things that look odd
to me so I figured I report them. Could not find a maintainer in the MAINTANERS file
so I sent here, cc:ed linuxppc-dev as well.
1) There are a lot of return -1 error code that is propagated back to
userspace. Should be changed to proper -Exxx codes.
2) mpc_read(), according to the comment below it sends a STOP condition here but
this function does not known if this is the last read or not. mpc_xfer is
the one that knows when the transaction is over and should send the stop, which it already
does.
/* Generate stop on last byte */
if (i == length - 1)
writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_TXAK);
Jocke
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Matt Mackall @ 2007-10-24 21:54 UTC (permalink / raw)
To: Grant Likely; +Cc: gdb, linuxppc-embedded
In-Reply-To: <20071024204215.GC19691@waste.org>
On Wed, Oct 24, 2007 at 03:42:16PM -0500, Matt Mackall wrote:
> On Wed, Oct 24, 2007 at 02:28:14PM -0600, Grant Likely wrote:
> > On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> > > I'm trying to debug a trivial statically-linked hello world program on
> > > a Xilinx PPC 405 and I'm seeing the following behavior:
> > >
> > <snip>
> > >
> > > Any suggestions?
> >
> > http://thread.gmane.org/gmane.linux.ports.ppc.embedded/11202
> >
> > I was fighting with a similar problem almost 2 years ago. Looks like
> > it might be related. At some point the problem seemed to go away and
> > I determined what the root cause was. :-(
> >
> > I haven't been using gdb lately, so I don't know if it's the same
> > problem. Nobody I had talked to had seen the issue on other 405
> > platforms. It could very well be something virtex-specific.
>
> Could be the same problem, but I'm seeing only your symptom 3 so far.
>
> I've tried throwing some larger hammers at the problem. Flushing all
> of the dcache and icache (flush_dcache_all and
> flush_instruction_cache) isn't helping. But printk(".") does!
Well there was one remaining cache - the TLB. This patch seems to make
things work, but don't ask me why:
--- include/asm-ppc/cacheflush.h (revision 10439)
+++ include/asm-ppc/cacheflush.h (working copy)
@@ -11,6 +11,7 @@
#define _PPC_CACHEFLUSH_H
#include <linux/mm.h>
+#include <asm/tlbflush.h>
/*
* No cache flushing is required when address mappings are
@@ -35,10 +36,23 @@
extern void flush_icache_user_range(struct vm_area_struct *vma,
struct page *page, unsigned long addr, int len);
#define copy_to_user_page(vma, page, vaddr, dst, src, len) \
do { memcpy(dst, src, len); \
flush_icache_user_range(vma, page, vaddr, len); \
+ _tlbia(); \
} while (0)
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: New time code miscalculates cpu usage
From: Benjamin Herrenschmidt @ 2007-10-24 21:56 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <471FA875.6080602@ru.mvista.com>
On Thu, 2007-10-25 at 00:17 +0400, Sergei Shtylyov wrote:
> Hello.
>
> Olof Johansson wrote:
>
> > Not sure when this started happening, but I wanted to report it. I'll
> > start bisecting in a day or two if noone else has gotten around to
> > looking at it:
>
> > $ echo "int main(void) { while(1); }" > test.c ; gcc test.c
> > $ time ./a.out & sleep 2 ; killall a.out
> > real 0m2.008s
> > user 0m4.014s
> > sys 0m0.002s
> >
> > Seen on POWER5 and PA6T, haven't tried anything else yet.
>
> I'm not surprised -- the kernel accounts twice for each tick.
Your input would be much more valuable if you actually pointed out where
that happens and why since you seem to know it.
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: Matt Sealey @ 2007-10-24 22:05 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, tnt, linux-usb-devel
In-Reply-To: <20071024163412.GA17785@ru.mvista.com>
Valentine Barshak wrote:
> Rework ohci-ppc-of driver to use big-endian property instead of
> ohci-be/ohci-le compatible strings. Also remove unnecessary
> user-selectable USB_OHCI_HCD_PPC_OF_LE/BE stuff, because
> USB_OHCI_BIG_ENDIAN_DESC/MMIO should always be enabled for ppc
> and USB_OHCI_LITTLE_ENDIAN is selected for USB_OHCI_HCD_PCI by default.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
[snip]
>
> config USB_UHCI_HCD
> diff -pruN linux-2.6.orig/drivers/usb/host/ohci-ppc-of.c linux-2.6/drivers/usb/host/ohci-ppc-of.c
> --- linux-2.6.orig/drivers/usb/host/ohci-ppc-of.c 2007-10-24 18:44:25.000000000 +0400
> +++ linux-2.6/drivers/usb/host/ohci-ppc-of.c 2007-10-24 19:32:21.000000000 +0400
> @@ -15,8 +15,8 @@
>
> #include <linux/signal.h>
>
> -#include <asm/of_platform.h>
> -#include <asm/prom.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
>
>
> static int __devinit
> @@ -91,15 +91,10 @@ ohci_hcd_ppc_of_probe(struct of_device *
> int irq;
>
> int rv;
> - int is_bigendian;
>
> if (usb_disabled())
> return -ENODEV;
>
> - is_bigendian =
> - of_device_is_compatible(dn, "ohci-bigendian") ||
> - of_device_is_compatible(dn, "ohci-be");
> -
> dev_dbg(&op->dev, "initializing PPC-OF USB Controller\n");
>
> rv = of_address_to_resource(dn, 0, &res);
> @@ -134,9 +129,10 @@ ohci_hcd_ppc_of_probe(struct of_device *
> }
>
> ohci = hcd_to_ohci(hcd);
> - if (is_bigendian) {
> +
> + if (of_get_property(dn, "big-endian", NULL)) {
> ohci->flags |= OHCI_QUIRK_BE_MMIO | OHCI_QUIRK_BE_DESC;
> - if (of_device_is_compatible(dn, "mpc5200-ohci"))
> + if (of_device_is_compatible(dn, "mpc5200-usb-ohci"))
> ohci->flags |= OHCI_QUIRK_FRAME_NO;
> }
Just a note, this is a fairly destructive change and will stop the Efika
from having it's USB ports detected.
I've updated the Efika Device Tree Supplement script internally, but I
would really rather not have users be forced to update their kernel and
firmware quite so often just for what is, here, a merely aesthetic
change.
Can we just make sure real quickly that the changing of compatibles
doesn't break existing, not-easily-flashable firmwares?
At least work in 'mpc5200-ohci' for the endian check (it's always big
endian, but our device tree has no big-endian property by default and
does not contain mpc5200-usb-ohci or usb-ohci properties) otherwise we are
going to have users complain. To you guys.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Grant Likely @ 2007-10-24 22:27 UTC (permalink / raw)
To: Matt Mackall; +Cc: gdb, linuxppc-embedded
In-Reply-To: <20071024215421.GF19691@waste.org>
On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> On Wed, Oct 24, 2007 at 03:42:16PM -0500, Matt Mackall wrote:
> > On Wed, Oct 24, 2007 at 02:28:14PM -0600, Grant Likely wrote:
> > > On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> > > > I'm trying to debug a trivial statically-linked hello world program on
> > > > a Xilinx PPC 405 and I'm seeing the following behavior:
> > > >
> > > <snip>
> > > >
> > > > Any suggestions?
> > >
> > > http://thread.gmane.org/gmane.linux.ports.ppc.embedded/11202
> > >
> > > I was fighting with a similar problem almost 2 years ago. Looks like
> > > it might be related. At some point the problem seemed to go away and
> > > I determined what the root cause was. :-(
> > >
> > > I haven't been using gdb lately, so I don't know if it's the same
> > > problem. Nobody I had talked to had seen the issue on other 405
> > > platforms. It could very well be something virtex-specific.
> >
> > Could be the same problem, but I'm seeing only your symptom 3 so far.
> >
> > I've tried throwing some larger hammers at the problem. Flushing all
> > of the dcache and icache (flush_dcache_all and
> > flush_instruction_cache) isn't helping. But printk(".") does!
>
> Well there was one remaining cache - the TLB. This patch seems to make
> things work, but don't ask me why:
>
> --- include/asm-ppc/cacheflush.h (revision 10439)
> +++ include/asm-ppc/cacheflush.h (working copy)
> @@ -11,6 +11,7 @@
> #define _PPC_CACHEFLUSH_H
>
> #include <linux/mm.h>
> +#include <asm/tlbflush.h>
>
> /*
> * No cache flushing is required when address mappings are
> @@ -35,10 +36,23 @@
> extern void flush_icache_user_range(struct vm_area_struct *vma,
> struct page *page, unsigned long addr, int len);
>
> #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
> do { memcpy(dst, src, len); \
> flush_icache_user_range(vma, page, vaddr, len); \
> + _tlbia(); \
> } while (0)
Hmmm; thinking out loud here...
- so tlbia invalidates all TLB entries
- When gdb inserts a breakpoint the .text pages are marked as read
only, so the kernel does a copy on write so that gdb can modify the
instruction. The kernel also updates the page tables so that the test
process now uses the new page.
- This means that there are now 2 pages for that one section of
executable code; the original and the one with the breakpoint.
- However, the program is still in memory, and there is probably
already a TLB entry pointing to the original page for that range of
addresses.
Could it be that the kernel page tables are getting updated to the new
page; but active set of TLB entries is not getting updated?
If so, then printk(".") probably solves the problem simply because it
touches enough pages in its execution path that the old TLB entry gets
overwritten? There are only 64 TLB entries afterall.
Thoughts?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Matt Mackall @ 2007-10-24 22:32 UTC (permalink / raw)
To: Grant Likely; +Cc: gdb, linuxppc-embedded
In-Reply-To: <fa686aa40710241527j1a316760lf36d512eb625810f@mail.gmail.com>
On Wed, Oct 24, 2007 at 04:27:52PM -0600, Grant Likely wrote:
> On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> > On Wed, Oct 24, 2007 at 03:42:16PM -0500, Matt Mackall wrote:
> > > On Wed, Oct 24, 2007 at 02:28:14PM -0600, Grant Likely wrote:
> > > > On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> > > > > I'm trying to debug a trivial statically-linked hello world program on
> > > > > a Xilinx PPC 405 and I'm seeing the following behavior:
> > > > >
> > > > <snip>
> > > > >
> > > > > Any suggestions?
> > > >
> > > > http://thread.gmane.org/gmane.linux.ports.ppc.embedded/11202
> > > >
> > > > I was fighting with a similar problem almost 2 years ago. Looks like
> > > > it might be related. At some point the problem seemed to go away and
> > > > I determined what the root cause was. :-(
> > > >
> > > > I haven't been using gdb lately, so I don't know if it's the same
> > > > problem. Nobody I had talked to had seen the issue on other 405
> > > > platforms. It could very well be something virtex-specific.
> > >
> > > Could be the same problem, but I'm seeing only your symptom 3 so far.
> > >
> > > I've tried throwing some larger hammers at the problem. Flushing all
> > > of the dcache and icache (flush_dcache_all and
> > > flush_instruction_cache) isn't helping. But printk(".") does!
> >
> > Well there was one remaining cache - the TLB. This patch seems to make
> > things work, but don't ask me why:
> >
> > --- include/asm-ppc/cacheflush.h (revision 10439)
> > +++ include/asm-ppc/cacheflush.h (working copy)
> > @@ -11,6 +11,7 @@
> > #define _PPC_CACHEFLUSH_H
> >
> > #include <linux/mm.h>
> > +#include <asm/tlbflush.h>
> >
> > /*
> > * No cache flushing is required when address mappings are
> > @@ -35,10 +36,23 @@
> > extern void flush_icache_user_range(struct vm_area_struct *vma,
> > struct page *page, unsigned long addr, int len);
> >
> > #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
> > do { memcpy(dst, src, len); \
> > flush_icache_user_range(vma, page, vaddr, len); \
> > + _tlbia(); \
> > } while (0)
>
> Hmmm; thinking out loud here...
>
> - so tlbia invalidates all TLB entries
> - When gdb inserts a breakpoint the .text pages are marked as read
> only, so the kernel does a copy on write so that gdb can modify the
> instruction. The kernel also updates the page tables so that the test
> process now uses the new page.
> - This means that there are now 2 pages for that one section of
> executable code; the original and the one with the breakpoint.
> - However, the program is still in memory, and there is probably
> already a TLB entry pointing to the original page for that range of
> addresses.
>
> Could it be that the kernel page tables are getting updated to the new
> page; but active set of TLB entries is not getting updated?
>
> If so, then printk(".") probably solves the problem simply because it
> touches enough pages in its execution path that the old TLB entry gets
> overwritten? There are only 64 TLB entries afterall.
>
> Thoughts?
Not completely implausible, but a) why isn't this seen on basically
every machine with software TLB? b) why does -local- GDB, which is
presumably doing much less work than gdbserver + network stack, not fail?
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Grant Likely @ 2007-10-24 22:39 UTC (permalink / raw)
To: Matt Mackall; +Cc: gdb, linuxppc-embedded
In-Reply-To: <20071024223250.GI19691@waste.org>
On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> On Wed, Oct 24, 2007 at 04:27:52PM -0600, Grant Likely wrote:
> > On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> > > On Wed, Oct 24, 2007 at 03:42:16PM -0500, Matt Mackall wrote:
> > > > On Wed, Oct 24, 2007 at 02:28:14PM -0600, Grant Likely wrote:
> > > > > On 10/24/07, Matt Mackall <mpm@selenic.com> wrote:
> > > > > > I'm trying to debug a trivial statically-linked hello world program on
> > > > > > a Xilinx PPC 405 and I'm seeing the following behavior:
> > > > > >
> > > > > <snip>
> > > > > >
> > > > > > Any suggestions?
> > > > >
> > > > > http://thread.gmane.org/gmane.linux.ports.ppc.embedded/11202
> > > > >
> > > > > I was fighting with a similar problem almost 2 years ago. Looks like
> > > > > it might be related. At some point the problem seemed to go away and
> > > > > I determined what the root cause was. :-(
> > > > >
> > > > > I haven't been using gdb lately, so I don't know if it's the same
> > > > > problem. Nobody I had talked to had seen the issue on other 405
> > > > > platforms. It could very well be something virtex-specific.
> > > >
> > > > Could be the same problem, but I'm seeing only your symptom 3 so far.
> > > >
> > > > I've tried throwing some larger hammers at the problem. Flushing all
> > > > of the dcache and icache (flush_dcache_all and
> > > > flush_instruction_cache) isn't helping. But printk(".") does!
> > >
> > > Well there was one remaining cache - the TLB. This patch seems to make
> > > things work, but don't ask me why:
> > >
> > > --- include/asm-ppc/cacheflush.h (revision 10439)
> > > +++ include/asm-ppc/cacheflush.h (working copy)
> > > @@ -11,6 +11,7 @@
> > > #define _PPC_CACHEFLUSH_H
> > >
> > > #include <linux/mm.h>
> > > +#include <asm/tlbflush.h>
> > >
> > > /*
> > > * No cache flushing is required when address mappings are
> > > @@ -35,10 +36,23 @@
> > > extern void flush_icache_user_range(struct vm_area_struct *vma,
> > > struct page *page, unsigned long addr, int len);
> > >
> > > #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
> > > do { memcpy(dst, src, len); \
> > > flush_icache_user_range(vma, page, vaddr, len); \
> > > + _tlbia(); \
> > > } while (0)
> >
> > Hmmm; thinking out loud here...
> >
> > - so tlbia invalidates all TLB entries
> > - When gdb inserts a breakpoint the .text pages are marked as read
> > only, so the kernel does a copy on write so that gdb can modify the
> > instruction. The kernel also updates the page tables so that the test
> > process now uses the new page.
> > - This means that there are now 2 pages for that one section of
> > executable code; the original and the one with the breakpoint.
> > - However, the program is still in memory, and there is probably
> > already a TLB entry pointing to the original page for that range of
> > addresses.
> >
> > Could it be that the kernel page tables are getting updated to the new
> > page; but active set of TLB entries is not getting updated?
> >
> > If so, then printk(".") probably solves the problem simply because it
> > touches enough pages in its execution path that the old TLB entry gets
> > overwritten? There are only 64 TLB entries afterall.
> >
> > Thoughts?
>
> Not completely implausible, but a) why isn't this seen on basically
> every machine with software TLB? b) why does -local- GDB, which is
> presumably doing much less work than gdbserver + network stack, not fail?
a) I don't know.... very odd.
b) gdb is big. It probably touches far more pages (via library calls)
than gdbserver. The network stack is also big, but it's probably more
localized too.
Niceing down the host also makes sense because if the PC is being slow
then the target may go off and run other things while between setting
the breakpoint and getting the 'go' command.
Can you grab a snapshot of the TLB before and after setting the breakpoint?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Grant Likely @ 2007-10-24 22:40 UTC (permalink / raw)
To: Matt Mackall; +Cc: gdb, linuxppc-embedded
In-Reply-To: <fa686aa40710241539r792380dam62ea820a48dab62e@mail.gmail.com>
On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > Not completely implausible, but a) why isn't this seen on basically
> > every machine with software TLB? b) why does -local- GDB, which is
> > presumably doing much less work than gdbserver + network stack, not fail?
>
> a) I don't know.... very odd.
>
> b) gdb is big. It probably touches far more pages (via library calls)
> than gdbserver. The network stack is also big, but it's probably more
> localized too.
>
> Niceing down the host also makes sense because if the PC is being slow
> then the target may go off and run other things while between setting
> the breakpoint and getting the 'go' command.
>
> Can you grab a snapshot of the TLB before and after setting the breakpoint?
Or; probably more relevant, before and after the page copy?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: i2c-mpc.c driver issues
From: Jon Smirl @ 2007-10-24 22:44 UTC (permalink / raw)
To: Tjernlund; +Cc: linuxppc-dev, i2c
In-Reply-To: <019001c81681$b5d449c0$5267a8c0@Jocke>
On 10/24/07, Tjernlund <tjernlund@tjernlund.se> wrote:
> While browsing the i2c-mpc.c driver I noticed some things that look odd
> to me so I figured I report them. Could not find a maintainer in the MAINTANERS file
> so I sent here, cc:ed linuxppc-dev as well.
There appear to be more issues with this driver. It is still
registering as platform driver instead of a of_platform driver.
On the mpc5200 the probe function for platform drivers is not getting
called, so fsl_i2c_probe never gets called. It's not clear to me that
this driver is functioning on the mpc5200.
> 1) There are a lot of return -1 error code that is propagated back to
> userspace. Should be changed to proper -Exxx codes.
>
> 2) mpc_read(), according to the comment below it sends a STOP condition here but
> this function does not known if this is the last read or not. mpc_xfer is
> the one that knows when the transaction is over and should send the stop, which it already
> does.
>
> /* Generate stop on last byte */
> if (i == length - 1)
> writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_TXAK);
>
> Jocke
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Daniel Jacobowitz @ 2007-10-24 22:41 UTC (permalink / raw)
To: Matt Mackall; +Cc: gdb, linuxppc-embedded
In-Reply-To: <20071024223250.GI19691@waste.org>
On Wed, Oct 24, 2007 at 05:32:50PM -0500, Matt Mackall wrote:
> Not completely implausible, but a) why isn't this seen on basically
> every machine with software TLB? b) why does -local- GDB, which is
> presumably doing much less work than gdbserver + network stack, not fail?
You said it yourself. Local gdb does more work -> blows through more
TLB entries.
I can't answer you about the other half, but I'm pretty sure TLB
invalidation is already supposed to be happening... somewhere.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply
* Re: Ocotea board?
From: Jeff Mock @ 2007-10-24 23:18 UTC (permalink / raw)
To: Charlie Ashton; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <9D1E2BDCB5C57B46B56E6D80843439EB041E1E3D@SDCEXCHANGE01.ad.amcc.com>
Well, I suppose that it was really just a little poke to see if anyone
from AMCC reads the mailing list :) No offense intended.
The 440GX worked out great for my project, a new spectrometer for the
radio telescope in Arecibo. There are 14 of these boxes running in
parallel at the telescope. We got good performance out of the 440GX in
all respects with no major hangups during development.
jeff
Charlie Ashton wrote:
> The AMCC 440GX processor is by no means obsolete. There are more
> customers for this processor every month. There is a new, comprehensive
> evaluation kit called "Taishan"
> (http://www.amcc.com/Embedded/evalkits/440GX_PB_1_04.pdf), which AMCC
> provides to customers and partners. "Ocotea" is a board that was
> originally designed and used for processor validation purposes.
>
> Regards,
> Charlie
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+cashton=amcc.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+cashton=amcc.com@ozlabs.org] On Behalf
> Of Jeff Mock
> Sent: Wednesday, October 24, 2007 12:10 PM
> To: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
> Subject: Re: Ocotea board?
>
> Thanks for all of the replies, it's nice to hear that the 440GX isn't
> obsolete yet... A relatively arbitrary decision, but I'm going to send
>
> the Ocotea board to Josh.
>
> jeff
>
>
> Jeff Mock wrote:
>> Is the Ocotea board (the original 440GX eval board) still interesting?
>
>> I'm wrapping up a project using the 440GX, I started out hacking on
>> the Ocotea board to get started, but we moved off Ocotea long ago onto
>
>> our own hardware.
>>
>> I'm cleaning up the lab now that the project is nearly finished and I
>> would like to give the board to someone that will put it to good use.
>> I've sponged off this mailing list quite a lot, it's about time I give
>
>> a little something back.
>>
>> The board has been hacked a little bit but still works fine. I just
>> powered it up and it happily booted Linux via TFTP. The boot ROM now
>> has u-boot, the original PIBs (or whatever) is long gone. All I ask is
>
>> that you're self-sufficient and don't bug me too much about it...
>>
>> Can someone recommend a good home? Otherwise it will wind up in
>> storeroom purgatory.
>>
>> jeff
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> --------------------------------------------------------
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
>
^ permalink raw reply
* Re: [PATCH] taskstats scaled time cleanup
From: Andrew Morton @ 2007-10-24 23:33 UTC (permalink / raw)
To: Michael Neuling
Cc: linux-s390, linux-kernel, linuxppc-dev, paulus, linux390, balbir
In-Reply-To: <8789.1193208897@neuling.org>
On Wed, 24 Oct 2007 16:54:57 +1000
Michael Neuling <mikey@neuling.org> wrote:
> +/* Estimate the scaled cputime by scaling the real cputime based on
> + * the last scaled to real ratio */
> +static inline cputime_t cputime_to_scaled(const cputime_t ct)
> +{
> + if (cpu_has_feature(CPU_FTR_SPURR) &&
> + per_cpu(cputime_last_delta, smp_processor_id()))
> + return ct *
> + per_cpu(cputime_scaled_last_delta, smp_processor_id())/
> + per_cpu(cputime_last_delta, smp_processor_id());
> + return ct;
> +}
This looks far too large to be inlined.
^ permalink raw reply
* Re: Audio codec device tree entries
From: David Gibson @ 2007-10-24 23:52 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40710240828p532e8e4axf1f9b9ad4cd324f8@mail.gmail.com>
On Wed, Oct 24, 2007 at 09:28:42AM -0600, Grant Likely wrote:
> On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> > Jon Smirl wrote:
[snip]
> > My vote is for this version. In fact, I think it *has* to be this way. If
> > you're using a CS4270 codec (as I am), the I2C interface is *optional*. So I
> > want the I2S node to point to the I2C node if it exists.
>
> It doesn't have to be this way. If the codec does not have a control
> interface, then it can happily be a child of the i2s node. But if it
> *does*; don't break convention by separating it from it's control
> interface.
>
> I strongly recommend following the lead of ethernet phys and mdio
> busses here.
Yes. Devices should appear on the bus from which they're addressable,
that is from the control interface in this case. Sometimes different
things need to be done for bus-bridges which are configured from a
different bus than the one they bridge, but this is not such a
situation.
--
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
^ permalink raw reply
* Re: Audio codec device tree entries
From: David Gibson @ 2007-10-24 23:55 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <9e4733910710240854y6ac115b6i5e0400eb369fcf7@mail.gmail.com>
On Wed, Oct 24, 2007 at 11:54:23AM -0400, Jon Smirl wrote:
> On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > Do you want to pick one and add it to the device tree documentation
> > > with an example for i2s and ac97? I'll use which ever one is picked.
> >
> > Sure, I'll draft something up and post it for review.
> >
> > On the device probing front; what about this method:
> >
> > Rather than trying to figure things out from the board model, or the
> > combination of the codec and i2s bus; add another node to represent
> > the sound circuit. All that node would need is a unique compatible
> > property and a phandle to either the i2s bus or the codec (depending
> > on which binding approach is used). It could have additional
> > properties to represent optional features, etc.
>
> That's the pseudo-sound node proposal that other people objected to.
>
> It makes sense to me, there needs to be some way to trigger loading
> the fabric driver.
>
> >
> > For example:
> > sound@0 {
> > compatible = "<mfg>,<board>,sound" // The board might have
> > more than one sound i/f which could be wired differently
> > codec-handle = <&codec0>;
> > };
>
> Do you even need the parameters, how about simply this?
>
> sound-fabric {
> };
>
> That will trigger loading all of the sound-fabric drivers built into
> the kernel. In their probe functions they can look in the device tree
> and extract the machine name and then decide to stay loaded or fail
> the probe.
We shouldn't be basing driver configuration on the machine name unless
we really have to. We should be able to find a sane way to encode the
necessary information in the tree proper.
--
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
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Paul Mackerras @ 2007-10-24 23:55 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, Thomas Gleixner, Realtime Kernel
In-Reply-To: <471F358D.7070300@ru.mvista.com>
Sergei Shtylyov writes:
> I've just realized that I've missed the call to account_process_time() in
> the new timer_interrupt(). :-<
Which is bogus. I had removed it in the version of the patch that I
posted in early September, but apparently it crept back in.
> Anyway, this leads to each tick being accounted twice if the deterministic
> accounting is not enabled -- first by timer_interrupt() and then by the
> hrtimers core, doesn't it?
Yep.
Actually, I thought I was told that with CFS, the total process time
was accounted accurately using sched_clock(), then apportioned between
utime and stime (using counts of ticks in user/system state, which are
somewhat inaccurate). At the time I thought that would be OK, but now
I'm not so sure.
Paul.
^ permalink raw reply
* Re: Audio codec device tree entries
From: David Gibson @ 2007-10-25 0:01 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <9e4733910710240819m3d1cefeand264d2ced243904e@mail.gmail.com>
On Wed, Oct 24, 2007 at 11:19:33AM -0400, Jon Smirl wrote:
> On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> > > > codec0: i2s-codec@0 {
> > > > compatible = "ti,tas5508";
> > > > reg = <0>;
> > > > i2s-handle = <&i2s@2000>;
> > > > };
> > >
> > > I'd do this the other way around -- that is:
> > >
> > > i2s@2200 { // PSC2
> > > compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
> > > ...
> > > i2c-handle = <&codec0>; /* Or something like that */
> >
> > i2c-handle is a poor property name here. It should be 'codec-handle'.
> > The codec could theoretically live on just about *any* control bus;
> > not just i2c.
>
> That's one of the reasons I put the second option in the post.
>
> In the second option the i2s driver would instantiate first. Next the
> generic code would get loaded. The generic codec will know the control
> but for the device and it can go look in the i2c node for the address.
> i2c node still lists all of the devices on the i2c bus. But the codecs
> are in the i2c-handle property so they don't trigger a second loading
> of the codec.
>
> A fundamental question is, which bus should trigger the loading of the
> generic codec driver. The answer to this determines how the device
> tree should look.
No! Device tree layout should not be determined by the instantiation
model used by Linux drivers right now.
--
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
^ permalink raw reply
* Re: Audio codec device tree entries
From: David Gibson @ 2007-10-25 0:04 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40710240938l5b8c30b9qe538cc641df5e61b@mail.gmail.com>
On Wed, Oct 24, 2007 at 10:38:11AM -0600, Grant Likely wrote:
> On 10/24/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
[snip]
> > > For example:
> > > sound@0 {
> > > compatible = "<mfg>,<board>,sound" // The board might have
> > > more than one sound i/f which could be wired differently
> > > codec-handle = <&codec0>;
> > > };
>
> The difference here is that the node provides real information about
> the board. It has a compatible field which tells you *exactly* what
> sound circuit is present on the board. It can have additional
> information that does make sense to encode into the device tree (ie.
> the codec that is used). It's not addressable (no registers or
> anything), but it does describe the board.
>
> It would be possible and reasonable for a single fabric driver to work
> with many different circuit layouts as long as it has the information
> needed to adapt each instance.
This still seems nasty, since it seems to do little but duplicate the
platform information.
I'm afraid I still don't understand quite what information this
"fabric" driver is conveying. Is it really inherently platform
specific, or is it something that can be encoded directly in a
sensible way. If the latter we could have a general "device tree"
fabric driver that will handle all systems with the layout correctly
encoded in the device tree.
--
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
^ permalink raw reply
* Re: Audio codec device tree entries
From: Jon Smirl @ 2007-10-25 0:17 UTC (permalink / raw)
To: Grant Likely, Jon Smirl, PowerPC dev list, Timur Tabi
In-Reply-To: <20071025000425.GD23694@localhost.localdomain>
On 10/24/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> I'm afraid I still don't understand quite what information this
> "fabric" driver is conveying. Is it really inherently platform
> specific, or is it something that can be encoded directly in a
> sensible way. If the latter we could have a general "device tree"
> fabric driver that will handle all systems with the layout correctly
> encoded in the device tree.
Codecs are like GPIOs, all of their pins are programmable. So the same
codec can be wired into various boards quite differently and then
software programmed to work the same. The fabric driver contains the
mapping information.
People were making a codec driver for each board, but this resulted in
lots of similar codec drivers for the same chips. I believe a common
Wolfson chip had eight drivers in the kernel. In the new model the
codec drivers are generic and the fabric driver describes the mapping.
A side effect of this is that we need to load the fabric driver which
doesn't have a device associated with it.
This is a complex mapping from a STAC9277 used with an Intel hda chip.
Codec: SigmaTel STAC9227
Address: 2
Vendor Id: 0x83847618
Subsystem Id: 0x102801db
Revision Id: 0x100201
No Modem Function Group found
Default PCM:
rates [0x7e0]: 44100 48000 88200 96000 176400 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Default Amp-In caps: ofs=0x00, nsteps=0x0e, stepsize=0x05, mute=0
Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1
Node 0x02 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out
Amp-Out caps: N/A
Amp-Out vals: [0x62 0x62]
Power: 0x0
Node 0x03 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out
Amp-Out caps: N/A
Amp-Out vals: [0xe4 0xe4]
Power: 0x0
Node 0x04 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out
Amp-Out caps: N/A
Amp-Out vals: [0x62 0x62]
Power: 0x0
Node 0x05 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out
Amp-Out caps: N/A
Amp-Out vals: [0xe4 0xe4]
Power: 0x0
Node 0x06 [Vendor Defined Widget] wcaps 0xfd0c05: Stereo Amp-Out
Amp-Out caps: N/A
Amp-Out vals: [0xff 0xff]
Power: 0x0
Node 0x07 [Audio Input] wcaps 0x1d0541: Stereo
Power: 0x0
Connection: 1
0x1b
Node 0x08 [Audio Input] wcaps 0x1d0541: Stereo
Power: 0x0
Connection: 1
0x1c
Node 0x09 [Audio Input] wcaps 0x1d0541: Stereo
Power: 0x0
Connection: 1
0x1d
Node 0x0a [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x08173f: IN OUT HP Detect
Pin Default 0x0221101f: [Jack] HP Out at Ext Front
Conn = 1/8, Color = Black
Pin-ctls: 0xc0: OUT HP
Connection: 2
0x02* 0x03
Node 0x0b [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x08173f: IN OUT HP Detect
Pin Default 0x02a11020: [Jack] Mic at Ext Front
Conn = 1/8, Color = Black
Pin-ctls: 0x24: IN
Connection: 2
0x02* 0x03
Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x081737: IN OUT Detect
Pin Default 0x01a19021: [Jack] Mic at Ext Rear
Conn = 1/8, Color = Pink
Pin-ctls: 0x24: IN
Connection: 1
0x03
Node 0x0d [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x08173f: IN OUT HP Detect
Pin Default 0x01014010: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Green
Pin-ctls: 0x40: OUT
Connection: 1
0x02
Node 0x0e [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x081737: IN OUT Detect
Pin Default 0x01011012: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Black
Pin-ctls: 0x40: OUT
Connection: 1
0x04
Node 0x0f [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x081737: IN OUT Detect
Pin Default 0x01016011: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Orange
Pin-ctls: 0x40: OUT
Connection: 1
0x05
Node 0x10 [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x0837: IN OUT Detect
Pin Default 0x0181302e: [Jack] Line In at Ext Rear
Conn = 1/8, Color = Blue
Pin-ctls: 0x20: IN
Connection: 1
0x04
Node 0x11 [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x0837: IN OUT Detect
Pin Default 0x01012014: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Grey
Pin-ctls: 0x40: OUT
Connection: 1
0x03
Node 0x12 [Pin Complex] wcaps 0x400001: Stereo
Pincap 0x0820: IN
Pin Default 0x40f000f1: [N/A] Other at Ext N/A
Conn = Unknown, Color = Unknown
Pin-ctls: 0x00:
Node 0x13 [Vendor Defined Widget] wcaps 0xf00001: Stereo
Node 0x14 [Vendor Defined Widget] wcaps 0xf00001: Stereo
Node 0x15 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
Amp-Out vals: [0x00 0x00]
Connection: 9
0x0e 0x12 0x0f 0x0b 0x0c* 0x0d 0x0a 0x10 0x11
Node 0x16 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
Amp-Out vals: [0x00 0x00]
Connection: 9
0x0e 0x12 0x0f 0x0b 0x0c* 0x0d 0x0a 0x10 0x11
Node 0x17 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
Amp-Out vals: [0x00 0x00]
Connection: 9
0x0e 0x12 0x0f 0x0b 0x0c* 0x0d 0x0a 0x10 0x11
Node 0x18 [Audio Selector] wcaps 0x300103: Stereo Amp-In
Amp-In caps: N/A
Amp-In vals: [0x00 0x00]
Connection: 1
0x15
Node 0x19 [Audio Selector] wcaps 0x300103: Stereo Amp-In
Amp-In caps: N/A
Amp-In vals: [0x00 0x00]
Connection: 1
0x16
Node 0x1a [Audio Selector] wcaps 0x300103: Stereo Amp-In
Amp-In caps: N/A
Amp-In vals: [0x00 0x00]
Connection: 1
0x17
Node 0x1b [Audio Selector] wcaps 0x30090d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x80 0x80]
Connection: 1
0x18
Node 0x1c [Audio Selector] wcaps 0x30090d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x80 0x80]
Connection: 1
0x19
Node 0x1d [Audio Selector] wcaps 0x30090d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x80 0x80]
Connection: 1
0x1a
Node 0x1e [Audio Output] wcaps 0x40211: Stereo Digital
PCM:
rates [0x7e0]: 44100 48000 88200 96000 176400 192000
bits [0xe]: 16 20 24
formats [0x5]: PCM AC3
Node 0x1f [Vendor Defined Widget] wcaps 0xf30201: Stereo Digital
Node 0x20 [Audio Input] wcaps 0x140311: Stereo Digital
PCM:
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x5]: PCM AC3
Connection: 1
0x22
Node 0x21 [Pin Complex] wcaps 0x400301: Stereo Digital
Pincap 0x0810: OUT
Pin Default 0x014510a0: [Jack] SPDIF Out at Ext Rear
Conn = Optical, Color = Black
Pin-ctls: 0x40: OUT
Connection: 5
0x1e* 0x1f 0x1b 0x1c 0x1d
Node 0x22 [Pin Complex] wcaps 0x430681: Stereo Digital
Pincap 0x0810024: IN EAPD Detect
Pin Default 0x40f000f0: [N/A] Other at Ext N/A
Conn = Unknown, Color = Unknown
Pin-ctls: 0x00:
Power: 0x0
Node 0x23 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out
Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=0
Amp-Out vals: [0x00]
Node 0x24 [Volume Knob Widget] wcaps 0x600000: Mono
--
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