* Re: Fix Firmware class name collision
From: Kay Sievers @ 2007-12-15 15:46 UTC (permalink / raw)
To: Greg KH; +Cc: Markus Rechberger, Timur Tabi, PowerPC dev list
In-Reply-To: <20071215063917.GA14942@suse.de>
On Fri, 2007-12-14 at 22:39 -0800, Greg KH wrote:
> On Sat, Dec 15, 2007 at 05:14:29PM +1100, Benjamin Herrenschmidt wrote:
> >
> > On Fri, 2007-12-14 at 14:40 -0800, Greg KH wrote:
> > > On Tue, Dec 04, 2007 at 07:28:00PM -0600, Timur Tabi wrote:
> > > > Scott Wood wrote:
> > > >
> > > >> The physical address certainly is useful when you have more than one
> > > >> device of the same name.
> > > >
> > > > What I meant was that the physical address isn't helpful by itself.
> > > >
> > > >> So then you'd get "firmware-ucc.e01024". What if there's another ucc at
> > > >> e0102480? For devices with longer names, you'd have even less precision
> > > >> in the address.
> > > >
> > > > Maybe we need to consider a more sophisticated algorithm, one that
> > > > guarantees that the device name in its entirety is preserved? Either that,
> > > > or replace the physical address with something shorter, like the offset to
> > > > the root node only? That way, ucc.e0102400 because just ucc.2400.
> > >
> > > You should do something :)
> > >
> > > In the near future (2.6.26) there will not be a limit on the size of the
> > > file name, so we should not have this problem anymore.
> >
> > Not even .25 ? damn ! Any way that fix can be fastracked ? This
> > limitation has been a major PITA for some time now (this is just -one-
> > example where it gets in the way).
>
> I'll let Kay answer that, last he said, it involves a _lot_ of changes
> throughout the kernel :(
The current patch gets rid of bus_id and uses the dynamic kobject_name
directly all over the place. It's huge, because the current code expects
a static array and uses strncpy/snprintf all over the place.
I'm currently waiting for the new kobject api to finish, before I update
the patch, not sure if we will make it in time for .25.
Kay
^ permalink raw reply
* Re: [PATCH] [POWERPC][RFC] MPC8360E-RDK: Device tree and board file
From: Anton Vorontsov @ 2007-12-15 16:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <10D5CABD-442B-44DF-83D7-7FED5CD150E3@kernel.crashing.org>
On Tue, Dec 11, 2007 at 12:42:18PM -0600, Kumar Gala wrote:
[...]
> let's go ahead w/an aliases node:
>
> aliases {
> ethernet0 = &enet0;
> ethernet1 = &enet1;
> ...
> serial0 = &serial0;
> serial1 = &serial1;
> };
>
> >
> >+ cpus {
> >+ #address-cells = <1>;
> >+ #size-cells = <0>;
[...]
> >+
>
> Add serial labels:
> serial0: serial@4500 {...
> >
> >+ serial@4500 {
[...]
> ethernet labels
> >
> >+ ucc@2000 {
Done, thanks. As time goes by, I also added support for UCC7,4
(10/100 ethernet).
Plus, added compatible = "fsl,qe-pario"; into the par_io node,
now I'm searching for it instead of "par_io" name.
This is still RFC, so nitpicking is highly appreciated.
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
[POWERPC] MPC8360E-RDK: Device tree and board file
This is new board made by Freescale Semiconductor Inc. and
Logic Product Development.
Currently supported:
1. UEC1,2,7,4
2. I2C
3. SPI
4. NS16550 serial
Not supported so far:
1. StMICRO NAND512W3A2BN6E, 512 Mbit (supported with FSL UPM patches)
2. QE SCCs (slow UCCs, used as an UARTs)
3. PCI
4. ADC AD7843
5. FHCI USB
6. Graphics controller, Fujitsu MB86277
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc836x_rdk.dts | 288 +++++++++++++++++++++++++++++
arch/powerpc/platforms/83xx/Kconfig | 11 +-
arch/powerpc/platforms/83xx/Makefile | 1 +
arch/powerpc/platforms/83xx/mpc836x_rdk.c | 112 +++++++++++
4 files changed, 411 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc836x_rdk.dts
create mode 100644 arch/powerpc/platforms/83xx/mpc836x_rdk.c
diff --git a/arch/powerpc/boot/dts/mpc836x_rdk.dts b/arch/powerpc/boot/dts/mpc836x_rdk.dts
new file mode 100644
index 0000000..c873c39
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc836x_rdk.dts
@@ -0,0 +1,288 @@
+/*
+ * MPC8360E RDK Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ * Copyright 2007 MontaVista Software, Inc.
+ * Anton Vorontsov <avorontsov@ru.mvista.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "MPC8360ERDK", "MPC836xRDK", "MPC83xxRDK";
+ model = "MPC8360RDK";
+
+ aliases {
+ serial0 = &serial0;
+ serial1 = &serial1;
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ ethernet2 = &enet2;
+ ethernet3 = &enet3;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8360@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <32>;
+ i-cache-line-size = <32>;
+ d-cache-size = <32768>;
+ i-cache-size = <32768>;
+ /* filled by u-boot */
+ timebase-frequency = <0>;
+ bus-frequency = <0>;
+ clock-frequency = <0>;
+ };
+ };
+
+ soc8360@e0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ ranges = <0 0xe0000000 0x00100000>;
+ reg = <0xe0000000 0x00000200>;
+ /* filled by u-boot */
+ bus-frequency = <0>;
+
+ wdt@200 {
+ device_type = "watchdog";
+ compatible = "mpc83xx_wdt";
+ reg = <0x200 0x100>;
+ };
+
+ i2c@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <0x3000 0x100>;
+ interrupts = <14 8>;
+ interrupt-parent = <&ipic>;
+ dfsrr;
+ };
+
+ i2c@3100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <0x3100 0x100>;
+ interrupts = <16 8>;
+ interrupt-parent = <&ipic>;
+ dfsrr;
+ };
+
+ serial0: serial@4500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4500 0x100>;
+ interrupts = <9 8>;
+ interrupt-parent = <&ipic>;
+ /* filled by u-boot */
+ clock-frequency = <0>;
+ };
+
+ serial1: serial@4600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4600 0x100>;
+ interrupts = <10 8>;
+ interrupt-parent = <&ipic>;
+ /* filled by u-boot */
+ clock-frequency = <0>;
+ };
+
+ crypto@30000 {
+ device_type = "crypto";
+ model = "SEC2";
+ compatible = "talitos";
+ reg = <0x30000 0x10000>;
+ interrupts = <11 8>;
+ interrupt-parent = <&ipic>;
+ num-channels = <4>;
+ channel-fifo-len = <24>;
+ exec-units-mask = <0x0000007e>;
+ /*
+ * desc mask is for rev1.x, we need runtime fixup
+ * for >=2.x
+ */
+ descriptor-types-mask = <0x01010ebf>;
+ };
+
+ ipic: pic@700 {
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ reg = <0x700 0x100>;
+ device_type = "ipic";
+ };
+
+ par_io@1400 {
+ compatible = "fsl,qe-pario";
+ reg = <0x1400 0x100>;
+ num-ports = <7>;
+ };
+ };
+
+ qe@e0100000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "qe";
+ model = "QE";
+ ranges = <0 0xe0100000 0x00100000>;
+ reg = <0xe0100000 0x480>;
+ /* filled by u-boot */
+ brg-frequency = <0>;
+ bus-frequency = <0>;
+
+ muram@10000 {
+ device_type = "muram";
+ ranges = <0 0x00010000 0x0000c000>;
+
+ data-only@0 {
+ reg = <0 0xc000>;
+ };
+ };
+
+ spi@4c0 {
+ device_type = "spi";
+ compatible = "fsl_spi";
+ reg = <0x4c0 0x40>;
+ interrupts = <2>;
+ interrupt-parent = <&qeic>;
+ mode = "cpu";
+ };
+
+ spi@500 {
+ device_type = "spi";
+ compatible = "fsl_spi";
+ reg = <0x500 0x40>;
+ interrupts = <1>;
+ interrupt-parent = <&qeic>;
+ mode = "cpu";
+ };
+
+ usb@6c0 {
+ device_type = "usb";
+ compatible = "qe_udc";
+ reg = <0x6c0 0x40 0x8b00 0x100>;
+ interrupts = <11>;
+ interrupt-parent = <&qeic>;
+ mode = "slave";
+ };
+
+ enet0: ucc@2000 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ model = "UCC";
+ device-id = <1>;
+ reg = <0x2000 0x200>;
+ interrupts = <32>;
+ interrupt-parent = <&qeic>;
+ rx-clock = <0>;
+ tx-clock = <25>;
+ phy-handle = <&phy2>;
+ phy-connection-type = "rgmii-id";
+ /* filled by u-boot */
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ };
+
+ enet1: ucc@3000 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ model = "UCC";
+ device-id = <2>;
+ reg = <0x3000 0x200>;
+ interrupts = <33>;
+ interrupt-parent = <&qeic>;
+ rx-clock = <0>;
+ tx-clock = <20>;
+ phy-handle = <&phy4>;
+ phy-connection-type = "rgmii-id";
+ /* filled by u-boot */
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ };
+
+ enet2: ucc@2600 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ model = "UCC";
+ device-id = <7>;
+ reg = <0x2600 0x200>;
+ interrupts = <34>;
+ interrupt-parent = <&qeic>;
+ rx-clock = <36>;
+ tx-clock = <35>;
+ phy-handle = <&phy1>;
+ phy-connection-type = "mii";
+ /* filled by u-boot */
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ };
+
+ enet3: ucc@3200 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ model = "UCC";
+ device-id = <4>;
+ reg = <0x3200 0x200>;
+ interrupts = <35>;
+ interrupt-parent = <&qeic>;
+ rx-clock = <24>;
+ tx-clock = <23>;
+ phy-handle = <&phy3>;
+ phy-connection-type = "mii";
+ /* filled by u-boot */
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ };
+
+ mdio@2120 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2120 0x18>;
+ device_type = "mdio";
+ compatible = "ucc_geth_phy";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+
+ phy2: ethernet-phy@2 {
+ reg = <2>;
+ device_type = "ethernet-phy";
+ };
+
+ phy3: ethernet-phy@3 {
+ reg = <3>;
+ device_type = "ethernet-phy";
+ };
+
+ phy4: ethernet-phy@4 {
+ reg = <4>;
+ device_type = "ethernet-phy";
+ };
+ };
+
+ qeic: qeic@80 {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ device_type = "qeic";
+ reg = <0x80 0x80>;
+ big-endian;
+ interrupts = <32 8 33 8>;
+ interrupt-parent = <&ipic>;
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
index 2430ac8..0d5a87c 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -55,6 +55,15 @@ config MPC837x_MDS
select DEFAULT_UIMAGE
help
This option enables support for the MPC837x MDS Processor Board.
+
+config MPC836x_RDK
+ bool "Freescale/Logic MPC836x RDK"
+ select DEFAULT_UIMAGE
+ select QUICC_ENGINE
+ help
+ This option enables support for the MPC836x RDK Processor Board,
+ also known as ZOOM PowerQUICC Kit.
+
endchoice
config PPC_MPC831x
@@ -79,7 +88,7 @@ config PPC_MPC836x
bool
select PPC_UDBG_16550
select PPC_INDIRECT_PCI
- default y if MPC836x_MDS
+ default y if MPC836x_MDS || MPC836x_RDK
config PPC_MPC837x
bool
diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile
index df46629..bf1b799 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_MPC834x_ITX) += mpc834x_itx.o
obj-$(CONFIG_MPC836x_MDS) += mpc836x_mds.o
obj-$(CONFIG_MPC832x_MDS) += mpc832x_mds.o
obj-$(CONFIG_MPC837x_MDS) += mpc837x_mds.o
+obj-$(CONFIG_MPC836x_RDK) += mpc836x_rdk.o
diff --git a/arch/powerpc/platforms/83xx/mpc836x_rdk.c b/arch/powerpc/platforms/83xx/mpc836x_rdk.c
new file mode 100644
index 0000000..2d94b38
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/mpc836x_rdk.c
@@ -0,0 +1,112 @@
+/*
+ * MPC8360E-RDK board file.
+ *
+ * Copyright (c) 2006 Freescale Semicondutor, Inc.
+ * Copyright (c) 2007 MontaVista Software, Inc.
+ * Anton Vorontsov <avorontsov@ru.mvista.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+#include <asm/prom.h>
+#include <asm/time.h>
+#include <asm/ipic.h>
+#include <asm/udbg.h>
+#include <asm/io.h>
+#include <asm/qe.h>
+#include <asm/qe_ic.h>
+#include <sysdev/fsl_soc.h>
+
+#include "mpc83xx.h"
+
+static struct of_device_id mpc836x_rdk_ids[] = {
+ { .type = "soc", },
+ { .compatible = "soc", },
+ { .type = "qe", },
+ {},
+};
+
+static int __init mpc836x_rdk_declare_of_platform_devices(void)
+{
+ if (!machine_is(mpc836x_rdk))
+ return 0;
+
+ of_platform_bus_probe(NULL, mpc836x_rdk_ids, NULL);
+
+ return 0;
+}
+device_initcall(mpc836x_rdk_declare_of_platform_devices);
+
+static void __init mpc836x_rdk_setup_arch(void)
+{
+ struct device_node *np;
+
+ if (ppc_md.progress)
+ ppc_md.progress("mpc836x_rdk_setup_arch()", 0);
+
+#ifdef CONFIG_QUICC_ENGINE
+ qe_reset();
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,qe-pario");
+ if (np) {
+ par_io_init(np);
+ of_node_put(np);
+ } else {
+ pr_warning("QE PIO not initialized!\n");
+ }
+#endif
+}
+
+static void __init mpc836x_rdk_init_IRQ(void)
+{
+ struct device_node *np;
+
+ np = of_find_node_by_type(NULL, "ipic");
+ if (!np)
+ return;
+
+ ipic_init(np, 0);
+
+ /*
+ * Initialize the default interrupt mapping priorities,
+ * in case the boot rom changed something on us.
+ */
+ ipic_set_default_priority();
+ of_node_put(np);
+
+#ifdef CONFIG_QUICC_ENGINE
+ np = of_find_node_by_type(NULL, "qeic");
+ if (!np)
+ return;
+
+ qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
+ of_node_put(np);
+#endif
+}
+
+/*
+ * Called very early, MMU is off, device-tree isn't unflattened.
+ */
+static int __init mpc836x_rdk_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "MPC836xRDK");
+}
+
+define_machine(mpc836x_rdk) {
+ .name = "MPC836x RDK",
+ .probe = mpc836x_rdk_probe,
+ .setup_arch = mpc836x_rdk_setup_arch,
+ .init_IRQ = mpc836x_rdk_init_IRQ,
+ .get_irq = ipic_get_irq,
+ .restart = mpc83xx_restart,
+ .time_init = mpc83xx_time_init,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.5.2.2
^ permalink raw reply related
* Re: mmap + segfaults on MPC8349E
From: David Hawkins @ 2007-12-15 19:55 UTC (permalink / raw)
To: R. Ebersole (VTI - new); +Cc: linuxppc-embedded
In-Reply-To: <476376DA.9010608@valleytech.com>
Hi,
> Attached is the driver code that was in use when we had the problem.
> (FPGA_orig.7z)
>
> We think that we *may* have resolved the issue.
> We have not, yet, completed testing the resolution, however.
>
> Attached is the updated version of the driver (FPGArw.7z).
> So far, this version appears OK when using mmap() without
> MAP_FIXED. We open() the device O_RDWR | O_SYNC.
>
> We were going to switch to using pread(), pwrite(), and ioctl() to
> access the FPGA's registers, but we are going to hold off on that
> for now.
I had a look at a few of the user-space examples I have written
for accessing via mmap() for my own drivers, and the standard
/dev/mem driver. I've include a generic /dev/mem interface program
that I've used on a TS-7300 board (ARM-based board from Technologic
Systems). Its inline below. It should work fine on a PowerPC too.
My example code has always used open with O_RDWR and in some
cases (O_RDWR | O_SYNC) (as in the code below). The call to
mmap() uses prot set to (PROT_READ|PROT_WRITE) to match the open
mode, and for the flags MAP_SHARED, never MAP_FIXED.
From the man page for mmap()
http://linux.die.net/man/2/mmap
MAP_FIXED
Do not select a different address than the one specified.
If the memory region specified by start and len overlaps pages
of any existing mapping(s), then the overlapped part of the
existing mapping(s) will be discarded. If the specified address
cannot be used, mmap() will fail. If MAP_FIXED is specified,
start must be a multiple of the page size. Use of this option
is discouraged.
So I'm not sure why you would choose this option.
I can't say what problems selecting this option would create, as I've
never tried. It would take some walking through the kernel code to
see where this flag is used.
Did you really see a difference between the driver code versions, or
was it changing MAP_FIXED to MAP_SHARED that did the trick?
If you test with the /dev/mem driver below and have no problems,
then I would recommend using the /dev/mem mmap() routine in your
custom driver.
To track down which code change causes the SEGFAULT would require
finding out the source of the SEGFAULT. So if you can code up
something that consistently causes the error, then you should be
able to debug the kernel to see what is causing it. I haven't had
to debug this sort of thing, so can't offer much advice. If its
hard to trigger the error, then do something deliberate; generate
a parity error (eg. by reading a specific FPGA register), generate
a bus timeout, etc. If that has the same effect on your code, then
perhaps the driver can be instrumented to give you a little more
debug information.
Cheers,
Dave
/*
* mem_debug.c
*
* 5/10/07 D. W. Hawkins (dwh@ovro.caltech.edu)
*
* A debug console for read/write access to /dev/mem mapped
* areas.
*/
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <signal.h>
#include <sys/mman.h>
#include <stdlib.h>
#include <unistd.h>
void display_help();
void change_mem(char *cmd);
void display_mem(char *cmd);
void process_command(char *cmd);
/* Mapped address and size */
static char *mem_addr = NULL;
static unsigned int mem_phys = 0;
static unsigned int mem_pages = 0;
static unsigned int mem_size = 0;
static void show_usage()
{
printf("\nUsage: mem_debug -a <address> -n <pages>\n"\
" -h Help (this message)\n"\
" -a <address> Hex address to start the map\n"\
" -n <pages> Number of pages to map\n\n");
}
int main(int argc, char *argv[])
{
int opt; /* getopt processing */
int fd; /* /dev/mem file descriptor */
char buf[200]; /* command processing buffer */
int len = 200;
int page_size = getpagesize();
int status;
while ((opt = getopt(argc, argv, "a:hn:")) != -1) {
switch (opt) {
case 'a':
status = sscanf(optarg, "%X", &mem_phys);
if (status != 1) {
printf("Parse error for -a option\n");
show_usage();
return -1;
}
break;
case 'h':
show_usage();
return -1;
case 'n':
mem_pages = atoi(optarg);
break;
default:
show_usage();
return -1;
}
}
if (mem_phys != (mem_phys/page_size)*page_size) {
printf("Error: the address must be page-aligned (0x%X)\n",
page_size);
return -1;
}
if (mem_pages == 0) {
mem_pages = 1;
}
mem_size = mem_pages*page_size;
/* Startup */
printf("\n------------------------\n");
printf("/dev/mem debug interface\n");
printf("========================\n\n");
/* Open /dev/mem and map it */
printf(" * open /dev/mem\n");
fd = open("/dev/mem", O_RDWR | O_SYNC);
if (fd < 0) {
printf("Open /dev/mem failed - %s\n",
strerror(errno));
return -1;
}
printf(" * map %d page(s) (%d-bytes) at address 0x%.8X\n",
mem_pages, mem_size, mem_phys);
mem_addr = (char *)mmap(
0,
mem_size,
PROT_READ|PROT_WRITE,
MAP_SHARED,
fd,
mem_phys);
if (mem_addr == (char *)MAP_FAILED) {
printf("Error: mmap failed\n");
close(fd);
return -1;
}
/* Display help */
display_help();
/* Process commands */
while (1) {
printf("CMD> ");
fflush(stdout);
fgets(buf,len,stdin);
process_command(buf);
}
/* Cleanup */
munmap((void *)mem_addr, mem_pages*page_size);
close(fd);
return 0;
}
/*--------------------------------------------------------------------
* User interface
*--------------------------------------------------------------------
*/
void display_help()
{
printf("\n ? Help\n");
printf(" dw addr len Display len words starting from addr\n");
printf(" db addr len Display len bytes starting from addr\n");
printf(" cw addr val Change word at addr to val\n");
printf(" cb addr val Change byte at addr to val\n");
printf(" q Quit\n");
printf("\n Notes:\n");
printf(" * addr, len, and val are interpreted as hex values\n");
printf(" * addresses are always byte based\n");
printf(" * addresses are offsets relative to the base address\n\n");
}
void process_command(char *cmd)
{
if (cmd[0] == '\0') {
return;
}
switch (cmd[0]) {
case '?':
display_help();
break;
case 'd':
case 'D':
display_mem(cmd);
break;
case 'c':
case 'C':
change_mem(cmd);
break;
case 'q':
case 'Q':
exit(0);
default:
break;
}
return;
}
void display_mem(char *cmd)
{
char width = 0;
int addr = 0;
int len = 0;
int status;
int i, data;
/* d, db, dw */
status = sscanf(cmd, "%*c%c %x %x", &width, &addr, &len);
if (status != 3) {
printf("syntax error (use ? for help)\n");
return;
}
if (len > mem_size) {
len = mem_size;
}
/* Convert to offset if required */
if (addr >= mem_phys) {
addr -= mem_phys;
}
if (addr >= mem_size) {
printf("Illegal address\n");
return;
}
switch (width) {
case 'b':
for (i = 0; i < len; i++) {
if ((i%16) == 0) {
printf("\n%.8X: ", mem_phys + addr + i);
}
data = (int)(mem_addr[addr+i]) & 0xFF;
printf("%.02X ", data);
}
printf("\n");
break;
default:
for (i = 0; i < len; i+=4) {
if ((i%16) == 0) {
printf("\n%.8X: ", mem_phys + addr + i);
}
data = *(int *)(mem_addr + addr + i);
printf("%.08X ", data);
}
printf("\n");
break;
}
printf("\n");
return;
}
void change_mem(char *cmd)
{
char width = 0;
int addr = 0;
int data = 0;
int status;
/* c, cb, cw */
status = sscanf(cmd, "%*c%c %x %x", &width, &addr, &data);
if (status != 3) {
printf("syntax error (use ? for help)\n");
return;
}
/* Convert to offset if required */
if (addr >= mem_phys) {
addr -= mem_phys;
}
if (addr >= mem_size) {
printf("Illegal address\n");
return;
}
switch (width) {
case 'b':
mem_addr[addr] = data & 0xFF;
break;
default:
*(int *)(mem_addr + addr) = data;
break;
}
return;
}
^ permalink raw reply
* port VNC to Xilinx ppc
From: d8341linux @ 2007-12-16 4:39 UTC (permalink / raw)
To: Linuxppc-embedded
Hi, All:
I have booted up linux on Xilinx ML403 board (powerpc on Virtex4), and
my next step is to port VNC server on it.
Is there a place I could download VNC on PowerPC?
Thanks a lot!
Regards,
Kevin
^ permalink raw reply
* Re: port VNC to Xilinx ppc
From: Grant Likely @ 2007-12-16 6:10 UTC (permalink / raw)
To: d8341linux; +Cc: Linuxppc-embedded
In-Reply-To: <1197779997.21822.3.camel@localhost.localdomain>
On 12/15/07, d8341linux <d8341linux@gmail.com> wrote:
> Hi, All:
>
> I have booted up linux on Xilinx ML403 board (powerpc on Virtex4), and
> my next step is to port VNC server on it.
>
> Is there a place I could download VNC on PowerPC?
I'd recommend going to one of the VNC providers. Google is your friend.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: David Gibson @ 2007-12-16 6:19 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1197705316-17618-1-git-send-email-sr@denx.de>
On Sat, Dec 15, 2007 at 08:55:16AM +0100, Stefan Roese wrote:
> Signed-off-by: Stefan Roese <sr@denx.de>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
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] [POWERPC] FSL: enet device tree cleanups
From: David Gibson @ 2007-12-16 6:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0712120151590.25255@blarg.am.freescale.net>
On Wed, Dec 12, 2007 at 01:52:05AM -0600, Kumar Gala wrote:
> * Removed address fields in ethernet nodes
> * Removed #address-cells, #size-cells from gianfar nodes
> * Added cell-index to gianfar and ucc ethernet nodes
> * Added enet[0..3] labels
> * Renamed compatible node for gianfar mdio to "fsl,gianfar-mdio"
> * Removed device_type = "mdio"
Hurrah! Finally.
> The matching for gianfar mdio still supports the old "mdio"/"gianfar" combo
> but it is now considered deprecated.
That's fine. It's acceptable to keep match list entries for broken
trees around pretty much indefinitely.
--
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 2/3] mpc82xx: Embedded Planet EP8248E support
From: David Gibson @ 2007-12-16 6:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071211212247.GB3620@loki.buserror.net>
On Tue, Dec 11, 2007 at 03:22:47PM -0600, Scott Wood wrote:
[snip]
> + bcsr@1,0 {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <1 0 10>;
> + compatible = "fsl,ep8248e-bcsr";
> + ranges;
> +
> + mdio {
> + device_type = "mdio";
> + compatible = "fsl,ep8248e-mdio-bitbang";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1 8 1>;
> +
> + PHY0: ethernet-phy@0 {
> + interrupt-parent = <&PIC>;
> + reg = <0>;
> + device_type = "ethernet-phy";
> + };
> +
> + PHY1: ethernet-phy@1 {
> + interrupt-parent = <&PIC>;
> + reg = <1>;
> + device_type = "ethernet-phy";
> + };
> + };
> + };
This mdio-under-bcsr arrangement is a bit strange. Can you explain
what's going on here?
--
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 1/5] PowerPC 74xx: Katana Qp device tree
From: David Gibson @ 2007-12-16 6:40 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Linuxppc-dev
In-Reply-To: <20071210211816.4657.qmail@farnsworth.org>
On Mon, Dec 10, 2007 at 02:18:16PM -0700, Dale Farnsworth wrote:
> David Gibson wrote:
> > On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote:
> > > Device tree source file for the Emerson Katana Qp board
>
> [snip]
>
> > > + mv64x60@f8100000 { /* Marvell Discovery */
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + model = "mv64460"; /* Default */
> > > + compatible = "marvell,mv64x60";
>
> [snip]
>
> > > + mdio {
> >
> > There must be some way of actuall accessing the mdio bus, so this node
> > ought to have a 'reg' property and unit address.
>
> There is no way for the cpu to directly access the mdio bus. The
> mdio bus is internally accessed by the ethernet MAC. That being the
> case, maybe it makes more sense to move the mdio node inside of the
> multiethernet node, as follows, but I don't see how we can give it
> a reg property or a unit address.
Ah, I see. If the mdio interface isn't distinct from the other
pieces, then it probably shouldn't get a device node at all. Having
an explicit mdio bus with the phys hanging off it is convenient for
hardware which actually works that way, but it doesn't have to be done
like that.
Of course, then the question is where to hang the phy nodes, which
look like they have information you need. Since you already have a
local addressing scheme for the MACs under the multiethernet, what
probably makes sense would be to hang the phys directly under the
multiethernet, using an encoding scheme for the reg properties so that
the MACs and PHYs aren't confused (say, MACs are 0x0, 0x1, 0x2, PHYs
are 0x80000000, 0x80000001, 0x80000002).
Incidentally, although I suggested it, I'm not all that fond of the
"multiethernet" name, it was just the first thing that occurred to me.
>
> multiethernet@2000 {
> reg = <0x2000 0x2000>;
> ethernet@0 {
> device_type = "network";
> compatible = "marvell,mv64360-eth";
> reg = <0>;
> interrupts = <32>;
> interrupt-parent = <&PIC>;
> phy = <&PHY0>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> };
> ethernet@1 {
> device_type = "network";
> compatible = "marvell,mv64360-eth";
> reg = <1>;
> interrupts = <33>;
> interrupt-parent = <&PIC>;
> phy = <&PHY1>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> };
> mdio {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "mdio";
> compatible = "marvell,mv64360-mdio";
> PHY0: ethernet-phy@1 {
> device_type = "ethernet-phy";
> compatible = "broadcom,bcm5421";
> interrupts = <76>; /* GPP 12 */
> interrupt-parent = <&PIC>;
> reg = <1>;
> };
> PHY1: ethernet-phy@3 {
> device_type = "ethernet-phy";
> compatible = "broadcom,bcm5421";
> interrupts = <76>; /* GPP 12 */
> interrupt-parent = <&PIC>;
> reg = <3>;
> };
> };
> };
--
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 RFC 0/7] "NAND on UPM" and related patches
From: David Gibson @ 2007-12-16 6:44 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071212124732.GA3904@localhost.localdomain>
On Wed, Dec 12, 2007 at 03:47:32PM +0300, Anton Vorontsov wrote:
> On Tue, Dec 11, 2007 at 11:36:47AM +1100, David Gibson wrote:
> [...]
> > > > > OF device tree GPIOs bindings are similar to IRQs:
> > > > >
> > > > > node {
> > > > > gpios = <bank pin bank pin bank pin>;
> > > > > gpio-parent = <&par_io_controller>;
> > > > > };
> > > > >
> > > > > "bank pin" scheme is controller specific, so controllers that want
> > > > > to implement flat mappings or any other could do so.
> > > >
> > > > It might be safest to do as is done for interrupts, and not define the
> > > > internal format at all.
> > >
> > > This is how it is done already. Take a look into second and third patches:
> > >
> > > +static int par_io_xlate(struct device_node *np, int index)
> > > +{
> > > + return __of_parse_gpio_bank_pin(np, index, 32, num_par_io_ports);
> > > +}
> > > +
> > > +static struct of_gpio_chip of_gpio_chip = {
> > > + .xlate = par_io_xlate,
> > > +};
> > >
> > > __of_parse_gpio_bank_pin() is helper function, I just factored
> > > it out, because both QE and CPM2 using same format.
> > >
> > > But generally, controllers are encouraged to do their own xlates.
> > >
> > > Or am I missing the point?
> >
> > Right, but you are assuming a fixed size (2 cells?)
>
> Nope, of_get_gpio() doesn't assume that, but per-controller's .xlate()
> is free to assume (and check) that, right.
Ah, ok, I see. I think doing this without an explicit '#gpio-cells'
is not a great idea, though. It would be nice to be able to sanity
check the "gpio descriptors" without having to deduce the correct
format from the controller's "compatible" property.
--
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: Device Tree updates for xilinx.
From: David Gibson @ 2007-12-16 7:04 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, Michal Simek, git
In-Reply-To: <20071213233945.E8FFAA6007C@mail180-sin.bigfish.com>
On Thu, Dec 13, 2007 at 03:41:16PM -0800, Stephen Neuendorffer wrote:
> These patches synchronize all the in-kernel drivers to use the
> compatible names generated by the UBoot BSP generator.
> (at git://git.xilinx.com/gen-mhs-devtree.git)
>
> The patches to make this work are coming shortly:
>
> patches 1-2 are provided for context only... They're not ready for
> mainline. They provide 'raw' boot support and port some initialization
> code from ARCH=ppc.
> patches 3-7 are the interesting patches, which I think could be taken
> for 2.6.25.
>
> I've also pushed the working tree up to git.xilinx.com containing these
> patches. This tree also includes updates for ps2, gpio, etc.
> The ll_temac currently doesn't work because I haven't gone back and
> fixed the mechanism by which it finds out about the DMA that it is
> connected to.
>
> If you want output from the boot loader, you'll need something like:
> linux,stdout-path = "/plb_v34/opb_v20/serial@40400000";
> This seems to work with uartlite, but I wasn't able to get it working
> with a UART design.
>
> Currently, you'll need to add, by hand the following labels:
>
> mem_size_cells, on the toplevel #address-cells attribue, e,g. :
> mem_size_cells: #address-cells = <1>;
Having a label called *_size_cells which is attached to
#address-cells, rather than #size-cells seems like a bad idea. Plus,
if I understood correctly, this is used to interpret the 'memsize'
value, which means it should be #size-cells anyway.
Also, if I understood the code in your later patches correctly, this
label is used as a direct pointer to the value you want. That means
it needs to be on the property value, not on the property, i.e.
#size-cells = <mem_size_cells: 1>;
instead of
mem_size_cells: #size-cells = <1>;
(the latter form will put the label on the tag which introduces the
property instead).
> timebase, on the processors timebase-frequency attribute, e.g. :
> timebase: timebase-frequency = <11e1a300>;
>
> memsize, on the memory's size, e.g.:
> DDR_256MB_32MX64_rank1_row13_col10_cl2_5: memory@0 {
> device_type = "memory";
> reg = < 0 memsize:10000000 >;
> } ;
>
> In addition, if you're using uartlite, you'll have to specify
> 'console=ttyUL0' as boot args.
>
> For reference, below is the device tree for a Virtex2Pro design. Except
> for the changes noted above, this is entirely automatically generated.
>
> Steve
>
> / {
> mem_size_cells: #address-cells = <1>;
> #size-cells = <1>;
> compatible = "xlnx,virtex";
> model = "testing";
> DDR_256MB_32MX64_rank1_row13_col10_cl2_5: memory@0 {
> device_type = "memory";
> reg = < 0 memsize:10000000 >;
> } ;
> chosen {
> bootargs = "root=/dev/nfs
> nfsroot=172.19.221.221:/exports/xup/ydl41 ip=dhcp console=ttyUL0";
> } ;
> cpus {
> #address-cells = <1>;
> #cpus = <1>;
> #size-cells = <0>;
> PowerPC,405@0 {
I'm trying to encourage people to move to naming cpu nodes simply
"cpu@XX", with the type of core in "compatible" instead - in keeping
with the generic names convention used elsewhere. I think this will
make your generator simpler, too.
--
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 1/7] bootwrapper: Add a firmware-independent "raw" target.
From: David Gibson @ 2007-12-16 11:35 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <f7eb0ae3da29213720e6b0049deca335@bga.com>
On Fri, Dec 14, 2007 at 02:05:56AM -0600, Milton Miller wrote:
> On Fri Dec 14 10:43:27 EST 2007, Stephen Neuendorffer wrote:
>
> > From: Grant Likely <grant.likely at secretlab.ca>
> >
> > This target produces a flat binary rather than an ELF file,
> > fixes the entry point at the beginning of the image, and takes
> > a complete device tree with no fixups needed.
> >
> > The device tree must have labels on /#address-cells, the timebase
> > frequency, and the memory size.
> >
> > Signed-off-by: Grant Likely <grant.likely at secretlab.ca>
> > ---
>
>
> You indicated in the intro in 0/ that this was not ready, and you
> didn't include your own s-o-b, but you did not put any statements to
> that effect in the header. The intro is not copied into patchwork,
> which maintainers often use when deciding what to push.
>
> Now on to why this should not be merged:
>
> In addition to the above, it changes the build rules. It tries to
> change wrapper to assemble the .dtb into a .o from a .S file, but
> doesn't set any flags to force the assembler into the right mode. In
> contrast the linker is controlled by the .lds linker script.
>
> In addition, the requirement for assembly labels can easily be
> eliminated. As mentioned above, they are used for 3 properties. With
> the existing library (in 2.6.24 and earlier), call simple_malloc_init
> with a small bss array (like BSS_STACK does to allocate stack), and
> then read the properties out of the device tree. At that point, call
> simple_malloc_init a second time using the found memory size. As I
> said the last time this was posted, my patches to boot from kexec
> implemented this strategy.
>
> However, with the new libfdt, which is already in for-2.6.25, we should
> no longer need malloc() to simple read the tree. At least that is
> what was advertised.
That's correct. No malloc() is necessary for read-only access.
--
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 1/3] [libata] pata_platform: make probe and remove functions device type neutral
From: Paul Mundt @ 2007-12-16 12:46 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Jeff Garzik, Arnd Bergmann, linux-ide, linuxppc-dev,
Olof Johansson
In-Reply-To: <20071214182429.GA1017@localhost.localdomain>
On Fri, Dec 14, 2007 at 09:24:29PM +0300, Anton Vorontsov wrote:
> Split pata_platform_{probe,remove} into two pieces:
> 1. pata_platform_{probe,remove} -- platform_device-dependant bits;
> 2. __ptata_platform_{probe,remove} -- device type neutral bits.
>
> This is done to not duplicate code for the OF-platform driver.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> Acked-by: Olof Johansson <olof@lixom.net>
Looks fine to me now, thanks for cleaning it up Anton.
Acked-by: Paul Mundt <lethal@linux-sh.org>
^ permalink raw reply
* [MPC5200] problem running FEC and ATA
From: Arnon Kaufman @ 2007-12-16 13:24 UTC (permalink / raw)
To: linuxppc-dev
does any one succeed running a functional FEC and ATA (pata) running
together ?
If so which version (2.6.x...) and with which architecture (powerpc or
ppc)?.
The machine I'm working on based on v2.6.21-rc6 and another one based on
v2.6.24-rc1, both configured with ARCH=powerpc.
my FEC introduce itself as: "PHY: f0003000:01", and not as f0003000:00,
I've fix it by adjusting the dts file, is that ok?
I'm getting the following, when pinging the machine:
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4401 ttl=64 time=0.249 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4402 ttl=64 time=0.285 ms
wrong data byte #52 should be 0x34 but was 0xa
#8 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27
#40 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 a 35 36 37
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4403 ttl=64 time=0.233 ms
wrong data byte #20 should be 0x14 but was 0x0
#8 8 9 a b c d e f 10 11 12 13 0 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27
#40 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4404 ttl=64 time=0.232 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4405 ttl=64 time=0.237 ms
-----
The offsets and values of the corrupted data are constant (can it be the
microcode?)
when enabling the PATA driver and doing some Compact flash access
operation the amount of packets corruption is getting worse.
does the pata driver needs to wait on the TIP indicator? cause it
doesn't seems to do it.
^ permalink raw reply
* Re: Device Tree updates for xilinx.
From: Josh Boyer @ 2007-12-16 13:38 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Michal Simek, git
In-Reply-To: <20071216070404.GK21311@localhost.localdomain>
On Sun, 16 Dec 2007 18:04:04 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:
> > cpus {
> > #address-cells = <1>;
> > #cpus = <1>;
> > #size-cells = <0>;
> > PowerPC,405@0 {
>
> I'm trying to encourage people to move to naming cpu nodes simply
> "cpu@XX", with the type of core in "compatible" instead - in keeping
> with the generic names convention used elsewhere. I think this will
> make your generator simpler, too.
cpu@XX with the model property of the node set to "PowerPC,405" please.
josh
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: Josh Boyer @ 2007-12-16 14:58 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20071216061959.GD21311@localhost.localdomain>
On Sun, 16 Dec 2007 17:19:59 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Sat, Dec 15, 2007 at 08:55:16AM +0100, Stefan Roese wrote:
> > Signed-off-by: Stefan Roese <sr@denx.de>
> Acked-by: David Gibson <david@gibson.dropbear.id.au>
Applied to my candidates tree. Though I'd really like dtc to be merged
so that we can figure out what the in-kernel version will support.
josh
^ permalink raw reply
* Re: [MPC5200] problem running FEC and ATA
From: Robert Schwebel @ 2007-12-16 15:44 UTC (permalink / raw)
To: Arnon Kaufman; +Cc: linuxppc-dev
In-Reply-To: <47652712.60006@gmail.com>
On Sun, Dec 16, 2007 at 03:24:34PM +0200, Arnon Kaufman wrote:
> does any one succeed running a functional FEC and ATA (pata) running
> together?
Yes, we do, on the phyCORE-MPC5200B-tiny; you can check our patches here:
http://www.pengutronix.de/oselas/bsp/phytec/download/phyCORE-MPC5200B-tiny/
We've recently made the -6 release which supports ATA; although I'm not
sure if the tests were done with networking & ATA at the same time I
assume yes (at least while doing nfsroot). We'll re-check your scenario.
Note that there has been quite some activity wrt. MPC5200, bestcom and
fec in the mainline recently. You should test the latest 2.6.24-rc
kernel.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [PATCH 2/3] mpc82xx: Embedded Planet EP8248E support
From: Scott Wood @ 2007-12-16 15:48 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <20071216063020.GG21311@localhost.localdomain>
On Sun, Dec 16, 2007 at 05:30:20PM +1100, David Gibson wrote:
> This mdio-under-bcsr arrangement is a bit strange. Can you explain
> what's going on here?
It's pretty much what it looks like; MDIO is connected to a couple pins
that are controlled by some bits in the BCSR.
-Scott
^ permalink raw reply
* Re: [MPC5200] problem running FEC and ATA
From: Arnon Kaufman @ 2007-12-16 17:28 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linuxppc-dev
In-Reply-To: <20071216154458.GZ3851@pengutronix.de>
Robert Schwebel wrote:
> On Sun, Dec 16, 2007 at 03:24:34PM +0200, Arnon Kaufman wrote:
>> does any one succeed running a functional FEC and ATA (pata) running
>> together?
>
> Yes, we do, on the phyCORE-MPC5200B-tiny; you can check our patches here:
> http://www.pengutronix.de/oselas/bsp/phytec/download/phyCORE-MPC5200B-tiny/
>
thanks, my kernels are already patched and still observing that kind of
behavior. I'm using Domen's new FEC code and ATA from 2.6.24-rc2.
playing with the XLB Master's enable and priority lead to significant
changes (good ones) in the rate of corruption appearance. I'm afraid of
the "new" priority I've set, as that may lead to lockups on the XLB,
still investigating.
> We've recently made the -6 release which supports ATA; although I'm not
> sure if the tests were done with networking & ATA at the same time I
> assume yes (at least while doing nfsroot). We'll re-check your scenario.
>
> Note that there has been quite some activity wrt. MPC5200, bestcom and
> fec in the mainline recently. You should test the latest 2.6.24-rc
> kernel.
>
> Robert
^ permalink raw reply
* Re: [MPC5200] problem running FEC and ATA
From: Robert Schwebel @ 2007-12-16 17:46 UTC (permalink / raw)
To: Arnon Kaufman; +Cc: linuxppc-dev
In-Reply-To: <47656048.7060809@gmail.com>
On Sun, Dec 16, 2007 at 07:28:40PM +0200, Arnon Kaufman wrote:
> Robert Schwebel wrote:
> >On Sun, Dec 16, 2007 at 03:24:34PM +0200, Arnon Kaufman wrote:
> >>does any one succeed running a functional FEC and ATA (pata) running
> >>together?
> >
> >Yes, we do, on the phyCORE-MPC5200B-tiny; you can check our patches here:
> >http://www.pengutronix.de/oselas/bsp/phytec/download/phyCORE-MPC5200B-tiny/
>
> thanks, my kernels are already patched and still observing that kind of
> behavior. I'm using Domen's new FEC code and ATA from 2.6.24-rc2.
>
> playing with the XLB Master's enable and priority lead to significant
> changes (good ones) in the rate of corruption appearance. I'm afraid of
> the "new" priority I've set, as that may lead to lockups on the XLB,
> still investigating.
Do you have a reproducable test scenario we can try on our hardware?
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: Segher Boessenkool @ 2007-12-16 18:10 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese, David Gibson
In-Reply-To: <20071216085858.55ffddbe@vader.jdub.homelinux.org>
> Applied to my candidates tree. Though I'd really like dtc to be merged
> so that we can figure out what the in-kernel version will support.
Hopefully some version that stores path strings in the properties
in /aliases, and not phandles. Or does that current version of DTC
do that correctly already, and just has an inconvenient source syntax?
Segher
^ permalink raw reply
* [PATCH 1/2] [RESEND] ps3: vuart: fix error path locking
From: Daniel Walker @ 2007-12-16 8:00 UTC (permalink / raw)
To: akpm
Cc: matthias.kaehlcke, linux-kernel, linux, linuxppc-dev, mingo,
kjwinchester
This stray down would cause a permanent sleep which doesn't seem correct.
The other uses of this semaphore appear fairly mutex like it's even initialized
with init_MUTEX() .. So here a patch for removing this one down().
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Daniel Walker <dwalker@mvista.com>
---
drivers/ps3/ps3-vuart.c | 1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.23/drivers/ps3/ps3-vuart.c
===================================================================
--- linux-2.6.23.orig/drivers/ps3/ps3-vuart.c
+++ linux-2.6.23/drivers/ps3/ps3-vuart.c
@@ -1072,7 +1072,6 @@ static int ps3_vuart_probe(struct ps3_sy
if (result) {
dev_dbg(&dev->core, "%s:%d: drv->probe failed\n",
__func__, __LINE__);
- down(&vuart_bus_priv.probe_mutex);
goto fail_probe;
}
--
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: Josh Boyer @ 2007-12-16 18:45 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Stefan Roese, paulus, David Gibson
In-Reply-To: <f3ddb435a7a71cea8362ed73eb154200@kernel.crashing.org>
On Sun, 16 Dec 2007 19:10:02 +0100
Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > Applied to my candidates tree. Though I'd really like dtc to be merged
> > so that we can figure out what the in-kernel version will support.
>
> Hopefully some version that stores path strings in the properties
> in /aliases, and not phandles. Or does that current version of DTC
> do that correctly already, and just has an inconvenient source syntax?
I have no idea. I can't even keep track of whether various DTC
features are dts-v1 only or not, and which "version" of DTC supports
which features. That's why I'm sort of waiting for Paul to merge
whatever version of DTC he is going to merge. *HINT*
We should also probably make a clear cut DTC release Real Soon Now.
*HINT*
josh
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: David Gibson @ 2007-12-16 22:30 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20071216085858.55ffddbe@vader.jdub.homelinux.org>
On Sun, Dec 16, 2007 at 08:58:58AM -0600, Josh Boyer wrote:
> On Sun, 16 Dec 2007 17:19:59 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > On Sat, Dec 15, 2007 at 08:55:16AM +0100, Stefan Roese wrote:
> > > Signed-off-by: Stefan Roese <sr@denx.de>
> > Acked-by: David Gibson <david@gibson.dropbear.id.au>
>
> Applied to my candidates tree. Though I'd really like dtc to be merged
> so that we can figure out what the in-kernel version will support.
I know, I know. I've been a little preoccupied lately and need to get
back to working out what to do with the merge patches.
--
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] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: David Gibson @ 2007-12-16 22:33 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <f3ddb435a7a71cea8362ed73eb154200@kernel.crashing.org>
On Sun, Dec 16, 2007 at 07:10:02PM +0100, Segher Boessenkool wrote:
> > Applied to my candidates tree. Though I'd really like dtc to be merged
> > so that we can figure out what the in-kernel version will support.
>
> Hopefully some version that stores path strings in the properties
> in /aliases, and not phandles. Or does that current version of DTC
> do that correctly already, and just has an inconvenient source
> syntax?
I don't think anyone's actually gone and generated phandles in
/aliases, although it was suggested early on. The syntax is
foo = < &bar >;
to generate a phandle and
foo = &bar;
to generate a path.
I was a bit worried about confusion between these forms, but at least
Kumar and myself came up with this syntax independently, which
suggests it's not too surprising to most people, and no-one had any
other suggestions.
--
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
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