* Re: [PATCH] eeh: Fixing a bug when pci structure is null
From: Mike Mason @ 2010-02-24 22:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Linas Vepstas, Breno Leitao
In-Reply-To: <1266616485.23523.1026.camel@pasglop>
On 2/19/2010 1:54 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2010-02-19 at 14:43 -0200, Breno Leitao wrote:
>> Hi Ben,
>>
>> I'd like to ask about this patch ? Should I re-submit ?
>>
>> Thanks,
>>
>> Breno Leitao wrote:
>>> During a EEH recover, the pci_dev structure can be null, mainly if an
>>> eeh event is detected during cpi config operation. In this case, the
>>> pci_dev will not be known (and will be null) the kernel will crash
>>> with the following message:
>
> It should be in -next, can you dbl check ?
I just confirmed the patch is in the -next tree.
Mike
>
> Cheers,
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: PCI on 834x
From: Kumar Gala @ 2010-02-24 22:25 UTC (permalink / raw)
To: Gary Thomas; +Cc: Scott Wood, linuxppc-dev, avorontsov
In-Reply-To: <4B85A4C2.6090007@mlbassoc.com>
On Feb 24, 2010, at 4:14 PM, Gary Thomas wrote:
> On 02/24/2010 01:51 PM, Anton Vorontsov wrote:
>> On Wed, Feb 24, 2010 at 02:26:20PM -0600, Scott Wood wrote:
>>> Gary Thomas wrote:
>>>> Yes, I'm using the exact same kernel with these two different PCI
>>>> setups (done by the boot loader).
>>>>=20
>>>> Restricting the memory via mem=3D128M has no effect - the PCI =
layout
>>>> is the same.
>>>>=20
>>>> I think the outbound window size is required because of how the =
Linux PCI
>>>> remaps the space (note in my dumps that it put the MMIO of the
>>>> boards starting
>>>> at 0xD0000000 when the inbound window is 0x10000000)
>>>=20
>>> I see where the amount of RAM is mattering -- Linux is assigning
>>> outbound I/O space to the PCI controller itself (device 00:00.0) and
>>> the amount that it asks for seems to differ based on memory size.
>>> Linux ought to skip that device when assigning resources. Some
>>> platforms do this (search for pci_exclude_device), but it seems to
>>> be missing on 83xx.
>>=20
>> Actually, 83xx had these exclude_device hooks, but they were removed:
>>=20
>> commit d8f1324a5063c833862328ceafabc53ac3cc4f71
>> Author: Kumar Gala<galak@kernel.crashing.org>
>> Date: Wed Sep 12 22:14:10 2007 -0500
>>=20
>> [POWERPC] 83xx: Removed PCI exclude of PHB
>>=20
>> Now that the generic code doesn't assign resources for Freescale
>> PHBs we dont have to explicitly exclude it.
>>=20
>> Signed-off-by: Kumar Gala<galak@kernel.crashing.org>
>>=20
>>=20
>> May be the generic code started to assign the resources again?
>>=20
>=20
> That cracked it; I re-enabled the exclusion of the bridge and now
> it's all working fine.
>=20
> Thanks for the help
>=20
> Note: I'm working with a fairly old kernel, so these results would
> have to be reworked against the latest.
Odd that the generic code isn't dealing with that for you.
- k=
^ permalink raw reply
* Re: PCI on 834x
From: Gary Thomas @ 2010-02-24 23:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, avorontsov
In-Reply-To: <A0F7894F-8B88-4646-8B81-830F67E39489@kernel.crashing.org>
On 02/24/2010 03:25 PM, Kumar Gala wrote:
>
> On Feb 24, 2010, at 4:14 PM, Gary Thomas wrote:
>
>> On 02/24/2010 01:51 PM, Anton Vorontsov wrote:
>>> On Wed, Feb 24, 2010 at 02:26:20PM -0600, Scott Wood wrote:
>>>> Gary Thomas wrote:
>>>>> Yes, I'm using the exact same kernel with these two different PCI
>>>>> setups (done by the boot loader).
>>>>>
>>>>> Restricting the memory via mem=128M has no effect - the PCI layout
>>>>> is the same.
>>>>>
>>>>> I think the outbound window size is required because of how the Linux PCI
>>>>> remaps the space (note in my dumps that it put the MMIO of the
>>>>> boards starting
>>>>> at 0xD0000000 when the inbound window is 0x10000000)
>>>>
>>>> I see where the amount of RAM is mattering -- Linux is assigning
>>>> outbound I/O space to the PCI controller itself (device 00:00.0) and
>>>> the amount that it asks for seems to differ based on memory size.
>>>> Linux ought to skip that device when assigning resources. Some
>>>> platforms do this (search for pci_exclude_device), but it seems to
>>>> be missing on 83xx.
>>>
>>> Actually, 83xx had these exclude_device hooks, but they were removed:
>>>
>>> commit d8f1324a5063c833862328ceafabc53ac3cc4f71
>>> Author: Kumar Gala<galak@kernel.crashing.org>
>>> Date: Wed Sep 12 22:14:10 2007 -0500
>>>
>>> [POWERPC] 83xx: Removed PCI exclude of PHB
>>>
>>> Now that the generic code doesn't assign resources for Freescale
>>> PHBs we dont have to explicitly exclude it.
>>>
>>> Signed-off-by: Kumar Gala<galak@kernel.crashing.org>
>>>
>>>
>>> May be the generic code started to assign the resources again?
>>>
>>
>> That cracked it; I re-enabled the exclusion of the bridge and now
>> it's all working fine.
>>
>> Thanks for the help
>>
>> Note: I'm working with a fairly old kernel, so these results would
>> have to be reworked against the latest.
>
> Odd that the generic code isn't dealing with that for you.
Remember it's an old kernel (2.6.28), so who knows the status.
As I said, I'll revisit this when I move to a newer kernel.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* MPC860 SCC HDLC driver under linux2.6
From: alex_hhy @ 2010-02-25 3:53 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 155 bytes --]
Hi,
I'm trying to drive SCC of MPC860 as HDLC mode under linux2.6.
Is there a completely driver? Who know this?
Best regards!
Alex ho.
[-- Attachment #2: Type: text/html, Size: 2715 bytes --]
^ permalink raw reply
* TBI interface
From: Hillery, Nathan @ 2010-02-25 5:34 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2882 bytes --]
I have a system with an SGMII interface on an MPC8536E, attached to a
Marvel 88E6152 Ethernet switch chip. I can access Ethernet from u-boot,
if I initially configure the MII "phy" and the switch port PHY to
disable auto-negotiation and assert link up. The link speed is 10Mbps
and it is half-duplex. When u-boot starts, reports that it didn't
recognize a PHY 0xFFFF id, and says it will assume a generic phy.
Obviously, I'd like to run without having to manually configure and have
it run at 1gbps, full-duplex.
However, I am not able to get linux to recognize the device - it reports
that a ten-bit interface (TBI) is required for SGMII and it can't find
one. I have a tbi-phy entry in the device-tree file. Here's the
relevant snippet:
mdio@24520 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-tbi";
reg = <0x24520 0x20>;
phy0: ethernet-phy@0x10 {
interrupt-parent = <&mpic>;
interrupts = <10 0x1>;
reg = <0x10>;
device_type = "ethernet-phy";
};
tbi0: tbi-phy@4 {
reg = <0x4>;
device_type = "tbi-phy";
};
};
enet0: ethernet@24000 {
cell-index = <0>;
device_type = "network";
model = "eTSEC";
compatible = "gianfar";
reg = <0x24000 0x1000>;
local-mac-address = [ 00
00 00 00 00 00 ];
interrupts = <29 2 30 2
34 2>;
interrupt-parent =
<&mpic>;
tbi-handle = <&tbi0>;
phy-handle = <&phy0>;
phy-connection-type =
"sgmii";
fsl,magic-packet;
fsl,wake-on-filer;
};
The processor has an MDIO interface to the switch. The switch port PHYs
are 0x10, 0x11, 0x12, 0x13, 0x17, and 0x19. I picked 4 for the TBI
arbitrarily (but seeking to avoid conflicting a PHY address).
Any hints will be appreciated.
[-- Attachment #2: Type: text/html, Size: 11577 bytes --]
^ permalink raw reply
* Re: TBI interface
From: Vadim Bendebury @ 2010-02-25 7:00 UTC (permalink / raw)
To: Hillery, Nathan; +Cc: linuxppc-dev
In-Reply-To: <DA601BED1671C24093F284F75082C99340B6CE@rtpwbee01.SIXIS.NS>
V2l0aG91dCBnb2luZyBpbnRvIG11Y2ggZGV0YWlscyBvZiB5b3VyIHBhcnRpY3VsYXIgY2FzZSwg
SSBjYW4gc2hhcmUKbXkgZXhwZXJpZW5jZSBkb2luZyBhIHNpbWlsYXIgdGhpbmcgd2l0aCBhIGRp
ZmZlcmVudCBmcmVlc2NhbGUgQ1BVOgoKLSBDT05GSUdfRklYRURfUEhZIG5lZWRzIHRvIGJlIGVu
YWJsZWQgKHRoaXMgYWN0aXZhdGVzIGEgInBzZXVkbyBwaHkiKQoKLSB0aGUgVEJJICh0ZW4gYml0
IGludGVyZmFjZSkgaXMgYW4gaW50ZXJuYWwgZGV2aWNlIGF0dGFjaGVkIHRvIHRoZQpNSUkgaW50
ZXJmYWNlIGFzc29jaWF0ZWQgd2l0aCB0aGUgZXRoZXJuZXQgaW50ZXJmYWNlLiBUaGUgTUlJIGJ1
cwphZGRyZXNzIG9mIHRoZSBUQkkgaXMgY29uZmlndXJhYmxlLCB1LWJvb3Qgc2V0cyBpdCB0byBD
RkdfVEJJUEFfVkFMVUUKKGVhY2ggZXRoZXJuZXQgaW50ZXJmYWNlIGFzc2lnbnMgdGhpcyBzZXBh
cmF0ZWx5IGFzIGludGVybmFsbHkgdGhleQphbGwgaGF2ZSBzZXBhcmF0ZSBNSUkgYnVzZXMpLiBU
aGUgc2FtZSBDRkdfVEJJUEFfVkFMVUUgIHZhbHVlIG5lZWRzIHRvCmJlIGxpc3RlZCBpbiB0aGUg
cmVnPD4gcHJvcGVydHkgb2YgdGhlIGFwcHJvcHJpYXRlIHRiaS1waHkgbm9kZXMgaW4KdGhlIGRl
dmljZSB0cmVlLgoKCmdvb2QgbHVjayEKCi92YgoKCk9uIFdlZCwgRmViIDI0LCAyMDEwIGF0IDk6
MzQgUE0sIEhpbGxlcnksIE5hdGhhbiA8bmhpbGxlcnlAc2l4aXNpbmMuY29tPiB3cm90ZToKPiBJ
IGhhdmUgYSBzeXN0ZW0gd2l0aCBhbiBTR01JSSBpbnRlcmZhY2Ugb24gYW4gTVBDODUzNkUsIGF0
dGFjaGVkIHRvIGEgTWFydmVsCj4gODhFNjE1MiBFdGhlcm5ldCBzd2l0Y2ggY2hpcC6gIEkgY2Fu
IGFjY2VzcyBFdGhlcm5ldCBmcm9tIHUtYm9vdCwgaWYgSQo+IGluaXRpYWxseSBjb25maWd1cmUg
dGhlIE1JSSCTcGh5lCBhbmQgdGhlIHN3aXRjaCBwb3J0IFBIWSB0byBkaXNhYmxlCj4gYXV0by1u
ZWdvdGlhdGlvbiBhbmQgYXNzZXJ0IGxpbmsgdXAuoCBUaGUgbGluayBzcGVlZCBpcyAxME1icHMg
YW5kIGl0IGlzCj4gaGFsZi1kdXBsZXguIKBXaGVuIHUtYm9vdCBzdGFydHMsIHJlcG9ydHMgdGhh
dCBpdCBkaWRuknQgcmVjb2duaXplIGEgUEhZCj4gMHhGRkZGIGlkLCBhbmQgc2F5cyBpdCB3aWxs
IGFzc3VtZSBhIGdlbmVyaWMgcGh5Lgo+Cj4KPgo+IE9idmlvdXNseSwgSZJkIGxpa2UgdG8gcnVu
IHdpdGhvdXQgaGF2aW5nIHRvIG1hbnVhbGx5IGNvbmZpZ3VyZSBhbmQgaGF2ZSBpdAo+IHJ1biBh
dCAxZ2JwcywgZnVsbC1kdXBsZXguCj4KPgo+Cj4gSG93ZXZlciwgSSBhbSBub3QgYWJsZSB0byBn
ZXQgbGludXggdG8gcmVjb2duaXplIHRoZSBkZXZpY2UgliBpdCByZXBvcnRzCj4gdGhhdCBhIHRl
bi1iaXQgaW50ZXJmYWNlIChUQkkpIGlzIHJlcXVpcmVkIGZvciBTR01JSSBhbmQgaXQgY2FuknQg
ZmluZCBvbmUuCj4gSSBoYXZlIGEgdGJpLXBoeSBlbnRyeSBpbiB0aGUgZGV2aWNlLXRyZWUgZmls
ZS6gIEhlcmWScyB0aGUgcmVsZXZhbnQKPiBzbmlwcGV0Ogo+Cj4KPgo+IKCgoKCgoKCgoKCgoKCg
oCBtZGlvQDI0NTIwIHsKPgo+IKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgICNhZGRyZXNzLWNlbGxz
ID0gPDE+Owo+Cj4goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgI3NpemUtY2VsbHMgPSA8MD47Cj4K
PiCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBjb21wYXRpYmxlID0gImZzbCxnaWFuZmFyLXRiaSI7
Cj4KPiCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCByZWcgPSA8MHgyNDUyMCAweDIwPjsKPgo+Cj4K
PiCgoKCgoKCgIKCgoKCgoKCgoKCgoKCgoKBwaHkwOiBldGhlcm5ldC1waHlAMHgxMCB7Cj4KPiCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIGludGVycnVwdC1wYXJlbnQgPSA8Jm1waWM+
Owo+Cj4goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBpbnRlcnJ1cHRzID0gPDEwIDB4
MT47Cj4KPiCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIHJlZyA9IDwweDEwPjsKPgo+
IKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgZGV2aWNlX3R5cGUgPSAiZXRoZXJuZXQt
cGh5IjsKPgo+IKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIH07Cj4KPgo+Cj4goKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKAgdGJpMDogdGJpLXBoeUA0IHsKPgo+IKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKAgcmVnID0gPDB4ND47Cj4KPiCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
IGRldmljZV90eXBlID0gInRiaS1waHkiOwo+Cj4goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgfTsK
Pgo+IKCgoKCgoKCgoKCgoKCgoCB9Owo+Cj4goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oCBlbmV0MDogZXRoZXJuZXRAMjQwMDAgewo+Cj4goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKAgY2VsbC1pbmRleCA9IDwwPjsKPgo+IKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIGRldmljZV90eXBlID0gIm5ldHdvcmsi
Owo+Cj4goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgbW9k
ZWwgPSAiZVRTRUMiOwo+Cj4goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKAgY29tcGF0aWJsZSA9ICJnaWFuZmFyIjsKPgo+IKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIHJlZyA9IDwweDI0MDAwIDB4MTAwMD47Cj4KPiCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBsb2NhbC1tYWMt
YWRkcmVzcyA9IFsgMDAgMDAKPiAwMCAwMCAwMCAwMCBdOwo+Cj4goKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgaW50ZXJydXB0cyA9IDwyOSAyIDMwIDIgMzQK
PiAyPjsKPgo+IKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
IGludGVycnVwdC1wYXJlbnQgPSA8Jm1waWM+Owo+Cj4goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgdGJpLWhhbmRsZSA9IDwmdGJpMD47Cj4KPiCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBwaHktaGFuZGxlID0gPCZw
aHkwPjsKPgo+IKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
IHBoeS1jb25uZWN0aW9uLXR5cGUgPQo+ICJzZ21paSI7Cj4KPiCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCBmc2wsbWFnaWMtcGFja2V0Owo+Cj4goKCgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgZnNsLHdha2Utb24tZmls
ZXI7Cj4KPiCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIH07Cj4KPgo+Cj4gVGhlIHBy
b2Nlc3NvciBoYXMgYW4gTURJTyBpbnRlcmZhY2UgdG8gdGhlIHN3aXRjaC6gIFRoZSBzd2l0Y2gg
cG9ydCBQSFlzIGFyZQo+IDB4MTAsIDB4MTEsIDB4MTIsIDB4MTMsIDB4MTcsIGFuZCAweDE5LiBJ
IHBpY2tlZCA0IGZvciB0aGUgVEJJIGFyYml0cmFyaWx5Cj4gKGJ1dCBzZWVraW5nIHRvIGF2b2lk
IGNvbmZsaWN0aW5nIGEgUEhZIGFkZHJlc3MpLgo+Cj4KPgo+IEFueSBoaW50cyB3aWxsIGJlIGFw
cHJlY2lhdGVkLgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KPiBMaW51eHBwYy1kZXYgbWFpbGluZyBsaXN0Cj4gTGludXhwcGMtZGV2QGxpc3RzLm96
bGFicy5vcmcKPiBodHRwczovL2xpc3RzLm96bGFicy5vcmcvbGlzdGluZm8vbGludXhwcGMtZGV2
Cj4K
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Martyn Welch @ 2010-02-25 10:31 UTC (permalink / raw)
To: linuxppc-dev list, netdev, linux-kernel
Cc: Anton Vorontsov, Sandeep Gopalpet, davem
In-Reply-To: <4B6C2488.3060403@ge.com>
Martyn Welch wrote:
> I have recently attempted to boot an 8641D based board from an NFS root.
> The boot process grinds to a halt not long after the first access of the
> NFS root and I receive multiple "nfs: server 192.168.0.1 not responding,
> still trying" messages. Wireshark suggests that there is no further
> traffic from this board at this point on. The NFS server seems to
> eventually try sending duplicate packets it's already sent, which
> results in "nfs: server 192.168.0.1 OK" messages, but the "not
> responding" messages resume with no further traffic from the board.
>
> I am able to boot to a ramdisk fine and the network seems to work -
> though I haven't really pushed the interface from it.
>
> I have attempted to git bisect, though I wasn't able to get much further
> than discovering the problem was introduced in the 2.6.33 merge window -
> at which point the gianfar network driver fails to compile (I have tried
> to git bisect skip many, many times to no avail).
>
> NFS booting fails for this board on todays linux-next, the master branch
> of Kumar's PPC tree and the head of the main tree. I have also been able
> to NFS boot from a random x86 based board that I have, using the head of
> the main tree and the linux-next tree.
>
> Copying the gianfar drivers from 2.6.32 into the head of the main tree
> restores the correct behaviour and I'm able to NFS boot. I have heard
> from others that the latest drivers work on 83xx and 85xx based boards,
> but it seems to be broken on at least the 8641D.
>
> I can see there has been a fair amount of work done on the gianfar
> driver, I assume that this is a bug introduced by the multiple queue
> support, but I'm way out of my depth on this.
>
I have just compiled 2.6.33 for the Freescale MPC8641_HPCN demo board
and am having still experiencing the problems outlined in my previous
email, though I have noticed that I tend to be able to boot from cold,
but my boot fails on reboot. Hitting the reset button doesn't help, I
need to actually power the machine on and off again for it to work.
As before, I'm way out of my depth in this, any one have any ideas?
Below is a dump of the failed boot process:
U-Boot 2009.01-00181-gc1b7c70 (Jan 30 2009 - 11:17:31)
Freescale PowerPC
CPU:
Core: E600 Core 0, Version: 0.2, (0x80040202)
System: Unknown, Version: 2.0, (0x80900120)
Clocks: CPU:1000 MHz, MPX: 400 MHz, DDR: 200 MHz, LBC: 25 MHz
L2: Enabled
Board: MPC8641HPCN, System ID: 0x10, System Version: 0x10, FPGA Version:
0x22
I2C: ready
DRAM: DDR: 1 GB
FLASH: 8 MB
Invalid ID (ff ff ff ff)
Scanning PCI bus 01
PCI-EXPRESS 1 on bus 00 - 02
PCI-EXPRESS 2 on bus 03 - 03
Video: No radeon video card found!
In: serial
Out: serial
Err: serial
SCSI: AHCI 0001.0000 32 slots 4 ports 3 Gbps 0xf impl IDE mode
flags: ncq ilck pm led clo pmp pio slum part
scanning bus for devices...
Net: eTSEC1, eTSEC2, eTSEC3, eTSEC4
=> tftp 4000000 hpcn/uImage-torvalds-linux-2.6
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.30
Filename 'hpcn/uImage-torvalds-linux-2.6'.
Load address: 0x4000000
Loading: #################################################################
#################################################################
#######################################################
done
Bytes transferred = 2709050 (29563a hex)
=> tftp 5000000 hpcn/mpc8641_hpcn-torvalds-linux-2.6.dtb
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.30
Filename 'hpcn/mpc8641_hpcn-torvalds-linux-2.6.dtb'.
Load address: 0x5000000
Loading: #
done
Bytes transferred = 11523 (2d03 hex)
=> setenv bootargs "root=/dev/nfs rw
nfsroot=192.168.0.1:/tftpboot/hpcn/root/ i"
=> bootm 4000000 - 5000000
WARNING: adjusting available memory to 10000000
## Booting kernel from Legacy Image at 04000000 ...
Image Name: Linux-2.6.33-00001-gbaac35c
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 2708986 Bytes = 2.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 05000000
Booting using the fdt blob at 0x5000000
Uncompressing Kernel Image ... OK
Loading Device Tree to 007fa000, end 007ffd02 ... OK
Using MPC86xx HPCN machine description
Total memory = 1024MB; using 2048kB for hash table (at cfe00000)
Linux version 2.6.33-00001-gbaac35c (welchma@ES-J7S4D2J) (gcc version
4.1.2) #20
CPU maps initialized for 1 thread per core
bootconsole [udbg0] enabled
setup_arch: bootmem
mpc86xx_hpcn_setup_arch()
Found FSL PCI host bridge at 0x00000000ffe08000. Firmware bus number: 0->2
PCI host bridge /pcie@ffe08000 (primary) ranges:
MEM 0x0000000080000000..0x000000009fffffff -> 0x0000000080000000
IO 0x00000000ffc00000..0x00000000ffc0ffff -> 0x0000000000000000
/pcie@ffe08000: PCICSRBAR @ 0xfff00000
Found FSL PCI host bridge at 0x00000000ffe09000. Firmware bus number: 0->0
PCI host bridge /pcie@ffe09000 ranges:
MEM 0x00000000a0000000..0x00000000bfffffff -> 0x00000000a0000000
IO 0x00000000ffc10000..0x00000000ffc1ffff -> 0x0000000000000000
/pcie@ffe09000: PCICSRBAR @ 0xfff00000
MPC86xx HPCN board from Freescale Semiconductor
arch: exit
Zone PFN ranges:
DMA 0x00000000 -> 0x00030000
Normal 0x00030000 -> 0x00030000
HighMem 0x00030000 -> 0x00040000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00040000
PERCPU: Embedded 7 pages/cpu @c1003000 s7712 r8192 d12768 u65536
pcpu-alloc: s7712 r8192 d12768 u65536 alloc=16*4096
pcpu-alloc: [0] 0 [0] 1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096
Kernel command line: root=/dev/nfs rw
nfsroot=192.168.0.1:/tftpboot/hpcn/root/ p
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1030864k/1048576k available (5228k kernel code, 17004k reserved,
196k d)
Kernel virtual memory layout:
* 0xfffc1000..0xfffff000 : fixmap
* 0xff800000..0xffc00000 : highmem PTEs
* 0xff7da000..0xff800000 : early ioremap
* 0xf1000000..0xff7da000 : vmalloc & ioremap
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:512 nr_irqs:512
mpic: Setting up MPIC " MPIC " version 1.2 at ffe40000, max 2 CPUs
mpic: ISU size: 256, shift: 8, mask: ff
mpic: Initializing for 256 sources
i8259 legacy interrupt controller initialized
clocksource: timebase mult[2800000] shift[22] registered
Console: colour dummy device 80x25
Mount-cache hash table entries: 512
mpic: requesting IPIs ...
Processor 1 found.
Brought up 2 CPUs
NET: Registered protocol family 16
PCI: Probing PCI hardware
pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:02:1d.0: unsupported PM cap regs version (4)
pci 0000:01:00.0: PCI bridge to [bus 02-ff] (subtractive decode)
pci 0001:03:00.0: ignoring class b20 (doesn't match header type 01)
pci 0001:03:00.0: PCI bridge to [bus 04-ff]
pci 0000:01:00.0: PCI bridge to [bus 02-02]
pci 0000:01:00.0: bridge window [io 0x1000-0x1fff]
pci 0000:01:00.0: bridge window [mem 0x80000000-0x800fffff]
pci 0000:01:00.0: bridge window [mem pref disabled]
pci 0000:00:00.0: PCI bridge to [bus 01-02]
pci 0000:00:00.0: bridge window [io 0x0000-0xffff]
pci 0000:00:00.0: bridge window [mem 0x80000000-0x9fffffff]
pci 0000:00:00.0: bridge window [mem pref disabled]
pci 0000:00:00.0: enabling device (0106 -> 0107)
pci 0001:03:00.0: PCI bridge to [bus 04-04]
pci 0001:03:00.0: bridge window [io 0xfffee000-0xffffdfff]
pci 0001:03:00.0: bridge window [mem 0xa0000000-0xbfffffff]
pci 0001:03:00.0: bridge window [mem pref disabled]
pci 0001:03:00.0: enabling device (0106 -> 0107)
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Advanced Linux Sound Architecture Driver Version 1.0.21.
Switching to clocksource timebase
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: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
audit: initializing netlink socket (disabled)
type=2000 audit(0.144:1): initialized
highmem bounce pool size: 64 pages
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver 2.1.29 [Flags: R/O].
msgmni has been set to 1502
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Generic non-volatile memory driver v1.1
Serial: 8250/16550 driver, 2 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xffe04500 (irq = 42) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
serial8250.0: ttyS1 at MMIO 0xffe04600 (irq = 28) is a 16550A
brd: module loaded
loop: module loaded
nbd: registered device at major 43
st: Version 20081215, fixed bufsize 32768, s/g segs 256
ahci 0000:02:1f.1: AHCI 0001.0000 32 slots 4 ports 3 Gbps 0xf impl SATA mode
ahci 0000:02:1f.1: flags: ncq sntf ilck pm led clo pmp pio slum part
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci
scsi3 : ahci
ata1: SATA max UDMA/133 abar m1024@0x80006000 port 0x80006100 irq 5
ata2: SATA max UDMA/133 abar m1024@0x80006000 port 0x80006180 irq 5
ata3: SATA max UDMA/133 abar m1024@0x80006000 port 0x80006200 irq 5
ata4: SATA max UDMA/133 abar m1024@0x80006000 port 0x80006280 irq 5
scsi4 : pata_ali
scsi5 : pata_ali
ata5: PATA max UDMA/133 cmd 0x1200 ctl 0x1208 bmdma 0x1220 irq 14
ata6: PATA max UDMA/133 cmd 0x1210 ctl 0x1218 bmdma 0x1228 irq 14
eth0: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:00:01
eth0: Running with NAPI enabled
eth0: :RX BD ring size for Q[0]: 256
eth0:TX BD ring size for Q[0]: 256
eth1: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:01:fd
eth1: Running with NAPI enabled
eth1: :RX BD ring size for Q[0]: 256
eth1:TX BD ring size for Q[0]: 256
eth2: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:02:fd
eth2: Running with NAPI enabled
eth2: :RX BD ring size for Q[0]: 256
eth2:TX BD ring size for Q[0]: 256
eth3: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:03:fd
eth3: Running with NAPI enabled
eth3: :RX BD ring size for Q[0]: 256
eth3:TX BD ring size for Q[0]: 256
Freescale PowerQUICC MII Bus: probed
Freescale PowerQUICC MII Bus: probed
Freescale PowerQUICC MII Bus: probed
Freescale PowerQUICC MII Bus: probed
usbmon: debugfs is not available
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_hcd 0000:02:1c.3: EHCI Host Controller
ehci_hcd 0000:02:1c.3: new USB bus registered, assigned bus number 1
ehci_hcd 0000:02:1c.3: debug port 1
ehci_hcd 0000:02:1c.3: Enabling legacy PCI PM
ehci_hcd 0000:02:1c.3: irq 11, io mem 0x80003000
ehci_hcd 0000:02:1c.3: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:02:1c.0: OHCI Host Controller
ata5.00: ATAPI: SONY DVD RW AW-Q170A, 1.73, max UDMA/66
ata5.00: WARNING: ATAPI DMA disabled for reliability issues. It can be
enabled
ata5.00: WARNING: via pata_ali.atapi_dma modparam or corresponding sysfs
node.
ata5.00: configured for UDMA/66
ohci_hcd 0000:02:1c.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:02:1c.0: irq 12, io mem 0x80000000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
ohci_hcd 0000:02:1c.1: OHCI Host Controller
ohci_hcd 0000:02:1c.1: new USB bus registered, assigned bus number 3
ohci_hcd 0000:02:1c.1: irq 9, io mem 0x80001000
ata3: SATA link down (SStatus 0 SControl 300)
ata1: SATA link down (SStatus 0 SControl 300)
ata4: SATA link down (SStatus 0 SControl 300)
ata2: SATA link down (SStatus 0 SControl 300)
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 3 ports detected
ohci_hcd 0000:02:1c.2: OHCI Host Controller
ohci_hcd 0000:02:1c.2: new USB bus registered, assigned bus number 4
scsi 4:0:0:0: CD-ROM SONY DVD RW AW-Q170A 1.73 PQ: 0 ANSI: 5
ohci_hcd 0000:02:1c.2: irq 10, io mem 0x80002000
sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 4:0:0:0: Attached scsi generic sg0 type 5
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 3 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
i8042.c: No controller found.
rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one day, 114 bytes nvram
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
intel8x0_measure_ac97_clock: measured 50231 usecs (2424 samples)
intel8x0: clocking to 48000
ALSA device list:
#0: ALi M5455 with ALC650F at irq 6
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
rtc_cmos rtc_cmos: setting system clock to 2002-03-11 18:46:05 UTC
(1015872365)
ADDRCONF(NETDEV_UP): eth0: link is not ready
ADDRCONF(NETDEV_UP): eth1: link is not ready
ADDRCONF(NETDEV_UP): eth2: link is not ready
ADDRCONF(NETDEV_UP): eth3: link is not ready
Sending DHCP requests .
PHY: mdio@ffe24520:00 - Link is Up - 1000/Full
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
., OK
IP-Config: Got DHCP answer from 192.168.0.1, my address is 192.168.0.241
IP-Config: Complete:
device=eth0, addr=192.168.0.241, mask=255.255.255.0, gw=192.168.0.1,
host=192.168.0.241, domain=Radstone.Local, nis-domain=(none),
bootserver=192.168.0.1, rootserver=192.168.0.1, rootpath=
Looking up port of RPC 100003/2 on 192.168.0.1
Looking up port of RPC 100005/1 on 192.168.0.1
VFS: Mounted root (nfs filesystem) on device 0:13.
Freeing unused kernel memory: 220k init
nfs: server 192.168.0.1 not responding, still trying
nfs: server 192.168.0.1 not responding, still trying
nfs: server 192.168.0.1 not responding, still trying
nfs: server 192.168.0.1 not responding, still trying
nfs: server 192.168.0.1 not responding, still trying
nfs: server 192.168.0.1 not responding, still trying
nfs: server 192.168.0.1 not responding, still trying
nfs: server 192.168.0.1 not responding, still trying
nfs: server 192.168.0.1 not responding, still trying
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
^ permalink raw reply
* Re: TBI interface
From: Lamb, Jason (DS-1) @ 2010-02-25 12:27 UTC (permalink / raw)
To: Hillery, Nathan; +Cc: linuxppc-dev
In-Reply-To: <DA601BED1671C24093F284F75082C99340B6CE@rtpwbee01.SIXIS.NS>
[-- Attachment #1: Type: text/plain, Size: 3461 bytes --]
Did you check your power on reset resistor values to make sure the
correct phy management interface is selected?
On Feb 25, 2010, at 1:21 AM, "Hillery, Nathan" <nhillery@sixisinc.com>
wrote:
> I have a system with an SGMII interface on an MPC8536E, attached to
> a Marvel 88E6152 Ethernet switch chip. I can access Ethernet from u-
> boot, if I initially configure the MII “phy” and the switch port
> PHY to disable auto-negotiation and assert link up. The link speed
> is 10Mbps and it is half-duplex. When u-boot starts, reports that i
> t didn’t recognize a PHY 0xFFFF id, and says it will assume a generi
> c phy.
>
>
>
> Obviously, I’d like to run without having to manually configure and
> have it run at 1gbps, full-duplex.
>
>
>
> However, I am not able to get linux to recognize the device – it rep
> orts that a ten-bit interface (TBI) is required for SGMII and it can
> ’t find one. I have a tbi-phy entry in the device-tree file.
> Here’s the relevant snippet:
>
>
>
> mdio@24520 {
>
> #address-cells = <1>;
>
> #size-cells = <0>;
>
> compatible = "fsl,gianfar-tbi";
>
> reg = <0x24520 0x20>;
>
>
>
> phy0: ethernet-phy@0x10 {
>
> interrupt-parent = <&mpic>;
>
> interrupts = <10 0x1>;
>
> reg = <0x10>;
>
> device_type = "ethernet-phy";
>
> };
>
>
>
> tbi0: tbi-phy@4 {
>
> reg = <0x4>;
>
> device_type = "tbi-phy";
>
> };
>
> };
>
> enet0: ethernet@24000 {
>
> cell-index = <0>;
>
> device_type =
> "network";
>
> model = "eTSEC";
>
> compatible =
> "gianfar";
>
> reg = <0x24000
> 0x1000>;
>
> local-mac-address =
> [ 00 00 00 00 00 00 ];
>
> interrupts = <29 2 30 2 34 2
> >;
>
> interrupt-parent =
> <&mpic>;
>
> tbi-handle = <&tbi0>;
>
> phy-handle = <&phy0>;
>
> phy-connection-type
> = "sgmii";
>
> fsl,magic-packet;
>
> fsl,wake-on-filer;
>
> };
>
>
>
> The processor has an MDIO interface to the switch. The switch port
> PHYs are 0x10, 0x11, 0x12, 0x13, 0x17, and 0x19. I picked 4 for the
> TBI arbitrarily (but seeking to avoid conflicting a PHY address).
>
>
>
> Any hints will be appreciated.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 10456 bytes --]
^ permalink raw reply
* Re: PCI on 834x
From: Gary Thomas @ 2010-02-25 14:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, avorontsov
In-Reply-To: <4B85B182.2030508@mlbassoc.com>
On 02/24/2010 04:08 PM, Gary Thomas wrote:
> On 02/24/2010 03:25 PM, Kumar Gala wrote:
>>
>> On Feb 24, 2010, at 4:14 PM, Gary Thomas wrote:
>>
>>> On 02/24/2010 01:51 PM, Anton Vorontsov wrote:
>>>> On Wed, Feb 24, 2010 at 02:26:20PM -0600, Scott Wood wrote:
>>>>> Gary Thomas wrote:
>>>>>> Yes, I'm using the exact same kernel with these two different PCI
>>>>>> setups (done by the boot loader).
>>>>>>
>>>>>> Restricting the memory via mem=128M has no effect - the PCI layout
>>>>>> is the same.
>>>>>>
>>>>>> I think the outbound window size is required because of how the Linux PCI
>>>>>> remaps the space (note in my dumps that it put the MMIO of the
>>>>>> boards starting
>>>>>> at 0xD0000000 when the inbound window is 0x10000000)
>>>>>
>>>>> I see where the amount of RAM is mattering -- Linux is assigning
>>>>> outbound I/O space to the PCI controller itself (device 00:00.0) and
>>>>> the amount that it asks for seems to differ based on memory size.
>>>>> Linux ought to skip that device when assigning resources. Some
>>>>> platforms do this (search for pci_exclude_device), but it seems to
>>>>> be missing on 83xx.
>>>>
>>>> Actually, 83xx had these exclude_device hooks, but they were removed:
>>>>
>>>> commit d8f1324a5063c833862328ceafabc53ac3cc4f71
>>>> Author: Kumar Gala<galak@kernel.crashing.org>
>>>> Date: Wed Sep 12 22:14:10 2007 -0500
>>>>
>>>> [POWERPC] 83xx: Removed PCI exclude of PHB
>>>>
>>>> Now that the generic code doesn't assign resources for Freescale
>>>> PHBs we dont have to explicitly exclude it.
>>>>
>>>> Signed-off-by: Kumar Gala<galak@kernel.crashing.org>
>>>>
>>>>
>>>> May be the generic code started to assign the resources again?
>>>>
>>>
>>> That cracked it; I re-enabled the exclusion of the bridge and now
>>> it's all working fine.
>>>
>>> Thanks for the help
>>>
>>> Note: I'm working with a fairly old kernel, so these results would
>>> have to be reworked against the latest.
>>
>> Odd that the generic code isn't dealing with that for you.
>
> Remember it's an old kernel (2.6.28), so who knows the status.
> As I said, I'll revisit this when I move to a newer kernel.
>
I may have been too hasty pronouncing this fixed. Indeed, the
SATA interface now works, but my video card (Fujitsu Coral-P)
does not work when it's mapped at the bottom of the PCI space :-(
With the bridge mapped, the video ends up at a non-zero address
(0xC8000000..0xCFFFFFFF). If it gets mapped to 0xC0000000, it
fails to respond to MMIO accesses.
Any ideas how I might get around this? Is there a way to force
the PCI allocator to start somewhere other than [relative] zero?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* RE: [PATCH 1/7] RapidIO: Add IDT CPS/TSI switches
From: Bounine, Alexandre @ 2010-02-25 14:18 UTC (permalink / raw)
To: Micha Nelissen, Alexandre Bounine
Cc: linux-kernel, thomas.moll, linuxppc-dev, alexandreb,
thomas.moll.ext
In-Reply-To: <4B8585DE.50701@neli.hopto.org>
Micha Nelissen wrote:
> Alexandre Bounine wrote:
> > @@ -369,6 +380,10 @@ static struct rio_dev __devinit *rio_set
> > rdev->rswitch->switchid);
> > rio_route_set_ops(rdev);
> >
> > + if (do_enum && rdev->rswitch->clr_table)
> > + rdev->rswitch->clr_table(port, destid, hopcount,
> > + RIO_GLOBAL_TABLE);
> > +
> > list_add_tail(&rswitch->node, &rio_switches);
> >
> > } else
>=20
> Why clear the tables here, why not in rio_enum_peer?
I prefer to keep it together with route table image initialization.=20
>=20
> > +DECLARE_RIO_ROUTE_OPS(RIO_VID_TUNDRA, RIO_DID_TSI572,
tsi57x_route_add_entry,
> tsi57x_route_get_entry, tsi57x_route_clr_table);
> > +DECLARE_RIO_ROUTE_OPS(RIO_VID_TUNDRA, RIO_DID_TSI574,
tsi57x_route_add_entry,
> tsi57x_route_get_entry, tsi57x_route_clr_table);
> > +DECLARE_RIO_ROUTE_OPS(RIO_VID_TUNDRA, RIO_DID_TSI577,
tsi57x_route_add_entry,
> tsi57x_route_get_entry, tsi57x_route_clr_table);
> > +DECLARE_RIO_ROUTE_OPS(RIO_VID_TUNDRA, RIO_DID_TSI578,
tsi57x_route_add_entry,
> tsi57x_route_get_entry, tsi57x_route_clr_table);
>=20
> Can the 568 and 578 driver be shared? Have a 5xx driver?
For route table operations this will work. But there are Error
Management functions added in follow-up patches, which are different for
Tsi568. I prefer to keep them in different files to avoid hiding the
differences. Plus, it makes easier for end-user to remove from the build
drivers for switches that are not used in their system. I do not want to
add new configuration options for switch selection at this moment but we
may consider it later.=20
Alex.
=20
^ permalink raw reply
* RE: [PATCH 2/7] RapidIO: Add switch locking during discovery
From: Bounine, Alexandre @ 2010-02-25 14:53 UTC (permalink / raw)
To: Micha Nelissen
Cc: Alexandre Bounine, linux-kernel, thomas.moll, linuxppc-dev,
thomas.moll.ext
In-Reply-To: <4B857A53.30106@neli.hopto.org>
Micha Nelissen wrote:
>=20
> Alexandre Bounine wrote:
> > + /* Attempt to acquire device lock */
> > + rio_mport_write_config_32(port, destid,
> > + hopcount,
> > +
RIO_HOST_DID_LOCK_CSR,
> > +
port->host_deviceid);
> > + rio_mport_read_config_32(port, destid,
hopcount,
> > + RIO_HOST_DID_LOCK_CSR, &result);
> > + while (result !=3D port->host_deviceid) {
>=20
> It's better to abstract the locking of a device into a new function,
> rio_lock_device / rio_unlock_device.
>=20
> Then you can use those in rio_get_route_entry and rio_add_route_entry.
Agree. Plus, adding a "lock" parameter to
rio_get_route_entry/rio_add_route_entry to avoid excessive locking
requests when scanning entire table. I will do it in next version or as
additional patch: I have to address locking anyway for future changes.
=20
>=20
> > @@ -1027,6 +1090,13 @@ int __devinit rio_disc_mport(struct rio_
> > +
> > + /* Read DestID assigned by enumerator */
> > + rio_local_read_config_32(mport, RIO_DID_CSR,
> > + &mport->host_deviceid);
> > + mport->host_deviceid =3D RIO_GET_DID(mport->sys_size,
> > +
mport->host_deviceid);
> > +
>=20
> This fixes something else, should be a separate patch.
This sets an ID used for locking during discovery. On a startup only
enumerator's ID is set to the specified value. All discovering agents
have this ID set to -1. After enumeration is completed it is safe to
initialize host_deviceid for agents as well.
Alex.
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Martyn Welch @ 2010-02-25 16:46 UTC (permalink / raw)
To: linuxppc-dev list, netdev, linux-kernel
Cc: Anton Vorontsov, Sandeep Gopalpet, davem
In-Reply-To: <4B865176.7080806@ge.com>
Martyn Welch wrote:
> Martyn Welch wrote:
>
>> I have recently attempted to boot an 8641D based board from an NFS root.
>> The boot process grinds to a halt not long after the first access of the
>> NFS root and I receive multiple "nfs: server 192.168.0.1 not responding,
>> still trying" messages. Wireshark suggests that there is no further
>> traffic from this board at this point on. The NFS server seems to
>> eventually try sending duplicate packets it's already sent, which
>> results in "nfs: server 192.168.0.1 OK" messages, but the "not
>> responding" messages resume with no further traffic from the board.
>>
>> I am able to boot to a ramdisk fine and the network seems to work -
>> though I haven't really pushed the interface from it.
>>
>> I have attempted to git bisect, though I wasn't able to get much further
>> than discovering the problem was introduced in the 2.6.33 merge window -
>> at which point the gianfar network driver fails to compile (I have tried
>> to git bisect skip many, many times to no avail).
>>
>> NFS booting fails for this board on todays linux-next, the master branch
>> of Kumar's PPC tree and the head of the main tree. I have also been able
>> to NFS boot from a random x86 based board that I have, using the head of
>> the main tree and the linux-next tree.
>>
>> Copying the gianfar drivers from 2.6.32 into the head of the main tree
>> restores the correct behaviour and I'm able to NFS boot. I have heard
>> from others that the latest drivers work on 83xx and 85xx based boards,
>> but it seems to be broken on at least the 8641D.
>>
>> I can see there has been a fair amount of work done on the gianfar
>> driver, I assume that this is a bug introduced by the multiple queue
>> support, but I'm way out of my depth on this.
>>
>>
> I have just compiled 2.6.33 for the Freescale MPC8641_HPCN demo board
> and am having still experiencing the problems outlined in my previous
> email, though I have noticed that I tend to be able to boot from cold,
> but my boot fails on reboot. Hitting the reset button doesn't help, I
> need to actually power the machine on and off again for it to work.
>
> As before, I'm way out of my depth in this, any one have any ideas?
> Below is a dump of the failed boot process:
>
> U-Boot 2009.01-00181-gc1b7c70 (Jan 30 2009 - 11:17:31)
>
> Freescale PowerPC
> CPU:
> Core: E600 Core 0, Version: 0.2, (0x80040202)
> System: Unknown, Version: 2.0, (0x80900120)
> Clocks: CPU:1000 MHz, MPX: 400 MHz, DDR: 200 MHz, LBC: 25 MHz
> L2: Enabled
> Board: MPC8641HPCN, System ID: 0x10, System Version: 0x10, FPGA Version:
> 0x22
> I2C: ready
> DRAM: DDR: 1 GB
> FLASH: 8 MB
> Invalid ID (ff ff ff ff)
> Scanning PCI bus 01
> PCI-EXPRESS 1 on bus 00 - 02
> PCI-EXPRESS 2 on bus 03 - 03
> Video: No radeon video card found!
> In: serial
> Out: serial
> Err: serial
> SCSI: AHCI 0001.0000 32 slots 4 ports 3 Gbps 0xf impl IDE mode
> flags: ncq ilck pm led clo pmp pio slum part
> scanning bus for devices...
> Net: eTSEC1, eTSEC2, eTSEC3, eTSEC4
> => tftp 4000000 hpcn/uImage-torvalds-linux-2.6
> Speed: 1000, full duplex
> Using eTSEC1 device
> TFTP from server 192.168.0.1; our IP address is 192.168.0.30
> Filename 'hpcn/uImage-torvalds-linux-2.6'.
> Load address: 0x4000000
> Loading: #################################################################
> #################################################################
> #######################################################
> done
> Bytes transferred = 2709050 (29563a hex)
> => tftp 5000000 hpcn/mpc8641_hpcn-torvalds-linux-2.6.dtb
> Speed: 1000, full duplex
> Using eTSEC1 device
> TFTP from server 192.168.0.1; our IP address is 192.168.0.30
> Filename 'hpcn/mpc8641_hpcn-torvalds-linux-2.6.dtb'.
> Load address: 0x5000000
> Loading: #
> done
> Bytes transferred = 11523 (2d03 hex)
> => setenv bootargs "root=/dev/nfs rw
> nfsroot=192.168.0.1:/tftpboot/hpcn/root/ i"
> => bootm 4000000 - 5000000
> WARNING: adjusting available memory to 10000000
> ## Booting kernel from Legacy Image at 04000000 ...
> Image Name: Linux-2.6.33-00001-gbaac35c
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 2708986 Bytes = 2.6 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 05000000
> Booting using the fdt blob at 0x5000000
> Uncompressing Kernel Image ... OK
> Loading Device Tree to 007fa000, end 007ffd02 ... OK
> Using MPC86xx HPCN machine description
> Total memory = 1024MB; using 2048kB for hash table (at cfe00000)
> Linux version 2.6.33-00001-gbaac35c (welchma@ES-J7S4D2J) (gcc version
> 4.1.2) #20
> CPU maps initialized for 1 thread per core
> bootconsole [udbg0] enabled
> setup_arch: bootmem
> mpc86xx_hpcn_setup_arch()
> Found FSL PCI host bridge at 0x00000000ffe08000. Firmware bus number: 0->2
> PCI host bridge /pcie@ffe08000 (primary) ranges:
> MEM 0x0000000080000000..0x000000009fffffff -> 0x0000000080000000
> IO 0x00000000ffc00000..0x00000000ffc0ffff -> 0x0000000000000000
> /pcie@ffe08000: PCICSRBAR @ 0xfff00000
> Found FSL PCI host bridge at 0x00000000ffe09000. Firmware bus number: 0->0
> PCI host bridge /pcie@ffe09000 ranges:
> MEM 0x00000000a0000000..0x00000000bfffffff -> 0x00000000a0000000
> IO 0x00000000ffc10000..0x00000000ffc1ffff -> 0x0000000000000000
> /pcie@ffe09000: PCICSRBAR @ 0xfff00000
> MPC86xx HPCN board from Freescale Semiconductor
> arch: exit
> Zone PFN ranges:
> DMA 0x00000000 -> 0x00030000
> Normal 0x00030000 -> 0x00030000
> HighMem 0x00030000 -> 0x00040000
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0x00000000 -> 0x00040000
> PERCPU: Embedded 7 pages/cpu @c1003000 s7712 r8192 d12768 u65536
> pcpu-alloc: s7712 r8192 d12768 u65536 alloc=16*4096
> pcpu-alloc: [0] 0 [0] 1
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096
> Kernel command line: root=/dev/nfs rw
> nfsroot=192.168.0.1:/tftpboot/hpcn/root/ p
> PID hash table entries: 4096 (order: 2, 16384 bytes)
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Memory: 1030864k/1048576k available (5228k kernel code, 17004k reserved,
> 196k d)
> Kernel virtual memory layout:
> * 0xfffc1000..0xfffff000 : fixmap
> * 0xff800000..0xffc00000 : highmem PTEs
> * 0xff7da000..0xff800000 : early ioremap
> * 0xf1000000..0xff7da000 : vmalloc & ioremap
> SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> Hierarchical RCU implementation.
> NR_IRQS:512 nr_irqs:512
> mpic: Setting up MPIC " MPIC " version 1.2 at ffe40000, max 2 CPUs
> mpic: ISU size: 256, shift: 8, mask: ff
> mpic: Initializing for 256 sources
> i8259 legacy interrupt controller initialized
> clocksource: timebase mult[2800000] shift[22] registered
> Console: colour dummy device 80x25
> Mount-cache hash table entries: 512
> mpic: requesting IPIs ...
> Processor 1 found.
> Brought up 2 CPUs
> NET: Registered protocol family 16
>
> PCI: Probing PCI hardware
> pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
> pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> pci 0000:02:1d.0: unsupported PM cap regs version (4)
> pci 0000:01:00.0: PCI bridge to [bus 02-ff] (subtractive decode)
> pci 0001:03:00.0: ignoring class b20 (doesn't match header type 01)
> pci 0001:03:00.0: PCI bridge to [bus 04-ff]
> pci 0000:01:00.0: PCI bridge to [bus 02-02]
> pci 0000:01:00.0: bridge window [io 0x1000-0x1fff]
> pci 0000:01:00.0: bridge window [mem 0x80000000-0x800fffff]
> pci 0000:01:00.0: bridge window [mem pref disabled]
> pci 0000:00:00.0: PCI bridge to [bus 01-02]
> pci 0000:00:00.0: bridge window [io 0x0000-0xffff]
> pci 0000:00:00.0: bridge window [mem 0x80000000-0x9fffffff]
> pci 0000:00:00.0: bridge window [mem pref disabled]
> pci 0000:00:00.0: enabling device (0106 -> 0107)
> pci 0001:03:00.0: PCI bridge to [bus 04-04]
> pci 0001:03:00.0: bridge window [io 0xfffee000-0xffffdfff]
> pci 0001:03:00.0: bridge window [mem 0xa0000000-0xbfffffff]
> pci 0001:03:00.0: bridge window [mem pref disabled]
> pci 0001:03:00.0: enabling device (0106 -> 0107)
> bio: create slab <bio-0> at 0
> vgaarb: loaded
> SCSI subsystem initialized
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Advanced Linux Sound Architecture Driver Version 1.0.21.
> Switching to clocksource timebase
> 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: 65536 (order: 7, 524288 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> TCP reno registered
> UDP hash table entries: 512 (order: 2, 16384 bytes)
> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
> NET: Registered protocol family 1
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> audit: initializing netlink socket (disabled)
> type=2000 audit(0.144:1): initialized
> highmem bounce pool size: 64 pages
> Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> NTFS driver 2.1.29 [Flags: R/O].
> msgmni has been set to 1502
> alg: No test for stdrng (krng)
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> Generic non-volatile memory driver v1.1
> Serial: 8250/16550 driver, 2 ports, IRQ sharing enabled
> serial8250.0: ttyS0 at MMIO 0xffe04500 (irq = 42) is a 16550A
> console [ttyS0] enabled, bootconsole disabled
> console [ttyS0] enabled, bootconsole disabled
> serial8250.0: ttyS1 at MMIO 0xffe04600 (irq = 28) is a 16550A
> brd: module loaded
> loop: module loaded
> nbd: registered device at major 43
> st: Version 20081215, fixed bufsize 32768, s/g segs 256
> ahci 0000:02:1f.1: AHCI 0001.0000 32 slots 4 ports 3 Gbps 0xf impl SATA mode
> ahci 0000:02:1f.1: flags: ncq sntf ilck pm led clo pmp pio slum part
> scsi0 : ahci
> scsi1 : ahci
> scsi2 : ahci
> scsi3 : ahci
> ata1: SATA max UDMA/133 abar m1024@0x80006000 port 0x80006100 irq 5
> ata2: SATA max UDMA/133 abar m1024@0x80006000 port 0x80006180 irq 5
> ata3: SATA max UDMA/133 abar m1024@0x80006000 port 0x80006200 irq 5
> ata4: SATA max UDMA/133 abar m1024@0x80006000 port 0x80006280 irq 5
> scsi4 : pata_ali
> scsi5 : pata_ali
> ata5: PATA max UDMA/133 cmd 0x1200 ctl 0x1208 bmdma 0x1220 irq 14
> ata6: PATA max UDMA/133 cmd 0x1210 ctl 0x1218 bmdma 0x1228 irq 14
> eth0: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:00:01
> eth0: Running with NAPI enabled
> eth0: :RX BD ring size for Q[0]: 256
> eth0:TX BD ring size for Q[0]: 256
> eth1: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:01:fd
> eth1: Running with NAPI enabled
> eth1: :RX BD ring size for Q[0]: 256
> eth1:TX BD ring size for Q[0]: 256
> eth2: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:02:fd
> eth2: Running with NAPI enabled
> eth2: :RX BD ring size for Q[0]: 256
> eth2:TX BD ring size for Q[0]: 256
> eth3: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:03:fd
> eth3: Running with NAPI enabled
> eth3: :RX BD ring size for Q[0]: 256
> eth3:TX BD ring size for Q[0]: 256
> Freescale PowerQUICC MII Bus: probed
> Freescale PowerQUICC MII Bus: probed
> Freescale PowerQUICC MII Bus: probed
> Freescale PowerQUICC MII Bus: probed
> usbmon: debugfs is not available
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci_hcd 0000:02:1c.3: EHCI Host Controller
> ehci_hcd 0000:02:1c.3: new USB bus registered, assigned bus number 1
> ehci_hcd 0000:02:1c.3: debug port 1
> ehci_hcd 0000:02:1c.3: Enabling legacy PCI PM
> ehci_hcd 0000:02:1c.3: irq 11, io mem 0x80003000
> ehci_hcd 0000:02:1c.3: USB 2.0 started, EHCI 1.00
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 8 ports detected
> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> ohci_hcd 0000:02:1c.0: OHCI Host Controller
> ata5.00: ATAPI: SONY DVD RW AW-Q170A, 1.73, max UDMA/66
> ata5.00: WARNING: ATAPI DMA disabled for reliability issues. It can be
> enabled
> ata5.00: WARNING: via pata_ali.atapi_dma modparam or corresponding sysfs
> node.
> ata5.00: configured for UDMA/66
> ohci_hcd 0000:02:1c.0: new USB bus registered, assigned bus number 2
> ohci_hcd 0000:02:1c.0: irq 12, io mem 0x80000000
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 3 ports detected
> ohci_hcd 0000:02:1c.1: OHCI Host Controller
> ohci_hcd 0000:02:1c.1: new USB bus registered, assigned bus number 3
> ohci_hcd 0000:02:1c.1: irq 9, io mem 0x80001000
> ata3: SATA link down (SStatus 0 SControl 300)
> ata1: SATA link down (SStatus 0 SControl 300)
> ata4: SATA link down (SStatus 0 SControl 300)
> ata2: SATA link down (SStatus 0 SControl 300)
> hub 3-0:1.0: USB hub found
> hub 3-0:1.0: 3 ports detected
> ohci_hcd 0000:02:1c.2: OHCI Host Controller
> ohci_hcd 0000:02:1c.2: new USB bus registered, assigned bus number 4
> scsi 4:0:0:0: CD-ROM SONY DVD RW AW-Q170A 1.73 PQ: 0 ANSI: 5
> ohci_hcd 0000:02:1c.2: irq 10, io mem 0x80002000
> sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray
> Uniform CD-ROM driver Revision: 3.20
> sr 4:0:0:0: Attached scsi generic sg0 type 5
> hub 4-0:1.0: USB hub found
> hub 4-0:1.0: 3 ports detected
> Initializing USB Mass Storage driver...
> usbcore: registered new interface driver usb-storage
> USB Mass Storage support registered.
> i8042.c: No controller found.
> rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
> rtc0: alarms up to one day, 114 bytes nvram
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> intel8x0_measure_ac97_clock: measured 50231 usecs (2424 samples)
> intel8x0: clocking to 48000
> ALSA device list:
> #0: ALi M5455 with ALC650F at irq 6
> IPv4 over IPv4 tunneling driver
> GRE over IPv4 tunneling driver
> TCP cubic registered
> Initializing XFRM netlink socket
> NET: Registered protocol family 10
> IPv6 over IPv4 tunneling driver
> NET: Registered protocol family 17
> rtc_cmos rtc_cmos: setting system clock to 2002-03-11 18:46:05 UTC
> (1015872365)
> ADDRCONF(NETDEV_UP): eth0: link is not ready
> ADDRCONF(NETDEV_UP): eth1: link is not ready
> ADDRCONF(NETDEV_UP): eth2: link is not ready
> ADDRCONF(NETDEV_UP): eth3: link is not ready
> Sending DHCP requests .
> PHY: mdio@ffe24520:00 - Link is Up - 1000/Full
> ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> ., OK
> IP-Config: Got DHCP answer from 192.168.0.1, my address is 192.168.0.241
> IP-Config: Complete:
> device=eth0, addr=192.168.0.241, mask=255.255.255.0, gw=192.168.0.1,
> host=192.168.0.241, domain=Radstone.Local, nis-domain=(none),
> bootserver=192.168.0.1, rootserver=192.168.0.1, rootpath=
> Looking up port of RPC 100003/2 on 192.168.0.1
> Looking up port of RPC 100005/1 on 192.168.0.1
> VFS: Mounted root (nfs filesystem) on device 0:13.
> Freeing unused kernel memory: 220k init
> nfs: server 192.168.0.1 not responding, still trying
> nfs: server 192.168.0.1 not responding, still trying
> nfs: server 192.168.0.1 not responding, still trying
> nfs: server 192.168.0.1 not responding, still trying
> nfs: server 192.168.0.1 not responding, still trying
> nfs: server 192.168.0.1 not responding, still trying
> nfs: server 192.168.0.1 not responding, still trying
> nfs: server 192.168.0.1 not responding, still trying
> nfs: server 192.168.0.1 not responding, still trying
>
Further testing has shown that this isn't restricted to warm reboots, it
happens from cold as well. In addition, the exact timing of the failure
seems to vary, some boots have got further before failing.
Martyn
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Anton Vorontsov @ 2010-02-25 16:51 UTC (permalink / raw)
To: Martyn Welch
Cc: netdev, linux-kernel, linuxppc-dev list, Sandeep Gopalpet, davem
In-Reply-To: <4B86A97E.6050509@ge.com>
On Thu, Feb 25, 2010 at 04:46:54PM +0000, Martyn Welch wrote:
[...]
> > nfs: server 192.168.0.1 not responding, still trying
> >
>
> Further testing has shown that this isn't restricted to warm reboots, it
> happens from cold as well. In addition, the exact timing of the failure
> seems to vary, some boots have got further before failing.
Unfortunately I don't have any 8641 boards near me, so I can't
debug this myself. Though, I tested gianfar on MPC8568E-MDS with
2.6.33 kernel, and it seems to work just fine.
I see you use SMP. Can you try to turn it off? If that will fix
the issue, then it'll be a good data point.
Meanwhile, I'll try SMP kernel on MPC8568 (UP), and let you
know the results.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Anton Vorontsov @ 2010-02-25 17:49 UTC (permalink / raw)
To: Martyn Welch
Cc: netdev, linux-kernel, linuxppc-dev list, Sandeep Gopalpet, davem
In-Reply-To: <20100225165141.GA9686@oksana.dev.rtsoft.ru>
On Thu, Feb 25, 2010 at 07:51:41PM +0300, Anton Vorontsov wrote:
> On Thu, Feb 25, 2010 at 04:46:54PM +0000, Martyn Welch wrote:
> [...]
> > > nfs: server 192.168.0.1 not responding, still trying
> > >
> >
> > Further testing has shown that this isn't restricted to warm reboots, it
> > happens from cold as well. In addition, the exact timing of the failure
> > seems to vary, some boots have got further before failing.
>
> Unfortunately I don't have any 8641 boards near me, so I can't
> debug this myself. Though, I tested gianfar on MPC8568E-MDS with
> 2.6.33 kernel, and it seems to work just fine.
>
> I see you use SMP. Can you try to turn it off? If that will fix
> the issue, then it'll be a good data point.
>
> Meanwhile, I'll try SMP kernel on MPC8568 (UP), and let you
> know the results.
Nope, no luck. Can't trigger the issue. :-/
Tested with NFS boot, TCP and UDP netperf tests.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [git pull] OF device tree rework for 2.6.34
From: Grant Likely @ 2010-02-25 17:51 UTC (permalink / raw)
To: Linus Torvalds, Linux Kernel Mailing List, linuxppc-dev,
devicetree-discuss, microblaze-uclinux, sparclinux,
Benjamin Herrenschmidt, Michal Simek, David Miller
Hi Linus,
Here is a bunch of device tree rework. This has also been simmering
in linux-next for a while now. Most of this is merging PowerPC &
Microblaze code with a sprinkling of SPARC changes, although there is
a small bit of minor rework throughout the drivers tree, all pretty
much powerpc specific stuff.
Cheers,
g.
The following changes since commit 60b341b778cc2929df16c0a504c91621b3c6a4ad:
Linus Torvalds (1):
Linux 2.6.33
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 next-devicetree
David Gibson (1):
of/flattree: Make the kernel accept ePAPR style phandle information
Grant Likely (30):
Merge commit 'v2.6.32-rc8'
of/flattree: merge find_flat_dt_string and initial_boot_params
of/flattree: merge of_scan_flat_dt
of/flattree: merge of_get_flat_dt_root
of/flattree: remove __init annotations from the header file
of/flattree: merge of_get_flat_dt_prop
of/flattree: Merge of_flat_dt_is_compatible
of/flattree: Merge unflatten_dt_node
of/flattree: Merge unflatten_device_tree
of: merge prom_{add,remove,modify}_property
of: remove special case definition of of_read_ulong()
of/flattree: Merge early_init_dt_check_for_initrd()
of/flattree: Merge earlyinit_dt_scan_root()
of/flattree: merge dt_mem_next_cell
of/flattree: eliminate cell_t typedef
of/flattree: merge early_init_dt_scan_chosen()
of: merge machine_is_compatible()
of: Merge of_node_get() and of_node_put()
of: unify phandle name in struct device_node
Merge commit 'v2.6.33-rc5' into secretlab/test-devicetree
microblaze: remove early_init_dt_scan_cpus() and phyp_dump_*()
of: merge of_attach_node() & of_detach_node()
of: add 'of_' prefix to machine_is_compatible()
of/flattree: merge early_init_dt_scan_memory() common code
of: Remove old and misplaced function declarations
of: put default string compare and #a/s-cell values into common header
of: remove unused extern reference to devtree_lock
of: move definition of of_chosen into common code.
of/sparc: Remove sparc-local declaration of allnodes and devtree_lock
of: remove undefined request_OF_resource & release_OF_resource
Jeremy Kerr (12):
of: merge of_find_node_by_phandle
of: include linux/proc_fs.h
of: make set_node_proc_entry private to proc_devtree.c
proc_devtree: include linux/of.h
of/flattree: use callback to setup initrd from /chosen
of/flattree: use OF_ROOT_NODE_{SIZE,ADDR}_CELLS DEFAULT for fdt parsing
of: use __be32 for cell value accessors
of: assume big-endian properties, adding conversions where necessary
of/flattree: endian-convert members of boot_param_header
proc_devtree: fix THIS_MODULE without module.h
of: protect linux/of.h with CONFIG_OF
of/flattree: Don't assume HAVE_LMB
arch/microblaze/Kconfig | 1 +
arch/microblaze/include/asm/prom.h | 20 -
arch/microblaze/kernel/of_platform.c | 2 +-
arch/microblaze/kernel/prom.c | 990 +------------------------
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/prom.h | 18 -
arch/powerpc/kernel/of_platform.c | 2 +-
arch/powerpc/kernel/pci_64.c | 2 +-
arch/powerpc/kernel/prom.c | 887 ++---------------------
arch/powerpc/platforms/85xx/xes_mpc85xx.c | 4 +-
arch/powerpc/platforms/cell/cbe_powerbutton.c | 2 +-
arch/powerpc/platforms/cell/ras.c | 2 +-
arch/powerpc/platforms/cell/spu_manage.c | 6 +-
arch/powerpc/platforms/pasemi/cpufreq.c | 4 +-
arch/powerpc/platforms/powermac/cpufreq_32.c | 14 +-
arch/powerpc/platforms/powermac/cpufreq_64.c | 14 +-
arch/powerpc/platforms/powermac/feature.c | 2 +-
arch/powerpc/platforms/powermac/pfunc_core.c | 2 +-
arch/powerpc/platforms/powermac/smp.c | 12 +-
arch/powerpc/platforms/powermac/time.c | 8 +-
arch/powerpc/platforms/powermac/udbg_scc.c | 6 +-
arch/powerpc/sysdev/grackle.c | 4 +-
arch/sparc/kernel/devices.c | 2 +-
arch/sparc/kernel/of_device_32.c | 2 +-
arch/sparc/kernel/of_device_64.c | 2 +-
arch/sparc/kernel/prom.h | 3 -
arch/sparc/kernel/prom_common.c | 18 +-
arch/sparc/kernel/smp_64.c | 2 +-
drivers/char/hvc_beat.c | 2 +-
drivers/gpu/drm/radeon/radeon_combios.c | 44 +-
drivers/macintosh/adb.c | 4 +-
drivers/macintosh/therm_pm72.c | 8 +-
drivers/macintosh/therm_windtunnel.c | 2 +-
drivers/macintosh/via-pmu-backlight.c | 8 +-
drivers/macintosh/via-pmu.c | 8 +-
drivers/macintosh/windfarm_core.c | 6 +-
drivers/macintosh/windfarm_cpufreq_clamp.c | 6 +-
drivers/macintosh/windfarm_lm75_sensor.c | 6 +-
drivers/macintosh/windfarm_max6690_sensor.c | 6 +-
drivers/macintosh/windfarm_pm112.c | 2 +-
drivers/macintosh/windfarm_pm121.c | 2 +-
drivers/macintosh/windfarm_pm81.c | 4 +-
drivers/macintosh/windfarm_pm91.c | 2 +-
drivers/macintosh/windfarm_smu_sensors.c | 6 +-
drivers/net/mace.c | 2 +-
drivers/of/Kconfig | 8 +
drivers/of/Makefile | 1 +
drivers/of/base.c | 318 ++++++++-
drivers/of/fdt.c | 590 +++++++++++++++
drivers/of/gpio.c | 13 +-
drivers/of/of_i2c.c | 4 +-
drivers/of/of_mdio.c | 8 +-
drivers/of/of_spi.c | 6 +-
drivers/sbus/char/openprom.c | 10 +-
drivers/serial/pmac_zilog.c | 6 +-
drivers/video/aty/aty128fb.c | 14 +-
drivers/video/aty/atyfb_base.c | 10 +-
drivers/video/aty/radeon_backlight.c | 6 +-
fs/proc/proc_devtree.c | 7 +-
include/linux/of.h | 62 ++-
include/linux/of_fdt.h | 75 ++-
sound/aoa/fabrics/layout.c | 2 +-
sound/ppc/awacs.c | 24 +-
sound/ppc/burgundy.c | 4 +-
sound/ppc/pmac.c | 18 +-
sound/soc/fsl/efika-audio-fabric.c | 2 +-
sound/soc/fsl/pcm030-audio-fabric.c | 2 +-
67 files changed, 1244 insertions(+), 2096 deletions(-)
create mode 100644 drivers/of/fdt.c
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Kumar Gala @ 2010-02-25 18:27 UTC (permalink / raw)
To: Martyn Welch
Cc: netdev, linux-kernel, linuxppc-dev list, Sandeep Gopalpet,
Anton Vorontsov, davem
In-Reply-To: <4B86A97E.6050509@ge.com>
On Feb 25, 2010, at 10:46 AM, Martyn Welch wrote:
>
> Further testing has shown that this isn't restricted to warm reboots, it
> happens from cold as well. In addition, the exact timing of the failure
> seems to vary, some boots have got further before failing.
what mechanism do you use for warm resets?
- k
^ permalink raw reply
* [PATCH] powerpc: fix handling of strnlen with zero len
From: Jeff Mahoney @ 2010-02-25 18:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Steven Rostedt, Christian_Sellars
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Commit 0119536c, which added the assembly version of strncmp to
powerpc, mentions that it adds two instructions to the version from
boot/string.S to allow it to handle len=0. Unfortunately, it doesn't
always return 0 when that is the case. The length is passed in r5, but
the return value is passed back in r3. In certain cases, this will
happen to work. Otherwise it will pass back the address of the first
string as the return value.
This patch lifts the len <= 0 handling code from memcpy to handle that case.
Reported by: Christian_Sellars@symantec.com
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
- ---
arch/powerpc/lib/string.S | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
- --- a/arch/powerpc/lib/string.S
+++ b/arch/powerpc/lib/string.S
@@ -71,7 +71,7 @@ _GLOBAL(strcmp)
_GLOBAL(strncmp)
PPC_LCMPI r5,0
- - beqlr
+ ble- 2f
mtctr r5
addi r5,r3,-1
addi r4,r4,-1
@@ -82,6 +82,8 @@ _GLOBAL(strncmp)
beqlr 1
bdnzt eq,1b
blr
+2: li r3,0
+ blr
_GLOBAL(strlen)
addi r4,r3,-1
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAkuGxkoACgkQLPWxlyuTD7LzfQCeKAaKtyEfbabuGzZyAEEnb8Mq
KEsAn1tKZtVSQ2A68TjwU/JN2LC3Mop7
=/CaR
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 2/7] RapidIO: Add switch locking during discovery
From: Micha Nelissen @ 2010-02-25 19:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E552A54EA1@CORPEXCH1.na.ads.idt.com>
Bounine, Alexandre wrote:
> Micha Nelissen wrote:
>> Alexandre Bounine wrote:
>>> + mport->host_deviceid = RIO_GET_DID(mport->sys_size,
>> This fixes something else, should be a separate patch.
>
> This sets an ID used for locking during discovery. On a startup only
> enumerator's ID is set to the specified value. All discovering agents
Ah I see. Isn't it a bit ugly to have "host_deviceid" being the device's
own destid?
I have removed mport->host_deviceid, and added rdev_host and rdev_self
to rio_net. I also added code to create a rio device for the "self"
instance; then the locking would always use net->rdev_self->destid.
Micha
^ permalink raw reply
* Re: [PATCH 7/7] powerpc/85xx: Fix the RapidIO maintenance access functions
From: Micha Nelissen @ 2010-02-25 19:20 UTC (permalink / raw)
To: Bounine, Alexandre; +Cc: Alexandre Bounine, linuxppc-dev, thomas.moll
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E552A54EA6@CORPEXCH1.na.ads.idt.com>
Bounine, Alexandre wrote:
> Hi Micha,
>
> I tested it on my setup - it works.
> Maybe Thomas may give more details on this change.
Did you (for fun) try once to decrease the maintenance window to say, 4
kB? Then you really need these "high" bits to work properly.
Or did you try with some register at offset > 4MB? The Tundra's have
registers going up to 0x14000 or so? So don't need 16MB addressing for that.
Thanks, Micha
>> -----Original Message-----
>> From: Micha Nelissen [mailto:micha@neli.hopto.org]
>> Sent: Wednesday, February 24, 2010 3:21 PM
>> To: Alexandre Bounine
>> Subject: Re: [PATCH 7/7] powerpc/85xx: Fix the RapidIO maintenance
> access functions
>> Alexandre Bounine wrote:
>>> out_be32(&priv->maint_atmu_regs->rowtar,
>>> - (destid << 22) | (hopcount << 12) | ((offset & ~0x3) >>
> 9));
>>> + (destid << 22) | (hopcount << 12) | (offset >> 12));
>>> + out_be32(&priv->maint_atmu_regs->rowtear, (destid >> 10));
>> Did this actually work for you? The (offset >> 12) is due to the 4MB
>> window size right?
>>
>> Micha
>
^ permalink raw reply
* Re: [async_tx-next PATCH 1/2] fsldma: Fix cookie issues
From: Ira W. Snyder @ 2010-02-25 19:21 UTC (permalink / raw)
To: Steven J. Magnani; +Cc: Zhang Wei, Dan Williams, linux-kernel, linuxppc-dev
In-Reply-To: <1266860431-17310-1-git-send-email-steve@digidescorp.com>
On Mon, Feb 22, 2010 at 11:40:31AM -0600, Steven J. Magnani wrote:
> fsl_dma_tx_submit() only sets the cookie on the first descriptor of a
> transaction. It should set the cookie on all.
>
> Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
> ---
> diff -uprN a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> --- a/drivers/dma/fsldma.c 2010-02-22 11:16:36.000000000 -0600
> +++ b/drivers/dma/fsldma.c 2010-02-22 11:24:01.000000000 -0600
> @@ -362,7 +362,7 @@ static dma_cookie_t fsl_dma_tx_submit(st
> if (cookie < 0)
> cookie = 1;
>
> - desc->async_tx.cookie = cookie;
> + child->async_tx.cookie = cookie;
> }
>
> chan->common.cookie = cookie;
>
This looks correct to me. I'm not sure I ever tested the driver with a
chained struct dma_async_tx_descriptor.
Ira
^ permalink raw reply
* Re: [async_tx-next PATCH 2/2] fsldma: Fix cookie issues
From: Ira W. Snyder @ 2010-02-25 19:25 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Zhang Wei, Dan Williams, linux-kernel, Steven J. Magnani,
linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.1002222123350.4120@axis700.grange>
On Mon, Feb 22, 2010 at 09:26:13PM +0100, Guennadi Liakhovetski wrote:
> On Mon, 22 Feb 2010, Steven J. Magnani wrote:
>
> > diff -uprN a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > --- a/include/linux/dmaengine.h 2010-02-22 11:18:11.000000000 -0600
> > +++ b/include/linux/dmaengine.h 2010-02-22 11:18:30.000000000 -0600
> > @@ -31,6 +31,8 @@
> > * if dma_cookie_t is >0 it's a DMA request cookie, <0 it's an error code
> > */
> > typedef s32 dma_cookie_t;
> > +#define DMA_MIN_COOKIE 1
> > +#define DMA_MAX_COOKIE 2147483647
>
> Taking into account, that dma_cookie_t is 32 bits:
>
> +#define DMA_MAX_COOKIE ((1 << 31) - 1)
>
Steven,
After you take Guennadi's comment into acount, the rest of the patch
looks good. I'm sure I've never rolled the cookie around during testing.
Ira
^ permalink raw reply
* [async_tx-next PATCH v2 1/2] fsldma: Fix cookie issues
From: Steven J. Magnani @ 2010-02-25 19:39 UTC (permalink / raw)
To: Li Yang
Cc: Ira W. Snyder, linux-kernel, linuxppc-dev, Zhang Wei,
Steven J. Magnani, Dan Williams
fsl_dma_tx_submit() only sets the cookie on the first descriptor of a
transaction. It should set the cookie on all.
Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
---
diff -uprN a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
--- a/drivers/dma/fsldma.c 2010-02-22 11:16:36.000000000 -0600
+++ b/drivers/dma/fsldma.c 2010-02-22 11:24:01.000000000 -0600
@@ -362,7 +362,7 @@ static dma_cookie_t fsl_dma_tx_submit(st
if (cookie < 0)
cookie = 1;
- desc->async_tx.cookie = cookie;
+ child->async_tx.cookie = cookie;
}
chan->common.cookie = cookie;
^ permalink raw reply
* [async_tx-next PATCH v2 2/2] fsldma: Fix cookie issues
From: Steven J. Magnani @ 2010-02-25 19:39 UTC (permalink / raw)
To: Li Yang
Cc: Ira W. Snyder, linux-kernel, linuxppc-dev, Zhang Wei,
Steven J. Magnani, Dan Williams
fsl_dma_update_completed_cookie() appears to calculate the last completed
cookie incorrectly in the corner case where DMA on cookie 1 is in progress
just following a cookie wrap.
Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
---
diff -uprN a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
--- a/drivers/dma/fsldma.c 2010-02-22 11:16:36.000000000 -0600
+++ b/drivers/dma/fsldma.c 2010-02-22 11:08:41.000000000 -0600
@@ -819,8 +819,11 @@ static void fsl_dma_update_completed_coo
desc = to_fsl_desc(chan->ld_running.prev);
if (dma_is_idle(chan))
cookie = desc->async_tx.cookie;
- else
+ else {
cookie = desc->async_tx.cookie - 1;
+ if (unlikely(cookie < DMA_MIN_COOKIE))
+ cookie = DMA_MAX_COOKIE;
+ }
chan->completed_cookie = cookie;
diff -uprN a/include/linux/dmaengine.h b/include/linux/dmaengine.h
--- a/include/linux/dmaengine.h 2010-02-22 11:18:11.000000000 -0600
+++ b/include/linux/dmaengine.h 2010-02-22 11:18:30.000000000 -0600
@@ -31,6 +31,8 @@
* if dma_cookie_t is >0 it's a DMA request cookie, <0 it's an error code
*/
typedef s32 dma_cookie_t;
+#define DMA_MIN_COOKIE 1
+#define DMA_MAX_COOKIE ((1 << 31) - 1)
#define dma_submit_error(cookie) ((cookie) < 0 ? 1 : 0)
^ permalink raw reply
* RE: [PATCH 3/7] RapidIO: Add Port-Write handling for EM
From: Bounine, Alexandre @ 2010-02-25 20:30 UTC (permalink / raw)
To: Micha Nelissen
Cc: Alexandre Bounine, linux-kernel, thomas.moll, linuxppc-dev,
thomas.moll.ext
In-Reply-To: <4B85894A.6040406@neli.hopto.org>
Micha Nelissen wrote:
>=20
> Alexandre Bounine wrote:
> > /**
> > + * rio_em_set_ops- Sets Error Managment operations for a particular
vendor switch
> > + * @rdev: RIO device
> > + *
> > + * Searches the RIO EM ops table for known switch types. If the vid
> > + * and did match a switch table entry, then set the em_init() and
> > + * em_handle() ops to the table entry values.
>=20
> Shouldn't any RIO device be able to support error management, not just
> switches?
Only if a device reports this capability by having Error Management
Extended Features block.
Ideally, we have to provide default handler for every such device (I am
planning it for some future updates). It should be the same as for
routing operations - if the standard feature exists, it has to be used
unless something else takes over.
For now I keep all port-write messages from end-points serviced by their
individual drivers. One of reasons for this: the EM PW message format
definitions lacks any hint that allows to identify type of the message.
In theory endpoints may send port-writes of any format (up to max size
of 64 bytes), what makes unifying handling of endpoints more difficult
(at least at this stage of SRIO evolution). =20
=20
> > +/**
> > + * rio_pw_enable - Enables/disables port-write handling by a master
port
> > + * @port: Master port associated with port-write handling
> > + * @enable: 1=3Denable, 0=3Ddisable
> > + */
> > +static void rio_pw_enable(struct rio_mport *port, int enable)
> > +{
> > + if (port->ops->pwenable)
> > + port->ops->pwenable(port, enable);
> > +}
> > +
>=20
> Maybe this can be done by switch->init function?
This is not per-switch function. This function enables mport to receive
incoming PW messages. Per-switch PW enable is done in switch->init as
for Tsi57x.=20
>=20
> > +/**
> > + * rio_inb_pwrite_handler - process inbound port-write message
> > + * @pw_msg: pointer to inbound port-write message
> > + *
> > + * Processes an inbound port-write message. Returns 0 if the
request
> > + * has been satisfied.
> > + */
> > +int rio_inb_pwrite_handler(u32 *pw_msg)
> > +{
>=20
> Perhaps map this pw_msg to a struct? Or read it into named variables?
Agree - this is not nice. The best way may be defining it as a union
which combines different message formats (EM at this point) and raw
array. Will change for next update.
>=20
> > + /* Clear Port Errors */
> > + rio_mport_write_config_32(mport, destid, hopcount,
> > + rdev->phys_efptr +
RIO_PORT_N_ERR_STS_CSR(portnum),
> > + err_status & 0x07120204);
>=20
> Hardcoded value!
Agree. Tagged for next drop.
>=20
> > +
> > + if (rdev->rswitch->port_ok & (1 << portnum)) {
> > + if (err_status & RIO_PORT_N_ERR_STS_PORT_UNINIT) {
> > + rdev->rswitch->port_ok &=3D ~(1 << portnum);
> > + rio_mport_read_config_32(mport, destid,
hopcount,
> > + rdev->phys_efptr +
RIO_PORT_N_CTL_CSR(portnum),
> > + ®val);
> > + rio_mport_write_config_32(mport, destid,
hopcount,
> > + rdev->phys_efptr +
RIO_PORT_N_CTL_CSR(portnum),
> > + regval | RIO_PORT_N_CTL_LOCKOUT);
>=20
> You have a function for this?
Yes, I do. Will be fixed for the next drop.
>=20
> > + rio_mport_write_config_32(mport, destid,
hopcount,
> > + rdev->phys_efptr +
> > + RIO_PORT_N_ACK_STS_CSR(portnum),
> > + RIO_PORT_N_ACK_CLEAR);
>=20
> This doesn't work for the 568; but the 568 has no special handling?
Tsi568 will not send EM PW message. Tsi568 PWs are disabled in its
em_init().
>=20
> > + /* Clear Port-Write Pending bit */
> > + rio_mport_write_config_32(mport, destid, hopcount,
> > + rdev->phys_efptr +
RIO_PORT_N_ERR_STS_CSR(portnum),
> > + RIO_PORT_N_ERR_STS_PW_PEND);
> > +DECLARE_RIO_EM_OPS(RIO_VID_TUNDRA, RIO_DID_TSI572, tsi57x_em_init,
tsi57x_em_handler);
> > +DECLARE_RIO_EM_OPS(RIO_VID_TUNDRA, RIO_DID_TSI574, tsi57x_em_init,
tsi57x_em_handler);
> > +DECLARE_RIO_EM_OPS(RIO_VID_TUNDRA, RIO_DID_TSI577, tsi57x_em_init,
tsi57x_em_handler);
> > +DECLARE_RIO_EM_OPS(RIO_VID_TUNDRA, RIO_DID_TSI578, tsi57x_em_init,
tsi57x_em_handler);
>=20
> Why not declare these along with the other ops?
Because the EM extensions is a separate capability. It is not guaranteed
to be in every switch.
Alex.
^ permalink raw reply
* CONFIG_ISA_DMA_API without CONFIG_GENERIC_ISA_DMA
From: Scott Wood @ 2010-02-25 20:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
I tried building a kernel using mpc85xx_smp_defconfig, but with all
platforms but p4080ds removed. This was the result:
> LD .tmp_vmlinux1
> sound/built-in.o: In function `claim_dma_lock':
> /home/scott/git/fsl/linux/upstream/arch/powerpc/include/asm/dma.h:179: undefined reference to `dma_spin_lock'
> /home/scott/git/fsl/linux/upstream/arch/powerpc/include/asm/dma.h:179: undefined reference to `dma_spin_lock'
> /home/scott/git/fsl/linux/upstream/arch/powerpc/include/asm/dma.h:179: undefined reference to `dma_spin_lock'
> /home/scott/git/fsl/linux/upstream/arch/powerpc/include/asm/dma.h:179: undefined reference to `dma_spin_lock'
> /home/scott/git/fsl/linux/upstream/arch/powerpc/include/asm/dma.h:179: undefined reference to `dma_spin_lock'
> sound/built-in.o:/home/scott/git/fsl/linux/upstream/arch/powerpc/include/asm/dma.h:179: more undefined references to `dma_spin_lock' follow
> make: *** [.tmp_vmlinux1] Error 1
Commit fb4f0e8832e0075849b41b65f6bb9fdfa7593b99 (Enable GENERIC_ISA_DMA
if FSL_ULI1575 to fix compile issue) tries to deal with this, but it
ties it to CONFIG_FSL_ULI1575, which is not selected in a p4080ds-only
config.
It seems that ULI isn't really relevant to the actual problem, which is
that we enable ISA DMA API support without selecting an implementation.
Whether a certain chip is on the board that has an actual ISA
interface is irrelevant to the build breakage.
Where did the dependency list for GENERIC_ISA_DMA come from? Are there
any legitimate cases on powerpc where we want to select ISA_DMA_API but
not GENERIC_ISA_DMA (i.e. we have an alternate implementation)?
-Scott
^ 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