LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 2/3] mtd/nand : set Nand flash page address to FBAR and FPAR correctly
From: Artem Bityutskiy @ 2011-11-22 21:05 UTC (permalink / raw)
  To: LiuShuo
  Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, Tang Yuantian,
	linux-mtd, Jerry Huang, scottwood, akpm, dwmw2
In-Reply-To: <4EC5BE16.9080205@freescale.com>

On Fri, 2011-11-18 at 10:08 +0800, LiuShuo wrote:
> Ok and I want to add another patch before 3/3.
> 
> -LiuShuo
> > On Tue, 2011-11-15 at 17:29 +0800, b35362@freescale.com wrote:
> >> From: Liu Shuo<b35362@freescale.com>
> >>
> >> If we use the Nand flash chip whose number of pages in a block is greater
> >> than 64(for large page), we must treat the low bit of FBAR as being the
> >> high bit of the page address due to the limitation of FCM, it simply uses
> >> the low 6-bits (for large page) of the combined block/page address as the
> >> FPAR component, rather than considering the actual block size.
> > Looks like this patch depends on the previous white-space clean-up patch
> > - could you please refactor it (and 3/3 too) and resend?
> Ok and I am going to add another new patch before 3/3.

Sure, send 3/3 as well because this one depends on the cleanup patch, so
cannot be applied independently.

Artem.

^ permalink raw reply

* Re: [PATCH v3 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Artem Bityutskiy @ 2011-11-22 21:04 UTC (permalink / raw)
  To: b35362
  Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, Liu Shuo,
	Shengzhou Liu, linux-mtd, scottwood, akpm, dwmw2
In-Reply-To: <1321349355-1639-3-git-send-email-b35362@freescale.com>

On Tue, 2011-11-15 at 17:29 +0800, b35362@freescale.com wrote:
> +               /*
> +                * Freescale FCM controller has a 2K size limitation of buffer
> +                * RAM, so elbc_fcm_ctrl->buffer have to be used if writesize
> +                * of chip is greater than 2048.
> +                * We malloc a large enough buffer at this point, because we
> +                * don't know writesize before calling nand_scan(). We will
> +                * re-malloc later if needed.
> +                */
> +               elbc_fcm_ctrl->buffer = kmalloc(4096 * 6, GFP_KERNEL);
> +               if (!elbc_fcm_ctrl->buffer)
> +                       return -ENOMEM; 

Why 4096*6? Judging from the comment it should be 4096.

Artem.

^ permalink raw reply

* [PATCH] powerpc: Fix building ppc64 w/hugetlbfs enabled
From: Kumar Gala @ 2011-11-22 20:25 UTC (permalink / raw)
  To: linuxppc-dev

arch/powerpc/kernel/setup_64.c: In function 'early_setup':
arch/powerpc/kernel/setup_64.c:226:2: error: implicit declaration of function 'reserve_hugetlb_gpages'

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
 arch/powerpc/kernel/setup_64.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 66648cc..6a98051 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -65,6 +65,7 @@
 #include <asm/kexec.h>
 #include <asm/mmu_context.h>
 #include <asm/code-patching.h>
+#include <asm/hugetlb.h>
 
 #include "setup.h"
 
-- 
1.7.3.4

^ permalink raw reply related

* Re: [PATCH][RFC] fsldma: fix performance degradation by optimizing spinlock use.
From: Ira W. Snyder @ 2011-11-22 18:59 UTC (permalink / raw)
  To: b29237; +Cc: vinod.koul, linux-kernel, zw, dan.j.williams, linuxppc-dev
In-Reply-To: <1321937705-19587-1-git-send-email-b29237@freescale.com>

On Tue, Nov 22, 2011 at 12:55:05PM +0800, b29237@freescale.com wrote:
> From: Forrest Shi <b29237@freescale.com>
> 
>     dma status check function fsl_tx_status is heavily called in
>     a tight loop and the desc lock in fsl_tx_status contended by
>     the dma status update function. this caused the dma performance
>     degrades much.
> 
>     this patch releases the lock in the fsl_tx_status function.
>     I believe it has no neglect impact on the following call of
>     dma_async_is_complete(...).
> 
>     we can see below three conditions will be identified as success
>     a)  x < complete < use
>     b)  x < complete+N < use+N
>     c)  x < complete < use+N
>     here complete is the completed_cookie, use is the last_used
>     cookie, x is the querying cookie, N is MAX cookie
> 
>     when chan->completed_cookie is being read, the last_used may
>     be incresed. Anyway it has no neglect impact on the dma status
>     decision.
> 
>     Signed-off-by: Forrest Shi <xuelin.shi@freescale.com>
> ---
>  drivers/dma/fsldma.c |    5 -----
>  1 files changed, 0 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index 8a78154..1dca56f 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -986,15 +986,10 @@ static enum dma_status fsl_tx_status(struct dma_chan *dchan,
>  	struct fsldma_chan *chan = to_fsl_chan(dchan);
>  	dma_cookie_t last_complete;
>  	dma_cookie_t last_used;
> -	unsigned long flags;
> -
> -	spin_lock_irqsave(&chan->desc_lock, flags);
>  

This will cause a bug. See below for a detailed explanation. You need
this instead:

	/*
	 * On an SMP system, we must ensure that this CPU has seen the
	 * memory accesses performed by another CPU under the
	 * chan->desc_lock spinlock.
	 */
	smp_mb();
>  	last_complete = chan->completed_cookie;
>  	last_used = dchan->cookie;
>  
> -	spin_unlock_irqrestore(&chan->desc_lock, flags);
> -
>  	dma_set_tx_state(txstate, last_complete, last_used, 0);
>  	return dma_async_is_complete(cookie, last_complete, last_used);
>  }

Facts:
- dchan->cookie is the same member as chan->common.cookie (same memory location)
- chan->common.cookie is the "last allocated cookie for a pending transaction"
- chan->completed_cookie is the "last completed transaction"

I have replaced "dchan->cookie" with "chan->common.cookie" in the below
explanation, to keep everything referenced from the same structure.

Variable usage before your change. Everything is used locked.
- RW chan->common.cookie		(fsl_dma_tx_submit)
- R  chan->common.cookie		(fsl_tx_status)
- R  chan->completed_cookie		(fsl_tx_status)
- W  chan->completed_cookie		(dma_do_tasklet)

Variable usage after your change:
- RW chan->common.cookie		LOCKED
- R  chan->common.cookie		NO LOCK
- R  chan->completed_cookie		NO LOCK
- W  chan->completed_cookie             LOCKED

What if we assume that you have a 2 CPU system (such as a P2020). After
your changes, one possible sequence is:

=== CPU1 - allocate + submit descriptor: fsl_dma_tx_submit() ===
spin_lock_irqsave
descriptor->cookie = 20		(x in your example)
chan->common.cookie = 20	(used in your example)
spin_unlock_irqrestore

=== CPU2 - immediately calls fsl_tx_status() ===
chan->common.cookie == 19
chan->completed_cookie == 19
descriptor->cookie == 20

Since we don't have locks anymore, CPU2 may not have seen the write to
chan->common.cookie yet.

Also assume that the DMA hardware has not started processing the
transaction yet. Therefore dma_do_tasklet() has not been called, and
chan->completed_cookie has not been updated.

