lkml.org 
[lkml]   [2014]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Resend Re: [PATCH v6] usb:serial:pl2303: add GPIOs interface on PL2303
On Tue, Aug 12, 2014 at 04:02:59PM +0200, Johan Hovold wrote:
> On Sat, Aug 09, 2014 at 02:46:56AM +0800, Wang YanQing wrote:
> > 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
>
> You seem to have an HX device, whereas mine is an HXD (rev D) with
> bcdDevice 4.00. That could account for the different behaviour of the
> GPIO state/value register.
>
> How did you figure out which registers to use? Were you sniffing the
> traffic of some driver for some other OS? And does your device only have
> two GPIOs and not four like the HX rev D?

After I found I need to use GPIOs in pl2303, I found below patch in Internet firstly:
http://comments.gmane.org/gmane.linux.usb.general/65066

Then I verified the protocol by sniffing the traffic of some driver for some other
OS running in virtualbox, and host OS is linux:)

Prolific has pl2303 gpio test program (.exe) for windows, maybe you could find it
from Internet. It support HXA and HXD, I use it to test two gpios in my pl2303HXA,
and analyze output of usbmon.

Yes, my device only have two GPIOs.
> <snip>
>
> > > > 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.
>
> The memory where the stack resides might not be available for DMA, and
> even if it is, there could still be problems with cache coherency.

It is still vague:
stack memory maybe resident higher place than normal memory,
but I don't think kmalloc could be immune from this problem, unless
we use GFP_DMA?


\
 
 \ /
  Last update: 2014-08-28 02:01    [W:0.077 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site