On Fri, Aug 08, 2014 at 09:54:42AM +0200, Johan Hovold wrote: > On Fri, Aug 08, 2014 at 03:10:34AM +0800, Wang YanQing wrote: > > On Tue, Aug 05, 2014 at 03:54:08PM +0200, Johan Hovold wrote: > > > > > I noticed that setting direction to output and setting the gpio high has > > > > > no effect on the read-back value (i.e. I still read back 0) for my > > > > > pl2303hx (note that my device has no easily accessible gpios so I > > > > > haven't verified the actual state of the output pin). > > > > > > > > > > What happens on your system? Is the read-back value still 0, even when > > > > > the GPIO output is actually high? Should we return the cached value in > > > > > this case? > > > > > > > > If i set direction to output, then I could control gpio high and low > > > > by set 1 or 0, and the read-back value is 1 or 0 according to high and > > > > low(I test high and low by oscillscope) > > > > > > > > I test it with my pl2303hx with only two gpios. > > > > > > > > Could you use usbmon to see whether the traffic is right according > > > > to comment in struct pl2303_gpio? > > > > > > The traffic appears correct judging from the debug output (which I > > > trust). Output-enable is reflected in register 0x81, but the value > > > isn't. > > > > > > What is the lsusb -v output for your device? > > > > Bus 001 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port. > > You forgot the verbose flag (-v). Sorry, below is output with -v: Bus 002 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x067b Prolific Technology, Inc. idProduct 0x2303 PL2303 Serial Port bcdDevice 3.00 iManufacturer 1 Prolific Technology Inc. iProduct 2 USB-Serial Controller iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) > > > It is strange your device doesn't work, I verify the control method by > > analyze usbmon output from linux host which has VirtualBox running > > gpio test program, but I don't have right to distribute the gpio test > > program I think, so I can't help you to figure out why it doesn't work > > for your device. > > What do you use the gpio test program for? I thought you verified the > gpios with a scope? Yes, I verified gpios with a scope. " You must allocate the buffer dynamically as some platforms cannot do DMA to the stack. " Thanks very much for point out it, could you clarify it? I want to know the reason. I am working on next version patch and hope it could be finished this weekend. :) Thanks again. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html