* RE: 83xx: Marking or Allocating Pages as Cache-Inhibited
From: Liu Dave-R63238 @ 2009-03-09 2:33 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: Ben Menchaca, linuxppc-dev
In-Reply-To: <ed82fe3e0903080819g166e5651rd07956d8f26c0f5a@mail.gmail.com>
Timur,
See the section 14.7.1 DMA Description Format at page 14-112
of MPC8315ERM rev.1.
> -----Original Message-----
> From: timur.tabi@gmail.com [mailto:timur.tabi@gmail.com] On=20
> Behalf Of Tabi Timur-B04825
> Sent: Sunday, March 08, 2009 11:20 PM
> To: Liu Dave-R63238
> Cc: Ben Menchaca; linuxppc-dev@ozlabs.org
> Subject: Re: 83xx: Marking or Allocating Pages as Cache-Inhibited
>=20
> On Fri, Mar 6, 2009 at 12:49 AM, Liu Dave-R63238=20
> <DaveLiu@freescale.com> wrote:
> > could you try to set '1' to DMA description bit3?
>=20
> Dave,
>=20
> I'm looking at the 8315e reference manual. What is "DMA=20
> description bit 3"?
>=20
> --
> Timur Tabi
> Linux kernel developer at Freescale
>=20
>=20
^ permalink raw reply
* RE: 83xx: Marking or Allocating Pages as Cache-Inhibited
From: Liu Dave-R63238 @ 2009-03-09 2:56 UTC (permalink / raw)
To: Ben Menchaca; +Cc: linuxppc-dev
In-Reply-To: <64ac01180903060830m1e5927c6y76b8302b0fb68eb6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6343 bytes --]
Hi Ben,
The second issue. you told me "some hosts" has problem,
and some hosts worked well.
what is the problem-hosts?
The issue seems like the hosts did set the NO SNOOP attribute
bit at TLP.
The PEX_DEVICE_CONTROL is standard PCI configuration space
register, it controls the behavior of the initiator's transaction.
For 8315, it is outbound, not inbound transaction.
Thanks, Dave
________________________________
From: Ben Menchaca [mailto:ben.menchaca@gmail.com]
Sent: Saturday, March 07, 2009 12:30 AM
To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating Pages as
Cache-Inhibited
Thank you for your help! That bit resolved all of the RDMA/WDMA
coherency issues on the CSB side...except:
We expose a 1MB region of memory from CSB via a BAR (BAR1, if it
matters) to the Host. This region is also not behaving correctly with
respect to coherency on SOME hosts; again, disabling our cache makes it
work correctly on all hosts. We have set PEX_DEVICE_CONTROL in PCI-E
Config Space (0x54) to 0x2010 (sorry about the endianness below). We
thought that CLEARING the no-snoop bit here would indicate that snooping
was required for this region...is this a similar issue?
- Ben
On Fri, Mar 6, 2009 at 10:12 AM, Ben Menchaca
<ben.menchaca@gmail.com> wrote:
Testing now...it looks like it (almost) works, though!
Why does setting no-snoop cause snooping to work? More on the effect on
setting that bit in a few minutes...need more testing.
ACR is 0x00030300.
- Ben
On Fri, Mar 6, 2009 at 12:30 AM, Liu Dave-R63238
<DaveLiu@freescale.com> wrote:
Did you enable the descriptor bit 3 to have a
try?
________________________________
From: Ben Menchaca
[mailto:ben.menchaca@gmail.com]
Sent: Friday, March 06, 2009 2:10 PM
To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating
Pages as Cache-Inhibited
I can look at ACR morning...although I
can say with a fair amount of certainty that I have not changed it from
the POR value.
I will try enabling No Snoop for CSB in
the descriptor (bit 3, yes?)...this seems a bit counterintuitive to me.
What is the hope regarding these two?
Some combination I am not seeing?
On Thu, Mar 5, 2009 at 11:40 PM, Liu
Dave-R63238 <DaveLiu@freescale.com> wrote:
what is the value of ACR register?
________________________________
From: Ben Menchaca
[mailto:ben.menchaca@gmail.com]
Sent: Friday, March 06, 2009 1:38 PM
To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating
Pages as Cache-Inhibited
1. BAT2 in linux is set to WIMG=0010,
and covers all 64M
2. PEX_DEVICE_CONTROL in PCI-E Config
Space (0x54): 0x1020
3. PEX_xDMA_CTRL is set to 0x00000401
at the initiation of the DMA.
4. OWAR0 is set to 0xFFFFF005, so NSNP
is 0.
5. The DMA descriptor (randomly chosen
when I hit a trigger...just ignore the size...) contains 0002AFF3 at
offset 0, so nosnoops are cleared.
Core is 400MHz, and CSB is 133MHz.
- Ben
On Thu, Mar 5, 2009 at 11:27 PM, Liu
Dave-R63238 <DaveLiu@freescale.com> wrote:
and what settings is DMA description
bit 3?
> -----Original Message-----
> From:
linuxppc-dev-bounces+daveliu=freescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
<mailto:linuxppc-dev-bounces%2Bdaveliu> =freescale.com@ozlabs.org]
> On Behalf Of Liu Dave-R63238
> Sent: Friday, March 06, 2009 1:22 PM
> To: Ben Menchaca;
linuxppc-dev@ozlabs.org
> Subject: RE: 83xx: Marking or
Allocating Pages as Cache-Inhibited
>
> Did you enable the snoop bit at
PEX_WDMA_CTRL[SNOOP] and
> PEX_RDMA_CTRL[SNOOP]?
>
> What is the freq settings? CORE/CSB
bus.
>
> Thanks, Dave
>
> ________________________________
>
> From:
linuxppc-dev-bounces+daveliu=freescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
<mailto:linuxppc-dev-bounces%2Bdaveliu> =freescale.com@ozlabs.org]
> On Behalf Of Ben Menchaca
> Sent: Friday, March 06, 2009
12:33 PM
> To: linuxppc-dev@ozlabs.org
> Subject: 83xx: Marking or
Allocating Pages as Cache-Inhibited
>
>
> I am working on a Freescale
8314e design, and the
> embedded device is configured as a
PCI-e endpoint running a
> 2.6.27-5 kernel. For context, we have
written a kernel
> module which, among other things, uses
the RDMA/WDMA engine
> in the PCI-e IP block. On the host
side, these DMAs are
> coherent. However, on the embedded
side, things are quite a
> bit less rosy; we must manually
flush/invalidate cache lines
> for WDMA/RDMAs to occur successfully.
After speaking with
> (several) FAEs at Freescale, we
believe there is a
> configuration issue that is the cause,
but we have yet to
> have anyone successfully point to it.
>
> Disabling the data cache
altogether resolves the issue
> entirely, but of course, also
completely tanks performance.
> As a temporary workaround, I would
like to simply mark the
> pages (obtained currently via
dma_alloc_coherent) involved as
> cache-inhibited. I have attempted to
do this via some
> snippets remaining in fec.c
(va_to_pte, uncache_pte to set
> _PAGE_NO_CACHE, flush_tlb_page, then
unmap_pte), but this is
> almost certainly braindead; va_to_pte
is not a part of the
> 83xx source, as far as I can tell; 8xx
only.
>
> A quick pointer in the correct
direction for marking
> pages as cache-inhibited on a 2.6.27-5
kernel would be
> appreciated, or if my approach to a
workaround is flawed, a
> pointer to the correct way would be
great.
>
> Ben Menchaca
>
>
>
_______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
[-- Attachment #2: Type: text/html, Size: 14763 bytes --]
^ permalink raw reply
* Re: 83xx: Marking or Allocating Pages as Cache-Inhibited
From: Ben Menchaca @ 2009-03-09 3:27 UTC (permalink / raw)
To: Liu Dave-R63238; +Cc: linuxppc-dev
In-Reply-To: <D7CCA83BB0796C49BC0BB53B6AB1208916D077@zch01exm21.fsl.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 7201 bytes --]
The only problem host found so far is a newer Asus 970FX motherboard,
regardless of OS.
We are seeing that some time after LTSSM finishes, but long before OS load,
our PEX_DEVICE_CONTROL register is changed. On the "working" motherboards,
NO_SNOOP is enabled; if I read the spec correctly, this means that TLPs with
no-snoop are permitted. On the non-working motherboards, NO_SNOOP is
disabled; this is supposed to mean that TLPs with no-snoop are not permitted
(again, if I understand correctly). Is it possible that there has been
another misinterpretation of this bit? Something regarding the generation
of snoops on CSB when it is cleared?
This bit could be a complete red herring; it was one of the few differences
in the config space, however, so it was my best guess.
- Ben
On Sun, Mar 8, 2009 at 9:56 PM, Liu Dave-R63238 <DaveLiu@freescale.com>wrote:
> Hi Ben,
>
> The second issue. you told me "some hosts" has problem,
> and some hosts worked well.
>
> what is the problem-hosts?
>
> The issue seems like the hosts did set the NO SNOOP attribute
> bit at TLP.
>
> The PEX_DEVICE_CONTROL is standard PCI configuration space
> register, it controls the behavior of the initiator's transaction.
> For 8315, it is outbound, not inbound transaction.
>
> Thanks, Dave
>
> ------------------------------
> *From:* Ben Menchaca [mailto:ben.menchaca@gmail.com]
> *Sent:* Saturday, March 07, 2009 12:30 AM
> *To:* Liu Dave-R63238
> *Cc:* linuxppc-dev@ozlabs.org
> *Subject:* Re: 83xx: Marking or Allocating Pages as Cache-Inhibited
>
> Thank you for your help! That bit resolved all of the RDMA/WDMA coherency
> issues on the CSB side...except:
>
> We expose a 1MB region of memory from CSB via a BAR (BAR1, if it matters)
> to the Host. This region is also not behaving correctly with respect to
> coherency on SOME hosts; again, disabling our cache makes it work correctly
> on all hosts. We have set PEX_DEVICE_CONTROL in PCI-E Config Space (0x54)
> to 0x2010 (sorry about the endianness below). We thought that CLEARING
> the no-snoop bit here would indicate that snooping was required for this
> region...is this a similar issue?
>
> - Ben
>
> On Fri, Mar 6, 2009 at 10:12 AM, Ben Menchaca <ben.menchaca@gmail.com>wrote:
>
>> Testing now...it looks like it (almost) works, though! Why does setting
>> no-snoop cause snooping to work? More on the effect on setting that bit in
>> a few minutes...need more testing.
>>
>> ACR is 0x00030300.
>>
>> - Ben
>>
>>
>> On Fri, Mar 6, 2009 at 12:30 AM, Liu Dave-R63238 <DaveLiu@freescale.com>wrote:
>>
>>> Did you enable the descriptor bit 3 to have a try?
>>>
>>> ------------------------------
>>> *From:* Ben Menchaca [mailto:ben.menchaca@gmail.com]
>>> *Sent:* Friday, March 06, 2009 2:10 PM
>>>
>>> *To:* Liu Dave-R63238
>>> *Cc:* linuxppc-dev@ozlabs.org
>>> *Subject:* Re: 83xx: Marking or Allocating Pages as Cache-Inhibited
>>>
>>> I can look at ACR morning...although I can say with a fair amount of
>>> certainty that I have not changed it from the POR value.
>>>
>>> I will try enabling No Snoop for CSB in the descriptor (bit 3,
>>> yes?)...this seems a bit counterintuitive to me.
>>>
>>> What is the hope regarding these two? Some combination I am not seeing?
>>>
>>>
>>> On Thu, Mar 5, 2009 at 11:40 PM, Liu Dave-R63238 <DaveLiu@freescale.com>wrote:
>>>
>>>> what is the value of ACR register?
>>>>
>>>> ------------------------------
>>>> *From:* Ben Menchaca [mailto:ben.menchaca@gmail.com]
>>>> *Sent:* Friday, March 06, 2009 1:38 PM
>>>> *To:* Liu Dave-R63238
>>>> *Cc:* linuxppc-dev@ozlabs.org
>>>> *Subject:* Re: 83xx: Marking or Allocating Pages as Cache-Inhibited
>>>>
>>>> 1. BAT2 in linux is set to WIMG=0010, and covers all 64M
>>>> 2. PEX_DEVICE_CONTROL in PCI-E Config Space (0x54): 0x1020
>>>> 3. PEX_xDMA_CTRL is set to 0x00000401 at the initiation of the DMA.
>>>> 4. OWAR0 is set to 0xFFFFF005, so NSNP is 0.
>>>> 5. The DMA descriptor (randomly chosen when I hit a trigger...just
>>>> ignore the size...) contains 0002AFF3 at offset 0, so nosnoops are cleared.
>>>>
>>>>
>>>> Core is 400MHz, and CSB is 133MHz.
>>>>
>>>> - Ben
>>>>
>>>> On Thu, Mar 5, 2009 at 11:27 PM, Liu Dave-R63238 <DaveLiu@freescale.com
>>>> > wrote:
>>>>
>>>>> and what settings is DMA description bit 3?
>>>>>
>>>>> > -----Original Message-----
>>>>> > From: linuxppc-dev-bounces+daveliu=freescale.com@ozlabs.org
>>>>> > [mailto:linuxppc-dev-bounces+daveliu<linuxppc-dev-bounces%2Bdaveliu>
>>>>> =freescale.com@ozlabs.org]
>>>>> > On Behalf Of Liu Dave-R63238
>>>>> > Sent: Friday, March 06, 2009 1:22 PM
>>>>> > To: Ben Menchaca; linuxppc-dev@ozlabs.org
>>>>> > Subject: RE: 83xx: Marking or Allocating Pages as Cache-Inhibited
>>>>> >
>>>>> > Did you enable the snoop bit at PEX_WDMA_CTRL[SNOOP] and
>>>>> > PEX_RDMA_CTRL[SNOOP]?
>>>>> >
>>>>> > What is the freq settings? CORE/CSB bus.
>>>>> >
>>>>> > Thanks, Dave
>>>>> >
>>>>> > ________________________________
>>>>> >
>>>>> > From: linuxppc-dev-bounces+daveliu=freescale.com@ozlabs.org
>>>>> > [mailto:linuxppc-dev-bounces+daveliu<linuxppc-dev-bounces%2Bdaveliu>
>>>>> =freescale.com@ozlabs.org]
>>>>> > On Behalf Of Ben Menchaca
>>>>> > Sent: Friday, March 06, 2009 12:33 PM
>>>>> > To: linuxppc-dev@ozlabs.org
>>>>> > Subject: 83xx: Marking or Allocating Pages as Cache-Inhibited
>>>>> >
>>>>> >
>>>>> > I am working on a Freescale 8314e design, and the
>>>>> > embedded device is configured as a PCI-e endpoint running a
>>>>> > 2.6.27-5 kernel. For context, we have written a kernel
>>>>> > module which, among other things, uses the RDMA/WDMA engine
>>>>> > in the PCI-e IP block. On the host side, these DMAs are
>>>>> > coherent. However, on the embedded side, things are quite a
>>>>> > bit less rosy; we must manually flush/invalidate cache lines
>>>>> > for WDMA/RDMAs to occur successfully. After speaking with
>>>>> > (several) FAEs at Freescale, we believe there is a
>>>>> > configuration issue that is the cause, but we have yet to
>>>>> > have anyone successfully point to it.
>>>>> >
>>>>> > Disabling the data cache altogether resolves the issue
>>>>> > entirely, but of course, also completely tanks performance.
>>>>> > As a temporary workaround, I would like to simply mark the
>>>>> > pages (obtained currently via dma_alloc_coherent) involved as
>>>>> > cache-inhibited. I have attempted to do this via some
>>>>> > snippets remaining in fec.c (va_to_pte, uncache_pte to set
>>>>> > _PAGE_NO_CACHE, flush_tlb_page, then unmap_pte), but this is
>>>>> > almost certainly braindead; va_to_pte is not a part of the
>>>>> > 83xx source, as far as I can tell; 8xx only.
>>>>> >
>>>>> > A quick pointer in the correct direction for marking
>>>>> > pages as cache-inhibited on a 2.6.27-5 kernel would be
>>>>> > appreciated, or if my approach to a workaround is flawed, a
>>>>> > pointer to the correct way would be great.
>>>>> >
>>>>> > Ben Menchaca
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > Linuxppc-dev mailing list
>>>>> > Linuxppc-dev@ozlabs.org
>>>>> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>>>> >
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
>
[-- Attachment #2: Type: text/html, Size: 14998 bytes --]
^ permalink raw reply
* fasync (Async Notification)
From: Vijay Nikam @ 2009-03-09 6:33 UTC (permalink / raw)
To: linuxppc-dev
Hello All,
I have mpc8313erdb eval board and kernel 2..6.20 on it. I have written
GPIO driver and have enabled Async Notification (SIGIO)
In the driver I am generating interrupt whenever the status of GPIO
pin (GPIO 2) changes, this part is working correct (as soon as the
GPIO pin status changes the interrupt is generated).
Then I included Async Notification to notify the particluar user space
process (to the process which I want to) by using fasync method,
kill_fasync is called in Interrupt handler and also the kill_fasync
signals the particular process and the Signal handler executes and
says SIGIO is received.
But the problem is, if I change GPIO pin status twice then two
interrupts are generated but I get SIGIO Async Notification only once.
Whereras I am expecting that I should get twice SIGIO Async
Notification (Theory says the same).
Could anyone please let me what is the reason for this ? ? ?
Kindly please acknowledge ... thank you ...
Kind Regards,
Vijay Nikam
^ permalink raw reply
* help:About USB_EHCI_ROOT_HUB_TT in MPC8347 USB development
From: Cris Gong @ 2009-03-09 6:29 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 28679 bytes --]
Greetings,
I have an mpc8347 board here.The linux kernel version is 2.6.19.2.
MPC8347 MPH0 is connectted to a FS/LS PHY(Philips ISP1105),I insert a
USB 2.0 storage disk.
I add initial usb_platform_data in
linux_2.6.19.2/arch/ppc/syslib/mpc83xx_devices.c
static struct fsl_usb2_platform_data mpc83xx_usb_platform_data = {
.operating_mode = FSL_USB2_MPH_HOST,
.phy_mode = FSL_USB2_PHY_SERIAL,
.port_enables = FSL_USB2_PORT0_ENABLED,
};
In kernel config,I have set CONFIG_USB_EHCI_ROOT_HUB_TT to y(get rid of
EXPERIMENTAL)
Why does it report error -32?(the Macro is EPIPE)
The following is capture file.
## Booting image at 01000000 ...
Loading image:
Image version:
Created: 2009-03-06 7:52:17 UTC
Verifying Checksum ... OK
Uncompressing Multi-File Image ... OK
Loading Ramdisk to 03e8b000, end 04000000 ... OK
Linux version 2.6.19.2-0.1 (cris.gong@atan-cat.accton.com.cn) (gcc version
4.0.0 (DENX ELDK 4.1 4.0.0)) #1 PREEMPT Fri Mar 6 15:48:37 CST 2009
Zone PFN ranges:
DMA 0 -> 125952
Normal 125952 -> 125952
early_node_map[1] active PFN ranges
0: 0 -> 125952
Built 1 zonelists. Total pages: 124968
Kernel command line: root=/dev/ram rw console=ttyS0,115200 mem=492M
dbg_start=0x1fc00914 dbg_size=524288
IPIC (128 IRQ sources, 8 External IRQs) at fe000700
PID hash table entries: 2048 (order: 11, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 494464k available (2036k kernel code, 1192k data, 144k init, 0k
highmem)
Mount-cache hash table entries: 512
checking if image is initramfs...it isn't (bad gzip magic numbers); looks
like an initrd
Freeing initrd memory: 1492k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler cfq registered (default)
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 9) is a 16550A
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 10) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: loaded (max 8 devices)
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.2, 00:08:07:00:00:39
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.2, 85:e1:89:82:72:6f
eth1: Running with NAPI enabled
eth1: 256/256 RX/TX BD ring size
Common Flash mtd init ...
physmap platform flash device: 04000000 at fc000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
physmap-flash.0: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
Using physmap partition information
Creating 8 MTD partitions on "physmap-flash.0":
0x03f00000-0x03f80000 : "loader"
0x03c00000-0x03c20000 : "partitiontable"
0x03c20000-0x03c40000 : "environment"
0x03c40000-0x03c60000 : "filemapping"
0x03c60000-0x03c80000 : "hwinfo"
0x00c00000-0x01000000 : "userdata"
0x01000000-0x02000000 : "runtime0"
0x02000000-0x03000000 : "runtime1"
fsl-ehci fsl-ehci.1: No platform data for fsl-ehci.1.
fsl-ehci fsl-ehci.2: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.2: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.2: irq 39, io base 0xe0022000
fsl-ehci fsl-ehci.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: Product: Freescale On-Chip EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.19.2-0.1 ehci_hcd
usb usb1: SerialNumber: fsl-ehci.2
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usb 1-1: new full speed USB device using fsl-ehci and address 2
usb 1-1: device descriptor read/64, error -32
usb 1-1: device descriptor read/64, error -32
usb 1-1: new full speed USB device using fsl-ehci and address 3
usb 1-1: device descriptor read/64, error -32
usb 1-1: device descriptor read/64, error -32
usb 1-1: new full speed USB device using fsl-ehci and address 4
usb 1-1: device not accepting address 4, error -32
usb 1-1: new full speed USB device using fsl-ehci and address 5
usb 1-1: device not accepting address 5, error -32
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
i2c /dev entries driver
oprofile: using timer interrupt.
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RAMDISK: cramfs filesystem found at block 0
RAMDISK: Loading 1492KiB [1 disk] into ram disk... done.
VFS: Mounted root (cramfs filesystem) readonly.
Freeing unused kernel memory: 144k init
Running rc.accton.init ...
Please press Enter to activate this console.
root:~> echo 8 > /proc/sys/kernel/printk
root:~> hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0002
fsl-ehci fsl-ehci.2: GetStatus port 1 status cc001002 POWER sig=se0 CSC
hub 1-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0002
fsl-ehci fsl-ehci.2: GetStatus port 1 status c0001803 POWER sig=j CSC
CONNECT
hub 1-0:1.0: port 1, status 0101, change 0001, 12 Mb/s
hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101
fsl-ehci fsl-ehci.2: port 1 high speed
fsl-ehci fsl-ehci.2: GetStatus port 1 status c0001005 POWER sig=se0 PE
CONNECT
usb 1-1: new full speed USB device using fsl-ehci and address 6
fsl-ehci fsl-ehci.2: port 1 high speed
fsl-ehci fsl-ehci.2: GetStatus port 1 status c0001005 POWER sig=se0 PE
CONNECT
usb 1-1: device descriptor read/64, error -32
usb 1-1: device descriptor read/64, error -32
usb 1-1: new full speed USB device using fsl-ehci and address 7
fsl-ehci fsl-ehci.2: port 1 high speed
fsl-ehci fsl-ehci.2: GetStatus port 1 status c0001005 POWER sig=se0 PE
CONNECT
usb 1-1: device descriptor read/64, error -32
usb 1-1: device descriptor read/64, error -32
usb 1-1: new full speed USB device using fsl-ehci and address 8
usb 1-1: device not accepting address 8, error -32
usb 1-1: new full speed USB device using fsl-ehci and address 9
usb 1-1: device not accepting address 9, error -32
The following is my kernel configure file.
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.19.2-0.1
# Wed Mar 4 13:35:26 2009
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# Code maturity level options
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_EXTRA_PASS=y
# CONFIG_HOTPLUG is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
# CONFIG_VM_EVENT_COUNTERS is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
#
# Processor
#
CONFIG_6xx=y
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_8xx is not set
# CONFIG_E200 is not set
# CONFIG_E500 is not set
CONFIG_PPC_FPU=y
# CONFIG_CPU_FREQ is not set
# CONFIG_WANT_EARLY_SERIAL is not set
CONFIG_PPC_GEN550=y
# CONFIG_ES4626H is not set
CONFIG_PPC_STD_MMU=y
#
# Platform options
#
# CONFIG_PPC_PREP is not set
# CONFIG_APUS is not set
# CONFIG_KATANA is not set
# CONFIG_WILLOW is not set
# CONFIG_CPCI690 is not set
# CONFIG_POWERPMC250 is not set
# CONFIG_CHESTNUT is not set
# CONFIG_SPRUCE is not set
# CONFIG_HDPU is not set
# CONFIG_EV64260 is not set
# CONFIG_LOPEC is not set
# CONFIG_MVME5100 is not set
# CONFIG_PPLUS is not set
# CONFIG_PRPMC750 is not set
# CONFIG_PRPMC800 is not set
# CONFIG_SANDPOINT is not set
# CONFIG_RADSTONE_PPC7D is not set
# CONFIG_PAL4 is not set
# CONFIG_GEMINI is not set
# CONFIG_EST8260 is not set
# CONFIG_SBC82xx is not set
# CONFIG_SBS8260 is not set
# CONFIG_RPX8260 is not set
# CONFIG_TQM8260 is not set
# CONFIG_PM82X is not set
# CONFIG_ADS8272_PLATFORM is not set
CONFIG_ASF4528B=y
# CONFIG_PQ2FADS is not set
# CONFIG_LITE5200 is not set
# CONFIG_EV64360 is not set
# CONFIG_TQM834x is not set
# CONFIG_TQM8272 is not set
CONFIG_MPC834x_SYS=y
CONFIG_83xx=y
CONFIG_MPC834x=y
CONFIG_PPC_83xx=y
# CONFIG_SMP is not set
# CONFIG_HIGHMEM is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
# CONFIG_CMDLINE_BOOL is not set
# CONFIG_PM is not set
CONFIG_SECCOMP=y
CONFIG_ISA_DMA_API=y
#
# Bus options
#
CONFIG_GENERIC_ISA_DMA=y
# CONFIG_PPC_I8259 is not set
CONFIG_PPC_INDIRECT_PCI=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
# CONFIG_MPC83xx_PCI2 is not set
# CONFIG_PCI_DEBUG is not set
#
# PCCARD (PCMCIA/CardBus) support
#
#
# PCI Express support
#
#
# Advanced setup
#
CONFIG_ADVANCED_OPTIONS=y
CONFIG_HIGHMEM_START=0xfe000000
# CONFIG_LOWMEM_SIZE_BOOL is not set
CONFIG_LOWMEM_SIZE=0x30000000
# CONFIG_KERNEL_START_BOOL is not set
CONFIG_KERNEL_START=0xc0000000
# CONFIG_TASK_SIZE_BOOL is not set
CONFIG_TASK_SIZE=0x80000000
# CONFIG_BOOT_LOAD_BOOL is not set
CONFIG_BOOT_LOAD=0x00800000
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_CUBIC=y
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
# CONFIG_DEFAULT_BIC is not set
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_SYS_HYPERVISOR is not set
#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=0xFE000000
CONFIG_MTD_PHYSMAP_LEN=0x02000000
CONFIG_MTD_PHYSMAP_BANKWIDTH=1
# CONFIG_MTD_PLATRAM is not set
# CONFIG_MTD_ECN430_FB2_FLASH is not set
CONFIG_MTD_ASF4528B_FLASH=y
#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set
#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set
#
# OneNAND Flash Device Drivers
#
# CONFIG_MTD_ONENAND is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play support
#
#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=32768
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
#
# Misc devices
#
# CONFIG_SGI_IOC4 is not set
#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
# CONFIG_ATA is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set
#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Macintosh device drivers
#
# CONFIG_WINDFARM is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# PHY device support
#
CONFIG_PHYLIB=y
#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_FIXED_PHY is not set
#
# Ethernet (10 or 100Mbit)
#
# CONFIG_NET_ETHERNET is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
CONFIG_GIANFAR=y
CONFIG_GFAR_NAPI=y
# CONFIG_QLA3XXX is not set
#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
# CONFIG_INPUT is not set
#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
# CONFIG_VT is not set
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_GEN_RTC=y
# CONFIG_GEN_RTC_X is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_RAW_DRIVER is not set
#
# TPM devices
#
#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
#
# I2C Algorithms
#
# CONFIG_I2C_ALGOBIT is not set
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_MPC=y
# CONFIG_I2C_MPC8260 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set
#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_M41T00 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
# CONFIG_USB_DABUSB is not set
#
# Graphics support
#
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_OHCI_HCD is not set
# CONFIG_USB_UHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set
#
# USB Input Devices
#
# CONFIG_USB_HID is not set
#
# USB HID Boot Protocol drivers
#
#
# USB Imaging devices
#
# CONFIG_USB_MICROTEK is not set
#
# USB Network Adapters
#
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_USBNET_MII is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_MON is not set
#
# USB port drivers
#
#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
#
# USB DSL modem support
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# LED devices
#
# CONFIG_NEW_LEDS is not set
#
# LED drivers
#
#
# LED Triggers
#
#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set
#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
#
# Real Time Clock
#
#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set
#
# DMA Clients
#
#
# DMA Devices
#
#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
#
# Miscellaneous filesystems
#
# CONFIG_HFSPLUS_FS is not set
# CONFIG_JFFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
CONFIG_JFFS2_RUBIN=y
# CONFIG_JFFS2_CMODE_NONE is not set
CONFIG_JFFS2_CMODE_PRIORITY=y
# CONFIG_JFFS2_CMODE_SIZE is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=y
CONFIG_NLS_CODEPAGE_775=y
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_CODEPAGE_852=y
CONFIG_NLS_CODEPAGE_855=y
CONFIG_NLS_CODEPAGE_857=y
CONFIG_NLS_CODEPAGE_860=y
CONFIG_NLS_CODEPAGE_861=y
CONFIG_NLS_CODEPAGE_862=y
CONFIG_NLS_CODEPAGE_863=y
CONFIG_NLS_CODEPAGE_864=y
CONFIG_NLS_CODEPAGE_865=y
CONFIG_NLS_CODEPAGE_866=y
CONFIG_NLS_CODEPAGE_869=y
CONFIG_NLS_CODEPAGE_936=y
CONFIG_NLS_CODEPAGE_950=y
CONFIG_NLS_CODEPAGE_932=y
CONFIG_NLS_CODEPAGE_949=y
CONFIG_NLS_CODEPAGE_874=y
CONFIG_NLS_ISO8859_8=y
CONFIG_NLS_CODEPAGE_1250=y
CONFIG_NLS_CODEPAGE_1251=y
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=y
CONFIG_NLS_ISO8859_3=y
CONFIG_NLS_ISO8859_4=y
CONFIG_NLS_ISO8859_5=y
CONFIG_NLS_ISO8859_6=y
CONFIG_NLS_ISO8859_7=y
CONFIG_NLS_ISO8859_9=y
CONFIG_NLS_ISO8859_13=y
CONFIG_NLS_ISO8859_14=y
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_KOI8_R=y
CONFIG_NLS_KOI8_U=y
CONFIG_NLS_UTF8=y
#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_MUST_CHECK=y
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_RWSEMS is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
CONFIG_FORCED_INLINING=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_KGDB is not set
# CONFIG_XMON is not set
# CONFIG_BDI_SWITCH is not set
# CONFIG_SERIAL_TEXT_DEBUG is not set
# CONFIG_ICE_DEBUG is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
# CONFIG_CRYPTO is not set
Best Regards!
[-- Attachment #2: Type: text/html, Size: 77856 bytes --]
^ permalink raw reply
* Machine check in 4xx ethernet driver
From: Felix Radensky @ 2009-03-09 7:47 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm getting machine check exception when trying to dump
emac registers on 405EX Kilauea board. The kernel is 2.6.29-rc7
The problem seems not new, I can reproduce it on 2.6.25 Denx kernel
-bash-3.2# ethtool -d eth0
Data machine check in kernel mode.
Oops: Machine check, sig: 7 [#1]
Kilauea
Modules linked in:
NIP: c000e240 LR: c0158358 CTR: 00000004
REGS: cfffdf50 TRAP: 0202 Not tainted (2.6.29-rc7)
MSR: 00029030 <EE,ME,CE,IR,DR> CR: 22002044 XER: 2000005f
TASK = cfa79740[1011] 'ethtool' THREAD: cfa82000
GPR00: 00000001 cfa83d10 cfa79740 cf8d7a34 d105696c 00000004 cfa83d40
00000000
GPR08: 00000000 0000001b 00000004 00000004 22002022 1005f4d0 10010000
1000d9c4
GPR16: 1000d9bc 1000d9b4 1000fbec 10057650 100118a4 10010000 1000da10
100570ec
GPR24: bf90f790 00000000 cfa83d38 cf8d7800 10058008 cf8d7800 cf8d79c0
cf811360
NIP [c000e240] _memcpy_fromio+0x9c/0xc4
LR [c0158358] emac_ethtool_get_regs+0x68/0xc4
Call Trace:
[cfa83d10] [c015831c] emac_ethtool_get_regs+0x2c/0xc4 (unreliable)
[cfa83d30] [c017ed00] ethtool_get_regs+0xf8/0x1f8
[cfa83d60] [c018036c] dev_ethtool+0x10f4/0x13ac
[cfa83df0] [c017d7dc] dev_ioctl+0x430/0x700
[cfa83e70] [c016ad80] sock_ioctl+0x80/0x2ec
[cfa83e90] [c0088104] vfs_ioctl+0x34/0x98
[cfa83ea0] [c0088550] do_vfs_ioctl+0x3c0/0x734
[cfa83f10] [c0088904] sys_ioctl+0x40/0x74
[cfa83f40] [c000eb60] ret_from_syscall+0x0/0x3c
Instruction dump:
419c004c 80040000 90030000 7c0006ac 38840004 38630004 38a5fffc 4200ffe8
2f050000 41baffb4 7ca903a6 88040000 <98030000> 7c0006ac 38840001 38630001
---[ end trace 075752cbf5bce2a1 ]---
Bus error
Felix.
--
View this message in context: http://www.nabble.com/Machine-check-in-4xx-ethernet-driver-tp22408005p22408005.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Davicom DM9000A on MPC5200B (powerpc) works using a dirty offsetting and byte trick
From: Henk Stegeman @ 2009-03-09 9:32 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-dev
In-Reply-To: <200903071109.49726.jbe@pengutronix.de>
Juergen,
I don't understand how this would work,
Now I do one byte-swap, which works.
-I byteswap in software, for 16-bit cycles by byte swapping and for 8
bit cycles by adding an offset of 1.
(The byte swapping on the chipselect is off)
Your advice includes two byteswaps, one by re-routing the data bus and
one by enabling the byte swap on the chip-select.
Or does one of them not really swap bytes?
Henk
On Sat, Mar 7, 2009 at 11:09 AM, Juergen Beisert <jbe@pengutronix.de> wrote=
:
> Henk,
>
> On Freitag, 20. Februar 2009, Henk Stegeman wrote:
>> - Any suggestions to what could be wrong here? Or does the MPC5200 in
>> this case only byte swap u16 reads, but a u8 read is unchanged?
>
> You should not follow the Freescale bus signal names when you connect you=
r
> external little endian device. Otherwise the offsets are always wrong.
>
> Do it in this way instead:
>
> =A0 =A0MPC =A0 =A0 =A0 =A0 =A0LE Device
> =A0D[0..7] =A0 <-> =A0D[24..31]
> =A0D[8..15] =A0<-> =A0D[16..23]
> =A0D[16..23] <-> =A0D[8..15]
> =A0D[24..31] <-> =A0D[0..7]
>
> If you connect your device in such a way, just enable CS's byte swap feat=
ure
> depending on your bus size and you are done (no additional software
> manipulation required). Now you can write bytes, words or longs and you w=
ill
> always write the correct data into the corresponding device register.
>
> Hope it helps
> Juergen
>
> --
> Pengutronix e.K. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0| Juergen Beisert =A0 =A0 =A0 =A0 =A0 =A0 |
> Linux Solutions for Science and Industry =A0 =A0 =A0| Phone: +49-8766-939=
228 =A0 =A0 |
> Vertretung Sued/Muenchen, Germany =A0 =A0 =A0 =A0 =A0 =A0 | Fax: =A0 +49-=
5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686 =A0 =A0 =A0 =A0 =A0 =A0 =A0| http://www.=
pengutronix.de/ =A0|
>
^ permalink raw reply
* RE: [PATCH] powerpc/usb: Fix 440EPx USBH_3 & USBH_5 EHCI errata
From: - Reyneke @ 2009-03-09 10:01 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, dbrownell, stern
In-Reply-To: <1236463245.7260.170.camel@pasglop>
> Please provide a valid email address here.
New email client helpfully stripped out the address...
>> called in a context where you can't iomap ? (ie with a spinlock held).
That is indeed the case. Keeping ehci generic is a valid point=2C but becau=
se of the above I don't think adding a "hook" is going to work. I'll take a=
look at the *platform_private option and re-post - this would also allow f=
or better runtime checking=2C as you suggested.
Cheers
Jan
----------------------------------
> On Fri=2C 2009-03-06 at 11:30 +0000=2C - Reyneke wrote:
>> Patch applies to 440EPx devices in USB EHCI host mode (USB 2.0).
>>
>>>From the 440EPx errata:
>>
>> USBH_3: Host hangs after underrun or overrun occurs
>> USBH_5: EHCI0_INSNREGxx registers are reset by a Soft or Light Host Cont=
roller Reset
>>
>> Workround for USBH_3 is to enable Break Memory Transfer (BMT) in INSNREG=
3. But the controller is reset after this fix is applied=2C and thus the cu=
rrent workround is lost. The following short patch ensures INSNREG3 is corr=
ectly set after reset.
>
>> Signed-off-by: Jan Reyneke
>
> Please provide a valid email address here.
>
>> ---
>
> A few issues here. First=2C it would be preferable to have this in the
> ehci-ppc-of.c file. If you can't stick that in such a place that it will
> be called after ehci_reset=2C then maybe you can add a reset "hook" so
> that ehci-ppc-of.c gets to wrap the real ehci_reset().
>
> Also=2C while the ifdef CONFIG_440EPX is good to prevent building the cod=
e
> on machines that don't need it=2C it's also not enough. We allow building
> kernels that support multiple boards and SoC's within the same major CPU
> family and thus you -also- need runtime detection. Either using a quirk
> (I think the USB drivers have quirk flags) or just always doing the
> of_device_is_compatible() thingy which is yet another reason for finding
> a way to move that up into ehci-ppc-of.c
>
> That would also avoid some duplication...
>
>
> So if you manage to move the quirk here=2C you can thus re-use the
> existing code=2C or is the reset always called in a context where you
> can't iomap ? (ie with a spinlock held).
>
> In any case=2C I don't like adding a specific field to the generic ehci
> structure like that. If that's what it takes=2C add a void
> *platform_private to it=2C and use -that- to stick a host specific data
> structure=2C but for something not performance sensitive such as a reset=
=2C
> if you can get away with always mapping/unmapping=2C it's probably better=
.
>
> Cheers=2C
> Ben.
>
>
_________________________________________________________________
View your Twitter and Flickr updates from one place =96 Learn more!
http://clk.atdmt.com/UKM/go/137984870/direct/01/=
^ permalink raw reply
* Re: Machine check in 4xx ethernet driver
From: Josh Boyer @ 2009-03-09 10:38 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev
In-Reply-To: <22408005.post@talk.nabble.com>
On Mon, Mar 09, 2009 at 12:47:02AM -0700, Felix Radensky wrote:
>
>Hi,
>
>I'm getting machine check exception when trying to dump
>emac registers on 405EX Kilauea board. The kernel is 2.6.29-rc7
>The problem seems not new, I can reproduce it on 2.6.25 Denx kernel
I've not looked at what that code path does, but the EMAC regs are
in DCR space, not MMIO. Using memcpy_fromio there seems odd.
josh
^ permalink raw reply
* Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device
From: Geert Uytterhoeven @ 2009-03-09 10:43 UTC (permalink / raw)
To: Jens Axboe
Cc: Arnd Bergmann, Linux Kernel Development, Jim Paris,
Linux/PPC Development, linux-mtd, Vivien Chappelier,
David Woodhouse, Cell Broadband Engine OSS Development
In-Reply-To: <20090306190350.GD11787@kernel.dk>
On Fri, 6 Mar 2009, Jens Axboe wrote:
> On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > > > > But then I noticed ps3vram_make_request() may be called concurrently,
> > > > > > so I had to add a mutex to avoid data corruption. This slows the
> > > > > > driver down, and in the end, the version with a thread turns out to be
> > > > > > ca. 1% faster. The version without a thread is about 50 lines less
> > > > > > code, though.
> > > > >
> > > > > That is correct, ->make_request_fn may get reentered. I'm not surprised
> > > > > that performance dropped if you just shoved everything under a mutex.
> > > > > You could be a little more smart and queue concurrent bio's for
> > > > > processing when the current one is complete though, there are several
> > > > > approaches there that be a lot faster than going all the way through the
> > > > > IO stack and scheduler just to avoid concurrency.
> > > >
> > > > Yes, using a spinlock and queueing requests on a list if the driver is
> > > > busy can be done after 2.6.29...
> > >
> > > Certainly. Even just replacing your current mutex with a spinlock during
> > > the memcpy() would surely be a lot faster. Or even just grabbing the
> > > mutex before calling into the write for the duration of the bio. The way
> > > you do it is certain context switch death :-)
> >
> > It's not just the memcpy(). ps3vram_{up,down}load() call msleep(), so
> > I cannot use a spinlock.
>
> Ah right, I hadn't looked close enough. But putting the mutex_lock()
> outside of the bio_for_each_segment() is going to be much faster than
> getting/releasing it for each segment.
It doesn't seem to make any measurable difference, so I'm gonna leave it for
now.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device
From: Jens Axboe @ 2009-03-09 10:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Linux Kernel Development, Jim Paris,
Linux/PPC Development, linux-mtd, Vivien Chappelier,
David Woodhouse, Cell Broadband Engine OSS Development
In-Reply-To: <alpine.LRH.2.00.0903091142500.19484@vixen.sonytel.be>
On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> On Fri, 6 Mar 2009, Jens Axboe wrote:
> > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > > > > > But then I noticed ps3vram_make_request() may be called concurrently,
> > > > > > > so I had to add a mutex to avoid data corruption. This slows the
> > > > > > > driver down, and in the end, the version with a thread turns out to be
> > > > > > > ca. 1% faster. The version without a thread is about 50 lines less
> > > > > > > code, though.
> > > > > >
> > > > > > That is correct, ->make_request_fn may get reentered. I'm not surprised
> > > > > > that performance dropped if you just shoved everything under a mutex.
> > > > > > You could be a little more smart and queue concurrent bio's for
> > > > > > processing when the current one is complete though, there are several
> > > > > > approaches there that be a lot faster than going all the way through the
> > > > > > IO stack and scheduler just to avoid concurrency.
> > > > >
> > > > > Yes, using a spinlock and queueing requests on a list if the driver is
> > > > > busy can be done after 2.6.29...
> > > >
> > > > Certainly. Even just replacing your current mutex with a spinlock during
> > > > the memcpy() would surely be a lot faster. Or even just grabbing the
> > > > mutex before calling into the write for the duration of the bio. The way
> > > > you do it is certain context switch death :-)
> > >
> > > It's not just the memcpy(). ps3vram_{up,down}load() call msleep(), so
> > > I cannot use a spinlock.
> >
> > Ah right, I hadn't looked close enough. But putting the mutex_lock()
> > outside of the bio_for_each_segment() is going to be much faster than
> > getting/releasing it for each segment.
>
> It doesn't seem to make any measurable difference, so I'm gonna leave it for
> now.
It will depend on where the bio's are coming from. If they are all
single segment, then there will be no difference. If they contain
multiple segments, you reduce the lock/release by that amount.
But yeah, just leave it as-is for now. You can send a final patch for
inclusion though. Unless I'm mistaken, I only saw the original and then
an incremental patch for changing it to ->make_request_fn?
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device
From: Jens Axboe @ 2009-03-09 10:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Linux Kernel Development, Jim Paris,
Linux/PPC Development, linux-mtd, Vivien Chappelier,
David Woodhouse, Cell Broadband Engine OSS Development
In-Reply-To: <20090309104833.GM11787@kernel.dk>
On Mon, Mar 09 2009, Jens Axboe wrote:
> On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > > > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > > > > > > But then I noticed ps3vram_make_request() may be called concurrently,
> > > > > > > > so I had to add a mutex to avoid data corruption. This slows the
> > > > > > > > driver down, and in the end, the version with a thread turns out to be
> > > > > > > > ca. 1% faster. The version without a thread is about 50 lines less
> > > > > > > > code, though.
> > > > > > >
> > > > > > > That is correct, ->make_request_fn may get reentered. I'm not surprised
> > > > > > > that performance dropped if you just shoved everything under a mutex.
> > > > > > > You could be a little more smart and queue concurrent bio's for
> > > > > > > processing when the current one is complete though, there are several
> > > > > > > approaches there that be a lot faster than going all the way through the
> > > > > > > IO stack and scheduler just to avoid concurrency.
> > > > > >
> > > > > > Yes, using a spinlock and queueing requests on a list if the driver is
> > > > > > busy can be done after 2.6.29...
> > > > >
> > > > > Certainly. Even just replacing your current mutex with a spinlock during
> > > > > the memcpy() would surely be a lot faster. Or even just grabbing the
> > > > > mutex before calling into the write for the duration of the bio. The way
> > > > > you do it is certain context switch death :-)
> > > >
> > > > It's not just the memcpy(). ps3vram_{up,down}load() call msleep(), so
> > > > I cannot use a spinlock.
> > >
> > > Ah right, I hadn't looked close enough. But putting the mutex_lock()
> > > outside of the bio_for_each_segment() is going to be much faster than
> > > getting/releasing it for each segment.
> >
> > It doesn't seem to make any measurable difference, so I'm gonna leave it for
> > now.
>
> It will depend on where the bio's are coming from. If they are all
> single segment, then there will be no difference. If they contain
> multiple segments, you reduce the lock/release by that amount.
>
> But yeah, just leave it as-is for now. You can send a final patch for
> inclusion though. Unless I'm mistaken, I only saw the original and then
> an incremental patch for changing it to ->make_request_fn?
There was a full version, my mistake. I got confused by the removal of
the old driver in another directory :-)
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device
From: Geert Uytterhoeven @ 2009-03-09 10:52 UTC (permalink / raw)
To: Jens Axboe
Cc: Arnd Bergmann, Linux Kernel Development, Jim Paris,
Linux/PPC Development, linux-mtd, Vivien Chappelier,
David Woodhouse, Cell Broadband Engine OSS Development
In-Reply-To: <20090309105022.GN11787@kernel.dk>
On Mon, 9 Mar 2009, Jens Axboe wrote:
> On Mon, Mar 09 2009, Jens Axboe wrote:
> > On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > > > > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > > > > > > > But then I noticed ps3vram_make_request() may be called concurrently,
> > > > > > > > > so I had to add a mutex to avoid data corruption. This slows the
> > > > > > > > > driver down, and in the end, the version with a thread turns out to be
> > > > > > > > > ca. 1% faster. The version without a thread is about 50 lines less
> > > > > > > > > code, though.
> > > > > > > >
> > > > > > > > That is correct, ->make_request_fn may get reentered. I'm not surprised
> > > > > > > > that performance dropped if you just shoved everything under a mutex.
> > > > > > > > You could be a little more smart and queue concurrent bio's for
> > > > > > > > processing when the current one is complete though, there are several
> > > > > > > > approaches there that be a lot faster than going all the way through the
> > > > > > > > IO stack and scheduler just to avoid concurrency.
> > > > > > >
> > > > > > > Yes, using a spinlock and queueing requests on a list if the driver is
> > > > > > > busy can be done after 2.6.29...
> > > > > >
> > > > > > Certainly. Even just replacing your current mutex with a spinlock during
> > > > > > the memcpy() would surely be a lot faster. Or even just grabbing the
> > > > > > mutex before calling into the write for the duration of the bio. The way
> > > > > > you do it is certain context switch death :-)
> > > > >
> > > > > It's not just the memcpy(). ps3vram_{up,down}load() call msleep(), so
> > > > > I cannot use a spinlock.
> > > >
> > > > Ah right, I hadn't looked close enough. But putting the mutex_lock()
> > > > outside of the bio_for_each_segment() is going to be much faster than
> > > > getting/releasing it for each segment.
> > >
> > > It doesn't seem to make any measurable difference, so I'm gonna leave it for
> > > now.
> >
> > It will depend on where the bio's are coming from. If they are all
> > single segment, then there will be no difference. If they contain
> > multiple segments, you reduce the lock/release by that amount.
> >
> > But yeah, just leave it as-is for now. You can send a final patch for
> > inclusion though. Unless I'm mistaken, I only saw the original and then
> > an incremental patch for changing it to ->make_request_fn?
>
> There was a full version, my mistake. I got confused by the removal of
Indeed.
> the old driver in another directory :-)
Can you please ack it? Thx!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: Machine check in 4xx ethernet driver
From: Felix Radensky @ 2009-03-09 10:53 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090309103820.GA17943@zod.rchland.ibm.com>
Josh Boyer-4 wrote:
>
> On Mon, Mar 09, 2009 at 12:47:02AM -0700, Felix Radensky wrote:
>>
>>Hi,
>>
>>I'm getting machine check exception when trying to dump
>>emac registers on 405EX Kilauea board. The kernel is 2.6.29-rc7
>>The problem seems not new, I can reproduce it on 2.6.25 Denx kernel
>
> I've not looked at what that code path does, but the EMAC regs are
> in DCR space, not MMIO. Using memcpy_fromio there seems odd.
>
>
At least on 405EX MAL registers are in DCR space, but EMAC and RGMII
ones are in MMIO space.
--
View this message in context: http://www.nabble.com/Machine-check-in-4xx-ethernet-driver-tp22408005p22410889.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device
From: Jens Axboe @ 2009-03-09 10:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Linux Kernel Development, Jim Paris,
Linux/PPC Development, linux-mtd, Vivien Chappelier,
David Woodhouse, Cell Broadband Engine OSS Development
In-Reply-To: <alpine.LRH.2.00.0903091151480.19484@vixen.sonytel.be>
On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> On Mon, 9 Mar 2009, Jens Axboe wrote:
> > On Mon, Mar 09 2009, Jens Axboe wrote:
> > > On Mon, Mar 09 2009, Geert Uytterhoeven wrote:
> > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > > > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > > > > > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > > > > > > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > > > > > > > > But then I noticed ps3vram_make_request() may be called concurrently,
> > > > > > > > > > so I had to add a mutex to avoid data corruption. This slows the
> > > > > > > > > > driver down, and in the end, the version with a thread turns out to be
> > > > > > > > > > ca. 1% faster. The version without a thread is about 50 lines less
> > > > > > > > > > code, though.
> > > > > > > > >
> > > > > > > > > That is correct, ->make_request_fn may get reentered. I'm not surprised
> > > > > > > > > that performance dropped if you just shoved everything under a mutex.
> > > > > > > > > You could be a little more smart and queue concurrent bio's for
> > > > > > > > > processing when the current one is complete though, there are several
> > > > > > > > > approaches there that be a lot faster than going all the way through the
> > > > > > > > > IO stack and scheduler just to avoid concurrency.
> > > > > > > >
> > > > > > > > Yes, using a spinlock and queueing requests on a list if the driver is
> > > > > > > > busy can be done after 2.6.29...
> > > > > > >
> > > > > > > Certainly. Even just replacing your current mutex with a spinlock during
> > > > > > > the memcpy() would surely be a lot faster. Or even just grabbing the
> > > > > > > mutex before calling into the write for the duration of the bio. The way
> > > > > > > you do it is certain context switch death :-)
> > > > > >
> > > > > > It's not just the memcpy(). ps3vram_{up,down}load() call msleep(), so
> > > > > > I cannot use a spinlock.
> > > > >
> > > > > Ah right, I hadn't looked close enough. But putting the mutex_lock()
> > > > > outside of the bio_for_each_segment() is going to be much faster than
> > > > > getting/releasing it for each segment.
> > > >
> > > > It doesn't seem to make any measurable difference, so I'm gonna leave it for
> > > > now.
> > >
> > > It will depend on where the bio's are coming from. If they are all
> > > single segment, then there will be no difference. If they contain
> > > multiple segments, you reduce the lock/release by that amount.
> > >
> > > But yeah, just leave it as-is for now. You can send a final patch for
> > > inclusion though. Unless I'm mistaken, I only saw the original and then
> > > an incremental patch for changing it to ->make_request_fn?
> >
> > There was a full version, my mistake. I got confused by the removal of
>
> Indeed.
>
> > the old driver in another directory :-)
>
> Can you please ack it? Thx!
Sure, I thought we had agreed to queue it up for 2.6.29?
--
Jens Axboe
^ permalink raw reply
* Re: Davicom DM9000A on MPC5200B (powerpc) works using a dirty offsetting and byte trick
From: Juergen Beisert @ 2009-03-09 11:09 UTC (permalink / raw)
To: Henk Stegeman; +Cc: linuxppc-dev
In-Reply-To: <ae4f76fd0903090232n21152b02of5ebcac86c60e53a@mail.gmail.com>
Henk,
On Montag, 9. M=E4rz 2009, Henk Stegeman wrote:
> I don't understand how this would work,
>
> Now I do one byte-swap, which works.
> -I byteswap in software, for 16-bit cycles by byte swapping and for 8
> bit cycles by adding an offset of 1.
> (The byte swapping on the chipselect is off)
>
> Your advice includes two byteswaps, one by re-routing the data bus and
> one by enabling the byte swap on the chip-select.
My experience is the chip select byte swap feature only works correctly if =
you=20
connect a little endian device like I showed you.
> Or does one of them not really swap bytes?
Let me show you how it works. You must ensure you can write/read data in an=
y=20
data width, but at the side of the little endian device it always must be i=
n=20
the correct endianess. This example uses a 32 bit data width, but it works=
=20
for 16 bit, too.
=2D LE shows how a real litte endian CPU would write data
=2D MPC1 shows how MPC5200 will do it, without any byte swap and DO at the
MPC5200 side is also D0 at the little endian device
=2D MPC2 shows how MPC5200 will do it, with D0 at the MPC5200 side is D24 a=
t the
little endian device
=2D MPC3 shows how MPC5200 will do it, connected like MPC2 but also the chip
select byte swap feature enabled
=2D LE DEV shows how the little endian device expects the data
You want to write this data at the given offset into the little endian devi=
ce:
Bytes: 0:0x34, 1:0x12, 2:0x78, 3:0x56
Worte: 0:0x1234 2:0x5678
LONG: 0:0x56781234
Writing as bytes:
Bytes: 0:0x34, 1:0x12, 2:0x78, 3:0x56
Offset LE MPC1 MPC2 MPC3 LE DEV
0 0x34 0x56 0x34 0x34 0x34
1 0x12 0x78 0x12 0x12 0x12
2 0x78 0x12 0x78 0x78 0x78
3 0x56 0x34 0x56 0x56 0x56
^^^^--------^^^^--^^^^--^^^^--> these are correct
^^^^--------------------> this is wrong
Writing as words:
Words: 0:0x1234 2:0x5678
Offset LE MPC1 MPC2 MPC3 LE DEV
0 0x34 0x78 0x12 0x34 0x34
(1) 0x12 0x56 0x34 0x12 0x12
2 0x78 0x34 0x56 0x78 0x78
(3) 0x56 0x12 0x78 0x56 0x56
^^^^---------------^^^^--^^^^--> these are correct
^^^^--^^^^--------------> these are wrong
Writing as longs:
LONG: 0:0x56781234
Offset LE MPC1 MPC2 MPC3 LE DEV
0 0x34 0x34 0x56 0x34 0x34
(1) 0x12 0x12 0x78 0x12 0x12
(2) 0x78 0x78 0x12 0x78 0x78
(3) 0x56 0x56 0x34 0x56 0x56
^^^^---^^^^ -------^^^^--^^^^--> these are correct
^^^^--------------> this is wrong
So, the MPC3 example always writes correct data.
Hope it helps,
Juergen
=2D-=20
Pengutronix e.K. | Juergen Beisert =
|
Linux Solutions for Science and Industry | Phone: +49-8766-939 228 =
|
Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917-5555=
|
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ =
|
^ permalink raw reply
* Re: Machine check in 4xx ethernet driver
From: Josh Boyer @ 2009-03-09 11:14 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev
In-Reply-To: <22410889.post@talk.nabble.com>
On Mon, Mar 09, 2009 at 03:53:25AM -0700, Felix Radensky wrote:
>
>
>
>Josh Boyer-4 wrote:
>>
>> On Mon, Mar 09, 2009 at 12:47:02AM -0700, Felix Radensky wrote:
>>>
>>>Hi,
>>>
>>>I'm getting machine check exception when trying to dump
>>>emac registers on 405EX Kilauea board. The kernel is 2.6.29-rc7
>>>The problem seems not new, I can reproduce it on 2.6.25 Denx kernel
>>
>> I've not looked at what that code path does, but the EMAC regs are
>> in DCR space, not MMIO. Using memcpy_fromio there seems odd.
>>
>>
>
>At least on 405EX MAL registers are in DCR space, but EMAC and RGMII
>ones are in MMIO space.
Ah, quite right. No coffee yet this morning.
You'll need to look at the code path ethtool is forcing. Perhaps it's doing
something stupid.
josh
^ permalink raw reply
* KGDB over serial on xilinx virtex-5 (ppc440)
From: srikanth krishnakar @ 2009-03-09 12:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <6213bc560903070759x87658adrb6a9acaa7d4e2855@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]
Hi all,
Has anybody tested KGDBOC in linux-2.6.28 for Xilinx Virtex-5 PowerPC
target boards..
I just see that KGDB waits for remote connection from GDB host, but
unfortunately
Command line arguments were :
console=ttyS0 ip=bootp root=/dev/nfs rw kgdboc=ttyS0 kgdbwait
The test is been done on xilinx virtex-5 ppc440 target
Target side:
----------------
Serial: 8250/16550 driver4 ports, IRQ sharing disabled
83e00000.serial: ttyS0 at MMIO 0x83e01003 (irq = 16) is a 16550A
console [ttyS0] enabled
kgdb: Registered I/O driver kgdboc.
kgdb: Waiting for connection from remote gdb...
------------------
Host side
------------------
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
Sending packet: $qSupported#37...Sending packet: $qSupported#37...Sending
packet: $qSupported#37...Sending packet: $qSupported#37...Timed out.
Timed out.
Timed out
.....
.....
------------------
Is anything else need to be implemented for ppc44x for KGDB to work ?
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 1324 bytes --]
^ permalink raw reply
* Re: Machine check in 4xx ethernet driver
From: Felix Radensky @ 2009-03-09 13:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090309111436.GA2256@yoda.jdub.homelinux.org>
Josh Boyer-4 wrote:
>
> On Mon, Mar 09, 2009 at 03:53:25AM -0700, Felix Radensky wrote:
>>
>>
>>
>>Josh Boyer-4 wrote:
>>>
>>> On Mon, Mar 09, 2009 at 12:47:02AM -0700, Felix Radensky wrote:
>>>>
>>>>Hi,
>>>>
>>>>I'm getting machine check exception when trying to dump
>>>>emac registers on 405EX Kilauea board. The kernel is 2.6.29-rc7
>>>>The problem seems not new, I can reproduce it on 2.6.25 Denx kernel
>>>
>>> I've not looked at what that code path does, but the EMAC regs are
>>> in DCR space, not MMIO. Using memcpy_fromio there seems odd.
>>>
>>>
>>
>>At least on 405EX MAL registers are in DCR space, but EMAC and RGMII
>>ones are in MMIO space.
>
> Ah, quite right. No coffee yet this morning.
>
> You'll need to look at the code path ethtool is forcing. Perhaps it's
> doing
> something stupid.
>
> The problem goes away if I replace memcpy_fromio() by memcpy().
> Is memcpy_fromio() really necessary in this case ?
>
>
--
View this message in context: http://www.nabble.com/Machine-check-in-4xx-ethernet-driver-tp22408005p22412825.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH 0/7] Generic RTC class driver
From: Geert Uytterhoeven @ 2009-03-09 13:26 UTC (permalink / raw)
To: Alessandro Zummo, Kyle McMartin
Cc: linux-m68k, rtc-linux, linux-parisc, linux-kernel, linuxppc-dev,
Paul Mundt, Dann Frazier
Hi Alessandro et al,
This patch series:
1. Adds the missing module alias to rtc-parisc (which is a bugfix), and
performs a few cleanups,
2. Moves the platform device creation out of rtc-ppc and into arch-specific
code (which is also a bugfix),
3. Consolidates rtc-parisc and rtc-ppc into rtc-generic (which is a cleanup),
4. Hooks up rtc-generic on m68k (it's been using [sg]et_rtc_time() since
ages),
5. Makes rtc-generic dependent on PARISC, PPC, and M68K (the existing
[sg]et_rtc_time() users):
a. without introducing ARCH_HAS_GENERIC_RTC,
b. with a big fat warning in the Kconfig comment discouraging people
from relaxing the dependencies.
6. Converts the PS3 RTC support into a separate driver, called rtc-ps3
(as a bonus ;-)
To reduce code churn, the order and number of the actual patches slightly
differs:
[1] parisc: rtc: get_rtc_time() returns unsigned int
[2] parisc: rtc: platform_driver_probe() fixups
[3] parisc: rtc: Add missing module alias
[4] parisc: rtc: Rename rtc-parisc to rtc-generic
[5] m68k: Hook up rtc-generic
[6] powerpc: Hook up rtc-generic, and kill rtc-ppc
[7] powerpc/ps3: Add rtc-ps3
a/drivers/rtc/rtc-parisc.c | 85 -------------------------
b/arch/m68k/include/asm/rtc.h | 7 +-
b/arch/m68k/kernel/time.c | 18 +++++
b/arch/parisc/Kconfig | 2
b/arch/parisc/kernel/time.c | 6 -
b/arch/powerpc/include/asm/ps3.h | 3
b/arch/powerpc/kernel/time.c | 16 ++++
b/arch/powerpc/platforms/ps3/os-area.c | 2
b/arch/powerpc/platforms/ps3/platform.h | 2
b/arch/powerpc/platforms/ps3/setup.c | 2
b/arch/powerpc/platforms/ps3/time.c | 26 +++----
b/drivers/rtc/Kconfig | 10 +--
b/drivers/rtc/Makefile | 2
b/drivers/rtc/rtc-generic.c | 84 +++++++++++++++++++++++++
b/drivers/rtc/rtc-parisc.c | 5 -
b/drivers/rtc/rtc-ps3.c | 106 +++++++++++++++++++++++++++++++-
drivers/rtc/Kconfig | 22 +++---
drivers/rtc/Makefile | 2
drivers/rtc/rtc-parisc.c | 6 -
drivers/rtc/rtc-ppc.c | 70 ---------------------
20 files changed, 271 insertions(+), 205 deletions(-)
These patches are relative to the "rtc-parisc" branch of Kyle's PA-RISC git
repository, which already contains some cleanups for the rtc-parisc driver by
Dann, which already have been ack'ed by Alessandro:
http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=shortlog;h=rtc-parisc
Paul: Feel free to add your SuperH support.
I suppose the easiest way for this to go in is through Kyle's PA-RISC tree, as
he already has the preceding patches? Can I have your acks, please?
Thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* [PATCH 1/7] parisc: rtc: get_rtc_time() returns unsigned int
From: Geert Uytterhoeven @ 2009-03-09 13:26 UTC (permalink / raw)
To: Alessandro Zummo, Kyle McMartin
Cc: linux-m68k, rtc-linux, linux-parisc, linux-kernel, linuxppc-dev,
Paul Mundt, Geert Uytterhoeven, Dann Frazier
In-Reply-To: <1236605183-22718-1-git-send-email-Geert.Uytterhoeven@sonycom.com>
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/rtc/rtc-parisc.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-parisc.c b/drivers/rtc/rtc-parisc.c
index b966f56..620b949 100644
--- a/drivers/rtc/rtc-parisc.c
+++ b/drivers/rtc/rtc-parisc.c
@@ -13,9 +13,7 @@
static int parisc_get_time(struct device *dev, struct rtc_time *tm)
{
- unsigned long ret;
-
- ret = get_rtc_time(tm);
+ unsigned int ret = get_rtc_time(tm);
if (ret & RTC_BATT_BAD)
return -EOPNOTSUPP;
--
1.6.0.4
^ permalink raw reply related
* [PATCH 2/7] parisc: rtc: platform_driver_probe() fixups
From: Geert Uytterhoeven @ 2009-03-09 13:26 UTC (permalink / raw)
To: Alessandro Zummo, Kyle McMartin
Cc: linux-m68k, rtc-linux, linux-parisc, linux-kernel, dann frazier,
linuxppc-dev, Paul Mundt, Geert Uytterhoeven, Dann Frazier
In-Reply-To: <1236605183-22718-2-git-send-email-Geert.Uytterhoeven@sonycom.com>
When using platform_driver_probe(), it's not needed to setup a .probe
function, and .remove should be marked __exit_p(), not __devexit_p().
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Cc: dann frazier <dannf@hp.com>
---
drivers/rtc/rtc-parisc.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-parisc.c b/drivers/rtc/rtc-parisc.c
index 620b949..f4e871c 100644
--- a/drivers/rtc/rtc-parisc.c
+++ b/drivers/rtc/rtc-parisc.c
@@ -62,8 +62,7 @@ static struct platform_driver parisc_rtc_driver = {
.name = "rtc-parisc",
.owner = THIS_MODULE,
},
- .probe = parisc_rtc_probe,
- .remove = __devexit_p(parisc_rtc_remove),
+ .remove = __exit_p(parisc_rtc_remove),
};
static int __init parisc_rtc_init(void)
--
1.6.0.4
^ permalink raw reply related
* [PATCH 3/7] parisc: rtc: Add missing module alias
From: Geert Uytterhoeven @ 2009-03-09 13:26 UTC (permalink / raw)
To: Alessandro Zummo, Kyle McMartin
Cc: linux-m68k, rtc-linux, linux-parisc, linux-kernel, linuxppc-dev,
Paul Mundt, Geert Uytterhoeven, Dann Frazier
In-Reply-To: <1236605183-22718-3-git-send-email-Geert.Uytterhoeven@sonycom.com>
Make udev autoload the driver
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/rtc/rtc-parisc.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/rtc/rtc-parisc.c b/drivers/rtc/rtc-parisc.c
index f4e871c..48ef5b4 100644
--- a/drivers/rtc/rtc-parisc.c
+++ b/drivers/rtc/rtc-parisc.c
@@ -81,3 +81,4 @@ module_exit(parisc_rtc_fini);
MODULE_AUTHOR("Kyle McMartin <kyle@mcmartin.ca>");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("HP PA-RISC RTC driver");
+MODULE_ALIAS("platform:rtc-parisc");
--
1.6.0.4
^ permalink raw reply related
* [PATCH 5/7] m68k: Hook up rtc-generic
From: Geert Uytterhoeven @ 2009-03-09 13:26 UTC (permalink / raw)
To: Alessandro Zummo, Kyle McMartin
Cc: linux-m68k, rtc-linux, linux-parisc, linux-kernel, linuxppc-dev,
Paul Mundt, Geert Uytterhoeven, Dann Frazier
In-Reply-To: <1236605183-22718-5-git-send-email-Geert.Uytterhoeven@sonycom.com>
m68k has been a long time user of the generic RTC abstraction, so hook up
rtc-generic:
- Create the "rtc-generic" platform device if mach_hwclk is set,
- Add checks for mach_hwclk, in anticipation of RTC chip drivers being moved
to drivers/rtc/.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
arch/m68k/include/asm/rtc.h | 7 +++++--
arch/m68k/kernel/time.c | 18 ++++++++++++++++++
drivers/rtc/Kconfig | 2 +-
3 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/arch/m68k/include/asm/rtc.h b/arch/m68k/include/asm/rtc.h
index 5d3e038..a4d08ea 100644
--- a/arch/m68k/include/asm/rtc.h
+++ b/arch/m68k/include/asm/rtc.h
@@ -36,13 +36,16 @@ static inline unsigned int get_rtc_time(struct rtc_time *time)
* RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
* by the RTC when initially set to a non-zero value.
*/
- mach_hwclk(0, time);
+ if (mach_hwclk)
+ mach_hwclk(0, time);
return RTC_24H;
}
static inline int set_rtc_time(struct rtc_time *time)
{
- return mach_hwclk(1, time);
+ if (mach_hwclk)
+ return mach_hwclk(1, time);
+ return -EINVAL;
}
static inline unsigned int get_rtc_ss(void)
diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c
index 7db4159..54d9807 100644
--- a/arch/m68k/kernel/time.c
+++ b/arch/m68k/kernel/time.c
@@ -18,6 +18,7 @@
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/rtc.h>
+#include <linux/platform_device.h>
#include <asm/machdep.h>
#include <asm/io.h>
@@ -159,3 +160,20 @@ int do_settimeofday(struct timespec *tv)
}
EXPORT_SYMBOL(do_settimeofday);
+
+
+static int __init rtc_init(void)
+{
+ struct platform_device *pdev;
+
+ if (!mach_hwclk)
+ return -ENODEV;
+
+ pdev = platform_device_register_simple("rtc-generic", -1, NULL, 0);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ return 0;
+}
+
+module_init(rtc_init);
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index d0aeff2..c8ead87 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -681,7 +681,7 @@ config RTC_DRV_GENERIC
tristate "Generic RTC support"
# Please consider writing a new RTC driver instead of using the generic
# RTC abstraction
- depends on PARISC
+ depends on PARISC || M68K
help
Say Y or M here to enable RTC support on systems using the generic
RTC abstraction. If you do not know what you are doing, you should
--
1.6.0.4
^ permalink raw reply related
* [PATCH 4/7] parisc: rtc: Rename rtc-parisc to rtc-generic
From: Geert Uytterhoeven @ 2009-03-09 13:26 UTC (permalink / raw)
To: Alessandro Zummo, Kyle McMartin
Cc: linux-m68k, rtc-linux, linux-parisc, linux-kernel, linuxppc-dev,
Paul Mundt, Geert Uytterhoeven, Dann Frazier
In-Reply-To: <1236605183-22718-4-git-send-email-Geert.Uytterhoeven@sonycom.com>
The rtc-parisc driver is not PA-RISC specific at all, as it uses the existing
(but deprecated) generic RTC infrastructure ([gs]et_rtc_time()).
Rename the driver from rtc-parisc to rtc-generic.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
arch/parisc/Kconfig | 2 +-
arch/parisc/kernel/time.c | 6 ++--
drivers/rtc/Kconfig | 10 +++--
drivers/rtc/Makefile | 2 +-
drivers/rtc/rtc-generic.c | 84 +++++++++++++++++++++++++++++++++++++++++++++
drivers/rtc/rtc-parisc.c | 84 ---------------------------------------------
6 files changed, 95 insertions(+), 93 deletions(-)
create mode 100644 drivers/rtc/rtc-generic.c
delete mode 100644 drivers/rtc/rtc-parisc.c
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index aacf11d..378b649 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -10,7 +10,7 @@ config PARISC
select HAVE_IDE
select HAVE_OPROFILE
select RTC_CLASS
- select RTC_DRV_PARISC
+ select RTC_DRV_GENERIC
select INIT_ALL_POSSIBLE
help
The PA-RISC microprocessor is designed by Hewlett-Packard and used
diff --git a/arch/parisc/kernel/time.c b/arch/parisc/kernel/time.c
index e75cae6..86a99d0 100644
--- a/arch/parisc/kernel/time.c
+++ b/arch/parisc/kernel/time.c
@@ -216,14 +216,14 @@ void __init start_cpu_itimer(void)
per_cpu(cpu_data, cpu).it_value = next_tick;
}
-static struct platform_device rtc_parisc_dev = {
- .name = "rtc-parisc",
+static struct platform_device rtc_generic_dev = {
+ .name = "rtc-generic",
.id = -1,
};
static int __init rtc_init(void)
{
- if (platform_device_register(&rtc_parisc_dev) < 0)
+ if (platform_device_register(&rtc_generic_dev) < 0)
printk(KERN_ERR "unable to register rtc device...\n");
/* not necessarily an error */
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 81450fb..d0aeff2 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -677,12 +677,14 @@ config RTC_DRV_RS5C313
help
If you say yes here you get support for the Ricoh RS5C313 RTC chips.
-config RTC_DRV_PARISC
- tristate "PA-RISC firmware RTC support"
+config RTC_DRV_GENERIC
+ tristate "Generic RTC support"
+ # Please consider writing a new RTC driver instead of using the generic
+ # RTC abstraction
depends on PARISC
help
- Say Y or M here to enable RTC support on PA-RISC systems using
- firmware calls. If you do not know what you are doing, you should
+ Say Y or M here to enable RTC support on systems using the generic
+ RTC abstraction. If you do not know what you are doing, you should
just say Y.
config RTC_DRV_PPC
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 0e697aa..9c18a01 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -55,7 +55,7 @@ obj-$(CONFIG_RTC_DRV_PCF8563) += rtc-pcf8563.o
obj-$(CONFIG_RTC_DRV_PCF8583) += rtc-pcf8583.o
obj-$(CONFIG_RTC_DRV_PL030) += rtc-pl030.o
obj-$(CONFIG_RTC_DRV_PL031) += rtc-pl031.o
-obj-$(CONFIG_RTC_DRV_PARISC) += rtc-parisc.o
+obj-$(CONFIG_RTC_DRV_GENERIC) += rtc-generic.o
obj-$(CONFIG_RTC_DRV_PPC) += rtc-ppc.o
obj-$(CONFIG_RTC_DRV_PXA) += rtc-pxa.o
obj-$(CONFIG_RTC_DRV_R9701) += rtc-r9701.o
diff --git a/drivers/rtc/rtc-generic.c b/drivers/rtc/rtc-generic.c
new file mode 100644
index 0000000..9832200
--- /dev/null
+++ b/drivers/rtc/rtc-generic.c
@@ -0,0 +1,84 @@
+/* rtc-generic: RTC driver using the generic RTC abstraction
+ *
+ * Copyright (C) 2008 Kyle McMartin <kyle@mcmartin.ca>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/time.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+
+#include <asm/rtc.h>
+
+static int generic_get_time(struct device *dev, struct rtc_time *tm)
+{
+ unsigned int ret = get_rtc_time(tm);
+
+ if (ret & RTC_BATT_BAD)
+ return -EOPNOTSUPP;
+
+ return rtc_valid_tm(tm);
+}
+
+static int generic_set_time(struct device *dev, struct rtc_time *tm)
+{
+ if (set_rtc_time(tm) < 0)
+ return -EOPNOTSUPP;
+
+ return 0;
+}
+
+static const struct rtc_class_ops generic_rtc_ops = {
+ .read_time = generic_get_time,
+ .set_time = generic_set_time,
+};
+
+static int __init generic_rtc_probe(struct platform_device *dev)
+{
+ struct rtc_device *rtc;
+
+ rtc = rtc_device_register("rtc-generic", &dev->dev, &generic_rtc_ops,
+ THIS_MODULE);
+ if (IS_ERR(rtc))
+ return PTR_ERR(rtc);
+
+ platform_set_drvdata(dev, rtc);
+
+ return 0;
+}
+
+static int __exit generic_rtc_remove(struct platform_device *dev)
+{
+ struct rtc_device *rtc = platform_get_drvdata(dev);
+
+ rtc_device_unregister(rtc);
+
+ return 0;
+}
+
+static struct platform_driver generic_rtc_driver = {
+ .driver = {
+ .name = "rtc-generic",
+ .owner = THIS_MODULE,
+ },
+ .remove = __exit_p(generic_rtc_remove),
+};
+
+static int __init generic_rtc_init(void)
+{
+ return platform_driver_probe(&generic_rtc_driver, generic_rtc_probe);
+}
+
+static void __exit generic_rtc_fini(void)
+{
+ platform_driver_unregister(&generic_rtc_driver);
+}
+
+module_init(generic_rtc_init);
+module_exit(generic_rtc_fini);
+
+MODULE_AUTHOR("Kyle McMartin <kyle@mcmartin.ca>");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Generic RTC driver");
+MODULE_ALIAS("platform:rtc-generic");
diff --git a/drivers/rtc/rtc-parisc.c b/drivers/rtc/rtc-parisc.c
deleted file mode 100644
index 48ef5b4..0000000
--- a/drivers/rtc/rtc-parisc.c
+++ /dev/null
@@ -1,84 +0,0 @@
-/* rtc-parisc: RTC for HP PA-RISC firmware
- *
- * Copyright (C) 2008 Kyle McMartin <kyle@mcmartin.ca>
- */
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/time.h>
-#include <linux/platform_device.h>
-#include <linux/rtc.h>
-
-#include <asm/rtc.h>
-
-static int parisc_get_time(struct device *dev, struct rtc_time *tm)
-{
- unsigned int ret = get_rtc_time(tm);
-
- if (ret & RTC_BATT_BAD)
- return -EOPNOTSUPP;
-
- return rtc_valid_tm(tm);
-}
-
-static int parisc_set_time(struct device *dev, struct rtc_time *tm)
-{
- if (set_rtc_time(tm) < 0)
- return -EOPNOTSUPP;
-
- return 0;
-}
-
-static const struct rtc_class_ops parisc_rtc_ops = {
- .read_time = parisc_get_time,
- .set_time = parisc_set_time,
-};
-
-static int __init parisc_rtc_probe(struct platform_device *dev)
-{
- struct rtc_device *rtc;
-
- rtc = rtc_device_register("rtc-parisc", &dev->dev, &parisc_rtc_ops,
- THIS_MODULE);
- if (IS_ERR(rtc))
- return PTR_ERR(rtc);
-
- platform_set_drvdata(dev, rtc);
-
- return 0;
-}
-
-static int __exit parisc_rtc_remove(struct platform_device *dev)
-{
- struct rtc_device *rtc = platform_get_drvdata(dev);
-
- rtc_device_unregister(rtc);
-
- return 0;
-}
-
-static struct platform_driver parisc_rtc_driver = {
- .driver = {
- .name = "rtc-parisc",
- .owner = THIS_MODULE,
- },
- .remove = __exit_p(parisc_rtc_remove),
-};
-
-static int __init parisc_rtc_init(void)
-{
- return platform_driver_probe(&parisc_rtc_driver, parisc_rtc_probe);
-}
-
-static void __exit parisc_rtc_fini(void)
-{
- platform_driver_unregister(&parisc_rtc_driver);
-}
-
-module_init(parisc_rtc_init);
-module_exit(parisc_rtc_fini);
-
-MODULE_AUTHOR("Kyle McMartin <kyle@mcmartin.ca>");
-MODULE_LICENSE("GPL");
-MODULE_DESCRIPTION("HP PA-RISC RTC driver");
-MODULE_ALIAS("platform:rtc-parisc");
--
1.6.0.4
^ permalink raw reply related
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