2.6.23.atmel.2 Synchronous Serial Controller (SSC) driver?

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have just recompiled a new kernel, rev 2.6.23.atmel.2, with the new SSC driver enabled. I have not enabled loadable modules support, and the kernel is compiled against static libraries. During bootup, however, the driver does not seem to initialize, and after bootup the device is not accessible via /dev. Should it be?

There is nearly no documentation at all concerning this driver, any help would be appreciated, in particular if you have successfully used the interface somehow.

Below is a copy of the bootup sequence.



U-Boot 1.1.4-at0 (Jan  3 2007 - 10:30:09) 

U-Boot code: 00000000 -> 000144f7  data: 24000000 -> 24002d80
SDRAM: 32 MB at address 0x10000000
Testing SDRAM...OK
malloc: Using memory from 0x11fc0000 to 0x12000000
Flash:  8 MB at address 0x00000000
DRAM Configuration:
Bank #0: 10000000 32 MB
In:    serial
Out:   serial
Err:   serial
Net:   macb0, macb1
Press SPACE to abort autoboot in 1 seconds
### JFFS2 loading 'uImage' to 0x10200000
Scanning JFFS2 FS:   .  | / - \ | / .  - .  \ | / - .  \ | .  / - \ | / .  - \ | / - \ | .  / - \ | / -  done.

### JFFS2 load complete: 1146680 bytes loaded to 0x10200000
## Booting image at 10200000 ...
   Image Name:   Linux-2.6.23.atmel.2
   Image Type:   AVR32 Linux Kernel Image (gzip compressed)
   Data Size:    1146616 Bytes =  1.1 MB
   Load Address: 10000000
   Entry Point:  90000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel at 90000000 (params at 11fc0040)...

Linux version 2.6.23.atmel.2 (root@Slack12VM) (gcc version 4.0.2-atmel.0.99.2) #1 Fri Nov 2 15:03:01 EDT 2007
CPU: AP7000 [01] revision 0 (AVR32B revision 1)
CPU: MMU configuration: Shared TLB
CPU: features: dsp simd ocd perfctr java
CPU: Running at 130.000 MHz
Physical memory:
  10000000-11ffffff
Reserved memory:
  10000000-1015c08f: Kernel code
  1015c090-101dbf47: Kernel data
Exception vectors start at 9000e000
CPU: Paging enabled
Node 0: start_pfn = 0x10000, low = 0x12000
Node 0: mem_map starts at 901de000
Built 1 zonelists in Zone order.  Total pages: 8128
Kernel command line: console=ttyS0 root=/dev/mtdblock1 rootfstype=jffs2
PID hash table entries: 128 (order: 7, 512 bytes)
timer: AT32AP system timer/counter at 0xfff00c00 irq 22
console [ttyS0] enabled
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 30576k/30576k available (1336k kernel code, 2192k reserved, 102k data, 56k init)
SLUB: Genslabs=20, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
Calibrating delay using timer specific routine.. 260.42 BogoMIPS (lpj=520859)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
pdc pdc.0: Atmel Peripheral DMA Controller enabled
at32_eic at32_eic.0: External Interrupt Controller at 0xfff00100, IRQ 19
at32_eic at32_eic.0: Handling 4 external IRQs, starting with IRQ 64
smc smc.0: Atmel Static Memory Controller at 0xfff03400
Generic PHY: Registered new driver
dmac0: DesignWare DMA controller at 0xff200000 irq 2
Time: avr32 clocksource has been installed.
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
fuse init (API version 7.8)
io scheduler noop registered
io scheduler cfq registered (default)
atmel_usart.0: ttyS0 at MMIO 0xffe01000 (irq = 7) is a ATMEL_SERIAL
loop: module loaded
nbd: registered device at major 43
MACB_mii_bus: probed
eth0: Atmel MACB at 0xfff01800 irq 25 (00:04:25:1c:60:4e)
eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=0:01, irq=-1)
MACB_mii_bus: probed
eth1: Atmel MACB at 0xfff01c00 irq 26 (00:04:25:1c:60:4f)
eth1: attached PHY driver [Generic PHY] (mii_bus:phy_addr=1:03, irq=-1)
physmap platform flash device: 00800000 at 00000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd/Fujitsu Extended Query Table at 0x0041
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 3 MTD partitions on "physmap-flash.0":
0x00000000-0x00020000 : "u-boot"
0x00020000-0x007f0000 : "root"
0x007f0000-0x00800000 : "env"
atmel_spi atmel_spi.0: Atmel SPI Controller at 0xffe00000 (irq 3)
mtd_dataflash spi0.0: AT45DB642x (8448 KBytes)
atmel_usba_udc atmel_usba_udc.0: MMIO registers at 0xfff03000 mapped at fff03000
atmel_usba_udc atmel_usba_udc.0: FIFO at 0xff300000 mapped at ff300000
ether gadget: using random self ethernet address
ether gadget: using random host ethernet address
usb0: Ethernet Gadget, version: May Day 2005
usb0: using atmel_usba_udc, OUT ep2out-bulk IN ep1in-bulk STATUS ep3in-int
usb0: MAC ce:5f:d7:6b:8e:3a
usb0: HOST MAC 6e:29:3b:68:2d:80
at32ap700x_rtc at32ap700x_rtc.0: rtc core: registered at32ap700x_rtc as rtc0
at32ap700x_rtc at32ap700x_rtc.0: Atmel RTC for AT32AP700x at fff00080 irq 21
i2c /dev entries driver
i2c-gpio: probe failed: -19
atmel_twi: probe of atmel_twi.0 failed with error -2
Registered led device: sys
Registered led device: a
Registered led device: b
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
at32ap700x_rtc at32ap700x_rtc.0: setting the system clock to 1970-01-01 00:00:00 (0)
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 56K (90000000 - 9000e000)

