* 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
* Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Kumar Gala @ 2007-11-21 15:33 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <474447EF.8080405@freescale.com>
On Nov 21, 2007, at 8:59 AM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> + * Freescale 83xx DMA Controller
>> +
>> + Freescale PowerPC 83xx have on chip general purpose DMA
>> controllers.
>> +
>> + Required properties:
>> +
>> + - compatible : compatible list, contains 2 entries,
>> first is
>> + "fsl,CHIP-dma", where CHIP is the processor
>> + (mpc8349, mpc8360, etc.) and the second is
>> + "fsl,elo-dma"
>
> Shouldn't we put some text somewhere that we're calling it the Elo
> controller even though that word isn't used in the reference manual?
we don't really have a place to put that. its effectively documented
right here.
>
>
>> + * Freescale 85xx DMA Controller
>
> And 86xx.
yes, true.
>> +
>> + Freescale PowerPC 85xx have on chip general purpose DMA
>> controllers.
>> +
>> + Required properties:
>> +
>> + - 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"
>> + - reg : <registers mapping for DMA general
>> status reg>
>> + - ranges : Should be defined as specified in 1) to describe
>> the
>> + DMA controller channels.
>> +
>> + - DMA channel nodes:
>> + - compatible : compatible list, contains 2 entries,
>> first is
>> + "fsl,CHIP-dma-channel", where CHIP is the processor
>> + (mpc8540, mpc8560, etc.) and the second is
>> + "fsl,eloplus-dma-channel"
>> + - reg : <registers mapping for channel>
>> + - interrupts : <interrupt mapping for DMA channel IRQ>
>> + - interrupt-parent : optional, if needed for interrupt mapping
>> +
>> + Example:
>> + dma@21000 {
>
> Shouldn't this be dma@21300?
its an example that has not basis is reality :)
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
>> + reg = <21300 4>;
>> + ranges = <0 21100 200>;
>> + dma-channel@0 {
>> + compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-
>> channel";
>> + reg = <0 80>;
>> + interrupt-parent = <&mpic>;
>> + interrupts = <14 2>;
>> + };
>
> 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.
> dma@21300 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "fsl,mpc8610-dma", "fsl,mpc8540-
> dma";
> --> device-id = <0>;
> reg = <21300 4>; /* DMA general status
> register */
> ranges = <0 21100 200>;
>
> dma-channel@0 {
> compatible = "fsl,mpc8610-dma-channel",
> "fsl,mpc8540-dma-channel";
> --> device-id = <0>;
> reg = <0 80>;
> interrupt-parent = <&mpic>;
> interrupts = <14 2>;
> };
>
- k
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Timur Tabi @ 2007-11-21 14:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711202314030.24220@blarg.am.freescale.net>
Kumar Gala wrote:
> + * Freescale 83xx DMA Controller
> +
> + Freescale PowerPC 83xx have on chip general purpose DMA controllers.
> +
> + Required properties:
> +
> + - compatible : compatible list, contains 2 entries, first is
> + "fsl,CHIP-dma", where CHIP is the processor
> + (mpc8349, mpc8360, etc.) and the second is
> + "fsl,elo-dma"
Shouldn't we put some text somewhere that we're calling it the Elo controller
even though that word isn't used in the reference manual?
> + * Freescale 85xx DMA Controller
And 86xx.
> +
> + Freescale PowerPC 85xx have on chip general purpose DMA controllers.
> +
> + Required properties:
> +
> + - 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"
> + - reg : <registers mapping for DMA general status reg>
> + - ranges : Should be defined as specified in 1) to describe the
> + DMA controller channels.
> +
> + - DMA channel nodes:
> + - compatible : compatible list, contains 2 entries, first is
> + "fsl,CHIP-dma-channel", where CHIP is the processor
> + (mpc8540, mpc8560, etc.) and the second is
> + "fsl,eloplus-dma-channel"
> + - reg : <registers mapping for channel>
> + - interrupts : <interrupt mapping for DMA channel IRQ>
> + - interrupt-parent : optional, if needed for interrupt mapping
> +
> + Example:
> + dma@21000 {
Shouldn't this be dma@21300?
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
> + reg = <21300 4>;
> + ranges = <0 21100 200>;
> + dma-channel@0 {
> + compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
> + reg = <0 80>;
> + interrupt-parent = <&mpic>;
> + interrupts = <14 2>;
> + };
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:
dma@21300 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8610-dma", "fsl,mpc8540-dma";
--> device-id = <0>;
reg = <21300 4>; /* DMA general status register */
ranges = <0 21100 200>;
dma-channel@0 {
compatible = "fsl,mpc8610-dma-channel",
"fsl,mpc8540-dma-channel";
--> device-id = <0>;
reg = <0 80>;
interrupt-parent = <&mpic>;
interrupts = <14 2>;
};
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ 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