* ATI Radeon M6-C16H for PPC 440GX
From: Bashier Machmur @ 2005-11-30 12:55 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 334 bytes --]
Hello,
i'm using on my custom board (PPC 440GX) a ATI M6-C16H Mobility Radeon video
card. I work with U-boot and linux kernel 2.6.12 and installed the driver
"radeonfb". Now I don't have the BIOS of ATI for PPC to support it.
How can I configure the U-boot for ATI to initialize this video card?
Thanks for any help,
Bashier
[-- Attachment #2: Type: text/html, Size: 1440 bytes --]
^ permalink raw reply
* Require info regarding the flow of uart driver in linux for mpc8260
From: s.maiti @ 2005-11-30 8:30 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051130010005.3E86868862@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 997 bytes --]
Hi,
I am a fresher in device driver development. Currently I am involve in
developing the uart driver in linux for a custom board of mpc8260. I am
confused about tty and console in the code uart.c . I will be very
grateful if any one can clear my confusion.
Thanks in advance,
Souvik Maiti
Tata Consultancy Sevices Limited
Bengal Intelligent Park
Bldg. - D, Plots - A2, M2 & N2
Block - GP, Sector - V
Saltlake Electronics Complex
Kolkata - 700091, West Bengal
India
Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
[-- Attachment #2: Type: text/html, Size: 1300 bytes --]
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Johannes Berg @ 2005-11-30 11:17 UTC (permalink / raw)
To: Parag Warudkar; +Cc: linuxppc-dev, debian-powerpc, linux-kernel
In-Reply-To: <2100B419-3498-4BAF-8186-3EC06A917DF6@comcast.net>
Parag Warudkar wrote:
> Hopefully Johannes will have a PowerBook with either of the 0x0214 or
> 0x0215 touchpads and we will make some headway!
If anyone is in the area of Paderborn (Germany) who has such a touchpad,
it may be faster if I just look at that one :) If not, well, we can sort
of hope that the one my brother's ordering will have that touchpad.
johannes
^ permalink raw reply
* Re: Is there some articles discussing how to change bare-board code to linux driver?
From: Andrei Konovalov @ 2005-11-30 10:04 UTC (permalink / raw)
To: David H. Lynch Jr; +Cc: T Ziomek, linuxppc-embedded
In-Reply-To: <438D0878.30503@comcast.net>
David H. Lynch Jr wrote:
> Where can I find the ./drivers/net/xilinx_enet, ... etc files.
> I can not find them in the 2.6.14.2 tree
They are in the linuxppc-2.4 tree. Try
rsync -avz --delete source.mvista.com::linuxppc-2.4 <directory>
-- Andrei
> T Ziomek wrote:
>
>>> Where can i find them?thanks.
>>
>>
>> In addition to LDD3 (for 2.6 kernels, or the freely available LDD2 for
>> 2.4 kernels), you might want to look at some existing Linux drivers
>> that are
>> based on "bare metal" / "no OS" drivers. The ones I know of are for
>> Xilinx
>> peripherals, for example (within the Linux kernel tree),
>> - ./drivers/net/xilinx_enet
>> - ./drivers/char/xilinx_uartlite
>> - ./drivers/char/xilinx_gpio
>>
>> Tom
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Setting IDE mode to PIO for compact flash
From: Gregg Nemas @ 2005-11-30 10:12 UTC (permalink / raw)
To: linuxppc-embedded
I have a compact flash connected to a PPC440GP processor in "true IDE"
mode. The DMA signals are not connected, so the device must be used in
PIO mode.
However, when I issue hdparm -i, it indicates that the current mode is
DMA mode mdma2, and I think this must be why I am getting "lost
interrupt" messages. Unfortunately, when I try to set the mode to PIO
using "hdparm -p1" or "hdparm -X9", it seems to have no effect.
What do I need to do to get the drive to be set to use PIO?
I amusing linux 2.6.12.3.
Thanks.
Gregg
^ permalink raw reply
* RE: linuxppc-embedded help needed:kernel access of bad area
From: Fillod Stephane @ 2005-11-30 9:33 UTC (permalink / raw)
To: zengshuai, ppc
Dear zengshuai,
zengshuai@sogou.com wrote:
> i writed a led driver for PQ2FADS(a ppc board).
> but i can't read/write 0x04500000 where led register addr locate in.
> i tested two ways to do that.
> first,
> p=3D0x04500000;
> *p=3D0x12;
> ....
> second,
> outb(0x12,0x04500000);
> ...
> two ways both didn't work.they had a some wrong:kernel access of bad
area.
> how can i know which area is bad area or good area?
> and what can i do next? thanks.
Do yourself a favor, read a book about Linux device driver development,
for example one listed[1] in the excellent Denx's DLUG FAQ[2].
Getting some training on PowerPC development is a good idea too.
[1] http://www.denx.de/wiki/view/DULG/MoreInformationBooks
[2] http://www.denx.de/wiki/DULG/Manual
Peruse also your chip data-sheet, and you will see that outb() is
non-sense.
If you are accessing the led register from kernel space, you'll find
a solution using ioremap(). Otherwise, if you are accessing the led
register
from user space, this link[3] will help you, or this shorter one[4].
You can follow this thread[5] for more information.
[3]
http://www.denx.de/twiki/bin/view/PPCEmbedded/DeviceDrivers#Section_Acce
ssingPeripheralsFromUserSpace
[4] http://tinyurl.com/6c7th
[5] http://lists.linuxppc.org/linuxppc-embedded/200403/msg00059.html
Please next time, do ourselves a favor, try some searching first
(google,=20
whatever). Your question is a FAQ.
Regards,
--=20
Stephane
^ permalink raw reply
* Re:linuxppc-embedded help needed:kernel access of bad area
From: zengshuai @ 2005-11-30 9:01 UTC (permalink / raw)
To: Linuxppc-embedded
detail:
---------------------------------------------------------------------------------
# ls
led-app.exe led-module.o
# ./led-app.exe
open led-app.exe...OK!
Oops: kernel access of bad area, sig: 11
NIP: C30B11B4 XER: 00000000 LR: C003A310 SP: C06B1F00 REGS: c06b1e50 TRAP: 0300
Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 04500000, DSISR: 20000000
TASK = c06b0000[201] 'led-app.exe' Last syscall: 3
last math c06b0000 last altivec 00000000
GPR00: C003A310 C06B1F00 C06B0000 C01A5AA0 7FFFFDE0 00000014 C01A5AC0 00000000
GPR08: 00000000 04500000 0000000C C01A0000 30025CE8 10018B5C 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00009032 006B1F40 00000000 C0003E88
GPR24: C0003BE0 00000001 10000500 7FFFFEA4 7FFFFDE0 FFFFFFEA C01A5AA0 00000014
Call backtrace:
10000A1C C003A310 C0003C3C 100004AC 0FEC6D74 00000000
Segmentation fault
#
----------------------------------------------------------------------------------
> -------------------
> From: zengshuai@sogou.com
> To: ppc
> Subject: linuxppc-embedded help needed:kernel access of bad area
> Sent: Wed Nov 30 16:18:06 CST 2005
>
> > i writed a led driver for PQ2FADS(a ppc board).
> > but i can't read/write 0x04500000 where led register addr locate in.
> > i tested two ways to do that.
> > first,
> > p=0x04500000;
> > *p=0x12;
> > ....
> > second,
> > outb(0x12,0x04500000);
> > ...
> > two ways both didn't work.they had a some wrong:kernel access of bad area.
> > how can i know which area is bad area or good area?
> > and what can i do next? thanks.
> >
> > ------------------------------
> > 我现在使用Sogou.com的2G邮箱了，你也来试试吧!
> > http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=linuxppc-embedded&FullName=linuxppc-embedded&Email=linuxppc-embedded%40ozlabs.org&verify=755eff4e640bdcfc57d93cbd8b0a9cb7
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> ------------------------------
> 我现在使用Sogou.com的2G邮箱了，你也来试试吧!
> http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=zengshuai&FullName=zengshuai&Email=zengshuai%40sogou.com&verify=9cab69a60842dbdbc5ad49cbd78e2e11
------------------------------
我现在使用Sogou.com的2G邮箱了，你也来试试吧!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=Linuxppc-embedded&FullName=Linuxppc-embedded&Email=Linuxppc-embedded%40ozlabs.org&verify=777667b18eda2b5dd1bbd47542afad9b
^ permalink raw reply
* linuxppc-embedded help needed:kernel access of bad area
From: zengshuai @ 2005-11-30 8:18 UTC (permalink / raw)
To: ppc
i writed a led driver for PQ2FADS(a ppc board).
but i can't read/write 0x04500000 where led register addr locate in.
i tested two ways to do that.
first,
p=0x04500000;
*p=0x12;
....
second,
outb(0x12,0x04500000);
...
two ways both didn't work.they had a some wrong:kernel access of bad area.
how can i know which area is bad area or good area?
and what can i do next? thanks.
------------------------------
我现在使用Sogou.com的2G邮箱了，你也来试试吧!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=linuxppc-embedded&FullName=linuxppc-embedded&Email=linuxppc-embedded%40ozlabs.org&verify=755eff4e640bdcfc57d93cbd8b0a9cb7
^ permalink raw reply
* Re: immap with 8xx.
From: Ingo Hornberger @ 2005-11-30 7:59 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-devel list
In-Reply-To: <f3e079332f2f66cb1898b288cf66e5c9@embeddededge.com>
Thanks Dan for your reply!
I mainly needed the immap stuff like 'immap_rp_t' and some 'defines'.
But I just started to reorder this. I thought that 'cpm1' and 'cpm2'
devices should follow the same unique scheme, shouldn't they? Even if we
only have one cpm1 device.
Otherwise the naming is very confusing.
For example:
(8xx) (cpm2)
commproc.h cpm2.h
8xx_immap.h immap_cpm2.h
immap_t cpm2_map_t
iop8xx_t iop_cpm2_t
... ...
And because the cpm2 scheme is newer and cleaner, I think we should use
that instead.
This change would mainly rename the following files (and their symbols):
8xx_immap.h -> immap_cpm1.h
commproc.h -> cpm1.h
(but likely affect others, too)
Then we would need three patches:
1. rename the files
2. patch only the 'include/asm' files
3. rename all "#include" directives and symbols in the rest.
Or do you see too much problems in renaming such symbols? Perhaps this
should be a topic for the development kernel, but I don't think so...
I think we should do this now, because it's only relevant for low-level
8xx code (and drivers like mine or the ide driver). The init code could
be converted by us, and as the 8xx port of 2.6 isn't such old and stable
I believe that there are not too much (if none) already ported drivers
around that are using low-level 8xx stuff.
But I'd like to here more opinions.
regards,
Ingo
On Tue, 2005-11-29 at 13:13 -0500, Dan Malek wrote:
> On Nov 29, 2005, at 9:39 AM, Ingo Hornberger wrote:
>
> > But it seems that there was some generalization work done, which didn't
> > reach the 8xx part. Particularly this means that some parts of
> > 'asm/commproc.h' as well as (at least) 'asm/immap_8260.h' built up a
> > new
> > header 'asm/immap_cpm2.h'.
>
> That's because the cpm2 is used in more parts than just the 82xx,
> so we carved up the files to make it more useful.
>
> > Actally I miss a file like 'asm/immap_cpm1.h'.
>
> The 8xx is the only processor to use the CPM1, so just update
> the immap or 8xx files to accommodate the differences you may
> need. There isn't a similar requirement to create a immap_cpm1.h
> file like there was for the CPM2. What kind of updates do you need?
>
> Thanks.
>
> -- Dan
>
^ permalink raw reply
* Re: Kernel 2.6 support for MVME5500?
From: Gerhard Jaeger @ 2005-11-30 7:22 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1133296311.8749.9.camel@kokopelli.npt.nuwc.navy.mil>
Hi,
On Tuesday 29 November 2005 21:31, Henry A. Leinhos wrote:
> Hi,
>
> Does anyone have any information regarding support for the Motorola
> MVME5500 SBC under kernel 2.6.x? Motorola has 2.4.x patches on their
> website, but I can't seem to find anything for 2.6.x.
>
I'm pretty sure, that Motorola has 2.6 patches available, the latest
one I saw was for 2.6.10 Kernel series. You might ask your local
Motorola representative.
Ciao,
Gerhard
--
Gerhard Jaeger <gjaeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
^ permalink raw reply
* Re: MPC85xx i2c interface bug
From: Dan Wilson @ 2005-11-30 7:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0511300013110.32230-100000@gate.crashing.org>
On 11/30/2005 at 12:14 AM Kumar Gala wrote:
> Dan,
>
> Did you see an issue this change fixed? If so can you provide more
> details. Also, can you provide your diff as a unified diff (diff -u) so
> its easier to see where the changes where.
>
> I'm trying to figure out if the same issue exists in the 2.6 driver (and
> if so, why we havent seen it)
>
> thanks
>
> - kumar
>
Yes, there was an issue that this change fixed. Our I2C bus has a number=
of devices on it. The first device is at address 0x2c, and is an Analog=
Device AD5173BRM50 software programmable 50K ohm resistor. We connected a=
logic analyzer to the device and watched the bus activity as linux booted=
and the i2c bus scan took place. During this scan, the 8541 attempts to=
address each device and then read a byte from the device. With the=
original code, the 8541 would reply to the byte read by sending a zero as=
the TXACK bit, which instructed the 5173 to send an additional byte, but=
the 8541 didn't attempt to retrieve that byte, since it was already moving=
on, trying to stop the bus and go on to the next device. The 5173=
appeared to not be able to see the stop command since it had received a=
command to transmit the next byte. The bus didn't seem to ever recover=
from this: if we allowed linux to complete it's boot and then told it to=
reboot, the u-boot code was no longer able to identify and configure the=
SDRAM, since it is also connected to the now non-functional I2C. With the=
new code, linux correctly identifies all of the devices on the I2C, boots=
quickly and cleanly, and after a reboot the u-boot code has no problem=
coming up again.
Here is the diff -u that you requested:
@@ -299,11 +299,11 @@
if(pm->flags & I2C_M_RD) {
/* Change to read mode */
- priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX);
+ priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX |=
MPC_I2CCR_TXAK);
/* If there is only one byte, we need to TXAK now */
if(len =3D=3D 1)
- priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
+ priv->write(®s->i2ccr, MPC_I2CCR_TXAK,=
MPC_I2CCR_TXAK);
/* Do a dummy read, to initiate the first read */
priv->read(®s->i2cdr);
@@ -321,7 +321,7 @@
/* If this is the 2nd to last byte, send
* the TXAK signal */
if(i =3D=3D len - 2) {
- priv->write(®s->i2ccr, 0,=
MPC_I2CCR_TXAK);
+ priv->write(®s->i2ccr, MPC_I2CCR_TXAK,=
MPC_I2CCR_TXAK);
}
/* If this is the last byte, send STOP */
@@ -383,7 +383,6 @@
priv->write(®s->i2csr, 0, MPC_I2CSR_MIF);
mpc_i2c_start(priv);
-
/* Send each message, chaining them together with repeat STARTs */
for(i =3D 0; i < num && !err; ++i) {
err =3D mpc_doAddress(priv, &msgs[i]);
Hope this helps,
Dan.
^ permalink raw reply
* Re: Support for S29GL512N in U-boot
From: Kumar Gala @ 2005-11-30 7:12 UTC (permalink / raw)
To: le tang; +Cc: linuxppc-embedded list
In-Reply-To: <20051130070059.28442.qmail@web50609.mail.yahoo.com>
On Nov 30, 2005, at 1:00 AM, le tang wrote:
> Hi all,
>
> My board has Flash memory type AMD, S29GL512N and
> CPU8541, and I found in the /include/flash.h in u-boot
> source, there is entry for flash memory S29GL064M-R6,
>
> How can I add the support for S29GL512N flash memory?
Please post such queries to the u-boot list.
- kumar
^ permalink raw reply
* Re: Trying to understand initsenses and pci_irq_table
From: Kumar Gala @ 2005-11-30 7:11 UTC (permalink / raw)
To: Richard Danter; +Cc: linuxppc-embedded
In-Reply-To: <438374FE.4040608@ntlworld.com>
On Nov 22, 2005, at 1:43 PM, Richard Danter wrote:
> Richard Danter wrote:
>> The kernel crashes after starting init. I see some random
>> characters on the serial and then nothing. Looking in the log
>> buffer via JTAG I can see that the init process exited with signal
>> 11. I assume this is unrelated to the above, but any suggestions
>> where I should look?
>
> I managed to fix this problem, so I am now booted and running
> busybox from NFS :)
>
> I'd still like a pointer to any docs explaining the PCI and
> interrupt stuff if possible.
Well the PCI SIG has specs. If your talking about the code, its a
simple lookup table. The key is realizing that PCI_IRQ_TABLE_LOOKUP
is a macro.
- kumar
^ permalink raw reply
* Re: [PATCH] ppc32: 8xx board-specific platform stuff for fs_enet
From: Kumar Gala @ 2005-11-30 7:08 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded list, Paul Mackerras
In-Reply-To: <20051123120033.GA3551@logos.cnet>
> Hi Kumar,
>
> I dont really know the policy for driver placement, but it seems that
> it works on a case by case basis.
>
> The files in arch/ppc/8xx_io/ (which is what I think you refer to as
> candidates for drivers/), are:
We have been slowly working on moving drivers out of arch/ppc and
into drivers/ so that subsystem maintainers could get proper review
of them.
> 1) commproc.c
> Basic API for dpram access. Core code.
>
> 2) micropatch.c
> microcode update code/data. Core code.
Well #1 & #2 aren't what I would call drivers at all. I would
consider them syslib/ candidates. Hopefully, someone will
>
> 3) cs4218.h
> 4) cs4218_tdm.c
>
> cs4218 does not compile at the moment due to syntatical problems,
> I've fixed them up and the driver compiles, but I don't know
> if it works (patch attached).
>
> I would not be surprised if the driver has been broken since
> long time ago.
>
> Does anyone have hardware to test it? Dan?
>
> Otherwise we should remove it from the tree, since its unmaintained
> and unused.
If its still good, I would guessing /drivers/audio or snd, but
neither seem to exist. I wondering where sound card drivers live
these days.
>
> 5) enet.c
> 6) fec.c
>
> The ENET/FEC network drivers are obseleted by fs_enet.
>
> However there are some PHY descriptions in fec.c which are missing
> from
> fs_enet - we'd better make sure to have them all in the new driver
> before removing the old one.
Agreed.
> Aris, would you mind looking into this?
>
> Once we have that we can set a deadline at Documentation/feature-
> removal.txt
> if desired.
>
> Other than those there are no 8xx drivers in arch/ppc/ AFAIK.
>
> <cs42.patch>
Good deal. Are we really removing anything (except maybe cs4218)?
- kumar
^ permalink raw reply
* Re: USB on MPC8272
From: Kumar Gala @ 2005-11-30 7:03 UTC (permalink / raw)
To: Mike Rapoport; +Cc: linuxppc-embedded, Nathael PAJANI
In-Reply-To: <438D4A03.4060500@compulab.co.il>
On Nov 30, 2005, at 12:43 AM, Mike Rapoport wrote:
> Nathael PAJANI wrote:
>
>> Hi all!
>>
>>
>> I have to support USB hcd for an Actis board based on a MPC8248
>> processor. I already have a 2.6.9 linux kernel running fine on it,
>> and actualy have to use it rather than a newer one.
>> I'm actualy looking for existing or ongoing jobs.
>
> Dear Nathael,
> As far as I understand there are several drivers for the MPC8272
> usb host controller, and none of them is in
> official kernel tree.
> There's a driver in Metrowerks BSP for linux 2.6 for MPC8272 (the
> Freescale driver), an orignally mpc8xx driver by Brad Parker ported
> to linux 2.4 for MPC8272 by Pantelis Antoniou, there ought to be
> USB driver by ArabellaSW also.
> My driver ("http://cpm2usb.sourceforge.net./") is a port of the
> Brad Parker's driver to linux 2.6 with some modifications.
And, ideally we would like to see one driver get into the linux
source tree that everyone is happy with. I'm told by someone that
the FSL driver is suppose to have working host support "was tested/
verified with keyboard/mouse/diskdrives/network".
- kumar
^ permalink raw reply
* Support for S29GL512N in U-boot
From: le tang @ 2005-11-30 7:00 UTC (permalink / raw)
To: linuxppc-embedded list
In-Reply-To: <20051129081052.77DA1353F54@atlas.denx.de>
Hi all,
My board has Flash memory type AMD, S29GL512N and
CPU8541, and I found in the /include/flash.h in u-boot
source, there is entry for flash memory S29GL064M-R6,
How can I add the support for S29GL512N flash memory?
Thanks,
Le
__________________________________
Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/
^ permalink raw reply
* Re: USB on MPC8272
From: Mike Rapoport @ 2005-11-30 6:43 UTC (permalink / raw)
To: Nathael PAJANI; +Cc: linuxppc-embedded
In-Reply-To: <438C8E8E.3030306@cpe.fr>
Nathael PAJANI wrote:
> Hi all!
>
>
> I have to support USB hcd for an Actis board based on a MPC8248
> processor. I already have a 2.6.9 linux kernel running fine on it, and
> actualy have to use it rather than a newer one.
> I'm actualy looking for existing or ongoing jobs.
Dear Nathael,
As far as I understand there are several drivers for the MPC8272 usb
host controller, and none of them is in
official kernel tree.
There's a driver in Metrowerks BSP for linux 2.6 for MPC8272 (the
Freescale driver), an orignally mpc8xx driver by Brad Parker ported to
linux 2.4 for MPC8272 by Pantelis Antoniou, there ought to be USB driver
by ArabellaSW also.
My driver ("http://cpm2usb.sourceforge.net./") is a port of the Brad
Parker's driver to linux 2.6 with some modifications.
--
Sincerely yours,
Mike Rapoport
^ permalink raw reply
* Re: MPC85xx i2c interface bug
From: Kumar Gala @ 2005-11-30 6:14 UTC (permalink / raw)
To: dwilson; +Cc: linuxppc-embedded
In-Reply-To: <23fdca41e44a84e4a32634a.20051129124254.qjvyfba@www.dslextreme.com>
Dan,
Did you see an issue this change fixed? If so can you provide more
details. Also, can you provide your diff as a unified diff (diff -u) so
its easier to see where the changes where.
I'm trying to figure out if the same issue exists in the 2.6 driver (and
if so, why we havent seen it)
thanks
- kumar
On Tue, 29 Nov 2005 dwilson@dslextreme.com wrote:
> We have found a problem in the i2c-mpc.c file (linux 2.4 kernel). The
> logic for the i2c transfer termination seems to have been inverted.
>
> The original function is:
>
> /* Perform one i2c_msg transfer. It could be a read, or a write.
> * This function assumes that the address byte has been sent
> * already, and only handles the message contents */
> static int mpc_i2c_xfer_bytes(struct mpc_i2c_private* priv, struct
> i2c_msg* pm)
> {
> volatile struct mpc_i2c *regs = priv->regs;
> char *buf = pm->buf;
> int len = pm->len;
> int i;
> int ret = 0;
>
> if(pm->flags & I2C_M_RD) {
> /* Change to read mode */
> priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX);
>
> /* If there is only one byte, we need to TXAK now */
> if(len == 1)
> priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
>
> /* Do a dummy read, to initiate the first read */
> priv->read(®s->i2cdr);
> }
>
> for(i = 0; i < len; ++i) {
> /* If this is a read, read a byte, otherwise, write a byte */
> if(pm->flags & I2C_M_RD) {
> /* Wait for the previous read to finish */
> ret = wait_for_txcomplete(priv);
>
> if (ret)
> return ret;
>
> /* If this is the 2nd to last byte, send
> * the TXAK signal */
> if(i == len - 2) {
> priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
> }
>
> /* If this is the last byte, send STOP */
> if (i == len - 1)
> mpc_i2c_stop(priv);
>
> buf[i] = priv->read(®s->i2cdr);
>
> } else {
> /* Otherwise, it's a write */
> priv->write(®s->i2cdr, buf[i], MPC_I2C_FULLREG);
>
> /* Wait for the transaction to complete */
> ret = wait_for_txcomplete(priv);
>
> if(ret)
> return ret;
>
> /* Return error if we didn't get the ack */
> if((priv->read(®s->i2csr) & MPC_I2CSR_RXAK)) {
> printk(KERN_DEBUG "NO ACK!\n");
> ret = -EREMOTEIO;
> }
> }
>
> /* If there was an error, abort */
> if(ret)
> return ret;
> }
>
> return ret;
> }
>
> The problem is that the TXAK bit is set incorrectly: it should be set to a
> zero when acks are to be sent and then set to a 1 just before reading the
> next-to-last byte in the transfer (8555 Processor Reference Manual
> (MPC8555ERM rev1), section 11.3.1.3 and also Figure 11-8).
>
> Changes to the above code are thus:
>
> 302c302
> < priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX);
> ---
> > priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX | MPC_I2CCR_TXAK);
> 306c306
> < priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
> ---
> > priv->write(®s->i2ccr, MPC_I2CCR_TXAK,
> MPC_I2CCR_TXAK);
> 324c324
> < priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
> ---
> > priv->write(®s->i2ccr, MPC_I2CCR_TXAK,
> MPC_I2CCR_TXAK);
>
> Thanks,
>
> Dan.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* [PATCH] powerpc: Update OF address parsers
From: Benjamin Herrenschmidt @ 2005-11-30 5:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
This updates the OF address parsers to return the IO flags
indicating the type of address obtained. It also adds a PCI
call for converting physical addresses that hit IO space into
into IO tokens, and add routines that return the translated
addresses into struct resource
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
For powerpc tree, not for 2.6.15
Index: linux-work/include/asm-powerpc/prom.h
===================================================================
--- linux-work.orig/include/asm-powerpc/prom.h 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/include/asm-powerpc/prom.h 2005-11-30 16:19:51.000000000 +1100
@@ -223,14 +223,36 @@ extern struct resource *request_OF_resou
int index, const char* name_postfix);
extern int release_OF_resource(struct device_node* node, int index);
+
/*
- * Address translation function(s)
+ * OF address retreival & translation
+ */
+
+
+/* Translate an OF address block into a CPU physical address
*/
#define OF_BAD_ADDR ((u64)-1)
extern u64 of_translate_address(struct device_node *np, u32 *addr);
-extern u32 *of_get_address(struct device_node *dev, int index, u64 *size);
-extern u32 *of_get_pci_address(struct device_node *dev, int bar_no, u64 *size);
+/* Extract an address from a device, returns the region size and
+ * the address space flags too. The PCI version uses a BAR number
+ * instead of an absolute index
+ */
+extern u32 *of_get_address(struct device_node *dev, int index,
+ u64 *size, unsigned int *flags);
+extern u32 *of_get_pci_address(struct device_node *dev, int bar_no,
+ u64 *size, unsigned int *flags);
+
+/* Get an address as a resource. Note that if your address is
+ * a PIO address, the conversion will fail if the physical address
+ * can't be internally converted to an IO token with
+ * pci_address_to_pio(), that is because it's either called to early
+ * or it can't be matched to any host bridge IO space
+ */
+extern int of_address_to_resource(struct device_node *dev, int index,
+ struct resource *r);
+extern int of_pci_address_to_resource(struct device_node *dev, int bar,
+ struct resource *r);
#endif /* __KERNEL__ */
#endif /* _POWERPC_PROM_H */
Index: linux-work/arch/powerpc/kernel/legacy_serial.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/legacy_serial.c 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/arch/powerpc/kernel/legacy_serial.c 2005-11-30 15:38:27.000000000 +1100
@@ -146,6 +146,7 @@ static int __init add_legacy_pci_port(st
{
phys_addr_t addr, base;
u32 *addrp;
+ unsigned int flags;
int iotype, index = -1, lindex = 0;
/* We only support ports that have a clock frequency properly
@@ -159,12 +160,12 @@ static int __init add_legacy_pci_port(st
return -1;
/* Get the PCI address. Assume BAR 0 */
- addrp = of_get_pci_address(pci_dev, 0, NULL);
+ addrp = of_get_pci_address(pci_dev, 0, NULL, &flags);
if (addrp == NULL)
return -1;
/* We only support BAR 0 for now */
- iotype = (addrp[0] & 0x02000000) ? UPIO_MEM : UPIO_PORT;
+ iotype = (flags & IORESOURCE_MEM) ? UPIO_MEM : UPIO_PORT;
addr = of_translate_address(pci_dev, addrp);
/* Set the IO base to the same as the translated address for MMIO,
Index: linux-work/arch/powerpc/kernel/pci_64.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/pci_64.c 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/arch/powerpc/kernel/pci_64.c 2005-11-30 15:38:27.000000000 +1100
@@ -1181,6 +1181,20 @@ void phbs_remap_io(void)
remap_bus_range(hose->bus);
}
+unsigned int pci_address_to_pio(phys_addr_t address)
+{
+ struct pci_controller *hose, *tmp;
+
+ list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
+ if (address >= hose->io_base_phys &&
+ address < (hose->io_base_phys + hose->pci_io_size))
+ return (unsigned int)hose->io_base_virt +
+ (address - hose->io_base_phys);
+ }
+ return (unsigned int)-1;
+}
+EXPORT_SYMBOL_GPL(pci_address_to_pio);
+
static void __devinit fixup_resource(struct resource *res, struct pci_dev *dev)
{
struct pci_controller *hose = pci_bus_to_host(dev->bus);
Index: linux-work/arch/powerpc/kernel/prom_parse.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/prom_parse.c 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/arch/powerpc/kernel/prom_parse.c 2005-11-30 16:20:22.000000000 +1100
@@ -4,7 +4,9 @@
#include <linux/string.h>
#include <linux/pci_regs.h>
#include <linux/module.h>
+#include <linux/ioport.h>
#include <asm/prom.h>
+#include <asm/pci-bridge.h>
#ifdef DEBUG
#define DBG(fmt...) do { printk(fmt); } while(0)
@@ -54,6 +56,7 @@ struct of_bus {
int *addrc, int *sizec);
u64 (*map)(u32 *addr, u32 *range, int na, int ns, int pna);
int (*translate)(u32 *addr, u64 offset, int na);
+ unsigned int (*get_flags)(u32 *addr);
};
@@ -61,8 +64,8 @@ struct of_bus {
* Default translator (generic bus)
*/
-static void of_default_count_cells(struct device_node *dev,
- int *addrc, int *sizec)
+static void of_bus_default_count_cells(struct device_node *dev,
+ int *addrc, int *sizec)
{
if (addrc)
*addrc = prom_n_addr_cells(dev);
@@ -70,7 +73,7 @@ static void of_default_count_cells(struc
*sizec = prom_n_size_cells(dev);
}
-static u64 of_default_map(u32 *addr, u32 *range, int na, int ns, int pna)
+static u64 of_bus_default_map(u32 *addr, u32 *range, int na, int ns, int pna)
{
u64 cp, s, da;
@@ -86,7 +89,7 @@ static u64 of_default_map(u32 *addr, u32
return da - cp;
}
-static int of_default_translate(u32 *addr, u64 offset, int na)
+static int of_bus_default_translate(u32 *addr, u64 offset, int na)
{
u64 a = of_read_addr(addr, na);
memset(addr, 0, na * 4);
@@ -98,6 +101,11 @@ static int of_default_translate(u32 *add
return 0;
}
+static unsigned int of_bus_default_get_flags(u32 *addr)
+{
+ return IORESOURCE_MEM;
+}
+
/*
* PCI bus specific translator
@@ -139,7 +147,24 @@ static u64 of_bus_pci_map(u32 *addr, u32
static int of_bus_pci_translate(u32 *addr, u64 offset, int na)
{
- return of_default_translate(addr + 1, offset, na - 1);
+ return of_bus_default_translate(addr + 1, offset, na - 1);
+}
+
+static unsigned int of_bus_pci_get_flags(u32 *addr)
+{
+ unsigned int flags = 0;
+ u32 w = addr[0];
+
+ switch((w >> 24) & 0x03) {
+ case 0x01:
+ flags |= IORESOURCE_IO;
+ case 0x02: /* 32 bits */
+ case 0x03: /* 64 bits */
+ flags |= IORESOURCE_MEM;
+ }
+ if (w & 0x40000000)
+ flags |= IORESOURCE_PREFETCH;
+ return flags;
}
/*
@@ -182,9 +207,22 @@ static u64 of_bus_isa_map(u32 *addr, u32
static int of_bus_isa_translate(u32 *addr, u64 offset, int na)
{
- return of_default_translate(addr + 1, offset, na - 1);
+ return of_bus_default_translate(addr + 1, offset, na - 1);
}
+static unsigned int of_bus_isa_get_flags(u32 *addr)
+{
+ unsigned int flags = 0;
+ u32 w = addr[0];
+
+ if (w & 1)
+ flags |= IORESOURCE_IO;
+ else
+ flags |= IORESOURCE_MEM;
+ return flags;
+}
+
+
/*
* Array of bus specific translators
*/
@@ -198,6 +236,7 @@ static struct of_bus of_busses[] = {
.count_cells = of_bus_pci_count_cells,
.map = of_bus_pci_map,
.translate = of_bus_pci_translate,
+ .get_flags = of_bus_pci_get_flags,
},
/* ISA */
{
@@ -207,15 +246,17 @@ static struct of_bus of_busses[] = {
.count_cells = of_bus_isa_count_cells,
.map = of_bus_isa_map,
.translate = of_bus_isa_translate,
+ .get_flags = of_bus_isa_get_flags,
},
/* Default */
{
.name = "default",
.addresses = "reg",
.match = NULL,
- .count_cells = of_default_count_cells,
- .map = of_default_map,
- .translate = of_default_translate,
+ .count_cells = of_bus_default_count_cells,
+ .map = of_bus_default_map,
+ .translate = of_bus_default_translate,
+ .get_flags = of_bus_default_get_flags,
},
};
@@ -254,7 +295,8 @@ static int of_translate_one(struct devic
ranges = (u32 *)get_property(parent, "ranges", &rlen);
if (ranges == NULL || rlen == 0) {
offset = of_read_addr(addr, na);
- memset(addr, 0, pna);
+ memset(addr, 0, pna * 4);
+ DBG("OF: no ranges, 1:1 translation\n");
goto finish;
}
@@ -370,7 +412,8 @@ u64 of_translate_address(struct device_n
}
EXPORT_SYMBOL(of_translate_address);
-u32 *of_get_address(struct device_node *dev, int index, u64 *size)
+u32 *of_get_address(struct device_node *dev, int index, u64 *size,
+ unsigned int *flags)
{
u32 *prop;
unsigned int psize;
@@ -399,22 +442,106 @@ u32 *of_get_address(struct device_node *
if (i == index) {
if (size)
*size = of_read_addr(prop + na, ns);
+ if (flags)
+ *flags = bus->get_flags(prop);
return prop;
}
return NULL;
}
EXPORT_SYMBOL(of_get_address);
-u32 *of_get_pci_address(struct device_node *dev, int bar_no, u64 *size)
+u32 *of_get_pci_address(struct device_node *dev, int bar_no, u64 *size,
+ unsigned int *flags)
{
- u32 *addr;
- int index;
+ u32 *prop;
+ unsigned int psize;
+ struct device_node *parent;
+ struct of_bus *bus;
+ int onesize, i, na, ns;
- for (index = 0; (addr = of_get_address(dev, index, size)) != NULL;
- index++) {
- if ((addr[0] & 0xff) == ((bar_no * 4) + PCI_BASE_ADDRESS_0))
- return addr;
- }
+ /* Get parent & match bus type */
+ parent = of_get_parent(dev);
+ if (parent == NULL)
+ return NULL;
+ bus = of_match_bus(parent);
+ if (strcmp(bus->name, "pci"))
+ return NULL;
+ bus->count_cells(dev, &na, &ns);
+ of_node_put(parent);
+ if (!OF_CHECK_COUNTS(na, ns))
+ return NULL;
+
+ /* Get "reg" or "assigned-addresses" property */
+ prop = (u32 *)get_property(dev, bus->addresses, &psize);
+ if (prop == NULL)
+ return NULL;
+ psize /= 4;
+
+ onesize = na + ns;
+ for (i = 0; psize >= onesize; psize -= onesize, prop += onesize, i++)
+ if ((prop[0] & 0xff) == ((bar_no * 4) + PCI_BASE_ADDRESS_0)) {
+ if (size)
+ *size = of_read_addr(prop + na, ns);
+ if (flags)
+ *flags = bus->get_flags(prop);
+ return prop;
+ }
return NULL;
}
EXPORT_SYMBOL(of_get_pci_address);
+
+static int __of_address_to_resource(struct device_node *dev, u32 *addrp,
+ u64 size, unsigned int flags,
+ struct resource *r)
+{
+ u64 taddr;
+
+ if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
+ return -EINVAL;
+ taddr = of_translate_address(dev, addrp);
+ if (taddr == OF_BAD_ADDR)
+ return -EINVAL;
+ memset(r, 0, sizeof(struct resource));
+ if (flags & IORESOURCE_IO) {
+ unsigned int port;
+ port = pci_address_to_pio(taddr);
+ if (port == (unsigned int)-1)
+ return -EINVAL;
+ r->start = port;
+ r->end = port + size - 1;
+ } else {
+ r->start = taddr;
+ r->end = taddr + size - 1;
+ }
+ r->flags = flags;
+ r->name = dev->name;
+ return 0;
+}
+
+int of_address_to_resource(struct device_node *dev, int index,
+ struct resource *r)
+{
+ u32 *addrp;
+ u64 size;
+ unsigned int flags;
+
+ addrp = of_get_address(dev, index, &size, &flags);
+ if (addrp == NULL)
+ return -EINVAL;
+ return __of_address_to_resource(dev, addrp, size, flags, r);
+}
+EXPORT_SYMBOL_GPL(of_address_to_resource);
+
+int of_pci_address_to_resource(struct device_node *dev, int bar,
+ struct resource *r)
+{
+ u32 *addrp;
+ u64 size;
+ unsigned int flags;
+
+ addrp = of_get_pci_address(dev, bar, &size, &flags);
+ if (addrp == NULL)
+ return -EINVAL;
+ return __of_address_to_resource(dev, addrp, size, flags, r);
+}
+EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
Index: linux-work/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/feature.c 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/feature.c 2005-11-30 16:19:51.000000000 +1100
@@ -2672,7 +2672,7 @@ static void __init probe_one_macio(const
printk(KERN_ERR "pmac_feature: %s skipped\n", node->full_name);
return;
}
- addrp = of_get_pci_address(node, 0, &size);
+ addrp = of_get_pci_address(node, 0, &size, NULL);
if (addrp == NULL) {
printk(KERN_ERR "pmac_feature: %s: can't find base !\n",
node->full_name);
Index: linux-work/arch/ppc/kernel/pci.c
===================================================================
--- linux-work.orig/arch/ppc/kernel/pci.c 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/arch/ppc/kernel/pci.c 2005-11-30 15:38:27.000000000 +1100
@@ -1805,6 +1805,21 @@ void pci_iounmap(struct pci_dev *dev, vo
EXPORT_SYMBOL(pci_iomap);
EXPORT_SYMBOL(pci_iounmap);
+unsigned int pci_address_to_pio(phys_addr_t address)
+{
+ struct pci_controller* hose = hose_head;
+
+ for (; hose; hose = hose->next) {
+ unsigned int size = hose->io_resource.end -
+ hose->io_resource.start + 1;
+ if (address >= hose->io_base_phys &&
+ address < (hose->io_base_phys + size))
+ return (unsigned int)hose->io_base_virt +
+ (address - hose->io_base_phys);
+ }
+ return (unsigned int)-1;
+}
+EXPORT_SYMBOL(pci_address_to_pio);
/*
* Null PCI config access functions, for the case when we can't
Index: linux-work/drivers/macintosh/macio_asic.c
===================================================================
--- linux-work.orig/drivers/macintosh/macio_asic.c 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/drivers/macintosh/macio_asic.c 2005-11-30 16:19:51.000000000 +1100
@@ -332,18 +332,14 @@ static void macio_setup_resources(struct
struct resource *parent_res)
{
struct device_node *np = dev->ofdev.node;
- u32 *addr;
- u64 size;
+ struct resource r;
int index;
- for (index = 0; (addr = of_get_address(np, index, &size)) != NULL;
- index++) {
+ for (index = 0; of_address_to_resource(np, index, &r) == 0; index++) {
struct resource *res = &dev->resource[index];
if (index >= MACIO_DEV_COUNT_RESOURCES)
break;
- res->start = of_translate_address(np, addr);
- res->end = res->start + (unsigned long)size - 1;
- res->flags = IORESOURCE_MEM;
+ *res = r;
res->name = dev->ofdev.dev.bus_id;
if (macio_resource_quirks(np, res, index)) {
@@ -353,7 +349,7 @@ static void macio_setup_resources(struct
/* Currently, we consider failure as harmless, this may
* change in the future, once I've found all the device
* tree bugs in older machines & worked around them
- */
+l */
if (insert_resource(parent_res, res)) {
printk(KERN_WARNING "Can't request resource "
"%d for MacIO device %s\n",
Index: linux-work/include/asm-powerpc/pci-bridge.h
===================================================================
--- linux-work.orig/include/asm-powerpc/pci-bridge.h 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/include/asm-powerpc/pci-bridge.h 2005-11-30 15:38:27.000000000 +1100
@@ -157,6 +157,15 @@ extern struct pci_controller *
pcibios_alloc_controller(struct device_node *dev);
extern void pcibios_free_controller(struct pci_controller *phb);
+#ifdef CONFIG_PCI
+extern unsigned int pci_address_to_pio(phys_addr_t address);
+#else
+static inline unsigned int pci_address_to_pio(phys_addr_t address)
+{
+ return (unsigned int)-1;
+}
+#endif
+
/* Return values for ppc_md.pci_probe_mode function */
#define PCI_PROBE_NONE -1 /* Don't look at this bus at all */
#define PCI_PROBE_NORMAL 0 /* Do normal PCI probing */
Index: linux-work/include/asm-ppc/pci-bridge.h
===================================================================
--- linux-work.orig/include/asm-ppc/pci-bridge.h 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/include/asm-ppc/pci-bridge.h 2005-11-30 15:38:27.000000000 +1100
@@ -137,5 +137,14 @@ static inline unsigned char bridge_swizz
*/
extern int pciauto_bus_scan(struct pci_controller *, int);
+#ifdef CONFIG_PCI
+extern unsigned int pci_address_to_pio(phys_addr_t address);
+#else
+static inline unsigned int pci_address_to_pio(phys_addr_t address)
+{
+ return (unsigned int)-1;
+}
+#endif
+
#endif
#endif /* __KERNEL__ */
Index: linux-work/include/asm-ppc/prom.h
===================================================================
--- linux-work.orig/include/asm-ppc/prom.h 2005-11-30 15:37:21.000000000 +1100
+++ linux-work/include/asm-ppc/prom.h 2005-11-30 15:38:27.000000000 +1100
@@ -138,12 +138,34 @@ extern unsigned long sub_reloc_offset(un
/*
- * Address translation function(s)
+ * OF address retreival & translation
+ */
+
+
+/* Translate an OF address block into a CPU physical address
*/
#define OF_BAD_ADDR ((u64)-1)
extern u64 of_translate_address(struct device_node *np, u32 *addr);
-extern u32 *of_get_address(struct device_node *dev, int index, u64 *size);
-extern u32 *of_get_pci_address(struct device_node *dev, int bar_no, u64 *size);
+
+/* Extract an address from a device, returns the region size and
+ * the address space flags too. The PCI version uses a BAR number
+ * instead of an absolute index
+ */
+extern u32 *of_get_address(struct device_node *dev, int index,
+ u64 *size, unsigned int *flags);
+extern u32 *of_get_pci_address(struct device_node *dev, int bar_no,
+ u64 *size, unsigned int *flags);
+
+/* Get an address as a resource. Note that if your address is
+ * a PIO address, the conversion will fail if the physical address
+ * can't be internally converted to an IO token with
+ * pci_address_to_pio(), that is because it's either called to early
+ * or it can't be matched to any host bridge IO space
+ */
+extern int of_address_to_resource(struct device_node *dev, int index,
+ struct resource *r);
+extern int of_pci_address_to_resource(struct device_node *dev, int bar,
+ struct resource *r);
#endif /* _PPC_PROM_H */
^ permalink raw reply
* [PATCH] powerpc: udbg updates
From: Benjamin Herrenschmidt @ 2005-11-30 5:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
The udbg low level io layer has an issue with udbg_getc() returning a
char (unsigned on ppc) instead of an int, thus the -1 if you had no
available input device could end up turned into 0xff, filling your
display with bogus characters. This fixes it, along with adding a little
blob to xmon to do a delay before exiting when getting an EOF and fixing
the detection of ADB keyboards in udbg_adb.c
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
For the powerpc tree, not for 2.6.15.
Index: linux-work/arch/powerpc/kernel/prom_parse.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/prom_parse.c 2005-11-30 15:23:47.000000000 +1100
+++ linux-work/arch/powerpc/kernel/prom_parse.c 2005-11-30 15:30:17.000000000 +1100
@@ -276,7 +276,7 @@ static int of_translate_one(struct devic
finish:
of_dump_addr("OF: parent translation for:", addr, pna);
- DBG("OF: with offset: %lx\n", offset);
+ DBG("OF: with offset: "PRu64"\n", offset);
/* Translate it into parent bus space */
return pbus->translate(addr, offset, pna);
Index: linux-work/arch/powerpc/kernel/udbg.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/udbg.c 2005-11-30 15:19:50.000000000 +1100
+++ linux-work/arch/powerpc/kernel/udbg.c 2005-11-30 15:30:40.000000000 +1100
@@ -17,7 +17,7 @@
#include <asm/processor.h>
void (*udbg_putc)(char c);
-char (*udbg_getc)(void);
+int (*udbg_getc)(void);
int (*udbg_getc_poll)(void);
/* udbg library, used by xmon et al */
@@ -57,8 +57,8 @@ int udbg_write(const char *s, int n)
int udbg_read(char *buf, int buflen)
{
- char c, *p = buf;
- int i;
+ char *p = buf;
+ int i, c;
if (!udbg_getc)
return 0;
@@ -66,8 +66,11 @@ int udbg_read(char *buf, int buflen)
for (i = 0; i < buflen; ++i) {
do {
c = udbg_getc();
+ if (c == -1 && i == 0)
+ return -1;
+
} while (c == 0x11 || c == 0x13);
- if (c == 0)
+ if (c == 0 || c == -1)
break;
*p++ = c;
}
Index: linux-work/arch/powerpc/kernel/udbg_16550.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/udbg_16550.c 2005-11-30 15:19:50.000000000 +1100
+++ linux-work/arch/powerpc/kernel/udbg_16550.c 2005-11-30 15:24:47.000000000 +1100
@@ -69,14 +69,14 @@ static int udbg_550_getc_poll(void)
return -1;
}
-static char udbg_550_getc(void)
+static int udbg_550_getc(void)
{
if (udbg_comport) {
while ((in_8(&udbg_comport->lsr) & LSR_DR) == 0)
/* wait for char */;
return in_8(&udbg_comport->rbr);
}
- return 0;
+ return -1;
}
void udbg_init_uart(void __iomem *comport, unsigned int speed,
Index: linux-work/arch/powerpc/platforms/powermac/udbg_adb.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/udbg_adb.c 2005-11-30 15:19:50.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/udbg_adb.c 2005-11-30 15:24:47.000000000 +1100
@@ -29,7 +29,7 @@
*/
static void (*udbg_adb_old_putc)(char c);
-static char (*udbg_adb_old_getc)(void);
+static int (*udbg_adb_old_getc)(void);
static int (*udbg_adb_old_getc_poll)(void);
static enum {
@@ -73,7 +73,7 @@ static unsigned char xmon_shift_keytab[1
"\0.\0*\0+\0\0\0\0\0/\r\0-\0" /* 0x40 - 0x4f */
"\0\0000123456789\0\0\0"; /* 0x50 - 0x5f */
-static char udbg_adb_local_getc(void)
+static int udbg_adb_local_getc(void)
{
int k, t, on;
@@ -116,7 +116,7 @@ static char udbg_adb_local_getc(void)
}
#endif /* CONFIG_BOOTX_TEXT */
-static char udbg_adb_getc(void)
+static int udbg_adb_getc(void)
{
#ifdef CONFIG_BOOTX_TEXT
if (udbg_adb_use_btext && input_type != input_adb_none)
@@ -192,7 +192,7 @@ int udbg_adb_init(int force_btext)
*/
for (np = NULL; (np = of_find_node_by_name(np, "keyboard")) != NULL;) {
struct device_node *parent = of_get_parent(np);
- int found = (parent && !strcmp(parent->type, "adb") == 0);
+ int found = (parent && strcmp(parent->type, "adb") == 0);
of_node_put(parent);
if (found)
break;
Index: linux-work/arch/powerpc/platforms/powermac/udbg_scc.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/udbg_scc.c 2005-11-30 15:19:50.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/udbg_scc.c 2005-11-30 15:24:47.000000000 +1100
@@ -47,14 +47,14 @@ static int udbg_scc_getc_poll(void)
return -1;
}
-static char udbg_scc_getc(void)
+static int udbg_scc_getc(void)
{
if (sccc) {
while ((in_8(sccc) & SCC_RXRDY) == 0)
;
return in_8(sccd);
}
- return 0;
+ return -1;
}
static unsigned char scc_inittab[] = {
Index: linux-work/arch/powerpc/platforms/pseries/lpar.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/pseries/lpar.c 2005-11-30 15:19:50.000000000 +1100
+++ linux-work/arch/powerpc/platforms/pseries/lpar.c 2005-11-30 15:24:47.000000000 +1100
@@ -112,7 +112,7 @@ static int udbg_hvsi_getc_poll(void)
return ch;
}
-static char udbg_hvsi_getc(void)
+static int udbg_hvsi_getc(void)
{
int ch;
for (;;) {
@@ -173,7 +173,7 @@ static int udbg_getc_pollLP(void)
return ch;
}
-static char udbg_getcLP(void)
+static int udbg_getcLP(void)
{
int ch;
for (;;) {
Index: linux-work/arch/powerpc/xmon/xmon.c
===================================================================
--- linux-work.orig/arch/powerpc/xmon/xmon.c 2005-11-30 15:19:50.000000000 +1100
+++ linux-work/arch/powerpc/xmon/xmon.c 2005-11-30 15:24:47.000000000 +1100
@@ -450,7 +450,6 @@ int xmon_core(struct pt_regs *regs, int
leave:
cpu_clear(cpu, cpus_in_xmon);
xmon_fault_jmp[cpu] = NULL;
-
#else
/* UP is simple... */
if (in_xmon) {
@@ -805,7 +804,10 @@ cmds(struct pt_regs *excp)
break;
case 'x':
case 'X':
+ return cmd;
case EOF:
+ printf(" <no input ...>\n");
+ mdelay(2000);
return cmd;
case '?':
printf(help_string);
Index: linux-work/include/asm-powerpc/udbg.h
===================================================================
--- linux-work.orig/include/asm-powerpc/udbg.h 2005-11-30 15:19:50.000000000 +1100
+++ linux-work/include/asm-powerpc/udbg.h 2005-11-30 15:24:47.000000000 +1100
@@ -14,7 +14,7 @@
#include <linux/init.h>
extern void (*udbg_putc)(char c);
-extern char (*udbg_getc)(void);
+extern int (*udbg_getc)(void);
extern int (*udbg_getc_poll)(void);
extern void udbg_puts(const char *s);
Index: linux-work/drivers/macintosh/via-pmu.c
===================================================================
--- linux-work.orig/drivers/macintosh/via-pmu.c 2005-11-30 15:23:50.000000000 +1100
+++ linux-work/drivers/macintosh/via-pmu.c 2005-11-30 15:30:20.000000000 +1100
@@ -313,7 +313,7 @@ int __init find_via_pmu(void)
goto fail;
}
taddr = of_translate_address(vias, reg);
- if (taddr == 0) {
+ if (taddr == OF_BAD_ADDR) {
printk(KERN_ERR "via-pmu: Can't translate address !\n");
goto fail;
}
@@ -376,7 +376,7 @@ int __init find_via_pmu(void)
return 0;
}
- printk(KERN_INFO "PMU driver %d initialized for %s, firmware: %02x\n",
+ printk(KERN_INFO "PMU driver v%d initialized for %s, firmware: %02x\n",
PMU_DRIVER_VERSION, pbook_type[pmu_kind], pmu_version);
sys_ctrler = SYS_CTRLER_PMU;
^ permalink raw reply
* Re: [RFC] add PHY support to AM79C874
From: Kumar Gala @ 2005-11-30 5:51 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: linuxppc-embedded
In-Reply-To: <20051128141042.GR7163@cathedrallabs.org>
I would suggest sending this to the netdev list for review and
acceptance.
- kumar
On Nov 28, 2005, at 8:10 AM, Aristeu Sergio Rozanski Filho wrote:
> This is a simple port from old fec driver to PHY layer to support AMD
> AM79C874 PHY.
> As I don't have the hardware to test this, all kinds of feedback are
> most welcome.
> Thanks,
>
> --
> Aristeu
>
> <phy-add_am79c874_phy.patch>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: spi on mpc82xx
From: Kumar Gala @ 2005-11-30 5:49 UTC (permalink / raw)
To: Thomas Arvanitis; +Cc: linuxppc-embedded
In-Reply-To: <20051129111442.GB27630@inaccessnetworks.com>
On Nov 29, 2005, at 5:14 AM, Thomas Arvanitis wrote:
> Hi,
>
> I was wondering what is the status for supporting spi devices with 2.6
> on an mpc82xx device (I use an mpc8275). I checked and the kernel from
> kernel.org does not include anything. Is there an spi bus
> infrastructure (like i2c) coming any time soon, where one can add
> support for specific chips, and then write a driver on top of that?
> Or a plan for these things?
>
> I found a patch for something like that, by Grant Likely, but I don't
> know whether I should go that way.
>
> I want to write a driver for controlling the micrel ks8995 ethernet
> switch through spi. Should I just go for a self contained driver?
There has be some patches on the lkml list for the creation of a SPI
layer similar to I2C. I'm not sure what the latest status is. I'd
google search for SPI on lkml.
Once something like that gets in I'm sure someone will get around to
contributing a SPI driver for the 82xx line of processors.
- kumar
^ permalink raw reply
* Re: Is there some articles discussing how to change bare-board code to linux driver?
From: David H. Lynch Jr @ 2005-11-30 2:03 UTC (permalink / raw)
To: T Ziomek, linuxppc-embedded
In-Reply-To: <Pine.WNT.4.61.0511291821320.3620@holyoke.labs.mot.com>
Where can I find the ./drivers/net/xilinx_enet, ... etc files.
I can not find them in the 2.6.14.2 tree
T Ziomek wrote:
>> Where can i find them?thanks.
>
> In addition to LDD3 (for 2.6 kernels, or the freely available LDD2 for
> 2.4 kernels), you might want to look at some existing Linux drivers
> that are
> based on "bare metal" / "no OS" drivers. The ones I know of are for
> Xilinx
> peripherals, for example (within the Linux kernel tree),
> - ./drivers/net/xilinx_enet
> - ./drivers/char/xilinx_uartlite
> - ./drivers/char/xilinx_gpio
>
> Tom
^ permalink raw reply
* re: Is there some articles discussing how to change bare-board code to linux driver?
From: T Ziomek @ 2005-11-30 0:35 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051125214126.15F9E6884D@ozlabs.org>
> Where can i find them?thanks.
In addition to LDD3 (for 2.6 kernels, or the freely available LDD2 for 2.4
kernels), you might want to look at some existing Linux drivers that are
based on "bare metal" / "no OS" drivers. The ones I know of are for Xilinx
peripherals, for example (within the Linux kernel tree),
- ./drivers/net/xilinx_enet
- ./drivers/char/xilinx_uartlite
- ./drivers/char/xilinx_gpio
Tom
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Kernel 2.6 support for MVME5500?
From: Henry A. Leinhos @ 2005-11-29 20:31 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 220 bytes --]
Hi,
Does anyone have any information regarding support for the Motorola
MVME5500 SBC under kernel 2.6.x? Motorola has 2.4.x patches on their
website, but I can't seem to find anything for 2.6.x.
Thanks,
Henry
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2562 bytes --]
^ 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