* Start the consolidation of the OpenFrimware support routines
From: Stephen Rothwell @ 2007-07-18 7:30 UTC (permalink / raw)
To: ppc-dev, sparclinux; +Cc: paulus, David S. Miller, wli
[-- Attachment #1: Type: text/plain, Size: 3908 bytes --]
Hi Dave, Paul,
The latest version of the changes is available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/ofcons.git master
I will send patches to the lists if people want them. The only changes
from the previous version is to merge with Linus' current tree (there
were various conflicts with PowerPC changes). This has been built for
Sparc and Sparc64 defconfigs but I have no Sparc hardware to boot on. It
has also been built for PowerPC allmodconfig and ppc64_defconfig - the
latter has been booted on an iSeries box.
The intention here is that there should be no behavioural changes and
minimal code changes (apart from movement of the code to common places).
There are, however a couple of unavoidable changes:
- some of the accessor functions now take a read lock on Sparc[64]
where they didn't before.
- the bus structures are initialised at runtime.
If people are happy with this, I will submit it directly to Linus.
Stephen Rothwell (12):
Split out common parts of prom.h
Start split out of common open firmware code
Consolidate of_device_is_compatible
Consolidate of_find_property
Consolidate of_get_parent
Consolidate of_get_next_child
Consolidate of_find_node_by routines
Begin to consolidate of_device.c
Begin consolidation of of_device.h
[SPARC/64] Rename some functions like PowerPC
Create linux/of_platorm.h
Create drivers/of/platform.c
arch/powerpc/Kconfig | 3 +
arch/powerpc/kernel/of_device.c | 122 +----------------
arch/powerpc/kernel/of_platform.c | 82 +-----------
arch/powerpc/kernel/prom.c | 250 +---------------------------------
arch/sparc/Kconfig | 3 +
arch/sparc/kernel/of_device.c | 222 ++----------------------------
arch/sparc/kernel/prom.c | 173 +-----------------------
arch/sparc/kernel/time.c | 2 +-
arch/sparc64/Kconfig | 3 +
arch/sparc64/kernel/auxio.c | 2 +-
arch/sparc64/kernel/of_device.c | 238 +++-----------------------------
arch/sparc64/kernel/power.c | 2 +-
arch/sparc64/kernel/prom.c | 173 +-----------------------
arch/sparc64/kernel/time.c | 2 +-
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/of/Kconfig | 3 +
drivers/of/Makefile | 2 +
drivers/of/base.c | 275 +++++++++++++++++++++++++++++++++++++
drivers/of/device.c | 131 ++++++++++++++++++
drivers/of/platform.c | 96 +++++++++++++
include/asm-powerpc/of_device.h | 22 +---
include/asm-powerpc/of_platform.h | 38 +-----
include/asm-powerpc/prom.h | 50 ++-----
include/asm-sparc/of_device.h | 49 +------
include/asm-sparc/of_platform.h | 32 +++++
include/asm-sparc/prom.h | 62 +++------
include/asm-sparc64/of_device.h | 50 +------
include/asm-sparc64/of_platform.h | 33 +++++
include/asm-sparc64/prom.h | 62 +++------
include/linux/of.h | 61 ++++++++
include/linux/of_device.h | 26 ++++
include/linux/of_platform.h | 57 ++++++++
33 files changed, 846 insertions(+), 1483 deletions(-)
create mode 100644 drivers/of/Kconfig
create mode 100644 drivers/of/Makefile
create mode 100644 drivers/of/base.c
create mode 100644 drivers/of/device.c
create mode 100644 drivers/of/platform.c
create mode 100644 include/asm-sparc/of_platform.h
create mode 100644 include/asm-sparc64/of_platform.h
create mode 100644 include/linux/of.h
create mode 100644 include/linux/of_device.h
create mode 100644 include/linux/of_platform.h
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Start the consolidation of the OpenFrimware support routines
From: David Miller @ 2007-07-18 7:36 UTC (permalink / raw)
To: sfr; +Cc: sparclinux, linuxppc-dev, paulus, wli
In-Reply-To: <20070718173024.50204a1a.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 18 Jul 2007 17:30:24 +1000
> Hi Dave, Paul,
>
> The latest version of the changes is available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sfr/ofcons.git master
>
> I will send patches to the lists if people want them. The only changes
> from the previous version is to merge with Linus' current tree (there
> were various conflicts with PowerPC changes). This has been built for
> Sparc and Sparc64 defconfigs but I have no Sparc hardware to boot on. It
> has also been built for PowerPC allmodconfig and ppc64_defconfig - the
> latter has been booted on an iSeries box.
>
> The intention here is that there should be no behavioural changes and
> minimal code changes (apart from movement of the code to common places).
> There are, however a couple of unavoidable changes:
> - some of the accessor functions now take a read lock on Sparc[64]
> where they didn't before.
> - the bus structures are initialised at runtime.
>
> If people are happy with this, I will submit it directly to Linus.
No objections here. If the read lock or bus initialization issue
causes problems, I'll fix it up after this gets merged in, don't worry
about it.
^ permalink raw reply
* Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
From: Andrew Morton @ 2007-07-18 7:52 UTC (permalink / raw)
To: netdev, Eugene Surovegin, linuxppc-embedded
Cc: bart.vanassche, bugme-daemon@kernel-bugs.osdl.org
In-Reply-To: <bug-8778-10286@http.bugzilla.kernel.org/>
On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8778
>
> Summary: Ocotea board: kernel reports access of bad area during
> boot with DEBUG_SLAB=y
> Product: Platform Specific/Hardware
> Version: 2.5
> KernelVersion: 2.6.22
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: PPC-32
> AssignedTo: platform_ppc-32@kernel-bugs.osdl.org
> ReportedBy: bart.vanassche@gmail.com
>
>
> Most recent kernel where this bug did not occur: not known - was probably
> already an issue in 2.6.10
> Distribution: not relevant for this issue.
> Hardware Environment: AMCC Ocotea board
> Software Environment: not relevant for this issue.
> Problem Description: see title.
>
> Steps to reproduce:
> 1. Compile the 2.6.22 kernel with the attached .config
> 2. Boot an Ocotea board with this kernel.
> 3. Observe the output that appears on the serial console.
>
> U-Boot 1.1.1 (Nov 10 2005 - 16:29:34)
>
> IBM PowerPC 440 GUNKNOWN (PVR=51b21892)
> Board: IBM 440GX Evaluation Board
> VCO: 1066 MHz
> CPU: 533 MHz
> PLB: 152 MHz
> OPB: 76 MHz
> EPB: 76 MHz
> I2C: ready
> DRAM: I2c read: failed 4
> I2c read: failed 4
> 256 MB
> FLASH: 5 MB
> PCI: Bus Dev VenId DevId Class Int
> In: serial
> Out: serial
> Err: serial
> KGDB: kgdb ready
> ready
> Net: ppc_440x_eth0
> BEDBUG:ready
> => boot
> Waiting for PHY auto negotiation to complete.. done
> ENET Speed is 100 Mbps - FULL duplex connection
> Using ppc_440x_eth0 device
> TFTP from server 172.30.36.154; our IP address is 172.30.39.77
> Filename 'ocotea-vanassb'.
> Load address: 0x1000000
> Loading: T #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################
> done
> Bytes transferred = 1415440 (159910 hex)
> Automatic boot of image at addr 0x01000000 ...
> ## Booting image at 01000000 ...
> Image Name: Linux-2.6.22
> Created: 2007-07-18 6:53:56 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1415376 Bytes = 1.3 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Linux version 2.6.22 (vanassb@sabekorlnx05) (gcc version 3.4.3 (MontaVista
> 3.4.7
> IBM Ocotea port (MontaVista Software, Inc. <source@mvista.com>)
> Zone PFN ranges:
> DMA 0 -> 65536
> Normal 65536 -> 65536
> early_node_map[1] active PFN ranges
> 0: 0 -> 65536
> Built 1 zonelists. Total pages: 65024
> Kernel command line: root=/dev/nfs
> nfsroot=172.30.36.154:/nfs-export/RFS_MVL4-00
> PID hash table entries: 1024 (order: 10, 4096 bytes)
> ------------------------
> | Locking API testsuite:
> ----------------------------------------------------------------------------
> | spin |wlock |rlock |mutex | wsem | rsem |
> --------------------------------------------------------------------------
> A-A deadlock:failed|failed| ok |failed|failed|failed|
> A-B-B-A deadlock:failed|failed| ok |failed|failed|failed|
> A-B-B-C-C-A deadlock:failed|failed| ok |failed|failed|failed|
> A-B-C-A-B-C deadlock:failed|failed| ok |failed|failed|failed|
> A-B-B-C-C-D-D-A deadlock:failed|failed| ok |failed|failed|failed|
> A-B-C-D-B-D-D-A deadlock:failed|failed| ok |failed|failed|failed|
> A-B-C-D-B-C-D-A deadlock:failed|failed| ok |failed|failed|failed|
> double unlock: ok | ok |failed| ok |failed|failed|
> initialize held:failed|failed|failed|failed|failed|failed|
> bad unlock order: ok | ok | ok | ok | ok | ok |
> --------------------------------------------------------------------------
> recursive read-lock: | ok | |failed|
> recursive read-lock #2: | ok | |failed|
> mixed read-write-lock: |failed| |failed|
> mixed write-read-lock: |failed| |failed|
> --------------------------------------------------------------------------
> hard-irqs-on + irq-safe-A/12:failed|failed| ok |
> soft-irqs-on + irq-safe-A/12:failed|failed| ok |
> hard-irqs-on + irq-safe-A/21:failed|failed| ok |
> soft-irqs-on + irq-safe-A/21:failed|failed| ok |
> sirq-safe-A => hirqs-on/12:failed|failed| ok |
> sirq-safe-A => hirqs-on/21:failed|failed| ok |
> hard-safe-A + irqs-on/12:failed|failed| ok |
> soft-safe-A + irqs-on/12:failed|failed| ok |
> hard-safe-A + irqs-on/21:failed|failed| ok |
> soft-safe-A + irqs-on/21:failed|failed| ok |
> hard-safe-A + unsafe-B #1/123:failed|failed| ok |
> soft-safe-A + unsafe-B #1/123:failed|failed| ok |
> hard-safe-A + unsafe-B #1/132:failed|failed| ok |
> soft-safe-A + unsafe-B #1/132:failed|failed| ok |
> hard-safe-A + unsafe-B #1/213:failed|failed| ok |
> soft-safe-A + unsafe-B #1/213:failed|failed| ok |
> hard-safe-A + unsafe-B #1/231:failed|failed| ok |
> soft-safe-A + unsafe-B #1/231:failed|failed| ok |
> hard-safe-A + unsafe-B #1/312:failed|failed| ok |
> soft-safe-A + unsafe-B #1/312:failed|failed| ok |
> hard-safe-A + unsafe-B #1/321:failed|failed| ok |
> soft-safe-A + unsafe-B #1/321:failed|failed| ok |
> hard-safe-A + unsafe-B #2/123:failed|failed| ok |
> soft-safe-A + unsafe-B #2/123:failed|failed| ok |
> hard-safe-A + unsafe-B #2/132:failed|failed| ok |
> soft-safe-A + unsafe-B #2/132:failed|failed| ok |
> hard-safe-A + unsafe-B #2/213:failed|failed| ok |
> soft-safe-A + unsafe-B #2/213:failed|failed| ok |
> hard-safe-A + unsafe-B #2/231:failed|failed| ok |
> soft-safe-A + unsafe-B #2/231:failed|failed| ok |
> hard-safe-A + unsafe-B #2/312:failed|failed| ok |
> soft-safe-A + unsafe-B #2/312:failed|failed| ok |
> hard-safe-A + unsafe-B #2/321:failed|failed| ok |
> soft-safe-A + unsafe-B #2/321:failed|failed| ok |
> hard-irq lock-inversion/123:failed|failed| ok |
> soft-irq lock-inversion/123:failed|failed| ok |
> hard-irq lock-inversion/132:failed|failed| ok |
> soft-irq lock-inversion/132:failed|failed| ok |
> hard-irq lock-inversion/213:failed|failed| ok |
> soft-irq lock-inversion/213:failed|failed| ok |
> hard-irq lock-inversion/231:failed|failed| ok |
> soft-irq lock-inversion/231:failed|failed| ok |
> hard-irq lock-inversion/312:failed|failed| ok |
> soft-irq lock-inversion/312:failed|failed| ok |
> hard-irq lock-inversion/321:failed|failed| ok |
> soft-irq lock-inversion/321:failed|failed| ok |
> hard-irq read-recursion/123: ok |
> soft-irq read-recursion/123: ok |
> hard-irq read-recursion/132: ok |
> soft-irq read-recursion/132: ok |
> hard-irq read-recursion/213: ok |
> soft-irq read-recursion/213: ok |
> hard-irq read-recursion/231: ok |
> soft-irq read-recursion/231: ok |
> hard-irq read-recursion/312: ok |
> soft-irq read-recursion/312: ok |
> hard-irq read-recursion/321: ok |
> soft-irq read-recursion/321: ok |
> --------------------------------------------------------
> 142 out of 218 testcases failed, as expected. |
> ----------------------------------------------------
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Memory: 256768k available (2088k kernel code, 816k data, 128k init, 0k highmem)
> Mount-cache hash table entries: 512
> NET: Registered protocol family 16
> PCI: Probing PCI hardware
> NET: Registered protocol family 2
> IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
> TCP established hash table entries: 8192 (order: 5, 163840 bytes)
> TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP reno registered
> Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> io scheduler noop registered
> io scheduler deadline registered (default)
> Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
> serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
> serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: module loaded
> PPC 4xx OCP EMAC driver, version 3.54
> mal0: initialized, 4 TX channels, 4 RX channels
> zmii0: bridge in SMII mode
> eth0: emac0, MAC 00:04:ac:e3:28:8a
> eth0: found Generic MII PHY (0x01)
> eth1: emac1, MAC 00:00:00:00:00:00
> eth1: found Generic MII PHY (0x02)
> rgmii0: input 0 in RGMII mode
> eth2: emac2, MAC 00:00:00:00:00:00
> eth2: found CIS8201 Gigabit Ethernet PHY (0x10)
> rgmii0: input 1 in RGMII mode
> eth3: emac3, MAC 00:00:00:00:00:00
> eth3: found CIS8201 Gigabit Ethernet PHY (0x18)
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
> i2c /dev entries driver
> IBM IIC driver v2.1
> ibm-iic0: using standard (100 kHz) mode
> ibm-iic1: using standard (100 kHz) mode
> Netfilter messages via NETLINK v0.30.
> TCP cubic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> eth0: link is down
> IP-Config: Complete:
> device=eth0, addr=172.30.39.77, mask=255.255.252.0, gw=172.30.39.254,
> host=ocotea, domain=, nis-domain=(none),
> bootserver=172.30.36.154, rootserver=172.30.36.154, rootpath=
> Looking up port of RPC 100003/3 on 172.30.36.154
> eth0: link is up, 100 FDX, pause enabled
> Looking up port of RPC 100005/3 on 172.30.36.154
> VFS: Mounted root (nfs filesystem) readonly.
> Freeing unused kernel memory: 128k init
> Oops: kernel access of bad area, sig: 11 [#1]
> PREEMPT
> NIP: c004be40 LR: c017d9d8 CTR: c01822fc
> REGS: c02b1af0 TRAP: 0300 Not tainted (2.6.22)
> MSR: 00029000 <EE,ME> CR: 28f22b24 XER: 20000000
> DAR: 99750000, DSISR: 00000000
> TASK = c0296830[0] 'swapper' THREAD: c02b0000
> GPR00: c017d9d8 c02b1ba0 c0296830 99750000 c026cb38 000000f8 3b92a76c c02d73ec
> GPR08: 0000000c 99750004 00000001 000006a8 00000781 5c8071f0 0fff1200 00000000
> GPR16: 00000001 00000001 c02ae020 c02d0000 080103cf 00000001 000003cf c02b1be8
> GPR24: c01f2c1c c02b1c30 000000f8 c07d3510 000000f8 c0786998 c0786998 99750000
> NIP [c004be40] put_page+0x18/0x170
> LR [c017d9d8] skb_release_data+0x70/0xb4
> Call Trace:
> [c02b1ba0] [000000f8] 0xf8 (unreliable)
> [c02b1bc0] [c017d9d8] skb_release_data+0x70/0xb4
> [c02b1bd0] [c017d730] kfree_skbmem+0x18/0xdc
> [c02b1be0] [c01b0d3c] tcp_read_sock+0x188/0x1d8
> [c02b1c20] [c01f3134] xs_tcp_data_ready+0x70/0x94
> [c02b1c50] [c01b960c] tcp_rcv_established+0x4b4/0x758
> [c02b1c80] [c01c1274] tcp_v4_do_rcv+0x15c/0x44c
> [c02b1cc0] [c01c1efc] tcp_v4_rcv+0x998/0xa58
> [c02b1d10] [c01a3d48] ip_local_deliver+0x1f8/0x320
> [c02b1d40] [c01a4450] ip_rcv+0x298/0x598
> [c02b1d70] [c0185828] netif_receive_skb+0x2d0/0x334
> [c02b1da0] [c01583e4] emac_poll_rx+0x140/0x724
> [c02b1df0] [c0155c50] mal_poll+0xa8/0x26c
> [c02b1e30] [c0185a88] net_rx_action+0x88/0x15c
> [c02b1e60] [c001facc] __do_softirq+0x78/0xd4
> [c02b1e90] [c0006d50] do_softirq+0x54/0x5c
> [c02b1ea0] [c001fb9c] irq_exit+0x60/0x80
> [c02b1eb0] [c0006cac] do_IRQ+0x68/0xb8
> [c02b1ec0] [c000201c] ret_from_except+0x0/0x18
> [c02b1f80] [c0009eb4] cpu_idle+0xe8/0xf8
> [c02b1fa0] [c0205278] rest_init+0x74/0x88
> [c02b1fc0] [c02b2724] start_kernel+0x250/0x2b4
> [c02b1ff0] [c00001e8] skpinv+0x190/0x1cc
> Instruction dump:
> 80010014 38210010 7c0803a6 4e800020 8163000c 4bffffb0 7c0802a6 9421ffe0
> bfa10014 39230004 90010024 7c7f1b78 <80030000> 700a4000 4082013c 7c004828
> Kernel panic - not syncing: Aiee, killing interrupt handler!
> Rebooting in 180 seconds..
hm, it's hard to tell if this is a net problem, a driver problem or
an NFS problem or what.
^ permalink raw reply
* Re: [PATCH 07/61] bootwrapper: Set timebase_period_ns from dt_fixup_cpu_clocks.
From: Stephen Rothwell @ 2007-07-18 8:17 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070718013304.GF15238@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
On Tue, 17 Jul 2007 20:33:04 -0500 Scott Wood <scottwood@freescale.com> wrote:
>
void dt_fixup_cpu_clocks(u32 cpu, u32 tb, u32 bus)
> {
> + extern unsigned long timebase_period_ns;
Why isn't this declared in a header file somewhere?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: WDT with 82xx
From: Laurent Pinchart @ 2007-07-18 8:33 UTC (permalink / raw)
To: linuxppc-embedded, matvejchikov
In-Reply-To: <8496f91a0707160415i251aa027x6ef3899b92a5fccc@mail.gmail.com>
On Monday 16 July 2007 13:15, Matvejchikov Ilya wrote:
> Hi all!
>
> Does anybody use watchdog timer with mpc82xx?
I do.
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
From: Eugene Surovegin @ 2007-07-18 8:34 UTC (permalink / raw)
To: Andrew Morton
Cc: bart.vanassche, netdev, bugme-daemon@kernel-bugs.osdl.org,
linuxppc-embedded
In-Reply-To: <20070718005253.942f0464.akpm@linux-foundation.org>
On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote:
> On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=8778
> >
> > Summary: Ocotea board: kernel reports access of bad area during
> > boot with DEBUG_SLAB=y
Slab debugging is probably the culprit here. I had similar problem
couple of years ago, not sure something has changed since then,
haven't checked.
When slab debugging was enabled it made memory allocations non L1
cache line aligned. This is very bad for DMA on non-coherent cache
arches (PPC440 is one of those archs).
I have a hack for EMAC which tries to "workaround" this problem:
http://kernel.ebshome.net/emac_slab_debug.diff
which might help.
--
Eugene
^ permalink raw reply
* [PATCH] Add 8548CDS with Arcadia 3.0 support
From: Zang Roy-r61911 @ 2007-07-18 9:22 UTC (permalink / raw)
To: Kumar Gala, Paul Mackerras; +Cc: linuxppc-dev list
From: Roy Zang <tie-fei.zang@freescale.com>
Add 8548CDS with Arcadia 3.0 support. Arcadia 3.0 has different
pci irq routing comparing with Arcadia 3.1.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
arch/powerpc/boot/dts/mpc8548cds_legacy.dts | 327 +++++++++++++++++++++++++++
1 files changed, 327 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc8548cds_legacy.dts
diff --git a/arch/powerpc/boot/dts/mpc8548cds_legacy.dts b/arch/powerpc/boot/dts/mpc8548cds_legacy.dts
new file mode 100644
index 0000000..7d26cb2
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8548cds_legacy.dts
@@ -0,0 +1,327 @@
+/*
+ * Copyright 2007 Freescale Semiconductor Inc.
+ *
+ * Author: Roy Zang tie-fei.zang@freescale.com Jan, 2007
+ *
+ * Description:
+ * MPC8548 CDS with Arcadia 3.0 Device Tree Source
+ *
+ * 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.
+ */
+
+
+/ {
+ model = "MPC8548CDS";
+ compatible = "MPC8548CDS", "MPC85xxCDS";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8548@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <20>; // 32 bytes
+ i-cache-line-size = <20>; // 32 bytes
+ d-cache-size = <8000>; // L1, 32K
+ i-cache-size = <8000>; // L1, 32K
+ timebase-frequency = <0>; // 33 MHz, from uboot
+ bus-frequency = <0>; // 166 MHz
+ clock-frequency = <0>; // 825 MHz, from uboot
+ 32-bit;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <00000000 08000000>; // 128M at 0x0
+ };
+
+ soc8548@e0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ ranges = <0 e0000000 00100000>;
+ reg = <e0000000 00100000>; // CCSRBAR 1M
+ bus-frequency = <0>;
+
+ memory-controller@2000 {
+ compatible = "fsl,8548-memory-controller";
+ reg = <2000 1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <12 2>;
+ };
+
+ l2-cache-controller@20000 {
+ compatible = "fsl,8548-l2-cache-controller";
+ reg = <20000 1000>;
+ cache-line-size = <20>; // 32 bytes
+ cache-size = <80000>; // L2, 512K
+ interrupt-parent = <&mpic>;
+ interrupts = <10 2>;
+ };
+
+ i2c@3000 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3000 100>;
+ interrupts = <2b 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
+
+ mdio@24520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "mdio";
+ compatible = "gianfar";
+ reg = <24520 20>;
+ phy0: ethernet-phy@0 {
+ interrupt-parent = <&mpic>;
+ interrupts = <5 1>;
+ reg = <0>;
+ device_type = "ethernet-phy";
+ };
+ phy1: ethernet-phy@1 {
+ interrupt-parent = <&mpic>;
+ interrupts = <5 1>;
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+ phy2: ethernet-phy@2 {
+ interrupt-parent = <&mpic>;
+ interrupts = <5 1>;
+ reg = <2>;
+ device_type = "ethernet-phy";
+ };
+ phy3: ethernet-phy@3 {
+ interrupt-parent = <&mpic>;
+ interrupts = <5 1>;
+ reg = <3>;
+ device_type = "ethernet-phy";
+ };
+ };
+
+ ethernet@24000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <24000 1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <1d 2 1e 2 22 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy0>;
+ };
+
+ ethernet@25000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <25000 1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <23 2 24 2 28 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy1>;
+ };
+
+/* eTSEC 3/4 are currently broken
+ ethernet@26000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <26000 1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <1f 2 20 2 21 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy2>;
+ };
+
+ ethernet@27000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <27000 1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <25 2 26 2 27 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy3>;
+ };
+ */
+
+ serial@4500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4500 100>; // reg base, size
+ clock-frequency = <0>; // should we fill in in uboot?
+ interrupts = <2a 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ serial@4600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4600 100>; // reg base, size
+ clock-frequency = <0>; // should we fill in in uboot?
+ interrupts = <2a 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ global-utilities@e0000 { //global utilities reg
+ compatible = "fsl,mpc8548-guts";
+ reg = <e0000 1000>;
+ fsl,has-rstcr;
+ };
+
+ pci1: pci@8000 {
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+
+ /* IDSEL 0x2 (PCIX Tsi310 bridge) */
+ 1000 0 0 1 &mpic 0 1
+ 1000 0 0 2 &mpic 1 1
+ 1000 0 0 3 &mpic 2 1
+ 1000 0 0 4 &mpic 3 1
+
+ /* IDSEL 0x3 (PCIX Slot 2) */
+ 1800 0 0 1 &mpic 0 1
+ 1800 0 0 2 &mpic 1 1
+ 1800 0 0 3 &mpic 2 1
+ 1800 0 0 4 &mpic 3 1
+
+ /* IDSEL 0x4 (PCIX Slot 3) */
+ 2000 0 0 1 &mpic 0 1
+ 2000 0 0 2 &mpic 1 1
+ 2000 0 0 3 &mpic 2 1
+ 2000 0 0 4 &mpic 3 1
+
+ /* IDSEL 0x5 (PCIX Slot 4) */
+ 2800 0 0 1 &mpic 0 1
+ 2800 0 0 2 &mpic 1 1
+ 2800 0 0 3 &mpic 2 1
+ 2800 0 0 4 &mpic 3 1
+
+ /* IDSEL 0x6 (PCIX Slot 5) */
+ 3000 0 0 1 &mpic 0 1
+ 3000 0 0 2 &mpic 1 1
+ 3000 0 0 3 &mpic 2 1
+ 3000 0 0 4 &mpic 3 1
+
+ /* IDSEL 0x12 (Tsi310 bridge) */
+ 9000 0 0 1 &mpic 0 1
+ 9000 0 0 2 &mpic 1 1
+ 9000 0 0 3 &mpic 2 1
+ 9000 0 0 4 &mpic 3 1
+
+ /* IDSEL 0x13 (Slot 2) */
+ 9800 0 0 1 &mpic 0 1
+ 9800 0 0 2 &mpic 1 1
+ 9800 0 0 3 &mpic 2 1
+ 9800 0 0 4 &mpic 3 1
+
+ /* IDSEL 0x14 (Slot 3) */
+ a000 0 0 1 &mpic 0 1
+ a000 0 0 2 &mpic 1 1
+ a000 0 0 3 &mpic 2 1
+ a000 0 0 4 &mpic 3 1
+
+ /* IDSEL 0x15 (Slot 4) */
+ a800 0 0 1 &mpic 0 1
+ a800 0 0 2 &mpic 1 1
+ a800 0 0 3 &mpic 2 1
+ a800 0 0 4 &mpic 3 1
+
+ /* IDSEL 0x16 (Slot 5) */
+ b000 0 0 1 &mpic 0 1
+ b000 0 0 2 &mpic 1 1
+ b000 0 0 3 &mpic 2 1
+ b000 0 0 4 &mpic 3 1>
+
+ interrupt-parent = <&mpic>;
+ interrupts = <18 2>;
+ bus-range = <0 0>;
+ ranges = <02000000 0 80000000 80000000 0 10000000
+ 01000000 0 00000000 e2000000 0 00800000>;
+ clock-frequency = <3f940aa>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <8000 1000>;
+ compatible = "fsl,mpc8540-pcix", "fsl,mpc8540-pci";
+ device_type = "pci";
+ };
+
+ pci@9000 {
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+
+ /* IDSEL 0x15 */
+ a800 0 0 1 &mpic b 1
+ a800 0 0 2 &mpic b 1
+ a800 0 0 3 &mpic b 1
+ a800 0 0 4 &mpic b 1>;
+
+ interrupt-parent = <&mpic>;
+ interrupts = <19 2>;
+ bus-range = <0 0>;
+ ranges = <02000000 0 90000000 90000000 0 10000000
+ 01000000 0 00000000 e2800000 0 00800000>;
+ clock-frequency = <3f940aa>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <9000 1000>;
+ compatible = "fsl,mpc8540-pci";
+ device_type = "pci";
+ };
+
+ /* PCI Express */
+ pcie@a000 {
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+
+ /* IDSEL 0x0 (PEX) */
+ 0000 0 0 1 &mpic 0 1
+ 0000 0 0 2 &mpic 1 1
+ 0000 0 0 3 &mpic 2 1
+ 0000 0 0 4 &mpic 3 1>;
+
+ interrupt-parent = <&mpic>;
+ interrupts = <1a 2>;
+ bus-range = <0 ff>;
+ ranges = <02000000 0 a0000000 a0000000 0 20000000
+ 01000000 0 00000000 e3000000 0 08000000>;
+ clock-frequency = <1fca055>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <a000 1000>;
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ };
+
+ mpic: pic@40000 {
+ clock-frequency = <0>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <40000 40000>;
+ built-in;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+ big-endian;
+ };
+ };
+};
--
1.5.1
^ permalink raw reply related
* [PATCH 2/2] fix showing xmon help
From: Ishizaki Kou @ 2007-07-18 9:26 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In some configuration, xmon help string is larger than xmon_printf
buffer. We need not to use printf. This patch adds xmon_puts and
change to use it to show help string.
Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
---
This patch depends on [PATCH 1/2].
Index: linux-powerpc-git/arch/powerpc/xmon/nonstdio.h
===================================================================
--- linux-powerpc-git.orig/arch/powerpc/xmon/nonstdio.h
+++ linux-powerpc-git/arch/powerpc/xmon/nonstdio.h
@@ -5,6 +5,7 @@
extern int xmon_putchar(int c);
extern int xmon_getchar(void);
+extern void xmon_puts(const char *);
extern char *xmon_gets(char *, int);
extern void xmon_printf(const char *, ...);
extern void xmon_map_scc(void);
Index: linux-powerpc-git/arch/powerpc/xmon/xmon.c
===================================================================
--- linux-powerpc-git.orig/arch/powerpc/xmon/xmon.c
+++ linux-powerpc-git/arch/powerpc/xmon/xmon.c
@@ -833,7 +833,7 @@ cmds(struct pt_regs *excp)
mdelay(2000);
return cmd;
case '?':
- printf(help_string);
+ xmon_puts(help_string);
break;
case 'b':
bpt_cmds();
Index: linux-powerpc-git/arch/powerpc/xmon/nonstdio.c
===================================================================
--- linux-powerpc-git.orig/arch/powerpc/xmon/nonstdio.c
+++ linux-powerpc-git/arch/powerpc/xmon/nonstdio.c
@@ -132,3 +132,8 @@ void xmon_printf(const char *format, ...
va_end(args);
xmon_write(xmon_outbuf, n);
}
+
+void xmon_puts(const char *str)
+{
+ xmon_write(str, strlen(str));
+}
^ permalink raw reply
* [PATCH 1/2] Make xmon_write accept a const buffer
From: Ishizaki Kou @ 2007-07-18 9:30 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Because xmon_write doesn't change the buffer, we should add 'const'
qualifier to the argument which points it.
Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
---
Index: linux-powerpc-git/arch/powerpc/xmon/start.c
===================================================================
--- linux-powerpc-git.orig/arch/powerpc/xmon/start.c
+++ linux-powerpc-git/arch/powerpc/xmon/start.c
@@ -14,7 +14,7 @@ void xmon_map_scc(void)
{
}
-int xmon_write(void *ptr, int nb)
+int xmon_write(const void *ptr, int nb)
{
return udbg_write(ptr, nb);
}
Index: linux-powerpc-git/arch/powerpc/xmon/nonstdio.h
===================================================================
--- linux-powerpc-git.orig/arch/powerpc/xmon/nonstdio.h
+++ linux-powerpc-git/arch/powerpc/xmon/nonstdio.h
@@ -9,6 +9,6 @@ extern char *xmon_gets(char *, int);
extern void xmon_printf(const char *, ...);
extern void xmon_map_scc(void);
extern int xmon_expect(const char *str, unsigned long timeout);
-extern int xmon_write(void *ptr, int nb);
+extern int xmon_write(const void *ptr, int nb);
extern int xmon_readchar(void);
extern int xmon_read_poll(void);
^ permalink raw reply
* RE: Machine check exception. 2.6.20 powerpc tree.
From: Ramirez-Ortiz, Jorge @ 2007-07-18 9:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <43F1785C-E5DA-4460-A9C7-9B02431F1FE0@kernel.crashing.org>
Hi Kumar
The address we are trying to access corresponds to a mapped device in
the PCI space
Attached some additional debugging information (we have instrumented the
kernel)
Thanks
jorge
INFO [_probe]: Found Device [irq=3D58]
INFO [_open]: device opened with irq 58
INFO [_read]: waiting for interrupt
INFO [_intr]: ISR 58
PCI1: Error! ERR_DETECT=3D00000040, ATTR=3D00516001, addr=3D80020034,
data=3D00050000
machine_check_exception: task my_process, MCSR=3D0x10008, =
NIP=3D0x10153530
Machine check in user mode.
Caused by (from MCSR=3D10008): Guarded Load or Cache-Inhibited stwcx.
Bus - Read Data Bus Error
Call Trace:
[C7355EF0] [C0006E64] show_stack+0x48/0x19c (unreliable)
[C7355F20] [C000C04C] machine_check_exception+0x294/0x484
[C7355F40] [C000E48C] ret_from_mcheck_exc+0x0/0xe0
cat /proc/cpuinfo
processor : 0
cpu : e500v2
clock : 799.500000MHz
revision : 2.0 (pvr 8021 0020)
bogomips : 99.84
timebase : 49968750
platform : MPC85xx CDS
Vendor : Freescale Semiconductor
Machine : MPC85xx CDS (0xff)
PVR : 0x80210020
SVR : 0x80390220
PLL setting : 0x4
Memory : 256 MB
LAW 1 : 00000000, 20000000 -> DDR SDRAM
LAW 2 : 80000000, 10000000 -> PCI1
LAW 3 : 90000000, 10000000 -> PCI2
LAW 4 : a0000000, 10000000 -> PCI Express
LAW 5 : e1000000, 01000000 -> PCI1
LAW 6 : e2000000, 01000000 -> PCI2
LAW 7 : e3000000, 01000000 -> PCI Express
LAW 8 : f0000000, 10000000 -> Local bus
DDR 0 : 00000000, 20000000 -> 2/14/10 addr bits
PCI1 Out_1 : 80000000, 10000000 -> Mem: 80000000
PCI1 Out_2 : e1000000, 01000000 -> I/O: 00000000
PCI2 Out_1 : 90000000, 10000000 -> Mem: 90000000
PCI2 Out_2 : e2000000, 01000000 -> I/O: 00000000
PCI3 Out_1 : a0000000, 10000000 -> Mem: a0000000
PCI3 Out_2 : e3000000, 01000000 -> I/O: 00000000
PCI1 In_1 : 00000000, 20000000 (Internal,R:snoop,W:snoop) <-
00000000 PF
PCI2 In_1 : 00000000, 20000000 (Internal,R:snoop,W:snoop) <-
00000000 PF
PCI3 In_1 : 00000000, 20000000 (Internal,R:snoop,W:snoop) <-
00000000 PF
______________________________
=20
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: 17 July 2007 17:29
To: Ramirez-Ortiz, Jorge
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Machine check exception. 2.6.20 powerpc tree.=20
On Jul 17, 2007, at 9:21 AM, Ramirez-Ortiz, Jorge wrote:
> Running our multithreaded application on ppc8548 (E500 core) =20
> generates a machine check exception when trying to access some =20
> ASIC's registers mapped on the PCI space (This application maps a =20
> PCI device to access its registers)
>
>
>
> machine_check_exception: task my_process, MCSR=3D0x10008, =
NIP=3D0x10153530
>
> Machine check in user mode.
>
> Caused by (from MCSR=3D10008): Guarded Load or Cache-Inhibited stwcx.
>
> Bus - Read Data Bus Error
>
>
>
> Here is the assembly dump of the region of code containing the =20
> offending instruction in user-space, with SRR0 pointing us at =20
> 0x10153530 when the exception is raised:
>
>
>
> 0x10153528 <_ZN2vk7in_le32EPVKj+16>: lwz r0,8(r31)
>
> 0x1015352c <_ZN2vk7in_le32EPVKj+20>: lwz r9,8(r31)
>
> 0x10153530 <_ZN2vk7in_le32EPVKj+24>: lwbrx r0,0,r0
>
> 0x10153534 <_ZN2vk7in_le32EPVKj+28>: twi 0,r0,0
>
> 0x10153538 <_ZN2vk7in_le32EPVKj+32>: isync
Can you get the code to dump the value of r0. I'm wondering if =20
you're really getting a read data bus error due to the fact that r0 =20
is pointing to a PCI address that doesn't have a device that will =20
respond.
- k
^ permalink raw reply
* Re: [PATCH 52/61] cpm_uart: Issue STOP_TX command before initializing console.
From: Vitaly Bordug @ 2007-07-18 8:00 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070718013608.GX15238@ld0162-tx32.am.freescale.net>
On Tue, 17 Jul 2007 20:36:08 -0500
Scott Wood wrote:
> This prevents some bootloader/bootwrapper characters from being lost.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> drivers/serial/cpm_uart/cpm_uart_core.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
> b/drivers/serial/cpm_uart/cpm_uart_core.c index 805ca46..7772c87
> 100644 --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
> @@ -1310,6 +1310,8 @@ static int __init cpm_uart_console_setup(struct
> console *co, char *options) udbg_putc = NULL;
> #endif
>
> + cpm_line_cr_cmd(pinfo, CPM_CR_STOP_TX);
> +
I am recalling exactly the contrary patch that removes stuff to get the non-console UARTs work.
Let's better revalidate this once other pieces will be in before applying.
> if (IS_SMC(pinfo)) {
> pinfo->smcp->smc_smcm &= ~(SMCM_RX | SMCM_TX);
> pinfo->smcp->smc_smcmr &= ~(SMCMR_REN | SMCMR_TEN);
> @@ -1331,6 +1333,7 @@ static int __init cpm_uart_console_setup(struct
> console *co, char *options) cpm_uart_init_scc(pinfo);
>
> uart_set_options(port, co, baud, parity, bits, flow);
> + cpm_line_cr_cmd(pinfo, CPM_CR_RESTART_TX);
>
> return 0;
> }
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 46/61] mpc885ads: Rework initialization.
From: Vitaly Bordug @ 2007-07-18 8:44 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070718013600.GR15238@ld0162-tx32.am.freescale.net>
Overall looks good, though mentioned mutually exclusive SoC devices adding some pain
and extra code having relevant parts removed but not covered (see below).
I think it makes sense to work ontop of this code to address known quirks/issues though, hence will cover this.
yet, there are little chances to play with the 8xx inside this merge window, so I basically don't object from it being merged
as is.
On Tue, 17 Jul 2007 20:36:00 -0500
Scott Wood wrote:
> -#ifdef CONFIG_SERIAL_CPM_SMC1
> - clrbits32(bcsr_io, BCSR1_RS232EN_1);
> - clrbits32(&cp->cp_simode, 0xe0000000 >> 17); /* brg1
> */
> - tmpval8 = in_8(&(cp->cp_smc[0].smc_smcm)) | (SMCM_RX |
> SMCM_TX);
> - out_8(&(cp->cp_smc[0].smc_smcm), tmpval8);
> - clrbits16(&cp->cp_smc[0].smc_smcmr, SMCMR_REN |
> SMCMR_TEN); /* brg1 */ -#else
> - setbits32(bcsr_io,BCSR1_RS232EN_1);
> - out_be16(&cp->cp_smc[0].smc_smcmr, 0);
> - out_8(&cp->cp_smc[0].smc_smce, 0);
> -#endif
these are not just for beauty: if corresponding not-used uart regs are not cleared, second one has a
good chances to be hosed.
> -void init_scc_ioports(struct fs_platform_info *fpi)
> -{
> - int scc_no = fs_get_scc_index(fpi->fs_no);
> + /* The SCC3 enet registers overlap the SMC1 registers, so
> + * one of the two must be removed from the device tree.
> + */
Unfortunately,
this approach has very little chances to work. IIRC, SCC3 eth and SMC1 do have overlapping pins,
and just removing it from the tree is not going to save the world because now we have all-in-one early condensed
pins setup.
Also, we have to be very careful with corresponding ports shutdown: say turn off smc1 if scc3 is enabled: most prolly
it was turned on by the firmware/bootwrapper, and eth won't be alive.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 51/61] cpm_uart: Be an of_platform device when using arch/powerpc.
From: Vitaly Bordug @ 2007-07-18 8:53 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070718013606.GW15238@ld0162-tx32.am.freescale.net>
On Tue, 17 Jul 2007 20:36:06 -0500
Scott Wood wrote:
> The existing OF glue code was crufty and broken. Rather than fix it,
> it has been removed, and the serial driver now talks to the device
> tree directly.
>
> The non-CONFIG_PPC_MERGE code can do away once CPM platforms are
> dropped from arch/ppc (which will hopefully be soon).
Was is verified to boot on arch/ppc setup?
--
Sincerely, Vitaly
^ permalink raw reply
* Re: compile error if CONFIG_BLOCK not enabled related to linux/ide.h include
From: Bartlomiej Zolnierkiewicz @ 2007-07-18 10:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-kernel, linux-ide
In-Reply-To: <Pine.LNX.4.64.0707172353050.29097@blarg.am.freescale.net>
Hi,
On Wednesday 18 July 2007, Kumar Gala wrote:
> M: bzolnier@gmail.com
> L: linux-ide@vger.kernel.org
>
> We get the following compile error if CONFIG_BLOCK isn't enabled:
>
> CC arch/powerpc/kernel/setup_32.o
> In file included from arch/powerpc/kernel/setup_32.c:14:
> include/linux/ide.h:558: error: expected specifier-qualifier-list before 'request_queue_t'
> include/linux/ide.h:696: warning: 'struct request' declared inside parameter list
> include/linux/ide.h:696: warning: its scope is only this definition or declaration, which is probably not what you want
> include/linux/ide.h:820: warning: 'struct request' declared inside parameter list
> include/linux/ide.h:853: error: field 'wrq' has incomplete type
> include/linux/ide.h:1205: error: expected ')' before '*' token
> make[1]: *** [arch/powerpc/kernel/setup_32.o] Error 1
> make: *** [arch/powerpc/kernel] Error 2
include/linux/ide.h is exclusively for IDE subsystem
> What I'm trying to figure out is if include/linux/ide.h should be wrapped
> in a #if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE) or if there is
> some other desired way to handle this.
Plese remove <linux/ide.h> include, there doesn't seem to be any piece of
code in arch/powerpc/kernel/setup_32.c which needs it anyway.
Thanks,
Bart
^ permalink raw reply
* RE: OF devices and non OF devices
From: Kári Davíðsson @ 2007-07-18 11:13 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-embedded
In-Reply-To: <4b73d43f0707051020o67e671dft1d3b3816776d8eb7@mail.gmail.com>
Yes there was indeed.
Combination of my misunderstanding, device trees and board specific =
initialization.
Things are working now.
Thanks,
kd
________________________________
From: John Rigby [mailto:jcrigby@gmail.com]=20
Sent: 5. j=FAl=ED 2007 17:21
To: K=E1ri Dav=ED=F0sson
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: OF devices and non OF devices
There must be something else wrong with your configuration.
On my Lite5200B fsl_i2c_probe gets called with no changes to the driver.
The kernel version is 2.6.22-rc7
The relevant part of my device tree is:=20
i2c@3d00 {
device_type =3D "i2c";
compatible =3D "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
cell-index =3D <0>;
reg =3D <3d00 40>;=20
interrupts =3D <2 f 0>;
interrupt-parent =3D <&mpc5200_pic>;
fsl5200-clocking;
};
i2c@3d40 {
device_type =3D "i2c";=20
compatible =3D "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
cell-index =3D <1>;
reg =3D <3d40 40>;
interrupts =3D <2 10 0>;
interrupt-parent =3D <&mpc5200_pic>;=20
fsl5200-clocking;
};
I turned on DEBUG in drivers/base/dd.c and a call to pr_debug in the =
probe routine
and here are the relevant log messages:
[ 27.258245] platform: Matched Device fsl-i2c.0 with Driver fsl-i2c
[ 27.258269] platform: Probing driver fsl-i2c with device fsl-i2c.0
[ 27.258299] I2C: here in fsl_i2c_probe
[ 27.258732] bound device 'fsl-i2c.0' to driver 'fsl-i2c'=20
[ 27.258756] platform: Bound Device fsl-i2c.0 to Driver fsl-i2c
[ 27.258776] platform: Matched Device fsl-i2c.1 with Driver fsl-i2c
[ 27.258789] platform: Probing driver fsl-i2c with device fsl-i2c.1
[ 27.258821] I2C: here in fsl_i2c_probe
[ 27.259269] bound device 'fsl-i2c.1' to driver 'fsl-i2c'
[ 27.259293] platform: Bound Device fsl-i2c.1 to Driver fsl-i2c
John
On 7/5/07, John Rigby <jcrigby@gmail.com> wrote:=20
kd,
=09
Ok, obviously It doesn't work the way I thought. Hopefully someone who =
does
understand this will comment.
=09
John=20
=09
=09
=09
On 7/4/07, K=E1ri Dav=ED=F0sson <kari.davidsson@marel.is> wrote:=20
John, thank you for your answare.
=09
Enabling CONFIG_FSL_SOC only enabled the execution of the init =
function (fsl_i2c_init())
of the fsl-i2c driver (i2c-mpc.c). The .probe function of the driver =
was never called
until I converted the driver to the OF model and added the =
.match_table to the driver structure.
=09
Then I get the .probe function (fsl_i2c_probe()) called and the i2c =
bus set up.
=09
Similar thing happens for the i2c device PCF8563 i.e., the init =
functin of the driver (pcf8563_init())
is called the driver is registered with the kernel, but the .probe =
(pcf8563_probe()) is never called.
=09
The driver pcf8563 has _NO_ exported structures or functions so I =
basically have no handle on it=20
that I can utilize in board specific setup.
=09
The way I suspect this is supposed to work is that from the board =
settup files I would do
rtc_dev =3D platform_device_register_simple("pcf8563", -1, NULL, 0);=20
which should later trigger the calling of the pcf8563_probe() =
function.
=09
This is doing things in the same way as the fsl i2c code, i.e.
i2c_dev =3D platform_device_register_simple("i2c", i, r, 2);
which by the way does not work untill I have converted the fsl_i2c =
(i2c-mpc.c) driver to the OF structure.
=09
So still the method of gluing together the OF drivers and non OF =
drivers eludes me.
=09
rg
kd
=09
P.S. I did check the 2.6.21-RC7-git3 and found that the i2c-mpc.c and =
the rtc-pcf85763.c are basically the same
as what I am working with in 2.6.20+
________________________________
=09
From: John Rigby [mailto: jcrigby@gmail.com]
Sent: 3. j=FAl=ED 2007 16:31
To: K=E1ri Dav=ED=F0sson
Cc: linuxppc-embedded@ozlabs.org=20
Subject: Re: OF devices and non OF devices
=09
=09
One place to find binding between OF devices and non OF devices is in =
arch/powerpc/sysdev/fsl_soc.c=20
The typical pattern is:
if of_find_compatible_node "of-device-name"
platform_device_register_simple ""platform-device-name"
platform_device_add_data ...
=09
=09
=09
On 7/3/07, K=E1ri Dav=ED=F0sson <kari.davidsson@marel.is> wrote:
=09
Hi,
=09
I am attempting to get some non OF devices working for an mpc =
5200 board, in particular=20
PCF8563 RTC.
=09
This device has an non OF device interface which I believe is =
correct. After all it should work
on non OF platforms.
=09
I have managed to get the board to run the i2c initialization =
(and probe) for the fsl-mpc i2c driver by=20
converting the fsl-mpc i2c driver to OF driver (I found some =
patch here that I based this work on).
=09
=09
fsl-i2c is one of the devices handled by fsl_soc.c so you shouldn't =
need to change anything to=20
make it work in the latest kernel. CONFIG_FSL_SOC was only added to =
lite5200_defconfig recently so
that may explain why it's not on in your kernel.
=09
=09
=09
Since the PCF8563 driver is not OF driver only its =
initaliziation code is run but the .probe function=20
of the driver is never run. Basically (as far as I can =
understand) the .probe is never run because the
driver is not an OF driver.
=09
I could convert the PCF8563 driver to OF driver and make it =
work for our puposes but I feel this is=20
1) Wrong
2) therefore wasted work.
=09
=09
Since the driver must run on non OF platforms then it should not be =
converted. You just need to add a platform_device_register somewhere.
I don't think fsl_soc.c is the right place since it is not part of an =
freescale SOC.=20
You could probably put it in a board specific startup routine.
=09
=09
=09
What seems to elude me is some glue that glues together the OF =
part of the driver space to the non OF part
of the driver space.=20
=09
Any hints or pointers on where to find this glue?
=09
Regards,
kd
=09
P.S. Kernel is post 2.6.20.
=09
--
K=E1ri Dav=ED=F0sson | =
kari.davidsson@marel.is
Hugb=FAna=F0arger=F0 | www.marel.com
Tel: 563-8156 Fax: +354 563 8001=20
Iceland
_______________________________________________=20
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded =
<https://ozlabs.org/mailman/listinfo/linuxppc-embedded>=20
=09
=09
=09
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
=09
=09
^ permalink raw reply
* Re: mpc52xx: Correct calculation of FEC RX errors???
From: Sylvain Munaut @ 2007-07-18 11:45 UTC (permalink / raw)
To: Miguel Angel Alvarez; +Cc: linuxppc-embedded
In-Reply-To: <469DFC03.9080201@ziv.es>
> Hi
>
> We are showing figures of more than 4 billion error frames in our
> ethernet interfaces. We have tested that the problem is in a
> substraction (the number of errors decrements with the number of frames).
>
> So... looking in the fec driver (fec.c) for the calculations we have
> seen that the number of multicast packets is added to the number of
> correct frames in order to get the frame errors...
>
> But the interesting thing is that we have checked that this
> calculation is something that we have added with a patch by Grzegorz
> Bernacki in this list.
>
> So... The funny thing is... Why a patch that solves the problem for
> Grzegorz produces "the same problem" for us?
>
> And... by the way... I have seen IEEE802.3, and when they talk about
> aFramesReceivedOK (which I suppose is the ieee_r_frame_ok in the
> driver), and they do not say a word about not including multicast
> packets in it...
>
> Any comment will be appreciate.
The only comment I have, is that yes, the computation are flawed.
And that's not very high in my priority list.
I don't think the path posted on the list fully fix the issue but I
really don't want to spend hours trying to figure out exactly what
values are reported in all those counters. You're welcome to do so if
you have some free time ...
There are other stuff wrong in this driver (try ifconfig eth0 down, then
send some broad cast traffic on the network .... you'll see some fifo
error popping up ) ...
Sylvain
^ permalink raw reply
* mpc52xx: Correct calculation of FEC RX errors???
From: Miguel Angel Alvarez @ 2007-07-18 11:39 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: tnt
Hi
We are showing figures of more than 4 billion error frames in our=20
ethernet interfaces. We have tested that the problem is in a=20
substraction (the number of errors decrements with the number of =
frames).
So... looking in the fec driver (fec.c) for the calculations we have=20
seen that the number of multicast packets is added to the number of=20
correct frames in order to get the frame errors...
But the interesting thing is that we have checked that this calculation=20
is something that we have added with a patch by Grzegorz Bernacki in=20
this list.
So... The funny thing is... Why a patch that solves the problem for=20
Grzegorz produces "the same problem" for us?
And... by the way... I have seen IEEE802.3, and when they talk about=20
aFramesReceivedOK (which I suppose is the ieee_r_frame_ok in the=20
driver), and they do not say a word about not including multicast=20
packets in it...
Any comment will be appreciate.
Miguel =C1ngel =C1lvarez
**=20
=20
----------------------------------------- PLEASE NOTE =
-------------------------------------------
This message, along with any attachments, may be confidential or legally =
privileged.=20
It is intended only for the named person(s), who is/are the only =
authorized recipients.
If this message has reached you in error, kindly destroy it without =
review and notify the sender immediately.
Thank you for your help.
ZIV uses virus scanning software but excludes any liability for viruses =
contained in any attachment.
=20
------------------------------------ ROGAMOS LEA ESTE TEXTO =
-------------------------------
Este mensaje y sus anexos pueden contener informaci=F3n confidencial y/o =
con derecho legal.=20
Est=E1 dirigido =FAnicamente a la/s persona/s o entidad/es rese=F1adas =
como =FAnico destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elim=EDnelo sin =
revisarlo ni reenviarlo y notif=EDquelo inmediatamente al remitente. =
Gracias por su colaboraci=F3n. =20
ZIV utiliza software antivirus, pero no se hace responsable de los virus =
contenidos en los ficheros anexos.
^ permalink raw reply
* Re: [PATCH v2] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Segher Boessenkool @ 2007-07-18 12:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org, Jon Loeliger, Paul Mackerras
In-Reply-To: <3198C3F2-91CE-4AF6-822B-5BA2820458C7@kernel.crashing.org>
>>>> A: They haven't been posted yet.
>>>>
>>>> Q: How do we know Segher has new patches?
>>>
>>> He sent it to me to test, and I told him it worked...
>>
>> And I sent it to the list hours later, over a week ago.
>
> Can someone send a ozlabs linuxppc list link or patchworks to the
> "new" patch.
<http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039076.html>
is Johannes' ack.
It seems ozlabs ate the original, will resend.
Segher
^ permalink raw reply
* Re: [PATCH 38/61] cpm2: Update device trees.
From: Vitaly Bordug @ 2007-07-18 12:22 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070718013549.GJ15238@ld0162-tx32.am.freescale.net>
On Tue, 17 Jul 2007 20:35:50 -0500
Scott Wood wrote:
> + "fsl,cpm-uart";
> reg = <11a00 20 8000 100>;
> - current-speed = <1c200>;
Hmm, how is it supposed to work without speed? I was testing my u-boot OF bindings for 82xx and spotted into it.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [RFC 0/3] lro: Generic Large Receive Offload for TCP traffic (IPv6)
From: Jan-Bernd Themann @ 2007-07-18 13:00 UTC (permalink / raw)
To: David Miller
Cc: tklein, themann, netdev, linux-kernel, hch, linuxppc-dev, raisch,
meder, stefan.roscher
In-Reply-To: <20070715.024015.126137834.davem@davemloft.net>
Hi,
I suggest we keep the interface open for IPv6 support by adding
an additional parameter but first just get IPv4 support only
into the kernel. IPv6 support can then incrementially be added.
Would that be ok?
On Sunday 15 July 2007 11:40, David Miller wrote:
> From: Christoph Hellwig <hch@infradead.org>
> Date: Sun, 15 Jul 2007 10:12:53 +0100
>
> > I'm not sure that's a good idea. If current chips can't handle ipv6
> > lro there is no way to actually test it and the code will surely bitrot.
>
> Christoph, you can do LRO pretty much completely in software.
>
>
^ permalink raw reply
* [PATCH] PPC: Prevent direct inclusion of <asm/rwsem.h>.
From: Robert P. J. Day @ 2007-07-18 13:36 UTC (permalink / raw)
To: Linux PPC Mailing List; +Cc: Paul Mackerras
Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>
---
not compile-tested, so if there's a flaw here somewhere, feel free
to tweak it.
arch/ppc/syslib/ocp.c | 2 +-
include/asm-powerpc/rwsem.h | 4 ++++
include/asm-ppc/ocp.h | 2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/ppc/syslib/ocp.c b/arch/ppc/syslib/ocp.c
index 491fe9a..3f5be2c 100644
--- a/arch/ppc/syslib/ocp.c
+++ b/arch/ppc/syslib/ocp.c
@@ -44,11 +44,11 @@
#include <linux/pm.h>
#include <linux/bootmem.h>
#include <linux/device.h>
+#include <linux/rwsem.h>
#include <asm/io.h>
#include <asm/ocp.h>
#include <asm/errno.h>
-#include <asm/rwsem.h>
#include <asm/semaphore.h>
//#define DBG(x) printk x
diff --git a/include/asm-powerpc/rwsem.h b/include/asm-powerpc/rwsem.h
index e929145..cefc147 100644
--- a/include/asm-powerpc/rwsem.h
+++ b/include/asm-powerpc/rwsem.h
@@ -1,6 +1,10 @@
#ifndef _ASM_POWERPC_RWSEM_H
#define _ASM_POWERPC_RWSEM_H
+#ifndef _LINUX_RWSEM_H
+#error "Please don't include <asm/rwsem.h> directly, use <linux/rwsem.h> instead."
+#endif
+
#ifdef __KERNEL__
/*
diff --git a/include/asm-ppc/ocp.h b/include/asm-ppc/ocp.h
index 16dbc7d..1379a4f 100644
--- a/include/asm-ppc/ocp.h
+++ b/include/asm-ppc/ocp.h
@@ -27,10 +27,10 @@
#include <linux/init.h>
#include <linux/list.h>
#include <linux/device.h>
+#include <linux/rwsem.h>
#include <asm/mmu.h>
#include <asm/ocp_ids.h>
-#include <asm/rwsem.h>
#include <asm/semaphore.h>
#ifdef CONFIG_PPC_OCP
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply related
* Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
From: Josh Boyer @ 2007-07-18 13:41 UTC (permalink / raw)
To: Eugene Surovegin
Cc: bart.vanassche, netdev, Andrew Morton,
bugme-daemon@kernel-bugs.osdl.org, linuxppc-embedded
In-Reply-To: <20070718083425.GA29722@gate.ebshome.net>
On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote:
> On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote:
> > On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:
> >
> > > http://bugzilla.kernel.org/show_bug.cgi?id=8778
> > >
> > > Summary: Ocotea board: kernel reports access of bad area during
> > > boot with DEBUG_SLAB=y
>
> Slab debugging is probably the culprit here. I had similar problem
> couple of years ago, not sure something has changed since then,
> haven't checked.
>
> When slab debugging was enabled it made memory allocations non L1
> cache line aligned. This is very bad for DMA on non-coherent cache
> arches (PPC440 is one of those archs).
>
> I have a hack for EMAC which tries to "workaround" this problem:
> http://kernel.ebshome.net/emac_slab_debug.diff
> which might help.
Would you be opposed to including that patch in mainline? I'd like to
have the bug reporter try it and then get it in if it fixes the issue.
josh
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Segher Boessenkool @ 2007-07-18 13:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <1184707558.25235.159.camel@localhost.localdomain>
>> Yes, I shouldn't say "defaulted" -- a unit interrupt specifier
>> simply has no unit address part, in an interrupt domain that
>> doesn't correspond to a "normal" bus. But saying it like this
>> is a little bit inexact, and it uses more words.
>>
>>> which is why I tend to prefer having it
>>> explicitely in the interrupt controller node :-)
>>
>> Which is simply incorrect.
>
> It's absolutely not.
Of course it is. #address-cells is a property for
bus nodes, you don't go around putting it in unrelated
places, just like you don't put "slot-names" properties
where it has no business.
Oh, wait, you're going to say that is a stupid comparison.
Yeah it is, "slot-names" would be way more harmless, #a is
such a fundamental low-level building block of the OF device
tree that the imap people didn't dare change it semantics
(or, were simply smart enough to not try).
> Please, stop that moronic pin-head behaviour and
> find me a single case where that would actually be a problem of any =20=
> sort
> or form.
You want all DTS authors to put properties where they do
not belong, confusing them even further about what all this
stuff is. You want to make this a "requirement", although
it of course won't help anything anywhere, since *even you
_do_ have to follow the rules*, because the Linux code has
to support proper standards-compliant OF device trees, too.
>> You mean, the magic default values you used for #address-cells
>> and #size-cells? That was simply a bug, someone forgot to read
>> the documentation...
>
> No, defaults are crap, period. This is a general thing.
I'm sorry if you feel that way, but there simply is no
way you can do anything about it; defaults exist, you
have to support them.
> Besides, the
> spec itself has issues about the default values (remember those blurbs
> about PCI and ISA supposedly having different defaults ?)
I remember those very very vaguely. The conclusion was that
people have trouble understanding what they read, if I
remember it right.
Anyway, quit saying vague things about supposed bugs in the
OF documents without pointing them out; it is less than
helpful.
> In any way,
> defaults are a bad idea and I'm happy to say don't use them.
Sure, feel free to recommend people to explicitly write out
default values. Nothing wrong there, it's just one particular
coding style.
As I've explained enough times though, the issue at hand isn't
about writing out a default value though; you want to require
(not recommend) a completely bogus property where it doesn't
belong. And none of the code will benefit, either. I don't
see the point.
>> For this? No way:
>>
>> [=46rom the base spec]:
>>
>> =93#address-cells=94 S
>> Standard property name to define the package=92s address format.
>> prop-encoded-array: Integer, encoded with encode-int.
>>
>> This property applies to packages that define a physical
>> address space, i.e., those packages with =93decode-unit=94
>> methods. The property value specifies the number of cells
>> that are used to encode a physical address within that
>> address space. The value of this property affects the other
>> functions, commands, and methods that deal with physical
>> addresses. In a package with a =93decode-unit=94 method, a =
missing
>> =93#address-cells=94 property signifies that the number of
>> address cells is two.
>
> And you omit the various bus bindings that have come up with different
> defaults...
a) Do you expect me to quote every OF document in every post?
That would easily exceed the message limits on this list,
sorry.
b) There are no such bindings. Stop confusing people. There
might be a bug in one such binding or so, but that would be
just that, a bug; or maybe it uses confusing language; or
maybe some people just don't know how to read [that would
include me, I'm not trying to escalate this, ahem, polite
conversation]. In any case, please point out the exact
spot where you say this happens.
>> See? The flat device tree unfortunately has no decode-unit, but
>> it is still pretty clear which nodes "define a physical address
>> space" and which do not.
>>
>> There is nothing badly defined here.
>
> See above. Besides, as I said, default values are crap.
Hey, maybe if you repeat it often enough, I might start to
believe it. Not that that will help your point, since it
is absolutely irrelevant.
> And no, it's not
> obvious which nodes define a physical address space or not, at =20
> least not
> for a generic parser.
"Everything which can have kids with an @ in your DTB full
name thingie". That includes everything with a #address-cells.
> Defaults are a bad idea, just get it
I'm getting tired of repeating myself, I hope you do, too.
> and move on and stop arguing just for the sake of arguing.
Would you please stop using that childish argument when
you've run out of real ones?
> Pointing out the letter
> of the spec is not a constructive attitude here.
Not just the letter, also the spirit, and the history.
And of course it _is_ constructive; you want to make a
useless, non-compatible change, are we peasants allowed
to quote the law that even you the mighty king must follow?
It's the only weapon we have you know. Oh, if you discount
the pitchforks ;-)
>> Nothing in the "interrupt mapping" spec redefines #address-cells
>> (OF isn't all that stupid you know); it simply says that a /unit
>> interrupt specifier/ has no /unit address/ part if there is no
>> #address-cells. The algorithm in paragraph 7 makes it super
>> clear how exactly this should work.
>
> No, the algorithm provided isn't clear and is buggy.
Yes it is clear. No it isn't buggy (it _does_ state right
before the algo that some details are left out, maybe that
hurt you?)
> I have implemented it so I know what I'm talking about.
Me too.
> The fact that basically you end up
> with "different" defaults for what is essentially the value
> #address-cells depending on whether you are walking the device-tree =20=
> for
> address resolution or for interrupt resolution is stupid.
Until you realise #address-cells is missing in those two
cases for completely different reasons. In the first case,
#address-cells is missing for historic reasons; there didn't
use to be a #address-cells, everyone implicitly assumed it
was 2, it wasn't a default as such. After #a was introduced,
not specifying it if it was 2 had to be allowed, for compatibility
reasons. To this day, people routinely write trees with implicit
#address-cells =3D <2>, simply since they find it handy [<-- this
is the only thing you can fight with that "defaults are bad"
argument, btw, and you won't get far; most people feel passionately
about their own coding style].
In the interrupt "tree" case though, #address-cells is missing
in certain nodes ***because it simply doesn't belong there!***
The imap spec doesn't put any new rules on #address-cells [how
could it, without risking serious damage], it simply specifies
how to deal with the existing bus tree structure. And not every
node in the interrupt graph is a bus node, so it says how to
form a unit interrupt specifier when there is no #address-cells:
you simply leave out the unit part. Wow. Now that was hard.
And there is no "default" (in your sense) in sight.
> Thus, the
> solution is simple: don't do defaults. Explicit values are good.
Except where the decisive thing is whether there _is_ a value
at all.
>>> and the spec contains gray areas
>>> and contradictions as to what the default values should be in some
>>> circumstances.
>>
>> In some areas, perhaps. And it would be nice to bring those
>> areas to the attention of the working group, instead of just
>> to complain.
>
> The working group is dead
"It's just resting".
> and some of the ex members of it expressed
> their lack of interest in pursuing these matters.
Some, yes. Even if the WG wouldn't help, there are some other
forums where you can discuss OF bugs; if all else fails, you
could try this mailing list even.
Point remains: it is a terribly bad argument to say "defaults
are bad, ooh I'm creating a rumour there are some vague defaults
in the OF standard right here, without pointing out anything,
ever".
[Here you cut out the part of our little chat where you
suggest the interrupt mapping spec should have said that
if there is no #address-cells in a node, just put something
there]
>> If it would, the interrupt mapping spec would have had to say
>> how the semantics of #address-cells were changed (and they
>> weren't, and they shouldn't, and this is such a laughable idea
>> I wonder why anyone would suggest it did).
>
> That's bullshit. The semantics are exactly the same. You obviously
> decided to be immune to any kind of common sense today.
Huh? Let me write more abstractly what I said:
"If you change A, A gets changed".
Hard to argue with that I would think, but hey.
>> What the interrupt mapping spec defines is how to _use_ the
>> value of #address-cells, and how to interpret its absence;
>> what should be put in #address-cells for separate nodes is
>> defined elsewhere (namely, in the base spec, and in relevant
>> device bindings).
>
> There is no such crackpot interpretation.
Well please read it again, if that's what you think. Obviously
you didn't understand it on the first try. This is really basic
stuff; it's how standards work.
> A unit interrupt specifier
> contains ... an address. An address format/size is defined by a
> #address-cells.
No. A unit address format is defined by its device binding.
Luckily, for (PCI) interrupt mapping, nothing more than the
unit address _size_ is needed since the imap spec doesn't
concern itself with the semantics of the unit addresses in
question; it just needs some way to get unique identifiers.
> Period. That's not an "interpretation", that's the
> basic, primary semantic of #address-cells.
Pretty much, yes...
> The fact that the absence of
> #address-cells will give a different "default" for the address size
> depending on "how" you walk the tree is just a plain wrong bad idea.
...so I don't see how you made _this_ mental jump.
There _is_ no default, there is just a different way to
form unit interrupt specifiers for nodes with or without
#address-cells. They are treated differently, because
they _are_ different. Yes you can try to shoehorn them
into one mould by pretending #address-cells exists and
has the value 0; this might be okay for an interrupt tree
walker implementation [or it might not -- the writers of
the example algorithm that you so despise probably had
a reason for writing it out all three times, even though
they aren't all that careful in other places], maybe it
isn't too confusing there, but it certainly is if you put
it in a device tree.
> I
> see no reason why it would be or cause or be in any way shape or form
> wrong or against the "spirit" of the spec (if not the letter) to
> explicitely specify in the case of leaf interrupt controllers, that
> their #address-cells is 0 and be done with it.
Maybe you don't see it. But the specs make abundantly
clear that _not_ putting an #address-cells here is perfectly
fine, which I thought would have prevented this particular
flame war from happening at all. Oh well.
Segher
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Segher Boessenkool @ 2007-07-18 13:53 UTC (permalink / raw)
To: Scott Wood; +Cc: Yoder Stuart-B08248, linuxppc-dev
In-Reply-To: <20070717222507.GA4682@ld0162-tx32.am.freescale.net>
>> See above. Besides, as I said, default values are crap. And no,
>> it's not
>> obvious which nodes define a physical address space or not, at
>> least not
>> for a generic parser.
>
> The obvious way (which indeed isn't what the suggested algorithm
> does --
> but the suggested algorithm doesn't do anything sensible) is that
> if you
> got to the node via an interrupt-parent or interrupt-map, it
> doesn't use
> #address-cells, and if you got to it by going to the regular device
> tree
> parent, it does.
>
> Pretty much any time you use the unit address in a context other
> than the
> bus parent, things cease making sense.
Yes indeed. The problem with your suggested "obvious way"
is that you wouldn't get a unit address included if your
interrupt-map points (for some entry) at your device tree
parent, either. Not all that hypothetical.
Segher
^ permalink raw reply
* Re: compile error if CONFIG_BLOCK not enabled related to linux/ide.h include
From: Kumar Gala @ 2007-07-18 14:12 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linuxppc-dev, linux-kernel, linux-ide
In-Reply-To: <200707181247.26262.bzolnier@gmail.com>
On Jul 18, 2007, at 5:47 AM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday 18 July 2007, Kumar Gala wrote:
>> M: bzolnier@gmail.com
>> L: linux-ide@vger.kernel.org
>>
>> We get the following compile error if CONFIG_BLOCK isn't enabled:
>>
>> CC arch/powerpc/kernel/setup_32.o
>> In file included from arch/powerpc/kernel/setup_32.c:14:
>> include/linux/ide.h:558: error: expected specifier-qualifier-list
>> before 'request_queue_t'
>> include/linux/ide.h:696: warning: 'struct request' declared inside
>> parameter list
>> include/linux/ide.h:696: warning: its scope is only this
>> definition or declaration, which is probably not what you want
>> include/linux/ide.h:820: warning: 'struct request' declared inside
>> parameter list
>> include/linux/ide.h:853: error: field 'wrq' has incomplete type
>> include/linux/ide.h:1205: error: expected ')' before '*' token
>> make[1]: *** [arch/powerpc/kernel/setup_32.o] Error 1
>> make: *** [arch/powerpc/kernel] Error 2
>
> include/linux/ide.h is exclusively for IDE subsystem
>
>> What I'm trying to figure out is if include/linux/ide.h should be
>> wrapped
>> in a #if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE) or if
>> there is
>> some other desired way to handle this.
>
> Plese remove <linux/ide.h> include, there doesn't seem to be any
> piece of
> code in arch/powerpc/kernel/setup_32.c which needs it anyway.
Its needed for:
struct ide_machdep_calls ppc_ide_md;
which gets defined in asm/ide.h which needs linux/ide.h for the defn
of ide_init_hwif.
- k
^ 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