In this case, dma_async_is_complete() (on CPU2) returns DMA_SUCCESS,
even though the DMA operation has not succeeded. The DMA operation has
not even started yet!

The smp_mb() fixes this, since it forces CPU2 to have seen all memory
operations that happened before CPU1 released the spinlock. Spinlocks
are implicit SMP memory barriers.

Therefore, the above example becomes:
smp_mb();
chan->common.cookie == 20
chan->completed_cookie == 19
descriptor->cookie == 20

Then dma_async_is_complete() returns DMA_IN_PROGRESS, which is correct.

Thanks,
Ira

^ permalink raw reply

* Enabling MBX in MPC5121 - OGLES kernel modules
From: Einar Már Björgvinsson @ 2011-11-22 19:15 UTC (permalink / raw)
  To: linuxppc-dev@lists.ozlabs.org

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

Hi

I've been working on enabling the PowerVR GPU core in MPC5121 chip. I've been following the documentation from here:

http://www.datasheetarchive.com/indexdl/Datasheet-076/DSAE0026055.pdf

This documentation was released in a bundle with MBX libraries and MBX kernel patches. Also have I downloaded the OGLES SDK from Imgtech where I've successfully built some demos for MPC5121.

The last piece of the puzzle is to have the right kernel modules. There are some kernel modules provided in the documentation bundle but they are build against older kernel version (2.6.24) but I'm am using kernel version 2.6.33 with RT 29.

What I'm hoping is that somebody have the source code for the following kernel modules:

- pvr.ko
- clcdc.ko
- swcamera.ko
- dgbdrv.ko

Hope somebody out there can assist

Regards
Einar M. Bjorgvinsson
Embedded Software Engineer
Marel ehf
Iceland


[-- Attachment #2: Type: text/html, Size: 1495 bytes --]

^ permalink raw reply

* curious why mpc85xx/edac/pcie patch series was never picked up
From: Chris Friesen @ 2011-11-22 17:40 UTC (permalink / raw)
  To: linuxppc-dev, Paul Mackerras, Benjamin Herrenschmidt, b25806


We're doing some work with an mpc85xx-based board and someone pointed to 
a patch adding PCI/PCIE error interrupt edac support that was proposed 
by Lan Chunhe over a year ago:

http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-November/086930.html

For some reason this doesn't appear to have been picked up for mainline, 
and I'm curious why not--is there something wrong with it?

Thanks,
Chris

-- 
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com

^ permalink raw reply

* Re: [PATCH v2 1/7] powerpc/85xx: re-enable timebase sync disabled by KEXEC patch
From: Kumar Gala @ 2011-11-22 16:05 UTC (permalink / raw)
  To: Li Yang-R58472
  Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
	Zhao Chenhui-B35336
In-Reply-To: <3F607A5180246847A760FD34122A1E052D942C@039-SN1MPN1-003.039d.mgd.msft.net>


On Nov 22, 2011, at 3:29 AM, Li Yang-R58472 wrote:

>> Subject: Re: [PATCH v2 1/7] powerpc/85xx: re-enable timebase sync =
disabled
>> by KEXEC patch
>>=20
>> On Fri, Nov 18, 2011 at 08:35:02AM -0600, Kumar Gala wrote:
>>>=20
>>> On Nov 16, 2011, at 12:42 PM, Scott Wood wrote:
>>>=20
>>>> On 11/16/2011 03:55 AM, Zhao Chenhui wrote:
>>>>> From: Li Yang <leoli@freescale.com>
>>>>>=20
>>>>> The timebase sync is not only necessary when using KEXEC. It =
should
>> also
>>>>> be used by normal boot up and cpu hotplug. Remove the ifdef added =
by
>>>>> the KEXEC patch.
>>>>=20
>>>> Again, no it should not be used by normal boot up (whether KEXEC
>> support
>>>> is enabled or not).  We should only do timebase sync when we =
actually
>>>> need to (when we've actually just reset a core), and we should do =
it
>> the
>>>> way U-Boot does rather than with smp-tbsync.c.
>=20
> While looking into the timebase sync code in u-boot, I have a few =
questions.
>=20
>        /* enable time base at the platform */
>        if (whoami)
>                devdisr |=3D MPC85xx_DEVDISR_TB1;
>        else
>                devdisr |=3D MPC85xx_DEVDISR_TB0;
>        out_be32(&gur->devdisr, devdisr);
>=20
>        /* readback to sync write */
>        in_be32(&gur->devdisr);
>=20
>        mtspr(SPRN_TBWU, 0);
>        mtspr(SPRN_TBWL, 0);
>=20
> What are the TBWU/TBWL registers?  I can't find the definition of them =
in either e500 RM or booke RM.  Are they valid to be used?  What is the =
result of writing to them?  Aren't the SPR registers core specific?  How =
can we set the TB for the other cores?

TBWU/TBWL are SPR 284/285 (they might be called something a little =
different in the manual).

You can only set the TB on the core itself.  The way the u-boot code =
works is it sets TBL/TBU (TB) to 0 in release.S for secondary cores.  In =
the code you reference we are setting TB on the 'master' core to 0 since =
we turned TB on earlier for the master core and now are resetting it to =
0 to sync all the cores.

>=20
>        devdisr &=3D ~(MPC85xx_DEVDISR_TB0 | MPC85xx_DEVDISR_TB1);
>        out_be32(&gur->devdisr, devdisr);
>=20
> Also in the UM, I read "Blocks disabled by DEVDISR must not be =
re-enabled without a hard reset."  Is it safe we enable it here?

Yes this is safe, TB isn't truly a block.  Manual should technically be =
updated to exclude TB.

- k=

^ permalink raw reply

* Re: powerpc: dts: Fix canyonlands EMAC interrupt map
From: Josh Boyer @ 2011-11-22 14:31 UTC (permalink / raw)
  To: Tanmay Inamdar; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <CACoXjc=RBpB6eYu1zB-kCcYmsV8rdbzYtdxyBJDLTdt6uu04ig@mail.gmail.com>

On Tue, Nov 22, 2011 at 9:15 AM, Tanmay Inamdar <tinamdar@apm.com> wrote:
>
> On Tue, Nov 22, 2011 at 5:00 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>>
>> On Tue, Nov 22, 2011 at 2:11 AM, Tanmay Inamdar <tinamdar@apm.com> wrote=
:
>> > Fixing interrupt mapping of EMAC for canyonlands
>> >
>> > Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
>>
>> As far as I can tell, your changes aren't really changing anything
>> just making it a bit clearer, correct? =A0If so, do you mind if I change
>> the commit log to "clear up" instead of fix?
>
> Actually Rob Herring's commit
> (http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dcommi=
t;h=3Ddc9372808412edbc653a675a526c2ee6c0c14a91)
> breaks the interrupt mapping in EMAC driver.
> I am trying to fix this issue by mapping interrupts in different way.

I see.  That should have been in the commit log then.  I'll add
something like that to it.

josh

^ permalink raw reply

* Re: powerpc: dts: Fix canyonlands EMAC interrupt map
From: Tanmay Inamdar @ 2011-11-22 14:15 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <CA+5PVA7BD9jNoV9LrXjk2+UPBW8MSTPkwpYPFj2y-CNkXCrAhA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4224 bytes --]

On Tue, Nov 22, 2011 at 5:00 PM, Josh Boyer <jwboyer@gmail.com> wrote:

> On Tue, Nov 22, 2011 at 2:11 AM, Tanmay Inamdar <tinamdar@apm.com> wrote:
> > Fixing interrupt mapping of EMAC for canyonlands
> >
> > Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
>
> As far as I can tell, your changes aren't really changing anything
> just making it a bit clearer, correct?  If so, do you mind if I change
> the commit log to "clear up" instead of fix?
>

Actually Rob Herring's commit (
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=dc9372808412edbc653a675a526c2ee6c0c14a91)
breaks the interrupt mapping in EMAC driver.
I am trying to fix this issue by mapping interrupts in different way.

