Re: Trying to use Device Tree...and getting continuous interrupts from attached 88e1145
On Fri, 2007-08-03 at 18:54 -0400, Morrison, Tom wrote: > Now, that looks OK! Those are what I would expect. And when the > mdio/phy are probed, configured, and the 88E1145 interrupt (EXT7 > (0x37H)) is enabled, the interrupt never (seemingly) gets cleared, > and basically hangs the entire box up and eventually it panics! > > I don't even have an external phy(SFP) connected to this 88e1148 phy.. > > I am at a lost - is there something I am missing in device tree? > Help mr. wizard (Kumar?)... Double check you got the interrupt sense and polarity right. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Page faults blowing up ... [was Re: [PATCH] Fix special PTE code for secondary hash bucket
On Fri, 2007-08-03 at 14:32 -0500, Linas Vepstas wrote: > On Fri, Aug 03, 2007 at 06:58:51PM +1000, Paul Mackerras wrote: > > The code for mapping special 4k pages on kernels using a 64kB base > > page size was missing the code for doing the RPN (real page number) > > manipulation when inserting the hardware PTE in the secondary hash > > bucket. It needs the same code as has already been added to the > > code that inserts the HPTE in the primary hash bucket. This adds it. > > So what are the symptoms of hitting this? Does this affect only > recent kernels, or old ones too? Paulus stuff is likely to be unrelated to your bug. Also, whatever blurb you pasted in this email is totally incomprehensible due to total lack of context. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 06/10] 40x decrementer fixes
On Fri, 2007-08-03 at 21:10 +0400, Sergei Shtylyov wrote: > > Why bother doing this?! This will only warrant you imprecise > > decrementer > > interrupts while it should be interrupting at the precise period currently > > (if > > you load PIT once)... > > I.e. the error will only accumulate. NAK. No, it won't since the timebase is always used as the reference. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 06/10] 40x decrementer fixes
On Fri, 2007-08-03 at 20:47 +0400, Sergei Shtylyov wrote: > Josh Boyer wrote: > > > Allow generic_calibrate_decr to work for 40x platforms. Given that the > > hardware > > behavior is identical, this also changes the set_dec function to reload the > > PIT > > on 40x to match the behavior 44x currently has. > > Why bother doing this?! This will only warrant you imprecise decrementer > interrupts while it should be interrupting at the precise period currently > (if > you load PIT once)... Because that's what the kernel timekeeping code expects ? The reference time is the timebase and it doesn't drift. The DEC/PIT is commonly used to trigger any timing, such as what is done for lost interrupts on some platforms. Also, with dynticks, we'll most certainly want variable reload values as well. So I'm very happy to have Josh change the code that way. It makes things more consistent accross the board and removes confusion. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] cell: move SPU affinity init to spu_management_of_ops
From: Andre Detsch <[EMAIL PROTECTED]>
This patch moves affinity initialization code from spu_base.c to a
new spu_management_of_ops function (init_affinity), which is empty
in the case of PS3. This fixes a linking problem that was happening
when compiling for PS3.
Also, some small code style changes were made.
Signed-off-by: Andre Detsch <[EMAIL PROTECTED]>
Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
---
Arnd,
I rebased this to to Paul's powerpc git tree. This needs to go
in for 2.6.23, as it fixes build breakage for PS3-only configs.
Please check and ack.
-Geoff
arch/powerpc/platforms/cell/spu_base.c | 141 --
arch/powerpc/platforms/cell/spu_manage.c | 163 +++
arch/powerpc/platforms/ps3/spu.c |6 +
include/asm-powerpc/spu_priv1.h |7 +
4 files changed, 177 insertions(+), 140 deletions(-)
--- a/arch/powerpc/platforms/cell/spu_base.c
+++ b/arch/powerpc/platforms/cell/spu_base.c
@@ -36,7 +36,6 @@
#include
#include
#include
-#include "spu_priv1_mmio.h"
const struct spu_management_ops *spu_management_ops;
EXPORT_SYMBOL_GPL(spu_management_ops);
@@ -636,138 +635,6 @@ static ssize_t spu_stat_show(struct sys_
static SYSDEV_ATTR(stat, 0644, spu_stat_show, NULL);
-/* Hardcoded affinity idxs for QS20 */
-#define SPES_PER_BE 8
-static int QS20_reg_idxs[SPES_PER_BE] = { 0, 2, 4, 6, 7, 5, 3, 1 };
-static int QS20_reg_memory[SPES_PER_BE] = { 1, 1, 0, 0, 0, 0, 0, 0 };
-
-static struct spu *spu_lookup_reg(int node, u32 reg)
-{
- struct spu *spu;
-
- list_for_each_entry(spu, &cbe_spu_info[node].spus, cbe_list) {
- if (*(u32 *)get_property(spu_devnode(spu), "reg", NULL) == reg)
- return spu;
- }
- return NULL;
-}
-
-static void init_aff_QS20_harcoded(void)
-{
- int node, i;
- struct spu *last_spu, *spu;
- u32 reg;
-
- for (node = 0; node < MAX_NUMNODES; node++) {
- last_spu = NULL;
- for (i = 0; i < SPES_PER_BE; i++) {
- reg = QS20_reg_idxs[i];
- spu = spu_lookup_reg(node, reg);
- if (!spu)
- continue;
- spu->has_mem_affinity = QS20_reg_memory[reg];
- if (last_spu)
- list_add_tail(&spu->aff_list,
- &last_spu->aff_list);
- last_spu = spu;
- }
- }
-}
-
-static int of_has_vicinity(void)
-{
- struct spu* spu;
-
- spu = list_entry(cbe_spu_info[0].spus.next, struct spu, cbe_list);
- return of_find_property(spu_devnode(spu), "vicinity", NULL) != NULL;
-}
-
-static struct spu *aff_devnode_spu(int cbe, struct device_node *dn)
-{
- struct spu *spu;
-
- list_for_each_entry(spu, &cbe_spu_info[cbe].spus, cbe_list)
- if (spu_devnode(spu) == dn)
- return spu;
- return NULL;
-}
-
-static struct spu *
-aff_node_next_to(int cbe, struct device_node *target, struct device_node
*avoid)
-{
- struct spu *spu;
- const phandle *vic_handles;
- int lenp, i;
-
- list_for_each_entry(spu, &cbe_spu_info[cbe].spus, cbe_list) {
- if (spu_devnode(spu) == avoid)
- continue;
- vic_handles = get_property(spu_devnode(spu), "vicinity", &lenp);
- for (i=0; i < (lenp / sizeof(phandle)); i++) {
- if (vic_handles[i] == target->linux_phandle)
- return spu;
- }
- }
- return NULL;
-}
-
-static void init_aff_fw_vicinity_node(int cbe)
-{
- struct spu *spu, *last_spu;
- struct device_node *vic_dn, *last_spu_dn;
- phandle avoid_ph;
- const phandle *vic_handles;
- const char *name;
- int lenp, i, added, mem_aff;
-
- last_spu = list_entry(cbe_spu_info[cbe].spus.next, struct spu,
cbe_list);
- avoid_ph = 0;
- for (added = 1; added < cbe_spu_info[cbe].n_spus; added++) {
- last_spu_dn = spu_devnode(last_spu);
- vic_handles = get_property(last_spu_dn, "vicinity", &lenp);
-
- for (i = 0; i < (lenp / sizeof(phandle)); i++) {
- if (vic_handles[i] == avoid_ph)
- continue;
-
- vic_dn = of_find_node_by_phandle(vic_handles[i]);
- if (!vic_dn)
- continue;
-
- name = get_property(vic_dn, "name", NULL);
- if (strcmp(name, "spe") == 0) {
- spu = aff_devnode_spu(cbe, vic_dn);
- avoid_ph = last_spu_dn->linux_phandle;
- }
- else {
- mem_aff = strcmp(name, "mic-tm") == 0;
-
Trying to use Device Tree...and getting continuous interrupts from attached 88e1145
All,
Connected to eth1 (etsec2) of my mpc8548 cpu is a 88E1145 and I
am trying to get the core functionality running with the device tree
paradigm - I know the sense of the 88E1145 is active-low for my
mpc8548 board and have it working with an older 2.6.11++ kernel.
I built this new kernel with the marvell driver - it seemingly
does all the same things we did in the 2.6.11 kernel in separate
spots...
Here is the appropriate parts of my device tree for this part of the
core...
>> [EMAIL PROTECTED] {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> device_type = "mdio";
>> compatible = "gianfar";
>> reg = <24520 20>;
>> phy1: [EMAIL PROTECTED] {
>> interrupt-parent = <&mpic>;
>> interrupts = <37 1>;
>> reg = <11>;
>> device_type = "ethernet-phy";
>> };
>> };
>> [EMAIL PROTECTED] {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> device_type = "network";
>> model = "eTSEC";
>> compatible = "gianfar";
>> reg = <25000 1000>;
>> local-mac-address = [ 00 00 00 00 00 00 ];
>> interrupts = <23 2 24 2 28 2>;
>> interrupt-parent = <&mpic>;
>> phy-handle = <&phy1>;
>> };
>> mpic: [EMAIL PROTECTED] {
>> clock-frequency = <0>;
>> interrupt-controller;
>> #address-cells = <0>;
>> #interrupt-cells = <2>;
>> reg = <4 4>;
>> built-in;
>> compatible = "chrp,open-pic";
>> device_type = "open-pic";
>>big-endian;
>> };
The device tree seems to be parsed OK:
>> of_irq_map_one: dev=/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],
index=0
>> intsize=2 intlen=2
>> of_irq_map_raw: par=/[EMAIL PROTECTED]/[EMAIL PROTECTED],intspec=[0x0037
>> 0x0001...],ointsize=2
>> of_irq_map_raw: ipar=/[EMAIL PROTECTED]/[EMAIL PROTECTED], size=2
>> mpic: xlate (2 cells: 0x0037 0x0001) to line 0x37 sense 0x8
Now, that looks OK! Those are what I would expect. And when the
mdio/phy are probed, configured, and the 88E1145 interrupt (EXT7
(0x37H)) is enabled, the interrupt never (seemingly) gets cleared,
and basically hangs the entire box up and eventually it panics!
I don't even have an external phy(SFP) connected to this 88e1148 phy..
I am at a lost - is there something I am missing in device tree?
Help mr. wizard (Kumar?)...
Tom
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 3/3] First cut at PReP support for arch/powerpc
> > > > + MPIC: [EMAIL PROTECTED] {
> > > > + device_type = "open-pic";
> > > >
> > > > device_type = "interrupt-controller".
> >
> > Not according to the binding in booting-without-of.txt
>
> My understanding here, though possibly flawed, is that the current
> implementation has "open-pic" but _should_ have "interrupt-controller"
> as that is the officially correct name.
>
> I _think_ this means we need a transitional period where we update
> the code to look for "interrupt-controller", and obsoletedly, looks
> for the "open-pic", while we transition to the new, correct name.
"open-pic" is the correct value for the device_type property.
See the binding at:
http://playground.sun.com/1275/bindings/chrp/chrp1_8a.ps
That is the definition for open pic interrupt controllers (AFAIK).
I am not aware of any official binding with "interrupt-controller"
as the device_type.
However, the interrupt mapping spec says that all interrupt
controller (regardless of device_type) must have a
property named "interrupt-controller" to identify
the device node as an interrupt controller and root of
a interrupt tree.
See: http://playground.sun.com/1275/practice/imap/imap0_9d.html
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Page faults blowing up ... [was Re: [PATCH] Fix special PTE code for secondary hash bucket
Linas Vepstas wrote: > 3:mon> d c77b21e0 > c77b21e0 e0008004b224 067410090080 |...$.t..| > > Well, howdy doody, there's the value that should have been in r3 > > c77b21f0 c4008e00 49424d00 |IBM.| > > IBM ??? > > c77b2200 504800300600 |PH.0| > c77b2210 4803 |H...| > c77b2220 || > c77b2230 554800180600 10004000 |[EMAIL PROTECTED]| > c77b2240 2000 4d4300280600 |.. .MC.(| > c77b2250 0001 00c3 || > c77b2260 e0008004b224 |...$| > c77b2270 d00d32c0 80101032 |..22| > > hey .. wait .. d00d32c0 is the faulting adddress; whats it doing here > ??? > ... and 80101032 is the value of the MSR ... why is that here ?? That looks like part of an RTAS event. PH indicates a "Main A" section, UH a "Main B" section, and, probably of most interest to you, MC indicates a "Failing Memory Address" section. The "Error and Event Notification" chapter of the PAPR will be useful here. You can use rtas_dump (in either powerpc-utils or ppc64-utils, depending on the distro) to decode the event in its entirety. A quick hand-decode of the MC section yields (might be wrong, you'll want to double-check): Unrecoverable memory error (UE); transient UE, 64-bit effective address provided by the log (located at c77b2260), 64-bit logical address of logical page is not provided by the log; error detected by load/store unit of the processor. Mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] lro: myri10ge example how to use LRO
Kok, Auke wrote: > Andrew Gallatin wrote: >> To follow up on Jan-Bernd Themann's LRO patch earlier today, >> this patch shows how the generic LRO interface can be used for >> page based drivers. >> >> Again, many thanks to Jan-Bernd Themann for leading this effort. >> >> Drew >> >> Singed off by: Andrew Gallatin <[EMAIL PROTECTED]> >> > > > please take a look at my lro patch for ethtool and see if it works for > you, instead of adding another generic module parameter that doesn't > need to be there. That looks very nice, and will indeed work for me. Thanks, Drew ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3] Fix ibmvscsi client for multiplatform iSeries+pSeries kernel.
Acked by: Brian King <[EMAIL PROTECTED]>
David Woodhouse wrote:
> If you build a multiplatform kernel for iSeries and pSeries, with
> ibmvscsic support, the resulting client doesn't work on iSeries.
>
> This patch should fix that, using the appropriate low-level operations
> for the machine detected at runtime.
>
> Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
>
> ---
> This third version of the patch is updated to apply to Linus' current
> git tree following the recent ibmvscsi updates.
>
> diff --git a/drivers/scsi/ibmvscsi/rpa_vscsi.c
> b/drivers/scsi/ibmvscsi/rpa_vscsi.c
> index 9c14e78..1821461 100644
> --- a/drivers/scsi/ibmvscsi/rpa_vscsi.c
> +++ b/drivers/scsi/ibmvscsi/rpa_vscsi.c
> @@ -42,14 +42,14 @@ static unsigned int partition_number = -1;
> * Routines for managing the command/response queue
> */
> /**
> - * ibmvscsi_handle_event: - Interrupt handler for crq events
> + * rpavscsi_handle_event: - Interrupt handler for crq events
> * @irq: number of irq to handle, not used
> * @dev_instance: ibmvscsi_host_data of host that received interrupt
> *
> * Disables interrupts and schedules srp_task
> * Always returns IRQ_HANDLED
> */
> -static irqreturn_t ibmvscsi_handle_event(int irq, void *dev_instance)
> +static irqreturn_t rpavscsi_handle_event(int irq, void *dev_instance)
> {
> struct ibmvscsi_host_data *hostdata =
> (struct ibmvscsi_host_data *)dev_instance;
> @@ -66,9 +66,9 @@ static irqreturn_t ibmvscsi_handle_event(int irq, void
> *dev_instance)
> * Frees irq, deallocates a page for messages, unmaps dma, and unregisters
> * the crq with the hypervisor.
> */
> -void ibmvscsi_release_crq_queue(struct crq_queue *queue,
> - struct ibmvscsi_host_data *hostdata,
> - int max_requests)
> +static void rpavscsi_release_crq_queue(struct crq_queue *queue,
> +struct ibmvscsi_host_data *hostdata,
> +int max_requests)
> {
> long rc;
> struct vio_dev *vdev = to_vio_dev(hostdata->dev);
> @@ -108,12 +108,13 @@ static struct viosrp_crq *crq_queue_next_crq(struct
> crq_queue *queue)
> }
>
> /**
> - * ibmvscsi_send_crq: - Send a CRQ
> + * rpavscsi_send_crq: - Send a CRQ
> * @hostdata:the adapter
> * @word1: the first 64 bits of the data
> * @word2: the second 64 bits of the data
> */
> -int ibmvscsi_send_crq(struct ibmvscsi_host_data *hostdata, u64 word1, u64
> word2)
> +static int rpavscsi_send_crq(struct ibmvscsi_host_data *hostdata,
> + u64 word1, u64 word2)
> {
> struct vio_dev *vdev = to_vio_dev(hostdata->dev);
>
> @@ -121,10 +122,10 @@ int ibmvscsi_send_crq(struct ibmvscsi_host_data
> *hostdata, u64 word1, u64 word2)
> }
>
> /**
> - * ibmvscsi_task: - Process srps asynchronously
> + * rpavscsi_task: - Process srps asynchronously
> * @data:ibmvscsi_host_data of host
> */
> -static void ibmvscsi_task(void *data)
> +static void rpavscsi_task(void *data)
> {
> struct ibmvscsi_host_data *hostdata = (struct ibmvscsi_host_data *)data;
> struct vio_dev *vdev = to_vio_dev(hostdata->dev);
> @@ -190,6 +191,42 @@ static void set_adapter_info(struct ibmvscsi_host_data
> *hostdata)
> }
>
> /**
> + * reset_crq_queue: - resets a crq after a failure
> + * @queue: crq_queue to initialize and register
> + * @hostdata:ibmvscsi_host_data of host
> + *
> + */
> +static int rpavscsi_reset_crq_queue(struct crq_queue *queue,
> + struct ibmvscsi_host_data *hostdata)
> +{
> + int rc;
> + struct vio_dev *vdev = to_vio_dev(hostdata->dev);
> +
> + /* Close the CRQ */
> + do {
> + rc = plpar_hcall_norets(H_FREE_CRQ, vdev->unit_address);
> + } while ((rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
> +
> + /* Clean out the queue */
> + memset(queue->msgs, 0x00, PAGE_SIZE);
> + queue->cur = 0;
> +
> + set_adapter_info(hostdata);
> +
> + /* And re-open it again */
> + rc = plpar_hcall_norets(H_REG_CRQ,
> + vdev->unit_address,
> + queue->msg_token, PAGE_SIZE);
> + if (rc == 2) {
> + /* Adapter is good, but other end is not ready */
> + dev_warn(hostdata->dev, "Partner adapter not ready\n");
> + } else if (rc != 0) {
> + dev_warn(hostdata->dev, "couldn't register crq--rc 0x%x\n", rc);
> + }
> + return rc;
> +}
> +
> +/**
> * initialize_crq_queue: - Initializes and registers CRQ with hypervisor
> * @queue: crq_queue to initialize and register
> * @hostdata:ibmvscsi_host_data of host
> @@ -198,9 +235,9 @@ static void set_adapter_info(struct ibmvscsi_host_data
> *hostdata)
> * the crq with the hypervisor.
> * Returns zero on success.
> */
> -int ibmvscsi_init_crq_queue(struct crq_queue *queue,
> - struct ibmvscsi_host_data *hos
Re: [PATCH] lro: myri10ge example how to use LRO
Andrew Gallatin wrote: > To follow up on Jan-Bernd Themann's LRO patch earlier today, > this patch shows how the generic LRO interface can be used for > page based drivers. > > Again, many thanks to Jan-Bernd Themann for leading this effort. > > Drew > > Singed off by: Andrew Gallatin <[EMAIL PROTECTED]> > please take a look at my lro patch for ethtool and see if it works for you, instead of adding another generic module parameter that doesn't need to be there. Thanks. Auke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] lro: eHEA example how to use LRO
Jan-Bernd Themann wrote: > This patch shows how the generic LRO interface is used for SKB mode > > Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]> > > --- > drivers/net/Kconfig |1 + > drivers/net/ehea/ehea.h |9 - > drivers/net/ehea/ehea_ethtool.c | 15 +++ > drivers/net/ehea/ehea_main.c| 84 +++--- > 4 files changed, 101 insertions(+), 8 deletions(-) > > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig > index f8a602c..fec4004 100644 > --- a/drivers/net/Kconfig > +++ b/drivers/net/Kconfig > +module_param(use_lro, int, 0); Have you looked at my generic lro get/set patch that I posted this week? this adds a useless module parameter while ethtool has all the structure already to accomodate setting lro on/off. Auke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pci in arch/powerpc vs arch/ppc
On Fri, Aug 03, 2007 at 05:58:56PM +0300, Alexandros Kostopoulos wrote: > Hi all, > in the old arch/ppc tree, there was a function called pq2ads_setup_pci() > that set up PCI regs for 8272xx, in m82xx_pci.c. I was wandering, where > are these registers configured now in arch/powerpc? I can't seem to find > these code now. It's done by the firmware or the bootwrapper. > Also, I can see that now bus 0, dev 0 (which I think represents the host > bridge, right?) is now excluded using pq2_pci_exclude_device, but it > wasn't in older code. Why is that? The older code probably either excluded all host bridges by class, or just lived with the error message that gets printed on boot. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Page faults blowing up ... [was Re: [PATCH] Fix special PTE code for secondary hash bucket
On Fri, Aug 03, 2007 at 06:58:51PM +1000, Paul Mackerras wrote: > The code for mapping special 4k pages on kernels using a 64kB base > page size was missing the code for doing the RPN (real page number) > manipulation when inserting the hardware PTE in the secondary hash > bucket. It needs the same code as has already been added to the > code that inserts the HPTE in the primary hash bucket. This adds it. So what are the symptoms of hitting this? Does this affect only recent kernels, or old ones too? I'm hitting the craziest bug I've seen in a while, I get some corrputed value in a register: 0x877b21e0 which sure looks like an address with 0x8... instead of 0xc... and, what is even stranger, I find that 0xc77b21e0 is pointing at the data that I *should have had* in the register! And theres some other oddball stuff hinting that a page fault handler ran and blew up: 3:mon> d c77b21e0 c77b21e0 e0008004b224 067410090080 |...$.t..| Well, howdy doody, there's the value that should have been in r3 c77b21f0 c4008e00 49424d00 |IBM.| IBM ??? c77b2200 504800300600 |PH.0| c77b2210 4803 |H...| c77b2220 || c77b2230 554800180600 10004000 |[EMAIL PROTECTED]| c77b2240 2000 4d4300280600 |.. .MC.(| c77b2250 0001 00c3 || c77b2260 e0008004b224 |...$| c77b2270 d00d32c0 80101032 |..22| hey .. wait .. d00d32c0 is the faulting adddress; whats it doing here ??? ... and 80101032 is the value of the MSR ... why is that here ?? c77b2280 || c77b2290 || Any hints or tips appreciated ... btw, I should mention I'm seeing this exact same bug on both 2.6.9 (RHEL4) and on 2.6.16 (SLES10) so... wtf ??? why now ? --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 06/10] 40x decrementer fixes
Josh Boyer wrote: > Why bother doing this?! This will only warrant you imprecise > decrementer >interrupts while it should be interrupting at the precise period currently >(if >you load PIT once)... I.e. the error will only accumulate. NAK. >>>What error exactly? I'm not following you there. If there really is >> I was assuming that the decrementer is in auto-reload mode. Brain fade. >> :-< > Heh, ok. Glad I wasn't completely lost there :). Actually, the current set_dec() which you're fixing made me think so. :-) > josh WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 06/10] 40x decrementer fixes
On Fri, 03 Aug 2007 21:30:57 +0400 Sergei Shtylyov <[EMAIL PROTECTED]> wrote: > Josh Boyer wrote: > > on 40x to match the behavior 44x currently has. > > >>>Why bother doing this?! This will only warrant you imprecise > >>> decrementer > >>>interrupts while it should be interrupting at the precise period currently > >>>(if > >>>you load PIT once)... > > >>I.e. the error will only accumulate. NAK. > > > What error exactly? I'm not following you there. If there really is > >I was assuming that the decrementer is in auto-reload mode. Brain fade. > :-< Heh, ok. Glad I wasn't completely lost there :). josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 06/10] 40x decrementer fixes
Josh Boyer wrote: on 40x to match the behavior 44x currently has. >>>Why bother doing this?! This will only warrant you imprecise decrementer >>>interrupts while it should be interrupting at the precise period currently >>>(if >>>you load PIT once)... >>I.e. the error will only accumulate. NAK. > What error exactly? I'm not following you there. If there really is I was assuming that the decrementer is in auto-reload mode. Brain fade. :-< > josh WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 06/10] 40x decrementer fixes
On Fri, 03 Aug 2007 21:10:19 +0400 Sergei Shtylyov <[EMAIL PROTECTED]> wrote: > I wrote: > > >>Allow generic_calibrate_decr to work for 40x platforms. Given that the > >>hardware > >>behavior is identical, this also changes the set_dec function to reload the > >>PIT > > It's not actually identical. When you're writing to the PIT reg on 40x, > you're alos writing to the hidden PIT auto-reload reg. which is not the case > for 440 that is true Book E. I said the hardware _behavior_ is identical. On both 440 and 405, if the PIT/DEC counts down to 0 and ARE isn't set, it just doesn't tick anymore. The fact that writing to PIT sets the shadow reload reg on 405 doesn't matter since ARE isn't enabled. The same is true for 440 at the moment, since DECAR is never set. > > >>on 40x to match the behavior 44x currently has. > > > Why bother doing this?! This will only warrant you imprecise > > decrementer > > interrupts while it should be interrupting at the precise period currently > > (if > > you load PIT once)... > > I.e. the error will only accumulate. NAK. What error exactly? I'm not following you there. If there really is an error, then we can fix it but it seems that it would be common error for both 440 and 405 at the moment. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 06/10] 40x decrementer fixes
Josh Boyer wrote: >>>Allow generic_calibrate_decr to work for 40x platforms. Given that the >>>hardware >>>behavior is identical, this also changes the set_dec function to reload the >>>PIT >>>on 40x to match the behavior 44x currently has. >>Why bother doing this?! This will only warrant you imprecise decrementer >>interrupts while it should be interrupting at the precise period currently >>(if >>you load PIT once)... > Without some kind of fix, it doesn't function at all. We can load the > PIT once, but then we need to make sure ARE is set because if the PIT > ticks down to zero it just sits there. Ah, sorry... somehow I thought 40x doesn't have TCR and so only a periodic mode. :-< > josh WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] lro: myri10ge example how to use LRO
To follow up on Jan-Bernd Themann's LRO patch earlier today,
this patch shows how the generic LRO interface can be used for
page based drivers.
Again, many thanks to Jan-Bernd Themann for leading this effort.
Drew
Singed off by: Andrew Gallatin <[EMAIL PROTECTED]>
diff -urNp a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
--- a/drivers/net/myri10ge/myri10ge.c 2007-07-24 15:57:12.0 -0400
+++ b/drivers/net/myri10ge/myri10ge.c 2007-08-03 13:07:48.0 -0400
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -62,6 +63,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -89,6 +92,7 @@ MODULE_LICENSE("Dual BSD/GPL");
#define MYRI10GE_EEPROM_STRINGS_SIZE 256
#define MYRI10GE_MAX_SEND_DESC_TSO ((65536 / 2048) * 2)
+#define MYRI10GE_MAX_LRO_DESCRIPTORS 8
#define MYRI10GE_NO_CONFIRM_DATA htonl(0x)
#define MYRI10GE_NO_RESPONSE_RESULT 0x
@@ -151,6 +155,8 @@ struct myri10ge_rx_done {
dma_addr_t bus;
int cnt;
int idx;
+ struct net_lro_mgr lro_mgr;
+ struct net_lro_desc lro_desc[MYRI10GE_MAX_LRO_DESCRIPTORS];
};
struct myri10ge_priv {
@@ -276,6 +282,14 @@ static int myri10ge_debug = -1;/* defau
module_param(myri10ge_debug, int, 0);
MODULE_PARM_DESC(myri10ge_debug, "Debug level (0=none,...,16=all)");
+static int myri10ge_lro = 1;
+module_param(myri10ge_lro, int, S_IRUGO);
+MODULE_PARM_DESC(myri10ge_lro, "Enable large receive offload\n");
+
+static int myri10ge_lro_max_pkts = MYRI10GE_LRO_MAX_PKTS;
+module_param(myri10ge_lro_max_pkts, int, S_IRUGO);
+MODULE_PARM_DESC(myri10ge_lro, "Number of LRO packets to be aggregated\n");
+
static int myri10ge_fill_thresh = 256;
module_param(myri10ge_fill_thresh, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(myri10ge_fill_thresh, "Number of empty rx slots allowed\n");
@@ -1019,6 +1033,15 @@ myri10ge_rx_done(struct myri10ge_priv *m
remainder -= MYRI10GE_ALLOC_SIZE;
}
+ if (mgp->csum_flag && myri10ge_lro) {
+ rx_frags[0].page_offset += MXGEFW_PAD;
+ rx_frags[0].size -= MXGEFW_PAD;
+ len -= MXGEFW_PAD;
+ lro_receive_frags(&mgp->rx_done.lro_mgr, rx_frags,
+ len, len, (void *)(unsigned long)csum, csum);
+ return 1;
+ }
+
hlen = MYRI10GE_HLEN > len ? len : MYRI10GE_HLEN;
/* allocate an skb to attach the page(s) to. */
@@ -1137,6 +1160,9 @@ static inline void myri10ge_clean_rx_don
mgp->stats.rx_packets += rx_packets;
mgp->stats.rx_bytes += rx_bytes;
+ if (myri10ge_lro)
+ lro_flush_all(&rx_done->lro_mgr);
+
/* restock receive rings if needed */
if (mgp->rx_small.fill_cnt - mgp->rx_small.cnt < myri10ge_fill_thresh)
myri10ge_alloc_rx_pages(mgp, &mgp->rx_small,
@@ -1378,7 +1404,8 @@ static const char myri10ge_gstrings_stat
"dropped_pause", "dropped_bad_phy", "dropped_bad_crc32",
"dropped_unicast_filtered", "dropped_multicast_filtered",
"dropped_runt", "dropped_overrun", "dropped_no_small_buffer",
- "dropped_no_big_buffer"
+ "dropped_no_big_buffer", "LRO aggregated", "LRO flushed",
+ "LRO avg aggr", "LRO no_desc"
};
#define MYRI10GE_NET_STATS_LEN 21
@@ -1444,6 +1471,14 @@ myri10ge_get_ethtool_stats(struct net_de
data[i++] = (unsigned int)ntohl(mgp->fw_stats->dropped_overrun);
data[i++] = (unsigned int)ntohl(mgp->fw_stats->dropped_no_small_buffer);
data[i++] = (unsigned int)ntohl(mgp->fw_stats->dropped_no_big_buffer);
+ data[i++] = mgp->rx_done.lro_mgr.stats.aggregated;
+ data[i++] = mgp->rx_done.lro_mgr.stats.flushed;
+ if (mgp->rx_done.lro_mgr.stats.flushed)
+ data[i++] = mgp->rx_done.lro_mgr.stats.aggregated /
+ mgp->rx_done.lro_mgr.stats.flushed;
+ else
+ data[i++] = 0;
+ data[i++] = mgp->rx_done.lro_mgr.stats.no_desc;
}
static void myri10ge_set_msglevel(struct net_device *netdev, u32 value)
@@ -1717,10 +1752,69 @@ static void myri10ge_free_irq(struct myr
pci_disable_msi(pdev);
}
+static int
+myri10ge_get_frag_header(struct skb_frag_struct *frag, void **mac_hdr,
+void **ip_hdr, void **tcpudp_hdr,
+u64 * hdr_flags, void *priv)
+{
+ struct ethhdr *eh;
+ struct vlan_ethhdr *veh;
+ struct iphdr *iph;
+ u8 *va = page_address(frag->page) + frag->page_offset;
+ unsigned long ll_hlen;
+ __wsum csum = (__wsum) (unsigned long)priv;
+
+ /* find the mac header, aborting if not IPv4 */
+
+ eh = (struct ethhdr *)va;
+ *mac_hdr = eh;
+ ll_hlen = ETH_HLEN;
+ if (eh->h_proto != htons(ETH_P_IP)) {
+ if (eh->h_proto == htons(ETH_P_8021Q)) {
+ veh = (struct vlan_ethhdr *)va;
Re: [patch 06/10] 40x decrementer fixes
On Fri, 03 Aug 2007 20:47:03 +0400 Sergei Shtylyov <[EMAIL PROTECTED]> wrote: > Josh Boyer wrote: > > > Allow generic_calibrate_decr to work for 40x platforms. Given that the > > hardware > > behavior is identical, this also changes the set_dec function to reload the > > PIT > > on 40x to match the behavior 44x currently has. > > Why bother doing this?! This will only warrant you imprecise decrementer > interrupts while it should be interrupting at the precise period currently > (if > you load PIT once)... Without some kind of fix, it doesn't function at all. We can load the PIT once, but then we need to make sure ARE is set because if the PIT ticks down to zero it just sits there. If we want to do that, then fine but it should be common between 40x and 44x. I didn't see much of a reason to differ from what's there today. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 06/10] 40x decrementer fixes
I wrote: >>Allow generic_calibrate_decr to work for 40x platforms. Given that the >>hardware >>behavior is identical, this also changes the set_dec function to reload the >>PIT It's not actually identical. When you're writing to the PIT reg on 40x, you're alos writing to the hidden PIT auto-reload reg. which is not the case for 440 that is true Book E. >>on 40x to match the behavior 44x currently has. > Why bother doing this?! This will only warrant you imprecise decrementer > interrupts while it should be interrupting at the precise period currently > (if > you load PIT once)... I.e. the error will only accumulate. NAK. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 06/10] 40x decrementer fixes
Josh Boyer wrote: > Allow generic_calibrate_decr to work for 40x platforms. Given that the > hardware > behavior is identical, this also changes the set_dec function to reload the > PIT > on 40x to match the behavior 44x currently has. Why bother doing this?! This will only warrant you imprecise decrementer interrupts while it should be interrupting at the precise period currently (if you load PIT once)... WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 05/10] 40x MMU
Add MMU definitions for 40x platforms. Also fixes two warnings in 40x_mmu.c.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/head_40x.S |2 -
arch/powerpc/mm/40x_mmu.c |4 +-
include/asm-powerpc/mmu-40x.h | 65 +
include/asm-powerpc/mmu.h |3 +
4 files changed, 71 insertions(+), 3 deletions(-)
--- /dev/null
+++ linux-2.6/include/asm-powerpc/mmu-40x.h
@@ -0,0 +1,65 @@
+#ifndef _ASM_POWERPC_MMU_40X_H_
+#define _ASM_POWERPC_MMU_40X_H_
+
+/*
+ * PPC40x support
+ */
+
+#define PPC40X_TLB_SIZE 64
+
+/*
+ * TLB entries are defined by a "high" tag portion and a "low" data
+ * portion. On all architectures, the data portion is 32-bits.
+ *
+ * TLB entries are managed entirely under software control by reading,
+ * writing, and searchoing using the 4xx-specific tlbre, tlbwr, and tlbsx
+ * instructions.
+ */
+
+#defineTLB_LO 1
+#defineTLB_HI 0
+
+#defineTLB_DATATLB_LO
+#defineTLB_TAG TLB_HI
+
+/* Tag portion */
+
+#define TLB_EPN_MASK0xFC00 /* Effective Page Number */
+#define TLB_PAGESZ_MASK 0x0380
+#define TLB_PAGESZ(x) (((x) & 0x7) << 7)
+#define PAGESZ_1K0
+#define PAGESZ_4K 1
+#define PAGESZ_16K2
+#define PAGESZ_64K3
+#define PAGESZ_256K 4
+#define PAGESZ_1M 5
+#define PAGESZ_4M 6
+#define PAGESZ_16M7
+#define TLB_VALID 0x0040 /* Entry is valid */
+
+/* Data portion */
+
+#define TLB_RPN_MASK0xFC00 /* Real Page Number */
+#define TLB_PERM_MASK 0x0300
+#define TLB_EX 0x0200 /* Instruction execution allowed */
+#define TLB_WR 0x0100 /* Writes permitted */
+#define TLB_ZSEL_MASK 0x00F0
+#define TLB_ZSEL(x) (((x) & 0xF) << 4)
+#define TLB_ATTR_MASK 0x000F
+#define TLB_W 0x0008 /* Caching is write-through */
+#define TLB_I 0x0004 /* Caching is inhibited */
+#define TLB_M 0x0002 /* Memory is coherent */
+#define TLB_G 0x0001 /* Memory is guarded from prefetch */
+
+#ifndef __ASSEMBLY__
+
+typedef unsigned long phys_addr_t;
+
+typedef struct {
+ unsigned long id;
+ unsigned long vdso_base;
+} mm_context_t;
+
+#endif /* !__ASSEMBLY__ */
+
+#endif /* _ASM_POWERPC_MMU_40X_H_ */
--- linux-2.6.orig/include/asm-powerpc/mmu.h
+++ linux-2.6/include/asm-powerpc/mmu.h
@@ -8,6 +8,9 @@
#elif defined(CONFIG_PPC_STD_MMU)
/* 32-bit classic hash table MMU */
# include
+#elif defined(CONFIG_40x)
+/* 40x-style software loaded TLB */
+# include
#elif defined(CONFIG_44x)
/* 44x-style software loaded TLB */
# include
--- linux-2.6.orig/arch/powerpc/mm/40x_mmu.c
+++ linux-2.6/arch/powerpc/mm/40x_mmu.c
@@ -108,7 +108,7 @@ unsigned long __init mmu_mapin_ram(void)
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_16M | _PAGE_HWEXEC |
_PAGE_HWWRITE;
- pmdp = pmd_offset(pgd_offset_k(v), v);
+ pmdp = pmd_offset(pud_offset(pgd_offset_k(v), v), v);
pmd_val(*pmdp++) = val;
pmd_val(*pmdp++) = val;
pmd_val(*pmdp++) = val;
@@ -123,7 +123,7 @@ unsigned long __init mmu_mapin_ram(void)
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_4M | _PAGE_HWEXEC |
_PAGE_HWWRITE;
- pmdp = pmd_offset(pgd_offset_k(v), v);
+ pmdp = pmd_offset(pud_offset(pgd_offset_k(v), v), v);
pmd_val(*pmdp) = val;
v += LARGE_PAGE_SIZE_4M;
--- linux-2.6.orig/arch/powerpc/kernel/head_40x.S
+++ linux-2.6/arch/powerpc/kernel/head_40x.S
@@ -772,7 +772,7 @@ finish_tlb_load:
*/
lwz r9, [EMAIL PROTECTED](0)
addir9, r9, 1
- andi. r9, r9, (PPC4XX_TLB_SIZE-1)
+ andi. r9, r9, (PPC40X_TLB_SIZE-1)
stw r9, [EMAIL PROTECTED](0)
6:
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 10/10] Bamboo zImage wrapper
Add a bootwrapper for the AMCC 440EP Bamboo Eval board. This also adds a
common fixup_clock function for all 440EP(x) chips.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/44x.h |1
arch/powerpc/boot/4xx.c | 82
arch/powerpc/boot/4xx.h |1
arch/powerpc/boot/Makefile |5 +-
arch/powerpc/boot/bamboo.c | 45 +++
arch/powerpc/boot/dcr.h | 10
arch/powerpc/boot/treeboot-bamboo.c | 27 +++
7 files changed, 169 insertions(+), 2 deletions(-)
--- linux-2.6.orig/arch/powerpc/boot/44x.h
+++ linux-2.6/arch/powerpc/boot/44x.h
@@ -11,5 +11,6 @@
#define _PPC_BOOT_44X_H_
void ebony_init(void *mac0, void *mac1);
+void bamboo_init(void);
#endif /* _PPC_BOOT_44X_H_ */
--- linux-2.6.orig/arch/powerpc/boot/4xx.c
+++ linux-2.6/arch/powerpc/boot/4xx.c
@@ -109,3 +109,85 @@ void ibm4xx_fixup_ebc_ranges(const char
setprop(devp, "ranges", ranges, (p - ranges) * sizeof(u32));
}
+
+#define SPRN_CCR1 0x378
+void ibm440ep_fixup_clocks(unsigned int sysclk, unsigned int ser_clk)
+{
+ u32 cpu, plb, opb, ebc, tb, uart0, m, vco;
+ u32 reg;
+ u32 fwdva, fwdvb, fbdv, lfbdv, opbdv0, perdv0, spcid0, prbdv0, tmp;
+
+ mtdcr(DCRN_CPR0_ADDR, CPR0_PLLD0);
+ reg = mfdcr(DCRN_CPR0_DATA);
+ tmp = (reg & 0x000F) >> 16;
+ fwdva = tmp ? tmp : 16;
+ tmp = (reg & 0x0700) >> 8;
+ fwdvb = tmp ? tmp : 8;
+ tmp = (reg & 0x1F00) >> 24;
+ fbdv = tmp ? tmp : 32;
+ lfbdv = (reg & 0x007F);
+
+ mtdcr(DCRN_CPR0_ADDR, CPR0_OPBD0);
+ reg = mfdcr(DCRN_CPR0_DATA);
+ tmp = (reg & 0x0300) >> 24;
+ opbdv0 = tmp ? tmp : 4;
+
+ mtdcr(DCRN_CPR0_ADDR, CPR0_PERD0);
+ reg = mfdcr(DCRN_CPR0_DATA);
+ tmp = (reg & 0x0700) >> 24;
+ perdv0 = tmp ? tmp : 8;
+
+ mtdcr(DCRN_CPR0_ADDR, CPR0_PRIMBD0);
+ reg = mfdcr(DCRN_CPR0_DATA);
+ tmp = (reg & 0x0700) >> 24;
+ prbdv0 = tmp ? tmp : 8;
+
+ mtdcr(DCRN_CPR0_ADDR, CPR0_SCPID);
+ reg = mfdcr(DCRN_CPR0_DATA);
+ tmp = (reg & 0x0300) >> 24;
+ spcid0 = tmp ? tmp : 4;
+
+ /* Calculate M */
+ mtdcr(DCRN_CPR0_ADDR, CPR0_PLLC0);
+ reg = mfdcr(DCRN_CPR0_DATA);
+ tmp = (reg & 0x0300) >> 24;
+ if (tmp == 0) { /* PLL output */
+ tmp = (reg & 0x2000) >> 29;
+ if (!tmp) /* PLLOUTA */
+ m = fbdv * lfbdv * fwdva;
+ else
+ m = fbdv * lfbdv * fwdvb;
+ }
+ else if (tmp == 1) /* CPU output */
+ m = fbdv * fwdva;
+ else
+ m = perdv0 * opbdv0 * fwdvb;
+
+ vco = (m * sysclk) + (m >> 1);
+ cpu = vco / fwdva;
+ plb = vco / fwdvb / prbdv0;
+ opb = plb / opbdv0;
+ ebc = plb / perdv0;
+
+ /* FIXME */
+ uart0 = ser_clk;
+
+ /* Figure out timebase. Either CPU or default TmrClk */
+ asm volatile (
+ "mfspr %0,%1\n"
+ :
+ "=&r"(reg) : "i"(SPRN_CCR1));
+ if (reg & 0x0080)
+ tb = 2500; /* TmrClk is 25MHz */
+ else
+ tb = cpu;
+
+ dt_fixup_cpu_clocks(cpu, tb, 0);
+ dt_fixup_clock("/plb", plb);
+ dt_fixup_clock("/plb/opb", opb);
+ dt_fixup_clock("/plb/opb/ebc", ebc);
+ dt_fixup_clock("/plb/opb/[EMAIL PROTECTED]", uart0);
+ dt_fixup_clock("/plb/opb/[EMAIL PROTECTED]", uart0);
+ dt_fixup_clock("/plb/opb/[EMAIL PROTECTED]", uart0);
+ dt_fixup_clock("/plb/opb/[EMAIL PROTECTED]", uart0);
+}
--- linux-2.6.orig/arch/powerpc/boot/4xx.h
+++ linux-2.6/arch/powerpc/boot/4xx.h
@@ -16,5 +16,6 @@ void ibm44x_dbcr_reset(void);
void ibm40x_dbcr_reset(void);
void ibm4xx_quiesce_eth(u32 *emac0, u32 *emac1);
void ibm4xx_fixup_ebc_ranges(const char *ebc);
+void ibm440ep_fixup_clocks(unsigned int sysclk, unsigned int ser_clk);
#endif /* _POWERPC_BOOT_4XX_H_ */
--- linux-2.6.orig/arch/powerpc/boot/Makefile
+++ linux-2.6/arch/powerpc/boot/Makefile
@@ -44,10 +44,10 @@ $(addprefix $(obj)/,$(zlib) gunzip_util.
src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
- 4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c
+ 4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
- ps3-head.S ps3-hvcall.S ps3.c
+ ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -142,6 +142,7 @@ ifneq ($(CONFIG_D
[patch 09/10] Bamboo board support
Add support for the AMCC Bamboo board Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> --- arch/powerpc/configs/bamboo_defconfig | 775 ++ arch/powerpc/platforms/44x/Kconfig| 15 arch/powerpc/platforms/44x/Makefile |1 arch/powerpc/platforms/44x/bamboo.c | 66 ++ 4 files changed, 850 insertions(+), 7 deletions(-) --- /dev/null +++ linux-2.6/arch/powerpc/configs/bamboo_defconfig @@ -0,0 +1,775 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.23-rc1 +# Fri Aug 3 10:46:53 2007 +# +# CONFIG_PPC64 is not set + +# +# Processor support +# +# CONFIG_6xx is not set +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +CONFIG_44x=y +# CONFIG_E200 is not set +CONFIG_PPC_FPU=y +CONFIG_4xx=y +CONFIG_BOOKE=y +CONFIG_PTE_64BIT=y +CONFIG_PHYS_64BIT=y +# CONFIG_PPC_MM_SLICES is not set +CONFIG_NOT_COHERENT_CACHE=y +CONFIG_PPC32=y +CONFIG_PPC_MERGE=y +CONFIG_MMU=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_IRQ_PER_CPU=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_ARCH_HAS_ILOG2_U32=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_FIND_NEXT_BIT=y +# CONFIG_ARCH_NO_VIRT_TO_BUS is not set +CONFIG_PPC=y +CONFIG_EARLY_PRINTK=y +CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_OF=y +CONFIG_PPC_UDBG_16550=y +# CONFIG_GENERIC_TBSYNC is not set +CONFIG_AUDIT_ARCH=y +CONFIG_GENERIC_BUG=y +# CONFIG_DEFAULT_UIMAGE is not set +CONFIG_PPC_DCR_NATIVE=y +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_PPC_DCR=y +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_POSIX_MQUEUE=y +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_USER_NS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_SYSFS_DEPRECATED=y +# CONFIG_RELAY is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y +CONFIG_BLOCK=y +CONFIG_LBD=y +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" + +# +# Platform support +# +# CONFIG_PPC_MPC52xx is not set +# CONFIG_PPC_MPC5200 is not set +# CONFIG_PPC_CELL is not set +# CONFIG_PPC_CELL_NATIVE is not set +# CONFIG_PQ2ADS is not set +CONFIG_BAMBOO=y +# CONFIG_EBONY is not set +CONFIG_440EP=y +CONFIG_IBM440EP_ERR42=y +# CONFIG_MPIC is not set +# CONFIG_MPIC_WEIRD is not set +# CONFIG_PPC_I8259 is not set +# CONFIG_PPC_RTAS is not set +# CONFIG_MMIO_NVRAM is not set +# CONFIG_PPC_MPC106 is not set +# CONFIG_PPC_970_NAP is not set +# CONFIG_PPC_INDIRECT_IO is not set +# CONFIG_GENERIC_IOMAP is not set +# CONFIG_CPU_FREQ is not set +# CONFIG_CPM2 is not set + +# +# Kernel options +# +# CONFIG_HIGHMEM is not set +# CONFIG_HZ_100 is not set +CONFIG_HZ_250=y +# CONFIG_HZ_300 is not set +# CONFIG_HZ_1000 is not set +CONFIG_HZ=250 +CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_VOLUNTARY is not set +# CONFIG_PREEMPT is not set +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set +# CONFIG_MATH_EMULATION is not set +CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y +CONFIG_ARCH_FLATMEM_ENABLE=y +CONFIG_ARCH_POPULATES_NODE_MAP=y +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_FLATMEM_MANUAL=y +# CONFIG_DISCONTIGMEM_MANUAL is not set +# CONFIG_SPARSEMEM_MANUAL is not set +CONFIG_FLATMEM=y +CONFIG_FLAT_NODE_MEM_MAP=y +# CONFIG_SPARSEMEM_STATIC is not set +CONFIG_SPLIT_PTLOCK_CPUS=4 +CONFIG_RESOURCES_64BIT=y +CONFIG_ZONE_DMA_FLAG=1 +CONFIG_BOUNCE=y +CONFIG_VIRT_TO_BUS=y +CONFIG_PROC_DEVICETREE=y +CONFIG_CMDLINE_BOOL=y +CONFIG_CMDLINE="" +CONFIG_SECCOMP=y +CONFIG_WANT_DEVICE_TREE=y +CONFIG_DEVICE_TREE="bamboo.dts" +CONFIG_ISA_DMA_API=y + +# +# Bus options +# +CONFIG_ZONE_DMA=y +CONFIG_PPC_INDIRECT_PCI=y +CONF
[patch 07/10] Fix 40x build
Remove inclusion of __res on 40x. We don't need it in arch/powerpc Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> --- arch/powerpc/kernel/head_40x.S |1 - arch/powerpc/kernel/ppc_ksyms.c |2 +- 2 files changed, 1 insertion(+), 2 deletions(-) --- linux-2.6.orig/arch/powerpc/kernel/ppc_ksyms.c +++ linux-2.6/arch/powerpc/kernel/ppc_ksyms.c @@ -180,7 +180,7 @@ EXPORT_SYMBOL(cacheable_memcpy); EXPORT_SYMBOL(cpm_install_handler); EXPORT_SYMBOL(cpm_free_handler); #endif /* CONFIG_8xx */ -#if defined(CONFIG_8xx) || defined(CONFIG_40x) +#if defined(CONFIG_8xx) EXPORT_SYMBOL(__res); #endif --- linux-2.6.orig/arch/powerpc/kernel/head_40x.S +++ linux-2.6/arch/powerpc/kernel/head_40x.S @@ -35,7 +35,6 @@ #include #include #include -#include #include #include #include -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 08/10] Bamboo DTS
AMCC Bamboo board DTS
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/bamboo.dts | 248 +++
1 file changed, 248 insertions(+)
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/dts/bamboo.dts
@@ -0,0 +1,248 @@
+/*
+ * Device Tree Source for AMCC Bamboo
+ *
+ * Copyright (c) 2006, 2007 IBM Corp.
+ * Josh Boyer <[EMAIL PROTECTED]>
+ *
+ * FIXME: Draft only!
+ *
+ * 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.
+ *
+ * To build:
+ * dtc -I dts -O asm -o bamboo.S -b 0 bamboo.dts
+ * dtc -I dts -O dtb -o bamboo.dtb -b 0 bamboo.dts
+ */
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,bamboo";
+ compatible = "amcc,bamboo";
+ dcr-parent = <&/cpus/PowerPC,[EMAIL PROTECTED]>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ timebase-frequency = <0>; /* Filled in by zImage */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <8000>;
+ d-cache-size = <8000>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0>; /* Filled in by zImage */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-440gp","ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-440gp","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-440ep";
+ dcr-reg = <00e 002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-440ep";
+ dcr-reg = <00c 002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-440gp", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ SDRAM0: sdram {
+ compatible = "ibm,sdram-405gp";
+ dcr-reg = <010 2>;
+ };
+
+ DMA0: dma {
+ compatible = "ibm,dma-440gp";
+ dcr-reg = <100 027>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-440gp", "ibm,mcmal";
+ dcr-reg = <180 62>;
+ num-tx-chans = <4>;
+ num-rx-chans = <4>;
+ interrupt-parent = <&MAL0>;
+ interrupts = <0 1 2 3 4>;
+ #interrupt-cells = <1>;
+ interrupt-map = ;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-440gp", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ /* Bamboo is oddball in the 44x world and doesn't use
the ERPN
+* bits.
+*/
+ ranges = < 0 8000
+ 8000 0 8000 8000>;
+ interrupt-parent = <&UIC1>;
+ interrupts = <7 4>;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-440gp", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ ranges;
+ interrupts = <5 1>;
+ interrupt-parent = <&UIC1>;
+ };
+
+ UART0: [EMAIL PROTECTED] {
+ device_type = "serial";
+
[patch 06/10] 40x decrementer fixes
Allow generic_calibrate_decr to work for 40x platforms. Given that the hardware
behavior is identical, this also changes the set_dec function to reload the PIT
on 40x to match the behavior 44x currently has.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/time.c |2 +-
include/asm-powerpc/time.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.orig/arch/powerpc/kernel/time.c
+++ linux-2.6/arch/powerpc/kernel/time.c
@@ -867,7 +867,7 @@ void __init generic_calibrate_decr(void)
"(not found)\n");
}
-#ifdef CONFIG_BOOKE
+#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
/* Set the time base to zero */
mtspr(SPRN_TBWL, 0);
mtspr(SPRN_TBWU, 0);
--- linux-2.6.orig/include/asm-powerpc/time.h
+++ linux-2.6/include/asm-powerpc/time.h
@@ -174,7 +174,7 @@ static inline unsigned int get_dec(void)
static inline void set_dec(int val)
{
#if defined(CONFIG_40x)
- return; /* Have to let it auto-reload */
+ mtspr(SPRN_PIT, val);
#elif defined(CONFIG_8xx_CPU6)
set_dec_cpu6(val);
#else
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 04/10] 4xx bootwrapper reworks
Make the fixup_memsize function common for all of 4xx as several chips share
the same SDRAM controller. Also add functions to reset 40x chips and quiesce
the ethernet.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/44x.h |4
arch/powerpc/boot/4xx.c | 36 +++-
arch/powerpc/boot/4xx.h | 20
arch/powerpc/boot/dcr.h |2 ++
arch/powerpc/boot/ebony.c |3 ++-
5 files changed, 55 insertions(+), 10 deletions(-)
--- linux-2.6.orig/arch/powerpc/boot/44x.h
+++ linux-2.6/arch/powerpc/boot/44x.h
@@ -10,10 +10,6 @@
#ifndef _PPC_BOOT_44X_H_
#define _PPC_BOOT_44X_H_
-void ibm44x_fixup_memsize(void);
-void ibm4xx_fixup_ebc_ranges(const char *ebc);
-
-void ibm44x_dbcr_reset(void);
void ebony_init(void *mac0, void *mac1);
#endif /* _PPC_BOOT_44X_H_ */
--- linux-2.6.orig/arch/powerpc/boot/4xx.c
+++ linux-2.6/arch/powerpc/boot/4xx.c
@@ -21,8 +21,8 @@
#include "reg.h"
#include "dcr.h"
-/* Read the 44x memory controller to get size of system memory. */
-void ibm44x_fixup_memsize(void)
+/* Read the 4xx SDRAM controller to get size of system memory. */
+void ibm4xx_fixup_memsize(void)
{
int i;
unsigned long memsize, bank_config;
@@ -39,22 +39,48 @@ void ibm44x_fixup_memsize(void)
dt_fixup_memory(0, memsize);
}
-#define SPRN_DBCR0 0x134
-#define DBCR0_RST_SYSTEM 0x3000
+#define DBCR0_RST_SYSTEM 0x3000
void ibm44x_dbcr_reset(void)
{
unsigned long tmp;
+ /* DBCR0 on 44x is SPRN 0x134 */
asm volatile (
"mfspr %0,%1\n"
"oris %0,%0,[EMAIL PROTECTED]"
"mtspr %1,%0"
- : "=&r"(tmp) : "i"(SPRN_DBCR0), "i"(DBCR0_RST_SYSTEM)
+ : "=&r"(tmp) : "i"(0x134), "i"(DBCR0_RST_SYSTEM)
);
}
+void ibm40x_dbcr_reset(void)
+{
+ unsigned long tmp;
+
+ /* DBCR0 on 40x is SPRN 0x3F2 */
+ asm volatile (
+ "mfspr %0,%1\n"
+ "oris %0,%0,[EMAIL PROTECTED]"
+ "mtspr %1,%0"
+ : "=&r"(tmp) : "i"(0x3F2), "i"(DBCR0_RST_SYSTEM)
+ );
+}
+
+#define EMAC_RESET 0x2000
+#define MAL_RESET 0x8000
+void ibm4xx_quiesce_eth(u32 *emac0, u32 *emac1)
+{
+ /* Quiesce the MAL and EMAC(s) since PIBS/OpenBIOS don't do this for us
*/
+ if (emac0)
+ *emac0 = EMAC_RESET;
+ if (emac1)
+ *emac1 = EMAC_RESET;
+
+ mtdcr(DCRN_MAL0_CFG, MAL_RESET);
+}
+
/* Read 4xx EBC bus bridge registers to get mappings of the peripheral
* banks into the OPB address space */
void ibm4xx_fixup_ebc_ranges(const char *ebc)
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/4xx.h
@@ -0,0 +1,20 @@
+/*
+ * PowerPC 4xx related functions
+ *
+ * Copyright 2007 IBM Corporation.
+ * Josh Boyer <[EMAIL PROTECTED]>
+ *
+ * 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.
+ */
+#ifndef _POWERPC_BOOT_4XX_H_
+#define _POWERPC_BOOT_4XX_H_
+
+void ibm4xx_fixup_memsize(void);
+void ibm44x_dbcr_reset(void);
+void ibm40x_dbcr_reset(void);
+void ibm4xx_quiesce_eth(u32 *emac0, u32 *emac1);
+void ibm4xx_fixup_ebc_ranges(const char *ebc);
+
+#endif /* _POWERPC_BOOT_4XX_H_ */
--- linux-2.6.orig/arch/powerpc/boot/dcr.h
+++ linux-2.6/arch/powerpc/boot/dcr.h
@@ -121,4 +121,6 @@ static const unsigned long sdram_bxcr[]
#define DCRN_CPC0_MIRQ10x0ed
#define DCRN_CPC0_JTAGID 0x0ef
+#define DCRN_MAL0_CFG 0x180
+
#endif /* _PPC_BOOT_DCR_H_ */
--- linux-2.6.orig/arch/powerpc/boot/ebony.c
+++ linux-2.6/arch/powerpc/boot/ebony.c
@@ -25,6 +25,7 @@
#include "ops.h"
#include "reg.h"
#include "dcr.h"
+#include "4xx.h"
#include "44x.h"
extern char _dtb_start[];
@@ -98,7 +99,7 @@ static void ebony_fixups(void)
unsigned long sysclk = 3300;
ibm440gp_fixup_clocks(sysclk, 6 * 1843200);
- ibm44x_fixup_memsize();
+ ibm4xx_fixup_memsize();
dt_fixup_mac_addresses(ebony_mac0, ebony_mac1);
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
}
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 03/10] Rename 44x bootwrapper
Rename the 44x.c wrapper file to 4xx.c. This will allow us to add common
functions in a single file that can be shared across all of 4xx.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/44x.c| 85 -
arch/powerpc/boot/4xx.c| 85 +
arch/powerpc/boot/Makefile |4 +-
3 files changed, 87 insertions(+), 87 deletions(-)
--- linux-2.6.orig/arch/powerpc/boot/44x.c
+++ /dev/null
@@ -1,85 +0,0 @@
-/*
- * Copyright 2007 David Gibson, IBM Corporation.
- *
- * Based on earlier code:
- * Matt Porter <[EMAIL PROTECTED]>
- * Copyright 2002-2005 MontaVista Software Inc.
- *
- * Eugene Surovegin <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
- * Copyright (c) 2003, 2004 Zultys Technologies
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-#include
-#include "types.h"
-#include "string.h"
-#include "stdio.h"
-#include "ops.h"
-#include "reg.h"
-#include "dcr.h"
-
-/* Read the 44x memory controller to get size of system memory. */
-void ibm44x_fixup_memsize(void)
-{
- int i;
- unsigned long memsize, bank_config;
-
- memsize = 0;
- for (i = 0; i < ARRAY_SIZE(sdram_bxcr); i++) {
- mtdcr(DCRN_SDRAM0_CFGADDR, sdram_bxcr[i]);
- bank_config = mfdcr(DCRN_SDRAM0_CFGDATA);
-
- if (bank_config & SDRAM_CONFIG_BANK_ENABLE)
- memsize += SDRAM_CONFIG_BANK_SIZE(bank_config);
- }
-
- dt_fixup_memory(0, memsize);
-}
-
-#define SPRN_DBCR0 0x134
-#define DBCR0_RST_SYSTEM 0x3000
-
-void ibm44x_dbcr_reset(void)
-{
- unsigned long tmp;
-
- asm volatile (
- "mfspr %0,%1\n"
- "oris %0,%0,[EMAIL PROTECTED]"
- "mtspr %1,%0"
- : "=&r"(tmp) : "i"(SPRN_DBCR0), "i"(DBCR0_RST_SYSTEM)
- );
-
-}
-
-/* Read 4xx EBC bus bridge registers to get mappings of the peripheral
- * banks into the OPB address space */
-void ibm4xx_fixup_ebc_ranges(const char *ebc)
-{
- void *devp;
- u32 bxcr;
- u32 ranges[EBC_NUM_BANKS*4];
- u32 *p = ranges;
- int i;
-
- for (i = 0; i < EBC_NUM_BANKS; i++) {
- mtdcr(DCRN_EBC0_CFGADDR, EBC_BXCR(i));
- bxcr = mfdcr(DCRN_EBC0_CFGDATA);
-
- if ((bxcr & EBC_BXCR_BU) != EBC_BXCR_BU_OFF) {
- *p++ = i;
- *p++ = 0;
- *p++ = bxcr & EBC_BXCR_BAS;
- *p++ = EBC_BXCR_BANK_SIZE(bxcr);
- }
- }
-
- devp = finddevice(ebc);
- if (! devp)
- fatal("Couldn't locate EBC node %s\n\r", ebc);
-
- setprop(devp, "ranges", ranges, (p - ranges) * sizeof(u32));
-}
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/4xx.c
@@ -0,0 +1,85 @@
+/*
+ * Copyright 2007 David Gibson, IBM Corporation.
+ *
+ * Based on earlier code:
+ * Matt Porter <[EMAIL PROTECTED]>
+ * Copyright 2002-2005 MontaVista Software Inc.
+ *
+ * Eugene Surovegin <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
+ * Copyright (c) 2003, 2004 Zultys Technologies
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include
+#include "types.h"
+#include "string.h"
+#include "stdio.h"
+#include "ops.h"
+#include "reg.h"
+#include "dcr.h"
+
+/* Read the 44x memory controller to get size of system memory. */
+void ibm44x_fixup_memsize(void)
+{
+ int i;
+ unsigned long memsize, bank_config;
+
+ memsize = 0;
+ for (i = 0; i < ARRAY_SIZE(sdram_bxcr); i++) {
+ mtdcr(DCRN_SDRAM0_CFGADDR, sdram_bxcr[i]);
+ bank_config = mfdcr(DCRN_SDRAM0_CFGDATA);
+
+ if (bank_config & SDRAM_CONFIG_BANK_ENABLE)
+ memsize += SDRAM_CONFIG_BANK_SIZE(bank_config);
+ }
+
+ dt_fixup_memory(0, memsize);
+}
+
+#define SPRN_DBCR0 0x134
+#define DBCR0_RST_SYSTEM 0x3000
+
+void ibm44x_dbcr_reset(void)
+{
+ unsigned long tmp;
+
+ asm volatile (
+ "mfspr %0,%1\n"
+ "oris %0,%0,[EMAIL PROTECTED]"
+ "mtspr %1,%0"
+ : "=&r"(tmp) : "i"(SPRN_DBCR0), "i"(DBCR0_RST_SYSTEM)
+ );
+
+}
+
+/* Read 4xx EBC bus bridge registers to get mappings of the peripheral
+ * banks into the OPB address space */
+void ibm4xx_fixup_ebc_ranges(const char *ebc)
+{
+ void *devp;
+ u32 bxcr;
+ u32 ranges[EBC_NUM_BANKS*4];
+ u32 *p = ranges;
+ int i;
+
+ for (i = 0; i
[patch 02/10] 4xx Kconfig cleanup
Remove some leftover cruft in the 40x Kconfig file. Also make sure we select WANT_DEVICE_TREE for 40x. Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> --- arch/powerpc/platforms/40x/Kconfig | 77 - arch/powerpc/platforms/Kconfig.cputype |1 2 files changed, 1 insertion(+), 77 deletions(-) --- linux-2.6.orig/arch/powerpc/platforms/40x/Kconfig +++ linux-2.6/arch/powerpc/platforms/40x/Kconfig @@ -1,16 +1,3 @@ -config 4xx - bool - depends on 40x || 44x - default y - -config BOOKE - bool - depends on 44x - default y - -menu "AMCC 40x options" - depends on 40x - #config BUBINGA # bool "Bubinga" # depends on 40x @@ -82,8 +69,6 @@ menu "AMCC 40x options" # help #This option enables support for the Xilinx ML300 evaluation board. -endmenu - # 40x specific CPU modules, selected based on the board above. config NP405H bool @@ -126,68 +111,6 @@ config IBM405_ERR77 config IBM405_ERR51 bool -menu "AMCC 44x options" - depends on 44x - -#config BAMBOO -# bool "Bamboo" -# depends on 44x -# default n -# select 440EP -# help -#This option enables support for the IBM PPC440EP evaluation board. - -config EBONY - bool "Ebony" - depends on 44x - default y - select 440GP - help - This option enables support for the IBM PPC440GP evaluation board. - -#config LUAN -# bool "Luan" -# depends on 44x -# default n -# select 440SP -# help -#This option enables support for the IBM PPC440SP evaluation board. - -#config OCOTEA -# bool "Ocotea" -# depends on 44x -# default n -# select 440GX -# help -#This option enables support for the IBM PPC440GX evaluation board. - -endmenu - -# 44x specific CPU modules, selected based on the board above. -config 440EP - bool - select PPC_FPU - select IBM440EP_ERR42 - -config 440GP - bool - select IBM_NEW_EMAC_ZMII - -config 440GX - bool - -config 440SP - bool - -config 440A - bool - depends on 440GX - default y - -# 44x errata/workaround config symbols, selected by the CPU models above -config IBM440EP_ERR42 - bool - #config XILINX_OCP # bool # depends on XILINX_ML300 --- linux-2.6.orig/arch/powerpc/platforms/Kconfig.cputype +++ linux-2.6/arch/powerpc/platforms/Kconfig.cputype @@ -40,6 +40,7 @@ config PPC_8xx config 40x bool "AMCC 40x" select PPC_DCR_NATIVE + select WANT_DEVICE_TREE config 44x bool "AMCC 44x" -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 00/10] 4xx patch series for 2.6.24
Here are the current 4xx patches I'd like to get in to 2.6.24. They include some initial cleanups for 40x support as well as the AMCC Bamboo board support. If we can get Bamboo merged, that will make it much easier for Sequoia (440EPx) and Rainer (440GRx) to follow on. Also, I've started a git tree for 4xx work. It contains these patches on the for-2.6.24 branch. If you do git pull \ git://git.infradead.org/users/jwboyer/powerpc.git for-2.6.24 You should get this entire series. It is currently based off of Paul's latest tree. josh -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
David Gibson wrote: > Duh, forgot to attach the actual patch. Here it is: > Index: working-2.6/Documentation/powerpc/booting-without-of.txt > === > --- working-2.6.orig/Documentation/powerpc/booting-without-of.txt > 2007-07-30 17:07:14.0 +1000 > +++ working-2.6/Documentation/powerpc/booting-without-of.txt 2007-07-30 > 17:07:14.0 +1000 > @@ -1757,45 +1757,23 @@ platforms are moved over to use the flat > }; > }; > > -j) Flash chip nodes > + j) CFI or JEDEC memory-mapped NOR flash > > Flash chips (Memory Technology Devices) are often used for solid state > file systems on embedded devices. > > -Required properties: > + - compatible : should contain the specific model of flash chip(s) used > + followed by either "cfi-flash" or "jedec-flash" Duh, have nearly forgotten to complain about "-flash" suffix. Isn't it superfluous? WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
Hello.
David Gibson wrote:
>>>Index: working-2.6/Documentation/powerpc/booting-without-of.txt
>>>===
>>>--- working-2.6.orig/Documentation/powerpc/booting-without-of.txt
>>>2007-07-30 17:07:14.0 +1000
>>>+++ working-2.6/Documentation/powerpc/booting-without-of.txt 2007-07-30
>>>17:07:14.0 +1000
>>>@@ -1757,45 +1757,23 @@ platforms are moved over to use the flat
>>> };
>>> };
>>>
>>>-j) Flash chip nodes
>>>+ j) CFI or JEDEC memory-mapped NOR flash
>>>
>>> Flash chips (Memory Technology Devices) are often used for solid state
>>> file systems on embedded devices.
>>>-Required properties:
>>>+ - compatible : should contain the specific model of flash chip(s) used
>>>+ followed by either "cfi-flash" or "jedec-flash"
>>This "compatible" prop (and the node in whole) doesn't say a
>>thing about how the flash is mapped into the CPU address space. I
>>strongly disagree that this node provides enough info to select a
>>driver. :-/
> To be honest, I'm not sure that describing the mapping is really the
> job of the compatible property. That the flash is mapped into the
> address space is kind of implicit in the way the reg interacts with
> the parents' ranges property.
Ah, I keep forgetting about implied 1:1 parent/child address
correspondence... :-<
But does it really imply how the (low) address bits of the *child* bus
("ebc" in this case) are connected to the chip? I don't think so...
> Can you describe some of the options for *not* direct mapped flash
> chips - I can't reasonably come up with a way of describing the
> distinction when I've never seen NOR flash other than direct mapped.
You're lucky to live in the single-endian world. Once you're in bi-endian
one, all kinds of strange mappings become possible. I've seen the MIPS
mapping driver which required swapping flash bytes in s/w in BE mode, i.e.
couldn't be served by physmap, yet that's not all... here's the code of its
map read*() methods:
static __u8 xxx_map_read8(struct map_info *map, unsigned long offs)
{
u16 val;
val = readw(map->map_priv_1 + (offs & ~1));
if (offs & 1)
return ((val >> 8) & 0xff);
else
return (val & 0xff);
}
static __u16 bcm947xx_map_read16(struct map_info *map, unsigned long offs)
{
return readw(map->map_priv_1 + offs);
}
static __u32 bcm947xx_map_read32(struct map_info *map, unsigned long offs)
{
return readl(map->map_priv_1 + offs);
}
... while the simple map (used by physmap) has just __raw_read*() for those?
>>>+ - reg : Address range of the flash chip
>>>+ - bank-width : Width (in bytes) of the flash bank. Equal to the
>>>device width
>>>+ times the number of interleaved chips.
>>>+ - device-width : (optional) Width of a single flash chip. If omitted,
>>>+ assumed to be equal to 'bank-width'.
>>Why then not just introduce the "interleave" prop and obsolete the
>>"bank-width"?
> Because they're equivalent information, and bank-width is what the
> code ends up actually caring about. I don't see any reason to prefer
> giving the interleave.
Well, "device-width" is not the thing that we care about either. ;-)
>>>Index: working-2.6/drivers/mtd/maps/physmap_of.c
>>>===
>>>--- working-2.6.orig/drivers/mtd/maps/physmap_of.c 2007-07-30
>>>17:07:11.0 +1000
>>>+++ working-2.6/drivers/mtd/maps/physmap_of.c2007-07-30
>>>17:07:14.0 +1000
[...]
>>>+for (pp = dp->child, i = 0 ; pp; pp = pp->sibling, i++) {
>>>+const u32 *reg;
>>>+const char *name;
>>>+const void *ro;
>>
>>We hardly need the above 2 variables.
> They're all used...
I meant that there's no necessity in them.
[...]
>>Oh, I see that the new partition representation have really simplified
>>parsing -- this function is hardly shorter than the old one... :-P
> They new format isn't supposed to be simpler to parse: it's supposed
> to be more flexible if we ever need to add more per-partition
> information than just the offset / size / read-only.
Well, if we ever need that indeed... :-)
[...]
>>>@@ -221,6 +297,14 @@ err_out:
>>>
>>> static struct of_device_id of_physmap_match[] = {
>>> {
>>>+.compatible = "cfi-flash",
>>>+.data = (void *)"cfi_probe",
>>>+},
>>>+{
>>>+.compatible = "jedec-flash",
>>>+.data = (void *)"jedec_probe",
>>>+},
>>>+{
>>This would also trigger on non-linearly mapped CFI or JEDEC
>>flashes which is not a good idea -- however, as we're using the MTD
>>probing code anyway, it will just fail, so it's not luckily is not a
>>fatal design flaw.
> Well, if there's nothing else to distinguish them. Which there isn't
> yet,
Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
On Fri, 2007-08-03 at 01:35, David Gibson wrote:
> > > + PIC8259: interrupt-controller {
> > > + device_type = "i8259";
> > >
> > > device_type = "interrupt-controller".
>
> Is that really right? The MPIC binding, at least, has device_type =
> "open-pic" rather than "interrupt-controller".
>
> > > + compatible = "prep,iic";
> > > + reg = < 0001 0020 0002
> > > + 0001 00a0 0002
> > > + 0001 04d0 0002>;
> > > + interrupts = < 0003
> > > + 0002 0003>;
> > > + interrupt-parent = <&MPIC>;
> > > + };
> > > + };
> > > +
> > > + MPIC: [EMAIL PROTECTED] {
> > > + device_type = "open-pic";
> > >
> > > device_type = "interrupt-controller".
>
> Not according to the binding in booting-without-of.txt
My understanding here, though possibly flawed, is that the current
implementation has "open-pic" but _should_ have "interrupt-controller"
as that is the officially correct name.
I _think_ this means we need a transitional period where we update
the code to look for "interrupt-controller", and obsoletedly, looks
for the "open-pic", while we transition to the new, correct name.
I'm just betting that if I'm wrong Segher will tell me! :-)
jdl
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
pci in arch/powerpc vs arch/ppc
Hi all, in the old arch/ppc tree, there was a function called pq2ads_setup_pci() that set up PCI regs for 8272xx, in m82xx_pci.c. I was wandering, where are these registers configured now in arch/powerpc? I can't seem to find these code now. Also, I can see that now bus 0, dev 0 (which I think represents the host bridge, right?) is now excluded using pq2_pci_exclude_device, but it wasn't in older code. Why is that? thank you in advance... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1] lro: Generic Large Receive Offload for TCP traffic
On Fri, 3 August 2007 14:41:19 +0200, Jan-Bernd Themann wrote: > > This patch provides generic Large Receive Offload (LRO) functionality > for IPv4/TCP traffic. > > LRO combines received tcp packets to a single larger tcp packet and > passes them then to the network stack in order to increase performance > (throughput). The interface supports two modes: Drivers can either pass > SKBs or fragment lists to the LRO engine. Maybe this is a stupid question, but why is LRO done at the device driver level? If it is a unversal performance benefit, I would have expected it to be done generically, i.e. have all packets moved into network layer pass through LRO instead. > +void lro_flush_pkt(struct net_lro_mgr *lro_mgr, > +struct iphdr *iph, struct tcphdr *tcph); In particular this bit looks like it should be driven by a timeout, which would be settable via /proc/sys/net/core/lro_timeout or similar. Jörn -- Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. -- M.A. Jackson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] lro: eHEA example how to use LRO
This patch shows how the generic LRO interface is used for SKB mode
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/Kconfig |1 +
drivers/net/ehea/ehea.h |9 -
drivers/net/ehea/ehea_ethtool.c | 15 +++
drivers/net/ehea/ehea_main.c| 84 +++---
4 files changed, 101 insertions(+), 8 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f8a602c..fec4004 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2399,6 +2399,7 @@ config CHELSIO_T3
config EHEA
tristate "eHEA Ethernet support"
depends on IBMEBUS
+ select INET_LRO
---help---
This driver supports the IBM pSeries eHEA ethernet adapter.
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index d67f97b..70e33fe 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -33,13 +33,14 @@
#include
#include
#include
+#include
#include
#include
#include
#define DRV_NAME "ehea"
-#define DRV_VERSION"EHEA_0073"
+#define DRV_VERSION"EHEA_0074"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
@@ -58,6 +59,7 @@
#define EHEA_SMALL_QUEUES
#define EHEA_NUM_TX_QP 1
+#define EHEA_LRO_MAX_AGGR 64
#ifdef EHEA_SMALL_QUEUES
#define EHEA_MAX_CQE_COUNT 1023
@@ -84,6 +86,8 @@
#define EHEA_RQ2_PKT_SIZE 1522
#define EHEA_L_PKT_SIZE 256/* low latency */
+#define MAX_LRO_DESCRIPTORS 8
+
/* Send completion signaling */
/* Protection Domain Identifier */
@@ -376,6 +380,8 @@ struct ehea_port_res {
u64 tx_packets;
u64 rx_packets;
u32 poll_counter;
+ struct net_lro_mgr lro_mgr;
+ struct net_lro_desc lro_desc[MAX_LRO_DESCRIPTORS];
};
@@ -427,6 +433,7 @@ struct ehea_port {
u32 msg_enable;
u32 sig_comp_iv;
u32 state;
+ u32 lro_max_aggr;
u8 full_duplex;
u8 autoneg;
u8 num_def_qps;
diff --git a/drivers/net/ehea/ehea_ethtool.c b/drivers/net/ehea/ehea_ethtool.c
index decec8c..29ef7a9 100644
--- a/drivers/net/ehea/ehea_ethtool.c
+++ b/drivers/net/ehea/ehea_ethtool.c
@@ -183,6 +183,9 @@ static char ehea_ethtool_stats_keys[][ETH_GSTRING_LEN] = {
{"PR5 free_swqes"},
{"PR6 free_swqes"},
{"PR7 free_swqes"},
+ {"LRO aggregated"},
+ {"LRO flushed"},
+ {"LRO no_desc"},
};
static void ehea_get_strings(struct net_device *dev, u32 stringset, u8 *data)
@@ -239,6 +242,18 @@ static void ehea_get_ethtool_stats(struct net_device *dev,
for (k = 0; k < 8; k++)
data[i++] = atomic_read(&port->port_res[k].swqe_avail);
+ for (k = 0, tmp = 0; k < EHEA_MAX_PORT_RES; k++)
+ tmp |= port->port_res[k].lro_mgr.stats.aggregated;
+ data[i++] = tmp;
+
+ for (k = 0, tmp = 0; k < EHEA_MAX_PORT_RES; k++)
+ tmp |= port->port_res[k].lro_mgr.stats.flushed;
+ data[i++] = tmp;
+
+ for (k = 0, tmp = 0; k < EHEA_MAX_PORT_RES; k++)
+ tmp |= port->port_res[k].lro_mgr.stats.no_desc;
+ data[i++] = tmp;
+
}
const struct ethtool_ops ehea_ethtool_ops = {
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 9756211..fbaa395 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -52,6 +52,8 @@ static int rq2_entries = EHEA_DEF_ENTRIES_RQ2;
static int rq3_entries = EHEA_DEF_ENTRIES_RQ3;
static int sq_entries = EHEA_DEF_ENTRIES_SQ;
static int use_mcs = 0;
+static int use_lro = 0;
+static int lro_max_aggr = EHEA_LRO_MAX_AGGR;
static int num_tx_qps = EHEA_NUM_TX_QP;
module_param(msg_level, int, 0);
@@ -60,6 +62,8 @@ module_param(rq2_entries, int, 0);
module_param(rq3_entries, int, 0);
module_param(sq_entries, int, 0);
module_param(use_mcs, int, 0);
+module_param(use_lro, int, 0);
+module_param(lro_max_aggr, int, 0);
module_param(num_tx_qps, int, 0);
MODULE_PARM_DESC(num_tx_qps, "Number of TX-QPS");
@@ -77,6 +81,10 @@ MODULE_PARM_DESC(sq_entries, " Number of entries for the
Send Queue "
"[2^x - 1], x = [6..14]. Default = "
__MODULE_STRING(EHEA_DEF_ENTRIES_SQ) ")");
MODULE_PARM_DESC(use_mcs, " 0:NAPI, 1:Multiple receive queues, Default = 1 ");
+MODULE_PARM_DESC(lro_max_aggr, " LRO: Max packets to be aggregated. Default = "
+__MODULE_STRING(EHEA_LRO_MAX_AGGR));
+MODULE_PARM_DESC(use_lro, " Large Receive Offload, 1: enable, 0: disable, "
+ "Default = 0");
static int port_name_cnt = 0;
static LIST_HEAD(adapter_list);
@@ -389,6 +397,60 @@ static int ehea_treat_poll_error(struct ehea_port_res *pr,
int rq,
return 0;
}
+static int get_skb_hdr(struct sk_buff *skb, void **iphdr,
+ void **tcph, u64 *hdr_flags, void *priv)
+{
+ struct ehea_cqe *cqe = priv;
+ unsigned int ip_len;
+ struct iphdr *iph;
+
+/* non tcp/udp packets */
+ if (!cqe->header
[PATCH 1/1] lro: Generic Large Receive Offload for TCP traffic
This patch provides generic Large Receive Offload (LRO) functionality
for IPv4/TCP traffic.
LRO combines received tcp packets to a single larger tcp packet and
passes them then to the network stack in order to increase performance
(throughput). The interface supports two modes: Drivers can either pass
SKBs or fragment lists to the LRO engine.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
include/linux/inet_lro.h | 177 ++
net/ipv4/Kconfig |8 +
net/ipv4/Makefile|1 +
net/ipv4/inet_lro.c | 600 ++
4 files changed, 786 insertions(+), 0 deletions(-)
create mode 100644 include/linux/inet_lro.h
create mode 100644 net/ipv4/inet_lro.c
diff --git a/include/linux/inet_lro.h b/include/linux/inet_lro.h
new file mode 100644
index 000..e1fc1d1
--- /dev/null
+++ b/include/linux/inet_lro.h
@@ -0,0 +1,177 @@
+/*
+ * linux/include/linux/inet_lro.h
+ *
+ * Large Receive Offload (ipv4 / tcp)
+ *
+ * (C) Copyright IBM Corp. 2007
+ *
+ * Authors:
+ * Jan-Bernd Themann <[EMAIL PROTECTED]>
+ * Christoph Raisch <[EMAIL PROTECTED]>
+ *
+ *
+ * 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, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __INET_LRO_H_
+#define __INET_LRO_H_
+
+#include
+#include
+
+/*
+ * LRO statistics
+ */
+
+struct net_lro_stats {
+ unsigned long aggregated;
+ unsigned long flushed;
+ unsigned long no_desc;
+};
+
+/*
+ * LRO descriptor for a tcp session
+ */
+struct net_lro_desc {
+ struct sk_buff *parent;
+ struct sk_buff *last_skb;
+ struct skb_frag_struct *next_frag;
+ struct iphdr *iph;
+ struct tcphdr *tcph;
+ struct vlan_group *vgrp;
+ __wsum data_csum;
+ u32 tcp_rcv_tsecr;
+ u32 tcp_rcv_tsval;
+ u32 tcp_ack;
+ u32 tcp_next_seq;
+ u32 skb_tot_frags_len;
+ u16 ip_tot_len;
+ u16 tcp_saw_tstamp; /* timestamps enabled */
+ u16 tcp_window;
+ u16 vlan_tag;
+ int pkt_aggr_cnt; /* counts aggregated packets */
+ int vlan_packet;
+ int mss;
+ int active;
+};
+
+/*
+ * Large Receive Offload (LRO) Manager
+ *
+ * Fields must be set by driver
+ */
+
+struct net_lro_mgr {
+ struct net_device *dev;
+ struct net_lro_stats stats;
+
+ /* LRO features */
+ unsigned long features;
+#define LRO_F_NAPI1 /* Pass packets to stack via NAPI */
+#define LRO_F_EXTRACT_VLAN_ID 2 /* Set flag if VLAN IDs are extracted
+ from received packets and eth protocol
+ is still ETH_P_8021Q */
+
+ u32 ip_summed; /* Set in non generated SKBs in page mode */
+ u32 ip_summed_aggr; /* Set in aggregated SKBs: CHECKSUM_UNNECESSARY
+* or CHECKSUM_NONE */
+
+ int max_desc; /* Max number of LRO descriptors */
+ int max_aggr; /* Max number of LRO packets to be aggregated */
+
+ struct net_lro_desc *lro_arr; /* Array of LRO descriptors */
+
+ /*
+* Optimized driver functions
+*
+* get_skb_header: returns tcp and ip header for packet in SKB
+*/
+ int (*get_skb_header)(struct sk_buff *skb, void **ip_hdr,
+ void **tcpudp_hdr, u64 *hdr_flags, void *priv);
+
+ /* hdr_flags: */
+#define LRO_IPV4 1 /* ip_hdr is IPv4 header */
+#define LRO_TCP 2 /* tcpudp_hdr is TCP header */
+
+ /*
+* get_frag_header: returns mac, tcp and ip header for packet in SKB
+*
+* @hdr_flags: Indicate what kind of LRO has to be done
+* (IPv4/IPv6/TCP/UDP)
+*/
+ int (*get_frag_header)(struct skb_frag_struct *frag, void **mac_hdr,
+ void **ip_hdr, void **tcpudp_hdr, u64 *hdr_flags,
+ void *priv);
+};
+
+/*
+ * Processes a SKB
+ *
+ * @lro_mgr: LRO manager to use
+ * @skb: SKB to aggregate
+ * @priv: Private data that may be used by driver functions
+ *(for example get_tcp_ip_hdr)
+ */
+
+void lro_receive_skb(struct net_lro_mgr *lro_mgr,
+struct sk_buff *skb,
+void *priv);
+
+/*
+ * Processes a SKB with VLAN HW acceleration support
+ */
+
+void lro_vlan_hwaccel_receive_skb(struct net_lro_mgr
[PATCH 0/1] lro: Generic Large Receive Offload for TCP traffic
Hi, I think this patch could be the final version for now. It has been tested on two platforms (power and x86_64) and works very well. Apart from David Miller and Evgeniy Polaykov, we'd like to thank especially Andrew Gallatin for his great reviews and help to make that happen. After some discussion we decided to post the LRO patch separately from the driver patches. Our final driver patches for LRO will be posted later with some additional fixes for upstream inclusion to the netdev git. However, I'll also post our LRO patch for the driver today as an example of how to use this interface. Thanks a lot, Jan-Bernd [PATCH 1/1] lro: Generic Large Receive Offload for TCP traffic Changes to http://www.spinics.net/lists/netdev/msg37084.html 1) Fixed the LRO_MAX_PG_HLEN bug 2) skb->ip_summed can now be defined by driver for aggregated packets 3) The problem that the "ramp up" for tcp connections between machines with different MTU size (1500 vs 9000) is very slow has been fixed by setting skb->gso_size. 4) Checksum problem for little endian machines has been fixed 5) missing additon of vlan_hdr_len for TCP header determination has been added. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
On Fri, 3 Aug 2007 03:39:23 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Aug 2, 2007, at 3:32 PM, Josh Boyer wrote:
>
> > On Wed, 1 Aug 2007 15:05:42 +1000
> > David Gibson <[EMAIL PROTECTED]> wrote:
> >
> >> On Wed, Aug 01, 2007 at 07:01:17AM +0200, Segher Boessenkool wrote:
> > + { /* 440EPX - without Security/Kasumi */
> > + .pvr_mask = 0xffff,
> > + .pvr_value = 0x28D4,
> > + .cpu_name = "440EPX - no Security/Kasumi",
> > + .cpu_features = CPU_FTRS_44X,
> > + .cpu_user_features = COMMON_USER_BOOKE |
> > PPC_FEATURE_HAS_FPU, /*
> > 440EPX has an FPU */
> > + .icache_bsize = 32,
> > + .dcache_bsize = 32,
> > + },
>
> Since the with/without Security/Kasumi versions have no
> differences in
> their cputable entry other than the PVR, couldn't you just
> remove the
> relevant PVR bit from the mask and use a single entry?
> >>>
> >>> And get rid of the stupid "has an FPU" comment at the same time
> >>> please :-)
> >>
> >> Actually that comment may be worthwhile if expanded a little. I
> >> think
> >> the point is that 440EPx *unlike most other 4xx chips* has an
> >> FPU. So
> >> the point of the comment is not explaining the feature bit, which is
> >> obvious, but as a "no, really, it does".
> >
> > Right. 440EP(x) are the only currently available 44x chips that
> > contain an FPU, so I also think the comment can stay.
>
> I agree w/Segher the comment is redundant. Just make a note of the
> fact that we really have FPU in the commit message.
Fine. I don't really care either way because in the grand scheme of
things, it has no significant impact either way. It's just a comment.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/6] PowerPC 440EPx: Sequoia bootwrapper
On Fri, 3 Aug 2007 08:38:25 +0200 Stefan Roese <[EMAIL PROTECTED]> wrote: > > > +static void ibm440epx_fixup_memsize(void) > > > > And we should move this at the same time. Isn't denali used by another > > CPU as well? > > Right now the Denali DDR(2) core is only used by the 440EPx/440GRx. But other > AMCC PPC's using it will follow soon. So that would be a yes :) Good. Then we should add the function to 4xx.c and call it ibm4xx_denali_fixup_memsize. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
> Depends on interpretation. IIRC currently the same die is used for 440EPx and > 440GRx. I could be wrong here though and it is just a bug in the chip. But > anyway we should support this somehow. Could be that I missed this in the > current 440GRx (Rainier) arch/ppc support too. I have to admit, that no > clever solution comes to my mind right away though. We can always come up with some kind of runtime detection, by turning on MSR:FP, issuing an fp instruction and catching the illegal instruction fault if any :-) Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 22.1-rt8 : BUG: scheduling while atomic: stress/0x00000002/739, CPU#0
On Fri, 2007-08-03 at 17:20 +0530, Pradyumna Sampath wrote: > Hi, > I am running linux-2.6.22.1-rt8 on mpc5200 and on running stress > > #./stress --cpu 8 --io 4 --vm 2 --vm-bytes 2M --timeout 300s > > I get the following stack.But this does not happen with non -rt kernel. > >LR = 0xff51fcc > BUG: scheduling while atomic: stress/0x0002/739, CPU#0 > Call Trace: > [c04fbb80] [c0008650] show_stack+0x50/0x190 (unreliable) > [c04fbbb0] [c0016fc0] __schedule_bug+0x38/0x48 > [c04fbbc0] [c01d4f7c] __schedule+0x3dc/0x450 > [c04fbbf0] [c01d56c8] schedule+0x54/0xf0 > [c04fbc00] [c01d6390] rt_spin_lock_slowlock+0x100/0x224 > [c04fbc60] [c0052198] get_zone_pcp+0x30/0x58 > [c04fbc80] [c0053078] free_hot_cold_page+0x114/0x1fc > [c04fbcb0] [c0056424] put_page+0x50/0x15c > [c04fbcd0] [c0069854] free_page_and_swap_cache+0x44/0x80 > [c04fbce0] [c005d760] unmap_vmas+0x2e0/0x788 > [c04fbd70] [c006292c] exit_mmap+0x74/0x108 > [c04fbda0] [c001adc0] mmput+0x54/0xf0 > [c04fbdc0] [c001ecfc] exit_mm+0xc0/0x124 > [c04fbde0] [c001ffd0] do_exit+0x164/0x8bc > [c04fbe20] [c0020760] do_group_exit+0x38/0x90 > [c04fbe40] [c002ba48] get_signal_to_deliver+0x2ac/0x3c0 > [c04fbe70] [c000739c] do_signal+0x50/0x60c > [c04fbf40] [c000fec0] do_user_signal+0x74/0xc4 > --- Exception: c00 at 0xfeab1dc >LR = 0xff51fcc > > I have also tested the same case on x86 and that does not throw up > anything. Another observation is the fact is that this happens when > --vm is > 1. So I am guessing its a very PowerPC specific problem. > Maybe some part of the vm code for powerpc. This happens for all > powerpc -rt kernels I have used. Weird. unmap_vmas calls to free_page_and_swap_cache() should be happening within a get/put_cpu section, thus with preempt disabled, thus I fail to see how rt_spin_lock would be allowed to preempt. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
On Friday 03 August 2007, Valentine Barshak wrote: > >> Should the 440GRX PVR additions be done in a separate patch? Or is the > >> PVR and cpu features truly the only difference between 440EPx and > >> 440GRx? > > > > I think it makes sense to add the 440GRx with this patchset too. The > > 440GRx is a subset of the 440EPx, missing some stuff like USB, FPU. And > > the AMCC Rainier 440GRx eval board is a subset of the Sequoia eval board. > > So no new board specific sources should be necessary to support the > > Rainier, just a different defconfig file. > > > > Best regards, > > Stefan > > I have a Rainier 440GRx board and the PVR is equal to the 440EPx one > (0x28D0). This has to be handled somehow, since the > PPC_FEATURE_HAS_FPU flag should *not* be set for 440GRx. > I'm really not sure how though. Any ideas are greatly appreciated :) > Is it a h/w bug? Depends on interpretation. IIRC currently the same die is used for 440EPx and 440GRx. I could be wrong here though and it is just a bug in the chip. But anyway we should support this somehow. Could be that I missed this in the current 440GRx (Rainier) arch/ppc support too. I have to admit, that no clever solution comes to my mind right away though. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix special PTE code for secondary hash bucket
On Fri, 2007-08-03 at 18:58 +1000, Paul Mackerras wrote: > The code for mapping special 4k pages on kernels using a 64kB base > page size was missing the code for doing the RPN (real page number) > manipulation when inserting the hardware PTE in the secondary hash > bucket. It needs the same code as has already been added to the > code that inserts the HPTE in the primary hash bucket. This adds it. > > Spotted by Ben Herrenschmidt. > > Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- > diff --git a/arch/powerpc/mm/hash_low_64.S b/arch/powerpc/mm/hash_low_64.S > index 4762ff7..35eabfb 100644 > --- a/arch/powerpc/mm/hash_low_64.S > +++ b/arch/powerpc/mm/hash_low_64.S > @@ -472,10 +472,12 @@ _GLOBAL(htab_call_hpte_insert1) > /* Now try secondary slot */ > > /* real page number in r5, PTE RPN value + index */ > - rldicl r5,r31,64-PTE_RPN_SHIFT,PTE_RPN_SHIFT > + andis. r0,r31,[EMAIL PROTECTED] > + srdir5,r31,PTE_RPN_SHIFT > + bne-3f > sldir5,r5,PAGE_SHIFT-HW_PAGE_SHIFT > add r5,r5,r25 > - sldir5,r5,HW_PAGE_SHIFT > +3: sldir5,r5,HW_PAGE_SHIFT > > /* Calculate secondary group hash */ > andcr0,r27,r28 > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
22.1-rt8 : BUG: scheduling while atomic: stress/0x00000002/739, CPU#0
Hi, I am running linux-2.6.22.1-rt8 on mpc5200 and on running stress #./stress --cpu 8 --io 4 --vm 2 --vm-bytes 2M --timeout 300s I get the following stack.But this does not happen with non -rt kernel. LR = 0xff51fcc BUG: scheduling while atomic: stress/0x0002/739, CPU#0 Call Trace: [c04fbb80] [c0008650] show_stack+0x50/0x190 (unreliable) [c04fbbb0] [c0016fc0] __schedule_bug+0x38/0x48 [c04fbbc0] [c01d4f7c] __schedule+0x3dc/0x450 [c04fbbf0] [c01d56c8] schedule+0x54/0xf0 [c04fbc00] [c01d6390] rt_spin_lock_slowlock+0x100/0x224 [c04fbc60] [c0052198] get_zone_pcp+0x30/0x58 [c04fbc80] [c0053078] free_hot_cold_page+0x114/0x1fc [c04fbcb0] [c0056424] put_page+0x50/0x15c [c04fbcd0] [c0069854] free_page_and_swap_cache+0x44/0x80 [c04fbce0] [c005d760] unmap_vmas+0x2e0/0x788 [c04fbd70] [c006292c] exit_mmap+0x74/0x108 [c04fbda0] [c001adc0] mmput+0x54/0xf0 [c04fbdc0] [c001ecfc] exit_mm+0xc0/0x124 [c04fbde0] [c001ffd0] do_exit+0x164/0x8bc [c04fbe20] [c0020760] do_group_exit+0x38/0x90 [c04fbe40] [c002ba48] get_signal_to_deliver+0x2ac/0x3c0 [c04fbe70] [c000739c] do_signal+0x50/0x60c [c04fbf40] [c000fec0] do_user_signal+0x74/0xc4 --- Exception: c00 at 0xfeab1dc LR = 0xff51fcc I have also tested the same case on x86 and that does not throw up anything. Another observation is the fact is that this happens when --vm is > 1. So I am guessing its a very PowerPC specific problem. Maybe some part of the vm code for powerpc. This happens for all powerpc -rt kernels I have used. Link to stress is : http://weather.ou.edu/~apw/projects/stress/ A friend of mine has already posted this problem to the rt-preempt mailing list. Any pointers suggestions as to where the problem could be is most welcome. Thanks in advance regards /prady -- htp://prady.livejournal.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
Stefan Roese wrote:
> On Thursday 02 August 2007, Josh Boyer wrote:
>> On Mon, 30 Jul 2007 19:16:28 +0400
>>> +0400 +++ linux/arch/powerpc/kernel/cputable.c 2007-07-27
>>> 20:44:26.0 +0400 @@ -1132,6 +1132,42 @@
>>> .dcache_bsize = 32,
>>> .platform = "ppc440",
>>> },
>>> + { /* 440EPX - with Security/Kasumi */
>>> + .pvr_mask = 0xffff,
>>> + .pvr_value = 0x28D0,
>>> + .cpu_name = "440EPX - with Security/Kasumi",
>>> + .cpu_features = CPU_FTRS_44X,
>>> + .cpu_user_features = COMMON_USER_BOOKE |
>>> PPC_FEATURE_HAS_FPU, /*
>>> 440EPX has an FPU */ + .icache_bsize = 32,
>>> + .dcache_bsize = 32,
>>> + },
>>> + { /* 440EPX - without Security/Kasumi */
>>> + .pvr_mask = 0xffff,
>>> + .pvr_value = 0x28D4,
>>> + .cpu_name = "440EPX - no Security/Kasumi",
>>> + .cpu_features = CPU_FTRS_44X,
>>> + .cpu_user_features = COMMON_USER_BOOKE |
>>> PPC_FEATURE_HAS_FPU, /*
>>> 440EPX has an FPU */ + .icache_bsize = 32,
>>> + .dcache_bsize = 32,
>>> + },
>>> + { /* 440GRX - with Security/Kasumi */
>>> + .pvr_mask = 0xffff,
>>> + .pvr_value = 0x28D8,
>>> + .cpu_name = "440GRX - with Security/Kasumi",
>>> + .cpu_features = CPU_FTRS_44X,
>>> + .cpu_user_features = COMMON_USER_BOOKE, /* 440GRX has no
>>> FPU */
>>> + .icache_bsize = 32,
>>> + .dcache_bsize = 32,
>>> + },
>>> + { /* 440GRX - without Security/Kasumi */
>>> + .pvr_mask = 0xffff,
>>> + .pvr_value = 0x28DC,
>>> + .cpu_name = "440GRX - no Security/Kasumi",
>>> + .cpu_features = CPU_FTRS_44X,
>>> + .cpu_user_features = COMMON_USER_BOOKE, /* 440GRX has no
>>> FPU */
>>> + .icache_bsize = 32,
>>> + .dcache_bsize = 32,
>>> + },
>> Should the 440GRX PVR additions be done in a separate patch? Or is the
>> PVR and cpu features truly the only difference between 440EPx and
>> 440GRx?
>
> I think it makes sense to add the 440GRx with this patchset too. The 440GRx
> is
> a subset of the 440EPx, missing some stuff like USB, FPU. And the AMCC
> Rainier 440GRx eval board is a subset of the Sequoia eval board. So no new
> board specific sources should be necessary to support the Rainier, just a
> different defconfig file.
>
> Best regards,
> Stefan
I have a Rainier 440GRx board and the PVR is equal to the 440EPx one
(0x28D0). This has to be handled somehow, since the
PPC_FEATURE_HAS_FPU flag should *not* be set for 440GRx.
I'm really not sure how though. Any ideas are greatly appreciated :)
Is it a h/w bug?
Thanks,
Valentine.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/6] PowerPC 440EPx: Sequoia new EMAC support
Josh Boyer wrote: > On Mon, 30 Jul 2007 19:23:39 +0400 > Valentine Barshak <[EMAIL PROTECTED]> wrote: > >> The patch adds PHY support for the Sequoia board to the new EMAC driver and >> enables NEW_EMAC for 440EPx Kconfig. >> The phy code has been written by Stefan Roese. >> This has been tested with the following version of the EMAC dirver: >> >> http://ozlabs.org/~dgibson/home/emac/powerpc-emac-new-20070516.patch >> >> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> >> Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]> >> --- >> arch/powerpc/platforms/44x/Kconfig |5 +--- >> drivers/net/ibm_newemac/phy.c | 39 >> + >> 2 files changed, 41 insertions(+), 3 deletions(-) >> >> --- linux.orig/arch/powerpc/platforms/44x/Kconfig2007-07-30 >> 15:05:50.0 +0400 >> +++ linux/arch/powerpc/platforms/44x/Kconfig 2007-07-30 17:59:05.0 >> +0400 >> @@ -47,9 +47,8 @@ >> config 440EPX >> bool >> select PPC_FPU >> -# Disabled until the new EMAC Driver is merged. >> -# select IBM_NEW_EMAC_EMAC4 >> -# select IBM_NEW_EMAC_ZMII >> +select IBM_NEW_EMAC_EMAC4 >> +select IBM_NEW_EMAC_ZMII > > Probably don't want this bit yet. The EMAC driver isn't really merged > yet. > > josh Actually, this one is intended for use as a separate Sequoia emac support patch until new emac is merged. May be I should submit it separately, not with the whole Sequoia bundle. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
Josh Boyer wrote:
> On Mon, 30 Jul 2007 19:16:28 +0400
> Valentine Barshak <[EMAIL PROTECTED]> wrote:
>
>> diff -ruN linux.orig/arch/powerpc/kernel/cputable.c
>> linux/arch/powerpc/kernel/cputable.c
>> --- linux.orig/arch/powerpc/kernel/cputable.c2007-07-27
>> 20:37:10.0 +0400
>> +++ linux/arch/powerpc/kernel/cputable.c 2007-07-27 20:44:26.0
>> +0400
>> @@ -1132,6 +1132,42 @@
>> .dcache_bsize = 32,
>> .platform = "ppc440",
>> },
>> +{ /* 440EPX - with Security/Kasumi */
>> +.pvr_mask = 0xffff,
>> +.pvr_value = 0x28D0,
>> +.cpu_name = "440EPX - with Security/Kasumi",
>> +.cpu_features = CPU_FTRS_44X,
>> +.cpu_user_features = COMMON_USER_BOOKE |
>> PPC_FEATURE_HAS_FPU, /* 440EPX has an FPU */
>> +.icache_bsize = 32,
>> +.dcache_bsize = 32,
>> +},
>> +{ /* 440EPX - without Security/Kasumi */
>> +.pvr_mask = 0xffff,
>> +.pvr_value = 0x28D4,
>> +.cpu_name = "440EPX - no Security/Kasumi",
>> +.cpu_features = CPU_FTRS_44X,
>> +.cpu_user_features = COMMON_USER_BOOKE |
>> PPC_FEATURE_HAS_FPU, /* 440EPX has an FPU */
>> +.icache_bsize = 32,
>> +.dcache_bsize = 32,
>> +},
>> +{ /* 440GRX - with Security/Kasumi */
>> +.pvr_mask = 0xffff,
>> +.pvr_value = 0x28D8,
>> +.cpu_name = "440GRX - with Security/Kasumi",
>> +.cpu_features = CPU_FTRS_44X,
>> +.cpu_user_features = COMMON_USER_BOOKE, /* 440GRX has no
>> FPU */
>> +.icache_bsize = 32,
>> +.dcache_bsize = 32,
>> +},
>> +{ /* 440GRX - without Security/Kasumi */
>> +.pvr_mask = 0xffff,
>> +.pvr_value = 0x28DC,
>> +.cpu_name = "440GRX - no Security/Kasumi",
>> +.cpu_features = CPU_FTRS_44X,
>> +.cpu_user_features = COMMON_USER_BOOKE, /* 440GRX has no
>> FPU */
>> +.icache_bsize = 32,
>> +.dcache_bsize = 32,
>> +},
>
> Should the 440GRX PVR additions be done in a separate patch? Or is the
> PVR and cpu features truly the only difference between 440EPx and
> 440GRx?
440GRx Doesn't have USB (host/device) controllers and and FPU.
Actually, I have a 440GRx board with the same PVR valus as 440EPx has.
HW bug may be?
I think I'll remove 440GRx for now.
>
>> diff -ruN linux.orig/arch/powerpc/platforms/44x/sequoia.c
>> linux/arch/powerpc/platforms/44x/sequoia.c
>> --- linux.orig/arch/powerpc/platforms/44x/sequoia.c 1970-01-01
>> 03:00:00.0 +0300
>> +++ linux/arch/powerpc/platforms/44x/sequoia.c 2007-07-27
>> 20:44:26.0 +0400
>> @@ -0,0 +1,66 @@
>> +/*
>> + * Sequoia board specific routines
>> + *
>> + * Wade Farnsworth <[EMAIL PROTECTED]>
>> + * Copyright 2004-2007 MontaVista Software Inc.
>> + *
>> + * Rewritten and ported to the merged powerpc tree:
>> + * Josh Boyer <[EMAIL PROTECTED]>
>> + * Copyright 2007 IBM Corporation
>
> I didn't really do this. Might want to give yourself credit instead :).
>
> josh
I'll change it to "base on Bamboo code by Josh" :)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [ PATCH ] PowerPC cascade UIC IRQ handler fix.
Josh Boyer wrote: > On Thu, 2 Aug 2007 13:48:48 +1000 > David Gibson <[EMAIL PROTECTED]> wrote: > >> On Mon, Jul 30, 2007 at 08:35:17PM +0400, Valentine Barshak wrote: >>> PPC44x cascade UIC irq handler fix. >>> >>> According to PPC44x UM, if an interrupt is configured as >>> level-sensitive, and a clear is attempted on the UIC_SR, the UIC_SR >>> field is not cleared if the incoming interrupt signal is at the >>> asserted polarity. This causes us to enter a cascade handler twice, >>> since we first ack parent UIC interrupt and ack child UIC one after >>> that. The patch checks child UIC msr value and returns IRQ_HANDLED >>> if there're no pending interrupts. Otherwise we get a kernel panic >>> with a "Fatal exception in interrupt" (illegal vector). >>> The patch also fixes status flags. >>> >>> Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]> >> Hrm... This doesn't seem like the right fix to me. Instead, I think >> the cascaded IRQ handler should ack the interrupt on the child first. >> I'm a little surprised it doesn't at the moment. > > Agreed. Anyone going to hack up a patch for that? > > josh Anyways, I don't see why kernel should panic if we get a spurious interrupt. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull powerpc.git merge branch
Linus, Please do git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get another batch of bug-fixes for powerpc. Thanks, Paul. arch/powerpc/kernel/entry_64.S|3 +++ arch/powerpc/kernel/pci_32.c |5 - arch/powerpc/kernel/smp.c |9 +++-- arch/powerpc/mm/hash_low_64.S |6 -- arch/powerpc/mm/hash_utils_64.c |2 +- arch/powerpc/mm/numa.c|4 ++-- arch/powerpc/mm/slb.c | 28 ++-- arch/powerpc/platforms/cell/spufs/sched.c |3 ++- arch/powerpc/platforms/powermac/feature.c |6 -- arch/powerpc/platforms/ps3/setup.c|2 +- include/asm-powerpc/mmu-hash64.h |1 + include/asm-powerpc/pgtable-64k.h |8 +++- 12 files changed, 46 insertions(+), 31 deletions(-) Andre Detsch (1): [POWERPC] spufs: Fix affinity after introduction of node_allowed() calls Kevin Corry (1): [POWERPC] Fix num_cpus calculation in smp_call_function_map() Michael Ellerman (1): [POWERPC] Fix parse_drconf_memory() for 64-bit start addresses Michael Neuling (1): [POWERPC] Fixes for the SLB shadow buffer code Paul Mackerras (2): [POWERPC] Expand RPN field to 34 bits when using 64k pages [POWERPC] Fix special PTE code for secondary hash bucket Segher Boessenkool (2): [POWERPC] Fix a compile warning in pci_32.c [POWERPC] Fix a compile warning in powermac/feature.c Stephen Rothwell (1): [POWERPC] ps3: Fix section mismatch in ps3/setup.c ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.23-rc1-mm2
On Aug 2, 2007, at 5:14 AM, Mariusz Kozlowski wrote: >>> Second issue as reported earilier allmodconfig fails to build on >>> imac g3. >> >> Do you really mean g3? If so it's a 32-bit kernel and it >> shouldn't be >> building lparmap.s. Or do you mean G5? > > Yes it is iMac G3. More or less sth like this: > http://upload.wikimedia.org/wikipedia/commons/c/c0/IMac_Bondi_Blue.jpg > > processor : 0 > cpu : 740/750 > temperature : 47-49 C (uncalibrated) > clock : 400MHz > revision: 2.2 (pvr 0008 0202) > bogomips: 796.67 > machine : PowerMac2,1 > motherboard : PowerMac2,1 MacRISC2 MacRISC Power Macintosh > detected as : 66 (iMac FireWire) > pmac flags : 0005 > L2 cache: 512K unified > memory : 256MB > pmac-generation : NewWorld > >>> CC arch/powerpc/kernel/lparmap.s >>> AS arch/powerpc/kernel/head_64.o >>> lparmap.c: Assembler messages: >>> lparmap.c:84: Error: file number 1 already allocated >>> make[1]: *** [arch/powerpc/kernel/head_64.o] Blad 1 >>> make: *** [arch/powerpc/kernel] Blad 2 >> >> Weird. Could you do make V=1 and send me the output? > > Ok. Here it goes. The last screen. If you need all / more feel free > to mail > me. Config is attached - please note that this is default > allmodconfig. > > > > gcc -m64 -Wp,-MD,arch/powerpc/kernel/.machine_kexec.o.d -nostdinc - > isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ - > Iinclude -include > include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno- > trigraphs -fno-strict-aliasing -fno-common -Werror-implicit- > function-declaration -Os -msoft-float -pipe -mminimal-toc - > mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at- > a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno- > stack-protector -Wdeclaration-after-statement -Wno-pointer-sign - > mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR > (machine_kexec)" -D"KBUILD_MODNAME=KBUILD_STR(machine_kexec)" -c -o > arch/powerpc/kernel/.tmp_machine_kexec.o arch/powerpc/kernel/ > machine_kexec.c > > gcc -m64 -Wp,-MD,arch/powerpc/kernel/.crash.o.d -nostdinc - > isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ - > Iinclude -include > include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno- > trigraphs -fno-strict-aliasing -fno-common -Werror-implicit- > function-declaration -Os -msoft-float -pipe -mminimal-toc - > mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at- > a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno- > stack-protector -Wdeclaration-after-statement -Wno-pointer-sign - > mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR > (crash)" -D"KBUILD_MODNAME=KBUILD_STR(crash)" -c -o > arch/powerpc/kernel/.tmp_crash.o arch/powerpc/kernel/crash.c > > gcc -m64 -Wp,-MD,arch/powerpc/kernel/.machine_kexec_64.o.d - > nostdinc -isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include - > D__KERNEL__ -Iinclude -include > include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno- > trigraphs -fno-strict-aliasing -fno-common -Werror-implicit- > function-declaration -Os -msoft-float -pipe -mminimal-toc - > mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at- > a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno- > stack-protector -Wdeclaration-after-statement -Wno-pointer-sign - > mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR > (machine_kexec_64)" -D"KBUILD_MODNAME=KBUILD_STR > (machine_kexec_64)" -c -o > arch/powerpc/kernel/.tmp_machine_kexec_64.o > arch/powerpc/kernel/machine_kexec_64.c > > gcc -m64 -Wp,-MD,arch/powerpc/kernel/.audit.o.d -nostdinc - > isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ - > Iinclude -include > include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno- > trigraphs -fno-strict-aliasing -fno-common -Werror-implicit- > function-declaration -Os -msoft-float -pipe -mminimal-toc - > mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at- > a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno- > stack-protector -Wdeclaration-after-statement -Wno-pointer-sign - > mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR > (audit)" -D"KBUILD_MODNAME=KBUILD_STR(audit)" -c -o > arch/powerpc/kernel/.tmp_audit.o arch/powerpc/kernel/audit.c > > gcc -m64 -Wp,-MD,arch/powerpc/kernel/.swsusp_64.o.d -nostdinc - > isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ - > Iinclude -include > include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno- > trigraphs -fno-strict-aliasing -fno-common -Werror-implicit- > function-declaration -Os -msoft-float -pipe -mminimal-toc - > mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at- > a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno- > stack-protector -Wdeclaration-after-statement
Re: [spi-devel-general] [PATCH] [SPI][POWERPC] spi_mpc83xx: in "QE mode" spiclk is sysclk/2
On Aug 2, 2007, at 4:47 PM, David Brownell wrote: > On Thursday 02 August 2007, Anton Vorontsov wrote: >> Probably someday mpc83xx_spi->sysclk should be renamed to >> mpc83xx_spi->spiclk to be less confusing. > > Why not "today", with this patch? That would fix some of > the root cause of this bug... I'm fine with this as well. I just called it sysclk to start with since when I wrote the driver it was just for the MPC834x. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix FSL BookE machine check reporting
On Aug 3, 2007, at 4:18 AM, Paul Mackerras wrote: > Becky Bruce writes: > >> Reserved MCSR bits on FSL BookE parts may have spurious values >> when mcheck occurs. Mask these off when printing the MCSR to >> avoid confusion. Also, get rid of the MCSR_GL_CI bit defined >> for e500 - this bit doesn't actually have any meaning. > > Is this needed for 2.6.23? It would be nice. I'll queue it up with some other fixes for 2.6.23. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix FSL BookE machine check reporting
Becky Bruce writes: > Reserved MCSR bits on FSL BookE parts may have spurious values > when mcheck occurs. Mask these off when printing the MCSR to > avoid confusion. Also, get rid of the MCSR_GL_CI bit defined > for e500 - this bit doesn't actually have any meaning. Is this needed for 2.6.23? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Generic clk.h wrappers? [Was: Re: [PATCH 1/3] powerpc clk.h interface for platforms]
On Thu, Aug 02, 2007 at 04:32:13PM -0700, David Brownell wrote: > On Wednesday 01 August 2007, Christoph Hellwig wrote: > > On Wed, Aug 01, 2007 at 09:28:07AM +0200, Domen Puncer wrote: > > > > It doesn't make any assumption on struct clk, it's just a > > > > wrapper around functions from clk.h. > > > > Point of this patch was to abstract exported functions, since > > > > arch/powerpc/ can support multiple platfroms in one binary. > > > > > > So... the thread just ended without any consensus, ACK or whatever. > > > > > > Choices I see: > > > - have EXPORT_SYMBOL for clk.h functions in ie. lib/clock.c and have > > > every implemenation fill some global struct. > > > - leave this patch as it is, abstraction only for arch/powerpc/. > > That seems the best solution for now, I agree. I've not been avoiding replying further to this thread in spite, it's just that I've not had any time what so ever to look at this further. It's very low priority for me at the moment, so it's getting zero time, and will continue to be in that state for at least the next month and a bit. Sorry. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Expand RPN field to 34 bits when using 64k pages
The real page number field in our PTEs when configured for 64kB pages is currently 32 bits, which turns out to be not quite enough for the resources that the eHCA driver wants to map. This expands the RPN field to include 2 adjacent, previously-unused bits. Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- diff --git a/include/asm-powerpc/pgtable-64k.h b/include/asm-powerpc/pgtable-64k.h index 31cbd3d..33ae901 100644 --- a/include/asm-powerpc/pgtable-64k.h +++ b/include/asm-powerpc/pgtable-64k.h @@ -49,12 +49,10 @@ /* Shift to put page number into pte. * - * That gives us a max RPN of 32 bits, which means a max of 48 bits - * of addressable physical space. - * We could get 3 more bits here by setting PTE_RPN_SHIFT to 29 but - * 32 makes PTEs more readable for debugging for now :) + * That gives us a max RPN of 34 bits, which means a max of 50 bits + * of addressable physical space, or 46 bits for the special 4k PFNs. */ -#define PTE_RPN_SHIFT (32) +#define PTE_RPN_SHIFT (30) #define PTE_RPN_MAX(1UL << (64 - PTE_RPN_SHIFT)) #define PTE_RPN_MASK (~((1UL
[PATCH] Fix special PTE code for secondary hash bucket
The code for mapping special 4k pages on kernels using a 64kB base page size was missing the code for doing the RPN (real page number) manipulation when inserting the hardware PTE in the secondary hash bucket. It needs the same code as has already been added to the code that inserts the HPTE in the primary hash bucket. This adds it. Spotted by Ben Herrenschmidt. Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> --- diff --git a/arch/powerpc/mm/hash_low_64.S b/arch/powerpc/mm/hash_low_64.S index 4762ff7..35eabfb 100644 --- a/arch/powerpc/mm/hash_low_64.S +++ b/arch/powerpc/mm/hash_low_64.S @@ -472,10 +472,12 @@ _GLOBAL(htab_call_hpte_insert1) /* Now try secondary slot */ /* real page number in r5, PTE RPN value + index */ - rldicl r5,r31,64-PTE_RPN_SHIFT,PTE_RPN_SHIFT + andis. r0,r31,[EMAIL PROTECTED] + srdir5,r31,PTE_RPN_SHIFT + bne-3f sldir5,r5,PAGE_SHIFT-HW_PAGE_SHIFT add r5,r5,r25 - sldir5,r5,HW_PAGE_SHIFT +3: sldir5,r5,HW_PAGE_SHIFT /* Calculate secondary group hash */ andcr0,r27,r28 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
On Aug 2, 2007, at 3:32 PM, Josh Boyer wrote:
> On Wed, 1 Aug 2007 15:05:42 +1000
> David Gibson <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Aug 01, 2007 at 07:01:17AM +0200, Segher Boessenkool wrote:
> + { /* 440EPX - without Security/Kasumi */
> + .pvr_mask = 0xffff,
> + .pvr_value = 0x28D4,
> + .cpu_name = "440EPX - no Security/Kasumi",
> + .cpu_features = CPU_FTRS_44X,
> + .cpu_user_features = COMMON_USER_BOOKE |
> PPC_FEATURE_HAS_FPU, /*
> 440EPX has an FPU */
> + .icache_bsize = 32,
> + .dcache_bsize = 32,
> + },
Since the with/without Security/Kasumi versions have no
differences in
their cputable entry other than the PVR, couldn't you just
remove the
relevant PVR bit from the mask and use a single entry?
>>>
>>> And get rid of the stupid "has an FPU" comment at the same time
>>> please :-)
>>
>> Actually that comment may be worthwhile if expanded a little. I
>> think
>> the point is that 440EPx *unlike most other 4xx chips* has an
>> FPU. So
>> the point of the comment is not explaining the feature bit, which is
>> obvious, but as a "no, really, it does".
>
> Right. 440EP(x) are the only currently available 44x chips that
> contain an FPU, so I also think the comment can stay.
I agree w/Segher the comment is redundant. Just make a note of the
fact that we really have FPU in the commit message.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ehca: map 4k firmware context of cq, qp to user space
From: Hoang-Nam Nguyen
Date: Fri, 3 Aug 2007 09:44:56 +0200
Subject: [PATCH] ehca: map 4k firmware context of cq, qp to user space
This patch utilizes remap_4k_pfn() as introduced by Paul M.,
for details see http://patchwork.ozlabs.org/linuxppc/patch?id=10281,
to map ehca cq, qp firmware context (4k) to user space if kernel page
size is 64k. For reason, why this is required, see also Paul's patch.
In addition to that the kernel page offset of firmware context needs
to be set in cq and qp response block so that user space can assemble
the proper virtual address to use.
An appropriate patch for libehca will follow for ofed-1.3.
Signed-off-by: Hoang-Nam Nguyen <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_classes.h |4 +++-
drivers/infiniband/hw/ehca/ehca_cq.c |2 ++
drivers/infiniband/hw/ehca/ehca_qp.c |2 ++
drivers/infiniband/hw/ehca/ehca_uverbs.c |6 +++---
4 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h
b/drivers/infiniband/hw/ehca/ehca_classes.h
index b5e9603..206d4eb 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -337,6 +337,8 @@ struct ehca_create_cq_resp {
u32 cq_number;
u32 token;
struct ipzu_queue_resp ipz_queue;
+ u32 fw_handle_ofs;
+ u32 dummy;
};
struct ehca_create_qp_resp {
@@ -347,7 +349,7 @@ struct ehca_create_qp_resp {
u32 qkey;
/* qp_num assigned by ehca: sqp0/1 may have got different numbers */
u32 real_qp_num;
- u32 dummy; /* padding for 8 byte alignment */
+ u32 fw_handle_ofs;
struct ipzu_queue_resp ipz_squeue;
struct ipzu_queue_resp ipz_rqueue;
};
diff --git a/drivers/infiniband/hw/ehca/ehca_cq.c
b/drivers/infiniband/hw/ehca/ehca_cq.c
index 81aff36..ed5d67f 100644
--- a/drivers/infiniband/hw/ehca/ehca_cq.c
+++ b/drivers/infiniband/hw/ehca/ehca_cq.c
@@ -276,6 +276,8 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int
cqe, int comp_vector,
resp.ipz_queue.queue_length = ipz_queue->queue_length;
resp.ipz_queue.pagesize = ipz_queue->pagesize;
resp.ipz_queue.toggle_state = ipz_queue->toggle_state;
+ resp.fw_handle_ofs = (u32)
+ (my_cq->galpas.user.fw_handle & (PAGE_SIZE - 1));
if (ib_copy_to_udata(udata, &resp, sizeof(resp))) {
ehca_err(device, "Copy to udata failed.");
goto create_cq_exit4;
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c
b/drivers/infiniband/hw/ehca/ehca_qp.c
index b178cba..66f632c 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -745,6 +745,8 @@ static struct ehca_qp *internal_create_qp(
queue2resp(&resp.ipz_squeue, &my_qp->ipz_squeue);
if (HAS_RQ(my_qp))
queue2resp(&resp.ipz_rqueue, &my_qp->ipz_rqueue);
+ resp.fw_handle_ofs = (u32)
+ (my_qp->galpas.user.fw_handle & (PAGE_SIZE - 1));
if (ib_copy_to_udata(udata, &resp, sizeof resp)) {
ehca_err(pd->device, "Copy to udata failed");
diff --git a/drivers/infiniband/hw/ehca/ehca_uverbs.c
b/drivers/infiniband/hw/ehca/ehca_uverbs.c
index 4bc687f..be062f1 100644
--- a/drivers/infiniband/hw/ehca/ehca_uverbs.c
+++ b/drivers/infiniband/hw/ehca/ehca_uverbs.c
@@ -109,7 +109,7 @@ static int ehca_mmap_fw(struct vm_area_struct *vma, struct
h_galpas *galpas,
u64 vsize, physical;
vsize = vma->vm_end - vma->vm_start;
- if (vsize != EHCA_PAGESIZE) {
+ if (vsize >= EHCA_PAGESIZE) {
ehca_gen_err("invalid vsize=%lx", vma->vm_end - vma->vm_start);
return -EINVAL;
}
@@ -118,8 +118,8 @@ static int ehca_mmap_fw(struct vm_area_struct *vma, struct
h_galpas *galpas,
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
ehca_gen_dbg("vsize=%lx physical=%lx", vsize, physical);
/* VM_IO | VM_RESERVED are set by remap_pfn_range() */
- ret = remap_pfn_range(vma, vma->vm_start, physical >> PAGE_SHIFT,
- vsize, vma->vm_page_prot);
+ ret = remap_4k_pfn(vma, vma->vm_start, physical >> EHCA_PAGESHIFT,
+ vma->vm_page_prot);
if (unlikely(ret)) {
ehca_gen_err("remap_pfn_range() failed ret=%x", ret);
return -ENOMEM;
--
1.5.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
