* Re: AltiVec in the kernel
From: Linas Vepstas @ 2006-07-20 17:42 UTC (permalink / raw)
To: Matt Sealey; +Cc: 'linuxppc-dev list', 'Paul Mackerras'
In-Reply-To: <001301c6abf8$73d780e0$99dfdfdf@bakuhatsu.net>
On Thu, Jul 20, 2006 at 07:31:32AM -0500, Matt Sealey wrote:
>
> 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.?
arch/powerpc/lib/copy_32.S
arch/powerpc/lib/memcpy_64.S
Looks pretty darned optimized to me.
> We found glibc sucked for that.
Only because someone was asleep at the wheel, or there was a bug.
When glibc gets ported to a new architecture, one of the earliest
tasks is to create optimized versions of memcpy and the like.
Presumably, on powerpc, this would have been done more than a
decade ago; its hard for me to imagine that there'd be a problem
there. Now, I haven't looked at the code, but I just can't imagine
how this would not have been found and fixed by now. Is there
really a problem wiht glibc performance on powerpc? I mean,
this is a pretty serious accusation, and something that should
be fixed asap.
--linas
^ permalink raw reply
* Re: [Linux-ATM-General] mpc8360sar
From: Alex Zeffertt @ 2006-07-20 16:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-atm-general, linuxppc-embedded, Li Tony-r64360
In-Reply-To: <EFE44D26-140D-4E33-A6BF-8D2C13C89821@kernel.crashing.org>
Kumar Gala wrote:
>
> 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
Tony, can you let me know when CONFIG_MPC832XE_MDS support is upstreamed
to a kernel.org kernel. I'll then try to get the mpc8360sar working with this
kernel and then upstream it.
Alex
PS I'm not entirely sure how "upstreaming" is done.
^ permalink raw reply
* Re: [PATCH] panic_on_oops: remove ssleep()
From: Paul Mackerras @ 2006-07-20 16:03 UTC (permalink / raw)
To: Horms
Cc: Andrew Morton, Chris Zankel, Tony Luck, linux-ia64, discuss,
Andi Kleen, linux-kernel, linuxppc-dev, Anton Blanchard,
Russell King
In-Reply-To: <31687.FP.7244@verge.net.au>
Horms writes:
> This patch is part of an effort to unify the panic_on_oops behaviour
> across all architectures that implement it.
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: multicast for 8260 for 2.6.13
From: Dan Malek @ 2006-07-20 15:44 UTC (permalink / raw)
To: Harnois Anne-Sophie; +Cc: linuxppc-embedded
In-Reply-To: <1CFEB358338412458B21FAA0D78FE86D5D2488@rennsmail02.eu.thmulti.com>
On Jul 20, 2006, at 10:45 AM, Harnois Anne-Sophie wrote:
> In the file arch/ppc/8260_io/fcc_enet.c, set_multicast_list
> function is
> commented out and I can't figure out why.
Read the mailing list archives.
> I checked the code, removed the comments and tried it, and multicast
> seemed to work properly.
Sorry, but that code will never work on a 82xx.
> What am I missing?
> Could someone explain me why this is commented out?
Because it was copied from the 8xx many years ago when
I ported the driver, and the 82xx lacks the CRC generator
support. You can enable promiscuous mode, which is
what I suspect you did, and then the Linux IP stack will
do the multicast filtering.
By the way, this driver is obsolete and you should be
using the version in drivers/net/fs_enet.
Thanks.
-- Dan
^ permalink raw reply
* Re: multicast for 8260 for 2.6.13
From: Vitaly Bordug @ 2006-07-20 15:41 UTC (permalink / raw)
To: Harnois Anne-Sophie; +Cc: linuxppc-embedded
In-Reply-To: <1CFEB358338412458B21FAA0D78FE86D5D2488@rennsmail02.eu.thmulti.com>
On Thu, 20 Jul 2006 16:45:11 +0200
"Harnois Anne-Sophie" <anne-sophie.harnois@thomson.net> wrote:
> 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.
> I checked the code, removed the comments and tried it, and multicast
> seemed to work properly.
>
> What am I missing?
> Could someone explain me why this is commented out?
The reason is because the arch/ppc/8260_io/* is deprecated by drivers/net/fs_enet, hence
people switched to use it...
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: I2C with bus muxes
From: Ben Warren @ 2006-07-20 15:36 UTC (permalink / raw)
To: Travis B. Sawyer; +Cc: Linuxppc-embedded
In-Reply-To: <44BF9FBA.8030201@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 678 bytes --]
Thanks Travis,
On Thu, 2006-07-20 at 11:22 -0400, Travis B. Sawyer wrote:
> 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.
>
I'm happy to see anything. Due to time constraints, I may end up doing
most of my devices stuff 2.4-style anyway, at least for now, since I
have a much firmer grasp on the concepts...
> Not sure if I should send it here, as it won't be in patch form...
>
Please pass your code along whenever it's convenient. Your call whether
to the list or just to me.
Cheers,
Ben
[-- Attachment #2: Type: text/html, Size: 1212 bytes --]
^ 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
* 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
* 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
* 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
* 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
* 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: 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: [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: [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: 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
* 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: [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
* 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: 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: [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: 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: 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: [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: [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
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