If you think "clear up" is fine, then please go ahead.

Thanks,
Tanmay

>
> josh
>
> > ---
> >  arch/powerpc/boot/dts/canyonlands.dts |   16 ++++++----------
> >  1 files changed, 6 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/canyonlands.dts
> b/arch/powerpc/boot/dts/canyonlands.dts
> > index 3dc75de..c76bbcd 100644
> > --- a/arch/powerpc/boot/dts/canyonlands.dts
> > +++ b/arch/powerpc/boot/dts/canyonlands.dts
> > @@ -360,13 +360,11 @@
> >                        EMAC0: ethernet@ef600e00 {
> >                                device_type = "network";
> >                                compatible = "ibm,emac-460ex",
> "ibm,emac4sync";
> > -                               interrupt-parent = <&EMAC0>;
> > -                               interrupts = <0x0 0x1>;
> > -                               #interrupt-cells = <1>;
> > +                               interrupt-parent = <&UIC2>;
> >                                #address-cells = <0>;
> >                                #size-cells = <0>;
> > -                               interrupt-map = </*Status*/ 0x0 &UIC2
> 0x10 0x4
> > -                                                /*Wake*/   0x1 &UIC2
> 0x14 0x4>;
> > +                               interrupts = </*Status*/0x10 0x4
> > +                                               /*Wake*/0x14 0x4>;
> >                                reg = <0xef600e00 0x000000c4>;
> >                                local-mac-address = [000000000000]; /*
> Filled in by U-Boot */
> >                                mal-device = <&MAL0>;
> > @@ -390,13 +388,11 @@
> >                        EMAC1: ethernet@ef600f00 {
> >                                device_type = "network";
> >                                compatible = "ibm,emac-460ex",
> "ibm,emac4sync";
> > -                               interrupt-parent = <&EMAC1>;
> > -                               interrupts = <0x0 0x1>;
> > -                               #interrupt-cells = <1>;
> > +                               interrupt-parent = <&UIC2>;
> >                                #address-cells = <0>;
> >                                #size-cells = <0>;
> > -                               interrupt-map = </*Status*/ 0x0 &UIC2
> 0x11 0x4
> > -                                                /*Wake*/   0x1 &UIC2
> 0x15 0x4>;
> > +                               interrupts = </*Status*/0x11 0x4
> > +                                               /*Wake*/0x15 0x4>;
> >                                reg = <0xef600f00 0x000000c4>;
> >                                local-mac-address = [000000000000]; /*
> Filled in by U-Boot */
> >                                mal-device = <&MAL0>;
> > --
> > 1.6.1.rc3
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
>

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, 
is for the sole use of the intended recipient(s) and contains information 
that is confidential and proprietary to AppliedMicro Corporation or its subsidiaries. 
It is to be used solely for the purpose of furthering the parties' business relationship. 
All unauthorized review, use, disclosure or distribution is prohibited. 
If you are not the intended recipient, please contact the sender by reply e-mail 
and destroy all copies of the original message.

[-- Attachment #2: Type: text/html, Size: 5687 bytes --]

^ permalink raw reply

* Re: [PATCH] usb/fsl_udc: fix dequeuing a request in progress
From: Peter Chen @ 2011-11-22 11:48 UTC (permalink / raw)
  To: Li Yang-R58472
  Cc: Chen Peter-B29397, gregkh@suse.de, linuxppc-dev@lists.ozlabs.org,
	linux-usb@vger.kernel.org, balbi@ti.com
In-Reply-To: <3F607A5180246847A760FD34122A1E052D94DB@039-SN1MPN1-003.039d.mgd.msft.net>

>>It seems to can't get the correct qh pointer, you may still need to use
>>below code to get it
>> =A0 =A0 =A0 int i =3D ep_index(ep) * 2 + ep_is_in(ep);
>> =A0 =A0 =A0 struct ep_queue_head *dQH =3D &ep->udc->ep_qh[i];
>
> Thanks for trying. =A0 =A0It will be much easier if we can dereference QH=
 from the ep structure. =A0It is really strange that the ep->qh pointer is =
not working somehow.
>

Seems only ep0-out's qh pointer is assigned at ep structure.
At probe:
/* setup udc->eps[] for ep0 */
struct_ep_setup(udc_controller, 0, "ep0", 0);


> We have initialized it in struct_ep_setup():
> =A0 =A0 =A0 =A0ep->qh =3D &udc->ep_qh[index];
>
> Can you do me a favor on investigating why it's failing?
>
> Thanks,
> Leo
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>



--=20
BR,
Peter Chen

^ permalink raw reply

* Re: powerpc: dts: Fix canyonlands EMAC interrupt map
From: Josh Boyer @ 2011-11-22 11:30 UTC (permalink / raw)
  To: Tanmay Inamdar; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1321945877-22802-1-git-send-email-tinamdar@apm.com>

On Tue, Nov 22, 2011 at 2:11 AM, Tanmay Inamdar <tinamdar@apm.com> wrote:
> Fixing interrupt mapping of EMAC for canyonlands
>
> Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>

As far as I can tell, your changes aren't really changing anything
just making it a bit clearer, correct?  If so, do you mind if I change
the commit log to "clear up" instead of fix?

josh

> ---
> =A0arch/powerpc/boot/dts/canyonlands.dts | =A0 16 ++++++----------
> =A01 files changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dt=
s/canyonlands.dts
> index 3dc75de..c76bbcd 100644
> --- a/arch/powerpc/boot/dts/canyonlands.dts
> +++ b/arch/powerpc/boot/dts/canyonlands.dts
> @@ -360,13 +360,11 @@
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0EMAC0: ethernet@ef600e00 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_typ=
e =3D "network";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible=
 =3D "ibm,emac-460ex", "ibm,emac4sync";
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt-p=
arent =3D <&EMAC0>;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupts =
=3D <0x0 0x1>;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #interrupt-=
cells =3D <1>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt-p=
arent =3D <&UIC2>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#address-c=
ells =3D <0>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#size-cell=
s =3D <0>;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt-m=
ap =3D </*Status*/ 0x0 &UIC2 0x10 0x4
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0/*Wake*/ =A0 0x1 &UIC2 0x14 0x4>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupts =
=3D </*Status*/0x10 0x4
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 /*Wake*/0x14 0x4>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0=
xef600e00 0x000000c4>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0local-mac-=
address =3D [000000000000]; /* Filled in by U-Boot */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mal-device=
 =3D <&MAL0>;
> @@ -390,13 +388,11 @@
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0EMAC1: ethernet@ef600f00 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_typ=
e =3D "network";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible=
 =3D "ibm,emac-460ex", "ibm,emac4sync";
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt-p=
arent =3D <&EMAC1>;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupts =
=3D <0x0 0x1>;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #interrupt-=
cells =3D <1>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt-p=
arent =3D <&UIC2>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#address-c=
ells =3D <0>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#size-cell=
s =3D <0>;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt-m=
ap =3D </*Status*/ 0x0 &UIC2 0x11 0x4
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0/*Wake*/ =A0 0x1 &UIC2 0x15 0x4>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupts =
=3D </*Status*/0x11 0x4
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 /*Wake*/0x15 0x4>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0=
xef600f00 0x000000c4>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0local-mac-=
address =3D [000000000000]; /* Filled in by U-Boot */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mal-device=
 =3D <&MAL0>;
> --
> 1.6.1.rc3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" i=
n
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at =A0http://www.tux.org/lkml/
>

^ permalink raw reply

* Re: [PATCH] mtd/nand: Add NAND chip ID to support Micron 4k pagesize NAND chip
From: Josh Boyer @ 2011-11-22 11:27 UTC (permalink / raw)
  To: Shengzhou Liu; +Cc: kumar.gala, linuxppc-dev
In-Reply-To: <1321953786-26472-1-git-send-email-Shengzhou.Liu@freescale.com>

On Tue, Nov 22, 2011 at 4:23 AM, Shengzhou Liu
<Shengzhou.Liu@freescale.com> wrote:
> Add NAND chip ID 0x38 in ids table to support Micron 4k large-page NAND c=
hip.
>
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> ---
> =A0drivers/mtd/nand/nand_ids.c | =A0 =A01 +

You really need to send this to the MTD list and have it go through that tr=
ee.

josh

^ permalink raw reply

* [PATCH] mtd/nand: Add NAND chip ID to support Micron 4k pagesize NAND chip
From: Shengzhou Liu @ 2011-11-22  9:23 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: kumar.gala, Shengzhou Liu

Add NAND chip ID 0x38 in ids table to support Micron 4k large-page NAND chip.

Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
 drivers/mtd/nand/nand_ids.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 00cf1b0..23ed1d2 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -106,6 +106,7 @@ struct nand_flash_dev nand_flash_ids[] = {
 	/* 8 Gigabit */
 	{"NAND 1GiB 1,8V 8-bit",	0xA3, 0, 1024, 0, LP_OPTIONS},
 	{"NAND 1GiB 3,3V 8-bit",	0xD3, 0, 1024, 0, LP_OPTIONS},
+	{"NAND 1GiB 3,3V 8-bit",	0x38, 0, 1024, 0, LP_OPTIONS},
 	{"NAND 1GiB 1,8V 16-bit",	0xB3, 0, 1024, 0, LP_OPTIONS16},
 	{"NAND 1GiB 3,3V 16-bit",	0xC3, 0, 1024, 0, LP_OPTIONS16},
 
-- 
1.6.4

^ permalink raw reply related

* RE: [PATCH] usb/fsl_udc: fix dequeuing a request in progress
From: Li Yang-R58472 @ 2011-11-22  9:49 UTC (permalink / raw)
  To: Chen Peter-B29397
  Cc: gregkh@suse.de, linuxppc-dev@lists.ozlabs.org,
	linux-usb@vger.kernel.org, balbi@ti.com
In-Reply-To: <20111122093437.GA18543@nchen-desktop>

>Subject: Re: [PATCH] usb/fsl_udc: fix dequeuing a request in progress
>
>On Fri, Nov 11, 2011 at 08:38:13PM +0800, Li Yang wrote:
>> 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 <leoli@freescale.com>
>> ---
>>  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 =3D ep->qh;
>It seems to can't get the correct qh pointer, you may still need to use
>below code to get it
> 	int i =3D ep_index(ep) * 2 + ep_is_in(ep);
> 	struct ep_queue_head *dQH =3D &ep->udc->ep_qh[i];

Thanks for trying.    It will be much easier if we can dereference QH from =
the ep structure.  It is really strange that the ep->qh pointer is not work=
ing somehow.

We have initialized it in struct_ep_setup():
	ep->qh =3D &udc->ep_qh[index];

Can you do me a favor on investigating why it's failing?

Thanks,
Leo

^ permalink raw reply

* Re: [PATCH] usb/fsl_udc: fix dequeuing a request in progress
From: Peter Chen @ 2011-11-22  9:34 UTC (permalink / raw)
  To: Li Yang; +Cc: gregkh, linuxppc-dev, linux-usb, balbi
In-Reply-To: <1321015093-13715-1-git-send-email-leoli@freescale.com>

On Fri, Nov 11, 2011 at 08:38:13PM +0800, Li Yang wrote:
> 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 <leoli@freescale.com>
> ---
>  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;
It seems to can't get the correct qh pointer, you may still need to
use below code to get it
 	int i = ep_index(ep) * 2 + ep_is_in(ep);
 	struct ep_queue_head *dQH = &ep->udc->ep_qh[i];
> +
> +	/* 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);

After fixing above error, others are ok. I have tested it at i.mx51 bbg board
using 3.2.0-rc2+.
> -- 
> 1.5.4.3
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 

Best Regards,
Peter Chen

^ permalink raw reply

* RE: [PATCH v2 1/7] powerpc/85xx: re-enable timebase sync disabled by KEXEC patch
From: Li Yang-R58472 @ 2011-11-22  9:29 UTC (permalink / raw)
  To: Wood Scott-B07421, Kumar Gala
  Cc: linuxppc-dev@lists.ozlabs.org, Zhao Chenhui-B35336
In-Reply-To: <20111118180114.GB28562@schlenkerla.am.freescale.net>

>Subject: Re: [PATCH v2 1/7] powerpc/85xx: re-enable timebase sync disabled
>by KEXEC patch
>
>On Fri, Nov 18, 2011 at 08:35:02AM -0600, Kumar Gala wrote:
>>
>> On Nov 16, 2011, at 12:42 PM, Scott Wood wrote:
>>
>> > On 11/16/2011 03:55 AM, Zhao Chenhui wrote:
>> >> From: Li Yang <leoli@freescale.com>
>> >>
>> >> The timebase sync is not only necessary when using KEXEC. It should
>also
>> >> be used by normal boot up and cpu hotplug. Remove the ifdef added by
>> >> the KEXEC patch.
>> >
>> > Again, no it should not be used by normal boot up (whether KEXEC
>support
>> > is enabled or not).  We should only do timebase sync when we actually
>> > need to (when we've actually just reset a core), and we should do it
>the
>> > way U-Boot does rather than with smp-tbsync.c.

While looking into the timebase sync code in u-boot, I have a few questions=
.

        /* enable time base at the platform */
        if (whoami)
                devdisr |=3D MPC85xx_DEVDISR_TB1;
        else
                devdisr |=3D MPC85xx_DEVDISR_TB0;
        out_be32(&gur->devdisr, devdisr);

        /* readback to sync write */
        in_be32(&gur->devdisr);

        mtspr(SPRN_TBWU, 0);
        mtspr(SPRN_TBWL, 0);

What are the TBWU/TBWL registers?  I can't find the definition of them in e=
ither e500 RM or booke RM.  Are they valid to be used?  What is the result =
of writing to them?  Aren't the SPR registers core specific?  How can we se=
t the TB for the other cores?

        devdisr &=3D ~(MPC85xx_DEVDISR_TB0 | MPC85xx_DEVDISR_TB1);
        out_be32(&gur->devdisr, devdisr);

Also in the UM, I read "Blocks disabled by DEVDISR must not be re-enabled w=
ithout a hard reset."  Is it safe we enable it here?

- Leo

^ permalink raw reply

* powerpc: dts: Fix canyonlands EMAC interrupt map
From: Tanmay Inamdar @ 2011-11-22  7:11 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, linux-kernel, Tanmay Inamdar

Fixing interrupt mapping of EMAC for canyonlands

Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
---
 arch/powerpc/boot/dts/canyonlands.dts |   16 ++++++----------
 1 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index 3dc75de..c76bbcd 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -360,13 +360,11 @@
 			EMAC0: ethernet@ef600e00 {
 				device_type = "network";
 				compatible = "ibm,emac-460ex", "ibm,emac4sync";
-				interrupt-parent = <&EMAC0>;
-				interrupts = <0x0 0x1>;
-				#interrupt-cells = <1>;
+				interrupt-parent = <&UIC2>;
 				#address-cells = <0>;
 				#size-cells = <0>;
-				interrupt-map = </*Status*/ 0x0 &UIC2 0x10 0x4
-						 /*Wake*/   0x1 &UIC2 0x14 0x4>;
+				interrupts = </*Status*/0x10 0x4
+						/*Wake*/0x14 0x4>;
 				reg = <0xef600e00 0x000000c4>;
 				local-mac-address = [000000000000]; /* Filled in by U-Boot */
 				mal-device = <&MAL0>;
@@ -390,13 +388,11 @@
 			EMAC1: ethernet@ef600f00 {
 				device_type = "network";
 				compatible = "ibm,emac-460ex", "ibm,emac4sync";
-				interrupt-parent = <&EMAC1>;
-				interrupts = <0x0 0x1>;
-				#interrupt-cells = <1>;
+				interrupt-parent = <&UIC2>;
 				#address-cells = <0>;
 				#size-cells = <0>;
-				interrupt-map = </*Status*/ 0x0 &UIC2 0x11 0x4
-						 /*Wake*/   0x1 &UIC2 0x15 0x4>;
+				interrupts = </*Status*/0x11 0x4
+						/*Wake*/0x15 0x4>;
 				reg = <0xef600f00 0x000000c4>;
 				local-mac-address = [000000000000]; /* Filled in by U-Boot */
 				mal-device = <&MAL0>;
-- 
1.6.1.rc3

^ permalink raw reply related

* RE: [PATCH 1/2] Unify pci/pcie initialization code
From: Jia Hongtao-B38951 @ 2011-11-22  6:35 UTC (permalink / raw)
  To: Gala Kumar-B11780
  Cc: linuxppc-dev@lists.ozlabs.org, Li Yang-R58472, Jia Hongtao-B38951
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5DFD4DB8@039-SN1MPN1-005.039d.mgd.msft.net>

Hi Kumar,
If the patch is ok we will apply the patch into other platforms.
Thanks.

-----Original Message-----
From: Jia Hongtao-B38951=20
Sent: Tuesday, November 22, 2011 2:21 PM
To: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org
Cc: Li Yang-R58472; Gala Kumar-B11780
Subject: RE: [PATCH 1/2] Unify pci/pcie initialization code

Hi Kumar,
We want more comments on this series of patches ([1/2] & [2/2]) to speed up=
 the pushing-to-kernel progress.
Thanks.

-----Original Message-----
From: Jia Hongtao-B38951=20
Sent: Monday, October 31, 2011 1:55 PM
To: linuxppc-dev@lists.ozlabs.org
Cc: Li Yang-R58472; Gala Kumar-B11780; Jia Hongtao-B38951
Subject: [PATCH 1/2] Unify pci/pcie initialization code

In previous version pci/pcie initialization is in platform code which Initi=
alize PCI bridge base on EP/RC or host/agent settings.
We unified pci/pcie initialization as common APIs named fsl_pci_setup which=
 can be called by platform code.

Signed-off-by: Jia Hongtao <B38951@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
 arch/powerpc/platforms/85xx/mpc85xx_ds.c |   30 ++-----------------
 arch/powerpc/sysdev/fsl_pci.c            |   48 ++++++++++++++++++++++++++=
++++
 arch/powerpc/sysdev/fsl_pci.h            |    5 +++
 3 files changed, 56 insertions(+), 27 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platfo=
rms/85xx/mpc85xx_ds.c
index 10e7db0..7188c0b 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -157,33 +157,12 @@ extern void __init mpc85xx_smp_init(void);  #endif  s=
tatic void __init mpc85xx_ds_setup_arch(void)  { -#ifdef CONFIG_PCI
-	struct device_node *np;
-	struct pci_controller *hose;
-#endif
-	dma_addr_t max =3D 0xffffffff;
-
 	if (ppc_md.progress)
 		ppc_md.progress("mpc85xx_ds_setup_arch()", 0);
=20
-#ifdef CONFIG_PCI
-	for_each_node_by_type(np, "pci") {
-		if (of_device_is_compatible(np, "fsl,mpc8540-pci") ||
-		    of_device_is_compatible(np, "fsl,mpc8548-pcie") ||
-		    of_device_is_compatible(np, "fsl,p2020-pcie")) {
-			struct resource rsrc;
-			of_address_to_resource(np, 0, &rsrc);
-			if ((rsrc.start & 0xfffff) =3D=3D primary_phb_addr)
-				fsl_add_bridge(np, 1);
-			else
-				fsl_add_bridge(np, 0);
-
-			hose =3D pci_find_hose_for_OF_device(np);
-			max =3D min(max, hose->dma_window_base_cur +
-					hose->dma_window_size);
-		}
-	}
+	fsl_pci_setup(primary_phb_addr);
=20
+#ifdef CONFIG_PCI
 	ppc_md.pci_exclude_device =3D mpc85xx_exclude_device;  #endif
=20
@@ -192,11 +171,8 @@ static void __init mpc85xx_ds_setup_arch(void)  #endif
=20
 #ifdef CONFIG_SWIOTLB
-	if (memblock_end_of_DRAM() > max) {
+	if (memblock_end_of_DRAM() > 0xffffffff)
 		ppc_swiotlb_enable =3D 1;
-		set_pci_dma_ops(&swiotlb_dma_ops);
-		ppc_md.pci_dma_dev_setup =3D pci_dma_dev_setup_swiotlb;
-	}
 #endif
=20
 	printk("MPC85xx DS board from Freescale Semiconductor\n"); diff --git a/a=
rch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c index 80b8b7a.=
.4d4536f 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -402,6 +402,54 @@ int __init fsl_add_bridge(struct device_node *dev, int=
 is_primary)  }  #endif /* CONFIG_FSL_SOC_BOOKE || CONFIG_PPC_86xx */
=20
+static struct of_device_id pci_ids[] =3D {
+	{ .compatible =3D "fsl,mpc8540-pci", },
+	{ .compatible =3D "fsl,mpc8548-pcie", },
+	{},
+};
+
+/**
+ * fsl_pci_setup - Initialization for PCI
+ * @primary_phb_addr: primary bus address
+ *
+ * Add bridge if pci controller is a host  */ void fsl_pci_setup(int=20
+primary_phb_addr) {
+	struct device_node *np;
+	struct pci_controller *hose;
+	dma_addr_t min_dma_addr =3D 0xffffffff;
+
+	for_each_node_by_type(np, "pci") {
+		if (of_match_node(pci_ids, np)) {
+			struct resource rsrc;
+			of_address_to_resource(np, 0, &rsrc);
+			if ((rsrc.start & 0xfffff) =3D=3D primary_phb_addr)
+				fsl_add_bridge(np, 1);
+			else
+				fsl_add_bridge(np, 0);
+
+			hose =3D pci_find_hose_for_OF_device(np);
+			min_dma_addr =3D min(min_dma_addr,
+					hose->dma_window_base_cur
+					+ hose->dma_window_size);
+
+		}
+	}
+
+#ifdef CONFIG_SWIOTLB
+	/*
+	 * if we couldn't map all of DRAM via the dma windows we need SWIOTLB
+	 * to handle buffers located outside of dma capable memory region
+	 */
+	if (memblock_end_of_DRAM() > min_dma_addr) {
+		ppc_swiotlb_enable =3D 1;
+		set_pci_dma_ops(&swiotlb_dma_ops);
+		ppc_md.pci_dma_dev_setup =3D pci_dma_dev_setup_swiotlb;
+	}
+#endif
+}
+
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID, quirk_fsl_pc=
ie_header);
=20
 #if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_MPC512x) diff --git a/a=
rch/powerpc/sysdev/fsl_pci.h b/arch/powerpc/sysdev/fsl_pci.h index a39ed5c.=
.775ea21 100644
--- a/arch/powerpc/sysdev/fsl_pci.h
+++ b/arch/powerpc/sysdev/fsl_pci.h
@@ -89,6 +89,11 @@ struct ccsr_pci {
 };
=20
 extern int fsl_add_bridge(struct device_node *dev, int is_primary);
+#ifndef CONFIG_PCI
+#define fsl_pci_setup(p)
+#else
+extern void fsl_pci_setup(int primary_phb_addr); #endif
 extern void fsl_pcibios_fixup_bus(struct pci_bus *bus);  extern int mpc83x=
x_add_bridge(struct device_node *dev);
 u64 fsl_pci_immrbar_base(struct pci_controller *hose);
--
1.7.5.1

^ permalink raw reply related

* RE: [PATCH 1/2] Unify pci/pcie initialization code
From: Jia Hongtao-B38951 @ 2011-11-22  6:20 UTC (permalink / raw)
  To: Jia Hongtao-B38951, linuxppc-dev@lists.ozlabs.org
  Cc: Gala Kumar-B11780, Li Yang-R58472
In-Reply-To: <1320040492-6407-2-git-send-email-B38951@freescale.com>

Hi Kumar,
We want more comments on this series of patches ([1/2] & [2/2]) to speed up=
 the pushing-to-kernel progress.
Thanks.

-----Original Message-----
From: Jia Hongtao-B38951=20
Sent: Monday, October 31, 2011 1:55 PM
To: linuxppc-dev@lists.ozlabs.org
Cc: Li Yang-R58472; Gala Kumar-B11780; Jia Hongtao-B38951
Subject: [PATCH 1/2] Unify pci/pcie initialization code

In previous version pci/pcie initialization is in platform code which Initi=
alize PCI bridge base on EP/RC or host/agent settings.
We unified pci/pcie initialization as common APIs named fsl_pci_setup which=
 can be called by platform code.

Signed-off-by: Jia Hongtao <B38951@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
 arch/powerpc/platforms/85xx/mpc85xx_ds.c |   30 ++-----------------
 arch/powerpc/sysdev/fsl_pci.c            |   48 ++++++++++++++++++++++++++=
++++
 arch/powerpc/sysdev/fsl_pci.h            |    5 +++
 3 files changed, 56 insertions(+), 27 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platfo=
rms/85xx/mpc85xx_ds.c
index 10e7db0..7188c0b 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -157,33 +157,12 @@ extern void __init mpc85xx_smp_init(void);  #endif  s=
tatic void __init mpc85xx_ds_setup_arch(void)  { -#ifdef CONFIG_PCI
-	struct device_node *np;
-	struct pci_controller *hose;
-#endif
-	dma_addr_t max =3D 0xffffffff;
-
 	if (ppc_md.progress)
 		ppc_md.progress("mpc85xx_ds_setup_arch()", 0);
=20
-#ifdef CONFIG_PCI
-	for_each_node_by_type(np, "pci") {
-		if (of_device_is_compatible(np, "fsl,mpc8540-pci") ||
-		    of_device_is_compatible(np, "fsl,mpc8548-pcie") ||
-		    of_device_is_compatible(np, "fsl,p2020-pcie")) {
-			struct resource rsrc;
-			of_address_to_resource(np, 0, &rsrc);
-			if ((rsrc.start & 0xfffff) =3D=3D primary_phb_addr)
-				fsl_add_bridge(np, 1);
-			else
-				fsl_add_bridge(np, 0);
-
-			hose =3D pci_find_hose_for_OF_device(np);
-			max =3D min(max, hose->dma_window_base_cur +
-					hose->dma_window_size);
-		}
-	}
+	fsl_pci_setup(primary_phb_addr);
=20
+#ifdef CONFIG_PCI
 	ppc_md.pci_exclude_device =3D mpc85xx_exclude_device;  #endif
=20
@@ -192,11 +171,8 @@ static void __init mpc85xx_ds_setup_arch(void)  #endif
=20
 #ifdef CONFIG_SWIOTLB
-	if (memblock_end_of_DRAM() > max) {
+	if (memblock_end_of_DRAM() > 0xffffffff)
 		ppc_swiotlb_enable =3D 1;
-		set_pci_dma_ops(&swiotlb_dma_ops);
-		ppc_md.pci_dma_dev_setup =3D pci_dma_dev_setup_swiotlb;
-	}
 #endif
=20
 	printk("MPC85xx DS board from Freescale Semiconductor\n"); diff --git a/a=
rch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c index 80b8b7a.=
.4d4536f 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -402,6 +402,54 @@ int __init fsl_add_bridge(struct device_node *dev, int=
 is_primary)  }  #endif /* CONFIG_FSL_SOC_BOOKE || CONFIG_PPC_86xx */
=20
+static struct of_device_id pci_ids[] =3D {
+	{ .compatible =3D "fsl,mpc8540-pci", },
+	{ .compatible =3D "fsl,mpc8548-pcie", },
+	{},
+};
+
+/**
+ * fsl_pci_setup - Initialization for PCI
+ * @primary_phb_addr: primary bus address
+ *
+ * Add bridge if pci controller is a host  */ void fsl_pci_setup(int=20
+primary_phb_addr) {
+	struct device_node *np;
+	struct pci_controller *hose;
+	dma_addr_t min_dma_addr =3D 0xffffffff;
+
+	for_each_node_by_type(np, "pci") {
+		if (of_match_node(pci_ids, np)) {
+			struct resource rsrc;
+			of_address_to_resource(np, 0, &rsrc);
+			if ((rsrc.start & 0xfffff) =3D=3D primary_phb_addr)
+				fsl_add_bridge(np, 1);
+			else
+				fsl_add_bridge(np, 0);
+
+			hose =3D pci_find_hose_for_OF_device(np);
+			min_dma_addr =3D min(min_dma_addr,
+					hose->dma_window_base_cur
+					+ hose->dma_window_size);
+
+		}
+	}
+
+#ifdef CONFIG_SWIOTLB
+	/*
+	 * if we couldn't map all of DRAM via the dma windows we need SWIOTLB
+	 * to handle buffers located outside of dma capable memory region
+	 */
+	if (memblock_end_of_DRAM() > min_dma_addr) {
+		ppc_swiotlb_enable =3D 1;
+		set_pci_dma_ops(&swiotlb_dma_ops);
+		ppc_md.pci_dma_dev_setup =3D pci_dma_dev_setup_swiotlb;
+	}
+#endif
+}
+
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID, quirk_fsl_pc=
ie_header);
=20
 #if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_MPC512x) diff --git a/a=
rch/powerpc/sysdev/fsl_pci.h b/arch/powerpc/sysdev/fsl_pci.h index a39ed5c.=
.775ea21 100644
--- a/arch/powerpc/sysdev/fsl_pci.h
+++ b/arch/powerpc/sysdev/fsl_pci.h
@@ -89,6 +89,11 @@ struct ccsr_pci {
 };
=20
 extern int fsl_add_bridge(struct device_node *dev, int is_primary);
+#ifndef CONFIG_PCI
+#define fsl_pci_setup(p)
+#else
+extern void fsl_pci_setup(int primary_phb_addr); #endif
 extern void fsl_pcibios_fixup_bus(struct pci_bus *bus);  extern int mpc83x=
x_add_bridge(struct device_node *dev);
 u64 fsl_pci_immrbar_base(struct pci_controller *hose);
--
1.7.5.1

^ permalink raw reply related

* RE: [PATCH] Do not hide resource for pci/pcie when configured as Agent/EP
From: Jia Hongtao-B38951 @ 2011-11-22  6:18 UTC (permalink / raw)
  To: Gala Kumar-B11780
  Cc: linuxppc-dev@lists.ozlabs.org, Li Yang-R58472, Jia Hongtao-B38951
In-Reply-To: <1319789280-12091-1-git-send-email-B38951@freescale.com>

Hi Kumar,
We want more comments on this patch to speed up the pushing-to-kernel progr=
ess.
Thanks.

-----Original Message-----
From: Jia Hongtao-B38951=20
Sent: Friday, October 28, 2011 4:08 PM
To: linuxppc-dev@lists.ozlabs.org
Cc: Li Yang-R58472; Gala Kumar-B11780; Jia Hongtao-B38951
Subject: [PATCH] Do not hide resource for pci/pcie when configured as Agent=
/EP

From: Jason Jin <Jason.jin@freescale.com>

Current pci/pcie init code will hide the pci/pcie host resource.
But did not judge it is host/RC or agent/EP. If configured as agent/EP, we =
should avoid hiding its resource in the host side.

In PCI system, the Programing Interface can be used to judge the host/agent=
 status:
Programing Interface =3D 0: host
Programing Interface =3D 1: Agent

In PCIE system, both the Programing Interface and Header type can be used t=
o judge the RC/EP status.
Header Type =3D 0: EP
Header Type =3D 1: RC

Signed-off-by: Jason Jin <Jason.jin@freescale.com>
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
Signed-off-by: Jia Hongtao <B38951@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
 arch/powerpc/kernel/pci-common.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-com=
mon.c
index 4f134132c..bc61a69 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1732,10 +1732,13 @@ void __devinit pcibios_scan_phb(struct pci_controll=
er *hose)  static void fixup_hide_host_resource_fsl(struct pci_dev *dev)  {
 	int i, class =3D dev->class >> 8;
+	/* When configured as agent, programing interface =3D 1 */
+	int prog_if =3D dev->class & 0xf;
=20
 	if ((class =3D=3D PCI_CLASS_PROCESSOR_POWERPC ||
 	     class =3D=3D PCI_CLASS_BRIDGE_OTHER) &&
 		(dev->hdr_type =3D=3D PCI_HEADER_TYPE_NORMAL) &&
+		(prog_if =3D=3D 0) &&
 		(dev->bus->parent =3D=3D NULL)) {
 		for (i =3D 0; i < DEVICE_COUNT_RESOURCE; i++) {
 			dev->resource[i].start =3D 0;
--
1.7.5.1

^ permalink raw reply related

* [PATCH][RFC] fsldma: fix performance degradation by optimizing spinlock use.
From: b29237 @ 2011-11-22  4:55 UTC (permalink / raw)
  To: dan.j.williams, leoli, zw, vinod.koul
  Cc: Forrest Shi, linuxppc-dev, linux-kernel

From: Forrest Shi <b29237@freescale.com>

    dma status check function fsl_tx_status is heavily called in
    a tight loop and the desc lock in fsl_tx_status contended by
    the dma status update function. this caused the dma performance
    degrades much.

    this patch releases the lock in the fsl_tx_status function.
    I believe it has no neglect impact on the following call of
    dma_async_is_complete(...).

    we can see below three conditions will be identified as success
    a)  x < complete < use
    b)  x < complete+N < use+N
    c)  x < complete < use+N
    here complete is the completed_cookie, use is the last_used
    cookie, x is the querying cookie, N is MAX cookie

    when chan->completed_cookie is being read, the last_used may
    be incresed. Anyway it has no neglect impact on the dma status
    decision.

    Signed-off-by: Forrest Shi <xuelin.shi@freescale.com>
---
 drivers/dma/fsldma.c |    5 -----
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 8a78154..1dca56f 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -986,15 +986,10 @@ static enum dma_status fsl_tx_status(struct dma_chan *dchan,
 	struct fsldma_chan *chan = to_fsl_chan(dchan);
 	dma_cookie_t last_complete;
 	dma_cookie_t last_used;
-	unsigned long flags;
-
-	spin_lock_irqsave(&chan->desc_lock, flags);
 
 	last_complete = chan->completed_cookie;
 	last_used = dchan->cookie;
 
-	spin_unlock_irqrestore(&chan->desc_lock, flags);
-
 	dma_set_tx_state(txstate, last_complete, last_used, 0);
 	return dma_async_is_complete(cookie, last_complete, last_used);
 }
-- 
1.7.0.4

^ permalink raw reply related

* RE: [PATCH v2] USB: fsl_udc_core: use usb_endpoint_xfer_isoc to judge ISO XFER
From: Li Yang-R58472 @ 2011-11-22  3:11 UTC (permalink / raw)
  To: Chen Peter-B29397, balbi@ti.com, mina86@mina86.com
  Cc: gregkh@suse.de, linuxppc-dev@lists.ozlabs.org,
	linux-usb@vger.kernel.org, hzpeterchen@gmail.com,
	stable@kernel.org
In-Reply-To: <1321926945-8182-1-git-send-email-peter.chen@freescale.com>

PiBTdWJqZWN0OiBbUEFUQ0ggdjJdIFVTQjogZnNsX3VkY19jb3JlOiB1c2UgdXNiX2VuZHBvaW50
X3hmZXJfaXNvYyB0byBqdWRnZSBJU08NCj4gWEZFUg0KPiANCj4gU29tZSBJU08gZ2FkZ2V0cywg
bGlrZSBhdWRpbywgaGFzIFNZTkMgYXR0cmlidXRlIGFzIHdlbGwgYXMNCj4gVVNCX0VORFBPSU5U
X1hGRVJfSVNPQyBmb3IgdGhlaXIgYm1BdHRyaWJ1dGVzIGF0IElTTyBlbmRwb2ludCBkZXNjcmlw
dG9yLiBTbywgaXQNCj4gbmVlZHMgdG8gdXNlIHVzYl9lbmRwb2ludF94ZmVyX2lzb2MgdG8ganVk
Z2UgSVNPIFhGRVIuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBQZXRlciBDaGVuIDxwZXRlci5jaGVu
QGZyZWVzY2FsZS5jb20+DQoNCkFja2VkLWJ5OiBMaSBZYW5nIDxsZW9saUBmcmVlc2NhbGUuY29t
Pg0KDQotIExlbw0K

^ permalink raw reply

* Re: [PATCH v2] USB: fsl_udc_core: use usb_endpoint_xfer_isoc to judge ISO XFER
From: Michal Nazarewicz @ 2011-11-22  1:57 UTC (permalink / raw)
  To: leoli, balbi, Peter Chen
  Cc: gregkh, linuxppc-dev, linux-usb, hzpeterchen, stable
In-Reply-To: <1321926945-8182-1-git-send-email-peter.chen@freescale.com>

On Tue, 22 Nov 2011 02:55:45 +0100, Peter Chen <peter.chen@freescale.com=
> wrote:
> Some ISO gadgets, like audio, has SYNC attribute as well as
> USB_ENDPOINT_XFER_ISOC for their bmAttributes at ISO endpoint
> descriptor. So, it needs to use usb_endpoint_xfer_isoc to judge
> ISO XFER.
>
> Signed-off-by: Peter Chen <peter.chen@freescale.com>

Acked-by: Michal Nazarewicz <mina86@mina86.com>

> @@ -877,7 +877,7 @@ fsl_ep_queue(struct usb_ep *_ep, struct usb_reques=
t *_req, gfp_t gfp_flags)
>  		VDBG("%s, bad ep", __func__);
>  		return -EINVAL;
>  	}
> -	if (ep->desc->bmAttributes =3D=3D USB_ENDPOINT_XFER_ISOC) {
> +	if (usb_endpoint_xfer_isoc(ep->desc)) {
>  		if (req->req.length > ep->ep.maxpacket)
>  			return -EMSGSIZE;
>  	}
> @@ -1032,7 +1032,7 @@ static int fsl_ep_set_halt(struct usb_ep *_ep, i=
nt value)
>  		goto out;
>  	}
>-	if (ep->desc->bmAttributes =3D=3D USB_ENDPOINT_XFER_ISOC) {
> +	if (usb_endpoint_xfer_isoc(ep->desc)) {
>  		status =3D -EOPNOTSUPP;
>  		goto out;
>  	}

-- =

Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=3D./ `o
..o | Computer Science,  Micha=C5=82 =E2=80=9Cmina86=E2=80=9D Nazarewicz=
    (o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--

^ permalink raw reply

* [PATCH v2] USB: fsl_udc_core: use usb_endpoint_xfer_isoc to judge ISO XFER
From: Peter Chen @ 2011-11-22  1:55 UTC (permalink / raw)
  To: leoli, balbi, mina86; +Cc: gregkh, linuxppc-dev, linux-usb, hzpeterchen, stable

Some ISO gadgets, like audio, has SYNC attribute as well as
USB_ENDPOINT_XFER_ISOC for their bmAttributes at ISO endpoint
descriptor. So, it needs to use usb_endpoint_xfer_isoc to judge
ISO XFER.

Signed-off-by: Peter Chen <peter.chen@freescale.com>
---
 drivers/usb/gadget/fsl_udc_core.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c
index d786ba3..91df255 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -877,7 +877,7 @@ fsl_ep_queue(struct usb_ep *_ep, struct usb_request *_req, gfp_t gfp_flags)
 		VDBG("%s, bad ep", __func__);
 		return -EINVAL;
 	}
-	if (ep->desc->bmAttributes == USB_ENDPOINT_XFER_ISOC) {
+	if (usb_endpoint_xfer_isoc(ep->desc)) {
 		if (req->req.length > ep->ep.maxpacket)
 			return -EMSGSIZE;
 	}
@@ -1032,7 +1032,7 @@ static int fsl_ep_set_halt(struct usb_ep *_ep, int value)
 		goto out;
 	}
 
-	if (ep->desc->bmAttributes == USB_ENDPOINT_XFER_ISOC) {
+	if (usb_endpoint_xfer_isoc(ep->desc)) {
 		status = -EOPNOTSUPP;
 		goto out;
 	}
-- 
1.6.3.3

^ permalink raw reply related

* Re: [PATCH] USB: fsl_udc_core: Use (&) instead of (==) to compare ISO XFER
From: Michal Nazarewicz @ 2011-11-22  1:26 UTC (permalink / raw)
  To: leoli, balbi, Peter Chen; +Cc: gregkh, linuxppc-dev, linux-usb, stable
In-Reply-To: <op.v5bp28eu3l0zgt@mpn-glaptop>

> On Tue, 22 Nov 2011 02:15:21 +0100, Peter Chen <peter.chen@freescale.c=
om> wrote:
>> @@ -877,7 +877,7 @@ fsl_ep_queue(struct usb_ep *_ep, struct usb_reque=
st *_req, gfp_t gfp_flags)
>>  		VDBG("%s, bad ep", __func__);
>>  		return -EINVAL;
>>  	}
>> -	if (ep->desc->bmAttributes =3D=3D USB_ENDPOINT_XFER_ISOC) {
>> +	if (ep->desc->bmAttributes & USB_ENDPOINT_XFER_ISOC) {

On Tue, 22 Nov 2011 02:22:10 +0100, Michal Nazarewicz <mina86@mina86.com=
> wrote:
> What you really meant is:
>
> (ep->desc->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) =3D=3D USB_ENDPO=
INT_XFER_ISOC
>
> It would probably be useful to create a function that performs that ch=
eck rather
> than having to type all of that every time.

Ah, there it is:

usb_endpoint_xfer_isoc(ep)

:)

>
>>  		if (req->req.length > ep->ep.maxpacket)
>>  			return -EMSGSIZE;
>>  	}

-- =

Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=3D./ `o
..o | Computer Science,  Micha=C5=82 =E2=80=9Cmina86=E2=80=9D Nazarewicz=
    (o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox