* Re: 2.6.24-mm1: ppc32: too few arguments to function 'reserve_bootmem'
From: Sergei Shtylyov @ 2008-02-05 13:00 UTC (permalink / raw)
To: Andrew Morton
Cc: linuxppc-dev, Mariusz Kozlowski, paulus, bwalle, linux-kernel
In-Reply-To: <20080204144036.cf22a402.akpm@linux-foundation.org>
Hello.
Andrew Morton wrote:
>> This is from ppc32:
>> CC arch/powerpc/mm/mem.o
>>arch/powerpc/mm/mem.c: In function 'do_init_bootmem':
>>arch/powerpc/mm/mem.c:256: error: too few arguments to function 'reserve_bootmem'
>>arch/powerpc/mm/mem.c:261: error: too few arguments to function 'reserve_bootmem'
>>Leftover from introduce-flags-for-reserve_bootmem.patch?
> Yes, I've had to fix that patch many times.
> --- a/arch/powerpc/mm/mem.c~introduce-flags-for-reserve_bootmem-powerpc-fix
> +++ a/arch/powerpc/mm/mem.c
> @@ -253,12 +253,13 @@ void __init do_init_bootmem(void)
> lmb_size_bytes(&lmb.reserved, i) - 1;
> if (addr < total_lowmem)
> reserve_bootmem(lmb.reserved.region[i].base,
> - lmb_size_bytes(&lmb.reserved, i));
> + lmb_size_bytes(&lmb.reserved, i),
> + BOOTMEM_DEFAULT);
> else if (lmb.reserved.region[i].base < total_lowmem) {
> unsigned long adjusted_size = total_lowmem -
> lmb.reserved.region[i].base;
> reserve_bootmem(lmb.reserved.region[i].base,
> - adjusted_size);
> + adjusted_size, BOOTMEM_DWEFAULT);
BOOTMEM_DWEFAULT, are you sure? :-)
WBR, Sergei
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Josh Boyer @ 2008-02-05 13:08 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, Bernhard Reiter, debian-powerpc, paulus
In-Reply-To: <20080204095121.GA18167@powerlinux.fr>
On Mon, 4 Feb 2008 10:51:21 +0100
Sven Luther <sven@powerlinux.fr> wrote:
> On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote:
> > Dear linux powerpc Maintainers and Users,
> >
> > recently I have tried to compile a new kernel on a Debian sarge ppc
> > system (PowerBook5,6 MacRISC3 Power Macintosh).
>
> This is a G4 based system.
>
> > The build system bailed out with
> > BOOTCC arch/powerpc/boot/4xx.o
> > cc1: error: bad value (440) for -mcpu= switch
> > make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
> >
> > I have tracked this a few steps and the attached patch made the compile for me
> > as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
> > cannot produce code for 4xx it seems.
>
> You should normally not need to build the 4xx bootloader part. Make sure
> that, i don't know why this happens. Can you look into
> arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
> and make sure it is disabled in the main config ?
That's not true. All the wrapper bits are built for every board always.
josh
^ permalink raw reply
* Re: [PATCH] [POWERPC] get rid of `model = "UCC"' in the ucc nodes
From: David Gibson @ 2008-02-05 13:20 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev, Jon Loeliger
In-Reply-To: <fa686aa40802010823n1b837ffk7110a72e2bd44bf6@mail.gmail.com>
On Fri, Feb 01, 2008 at 09:23:47AM -0700, Grant Likely wrote:
> On 2/1/08, Kumar Gala <galak@kernel.crashing.org> wrote:
> >
> > > --- a/Documentation/powerpc/booting-without-of.txt
> > > +++ b/Documentation/powerpc/booting-without-of.txt
> > > @@ -1675,7 +1675,6 @@ platforms are moved over to use the flattened-
> > > device-tree model.
> > > ucc@2000 {
> > > device_type = "network";
> > > compatible = "ucc_geth";
> > > - model = "UCC";
> > > device-id = <1>;
> >
> > can we change device-id to cell-index?
>
> <aside>
> Here's a thought; do we really need a cell-index at all? (and I'm
> talking in general; not just this specific case). I'm starting to
> think we should migrate away from using it.
_Need_ perhaps not, but in some cases I think the alternatives are
overly complex.
> cell-index has been useful for things like clock controllers to know
> what offset into a shared clock control register or something like
> that and a driver would pass the cell-index value to the shared reg
> driver when requesting service.
Right. Except that if the shared resource is just a single register,
calling the routines to access it a "shared reg driver" gives a
misleading impression. Depending on how the shared reg is used, even
a lock may not be necessary, so potentially the drivers for the
individual device instances using the shared resource can (safely)
directly access it.
> However, I think the information
> encoded in cell-index is already encoded in the device tree in a
> different manor.
>
> Typically, shared registers and the like are all chip specific and the
> behaviour of the shared register drivers usually needs to be tweaked
> for different SoCs. Each ip core on an SoC is already uniquely
> indexed via the reg property. True, 'reg' is sparse (0x2000, 0x2200,
> 0x2300, ...) whereas cell-index is tight (0,1,2,3,...), but I don't
> think that introduces any additional difficulty.
>
> So, instead of a driver passing it's cell-index value to the shared
> reg driver, it would pass it's reg base instead. The shared register
> driver could then choose an internal representation that makes sense
> for it instead of whatever layout was chosen by the device tree.
Except that the "shared reg driver" then needs a way to map from reg
property to index. So either it has to have that hardcoded, or the
shared resource will need its own device tree representation for the
mapping.
In some cases the shared resource is complex enough that that makes
sense (e.g. an mdio bus shared between ethernet MACs to take an
extreme example). But when the "shared reg driver" consists entirely
of:
(readl(shared_reg_addr) & (1UL << cell_index))
and/or:
writel(shared_reg_addr, 1UL << cell_index)
your approach would seem to be overkill and then some. (The latter
example can be safe without locking in the case of a read/clear
register).
Exactly this sort of thing is fairly common on 4xx, which is just the
context in which BenH invented "cell-index" as a really simple way of
representing the index into shared registers like this.
> Dropping cell-index would mean one less property to keep in sync when
> tailoring device trees. (== less complexity for board porters).
> Besides, the purpose of cell-index is often misunderstood already by
> people trying to use it to describe port numbers (ttyS0, ttyS1, etc).
This is indeed a problem. But I don't think ditching cell-index
entirely is a sensible solution, sorry.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: 2.6.24-mm1: ppc32: too few arguments to function 'reserve_bootmem'
From: Bernhard Walle @ 2008-02-05 13:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Mariusz Kozlowski, paulus, linux-kernel
In-Reply-To: <20080204144036.cf22a402.akpm@linux-foundation.org>
* Andrew Morton <akpm@linux-foundation.org> [2008-02-04 23:40]:
> We did this wrong. We should have introduced a new reserve_bootmem_foo()
> and migrated over to that in stages. Once all callers are migrated, remove
> the old interface.
Well, my original proposal was to add a new function but then someone
complained that we already have too much bootmem functions. I don't
remember if this was on LKML or internally in Bugzilla.
However, sorry, it was my fault of course.
Bernhard
^ permalink raw reply
* Reboot at die_probe
From: Lehmann, Hans (Ritter Elektronik) @ 2008-02-05 13:39 UTC (permalink / raw)
To: linuxppc-embedded
Hi ,
i have strange problems with my cf card driver on our MPC5200 embedded
board. The cf card is mapped to memory space and interrupt is connected
to IRQ1(rising edge sensitive). First the driver was written for Kernel
2.6.14 and worked pretty. Now I ported it to Kernel 2.6.24 and get
strange behaviour I do not understand.
After I load the modul, the kernel start to reboot when i call function
ide_device_add(). The reboot appears while device responses in function
"actual_try_to_identify" (ide-probe.c), after kernel sent the identify
command (0xec) to status/command register (hwif->outb(cmd,
DIE_COMMAND_REG;).=20
To figure out whether card will be identify correct, I changed irq from
edge sensitive to level sensitive and card will be identified proper,
but get error "lost interrupt".
I habe no idea what happend.
Kindly regards
Hans
=20
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Sven Luther @ 2008-02-05 14:39 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Bernhard Reiter, debian-powerpc, paulus
In-Reply-To: <20080205070833.3a5b7c11@zod.rchland.ibm.com>
On Tue, Feb 05, 2008 at 07:08:33AM -0600, Josh Boyer wrote:
> On Mon, 4 Feb 2008 10:51:21 +0100
> Sven Luther <sven@powerlinux.fr> wrote:
>
> > On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote:
> > > Dear linux powerpc Maintainers and Users,
> > >
> > > recently I have tried to compile a new kernel on a Debian sarge ppc
> > > system (PowerBook5,6 MacRISC3 Power Macintosh).
> >
> > This is a G4 based system.
> >
> > > The build system bailed out with
> > > BOOTCC arch/powerpc/boot/4xx.o
> > > cc1: error: bad value (440) for -mcpu= switch
> > > make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
> > >
> > > I have tracked this a few steps and the attached patch made the compile for me
> > > as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
> > > cannot produce code for 4xx it seems.
> >
> > You should normally not need to build the 4xx bootloader part. Make sure
> > that, i don't know why this happens. Can you look into
> > arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
> > and make sure it is disabled in the main config ?
>
> That's not true. All the wrapper bits are built for every board always.
Yes, which is why it fails. But Should they not be conditionally built
upon including support or not for the actual board ?
I mean, if you have not included 4xx support in the kernel, as is the
case here, it does not make sense to add the 4xx bootwrapper code, no ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH] Fix legacy serial search for opb bus ports
From: Paul Gortmaker @ 2008-02-05 14:50 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <9efb8c0e313840ccb1bdf918406cdc812ec5de94.1202212897.git.michael@ellerman.id.au>
In message: [PATCH] Fix legacy serial search for opb bus ports
on 05/02/2008 Michael Ellerman wrote:
> The patch to legacy_serial.c (1a7507c7da2df6856e085e0fbb0c9ea8c12ac4e,
> Reduce code duplication in legacy_serial, add UART parent types) changed
> the semantics for opb ports from type = "opb" || compatible = "ibm,opb"
> to type = "opb" && compatible = "ibm,opb".
Ah. I'd originally coded it as an || -- but then Arnd suggested I
condense it further by using of_match_node() -- which was a good idea,
but that is where it accidentally changed to && without me catching it.
Thanks for finding this, and sorry for the debug adventure (I know
vanishing uarts isn't fun).
Paul.
Acked-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> The result is serial ports on our QS21s (Cell blades) don't get found,
> and for some reason the machine doesn't boot at all - possibly it's
> panicking due to lack of a console?
>
> The fix is to add two entries to the of_device_id table, one that looks
> for type = "opb" and the other compatible = "ibm,opb".
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
> arch/powerpc/kernel/legacy_serial.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> index 76b862b..61dd174 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -36,7 +36,8 @@ static struct legacy_serial_info {
> static struct __initdata of_device_id parents[] = {
> {.type = "soc",},
> {.type = "tsi-bridge",},
> - {.type = "opb", .compatible = "ibm,opb",},
> + {.type = "opb", },
> + {.compatible = "ibm,opb",},
> {.compatible = "simple-bus",},
> {.compatible = "wrs,epld-localbus",},
> };
> --
> 1.5.2.rc1.1884.g59b20
>
^ permalink raw reply
* Problems booting in ML403
From: A. Nolson @ 2008-02-05 14:52 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am having problems while trying to boot my linux kernel 2.6.24-rc3 (
secretlab git). After some days studying this list and other related
documents/wikis about how to make work a linux kernel in my ML403, I
managed to make it work partially.
I am using ELDK 4.1 "uclibc" as a cross compiler. I have also used ELDK
rootfs in my compactflash, when I boot it hangs at some point. This is
my console output:
loaded at: 00400000
005981A0
board data at: 00596124
005961A0
relocated to: 004040DC
00404158
zimage at: 00404ECD
00595EB8
avail ram: 00599000
04000000
Linux/PPC load: console=ttyS0,9600 console=tty0,9600 console=ttyUL0,9600
root=/d
ev/xsa2 rw
init=/sbin/init
Uncompressing
Linux...done.
Now booting the
kernel
[ 0.000000] Linux version 2.6.24-rc3-gd7ed933b-dirty (ios@xxx) (gcc vers
ion 4.0.0 (DENX ELDK 4.1 4.0.0)) #6 Mon Feb 4 14:06:43 CET
2008
[ 0.000000] Xilinx ML403 Reference System (Virtex-4
FX)
[ 0.000000] Zone PFN
ranges:
[ 0.000000] DMA 0 ->
16384
[ 0.000000] Normal 16384 ->
16384
[ 0.000000] HighMem 16384 ->
16384
[ 0.000000] Movable zone start PFN for each
node
[ 0.000000] early_node_map[1] active PFN
ranges
[ 0.000000] 0: 0 ->
16384
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pag
es:
16256
[ 0.000000] Kernel command line: console=ttyS0,9600 console=tty0,9600
console
=ttyUL0,9600 root=/dev/xsa2 rw
init=/sbin/init
[ 0.000000] Xilinx INTC #0 at 0x41200000 mapped to
0xFDFFE000
[ 0.000000] PID hash table entries: 256 (order: 8, 1024
bytes)
[ 0.000449] Console: colour dummy device
80x25
[ 0.000546] console [tty0]
enabled
[ 0.002982] Dentry cache hash table entries: 8192 (order: 3, 32768
bytes)
[ 0.004906] Inode-cache hash table entries: 4096 (order: 2, 16384
bytes)
[ 0.038813] Memory: 61312k available (2740k kernel code, 784k data,
112k init
, 0k
highmem)
[ 0.039615] SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4,
CPUs=1, N
odes=1
[ 0.220715] Mount-cache hash table entries:
512
[ 0.231019] net_namespace: 64
bytes
[ 0.244246] NET: Registered protocol family
16
[ 0.368073] NET: Registered protocol family
2
[ 0.461661] IP route cache hash table entries: 1024 (order: 0, 4096
bytes)
[ 0.467834] TCP established hash table entries: 2048 (order: 2, 16384
bytes)
[ 0.468813] TCP bind hash table entries: 2048 (order: 1, 8192
bytes)
[ 0.469483] TCP: Hash tables configured (established 2048 bind
2048)
[ 0.469711] TCP reno
registered
[ 0.493382] sysctl table check failed: /kernel/l2cr .1.31 Missing
strategy
[ 0.493825] Call
Trace:
[ 0.493957] [c3c11e80] [c0008380] show_stack+0x4c/0x174
(unreliable)
[ 0.494322] [c3c11eb0] [c0037170]
set_fail+0x50/0x68
[ 0.494637] [c3c11ed0] [c00377f8]
sysctl_check_table+0x670/0x6bc
[ 0.494922] [c3c11f10] [c003780c]
sysctl_check_table+0x684/0x6bc
[ 0.495203] [c3c11f50] [c0024e7c]
register_sysctl_table+0x5c/0xac
[ 0.495533] [c3c11f70] [c034ab68]
register_ppc_htab_sysctl+0x18/0x2c
[ 0.495864] [c3c11f80] [c034484c]
kernel_init+0xc8/0x284
[ 0.496130] [c3c11ff0] [c0004b18]
kernel_thread+0x44/0x60
[ 0.630804] Installing knfsd (copyright (C) 1996
okir@monad.swb.de).
[ 0.642747] JFS: nTxBlock = 479, nTxLock =
3832
[ 0.650497] SGI XFS with ACLs, large block numbers, no debug
enabled
[ 0.687400] io scheduler noop
registered
[ 0.687710] io scheduler anticipatory
registered
[ 0.687880] io scheduler deadline
registered
[ 0.689104] io scheduler cfq registered
(default)
[ 2.129848] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ
sharing
disabled
[ 2.150840] serial8250.0: ttyS0 at MMIO 0x40401003 (irq = 3) is a
16550A
[ 2.151248] console [ttyS0]
enabled
[ 5.425398] RAMDISK driver initialized: 16 RAM disks of 4096K size
1024 block
size
[ 5.532502] loop: module
loaded
[ 5.572824] xsysace xsysace.0: Xilinx SystemACE revision
1.0.12
[ 5.645558] xsysace xsysace.0: capacity: 1019088
sectors
[ 5.710732] xsa: xsa1 xsa2
xsa3
[ 5.763112] Xilinx SystemACE device driver,
major=254
[ 5.826421] nbd: registered device at major
43
[ 5.921820] XTemac: using sgDMA
mode.
[ 5.966225] XTemac: using TxDRE
mode
[ 6.009573] XTemac: using RxDRE
mode
[ 6.052783] XTemac: buffer descriptor size: 32768
(0x8000)
[ 6.120289] XTemac: (buffer_descriptor_init) phy: 0x3d80000, virt:
0xff100000
, size:
0x8000
[ 6.231949] eth%d: XTemac: No PHY detected. Assuming a PHY at
address 0
[ 6.313017] eth0: Dropping NETIF_F_SG since no checksum
feature.
[ 6.392778] eth0: Xilinx TEMAC #0 at 0x81200000 mapped to 0xC5060000,
irq=0
[ 6.476905] eth0: XTemac id 1.0f, block id 5, type
8
[ 6.539381] NFTL driver: nftlcore.c $Revision: 1.98 $, nftlmount.c
$Revision:
1.41
$
[ 6.633905] INFTL: inftlcore.c $Revision: 1.19 $, inftlmount.c
$Revision: 1.1
8
$
[ 6.725083] SSFDC read-only Flash Translation
layer
[ 6.791347] i8042.c: No controller
found.
[ 6.843298] mice: PS/2 mouse device common for all
mice
[ 6.912775] i2c /dev entries
driver
[ 6.958352] TCP cubic
registered
[ 6.998344] NET: Registered protocol family
1
[ 7.051264] NET: Registered protocol family
17
[ 7.110285] RPC: Registered udp transport
module.
[ 7.167370] RPC: Registered tcp transport
module.
[ 9.302726] kjournald starting. Commit interval 5
seconds
[ 9.408788] EXT3 FS on xsa2, internal
journal
[ 9.461599] EXT3-fs: recovery
complete.
[ 9.547744] EXT3-fs: mounted filesystem with ordered data
mode.
[ 9.619378] VFS: Mounted root (ext3
filesystem).
[ 9.675834] Freeing unused kernel memory: 112k
init
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I actually had tried before with the original rootfs that comes with the
given montavista demo, and I got this:
(...)
[ 12.906329] kjournald starting. Commit interval 5 seconds
[ 12.972902] EXT3-fs warning: maximal mount count reached, running
e2fsck is r
ecommended
[ 13.109355] EXT3 FS on xsa2, internal
journal
[ 13.162196] EXT3-fs: recovery
complete.
[ 13.247717] EXT3-fs: mounted filesystem with ordered data
mode.
[ 13.319357] VFS: Mounted root (ext3
filesystem).
[ 13.375883] Freeing unused kernel memory: 112k
init
[ 13.441190] Warning: unable to open an initial
console.
[ 19.728949] eth0: XTemac: Options:
0xb8f2
[ 31.747487] eth0: XTemac: Not able to set the speed to 1000 (status:
0x148)
[ 41.806572] eth0: XTemac: Not able to set the speed to 100 (status:
0x148)
[ 51.864570] eth0: XTemac: Not able to set the speed to 10 (status:
0x148)
[ 51.946095] eth0: XTemac: could not negotiate
speed
[ 52.004713] eth0: XTemac: Send Threshold = 16, Receive Threshold =
2
[ 52.080998] eth0: XTemac: Send Wait bound = 1, Receive Wait bound =
1
[ 64.670479] eth0: XTemac: PHY Link carrier lost.
Stopping here. Any ideas? Is there a problem with my eldk rootfs?
Thanks in advance!
^ permalink raw reply
* Re: [Virtex 4 PPC] Which Linux?
From: Robert Schwebel @ 2008-02-05 14:58 UTC (permalink / raw)
To: IngoM; +Cc: linuxppc-embedded
In-Reply-To: <15268468.post@talk.nabble.com>
On Mon, Feb 04, 2008 at 05:54:55AM -0800, IngoM wrote:
> 2) Linux
> I'd like to build my kernel and filesystem myself. But which way to go?
> Using OE, buildroot, ELDK...
> Can you please provide some starting points for me?
ptxdist would be another alternative.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Josh Boyer @ 2008-02-05 15:15 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, Bernhard Reiter, debian-powerpc, paulus
In-Reply-To: <20080205143926.GA9709@powerlinux.fr>
On Tue, 5 Feb 2008 15:39:26 +0100
Sven Luther <sven@powerlinux.fr> wrote:
> On Tue, Feb 05, 2008 at 07:08:33AM -0600, Josh Boyer wrote:
> > On Mon, 4 Feb 2008 10:51:21 +0100
> > Sven Luther <sven@powerlinux.fr> wrote:
> >
> > > On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote:
> > > > Dear linux powerpc Maintainers and Users,
> > > >
> > > > recently I have tried to compile a new kernel on a Debian sarge ppc
> > > > system (PowerBook5,6 MacRISC3 Power Macintosh).
> > >
> > > This is a G4 based system.
> > >
> > > > The build system bailed out with
> > > > BOOTCC arch/powerpc/boot/4xx.o
> > > > cc1: error: bad value (440) for -mcpu= switch
> > > > make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
> > > >
> > > > I have tracked this a few steps and the attached patch made the compile for me
> > > > as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
> > > > cannot produce code for 4xx it seems.
> > >
> > > You should normally not need to build the 4xx bootloader part. Make sure
> > > that, i don't know why this happens. Can you look into
> > > arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
> > > and make sure it is disabled in the main config ?
> >
> > That's not true. All the wrapper bits are built for every board always.
>
> Yes, which is why it fails. But Should they not be conditionally built
> upon including support or not for the actual board ?
One would think so.
> I mean, if you have not included 4xx support in the kernel, as is the
> case here, it does not make sense to add the 4xx bootwrapper code, no ?
It does, in a manner. There are both generic and platform specific
pieces to the bootwrapper. Having everything always built helps keep
the generic bits from breaking, which is important as they're often
tightly coupled. That's at least the reason I can think of.
The powerpc maintainers have been over this quite a bit and I don't see
it changing anytime soon.
josh
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Grant Likely @ 2008-02-05 15:24 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Bernhard Reiter, debian-powerpc, paulus
In-Reply-To: <20080205091548.724c4e20@zod.rchland.ibm.com>
On 2/5/08, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> > I mean, if you have not included 4xx support in the kernel, as is the
> > case here, it does not make sense to add the 4xx bootwrapper code, no ?
>
> It does, in a manner. There are both generic and platform specific
> pieces to the bootwrapper. Having everything always built helps keep
> the generic bits from breaking, which is important as they're often
> tightly coupled. That's at least the reason I can think of.
>
> The powerpc maintainers have been over this quite a bit and I don't see
> it changing anytime soon.
That would mean we're dropping support for compilers which can't build
405/440 specific wrapper bits (or other core specific quirks that need
to go in the wrapper) That doesn't sound appropriate to me.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Josh Boyer @ 2008-02-05 15:38 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Bernhard Reiter, debian-powerpc, paulus
In-Reply-To: <fa686aa40802050724o692ef9e7yf51945225f56da5b@mail.gmail.com>
On Tue, 5 Feb 2008 08:24:38 -0700
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> On 2/5/08, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> > > I mean, if you have not included 4xx support in the kernel, as is the
> > > case here, it does not make sense to add the 4xx bootwrapper code, no ?
> >
> > It does, in a manner. There are both generic and platform specific
> > pieces to the bootwrapper. Having everything always built helps keep
> > the generic bits from breaking, which is important as they're often
> > tightly coupled. That's at least the reason I can think of.
> >
> > The powerpc maintainers have been over this quite a bit and I don't see
> > it changing anytime soon.
>
> That would mean we're dropping support for compilers which can't build
> 405/440 specific wrapper bits (or other core specific quirks that need
> to go in the wrapper) That doesn't sound appropriate to me.
No it doesn't. At least not yet. I said I'd try to come up with a
patch soon-ish. We haven't failed!(yet) Also, this isn't a
core-specific quirk. It's an architected instruction of Book III-E in
the PowerPC ISA. I can't help it if other chips don't implement this
wonderful control mechanism ;)
Taking a step back though, there will always be odd cases like this as
we move forward. Toolchain XXX will eventually not support instruction
YYYY which will eventually be used, etc. I'll try to make this
specific case work because it's scope is quite limited. But this
problem as a whole will still remain.
josh
^ permalink raw reply
* Re: [PATCH 2/10] sbc8560: Add v1 device tree source for Wind River SBC8560 board
From: Kumar Gala @ 2008-02-05 15:44 UTC (permalink / raw)
To: David Gibson; +Cc: Paul Gortmaker, linuxppc-dev
In-Reply-To: <20080205024049.GC28846@localhost.localdomain>
On Feb 4, 2008, at 8:40 PM, David Gibson wrote:
> On Fri, Feb 01, 2008 at 08:46:32AM -0600, Kumar Gala wrote:
>>
>> On Feb 1, 2008, at 1:54 AM, David Gibson wrote:
>>
>>> On Thu, Jan 24, 2008 at 06:41:24PM -0500, Paul Gortmaker wrote:
> [snip]
>>>> + epld@5,0 {
>>>
>>> I'm not entirely convinced on this two-level representation. I
>>> think
>>> the FSL people need to get together and define a binding (or set of
>>> bindings) for their various chipselect style external bus bridges.
>>
>> It seems reasonable if you had a FPGA off of the localbus to have a
>> two level representation. One for the localbus controller on the FSL
>> part and the child to describe the FPGA.
>>
>> What are you expecting beyond what we have today? I guess I'm asking
>> what's missing from the localbus nodes we have?
>
> Sorry, I was probably misleading. All I really meant is that I don't
> know enough about these FSL bus bridge arrangements to assess if this
> representation is the most sensible one. I'm presuming that this
> chipselect bridge unit is a more-or-less standard ASIC appearing on
> lots of the FSL chips, so it would be nice to have a standard binding
> for them, as we do for the roughly-equivalent EBC bridge on 4xx.
Is there a writeup for EBC? I'll take a look at it and see if it
makes senses for the freescale 'localbus'.
- k
^ permalink raw reply
* [PATCH 1/2] fb: add support for foreign endianness
From: Anton Vorontsov @ 2008-02-05 15:44 UTC (permalink / raw)
To: adaplas, linux-kernel; +Cc: linuxppc-dev
This patch adds support for the framebuffers with non-native
endianness. This is done via FBINFO_FOREIGN_ENDIAN flag that will
be used by the drivers. Depending on the host endianness this flag
will be overwritten by FBINFO_BE_MATH internal flag, or cleared.
Tested to work on MPC8360E-RDK (BE) + Fujitsu MINT framebuffer (LE).
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/video/cfbcopyarea.c | 23 ++++++++++--------
drivers/video/cfbfillrect.c | 48 +++++++++++++++++++++------------------
drivers/video/cfbimgblt.c | 52 +++++++++++++++++++++---------------------
drivers/video/fb_draw.h | 31 ++++++++++++++-----------
drivers/video/fbmem.c | 8 ++++++
drivers/video/syscopyarea.c | 20 ++++++++--------
drivers/video/sysfillrect.c | 49 ++++++++++++++++++++-------------------
drivers/video/sysimgblt.c | 47 ++++++++++++++++++--------------------
include/linux/fb.h | 30 +++++++++++++++++-------
9 files changed, 168 insertions(+), 140 deletions(-)
diff --git a/drivers/video/cfbcopyarea.c b/drivers/video/cfbcopyarea.c
index b07e419..df03f37 100644
--- a/drivers/video/cfbcopyarea.c
+++ b/drivers/video/cfbcopyarea.c
@@ -44,15 +44,16 @@
*/
static void
-bitcpy(unsigned long __iomem *dst, int dst_idx, const unsigned long __iomem *src,
- int src_idx, int bits, unsigned n, u32 bswapmask)
+bitcpy(struct fb_info *p, unsigned long __iomem *dst, int dst_idx,
+ const unsigned long __iomem *src, int src_idx, int bits,
+ unsigned n, u32 bswapmask)
{
unsigned long first, last;
int const shift = dst_idx-src_idx;
int left, right;
- first = fb_shifted_pixels_mask_long(dst_idx, bswapmask);
- last = ~fb_shifted_pixels_mask_long((dst_idx+n) % bits, bswapmask);
+ first = fb_shifted_pixels_mask_long(p, dst_idx, bswapmask);
+ last = ~fb_shifted_pixels_mask_long(p, (dst_idx+n) % bits, bswapmask);
if (!shift) {
// Same alignment for source and dest
@@ -202,8 +203,9 @@ bitcpy(unsigned long __iomem *dst, int dst_idx, const unsigned long __iomem *src
*/
static void
-bitcpy_rev(unsigned long __iomem *dst, int dst_idx, const unsigned long __iomem *src,
- int src_idx, int bits, unsigned n, u32 bswapmask)
+bitcpy_rev(struct fb_info *p, unsigned long __iomem *dst, int dst_idx,
+ const unsigned long __iomem *src, int src_idx, int bits,
+ unsigned n, u32 bswapmask)
{
unsigned long first, last;
int shift;
@@ -221,8 +223,9 @@ bitcpy_rev(unsigned long __iomem *dst, int dst_idx, const unsigned long __iomem
shift = dst_idx-src_idx;
- first = fb_shifted_pixels_mask_long(bits - 1 - dst_idx, bswapmask);
- last = ~fb_shifted_pixels_mask_long(bits - 1 - ((dst_idx-n) % bits), bswapmask);
+ first = fb_shifted_pixels_mask_long(p, bits - 1 - dst_idx, bswapmask);
+ last = ~fb_shifted_pixels_mask_long(p, bits - 1 - ((dst_idx-n) % bits),
+ bswapmask);
if (!shift) {
// Same alignment for source and dest
@@ -404,7 +407,7 @@ void cfb_copyarea(struct fb_info *p, const struct fb_copyarea *area)
dst_idx &= (bytes - 1);
src += src_idx >> (ffs(bits) - 1);
src_idx &= (bytes - 1);
- bitcpy_rev(dst, dst_idx, src, src_idx, bits,
+ bitcpy_rev(p, dst, dst_idx, src, src_idx, bits,
width*p->var.bits_per_pixel, bswapmask);
}
} else {
@@ -413,7 +416,7 @@ void cfb_copyarea(struct fb_info *p, const struct fb_copyarea *area)
dst_idx &= (bytes - 1);
src += src_idx >> (ffs(bits) - 1);
src_idx &= (bytes - 1);
- bitcpy(dst, dst_idx, src, src_idx, bits,
+ bitcpy(p, dst, dst_idx, src, src_idx, bits,
width*p->var.bits_per_pixel, bswapmask);
dst_idx += bits_per_line;
src_idx += bits_per_line;
diff --git a/drivers/video/cfbfillrect.c b/drivers/video/cfbfillrect.c
index 23d70a1..64b3576 100644
--- a/drivers/video/cfbfillrect.c
+++ b/drivers/video/cfbfillrect.c
@@ -36,16 +36,16 @@
*/
static void
-bitfill_aligned(unsigned long __iomem *dst, int dst_idx, unsigned long pat,
- unsigned n, int bits, u32 bswapmask)
+bitfill_aligned(struct fb_info *p, unsigned long __iomem *dst, int dst_idx,
+ unsigned long pat, unsigned n, int bits, u32 bswapmask)
{
unsigned long first, last;
if (!n)
return;
- first = fb_shifted_pixels_mask_long(dst_idx, bswapmask);
- last = ~fb_shifted_pixels_mask_long((dst_idx+n) % bits, bswapmask);
+ first = fb_shifted_pixels_mask_long(p, dst_idx, bswapmask);
+ last = ~fb_shifted_pixels_mask_long(p, (dst_idx+n) % bits, bswapmask);
if (dst_idx+n <= bits) {
// Single word
@@ -93,16 +93,16 @@ bitfill_aligned(unsigned long __iomem *dst, int dst_idx, unsigned long pat,
*/
static void
-bitfill_unaligned(unsigned long __iomem *dst, int dst_idx, unsigned long pat,
- int left, int right, unsigned n, int bits)
+bitfill_unaligned(struct fb_info *p, unsigned long __iomem *dst, int dst_idx,
+ unsigned long pat, int left, int right, unsigned n, int bits)
{
unsigned long first, last;
if (!n)
return;
- first = FB_SHIFT_HIGH(~0UL, dst_idx);
- last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
+ first = FB_SHIFT_HIGH(p, ~0UL, dst_idx);
+ last = ~(FB_SHIFT_HIGH(p, ~0UL, (dst_idx+n) % bits));
if (dst_idx+n <= bits) {
// Single word
@@ -147,8 +147,9 @@ bitfill_unaligned(unsigned long __iomem *dst, int dst_idx, unsigned long pat,
* Aligned pattern invert using 32/64-bit memory accesses
*/
static void
-bitfill_aligned_rev(unsigned long __iomem *dst, int dst_idx, unsigned long pat,
- unsigned n, int bits, u32 bswapmask)
+bitfill_aligned_rev(struct fb_info *p, unsigned long __iomem *dst,
+ int dst_idx, unsigned long pat, unsigned n, int bits,
+ u32 bswapmask)
{
unsigned long val = pat, dat;
unsigned long first, last;
@@ -156,8 +157,8 @@ bitfill_aligned_rev(unsigned long __iomem *dst, int dst_idx, unsigned long pat,
if (!n)
return;
- first = fb_shifted_pixels_mask_long(dst_idx, bswapmask);
- last = ~fb_shifted_pixels_mask_long((dst_idx+n) % bits, bswapmask);
+ first = fb_shifted_pixels_mask_long(p, dst_idx, bswapmask);
+ last = ~fb_shifted_pixels_mask_long(p, (dst_idx+n) % bits, bswapmask);
if (dst_idx+n <= bits) {
// Single word
@@ -217,16 +218,17 @@ bitfill_aligned_rev(unsigned long __iomem *dst, int dst_idx, unsigned long pat,
*/
static void
-bitfill_unaligned_rev(unsigned long __iomem *dst, int dst_idx, unsigned long pat,
- int left, int right, unsigned n, int bits)
+bitfill_unaligned_rev(struct fb_info *p, unsigned long __iomem *dst,
+ int dst_idx, unsigned long pat, int left, int right,
+ unsigned n, int bits)
{
unsigned long first, last, dat;
if (!n)
return;
- first = FB_SHIFT_HIGH(~0UL, dst_idx);
- last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
+ first = FB_SHIFT_HIGH(p, ~0UL, dst_idx);
+ last = ~(FB_SHIFT_HIGH(p, ~0UL, (dst_idx+n) % bits));
if (dst_idx+n <= bits) {
// Single word
@@ -306,7 +308,8 @@ void cfb_fillrect(struct fb_info *p, const struct fb_fillrect *rect)
p->fbops->fb_sync(p);
if (!left) {
u32 bswapmask = fb_compute_bswapmask(p);
- void (*fill_op32)(unsigned long __iomem *dst, int dst_idx,
+ void (*fill_op32)(struct fb_info *p,
+ unsigned long __iomem *dst, int dst_idx,
unsigned long pat, unsigned n, int bits,
u32 bswapmask) = NULL;
@@ -325,16 +328,17 @@ void cfb_fillrect(struct fb_info *p, const struct fb_fillrect *rect)
while (height--) {
dst += dst_idx >> (ffs(bits) - 1);
dst_idx &= (bits - 1);
- fill_op32(dst, dst_idx, pat, width*bpp, bits, bswapmask);
+ fill_op32(p, dst, dst_idx, pat, width*bpp, bits,
+ bswapmask);
dst_idx += p->fix.line_length*8;
}
} else {
int right;
int r;
int rot = (left-dst_idx) % bpp;
- void (*fill_op)(unsigned long __iomem *dst, int dst_idx,
- unsigned long pat, int left, int right,
- unsigned n, int bits) = NULL;
+ void (*fill_op)(struct fb_info *p, unsigned long __iomem *dst,
+ int dst_idx, unsigned long pat, int left,
+ int right, unsigned n, int bits) = NULL;
/* rotate pattern to correct start position */
pat = pat << rot | pat >> (bpp-rot);
@@ -355,7 +359,7 @@ void cfb_fillrect(struct fb_info *p, const struct fb_fillrect *rect)
while (height--) {
dst += dst_idx >> (ffs(bits) - 1);
dst_idx &= (bits - 1);
- fill_op(dst, dst_idx, pat, left, right,
+ fill_op(p, dst, dst_idx, pat, left, right,
width*bpp, bits);
r = (p->fix.line_length*8) % bpp;
pat = pat << (bpp-r) | pat >> r;
diff --git a/drivers/video/cfbimgblt.c b/drivers/video/cfbimgblt.c
index f598907..ff3136b 100644
--- a/drivers/video/cfbimgblt.c
+++ b/drivers/video/cfbimgblt.c
@@ -43,30 +43,26 @@
#define DPRINTK(fmt, args...)
#endif
-static const u32 cfb_tab8[] = {
-#if defined(__BIG_ENDIAN)
+static const u32 cfb_tab8_be[] = {
0x00000000,0x000000ff,0x0000ff00,0x0000ffff,
0x00ff0000,0x00ff00ff,0x00ffff00,0x00ffffff,
0xff000000,0xff0000ff,0xff00ff00,0xff00ffff,
0xffff0000,0xffff00ff,0xffffff00,0xffffffff
-#elif defined(__LITTLE_ENDIAN)
+};
+
+static const u32 cfb_tab8_le[] = {
0x00000000,0xff000000,0x00ff0000,0xffff0000,
0x0000ff00,0xff00ff00,0x00ffff00,0xffffff00,
0x000000ff,0xff0000ff,0x00ff00ff,0xffff00ff,
0x0000ffff,0xff00ffff,0x00ffffff,0xffffffff
-#else
-#error FIXME: No endianness??
-#endif
};
-static const u32 cfb_tab16[] = {
-#if defined(__BIG_ENDIAN)
+static const u32 cfb_tab16_be[] = {
0x00000000, 0x0000ffff, 0xffff0000, 0xffffffff
-#elif defined(__LITTLE_ENDIAN)
+};
+
+static const u32 cfb_tab16_le[] = {
0x00000000, 0xffff0000, 0x0000ffff, 0xffffffff
-#else
-#error FIXME: No endianness??
-#endif
};
static const u32 cfb_tab32[] = {
@@ -98,7 +94,8 @@ static inline void color_imageblit(const struct fb_image *image,
val = 0;
if (start_index) {
- u32 start_mask = ~fb_shifted_pixels_mask_u32(start_index, bswapmask);
+ u32 start_mask = ~fb_shifted_pixels_mask_u32(p,
+ start_index, bswapmask);
val = FB_READL(dst) & start_mask;
shift = start_index;
}
@@ -108,20 +105,21 @@ static inline void color_imageblit(const struct fb_image *image,
color = palette[*src];
else
color = *src;
- color <<= FB_LEFT_POS(bpp);
- val |= FB_SHIFT_HIGH(color, shift ^ bswapmask);
+ color <<= FB_LEFT_POS(p, bpp);
+ val |= FB_SHIFT_HIGH(p, color, shift ^ bswapmask);
if (shift >= null_bits) {
FB_WRITEL(val, dst++);
val = (shift == null_bits) ? 0 :
- FB_SHIFT_LOW(color, 32 - shift);
+ FB_SHIFT_LOW(p, color, 32 - shift);
}
shift += bpp;
shift &= (32 - 1);
src++;
}
if (shift) {
- u32 end_mask = fb_shifted_pixels_mask_u32(shift, bswapmask);
+ u32 end_mask = fb_shifted_pixels_mask_u32(p, shift,
+ bswapmask);
FB_WRITEL((FB_READL(dst) & end_mask) | val, dst);
}
@@ -152,8 +150,8 @@ static inline void slow_imageblit(const struct fb_image *image, struct fb_info *
u32 bswapmask = fb_compute_bswapmask(p);
dst2 = (u32 __iomem *) dst1;
- fgcolor <<= FB_LEFT_POS(bpp);
- bgcolor <<= FB_LEFT_POS(bpp);
+ fgcolor <<= FB_LEFT_POS(p, bpp);
+ bgcolor <<= FB_LEFT_POS(p, bpp);
for (i = image->height; i--; ) {
shift = val = 0;
@@ -164,7 +162,8 @@ static inline void slow_imageblit(const struct fb_image *image, struct fb_info *
/* write leading bits */
if (start_index) {
- u32 start_mask = ~fb_shifted_pixels_mask_u32(start_index, bswapmask);
+ u32 start_mask = ~fb_shifted_pixels_mask_u32(p,
+ start_index, bswapmask);
val = FB_READL(dst) & start_mask;
shift = start_index;
}
@@ -172,13 +171,13 @@ static inline void slow_imageblit(const struct fb_image *image, struct fb_info *
while (j--) {
l--;
color = (*s & (1 << l)) ? fgcolor : bgcolor;
- val |= FB_SHIFT_HIGH(color, shift ^ bswapmask);
+ val |= FB_SHIFT_HIGH(p, color, shift ^ bswapmask);
/* Did the bitshift spill bits to the next long? */
if (shift >= null_bits) {
FB_WRITEL(val, dst++);
val = (shift == null_bits) ? 0 :
- FB_SHIFT_LOW(color,32 - shift);
+ FB_SHIFT_LOW(p, color, 32 - shift);
}
shift += bpp;
shift &= (32 - 1);
@@ -187,7 +186,8 @@ static inline void slow_imageblit(const struct fb_image *image, struct fb_info *
/* write trailing bits */
if (shift) {
- u32 end_mask = fb_shifted_pixels_mask_u32(shift, bswapmask);
+ u32 end_mask = fb_shifted_pixels_mask_u32(p, shift,
+ bswapmask);
FB_WRITEL((FB_READL(dst) & end_mask) | val, dst);
}
@@ -223,13 +223,13 @@ static inline void fast_imageblit(const struct fb_image *image, struct fb_info *
u32 __iomem *dst;
const u32 *tab = NULL;
int i, j, k;
-
+
switch (bpp) {
case 8:
- tab = cfb_tab8;
+ tab = fb_be_math(p) ? cfb_tab8_be : cfb_tab8_le;
break;
case 16:
- tab = cfb_tab16;
+ tab = fb_be_math(p) ? cfb_tab16_be : cfb_tab16_le;
break;
case 32:
default:
diff --git a/drivers/video/fb_draw.h b/drivers/video/fb_draw.h
index cdafbe1..372755a 100644
--- a/drivers/video/fb_draw.h
+++ b/drivers/video/fb_draw.h
@@ -93,41 +93,44 @@ static inline unsigned long fb_rev_pixels_in_long(unsigned long val,
val = comp(val >> 4, val << 4, REV_PIXELS_MASK4);
}
-static inline u32 fb_shifted_pixels_mask_u32(u32 index, u32 bswapmask)
+static inline u32 fb_shifted_pixels_mask_u32(struct fb_info *p, u32 index,
+ u32 bswapmask)
{
u32 mask;
if (!bswapmask) {
- mask = FB_SHIFT_HIGH(~(u32)0, index);
+ mask = FB_SHIFT_HIGH(p, ~(u32)0, index);
} else {
- mask = 0xff << FB_LEFT_POS(8);
- mask = FB_SHIFT_LOW(mask, index & (bswapmask)) & mask;
- mask = FB_SHIFT_HIGH(mask, index & ~(bswapmask));
+ mask = 0xff << FB_LEFT_POS(p, 8);
+ mask = FB_SHIFT_LOW(p, mask, index & (bswapmask)) & mask;
+ mask = FB_SHIFT_HIGH(p, mask, index & ~(bswapmask));
#if defined(__i386__) || defined(__x86_64__)
/* Shift argument is limited to 0 - 31 on x86 based CPU's */
if(index + bswapmask < 32)
#endif
- mask |= FB_SHIFT_HIGH(~(u32)0,
+ mask |= FB_SHIFT_HIGH(p, ~(u32)0,
(index + bswapmask) & ~(bswapmask));
}
return mask;
}
-static inline unsigned long fb_shifted_pixels_mask_long(u32 index, u32 bswapmask)
+static inline unsigned long fb_shifted_pixels_mask_long(u32 index,
+ struct fb_info *p,
+ u32 bswapmask)
{
unsigned long mask;
if (!bswapmask) {
- mask = FB_SHIFT_HIGH(~0UL, index);
+ mask = FB_SHIFT_HIGH(p, ~0UL, index);
} else {
- mask = 0xff << FB_LEFT_POS(8);
- mask = FB_SHIFT_LOW(mask, index & (bswapmask)) & mask;
- mask = FB_SHIFT_HIGH(mask, index & ~(bswapmask));
+ mask = 0xff << FB_LEFT_POS(p, 8);
+ mask = FB_SHIFT_LOW(p, mask, index & (bswapmask)) & mask;
+ mask = FB_SHIFT_HIGH(p, mask, index & ~(bswapmask));
#if defined(__i386__) || defined(__x86_64__)
/* Shift argument is limited to 0 - 31 on x86 based CPU's */
if(index + bswapmask < BITS_PER_LONG)
#endif
- mask |= FB_SHIFT_HIGH(~0UL,
+ mask |= FB_SHIFT_HIGH(p, ~0UL,
(index + bswapmask) & ~(bswapmask));
}
return mask;
@@ -157,8 +160,8 @@ static inline unsigned long fb_rev_pixels_in_long(unsigned long val,
return val;
}
-#define fb_shifted_pixels_mask_u32(i, b) FB_SHIFT_HIGH(~(u32)0, (i))
-#define fb_shifted_pixels_mask_long(i, b) FB_SHIFT_HIGH(~0UL, (i))
+#define fb_shifted_pixels_mask_u32(p, i, b) FB_SHIFT_HIGH((p), ~(u32)0, (i))
+#define fb_shifted_pixels_mask_long(p, i, b) FB_SHIFT_HIGH((p), ~0UL, (i))
#define fb_compute_bswapmask(...) 0
#endif /* CONFIG_FB_CFB_REV_PIXELS_IN_BYTE */
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 1194f5e..c086004 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1368,6 +1368,7 @@ register_framebuffer(struct fb_info *fb_info)
int i;
struct fb_event event;
struct fb_videomode mode;
+ const bool foreign_endian = fb_info->flags & FBINFO_FOREIGN_ENDIAN;
if (num_registered_fb == FB_MAX)
return -ENXIO;
@@ -1404,6 +1405,13 @@ register_framebuffer(struct fb_info *fb_info)
if (!fb_info->pixmap.blit_y)
fb_info->pixmap.blit_y = ~(u32)0;
+ fb_info->flags &= ~FBINFO_FOREIGN_ENDIAN;
+#ifdef __BIG_ENDIAN
+ fb_info->flags |= foreign_endian ? 0 : FBINFO_BE_MATH;
+#else
+ fb_info->flags |= foreign_endian ? FBINFO_BE_MATH : 0;
+#endif
+
if (!fb_info->modelist.prev || !fb_info->modelist.next)
INIT_LIST_HEAD(&fb_info->modelist);
diff --git a/drivers/video/syscopyarea.c b/drivers/video/syscopyarea.c
index 37af10a..a352d5f 100644
--- a/drivers/video/syscopyarea.c
+++ b/drivers/video/syscopyarea.c
@@ -26,15 +26,15 @@
*/
static void
-bitcpy(unsigned long *dst, int dst_idx, const unsigned long *src,
- int src_idx, int bits, unsigned n)
+bitcpy(struct fb_info *p, unsigned long *dst, int dst_idx,
+ const unsigned long *src, int src_idx, int bits, unsigned n)
{
unsigned long first, last;
int const shift = dst_idx-src_idx;
int left, right;
- first = FB_SHIFT_HIGH(~0UL, dst_idx);
- last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
+ first = FB_SHIFT_HIGH(p, ~0UL, dst_idx);
+ last = ~(FB_SHIFT_HIGH(p, ~0UL, (dst_idx+n) % bits));
if (!shift) {
/* Same alignment for source and dest */
@@ -167,8 +167,8 @@ bitcpy(unsigned long *dst, int dst_idx, const unsigned long *src,
*/
static void
-bitcpy_rev(unsigned long *dst, int dst_idx, const unsigned long *src,
- int src_idx, int bits, unsigned n)
+bitcpy_rev(struct fb_info *p, unsigned long *dst, int dst_idx,
+ const unsigned long *src, int src_idx, int bits, unsigned n)
{
unsigned long first, last;
int shift;
@@ -186,8 +186,8 @@ bitcpy_rev(unsigned long *dst, int dst_idx, const unsigned long *src,
shift = dst_idx-src_idx;
- first = FB_SHIFT_LOW(~0UL, bits - 1 - dst_idx);
- last = ~(FB_SHIFT_LOW(~0UL, bits - 1 - ((dst_idx-n) % bits)));
+ first = FB_SHIFT_LOW(p, ~0UL, bits - 1 - dst_idx);
+ last = ~(FB_SHIFT_LOW(p, ~0UL, bits - 1 - ((dst_idx-n) % bits)));
if (!shift) {
/* Same alignment for source and dest */
@@ -353,7 +353,7 @@ void sys_copyarea(struct fb_info *p, const struct fb_copyarea *area)
dst_idx &= (bytes - 1);
src += src_idx >> (ffs(bits) - 1);
src_idx &= (bytes - 1);
- bitcpy_rev(dst, dst_idx, src, src_idx, bits,
+ bitcpy_rev(p, dst, dst_idx, src, src_idx, bits,
width*p->var.bits_per_pixel);
}
} else {
@@ -362,7 +362,7 @@ void sys_copyarea(struct fb_info *p, const struct fb_copyarea *area)
dst_idx &= (bytes - 1);
src += src_idx >> (ffs(bits) - 1);
src_idx &= (bytes - 1);
- bitcpy(dst, dst_idx, src, src_idx, bits,
+ bitcpy(p, dst, dst_idx, src, src_idx, bits,
width*p->var.bits_per_pixel);
dst_idx += bits_per_line;
src_idx += bits_per_line;
diff --git a/drivers/video/sysfillrect.c b/drivers/video/sysfillrect.c
index a261e9e..f94d6b6 100644
--- a/drivers/video/sysfillrect.c
+++ b/drivers/video/sysfillrect.c
@@ -22,16 +22,16 @@
*/
static void
-bitfill_aligned(unsigned long *dst, int dst_idx, unsigned long pat,
- unsigned n, int bits)
+bitfill_aligned(struct fb_info *p, unsigned long *dst, int dst_idx,
+ unsigned long pat, unsigned n, int bits)
{
unsigned long first, last;
if (!n)
return;
- first = FB_SHIFT_HIGH(~0UL, dst_idx);
- last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
+ first = FB_SHIFT_HIGH(p, ~0UL, dst_idx);
+ last = ~(FB_SHIFT_HIGH(p, ~0UL, (dst_idx+n) % bits));
if (dst_idx+n <= bits) {
/* Single word */
@@ -78,16 +78,16 @@ bitfill_aligned(unsigned long *dst, int dst_idx, unsigned long pat,
*/
static void
-bitfill_unaligned(unsigned long *dst, int dst_idx, unsigned long pat,
- int left, int right, unsigned n, int bits)
+bitfill_unaligned(struct fb_info *p, unsigned long *dst, int dst_idx,
+ unsigned long pat, int left, int right, unsigned n, int bits)
{
unsigned long first, last;
if (!n)
return;
- first = FB_SHIFT_HIGH(~0UL, dst_idx);
- last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
+ first = FB_SHIFT_HIGH(p, ~0UL, dst_idx);
+ last = ~(FB_SHIFT_HIGH(p, ~0UL, (dst_idx+n) % bits));
if (dst_idx+n <= bits) {
/* Single word */
@@ -132,8 +132,8 @@ bitfill_unaligned(unsigned long *dst, int dst_idx, unsigned long pat,
* Aligned pattern invert using 32/64-bit memory accesses
*/
static void
-bitfill_aligned_rev(unsigned long *dst, int dst_idx, unsigned long pat,
- unsigned n, int bits)
+bitfill_aligned_rev(struct fb_info *p, unsigned long *dst, int dst_idx,
+ unsigned long pat, unsigned n, int bits)
{
unsigned long val = pat;
unsigned long first, last;
@@ -141,8 +141,8 @@ bitfill_aligned_rev(unsigned long *dst, int dst_idx, unsigned long pat,
if (!n)
return;
- first = FB_SHIFT_HIGH(~0UL, dst_idx);
- last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
+ first = FB_SHIFT_HIGH(p, ~0UL, dst_idx);
+ last = ~(FB_SHIFT_HIGH(p, ~0UL, (dst_idx+n) % bits));
if (dst_idx+n <= bits) {
/* Single word */
@@ -188,16 +188,17 @@ bitfill_aligned_rev(unsigned long *dst, int dst_idx, unsigned long pat,
*/
static void
-bitfill_unaligned_rev(unsigned long *dst, int dst_idx, unsigned long pat,
- int left, int right, unsigned n, int bits)
+bitfill_unaligned_rev(struct fb_info *p, unsigned long *dst, int dst_idx,
+ unsigned long pat, int left, int right, unsigned n,
+ int bits)
{
unsigned long first, last;
if (!n)
return;
- first = FB_SHIFT_HIGH(~0UL, dst_idx);
- last = ~(FB_SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
+ first = FB_SHIFT_HIGH(p, ~0UL, dst_idx);
+ last = ~(FB_SHIFT_HIGH(p, ~0UL, (dst_idx+n) % bits));
if (dst_idx+n <= bits) {
/* Single word */
@@ -267,9 +268,9 @@ void sys_fillrect(struct fb_info *p, const struct fb_fillrect *rect)
if (p->fbops->fb_sync)
p->fbops->fb_sync(p);
if (!left) {
- void (*fill_op32)(unsigned long *dst, int dst_idx,
- unsigned long pat, unsigned n, int bits) =
- NULL;
+ void (*fill_op32)(struct fb_info *p, unsigned long *dst,
+ int dst_idx, unsigned long pat, unsigned n,
+ int bits) = NULL;
switch (rect->rop) {
case ROP_XOR:
@@ -287,16 +288,16 @@ void sys_fillrect(struct fb_info *p, const struct fb_fillrect *rect)
while (height--) {
dst += dst_idx >> (ffs(bits) - 1);
dst_idx &= (bits - 1);
- fill_op32(dst, dst_idx, pat, width*bpp, bits);
+ fill_op32(p, dst, dst_idx, pat, width*bpp, bits);
dst_idx += p->fix.line_length*8;
}
} else {
int right;
int r;
int rot = (left-dst_idx) % bpp;
- void (*fill_op)(unsigned long *dst, int dst_idx,
- unsigned long pat, int left, int right,
- unsigned n, int bits) = NULL;
+ void (*fill_op)(struct fb_info *p, unsigned long *dst,
+ int dst_idx, unsigned long pat, int left,
+ int right, unsigned n, int bits) = NULL;
/* rotate pattern to correct start position */
pat = pat << rot | pat >> (bpp-rot);
@@ -318,7 +319,7 @@ void sys_fillrect(struct fb_info *p, const struct fb_fillrect *rect)
while (height--) {
dst += dst_idx >> (ffs(bits) - 1);
dst_idx &= (bits - 1);
- fill_op(dst, dst_idx, pat, left, right,
+ fill_op(p, dst, dst_idx, pat, left, right,
width*bpp, bits);
r = (p->fix.line_length*8) % bpp;
pat = pat << (bpp-r) | pat >> r;
diff --git a/drivers/video/sysimgblt.c b/drivers/video/sysimgblt.c
index bd7e7e9..88daa9b 100644
--- a/drivers/video/sysimgblt.c
+++ b/drivers/video/sysimgblt.c
@@ -23,30 +23,26 @@
#define DPRINTK(fmt, args...)
#endif
-static const u32 cfb_tab8[] = {
-#if defined(__BIG_ENDIAN)
+static const u32 cfb_tab8_be[] = {
0x00000000,0x000000ff,0x0000ff00,0x0000ffff,
0x00ff0000,0x00ff00ff,0x00ffff00,0x00ffffff,
0xff000000,0xff0000ff,0xff00ff00,0xff00ffff,
0xffff0000,0xffff00ff,0xffffff00,0xffffffff
-#elif defined(__LITTLE_ENDIAN)
+};
+
+static const u32 cfb_tab8_le[] = {
0x00000000,0xff000000,0x00ff0000,0xffff0000,
0x0000ff00,0xff00ff00,0x00ffff00,0xffffff00,
0x000000ff,0xff0000ff,0x00ff00ff,0xffff00ff,
0x0000ffff,0xff00ffff,0x00ffffff,0xffffffff
-#else
-#error FIXME: No endianness??
-#endif
};
-static const u32 cfb_tab16[] = {
-#if defined(__BIG_ENDIAN)
+static const u32 cfb_tab16_be[] = {
0x00000000, 0x0000ffff, 0xffff0000, 0xffffffff
-#elif defined(__LITTLE_ENDIAN)
+};
+
+static const u32 cfb_tab16_le[] = {
0x00000000, 0xffff0000, 0x0000ffff, 0xffffffff
-#else
-#error FIXME: No endianness??
-#endif
};
static const u32 cfb_tab32[] = {
@@ -72,7 +68,7 @@ static void color_imageblit(const struct fb_image *image, struct fb_info *p,
val = 0;
if (start_index) {
- u32 start_mask = ~(FB_SHIFT_HIGH(~(u32)0,
+ u32 start_mask = ~(FB_SHIFT_HIGH(p, ~(u32)0,
start_index));
val = *dst & start_mask;
shift = start_index;
@@ -83,20 +79,20 @@ static void color_imageblit(const struct fb_image *image, struct fb_info *p,
color = palette[*src];
else
color = *src;
- color <<= FB_LEFT_POS(bpp);
- val |= FB_SHIFT_HIGH(color, shift);
+ color <<= FB_LEFT_POS(p, bpp);
+ val |= FB_SHIFT_HIGH(p, color, shift);
if (shift >= null_bits) {
*dst++ = val;
val = (shift == null_bits) ? 0 :
- FB_SHIFT_LOW(color, 32 - shift);
+ FB_SHIFT_LOW(p, color, 32 - shift);
}
shift += bpp;
shift &= (32 - 1);
src++;
}
if (shift) {
- u32 end_mask = FB_SHIFT_HIGH(~(u32)0, shift);
+ u32 end_mask = FB_SHIFT_HIGH(p, ~(u32)0, shift);
*dst &= end_mask;
*dst |= val;
@@ -125,8 +121,8 @@ static void slow_imageblit(const struct fb_image *image, struct fb_info *p,
u32 i, j, l;
dst2 = dst1;
- fgcolor <<= FB_LEFT_POS(bpp);
- bgcolor <<= FB_LEFT_POS(bpp);
+ fgcolor <<= FB_LEFT_POS(p, bpp);
+ bgcolor <<= FB_LEFT_POS(p, bpp);
for (i = image->height; i--; ) {
shift = val = 0;
@@ -137,7 +133,8 @@ static void slow_imageblit(const struct fb_image *image, struct fb_info *p,
/* write leading bits */
if (start_index) {
- u32 start_mask = ~(FB_SHIFT_HIGH(~(u32)0,start_index));
+ u32 start_mask = ~(FB_SHIFT_HIGH(p, ~(u32)0,
+ start_index));
val = *dst & start_mask;
shift = start_index;
}
@@ -145,13 +142,13 @@ static void slow_imageblit(const struct fb_image *image, struct fb_info *p,
while (j--) {
l--;
color = (*s & (1 << l)) ? fgcolor : bgcolor;
- val |= FB_SHIFT_HIGH(color, shift);
+ val |= FB_SHIFT_HIGH(p, color, shift);
/* Did the bitshift spill bits to the next long? */
if (shift >= null_bits) {
*dst++ = val;
val = (shift == null_bits) ? 0 :
- FB_SHIFT_LOW(color,32 - shift);
+ FB_SHIFT_LOW(p, color, 32 - shift);
}
shift += bpp;
shift &= (32 - 1);
@@ -160,7 +157,7 @@ static void slow_imageblit(const struct fb_image *image, struct fb_info *p,
/* write trailing bits */
if (shift) {
- u32 end_mask = FB_SHIFT_HIGH(~(u32)0, shift);
+ u32 end_mask = FB_SHIFT_HIGH(p, ~(u32)0, shift);
*dst &= end_mask;
*dst |= val;
@@ -199,10 +196,10 @@ static void fast_imageblit(const struct fb_image *image, struct fb_info *p,
switch (bpp) {
case 8:
- tab = cfb_tab8;
+ tab = fb_be_math(p) ? cfb_tab8_be : cfb_tab8_le;
break;
case 16:
- tab = cfb_tab16;
+ tab = fb_be_math(p) ? cfb_tab16_be : cfb_tab16_le;
break;
case 32:
default:
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 58c57a3..a6de45e 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -791,6 +791,17 @@ struct fb_tile_ops {
*/
#define FBINFO_MISC_ALWAYS_SETPAR 0x40000
+/*
+ * Host and GPU endianness differ.
+ */
+#define FBINFO_FOREIGN_ENDIAN 0x100000
+/*
+ * Big endian math. This is the same flags as above, but with different
+ * meaning, it is set by the fb subsystem depending FOREIGN_ENDIAN flag
+ * and host endianness. Drivers should not use this flag.
+ */
+#define FBINFO_BE_MATH 0x100000
+
struct fb_info {
int node;
int flags;
@@ -899,15 +910,11 @@ struct fb_info {
#endif
-#if defined (__BIG_ENDIAN)
-#define FB_LEFT_POS(bpp) (32 - bpp)
-#define FB_SHIFT_HIGH(val, bits) ((val) >> (bits))
-#define FB_SHIFT_LOW(val, bits) ((val) << (bits))
-#else
-#define FB_LEFT_POS(bpp) (0)
-#define FB_SHIFT_HIGH(val, bits) ((val) << (bits))
-#define FB_SHIFT_LOW(val, bits) ((val) >> (bits))
-#endif
+#define FB_LEFT_POS(p, bpp) (fb_be_math(p) ? (32 - bpp) : 0)
+#define FB_SHIFT_HIGH(p, val, bits) (fb_be_math(p) ? (val) >> (bits) : \
+ (val) << (bits))
+#define FB_SHIFT_LOW(p, val, bits) (fb_be_math(p) ? (val) << (bits) : \
+ (val) >> (bits))
/*
* `Generic' versions of the frame buffer device operations
@@ -970,6 +977,11 @@ extern void fb_deferred_io_cleanup(struct fb_info *info);
extern int fb_deferred_io_fsync(struct file *file, struct dentry *dentry,
int datasync);
+static inline bool fb_be_math(struct fb_info *info)
+{
+ return info->flags & FBINFO_BE_MATH;
+}
+
/* drivers/video/fbsysfs.c */
extern struct fb_info *framebuffer_alloc(size_t size, struct device *dev);
extern void framebuffer_release(struct fb_info *info);
--
1.5.2.2
^ permalink raw reply related
* [PATCH 2/2] [POWERPC] offb: add support for foreign endianness
From: Anton Vorontsov @ 2008-02-05 15:44 UTC (permalink / raw)
To: adaplas, linux-kernel; +Cc: linuxppc-dev
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/video/offb.c | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/video/offb.c b/drivers/video/offb.c
index 452433d..d7b3dcc 100644
--- a/drivers/video/offb.c
+++ b/drivers/video/offb.c
@@ -248,7 +248,7 @@ static void __iomem *offb_map_reg(struct device_node *np, int index,
static void __init offb_init_fb(const char *name, const char *full_name,
int width, int height, int depth,
int pitch, unsigned long address,
- struct device_node *dp)
+ int foreign_endian, struct device_node *dp)
{
unsigned long res_size = pitch * height * (depth + 7) / 8;
struct offb_par *par = &default_par;
@@ -397,7 +397,7 @@ static void __init offb_init_fb(const char *name, const char *full_name,
info->screen_base = ioremap(address, fix->smem_len);
info->par = par;
info->pseudo_palette = (void *) (info + 1);
- info->flags = FBINFO_DEFAULT;
+ info->flags = FBINFO_DEFAULT | foreign_endian;
fb_alloc_cmap(&info->cmap, 256, 0);
@@ -424,6 +424,15 @@ static void __init offb_init_nodriver(struct device_node *dp, int no_real_node)
u64 rstart, address = OF_BAD_ADDR;
const u32 *pp, *addrp, *up;
u64 asize;
+ int foreign_endian = 0;
+
+#ifdef __BIG_ENDIAN
+ if (of_get_property(dp, "little-endian", NULL))
+ foreign_endian = FBINFO_FOREIGN_ENDIAN;
+#else
+ if (of_get_property(dp, "big-endian", NULL))
+ foreign_endian = FBINFO_FOREIGN_ENDIAN;
+#endif
pp = of_get_property(dp, "linux,bootx-depth", &len);
if (pp == NULL)
@@ -509,7 +518,7 @@ static void __init offb_init_nodriver(struct device_node *dp, int no_real_node)
offb_init_fb(no_real_node ? "bootx" : dp->name,
no_real_node ? "display" : dp->full_name,
width, height, depth, pitch, address,
- no_real_node ? NULL : dp);
+ foreign_endian, no_real_node ? NULL : dp);
}
}
--
1.5.2.2
^ permalink raw reply related
* [Virtex4] kernel2.6 or distribution
From: Desroches L. @ 2008-02-05 15:48 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Sorry for my English, I am a French student. For my internship, I have to
implement Linux on a Virtex4.
I know a few things about the Virtex4 because I am specialized in digital
electronic (VHDL). I have to choose a solution for the Linux to implement.
At this stage, I have some problems to determine the best solution probably
because things are not clear for me whereas I have read a book about Linux
embedded and seen a lot of websites.
I have seen several distributions (maybe my vocable is false) from
MontaVista, LynuxWorks and others. I have seen also kernel2.6 for Virtex4
(http://git.xilinx.com/cgi-bin/gitweb.cgi?p=3Dlinux-2.6-xlnx.git;a=3Dsummar=
y). I
would like to understand the difference between these two things.
If I have understood MontaVista for example offers a solution with a C
library and drivers, isn't it ? So is it a better solution than kernel2.6 ?
I prefer to start with the kernel given by xilinx, it is an internship so
the aim is to learn the more I can but I have to convince my tutor that it
is a better solution than MontaVista, BlueCat or =C2=B5C/OSII. Do you have =
some
arguments ?
Thanks for your help
Best Regards
---
Desroches Ludovic
ESIEE engineer : http://www.esiee.fr
--=20
View this message in context: http://www.nabble.com/-Virtex4--kernel2.6-or-=
distribution-tp15291528p15291528.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 5/6] Add OF-tree support to RapidIO controller driver.
From: Kumar Gala @ 2008-02-05 16:06 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080205164425.b6af5bff.sfr@canb.auug.org.au>
On Feb 4, 2008, at 11:44 PM, Stephen Rothwell wrote:
>>
>> + aw = *(u32 *)of_get_property(dev->node, "#address-cells", NULL);
>> + sw = *(u32 *)of_get_property(dev->node, "#size-cells", NULL);
>
> What happens if either of these properties is missing?
Should we add __must_check to of_get_property?
- k
^ permalink raw reply
* Kernel entry point
From: Marco Stornelli @ 2008-02-05 16:10 UTC (permalink / raw)
To: LinuxPPC-Embedded
Hi,
where is the main kernel entry point (the first function/instruction)
for the powerpc arch called by uboot? In kernel 2.6.10 there was the
head_fsl_booke.S (I'm using a booke processor) that it called the
start_kernel function, and now?
Thanks.
Marco
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Olof Johansson @ 2008-02-05 16:10 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Bernhard Reiter, debian-powerpc, paulus
In-Reply-To: <20080205093820.5918a216@zod.rchland.ibm.com>
On Tue, Feb 05, 2008 at 09:38:20AM -0600, Josh Boyer wrote:
> Taking a step back though, there will always be odd cases like this as
> we move forward. Toolchain XXX will eventually not support instruction
> YYYY which will eventually be used, etc. I'll try to make this
> specific case work because it's scope is quite limited. But this
> problem as a whole will still remain.
Worst case, if it's only a couple of instructions, they could be covered
the way we usually handle new instructions in the ISA: make a macro for
them and hand-encode them.
See real_205_{read,write}b() in arch/powerpc/kernel/misc_64.S for
example.
-Olof
^ permalink raw reply
* Re: [PATCH 4/6] Add multi mport support.
From: Matt Porter @ 2008-02-05 16:23 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <ABF87B0B6A38C0458E319AC973ED68AEBD0677@zch01exm26.fsl.freescale.net>
On Thu, Jan 31, 2008 at 01:57:25PM +0800, Zhang Wei wrote:
>
>
> > -----Original Message-----
> > From: Kumar Gala [mailto:galak@kernel.crashing.org]
> >
> > On Jan 30, 2008, at 4:30 AM, Zhang Wei wrote:
> >
> > > Change lots of static variable to mport private. And add
> > mport to some
> > > function declaration.
> >
> > Can you explain this patch further. Its not clear exactly from this
> > commit message why we are doing this.
> >
> > - k
>
> Sorry about I have a little hurry about it.
>
> The original RapidIO driver suppose there is only one mpc85xx RIO
> controller
> in system. So, some data structures are defined as mpc85xx_rio global,
> such as 'regs_win', 'dbell_ring', 'msg_tx_ring'. Now, I changed them to
> mport's private members. And you can define multi RIO OF-nodes in dts
> file
> for multi RapidIO controller in one processor, such as PCI/PCI-Ex host
> controllers
> in Freescale's silicon. And the mport operation function declaration
> should be changed
> to know which RapidIO controller is target.
Right, the RapidIO subsystem itself has had the concept of multiple
master ports from the beginning. However, when I did the MPC85xx
support I chose to just implement it for the known silicon available
at the time. I'm not surprised there's new silicon with multiple
controllers now.
-Matt
^ permalink raw reply
* Re: [PATCH 4/6] Add multi mport support.
From: Matt Porter @ 2008-02-05 16:29 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <ABF87B0B6A38C0458E319AC973ED68AEBD0697@zch01exm26.fsl.freescale.net>
On Thu, Jan 31, 2008 at 02:30:13PM +0800, Zhang Wei wrote:
> > -----Original Message-----
> > From: Kumar Gala [mailto:galak@kernel.crashing.org]
> > when we have multiple ports are the device IDs on the ports intended
> > to be unique only to a port or unique across all ports?
> >
> I consider each RIO controller will has its own network, the device IDs
> should be
> unique only in its port network.
This is a bad assumption IMHO. It pushes policy on to the system
designer of a RapidIO network.
It is very possible to use multiple controllers as entry points
in a single RapidIO network fabric space. The reason one would do this
is to provide optimized paths to some endpoints in the system.
If possible, there should never be a policy assumption like this in
kernel space. It's much better to assume that one may or may not
have a unique id space.
-Matt
^ permalink raw reply
* Re: Problems booting in ML403
From: Grant Likely @ 2008-02-05 16:24 UTC (permalink / raw)
To: A. Nolson; +Cc: linuxppc-embedded
In-Reply-To: <47A8782E.4050402@gmail.com>
On 2/5/08, A. Nolson <alohanono@gmail.com> wrote:
> Hello,
>
> I am having problems while trying to boot my linux kernel 2.6.24-rc3 (
> secretlab git). After some days studying this list and other related
> documents/wikis about how to make work a linux kernel in my ML403, I
> managed to make it work partially.
>
<snip>
>
>
> Linux/PPC load: console=ttyS0,9600 console=tty0,9600 console=ttyUL0,9600
> root=/d
> ev/xsa2 rw
> init=/sbin/init
What happens if you try init=/bin/sh?
What does your /etc/inittab look like?
It looks like the system is booting, but inittab might not be starting
any processes attached to the serial console.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] [POWERPC] get rid of `model = "UCC"' in the ucc nodes
From: Grant Likely @ 2008-02-05 16:39 UTC (permalink / raw)
To: Grant Likely, Kumar Gala, Jon Loeliger, linuxppc-dev, Scott Wood
In-Reply-To: <20080205132026.GE7983@localhost.localdomain>
On 2/5/08, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Fri, Feb 01, 2008 at 09:23:47AM -0700, Grant Likely wrote:
> > cell-index has been useful for things like clock controllers to know
> > what offset into a shared clock control register or something like
> > that and a driver would pass the cell-index value to the shared reg
> > driver when requesting service.
>
> Right. Except that if the shared resource is just a single register,
> calling the routines to access it a "shared reg driver" gives a
> misleading impression. Depending on how the shared reg is used, even
> a lock may not be necessary, so potentially the drivers for the
> individual device instances using the shared resource can (safely)
> directly access it.
Fair enough. In the case of a single shared, or a homogeneous set of
shared registers (all of them use the same index) I can see the
argument for cell index.
However, there are places where cell-index is being used where the
value of cell-index has no relation to the offset into a register.
But what about the case where the device uses multiple shared
registers, each one using a *different* offset. cell-index doesn't
describe this situation well (or at least no better than just using
the value of reg instead, a translation is still required)
> > Typically, shared registers and the like are all chip specific and the
> > behaviour of the shared register drivers usually needs to be tweaked
> > for different SoCs. Each ip core on an SoC is already uniquely
> > indexed via the reg property. True, 'reg' is sparse (0x2000, 0x2200,
> > 0x2300, ...) whereas cell-index is tight (0,1,2,3,...), but I don't
> > think that introduces any additional difficulty.
> >
> > So, instead of a driver passing it's cell-index value to the shared
> > reg driver, it would pass it's reg base instead. The shared register
> > driver could then choose an internal representation that makes sense
> > for it instead of whatever layout was chosen by the device tree.
>
> Except that the "shared reg driver" then needs a way to map from reg
> property to index. So either it has to have that hardcoded, or the
> shared resource will need its own device tree representation for the
> mapping.
SoCs are fickle things; Writing code to handle differences between the
same devices on different SoCs is going to happen anyway. Isn't that
what a device driver is for? :-)
>
> In some cases the shared resource is complex enough that that makes
> sense (e.g. an mdio bus shared between ethernet MACs to take an
> extreme example). But when the "shared reg driver" consists entirely
> of:
> (readl(shared_reg_addr) & (1UL << cell_index))
> and/or:
> writel(shared_reg_addr, 1UL << cell_index)
> your approach would seem to be overkill and then some. (The latter
> example can be safe without locking in the case of a read/clear
> register).
>
> Exactly this sort of thing is fairly common on 4xx, which is just the
> context in which BenH invented "cell-index" as a really simple way of
> representing the index into shared registers like this.
>From booting-without-of (in the EMAC description):
- cell-index : 1 cell, hardware index of the EMAC cell on a
given ASIC (typically 0x0 and 0x1 for EMAC0 and EMAC1 on each Axon
chip.
So, even if the intent was for cell-index to specify offsets into
shared regs, the description does not reflect that purpose. And
reading thorough the rest of the document, cell-index is described
purely in terms of enumerating ip blocks, so that is clearly the
assumption that people are making when using it.
In other words, my point is this: *If* cell-index is just a way to
encode the manufacturing assigned ip-block number (EMAC0, EMAC1, etc)
then there is probably little or no value in it. The two arguments I
see for using cell-index in that mode are:
1) to offset into shared registers (but this doesn't hold because ip
block numbers often don't match register offsets and the reg property
would be just as suitable)
2) to logically identify ip blocks to the user (but cell-index was
never intended for this and /aliases is a better solution anyway)
> > Dropping cell-index would mean one less property to keep in sync when
> > tailoring device trees. (== less complexity for board porters).
> > Besides, the purpose of cell-index is often misunderstood already by
> > people trying to use it to describe port numbers (ttyS0, ttyS1, etc).
>
> This is indeed a problem. But I don't think ditching cell-index
> entirely is a sensible solution, sorry.
Gah! Don't apologize! :-) My goal was to spur on debate to better
firm up our device tree conventions. Mission accomplished (or at
least in progress.) :-)
Also, I can probably be convinced on the continued usage of
cell-index, but as it stands right now I think we're over using it.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 6/6] Change the kernel configurated RapidIO system size to auto-probing.
From: Matt Porter @ 2008-02-05 16:43 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <12016890873190-git-send-email-wei.zhang@freescale.com>
On Wed, Jan 30, 2008 at 06:30:53PM +0800, Zhang Wei wrote:
> The RapidIO system size will auto probe in RIO setup. The route
> table and rionet_active in rionet.c are changed to be allocated
> dynamically according the system size.
<snip>
> + port->sys_size = (in_be32((priv->regs_win + RIO_PEF_CAR))
> + & RIO_PEF_CTLS) >> 4;
> + dev_info(&dev->dev, "RapidIO Common Transport System size: %d\n",
> + port->sys_size ? 65536 : 256);
> +
This is much nicer than the original hardcoded transport size
implementation.
-Matt
^ permalink raw reply
* Re: [PATCH 2/10] sbc8560: Add v1 device tree source for Wind River SBC8560 board
From: Paul Gortmaker @ 2008-02-05 16:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: david
In-Reply-To: <20080201075408.GC18684@localhost.localdomain>
In message: Re: [PATCH 2/10] sbc8560: Add v1 device tree source for Wind River SBC8560 board
on 01/02/2008 David Gibson wrote:
> On Thu, Jan 24, 2008 at 06:41:24PM -0500, Paul Gortmaker wrote:
> > This adds a v1 device tree source for the Wind River SBC8560 board. The
> > biggest difference between this and the MPC8560ADS reference platform
> > dts is the use of an external 16550 compatible UART instead of the CPM2.
> >
> > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> [snip]
> > +/dts-v1/;
> > +
> > +/ {
> > + model = "SBC8560";
> > + compatible = "SBC8560";
>
> This is not the conventional format for board-level compatible
> entries, which should generally be "vendor,model" and all in lower
> case.
No problem - I can change to "sbc8560" and "wrs,sbc8560" on this board
and others.
>
> [snip]
> > + enet0: ethernet@24000 {
> > + cell-index = <0>;
> > + device_type = "network";
> > + model = "TSEC";
> > + compatible = "gianfar";
>
> This looks like the old dodgy gianfar binding, and needs updating
> (mdio node will probably also need changes).
I thought I'd merged in all Kumar's updates to the gianfar nodes at that
point in time, but I'll go back and re-check.
>
> [snip]
> > + localbus@ff705000 {
> > + compatible = "fsl,mpc8560-localbus";
> > + #address-cells = <2>;
> > + #size-cells = <1>;
> > + reg = <0xff705000 0x100>; // BRx, ORx, etc.
> > +
> > + ranges = <
> > + 0x0 0x0 0xff800000 0x0800000 // 8MB boot flash
> > + 0x1 0x0 0xe4000000 0x4000000 // 64MB flash
> > + 0x3 0x0 0x20000000 0x4000000 // 64MB SDRAM
> > + 0x4 0x0 0x24000000 0x4000000 // 64MB SDRAM
> > + 0x5 0x0 0xfc000000 0x0c00000 // EPLD
> > + 0x6 0x0 0xe0000000 0x4000000 // 64MB flash
> > + 0x7 0x0 0x80000000 0x0200000 // ATM1,2
> > + >;
> > +
> > + epld@5,0 {
>
> I'm not entirely convinced on this two-level representation. I think
> the FSL people need to get together and define a binding (or set of
> bindings) for their various chipselect style external bus bridges.
I'd tried to capture what you'd outlined for the localbus node, and the
epld child seemed like a natural extension of that. I suspect that a
lot of boards would just have the localbus node and not the extra node
that fans things out a step further. There wasn't really any similar
precedent for that to work off of that I noticed. I'm agreeable to
change or restructuring if Kumar recommends re-using some standard as
set by the 4xx/EBC.
Paul.
>
> > + compatible = "wrs,epld-localbus";
> > + #address-cells = <2>;
> > + #size-cells = <1>;
> > + reg = <0x5 0x0 0xc00000>;
> > + ranges = <
> > + 0x0 0x0 0x5 0x000000 0x1fff // LED disp.
> > + 0x1 0x0 0x5 0x100000 0x1fff // switches
> > + 0x2 0x0 0x5 0x200000 0x1fff // ID reg.
> > + 0x3 0x0 0x5 0x300000 0x1fff // status reg.
> > + 0x4 0x0 0x5 0x400000 0x1fff // reset reg.
> > + 0x5 0x0 0x5 0x500000 0x1fff // Wind port
> > + 0x7 0x0 0x5 0x700000 0x1fff // UART #1
> > + 0x8 0x0 0x5 0x800000 0x1fff // UART #2
> > + 0x9 0x0 0x5 0x900000 0x1fff // RTC
> > + 0xb 0x0 0x5 0xb00000 0x1fff // EEPROM
> > + >;
>
> --
> 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
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