RE: [PATCH] fsl-rio: fix compile error
Yes, I'm afraid srio was not enabled when you compiled. Regards, Liu Gang -Original Message- From: Paul Gortmaker [mailto:paul.gortma...@windriver.com] Sent: Friday, November 11, 2011 11:48 PM To: Liu Gang-B34182 Cc: linuxppc-dev@lists.ozlabs.org; alexandre.boun...@idt.com; a...@linux-foundation.org; linux-ker...@vger.kernel.org; Li Yang-R58472; Gala Kumar-B11780; Zang Roy-R61911 Subject: Re: [PATCH] fsl-rio: fix compile error On 11-11-11 08:48 AM, Liu Gang wrote: > The "#include " was replaced by "#include " > in the patch "powerpc: various straight conversions from module.h --> > export.h". > This will cause the following compile problem: > arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception': > arch/powerpc/sysdev/fsl_rio.c:296: error: implicit declaration of function > 'search_exception_tables'. > > The file fsl_rio.c needs the declaration of function "search_exception_tables" > in the header file "linux/module.h". Thanks -- not sure why this never showed up in my builds of all the powerpc configs, _or_ the linux-next builds. Maybe srio isn't enabled in any of them? In any case it looks fine to me. Having the search_exception_tables live in module.h seems odd, but that is an independent issue for later. I can queue this unless someone else has already done so. Paul. > > Signed-off-by: Liu Gang > --- > arch/powerpc/sysdev/fsl_rio.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/powerpc/sysdev/fsl_rio.c > b/arch/powerpc/sysdev/fsl_rio.c index de170fd..22ffccd 100644 > --- a/arch/powerpc/sysdev/fsl_rio.c > +++ b/arch/powerpc/sysdev/fsl_rio.c > @@ -23,7 +23,7 @@ > */ > > #include > -#include > +#include > #include > #include > #include ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc kvm: fix kvmppc_start_thread() for CONFIG_SMP=N
In message <4ebd46f4.5040...@suse.de> you wrote: > On 11/11/2011 03:03 AM, Michael Neuling wrote: > > Currently kvmppc_start_thread() tries to wake other SMT threads via > > xics_wake_cpu(). Unfortunately xics_wake_cpu only exists when > > CONFIG_SMP=Y so when compiling with CONFIG_SMP=N we get: > > > >arch/powerpc/kvm/built-in.o: In function `.kvmppc_start_thread': > >book3s_hv.c:(.text+0xa1e0): undefined reference to `.xics_wake_cpu' > > > > The following should be fine since kvmppc_start_thread() shouldn't > > called to start non-zero threads when SMP=N since threads_per_core=1. > > > > Signed-off-by: Michael Neuling > > Thanks, applied to kvm-ppc-next. Please CC kvm-ppc@vger next time :). Thanks will do. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
AUTO: Michael Barry is out of the office (returning 15/11/2011)
I am out of the office until 15/11/2011. Note: This is an automated response to your message "Linuxppc-dev Digest, Vol 87, Issue 74" sent on 12/11/2011 1:00:02. This is the only notification you will receive while this person is away. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Disabling TCP slow start after idle
Hi David, On Fri, 11 Nov 2011 15:30:23 - "David Laight" wrote: > > We have some connections that suffer very badly from the TCP > 'slow start' algorithm. These are connections that will > always be local - they may be MAC-Switch-MAC using RGMII > crossover, they might also be connected via an external > switch. In either case the RTT is most likely to be almost > zero, certainly below 1ms. You would be better off asking networking questions on netdev at vger.kernel.org ... -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgplAPTcbUlop.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] fsl-rio: fix compile error
On Fri, Nov 11, 2011 at 8:48 AM Liu Gang wrote: > Sent: Friday, November 11, 2011 8:48 AM > To: linuxppc-dev@lists.ozlabs.org; Bounine, Alexandre > Cc: a...@linux-foundation.org; linux-ker...@vger.kernel.org; > paul.gortma...@windriver.com; r58...@freescale.com; > b11...@freescale.com; r61...@freescale.com; Liu Gang > Subject: [PATCH] fsl-rio: fix compile error > > The "#include " was replaced by "#include > " > in the patch "powerpc: various straight conversions from module.h --> > export.h". > This will cause the following compile problem: > arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception': > arch/powerpc/sysdev/fsl_rio.c:296: error: implicit declaration of > function 'search_exception_tables'. > > The file fsl_rio.c needs the declaration of function > "search_exception_tables" > in the header file "linux/module.h". > > Signed-off-by: Liu Gang > --- > arch/powerpc/sysdev/fsl_rio.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/powerpc/sysdev/fsl_rio.c > b/arch/powerpc/sysdev/fsl_rio.c > index de170fd..22ffccd 100644 > --- a/arch/powerpc/sysdev/fsl_rio.c > +++ b/arch/powerpc/sysdev/fsl_rio.c > @@ -23,7 +23,7 @@ > */ > > #include > -#include > +#include > #include > #include > #include > -- > 1.7.3.1 > Acked-by: Alexandre Bounine ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] P1021: set IReady in QE Microcode Upload
Kokoris, Ioannis wrote: > Hi, > > QE Microcode Initialization using qe_upload_microcode() does not work > on P1021 if the IRAM-Ready register is not set after the microcode > upload. This patch adds a definition for the "I-RAM Ready" register and > sets it uppon microcode upload completion. Will this code still work on other QE parts, like the MPC8323? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Friday, November 11, 2011 12:23 PM
> To: Zhao Chenhui-B35336
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
>
> On Fri, 2011-11-04 at 20:31 +0800, Zhao Chenhui wrote:
>
> > #ifdef CONFIG_SMP
> > /* When we get here, r24 needs to hold the CPU # */
> > .globl __secondary_start
> > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> > index 7bf2187..12a54f0 100644
> > --- a/arch/powerpc/kernel/smp.c
> > +++ b/arch/powerpc/kernel/smp.c
> > @@ -381,8 +381,14 @@ void generic_cpu_die(unsigned int cpu)
> >
> > for (i = 0; i < 100; i++) {
> > smp_rmb();
> > - if (per_cpu(cpu_state, cpu) == CPU_DEAD)
> > + if (per_cpu(cpu_state, cpu) == CPU_DEAD) {
> > + /*
> > +* After another core sets cpu_state to CPU_DEAD,
> > +* it needs some time to die.
> > +*/
> > + msleep(10);
> > return;
> > + }
> > msleep(100);
> > }
> > printk(KERN_ERR "CPU%d didn't die...\n", cpu);
>
> I don't really see why you need to wait. This loop is about waiting for
> the CPU to mark itself DEAD, not necessarily to be physically powered
> off.
>
If I don't add this delay, the kernel hangs sometimes when hotpluging a core.
I will move this function to 85xx/smp.c in the next revision.
> > +struct epapr_entry {
> > + u32 addr_h;
> > + u32 addr_l;
> > + u32 r3_h;
> > + u32 r3_l;
> > + u32 reserved;
> > + u32 pir;
> > + u32 r6_h;
> > + u32 r6_l;
> > +};
>
> This should probably be in a generic location.
>
> > +static int is_corenet;
>
> This global is a bit gross...
>
> ...
Agree. I will remove it.
>
> > +
> > +static void __cpuinit smp_85xx_reset_core(int nr)
> > +{
> > + __iomem u32 *vaddr, *pir_vaddr;
> > + u32 val, cpu_mask;
> > +
> > + /* If CoreNet platform, use BRR as release register. */
> > + if (is_corenet) {
> > + cpu_mask = 1 << nr;
> > + vaddr = ioremap(get_immrbase() + MPC85xx_BRR_OFF, 4);
> > + } else {
> > + cpu_mask = 1 << (24 + nr);
> > + vaddr = ioremap(get_immrbase() + MPC85xx_ECM_EEBPCR_OFF, 4);
> > + }
>
> Instead, can't you instead have two functions using a common helper and
> pick/hook the right one ?
>
> Also in what context is that reset_core() called ? Doing ioremap isn't
> something you can do at any random time...
>
> Cheers,
> Ben.
>
>
Thanks. I will fix them.
-chenhui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] P1021: set IReady in QE Microcode Upload
Hi,
QE Microcode Initialization using qe_upload_microcode() does not work on P1021
if the IRAM-Ready register is not set after the microcode upload. This patch
adds a definition for the "I-RAM Ready" register and sets it uppon microcode
upload completion.
Signed-off-by: Ioannis Kokkoris
diff -Nru a/arch/powerpc/include/asm/immap_qe.h
b/arch/powerpc/include/asm/immap_qe.h
--- a/arch/powerpc/include/asm/immap_qe.h 2011-11-11 17:47:45.0
+0200
+++ b/arch/powerpc/include/asm/immap_qe.h 2011-11-11 17:49:31.0
+0200
@@ -26,7 +26,9 @@
struct qe_iram {
__be32 iadd; /* I-RAM Address Register */
__be32 idata; /* I-RAM Data Register */
- u8 res0[0x78];
+ u8 res0[0x04];
+ __be32 iready; /* I-RAM Ready Register */
+ u8 res1[0x70];
} __attribute__ ((packed));
/* QE Interrupt Controller */
diff -Nru a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
--- a/arch/powerpc/include/asm/qe.h 2011-11-11 17:47:57.0 +0200
+++ b/arch/powerpc/include/asm/qe.h 2011-11-11 17:49:42.0 +0200
@@ -499,6 +499,7 @@
/* I-RAM */
#define QE_IRAM_IADD_AIE 0x8000 /* Auto Increment Enable */
#define QE_IRAM_IADD_BADDR 0x0008 /* Base Address */
+#define QE_IRAM_READY 0x8000 /* Ready */
/* UPC */
#define UPGCR_PROTOCOL 0x8000 /* protocol ul2 or pl2 */
diff -Nru a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
--- a/arch/powerpc/sysdev/qe_lib/qe.c 2011-11-11 17:48:44.0 +0200
+++ b/arch/powerpc/sysdev/qe_lib/qe.c 2011-11-11 17:49:59.0 +0200
@@ -377,6 +377,9 @@
for (i = 0; i < be32_to_cpu(ucode->count); i++)
out_be32(&qe_immr->iram.idata, be32_to_cpu(code[i]));
+
+ /* Set I-RAM Ready Register */
+ out_be32(&qe_immr->iram.iready, be32_to_cpu(QE_IRAM_READY));
}
/*
--
Best Regards,
Ioannis
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: move compute_tlbie_rb to book3s_64 common header
On 11/08/2011 06:08 PM, Andreas Schwab wrote: compute_tlbie_rb is only used on ppc64 and cannot be compiled on ppc32. Signed-off-by: Andreas Schwab Thanks, applied to kvm-ppc-next. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: protect use of kvmppc_h_pr
On 11/08/2011 06:17 PM, Andreas Schwab wrote: kvmppc_h_pr is only available if CONFIG_KVM_BOOK3S_64_PR. Signed-off-by: Andreas Schwab Thanks, applied to kvm-ppc-next. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc kvm: fix kvmppc_start_thread() for CONFIG_SMP=N
On 11/11/2011 03:03 AM, Michael Neuling wrote: Currently kvmppc_start_thread() tries to wake other SMT threads via xics_wake_cpu(). Unfortunately xics_wake_cpu only exists when CONFIG_SMP=Y so when compiling with CONFIG_SMP=N we get: arch/powerpc/kvm/built-in.o: In function `.kvmppc_start_thread': book3s_hv.c:(.text+0xa1e0): undefined reference to `.xics_wake_cpu' The following should be fine since kvmppc_start_thread() shouldn't called to start non-zero threads when SMP=N since threads_per_core=1. Signed-off-by: Michael Neuling Thanks, applied to kvm-ppc-next. Please CC kvm-ppc@vger next time :). Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] fsl-rio: fix compile error
On 11-11-11 08:48 AM, Liu Gang wrote: > The "#include " was replaced by "#include " > in the patch "powerpc: various straight conversions from module.h --> > export.h". > This will cause the following compile problem: > arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception': > arch/powerpc/sysdev/fsl_rio.c:296: error: implicit declaration of function > 'search_exception_tables'. > > The file fsl_rio.c needs the declaration of function "search_exception_tables" > in the header file "linux/module.h". Thanks -- not sure why this never showed up in my builds of all the powerpc configs, _or_ the linux-next builds. Maybe srio isn't enabled in any of them? In any case it looks fine to me. Having the search_exception_tables live in module.h seems odd, but that is an independent issue for later. I can queue this unless someone else has already done so. Paul. > > Signed-off-by: Liu Gang > --- > arch/powerpc/sysdev/fsl_rio.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c > index de170fd..22ffccd 100644 > --- a/arch/powerpc/sysdev/fsl_rio.c > +++ b/arch/powerpc/sysdev/fsl_rio.c > @@ -23,7 +23,7 @@ > */ > > #include > -#include > +#include > #include > #include > #include ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Disabling TCP slow start after idle
We have some connections that suffer very badly from the TCP 'slow start' algorithm. These are connections that will always be local - they may be MAC-Switch-MAC using RGMII crossover, they might also be connected via an external switch. In either case the RTT is most likely to be almost zero, certainly below 1ms. The traffic is single packets (carrying another protocol) so we have Nagle disabled and the send and receive sides run separately. So the traffic is neither bulk, nor command/response. This means that there is very rarely any unacked data, so almost every packet is sent using 'slow start'. If the external switch drops a packet (they do!) then slow start stops more packets being sent, and nothing progresses for about 1.5 seconds by which time there is a significant amount of traffic queued and, in some cases, data has to be discarded. Similar issues happen if the receiving system decides to defer the ack until a timer tick (instead of sending one after every second packet). In this case only 4 packets are sent. (We fixed this one be sending a software ACK every 4 packets.) Quite cleary the 'slow start' algorithm just doesn't work in these cases. I found this https://lkml.org/lkml/2010/4/9/427 discussion about a socket option to disable slow start. But it seems that some people are completely against the idea. I'd have thought that the global option would be more of a problem - since that will affect ftp connections to remote hosts where slow start is alomost certainly benefitial. I'd have thought it would be sensible to allow one (or more) of the following (either as a sysctl, socket option, or code change): 1) Disable slow start for the local subnet. 2) Disable slow start for connections with very low RTT. 3) Disable slow start for a minimum period with no traffic (after the last packet is acked). I'm not sure of the resolution used by the Linux RTT calculations. I know NetBSD had a recent set of patches to fix calculation errors with low RTT because the code had been written when all RTT were much longer. David (Copied to linuxppc-dev because I'm subscribed to it.) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH 08/30] powerpc/85xx: Rework P1020 SoC device tree
On Thu, Nov 10, 2011 at 02:27:11PM -0600, Kumar Gala wrote: > On Nov 10, 2011, at 12:58 PM, Scott Wood wrote: > > On Thu, Nov 10, 2011 at 12:46:27PM -0600, Kumar Gala wrote: > >> On Nov 10, 2011, at 12:05 PM, Scott Wood wrote: > >>> What does the SoC part need to specify that has to override or go within > >>> something the board specifies? > >> > >> Not sure I follow the question. > > > > My question is, why does the stuff in post need to be in post, versus pre? > > > > Why can't pre define the soc node, and let the board dts set ranges? > > Likewise for localbus, pci, etc. > > > > -Scott > > Gotcha, the reason we have -pre and -post is because of how dtc include > mechanism works. It builds it's tree in the order things are parsed in > the file. That doesn't really answer the question. > In addition, "labeled nodes" like we have in post for 'soc', 'lbc', > etc. have to be defined after they are referenced. Don't you mean defined before they are referenced? What's wrong with defining them in pre? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] fsl-rio: fix compile error
The "#include " was replaced by "#include " in the patch "powerpc: various straight conversions from module.h --> export.h". This will cause the following compile problem: arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception': arch/powerpc/sysdev/fsl_rio.c:296: error: implicit declaration of function 'search_exception_tables'. The file fsl_rio.c needs the declaration of function "search_exception_tables" in the header file "linux/module.h". Signed-off-by: Liu Gang --- arch/powerpc/sysdev/fsl_rio.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c index de170fd..22ffccd 100644 --- a/arch/powerpc/sysdev/fsl_rio.c +++ b/arch/powerpc/sysdev/fsl_rio.c @@ -23,7 +23,7 @@ */ #include -#include +#include #include #include #include -- 1.7.3.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 02/17] powerpc: Split up PHYS_64BIT config option to fix "select" issues
Benjamin Herrenschmidt wrote: > For PHYS_64BIT, I'm not 100% certain at this point what the best > approach it. It should clearly be fixed and hidden for real 64-bit. As > for the rest, should it be user selectable ? I have been unable to convince our BSP teams that the minor performance improvement of a 32-bit kernel vs 36-bit is not worth the hassle. We ship a lot of lower-end e500 systems that will never have more than 2GB of memory. The P1022DS is an example. We ship 32-bit and 36-bit versions of U-Boot, the kernel, and the device tree. I recently added code to U-boot to detect if you have a mismatched U-Boot and device tree, because it is so easy to mess that up. I would like nothing more than to abandon 32-bit for all e500, but I don't see Freescale allowing that any time soon. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] usb/fsl_udc: fix dequeuing a request in progress
The original implementation of dequeuing a request in progress
is not correct. Change to use a correct process and also clean
up the related functions a little bit.
Signed-off-by: Li Yang
---
drivers/usb/gadget/fsl_udc_core.c | 62 +---
1 files changed, 29 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index b2c44e1..beef9b7 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -696,12 +696,31 @@ static void fsl_free_request(struct usb_ep *_ep, struct
usb_request *_req)
kfree(req);
}
-/*-*/
+/* Actually add a dTD chain to an empty dQH and let go */
+static void fsl_prime_ep(struct fsl_ep *ep, struct ep_td_struct *td)
+{
+ struct ep_queue_head *qh = ep->qh;
+
+ /* Write dQH next pointer and terminate bit to 0 */
+ qh->next_dtd_ptr = cpu_to_hc32(td->td_dma
+ & EP_QUEUE_HEAD_NEXT_POINTER_MASK);
+
+ /* Clear active and halt bit */
+ qh->size_ioc_int_sts &= cpu_to_hc32(~(EP_QUEUE_HEAD_STATUS_ACTIVE
+ | EP_QUEUE_HEAD_STATUS_HALT));
+
+ /* Ensure that updates to the QH will occur before priming. */
+ wmb();
+
+ /* Prime endpoint by writing correct bit to ENDPTPRIME */
+ fsl_writel(ep_is_in(ep) ? (1 << (ep_index(ep) + 16))
+ : (1 << (ep_index(ep))), &dr_regs->endpointprime);
+}
+
+/* Add dTD chain to the dQH of an EP */
static void fsl_queue_td(struct fsl_ep *ep, struct fsl_req *req)
{
- int i = ep_index(ep) * 2 + ep_is_in(ep);
u32 temp, bitmask, tmp_stat;
- struct ep_queue_head *dQH = &ep->udc->ep_qh[i];
/* VDBG("QH addr Register 0x%8x", dr_regs->endpointlistaddr);
VDBG("ep_qh[%d] addr is 0x%8x", i, (u32)&(ep->udc->ep_qh[i])); */
@@ -719,7 +738,7 @@ static void fsl_queue_td(struct fsl_ep *ep, struct fsl_req
*req)
cpu_to_hc32(req->head->td_dma & DTD_ADDR_MASK);
/* Read prime bit, if 1 goto done */
if (fsl_readl(&dr_regs->endpointprime) & bitmask)
- goto out;
+ return;
do {
/* Set ATDTW bit in USBCMD */
@@ -736,28 +755,10 @@ static void fsl_queue_td(struct fsl_ep *ep, struct
fsl_req *req)
fsl_writel(temp & ~USB_CMD_ATDTW, &dr_regs->usbcmd);
if (tmp_stat)
- goto out;
+ return;
}
- /* Write dQH next pointer and terminate bit to 0 */
- temp = req->head->td_dma & EP_QUEUE_HEAD_NEXT_POINTER_MASK;
- dQH->next_dtd_ptr = cpu_to_hc32(temp);
-
- /* Clear active and halt bit */
- temp = cpu_to_hc32(~(EP_QUEUE_HEAD_STATUS_ACTIVE
- | EP_QUEUE_HEAD_STATUS_HALT));
- dQH->size_ioc_int_sts &= temp;
-
- /* Ensure that updates to the QH will occur before priming. */
- wmb();
-
- /* Prime endpoint by writing 1 to ENDPTPRIME */
- temp = ep_is_in(ep)
- ? (1 << (ep_index(ep) + 16))
- : (1 << (ep_index(ep)));
- fsl_writel(temp, &dr_regs->endpointprime);
-out:
- return;
+ fsl_prime_ep(ep, req->head);
}
/* Fill in the dTD structure
@@ -973,25 +974,20 @@ static int fsl_ep_dequeue(struct usb_ep *_ep, struct
usb_request *_req)
/* The request isn't the last request in this ep queue */
if (req->queue.next != &ep->queue) {
- struct ep_queue_head *qh;
struct fsl_req *next_req;
- qh = ep->qh;
next_req = list_entry(req->queue.next, struct fsl_req,
queue);
- /* Point the QH to the first TD of next request */
- fsl_writel((u32) next_req->head, &qh->curr_dtd_ptr);
+ /* prime with dTD of next request */
+ fsl_prime_ep(ep, next_req->head);
}
-
- /* The request hasn't been processed, patch up the TD chain */
+ /* The request hasn't been processed, patch up the TD chain */
} else {
struct fsl_req *prev_req;
prev_req = list_entry(req->queue.prev, struct fsl_req, queue);
- fsl_writel(fsl_readl(&req->tail->next_td_ptr),
- &prev_req->tail->next_td_ptr);
-
+ prev_req->tail->next_td_ptr = req->tail->next_td_ptr;
}
done(ep, req, -ECONNRESET);
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
