* [PATCH] PPC: CELLEB - fix potential NULL pointer dereference
From: Cyrill Gorcunov @ 2007-11-26 7:46 UTC (permalink / raw)
To: PPCML; +Cc: Olof Johansson, Paul Mackerras, LKML
[-- Attachment #1: Type: text/plain, Size: 218 bytes --]
This patch adds checking for NULL value returned to prevent possible
NULL pointer dereference.
Also two unneeded 'return' are removed.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
---
Any comments are welcome.
[-- Attachment #2: ppc-celleb-fix-null.diff --]
[-- Type: text/plain, Size: 2105 bytes --]
arch/powerpc/platforms/celleb/pci.c | 23 ++++++++++++++++++++---
1 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/pci.c b/arch/powerpc/platforms/celleb/pci.c
index 6bc32fd..9b8bb01 100644
--- a/arch/powerpc/platforms/celleb/pci.c
+++ b/arch/powerpc/platforms/celleb/pci.c
@@ -138,8 +138,6 @@ static void celleb_config_read_fake(unsigned char *config, int where,
*val = celleb_fake_config_readl(p);
break;
}
-
- return;
}
static void celleb_config_write_fake(unsigned char *config, int where,
@@ -158,7 +156,6 @@ static void celleb_config_write_fake(unsigned char *config, int where,
celleb_fake_config_writel(val, p);
break;
}
- return;
}
static int celleb_fake_pci_read_config(struct pci_bus *bus,
@@ -348,9 +345,25 @@ static int __init celleb_setup_fake_pci_device(struct device_node *node,
pr_debug("PCI: res assigned 0x%016lx\n", (unsigned long)*res);
wi0 = of_get_property(node, "device-id", NULL);
+ if (unlikely((!wi0))) {
+ printk(KERN_ERR "PCI: device-id not found.\n");
+ goto error;
+ }
wi1 = of_get_property(node, "vendor-id", NULL);
+ if (unlikely((!wi1))) {
+ printk(KERN_ERR "PCI: vendor-id not found.\n");
+ goto error;
+ }
wi2 = of_get_property(node, "class-code", NULL);
+ if (unlikely((!wi2))) {
+ printk(KERN_ERR "PCI: class-code not found.\n");
+ goto error;
+ }
wi3 = of_get_property(node, "revision-id", NULL);
+ if (unlikely((!wi3))) {
+ printk(KERN_ERR "PCI: revision-id not found.\n");
+ goto error;
+ }
celleb_config_write_fake(*config, PCI_DEVICE_ID, 2, wi0[0] & 0xffff);
celleb_config_write_fake(*config, PCI_VENDOR_ID, 2, wi1[0] & 0xffff);
@@ -372,6 +385,10 @@ static int __init celleb_setup_fake_pci_device(struct device_node *node,
celleb_setup_pci_base_addrs(hose, devno, fn, num_base_addr);
li = of_get_property(node, "interrupts", &rlen);
+ if (!li) {
+ printk(KERN_ERR "PCI: interrupts not found.\n");
+ goto error;
+ }
val = li[0];
celleb_config_write_fake(*config, PCI_INTERRUPT_PIN, 1, 1);
celleb_config_write_fake(*config, PCI_INTERRUPT_LINE, 1, val);
^ permalink raw reply related
* Re: MontaVista 4.0.1 on Xilinx ML405 board
From: schardt @ 2007-11-26 7:12 UTC (permalink / raw)
To: gsk19; +Cc: linuxppc-embedded
In-Reply-To: <20071123185858.DSC68826@mas23.bezeqint.net>
lock up the location of the __log_buf in the System.map and check if
errormessages are stored there in the memory.
check the console device. it must be /dev/ttyULx
Georg
gsk19@bezeqint.net wrote:
> We built a design for ML405 using EDK 9.1.02. EDK also
> creates linux drivers for MontaVista Pro 4.0.1 (2.6.10).
> The drivers were copied to a clean copy of Pro 4.0.1 and the
> kernel was built. When we downloaded the kernel to the target
> and ran it, we got exception. We didn't get any messages on
> the hyper terminal.
> We used Tri-Mode Ethernet and UART lite.
> MontaVista checked the integration of EDK 8.2 with ML403.
> Can you help ?
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Dr. Sebastian M. Schmidt
-------------------------------------------------------------------
-------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] [PPC 44x] L2-cache synchronization for ppc44x
From: Benjamin Herrenschmidt @ 2007-11-26 6:47 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <608329302.20071108021252@emcraft.com>
On Thu, 2007-11-08 at 02:12 +0300, Yuri Tikhonov wrote:
> This is the updated patch for support synchronization of L2-Cache with the external memory on the ppc44x-based platforms.
>
> Differencies against the previous patch-set:
> - remove L2_CACHE config option;
> - introduce the ppc machdep to invalidate L2 cache lines;
> - some code clean-up.
>
> Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
> Signed-off-by: Pavel Kolesnikov <concord@emcraft.com>
It's almost right :-0
You want something a bit more details than just a
ppc_md.l2cache_inv_range.
I'd suggest you do a separate extcache_ops structure that contains
callbacks for all 3 directions (flush, flush & invalidate, invalidate),
then fill that up accordingly.
It might be a good idea in the long run to do some tricks to avoid a
branch via function pointer since the cache ops are pretty "hot", but if
that ever happens, I'll do that via asm patching tricks I suppose.
Now regarding the line size, I would recommend using the device-tree to
describe the cache instead rather than a config option. The intend is to
be able to build a single binary kernel that can boot multiple variants
of 44x.
I may eventually rewrite your patch around those ideas next week if you
don't feel like doing it -and- I get bored :-)
Cheers,
Ben.
^ permalink raw reply
* Re: The question about the high memory support on MPC8360?
From: vijay baskar @ 2007-11-26 6:11 UTC (permalink / raw)
To: 郭劲; +Cc: linuxppc-embedded
In-Reply-To: <396049508.10992@tsinghua.org.cn>
Hi friends,
Kernel virtual space is divided into 3 different zones namely ZONE_DMA,=20
ZONE_NORMAL, ZONE_HIGHMEM.Remember that the kernel follows the 3GB/1GB=20
split ie 3 GB for user space and 1 GB for kernel space. Since your ram=20
is 1 GB, 896 MB will be mapped one to one with the kernel virtual space.=20
This one to one mapping will be done in the ZONE_NORMAL and ZONE_DMA of=20
kernel virtual space.Remaining 128 MB of kernel virtual address space=20
will be used for setting up kernel data structures and for ioremaps and=20
vmallocs that the kernel will need to perform during boot up. If u=20
configure high memory this 128 MB will be used for accessing unmapped=20
memory regions in the ram and there wont be sufficient virtual=20
addresses for ioremaps and vmallocs. Thats why your kernel did not boot=20
when high mem is configured.
Since u want to have 1 GB of ram an alternative to=20
this is that u can try 2 GB/ 2 GB split which is configurable ie 2 GB=20
for user space and 2 GB for kernel space in your kernel.
Thanks and Regards,
vijai
=E9=83=AD=E5=8A=B2 wrote:
>Hi,friends,=20
> I plug in 1GB DDR-1 on my MPC8360 board, the u-boot-1.2.0 found the DD=
R storage
>is 1GB, but the linux just found 773504k. please see follow information=
.
> I think I need to config the kernel to support the high memory. but i=
f I config
>the kernel to select the "high memory support" under the "platform optio=
ns" on
>"linux kernel configuration" during compile, the kernel is not to boot. =
if I
>cancel this options, the kernel is ok to run.
> why? how to deal with this problem? there are two DIMM-184 slots on m=
y MPC8360
>board, I want to support total 2GB DDR-1 storage. now I want to try 1GB =
on one of=20
>DIMM-184 slots firstly.
> please see follow information. Thanks.
>
>
>~ # dmesg =
=20
>Linux version 2.6.11 (olivia@bamboo) (gcc version 3.4.3) #1 Thu Jul 12 1=
4:29:297
>On node 0 totalpages: 196608 =
=20
> DMA zone: 196608 pages, LIFO batch:16 =
=20
> Normal zone: 0 pages, LIFO batch:1 =
=20
> HighMem zone: 0 pages, LIFO batch:1 =
=20
>Built 1 zonelists =
=20
>Kernel command line: console=3DttyS0,115200 root=3D/dev/ram0 =
=20
>IPIC (128 IRQ sources, 8 External IRQs) at fe000700 =
=20
>QE IC (64 IRQ sources) at fe100080 =
=20
>PID hash table entries: 4096 (order: 12, 65536 bytes) =
=20
>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) =
=20
>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) =
=20
>Memory: 773504k available (1724k kernel code, 432k data, 100k init, 0k h=
ighmem)=20
>Calibrating delay loop... 351.23 BogoMIPS (lpj=3D175616) =
=20
>Mount-cache hash table entries: 512 (order: 0, 4096 bytes) =
=20
>checking if image is initramfs...it isn't (no cpio magic); looks like an=
initrd=20
>Freeing initrd memory: 3120k freed =
=20
>NET: Registered protocol family 16 =
=20
>Registering ipic with sysfs... =
=20
>SCSI subsystem initialized =
=20
>JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc. =
=20
>Generic RTC Driver v1.07 =
=20
>Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disable=
d =20
>ttyS0 at MMIO 0xe0004500 (irq =3D 9) is a 16550A =
=20
>ttyS1 at MMIO 0xe0004600 (irq =3D 10) is a 16550A =
=20
>io scheduler noop registered =
=20
>io scheduler anticipatory registered =
=20
>io scheduler deadline registered =
=20
>io scheduler cfq registered =
=20
>RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize =
=20
>loop: loaded (max 8 devices) =
=20
>MPC8360E PB flash device: 2000000 at fe000000 Partition number 6 =
=20
>MPC8360E PB Flash Map Info: Found 1 x16 devices at 0x0 in 16-bit bank =
=20
>MPC8360E PB Flash Map Info: Found an alias at 0x1000000 for the chip at =
0x0 =20
>Support for command set 0001 not present =
=20
>gen_probe: No supported Vendor Command Set found =
=20
>i2c /dev entries driver =
=20
>eth0: Running with NAPI disabled =
=20
>eth1: Running with NAPI disabled =
=20
>NET: Registered protocol family 2 =
=20
>IP: routing cache hash table of 8192 buckets, 64Kbytes =
=20
>TCP established hash table entries: 131072 (order: 8, 1048576 bytes) =
=20
>TCP bind hash table entries: 65536 (order: 6, 262144 bytes) =
=20
>TCP: Hash tables configured (established 131072 bind 65536) =
=20
>NET: Registered protocol family 1 =
=20
>NET: Registered protocol family 17 =
=20
>RAMDISK: Compressed image found at block 0 =
=20
>VFS: Mounted root (ext2 filesystem) readonly. =
=20
>Freeing unused kernel memory: 100k init =
=20
>eth0: PHY is Marvell 88E11x1 (1410cc1) =
=20
>eth0: Full Duplex =
=20
>eth0: Speed 1000BT =
=20
>eth0: Link is up
>
>
>U-Boot 1.2.0 (Nov 21 2007 - 16:05:15) MPC83XX =
=20
> =
=20
>CPU: e300c1, MPC8360E, Rev: 20 at 528 MHz, CSB: 264 MHz =
=20
>Board: Freescale MPC8360EMDS =
=20
>I2C: ready =
=20
>DRAM: =
=20
>DIMM type: =
=20
>SPD size: 128 =
=20
>EEPROM size: 256 =
=20
>Memory type: 7 =
=20
>Row addr: 13 =
=20
>Column addr: 11 =
=20
># of rows: 2 =
=20
>Row density: 128 =
=20
># of banks: 4 =
=20
>Data width: 64 =
=20
>Chip width: 8 =
=20
>Refresh rate: 82 =
=20
>CAS latencies: 1C =
=20
>Write latencies: 02 =
=20
>tRP: 60 =
=20
>tRCD: 60 =
=20
> =
=20
> =
=20
> DDR DIMM: data bus width is 64 bit without ECC =
=20
> DDRC ECC mode: OFF =
=20
> =
=20
> SDRAM on Local Bus: 64 MB =
=20
> DDR RAM: 1024 MB =
=20
>FLASH: 16 MB =
=20
>PCI clock is 66MHz =
=20
>PCI 32bit bus on PMC1 & PMC2 & PMC3 =
=20
>In: serial =
=20
>Out: serial =
=20
>Err: serial =
=20
>Net: UEC: PHY is Marvell 88E11x1 (1410cc1) =
=20
>FSL UEC0: Full Duplex =
=20
>FSL UEC0: Speed 1000BT =
=20
>FSL UEC0: Link is up =
=20
>FSL UEC0 =
=20
>Hit any key to stop autoboot: 0 =
=20
>=3D> bootm fed00000 fe900000 =
=20
>## Booting image at fed00000 ... =
=20
> Image Name: Linux-2.6.11 =
=20
> Image Type: PowerPC Linux Kernel Image (gzip compressed) =
=20
> Data Size: 1054435 Bytes =3D 1 MB =
=20
> Load Address: 00000000 =
=20
> Entry Point: 00000000 =
=20
> Verifying Checksum ... OK =
=20
> Uncompressing Kernel Image ... OK =
=20
>## Loading RAMDisk Image at fe900000 ... =
=20
> Image Name: uboot ext2 ramdisk rootfs =
=20
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed) =
=20
> Data Size: 3195657 Bytes =3D 3 MB =
=20
> Load Address: 00000000 =
=20
> Entry Point: 00000000 =
=20
> Verifying Checksum ... OK =
=20
> Loading Ramdisk to 0fc9a000, end 0ffa6309 ... OK
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> =20
>
^ permalink raw reply
* The question about the high memory support on MPC8360?
From: 郭劲 @ 2007-11-26 3:58 UTC (permalink / raw)
To: linuxppc-embedded
Hi,friends,
I plug in 1GB DDR-1 on my MPC8360 board, the u-boot-1.2.0 found the DDR storage
is 1GB, but the linux just found 773504k. please see follow information.
I think I need to config the kernel to support the high memory. but if I config
the kernel to select the "high memory support" under the "platform options" on
"linux kernel configuration" during compile, the kernel is not to boot. if I
cancel this options, the kernel is ok to run.
why? how to deal with this problem? there are two DIMM-184 slots on my MPC8360
board, I want to support total 2GB DDR-1 storage. now I want to try 1GB on one of
DIMM-184 slots firstly.
please see follow information. Thanks.
~ # dmesg
Linux version 2.6.11 (olivia@bamboo) (gcc version 3.4.3) #1 Thu Jul 12 14:29:297
On node 0 totalpages: 196608
DMA zone: 196608 pages, LIFO batch:16
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: console=ttyS0,115200 root=/dev/ram0
IPIC (128 IRQ sources, 8 External IRQs) at fe000700
QE IC (64 IRQ sources) at fe100080
PID hash table entries: 4096 (order: 12, 65536 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 773504k available (1724k kernel code, 432k data, 100k init, 0k highmem)
Calibrating delay loop... 351.23 BogoMIPS (lpj=175616)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 3120k freed
NET: Registered protocol family 16
Registering ipic with sysfs...
SCSI subsystem initialized
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
ttyS0 at MMIO 0xe0004500 (irq = 9) is a 16550A
ttyS1 at MMIO 0xe0004600 (irq = 10) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
MPC8360E PB flash device: 2000000 at fe000000 Partition number 6
MPC8360E PB Flash Map Info: Found 1 x16 devices at 0x0 in 16-bit bank
MPC8360E PB Flash Map Info: Found an alias at 0x1000000 for the chip at 0x0
Support for command set 0001 not present
gen_probe: No supported Vendor Command Set found
i2c /dev entries driver
eth0: Running with NAPI disabled
eth1: Running with NAPI disabled
NET: Registered protocol family 2
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 100k init
eth0: PHY is Marvell 88E11x1 (1410cc1)
eth0: Full Duplex
eth0: Speed 1000BT
eth0: Link is up
U-Boot 1.2.0 (Nov 21 2007 - 16:05:15) MPC83XX
CPU: e300c1, MPC8360E, Rev: 20 at 528 MHz, CSB: 264 MHz
Board: Freescale MPC8360EMDS
I2C: ready
DRAM:
DIMM type:
SPD size: 128
EEPROM size: 256
Memory type: 7
Row addr: 13
Column addr: 11
# of rows: 2
Row density: 128
# of banks: 4
Data width: 64
Chip width: 8
Refresh rate: 82
CAS latencies: 1C
Write latencies: 02
tRP: 60
tRCD: 60
DDR DIMM: data bus width is 64 bit without ECC
DDRC ECC mode: OFF
SDRAM on Local Bus: 64 MB
DDR RAM: 1024 MB
FLASH: 16 MB
PCI clock is 66MHz
PCI 32bit bus on PMC1 & PMC2 & PMC3
In: serial
Out: serial
Err: serial
Net: UEC: PHY is Marvell 88E11x1 (1410cc1)
FSL UEC0: Full Duplex
FSL UEC0: Speed 1000BT
FSL UEC0: Link is up
FSL UEC0
Hit any key to stop autoboot: 0
=> bootm fed00000 fe900000
## Booting image at fed00000 ...
Image Name: Linux-2.6.11
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1054435 Bytes = 1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at fe900000 ...
Image Name: uboot ext2 ramdisk rootfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 3195657 Bytes = 3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0fc9a000, end 0ffa6309 ... OK
^ permalink raw reply
* The question about the UART on UCC5,UCC6,UCC7,UCC8 for MPC8360?
From: 郭劲 @ 2007-11-26 3:47 UTC (permalink / raw)
To: linuxppc-embedded
Hi,friends,
I runed the LTIB for MPC8360,selected "configure the kernel", then the make
menuconfig is appeared,that is "linux kernel configuration". I config QE to
follow
style:
UCC1,GETH;
UCC2,GETH;
UCC5,UART;
UCC6,UART;
UCC7,UART;
UCC8,UART.
after compiled, I download the linux to MPC8360 board, but I cannot find the
serial device for UCC5,UCC6,UCC7,UCC8. I just find the ttyS0,ttyS1 is OK.
Could you tell me that what's the name for the serial device of UCC5,6,7,8?
Whether or not I can use those UART just like the ttyS0,ttyS1?
>Follow is the device name in linux for MPC8360.
>/dev # ls
>audio hdb5 mtdblock4 ram2 sdc3 tty6 ttyp0
>audio1 hdb6 mtdblock5 ram3 sdc4 tty7 ttyp1
>buttons hdb7 mtdblock6 random sdc5 ttyAM0 ttyp2
>console input net rtc sdc6 ttyAM1 ttyp3
>dsp kmem null sda sdc7 ttyAM2 ttyp4
>dsp1 loop0 ppp sda1 sdd ttyAM3 ttyp5
>fb0 loop1 psaux sda2 sdd1 ttyCPM0 ttyp6
>fb1 md0 ptmx sda3 sdd2 ttyCPM1 ttyp7
>fb2 md1 pts sda4 sdd3 ttyP0 ttyp8
>fb3 md2 ptyp0 sda5 sdd4 ttyP1 ttyp9
>hda md3 ptyp1 sda6 sdd5 ttyP2 ubda
>hda1 mem ptyp2 sda7 sdd6 ttyP3 ubda1
>hda2 mtd0 ptyp3 sdb sdd7 ttyPSC0 ubda2
>hda3 mtd1 ptyp4 sdb1 shm ttyPSC1 ubda3
>hda4 mtd2 ptyp5 sdb2 sndstat ttyPSC2 ubda4
>hda5 mtd3 ptyp6 sdb3 ts ttyPSC3 ubda5
>hda6 mtd4 ptyp7 sdb4 tty ttyPSC4 ubda6
>hda7 mtd5 ptyp8 sdb5 tty0 ttyPSC5 ubda7
>hdb mtd6 ptyp9 sdb6 tty1 ttyS0 urandom
>hdb1 mtdblock0 qspi sdb7 tty2 ttyS1 watchdog
>hdb2 mtdblock1 ram sdc tty3 ttyS2 zero
>hdb3 mtdblock2 ram0 sdc1 tty4 ttyS3
>hdb4 mtdblock3 ram1 sdc2 tty5 ttymxc0
>/dev # cat ttyS0
>
>/dev # cat ttyS1
>
>/dev # cat ttyS2
>cat: ttyS2: No such device or address
>/dev # cat ttyPSC0
>cat: ttyPSC0: No such device or address
>/dev # cat ttyP0
>cat: ttyP0: No such device or address
>/dev # cat ttyp0
>cat: ttyp0: Input/output error
>/dev # cat ttyAM0
>cat: ttyAM0: No such device or address
>/dev # cat ttyCPM0
>cat: ttyCPM0: No such device or address
>/dev #
^ permalink raw reply
* Re: [RFC][PATCH 0/3] OF-platform PATA driver
From: Paul Mundt @ 2007-11-26 1:40 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Jeff Garzik, linux-ide
In-Reply-To: <20071126002314.GA20104@zarina>
On Mon, Nov 26, 2007 at 03:23:14AM +0300, Anton Vorontsov wrote:
> On Sat, Nov 24, 2007 at 04:26:13PM +0900, Paul Mundt wrote:
> > On Fri, Nov 23, 2007 at 07:49:33PM -0500, Jeff Garzik wrote:
> > > Anton Vorontsov wrote:
> > > >Here is the PATA Platform driver using OF infrastructure.
> > > >
> > > >Mostly it's just a wrapper around a bit modified pata_platform
> > > >driver.
> > > >
> > > >Patches are well split for the easier review:
> > > >
> > > >First one factors out platform_device specific bits and modifies
> > > >pata_platform to be a library-alike driver (with platform_device
> > > >default binding).
> > > >
> > The only issue I have here is that this library-like version has subtle
> > semantic changes that will break existing drivers.
>
> Actually I've tried to keep semantics intact:
>
> +static int __devinit pata_platform_probe(struct platform_device *pdev)
> [...]
> + /*
> + * And the IRQ
> + */
> + irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> + if (irq_res)
> + irq_res->flags = pp_info ? pp_info->irq_flags : 0;
> [...]
>
> So, I'm passing flags from the platform data. Did you overlook these
> bits, or I'm still changing semantics somewhere else?
>
Oh, I overlooked that. Using irq_res->flags as a temporary for
pp_info->irq_flags seems a bit hacky, but as long as pp_info->irq_flags
semantics are intact, I'm not too violently opposed to this anyways.
> > Incidentally, we already have an include/linux/pata_platform.h. If this
> > is going to be library-like, through the prototypes in there, rather than
> > splitting them up betewen include/linux and drivers/ata. We don't need
> > two headers.
>
> My intention was: keep "private" declarations in the drivers/ata/ and
> "public" in the include/linux/ -- to not confuse pata_platform users
> by __pata_platform_* internal stuff. But okay, I'll merge them.
>
I suppose that depends on whether the intent is that all pata_platform
users will be stuck in drivers/ata or not. If this is treated as more of
a library, implementations can simply bury themselves in arch/ land if
they feel like it.
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce pata node, make use pata_of_platform driver
From: Anton Vorontsov @ 2007-11-26 0:34 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <200711242157.47303.arnd@arndb.de>
On Sat, Nov 24, 2007 at 09:57:46PM +0100, Arnd Bergmann wrote:
> On Friday 23 November 2007, Anton Vorontsov wrote:
> >
> > +static struct of_device_id mpc834x_ids[] = {
> > + { .compatible = "pata-platform", },
> > + {},
> > +};
> > +
> > +static int __init mpc834x_declare_of_platform_devices(void)
> > +{
> > + if (!machine_is(mpc834x_itx))
> > + return 0;
> > +
> > + of_platform_bus_probe(NULL, mpc834x_ids, NULL);
> > +
> > + return 0;
> > +}
> > +device_initcall(mpc834x_declare_of_platform_devices);
>
> This is not really how of_platform_bus_probe was meant to be used.
> Instead of listing the device you want to probe, you should list
> all buses that potentially contain a device that you are probing.
Yup, I sort of knew it. For mpc8349emitx, pata node should be in
the localbus node. But there is no localbus node yet... I'll fix
that issue in the next round of these patches.
Much thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [RFC][PATCH 0/3] OF-platform PATA driver
From: Anton Vorontsov @ 2007-11-26 0:23 UTC (permalink / raw)
To: Paul Mundt; +Cc: linuxppc-dev, Jeff Garzik, linux-ide
In-Reply-To: <20071124072613.GA7303@linux-sh.org>
On Sat, Nov 24, 2007 at 04:26:13PM +0900, Paul Mundt wrote:
> On Fri, Nov 23, 2007 at 07:49:33PM -0500, Jeff Garzik wrote:
> > Anton Vorontsov wrote:
> > >Here is the PATA Platform driver using OF infrastructure.
> > >
> > >Mostly it's just a wrapper around a bit modified pata_platform
> > >driver.
> > >
> > >Patches are well split for the easier review:
> > >
> > >First one factors out platform_device specific bits and modifies
> > >pata_platform to be a library-alike driver (with platform_device
> > >default binding).
> > >
> The only issue I have here is that this library-like version has subtle
> semantic changes that will break existing drivers.
Actually I've tried to keep semantics intact:
+static int __devinit pata_platform_probe(struct platform_device *pdev)
[...]
+ /*
+ * And the IRQ
+ */
+ irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (irq_res)
+ irq_res->flags = pp_info ? pp_info->irq_flags : 0;
[...]
So, I'm passing flags from the platform data. Did you overlook these
bits, or I'm still changing semantics somewhere else?
> irq_flags exists in struct pata_platform_info precisely for the IRQ
> resource IRQ flags (as opposed to the IORESOURCE flags, which are what
> the IRQ resource flags refer to instead). This change takes that for
> granted and just assumes we're going to be using the res->flags, which is
> both an invalid assumption, and will utterly break blackfin and others
> that depend on it.
>
> Incidentally, we already have an include/linux/pata_platform.h. If this
> is going to be library-like, through the prototypes in there, rather than
> splitting them up betewen include/linux and drivers/ata. We don't need
> two headers.
My intention was: keep "private" declarations in the drivers/ata/ and
"public" in the include/linux/ -- to not confuse pata_platform users
by __pata_platform_* internal stuff. But okay, I'll merge them.
> These patches basically look fine to me otherwise, though it would be
> nice if the semantic-changing bits had been abstracted. So as long as the
> old irq_flags behaviour is maintained and that irq_res->flags stuff is
> ripped out, I'll add my Acked-by as well.
Much thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [RFC][PATCH 0/3] OF-platform PATA driver
From: Anton Vorontsov @ 2007-11-26 0:21 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Paul Mundt, linuxppc-dev, Jeff Garzik, linux-ide
In-Reply-To: <200711242150.09812.arnd@arndb.de>
On Sat, Nov 24, 2007 at 09:50:07PM +0100, Arnd Bergmann wrote:
> On Friday 23 November 2007, Anton Vorontsov wrote:
> > Here is the PATA Platform driver using OF infrastructure.
> >
> > Mostly it's just a wrapper around a bit modified pata_platform
> > driver.
>
> Thanks a lot for doing this. Patches 2/3 are what I tried to get
> people to do for some time now but was too lazy to do myself.
>
> As a further thought, do the drivers now still need to be
> pata specific, or should the OF part be called ata_of_platform
> instead and also be used for sata devices?
Ugh, I don't know much about sata, it should act just as a pata
in the very basic usage, IIRC. So it's worth trying, but I don't
have any platform satas to try... :-/
Hereby, I'd rather stick with pata name, as it's never too late
to simply rename things later.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: Xilinx devicetrees
From: Stephen Neuendorffer @ 2007-11-25 23:58 UTC (permalink / raw)
To: David H. Lynch Jr., Grant Likely, linuxppc-embedded
In-Reply-To: <4749FD5E.7000408@dlasys.net>
[-- Attachment #1: Type: text/plain, Size: 4423 bytes --]
I understand that you're trying to be somewhat of a devil's advocate here, but (as I mentioned in my other email), alot of these are issues we're attempting to tackle.
More comments below.
-----Original Message-----
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of David H. Lynch Jr.
Sent: Sun 11/25/2007 2:55 PM
To: Grant Likely; linuxppc-embedded
Subject: Re: Xilinx devicetrees
Grant Likely wrote:
> I am not expert on this, but at Pico we already store our boot
> monitor in the .bit files in BRAM.
> But that is not free. It is one of the reasons we do not use
> u-boot. Our boot monitor must fit into 16K of BRAM.
> Must be able to perform selftests on critical hardware, support a
> flash file system, load bit files from flash to the FGA, load and
> exectute elf files, allow a small set of user commands, and handle
> hosted vs. standalone operation.
> And aparently extract the devicetree from a bit file and pass it to
> a linux kernel.
Once you can load a bitstream from flash, loading the device tree from flash
should be practically free. In any event, why do you do this rather than just run out of the flash (or a ram copy of the flash?)
> In static or fairly static hardware, that's fine. Even in somewhat
> dynamic hardware with large quantities of startup resources - like a PC.
> But in highly dynamic hardware with fairly limited resources it
> starts to become an issue.
As Grant says, the dynamic detection doesn't have to be done in the boot loader, it could be done in the platform code. You can largely ignore the device trees, or always boot with a core device tree and figure it all out later (perhaps using version registers). I anticipate that the 'standard flow' will have standard platform code for any board that uses a complete device tree. If you have the need to do something extraordinary, then you should feel free to hack away... However, It doesn't seem to me to be really necessary in your case, assuming that the device tree is packaged (somehow, TBD) along with the bitstream.
>> No, unfortunately they don't deal with the problem you're facing
>> (which I'm facing also). But it will be solved if we figure out a
>> sane way to bind the device tree up with the FPGA bitstream without
>> consuming FPGA resources.
>>
> Note to Xilinx:
>
> There MUST be some way of binding a device description to a bit file.
>
> neither building it into the FPGA fabric nor appending it to the end
> of the bit file are perfect solutions,
> The former is more powerfull and flexible but wastes precious
> resources. The later is more complex and puts more burdens on
> software developers, and may be completely unfeasible in some
> environments - not mine fortunately.
I don't understand the 'burden on software developers'. The code to do this will just be standard code. The worst that one can say is:
1) I need several KB additional non volatile storage. Given the size of the FPGA bitstream, this can't be a huge constraint.
2) I can't use compile time optimization based on xparameters as easily. Anyone want to implement the alternatives mechanism on ppc and microblaze?
3) Some additional boot time. However, again, this seems marginal.
> Regardless, something must be done. An odd collection of devicetree
> files co-mingled with a collection of bit files, is little better than
> xparameter files all over the place.
Certainly.. But in a sense, these are all intermediate files on the path to the image on the board. That (and how it is interpreted by the platform code) should be generated in a consistent fashion by EDK. See my other email for some of the possibilities. Are there specific reasons why you think those proposals are inadequate? Now is the time when we can take criticism, with the goal towards making a good end solution.
> And once again a plea to ALWAYS make version/capabilities registers
> atleast an optional part of every design.
> Embeddeding a device tree into a design might be fairly expensive. a
> pair of read only 32 bit registers is damn near free - basically the
> FPGA equivalent of atmost 64 diodes or resistors.
Actually, device trees actually seem to be cheaper (in the whole system sense) than such registers. Unless there is something I don't understand?
Steve
[-- Attachment #2: Type: text/html, Size: 5534 bytes --]
^ permalink raw reply
* [RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
From: Benjamin Herrenschmidt @ 2007-11-25 23:41 UTC (permalink / raw)
To: David Airlie; +Cc: linuxppc-dev, dri-devel, linux-kernel
This patch fixes bits of the DRM so to make the radeon DRI work on
non-cache coherent PCI DMA variants of the PowerPC processors.
It moves the few places that needs change to wrappers to that
other architectures with similar issues can easily add their
own changes to those wrappers, at least until we have more useful
generic kernel API.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/char/drm/ati_pcigart.c | 6 ++++++
drivers/char/drm/drm_scatter.c | 12 +++++++++++-
drivers/char/drm/drm_vm.c | 20 +++++++++++++++-----
3 files changed, 32 insertions(+), 6 deletions(-)
Index: linux-work/drivers/char/drm/ati_pcigart.c
===================================================================
--- linux-work.orig/drivers/char/drm/ati_pcigart.c 2007-11-26 10:07:29.000000000 +1100
+++ linux-work/drivers/char/drm/ati_pcigart.c 2007-11-26 10:21:33.000000000 +1100
@@ -214,6 +214,12 @@ int drm_ati_pcigart_init(struct drm_devi
}
}
+ if (gart_info->gart_table_location == DRM_ATI_GART_MAIN)
+ dma_sync_single_for_device(&dev->pdev->dev,
+ bus_address,
+ max_pages * sizeof(u32),
+ PCI_DMA_TODEVICE);
+
ret = 1;
#if defined(__i386__) || defined(__x86_64__)
Index: linux-work/drivers/char/drm/drm_scatter.c
===================================================================
--- linux-work.orig/drivers/char/drm/drm_scatter.c 2007-11-26 10:07:29.000000000 +1100
+++ linux-work/drivers/char/drm/drm_scatter.c 2007-11-26 10:20:08.000000000 +1100
@@ -36,6 +36,16 @@
#define DEBUG_SCATTER 0
+static inline void *drm_vmalloc_dma(unsigned long size)
+{
+#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
+ return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM,
+ PAGE_KERNEL | _PAGE_NO_CACHE);
+#else
+ return vmalloc_32(size);
+#endif
+}
+
void drm_sg_cleanup(struct drm_sg_mem * entry)
{
struct page *page;
@@ -104,7 +114,7 @@ int drm_sg_alloc(struct drm_device *dev,
}
memset((void *)entry->busaddr, 0, pages * sizeof(*entry->busaddr));
- entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
+ entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
if (!entry->virtual) {
drm_free(entry->busaddr,
entry->pages * sizeof(*entry->busaddr), DRM_MEM_PAGES);
Index: linux-work/drivers/char/drm/drm_vm.c
===================================================================
--- linux-work.orig/drivers/char/drm/drm_vm.c 2007-11-26 10:07:29.000000000 +1100
+++ linux-work/drivers/char/drm/drm_vm.c 2007-11-26 10:11:09.000000000 +1100
@@ -54,13 +54,24 @@ static pgprot_t drm_io_prot(uint32_t map
pgprot_val(tmp) |= _PAGE_NO_CACHE;
if (map_type == _DRM_REGISTERS)
pgprot_val(tmp) |= _PAGE_GUARDED;
-#endif
-#if defined(__ia64__)
+#elif defined(__ia64__)
if (efi_range_is_wc(vma->vm_start, vma->vm_end -
vma->vm_start))
tmp = pgprot_writecombine(tmp);
else
tmp = pgprot_noncached(tmp);
+#elif defined(__sparc__)
+ tmp = pgprot_noncached(tmp);
+#endif
+ return tmp;
+}
+
+static pgprot_t drm_dma_prot(uint32_t map_type, struct vm_area_struct *vma)
+{
+ pgprot_t tmp = vm_get_page_prot(vma->vm_flags);
+
+#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
+ tmp |= _PAGE_NO_CACHE;
#endif
return tmp;
}
@@ -617,9 +628,6 @@ static int drm_mmap_locked(struct file *
offset = dev->driver->get_reg_ofs(dev);
vma->vm_flags |= VM_IO; /* not in core dump */
vma->vm_page_prot = drm_io_prot(map->type, vma);
-#ifdef __sparc__
- vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
-#endif
if (io_remap_pfn_range(vma, vma->vm_start,
(map->offset + offset) >> PAGE_SHIFT,
vma->vm_end - vma->vm_start,
@@ -638,6 +646,7 @@ static int drm_mmap_locked(struct file *
page_to_pfn(virt_to_page(map->handle)),
vma->vm_end - vma->vm_start, vma->vm_page_prot))
return -EAGAIN;
+ vma->vm_page_prot = drm_dma_prot(map->type, vma);
/* fall through to _DRM_SHM */
case _DRM_SHM:
vma->vm_ops = &drm_vm_shm_ops;
@@ -650,6 +659,7 @@ static int drm_mmap_locked(struct file *
vma->vm_ops = &drm_vm_sg_ops;
vma->vm_private_data = (void *)map;
vma->vm_flags |= VM_RESERVED;
+ vma->vm_page_prot = drm_dma_prot(map->type, vma);
break;
default:
return -EINVAL; /* This should never happen. */
^ permalink raw reply
* RE: SPI, I2C
From: Stephen Neuendorffer @ 2007-11-25 23:17 UTC (permalink / raw)
To: David H. Lynch Jr., linuxppc-embedded
In-Reply-To: <4749441B.1000703@dlasys.net>
[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]
The drivers for these do exist (see git.xilinx.com). I suppose as a 'control' bus, they might actually be useful inside an FPGA, but why not just use dcr? Part of the value of i2c is minimizing wires (including power wires), but that's hardly a design constraint in an FPGA compared to conserving logic.
I also got fed up with the i2c core at one point and wrote a bitbang version for the gpio. It might be a bit slower, but it's dirt simple. I can send it do you, if you're interested.
Steve
-----Original Message-----
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of David H. Lynch Jr.
Sent: Sun 11/25/2007 1:44 AM
To: linuxppc-embedded
Subject: SPI, I2C
I have been asked to do SPI and I2C drivers for Pico cards.
I am trying to grasp what the practical use of either could be in an
environment where neither SPI nor I2C are going to be able to
communicate outside the FPGA.
I am guessing that SPI and I2C implementations already exist for
Xilinx FPGA's - any chance that drivers might already exist ?
I would prefer not to charge a client to reinvent something that
exists, or that can not serve a useful purpose.
I am not trying to imply that SPI or I2C are not useful, just that
they are communications channels, and unless they have outside I2C or
SPI hardware to talk to what purpose might they serve ?
--
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
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 3492 bytes --]
^ permalink raw reply
* Re: Xilinx devicetrees
From: David H. Lynch Jr. @ 2007-11-25 22:55 UTC (permalink / raw)
To: Grant Likely, linuxppc-embedded
In-Reply-To: <fa686aa40711251421q38f53ee3hb2a308cc5f93183f@mail.gmail.com>
Grant Likely wrote:
> nope, not at all the same as dynamic detection; just backwards
> compatibility with the way we do it now for arch/ppc.
>
Other things being equal a common architecture is preferable to a
collection of independent ones.
>
>
> No, it doesn't make sense to store is in the FPGA fabric; but if the
> design already contains BRAM then it could be placed there and
> reclaimed for other purposes after booting. Or anywhere in RAM for
> that matter. I don't know how feasible is to load a device tree into
> SDRAM at FPGA config time.
>
I am not expert on this, but at Pico we already store our boot
monitor in the .bit files in BRAM.
But that is not free. It is one of the reasons we do not use
u-boot. Our boot monitor must fit into 16K of BRAM.
Must be able to perform selftests on critical hardware, support a
flash file system, load bit files from flash to the FGA, load and
exectute elf files, allow a small set of user commands, and handle
hosted vs. standalone operation.
And aparently extract the devicetree from a bit file and pass it to
a linux kernel.
> Ah; I think I see the disconnect we're having. Device trees are not
> about, *and never have been about*, device detection. The device tree
> is simply the communication medium used to describe the hardware. It
> doesn't matter if you choose to use a 100% dynamically generated
> device tree from intelligent firmware or a 100% static device tree
> blob. All that matters is that the kernel is able to trust the
> information handed to it by firmware.
>
> Device detection is not a problem that the device tree is designed to solve.
>
> It is designed to solve the problem of telling the kernel what the
> platform looks like (which occurs after the detection stage).
>
In static or fairly static hardware, that's fine. Even in somewhat
dynamic hardware with large quantities of startup resources - like a PC.
But in highly dynamic hardware with fairly limited resources it
starts to become an issue.
Still if xilinx intends to generate the device tree with the bit
file - even better appended to the bit file or embedded in the FPGA if
feasible,
this could still work.
I do not see Detection as independent of communication.
Aside from a very minimal core, If device drivers can do a good job
of validating their hardware (back to my version registers issue in
another post) and I just load them willy nilly and let the ones that
have no hardware fail (Gross over simplification, but still viable) then
a communication scheme is meaningless. Going the opposite direction, if
I do not have the resources to detect the hardware and build the
devicetree dynamically, AND I have highly dynamic hardware, AND I do
not have an easy method I can trust of aquiring another source for the
hardware description, devicetree's aren't any help. There are alot of
AND's there but most if not all appear to be present with FPGA based
systems.
> arch/powerpc support for Virtex is now in Linus' mainline tree which
> will become 2.6.24
>
Guess it is time to pull Linus again.
> No, unfortunately they don't deal with the problem you're facing
> (which I'm facing also). But it will be solved if we figure out a
> sane way to bind the device tree up with the FPGA bitstream without
> consuming FPGA resources.
>
Note to Xilinx:
There MUST be some way of binding a device description to a bit file.
neither building it into the FPGA fabric nor appending it to the end
of the bit file are perfect solutions,
The former is more powerfull and flexible but wastes precious
resources. The later is more complex and puts more burdens on
software developers, and may be completely unfeasible in some
environments - not mine fortunately.
Regardless, something must be done. An odd collection of devicetree
files co-mingled with a collection of bit files, is little better than
xparameter files all over the place.
And once again a plea to ALWAYS make version/capabilities registers
atleast an optional part of every design.
Embeddeding a device tree into a design might be fairly expensive. a
pair of read only 32 bit registers is damn near free - basically the
FPGA equivalent of atmost 64 diodes or resistors.
> Cheers,
> g.
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* [PATCH 2/2] usb: Remove OHCI useless masking/unmasking of WDH interrupt
From: Benjamin Herrenschmidt @ 2007-11-25 22:54 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, linux-usb-devel
The OHCI driver's IRQ handler, while processing a WDH interrupt, masks
and unmasks it. I believe this is both broken (no dealign with write
posting) and totally useless as the IRQ cannot re-occur while we are in
the handler anyway.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
It might be a leftover related to the bogus optmisation that I've removed
in a separate patch. Anyway, I don't think it's any use so let's remove
to useless MMIO writes.
drivers/usb/host/ohci-hcd.c | 4 ----
1 file changed, 4 deletions(-)
Index: linux-work/drivers/usb/host/ohci-hcd.c
===================================================================
--- linux-work.orig/drivers/usb/host/ohci-hcd.c 2007-11-26 09:17:52.000000000 +1100
+++ linux-work/drivers/usb/host/ohci-hcd.c 2007-11-26 09:17:58.000000000 +1100
@@ -807,13 +807,9 @@ static irqreturn_t ohci_irq (struct usb_
}
if (ints & OHCI_INTR_WDH) {
- if (HC_IS_RUNNING(hcd->state))
- ohci_writel (ohci, OHCI_INTR_WDH, ®s->intrdisable);
spin_lock (&ohci->lock);
dl_done_list (ohci);
spin_unlock (&ohci->lock);
- if (HC_IS_RUNNING(hcd->state))
- ohci_writel (ohci, OHCI_INTR_WDH, ®s->intrenable);
}
if (quirk_zfmicro(ohci) && (ints & OHCI_INTR_SF)) {
^ permalink raw reply
* [PATCH 1/2] usb: Remove broken optimisation in OHCI IRQ handler
From: Benjamin Herrenschmidt @ 2007-11-25 22:54 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, linux-usb-devel
The OHCI IRQ handler has an optimisation that tries to avoid reading
the status register when it sees something has been put in the
controller "done list".
This optimisation is broken on controllers that use edge interrupt
signaling as it relies on "missed" interrupt to be re-emitted which
is not the case with egde interrupts. Among others, it breaks the
OHCI SoC controller in the AMCC 440EP PowerPC processor (and according
to David, it also breaks the SA1111).
This patch removes the optimisation along with making the code a little
bit less convoluted.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
While there, any reason why we do the read of the interenable register
and mask ? Is that actually useful in practice ? I haven't removed it
but it might be a good candidate if we want to save on MMIO reads.
drivers/usb/host/ohci-hcd.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
Index: linux-work/drivers/usb/host/ohci-hcd.c
===================================================================
--- linux-work.orig/drivers/usb/host/ohci-hcd.c 2007-11-26 09:14:12.000000000 +1100
+++ linux-work/drivers/usb/host/ohci-hcd.c 2007-11-26 09:16:40.000000000 +1100
@@ -732,24 +732,25 @@ static irqreturn_t ohci_irq (struct usb_
struct ohci_regs __iomem *regs = ohci->regs;
int ints;
- /* we can eliminate a (slow) ohci_readl()
- * if _only_ WDH caused this irq
- */
- if ((ohci->hcca->done_head != 0)
- && ! (hc32_to_cpup (ohci, &ohci->hcca->done_head)
- & 0x01)) {
- ints = OHCI_INTR_WDH;
+ /* Read interrupt status & flush pending DMAs */
+ ints = ohci_readl (ohci, ®s->intrstatus);
- /* cardbus/... hardware gone before remove() */
- } else if ((ints = ohci_readl (ohci, ®s->intrstatus)) == ~(u32)0) {
+ /* Check for an all 1's result which is the consequence of a
+ * dead or unplugged device
+ */
+ if (ints == ~(u32)0) {
disable (ohci);
ohci_dbg (ohci, "device removed!\n");
return IRQ_HANDLED;
+ }
+
+ /* We only care about interrupts that are enabled */
+ ints &= ohci_readl (ohci, ®s->intrenable);
+
/* interrupt for some other device? */
- } else if ((ints &= ohci_readl (ohci, ®s->intrenable)) == 0) {
+ if (ints == 0)
return IRQ_NOTMINE;
- }
if (ints & OHCI_INTR_UE) {
// e.g. due to PCI Master/Target Abort
^ permalink raw reply
* Re: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
From: Grant Likely @ 2007-11-25 22:47 UTC (permalink / raw)
To: Stephen Neuendorffer, Segher Boessenkool, David Gibson,
Jon Loeliger
Cc: microblaze-uclinux, Michal Simek, git, linuxppc-dev
In-Reply-To: <20071125062456.ABA4AA4804E@mail64-cpk.bigfish.com>
On 11/24/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
Thanks for all this work; comments below.
>
> Here's what I've gotten so far:
>
> Hard_Ethernet_MAC: xps-ll-temac@81c00000 {
> #address-cells = <1>;
> #size-cells = <1>;
> network@81c00000 {
> compatible = "xlnx,xps-ll-temac-1.00.a",
> "xlnx,xps-ll-temac";
Drop "xlnx,xps-ll-temac"; it's 100% made up. This should be simply:
compatible = "xlnx,xps-ll-temac-1.00.a" for version 1.00.a and
compatible =
"xlnx,xps-ll-temac-<version>","xlnx,xps-ll-temac-1.00.a" for a future
version if it maintains register level compatibility.
"xlnx,xps-ll-temac" is far to ambiguous.
> interrupt-parent = <&xps_intc_0>;
> interrupts = < 3 0 >;
> llink-connected = <&PIM3>;
What's this property for?
> reg = < 81c00000 40 >;
If these registers are addressable, then the parent needs a 'ranges' property.
> xlnx,bus2core-clk-ratio = <1>;
> xlnx,phy-type = <1>;
> xlnx,phyaddr = <1>;
> xlnx,rxcsum = <0>;
> xlnx,rxfifo = <1000>;
> xlnx,temac-type = <0>;
> xlnx,txcsum = <0>;
> xlnx,txfifo = <1000>;
Would be nice to have a 'phy-handle' property as that is what is being
used on other platforms; but that's not something that EDK knows
about. It would be nice to have a way to tell EDK what PHY device is
on the board so it could generate the appropriate mdio and phy nodes.
> } ;
> } ;
> mpmc@90000000 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "xlnx,mpmc-3.00.a", "xlnx,mpmc";
Drop 'xlns,mpmc'
> PIM3: sdma@84600180 {
> compatible = "xlnx,ll-dma-1.00a",
> "xlnx,ll-dma";
> interrupt-parent = <&xps_intc_0>;
> interrupts = < 1 0 0 0 >;
> reg = < 84600180 80 >;
Are these directly addressable registers from the CPU? If so, the
parent node needs a 'ranges' property.
> } ;
> } ;
> DDR2_SDRAM: memory@90000000 {
> device_type = "memory";
> reg = < 90000000 10000000 >;
> } ;
>
> So: the mpmc generates a 'memory' node, corresponding to it's memory
> interface. It also gets a separate entry which contains the (optional, not
> present in this example) slave management interface (for ECC and performance
> information), and any sdma ports. In this case, this node is mpmc@90000000,
> because there is no management interface. If a management interface was
> present, then it would be @ the management address.
I don't think this is right; but I'm not sure. I don't know what the
best naming convention is for the case of no management interface, but
mpmc@90000000 doesn't feel right.
Segher, David; what's your opinion?
> The mpmc gets a compatible string that describes its management interface.
> The sdma port has information about the tx and rx interrupts and the slave
> management interface. Note that the slave management interface has the
> correct baseaddress for port3, generated from the base SDMA_CTRL_ address
> from the mpmc + the port 3 offset. Note that sdma has an artificial
> compatible name. I'm not sure whether the ll_dma driver can be easily
> convinced to bind to this, or whether the ll_temac driver will just traverse
> the device tree and then do a match against this.
Don't worry about having a too-sparse compatible property. Be
specific and we can always add entries to the bind list. For the IP
cores, always specify specific device versions in the compatible
entries.
>
> The temac works similarly, although the temac itself doesn't have a slave
> interface, so no compatible node for it. The sub nodes get the compatible
> string for the ll_temac driver. In this case, there is only one temac port
> active. Some of the parameters are specific to port 0, in which case the
> parameter names (e.g. phyaddr) are generated by stripping off the complete
> C_TEMAC0 prefix. Other parameters (e.g. phy-type) are common to both sub
> nodes, but are duplicated to make it easier for the driver to get the
> information out. At runtime, the driver has to follow the llink-connected
> path to find what it is connected to, and use the dma code, or the fifo
> code.
>
> the xps-ll-fifo structure is a bit simpler, with llink-connected pointing
> to the fifo, which looks like a 'normal' peripheral.
>
> Points for comment:
> 1) I don't like the "PIM3" label, which is artificial (i.e. it doesn't
> correspond to a name in the .mhs) and not guaranteed to be unique. However,
> in the BSP generator it seems awkward to generate path references easily in
> a single pass. What I'd might prefer is:
> DDR2_SDRAM: mpmc@90000000 {
> sdma@3 {
>
> and refer to the sdma port using something like <&DDR2_SDRAM/sdma@3>, but I
> don't think you can do that in dtc?
If not, it is possible to extend the dtc syntax. Jon, David? Thoughts?
>
> 2) Not sure whether this is really simpler than just having a 'simple' node
> with both temacs and letting the driver sort everything out. In particular,
> I'm concerned about maintaining a bunch of semantic information about the
> ll_temac driver outside of the driver itself.
I wouldn't recommend it. It is better for probing to have one node
per logical device.
However, you could either have the network nodes as children of the
xps-ll-temac node, or they could be children of their addressable bus
and have phandles to the xps-ll-temac node...
In fact, if the network nodes are children of the xps-ll-temac node,
then the xps-ll-temac node should itself be a child of the addressable
bus (be it PLB or OPB).
Cheers,
g.
>
> 3) All of this is very different in structure from the way that the
> xparameters are organized. The ll_temac BSP code copies the xparameters out
> of the MPMC and they are simply other parameters of the ll_temac driver.
> Although the above structure better represents the actual system, there is
> another organization for people to be confused about.
>
> Steve
>
>
> -----Original Message-----
> From:
> linuxppc-dev-bounces+stephen.neuendorffer=xilinx.com@ozlabs.org
> on behalf of Stephen Neuendorffer
> Sent: Tue 11/20/2007 11:44 AM
> To: microblaze-uclinux@itee.uq.edu.au;
> linuxppc-dev@ozlabs.org; Grant Likely; Michal Simek
> Subject: Xilinx EDK BSP generation of device trees for microblaze and
> PowerPC
>
>
>
> I've updated some code from Michel Simek to generate Flat Device Trees
> from Xilinx EDK projects. This code is now hosted at:
> git://git.xilinx.com/gen-mhs-devtree.git
>
> This has one major advantage over the gen-mhs-devtree.py approach:
> default IP core parameters that are not specified in the mhs file can
> now be generated, since EDK pulls these in from the core .mpd file.
> I've also managed to incorporate a few more improvements from the
> previous review, so the BSP generator should include at least as much
> information as gen-mhs-devtree.py
>
> The next major order of business is to represent the DMA engines in the
> MPMC and locallink connections to the lltemac.
>
> Steve
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/3] [POWERPC] Add docs for Freescale 83xx SATA device tree nodes
From: Arnd Bergmann @ 2007-11-25 22:22 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711202312130.24220@blarg.am.freescale.net>
On Wednesday 21 November 2007, Kumar Gala wrote:
> + =A0 =A0* Freescale 8xxx/3.0 Gb/s SATA nodes
> +
> + =A0 =A0SATA nodes are defined to describe on-chip Serial ATA controller=
s.
> + =A0 =A0Each SATA port should have its own node.
> +
> + =A0 =A0Required properties:
> + =A0 =A0- compatible =A0 =A0 =A0 =A0: compatible list, contains 2 entrie=
s, first is
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "f=
sl,sata-CHIP", where CHIP is the processor
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (m=
pc8315, mpc8379, etc.) and the second is
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "f=
sl,sata-pq2pro"
> + =A0 =A0- interrupts =A0 =A0 =A0 =A0: <interrupt mapping for SATA IRQ>
> + =A0 =A0- interrupt-parent =A0: optional, if needed for interrupt mapping
> + =A0 =A0- reg =A0 =A0 =A0 =A0 =A0 =A0 =A0 : <registers mapping>
> +
Should this maybe also mandate a compatible property that is defined
in a way to match the generic (p)ata_of_platform driver?
Arnd <><
^ permalink raw reply
* Re: Xilinx devicetrees
From: Grant Likely @ 2007-11-25 22:21 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <47493D4F.4070605@dlasys.net>
On 11/25/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> > One more point; it is also possible to bind the device tree up with
> > the kernel so you've got a single image just like old times. :-)
> >
> But that is not actually the same is dynamically detecting
> configuration.
nope, not at all the same as dynamic detection; just backwards
compatibility with the way we do it now for arch/ppc.
> On an ordinary PC where the critical core configuration is somewhat
> fixed and the rest can be determined by firmware (code), this makes a
> great deal of sense.
> In a system where the hardware itself is actually firmware and there
> is little or no startup software to query the device and build a device
> tree dynamically for you, it is of more questionable value.
> Maybe if there is some mechanism existed to have the devicetree
> stored into the FPGA firmware where there is a natural link between the
> implimented hardware and its description. But I am not gathering things
> going in that direction and storing the device tree in the FPGA consumes
> valuable FPGA resources.
No, it doesn't make sense to store is in the FPGA fabric; but if the
design already contains BRAM then it could be placed there and
reclaimed for other purposes after booting. Or anywhere in RAM for
that matter. I don't know how feasible is to load a device tree into
SDRAM at FPGA config time.
If the FPGA bitstream is stored in processor accessable flash, then
the best place would be tacked onto the end of the bitstream file. I
believe Xilinx is planning for EDK to be responsible to generate the
.dts file for the design.
>
> >
> > The board description has to live *somewhere*.
> I have done alot of code for many purposes where the code went to a
> great deal of effort to figure out its own environment dynamically.
> Some (relatively minimal) assumptions have to be made. And some
> balance has to be struck between code complexity and dynamic flexibility.
> though sometimes dynamic detection can be simpler.
> Part of what bothers me about devicetrees, is that the entire design
> seems to presume either standard hardware with minimal permutations, or
> fairly complex firmware - like boot roms to dynamically build atleast
> parts of the device tree.
Ah; I think I see the disconnect we're having. Device trees are not
about, *and never have been about*, device detection. The device tree
is simply the communication medium used to describe the hardware. It
doesn't matter if you choose to use a 100% dynamically generated
device tree from intelligent firmware or a 100% static device tree
blob. All that matters is that the kernel is able to trust the
information handed to it by firmware.
Device detection is not a problem that the device tree is designed to solve.
It is designed to solve the problem of telling the kernel what the
platform looks like (which occurs after the detection stage).
> > That being said, using the device tree does not preclude using
> > platform code to setup devices *where it makes sense to do so*. Many
> > things are one-off board specific things that are not well described
> > with the device tree. For example, we've been debating how to handle
> > on board sound which use common codec chips, but have custom wireup.
> > The codec chip can use a common driver, but the wireup is handled with
> > an ALSA 'fabric' driver that is pretty much a one-off for the board.
> > It probably makes more sense for the fabric driver to be instantiated
> > by the platform code rather than trying to do a full device tree
> > representation.
> >
> So I can hard code some relatively simple stripped devicetree
> that may do little more than specify the CPU, major elements of the
> memory map (maybe), and say the PIC, and then let the BSP, detect things
> like the UART(s), NIC, ...
If devices *are* detectable, then they don't need to be in the device
tree. That's why we don't describe PCI devices in the FDT for
embedded boards. (We *could* but we *don't*) :-)
> > In arch/powerpc
> > we're *still* data driven; it's just that the data is no longer
> > compiled into a static structure. Plus, in the transition we've moved
> > from needed per-device platform data structures to a more expressive
> > format. Also, per-board platform support code has become much simpler
> > (compare ml300.c in arch/ppc with platforms/40x/virtex.c)
> >
>
> I have not pulled your tree in a while - are devicetree's in your
> current git tree ?
arch/powerpc support for Virtex is now in Linus' mainline tree which
will become 2.6.24
>
> Thanks for the remarks.
>
> Again, I am just trying to figure out how to keep my Pico code in
> sync and hopefully make my life better rather than worse at the same time.
> Unfortunately, I am coming to the conclusion that DeviceTrees are
> probably not going to make it that much better,
> but they are probably not going to make it that much worse either.
No, unfortunately they don't deal with the problem you're facing
(which I'm facing also). But it will be solved if we figure out a
sane way to bind the device tree up with the FPGA bitstream without
consuming FPGA resources.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH 14/27] powerpc: ptrace generic resume
From: Roland McGrath @ 2007-11-25 22:04 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20071125215507.4B89226F8C5@magilla.localdomain>
This removes the handling for PTRACE_CONT et al from the powerpc
ptrace code, so it uses the new generic code via ptrace_request.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
arch/powerpc/kernel/ptrace.c | 46 ------------------------------------------
1 files changed, 0 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index b970d79..8b056d2 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -445,52 +445,6 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
break;
}
- case PTRACE_SYSCALL: /* continue and stop at next (return from) syscall */
- case PTRACE_CONT: { /* restart after signal. */
- ret = -EIO;
- if (!valid_signal(data))
- break;
- if (request == PTRACE_SYSCALL)
- set_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
- else
- clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
- child->exit_code = data;
- /* make sure the single step bit is not set. */
- user_disable_single_step(child);
- wake_up_process(child);
- ret = 0;
- break;
- }
-
-/*
- * make the child exit. Best I can do is send it a sigkill.
- * perhaps it should be put in the status that it wants to
- * exit.
- */
- case PTRACE_KILL: {
- ret = 0;
- if (child->exit_state == EXIT_ZOMBIE) /* already dead */
- break;
- child->exit_code = SIGKILL;
- /* make sure the single step bit is not set. */
- user_disable_single_step(child);
- wake_up_process(child);
- break;
- }
-
- case PTRACE_SINGLESTEP: { /* set the trap flag. */
- ret = -EIO;
- if (!valid_signal(data))
- break;
- clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
- user_enable_single_step(child);
- child->exit_code = data;
- /* give it a chance to run. */
- wake_up_process(child);
- ret = 0;
- break;
- }
-
case PTRACE_GET_DEBUGREG: {
ret = -EINVAL;
/* We only support one DABR and no IABRS at the moment */
^ permalink raw reply related
* [PATCH 13/27] powerpc: arch_has_single_step
From: Roland McGrath @ 2007-11-25 22:03 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20071125215507.4B89226F8C5@magilla.localdomain>
This defines the new standard arch_has_single_step macro. It makes the
existing set_single_step and clear_single_step entry points global, and
renames them to the new standard names user_enable_single_step and
user_disable_single_step, respectively.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
arch/powerpc/kernel/ptrace.c | 12 ++++++------
include/asm-powerpc/ptrace.h | 7 +++++++
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 3e17d15..b970d79 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -256,7 +256,7 @@ static int set_evrregs(struct task_struct *task, unsigned long *data)
#endif /* CONFIG_SPE */
-static void set_single_step(struct task_struct *task)
+void user_enable_single_step(struct task_struct *task)
{
struct pt_regs *regs = task->thread.regs;
@@ -271,7 +271,7 @@ static void set_single_step(struct task_struct *task)
set_tsk_thread_flag(task, TIF_SINGLESTEP);
}
-static void clear_single_step(struct task_struct *task)
+void user_disable_single_step(struct task_struct *task)
{
struct pt_regs *regs = task->thread.regs;
@@ -313,7 +313,7 @@ static int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
void ptrace_disable(struct task_struct *child)
{
/* make sure the single step bit is not set. */
- clear_single_step(child);
+ user_disable_single_step(child);
}
/*
@@ -456,7 +456,7 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
child->exit_code = data;
/* make sure the single step bit is not set. */
- clear_single_step(child);
+ user_disable_single_step(child);
wake_up_process(child);
ret = 0;
break;
@@ -473,7 +473,7 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
break;
child->exit_code = SIGKILL;
/* make sure the single step bit is not set. */
- clear_single_step(child);
+ user_disable_single_step(child);
wake_up_process(child);
break;
}
@@ -483,7 +483,7 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
if (!valid_signal(data))
break;
clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
- set_single_step(child);
+ user_enable_single_step(child);
child->exit_code = data;
/* give it a chance to run. */
wake_up_process(child);
diff --git a/include/asm-powerpc/ptrace.h b/include/asm-powerpc/ptrace.h
index 13fccc5..3063363 100644
--- a/include/asm-powerpc/ptrace.h
+++ b/include/asm-powerpc/ptrace.h
@@ -119,6 +119,13 @@ do { \
} while (0)
#endif /* __powerpc64__ */
+/*
+ * These are defined as per linux/ptrace.h, which see.
+ */
+#define arch_has_single_step() (1)
+extern void user_enable_single_step(struct task_struct *);
+extern void user_disable_single_step(struct task_struct *);
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
^ permalink raw reply related
* Re: Access to PCI Expansion ROMs on PPC
From: Benjamin Herrenschmidt @ 2007-11-25 21:34 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <9e4733910711251324y5116d90pab54a1a033d024e3@mail.gmail.com>
> You can dump the PCI config block in /sys with hexdump and see if the
> PCI_COMMAND_MEMORY bit is set. I was also unable to locate where in
> the kernel PCI_COMMAND_MEMORY is being set. It could be that it is set
> by the BIOS at boot on the x86 and not on the ppc.
The kernel doesn't until somebody calls pci_enable_device(). So yes,
that's likely to be your problem.
Ben.
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Jon Smirl @ 2007-11-25 21:24 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1196022000.7195.70.camel@pasglop>
On 11/25/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Now, regarding that user problem, this it totally unrelated as it's a
> "mac" card.
>
> It's possible that it's one of these radeons that disable ROM access via
> a register in which case a quirk is needed to re-enable it.
He says in the first email that when he puts the boards into an x86
box he can read them. The quick turns the ROM back on if the firmware
is turning them off.
In the PPC box the ROMs aren't being run so they would still be in
power on state. I'd expect them to be readable in power-on state.
You can dump the PCI config block in /sys with hexdump and see if the
PCI_COMMAND_MEMORY bit is set. I was also unable to locate where in
the kernel PCI_COMMAND_MEMORY is being set. It could be that it is set
by the BIOS at boot on the x86 and not on the ppc.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH revised 3/4] powerpc: Add EXPORT_SYMBOL_GPL for symbols required by fs_enet and cpm_uart
From: Dan Malek @ 2007-11-25 21:02 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20071125191833.1e76f335@kernel.crashing.org>
On Nov 25, 2007, at 8:18 AM, Vitaly Bordug wrote:
> To prevent using those pointers from within non-GPL modules. kind
> of policy now...
As the original copyright holder of nearly all of this of
this code, I do not wish this be done.
Thanks.
-- Dan
^ permalink raw reply
* Re: PCI to Parallel for PowerPC
From: Benjamin Herrenschmidt @ 2007-11-25 21:09 UTC (permalink / raw)
To: Clemens Koller; +Cc: puyq, linuxppc-embedded, linuxppc-dev, zhang_wei, shekr06
In-Reply-To: <4749AA1B.3050805@anagramm.de>
On Sun, 2007-11-25 at 18:00 +0100, Clemens Koller wrote:
> Put that PCI Card to your host where your stepper was working
> properly to see if it's a hardware issue with that card.
>
> Then it depends on how you control your stepper motor. If you use
> some bit-banging (which I wouldn't recommend) to drive each winding
> and want to have smooth movement, you need a very precise timing
> when it comes to some "more than low-speed" stepper motors,
> otherwise your motors will start to coggle.
> To be precise: you will first have to figure out what leads to
> the effect of "it's not stable". Do you have an Oscilloscope?
Also, we might need to see the code you are using to control the
parallel port, it may be ignoring issues such as PCI write posting or
lacking appropriate memory barriers...
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox