From owner-freebsd-usb@FreeBSD.ORG Fri Sep 3 13:56:58 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0967210656D1 for ; Fri, 3 Sep 2010 13:56:58 +0000 (UTC) (envelope-from tuksgig@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id CD35E8FC1B for ; Fri, 3 Sep 2010 13:56:57 +0000 (UTC) Received: by pvg4 with SMTP id 4so732346pvg.13 for ; Fri, 03 Sep 2010 06:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+LlCTQ+SorRX+rOxKK8Yzaa0rYNC8GY4oGg+sa6apBc=; b=dS0v6aZOW9tk7JIHVgBsgMX2QidLcDOBY0157FJIDrUYSmU4T4DDXUELapUUGcAZUA jXEf3k85qJTV1AmybrjI4KGpX+Mc+s52eZGKitJg7cb3ajVDoDC5GaBqyrfIGJi4eAE/ f+p1FvSyHcSLpxmt8H5grotJvOiut4wYgbNMM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xiaY7yvG23QtIvEyBYXeuCtW3/O9KuZbP3b3KTpL+CuHHVSol7BcJKU8EK7xVq9gOD Bbs6ar/E5jWElmt52OaHXPZdRDL1UhtL0ruNISu3NnOs+KhOVdTWiW02A5UZPfFOQZQI IVuuqctOQtZ0CrITyZTwCVtC2LOs9kv946gyM= MIME-Version: 1.0 Received: by 10.114.39.18 with SMTP id m18mr45380wam.196.1283522210376; Fri, 03 Sep 2010 06:56:50 -0700 (PDT) Received: by 10.220.86.143 with HTTP; Fri, 3 Sep 2010 06:56:49 -0700 (PDT) In-Reply-To: <201008310947.07460.hselasky@c2i.net> References: <201008302113.33960.hselasky@c2i.net> <201008310947.07460.hselasky@c2i.net> Date: Fri, 3 Sep 2010 15:56:49 +0200 Message-ID: From: Piet Skiet To: Hans Petter Selasky Content-Type: multipart/mixed; boundary=001636417e496a4162048f5b4d0f Cc: freebsd-usb@freebsd.org Subject: Re: USB synchronous control transfers (for usb-to-serial) X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 13:56:58 -0000 --001636417e496a4162048f5b4d0f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 31, 2010 at 9:47 AM, Hans Petter Selasky wrote: > On Tuesday 31 August 2010 09:39:46 Piet Skiet wrote: >> On Mon, Aug 30, 2010 at 9:13 PM, Hans Petter Selasky > wrote: >> > On Monday 30 August 2010 14:41:56 Piet Skiet wrote: >> >> On Mon, Aug 30, 2010 at 10:51 AM, Piet Skiet wrote: >> >> > Hi, >> >> > >> >> > Can anyone clarify how to go about doing a synchronous usb control >> >> > transfer, similar to Linux's usb_control_msg? I want to implement the >> >> > TIOCMGET ioctl on a usb-to-serial converter. The Linux driver uses >> >> > synchronous control messages to read DCE and CTS serial pin status, >> >> > and I want to do something similar in FreeBSD. The usbdi(9) manpage >> >> > talks about control transfers using usbd_transfer_submit, but they're >> >> > not synchronous. What about using usbd_transfer_drain? Is there an >> >> > example driver showing setting up and doing control transfers? >> >> > >> >> > The ucom driver seems to only implement TIOCSBRK and TIOCCBRK iotcls >> >> > at the moment. >> >> > >> >> > Thanks >> >> >> >> Scanning through the ucom code, it seems to me that the >> >> usbd_do_request_proc has somehting to do with blocking control >> >> transfers. Am I on the right track here? >> > >> > Yes, this is correct. You have to re-format the do request information a >> > little bit compared with Linux. This function is supposed to be called >> > from a UCOM callback. Please also check recent changes in USB P4: >> > >> > http://p4web.freebsd.org/@md=d&cd=//depot/projects/usb/src/sys/dev/usb/co >> > ntroller/&cdf=//depot/projects/usb/src/sys/dev/usb/serial/usb_serial.c&c= >> > LJN@//depot/projects/usb/src/sys/dev/usb/serial/usb_serial.c?ac=22 >> > >> > --HPS >> >> OK, but I'm still a bit confused. I'm not sure in which callback to >> put the usb_do_request. For instance, the driver that I'm interested >> in is the uslcom.c driver for the cp210x usb-to-serial converter. It >> has two usb_config structs defined of type UE_BULK for read and write >> transfers. Do I need to add a third usb_config struct for UE_CONTROL? >> Should the usb_do_request then be called from the UE_CONTROL callback? > > Hi, > > The usb_config's are for asynchronous operation. The usbd_do_request_proc() > function is synchronous. I.E. it completes when it returns. The reason we have > this variant is to allow smooth exit and entry of the mutex which is locked > when you get callbacks from UCOM. All UCOM callbacks are pre-locked, and if > you don't exit the lock the kernel will complain. > >> The plan is to add a .ucom_ioctl to the uslcom.c driver and implement >> the TIOCMGET directly in the driver ioctl using synchronous usb >> transfers. I've already tested the .ucom_ioctl override and it works, >> now I just need to figure out how to do the usb transfers. >> >> BTW, the FTDI driver (uftdi.c) does things differently. It updates the >> msr (modem status register?) in the bulk read callback and then calls >> ucom_status_change to update any changes to ucom. > > The FTDI driver uses another mechanism to transfer that information. Probably > what you want to do is to add a timer/watchdog to poll that information > regularly. Then you can use a single asynchronous control transfer, and set > the interval of the transfer to 250ms, for example, so that you don't need to > allocate a separate timer to do this. Or maybe 100ms is better. You need to > test this. > > --HPS > Hi, Attached is the patch adding a 250ms polling control transfer to update the port status flags. I've also added CRTSCTS hardware flow control. I did some tests with minicom and with gtkterm. Minicom works perfectly, but gtkterm has problems at baud 115200 and also with hardware flow control. I also testes the Prolific driver (uplcom) with minicom and gtkterm, and gtkterm has the same problems at 115200 baud, so I'm assuming it's a gtkterm bug (not maintained anymore). BTW, do the usb-to-serial drivers need the force_short_xfer usb transfer flag? gtkterm seems to work slightly better without the flag... Anyway, thanks for the help so far --001636417e496a4162048f5b4d0f Content-Type: application/octet-stream; name="uslcom.patch" Content-Disposition: attachment; filename="uslcom.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gdn3jigp0 NjdkNjYKPCAvKiBSZXF1ZXN0IHR5cGVzICovCjcxZDY5CjwgLyogUmVxdWVzdCBjb2RlcyAqLwo3 Nyw3OGQ3NAo8ICNkZWZpbmUgVVNMQ09NX1JDVFJMCQkweDA4CjwgI2RlZmluZSBVU0xDT01fU0VU X0ZMT1dDVFJMCTB4MTMKODBkNzUKPCAvKiBVU0xDT01fVUFSVCB2YWx1ZXMgKi8KODRkNzgKPCAv KiBVU0xDT01fQ1RSTC9VU0xDT01fUkNUUkwgdmFsdWVzICovCjkxZDg0CjwgI2RlZmluZSBVU0xD T01fQ1RSTF9SSQkJMHgwMDQwCjk0ZDg2CjwgLyogVVNMQ09NX0JBVURfUkFURSB2YWx1ZXMgKi8K OTdkODgKPCAvKiBVU0xDT01fREFUQSB2YWx1ZXMgKi8KOTlhOTEKPiAKMTA2ZDk3CjwgLyogVVNM Q09NX0JSRUFLIHZhbHVlcyAqLwoxMTAsMTE3ZDEwMAo8IC8qIFVTTENPTV9TRVRfRkxPV0NUUkwg dmFsdWVzIC0gMXN0IHdvcmQgKi8KPCAjZGVmaW5lIFVTTENPTV9GTE9XX0RUUl9PTgkweDAwMDAw MDAxCjwgI2RlZmluZSBVU0xDT01fRkxPV19DVFNfSFMJMHgwMDAwMDAwOCAvKiBDVFMgaGFuZHNo YWtlICovCjwgI2RlZmluZSBVU0xDT01fRkxPV19SRVNFUlZFRAkweEZGRkZGRjgwCjwgLyogVVNM Q09NX1NFVF9GTE9XQ1RSTCB2YWx1ZXMgLSAybmQgd29yZCAqLwo8ICNkZWZpbmUgVVNMQ09NX0ZM T1dfUlRTX09OCTB4MDAwMDAwNDANCjwgI2RlZmluZSBVU0xDT01fRkxPV19SVFNfSFMJMHgwMDAw MDA4MCAvKiBSVFMgaGFuZHNoYWtlICovCjwgCjEyMWQxMDMKPCAJVVNMQ09NX0NUUkxfRFRfUkQs CjE0M2QxMjQKPCBzdGF0aWMgdXNiX2NhbGxiYWNrX3QgdXNsY29tX2NvbnRyb2xfY2FsbGJhY2s7 CjE2NmMxNDcKPCAJCS5mbGFncyA9IHsucGlwZV9ib2YgPSAxLC8qLmZvcmNlX3Nob3J0X3hmZXIg PSAxLCovfSwKLS0tCj4gCQkuZmxhZ3MgPSB7LnBpcGVfYm9mID0gMSwuZm9yY2Vfc2hvcnRfeGZl ciA9IDEsfSwKMTc4LDE4NmQxNTgKPCAJW1VTTENPTV9DVFJMX0RUX1JEXSA9IHsKPCAJCS50eXBl ID0gVUVfQ09OVFJPTCwKPCAJCS5lbmRwb2ludCA9IDB4MDAsCjwgCQkuZGlyZWN0aW9uID0gVUVf RElSX0FOWSwKPCAJCS5pbnRlcnZhbCA9IDI1MCwgLyogcG9sbCBzdGF0dXMgZXZlcnkgMjUwIG1z ICovCjwgCQkuYnVmc2l6ZSA9IFVTTENPTV9CVUxLX0JVRl9TSVpFLAo8IAkJLmZsYWdzID0gey5w aXBlX2JvZiA9IDEsLnNob3J0X3hmZXJfb2sgPSAxLH0sCjwgCQkuY2FsbGJhY2sgPSAmdXNsY29t X2NvbnRyb2xfY2FsbGJhY2ssCjwgCX0sCjI5M2QyNjQKPCAJdXNiZF94ZmVyX3NldF9zdGFsbChz Yy0+c2NfeGZlcltVU0xDT01fQ1RSTF9EVF9SRF0pOwozMzgsMzM5ZDMwOAo8IAkvKiBTdGFydCBw b2xsaW5nIHN0YXR1cyAqLwo8IAl1c2JkX3RyYW5zZmVyX3N0YXJ0KHNjLT5zY194ZmVyW1VTTENP TV9DVFJMX0RUX1JEXSk7CjM0OCwzNTBkMzE2CjwgCS8qIFN0b3AgcG9sbGluZyBzdGF0dXMgKi8K PCAJdXNiZF90cmFuc2Zlcl9zdG9wKHNjLT5zY194ZmVyW1VTTENPTV9DVFJMX0RUX1JEXSk7Cjwg CjQyNWQzOTAKPCAJdWludDMyX3QgZmxvd2N0cmxbNF07CjQ3Niw0OTVkNDQwCjwgCQo8IAlpZiAo dC0+Y19jZmxhZyAmIENSVFNDVFMpIHsKPCAJCWZsb3djdHJsWzBdID0gVVNMQ09NX0ZMT1dfUkVT RVJWRUQgfCBVU0xDT01fRkxPV19EVFJfT04gfCAKPCAJCQlVU0xDT01fRkxPV19DVFNfSFM7Cjwg CQlmbG93Y3RybFsxXSA9IFVTTENPTV9GTE9XX1JUU19IUzsKPCAJfSBlbHNlIHsKPCAJCWZsb3dj dHJsWzBdID0gVVNMQ09NX0ZMT1dfUkVTRVJWRUQgfCBVU0xDT01fRkxPV19EVFJfT047CjwgCQlm bG93Y3RybFsxXSA9IFVTTENPTV9GTE9XX1JUU19PTjsKPCAJfQo8IAlyZXEuYm1SZXF1ZXN0VHlw ZSA9IFVTTENPTV9XUklURTsKPCAJcmVxLmJSZXF1ZXN0ID0gVVNMQ09NX1NFVF9GTE9XQ1RSTDsK PCAJVVNFVFcocmVxLndWYWx1ZSwgMCk7CjwgCVVTRVRXKHJlcS53SW5kZXgsIFVTTENPTV9QT1JU X05PKTsKPCAJVVNFVFcocmVxLndMZW5ndGgsIHNpemVvZihmbG93Y3RybCkpOwo8IAo8ICAgICAg ICAgaWYgKHVjb21fY2ZnX2RvX3JlcXVlc3Qoc2MtPnNjX3VkZXYsICZzYy0+c2NfdWNvbSwgCjwg CSAgICAmcmVxLCBmbG93Y3RybCwgMCwgMTAwMCkpIHsKPCAJCURQUklOVEYoIlNldCBmbG93Y29u dHJvbCBmYWlsZWQgKGlnbm9yZWQpXG4iKTsKPCAJfQo8IAkKNTkyLDY0NmQ1MzYKPCB1c2xjb21f Y29udHJvbF9jYWxsYmFjayhzdHJ1Y3QgdXNiX3hmZXIgKnhmZXIsIHVzYl9lcnJvcl90IGVycm9y KQo8IHsKPCAJc3RydWN0IHVzbGNvbV9zb2Z0YyAqc2MgPSB1c2JkX3hmZXJfc29mdGMoeGZlcik7 CjwgCXN0cnVjdCB1c2JfcGFnZV9jYWNoZSAqcGM7CjwgCXVpbnQ4X3QgYnVmOwo8IAlzdHJ1Y3Qg dXNiX2RldmljZV9yZXF1ZXN0IHJlcTsKPCAJdWludDhfdCBtc3IgPSAwOwo8IAo8IAlzd2l0Y2gg KFVTQl9HRVRfU1RBVEUoeGZlcikpIHsKPCAJY2FzZSBVU0JfU1RfVFJBTlNGRVJSRUQ6CjwgCQlw YyA9IHVzYmRfeGZlcl9nZXRfZnJhbWUoeGZlciwgMSk7CjwgCQl1c2JkX2NvcHlfb3V0KHBjLCAw LCAmYnVmLCBzaXplb2YoYnVmKSk7CjwgCQlpZiAoYnVmICYgVVNMQ09NX0NUUkxfQ1RTKQo8IAkJ CW1zciB8PSBTRVJfQ1RTOwo8IAkJaWYgKGJ1ZiAmIFVTTENPTV9DVFJMX0RTUikKPCAJCQltc3Ig fD0gU0VSX0RTUjsKPCAJCWlmIChidWYgJiBVU0xDT01fQ1RSTF9SSSkKPCAJCQltc3IgfD0gU0VS X1JJOwo8IAkJaWYgKGJ1ZiAmIFVTTENPTV9DVFJMX0RDRCkKPCAJCQltc3IgfD0gU0VSX0RDRDsK PCAKPCAJCWlmIChtc3IgIT0gc2MtPnNjX21zcikgewo8IAkJCURQUklOVEYoInN0YXR1cyBjaGFu Z2UgbXNyPTB4JTAyeCAod2FzIDB4JTAyeClcbiIsIG1zciwgc2MtPnNjX21zcik7CjwgCQkJc2Mt PnNjX21zciA9IG1zcjsKPCAJCQl1Y29tX3N0YXR1c19jaGFuZ2UoJnNjLT5zY191Y29tKTsKPCAJ CX0KPCAJCS8qIG5vIGJyZWFrICovCjwgCWNhc2UgVVNCX1NUX1NFVFVQOgo8IHRyX3NldHVwOgkJ CjwgCQlyZXEuYm1SZXF1ZXN0VHlwZSA9IFVTTENPTV9SRUFEOwo8IAkJcmVxLmJSZXF1ZXN0ID0g VVNMQ09NX1JDVFJMOwo8IAkJVVNFVFcocmVxLndWYWx1ZSwgMCk7CjwgCQlVU0VUVyhyZXEud0lu ZGV4LCAwKTsKPCAJCVVTRVRXKHJlcS53TGVuZ3RoLCBzaXplb2YoYnVmKSk7CjwgCQkKPCAJCXVz YmRfeGZlcl9zZXRfZnJhbWVzKHhmZXIsIDIpOwo8IAkJdXNiZF94ZmVyX3NldF9mcmFtZV9sZW4o eGZlciwgMCwgc2l6ZW9mKHJlcSkpOwo8IAkJdXNiZF94ZmVyX3NldF9mcmFtZV9sZW4oeGZlciwg MSwgc2l6ZW9mKGJ1ZikpOwo8IAo8IAkJcGMgPSB1c2JkX3hmZXJfZ2V0X2ZyYW1lKHhmZXIsIDAp Owo8IAkJdXNiZF9jb3B5X2luKHBjLCAwLCAmcmVxLCBzaXplb2YocmVxKSk7CjwgCQl1c2JkX3Ry YW5zZmVyX3N1Ym1pdCh4ZmVyKTsKPCAJCXJldHVybjsKPCAKPCAJZGVmYXVsdDoJCQkvKiBFcnJv ciAqLwo8IAkJaWYgKGVycm9yICE9IFVTQl9FUlJfQ0FOQ0VMTEVEKSB7CjwgCQkJLyogdHJ5IHRv IGNsZWFyIHN0YWxsIGZpcnN0ICovCjwgCQkJdXNiZF94ZmVyX3NldF9zdGFsbCh4ZmVyKTsKPCAJ CQlnb3RvIHRyX3NldHVwOwo8IAkJfQo8IAkJcmV0dXJuOwo8IAl9CjwgfQo8IAo8IHN0YXRpYyB2 b2lkCg== --001636417e496a4162048f5b4d0f--