Thu Jun 14 19:06:24 EDT 2012

IN transaction

When exactly is the TRNIF for the IN transaction set?  Figure 17-9
indicates that it is after a transaction is complete.

So, to send data on an IN endpoint, update BD and transfer it to USB
transceiver.  Whenever it receives an IN token it sends out the data
and after receiving an ACK from the host, it sets TRNIF.

With IN implemented I see stuff on the wire, but the serial port side
doesn't do anything.  Probably needs OUT too.

So.. now I see a bunch of data on both endpoints, but still nothing on
the serial side.  Overlooking something..  Oops.. going a bit too hard?

[17504.255316] ------------[ cut here ]------------
[17504.255334] WARNING: at drivers/usb/serial/usb-serial.c:410 serial_unthrottle+0x53/0x72 [usbserial]()
[17504.255342] Hardware name: Aspire M3400
[17504.255346] Modules linked in: ftdi_sio usbserial binfmt_misc ppdev lp sco bnep l2cap crc16 bluetooth rfkill vmnet parport_pc parport vmblock vsock vmci vmmon autofs4 powernow_k8 cpufreq_stats cpufreq_powersave cpufreq_conservative cpufreq_userspace cpufreq_ondemand freq_table nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc act_police sch_ingress cls_u32 sch_sfq sch_cbq 8021q ipt_MASQUERADE xt_tcpudp xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables bridge stp fuse radeon ttm drm_kms_helper drm i2c_algo_bit tun kvm_amd kvm dm_mirror dm_region_hash dm_log sbp2 ieee1394 loop usbhid hid snd_hda_codec_atihdmi snd_ice1712 snd_ice17xx_ak4xxx snd_ak4xxx_adda snd_cs8427 snd_ac97_codec snd_hda_codec_realtek snd_seq_dummy ac97_bus snd_i2c snd_mpu401_uart snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_hda_intel snd_hda_codec psmouse snd_pcm_oss snd_mixer_oss snd_seq snd_pcm i2c_piix4 shpchp snd_timer snd_seq_device snd i2c_core soundcore serio_raw snd_page_alloc button processor pci_hotplug evdev wmi ext3 jbd mbcache dm_mod sr_mod cdrom sd_mod usb_storage ohci_hcd ahci r8169 libata thermal mii thermal_sys scsi_mod ehci_hcd [last unloaded: usbserial]
[17504.255566] Pid: 7475, comm: cat Tainted: G        W #1
[17504.255571] Call Trace:
[17504.255586]  [<ffffffff8103c61f>] ? warn_slowpath_common+0x76/0x8d
[17504.255597]  [<ffffffffa06802ca>] ? serial_unthrottle+0x53/0x72 [usbserial]
[17504.255608]  [<ffffffff811def55>] ? tty_unthrottle+0x39/0x45
[17504.255616]  [<ffffffff811dda78>] ? n_tty_flush_buffer+0xe/0x67
[17504.255625]  [<ffffffff811e0993>] ? tty_ldisc_flush+0x27/0x3c
[17504.255634]  [<ffffffff811e1332>] ? tty_port_close_start+0x13b/0x163
[17504.255643]  [<ffffffff811e176f>] ? tty_port_close+0x11/0x41
[17504.255651]  [<ffffffff811db440>] ? tty_release+0x23c/0x578
[17504.255661]  [<ffffffff810c485e>] ? handle_mm_fault+0x3cb/0x79a
[17504.255669]  [<ffffffff812ee201>] ? rt_spin_lock+0x29/0x6d
[17504.255678]  [<ffffffff810dd642>] ? __fput+0x10e/0x1e2
[17504.255686]  [<ffffffff810da8ad>] ? filp_close+0x5f/0x6a
[17504.255693]  [<ffffffff810da95a>] ? sys_close+0xa2/0xdb
[17504.255701]  [<ffffffff81002b02>] ? system_call_fastpath+0x16/0x1b
[17504.255708] ---[ end trace b863518ac3707459 ]---

EDIT: This is probably because 64 bytes is not a short packet, and
host keeps polling, so the transfer never stops.

Maybe it's the CRC?  Doesn't look like it.  From what I see in PIC DS
this is handled by the transceiver.  Maybe it needs a stall packet?

From [1]:

  IN: When the host is ready to receive bulk data it issues an IN
  Token. If the function receives the IN token with an error, it
  ignores the packet. If the token was received correctly, the
  function can either reply with a DATA packet containing the bulk
  data to be sent, or a stall packet indicating the endpoint has had a
  error or a NAK packet indicating to the host that the endpoint is
  working, but temporary has no data to send.  

Searching for NAK in the PIC DS doesn't turn up an explicit mechanism.
Maybe just not send stuff?

Ok, this goes a little better.  OUT now seems to work: when I cat a
file to /dev/ttyUSB it goes over the wire in its entirety.  However,
the IN stuff is still weird.  In response to IN, host sends an OUT
transaction.  Maybe there's a handshake?  Or is the IN data
interpreted in some way?

Wait, this could just be TTY stuff in response to the codes sent by
the device.  Let's just send characters.

It's probably because echo is on.

And the fact I don't see anything is probably because of line
buffering.  Adding CR/LF to the string gives this:

broebel:/home/tom# cat /dev/ttyUSB0

Looks like it's working!

[1] http://www.beyondlogic.org/usbnutshell/usb4.shtml#Bulk