* Re: [F]Framebuffer driver using SM501 hardware.
From: Andrey Volkov @ 2005-08-17 12:37 UTC (permalink / raw)
To: Matej Kupljen; +Cc: linuxppc-dev
In-Reply-To: <1124279443.16175.40.camel@localhost.localdomain>
Matej Kupljen wrotq:
> Hi Clemens
>
>
>>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 also did some testing with X and SM501 using SM501 and MPC5200
> on local bus, but I am not working on that board at the moment.
>
> See:
> https://bugs.freedesktop.org/show_bug.cgi?id=312
>
> If I find some time, I'll probably be able to help you
> with some testing.
>
> BR,
> Matej
>
Thanks all for (keen) interest, I'll create cvs/git during nearest days.
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: [F]Framebuffer driver using SM501 hardware.
From: Matej Kupljen @ 2005-08-17 11:50 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-dev
In-Reply-To: <430319BB.2020801@anagramm.de>
Hi Clemens
> 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 also did some testing with X and SM501 using SM501 and MPC5200
on local bus, but I am not working on that board at the moment.
See:
https://bugs.freedesktop.org/show_bug.cgi?id=312
If I find some time, I'll probably be able to help you
with some testing.
BR,
Matej
^ permalink raw reply
* Re: [F]Framebuffer driver using SM501 hardware.
From: Andrey Volkov @ 2005-08-17 12:15 UTC (permalink / raw)
To: Geert Uytterhoeven, linux-fbdev-devel
Cc: Linux/PPC Development, surendra.yadav
In-Reply-To: <Pine.LNX.4.62.0508171317540.6073@numbat.sonytel.be>
Geert Uytterhoeven wrote:
> On Wed, 17 Aug 2005, Andrey Volkov wrote:
>
>>Todo:
>>- 16 bpp colormap (needed reverse endian support in fbcon/fbmem)
>
>
> Can you please elaborate? For 2.6, there should be no such problems (for 2.4,
> there are).
Sorry for inexactitude, problem (as usually :)) in next (for case of
MPC5200 connected through PCI to SM501): PCI on PPC (and hence SM501) is
a little endian, PPC - big endian.
Currently (up to 2.6.13-rc6) frame buffer routines use
__raw_writeXX for write to fb memory. Result - garbage with colors in
RGB565/RGB888 modes (but pixels, meanwhile, are in place). If using
write[lw] - colors are diplayed correctly, but all image pixels are
shifted for (RGB565). This is not bug of frame buffer, this is lack of
some define in .config which tell fb/device driver how palette must be
generated (more precisely it is unknown when must be RGB565, but when
must be BGR565).
Problem redouble when hw accel, as bus muster, entered in the game:
for accelerated imageblit pixels must be in RGB565 mode :((
--
Regards
Andrey Volkov
^ permalink raw reply
* Bestcomm and FEC problems in 2.4
From: Nuguru Susheel @ 2005-08-17 15:11 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Sylvain Munaut
Hi all,
I know that very few are now using MPC5200 Rev B, even then i dare
that someone would answer me :-)...
Root NFS doesnt work for me on this core and i was suggested that I
should use new Bestcomm drivers from Sylvain's 2.6 kernel (I think I
would need both Bestcomm and FEC drivers).. I am also aware of Andrey
Volkov's updates of the Bestcomm drivers but, I am using Denx 2.4
Version.
does anyone tried to use this new drivers into 2.4 kernel. If yes
please give me a hint how to do so, because of difference in the file
structure of the these versions the solution is definately not straight
forward and needs a lot of hacking ...
any suggestions where to start ???
thanks a lot,
nSr
^ permalink raw reply
* Re: [F]Framebuffer driver using SM501 hardware.
From: Geert Uytterhoeven @ 2005-08-17 11:18 UTC (permalink / raw)
To: Andrey Volkov; +Cc: Linux/PPC Development, surendra.yadav
In-Reply-To: <43030D41.3000508@varma-el.com>
On Wed, 17 Aug 2005, Andrey Volkov wrote:
> Todo:
> - 16 bpp colormap (needed reverse endian support in fbcon/fbmem)
Can you please elaborate? For 2.6, there should be no such problems (for 2.4,
there are).
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: Russell King @ 2005-08-17 11:11 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1124209292.3869.5.camel@localhost.localdomain>
On Wed, Aug 17, 2005 at 11:44:38AM +0100, David Woodhouse wrote:
> 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.
Great. See comments below - not many of them though, most of them
trivial.
> --- linux-2.6.12/drivers/serial/8250_of.c~ 2005-08-15 21:14:27.000000000 +0100
> +++ linux-2.6.12/drivers/serial/8250_of.c 2005-08-15 21:20:59.000000000 +0100
> @@ -0,0 +1,199 @@
> +#include <linux/kernel.h>
> +#include <linux/serial.h>
> +#include <linux/serial_8250.h>
> +#include <linux/config.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/pci.h>
> +#include <asm/serial.h>
> +#include <asm/prom.h>
> +
> +#if 0
> +#define DBG(fmt...) printk(KERN_DEBUG fmt)
> +#else
> +#define DBG(fmt...) do { } while (0)
> +#endif
pr_debug() ?
> +
> +/*
> + * This function can be used by platforms to "find" legacy serial ports.
> + * It works for "serial" nodes under an "isa" node, and will try to
> + * respect the "ibm,aix-loc" property if any. It works with up to 8
> + * ports.
> + */
> +
> +#define MAX_LEGACY_SERIAL_PORTS 8
> +static int ports_probed = 0;
> +
> +static struct plat_serial8250_port serial_ports[MAX_LEGACY_SERIAL_PORTS+1];
> +static unsigned int old_serial_count;
> +
> +void __init generic_find_legacy_serial_ports(u64 *physport,
> + unsigned int *default_speed)
> +{
> + struct device_node *np;
> + u32 *sizeprop;
> +
> + struct isa_reg_property {
> + u32 space;
> + u32 address;
> + u32 size;
> + };
> +
> + DBG(" -> generic_find_legacy_serial_port()\n");
> + ports_probed = 1;
> +
> + *physport = 0;
> + if (default_speed)
> + *default_speed = 0;
> +
> + np = of_find_node_by_path("/");
> + if (!np)
> + return;
> +
> + /* First fill our array */
> + for (np = NULL; (np = of_find_node_by_type(np, "serial"));) {
> + struct device_node *isa, *pci;
> + struct isa_reg_property *reg;
> + unsigned long phys_size, addr_size;
> + u64 io_base;
> + u32 *rangesp;
> + u32 *interrupts, *clk, *spd;
> + char *typep;
> + int index, rlen, rentsize;
> +
> + /* Ok, first check if it's under an "isa" parent */
> + isa = of_get_parent(np);
> + if (!isa || strcmp(isa->name, "isa")) {
> + DBG("%s: no isa parent found\n", np->full_name);
> + continue;
> + }
> +
Extraneous two tabs
> + /* Now look for an "ibm,aix-loc" property that gives us ordering
> + * if any...
> + */
> + typep = (char *)get_property(np, "ibm,aix-loc", NULL);
> +
> + /* Get the ISA port number */
> + reg = (struct isa_reg_property *)get_property(np, "reg", NULL);
Extraneous tab at the end of this line
> + if (reg == NULL)
> + goto next_port;
> + /* We assume the interrupt number isn't translated ... */
> + interrupts = (u32 *)get_property(np, "interrupts", NULL);
> + /* get clock freq. if present */
> + clk = (u32 *)get_property(np, "clock-frequency", NULL);
> + /* get default speed if present */
> + spd = (u32 *)get_property(np, "current-speed", NULL);
> + /* Default to locate at end of array */
> + index = old_serial_count; /* end of the array by default */
> +
> + /* If we have a location index, then use it */
> + if (typep && *typep == 'S') {
> + index = simple_strtol(typep+1, NULL, 0) - 1;
> + /* if index is out of range, use end of array instead */
> + if (index >= MAX_LEGACY_SERIAL_PORTS)
> + index = old_serial_count;
> + /* if our index is still out of range, that mean that
> + * array is full, we could scan for a free slot but that
> + * make little sense to bother, just skip the port
> + */
> + if (index >= MAX_LEGACY_SERIAL_PORTS)
> + goto next_port;
> + if (index >= old_serial_count)
> + old_serial_count = index + 1;
> + /* Check if there is a port who already claimed our slot */
> + if (serial_ports[index].iobase != 0) {
> + /* if we still have some room, move it, else override */
> + if (old_serial_count < MAX_LEGACY_SERIAL_PORTS) {
> + DBG("Moved legacy port %d -> %d\n", index,
> + old_serial_count);
> + serial_ports[old_serial_count++] =
> + serial_ports[index];
> + } else {
> + DBG("Replacing legacy port %d\n", index);
> + }
> + }
> + }
> + if (index >= MAX_LEGACY_SERIAL_PORTS)
> + goto next_port;
> + if (index >= old_serial_count)
> + old_serial_count = index + 1;
> +
> + /* Now fill the entry */
> + memset(&serial_ports[index], 0, sizeof(struct plat_serial8250_port));
> + serial_ports[index].uartclk = (clk && *clk) ? *clk : BASE_BAUD * 16;
> + serial_ports[index].iobase = reg->address;
> + serial_ports[index].irq = interrupts ? interrupts[0] : 0;
Doesn't PPC64 have NO_IRQ ?
> + serial_ports[index].flags = ASYNC_BOOT_AUTOCONF;
> +
> + DBG("Added legacy port, index: %d, port: %x, irq: %d, clk: %d\n",
> + index,
> + serial_ports[index].iobase,
> + serial_ports[index].irq,
> + serial_ports[index].uartclk);
> +
> + /* Get phys address of IO reg for port 1 */
> + if (index != 0)
> + goto next_port;
> +
> + pci = of_get_parent(isa);
> + if (!pci) {
> + DBG("%s: no pci parent found\n", np->full_name);
> + goto next_port;
> + }
> +
> + rangesp = (u32 *)get_property(pci, "ranges", &rlen);
> + if (rangesp == NULL) {
> + of_node_put(pci);
> + goto next_port;
> + }
> + rlen /= 4;
> +
> + /* we need the #size-cells of the PCI bridge node itself */
> + phys_size = 1;
> + sizeprop = (u32 *)get_property(pci, "#size-cells", NULL);
> + if (sizeprop != NULL)
> + phys_size = *sizeprop;
> + /* we need the parent #addr-cells */
> + addr_size = prom_n_addr_cells(pci);
> + rentsize = 3 + addr_size + phys_size;
> + io_base = 0;
> + for (;rlen >= rentsize; rlen -= rentsize,rangesp += rentsize) {
> + if (((rangesp[0] >> 24) & 0x3) != 1)
> + continue; /* not IO space */
> + io_base = rangesp[3];
> + if (addr_size == 2)
> + io_base = (io_base << 32) | rangesp[4];
> + }
> + if (io_base != 0) {
> + *physport = io_base + reg->address;
> + if (default_speed && spd)
> + *default_speed = *spd;
> + }
> + of_node_put(pci);
> + next_port:
> + of_node_put(isa);
> + }
> +
> + DBG(" <- generic_find_legacy_serial_port()\n");
> +}
> +
> +static struct platform_device serial_device = {
> + .name = "serial8250",
> + .id = 0,
> + .dev = {
> + .platform_data = serial_ports,
> + },
> +};
> +
> +static int __init serial_dev_init(void)
> +{
> + u64 phys;
> + unsigned int spd;
> +
> + if (!ports_probed)
> + generic_find_legacy_serial_ports(&phys, &spd);
> + return platform_device_register(&serial_device);
> +}
> +arch_initcall(serial_dev_init);
> +
> +
Can we kill the two blank lines please?
> --- linux-2.6.12/drivers/serial/Kconfig~ 2005-08-11 13:51:50.000000000 +0100
> +++ linux-2.6.12/drivers/serial/Kconfig 2005-08-15 21:13:41.000000000 +0100
> @@ -77,6 +77,11 @@ config SERIAL_8250_CS
>
> If unsure, say N.
>
> +config SERIAL_8250_OF
> + bool
> + default y
> + depends on PPC_OF && SERIAL_8250 != n
Wouldn't "depends on PPC_OF && SERIAL_8250" be sufficient? iirc "bool"
treats a dependency result of 'm' as 'y'.
> +
> config SERIAL_8250_ACPI
> bool "8250/16550 device discovery via ACPI namespace"
> default y if IA64
> --- linux-2.6.12/arch/ppc64/kernel/setup.c~ 2005-08-11 13:52:04.000000000 +0100
> +++ linux-2.6.12/arch/ppc64/kernel/setup.c 2005-08-15 20:27:25.000000000 +0100
> @@ -1147,186 +1147,6 @@ void __init setup_default_decr(void)
> lpaca->next_jiffy_update_tb = get_tb() + tb_ticks_per_jiffy;
> }
>
> -#ifndef CONFIG_PPC_ISERIES
> -/*
> - * This function can be used by platforms to "find" legacy serial ports.
> - * It works for "serial" nodes under an "isa" node, and will try to
> - * respect the "ibm,aix-loc" property if any. It works with up to 8
> - * ports.
> - */
> -
> -#define MAX_LEGACY_SERIAL_PORTS 8
> -static struct plat_serial8250_port serial_ports[MAX_LEGACY_SERIAL_PORTS+1];
> -static unsigned int old_serial_count;
> -
> -void __init generic_find_legacy_serial_ports(u64 *physport,
> - unsigned int *default_speed)
> -{
> - struct device_node *np;
> - u32 *sizeprop;
> -
> - struct isa_reg_property {
> - u32 space;
> - u32 address;
> - u32 size;
> - };
> - struct pci_reg_property {
> - struct pci_address addr;
> - u32 size_hi;
> - u32 size_lo;
> - };
Lots a space at the end of this line.
> -
> - DBG(" -> generic_find_legacy_serial_port()\n");
> -
> - *physport = 0;
> - if (default_speed)
> - *default_speed = 0;
> -
> - np = of_find_node_by_path("/");
> - if (!np)
> - return;
> -
> - /* First fill our array */
> - for (np = NULL; (np = of_find_node_by_type(np, "serial"));) {
> - struct device_node *isa, *pci;
> - struct isa_reg_property *reg;
> - unsigned long phys_size, addr_size, io_base;
> - u32 *rangesp;
> - u32 *interrupts, *clk, *spd;
> - char *typep;
> - int index, rlen, rentsize;
> -
> - /* Ok, first check if it's under an "isa" parent */
> - isa = of_get_parent(np);
> - if (!isa || strcmp(isa->name, "isa")) {
> - DBG("%s: no isa parent found\n", np->full_name);
> - continue;
> - }
> -
> - /* Now look for an "ibm,aix-loc" property that gives us ordering
> - * if any...
> - */
> - typep = (char *)get_property(np, "ibm,aix-loc", NULL);
> -
> - /* Get the ISA port number */
> - reg = (struct isa_reg_property *)get_property(np, "reg", NULL);
> - if (reg == NULL)
> - goto next_port;
> - /* We assume the interrupt number isn't translated ... */
> - interrupts = (u32 *)get_property(np, "interrupts", NULL);
> - /* get clock freq. if present */
> - clk = (u32 *)get_property(np, "clock-frequency", NULL);
> - /* get default speed if present */
> - spd = (u32 *)get_property(np, "current-speed", NULL);
> - /* Default to locate at end of array */
> - index = old_serial_count; /* end of the array by default */
> -
> - /* If we have a location index, then use it */
> - if (typep && *typep == 'S') {
> - index = simple_strtol(typep+1, NULL, 0) - 1;
> - /* if index is out of range, use end of array instead */
> - if (index >= MAX_LEGACY_SERIAL_PORTS)
> - index = old_serial_count;
> - /* if our index is still out of range, that mean that
> - * array is full, we could scan for a free slot but that
> - * make little sense to bother, just skip the port
> - */
> - if (index >= MAX_LEGACY_SERIAL_PORTS)
> - goto next_port;
> - if (index >= old_serial_count)
> - old_serial_count = index + 1;
> - /* Check if there is a port who already claimed our slot */
> - if (serial_ports[index].iobase != 0) {
> - /* if we still have some room, move it, else override */
> - if (old_serial_count < MAX_LEGACY_SERIAL_PORTS) {
> - DBG("Moved legacy port %d -> %d\n", index,
> - old_serial_count);
> - serial_ports[old_serial_count++] =
> - serial_ports[index];
> - } else {
> - DBG("Replacing legacy port %d\n", index);
> - }
> - }
> - }
> - if (index >= MAX_LEGACY_SERIAL_PORTS)
> - goto next_port;
> - if (index >= old_serial_count)
> - old_serial_count = index + 1;
> -
> - /* Now fill the entry */
> - memset(&serial_ports[index], 0, sizeof(struct plat_serial8250_port));
> - serial_ports[index].uartclk = clk ? *clk : BASE_BAUD * 16;
> - serial_ports[index].iobase = reg->address;
> - serial_ports[index].irq = interrupts ? interrupts[0] : 0;
> - serial_ports[index].flags = ASYNC_BOOT_AUTOCONF;
> -
> - DBG("Added legacy port, index: %d, port: %x, irq: %d, clk: %d\n",
> - index,
> - serial_ports[index].iobase,
> - serial_ports[index].irq,
> - serial_ports[index].uartclk);
> -
> - /* Get phys address of IO reg for port 1 */
> - if (index != 0)
> - goto next_port;
> -
> - pci = of_get_parent(isa);
> - if (!pci) {
> - DBG("%s: no pci parent found\n", np->full_name);
> - goto next_port;
> - }
> -
> - rangesp = (u32 *)get_property(pci, "ranges", &rlen);
> - if (rangesp == NULL) {
> - of_node_put(pci);
> - goto next_port;
> - }
> - rlen /= 4;
> -
> - /* we need the #size-cells of the PCI bridge node itself */
> - phys_size = 1;
> - sizeprop = (u32 *)get_property(pci, "#size-cells", NULL);
> - if (sizeprop != NULL)
> - phys_size = *sizeprop;
> - /* we need the parent #addr-cells */
> - addr_size = prom_n_addr_cells(pci);
> - rentsize = 3 + addr_size + phys_size;
> - io_base = 0;
> - for (;rlen >= rentsize; rlen -= rentsize,rangesp += rentsize) {
> - if (((rangesp[0] >> 24) & 0x3) != 1)
> - continue; /* not IO space */
> - io_base = rangesp[3];
> - if (addr_size == 2)
> - io_base = (io_base << 32) | rangesp[4];
> - }
> - if (io_base != 0) {
> - *physport = io_base + reg->address;
> - if (default_speed && spd)
> - *default_speed = *spd;
> - }
> - of_node_put(pci);
> - next_port:
> - of_node_put(isa);
> - }
> -
> - DBG(" <- generic_find_legacy_serial_port()\n");
> -}
> -
> -static struct platform_device serial_device = {
> - .name = "serial8250",
> - .id = 0,
> - .dev = {
> - .platform_data = serial_ports,
> - },
> -};
> -
> -static int __init serial_dev_init(void)
> -{
> - return platform_device_register(&serial_device);
> -}
> -arch_initcall(serial_dev_init);
> -
> -#endif /* CONFIG_PPC_ISERIES */
>
> int check_legacy_ioport(unsigned long base_port)
> {
> --- linux-2.6.12/include/asm-ppc/pc_serial.h~ 2005-08-15 21:19:32.000000000 +0100
> +++ linux-2.6.12/include/asm-ppc/pc_serial.h 2005-08-15 21:20:24.000000000 +0100
> @@ -26,18 +26,3 @@
> #define RS_TABLE_SIZE 4
> #endif
>
> -/* Standard COM flags (except for COM4, because of the 8514 problem) */
> -#ifdef CONFIG_SERIAL_DETECT_IRQ
> -#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ)
> -#define STD_COM4_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_AUTO_IRQ)
> -#else
> -#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST)
> -#define STD_COM4_FLAGS ASYNC_BOOT_AUTOCONF
> -#endif
> -
> -#define SERIAL_PORT_DFNS \
> - /* UART CLK PORT IRQ FLAGS */ \
> - { 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS }, /* ttyS0 */ \
> - { 0, BASE_BAUD, 0x2F8, 3, STD_COM_FLAGS }, /* ttyS1 */ \
> - { 0, BASE_BAUD, 0x3E8, 4, STD_COM_FLAGS }, /* ttyS2 */ \
> - { 0, BASE_BAUD, 0x2E8, 3, STD_COM4_FLAGS }, /* ttyS3 */
>
--
Russell King
^ permalink raw reply
* Re: [PATCH] 1/2 Start header file merger (Was: Re: Beginning Merger Patch)
From: Arnd Bergmann @ 2005-08-17 11:05 UTC (permalink / raw)
To: linuxppc64-dev; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <8DC89F16-0704-484A-9216-D94F3EE90CA4@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 9916 bytes --]
On Middeweken 17 August 2005 07:39, Kumar Gala wrote:
>
> 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.
I have identified a list of files that are included only from files
in a single directory (after the platform merge) or not included at
all.
See the end of this mail.
> 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/
I vote for doing it with the Makefile hacks. The advantage I see in this
is that it is obvious from the file in each of the directories which files
are already merged and which ones still need to be worked on.
Arnd <><
+++ ./bseip.h 0 +++
+++ ./gt64260.h 0 +++
+++ ./hdreg.h 0 +++
+++ ./md.h 0 +++
+++ ./ans-lcd.h 1 +++
./drivers/macintosh/ans-lcd.c:#include <asm/ans-lcd.h>
+++ ./gt64260_defs.h 1 +++
./include/asm-ppc/gt64260.h:#include <asm/gt64260_defs.h>
+++ ./hawk_defs.h 1 +++
./include/asm-ppc/hawk.h:#include <asm/hawk_defs.h>
+++ ./iSeries/HvCallSm.h 1 +++
./arch/ppc64/kernel/iSeries_setup.c:#include <asm/iSeries/HvCallSm.h>
+++ ./iSeries/HvReleaseData.h 1 +++
./arch/ppc64/kernel/LparData.c:#include <asm/iSeries/HvReleaseData.h>
+++ ./iSeries/ItIplParmsReal.h 1 +++
./arch/ppc64/kernel/LparData.c:#include <asm/iSeries/ItIplParmsReal.h>
+++ ./iSeries/ItSpCommArea.h 1 +++
./arch/ppc64/kernel/LparData.c:#include <asm/iSeries/ItSpCommArea.h>
+++ ./iSeries/iSeries_io.h 1 +++
./include/asm-ppc64/io.h:#include <asm/iSeries/iSeries_io.h>
+++ ./ibm403.h 1 +++
./arch/ppc/platforms/4xx/oak.h:#include <asm/ibm403.h>
+++ ./m8260_pci.h 1 +++
./arch/ppc/syslib/m82xx_pci.h:#include <asm/m8260_pci.h>
+++ ./mk48t59.h 1 +++
./arch/ppc/platforms/prep_setup.c:#include <asm/mk48t59.h>
+++ ./ppc32.h 1 +++
./arch/ppc64/kernel/signal32.c:#include <asm/ppc32.h>
+++ ./raven.h 1 +++
./arch/ppc/platforms/prep_setup.c:#include <asm/raven.h>
+++ ./gg2.h 2 +++
./arch/ppc/platforms/chrp_pci.c:#include <asm/gg2.h>
./arch/ppc/platforms/chrp_setup.c:#include <asm/gg2.h>
+++ ./harrier.h 2 +++
./arch/ppc/platforms/prpmc800.c:#include <asm/harrier.h>
./arch/ppc/syslib/harrier.c:#include <asm/harrier.h>
+++ ./iSeries/IoHriMainStore.h 2 +++
./arch/ppc64/kernel/iSeries_proc.c:#include <asm/iSeries/IoHriMainStore.h>
./arch/ppc64/kernel/iSeries_setup.c:#include <asm/iSeries/IoHriMainStore.h>
+++ ./iSeries/ItVpdAreas.h 2 +++
./arch/ppc64/kernel/LparData.c:#include <asm/iSeries/ItVpdAreas.h>
./arch/ppc64/kernel/iSeries_setup.c:#include <asm/iSeries/ItVpdAreas.h>
+++ ./iSeries/LparMap.h 2 +++
./arch/ppc64/kernel/LparData.c:#include <asm/iSeries/LparMap.h>
./arch/ppc64/kernel/iSeries_setup.c:#include <asm/iSeries/LparMap.h>
+++ ./imalloc.h 2 +++
./arch/ppc64/mm/imalloc.c:#include <asm/imalloc.h>
./arch/ppc64/mm/init.c:#include <asm/imalloc.h>
+++ ./ppc4xx_dma.h 2 +++
./arch/ppc/syslib/ppc4xx_dma.c:#include <asm/ppc4xx_dma.h>
./arch/ppc/syslib/ppc4xx_sgdma.c:#include <asm/ppc4xx_dma.h>
+++ ./xparameters.h 2 +++
./arch/ppc/platforms/4xx/virtex-ii_pro.h:#include <asm/xparameters.h>
./arch/ppc/syslib/xilinx_pic.c:#include <asm/xparameters.h>
+++ ./iSeries/HvCallHpt.h 3 +++
./arch/ppc64/kernel/iSeries_htab.c:#include <asm/iSeries/HvCallHpt.h>
./arch/ppc64/kernel/iSeries_setup.c:#include <asm/iSeries/HvCallHpt.h>
./arch/ppc64/kernel/process.c:#include <asm/iSeries/HvCallHpt.h>
+++ ./iSeries/IoHriProcessorVpd.h 3 +++
./arch/ppc64/kernel/LparData.c:#include <asm/iSeries/IoHriProcessorVpd.h>
./arch/ppc64/kernel/iSeries_proc.c:#include <asm/iSeries/IoHriProcessorVpd.h>
./arch/ppc64/kernel/iSeries_setup.c:#include <asm/iSeries/IoHriProcessorVpd.h>
+++ ./iSeries/ItExtVpdPanel.h 3 +++
./arch/ppc64/kernel/LparData.c:#include <asm/iSeries/ItExtVpdPanel.h>
./arch/ppc64/kernel/lparcfg.c:#include <asm/iSeries/ItExtVpdPanel.h>
./arch/ppc64/kernel/viopath.c:#include <asm/iSeries/ItExtVpdPanel.h>
+++ ./iSeries/iSeries_irq.h 3 +++
./arch/ppc64/kernel/iSeries_irq.c:#include <asm/iSeries/iSeries_irq.h>
./arch/ppc64/kernel/iSeries_pci.c:#include <asm/iSeries/iSeries_irq.h>
./arch/ppc64/kernel/iSeries_setup.c:#include <asm/iSeries/iSeries_irq.h>
+++ ./ipic.h 3 +++
./arch/ppc/platforms/83xx/mpc834x_sys.c:#include <asm/ipic.h>
./arch/ppc/syslib/ipic.c:#include <asm/ipic.h>
./arch/ppc/syslib/ipic.h:#include <asm/ipic.h>
+++ ./xics.h 3 +++
./arch/ppc64/kernel/pSeries_setup.c:#include <asm/xics.h>
./arch/ppc64/kernel/pSeries_smp.c:#include <asm/xics.h>
./arch/ppc64/kernel/xics.c:#include <asm/xics.h>
+++ ./plpar_wrappers.h 4 +++
./arch/ppc64/kernel/pSeries_iommu.c:#include <asm/plpar_wrappers.h>
./arch/ppc64/kernel/pSeries_lpar.c:#include <asm/plpar_wrappers.h>
./arch/ppc64/kernel/pSeries_setup.c:#include <asm/plpar_wrappers.h>
./arch/ppc64/kernel/pSeries_smp.c:#include <asm/plpar_wrappers.h>
+++ ./prep_nvram.h 4 +++
./arch/ppc/platforms/lopec.c:#include <asm/prep_nvram.h>
./arch/ppc/platforms/pplus.c:#include <asm/prep_nvram.h>
./arch/ppc/platforms/prep_setup.c:#include <asm/prep_nvram.h>
./arch/ppc/syslib/prep_nvram.c:#include <asm/prep_nvram.h>
+++ ./hawk.h 5 +++
./arch/ppc/platforms/mcpn765.c:#include <asm/hawk.h>
./arch/ppc/platforms/mvme5100.c:#include <asm/hawk.h>
./arch/ppc/platforms/pplus.c:#include <asm/hawk.h>
./arch/ppc/platforms/prpmc750.c:#include <asm/hawk.h>
./arch/ppc/syslib/hawk_common.c:#include <asm/hawk.h>
+++ ./hvconsole.h 5 +++
./arch/ppc64/kernel/hvconsole.c:#include <asm/hvconsole.h>
./drivers/char/hvc_console.c:#include <asm/hvconsole.h>
./drivers/char/hvcs.c:#include <asm/hvconsole.h>
./drivers/char/hvsi.c:#include <asm/hvconsole.h>
./drivers/char/hvc_vio.c:#include <asm/hvconsole.h>
+++ ./pSeries_reconfig.h 5 +++
./arch/ppc64/kernel/pSeries_iommu.c:#include <asm/pSeries_reconfig.h>
./arch/ppc64/kernel/pSeries_reconfig.c:#include <asm/pSeries_reconfig.h>
./arch/ppc64/kernel/pSeries_smp.c:#include <asm/pSeries_reconfig.h>
./arch/ppc64/kernel/pci_dn.c:#include <asm/pSeries_reconfig.h>
./arch/ppc64/kernel/prom.c:#include <asm/pSeries_reconfig.h>
+++ ./ibm_ocp_pci.h 6 +++
./arch/ppc/platforms/4xx/ash.c:#include <asm/ibm_ocp_pci.h>
./arch/ppc/platforms/4xx/bubinga.c:#include <asm/ibm_ocp_pci.h>
./arch/ppc/platforms/4xx/ep405.c:#include <asm/ibm_ocp_pci.h>
./arch/ppc/platforms/4xx/sycamore.c:#include <asm/ibm_ocp_pci.h>
./arch/ppc/platforms/4xx/walnut.c:#include <asm/ibm_ocp_pci.h>
./arch/ppc/syslib/ppc405_pci.c:#include <asm/ibm_ocp_pci.h>
+++ ./mv64x60_defs.h 6 +++
./arch/ppc/boot/simple/misc-chestnut.c:#include <asm/mv64x60_defs.h>
./arch/ppc/boot/simple/misc-ev64260.c:#include <asm/mv64x60_defs.h>
./arch/ppc/boot/simple/misc-katana.c:#include <asm/mv64x60_defs.h>
./arch/ppc/boot/simple/misc-mv64x60.c:#include <asm/mv64x60_defs.h>
./arch/ppc/boot/simple/mv64x60_tty.c:#include <asm/mv64x60_defs.h>
./include/asm-ppc/mv64x60.h:#include <asm/mv64x60_defs.h>
+++ ./iSeries/HvCallXm.h 7 +++
./arch/ppc64/kernel/iSeries_iommu.c:#include <asm/iSeries/HvCallXm.h>
./arch/ppc64/kernel/iSeries_irq.c:#include <asm/iSeries/HvCallXm.h>
./arch/ppc64/kernel/iSeries_pci.c:#include <asm/iSeries/HvCallXm.h>
./arch/ppc64/kernel/iSeries_proc.c:#include <asm/iSeries/HvCallXm.h>
./arch/ppc64/kernel/iSeries_setup.c:#include <asm/iSeries/HvCallXm.h>
./arch/ppc64/kernel/vio.c:#include <asm/iSeries/HvCallXm.h>
./arch/ppc64/kernel/time.c:#include <asm/iSeries/HvCallXm.h>
+++ ./ibm405.h 7 +++
./arch/ppc/platforms/4xx/ibm405ep.h:#include <asm/ibm405.h>
./arch/ppc/platforms/4xx/ibm405gp.h:#include <asm/ibm405.h>
./arch/ppc/platforms/4xx/ibm405gpr.h:#include <asm/ibm405.h>
./arch/ppc/platforms/4xx/ibmnp405h.h:#include <asm/ibm405.h>
./arch/ppc/platforms/4xx/ibmstb4.h:#include <asm/ibm405.h>
./arch/ppc/platforms/4xx/ibmstbx25.h:#include <asm/ibm405.h>
./arch/ppc/platforms/4xx/virtex-ii_pro.h:#include <asm/ibm405.h>
+++ ./lppaca.h 7 +++
./arch/ppc64/kernel/LparData.c:#include <asm/lppaca.h>
./arch/ppc64/kernel/asm-offsets.c:#include <asm/lppaca.h>
./arch/ppc64/kernel/iSeries_proc.c:#include <asm/lppaca.h>
./arch/ppc64/kernel/lparcfg.c:#include <asm/lppaca.h>
./arch/ppc64/kernel/pacaData.c:#include <asm/lppaca.h>
./arch/ppc64/kernel/sysfs.c:#include <asm/lppaca.h>
./include/asm-ppc64/paca.h:#include <asm/lppaca.h>
+++ ./iSeries/ItLpQueue.h 8 +++
./arch/ppc64/kernel/ItLpQueue.c:#include <asm/iSeries/ItLpQueue.h>
./arch/ppc64/kernel/LparData.c:#include <asm/iSeries/ItLpQueue.h>
./arch/ppc64/kernel/iSeries_proc.c:#include <asm/iSeries/ItLpQueue.h>
./arch/ppc64/kernel/iSeries_setup.c:#include <asm/iSeries/ItLpQueue.h>
./arch/ppc64/kernel/irq.c:#include <asm/iSeries/ItLpQueue.h>
./arch/ppc64/kernel/mf.c:#include <asm/iSeries/ItLpQueue.h>
./arch/ppc64/kernel/pacaData.c:#include <asm/iSeries/ItLpQueue.h>
./arch/ppc64/kernel/time.c:#include <asm/iSeries/ItLpQueue.h>
+++ ./immap_85xx.h 8 +++
./arch/ppc/platforms/85xx/mpc8540_ads.c:#include <asm/immap_85xx.h>
./arch/ppc/platforms/85xx/mpc8560_ads.c:#include <asm/immap_85xx.h>
./arch/ppc/platforms/85xx/mpc85xx_ads_common.c:#include <asm/immap_85xx.h>
./arch/ppc/platforms/85xx/mpc85xx_cds_common.c:#include <asm/immap_85xx.h>
./arch/ppc/platforms/85xx/sbc8560.c:#include <asm/immap_85xx.h>
./arch/ppc/platforms/85xx/sbc85xx.c:#include <asm/immap_85xx.h>
./arch/ppc/platforms/85xx/stx_gp3.c:#include <asm/immap_85xx.h>
./arch/ppc/syslib/ppc85xx_setup.c:#include <asm/immap_85xx.h>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* 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
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