* Re: [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
From: Kumar Gala @ 2007-08-14 3:09 UTC (permalink / raw)
To: joe.hamman; +Cc: linuxppc-embedded
In-Reply-To: <1187044669.10295.4.camel@server>
On Aug 13, 2007, at 5:37 PM, Joe Hamman wrote:
> Allow the address of the Ten Bit Interface (TBI) to be changed in the
> event of a conflict with another device.
>
> Signed-off by: Joe Hamman <joe.hamman@embeddedspecialties.com>
> ---
>
> Please ignore the last patch - I missed a cut & paste error on the
> range
> that my testing didn't catch.
I think we'd rather this came from the device tree.
- k
^ permalink raw reply
* Best Linux tree for Xilinx support.
From: Leonid @ 2007-08-14 2:47 UTC (permalink / raw)
To: Grant Likely, Wolfgang Reissnegger; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40708102137o25b83daar82a40471756a3f2b@mail.gmail.com>
Hi:
I have several boards with different architectures (Microblaze, PPC),
running Linux/uClinux and using Xilinx IP cores. I use both Virtex and
Spartan FPGAs.
Historically I'm using different kernels for them, starting from uClinux
2.4, all way through Linux 2.6.16 and 2.6.19. I patched them here and
there to get working.
I certainly feel a need to move to some standard kernel tree.
I understand that you guys are in some advanced steps of integrating
Xilinx into Linux. What would be my best choice of Linux kernel now?
I see the following options:
- download some GIT tree your are using (which one?).
- get latest tree from kernel.org and patch it using your patches (where
I can get them?).
- ??
Please advise,
Thanks,
Leonid.
^ permalink raw reply
* Bestcomm Firmware update
From: Frank Bennett @ 2007-08-14 2:10 UTC (permalink / raw)
To: linuxppc-embedded, jonsmirl
[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]
I wrote the disassembler below but never was able to get MPC5200/I2S
DMA running. Hope you can further BestComm code....
Copy of Posting 3/30/2006:
BestComm Dudes:
I was able to contact Davide Santo, AN2604 "Introduction to BestComm".
He admitted the short commings of his document in the area of Firmware
instruction info and gave me a name of a guy, Ed.Nuckolls@freescale.com
in the ASIC design area in Austin. Ed has agreed to answer questions,
push for resources to provide a support tool and provided me with a
document from their head programmer "SmartDMA Hand-Assembly Guides" (see
attached pdf).
With this secret decoded ring I was able to put together a disassembler,
see attached disasm.c. Cut and paste your favorite Task into fw[] array
at the beginning, "cc -o d disasm.c ; d" It's not perfect, but useful-
Enjoy.
If we can formulate a list of questions Ed might be able to help, I'll
start:
o what does init=31 mean?
AN2604 say init=0 means always requestor and 31 is reserved but
referenced alot in the F/W comments
o Need more info on how MORE works
o Tell us about LCD levels. Only 2? (let's call a LCD indent a level)
LCD seems to reset DRD to 1A. DRD2B1or2 follow a DRD2A (ext=1)?
o LCD[28:23]orLCD[20:15] or LCD[11:6] what is extraN?
drop 101nnn - extraN
add 1nnnnn - indexN
o how many DRD2B1[2] can be stacked up?
o when is/can a LDC Literal used? and how?
Frank Bennett
[-- Attachment #2: disasm.c --]
[-- Type: text/x-c, Size: 11341 bytes --]
/*
* disasm.c - disassembler for MPC5200 Bestcomm DMA Firmware
* copy and paste task code into fw, compile a run
* by Frank bennett, 3/29/2006
*
* Based on Freescale pdf "SmartDMA Hand-Assembly Guides"
*
* TODO:
* o add inc[0:7] array (maybe var) to deternmine proper term condition (upper 3 bits)
* o need to review sheet 3 of the pdf
* o simulator would be nice
*
*/
// Task12 (TASK_GEN_TX_BD) : Start of TDT -> 0xf0008528
// linuxppc_2_4_devel/arch/ppc/5xxx_io/bestcomm/code_dma/image_rtos1/"dma_image.reloc.c
//
// 31,30,29,28|27,26,25,24|23,22,21,20|19,18,17,16|15,14,13,12|11,10, 9, 8| 7, 6, 5, 4| 3, 2, 1, 0
// 0 0 0 1 0 0| 0 0 0 0 0| 0 0| 0 0| 0| 0 0 0 1 0 0| 1| 1 0 0 0 0 1| 0 0 0
// 0x10001308, /* 000C DRD1A: var4 = idx1; FN=0 MORE init=0 WS=0 RS=2 */
// 1 0 0| 1 1 0 0 1 0| 0| 0| 1 1 0 0 1 0| 0 0| 0| 0 0 0 0 0 0| 1 1 0| 1 1 0
// 0x99190036, /* 002C LCD: idx2 = idx2; idx2 once var0; idx2 += inc6 */
// 31,30,29,28|27,26,25,24|23,22,21,20|19,18,17,16|15,14,13,12|11,10, 9, 8| 7, 6, 5, 4| 3, 2, 1, 0
// 1 0| 0 1 1 0, 0 1 0 1, 1 0 0, 0 0 1| 1 0| 1 0 0 1 0 0 0 0 1 0 0 0 0
// 0x9950d210
/* Task12(TASK_GEN_TX_BD): Start of TDT -> 0xf0008528 */
unsigned long fw[] = {
0x800220e3, /* 0000 LCD: idx0 = var0, idx1 = var4; idx1 <= var3; idx0 += inc4, idx1 += inc3 */
0x13e01010, /* 0004 DRD1A: var4 = var2; FN=0 MORE init=24 WS=0 RS=0 */
0xb8808264, /* 0008 LCD: idx2 = *idx1, idx3 = var1; idx2 < var9; idx2 += inc4, idx3 += inc4 */
0x10001308, /* 000C DRD1A: var4 = idx1; FN=0 MORE init=0 WS=0 RS=2 */
0x60140002, /* 0010 DRD2A: EU0=0 EU1=0 EU2=0 EU3=2 EXT init=0 WS=2 RS=2 */
0x0cccfcca, /* 0014 DRD2B1: *idx3 = EU3(); EU3(*idx3,var10) */
0xd9190300, /* 0018 LCDEXT: idx2 = idx2; idx2 > var12; idx2 += inc0 */
0xb8c5e009, /* 001C LCD: idx3 = *(idx1 + var00000015); ; idx3 += inc1 */
0x03fec398, /* 0020 DRD1A: *idx0 = *idx3; FN=0 init=24 WS=3 RS=2 */
0x9919826a, /* 0024 LCD: idx2 = idx2, idx3 = idx3; idx2 > var9; idx2 += inc5, idx3 += inc2 */
0x0feac398, /* 0028 DRD1A: *idx0 = *idx3; FN=0 TFD INT init=24 WS=1 RS=2 */
0x99190036, /* 002C LCD: idx2 = idx2; idx2 once var0; idx2 += inc6 */
0x60000005, /* 0030 DRD2A: EU0=0 EU1=0 EU2=0 EU3=5 EXT init=0 WS=0 RS=0 */
0x0c4cf889, /* 0034 DRD2B1: *idx1 = EU3(); EU3(idx2,var9) */
0x000001f8, /* 0038 NOP */
0x9950d210,
0x2c4cf889,
0
};
union
{
unsigned long i;
struct
{
unsigned sb:3; // [02:00] increment #2
unsigned sa:3; // [05:03] increment #1
unsigned tc:6; // [11:06] variable to which idx is compared
unsigned drtc:1; // [12] dr ? *(tc) : (tc)
unsigned tu:2; // [14:13] term usage 00-idx_a, 01-idx_b, 10- lit init 11-no cond
unsigned ib:6; // [20:15] init_b
unsigned drib:1; // [21] dr ? *(init_a) : (init_a)
unsigned p:1; // [22] indx plus offset
unsigned ia:6; // [28:23] init_a
unsigned dria:1; // [29] dr ? *(init_a) : (init_a)
unsigned ext:1; // [30] = 2 or 3 for LCD
unsigned op:1; // [31] = 2 or 3 for LCD
} lcd;
struct
{
unsigned ll:13; // [12:00] literal init low
unsigned tu:2; // [14:13] term usage == 2
unsigned lh:15; // [29:15] literal init hi
unsigned bas:1; // [30] = 2 or 3 for LCD
unsigned op:1; // [31] = 2 or 3 for LCD
} lcdl;
struct
{
unsigned fn:3; // [02:00]
unsigned src:6; // [08:03]
unsigned drs:1; // [09] deref src?
unsigned dst:6; // [15:10]
unsigned drd:1; // [16] deref dst? scal?
unsigned ws:2; // [18:17] 0-32bit, 1-1 byte, 2-16 word, 3-dynamic/reserved??
unsigned rs:2; // [20:19] 0-32bit, 1-1 byte, 2-16 word, 3-dynamic/reserved??
unsigned init:5; // [25:21]
unsigned intr:1; // [26]
unsigned tfd:1; // [27]
unsigned more:1; // [28]
unsigned type:1; // [29]
unsigned ext:1; // [30]
unsigned op:1; // [31] = 0 for DRD
} drd1a;
struct
{
unsigned eu3:4; // [03:00] Execution Unit3 Function number
unsigned eu2:4; // [07:04] Execution Unit3 Function number
unsigned eu1:4; // [11:08] Execution Unit3 Function number
unsigned eu0:4; // [15:12] Execution Unit3 Function number
unsigned drd:1; // [16] deref dst? scal?
unsigned ws:2; // [18:17] 0-32bit, 1-1 byte, 2-16 word, 3-dynamic/reserved??
unsigned rs:2; // [20:19] 0-32bit, 1-1 byte, 2-16 word, 3-dynamic/reserved??
unsigned init:5; // [25:21]
unsigned int:1; // [26]
unsigned tfd:1; // [27]
unsigned more:1; // [28]
unsigned type:1; // [29]
unsigned ext:1; // [30]
unsigned op:1; // [31] = 0 for DRD
} drd2a;
struct
{
unsigned od1:6; // [05:00] EU operand 1
unsigned od0:6; // [11:06] EU operand 0
unsigned eu:2; // [13:12] EU#, only #3 available on MPC5200
unsigned mems:6; // [19:14] memory write source
unsigned drds:1; // [20]
unsigned rsv2:1; // [21]
unsigned memd:6; // [27:22] memory write destination
unsigned rsv1:1; // [28] reserved?
unsigned type:1; // [29]
unsigned ext:1; // [30]
unsigned op:1; // [31] = 0 for DRD
} drd2b1;
struct
{
unsigned odb1:6; // [05:00] EUb operand 1/3/5/7
unsigned odb0:6; // [11:06] EUb operand 0/2/4/6
unsigned eub:2; // [13:12] EUb#, only #3 available on MPC5200
unsigned oda1:6; // [19:14] EUa operand 1/3/5/7
unsigned oda0:6; // [25:20] EUa operand 0/2/4/6
unsigned eua:2; // [27:26] EUa#, only #3 available on MPC5200
unsigned rsv1:1; // [28]
unsigned type:1; // [29]
unsigned ext:1; // [30]
unsigned op:1; // [31] = 0 for DRD
} drd2b2;
} x;
// Condition codes (first 4 bits of the increments)
// >= c
// > 4
// once 0
// != 6
// <= a
// < 2
char *ft[] = {
"ld_acc", "unld_acc", "and", "or", "xor" "andn", "not",
"add", "sub", "lsh", "rsh", "crc8", "crc16", "crc32",
"endian32", "endian16"
};
char s[8];
indvar (int i)
{
switch ((i & 0x3f) >> 4)
{
case 0:
sprintf (s, "var%d", i & 0x1f); // varN
break;
case 1:
sprintf (s, "inc%d", i & 0x07); // incN
break;
case 2: // extraN
case 3:
sprintf (s, "idx%d", i & 0x0f); // idxN
break;
}
}
#define L2 LLev*2
main ()
{
int i, j, LLev = 0, drdt, ex = 0, ml;
char in[12];
for (i = 0; fw[i]; i++)
{
x.i = fw[i];
if (x.i == 0x1f8)
printf ("0x%08x, // NOP\n", x.i);
else if (x.lcd.op) // LCD
{
if (LLev == 0)
strcpy (in, "");
else
strcpy (in, " ");
if (x.lcd.ext) // LCDEXT
{
indvar (x.lcd.tc);
printf
("0x%08x, // %sLCDEXT: idx%d=idx%d; idx%d >%s%s ; idx%d += inc%d\n",
x.i, in, L2, L2, L2, x.lcd.drtc ? "*" : " ", s, L2,
x.lcd.sb);
} else if (x.lcd.tu == 2) // LCDLIT
{
printf ("0x%08x, // %sLCDLIT: idx%d = 0x%07x ??\n",
x.i, in, L2, (x.lcdl.lh << 13) | x.lcdl.ll);
} else // LCD
{
printf ("0x%08x, // %sLCD: ", x.i, in);
if (x.lcd.p) // indexed p-plus
{
indvar (x.lcd.ia);
printf ("idx%d = %s(%s + ", L2 + 1, x.lcd.dria ? "*" : " ", s);
indvar (x.lcd.ib);
printf ("%s%s); ; ", x.lcd.drib ? "*" : " ", s);
} else
{
indvar (x.lcd.ia);
printf ("idx%d=%s%s, ", L2, x.lcd.dria ? "*" : " ", s);
indvar (x.lcd.ib);
printf ("idx%d=%s%s, ", L2 + 1, x.lcd.drib ? "*" : " ", s);
}
if (x.lcd.tu < 2)
{
indvar (x.lcd.tc);
printf ("idx%d <=%s%s, ", (x.lcd.tu == 0) ? L2 : L2 + 1,
x.lcd.drtc ? "*" : " ", s);
}
if (x.lcd.tu != 3)
printf ("idx%d += inc%01x, ", L2, x.lcd.sa);
printf ("idx%d += inc%01x\n", L2 + 1, x.lcd.sb);
ex = 0;
}
}
else
{
// DRD
if (LLev == 0)
strcpy (in, " ");
else
strcpy (in, " ");
drdt = (ex << 2) | (x.drd1a.ext << 1) | x.drd1a.type;
switch (drdt)
{
case 0: // DRD1A
printf ("0x%08x, // %sDRD1A: ", x.i, in);
indvar (x.drd1a.dst);
printf ("%s%s =", x.drd1a.drd ? "*" : " ", s);
indvar (x.drd1a.src);
printf ("%s%s; ", x.drd1a.drs ? "*" : " ", s);
printf ("FN=%d (%s) ", x.drd1a.fn, ft[x.drd1a.fn]);
if (x.drd1a.more)
printf ("MORE ");
if (x.drd1a.tfd)
printf ("TFD ");
if (x.drd1a.intr)
printf ("INT ");
printf ("init=%d ", x.drd1a.init);
printf ("WS=%d RS=%d \n", x.drd1a.ws, x.drd1a.rs);
break;
case 3: // DRD2A
ex = x.drd2a.ext;
printf ("0x%08x, // %sDRD2A: ", x.i, in);
printf ("EU0=0 EU1=0 EU2=0 EU3=%d (%s) EXT init=%d ",
x.drd2a.eu3, ft[x.drd2a.eu3], x.drd2a.init);
printf ("WS=%d RS=%d \n", x.drd2a.ws, x.drd2a.rs);
break;
case 4: // DRD2B1
printf ("0x%08x, // %sDRD2B1: ", x.i, in);
indvar (x.drd2b1.memd); // mems ??
printf ("*%s=EU%d(); ", s, x.drd2b1.eu);
indvar (x.drd2b1.od0); printf ("EU%d(%s, ", x.drd2b1.eu, s);
indvar (x.drd2b1.od1); printf ("%s) \n", s);
break;
case 5: // DRD2B2
case 7: // DRD2B2?
printf ("0x%08x, // %sDRD2B2: ", x.i, in);
indvar (x.drd2b2.oda0); printf ("EU%d(%s, ", x.drd2b2.eub, s);
indvar (x.drd2b2.oda1); printf ("%s) , ", s);
indvar (x.drd2b2.odb0); printf ("EU%d(%s, ", x.drd2b2.eua, s);
indvar (x.drd2b2.odb1); printf ("%s) ??\n", s);
break;
case 1:
case 2:
case 6:
printf ("fix_me\n");
ex = x.drd1a.ext;
break;
}
LLev |= 1;
}
}
}
[-- Attachment #3: sdHandAssemblyLcdDrd.pdf --]
[-- Type: application/pdf, Size: 9985 bytes --]
^ permalink raw reply
* Xilinx EMAC driver for Linux in polling mode.
From: Leonid @ 2007-08-14 2:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1187044134.9536.4.camel@server>
Does anyboady have adapter.c file (or any source code) for Linux kernel
driver for Xilinx EMAC IP core, WORKING in POLLING mode? For certain
reasons I cannot use interrupt in my system.
Thanks,
Leonid.=20
^ permalink raw reply
* Re: [ PATCH ] PowerPC cascade UIC IRQ handler fix.
From: David Gibson @ 2007-08-14 1:35 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46C04F07.3040909@ru.mvista.com>
On Mon, Aug 13, 2007 at 04:31:03PM +0400, Valentine Barshak wrote:
[snip]
> >> Ok, here's a patch which fixes up the flow handling on the UIC. It
> >> needs some polish yet, but should be ok to test. Valentine, can you
> >> test this on your setup, *without* your original proposed patch.
> >> Eventually, for robustness, we'll want something like your original
> >> patch as well for robustness, but in the meantime leaving it out
> >> should tell us if my patch is actually having the intended effect.
> >
> > Valentine, it would be really helpful if you could test this on the
> > problem you observed with the cascade interrupt. Any word on this?
> >
>
> Thanks David,
> the patch works fine here (without the original one).
Ok, great.
> Don't think we really need a "fastcall" here on a powerpc though.
Oh, yeah, that's just copied from the generic handle_level_irq().
> The original patch also fixes a minor issue with /proc/interrupts
> (the the "if (trigger)" stuff).
> Currently level-triggered interrupts are displayed as edge-triggered
> ones and vice versa.
Yes, we'll still want two patches similar to your original: one to fix
the cosmetic /proc/interrupts problem, the other to make the cascade
handler more robust against spurious interrupts. I just wanted to see
if this flow handler change fixed the basic problem.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* patch powerpc-fix-size-check-for-hugetlbfs.patch queued to -stable tree
From: gregkh @ 2007-08-13 23:26 UTC (permalink / raw)
To: benh, gregkh, linuxppc-dev, paulus; +Cc: stable-commits
In-Reply-To: <1186551855.938.164.camel@localhost.localdomain>
This is a note to let you know that we have just queued up the patch titled
Subject: powerpc: Fix size check for hugetlbfs
to the 2.6.22-stable tree. Its filename is
powerpc-fix-size-check-for-hugetlbfs.patch
A git repo of this tree can be found at
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>From benh@kernel.crashing.org Mon Aug 13 16:17:09 2007
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed, 08 Aug 2007 15:44:15 +1000
Subject: powerpc: Fix size check for hugetlbfs
To: linuxppc-dev list <linuxppc-dev@ozlabs.org>
Cc: Paul Mackerras <paulus@samba.org>, stable@kernel.org
Message-ID: <1186551855.938.164.camel@localhost.localdomain>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
My "slices" address space management code that was added in 2.6.22
implementation of get_unmapped_area() doesn't properly check that the
size is a multiple of the requested page size. This allows userland to
create VMAs that aren't a multiple of the huge page size with hugetlbfs
(since hugetlbfs entirely relies on get_unmapped_area() to do that
checking) which leads to a kernel BUG() when such areas are torn down.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
--- linux-work.orig/arch/powerpc/mm/slice.c 2007-08-08 15:16:06.000000000 +1000
+++ linux-work/arch/powerpc/mm/slice.c 2007-08-08 15:16:41.000000000 +1000
@@ -405,6 +405,8 @@ unsigned long slice_get_unmapped_area(un
if (len > mm->task_size)
return -ENOMEM;
+ if (len & ((1ul << pshift) - 1))
+ return -EINVAL;
if (fixed && (addr & ((1ul << pshift) - 1)))
return -EINVAL;
if (fixed && addr > (mm->task_size - len))
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
Patches currently in stable-queue which might be from benh@kernel.crashing.org are
queue-2.6.22/ppc-revert-don-t-complain-if-size-cells-0-in-prom_parse.patch
queue-2.6.22/ppc-revert-add-mdio-to-bus-scan-id-list-for-platforms-with-qe-uec.patch
queue-2.6.22/powerpc-fix-size-check-for-hugetlbfs.patch
^ permalink raw reply
* [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
From: Joe Hamman @ 2007-08-13 22:37 UTC (permalink / raw)
To: galak; +Cc: linuxppc-embedded
Allow the address of the Ten Bit Interface (TBI) to be changed in the
event of a conflict with another device.
Signed-off by: Joe Hamman <joe.hamman@embeddedspecialties.com>
---
Please ignore the last patch - I missed a cut & paste error on the range
that my testing didn't catch.
---
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 81ef81c..b4813d9 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2276,6 +2276,14 @@ config GFAR_NAPI
bool "NAPI Support"
depends on GIANFAR
+config GFAR_TBIPA_VALUE
+ hex "Ten Bit Interface Port Address Value"
+ depends on GIANFAR
+ range 0 0x1f
+ default "0x1f"
+ help
+ Select an address that does not conflict with other addresses on the board.
+
config UCC_GETH
tristate "Freescale QE Gigabit Ethernet"
depends on QUICC_ENGINE
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index f926905..91ae0d3 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -490,15 +490,15 @@ static void gfar_configure_serdes(struct net_device *dev)
/* Initialise TBI i/f to communicate with serdes (lynx phy) */
/* Single clk mode, mii mode off(for aerdes communication) */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT);
+ gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT);
/* Supported pause and full-duplex, no half-duplex */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_ADVERTISE,
+ gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_ADVERTISE,
ADVERTISE_1000XFULL | ADVERTISE_1000XPAUSE |
ADVERTISE_1000XPSE_ASYM);
/* ANEG enable, restart ANEG, full duplex mode, speed[1] set */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE |
+ gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE |
BMCR_ANRESTART | BMCR_FULLDPLX | BMCR_SPEED1000);
}
@@ -547,7 +547,7 @@ static void init_registers(struct net_device *dev)
gfar_write(&priv->regs->minflr, MINFLR_INIT_SETTINGS);
/* Assign the TBI an address which won't conflict with the PHYs */
- gfar_write(&priv->regs->tbipa, TBIPA_VALUE);
+ gfar_write(&priv->regs->tbipa, CONFIG_GFAR_TBIPA_VALUE);
}
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index d8e779c..0fd1c02 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -131,7 +131,6 @@ extern const char gfar_driver_version[];
#define DEFAULT_RXCOUNT 16
#define DEFAULT_RXTIME 4
-#define TBIPA_VALUE 0x1f
#define MIIMCFG_INIT_VALUE 0x00000007
#define MIIMCFG_RESET 0x80000000
#define MIIMIND_BUSY 0x00000001
^ permalink raw reply related
* [PATCH] tsec: Allow Ten Bit Interface to be configurable
From: Joe Hamman @ 2007-08-13 22:28 UTC (permalink / raw)
To: galak; +Cc: linuxppc-embedded
Allow the address of the Ten Bit Interface (TBI) to be changed in the
event of a conflict with another device.
Signed-off by: Joe Hamman <joe.hamman@embeddedspecialties.com>
---
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 81ef81c..ba67b3b 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2276,6 +2276,14 @@ config GFAR_NAPI
bool "NAPI Support"
depends on GIANFAR
+config GFAR_TBIPA_VALUE
+ hex "Ten Bit Interface Port Address Value"
+ depends on GIANFAR
+ range 0 0x1f if BFIN_MAC_USE_L1
+ default "0x1f"
+ help
+ Select an address that does not conflict with other addresses on the board.
+
config UCC_GETH
tristate "Freescale QE Gigabit Ethernet"
depends on QUICC_ENGINE
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index f926905..91ae0d3 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -490,15 +490,15 @@ static void gfar_configure_serdes(struct net_device *dev)
/* Initialise TBI i/f to communicate with serdes (lynx phy) */
/* Single clk mode, mii mode off(for aerdes communication) */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT);
+ gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT);
/* Supported pause and full-duplex, no half-duplex */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_ADVERTISE,
+ gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_ADVERTISE,
ADVERTISE_1000XFULL | ADVERTISE_1000XPAUSE |
ADVERTISE_1000XPSE_ASYM);
/* ANEG enable, restart ANEG, full duplex mode, speed[1] set */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE |
+ gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE |
BMCR_ANRESTART | BMCR_FULLDPLX | BMCR_SPEED1000);
}
@@ -547,7 +547,7 @@ static void init_registers(struct net_device *dev)
gfar_write(&priv->regs->minflr, MINFLR_INIT_SETTINGS);
/* Assign the TBI an address which won't conflict with the PHYs */
- gfar_write(&priv->regs->tbipa, TBIPA_VALUE);
+ gfar_write(&priv->regs->tbipa, CONFIG_GFAR_TBIPA_VALUE);
}
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index d8e779c..0fd1c02 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -131,7 +131,6 @@ extern const char gfar_driver_version[];
#define DEFAULT_RXCOUNT 16
#define DEFAULT_RXTIME 4
-#define TBIPA_VALUE 0x1f
#define MIIMCFG_INIT_VALUE 0x00000007
#define MIIMCFG_RESET 0x80000000
#define MIIMIND_BUSY 0x00000001
^ permalink raw reply related
* Re: [PATCH, RFC] wake up from a serial port
From: Greg KH @ 2007-08-13 22:28 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <Pine.LNX.4.60.0708132307200.5643@poirot.grange>
On Mon, Aug 13, 2007 at 11:14:22PM +0200, Guennadi Liakhovetski wrote:
> On Mon, 13 Aug 2007, Scott Wood wrote:
>
> > Guennadi Liakhovetski wrote:
> > >
> > > # ls -l /sys/devices/platform/serial8250.0/tty*
> > > lrwxrwxrwx 1 root root 0 Aug 13 22:05
> > > /sys/devices/platform/serial8250.0/tty:ttyS0 -> ../../../class/tty/ttyS0
> > > lrwxrwxrwx 1 root root 0 Aug 13 22:05
> > > /sys/devices/platform/serial8250.0/tty:ttyS1 -> ../../../class/tty/ttyS1
> > >
> > > And placing some wakeup file under the class/tty/ directory doesn't seem
> > > very consistent with the current policy - until now they only live under
> > > devices/... (Greg added to cc:).
> >
> > Hmm... I'd assumed each port would have its own device directory. Would
> > anything break horribly if it were changed so that each tty:ttySx is a
> > directory, which contains both a wakeup file and the symlink?
No, you are already in the tty device directory in the first place, the
tty:ttyS1 is just a symlink to the class in case you need the thing.
Let's follow things around:
~ $ cd /sys/class/tty
/sys/class/tty $ ls -l | grep ttyS
lrwxrwxrwx 1 root root 0 Aug 12 20:12 ttyS0 -> ../../devices/platform/serial8250/tty/ttyS0
lrwxrwxrwx 1 root root 0 Aug 12 20:12 ttyS1 -> ../../devices/platform/serial8250/tty/ttyS1
lrwxrwxrwx 1 root root 0 Aug 12 20:12 ttyS2 -> ../../devices/platform/serial8250/tty/ttyS2
lrwxrwxrwx 1 root root 0 Aug 12 20:12 ttyS3 -> ../../devices/platform/serial8250/tty/ttyS3
/sys/class/tty $ cd ../../devices/platform/serial8250/tty/ttyS0
/sys/devices/platform/serial8250/tty/ttyS0 $ ls
dev device power subsystem uevent
/sys/devices/platform/serial8250/tty/ttyS0 $ cd ..
/sys/devices/platform/serial8250/tty $ $ ls -l
total 0
drwxr-xr-x 3 root root 0 Aug 12 20:12 ttyS0
drwxr-xr-x 3 root root 0 Aug 12 20:12 ttyS1
drwxr-xr-x 3 root root 0 Aug 12 20:12 ttyS2
drwxr-xr-x 3 root root 0 Aug 12 20:12 ttyS3
/sys/devices/platform/serial8250/tty $ cd ..
gregkh@mini /sys/devices/platform/serial8250 $ ls -l
total 0
lrwxrwxrwx 1 root root 0 Aug 12 20:13 driver -> ../../../bus/platform/drivers/serial8250
-r--r--r-- 1 root root 4096 Aug 13 15:24 modalias
drwxr-xr-x 2 root root 0 Aug 13 15:24 power
lrwxrwxrwx 1 root root 0 Aug 12 20:13 subsystem -> ../../../bus/platform
drwxr-xr-x 6 root root 0 Aug 12 20:12 tty
-rw-r--r-- 1 root root 4096 Aug 12 20:12 uevent
So, the serial8250 device is the "bridge" for the 4 different serial
ports in my machine. You have the tty:ttyS? symlinks in that directory
as you have CONFIG_SYSFS_DEPRECATED still enabled, but the directory
structure should all still be the same for you.
So, if you want to put things into the tty device's directory, you can,
they will just show up in the proper place, under
/sys/devices/platform/serial8250/tty/ttyS0 for the first serial port.
Does that make sense?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] [392/2many] MAINTAINERS - PS3 PLATFORM SUPPORT
From: Joe Perches @ 2007-08-13 22:36 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, akpm, torvalds, linux-kernel, cbe-oss-dev
In-Reply-To: <46C0DA2B.6080407@am.sony.com>
On Mon, 2007-08-13 at 15:24 -0700, Geoff Levand wrote:
> +F: include/asm-powerpc/lv1call.h
Added to my tree.
PS3 PLATFORM SUPPORT
P: Geoff Levand
M: geoffrey.levand@am.sony.com
L: linuxppc-dev@ozlabs.org
L: cbe-oss-dev@ozlabs.org
S: Supported
F: arch/powerpc/boot/ps3*
F: arch/powerpc/platforms/ps3/
F: drivers/*/ps3*
F: drivers/ps3/
F: drivers/usb/host/*ps3.c
F: include/asm-powerpc/ps3*
F: include/asm-powerpc/lv1call.h
^ permalink raw reply
* Re: [PATCH] [392/2many] MAINTAINERS - PS3 PLATFORM SUPPORT
From: Geoff Levand @ 2007-08-13 22:24 UTC (permalink / raw)
To: joe; +Cc: linuxppc-dev, akpm, torvalds, linux-kernel, cbe-oss-dev
In-Reply-To: <46bffb71.JWcVvIR5pg3biTEh%joe@perches.com>
From: joe@perches.com
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
I also maintain the file include/asm-powerpc/lv1call.h.
This updated patch adds that file.
-Geoff
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3015,6 +3015,13 @@ M: geoffrey.levand@am.sony.com
L: linuxppc-dev@ozlabs.org
L: cbe-oss-dev@ozlabs.org
S: Supported
+F: arch/powerpc/boot/ps3*
+F: arch/powerpc/platforms/ps3/
+F: drivers/*/ps3*
+F: drivers/ps3/
+F: drivers/usb/host/*ps3.c
+F: include/asm-powerpc/ps3*
+F: include/asm-powerpc/lv1call.h
PVRUSB2 VIDEO4LINUX DRIVER
P: Mike Isely
^ permalink raw reply
* Re: [PATCH, RFC] wake up from a serial port
From: Guennadi Liakhovetski @ 2007-08-13 21:14 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, linux-serial, Greg KH
In-Reply-To: <46C0C419.6060009@freescale.com>
On Mon, 13 Aug 2007, Scott Wood wrote:
> Guennadi Liakhovetski wrote:
> >
> > # ls -l /sys/devices/platform/serial8250.0/tty*
> > lrwxrwxrwx 1 root root 0 Aug 13 22:05
> > /sys/devices/platform/serial8250.0/tty:ttyS0 -> ../../../class/tty/ttyS0
> > lrwxrwxrwx 1 root root 0 Aug 13 22:05
> > /sys/devices/platform/serial8250.0/tty:ttyS1 -> ../../../class/tty/ttyS1
> >
> > And placing some wakeup file under the class/tty/ directory doesn't seem
> > very consistent with the current policy - until now they only live under
> > devices/... (Greg added to cc:).
>
> Hmm... I'd assumed each port would have its own device directory. Would
> anything break horribly if it were changed so that each tty:ttySx is a
> directory, which contains both a wakeup file and the symlink?
Yeah, I'd love to know the answer too:-) As you see, atm it is one
platform device as defined in arch/powerpc/kernel/legacy_serial.c:
static struct platform_device serial_device = {
.name = "serial8250",
.id = PLAT8250_DEV_PLATFORM,
.dev = {
.platform_data = legacy_serial_ports,
},
};
with a list of ports in platform data:
static struct plat_serial8250_port legacy_serial_ports[MAX_LEGACY_SERIAL_PORTS+1];
Hence one device directory. Same on a PC
$ ls -l /sys/devices/platform/serial8250/tty*
lrwxrwxrwx 1 root root 0 Aug 13 23:10 /sys/devices/platform/serial8250/tty:ttyS0 -> ../../../class/tty/ttyS0
lrwxrwxrwx 1 root root 0 Aug 13 23:10 /sys/devices/platform/serial8250/tty:ttyS1 -> ../../../class/tty/ttyS1
lrwxrwxrwx 1 root root 0 Aug 13 23:10 /sys/devices/platform/serial8250/tty:ttyS2 -> ../../../class/tty/ttyS2
lrwxrwxrwx 1 root root 0 Aug 13 23:10 /sys/devices/platform/serial8250/tty:ttyS3 -> ../../../class/tty/ttyS3
> You should get the interrupt, but not until after the PM code enables IRQs.
> Are you saying that the interrupt handler runs before then?
Great, it is working correctly then! Don't think the ISR runs return from
PM, no.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: Sequoia 440EPx patches not working
From: Jerone Young @ 2007-08-13 21:04 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46BB41EB.5030207@ru.mvista.com>
I got it to load now cuImage.sequoia and loading at address 0x200000. I
had been trying to load at 0x400000...apparently this was not good. So
moving to 0x300000 it loads but stops after setting up the device tree.
So the image was clobbering something but now is not at 0x200000.
Thanks for the help.
Jerone
On Thu, 2007-08-09 at 20:33 +0400, Valentine Barshak wrote:
> Jerone Young wrote:
> > So did a rebase on kernel.org 2.6.23-rc2 patch (as opposed the latest
> > git). I am using Uboot version 1.2.0-gc0c292b2. This is the version
> > that came with the board. It still appears to hang during early boot on
> > my Sequoia.
> >
> > Trying the cuImage.sequoia.bin.gz just result in Uboot giving "Bad Magic
> > Number" when trying to boot it. This is also the same for using
> > cuImage.sequoia.elf.
> >
> > So when I use the uImage file it will load but just hang after it's
> > loaded. I'm building it using "make uImage CROSS_COMPILE=<cross prefix>
> > ARCH=powerpc" on an x86 box.
> >
> > I'll see what else I could possibly be doing wrong (maybe something
> > happened to the patch when I grabbed it off of gmane and the web filters
> > did something to it, I did have to fix a problem where in the
> > sequoia.dts file the web filter replace "@" with " at ". This was simple
> > enough to fix. Maybe something else when wrong. I'll see what else I can
> > look at.
> >
> > On Thu, 2007-08-09 at 16:56 +0400, Vitaly Bordug wrote:
> >> On Wed, 08 Aug 2007 13:45:10 -0500
> >> Jerone Young wrote:
> >>
> >>> Using the Sequoia (AMCC 440EPx) patches recently submitted to the
> >>> list I am unable to boot to fully boot a uImage built with these
> >>> patches under Uboot. It appears to hang in very early boot.
> >>>
> >>>
> >>> Here is the output:
> >>> => tftp 400000
> >>> sequoia/uImage ENET Speed is 100 Mbps - FULL duplex connection
> >>> (EMAC0) Using ppc_4xx_eth0
> >>> device TFTP from server 9.53.41.24; our IP address is
> >>> 9.53.41.38 Filename
> >>> 'sequoia/uImage'. Load address:
> >>> 0x400000 Loading:
> >>> #################################################################
> >>> #################################################################
> >>> #################################################################
> >>> #######################
> >>> done Bytes transferred = 1112434 (10f972
> >>> hex) => bootm
> >>> 400000 ## Booting image at
> >>> 00400000 ... Image Name:
> >>> Linux-2.6.23-rc2 Image Type: PowerPC Linux Kernel Image (gzip
> >>> compressed) Data Size: 1112370 Bytes = 1.1
> >>> MB Load Address:
> >>> 00000000 Entry Point:
> >>> 00000000 Verifying Checksum ...
> >>> OK Uncompressing Kernel Image ... OK
> >>>
> >>> _______________________________________________
> >>> Linuxppc-dev mailing list
> >>> Linuxppc-dev@ozlabs.org
> >>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >> This seems to be a wrong image..
> >>
> >> Are you using "make zImage" ?
> >>
> >> The proper uImage after that command would be smth like cuImage* then...
> >>
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
> Please, apply clean patches (not filtered by web filters) and
> try make ARCH=powerpc CROSS_COMPILE=<cross_prefix> zImage
> The image should be at arch/powerpc/boot/cuImage.sequoia
^ permalink raw reply
* Re: [PATCH, RFC] wake up from a serial port
From: Scott Wood @ 2007-08-13 20:50 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, linux-serial, Greg KH
In-Reply-To: <Pine.LNX.4.60.0708132207530.5643@poirot.grange>
Guennadi Liakhovetski wrote:
> Well, sort of. One of them is more "natural" - it has a button on the
> front panel, to use the other one you have to modify the hardware.
> However, I like the idea - generally it does seem to be a better approach
> to have it run-time configurable over sysfs... Only - how? The only
> differentitaion ATM between the two ports are these two links:
>
> # ls -l /sys/devices/platform/serial8250.0/tty*
> lrwxrwxrwx 1 root root 0 Aug 13 22:05 /sys/devices/platform/serial8250.0/tty:ttyS0 -> ../../../class/tty/ttyS0
> lrwxrwxrwx 1 root root 0 Aug 13 22:05 /sys/devices/platform/serial8250.0/tty:ttyS1 -> ../../../class/tty/ttyS1
>
> And placing some wakeup file under the class/tty/ directory doesn't seem
> very consistent with the current policy - until now they only live under
> devices/... (Greg added to cc:).
Hmm... I'd assumed each port would have its own device directory. Would
anything break horribly if it were changed so that each tty:ttySx is a
directory, which contains both a wakeup file and the symlink?
> Actually, it is good you replied, Scott:-) I wanted to ask you about the
> following: I've switched to your generic suspend/resume routines using the
> _TLF_NAPPING bit, the arch_suspend_{dis,en}able_irqs() hooks... On wakeup
> your _TLF_NAPPING trick should bypass calling the ISR and jump directly to
> the resume code. However, on wakeup, it looks like I do get the wakeup
> interrupt too.
You should get the interrupt, but not until after the PM code enables
IRQs. Are you saying that the interrupt handler runs before then?
> Is it the correct behaviour and is this the (approximately)
> correct explanation why:
>
> 1. the AVR connected to ttyS0 sends 1 byte on button press and 1 byte on
> button release. So, normally you would get 2 bytes and 2 interupts for one
> such button down-up.
>
> 2. Interrupt is configured as edge (is it correct - haven't found in
> mpc8245um, UARTs are usually edge), so,
>
> --- button down -> byte #1 -> IRQ line active -> IC interrupts
> --- on resume interrupts are disabled, an EOI is performed (the line is
> still active)
> --- interrupts are re-enabled
>
> 3. a second interrupt for the same byte is delivered.
No EOI is performed -- the idea is to defer the interrupt, not swallow
it. All that is done to defer the interrupt is clearing MSR[EE].
-Scott
^ permalink raw reply
* Re: [PATCH, RFC] wake up from a serial port
From: Guennadi Liakhovetski @ 2007-08-13 20:41 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, linux-serial, Greg KH
In-Reply-To: <20070813155734.GB17535@ld0162-tx32.am.freescale.net>
On Mon, 13 Aug 2007, Scott Wood wrote:
> On Mon, Aug 13, 2007 at 12:27:30AM +0200, Guennadi Liakhovetski wrote:
> > A number of Linkstation models from Buffalo Technology with PPC, ARM, and
> > also MIPS (I think) CPUs have a power-management controller connected to a
> > UART. Among other things that chip controlls power and reset buttons.
> > Working on a standby support for one of these systems (ppc mpc8241 based),
> > the only suitable wakeup source there is the power button, which means, I
> > have to configure one of the two system UARTs to not be suspendsd. Using
> > the device_*_wakeup API doesn't quite work because both serial ports share
> > one device. The below patch proposes a new port flag UPF_MAY_WAKEUP to
> > configure such UARTs. It also adds support for a new "can-wakeup" serial
> > node property to the legacy_serial driver.
>
> Shouldn't the ability to wakeup be configured through sysfs, rather than
> encoded into the device tree? I'm assuming this is just a matter of
> configuration, and not that the hardware supports waking from one and not
> the other.
Well, sort of. One of them is more "natural" - it has a button on the
front panel, to use the other one you have to modify the hardware.
However, I like the idea - generally it does seem to be a better approach
to have it run-time configurable over sysfs... Only - how? The only
differentitaion ATM between the two ports are these two links:
# ls -l /sys/devices/platform/serial8250.0/tty*
lrwxrwxrwx 1 root root 0 Aug 13 22:05 /sys/devices/platform/serial8250.0/tty:ttyS0 -> ../../../class/tty/ttyS0
lrwxrwxrwx 1 root root 0 Aug 13 22:05 /sys/devices/platform/serial8250.0/tty:ttyS1 -> ../../../class/tty/ttyS1
And placing some wakeup file under the class/tty/ directory doesn't seem
very consistent with the current policy - until now they only live under
devices/... (Greg added to cc:).
Actually, it is good you replied, Scott:-) I wanted to ask you about the
following: I've switched to your generic suspend/resume routines using the
_TLF_NAPPING bit, the arch_suspend_{dis,en}able_irqs() hooks... On wakeup
your _TLF_NAPPING trick should bypass calling the ISR and jump directly to
the resume code. However, on wakeup, it looks like I do get the wakeup
interrupt too. Is it the correct behaviour and is this the (approximately)
correct explanation why:
1. the AVR connected to ttyS0 sends 1 byte on button press and 1 byte on
button release. So, normally you would get 2 bytes and 2 interupts for one
such button down-up.
2. Interrupt is configured as edge (is it correct - haven't found in
mpc8245um, UARTs are usually edge), so,
--- button down -> byte #1 -> IRQ line active -> IC interrupts
--- on resume interrupts are disabled, an EOI is performed (the line is
still active)
--- interrupts are re-enabled
3. a second interrupt for the same byte is delivered.
I'm just trying to understand whether this is the correct and expected
behaviour or something is wrong here.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* PCI BAR mapping problem
From: Johan Borkhuis @ 2007-08-13 20:23 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I am having some problems with the initialization of BAR registers of
the PCI bus. I have a number of devices connected to the bus, which have
a BAR-size of less than PAGE_SIZE. For example:
01:00.0 Network controller: VMIC: Unknown device 5565 (rev 01)
Subsystem: PLX Technology, Inc.: Unknown device 9656
Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 52
Memory at 00000000dfeffe00 (32-bit, non-prefetchable) [size=512]
I/O ports at e0ffff00 [size=256]
Memory at 00000000dfeffdc0 (32-bit, non-prefetchable) [size=64]
Memory at 00000000d8000000 (32-bit, non-prefetchable) [size=64M]
Capabilities: [40] Power Management version 0
Capabilities: [48] #00 [0080]
I want to access the PCI-areas from from user space, so I try to do an
mmap. The returned address is however rounded to multiple of PAGE_SIZE
(=0x1000). To access for example BAR0, I have to use the return-value
from mmap+0xE00. And in the above case, I am able to access the BAR0 and
BAR2 areas with only 1 mmap call, as the 2 addresses are within one page.
The problem is that, when running my code on a I386 platform the BAR
registers are mapped at address 0x0 of the returned area.
When looking at the PCI init code (arch/ppc/syslib/pci_auto.c) I see
that the BAR-base address and/or size is not corrected for PAGE_SIZE. Is
this correct behaviour?
I could image the following line being changed from:
bar_value = (*upper_limit - bar_size) & ~(bar_size - 1);
to:
bar_value = ((*upper_limit - bar_size) & ~(bar_size - 1)) &
~(PAGE_SIZE-1);
The PCI area is assigned using a top-down method. Using this statement
the bar_value is rounded down to the first PAGE_SIZE boundary.
This gives the following output:
01:00.0 Network controller: VMIC: Unknown device 5565 (rev 01)
Subsystem: PLX Technology, Inc.: Unknown device 9656
Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 52
Memory at 00000000dfeff000 (32-bit, non-prefetchable) [size=512]
I/O ports at e0fff000 [size=256]
Memory at 00000000dfefe000 (32-bit, non-prefetchable) [size=64]
Memory at 00000000d8000000 (32-bit, non-prefetchable) [size=64M]
Capabilities: [40] Power Management version 0
Capabilities: [48] #00 [0080]
My architecture: MVME3100 board with PPC8540 processor.
Note:
I posted this message to the embedded PPC mailing list, but as this is a
more generic linux-ppc issue, it could be discussed here as well.
Kind regards,
Johan Borkhuis
--
o o o o o o o . . . ___J_o_h_a_n___B_o_r_k_h_u_i_s___
o _____ || http://www.borkhuis.com |
.][__n_n_|DD[ ====_____ | johan@borkhuis.com |
>(________|__|_[_________]_|______________________________|
_/oo OOOOO oo` ooo ooo 'o!o!o o!o!o`
=== VxWorks-FAQ: http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html ===
^ permalink raw reply
* Re: MPC5200 and Bestcomm
From: Jon Smirl @ 2007-08-13 18:32 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-embedded
In-Reply-To: <46C0985B.9040401@genesi-usa.com>
On 8/13/07, Matt Sealey <matt@genesi-usa.com> wrote:
> I'll put in a decent request here for any work on this subject to
> please at least attempt to retrieve the tasks from the Efika
> firmware rather than replacing them in Linux gratuituously.
> I understand this doesn't help the Lite5200 guys.. but.. pretty
> please with a cherry on top? :]
We're making an open device with all software being replaceable. I
already have u-boot. Is there a free open firmware option? Which is
the recommended path?
Matt, I'll buy some Efikas as soon as you're selling them again.,
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: DTC 1.0.0 Release
From: Jon Loeliger @ 2007-08-13 18:30 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev@ozlabs.org, Olaf Hering, Jon Loeliger
In-Reply-To: <20070813005055.GC15738@localhost.localdomain>
On Sun, 2007-08-12 at 19:50, David Gibson wrote:
> On Fri, Aug 10, 2007 at 11:21:29PM +0200, Olaf Hering wrote:
> > On Thu, Aug 09, Jon Loeliger wrote:
> >
> > > As usual, please let me know of any issues with it.
> >
> > tests/truncated_property.c:45: warning: 'err' is used uninitialized
> > in this function
>
> Looks good. If you had a Signed-off-by, I'd add an Acked-by...
... I'd apply it and start us on the way to some
other release!
Thanks,
jdl
^ permalink raw reply
* On the other side of early_debug...
From: Morrison, Tom @ 2007-08-13 18:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <mailman.1.1186797602.26064.linuxppc-dev@ozlabs.org>
It looks like I am getting up to the point where the=20
rootfs has been NFS mounted correctly. Whew, but the
first thing the INIT program does it try to open the
/dev/console device - and it goes oops:
>> kernel BUG at drivers/char/tty_io.c:781!
>> Oops: Exception in kernel mode, sig: 5 [#1]
>> Empirix MPC848 Cheetah Board
>> Modules linked in:
>> NIP: c01390d4 LR: c013abe4 CTR: 00000000
>> REGS: effc3d50 TRAP: 0700 Not tainted
(2.6.23-r3_tom-g46b28357-dirty)
>> MSR: 00021000 <ME> CR: 24242422 XER: 00000000
>> TASK =3D effc1a80[1] 'init' THREAD: effc2000
>> GPR00: 00000001 effc3e00 effc1a80 00000000 effc3de0 00000001 00000000
>> c02b60c8
>> GPR08: 00001aa3 00000000 c030b730 00000000 22242422 1001f2f8 fffffff0
>> 007fff94
>> GPR16: 20000000 00000000 00000000 effc3e30 c17c2528 c17c2530 00000130
>> 00000128
>> GPR24: c02c0000 00000001 00000001 00000000 00000000 00029000 c17c2400
>> 00000001
>> NIP [c01390d4] tty_ldisc_put+0x44/0x70
>> LR [c013abe4] release_dev+0x4ec/0x6a0
>> Call Trace:
>> [effc3e00] [c021d800] __mutex_unlock_slowpath+0x40/0xd4 (unreliable)
>> [effc3e20] [c013abe4] release_dev+0x4ec/0x6a0
>> [effc3ee0] [c013adac] tty_release+0x14/0x28
>> [effc3ef0] [c0068844] __fput+0x178/0x19c
>> [effc3f10] [c0066a5c] filp_close+0x54/0xac
>> [effc3f30] [c0066b34] sys_close+0x80/0xc0
>> [effc3f40] [c000c54c] ret_from_syscall+0x0/0x3c
>> Instruction dump:
>> 7c000110 7c0000d0 0f000000 7fa000a6 7c000146 1d43004c 3d20c031
3929b730
>> 7d4a4a14 816a0048 212b0000 7c095914 <0f000000> 396bffff 806a0044
916a0048
Now, it seems the root cause is that the tty's=20
console_init was NEVER being called.=20
I am wondering if there was a reason or rhyme for this?
^ permalink raw reply
* Re: [PATCH] [43/2many] MAINTAINERS - AOA (Apple Onboard Audio) ALSA DRIVER
From: Joe Perches @ 2007-08-13 18:08 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, johannes, torvalds, linux-kernel, akpm
In-Reply-To: <1186988077.32127.2.camel@concordia.ozlabs.ibm.com>
On Mon, 2007-08-13 at 16:54 +1000, Michael Ellerman wrote:
> > +F: sound/oao/
> Should be aoa.
AOA (Apple Onboard Audio) ALSA DRIVER
P: Johannes Berg
M: johannes@sipsolutions.net
L: linuxppc-dev@ozlabs.org
L: alsa-devel@alsa-project.org (subscribers-only)
S: Maintained
F: sound/aoa/
^ permalink raw reply
* Re: MPC5200 and Bestcomm
From: Bartlomiej Sieka @ 2007-08-13 17:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40708130934v912eda2r691d2db30a9bc17c@mail.gmail.com>
Grant Likely wrote:
> On 8/13/07, Jon Smirl <jonsmirl@gmail.com> wrote:
>> We're starting a new MPC5200 project and I'm trying to track down
>> the best kernel to start from. Is Sylvain's tree at
>> http://www.246tnt.com/mpc52xx/ a good place to start? The git URLs
>> from the web page don't work. Everything 5200 related in the trees
>> at Secret Labs already appears to be merged.
>>
>> Most of this work also appears to be in the Open Embedded tree's
>> Ekifa support. Is that a better place to start?
>
> It might be. The major problem with MPC5200 is the Ethernet driver.
> I believe both Domen and Sylvain have been working on drivers
> suitable for arch/powerpc inclusion.
We have integrated FEC code floating around into DENX Linux 2.6 tree,
and have it working on several boards in the arch/powerpc context.
It might be worthwhile to check out
git://www.denx.de/git/linux-2.6-denx.git#linux-2.6-denx
HTH,
Bartlomiej
^ permalink raw reply
* Re: MPC5200 and Bestcomm
From: Matt Sealey @ 2007-08-13 17:43 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910708130952m9c5e512xe41fec3a02435298@mail.gmail.com>
The current (2.6.22) patchset for the Efika is being held here for
the moment; http://dev.gentoo.org/~nixnut/efika/
That's everything you 'really need' and it's probably the same as
this patch list.
However practically none of it is mainline-worthy at the moment,
Sylvain has detailed too many things he thinks is wrong with it.
I'm having a go with the new ethernet driver patch right now (a
customer asked me for a prebuilt kernel..) so I can get on with
testing that. The most important ones for rewrites besides that
are the AC97 driver (which is a little.. sparse) and actually
using the ATA task.
I'll put in a decent request here for any work on this subject to
please at least attempt to retrieve the tasks from the Efika
firmware rather than replacing them in Linux gratuituously.
I understand this doesn't help the Lite5200 guys.. but.. pretty
please with a cherry on top? :]
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Jon Smirl wrote:
> Another series is being posted to the Efika boards.
>
> 0001-powerpc-exports-rheap-symbol-to-modules.patch
> 0002-powerpc-Changes-the-config-mechanism-for-rheap.patch
> 0003-powerpc-ppc32-Update-mpc52xx_psc-structure-with-B-r.patch
> 0004-powerpc-BestComm-core-support-for-Freescale-MPC5200.patch
> 0005-powerpc-BestcComm-ATA-task-support.patch
> 0006-powerpc-BestcComm-FEC-task-support.patch
> 0007-powerpc-BestcComm-GenBD-task-support.patch
> 0008-drivers-net-Add-support-for-Freescale-MPC5200-SoC-i.patch
> 0009-sound-Add-support-for-Freescale-MPC5200-AC97-interf.patch
> 0010-powerpc-In-rheap.c-move-the-EXPORT_SYMBOL-and-use.patch
> 0011-powerpc-BestComm-move-the-EXPORT_SYMBOL-and-use-th.patch
> 0012-powerpc-BestComm-ATA-task-move-the-EXPORT_SYMBOL-a.patch
> 0013-powerpc-BestComm-FEC-task-move-the-EXPORT_SYMBOL-a.patch
> 0014-powerpc-BestComm-GenBD-task-move-the-EXPORT_SYMBOL.patch
> 0015-powerpc-BestComm-Replace-global-variable-bcom-by-b.patch
> 0016-powerpc-Make-the-BestComm-driver-a-standard-of_plat.patch
> 0017-powerpc-Fix-typo-in-BestComm-ATA-task-support-code.patch
> 0018-powerpc-BestComm-ATA-task-microcode-insert-copyri.patch
> 0019-powerpc-BestComm-FEC-task-microcode-insert-copyri.patch
> 0020-powerpc-BestComm-GenBD-task-microcode-insert-copy.patch
> 0021-powerpc-Fix-errors-in-bcom-bcom_eng-renaming.patch
> 0081-mpc52xx-correct-calculation-of-FEC-RX-errors.patch
> 0082-powerpc-pata_mpc52xx-suspend.patch
>
^ permalink raw reply
* Re: [PATCH] [298/2many] MAINTAINERS - LINUX FOR 64BIT POWERPC
From: Joe Perches @ 2007-08-13 17:40 UTC (permalink / raw)
To: Josh Boyer
Cc: anton, linux-kernel, linuxppc-dev, paulus, anton, paulus,
torvalds, akpm
In-Reply-To: <20070813061522.57ca3662@zod.rchland.ibm.com>
On Mon, 2007-08-13 at 06:15 -0500, Josh Boyer wrote:
> Erm, there's a lot more to 64-bit PowerPC than those 3 files. You're
> better off just doing arch/powerpc/, include/asm-powerpc.
LINUX FOR 64BIT POWERPC
P: Paul Mackerras
M: paulus@samba.org
M: paulus@au.ibm.com
P: Anton Blanchard
M: anton@samba.org
M: anton@au.ibm.com
W: http://www.penguinppc.org/ppc64/
L: linuxppc-dev@ozlabs.org
S: Supported
F: arch/powerpc/
F: include/asm-powerpc/
^ permalink raw reply
* Re: [PATCH] [292/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED PPC4XX
From: Josh Boyer @ 2007-08-13 17:39 UTC (permalink / raw)
To: Joe Perches; +Cc: torvalds, linux-kernel, akpm, linuxppc-embedded
In-Reply-To: <1187026501.10249.158.camel@localhost>
On Mon, 13 Aug 2007 10:35:01 -0700
Joe Perches <joe@perches.com> wrote:
> On Mon, 2007-08-13 at 06:18 -0500, Josh Boyer wrote:
> > You're missing arch/ppc/platforms/4xx/, among other things.
> > Also, we're in the middle of merging 4xx to arch/powerpc.
>
> We can leave the whole block unmodified until you're ready.
>
> LINUX FOR POWERPC EMBEDDED PPC4XX
> P: Matt Porter
> M: mporter@kernel.crashing.org
> W: http://www.penguinppc.org/
> L: linuxppc-embedded@ozlabs.org
> S: Maintained
Yeah. I would actually prefer that, thanks.
josh
^ permalink raw reply
* Re: [PATCH] [289/2many] MAINTAINERS - LINUX FOR POWERPC
From: Joe Perches @ 2007-08-13 17:38 UTC (permalink / raw)
To: Josh Boyer; +Cc: paulus, akpm, torvalds, linux-kernel, linuxppc-dev
In-Reply-To: <20070813061601.50bbefe0@zod.rchland.ibm.com>
On Mon, 2007-08-13 at 06:16 -0500, Josh Boyer wrote:
> There's also the arch/ppc, include/asm-ppc directories until they get
> removed.
LINUX FOR POWERPC
P: Paul Mackerras
M: paulus@samba.org
W: http://www.penguinppc.org/
L: linuxppc-dev@ozlabs.org
T: git kernel.org:/pub/scm/linux/kernel/git/paulus/powerpc.git
S: Supported
F: arch/powerpc/
F: arch/ppc/
F: include/asm-powerpc/
F: include/asm-ppc/
^ 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