* RE: Keep On Debugging You
From: Zhang Wei-r63237 @ 2007-09-06 2:59 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <46DE1A36.3010300@tabi.org>
Oops!
Could you give us a live show version? :D =20
Cheers!
- zw
> -----Original Message-----
> From: linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.or
> g] On Behalf Of Timur Tabi
> Sent: Wednesday, September 05, 2007 10:54 AM
> To: linuxppc-dev@ozlabs.org
> Subject: Keep On Debugging You
>=20
> I wrote this last year in frustration with an out-of-order=20
> execution bug=20
> I was trying to fix.
>=20
>=20
> Keep On Debugging You
> Sung to the tune of REO Speedwagon's "Keep on Loving' You"
>=20
> You should've seen by the opcodes in the queue, baby
> There was something missin'
> You should known by the registers, too, maybe
> But you were too busy bitchin'
> You stalled ahead
> But you never fed
> Instead my instructions
> All ended up switchin'
>=20
> And though I know all flushes
> Still I don't remember
> Cause it was stwu way before lwzu
> And they're still together
> And I meant every line I wrote
> When I wrote them in order I meant
> That I wanted them in order
>=20
> And I'm gonna keep on debugging you
> Cause it's the only thing I'm paid to do
> I don't have time to sleep
> I just want to keep on debugging you
>=20
> (solo)
>=20
> And I meant every line I wrote
> When I wrote them in order I meant
> That I wanted them in order
>=20
> (chorus)
>=20
>=20
> --=20
> Timur Tabi
>=20
^ permalink raw reply
* Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.
From: Scott Wood @ 2007-09-06 3:01 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <04819433-30F0-4789-864D-57B474485E32@embeddedalley.com>
On Wed, Sep 05, 2007 at 03:42:03PM -0700, Dan Malek wrote:
> On Sep 5, 2007, at 3:23 PM, Scott Wood wrote:
>
> >The IMMRs I've seen from the bootloader are ff000000 (Freescale
> >boards)
> >and fa200000 (Embedded Planet). AFAICT, the number of fixed TLB
> >entries
> >is fixed at 4 on these chips, so using the fourth for flash
> >wouldn't take
> >away any general-purpose TLB entries.
>
> On these same boards, the memory controllers are usually
> configured to put the flash somewhere in that space as well.
Not on any of the boards I've worked with.
> >I certainly agree that it would be nice to check -- my immediate goal
> >is to get things working, though.
>
> It's more than nice. If you want this to work correctly and also get
> the performance enhancement, it needs to be done.
And my point was that getting that performance enhancement is "nice".
It's not there now. If you want to submit a patch to add it, go right
ahead, but it's not really related to this patch.
-Scott
^ permalink raw reply
* Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.
From: Scott Wood @ 2007-09-06 3:11 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <63F66EED-7808-40A3-B63D-AA53664CB1A0@embeddedalley.com>
On Wed, Sep 05, 2007 at 03:27:31PM -0700, Dan Malek wrote:
> On Sep 5, 2007, at 1:59 PM, Scott Wood wrote:
>
> >BTW, it seems I misremembered what the conflict was -- it's not with
> >ioremap space, but with the default location of the consistent memory
> >pool (at 0xff100000).
>
> Change the configuration option to move this somewhere
> else, outside of the wired mapping.
Sure, that'd work too -- though then I'd either have to change the
default for all platforms and hope I didn't break any of them, or have
8xx be different for what might amount to be no reason.
Would any platforms have a problem with setting the default to
0xfd000000? Anything over 0xfe000000 is particularly likely to conflict
with something.
> As I said in the last message, these lower end processors are very
> resource challenged, and we need to clever about the memory mapping and
> use of the TLBs. This isn't a place to be creating fancy memory maps
> and algorithms to manage them.
Actually, being slightly fancier by dynamically choosing where to place
the consistent memory pool would have avoided this issue.
I agree that not using a pinned TLB entry for the IMMR sucks, and maybe
I'll do something about it later -- just not right now. This patchset's
been floating for long enough without expanding its scope further.
> Use maximum mappings whenever possible, configure the memory controller
> to pack as much stuff into this single TLB mapping as possible.
> Something configurable like this memory pool should not be a reason to
> give up these performance enhancements.
Sure. I still don't think it's that big of a deal when none of the
currently supported boards have anything useful in the 8MB after the
IMMR (and pinning is only used for the debug console anyway), and custom
boards can always use custom TLB mappings, but moving the coherent region
to somewhere a little more polite is something that we should do anyway.
-Scott
^ permalink raw reply
* Re: The question about the relocate_code on u-boot for MPC8360?
From: Paul Gortmaker @ 2007-09-06 3:12 UTC (permalink / raw)
To: 郭劲; +Cc: linuxppc-embedded
In-Reply-To: <388526407.00819@tsinghua.org.cn>
T24gOC8zMC8wNywgufm+oiA8Z3VvamluMDJAdHNpbmdodWEub3JnLmNuPiB3cm90ZToKPgo+IEhp
LCBGcmllbmRzLAo+Cj4KPiBJIGFtIGRlYnVnaW5nIHRoZSB1LWJvb3Qgb24gZnJlZXNjYWxlIE1Q
QzgzNjAsIHRoZSB2ZXJzaW9uIG9mIHUtYm9vdCBpcyAxLjIuMCwgdGhlCj4gY29kZSBvbiBmbGFz
aCBpcyBPSyxidXQgdGhlIGNvZGUgZnJvbSBGTEFTSCB0byBERFIgaXMgYnJva2VuLCB0aGF0IGlz
LCBhZnRlciB0aGUKPiByZWxvY2F0ZV9jb2RlIGZ1bmN0aW9uLCB0aGUgdS1ib290IHN0YXJ0IGFn
YWluLiBJIHRlc3RlZCB0aGUgRERSIG9uIHUtYm9vdCwgaXQncwo+IE9LLiBJIHdhcyB3b25kZXJp
bmcgdGhhdCBob3QgdG8gZGVhbCB3aXRoIHRoaXMgcHJvYmxlbT8gZm9sbG93IGlzIHRoZSBDT00g
b3V0cHV0Cj4gZnJvbSB1LWJvb3QuIFRoYW5rcy4KPgoKSSB0aGluayB5b3Ugd2lsbCBmaW5kIHRo
YXQgdGhlIGRlZmF1bHQgMS4yLjAgdHJlZSBkb2VzIG5vdCBjb250YWluIHRoZQpzdXBwb3J0IGZv
ciBuZXdlciA4MzYwTURTIGJvYXJkcyB3aXRoIHRoZSByZXYyIENQVSBhbmQgdGhlIEREUjIuClRo
ZXJlIHdlcmUgZ2l0IGNvbW1pdHMgcG9zdCAxLjIuMCB0aGF0IGFkZGVkIHN1cHBvcnQgZm9yIHRo
ZXNlIC0tIGZvcgpleGFtcGxlOgoKICAgICAgICBGaXggdHdvIGJ1Z3MgZm9yIE1QQzgzeHggRERS
MiBjb250cm9sbGVyIFNQRCBJbml0CiAgICAgICAgY29tbWl0IDZmYmYyNjFmOGRmMjk0ZTU4OWNm
YWRlYmViZTU0NjhlM2MwZjI5ZTkKCiAgICAgICAgbXBjODN4eDogQWRkIEREUjIgY29udHJvbGxl
ciBmaXhlZC9TUEQgSW5pdCBmb3IgTVBDODN4eAogICAgICAgIGNvbW1pdCBkNjE4NTNjZjI0NzJl
MGI4YmNiZDEzMTQ2MWE5M2QxYzQ5ZmYwYzFmCgpUaGVyZSB3ZXJlIGFsc28gc29tZSBERFIyIHJl
bGF0ZWQgY2hhbmdlcyB0aGF0IGNhbWUgaW4gd2l0aCB0aGUKbXBjODMyeE1EUyBwYXRjaGVzLgoK
UGF1bC4KCgoKCj4KPgo+Cj4KPgo+Cj4gVS1Cb290IDEuMi4wIChBdWcgMjkgMjAwNyAtIDIwOjUw
OjM3KSBNUEM4M1hYCj4KPiBDbG9jayBjb25maWd1cmF0aW9uOgo+ICAgQ29oZXJlbnQgU3lzdGVt
IEJ1czogIDI2NCBNSHoKPiAgIENvcmU6ICAgICAgICAgICAgICAgICA1MjggTUh6Cj4gICBRRTog
ICAgICAgICAgICAgICAgICAgMTk4IE1Iego+ICAgTG9jYWwgQnVzIENvbnRyb2xsZXI6IDI2NCBN
SHoKPiAgIExvY2FsIEJ1czogICAgICAgICAgICAgNjYgTUh6Cj4gICBERFI6ICAgICAgICAgICAg
ICAgICAgMjY0IE1Iego+ICAgRERSIFNlY29uZGFyeTogICAgICAgIDI2NCBNSHoKPiAgIFNFQzog
ICAgICAgICAgICAgICAgICAgODggTUh6Cj4gICBJMkMxOiAgICAgICAgICAgICAgICAgMjY0IE1I
ego+ICAgSTJDMjogICAgICAgICAgICAgICAgIDI2NCBNSHoKPiBDUFU6IFJldjogVW5rbm93biBn
dW9qaW5nIG1vZGlmaWVkIHNvdXJjZSBjb2RlCj4gUmV2OiAyMCBhdCA1MjggTUh6Cj4gQm9hcmQ6
IEZyZWVzY2FsZSBNUEM4MzYwRU1EUwo+IEkyQzogICByZWFkeQo+IERSQU06Cj4gICAgU0RSQU0g
b24gTG9jYWwgQnVzOiA2NCBNQgo+ICAgIEREUiBSQU06IDI1NiBNQgo+IEREUiB0ZXN0IHBoYXNl
IDE6Cj4gRERSIHRlc3QgcGhhc2UgMjoKPiBERFIgdGVzdCBwYXNzZWQuCj4gaW5pdF9zZXF1ZW5j
ZSBmaW5pc2hlZAo+IGJlZ2luIHNldCB1cCBhIG5ldyBzdGFjawo+IGJlZ2lubmluZyBtZW1jcHkK
PiBlbmRlZCBtZW1jcHksYmVnaW5uaW5nIHJlbG9jYXRlX2NvZGUKPgo+Cj4gVS1Cb290IDEuMi4w
IChBdWcgMjkgMjAwNyAtIDIwOjUwOjM3KSBNUEM4M1hYCj4KPiBDbG9jayBjb25maWd1cmF0aW9u
Ogo+ICAgQ29oZXJlbnQgU3lzdGVtIEJ1czogIDI2NCBNSHoKPiAgIENvcmU6ICAgICAgICAgICAg
ICAgICA1MjggTUh6Cj4gICBRRTogICAgICAgICAgICAgICAgICAgMTk4IE1Iego+ICAgTG9jYWwg
QnVzIENvbnRyb2xsZXI6IDI2NCBNSHoKPiAgIExvY2FsIEJ1czogICAgICAgICAgICAgNjYgTUh6
Cj4gICBERFI6ICAgICAgICAgICAgICAgICAgMjY0IE1Iego+ICAgRERSIFNlY29uZGFyeTogICAg
ICAgIDI2NCBNSHoKPiAgIFNFQzogICAgICAgICAgICAgICAgICAgODggTUh6Cj4gICBJMkMxOiAg
ICAgICAgICAgICAgICAgMjY0IE1Iego+ICAgSTJDMjogICAgICAgICAgICAgICAgIDI2NCBNSHoK
PiBDUFU6IFJldjogVW5rbm93biBndW9qaW5nIG1vZGlmaWVkIHNvdXJjZSBjb2RlCj4gUmV2OiAy
MCBhdCA1MjggTUh6Cj4gQm9hcmQ6IEZyZWVzY2FsZSBNUEM4MzYwRU1EUwo+IEkyQzogICByZWFk
eQo+IERSQU06Cj4gICAgU0RSQU0gb24gTG9jYWwgQnVzOiA2NCBNQgo+ICAgIEREUiBSQU06IDI1
NiBNQgo+IEREUiB0ZXN0IHBoYXNlIDE6Cj4gRERSIHRlc3QgcGhhc2UgMjoKPiBERFIgdGVzdCBw
YXNzZWQuCj4gaW5pdF9zZXF1ZW5jZSBmaW5pc2hlZAo+IGJlZ2luIHNldCB1cCBhIG5ldyBzdGFj
awo+IGJlZ2lubmluZyBtZW1jcHkKPiBlbmRlZCBtZW1jcHksYmVnaW5uaW5nIHJlbG9jYXRlX2Nv
ZGUKPgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
PiBMaW51eHBwYy1lbWJlZGRlZCBtYWlsaW5nIGxpc3QKPiBMaW51eHBwYy1lbWJlZGRlZEBvemxh
YnMub3JnCj4gaHR0cHM6Ly9vemxhYnMub3JnL21haWxtYW4vbGlzdGluZm8vbGludXhwcGMtZW1i
ZWRkZWQKPgo=
^ permalink raw reply
* [PATCH] cmd_ctrl-callback is needed in plat_nand.c
From: Sergej Stepanov @ 2007-09-06 7:41 UTC (permalink / raw)
To: linuxppc-embedded, Vitaly Wool
To get our board (IDS8247) to work with the driver the cmd_ctrl-callback is needed (controlling ALE/CLE/nCE).
Sigend-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
---
diff -ruN linux-2.6.22.1-orig/drivers/mtd/nand/plat_nand.c linux-2.6.22.1_ids8247/drivers/mtd/nand/plat_nand.c
--- linux-2.6.22.1-orig/drivers/mtd/nand/plat_nand.c 2007-07-10 20:56:30.000000000 +0200
+++ linux-2.6.22.1_ids8247/drivers/mtd/nand/plat_nand.c 2007-08-02 10:54:34.000000000 +0200
@@ -66,7 +66,7 @@
data->chip.ecc.hwctl = pdata->ctrl.hwcontrol;
data->chip.ecc.layout = pdata->chip.ecclayout;
data->chip.ecc.mode = NAND_ECC_SOFT;
+ data->chip.cmd_ctrl = pdata->ctrl.cmd_ctrl;
platform_set_drvdata(pdev, data);
/* Scan to find existance of the device */
^ permalink raw reply
* Re: Problems enabling NTP on ELDK
From: Johan Borkhuis @ 2007-09-06 7:43 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20070905184827.26859247AF@gemini.denx.de>
Wolfgang Denk wrote:
> In message <46DE9322.7080901@dutchspace.nl> you wrote:
>
>> I tried enabling NTP on my embedded machine (using ELDK 4.1, ppc_85xx,
>> kernel version 2.6.14 with Xenomai 2.3.2). After I did that I noticed
>> that ksoftirqd/0 suddenly took almost all processor time (> 95%). What
>> is causing this? Is there a way around this, or is this something that
>> does not cause any problems?
>>
>
> You probably have some poroblems in your kernel port - check the RTC
> driver and related modules like I2C etc. Of course this depends on
> the NTP configuration you use, but the only kernel interaction I can
> think of that could cause this is if you interact with the RTC. [I
> guess that normal network traffic is working fine on your board.]
>
All other functions are working fine: no problem with network or other
PCI devices.
I disabled all RTC and I2C devices, and the problem disappeared. After
enabling all items one by one the cause of the problem seems to be the
DS1375 RTC: after I enable this and start NTPD ksoftirqd goes wild
again. I do not see any other special activity: no extra interrupts in
/proc/interrupts, and also no other RTC related errors or messages. Also
OpenPIC does not show any extra interrupts.
Is there a way to find out what interrupt is causing ksoftirqd to be
triggered?
> BTW: ELDK 4.1 comes with a 2.6.19.2 kernel - is there a special
> reason that you use such an obsoletel kernel tree?
>
I am using an MVME3100 board together with Xenomai. This board has
support for version 2.6.14-ppc and 2.6.20-ppc, while Xenomai/Adeos is
supported on 2.6.14 and 2.6.19. I did not yet find time to backport the
support to 2.6.19.
Kind regards,
Johan Borkhuis
^ permalink raw reply
* [PATCH update] Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Stefan Richter @ 2007-09-06 7:50 UTC (permalink / raw)
To: Andrew Morton
Cc: michal.k.k.piotrowski, rbrito, krh, linux-kernel, rjw,
linuxppc-dev, debian-powerpc, linux-pm, rael
In-Reply-To: <tkrat.29a16d2ec8698ff2@s5r6.in-berlin.de>
On 5 Sep, Stefan Richter wrote:
> On 5 Sep, Andrew Morton wrote:
>>> >>> Trying to free already-free IRQ 40
>>> >>> pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
>>> >>> firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
...
>> It's not clear _why_ pci_set_power_state() is failing.
>
> The only -22 error path in pci_set_power_state is this:
>
> /* Validate current state:
> * Can enter D0 from any state, but if we can only go deeper
> * to sleep if we're already in a low power state
> */
> if (state != PCI_D0 && dev->current_state > state) {
> printk(KERN_ERR "%s(): %s: state=%d, current state=%d\n",
> __FUNCTION__, pci_name(dev), state, dev->current_state);
> return -EINVAL;
> } [...else...]
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Subject: firewire: fw-ohci: ignore failure of pci_set_power_state (fix suspend regression)
Fixes (papers over) "Sleep problems with kernels >= 2.6.21 on powerpc",
http://lkml.org/lkml/2007/8/25/155. The issue is that the FireWire
controller's pci_dev.current_state of iBook G3 and presumably older
PowerBooks is still in PCI_UNKNOWN instead of PCI_D0 when the firewire
driver's .suspend method is called.
Like it was suggested earlier in http://lkml.org/lkml/2006/10/24/13, we
do not fail .suspend anymore if pci_set_power_state failed.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
Update:
- omit comment which will become outdated if the underlying problem is fixed
- log the error return value
- document the actual bug in the patch description
IMO the actual bug here (operating the controller while it is in
PCI_UNKNOWN state, which is surely a fault in the PPC platform code) is
something to be fixed post 2.6.23 release.
drivers/firewire/fw-ohci.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
Index: linux/drivers/firewire/fw-ohci.c
===================================================================
--- linux.orig/drivers/firewire/fw-ohci.c
+++ linux/drivers/firewire/fw-ohci.c
@@ -1973,10 +1973,8 @@ static int pci_suspend(struct pci_dev *p
return err;
}
err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
- if (err) {
- fw_error("pci_set_power_state failed\n");
- return err;
- }
+ if (err)
+ fw_error("pci_set_power_state failed with %d\n", err);
return 0;
}
--
Stefan Richter
-=====-=-=== =--= --==-
http://arcgraph.de/sr/
^ permalink raw reply
* RE: Gianfar - MPC8541 - tx buffer overrun errors
From: Joyeau Sylvain @ 2007-09-06 8:43 UTC (permalink / raw)
To: Shriram Janardhan, linuxppc-embedded
Hi Shriram,
Try to increase the DEFAULT_TX_RING_SIZE parameter in gianfar.h.
Enabling NAPI mechanism should have no effect on transmission side.
Cheers
--
sj
________________________________
From:
linuxppc-embedded-bounces+sylvain.joyeau=3Dthomson.net@ozlabs.org
[mailto:linuxppc-embedded-bounces+sylvain.joyeau=3Dthomson.net@ozlabs.org=
]
On Behalf Of Shriram Janardhan
Sent: jeudi 6 septembre 2007 03:49
To: linuxppc-embedded@ozlabs.org
Subject: Gianfar - MPC8541 - tx buffer overrun errors
=09
=09
All,
=20
I am running 2.6.11 version of the kernel on MPC8541. Have one
of the TSECs configured at 100Mbps/Full Duplex. The TSEC MAC is
connected to a Marvell Ethernet switch MAC without any PHY in between.
MAC level flow control is enabled but no pause frames sent or received.
=20
I see a high number of transmit buffer overrun errors
(tx_fifo_empty errors in the gianfar driver). I don't have NAPI
enabled. In addition to other things, I was thinking of enabling NAPI
and see if it helps - is there any downside to it?? Are there any other
parameters that I could tweak to reduce/eliminate the overrun errors??
=20
Thanks,
Shriram.
=20
________________________________
Got a little couch potato?=20
Check out fun summer activities for kids.
<http://us.rd.yahoo.com/evt=3D48248/*http://search.yahoo.com/search?fr=3D=
oni
_on_mail&p=3Dsummer+activities+for+kids&cs=3Dbz>=20
^ permalink raw reply
* Re: OF NDFC
From: Segher Boessenkool @ 2007-09-06 13:06 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070905160008.201a243a@vader.jdub.homelinux.org>
>> Is anybody working on the device-tree-aware ppc 44x NAND flash
>> controller (ndfc) driver?
>
> Not to my knowledge. We sort of need a decent binding for NAND flash
> in general first.
Not really. You can put the NAND controller in the device
tree without describing the NAND flash itself -- and for that,
you only need a "name", "compatible", "reg", and maybe some
interrupt stuff.
Segher
^ permalink raw reply
* Re: OF NDFC
From: Josh Boyer @ 2007-09-06 13:17 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <b9fb2fad5d6b04a07996416842df7f72@kernel.crashing.org>
On Thu, 6 Sep 2007 15:06:03 +0200
Segher Boessenkool <segher@kernel.crashing.org> wrote:
> >> Is anybody working on the device-tree-aware ppc 44x NAND flash
> >> controller (ndfc) driver?
> >
> > Not to my knowledge. We sort of need a decent binding for NAND flash
> > in general first.
>
> Not really. You can put the NAND controller in the device
> tree without describing the NAND flash itself -- and for that,
> you only need a "name", "compatible", "reg", and maybe some
> interrupt stuff.
He said driver. To test a driver, you'd need the binding for both the
controller, and the NAND flash it controls. Otherwise, the driver
isn't going to do much :).
josh
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Segher Boessenkool @ 2007-09-06 13:21 UTC (permalink / raw)
To: Scott Wood; +Cc: ppc-dev
In-Reply-To: <20070904184810.GG18280@ld0162-tx32.am.freescale.net>
>> That's wrong if lock is assigned to r0, you should use
>> a "b" constraint to avoid this. Same for atomic_dec below.
>
> GCC should really have removed r0 from the "r" class (it isn't truly a
> general-purpose register), and had a different class meaning
> "r"-plus-r0.
Nah, GPR0 _is_ a general purpose register, you just cannot use all
general purpose registers as base registers ;-)
Either way, it's a bit late to change this, no?
Segher
^ permalink raw reply
* Re: Document and implement an improved flash device binding
From: Segher Boessenkool @ 2007-09-06 13:28 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070905025907.GG17189@localhost.localdomain>
>>> + - bank-width : Width (in bytes) of the flash bank. Equal to
>>> the
>>> + device width times the number of interleaved chips.
>>> + - device-width : (optional) Width of a single flash chip. If
>>> + omitted, assumed to be equal to 'bank-width'.
>>
>> Let's have bank-width optional instead, it's more natural
>> that way for the common case of just one chip. Or, you can
>> say that either is optional.
>
> No, I'm disinclined to do that since bank-width is the primary bit of
> information that the driver needs.
Bzzzzt. That's not what the device tree is about; it should
describe the hardware, it shouldn't be just a config file for
the current Linux drivers.
Besides, like I said, for the common case where your flash
chips aren't interleaved, it makes way more sense to talk
about device-width than it does to call it bank-width.
>>> + OpenBIOS@0 {
>>
>> This show immediately why node name = partition name won't
>> work out. You're not supposed to start a node name with a
>> capital like this.
>
> According to which?
It's just convention, really.
OTOH, spaces and commas and colons and a whole bunch of special
chars are completely disallowed here, so you need...
> Nonetheless, I've added a label property,
...something like that :-)
Segher
^ permalink raw reply
* [NEWBIE] Interrupt-problem mpc5200
From: S. Fricke @ 2007-09-06 13:30 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]
Hello all.
What are the steps to configure an MPC500B-Board to react on an IRQ (2)?
I have written a test-driver with this code-snippets, but the prozessor
hangs when loading the driver.
my __init-function looks like:
static int __init mod_init( void )
{
volatile static struct mpc52xx_intr __iomem *intr;
u32 intr_ctrl;
// ...
printk( "intmod.ko: interrupt init ");
if (request_irq(MPC52xx_IRQ2, intmod_isr, IRQF_SHARED , "intmod",
INTMOD_IRQ_BOARD) == -EBUSY)
printk("KO\n");
else
printk("OK\n");
intr = ioremap(MPC52xx_MBAR+MPC52xx_INTR_OFFSET, MPC52xx_INTR_SIZE);
// read - modify - write
intr_ctrl = in_be32(&intr->ctrl);
intr_ctrl &= 0xfff3ffff;
intr_ctrl |= 0x00080200;
out_be32(&intr->ctrl, intr_ctrl); // ERROR!
if(intr) iounmap(intr);
// ...
}
On the Line, marked with "ERROR!" the prozessor hangs and the kernel drops
out.
TIA: Silvio
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH)
Linux-Entwicklung JABBER: fricke@jabber.org
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: OF NDFC
From: Valentine Barshak @ 2007-09-06 13:30 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070906081732.079bc45d@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Thu, 6 Sep 2007 15:06:03 +0200
> Segher Boessenkool <segher@kernel.crashing.org> wrote:
>
>>>> Is anybody working on the device-tree-aware ppc 44x NAND flash
>>>> controller (ndfc) driver?
>>> Not to my knowledge. We sort of need a decent binding for NAND flash
>>> in general first.
>> Not really. You can put the NAND controller in the device
>> tree without describing the NAND flash itself -- and for that,
>> you only need a "name", "compatible", "reg", and maybe some
>> interrupt stuff.
>
> He said driver. To test a driver, you'd need the binding for both the
> controller, and the NAND flash it controls. Otherwise, the driver
> isn't going to do much :).
>
> josh
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
AFAIK, NAND flash is autodetected by reading it's ID at runtime, so
there should be no need for flash bindings.
Thanks,
Valentine.
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: Segher Boessenkool @ 2007-09-06 13:31 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070904002745.GB20549@localhost.localdomain>
> Hrm.. IIRC, it is permissible under Linux to only include device nodes
> for those PCI devices where something must be specified which can't be
> proved via PCI.
It is. It isn't clear (to me, at least) which properties are
required in a PCI node that exists for e.g. interrupt reasons
only; or how the kernel decides if a PCI node is a "real" PCI
node (i.e., using the PCI binding), or an "empty" PCI node.
Segher
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: Segher Boessenkool @ 2007-09-06 13:36 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, david
In-Reply-To: <20070904114945.303440@gmx.net>
>> PCI memory space sits on the PCI bus, not on the PCI host bridge,
>> so is not part of "reg" but is part of "ranges" here, since it is
>> direct mapped into the host's address space.
> That's right, but what about this example here (from a Pegasos II):
>
> /proc/device-tree/pci@80000000:
> reg 80000000 40000000
> ranges 01000000 00000000 00000000 fe000000 00000000 00010000
> 02000000 00000000 80000000 80000000 00000000 40000000
That's just broken.
> AFAIU the reg property overlaps the ranges property for the PCI memory
> space from 0x80000000 to 0xC0000000 or the CPU address space at the
> same location!?
reg = < something for pci config space >,
< fe000000 10000 >
ranges = < 02000000 0 80000000 80000000 0 40000000 >
>> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
>> PowerPC system bus. So, it can not be mentioned in the "ranges"
>> property, but the PHB registers used to access it should be shown
>> in the "reg" property. It could be a simple linear window (it
>> sounds like it is here?), but it could for example also be implemented
>> via an address/data register pair.
> Yes, it is a simple linear address window. I'll remove its address
> range
> from the reg property.
No, please remove it from the "ranges" property, instead.
>> The order of the "reg" entries depends on the exact model of PCI
>> bridge, so a device binding for it has to be written.
> Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it
> should
> be enough to check for the board type, but a compatible property
> doesn't
> hurt.
Please always use "compatible" to probe any devices.
Segher
^ permalink raw reply
* Re: OF NDFC
From: Josh Boyer @ 2007-09-06 13:41 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46E000E0.4080203@ru.mvista.com>
On Thu, 06 Sep 2007 17:30:08 +0400
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> AFAIK, NAND flash is autodetected by reading it's ID at runtime, so
> there should be no need for flash bindings.
Well, I'm not really sure. CFI and JEDEC can both be probed as well,
and we're working on a binding there. But if you think you can come up
with a driver for NDFC that doesn't require some kind of device tree
description of the devices it controls, then by all means go for it.
josh
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: Segher Boessenkool @ 2007-09-06 13:41 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, david
In-Reply-To: <20070904122040.276440@gmx.net>
> BTW: It looks like the Pegasos II device tree defines device_type =
> "spi"
> for the IDE controller. Is that correct?
There is no standard binding for an "spi" device type. I have no
idea which of various "SPI" kind of devices is meant here; and none
of the ones I know of have anything to do with ATA anyway.
In short, it probably is incorrect.
Also, in general, you shouldn't use "device_type" in flat device
trees (the main exceptions are: some/most bus nodes, cpu nodes,
some other "standard" nodes).
>> There is no such thing as "interrupt 14 and 15" on PCI. You can use
>> the interrupt mapping recommended practice to show two interrupts
>> (and their polarity, and how they are routed to the relevant interrupt
>> controller) in the IDE node.
> But I'll still need a quirk in the IDE driver, because it doesn't make
> use of any interrupt routing information in the device tree. If so, I
> can omit the whole IDE controller device node and simply rely on the
> IDE driver's probe functions and the Pegasos IDE IRQ quirk.
> I wonder how this issue will be handled for libata and the via-pata
> driver, since IIRC this one doesn't contain the Pegasos IDE IRQ quirk.
I imagine the ata quirk would ask the arch or platform code about
the interrupts used; it in turn can query the device tree.
Segher
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Scott Wood @ 2007-09-06 13:43 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppc-dev
In-Reply-To: <e1d766f8390851a75a6fe83800484ab7@kernel.crashing.org>
On Thu, Sep 06, 2007 at 03:21:36PM +0200, Segher Boessenkool wrote:
> >>That's wrong if lock is assigned to r0, you should use
> >>a "b" constraint to avoid this. Same for atomic_dec below.
> >
> >GCC should really have removed r0 from the "r" class (it isn't truly a
> >general-purpose register), and had a different class meaning
> >"r"-plus-r0.
>
> Nah, GPR0 _is_ a general purpose register, you just cannot use all
> general purpose registers as base registers ;-)
Bah.
> Either way, it's a bit late to change this, no?
Sure, I was just whining due to having been bitten by this sort of bug in
the past. :-)
-Scott
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: Segher Boessenkool @ 2007-09-06 13:56 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070905024805.GE17189@localhost.localdomain>
> That looks totally bogus. Unlike Segher, I think there are a few
> cases where overlapping reg and ranges can make sense
That's not unlike me -- I may have lower tolerance for it though :-)
> (PCI bridges
> where config space is accessed indirectly via MMIO registers which lie
> in the legacy ISA IO space is an example).
That's a good example yes.
> But this doesn't look like
> such a case - it just looks like whoever did the device tree
> misunderstood the distinction between reg and ranges.
Indeed.
>>> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
>>> PowerPC system bus. So, it can not be mentioned in the "ranges"
>>> property, but the PHB registers used to access it should be shown
>>> in the "reg" property. It could be a simple linear window (it
>>> sounds like it is here?), but it could for example also be
>>> implemented
>>> via an address/data register pair.
>
> Err... huh? The legacy IO space is assigned a block of addresses in
> 3-word "OF-PCI-space by the PCI binding. When that is translated into
> an MMIO range by the bridge, there's no reason that can't be encoded
> into the ranges property.
Sure, it can be encoded like that. But does it make sense?
You cannot use legacy I/O space as normal memory space.
On an arch like x86, where "I/O addresses" exist on the system
bus as well, it would make sense, since you can translate I/O
addresses to I/O addresses that way (except on x86 even it cannot
be done either, since I/O addresses cannot be encoded on the root
bus -- at least not in existing device trees. There is no official
x86 binding yet though).
Also, from a driver standpoint, a PHB driver needs to find out
two main things about the bridge: a) how and where to generate
config cycles; b) how and where to generate legacy I/O cycles.
It is told "how" by the "compatible" property, and "where" by
the "reg" property, normally.
But yes, you _can_ use "ranges" for this purpose on PHBs where
legacy I/O is linearly mapped. It just doesn't make much sense.
The binding for your specific PHB should tell you what to do.
>> Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it
>> should
>> be enough to check for the board type, but a compatible property
>> doesn't
>> hurt.
>
> The whole damn point of the device tree is to avoid using this kind of
> non-local information "I know what the board type is over there, so it
> must be this PCI bridge over here". The node should have a compatible
> property which is sufficient to select the right bridge driver.
Yeah. _Even if_ the kernel decides to cheat by hardcoding certain
board information, that doesn't mean the device tree shouldn't
encode that info, too.
> I think this is typically badly done at the moment, simply because PCI
> has historically been set up by the platform code, rather than by a
> "host bridge driver" in the mould of other drivers. I don't see that
> changing real soon, but that doesn't mean we shouldn't at least put
> enough information in the device tree to make it possible.
Exactly.
Segher
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: Segher Boessenkool @ 2007-09-06 14:00 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20070905115419.321990@gmx.net>
>> The node should have a compatible
>> property which is sufficient to select the right bridge driver.
> Yeah, I defined a compatible = "mai,articias"; property in the pci
> node.
> Are there any naming conventions (maybe lower case only)?
It's conventional for the part behind the comma to be lower-case
only, yes. There are more stringent rules for the part before
the comma (the manufacturer part). What is "mai"?
Segher
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Segher Boessenkool @ 2007-09-06 14:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192820.GG32398@ld0162-tx32.am.freescale.net>
> +/ {
> + model = "Analogue & Micro Adder MPC875";
This should probably be just "MPC875".
Segher
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Segher Boessenkool @ 2007-09-06 14:09 UTC (permalink / raw)
To: Scott Wood; +Cc: ppc-dev
In-Reply-To: <20070906134354.GA16153@ld0162-tx32.am.freescale.net>
>> Either way, it's a bit late to change this, no?
>
> Sure, I was just whining due to having been bitten by this sort of bug
> in
> the past. :-)
Write a song about it, it's therapeutical it seems!
Segher
^ permalink raw reply
* Re: OF NDFC
From: Segher Boessenkool @ 2007-09-06 14:06 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070906084109.315544ea@zod.rchland.ibm.com>
>> AFAIK, NAND flash is autodetected by reading it's ID at runtime, so
>> there should be no need for flash bindings.
>
> Well, I'm not really sure. CFI and JEDEC can both be probed as well,
> and we're working on a binding there.
JEDEC cannot be reliably probed. CFI can be _almost_ probed,
you need to know the interleaving though, to handle some edge
cases. Oh, and you need to know it _is_ CFI, of course.
> But if you think you can come up
> with a driver for NDFC that doesn't require some kind of device tree
> description of the devices it controls, then by all means go for it.
I don't know whether NAND can be reliably probed; most "standard"
NAND devices can be, but I don't know what standards are involved
here, if any. We'll need some MTD people help here.
OTOH, it definitely is better to describe only the NAND controller
and not the devices, than to put nothing at all in the device tree.
We had this same situation with NOR flash before, already...
Segher
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Segher Boessenkool @ 2007-09-06 14:13 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <46DCCE19.6050401@freescale.com>
>> This kind of thing is typically hardcoded into the firmware (just like
>> the device tree is) -- just put it somewhere _next to_ the device
>> tree,
>> not _in_ it.
>
> What is next to the device tree?
"Anywhere else in the firmware".
> AFAIK, there is no other standard data structure that could take place
> of the par_io nodes in the DTS.
The device tree is not a dumping ground for all your "I need some
standard data structure" stuff. Use an XML file if you have to ;-)
> I agree with your points, Segher, but replacing the par_io node with a
> bunch of par_io_config_pin() calls in the kernel is not really an
> improvement, I think. Until we migrate the QE pin configuration code
> to U-boot, I suggest that we keep the device tree structure as-is and
> continue to use it for new code. That way, it will all stay in one
> place.
Sure, some migration plan is in order, things won't change overnight.
That doesn't mean you don't need to start planning _now_ ;-)
Segher
^ 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