* RE: [Linux-ATM-General] mpc8360sar
From: Li Tony-r64360 @ 2006-07-20 12:07 UTC (permalink / raw)
To: Alex Zeffertt, linuxppc-embedded, linux-atm-general
In-Reply-To: <44BF5D6D.1070400@cambridgebroadband.com>
Hi, alex
I am tony li. I am glad to know that you add many features support.
Do you have test the UBR and AAL0 ? I am lack of enviroment test them
now.
I have not read your code detailly.:)
And which ltib release version is your base ? I have updated my code a
little which contain a workaround for a bug.
Tony.li =20
-----Original Message-----
From: linux-atm-general-bounces@lists.sourceforge.net
[mailto:linux-atm-general-bounces@lists.sourceforge.net] On Behalf Of
Alex Zeffertt
Sent: Thursday, July 20, 2006 6:40 PM
To: linuxppc-embedded@ozlabs.org;
linux-atm-general@lists.sourceforge.net
Subject: [Linux-ATM-General] mpc8360sar
Hi lists,
I'm writing to announce a new project http://mpc8360sar.sourceforge.net
.
This is an ATM driver for the QUICC Engine (QE) of the PowerQUICC II Pro
range of processors. It is based on Tony Li's fsl-atm driver and my
mpc8260sar driver. I've basically used Tony's driver for the most low
level stuff and ported a lot of extra functionality from my PQII driver.
You will need the Linux BSP from Freescale to build this driver.
I have only tested this driver on mpc832xe-mds, but it should also work
on the mpc8360e-pb board.
If you use mpc8360sar, please let me know how you get on. In particular
let me know if you work out how to stop the QE occaisionally corrupting
the TCT when using external channels.
Regards,
Alex
------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT Join
SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
V
_______________________________________________
Linux-atm-general mailing list
Linux-atm-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-atm-general
^ permalink raw reply
* RE: AltiVec in the kernel
From: Matt Sealey @ 2006-07-20 12:31 UTC (permalink / raw)
To: 'Linas Vepstas', 'Paul Mackerras'
Cc: 'linuxppc-dev list'
In-Reply-To: <20060719181047.GL5905@austin.ibm.com>
> But perhaps, in principle, couldn't one run four independent
> streams in parallel? Thus, for example, on an SSL-enabled
> web server, one could service multiple encryption/decryption
> threads at once.
>
> In practice, I don't beleive the infrastructure for that kind
> of parallelism is in place. I'm struggling to find a reason
> to develop that kind of infrastructure. Mumble something about Cell.
If not AltiVec there is potential to use some features which come
with AltiVec like the data stream functionality. Or even the standard
PPC cache control stuff would work.
What's the case in the kernel for the memcpy functions etc., are
they optimized for doing things like longword copies rather than
byte-per-byte etc.? We found glibc sucked for that.
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
^ permalink raw reply
* Re: [Linux-ATM-General] mpc8360sar
From: Alex Zeffertt @ 2006-07-20 12:35 UTC (permalink / raw)
To: Li Tony-r64360; +Cc: linux-atm-general, linuxppc-embedded
In-Reply-To: <995B09A8299C2C44B59866F6391D2635058751@zch01exm21.fsl.freescale.net>
Hi,
Yes, UBR and AAL0 work. I've also added support for the qos parameters
min_pcr, pcr, and max_pcr.
I used ltib-mpc832xemds-20060615 as my base. More details are on the
website.
BTW, I left all your code in. There's a simple config option now which
allows you to choose between the two drivers.
Alex
PS Thanks!
Li Tony-r64360 wrote:
> Hi, alex
> I am tony li. I am glad to know that you add many features support.
> Do you have test the UBR and AAL0 ? I am lack of enviroment test them
> now.
> I have not read your code detailly.:)
> And which ltib release version is your base ? I have updated my code a
> little which contain a workaround for a bug.
>
> Tony.li
>
> -----Original Message-----
> From: linux-atm-general-bounces@lists.sourceforge.net
> [mailto:linux-atm-general-bounces@lists.sourceforge.net] On Behalf Of
> Alex Zeffertt
> Sent: Thursday, July 20, 2006 6:40 PM
> To: linuxppc-embedded@ozlabs.org;
> linux-atm-general@lists.sourceforge.net
> Subject: [Linux-ATM-General] mpc8360sar
>
> Hi lists,
>
> I'm writing to announce a new project http://mpc8360sar.sourceforge.net
> .
> This is an ATM driver for the QUICC Engine (QE) of the PowerQUICC II Pro
> range of processors. It is based on Tony Li's fsl-atm driver and my
> mpc8260sar driver. I've basically used Tony's driver for the most low
> level stuff and ported a lot of extra functionality from my PQII driver.
>
> You will need the Linux BSP from Freescale to build this driver.
>
> I have only tested this driver on mpc832xe-mds, but it should also work
> on the mpc8360e-pb board.
>
> If you use mpc8360sar, please let me know how you get on. In particular
> let me know if you work out how to stop the QE occaisionally corrupting
> the TCT when using external channels.
>
> Regards,
>
> Alex
>
> ------------------------------------------------------------------------
> -
> Take Surveys. Earn Cash. Influence the Future of IT Join
> SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> V
> _______________________________________________
> Linux-atm-general mailing list
> Linux-atm-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-atm-general
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH] Fix Freescale high-speed USB hostdependency
From: Kumar Gala @ 2006-07-20 12:59 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, gregkh, linux-usb-devel
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D07064D@zch01exm20.fsl.freescale.net>
On Jul 20, 2006, at 6:42 AM, Li Yang-r58472 wrote:
> Another one in header file.
>
> ---
> diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
> index 679c1cd..8da2774 100644
> --- a/drivers/usb/host/ehci.h
> +++ b/drivers/usb/host/ehci.h
> @@ -642,7 +642,7 @@ #endif
>
>
> /
> *---------------------------------------------------------------------
> -
> ---*/
>
> -#ifdef CONFIG_PPC_83xx
> +#ifdef CONFIG_MPC834x
> /* Some Freescale processors have an erratum in which the TT
> * port number in the queue head was 0..N-1 instead of 1..N.
> */
Do we really want to make this change. What harm is there in having
the ehci support for MPC834x build on all 83xx processors? I can't
imagine we are going to config in support for ehci on anything that
is MPC834x at this point and if you do, your device tree isn't going
to have nodes in it so the drivers not going to bind against anything.
Finally, I got to believe Freescale's going to build some MPC83xx in
the future with the high speed USB IP.
- kumar
>
>> -----Original Message-----
>> From: linux-usb-devel-bounces@lists.sourceforge.net
>> [mailto:linux-usb-devel-bounces@lists.sourceforge.net] On Behalf Of
> Kumar Gala
>> Sent: Friday, July 14, 2006 9:52 PM
>> To: Li Yang-r58472
>> Cc: linuxppc-dev@ozlabs.org; gregkh@suse.de;
>> linux-usb-devel@lists.sourceforge.net
>> Subject: Re: [linux-usb-devel] [PATCH] Fix Freescale high-speed USB
> hostdependency
>>
>> Acked-by: Kumar Gala <galak@kernel.crashing.org>
>>
>> On Jul 14, 2006, at 6:58 AM, Li Yang wrote:
>>
>>> The high-speed USB SOC only exists on MPC834x family not MPC83xx
>>> family.
>>>
>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>
>>> ---
>>>
>>> drivers/usb/host/ehci-hcd.c | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-
>>> hcd.c index 79f2d8b..3af1844 100644
>>> --- a/drivers/usb/host/ehci-hcd.c
>>> +++ b/drivers/usb/host/ehci-hcd.c
>>> @@ -892,7 +892,7 @@ #include "ehci-pci.c"
>>> #define EHCI_BUS_GLUED
>>> #endif
>>>
>>> -#ifdef CONFIG_PPC_83xx
>>> +#ifdef CONFIG_MPC834x
>>> #include "ehci-fsl.c"
>>> #define EHCI_BUS_GLUED
>>> #endif
>
^ permalink raw reply
* Re: export-objs in spi Makefile broke in latest linuxppc_2_4_deve l [r eposted]?
From: Kumar Gala @ 2006-07-20 13:12 UTC (permalink / raw)
To: hs; +Cc: Chad.Rowan, linuxppc-embedded
In-Reply-To: <1153371343.6004.16.camel@Zeus.EmbLux>
On Jul 19, 2006, at 11:55 PM, Heiko Schocher wrote:
> Hello Chad
>
>> linuxppc_2_4_devel is alive and well.
>>
>> http://www.denx.de/cgi-bin/gitweb.cgi?
>> p=linuxppc_2_4_devel.git;a=shortlog
>
> You speak from the DENX linuxppc_2_4_devel Kernel? If so, I think
> you are right.
> I had the same problem, some days ago. I made a SPI bitbanging
> algorithm, but
> I dont know, if this goes in the git repository from DENX ...
> Wolfgang?
I think this issue should be taken off list.
- k
^ permalink raw reply
* Re: [Linux-ATM-General] mpc8360sar
From: Kumar Gala @ 2006-07-20 13:13 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linux-atm-general, linuxppc-embedded, Li Tony-r64360
In-Reply-To: <44BF787F.3020203@cambridgebroadband.com>
On Jul 20, 2006, at 7:35 AM, Alex Zeffertt wrote:
> Hi,
>
> Yes, UBR and AAL0 work. I've also added support for the qos
> parameters
> min_pcr, pcr, and max_pcr.
>
> I used ltib-mpc832xemds-20060615 as my base. More details are on the
> website.
>
> BTW, I left all your code in. There's a simple config option now
> which
> allows you to choose between the two drivers.
>
> Alex
>
> PS Thanks!
Any reason we dont try to get your work up stream into the mainline
kernel?
- kumar
> Li Tony-r64360 wrote:
>> Hi, alex
>> I am tony li. I am glad to know that you add many features support.
>> Do you have test the UBR and AAL0 ? I am lack of enviroment test them
>> now.
>> I have not read your code detailly.:)
>> And which ltib release version is your base ? I have updated my
>> code a
>> little which contain a workaround for a bug.
>>
>> Tony.li
>>
>> -----Original Message-----
>> From: linux-atm-general-bounces@lists.sourceforge.net
>> [mailto:linux-atm-general-bounces@lists.sourceforge.net] On Behalf Of
>> Alex Zeffertt
>> Sent: Thursday, July 20, 2006 6:40 PM
>> To: linuxppc-embedded@ozlabs.org;
>> linux-atm-general@lists.sourceforge.net
>> Subject: [Linux-ATM-General] mpc8360sar
>>
>> Hi lists,
>>
>> I'm writing to announce a new project http://
>> mpc8360sar.sourceforge.net
>> .
>> This is an ATM driver for the QUICC Engine (QE) of the PowerQUICC
>> II Pro
>> range of processors. It is based on Tony Li's fsl-atm driver and my
>> mpc8260sar driver. I've basically used Tony's driver for the most
>> low
>> level stuff and ported a lot of extra functionality from my PQII
>> driver.
>>
>> You will need the Linux BSP from Freescale to build this driver.
>>
>> I have only tested this driver on mpc832xe-mds, but it should also
>> work
>> on the mpc8360e-pb board.
>>
>> If you use mpc8360sar, please let me know how you get on. In
>> particular
>> let me know if you work out how to stop the QE occaisionally
>> corrupting
>> the TCT when using external channels.
>>
>> Regards,
>>
>> Alex
>>
>> ---------------------------------------------------------------------
>> ---
>> -
>> Take Surveys. Earn Cash. Influence the Future of IT Join
>> SourceForge.net's Techsay panel and you'll get the chance to share
>> your
>> opinions on IT & business topics through brief surveys -- and earn
>> cash
>> http://www.techsay.com/default.php?
>> page=join.php&p=sourceforge&CID=DEVDE
>> V
>> _______________________________________________
>> Linux-atm-general mailing list
>> Linux-atm-general@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/linux-atm-general
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: [PATCH] clean up pseries hcall interfaces
From: Levand, Geoffrey @ 2006-07-20 13:14 UTC (permalink / raw)
To: Anton Blanchard ,
linuxppc-dev-bounces+geoffrey.levand=am.sony.com, linuxppc-dev
Cc: paulus
> From: Anton Blanchard
>=20
> Our pseries hcall interfaces are out of control:
Seems like this in needed too... Untested.
Change the scope of some pSeries routines now called through
ppc_md to static.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
--
Index: a/arch/powerpc/platforms/pseries/lpar.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- a.orig/arch/powerpc/platforms/pseries/lpar.c 2006-07-18
12:37:47.000000000 -0700
+++ a/arch/powerpc/platforms/pseries/lpar.c 2006-07-20
05:18:59.000000000 -0700
@@ -268,7 +268,7 @@
cpu, hwcpu, vpa, ret);
}
=20
-long pSeries_lpar_hpte_insert(unsigned long hpte_group,
+static long pSeries_lpar_hpte_insert(unsigned long hpte_group,
unsigned long va, unsigned long pa,
unsigned long rflags, unsigned long
vflags,
int psize)
@@ -494,7 +494,7 @@
* Take a spinlock around flushes to avoid bouncing the hypervisor
tlbie
* lock.
*/
-void pSeries_lpar_flush_hash_range(unsigned long number, int local)
+static void pSeries_lpar_flush_hash_range(unsigned long number, int
local)
{
int i;
unsigned long flags =3D 0;
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Kumar Gala @ 2006-07-20 13:19 UTC (permalink / raw)
To: Marc Leeman; +Cc: linuxppc-dev
In-Reply-To: <20060720072134.GX5219@scorpius.homelinux.org>
On Jul 20, 2006, at 2:21 AM, Marc Leeman wrote:
>>> Though I do agree that there is a gap: it would be nice to have some
>>> place to submit the kernel patches;
>>
>> This should be the kernel. The general rule of thumb I've used is if
>> its useful to more than one other person its worth trying to get into
>> the kernel. However, I can see if you are doing a one off kernel for
>
> That is about the same rule that I use; luckily (a credit to the Linux
> kernel and other developers); I don't have to change much stuff like
> that.
>
>> your embedded product that getting your changes into the kernel
>> wouldn't be worth while. You have to have a desire to interact with
>> the community if you want to get your code in.
>
> There is a grey zone, but let's talk about a specific case:
>
> In my current queue, I have to write a Host Port Interface (HPI)
> protocol
> (serial) to a TI DSP. I would imagine that this is a useful
> contribution. However, using HPI is almost by nature limited to
> specific
> embedded designs (most of which differ slightly from one another).
> Furthermore; I will need to use a number of GPIO pins on a 834x
> processor. Using this needs to be backed by configuration settings in
> U-Boot. If someone else makes a similar design; it would most
> likely be
> with another processor family; and even then; they'll have other pins
> connected/used.
>
> Though the protocol would be a real nice addition; the physical
> connection/configuration make including it in the main kernel tree
> difficult.
Maybe, but your are just talking about abstracting what GPIO pins are
used, which is a minor issue.
>> Personally, I see it useful if for no other reason that someone will
>> fixup my board port if/when they change something which will make my
>> moving to a newer kernel release that much easier.
>
> Even though I would welcome this; our boards are included in larger
> expensive systems that would just be shipped back in case of problems;
> but we've never had functional (linux) problems (yet).
>
> Come to think of it, I have a number of minor patches for 8349SYS
> based
> configurations; where can I find the last devel code (next to 2.6.17)
> for patch creation (and to whom to send them back)?
Grab a git kernel from kernel.org/git, I'd say to use either linux/
kernel/git/torvalds/linux-2.6.git (Linus's tree) or linux/kernel/git/
paulus/powerpc.git (Paul's tree).
You'd send the patches to me as I'm the maintainer for 83xx stuff.
- kumar
^ permalink raw reply
* Re: AltiVec in the kernel
From: Kumar Gala @ 2006-07-20 13:23 UTC (permalink / raw)
To: matt; +Cc: 'Paul Mackerras', 'linuxppc-dev list'
In-Reply-To: <001301c6abf8$73d780e0$99dfdfdf@bakuhatsu.net>
On Jul 20, 2006, at 7:31 AM, Matt Sealey wrote:
>
>
>> But perhaps, in principle, couldn't one run four independent
>> streams in parallel? Thus, for example, on an SSL-enabled
>> web server, one could service multiple encryption/decryption
>> threads at once.
>>
>> In practice, I don't beleive the infrastructure for that kind
>> of parallelism is in place. I'm struggling to find a reason
>> to develop that kind of infrastructure. Mumble something about Cell.
>
> If not AltiVec there is potential to use some features which come
> with AltiVec like the data stream functionality. Or even the standard
> PPC cache control stuff would work.
>
> What's the case in the kernel for the memcpy functions etc., are
> they optimized for doing things like longword copies rather than
> byte-per-byte etc.? We found glibc sucked for that.
Matt, can I ask what exactly you are trying to accomplish? There is
a lot of work put into the kernel to ensure things are optimized.
I'd say far more so than gets put into user space.
- k
^ permalink raw reply
* RE: AltiVec in the kernel
From: Matt Sealey @ 2006-07-20 13:33 UTC (permalink / raw)
To: 'Kumar Gala'
Cc: 'Paul Mackerras', 'linuxppc-dev list'
In-Reply-To: <678C8D4E-C3AC-4F79-BFF2-5BF424682D04@kernel.crashing.org>
> Matt, can I ask what exactly you are trying to accomplish? There is
> a lot of work put into the kernel to ensure things are optimized.
> I'd say far more so than gets put into user space.
Just trying to find out what the general state of play is.
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
^ permalink raw reply
* Re: [Linux-ATM-General] mpc8360sar
From: Alex Zeffertt @ 2006-07-20 13:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-atm-general, linuxppc-embedded, Li Tony-r64360
In-Reply-To: <26296171-D21D-4FF3-B9C5-C6378064AF44@kernel.crashing.org>
>
> Any reason we dont try to get your work up stream into the mainline kernel?
>
> - kumar
>
I'd like to see it upstreamed - the more people who use it the more help I get!
However, mpc8360sar is built on Freescale's BSP which adds basic support for the
board, the MPC832xE-MDS, to the stock linux kernel. This support consists of the
following patches:
Patch0 : patch-2.6.11.bz2
Patch1 : linux-2.6.11-mpc8349e-general-20060414.patch
Patch2 : linux-2.6.11-mpc8349e-pci-3.patch
Patch3 : linux-2.6.11-mpc8349e-pci-agent.patch
Patch4 : linux-2.6.11-mpc8349e-watchdog.patch
Patch5 : linux-2.6.11-mpc83xx-sec2.patch
Patch6 : mpc832x-sec2v15-config-1.patch
Patch7 : linux-2.6.11-mpc8349e-usb-gadget.patch
Patch8 : linux-2.6.11-mpc8349e-usb-host.patch
Patch9 : linux-2.6.11-mpc8360-general-1.patch
Patch10 : linux-2.6.11-mpc8360-pci-agent.patch
Patch11 : linux-2.6.11-mpc832x-basic-4.patch
Patch12 : linux-2.6.11-mpc832x-pci-agent.patch
Patch13 : linux-2.6.11-mpc832x-spi-1.patch
Patch14 : linux-2.6.11-mpc832x-BIT.patch
Patch15 : linux-2.6.11-mpc83xx-ct-1.patch
Patch16 : linux-2.6.11-mpc832x-usb-gadget.patch
Patch17 : linux-2.6.11-mpc832x-atm-1.patch
I guess there's no point upstreaming mpc8360sar until freescale have
upstreamed these patches (and ported them to the current kernel).
Alex
PS It's probable that mpc8360sar actually only requires a handful of
the above patches to be applied.
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH] Fix Freescale high-speed USB hostdependency
From: Li Yang @ 2006-07-20 13:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, gregkh, linux-usb-devel
In-Reply-To: <93F26879-ECEB-4513-AA77-EE7285DF7961@kernel.crashing.org>
On 7/20/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jul 20, 2006, at 6:42 AM, Li Yang-r58472 wrote:
>
> > Another one in header file.
> >
> > ---
> > diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
> > index 679c1cd..8da2774 100644
> > --- a/drivers/usb/host/ehci.h
> > +++ b/drivers/usb/host/ehci.h
> > @@ -642,7 +642,7 @@ #endif
> >
> >
> > /
> > *---------------------------------------------------------------------
> > -
> > ---*/
> >
> > -#ifdef CONFIG_PPC_83xx
> > +#ifdef CONFIG_MPC834x
> > /* Some Freescale processors have an erratum in which the TT
> > * port number in the queue head was 0..N-1 instead of 1..N.
> > */
>
> Do we really want to make this change. What harm is there in having
> the ehci support for MPC834x build on all 83xx processors? I can't
> imagine we are going to config in support for ehci on anything that
> is MPC834x at this point and if you do, your device tree isn't going
> to have nodes in it so the drivers not going to bind against anything.
>
It's not very harmful. But it will cause some misunderstanding.
There were already some guys trying to use the 834x USB driver on 836x
and 832x. Anyway, it's a trivial patch. Please apply if it doesn't
cause much trouble.
> Finally, I got to believe Freescale's going to build some MPC83xx in
> the future with the high speed USB IP.
I can't tell exactly. But it's not likely to integrate this IP into a
chip with QE/CPM support. As QE/CPM has already provided full speed
USB support, and the USB speed is not very important for Netcomm
processors.
>
> - kumar
>
> >
> >> -----Original Message-----
> >> From: linux-usb-devel-bounces@lists.sourceforge.net
> >> [mailto:linux-usb-devel-bounces@lists.sourceforge.net] On Behalf Of
> > Kumar Gala
> >> Sent: Friday, July 14, 2006 9:52 PM
> >> To: Li Yang-r58472
> >> Cc: linuxppc-dev@ozlabs.org; gregkh@suse.de;
> >> linux-usb-devel@lists.sourceforge.net
> >> Subject: Re: [linux-usb-devel] [PATCH] Fix Freescale high-speed USB
> > hostdependency
> >>
> >> Acked-by: Kumar Gala <galak@kernel.crashing.org>
> >>
> >> On Jul 14, 2006, at 6:58 AM, Li Yang wrote:
> >>
> >>> The high-speed USB SOC only exists on MPC834x family not MPC83xx
> >>> family.
> >>>
> >>> Signed-off-by: Li Yang <leoli@freescale.com>
> >>>
> >>> ---
> >>>
> >>> drivers/usb/host/ehci-hcd.c | 2 +-
> >>> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-
> >>> hcd.c index 79f2d8b..3af1844 100644
> >>> --- a/drivers/usb/host/ehci-hcd.c
> >>> +++ b/drivers/usb/host/ehci-hcd.c
> >>> @@ -892,7 +892,7 @@ #include "ehci-pci.c"
> >>> #define EHCI_BUS_GLUED
> >>> #endif
> >>>
> >>> -#ifdef CONFIG_PPC_83xx
> >>> +#ifdef CONFIG_MPC834x
> >>> #include "ehci-fsl.c"
> >>> #define EHCI_BUS_GLUED
> >>> #endif
> >
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* RE: export-objs in spi Makefile broke in latest linuxppc_2_4_deve l [r eposted]?
From: Rowan, Chad @ 2006-07-20 13:38 UTC (permalink / raw)
To: Kumar Gala, hs; +Cc: linuxppc-embedded
Why should this be taken off list? Is it because it's Denx specific? Or
because it's 2.4 specific? There is active 5200 development on the 2.4
kernel at Denx and it seems relevant to this list.
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Thursday, July 20, 2006 8:12 AM
To: hs@denx.de
Cc: linuxppc-embedded@ozlabs.org; Chad.Rowan@thyssenkrupp.com
Subject: Re: export-objs in spi Makefile broke in latest linuxppc_2_4_deve l
[r eposted]?
On Jul 19, 2006, at 11:55 PM, Heiko Schocher wrote:
> Hello Chad
>
>> linuxppc_2_4_devel is alive and well.
>>
>> http://www.denx.de/cgi-bin/gitweb.cgi?
>> p=linuxppc_2_4_devel.git;a=shortlog
>
> You speak from the DENX linuxppc_2_4_devel Kernel? If so, I think
> you are right.
> I had the same problem, some days ago. I made a SPI bitbanging
> algorithm, but
> I dont know, if this goes in the git repository from DENX ...
> Wolfgang?
I think this issue should be taken off list.
- k
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH] Fix Freescale high-speed USB hostdependency
From: Kumar Gala @ 2006-07-20 13:42 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, gregkh, linux-usb-devel
In-Reply-To: <a0bc9bf80607200636q785180e0rca1f974c6fe6d127@mail.gmail.com>
On Jul 20, 2006, at 8:36 AM, Li Yang wrote:
> On 7/20/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>>
>> On Jul 20, 2006, at 6:42 AM, Li Yang-r58472 wrote:
>>
>> > Another one in header file.
>> >
>> > ---
>> > diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
>> > index 679c1cd..8da2774 100644
>> > --- a/drivers/usb/host/ehci.h
>> > +++ b/drivers/usb/host/ehci.h
>> > @@ -642,7 +642,7 @@ #endif
>> >
>> >
>> > /
>> >
>> *--------------------------------------------------------------------
>> -
>> > -
>> > ---*/
>> >
>> > -#ifdef CONFIG_PPC_83xx
>> > +#ifdef CONFIG_MPC834x
>> > /* Some Freescale processors have an erratum in which the TT
>> > * port number in the queue head was 0..N-1 instead of 1..N.
>> > */
>>
>> Do we really want to make this change. What harm is there in having
>> the ehci support for MPC834x build on all 83xx processors? I can't
>> imagine we are going to config in support for ehci on anything that
>> is MPC834x at this point and if you do, your device tree isn't going
>> to have nodes in it so the drivers not going to bind against
>> anything.
>>
>
> It's not very harmful. But it will cause some misunderstanding.
> There were already some guys trying to use the 834x USB driver on 836x
> and 832x. Anyway, it's a trivial patch. Please apply if it doesn't
> cause much trouble.
Is that more because the QE drivers aren't in the kernel tree?
>> Finally, I got to believe Freescale's going to build some MPC83xx in
>> the future with the high speed USB IP.
>
> I can't tell exactly. But it's not likely to integrate this IP into a
> chip with QE/CPM support. As QE/CPM has already provided full speed
> USB support, and the USB speed is not very important for Netcomm
> processors.
True, but not all 83xx are Netcomm processors.
- k
^ permalink raw reply
* Host USB on MPC8247
From: Uros Borovsak @ 2006-07-20 13:44 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I'm looking for host USB driver for MPC8247. We are using MV kernel
2.6.10 and I'm wondering, if there is a driver for this specific kernel.
I'm aware of cpm2usb project on sourceforge, but it is for kernel
2.6.13. How difficult would it be to patch only usb part of kernel from
2.6.10 to 2.6.13 so I could use that drivers. I only need suport for USB
storage devices, so that driver is enough for me.
Thanks,
Best regards,
Uros
^ permalink raw reply
* Re: export-objs in spi Makefile broke in latest linuxppc_2_4_deve l [r eposted]?
From: Kumar Gala @ 2006-07-20 13:52 UTC (permalink / raw)
To: Rowan, Chad; +Cc: hs, linuxppc-embedded
In-Reply-To: <86EC6E02268B3D4BA41C1B0C61FB14E60B4553CE@mdcexc01.na.ops.local>
On Jul 20, 2006, at 8:38 AM, Rowan, Chad wrote:
> Why should this be taken off list? Is it because it's Denx
> specific? Or
> because it's 2.4 specific? There is active 5200 development on the
> 2.4
> kernel at Denx and it seems relevant to this list.
Because its Denx specific, I believe the tree you are taking about is
maintained only by Denx and not a community tree.
- k
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Thursday, July 20, 2006 8:12 AM
> To: hs@denx.de
> Cc: linuxppc-embedded@ozlabs.org; Chad.Rowan@thyssenkrupp.com
> Subject: Re: export-objs in spi Makefile broke in latest
> linuxppc_2_4_deve l
> [r eposted]?
>
>
> On Jul 19, 2006, at 11:55 PM, Heiko Schocher wrote:
>
>> Hello Chad
>>
>>> linuxppc_2_4_devel is alive and well.
>>>
>>> http://www.denx.de/cgi-bin/gitweb.cgi?
>>> p=linuxppc_2_4_devel.git;a=shortlog
>>
>> You speak from the DENX linuxppc_2_4_devel Kernel? If so, I think
>> you are right.
>> I had the same problem, some days ago. I made a SPI bitbanging
>> algorithm, but
>> I dont know, if this goes in the git repository from DENX ...
>> Wolfgang?
>
> I think this issue should be taken off list.
>
> - k
^ permalink raw reply
* Re: [Linux-ATM-General] mpc8360sar
From: Kumar Gala @ 2006-07-20 13:54 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linux-atm-general, linuxppc-embedded, Li Tony-r64360
In-Reply-To: <44BF8634.2060009@cambridgebroadband.com>
On Jul 20, 2006, at 8:33 AM, Alex Zeffertt wrote:
>
>> Any reason we dont try to get your work up stream into the
>> mainline kernel?
>> - kumar
>
> I'd like to see it upstreamed - the more people who use it the more
> help I get!
>
> However, mpc8360sar is built on Freescale's BSP which adds basic
> support for the
> board, the MPC832xE-MDS, to the stock linux kernel. This support
> consists of the
> following patches:
>
> Patch0 : patch-2.6.11.bz2
> Patch1 : linux-2.6.11-mpc8349e-general-20060414.patch
> Patch2 : linux-2.6.11-mpc8349e-pci-3.patch
> Patch3 : linux-2.6.11-mpc8349e-pci-agent.patch
> Patch4 : linux-2.6.11-mpc8349e-watchdog.patch
> Patch5 : linux-2.6.11-mpc83xx-sec2.patch
> Patch6 : mpc832x-sec2v15-config-1.patch
> Patch7 : linux-2.6.11-mpc8349e-usb-gadget.patch
> Patch8 : linux-2.6.11-mpc8349e-usb-host.patch
> Patch9 : linux-2.6.11-mpc8360-general-1.patch
> Patch10 : linux-2.6.11-mpc8360-pci-agent.patch
> Patch11 : linux-2.6.11-mpc832x-basic-4.patch
> Patch12 : linux-2.6.11-mpc832x-pci-agent.patch
> Patch13 : linux-2.6.11-mpc832x-spi-1.patch
> Patch14 : linux-2.6.11-mpc832x-BIT.patch
> Patch15 : linux-2.6.11-mpc83xx-ct-1.patch
> Patch16 : linux-2.6.11-mpc832x-usb-gadget.patch
> Patch17 : linux-2.6.11-mpc832x-atm-1.patch
>
> I guess there's no point upstreaming mpc8360sar until freescale have
> upstreamed these patches (and ported them to the current kernel).
True, a large number of these patches are upstream, and if I had
access to MPC836x or MPC832x HW I'd work on getting the others that
are reasonable.
> Alex
>
> PS It's probable that mpc8360sar actually only requires a handful of
> the above patches to be applied.
Agreed.
- kumar
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH] Fix Freescale high-speed USB hostdependency
From: Li Yang @ 2006-07-20 14:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, gregkh, linux-usb-devel
In-Reply-To: <6DAE6213-B8D0-4226-9402-98B4F3FD907B@kernel.crashing.org>
On 7/20/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jul 20, 2006, at 8:36 AM, Li Yang wrote:
>
> > On 7/20/06, Kumar Gala <galak@kernel.crashing.org> wrote:
> >>
> >> On Jul 20, 2006, at 6:42 AM, Li Yang-r58472 wrote:
> >>
> >> > Another one in header file.
> >> >
> >> > ---
> >> > diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
> >> > index 679c1cd..8da2774 100644
> >> > --- a/drivers/usb/host/ehci.h
> >> > +++ b/drivers/usb/host/ehci.h
> >> > @@ -642,7 +642,7 @@ #endif
> >> >
> >> >
> >> > /
> >> >
> >> *--------------------------------------------------------------------
> >> -
> >> > -
> >> > ---*/
> >> >
> >> > -#ifdef CONFIG_PPC_83xx
> >> > +#ifdef CONFIG_MPC834x
> >> > /* Some Freescale processors have an erratum in which the TT
> >> > * port number in the queue head was 0..N-1 instead of 1..N.
> >> > */
> >>
> >> Do we really want to make this change. What harm is there in having
> >> the ehci support for MPC834x build on all 83xx processors? I can't
> >> imagine we are going to config in support for ehci on anything that
> >> is MPC834x at this point and if you do, your device tree isn't going
> >> to have nodes in it so the drivers not going to bind against
> >> anything.
> >>
> >
> > It's not very harmful. But it will cause some misunderstanding.
> > There were already some guys trying to use the 834x USB driver on 836x
> > and 832x. Anyway, it's a trivial patch. Please apply if it doesn't
> > cause much trouble.
>
> Is that more because the QE drivers aren't in the kernel tree?
>
> >> Finally, I got to believe Freescale's going to build some MPC83xx in
> >> the future with the high speed USB IP.
> >
> > I can't tell exactly. But it's not likely to integrate this IP into a
> > chip with QE/CPM support. As QE/CPM has already provided full speed
> > USB support, and the USB speed is not very important for Netcomm
> > processors.
>
> True, but not all 83xx are Netcomm processors.
83xx=PowerQUICC II Pro, IMHO.
I just give my 2 cents. It's up to you to decide as you are the maintainer. :)
>
> - k
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* RE: export-objs in spi Makefile broke in latest linuxppc_2_4_deve l [r eposted]?
From: Rowan, Chad @ 2006-07-20 14:09 UTC (permalink / raw)
To: Kumar Gala, Rowan, Chad; +Cc: hs, linuxppc-embedded
Agreed.
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Thursday, July 20, 2006 8:52 AM
To: Rowan, Chad
Cc: hs@denx.de; linuxppc-embedded@ozlabs.org
Subject: Re: export-objs in spi Makefile broke in latest linuxppc_2_4_deve l
[r eposted]?
On Jul 20, 2006, at 8:38 AM, Rowan, Chad wrote:
> Why should this be taken off list? Is it because it's Denx
> specific? Or
> because it's 2.4 specific? There is active 5200 development on the
> 2.4
> kernel at Denx and it seems relevant to this list.
Because its Denx specific, I believe the tree you are taking about is
maintained only by Denx and not a community tree.
- k
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Thursday, July 20, 2006 8:12 AM
> To: hs@denx.de
> Cc: linuxppc-embedded@ozlabs.org; Chad.Rowan@thyssenkrupp.com
> Subject: Re: export-objs in spi Makefile broke in latest
> linuxppc_2_4_deve l
> [r eposted]?
>
>
> On Jul 19, 2006, at 11:55 PM, Heiko Schocher wrote:
>
>> Hello Chad
>>
>>> linuxppc_2_4_devel is alive and well.
>>>
>>> http://www.denx.de/cgi-bin/gitweb.cgi?
>>> p=linuxppc_2_4_devel.git;a=shortlog
>>
>> You speak from the DENX linuxppc_2_4_devel Kernel? If so, I think
>> you are right.
>> I had the same problem, some days ago. I made a SPI bitbanging
>> algorithm, but
>> I dont know, if this goes in the git repository from DENX ...
>> Wolfgang?
>
> I think this issue should be taken off list.
>
> - k
^ permalink raw reply
* Re: MPC8260 SCC UART hardware flow control
From: Laurent Pinchart @ 2006-07-20 14:30 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060719183740.22636352681@atlas.denx.de>
On Wednesday 19 July 2006 20:37, Wolfgang Denk wrote:
> In message <200607191718.00328.laurent.pinchart@tbox.biz> you wrote:
> > I was wondering if anyone had implemented hardware flow control support
> > in the cpm_uart driver. If not, I would appreciate pointers regarding how
> > to do so.
>
> You can probably take our 2.4 kernel code as a starting point. But be
> aware of the inherent restrictions of the CPM, see
> http://www.denx.de/wiki/view/DULG/UseSCCUARTWithHardwareHandshake
I didn't know the CPM implemented hardware flow control as a DTE only. Thanks
for the information. As our hardware connects to DCE devices this shouldn't
be a problem.
> [In the end, you might want to configure the handshake signals as
> GPIO lines and controll these manually. But then you will have to ask
> yourself why you are using a CPM...]
Laurent Pinchart
^ permalink raw reply
* Re: MPC8260 SCC UART hardware flow control
From: Laurent Pinchart @ 2006-07-20 14:32 UTC (permalink / raw)
To: Mathieu Deschamps; +Cc: linuxppc-embedded
In-Reply-To: <200607201018.13445.mathieu.deschamps@com2gether.net>
Hi Mathieu,
> > Hi everybody,
> >
> > I was wondering if anyone had implemented hardware flow control support
> > in the cpm_uart driver. If not, I would appreciate pointers regarding how
> > to do so.
> >
> > Best regards,
> >
> > Laurent Pinchart
>
> I had. PQ2 CPM is a dedicated part which handles this aspect for you via
> its microcode. This also means you can't play with it the old way and
> making your own HHS with a CD/DSR :). Back to seriousness, rather this
> means you needn't adding modem signal handling in cpm_uart driver. So don't
> define modem_something that's an ancient reliq from the times, I guess, no
> CPM was put auxillary.
>
> So how to tell CPM to cope with HHS ? Simple, you "just" have to put SCC's
> Dedicated pins the right way which depends on your board type. Remember you
> can't do any HHS with SMC. Refer to Dedicated Pins chapter in the
> litterature [41.4.2]. Also take a look at SCC GSMR register [20.8] and to
> SCC UART mode PSMR register [21-14] to maybe use protocol specificities.
Thanks.
> When you'll have your kernel ready, you would do probably something like :
> stty -F $port crtscts $SPEED
I suppose I also have to add support for the CRTSCTS flag in set_termios.
> As Wolfgang said HHS works for DTE-DCE only (roughly but visually you must
> have plugs opposite gender on both ends), trying DTE-DTE HHS dialog is
> bound to failure despite time spend on it.
I'll disable hardware flow control if I need DTE-DTE communication.
Thanks for your help.
Laurent Pinchart
^ permalink raw reply
* Deepak C Shetty is out of the office.
From: Deepak C Shetty @ 2006-07-20 15:04 UTC (permalink / raw)
To: linuxppc-dev
I will be out of the office starting 20/07/2006 and will not return until
22/07/2006.
For all HTX related technical issues, pls contact mehul.patel@in.ibm.com &
for other issues pls contact my manager ahema@in.ibm.com
^ permalink raw reply
* I2C with bus muxes
From: Ben Warren @ 2006-07-20 15:16 UTC (permalink / raw)
To: Linuxppc-embedded
Hello,
Has anyone implemented devices like the Philips PCA954x I2C bus muxes
under the /sysfs device model? I have some optical transponders on my
board that through the wisdom of some committee all have the same fixed
I2C address. To get around this, we put them behind muxes, creating
'virtual' I2C busses. I imagine this could be modeled something like
the USB hub model, but that's just a first stab.
regards,
Ben
^ permalink raw reply
* Re: I2C with bus muxes
From: Travis B. Sawyer @ 2006-07-20 15:22 UTC (permalink / raw)
To: bwarren; +Cc: Linuxppc-embedded
In-Reply-To: <1153408592.19682.39.camel@saruman.qstreams.net>
Ben Warren wrote:
> Hello,
>
> Has anyone implemented devices like the Philips PCA954x I2C bus muxes
> under the /sysfs device model? I have some optical transponders on my
> board that through the wisdom of some committee all have the same fixed
> I2C address. To get around this, we put them behind muxes, creating
> 'virtual' I2C busses. I imagine this could be modeled something like
> the USB hub model, but that's just a first stab.
>
>
Ben:
I have a driver for 2.4.x that works with our SFP/XFPs. We also have a
bunch of other 'stuff'
hanging off of muxes. I haven't given it a go on 2.6, but I have it
compiled and it doesn't complain on
startup.
Not sure if I should send it here, as it won't be in patch form...
Lemme know if you want a look-see,
Travis
^ permalink raw reply
* multicast for 8260 for 2.6.13
From: Harnois Anne-Sophie @ 2006-07-20 14:45 UTC (permalink / raw)
To: linuxppc-embedded
Hello
In the file arch/ppc/8260_io/fcc_enet.c, set_multicast_list function is
commented out and I can't figure out why.=20
I checked the code, removed the comments and tried it, and multicast
seemed to work properly.=20
What am I missing?
Could someone explain me why this is commented out?
Many thanks,
Anne-Sophie
^ 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