init started:  BusyBox v1.4.2 (2007-04-17 15:34:55 CEST) multi-call binary
 * mounting virtual filesystems: /proc /sys /dev /dev/pts /config /tmp /var/run /var/lib/samba /var/log 
 * set mdev hotplug ...          [ OK ]
 * mdev ...                      [ OK ]
 * setting hostname ...          'gateway.ngw100.net'
 * network loopback ...          [ OK ]
 * starting syslogd ...          [ OK ]
 * log messages to syslog ...    [ OK ]
 * starting klogd ...            [ OK ]
 * probing modules ...           vfat failed, mmc_block failed, atmel-mci failed, [ OK ]
 * mounting filesystems:         /usr 
 * setup eth0 ...                [ STATIC ] (192.168.3.1)
 * setup eth1 ...                [ OK ] (192.168.1.101)
 * network ...                   [ OK ]
 * starting telnetd ...          [ OK ]
 * starting dnsmasq ...          [ OK ]
 * running ntpdate ...           [ OK ]
 * starting ntpd ...             [ OK ]
Last Edited: Sat. Nov 3, 2007 - 08:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The NGW100 does not have wire code in the board setup for the SSC driver.

The SSC driver is very simple, just a way to reserve the peripheral properly. Take a look at the stk1002 board in the kernel for wire code and snd-at73c213 for usage.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm okay so there is no /dev interface to the device per se, the driver simply defines names for the registers to use in a C program for example, correct?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It sure would be simpler if the driver was configurable via /config and would spawn a /dev/sscR0 or /dev/sscT0 for example... Then buffer a set amount of data in a FIFO fashion, and simply read the data from the /dev pipe..

Hopefully this is where this driver is going... ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It was chosen to be simple because there is no way to know how the user wants to setup and use the peripheral. If you want a /dev/sscNN make a character driver interfacing the SSC driver.

AFAIK the driver will not get any new features soon.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Am I right in assuming I can address the peripheral at low-level in C? Or is the kernel going to prevent me from doing so?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

UNiXWHoRe wrote:
Am I right in assuming I can address the peripheral at low-level in C? Or is the kernel going to prevent me from doing so?

If, by low-level C, you mean a kernel driver, then yes. The peripheral is not available from user space.

If you must have access to it from user space, I would recommend making a character driver.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok so I must build a kernel driver that will configure the SSC port using the definitions in atmel-ssc.h and open a character device like /dev/sscR0 to be able to fetch data from it. As funny as this sounds, seems simple enough... :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup, sounds about right. Same kinda job as spidev now does for SPI.

Should be able to cut and paste most code from either spidev or from the characters driver examples in "Linux Device Drivers" (a good book, check it out).

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm, I guess it shouldn't be too hard to create a /dev interface for sending some data through the SSC, but the question remains why would you do that? The SSC driver is really meant to be a thin library used to implement drivers for more specific functionality, e.g. hooking external i2s sound chips up to the ALSA framework.