* Re: [PATCH 1/8] ibm_newemac: Fix possible lockup on close
From: Benjamin Herrenschmidt @ 2007-11-21 19:53 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071121154123.GB23589@lst.de>
On Wed, 2007-11-21 at 16:41 +0100, Christoph Hellwig wrote:
> On Wed, Nov 21, 2007 at 05:06:39PM +1100, Benjamin Herrenschmidt wrote:
> > It's a bad idea to call flush_scheduled_work from within a
> > netdev->stop because the linkwatch will occasionally take the
> > rtnl lock from a workqueue context, and thus that can deadlock.
> >
> > This reworks things a bit in that area to avoid the problem.
>
> So from the name of the driver you want to keep the previous emac
> driver around. Is there a good reason for that?
Until arch/ppc is gone... the previous driver works with arch/ppc the
new one with arch/powerpc.
If we kill arch/ppc in .25, then we'll remove the old driver and rename
the new one. If not, that will wait til .26
I'm hard at work porting as much of 4xx over I can to get to the point
where we -can- kill arch/ppc but I'm not done yet.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 0/14] powerpc: 4xx PCI and PCI-X support
From: Benjamin Herrenschmidt @ 2007-11-21 19:51 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200711211504.13003.sr@denx.de>
On Wed, 2007-11-21 at 15:04 +0100, Stefan Roese wrote:
> On Wednesday 21 November 2007, Josh Boyer wrote:
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > > Here's a set of patches that bring PCI and PCI-X support for
> > > 4xx (PCIe still missing) in arch/powerpc.
> > >
> > > This is for review before I ask paulus to pull that into his
> > > for 2.6.25 tree. Some of the patches still need a bit more
> > > testing vs. regressions on other platforms such as the
> > > 64 bits resource fixup one.
> >
> > I'm starting my 2.6.25 branch today. I'll probably throw these in
> > there after I've tested a bit, since I need them to make further
> > progress with 4xx anyway.
>
> Yes, it would be great to have an "official" repo with all the new 4xx stuff
> (PCI, EMAC...) stuff.
It would be good, but not in the form of a for-2.6.25 because some of
the patches aren't yet dry enough, more like something paulus could pull
into powerpc.git...
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 0/14] powerpc: 4xx PCI and PCI-X support
From: Benjamin Herrenschmidt @ 2007-11-21 19:50 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071121072348.7fff79a9@weaponx>
On Wed, 2007-11-21 at 07:23 -0600, Josh Boyer wrote:
> On Wed, 21 Nov 2007 17:16:17 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Here's a set of patches that bring PCI and PCI-X support for
> > 4xx (PCIe still missing) in arch/powerpc.
> >
> > This is for review before I ask paulus to pull that into his
> > for 2.6.25 tree. Some of the patches still need a bit more
> > testing vs. regressions on other platforms such as the
> > 64 bits resource fixup one.
>
> I'm starting my 2.6.25 branch today. I'll probably throw these in
> there after I've tested a bit, since I need them to make further
> progress with 4xx anyway.
Don't until I submit them for inclusion (when I said paulus above, I
actually meant you of course :-), I want one more round (I already have
enough comments to do minor fixups on most of them)
But I would definitely appreciate testing :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 5/14] powerpc: Fix 440/440A machine check handling
From: Josh Boyer @ 2007-11-21 19:51 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1195674530.6970.86.camel@pasglop>
On Thu, 22 Nov 2007 06:48:50 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Why didn't you just add a ppc_md.machine_check_exception to the
> > effected boards? Then you could have gotten rid of the ifdefs all
> > together.
>
> Hrm... it's per processor, not per board. I didn't feel like digging
> which board uses which processor and go fixup all the ppc_md's
Sounds like something a generic function could probe for from the DTS.
I'll look at doing something here when I start making 44x multiplatform
(soon).
josh
^ permalink raw reply
* Re: [RFC/PATCH 13/14] powerpc: EP405 boards support for arch/powerpc
From: Benjamin Herrenschmidt @ 2007-11-21 19:49 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071121072151.01156349@weaponx>
>
> Hm... odd. I don't remember writing this device tree ;)
Heh, oops... it's mostly copied from walnut. I'll fix that up.
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 5/14] powerpc: Fix 440/440A machine check handling
From: Benjamin Herrenschmidt @ 2007-11-21 19:48 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071121071240.141d2917@weaponx>
> Why didn't you just add a ppc_md.machine_check_exception to the
> effected boards? Then you could have gotten rid of the ifdefs all
> together.
Hrm... it's per processor, not per board. I didn't feel like digging
which board uses which processor and go fixup all the ppc_md's
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Scott Wood @ 2007-11-21 19:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <8B189FFE-F45E-470C-87A0-E9FC61A1CF59@kernel.crashing.org>
Kumar Gala wrote:
> On Nov 21, 2007, at 11:35 AM, Scott Wood wrote:
>> A cell-index property would be useful here for indexing into the summary
>> status register.
>
> Divide by 0x80.
:-P
Using cell-index for things like this is reasonably common, and endorsed
by current ePAPR drafts.
>>>> dma@21300 {
>>>> #address-cells = <1>;
>>>> #size-cells = <1>;
>>>> compatible = "fsl,mpc8610-dma", "fsl,mpc8540-
>>>> dma";
>>>> --> device-id = <0>;
>>
>> I don't see any justification for having such a property in the parent
>> node,
>> though.
>
> huh?
Timur put device-id properties in both the parent and the channel nodes.
I was wondering why he did the former.
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Kumar Gala @ 2007-11-21 19:22 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.62.0711211746180.12720@pademelon.sonytel.be>
On Nov 21, 2007, at 10:50 AM, Geert Uytterhoeven wrote:
> On Wed, 21 Nov 2007, Kumar Gala wrote:
>> On Nov 21, 2007, at 7:09 AM, Geert Uytterhoeven wrote:
>>> On Tue, 20 Nov 2007, Kumar Gala wrote:
>>>> On Nov 20, 2007, at 11:54 AM, Scott Wood wrote:
>>>>> Given that the instruction is meant to be a performance
>>>>> enhancement,
>>>>> we should probably warn the first few times it's emulated, so
>>>>> the user
>>>>> knows they should change their toolchain setup if possible.
>>>>
>>>> The same is true of mcrxr, popcntb, and possibly string ld/st.
>>>>
>>>> Feel free to submit a patch that warns about their usage.
>>
>> How about some per processor counters in sysfs under the processor.
>
> Per processor? That means it has to be per_cpu, which sounds a bit
> like
> overkill to me.
I can probably live with global, not sure that would work with sysfs.
- k
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Kumar Gala @ 2007-11-21 19:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20071121173540.GC4413@loki.buserror.net>
On Nov 21, 2007, at 11:35 AM, Scott Wood wrote:
> On Wed, Nov 21, 2007 at 09:33:05AM -0600, Kumar Gala wrote:
>> On Nov 21, 2007, at 8:59 AM, Timur Tabi wrote:
>>>> + Example:
>>>> + dma@21000 {
>>>
>>> Shouldn't this be dma@21300?
>>
>> its an example that has not basis is reality :)
>
> But it should at least be internally consistent with this:
>
>>>> + reg = <21300 4>;
ahh, i see.. yes I'll fix that.
> [snip]
>>> The DMA controller and the DMA channels need a "device-id", so that
>>> they can be identified by number. Some peripherals, like the SSI,
>>> can only use the controller and channel number. This is what I have
>>> in my 8610 DTS:
>>
>> Why not use reg for this? I don't see any reason to add another
>> "unique id" when there is already one.
>
> A cell-index property would be useful here for indexing into the
> summary
> status register.
Divide by 0x80.
>>> dma@21300 {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> compatible = "fsl,mpc8610-dma", "fsl,mpc8540-
>>> dma";
>>> --> device-id = <0>;
>
> I don't see any justification for having such a property in the
> parent node,
> though.
huh?
- k
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Add docs for Freescale RapidIO device tree node
From: Kumar Gala @ 2007-11-21 19:20 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071121172927.GA4413@loki.buserror.net>
On Nov 21, 2007, at 11:29 AM, Scott Wood wrote:
> On Tue, Nov 20, 2007 at 11:13:58PM -0600, Kumar Gala wrote:
>> Required properties:
>> - compatible : compatible list, contains 2 entries,
>> first is
>> - "fsl,sata-CHIP", where CHIP is the processor
>> + "fsl,CHIP-sata", where CHIP is the processor
>> (mpc8315, mpc8379, etc.) and the second is
>> - "fsl,sata-pq2pro"
>> + "fsl,pq2pro-sata"
>> - interrupts : <interrupt mapping for SATA IRQ>
>> - interrupt-parent : optional, if needed for interrupt mapping
>> - reg : <registers mapping>
>> @@ -2531,12 +2531,53 @@ platforms are moved over to use the
>> flattened-device-tree model.
>> Example:
>>
>> sata@19000 {
>> - compatible = "fsl,mpc8315-sata", "fsl,sata-pq2pro;
>> + compatible = "fsl,mpc8315-sata", "fsl,pq2pro-sata;
>
> I think you meant to merge these changes with the previous patch...
Yeah a merge issue, I'll look into it.
- k
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Kumar Gala @ 2007-11-21 19:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071121173308.GB4413@loki.buserror.net>
On Nov 21, 2007, at 11:33 AM, Scott Wood wrote:
> On Tue, Nov 20, 2007 at 11:14:40PM -0600, Kumar Gala wrote:
>> + - compatible : compatible list, contains 2 entries,
>> first is
>> + "fsl,CHIP-dma", where CHIP is the processor
>> + (mpc8540, mpc8540, etc.) and the second is
>> + "fsl,eloplus-dma"
>
> So if the DMA register set gets tweaked again, will we have
> eloplusplus? :-)
> Maybe elo2 would be better.
Seem unlikely for the forseeable future.
> Do we really need completely separate descriptions of the two, or
> can we just describe the difference in the compatible section?
it seemed easier to duplicate and fix.
- k
^ permalink raw reply
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
From: Vitaly Bordug @ 2007-11-21 18:08 UTC (permalink / raw)
To: Andrei Dolnikov; +Cc: linuxppc-dev
In-Reply-To: <20071116161253.GB25062@ru.mvista.com>
On Fri, 16 Nov 2007 19:12:53 +0300
Andrei Dolnikov wrote:
> Device tree source file for the Emerson Katana Qp board
>
> Signed-off-by: Andrei Dolnikov <adolnikov@ru.mvisa.com>
>
> ---
> arch/powerpc/boot/dts/katanaqp.dts | 357
> +++++++++++++++++++++++++++++++++++++ 1 files changed, 357
> insertions(+)
>
> diff --git a/arch/powerpc/boot/dts/katanaqp.dts
> b/arch/powerpc/boot/dts/katanaqp.dts new file mode 100644
> index 0000000..9273c4e
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/katanaqp.dts
> @@ -0,0 +1,357 @@
> +/* Device Tree Source for Emerson Katana Qp
> + *
> + * Authors: Vladislav Buzov <vbuzov@ru.mvista.com>
> + * Andrei Dolnikov <adolnikov@ru.mvista.com>
> + *
> + * Based on prpmc8200.dts by Mark A. Greer <mgreer@mvista.com>
> + *
> + * 2007 (c) MontaVista, Software, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This
> program
> + * is licensed "as is" without any warranty of any kind, whether
> express
> + * or implied.
> + *
> + */
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + model = "Katana-Qp"; /* Default */
> + compatible = "emerson,Katana-Qp";
> + coherency-off;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,7448@0 {
> + device_type = "cpu";
> + reg = <0>;
> + clock-frequency = <0>; /*
> From U-boot */
> + bus-frequency = <0>; /* From
> U-boot */
> + timebase-frequency = <0>; /* From
> U-boot */
> + i-cache-line-size = <20>;
> + d-cache-line-size = <20>;
> + i-cache-size = <8000>;
> + d-cache-size = <8000>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <00000000 20000000>; /* Default (512MB)
> */
> + };
> +
shouldn't this come from the firmware if possible?
> + mv64x60@f8100000 { /* Marvell Discovery */
> + #address-cells = <1>;
> + #size-cells = <1>;
> + model = "mv64460"; /* Default
> */
> + compatible = "marvell,mv64x60";
> + clock-frequency = <7f28155>; /*
> 133.333333 MHz */
This should be updated somewhere in fw or bootwrapper.. Or is it hardcoded
value that is not going to change?
> + reg = <f8100000 00010000>;
> + virtual-reg = <f8100000>;
> + ranges = <c1000000 c1000000 01000000 /* PCI 1
> I/O Space */
> + 90000000 90000000 30000000 /* PCI 1
> MEM Space */
> + e8000000 e8000000 04000000 /* User
> FLASH: Up to 64Mb */
> + 00000000 f8100000 00010000 /*
> Bridge's regs */
> + f8500000 f8500000 00040000>; /*
> Integrated SRAM */ +
> + flash@e8000000 {
> + compatible = "cfi-flash";
> + reg = <e8000000 1000000>; /* Default (16MB)
> */
> + probe-type = "CFI";
> + bank-width = <4>;
> +
> + partition@0 {
> + label = "Primary Monitor";
> + reg = <0 100000>; /* 1Mb */
> + read-only;
> + };
> +
> + partition@100000 {
> + label = "Primary Kernel";
> + reg = <100000 200000>; /* 2 Mb */
> + };
> +
> + partition@300000 {
> + label = "Primary FS";
> + reg = <300000 d00000>; /* 13 Mb */
> + };
> +
> + };
> +
> + cpld@f8200000 {
> + compatible = "altera,maxii";
> + reg = <f8200000 40000>;
> + virtual-reg = <f8200000>;
> + };
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "marvell,mv64x60-mdio";
> + ethernet-phy@0 {
> + block-index = <0>;
> + compatible = "marvell,mv88e1111";
> + reg = <a>;
> + };
> + ethernet-phy@1 {
> + compatible = "marvell,mv88e1111";
> + block-index = <1>;
> + reg = <d>;
> + };
> + ethernet-phy@2 {
> + compatible = "marvell,mv88e1111";
> + block-index = <2>;
> + reg = <6>;
> + };
> + };
> +
> + ethernet@2000 {
> + reg = <2000 2000>;
> + eth0 {
> + device_type = "network";
> + compatible = "marvell,mv64x60-eth";
> + block-index = <0>;
> + interrupts = <20>;
> + interrupt-parent = <&/mv64x60/pic>;
> + phy =
> <&/mv64x60/mdio/ethernet-phy@0>;
> + speed = <3e8>;
> + duplex = <1>;
> + tx_queue_size = <320>;
> + rx_queue_size = <190>;
> + local-mac-address = [ 00 00 00 00 00
> 00 ];
> + };
> + eth1 {
> + device_type = "network";
> + compatible = "marvell,mv64x60-eth";
> + block-index = <1>;
> + interrupts = <21>;
> + interrupt-parent = <&/mv64x60/pic>;
> + phy =
> <&/mv64x60/mdio/ethernet-phy@1>;
> + speed = <3e8>;
> + duplex = <1>;
> + tx_queue_size = <320>;
> + rx_queue_size = <190>;
> + local-mac-address = [ 00 00 00 00 00
> 00 ];
here and in other places: you need to add a note that stuff is being rewritten/updated by fw and/or bootwrapper.
> + };
> + eth2 {
> + device_type = "network";
> + compatible = "marvell,mv64x60-eth";
> + block-index = <2>;
> + interrupts = <22>;
> + interrupt-parent = <&/mv64x60/pic>;
> + phy =
> <&/mv64x60/mdio/ethernet-phy@2>;
> + speed = <3e8>;
> + duplex = <1>;
> + tx_queue_size = <320>;
> + rx_queue_size = <190>;
> + local-mac-address = [ 00 00 00 00 00
> 00 ];
> + };
> + };
> +
> + sdma@4000 {
> + compatible = "marvell,mv64x60-sdma";
> + reg = <4000 c18>;
> + virtual-reg = <f8104000>;
> + interrupt-base = <0>;
> + interrupts = <24>;
> + interrupt-parent = <&/mv64x60/pic>;
> + };
> +
> + sdma@6000 {
> + compatible = "marvell,mv64x60-sdma";
> + reg = <6000 c18>;
> + virtual-reg = <f8106000>;
> + interrupt-base = <0>;
> + interrupts = <26>;
> + interrupt-parent = <&/mv64x60/pic>;
> + };
> +
> + brg@b200 {
> + compatible = "marvell,mv64x60-brg";
> + reg = <b200 8>;
> + clock-src = <8>;
> + clock-frequency = <7ed6b40>;
> + current-speed = <2580>;
> + bcr = <0>;
> + };
> +
> + brg@b208 {
> + compatible = "marvell,mv64x60-brg";
> + reg = <b208 8>;
> + clock-src = <8>;
> + clock-frequency = <7ed6b40>;
> + current-speed = <2580>;
> + bcr = <0>;
> + };
> +
> + cunit@f200 {
> + reg = <f200 200>;
> + };
> +
> + mpscrouting@b400 {
> + reg = <b400 c>;
> + };
> +
> + mpscintr@b800 {
> + reg = <b800 100>;
> + virtual-reg = <f810b800>;
> + };
> +
> + mpsc@8000 {
> + device_type = "serial";
> + compatible = "marvell,mpsc";
> + reg = <8000 38>;
> + virtual-reg = <f8108000>;
> + sdma = <&/mv64x60/sdma@4000>;
> + brg = <&/mv64x60/brg@b200>;
> + cunit = <&/mv64x60/cunit@f200>;
> + mpscrouting = <&/mv64x60/mpscrouting@b400>;
> + mpscintr = <&/mv64x60/mpscintr@b800>;
> + block-index = <0>;
> + max_idle = <28>;
> + chr_1 = <0>;
> + chr_2 = <0>;
> + chr_10 = <3>;
> + mpcr = <0>;
> + interrupts = <28>;
> + interrupt-parent = <&/mv64x60/pic>;
> + };
> +
> + mpsc@9000 {
> + device_type = "serial";
> + compatible = "marvell,mpsc";
> + reg = <9000 38>;
> + virtual-reg = <f8109000>;
> + sdma = <&/mv64x60/sdma@6000>;
> + brg = <&/mv64x60/brg@b208>;
> + cunit = <&/mv64x60/cunit@f200>;
> + mpscrouting = <&/mv64x60/mpscrouting@b400>;
> + mpscintr = <&/mv64x60/mpscintr@b800>;
> + block-index = <1>;
> + max_idle = <28>;
> + chr_1 = <0>;
> + chr_2 = <0>;
> + chr_10 = <3>;
> + mpcr = <0>;
> + interrupts = <29>;
> + interrupt-parent = <&/mv64x60/pic>;
> + };
> +
> + wdt@b410 { /* watchdog timer
> */
> + compatible = "marvell,mv64x60-wdt";
> + reg = <b410 8>;
> + timeout = <a>; /* wdt timeout
> in seconds */
> + };
> +
> + i2c@c000 {
> + compatible = "marvell,mv64x60-i2c";
> + reg = <c000 20>;
> + virtual-reg = <f810c000>;
> + freq_m = <8>;
> + freq_n = <3>;
> + timeout = <3e8>; /* 1000 = 1
> second */
> + retries = <1>;
> + interrupts = <25>;
> + interrupt-parent = <&/mv64x60/pic>;
> + };
> +
> + pic {
> + #interrupt-cells = <1>;
> + #address-cells = <0>;
> + compatible = "marvell,mv64x60-pic";
> + reg = <0000 88>;
> + interrupt-controller;
> + };
> +
> + mpp@f000 {
> + compatible = "marvell,mv64x60-mpp";
> + reg = <f000 10>;
> + };
> +
> + gpp@f100 {
> + compatible = "marvell,mv64x60-gpp";
> + reg = <f100 20>;
> + };
> +
> + pci@90000000 {
> + #address-cells = <3>;
> + #size-cells = <2>;
> + #interrupt-cells = <1>;
> + device_type = "pci";
> + compatible = "marvell,mv64x60-pci";
> + reg = <0c78 8>;
> + ranges = <01000000 0 0 c1000000 0
> 01000000
> + 02000000 0 90000000 90000000 0
> 30000000>;
> + bus-range = <0 ff>;
> + clock-frequency = <3EF1480>;
> + interrupt-pci-iack = <0c34>;
> + interrupt-parent = <&/mv64x60/pic>;
> + interrupt-map-mask = <f800 0 0 7>;
> + interrupt-map = <
> + /* IDSEL 0x1 */
> + 0800 0 0 1 &/mv64x60/pic 5a
> + 0800 0 0 2 &/mv64x60/pic 5b
> + 0800 0 0 3 &/mv64x60/pic 5e
> + 0800 0 0 4 &/mv64x60/pic 5f
> +
> + /* IDSEL 0x2 */
> + 1000 0 0 1 &/mv64x60/pic 5b
> + 1000 0 0 2 &/mv64x60/pic 5e
> + 1000 0 0 3 &/mv64x60/pic 5f
> + 1000 0 0 4 &/mv64x60/pic 5a
> +
> + /* IDSEL 0x3 */
> + 1800 0 0 1 &/mv64x60/pic 5e
> + 1800 0 0 2 &/mv64x60/pic 5f
> + 1800 0 0 3 &/mv64x60/pic 5a
> + 1800 0 0 4 &/mv64x60/pic 5b
> +
> + /* IDSEL 0x4 */
> + 2000 0 0 1 &/mv64x60/pic 5f
> + 2000 0 0 2 &/mv64x60/pic 5a
> + 2000 0 0 3 &/mv64x60/pic 5b
> + 2000 0 0 4 &/mv64x60/pic 5e
> +
> + /* IDSEL 0x6 */
> + 3000 0 0 1 &/mv64x60/pic 5b
> + 3000 0 0 2 &/mv64x60/pic 5e
> + 3000 0 0 3 &/mv64x60/pic 5f
> + 3000 0 0 4 &/mv64x60/pic 5a
> + >;
> + };
> +
> + cpu-error@0070 {
> + compatible = "marvell,mv64x60-cpu-error";
> + reg = <0070 10 0128 28>;
> + interrupts = <03>;
> + interrupt-parent = <&/mv64x60/pic>;
> + };
> +
> + sram-ctrl@0380 {
> + compatible = "marvell,mv64x60-sram-ctrl";
> + reg = <0380 80>;
> + interrupts = <0d>;
> + interrupt-parent = <&/mv64x60/pic>;
> + };
> +
> + pci-error@1d40 {
> + compatible = "marvell,mv64x60-pci-error";
> + reg = <1d40 40 0c28 4>;
> + interrupts = <0c>;
> + interrupt-parent = <&/mv64x60/pic>;
> + };
> +
> + mem-ctrl@1400 {
> + compatible = "marvell,mv64x60-mem-ctrl";
> + reg = <1400 60>;
> + interrupts = <11>;
> + interrupt-parent = <&/mv64x60/pic>;
> + };
> + };
> +
> + chosen {
> + bootargs = "ip=on";
> + linux,stdout-path = "/mv64x60@f8100000/mpsc@8000";
> + };
Not sure it is required. At least if u-boot would have OF support, it'll rewrite chosen...
> +};
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 4/5] PowerPC 74xx: Katana Qp base support
From: Vitaly Bordug @ 2007-11-21 16:30 UTC (permalink / raw)
To: Andrei Dolnikov; +Cc: linuxppc-dev
In-Reply-To: <20071116163116.GE25062@ru.mvista.com>
Hi Andrei,
Looks okay in general, some notes below...
On Fri, 16 Nov 2007 19:31:16 +0300
Andrei Dolnikov wrote:
> Emerson Katana Qp platform specific code
>
> Signed-off-by: Andrei Dolnikov <adolnikov@ru.mvista.com>
>
> ---
> arch/powerpc/platforms/embedded6xx/Kconfig | 9 +
> arch/powerpc/platforms/embedded6xx/Makefile | 1
> arch/powerpc/platforms/embedded6xx/katanaqp.c | 180
> ++++++++++++++++++++++++++ 3 files changed, 190 insertions(+)
>
> diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig
> b/arch/powerpc/platforms/embedded6xx/Kconfig index 8924095..33190bd
> 100644 --- a/arch/powerpc/platforms/embedded6xx/Kconfig
> +++ b/arch/powerpc/platforms/embedded6xx/Kconfig
> @@ -46,6 +46,15 @@ config PPC_PRPMC2800
> help
> This option enables support for the Motorola PrPMC2800
> board
> +config PPC_KATANAQP
> + bool "Emerson-Katana Qp"
> + depends on EMBEDDED6xx
> + select MV64X60
> + select NOT_COHERENT_CACHE
> + select WANT_DEVICE_TREE
> + help
> + This option enables support for the Emerson Katana Qp board
> +
> config TSI108_BRIDGE
> bool
> depends on MPC7448HPC2 || PPC_HOLLY
> diff --git a/arch/powerpc/platforms/embedded6xx/Makefile
> b/arch/powerpc/platforms/embedded6xx/Makefile index 844947c..c83558f
> 100644 --- a/arch/powerpc/platforms/embedded6xx/Makefile
> +++ b/arch/powerpc/platforms/embedded6xx/Makefile
> @@ -5,3 +5,4 @@ obj-$(CONFIG_MPC7448HPC2) += mpc7448_hpc2.o
> obj-$(CONFIG_LINKSTATION) += linkstation.o ls_uart.o
> obj-$(CONFIG_PPC_HOLLY) += holly.o
> obj-$(CONFIG_PPC_PRPMC2800) += prpmc2800.o
> +obj-$(CONFIG_PPC_KATANAQP) += katanaqp.o
> diff --git a/arch/powerpc/platforms/embedded6xx/katanaqp.c
> b/arch/powerpc/platforms/embedded6xx/katanaqp.c new file mode 100644
> index 0000000..c0a8469
> --- /dev/null
> +++ b/arch/powerpc/platforms/embedded6xx/katanaqp.c
> @@ -0,0 +1,180 @@
> +/*
> + * Board setup routines for the Emerson Katana Qp
> + *
> + * Authors: Vladislav Buzov <vbuzov@ru.mvista.com>
> + * Andrei Dolnikov <adolnikov@ru.mvista.com>
> + *
> + * Based on prpmc2800.c by Dale Farnsworth <dale@farnsworth.org>
> + *
> + * 2007 (c) MontaVista, Software, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This
> program
> + * is licensed "as is" without any warranty of any kind, whether
> express
> + * or implied.
> + */
> +
> +#include <linux/stddef.h>
> +#include <linux/kernel.h>
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/seq_file.h>
> +#include <linux/of_platform.h>
> +#include <linux/pci.h>
> +
> +#include <asm/machdep.h>
> +#include <asm/prom.h>
> +#include <asm/system.h>
> +#include <asm/time.h>
> +#include <asm/kexec.h>
> +
> +#include <mm/mmu_decl.h>
> +
> +#include <sysdev/mv64x60.h>
> +
> +#define PLATFORM_NAME_MAX 64
> +
> +/* CPLD registers definitions */
> +#define KATANAQP_CPLD_RCR 0x0004 /* Reset command */
> +#define KATANAQP_CPLD_RCR_CPUHR (1 << 7)
> +
> +#define KATANAQP_CPLD_HVR 0x0020
> +
> +#define KATANAQP_CPLD_PSR 0x0030 /* PCI status */
> +#define KATANAQP_CPLD_PSR_PMCM (1 << 1)
> +
> +#define KATANAQP_CPLD_HCR 0x0044
> +
> +static char katanaqp_platform_name[PLATFORM_NAME_MAX];
> +
> +static void __iomem *cpld_base;
> +
> +int katanaqp_exclude_device(struct pci_controller *hose, u_char bus,
> + u_char devfn)
> +{
> + if (bus == 0 && PCI_SLOT(devfn) == 0)
> + return PCIBIOS_DEVICE_NOT_FOUND;
> + else
> + return PCIBIOS_SUCCESSFUL;
> +}
> +
> +static int __init katanaqp_is_monarch(void)
> +{
> + return !(in_8((volatile char *)(cpld_base +
> KATANAQP_CPLD_PSR)) &
> + KATANAQP_CPLD_PSR_PMCM);
> +}
> +
> +static void __init katanaqp_setup_arch(void)
> +{
> + struct device_node *cpld;
> + const unsigned int *reg;
> +
> + /*
> + * ioremap cpld registers in case they are later
> + * needed by katanaqp_reset_board().
> + */
> + cpld =
> of_find_node_by_path("/mv64x60@f8100000/cpld@f8200000");
> + reg = of_get_property(cpld, "reg", NULL);
> + of_node_put(cpld);
> + cpld_base = ioremap(reg[0], reg[1]);
> +
use of_iomap here?
> +#ifdef CONFIG_PCI
> + if (katanaqp_is_monarch()) {
> + mv64x60_pci_init();
> + ppc_md.pci_exclude_device = katanaqp_exclude_device;
> + }
> +#endif
> +
> + printk("Emerson Network Power %s\n", katanaqp_platform_name);
> +}
> +
> +static void katanaqp_reset_board(void)
> +{
> + local_irq_disable();
> +
> + /* issue hard reset to the reset command register */
> + out_8((volatile char *)(cpld_base + KATANAQP_CPLD_RCR),
> + KATANAQP_CPLD_RCR_CPUHR);
> + for (;;) ;
> +}
> +
> +static void katanaqp_restart(char *cmd)
> +{
> + katanaqp_reset_board();
> +}
> +
> +#ifdef CONFIG_NOT_COHERENT_CACHE
> +#define KATANAQP_COHERENCY_SETTING "off"
> +#else
> +#define KATANAQP_COHERENCY_SETTING "on"
> +#endif
> +
Does it mean this HW supports both coherent and non-coherent case?
I don't think we need to add this just "for the future" if QP doesn't have it.
If it does, I dont' see how it's being handled - defconfig just enables noncoherent upper.
> +void katanaqp_show_cpuinfo(struct seq_file *m)
> +{
> + uint memsize = total_memory;
> +
> + seq_printf(m, "vendor\t\t: Emerson Network Power\n");
> +
> + seq_printf(m, "hardware rev\t: %d\n",
> + in_8((volatile char *)(cpld_base +
> KATANAQP_CPLD_HVR))); +
> + seq_printf(m, "hardware config\t: %d\n",
> + in_8((volatile char *)(cpld_base +
> KATANAQP_CPLD_HCR))); +
> + seq_printf(m, "memory size\t: %d MB\n", memsize / (1024 *
> 1024)); +
> + seq_printf(m, "voherency\t: %s\n",
> KATANAQP_COHERENCY_SETTING); +
> + seq_printf(m, "PCI\t\t: %sMonarch\n",
> + katanaqp_is_monarch() ? "" : "Non-");
> +}
> +
> +static int __init katanaqp_of_init(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "cfi-flash");
> + if (np)
> + of_platform_device_create(np, "of-flash", NULL);
> +
Why not using of_device for physmap?
> + return 0;
> +}
> +
> +device_initcall(katanaqp_of_init);
> +
> +/*
> + * Called very early, device-tree isn't unflattened
> + */
> +static int __init katanaqp_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> + unsigned long len = PLATFORM_NAME_MAX;
not needed - get-prop will rewrite it anyway.
> + void *m;
> +
> + if (!of_flat_dt_is_compatible(root, "emerson,Katana-Qp"))
> + return 0;
> +
> + /* Update ppc_md.name with name from dt */
> + m = of_get_flat_dt_prop(root, "model", &len);
> + if (m)
> + strncpy(katanaqp_platform_name, m,
> + min((int)len, PLATFORM_NAME_MAX - 1));
> +
> + return 1;
> +}
> +
> +define_machine(katanaqp)
> +{
> + .name = katanaqp_platform_name,
> + .probe = katanaqp_probe,
> + .setup_arch = katanaqp_setup_arch,
> + .init_early = mv64x60_init_early,
> + .show_cpuinfo = katanaqp_show_cpuinfo,
> + .init_IRQ = mv64x60_init_irq,
> + .get_irq = mv64x60_get_irq,
> + .restart = katanaqp_restart,
> + .calibrate_decr = generic_calibrate_decr,
> +#ifdef CONFIG_KEXEC
> + .machine_kexec = default_machine_kexec,
> + .machine_kexec_prepare =
> default_machine_kexec_prepare,
> + .machine_crash_shutdown =
> default_machine_crash_shutdown, +#endif
> +};
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Scott Wood @ 2007-11-21 17:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <E9CED991-4E10-44AE-A446-B6CB151FB9EE@kernel.crashing.org>
On Wed, Nov 21, 2007 at 09:33:05AM -0600, Kumar Gala wrote:
> On Nov 21, 2007, at 8:59 AM, Timur Tabi wrote:
> >> + Example:
> >> + dma@21000 {
> >
> > Shouldn't this be dma@21300?
>
> its an example that has not basis is reality :)
But it should at least be internally consistent with this:
> >> + reg = <21300 4>;
[snip]
> > The DMA controller and the DMA channels need a "device-id", so that
> > they can be identified by number. Some peripherals, like the SSI,
> > can only use the controller and channel number. This is what I have
> > in my 8610 DTS:
>
> Why not use reg for this? I don't see any reason to add another
> "unique id" when there is already one.
A cell-index property would be useful here for indexing into the summary
status register.
>
> > dma@21300 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > compatible = "fsl,mpc8610-dma", "fsl,mpc8540-
> > dma";
> > --> device-id = <0>;
I don't see any justification for having such a property in the parent node,
though.
-Scott
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Scott Wood @ 2007-11-21 17:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711202314030.24220@blarg.am.freescale.net>
On Tue, Nov 20, 2007 at 11:14:40PM -0600, Kumar Gala wrote:
> + - compatible : compatible list, contains 2 entries, first is
> + "fsl,CHIP-dma", where CHIP is the processor
> + (mpc8540, mpc8540, etc.) and the second is
> + "fsl,eloplus-dma"
So if the DMA register set gets tweaked again, will we have eloplusplus? :-)
Maybe elo2 would be better.
Do we really need completely separate descriptions of the two, or
can we just describe the difference in the compatible section?
-Scott
^ permalink raw reply
* Re: Firmware Support for USB Hub
From: Laurent Pinchart @ 2007-11-21 17:29 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Misbah khan
In-Reply-To: <474468C5.8080402@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]
On Wednesday 21 November 2007 18:20, Scott Wood wrote:
> Misbah khan wrote:
> > Hi all,
> >
> > I am using a 8248 processor which has a USB controller and i need to
> > connect a USB Hub to it, iam using Montavista Linux .I need to know that
> > what are the support i need form Montavista or Open source to have an
> > interface with Usb hub. ???
> >
> > Is there any driver that we need to make if so what type ???
>
> I don't believe a driver currently exists for CPM USB.
There's an experimental out-of-tree driver available at
http://cpm2usb.sourceforge.net/
The code is outdated and doesn't work, but that's a starting point.
If I remember correctly, CPM2 USB host support requires the host to create SOF
packets in software. High system loads will probably mess the bus up. A
colleague of mines was told by Freescale to use an external USB controller
instead of the MPC8248 bundled one.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Add docs for Freescale RapidIO device tree node
From: Scott Wood @ 2007-11-21 17:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711202313350.24220@blarg.am.freescale.net>
On Tue, Nov 20, 2007 at 11:13:58PM -0600, Kumar Gala wrote:
> Required properties:
> - compatible : compatible list, contains 2 entries, first is
> - "fsl,sata-CHIP", where CHIP is the processor
> + "fsl,CHIP-sata", where CHIP is the processor
> (mpc8315, mpc8379, etc.) and the second is
> - "fsl,sata-pq2pro"
> + "fsl,pq2pro-sata"
> - interrupts : <interrupt mapping for SATA IRQ>
> - interrupt-parent : optional, if needed for interrupt mapping
> - reg : <registers mapping>
> @@ -2531,12 +2531,53 @@ platforms are moved over to use the flattened-device-tree model.
> Example:
>
> sata@19000 {
> - compatible = "fsl,mpc8315-sata", "fsl,sata-pq2pro;
> + compatible = "fsl,mpc8315-sata", "fsl,pq2pro-sata;
I think you meant to merge these changes with the previous patch...
-Scott
^ permalink raw reply
* Re: Firmware Support for USB Hub
From: Scott Wood @ 2007-11-21 17:20 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <13877282.post@talk.nabble.com>
Misbah khan wrote:
> Hi all,
>
> I am using a 8248 processor which has a USB controller and i need to connect
> a USB Hub to it, iam using Montavista Linux .I need to know that what are
> the support i need form Montavista or Open source to have an interface with
> Usb hub. ???
>
> Is there any driver that we need to make if so what type ???
I don't believe a driver currently exists for CPM USB.
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Geert Uytterhoeven @ 2007-11-21 16:50 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <7D40FA9E-A972-4995-85AE-3CE2551BB195@kernel.crashing.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1328 bytes --]
On Wed, 21 Nov 2007, Kumar Gala wrote:
> On Nov 21, 2007, at 7:09 AM, Geert Uytterhoeven wrote:
> > On Tue, 20 Nov 2007, Kumar Gala wrote:
> > > On Nov 20, 2007, at 11:54 AM, Scott Wood wrote:
> > > > Given that the instruction is meant to be a performance enhancement,
> > > > we should probably warn the first few times it's emulated, so the user
> > > > knows they should change their toolchain setup if possible.
> > >
> > > The same is true of mcrxr, popcntb, and possibly string ld/st.
> > >
> > > Feel free to submit a patch that warns about their usage.
>
> How about some per processor counters in sysfs under the processor.
Per processor? That means it has to be per_cpu, which sounds a bit like
overkill to me.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [PATCH 2/2][2.6.24] ehea: Reworked rcv queue handling to log only fatal errors
From: Thomas Klein @ 2007-11-21 16:42 UTC (permalink / raw)
To: Jeff Garzik
Cc: Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
Prevent driver from brawly logging packet checksum errors.
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 11 +++++------
drivers/net/ehea/ehea_qmr.h | 4 ++--
3 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 5935899..ea67615 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0082"
+#define DRV_VERSION "EHEA_0083"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index d2f715d..869e160 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -410,11 +410,6 @@ static int ehea_treat_poll_error(struct ehea_port_res *pr, int rq,
if (cqe->status & EHEA_CQE_STAT_ERR_CRC)
pr->p_stats.err_frame_crc++;
- if (netif_msg_rx_err(pr->port)) {
- ehea_error("CQE Error for QP %d", pr->qp->init_attr.qp_nr);
- ehea_dump(cqe, sizeof(*cqe), "CQE");
- }
-
if (rq == 2) {
*processed_rq2 += 1;
skb = get_skb_by_index(pr->rq2_skba.arr, pr->rq2_skba.len, cqe);
@@ -426,7 +421,11 @@ static int ehea_treat_poll_error(struct ehea_port_res *pr, int rq,
}
if (cqe->status & EHEA_CQE_STAT_FAT_ERR_MASK) {
- ehea_error("Critical receive error. Resetting port.");
+ if (netif_msg_rx_err(pr->port)) {
+ ehea_error("Critical receive error for QP %d. "
+ "Resetting port.", pr->qp->init_attr.qp_nr);
+ ehea_dump(cqe, sizeof(*cqe), "CQE");
+ }
schedule_work(&pr->port->reset_task);
return 1;
}
diff --git a/drivers/net/ehea/ehea_qmr.h b/drivers/net/ehea/ehea_qmr.h
index 562de0e..bc62d38 100644
--- a/drivers/net/ehea/ehea_qmr.h
+++ b/drivers/net/ehea/ehea_qmr.h
@@ -145,8 +145,8 @@ struct ehea_rwqe {
#define EHEA_CQE_VLAN_TAG_XTRACT 0x0400
#define EHEA_CQE_TYPE_RQ 0x60
-#define EHEA_CQE_STAT_ERR_MASK 0x720F
-#define EHEA_CQE_STAT_FAT_ERR_MASK 0x1F
+#define EHEA_CQE_STAT_ERR_MASK 0x700F
+#define EHEA_CQE_STAT_FAT_ERR_MASK 0xF
#define EHEA_CQE_STAT_ERR_TCP 0x4000
#define EHEA_CQE_STAT_ERR_IP 0x2000
#define EHEA_CQE_STAT_ERR_CRC 0x1000
--
1.5.2
^ permalink raw reply related
* [PATCH 1/2][2.6.24] ehea: Improve tx packets counting
From: Thomas Klein @ 2007-11-21 16:37 UTC (permalink / raw)
To: Jeff Garzik
Cc: Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
Using own tx_packets counter instead of firmware counters.
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 9 +++++++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index f78e5bf..5935899 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0080"
+#define DRV_VERSION "EHEA_0082"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index f0319f1..d2f715d 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -136,7 +136,7 @@ static struct net_device_stats *ehea_get_stats(struct net_device *dev)
struct ehea_port *port = netdev_priv(dev);
struct net_device_stats *stats = &port->stats;
struct hcp_ehea_port_cb2 *cb2;
- u64 hret, rx_packets;
+ u64 hret, rx_packets, tx_packets;
int i;
memset(stats, 0, sizeof(*stats));
@@ -162,7 +162,11 @@ static struct net_device_stats *ehea_get_stats(struct net_device *dev)
for (i = 0; i < port->num_def_qps; i++)
rx_packets += port->port_res[i].rx_packets;
- stats->tx_packets = cb2->txucp + cb2->txmcp + cb2->txbcp;
+ tx_packets = 0;
+ for (i = 0; i < port->num_def_qps + port->num_add_tx_qps; i++)
+ tx_packets += port->port_res[i].tx_packets;
+
+ stats->tx_packets = tx_packets;
stats->multicast = cb2->rxmcp;
stats->rx_errors = cb2->rxuerr;
stats->rx_bytes = cb2->rxo;
@@ -2000,6 +2004,7 @@ static int ehea_start_xmit(struct sk_buff *skb, struct net_device *dev)
}
ehea_post_swqe(pr->qp, swqe);
+ pr->tx_packets++;
if (unlikely(atomic_read(&pr->swqe_avail) <= 1)) {
spin_lock_irqsave(&pr->netif_queue, flags);
--
1.5.2
^ permalink raw reply related
* Re: [PATCH 1/8] ibm_newemac: Fix possible lockup on close
From: Josh Boyer @ 2007-11-21 15:43 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <20071121154123.GB23589@lst.de>
On Wed, 21 Nov 2007 16:41:23 +0100
Christoph Hellwig <hch@lst.de> wrote:
> On Wed, Nov 21, 2007 at 05:06:39PM +1100, Benjamin Herrenschmidt wrote:
> > It's a bad idea to call flush_scheduled_work from within a
> > netdev->stop because the linkwatch will occasionally take the
> > rtnl lock from a workqueue context, and thus that can deadlock.
> >
> > This reworks things a bit in that area to avoid the problem.
>
> So from the name of the driver you want to keep the previous emac
> driver around. Is there a good reason for that?
It's being kept around until arch/ppc dies. Then things should get
renamed.
josh
^ permalink raw reply
* Re: [PATCH 1/8] ibm_newemac: Fix possible lockup on close
From: Christoph Hellwig @ 2007-11-21 15:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071121060729.71A1FDDE01@ozlabs.org>
On Wed, Nov 21, 2007 at 05:06:39PM +1100, Benjamin Herrenschmidt wrote:
> It's a bad idea to call flush_scheduled_work from within a
> netdev->stop because the linkwatch will occasionally take the
> rtnl lock from a workqueue context, and thus that can deadlock.
>
> This reworks things a bit in that area to avoid the problem.
So from the name of the driver you want to keep the previous emac
driver around. Is there a good reason for that?
^ permalink raw reply
* annoying prinkts during vmemmap initialization
From: Christoph Hellwig @ 2007-11-21 15:35 UTC (permalink / raw)
To: apw; +Cc: linuxppc-dev
Hi Andi,
your patch 'ppc64: SPARSEMEM_VMEMMAP support' adds the following two lines:
+ printk(KERN_WARNING "vmemmap %08lx allocated at %p, "
+ "physical %p.\n", start, p, __pa(p));
in a loop around basically every page. That's a lot of flooding (with
the wrong printk level, btw) and really slows down booting my cell blade
a lot (these only have a very slow serial over lan console).
Any reason to keep this? And if yes can we please make it conditional
on some kind of vmemmap_debug boot option?
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Kumar Gala @ 2007-11-21 15:34 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.62.0711211524370.12720@pademelon.sonytel.be>
On Nov 21, 2007, at 8:33 AM, Geert Uytterhoeven wrote:
> On Wed, 21 Nov 2007, Kumar Gala wrote:
>> On Nov 21, 2007, at 7:09 AM, Geert Uytterhoeven wrote:
>>> On Tue, 20 Nov 2007, Kumar Gala wrote:
>>>> On Nov 20, 2007, at 11:54 AM, Scott Wood wrote:
>>>>> On Mon, Nov 19, 2007 at 09:36:57PM -0600, Kumar Gala wrote:
>>>>>> isel (Integer Select) is a new user space instruction in the
>>>>>> PowerISA 2.04 spec. Not all processors implement it so lets
>>>>>> emulate
>>>>>> to ensure code built with isel will run everywhere.
>>>>>
>>>>> Given that the instruction is meant to be a performance
>>>>> enhancement,
>>>>> we should probably warn the first few times it's emulated, so
>>>>> the user
>>>>> knows they should change their toolchain setup if possible.
>>>>
>>>> The same is true of mcrxr, popcntb, and possibly string ld/st.
>>>>
>>>> Feel free to submit a patch that warns about their usage.
>>>
>>> Something like this?
>>>
>>> Probably we also want it for:
>>>
>>> - arch/powerpc/kernel/align.c
>>> o emulate_dcbz()
>>> o emulate_multiple()
>>> o emulate_fp_pair()
>>> o emulate_spe()
>>>
>>> - arch/powerpc/kernel/softemu8xx.c
>>> o Soft_emulate_8xx()
>>>
>>> - arch/powerpc/kernel/traps.c
>>> o SoftwareEmulation()
>>
>> You missed math_emu.
>>
>>> - arch/powerpc/kernel/vecemu.c
>>> o emulate_altivec()
>>
>> I'm not sure I would concern this one emulation, there isn't much
>> you can do
>> about the denorm fixup.
>>
>> How about some per processor counters in sysfs under the processor.
>
> Good idea!
>
>>> Question: do we want it for emulate_single_step(), too?
>>
>> What do you mean, we should could the emulation, the emulate single
>> step just
>> is for handling if you are doing debug while hitting an emulated
>> insn.
>
> I mean: should these be counted?
the number of emulated single steps insn? not sure I follow. I think
we should count regardless if we go through emulate_single_step().
- k
^ 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