[#3858] rts/cts control case fails

Submitted By: Mingquan Pan

Open Date

2008-01-25 01:12:46 Close Date

2008-02-25 01:41:53

Priority:

Medium Assignee:

Sonic Zhang

Status:

Closed Fixed In Release:

N/A

Found In Release:

N/A Release:

Category:

N/A Board:

N/A

Processor:

N/A Silicon Revision:

Is this bug repeatable?:

Yes Resolution:

Fixed

Uboot version or rev.:

Toolchain version or rev.:

08r1-6

App binary format:

N/A

Summary: rts/cts control case fails

Details:

rts/cts control case fails now.

kernel config file is attached.

cat /proc/kallsyms at kernel prompt, it prints all the stuff. Switch SW.4.3 from on to off, it would hold the message to be printed on the screen. But switch sw4.3 back to on, the printing would not resume, it just stop there, and not even reponse to Ctrl+c.

Bytes transferred = 6308412 (60423c hex)

Loading .text @ 0x00001000 (1011376 bytes)

Loading .rodata @ 0x000f8000 (228064 bytes)

Loading __ksymtab @ 0x0012fae0 (14312 bytes)

Loading __ksymtab_gpl @ 0x001332c8 (4016 bytes)

Loading __ksymtab_strings @ 0x00134278 (43876 bytes)

Loading __param @ 0x0013eddc (300 bytes)

Loading .data @ 0x0013f000 (69632 bytes)

Loading .init.text @ 0x00150000 (93888 bytes)

Loading .init.data @ 0x00166ec0 (3304 bytes)

Loading .init.setup @ 0x00167ba8 (596 bytes)

Loading .initcall.init @ 0x00167dfc (432 bytes)

Loading .con_initcall.init @ 0x00167fac (4 bytes)

Loading .init.ramfs @ 0x00167fb0 (4281883 bytes)

Loading .text_l1 @ 0xffa00000 (8224 bytes)

sh_addr: FFA00000, p_paddr: 0057D5CB

Loading from: 0257E000 to 0057D5CB, size: 8224

Loading .data_l1 @ 0xff800000 (192 bytes)

sh_addr: FF800000, p_paddr: 0057F5EB

Loading from: 02581000 to 0057F5EB, size: 192

Clearing .bss @ 0x00580000 (61232 bytes)

## Starting application at 0x00150000 ...

Linux version 2.6.22.16-ADI-2008R1-svn4139 (test@linux) (gcc version 4.1.2 (ADI svn)) #34 Fri Jan 25 15:48:01 CST 2008

early printk enabled on early_BFuart0

Hardware Trace Active and Enabled

Warning: limiting memory to 56MB due to hardware anomaly 05000263

Compiled for ADSP-BF537 Rev 0.2

Blackfin Linux support by blackfin.uclinux.org/

Processor Speed: 500 MHz core clock and 100 MHz System Clock

Board Memory: 64MB

Kernel Managed Memory: 64MB

Memory map:

text = 0x00001000-0x000f7eb0

rodata = 0x000f8000-0x0013ef08

data = 0x0013f000-0x00150000

stack = 0x00140000-0x00142000

init = 0x00150000-0x00580000

bss = 0x00580000-0x0058ef30

available = 0x0058ef30-0x037ff000

DMA Zone = 0x03f00000-0x04000000

Instruction Cache Enabled

Data Cache Enabled (write-through)

Built 1 zonelists. Total pages: 14224

Kernel command line: root=/dev/mtdblock0 rw earlyprintk=serial,uart0,57600

Configuring Blackfin Priority Driven Interrupts

PID hash table entries: 256 (order: 8, 1024 bytes)

console handover: boot [early_BFuart0] -> real [ttyBF0]

Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)

Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)

Physical pages: 37ff

Memory available: 51004k/64260k RAM, (4288k init code, 987k kernel code, 59k data, 1024k dma)

Blackfin Scratchpad data SRAM: 4 KB

Blackfin Data A SRAM: 16 KB (15 KB free)

Blackfin Data B SRAM: 16 KB (16 KB free)

Blackfin Instruction SRAM: 48 KB (39 KB free)

Security Framework v1.0.0 initialized

Mount-cache hash table entries: 512

NET: Registered protocol family 16

Blackfin GPIO Controller

Blackfin DMA Controller

stamp_init(): registering device resources

Generic PHY: Registered new driver

.IP route cache hash table entries: 1024 (order: 0, 4096 bytes)

TCP established hash table entries: 2048 (order: 2, 16384 bytes)

TCP bind hash table entries: 2048 (order: 1, 8192 bytes)

TCP: Hash tables configured (established 2048 bind 2048)

TCP reno registered

io scheduler noop registered

io scheduler anticipatory registered (default)

io scheduler cfq registered

