* [PATCH 5/6] [POWERPC] properly declare onstack completion in iseries veth
From: Benjamin Herrenschmidt @ 2008-04-09 7:21 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
The iSeries veth driver uses an on-stack struct completion that
it initializes using the COMPLETION_INITIALIZER instead of
COMPLETION_INITIALIZER_ONSTACK macro, causing problems with
lockdep.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/net/iseries_veth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-work.orig/drivers/net/iseries_veth.c 2008-04-09 13:55:24.000000000 +1000
+++ linux-work/drivers/net/iseries_veth.c 2008-04-09 13:55:48.000000000 +1000
@@ -308,7 +308,8 @@ static void veth_complete_allocation(voi
static int veth_allocate_events(HvLpIndex rlp, int number)
{
- struct veth_allocation vc = { COMPLETION_INITIALIZER(vc.c), 0 };
+ struct veth_allocation vc =
+ { COMPLETION_INITIALIZER_ONSTACK(vc.c), 0 };
mf_allocate_lp_events(rlp, HvLpEvent_Type_VirtualLan,
sizeof(struct veth_lpevent), number,
^ permalink raw reply
* [PATCH 6/6] [POWERPC] Fix device-tree locking vs. interrupts
From: Benjamin Herrenschmidt @ 2008-04-09 7:21 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Lockdep found out that we can occasionally take the device-tree
lock for reading from softirq time (from rtas_token called
by the rtas real time clock code called by the NTP code),
while we take it occasionally for writing without masking
interrupts. The combination of those two can thus deadlock.
While some of those cases of interrupt read lock could be fixed
(such as caching the RTAS tokens) I figured that taking the
lock for writing is so rare (device-tree modification) that we
may as well penalize that case and allow reading from interrupts.
Thus, this turns all the writers to take the lock with irqs
masked to avoid the situation.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/prom.c | 28 +++++++++++++++++-----------
1 file changed, 17 insertions(+), 11 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/prom.c 2008-04-09 14:23:18.000000000 +1000
+++ linux-work/arch/powerpc/kernel/prom.c 2008-04-09 14:25:48.000000000 +1000
@@ -1244,12 +1244,14 @@ EXPORT_SYMBOL(of_node_put);
*/
void of_attach_node(struct device_node *np)
{
- write_lock(&devtree_lock);
+ unsigned long flags;
+
+ write_lock_irqsave(&devtree_lock, flags);
np->sibling = np->parent->child;
np->allnext = allnodes;
np->parent->child = np;
allnodes = np;
- write_unlock(&devtree_lock);
+ write_unlock_irqrestore(&devtree_lock, flags);
}
/*
@@ -1260,8 +1262,9 @@ void of_attach_node(struct device_node *
void of_detach_node(struct device_node *np)
{
struct device_node *parent;
+ unsigned long flags;
- write_lock(&devtree_lock);
+ write_lock_irqsave(&devtree_lock, flags);
parent = np->parent;
if (!parent)
@@ -1292,7 +1295,7 @@ void of_detach_node(struct device_node *
of_node_set_flag(np, OF_DETACHED);
out_unlock:
- write_unlock(&devtree_lock);
+ write_unlock_irqrestore(&devtree_lock, flags);
}
#ifdef CONFIG_PPC_PSERIES
@@ -1373,20 +1376,21 @@ __initcall(prom_reconfig_setup);
int prom_add_property(struct device_node* np, struct property* prop)
{
struct property **next;
+ unsigned long flags;
prop->next = NULL;
- write_lock(&devtree_lock);
+ write_lock_irqsave(&devtree_lock, flags);
next = &np->properties;
while (*next) {
if (strcmp(prop->name, (*next)->name) == 0) {
/* duplicate ! don't insert it */
- write_unlock(&devtree_lock);
+ write_unlock_irqrestore(&devtree_lock, flags);
return -1;
}
next = &(*next)->next;
}
*next = prop;
- write_unlock(&devtree_lock);
+ write_unlock_irqrestore(&devtree_lock, flags);
#ifdef CONFIG_PROC_DEVICETREE
/* try to add to proc as well if it was initialized */
@@ -1406,9 +1410,10 @@ int prom_add_property(struct device_node
int prom_remove_property(struct device_node *np, struct property *prop)
{
struct property **next;
+ unsigned long flags;
int found = 0;
- write_lock(&devtree_lock);
+ write_lock_irqsave(&devtree_lock, flags);
next = &np->properties;
while (*next) {
if (*next == prop) {
@@ -1421,7 +1426,7 @@ int prom_remove_property(struct device_n
}
next = &(*next)->next;
}
- write_unlock(&devtree_lock);
+ write_unlock_irqrestore(&devtree_lock, flags);
if (!found)
return -ENODEV;
@@ -1447,9 +1452,10 @@ int prom_update_property(struct device_n
struct property *oldprop)
{
struct property **next;
+ unsigned long flags;
int found = 0;
- write_lock(&devtree_lock);
+ write_lock_irqsave(&devtree_lock, flags);
next = &np->properties;
while (*next) {
if (*next == oldprop) {
@@ -1463,7 +1469,7 @@ int prom_update_property(struct device_n
}
next = &(*next)->next;
}
- write_unlock(&devtree_lock);
+ write_unlock_irqrestore(&devtree_lock, flags);
if (!found)
return -ENODEV;
^ permalink raw reply
* Re: [PATCH 2/11] cell: generalize io-workarounds code
From: Ishizaki Kou @ 2008-04-09 7:46 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
In-Reply-To: <1207295412.10388.364.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2008-04-04 at 15:42 +0900, Ishizaki Kou wrote:
> >
> > As you pointed, spider I/O functions in Cell blades need 2 step
> > indirections by our patch. Shall I make another one for Cell blades
> > whose spider I/O functions need one step indirection?
> > (But you will need 2 step indirections when you use PCI-ex.)
>
> I think the blades will need the same stuff as celleb since it's
> possible to use the PCI-Express on them too.
>
> Maybe an option is to do a if () / else statement rather than a function
> pointer in there, it would at least be cheaper in term of CPU cycle
> don't you think ? Anyway, do as you prefer.
I want to keep my patch as it is, because I think it is easier to add
function pointers than if () / else statement when someone adds new
I/O functions to the io-workaround. For 2.6.27 or later, I think about
adding null I/O functions for Celleb internal pci bus to reduce
overhead for searching bus.
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: [PATCH 5/6] [POWERPC] properly declare onstack completion in iseries veth
From: Christoph Hellwig @ 2008-04-09 8:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080409072230.C861EDDED0@ozlabs.org>
On Wed, Apr 09, 2008 at 05:21:34PM +1000, Benjamin Herrenschmidt wrote:
> The iSeries veth driver uses an on-stack struct completion that
> it initializes using the COMPLETION_INITIALIZER instead of
> COMPLETION_INITIALIZER_ONSTACK macro, causing problems with
> lockdep.
should probably go in ASAP independent of the lockdep series.
^ permalink raw reply
* Re: [PATCH 5/6] [POWERPC] properly declare onstack completion in iseries veth
From: Stephen Rothwell @ 2008-04-09 8:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080409072230.C861EDDED0@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]
On Wed, 09 Apr 2008 17:21:34 +1000 Benjamin Herrenschmidt <benh@ozlabs.org> wrote:
>
> The iSeries veth driver uses an on-stack struct completion that
> it initializes using the COMPLETION_INITIALIZER instead of
> COMPLETION_INITIALIZER_ONSTACK macro, causing problems with
> lockdep.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 4xx defconfig reorg
From: Josh Boyer @ 2008-04-09 10:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18428.24729.933714.665889@cargo.ozlabs.ibm.com>
On Wed, 9 Apr 2008 16:22:17 +1000
Paul Mackerras <paulus@samba.org> wrote:
> Josh Boyer writes:
>
> > I've not heard any objections. I'll be pushing my commit to my next
> > branch tomorrow morning.
>
> I don't have any objections. I wonder if Sam Ravnborg responded to
> Segher's patch to extend make help?
I haven't seen any commentary on that at all. Sam is quite busy from
what I gather.
I'll try to poke at things today a bit and see if we can get an Ack
from him either way.
josh
^ permalink raw reply
* [PATCH] [POWERPC] Rework Book-E debug exception handling
From: Kumar Gala @ 2008-04-09 11:25 UTC (permalink / raw)
To: linuxppc-dev
The architecture allows for "Book-E" style debug interrupts to either go
to critial interrupts of their own debug interrupt level. To allow for
a dynamic kernel to support machines of either type we want to be able to
compile in the interrupt handling code for both exception levels.
Towards this goal we renamed the debug handling macros to specify the
interrupt level in their name (DEBUG_CRIT_EXCEPTION/DebugCrit and
DEBUG_DEBUG_EXCEPTION/DebugDebug).
Additionally, on the Freescale Book-e parts we expanded the exception
stacks to cover the maximum case of needing three exception stacks (normal,
machine check and debug).
There is some kernel text space optimization to be gained if a kernel is
configured for a specific Freescale implementation but we aren't handling
that now to allow for the single kernel image support.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Josh, can you test on 44x. I don't expect any harm since its just
renaming a few things.
arch/powerpc/kernel/head_44x.S | 4 ++--
arch/powerpc/kernel/head_booke.h | 33 ++++++++++++++++++++-------------
arch/powerpc/kernel/head_fsl_booke.S | 10 ++++++++--
3 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index ad071a1..b84ec6a 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -211,7 +211,7 @@ skpinv: addi r4,r4,1 /* Increment */
SET_IVOR(12, WatchdogTimer);
SET_IVOR(13, DataTLBError);
SET_IVOR(14, InstructionTLBError);
- SET_IVOR(15, Debug);
+ SET_IVOR(15, DebugCrit);
/* Establish the interrupt vector base */
lis r4,interrupt_base@h /* IVPR only uses the high 16-bits */
@@ -578,7 +578,7 @@ interrupt_base:
b InstructionStorage
/* Debug Interrupt */
- DEBUG_EXCEPTION
+ DEBUG_CRIT_EXCEPTION
/*
* Local functions
diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index ba9393f..aefafc6 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -56,8 +56,17 @@
* is necessary since the MMU is always on, for Book-E parts, and the stacks
* are offset from KERNELBASE.
*
+ * There is some space optimization to be had here if desired. However
+ * to allow for a common kernel with support for debug exceptions either
+ * going to critical or their own debug level we aren't currently
+ * providing configurations that micro-optimize space usage.
*/
-#define BOOKE_EXCEPTION_STACK_SIZE (8192)
+#ifdef CONFIG_44x
+#define NUM_EXCEPTION_LVLS 2
+#else
+#define NUM_EXCEPTION_LVLS 3
+#endif
+#define BOOKE_EXCEPTION_STACK_SIZE (4096 * NUM_EXCEPTION_LVLS)
/* CRIT_SPRG only used in critical exception handling */
#define CRIT_SPRG SPRN_SPRG2
@@ -68,7 +77,7 @@
#define CRIT_STACK_TOP (exception_stack_top)
/* only on e200 for now */
-#define DEBUG_STACK_TOP (exception_stack_top - 4096)
+#define DEBUG_STACK_TOP (exception_stack_top - 8192)
#define DEBUG_SPRG SPRN_SPRG6W
#ifdef CONFIG_SMP
@@ -212,9 +221,8 @@ label:
* save (and later restore) the MSR via SPRN_CSRR1, which will still have
* the MSR_DE bit set.
*/
-#ifdef CONFIG_E200
-#define DEBUG_EXCEPTION \
- START_EXCEPTION(Debug); \
+#define DEBUG_DEBUG_EXCEPTION \
+ START_EXCEPTION(DebugDebug); \
DEBUG_EXCEPTION_PROLOG; \
\
/* \
@@ -234,8 +242,8 @@ label:
cmplw r12,r10; \
blt+ 2f; /* addr below exception vectors */ \
\
- lis r10,Debug@h; \
- ori r10,r10,Debug@l; \
+ lis r10,DebugDebug@h; \
+ ori r10,r10,DebugDebug@l; \
cmplw r12,r10; \
bgt+ 2f; /* addr above exception vectors */ \
\
@@ -265,9 +273,9 @@ label:
2: mfspr r4,SPRN_DBSR; \
addi r3,r1,STACK_FRAME_OVERHEAD; \
EXC_XFER_TEMPLATE(DebugException, 0x2002, (MSR_KERNEL & ~(MSR_ME|MSR_DE|MSR_CE)), NOCOPY, debug_transfer_to_handler, ret_from_debug_exc)
-#else
-#define DEBUG_EXCEPTION \
- START_EXCEPTION(Debug); \
+
+#define DEBUG_CRIT_EXCEPTION \
+ START_EXCEPTION(DebugCrit); \
CRITICAL_EXCEPTION_PROLOG; \
\
/* \
@@ -287,8 +295,8 @@ label:
cmplw r12,r10; \
blt+ 2f; /* addr below exception vectors */ \
\
- lis r10,Debug@h; \
- ori r10,r10,Debug@l; \
+ lis r10,DebugCrit@h; \
+ ori r10,r10,DebugCrit@l; \
cmplw r12,r10; \
bgt+ 2f; /* addr above exception vectors */ \
\
@@ -318,7 +326,6 @@ label:
2: mfspr r4,SPRN_DBSR; \
addi r3,r1,STACK_FRAME_OVERHEAD; \
EXC_XFER_TEMPLATE(DebugException, 0x2002, (MSR_KERNEL & ~(MSR_ME|MSR_DE|MSR_CE)), NOCOPY, crit_transfer_to_handler, ret_from_crit_exc)
-#endif
#define INSTRUCTION_STORAGE_EXCEPTION \
START_EXCEPTION(InstructionStorage) \
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index d9cc2c2..92bf2cc 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -283,7 +283,10 @@ skpinv: addi r6,r6,1 /* Increment */
SET_IVOR(12, WatchdogTimer);
SET_IVOR(13, DataTLBError);
SET_IVOR(14, InstructionTLBError);
- SET_IVOR(15, Debug);
+ SET_IVOR(15, DebugDebug);
+#if defined(CONFIG_E500)
+ SET_IVOR(15, DebugCrit);
+#endif
SET_IVOR(32, SPEUnavailable);
SET_IVOR(33, SPEFloatingPointData);
SET_IVOR(34, SPEFloatingPointRound);
@@ -718,7 +721,10 @@ interrupt_base:
/* Debug Interrupt */
- DEBUG_EXCEPTION
+ DEBUG_DEBUG_EXCEPTION
+#if defined(CONFIG_E500)
+ DEBUG_CRIT_EXCEPTION
+#endif
/*
* Local functions
--
1.5.4.1
^ permalink raw reply related
* Re: [PATCH] Freescale QUICC Engine USB Host Controller
From: Laurent Pinchart @ 2008-04-09 12:13 UTC (permalink / raw)
To: avorontsov
Cc: Scott Wood, linuxppc-dev, linux-usb, David Brownell, Timur Tabi
In-Reply-To: <20080408121630.GB26716@polina.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 2900 bytes --]
On Tuesday 08 April 2008 14:16, Anton Vorontsov wrote:
> On Mon, Apr 07, 2008 at 06:11:15PM +0200, Laurent Pinchart wrote:
> [...]
> > I had a first go at hacking the FHCI driver to make it run on a CPM2
> > platform. Results so far are quite good. After getting rid of qe-specific
> > APIs as explained above, and adding SOF token generation support, I've
> > been able to access a mass storage device. The driver hasn't been
> > stress-tested yet though.
>
> Wow, awesome! That's great news, really. Looking forward for the patch. :-)
The current version of the code is CPM2-specific and won't work on QE-based
platforms. Should I still post it ?
> > I ran into an issue with IDLE and RESET interrupts. When the device is
> > first plugged into the USB port, the idle interrupt kicks in and the
> > driver detects the device properly. When the device is then removed, the
> > reset interrupt is generated and the driver handles device removal
> > properly. Right after the reset interrupt, idle interrupts are generated
> > every milliseconds for around 175ms. The status register always reports a
> > non-idle condition when read in the interrupt handler. The flow of idle
> > interrupts then stops, and no idle interrupt is generated when I replug
> > the device. I've checked the interrupts mask register to make sure idle
> > interrupts were enabled.
> >
> > Have you noticed a similar behaviour when you tested the driver on your
> > QE-based platform ? I suspected a debouncing issue, but I should then get
> > idle conditions once every other time when reading the status register.
>
> Hm.. nope, I didn't see anything like that, at least not something that
> is affecting the driver functionality. Did out_be16(tmr->gtevr, 0xFFFF);
> help there? Or it's different problem?
No it didn't, it's a completely different problem.
The IDLE interrupts I see every millisecond for around 175ms after
disconnecting the device are probably due to the SOF tokens sent between
device disconnection and the fhci_stop_sof_timer() call. Calling
fhci_stop_sof_timer() in device_disconnected_interrupt() prevents spurious
idle interrupts from being generated.
After further investigation I found out why no idle interrupt were generated
when replugging the device. Upon disconnection the FHCI driver turns bus
power off by setting the suspend GPIO pin high. As the signal is connected to
the suspend input of the USB phy on my hardware, setting the signal high
turned the phy off, disconnecting the RP and RN signals completely.
I solved the issue by referencing the bus power control GPIO instead of the
suspend GPIO in the device tree. GPIO_SUSPN should really be renamed
GPIO_POWER.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Freescale QUICC Engine USB Host Controller
From: Laurent Pinchart @ 2008-04-09 12:20 UTC (permalink / raw)
To: Pandita, Vikram
Cc: linux-usb, David Brownell, linuxppc-dev, Scott Wood, Timur Tabi
In-Reply-To: <5DF83221BE20114E9C331F665ACBC080048F8760@dbde01.ent.ti.com>
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]
On Wednesday 09 April 2008 14:16, Pandita, Vikram wrote:
> What does QUICC stand for?
QUICC stands for QUad Integrated Communications Controller.
http://en.wikipedia.org/wiki/PowerQUICC
> Am getting confused with SmartCard UICC. Is it anyway related?
They are not related.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: [PATCH] Freescale QUICC Engine USB Host Controller
From: Pandita, Vikram @ 2008-04-09 12:16 UTC (permalink / raw)
To: Laurent Pinchart, avorontsov
Cc: Scott Wood, linuxppc-dev, linux-usb, David Brownell, Timur Tabi
In-Reply-To: <200804091413.46592.laurentp@cse-semaphore.com>
V2hhdCBkb2VzIFFVSUNDIHN0YW5kIGZvcj8gDQpBbSBnZXR0aW5nIGNvbmZ1c2VkIHdpdGggU21h
cnRDYXJkIFVJQ0MuIElzIGl0IGFueXdheSByZWxhdGVkPyANCg0KPi0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQo+RnJvbTogbGludXgtdXNiLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRv
OmxpbnV4LXVzYi1vd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uIEJlaGFsZiBPZiBMYXVyZW50DQo+
UGluY2hhcnQNCj5TZW50OiBXZWRuZXNkYXksIEFwcmlsIDA5LCAyMDA4IDU6NDQgUE0NCj5Ubzog
YXZvcm9udHNvdkBydS5tdmlzdGEuY29tDQo+Q2M6IGxpbnV4cHBjLWRldkBvemxhYnMub3JnOyBs
aW51eC11c2JAdmdlci5rZXJuZWwub3JnOyBUaW11ciBUYWJpOyBTY290dCBXb29kOyBEYXZpZCBC
cm93bmVsbA0KPlN1YmplY3Q6IFJlOiBbUEFUQ0hdIEZyZWVzY2FsZSBRVUlDQyBFbmdpbmUgVVNC
IEhvc3QgQ29udHJvbGxlcg0KPg0KPk9uIFR1ZXNkYXkgMDggQXByaWwgMjAwOCAxNDoxNiwgQW50
b24gVm9yb250c292IHdyb3RlOg0KPj4gT24gTW9uLCBBcHIgMDcsIDIwMDggYXQgMDY6MTE6MTVQ
TSArMDIwMCwgTGF1cmVudCBQaW5jaGFydCB3cm90ZToNCj4+IFsuLi5dDQo+PiA+IEkgaGFkIGEg
Zmlyc3QgZ28gYXQgaGFja2luZyB0aGUgRkhDSSBkcml2ZXIgdG8gbWFrZSBpdCBydW4gb24gYSBD
UE0yDQo+PiA+IHBsYXRmb3JtLiBSZXN1bHRzIHNvIGZhciBhcmUgcXVpdGUgZ29vZC4gQWZ0ZXIg
Z2V0dGluZyByaWQgb2YgcWUtc3BlY2lmaWMNCj4+ID4gQVBJcyBhcyBleHBsYWluZWQgYWJvdmUs
IGFuZCBhZGRpbmcgU09GIHRva2VuIGdlbmVyYXRpb24gc3VwcG9ydCwgSSd2ZQ0KPj4gPiBiZWVu
IGFibGUgdG8gYWNjZXNzIGEgbWFzcyBzdG9yYWdlIGRldmljZS4gVGhlIGRyaXZlciBoYXNuJ3Qg
YmVlbg0KPj4gPiBzdHJlc3MtdGVzdGVkIHlldCB0aG91Z2guDQo+Pg0KPj4gV293LCBhd2Vzb21l
ISBUaGF0J3MgZ3JlYXQgbmV3cywgcmVhbGx5LiBMb29raW5nIGZvcndhcmQgZm9yIHRoZSBwYXRj
aC4gOi0pDQo+DQo+VGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgY29kZSBpcyBDUE0yLXNwZWNp
ZmljIGFuZCB3b24ndCB3b3JrIG9uIFFFLWJhc2VkDQo+cGxhdGZvcm1zLiBTaG91bGQgSSBzdGls
bCBwb3N0IGl0ID8NCj4NCj4+ID4gSSByYW4gaW50byBhbiBpc3N1ZSB3aXRoIElETEUgYW5kIFJF
U0VUIGludGVycnVwdHMuIFdoZW4gdGhlIGRldmljZSBpcw0KPj4gPiBmaXJzdCBwbHVnZ2VkIGlu
dG8gdGhlIFVTQiBwb3J0LCB0aGUgaWRsZSBpbnRlcnJ1cHQga2lja3MgaW4gYW5kIHRoZQ0KPj4g
PiBkcml2ZXIgZGV0ZWN0cyB0aGUgZGV2aWNlIHByb3Blcmx5LiBXaGVuIHRoZSBkZXZpY2UgaXMg
dGhlbiByZW1vdmVkLCB0aGUNCj4+ID4gcmVzZXQgaW50ZXJydXB0IGlzIGdlbmVyYXRlZCBhbmQg
dGhlIGRyaXZlciBoYW5kbGVzIGRldmljZSByZW1vdmFsDQo+PiA+IHByb3Blcmx5LiBSaWdodCBh
ZnRlciB0aGUgcmVzZXQgaW50ZXJydXB0LCBpZGxlIGludGVycnVwdHMgYXJlIGdlbmVyYXRlZA0K
Pj4gPiBldmVyeSBtaWxsaXNlY29uZHMgZm9yIGFyb3VuZCAxNzVtcy4gVGhlIHN0YXR1cyByZWdp
c3RlciBhbHdheXMgcmVwb3J0cyBhDQo+PiA+IG5vbi1pZGxlIGNvbmRpdGlvbiB3aGVuIHJlYWQg
aW4gdGhlIGludGVycnVwdCBoYW5kbGVyLiBUaGUgZmxvdyBvZiBpZGxlDQo+PiA+IGludGVycnVw
dHMgdGhlbiBzdG9wcywgYW5kIG5vIGlkbGUgaW50ZXJydXB0IGlzIGdlbmVyYXRlZCB3aGVuIEkg
cmVwbHVnDQo+PiA+IHRoZSBkZXZpY2UuIEkndmUgY2hlY2tlZCB0aGUgaW50ZXJydXB0cyBtYXNr
IHJlZ2lzdGVyIHRvIG1ha2Ugc3VyZSBpZGxlDQo+PiA+IGludGVycnVwdHMgd2VyZSBlbmFibGVk
Lg0KPj4gPg0KPj4gPiBIYXZlIHlvdSBub3RpY2VkIGEgc2ltaWxhciBiZWhhdmlvdXIgd2hlbiB5
b3UgdGVzdGVkIHRoZSBkcml2ZXIgb24geW91cg0KPj4gPiBRRS1iYXNlZCBwbGF0Zm9ybSA/IEkg
c3VzcGVjdGVkIGEgZGVib3VuY2luZyBpc3N1ZSwgYnV0IEkgc2hvdWxkIHRoZW4gZ2V0DQo+PiA+
IGlkbGUgY29uZGl0aW9ucyBvbmNlIGV2ZXJ5IG90aGVyIHRpbWUgd2hlbiByZWFkaW5nIHRoZSBz
dGF0dXMgcmVnaXN0ZXIuDQo+Pg0KPj4gSG0uLiBub3BlLCBJIGRpZG4ndCBzZWUgYW55dGhpbmcg
bGlrZSB0aGF0LCBhdCBsZWFzdCBub3Qgc29tZXRoaW5nIHRoYXQNCj4+IGlzIGFmZmVjdGluZyB0
aGUgZHJpdmVyIGZ1bmN0aW9uYWxpdHkuIERpZCBvdXRfYmUxNih0bXItPmd0ZXZyLCAweEZGRkYp
Ow0KPj4gaGVscCB0aGVyZT8gT3IgaXQncyBkaWZmZXJlbnQgcHJvYmxlbT8NCj4NCj5ObyBpdCBk
aWRuJ3QsIGl0J3MgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBwcm9ibGVtLg0KPg0KPlRoZSBJRExF
IGludGVycnVwdHMgSSBzZWUgZXZlcnkgbWlsbGlzZWNvbmQgZm9yIGFyb3VuZCAxNzVtcyBhZnRl
cg0KPmRpc2Nvbm5lY3RpbmcgdGhlIGRldmljZSBhcmUgcHJvYmFibHkgZHVlIHRvIHRoZSBTT0Yg
dG9rZW5zIHNlbnQgYmV0d2Vlbg0KPmRldmljZSBkaXNjb25uZWN0aW9uIGFuZCB0aGUgZmhjaV9z
dG9wX3NvZl90aW1lcigpIGNhbGwuIENhbGxpbmcNCj5maGNpX3N0b3Bfc29mX3RpbWVyKCkgaW4g
ZGV2aWNlX2Rpc2Nvbm5lY3RlZF9pbnRlcnJ1cHQoKSBwcmV2ZW50cyBzcHVyaW91cw0KPmlkbGUg
aW50ZXJydXB0cyBmcm9tIGJlaW5nIGdlbmVyYXRlZC4NCj4NCj5BZnRlciBmdXJ0aGVyIGludmVz
dGlnYXRpb24gSSBmb3VuZCBvdXQgd2h5IG5vIGlkbGUgaW50ZXJydXB0IHdlcmUgZ2VuZXJhdGVk
DQo+d2hlbiByZXBsdWdnaW5nIHRoZSBkZXZpY2UuIFVwb24gZGlzY29ubmVjdGlvbiB0aGUgRkhD
SSBkcml2ZXIgdHVybnMgYnVzDQo+cG93ZXIgb2ZmIGJ5IHNldHRpbmcgdGhlIHN1c3BlbmQgR1BJ
TyBwaW4gaGlnaC4gQXMgdGhlIHNpZ25hbCBpcyBjb25uZWN0ZWQgdG8NCj50aGUgc3VzcGVuZCBp
bnB1dCBvZiB0aGUgVVNCIHBoeSBvbiBteSBoYXJkd2FyZSwgc2V0dGluZyB0aGUgc2lnbmFsIGhp
Z2gNCj50dXJuZWQgdGhlIHBoeSBvZmYsIGRpc2Nvbm5lY3RpbmcgdGhlIFJQIGFuZCBSTiBzaWdu
YWxzIGNvbXBsZXRlbHkuDQo+DQo+SSBzb2x2ZWQgdGhlIGlzc3VlIGJ5IHJlZmVyZW5jaW5nIHRo
ZSBidXMgcG93ZXIgY29udHJvbCBHUElPIGluc3RlYWQgb2YgdGhlDQo+c3VzcGVuZCBHUElPIGlu
IHRoZSBkZXZpY2UgdHJlZS4gR1BJT19TVVNQTiBzaG91bGQgcmVhbGx5IGJlIHJlbmFtZWQNCj5H
UElPX1BPV0VSLg0KPg0KPi0tDQo+TGF1cmVudCBQaW5jaGFydA0KPkNTRSBTZW1hcGhvcmUgQmVs
Z2l1bQ0KPg0KPkNoYXVzc2VlIGRlIEJydXhlbGxlcywgNzMyQQ0KPkItMTQxMCBXYXRlcmxvbw0K
PkJlbGdpdW0NCj4NCj5UICszMiAoMikgMzg3IDQyIDU5DQo+RiArMzIgKDIpIDM4NyA0MiA3NQ0K
^ permalink raw reply
* Re: MPC8343 - "unable to handle paging request @ 0"
From: Andre Schwarz @ 2008-04-09 12:54 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080408164853.GH2552@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 8893 bytes --]
Scott Wood schrieb:
> On Tue, Apr 08, 2008 at 03:50:26PM +0200, Andre Schwarz wrote:
>
>> after building a debug kernel and attaching the bdi2000 it looks like
>> the crash occurs during "console_init()" ...
>>
>
> Does your device tree have a /chosen node after u-boot is done with it?
> find_legacy_serial_ports() can crash otherwise (we really should fix that).
>
>
>> Since we're using a dtb I omit the "console=..." argument for the
>> kernel. Is this correct ?
>>
>
> It's OK if you have /chosen/linux,stdout-path.
>
>
>> If "console=/dev/ttyS0,115200N8" argument is given the serial console
>> stops working after console_init....
>>
>>
>> On other PowerPC system I could see something like this during boot :
>>
>> -> find_legacy_serial_port()
>> stdout is /soc8568@e0000000/serial@4600
>> legacy_serial_console = 1
>> default console speed = 115340
>> <- find_legacy_serial_port()
>>
>>
>> Should I see this message also ?
>>
>
> Only if you enable debug messages in legacy_serial.c.
>
>
>> Have I misconfigured anything ?
>>
>
> One thing that sticks out from the above is that you ask for ttyS0, but the
> stdout you list from the other system corresponds to ttyS1. Is this just a
> difference between the two systems?
>
> -Scott
>
Scott,
I've added kallsyms and the #debug in legacy_serial.
Obviously there's missing something
-> see error "can't find stdout package /soc8343@e0000000/serial@4500 !"
below.
Can you help here ?
Thanks,
Andre
## Booting kernel from Legacy Image at ff810000 ...
Image Name: 2.6.25 mvBL-M7 MPC8343 #12
Image Type: PowerPC Linux Kernel Image (uncompressed)
Data Size: 2494236 Bytes = 2.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
## Flattened Device Tree blob at 00000000
Booting using the fdt blob at 0x600000
## Loading init Ramdisk from Legacy Image at 01000000 ...
Image Name: mvBC-1G uInitrd #1.1.03
Image Type: PowerPC Linux RAMDisk Image (uncompressed)
Data Size: 2654208 Bytes = 2.5 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 1fcb7000, end 1ff3f000 ... OK
-> early_init_devtree(c0600000)
search "chosen", depth: 0, uname:
search "chosen", depth: 1, uname: chosen
Looking for initrd properties... <3>initrd_start=0xdfcb7000
initrd_end=0xdff3f000
Command line is: root=/dev/ram ro rootfstype=squashfs
dt_root_size_cells = 1
dt_root_addr_cells = 1
memory scan node memory, reg size 8, data: 0 20000000 2 1,
- 0 , 20000000
reserving: 1fcb7000 -> 288001
Phys. mem: 20000000
-> move_device_tree
<- move_device_tree
Scanning CPUs ...
boot cpu: logical 0 physical 0
<- early_init_devtree()
Using mvBlueLYNX-M7 machine description
Linux version 2.6.25-rc8-01197-g1de15bb-dirty (root@nova) (gcc version
4.0.0 (DENX ELDK 4.1 4.0.0)) #12 PREEMPT Wed Apr 9 14:40:48 CEST 2008
-> unflatten_device_tree()
size is 192c, allocating...
unflattening dfffe6d0...
fixed up name for ->
fixed up name for chosen -> chosen
fixed up name for wdt@200 -> wdt
fixed up name for ethernet-phy@0 -> ethernet-phy
fixed up name for ethernet-phy@1 -> ethernet-phy
fixed up name for ethernet@24000 -> ethernet
fixed up name for ethernet@25000 -> ethernet
fixed up name for serial@4500 -> serial
fixed up name for serial@4600 -> serial
fixed up name for pic@700 -> pic
fixed up name for ppcboot_env@0 -> ppcboot_env
fixed up name for ppcboot_env_red@0x2000 -> ppcboot_env_red
fixed up name for u-boot_autoscript@0x4000 -> u-boot_autoscript
fixed up name for u-boot_autoscript_red@0x4000 -> u-boot_autoscript_red
fixed up name for dtb@0x8000 -> dtb
fixed up name for dtb_red@0xa000 -> dtb_red
fixed up name for kernel@0x10000 -> kernel
fixed up name for rfs@0x400000 -> rfs
fixed up name for u-boot@0x700000 -> u-boot
fixed up name for fpga@0x780000 -> fpga
<- unflatten_device_tree()
Found initrd at 0xdfcb7000:0xdff3f000
-> find_legacy_serial_port()
stdout is /soc8343@e0000000/serial@4500
legacy_serial_console = 0
default console speed = 115740
<- find_legacy_serial_port()
console [udbg0] enabled
setup_arch: bootmem
mvblm7_setup_arch()
arch: exit
Zone PFN ranges:
DMA 0 -> 131072
Normal 131072 -> 131072
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 131072
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048
Kernel command line: root=/dev/ram ro rootfstype=squashfs
PID hash table entries: 2048 (order: 11, 8192 bytes)
clocksource: timebase mult[3c00001] shift[22] registered
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-> check_legacy_serial_console()
can't find stdout package /soc8343@e0000000/serial@4500 !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 514048k/524288k available (2328k kernel code, 9676k reserved,
88k data, 126k bss, 140k init)
SLUB: Genslabs=12, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
Mount-cache hash table entries: 512
------------[ cut here ]------------
Badness at lib/kref.c:43
NIP: c00f5494 LR: c000d6b0 CTR: 00000000
REGS: c025de60 TRAP: 0700 Not tainted (2.6.25-rc8-01197-g1de15bb-dirty)
MSR: 00029032 <EE,ME,IR,DR> CR: 84000048 XER: 00000000
TASK = c0248510[0] 'swapper' THREAD: c025c000
GPR00: 00000001 c025df10 c0248510 dffff170 dffff050 00000009 df80fc6a
00000000
GPR08: 0007ffff 00000000 df80b990 c06011cf 24000042 5fffffff 1fffd000
00000000
GPR16: 1fffffff 9fffffff 00000000 00000000 1fff8910 1ff426f8 00000004
00288000
GPR24: 00000000 00000000 c02630a0 c0260000 dfffefa0 c025c000 dffff050
dffff13c
NIP [c00f5494] kref_get+0xc/0x24
LR [c000d6b0] of_node_get+0x20/0x38
Call Trace:
[c025df10] [c06011cf] 0xc06011cf (unreliable)
[c025df20] [c01571a4] of_get_next_child+0x40/0x9c
[c025df40] [c00bab5c] proc_device_tree_add_node+0x4c/0x144
[c025df60] [c00bab50] proc_device_tree_add_node+0x40/0x144
[c025df80] [c00bab50] proc_device_tree_add_node+0x40/0x144
[c025dfa0] [c00bacc8] proc_device_tree_init+0x74/0xa0
[c025dfb0] [c0235c70] proc_root_init+0xd4/0x10c
[c025dfc0] [c022374c] start_kernel+0x244/0x2cc
[c025dff0] [00003438] 0x3438
Instruction dump:
4bf289e1 7fa3eb78 3ba00000 4bfff3ad 4bffffd8 90830000 4e800020 38800001
4bfffff4 80030000 21200000 7c090114 <0f000000> 7d201828 31290001 7d20192d
WARNING: Bad of_node_put() on
Call Trace:
[c025ded0] [c00088fc] show_stack+0x50/0x190 (unreliable)
[c025df00] [c000de70] of_node_release+0xb0/0xcc
[c025df20] [c00f5500] kref_put+0x54/0x6c
[c025df30] [c000d6ec] of_node_put+0x24/0x34
[c025df40] [c00babc8] proc_device_tree_add_node+0xb8/0x144
[c025df60] [c00bab50] proc_device_tree_add_node+0x40/0x144
[c025df80] [c00bab50] proc_device_tree_add_node+0x40/0x144
[c025dfa0] [c00bacc8] proc_device_tree_init+0x74/0xa0
[c025dfb0] [c0235c70] proc_root_init+0xd4/0x10c
[c025dfc0] [c022374c] start_kernel+0x244/0x2cc
[c025dff0] [00003438] 0x3438
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc0014454
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT mvBlueLYNX-M7
Modules linked in:
NIP: c0014454 LR: c00ba9e0 CTR: 00000000
REGS: c025de70 TRAP: 0300 Not tainted (2.6.25-rc8-01197-g1de15bb-dirty)
MSR: 00009032 <EE,ME,IR,DR> CR: 44000048 XER: 00000000
DAR: 00000000, DSISR: 20000000
TASK = c0248510[0] 'swapper' THREAD: c025c000
GPR00: c00bac0c c025df20 c0248510 00000023 ffffffff df80fd60 df80fd6e
00000000
GPR08: 001fffff 00000002 df80b990 c06010f5 24000022 5fffffff 1fffd000
00000000
GPR16: 1fffffff 9fffffff 00000000 00000000 1fff8910 1ff426f8 00000004
00288000
GPR24: 00000000 00000000 c02630a0 c0260000 dfffefa0 00000000 c025c000
df80fd00
NIP [c0014454] strcmp+0x10/0x24
LR [c00ba9e0] duplicate_name+0x3c/0x94
Call Trace:
[c025df20] [c00ba870] __proc_device_tree_add_prop+0x54/0xd4 (unreliable)
[c025df40] [c00bac0c] proc_device_tree_add_node+0xfc/0x144
[c025df60] [c00bab50] proc_device_tree_add_node+0x40/0x144
[c025df80] [c00bab50] proc_device_tree_add_node+0x40/0x144
[c025dfa0] [c00bacc8] proc_device_tree_init+0x74/0xa0
[c025dfb0] [c0235c70] proc_root_init+0xd4/0x10c
[c025dfc0] [c022374c] start_kernel+0x244/0x2cc
[c025dff0] [00003438] 0x3438
Instruction dump:
2c000000 4082fff8 38a5ffff 8c040001 2c000000 9c050001 4082fff4 4e800020
38a3ffff 3884ffff 8c650001 2c830000 <8c040001> 7c601851 4d860020 4182ffec
---[ end trace 8640abe69a316dee ]---
Kernel panic - not syncing: Attempted to kill the idle task!
Rebooting in 180
seconds..
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
[-- Attachment #2: Type: text/html, Size: 11291 bytes --]
^ permalink raw reply
* [PATCH] FCC: fix confused base / offset
From: Sascha Hauer @ 2008-04-09 13:06 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
This patch fixes a mixup in struct fs_platform_info. The struct has a field
dpram_offset which really is no offset but an io pointer to the dpram
(casted to u32).
It also has a field mem_offset which is used as the offset from the dpram
to the fcc RAM but then in turn filled into fcc.mem (casted to void __iomem *)
This patch fixes this in the way that dpram_offset holds the offset to the
fcc dpram as the name suggests and the mem_offset field is renamed to mem of
type void __iomem *.
This way we get rid of some #ifdefs and type casts.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 2c5388c..578ced2 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -837,13 +837,13 @@ static int __init fs_enet_of_init(void)
int fcc_index = *id - 1;
const unsigned char *mdio_bb_prop;
- fs_enet_data.dpram_offset = (u32)cpm_dpram_addr(0);
+ fs_enet_data.dpram_offset = FCC_MEM_OFFSET(fcc_index);
fs_enet_data.rx_ring = 32;
fs_enet_data.tx_ring = 32;
fs_enet_data.rx_copybreak = 240;
fs_enet_data.use_napi = 0;
fs_enet_data.napi_weight = 17;
- fs_enet_data.mem_offset = FCC_MEM_OFFSET(fcc_index);
+ fs_enet_data.mem = cpm_dpram_addr(0);
fs_enet_data.cp_page = CPM_CR_FCC_PAGE(fcc_index);
fs_enet_data.cp_block = CPM_CR_FCC_SBLOCK(fcc_index);
diff --git a/drivers/net/fs_enet/mac-fcc.c b/drivers/net/fs_enet/mac-fcc.c
index e363211..1659ac7 100644
--- a/drivers/net/fs_enet/mac-fcc.c
+++ b/drivers/net/fs_enet/mac-fcc.c
@@ -157,7 +157,7 @@ out:
if (fep->fcc.fcccp == NULL)
return -EINVAL;
- fep->fcc.mem = (void __iomem *)fep->fpi->mem_offset;
+ fep->fcc.mem = fep->fpi->mem;
if (fep->fcc.mem == NULL)
return -EINVAL;
@@ -304,9 +304,6 @@ static void restart(struct net_device *dev)
fcc_enet_t __iomem *ep = fep->fcc.ep;
dma_addr_t rx_bd_base_phys, tx_bd_base_phys;
u16 paddrh, paddrm, paddrl;
-#ifndef CONFIG_PPC_CPM_NEW_BINDING
- u16 mem_addr;
-#endif
const unsigned char *mac;
int i;
@@ -338,19 +335,10 @@ static void restart(struct net_device *dev)
* this area.
*/
-#ifdef CONFIG_PPC_CPM_NEW_BINDING
W16(ep, fen_genfcc.fcc_riptr, fpi->dpram_offset);
W16(ep, fen_genfcc.fcc_tiptr, fpi->dpram_offset + 32);
W16(ep, fen_padptr, fpi->dpram_offset + 64);
-#else
- mem_addr = (u32) fep->fcc.mem; /* de-fixup dpram offset */
-
- W16(ep, fen_genfcc.fcc_riptr, (mem_addr & 0xffff));
- W16(ep, fen_genfcc.fcc_tiptr, ((mem_addr + 32) & 0xffff));
-
- W16(ep, fen_padptr, mem_addr + 64);
-#endif
/* fill with special symbol... */
memset_io(fep->fcc.mem + fpi->dpram_offset + 64, 0x88, 32);
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 9bc045b..70080a0 100644
--- a/include/linux/fs_enet_pd.h
+++ b/include/linux/fs_enet_pd.h
@@ -128,7 +128,7 @@ struct fs_platform_info {
u32 clk_route;
u32 clk_mask;
- u32 mem_offset;
+ void __iomem *mem;
u32 dpram_offset;
u32 fcc_regs_c;
--
Pengutronix e.K. - Linux Solutions for Science and Industry
-----------------------------------------------------------
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite -> http://www.pengutronix.de/impressum/ <-
^ permalink raw reply related
* Re: [PATCH v3] powerpc: Add irqtrace support for 32-bit powerpc
From: Johannes Berg @ 2008-04-08 21:36 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <1207670643.5550.11.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 586 bytes --]
> > This version fixes the clobbering of r12 by the call to
> > trace_hardirqs_off() that was pointed out by BenH.
> >
> > Johannes, I'd appreciate your trying this version if/when
> > you get the chance.
>
> Thanks Dale, this version seems to work. I'll stress it a bit more
> later, but so far it has survived *much* longer than both previous
> versions.
Hmm. Bad news. I got a crash in console_callback() again where
apparently r28 had a bogus value. That, however, doesn't make sense, so
maybe that register value was calculated from another register.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH] [POWERPC] mpc8315: fix USB UTMI Host setup
From: Anton Vorontsov @ 2008-04-09 13:59 UTC (permalink / raw)
To: linuxppc-dev
Currently USB Host isn't functional on the MPC8315E boards, for two
reasons as described below.
MPC8315 Reference Manual says:
"The USB DR unit must have the same clock ratio as the encryption core
unit, unless one of them has its clock disabled."
The encryption core also drives I2C clock, so it is enabled and is equal
to 01. That means USBDRCM should be 01 here.
Plus, according to MPC8315E-RDB schematics, USB unit consumes CLK_IN
clock from the 24.00MHz oscillator, which means we must adjust REFSEL
bits as well.
p.s.
Idially we should rework whole 83xx/usb.c code, in two steps:
1. Move SCCR code to the U-Boot;
2. Implement fsl,usb-clock property in the device tree, so usb.c could
decide what clock exactly to use on per-board basis.
Though, today we're not in a hurry since there is just one 8315e board
out there.
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/83xx/mpc83xx.h | 2 ++
arch/powerpc/platforms/83xx/usb.c | 12 +++++++++---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h b/arch/powerpc/platforms/83xx/mpc83xx.h
index 68065e6..88a3b5c 100644
--- a/arch/powerpc/platforms/83xx/mpc83xx.h
+++ b/arch/powerpc/platforms/83xx/mpc83xx.h
@@ -16,6 +16,7 @@
#define MPC83XX_SCCR_USB_DRCM_10 0x00200000
#define MPC8315_SCCR_USB_MASK 0x00c00000
#define MPC8315_SCCR_USB_DRCM_11 0x00c00000
+#define MPC8315_SCCR_USB_DRCM_01 0x00400000
#define MPC837X_SCCR_USB_DRCM_11 0x00c00000
/* system i/o configuration register low */
@@ -37,6 +38,7 @@
/* USB Control Register */
#define FSL_USB2_CONTROL_OFFS 0x500
#define CONTROL_UTMI_PHY_EN 0x00000200
+#define CONTROL_REFSEL_24MHZ 0x00000040
#define CONTROL_REFSEL_48MHZ 0x00000080
#define CONTROL_PHY_CLK_SEL_ULPI 0x00000400
#define CONTROL_OTG_PORT 0x00000020
diff --git a/arch/powerpc/platforms/83xx/usb.c b/arch/powerpc/platforms/83xx/usb.c
index 471fdd8..64bcf0a 100644
--- a/arch/powerpc/platforms/83xx/usb.c
+++ b/arch/powerpc/platforms/83xx/usb.c
@@ -129,7 +129,7 @@ int mpc831x_usb_cfg(void)
if (immr_node && of_device_is_compatible(immr_node, "fsl,mpc8315-immr"))
clrsetbits_be32(immap + MPC83XX_SCCR_OFFS,
MPC8315_SCCR_USB_MASK,
- MPC8315_SCCR_USB_DRCM_11);
+ MPC8315_SCCR_USB_DRCM_01);
else
clrsetbits_be32(immap + MPC83XX_SCCR_OFFS,
MPC83XX_SCCR_USB_MASK,
@@ -164,9 +164,15 @@ int mpc831x_usb_cfg(void)
/* Using on-chip PHY */
if (prop && (!strcmp(prop, "utmi_wide") ||
!strcmp(prop, "utmi"))) {
- /* Set UTMI_PHY_EN, REFSEL to 48MHZ */
+ u32 refsel;
+
+ if (of_device_is_compatible(immr_node, "fsl,mpc8315-immr"))
+ refsel = CONTROL_REFSEL_24MHZ;
+ else
+ refsel = CONTROL_REFSEL_48MHZ;
+ /* Set UTMI_PHY_EN and REFSEL */
out_be32(usb_regs + FSL_USB2_CONTROL_OFFS,
- CONTROL_UTMI_PHY_EN | CONTROL_REFSEL_48MHZ);
+ CONTROL_UTMI_PHY_EN | refsel);
/* Using external UPLI PHY */
} else if (prop && !strcmp(prop, "ulpi")) {
/* Set PHY_CLK_SEL to ULPI */
^ permalink raw reply related
* [PATCH] [POWERPC] 83xx/85xx: Reorganize defconfigs
From: Kumar Gala @ 2008-04-09 15:18 UTC (permalink / raw)
To: linuxppc-dev
Board specific defconfigs are useful, however with the ability to do
multi-board defconfigs they aren't needed in the top level configs directory
Move the 83xx/85xx board specific defconfigs to individual directories under
arch/powerpc/configs.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
.../configs/{ => 83xx}/mpc8313_rdb_defconfig | 0
.../configs/{ => 83xx}/mpc8315_rdb_defconfig | 0
.../configs/{ => 83xx}/mpc832x_mds_defconfig | 0
.../configs/{ => 83xx}/mpc832x_rdb_defconfig | 0
.../configs/{ => 83xx}/mpc834x_itx_defconfig | 0
.../configs/{ => 83xx}/mpc834x_itxgp_defconfig | 0
.../configs/{ => 83xx}/mpc834x_mds_defconfig | 0
.../configs/{ => 83xx}/mpc836x_mds_defconfig | 0
.../configs/{ => 83xx}/mpc837x_mds_defconfig | 0
.../configs/{ => 83xx}/mpc837x_rdb_defconfig | 0
arch/powerpc/configs/{ => 83xx}/sbc834x_defconfig | 0
arch/powerpc/configs/{ => 85xx}/ksi8560_defconfig | 0
.../configs/{ => 85xx}/mpc8540_ads_defconfig | 0
.../configs/{ => 85xx}/mpc8544_ds_defconfig | 0
.../configs/{ => 85xx}/mpc8560_ads_defconfig | 0
.../configs/{ => 85xx}/mpc8568mds_defconfig | 0
.../configs/{ => 85xx}/mpc8572_ds_defconfig | 0
.../configs/{ => 85xx}/mpc85xx_cds_defconfig | 0
arch/powerpc/configs/{ => 85xx}/sbc8548_defconfig | 0
arch/powerpc/configs/{ => 85xx}/sbc8560_defconfig | 0
arch/powerpc/configs/{ => 85xx}/stx_gp3_defconfig | 0
arch/powerpc/configs/{ => 85xx}/tqm8540_defconfig | 0
arch/powerpc/configs/{ => 85xx}/tqm8541_defconfig | 0
arch/powerpc/configs/{ => 85xx}/tqm8555_defconfig | 0
arch/powerpc/configs/{ => 85xx}/tqm8560_defconfig | 0
25 files changed, 0 insertions(+), 0 deletions(-)
rename arch/powerpc/configs/{ => 83xx}/mpc8313_rdb_defconfig (100%)
rename arch/powerpc/configs/{ => 83xx}/mpc8315_rdb_defconfig (100%)
rename arch/powerpc/configs/{ => 83xx}/mpc832x_mds_defconfig (100%)
rename arch/powerpc/configs/{ => 83xx}/mpc832x_rdb_defconfig (100%)
rename arch/powerpc/configs/{ => 83xx}/mpc834x_itx_defconfig (100%)
rename arch/powerpc/configs/{ => 83xx}/mpc834x_itxgp_defconfig (100%)
rename arch/powerpc/configs/{ => 83xx}/mpc834x_mds_defconfig (100%)
rename arch/powerpc/configs/{ => 83xx}/mpc836x_mds_defconfig (100%)
rename arch/powerpc/configs/{ => 83xx}/mpc837x_mds_defconfig (100%)
rename arch/powerpc/configs/{ => 83xx}/mpc837x_rdb_defconfig (100%)
rename arch/powerpc/configs/{ => 83xx}/sbc834x_defconfig (100%)
rename arch/powerpc/configs/{ => 85xx}/ksi8560_defconfig (100%)
rename arch/powerpc/configs/{ => 85xx}/mpc8540_ads_defconfig (100%)
rename arch/powerpc/configs/{ => 85xx}/mpc8544_ds_defconfig (100%)
rename arch/powerpc/configs/{ => 85xx}/mpc8560_ads_defconfig (100%)
rename arch/powerpc/configs/{ => 85xx}/mpc8568mds_defconfig (100%)
rename arch/powerpc/configs/{ => 85xx}/mpc8572_ds_defconfig (100%)
rename arch/powerpc/configs/{ => 85xx}/mpc85xx_cds_defconfig (100%)
rename arch/powerpc/configs/{ => 85xx}/sbc8548_defconfig (100%)
rename arch/powerpc/configs/{ => 85xx}/sbc8560_defconfig (100%)
rename arch/powerpc/configs/{ => 85xx}/stx_gp3_defconfig (100%)
rename arch/powerpc/configs/{ => 85xx}/tqm8540_defconfig (100%)
rename arch/powerpc/configs/{ => 85xx}/tqm8541_defconfig (100%)
rename arch/powerpc/configs/{ => 85xx}/tqm8555_defconfig (100%)
rename arch/powerpc/configs/{ => 85xx}/tqm8560_defconfig (100%)
diff --git a/arch/powerpc/configs/mpc8313_rdb_defconfig b/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig
similarity index 100%
rename from arch/powerpc/configs/mpc8313_rdb_defconfig
rename to arch/powerpc/configs/83xx/mpc8313_rdb_defconfig
diff --git a/arch/powerpc/configs/mpc8315_rdb_defconfig b/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig
similarity index 100%
rename from arch/powerpc/configs/mpc8315_rdb_defconfig
rename to arch/powerpc/configs/83xx/mpc8315_rdb_defconfig
diff --git a/arch/powerpc/configs/mpc832x_mds_defconfig b/arch/powerpc/configs/83xx/mpc832x_mds_defconfig
similarity index 100%
rename from arch/powerpc/configs/mpc832x_mds_defconfig
rename to arch/powerpc/configs/83xx/mpc832x_mds_defconfig
diff --git a/arch/powerpc/configs/mpc832x_rdb_defconfig b/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig
similarity index 100%
rename from arch/powerpc/configs/mpc832x_rdb_defconfig
rename to arch/powerpc/configs/83xx/mpc832x_rdb_defconfig
diff --git a/arch/powerpc/configs/mpc834x_itx_defconfig b/arch/powerpc/configs/83xx/mpc834x_itx_defconfig
similarity index 100%
rename from arch/powerpc/configs/mpc834x_itx_defconfig
rename to arch/powerpc/configs/83xx/mpc834x_itx_defconfig
diff --git a/arch/powerpc/configs/mpc834x_itxgp_defconfig b/arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig
similarity index 100%
rename from arch/powerpc/configs/mpc834x_itxgp_defconfig
rename to arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig
diff --git a/arch/powerpc/configs/mpc834x_mds_defconfig b/arch/powerpc/configs/83xx/mpc834x_mds_defconfig
similarity index 100%
rename from arch/powerpc/configs/mpc834x_mds_defconfig
rename to arch/powerpc/configs/83xx/mpc834x_mds_defconfig
diff --git a/arch/powerpc/configs/mpc836x_mds_defconfig b/arch/powerpc/configs/83xx/mpc836x_mds_defconfig
similarity index 100%
rename from arch/powerpc/configs/mpc836x_mds_defconfig
rename to arch/powerpc/configs/83xx/mpc836x_mds_defconfig
diff --git a/arch/powerpc/configs/mpc837x_mds_defconfig b/arch/powerpc/configs/83xx/mpc837x_mds_defconfig
similarity index 100%
rename from arch/powerpc/configs/mpc837x_mds_defconfig
rename to arch/powerpc/configs/83xx/mpc837x_mds_defconfig
diff --git a/arch/powerpc/configs/mpc837x_rdb_defconfig b/arch/powerpc/configs/83xx/mpc837x_rdb_defconfig
similarity index 100%
rename from arch/powerpc/configs/mpc837x_rdb_defconfig
rename to arch/powerpc/configs/83xx/mpc837x_rdb_defconfig
diff --git a/arch/powerpc/configs/sbc834x_defconfig b/arch/powerpc/configs/83xx/sbc834x_defconfig
similarity index 100%
rename from arch/powerpc/configs/sbc834x_defconfig
rename to arch/powerpc/configs/83xx/sbc834x_defconfig
diff --git a/arch/powerpc/configs/ksi8560_defconfig b/arch/powerpc/configs/85xx/ksi8560_defconfig
similarity index 100%
rename from arch/powerpc/configs/ksi8560_defconfig
rename to arch/powerpc/configs/85xx/ksi8560_defconfig
diff --git a/arch/powerpc/configs/mpc8540_ads_defconfig b/arch/powerpc/configs/85xx/mpc8540_ads_defconfig
similarity index 100%
rename from arch/powerpc/configs/mpc8540_ads_defconfig
rename to arch/powerpc/configs/85xx/mpc8540_ads_defconfig
diff --git a/arch/powerpc/configs/mpc8544_ds_defconfig b/arch/powerpc/configs/85xx/mpc8544_ds_defconfig
similarity index 100%
rename from arch/powerpc/configs/mpc8544_ds_defconfig
rename to arch/powerpc/configs/85xx/mpc8544_ds_defconfig
diff --git a/arch/powerpc/configs/mpc8560_ads_defconfig b/arch/powerpc/configs/85xx/mpc8560_ads_defconfig
similarity index 100%
rename from arch/powerpc/configs/mpc8560_ads_defconfig
rename to arch/powerpc/configs/85xx/mpc8560_ads_defconfig
diff --git a/arch/powerpc/configs/mpc8568mds_defconfig b/arch/powerpc/configs/85xx/mpc8568mds_defconfig
similarity index 100%
rename from arch/powerpc/configs/mpc8568mds_defconfig
rename to arch/powerpc/configs/85xx/mpc8568mds_defconfig
diff --git a/arch/powerpc/configs/mpc8572_ds_defconfig b/arch/powerpc/configs/85xx/mpc8572_ds_defconfig
similarity index 100%
rename from arch/powerpc/configs/mpc8572_ds_defconfig
rename to arch/powerpc/configs/85xx/mpc8572_ds_defconfig
diff --git a/arch/powerpc/configs/mpc85xx_cds_defconfig b/arch/powerpc/configs/85xx/mpc85xx_cds_defconfig
similarity index 100%
rename from arch/powerpc/configs/mpc85xx_cds_defconfig
rename to arch/powerpc/configs/85xx/mpc85xx_cds_defconfig
diff --git a/arch/powerpc/configs/sbc8548_defconfig b/arch/powerpc/configs/85xx/sbc8548_defconfig
similarity index 100%
rename from arch/powerpc/configs/sbc8548_defconfig
rename to arch/powerpc/configs/85xx/sbc8548_defconfig
diff --git a/arch/powerpc/configs/sbc8560_defconfig b/arch/powerpc/configs/85xx/sbc8560_defconfig
similarity index 100%
rename from arch/powerpc/configs/sbc8560_defconfig
rename to arch/powerpc/configs/85xx/sbc8560_defconfig
diff --git a/arch/powerpc/configs/stx_gp3_defconfig b/arch/powerpc/configs/85xx/stx_gp3_defconfig
similarity index 100%
rename from arch/powerpc/configs/stx_gp3_defconfig
rename to arch/powerpc/configs/85xx/stx_gp3_defconfig
diff --git a/arch/powerpc/configs/tqm8540_defconfig b/arch/powerpc/configs/85xx/tqm8540_defconfig
similarity index 100%
rename from arch/powerpc/configs/tqm8540_defconfig
rename to arch/powerpc/configs/85xx/tqm8540_defconfig
diff --git a/arch/powerpc/configs/tqm8541_defconfig b/arch/powerpc/configs/85xx/tqm8541_defconfig
similarity index 100%
rename from arch/powerpc/configs/tqm8541_defconfig
rename to arch/powerpc/configs/85xx/tqm8541_defconfig
diff --git a/arch/powerpc/configs/tqm8555_defconfig b/arch/powerpc/configs/85xx/tqm8555_defconfig
similarity index 100%
rename from arch/powerpc/configs/tqm8555_defconfig
rename to arch/powerpc/configs/85xx/tqm8555_defconfig
diff --git a/arch/powerpc/configs/tqm8560_defconfig b/arch/powerpc/configs/85xx/tqm8560_defconfig
similarity index 100%
rename from arch/powerpc/configs/tqm8560_defconfig
rename to arch/powerpc/configs/85xx/tqm8560_defconfig
--
1.5.4.1
^ permalink raw reply
* Re: [PATCH] [POWERPC] 83xx/85xx: Reorganize defconfigs
From: Grant Likely @ 2008-04-09 15:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0804091017440.18753@blarg.am.freescale.net>
On Wed, Apr 9, 2008 at 9:18 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> Board specific defconfigs are useful, however with the ability to do
> multi-board defconfigs they aren't needed in the top level configs directory
>
> Move the 83xx/85xx board specific defconfigs to individual directories under
> arch/powerpc/configs.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] [POWERPC] 83xx/85xx: Reorganize defconfigs
From: Kumar Gala @ 2008-04-09 15:27 UTC (permalink / raw)
To: Wood Scott; +Cc: ppc-dev list
In-Reply-To: <fa686aa40804090826j1cd5c9c2t3bd95eeb9e356a48@mail.gmail.com>
On Apr 9, 2008, at 10:26 AM, Grant Likely wrote:
> On Wed, Apr 9, 2008 at 9:18 AM, Kumar Gala
> <galak@kernel.crashing.org> wrote:
>> Board specific defconfigs are useful, however with the ability to do
>> multi-board defconfigs they aren't needed in the top level configs
>> directory
>>
>> Move the 83xx/85xx board specific defconfigs to individual
>> directories under
>> arch/powerpc/configs.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Scott is 8xx capable of having a generic defconfig such that we can
build a single kernel image that will run on the various boards?
- k
^ permalink raw reply
* Re: 4xx defconfig reorg
From: Segher Boessenkool @ 2008-04-09 15:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18428.24729.933714.665889@cargo.ozlabs.ibm.com>
>> I've not heard any objections. I'll be pushing my commit to my next
>> branch tomorrow morning.
>
> I don't have any objections. I wonder if Sam Ravnborg responded to
> Segher's patch to extend make help?
I haven't had a reply to that yet, from anyone. IIRC Sam send a
mail some time ago saying he wouldn't have much time for kbuild
in the future. I just now see there is a mailing list for kbuild
as well, I'll forward the patch to there. If nothing happens, can
you pick up the patch? I've tested it on all architectures that
build on mainline.
Segher
^ permalink raw reply
* Re: [PATCH] [POWERPC] 83xx/85xx: Reorganize defconfigs
From: Scott Wood @ 2008-04-09 16:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppc-dev list
In-Reply-To: <9258E8EF-27DF-44C4-BF73-335D9EB5DD7A@kernel.crashing.org>
On Wed, Apr 09, 2008 at 10:27:04AM -0500, Kumar Gala wrote:
> Scott is 8xx capable of having a generic defconfig such that we can
> build a single kernel image that will run on the various boards?
It should be.
-Scott
^ permalink raw reply
* Re: [PATCH] FCC: fix confused base / offset
From: Scott Wood @ 2008-04-09 16:11 UTC (permalink / raw)
To: Sascha Hauer; +Cc: linuxppc-dev
In-Reply-To: <20080409130610.GE10465@pengutronix.de>
On Wed, Apr 09, 2008 at 03:06:10PM +0200, Sascha Hauer wrote:
> This patch fixes a mixup in struct fs_platform_info. The struct has a field
> dpram_offset which really is no offset but an io pointer to the dpram
> (casted to u32).
Right, I didn't want to touch that as the old-binding code should be
going away soon anyway. Does this break arch/ppc, BTW?
-Scott
^ permalink raw reply
* Re: Question on mpc52xx_common.c
From: Matt Sealey @ 2008-04-09 16:46 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <29c98f1cd48092a67f9c7e431063e656@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
On Tue, Apr 8, 2008 at 10:51 PM, Segher Boessenkool <
segher@kernel.crashing.org> wrote:
>
> Let's flat out refuse any patch series that uses a non-documented
> binding.
>
I would love this, it makes life easier, but let's make sure that the
documented binding is actually
fairly future proof, first, and not going to cause a billion problems
further down the line when kernels
and device trees diverge in their implementation/requirements as the
MPC5200B ethernet driver
has.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
[-- Attachment #2: Type: text/html, Size: 883 bytes --]
^ permalink raw reply
* Re: [PATCH] FCC: fix confused base / offset
From: Sascha Hauer @ 2008-04-09 16:53 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080409161110.GA5296@ld0162-tx32.am.freescale.net>
On Wed, Apr 09, 2008 at 11:11:10AM -0500, Scott Wood wrote:
> On Wed, Apr 09, 2008 at 03:06:10PM +0200, Sascha Hauer wrote:
> > This patch fixes a mixup in struct fs_platform_info. The struct has a field
> > dpram_offset which really is no offset but an io pointer to the dpram
> > (casted to u32).
>
> Right, I didn't want to touch that as the old-binding code should be
> going away soon anyway.
Right, so it's probably not worth the effort. I stumbled on this while
porting my board to the new binding code. I was quite confused when
seeing this so I made this fix to understand what's going on here.
BTW have you tested the FCC driver with the new binding code? I do not
manage to get it working. Everything seems to be fine but
fs_enet_start_xmit does not send a packet and no interrupts are
arriving.
> Does this break arch/ppc, BTW?
Yes. arch=ppc is out of my scope, so I forget about it regularly, sorry.
It breaks arch/ppc/platforms/mpc8272ads_setup.c which can be easily
fixed though. But as the mpc8272ads is supported with arch=powerpc,
shouldn't it go away anyway?
Sascha
--
Pengutronix e.K. - Linux Solutions for Science and Industry
-----------------------------------------------------------
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite -> http://www.pengutronix.de/impressum/ <-
^ permalink raw reply
* Re: [PATCH] pseries: phyp dump: Variable size reserve space.
From: Manish Ahuja @ 2008-04-09 17:32 UTC (permalink / raw)
To: Olof Johansson; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <20080408024352.GA32761@lixom.net>
Olof Johansson wrote:
> These make for some really long variable names and lines. I know from
> experience, since I've picked unneccessary long driver names in the past
> myself. :)
>
> How about just naming the new variables reserve_bootvar, etc? The name
> of the struct they're in makes it obvious what they're for.
>
Yeah, I guess thats a good suggestion. Will truncate it.
>
>> +static inline unsigned long phyp_dump_calculate_reserve_size(void)
>> +{
>> + unsigned long tmp;
>> +
>> + if (phyp_dump_info->phyp_dump_reserve_bootvar)
>> + return phyp_dump_info->phyp_dump_reserve_bootvar;
>> +
>> + /* divide by 20 to get 5% of value */
>> + tmp = lmb_end_of_DRAM();
>> + do_div(tmp, 20);
>> +
>> + /* round it down in multiples of 256 */
>> + tmp = tmp & ~0x000000001FFFFFFF;
>
> That's 512MB, isn't it?
>
No, its 5 % of memory and then rounded down to 256 MB multiples.
so if you 4GB its 256MB.
if you have 8 GB its 512 MB etc.
>
> -Olof
^ permalink raw reply
* Re: [PATCH] pseries: phyp dump: Variable size reserve space.
From: Manish Ahuja @ 2008-04-09 17:37 UTC (permalink / raw)
To: Olof Johansson; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <20080408024352.GA32761@lixom.net>
Olof Johansson wrote:
>> +static inline unsigned long phyp_dump_calculate_reserve_size(void)
>> +{
>> + unsigned long tmp;
>> +
>> + if (phyp_dump_info->phyp_dump_reserve_bootvar)
>> + return phyp_dump_info->phyp_dump_reserve_bootvar;
>> +
>> + /* divide by 20 to get 5% of value */
>> + tmp = lmb_end_of_DRAM();
>> + do_div(tmp, 20);
>> +
>> + /* round it down in multiples of 256 */
>> + tmp = tmp & ~0x000000001FFFFFFF;
>
> That's 512MB, isn't it?
My calculations in the example I gave in the last email were wrong.
In mentally did 10% instead of 5%. But the premise is same.
So assuming 5% of some memory is 400 MB, it rounds it down to 256MB etc.
^ permalink raw reply
* Re: [PATCH] FCC: fix confused base / offset
From: Scott Wood @ 2008-04-09 17:39 UTC (permalink / raw)
To: Sascha Hauer; +Cc: linuxppc-dev
In-Reply-To: <20080409165324.GF10465@pengutronix.de>
Sascha Hauer wrote:
> Right, so it's probably not worth the effort. I stumbled on this while
> porting my board to the new binding code. I was quite confused when
> seeing this so I made this fix to understand what's going on here.
>
> BTW have you tested the FCC driver with the new binding code?
Yes.
> I do not
> manage to get it working. Everything seems to be fine but
> fs_enet_start_xmit does not send a packet and no interrupts are
> arriving.
What does your device tree look like? Are all the pins and clocks set
up properly? Does the PHY negotiate OK? Is any error reported in the
descriptor?
>> Does this break arch/ppc, BTW?
>
> Yes. arch=ppc is out of my scope, so I forget about it regularly, sorry.
> It breaks arch/ppc/platforms/mpc8272ads_setup.c which can be easily
> fixed though. But as the mpc8272ads is supported with arch=powerpc,
> shouldn't it go away anyway?
arch/ppc is going away entirely in June or so. !CONFIG_PPC_NEW_BINDING
in arch/powerpc is going away as soon as I can unlazy myself enough to
send a patch. :-)
-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