* Re: USB Disk Support...FIXED
From: Jeff Stevens @ 2006-10-11 10:54 UTC (permalink / raw)
To: linuxppc-embedded
For those interested, I figured out the issue. It was an incorrect PCIX PI=
M setting. Even though the comment on the PIM windows that are setup in lu=
an.c (the board specific platform file in the kernel) says 2GB window, the =
actual register setting is only for a 512MB window. I happend to have 1GB =
of memory in my system, and it must have been allocating an address above t=
he 512MB. In the Luan board, I only had 512MB, so that is why it worked th=
ere.=0A=0AMaybe in the next kernel release, the comment should be fixed to =
match the register setting.=0A=0A-Jeff Stevens=0A=0A----- Original Message =
----=0AFrom: Jeff Stevens <jsteve17@yahoo.com>=0ATo: Jeff Stevens <jsteve17=
@yahoo.com>; linuxppc-embedded@ozlabs.org=0ASent: Sunday, October 8, 2006 1=
2:26:17 PM=0ASubject: Re: USB Disk Support=0A=0AI have more information. I=
am using a Phillips=0AISP1562 USB host controller. I ran the same kernel=
=0Aconfig on the actual Luan board (with an ISP1563 PCI=0Aeval board from P=
hillips), and the USB storage works=0Afine. I compared the dmesg from both=
the Luan board=0Aand our 440SP custom system, and here are the=0Adifferenc=
es:=0A=0AThe custom system stops at:=0A...=0Ausb-storage: Command READ_CAPA=
CITY (10 bytes)=0Ausb-storage: 25 00 00 00 00 00 00 00 00 00=0Ausb-storage=
: Bulk Command S 0x43425355 T 0x3 L 8 F 128=0ATrg 0 LUN 0 CL 10=0Ausb-stora=
ge: usb_stor_bulk_transfer_buf: xfer 31 bytes=0Ausb-storage: Status code 0;=
transferred 31/31=0Ausb-storage: -- transfer complete=0Ausb-storage: Bulk =
command transfer result=3D0=0Ausb-storage: usb_stor_bulk_transfer_sglist: x=
fer 8=0Abytes, 1 entries=0Ausb-storage: Status code 0; transferred 8/8=0Aus=
b-storage: -- transfer complete=0Ausb-storage: Bulk data transfer result 0x=
0=0Ausb-storage: Attempting to get CSW...=0Ausb-storage: usb_stor_bulk_tran=
sfer_buf: xfer 13 bytes=0Ausb-storage: command_abort called=0Ausb-storage: =
usb_stor_stop_transport called=0Ausb-storage: -- cancelling URB=0A=0AIt see=
ms to fail on Attempting to get CSW... On the=0ALuan board it gets passed =
this:=0A=0Ausb-storage: Command READ_CAPACITY (10 bytes)=0Ausb-storage: 25=
00 00 00 00 00 00 00 00 00=0Ausb-storage: Bulk Command S 0x43425355 T 0x3 =
L 8 F 128=0ATrg 0 LUN 0 CL 10=0Ausb-storage: usb_stor_bulk_transfer_buf: xf=
er 31 bytes=0Ausb-storage: Status code 0; transferred 31/31=0Ausb-storage: =
-- transfer complete=0Ausb-storage: Bulk command transfer result=3D0=0Ausb-=
storage: usb_stor_bulk_transfer_sglist: xfer 8=0Abytes, 1 entries=0Ausb-sto=
rage: Status code 0; transferred 8/8=0Ausb-storage: -- transfer complete=0A=
usb-storage: Bulk data transfer result 0x0=0Ausb-storage: Attempting to get=
CSW...=0Ausb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes=0Ausb-stor=
age: Status code 0; transferred 13/13=0Ausb-storage: -- transfer complete=
=0Ausb-storage: Bulk status result =3D 0=0Ausb-storage: Bulk Status S 0x534=
25355 T 0x3 R 0 Stat=0A0x0=0Ausb-storage: scsi cmd done, result=3D0x0=0Ausb=
-storage: *** thread sleeping.=0Ausb-storage: queuecommand called=0Ausb-sto=
rage: *** thread awakened.=0Ausb-storage: Command MODE_SENSE (6 bytes)=0Aus=
b-storage: 1a 00 3f 00 c0 00=0Ausb-storage: Bulk Command S 0x43425355 T 0x=
4 L 192 F=0A128 Trg 0 LUN 0 CL 6=0Ausb-storage: usb_stor_bulk_transfer_buf:=
xfer 31 bytes=0Ausb-storage: Status code 0; transferred 31/31=0A... <conti=
nues>=0A=0ACould this be a noisy usb port? The USB controller=0Aused is th=
e same, the only difference is that on the=0Acustom board, the USB controll=
er is onboard, where as=0Aon the Luan board it is a PCI card. U-boot is al=
so=0Ausing practically the same board specific config file=0Aand board file=
, other than the flash and DDR stuff. =0AOn the custom board, the card read=
er never ends up in=0A/proc/scsi/scsi, but it does on the luan board.=0A=0A=
Thanks,=0A Jeff Stevens=0A=0A=0A--- Jeff Stevens <jsteve17@yahoo.com> wro=
te:=0A=0A> I am having issues getting a uDiskOnChip to mount or=0A> fdisk u=
nder linux. I have a board running U-Boot on=0A> a=0A> AMCC 440SP platform=
. Linux seems to find the=0A> uDiskOnChip fine, however, when I try to fdi=
sk or=0A> mount the device, the console hangs. I have added=0A> SCSI, SCSI=
storage, USB, USB OHCI, USB EHCI, USB=0A> Mass=0A> Storage. Here is my dm=
esg:=0A> =0A> bash-3.00# dmesg | grep -i usb=0A> usbcore: registered new dr=
iver usbfs=0A> usbcore: registered new driver hub=0A> usbmon: debugfs is no=
t available=0A> drivers/usb/core/inode.c: creating file 'devices'=0A> drive=
rs/usb/core/inode.c: creating file '001'=0A> ehci_hcd 0002:02:08.2: new USB=
bus registered,=0A> assigned bus number 1=0A> ehci_hcd 0002:02:08.2: suppo=
rts USB remote wakeup=0A> ehci_hcd 0002:02:08.2: USB 2.0 started, EHCI 0.95=
,=0A> driver 10 Dec 2004=0A> usb usb1: default language 0x0409=0A> usb usb1=
: new device strings: Mfr=3D3, Product=3D2,=0A> SerialNumber=3D1=0A> usb us=
b1: Product: EHCI Host Controller=0A> usb usb1: Manufacturer: Linux 2.6.17.=
9 ehci_hcd=0A> usb usb1: SerialNumber: 0002:02:08.2=0A> usb usb1: configura=
tion #1 chosen from 1 choice=0A> usb usb1: adding 1-0:1.0 (config #1, inter=
face 0)=0A> hub 1-0:1.0: usb_probe_interface=0A> hub 1-0:1.0: usb_probe_int=
erface - got id=0A> hub 1-0:1.0: USB hub found=0A> drivers/usb/core/inode.c=
: creating file '001'=0A> ohci_hcd: 2005 April 22 USB 1.1 'Open' Host=0A> C=
ontroller=0A> (OHCI) Driver (PCI)=0A> drivers/usb/core/inode.c: creating fi=
le '002'=0A> ohci_hcd 0002:02:08.0: new USB bus registered,=0A> assigned bu=
s number 2=0A> usb usb2: default language 0x0409=0A> usb usb2: new device s=
trings: Mfr=3D3, Product=3D2,=0A> SerialNumber=3D1=0A> usb usb2: Product: O=
HCI Host Controller=0A> usb usb2: Manufacturer: Linux 2.6.17.9 ohci_hcd=0A>=
usb usb2: SerialNumber: 0002:02:08.0=0A> usb usb2: configuration #1 chosen=
from 1 choice=0A> usb usb2: adding 2-0:1.0 (config #1, interface 0)=0A> hu=
b 2-0:1.0: usb_probe_interface=0A> hub 2-0:1.0: usb_probe_interface - got i=
d=0A> hub 2-0:1.0: USB hub found=0A> hub 2-0:1.0: no power switching (usb 1=
.0)=0A> usb 1-1: new high speed USB device using ehci_hcd=0A> and=0A> addre=
ss 2=0A> usb 1-1: default language 0x0409=0A> usb 1-1: new device strings: =
Mfr=3D1, Product=3D2,=0A> SerialNumber=3D3=0A> usb 1-1: Product: uDiskOnChi=
p=0A> usb 1-1: Manufacturer: M-Systems=0A> usb 1-1: SerialNumber: 98B0FB510=
031E86E=0A> usb 1-1: configuration #1 chosen from 1 choice=0A> drivers/usb/=
core/inode.c: creating file '001'=0A> drivers/usb/core/inode.c: creating fi=
le '003'=0A> ohci_hcd 0002:02:08.1: new USB bus registered,=0A> assigned bu=
s number 3=0A> usb 1-1: adding 1-1:1.0 (config #1, interface 0)=0A> drivers=
/usb/core/inode.c: creating file '002'=0A> usb usb3: default language 0x040=
9=0A> usb usb3: new device strings: Mfr=3D3, Product=3D2,=0A> SerialNumber=
=3D1=0A> usb usb3: Product: OHCI Host Controller=0A> usb usb3: Manufacturer=
: Linux 2.6.17.9 ohci_hcd=0A> usb usb3: SerialNumber: 0002:02:08.1=0A> usb =
usb3: configuration #1 chosen from 1 choice=0A> usb usb3: adding 3-0:1.0 (c=
onfig #1, interface 0)=0A> hub 3-0:1.0: usb_probe_interface=0A> hub 3-0:1.0=
: usb_probe_interface - got id=0A> hub 3-0:1.0: USB hub found=0A> hub 3-0:1=
.0: no power switching (usb 1.0)=0A> drivers/usb/core/inode.c: creating fil=
e '001'=0A> Initializing USB Mass Storage driver...=0A> usb-storage 1-1:1.0=
: usb_probe_interface=0A> usb-storage 1-1:1.0: usb_probe_interface - got id=
=0A> usb-storage: USB Mass Storage device detected=0A> usb-storage: -- asso=
ciate_dev=0A> usb-storage: Vendor: 0x08ec, Product: 0x1000,=0A> Revision: 0=
x0200=0A> usb-storage: Interface Subclass: 0x06, Protocol:=0A> 0x50=0A> usb=
-storage: Transport: Bulk=0A> usb-storage: Protocol: Transparent SCSI=0A> s=
csi0 : SCSI emulation for USB Mass Storage devices=0A> usb-storage: *** thr=
ead sleeping.=0A> usbcore: registered new driver usb-storage=0A> USB Mass S=
torage support registered.=0A> usb-storage: device found at 2=0A> usb-stora=
ge: waiting for device to settle before=0A> scanning=0A> usb-storage: usb_s=
tor_control_msg: rq=3Dfe rqtype=3Da1=0A> value=3D0000 index=3D00 len=3D1=0A=
> usb-storage: GetMaxLUN command result is 1, data is=0A> 0=0A> usb-storage=
: queuecommand called=0A> usb-storage: *** thread awakened.=0A> usb-storage=
: Command INQUIRY (6 bytes)=0A> usb-storage: 12 00 00 00 24 00=0A> usb-sto=
rage: Bulk Command S 0x43425355 T 0x1 L 36 F=0A> 128 Trg 0 LUN 0 CL 6=0A> u=
sb-storage: usb_stor_bulk_transfer_buf: xfer 31=0A> bytes=0A> usb-storage: =
Status code 0; transferred 31/31=0A> usb-storage: -- transfer complete=0A> =
usb-storage: Bulk command transfer result=3D0=0A> usb-storage: usb_stor_bul=
k_transfer_sglist: xfer 36=0A> bytes, 1 entries=0A> usb-storage: Status cod=
e 0; transferred 36/36=0A> usb-storage: -- transfer complete=0A> usb-storag=
e: Bulk data transfer result 0x0=0A> usb-storage: Attempting to get CSW...=
=0A> usb-storage: usb_stor_bulk_transfer_buf: xfer 13=0A> bytes=0A> usb-sto=
rage: Status code 0; transferred 13/13=0A> usb-storage: -- transfer complet=
e=0A> usb-storage: Bulk status result =3D 0=0A> usb-storage: Bulk Status S =
0x53425355 T 0x1 R 0 Stat=0A> 0x0=0A> usb-storage: scsi cmd done, result=3D=
0x0=0A> usb-storage: *** thread sleeping.=0A> usb-storage: queuecommand cal=
led=0A> usb-storage: *** thread awakened.=0A> usb-storage: Command TEST_UNI=
T_READY (6 bytes)=0A> usb-storage: 00 00 00 00 00 00=0A> usb-storage: Bulk=
Command S 0x43425355 T 0x2 L 0 F 0=0A> Trg 0 LUN 0 CL 6=0A> usb-storage: u=
sb_stor_bulk_transfer_buf: xfer 31=0A> bytes=0A> usb-storage: Status code 0=
; transferred 31/31=0A> usb-storage: -- transfer complete=0A> usb-storage: =
Bulk command transfer result=3D0=0A> usb-storage: Attempting to get CSW...=
=0A> usb-storage: usb_stor_bulk_transfer_buf: xfer 13=0A> bytes=0A> usb-sto=
rage: Status code 0; transferred 13/13=0A> usb-storage: -- transfer complet=
e=0A> usb-storage: Bulk status result =3D 0=0A> usb-storage: Bulk Status S =
0x53425355 T 0x2 R 0 Stat=0A> 0x0=0A> usb-storage: scsi cmd done, result=3D=
0x0=0A> usb-storage: *** thread sleeping.=0A> usb-storage: queuecommand cal=
led=0A> usb-storage: *** thread awakened.=0A> usb-storage: Command READ_CAP=
ACITY (10 bytes)=0A> usb-storage: 25 00 00 00 00 00 00 00 00 00=0A> usb-st=
orage: Bulk Command S 0x43425355 T 0x3 L 8 F=0A> 128=0A> Trg 0 LUN 0 CL 10=
=0A> usb-storage: usb_stor_bulk_transfer_buf: xfer 31=0A> bytes=0A> usb-sto=
rage: Status code 0; transferred 31/31=0A> usb-storage: -- transfer complet=
e=0A> usb-storage: Bulk command transfer result=3D0=0A> usb-storage: usb_st=
or_bulk_transfer_sglist: xfer 8=0A> bytes, 1 entries=0A> usb-storage: Statu=
s code 0; transferred 8/8=0A> usb-storage: -- transfer complete=0A> usb-sto=
rage: Bulk data transfer result 0x0=0A> usb-storage: Attempting to get CSW.=
..=0A> usb-storage: usb_stor_bulk_transfer_buf: xfer 13=0A> bytes=0A> usb-s=
torage: command_abort called=0A> usb-storage: usb_stor_stop_transport calle=
d=0A> usb-storage: -- cancelling URB=0A> =0A> =0A>=0A----------------------=
---------------------------------=0A> And a few other things:=0A> =0A> bash=
-3.00# cat /proc/bus/usb/devices=0A> =0A> T: Bus=3D03 Lev=3D00 Prnt=3D00 P=
ort=3D00 Cnt=3D00 Dev#=3D 1=0A> Spd=3D12 MxCh=3D 1=0A> B: Alloc=3D 0/90=
0 us ( 0%), #Int=3D 0, #Iso=3D 0=0A> D: Ver=3D 1.10 Cls=3D09(hub ) Sub=
=3D00 Prot=3D00 MxPS=3D64=0A> #Cfgs=3D 1=0A> P: Vendor=3D0000 ProdID=3D00=
00 Rev=3D 2.06=0A> S: Manufacturer=3DLinux 2.6.17.9 ohci_hcd=0A> S: Produ=
ct=3DOHCI Host Controller=0A> S: SerialNumber=3D0002:02:08.1=0A> C:* #Ifs=
=3D 1 Cfg#=3D 1 Atr=3De0 MxPwr=3D 0mA=0A> I: If#=3D 0 Alt=3D 0 #EPs=3D 1 =
Cls=3D09(hub ) Sub=3D00=0A> Prot=3D00=0A> Driver=3Dhub=0A> E: Ad=3D81(I) =
Atr=3D03(Int.) MxPS=3D 2 Ivl=3D255ms=0A> =0A> T: Bus=3D02 Lev=3D00 Prnt=
=3D00 Port=3D00 Cnt=3D00 Dev#=3D 1=0A> Spd=3D12 MxCh=3D 1=0A> B: Alloc=
=3D 0/900 us ( 0%), #Int=3D 0, #Iso=3D 0=0A> D: Ver=3D 1.10 Cls=3D09(hu=
b ) Sub=3D00 Prot=3D00 MxPS=3D64=0A> #Cfgs=3D 1=0A> P: Vendor=3D0000 Pro=
dID=3D0000 Rev=3D 2.06=0A> S: Manufacturer=3DLinux 2.6.17.9 ohci_hcd=0A> S=
: Product=3DOHCI Host Controller=0A> S: SerialNumber=3D0002:02:08.0=0A> C=
:* #Ifs=3D 1 Cfg#=3D 1 Atr=3De0 MxPwr=3D 0mA=0A> I: If#=3D 0 Alt=3D 0 #EP=
s=3D 1 Cls=3D09(hub ) Sub=3D00=0A> Prot=3D00=0A> Driver=3Dhub=0A> E: Ad=
=3D81(I) Atr=3D03(Int.) MxPS=3D 2 Ivl=3D255ms=0A> =0A> T: Bus=3D01 Lev=
=3D00 Prnt=3D00 Port=3D00 Cnt=3D00 Dev#=3D 1=0A> Spd=3D480 MxCh=3D 2=0A> B=
: Alloc=3D 0/800 us ( 0%), #Int=3D 0, #Iso=3D 0=0A> D: Ver=3D 2.00 Cls=
=3D09(hub ) Sub=3D00 Prot=3D01 MxPS=3D64=0A> #Cfgs=3D 1=0A> P: Vendor=3D=
0000 ProdID=3D0000 Rev=3D 2.06=0A> S: Manufacturer=3DLinux 2.6.17.9 ehci_h=
cd=0A> S: Product=3DEHCI Host Controller=0A> S: SerialNumber=3D0002:02:08=
.2=0A> C:* #Ifs=3D 1 Cfg#=3D 1 Atr=3De0 MxPwr=3D 0mA=0A> I: If#=3D 0 Alt=
=3D 0 #EPs=3D 1 Cls=3D09(hub ) Sub=3D00=0A> Prot=3D00=0A> Driver=3Dhub=0A>=
E: Ad=3D81(I) Atr=3D03(Int.) MxPS=3D 2 Ivl=3D256ms=0A> =0A> T: Bus=3D0=
1 Lev=3D01 Prnt=3D01 Port=3D00 Cnt=3D01 Dev#=3D 2=0A> Spd=3D480 MxCh=3D 0=
=0A> D: Ver=3D 2.00 Cls=3D00(>ifc ) Sub=3D00 Prot=3D00 MxPS=3D64=0A> #Cfgs=
=3D 1=0A> P: Vendor=3D08ec ProdID=3D1000 Rev=3D 2.00=0A> S: Manufacturer=
=3DM-Systems=0A> S: Product=3DuDiskOnChip=0A> S: SerialNumber=3D98B0FB510=
031E86E=0A> C:* #Ifs=3D 1 Cfg#=3D 1 Atr=3D80 MxPwr=3D140mA=0A> I: If#=3D 0=
Alt=3D 0 #EPs=3D 2 Cls=3D08(stor.) Sub=3D06=0A> Prot=3D50=0A> Driver=3Dusb=
-storage=0A> E: Ad=3D81(I) Atr=3D02(Bulk) MxPS=3D 512 Ivl=3D0ms=0A> E: Ad=
=3D02(O) Atr=3D02(Bulk) MxPS=3D 512 Ivl=3D0ms=0A> =0A> bash-3.00# cat /proc=
/scsi/scsi=0A> Attached devices:=0A> =0A> =0A> It's probably just a kernel =
config issue, but I'm=0A> not=0A> sure what else to try. I would appreciat=
e any=0A> input!=0A> =0A> Thanks,=0A> Jeff=0A> =0A> ____________________=
______________________________=0A> Do You Yahoo!?=0A> Tired of spam? Yahoo=
! Mail has the best spam=0A> protection around =0A> http://mail.yahoo.com =
=0A> _______________________________________________=0A> Linuxppc-embedded =
mailing list=0A> Linuxppc-embedded@ozlabs.org=0A>=0Ahttps://ozlabs.org/mail=
man/listinfo/linuxppc-embedded=0A> =0A=0A=0A_______________________________=
___________________=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the =
best spam protection around =0Ahttp://mail.yahoo.com =0A=0A=0A=0A=0A
^ permalink raw reply
* [PATCH] Fix MPC8360EMDS PB board support
From: Li Yang @ 2006-10-11 11:04 UTC (permalink / raw)
To: Paul; +Cc: linuxppc-dev
MPC8360EMDS PB support is broken as some code was missing
in last submission. This patch adds missing code and makes
MPC8360EMDS PB support working.
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
As Kim's patch to add Kconfig file hasn't been merged, I
include the fix in this patch.
arch/powerpc/platforms/83xx/Kconfig | 13 +++++++++++++
arch/powerpc/platforms/83xx/Makefile | 1 +
arch/powerpc/platforms/83xx/mpc8360e_pb.c | 19 +++++++++++++++++++
3 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
index 0975e94..7edb6b4 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -32,6 +32,13 @@ config MPC834x_ITX
Be aware that PCI initialization is the bootloader's
responsiblilty.
+config MPC8360E_PB
+ bool "Freescale MPC8360E PB"
+ select DEFAULT_UIMAGE
+ select QUICC_ENGINE
+ help
+ This option enables support for the MPC836x EMDS Processor Board.
+
endchoice
config PPC_MPC832x
@@ -46,4 +53,10 @@ config MPC834x
select PPC_INDIRECT_PCI
default y if MPC834x_SYS || MPC834x_ITX
+config PPC_MPC836x
+ bool
+ select PPC_UDBG_16550
+ select PPC_INDIRECT_PCI
+ default y if MPC8360E_PB
+
endmenu
diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile
index 9387a11..e60fd75 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -5,3 +5,4 @@ obj-y := misc.o
obj-$(CONFIG_PCI) += pci.o
obj-$(CONFIG_MPC834x_SYS) += mpc834x_sys.o
obj-$(CONFIG_MPC834x_ITX) += mpc834x_itx.o
+obj-$(CONFIG_MPC8360E_PB) += mpc8360e_pb.o
diff --git a/arch/powerpc/platforms/83xx/mpc8360e_pb.c b/arch/powerpc/platforms/83xx/mpc8360e_pb.c
index c019190..1a523c8 100644
--- a/arch/powerpc/platforms/83xx/mpc8360e_pb.c
+++ b/arch/powerpc/platforms/83xx/mpc8360e_pb.c
@@ -30,6 +30,7 @@ #include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/initrd.h>
+#include <asm/of_device.h>
#include <asm/system.h>
#include <asm/atomic.h>
#include <asm/time.h>
@@ -141,6 +142,24 @@ #else
#endif
}
+static int __init mpc8360_declare_of_platform_devices(void)
+{
+ struct device_node *np;
+
+ for (np = NULL; (np = of_find_compatible_node(np, "network",
+ "ucc_geth")) != NULL;) {
+ int ucc_num;
+ char bus_id[BUS_ID_SIZE];
+
+ ucc_num = *((uint *) get_property(np, "device-id", NULL)) - 1;
+ snprintf(bus_id, BUS_ID_SIZE, "ucc_geth.%u", ucc_num);
+ of_platform_device_create(np, bus_id, NULL);
+ }
+
+ return 0;
+}
+device_initcall(mpc8360_declare_of_platform_devices);
+
void __init mpc8360_sys_init_IRQ(void)
{
^ permalink raw reply related
* [PATCH] Add Makefile entry for MPC832x_mds support
From: Li Yang @ 2006-10-11 11:27 UTC (permalink / raw)
To: Paul; +Cc: linuxppc-dev
Add missing entry in Makefile for MPC832x MDS support. It
also change white space to tab in MPC8360 entry.
Signed-off-by: Li Yang <leoli@freescale.com>
---
diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile
index e60fd75..f1aa7e2 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -5,4 +5,5 @@ obj-y := misc.o
obj-$(CONFIG_PCI) += pci.o
obj-$(CONFIG_MPC834x_SYS) += mpc834x_sys.o
obj-$(CONFIG_MPC834x_ITX) += mpc834x_itx.o
-obj-$(CONFIG_MPC8360E_PB) += mpc8360e_pb.o
+obj-$(CONFIG_MPC8360E_PB) += mpc8360e_pb.o
+obj-$(CONFIG_MPC832x_MDS) += mpc832x_mds.o
^ permalink raw reply related
* help for sound support on PPC405EP
From: jagadeesh kali @ 2006-10-11 13:31 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1.1: Type: text/plain, Size: 682 bytes --]
Hi,
I am working on AMCC PPC405EP Taihu board.
I created Linux kernel Image with kernel source 2.6.13(provided by AMCC) by
enabling inbuilt alsa-drivers(CA0106) for soundcard Creative Sound Blaster
Live 24bit! and I am using ELDK 4.0.
we have successfully installed alsa-libs and alsa-utils on the board using
ELDK 4.0 compilers.
The sound card is detecting properly when I type "aplay -l", but I am unable
to play audio file on the Taihu board.
I am getting some exceptions while playing audio files on the board.
The log file contains the errors.
Please let me know weather we have to made any kernel level configurations
for sound support?
Thanks and Regards,
Jagadeesh.
[-- Attachment #1.2: Type: text/html, Size: 762 bytes --]
[-- Attachment #2: log.txt --]
[-- Type: text/plain, Size: 5227 bytes --]
______________________________________________________________________________
With Sound Card (Creative Sound Blaster Live! 24 bit ) on the Taihu board
______________________________________________________________________________
bash-3.00# aplay
Aborted by signal Interrupt...
bash-3.00#
bash-3.00# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: CA0106 [CA0106], device 0: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 1: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 2: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 3: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
bash-3.00#
bash-3.00# arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: CA0106 [CA0106], device 0: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 1: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 2: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 3: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
bash-3.00#
___________________________________________________________________________________________________
_____while playing audio files ____________________________________________________________________
bash-3.00# aplay audio1.wav
Playing WAVE 'audio1.wav' : Unsigned 8 bit, RateData machine check in kernel mode.
PLB0: BEAR= 0x3f107000 ACR= 0x00000000 BESR= 0x00c00000
PLB0 to OPB: BEAR= 0x00000000 BESR0= 0x00000000 BESR1= 0x00000000
Oops: machine check, sig: 7 [#1]
NIP: C0003730 LR: C00035BC SP: C73D3F40 REGS: c02ccf50 TRAP: 0202 Not tainted
MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c7785470[1290] 'aplay' THREAD: c73d2000
Last syscall: 3
GPR00: 00000000 C73D3F40 C7785470 00004000 00000001 00000000 C72E8978 00000000
GPR08: C778578C 00000004 00029032 C73D2000 22008028 100246D4 000002AA 00000000
GPR16: 10027BEC 00001000 00000000 00000000 00000000 00300C03 10027BF0 00080000
GPR24: 30038004 1001DB24 00000000 10036220 1001D7D0 00000000 0FFE7C58 FFFFE100
Call trace:
8000 Hz, Mono
Data machine check in kernel mode.
PLB0: BEAR= 0x3f107000 ACR= 0x00000000 BESR= 0x00800000
PLB0 to OPB: BEAR= 0x00000000 BESR0= 0x00000000 BESR1= 0x00000000
Oops: machine check, sig: 7 [#2]
NIP: C0004958 LR: C0003510 SP: C02CCE30 REGS: c02ccf50 TRAP: 0202 Not tainted
MSR: 00021030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c7785470[1290] 'aplay' THREAD: c73d2000
Last syscall: 3
GPR00: 08000000 C02CCE30 C7785470 C02CCE40 C02CF394 00000000 3B7F4486 3B7F4486
GPR08: C02CF398 C0003510 00021032 C0004958 07785638 100246D4 000002AA 00000000
GPR16: 10027BEC 00001000 00000000 00000000 00000000 00300C03 10027BF0 C7785554
GPR24: C7785520 C77854DC C02CCEF8 C0434B10 C77854DC 00000010 C7785470 C04462E0
Fixing recursive fault but reboot is needed!
Bus error
bash-3.00#
bash-3.00# arecord 1.wav
Recording WAVE '1.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono
overrun!!! (at least 0.203 ms long)
Data machine check in kernel mode.
PLB0: BEAR= 0x3f117000 ACR= 0x00000000 BESR= 0x00c00000
PLB0 to OPB: BEAR= 0x00000000 BESR0= 0x00000000 BESR1= 0x00000000
Oops: machine check, sig: 7 [#9]
NIP: C0003730 LR: C00035BC SP: C71F3F40 REGS: c02ccf50 TRAP: 0202 Not tainted
MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c7dde0b0[1296] 'arecord' THREAD: c71f2000
Last syscall: 167
GPR00: 00000000 C71F3F40 C7DDE0B0 00004000 00000001 00000000 C7226958 00000000
GPR08: C7DDE3CC 00000004 00029032 C71F2000 22048028 100246D4 3001E000 0FF6FA74
GPR16: 7FBDF4E0 0FF6F868 00000002 7FBDF500 00001008 7FBDF4B0 00000000 00000000
GPR24: 00000000 00000000 30028000 00000004 00000000 7FBDF4B0 0FFE79A8 7FBDF510
Call trace:
Bus error
bash-3.00#
__________________________________________________________________________________________________
___________________________________________________________________________________________________
____________________________________________________
Without Sound Card on the Taihu board
____________________________________________________
bash-3.00# aplay
ALSA lib confmisc.c:560:(snd_determine_driver) could not open control for card 0
ALSA lib conf.c:3479:(_snd_config_evaluate) function snd_func_card_driver returned error: No such device
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:3479:(_snd_config_evaluate) function snd_func_concat returned error: No such device
ALSA lib confmisc.c:955:(snd_func_refer) error evaluating name
ALSA lib conf.c:3479:(_snd_config_evaluate) function snd_func_refer returned error: No such device
ALSA lib conf.c:3948:(snd_config_expand) Evaluate error: No such device
ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown PCM default
aplay: main:533: audio open error: No such device
bash-3.00#
bash-3.00# aplay -l
aplay: device_list:218: no soundcards found...
bash-3.00#
bash-3.00# arecord -l
arecord: device_list:218: no soundcards found...
bash-3.00#
^ permalink raw reply
* Re: Graphic issues (emulating VGA bios on IBM Maple)
From: Michel Dänzer @ 2006-10-11 13:49 UTC (permalink / raw)
To: jean-francois simon; +Cc: linuxppc-dev
In-Reply-To: <20061010203620.771.qmail@web27502.mail.ukl.yahoo.com>
On Tue, 2006-10-10 at 22:36 +0200, jean-francois simon wrote:
> Hi,
> I have ported the x86emu x86 emulator to IBM PIBS firmware on a Maple
> platform. I am now trying to emulate a PCI ATI RADEON RV100 VGA BIOS.
> It goes all the way and seems OK. When I boot Linux , the card is
> recognized (it wasn't before),
If the VGA BIOS POST works correctly, you should probably see some
output in VGA text mode. Do you?
> but the screen just flickers a couple of time. I worry about the message:
> "radeonfb: Retrieved PLL infos from BIOS" since I don't have a BIOS.
It refers to the VGA BIOS.
> The PLL values may be bogus..
[...]
> radeonfb: Retrieved PLL infos from BIOS
> radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=150.00 Mhz,
> System=150.00 MHz
> radeonfb:
> PLL min 12000 max 35000
These look sane.
> radeonfb: I2C (port 3) ... found CRT display
> radeonfb: Monitor 1 type CRT found
> radeonfb: EDID probed
> radeonfb: Monitor 2 type no found
Is this correct?
> hStart = 1328, hEnd = 1440, hTotal = 1688
> vStart = 1025, vEnd = 1028, vTotal = 1066
Does the monitor support this mode?
> kobject_register failed for radeonfb (-17)
> Call Trace:
> [C000000000BFFB60] [C00000000000E97C] .show_stack+0x68/0x1b4
> (unreliable)
> [C000000000BFFC10] [C00000000017EC54] .kobject_register+0x5c/0x8c
> [C000000000BFFCA0] [C0000000001FAAF0] .bus_add_driver+0x7c/0x1b4
> [C000000000BFFD50] [C0000000001FBDC8] .driver_register+0xac/0xc8
> [C000000000BFFDD0] [C00000000018D084] .__pci_register_driver+0x8c/0xdc
> [C000000000BFFE60] [C0000000003CCC9C] .radeonfb_old_init+0x164/0x188
> [C000000000BFFF00] [C00000000000929C] .init+0x258/0x3d0
> [C000000000BFFF90] [C00000000001E848] .kernel_thread+0x4c/0x68
Could this be the problem?
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Problems with DMA from user space on MPC834x (Cache coherency?)
From: Lauri Ehrenpreis @ 2006-10-11 14:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
I have a problem with DMA from user space on a platform powered by MPC834x
processor (which has powerpc e300 core inside). Our linux kernel version is
2.6.17.
My user space program does something like this:
file_fd = open("/disk/file", O_RDONLY);
result = read(file_fd, page_aligned_buf, len);
call_driver_ioctl_which_performs_dma();
while /disk is mounted to a partition residing on USB memory stick or SD
card.
page_aligned_buf starts from page boundary and contains enough full pages
for
the data (so I can allways map full page with dma_map_page in kernel).
The buffer address and data length will then be passed to a driver, which
calls
get_user_pages, then maps each page with dma_map_page and tells a PCI
device
to start reading from that page:
...
down_read(¤t->mm->mmap_sem);
result = get_user_pages(current, current->mm, page_aligned_buf, nr_pages,
0, 0, pages, NULL);
up_read(¤t->mm->mmap_sem);
for (i = 0; i < nr_pages; i++) {
find_data_checksum(pages[i]);
dma_addr = dma_map_page(&fpga.pci_dev->dev, pages[i], 0, PAGE_SIZE,
DMA_TO_DEVICE);
start_dma();
wait_until_dma_ready();
dma_unmap_page(&fpga.pci_dev->dev, dma_addr, dma_len, DMA_TO_DEVICE);
if(!checksum_ok_in_fpga())
print_page_data();
}
for (i = 0; i < nr_pages; i++)
page_cache_release(pages[i]);
The problem is that sometimes the PCI device receives wrong bytes at random
locations. I find the data checksum inside the driver and inside the FPGA.
Inside the driver I use kmap(page) and kunmap(page) to access data on the
user page. Sometimes the checksums do not match and I can see with the FPGA
debugging tool, that the FPGA receives different data than the driver is
printing out.
I have noticed 3 things regarding this error:
1) When I copy the data I read from the block device to another buffer in
userspace and pass this new buffer to the driver, then this error will
never occur:
file_fd = open("/disk/file", O_RDONLY);
result = read(file_fd, page_aligned_buf, len);
memcpy(new_page_aligned_buf, page_aligned_buf, len);
call_driver_ioctl_which_performs_dma(new_page_aligned_buf, len);
2) this error does not occur when I use copy_from_user instead of
get_user_pages
and dma_map_page inside driver.
3) this error does not occur on our previuos device, which has x86
platform.
I am currently out of ideas what to do next.. It seems to me like a cache
coherency problem. Can anyone suggest what might be wrong?
--
^ permalink raw reply
* How to connect a CF to a MPC82xx in trueIDE mode with DMA/UDMA capability?
From: Miguel Valero (OS/EXA) @ 2006-10-11 14:07 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 658 bytes --]
Does anybody know whether it is possible to have a CF card directly
connected to a MPC82xx and have it working in trueIDE mode with either
multiword DMA or, preferibly, UDMA capabilities on?
We know how to have it connected and working in trueIDE mode, but
without DMA capabilities.
Is the MPC82xx DMA controller at all able to assist the CF in doing
multiword DMA or UDMA? How does one connect the DMA related CF pins to
the MPC82xx? How does one configure the UPM that controls the CF? Is
there a linux driver for MPC82xx that exploits the DMA/UDMA capabilities
of the CF?
Regards
Miguel A. Valero
R&D engineer
Ericsson AXXESSIT AS
[-- Attachment #2: Type: text/html, Size: 1326 bytes --]
^ permalink raw reply
* Problems with DMA from user space on MPC834x (Cache coherency?)
From: Lauri Ehrenpreis @ 2006-10-11 14:14 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
I have a problem with DMA from user space on a platform powered by MPC834x
processor (which has powerpc e300 core inside). Our linux kernel version is
2.6.17.
My user space program does something like this:
file_fd = open("/disk/file", O_RDONLY);
result = read(file_fd, page_aligned_buf, len);
call_driver_ioctl_which_performs_dma();
while /disk is mounted to a partition residing on USB memory stick or SD
card.
page_aligned_buf starts from page boundary and contains enough full pages
for
the data (so I can allways map full page with dma_map_page in kernel).
The buffer address and data length will then be passed to a driver, which
calls
get_user_pages, then maps each page with dma_map_page and tells a PCI
device
to start reading from that page:
...
down_read(¤t->mm->mmap_sem);
result = get_user_pages(current, current->mm, page_aligned_buf, nr_pages,
0, 0, pages, NULL);
up_read(¤t->mm->mmap_sem);
for (i = 0; i < nr_pages; i++) {
find_data_checksum(pages[i]);
dma_addr = dma_map_page(&fpga.pci_dev->dev, pages[i], 0, PAGE_SIZE,
DMA_TO_DEVICE);
start_dma();
wait_until_dma_ready();
dma_unmap_page(&fpga.pci_dev->dev, dma_addr, dma_len, DMA_TO_DEVICE);
if(!checksum_ok_in_fpga())
print_page_data();
}
for (i = 0; i < nr_pages; i++)
page_cache_release(pages[i]);
The problem is that sometimes the PCI device receives wrong bytes at random
locations. I find the data checksum inside the driver and inside the FPGA.
Inside the driver I use kmap(page) and kunmap(page) to access data on the
user page. Sometimes the checksums do not match and I can see with the FPGA
debugging tool, that the FPGA receives different data than the driver is
printing out.
I have noticed 3 things regarding this error:
1) When I copy the data I read from the block device to another buffer in
userspace and pass this new buffer to the driver, then this error will
never occur:
file_fd = open("/disk/file", O_RDONLY);
result = read(file_fd, page_aligned_buf, len);
memcpy(new_page_aligned_buf, page_aligned_buf, len);
call_driver_ioctl_which_performs_dma(new_page_aligned_buf, len);
2) this error does not occur when I use copy_from_user instead of
get_user_pages
and dma_map_page inside driver.
3) this error does not occur on our previuos device, which has x86
platform.
I am currently out of ideas what to do next.. It seems to me like a cache
coherency problem. Can anyone suggest what might be wrong?
--
^ permalink raw reply
* FYI: SM5xx toolchain project berliOS registration
From: Andrey Volkov @ 2006-10-11 14:36 UTC (permalink / raw)
To: bgat
Cc: linux-fbdev-devel, vince, ben-linux, linuxppc-embedded,
alexdeucher, gewang, syrjala
Hi all,
Yesterday I issued new SiliconMotion SM501 drivers
project request to berlios, and receive
approvement couple hours ago.
So project home page is:
http://developer.berlios.de/projects/sm5xx/
Anyone who wants admin/write-access, please register with
berlios and tell me your account.
SVN will be activated in nearest hours.
Berlios has direct shell access to your repos.
So if there are any svn/CVS-dumps to import or any
scripts to set up...
The central mailing list
sm5xx-devel@lists.berlios.de
will be active soon too.
--
Happy hacking ;),
Andrey Volkov
Varma Electronics Oy
-------- Original Message --------
Subject: BerliOS Developer Project Approved
Date: Wed, 11 Oct 2006 12:49:58 +0200 (CEST)
From: admin@berlios.de
To: avolkov@varma-el.com
Your project registration for BerliOS Developer has been approved.
Project Full Name: SM5xx Toolchain
Project Unix Name: sm5xx
CVS Server: cvs.berlios.de
SVN Server: svn.berlios.de
Shell Server: shell.berlios.de
Web Server: sm5xx.berlios.de
^ permalink raw reply
* Re: Graphic issues (emulating VGA bios on IBM Maple)
From: jf simon @ 2006-10-11 15:06 UTC (permalink / raw)
To: Michel �; +Cc: linuxppc-dev
In-Reply-To: <1160574593.23225.56.camel@thor.lorrainebruecke.local>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8; format=flowed, Size: 1079 bytes --]
>>I have ported the x86emu x86 emulator to IBM PIBS firmware on a Maple
>>platform. I am now trying to emulate a PCI ATI RADEON RV100 VGA BIOS.
>>It goes all the way and seems OK. When I boot Linux , the card is
>>recognized (it wasn't before),
>>
>>
>
>If the VGA BIOS POST works correctly, you should probably see some
>output in VGA text mode. Do you?
>
>
No can do. The Maple platform can't generate any PCI memory access below
0x8000.0000. So it can't access the VGA buffer. I have removed all
these accesses from being generated by the emulator. (all other acceses
to the card, including PCI I/O accesses to the VGA registers remain
though).
I am looking at the radeon driver. Maybe it is confused as it thinks it
is running on an OF based machine while at the same time locates a x86
VGA BIOS.
-jfs
___________________________________________________________________________
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Demandez à ceux qui savent sur Yahoo! Questions/Réponses
http://fr.answers.yahoo.com
^ permalink raw reply
* Re: [PATCH 21/21]: powerpc/cell spidernet DMA coalescing
From: Linas Vepstas @ 2006-10-11 15:20 UTC (permalink / raw)
To: Geoff Levand
Cc: akpm, jeff, Arnd Bergmann, netdev, James K Lewis, linux-kernel,
linuxppc-dev
In-Reply-To: <452C4CE0.5010607@am.sony.com>
On Tue, Oct 10, 2006 at 06:46:08PM -0700, Geoff Levand wrote:
> > Linas Vepstas wrote:
> >> The current driver code performs 512 DMA mappns of a bunch of
> >> 32-byte structures. This is silly, as they are all in contiguous
> >> memory. Ths patch changes the code to DMA map the entie area
> >> with just one call.
>
> Linas,
>
> Is the motivation for this change to improve performance by reducing the overhead
> of the mapping calls?
Yes.
> If so, there may be some benefit for some systems. Could
> you please elaborate?
I started writingthe patch thinking it will have some huge effect on
performance, based on a false assumption on how i/o was done on this
machine
*If* this were another pSeries system, then each call to
pci_map_single() chews up an actual hardware "translation
control entry" (TCE) that maps pci bus addresses into
system RAM addresses. These are somewhat limited resources,
and so one shouldn't squander them. Furthermore, I thouhght
TCE's have TLB's associated with them (similar to how virtual
memory page tables are backed by hardware page TLB's), of which
there are even less of. I was thinking that TLB thrashing would
have a big hit on performance.
Turns out that there was no difference to performance at all,
and a quick look at "cell_map_single()" in arch/powerpc/platforms/cell
made it clear why: there's no fancy i/o address mapping.
Thus, the patch has only mrginal benefit; I submit it only in the
name of "its the right thing to do anyway".
--linas
^ permalink raw reply
* Re: [PATCH 21/21]: powerpc/cell spidernet DMA coalescing
From: Geoff Levand @ 2006-10-11 15:47 UTC (permalink / raw)
To: Linas Vepstas
Cc: akpm, jeff, Arnd Bergmann, netdev, James K Lewis, linux-kernel,
linuxppc-dev
In-Reply-To: <20061011152016.GU4381@austin.ibm.com>
Linas Vepstas wrote:
> On Tue, Oct 10, 2006 at 06:46:08PM -0700, Geoff Levand wrote:
>> > Linas Vepstas wrote:
>> >> The current driver code performs 512 DMA mappns of a bunch of
>> >> 32-byte structures. This is silly, as they are all in contiguous
>> >> memory. Ths patch changes the code to DMA map the entie area
>> >> with just one call.
>>
>> Linas,
>>
>> Is the motivation for this change to improve performance by reducing the overhead
>> of the mapping calls?
>
> Yes.
>
>> If so, there may be some benefit for some systems. Could
>> you please elaborate?
>
> I started writingthe patch thinking it will have some huge effect on
> performance, based on a false assumption on how i/o was done on this
> machine
>
> *If* this were another pSeries system, then each call to
> pci_map_single() chews up an actual hardware "translation
> control entry" (TCE) that maps pci bus addresses into
> system RAM addresses. These are somewhat limited resources,
> and so one shouldn't squander them. Furthermore, I thouhght
> TCE's have TLB's associated with them (similar to how virtual
> memory page tables are backed by hardware page TLB's), of which
> there are even less of. I was thinking that TLB thrashing would
> have a big hit on performance.
>
> Turns out that there was no difference to performance at all,
> and a quick look at "cell_map_single()" in arch/powerpc/platforms/cell
> made it clear why: there's no fancy i/o address mapping.
OK, thanks for the explanation. Actually, the current cell DMA mapping
implementation uses a simple 'linear' mapping, in that, all of RAM is
mapped into the bus DMA address space at once, and in fact, it is all
just done at system startup.
There is ongoing work to implement 'dynamic' mapping, where DMA pages are
mapped into the bus DMA address space on demand. I think a key point to
understand the benefit to this is that the cell processor's I/O controller
maps pages per device, so you can map one DMA page to one device. I
currently have this working for my platform, but have not released that
work. There is some overhead to managing the mapped buffers and to request
pages be mapped by the hypervisor, etc., so I was thinking that is this work
of yours to consolidate the memory buffers prior to requesting the mapping
could be of benefit if it was in an often executed code path.
-Geoff
^ permalink raw reply
* Re: [PATCH 0/21]: powerpc/cell spidernet bugfixes, etc.
From: Arnd Bergmann @ 2006-10-11 16:02 UTC (permalink / raw)
To: Linas Vepstas
Cc: akpm, jeff, netdev, James K Lewis, linux-kernel, linuxppc-dev
In-Reply-To: <20061010204946.GW4381@austin.ibm.com>
On Tuesday 10 October 2006 22:49, Linas Vepstas wrote:
> Andrew, please apply/forward upstream.
>=20
> The following set of 21 patches (!) are all aimed at the the=20
> spidernet ethernet device driver. The spidernet is an etherenet
> controller built into the Toshiba southbridge for the PowerPC Cell
> processor. (This is the only device in existance that with this
> ethernet hardware in it).
>=20
> These patches re-package/re-order/re-cleanup a previous
> set of patches I've previously mailed. Thus, some have
> been previously Acked-by lines, most do not. Most of
> these patches are tiny, and handle problems that cropped
> up during testing. Sorry about there being so many of them.
>=20
> The first set of 12 patches fix a large variety of mostly=20
> minor bugs.=20
>=20
> The important patches are 13 through 17: these overcome a=20
> debilitating performance problem on transmit (6 megabits
> per second !!) on transmit of patches 500 bytes or larger.
> After applying these, I am able to get the following:
>=20
> pkt sz =A0 speed (100K buffs) =A0 =A0 =A0 speed (4M buffs)
> ------ =A0 ----------------- =A0 =A0 =A0 =A0----------------
> 1500 =A0 =A0 700 Mbits/sec =A0 =A0 =A0 =A0 =A0 =A0951 Mbits/sec
> 1000 =A0 =A0 658 Mbits/sec =A0 =A0 =A0 =A0 =A0 =A0770
> 800 =A0 =A0 =A0600 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0648
> 500 =A0 =A0 =A0500 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0500
> 300 =A0 =A0 =A0372 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0372
> 60 =A0 =A0 =A0 =A070 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 70
>=20
> Above buf size refers to /proc/sys/net/core/wmem_default
Excellent work! I guess this the best tx performance we've
seen so far on this hardware.
Consider this as an Acked-by: for all the patches, I'll save
the effort of replying to each one of them separately.
Jeff, do you plan on merging these fixes for 2.6.19?
Arnd <><
^ permalink raw reply
* plb_temac, ML403, linux 2.4.26, EDK 7.1
From: robert corley @ 2006-10-11 16:14 UTC (permalink / raw)
To: linuxppc-embedded
Some background:=0A ML403 devel board=0A EDK 7.1=0A compilation of=
reference design xapp902, modified to use linux and without loopback=0A =
use of linux_2_4_devel obtained from montavista via rsync=0A=0AI am trying=
to use the plb_temac rather than the ll_temac. In the long run, I'd prefe=
r to stick with linux 2.4. In addition, I will need to get both embedded E=
MAC's up and running, but first I just wanna get the xapp902 working. Also=
, I will need gigE support.=0A=0ASo, right now I am trying to get the plb_t=
emac to compile and get errors about the defines XPAR_XTEMAC_* within the l=
inux directories ../drivers/net/xilinx_enet. I see that the edk gets the d=
efines within the xparameters.h file of the xapp902 project. I also see th=
at my C:\EDK\sw\ThirdParty\bsp\linux_mvl31_v1_01_a\drivers don't have anyth=
ing for a plb_temac.=0A=0AQ: Is my error related to an incorrect setup o=
f the linux or with the EDK?=0A=0AQ: t is stated that the plb_temac driv=
ers are in EDK 8.1. Can I stick=0Awith 7.1 or must I ugprade?=0A=0AQ: W=
here in the linux tree should I look for the xtemac=0Astuff? Is this what =
the EDK pushes on to the tree or is it released=0Awithin the MVL distro?=0A=
=0AQ Based on posts by David and Ming, it=0Aappears that I must use xili=
nx_gige to get up to gigE speeds. Will the=0Aplb_temac support this data r=
ate and, if so, is this a transparent=0Asupport or do I need to go the rout=
e suggested to Ming and=0Aoverwrite files in xilinx_enet?=0A=0AR. Corley=0A=
=0A=0A=0A=0A
^ permalink raw reply
* PPChameleonEVB Newbie question
From: Adrian @ 2006-10-11 15:24 UTC (permalink / raw)
To: linuxppc-embedded
Hi Folks.
I'm a newbie to embedded and am getting stuck.
I have a PPChameleonEVB board running a 405EP processor.
I have tried many things, and can now boot Linux 2.6.15 on the board using
an NFS share as both root fs and swap.
When I try to compile & install the kernel modules on the board, i get an
message about perl and then it errors.
So i'm trying to install perl. And failing.
Can someone tell me the following please, from a working setup (i.e. where
you can compile/install kernel 2.6.15 + modules) :-
1) Kernel version/Linux distroof the i386 PC used for the cross-compiling.
2) ELDK version and if there are any patches needed.
2) Perl version (or how to stop the Kernel build using perl)
I'm using Slack 8.1, kernel 2.4.18 and perl 5.6.1 on the cross-compiler pc.
Anything newer fell apart a lot earlier.
Many thanks in advance.
Adrian Atkins
IT Live Limited
tel: 0161 408 3327
fax: 08702 360 443
skype: adrianitlive
ES mob: (0034) 606806236
^ permalink raw reply
* Re: [PATCH 0/21]: powerpc/cell spidernet bugfixes, etc.
From: James K Lewis @ 2006-10-11 16:42 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: akpm, jeff, netdev, linux-kernel, linuxppc-dev
In-Reply-To: <200610111802.43996.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]
Please don't be confused by the numbers in the 4M column, they don't
mean anything to the end user. We had a bit better performance (approx.
720 Mbps) at one time but at 100% CPU usage. These new patches lower the
max. to about 700 Mbps but decrease CPU usage down to about 30% which I
think will help all around. I have been testing this driver all night and
have not found a problem yet. Consider this my Acked-by: for all these
patches.
Jim Lewis
Advisory Software Engineer
IBM Linux Technology Center
512-838-7754
Arnd Bergmann <arnd@arndb.de>
10/11/2006 11:02 AM
To
Linas Vepstas <linas@austin.ibm.com>
cc
akpm@osdl.org, jeff@garzik.org, James K Lewis/Austin/IBM@ibmus,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org
Subject
Re: [PATCH 0/21]: powerpc/cell spidernet bugfixes, etc.
On Tuesday 10 October 2006 22:49, Linas Vepstas wrote:
> Andrew, please apply/forward upstream.
>
> The following set of 21 patches (!) are all aimed at the the
> spidernet ethernet device driver. The spidernet is an etherenet
> controller built into the Toshiba southbridge for the PowerPC Cell
> processor. (This is the only device in existance that with this
> ethernet hardware in it).
>
> These patches re-package/re-order/re-cleanup a previous
> set of patches I've previously mailed. Thus, some have
> been previously Acked-by lines, most do not. Most of
> these patches are tiny, and handle problems that cropped
> up during testing. Sorry about there being so many of them.
>
> The first set of 12 patches fix a large variety of mostly
> minor bugs.
>
> The important patches are 13 through 17: these overcome a
> debilitating performance problem on transmit (6 megabits
> per second !!) on transmit of patches 500 bytes or larger.
> After applying these, I am able to get the following:
>
> pkt sz speed (100K buffs) speed (4M buffs)
> ------ ----------------- ----------------
> 1500 700 Mbits/sec 951 Mbits/sec
> 1000 658 Mbits/sec 770
> 800 600 648
> 500 500 500
> 300 372 372
> 60 70 70
>
> Above buf size refers to /proc/sys/net/core/wmem_default
Excellent work! I guess this the best tx performance we've
seen so far on this hardware.
Consider this as an Acked-by: for all the patches, I'll save
the effort of replying to each one of them separately.
Jeff, do you plan on merging these fixes for 2.6.19?
Arnd <><
[-- Attachment #2: Type: text/html, Size: 4073 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: make MAL use the new DCR methods
From: Eugene Surovegin @ 2006-10-11 17:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1160545539.6177.56.camel@localhost.localdomain>
On Wed, Oct 11, 2006 at 03:45:39PM +1000, Benjamin Herrenschmidt wrote:
> This is a test patch to validate the new DCR method code for the
> "native" case. It will ultimately be the first of a pile porting the
> EMAC driver to ARCH=powerpc and non-native DCRs.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Index: linux-cell/drivers/net/ibm_emac/ibm_emac_mal.h
> ===================================================================
> --- linux-cell.orig/drivers/net/ibm_emac/ibm_emac_mal.h 2006-10-11 13:01:59.000000000 +1000
> +++ linux-cell/drivers/net/ibm_emac/ibm_emac_mal.h 2006-10-11 14:35:28.000000000 +1000
> @@ -24,6 +24,7 @@
> #include <linux/netdevice.h>
>
> #include <asm/io.h>
> +#include <asm/dcr.h>
>
> /*
> * These MAL "versions" probably aren't the real versions IBM uses for these
> @@ -191,6 +192,7 @@ struct mal_commac {
>
> struct ibm_ocp_mal {
> int dcrbase;
> + dcr_host_t dcrhost;
>
> struct list_head poll_list;
> struct net_device poll_dev;
> @@ -207,12 +209,12 @@ struct ibm_ocp_mal {
>
> static inline u32 get_mal_dcrn(struct ibm_ocp_mal *mal, int reg)
> {
> - return mfdcr(mal->dcrbase + reg);
> + return dcr_read(mal->dcrhost, mal->dcrbase + reg);
> }
>
> static inline void set_mal_dcrn(struct ibm_ocp_mal *mal, int reg, u32 val)
> {
> - mtdcr(mal->dcrbase + reg, val);
> + dcr_write(mal->dcrhost, mal->dcrbase + reg, val);
> }
>
> /* Register MAL devices */
>
>
Looks fine to me.
Acked-by: Eugene Surovegin <ebs@ebshome.net>
^ permalink raw reply
* RE: plb_temac, ML403, linux 2.4.26, EDK 7.1
From: Ming Liu @ 2006-10-11 20:24 UTC (permalink / raw)
To: rdcorle, linuxppc-embedded
In-Reply-To: <20061011161451.3292.qmail@web56312.mail.re3.yahoo.com>
Hi,
>So, right now I am trying to get the plb_temac to compile and get errors
about the defines XPAR_XTEMAC_* within the linux directories
../drivers/net/xilinx_enet. I see that the edk gets the defines within the
xparameters.h file of the xapp902 project. I also see that my
C:\EDK\sw\ThirdParty\bsp\linux_mvl31_v1_01_a\drivers don't have anything
for a plb_temac.
Yes. In MV3.1, there is no gige enet supported. You should include the
patch for TEMAC by yourself.
>Q: Is my error related to an incorrect setup of the linux or with the
EDK?
Try to check your xparameters.h file and find if there are the definations.
>Q: t is stated that the plb_temac drivers are in EDK 8.1. Can I stick
>with 7.1 or must I ugprade?
I don't think that's the problem of 7.1, if you can make sure you use a
correct core for TEMAC and generated correct BSP files.
>Q: Where in the linux tree should I look for the xtemac
>stuff? Is this what the EDK pushes on to the tree or is it released
>within the MVL distro?
Try to find the patch for TEMAC in this list.
>Q Based on posts by David and Ming, it
>appears that I must use xilinx_gige to get up to gigE speeds. Will the
>plb_temac support this data rate and, if so, is this a transparent
>support or do I need to go the route suggested to Ming and
>overwrite files in xilinx_enet?
Temac is tri-mode including 1000M/s speed. sorry that i cannot understand
this question very well.
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* RE: plb_temac, ML403, linux 2.4.26, EDK 7.1
From: robert corley @ 2006-10-11 20:46 UTC (permalink / raw)
To: linuxppc-embedded
Ming;=0A=0AHere is what the EDK generates in this file:=0A=0AC:\EDK\project=
s\startup_network\ppc405_0\libsrc\linux_mvl31_v1_01_a\linux\arch\ppc\platfo=
rms\xilinx_ocp\xparameters_ml300.h=0A=0A<snip>=0A#define XPAR_XTEMAC_NUM_IN=
STANCES 1=0A#define XPAR_PLB_TEMAC_0_BASEADDR 0x60000000=0A#define XPAR_PLB=
_TEMAC_0_HIGHADDR 0x60003FFF=0A#define XPAR_PLB_TEMAC_0_DEVICE_ID 0=0A#defi=
ne XPAR_PLB_TEMAC_0_IPIF_RDFIFO_DEPTH 131072=0A#define XPAR_PLB_TEMAC_0_IPI=
F_WRFIFO_DEPTH 131072=0A#define XPAR_PLB_TEMAC_0_MAC_FIFO_DEPTH 64=0A#defin=
e XPAR_PLB_TEMAC_0_DMA_TYPE 3=0A#define XPAR_PLB_TEMAC_0_TEMAC_DCR_HOST 0=
=0A#define XPAR_PLB_TEMAC_0_INCLUDE_DRE 1=0A<snip>=0A=0A=0AWhich is fine. =
However, the file in the linux distribution: linux_2_4_devel/drivers/net/xi=
linx_enet/adapter.c is looking for "XEMAC" instead of "XTEMAC" as above.=0A=
=0AAlso, when I look at the EDK project directory =0A=0A"C:\EDK\projects\st=
artup_network\ppc405_0\libsrc\linux_mvl31_v1_01_a\linux\drivers\net\"=0A=0A=
I see that it is empty. Which means that nothing in the MVL tree will be o=
verwritten (specifically the adapter.c file, which uses the above defines).=
=0A=0ASo, it appears that the driver is not being properly insterted into t=
he tree as expected. Would you agree?=0A=0A-R=0A=0A
^ permalink raw reply
* Re: [PATCH 0/21]: powerpc/cell spidernet bugfixes, etc.
From: James K Lewis @ 2006-10-11 21:06 UTC (permalink / raw)
To: Arnd Bergmann, jim; +Cc: akpm, jeff, netdev, linux-kernel, linuxppc-dev
In-Reply-To: <200610111802.43996.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 2176 bytes --]
Jeff,
Please apply and forward these Spidernet patches. Thanks!
Jim Lewis
Advisory Software Engineer
IBM Linux Technology Center
512-838-7754
Arnd Bergmann <arnd@arndb.de>
10/11/2006 11:02 AM
To
Linas Vepstas <linas@austin.ibm.com>
cc
akpm@osdl.org, jeff@garzik.org, James K Lewis/Austin/IBM@ibmus,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org
Subject
Re: [PATCH 0/21]: powerpc/cell spidernet bugfixes, etc.
On Tuesday 10 October 2006 22:49, Linas Vepstas wrote:
> Andrew, please apply/forward upstream.
>
> The following set of 21 patches (!) are all aimed at the the
> spidernet ethernet device driver. The spidernet is an etherenet
> controller built into the Toshiba southbridge for the PowerPC Cell
> processor. (This is the only device in existance that with this
> ethernet hardware in it).
>
> These patches re-package/re-order/re-cleanup a previous
> set of patches I've previously mailed. Thus, some have
> been previously Acked-by lines, most do not. Most of
> these patches are tiny, and handle problems that cropped
> up during testing. Sorry about there being so many of them.
>
> The first set of 12 patches fix a large variety of mostly
> minor bugs.
>
> The important patches are 13 through 17: these overcome a
> debilitating performance problem on transmit (6 megabits
> per second !!) on transmit of patches 500 bytes or larger.
> After applying these, I am able to get the following:
>
> pkt sz speed (100K buffs) speed (4M buffs)
> ------ ----------------- ----------------
> 1500 700 Mbits/sec 951 Mbits/sec
> 1000 658 Mbits/sec 770
> 800 600 648
> 500 500 500
> 300 372 372
> 60 70 70
>
> Above buf size refers to /proc/sys/net/core/wmem_default
Excellent work! I guess this the best tx performance we've
seen so far on this hardware.
Consider this as an Acked-by: for all the patches, I'll save
the effort of replying to each one of them separately.
Jeff, do you plan on merging these fixes for 2.6.19?
Arnd <><
[-- Attachment #2: Type: text/html, Size: 3738 bytes --]
^ permalink raw reply
* Re: [PATCH] Xilinx UART Lite 2.6.18 driver
From: David H. Lynch Jr. @ 2006-10-11 22:06 UTC (permalink / raw)
To: David Bolcsfoldi; +Cc: linuxppc-embedded
In-Reply-To: <609d5c8e0610101349w64cdd4ecjc5359ad8d1f5d635@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 30623 bytes --]
also:
your driver is strictly interrupt driven.
I need polled for the Pico E12 - which my driver an early
version was posted in January, supports.
Somebody else needs DCR support.
David Bolcsfoldi wrote:
> Hi,
>
> here's a set of patches that adds support for Xilinx UART lite
> devices. It has been tested on an ML403-FX using xapp902
> (ml403_ppc_plb_temac) using a 2.6.18 kernel and a BusyBox userspace.
>
> This is my first patch for the Linux kernel, so please be gentle :-)
>
> David
> ------------------------------------------------------------------------
>
> diff -urN 2.6.18/arch/ppc/boot/simple/Makefile patched/arch/ppc/boot/simple/Makefile
> --- 2.6.18/arch/ppc/boot/simple/Makefile 2006-10-04 14:31:15.000000000 -0700
> +++ patched/arch/ppc/boot/simple/Makefile 2006-10-07 10:34:32.000000000 -0700
> @@ -205,6 +205,7 @@
> endif
> boot-$(CONFIG_SERIAL_MPC52xx_CONSOLE) += mpc52xx_tty.o
> boot-$(CONFIG_SERIAL_MPSC_CONSOLE) += mv64x60_tty.o
> +boot-$(CONFIG_SERIAL_XUL_CONSOLE) += xuartlite_tty.o
>
> LIBS := $(common)/lib.a $(bootlib)/lib.a
> ifeq ($(CONFIG_PPC_PREP),y)
> diff -urN 2.6.18/arch/ppc/boot/simple/misc.c patched/arch/ppc/boot/simple/misc.c
> --- 2.6.18/arch/ppc/boot/simple/misc.c 2006-10-04 14:31:15.000000000 -0700
> +++ patched/arch/ppc/boot/simple/misc.c 2006-10-07 10:27:34.000000000 -0700
> @@ -48,7 +48,8 @@
> #if (defined(CONFIG_SERIAL_8250_CONSOLE) \
> || defined(CONFIG_VGA_CONSOLE) \
> || defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
> - || defined(CONFIG_SERIAL_MPSC_CONSOLE)) \
> + || defined(CONFIG_SERIAL_MPSC_CONSOLE) \
> + || defined(CONFIG_SERIAL_XUL_CONSOLE)) \
> && !defined(CONFIG_GEMINI)
> #define INTERACTIVE_CONSOLE 1
> #endif
> diff -urN 2.6.18/arch/ppc/boot/simple/xuartlite_tty.c patched/arch/ppc/boot/simple/xuartlite_tty.c
> --- 2.6.18/arch/ppc/boot/simple/xuartlite_tty.c 1969-12-31 16:00:00.000000000 -0800
> +++ patched/arch/ppc/boot/simple/xuartlite_tty.c 2006-10-07 10:29:30.000000000 -0700
> @@ -0,0 +1,74 @@
> +/*
> + * Xilinx UART Lite support.
> + * Right now it only works over UART0 and none other.
> + *
> + * Copyright (C) 2006 David Bolcsfoldi <dbolcsfoldi@gmail.com>
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include <asm/io.h>
> +#include <platforms/4xx/xparameters/xparameters.h>
> +
> +#define XUL_STATUS_REG_OFFSET 8 /* status register, read only */
> +#define XUL_SR_TX_FIFO_FULL 0x08 /* transmit FIFO full */
> +#define XUL_SR_RX_FIFO_VALID_DATA 0x01 /* data in receive FIFO */
> +#define XUL_RX_FIFO_OFFSET 0 /* receive FIFO, read only */
> +#define XUL_TX_FIFO_OFFSET 4 /* transmit FIFO, write only */
> +
> +static inline int is_xmit_full(unsigned int address)
> +{
> + return ((in_be32((volatile unsigned *) (address + XUL_STATUS_REG_OFFSET)) & XUL_SR_TX_FIFO_FULL) == XUL_SR_TX_FIFO_FULL);
> +}
> +
> +static inline int is_recv_empty(unsigned int address)
> +{
> + return ((in_be32((volatile unsigned *) (address + XUL_STATUS_REG_OFFSET)) & XUL_SR_RX_FIFO_VALID_DATA) != XUL_SR_RX_FIFO_VALID_DATA);
> +}
> +
> +unsigned long serial_init(int chan, void *ignored)
> +{
> + switch (chan) {
> + #ifdef XPAR_XUL_UART_0_BASEADDR
> + case 0:
> + return XPAR_XUL_UART_0_BASEADDR;
> + #endif
> + #ifdef XPAR_XUL_UART_1_BASEADDR
> + case 1:
> + return XPAR_XUL_UART_1_BASEADDR;
> + #endif
> + #ifdef XPAR_XUL_UART_2_BASEADDR
> + case 2:
> + return XPAR_XUL_UART_2_BASEADDR;
> + #endif
> + #ifdef XPAR_XUL_UART_3_BASEADDR
> + case 3:
> + return XPAR_XUL_UART_3_BASEADDR;
> + #endif
> + default:
> + goto out;
> + }
> +
> +out:
> + return -1;
> +}
> +
> +void serial_putc(unsigned long com_port, unsigned char c)
> +{
> + while(is_xmit_full(XPAR_XUL_UART_0_BASEADDR));
> + out_be32((volatile unsigned *) (XPAR_XUL_UART_0_BASEADDR + XUL_TX_FIFO_OFFSET), c);
> +}
> +
> +unsigned char serial_getc(unsigned long com_port)
> +{
> + while(is_recv_empty(XPAR_XUL_UART_0_BASEADDR));
> + return in_be32((volatile unsigned *) (XPAR_XUL_UART_0_BASEADDR + XUL_RX_FIFO_OFFSET));
> +}
> +
> +int serial_tstc(unsigned long com_port)
> +{
> + return !(is_recv_empty(XPAR_XUL_UART_0_BASEADDR));
> +}
> +
>
> ------------------------------------------------------------------------
>
> diff -urN 2.6.18/arch/ppc/boot/common/misc-common.c patched/arch/ppc/boot/common/misc-common.c
> --- 2.6.18/arch/ppc/boot/common/misc-common.c 2006-10-04 14:31:15.000000000 -0700
> +++ patched/arch/ppc/boot/common/misc-common.c 2006-10-07 10:33:28.000000000 -0700
> @@ -57,7 +57,8 @@
>
> #if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \
> || defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
> - || defined(CONFIG_SERIAL_MPSC_CONSOLE)
> + || defined(CONFIG_SERIAL_MPSC_CONSOLE) \
> + || defined(CONFIG_SERIAL_XUL_CONSOLE)
> extern unsigned long com_port;
>
> extern int serial_tstc(unsigned long com_port);
> @@ -80,7 +81,8 @@
> {
> #if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \
> || defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
> - || defined(CONFIG_SERIAL_MPSC_CONSOLE)
> + || defined(CONFIG_SERIAL_MPSC_CONSOLE) \
> + || defined(CONFIG_SERIAL_XUL_CONSOLE)
> if(keyb_present)
> return (CRT_tstc() || serial_tstc(com_port));
> else
> @@ -95,7 +97,8 @@
> while (1) {
> #if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \
> || defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
> - || defined(CONFIG_SERIAL_MPSC_CONSOLE)
> + || defined(CONFIG_SERIAL_MPSC_CONSOLE) \
> + || defined(CONFIG_SERIAL_XUL_CONSOLE)
> if (serial_tstc(com_port))
> return (serial_getc(com_port));
> #endif /* serial console */
> @@ -112,7 +115,8 @@
>
> #if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \
> || defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
> - || defined(CONFIG_SERIAL_MPSC_CONSOLE)
> + || defined(CONFIG_SERIAL_MPSC_CONSOLE) \
> + || defined(CONFIG_SERIAL_XUL_CONSOLE)
> serial_putc(com_port, c);
> if ( c == '\n' )
> serial_putc(com_port, '\r');
> @@ -161,7 +165,8 @@
> while ( ( c = *s++ ) != '\0' ) {
> #if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \
> || defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
> - || defined(CONFIG_SERIAL_MPSC_CONSOLE)
> + || defined(CONFIG_SERIAL_MPSC_CONSOLE) \
> + || defined(CONFIG_SERIAL_XUL_CONSOLE)
> serial_putc(com_port, c);
> if ( c == '\n' ) serial_putc(com_port, '\r');
> #endif /* serial console */
>
> ------------------------------------------------------------------------
>
> --- 2.6.18/arch/ppc/platforms/4xx/virtex.c 2006-10-04 14:31:15.000000000 -0700
> +++ patched/arch/ppc/platforms/4xx/virtex.c 2006-10-07 11:21:18.000000000 -0700
> @@ -52,5 +52,10 @@
> .id = 0,
> .dev.platform_data = serial_platform_data,
> },
> +
> + [VIRTEX_XUL_UART] = {
> + .name = "xul_uart",
> + .id = 0,
> + },
> };
>
>
> ------------------------------------------------------------------------
>
> --- 2.6.18/arch/ppc/platforms/4xx/virtex.h 2006-10-04 14:31:15.000000000 -0700
> +++ patched/arch/ppc/platforms/4xx/virtex.h 2006-10-07 10:35:31.000000000 -0700
> @@ -27,7 +27,9 @@
> /* Device type enumeration for platform bus definitions */
> #ifndef __ASSEMBLY__
> enum ppc_sys_devices {
> - VIRTEX_UART, NUM_PPC_SYS_DEVS,
> + VIRTEX_UART,
> + VIRTEX_XUL_UART,
> + NUM_PPC_SYS_DEVS,
> };
> #endif
>
>
> ------------------------------------------------------------------------
>
> diff -urN 2.6.18/drivers/serial/Kconfig patched/drivers/serial/Kconfig
> --- 2.6.18/drivers/serial/Kconfig 2006-10-04 14:31:18.000000000 -0700
> +++ patched/drivers/serial/Kconfig 2006-10-07 10:50:20.000000000 -0700
> @@ -959,4 +959,22 @@
> If you have enabled the serial port on the Motorola IMX
> CPU you can make it the console by answering Y to this option.
>
> +config SERIAL_XUL
> + tristate "Xilinx UART Lite serial support"
> + depends on XILINX_ML403
> + select SERIAL_CORE
> + help
> + This driver supports the Xilinx UART Lite serial ports. If you would
> + like to use them, you must answer Y or M to this option. Note that
> + for use as console, it must be included in the kernel and not as a
> + module.
> +
> +config SERIAL_XUL_CONSOLE
> + bool "Console on a Xilinx UART Lite serial port"
> + depends on SERIAL_XUL
> + select SERIAL_CORE_CONSOLE
> + help
> + Select this option if you'd like to use the UART Lite serial port
> + of the Xilinx ML403 board as a console.
> +
> endmenu
> diff -urN 2.6.18/drivers/serial/Makefile patched/drivers/serial/Makefile
> --- 2.6.18/drivers/serial/Makefile 2006-10-04 14:31:18.000000000 -0700
> +++ patched/drivers/serial/Makefile 2006-10-07 10:51:02.000000000 -0700
> @@ -56,3 +56,4 @@
> obj-$(CONFIG_SERIAL_SGI_IOC3) += ioc3_serial.o
> obj-$(CONFIG_SERIAL_AT91) += at91_serial.o
> obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
> +obj-$(CONFIG_SERIAL_XUL) += xuartlite.o
> diff -urN 2.6.18/drivers/serial/xuartlite.c patched/drivers/serial/xuartlite.c
> --- 2.6.18/drivers/serial/xuartlite.c 1969-12-31 16:00:00.000000000 -0800
> +++ patched/drivers/serial/xuartlite.c 2006-10-10 11:08:08.000000000 -0700
> @@ -0,0 +1,723 @@
> +/*
> + * drivers/serial/xuartlite.c
> + *
> + * Driver for Xilinx UART Lite device.
> + *
> + * This driver has only been tested with the Xilinx ML403-FX board using the plb_temac
> + * reference design with on UART port.
> + *
> + * This driver is loosely based off the mpc52xx_uart driver.
> + *
> + * Copyright (C) 2006 David Bolcsfoldi <dbolcsfoldi@gmail.com>
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include <linux/config.h>
> +#include <linux/platform_device.h>
> +#include <linux/module.h>
> +#include <linux/tty.h>
> +#include <linux/serial.h>
> +#include <linux/sysrq.h>
> +#include <linux/console.h>
> +
> +#include <asm/delay.h>
> +#include <asm/io.h>
> +#include <platforms/4xx/xparameters/xparameters.h>
> +
> +#if defined(CONFIG_SERIAL_XUL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
> +#define SUPPORT_SYSRQ
> +#endif
> +
> +#include <linux/serial_core.h>
> +
> +#define SERIAL_XUL_MAJOR 204
> +#define SERIAL_XUL_MINOR 187
> +
> +/*
> + * Keeps various tidbits about the serial port taken
> + * from xparameters.h
> + * */
> +
> +struct xul_uart_data {
> + int baud;
> + int parity;
> + int bits;
> + int flow;
> + int uartclk;
> + int irq;
> + int mapbase;
> + int size;
> +};
> +
> +static struct xul_uart_data xul_data[XPAR_XUARTLITE_NUM_INSTANCES] = {
> + {
> + .baud = XPAR_XUL_UART_0_BAUDRATE,
> +#if (XPAR_XUL_UART_0_USE_PARITY != 0)
> + .parity = 'y',
> +#else
> + .parity = 'n',
> +#endif /* XPAR_XUL_UART_0_USE_PARITY */
> + .bits = XPAR_XUL_UART_0_DATA_BITS,
> + .flow = 'n',
> + .uartclk = 100000000 / 16, /* PLB speed / 16 */
> + .irq = XPAR_INTC_0_XUL_UART_0_VEC_ID,
> + .mapbase = XPAR_XUL_UART_0_BASEADDR,
> + .size = (XPAR_XUL_UART_0_HIGHADDR - XPAR_XUL_UART_0_BASEADDR) + 1
> + }
> +
> + /* Add next uart here */
> +};
> +
> +static const long ISR_PASS_LIMIT = 255;
> +static struct uart_port xul_uart_ports[XPAR_XUARTLITE_NUM_INSTANCES];
> +
> +#define XUL(port) ((unsigned int)((port)->membase))
> +
> +#define XUL_RX_FIFO_OFFSET 0 /* receive FIFO, read only */
> +#define XUL_TX_FIFO_OFFSET 4 /* transmit FIFO, write only */
> +#define XUL_STATUS_REG_OFFSET 8 /* status register, read only */
> +#define XUL_CONTROL_REG_OFFSET 12 /* control register, write only */
> +
> +#define XUL_CR_ENABLE_INTR 0x10 /* enable interrupt */
> +#define XUL_CR_FIFO_RX_RESET 0x02 /* reset receive FIFO */
> +#define XUL_CR_FIFO_TX_RESET 0x01 /* reset transmit FIFO */
> +
> +#define XUL_SR_PARITY_ERROR 0x80
> +#define XUL_SR_FRAMING_ERROR 0x40
> +#define XUL_SR_OVERRUN_ERROR 0x20
> +#define XUL_SR_TX_FIFO_FULL 0x08 /* transmit FIFO full */
> +#define XUL_SR_TX_FIFO_EMPTY 0x04 /* transmit FIFO empty */
> +#define XUL_SR_RX_FIFO_VALID_DATA 0x01 /* data in receive FIFO */
> +
> +/* Forward declaration of the interruption handling routine */
> +static irqreturn_t xul_uart_int(int irq,void *dev_id,struct pt_regs *regs);
> +
> +/* Simple macro to test if a port is console or not. This one is taken
> + * for serial_core.c and maybe should be moved to serial_core.h ? */
> +#ifdef CONFIG_SERIAL_CORE_CONSOLE
> +#define uart_console(port) ((port)->cons && (port)->cons->index == (port)->line)
> +#else
> +#define uart_console(port) (0)
> +#endif
> +
> +/* ======================================================================== */
> +/* UART operations */
> +/* ======================================================================== */
> +
> +static int
> +xul_uart_int_tx_chars(struct uart_port *port);
> +
> +static inline int is_xmit_empty(struct uart_port *port)
> +{
> + return ((in_be32((volatile unsigned *) (XUL(port) + XUL_STATUS_REG_OFFSET)) & XUL_SR_TX_FIFO_EMPTY) == XUL_SR_TX_FIFO_EMPTY);
> +}
> +
> +static inline int is_recv_empty(struct uart_port *port)
> +{
> + return ((in_be32((volatile unsigned *) (XUL(port) + XUL_STATUS_REG_OFFSET)) & XUL_SR_RX_FIFO_VALID_DATA) != XUL_SR_RX_FIFO_VALID_DATA);
> +}
> +
> +static inline int is_xmit_full(struct uart_port *port)
> +{
> + return ((in_be32((volatile unsigned *) (XUL(port) + XUL_STATUS_REG_OFFSET)) & XUL_SR_TX_FIFO_FULL) == XUL_SR_TX_FIFO_FULL);
> +}
> +
> +static inline void xmit_char(struct uart_port *port, char c)
> +{
> + while(is_xmit_full(port));
> + out_be32((volatile unsigned *) (XUL(port) + XUL_TX_FIFO_OFFSET), c);
> +}
> +
> +static inline char recv_char(struct uart_port *port)
> +{
> + while(is_recv_empty(port));
> + return in_be32((volatile unsigned *) (XUL(port) + XUL_RX_FIFO_OFFSET));
> +}
> +
> +static unsigned int
> +xul_uart_tx_empty(struct uart_port *port)
> +{
> + return ((is_xmit_empty(port)) ? TIOCSER_TEMT : 0);
> +}
> +
> +static void
> +xul_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
> +{
> + /* Not implemented */
> +}
> +
> +static unsigned int
> +xul_uart_get_mctrl(struct uart_port *port)
> +{
> + return TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
> +}
> +
> +static void
> +xul_uart_stop_tx(struct uart_port *port)
> +{
> + /* port->lock taken by caller */
> +}
> +
> +static void
> +xul_uart_start_tx(struct uart_port *port)
> +{
> + /* port->lock taken by caller */
> + xul_uart_int_tx_chars(port);
> +}
> +
> +static void
> +xul_uart_send_xchar(struct uart_port *port, char ch)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&port->lock, flags);
> +
> + port->x_char = ch;
> +
> + if (ch) {
> + xmit_char(port, ch);
> + }
> +
> + spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +static void
> +xul_uart_stop_rx(struct uart_port *port)
> +{
> + /* port->lock taken by caller */
> +}
> +
> +static void
> +xul_uart_enable_ms(struct uart_port *port)
> +{
> + /* Not implemented */
> +}
> +
> +static void
> +xul_uart_break_ctl(struct uart_port *port, int ctl)
> +{
> + /* Not implemented */
> +}
> +
> +static int
> +xul_uart_startup(struct uart_port *port)
> +{
> + int ret;
> +
> + /* Request IRQ */
> + ret = request_irq(port->irq, xul_uart_int,
> + SA_INTERRUPT | SA_SAMPLE_RANDOM, "xul_uart", port);
> + if (ret)
> + return ret;
> +
> + /* Reset/activate the port, clear and enable interrupts */
> + out_be32((volatile unsigned *) (XUL(port) + XUL_CONTROL_REG_OFFSET), XUL_CR_FIFO_TX_RESET); /* Reset TX */
> + out_be32((volatile unsigned *) (XUL(port) + XUL_CONTROL_REG_OFFSET), XUL_CR_FIFO_RX_RESET); /* Reset RX */
> + out_be32((volatile unsigned *) (XUL(port) + XUL_CONTROL_REG_OFFSET), XUL_CR_ENABLE_INTR); /* Enable interrupt */
> +
> + return 0;
> +}
> +
> +static void
> +xul_uart_shutdown(struct uart_port *port)
> +{
> + /* Shut down the port, interrupt and all */
> +
> + /* Disable interrupt bu clearing control register */
> + out_be32((volatile unsigned *) (XUL(port) + XUL_CONTROL_REG_OFFSET), 0);
> +
> + out_be32((volatile unsigned *) (XUL(port) + XUL_CONTROL_REG_OFFSET), XUL_CR_FIFO_TX_RESET); /* Reset TX */
> + out_be32((volatile unsigned *) (XUL(port) + XUL_CONTROL_REG_OFFSET), XUL_CR_FIFO_RX_RESET); /* Reset RX */
> +
> + /* Release interrupt */
> + free_irq(port->irq, port);
> +}
> +
> +static void
> +xul_uart_set_termios(struct uart_port *port, struct termios *new,
> + struct termios *old)
> +{
> + /* Nothing can be set, fixed at IP block generation */
> +}
> +
> +static const char *
> +xul_uart_type(struct uart_port *port)
> +{
> + return port->type == PORT_XUL ? "ttyXUL" : NULL;
> +}
> +
> +static void
> +xul_uart_release_port(struct uart_port *port)
> +{
> + if (port->flags & UPF_IOREMAP) {
> + iounmap(port->membase);
> + port->membase = NULL;
> + }
> +
> + release_mem_region(port->mapbase, xul_data[port->line].size);
> +}
> +
> +static int
> +xul_uart_request_port(struct uart_port *port)
> +{
> + int mem_region;
> +
> + if (port->flags & UPF_IOREMAP) {
> + port->membase = ioremap(port->mapbase, xul_data[port->line].size);
> + }
> +
> + if (!port->membase) {
> + return -EINVAL;
> + }
> +
> + mem_region = request_mem_region(port->mapbase, xul_data[port->line].size, "xul_uart") != NULL ? 0 : -EBUSY;
> + return 0;
> +}
> +
> +static void
> +xul_uart_config_port(struct uart_port *port, int flags)
> +{
> + if ( (flags & UART_CONFIG_TYPE) &&
> + (xul_uart_request_port(port) == 0) )
> + port->type = PORT_XUL;
> +}
> +
> +static int
> +xul_uart_verify_port(struct uart_port *port, struct serial_struct *ser)
> +{
> + if ( ser->type != PORT_UNKNOWN && ser->type != PORT_XUL ) {
> + printk(KERN_WARNING "xul_uart_verify_port(1)\n");
> + return -EINVAL;
> + }
> +
> + if ( (ser->irq != port->irq) ||
> + (ser->io_type != SERIAL_IO_MEM) ||
> + (ser->baud_base != port->uartclk) ||
> + (ser->iomem_base != (void*)port->mapbase) ||
> + (ser->hub6 != 0 ) ) {
> + printk(KERN_WARNING "xul_uart_verify_port(1)\n");
> + }
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +
> +static struct uart_ops xul_uart_ops = {
> + .tx_empty = xul_uart_tx_empty,
> + .set_mctrl = xul_uart_set_mctrl,
> + .get_mctrl = xul_uart_get_mctrl,
> + .stop_tx = xul_uart_stop_tx,
> + .start_tx = xul_uart_start_tx,
> + .send_xchar = xul_uart_send_xchar,
> + .stop_rx = xul_uart_stop_rx,
> + .enable_ms = xul_uart_enable_ms,
> + .break_ctl = xul_uart_break_ctl,
> + .startup = xul_uart_startup,
> + .shutdown = xul_uart_shutdown,
> + .set_termios = xul_uart_set_termios,
> +/* .pm = xul_uart_pm, Not supported yet */
> +/* .set_wake = xul_uart_set_wake, Not supported yet */
> + .type = xul_uart_type,
> + .release_port = xul_uart_release_port,
> + .request_port = xul_uart_request_port,
> + .config_port = xul_uart_config_port,
> + .verify_port = xul_uart_verify_port
> +};
> +
> +
> +/* ======================================================================== */
> +/* Interrupt handling */
> +/* ======================================================================== */
> +
> +static int
> +xul_uart_int_rx_chars(struct uart_port *port, struct pt_regs *regs)
> +{
> + struct tty_struct *tty = port->info->tty;
> + unsigned char ch, flag;
> + unsigned long status;
> +
> + status = in_be32((volatile unsigned *) (XUL(port) + XUL_STATUS_REG_OFFSET));
> +
> + /* While we can read, do so ! */
> + if ((status & XUL_SR_RX_FIFO_VALID_DATA) == XUL_SR_RX_FIFO_VALID_DATA) {
> +
> + /* Get the char */
> + ch = recv_char(port);
> +
> + /* Handle sysreq char */
> +#ifdef SUPPORT_SYSRQ
> + if (uart_handle_sysrq_char(port, ch, regs)) {
> + port->sysrq = 0;
> + continue;
> + }
> +#endif
> + /* Store it */
> +
> + flag = TTY_NORMAL;
> + port->icount.rx++;
> +
> + if (status & XUL_SR_PARITY_ERROR)
> + flag = TTY_PARITY;
> + else if (status & XUL_SR_FRAMING_ERROR)
> + flag = TTY_FRAME;
> +
> + tty_insert_flip_char(tty, ch, flag);
> +
> + if (status & XUL_SR_OVERRUN_ERROR) {
> + tty_insert_flip_char(tty, 0, TTY_OVERRUN);
> + }
> + }
> +
> + spin_unlock(&port->lock);
> + tty_flip_buffer_push(tty);
> + spin_lock(&port->lock);
> +
> + return 0;
> +}
> +
> +static int
> +xul_uart_int_tx_chars(struct uart_port *port)
> +{
> + struct circ_buf *xmit = &port->info->xmit;
> +
> + /* Process out of band chars */
> + if (port->x_char) {
> + xmit_char(port, port->x_char);
> + port->icount.tx++;
> + port->x_char = 0;
> + return 1;
> + }
> +
> + /* Nothing to do ? */
> + if (uart_circ_empty(xmit) || uart_tx_stopped(port)) {
> + xul_uart_stop_tx(port);
> + return 0;
> + }
> +
> + /* Send chars */
> + while (is_xmit_full(port) == 0) {
> + xmit_char(port, xmit->buf[xmit->tail]);
> + xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
> + port->icount.tx++;
> +
> + if (uart_circ_empty(xmit))
> + break;
> + }
> +
> + /* Wake up */
> + if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
> + uart_write_wakeup(port);
> + }
> +
> + /* Maybe we're done after all */
> + if (uart_circ_empty(xmit)) {
> + xul_uart_stop_tx(port);
> + return 0;
> + }
> +
> + return 1;
> +}
> +
> +static irqreturn_t
> +xul_uart_int(int irq, void *dev_id, struct pt_regs *regs)
> +{
> + struct uart_port *port = (struct uart_port *) dev_id;
> + unsigned long pass = ISR_PASS_LIMIT;
> + unsigned int keepgoing;
> +
> + if ( irq != port->irq ) {
> + printk( KERN_WARNING
> + "xul_uart_int : " \
> + "Received wrong int %d. Waiting for %d\n",
> + irq, port->irq);
> + return IRQ_NONE;
> + }
> +
> + spin_lock(&port->lock);
> +
> + /* While we have stuff to do, we continue */
> + do {
> + /* If we don't find anything to do, we stop */
> + keepgoing = 0;
> +
> + /* Do we need to receive chars ? */
> + if (is_recv_empty(port) == 0) {
> + keepgoing |= xul_uart_int_rx_chars(port, regs);
> + }
> +
> + /* Do we need to send chars ? */
> + if (is_xmit_empty(port)) {
> + keepgoing |= xul_uart_int_tx_chars(port);
> + }
> +
> + /* Limit number of iteration */
> + if ( !(--pass) )
> + keepgoing = 0;
> +
> + } while (keepgoing);
> +
> + spin_unlock(&port->lock);
> +
> + return IRQ_HANDLED;
> +}
> +
> +
> +/*
> + * Utility routines
> + */
> +
> +static void __init xul_uart_init_ports(void)
> +{
> + int i;
> + static int once = 1;
> +
> + /* Initialize ports only once */
> + if (!once)
> + return;
> + once = 0;
> +
> + for (i = 0; i < XPAR_XUARTLITE_NUM_INSTANCES; ++i) {
> + struct uart_port *xup = &xul_uart_ports[i];
> +
> + xup->line = i;
> + spin_lock_init(&xup->lock);
> + xup->uartclk = xul_data[i].uartclk / 16;
> + xup->fifosize = 16;
> + xup->iotype = UPIO_MEM;
> + xup->flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP;
> + xup->ops = &xul_uart_ops;
> + xup->irq = xul_data[i].irq;
> + xup->mapbase = xul_data[i].mapbase;
> + }
> +}
> +
> +static void __init xul_uart_register_ports(struct uart_driver *driver)
> +{
> + int i, ret;
> +
> + for(i = 0; i < XPAR_XUARTLITE_NUM_INSTANCES; ++i) {
> + struct uart_port *port = &xul_uart_ports[i];
> + /* Add the port to the uart sub-system */
> + ret = uart_add_one_port(driver, port);
> + }
> +}
> +
> +/* ======================================================================== */
> +/* Console ( if applicable ) */
> +/* ======================================================================== */
> +
> +#ifdef CONFIG_SERIAL_XUL_CONSOLE
> +
> +static void
> +xul_console_write(struct console *co, const char *s, unsigned int count)
> +{
> + struct uart_port *port = &xul_uart_ports[co->index];
> + unsigned int i, j;
> +
> + /* Disable interrupts */
> +
> + spin_lock(&port->lock);
> + out_be32((volatile unsigned *) (XUL(port) + XUL_CONTROL_REG_OFFSET), 0);
> + spin_unlock(&port->lock);
> +
> + /* Wait the TX buffer to be empty */
> + j = 5000000; /* Maximum wait */
> + while (!(is_xmit_empty(port)) &&
> + --j)
> + udelay(1);
> +
> + for (i = 0; i < count; i++, s++) {
> + if (*s == '\n')
> + xmit_char(port, '\r');
> +
> + xmit_char(port, *s);
> + }
> +
> + /* Restore interrupt state */
> + out_be32((volatile unsigned *) (XUL(port) + XUL_CONTROL_REG_OFFSET), 0);
> +}
> +
> +static int __init
> +xul_console_setup(struct console *co, char *options)
> +{
> + struct uart_port *port;
> + int baud;
> + int bits;
> + int parity;
> + int flow;
> +
> + if (co->index < 0 || co->index >= XPAR_XUARTLITE_NUM_INSTANCES)
> + return -EINVAL;
> +
> + port = &xul_uart_ports[co->index];
> +
> + /* We ioremap ourself */
> + port->membase = ioremap(port->mapbase, xul_data[co->index].size);
> +
> + if (port->membase == NULL) {
> + return -EINVAL;
> + }
> +
> + port->flags &= ~UPF_IOREMAP;
> +
> + baud = xul_data[co->index].baud;
> + parity = xul_data[co->index].parity;
> + bits = xul_data[co->index].bits;
> + flow = xul_data[co->index].flow;
> +
> + return uart_set_options(port, co, baud, parity, bits, flow);
> +}
> +
> +static struct uart_driver xul_uart_driver;
> +
> +static struct console xul_console = {
> + .name = "ttyXUL",
> + .write = xul_console_write,
> + .device = uart_console_device,
> + .setup = xul_console_setup,
> + .flags = CON_PRINTBUFFER,
> + .index = -1, /* Specified on the cmdline (e.g. console=ttyXUL0 ) */
> + .data = &xul_uart_driver,
> +};
> +
> +
> +static int __init
> +xul_console_init(void)
> +{
> + xul_uart_init_ports();
> + register_console(&xul_console);
> + return 0;
> +}
> +
> +console_initcall(xul_console_init);
> +
> +#define XUL_CONSOLE &xul_console
> +#else
> +#define XUL_CONSOLE NULL
> +#endif
> +
> +
> +/* ======================================================================== */
> +/* UART Driver */
> +/* ======================================================================== */
> +
> +static struct uart_driver xul_uart_driver = {
> + .owner = THIS_MODULE,
> + .driver_name = "xul_uart",
> + .dev_name = "ttyXUL",
> + .major = SERIAL_XUL_MAJOR,
> + .minor = SERIAL_XUL_MINOR,
> + .nr = XPAR_XUARTLITE_NUM_INSTANCES,
> + .cons = XUL_CONSOLE,
> +};
> +
> +
> +/* ======================================================================== */
> +/* Platform Driver */
> +/* ======================================================================== */
> +
> +static int __devinit
> +xul_uart_probe(struct platform_device *dev)
> +{
> + /* Probe does nothing */
> + return 0;
> +}
> +
> +static int
> +xul_uart_remove(struct platform_device *dev)
> +{
> + struct uart_port *port = (struct uart_port *) platform_get_drvdata(dev);
> +
> + platform_set_drvdata(dev, NULL);
> +
> + if (port)
> + uart_remove_one_port(&xul_uart_driver, port);
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_PM
> +static int
> +xul_uart_suspend(struct platform_device *dev, pm_message_t state)
> +{
> + struct uart_port *port = (struct uart_port *) platform_get_drvdata(dev);
> +
> + if (port)
> + uart_suspend_port(&xul_uart_driver, port);
> +
> + return 0;
> +}
> +
> +static int
> +xul_uart_resume(struct platform_device *dev)
> +{
> + struct uart_port *port = (struct uart_port *) platform_get_drvdata(dev);
> +
> + if (port)
> + uart_resume_port(&xul_uart_driver, port);
> +
> + return 0;
> +}
> +#endif
> +
> +static struct platform_driver xul_uart_platform_driver = {
> + .probe = xul_uart_probe,
> + .remove = xul_uart_remove,
> +#ifdef CONFIG_PM
> + .suspend = xul_uart_suspend,
> + .resume = xul_uart_resume,
> +#endif
> + .driver = {
> + .name = "xul_uart"
> + },
> +};
> +
> +
> +/* ======================================================================== */
> +/* Module */
> +/* ======================================================================== */
> +
> +static int __init
> +xul_uart_init(void)
> +{
> + int ret;
> +
> + printk(KERN_INFO "Serial: Xilinx UART Lite driver\n");
> +
> + xul_uart_init_ports();
> +
> + ret = uart_register_driver(&xul_uart_driver);
> +
> + if (ret == 0) {
> + xul_uart_register_ports(&xul_uart_driver);
> +
> + ret = platform_driver_register(&xul_uart_platform_driver);
> +
> + if (ret) {
> + printk(KERN_WARNING "platform_driver_register failed! :%i\n", ret);
> + uart_unregister_driver(&xul_uart_driver);
> + }
> + }
> +
> + return ret;
> +}
> +
> +static void __exit
> +xul_uart_exit(void)
> +{
> + platform_driver_unregister(&xul_uart_platform_driver);
> + uart_unregister_driver(&xul_uart_driver);
> +}
> +
> +
> +module_init(xul_uart_init);
> +module_exit(xul_uart_exit);
> +
> +MODULE_AUTHOR("David Bolcsfoldi <dbolcsfoldi@gmail.com>");
> +MODULE_DESCRIPTION("Xilinx UART Lite");
> +MODULE_LICENSE("GPL");
> +
>
> ------------------------------------------------------------------------
>
> --- 2.6.18/arch/ppc/platforms/4xx/xilinx_ml403.c 2006-10-04 14:31:15.000000000 -0700
> +++ patched/arch/ppc/platforms/4xx/xilinx_ml403.c 2006-10-07 10:41:50.000000000 -0700
> @@ -69,6 +69,7 @@
> .device_list = (enum ppc_sys_devices[])
> {
> VIRTEX_UART,
> + VIRTEX_XUL_UART,
> },
> },
> };
>
> ------------------------------------------------------------------------
>
> --- 2.6.18/include/linux/serial_core.h 2006-10-04 14:31:19.000000000 -0700
> +++ patched/include/linux/serial_core.h 2006-10-07 10:52:24.000000000 -0700
> @@ -132,6 +132,8 @@
>
> #define PORT_S3C2412 73
>
> +/* Xilinx UART Lite */
> +#define PORT_XUL 74
>
> #ifdef __KERNEL__
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
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
[-- Attachment #2: Type: text/html, Size: 30125 bytes --]
^ permalink raw reply
* Re: Graphic issues (emulating VGA bios on IBM Maple)
From: Benjamin Herrenschmidt @ 2006-10-11 22:16 UTC (permalink / raw)
To: jean-francois simon; +Cc: linuxppc-dev
In-Reply-To: <20061010203620.771.qmail@web27502.mail.ukl.yahoo.com>
> [C000000000BFFE60] [C0000000003CCC9C] .radeonfb_old_init+0x164/0x188
Try getting rid of the old radeonfb and see if that works.
Ben.
^ permalink raw reply
* Re: [PATCH 21/21]: powerpc/cell spidernet DMA coalescing
From: Benjamin Herrenschmidt @ 2006-10-11 22:13 UTC (permalink / raw)
To: Linas Vepstas
Cc: akpm, jeff, Arnd Bergmann, netdev, James K Lewis, linux-kernel,
linuxppc-dev
In-Reply-To: <20061011152016.GU4381@austin.ibm.com>
> I started writingthe patch thinking it will have some huge effect on
> performance, based on a false assumption on how i/o was done on this
> machine
>
> *If* this were another pSeries system, then each call to
> pci_map_single() chews up an actual hardware "translation
> control entry" (TCE) that maps pci bus addresses into
> system RAM addresses. These are somewhat limited resources,
> and so one shouldn't squander them. Furthermore, I thouhght
> TCE's have TLB's associated with them (similar to how virtual
> memory page tables are backed by hardware page TLB's), of which
> there are even less of. I was thinking that TLB thrashing would
> have a big hit on performance.
>
> Turns out that there was no difference to performance at all,
> and a quick look at "cell_map_single()" in arch/powerpc/platforms/cell
> made it clear why: there's no fancy i/o address mapping.
>
> Thus, the patch has only mrginal benefit; I submit it only in the
> name of "its the right thing to do anyway".
Well, there is no fancy iommu mapping ... yet.
It's been implemented and is coming after we put together some
workarounds for various other spider hardware issues that trigger when
using it (bogus prefetches and bogus pci ordering).
I think the hypervisor based platforms will be happy with that patch
too.
Ben.
^ permalink raw reply
* Re: PPChameleonEVB Newbie question
From: Wolfgang Denk @ 2006-10-11 23:00 UTC (permalink / raw)
To: Adrian; +Cc: linuxppc-embedded
In-Reply-To: <010001c6ed49$aa8ab390$3a0da8c0@adrianlaptop>
Dear Adrian,
in message <010001c6ed49$aa8ab390$3a0da8c0@adrianlaptop> you wrote:
>
> I have a PPChameleonEVB board running a 405EP processor.
DAVE has a lot of pretty detailed application notes. Make sure to
read their docs.
> I have tried many things, and can now boot Linux 2.6.15 on the board using
> an NFS share as both root fs and swap.
Swap over NFS? Grrghh...
> When I try to compile & install the kernel modules on the board, i get an
> message about perl and then it errors.
Why don't you just use the cross tools?
> 1) Kernel version/Linux distroof the i386 PC used for the cross-compiling.
Should not matter much.
> 2) ELDK version and if there are any patches needed.
For a 2.6 kernel tree you need ELDK 4.0.
> 2) Perl version (or how to stop the Kernel build using perl)
Use the cross tools. It's much faster anyway.
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
He had quite a powerful intellect, but it was as powerful like a
locomotive, and ran on rails and was therefore almost impossible to
steer. - Terry Pratchett, _Lords and Ladies_
^ permalink raw reply
* [PATCH 0/4] powerpc: Next round of bootwrapper flat dt patches
From: Mark A. Greer @ 2006-10-12 1:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
I'm resumitting the entire patch series because I messed up the
threading and made some changes to simple_alloc.
Mark
---
Hi,
This patch series is a respin of--and complete replacement for--the
bootwrapper reorg patches that I sent out a while back. I also included
the flatdevtree.c file which is the latest version that Paul sent plus
changes that I've made.
The patches apply to powerpc.git commit id:
ba00003aa83a61b615542dd66f5af8fb4a7cee1d
Paul, it would really help the rest of us if you would apply these patches
quickly. There are several people waiting for this work but there are so
many versions of so many patches that no one knows what to use. Plus, it
would get more people testing/debugging the flatdevtree code.
Summary of changes:
===================
more reorg patch
----------------
- This patch includes Paul's changes to zImage.lds.S which define
_dtb_start & _dtb_end and a related patch for the wrapper script.
- I changed main.c:start() a little so that the call to ft_init() is
done in platform_init(). I did this because of an interface change
to ft_init which now require some platform knowledge.
- I added a realloc() call to dt_ops so it can be passed to ft_open.
flatdevtree patch
-----------------
- I did not debug all of the flatdevtree.c code. I only debugged
ft_find_device, ft_get_prop, ft_set_prop and their supporting routines.
- I added a phandle table (insided the cxt) to track phandles returned by
ft_find_device(). Now the value returned by ft_find_device() is a phandle
which is nothing more than an index into the phandle table. The phandle
table contains the address of the corresponding node. When the flat dt
is edited/moved, the node pointers in the phandle table are updated
accordingly so no phandles kept by the caller become stale.
- I tested shrinking, and expanding an existing property but did not test
adding a new property.
- I'm not sure of the usefulness of the genealogy stuff but I left it there
in case Paul has plans for it. I did not test ft_get_parent (the only user
of genealogy).
simple_realloc patch
--------------------
- The flatdevtree code needs a realloc now so that is implemented in here.
- As the name implies, it is a simple allocator which uses a table to track
what's been allocated. simple_alloc_init() let's the caller set where
the heap is, its size, the granularity of its allocations, and how many
entries the table has.
- Once a slot in the table is used, its base & size are set. This allows
the code to be much simpler.
non-OF serial console patch
---------------------------
- I decided not to look for a /cpus/<some cpu>/64-bit property and instead
get either 1 or 2 "32-bit things" from the uart's 'virtual-reg' property.
If there is 1, its 32-bits; if its 2, its 64-bits.
Mark
^ 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