* 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
* 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
* 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: 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: [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: [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: 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
* PHY Howto ?
From: David H. Lynch Jr. @ 2006-07-20 17:52 UTC (permalink / raw)
To: linuxppc-embedded
If I am writing a network MAC driver, for hardware that has a phy
that is already supported, if I provide the appropriate mdio_read() and
mdio_write() calls to access the phy registers, and setup my config to
include phylib and drivers for my specific phy, what else do I have to
take care of with respect to the phy within my driver ?
Are there some resources, howto's, examples, ... demonstrating
how to use phylib ?
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: PHY Howto ?
From: Vitaly Bordug @ 2006-07-20 18:01 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-embedded
In-Reply-To: <44BFC2EF.5020305@dlasys.net>
On Thu, 20 Jul 2006 13:52:47 -0400
"David H. Lynch Jr." <dhlii@dlasys.net> wrote:
> If I am writing a network MAC driver, for hardware that has a phy
> that is already supported, if I provide the appropriate mdio_read() and
> mdio_write() calls to access the phy registers, and setup my config to
> include phylib and drivers for my specific phy, what else do I have to
> take care of with respect to the phy within my driver ?
>
> Are there some resources, howto's, examples, ... demonstrating
> how to use phylib ?
There is pretty good writeup in Documentation about your concern, find it at
Documentation/networking/phy.txt . Live example is obviously drivers/net/gianfar*
--
Sincerely,
Vitaly
^ permalink raw reply
* Problem with ibm_emac driver
From: Ian Remmler @ 2006-07-20 18:32 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm having a problem with the ibm_emac driver for the built in
gigabit ethernet on the 440gx. I was hoping someone could shed
some light or at least point me in the right direction.
I'm using a GMS P502 board runing 2.4.27-pre3 (from GMS). The
problem we are having is this: when we push data over the emac
interface (eth0 and eth1 both show the problem), we sporadically
get a "MAL: Rx descriptor error..." from mal_rxde in
ibm_ocp_mal.c.
Occasionally, the interface will "freeze up" for a few seconds.
An ifconfig down/up will bring it back, but from then on it will
freeze up again right away.
It looks to me like this error indicates that we're out of RX
buffers, but I don't how we would be running out. I'm no kernel
or networking expert, but I thought the TCP stack would take
care of throttling itself to prevent that sort of thing. I
would appreciate any help.
Thanks,
- Ian.
--
"A shark on whiskey is mighty risky.
A shark on beer is a beer engineer."
-- Dr. Worm
^ permalink raw reply
* Re: page locking in PowerPC cores
From: Benjamin Herrenschmidt @ 2006-07-20 18:50 UTC (permalink / raw)
To: Parav Pandit; +Cc: linuxppc-embedded
In-Reply-To: <20060719044510.24117.qmail@web36604.mail.mud.yahoo.com>
Only memory mapped into userland contexts can be paged out in the first
place.
Ben.
^ 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