Re: [PATCH] Add Fixed PHY support for ucc_geth
On Tue, 18 Mar 2008 10:46:55 +0100
Joakim Tjernlund wrote:
> The new Fixed PHY method, fixed-link property, isn't
> impl. for ucc_geth which makes fixed PHYs non functional.
> Add support for the new method to restore the Fixed PHY
> functionality.
>
Makes sense to me, but let's cc linuxppc-devel
> Signed-off-by: Joakim Tjernlund <[EMAIL PROTECTED]>
Acked-by: Vitaly Bordug <[EMAIL PROTECTED]>
> ---
>
> This is a regression as fixed PHYs works in 2.6.23 and I am
> using it.
>
> drivers/net/ucc_geth.c | 53
> +++ 1 files changed, 30
> insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index ecc5712..18c8b39 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -3836,6 +3836,7 @@ static int ucc_geth_probe(struct of_device*
> ofdev, const struct of_device_id *ma struct device_node *phy;
> int err, ucc_num, max_speed = 0;
> const phandle *ph;
> + const u32 *fixed_link;
> const unsigned int *prop;
> const char *sprop;
> const void *mac_addr;
> @@ -3926,18 +3927,38 @@ static int ucc_geth_probe(struct of_device*
> ofdev, const struct of_device_id *ma
> ug_info->uf_info.regs = res.start;
> ug_info->uf_info.irq = irq_of_parse_and_map(np, 0);
> + fixed_link = of_get_property(np, "fixed-link", NULL);
> + if (fixed_link) {
> + ug_info->mdio_bus = 0;
> + ug_info->phy_address = fixed_link[0];
> + phy = NULL;
> + } else {
> + ph = of_get_property(np, "phy-handle", NULL);
> + phy = of_find_node_by_phandle(*ph);
>
> - ph = of_get_property(np, "phy-handle", NULL);
> - phy = of_find_node_by_phandle(*ph);
> + if (phy == NULL)
> + return -ENODEV;
>
> - if (phy == NULL)
> - return -ENODEV;
> + /* set the PHY address */
> + prop = of_get_property(phy, "reg", NULL);
> + if (prop == NULL)
> + return -1;
> + ug_info->phy_address = *prop;
> +
> + /* Set the bus id */
> + mdio = of_get_parent(phy);
> +
> + if (mdio == NULL)
> + return -1;
>
> - /* set the PHY address */
> - prop = of_get_property(phy, "reg", NULL);
> - if (prop == NULL)
> - return -1;
> - ug_info->phy_address = *prop;
> + err = of_address_to_resource(mdio, 0, &res);
> + of_node_put(mdio);
> +
> + if (err)
> + return -1;
> +
> + ug_info->mdio_bus = res.start;
> + }
>
> /* get the phy interface type, or default to MII */
> prop = of_get_property(np, "phy-connection-type", NULL);
> @@ -3982,20 +4003,6 @@ static int ucc_geth_probe(struct of_device*
> ofdev, const struct of_device_id *ma ug_info->numThreadsRx =
> UCC_GETH_NUM_OF_THREADS_4; }
>
> - /* Set the bus id */
> - mdio = of_get_parent(phy);
> -
> - if (mdio == NULL)
> - return -1;
> -
> - err = of_address_to_resource(mdio, 0, &res);
> - of_node_put(mdio);
> -
> - if (err)
> - return -1;
> -
> - ug_info->mdio_bus = res.start;
> -
> if (netif_msg_probe(&debug))
> printk(KERN_INFO "ucc_geth: UCC%1d at 0x%8x (irq =
> %d) \n", ug_info->uf_info.ucc_num + 1, ug_info->uf_info.regs,
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Where is fcc_enet.c
On Sun, 10 Feb 2008 15:08:46 -0800 Bizhan Gholikhamseh (bgholikh) wrote: > Hi, > I am porting to Linux 2.6.24 from linux 2.6.11 on mpc85xx cds > platform, I am not able to locate fcc_enet.c file under > linux 2.6.24 source tree, any idea try drivers/net/fs_enet at least CPM2 FCC is handled in there. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 83xx, ELDK 2.6.23, IP-Config: No network devices
On Sun, 30 Dec 2007 16:51:44 -0800 Russell McGuire wrote: > 1) Is there some basic kernel feature I am missing? I have enabled > the GIGE UEC GETH driver in the kernel. Perhaps a PHY LIB? Isn't > generic MII supported by default? > yes you will need phylib > 2) Is there something in the startup board files, that I need to add > to register my PHY like an of_put_node()? Again I have pretty much > copied the MPC8360E MDS board and it is starting, and defining the > par_io port already, except that my PHY ID dev ID 0x01>. However, I don't see the probe function being called, > so I don't think this is a concern yet. I think you will need to write a driver for your specific PHY access to get it covered by phy abstraction layer. Generic mii thing is useful when it has access to phy regs somehow (live examples are some BCM phys that do not have specs available but the thing works using generic mii and standard phy regs). -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC885 - USB HCI drivers.
On Thu, 20 Dec 2007 08:53:07 +0200 Jonathan Journo wrote: > Hello Pantelis , > > I saw you used usb host driver on mpc8xx. I am trying to make one on > MPC885 because vxworks drivers are not compatible with it. > > To begin I tried to make the loopback mode (test) working but it > doesn't work. Is there anything that is not mentioned on the > datasheet in" USB host controller initialization example" that I have > to know to make it work. iirc, Panto was working with 8271, not 8xx hci. I made some investigations, basing on driver from Arabella SW. The whole thing needs microcode upload and is very flakey from what I recall. In fact I gave up b/c it was not doing things described in datasheet, so the same case. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: USB configuration
On Thu, 6 Dec 2007 05:27:14 -0800 (PST) Misbah khan wrote: > > HI all ... > I have configured the Montavista Kernel for USB support and for > PPC8272-ADS board I need to know that how could i test that my USB is > working > I'm not sure what MV version you are trying to use, but there is no support for USB host(I am about 8272ads). MV supports USB gadget though... > Its creating the directory :- /proc/bus/usb/ but doesent contain any > file under it > you enabled generic usb support. But no HW/driver picking it up > > its also creating the directory :- /sys/bus/usb/ but doesent > contain any file under it > same reason > > Please let me know the procedure to test whether my USB configuration > is all right > First, if you want to use USB host, you'll have to develop the driver first or assist someone doing that (there yet another such attempt recently initiated - see linuxppc-dev logs) > Thank u > Misbah <>< -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: I2C support for 8541
Hello Charles, On Mon, 30 Apr 2007 09:25:28 -0700 Charles Krinke wrote: > Assuming I have the external IRQ's understood, the next issue is the > hardware clock on our board with the linux-2.6.17.11 kernel. We are > using a "DS1338U", which is an I2C RTC. > > I am trying to identify the relevant source for the 8541/8555 I2C > interface in the source base which reads/writes I2MOD, I2ADD, II2BRG, > I2COM, I2CER & I2CMR. > > I can find a few references to MPC85xx_CPM_I2C in > ../syslib/mpc85xx_devices.c, but nothing close in drivers/i2c/... > > Can someone help me understand the completeness of the I2C source in the > 2.6.17.11 kernel, please. > i2c-mpc.c is prolly responsible to care of 8xxx i2c stuff... HTH > Charles Krinke > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded signature.asc Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: USB Host Controller MPC875 Linux 2.6
Hello Henrik, On Sun, 29 Apr 2007 19:19:09 +0200 (CEST) Henrik Larson wrote: > > Hi, > > I have a board with a MPC875 processor with a Linux 2.6.16 kernel and > looking for USB support. > > Previous, for the 2.4 kernel, I've used used Brad Parker's > m8xxhci driver (with success). > > Does anyone know if there is a Linux 2.6.x USB Host Controller driver > for MPC875 (or MPC8xx) somewhere ? > Not that I am aware of. Even on 2.4, Brad's driver was not apparent to get to work. So moving USB host forward never seemed like a worthwhile idea so far. > > Thanks. > > /Henrik > > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded signature.asc Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC82xx ADS SCC ports initialisation
On Wed, 11 Jul 2007 09:11:18 +0200 Laurent Pinchart wrote: > On Tuesday 10 July 2007 20:11, Scott Wood wrote: > > On Tue, Jul 10, 2007 at 04:19:51PM +0200, Laurent Pinchart wrote: > > > clrbits32(&immap->im_cpmux.cmx_scr, (0x0007 << (4 - > > > data->clk_tx))); clrbits32(&immap->im_cpmux.cmx_scr, (0x0038 > > > << (4 - data->clk_rx))); setbits32(&immap->im_cpmux.cmx_scr, > > > ((data->clk_tx - 1) << (4 - data->clk_tx))); > > > setbits32(&immap->im_cpmux.cmx_scr, > > > ((data->clk_rx - 1) << (4 - data->clk_rx))); > > > > > > The shift right-hand operand doesn't seem to be correct. Could > > > anyone confirm this ? > > > > You are correct; it's broken. > > That code should be replaced with calls to cpm2_clk_setup > (arch/powerpc/sysdev/cpm2_common.c). cpm2_clk_setup currently > supports FCC clock setup only, but I've got a patch to add SCC clock > setup support. Should I send it ? > If you have functional approach, please feel free to send it... > > > If my assumption is right, could anyone tell me if the MPC82xx > > > processors are actually supported by the powerpc architecture, or > > > if the MPC82xx ADS code is just a non-functional work in progress. > > once my last changes were committed, 82xx was supported and worked fine. Pretty long time I had no access to the hardware, hence some minor things might require catch-up. > > I have a bunch of 8xx/82xx changes pending; I hope to get them > > cleaned up before the merge window ends. > Since I'm the only person covering 8xx/82xx for a while, I definitely want to look at those changes... > That would be nice. I'll wait for your changes to continue my ppc -> > powerpc port. > > > > I also noticed that U-Boot doesn't have flatten device tree > > > support for the MPC82xx family. > > At the moment, I have a patch to add such a thing, but no ability to validate it still works. If you guys will assist a little, I'll go ahead and submit it to the u-boot list. > > No, but cuImage for 82xx is on its way. > > Ok, nice to know. Adding FDT support to U-Boot for the MPC82xx family > will be on my todo-list once I get Linux working with cuImage. > > Laurent Pinchart signature.asc Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Still trying to get a stable 2.6.20.4 running on 8349ITX eval board
On Wed, 11 Apr 2007 13:47:55 -0700 [EMAIL PROTECTED] wrote: > Hi, > > Posted a cry for help a few days ago on this issue ;)> . Got a couple of > answers that didn't get me any farther so I'm on another fishing > expedition. Basic set up is as follows; MPC8349ITX eval board; 2.6.20.4 > kernel; a ubuntu/dapper FS via NFS. The problem seems to be a random > lock-up in either a DSI exception (0x300), a program exception (0x700) or > a DTLB miss on store exception (0x1200). I'm sure it's not truly random > (I'm sure there's probably only a single underlying problem), but it's > random in how it manifests. When trying to mount the root FS via NFS, it > always successfully reaches the point where it runs "/sbin/init" in > main.c, but which script it fails in varies and it never gets to a login. > > I've tried passing "init=/bin/sh" on the command line and I can reach a sh > prompt, but it doesn't take long before it locks up. I can do a "find . > -name '*gcc*'" about four times before it stops. I have a BDI2K hooked up > so I know where it's stopping (most commonly in the DTLB miss mentioned > above), but backtrace from GDB gets me nothing, and SRR0 and SRR1 don't > contain any useful information (frequently they're both zero). I expect > it may be an interaction with the BDI, tho I'm not sure. > > I've also tried a couple of other file systems (one right off the CD that > ships with the eval board and the latest from ELDK) as well as pulling > Kumar's powerpc kernel tree. All possible combinations of these kernels > and file systems fail to run for any period of time. > > Long winded way to get around to my questions (sorry :( ): > 1) Can any one point me to good references in using the BDI2K to find my > way back from exceptions? > 2) I assume someone (Kumar?) has gotten some combination of kernel/FS to > boot and run on this box. What combination is that? > > It worked for me with both MontaVista and ELDK rfs for 6xx. Your problem looks very much like odd DDR or memctl misconfiguration early in u-boot. Please try upgrading your firmware with the latest u-boot from git tree at denx.de. Kernel from Paul Mackerras (powerpc.git) is also a good thing to give a try. Also, there is Vitesse switch on this target, which should be initialized(Normally with vendor-shipped image you'll figure out how by print thirdp_init. Starting kernel without that may result in some instability too. Hope it helps. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC 8349e-mITX and MTD/Flash
On Tue, 10 Apr 2007 10:48:43 -0500 Timur Tabi <[EMAIL PROTECTED]> wrote: > Having said that, it seems that the kernel now supports defining the physmap > via the OF > tree. Is that true? Yes, we drafted some stuff while working on mpc8540ads - see drivers/mtd/maps/physmap_of.c -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Unable to boot kernel on MPC8349ITX eval board
On Thu, 5 Apr 2007 11:33:19 -0700 [EMAIL PROTECTED] wrote: > Modules linked in: > NIP: 0FE741B0 LR: 0FE76464 CTR: > REGS: c0001f50 TRAP: 0301 Not tainted (2.6.20.4) > MSR: D032 CR: XER: > DAR: 7F9A26C8, DSISR: 2000 > TASK = c0656030[865] 'udevd' THREAD: cfb0 > GPR00: 0019 7F99E6A0 30023290 100155F8 28D8 0FE76464 0019 > 0FF521C0 > GPR08: 100155F8 3D407265 FFD0 22004442 > NIP [0FE741B0] 0xfe741b0 > LR [0FE76464] 0xfe76464 > Call Trace: > <0>Kernel panic - not syncing: Fatal exception in interrupt > <0>Rebooting in 180 seconds.. You should build the kernel with debugging enabled - to extract what kernel module caused the oops. Try to disable that "[ ok ]rting kernel event manager..." service, look up what script says "* Loading hardware drivers..." and make it tell what exactly it tries to insmod. Also, you can use any other ppc root (eldk, freescale, buildroot etc...) -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Allocating (placing) BufferDescriptors in Dual-Port RAM (CPM2)
On Sun, 01 Apr 2007 00:26:19 +0200 Robert Staven <[EMAIL PROTECTED]> wrote: > It's probably basic knowledge, but I still having trouble figure it > out anyway: > > Working with a SCC in a CPM (MPC8250 running linux 2.6.13-AM) > > I need to place Buffer Descriptors (BD) in the Dual-Port RAM (DPRAM) > somewhere > But two FCCs, SMC1 and SCC1 are in use, and they might use some part of > the DPRAM. > ... cpm_dpalloc() will work for you I guess. > Is there any way to figure out what part of the DPRAM thats free? > And how to reserve the part I need? > > Robert > > (SCC3 parameter RAM are at 0x8200 in DPRAM so I just place a struct > there and assume that linux stays away from this memory area and don't > get mad cause I use it without allocating it. Or have I got this wrong to?) > I'd suggest to look at the implemented 8260-like stuff and platform device approach (syslib/pq2_devices.c). Whole immr including DPRAM are is io_block_mapped early by the platform code so you can do stuff in brackets I guess, but that might look weird and be more complex to debug. Thanks. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MDIO bus description and bitbang property
On Fri, 30 Mar 2007 23:15:47 +0400 "Matvejchikov Ilya" <[EMAIL PROTECTED]> wrote: > Hi all! > > As I see it mpc82xx MDIO description given in DTS file contains several > inaccuracies concerning 'bitbang' property. Thus, 'bitbang' is the property > of MDIO bus, but not a device on the bus (PHY for ex.). I have changed > fs_enet_of_init() a little bit. Does anyone require such a patch? Sorry but I don't quite follow the logic upper. If you have a patch, pls send it to me CC this list and we'll get it discussed. Thanks. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ELDK4.1, TQM860L, Kernel 2.6.19
On Mon, 19 Mar 2007 21:21:01 -0700 Thomas Maenner <[EMAIL PROTECTED]> wrote: > Hi, > > I've downloaded ELDK4.1 and tried to compile the included kernel 2.6.19.2 > with: > make mrproper > make TQM860L_defconfig > make > (No other changes) > > At the end of the compile I get: > ---snip--- > UIMAGE arch/ppc/boot/images/uImage > Image Name: Linux-2.6.19.2 > Created: Mon Mar 19 15:50:14 2007 > Image Type: PowerPC Linux Kernel Image (gzip compressed) > Data Size:979098 Bytes = 956.15 kB = 0.93 MB > Load Address: 0x > Entry Point: 0x > Image: arch/ppc/boot/images/uImage is ready > AS arch/ppc/boot/simple/head.o > AS arch/ppc/boot/simple/relocate.o > CC arch/ppc/boot/simple/misc-embedded.o > CC arch/ppc/boot/simple/embed_config.o > arch/ppc/boot/simple/embed_config.c:31: warning: 'bdinfo' defined but not used > arch/ppc/boot/simple/embed_config.c:44: warning: 'def_enet_addr' defined but > not used > CC arch/ppc/boot/simple/m8xx_tty.o > arch/ppc/boot/simple/m8xx_tty.c:32: error: static declaration of 'cpmp' > follows non-static declaration > include/asm/commproc.h:74: error: previous declaration of 'cpmp' was here > make[2]: *** [arch/ppc/boot/simple/m8xx_tty.o] Error 1 > make[1]: *** [simple] Error 2 > make: *** [zImage] Error 2 > --- > > Just in order to get it to compile, I took out static in > arch/ppc/boot/simple/m8xx_tty.c: > line 32: cpm8xx_t*cpmp = (cpm8xx_t *)&(((immap_t > *)IMAP_ADDR)->im_cpm); > > BTW, same thing happens if TQM823 config is used. > > I'm probably doing something wrong here... ;) > Well, after make foo_defconfig I usually do make uImage since with u-boot equipped boards full zImage is not required. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [patch 1/1] ppc: Possible bug fix for FCC driver
On Tue, 6 Mar 2007 12:03:57 +0100 Cedric Pontois wrote: > Hi Vitaly, > > The problem seems to be similar in recent kernels > (/drivers/net/fs_enet/mac-fcc.c). The transmit clock is inverted (TCI > bit set). The packets are well received, transmitted packets go out > (tx counter is ok), unfortunately as the clock is inverted (TCI) the > data are not correctly received by the other side. The FCC works in > 100Mbps (luck?) but doesn't in 10Mbps. I solved this problem by > removing the TCI bit set as described in the patch. Actually, this > problem depends also of the Ethernet phy used on board. > IIRC it worked for us with Davicom PHY on 10 MBps on one of 8260-like... Well I give it a try once more with the recent kernel, but anyway if you think you've located and fixed root cause, do (and test) a patch against recent kernel, send it to me cc'ing netdev and linuxppc-embedded, and I'll push it along if it is not breaking existing boards. -Vitaly > Cedric > > -Original Message- > From: Vitaly Bordug [mailto:[EMAIL PROTECTED] > Sent: mardi 6 mars 2007 10:42 > To: Li Yang-r58472 > Cc: Pontois, Cedric UMTS (CEZ:8Z10); [EMAIL PROTECTED]; > linux-kernel@vger.kernel.org; linuxppc-embedded@ozlabs.org > Subject: Re: [patch 1/1] ppc: Possible bug fix for FCC driver > > > On Tue, 6 Mar 2007 10:23:43 +0800 > Li Yang-r58472 wrote: > > > Hi Cedric, > > > > For ppc embedded related patches, please also cc: > > [EMAIL PROTECTED] > > > > > We use a kernel 2.6.14 on PPC platform (MPC 8555). The FCC driver > > works > > > > To submit a kernel patch upstream, the patch should be against the > > latest kernel version which is 2.6.21-rc now. > > > well with a 100Mbps link. But it doesn't with a 10Mbps link. To > > > solve it, I modified the GFMR register init: removed TCI bit and > > > set > > > > CRC32 > > bit > > > instead of. > > > > I don't know how these bits caused the 10M link issue. Do you have > > any reasoning? > > > > > Signed-off-by: Cedric Pontois <[EMAIL PROTECTED]> > > > > > > > > -- > > -- > > > - > > > > > > diff -ruN pa-original/arch/ppc/8260_io/fcc_enet.c > The fcc code in 8260_io has been obsoleted by fs_enet driver > (drivers/net/fs_enet). It is known to work with 85xx at least in > recent kernels. If it does not for some reason, please letus know. > > Thanks, > > -Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [patch 1/1] ppc: Possible bug fix for FCC driver
On Tue, 6 Mar 2007 10:23:43 +0800 Li Yang-r58472 wrote: > Hi Cedric, > > For ppc embedded related patches, please also cc: > [EMAIL PROTECTED] > > > We use a kernel 2.6.14 on PPC platform (MPC 8555). The FCC driver > works > > To submit a kernel patch upstream, the patch should be against the > latest kernel version which is 2.6.21-rc now. > > well with a 100Mbps link. But it doesn't with a 10Mbps link. To > > solve it, I modified the GFMR register init: removed TCI bit and > > set CRC32 > bit > > instead of. > > I don't know how these bits caused the 10M link issue. Do you have > any reasoning? > > > Signed-off-by: Cedric Pontois <[EMAIL PROTECTED]> > > > > > > > - > > > > diff -ruN pa-original/arch/ppc/8260_io/fcc_enet.c The fcc code in 8260_io has been obsoleted by fs_enet driver (drivers/net/fs_enet). It is known to work with 85xx at least in recent kernels. If it does not for some reason, please letus know. Thanks, -Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: errors compiling 2.6.20 for mpc866ads
On Fri, 2 Mar 2007 16:25:14 + Kenneth Fairweather <[EMAIL PROTECTED]> wrote: > Compiling a vanilla 2.6.20 kernel and applying Vitaly Bordug's 7 patches > (21st > Jan'07) for mpc866_ads_defconfig gives compiler errors: > > LD arch/powerpc/platforms/8xx/built-in.o > LD arch/powerpc/platforms/built-in.o > CC drivers/net/fs_enet/fs_enet-main.o > linux-2.6.20/drivers/net/fs_enet/fs_enet-main.c: In function `setup_immap': > inux-2.6.20/drivers/net/fs_enet/fs_enet-main.c:1139: error: `IMAP_ADDR' > undeclared (first use in this function) > Please update to current Linus' git and retry. All patches should be in there, let me know if not and/or something not working. > Are these patches for 2.6.20 kernel, and/or are there other patches required? > should I still be using ppc branch? > > Also, tried to grab Vitaly's git tree, but it is failing on http (I'm behind > a > firewall). Is this a known problem? > > cg-clone http://source.mvista.com/git/linux-2.6-vitb.git > defaulting to local storage area > Fetching head... > cg-fetch: unable to get the HEAD branch > Heh, sort of - I've synced my tree with mainline a while ago which reminds me to have a look at it... -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: SPI controller hangs in 2.6 and not in 2.4 (on MPC875)
On Sun, 25 Feb 2007 20:51:12 +0100 DI BACCO ANTONIO - technolabs wrote: > Hi Melinda, > > the problem in my case was caused by the following instructions to > allocate the buffers for SPI controller tx and rx: > > rxbuffer = (u8*)m8xx_cpm_hostalloc(SPI_MAX_BUFFER_SIZE); > txbuffer = (u8*)m8xx_cpm_hostalloc(SPI_MAX_BUFFER_SIZE); > // Set the bd's rx and tx buffer address pointers > rbdf->cbd_bufaddr = virt_to_bus((void > *)rxbuffer); tbdf->cbd_bufaddr = virt_to_bus((void *)txbuffer); > > I don't know why (I'm asking an opinion to Vitaly Bordug), I replaced > the allocation of rx and tx buffers with: > > ...->cbd_bufaddr = __pa(__get_free_page(GFP_KERNEL | GFP_DMA)) > Well this is just evil... even if it works :) > but it will better to use dma_alloc_coherent. > In my case the use of m8xx_cpm_hostalloc led to an immediate kernel > hang after giving the start command to the spi controller. > Heh, this case you'lll have to use dpram for the buffers I guess iiuc. dma_* stuff might work too but I'm not sure. Moreover, it didn't work for me in case of powerpc, where m8xx_cpm_hostalloc made as a placeholder for dma_alloc_coherent... ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: enabling two eths
On Tue, 20 Feb 2007 15:31:54 + Alex Zeffertt <[EMAIL PROTECTED]> wrote: > > Manjunath AM wrote: > > > > Hi, > > > > We are using MPC8272 based target board, we use montavista Linux version > > 2.6.10 kernel image (with NFS enabled) to our target board, > > > > Our board has 2 FCCs (eth0 and eth1). bot the eth's works perfectly > > when we use them independently, but when we are trying to enable second > > one after the kernel is up using linux command "ifconfig eth1 > > 192.168.33.64 up"(IP address)nothing is working. > > Please suggest how to enable second eth (either 0 or 1) once the kernel > > is up with NFS file system > > > Have you made sure that eth0 and eth1 are on *different* IP subnets? > If they are on the same subnet, or intersecting subnets, your routing > will get confused. > It depends :) I used to test functionality such a way to have two enets in same subnet, then ifdown one of them. At least with mvista RFS, one enet handles NFS, other is up but all the packets are routed to it via the first one. And when the first one got ifdown, routing switches to the remaining enet... -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: enabling two eths
On Tue, 20 Feb 2007 18:51:41 +0530 Manjunath AM <[EMAIL PROTECTED]> wrote: > Hi, > > We are using MPC8272 based target board, we use montavista Linux version > 2.6.10 kernel image (with NFS enabled) to our target board, > > Our board has 2 FCCs (eth0 and eth1). bot the eth's works perfectly when > we use them independently, but when we are trying to enable second one > after the kernel is up using linux command "ifconfig eth1 192.168.33.64 > up"(IP address)nothing is working. > Please suggest how to enable second eth (either 0 or 1) once the kernel is > up with NFS file system > I could recall no problems with mpc8272 except stuck PHY which were cured by board power cycle. I brought up second Ethernet interface a number of times without any problem; even had them replace each other serving as NFS root gate. So I would suggest supplying more information on "nothing is working", prolly kernel output and details about MVL product you are using. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: What is the difference between Montavista Kernel Source, and Kernel.Org Source
On Sun, 18 Feb 2007 11:20:27 +0100 Lorenz Kolb <[EMAIL PROTECTED]> wrote: > > >> I'm Going to use linux on ML403. > >> > >> I want to know, what is the difference between the linux kernel source, > >> that we download from source.mvista.com ( using git ) and the original > >> kernel source code that we download from kernel.org? > >> Being brief, some Mvista patches were not merged due to various reasons (such as say Xilinx stuff for a while) and anyone interested can still use that work. So for instance people asking here and in other ML's can be just referred to those git trees and obtain a full understanding what were done to get things work. > > > > The multiple git trees hosted at source.mvista.com/git are development > > trees similar to the trees hosted at www.kernel.org/git. Contact the > > individual developers for details on each tree. > > > > Dale Farnsworth > > > > > Oh, and I thought that development does mean something like progress. > If I'd "develop" something "new" with last change 8 months ago, I guess > my boss would not pay for that "development". > sorry, but that is not quite right. Trees there are development stuff for 4.x MVL product (at least ppc-related), and now active development is heading for next release. I don't think you'll find these up-to-date sources in source.mvista.com, bit not because of internal reasons - almost all the efforts were brought up to the community and merged to the stock kernel tree. > So what is the difference between kernel.org and montavista's tree for > ML403. > > kernel.org is quite a bit ahead. > > Personally I'd recommend Denk's 2.6.19 tree (that's a 2.6.19 from > kernel.org with some ppc specific patches, afaik) and patching the EDK > 8.2 into it. That's quite a lot of work (I am just doing that at the > moment) but that's the only way to get an up-to-date system. > Currently my partner and I are working on building a minimalistic sound > driver and in some future release a ALSA compliant sound driver and a > new controller (with at least DMA support) as this is can still not be > found in MontaVista. > Xilinx stuff is a really interesting approach. Sorry, but I guess "patching the EDK 8.2 into it" is not the thing maintainers are expecting to appear upstream. So, referred mvista code can be used as a reference, but a living solution requires careful consideration. Do some investigations, share the thoughts and you'll not be left alone. As a side note, most of the active work is in the mainstream kernel, MV, Denx and many others actively participating in it. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Moving from arch/ppc to arch/powerpc with an MPC8248 (part 1)
On Thu, 15 Feb 2007 13:43:43 +0100
Heiko Schocher wrote:
> Hello Laurent, Vitaly
>
> >> Are you using up-to-date powerpc.git? I get rid of hardcoded
> CPM_MAP_ADDR
> >> completely (or it should be such, heh). please make sure you have
> >> my recent
>
> I found two more in arch/powerpc/sysdev/cpm2_common.c (in actual
> powerpc.git Tree):
>
> diff --git a/arch/powerpc/sysdev/cpm2_common.c
> b/arch/powerpc/sysdev/cpm2_common.c index ec26599..2159895 100644
> --- a/arch/powerpc/sysdev/cpm2_common.c
> +++ b/arch/powerpc/sysdev/cpm2_common.c
> @@ -60,7 +60,7 @@ intctl_cpm2_t *cpm2_intctl;
> void
> cpm2_reset(void)
> {
> - cpm2_immr = (cpm2_map_t *)ioremap(CPM_MAP_ADDR,
> CPM_MAP_SIZE);
> + cpm2_immr = (cpm2_map_t *) ioremap(get_immrbase(),
> CPM_MAP_SIZE); cpm2_intctl = cpm2_map(im_intctl);
>
> /* Reclaim the DP memory for our use.
> @@ -234,7 +234,7 @@ static void cpm2_dpinit(void)
> {
> spin_lock_init(&cpm_dpmem_lock);
>
> - im_dprambase = ioremap(CPM_MAP_ADDR, CPM_DATAONLY_BASE +
> CPM_DATAONLY_SIZE);
> + im_dprambase = (u8 *) ioremap(get_immrbase(),
> CPM_DATAONLY_BASE + CPM_DATAONLY_SIZE);
> /* initialize the info header */
> rh_init(&cpm_dpmem_info, 1,
>
>
Those exist in my local tree - missed the resubmit I guess. Will fix.
> >> commits in.
> >
> > I'm using up-to-date linux-2.6.git, which is probably way old
> > compared to posuch werpc.git :-) What's the powerpc.git URL ? Do
> > you plan to push your changes upstream for 2.6.21 ?
>
> I think you find the powerpc.git at
> http://www.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git/
>
> Am I right?
>
yep. :)
> I also "playing" at the moment to port a running mpc8272 base port
> under arch/ppc to arch/powerpc, but I cant say, when I am finishing
> it ...
>
it is completed and works for me - I even checked in the defconfig.
> When I compile the Tree I got a compilererror in
> drivers/serial/cpm_uart/cpm_uart_cpm2.c, because I have a SMC as a
> console. I fixed it with the following patch:
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> index 787a8f1..5a36ad2 100644
> --- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> @@ -285,7 +285,7 @@ void cpm_uart_freebuf(struct uart_cpm_port *pinfo)
> int __init cpm_uart_init_portdesc(void)
> {
> #if defined(CONFIG_SERIAL_CPM_SMC1) ||
> defined(CONFIG_SERIAL_CPM_SMC2)
> - u32 addr;
> + u16* addr;
> #endif
> pr_debug("CPM uart[-]:init portdesc\n");
>
Well, those init_portdesc should not be toggled in normal case - all should
come through platform devices (done by device tree traversal for now since we
need to keep the compatibility with ppc stuff)
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Moving from arch/ppc to arch/powerpc with an MPC8248 (part 1)
On Wed, 14 Feb 2007 14:43:18 +0100 Laurent Pinchart <[EMAIL PROTECTED]> wrote: > Hi, > > > > I'm trying to take the big jump and move my (mostly) stable board support > > > from arch/ppc to arch/powerpc. I'm still at a very early stage, but here > > > are already a few questions. > > > > > > arch/ppc defines some 8260 generic handlers in syslib/mpc8260_setup.c for > > > operations such as halt, reset, show_cpuinfo, ... The MPC82xx ADS in > > > arch/powerpc/platforms/82xx redefines those handles as board-specific > > > functions. Should they be made generic to all 82xx boards, or should I > > > copy them to my board-specific file ? If the code should be shared by all > > > 82xx boards, I'll probably end up copying most of the > > > arch/ppc/syslib/mpc8260_setup.c code to > > > arch/powerpc/platforms/82xx/mpc82xx.c. > > > > I'd just copy stuff to the BSP -- let's consider the common/uncommon stuff > > later when we'll have to add something else. > > > > It's hard to envision what level of code should be common and what should > > be board-specific as of now. Otherwise, we'll have to painfully revisit > > issue later. > > It seems there are still lots of inconsistencies regarding MPC82xx support in > arch/powerpc. For instance, get_immrbase() is used to get the IMMR address > from the OF device tree, but cpm2_map() uses the CPM_MAP_ADDR address which > is platform-dependant, and hardcoded to 0xf000 in > platforms/82xx/pq2ads.h. > Are you using up-to-date powerpc.git? I get rid of hardcoded CPM_MAP_ADDR completely (or it should be such, heh). please make sure you have my recent commits in. > Is someone working on fixing MPC82xx support for arch/powerpc ? I don't have > much time now to hack all the platform-specific code and cleanup > inconsistencies, so if someone is working on it I'll wait for patches. If > not, I'll have to work on that later, as time permits. As I'm new to the > arch/powerpc code, I'd appreciate if someone with a good understanding of > what should be done could give me a few pointers (such as 'fix the CPM2 > mapping code this way', just general guidelines). Otherwise I'll have to ask > questions at every line of code. > Well 827x works perfectly for me, and there are no direct immr dereferences anymore in arch/powerpc... There still might be gotchas because that merge was sort of one-man-show, but let me know and we'll figure out something. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Moving from arch/ppc to arch/powerpc with an MPC8248 (part 1)
On Wed, 14 Feb 2007 13:08:17 +0100 Laurent Pinchart <[EMAIL PROTECTED]> wrote: > Hi everybody, > > I'm trying to take the big jump and move my (mostly) stable board support > from > arch/ppc to arch/powerpc. I'm still at a very early stage, but here are > already a few questions. > > arch/ppc defines some 8260 generic handlers in syslib/mpc8260_setup.c for > operations such as halt, reset, show_cpuinfo, ... The MPC82xx ADS in > arch/powerpc/platforms/82xx redefines those handles as board-specific > functions. Should they be made generic to all 82xx boards, or should I copy > them to my board-specific file ? If the code should be shared by all 82xx > boards, I'll probably end up copying most of the > arch/ppc/syslib/mpc8260_setup.c code to > arch/powerpc/platforms/82xx/mpc82xx.c. > I'd just copy stuff to the BSP -- let's consider the common/uncommon stuff later when we'll have to add something else. It's hard to envision what level of code should be common and what should be board-specific as of now. Otherwise, we'll have to painfully revisit issue later. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] CPM_UART: Fixed SMC handling for CPM2 processors
On Tue, 13 Feb 2007 09:09:47 +0100
Heiko Schocher wrote:
> Hello Vitaly,
>
> Vitaly Bordug wrote:
> > > I tried the Patch from Kalle Pokki
> > > http://ozlabs.org/pipermail/linuxppc-embedded/2006-November/025108.html
> > >
> > > but my SMC didnt work, without this patch, it works fine. I think
> > > that the pram_base must be set the follwing way:
> > >
> > Thanks for the patch, but I guess it requires a bit of
> > investigation first since we cannot just drop ioremapped offset and
> > get back to raw one that has been returned by platform_get_
>
> Ok, "Linux" writes/reads with the ioremapped Address in the Dualported
> RAM we get with platform_get_...("pram"), thats Okay, but the CPM
> needs the "real" Dualported RAM Address from this Area at offset
> SMCx_BASE, which we get with platform_get_...("pram_base"), so it can
> find the SMC Parameter RAM, he(CPM) didnt know anything about
> ioremapped addresses.
>
> > We require ioremap stuff for powerpc approach, and I think we'd
> > have to figure out why ioremapped address did not satisfy smc (and
> > I'll try on my 8xx).
>
> Hmm... you mean the following?:
>
> r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pram_base");
> if (r) {
> + pram_base = (u32)ioremap(r->start, r->end - r->start + 1);
> out_be16((u16 *)pram_base, base & 0x);
> + iounmap(pram_base);
> }
>
> But thats not, what I correct with my patch, the error was, that
> we wrote the ioremapped address pram in pram_base and not the real
> address ... and with this ioremapped address, the CPM cannot do
> anything (I think).
>
That is what I am about - I think there is a bit of confusion around the upper.
I mean, we'll have to investigate
what's happening in arch/powerpc since the SMC CPM works fine for me in
aprch/powerpc with the ioremap stuff. Maybe it has to do something with
io_block_map() and the ioremap - I'm not sure. Well it worths looking at it, if
it will be unclear we can end up with #ifdef that areas to keep ppc/ happy at
least.
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] CPM_UART: Fixed SMC handling for CPM2 processors
On Mon, 12 Feb 2007 11:33:42 +0100
Heiko Schocher <[EMAIL PROTECTED]> wrote:
> Hello Vitaly,
>
> I tried the Patch from Kalle Pokki
> http://ozlabs.org/pipermail/linuxppc-embedded/2006-November/025108.html
>
> but my SMC didnt work, without this patch, it works fine. I think that
> the pram_base must be set the follwing way:
>
Thanks for the patch, but I guess it requires a bit of investigation first
since
we cannot just drop ioremapped offset and get back to raw one that has been
returned by
platform_get_
We require ioremap stuff for powerpc approach, and I think we'd have to figure
out why
ioremapped address did not satisfy smc (and I'll try on my 8xx).
Guessing we are speaking about arch/ppc/ domain upper...
> diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
> b/drivers/serial/cpm_uart/cpm_uart_core.c
> index ea85f6a..76ab6e5 100644
> --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
> @@ -1025,6 +1025,7 @@ int cpm_uart_drv_get_platform_data(struct
> platform_device *pdev, int is_con)
> struct uart_cpm_port *pinfo;
> int line;
> u32 mem, pram, pram_base;
> + int base;
>
> idx = pdata->fs_no = fs_uart_get_id(pdata);
>
> @@ -1050,11 +1051,12 @@ int cpm_uart_drv_get_platform_data(struct
> platform_device *pdev, int is_con)
> if (!(r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pram")))
> return -EINVAL;
> pram = (u32)ioremap(r->start, r->end - r->start + 1);
> -
> + base = r->start;
> +
> r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pram_base");
> if (r) {
> pram_base = r->start;
> - out_be16((u16 *)pram_base, pram & 0x);
> + out_be16((u16 *)pram_base, base & 0x);
> }
>
> if(idx > fsid_smc2_uart) {
>
>
> with this patch it works fine :-)
>
> Best regards
> Heiko
>
> --
> DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
> Office: Kirchenstr. 5, D-82194 Groebenzell,Germany
>
--
Sincerely,
Vitaly
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Problem with linking customer phy with fs_enet drivers
On Tue, 06 Feb 2007 21:11:15 -0800 Jack Ger wrote: > Hi Vitaly, > > Thanks for your response. > > I dont know how to create the patch which I changed. I disabled > all the board_init in mpc885ads_setup.c, and disable the scc and fcc > driver init function in the fs_enet-main.c init. > So, you are using board specific file for mpc885ads? what is the platform info passed into fs_enet then (that is filled in there)? Note that you have to specify bus_id right way. Also, looks like you do not have fsl-cpm-fec-mdio device registered on platform bus. fs_enet supports fec and bitbang mii types so far, and if you have your LXT970 connected another way, you'll have to implement respective mii driver (like in drivers/net/fs_enet/mii-*) -- Sincerely, Vitaly signature.asc Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Conditions for mydriver_probe to be called
On Tue, 6 Feb 2007 16:42:30 +0100 "DI BACCO ANTONIO - technolabs" <[EMAIL PROTECTED]> wrote: > I'm realizing a controller driver for the mpc8xx spi master device. My > driver has a mpc8xx_spi_probe method that I expected to be called. I'm > sure that platform_device_register is called for my spi platform_device > but nothing happens, mpc8xx_spi_probe is not called. I'd dump ppc_sys.c in the place where it puts devices into the bus, and peek into driver_register. Note that for 8xx, spi normally resides on scc, so you'll have to use ...set_func and ...device_enable() stuff (see in ppc_sys.c for exact prototypes) to have foo-bar-scc:spi or alike registered on bus. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Problem with linking customer phy with fs_enet drivers
On Sun, 04 Feb 2007 15:19:41 -0800 "Jack Ger" <[EMAIL PROTECTED]> wrote: > Hi all, > > I am trying to run the customer LXT970 phy with MPC870, porting from > MPC885. I have the lxt phy driver installed and fs_enet driver installed > during > the kernel bootup. But during the the fs_enet_open, when trying to link > the specific phy, it fails to find the bus_id. Since we already know that > the FEC > is working in 2.4 kernel runing the 8xx_io fec, it must be something I have > done > wrong with the fs_enet, 2 questions: > It would be easier not to repeat myself to figure out the reason, and have a look at the patch. Mind posting it here? If that is a problem, send it to me and I'll try to get a few hins out... > 1) I understood that probably I didn't activate the bus, since I am porting > it > from MPC885fads_setup.c, there is something I missed. Currently I am using > montavista 4.0.1 which runing on kernel 2.6.10.; I noticed that the > mdiobus_register > never get called. > > 2) what is the right way to do the mdiobus_register to register the phy bus? > > TIA for your help. > > A Jones > > _ > Laugh, share and connect with Windows Live Messenger > http://clk.atdmt.com/MSN/go/msnnkwme002001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: SMC as UART problem on mpc8xx
On 02 Feb 2007 11:51:01 +0100 (CET)
Ladislav Klenovic <[EMAIL PROTECTED]> wrote:
> > On 01 Feb 2007 17:10:31 +0100 (CET)
> > a b wrote:
> >
> > > Hi,
> > > I have mpc8xx where I would like the following configuration:
> > > - SCC1 as system console (works fine)
> > > - SMC1-2 as UART (doesn\\\'t work)
> > >
> > > I use linux 2.6.16.20 with backward patch from linux-2.6.19.2 for SMCs.
> > > My only problem is
> > > that even I can see cpm_uart registered for IRQ 20 (for SMC1) I never get
> > > interrupt even
> > > I do e.g. \\\"echo 123 > /dev/ttyCPM\\\".
> > >
> > > here is a short extract from /proc/interrupts:
> > > 20: 0 CPM Edge cpm_uart <--SMC1
> > > 21: 7546 CPM Edge SPI
> > > 46: 20 CPM Edge cpm_uart <-- SCC1 (console)
> > >
> > > here is a short extract from /proc/tty/driver/ttyCPM:
> > > serinfo:1.0 driver revision:
> > > 0: uart:CPM UART mmio:0xFFF00A80 irq:20 tx:14 rx:0 RTS|CTS|DTR|DSR|CD
> > > 1: uart:CPM UART mmio:0xFFF00A90 irq:19 tx:0 rx:0 CTS|DSR|CD
> > > 2: uart:CPM UART mmio:0xFFF00A00 irq:46 tx:3038 rx:46 RTS|CTS|DTR|DSR|CD
> > >
> > > Can anybody help me to get SMCs working?
> > >
> > >
> > Check IO ports? IIRC, in 8xx some SoC devices could not work simultaneously
> > because they
> > share some GPIO pins. In any case, if something does not function with CPM
> > UART, IOports stuff is the first thing to check.
> >
> > --
> > Sincerely,
> > Vitaly
> >
>
> Hi,
> thnx for hint, you were right, problem was in I/O port configuration.
> I am a bit wondered why is B port for mpc8xx not configured in 2.16.19.2. Or
> is it
> configured somewhere else? I especially miss this part of code in
> cpm_uart_cpm1.c:
>
> void smc1_lineif(struct uart_cpm_port *pinfo){
> ...
> #elif defined (CONFIG_MPC86XADS)
>if (!pinfo->is_portb) {
> cp->cp_pbpar |= iobits;
> cp->cp_pbdir &= ~iobits;
> cp->cp_pbodr &= ~iobits;
> } else {
> ((immap_t *)IMAP_ADDR)->im_ioport.iop_papar |= iobits;
> ((immap_t *)IMAP_ADDR)->im_ioport.iop_padir &= ~iobits;
> ((immap_t *)IMAP_ADDR)->im_ioport.iop_paodr &= ~iobits;
> }
> #endif
> ...
> }
>
Oh well, the preferred way is not to bloat drivers/ space with code snippets
that are clearly
board specific. There are hooks to set up IO space in BSP code already, it just
has to have proper pinfo
set up - mpc86xads and mpc885ads work that way. Yet I haven't checked ppc/
stuff for a while, being concentrated on arch/powerpc...
--
Sincerely,
Vitaly
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: SMC as UART problem on mpc8xx
On 01 Feb 2007 17:10:31 +0100 (CET) a b <[EMAIL PROTECTED]> wrote: > Hi, > I have mpc8xx where I would like the following configuration: > - SCC1 as system console (works fine) > - SMC1-2 as UART (doesn\'t work) > > I use linux 2.6.16.20 with backward patch from linux-2.6.19.2 for SMCs. My > only problem is > that even I can see cpm_uart registered for IRQ 20 (for SMC1) I never get > interrupt even > I do e.g. \"echo 123 > /dev/ttyCPM\". > > here is a short extract from /proc/interrupts: > 20: 0 CPM Edge cpm_uart <--SMC1 > 21: 7546 CPM Edge SPI > 46: 20 CPM Edge cpm_uart <-- SCC1 (console) > > here is a short extract from /proc/tty/driver/ttyCPM: > serinfo:1.0 driver revision: > 0: uart:CPM UART mmio:0xFFF00A80 irq:20 tx:14 rx:0 RTS|CTS|DTR|DSR|CD > 1: uart:CPM UART mmio:0xFFF00A90 irq:19 tx:0 rx:0 CTS|DSR|CD > 2: uart:CPM UART mmio:0xFFF00A00 irq:46 tx:3038 rx:46 RTS|CTS|DTR|DSR|CD > > Can anybody help me to get SMCs working? > > Check IO ports? IIRC, in 8xx some SoC devices could not work simultaneously because they share some GPIO pins. In any case, if something does not function with CPM UART, IOports stuff is the first thing to check. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: cpm_uart: WARNING: no UART devices found
On Tue, 30 Jan 2007 09:30:49 +0100 DI BACCO ANTONIO - technolabs wrote: > My board has an MPC880 and it is named TL880 with a linux 2.6.19, I > copied kernel configurations from the very similar board mpc885ads. > I filled in platform data in file TL880_setup.c but I see that > function TL880_fixup_uart_pdata is never called and, as a > consequence, I see the message cpm_uart: WARNING: no UART devices > found. Also I receive message: IP-Config: No network devices > available. You seem to miss the board ppc_sys_identify_by_name() (or alike) call - so BOARD_CHIP_NAME is not defined for your board in BSP file. There is no other way to properly identify SoC with 8xx... -- Sincerely, Vitaly signature.asc Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: regarding kgdb in ppc
On Tue, 23 Jan 2007 11:30:57 +0530 sudheer wrote: > Vijay Sampath wrote: > > Sorry no idea. The configuration and options for kgdb are different > > in my architecture. In make menuconfig, under "Kernel Hacking', I > > enable kgdb and choose its serial port (ttyS0 or ttyS1). After this > > if I just pass a string with "kgdb" in it in the commandline, it > > halts early on. Looks like kgdb function is different in your > > architecture. You will have to read the code that implements your > > kgdb setup. Clearly it is not happy with the arguments you are > > passing it, as evident in the output. > > > > BTW I am using Linux kernel version 2.6.16 on a IBM405EP board. kgdb > > breakpoint is setup in setup_arch() in arch/ppc/kernel/setup.c. > > Note I also enabled CONFIG_WANT_EARLY_SERIAL in the processor > > configuration. Not sure if this is important. > > > In my setup i have one serial port on the target(MPC8540) and one on > host(x86). The document(kgdb_docu_full-2.4.pdf) by default considers > having two serial ports(two on target and two on host). > To be correct, usually one serial is for serial console, the other-for kgdb. Yet you can either disable serial console, or have its output into kgdb. host requires only one serial to be tied on ppc_85xx-gdb. > Can anyone plz guide me how to proceed when i have only one serial > port . ? > having one serial is not a comfy case for serial kgdb. > I want to know the initilization steps for estrablishing the serial > communication between kgdb(in target) and gdb on host. I tried one or > two ways but couldnot succeed. I'd consider kgdboe - it works pretty well with 8540 gianfar (or at least used to work for me so tinkering might be trivial). > > Thanks > Sudheer > > Vijay > > > > On 12/30/06, sudheer <[EMAIL PROTECTED]> wrote: > >> Vijay, Thanks for the reply. > >> But before trying these options i want to clear one more issue. > >> While booting the kgdb kernel the kernel claims "kgdb > >> initialisation failure." I have observed it very lately. > >> > >> Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb > >> Linux version 2.6.15.5 ([EMAIL PROTECTED]) (gcc version 3.4.4) #2 Fri > >> Dec 29 17:58:40 IST > >> 2006 > >> KGDB cannot initialize I/O yet. > >> Invalid syntax for option kgdb8250= > >> Malformed early option 'kgdb8250' > >> Built 1 zonelists > >> Kernel command line: console=ttyS0,115200 root=/dev/ram rw > >> kgdbwait kgdb8250=0,115200 > >> OpenPIC Version 1.2 (1 CPUs and 60 IRQ sources) at fcfbb000 > >> PID hash table entries: 2048 (order: 11, 32768 bytes) > >> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) > >> > >> > >> > >> > >> I have changed the kgdb8250 arg to 1,0, but the result is same. > >> And .. > >> I have checked the serial cable NULL Mode connecting x86 systems > >> serially- with Cat and echo and this is fine. > >> When i try with Unpatched kernel on target and host(x86) - cat < > >> /dev/ttyS0 doesnt wait and returns to prompt. > >> I tried with 2.6.13 and 2.6.15.5 with resepective kgdb patches, > >> but the result is same (kgdb Initialization failure). I am not > >> sure where am doing the mistake. > >> Please guide me in right way and also please let me know if any > >> more details are required. > >> Happy New Year in Advance. > >> > >> Thanks > >> Sudheer > >> > >> > >> > >> > > > >> > >> > > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded signature.asc Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC83xx: ns16550.c - 'SERIAL_PORT_DFNS' undeclared?
On Fri, 19 Jan 2007 12:14:04 -0800 Russell McGuire wrote: > Ben, > > That could be the problem > > I am building using ARCH=ppc > > What is the difference between the two? Newer targets appear within arch/powerpc... Concerning your question, you seem to add new board hence you'll have to do those SERIAL_PORT_DFNS in board-specific header file - grep for them inside arch/ppc for reference (if that code is still there of course). OTOH, if you are able to replace/update your firmware, I'd follow powerpc way. Difference is FAQ I guess, please look around this list. > > -Original Message- And, uhm, top quoting is not good. I know telling that fact to Lookout DIstress is a challenge but anyway :) -- Thanks, Vitaly > From: Ben Warren [mailto:[EMAIL PROTECTED] > Sent: Friday, January 19, 2007 11:58 AM > To: Russell McGuire > Cc: linuxppc-embedded@ozlabs.org > Subject: Re: MPC83xx: ns16550.c - 'SERIAL_PORT_DFNS' undeclared? > > > Russell, > > On Fri, 2007-01-19 at 11:28 -0800, Russell McGuire wrote: > > > > > arch/ppc/boot/common/ns16550.c error: 'SERIAL_PORT_DFNS' undeclared > > here .. > > > > I don't think you should be building any code there... Are you using > ARCH=powerpc (you should be) > > regards, > Ben > > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded signature.asc Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Using fixed_phy with gianfar
On Wed, 10 Jan 2007 06:22:40 -0800 (PST) Ben Warren wrote: > Thanks Vitaly! > > --- Vitaly Bordug <[EMAIL PROTECTED]> wrote: > > > No, you do not miss - this is an issue. In fact MDIO > > bus was changed for numeric for gianfar-stuff, and > > has been remaining string for fs_enet. I think it > > makes sense to average this up, and will try to do > > that once will get 8349-mitx which is gianfar+ fixed > > user. > > > > The point is that fixed should be updated to numeric > > MDIO address encoding. This has to come through > > netdev, so I'll try to get it fixed by the next > > merge window. > > > > -- > > Sincerely, Vitaly > > > > Ideally (for me anyway), we'd be able to pass some > fixed phy information via the device tree, for example > speed and duplexity. This way a board could, for > example, connect to one switch via RvMII @100FD and > another via GMII @1000FD. Having parameters as > numeric limits this capability, but presumably a > simple encoding scheme could be make it work. > > I'm sure you've already thought of this, though... Yes, I was thinking about something like 0:1001 or 0:101 where 1 at the end respects duplexity. Putting it into devtree is good but we'll need to unify the interface first. -- Sincerely, Vitaly signature.asc Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Using fixed_phy with gianfar
On Tue, 09 Jan 2007 18:23:58 -0500 Ben Warren wrote: > Hello, > > My custom board has a couple of Ethernet switches attached via RvMII > to the 'Gianfar' controllers of an MPC8349 CPU. We're using SPI > instead of MDIO for control of the switches, and it looked like the > 'fixed.c' PHY driver was the right thing to use. BTW, I'm using a > 2.6.19 kernel. > > When I 'ifconfig up' one of the interfaces, the Gianfar driver tries > to find a device on the MDIO bus of the variety bus_id:phy_id, where > both bus_id and phy_id are numeric (defined in fsl_devices.h). The > Fixed PHY driver creates devices on the MDIO bus with a bus_id that > is a string, for example "[EMAIL PROTECTED]:1". Obviously, these will > never match up. The very crude hack I made to get things working was > to modify the Gianfar driver to match the "fixed" string. > > I'm sure I'm missing something, and am wondering what the correct way > to do this is. Should I have board-specific code that creates PHY > devices conforming to the Gianfar expectations instead of calling > 'fixed_mdio_register_device()', or something else? No, you do not miss - this is an issue. In fact MDIO bus was changed for numeric for gianfar-stuff, and has been remaining string for fs_enet. I think it makes sense to average this up, and will try to do that once will get 8349-mitx which is gianfar+ fixed user. The point is that fixed should be updated to numeric MDIO address encoding. This has to come through netdev, so I'll try to get it fixed by the next merge window. -- Sincerely, Vitaly signature.asc Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [FS_ENET] OF-related update for FEC and SCC MAC's
On Mon, 11 Dec 2006 21:00:49 +0300 Vitaly Bordug <[EMAIL PROTECTED]> wrote: > > Updated direct resource pass with ioremap call, make it grant proper IRQ > mapping, stuff incompatible with the new approach were respectively put > under > #ifndef CONFIG_PPC_MERGE. Hrm, Signed-off-by: missed, I'll resend, sorry about that. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] [FS_ENET] OF-related update for FEC and SCC MAC's
Updated direct resource pass with ioremap call, make it grant proper IRQ
mapping, stuff incompatible with the new approach were respectively put under
#ifndef CONFIG_PPC_MERGE.
---
drivers/net/fs_enet/mac-fec.c | 13 +
drivers/net/fs_enet/mac-scc.c |6 --
drivers/net/phy/fixed.c |2 +-
3 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c
index c2c5fd4..474d6d7 100644
--- a/drivers/net/fs_enet/mac-fec.c
+++ b/drivers/net/fs_enet/mac-fec.c
@@ -104,9 +104,9 @@ static int do_pd_setup(struct fs_enet_pr
fep->interrupt = platform_get_irq_byname(pdev,"interrupt");
if (fep->interrupt < 0)
return -EINVAL;
-
+
r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
- fep->fec.fecp =(void*)r->start;
+ fep->fec.fecp = (void *)ioremap(r->start, r->end - r->start + 1);
if(fep->fec.fecp == NULL)
return -EINVAL;
@@ -319,11 +319,14 @@ #endif
* Clear any outstanding interrupt.
*/
FW(fecp, ievent, 0xffc0);
+#ifndef CONFIG_PPC_MERGE
FW(fecp, ivec, (fep->interrupt / 2) << 29);
-
+#else
+ FW(fecp, ivec, (irq_map[fep->interrupt].hwirq / 2) << 29);
+#endif
/*
-* adjust to speed (only for DUET & RMII)
+* adjust to speed (only for DUET & RMII)
*/
#ifdef CONFIG_DUET
if (fpi->use_rmii) {
@@ -418,6 +421,7 @@ static void stop(struct net_device *dev)
static void pre_request_irq(struct net_device *dev, int irq)
{
+#ifndef CONFIG_PPC_MERGE
immap_t *immap = fs_enet_immap;
u32 siel;
@@ -431,6 +435,7 @@ static void pre_request_irq(struct net_d
siel &= ~(0x8000 >> (irq & ~1));
out_be32(&immap->im_siu_conf.sc_siel, siel);
}
+#endif
}
static void post_free_irq(struct net_device *dev, int irq)
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index 95ec587..62057f4 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -121,13 +121,13 @@ static int do_pd_setup(struct fs_enet_pr
return -EINVAL;
r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
- fep->scc.sccp = (void *)r->start;
+ fep->scc.sccp = (void *)ioremap(r->start, r->end - r->start + 1);
if (fep->scc.sccp == NULL)
return -EINVAL;
r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pram");
- fep->scc.ep = (void *)r->start;
+ fep->scc.ep = (void *)ioremap(r->start, r->end - r->start + 1);
if (fep->scc.ep == NULL)
return -EINVAL;
@@ -397,6 +397,7 @@ static void stop(struct net_device *dev)
static void pre_request_irq(struct net_device *dev, int irq)
{
+#ifndef CONFIG_PPC_MERGE
immap_t *immap = fs_enet_immap;
u32 siel;
@@ -410,6 +411,7 @@ static void pre_request_irq(struct net_d
siel &= ~(0x8000 >> (irq & ~1));
out_be32(&immap->im_siu_conf.sc_siel, siel);
}
+#endif
}
static void post_free_irq(struct net_device *dev, int irq)
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index 096d4a1..8613539 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -349,7 +349,7 @@ #ifdef CONFIG_FIXED_MII_100_FDX
fixed_mdio_register_device(0, 100, 1);
#endif
-#ifdef CONFIX_FIXED_MII_10_FDX
+#ifdef CONFIG_FIXED_MII_10_FDX
fixed_mdio_register_device(0, 10, 1);
#endif
return 0;
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Compiling 2.6.19 for powerpc 8xx
On Wed, 6 Dec 2006 15:51:14 - "Fairweather Kenneth-R61777" <[EMAIL PROTECTED]> wrote: > Hi, > > I am trying to compile a 2.6.19 kernel for 8xx on powerpc branch. It > fails on drivers/serial/cpm_uart/cpm_uart_cpm1.c for undefined __res > variable > > It looks like cpm1.c doesn't have the open firmware changes that cpm2.c > has. > > I have looked for a patch for this on the site, and havent found one. I > have applied Vitaly Bordug's 5 patches for 8xx, but they don't appear to > address this issue. > Yes as the fix is driver-related not exact arch/powerpc stuff. Bits will be submitted shortly (as I had to do sort of a rebase after powerpc.git tree reset) and mentioned issue will be addressed there, as well as similar in fs_enet. And yes, cpm2's OF-related things were merged (but still needs a couple of fixes that will follow too). -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Compile Error using SMC1 on a MPC8272 for 2.6.19-rc4
On Mon, 04 Dec 2006 13:09:10 +0100
Heiko Schocher <[EMAIL PROTECTED]> wrote:
> Hello Vitaly,
>
> Am Samstag, den 11.11.2006, 00:15 +0300 schrieb Vitaly Bordug:
> > On Fri, 10 Nov 2006 12:53:14 +0100
> > Heiko Schocher wrote:
> > > I tried to compile the Linux Kernel 2.6.19-rc5 with a MPC8272 CPU and
> > > a console on SMC1, and get the following Compile Error:
> > >
> > > CC drivers/serial/cpm_uart/cpm_uart_cpm2.o
> > > drivers/serial/cpm_uart/cpm_uart_cpm2.c: In function
> > > 'cpm_uart_init_portdesc':
> > > drivers/serial/cpm_uart/cpm_uart_cpm2.c:364: warning: assignment makes
> > > integer from pointer without a cast
> > > drivers/serial/cpm_uart/cpm_uart_cpm2.c:368: error: invalid type
> > > argument of 'unary *'
> > > make[3]: *** [drivers/serial/cpm_uart/cpm_uart_cpm2.o] Error 1
> > > make[2]: *** [drivers/serial/cpm_uart] Error 2
> > > make[1]: *** [drivers/serial] Error 2
> > > make: *** [drivers] Error 2
> > >
> > > The following Code solves the problem:
> > >
> > > diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> > > b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> > > index 0599030..bb0a6c1 100644
> > > --- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> > > +++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> > > @@ -349,7 +349,7 @@ void cpm_uart_freebuf(struct uart_cpm_po
> > > int cpm_uart_init_portdesc(void)
> > > {
> > > #if defined(CONFIG_SERIAL_CPM_SMC1) ||
> > > defined(CONFIG_SERIAL_CPM_SMC2)
> > > - u32 addr;
> > > + u32 *addr;
> > > #endif
> > > pr_debug("CPM uart[-]:init portdesc\n");
> > >
> > Yes, but that is not the only issue. I am working on that.
>
> Yes, i think so too, because I tried the 2.6.19 Kernel on a board with
> MPC8272, SMC1-2 and SMCC1-4 used as serial port, SMC2 as Console, and
> it dont work ... with a 2.6.14er Kernel it worked ...
>
> I had to change the following Code:
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> index bb0a6c1..4ee1bfc 100644
> @@ -349,7 +351,7 @@ void cpm_uart_freebuf(struct uart_cpm_po
> int cpm_uart_init_portdesc(void)
> {
> #if defined(CONFIG_SERIAL_CPM_SMC1) || defined(CONFIG_SERIAL_CPM_SMC2)
> - u32 *addr;
> + u16 *addr;
> #endif
> pr_debug("CPM uart[-]:init portdesc\n");
>
>
>
> With this change, Linux comes up, with SMC1-2 and SCC1-4 as serial port,
> and a console on SMC2 :-)
>
> If I use the Plattform Bus:
> I have also to apply the patch from:
> http://ozlabs.org/pipermail/linuxppc-embedded/2006-November/025101.html
>
> to bring it up working.
>
Thanks very much for these bits. I'm in process of finalizing PQ-related
powerpc merge and fix-ups for what is
currently in-tree so arch/ppc been left a bit aside.
I'll send your patches together with my bunch and get them merged.
--
Sincerely,
Vitaly
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: fs_enet driver "generating" bad interrupts on 2.6.19
On Fri, 1 Dec 2006 14:18:26 +0100 Laurent Pinchart wrote: > > The problem wasn't visible with the 2.6.18 kernel. The number of bad > interrupts didn't increase with outbound FCC traffic. > > Has anyone noticed the same problem ? > So, not reproduced on 8272ads and 8560ads FCC's with current kernel. They are arch/powerpc though. Bad irq's may be relevant to the fact that ppc/ has some cascaded IRQ's that were not adopted to genirq rework, but that should be expressed in 2.6.18 too -- Sincerely, Vitaly signature.asc Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: fs_enet driver "generating" bad interrupts on 2.6.19
On Fri, 1 Dec 2006 14:18:26 +0100 Laurent Pinchart <[EMAIL PROTECTED]> wrote: > Hi everybody, > > I upgraded to 2.6.19 today, and found a strange issue that seems to be > related > with the fs_enet driver on a MPC8248. > > The number of "bad" interrupts, as reported by /proc/interrupts, seems to > grown with the number of packets received and sent by the FCC ethernet > controllers. > I'll check if it is true on our 82xx board && FCC. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: CPM_UART: tcdrain() is broken
On Tue, 14 Nov 2006 09:28:00 +0100 Laurent Pinchart <[EMAIL PROTECTED]> wrote: > Hi Dan, > > > > There is, however, a problem left. The SCC controllers have a 32- > > > byte FIFO between the buffer descriptors and the wires. > > > cpm_uart_tx_empty() checks if all buffer descriptors have been processed, > > > but doesn't check if the transmit FIFO is actually empty. > > > > There is no way to determine if the hardware FIFO is empty. > > It's buried under the CPM microcode. > > I was hoping the information would be somewhere in the parameter RAM :-( > > > > . I can't figure out how to do so from the datasheet. > > > Does anyone have an idea ? > > > > The original versions of the SCC UART driver used to have a > > timeout based on the maximum depth of this FIFO and baud rate. > > After the last BD was empty, it would further wait this amount of > > time. Lots of these little details seem to have been lost over > > the years of making a "better" driver :-) > > That's a solution, but we might wait longer than necessary then. Vitaly, > what's your opinion ? We should at least set fifosize to a proper value (see > my previous mail). I'll submit a patch after we agree on the need for an > additional delay. > Well, I also bothered Dan with the same question some time ago, getting the same answer :) I think here we aught to have this delay ported, but under Kconfig option, so that those who are happy with current being, do not suffer from additional delays. Patch appreciated :) -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] CPM_UART: Fix non-console initialisation (v2)
On Mon, 13 Nov 2006 20:54:21 +1100 Paul Mackerras <[EMAIL PROTECTED]> wrote: > Vitaly Bordug writes: > > > patch with proper description inlined. > > > > Thanks, > > -Vitaly > > --- > > [POWERPC] CPM_UART: Fixes inconsistency of function definition > > > > From: Kalle Pokki <[EMAIL PROTECTED]> > > > > The below hunk was missed from the recent patch, and now, there are > > somewhat > > inconsistent definitions: > > Well, what I want to know is this: why was the addition of __init > bundled in with what I was told was a bug-fix that was needed for > 2.6.19? Does the addition of __init fix a bug somehow? > > That wasn't for .19 - I assumed your comment as -ENO_PROPER_DESCRIPTION. The issue is small but shouldn't be put aside. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] CPM_UART: Fix non-console initialisation (v2)
Paul,
patch with proper description inlined.
Thanks,
-Vitaly
---
[POWERPC] CPM_UART: Fixes inconsistency of function definition
From: Kalle Pokki <[EMAIL PROTECTED]>
The below hunk was missed from the recent patch, and now, there are somewhat
inconsistent definitions:
in cpm_uart.h:
int __init cpm_uart_init_portdesc(void);
in cpm_uart_cpm1.c:
int __init cpm_uart_init_portdesc(void)
{
}
in cpm_uart_cpm2.c:
int cpm_uart_init_portdesc(void)
{
}
Signed-off-by: Kalle Pokki <[EMAIL PROTECTED]>
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
---
drivers/serial/cpm_uart/cpm_uart_cpm2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
index b691d3e..787a8f1 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
@@ -282,7 +282,7 @@ void cpm_uart_freebuf(struct uart_cpm_po
}
/* Setup any dynamic params in the uart desc */
-int cpm_uart_init_portdesc(void)
+int __init cpm_uart_init_portdesc(void)
{
#if defined(CONFIG_SERIAL_CPM_SMC1) || defined(CONFIG_SERIAL_CPM_SMC2)
u32 addr;
signature.asc
Description: PGP signature
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Compile Error using SMC1 on a MPC8272 for 2.6.19-rc4
On Fri, 10 Nov 2006 12:53:14 +0100
Heiko Schocher wrote:
> Hello,
>
> I tried to compile the Linux Kernel 2.6.19-rc5 with a MPC8272 CPU and
> a console on SMC1, and get the following Compile Error:
>
> CC drivers/serial/cpm_uart/cpm_uart_cpm2.o
> drivers/serial/cpm_uart/cpm_uart_cpm2.c: In function
> 'cpm_uart_init_portdesc':
> drivers/serial/cpm_uart/cpm_uart_cpm2.c:364: warning: assignment makes
> integer from pointer without a cast
> drivers/serial/cpm_uart/cpm_uart_cpm2.c:368: error: invalid type
> argument of 'unary *'
> make[3]: *** [drivers/serial/cpm_uart/cpm_uart_cpm2.o] Error 1
> make[2]: *** [drivers/serial/cpm_uart] Error 2
> make[1]: *** [drivers/serial] Error 2
> make: *** [drivers] Error 2
>
> The following Code solves the problem:
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> index 0599030..bb0a6c1 100644
> --- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> @@ -349,7 +349,7 @@ void cpm_uart_freebuf(struct uart_cpm_po
> int cpm_uart_init_portdesc(void)
> {
> #if defined(CONFIG_SERIAL_CPM_SMC1) ||
> defined(CONFIG_SERIAL_CPM_SMC2)
> - u32 addr;
> + u32 *addr;
> #endif
> pr_debug("CPM uart[-]:init portdesc\n");
>
Yes, but that is not the only issue. I am working on that.
Thanks,
-Vitaly
signature.asc
Description: PGP signature
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Freescale combined ethernet driver
On Wed, 08 Nov 2006 17:12:03 +1300 Robin Gilks <[EMAIL PROTECTED]> wrote: > OK - I give up - whats the name of the device? > > I've tried eth0, fsl-cpm-fec0 (and other combinations) with a > commandline of the form: > >ip=172.25.206.113:172.25.140.15::255.255.0.0:unset:fsl-cpm-fec0:off \ > panic=1 console=ttyCPM0 > I am not following why you're touching netdev name here... Your problem clearly points to the unregistered platform device (which should be added to the identification code that maps system to the platform device list). In short, bsp code does name matching of the supported boards, and ties it to the enum of platform devices aught to be registered for this board. It registers nothing by default, and since fs_enet fail to found anything suitable on platform bus, not network devices created. Yet it may be not the case of course - too less information to be sure. Assuming it is not relevant to you anymore, just for archive purposes. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] CPM_UART: Fixed SMC handling for CPM2 processors
On Tue, 7 Nov 2006 15:21:00 +0200 (EET) Kalle Pokki wrote: > On Tue, 7 Nov 2006, Vitaly Bordug wrote: > > > Well, yes, but are you _sure_ pram_base will be the same across all > > the 82xx PQ2, that happen to have smc wired to Ethernet? > > > > If not I am considering storing it in the platform_data is better > > approach. > > Yes, pram_base is always 0x87fc for SMC1 and 0x88fc for SMC2. This is > for all PowerQUICC II families (8260, 8272, and 8280). I'm not sure > how PQ2 Pro and PQ3 and handled, but I suspect they don't share these > definitions. > ok > Anyway, I'm only extending the already existing conventions to the > platform device approach. These same decisions have already been made > in the past and are used in the cpm_uart compat mode. It may be that > Freescale someday releases a microcode patch that relocates the SMC > parameter RAM, but even in this case it would be better to use the > same approach with compat mode and platform device mode to avoid > confusion. > > I could have used the numerical address offsets in the resource > definition, but I wanted to emphasize the fact that the offsets are > already defined by the DPRAM memory allocator (this is a little > hackish, yes) instead of hardware directly requiring these exact > values. > Aha, I recall now. There was nearly exactly the same discussion in the past. The recap was since ppc_platform_devices[] approach is not flexible enough, revisit issue from the arch/powerpc POV. > This snippet is from cpm2.h: > > /* Dual Port RAM addresses. The first 16K is available for > almost >* any CPM use, so we put the BDs there. The first 128 > bytes are >* used for SMC1 and SMC2 parameter RAM, so we start > allocating >* BDs above that. All of this must change when we start >* downloading RAM microcode. >*/ > #define CPM_DATAONLY_BASE ((uint)128) > > My patch puts pram_base exactly here. > > I know, the questionable thing was if there is enough "value" to add yet another platform device for that. Since it improves current ppc being and sort of puts a note for powerpc port, I'm inclined to ACK. Thanks, -Vitaly signature.asc Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] CPM_UART: Fixed SMC handling for CPM2 processors
On Mon, 6 Nov 2006 22:49:49 +0200 (EET) Kalle Pokki <[EMAIL PROTECTED]> wrote: > On Mon, 6 Nov 2006, Vitaly Bordug wrote: > > >> This patch renames these the two existing resources, and introduces a > >> new one, "pram_base", which is a pointer to the parameter RAM. The > >> parameter RAM for SMC1 and SMC2 is put in the first 128 bytes of the > >> DPRAM. This memory was already reserved from the DPRAM memory > >> allocator for this purpose. > >> > > Well just one objection. pram_base should not be a device unless it applies > > to all the stuff of > > SoC family which is not the case. > > > > For this aim, I'd put what you need into the platform_data, or follow the > > same approach 8xx stuff having. > > I'm not sure I follow you now. "pram_base" is not a device by itself, but > it's just another resource in the PQ2 version of the SMC devices in the > platform_data. So the resource is only present when it is needed, and for > other platform devices that don't have this resource, the cpm_uart code > does nothing (as it should not). > Well, yes, but are you _sure_ pram_base will be the same across all the 82xx PQ2, that happen to have smc wired to Ethernet? If not I am considering storing it in the platform_data is better approach. > The only difference to the 8xx version is the new "pram_base" resource, > and it is required with PQ2, right? Prolly, and I actually tried the same when introduced 8xx stuff. It was not permitted because such a thing could not be stuck to one value, and as long as we'll have it compiled into the devices table, others will have to use that offset (yet maybe having the specific dpram required for another purpose). Hope that clarifies my position... -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] CPM_UART: Fixed SMC handling for CPM2 processors
On Mon, 6 Nov 2006 15:29:47 +0200 (EET)
Kalle Pokki wrote:
> SMC handling is broken in two places when using then platform device
> approach with CPM2 devices.
>
> 1. The resources in pq2_devices are not named "regs" and "pram", thus
> they are not found in cpm_uart_drv_get_platform_data().
>
> 2. The code in cpm_uart_drv_get_platform_data() assumes the parameter
> RAM is at "pram". With SMCs of CPM2 devices, "pram" is just a pointer
> to the actual parameter RAM, which the code should reserve somewhere
> in DPRAM.
>
Right, since I had nothing to probe with pq2/smc, that part of code remain
intact since creation.
Nice to see this stuff tuned finally :)
> This patch renames these the two existing resources, and introduces a
> new one, "pram_base", which is a pointer to the parameter RAM. The
> parameter RAM for SMC1 and SMC2 is put in the first 128 bytes of the
> DPRAM. This memory was already reserved from the DPRAM memory
> allocator for this purpose.
>
Well just one objection. pram_base should not be a device unless it applies to
all the stuff of
SoC family which is not the case.
For this aim, I'd put what you need into the platform_data, or follow the same
approach 8xx stuff having.
Thanks, Vitaly
> Signed-off-by: Kalle Pokki <[EMAIL PROTECTED]>
> ---
> arch/ppc/syslib/pq2_devices.c | 24
> ++-- drivers/serial/cpm_uart/cpm_uart_core.c |
> 8 +++- 2 files changed, 25 insertions(+), 7 deletions(-)
>
> diff --git a/arch/ppc/syslib/pq2_devices.c
> b/arch/ppc/syslib/pq2_devices.c index fefbc21..e8f7ba2 100644
> --- a/arch/ppc/syslib/pq2_devices.c
> +++ b/arch/ppc/syslib/pq2_devices.c
> @@ -286,16 +286,22 @@ struct platform_device ppc_sys_platform_
> [MPC82xx_CPM_SMC1] = {
> .name = "fsl-cpm-smc",
> .id = 1,
> - .num_resources = 3,
> + .num_resources = 4,
> .resource = (struct resource[]) {
> {
> - .name = "smc_mem",
> + .name = "regs",
> .start = 0x11A80,
> .end= 0x11A8F,
> .flags = IORESOURCE_MEM,
> },
> {
> - .name = "smc_pram",
> + .name = "pram",
> + .start = PROFF_SMC1,
> + .end= PROFF_SMC1 + 63,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "pram_base",
> .start = 0x87fc,
> .end= 0x87fd,
> .flags = IORESOURCE_MEM,
> @@ -310,16 +316,22 @@ struct platform_device ppc_sys_platform_
> [MPC82xx_CPM_SMC2] = {
> .name = "fsl-cpm-smc",
> .id = 2,
> - .num_resources = 3,
> + .num_resources = 4,
> .resource = (struct resource[]) {
> {
> - .name = "smc_mem",
> + .name = "regs",
> .start = 0x11A90,
> .end= 0x11A9F,
> .flags = IORESOURCE_MEM,
> },
> {
> - .name = "smc_pram",
> + .name = "pram",
> + .start = PROFF_SMC2,
> + .end= PROFF_SMC2 + 63,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "pram_base",
> .start = 0x88fc,
> .end= 0x88fd,
> .flags = IORESOURCE_MEM,
> diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
> b/drivers/serial/cpm_uart/cpm_uart_core.c index 4047530..55419b1
> 100644 --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
> @@ -1024,7 +1024,7 @@ int cpm_uart_drv_get_platform_data(struc
> int idx = pdata->fs_no; /* It is UART_SMCx or
> UART_SCCx index */ struct uart_cpm_port *pinfo;
> int line;
> - u32 mem, pram;
> + u32 mem, pram, pram_base;
>
> line = cpm_uart_id2nr(idx);
> if(line < 0) {
> @@ -1049,6 +1049,12 @@ int cpm_uart_drv_get_platform_data(struc
> return -EINVAL;
> pram = r->start;
>
> + r = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "pram_base");
> + if (r) {
> + pram_base = r->start;
> + out_be16((u16 *)pram_base, pram & 0x);
> + }
> +
> if(idx > fsid_smc2_uart) {
> pinfo->sccp = (scc_t *)mem;
> pinfo->sccup = (scc_uart_t *)pram;
Re: [PATCH] CPM_UART: Fix non-console initialisation (v2)
On Wed, 1 Nov 2006 15:08:13 +0200 (EET)
Kalle Pokki <[EMAIL PROTECTED]> wrote:
> This is a cleaned-up version of a patch sent on Oct 19th. The patch is
> fairly straightforward and does not affect other than the compat mode. As
> not having this patch renders the cpm_uart driver unusable with a frame
> buffer console, I think this should be included in 2.6.19.
>
Fine with me.
> ---
> The cpm_uart driver is initialised incorrectly, if there is a frame buffer
> console, and CONFIG_SERIAL_CPM_CONSOLE is defined. The driver fails to
> call cpm_uart_init_portdesc() and set_lineif() in this case.
>
> Signed-off-by: Kalle Pokki <[EMAIL PROTECTED]>
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
> ---
> drivers/serial/cpm_uart/cpm_uart.h |2 +-
> drivers/serial/cpm_uart/cpm_uart_core.c | 11 ++-
> drivers/serial/cpm_uart/cpm_uart_cpm1.c |2 +-
> drivers/serial/cpm_uart/cpm_uart_cpm2.c |2 +-
> 4 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart.h
> b/drivers/serial/cpm_uart/cpm_uart.h
> index 3b35cb7..19a6ffe 100644
> --- a/drivers/serial/cpm_uart/cpm_uart.h
> +++ b/drivers/serial/cpm_uart/cpm_uart.h
> @@ -89,7 +89,7 @@ extern struct uart_cpm_port cpm_uart_por
>
> /* these are located in their respective files */
> void cpm_line_cr_cmd(int line, int cmd);
> -int cpm_uart_init_portdesc(void);
> +int __init cpm_uart_init_portdesc(void);
> int cpm_uart_allocbuf(struct uart_cpm_port *pinfo, unsigned int is_con);
> void cpm_uart_freebuf(struct uart_cpm_port *pinfo);
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
> b/drivers/serial/cpm_uart/cpm_uart_core.c
> index 8f3b3e5..4047530 100644
> --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
> @@ -1349,11 +1349,10 @@ static int cpm_uart_init(void) {
> pr_info("cpm_uart: WARNING: no UART devices found on platform
> bus!\n");
> pr_info(
> "cpm_uart: the driver will guess configuration, but this mode
> is no longer supported.\n");
> -#ifndef CONFIG_SERIAL_CPM_CONSOLE
> - ret = cpm_uart_init_portdesc();
> - if (ret)
> - return ret;
> -#endif
> +
> + /* Don't run this again, if the console driver did it already */
> + if (cpm_uart_nr == 0)
> + cpm_uart_init_portdesc();
>
> cpm_reg.nr = cpm_uart_nr;
> ret = uart_register_driver(&cpm_reg);
> @@ -1365,6 +1364,8 @@ #endif
> int con = cpm_uart_port_map[i];
> cpm_uart_ports[con].port.line = i;
> cpm_uart_ports[con].port.flags = UPF_BOOT_AUTOCONF;
> + if (cpm_uart_ports[con].set_lineif)
> +
> cpm_uart_ports[con].set_lineif(&cpm_uart_ports[con]);
> uart_add_one_port(&cpm_reg, &cpm_uart_ports[con].port);
> }
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> index 95afc37..08e55fd 100644
> --- a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> @@ -184,7 +184,7 @@ void cpm_uart_freebuf(struct uart_cpm_po
> }
>
> /* Setup any dynamic params in the uart desc */
> -int cpm_uart_init_portdesc(void)
> +int __init cpm_uart_init_portdesc(void)
> {
> pr_debug("CPM uart[-]:init portdesc\n");
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> index ef3bb47..b392aea 100644
> --- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> @@ -252,7 +252,7 @@ void cpm_uart_freebuf(struct uart_cpm_po
> }
>
> /* Setup any dynamic params in the uart desc */
> -int cpm_uart_init_portdesc(void)
> +int __init cpm_uart_init_portdesc(void)
> {
> pr_debug("CPM uart[-]:init portdesc\n");
>
> --
> 1.4.1.1
>
>
--
Sincerely,
Vitaly
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH/RFC] FS_ENET: Removed MII bitbang check for TA
On Wed, 1 Nov 2006 13:22:17 +0200 (EET) Kalle Pokki wrote: > The PHY abstraction layer expects to receive 0x when > reading PHY registers if there is no PHY at that address. The > all-ones condition is guaranteed by the pull-up in the MDIO line, so > there is no need to check for the TA bits. > > With this, the PHY layer is able to probe the MDIO bus as it expects. > This also removes one board dependency from the fs_enet driver, as > there is no need to set the phy_mask bits anymore. > > Signed-off-by: Kalle Pokki <[EMAIL PROTECTED]> At the first sight this it OK. I'll give it a try, prolly add some bits and forward along with the other fs_enet stuff residing in todo. Thanks, -Vitaly signature.asc Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] CPM_UART: Fix non-console transmit
On Thu, 19 Oct 2006 15:52:11 +0300 (EEST) Kalle Pokki <[EMAIL PROTECTED]> wrote: > The SMC and SCC hardware transmitter is enabled at the wrong > place. Simply writing twice to the non-console port, like > > $ echo asdf > /dev/ttyCPM1 > $ echo asdf > /dev/ttyCPM1 > > puts the shell into endless uninterruptible sleep, since the > transmitter is stopped after the first write, and is not enabled > before the shutdown function of the second write. Thus the transmit > buffers are never emptied. > > Signed-off-by: Kalle Pokki <[EMAIL PROTECTED]> Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]> Paul: please apply. I am recalling addressing something like the upper, but dunno why it haven't pushed upstream. Something around re-use scc/smc did not feel good with this approach, but it is much less important than the odd behavior expressed. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: enabling MDIO on ppc/8xx_io/fec.c causes ioctl problems
On Mon, 30 Oct 2006 20:07:29 +0100 Antonio Di Bacco <[EMAIL PROTECTED]> wrote: > I enabled the use of MDIO in the fec.c driver but now the driver doesn't > handle some ioctls that ifconfig sends to it. I saw that there is this code > snippet in the driver: > > #ifdefCONFIG_USE_MDIO > dev->do_ioctl = fec_enet_ioctl; > > for (i=0; i mii_cmds[i].mii_next = &mii_cmds[i+1]; > mii_free = mii_cmds; > #endif/* CONFIG_USE_MDIO */ > > But fec_enet_ioctl treats only mii related ioctls. > > What am I missing? > The 8xx_io/ stuff is obsoleted long ago. You should use drivers/fs_enet/* for your FEC eth instead. arch/ppc/mpc885_setup.c can hand some guidance on ho to do that. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: CPM2 SCC/SMC break handling broken
On Mon, 30 Oct 2006 16:23:51 +0100
Laurent Pinchart <[EMAIL PROTECTED]> wrote:
> Hi Ricardo,
>
> > > > > I need to generate a break on a CPM2 SMC serial port (same issue with
> > > > > SCC serial ports).
> > > > >
> > > > > The tcsendbreak() man page states that the function should generate a
> > > > > break between 250ms and 500ms, but testing showed that the break is
> > > > > one character long (10 bits in 8N1 mode).
> > > >
> > > > [snip]
> > > >
> > > > > CPM_CR_STOP_TX is documented to generate a break of BRKCR characters.
> > > > > The BRKCR register is initialized to 1, so only 1 break character is
> > > > > sent, which won't last between 250ms and 500ms.
> > > >
> > > > [snip]
> > > >
> > > > > Could anyone think of a proper solution which would not disturb the
> > > > > other drivers too much ?
> > > >
> > > > Well, one could always set the BRKCR parameter to the maximum number of
> > > > break characters permitted by it's size, since the break condition will
> > > > anyway end as soon as the RESTART TX command is issued as a consequence
> > > > of the tty->driver->break_ctl(tty, 0) call. But I did not test this.
> > >
> > > That's a very good idea, but the documentation is a bit misleading here.
> > > I tested the CPM2 behaviour, and found out that the break will last BRKCR
> > > characters, even if a RESTART TX command is sent sooner.
> > >
> > > The user manual states
> > >
> > > "The SMC sends a programmable number of break characters according to
> > > BRKCR and reverts to idle or sends data if a RESTART TRANSMIT is issued
> > > before completion."
> > >
> > > I suppose they meant that, if a RESTART TX command is issued before
> > > completion of the break sequence, the SMC will send data at the end of
> > > the break sequence. This is at least the behaviour I noticed after trying
> > > your idea.
> >
> > Too bad :( One more good idea to the junk bin.
> >
> > Hmm, just a wild shot you can try, while you're at that: what about setting
> > BRKCR to zero and issuing another STOP TRANSMIT, just before the RESTART
> > TRANSMIT?
>
> Wow, congratulations. I wouldn't have thought about that.
>
> static void cpm_uart_break_ctl(struct uart_port *port, int break_state)
> {
> struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
> int line = pinfo - cpm_uart_ports;
> volatile u16 *brkcr = IS_SMC(pinfo) ? &pinfo->smcup->smc_brkcr
> : &pinfo->sccup->scc_brkcr;
>
> pr_debug("CPM uart[%d]:break ctrl, break_state: %d\n", port->line,
> break_state);
>
> if (break_state)
> {
> *brkcr = 32767;
> cpm_line_cr_cmd(line, CPM_CR_STOP_TX);
> }
> else
> {
> *brkcr = 0;
> cpm_line_cr_cmd(line, CPM_CR_STOP_TX);
> cpm_line_cr_cmd(line, CPM_CR_RESTART_TX);
> }
> }
>
> This is a bit hackish though, but it works and doesn't require any API
> modification.
>
> Vitaly, could you give me your opinion ?
I'm fine with this change. Can you provide a sorta more complete reference why
it is required?
I understood in general, but as author, you can explain the reason more clear I
beleive...
Thanks.
-V
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Building new FEC code on 8xx with 2.6.17 kernel
On Fri, 27 Oct 2006 14:41:06 +1300 Robin Gilks <[EMAIL PROTECTED]> wrote: > Greetings > > Just having a first stab at building for an 859T based product so I > assume I'll be using the new FEC driver. I'm getting two unresolved > references as follows: > > drivers/built-in.o: In function > `fec_8xx_init':fec_main.c:(.init.text+0x1a40): undefined reference to > `fec_8xx_platform_init' > drivers/built-in.o: In function > `fec_8xx_cleanup':fec_main.c:(.exit.text+0x39c): undefined reference to > `fec_8xx_platform_cleanup' > > No big deal as I can see an example for the netta platform (whatever > that is) that defines these functions and I can hack that to suit my > hardware - what I can't find is where CONFIG_NETTA is defined. I can't > find it in any Kconfig file, and I want to use the same mechanism for > selecting my platform. > > Any ideas? (or is FEC still broken on CPM1 processors) > Please use fs_enet driver (drivers/fs_enet). You can find the reference for platform code at say arch/ppc/platforms/mpc885_setup.c -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: CPM2 (MPC8260) SMC problem. Please help.
[...]
> >>
> >> I think that should be walked along the cpm_uart driver, TX part
> >> to see is sending stuff
> >> do not indicate any error in the CPM registers, or at least
> >> discover exact track leading to the endless loop.
> >
> > HI. I'm new here, but I encounted a very similar problem late last
> > week
> >
> > Boris, I am willing to bet that your problem lies with the return
> > value from cpm_uart_tx_pump(). Here's the last few lines of that
> > function from 2.6.17 :
> > 693 if (uart_circ_empty(xmit)) {
> > 694 cpm_uart_stop_tx(port);
> > 695 return 0;
> > 696 }
> > 697
> > 698 return 1;
> > 699 }
> > Note that return value is 0 if there is no more data in the tty's
> > circular queue (uart_circ_empty() returns true) This is the case when
> > you send a small packet. It seems appropriate to turn off the
> > transmitter (cpm_uart_stop_tx()) in the general case, but the problem
> > is that you never turned on the transmitter in the first place.you
> > called cpm_uart_tx_pump() from cpm_uart_start_tx() like so:
> > 195 if (cpm_uart_tx_pump(port) != 0) {
> > 196 if (IS_SMC(pinfo)) {
> > 197 smcp->smc_smcm |= SMCM_TX;
> > 198 smcp->smc_smcmr |= SMCMR_TEN;
> > 199 } else {
> > 200 sccp->scc_sccm |= UART_SCCM_TX;
> > 201 pinfo->sccp->scc_gsmrl |= SCC_GSMRL_ENT;
> > 202 }
> > 203 }
> >
> > When you then attempt to close the port, you'll get stuck here, in
> > cpm_uart_shutdown():
> > 455 /* Wait for all the BDs marked sent */
> > 456 while(!cpm_uart_tx_empty(port)) {
> > 457 set_current_state(TASK_UNINTERRUPTIBLE);
> > 458 schedule_timeout(2);
> > 459 }
> > Because the transmitter was never turned on, the bd will never be
> > processed by the CPM and cpm_uart_tx_empty() will always return false.
> >
> > Recommendation: Change the first block of code above to: "return
> > (count != 0);" Now cpm_uart_tx_pump() will return true if data was
> > placed in a bd, instead of true when there is more data to be
> > processed later. This code works for me - but there are folks on this
> > list who would have a better idea about possible side
> > effectsanyone?
>
> Yes, sounds true.
>
> Since I was responsible for that, hand me the brown paper bag...
>
> /me wears it.
>
> Please send me a patch to process it.
>
Hey, not that rough :)
I used to add some bits and "cpm_uart_tx_empty() will always return false" is
mine as well.
Greg:
Patch/code snippet from working tree welcome, and I'll address it anyway since
it looks like generic issue.
Thanks.
--
Sincerely,
Vitaly
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8xx CPM I2C interface driver
On Tue, 10 Oct 2006 11:05:49 +0200 Norbert van Bolhuis wrote: > > Is there no MPC8xx CPM I2C interface driver in (latest) linux v2.6 or > am I mistaken ? > There's no code for CONFIG_I2C_ALGO8XX. The answer is - no, there is no stuff in the 2.6 kernel. I used to have the port from 2.4 a while ago (an improvement to the patches posted here btw) but had no chance to cleanup it and push through lm_sensors. > > I've a MPC870 based board and I was hoping for a MPC8xx CPM I2C > interface driver to be there (allowing user applications to open and > read/write /dev/i2c-0) > You should be able to locate sources in this list's archives. Ping me once more if not, I'll try to dig it out of my HDD then... > Thanks, > N. > > > -- -Vitaly signature.asc Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: CPM2 (MPC8260) SMC problem. Please help.
On Wed, 18 Oct 2006 22:40:31 +0200 Boris Shteinbock <[EMAIL PROTECTED]> wrote: > Hi ppl. > > I have discovered very very odd problem with SMC2 on my 8260 board. > kernel version is 2.6.17. > > The board is 8260 with serial ports on SMC1 and SMC 2 (SMC1 - console) > > Now if I use SMC2 for communicating with remote device, ( some protocol) > I am sending packets and wait for a response. > However if the packet I send is SMALLER than 5 bytes, SMC goes > completely crazy. > write() doesn't return error, but the next read() hangs completely, and the > process moves to D state and it is impossible to kill it by any means. > It only happens when consequent writes of smaller than 5 bytes. > I tried to check the driver, but couldn't find any clues to what goes wrong. > > I tried both compatibility and platform-based modes with the same results. > > Any help on the issue would be highliy appreciated. > > I think that should be walked along the cpm_uart driver, TX part to see is sending stuff do not indicate any error in the CPM registers, or at least discover exact track leading to the endless loop. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] CPM_UART: Fix non-console initialisation
On Thu, 19 Oct 2006 22:40:27 +0300 Kalle Pokki wrote: > On 10/19/06, Vitaly Bordug <[EMAIL PROTECTED]> wrote: > > And we end up with init_portdesc called unconditionally? this would > > likely break, or at least confuse the code, that uses platform dev > > to pass resources offsets. > > Well now that I look at it again, we should probably do > > if (cpm_uart_no == 0) > cpm_uart_init_portdesc(); > > to make it at least a little less confusing. Remember that > init_portdesc() is not called when using platform device, so this > should not affect those targets using it at all. > ok. > > Personally, I don't care much of compat stuff, unless it is > > breaking/confusing targets using proper resources... > > I'm sure there are still lots of people using the compat mode. As long > as we have it, it should be kept functional. I'm not for removing it - just any update to the compat stuff should not touch platform-managed/ make it more complex/confusing to deal with. I believe it's cumbersome enough yet :-) > > -Vitaly signature.asc Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] CPM_UART: Fix non-console transmit
On Thu, 19 Oct 2006 15:25:55 +0300 (EEST)
[EMAIL PROTECTED] wrote:
> The SMC and SCC hardware transmitter is enabled at the wrong
> place. Simply writing twice to the non-console port, like
>
> $ echo asdf > /dev/ttyCPM1
> $ echo asdf > /dev/ttyCPM1
>
> puts the shell into endless uninterruptible sleep, since the
> transmitter is stopped after the first write, and is not enabled
> before the shutdown function of the second write. Thus the transmit
> buffers are never emptied.
>
Was about to Ack, but... need one more glance at it on hw.
I recall something that might be reason of the current implementation,
but had no chance to recover the details.
Thanks for the input. I'll follow-up tomorrow.
> Signed-off-by: Kalle Pokki <[EMAIL PROTECTED]>
> ---
> drivers/serial/cpm_uart/cpm_uart_core.c |5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
> b/drivers/serial/cpm_uart/cpm_uart_core.c index 90ff96e..8f3b3e5
> 100644 --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
> @@ -194,10 +194,8 @@ static void cpm_uart_start_tx(struct uar
> if (cpm_uart_tx_pump(port) != 0) {
> if (IS_SMC(pinfo)) {
> smcp->smc_smcm |= SMCM_TX;
> - smcp->smc_smcmr |= SMCMR_TEN;
> } else {
> sccp->scc_sccm |= UART_SCCM_TX;
> - pinfo->sccp->scc_gsmrl |= SCC_GSMRL_ENT;
> }
> }
> }
> @@ -420,9 +418,10 @@ static int cpm_uart_startup(struct uart_
> /* Startup rx-int */
> if (IS_SMC(pinfo)) {
> pinfo->smcp->smc_smcm |= SMCM_RX;
> - pinfo->smcp->smc_smcmr |= SMCMR_REN;
> + pinfo->smcp->smc_smcmr |= (SMCMR_REN | SMCMR_TEN);
> } else {
> pinfo->sccp->scc_sccm |= UART_SCCM_RX;
> + pinfo->sccp->scc_gsmrl |= (SCC_GSMRL_ENR |
> SCC_GSMRL_ENT); }
>
> if (!(pinfo->flags & FLAG_CONSOLE))
signature.asc
Description: PGP signature
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] CPM_UART: Fix non-console initialisation
On Thu, 19 Oct 2006 15:31:10 +0300 (EEST)
[EMAIL PROTECTED] wrote:
> If there is a frame buffer console, the cpm_uart_init_portdesc()
> function is never called in the compat mode. Also, the set_lineif()
> method is not called in the compat mode.
>
for the fbconsole case, I agree we do have to address it. But not the proposed
way.
See below.
> Signed-off-by: Kalle Pokki <[EMAIL PROTECTED]>
> ---
> drivers/serial/cpm_uart/cpm_uart.h |2 +-
> drivers/serial/cpm_uart/cpm_uart_core.c |9 -
> drivers/serial/cpm_uart/cpm_uart_cpm1.c |6 +-
> drivers/serial/cpm_uart/cpm_uart_cpm2.c |6 +-
> 4 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart.h
> b/drivers/serial/cpm_uart/cpm_uart.h index 3b35cb7..19a6ffe 100644
> --- a/drivers/serial/cpm_uart/cpm_uart.h
> +++ b/drivers/serial/cpm_uart/cpm_uart.h
> @@ -89,7 +89,7 @@ extern struct uart_cpm_port cpm_uart_por
>
> /* these are located in their respective files */
> void cpm_line_cr_cmd(int line, int cmd);
> -int cpm_uart_init_portdesc(void);
> +int __init cpm_uart_init_portdesc(void);
> int cpm_uart_allocbuf(struct uart_cpm_port *pinfo, unsigned int
> is_con); void cpm_uart_freebuf(struct uart_cpm_port *pinfo);
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
> b/drivers/serial/cpm_uart/cpm_uart_core.c index 8f3b3e5..895f2f1
> 100644 --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
> @@ -1349,11 +1349,8 @@ static int cpm_uart_init(void) {
> pr_info("cpm_uart: WARNING: no UART devices found
> on platform bus!\n"); pr_info(
> "cpm_uart: the driver will guess configuration, but
> this mode is no longer supported.\n"); -#ifndef
> CONFIG_SERIAL_CPM_CONSOLE
> - ret = cpm_uart_init_portdesc();
> - if (ret)
> - return ret;
> -#endif
> +
> + cpm_uart_init_portdesc();
>
And we end up with init_portdesc called unconditionally? this would likely
break, or at least confuse the
code, that uses platform dev to pass resources offsets.
> cpm_reg.nr = cpm_uart_nr;
> ret = uart_register_driver(&cpm_reg);
> @@ -1365,6 +1362,8 @@ #endif
> int con = cpm_uart_port_map[i];
> cpm_uart_ports[con].port.line = i;
> cpm_uart_ports[con].port.flags =
> UPF_BOOT_AUTOCONF;
> + if (cpm_uart_ports[con].set_lineif)
> +
> cpm_uart_ports[con].set_lineif(&cpm_uart_ports[con]);
> uart_add_one_port(&cpm_reg, &cpm_uart_ports[con].port); }
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> b/drivers/serial/cpm_uart/cpm_uart_cpm1.c index 95afc37..6f04a9f
> 100644 --- a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> @@ -184,10 +184,14 @@ void cpm_uart_freebuf(struct uart_cpm_po
> }
>
> /* Setup any dynamic params in the uart desc */
> -int cpm_uart_init_portdesc(void)
> +int __init cpm_uart_init_portdesc(void)
> {
> pr_debug("CPM uart[-]:init portdesc\n");
>
> + /* Don't run this again, if the console driver did it
> already */
> + if (cpm_uart_nr > 0)
> + return 0;
> +
> cpm_uart_nr = 0;
> #ifdef CONFIG_SERIAL_CPM_SMC1
> cpm_uart_ports[UART_SMC1].smcp = &cpmp->cp_smc[0];
> diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> b/drivers/serial/cpm_uart/cpm_uart_cpm2.c index ef3bb47..0f21543
> 100644 --- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> @@ -252,10 +252,14 @@ void cpm_uart_freebuf(struct uart_cpm_po
> }
>
> /* Setup any dynamic params in the uart desc */
> -int cpm_uart_init_portdesc(void)
> +int __init cpm_uart_init_portdesc(void)
> {
> pr_debug("CPM uart[-]:init portdesc\n");
>
> + /* Don't run this again, if the console driver did it
> already */
> + if (cpm_uart_nr > 0)
> + return 0;
> +
Personally, I don't care much of compat stuff, unless it is breaking/confusing
targets
using proper resources...
> cpm_uart_nr = 0;
> #ifdef CONFIG_SERIAL_CPM_SMC1
> cpm_uart_ports[UART_SMC1].smcp = (smc_t *) &
> cpm2_immr->im_smc[0];
signature.asc
Description: PGP signature
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: bdm/jtag interface for MPC834x with gdb access
On Wed, 4 Oct 2006 22:00:12 + "Reeve Yang" <[EMAIL PROTECTED]> wrote: > Can anyone share experience on bcm/jtag interface for MPC834x with gdb > access? I'm using windriver usb jtag probe. Is there any bdm interface with > gdb access available for it? > Abatron BDI2000 is just the best IMO. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: fs_enet - support for SCC on CPM2?
On Tue, 26 Sep 2006 11:22:30 -0400 "Pelton, Dave" <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: Matt Hevern > > > > > I am trying to compile for an freescale 82xx (CPM2) series > > processor, with ethernet on an SCC. (kernel 2.6.x) From what > > i can see, in the file drivers/net/fs_enet/fs_enet-main.c, > > the config option "CONFIG_FS_ENET_HAS_SCC" pulls in > > "fs_scc_ops" which are defined in > > drivers/net/fs_enet/mac-scc.c, but this file does not seem > > to have support for 82xx series, failing with various compile errors: > > > It seems like these errors are mostly due to the driver being tailored > for 8xx series. > > > I had the same problem trying to use fs_enet for 82xx SCC Ethernet and > came to the same conclusion. The FCC could not be used instead of the > SCC because of pin limitations in the hardware design. I ended up using > the "old" SCC Ethernet driver by disabling CONFIG_FS_ENET_HAS_SCC and > enabling CONFIG_SCC_ENET (Under CPM2 options in kernel config). This > does not use the new platform bus structure, and arch/ppc/8260_io/enet.c > may require some board specific tweaks, but it does work. > Scc Ethernet on 82xx was not supported because the hardware it was developed on did not support such an option at all. That was the reason why scc_enet is "tailored" for 8xx. If there is a desire and HW to make it work, please go ahead, I'll assist as per time permits, and make sure the stuff will be merged upstream. Obsoleted things like 8260_io may disappear sooner or later (I bet sooner is more probably...) -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
How to move from /ppc/ to /powerpc/
On Tue, 12 Sep 2006 17:33:16 +0200 Fredrik Roubert wrote: > Hi! > > I have a custom board on which I currently run Linux 2.6.18-rc6 > configured for MPC834x_SYS in the /ppc/ tree, which just a few minor > changes. Now I'm interested to move to using the /powerpc/ source tree > instead, but I can't figure out exactly what steps are necessary to do > this. > > Does anyone run a MPC834x_SYS built with ARCH=powerpc? > Actually it was the first ppc board actually moved over to powerpc. > I boot the board with U-Boot (version 1.1.4, customized), and I assume > that I need to add some stuff for this new device tree thing, but I > can't figure out exactly what the kernel will expect. You'll need to replace u-boot with custom one that is able to deal with dts. There are 2 ways ATM - use bootm dts approach, which could load device tree from external source, and built-in that makes in compiled into u-boot. Both patches against u-boot should be searched in u-boot mailing list archives. For 83xx both way work just fine. -- Sincerely, Vitaly
Re: How to move from /ppc/ to /powerpc/
On Tue, 12 Sep 2006 17:33:16 +0200 Fredrik Roubert <[EMAIL PROTECTED]> wrote: > Hi! > > I have a custom board on which I currently run Linux 2.6.18-rc6 > configured for MPC834x_SYS in the /ppc/ tree, which just a few minor > changes. Now I'm interested to move to using the /powerpc/ source tree > instead, but I can't figure out exactly what steps are necessary to do > this. > > Does anyone run a MPC834x_SYS built with ARCH=powerpc? > Actually it was the first ppc board actually moved over to powerpc. > I boot the board with U-Boot (version 1.1.4, customized), and I assume > that I need to add some stuff for this new device tree thing, but I > can't figure out exactly what the kernel will expect. You'll need to replace u-boot with custom one that is able to deal with dts. There are 2 ways ATM - use bootm dts approach, which could load device tree from external source, and built-in that makes in compiled into u-boot. Both patches against u-boot should be searched in u-boot mailing list archives. For 83xx both way work just fine. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
I2C on MPC8272...
On Fri, 8 Sep 2006 13:00:58 -0400 "Kuffner Cory" wrote: > Hello all, > > Does anyone know how to use the I2C module for the MPC8272?? We are > attempting to enable it by following code written for a bareboard system and > converting it into a kernel module (2.6.11 Kernel), but nothing happens on > our SDA and SCL data lines. The parameter ram is kind of tricky to set up, > but I beleive we have everything pointing where it should. To write to the > IMM we are using the ioremap function with ioread and iowrite, we can write > to the ports so I don't think there is an issue writing to memory, but I'm > new to embedded linux. Has anyone ever used the I2C controller in one of > freescale's chips or just a good understanding of I2C modules in embedded > linux?? I think all the chips have the same I2C interfaceso it should be > the same set up for MPC8250, 8255, 8260, etc. > I am recalling i2c functional on 8272, but no other details unfortunately. IIRC, i2c-mpc.c did the magic with some minor intervention. Barely, to access immr it is ioremapped early, and cpm2_immr-> holds i2c controller, pram and other pleasant stuff. And, I am recalling i2c on 8540 working fine right out of the box... -- Sincerely, Vitaly
Re: I2C on MPC8272...
On Fri, 8 Sep 2006 13:00:58 -0400 "Kuffner Cory" <[EMAIL PROTECTED]> wrote: > Hello all, > > Does anyone know how to use the I2C module for the MPC8272?? We are > attempting to enable it by following code written for a bareboard system and > converting it into a kernel module (2.6.11 Kernel), but nothing happens on > our SDA and SCL data lines. The parameter ram is kind of tricky to set up, > but I beleive we have everything pointing where it should. To write to the > IMM we are using the ioremap function with ioread and iowrite, we can write > to the ports so I don't think there is an issue writing to memory, but I'm > new to embedded linux. Has anyone ever used the I2C controller in one of > freescale's chips or just a good understanding of I2C modules in embedded > linux?? I think all the chips have the same I2C interfaceso it should be > the same set up for MPC8250, 8255, 8260, etc. > I am recalling i2c functional on 8272, but no other details unfortunately. IIRC, i2c-mpc.c did the magic with some minor intervention. Barely, to access immr it is ioremapped early, and cpm2_immr-> holds i2c controller, pram and other pleasant stuff. And, I am recalling i2c on 8540 working fine right out of the box... -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
OT: Re: [U-Boot-Users] Status of OF in TQM8540 and linux-2.6.17.11
On Tue, 05 Sep 2006 15:28:54 +0200 Clemens Koller wrote: > Hello, Wolfgang! > > -> moving from u-boot-users to linuxppc-embedded > > Wolfgang Denk wrote: > > In message <44FD5BD4.9090406 at anagramm.de> you wrote: > > > >>Now I try to boot a current linux kernel - the vanilla 2.6.17.11 > >>with the default tqm8540 config but it doesn't show any sign of life > > > > Please use the kernel from our repo instead; see > > http://www.denx.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git > > Okay, the compilation after a make TQM8540_defconfig fails: > > clemens at ecam:~/git/linux-2.6-denx$ make uImage > CHK include/linux/version.h > CHK include/linux/utsrelease.h > SYMLINK include/asm -> include/asm-ppc > CHK include/linux/compile.h > CC arch/ppc/syslib/mpc85xx_devices.o > In file included from arch/ppc/syslib/mpc85xx_devices.c:23: > include/asm/cpm2.h:1193:1: warning: "FCC2_MEM_OFFSET" redefined > include/asm/cpm2.h:1192:1: warning: this is the location of the previous > definition > arch/ppc/syslib/mpc85xx_devices.c:99: error: `F1_RXCLK' undeclared here (not > in a function) > arch/ppc/syslib/mpc85xx_devices.c:99: error: `F1_TXCLK' undeclared here (not > in a function) > arch/ppc/syslib/mpc85xx_devices.c:99: error: initializer element is not > constant > arch/ppc/syslib/mpc85xx_devices.c:99: error: (near initialization for > `mpc85xx_fcc1_pdata.clk_route') > arch/ppc/syslib/mpc85xx_devices.c:100: error: initializer element is not > constant > arch/ppc/syslib/mpc85xx_devices.c:100: error: (near initialization for > `mpc85xx_fcc1_pdata.clk_trx') > arch/ppc/syslib/mpc85xx_devices.c:117: error: `F2_RXCLK' undeclared here (not > in a function) > arch/ppc/syslib/mpc85xx_devices.c:117: error: `F2_TXCLK' undeclared here (not > in a function) > arch/ppc/syslib/mpc85xx_devices.c:117: error: initializer element is not > constant > arch/ppc/syslib/mpc85xx_devices.c:117: error: (near initialization for > `mpc85xx_fcc2_pdata.clk_route') > arch/ppc/syslib/mpc85xx_devices.c:118: error: initializer element is not > constant > arch/ppc/syslib/mpc85xx_devices.c:118: error: (near initialization for > `mpc85xx_fcc2_pdata.clk_trx') > arch/ppc/syslib/mpc85xx_devices.c:135: error: `F3_RXCLK' undeclared here (not > in a function) > arch/ppc/syslib/mpc85xx_devices.c:135: error: `F3_TXCLK' undeclared here (not > in a function) > arch/ppc/syslib/mpc85xx_devices.c:135: error: initializer element is not > constant > arch/ppc/syslib/mpc85xx_devices.c:135: error: (near initialization for > `mpc85xx_fcc3_pdata.clk_route') > arch/ppc/syslib/mpc85xx_devices.c:136: error: initializer element is not > constant > arch/ppc/syslib/mpc85xx_devices.c:136: error: (near initialization for > `mpc85xx_fcc3_pdata.clk_trx') > arch/ppc/syslib/mpc85xx_devices.c:138: error: `FCC3_MEM_OFFSET' undeclared > here (not in a function) > arch/ppc/syslib/mpc85xx_devices.c:138: error: initializer element is not > constant > arch/ppc/syslib/mpc85xx_devices.c:138: error: (near initialization for > `mpc85xx_fcc3_pdata.mem_offset') > make[1]: *** [arch/ppc/syslib/mpc85xx_devices.o] Error 1 > make: *** [arch/ppc/syslib] Error 2 > > >>Are there any tips&tricks to consider regarding that point? > > > > Yes, use a working kernel. Not all our patches have been accepted > > upstream, and we have some lag with re-submissions. > > According to TQC, the latest "working" kernel was a 2.6.15-git from your > (denx) tree. I get the details from Mr. Becher at TQC and see how far I can > get. > > Okay, let's move over to linux-ppc-embedded. (xposting) The upper defines need to reside in the board-specific code for tqm as well as for other boards utilizing such scheme (see platforms/85xx/mpc85xx_ads_common.h for instance). Fix for FCC3_MEM_OFFSET was part of my patch series (as a typo fix), I'll submit it separately since it's a notable bugfix should be in the mainstream. -- Sincerely, Vitaly
Re: OT: Re: [U-Boot-Users] Status of OF in TQM8540 and linux-2.6.17.11
On Tue, 05 Sep 2006 15:28:54 +0200 Clemens Koller <[EMAIL PROTECTED]> wrote: > Hello, Wolfgang! > > -> moving from u-boot-users to linuxppc-embedded > > Wolfgang Denk wrote: > > In message <[EMAIL PROTECTED]> you wrote: > > > >>Now I try to boot a current linux kernel - the vanilla 2.6.17.11 > >>with the default tqm8540 config but it doesn't show any sign of life > > > > Please use the kernel from our repo instead; see > > http://www.denx.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git > > Okay, the compilation after a make TQM8540_defconfig fails: > > [EMAIL PROTECTED]:~/git/linux-2.6-denx$ make uImage > CHK include/linux/version.h > CHK include/linux/utsrelease.h > SYMLINK include/asm -> include/asm-ppc > CHK include/linux/compile.h > CC arch/ppc/syslib/mpc85xx_devices.o > In file included from arch/ppc/syslib/mpc85xx_devices.c:23: > include/asm/cpm2.h:1193:1: warning: "FCC2_MEM_OFFSET" redefined > include/asm/cpm2.h:1192:1: warning: this is the location of the previous > definition > arch/ppc/syslib/mpc85xx_devices.c:99: error: `F1_RXCLK' undeclared here (not > in a function) > arch/ppc/syslib/mpc85xx_devices.c:99: error: `F1_TXCLK' undeclared here (not > in a function) > arch/ppc/syslib/mpc85xx_devices.c:99: error: initializer element is not > constant > arch/ppc/syslib/mpc85xx_devices.c:99: error: (near initialization for > `mpc85xx_fcc1_pdata.clk_route') > arch/ppc/syslib/mpc85xx_devices.c:100: error: initializer element is not > constant > arch/ppc/syslib/mpc85xx_devices.c:100: error: (near initialization for > `mpc85xx_fcc1_pdata.clk_trx') > arch/ppc/syslib/mpc85xx_devices.c:117: error: `F2_RXCLK' undeclared here (not > in a function) > arch/ppc/syslib/mpc85xx_devices.c:117: error: `F2_TXCLK' undeclared here (not > in a function) > arch/ppc/syslib/mpc85xx_devices.c:117: error: initializer element is not > constant > arch/ppc/syslib/mpc85xx_devices.c:117: error: (near initialization for > `mpc85xx_fcc2_pdata.clk_route') > arch/ppc/syslib/mpc85xx_devices.c:118: error: initializer element is not > constant > arch/ppc/syslib/mpc85xx_devices.c:118: error: (near initialization for > `mpc85xx_fcc2_pdata.clk_trx') > arch/ppc/syslib/mpc85xx_devices.c:135: error: `F3_RXCLK' undeclared here (not > in a function) > arch/ppc/syslib/mpc85xx_devices.c:135: error: `F3_TXCLK' undeclared here (not > in a function) > arch/ppc/syslib/mpc85xx_devices.c:135: error: initializer element is not > constant > arch/ppc/syslib/mpc85xx_devices.c:135: error: (near initialization for > `mpc85xx_fcc3_pdata.clk_route') > arch/ppc/syslib/mpc85xx_devices.c:136: error: initializer element is not > constant > arch/ppc/syslib/mpc85xx_devices.c:136: error: (near initialization for > `mpc85xx_fcc3_pdata.clk_trx') > arch/ppc/syslib/mpc85xx_devices.c:138: error: `FCC3_MEM_OFFSET' undeclared > here (not in a function) > arch/ppc/syslib/mpc85xx_devices.c:138: error: initializer element is not > constant > arch/ppc/syslib/mpc85xx_devices.c:138: error: (near initialization for > `mpc85xx_fcc3_pdata.mem_offset') > make[1]: *** [arch/ppc/syslib/mpc85xx_devices.o] Error 1 > make: *** [arch/ppc/syslib] Error 2 > > >>Are there any tips&tricks to consider regarding that point? > > > > Yes, use a working kernel. Not all our patches have been accepted > > upstream, and we have some lag with re-submissions. > > According to TQC, the latest "working" kernel was a 2.6.15-git from your > (denx) tree. I get the details from Mr. [EMAIL PROTECTED] and see how far I > can get. > > Okay, let's move over to linux-ppc-embedded. (xposting) The upper defines need to reside in the board-specific code for tqm as well as for other boards utilizing such scheme (see platforms/85xx/mpc85xx_ads_common.h for instance). Fix for FCC3_MEM_OFFSET was part of my patch series (as a typo fix), I'll submit it separately since it's a notable bugfix should be in the mainstream. -- Sincerely, Vitaly ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Platform device style question
On Thu, 24 Aug 2006 13:53:17 -0400 Ben Warren wrote: > Hello, > > A 'newbie-to-platform-devices' question: > > In a patch that Kumar just sent for a compact flash device, the resource > data (I/O addresses, IRQ # etc.) are retrieved from the platform system. > I guess I can either modify the device tree in U-boot by adding > additional nodes, or instantiate a platform device in Linux __init code > based on static information. The former gives the advantage of having > the bootloader pass the info to the OS. (Somebody please correct me if > I'm off-base here!) > I'd suggest to make a look at LDD concerning linux device model... For platform device, there's no need to cope with u-boot at all. You'll prolly need to register the respective platform device from the board-specific code, with proper name and driver's board-specific platform info. You may have a look at arch/ppc/syslib/ppc_sys.c about static PD definitions usage. > Are device trees meant to only contain information about the CPU and > tightly-coupled peripherals, or is it considered OK-form to also include > board-level hardware info? I guess they can really hold anything, but > I'm trying to figure out the original intent. > I'd make sense to figure out the platform device bus before digging into device trees. It's slightly different stuff, for similar aim, but anyway... Actually you do not strictly need devtree to cope with your case afaiu. > regards, > Ben > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > -- Sincerely, Vitaly
Compilation error in fsl_soc.c
On Mon, 31 Jul 2006 08:37:56 +0100 "Demke Torsten-atd012" wrote: > Hi all, > > with a recent versions from Paulus merge-tree the compilation > of MPC85xx CDS failed with following output: > ... > LD arch/powerpc/lib/built-in.o > CC arch/powerpc/sysdev/mpic.o > CC arch/powerpc/sysdev/indirect_pci.o > AS arch/powerpc/sysdev/dcr.o > CC arch/powerpc/sysdev/fsl_soc.o > arch/powerpc/sysdev/fsl_soc.c: In function 'gfar_mdio_of_init': > arch/powerpc/sysdev/fsl_soc.c:88: error: 'struct device_node' has no > member name d 'n_intrs' > arch/powerpc/sysdev/fsl_soc.c:91: error: 'struct device_node' has no > member name d 'intrs' > arch/powerpc/sysdev/fsl_soc.c: In function 'gfar_of_init': > arch/powerpc/sysdev/fsl_soc.c:142: error: 'struct device_node' has no > member nam ed 'intrs' > arch/powerpc/sysdev/fsl_soc.c:143: error: 'struct device_node' has no > member nam ed 'intrs' > arch/powerpc/sysdev/fsl_soc.c:153: error: 'struct device_node' has no > member nam ed 'intrs' > arch/powerpc/sysdev/fsl_soc.c:154: error: 'struct device_node' has no > member nam ed 'intrs' > arch/powerpc/sysdev/fsl_soc.c:158: error: 'struct device_node' has no > member nam ed 'intrs' > arch/powerpc/sysdev/fsl_soc.c:159: error: 'struct device_node' has no > member nam ed 'intrs' > arch/powerpc/sysdev/fsl_soc.c:165: error: 'struct device_node' has no > member nam ed 'n_intrs' > arch/powerpc/sysdev/fsl_soc.c: In function 'fsl_i2c_of_init': > arch/powerpc/sysdev/fsl_soc.c:254: error: 'struct device_node' has no > member nam ed 'intrs' > arch/powerpc/sysdev/fsl_soc.c:255: error: 'struct device_node' has no > member nam ed 'intrs' > arch/powerpc/sysdev/fsl_soc.c: In function 'fsl_usb_of_init': > arch/powerpc/sysdev/fsl_soc.c:391: error: 'struct device_node' has no > member nam ed 'intrs' > arch/powerpc/sysdev/fsl_soc.c:392: error: 'struct device_node' has no > member nam ed 'intrs' > arch/powerpc/sysdev/fsl_soc.c:440: error: 'struct device_node' has no > member nam ed 'intrs' > arch/powerpc/sysdev/fsl_soc.c:441: error: 'struct device_node' has no > member nam ed 'intrs' > make[1]: *** [arch/powerpc/sysdev/fsl_soc.o] Error 1 > make: *** [arch/powerpc/sysdev] Error 2 No, since it is just going to be out. I'll submit some patches addressing that this week... -- Sincerely, Vitaly
Endless "Trying 100/HALF" messages using FCC ethernet on MPC8248
On Mon, 24 Jul 2006 11:39:01 +0200 Laurent Pinchart wrote: > Hi everybody, > > I'm not sure if this issue is ppc-specific, so forgive me if it should have > been reported to the drivers/net/phy maintainer. > > When using the MPC8248 FCC ethernet ports, the following messages are printed > by the kernel on the console when a link is down (ethernet cable unplugged): > > Trying 100/FULL > Trying 100/HALF > Trying 100/HALF > Trying 100/HALF > ... > > This goes on forever, with a new message every 5 or 10 seconds. The message > is > printed by drivers/net/phy/phy.c at line 463. > > Those messages are pretty annoying. Commenting the pr_info() call gave me > some > rest, but a proper fix is probably needed. > > For the record, I'm using FCC1 and FCC2 with an LXT973 phy in bit-banging > mode. > The thing you'll need is to make driver to trust autonegotiation... IIRC that was addressed in my patches for fs-enet. what's happening: The PAL subsystem tries hard to be wise, an dif there are no link located, it starts to try forced mode, setting various stuff as link params and looking if link appeared or not. To keep consistency, I used the special flag passed via platform info, to just trust what ANEG had find out. Prolly we need to limit the forced aneg as well somehow - say give up after it failed to get link going at 10/HALF or smth like that. -- Sincerely, Vitaly
Boot strategies and Boot Image formats in arch/powerpc
On Fri, 21 Jul 2006 11:35:25 +0200 "Claus Gindhart" wrote: > Hi all, > > currently i am trying to migrate our existing PowerPC board supports from the > arch/ppc - directory into the new arch/powerpc. I am directly working within > a cloned paulus_powerpc git repository on the most recent status. > > We (Kontron) want to bring our kernel sources into the appropriate for an > open source submission. We are modifying both our proprietary Bootloader, and > the Linux Kernel, to make them fit to the new conventions, e.g. the flattened > device tree. > > However, i dont understand the following: > > In the old structure, the kernel provided a bunch of sub directories > (simple,openfirmware,...) to create a wrapper around the Linux kernel for > brining it into the format, which is appropriate for the boot loader used. > This structure was easily adaptable for custom image formats. > > Now, these dirs dont exist any more. Well, in arch/powerpc those stuff had no sense so far.. But it may change - see below. > > What is the strategy here (i could assume one the 3 variants below ? > > a) Is it now in the responsibility of the bootloader, to support one of the > image formats, > which can be generated here currently ? > This way we have started with powerpc merge and it still could be used. there are plenty of such stuff in the list archives, being discussed, and even followed up with patches. But that imply u-boot firmware so not interesting for you I assume. > b) Will these subdirs (e.g. "simple") come here, but just where not ported > yet ? > Currently, Mark is working on a thing similar to this case. the kernel building zImage has to compile devicetree to binary dtb and line stuff up so that booting, the shim has started the kernel and have devicetree passed to it. > c) Or, shall such wrapper around the kernel, and/or bringing the kernel into > a particular file format > be performed outside the kernel source, by proprietary tools > (e.g. like U-boot does it with the mkimage tool) ? > This was yet another way pondered, but I guess b) looked better. > -- > Mit freundlichen Gruessen / Best regards > > Claus Gindhart > SW R&D > Kontron Modular Computers > phone :++49 (0)8341-803-374 > mailto:claus.gindhart at kontron-modular.com > http://www.kontron.com > > -BEGIN GEEK CODE BLOCK- > Version: 3.1 > GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o? > K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++ > D-- G e++> h--- !r x+++ > --END GEEK CODE BLOCK-- > > > > > > -- Sincerely, Vitaly
PHY Howto ?
On Thu, 20 Jul 2006 13:52:47 -0400 "David H. Lynch Jr." wrote: > If I am writing a network MAC driver, for hardware that has a phy > that is already supported, if I provide the appropriate mdio_read() and > mdio_write() calls to access the phy registers, and setup my config to > include phylib and drivers for my specific phy, what else do I have to > take care of with respect to the phy within my driver ? > > Are there some resources, howto's, examples, ... demonstrating > how to use phylib ? There is pretty good writeup in Documentation about your concern, find it at Documentation/networking/phy.txt . Live example is obviously drivers/net/gianfar* -- Sincerely, Vitaly
multicast for 8260 for 2.6.13
On Thu, 20 Jul 2006 16:45:11 +0200 "Harnois Anne-Sophie" wrote: > Hello > > In the file arch/ppc/8260_io/fcc_enet.c, set_multicast_list function is > commented out and I can't figure out why. > I checked the code, removed the comments and tried it, and multicast > seemed to work properly. > > What am I missing? > Could someone explain me why this is commented out? The reason is because the arch/ppc/8260_io/* is deprecated by drivers/net/fs_enet, hence people switched to use it... -- Sincerely, Vitaly
cpm_uart_port_map not initialised before serial console setup
On Thu, 13 Jul 2006 16:55:35 +0200 Laurent Pinchart wrote: > Hi everybody, > > while trying to use SCC1 as a serial console, I found a bug in the cpm_uart > driver. > > The cpm_uart_port_map table is initialised by cpm_uart_count() which is > called > in cpm_uart_init() at module_init() time. cpm_uart_console_setup(), called at > console_initcall() time, accesses cpm_uart_port_map, leading to a crash when > using any serial port except SMC1 as the serial console. > > I attached a very simple patch to fix the problem, but it might be subject to > race conditions. Could anyone familiar with the cpm_uart driver have a look > at it ? > Ugh, you're right. But I think we need to finally get rid of the stupid count/port_map creation based on #ifdefs. I'll have a look at it immediately as time permits -- Sincerely, Vitaly
block after "io scheduler noop registered"
On Wed, 28 Jun 2006 16:48:34 +0200 "morelli.gab" wrote: > Hi All, > > i,m upgrading the linux kernel 2.4 from 2.6, during the phase of restart on > my card the system blocks on message "io scheduler noop registered". > the board mount MPC875 processor > > > ... > Serial: CPM driver $Revision: 0.01 $ > ttyCPM0 at MMIO 0xfa80 (irq = 20) is a CPM UART > ttyCPM1 at MMIO 0xfa90 (irq = 19) is a CPM UART > io scheduler noop registered You should add the proper cpm uart initialization bits to the board-specific code, as say 885ads does (ppc/platforms/mpc885ads_setup.c). What experienced is uart misconfiguration which alters pins in a way the console doesn't like very much. -- Sincerely, Vitaly
Reg RISC timers in MPC 8260
?? Tue, 27 Jun 2006 04:31:37 -0700 (PDT) Jagan : > Hi all > > We have a requirement of running a periodic timer for > 5 millisecond using RISC timers in CPM module of > MPC8260. The OS is monta vista linux and target is > MPC8260 I have written a sample code to start a > periodic timer using MPC8260. > > But it hangs when SET TIMER command is issued to the > CPCR register. The cross compiler we r using is > ppc_82xx-gcc. > > Can anyone pls help me in getting this right ? > > I am pasting the code here > -- > /*Start of code snippet ignoring the header files */ > cpm8xx_t *cpmp; > > volatile immap_t *immap = (immap_t *)IMAP_ADDR; > hrmmm, isn't 8260 CPM2? This is 8xx immap, that is _really_ different from what 8260 has... Grep for cpm2_immr and look into asm/immap_cpm2.h for details. -Vitaly
MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
On Mon, 26 Jun 2006 12:48:27 +0200 Florian Boelstler wrote: > Hi, > > I am currently working on a MPC8548-based development system. > Linux kernel version is 2.6.11 with patches delivered from Freescale > (BSP MPC8548CDS 02/24/2006). > > Kernel configuration contains a warning message for CONFIG_PEX: > "This requires hardware modification to work correctly if your CPU > version < 2.0 and will break the PCI bus. [...]" > > I was wondering whether enabling PCIe makes PCI bus functionality > unusable at all (including kernel functionality for detecting devices > behind a transparent PCI-to-PCI bridge). > IIRC,yes. > Our setup connects a transparent PLX8516 PCI-to-PCI bridge to the PCIe > port of the MPC8548 daughter board. Behind that bridge is another PCIe > capable device. > MPC8548 is configured to run as PCIe host mode. > > When trying to lookup the PCIe devices using lspci I can only see the > PPC itself and the bridge. > However I cannot see the device(s) behind the bridge. > That's highly depends on silicon and Arcadia rev. you are using. There are some other details about PCI-XP, but to inquire the certain information, you should contact FSL support. > Is there another method for detecting PCI(e) devices? > Is "BSP MPC8548CDS 02/24/2006" the latest version corresponding to that > hardware? > From what I know, yes, 2/24 is the latest. But you'll need some tricks in order to utilize PCI-xp... -- Sincerely, Vitaly
[PATCH 1/3] PAL: Support of the fixed PHY
?? Wed, 21 Jun 2006 22:48:27 +0200
Michael Buesch :
> On Wednesday 21 June 2006 18:09, Vitaly Bordug wrote:
>
> > +static int fixed_mdio_update_regs(struct fixed_info *fixed)
> > +{
> > + u16 *regs = fixed->regs;
> > + u16 bmsr = 0;
> > + u16 bmcr = 0;
> > +
> > + if(!regs) {
> > + printk(KERN_ERR "%s: regs not set up",
> > __FUNCTION__);
> > + return -1;
>
> -EINVAL perhaps?
>
OK
> > +static int fixed_mdio_register_device(int number, int speed, int
> > duplex) +{
> > + struct mii_bus *new_bus;
> > + struct fixed_info *fixed;
> > + struct phy_device *phydev;
> > + int err = 0;
> > +
> > + struct device* dev = kzalloc(sizeof(struct device),
> > GFP_KERNEL); +
> > + if (NULL == dev)
> > + return -EINVAL;
>
> -ENOMEM here.
OK
[snip]
> > + /*
> > + the mdio bus has phy_id match... In order not to do it
> > + artificially, we are binding the driver here by hand;
> > + it will be the same
> > + for all the fixed phys anyway.
> > +*/
> > + down_write(&phydev->dev.bus->subsys.rwsem);
> > +
> > + phydev->dev.driver = &fixed_mdio_driver.driver;
> > +
> > + err = phydev->dev.driver->probe(&phydev->dev);
> > + if(err < 0) {
> > + printk(KERN_ERR "Phy %s: problems with fixed
> > driver\n",
> > + phydev->dev.bus_id);
> > + up_write(&phydev->dev.bus->subsys.rwsem);
> > + goto bus_register_fail;
>
> Probably need some additional error unwinding code.
> Of doesn't device_register() have to be reverted?
> What about phy_device_create()?
>
Definitely. Moreover, as I noticed now, phy_driver_register also has to
be error-handled and such. Will fix/update and resubmit.
Thanks for the feedback.
--
Sincerely, Vitaly
MPC8560 CPM drivers
?? Wed, 21 Jun 2006 15:57:14 -0400 "Scott Coulter" : > > Hi everyone, > > I have a MPC8560 driver availability question that perhaps someone can > answer. > > My company has built a board for a customer with an MPC8560 on it. > The board has been designed so that the CPM can support several I/O > interfaces using an external PMC-Sierra COMET device. Originally, the > customer was planning to use VxWorks and port an existing pSOS driver > that was written for the CPM on the MPC8260. They are now inquiring > about linux driver support for the CPM. I currently have version > 2.6.15 of the kernel running on the board. > > Does anyone know what exists as far as driver support for the CPM on > the 8560? Specifically, the customer is looking to run the CPM with > the following interfaces: > > TDM T1 > TDM E1 > ATM T1 > ATM E1 > > If there is currently no support, does anyone know if there are any > drivers in the works? > I'm aware of http://mpc8260sar.sourceforge.net and http://atm8260.sourceforge.net, that utilize ATM from CPM (cpm1 and cpm2), but dunno if it is definitely the thing you are looking for... > Thanks in advance, > > Scott > > > > > ___ > > Scott N. Coulter > Senior Software Engineer > > Cyclone Microsystems > 370 James Street Phone: 203.786.5536 ext. 118 > New Haven, CT 06513-3051 Email: scott.coulter at cyclone.com > U.S.A.Web:http://www.cyclone.com > ___ > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > >
[PATCH 3/3] FS_ENET: phydev pointer may be dereferenced without NULL check
When interface is down, phy is "disconnected" from the bus and phydev is NULL.
But ethtool may try to get/set phy regs even at that time, which results in
NULL pointer dereference and OOPS hereby.
Signed-off-by: Vitaly Bordug
---
drivers/net/fs_enet/fs_enet-main.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index 302ecaa..e475e22 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -882,12 +882,16 @@ static void fs_get_regs(struct net_devic
static int fs_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
struct fs_enet_private *fep = netdev_priv(dev);
+ if (!fep->phydev)
+ return -EINVAL;
return phy_ethtool_gset(fep->phydev, cmd);
}
static int fs_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
struct fs_enet_private *fep = netdev_priv(dev);
+ if (!fep->phydev)
+ return -EINVAL;
phy_ethtool_sset(fep->phydev, cmd);
return 0;
}
[PATCH 2/3] FS_ENET: use PAL for mii management
This patch should update the fs_enet infrastructure to utilize
Phy Abstraction Layer subsystem. Inside there are generic driver rehaul,
board-specific portion to respect driver changes (for 8272ads and 866ads).
Signed-off-by: Vitaly Bordug
---
arch/ppc/platforms/mpc8272ads_setup.c | 154 ++
arch/ppc/platforms/mpc866ads_setup.c | 192 ++--
arch/ppc/platforms/mpc885ads_setup.c | 179
arch/ppc/syslib/mpc8xx_devices.c |8 +
arch/ppc/syslib/mpc8xx_sys.c |6
arch/ppc/syslib/pq2_devices.c |5
arch/ppc/syslib/pq2_sys.c |3
drivers/net/fs_enet/Makefile |6
drivers/net/fs_enet/fec.h | 42 +++
drivers/net/fs_enet/fs_enet-main.c| 207 -
drivers/net/fs_enet/fs_enet-mii.c | 507 -
drivers/net/fs_enet/fs_enet.h | 40 ++-
drivers/net/fs_enet/mac-fcc.c | 10 -
drivers/net/fs_enet/mac-fec.c | 132 +
drivers/net/fs_enet/mac-scc.c |4
drivers/net/fs_enet/mii-bitbang.c | 448 +++--
drivers/net/fs_enet/mii-fec.c | 243
drivers/net/fs_enet/mii-fixed.c | 92 --
include/asm-ppc/mpc8260.h |1
include/asm-ppc/mpc8xx.h |1
include/linux/fs_enet_pd.h| 50 +--
21 files changed, 982 insertions(+), 1348 deletions(-)
diff --git a/arch/ppc/platforms/mpc8272ads_setup.c
b/arch/ppc/platforms/mpc8272ads_setup.c
index abb7154..2a35fe2 100644
--- a/arch/ppc/platforms/mpc8272ads_setup.c
+++ b/arch/ppc/platforms/mpc8272ads_setup.c
@@ -56,64 +56,51 @@ static struct fs_uart_platform_info mpc8
},
};
-static struct fs_mii_bus_info mii_bus_info = {
- .method = fsmii_bitbang,
- .id = 0,
- .i.bitbang = {
- .mdio_port = fsiop_portc,
- .mdio_bit = 18,
- .mdc_port = fsiop_portc,
- .mdc_bit= 19,
- .delay = 1,
- },
-};
-
-static struct fs_platform_info mpc82xx_fcc1_pdata = {
- .fs_no = fsid_fcc1,
- .cp_page= CPM_CR_FCC1_PAGE,
- .cp_block = CPM_CR_FCC1_SBLOCK,
- .clk_trx= (PC_F1RXCLK | PC_F1TXCLK),
- .clk_route = CMX1_CLK_ROUTE,
- .clk_mask = CMX1_CLK_MASK,
- .init_ioports = init_fcc1_ioports,
-
- .phy_addr = 0,
-#ifdef PHY_INTERRUPT
- .phy_irq= PHY_INTERRUPT,
-#else
- .phy_irq= -1;
-#endif
- .mem_offset = FCC1_MEM_OFFSET,
- .bus_info = &mii_bus_info,
- .rx_ring= 32,
- .tx_ring= 32,
- .rx_copybreak = 240,
- .use_napi = 0,
- .napi_weight= 17,
+static struct fs_mii_bb_platform_info m82xx_mii_bb_pdata = {
+ .mdio_dat.bit = 18,
+ .mdio_dir.bit = 18,
+ .mdc_dat.bit= 19,
+ .delay = 1,
};
-static struct fs_platform_info mpc82xx_fcc2_pdata = {
- .fs_no = fsid_fcc2,
- .cp_page= CPM_CR_FCC2_PAGE,
- .cp_block = CPM_CR_FCC2_SBLOCK,
- .clk_trx= (PC_F2RXCLK | PC_F2TXCLK),
- .clk_route = CMX2_CLK_ROUTE,
- .clk_mask = CMX2_CLK_MASK,
- .init_ioports = init_fcc2_ioports,
-
- .phy_addr = 3,
-#ifdef PHY_INTERRUPT
- .phy_irq= PHY_INTERRUPT,
-#else
- .phy_irq= -1;
-#endif
- .mem_offset = FCC2_MEM_OFFSET,
- .bus_info = &mii_bus_info,
- .rx_ring= 32,
- .tx_ring= 32,
- .rx_copybreak = 240,
- .use_napi = 0,
- .napi_weight= 17,
+static struct fs_platform_info mpc82xx_enet_pdata[] = {
+ [fsid_fcc1] = {
+ .fs_no = fsid_fcc1,
+ .cp_page= CPM_CR_FCC1_PAGE,
+ .cp_block = CPM_CR_FCC1_SBLOCK,
+
+ .clk_trx= (PC_F1RXCLK | PC_F1TXCLK),
+ .clk_route = CMX1_CLK_ROUTE,
+ .clk_mask = CMX1_CLK_MASK,
+ .init_ioports = init_fcc1_ioports,
+
+ .mem_offset = FCC1_MEM_OFFSET,
+
+ .rx_ring= 32,
+ .tx_ring= 32,
+ .rx_copybreak = 240,
+ .use_napi = 0,
+ .napi_weight= 17,
+ .bus_id = "0:00",
+ },
+ [fsid_fcc2] = {
+ .fs_no = fsid_fcc2,
+ .cp_page= CPM_CR_FCC2_PAGE,
+ .cp_block = CPM_CR_FCC2_SBLOCK,
+ .clk_trx= (PC_F2RXCLK | PC_F2TXCLK),
+ .clk_route = CMX2_CLK_ROUTE,
+ .clk_mask = CMX2_CLK_MASK,
+ .init_ioports = init_fcc2_ioports,
+
+ .mem_offset = FCC2_MEM_OFFSET,
+
+ .r
[PATCH 1/3] PAL: Support of the fixed PHY
This makes it possible for HW PHY-less boards to utilize PAL goodies.
Generic routines to connect to fixed PHY are provided, as well as ability
to specify software callback that fills up link, speed, etc. information
into PHY descriptor (the latter feature not tested so far).
Signed-off-by: Vitaly Bordug
---
drivers/net/phy/Kconfig | 17 ++
drivers/net/phy/fixed.c | 385 ++
drivers/net/phy/phy_device.c | 51 +++---
include/linux/phy.h |1
4 files changed, 433 insertions(+), 21 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index cda3e53..425be84 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -51,5 +51,22 @@ config SMSC_PHY
---help---
Currently supports the LAN83C185 PHY
+config FIXED_PHY
+ tristate "Drivers for PHY emulation on fixed speed/link"
+ depends on PHYLIB
+ ---help---
+ Adds the driver to PHY layer to cover the boards that do not have any
PHY bound,
+ but with the ability to manipulate with speed/link in software. The
relavant MII
+ speed/duplex parameters could be effectively handled in
user-specified fuction.
+ Currently tested with mpc866ads.
+
+config FIXED_MII_10_FDX
+ bool "Emulation for 10M Fdx fixed PHY behavior"
+ depends on FIXED_PHY
+
+config FIXED_MII_100_FDX
+ bool "Emulation for 100M Fdx fixed PHY behavior"
+ depends on FIXED_PHY
+
endmenu
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
new file mode 100644
index 000..0360f65
--- /dev/null
+++ b/drivers/net/phy/fixed.c
@@ -0,0 +1,385 @@
+/*
+ * drivers/net/phy/fixed.c
+ *
+ * Driver for fixed PHYs, when transceiver is able to operate in one fixed
mode.
+ *
+ * Author: Vitaly Bordug
+ *
+ * Copyright (c) 2006 MontaVista Software, Inc.
+ *
+ * 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
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define MII_REGS_NUM 7
+
+/*
+The idea is to emulate normal phy behavior by responding with
+pre-defined values to mii BMCR read, so that read_status hook could
+take all the needed info.
+*/
+
+struct fixed_phy_status {
+ u8 link;
+ u16 speed;
+ u8 duplex;
+};
+
+/*-
+ * Private information hoder for mii_bus
+
*-*/
+struct fixed_info {
+ u16 *regs;
+ u8 regs_num;
+ struct fixed_phy_status phy_status;
+ struct phy_device *phydev; /* pointer to the container */
+ /* link & speed cb */
+ int(*link_update)(struct net_device*, struct fixed_phy_status*);
+
+};
+
+/*
+This is made global to free all the allocations on _exit call.
+Looks a bit odd, seems the only way.
+*/
+static struct fixed_info *fixed_ptr;
+
+/*-
+ * If something weird is required to be done with link/speed,
+ * network driver is able to assign a function to implement this.
+ * May be useful for PHY's that need to be software-driven.
+
*-*/
+int fixed_mdio_set_link_update(struct phy_device* phydev,
+ int(*link_update)(struct net_device*, struct fixed_phy_status*))
+{
+ struct fixed_info *fixed;
+
+ if(link_update == NULL)
+ return -EINVAL;
+
+ if(phydev) {
+ if(phydev->bus) {
+ fixed = phydev->bus->priv;
+ fixed->link_update = link_update;
+ return 0;
+ }
+ }
+ return -EINVAL;
+}
+EXPORT_SYMBOL(fixed_mdio_set_link_update);
+
+/*-
+ * This is used for updating internal mii regs from the status
+
*-*/
+static int fixed_mdio_update_regs(struct fixed_info *fixed)
+{
+ u16 *regs = fixed->regs;
+ u16 bmsr = 0;
+ u16 bmcr = 0;
+
+ if(!regs) {
+ printk(KERN_ERR "%s: regs not set up", __FUNCTION__);
+ return -1;
+ }
+
+ if(fixed->phy_status.link)
+ bmsr |= BMSR_LSTATUS;
+
+ if(fixed->phy_status.duplex) {
+ bmcr |= BMCR_FULLDPLX;
+
+
[PATCH 2/3] FS_ENET: use PAL for mii management
?? Wed, 21 Jun 2006 09:20:36 +0200
Gerhard Jaeger :
> Hi,
>
> On Tuesday 20 June 2006 16:58, Vitaly Bordug wrote:
> >
> > This patch should update the fs_enet infrastructure to utilize
> > Phy Abstraction Layer subsystem. Inside there are generic driver
> > rehaul, board-specific portion to respect driver changes (for
> > 8272ads and 866ads).
> >
> > Signed-off-by: Vitaly Bordug
> > ---
> >
> > arch/ppc/platforms/mpc8272ads_setup.c | 154 ++
> > arch/ppc/platforms/mpc866ads_setup.c | 192 ++--
> > arch/ppc/platforms/mpc885ads_setup.c | 179
> > arch/ppc/syslib/mpc8xx_devices.c |8 +
> > arch/ppc/syslib/mpc8xx_sys.c |6
> > arch/ppc/syslib/pq2_devices.c |5
> > arch/ppc/syslib/pq2_sys.c |3
> > drivers/net/fs_enet/Makefile |6
> > drivers/net/fs_enet/fec.h | 42 +++
> > drivers/net/fs_enet/fs_enet-main.c| 207 -
> > drivers/net/fs_enet/fs_enet-mii.c | 507
> > -
> > drivers/net/fs_enet/fs_enet.h | 40 ++-
> > drivers/net/fs_enet/mac-fcc.c | 10 -
> > drivers/net/fs_enet/mac-fec.c | 132 +
> > drivers/net/fs_enet/mac-scc.c |4
> > drivers/net/fs_enet/mii-bitbang.c | 384
> > +++-- drivers/net/fs_enet/mii-fec.c |
> > 243 drivers/net/fs_enet/mii-fixed.c | 92
> > -- include/asm-ppc/mpc8260.h |1
> > include/asm-ppc/mpc8xx.h |1
> > include/linux/fs_enet_pd.h| 50 +-- 21 files changed,
> > 983 insertions(+), 1283 deletions(-)
>
> [SNIPSNAP]
> > diff --git a/drivers/net/fs_enet/mii-bitbang.c
> > b/drivers/net/fs_enet/mii-bitbang.c index 24a5e2e..145bf4c 100644
> > --- a/drivers/net/fs_enet/mii-bitbang.c
> > +++ b/drivers/net/fs_enet/mii-bitbang.c
> > @@ -34,6 +34,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -41,6 +42,7 @@
> >
> > #include "fs_enet.h"
> >
> > +
> > #ifdef CONFIG_8xx
> > static int bitbang_prep_bit(u8 **dirp, u8 **datp, u8 *mskp, int
> > port, int bit) {
> > @@ -106,64 +108,25 @@ static int bitbang_prep_bit(u8 **dirp, u
> > }
> > #endif
> >
> > -#ifdef CONFIG_8260
> > -static int bitbang_prep_bit(u8 **dirp, u8 **datp, u8 *mskp, int
> > port, int bit) +static int bitbang_prep_bit(u8 **datp, u8 *mskp,
> > + struct fs_mii_bit *mii_bit)
>
> is it possible, that in case of CONFIG_8xx you'll have two times this
> bitbang_prep_bit() function?
>
Hmm, yes, thanks for pointing that out. The problem is in other
thing though - the bitbang stuff got unified so there should be no
board-specific ifdefs like those.
This issue must have missed the cleanup, I'll fix and redo the patches.
--
Sincerely, Vitaly
[PATCH 3/3] FS_ENET: phydev pointer may be dereferenced without NULL check
When interface is down, phy is "disconnected" from the bus and phydev is NULL.
But ethtool may try to get/set phy regs even at that time, which results in
NULL pointer dereference and OOPS hereby.
Signed-off-by: Vitaly Bordug
---
drivers/net/fs_enet/fs_enet-main.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index 302ecaa..e475e22 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -882,12 +882,16 @@ static void fs_get_regs(struct net_devic
static int fs_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
struct fs_enet_private *fep = netdev_priv(dev);
+ if (!fep->phydev)
+ return -EINVAL;
return phy_ethtool_gset(fep->phydev, cmd);
}
static int fs_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
struct fs_enet_private *fep = netdev_priv(dev);
+ if (!fep->phydev)
+ return -EINVAL;
phy_ethtool_sset(fep->phydev, cmd);
return 0;
}
[PATCH 2/3] FS_ENET: use PAL for mii management
This patch should update the fs_enet infrastructure to utilize
Phy Abstraction Layer subsystem. Inside there are generic driver rehaul,
board-specific portion to respect driver changes (for 8272ads and 866ads).
Signed-off-by: Vitaly Bordug
---
arch/ppc/platforms/mpc8272ads_setup.c | 154 ++
arch/ppc/platforms/mpc866ads_setup.c | 192 ++--
arch/ppc/platforms/mpc885ads_setup.c | 179
arch/ppc/syslib/mpc8xx_devices.c |8 +
arch/ppc/syslib/mpc8xx_sys.c |6
arch/ppc/syslib/pq2_devices.c |5
arch/ppc/syslib/pq2_sys.c |3
drivers/net/fs_enet/Makefile |6
drivers/net/fs_enet/fec.h | 42 +++
drivers/net/fs_enet/fs_enet-main.c| 207 -
drivers/net/fs_enet/fs_enet-mii.c | 507 -
drivers/net/fs_enet/fs_enet.h | 40 ++-
drivers/net/fs_enet/mac-fcc.c | 10 -
drivers/net/fs_enet/mac-fec.c | 132 +
drivers/net/fs_enet/mac-scc.c |4
drivers/net/fs_enet/mii-bitbang.c | 384 +++--
drivers/net/fs_enet/mii-fec.c | 243
drivers/net/fs_enet/mii-fixed.c | 92 --
include/asm-ppc/mpc8260.h |1
include/asm-ppc/mpc8xx.h |1
include/linux/fs_enet_pd.h| 50 +--
21 files changed, 983 insertions(+), 1283 deletions(-)
diff --git a/arch/ppc/platforms/mpc8272ads_setup.c
b/arch/ppc/platforms/mpc8272ads_setup.c
index abb7154..2a35fe2 100644
--- a/arch/ppc/platforms/mpc8272ads_setup.c
+++ b/arch/ppc/platforms/mpc8272ads_setup.c
@@ -56,64 +56,51 @@ static struct fs_uart_platform_info mpc8
},
};
-static struct fs_mii_bus_info mii_bus_info = {
- .method = fsmii_bitbang,
- .id = 0,
- .i.bitbang = {
- .mdio_port = fsiop_portc,
- .mdio_bit = 18,
- .mdc_port = fsiop_portc,
- .mdc_bit= 19,
- .delay = 1,
- },
-};
-
-static struct fs_platform_info mpc82xx_fcc1_pdata = {
- .fs_no = fsid_fcc1,
- .cp_page= CPM_CR_FCC1_PAGE,
- .cp_block = CPM_CR_FCC1_SBLOCK,
- .clk_trx= (PC_F1RXCLK | PC_F1TXCLK),
- .clk_route = CMX1_CLK_ROUTE,
- .clk_mask = CMX1_CLK_MASK,
- .init_ioports = init_fcc1_ioports,
-
- .phy_addr = 0,
-#ifdef PHY_INTERRUPT
- .phy_irq= PHY_INTERRUPT,
-#else
- .phy_irq= -1;
-#endif
- .mem_offset = FCC1_MEM_OFFSET,
- .bus_info = &mii_bus_info,
- .rx_ring= 32,
- .tx_ring= 32,
- .rx_copybreak = 240,
- .use_napi = 0,
- .napi_weight= 17,
+static struct fs_mii_bb_platform_info m82xx_mii_bb_pdata = {
+ .mdio_dat.bit = 18,
+ .mdio_dir.bit = 18,
+ .mdc_dat.bit= 19,
+ .delay = 1,
};
-static struct fs_platform_info mpc82xx_fcc2_pdata = {
- .fs_no = fsid_fcc2,
- .cp_page= CPM_CR_FCC2_PAGE,
- .cp_block = CPM_CR_FCC2_SBLOCK,
- .clk_trx= (PC_F2RXCLK | PC_F2TXCLK),
- .clk_route = CMX2_CLK_ROUTE,
- .clk_mask = CMX2_CLK_MASK,
- .init_ioports = init_fcc2_ioports,
-
- .phy_addr = 3,
-#ifdef PHY_INTERRUPT
- .phy_irq= PHY_INTERRUPT,
-#else
- .phy_irq= -1;
-#endif
- .mem_offset = FCC2_MEM_OFFSET,
- .bus_info = &mii_bus_info,
- .rx_ring= 32,
- .tx_ring= 32,
- .rx_copybreak = 240,
- .use_napi = 0,
- .napi_weight= 17,
+static struct fs_platform_info mpc82xx_enet_pdata[] = {
+ [fsid_fcc1] = {
+ .fs_no = fsid_fcc1,
+ .cp_page= CPM_CR_FCC1_PAGE,
+ .cp_block = CPM_CR_FCC1_SBLOCK,
+
+ .clk_trx= (PC_F1RXCLK | PC_F1TXCLK),
+ .clk_route = CMX1_CLK_ROUTE,
+ .clk_mask = CMX1_CLK_MASK,
+ .init_ioports = init_fcc1_ioports,
+
+ .mem_offset = FCC1_MEM_OFFSET,
+
+ .rx_ring= 32,
+ .tx_ring= 32,
+ .rx_copybreak = 240,
+ .use_napi = 0,
+ .napi_weight= 17,
+ .bus_id = "0:00",
+ },
+ [fsid_fcc2] = {
+ .fs_no = fsid_fcc2,
+ .cp_page= CPM_CR_FCC2_PAGE,
+ .cp_block = CPM_CR_FCC2_SBLOCK,
+ .clk_trx= (PC_F2RXCLK | PC_F2TXCLK),
+ .clk_route = CMX2_CLK_ROUTE,
+ .clk_mask = CMX2_CLK_MASK,
+ .init_ioports = init_fcc2_ioports,
+
+ .mem_offset = FCC2_MEM_OFFSET,
+
+ .r
[PATCH 1/3] PAL: Support of the fixed PHY
This makes it possible for HW PHY-less boards to utilize PAL goodies.
Generic routines to connect to fixed PHY are provided, as well as ability
to specify software callback that fills up link, speed, etc. information
into PHY descriptor (the latter feature not tested so far).
Signed-off-by: Vitaly Bordug
---
drivers/net/phy/Kconfig | 17 ++
drivers/net/phy/fixed.c | 385 ++
drivers/net/phy/phy_device.c | 51 +++---
include/linux/phy.h |1
4 files changed, 433 insertions(+), 21 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index cda3e53..425be84 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -51,5 +51,22 @@ config SMSC_PHY
---help---
Currently supports the LAN83C185 PHY
+config FIXED_PHY
+ tristate "Drivers for PHY emulation on fixed speed/link"
+ depends on PHYLIB
+ ---help---
+ Adds the driver to PHY layer to cover the boards that do not have any
PHY bound,
+ but with the ability to manipulate with speed/link in software. The
relavant MII
+ speed/duplex parameters could be effectively handled in
user-specified fuction.
+ Currently tested with mpc866ads.
+
+config FIXED_MII_10_FDX
+ bool "Emulation for 10M Fdx fixed PHY behavior"
+ depends on FIXED_PHY
+
+config FIXED_MII_100_FDX
+ bool "Emulation for 100M Fdx fixed PHY behavior"
+ depends on FIXED_PHY
+
endmenu
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
new file mode 100644
index 000..0360f65
--- /dev/null
+++ b/drivers/net/phy/fixed.c
@@ -0,0 +1,385 @@
+/*
+ * drivers/net/phy/fixed.c
+ *
+ * Driver for fixed PHYs, when transceiver is able to operate in one fixed
mode.
+ *
+ * Author: Vitaly Bordug
+ *
+ * Copyright (c) 2006 MontaVista Software, Inc.
+ *
+ * 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
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define MII_REGS_NUM 7
+
+/*
+The idea is to emulate normal phy behavior by responding with
+pre-defined values to mii BMCR read, so that read_status hook could
+take all the needed info.
+*/
+
+struct fixed_phy_status {
+ u8 link;
+ u16 speed;
+ u8 duplex;
+};
+
+/*-
+ * Private information hoder for mii_bus
+
*-*/
+struct fixed_info {
+ u16 *regs;
+ u8 regs_num;
+ struct fixed_phy_status phy_status;
+ struct phy_device *phydev; /* pointer to the container */
+ /* link & speed cb */
+ int(*link_update)(struct net_device*, struct fixed_phy_status*);
+
+};
+
+/*
+This is made global to free all the allocations on _exit call.
+Looks a bit odd, seems the only way.
+*/
+static struct fixed_info *fixed_ptr;
+
+/*-
+ * If something weird is required to be done with link/speed,
+ * network driver is able to assign a function to implement this.
+ * May be useful for PHY's that need to be software-driven.
+
*-*/
+int fixed_mdio_set_link_update(struct phy_device* phydev,
+ int(*link_update)(struct net_device*, struct fixed_phy_status*))
+{
+ struct fixed_info *fixed;
+
+ if(link_update == NULL)
+ return -EINVAL;
+
+ if(phydev) {
+ if(phydev->bus) {
+ fixed = phydev->bus->priv;
+ fixed->link_update = link_update;
+ return 0;
+ }
+ }
+ return -EINVAL;
+}
+EXPORT_SYMBOL(fixed_mdio_set_link_update);
+
+/*-
+ * This is used for updating internal mii regs from the status
+
*-*/
+static int fixed_mdio_update_regs(struct fixed_info *fixed)
+{
+ u16 *regs = fixed->regs;
+ u16 bmsr = 0;
+ u16 bmcr = 0;
+
+ if(!regs) {
+ printk(KERN_ERR "%s: regs not set up", __FUNCTION__);
+ return -1;
+ }
+
+ if(fixed->phy_status.link)
+ bmsr |= BMSR_LSTATUS;
+
+ if(fixed->phy_status.duplex) {
+ bmcr |= BMCR_FULLDPLX;
+
+
Binding FCC interfaces to device names in reverse order
On Thu, 15 Jun 2006 13:59:02 +0200 Laurent Pinchart wrote: > Hello, > > I'm trying to change the order in which the MPC8248 FCC devices are bound to > network interface names. > > The current behaviour is to handle FCC1, FCC2 and FCC3 in that order. FCC1 is > thus mapped to eth0 and FCC2 to eth1 (FCC3 is unused in my design). > > For some reason I'd like to map FCC2 to eth0 and FCC1 to eth1. Interface > names > are allocated as devices are registered, so I thought I could change the > detection order by modifying the ppc_sys_platform_devices array: > > ppc_sys_platform_devices[MPC82xx_CPM_FCC1].id = 2; > ppc_sys_platform_devices[MPC82xx_CPM_FCC2].id = 1; > > FCC devices detection is indeed reversed, and FCC2 is mapped to eth0. > Plugging > a cable into the FCC2 socket prints a message referencing eth0, and ifconfig > confirms that eth0 is running. > > Unfortunately, that's where things stop working. I can't ping FCC1 or FCC2, > no > data is received by the kernel. > > Does anyone know why changing the device ids breaks the fs_enet driver ? Obviously, because board-specific platform_data fixup use that id field to detect what soc device is that - fcc1 or fcc2 this case. So the phy's will be wrong-assigned, as well as other stuff. To change order pdevs are registered, you may try to disable all the fccs at the startup, and then enable them after ppc_sys_init, or just shoot enable-disable seq (this was't tested at all, but supposed to work). > > Laurent Pinchart > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > -- Sincerely, Vitaly
CPM_UART should allocate DPRAM for SMCx parameter RAM on MPC82xx
On Wed, 7 Jun 2006 15:39:57 +0200 Laurent Pinchart wrote: > > > the move to platform devices introduced a bug in the CPM_UART SMC driver. > > > > > > Unlike SCC and FCC, the SMC parameter ram is not at a fixed location. A > > > pointer to the parameter ram is instead stored at PROFF_SMCx_BASE. > > > > > > The SMC platform device resources (in arch/ppc/syslib/pq2_devices.c) > > > reserves the memory resource PROFF_SMCx_BASE - PROFF_SMCx_BASE+1. The CPM > > > UART driver considers that value as the SMC parameter ram offset. It > > > should instead allocate 64 bytes (on a 64 bytes boundary) of DPRAM for > > > its parameter ram, and store the offset at PROFF_SMCx_BASE. > > > > > > I'm not sure how to fix the problem as it seems that the platform device > > > support is not complete yet (cpm_uart_init_portdesc is still used to > > > initialize the console). A possible workaround is to set the pram > > > resource to 0x-0x003f and 0x0040-0x007f instead of 0x87fc-0x87fd and > > > 0x88fc-0x88fd for SMC1 and SMC2. This will not work if > > > cpm_uart_init_portdesc is not called. > > > > No, pdev support for cpm uart is complete and works for every board I have > > handy, both 8xx and 82xx. 8xx use SMC stuff and are ok, so I suppose the > > issue got inside because this is first case we head with combination of > > pq2/smc. > > > > init_portedsc is called in compatibility mode only, when driver was > > unable to locate platform device (early_uart_get_pdev call). The > > offsets are definitely odd - we should count the proper values (as it > > was done for 8xx - offset from immr where pram will be located that > > is). So, pq2_devices should be fixed, as well as bsp code should > > provide early_uart_get_pdev call (see 8272 as reference). > > From my understanding, SMC pram should be allocated, and its offset should be > stored at PROFF_SMCx_BASE. pq2_devices returns the PRFF_SMCx_BASE resource, > and the CPM UART driver should use cpm_dpalloc to allocate the parameter RAM. > Is that right ? If so, where should I allocate memory (and where should I > free it) in the CPM UART driver ? > As I said, SMC offsets relative to pram things are screwed for PQ2. That needs to be fixed. It is assumed, that for each SMC ready-for-use offset should be defined in pram resource (as for 8xx). There is no need to dpalloc/dpfree because the idea is that pram thing should be fixed to prevent confusion. So the odd offset for SMC devices in pq2_devices.c should be replaced with correct values (which should be dpram_start+PROFF_SMCx - have a look at 8xx as reference) -- Sincerely, Vitaly
CPM_UART should allocate DPRAM for SMCx parameter RAM on MPC82xx
On Wed, 7 Jun 2006 14:34:08 +0200 Laurent Pinchart wrote: > Hi everybody, > > the move to platform devices introduced a bug in the CPM_UART SMC driver. > > Unlike SCC and FCC, the SMC parameter ram is not at a fixed location. A > pointer to the parameter ram is instead stored at PROFF_SMCx_BASE. > > The SMC platform device resources (in arch/ppc/syslib/pq2_devices.c) reserves > the memory resource PROFF_SMCx_BASE - PROFF_SMCx_BASE+1. The CPM UART driver > considers that value as the SMC parameter ram offset. It should instead > allocate 64 bytes (on a 64 bytes boundary) of DPRAM for its parameter ram, > and store the offset at PROFF_SMCx_BASE. > > I'm not sure how to fix the problem as it seems that the platform device > support is not complete yet (cpm_uart_init_portdesc is still used to > initialize the console). A possible workaround is to set the pram resource to > 0x-0x003f and 0x0040-0x007f instead of 0x87fc-0x87fd and 0x88fc-0x88fd > for SMC1 and SMC2. This will not work if cpm_uart_init_portdesc is not > called. > No, pdev support for cpm uart is complete and works for every board I have handy, both 8xx and 82xx. 8xx use SMC stuff and are ok, so I suppose the issue got inside because this is first case we head with combination of pq2/smc. init_portedsc is called in compatibility mode only, when driver was unable to locate platform device (early_uart_get_pdev call). The offsets are definitely odd - we should count the proper values (as it was done for 8xx - offset from immr where pram will be located that is). So, pq2_devices should be fixed, as well as bsp code should provide early_uart_get_pdev call (see 8272 as reference). -- Sincerely, Vitaly
fs_enet segfaults when adding network interface to bridge
On Tue, 30 May 2006 16:54:42 -0500 Andy Fleming wrote: > > On May 30, 2006, at 08:39, Laurent Pinchart wrote: > > >>> Hi everybody, > >>> > >>> I ran into a segfault in the fs_enet driver when adding the > >>> network interface to an ethernet bridge. This only happens when > >>> the interface is > >>> down. > >>> > >>> - Kernel version - > >>> Linux tbox-cp11 2.6.17-rc3-g7f02f290-dirty #549 Tue May 30 > >>> 13:25:37 CEST > >>> 2006 ppc unknown > >>> (from main linux-2.6 git repository) > >>> - End of kernel version - > >>> > >>> - Oops report - > >>> Oops: kernel access of bad area, sig: 11 [#1] > >>> NIP: C0109884 LR: C010D420 CTR: > >>> REGS: c027d7f0 TRAP: 0300 Tainted: P (2.6.17-rc3- > >>> g7f02f290-dirty) > >>> MSR: 9032 CR: 24000222 XER: > >>> DAR: 0140, DSISR: 2000 > >>> TASK = c0851090[42] 'brctl' THREAD: c027c000 > >>> GPR00: C010D414 C027D8A0 C0851090 C027D8D0 > >>> F0A0 > >>> EFFF GPR08: C026E380 C021 C023 C021 > >>> 1001D150 > >>> 00FFE000 0001 GPR16: 007FFF00 7FDD0AC0 > >>> > >>> 10072C94 7FDD0AD8 10072CA4 GPR24: 1A48 > >>> C027D8D0 > >>> C027D8D0 C08A1A60 C027DC50 C08A1800 NIP [C0109884] > >>> phy_ethtool_gset+0x0/0x48 > >>> LR [C010D420] fs_get_settings+0x34/0x48 > >>> Call Trace: > >>> [C027D8A0] [C010D414] fs_get_settings+0x28/0x48 (unreliable) > >>> [C027D8C0] [C013DDC0] dev_ethtool+0x9bc/0x13c8 > >>> [C027DC40] [C018CBC0] port_cost+0x58/0x108 > >>> [C027DCB0] [C018D3E8] br_add_if+0x174/0x2f4 > >>> [C027DCE0] [C018D9AC] add_del_if+0x94/0x98 > >>> [C027DD00] [C018DD68] br_dev_ioctl+0x70/0xae4 > >>> [C027DE00] [C013B42C] dev_ifsioc+0x17c/0x404 > >>> [C027DE20] [C013BA4C] dev_ioctl+0x398/0x4e8 > >>> [C027DEB0] [C012EEFC] sock_ioctl+0x154/0x220 > >>> [C027DEE0] [C0067164] do_ioctl+0x88/0x9c > >>> [C027DEF0] [C0067230] vfs_ioctl+0xb8/0x3f0 > >>> [C027DF10] [C00675A8] sys_ioctl+0x40/0x74 > >>> [C027DF40] [C00040E0] ret_from_syscall+0x0/0x38 > >>> Instruction dump: > >>> 7c0803a6 4e800020 2f80 409eff78 4bb8 8804000e 2b81 > >>> 40bdff70 > >>> 3860ffea 4bd4 61200040 4b84 <81230140> 91240004 80030144 > >>> 90040008 > >>> - End of oops report - > >>> > >>> - Source lines - > >>> [C0109884] phy_ethtool_gset+0x0/0x48 (drivers/net/phy/phy.c:290) > >>> [C010D414] fs_get_settings+0x28/0x48 > >>> (drivers/net/fs_enet/fs_enet-main.c:885) [C013DDC0] > >>> dev_ethtool+0x9bc/0x13c8 (net/core/ethtool.c:122) > >>> [C018CBC0] port_cost+0x58/0x108 (net/bridge/br_if.c:54) > >>> - End of source lines - > >>> > >>> phy_ethtool_gset segfaults when trying to access phydev->supported > >>> because phydev is NULL. > >>> > >>> As I'm not familiar with the fs_enet driver, I'm looking for > >>> advices regarding what to fix and how to fix it. > >> > >> IIRC, fs_enet got bound to phydev only being ->up. So in down > >> state, phydev > >> may be either null, or last assigned (need to have a look into > >> source to > >> tell for certain). So what is the proper behavior from your point > >> of view? > > > > I have no idea :-) What I know is that the driver should not > > segfault when > > asked to report the port speed. Either we should return an error > > or have the > > phy device bound to fs_enet at all time. It might also be a bridge > > issue, > > maybe the bridge code should turn the interface up before reading > > its speed. > > How do other ethernet drivers proceed ? > > > Well, gianfar only invokes phy_ethtool_gset() after checking to see > that phydev is not NULL. fs_enet should do this as well. It may be > preferable to move that check into phy_ethtool_gset(). Certainly a > workable solution, though I'm inclined to feel that the PHY layer > should be able to assume that a given PHY exists. The sort of > problem also exists if you try to use ethtool to find the ring sizes > before the device has been opened. > > Anyway, the easy fix is for fs_enet to check for NULL before calling > phy_ethtool_gset(). > Andy, Thanks for pointing it out, I was just going to seek into gianfar behavior. That issue seems not the only problem - there are plenty of cases I saw, where if initially PHY got failed to be bound, fs_enet seems to be really unhappy with phydev == NULL and direct dereferences of the latter. I'll try to address that stuff as time permits... -Vitaly
[SOLVED] LXT973 support (dual PHY with single MDIO)
On Tue, 30 May 2006 11:28:48 +0200 Laurent Pinchart wrote: > Hi, > > once again, posting to a mailing list helped me solving my problem. It should > have been obvious that the MDIO bus is really a bus, and can as such support > several devices. The issue was that the drivers/net/fs_enet driver set > bus->phy_mask to ~0x9, and the LXT973 uses addresses 0 and 1. Address 1 thus > never got probed. What's the reason for probing addresses 0 and 3 only ? The reason is obvious: bitbang read of PHY id with not-existent PHY, does not return expected (0, iirc), that confuse mdio bus device-driver bound (it assumes error and returns -1), and prevents from probing other phys. So, as that seems to be a "feature" on CPM2 only, we are working that around specifying phy_mask to prevent probing inexistent phys w/over bitbang thing. -- Sincerely, Vitaly
fs_enet segfaults when adding network interface to bridge
On Tue, 30 May 2006 13:51:11 +0200 Laurent Pinchart wrote: > Hi everybody, > > I ran into a segfault in the fs_enet driver when adding the network interface > to an ethernet bridge. This only happens when the interface is down. > > - Kernel version - > Linux tbox-cp11 2.6.17-rc3-g7f02f290-dirty #549 Tue May 30 13:25:37 CEST 2006 > ppc unknown > (from main linux-2.6 git repository) > - End of kernel version - > > - Oops report - > Oops: kernel access of bad area, sig: 11 [#1] > NIP: C0109884 LR: C010D420 CTR: > REGS: c027d7f0 TRAP: 0300 Tainted: P (2.6.17-rc3-g7f02f290-dirty) > MSR: 9032 CR: 24000222 XER: > DAR: 0140, DSISR: 2000 > TASK = c0851090[42] 'brctl' THREAD: c027c000 > GPR00: C010D414 C027D8A0 C0851090 C027D8D0 F0A0 EFFF > GPR08: C026E380 C021 C023 C021 1001D150 00FFE000 0001 > GPR16: 007FFF00 7FDD0AC0 10072C94 7FDD0AD8 10072CA4 > GPR24: 1A48 C027D8D0 C027D8D0 C08A1A60 C027DC50 C08A1800 > NIP [C0109884] phy_ethtool_gset+0x0/0x48 > LR [C010D420] fs_get_settings+0x34/0x48 > Call Trace: > [C027D8A0] [C010D414] fs_get_settings+0x28/0x48 (unreliable) > [C027D8C0] [C013DDC0] dev_ethtool+0x9bc/0x13c8 > [C027DC40] [C018CBC0] port_cost+0x58/0x108 > [C027DCB0] [C018D3E8] br_add_if+0x174/0x2f4 > [C027DCE0] [C018D9AC] add_del_if+0x94/0x98 > [C027DD00] [C018DD68] br_dev_ioctl+0x70/0xae4 > [C027DE00] [C013B42C] dev_ifsioc+0x17c/0x404 > [C027DE20] [C013BA4C] dev_ioctl+0x398/0x4e8 > [C027DEB0] [C012EEFC] sock_ioctl+0x154/0x220 > [C027DEE0] [C0067164] do_ioctl+0x88/0x9c > [C027DEF0] [C0067230] vfs_ioctl+0xb8/0x3f0 > [C027DF10] [C00675A8] sys_ioctl+0x40/0x74 > [C027DF40] [C00040E0] ret_from_syscall+0x0/0x38 > Instruction dump: > 7c0803a6 4e800020 2f80 409eff78 4bb8 8804000e 2b81 40bdff70 > 3860ffea 4bd4 61200040 4b84 <81230140> 91240004 80030144 90040008 > - End of oops report - > > - Source lines - > [C0109884] phy_ethtool_gset+0x0/0x48 (drivers/net/phy/phy.c:290) > [C010D414] fs_get_settings+0x28/0x48 (drivers/net/fs_enet/fs_enet-main.c:885) > [C013DDC0] dev_ethtool+0x9bc/0x13c8 (net/core/ethtool.c:122) > [C018CBC0] port_cost+0x58/0x108 (net/bridge/br_if.c:54) > - End of source lines - > > phy_ethtool_gset segfaults when trying to access phydev->supported because > phydev is NULL. > > As I'm not familiar with the fs_enet driver, I'm looking for advices > regarding > what to fix and how to fix it. > IIRC, fs_enet got bound to phydev only being ->up. So in down state, phydev may be either null, or last assigned (need to have a look into source to tell for certain). So what is the proper behavior from your point of view? -- Sincerely, Vitaly
[PATCH 2/5] Updates for WRS SBC82xx boards
On Thu, 25 May 2006 14:25:33 -0400
Paul Gortmaker wrote:
>
> patch2: sbc82xx-PCI-diff1
> - allow m82xx_pci.c to be used by other platforms that have
> their own map_irq
>
> I'm open to doing this another way if desired -- I just went for the
> minimal impact on the existing code with this.
>
> Signed-off-by: Paul Gortmaker
>
>
> diff -ur orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c
> linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c ---
> orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c 2006-02-09
> 16:20:35.0 -0500 +++
> linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c 2006-02-09
> 16:01:40.0 -0500 @@ -198,7 +198,7 @@ } }
>
> -static int sbc82xx_pci_map_irq(struct pci_dev *dev, unsigned char
> idsel, +int pq2pci_map_irq(struct pci_dev *dev, unsigned char idsel,
> unsigned char pin)
> {
> static char pci_irq_table[][4] = {
> @@ -247,7 +247,7 @@
> callback_init_IRQ = ppc_md.init_IRQ;
>
> ppc_md.init_IRQ = sbc82xx_init_IRQ;
> - ppc_md.pci_map_irq = sbc82xx_pci_map_irq;
> + ppc_md.pci_map_irq = pq2pci_map_irq;
> #ifdef CONFIG_GEN_RTC
> ppc_md.time_init= NULL;
> ppc_md.get_rtc_time = NULL;
> diff -ur orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h
> linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h ---
> orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h 2006-02-09
> 16:20:35.0 -0500 +++
> linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h 2006-02-09
> 16:35:05.0 -0500 @@ -24,6 +24,7 @@ #define
> BOOTROM_RESTART_ADDR ((uint)0x4104)
> +#define HAVE_OWN_PQ2PCI_IRQ
> #define SBC82xx_PC_IRQA (NR_CPM_INTS+0)
> #define SBC82xx_PC_IRQB (NR_CPM_INTS+1)
> #define SBC82xx_MPC185_IRQ (NR_CPM_INTS+2)
> diff -ur orig/linux-2.6.16rc2/arch/ppc/syslib/m82xx_pci.c
> linux-2.6.16rc2/arch/ppc/syslib/m82xx_pci.c ---
> orig/linux-2.6.16rc2/arch/ppc/syslib/m82xx_pci.c 2006-01-02
> 22:21:10.0 -0500 +++
> linux-2.6.16rc2/arch/ppc/syslib/m82xx_pci.c 2006-02-09
> 14:35:10.0 -0500 @@ -51,6 +51,10 @@
> * Interrupt routing
> */
>
> +#ifdef HAVE_OWN_PQ2PCI_IRQ
> +extern int
> +pq2pci_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned
> char pin); +#else
> static inline int
> pq2pci_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned
> char pin) {
> @@ -172,6 +176,7 @@
> setup_irq(PCI_INT_TO_SIU, &pq2pci_irqaction);
> return;
> }
> +#endif /* HAVE_OWN_PQ2PCI_IRQ */
Sorry, but I don't quite follow the reason of that. As I see,
you are going to call find_bridges stuff but with demux disabled.
I see no reason to add any defines - if you won't call init_irq,
nothing will happen, I mean demux will not be assigned and so on. BTW,
right now it will not be issued in case of sbc82xx. It is not code-size
optimal, but we'll leave optimizations to arch/powerpc time.
Actually, you'll just have to override map_irq with sbc_ thing after
find_bridges() call.
>
> static int
> pq2pci_exclude_device(u_char bus, u_char devfn)
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
[PATCH 4/5] Updates for WRS SBC82xx boards
On Thu, 25 May 2006 14:30:38 -0400 Paul Gortmaker wrote: > patch4: sbc82xx-mchk-pci9.diff1 > - restore machine check disable for PCI9 that was in earlier > m8260_pci.c > > > Signed-off-by: Paul Gortmaker > > > > --- linux-2.6.16_rc5/arch/ppc/syslib/m82xx_pci.c.orig > 2006-02-27 15:02:01.0 -0500 +++ > linux-2.6.16_rc5/arch/ppc/syslib/m82xx_pci.c 2006-02-27 > 16:05:20.0 -0500 @@ -227,6 +227,11 @@ > immap->im_memctl.memc_pcibr1 = M82xx_PCI_SEC_WND_BASE | > PCIBR_ENABLE; #endif > +#ifdef CONFIG_8260_PCI9 > + /* Disable machine check on no response or target abort */ > +immap->im_pci.pci_emr = cpu_to_le32(0x1fe7); > +#endif > + No need in such a level of splitness - this is going to be hard to understand in common... > #if defined CONFIG_ADS8272 > immap->im_siu_conf.siu_82xx.sc_siumcr = > (immap->im_siu_conf.siu_82xx.sc_siumcr & > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > >
[PATCH 5/5] Updates for WRS SBC82xx boards
On Thu, 25 May 2006 14:32:32 -0400
Paul Gortmaker wrote:
>
> patch5: fcc_enet-mac-addr.diff1
> - restore proper collection of mac addr data in obsolete FCC
> driver by replacing mix of #ifdef and if() with case
8260_io stuff is obsoleted by fs_enet. You should fit the board into
ppc_sys infrastructure, fill the platform data and do per-board
initialization in board-specific file - refer to
platforms/mpc8272_setup.c for example...
>
> Signed-off-by: Paul Gortmaker
>
>
>
> --- linux-2.6.16_rc5/arch/ppc/8260_io/fcc_enet.c.orig
> 2006-01-02 22:21:10.0 -0500 +++
> linux-2.6.16_rc5/arch/ppc/8260_io/fcc_enet.c 2006-02-27
> 18:01:45.0 -0500 @@ -1962,32 +1962,30 @@
>* non-static part of the address.
>*/
> eap = (unsigned char *)&(ep->fen_paddrh);
> - for (i=5; i>=0; i--) {
>
> /*
> * The EP8260 only uses FCC3, so we can safely give it the real
> * MAC address.
> */
> + for (i=5; i>=0; i--) switch(i) {
> + case 5:
> #ifdef CONFIG_SBC82xx
> - if (i == 5) {
> /* bd->bi_enetaddr holds the SCC0 address;
> the FCC devices count up from there */
> dev->dev_addr[i] = bd->bi_enetaddr[i] & ~3;
> dev->dev_addr[i] += 1 + fip->fc_fccnum;
> *eap++ = dev->dev_addr[i];
> - }
> -#else
> -#ifndef CONFIG_RPX8260
> - if (i == 3) {
> + break;
> +#endif
> + case 3:
> +#if !defined(CONFIG_RPX8260) && !defined(CONFIG_SBC82xx)
> dev->dev_addr[i] = bd->bi_enetaddr[i];
> dev->dev_addr[i] |= (1 << (7 -
> fip->fc_fccnum)); *eap++ = dev->dev_addr[i];
> - } else
> + break;
> #endif
> - {
> + default:
> *eap++ = dev->dev_addr[i] =
> bd->bi_enetaddr[i];
> - }
> -#endif
> }
>
> ep->fen_taddrh = 0;
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
[PATCH] ppc32 CPM_UART: various fixes for pq2 uart users
This fixes various odd things that missed update together with cpm_uart
platform_device move. Unified resources names, restructurisation, etc.
Also, addressed issue with recent phys/virt translation rework. Being
cache-coherent, CPM2's do alloc_bootmem() for the console stuff, and it was
used to treat console buffer descriptor mapping 1:1 (as in CPM1 case),
which is definitely wrong.
Signed-off-by: Vitaly Bordug
---
arch/ppc/platforms/mpc8272ads_setup.c | 10 +-
arch/ppc/syslib/pq2_devices.c | 16
arch/ppc/syslib/pq2_sys.c |8
drivers/serial/cpm_uart/cpm_uart_core.c |8 +---
drivers/serial/cpm_uart/cpm_uart_cpm2.c |2 +-
5 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/arch/ppc/platforms/mpc8272ads_setup.c
b/arch/ppc/platforms/mpc8272ads_setup.c
index e62b757..abb7154 100644
--- a/arch/ppc/platforms/mpc8272ads_setup.c
+++ b/arch/ppc/platforms/mpc8272ads_setup.c
@@ -279,11 +279,11 @@ static int mpc8272ads_platform_notify(st
static const struct platform_notify_dev_map dev_map[] = {
{
.bus_id = "fsl-cpm-fcc",
- .rtn = mpc8272ads_fixup_enet_pdata
+ .rtn = mpc8272ads_fixup_enet_pdata,
},
{
.bus_id = "fsl-cpm-scc:uart",
- .rtn = mpc
+ .rtn = mpc8272ads_fixup_uart_pdata,
},
{
.bus_id = NULL
@@ -335,15 +335,15 @@ struct platform_device* early_uart_get_p
struct platform_device* pdev = NULL;
if(index) { /*assume SCC4 here*/
pdev = &ppc_sys_platform_devices[MPC82xx_CPM_SCC4];
- pinfo = &mpc8272_uart_pdata[1];
+ pinfo = &mpc8272_uart_pdata[fsid_scc4_uart];
} else { /*over SCC1*/
pdev = &ppc_sys_platform_devices[MPC82xx_CPM_SCC1];
- pinfo = &mpc8272_uart_pdata[0];
+ pinfo = &mpc8272_uart_pdata[fsid_scc1_uart];
}
pinfo->uart_clk = bd->bi_intfreq;
pdev->dev.platform_data = pinfo;
- ppc_sys_fixup_mem_resource(pdev, IMAP_ADDR);
+ ppc_sys_fixup_mem_resource(pdev, CPM_MAP_ADDR);
return NULL;
}
diff --git a/arch/ppc/syslib/pq2_devices.c b/arch/ppc/syslib/pq2_devices.c
index 0636aed..8692d00 100644
--- a/arch/ppc/syslib/pq2_devices.c
+++ b/arch/ppc/syslib/pq2_devices.c
@@ -121,13 +121,13 @@ struct platform_device ppc_sys_platform_
.num_resources = 3,
.resource = (struct resource[]) {
{
- .name = "scc_mem",
+ .name = "regs",
.start = 0x11A00,
.end= 0x11A1F,
.flags = IORESOURCE_MEM,
},
{
- .name = "scc_pram",
+ .name = "pram",
.start = 0x8000,
.end= 0x80ff,
.flags = IORESOURCE_MEM,
@@ -145,13 +145,13 @@ struct platform_device ppc_sys_platform_
.num_resources = 3,
.resource = (struct resource[]) {
{
- .name = "scc_mem",
+ .name = "regs",
.start = 0x11A20,
.end= 0x11A3F,
.flags = IORESOURCE_MEM,
},
{
- .name = "scc_pram",
+ .name = "pram",
.start = 0x8100,
.end= 0x81ff,
.flags = IORESOURCE_MEM,
@@ -169,13 +169,13 @@ struct platform_device ppc_sys_platform_
.num_resources = 3,
.resource = (struct resource[]) {
{
- .name = "scc_mem",
+ .name = "regs",
.start = 0x11A40,
.end= 0x11A5F,
.flags = IORESOURCE_MEM,
},
{
- .name = "scc_pram",
+ .name = "pram",
.start = 0x8200,
.end= 0x82ff,
.flags = IORESOURCE_MEM,
@@ -193,13 +193,13 @@ struct platform_device ppc_
UART DRIVER on 2.6.15
On Tue, 23 May 2006 14:02:49 +0200
"Ladislav Klenovi?" wrote:
> Hi,
> just a simple question, is uart driver for kernel 2.6.15 complete.
> There are some parts like:
> void scc1_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC1: insert port configuration here */
> pinfo->brg = 1;
> }
>
> that seems to incomplete. Am I able to do something with SCC1 with the
> current cpm_uart code?
>
> Maybe stupid question, is there any way (is it possible) to import old uart
> driver from kernel 2.4.x to kernel 2.6.x
>
It is clear, that per-board tune-up is too specific to be kept within drivers/
and now it is accomplished in the board setup code.
Just have a look at arch/ppc/platforms/mps866ads_setup.c The thing you'll have
to do is implement the pin tune-up for your board in a function, and set the
callback pointer to it - it will be executed at the time UART initializes its
resources.
--
Sincerely,
Vitaly
