* Re: [F]Framebuffer driver using SM501 hardware.
From: Clemens Koller @ 2005-08-17 11:04 UTC (permalink / raw)
To: Andrey Volkov; +Cc: linuxppc-dev
In-Reply-To: <43030D41.3000508@varma-el.com>
Hi, Andrey!
It would be great to have our code collected somewhere in a public
cvs/git archive.
There are also some patches to add (accelerated) SM501 support to
the latest X somewhere in atmosphere:
https://bugs.freedesktop.org/attachment.cgi?id=1775
I will be able to help you with some hacking/testing with the
SM501 on PCI on ppc/MPC8540 in the future.
Greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
Andrey Volkov wrote:
> I (now :)) working on it too.
>
> Unfortunately, due to terrible SM docos/examples,
> I rewrite/write some parts from scratch :(
> (mainly based on Applied Data Systems drivers for PXA).
> Currently my driver(s) in prerelease stage. It provide:
>
> - PCI/bus infra.
> - CRT or LCD fb (dual head in progress,
> I hope, on next week it will be done).
> - hwd cursor
> - hwd accel (bitblit/fill rect/color expand)
> - I2C/DDC (software, due to silicon bug in SM501)
> - CI (Command List Interpreter) partially supported
> (problems in PCI mode: when it work as master with
> MPC5200, some data are lost, needed investigation).
>
> Todo:
> - 16 bpp colormap (needed reverse endian support in fbcon/fbmem)
> - Alpha (have not ideas how to use it in fb/X)
> - Video (same as above)
> - Platform driver (it will not too hard to write it,
> but all boards, which I have, are PCI based)
> - USB host (in progress)
> - USB slave
> - Full CI support.
> - UART/SPI/AC97....
>
> To whom it is interesting, I could send my current code
> (not too little). And, if smb will wish fix/expand...,
> I could (temporally) create cvs on sf.net.
>
> Wolfgang Denk wrote:
>
>>In message <43022F05.3050409@anagramm.de> you wrote:
>>
>>
>>>I was working with the SM501 framebuffer for a while on
>>>linux-2.6.
>>
>>
>>...and we did in the context of our 2.4 kernel.
>>
>>
>>
>>>There is a color-mapping issue left (RGB is swapped on powerpc)
>>>and it needs lots of code cleanup or a complete rewrite.
>>
>>
>>I think we fixed some of these problems, and I have a couple of other
>>patches sitting in my queue. Anybody interested can (1) have a look
>>at our tree and (2) mail me.
>>
>>Best regards,
>>
>>Wolfgang Denk
>
> ----------------
>
>>In message <BPEMKMADCCCPHPEDDKOOMEHFCFAA.surendra.yadav@softdel.com> you wrote:
>>
>>
>>>>I am writing framebuffer driver using SM501. This graphics driver chip can
>>
>>
>>Why are you re-inventing the wheel?
>
> Because I (for ex.) don't use nor QT, nor X :) and I use 2.6 kernel.
> Also I need USB/AC97... support.
>
^ permalink raw reply
* Re: [F]Framebuffer driver using SM501 hardware.
From: Andrey Volkov @ 2005-08-17 10:11 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, surendra.yadav
In-Reply-To: <20050816194825.A62AC353AB5@atlas.denx.de>
I (now :)) working on it too.
Unfortunately, due to terrible SM docos/examples,
I rewrite/write some parts from scratch :(
(mainly based on Applied Data Systems drivers for PXA).
Currently my driver(s) in prerelease stage. It provide:
- PCI/bus infra.
- CRT or LCD fb (dual head in progress,
I hope, on next week it will be done).
- hwd cursor
- hwd accel (bitblit/fill rect/color expand)
- I2C/DDC (software, due to silicon bug in SM501)
- CI (Command List Interpreter) partially supported
(problems in PCI mode: when it work as master with
MPC5200, some data are lost, needed investigation).
Todo:
- 16 bpp colormap (needed reverse endian support in fbcon/fbmem)
- Alpha (have not ideas how to use it in fb/X)
- Video (same as above)
- Platform driver (it will not too hard to write it,
but all boards, which I have, are PCI based)
- USB host (in progress)
- USB slave
- Full CI support.
- UART/SPI/AC97....
To whom it is interesting, I could send my current code
(not too little). And, if smb will wish fix/expand...,
I could (temporally) create cvs on sf.net.
Wolfgang Denk wrote:
> In message <43022F05.3050409@anagramm.de> you wrote:
>
>>I was working with the SM501 framebuffer for a while on
>>linux-2.6.
>
>
> ...and we did in the context of our 2.4 kernel.
>
>
>>There is a color-mapping issue left (RGB is swapped on powerpc)
>>and it needs lots of code cleanup or a complete rewrite.
>
>
> I think we fixed some of these problems, and I have a couple of other
> patches sitting in my queue. Anybody interested can (1) have a look
> at our tree and (2) mail me.
>
> Best regards,
>
> Wolfgang Denk
----------------
>
> In message <BPEMKMADCCCPHPEDDKOOMEHFCFAA.surendra.yadav@softdel.com> you wrote:
>
>>>
>>> I am writing framebuffer driver using SM501. This graphics driver chip can
>
>
> Why are you re-inventing the wheel?
Because I (for ex.) don't use nor QT, nor X :) and I use 2.6 kernel.
Also I need USB/AC97... support.
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: [PATCH] ppc32: removed usage of <asm/segment.h>
From: Miklos Szeredi @ 2005-08-17 10:07 UTC (permalink / raw)
To: hch; +Cc: akpm, zach, linux-kernel, linuxppc-dev, galak, davem
In-Reply-To: <20050817092041.GA12910@infradead.org>
> > They are provided by _one_ kernel, not necessarily the running kernel.
>
> No, they're provided by packages like glibc-kernheaders or similar
> that are maintained separately.
Yes. And "maintenance" I presume means "copy" the kernel headers and
do some cleanup to be compliant to the relevant standards (which the
kernel maintainers couldn't be bothered to do).
> They're split from the kernel headers and we don't need to keep
> obsolete junk around.
I agree about obsolete junk.
However statements like "No kernel headers can be included by userland
anymore" can be slightly misleading.
Miklos
^ permalink raw reply
* Re: [PATCH] ppc32: removed usage of <asm/segment.h>
From: Miklos Szeredi @ 2005-08-17 8:56 UTC (permalink / raw)
To: hch; +Cc: akpm, zach, linux-kernel, linuxppc-dev, galak, davem
In-Reply-To: <20050817083048.GA11892@infradead.org>
> On Wed, Aug 17, 2005 at 12:43:37AM -0500, Kumar Gala wrote:
> > >I concur, in fact we should really kill that thing off entirely.
> >
> > I'm all for killing it off entirely but got some feedback that on
> > i386 segment.h can be included by userspace programs.
>
> No kernel headers can be included by userland anymore.
I know nothing about <asm/segment.h> but this generic statement is
simply not true.
There are perfectly valid uses of kernel headers from userspace. For
example if a program uses the netlink interface, it should include
<linux/netlink.h>. It's the interface definition after all.
Glibc headers also include <linux/*> and <asm/*> in quite few places.
Miklos
^ permalink raw reply
* Re: [PATCH] ppc32: removed usage of <asm/segment.h>
From: Christoph Hellwig @ 2005-08-17 9:20 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: akpm, zach, linux-kernel, hch, linuxppc-dev, galak, davem
In-Reply-To: <E1E5K1L-0004bH-00@dorka.pomaz.szeredi.hu>
On Wed, Aug 17, 2005 at 11:15:39AM +0200, Miklos Szeredi wrote:
> They are provided by _one_ kernel, not necessarily the running kernel.
No, they're provided by packages like glibc-kernheaders or similar
that are maintained separately. They're split from the kernel headers
and we don't need to keep obsolete junk around.
^ permalink raw reply
* Re: [PATCH] ppc32: removed usage of <asm/segment.h>
From: Miklos Szeredi @ 2005-08-17 9:15 UTC (permalink / raw)
To: hch; +Cc: akpm, zach, linux-kernel, linuxppc-dev, galak, davem
In-Reply-To: <20050817090920.GA12716@infradead.org>
> > There are perfectly valid uses of kernel headers from userspace. For
> > example if a program uses the netlink interface, it should include
> > <linux/netlink.h>. It's the interface definition after all.
> >
> > Glibc headers also include <linux/*> and <asm/*> in quite few places.
>
> But these files in /usr/include/ aren't provided by the kernel anymore.
They are provided by _one_ kernel, not necessarily the running kernel.
That doesn't make them any less a kernel header.
So if some userspace program depends on header <linux/x.h> to get the
interface definition for feature x, and you remove <linux/x.h> from
the current kernel, it _will_ break the userspace program some time
later, when glibc picks up the new kernel.
Having said that that, <asm/segment.h> may or may not be validly
exported to userspace.
Miklos
^ permalink raw reply
* Re: [PATCH] ppc32: removed usage of <asm/segment.h>
From: Christoph Hellwig @ 2005-08-17 9:09 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: akpm, zach, linux-kernel, hch, linuxppc-dev, galak, davem
In-Reply-To: <E1E5Jii-0004Yc-00@dorka.pomaz.szeredi.hu>
On Wed, Aug 17, 2005 at 10:56:24AM +0200, Miklos Szeredi wrote:
> > On Wed, Aug 17, 2005 at 12:43:37AM -0500, Kumar Gala wrote:
> > > >I concur, in fact we should really kill that thing off entirely.
> > >
> > > I'm all for killing it off entirely but got some feedback that on
> > > i386 segment.h can be included by userspace programs.
> >
> > No kernel headers can be included by userland anymore.
>
> I know nothing about <asm/segment.h> but this generic statement is
> simply not true.
>
> There are perfectly valid uses of kernel headers from userspace. For
> example if a program uses the netlink interface, it should include
> <linux/netlink.h>. It's the interface definition after all.
>
> Glibc headers also include <linux/*> and <asm/*> in quite few places.
But these files in /usr/include/ aren't provided by the kernel anymore.
^ permalink raw reply
* Re: [PATCH] ppc32: removed usage of <asm/segment.h>
From: Christoph Hellwig @ 2005-08-17 8:30 UTC (permalink / raw)
To: Kumar Gala
Cc: Andrew Morton, Zachary Amsden, linux-kernel list,
linuxppc-dev list, Gala Kumar K.-galak, David S. Miller
In-Reply-To: <032E6AED-9456-4271-9B06-C5DCE5970193@freescale.com>
On Wed, Aug 17, 2005 at 12:43:37AM -0500, Kumar Gala wrote:
> >I concur, in fact we should really kill that thing off entirely.
>
> I'm all for killing it off entirely but got some feedback that on
> i386 segment.h can be included by userspace programs.
No kernel headers can be included by userland anymore.
^ permalink raw reply
* Re: [PATCH] ppc32: removed usage of <asm/segment.h>
From: Geert Uytterhoeven @ 2005-08-17 8:16 UTC (permalink / raw)
To: Kumar Gala
Cc: Andrew Morton, Zachary Amsden, linux-kernel list,
linuxppc-dev list, Gala Kumar K.-galak, David S. Miller
In-Reply-To: <032E6AED-9456-4271-9B06-C5DCE5970193@freescale.com>
On Wed, 17 Aug 2005, Kumar Gala wrote:
> I'm all for killing it off entirely but got some feedback that on i386
> segment.h can be included by userspace programs.
>
> Here is the in kernel consumers that are outside of arch specific directories:
> ./drivers/video/q40fb.c:#include <asm/segment.h>
M68k-only, so doesn't affect ppc.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: David Woodhouse @ 2005-08-17 7:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded list, linuxppc-dev list
In-Reply-To: <11F30454-6808-44A3-8F5B-F36ED0028EF4@freescale.com>
On Wed, 2005-08-17 at 01:30 -0500, Kumar Gala wrote:
> > We could probably remove all the rest of the crap from asm/serial.h and
> > let platforms register their own serial8250 platform devices...
> Hmm, I wondering if we can provide some standard way of handling this
> for the embedded platforms as well. It would be nice to drop the old
> style of initialization completely and move to using a platform
> device always.
Yes, that's precisely what I meant. Just remove it from the list in
serial.h and as Ben says, instantiating a platform device is easy.
static struct plat_serial8250_port my_serial_ports[] = {
{
.uartclk = 115200*16,
.iobase = 0x2f8,
.irq = 3,
.flags = ASYNC_BOOT_AUTOCONF;
},
};
static struct platform_device my_serial_device = {
.name = "serial8250",
.dev.platform_data = my_serial_ports,
};
... platform_device_register(&my_serial_device);
--
dwmw2
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Benjamin Herrenschmidt @ 2005-08-17 6:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, David Woodhouse, linuxppc-embedded list
In-Reply-To: <11F30454-6808-44A3-8F5B-F36ED0028EF4@freescale.com>
On Wed, 2005-08-17 at 01:30 -0500, Kumar Gala wrote:
> On Aug 16, 2005, at 11:21 AM, David Woodhouse wrote:
>
> > My dual G4 PowerMac crashes sometimes when it probes for the (absent)
> > serial ports. Theoretically it's supposed to take a machine check and
> > recover -- but it doesn't always work like that.
> >
> > This patch removes the defaults from asm/pc_serial.h and uses the code
> > which already existed for ppc64 to register any ports which are
> > found in
> > the device tree. It's slightly updated to work in 32-bit and also
> > on the
> > Pegasos which claims the input frequency is 0Hz.
> >
> > We could probably remove all the rest of the crap from asm/serial.h
> > and
> > let platforms register their own serial8250 platform devices. And this
> > probably breaks serial ports on PReP, which needs to do likewise.
>
> Hmm, I wondering if we can provide some standard way of handling this
> for the embedded platforms as well. It would be nice to drop the old
> style of initialization completely and move to using a platform
> device always.
Sure, if they have a device-tree :) The code from ppc64 could be useable
there too. For others, they need to create their ports which whatever
mecanism they have to "know" where the port actually is ... little
common code here... but then, instanciating a platform device is easy.
Ben.
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Kumar Gala @ 2005-08-17 6:30 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-embedded list, linuxppc-dev list
In-Reply-To: <1124209292.3869.5.camel@localhost.localdomain>
On Aug 16, 2005, at 11:21 AM, David Woodhouse wrote:
> My dual G4 PowerMac crashes sometimes when it probes for the (absent)
> serial ports. Theoretically it's supposed to take a machine check and
> recover -- but it doesn't always work like that.
>
> This patch removes the defaults from asm/pc_serial.h and uses the code
> which already existed for ppc64 to register any ports which are
> found in
> the device tree. It's slightly updated to work in 32-bit and also
> on the
> Pegasos which claims the input frequency is 0Hz.
>
> We could probably remove all the rest of the crap from asm/serial.h
> and
> let platforms register their own serial8250 platform devices. And this
> probably breaks serial ports on PReP, which needs to do likewise.
Hmm, I wondering if we can provide some standard way of handling this
for the embedded platforms as well. It would be nice to drop the old
style of initialization completely and move to using a platform
device always.
- kumar
^ permalink raw reply
* [PATCH] ppc32: removed find_name.c
From: Kumar Gala @ 2005-08-16 22:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
No one uses find_name.c and no one seems to care about either. So I'm
removing it.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit eb5d5922d749a74f58416ca1a852651e7323449b
tree cb2371796401d2a7446134cec8f5deaa397e47ed
parent f63ab7e926d6c5e96de501ec9eac7f28af188a65
author Kumar K. Gala <kumar.gala@freescale.com> Tue, 16 Aug 2005 17:10:26 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Tue, 16 Aug 2005 17:10:26 -0500
arch/ppc/kernel/find_name.c | 48 -------------------------------------------
1 files changed, 0 insertions(+), 48 deletions(-)
diff --git a/arch/ppc/kernel/find_name.c b/arch/ppc/kernel/find_name.c
deleted file mode 100644
--- a/arch/ppc/kernel/find_name.c
+++ /dev/null
@@ -1,48 +0,0 @@
-#include <stdio.h>
-#include <asm/page.h>
-#include <sys/mman.h>
-#include <strings.h>
-/*
- * Finds a given address in the System.map and prints it out
- * with its neighbors. -- Cort
- */
-
-int main(int argc, char **argv)
-{
- unsigned long addr, cmp, i;
- FILE *f;
- char s[256], last[256];
-
- if ( argc < 2 )
- {
- fprintf(stderr, "Usage: %s <address>\n", argv[0]);
- return -1;
- }
-
- for ( i = 1 ; argv[i] ; i++ )
- {
- sscanf( argv[i], "%0lx", &addr );
- /* adjust if addr is relative to kernelbase */
- if ( addr < PAGE_OFFSET )
- addr += PAGE_OFFSET;
-
- if ( (f = fopen( "System.map", "r" )) == NULL )
- {
- perror("fopen()\n");
- exit(-1);
- }
-
- while ( !feof(f) )
- {
- fgets(s, 255 , f);
- sscanf( s, "%0lx", &cmp );
- if ( addr < cmp )
- break;
- strcpy( last, s);
- }
-
- printf( "%s%s", last, s );
- }
- fclose(f);
- return 0;
-}
^ permalink raw reply
* SDRAM init
From: Susheel Raj @ 2005-08-17 6:14 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I have been facing problems while writing to SDRAM
control regsiter. Somehow the hardware doesnt allow me
to write to SDRAM control register costing me a reboot
everytime.
I took the code from u-boot sdram_init and it works
fine only while i am executing it from the flash.
I want to leave the SDRAM control register value to be
0xd04f0000 at setup instead of 0x504f0000.
How should I do it???
It seems that the control register has to be
manipulated with some special care, like, precharging
all banks before manipulating or something ...
the below code works fine from flash
void sdram_init()
{
initdram ();
/* unlock mode register */
*(int *)MPC5XXX_SDRAM_CTRL = 0xd04f0000 |
hi_addr_bit;
/* precharge all banks */
*(int *)MPC5XXX_SDRAM_CTRL = 0xd04f0002 |
hi_addr_bit;
/* set mode register */
*(int *)MPC5XXX_SDRAM_MODE = 0x00cd0000;
/* precharge all banks */
*(int *)MPC5XXX_SDRAM_CTRL = 0xd04f0004 |
hi_addr_bit;
/* auto refresh */
*(int *)MPC5XXX_SDRAM_CTRL = 0xd04f0004 |
hi_addr_bit;
/* set mode register */
*(int *)MPC5XXX_SDRAM_MODE = 0x00cd0000;
/* normal operation */
*(int *)MPC5XXX_SDRAM_CTRL = 0x504f0000 |
hi_addr_bit;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
}
but If i want to deave MPC5xxx_SDRAM_CTRL to
0xd04f0000 it doesnt allow me . By the way just for
reference the address of this register is (MBAR +
0x0104)
I tried all trial and errors for understanding how to
manipulating with this register but in vain.
Please do help me ....
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* Re: [PATCH] ppc32: removed usage of <asm/segment.h>
From: Kumar Gala @ 2005-08-17 5:43 UTC (permalink / raw)
To: David S. Miller
Cc: Andrew Morton, Zachary Amsden, linux-kernel list,
linuxppc-dev list, Gala Kumar K.-galak
In-Reply-To: <20050816.203312.77701192.davem@davemloft.net>
On Aug 16, 2005, at 10:33 PM, David S. Miller wrote:
> From: Paul Mackerras <paulus@samba.org>
> Date: Wed, 17 Aug 2005 11:38:20 +1000
>
>
>> Kumar Gala writes:
>>
>>
>>> Made <asm/segment.h> a dummy include like it is in ppc64 and removed
>>>
> any
>
>>> users if it in arch/ppc.
>>>
>>
>> Why can't we just delete asm-ppc/segment.h (and asm-ppc64/segment.h
>> too, for that matter) entirely?
>>
>
> I concur, in fact we should really kill that thing off entirely.
I'm all for killing it off entirely but got some feedback that on
i386 segment.h can be included by userspace programs.
Here is the in kernel consumers that are outside of arch specific
directories:
./drivers/char/mxser.c:#include <asm/segment.h>
./drivers/isdn/hisax/hisax.h:#include <asm/segment.h>
./drivers/media/video/adv7170.c:#include <asm/segment.h>
./drivers/media/video/adv7175.c:#include <asm/segment.h>
./drivers/media/video/bt819.c:#include <asm/segment.h>
./drivers/media/video/bt856.c:#include <asm/segment.h>
./drivers/media/video/saa7111.c:#include <asm/segment.h>
./drivers/media/video/saa7114.c:#include <asm/segment.h>
./drivers/media/video/saa7185.c:#include <asm/segment.h>
./drivers/serial/68328serial.c:#include <asm/segment.h>
./drivers/serial/crisv10.c:#include <asm/segment.h>
./drivers/serial/icom.c:#include <asm/segment.h>
./drivers/serial/mcfserial.c:#include <asm/segment.h>
./drivers/video/q40fb.c:#include <asm/segment.h>
./include/linux/isdn.h:#include <asm/segment.h>
./sound/oss/os.h:#include <asm/segment.h>
- kumar
^ permalink raw reply
* Re: [PATCH] 1/2 Start header file merger (Was: Re: Beginning Merger Patch)
From: Kumar Gala @ 2005-08-17 5:39 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <20050805174705.731ffa05.sfr@canb.auug.org.au>
On Aug 5, 2005, at 2:47 AM, Stephen Rothwell wrote:
> On Tue, 2 Aug 2005 19:10:56 -0400 Dan Malek <dan@embeddededge.com>
> wrote:
>
>>
>> On Aug 2, 2005, at 6:59 PM, Jon Loeliger wrote:
>>
>>
>>> ..... A stub is left
>>> in asm-ppc and asm-ppc64 pointing to the unified files.
>>>
>>
>> Why bother? You may as well change all of the source
>> files, too, or else that will never get done :-)
>>
>
> You actually don't need to modify (m)any source files.
>
> Here is an alternative approach. These patches depend on Olaf's
> boot code cleanup for ppc64 (or similar). Do the following:
>
> cd linux/include
> mkdir asm-powerpc
> cd asm-ppc
> for i in *
> do
> [ -e ../asm-ppc64/$i ] || mv $i ../asm-powerpc/$i
> done
> cd ../asm-ppc64
> for i in *
> do
> [ -e ../asm-ppc/$i ] || mv $i ../asm-powerpc/$i
> done
> for i in *
> do
> [ -f ../asm-ppc64/$i ] && cmp -s $i ../asm-ppc64/$i &&
> mv $i ../asm-powerpc/$i && rm ../asm-ppc64/$i
> done
>
> Then apply the patch below and the patch in the following email.
>
> I have built this kernel for ppc (defconfig), ppc64 (iSeries, pSeries
> and
> pmac).
I think conceptual this is ok, just now how we should go about it.
There is a fair amount of cruft in asm-ppc and I think we should be
more selective and iterative about what we move into arch-powerpc.
For example, there is a fair amount of headers that are specific to
platform support code. It's probably the case that alot of that
should move into the proper platform directory.
If we just copy those files into arch-powerpc I think we will never
get around to moving them to the proper location in the future.
We've been doing some analysis (well, Jon and Becky have) and I think
there is some low hanging fruit that we can start with:
1. files that are identical are almost identical
2. files that are not overly ppc specific and seem straight forward
to merge
3. low hanging ppc specific files
4. identify files that we clearly want to wait on (for example
anything platform related)
This will hopefully leave us with the painful list of things that we
can start identifying and discussion how we want to go about solving
things (like what should "current" by defined as :)
Now your makefile hackery seems perfectly reasonable if we want to go
that way instead of explicitly including files like Jon's original
patch does. I dont have any strong feelings one way or the other.
The makefile hackery seems less intrusive since we dont have to
duplicate files in both places. I'd like to see if we can come to
some consensus on this since it directly impacts future patches that
we are working on to merge more files and move them into include/asm-
powerpc/
- kumar
^ permalink raw reply
* Re: [PATCH] ppc32: removed usage of <asm/segment.h>
From: David S. Miller @ 2005-08-17 3:33 UTC (permalink / raw)
To: paulus; +Cc: akpm, linuxppc-dev, linux-kernel, galak
In-Reply-To: <17154.38156.13295.731022@cargo.ozlabs.ibm.com>
From: Paul Mackerras <paulus@samba.org>
Date: Wed, 17 Aug 2005 11:38:20 +1000
> Kumar Gala writes:
>
> > Made <asm/segment.h> a dummy include like it is in ppc64 and removed any
> > users if it in arch/ppc.
>
> Why can't we just delete asm-ppc/segment.h (and asm-ppc64/segment.h
> too, for that matter) entirely?
I concur, in fact we should really kill that thing off entirely.
^ permalink raw reply
* Re: Redwood-6 and 2.6
From: Matt Porter @ 2005-08-17 3:17 UTC (permalink / raw)
To: Otto Solares; +Cc: linuxppc-embedded
In-Reply-To: <20050817024745.GA30824@guug.org>
On Tue, Aug 16, 2005 at 08:47:45PM -0600, Otto Solares wrote:
> On Tue, Aug 16, 2005 at 02:19:08PM -0700, Matt Porter wrote:
> > On Tue, Aug 16, 2005 at 03:12:59PM -0600, Otto Solares wrote:
> > > Now, when 'make znetboot' in 2.4 there was a zImage.embedded, is the
> > > same thing as zImage.treebot that appears now in 2.6?
> >
> > Yes, this is the image that boots on the stock OpenBIOS firmware.
> > It has the standard "tree" header on it.
>
> Thank you, just one more thing, do you know if the smc91x driver
> works for PPC? In 2.4 I had to set:
It should work.
> CONFIG_SMC91111=y
> CONFIG_SMC91111_ADVANCED=y
> CONFIG_SMC91111_BYTE_SWAP=y
>
> Looking in the driver itself I think it was developed for ARM.
Well, the ARM folks were the earliest users of smc9xxxx glued
onto their parts. There have been multiple drivers over the years
and then Nico recently unified them into smc91x. PPC has always
had PCI Ethernets or on-chips Ethernet (like the other 4xx parts)
so having a nasty little smc part glued onto a bus isn't that
popular. :)
It should still work. Dale Farnsworth took the time to add the
proper redwood specific bits to smc91x.h for accessing the regs
and add the bits to instantiate an smc91x platform device in the
redwood kernel ports.
> I am unable to netboot, I don't have serial console so my only access
> to this little box (MediaMVP) is the net. Thank you.
What kernel port are you using? You're trying boot a Redwood 6
kernel on the MediaMVP?
-Matt
^ permalink raw reply
* Re: Redwood-6 and 2.6
From: Dale Farnsworth @ 2005-08-17 3:13 UTC (permalink / raw)
To: Otto Solares, linuxppc-embedded
In-Reply-To: <20050817024745.GA30824@guug.org>
On Wed, Aug 17, 2005 at 02:47:45AM +0000, Otto Solares wrote:
> On Tue, Aug 16, 2005 at 02:19:08PM -0700, Matt Porter wrote:
> > On Tue, Aug 16, 2005 at 03:12:59PM -0600, Otto Solares wrote:
> > > Now, when 'make znetboot' in 2.4 there was a zImage.embedded, is the
> > > same thing as zImage.treebot that appears now in 2.6?
> >
> > Yes, this is the image that boots on the stock OpenBIOS firmware.
> > It has the standard "tree" header on it.
>
> Thank you, just one more thing, do you know if the smc91x driver
> works for PPC?
I added smc91111 support for redwood5 and redwood6 many months
ago. See the reference to CONFIG_REDWOOD_5 in smc91x.h. I haven't
tested it recently though. I'll give it a try tomorrow.
If your machine is not a redwood5 or redwood6, you'll also have to
add platform device initialization in your platform code. See
arch/ppc/platforms/4xx/redwood6.c.
-Dale
^ permalink raw reply
* Re: Redwood-6 and 2.6
From: Otto Solares @ 2005-08-17 2:47 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20050816141908.A1053@cox.net>
On Tue, Aug 16, 2005 at 02:19:08PM -0700, Matt Porter wrote:
> On Tue, Aug 16, 2005 at 03:12:59PM -0600, Otto Solares wrote:
> > Now, when 'make znetboot' in 2.4 there was a zImage.embedded, is the
> > same thing as zImage.treebot that appears now in 2.6?
>
> Yes, this is the image that boots on the stock OpenBIOS firmware.
> It has the standard "tree" header on it.
Thank you, just one more thing, do you know if the smc91x driver
works for PPC? In 2.4 I had to set:
CONFIG_SMC91111=y
CONFIG_SMC91111_ADVANCED=y
CONFIG_SMC91111_BYTE_SWAP=y
Looking in the driver itself I think it was developed for ARM.
I am unable to netboot, I don't have serial console so my only access
to this little box (MediaMVP) is the net. Thank you.
-otto
^ permalink raw reply
* Re: What's wrong with the serial port?
From: Shawn Jin @ 2005-08-17 1:53 UTC (permalink / raw)
To: ppcembed
In-Reply-To: <c3d0340b050811154148164691@mail.gmail.com>
> When the kernel is booting, it gets to the point where console_init()
> is called, which calls individual early console initialization
> functions. In my case it's serial8250_console_init(). Before
> register_console() is called in serial8250_console_init(), everything
> seems fine because the debugging logs are printed on the serial port.
> But once register_console() is called, the serial port continues
> spitting out =E0. See the following message. What's wrong?
FYI. The problem was caused by the endianess of io mem access. My
16550-compatible uart port is on a 32-bit bus. The io mem is big
endian. The current serial8250 driver always call read*/write*() to
access uart control registers. These functions are implemented for
little endian access only. So I have to add some awful #ifdef in the
driver to call big endian access functions.
Regards,
-Shawn.
^ permalink raw reply
* Re: [PATCH] ppc32: removed usage of <asm/segment.h>
From: Paul Mackerras @ 2005-08-17 1:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: Andrew Morton, linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.61.0508161700050.5751@nylon.am.freescale.net>
Kumar Gala writes:
> Made <asm/segment.h> a dummy include like it is in ppc64 and removed any
> users if it in arch/ppc.
Why can't we just delete asm-ppc/segment.h (and asm-ppc64/segment.h
too, for that matter) entirely?
Paul.
^ permalink raw reply
* [PATCH] ppc32: add cputable entry for 440SP Rev. A
From: Matt Porter @ 2005-08-16 22:17 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
Adds the appropriate cputable entry for PPC440SP so cache line
sizes are configured correctly.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
diff --git a/arch/ppc/kernel/cputable.c b/arch/ppc/kernel/cputable.c
--- a/arch/ppc/kernel/cputable.c
+++ b/arch/ppc/kernel/cputable.c
@@ -922,6 +922,16 @@ struct cpu_spec cpu_specs[] = {
.icache_bsize = 32,
.dcache_bsize = 32,
},
+ { /* 440SP Rev. A */
+ .pvr_mask = 0xff000fff,
+ .pvr_value = 0x53000891,
+ .cpu_name = "440SP Rev. A",
+ .cpu_features = CPU_FTR_SPLIT_ID_CACHE |
+ CPU_FTR_USE_TB,
+ .cpu_user_features = PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ },
#endif /* CONFIG_44x */
#ifdef CONFIG_FSL_BOOKE
{ /* e200z5 */
^ permalink raw reply
* [PATCH] ppc32: removed usage of <asm/segment.h>
From: Kumar Gala @ 2005-08-16 22:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel
Made <asm/segment.h> a dummy include like it is in ppc64 and removed any
users if it in arch/ppc.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit f63ab7e926d6c5e96de501ec9eac7f28af188a65
tree adcc67a572ec8e4d1520a7a5493ea909028e76f9
parent d88b795bc4c4b59c29a98e2a551c2ad4d65901c5
author Kumar K. Gala <kumar.gala@freescale.com> Tue, 16 Aug 2005 16:59:22 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Tue, 16 Aug 2005 16:59:22 -0500
arch/ppc/kernel/temp.c | 1 -
arch/ppc/kernel/time.c | 1 -
arch/ppc/platforms/chrp_time.c | 1 -
include/asm-ppc/segment.h | 7 ++++++-
4 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/ppc/kernel/temp.c b/arch/ppc/kernel/temp.c
--- a/arch/ppc/kernel/temp.c
+++ b/arch/ppc/kernel/temp.c
@@ -21,7 +21,6 @@
#include <linux/interrupt.h>
#include <linux/init.h>
-#include <asm/segment.h>
#include <asm/io.h>
#include <asm/reg.h>
#include <asm/nvram.h>
diff --git a/arch/ppc/kernel/time.c b/arch/ppc/kernel/time.c
--- a/arch/ppc/kernel/time.c
+++ b/arch/ppc/kernel/time.c
@@ -58,7 +58,6 @@
#include <linux/init.h>
#include <linux/profile.h>
-#include <asm/segment.h>
#include <asm/io.h>
#include <asm/nvram.h>
#include <asm/cache.h>
diff --git a/arch/ppc/platforms/chrp_time.c b/arch/ppc/platforms/chrp_time.c
--- a/arch/ppc/platforms/chrp_time.c
+++ b/arch/ppc/platforms/chrp_time.c
@@ -22,7 +22,6 @@
#include <linux/init.h>
#include <linux/bcd.h>
-#include <asm/segment.h>
#include <asm/io.h>
#include <asm/nvram.h>
#include <asm/prom.h>
diff --git a/include/asm-ppc/segment.h b/include/asm-ppc/segment.h
--- a/include/asm-ppc/segment.h
+++ b/include/asm-ppc/segment.h
@@ -1 +1,6 @@
-#include <asm/uaccess.h>
+#ifndef __PPC_SEGMENT_H
+#define __PPC_SEGMENT_H
+
+/* Only here because we have some old header files that expect it.. */
+
+#endif /* __PPC_SEGMENT_H */
^ permalink raw reply
* [PATCH] ppc32: Fix PPC440SP SRAM controller DCRs
From: Matt Porter @ 2005-08-16 21:41 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
Fixes the incorrect DCR base value for the 440SP SRAM controller.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
diff --git a/include/asm-ppc/ibm44x.h b/include/asm-ppc/ibm44x.h
--- a/include/asm-ppc/ibm44x.h
+++ b/include/asm-ppc/ibm44x.h
@@ -423,11 +423,7 @@
#define MQ0_CONFIG_SIZE_2G 0x0000c000
/* Internal SRAM Controller 440GX/440SP */
-#ifdef CONFIG_440SP
-#define DCRN_SRAM0_BASE 0x100
-#else /* 440GX */
#define DCRN_SRAM0_BASE 0x000
-#endif
#define DCRN_SRAM0_SB0CR (DCRN_SRAM0_BASE + 0x020)
#define DCRN_SRAM0_SB1CR (DCRN_SRAM0_BASE + 0x021)
^ 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