* 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: [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: [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: [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
* 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: 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
* 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: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: Geert Uytterhoeven @ 2005-08-17 12:42 UTC (permalink / raw)
To: Andrey Volkov
Cc: Linux/PPC Development, Linux Frame Buffer Device Development,
surendra.yadav
In-Reply-To: <43032A76.6080104@varma-el.com>
On Wed, 17 Aug 2005, Andrey Volkov wrote:
> 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).
Sorry, I cannot follow.
1. If it's a palette issue, your setcolreg() routine doesn't fill in correctly
the pseudo palette,
2. If it's a RGB565 vs. BGR565 issue, you don't fill in correctly the offsets
in the color bitfields in fb_var_screeninfo,
3. If it's an endian issue, it's RRRRRGGGGGGBBBBB vs.GGBBBBBRRRRGGGG, right?
And then there's no much we can do...
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: Kumar Gala @ 2005-08-17 13:54 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-embedded list, linuxppc-dev list
In-Reply-To: <1124263872.3869.48.camel@localhost.localdomain>
> 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);
If we are going forward with this change for OF, can we kill
pc_serial.h and just move the default BASE_BAUD and RS_TABLE size
into serial.h.
- kumar
^ permalink raw reply
* When are machine checks suppose to be recoverable?
From: Kumar Gala @ 2005-08-17 14:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev list; +Cc: David Woodhouse
In-Reply-To: <1124209292.3869.5.camel@localhost.localdomain>
David's 8250 cleanup patch made me wondering when are machine checks
suppose to recoverable? General class of conditions is what I'm
looking for here.
Is David's case due to some PCI master abort or something else?
- kumar
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.
^ permalink raw reply
* Re: [F]Framebuffer driver using SM501 hardware.
From: Andrey Volkov @ 2005-08-17 14:23 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Linux Frame Buffer Device Development,
surendra.yadav
In-Reply-To: <Pine.LNX.4.62.0508171439060.6073@numbat.sonytel.be>
Geert Uytterhoeven wrote:
> On Wed, 17 Aug 2005, Andrey Volkov wrote:
>
>>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).
>
>
> Sorry, I cannot follow.
Ok, I'll try more clearly:
>
> 1. If it's a palette issue, your setcolreg() routine doesn't fill in correctly
> the pseudo palette,
> 2. If it's a RGB565 vs. BGR565 issue, you don't fill in correctly the offsets
> in the color bitfields in fb_var_screeninfo,
Yes, due to duality of SM501: in memory mapped mode, its endian same as
on the host, BUT in PCI mode it work only as little endian
(theoretically it could be switched to big endian too, but for PPC it
have not meaning).
Both above problems could be solved by #ifdef/#else in SM5xx driver (as
I said before, my driver in prerelease stage :) ).
But it will be more useful, IMHO, if somewhere in Kconfig will be
defined something like CONFIG_PCI_LITTLE_ENDIAN/
CONFIG_FB_TARGET_LITTLE_ENDIAN.
> 3. If it's an endian issue, it's RRRRRGGGGGGBBBBB vs.GGBBBBBRRRRGGGG, right?
Right. As I wrote before, when SM501 blitter work as PCI bus master, it
read/write from/to host memory in little endian mode. But situation
changed when HOST (MPC), read/write from/to framebuffer - PCI subsystem
of MPC convert endian on the fly :(.
Currently I've two workarounds:
1) Don't use SM501 as bus master (more preferably, since SM501 anyway
have some silicon bugs when work as bus master)
2) Try use different functions for accelerated/unaccelerated bitblit.
> And then there's no much we can do...
>
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: [F]Framebuffer driver using SM501 hardware.
From: Clemens Koller @ 2005-08-17 14:31 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Linux Frame Buffer Device Development,
surendra.yadav
In-Reply-To: <Pine.LNX.4.62.0508171439060.6073@numbat.sonytel.be>
Hi Geert, Andrey and friends...
I am working on ppc, MPC8540, SM501 on PCI,
drivers=voyagerfb-0.2.tar.gz from last post.
on linux-2.6
Geert wrote:
> Sorry, I cannot follow.
>
> 1. If it's a palette issue, your setcolreg() routine doesn't fill in correctly
> the pseudo palette,
> 2. If it's a RGB565 vs. BGR565 issue, you don't fill in correctly the offsets
> in the color bitfields in fb_var_screeninfo,
> 3. If it's an endian issue, it's RRRRRGGGGGGBBBBB vs.GGBBBBBRRRRGGGG, right?
> And then there's no much we can do...
It looks for me like 3. = bytes are flipped = an endian issue:
In 32 (RGBAlpha) mode (the one we want to use) the colors appear
wrong. I get my /dev/fb0 appear as
BB GG RR aa BB GG RR aa BB GG RR aa ...
In the great SM501 Databook Version 1.02, Page 2-39, it says:
Configuration 2, Endian Control at MMIO_base+0x00005c:
write 0x00000000 for little endian or
write 0xffffffff for big endian
into this register before touching any other register of the sm501.
I've tried that, but it didn't change anything on my system. :-(
(Well, we can flip the DAC outputs in our hw design ;-)
Best greets,
Clemens
_______________________________
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
------------------------------------------------
details:
$ cp red /dev/fb0
gives me a some red color...
$ bvi red
00000000 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
00000010 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
00000020 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
...
$ cp green /dev/fb0
gives me a some green color...
00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00
...
$ cp blue /dev/fb0
well... blue
FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00
^ permalink raw reply
* Re: [F]Framebuffer driver using SM501 hardware.
From: Andrey Volkov @ 2005-08-17 14:52 UTC (permalink / raw)
To: Clemens Koller
Cc: Linux/PPC Development, Geert Uytterhoeven,
Linux Frame Buffer Device Development, surendra.yadav
In-Reply-To: <43034A59.6000008@anagramm.de>
Clemens Koller wrote:
> Hi Geert, Andrey and friends...
>
> I am working on ppc, MPC8540, SM501 on PCI,
> drivers=voyagerfb-0.2.tar.gz from last post.
> on linux-2.6
>
> Geert wrote:
>
>> Sorry, I cannot follow.
>>
>> 1. If it's a palette issue, your setcolreg() routine doesn't fill in
>> correctly
>> the pseudo palette,
>> 2. If it's a RGB565 vs. BGR565 issue, you don't fill in correctly the
>> offsets
>> in the color bitfields in fb_var_screeninfo,
>> 3. If it's an endian issue, it's RRRRRGGGGGGBBBBB vs.GGBBBBBRRRRGGGG,
>> right?
>> And then there's no much we can do...
>
>
> It looks for me like 3. = bytes are flipped = an endian issue:
> In 32 (RGBAlpha) mode (the one we want to use) the colors appear
> wrong. I get my /dev/fb0 appear as
> BB GG RR aa BB GG RR aa BB GG RR aa ...
>
> In the
> great
You're forget qutation here :)
SM501 Databook Version 1.02, Page 2-39, it says:
> Configuration 2, Endian Control at MMIO_base+0x00005c:
> write 0x00000000 for little endian or
> write 0xffffffff for big endian
> into this register before touching any other register of the sm501.
> I've tried that, but it didn't change anything on my system. :-(
> (Well, we can flip the DAC outputs in our hw design ;-)
As I understand, but I'm not sure, LE/BE controlled only by some GPIO
pin (GPIO4 was on rev A/B). I try write to this reg too, with same result.
>
> Best greets,
>
> Clemens
> _______________________________
> 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
>
> ------------------------------------------------
> details:
>
> $ cp red /dev/fb0 gives me a some red color...
> $ bvi red
> 00000000 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
> 00000010 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
> 00000020 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
> ...
> $ cp green /dev/fb0 gives me a some green color...
> 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00
> ...
> $ cp blue /dev/fb0
> well... blue
> FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00
>
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Tom Rini @ 2005-08-17 15:05 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev list, linuxppc-embedded list
In-Reply-To: <1124263872.3869.48.camel@localhost.localdomain>
On Wed, Aug 17, 2005 at 08:31:11AM +0100, David Woodhouse wrote:
> 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;
> },
> };
So long as you convert arch/ppc/boot/ to this as well, why not (or at
least being able to grab the infos from these structs somehow).
Once everyone is on a flat tree, I don't object to killing all of the
old-style uart definitions steaming out of <asm-ppc/serial.h>.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Kumar Gala @ 2005-08-17 15:22 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev list, David Woodhouse, linuxppc-embedded list
In-Reply-To: <20050817150536.GN8214@smtp.west.cox.net>
> So long as you convert arch/ppc/boot/ to this as well, why not (or at
> least being able to grab the infos from these structs somehow).
>
> Once everyone is on a flat tree, I don't object to killing all of the
> old-style uart definitions steaming out of <asm-ppc/serial.h>.
Tom, do have a test system that I can look at converting that you
would be willing to test the changes to arch/ppc/boot for me.
(everything I boot doesn't use it)
- kumar
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Tom Rini @ 2005-08-17 15:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, David Woodhouse, linuxppc-embedded list
In-Reply-To: <DCB7B3B3-635C-400A-BBAC-DF092AD5B143@freescale.com>
On Wed, Aug 17, 2005 at 10:22:54AM -0500, Kumar Gala wrote:
> >So long as you convert arch/ppc/boot/ to this as well, why not (or at
> >least being able to grab the infos from these structs somehow).
> >
> >Once everyone is on a flat tree, I don't object to killing all of the
> >old-style uart definitions steaming out of <asm-ppc/serial.h>.
>
> Tom, do have a test system that I can look at converting that you
> would be willing to test the changes to arch/ppc/boot for me.
With Matt's patch, you could boot a PReP kernel (no VGA con) :)
But if you convert LoPEC, I'll throw the kernel at it.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Kumar Gala @ 2005-08-17 16:16 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev list, David Woodhouse, linuxppc-embedded list
In-Reply-To: <20050817153013.GO8214@smtp.west.cox.net>
On Aug 17, 2005, at 10:30 AM, Tom Rini wrote:
> On Wed, Aug 17, 2005 at 10:22:54AM -0500, Kumar Gala wrote:
>
>
>>> So long as you convert arch/ppc/boot/ to this as well, why not
>>> (or at
>>> least being able to grab the infos from these structs somehow).
>>>
>>> Once everyone is on a flat tree, I don't object to killing all of
>>> the
>>> old-style uart definitions steaming out of <asm-ppc/serial.h>.
>>>
>>
>> Tom, do have a test system that I can look at converting that you
>> would be willing to test the changes to arch/ppc/boot for me.
>>
>
> With Matt's patch, you could boot a PReP kernel (no VGA con) :)
> But if you convert LoPEC, I'll throw the kernel at it.
Does PReP use bootcode? I thought it was OF based, but what do I know.
- kumar
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Matt Porter @ 2005-08-17 16:27 UTC (permalink / raw)
To: Kumar Gala
Cc: Tom Rini, linuxppc-embedded list, David Woodhouse,
linuxppc-dev list
In-Reply-To: <184D9473-D0E7-4424-A25F-60381472C10A@freescale.com>
On Wed, Aug 17, 2005 at 11:16:39AM -0500, Kumar Gala wrote:
>
> On Aug 17, 2005, at 10:30 AM, Tom Rini wrote:
>
> > On Wed, Aug 17, 2005 at 10:22:54AM -0500, Kumar Gala wrote:
> >
> >
> >>> So long as you convert arch/ppc/boot/ to this as well, why not
> >>> (or at
> >>> least being able to grab the infos from these structs somehow).
> >>>
> >>> Once everyone is on a flat tree, I don't object to killing all of
> >>> the
> >>> old-style uart definitions steaming out of <asm-ppc/serial.h>.
> >>>
> >>
> >> Tom, do have a test system that I can look at converting that you
> >> would be willing to test the changes to arch/ppc/boot for me.
> >>
> >
> > With Matt's patch, you could boot a PReP kernel (no VGA con) :)
> > But if you convert LoPEC, I'll throw the kernel at it.
>
> Does PReP use bootcode? I thought it was OF based, but what do I know.
Are you asking on a real machine or on qemu? On real PReP hardwrae
you can find both OF and other firmware like PPCBUG...in both cases
they dump residual data. On qemu, jmayer wrote the openhackware bios
with is supposed to be some minimal OF-like thing...it dumps
residual data too.
-Matt
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Tom Rini @ 2005-08-17 16:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, David Woodhouse, linuxppc-embedded list
In-Reply-To: <184D9473-D0E7-4424-A25F-60381472C10A@freescale.com>
On Wed, Aug 17, 2005 at 11:16:39AM -0500, Kumar Gala wrote:
>
> On Aug 17, 2005, at 10:30 AM, Tom Rini wrote:
>
> >On Wed, Aug 17, 2005 at 10:22:54AM -0500, Kumar Gala wrote:
> >
> >
> >>>So long as you convert arch/ppc/boot/ to this as well, why not
> >>>(or at
> >>>least being able to grab the infos from these structs somehow).
> >>>
> >>>Once everyone is on a flat tree, I don't object to killing all of
> >>>the
> >>>old-style uart definitions steaming out of <asm-ppc/serial.h>.
> >>>
> >>
> >>Tom, do have a test system that I can look at converting that you
> >>would be willing to test the changes to arch/ppc/boot for me.
> >>
> >
> >With Matt's patch, you could boot a PReP kernel (no VGA con) :)
> >But if you convert LoPEC, I'll throw the kernel at it.
>
> Does PReP use bootcode? I thought it was OF based, but what do I know.
In qemu? Yes, it does.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Tom Rini @ 2005-08-17 16:35 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-dev list, David Woodhouse, linuxppc-embedded list
In-Reply-To: <20050817092703.B6355@cox.net>
On Wed, Aug 17, 2005 at 09:27:03AM -0700, Matt Porter wrote:
> On Wed, Aug 17, 2005 at 11:16:39AM -0500, Kumar Gala wrote:
> >
> > On Aug 17, 2005, at 10:30 AM, Tom Rini wrote:
> >
> > > On Wed, Aug 17, 2005 at 10:22:54AM -0500, Kumar Gala wrote:
> > >
> > >
> > >>> So long as you convert arch/ppc/boot/ to this as well, why not
> > >>> (or at
> > >>> least being able to grab the infos from these structs somehow).
> > >>>
> > >>> Once everyone is on a flat tree, I don't object to killing all of
> > >>> the
> > >>> old-style uart definitions steaming out of <asm-ppc/serial.h>.
> > >>>
> > >>
> > >> Tom, do have a test system that I can look at converting that you
> > >> would be willing to test the changes to arch/ppc/boot for me.
> > >>
> > >
> > > With Matt's patch, you could boot a PReP kernel (no VGA con) :)
> > > But if you convert LoPEC, I'll throw the kernel at it.
> >
> > Does PReP use bootcode? I thought it was OF based, but what do I know.
>
> Are you asking on a real machine or on qemu? On real PReP hardwrae
> you can find both OF and other firmware like PPCBUG...in both cases
> they dump residual data. On qemu, jmayer wrote the openhackware bios
> with is supposed to be some minimal OF-like thing...it dumps
> residual data too.
But either way, the kernel boots using the code in arch/ppc/boot/simple/
which uses serial values from <asm-ppc/pc_serial.h>
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: David Woodhouse @ 2005-08-17 16:39 UTC (permalink / raw)
To: Russell King; +Cc: linuxppc-dev
In-Reply-To: <20050817121128.A19990@flint.arm.linux.org.uk>
On Wed, 2005-08-17 at 12:11 +0100, Russell King wrote:
> Doesn't PPC64 have NO_IRQ ?
PPC64 does but I find no definition of is_real_interrupt() other than
the bogus one in 8250.c which checks for zero. PPC32 does not -- let's
clean that one up separately.
--- linux-2.6.12/drivers/serial/Makefile~ 2005-08-11 13:51:50.000000000 +0100
+++ linux-2.6.12/drivers/serial/Makefile 2005-08-15 21:08:49.000000000 +0100
@@ -22,6 +22,7 @@ obj-$(CONFIG_SERIAL_8250_ACCENT) += 8250
obj-$(CONFIG_SERIAL_8250_BOCA) += 8250_boca.o
obj-$(CONFIG_SERIAL_8250_HUB6) += 8250_hub6.o
obj-$(CONFIG_SERIAL_8250_MCA) += 8250_mca.o
+obj-$(CONFIG_SERIAL_8250_OF) += 8250_of.o
obj-$(CONFIG_SERIAL_AMBA_PL010) += amba-pl010.o
obj-$(CONFIG_SERIAL_AMBA_PL011) += amba-pl011.o
obj-$(CONFIG_SERIAL_CLPS711X) += clps711x.o
--- 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,197 @@
+#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
+
+/*
+ * 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;
+ }
+
+ /* 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) ? *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)
+{
+ 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);
--- 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
+
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;
- };
-
- 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,4 @@
#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 /* */
-#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 */
--
dwmw2
^ permalink raw reply
* Re: [PATCH] Use platform device for 8250 registration
From: Russell King @ 2005-08-17 16:46 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1124296771.3869.74.camel@localhost.localdomain>
On Wed, Aug 17, 2005 at 05:39:30PM +0100, David Woodhouse wrote:
> On Wed, 2005-08-17 at 12:11 +0100, Russell King wrote:
> > Doesn't PPC64 have NO_IRQ ?
>
> PPC64 does but I find no definition of is_real_interrupt() other than
> the bogus one in 8250.c which checks for zero. PPC32 does not -- let's
> clean that one up separately.
Ok. I'll give you this line now for this patch:
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
so you're free to push it upstream whenever you deem is the right time.
Thanks.
--
Russell King
^ permalink raw reply
* [PATCH] ppc32: ppc_sys SOC identification additions
From: Vitaly Bordug @ 2005-08-17 17:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded list
[-- Attachment #1: Type: text/plain, Size: 142 bytes --]
Kumar,
this is proposed extension of ppc_sys identify functions.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
--
Sincerely,
Vitaly
[-- Attachment #2: ppc_sys_add.patch --]
[-- Type: text/x-patch, Size: 2509 bytes --]
diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
--- a/arch/ppc/syslib/ppc_sys.c
+++ b/arch/ppc/syslib/ppc_sys.c
@@ -6,6 +6,7 @@
* Maintainer: Kumar Gala <kumar.gala@freescale.com>
*
* Copyright 2005 Freescale Semiconductor Inc.
+ * Copyright 2005 MontaVista, Inc. by Vitaly Bordug <vbordug@ru.mvista.com>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -35,10 +36,58 @@ void __init identify_ppc_sys_by_id(u32 i
void __init identify_ppc_sys_by_name(char *name)
{
- /* TODO */
+ unsigned int i = 0;
+ while (strcmp(ppc_sys_specs[i].ppc_sys_name, "")) {
+ if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
+ break;
+ i++;
+ }
+ cur_ppc_sys_spec = &ppc_sys_specs[i];
return;
}
+static int __init count_sys_specs(void)
+{
+ int i = 0;
+ while (strcmp(ppc_sys_specs[i].ppc_sys_name, ""))
+ i++;
+ return i;
+}
+
+static int __init find_chip_by_name_and_id(char *name, u32 id)
+{
+ int ret = -1;
+ unsigned int i = 0;
+ unsigned int j = 0;
+ unsigned int dups = 0;
+
+ unsigned char matched[count_sys_specs()];
+
+ while (strcmp(ppc_sys_specs[i].ppc_sys_name, "")) {
+ if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
+ matched[j++] = i;
+ i++;
+ }
+ if (j != 0) {
+ for (i = 0; i < j; i++) {
+ if ((ppc_sys_specs[matched[i]].mask & id) ==
+ ppc_sys_specs[matched[i]].value) {
+ ret = matched[i];
+ dups++;
+ }
+ }
+ ret = (dups == 1) ? ret : (-1 * dups);
+ }
+ return ret;
+}
+
+void __init identify_ppc_sys_by_name_and_id(char *name, u32 id)
+{
+ int i = find_chip_by_name_and_id(name, id);
+ BUG_ON(i < 0);
+ cur_ppc_sys_spec = &ppc_sys_specs[i];
+}
+
/* Update all memory resources by paddr, call before platform_device_register */
void __init
ppc_sys_fixup_mem_resource(struct platform_device *pdev, phys_addr_t paddr)
diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
--- a/include/asm-ppc/ppc_sys.h
+++ b/include/asm-ppc/ppc_sys.h
@@ -51,7 +51,8 @@ extern struct ppc_sys_spec *cur_ppc_sys_
/* determine which specific SOC we are */
extern void identify_ppc_sys_by_id(u32 id) __init;
-extern void identify_ppc_sys_by_name(char *name) __init;
+extern void identify_ppc_sys_by_name(char* name) __init;
+extern void identify_ppc_sys_by_name_and_id(char *name, u32 id) __init;
/* describes all devices that may exist in a given family of processors */
extern struct platform_device ppc_sys_platform_devices[];
^ permalink raw reply
* Re: Redwood-6 and 2.6
From: Dale Farnsworth @ 2005-08-17 19:18 UTC (permalink / raw)
To: Otto Solares, linuxppc-embedded
In-Reply-To: <20050817031336.GA20712@xyzzy.farnsworth.org>
On Wed, Aug 17, 2005 at 03:13:36AM +0000, Dale Farnsworth wrote:
> 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.
Just following up. I verified that current linux-2.6.git netboots
fine on redwood5 using the SMC91111.
-Dale
^ 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