* Help Needed: PHY Driver
From: s.maiti @ 2006-05-26 11:10 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 957 bytes --]
Hi all,
In our custom board (MPC8260) there is a child card, which is having the
PHY chip DM256, and is being memory mapped with the processor via CS 7 and
they are connected via local bus.
Now my question is what nessary changes I have to make in linux tree for
thi purpose.
Thanks in advance.
Souvik Maiti
Tata Consultancy Services Limited
Mailto: s.maiti@tcs.com
Website: http://www.tcs.com
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
[-- Attachment #2: Type: text/html, Size: 1199 bytes --]
^ permalink raw reply
* Re: [PATCH] force 64bit mode in system_reset_fwnmi for broken POWER4 firmware
From: Paul Mackerras @ 2006-05-26 11:30 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060523130717.GA22364@suse.de>
Olaf Hering writes:
> According to this change for EXCEPTION_PROLOG_COMMON, I get still into
> decremeter_common, but its not fatal anymore because the cpu is now in
> 64bit mode and the stack is forced to PACAKSAVE(r13).
>
> subi r1,r1,INT_FRAME_SIZE; /* alloc frame on kernel stack */ \
> beq- 1f; \
> ld r1,PACAKSAVE(r13); /* kernel stack to use */ \
> -1: cmpdi cr1,r1,0; /* check if r1 is in userspace */ \
> +1: \
> + cmpdi cr1,r29,0x42; \
Ummm, what's r29 supposed to have in it here?
> + bne cr1,2f; \
> + li r29,2f@l; \
And why are we setting it?
Does it look like the SRR0 and SRR1 values are correct when we get
this problem occurring? Is it just the MSR that is bogus?
Paul.
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Mark Lord @ 2006-05-26 11:41 UTC (permalink / raw)
To: Sven Luther
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <20060526083931.GA23938@powerlinux.fr>
Sven Luther wrote:
> I'm trying to use a Marvell 88SX5081 based card here in my pegasos machine,
> and i never got it working with the libata driver, even with the patches Zang
> provided (and 2.6.16 though, maybe i should update to a newer version). The
> marvell provided driver worked though at some time.
>
> Would it be possible to have access to your work, in order to not duplicate
> effort or something ?
All of the relevant bits of "my work" are now in Jeff's upstream libata tree,
from the recently posted sata_mv patches.
After struggling with bad SDRAM earlier this week, I now have Ubuntu installed
and running reliably on my G3 box here. Next step is to upgrade the kernel
to something modern, and add in the latest sata_mv.
After that, I'll try my own 6081 Marvell card in it, and hopefully see the
same failures as you.. hopefully!
Cheers
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Sven Luther @ 2006-05-26 11:42 UTC (permalink / raw)
To: Mark Lord
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <4476E964.90509@rtr.ca>
On Fri, May 26, 2006 at 07:41:24AM -0400, Mark Lord wrote:
> Sven Luther wrote:
> >I'm trying to use a Marvell 88SX5081 based card here in my pegasos machine,
> >and i never got it working with the libata driver, even with the patches
> >Zang
> >provided (and 2.6.16 though, maybe i should update to a newer version). The
> >marvell provided driver worked though at some time.
> >
> >Would it be possible to have access to your work, in order to not duplicate
> >effort or something ?
>
> All of the relevant bits of "my work" are now in Jeff's upstream libata
> tree,
> from the recently posted sata_mv patches.
Ok. can i use this tree with a 2.6.16 base ?
> After struggling with bad SDRAM earlier this week, I now have Ubuntu
> installed
> and running reliably on my G3 box here. Next step is to upgrade the kernel
> to something modern, and add in the latest sata_mv.
Ok.
> After that, I'll try my own 6081 Marvell card in it, and hopefully see the
> same failures as you.. hopefully!
I tried getting a 6081 based low profile card, but they don't seem to sell in
europe.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH] force 64bit mode in system_reset_fwnmi for broken POWER4 firmware
From: Olaf Hering @ 2006-05-26 12:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17526.59069.781220.922878@cargo.ozlabs.ibm.com>
On Fri, May 26, Paul Mackeras wrote:
> Olaf Hering writes:
>
> > According to this change for EXCEPTION_PROLOG_COMMON, I get still into
> > decremeter_common, but its not fatal anymore because the cpu is now in
> > 64bit mode and the stack is forced to PACAKSAVE(r13).
> >
> > subi r1,r1,INT_FRAME_SIZE; /* alloc frame on kernel stack */ \
> > beq- 1f; \
> > ld r1,PACAKSAVE(r13); /* kernel stack to use */ \
> > -1: cmpdi cr1,r1,0; /* check if r1 is in userspace */ \
> > +1: \
> > + cmpdi cr1,r29,0x42; \
>
> Ummm, what's r29 supposed to have in it here?
0x42, from the spinning hello32 app. I filled all regs from r14 to r31
with a fixed value, and used these regs for debugging in the reset
handler.
> > + bne cr1,2f; \
> > + li r29,2f@l; \
>
> And why are we setting it?
Just a debug thing to find out how I got into bad_stack. I expected that
system_reset_common calls bad_stack, but it was decrementer_common. No
idea how that happend, MSR_EE is off, the timer interrupt has the lowest
priority, so it should not trigger.
> Does it look like the SRR0 and SRR1 values are correct when we get
> this problem occurring? Is it just the MSR that is bogus?
The MSR indicates 32bit mode, it is 0x1002 on entry and 0x1032 before
rfdi. I havent dumped the SRR1 content, SRR0 points to the hello32 'b .'
instruction.
It seems the JS20 and POWER4 firmware calls fwnmi on all cpus, while
JS21 (and probably POWER5) does it only on one cpu. The other cpus will
be stopped with an IPI, trap 501.
According to some firmware guys, the OS is supposed to force 64bit mode
on reset.
^ permalink raw reply
* Re: [PATCH] force 64bit mode in system_reset_fwnmi for broken POWER4 firmware
From: Paul Mackerras @ 2006-05-26 12:40 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060526123321.GA21866@suse.de>
Olaf Hering writes:
> According to some firmware guys, the OS is supposed to force 64bit mode
> on reset.
Who? I'll get a platform architect to drop on them from a great
height. :)
Paul.
^ permalink raw reply
* Re: [PATCH] force 64bit mode in system_reset_fwnmi for broken POWER4 firmware
From: Olaf Hering @ 2006-05-26 12:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17526.63315.759402.679928@cargo.ozlabs.ibm.com>
On Fri, May 26, Paul Mackeras wrote:
> Olaf Hering writes:
>
> > According to some firmware guys, the OS is supposed to force 64bit mode
> > on reset.
>
> Who? I'll get a platform architect to drop on them from a great
> height. :)
LTC22581 for the full story.
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Mark Lord @ 2006-05-26 13:19 UTC (permalink / raw)
To: Sven Luther
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <20060526114245.GA32330@powerlinux.fr>
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
Sven Luther wrote:
> On Fri, May 26, 2006 at 07:41:24AM -0400, Mark Lord wrote:
>> All of the relevant bits of "my work" are now in Jeff's upstream libata
>> tree,
>> from the recently posted sata_mv patches.
>
> Ok. can i use this tree with a 2.6.16 base ?
Not as-is. Here (attached) is a patch for 2.6.16.17+ that updates
the sata_mv driver to the latest source. Completely untested,
but it does compile.
I will hopefully test it later today, but in the meanwhile, have a go at it.
Cheers
[-- Attachment #2: sata_mv-2.6.16_backport.patch --]
[-- Type: text/x-patch, Size: 22667 bytes --]
--- linux-2.6.16.17/drivers/scsi/sata_mv.c 2006-04-14 23:14:22.000000000 -0400
+++ linux/drivers/scsi/sata_mv.c 2006-05-26 09:15:22.000000000 -0400
@@ -37,7 +37,7 @@
#include <asm/io.h>
#define DRV_NAME "sata_mv"
-#define DRV_VERSION "0.5"
+#define DRV_VERSION "0.7-backport"
enum {
/* BAR's are enumerated in terms of pci_resource_start() terms */
@@ -50,6 +50,12 @@
MV_PCI_REG_BASE = 0,
MV_IRQ_COAL_REG_BASE = 0x18000, /* 6xxx part only */
+ MV_IRQ_COAL_CAUSE = (MV_IRQ_COAL_REG_BASE + 0x08),
+ MV_IRQ_COAL_CAUSE_LO = (MV_IRQ_COAL_REG_BASE + 0x88),
+ MV_IRQ_COAL_CAUSE_HI = (MV_IRQ_COAL_REG_BASE + 0x8c),
+ MV_IRQ_COAL_THRESHOLD = (MV_IRQ_COAL_REG_BASE + 0xcc),
+ MV_IRQ_COAL_TIME_THRESHOLD = (MV_IRQ_COAL_REG_BASE + 0xd0),
+
MV_SATAHC0_REG_BASE = 0x20000,
MV_FLASH_CTL = 0x1046c,
MV_GPIO_PORT_CTL = 0x104f0,
@@ -228,7 +234,9 @@
MV_HP_ERRATA_50XXB2 = (1 << 2),
MV_HP_ERRATA_60X1B2 = (1 << 3),
MV_HP_ERRATA_60X1C0 = (1 << 4),
- MV_HP_50XX = (1 << 5),
+ MV_HP_ERRATA_XX42A0 = (1 << 5),
+ MV_HP_50XX = (1 << 6),
+ MV_HP_GEN_IIE = (1 << 7),
/* Port private flags (pp_flags) */
MV_PP_FLAG_EDMA_EN = (1 << 0),
@@ -237,6 +245,9 @@
#define IS_50XX(hpriv) ((hpriv)->hp_flags & MV_HP_50XX)
#define IS_60XX(hpriv) (((hpriv)->hp_flags & MV_HP_50XX) == 0)
+#define IS_GEN_I(hpriv) IS_50XX(hpriv)
+#define IS_GEN_II(hpriv) IS_60XX(hpriv)
+#define IS_GEN_IIE(hpriv) ((hpriv)->hp_flags & MV_HP_GEN_IIE)
enum {
/* Our DMA boundary is determined by an ePRD being unable to handle
@@ -255,29 +266,39 @@
chip_5080,
chip_604x,
chip_608x,
+ chip_6042,
+ chip_7042,
};
/* Command ReQuest Block: 32B */
struct mv_crqb {
- u32 sg_addr;
- u32 sg_addr_hi;
- u16 ctrl_flags;
- u16 ata_cmd[11];
+ __le32 sg_addr;
+ __le32 sg_addr_hi;
+ __le16 ctrl_flags;
+ __le16 ata_cmd[11];
+};
+
+struct mv_crqb_iie {
+ __le32 addr;
+ __le32 addr_hi;
+ __le32 flags;
+ __le32 len;
+ __le32 ata_cmd[4];
};
/* Command ResPonse Block: 8B */
struct mv_crpb {
- u16 id;
- u16 flags;
- u32 tmstmp;
+ __le16 id;
+ __le16 flags;
+ __le32 tmstmp;
};
/* EDMA Physical Region Descriptor (ePRD); A.K.A. SG */
struct mv_sg {
- u32 addr;
- u32 flags_size;
- u32 addr_hi;
- u32 reserved;
+ __le32 addr;
+ __le32 flags_size;
+ __le32 addr_hi;
+ __le32 reserved;
};
struct mv_port_priv {
@@ -287,9 +308,6 @@
dma_addr_t crpb_dma;
struct mv_sg *sg_tbl;
dma_addr_t sg_tbl_dma;
-
- unsigned req_producer; /* cp of req_in_ptr */
- unsigned rsp_consumer; /* cp of rsp_out_ptr */
u32 pp_flags;
};
@@ -328,6 +346,7 @@
static int mv_port_start(struct ata_port *ap);
static void mv_port_stop(struct ata_port *ap);
static void mv_qc_prep(struct ata_queued_cmd *qc);
+static void mv_qc_prep_iie(struct ata_queued_cmd *qc);
static int mv_qc_issue(struct ata_queued_cmd *qc);
static irqreturn_t mv_interrupt(int irq, void *dev_instance,
struct pt_regs *regs);
@@ -430,6 +449,33 @@
.host_stop = mv_host_stop,
};
+static const struct ata_port_operations mv_iie_ops = {
+ .port_disable = ata_port_disable,
+
+ .tf_load = ata_tf_load,
+ .tf_read = ata_tf_read,
+ .check_status = ata_check_status,
+ .exec_command = ata_exec_command,
+ .dev_select = ata_std_dev_select,
+
+ .phy_reset = mv_phy_reset,
+
+ .qc_prep = mv_qc_prep_iie,
+ .qc_issue = mv_qc_issue,
+
+ .eng_timeout = mv_eng_timeout,
+
+ .irq_handler = mv_interrupt,
+ .irq_clear = mv_irq_clear,
+
+ .scr_read = mv_scr_read,
+ .scr_write = mv_scr_write,
+
+ .port_start = mv_port_start,
+ .port_stop = mv_port_stop,
+ .host_stop = mv_host_stop,
+};
+
static const struct ata_port_info mv_port_info[] = {
{ /* chip_504x */
.sht = &mv_sht,
@@ -467,6 +513,21 @@
.udma_mask = 0x7f, /* udma0-6 */
.port_ops = &mv6_ops,
},
+ { /* chip_6042 */
+ .sht = &mv_sht,
+ .host_flags = (MV_COMMON_FLAGS | MV_6XXX_FLAGS),
+ .pio_mask = 0x1f, /* pio0-4 */
+ .udma_mask = 0x7f, /* udma0-6 */
+ .port_ops = &mv_iie_ops,
+ },
+ { /* chip_7042 */
+ .sht = &mv_sht,
+ .host_flags = (MV_COMMON_FLAGS | MV_6XXX_FLAGS |
+ MV_FLAG_DUAL_HC),
+ .pio_mask = 0x1f, /* pio0-4 */
+ .udma_mask = 0x7f, /* udma0-6 */
+ .port_ops = &mv_iie_ops,
+ },
};
static const struct pci_device_id mv_pci_tbl[] = {
@@ -477,6 +538,7 @@
{PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6040), 0, 0, chip_604x},
{PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6041), 0, 0, chip_604x},
+ {PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6042), 0, 0, chip_6042},
{PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6080), 0, 0, chip_608x},
{PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6081), 0, 0, chip_608x},
@@ -572,8 +634,8 @@
* @base: port base address
* @pp: port private data
*
- * Verify the local cache of the eDMA state is accurate with an
- * assert.
+ * Verify the local cache of the eDMA state is accurate with a
+ * WARN_ON.
*
* LOCKING:
* Inherited from caller.
@@ -584,15 +646,15 @@
writelfl(EDMA_EN, base + EDMA_CMD_OFS);
pp->pp_flags |= MV_PP_FLAG_EDMA_EN;
}
- assert(EDMA_EN & readl(base + EDMA_CMD_OFS));
+ WARN_ON(!(EDMA_EN & readl(base + EDMA_CMD_OFS)));
}
/**
* mv_stop_dma - Disable eDMA engine
* @ap: ATA channel to manipulate
*
- * Verify the local cache of the eDMA state is accurate with an
- * assert.
+ * Verify the local cache of the eDMA state is accurate with a
+ * WARN_ON.
*
* LOCKING:
* Inherited from caller.
@@ -610,7 +672,7 @@
writelfl(EDMA_DS, port_mmio + EDMA_CMD_OFS);
pp->pp_flags &= ~MV_PP_FLAG_EDMA_EN;
} else {
- assert(!(EDMA_EN & readl(port_mmio + EDMA_CMD_OFS)));
+ WARN_ON(EDMA_EN & readl(port_mmio + EDMA_CMD_OFS));
}
/* now properly wait for the eDMA to stop */
@@ -690,7 +752,7 @@
mv_dump_mem(mmio_base+0xf00, 0x4);
mv_dump_mem(mmio_base+0x1d00, 0x6c);
for (hc = start_hc; hc < start_hc + num_hcs; hc++) {
- hc_base = mv_hc_base(mmio_base, port >> MV_PORT_HC_SHIFT);
+ hc_base = mv_hc_base(mmio_base, hc);
DPRINTK("HC regs (HC %i):\n", hc);
mv_dump_mem(hc_base, 0x1c);
}
@@ -773,6 +835,33 @@
dma_free_coherent(dev, MV_PORT_PRIV_DMA_SZ, pp->crpb, pp->crpb_dma);
}
+static void mv_edma_cfg(struct mv_host_priv *hpriv, void __iomem *port_mmio)
+{
+ u32 cfg = readl(port_mmio + EDMA_CFG_OFS);
+
+ /* set up non-NCQ EDMA configuration */
+ cfg &= ~0x1f; /* clear queue depth */
+ cfg &= ~EDMA_CFG_NCQ; /* clear NCQ mode */
+ cfg &= ~(1 << 9); /* disable equeue */
+
+ if (IS_GEN_I(hpriv))
+ cfg |= (1 << 8); /* enab config burst size mask */
+
+ else if (IS_GEN_II(hpriv))
+ cfg |= EDMA_CFG_RD_BRST_EXT | EDMA_CFG_WR_BUFF_LEN;
+
+ else if (IS_GEN_IIE(hpriv)) {
+ cfg |= (1 << 23); /* dis RX PM port mask */
+ cfg &= ~(1 << 16); /* dis FIS-based switching (for now) */
+ cfg &= ~(1 << 19); /* dis 128-entry queue (for now?) */
+ cfg |= (1 << 18); /* enab early completion */
+ cfg |= (1 << 17); /* enab host q cache */
+ cfg |= (1 << 22); /* enab cutthrough */
+ }
+
+ writelfl(cfg, port_mmio + EDMA_CFG_OFS);
+}
+
/**
* mv_port_start - Port specific init/start routine.
* @ap: ATA channel to manipulate
@@ -786,6 +875,7 @@
static int mv_port_start(struct ata_port *ap)
{
struct device *dev = ap->host_set->dev;
+ struct mv_host_priv *hpriv = ap->host_set->private_data;
struct mv_port_priv *pp;
void __iomem *port_mmio = mv_ap_base(ap);
void *mem;
@@ -829,22 +919,29 @@
pp->sg_tbl = mem;
pp->sg_tbl_dma = mem_dma;
- writelfl(EDMA_CFG_Q_DEPTH | EDMA_CFG_RD_BRST_EXT |
- EDMA_CFG_WR_BUFF_LEN, port_mmio + EDMA_CFG_OFS);
+ mv_edma_cfg(hpriv, port_mmio);
writel((pp->crqb_dma >> 16) >> 16, port_mmio + EDMA_REQ_Q_BASE_HI_OFS);
writelfl(pp->crqb_dma & EDMA_REQ_Q_BASE_LO_MASK,
port_mmio + EDMA_REQ_Q_IN_PTR_OFS);
- writelfl(0, port_mmio + EDMA_REQ_Q_OUT_PTR_OFS);
- writelfl(0, port_mmio + EDMA_RSP_Q_IN_PTR_OFS);
+ if (hpriv->hp_flags & MV_HP_ERRATA_XX42A0)
+ writelfl(pp->crqb_dma & 0xffffffff,
+ port_mmio + EDMA_REQ_Q_OUT_PTR_OFS);
+ else
+ writelfl(0, port_mmio + EDMA_REQ_Q_OUT_PTR_OFS);
writel((pp->crpb_dma >> 16) >> 16, port_mmio + EDMA_RSP_Q_BASE_HI_OFS);
+
+ if (hpriv->hp_flags & MV_HP_ERRATA_XX42A0)
+ writelfl(pp->crpb_dma & 0xffffffff,
+ port_mmio + EDMA_RSP_Q_IN_PTR_OFS);
+ else
+ writelfl(0, port_mmio + EDMA_RSP_Q_IN_PTR_OFS);
+
writelfl(pp->crpb_dma & EDMA_RSP_Q_BASE_LO_MASK,
port_mmio + EDMA_RSP_Q_OUT_PTR_OFS);
- pp->req_producer = pp->rsp_consumer = 0;
-
/* Don't turn on EDMA here...do it before DMA commands only. Else
* we'll be unable to send non-data, PIO, etc due to restricted access
* to shadow regs.
@@ -915,7 +1012,7 @@
pp->sg_tbl[i].addr = cpu_to_le32(addr & 0xffffffff);
pp->sg_tbl[i].addr_hi = cpu_to_le32((addr >> 16) >> 16);
- pp->sg_tbl[i].flags_size = cpu_to_le32(len);
+ pp->sg_tbl[i].flags_size = cpu_to_le32(len & 0xffff);
sg_len -= len;
addr += len;
@@ -928,16 +1025,16 @@
}
}
-static inline unsigned mv_inc_q_index(unsigned *index)
+static inline unsigned mv_inc_q_index(unsigned index)
{
- *index = (*index + 1) & MV_MAX_Q_DEPTH_MASK;
- return *index;
+ return (index + 1) & MV_MAX_Q_DEPTH_MASK;
}
-static inline void mv_crqb_pack_cmd(u16 *cmdw, u8 data, u8 addr, unsigned last)
+static inline void mv_crqb_pack_cmd(__le16 *cmdw, u8 data, u8 addr, unsigned last)
{
- *cmdw = data | (addr << CRQB_CMD_ADDR_SHIFT) | CRQB_CMD_CS |
+ u16 tmp = data | (addr << CRQB_CMD_ADDR_SHIFT) | CRQB_CMD_CS |
(last ? CRQB_CMD_LAST : 0);
+ *cmdw = cpu_to_le16(tmp);
}
/**
@@ -956,34 +1053,32 @@
{
struct ata_port *ap = qc->ap;
struct mv_port_priv *pp = ap->private_data;
- u16 *cw;
+ __le16 *cw;
struct ata_taskfile *tf;
u16 flags = 0;
+ unsigned in_index;
- if (ATA_PROT_DMA != qc->tf.protocol) {
+ if (ATA_PROT_DMA != qc->tf.protocol)
return;
- }
-
- /* the req producer index should be the same as we remember it */
- assert(((readl(mv_ap_base(qc->ap) + EDMA_REQ_Q_IN_PTR_OFS) >>
- EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK) ==
- pp->req_producer);
/* Fill in command request block
*/
- if (!(qc->tf.flags & ATA_TFLAG_WRITE)) {
+ if (!(qc->tf.flags & ATA_TFLAG_WRITE))
flags |= CRQB_FLAG_READ;
- }
- assert(MV_MAX_Q_DEPTH > qc->tag);
+ WARN_ON(MV_MAX_Q_DEPTH <= qc->tag);
flags |= qc->tag << CRQB_TAG_SHIFT;
- pp->crqb[pp->req_producer].sg_addr =
+ /* get current queue index from hardware */
+ in_index = (readl(mv_ap_base(ap) + EDMA_REQ_Q_IN_PTR_OFS)
+ >> EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK;
+
+ pp->crqb[in_index].sg_addr =
cpu_to_le32(pp->sg_tbl_dma & 0xffffffff);
- pp->crqb[pp->req_producer].sg_addr_hi =
+ pp->crqb[in_index].sg_addr_hi =
cpu_to_le32((pp->sg_tbl_dma >> 16) >> 16);
- pp->crqb[pp->req_producer].ctrl_flags = cpu_to_le16(flags);
+ pp->crqb[in_index].ctrl_flags = cpu_to_le16(flags);
- cw = &pp->crqb[pp->req_producer].ata_cmd[0];
+ cw = &pp->crqb[in_index].ata_cmd[0];
tf = &qc->tf;
/* Sadly, the CRQB cannot accomodate all registers--there are
@@ -1029,9 +1124,76 @@
mv_crqb_pack_cmd(cw++, tf->device, ATA_REG_DEVICE, 0);
mv_crqb_pack_cmd(cw++, tf->command, ATA_REG_CMD, 1); /* last */
- if (!(qc->flags & ATA_QCFLAG_DMAMAP)) {
+ if (!(qc->flags & ATA_QCFLAG_DMAMAP))
+ return;
+ mv_fill_sg(qc);
+}
+
+/**
+ * mv_qc_prep_iie - Host specific command preparation.
+ * @qc: queued command to prepare
+ *
+ * This routine simply redirects to the general purpose routine
+ * if command is not DMA. Else, it handles prep of the CRQB
+ * (command request block), does some sanity checking, and calls
+ * the SG load routine.
+ *
+ * LOCKING:
+ * Inherited from caller.
+ */
+static void mv_qc_prep_iie(struct ata_queued_cmd *qc)
+{
+ struct ata_port *ap = qc->ap;
+ struct mv_port_priv *pp = ap->private_data;
+ struct mv_crqb_iie *crqb;
+ struct ata_taskfile *tf;
+ unsigned in_index;
+ u32 flags = 0;
+
+ if (ATA_PROT_DMA != qc->tf.protocol)
+ return;
+
+ /* Fill in Gen IIE command request block
+ */
+ if (!(qc->tf.flags & ATA_TFLAG_WRITE))
+ flags |= CRQB_FLAG_READ;
+
+ WARN_ON(MV_MAX_Q_DEPTH <= qc->tag);
+ flags |= qc->tag << CRQB_TAG_SHIFT;
+
+ /* get current queue index from hardware */
+ in_index = (readl(mv_ap_base(ap) + EDMA_REQ_Q_IN_PTR_OFS)
+ >> EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK;
+
+ crqb = (struct mv_crqb_iie *) &pp->crqb[in_index];
+ crqb->addr = cpu_to_le32(pp->sg_tbl_dma & 0xffffffff);
+ crqb->addr_hi = cpu_to_le32((pp->sg_tbl_dma >> 16) >> 16);
+ crqb->flags = cpu_to_le32(flags);
+
+ tf = &qc->tf;
+ crqb->ata_cmd[0] = cpu_to_le32(
+ (tf->command << 16) |
+ (tf->feature << 24)
+ );
+ crqb->ata_cmd[1] = cpu_to_le32(
+ (tf->lbal << 0) |
+ (tf->lbam << 8) |
+ (tf->lbah << 16) |
+ (tf->device << 24)
+ );
+ crqb->ata_cmd[2] = cpu_to_le32(
+ (tf->hob_lbal << 0) |
+ (tf->hob_lbam << 8) |
+ (tf->hob_lbah << 16) |
+ (tf->hob_feature << 24)
+ );
+ crqb->ata_cmd[3] = cpu_to_le32(
+ (tf->nsect << 0) |
+ (tf->hob_nsect << 8)
+ );
+
+ if (!(qc->flags & ATA_QCFLAG_DMAMAP))
return;
- }
mv_fill_sg(qc);
}
@@ -1051,6 +1213,7 @@
{
void __iomem *port_mmio = mv_ap_base(qc->ap);
struct mv_port_priv *pp = qc->ap->private_data;
+ unsigned in_index;
u32 in_ptr;
if (ATA_PROT_DMA != qc->tf.protocol) {
@@ -1062,23 +1225,20 @@
return ata_qc_issue_prot(qc);
}
- in_ptr = readl(port_mmio + EDMA_REQ_Q_IN_PTR_OFS);
+ in_ptr = readl(port_mmio + EDMA_REQ_Q_IN_PTR_OFS);
+ in_index = (in_ptr >> EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK;
- /* the req producer index should be the same as we remember it */
- assert(((in_ptr >> EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK) ==
- pp->req_producer);
/* until we do queuing, the queue should be empty at this point */
- assert(((in_ptr >> EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK) ==
- ((readl(port_mmio + EDMA_REQ_Q_OUT_PTR_OFS) >>
- EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK));
+ WARN_ON(in_index != ((readl(port_mmio + EDMA_REQ_Q_OUT_PTR_OFS)
+ >> EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK));
- mv_inc_q_index(&pp->req_producer); /* now incr producer index */
+ in_index = mv_inc_q_index(in_index); /* now incr producer index */
mv_start_dma(port_mmio, pp);
/* and write the request in pointer to kick the EDMA to life */
in_ptr &= EDMA_REQ_Q_BASE_LO_MASK;
- in_ptr |= pp->req_producer << EDMA_REQ_Q_PTR_SHIFT;
+ in_ptr |= in_index << EDMA_REQ_Q_PTR_SHIFT;
writelfl(in_ptr, port_mmio + EDMA_REQ_Q_IN_PTR_OFS);
return 0;
@@ -1090,7 +1250,7 @@
*
* This routine is for use when the port is in DMA mode, when it
* will be using the CRPB (command response block) method of
- * returning command completion information. We assert indices
+ * returning command completion information. We check indices
* are good, grab status, and bump the response consumer index to
* prove that we're up to date.
*
@@ -1101,28 +1261,26 @@
{
void __iomem *port_mmio = mv_ap_base(ap);
struct mv_port_priv *pp = ap->private_data;
+ unsigned out_index;
u32 out_ptr;
u8 ata_status;
- out_ptr = readl(port_mmio + EDMA_RSP_Q_OUT_PTR_OFS);
+ out_ptr = readl(port_mmio + EDMA_RSP_Q_OUT_PTR_OFS);
+ out_index = (out_ptr >> EDMA_RSP_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK;
- /* the response consumer index should be the same as we remember it */
- assert(((out_ptr >> EDMA_RSP_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK) ==
- pp->rsp_consumer);
-
- ata_status = pp->crpb[pp->rsp_consumer].flags >> CRPB_FLAG_STATUS_SHIFT;
+ ata_status = le16_to_cpu(pp->crpb[out_index].flags)
+ >> CRPB_FLAG_STATUS_SHIFT;
/* increment our consumer index... */
- pp->rsp_consumer = mv_inc_q_index(&pp->rsp_consumer);
+ out_index = mv_inc_q_index(out_index);
/* and, until we do NCQ, there should only be 1 CRPB waiting */
- assert(((readl(port_mmio + EDMA_RSP_Q_IN_PTR_OFS) >>
- EDMA_RSP_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK) ==
- pp->rsp_consumer);
+ WARN_ON(out_index != ((readl(port_mmio + EDMA_RSP_Q_IN_PTR_OFS)
+ >> EDMA_RSP_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK));
/* write out our inc'd consumer index so EDMA knows we're caught up */
out_ptr &= EDMA_RSP_Q_BASE_LO_MASK;
- out_ptr |= pp->rsp_consumer << EDMA_RSP_Q_PTR_SHIFT;
+ out_ptr |= out_index << EDMA_RSP_Q_PTR_SHIFT;
writelfl(out_ptr, port_mmio + EDMA_RSP_Q_OUT_PTR_OFS);
/* Return ATA status register for completed CRPB */
@@ -1132,6 +1290,7 @@
/**
* mv_err_intr - Handle error interrupts on the port
* @ap: ATA channel to manipulate
+ * @reset_allowed: bool: 0 == don't trigger from reset here
*
* In most cases, just clear the interrupt and move on. However,
* some cases require an eDMA reset, which is done right before
@@ -1142,7 +1301,7 @@
* LOCKING:
* Inherited from caller.
*/
-static void mv_err_intr(struct ata_port *ap)
+static void mv_err_intr(struct ata_port *ap, int reset_allowed)
{
void __iomem *port_mmio = mv_ap_base(ap);
u32 edma_err_cause, serr = 0;
@@ -1164,9 +1323,8 @@
writelfl(0, port_mmio + EDMA_ERR_IRQ_CAUSE_OFS);
/* check for fatal here and recover if needed */
- if (EDMA_ERR_FATAL & edma_err_cause) {
+ if (reset_allowed && (EDMA_ERR_FATAL & edma_err_cause))
mv_stop_and_reset(ap);
- }
}
/**
@@ -1190,7 +1348,6 @@
{
void __iomem *mmio = host_set->mmio_base;
void __iomem *hc_mmio = mv_hc_base(mmio, hc);
- struct ata_port *ap;
struct ata_queued_cmd *qc;
u32 hc_irq_cause;
int shift, port, port0, hard_port, handled;
@@ -1213,21 +1370,34 @@
for (port = port0; port < port0 + MV_PORTS_PER_HC; port++) {
u8 ata_status = 0;
- ap = host_set->ports[port];
- hard_port = port & MV_PORT_MASK; /* range 0-3 */
+ struct ata_port *ap = host_set->ports[port];
+ struct mv_port_priv *pp = ap->private_data;
+
+ hard_port = mv_hardport_from_port(port); /* range 0..3 */
handled = 0; /* ensure ata_status is set if handled++ */
- if ((CRPB_DMA_DONE << hard_port) & hc_irq_cause) {
- /* new CRPB on the queue; just one at a time until NCQ
- */
- ata_status = mv_get_crpb_status(ap);
- handled++;
- } else if ((DEV_IRQ << hard_port) & hc_irq_cause) {
- /* received ATA IRQ; read the status reg to clear INTRQ
- */
- ata_status = readb((void __iomem *)
+ /* Note that DEV_IRQ might happen spuriously during EDMA,
+ * and should be ignored in such cases.
+ * The cause of this is still under investigation.
+ */
+ if (pp->pp_flags & MV_PP_FLAG_EDMA_EN) {
+ /* EDMA: check for response queue interrupt */
+ if ((CRPB_DMA_DONE << hard_port) & hc_irq_cause) {
+ ata_status = mv_get_crpb_status(ap);
+ handled = 1;
+ }
+ } else {
+ /* PIO: check for device (drive) interrupt */
+ if ((DEV_IRQ << hard_port) & hc_irq_cause) {
+ ata_status = readb((void __iomem *)
ap->ioaddr.status_addr);
- handled++;
+ handled = 1;
+ /* ignore spurious intr if drive still BUSY */
+ if (ata_status & ATA_BUSY) {
+ ata_status = 0;
+ handled = 0;
+ }
+ }
}
if (ap &&
@@ -1241,14 +1411,14 @@
shift++; /* skip bit 8 in the HC Main IRQ reg */
}
if ((PORT0_ERR << shift) & relevant) {
- mv_err_intr(ap);
+ mv_err_intr(ap, 1);
err_mask |= AC_ERR_OTHER;
- handled++;
+ handled = 1;
}
- if (handled && ap) {
+ if (handled) {
qc = ata_qc_from_tag(ap, ap->active_tag);
- if (NULL != qc) {
+ if (qc && (qc->flags & ATA_QCFLAG_ACTIVE)) {
VPRINTK("port %u IRQ found for qc, "
"ata_status 0x%x\n", port,ata_status);
/* mark qc status appropriately */
@@ -1283,6 +1453,7 @@
struct ata_host_set *host_set = dev_instance;
unsigned int hc, handled = 0, n_hcs;
void __iomem *mmio = host_set->mmio_base;
+ struct mv_host_priv *hpriv;
u32 irq_stat;
irq_stat = readl(mmio + HC_MAIN_IRQ_CAUSE_OFS);
@@ -1304,6 +1475,17 @@
handled++;
}
}
+
+ hpriv = host_set->private_data;
+ if (IS_60XX(hpriv)) {
+ /* deal with the interrupt coalescing bits */
+ if (irq_stat & (TRAN_LO_DONE | TRAN_HI_DONE | PORTS_0_7_COAL_DONE)) {
+ writelfl(0, mmio + MV_IRQ_COAL_CAUSE_LO);
+ writelfl(0, mmio + MV_IRQ_COAL_CAUSE_HI);
+ writelfl(0, mmio + MV_IRQ_COAL_CAUSE);
+ }
+ }
+
if (PCI_ERR & irq_stat) {
printk(KERN_ERR DRV_NAME ": PCI ERROR; PCI IRQ cause=0x%08x\n",
readl(mmio + PCI_IRQ_CAUSE_OFS));
@@ -1684,6 +1866,12 @@
m2 |= hpriv->signal[port].pre;
m2 &= ~(1 << 16);
+ /* according to mvSata 3.6.1, some IIE values are fixed */
+ if (IS_GEN_IIE(hpriv)) {
+ m2 &= ~0xC30FF01F;
+ m2 |= 0x0000900F;
+ }
+
writel(m2, port_mmio + PHY_MODE2);
}
@@ -1696,7 +1884,8 @@
if (IS_60XX(hpriv)) {
u32 ifctl = readl(port_mmio + SATA_INTERFACE_CTL);
- ifctl |= (1 << 12) | (1 << 7);
+ ifctl |= (1 << 7); /* enable gen2i speed */
+ ifctl = (ifctl & 0xfff) | 0x9b1000; /* from chip spec */
writelfl(ifctl, port_mmio + SATA_INTERFACE_CTL);
}
@@ -1792,7 +1981,7 @@
ata_port_probe(ap);
} else {
printk(KERN_INFO "ata%u: no device found (phy stat %08x)\n",
- ap->id, scr_read(ap, SCR_STATUS));
+ ap->id, scr_read(ap, SCR_STATUS));
ata_port_disable(ap);
return;
}
@@ -1861,13 +2050,11 @@
ap->host_set->mmio_base, ap, qc, qc->scsicmd,
&qc->scsicmd->cmnd);
- mv_err_intr(ap);
+ mv_err_intr(ap, 0);
mv_stop_and_reset(ap);
- if (!qc) {
- printk(KERN_ERR "ata%u: BUG: timeout without command\n",
- ap->id);
- } else {
+ WARN_ON(!(qc->flags & ATA_QCFLAG_ACTIVE));
+ if (qc->flags & ATA_QCFLAG_ACTIVE) {
/* hack alert! We cannot use the supplied completion
* function from inside the ->eh_strategy_handler() thread.
* libata is the only user of ->eh_strategy_handler() in
@@ -1998,6 +2185,27 @@
}
break;
+ case chip_7042:
+ case chip_6042:
+ hpriv->ops = &mv6xxx_ops;
+
+ hp_flags |= MV_HP_GEN_IIE;
+
+ switch (rev_id) {
+ case 0x0:
+ hp_flags |= MV_HP_ERRATA_XX42A0;
+ break;
+ case 0x1:
+ hp_flags |= MV_HP_ERRATA_60X1C0;
+ break;
+ default:
+ dev_printk(KERN_WARNING, &pdev->dev,
+ "Applying 60X1C0 workarounds to unknown rev\n");
+ hp_flags |= MV_HP_ERRATA_60X1C0;
+ break;
+ }
+ break;
+
default:
printk(KERN_ERR DRV_NAME ": BUG: invalid board index %u\n", board_idx);
return 1;
@@ -2052,7 +2260,8 @@
void __iomem *port_mmio = mv_port_base(mmio, port);
u32 ifctl = readl(port_mmio + SATA_INTERFACE_CTL);
- ifctl |= (1 << 12);
+ ifctl |= (1 << 7); /* enable gen2i speed */
+ ifctl = (ifctl & 0xfff) | 0x9b1000; /* from chip spec */
writelfl(ifctl, port_mmio + SATA_INTERFACE_CTL);
}
@@ -2153,6 +2362,7 @@
if (rc) {
return rc;
}
+ pci_set_master(pdev);
rc = pci_request_regions(pdev, DRV_NAME);
if (rc) {
^ permalink raw reply
* Re: Help Needed: floating point used in kernel (task=c0398410, pc=3184)
From: sandeep malik @ 2006-05-26 14:00 UTC (permalink / raw)
To: Roger Larsson, linuxppc-embedded
In-Reply-To: <200605260949.48627.roger.larsson@norran.net>
Hi Roger,
The kernel is not linked with uClibc/glibc its user
application only which is linked with uClibc/glibc....
What i am able to conclude is that the library
internall might be using floating point operations and
might be genrating some floating point instructions
which are not handled by our board....and that might
be the reason....or this error might be mapped in a
generic way such that it is getting flashed in some
particular scenarios.....
I might be wrong but as of now i don't have any other
explaination as now after linking with glibs the
application is working fine.....
Regards,
Malik
--- Roger Larsson <roger.larsson@norran.net> wrote:
> On fredag 26 maj 2006 09.38, you wrote:
> > Hi Roger,
> >
> > The problem has been resolved...the issue was in
> the make
> > file.....actually we were cpmiling the code with
> gclibc and linking it with
> > uClibc which was causing the problem.....But this
> was real test i faced
> > till now as all the tricks realted to the message
> were failed.....any ways
> > thanks for ur help....
> > Regards,
> > Malik
>
> Now I am confused!
>
> How could this cause
> "floating point used in kernel (task=c0398410,
> pc=3184)"
>
> Both uClibc and gclibc are user land libraries. They
> should not be able to
> cause an kernel floating point operation. No user
> land code should be able
> to do this!
>
> Or is it your kernel linked with uClibc/gclibc? I do
> not think that is the
> right thing to do...
>
> /RogerL
>
Send instant messages to your online friends http://in.messenger.yahoo.com
^ permalink raw reply
* [RFC/PATCH] powersave_nap cleanup
From: Nathan Lynch @ 2006-05-26 14:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
[ Please consider for 2.6.18. ]
Instead of having the machdep_calls.power_save routines (such as
ppc6xx_idle and power4_idle) individually check the value of the
powersave_nap sysctl variable, we can have the newly-consolidated idle
loop check the value of powersave_nap when deciding whether to call
machdep_calls.power_save. In this way, a platform can implement a
machdep_calls.power_save method but still have threads go low-priority
when idle if the user has set powersave_nap to 0.
Rename machdep_calls.power_save to machdep_calls.powersave_nap to make
more apparent the connection with the powersave_nap sysctl.
Add some documentation to machdep_calls.powersave_nap to more
completely describe its intended use.
Change cpu_idle to call ppc_md.powersave_nap only when the
powersave_nap sysctl is set.
Remove tests of the powersave_nap variable from the ppc6xx_idle and
power4_idle routines.
Set powersave_nap to 1 by default on pSeries when the shared processor
firmware feature is present, preserving current behavior.
Remove a superfluous declaration of powersave_nap from
platforms/powermac/feature.c.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
index d491052..09bd0cf 100644
--- a/arch/powerpc/kernel/idle.c
+++ b/arch/powerpc/kernel/idle.c
@@ -53,7 +53,7 @@ void cpu_idle(void)
while (!need_resched() && !cpu_should_die()) {
ppc64_runlatch_off();
- if (ppc_md.power_save) {
+ if (ppc_md.powersave_nap && powersave_nap) {
clear_thread_flag(TIF_POLLING_NRFLAG);
/*
* smp_mb is so clearing of TIF_POLLING_NRFLAG
@@ -64,7 +64,7 @@ void cpu_idle(void)
/* check again after disabling irqs */
if (!need_resched() && !cpu_should_die())
- ppc_md.power_save();
+ ppc_md.powersave_nap();
local_irq_enable();
set_thread_flag(TIF_POLLING_NRFLAG);
diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/idle_6xx.S
index b45fa0e..c685a8d 100644
--- a/arch/powerpc/kernel/idle_6xx.S
+++ b/arch/powerpc/kernel/idle_6xx.S
@@ -1,5 +1,5 @@
/*
- * This file contains the power_save function for 6xx & 7xxx CPUs
+ * This file contains the powersave_nap function for 6xx & 7xxx CPUs
* rewritten in assembler
*
* Warning ! This code assumes that if your machine has a 750fx
@@ -74,11 +74,6 @@ BEGIN_FTR_SECTION
lwz r4,CPU_SPEC_FEATURES(r4)
andi. r0,r4,CPU_FTR_CAN_NAP
beq 1f
- /* Now check if user or arch enabled NAP mode */
- lis r4,powersave_nap@ha
- lwz r4,powersave_nap@l(r4)
- cmpwi 0,r4,0
- beq 1f
lis r3,HID0_NAP@h
1:
END_FTR_SECTION_IFSET(CPU_FTR_CAN_NAP)
diff --git a/arch/powerpc/kernel/idle_power4.S b/arch/powerpc/kernel/idle_power4.S
index d85c7c9..14e3c18 100644
--- a/arch/powerpc/kernel/idle_power4.S
+++ b/arch/powerpc/kernel/idle_power4.S
@@ -1,5 +1,5 @@
/*
- * This file contains the power_save function for 970-family CPUs.
+ * This file contains the powersave_nap function for 970-family CPUs.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -24,12 +24,6 @@ _GLOBAL(power4_idle)
BEGIN_FTR_SECTION
blr
END_FTR_SECTION_IFCLR(CPU_FTR_CAN_NAP)
- /* Now check if user or arch enabled NAP mode */
- LOAD_REG_ADDRBASE(r3,powersave_nap)
- lwz r4,ADDROFF(powersave_nap)(r3)
- cmpwi 0,r4,0
- beqlr
-
/* Go to NAP now */
BEGIN_FTR_SECTION
DSSALL
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 69ac257..57af9c4 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -142,7 +142,7 @@ void __init machine_init(unsigned long d
#ifdef CONFIG_6xx
if (cpu_has_feature(CPU_FTR_CAN_DOZE) ||
cpu_has_feature(CPU_FTR_CAN_NAP))
- ppc_md.power_save = ppc6xx_idle;
+ ppc_md.powersave_nap = ppc6xx_idle;
#endif
if (ppc_md.progress)
diff --git a/arch/powerpc/platforms/maple/setup.c b/arch/powerpc/platforms/maple/setup.c
index 24c0aef..eaa4c65 100644
--- a/arch/powerpc/platforms/maple/setup.c
+++ b/arch/powerpc/platforms/maple/setup.c
@@ -292,7 +292,7 @@ define_machine(maple_md) {
.get_rtc_time = maple_get_rtc_time,
.calibrate_decr = generic_calibrate_decr,
.progress = maple_progress,
- .power_save = power4_idle,
+ .powersave_nap = power4_idle,
#ifdef CONFIG_KEXEC
.machine_kexec = default_machine_kexec,
.machine_kexec_prepare = default_machine_kexec_prepare,
diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
index a5063cd..b9a45df 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -53,7 +53,6 @@
extern int powersave_lowspeed;
#endif
-extern int powersave_nap;
extern struct device_node *k2_skiplist[2];
/*
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index 4d15e39..66e6a21 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -740,7 +740,7 @@ define_machine(powermac) {
.progress = udbg_progress,
#ifdef CONFIG_PPC64
.pci_probe_mode = pmac_pci_probe_mode,
- .power_save = power4_idle,
+ .powersave_nap = power4_idle,
.enable_pmcs = power4_enable_pmcs,
#ifdef CONFIG_KEXEC
.machine_kexec = default_machine_kexec,
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 5f79f01..d094e9d 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -236,11 +236,13 @@ static void __init pSeries_setup_arch(vo
vpa_init(boot_cpuid);
if (get_lppaca()->shared_proc) {
printk(KERN_INFO "Using shared processor idle loop\n");
- ppc_md.power_save = pseries_shared_idle_sleep;
+ ppc_md.powersave_nap = pseries_shared_idle_sleep;
} else {
printk(KERN_INFO "Using dedicated idle loop\n");
- ppc_md.power_save = pseries_dedicated_idle_sleep;
+ ppc_md.powersave_nap = pseries_dedicated_idle_sleep;
}
+ /* We want this on by default. */
+ powersave_nap = 1;
} else {
printk(KERN_INFO "Using default idle loop\n");
}
diff --git a/include/asm-powerpc/machdep.h b/include/asm-powerpc/machdep.h
index 0f9254c..721fbe2 100644
--- a/include/asm-powerpc/machdep.h
+++ b/include/asm-powerpc/machdep.h
@@ -160,10 +160,11 @@ struct machdep_calls {
void (*idle_loop)(void);
/*
- * Function for waiting for work with reduced power in idle loop;
- * called with interrupts disabled.
+ * Function for waiting for work with reduced power and/or cpu
+ * utilization in idle loop; called with interrupts disabled.
+ * Can be overriden by the powersave_nap sysctl.
*/
- void (*power_save)(void);
+ void (*powersave_nap)(void);
/* Function to enable performance monitor counters for this
platform, called once per cpu. */
^ permalink raw reply related
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Sven Luther @ 2006-05-26 14:15 UTC (permalink / raw)
To: Mark Lord
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <44770065.8070907@rtr.ca>
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
On Fri, May 26, 2006 at 09:19:33AM -0400, Mark Lord wrote:
> Sven Luther wrote:
> >On Fri, May 26, 2006 at 07:41:24AM -0400, Mark Lord wrote:
> >>All of the relevant bits of "my work" are now in Jeff's upstream libata
> >>tree,
> >>from the recently posted sata_mv patches.
> >
> >Ok. can i use this tree with a 2.6.16 base ?
>
> Not as-is. Here (attached) is a patch for 2.6.16.17+ that updates
> the sata_mv driver to the latest source. Completely untested,
> but it does compile.
>
> I will hopefully test it later today, but in the meanwhile, have a go at it.
And here is attached my dmesg output. The last bit of mv_host_intr was when i
tried to access the partition table of the disk with parted.
Friendly,
Sven Luther
[-- Attachment #2: dmesg-2.6.16-mv_sata.gz --]
[-- Type: application/octet-stream, Size: 4002 bytes --]
^ permalink raw reply
* 2.6 (eldk) - I2C constants
From: Naru Sundar @ 2006-05-26 14:33 UTC (permalink / raw)
To: linuxppc-embedded
Hello folks, I'm porting a 2.4 driver over to 2.6 and noted some
weirdness in the I2C headers. I thought it was worth checking out here.
include/linux/i2c.h in 2.4 defined the following constants:
#define I2C_M_TEN 0x10 /* we have a ten bit chip address */
#define I2C_M_RD 0x01
#define I2C_M_WR 0x00 /* For readable code! */
#define I2C_M_NOSTART 0x4000
#define I2C_M_REV_DIR_ADDR 0x2000
in ELDK 2.6 source drop I have (2.6.15), the I2C_M_WR constant was removed.
Any thoughts? I can declare that constant locally in the driver, but
since these were standard I2C message constants I thought something
odd was up (or am I missing something obvious).
Thanks
--
Naru Sundar <nsundar@fulcrummicro.com>
Fulcrum Microsystems
http://www.fulcrummicro.com
^ permalink raw reply
* [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3
From: Mel Gorman @ 2006-05-26 15:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: apkm, linux-kernel
For the last few -mm releases, kernels built for an old RS6000 failed to
compile with the message;
arch/powerpc/kernel/built-in.o(.init.text+0x77b4): In function `vrsqrtefp':
: undefined reference to `__udivdi3'
arch/powerpc/kernel/built-in.o(.init.text+0x7800): In function `vrsqrtefp':
: undefined reference to `__udivdi3'
make: *** [.tmp_vmlinux1] Error 1
2.6.17-rc5 is not affected but I didn't search for the culprit patch in
-mm. The following patch adds an implementation of __udivdi3 for plain old
ppc32. This may not be the correct fix as Google tells me that __udivdi3
has been replaced by calls to do_div() in a number of cases. There was no
obvious way to do that for vrsqrtefp, hence this workaround. The patch should
be acked, rejected or replaced by a ppc expert.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc5-clean/arch/powerpc/lib/Makefile linux-2.6.17-rc5-udivdi3_ppc/arch/powerpc/lib/Makefile
--- linux-2.6.17-rc5-clean/arch/powerpc/lib/Makefile 2006-05-25 02:50:17.000000000 +0100
+++ linux-2.6.17-rc5-udivdi3_ppc/arch/powerpc/lib/Makefile 2006-05-26 13:17:15.000000000 +0100
@@ -4,7 +4,7 @@
ifeq ($(CONFIG_PPC_MERGE),y)
obj-y := string.o strcase.o
-obj-$(CONFIG_PPC32) += div64.o copy_32.o checksum_32.o
+obj-$(CONFIG_PPC32) += div64.o copy_32.o checksum_32.o udivdi3.o
endif
obj-y += bitops.o
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc5-clean/arch/powerpc/lib/udivdi3.c linux-2.6.17-rc5-udivdi3_ppc/arch/powerpc/lib/udivdi3.c
--- linux-2.6.17-rc5-clean/arch/powerpc/lib/udivdi3.c 2006-05-26 13:17:22.000000000 +0100
+++ linux-2.6.17-rc5-udivdi3_ppc/arch/powerpc/lib/udivdi3.c 2006-05-26 13:25:26.000000000 +0100
@@ -0,0 +1,15 @@
+/*
+ * Simple __udivdi3 function which doesn't use FPU.
+ */
+
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <asm-generic/div64.h>
+
+u64 __udivdi3(u64 n, u64 d)
+{
+ if (d & ~0xffffffff)
+ panic("Need true 64-bit/64-bit division");
+ return __div64_32(&n, (u32)d);
+}
+
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)
From: Mel Gorman @ 2006-05-26 15:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: akpm, linux-kernel
(Resending with Andrew's email address correct this time)
For the last few -mm releases, kernels built for an old RS6000 failed to
compile with the message;
arch/powerpc/kernel/built-in.o(.init.text+0x77b4): In function `vrsqrtefp':
: undefined reference to `__udivdi3'
arch/powerpc/kernel/built-in.o(.init.text+0x7800): In function `vrsqrtefp':
: undefined reference to `__udivdi3'
make: *** [.tmp_vmlinux1] Error 1
2.6.17-rc5 is not affected but I didn't search for the culprit patch in
-mm. The following patch adds an implementation of __udivdi3 for plain old
ppc32. This may not be the correct fix as Google tells me that __udivdi3
has been replaced by calls to do_div() in a number of cases. There was no
obvious way to do that for vrsqrtefp, hence this workaround. The patch should
be acked, rejected or replaced by a ppc expert.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc5-clean/arch/powerpc/lib/Makefile linux-2.6.17-rc5-udivdi3_ppc/arch/powerpc/lib/Makefile
--- linux-2.6.17-rc5-clean/arch/powerpc/lib/Makefile 2006-05-25 02:50:17.000000000 +0100
+++ linux-2.6.17-rc5-udivdi3_ppc/arch/powerpc/lib/Makefile 2006-05-26 13:17:15.000000000 +0100
@@ -4,7 +4,7 @@
ifeq ($(CONFIG_PPC_MERGE),y)
obj-y := string.o strcase.o
-obj-$(CONFIG_PPC32) += div64.o copy_32.o checksum_32.o
+obj-$(CONFIG_PPC32) += div64.o copy_32.o checksum_32.o udivdi3.o
endif
obj-y += bitops.o
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc5-clean/arch/powerpc/lib/udivdi3.c linux-2.6.17-rc5-udivdi3_ppc/arch/powerpc/lib/udivdi3.c
--- linux-2.6.17-rc5-clean/arch/powerpc/lib/udivdi3.c 2006-05-26 13:17:22.000000000 +0100
+++ linux-2.6.17-rc5-udivdi3_ppc/arch/powerpc/lib/udivdi3.c 2006-05-26 13:25:26.000000000 +0100
@@ -0,0 +1,15 @@
+/*
+ * Simple __udivdi3 function which doesn't use FPU.
+ */
+
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <asm-generic/div64.h>
+
+u64 __udivdi3(u64 n, u64 d)
+{
+ if (d & ~0xffffffff)
+ panic("Need true 64-bit/64-bit division");
+ return __div64_32(&n, (u32)d);
+}
+
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: Cell and new CPU feature bits
From: Olof Johansson @ 2006-05-26 15:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Arnd Bergmann, Steve Munroe, linuxppc-dev list, Paul Mackerras,
Olof Johansson, cbe-oss-dev
In-Reply-To: <1148628831.8089.107.camel@localhost.localdomain>
On Fri, May 26, 2006 at 05:33:51PM +1000, Benjamin Herrenschmidt wrote:
> > Do we see this likely to be used in "global userspace", or more likely
> > in the processor-specific glibc sections? If it's in the
> > processor-specific ones, maybe we should have a per-processor bitfield
> > with erratas/features instead of a global one. That'd make allocation
> > easier too.
>
> Do we have to deal with that many errata that affect userland ? It's
> generally an area where processors are fairly well validated... I don't
> think we need to scale up that much on this one.
Right, amount of erratas should be limited. BUt the amount of features
can be larger, especially as they grow over time and never go away.
> > > Yes, I think a new CPU feature bit for that too is needed. Not much of
> > > these left...
> >
> > Well, are these instructions architected in some later version past
> > 2.02? If so, the bit is only needed on the older processors -- yet again
> > a case for sub-feature/errata bitmasks.
>
> I have to check but I suspect it's still optional.
Ok. Features like that tend to be implementation-specific in the firt
processor they show up in, and later make it into the architecture.
That's why I'm asking. :-)
-Olof
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Mark Lord @ 2006-05-26 15:47 UTC (permalink / raw)
To: Sven Luther
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <20060526141535.GA7084@powerlinux.fr>
Sven Luther wrote:
> On Fri, May 26, 2006 at 09:19:33AM -0400, Mark Lord wrote:
>> Sven Luther wrote:
>>> Ok. can i use this tree with a 2.6.16 base ?
>> Not as-is. Here (attached) is a patch for 2.6.16.17+ that updates
>> the sata_mv driver to the latest source. Completely untested,
>> but it does compile.
>>
>> I will hopefully test it later today, but in the meanwhile, have a go at it.
>
> And here is attached my dmesg output. The last bit of mv_host_intr was when i
> tried to access the partition table of the disk with parted.
I don't see anything particularly bad in that dmesg output,
apart from all of the debug output --> did you enable that,
or was it "on" by default?
It finds one SATA drive, with no *known* partition table format.
Can you access the disk? Eg. hexdump -C /dev/sda
Meanwhile, I just booted 2.6.17-rc5-git1 (latest kernel.org) on my Mac G3
box here, and sata_mv seems to be behaving for me (thus far).
Cheers
^ permalink raw reply
* Re: [snd] looking for layout-ids
From: Eddy Petrişor @ 2006-05-26 16:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1148553785.11759.12.camel@johannes.berg>
T24gNS8yNS8wNiwgSm9oYW5uZXMgQmVyZyA8am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldD4gd3Jv
dGU6Cj4gSGV5LAoKSGksCgo+IFsxXSB0byBmaW5kIHlvdXIgbGF5b3V0LWlkLCBleGVjdXRlIHRo
ZSBmb2xsb3dpbmc6Cj4KPiAgIGZpbmQgL3Byb2MvZGV2aWNlLXRyZWUvIC1uYW1lIGxheW91dC1p
ZCB8IHhhcmdzIGhleGR1bXAgLWUgJzEvNCAiMHgleFxuIicKPgo+IElmIHlvdSBnZXQgbm8gb3V0
cHV0LCB5b3UgaGF2ZSBubyBsYXlvdXQtaWQgcHJvcGVydHkuIElmIHlvdSBkbyBnZXQKCldoYXQg
YXJlIHRoZSBwbGFucyBmb3IgbWFjaGluZXMgd2l0aG91dCBsYXlvdXQtaWQsIGxpa2UgdGhlIDUs
MiBtb2RlbD8KV2lsbCB0aGVyZSBiZSBhbnkgYWxzYS9hb2Egc3VwcG9ydCBhdCBzb21lIHBvaW50
PwoKLS0gClJlZ2FyZHMsCkVkZHlQCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PQoiSW1hZ2luYXRpb24gaXMgbW9yZSBpbXBvcnRhbnQgdGhhbiBrbm93bGVkZ2Ui
IEEuRWluc3RlaW4K
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Sven Luther @ 2006-05-26 16:01 UTC (permalink / raw)
To: Mark Lord
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <447722FF.9020202@rtr.ca>
On Fri, May 26, 2006 at 11:47:11AM -0400, Mark Lord wrote:
> Sven Luther wrote:
> >On Fri, May 26, 2006 at 09:19:33AM -0400, Mark Lord wrote:
> >>Sven Luther wrote:
> >>>Ok. can i use this tree with a 2.6.16 base ?
> >>Not as-is. Here (attached) is a patch for 2.6.16.17+ that updates
> >>the sata_mv driver to the latest source. Completely untested,
> >>but it does compile.
> >>
> >>I will hopefully test it later today, but in the meanwhile, have a go at
> >>it.
> >
> >And here is attached my dmesg output. The last bit of mv_host_intr was
> >when i
> >tried to access the partition table of the disk with parted.
>
> I don't see anything particularly bad in that dmesg output,
> apart from all of the debug output --> did you enable that,
> or was it "on" by default?
Ah, yes, i enabled it on Jeff's suggestion.
> It finds one SATA drive, with no *known* partition table format.
Well, it is a blank disk indeed, so this is no suprise.
> Can you access the disk? Eg. hexdump -C /dev/sda
Trying to partition the disk with parted yielded the last set of debug
messages, and a :
Error: Unable to open /dev/sda - unrecognized disk label.
The same when trying to write a partition table to it, and naturally, there is
no partition afterward.
hexdump yielded only the debugmessages and nothing else.
> Meanwhile, I just booted 2.6.17-rc5-git1 (latest kernel.org) on my Mac G3
> box here, and sata_mv seems to be behaving for me (thus far).
Mmm, this is a G3, while i have a G4. The G4 does some I/O reordering, which
we don't have with a G3, so this may be the cause.
Do you have a mac version of the board, with a forth/OF bios in it ? Or a
normal PC card, which is thus uninitialized ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Sven Luther @ 2006-05-26 16:15 UTC (permalink / raw)
To: Sven Luther
Cc: Alexandre.Bounine, linuxppc-dev list, Yang Xin-Xin-r48390,
linux-kernel, linux-ide, Paul Mackerras, Mark Lord, Jeff Garzik
In-Reply-To: <20060526160156.GA11778@powerlinux.fr>
On Fri, May 26, 2006 at 06:01:56PM +0200, Sven Luther wrote:
> > Can you access the disk? Eg. hexdump -C /dev/sda
>
> Trying to partition the disk with parted yielded the last set of debug
> messages, and a :
Interesting. Using dd, i am able to write some stuff to disk :
dd if=/dev/sda of=/tmp/blah count=1 -> hexdump /tmp/blah yields only 0s.
dd if=/dev/random of=/dev/sda count=4 (count = 4, because /dev/random outputs blocks of 128 bytes)
dd if=/dev/sda of=/tmp/blah count=1 -> hexdump /tmp/blah yield random non-0 content
Trying to write past the first block, seems to freeze the disk or someting, at
least dd doesn't come back without me ctr-c'ing it.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Mark Lord @ 2006-05-26 16:21 UTC (permalink / raw)
To: Sven Luther
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <20060526160156.GA11778@powerlinux.fr>
Sven Luther wrote:
> On Fri, May 26, 2006 at 11:47:11AM -0400, Mark Lord wrote:
>
>> Meanwhile, I just booted 2.6.17-rc5-git1 (latest kernel.org) on my Mac G3
>> box here, and sata_mv seems to be behaving for me (thus far).
>
> Mmm, this is a G3, while i have a G4. The G4 does some I/O reordering, which
> we don't have with a G3, so this may be the cause.
MMmm.. is your G4 using a 64-bit kernel, or a 32-bit kernel?
The driver is a complete unknown (for me, at least) on 64-bit systems,
as I don't have one (of any processor type) here yet.
> Do you have a mac version of the board, with a forth/OF bios in it ? Or a
> normal PC card, which is thus uninitialized ?
The board claims to be "mac" compatible, so it probably has an OF bios on it,
but I have not verified this yet.
Cheers
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Sven Luther @ 2006-05-26 16:25 UTC (permalink / raw)
To: Mark Lord
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <44772B10.7040300@rtr.ca>
On Fri, May 26, 2006 at 12:21:36PM -0400, Mark Lord wrote:
> Sven Luther wrote:
> >On Fri, May 26, 2006 at 11:47:11AM -0400, Mark Lord wrote:
> >
> >>Meanwhile, I just booted 2.6.17-rc5-git1 (latest kernel.org) on my Mac G3
> >>box here, and sata_mv seems to be behaving for me (thus far).
> >
> >Mmm, this is a G3, while i have a G4. The G4 does some I/O reordering,
> >which
> >we don't have with a G3, so this may be the cause.
>
> MMmm.. is your G4 using a 64-bit kernel, or a 32-bit kernel?
Ah, no, the G4 is a 32bit processor.
> The driver is a complete unknown (for me, at least) on 64-bit systems,
> as I don't have one (of any processor type) here yet.
I have an Xserve G5, which is a 64bit powerpc machine, and i could try it in
it. I need to get the fans to a usable level first though, as it sounds like
an airplan, and is sitting right beside my desk.
> >Do you have a mac version of the board, with a forth/OF bios in it ? Or a
> >normal PC card, which is thus uninitialized ?
>
> The board claims to be "mac" compatible, so it probably has an OF bios on
> it, but I have not verified this yet.
Yes, probably. This could mean that the board gets initialized for you, but
not for me.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)
From: Andrew Morton @ 2006-05-26 16:49 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060526151214.GA5190@skynet.ie>
mel@csn.ul.ie (Mel Gorman) wrote:
>
> (Resending with Andrew's email address correct this time)
>
> For the last few -mm releases, kernels built for an old RS6000 failed to
> compile with the message;
>
> arch/powerpc/kernel/built-in.o(.init.text+0x77b4): In function `vrsqrtefp':
> : undefined reference to `__udivdi3'
> arch/powerpc/kernel/built-in.o(.init.text+0x7800): In function `vrsqrtefp':
> : undefined reference to `__udivdi3'
> make: *** [.tmp_vmlinux1] Error 1
A function with a name like that doesn't _deserve_ to compile.
But actually vrsqrtefp() doesn't call __udivdi3 - the error lies somewhere
else in the kernel and the toolchain gets it wrong, so we don't know where.
The way I usually hunt this problem down is to build the .s files (make
arch/powerpc/kernel/foo.s) and then grep around, find the offending C
function.
If the problem is specific to powerpc then a
diffstat 2.6.17.rc4-mm3 | grep powerpc
will narrow down the number of files to be searched by rather a lot.
> 2.6.17-rc5 is not affected but I didn't search for the culprit patch in
> -mm. The following patch adds an implementation of __udivdi3 for plain old
> ppc32. This may not be the correct fix as Google tells me that __udivdi3
> has been replaced by calls to do_div() in a number of cases. There was no
> obvious way to do that for vrsqrtefp, hence this workaround. The patch should
> be acked, rejected or replaced by a ppc expert.
Yes, we've traditionally avoided adding the 64-bit divide library functions.
^ permalink raw reply
* Re: [PATCH, 2.6.17-rc4-git10] ieee80211softmac_io.c: fix warning "defined but not used"
From: John W. Linville @ 2006-05-26 19:24 UTC (permalink / raw)
To: Toralf Förster; +Cc: netdev, linuxppc-dev
In-Reply-To: <200605231549.43430.toralf.foerster@gmx.de>
On Tue, May 23, 2006 at 03:49:40PM +0200, Toralf Förster wrote:
> Got this compiler warning today and Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Yeah, known 'bug', we have that code there but never use it. Feel free
> to submit a patch (to John Linville, CC netdev and softmac-dev) to
> remove it.
>
> Signed-off-by: Toralf Foerster <toralf.foerster@gmx.de>
This patch is whitespace-damaged. Please teach your mailer not to
convert tabs to spaces and resubmit.
Thanks!
John
> --- linux-2.6.17-rc4-git10-pcie-rme9652/net/ieee80211/softmac/ieee80211softmac_io.c.old 2006-05-12 09:44:47.000000000 +0200
> +++ linux-2.6.17-rc4-git10-pcie-rme9652/net/ieee80211/softmac/ieee80211softmac_io.c 2006-05-23 15:16:38.000000000 +0200
> @@ -456,31 +456,3 @@
> return IEEE80211_2ADDR_LEN;
> }
>
> -
> -/* Sends a control packet */
> -static int
> -ieee80211softmac_send_ctl_frame(struct ieee80211softmac_device *mac,
> - struct ieee80211softmac_network *net, u32 type, u32 arg)
> -{
> - void *pkt = NULL;
> - u32 pkt_size = 0;
<snip>
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [openib-general] [PATCH 06/16] ehca: interrupt handling routines
From: Roland Dreier @ 2006-05-26 20:06 UTC (permalink / raw)
To: Heiko J Schick
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <4468BD63.6070509@de.ibm.com>
> + for_each_online_cpu(cpu) {
> + task = create_comp_task(pool, cpu);
> + if (task) {
> + kthread_bind(task, cpu);
> + wake_up_process(task);
> + }
> + }
How does this creation of a thread pool work with respect to CPU
hotplug? What happens if a CPU goes away? How about if only one CPU
is running when the driver is loaded, and then 15 more are hot-added?
> + for (i = 0; i < NR_CPUS; i++) {
> + if (cpu_online(i))
> + destroy_comp_task(pool, i);
> + }
And it seems in the destroy function, you will possibly leak threads
or try to kill a non-existent thread if the set of online CPUs has
changed since the driver started...
- R.
^ permalink raw reply
* 440gx dma transfer with no data change at dest
From: John Lange @ 2006-05-26 20:58 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 401 bytes --]
Hi Kevin
I saw a posting from March where you were asking about problems doing
memory to memory DMA transfers with the ppc4xx_dma module of Linux. I'm
curious if you figured out that issue. Would you be kind enough to
share how you fixed the issue you were having? I would sure appreciate
a snippet of working example code if it's not proprietary.
Best regards,
John
[-- Attachment #2: Type: text/html, Size: 2267 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox