* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Benjamin Herrenschmidt @ 2008-03-03 21:41 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080303212622.GB20382@netgate.macqel>
> Thanks
>
> The following seems important also :
>
> /*
> interrupts = <18 2>;
> */
> /* interrupts number are coded in hexa ! */
> interrupts = <12 2 19 2 1a 2 1b 2 35 2 36 2 37 2>;
>
> I have replaced the interrupts spec in comments by the longer interrupts spec
> below, and it seems to have some positive effect, but I do not know
> precisely what I have described there.
>
> I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are the
> interrupts numbers that I had in the ARCH=ppc version. I added 18 because
> of the error message, but it did not help.
Where is this ? (What node ?) The above looks like the interrupt spec
for a single device with 7 interrupts, is that what you are trying to
do ?
If not, then it's incorrect, you have to figure the interrupt-map out
(it's really not -that- hard).
Ben.
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Scott Wood @ 2008-03-03 21:55 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080303212622.GB20382@netgate.macqel>
Philippe De Muyter wrote:
> The following seems important also :
>
> /*
> interrupts = <18 2>;
> */
> /* interrupts number are coded in hexa ! */
> interrupts = <12 2 19 2 1a 2 1b 2 35 2 36 2 37 2>;
>
> I have replaced the interrupts spec in comments by the longer interrupts spec
> below,
Why?
> and it seems to have some positive effect,
What kind of positive effect? I'd think the extra interrupts would just
be ignored. The interrupts property for the PCI node itself is
generally for error reporting.
> I know that 25, 26, 27, 53, 54 and 55 decimal i(hence 19, 1a etc...) are the
> interrupts numbers that I had in the ARCH=ppc version. I added 18 because
> of the error message, but it did not help.
What ARCH=ppc version? There are no device trees for non-OF boards in
arch/ppc.
-Scott
^ permalink raw reply
* Re: I2S driver
From: Wolfgang Denk @ 2008-03-03 22:06 UTC (permalink / raw)
To: Pedro Luis D. L.; +Cc: linuxppc-embedded
In-Reply-To: <BLU106-W22AC7D9FCF4035AF6AB5E6CA170@phx.gbl>
In message <BLU106-W22AC7D9FCF4035AF6AB5E6CA170@phx.gbl> you wrote:
>
> depends on which kernel version are you using. You can find some working code in DENX repository:
> http://source.denx.net/cgi-bin/gitweb.cgi
Ah, you should use the official server instead:
http://www.denx.de/cgi-bin/gitweb.cgi
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
\|/ ____ \|/ \|/ ____ \|/
@~/ ,. \~@ @~/ ,. \~@
/_( \__/ )_\ /_( \__/ )_\
\__U_/ \__U_/
^ permalink raw reply
* locking problem in sata_sil24?
From: Rune Torgersen @ 2008-03-03 22:10 UTC (permalink / raw)
To: linuxppc-dev, linux-ide
Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel, but
kept gettign a BUG() (kernel BUG at kernel/rtmutex.c:692).
While tryiong to figure out what it was, I saw some mention of trying
LOCKDEP to see what is going on, so I patched my -rt1 kernel with some
lockdep patches from BenH.
Now I get an "inconsistent locking state", but I need help in trying to
fiure out what I should look for.
kernel is fo an Freescale 8280 and the locking seems to occur in the
driver for a Silicon Image SII3124 SATA disk driver
Linux version 2.6.24-rt1 (runet@runet) (gcc version 4.1.2) #12 PREEMPT
RT Mon Mar 3 15:47:03 CST 2008
Trying to allocate DevcomPtr
DevcomHugeMemPtr =3D c1800000
Zone PFN ranges:
DMA 0 -> 196608
Normal 196608 -> 196608
HighMem 196608 -> 262144
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 262144
Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
Built 1 zonelists in Zone order, mobility grouping on. Total pages:
260096
Kernel command line: root=3D/dev/sda3 rw console=3DttyCPM0,115200
WARNING: experimental RCU implementation.
PID hash table entries: 4096 (order: 12, 16384 bytes)
clocksource: timebase mult[a0c0437] shift[22] registered
console [ttyCPM0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 30
... MAX_LOCKDEP_KEYS: 2048
... CLASSHASH_SIZE: 1024
... MAX_LOCKDEP_ENTRIES: 16384
... MAX_LOCKDEP_CHAINS: 32768
... CHAINHASH_SIZE: 16384
memory used by lock dependency info: 1568 kB
per task-struct memory footprint: 1200 bytes
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1007824k/1048576k available (3240k kernel code, 302324k
reserved, 176k data, 2803k bss, 128k init)
Mount-cache hash table entries: 512
net_namespace: 88 bytes
NET: Registered protocol family 16
PCI: Probing PCI hardware
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 32768 (order: 9, 2228224 bytes)
TCP: Hash tables configured (established 131072 bind 32768)
TCP reno registered
krcupreemptd setsched 0
prio =3D 98
highmem bounce pool size: 64 pages
JFFS2 version 2.2. (NAND) .. 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
ttyCPM0 at MMIO 0xf1050a80 (irq =3D 16) is a CPM UART
Fixed MDIO Bus: probed
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
eth0: fs_enet: 00:30:d7:00:14:52
eth1: fs_enet: 00:30:d7:00:14:53
eth2: fs_enet: 00:30:d7:00:00:01
Driver 'sd' needs updating - please use bus_type methods
scsi0 : sata_sil24
scsi1 : sata_sil24
scsi2 : sata_sil24
scsi3 : sata_sil24
ata1: SATA max UDMA/100 host m128@0x90000000 port 0x90008000 irq 17
ata2: SATA max UDMA/100 host m128@0x90000000 port 0x9000a000 irq 17
ata3: SATA max UDMA/100 host m128@0x90000000 port 0x9000c000 irq 17
ata4: SATA max UDMA/100 host m128@0x90000000 port 0x9000e000 irq 17
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
stopped custom tracer.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
[ INFO: inconsistent lock state ]
[ 2.6.24-rt1 #12
---------------------------------
inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(&host->lock){+-..}, at: [<c01c8e14>] sil24_interrupt+0x68/0x53c
{hardirq-on-W} state was registered at:
[<c0047724>] __lock_acquire+0x494/0xc04
[<c0047ee8>] lock_acquire+0x54/0x78
[<c025c8f0>] rt_spin_lock+0x34/0x54
[<c01b45ac>] ata_dev_init+0x38/0x88
[<c01b467c>] ata_link_init+0x80/0xa4
[<c01b4840>] ata_port_alloc+0x1a0/0x1bc
[<c01b48f4>] ata_host_alloc+0x98/0xf8
[<c01b4974>] ata_host_alloc_pinfo+0x20/0x104
[<c01c83b4>] sil24_init_one+0x128/0x390
[<c01802f0>] pci_device_probe+0x70/0xa8
[<c0197d10>] driver_probe_device+0x104/0x1ac
[<c0197e0c>] __driver_attach+0x54/0x8c
[<c0197030>] bus_for_each_dev+0x58/0xa0
[<c0197adc>] driver_attach+0x2c/0x44
[<c0197778>] bus_add_driver+0xb4/0x1b8
[<c01980b8>] driver_register+0x7c/0x114
[<c01803bc>] __pci_register_driver+0x60/0x78
[<c031e620>] sil24_init+0x2c/0x44
[<c030a2c8>] kernel_init+0xdc/0x334
[<c0010408>] kernel_thread+0x44/0x60
irq event stamp: 16174
hardirqs last enabled at (16173): [<c0046d18>]
trace_hardirqs_on+0x1c/0x34
hardirqs last disabled at (16174): [<c0045554>]
trace_hardirqs_off+0x1c/0x34
softirqs last enabled at (0): [<00000000>] 0x0
softirqs last disabled at (0): [<00000000>] 0x0
other info that might help us debug this:
no locks held by swapper/0.
stack backtrace:
Call Trace:
[c0357ca0] [c0008474] show_stack+0x54/0x18c (unreliable)
[c0357cd0] [c00085cc] dump_stack+0x20/0x38
[c0357ce0] [c00460a0] print_usage_bug+0x130/0x14c
[c0357d10] [c0046674] mark_lock+0xf0/0x4ec
[c0357d30] [c004769c] __lock_acquire+0x40c/0xc04
[c0357d80] [c0047ee8] lock_acquire+0x54/0x78
[c0357da0] [c025c8f0] rt_spin_lock+0x34/0x54
[c0357dc0] [c01c8e14] sil24_interrupt+0x68/0x53c
[c0357e00] [c00529e0] handle_IRQ_event+0x6c/0x114
[c0357e30] [c0052bcc] __do_IRQ+0x144/0x1c4
[c0357e50] [c0017d88] apmax_int_irq_demux+0x90/0xb8
[c0357e70] [c00063f0] do_IRQ+0x6c/0xb0
[c0357e80] [c0010cfc] ret_from_except+0x0/0x28
--- Exception: 501 at check_critical_timing+0x184/0x190
LR =3D check_critical_timing+0x15c/0x190
[c0357f80] [c00519a4] touch_critical_timing+0x5c/0xb0
[c0357fa0] [c00096c4] cpu_idle+0xe4/0x124
[c0357fb0] [c0003bcc] rest_init+0x78/0xac
[c0357fc0] [c030ab9c] start_kernel+0x2c4/0x2dc
[c0357ff0] [00003438] 0x3438
ata1.00: ATA-7: Hitachi HDT725032VLA360, V54OA52A, max UDMA/133
ata1.00: 625142448 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/100
ata2: SATA link down (SStatus 0 SControl 0)
ata3: SATA link down (SStatus 0 SControl 0)
ata4: SATA link down (SStatus 0 SControl 0)
scsi 0:0:0:0: Direct-Access ATA Hitachi HDT72503 V54O PQ: 0
ANSI: 5
sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
sd 0:0:0:0: [sda] Attached SCSI disk
ff800000.flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
ff800000.flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Creating 7 MTD partitions on "ff800000.flash":
0x00000000-0x00010000 : "HWCR"
0x00010000-0x00030000 : "Altera"
0x00030000-0x00600000 : "Kernel"
0x00700000-0x00740000 : "u-boot"
0x00740000-0x00750000 : "u-boot-env"
0x00750000-0x00800000 : "JFFS2"
0x00600000-0x00610000 : "Altera Backup"
of-flash f8400000.sram: Device tree uses obsolete "direct-mapped" flash
binding
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Creating 1 MTD partitions on "f8400000.sram":
0x00000000-0x00020000 : "SRAM"
arp_tables: (C) 2002 David S. Miller
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
------------[ cut here ]------------
kernel BUG at kernel/rtmutex.c:692!
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT Innovative Systems ApMax
Modules linked in:
NIP: c025c340 LR: c025c318 CTR: c01c8dac
REGS: ef859ad0 TRAP: 0700 Not tainted (2.6.24-rt1)
MSR: 00021032 <ME,IR,DR> CR: 28004042 XER: 20000000
TASK =3D ef852090[8] 'softirq-block/0' THREAD: ef858000
GPR00: 00000001 ef859b80 ef852090 00000000 00000000 00000000 00000000
00000002
GPR08: 00000001 ef852090 ef852090 ef859b80 00000000 ffffffff 0fffd000
00000028
GPR16: 00800564 00800000 00000000 007fff00 00000000 00000001 ef8bc000
ef3ac2f0
GPR24: 00000011 00000000 00000000 ef3f77e0 ef858000 00001032 ef3ac2f0
ef859b80
NIP [c025c340] rt_spin_lock_slowlock+0x7c/0x1c0
LR [c025c318] rt_spin_lock_slowlock+0x54/0x1c0
Call Trace:
[ef859b80] [c025c318] rt_spin_lock_slowlock+0x54/0x1c0 (unreliable)
[ef859be0] [c025c78c] __rt_spin_lock+0x80/0x98
[ef859bf0] [c025c8f8] rt_spin_lock+0x3c/0x54
[ef859c10] [c01c8e14] sil24_interrupt+0x68/0x53c
[ef859c50] [c00529e0] handle_IRQ_event+0x6c/0x114
[ef859c80] [c0052bcc] __do_IRQ+0x144/0x1c4
[ef859ca0] [c0017d88] apmax_int_irq_demux+0x90/0xb8
[ef859cc0] [c00063f0] do_IRQ+0x6c/0xb0
[ef859cd0] [c0010cfc] ret_from_except+0x0/0x28
--- Exception: 501 at ata_qc_issue+0x140/0x684
LR =3D ata_scsi_translate+0x138/0x184
[ef859d90] [ef385960] 0xef385960 (unreliable)
[ef859dd0] [c01bd7a0] ata_scsi_translate+0x138/0x184
[ef859e00] [c01c0d0c] ata_scsi_queuecmd+0x210/0x240
[ef859e20] [c01a46d4] scsi_dispatch_cmd+0x1d0/0x240
[ef859e40] [c01aaecc] scsi_request_fn+0x274/0x340
[ef859e60] [c0160b9c] blk_run_queue+0x68/0xac
[ef859e80] [c01a8ee0] scsi_run_queue+0x1cc/0x1e4
[ef859eb0] [c01a9678] scsi_next_command+0x3c/0x5c
[ef859ed0] [c01a987c] scsi_end_request+0xd4/0xf4
[ef859ef0] [c01a9c30] scsi_io_completion+0xf4/0x320
[ef859f30] [c01a3f78] scsi_finish_command+0x94/0xac
[ef859f50] [c01aa5d4] scsi_softirq_done+0xd4/0xec
[ef859f70] [c015c83c] blk_done_softirq+0x8c/0xbc
[ef859f90] [c0026008] ksoftirqd+0x168/0x27c
[ef859fd0] [c00386d0] kthread+0x50/0x90
[ef859ff0] [c0010408] kernel_thread+0x44/0x60
Instruction dump:
7fc3f378 4bdefce9 2f830000 41be0010 7fc3f378 7fa4eb78 48000140 801e002c
5400003a 7c001278 7c000034 5400d97e <0f000000> 38000004 901f0008
801f0008
Kernel panic - not syncing: Fatal exception in interrupt
Call Trace:
[ef8598f0] [c0008474] show_stack+0x54/0x18c (unreliable)
[ef859920] [c00085cc] dump_stack+0x20/0x38
[ef859930] [c001f198] panic+0x94/0x178
[ef859980] [c000e4d0] die+0x178/0x184
[ef8599a0] [c000e6d8] _exception+0x5c/0x17c
[ef859a90] [c000eadc] program_check_exception+0x154/0x504
[ef859ac0] [c0010cb0] ret_from_except_full+0x0/0x4c
--- Exception: 700 at rt_spin_lock_slowlock+0x7c/0x1c0
LR =3D rt_spin_lock_slowlock+0x54/0x1c0
[ef859be0] [c025c78c] __rt_spin_lock+0x80/0x98
[ef859bf0] [c025c8f8] rt_spin_lock+0x3c/0x54
[ef859c10] [c01c8e14] sil24_interrupt+0x68/0x53c
[ef859c50] [c00529e0] handle_IRQ_event+0x6c/0x114
[ef859c80] [c0052bcc] __do_IRQ+0x144/0x1c4
[ef859ca0] [c0017d88] apmax_int_irq_demux+0x90/0xb8
[ef859cc0] [c00063f0] do_IRQ+0x6c/0xb0
[ef859cd0] [c0010cfc] ret_from_except+0x0/0x28
--- Exception: 501 at ata_qc_issue+0x140/0x684
LR =3D ata_scsi_translate+0x138/0x184
[ef859d90] [ef385960] 0xef385960 (unreliable)
[ef859dd0] [c01bd7a0] ata_scsi_translate+0x138/0x184
[ef859e00] [c01c0d0c] ata_scsi_queuecmd+0x210/0x240
[ef859e20] [c01a46d4] scsi_dispatch_cmd+0x1d0/0x240
[ef859e40] [c01aaecc] scsi_request_fn+0x274/0x340
[ef859e60] [c0160b9c] blk_run_queue+0x68/0xac
[ef859e80] [c01a8ee0] scsi_run_queue+0x1cc/0x1e4
[ef859eb0] [c01a9678] scsi_next_command+0x3c/0x5c
[ef859ed0] [c01a987c] scsi_end_request+0xd4/0xf4
[ef859ef0] [c01a9c30] scsi_io_completion+0xf4/0x320
[ef859f30] [c01a3f78] scsi_finish_command+0x94/0xac
[ef859f50] [c01aa5d4] scsi_softirq_done+0xd4/0xec
[ef859f70] [c015c83c] blk_done_softirq+0x8c/0xbc
[ef859f90] [c0026008] ksoftirqd+0x168/0x27c
[ef859fd0] [c00386d0] kthread+0x50/0x90
[ef859ff0] [c0010408] kernel_thread+0x44/0x60
Rebooting in 180 seconds..
^ permalink raw reply
* Re: locking problem in sata_sil24?
From: Benjamin Herrenschmidt @ 2008-03-03 22:37 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0410A524@ismail.innsys.innovsys.com>
On Mon, 2008-03-03 at 16:10 -0600, Rune Torgersen wrote:
> Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel, but
> kept gettign a BUG() (kernel BUG at kernel/rtmutex.c:692).
> While tryiong to figure out what it was, I saw some mention of trying
> LOCKDEP to see what is going on, so I patched my -rt1 kernel with some
> lockdep patches from BenH.
>
> Now I get an "inconsistent locking state", but I need help in trying to
> fiure out what I should look for.
> kernel is fo an Freescale 8280 and the locking seems to occur in the
> driver for a Silicon Image SII3124 SATA disk driver
What core is in the 8280 ? At this stage, I wouldn't rule out a bug in
the lockdep patches, I need to do more work on them.
Cheers,
Ben.
^ permalink raw reply
* RE: locking problem in sata_sil24?
From: Rune Torgersen @ 2008-03-03 22:44 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <1204583866.21545.31.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Mon, 2008-03-03 at 16:10 -0600, Rune Torgersen wrote:
>> Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel,
> What core is in the 8280 ? At this stage, I wouldn't rule out a bug in
> the lockdep patches, I need to do more work on them.
Should be an 603e
adn revision (from u-boot)
CPU: MPC8280 (HiP7 Rev 14, Mask 1.0 1K49M) at 447.897 MHz
I am currently compiling a LOCKDEP kernel for my x86 desktop, as it has
the exact same SiliconImage controller on a card, so I'll see if it gets
a similar detection.
^ permalink raw reply
* RE: locking problem in sata_sil24?
From: Benjamin Herrenschmidt @ 2008-03-03 22:58 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0410A575@ismail.innsys.innovsys.com>
On Mon, 2008-03-03 at 16:44 -0600, Rune Torgersen wrote:
> Benjamin Herrenschmidt wrote:
> > On Mon, 2008-03-03 at 16:10 -0600, Rune Torgersen wrote:
> >> Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel,
>
> > What core is in the 8280 ? At this stage, I wouldn't rule out a bug in
> > the lockdep patches, I need to do more work on them.
>
> Should be an 603e
> adn revision (from u-boot)
> CPU: MPC8280 (HiP7 Rev 14, Mask 1.0 1K49M) at 447.897 MHz
>
>
>
> I am currently compiling a LOCKDEP kernel for my x86 desktop, as it has
> the exact same SiliconImage controller on a card, so I'll see if it gets
> a similar detection.
In fact, I remember working on 64 bits lockdep, based on patches from
Johannes, but I didn't do 32 bits. I think somebody worked on it, but
now I can't find the patches...
Whoever did it can bounce them back to me ? I intend to do some more
work on this soon.
Cheers,
Ben.
^ permalink raw reply
* RE: locking problem in sata_sil24?
From: Rune Torgersen @ 2008-03-03 23:13 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <1204585095.21545.37.camel@pasglop>
> From: Benjamin Herrenschmidt
> In fact, I remember working on 64 bits lockdep, based on patches from
> Johannes, but I didn't do 32 bits. I think somebody worked on it, but
> now I can't find the patches...
http://patchwork.ozlabs.org/linuxppc/patch?id=3D16652
> Whoever did it can bounce them back to me ? I intend to do some more
> work on this soon.
^ permalink raw reply
* RE: locking problem in sata_sil24?
From: Johannes Berg @ 2008-03-03 23:28 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <1204585095.21545.37.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
> In fact, I remember working on 64 bits lockdep, based on patches from
> Johannes,
Your patches never really worked for me so far but I'll be happy to try
new ones, haven't gotten around to checking into the differences.
> but I didn't do 32 bits. I think somebody worked on it, but
> now I can't find the patches...
>
> Whoever did it can bounce them back to me ? I intend to do some more
> work on this soon.
That was Dale Farnsworth, with the subject
"[RFC/PATCH] powerpc: Add irqtrace support to 32-bit powerpc"
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 0/8] pseries: phyp dump: hypervisor-assisted dump
From: Joel Schopp @ 2008-03-03 23:37 UTC (permalink / raw)
To: Manish Ahuja; +Cc: ppc-dev, Linas Vepstas, paulus
In-Reply-To: <47C74A66.1060105@austin.ibm.com>
This looks like it is to a stable usable point now. In my opinion it is
ready to be merged into the next tree for 2.6.26.
Reviewed-by: Joel Schopp <jschopp@austin.ibm.com>
Manish Ahuja wrote:
> Changes from previous version:
>
> The only changes are in patch 2.
> moved early_init_dt_scan_phyp_dump from rtas.c to phyp_dump.c
> Added dummy function in phyp_dump.h
>
> Patch 3 required repatching due to changes to patch 2.
> Resubmitting all patches to avoid confusion.
>
> Thanks,
> Manish
>
>
> Michael Ellerman wrote:
>
>> On Sun, 2008-02-17 at 22:53 -0600, Manish Ahuja wrote:
>>
>>> The following series of patches implement a basic framework
>>> for hypervisor-assisted dump. The very first patch provides
>>> documentation explaining what this is :-) . Yes, its supposed
>>> to be an improvement over kdump.
>>>
>>> A list of open issues / todo list is included in the documentation.
>>> It also appears that the not-yet-released firmware versions this was tested
>>> on are still, ahem, incomplete; this work is also pending.
>>>
>>> I have included most of the changes requested. Although, I did find
>>> one or two, fixed in a later patch file rather than the first location
>>> they appeared at.
>>>
>> This series still doesn't build on !CONFIG_RTAS configs:
>> http://kisskb.ellerman.id.au/kisskb/head/629/
>>
>> This solution is to move early_init_dt_scan_phyp_dump() into
>> arch/powerpc/platforms/pseries/phyp_dump.c and provide a dummy
>> implementation in asm-powerpc/phyp_dump.c for the !CONFIG_PHYP_DUMP
>> case.
>>
>> cheers
>>
>>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Bamboo PCI interrupt issues
From: Hollis Blanchard @ 2008-03-04 0:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc-devel
I'm having two problems with PCI interrupts as described in bamboo.dts.
Here is are the properties in question:
/* Bamboo has all 4 IRQ pins tied together per slot */
interrupt-map-mask = <f800 0 0 0>;
interrupt-map = <
/* IDSEL 1 */
0800 0 0 0 &UIC0 1c 8
/* IDSEL 2 */
1000 0 0 0 &UIC0 1b 8
/* IDSEL 3 */
1800 0 0 0 &UIC0 1a 8
/* IDSEL 4 */
2000 0 0 0 &UIC0 19 8
>;
First, the 440EP[1] and Bamboo[2] user manuals indicate that PCI IRQ 0-3
-> board IRQ 2-5 -> UIC IRQ 25-28. However, the device tree has that
reversed, so PCI IRQ 0 appears as UIC IRQ 28 (0x1c).
Second, the sensitivity seems to be wrong. All these interrupts have the
sensitivity encoded as 8, which means "high to low edge" in the OpenPIC
binding. Now, 440EP has a UIC, rather than an OpenPIC, but there is no
UIC binding AFAICS.
When I change the 8 to a 4 ("active high level"), I see the proper
values in the UIC polarity register, and PCI interrupts start working in
KVM.
Is anybody using Bamboo PCI support right now? Does it actually work?
[1]
https://www.amcc.com/MyAMCC/retrieveDocument/PowerPC/440EP/PPC440EP_UM2000.pdf
[2] Seems to have been deleted from the web. Thanks, AMCC.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 3/3] ppc64-specific memory notifier support
From: Nathan Lynch @ 2008-02-29 0:39 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Badari Pulavarty
In-Reply-To: <1204243875.7729.3.camel@concordia.ozlabs.ibm.com>
Michael Ellerman wrote:
> On Thu, 2008-02-28 at 08:46 -0800, Badari Pulavarty wrote:
> > Hotplug memory notifier for ppc64. This gets invoked by writing
> > the device-node that needs to be removed to /proc/ppc64/ofdt.
> > We need to adjust the sections and remove sysfs entries by
> > calling __remove_pages(). Then call arch specific code to
> > get rid of htab mappings for the section of memory.
> >
> > Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
> > ---
> > arch/powerpc/platforms/pseries/Makefile | 1
> > arch/powerpc/platforms/pseries/hotplug-memory.c | 98 ++++++++++++++++++++++++
> > 2 files changed, 99 insertions(+)
> >
> > Index: linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c
> > ===================================================================
> > --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> > +++ linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c 2008-02-28 08:20:14.000000000 -0800
>
> > +
> > +static struct notifier_block pseries_smp_nb = {
> > + .notifier_call = pseries_memory_notifier,
> > +};
> > +
> > +static int __init pseries_memory_hotplug_init(void)
> > +{
> > + if (firmware_has_feature(FW_FEATURE_LPAR))
> > + pSeries_reconfig_notifier_register(&pseries_smp_nb);
> > +
> > + return 0;
> > +}
> > +arch_initcall(pseries_memory_hotplug_init);
>
> This is going to fire on non-pseries LPAR platforms, like iSeries and
> PS3. Which is not what you want I think.
Well, the notifier will be registered, yes, but it will never be
called because that path is reachable only from a write to
/proc/ppc64/ofdt, which is not created on non-pseries.
Maybe it should be
machine_device_initcall(pseries, pseries_memory_hotplug_init);
(and pseries_cpu_hotplug_init in hotplug-cpu.c should be changed to
machine_arch_initcall)
^ permalink raw reply
* Re: [PATCH 2/2 v2] [POWERPC] Ignore disabled serial ports
From: Arnd Bergmann @ 2008-03-04 0:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Nathan Lynch, paulus
In-Reply-To: <20080303214028.GE4712@localdomain>
On Monday 03 March 2008, Nathan Lynch wrote:
> I agree. =A0Josh's patch is immediately useful to other code as-is.
>=20
> used-by-rtas is powerpc-specific and doesn't belong in drivers/of IMO.
Ok, makes sense, plus paulus looked at the PAPR spec with me and we found
that used-by-rtas doesn't necessarily mean "don't touch" in all
circumstances, so original patch
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: Bamboo PCI interrupt issues
From: David Gibson @ 2008-03-04 0:59 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <1204588953.7921.13.camel@basalt>
On Mon, Mar 03, 2008 at 06:02:33PM -0600, Hollis Blanchard wrote:
> I'm having two problems with PCI interrupts as described in bamboo.dts.
> Here is are the properties in question:
>
> /* Bamboo has all 4 IRQ pins tied together per slot */
> interrupt-map-mask = <f800 0 0 0>;
> interrupt-map = <
> /* IDSEL 1 */
> 0800 0 0 0 &UIC0 1c 8
>
> /* IDSEL 2 */
> 1000 0 0 0 &UIC0 1b 8
>
> /* IDSEL 3 */
> 1800 0 0 0 &UIC0 1a 8
>
> /* IDSEL 4 */
> 2000 0 0 0 &UIC0 19 8
> >;
>
>
> First, the 440EP[1] and Bamboo[2] user manuals indicate that PCI IRQ 0-3
> -> board IRQ 2-5 -> UIC IRQ 25-28. However, the device tree has that
> reversed, so PCI IRQ 0 appears as UIC IRQ 28 (0x1c).
>
> Second, the sensitivity seems to be wrong. All these interrupts have the
> sensitivity encoded as 8, which means "high to low edge" in the OpenPIC
> binding. Now, 440EP has a UIC, rather than an OpenPIC, but there is no
> UIC binding AFAICS.
Uh.. there's no binding written down, it's just encoded into uic.c.
But UIC doesn't use OpenPIC sensitivity encoding. Like FSL's IPIC, it
uses Linux IRQ_TYPE values from include/linux/irq.h which makes 8
"level sensitive, active-low".
> When I change the 8 to a 4 ("active high level"), I see the proper
> values in the UIC polarity register, and PCI interrupts start working in
> KVM.
>
> Is anybody using Bamboo PCI support right now? Does it actually work?
>
> [1]
> https://www.amcc.com/MyAMCC/retrieveDocument/PowerPC/440EP/PPC440EP_UM2000.pdf
> [2] Seems to have been deleted from the web. Thanks, AMCC.
>
--
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: Bamboo PCI interrupt issues
From: Benjamin Herrenschmidt @ 2008-03-04 1:42 UTC (permalink / raw)
To: David Gibson; +Cc: kvm-ppc-devel, linuxppc-dev, Hollis Blanchard
In-Reply-To: <20080304005922.GB1393@localhost.localdomain>
On Tue, 2008-03-04 at 11:59 +1100, David Gibson wrote:
>
> Uh.. there's no binding written down, it's just encoded into uic.c.
> But UIC doesn't use OpenPIC sensitivity encoding. Like FSL's IPIC, it
> uses Linux IRQ_TYPE values from include/linux/irq.h which makes 8
> "level sensitive, active-low".
On a related note: aren't we taking a risk here of seeing those values
change in linux ?
Ben.
^ permalink raw reply
* DTC and Git and MontaVista
From: Jon Loeliger @ 2008-03-04 1:52 UTC (permalink / raw)
To: linuxppc-dev
Guys,
Sorry to bother everyone, but someone at MontaVista
who was trying to get the DTC today needs to update
their version of git to be something modern.
Thanks,
jdl
^ permalink raw reply
* Re: Bamboo PCI interrupt issues
From: David Gibson @ 2008-03-04 1:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: kvm-ppc-devel, linuxppc-dev, Hollis Blanchard
In-Reply-To: <1204594967.21545.46.camel@pasglop>
On Tue, Mar 04, 2008 at 12:42:47PM +1100, Benjamin Herrenschmidt wrote:
>
> On Tue, 2008-03-04 at 11:59 +1100, David Gibson wrote:
> >
> > Uh.. there's no binding written down, it's just encoded into uic.c.
> > But UIC doesn't use OpenPIC sensitivity encoding. Like FSL's IPIC, it
> > uses Linux IRQ_TYPE values from include/linux/irq.h which makes 8
> > "level sensitive, active-low".
>
> On a related note: aren't we taking a risk here of seeing those values
> change in linux ?
We've discussed this before. If that happens, the binding must remain
on the old values. It means the driver will then need a translation
which it doesn't now, but we can deal with it.
--
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: Bamboo PCI interrupt issues
From: Segher Boessenkool @ 2008-03-04 2:07 UTC (permalink / raw)
To: David Gibson; +Cc: kvm-ppc-devel, linuxppc-dev, Hollis Blanchard
In-Reply-To: <20080304015329.GE1393@localhost.localdomain>
>>> Uh.. there's no binding written down, it's just encoded into uic.c.
>>> But UIC doesn't use OpenPIC sensitivity encoding. Like FSL's IPIC,
>>> it
>>> uses Linux IRQ_TYPE values from include/linux/irq.h which makes 8
>>> "level sensitive, active-low".
>>
>> On a related note: aren't we taking a risk here of seeing those values
>> change in linux ?
>
> We've discussed this before. If that happens, the binding must remain
> on the old values. It means the driver will then need a translation
> which it doesn't now, but we can deal with it.
It also means it should be written down in the binding _already_.
Come on, how much work is that?
Segher
^ permalink raw reply
* Re: Bamboo PCI interrupt issues
From: David Gibson @ 2008-03-04 2:15 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: kvm-ppc-devel, linuxppc-dev, Hollis Blanchard
In-Reply-To: <08b18695c383fb829ecf3ab6c2822bd1@kernel.crashing.org>
On Tue, Mar 04, 2008 at 03:07:50AM +0100, Segher Boessenkool wrote:
> >>> Uh.. there's no binding written down, it's just encoded into uic.c.
> >>> But UIC doesn't use OpenPIC sensitivity encoding. Like FSL's IPIC,
> >>> it
> >>> uses Linux IRQ_TYPE values from include/linux/irq.h which makes 8
> >>> "level sensitive, active-low".
> >>
> >> On a related note: aren't we taking a risk here of seeing those values
> >> change in linux ?
> >
> > We've discussed this before. If that happens, the binding must remain
> > on the old values. It means the driver will then need a translation
> > which it doesn't now, but we can deal with it.
>
> It also means it should be written down in the binding _already_.
Well, yes, there should be, but isn't, a written binding for this,
amongst many other things.
> Come on, how much work is that?
Greater than zero.
--
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: Bamboo PCI interrupt issues
From: Josh Boyer @ 2008-03-04 3:37 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <1204588953.7921.13.camel@basalt>
On Mon, 03 Mar 2008 18:02:33 -0600
Hollis Blanchard <hollisb@us.ibm.com> wrote:
> I'm having two problems with PCI interrupts as described in bamboo.dts.
> Here is are the properties in question:
>
> /* Bamboo has all 4 IRQ pins tied together per slot */
> interrupt-map-mask = <f800 0 0 0>;
> interrupt-map = <
> /* IDSEL 1 */
> 0800 0 0 0 &UIC0 1c 8
>
> /* IDSEL 2 */
> 1000 0 0 0 &UIC0 1b 8
>
> /* IDSEL 3 */
> 1800 0 0 0 &UIC0 1a 8
>
> /* IDSEL 4 */
> 2000 0 0 0 &UIC0 19 8
> >;
>
>
> First, the 440EP[1] and Bamboo[2] user manuals indicate that PCI IRQ 0-3
> -> board IRQ 2-5 -> UIC IRQ 25-28. However, the device tree has that
> reversed, so PCI IRQ 0 appears as UIC IRQ 28 (0x1c).
Actually, the device tree is right. I got annoyed with myself for not
knowing how this works so I went and figured it out.
2000 0 0 0 is device #4. According to the specs, device #4 has AD(14)
asserted during type 0 configuration. Looking at the board schematics,
PCI slot 0 has it's IDSEL line tied to AD(14). So:
dev #4 -> PCI 0 -> board IRQ 2 -> UIC IRQ 25.
which is exactly what the device tree has.
> Second, the sensitivity seems to be wrong. All these interrupts have the
> sensitivity encoded as 8, which means "high to low edge" in the OpenPIC
> binding. Now, 440EP has a UIC, rather than an OpenPIC, but there is no
> UIC binding AFAICS.
There isn't. It uses the sense numbers from linux/irq.h. Which means
8 is level, low. This matches exactly what the board manual says for
IRQ2-5 on page 69.
> When I change the 8 to a 4 ("active high level"), I see the proper
> values in the UIC polarity register, and PCI interrupts start working in
> KVM.
That's odd.
> Is anybody using Bamboo PCI support right now? Does it actually work?
I plugged in an old 3Com ethernet card tonight. Slot 0. It was
assigned dev #4 IRQ 25. Using the device tree as-is, I could see
interrupts happening in /proc/interrupts but ethernet traffic failed.
Then I changed the sense level to 4 as you suggested, and my card hung
hard on the first ethernet traffic. I've no idea if we're dealing with
a crappy card or a crappy driver but the device tree seems to be
working ok. If I can find a different card to test with I will.
Ben, do you have any input here?
josh
^ permalink raw reply
* [PATCH] Correct a terrible scheduling error
From: Segher Boessenkool @ 2008-03-04 3:42 UTC (permalink / raw)
To: linuxppc-dev
It would be a pity if we can't all enjoy this.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
---
Documentation/feature-removal-schedule.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index c1d1fd0..78021bf 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -201,13 +201,13 @@ Who: Tejun Heo <htejun@gmail.com>
---------------------------
What: The arch/ppc and include/asm-ppc directories
-When: Jun 2008
+When: end of July 2008
Why: The arch/powerpc tree is the merged architecture for ppc32 and ppc64
platforms. Currently there are efforts underway to port the remaining
arch/ppc platforms to the merged tree. New submissions to the arch/ppc
tree have been frozen with the 2.6.22 kernel release and that tree will
remain in bug-fix only mode until its scheduled removal. Platforms
- that are not ported by June 2008 will be removed due to the lack of an
+ that are not ported by July 2008 will be removed due to the lack of an
interested maintainer.
Who: linuxppc-dev@ozlabs.org
--
1.5.3.4.208.g805a
^ permalink raw reply related
* dtc: Make some functions local to parser
From: David Gibson @ 2008-03-04 4:37 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
* eval_literal() is defined and used only in the parser, so make it
static.
* The Bison documentation explicitly permits yyerror() to be a
variadic function, so fold yyerror() and yyerrorf() into a single
printf-style function. The combined function is defined and used
only in the parse, so make it static.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
dtc-parser.y | 14 +++++---------
srcpos.h | 3 ---
2 files changed, 5 insertions(+), 12 deletions(-)
Index: dtc/dtc-parser.y
===================================================================
--- dtc.orig/dtc-parser.y 2008-03-04 15:29:09.000000000 +1100
+++ dtc/dtc-parser.y 2008-03-04 15:31:32.000000000 +1100
@@ -24,12 +24,13 @@
#include "dtc.h"
#include "srcpos.h"
-int yylex(void);
-unsigned long long eval_literal(const char *s, int base, int bits);
+extern int yylex(void);
extern struct boot_info *the_boot_info;
extern int treesource_error;
+static void yyerror(char const *, ...) __attribute__((format(printf, 1, 2)));
+static unsigned long long eval_literal(const char *s, int base, int bits);
%}
%union {
@@ -308,7 +309,7 @@ label:
%%
-void yyerrorf(char const *s, ...)
+static void yyerror(char const *s, ...)
{
const char *fname = srcpos_file ? srcpos_file->name : "<no-file>";
va_list va;
@@ -325,12 +326,7 @@ void yyerrorf(char const *s, ...)
va_end(va);
}
-void yyerror (char const *s)
-{
- yyerrorf("%s", s);
-}
-
-unsigned long long eval_literal(const char *s, int base, int bits)
+static unsigned long long eval_literal(const char *s, int base, int bits)
{
unsigned long long val;
char *e;
Index: dtc/srcpos.h
===================================================================
--- dtc.orig/srcpos.h 2008-03-04 15:30:06.000000000 +1100
+++ dtc/srcpos.h 2008-03-04 15:30:09.000000000 +1100
@@ -70,9 +70,6 @@ typedef struct YYLTYPE {
-extern void yyerror(char const *);
-extern void yyerrorf(char const *, ...) __attribute__((format(printf, 1, 2)));
-
extern struct dtc_file *srcpos_file;
extern void push_input_file(const char *filename);
--
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
* dtc: Make dt_from_blob() open its own file
From: David Gibson @ 2008-03-04 5:10 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
dt_from_source() and dt_from_fs() both take a filename (or directory
name) argument and open files as necessary themselves.
dt_from_blob(), however, expects the caller to open a file and pass it
in.
This patch makes dt_from_blob() take a filename and open its own
files, removing the inconsistency. In addition, dt_from_blob() now
correctly uses dtc_close_file() to close the file opened with
dtc_open_file(), rather than directly calling fclose() on the
contained FILE *.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
dtc.c | 11 +----------
dtc.h | 4 ++--
flattree.c | 10 +++++++++-
3 files changed, 12 insertions(+), 13 deletions(-)
Index: dtc/dtc.c
===================================================================
--- dtc.orig/dtc.c 2008-03-04 15:58:49.000000000 +1100
+++ dtc/dtc.c 2008-03-04 16:02:12.000000000 +1100
@@ -118,7 +118,6 @@ int main(int argc, char *argv[])
int force = 0, check = 0;
const char *arg;
int opt;
- struct dtc_file *inf = NULL;
FILE *outf = NULL;
int outversion = DEFAULT_FDT_VERSION;
int boot_cpuid_phys = 0xfeedbeef;
@@ -192,19 +191,11 @@ int main(int argc, char *argv[])
} else if (streq(inform, "fs")) {
bi = dt_from_fs(arg);
} else if(streq(inform, "dtb")) {
- inf = dtc_open_file(arg, NULL);
- if (!inf)
- die("Couldn't open \"%s\": %s\n", arg,
- strerror(errno));
-
- bi = dt_from_blob(inf->file);
+ bi = dt_from_blob(arg);
} else {
die("Unknown input format \"%s\"\n", inform);
}
- if (inf && inf->file != stdin)
- fclose(inf->file);
-
if (! bi || ! bi->dt || bi->error)
die("Couldn't read input tree\n");
Index: dtc/flattree.c
===================================================================
--- dtc.orig/flattree.c 2008-03-04 15:59:53.000000000 +1100
+++ dtc/flattree.c 2008-03-04 16:06:55.000000000 +1100
@@ -19,6 +19,7 @@
*/
#include "dtc.h"
+#include "srcpos.h"
#define FTF_FULLPATH 0x1
#define FTF_VARALIGN 0x2
@@ -780,8 +781,10 @@ static struct node *unflatten_tree(struc
}
-struct boot_info *dt_from_blob(FILE *f)
+struct boot_info *dt_from_blob(const char *fname)
{
+ struct dtc_file *dtcf;
+ FILE *f;
u32 magic, totalsize, version, size_dt;
u32 off_dt, off_str, off_mem_rsvmap;
int rc;
@@ -796,6 +799,9 @@ struct boot_info *dt_from_blob(FILE *f)
u32 val;
int flags = 0;
+ dtcf = dtc_open_file(fname, NULL);
+ f = dtcf->file;
+
rc = fread(&magic, sizeof(magic), 1, f);
if (ferror(f))
die("Error reading DT blob magic number: %s\n",
@@ -902,5 +908,7 @@ struct boot_info *dt_from_blob(FILE *f)
free(blob);
+ dtc_close_file(dtcf);
+
return build_boot_info(reservelist, tree);
}
Index: dtc/dtc.h
===================================================================
--- dtc.orig/dtc.h 2008-03-04 16:01:22.000000000 +1100
+++ dtc/dtc.h 2008-03-04 16:01:43.000000000 +1100
@@ -250,12 +250,12 @@ void dt_to_blob(FILE *f, struct boot_inf
void dt_to_asm(FILE *f, struct boot_info *bi, int version,
int boot_cpuid_phys);
-struct boot_info *dt_from_blob(FILE *f);
+struct boot_info *dt_from_blob(const char *fname);
/* Tree source */
void dt_to_source(FILE *f, struct boot_info *bi);
-struct boot_info *dt_from_source(const char *f);
+struct boot_info *dt_from_source(const char *fname);
/* FS trees */
--
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: dtc: Make dt_from_blob() open its own file
From: David Gibson @ 2008-03-04 5:15 UTC (permalink / raw)
To: Jon Loeliger, linuxppc-dev
In-Reply-To: <20080304051039.GC2757@localhost.localdomain>
On Tue, Mar 04, 2008 at 04:10:39PM +1100, David Gibson wrote:
> dt_from_source() and dt_from_fs() both take a filename (or directory
> name) argument and open files as necessary themselves.
> dt_from_blob(), however, expects the caller to open a file and pass it
> in.
>
> This patch makes dt_from_blob() take a filename and open its own
> files, removing the inconsistency. In addition, dt_from_blob() now
> correctly uses dtc_close_file() to close the file opened with
> dtc_open_file(), rather than directly calling fclose() on the
> contained FILE *.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Sorry, ignore. There's a bug in this one, revised version coming.
--
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: Bamboo PCI interrupt issues
From: Stefan Roese @ 2008-03-04 6:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc-devel, Hollis Blanchard
In-Reply-To: <20080303213718.12291eee@zod.rchland.ibm.com>
On Tuesday 04 March 2008, Josh Boyer wrote:
> > Is anybody using Bamboo PCI support right now? Does it actually work?
>
> I plugged in an old 3Com ethernet card tonight. Slot 0. It was
> assigned dev #4 IRQ 25. Using the device tree as-is, I could see
> interrupts happening in /proc/interrupts but ethernet traffic failed.
>
> Then I changed the sense level to 4 as you suggested, and my card hung
> hard on the first ethernet traffic.
Using '8' is correct. PCI interrupts are *always* level sensitive and active
low.
> I've no idea if we're dealing with
> a crappy card or a crappy driver but the device tree seems to be
> working ok. If I can find a different card to test with I will.
One thing always worth to check on 4xx IRQ problems is, if the external IRQ
pins are configured correctly for IRQ usage. Most of the times, the external
IRQ's are shared with other peripheral pins and/or GPIO pins. This
configuration is done in the GPIO core (and sometimes SDR PFCx registers).
This should be done correctly by the bootloader but sometimes the
configuration is wrong. I have to admit that I probably never tested PCI on
Bamboo. Just a thought.
Best regards,
Stefan
^ 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