Dynamic Power Management Controller Driver v0.1: major=10, minor = 254

bfin-wdt: initialized: timeout=20 sec (nowayout=0)

Serial: Blackfin serial driver

bfin-uart.1: ttyBF0 at MMIO 0xffc00400 (irq = 18) is a BFIN-UART

RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize

SMSC LAN83C185: Registered new driver

bfin_mac_mdio: probed

bfin_mac: attached PHY driver [SMSC LAN83C185] (mii_bus:phy_addr=0:01, irq=-1, mdc_clk=2500000Hz(mdc_div=19)@sclk=100MHz)

bfin_mac: Version 1.1, Blackfin BF53[67] BF527 on-chip Ethernet MAC driver

bfin-spi bfin-spi.0: Blackfin BF5xx on-chip SPI Contoller Driver, Version 1.0, regs_base@ffc00500, dma channel@7

rtc-bfin rtc-bfin: rtc core: registered rtc-bfin as rtc0

TCP cubic registered

NET: Registered protocol family 1

NET: Registered protocol family 17

rtc-bfin rtc-bfin: setting the system clock to 1970-01-01 01:17:11 (4631)

Freeing unused kernel memory: 4288k freed

dma_alloc_init: dma_page @ 0x0057d000 - 256 pages at 0x03f00000

_____________________________________

a8888b. / Welcome to the uClinux distribution \

d888888b. / _ _ \

8P"YP"Y88 / | | |_| __ __ (TM) |

8|o||o|88 _____/ | | _ ____ _ _ \ \/ / |

8' .88 \ | | | | _ \| | | | \ / |

8`._.' Y8. \ | |__ | | | | | |_| | / \ |

d/ `8b. \ \____||_|_| |_|\____|/_/\_\ |

dP . Y8b. \ For embedded processors including |

d8:' " `::88b \ the Analog Devices Blackfin /

d8" 'Y88b \___________________________________/

:8P ' :888

8a. : _a88P For further information, check out:

._/"Yaa_: .| 88P| - blackfin.uclinux.org/

\ YP" `| 8P `. - docs.blackfin.uclinux.org/

/ \.___.d| .' - www.uclinux.org/

`--..__)8888P`._.' jgs/a:f - www.analog.com/blackfin

Have a lot of fun...

BusyBox v1.4.1 (2008-01-24 10:17:39 CST) Built-in shell (msh)

Enter 'help' for a list of built-in commands.

root:/> cat /proc/kallsyms

00001000 t_dma_config

0000s

00001000 T __stext

00001000 T _text

00001000 T __text

00001018 t _init_post

000010d8 t _try_name

00001240 T _name_to_dev_t

00001488 T _calibrate_delay

00001680 t _kernel_thread_helper

Follow-ups

--- Sonic Zhang 2008-01-29 05:18:21

Should poll RTS/CTS status in DMA mode as well as that in PIO mode.

--- Robin Getz 2008-01-29 08:25:26

Sonic:

You really can't "poll" in DMA mode - can you?

When the host asserts CTS (meaning don't send any more information) - the data

needs to stop on the next byte. We can't do this if we poll at the start of new

DMA transactions.

I'm not even sure we can do this via interrupt. If we do turn data off in the

middle of a DMA transaction (cancelling DMA), can we tell where to restart when

CTS de-asserts?

--- Sonic Zhang 2008-01-29 22:20:29

Actually, software emulated hardware flow controll is impossible to stop

accurately in the next byte. There is haredware buffers in both PIO and DMA

mode. In this case, the CTS/RTS control logic in the driver only need to stop

kernel from writing more buffers to the driver while let current transfer to

complete.

--- Sonic Zhang 2008-01-29 22:25:11

Interrupt CTS mode doesn't help to solve the accuracy problem. It only benefits

the cpu consumption cost.

--- Robin Getz 2008-01-29 23:33:18

I understand it may not stop on the next byte, but it will be closer (and as you

said, be lower CPU consumption) with interrupt, rather than polled.

If a host asserts CTS - it means its buffers are full, and we need to stop

sending.

With PIO, I understand we might send an extra byte. Not much we can do about

that. But with DMA, it could be many, many bytes - couldn't it?

If we are not going to respect it in DMA mode, are we better off dis-allowing

the combo of DMA and FlowControl - ? Maybe?

-Robin

--- Sonic Zhang 2008-01-30 00:06:25

The max extra bytes sent out in DMA mode when CTS asserts are 256. Yes, this is

a big number. This makes flowcontrol in DMA mode meaningless if user wants

accurite hardware flowcontrol. We can document this weakness at least.

--- Mingquan Pan 2008-02-25 01:41:53

Yes,close.

Files

Changes

Commits

Dependencies

Duplicates

Associations

Partner Forums

Partner Libraries

[#3858] rts/cts control case fails