* Re: [PATCH] i2c: Race fix for i2c-mpc.c
From: Kumar Gala @ 2005-05-17 16:12 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Asier Llano Palacios, ML linuxppc-embedded
In-Reply-To: <4288C4FD.8080104@246tNt.com>
Sylvain,
Looks reasonable to me. Add a Signed-off-by: Kumar Gala=20
<kumar.gala@freescale.com> line and sent to GregKH, lm-sensors guys. =20
CC me if you would.
- kumar
On May 16, 2005, at 11:06 AM, Sylvain Munaut wrote:
> Kumar Gala wrote:
> > Sylvain,
> >
> > Are you really still using the OCP side of the driver?=A0 Do we need =
a
> > similar fix for the platform driver side?
>
> /me hits himself with a hammer
>
> Damn I included the wrong diff ... Sorry about that, the good one is
> in attachment.
>
>
>
> No I don't use the OCP side but I changed both to stay coherent. I=20
> don't
> experience the problem myself, it's Asier who reported it and it
> apparently mostly shows up on the second i2c bus (where I have nothing
> on my hardware and anyway my bootloader init I2C beforehand ...).
>
> But the patch looks correct, when a bus is added, it should be ready =
to
> be used.
>
>
>
> =A0=A0=A0=A0=A0=A0=A0 Sylvain
>
>
>
> ---
> i2c: Race fix for i2c-mpc.c
>
> The problem was that the clock speed and driver data is
> initialized after the i2c adapter was added. This caused
> the i2c bus to start working at a wrong speed. (Mostly
> noticable on the second bus on mpc5200)
>
> With this patch we've tried to keep the i2c adapter
> working perfectly all the time it is included in the system.
> Initialize before added, Remove garbage after deleleted.
>
>
>
> Submitted-by: Asier Llano Palacios
> Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
> ---
> <i2c-mpc-racefix.diff>=
^ permalink raw reply
* Re: What ethernet driver to use in 2.6.8.1 instead of gianfar in 2.6.11.x?
From: Kumar Gala @ 2005-05-17 15:41 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <4289DBE9.9080002@anagramm.de>
On May 17, 2005, at 6:56 AM, Clemens Koller wrote:
> Hello, again,
>
> for some tests and glibc-builds I want to work with a 2.6.8.1 kernel
> temporarily on a freescale mpc8540.
Out of interest, what issues did you have with 2.6.11.x?
> In 2.6.8.1 there was no gianfar ethernet driver. Is it okay to use the
> fec drivers instead of the gianfar or is it better to put the gianfar
> drivers back into 2.6.8.1? (100Mbps are okay for that testing)
I doubt fec drivers would ever work for the TSECs. You should be able
to pull the driver code out of 2.6.11.x for gianfar back into 2.6.8.1
w/o any real issue.
> Maybe somebody can get me a working .config for 2.6.8.1 and mpc8540ads?
Can you start with the .config file that exists in the 2.6.11 ?
- kumar
^ permalink raw reply
* Re: [PATCH] BOOKE_WDT Part 1/2 (Re: PPC 44x Watchdog timer)
From: Takeharu KATO @ 2005-05-17 14:47 UTC (permalink / raw)
To: Takeharu KATO; +Cc: Glenn Burkhardt, Gala Kumar K.-galak, linuxppc-embedded
In-Reply-To: <42898825.3000803@ybb.ne.jp>
Hi Kumar:
>> No problem, can you replace all the cmd line parsing with
>> early_param() code in arch/ppc/kernel/setup.c. Take a look at
>> arch/ppc64/kernel/setup.c for an example. We still need to add a call
>> to parse_early_param() in setup_arch().
>>
> Sorry, I can not figure out what you want.
> As far as I look the source tree,arch/ppc/kernel/setup.c does not have
> the function called early_param.
> Would you give me a more precise explanation?
>
On second thought, I make sense what you said.
You asked me that I make some kind of cleanups, didn't you?
If it is true, I'll try to clean up these setups, but it may be
take the time.
^ permalink raw reply
* Re: MPC885 - USB HCI drivers.
From: Guillaume Autran @ 2005-05-17 12:13 UTC (permalink / raw)
To: Mike Rapoport; +Cc: linuxppc-embedded
In-Reply-To: <4289D685.4070406@compulab.co.il>
Mike Rapoport wrote:
> Pantelis Antoniou wrote:
>
>> Also they're 2.4 only :)
>>
>> I'll try to clean them up and post them sometime this week.
>>
>> But I don't have time left to hack them for 2.6. I'll need
>> vict^H^H^Holunteers to do it...
>>
>> Regards
>>
>> Pantelis
>>
> I think you've found one _vict^H^H^Holunteer_ :)
> I've started to port the m82xxhci to 2.6. For now it is get compiled
> (mostly). :))
>
Add me to the list !
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
^ permalink raw reply
* Re: MPC885 - USB HCI drivers.
From: Guillaume Autran @ 2005-05-17 12:10 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
In-Reply-To: <4289A635.5000509@intracom.gr>
Hi Pantelis,
Are your drivers compatible with linux kernel 2.6.x ?
I'll be interested to have a look at them if you don't mind.
Also, do you think an USB bus analyzer is a *must have* in order to work
on the drivers ?
Regards,
Guillaume.
Pantelis Antoniou wrote:
> Wolfgang Denk wrote:
>
>> Dear Mike,
>>
>> in message <428995CB.4050301@compulab.co.il> you wrote:
>>
>>> Do you know if the same is applicable to CPM2 USB controllers
>>> present for example on mpc8247?
>>
>>
>>
>> Sorry, I don't know from personal experience. But from what I heard
>> there might be some "surprises", too.
>>
>>
>>> The Freescale sales representative we work with actually says that
>>> CPM2 USB host controller is working well.
>>
>>
>>
>> Of course they do. They say the same for the 850 and 823 :-(
>>
>> Best regards,
>>
>> Wolfgang Denk
>>
>
> Well I have USB host drivers for both 8xx & 82xx working.
>
> It was not a piece of cake exactly to get them to work
> but they seem to work fine even under heavy traffic.
>
> However I use them connected to a specific peripheral
> so I don't know how well they fare when used as a PC
> style USB host controller.
>
> YMMV
>
> Regards
>
> Pantelis
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
^ permalink raw reply
* What ethernet driver to use in 2.6.8.1 instead of gianfar in 2.6.11.x?
From: Clemens Koller @ 2005-05-17 11:56 UTC (permalink / raw)
To: linuxppc-embedded
Hello, again,
for some tests and glibc-builds I want to work with a 2.6.8.1 kernel
temporarily on a freescale mpc8540.
In 2.6.8.1 there was no gianfar ethernet driver. Is it okay to use the
fec drivers instead of the gianfar or is it better to put the gianfar
drivers back into 2.6.8.1? (100Mbps are okay for that testing)
Maybe somebody can get me a working .config for 2.6.8.1 and mpc8540ads?
Thanks in advance,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: MPC885 - USB HCI drivers.
From: Mike Rapoport @ 2005-05-17 11:33 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
In-Reply-To: <4289BD01.5080805@intracom.gr>
Pantelis Antoniou wrote:
> Also they're 2.4 only :)
>
> I'll try to clean them up and post them sometime this week.
>
> But I don't have time left to hack them for 2.6. I'll need
> vict^H^H^Holunteers to do it...
>
> Regards
>
> Pantelis
>
I think you've found one _vict^H^H^Holunteer_ :)
I've started to port the m82xxhci to 2.6. For now it is get compiled
(mostly). :))
--
Sincerely yours,
Mike
^ permalink raw reply
* Re: MPC885 - USB HCI drivers.
From: Bryan O'Donoghue @ 2005-05-17 9:58 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
In-Reply-To: <4289A635.5000509@intracom.gr>
Pantelis Antoniou wrote:
> Well I have USB host drivers for both 8xx & 82xx working.
Speaking of which... would it not be a good idea, to get these comitted
to the 2.6 tree... at some stage ... at least to stop people
periodically posting to this list... saying "Dear all have spent 2
months, writing code for m8xx_hci drivers", when it's a needless
replication of effort ?
> However I use them connected to a specific peripheral
> so I don't know how well they fare when used as a PC
> style USB host controller.
Also, one easy way to find out, how well or badly said code performs, in
hetrogenous environments, is to... suck it and see.
As I was attempting to intimate above, I'm sure there'd be a legion of
eager people to debug, modify and recode such drivers, if there lived in
an obvious place... in the 2.6 tree.
Just my €0.02.
--
Best,
Bryan
^ permalink raw reply
* Re: MPC885 - USB HCI drivers.
From: Pantelis Antoniou @ 2005-05-17 9:44 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: linuxppc-embedded
In-Reply-To: <4434E283.3000201@eircom.net>
Bryan O'Donoghue wrote:
> Pantelis Antoniou wrote:
>
>
>>Well I have USB host drivers for both 8xx & 82xx working.
>
>
> Speaking of which... would it not be a good idea, to get these comitted
> to the 2.6 tree... at some stage ... at least to stop people
> periodically posting to this list... saying "Dear all have spent 2
> months, writing code for m8xx_hci drivers", when it's a needless
> replication of effort ?
>
Well, they are too hideous for human eyes :)
>
>>However I use them connected to a specific peripheral
>>so I don't know how well they fare when used as a PC
>>style USB host controller.
>
>
> Also, one easy way to find out, how well or badly said code performs, in
> hetrogenous environments, is to... suck it and see.
>
> As I was attempting to intimate above, I'm sure there'd be a legion of
> eager people to debug, modify and recode such drivers, if there lived in
> an obvious place... in the 2.6 tree.
>
> Just my €0.02.
>
Also they're 2.4 only :)
I'll try to clean them up and post them sometime this week.
But I don't have time left to hack them for 2.6. I'll need
vict^H^H^Holunteers to do it...
Regards
Pantelis
> --
>
> Best,
> Bryan
>
>
^ permalink raw reply
* Starting UDHCP server at startup
From: Atit_Shah @ 2005-05-17 9:35 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I wish to start the udhcp server at boot up through the start up
script. I create a file S47udhcpd in /etc/init.d/ with the following
contents:
#!/bin/sh
PKG=3D"udhcp server"
STARTCMD=3D"/usr/sbin/udhcpd"
STOPCMD=3D"killall udhcpd"
. /etc/init.d/common
This is the last commond to be executed ie just before the linux prompt
ask for the login and password.
When I boot the system I get the following error message "SIOCGIFADDR
failed, is the interface up and configured?: Cannot assign requested
address."
If I give the command "udhcpd" in my /etc/profile file the server
starts. Why does this happen?=20
If I am having this for a router I will need to run udhcpd the moment it
comes...how will I do this?
Regards
Atit
DISCLAIMER:
This email (including any attachments) is intended for the sole use of =
the intended recipient/s and may contain material that is CONFIDENTIAL =
AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or =
copying or distribution or forwarding of any or all of the contents in =
this message is STRICTLY PROHIBITED. If you are not the intended =
recipient, please contact the sender by email and delete all copies; =
your cooperation in this regard is appreciated.
^ permalink raw reply
* Re: MPC885 - USB HCI drivers.
From: Pantelis Antoniou @ 2005-05-17 8:07 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20050517081558.74BA0C1512@atlas.denx.de>
Wolfgang Denk wrote:
> Dear Mike,
>
> in message <428995CB.4050301@compulab.co.il> you wrote:
>
>>Do you know if the same is applicable to CPM2 USB controllers present
>>for example on mpc8247?
>
>
> Sorry, I don't know from personal experience. But from what I heard
> there might be some "surprises", too.
>
>
>>The Freescale sales representative we work with actually says that CPM2
>>USB host controller is working well.
>
>
> Of course they do. They say the same for the 850 and 823 :-(
>
> Best regards,
>
> Wolfgang Denk
>
Well I have USB host drivers for both 8xx & 82xx working.
It was not a piece of cake exactly to get them to work
but they seem to work fine even under heavy traffic.
However I use them connected to a specific peripheral
so I don't know how well they fare when used as a PC
style USB host controller.
YMMV
Regards
Pantelis
^ permalink raw reply
* Re: MPC885 - USB HCI drivers.
From: Wolfgang Denk @ 2005-05-17 8:15 UTC (permalink / raw)
To: Mike Rapoport; +Cc: linuxppc-embedded
In-Reply-To: <428995CB.4050301@compulab.co.il>
Dear Mike,
in message <428995CB.4050301@compulab.co.il> you wrote:
>
> Do you know if the same is applicable to CPM2 USB controllers present
> for example on mpc8247?
Sorry, I don't know from personal experience. But from what I heard
there might be some "surprises", too.
> The Freescale sales representative we work with actually says that CPM2
> USB host controller is working well.
Of course they do. They say the same for the 850 and 823 :-(
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I haven't lost my mind -- it's backed up on tape somewhere.
^ permalink raw reply
* RE: MPC885 - USB HCI drivers.
From: Jonathan Masel @ 2005-05-17 8:28 UTC (permalink / raw)
To: 'Kylo Ginsberg'; +Cc: 'PPC_LINUX'
In-Reply-To: <0d07fbd5d90d129227b4f579067f2d16@embeddededge.com>
CPM USB controllers have their quirks and erratas, but they do work. Most
erratas are documented but I'm not sure all are - we identified a couple and
reported them back to Freescale, but I don't know if they've updated their
web site in this regard.
I'm not sure what "software hacks" means but they don't require CPM
downloads or hardware modifications to work. It is also not true that they
can only support one device at a time (though yes, you do need an external
hub).
Bottom line: it's not easy getting them to work, but I can assure you that
there are software packages that do so (we have one). They're not free - but
neither are the USB controllers. Your choice!
Jonathan Masel
On May 16, 2005, at 6:39 PM, Kylo Ginsberg wrote:
> Are there known problems with CPM-based USB controllers?
The original CPM USB controller was only supposed to be
a device side controller. With some software hacks, CPM
microcode downloads, and even some hardware modifications,
you can often get it to work as a host in some static situations.
It doesn't have a built in root hub, you usually concentrate
on making it work with one specific device for a particular
product. You may find some application notes on the
Freescale web site, but I haven't seem them lately.
Take Wolfgang's advice, it's easier to find a way to
attach a real USB controller than to make this one
work as you probably expect.
Thanks.
-- Dan
^ permalink raw reply
* RE: MPC860 CP / CPM Misbehaving
From: Wrobel Heinz-r39252 @ 2005-05-17 6:41 UTC (permalink / raw)
To: Martin, Tim, 'linuxppc-embedded@ozlabs.org'
> descriptors (BDs) from the CPM with the OV bit set (bit 14 of the RxBD
> status/control field, "Overrun. Set when a receiver overrun
> occurs during
> reception").
Check the following:
- SDRAM setup. If ORx(BIH)=1 makes the problem go away, your burst setup or the /TA pullup is broken. NB: Neither the SCC nor the SMC do bursts.
- Check pullups as per UM recommendation. I tend to recommend 1k.
- Did you by accident happen to enable any IDMA lines?
- Did you happen to misconfigure RCCR(DRxM)?
- Did you happen to misconfigure the SDCR?
One other thing. If you have an old BDM debugger *and* if the problem occurs *only* with the BDM debugger hooked up, you may want to check for an update or replacement. Old debuggers sometimes used a method to do BDM which could stall the DMAs in the machine and cause this kind of overrun/underrun effect.
Heinz
^ permalink raw reply
* Re: MPC885 - USB HCI drivers.
From: Mike Rapoport @ 2005-05-17 6:57 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20050516232744.F106DC1512@atlas.denx.de>
Wolfgang Denk wrote:
>In message <61cc712d050516153941bc3b26@mail.gmail.com> you wrote:
>
>
>>>My advice: use a _real_ USB controller.
>>>
>>>
>>Are there known problems with CPM-based USB controllers? I'm
>>
>>
>
>Ummmm... yes, there are. Especially if you want to use it as a host
>comtroller (which is never was designed for). Even more, if there
>might be other periopherals in your system that might need a bit a
>CPM performance. Or ...
>
>
>
Do you know if the same is applicable to CPM2 USB controllers present
for example on mpc8247?
>No, I better stop here. Please ask your Freecale sales representa-
>tive. He may know better. [Or not, maybe.]
>
>
The Freescale sales representative we work with actually says that CPM2
USB host controller is working well.
>Best regards,
>
>Wolfgang Denk
>
>
--
Sincerely yours,
Mike
^ permalink raw reply
* Re: [PATCH] BOOKE_WDT Part 1/2 (Re: PPC 44x Watchdog timer)
From: Takeharu KATO @ 2005-05-17 5:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: Glenn Burkhardt, Gala Kumar K.-galak, linuxppc-embedded
In-Reply-To: <63792af268f18c480d5ecf218a4e61af@freescale.com>
Hi Kumar:
Kumar Gala wrote:
> No problem, can you replace all the cmd line parsing with early_param()
> code in arch/ppc/kernel/setup.c. Take a look at
> arch/ppc64/kernel/setup.c for an example. We still need to add a call
> to parse_early_param() in setup_arch().
>
Sorry, I can not figure out what you want.
As far as I look the source tree,arch/ppc/kernel/setup.c does not have
the function called early_param.
Would you give me a more precise explanation?
> Matt & I need to talk about the driver patch. Once I have more feedback
> on that I'll let you know. The major issue I have is having the
> interrupt handler in drivers/char/watchdog/.. instead of
> arch/ppc/kernel/traps.c. However, I dont have a good idea how to
> structure the changes.
>
Certainly, moving the interrupt handler from
drivers/char/watchdog/booke_wdt.c to arch/ppc/kernel/traps.c
is easy, but I can not tell whether it is good or not.
But the handler is not used by the core kernel.
From this point of view, the handler should not be placed
in arch/ppc/kernel/traps.c. This is the reason why I locate
the exception handler in the driver part.
Anyway, I'll try to move this handler into arch/ppc/kernel/traps.c
for the moment.
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Benjamin Herrenschmidt @ 2005-05-17 3:14 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <2dd506f0a6d4b03e771c0bc9d80735e6@embeddededge.com>
On Mon, 2005-05-16 at 16:31 -0400, Dan Malek wrote:
> On May 16, 2005, at 2:06 PM, Mark A. Greer wrote:
>
> > Oops...
> > /me unintentionally stepped into the middle of a flame war :)
>
> Just pee on it :-)
>
> > To be clear, "offender" == board that has an io_block_mapping below
> > the 3 GB line.
>
> That is one of the obvious changes. You are likely to find some other
> assumptions
> that may need attention. The problem with io_block_mapping is you just
> can't
> remove it, you have to fix up all of the code that is based on the
> assumption these
> spaces are mapped. You are likely to find yourself in a situation
> where you need
> access to some board control registers before VM is set up and you can
> call
> ioremap(). So, you will find yourself doing some hack in head.S to map
> BAT
> registers to get access to this, which is exactly what
> io_block_mapping() does,
> only in a way that is obvious :-)
Well, I agree that way we currently do it has this issue, but I think
this is because we did it wrong in the first place. We really shouldn't
need to do anything before ioremap can be used. And if we need an early
ioremap, we could implement bolted hash entries like we do on ppc64 :)
However, don't get wrong here, I'm not 100% opposed to the use of BATs
for early mappings, I just think that the whole hard-coding of the
virtual address is a bad idea, and that we shouldn't have allowed them
to be below KERNELBASE. The BAT could still have been "dynamically"
positioned using the ioremap_bot mecanism with appropriate alignment, or
at worse, we could have kept the current mecanism, but just not let it
work below KERNELBASE.
Ben.
^ permalink raw reply
* [PATCH] ppc32: enable use of early_param
From: Kumar Gala @ 2005-05-17 1:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
We need to call parse_early_param() early on to allow usage of
early_param() for command line parsing.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit d9aa16f3736be7e3ff97ead1a710b8061e9990f8
tree ad05fc7300bdd058ecfb5cbbf022c4c19f4e13c5
parent 704da4a5c793087584fa5d0ed73440dd4ac44294
author Kumar K. Gala <kumar.gala@freescale.com> Mon, 16 May 2005 20:29:56 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Mon, 16 May 2005 20:29:56 -0500
ppc/kernel/setup.c | 2 ++
1 files changed, 2 insertions(+)
Index: arch/ppc/kernel/setup.c
===================================================================
--- 1702b9dd418707a930969079b460df0ace2f1c1a/arch/ppc/kernel/setup.c (mode:100644)
+++ ad05fc7300bdd058ecfb5cbbf022c4c19f4e13c5/arch/ppc/kernel/setup.c (mode:100644)
@@ -753,6 +753,8 @@
strlcpy(saved_command_line, cmd_line, COMMAND_LINE_SIZE);
*cmdline_p = cmd_line;
+ parse_early_param();
+
/* set up the bootmem stuff with available memory */
do_init_bootmem();
if ( ppc_md.progress ) ppc_md.progress("setup_arch: bootmem", 0x3eab);
^ permalink raw reply
* Re: [PATCH] BOOKE_WDT Part 1/2 (Re: PPC 44x Watchdog timer)
From: Kumar Gala @ 2005-05-17 1:21 UTC (permalink / raw)
To: Takeharu KATO; +Cc: Glenn Burkhardt, Gala Kumar K.-galak, linuxppc-embedded
In-Reply-To: <42884448.6040505@ybb.ne.jp>
No problem, can you replace all the cmd line parsing with early_param()=20=
code in arch/ppc/kernel/setup.c. Take a look at=20
arch/ppc64/kernel/setup.c for an example. We still need to add a call=20=
to parse_early_param() in setup_arch().
Matt & I need to talk about the driver patch. Once I have more=20
feedback on that I'll let you know. The major issue I have is having=20
the interrupt handler in drivers/char/watchdog/.. instead of=20
arch/ppc/kernel/traps.c. However, I dont have a good idea how to=20
structure the changes.
- kumar
On May 16, 2005, at 1:57 AM, Takeharu KATO wrote:
> Hi Kumar:
>
> I'm sorry that the reply becomes slow.
>
> Kumar Gala wrote:
> >>
> >
> > Any reason you moved this code into DecrementerHandler?
> >
> >>=A0=A0 /* 0x1000 - Programmable Interval Timer (PIT) Exception */
> >>=A0=A0=A0=A0=A0=A0=A0=A0=A0 START_EXCEPTION(0x1000, Decrementer)
> >>=A0 -=A0=A0=A0=A0=A0=A0 NORMAL_EXCEPTION_PROLOG
> >> -=A0=A0=A0=A0=A0=A0 lis=A0=A0=A0=A0 r0,TSR_PIS@h
> >> -=A0=A0=A0=A0=A0=A0 mtspr=A0=A0 SPRN_TSR,r0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 /* Clear the PIT exception=20
> */
> >>=A0 -=A0=A0=A0=A0=A0=A0 addi=A0=A0=A0 r3,r1,STACK_FRAME_OVERHEAD
> >> -=A0=A0=A0=A0=A0=A0 EXC_XFER_LITE(0x1000, timer_interrupt)
> >> +=A0=A0=A0=A0=A0=A0 b=A0=A0=A0 DecrementerHandler
> >>
> Current PIT exception handler is too big.
> If it is not moved, compilation is failed with relocation error.
> Because current PIT handler overwrites WDT handler's codes, the=20
> compiler
> can not relocate PIT and WDT handler correctly.
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Benjamin Herrenschmidt @ 2005-05-17 0:56 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <4288DFCB.2080208@mvista.com>
On Mon, 2005-05-16 at 11:00 -0700, Mark A. Greer wrote:
> Benjamin Herrenschmidt wrote:
>
> >
> >series are by no mean stable. Embedded code has been rather frozen in
> >the rock, I don't think it's much to ask from the appropriate maintainer
> >to have a quick look at possibly upgrading their board support as well.
> >
>
> Seems reasonable to me.
>
> >And it isn't a difficult change for most 6xx/7xx/7xxx based boards
> >anyway.
> >
>
> From a quick grep, it looks like apus, gemini, k2, lopec, pplus, prep,
> and prpmc800 are the offenders in the 6xx/7xx/74xx world. Does anyone
> even care about the lopec and k2 anymore?
Note that there is only a problem if those io_block_mapping calls are
done to map things in the virtual region between 2G and 3G. If they are
done to map things "high" (like 0xf*) they are still fine.
Ben.
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Benjamin Herrenschmidt @ 2005-05-17 0:54 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <22b73f109d1c4a95b565f1007d76b8bf@embeddededge.com>
> Who cares? We have the ability to support the memory map flexibility
> for everyone. If you need it, use it, and fix it if necessary. There
> are
> too many other things that need attention. Again, you are taking one
> of the features we added for embedded boards a long time ago, and
> demanding everyone support it.
Gack ? None of this was 'added for embedded boards'. The initial 2G/2G
split was Cort's decision afaik for the PReP port, and it was PReP and
pmac that introduced the use of BATs for IO mappings, which then got
turned into io_block_mapping() for clarity. Those platorms predate by
far any embedded involvement in the ppc kernel.
> That's not necessary. If you want
> to use this feature on a PMac, then use it, but please don't demand
> everyone else do so. We didn't do that when the feature was added.
It's more than a "feature", it's the way it should have been done in the
first place on 6xx/7xx/7xxx CPUs and wasn't done because of a cheap hack
for IO mapping. I have no problem with other CPU family maintainers
deciding to restrict TASK_SIZE for the sake of saving a couple of
instructions (on 4xx, it's really replacing andis.;beq with
rlwinm;cmpl;bne or something like that, so one instruction, to support
any TASK_SIZE).
> > The whole io_block_mapping() was a bad idea in the first place.
>
> All of the ideas in 2.6 are going to look like bad ideas in the future
> :-)
Hrm... If you say so ...
> It's what worked and was necessary given the lack of any other
> APIs at the time.
ioremap and variants was available at this time and has always been.
> We are working on removing these in the embedded
> boards, and it has to be done on the PMac as well if you want to
> take advantage of something other than a 2G task space.
Well, you know what ? I've removed them from pmac a long time ago :) And
you know what also ? what you just stated above is _exactly_ what this
thread is all about ... so what are you complaining about ? :)
> As time permits, I will make whatever changes to the board ports
> I'm aware of so they will accommodate a 3G task space, or fix up
> the configuration files so the default is 2G. At some point, we can
> make it the configuration default.
Good, I'm not asking for anything else here.
Ben.
^ permalink raw reply
* Re: MPC885 - USB HCI drivers.
From: Wolfgang Denk @ 2005-05-16 23:27 UTC (permalink / raw)
To: Kylo Ginsberg; +Cc: PPC_LINUX
In-Reply-To: <61cc712d050516153941bc3b26@mail.gmail.com>
In message <61cc712d050516153941bc3b26@mail.gmail.com> you wrote:
>
> > My advice: use a _real_ USB controller.
>
> Are there known problems with CPM-based USB controllers? I'm
Ummmm... yes, there are. Especially if you want to use it as a host
comtroller (which is never was designed for). Even more, if there
might be other periopherals in your system that might need a bit a
CPM performance. Or ...
No, I better stop here. Please ask your Freecale sales representa-
tive. He may know better. [Or not, maybe.]
> completely new to the subject, but we are designing a board assuming
> we can use the USB controller on an MPC8555E.
You can do that. Anything can be done. But in this case I don't know
of an efficient way to do it. But my knowledge is limited, obviously.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Man did not weave the web of life; he is merely a strand in it.
Whatever he does to the web, he does to himself. - Seattle [1854]
^ permalink raw reply
* Re: MPC885 - USB HCI drivers.
From: Dan Malek @ 2005-05-16 22:52 UTC (permalink / raw)
To: Kylo Ginsberg; +Cc: PPC_LINUX
In-Reply-To: <61cc712d050516153941bc3b26@mail.gmail.com>
On May 16, 2005, at 6:39 PM, Kylo Ginsberg wrote:
> Are there known problems with CPM-based USB controllers?
The original CPM USB controller was only supposed to be
a device side controller. With some software hacks, CPM
microcode downloads, and even some hardware modifications,
you can often get it to work as a host in some static situations.
It doesn't have a built in root hub, you usually concentrate
on making it work with one specific device for a particular
product. You may find some application notes on the
Freescale web site, but I haven't seem them lately.
Take Wolfgang's advice, it's easier to find a way to
attach a real USB controller than to make this one
work as you probably expect.
Thanks.
-- Dan
^ permalink raw reply
* Re: MPC885 - USB HCI drivers.
From: Kylo Ginsberg @ 2005-05-16 22:39 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: PPC_LINUX
In-Reply-To: <20050516220330.6D4E3C1512@atlas.denx.de>
On 5/16/05, Wolfgang Denk <wd@denx.de> wrote:
> This code will NOT work on a MPC885. It was written for the old
> MPC823/850 processors, and it NEVER worked really reliably on these
> systems either.
=20
Ok, thanks. Good to know! Do you know of a driver for the 885, or
for the 8555E?
> My advice: use a _real_ USB controller.
Are there known problems with CPM-based USB controllers? I'm
completely new to the subject, but we are designing a board assuming
we can use the USB controller on an MPC8555E.
Thanks for any comments. If there are gotchas here, I'd love to find
out about them sooner rather than later.
Cheers,
Kylo
^ permalink raw reply
* Re: MPC885 - USB HCI drivers.
From: Wolfgang Denk @ 2005-05-16 22:03 UTC (permalink / raw)
To: Kylo Ginsberg; +Cc: PPC_LINUX
In-Reply-To: <61cc712d05051614507b688c6e@mail.gmail.com>
Dear Kylo,
in message <61cc712d05051614507b688c6e@mail.gmail.com> you wrote:
>
> There is a driver in the linux-2.4 tree at denx.de, although I have no
No, there is not!
> experience with it. Here's info on the cvs repository:
> http://www.denx.de/e/solution-se.php. Look in drivers/usb for
> m8xxhci.[ch] This code is not in the 2.4/2.6 trees on kernel.org, not
> sure if patches have been submitted. I don't know the history here.
This code will NOT work on a MPC885. It was written for the old
MPC823/850 processors, and it NEVER worked really reliably on these
systems either.
My advice: use a _real_ USB controller.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
For those who like this sort of thing, this is the sort of thing they
like. - Abraham Lincoln
^ 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