[#3858] rts/cts control case fails

Document created by Aaronwu Employee on Aug 28, 2013
Version 1Show Document
  • View in full screen mode

[#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

Blackfin support (C) 2004-2007 Analog Devices, Inc.

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

    Tags

 

File Name     File Type     File Size     Posted By

config.ctsrts    application/octet-stream    28477    Mingquan Pan

Attachments

    Outcomes