* Re: State of the MPC5200 PSC AC97 driver
From: Juergen Beisert @ 2008-04-15 8:03 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <47FF135E.2060003@246tnt.com>
On Friday 11 April 2008 09:29, Sylvain Munaut wrote:
> > Last year you have posted a MPC5200 PSC AC97 driver patch
> > "[PATCH 9/9] sound: Add support for Freescale MPC5200 AC97 interface."
> >
> > with the following comment:
> >> Not quite a clean driver, but it get things done (well, mostly).
> >> Only included to be able to test functionalityi/usage of
> >> the BestComm driver.
>
> Yes ... and it still applies.
>
> > There are various FIXMEs and commented out code here and there.
> > Could you elaborate a bit on the overall state of the driver's
> > functionality,
> > which areas need improvement and attention?
>
> It's a minimum boiler plate.
> I filled the function at the minimum to get some sound output and being
> able to hear music coming out of it :)
> I also completely skipped the 5200 (not B) support ...
>
> At first there was no DMA at all (full software copy). I added some
> simple DMA later just to prove it could work and how to use the API.
>
> I just wrote it to get some sound, prove the interface could work under
> linux and to show how to use DMA. I had hoped someone else would finish
> it ... (yeah, I know ... big mistake).
>
> > Seems that you mainly tested BestComm with this driver, what was the
> > overall
> > BestComm performance, any issues here? Did you use any specific test
> > setup involving some dedicated application, etc.?
>
> My test was listening to Gorrillaz "Feel Good inc" using mplayer ...
>
> > Did anyone else tried it and/or has a updated version or can share
> > experience?
>
> At the time several other people tried it and it worked ... unless you
> did lots of harddrive IO and then it crumbled ...
Currently it fails to play anything with an external Wolfson WM9712 connect=
ed=20
to it. It seems the current AC97 reset sequence switches the WM9712 into=20
testmode due to SDATA_OUT and Sync are not held low while the reset is=20
active. Any idea to solve this? Switching both signals to GPIO and force th=
em=20
to low level while reset is active? How to cover PSC1 and PSC2 with differe=
nt=20
GPIOs for this case?
Juergen
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [PATCH 03/12] [POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr
From: Paul Mackerras @ 2008-04-15 7:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1207824531-27168-4-git-send-email-galak@kernel.crashing.org>
Kumar Gala writes:
> +phys_addr_t memstart_addr;
> +EXPORT_SYMBOL(memstart_addr);
Do you have a modular user of memstart_addr in mind?
Paul.
^ permalink raw reply
* Re: [PATCH] pseries: phyp dump: Variable size reserve space.
From: Paul Mackerras @ 2008-04-15 6:24 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas
In-Reply-To: <47FFF4E8.9010705@austin.ibm.com>
Manish Ahuja writes:
> B. It computers 5% of total ram and rounds it down to multiples of 256MB.
> C. Compares the rounded down value and returns larger of 256MB or the new
> computed value.
So if we have 10GB of memory or more we'll use reserve more than
256MB. What is the advantage of reserving more than 256MB of memory?
Paul.
^ permalink raw reply
* Re: [Buildroot] zImage.embedded
From: Ulf Samuelsson @ 2008-04-14 20:55 UTC (permalink / raw)
To: Guillaume Dargaud, linuxppc-dev, Buildroot Mailinglist,
In-Reply-To: <01e801c89e49$6d0e6400$ad289e86@LPSC0173W>
> [cross posting from one mailing list to another]
>=20
>>> is the file zImage.elf my proper network image ?
>>
>> What bootloader is on your board? zImage.elf *might* be the proper
>> image. If you're using u-boot, then you want to build a uImage
>> instead.
>=20
> I'm trying to compile u-boot with buildroot, but it fails with:
>=20
> /usr/bin/make -j1 -C=20
> =
/home/guinevere/Min_UartLite_NetLite_Ace/buildroot/project_build_powerpc/=
genepy/u-boot-1.3.2=20
> \
> ""_config
> make[1]: Entering directory=20
> =
`/home/guinevere/Min_UartLite_NetLite_Ace/buildroot/project_build_powerpc=
/genepy/u-boot-1.3.2'
> make[1]: *** No rule to make target `_config'. Stop.
> make[1]: Leaving directory=20
> =
`/home/guinevere/Min_UartLite_NetLite_Ace/buildroot/project_build_powerpc=
/genepy/u-boot-1.3.2'
> make: ***=20
> =
[/home/guinevere/Min_UartLite_NetLite_Ace/buildroot/project_build_powerpc=
/genepy/u-boot-1.3.2/.configured]=20
> Error 2
>=20
> Apparently it expects a BOARD_NAME variable, but I don't know what to =
put in=20
> it (I looked at the makefile and can't find the ml405 referenced in =
there).
> --=20
> Guillaume Dargaud
> http://www.gdargaud.net/
>=20
I think you need to figure out how to build u-boot for your board
outside buildroot, before you try to build it inside buildroot.
Best Regards
Ulf Samuelsson
^ permalink raw reply
* Re: [PATCH] [POWERPC] Make Book-E debug handling SMP safe
From: Paul Mackerras @ 2008-04-15 4:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0804091621140.24556@blarg.am.freescale.net>
Kumar Gala writes:
> global_dbcr0 needs to be a per cpu set of save areas instead of a single
> global on all processors.
Looks reasonable. At some point you might want to use a per-cpu
variable instead of an array in order to reduce cacheline bouncing.
> Also, we switch to using DBCR0_IDM to determine if the user space app is
> being debugged as its a more consistent way. In the future we should
> support features like hardware breakpoint and watchpoints which will
> have DBCR0_IDM set but not necessarily DBCR0_IC (single step).
That should be OK.
Paul.
^ permalink raw reply
* Re: [PATCH] IB/ehca: extend query_device() and query_port() to support all values for ibv_devinfo
From: Roland Dreier @ 2008-04-15 4:01 UTC (permalink / raw)
To: Stefan Roscher; +Cc: fenkes, ewg, linux-kernel, linuxppc-dev, raisch, general
In-Reply-To: <200804071457.36248.ossrosch@linux.vnet.ibm.com>
thanks, applied
^ permalink raw reply
* [PATCH] scc_pata.c: do setup itself instead of ide_setup_pci_device ()
From: Akira Iguchi @ 2008-04-15 3:15 UTC (permalink / raw)
To: bzolnier; +Cc: linux-ide, linuxppc-dev
scc_pata has the different BAR configuration and using ide_setup_pci_device()
is inappropriate.
(ide_setup_pci_device() expects a normal PCI IDE controller with
BAR0..BAR3 either non-existant or being primary/secondary port bases
in I/O space.)
This patch do all needed setup itself instead of calling ide_setup_pci_device().
Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
Signed-off-by: Akira Iguchi <akira2.iguchi@toshiba.co.jp>
---
--- linux-2.6.25-rc1/drivers/ide/pci/scc_pata.c 2008-02-11 07:18:14.000000000 +0900
+++ linux-2.6.25-rc1_mod/drivers/ide/pci/scc_pata.c 2008-04-15 11:45:25.000000000 +0900
@@ -523,6 +523,42 @@ static int setup_mmio_scc (struct pci_de
return -ENOMEM;
}
+static int scc_ide_setup_pci_device(struct pci_dev *dev, const struct ide_port_info *d)
+{
+ struct scc_ports *ports = pci_get_drvdata(dev);
+ ide_hwif_t *hwif = NULL;
+ hw_regs_t hw;
+ u8 idx[4] = { 0xff, 0xff, 0xff, 0xff };
+ int i;
+
+ for (i = 0; i < MAX_HWIFS; i++) {
+ hwif = &ide_hwifs[i];
+ if (hwif->chipset == ide_unknown)
+ break; /* pick an unused entry */
+ }
+ if (i == MAX_HWIFS) {
+ printk(KERN_ERR "%s: too many IDE interfaces, no room in table\n",
+ SCC_PATA_NAME);
+ return -ENOMEM;
+ }
+
+ memset(&hw, 0, sizeof(hw));
+ for (i = IDE_DATA_OFFSET; i <= IDE_CONTROL_OFFSET; i++)
+ hw.io_ports[i] = ports->dma + 0x20 + i * 4;
+ hw.irq = dev->irq;
+ hw.dev = &dev->dev;
+ hw.chipset = ide_pci;
+ ide_init_port_hw(hwif, &hw);
+ hwif->dev = &dev->dev;
+ hwif->cds = d;
+
+ idx[0] = hwif->index;
+
+ ide_device_add(idx, d);
+
+ return 0;
+}
+
/**
* init_setup_scc - set up an SCC PATA Controller
* @dev: PCI device
@@ -545,10 +581,13 @@ static int __devinit init_setup_scc(stru
struct scc_ports *ports;
int rc;
+ rc = pci_enable_device(dev);
+ if (rc)
+ goto end;
+
rc = setup_mmio_scc(dev, d->name);
- if (rc < 0) {
- return rc;
- }
+ if (rc < 0)
+ goto end;
ports = pci_get_drvdata(dev);
ctl_base = ports->ctl;
@@ -583,7 +622,10 @@ static int __devinit init_setup_scc(stru
out_be32((void*)mode_port, MODE_JCUSFEN);
out_be32((void*)intmask_port, INTMASK_MSK);
- return ide_setup_pci_device(dev, d);
+ rc = scc_ide_setup_pci_device(dev, d);
+
+ end:
+ return rc;
}
/**
@@ -610,17 +652,6 @@ static void __devinit init_mmio_iops_scc
hwif->OUTSW = scc_ide_outsw;
hwif->OUTSL = scc_ide_outsl;
- hwif->io_ports[IDE_DATA_OFFSET] = dma_base + 0x20;
- hwif->io_ports[IDE_ERROR_OFFSET] = dma_base + 0x24;
- hwif->io_ports[IDE_NSECTOR_OFFSET] = dma_base + 0x28;
- hwif->io_ports[IDE_SECTOR_OFFSET] = dma_base + 0x2c;
- hwif->io_ports[IDE_LCYL_OFFSET] = dma_base + 0x30;
- hwif->io_ports[IDE_HCYL_OFFSET] = dma_base + 0x34;
- hwif->io_ports[IDE_SELECT_OFFSET] = dma_base + 0x38;
- hwif->io_ports[IDE_STATUS_OFFSET] = dma_base + 0x3c;
- hwif->io_ports[IDE_CONTROL_OFFSET] = dma_base + 0x40;
-
- hwif->irq = dev->irq;
hwif->dma_base = dma_base;
hwif->config_data = ports->ctl;
hwif->mmio = 1;
^ permalink raw reply
* SecretLab 2.6.24 with USB
From: Sam Karp @ 2008-04-15 2:27 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 345 bytes --]
Hi all,
I've downloaded the SecretLab Xilinx Linux 2.6.24 Kernel and I'm trying to
use a thumbdrive with the kernel. I'm booting from a ramdisk and insert the
thumbdrive but I have no /dev/sd* or /dev/hd* blocks. Is there anything I
need to add to the kernel or design to ensure that the thumbdrive is working
or getting power?
Thanks,
-Sam
[-- Attachment #2: Type: text/html, Size: 446 bytes --]
^ permalink raw reply
* Re: [PATCH] 86xx: mark functions static, other minor cleanups
From: Paul Gortmaker @ 2008-04-15 1:32 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Scott Wood, Paul Gortmaker, sfr, linuxppc-dev
In-Reply-To: <28ac27892f91a47cd620aee7b7b9ecdb@kernel.crashing.org>
On Fri, Apr 11, 2008 at 3:11 PM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> > Updated as per above, and with tickerized prefixes for sbc8641.
> >
>
> Care to try once more? It's only "tickerized" if it's in all
> uppercase.
I'm looking at what exists in arch/powerpc/boot/dts/* and I'm
not seeing too much uppercase - here is a sample:
ebony.dts: compatible = "ibm,ebony";
ep405.dts: compatible = "ibm,uic";
ep8248e.dts: compatible = "fsl,ep8248e";
bamboo.dts: compatible = "amcc,bamboo";
cm5200.dts: compatible = "schindler,cm5200";
ep88xc.dts: compatible = "fsl,ep88xc";
haleakala.dts: compatible = "amcc,kilauea";
holly.dts: compatible = "ibm,holly";
katmai.dts: compatible = "amcc,katmai";
kilauea.dts: compatible = "amcc,kilauea";
lite5200b.dts: compatible = "fsl,lite5200b";
motionpro.dts: compatible = "promess,motionpro";
mpc8272ads.dts: compatible = "fsl,mpc8272ads";
mpc866ads.dts: compatible = "fsl,mpc866ads";
> > + compatible = "wind,sbc8641";
To me this looks in keeping with the rest. And I prefer
with the lower case, actually. (Apparently so do a lot of
other people...)
Paul.
> >
>
>
> Segher
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: Problems of using APU/FPU under linux
From: John Bonesio @ 2008-04-14 22:20 UTC (permalink / raw)
To: Shanyuan Gao; +Cc: John Bonesio, Stephen Neuendorffer, linuxppc-embedded
In-Reply-To: <1B35E815-094F-40CB-AEDA-C04A6CBECC07@gmail.com>
Hi Shan,
Someone here reminded me that the ppc405 is not BookE. One of your problems maybe in getting the kernel to set up an FPU unavilable handler.
- John
On Monday 14 April 2008 13:46, Shanyuan Gao wrote:
> Thank you very much, Steve and John!
>
> My advisor and I discussed how Linux works with APU/FPU a few days
> ago. And he had the same thoughts with John. My naive guess was it
> would automatically decode FP operations and mask the trap. Now it
> answers my second question. I will try it later.
>
> But for my first question, I searched all (almost all) the files,
> such as head.S, entry.S, head_4xx.S, etc. And added following three
> lines before mtmsr or MTMSRD are used
>
> ori r10, r10, 1<<13 /* enable fpu */
> oris r10, r10, 1<<9 /* enable apu */
> oris r10, r10, 1<<3 /* enable apu exception */
>
> However the MSR in trap prompts keeps the same (2d030) before and
> after I added those lines.
>
> [ 31.819079] Bad trap at PC: 10000458, MSR: 2d030, vector=800
> Not tainted
> [ 31.887027] Signal: 5
> [ 31.887042] Code: 0
> [ 31.887058] Addr: 0
> Trace/breakpoint trap
>
> I guess there must be some places, like some interrupts that changed
> the MSR that I didn't know.
>
> And for FP exceptions, it has two bits (two modes) in MSR. I think
> they are for such exceptions like divided by zero. Do I need to set
> them also?
>
> In my previous build, I also added PPC_FPU under config 40x in arch/
> ppc/Kconfig. It compiled arch/powerpc/kernel/fpu.S in, but didn't
> help. I will try CONFIG_PPC_FPU later.
>
>
> Shan
>
> On Apr 14, 2008, at 2:32 PM, John Bonesio wrote:
>
> > Hi,
> >
> > The Linux kernel itself doesn't issue floating point instructions
> > other than to save and restore the fpu state when necessary.
> >
> > In Linux, the way it saves and restores the fpu state is to make
> > use of the trap. When the trap (fpu unavailable) occurs, it loads
> > the fpu state for the current task, sets up the MSR, and returns to
> > re-try the instruction.
> >
> > So, getting the trap is normal. If the FPU is not being set up
> > correctly, then there may be a problem with the restoring of the
> > state.
> >
> > When you guild the Linux kernel, you need to have CONFIG_PPC_FPU
> > enabled. Otherwise the kernel does not setup the fpu exception
> > handling.
> >
> > - John
> >
> >
> > On Monday 14 April 2008 10:35, Stephen Neuendorffer wrote:
> >>
> >> I'm not sure exactly what's going on here. Generally speaking, if
> >> you
> >> have the FPU instantiated in the design and enable the APU in the
> >> msr,
> >> then the processor should decode FP instructions and send them
> >> directly
> >> to the APU with no trap. I haven't done this myself, or I could
> >> probably give you some better help...
> >>
> >> One thing you should be aware of is that the there are gcc compiler
> >> patches which are necessary to get the FPU working properly.
> >> However, I
> >> don't think the failure mode that these patches workaround would
> >> cause a
> >> trap, so my guess is that there is still something else wrong.
> >>
> >> Steve
> >>
> >>> -----Original Message-----
> >>> From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
> >> [mailto:linuxppc-embedded-
> >>> bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of Shanyuan
> >> Gao
> >>> Sent: Monday, April 14, 2008 9:18 AM
> >>> To: linuxppc-embedded@ozlabs.org
> >>> Subject: Problems of using APU/FPU under linux
> >>>
> >>> Hi,
> >>>
> >>> Recently I was trying to make APU/FPU working under Linux on Xilinx
> >>> ML410. The standalone programs work perfectly. However under Linux,
> >>> when I try to use a floating point operation, like *fmuls*, it will
> >>> give me a *trap*.
> >>>
> >>> By studying the user guide from Xilinx and dumping the object files,
> >>> I know I need to change the corresponding bits (APU enable, FP
> >>> enable, maybe APU Exception enable) in Machine State Register. I
> >>> guess I need to enable the bits whenever before the kernel uses
> >>> *mtmsr*. However, it doesn't work. I got the same trap with the same
> >>> MSR, as I had no APU/FPU before. I also tried to add the FPU.S to
> >>> ppc
> >>> tree, but it doesn't work either.
> >>>
> >>> The questions are
> >>> 1. I guess there might be some place that changed MSR after all my
> >>> changes. But I don't know where. And can I write a kernel module to
> >>> change the MSR after booting in Linux? (well, it's hard for me
> >>> though)
> >>>
> >>> 2. Does it have any exception/interrupt mechanism to direct FP
> >>> operation to APU/FPU? Or after enabling APU/FPU it will mask the
> >>> exception/interrupt and decode FP operation by itself?
> >>>
> >>>
> >>> Any ideas are appreciated. Thank you very much!
> >>>
> >>>
> >>> Shan
> >>>
> >>> _______________________________________________
> >>> Linuxppc-embedded mailing list
> >>> Linuxppc-embedded@ozlabs.org
> >>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>
> >>
> >
>
>
^ permalink raw reply
* Re: Problems of using APU/FPU under linux
From: John Bonesio @ 2008-04-14 21:56 UTC (permalink / raw)
To: Shanyuan Gao; +Cc: John Bonesio, Stephen Neuendorffer, linuxppc-embedded
In-Reply-To: <1B35E815-094F-40CB-AEDA-C04A6CBECC07@gmail.com>
Hi Shan,
It's not clear exactly what you are experiencing. What do you see in your user application, "Illegal instruction" ?
In arch/powerpc/kernel/head_booke.h, there's #define FP_UNAVAILABLE_EXCEPTION. This defines the FPU unavailable exception. Is the code getting there? You should see the call to load_up_fpu in there, which is defined in arch/powerpc/kernel/fpu.S
What exception is being generated? It looks like you're getting SIGTRAP in your application which is the debug exception, which doesn't seem related to how the kernel sets up the fpu.
I believe the 2 bits you mentioned just have to do with with how the fpu behaves. The kernel code doesn't use those for the fpu context switching. It uses the Floating-Point Available bit in the MSR.
Definitely check the errata and other information about the FPU you are using. As Steve mentioned, you should use the Xilinx gcc tools with the Xilinx FPU.
- John
On Monday 14 April 2008 13:46, Shanyuan Gao wrote:
> Thank you very much, Steve and John!
>
> My advisor and I discussed how Linux works with APU/FPU a few days
> ago. And he had the same thoughts with John. My naive guess was it
> would automatically decode FP operations and mask the trap. Now it
> answers my second question. I will try it later.
>
> But for my first question, I searched all (almost all) the files,
> such as head.S, entry.S, head_4xx.S, etc. And added following three
> lines before mtmsr or MTMSRD are used
>
> ori r10, r10, 1<<13 /* enable fpu */
> oris r10, r10, 1<<9 /* enable apu */
> oris r10, r10, 1<<3 /* enable apu exception */
>
> However the MSR in trap prompts keeps the same (2d030) before and
> after I added those lines.
>
> [ 31.819079] Bad trap at PC: 10000458, MSR: 2d030, vector=800
> Not tainted
> [ 31.887027] Signal: 5
> [ 31.887042] Code: 0
> [ 31.887058] Addr: 0
> Trace/breakpoint trap
>
> I guess there must be some places, like some interrupts that changed
> the MSR that I didn't know.
>
> And for FP exceptions, it has two bits (two modes) in MSR. I think
> they are for such exceptions like divided by zero. Do I need to set
> them also?
>
> In my previous build, I also added PPC_FPU under config 40x in arch/
> ppc/Kconfig. It compiled arch/powerpc/kernel/fpu.S in, but didn't
> help. I will try CONFIG_PPC_FPU later.
>
>
> Shan
>
> On Apr 14, 2008, at 2:32 PM, John Bonesio wrote:
>
> > Hi,
> >
> > The Linux kernel itself doesn't issue floating point instructions
> > other than to save and restore the fpu state when necessary.
> >
> > In Linux, the way it saves and restores the fpu state is to make
> > use of the trap. When the trap (fpu unavailable) occurs, it loads
> > the fpu state for the current task, sets up the MSR, and returns to
> > re-try the instruction.
> >
> > So, getting the trap is normal. If the FPU is not being set up
> > correctly, then there may be a problem with the restoring of the
> > state.
> >
> > When you guild the Linux kernel, you need to have CONFIG_PPC_FPU
> > enabled. Otherwise the kernel does not setup the fpu exception
> > handling.
> >
> > - John
> >
> >
> > On Monday 14 April 2008 10:35, Stephen Neuendorffer wrote:
> >>
> >> I'm not sure exactly what's going on here. Generally speaking, if
> >> you
> >> have the FPU instantiated in the design and enable the APU in the
> >> msr,
> >> then the processor should decode FP instructions and send them
> >> directly
> >> to the APU with no trap. I haven't done this myself, or I could
> >> probably give you some better help...
> >>
> >> One thing you should be aware of is that the there are gcc compiler
> >> patches which are necessary to get the FPU working properly.
> >> However, I
> >> don't think the failure mode that these patches workaround would
> >> cause a
> >> trap, so my guess is that there is still something else wrong.
> >>
> >> Steve
> >>
> >>> -----Original Message-----
> >>> From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
> >> [mailto:linuxppc-embedded-
> >>> bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of Shanyuan
> >> Gao
> >>> Sent: Monday, April 14, 2008 9:18 AM
> >>> To: linuxppc-embedded@ozlabs.org
> >>> Subject: Problems of using APU/FPU under linux
> >>>
> >>> Hi,
> >>>
> >>> Recently I was trying to make APU/FPU working under Linux on Xilinx
> >>> ML410. The standalone programs work perfectly. However under Linux,
> >>> when I try to use a floating point operation, like *fmuls*, it will
> >>> give me a *trap*.
> >>>
> >>> By studying the user guide from Xilinx and dumping the object files,
> >>> I know I need to change the corresponding bits (APU enable, FP
> >>> enable, maybe APU Exception enable) in Machine State Register. I
> >>> guess I need to enable the bits whenever before the kernel uses
> >>> *mtmsr*. However, it doesn't work. I got the same trap with the same
> >>> MSR, as I had no APU/FPU before. I also tried to add the FPU.S to
> >>> ppc
> >>> tree, but it doesn't work either.
> >>>
> >>> The questions are
> >>> 1. I guess there might be some place that changed MSR after all my
> >>> changes. But I don't know where. And can I write a kernel module to
> >>> change the MSR after booting in Linux? (well, it's hard for me
> >>> though)
> >>>
> >>> 2. Does it have any exception/interrupt mechanism to direct FP
> >>> operation to APU/FPU? Or after enabling APU/FPU it will mask the
> >>> exception/interrupt and decode FP operation by itself?
> >>>
> >>>
> >>> Any ideas are appreciated. Thank you very much!
> >>>
> >>>
> >>> Shan
> >>>
> >>> _______________________________________________
> >>> Linuxppc-embedded mailing list
> >>> Linuxppc-embedded@ozlabs.org
> >>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>
> >>
> >
>
>
^ permalink raw reply
* Re: Get new_emac driver running on 405EP
From: Benjamin Herrenschmidt @ 2008-04-14 21:02 UTC (permalink / raw)
To: M B; +Cc: ppc-dev
In-Reply-To: <6a6049b80804141038k77ac361cl11f50bc9d890c6a2@mail.gmail.com>
On Mon, 2008-04-14 at 19:38 +0200, M B wrote:
> Hi,
> I'm trying to get the new_emac driver (linux 2.6.25-rc8) running on my
> 405EP board with a KSZ8721BT Micrel/Kendin PHY.
> I've already found 2 problems/missing features:
> 1) 100 retries in __emac_mdio_read for the read to complete are
> slightly too less. 101 seem to be enough. But we could add a bit more,
> because there is no negative effect for faster chips.
> 2) On the 405EP only the MDIO pin of the emac0 is pinned out, so both
> phys have to be accessed through this one. This affectes the mdio
> read/write functions.
The later can easily be described in the device-tree as it's a fairly
common setup.
> I've already hacked around this problems, but ethernet is still not working.
> After bringing up the device dmesg is flooded with this section.
> emac/plb/opb/ethernet@ef600800: link timer
> emac/plb/opb/ethernet@ef600800: mdio_read(00,01)
> emac/plb/opb/ethernet@ef600800: mdio_read -> 786d
> emac/plb/opb/ethernet@ef600800: mdio_read(00,01)
> emac/plb/opb/ethernet@ef600800: mdio_read -> 786d
>
>
> Any ideas where I should start looking?
The above is the timer polling the link, you may want to remove that
debug once it looks sane.
Ben.
^ permalink raw reply
* Re: Manual kernel parameters are being ignored
From: Josh Boyer @ 2008-04-14 20:51 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <01f001c89e4b$05acddd0$ad289e86@LPSC0173W>
On Mon, 14 Apr 2008 18:17:16 +0200
"Guillaume Dargaud" <dargaud@lpsc.in2p3.fr> wrote:
> Anyone care to tell me why the parameters I type manually for the kernel are
> being ignored ?
Care to tell us which kernel you are using and what your .config for it
looks like?
josh
^ permalink raw reply
* Re: Problems of using APU/FPU under linux
From: Shanyuan Gao @ 2008-04-14 20:46 UTC (permalink / raw)
To: John Bonesio, Stephen Neuendorffer, linuxppc-embedded
In-Reply-To: <20080414183255.F056C1C300A3@mail62-sin.bigfish.com>
[-- Attachment #1: Type: text/plain, Size: 4591 bytes --]
Thank you very much, Steve and John!
My advisor and I discussed how Linux works with APU/FPU a few days
ago. And he had the same thoughts with John. My naive guess was it
would automatically decode FP operations and mask the trap. Now it
answers my second question. I will try it later.
But for my first question, I searched all (almost all) the files,
such as head.S, entry.S, head_4xx.S, etc. And added following three
lines before mtmsr or MTMSRD are used
ori r10, r10, 1<<13 /* enable fpu */
oris r10, r10, 1<<9 /* enable apu */
oris r10, r10, 1<<3 /* enable apu exception */
However the MSR in trap prompts keeps the same (2d030) before and
after I added those lines.
[ 31.819079] Bad trap at PC: 10000458, MSR: 2d030, vector=800
Not tainted
[ 31.887027] Signal: 5
[ 31.887042] Code: 0
[ 31.887058] Addr: 0
Trace/breakpoint trap
I guess there must be some places, like some interrupts that changed
the MSR that I didn't know.
And for FP exceptions, it has two bits (two modes) in MSR. I think
they are for such exceptions like divided by zero. Do I need to set
them also?
In my previous build, I also added PPC_FPU under config 40x in arch/
ppc/Kconfig. It compiled arch/powerpc/kernel/fpu.S in, but didn't
help. I will try CONFIG_PPC_FPU later.
Shan
On Apr 14, 2008, at 2:32 PM, John Bonesio wrote:
> Hi,
>
> The Linux kernel itself doesn't issue floating point instructions
> other than to save and restore the fpu state when necessary.
>
> In Linux, the way it saves and restores the fpu state is to make
> use of the trap. When the trap (fpu unavailable) occurs, it loads
> the fpu state for the current task, sets up the MSR, and returns to
> re-try the instruction.
>
> So, getting the trap is normal. If the FPU is not being set up
> correctly, then there may be a problem with the restoring of the
> state.
>
> When you guild the Linux kernel, you need to have CONFIG_PPC_FPU
> enabled. Otherwise the kernel does not setup the fpu exception
> handling.
>
> - John
>
>
> On Monday 14 April 2008 10:35, Stephen Neuendorffer wrote:
>>
>> I'm not sure exactly what's going on here. Generally speaking, if
>> you
>> have the FPU instantiated in the design and enable the APU in the
>> msr,
>> then the processor should decode FP instructions and send them
>> directly
>> to the APU with no trap. I haven't done this myself, or I could
>> probably give you some better help...
>>
>> One thing you should be aware of is that the there are gcc compiler
>> patches which are necessary to get the FPU working properly.
>> However, I
>> don't think the failure mode that these patches workaround would
>> cause a
>> trap, so my guess is that there is still something else wrong.
>>
>> Steve
>>
>>> -----Original Message-----
>>> From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
>> [mailto:linuxppc-embedded-
>>> bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of Shanyuan
>> Gao
>>> Sent: Monday, April 14, 2008 9:18 AM
>>> To: linuxppc-embedded@ozlabs.org
>>> Subject: Problems of using APU/FPU under linux
>>>
>>> Hi,
>>>
>>> Recently I was trying to make APU/FPU working under Linux on Xilinx
>>> ML410. The standalone programs work perfectly. However under Linux,
>>> when I try to use a floating point operation, like *fmuls*, it will
>>> give me a *trap*.
>>>
>>> By studying the user guide from Xilinx and dumping the object files,
>>> I know I need to change the corresponding bits (APU enable, FP
>>> enable, maybe APU Exception enable) in Machine State Register. I
>>> guess I need to enable the bits whenever before the kernel uses
>>> *mtmsr*. However, it doesn't work. I got the same trap with the same
>>> MSR, as I had no APU/FPU before. I also tried to add the FPU.S to
>>> ppc
>>> tree, but it doesn't work either.
>>>
>>> The questions are
>>> 1. I guess there might be some place that changed MSR after all my
>>> changes. But I don't know where. And can I write a kernel module to
>>> change the MSR after booting in Linux? (well, it's hard for me
>>> though)
>>>
>>> 2. Does it have any exception/interrupt mechanism to direct FP
>>> operation to APU/FPU? Or after enabling APU/FPU it will mask the
>>> exception/interrupt and decode FP operation by itself?
>>>
>>>
>>> Any ideas are appreciated. Thank you very much!
>>>
>>>
>>> Shan
>>>
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 13603 bytes --]
^ permalink raw reply
* Re: [PATCH 7/8] [POWERPC] qe_lib: add support for QE USB
From: Kumar Gala @ 2008-04-14 20:29 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080311172441.GG7727@localhost.localdomain>
On Mar 11, 2008, at 12:24 PM, Anton Vorontsov wrote:
> I believe QE USB clocks routing is qe_lib authority, so usb.c
> created. Also, now cmxgcr needs its own lock.
why? (I'm asking to be more descriptive in the commit message)
> This patch also fixes QE_USB_RESTART_TX command definition.
Patch look ok, but can you be a bit more descriptive about why we are
adding this.
- k
>
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/sysdev/qe_lib/Kconfig | 6 ++++
> arch/powerpc/sysdev/qe_lib/Makefile | 1 +
> arch/powerpc/sysdev/qe_lib/ucc.c | 7 ++--
> arch/powerpc/sysdev/qe_lib/usb.c | 57 ++++++++++++++++++++++++++
> +++++++++
> include/asm-powerpc/qe.h | 18 ++++++++++-
> 5 files changed, 85 insertions(+), 4 deletions(-)
> create mode 100644 arch/powerpc/sysdev/qe_lib/usb.c
>
> diff --git a/arch/powerpc/sysdev/qe_lib/Kconfig b/arch/powerpc/
> sysdev/qe_lib/Kconfig
> index c1f2849..f09dae4 100644
> --- a/arch/powerpc/sysdev/qe_lib/Kconfig
> +++ b/arch/powerpc/sysdev/qe_lib/Kconfig
> @@ -25,3 +25,9 @@ config QE_GTM
> default y if FSL_GTM
> help
> QE General-purpose Timers Module support
> +
> +config QE_USB
> + bool
> + default y if USB_FHCI_HCD
> + help
> + QE USB Host Controller support
> diff --git a/arch/powerpc/sysdev/qe_lib/Makefile b/arch/powerpc/
> sysdev/qe_lib/Makefile
> index 3297a52..c666a59 100644
> --- a/arch/powerpc/sysdev/qe_lib/Makefile
> +++ b/arch/powerpc/sysdev/qe_lib/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_UCC) += ucc.o
> obj-$(CONFIG_UCC_SLOW) += ucc_slow.o
> obj-$(CONFIG_UCC_FAST) += ucc_fast.o
> obj-$(CONFIG_QE_GTM) += gtm.o
> +obj-$(CONFIG_QE_USB) += usb.o
> diff --git a/arch/powerpc/sysdev/qe_lib/ucc.c b/arch/powerpc/sysdev/
> qe_lib/ucc.c
> index 0e348d9..d3c7f5a 100644
> --- a/arch/powerpc/sysdev/qe_lib/ucc.c
> +++ b/arch/powerpc/sysdev/qe_lib/ucc.c
> @@ -26,7 +26,8 @@
> #include <asm/qe.h>
> #include <asm/ucc.h>
>
> -static DEFINE_SPINLOCK(ucc_lock);
> +DEFINE_SPINLOCK(cmxgcr_lock);
> +EXPORT_SYMBOL(cmxgcr_lock);
>
> int ucc_set_qe_mux_mii_mng(unsigned int ucc_num)
> {
> @@ -35,10 +36,10 @@ int ucc_set_qe_mux_mii_mng(unsigned int ucc_num)
> if (ucc_num > UCC_MAX_NUM - 1)
> return -EINVAL;
>
> - spin_lock_irqsave(&ucc_lock, flags);
> + spin_lock_irqsave(&cmxgcr_lock, flags);
> clrsetbits_be32(&qe_immr->qmx.cmxgcr, QE_CMXGCR_MII_ENET_MNG,
> ucc_num << QE_CMXGCR_MII_ENET_MNG_SHIFT);
> - spin_unlock_irqrestore(&ucc_lock, flags);
> + spin_unlock_irqrestore(&cmxgcr_lock, flags);
>
> return 0;
> }
> diff --git a/arch/powerpc/sysdev/qe_lib/usb.c b/arch/powerpc/sysdev/
> qe_lib/usb.c
> new file mode 100644
> index 0000000..60ce676
> --- /dev/null
> +++ b/arch/powerpc/sysdev/qe_lib/usb.c
> @@ -0,0 +1,57 @@
> +/*
> + * QE USB routines
> + *
> + * Copyright (c) Freescale Semicondutor, Inc. 2006.
> + * Shlomi Gridish <gridish@freescale.com>
> + * Jerry Huang <Chang-Ming.Huang@freescale.com>
> + * Copyright (c) MontaVista Software, Inc. 2008.
> + * Anton Vorontsov <avorontsov@ru.mvista.com>
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/errno.h>
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <asm/immap_qe.h>
> +#include <asm/qe.h>
> +
> +int qe_usb_clock_set(enum qe_clock clk, int rate)
> +{
> + struct qe_mux __iomem *mux = &qe_immr->qmx;
> + unsigned long flags;
> + const bool is_brg = clk < QE_CLK1;
> + u32 val;
> +
> + switch (clk) {
> + case QE_CLK3: val = QE_CMXGCR_USBCS_CLK3; break;
> + case QE_CLK5: val = QE_CMXGCR_USBCS_CLK5; break;
> + case QE_CLK7: val = QE_CMXGCR_USBCS_CLK7; break;
> + case QE_CLK9: val = QE_CMXGCR_USBCS_CLK9; break;
> + case QE_CLK13: val = QE_CMXGCR_USBCS_CLK13; break;
> + case QE_CLK17: val = QE_CMXGCR_USBCS_CLK17; break;
> + case QE_CLK19: val = QE_CMXGCR_USBCS_CLK19; break;
> + case QE_CLK21: val = QE_CMXGCR_USBCS_CLK21; break;
> + case QE_BRG9: val = QE_CMXGCR_USBCS_BRG9; break;
> + case QE_BRG10: val = QE_CMXGCR_USBCS_BRG10; break;
> + default:
> + pr_err("%s: requested unknown clock %d\n", __func__, clk);
> + return -EINVAL;
> + }
> +
> + if (is_brg)
> + qe_setbrg(clk, rate, 1);
> +
> + spin_lock_irqsave(&cmxgcr_lock, flags);
> +
> + clrsetbits_be32(&mux->cmxgcr, QE_CMXGCR_USBCS, val);
> +
> + spin_unlock_irqrestore(&cmxgcr_lock, flags);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(qe_usb_clock_set);
> diff --git a/include/asm-powerpc/qe.h b/include/asm-powerpc/qe.h
> index c3be6e2..3276b06 100644
> --- a/include/asm-powerpc/qe.h
> +++ b/include/asm-powerpc/qe.h
> @@ -16,6 +16,7 @@
> #define _ASM_POWERPC_QE_H
> #ifdef __KERNEL__
>
> +#include <linux/spinlock.h>
> #include <asm/immap_qe.h>
>
> #define QE_NUM_OF_SNUM 28
> @@ -74,6 +75,8 @@ enum qe_clock {
> QE_CLK_DUMMY
> };
>
> +extern spinlock_t cmxgcr_lock;
> +
> /* Export QE common operations */
> extern void qe_reset(void);
> extern int par_io_init(struct device_node *np);
> @@ -156,6 +159,9 @@ int qe_upload_firmware(const struct qe_firmware
> *firmware);
> /* Obtain information on the uploaded firmware */
> struct qe_firmware_info *qe_get_firmware_info(void);
>
> +/* QE USB */
> +int qe_usb_clock_set(enum qe_clock clk, int rate);
> +
> /* Buffer descriptors */
> struct qe_bd {
> __be16 status;
> @@ -254,6 +260,16 @@ enum comm_dir {
> #define QE_CMXGCR_MII_ENET_MNG 0x00007000
> #define QE_CMXGCR_MII_ENET_MNG_SHIFT 12
> #define QE_CMXGCR_USBCS 0x0000000f
> +#define QE_CMXGCR_USBCS_CLK3 0x1
> +#define QE_CMXGCR_USBCS_CLK5 0x2
> +#define QE_CMXGCR_USBCS_CLK7 0x3
> +#define QE_CMXGCR_USBCS_CLK9 0x4
> +#define QE_CMXGCR_USBCS_CLK13 0x5
> +#define QE_CMXGCR_USBCS_CLK17 0x6
> +#define QE_CMXGCR_USBCS_CLK19 0x7
> +#define QE_CMXGCR_USBCS_CLK21 0x8
> +#define QE_CMXGCR_USBCS_BRG9 0x9
> +#define QE_CMXGCR_USBCS_BRG10 0xa
>
> /* QE CECR Commands.
> */
> @@ -283,7 +299,7 @@ enum comm_dir {
> #define QE_HPAC_START_TX 0x0000060b
> #define QE_HPAC_START_RX 0x0000070b
> #define QE_USB_STOP_TX 0x0000000a
> -#define QE_USB_RESTART_TX 0x0000000b
> +#define QE_USB_RESTART_TX 0x0000000c
> #define QE_QMC_STOP_TX 0x0000000c
> #define QE_QMC_STOP_RX 0x0000000d
> #define QE_SS7_SU_FIL_RESET 0x0000000e
> --
> 1.5.2.2
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] Make rheap safe for spinlocks
From: Timur Tabi @ 2008-04-14 20:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <30C5925E-31F7-4E52-95C9-43DB0DE68A9F@kernel.crashing.org>
Kumar Gala wrote:
> Is this need to fix a bug with an existing driver of for a new driver?
Both. The ucc_geth driver calls qe_muram_alloc() with spinlocks held. The 8610
DIU driver does something similar, but it's targeted for 2.6.26.
I'm hesitant to recommend inclusion in 2.6.25 because I haven't tested the fix
throughly enough to know that it doesn't break something else. Technically, it
could result in qe_muram_alloc() failing.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] Make rheap safe for spinlocks
From: Kumar Gala @ 2008-04-14 19:58 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, paulus
In-Reply-To: <12081878182664-git-send-email-timur@freescale.com>
On Apr 14, 2008, at 10:43 AM, Timur Tabi wrote:
> The rheap allocation function, rh_alloc, could call kmalloc with
> GFP_KERNEL.
> This can sleep, which means you couldn't hold a spinlock while
> called rh_alloc.
> Change all kmalloc calls to use GFP_ATOMIC so that it won't sleep.
> This is
> safe because only small blocks are allocated.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> This patch is for 2.6.26.
Is this need to fix a bug with an existing driver of for a new driver?
- k
^ permalink raw reply
* Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
From: Andrew Morton @ 2008-04-14 19:03 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, jirislaby, linux-kernel, yorksun
In-Reply-To: <48037C55.7060105@freescale.com>
On Mon, 14 Apr 2008 10:46:29 -0500
Timur Tabi <timur@freescale.com> wrote:
> Jiri Slaby wrote:
>
> > Mainly because you can sleep inside locked mutex and because spinlock shouldn't
> > be used for too many lines of code (busy waiting etc.). I think ldd3 will be
> > more descriptive than me here :).
>
> Ok, I'll look into it.
>
> Andrew, do you want us to respin the patch, or would you be willing to let us
> make the change in a follow-up patch?
A fix against rc8-mm3 would be ideal for me. But a replacement patch is OK
too - I'd convert that into an incremental so I can see what changed anyway.
Others might find the replacement patch harder to review though...
^ permalink raw reply
* Re: Problems of using APU/FPU under linux
From: John Bonesio @ 2008-04-14 18:32 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: Shanyuan Gao, git, linuxppc-embedded
In-Reply-To: <977C41F842E66D4CB2E41332313B615005CB0A39@XSJ-EXCHVS1.xlnx.xilinx.com>
Hi,
The Linux kernel itself doesn't issue floating point instructions other than to save and restore the fpu state when necessary.
In Linux, the way it saves and restores the fpu state is to make use of the trap. When the trap (fpu unavailable) occurs, it loads the fpu state for the current task, sets up the MSR, and returns to re-try the instruction.
So, getting the trap is normal. If the FPU is not being set up correctly, then there may be a problem with the restoring of the state.
When you guild the Linux kernel, you need to have CONFIG_PPC_FPU enabled. Otherwise the kernel does not setup the fpu exception handling.
- John
On Monday 14 April 2008 10:35, Stephen Neuendorffer wrote:
>
> I'm not sure exactly what's going on here. Generally speaking, if you
> have the FPU instantiated in the design and enable the APU in the msr,
> then the processor should decode FP instructions and send them directly
> to the APU with no trap. I haven't done this myself, or I could
> probably give you some better help...
>
> One thing you should be aware of is that the there are gcc compiler
> patches which are necessary to get the FPU working properly. However, I
> don't think the failure mode that these patches workaround would cause a
> trap, so my guess is that there is still something else wrong.
>
> Steve
>
> > -----Original Message-----
> > From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
> [mailto:linuxppc-embedded-
> > bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of Shanyuan
> Gao
> > Sent: Monday, April 14, 2008 9:18 AM
> > To: linuxppc-embedded@ozlabs.org
> > Subject: Problems of using APU/FPU under linux
> >
> > Hi,
> >
> > Recently I was trying to make APU/FPU working under Linux on Xilinx
> > ML410. The standalone programs work perfectly. However under Linux,
> > when I try to use a floating point operation, like *fmuls*, it will
> > give me a *trap*.
> >
> > By studying the user guide from Xilinx and dumping the object files,
> > I know I need to change the corresponding bits (APU enable, FP
> > enable, maybe APU Exception enable) in Machine State Register. I
> > guess I need to enable the bits whenever before the kernel uses
> > *mtmsr*. However, it doesn't work. I got the same trap with the same
> > MSR, as I had no APU/FPU before. I also tried to add the FPU.S to ppc
> > tree, but it doesn't work either.
> >
> > The questions are
> > 1. I guess there might be some place that changed MSR after all my
> > changes. But I don't know where. And can I write a kernel module to
> > change the MSR after booting in Linux? (well, it's hard for me though)
> >
> > 2. Does it have any exception/interrupt mechanism to direct FP
> > operation to APU/FPU? Or after enabling APU/FPU it will mask the
> > exception/interrupt and decode FP operation by itself?
> >
> >
> > Any ideas are appreciated. Thank you very much!
> >
> >
> > Shan
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* [PATCH rebased][POWERPC] qe_lib and ucc_geth: switch to the cpm_muram implementation
From: Anton Vorontsov @ 2008-04-14 18:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Jeff Garzik, Timur Tabi, netdev
In-Reply-To: <20080320173945.GA8446@localhost.localdomain>
This is very trivial patch. We're transitioning to the cpm_muram_*
calls. That's it.
Less trivial changes:
- BD_SC_* defines were defined in the cpm.h and qe.h, so to avoid redefines
we remove BD_SC from the qe.h and use cpm.h along with cpm_muram_*
prototypes;
- qe_muram_dump was unused and thus removed;
- added some code to the cpm_common.c to support legacy QE bindings
(data-only node name).
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
Rebased on top of today's galak/powerpc.git.
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/cpm_common.c | 16 +++++-
arch/powerpc/sysdev/qe_lib/qe.c | 96 +--------------------------------
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 8 ++--
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 18 +++---
drivers/net/ucc_geth.c | 96 ++++++++++++++++----------------
include/asm-powerpc/cpm.h | 1 +
include/asm-powerpc/qe.h | 29 +----------
8 files changed, 79 insertions(+), 186 deletions(-)
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 6d386d0..42b44a1 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -40,6 +40,7 @@ endif
ifeq ($(ARCH),powerpc)
obj-$(CONFIG_CPM) += cpm_common.o
obj-$(CONFIG_CPM2) += cpm2.o cpm2_pic.o
+obj-$(CONFIG_QUICC_ENGINE) += cpm_common.o
obj-$(CONFIG_PPC_DCR) += dcr.o
obj-$(CONFIG_8xx) += mpc8xx_pic.o cpm1.o
obj-$(CONFIG_UCODE_PATCH) += micropatch.o
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index cb7df2d..57d78fa 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -85,9 +85,13 @@ int __init cpm_muram_init(void)
np = of_find_compatible_node(NULL, NULL, "fsl,cpm-muram-data");
if (!np) {
- printk(KERN_ERR "Cannot find CPM muram data node");
- ret = -ENODEV;
- goto out;
+ /* try legacy bindings */
+ np = of_find_node_by_name(NULL, "data-only");
+ if (!np) {
+ printk(KERN_ERR "Cannot find CPM muram data node");
+ ret = -ENODEV;
+ goto out;
+ }
}
muram_pbase = of_translate_address(np, zero);
@@ -189,6 +193,12 @@ void __iomem *cpm_muram_addr(unsigned long offset)
}
EXPORT_SYMBOL(cpm_muram_addr);
+unsigned long cpm_muram_offset(void __iomem *addr)
+{
+ return addr - muram_vbase;
+}
+EXPORT_SYMBOL(cpm_muram_offset);
+
/**
* cpm_muram_dma - turn a muram virtual address into a DMA address
* @offset: virtual address from cpm_muram_addr() to convert
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index cff550e..4b48094 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -35,7 +35,6 @@
#include <asm/rheap.h>
static void qe_snums_init(void);
-static void qe_muram_init(void);
static int qe_sdma_init(void);
static DEFINE_SPINLOCK(qe_lock);
@@ -99,7 +98,7 @@ void qe_reset(void)
QE_CR_PROTOCOL_UNSPECIFIED, 0);
/* Reclaim the MURAM memory for our use. */
- qe_muram_init();
+ cpm_muram_init();
if (qe_sdma_init())
panic("sdma init failed!");
@@ -314,7 +313,7 @@ static int qe_sdma_init(void)
/* allocate 2 internal temporary buffers (512 bytes size each) for
* the SDMA */
- sdma_buf_offset = qe_muram_alloc(512 * 2, 4096);
+ sdma_buf_offset = cpm_muram_alloc(512 * 2, 4096);
if (IS_ERR_VALUE(sdma_buf_offset))
return -ENOMEM;
@@ -325,97 +324,6 @@ static int qe_sdma_init(void)
return 0;
}
-/*
- * muram_alloc / muram_free bits.
- */
-static DEFINE_SPINLOCK(qe_muram_lock);
-
-/* 16 blocks should be enough to satisfy all requests
- * until the memory subsystem goes up... */
-static rh_block_t qe_boot_muram_rh_block[16];
-static rh_info_t qe_muram_info;
-
-static void qe_muram_init(void)
-{
- struct device_node *np;
- const u32 *address;
- u64 size;
- unsigned int flags;
-
- /* initialize the info header */
- rh_init(&qe_muram_info, 1,
- sizeof(qe_boot_muram_rh_block) /
- sizeof(qe_boot_muram_rh_block[0]), qe_boot_muram_rh_block);
-
- /* Attach the usable muram area */
- /* XXX: This is a subset of the available muram. It
- * varies with the processor and the microcode patches activated.
- */
- np = of_find_compatible_node(NULL, NULL, "fsl,qe-muram-data");
- if (!np) {
- np = of_find_node_by_name(NULL, "data-only");
- if (!np) {
- WARN_ON(1);
- return;
- }
- }
-
- address = of_get_address(np, 0, &size, &flags);
- WARN_ON(!address);
-
- of_node_put(np);
- if (address)
- rh_attach_region(&qe_muram_info, *address, (int)size);
-}
-
-/* This function returns an index into the MURAM area.
- */
-unsigned long qe_muram_alloc(int size, int align)
-{
- unsigned long start;
- unsigned long flags;
-
- spin_lock_irqsave(&qe_muram_lock, flags);
- start = rh_alloc_align(&qe_muram_info, size, align, "QE");
- spin_unlock_irqrestore(&qe_muram_lock, flags);
-
- return start;
-}
-EXPORT_SYMBOL(qe_muram_alloc);
-
-int qe_muram_free(unsigned long offset)
-{
- int ret;
- unsigned long flags;
-
- spin_lock_irqsave(&qe_muram_lock, flags);
- ret = rh_free(&qe_muram_info, offset);
- spin_unlock_irqrestore(&qe_muram_lock, flags);
-
- return ret;
-}
-EXPORT_SYMBOL(qe_muram_free);
-
-/* not sure if this is ever needed */
-unsigned long qe_muram_alloc_fixed(unsigned long offset, int size)
-{
- unsigned long start;
- unsigned long flags;
-
- spin_lock_irqsave(&qe_muram_lock, flags);
- start = rh_alloc_fixed(&qe_muram_info, offset, size, "commproc");
- spin_unlock_irqrestore(&qe_muram_lock, flags);
-
- return start;
-}
-EXPORT_SYMBOL(qe_muram_alloc_fixed);
-
-void qe_muram_dump(void)
-{
- rh_dump(&qe_muram_info);
-}
-EXPORT_SYMBOL(qe_muram_dump);
-
/* The maximum number of RISCs we support */
#define MAX_QE_RISC 2
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
index bcf88e6..559678d 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
@@ -267,7 +267,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private ** ucc
/* Allocate memory for Tx Virtual Fifo */
uccf->ucc_fast_tx_virtual_fifo_base_offset =
- qe_muram_alloc(uf_info->utfs, UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
+ cpm_muram_alloc(uf_info->utfs, UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
if (IS_ERR_VALUE(uccf->ucc_fast_tx_virtual_fifo_base_offset)) {
printk(KERN_ERR "%s: cannot allocate MURAM for TX FIFO\n",
__func__);
@@ -278,7 +278,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private ** ucc
/* Allocate memory for Rx Virtual Fifo */
uccf->ucc_fast_rx_virtual_fifo_base_offset =
- qe_muram_alloc(uf_info->urfs +
+ cpm_muram_alloc(uf_info->urfs +
UCC_FAST_RECEIVE_VIRTUAL_FIFO_SIZE_FUDGE_FACTOR,
UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
if (IS_ERR_VALUE(uccf->ucc_fast_rx_virtual_fifo_base_offset)) {
@@ -350,10 +350,10 @@ void ucc_fast_free(struct ucc_fast_private * uccf)
return;
if (uccf->ucc_fast_tx_virtual_fifo_base_offset)
- qe_muram_free(uccf->ucc_fast_tx_virtual_fifo_base_offset);
+ cpm_muram_free(uccf->ucc_fast_tx_virtual_fifo_base_offset);
if (uccf->ucc_fast_rx_virtual_fifo_base_offset)
- qe_muram_free(uccf->ucc_fast_rx_virtual_fifo_base_offset);
+ cpm_muram_free(uccf->ucc_fast_rx_virtual_fifo_base_offset);
kfree(uccf);
}
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_slow.c b/arch/powerpc/sysdev/qe_lib/ucc_slow.c
index a578bc7..49e6949 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_slow.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_slow.c
@@ -187,7 +187,7 @@ int ucc_slow_init(struct ucc_slow_info * us_info, struct ucc_slow_private ** ucc
/* Get PRAM base */
uccs->us_pram_offset =
- qe_muram_alloc(UCC_SLOW_PRAM_SIZE, ALIGNMENT_OF_UCC_SLOW_PRAM);
+ cpm_muram_alloc(UCC_SLOW_PRAM_SIZE, ALIGNMENT_OF_UCC_SLOW_PRAM);
if (IS_ERR_VALUE(uccs->us_pram_offset)) {
printk(KERN_ERR "%s: cannot allocate MURAM for PRAM", __func__);
ucc_slow_free(uccs);
@@ -197,7 +197,7 @@ int ucc_slow_init(struct ucc_slow_info * us_info, struct ucc_slow_private ** ucc
qe_issue_cmd(QE_ASSIGN_PAGE_TO_DEVICE, id, us_info->protocol,
uccs->us_pram_offset);
- uccs->us_pram = qe_muram_addr(uccs->us_pram_offset);
+ uccs->us_pram = cpm_muram_addr(uccs->us_pram_offset);
/* Set UCC to slow type */
ret = ucc_set_type(us_info->ucc_num, UCC_SPEED_TYPE_SLOW);
@@ -213,7 +213,7 @@ int ucc_slow_init(struct ucc_slow_info * us_info, struct ucc_slow_private ** ucc
/* Allocate BDs. */
uccs->rx_base_offset =
- qe_muram_alloc(us_info->rx_bd_ring_len * sizeof(struct qe_bd),
+ cpm_muram_alloc(us_info->rx_bd_ring_len * sizeof(struct qe_bd),
QE_ALIGNMENT_OF_BD);
if (IS_ERR_VALUE(uccs->rx_base_offset)) {
printk(KERN_ERR "%s: cannot allocate %u RX BDs\n", __func__,
@@ -224,7 +224,7 @@ int ucc_slow_init(struct ucc_slow_info * us_info, struct ucc_slow_private ** ucc
}
uccs->tx_base_offset =
- qe_muram_alloc(us_info->tx_bd_ring_len * sizeof(struct qe_bd),
+ cpm_muram_alloc(us_info->tx_bd_ring_len * sizeof(struct qe_bd),
QE_ALIGNMENT_OF_BD);
if (IS_ERR_VALUE(uccs->tx_base_offset)) {
printk(KERN_ERR "%s: cannot allocate TX BDs", __func__);
@@ -234,7 +234,7 @@ int ucc_slow_init(struct ucc_slow_info * us_info, struct ucc_slow_private ** ucc
}
/* Init Tx bds */
- bd = uccs->confBd = uccs->tx_bd = qe_muram_addr(uccs->tx_base_offset);
+ bd = uccs->confBd = uccs->tx_bd = cpm_muram_addr(uccs->tx_base_offset);
for (i = 0; i < us_info->tx_bd_ring_len - 1; i++) {
/* clear bd buffer */
out_be32(&bd->buf, 0);
@@ -247,7 +247,7 @@ int ucc_slow_init(struct ucc_slow_info * us_info, struct ucc_slow_private ** ucc
out_be32((u32 *) bd, cpu_to_be32(T_W));
/* Init Rx bds */
- bd = uccs->rx_bd = qe_muram_addr(uccs->rx_base_offset);
+ bd = uccs->rx_bd = cpm_muram_addr(uccs->rx_base_offset);
for (i = 0; i < us_info->rx_bd_ring_len - 1; i++) {
/* set bd status and length */
out_be32((u32*)bd, 0);
@@ -362,13 +362,13 @@ void ucc_slow_free(struct ucc_slow_private * uccs)
return;
if (uccs->rx_base_offset)
- qe_muram_free(uccs->rx_base_offset);
+ cpm_muram_free(uccs->rx_base_offset);
if (uccs->tx_base_offset)
- qe_muram_free(uccs->tx_base_offset);
+ cpm_muram_free(uccs->tx_base_offset);
if (uccs->us_pram) {
- qe_muram_free(uccs->us_pram_offset);
+ cpm_muram_free(uccs->us_pram_offset);
uccs->us_pram = NULL;
}
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index ed84182..ba30a25 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -299,7 +299,7 @@ static int fill_init_enet_entries(struct ucc_geth_private *ugeth,
init_enet_offset = 0;
else {
init_enet_offset =
- qe_muram_alloc(thread_size, thread_alignment);
+ cpm_muram_alloc(thread_size, thread_alignment);
if (IS_ERR_VALUE(init_enet_offset)) {
if (netif_msg_ifup(ugeth))
ugeth_err("fill_init_enet_entries: Can not allocate DPRAM memory.");
@@ -338,7 +338,7 @@ static int return_init_enet_entries(struct ucc_geth_private *ugeth,
init_enet_offset =
(in_be32(p_start) &
ENET_INIT_PARAM_PTR_MASK);
- qe_muram_free(init_enet_offset);
+ cpm_muram_free(init_enet_offset);
}
*(p_start++) = 0; /* Just for cosmetics */
}
@@ -375,8 +375,8 @@ static int dump_init_enet_entries(struct ucc_geth_private *ugeth,
ugeth_info("Init enet entry %d:", i);
ugeth_info("Base address: 0x%08x",
(u32)
- qe_muram_addr(init_enet_offset));
- mem_disp(qe_muram_addr(init_enet_offset),
+ cpm_muram_addr(init_enet_offset));
+ mem_disp(cpm_muram_addr(init_enet_offset),
thread_size);
}
p_start++;
@@ -1085,11 +1085,11 @@ static void dump_regs(struct ucc_geth_private *ugeth)
ugeth_info("ucode RX Prefetched BDs:");
ugeth_info("Base address: 0x%08x",
(u32)
- qe_muram_addr(in_be32
+ cpm_muram_addr(in_be32
(&ugeth->p_rx_bd_qs_tbl[i].
bdbaseptr)));
mem_disp((u8 *)
- qe_muram_addr(in_be32
+ cpm_muram_addr(in_be32
(&ugeth->p_rx_bd_qs_tbl[i].
bdbaseptr)),
sizeof(struct ucc_geth_rx_prefetched_bds));
@@ -2090,47 +2090,47 @@ static void ucc_geth_memclean(struct ucc_geth_private *ugeth)
}
if (ugeth->p_thread_data_tx) {
- qe_muram_free(ugeth->thread_dat_tx_offset);
+ cpm_muram_free(ugeth->thread_dat_tx_offset);
ugeth->p_thread_data_tx = NULL;
}
if (ugeth->p_thread_data_rx) {
- qe_muram_free(ugeth->thread_dat_rx_offset);
+ cpm_muram_free(ugeth->thread_dat_rx_offset);
ugeth->p_thread_data_rx = NULL;
}
if (ugeth->p_exf_glbl_param) {
- qe_muram_free(ugeth->exf_glbl_param_offset);
+ cpm_muram_free(ugeth->exf_glbl_param_offset);
ugeth->p_exf_glbl_param = NULL;
}
if (ugeth->p_rx_glbl_pram) {
- qe_muram_free(ugeth->rx_glbl_pram_offset);
+ cpm_muram_free(ugeth->rx_glbl_pram_offset);
ugeth->p_rx_glbl_pram = NULL;
}
if (ugeth->p_tx_glbl_pram) {
- qe_muram_free(ugeth->tx_glbl_pram_offset);
+ cpm_muram_free(ugeth->tx_glbl_pram_offset);
ugeth->p_tx_glbl_pram = NULL;
}
if (ugeth->p_send_q_mem_reg) {
- qe_muram_free(ugeth->send_q_mem_reg_offset);
+ cpm_muram_free(ugeth->send_q_mem_reg_offset);
ugeth->p_send_q_mem_reg = NULL;
}
if (ugeth->p_scheduler) {
- qe_muram_free(ugeth->scheduler_offset);
+ cpm_muram_free(ugeth->scheduler_offset);
ugeth->p_scheduler = NULL;
}
if (ugeth->p_tx_fw_statistics_pram) {
- qe_muram_free(ugeth->tx_fw_statistics_pram_offset);
+ cpm_muram_free(ugeth->tx_fw_statistics_pram_offset);
ugeth->p_tx_fw_statistics_pram = NULL;
}
if (ugeth->p_rx_fw_statistics_pram) {
- qe_muram_free(ugeth->rx_fw_statistics_pram_offset);
+ cpm_muram_free(ugeth->rx_fw_statistics_pram_offset);
ugeth->p_rx_fw_statistics_pram = NULL;
}
if (ugeth->p_rx_irq_coalescing_tbl) {
- qe_muram_free(ugeth->rx_irq_coalescing_tbl_offset);
+ cpm_muram_free(ugeth->rx_irq_coalescing_tbl_offset);
ugeth->p_rx_irq_coalescing_tbl = NULL;
}
if (ugeth->p_rx_bd_qs_tbl) {
- qe_muram_free(ugeth->rx_bd_qs_tbl_offset);
+ cpm_muram_free(ugeth->rx_bd_qs_tbl_offset);
ugeth->p_rx_bd_qs_tbl = NULL;
}
if (ugeth->p_init_enet_param_shadow) {
@@ -2171,7 +2171,7 @@ static void ucc_geth_memclean(struct ucc_geth_private *ugeth)
kfree((void *)ugeth->tx_bd_ring_offset[i]);
else if (ugeth->ug_info->uf_info.bd_mem_part ==
MEM_PART_MURAM)
- qe_muram_free(ugeth->tx_bd_ring_offset[i]);
+ cpm_muram_free(ugeth->tx_bd_ring_offset[i]);
ugeth->p_tx_bd_ring[i] = NULL;
}
}
@@ -2201,7 +2201,7 @@ static void ucc_geth_memclean(struct ucc_geth_private *ugeth)
kfree((void *)ugeth->rx_bd_ring_offset[i]);
else if (ugeth->ug_info->uf_info.bd_mem_part ==
MEM_PART_MURAM)
- qe_muram_free(ugeth->rx_bd_ring_offset[i]);
+ cpm_muram_free(ugeth->rx_bd_ring_offset[i]);
ugeth->p_rx_bd_ring[i] = NULL;
}
}
@@ -2610,11 +2610,11 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
align) & ~(align - 1));
} else if (uf_info->bd_mem_part == MEM_PART_MURAM) {
ugeth->tx_bd_ring_offset[j] =
- qe_muram_alloc(length,
+ cpm_muram_alloc(length,
UCC_GETH_TX_BD_RING_ALIGNMENT);
if (!IS_ERR_VALUE(ugeth->tx_bd_ring_offset[j]))
ugeth->p_tx_bd_ring[j] =
- (u8 *) qe_muram_addr(ugeth->
+ (u8 *) cpm_muram_addr(ugeth->
tx_bd_ring_offset[j]);
}
if (!ugeth->p_tx_bd_ring[j]) {
@@ -2646,11 +2646,11 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
align) & ~(align - 1));
} else if (uf_info->bd_mem_part == MEM_PART_MURAM) {
ugeth->rx_bd_ring_offset[j] =
- qe_muram_alloc(length,
+ cpm_muram_alloc(length,
UCC_GETH_RX_BD_RING_ALIGNMENT);
if (!IS_ERR_VALUE(ugeth->rx_bd_ring_offset[j]))
ugeth->p_rx_bd_ring[j] =
- (u8 *) qe_muram_addr(ugeth->
+ (u8 *) cpm_muram_addr(ugeth->
rx_bd_ring_offset[j]);
}
if (!ugeth->p_rx_bd_ring[j]) {
@@ -2733,7 +2733,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
/* Tx global PRAM */
/* Allocate global tx parameter RAM page */
ugeth->tx_glbl_pram_offset =
- qe_muram_alloc(sizeof(struct ucc_geth_tx_global_pram),
+ cpm_muram_alloc(sizeof(struct ucc_geth_tx_global_pram),
UCC_GETH_TX_GLOBAL_PRAM_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->tx_glbl_pram_offset)) {
if (netif_msg_ifup(ugeth))
@@ -2744,7 +2744,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
return -ENOMEM;
}
ugeth->p_tx_glbl_pram =
- (struct ucc_geth_tx_global_pram *) qe_muram_addr(ugeth->
+ (struct ucc_geth_tx_global_pram *) cpm_muram_addr(ugeth->
tx_glbl_pram_offset);
/* Zero out p_tx_glbl_pram */
memset(ugeth->p_tx_glbl_pram, 0, sizeof(struct ucc_geth_tx_global_pram));
@@ -2754,7 +2754,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
/* TQPTR */
/* Size varies with number of Tx threads */
ugeth->thread_dat_tx_offset =
- qe_muram_alloc(numThreadsTxNumerical *
+ cpm_muram_alloc(numThreadsTxNumerical *
sizeof(struct ucc_geth_thread_data_tx) +
32 * (numThreadsTxNumerical == 1),
UCC_GETH_THREAD_DATA_ALIGNMENT);
@@ -2768,7 +2768,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
}
ugeth->p_thread_data_tx =
- (struct ucc_geth_thread_data_tx *) qe_muram_addr(ugeth->
+ (struct ucc_geth_thread_data_tx *) cpm_muram_addr(ugeth->
thread_dat_tx_offset);
out_be32(&ugeth->p_tx_glbl_pram->tqptr, ugeth->thread_dat_tx_offset);
@@ -2784,7 +2784,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
/* SQPTR */
/* Size varies with number of Tx queues */
ugeth->send_q_mem_reg_offset =
- qe_muram_alloc(ug_info->numQueuesTx *
+ cpm_muram_alloc(ug_info->numQueuesTx *
sizeof(struct ucc_geth_send_queue_qd),
UCC_GETH_SEND_QUEUE_QUEUE_DESCRIPTOR_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->send_q_mem_reg_offset)) {
@@ -2797,7 +2797,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
}
ugeth->p_send_q_mem_reg =
- (struct ucc_geth_send_queue_mem_region *) qe_muram_addr(ugeth->
+ (struct ucc_geth_send_queue_mem_region *) cpm_muram_addr(ugeth->
send_q_mem_reg_offset);
out_be32(&ugeth->p_tx_glbl_pram->sqptr, ugeth->send_q_mem_reg_offset);
@@ -2829,7 +2829,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
if (ug_info->numQueuesTx > 1) {
/* scheduler exists only if more than 1 tx queue */
ugeth->scheduler_offset =
- qe_muram_alloc(sizeof(struct ucc_geth_scheduler),
+ cpm_muram_alloc(sizeof(struct ucc_geth_scheduler),
UCC_GETH_SCHEDULER_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->scheduler_offset)) {
if (netif_msg_ifup(ugeth))
@@ -2841,7 +2841,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
}
ugeth->p_scheduler =
- (struct ucc_geth_scheduler *) qe_muram_addr(ugeth->
+ (struct ucc_geth_scheduler *) cpm_muram_addr(ugeth->
scheduler_offset);
out_be32(&ugeth->p_tx_glbl_pram->schedulerbasepointer,
ugeth->scheduler_offset);
@@ -2877,7 +2877,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
if (ug_info->
statisticsMode & UCC_GETH_STATISTICS_GATHERING_MODE_FIRMWARE_TX) {
ugeth->tx_fw_statistics_pram_offset =
- qe_muram_alloc(sizeof
+ cpm_muram_alloc(sizeof
(struct ucc_geth_tx_firmware_statistics_pram),
UCC_GETH_TX_STATISTICS_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->tx_fw_statistics_pram_offset)) {
@@ -2891,7 +2891,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
}
ugeth->p_tx_fw_statistics_pram =
(struct ucc_geth_tx_firmware_statistics_pram *)
- qe_muram_addr(ugeth->tx_fw_statistics_pram_offset);
+ cpm_muram_addr(ugeth->tx_fw_statistics_pram_offset);
/* Zero out p_tx_fw_statistics_pram */
memset(ugeth->p_tx_fw_statistics_pram,
0, sizeof(struct ucc_geth_tx_firmware_statistics_pram));
@@ -2919,7 +2919,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
/* Rx global PRAM */
/* Allocate global rx parameter RAM page */
ugeth->rx_glbl_pram_offset =
- qe_muram_alloc(sizeof(struct ucc_geth_rx_global_pram),
+ cpm_muram_alloc(sizeof(struct ucc_geth_rx_global_pram),
UCC_GETH_RX_GLOBAL_PRAM_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->rx_glbl_pram_offset)) {
if (netif_msg_ifup(ugeth))
@@ -2930,7 +2930,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
return -ENOMEM;
}
ugeth->p_rx_glbl_pram =
- (struct ucc_geth_rx_global_pram *) qe_muram_addr(ugeth->
+ (struct ucc_geth_rx_global_pram *) cpm_muram_addr(ugeth->
rx_glbl_pram_offset);
/* Zero out p_rx_glbl_pram */
memset(ugeth->p_rx_glbl_pram, 0, sizeof(struct ucc_geth_rx_global_pram));
@@ -2940,7 +2940,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
/* RQPTR */
/* Size varies with number of Rx threads */
ugeth->thread_dat_rx_offset =
- qe_muram_alloc(numThreadsRxNumerical *
+ cpm_muram_alloc(numThreadsRxNumerical *
sizeof(struct ucc_geth_thread_data_rx),
UCC_GETH_THREAD_DATA_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->thread_dat_rx_offset)) {
@@ -2953,7 +2953,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
}
ugeth->p_thread_data_rx =
- (struct ucc_geth_thread_data_rx *) qe_muram_addr(ugeth->
+ (struct ucc_geth_thread_data_rx *) cpm_muram_addr(ugeth->
thread_dat_rx_offset);
out_be32(&ugeth->p_rx_glbl_pram->rqptr, ugeth->thread_dat_rx_offset);
@@ -2964,7 +2964,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
if (ug_info->
statisticsMode & UCC_GETH_STATISTICS_GATHERING_MODE_FIRMWARE_RX) {
ugeth->rx_fw_statistics_pram_offset =
- qe_muram_alloc(sizeof
+ cpm_muram_alloc(sizeof
(struct ucc_geth_rx_firmware_statistics_pram),
UCC_GETH_RX_STATISTICS_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->rx_fw_statistics_pram_offset)) {
@@ -2977,7 +2977,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
}
ugeth->p_rx_fw_statistics_pram =
(struct ucc_geth_rx_firmware_statistics_pram *)
- qe_muram_addr(ugeth->rx_fw_statistics_pram_offset);
+ cpm_muram_addr(ugeth->rx_fw_statistics_pram_offset);
/* Zero out p_rx_fw_statistics_pram */
memset(ugeth->p_rx_fw_statistics_pram, 0,
sizeof(struct ucc_geth_rx_firmware_statistics_pram));
@@ -2987,7 +2987,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
/* Size varies with number of Rx queues */
ugeth->rx_irq_coalescing_tbl_offset =
- qe_muram_alloc(ug_info->numQueuesRx *
+ cpm_muram_alloc(ug_info->numQueuesRx *
sizeof(struct ucc_geth_rx_interrupt_coalescing_entry)
+ 4, UCC_GETH_RX_INTERRUPT_COALESCING_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->rx_irq_coalescing_tbl_offset)) {
@@ -3001,7 +3001,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
ugeth->p_rx_irq_coalescing_tbl =
(struct ucc_geth_rx_interrupt_coalescing_table *)
- qe_muram_addr(ugeth->rx_irq_coalescing_tbl_offset);
+ cpm_muram_addr(ugeth->rx_irq_coalescing_tbl_offset);
out_be32(&ugeth->p_rx_glbl_pram->intcoalescingptr,
ugeth->rx_irq_coalescing_tbl_offset);
@@ -3055,7 +3055,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
/* RBDQPTR */
/* Size varies with number of Rx queues */
ugeth->rx_bd_qs_tbl_offset =
- qe_muram_alloc(ug_info->numQueuesRx *
+ cpm_muram_alloc(ug_info->numQueuesRx *
(sizeof(struct ucc_geth_rx_bd_queues_entry) +
sizeof(struct ucc_geth_rx_prefetched_bds)),
UCC_GETH_RX_BD_QUEUES_ALIGNMENT);
@@ -3069,7 +3069,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
}
ugeth->p_rx_bd_qs_tbl =
- (struct ucc_geth_rx_bd_queues_entry *) qe_muram_addr(ugeth->
+ (struct ucc_geth_rx_bd_queues_entry *) cpm_muram_addr(ugeth->
rx_bd_qs_tbl_offset);
out_be32(&ugeth->p_rx_glbl_pram->rbdqptr, ugeth->rx_bd_qs_tbl_offset);
/* Zero out p_rx_bd_qs_tbl */
@@ -3148,7 +3148,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
/* Allocate memory for extended filtering Mode Global
Parameters */
ugeth->exf_glbl_param_offset =
- qe_muram_alloc(sizeof(struct ucc_geth_exf_global_pram),
+ cpm_muram_alloc(sizeof(struct ucc_geth_exf_global_pram),
UCC_GETH_RX_EXTENDED_FILTERING_GLOBAL_PARAMETERS_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->exf_glbl_param_offset)) {
if (netif_msg_ifup(ugeth))
@@ -3160,7 +3160,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
}
ugeth->p_exf_glbl_param =
- (struct ucc_geth_exf_global_pram *) qe_muram_addr(ugeth->
+ (struct ucc_geth_exf_global_pram *) cpm_muram_addr(ugeth->
exf_glbl_param_offset);
out_be32(&ugeth->p_rx_glbl_pram->exfGlobalParam,
ugeth->exf_glbl_param_offset);
@@ -3297,7 +3297,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
}
/* Allocate InitEnet command parameter structure */
- init_enet_pram_offset = qe_muram_alloc(sizeof(struct ucc_geth_init_pram), 4);
+ init_enet_pram_offset = cpm_muram_alloc(sizeof(struct ucc_geth_init_pram), 4);
if (IS_ERR_VALUE(init_enet_pram_offset)) {
if (netif_msg_ifup(ugeth))
ugeth_err
@@ -3307,7 +3307,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
return -ENOMEM;
}
p_init_enet_pram =
- (struct ucc_geth_init_pram *) qe_muram_addr(init_enet_pram_offset);
+ (struct ucc_geth_init_pram *) cpm_muram_addr(init_enet_pram_offset);
/* Copy shadow InitEnet command parameter structure into PRAM */
p_init_enet_pram->resinit1 = ugeth->p_init_enet_param_shadow->resinit1;
@@ -3336,7 +3336,7 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
init_enet_pram_offset);
/* Free InitEnet command parameter */
- qe_muram_free(init_enet_pram_offset);
+ cpm_muram_free(init_enet_pram_offset);
return 0;
}
diff --git a/include/asm-powerpc/cpm.h b/include/asm-powerpc/cpm.h
index ede38ff..63a5533 100644
--- a/include/asm-powerpc/cpm.h
+++ b/include/asm-powerpc/cpm.h
@@ -96,6 +96,7 @@ unsigned long cpm_muram_alloc(unsigned long size, unsigned long align);
int cpm_muram_free(unsigned long offset);
unsigned long cpm_muram_alloc_fixed(unsigned long offset, unsigned long size);
void __iomem *cpm_muram_addr(unsigned long offset);
+unsigned long cpm_muram_offset(void __iomem *addr);
dma_addr_t cpm_muram_dma(void __iomem *addr);
int cpm_command(u32 command, u8 opcode);
diff --git a/include/asm-powerpc/qe.h b/include/asm-powerpc/qe.h
index c3be6e2..54864dd 100644
--- a/include/asm-powerpc/qe.h
+++ b/include/asm-powerpc/qe.h
@@ -16,6 +16,7 @@
#define _ASM_POWERPC_QE_H
#ifdef __KERNEL__
+#include <asm/cpm.h>
#include <asm/immap_qe.h>
#define QE_NUM_OF_SNUM 28
@@ -89,20 +90,6 @@ unsigned int qe_get_brg_clk(void);
int qe_setbrg(enum qe_clock brg, unsigned int rate, unsigned int multiplier);
int qe_get_snum(void);
void qe_put_snum(u8 snum);
-unsigned long qe_muram_alloc(int size, int align);
-int qe_muram_free(unsigned long offset);
-unsigned long qe_muram_alloc_fixed(unsigned long offset, int size);
-void qe_muram_dump(void);
-
-static inline void __iomem *qe_muram_addr(unsigned long offset)
-{
- return (void __iomem *)&qe_immr->muram[offset];
-}
-
-static inline unsigned long qe_muram_offset(void __iomem *addr)
-{
- return addr - (void __iomem *)qe_immr->muram;
-}
/* Structure that defines QE firmware binary files.
*
@@ -166,20 +153,6 @@ struct qe_bd {
#define BD_STATUS_MASK 0xffff0000
#define BD_LENGTH_MASK 0x0000ffff
-#define BD_SC_EMPTY 0x8000 /* Receive is empty */
-#define BD_SC_READY 0x8000 /* Transmit is ready */
-#define BD_SC_WRAP 0x2000 /* Last buffer descriptor */
-#define BD_SC_INTRPT 0x1000 /* Interrupt on change */
-#define BD_SC_LAST 0x0800 /* Last buffer in frame */
-#define BD_SC_CM 0x0200 /* Continous mode */
-#define BD_SC_ID 0x0100 /* Rec'd too many idles */
-#define BD_SC_P 0x0100 /* xmt preamble */
-#define BD_SC_BR 0x0020 /* Break received */
-#define BD_SC_FR 0x0010 /* Framing error */
-#define BD_SC_PR 0x0008 /* Parity error */
-#define BD_SC_OV 0x0002 /* Overrun */
-#define BD_SC_CD 0x0001 /* ?? */
-
/* Alignment */
#define QE_INTR_TABLE_ALIGN 16 /* ??? */
#define QE_ALIGNMENT_OF_BD 8
--
1.5.5
^ permalink raw reply related
* Re: [PATCH 0/8] A bit of new code and sparse cleanups along the way
From: Anton Vorontsov @ 2008-04-14 17:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <4064F5C3-0A62-4331-9116-764347AEC090@kernel.crashing.org>
On Mon, Apr 14, 2008 at 10:14:05AM -0500, Kumar Gala wrote:
>
> On Mar 11, 2008, at 12:21 PM, Anton Vorontsov wrote:
>> Hi all,
>>
>> Please consider these patches for the 2.6.26.
>
> I've applied most of these patches to my powerpc-next branch.
Thanks!
> The
> following two patches have NOT been applied:
>
> [POWERPC] sysdev,qe_lib: implement FSL GTM support
> [POWERPC] qe_lib: add support for QE USB
>
> It seemed there was rework required to the sysdev,qe_lib patch.
I can't recall any issues with "[POWERPC] qe_lib: add support for QE USB".
As for FSL GTM.. yes, I'll send updated version soon.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Get new_emac driver running on 405EP
From: M B @ 2008-04-14 17:38 UTC (permalink / raw)
To: ppc-dev
Hi,
I'm trying to get the new_emac driver (linux 2.6.25-rc8) running on my
405EP board with a KSZ8721BT Micrel/Kendin PHY.
I've already found 2 problems/missing features:
1) 100 retries in __emac_mdio_read for the read to complete are
slightly too less. 101 seem to be enough. But we could add a bit more,
because there is no negative effect for faster chips.
2) On the 405EP only the MDIO pin of the emac0 is pinned out, so both
phys have to be accessed through this one. This affectes the mdio
read/write functions.
I've already hacked around this problems, but ethernet is still not working.
After bringing up the device dmesg is flooded with this section.
emac/plb/opb/ethernet@ef600800: link timer
emac/plb/opb/ethernet@ef600800: mdio_read(00,01)
emac/plb/opb/ethernet@ef600800: mdio_read -> 786d
emac/plb/opb/ethernet@ef600800: mdio_read(00,01)
emac/plb/opb/ethernet@ef600800: mdio_read -> 786d
Any ideas where I should start looking?
Best Regards
Markus
A ping doesn't work
==============
# ifconfig eth0 1.1.1.1
eth0: link is up, 100 FDX, pause enabled
# ping 1.1.1.1 -c1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
--- 1.1.1.1 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
No data gets transmitted
==================
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:50:C2:1E:AF:FE
inet addr:1.1.1.1 Bcast:1.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:23
And no interrupts triggered
===================
# cat /proc/interrupts
CPU0
16: 737 UIC Level serial
18: 0 UIC Level MAL TX EOB
19: 0 UIC Level MAL RX EOB
20: 0 UIC Level MAL SERR
21: 0 UIC Level MAL TX DE
22: 0 UIC Level MAL RX DE
BAD: 0
dmesg section after boot, debug level of emac driver is 3
=========================================
ef600400.serial: ttyS1 at MMIO 0xef600400 (irq = 17) is a 16550A
PPC 4xx OCP EMAC driver, version 3.54
mal/plb/mcmal: probe
mal/plb/mcmal: reset
mal/plb/mcmal: enable_irq
MAL v1 /plb/mcmal, 4 TX channels, 4 RX channels
emac/plb/opb/ethernet@ef600800: features : 0x00000000 / 0x00000000
emac/plb/opb/ethernet@ef600800: tx_fifo_size : 2048 (2048 gige)
emac/plb/opb/ethernet@ef600800: rx_fifo_size : 4096 (4096 gige)
emac/plb/opb/ethernet@ef600800: max_mtu : 1500
emac/plb/opb/ethernet@ef600800: OPB freq : 66000000
mal/plb/mcmal: reg(80000000, 80000000)
emac/plb/opb/ethernet@ef600800: tx_desc ff100000
emac/plb/opb/ethernet@ef600800: rx_desc ff100800
emac/plb/opb/ethernet@ef600800: PHY maps 00000000 00000000
emac/plb/opb/ethernet@ef600800: configure
emac/plb/opb/ethernet@ef600800: reset
emac/plb/opb/ethernet@ef600800: rx_disable
emac/plb/opb/ethernet@ef600800: tx_disable
emac/plb/opb/ethernet@ef600800: link = 1 duplex = 1, pause = 0, asym_pause = 0
emac/plb/opb/ethernet@ef600800: __emac_calc_base_mr1
emac/plb/opb/ethernet@ef600800: mdio_read(00,00)
emac/plb/opb/ethernet@ef600800: mdio_read -> 3100
emac/plb/opb/ethernet@ef600800: mdio_read(00,00)
emac/plb/opb/ethernet@ef600800: mdio_read -> 3100
emac/plb/opb/ethernet@ef600800: mdio_write(00,00,a100)
emac/plb/opb/ethernet@ef600800: mdio_read(00,00)
emac/plb/opb/ethernet@ef600800: mdio_read -> 3100
emac/plb/opb/ethernet@ef600800: mdio_read(00,02)
emac/plb/opb/ethernet@ef600800: mdio_read -> 0022
emac/plb/opb/ethernet@ef600800: mdio_read(00,03)
emac/plb/opb/ethernet@ef600800: mdio_read -> 1619
emac/plb/opb/ethernet@ef600800: mdio_read(00,01)
emac/plb/opb/ethernet@ef600800: mdio_read -> 7849
emac/plb/opb/ethernet@ef600800: mdio_read(00,00)
emac/plb/opb/ethernet@ef600800: mdio_read -> 3100
emac/plb/opb/ethernet@ef600800: mdio_write(00,00,0000)
emac/plb/opb/ethernet@ef600800: mdio_read(00,04)
emac/plb/opb/ethernet@ef600800: mdio_read -> 01e1
emac/plb/opb/ethernet@ef600800: mdio_write(00,04,0de1)
emac/plb/opb/ethernet@ef600800: mdio_read(00,00)
emac/plb/opb/ethernet@ef600800: mdio_read -> 0000
emac/plb/opb/ethernet@ef600800: mdio_write(00,00,1200)
emac/plb/opb/ethernet@ef600800: stats
eth0: EMAC-0 /plb/opb/ethernet@ef600800, MAC 00:50:c2:1e:af:fe
eth0: found Generic MII PHY (0x00)
emac/plb/opb/ethernet@ef600900: features : 0x00000000 / 0x00000000
emac/plb/opb/ethernet@ef600900: tx_fifo_size : 2048 (2048 gige)
emac/plb/opb/ethernet@ef600900: rx_fifo_size : 4096 (4096 gige)
emac/plb/opb/ethernet@ef600900: max_mtu : 1500
emac/plb/opb/ethernet@ef600900: OPB freq : 66000000
mal/plb/mcmal: reg(20000000, 40000000)
emac/plb/opb/ethernet@ef600900: tx_desc ff100400
emac/plb/opb/ethernet@ef600900: rx_desc ff100c00
emac/plb/opb/ethernet@ef600900: PHY maps 00000020 00000001
emac/plb/opb/ethernet@ef600900: configure
emac/plb/opb/ethernet@ef600900: reset
emac/plb/opb/ethernet@ef600900: rx_disable
emac/plb/opb/ethernet@ef600900: tx_disable
emac/plb/opb/ethernet@ef600900: link = 1 duplex = 1, pause = 0, asym_pause = 0
emac/plb/opb/ethernet@ef600900: __emac_calc_base_mr1
emac/plb/opb/ethernet@ef600900: mdio_read(01,00)
emac/plb/opb/ethernet@ef600900: mdio_read -> 3100
emac/plb/opb/ethernet@ef600900: mdio_read(01,00)
emac/plb/opb/ethernet@ef600900: mdio_read -> 3100
emac/plb/opb/ethernet@ef600900: mdio_write(01,00,a100)
emac/plb/opb/ethernet@ef600900: mdio_read(01,00)
emac/plb/opb/ethernet@ef600900: mdio_read -> 3100
emac/plb/opb/ethernet@ef600900: mdio_read(01,02)
emac/plb/opb/ethernet@ef600900: mdio_read -> 0022
emac/plb/opb/ethernet@ef600900: mdio_read(01,03)
emac/plb/opb/ethernet@ef600900: mdio_read -> 1619
emac/plb/opb/ethernet@ef600900: mdio_read(01,01)
emac/plb/opb/ethernet@ef600900: mdio_read -> 7849
emac/plb/opb/ethernet@ef600900: mdio_read(01,00)
emac/plb/opb/ethernet@ef600900: mdio_read -> 3100
emac/plb/opb/ethernet@ef600900: mdio_write(01,00,0000)
emac/plb/opb/ethernet@ef600900: mdio_read(01,04)
emac/plb/opb/ethernet@ef600900: mdio_read -> 01e1
emac/plb/opb/ethernet@ef600900: mdio_write(01,04,0de1)
emac/plb/opb/ethernet@ef600900: mdio_read(01,00)
emac/plb/opb/ethernet@ef600900: mdio_read -> 0000
emac/plb/opb/ethernet@ef600900: mdio_write(01,00,1200)
emac/plb/opb/ethernet@ef600900: stats
eth1: EMAC-1 /plb/opb/ethernet@ef600900, MAC 00:50:c2:1e:af:fd
eth1: found Generic MII PHY (0x01)
TCP cubic registered
Mal and emac sections of my device tree
==============================
MAL: mcmal {
compatible = "ibm,mcmal-405ep", "ibm,mcmal";
dcr-reg = <180 62>;
num-tx-chans = <4>;
num-rx-chans = <4>;
interrupt-parent = <&UIC0>;
interrupts = <
a 4 /* SERR */
b 4 /* TXEOB */
c 4 /* RXEOB */
d 4 /* TXDE */
e 4 /* RXDE */>;
};
POB0: opb {
compatible = "ibm,opb-405ep", "ibm,opb";
#address-cells = <1>;
#size-cells = <1>;
ranges = <ef600000 ef600000 a00000>;
dcr-reg = <0a0 5>;
clock-frequency = <3EF1480>;
EMAC0: ethernet@ef600800 {
linux,network-index = <0>;
device_type = "network";
compatible = "ibm,emac-405ep", "ibm,emac";
interrupt-parent = <&UIC0>;
interrupts = <
f 4 /* Ethernet */
9 4 /* Ethernet Wake Up */>;
local-mac-address = [0050c21eaffe]; /* Filled in by zImage */
reg = <ef600800 70>;
mal-device = <&MAL>;
mal-tx-channel = <0>;
mal-rx-channel = <0>;
cell-index = <0>;
max-frame-size = <5dc>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "mii";
phy-map = <00000000>;
};
EMAC1: ethernet@ef600900 {
linux,network-index = <1>;
device_type = "network";
compatible = "ibm,emac-405ep", "ibm,emac";
interrupt-parent = <&UIC0>;
interrupts = <
11 4 /* Ethernet */
9 4 /* Ethernet Wake Up */>;
local-mac-address = [0050c21eaffd]; /* Filled in by zImage */
reg = <ef600900 70>;
mal-device = <&MAL>;
mal-tx-channel = <2>;
mal-rx-channel = <1>;
cell-index = <1>;
max-frame-size = <5dc>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "mii";
phy-map = <00000020>;
};
Kconfig section of emac
=================
CONFIG_PHYLIB=y
#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_ENC28J60 is not set
CONFIG_IBM_NEW_EMAC=y
CONFIG_IBM_NEW_EMAC_RXB=128
CONFIG_IBM_NEW_EMAC_TXB=64
CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=32
CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=256
CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=0
CONFIG_IBM_NEW_EMAC_DEBUG=y
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
^ permalink raw reply
* RE: Problems of using APU/FPU under linux
From: Stephen Neuendorffer @ 2008-04-14 17:35 UTC (permalink / raw)
To: Shanyuan Gao, linuxppc-embedded, git
In-Reply-To: <287479FF-A7FC-4B48-BE1E-FDDCB97D55A9@gmail.com>
I'm not sure exactly what's going on here. Generally speaking, if you
have the FPU instantiated in the design and enable the APU in the msr,
then the processor should decode FP instructions and send them directly
to the APU with no trap. I haven't done this myself, or I could
probably give you some better help...
One thing you should be aware of is that the there are gcc compiler
patches which are necessary to get the FPU working properly. However, I
don't think the failure mode that these patches workaround would cause a
trap, so my guess is that there is still something else wrong.
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Shanyuan
Gao
> Sent: Monday, April 14, 2008 9:18 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Problems of using APU/FPU under linux
>=20
> Hi,
>=20
> Recently I was trying to make APU/FPU working under Linux on Xilinx
> ML410. The standalone programs work perfectly. However under Linux,
> when I try to use a floating point operation, like *fmuls*, it will
> give me a *trap*.
>=20
> By studying the user guide from Xilinx and dumping the object files,
> I know I need to change the corresponding bits (APU enable, FP
> enable, maybe APU Exception enable) in Machine State Register. I
> guess I need to enable the bits whenever before the kernel uses
> *mtmsr*. However, it doesn't work. I got the same trap with the same
> MSR, as I had no APU/FPU before. I also tried to add the FPU.S to ppc
> tree, but it doesn't work either.
>=20
> The questions are
> 1. I guess there might be some place that changed MSR after all my
> changes. But I don't know where. And can I write a kernel module to
> change the MSR after booting in Linux? (well, it's hard for me though)
>=20
> 2. Does it have any exception/interrupt mechanism to direct FP
> operation to APU/FPU? Or after enabling APU/FPU it will mask the
> exception/interrupt and decode FP operation by itself?
>=20
>=20
> Any ideas are appreciated. Thank you very much!
>=20
>=20
> Shan
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH v2.6.26] gianfar: Determine TBIPA value dynamically
From: Andy Fleming @ 2008-04-14 16:55 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: netdev, linuxppc-dev
In-Reply-To: <20080411154914.GA19036@windriver.com>
On Apr 11, 2008, at 10:49, Paul Gortmaker wrote:
> In message: [PATCH v2.6.26] gianfar: Determine TBIPA value dynamically
> on 10/04/2008 Andy Fleming wrote:
>
>> TBIPA needs to be set to a value (on connected MDIO buses) that
>> doesn't
>> conflict with PHYs on the bus. By hardcoding it to 0x1f, we were
>> preventing
>> boards with PHYs at 0x1f from working properly. Instead, scan the
>> bus when
>> it comes up, and find an address that doesn't have a PHY on it.
>> The TBI PHY
>> configuration code then trusts that the value in TBIPA is either
>> safe, or
>> doesn't matter (ie - it's not an active bus with other PHYs).
>>
>> Signed-off-by: Andy Fleming <afleming@freescale.com>
>> ---
>>
>> I think this should go in, but I'd like to see some testing first.
>> I don't
>> have hardware which is affected by this. I've only confirmed that
>> it doesn't
>> break current hardware.
>
> I've tested on a board with the primary PHY at 0x1f, and it seems OK.
>
> I'f I'm understanding this correctly, you are explicitly setting TBIPA
> to zero, doing a bus walk but excluding zero, and then assigning the
> found free address, which re-opens zero to be used by a real PHY.
Right. It's a somewhat lazy scan of the bus. I'm assuming, here,
that there will be at least one non-zero address that has no PHY on it.
>
>
> I've made some changes to what you'd sent out, those being:
> -changed the "if (i < 0) return -EBUSY to "i == 0"
> -remove the now unused TBIPA_VALUE define
> -remove the prototypes from gianfar.c now that you've
> added them into gianfar.h
> -factor out the code to read the PHY ID so we don't have
> it duplicated in two places.
Excellent. Print it! :)
Could you send out the two patches as two separate emails, and add my
Acked-by: Andy Fleming <afleming@freescale.com> to the first one? You
should also change the subject for the first patch so that it has
[PATCH v2.6.26].
Andy
^ permalink raw reply
* Re: Flash on LocalBus @ MPC8343
From: Scott Wood @ 2008-04-14 16:45 UTC (permalink / raw)
To: André Schwarz; +Cc: linux-ppc list
In-Reply-To: <480079CA.5040000@matrix-vision.de>
On Sat, Apr 12, 2008 at 10:58:50AM +0200, André Schwarz wrote:
> thanks , but ... can't find "of_bus_ids[]" entry.
That means your platform likely isn't calling of_platform_bus_probe() at
all. Look at other platforms, such as mpc831x_rdb, for an example.
> I'm obviously out of sync. My last git-pull from denx is 3 days old, now
> - need to update on monday.
For Denx-specific support, please contact Denx.
This certainly isn't something that was added in the past 3 days.
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox