Re: usbserial_generic, idVendor=1a28, idProduct=6010

2014-02-23 Thread Emanuel Koczwara 

Hi,

W dniu 18.02.2014 10:36, Johan Hovold pisze:

On Sun, Feb 16, 2014 at 12:35:06PM +0100, Emanuel Koczwara wrote:

Hi,

I have a device (thermal printer) which communicates through rs232. It
has also usb adapter/converter build-in.

root@emanuel-laptop:/home/emanuel# lsusb
Bus 004 Device 004: ID 8086:0189 Intel Corp.
Bus 004 Device 008: ID 1a28:6010 <-- here

Who is the manufacturer and what is the model?


http://www.novitus.pl/pl/produkty/systemy-fiskalne/bono-e.html

It is a fiscal printer used in Poland produced by NOVITUS. I have BONO E 
1.10.





Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 003: ID 0458:003a KYE Systems Corp. (Mouse Systems)
NetScroll+ Mini Traveler / Genius NetScroll 120
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 05ca:181f Ricoh Co., Ltd
Bus 001 Device 003: ID 138a:0011 Validity Sensors, Inc. VFS5011
Fingerprint Reader
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@emanuel-laptop:/home/emanuel# lsusb -d 1a28:6010 -v
Bus 004 Device 008: ID 1a28:6010
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB   2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor   0x1a28
idProduct  0x6010
bcdDevice5.00
iManufacturer   4 (error)
iProduct   14 (error)
iSerial 0
bNumConfigurations  1
Configuration Descriptor:
  bLength 9
  bDescriptorType 2
  wTotalLength   55
  bNumInterfaces  2
  bConfigurationValue 1
  iConfiguration  0
  bmAttributes 0x80
(Bus Powered)
  MaxPower   90mA
  Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting   0
bNumEndpoints   2
bInterfaceClass   255 Vendor Specific Class
bInterfaceSubClass255 Vendor Specific Subclass
bInterfaceProtocol255 Vendor Specific Protocol
iInterface 14 (error)
Endpoint Descriptor:
  bLength 7
  bDescriptorType 5
  bEndpointAddress 0x81  EP 1 IN
  bmAttributes2
Transfer TypeBulk
Synch Type   None
Usage Type   Data
  wMaxPacketSize 0x0040  1x 64 bytes
  bInterval   0
Endpoint Descriptor:
  bLength 7
  bDescriptorType 5
  bEndpointAddress 0x02  EP 2 OUT
  bmAttributes2
Transfer TypeBulk
Synch Type   None
Usage Type   Data
  wMaxPacketSize 0x0040  1x 64 bytes
  bInterval   0
  Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber1
bAlternateSetting   0
bNumEndpoints   2
bInterfaceClass   255 Vendor Specific Class
bInterfaceSubClass255 Vendor Specific Subclass
bInterfaceProtocol255 Vendor Specific Protocol
iInterface 14 (error)
Endpoint Descriptor:
  bLength 7
  bDescriptorType 5
  bEndpointAddress 0x83  EP 3 IN
  bmAttributes2
Transfer TypeBulk
Synch Type   None
Usage Type   Data
  wMaxPacketSize 0x0040  1x 64 bytes
  bInterval   0
Endpoint Descriptor:
  bLength 7
  bDescriptorType 5
  bEndpointAddress 0x04  EP 4 OUT
  bmAttributes2
Transfer TypeBulk
Synch Type   None
Usage Type   Data
  wMaxPacketSize 0x0040  1x 64 bytes
  bInterval   0
Device Status: 0x0001
Self Powered

After 'modprobe usbserial vendor=0x1a28 product=0x6010' the device is
working, /dev/ttyUSB0 pops out. I can read and write to /dev/ttyUSB0 and
it responds.

[34449.932999] usb 4-1.3: new full-speed USB device number 8 using ehci-pci
[34450.029508] usb 4-1.3: string descriptor 0 read error: -32
[34450.029521] usb 4-1.3: New USB device found, idVendor=1a28,
idProduct=6010
[34450.029526] usb 4-1.3: New USB device strings: Mfr=4, Product=14,
SerialNumber=0
[

Re: is it possible to temporarily not let user mode get hid input event

2014-02-23 Thread David Herrmann 
Hi

On Sun, Feb 23, 2014 at 7:52 AM, loody  wrote:
> hi David:
>
> Thanks for your suggestion.
> 2014-02-23 0:56 GMT+08:00 David Herrmann :
>> Hi
>>
>> On Sat, Feb 22, 2014 at 5:35 PM, loody  wrote:
>>> hi all:
>>> is there any kernel hid module parameter or test program can
>>> temporarily not letting user mode program not receiving hid event?
>>> 1. My hid kos are still inserted in.
>>> 2. the kernel usb driver is working well; that mean kernel usb driver
>>> still handle interrupt transaction.
>>>
>>> I just not want user mode program see the hid event for a while,
>>
>> For each connected HID device, there is a driver bound to it that
>> reads the events and forwards them to HID core. What you can do, is to
>> unbind a driver on a given device:
>>   echo "" >/sys/bus/hid/drivers//unbind
>> The device-name is the directory name in:
>>   /sys/bus/hid/devices/
>> The driver name is usually "hid-generic" but can be figured out for
>> each device by looking at the "driver" symlink in it's directry.
>> However, this is *really* just meant for debugging. This is not
>> recommended for anything serious. There is no support for that and if
>> you don't know what all this does, you shouldn't use it.
>>
>> There is no proper way to disable a single device in the kernel.
>> User-space is supposed to control device-access so we probably won't
>> add such features to the kernel. If you describe your use-case in more
>> details, we can try to give hints how to get that working.
>
> Sorry for not describing our situation clearer previously,
>
> The problem we met like below
> a. once plug in usb hid mouse and fast moving mouse
> b. the screen will get blur.
>
> We want to know whether the screen blur is caused by
> 1. the interrupt frequency of usb mouse is too high for our embedded
> system that make video decode slow
> 2. something wrong between hw cursor and video overlay.
>
> if we can deceive user mode program there is no mouse event, but
> kernel usb level still get hid interrupt transaction.
> We may clarify whether above 1) conclusion is correct.
>
> Appreciate your kind help :-)

You can unload the HID driver as described above, but that's unlikely
to fix any interrupt issues. How about you compile your kernel without
usbhid support? (CONFIG_USB_HID)

David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB Serial constantly polling

2014-02-23 Thread Greg KH 
On Sun, Feb 23, 2014 at 06:27:17AM +, Luke-Jr wrote:
> If I understand the USB Serial code correctly, at least open devices are 
> constantly polled by 2 active URBs replaced immediately upon completion, 
> except when the tty layer throttles them.

It depends on the specific driver, what one are you referring to?

And this is the way that the USB protocol works, a device can not send
data to the host unless it is asked for it.  So the host always has to
ask for it.

> With many of these devices, this creates significant USB bandwidth usage. At 
> least one report found that it starts creating practical problems after 12 
> devices (on a BeagleBone), while adding a delay allows up to 60.

That sounds like a bug in the BeagleBone USB host hardware.  It's as if
people didn't learn the problems of the UHCI controller from the 1990's,
which had the same issue :)

> Is there any reason not to have some small delay (perhaps user-configurable) 
> between URB requests, at least while the device is not actively receiving 
> data? If a patch is needed to implement this, what would be the recommended 
> approach for a kernel complete-newbie?

I bet the same thing happens if you plug in 12 keyboards.  This isn't a
USB driver problem, but rather an issue with the hardware used in the
BeagleBone USB host controller.  Maybe it just can't handle more than 12
devices plugged into it due to memory / slicon limitations.

Note, the rpi also has the same issue, if you plug in a single USB
keyboard, you used to loose 30% of your CPU.  I hope that issue has been
resolved, but it wasn't going to be easy given the hardware chosen in
that device.

good luck,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB Serial constantly polling

2014-02-23 Thread Johan Hovold 
On Sun, Feb 23, 2014 at 06:27:17AM +, Luke-Jr wrote:
> If I understand the USB Serial code correctly, at least open devices are 
> constantly polled by 2 active URBs replaced immediately upon completion, 
> except when the tty layer throttles them.

As Greg mentioned, it depends on what driver you're using but the
generic implementation, which most drivers use, has two bulk-in urbs.

> With many of these devices, this creates significant USB bandwidth usage. At 
> least one report found that it starts creating practical problems after 12 
> devices (on a BeagleBone), while adding a delay allows up to 60.

What driver are you using here?

In general this should not cause any problems, but for example the
ftdi_sio driver has the low-latency flag set by default which results in
bulk-in data (mostly empty, status-only packets) being received
every millisecond.

If the flag is cleared (e.g. using setserial) the latency can be
increased through sysfs (defaults to 16ms).

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usbserial_generic, idVendor=1a28, idProduct=6010

2014-02-23 Thread Johan Hovold 
On Sun, Feb 23, 2014 at 03:40:58PM +0100, Emanuel Koczwara wrote:
> W dniu 18.02.2014 10:36, Johan Hovold pisze:
> > On Sun, Feb 16, 2014 at 12:35:06PM +0100, Emanuel Koczwara wrote:

> >> I have just one problem with that device. This is typical response from
> >> the printer:
> >>
> >> 1#X0;0;0;1;1;1;14;02;05/23.00/08.00/00.00/05.00/17/0.00/0.001`/0.00/0.00/0.00/284.00/BCM11034990
> >>
> >> and this "1`" inside is strange, so I investigated further:
> >>
> >> emanuel@emanuel-laptop:~$ cat /dev/ttyUSB0
> >> 1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`1`^C
> >>
> >> What can I do with that? Is it becouse the generic driver?
> > Not likely. What happens if you open the device using a terminal program
> > such as minicom?
> 
> Using minicom I get the same constant stream of data.

Perhaps the printer is sending some status bytes that we shouldn't pass
to user space. Could you provide a log from when you send a command and
get a response while running with debugging enabled? You can enable
debugging with

echo "module usbserial +p" >/sys/kernel/debug/dynamic_debug/control

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB to Serial converter code pl2303

2014-02-23 Thread Johan Hovold 
On Thu, Feb 20, 2014 at 09:28:33PM +0100, Magnus wrote:
> Hi,
> 
> I borrowed another converter that uses pl2303 and it worked nicely.
> This device was bought some years ago and mine is new.
> 
> I have taken a picture of both devices here, its valid for a week:
> http://picpaste.com/USB_to_Serial_Adapters-0SALCBSL.png
> 
> One adapter works, the other one doesnt as the picture text describes.

So it does not work at all? Not even at 115200? Have you tried it on
some other OS?

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB Serial constantly polling

2014-02-23 Thread Luke-Jr 
On Sunday, February 23, 2014 5:45:19 PM you wrote:
> In general this should not cause any problems, but for example the
> ftdi_sio driver has the low-latency flag set by default which results in
> bulk-in data (mostly empty, status-only packets) being received
> every millisecond.
> 
> If the flag is cleared (e.g. using setserial) the latency can be
> increased through sysfs (defaults to 16ms).

Thanks, this should help.

(perhaps-waste-of-time-to-read detailed reply to Greg below..)

On Sunday, February 23, 2014 4:14:18 PM Greg KH wrote:
> On Sun, Feb 23, 2014 at 06:27:17AM +, Luke-Jr wrote:
> > If I understand the USB Serial code correctly, at least open devices are
> > constantly polled by 2 active URBs replaced immediately upon completion,
> > except when the tty layer throttles them.
> 
> It depends on the specific driver, what one are you referring to?

I was looking at the circumstances surrounding ftdi_sio, which uses the 
generic implementation.

> And this is the way that the USB protocol works, a device can not send
> data to the host unless it is asked for it.  So the host always has to
> ask for it.

I'm aware of that - but wouldn't it be possible to just ask less often to 
reduce the bandwidth load?

> > With many of these devices, this creates significant USB bandwidth usage.
> > At least one report found that it starts creating practical problems
> > after 12 devices (on a BeagleBone), while adding a delay allows up to
> > 60.
> 
> That sounds like a bug in the BeagleBone USB host hardware.  It's as if
> people didn't learn the problems of the UHCI controller from the 1990's,
> which had the same issue :)

What is the issue? If there are 2 URBs per device going back and forth 
constantly, it's almost certainly going to use more bandwidth than if it was 1 
URB polled every 10 milliseconds (for example). I suppose the controller might 
be able to delay the URBs such that they just start taking longer; is that 
what you expect should happen?

> Note, the rpi also has the same issue, if you plug in a single USB
> keyboard, you used to loose 30% of your CPU.  I hope that issue has been
> resolved, but it wasn't going to be easy given the hardware chosen in
> that device.

As far as I know, this isn't a CPU-load issue.

Luke
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB Serial constantly polling

2014-02-23 Thread Dave Mielke 
[quoted lines by Luke-Jr on 2014/02/23 at 19:03 +]

>I was looking at the circumstances surrounding ftdi_sio, which uses the 
>generic implementation.
>
>wouldn't it be possible to just ask less often to 
>reduce the bandwidth load?

That's sort of what we do in brltty's user-space implementation for serial 
adapters which use bulk input endpoints. And, yes, the ftdi_sio chip is a 
problem since it always has pending data (even if it's just status bits). What 
we do is back off by increasing the delay by powers of 2 up to a maximum as 
long as we're only getting status bytes, but go back to immediate as soon as we 
get data. We also only use a single URB. It works quite well.

-- 
Dave Mielke   | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: d...@mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usbserial_generic, idVendor=1a28, idProduct=6010

2014-02-23 Thread Emanuel Koczwara 

Hi,

W dniu 23.02.2014 18:58, Johan Hovold pisze:
Perhaps the printer is sending some status bytes that we shouldn't 
pass to user space. Could you provide a log from when you send a 
command and get a response while running with debugging enabled? You 
can enable debugging with echo "module usbserial +p" 
>/sys/kernel/debug/dynamic_debug/control 


root@emanuel-laptop:/home/emanuel# echo "module usbserial +p" > 
/sys/kernel/debug/dynamic_debug/control

bash: /sys/kernel/debug/dynamic_debug/control: No such file or directory

How can I enable it?

Thanks,
Emanuel
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usbserial_generic, idVendor=1a28, idProduct=6010

2014-02-23 Thread Emanuel Koczwara 

Hi,

W dniu 23.02.2014 21:10, Emanuel Koczwara pisze:

Hi,

W dniu 23.02.2014 18:58, Johan Hovold pisze:
Perhaps the printer is sending some status bytes that we shouldn't 
pass to user space. Could you provide a log from when you send a 
command and get a response while running with debugging enabled? You 
can enable debugging with echo "module usbserial +p" 
>/sys/kernel/debug/dynamic_debug/control 


root@emanuel-laptop:/home/emanuel# echo "module usbserial +p" > 
/sys/kernel/debug/dynamic_debug/control

bash: /sys/kernel/debug/dynamic_debug/control: No such file or directory



It looks like I need to enable CONFIG_DYNAMIC_DEBUG in my kernel first. 
This will take a while.


Thanks,
Emanuel

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usbserial_generic, idVendor=1a28, idProduct=6010

2014-02-23 Thread Johan Hovold 
On Sun, Feb 23, 2014 at 09:09:53PM +0100, Emanuel Koczwara wrote:
> Hi,
> 
> W dniu 23.02.2014 18:58, Johan Hovold pisze:
> > Perhaps the printer is sending some status bytes that we shouldn't 
> > pass to user space. Could you provide a log from when you send a 
> > command and get a response while running with debugging enabled? You 
> > can enable debugging with echo "module usbserial +p" 
> > >/sys/kernel/debug/dynamic_debug/control 
> 
> root@emanuel-laptop:/home/emanuel# echo "module usbserial +p" > 
> /sys/kernel/debug/dynamic_debug/control
> bash: /sys/kernel/debug/dynamic_debug/control: No such file or directory
> 
> How can I enable it?

You might need to mount debugfs:

mount -t debugfs none /sys/kernel/debug

and make sure your kernel is compiled with CONFIG_DYNAMIC_DEBUG (and
CONFIG_DEBUG_FS) enabled.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB Serial constantly polling

2014-02-23 Thread Greg KH 
On Sun, Feb 23, 2014 at 07:03:54PM +, Luke-Jr wrote:
> On Sunday, February 23, 2014 5:45:19 PM you wrote:
> > In general this should not cause any problems, but for example the
> > ftdi_sio driver has the low-latency flag set by default which results in
> > bulk-in data (mostly empty, status-only packets) being received
> > every millisecond.
> > 
> > If the flag is cleared (e.g. using setserial) the latency can be
> > increased through sysfs (defaults to 16ms).
> 
> Thanks, this should help.
> 
> (perhaps-waste-of-time-to-read detailed reply to Greg below..)
> 
> On Sunday, February 23, 2014 4:14:18 PM Greg KH wrote:
> > On Sun, Feb 23, 2014 at 06:27:17AM +, Luke-Jr wrote:
> > > If I understand the USB Serial code correctly, at least open devices are
> > > constantly polled by 2 active URBs replaced immediately upon completion,
> > > except when the tty layer throttles them.
> > 
> > It depends on the specific driver, what one are you referring to?
> 
> I was looking at the circumstances surrounding ftdi_sio, which uses the 
> generic implementation.
> 
> > And this is the way that the USB protocol works, a device can not send
> > data to the host unless it is asked for it.  So the host always has to
> > ask for it.
> 
> I'm aware of that - but wouldn't it be possible to just ask less often to 
> reduce the bandwidth load?

The device itself specifies what the polling rate is, so the host is
supposed to do what it is told to.  I suggest using a different device
if this is a problem :)

And it's not a big load at all, have you measured it?

> > > With many of these devices, this creates significant USB bandwidth usage.
> > > At least one report found that it starts creating practical problems
> > > after 12 devices (on a BeagleBone), while adding a delay allows up to
> > > 60.
> > 
> > That sounds like a bug in the BeagleBone USB host hardware.  It's as if
> > people didn't learn the problems of the UHCI controller from the 1990's,
> > which had the same issue :)
> 
> What is the issue? If there are 2 URBs per device going back and forth 
> constantly, it's almost certainly going to use more bandwidth than if it was 
> 1 
> URB polled every 10 milliseconds (for example). I suppose the controller 
> might 
> be able to delay the URBs such that they just start taking longer; is that 
> what you expect should happen?

The UHCI "bug" was that for "empty" USB requests, it was burning up the
PCI bandwidth of the whole machine.  Things like that should be done in
hardware, not software, as it's just busy-work that hardware can handle
quite well.

But this is a different issue, real data is being sent, so the
controller has to process it.  Nothing it can do about it (see above for
the "device sets the rate of packets").

> > Note, the rpi also has the same issue, if you plug in a single USB
> > keyboard, you used to loose 30% of your CPU.  I hope that issue has been
> > resolved, but it wasn't going to be easy given the hardware chosen in
> > that device.
> 
> As far as I know, this isn't a CPU-load issue.

What is it then?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB Serial constantly polling

2014-02-23 Thread Peter Stuge 
Luke-Jr wrote:
> > And this is the way that the USB protocol works, a device can not send
> > data to the host unless it is asked for it.  So the host always has to
> > ask for it.
> 
> I'm aware of that - but wouldn't it be possible to just ask less often to 
> reduce the bandwidth load?

It depends on the device hardware. Some USB devices by design (or
perhaps lack thereof) silently discard incoming data if no request
is pending.

It's easy to see why devices do this when considering the increased
complexity of device firmware to queue responses on a bulk-in endpoint
after processing a command on a bulk-out endpoint. It's obviously much
better for everybody involved to use control transfers instead, but
meh who cares about such details, too difficult, let's go shopping.

As was already mentioned, the FTDI protocol is exceptionally poorly
designed in that not only is there in-band overhead for every data
transfer but the protocol also implements its own in-band signalling
as opposed to using the signalling primitives already present in the
lower layers of USB.

This translates to wasted resources throughout the entire system; bus
time, CPU time, power consumption.

Greg's point about the host controller still stands.


> What is the issue?

It seems that the host controller IP fires interrupts too frequently.
Ie. based on the number of transfers as opposed to e.g. bus
utilization.

At first glance that may not seem like a very important distinction
but there is, as always, quite a significant difference between
that-seems-ok-lets-ship-it technology and something well-understood.


> I suppose the controller might be able to delay the URBs such that
> they just start taking longer; is that what you expect should happen?

An efficient HC design would at a minimum coalesce interrupts for
things that occur $close_enough to each other, making use of
knowledge about the schedule for the bus.


> As far as I know, this isn't a CPU-load issue.

Then can you investigate and report back on what *is* the issue?

Too high interrupt load is also a kind of CPU-load issue, even if it
doesn't show in top output.


//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/7] IBM Akebono: Add support to the OHCI platform driver for PPC476GTR

2014-02-23 Thread Alistair Popple 
On Fri, 21 Feb 2014 15:16:52 Arnd Bergmann wrote:
> On Friday 21 February 2014 17:31:29 Alistair Popple wrote:
> > +static const struct of_device_id ohci_of_match[] = {
> > +   { .compatible = "usb-ohci", },
> > +   {},
> > +};
> > +
> > 
> >  static const struct platform_device_id ohci_platform_table[] = {
> >  
> > { "ohci-platform", 0 },
> > { }
> > 
> > @@ -198,6 +209,7 @@ static struct platform_driver ohci_platform_driver = {
> > 
> > .owner  = THIS_MODULE,
> > .name   = "ohci-platform",
> > .pm = &ohci_platform_pm_ops,
> > 
> > +   .of_match_table = ohci_of_match,
> > 
> > }
> >  
> >  };
> 
> Linux-next already has a patch to add an of_match_table in this driver,
> using
> 
> static const struct of_device_id ohci_platform_ids[] = {
> { .compatible = "generic-ohci", },
> { }
> };
> 
> I think you should just use that string on your platform.

Excellent! I will drop this patch and use "generic-ohci" instead. Thanks for 
pointing this out.

- Alistair

>   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/7] ECHI Platform: Merge ppc-of EHCI driver into the ehci-platform driver

2014-02-23 Thread Alistair Popple 
On Fri, 21 Feb 2014 10:41:50 Alan Stern wrote:
> On Fri, 21 Feb 2014, Alistair Popple wrote:
> > Currently the ppc-of driver uses the compatibility string
> > "usb-ehci". This means platforms that use device-tree and implement an
> > EHCI compatible interface have to either use the ppc-of driver or add
> > a compatible line to the ehci-platform driver. It would be more
> > appropriate for the platform driver to be compatible with "usb-ehci"
> > as non-powerpc platforms are also beginning to utilise device-tree.
> > 
> > This patch merges the device tree property parsing from ehci-ppc-of
> > into the platform driver and adds a "usb-ehci" compatibility
> > string. The existing ehci-ppc-of driver is removed and the 440EPX
> > specific quirks are added to the ehci-platform driver.
> > 
> > Signed-off-by: Alistair Popple 
> 
> This patch is also out of date.  The compatibility string used by the
> ehci-platform driver is "generic-ehci".

Ok. I will switch to using "generic-ehci" in the Akebono device tree.

> There remains the question of whether to merge ehci-ppc-of into
> ehci-platform.  This would be a rather invasive change, but I suppose
> we could do it.  With adjustments along the lines suggested by Mark
> Rutland.

As I can use "generic-ehci" to support Akebono I will drop this patch. I can 
look at merging ehci-ppc-of at some later date if desired (thanks Mark & Tony 
for reviewing though).

- Alistair

> Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usbserial_generic, idVendor=1a28, idProduct=6010

2014-02-23 Thread Emanuel Koczwara 

Hi,

W dniu 23.02.2014 21:21, Johan Hovold pisze:
You might need to mount debugfs: mount -t debugfs none 
/sys/kernel/debug and make sure your kernel is compiled with 
CONFIG_DYNAMIC_DEBUG (and CONFIG_DEBUG_FS) enabled. Johan -- To 
unsubscribe from this list: send the line "unsubscribe linux-usb" in 
the body of a message to majord...@vger.kernel.org More majordomo info 
at http://vger.kernel.org/majordomo-info.html 


  Here is my debug output: http://nopaste.info/50a31e9ca7.html

  This is interesting:

  usb_serial_generic_read_bulk_callback - urb 0, len 2
  usb_serial_generic_read_bulk_callback - length = 2, data = 31 60

  I'm getting this 31 60 as 1` when I read from /dev/ttyUSB0.

Thanks,
Emanuel

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: chipidea: imx: Use dev_name() for ci_hdrc name to distinguish USBs

2014-02-23 Thread Peter Chen 
On Sat, Feb 22, 2014 at 05:17:58PM +0400, Alexander Shiyan wrote:
> Signed-off-by: Alexander Shiyan 
> ---
>  drivers/usb/chipidea/ci_hdrc_imx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
> b/drivers/usb/chipidea/ci_hdrc_imx.c
> index c00f772..2e58f8d 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -96,7 +96,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>  {
>   struct ci_hdrc_imx_data *data;
>   struct ci_hdrc_platform_data pdata = {
> - .name   = "ci_hdrc_imx",
> + .name   = dev_name(&pdev->dev),
>   .capoffset  = DEF_CAPOFFSET,
>   .flags  = CI_HDRC_REQUIRE_TRANSCEIVER |
> CI_HDRC_DISABLE_STREAMING,
> -- 
> 1.8.3.2
> 
> 
> 

I don't see too much meaningful for this change, and I don't see
the meaning of this entry (.name) and no user is using it.

Care to delete it for chipidea driver, and submit a patch?

Peter

-- 

Best Regards,
Peter Chen

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] usb: phy: delete CONFIG_USB_OTG_FSM

2014-02-23 Thread Peter Chen 
Hi Felipe,

Any comments for this patch?
It is related to our coming otg work, thanks.

Peter

On Fri, Feb 7, 2014 at 1:46 PM, Peter Chen  wrote:
> On Fri, Jan 10, 2014 at 3:54 PM, Peter Chen  wrote:
>> We already have CONFIG_USB_OTG which can cover all CONFIG_USB_OTG_FSM
>> does.
>>
>> Cc: Jun Li 
>> Cc: Anton Tikhomirov 
>> Signed-off-by: Peter Chen 
>> ---
>>  drivers/usb/phy/Kconfig  |   11 +--
>>  drivers/usb/phy/Makefile |2 +-
>>  2 files changed, 2 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
>> index 7d1451d..65e5b68 100644
>> --- a/drivers/usb/phy/Kconfig
>> +++ b/drivers/usb/phy/Kconfig
>> @@ -6,15 +6,6 @@ menu "USB Physical Layer drivers"
>>  config USB_PHY
>> def_bool n
>>
>> -config USB_OTG_FSM
>> -   tristate "USB 2.0 OTG FSM implementation"
>> -   depends on USB
>> -   select USB_OTG
>> -   select USB_PHY
>> -   help
>> - Implements OTG Final State Machine as specified in On-The-Go
>> - and Embedded Host Supplement to the USB Revision 2.0 Specification.
>> -
>>  #
>>  # USB Transceiver Drivers
>>  #
>> @@ -29,7 +20,7 @@ config AB8500_USB
>>
>>  config FSL_USB2_OTG
>> bool "Freescale USB OTG Transceiver Driver"
>> -   depends on USB_EHCI_FSL && USB_FSL_USB2 && USB_OTG_FSM && PM_RUNTIME
>> +   depends on USB_EHCI_FSL && USB_FSL_USB2 && PM_RUNTIME
>> select USB_OTG
>> select USB_PHY
>> help
>> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
>> index be58ada..3e8f831 100644
>> --- a/drivers/usb/phy/Makefile
>> +++ b/drivers/usb/phy/Makefile
>> @@ -3,7 +3,7 @@
>>  #
>>  obj-$(CONFIG_USB_PHY)  += phy.o
>>  obj-$(CONFIG_OF)   += of.o
>> -obj-$(CONFIG_USB_OTG_FSM)  += phy-fsm-usb.o
>> +obj-$(CONFIG_USB_OTG)  += phy-fsm-usb.o
>>
>>  # transceiver drivers, keep the list sorted
>>
>
> Ping...
>
> --
> BR,
> Peter Chen



-- 
BR,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 00/15] Add power management support for mxs phy

2014-02-23 Thread Peter Chen 
The serial adds power management support for MXS PHY, it includes:

- Add one PHY API .set_wakeup, and related API implementation at mxs phy driver
- misc changes and bug fixes for mxs phy to support low power mode and wakeup.

It is based on the lastest Greg's usb-next, 3.14-rc3.

Changes for v11:
- Change the descrition of adding compatible string, and
  add mention that "fsl,imx23-usbphy" is still a fallback
  for other strings. [1/15]

Changes for v10:
- Nothing related with function change.
- It adds dt maintainers to To list, and cc devicet...@vger.kernel.org,
wait dt-maintainer's ack for 1/15, 4/15.
- Add last three dts patches for reference which have already
at Shawn's tree.

Changes for v9:
- Fix the build warning if CONFIG_SUSPEND is not set

Changes for v8:
- Shawn has already applied two dts patches, so delete them at
  v8 version, http://marc.info/?l=linux-arm-kernel&m=138785188404939&w=2
- Using of_get_property to avoid imx6 fail at probe when using old DTB [5/12]
- Do not consider failure if alias id is not existed, it can avoid fail
  at probe when using old DTB [8/12]
- We don't need more changes for [8/12] change due to we use
  "mxs_phy->port_id ==" as condition

Changes for v7:
- Fixed indentation problem at binding doc [1/14]
- s/ganranteed/guaranteed, and add explanation for "auto setting" [3/14]
- add static before SIMPLE_DEV_PM_OPS [13/14]
- add one patch to change usb device description [7/14]
- Delete the .nofity_suspend and .notify_resume due to Felipe
  does not agree to add them as PHY API, will use other ways to implement
  them in future.

Changes for v6:
- Add description for IC bug fixes logic. [9/15]
- Move is_imx6q_phy and is_imx6sl_phy from [9/15] to [14/15] 
- %s/mxs_phy_clock_switch/mxs_phy_clock_switch_delay to reflect
the function meaning more precise [15/15]

Changes for v5:
Add Marc and Michael Grzeschik's commnets
- typo error at [2/15]
- sqhash patches which introducing mxs_phy_disconnect_line and
fixed but at this function. [13/15]
- Introducing flag MXS_PHY_NEED_IP_FIX who stands for the SoCs
who have IC fixes. [2/15, 8/15]
- Delete one patch for low speed connection problem at every rare
situations due to the root cause has still not found.

Peter Chen (15):
  usb: doc: phy-mxs: Add more compatible strings
  usb: phy-mxs: Add platform judgement code
  usb: phy-mxs: Add auto clock and power setting
  usb: doc: phy-mxs: update binding for adding anatop phandle
  usb: phy-mxs: Add anatop regmap
  usb: phy-mxs: change description of usb device speed
  usb: phy-mxs: Enable IC fixes for related SoCs
  usb: phy-mxs: add controller id
  usb: phy: Add set_wakeup API
  usb: phy-mxs: Add implementation of set_wakeup
  usb: phy-mxs: Add system suspend/resume API
  usb: phy-mxs: Add sync time after controller clear phcd
  ARM: dts: mxs: add mxs phy controller id
  ARM: dts: imx6: add anatop phandle for usbphy
  ARM: dts: imx6: add mxs phy controller id

 Documentation/devicetree/bindings/usb/mxs-phy.txt |8 +-
 arch/arm/boot/dts/imx23.dtsi  |1 +
 arch/arm/boot/dts/imx28.dtsi  |2 +
 arch/arm/boot/dts/imx6qdl.dtsi|4 +
 arch/arm/boot/dts/imx6sl.dtsi |4 +
 drivers/usb/phy/phy-mxs-usb.c |  310 -
 include/linux/usb/phy.h   |   16 +
 7 files changed, 330 insertions(+), 15 deletions(-)

-- 
1.7.8


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 11/15] usb: phy-mxs: Add system suspend/resume API

2014-02-23 Thread Peter Chen 
We need this to keep PHY's power on or off during the system
suspend mode. If we need to enable USB wakeup, then we
must keep PHY's power being on during the system suspend mode.
Otherwise, we need to keep PHY's power being off to save power.

Signed-off-by: Peter Chen 
---
 drivers/usb/phy/phy-mxs-usb.c |   61 +
 1 files changed, 61 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index da2eb6c..31ef59f 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -57,6 +57,10 @@
 #define BM_USBPHY_DEBUG_CLKGATEBIT(30)
 
 /* Anatop Registers */
+#define ANADIG_ANA_MISC0   0x150
+#define ANADIG_ANA_MISC0_SET   0x154
+#define ANADIG_ANA_MISC0_CLR   0x158
+
 #define ANADIG_USB1_VBUS_DET_STAT  0x1c0
 #define ANADIG_USB2_VBUS_DET_STAT  0x220
 
@@ -65,6 +69,9 @@
 #define ANADIG_USB2_LOOPBACK_SET   0x244
 #define ANADIG_USB2_LOOPBACK_CLR   0x248
 
+#define BM_ANADIG_ANA_MISC0_STOP_MODE_CONFIG   BIT(12)
+#define BM_ANADIG_ANA_MISC0_STOP_MODE_CONFIG_SL BIT(11)
+
 #define BM_ANADIG_USB1_VBUS_DET_STAT_VBUS_VALIDBIT(3)
 #define BM_ANADIG_USB2_VBUS_DET_STAT_VBUS_VALIDBIT(3)
 
@@ -134,6 +141,16 @@ struct mxs_phy {
int port_id;
 };
 
+static inline bool is_imx6q_phy(struct mxs_phy *mxs_phy)
+{
+   return mxs_phy->data == &imx6q_phy_data;
+}
+
+static inline bool is_imx6sl_phy(struct mxs_phy *mxs_phy)
+{
+   return mxs_phy->data == &imx6sl_phy_data;
+}
+
 static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
 {
int ret;
@@ -387,6 +404,8 @@ static int mxs_phy_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, mxs_phy);
 
+   device_set_wakeup_capable(&pdev->dev, true);
+
ret = usb_add_phy_dev(&mxs_phy->phy);
if (ret)
return ret;
@@ -403,6 +422,47 @@ static int mxs_phy_remove(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static void mxs_phy_enable_ldo_in_suspend(struct mxs_phy *mxs_phy, bool on)
+{
+   unsigned int reg = on ? ANADIG_ANA_MISC0_SET : ANADIG_ANA_MISC0_CLR;
+
+   /* If the SoCs don't have anatop, quit */
+   if (!mxs_phy->regmap_anatop)
+   return;
+
+   if (is_imx6q_phy(mxs_phy))
+   regmap_write(mxs_phy->regmap_anatop, reg,
+   BM_ANADIG_ANA_MISC0_STOP_MODE_CONFIG);
+   else if (is_imx6sl_phy(mxs_phy))
+   regmap_write(mxs_phy->regmap_anatop,
+   reg, BM_ANADIG_ANA_MISC0_STOP_MODE_CONFIG_SL);
+}
+
+static int mxs_phy_system_suspend(struct device *dev)
+{
+   struct mxs_phy *mxs_phy = dev_get_drvdata(dev);
+
+   if (device_may_wakeup(dev))
+   mxs_phy_enable_ldo_in_suspend(mxs_phy, true);
+
+   return 0;
+}
+
+static int mxs_phy_system_resume(struct device *dev)
+{
+   struct mxs_phy *mxs_phy = dev_get_drvdata(dev);
+
+   if (device_may_wakeup(dev))
+   mxs_phy_enable_ldo_in_suspend(mxs_phy, false);
+
+   return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static SIMPLE_DEV_PM_OPS(mxs_phy_pm, mxs_phy_system_suspend,
+   mxs_phy_system_resume);
+
 static struct platform_driver mxs_phy_driver = {
.probe = mxs_phy_probe,
.remove = mxs_phy_remove,
@@ -410,6 +470,7 @@ static struct platform_driver mxs_phy_driver = {
.name = DRIVER_NAME,
.owner  = THIS_MODULE,
.of_match_table = mxs_phy_dt_ids,
+   .pm = &mxs_phy_pm,
 },
 };
 
-- 
1.7.8


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 10/15] usb: phy-mxs: Add implementation of set_wakeup

2014-02-23 Thread Peter Chen 
When we need the PHY can be waken up by external signals,
we can call this API. Besides, we call mxs_phy_disconnect_line
at this API to close the connection between USB PHY and
controller, after that, the line state from controller is SE0.
Once the PHY is out of power, without calling mxs_phy_disconnect_line,
there are unknown wakeups due to dp/dm floating at device mode.

Signed-off-by: Peter Chen 
---
 drivers/usb/phy/phy-mxs-usb.c |  116 +
 1 files changed, 116 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index 3009ab5..da2eb6c 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -31,6 +31,9 @@
 #define HW_USBPHY_CTRL_SET 0x34
 #define HW_USBPHY_CTRL_CLR 0x38
 
+#define HW_USBPHY_DEBUG_SET0x54
+#define HW_USBPHY_DEBUG_CLR0x58
+
 #define HW_USBPHY_IP   0x90
 #define HW_USBPHY_IP_SET   0x94
 #define HW_USBPHY_IP_CLR   0x98
@@ -39,6 +42,9 @@
 #define BM_USBPHY_CTRL_CLKGATE BIT(30)
 #define BM_USBPHY_CTRL_ENAUTOSET_USBCLKS   BIT(26)
 #define BM_USBPHY_CTRL_ENAUTOCLR_USBCLKGATEBIT(25)
+#define BM_USBPHY_CTRL_ENVBUSCHG_WKUP  BIT(23)
+#define BM_USBPHY_CTRL_ENIDCHG_WKUPBIT(22)
+#define BM_USBPHY_CTRL_ENDPDMCHG_WKUP  BIT(21)
 #define BM_USBPHY_CTRL_ENAUTOCLR_PHY_PWD   BIT(20)
 #define BM_USBPHY_CTRL_ENAUTOCLR_CLKGATE   BIT(19)
 #define BM_USBPHY_CTRL_ENAUTO_PWRON_PLLBIT(18)
@@ -48,6 +54,25 @@
 
 #define BM_USBPHY_IP_FIX   (BIT(17) | BIT(18))
 
+#define BM_USBPHY_DEBUG_CLKGATEBIT(30)
+
+/* Anatop Registers */
+#define ANADIG_USB1_VBUS_DET_STAT  0x1c0
+#define ANADIG_USB2_VBUS_DET_STAT  0x220
+
+#define ANADIG_USB1_LOOPBACK_SET   0x1e4
+#define ANADIG_USB1_LOOPBACK_CLR   0x1e8
+#define ANADIG_USB2_LOOPBACK_SET   0x244
+#define ANADIG_USB2_LOOPBACK_CLR   0x248
+
+#define BM_ANADIG_USB1_VBUS_DET_STAT_VBUS_VALIDBIT(3)
+#define BM_ANADIG_USB2_VBUS_DET_STAT_VBUS_VALIDBIT(3)
+
+#define BM_ANADIG_USB1_LOOPBACK_UTMI_DIG_TST1  BIT(2)
+#define BM_ANADIG_USB1_LOOPBACK_TSTI_TX_EN BIT(5)
+#define BM_ANADIG_USB2_LOOPBACK_UTMI_DIG_TST1  BIT(2)
+#define BM_ANADIG_USB2_LOOPBACK_TSTI_TX_EN BIT(5)
+
 #define to_mxs_phy(p) container_of((p), struct mxs_phy, phy)
 
 /* Do disconnection between PHY and controller without vbus */
@@ -141,6 +166,79 @@ static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
return 0;
 }
 
+/* Return true if the vbus is there */
+static bool mxs_phy_get_vbus_status(struct mxs_phy *mxs_phy)
+{
+   unsigned int vbus_value;
+
+   if (mxs_phy->port_id == 0)
+   regmap_read(mxs_phy->regmap_anatop,
+   ANADIG_USB1_VBUS_DET_STAT,
+   &vbus_value);
+   else if (mxs_phy->port_id == 1)
+   regmap_read(mxs_phy->regmap_anatop,
+   ANADIG_USB2_VBUS_DET_STAT,
+   &vbus_value);
+
+   if (vbus_value & BM_ANADIG_USB1_VBUS_DET_STAT_VBUS_VALID)
+   return true;
+   else
+   return false;
+}
+
+static void __mxs_phy_disconnect_line(struct mxs_phy *mxs_phy, bool disconnect)
+{
+   void __iomem *base = mxs_phy->phy.io_priv;
+   u32 reg;
+
+   if (disconnect)
+   writel_relaxed(BM_USBPHY_DEBUG_CLKGATE,
+   base + HW_USBPHY_DEBUG_CLR);
+
+   if (mxs_phy->port_id == 0) {
+   reg = disconnect ? ANADIG_USB1_LOOPBACK_SET
+   : ANADIG_USB1_LOOPBACK_CLR;
+   regmap_write(mxs_phy->regmap_anatop, reg,
+   BM_ANADIG_USB1_LOOPBACK_UTMI_DIG_TST1 |
+   BM_ANADIG_USB1_LOOPBACK_TSTI_TX_EN);
+   } else if (mxs_phy->port_id == 1) {
+   reg = disconnect ? ANADIG_USB2_LOOPBACK_SET
+   : ANADIG_USB2_LOOPBACK_CLR;
+   regmap_write(mxs_phy->regmap_anatop, reg,
+   BM_ANADIG_USB2_LOOPBACK_UTMI_DIG_TST1 |
+   BM_ANADIG_USB2_LOOPBACK_TSTI_TX_EN);
+   }
+
+   if (!disconnect)
+   writel_relaxed(BM_USBPHY_DEBUG_CLKGATE,
+   base + HW_USBPHY_DEBUG_SET);
+
+   /* Delay some time, and let Linestate be SE0 for controller */
+   if (disconnect)
+   usleep_range(500, 1000);
+}
+
+static void mxs_phy_disconnect_line(struct mxs_phy *mxs_phy, bool on)
+{
+   bool vbus_is_on = false;
+
+   /* If the SoCs don't need to disconnect line without vbus, quit */
+   if (!(mxs_phy->data->flags & MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS))
+   return;
+
+   /* If the SoCs don't have anatop, quit */
+   if (!mxs_phy->regmap_anatop)
+

[PATCH v11 05/15] usb: phy-mxs: Add anatop regmap

2014-02-23 Thread Peter Chen 
It is needed by imx6 SoC series, but not for imx23 and imx28.

Signed-off-by: Peter Chen 
---
 drivers/usb/phy/phy-mxs-usb.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index d7adca3..2411e05 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define DRIVER_NAME "mxs_phy"
 
@@ -87,6 +89,7 @@ struct mxs_phy {
struct usb_phy phy;
struct clk *clk;
const struct mxs_phy_data *data;
+   struct regmap *regmap_anatop;
 };
 
 static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
@@ -197,6 +200,7 @@ static int mxs_phy_probe(struct platform_device *pdev)
int ret;
const struct of_device_id *of_id =
of_match_device(mxs_phy_dt_ids, &pdev->dev);
+   struct device_node *np = pdev->dev.of_node;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(&pdev->dev, res);
@@ -216,6 +220,17 @@ static int mxs_phy_probe(struct platform_device *pdev)
return -ENOMEM;
}
 
+   /* Some SoCs don't have anatop registers */
+   if (of_get_property(np, "fsl,anatop", NULL)) {
+   mxs_phy->regmap_anatop = syscon_regmap_lookup_by_phandle
+   (np, "fsl,anatop");
+   if (IS_ERR(mxs_phy->regmap_anatop)) {
+   dev_dbg(&pdev->dev,
+   "failed to find regmap for anatop\n");
+   return PTR_ERR(mxs_phy->regmap_anatop);
+   }
+   }
+
mxs_phy->phy.io_priv= base;
mxs_phy->phy.dev= &pdev->dev;
mxs_phy->phy.label  = DRIVER_NAME;
-- 
1.7.8


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 14/15] ARM: dts: imx6: add anatop phandle for usbphy

2014-02-23 Thread Peter Chen 
Add anatop phandle for usbphy

Signed-off-by: Peter Chen 
Signed-off-by: Shawn Guo 
---
 arch/arm/boot/dts/imx6qdl.dtsi |2 ++
 arch/arm/boot/dts/imx6sl.dtsi  |2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index fb28b2e..047b147 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -557,6 +557,7 @@
reg = <0x020c9000 0x1000>;
interrupts = <0 44 0x04>;
clocks = <&clks 182>;
+   fsl,anatop = <&anatop>;
};
 
usbphy2: usbphy@020ca000 {
@@ -564,6 +565,7 @@
reg = <0x020ca000 0x1000>;
interrupts = <0 45 0x04>;
clocks = <&clks 183>;
+   fsl,anatop = <&anatop>;
};
 
snvs@020cc000 {
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 28558f1..30322b5 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -489,6 +489,7 @@
reg = <0x020c9000 0x1000>;
interrupts = <0 44 0x04>;
clocks = <&clks IMX6SL_CLK_USBPHY1>;
+   fsl,anatop = <&anatop>;
};
 
usbphy2: usbphy@020ca000 {
@@ -496,6 +497,7 @@
reg = <0x020ca000 0x1000>;
interrupts = <0 45 0x04>;
clocks = <&clks IMX6SL_CLK_USBPHY2>;
+   fsl,anatop = <&anatop>;
};
 
snvs@020cc000 {
-- 
1.7.8


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 02/15] usb: phy-mxs: Add platform judgement code

2014-02-23 Thread Peter Chen 
The mxs-phy has several bugs and features at different
versions, the driver code can get it through of_device_id.data.

Signed-off-by: Peter Chen 
---
 drivers/usb/phy/phy-mxs-usb.c |   58 ++--
 1 files changed, 49 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index b42897b..cf58d8e 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -1,5 +1,5 @@
 /*
- * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2012-2013 Freescale Semiconductor, Inc.
  * Copyright (C) 2012 Marek Vasut 
  * on behalf of DENX Software Engineering GmbH
  *
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DRIVER_NAME "mxs_phy"
 
@@ -34,13 +35,55 @@
 #define BM_USBPHY_CTRL_ENUTMILEVEL2BIT(14)
 #define BM_USBPHY_CTRL_ENHOSTDISCONDETECT  BIT(1)
 
+#define to_mxs_phy(p) container_of((p), struct mxs_phy, phy)
+
+/* Do disconnection between PHY and controller without vbus */
+#define MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS   BIT(0)
+
+/*
+ * The PHY will be in messy if there is a wakeup after putting
+ * bus to suspend (set portsc.suspendM) but before setting PHY to low
+ * power mode (set portsc.phcd).
+ */
+#define MXS_PHY_ABNORMAL_IN_SUSPENDBIT(1)
+
+/*
+ * The SOF sends too fast after resuming, it will cause disconnection
+ * between host and high speed device.
+ */
+#define MXS_PHY_SENDING_SOF_TOO_FAST   BIT(2)
+
+struct mxs_phy_data {
+   unsigned int flags;
+};
+
+static const struct mxs_phy_data imx23_phy_data = {
+   .flags = MXS_PHY_ABNORMAL_IN_SUSPEND | MXS_PHY_SENDING_SOF_TOO_FAST,
+};
+
+static const struct mxs_phy_data imx6q_phy_data = {
+   .flags = MXS_PHY_SENDING_SOF_TOO_FAST |
+   MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS,
+};
+
+static const struct mxs_phy_data imx6sl_phy_data = {
+   .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS,
+};
+
+static const struct of_device_id mxs_phy_dt_ids[] = {
+   { .compatible = "fsl,imx6sl-usbphy", .data = &imx6sl_phy_data, },
+   { .compatible = "fsl,imx6q-usbphy", .data = &imx6q_phy_data, },
+   { .compatible = "fsl,imx23-usbphy", .data = &imx23_phy_data, },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mxs_phy_dt_ids);
+
 struct mxs_phy {
struct usb_phy phy;
struct clk *clk;
+   const struct mxs_phy_data *data;
 };
 
-#define to_mxs_phy(p) container_of((p), struct mxs_phy, phy)
-
 static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
 {
int ret;
@@ -138,6 +181,8 @@ static int mxs_phy_probe(struct platform_device *pdev)
struct clk *clk;
struct mxs_phy *mxs_phy;
int ret;
+   const struct of_device_id *of_id =
+   of_match_device(mxs_phy_dt_ids, &pdev->dev);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(&pdev->dev, res);
@@ -168,6 +213,7 @@ static int mxs_phy_probe(struct platform_device *pdev)
mxs_phy->phy.type   = USB_PHY_TYPE_USB2;
 
mxs_phy->clk = clk;
+   mxs_phy->data = of_id->data;
 
platform_set_drvdata(pdev, mxs_phy);
 
@@ -187,12 +233,6 @@ static int mxs_phy_remove(struct platform_device *pdev)
return 0;
 }
 
-static const struct of_device_id mxs_phy_dt_ids[] = {
-   { .compatible = "fsl,imx23-usbphy", },
-   { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, mxs_phy_dt_ids);
-
 static struct platform_driver mxs_phy_driver = {
.probe = mxs_phy_probe,
.remove = mxs_phy_remove,
-- 
1.7.8


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 09/15] usb: phy: Add set_wakeup API

2014-02-23 Thread Peter Chen 
This API is used to set wakeup enable at PHY registers, in that
case, the PHY can be waken up from suspend due to external events,
like vbus change, dp/dm change and id change.

Signed-off-by: Peter Chen 
---
 include/linux/usb/phy.h |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6c0b1c5..c2c6f49 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -111,6 +111,13 @@ struct usb_phy {
int (*set_suspend)(struct usb_phy *x,
int suspend);
 
+   /*
+* Set wakeup enable for PHY, in that case, the PHY can be
+* waken up from suspend status due to external events,
+* like vbus change, dp/dm change and id.
+*/
+   int (*set_wakeup)(struct usb_phy *x, bool enabled);
+
/* notify phy connect status change */
int (*notify_connect)(struct usb_phy *x,
enum usb_device_speed speed);
@@ -265,6 +272,15 @@ usb_phy_set_suspend(struct usb_phy *x, int suspend)
 }
 
 static inline int
+usb_phy_set_wakeup(struct usb_phy *x, bool enabled)
+{
+   if (x && x->set_wakeup)
+   return x->set_wakeup(x, enabled);
+   else
+   return 0;
+}
+
+static inline int
 usb_phy_notify_connect(struct usb_phy *x, enum usb_device_speed speed)
 {
if (x && x->notify_connect)
-- 
1.7.8


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 01/15] usb: doc: phy-mxs: Add more compatible strings

2014-02-23 Thread Peter Chen 
Add "fsl,imx6q-usbphy" for imx6dq and imx6dl, add
"fsl,imx6sl-usbphy" for imx6sl, and "fsl,imx23-usbphy"
is still a fallback for other strings.

Signed-off-by: Peter Chen 
---
 Documentation/devicetree/bindings/usb/mxs-phy.txt |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/mxs-phy.txt 
b/Documentation/devicetree/bindings/usb/mxs-phy.txt
index 5835b27..ea5134a 100644
--- a/Documentation/devicetree/bindings/usb/mxs-phy.txt
+++ b/Documentation/devicetree/bindings/usb/mxs-phy.txt
@@ -1,7 +1,11 @@
 * Freescale MXS USB Phy Device
 
 Required properties:
-- compatible: Should be "fsl,imx23-usbphy"
+- compatible: should contain:
+   * "fsl,imx23-usbphy" for imx23 and imx28
+   * "fsl,imx6q-usbphy" for imx6dq and imx6dl
+   * "fsl,imx6sl-usbphy" for imx6sl
+  "fsl,imx23-usbphy" is still a fallback for other strings
 - reg: Should contain registers location and length
 - interrupts: Should contain phy interrupt
 
-- 
1.7.8


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 13/15] ARM: dts: mxs: add mxs phy controller id

2014-02-23 Thread Peter Chen 
We need to use controller id to access different register regions
for mxs phy.

Signed-off-by: Peter Chen 
Signed-off-by: Shawn Guo 
---
 arch/arm/boot/dts/imx23.dtsi |1 +
 arch/arm/boot/dts/imx28.dtsi |2 ++
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 581b754..8a99a64 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -23,6 +23,7 @@
serial1 = &auart1;
spi0 = &ssp0;
spi1 = &ssp1;
+   usbphy0 = &usbphy0;
};
 
cpus {
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index f8e9b20..7da22b3 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -32,6 +32,8 @@
serial4 = &auart4;
spi0 = &ssp1;
spi1 = &ssp2;
+   usbphy0 = &usbphy0;
+   usbphy1 = &usbphy1;
};
 
cpus {
-- 
1.7.8


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 04/15] usb: doc: phy-mxs: update binding for adding anatop phandle

2014-02-23 Thread Peter Chen 
Add anatop phandle which is used to access anatop registers to
control PHY's power and other USB operations.

Signed-off-by: Peter Chen 
---
 Documentation/devicetree/bindings/usb/mxs-phy.txt |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/mxs-phy.txt 
b/Documentation/devicetree/bindings/usb/mxs-phy.txt
index ea5134a..cef181a 100644
--- a/Documentation/devicetree/bindings/usb/mxs-phy.txt
+++ b/Documentation/devicetree/bindings/usb/mxs-phy.txt
@@ -8,10 +8,12 @@ Required properties:
   "fsl,imx23-usbphy" is still a fallback for other strings
 - reg: Should contain registers location and length
 - interrupts: Should contain phy interrupt
+- fsl,anatop: phandle for anatop register, it is only for imx6 SoC series
 
 Example:
 usbphy1: usbphy@020c9000 {
compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy";
reg = <0x020c9000 0x1000>;
interrupts = <0 44 0x04>;
+   fsl,anatop = <&anatop>;
 };
-- 
1.7.8


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 07/15] usb: phy-mxs: Enable IC fixes for related SoCs

2014-02-23 Thread Peter Chen 
Two PHY bugs are fixed by IC logic, but these bits are not
enabled by default, so we enable them at driver.
The two bugs are: MXS_PHY_ABNORMAL_IN_SUSPEND and MXS_PHY_SENDING_SOF_TOO_FAST
which are described at code.

Signed-off-by: Peter Chen 
---
 drivers/usb/phy/phy-mxs-usb.c |   23 +--
 1 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index 1663a66..cb71135 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -31,6 +31,10 @@
 #define HW_USBPHY_CTRL_SET 0x34
 #define HW_USBPHY_CTRL_CLR 0x38
 
+#define HW_USBPHY_IP   0x90
+#define HW_USBPHY_IP_SET   0x94
+#define HW_USBPHY_IP_CLR   0x98
+
 #define BM_USBPHY_CTRL_SFTRST  BIT(31)
 #define BM_USBPHY_CTRL_CLKGATE BIT(30)
 #define BM_USBPHY_CTRL_ENAUTOSET_USBCLKS   BIT(26)
@@ -42,6 +46,8 @@
 #define BM_USBPHY_CTRL_ENUTMILEVEL2BIT(14)
 #define BM_USBPHY_CTRL_ENHOSTDISCONDETECT  BIT(1)
 
+#define BM_USBPHY_IP_FIX   (BIT(17) | BIT(18))
+
 #define to_mxs_phy(p) container_of((p), struct mxs_phy, phy)
 
 /* Do disconnection between PHY and controller without vbus */
@@ -60,6 +66,14 @@
  */
 #define MXS_PHY_SENDING_SOF_TOO_FAST   BIT(2)
 
+/*
+ * IC has bug fixes logic, they include
+ * MXS_PHY_ABNORMAL_IN_SUSPEND and MXS_PHY_SENDING_SOF_TOO_FAST
+ * which are described at above flags, the RTL will handle it
+ * according to different versions.
+ */
+#define MXS_PHY_NEED_IP_FIXBIT(3)
+
 struct mxs_phy_data {
unsigned int flags;
 };
@@ -70,11 +84,13 @@ static const struct mxs_phy_data imx23_phy_data = {
 
 static const struct mxs_phy_data imx6q_phy_data = {
.flags = MXS_PHY_SENDING_SOF_TOO_FAST |
-   MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS,
+   MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS |
+   MXS_PHY_NEED_IP_FIX,
 };
 
 static const struct mxs_phy_data imx6sl_phy_data = {
-   .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS,
+   .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS |
+   MXS_PHY_NEED_IP_FIX,
 };
 
 static const struct of_device_id mxs_phy_dt_ids[] = {
@@ -118,6 +134,9 @@ static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
BM_USBPHY_CTRL_ENUTMILEVEL3,
   base + HW_USBPHY_CTRL_SET);
 
+   if (mxs_phy->data->flags & MXS_PHY_NEED_IP_FIX)
+   writel(BM_USBPHY_IP_FIX, base + HW_USBPHY_IP_SET);
+
return 0;
 }
 
-- 
1.7.8


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 03/15] usb: phy-mxs: Add auto clock and power setting

2014-02-23 Thread Peter Chen 
The auto setting is used to open related power and clocks
automatically after receiving wakeup signal.

With this feature, the PHY's clock and power can be recovered
correctly from low power mode, it is guaranteed by IC logic.

Signed-off-by: Peter Chen 
---
 drivers/usb/phy/phy-mxs-usb.c |   20 +---
 1 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index cf58d8e..d7adca3 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -31,6 +31,11 @@
 
 #define BM_USBPHY_CTRL_SFTRST  BIT(31)
 #define BM_USBPHY_CTRL_CLKGATE BIT(30)
+#define BM_USBPHY_CTRL_ENAUTOSET_USBCLKS   BIT(26)
+#define BM_USBPHY_CTRL_ENAUTOCLR_USBCLKGATEBIT(25)
+#define BM_USBPHY_CTRL_ENAUTOCLR_PHY_PWD   BIT(20)
+#define BM_USBPHY_CTRL_ENAUTOCLR_CLKGATE   BIT(19)
+#define BM_USBPHY_CTRL_ENAUTO_PWRON_PLLBIT(18)
 #define BM_USBPHY_CTRL_ENUTMILEVEL3BIT(15)
 #define BM_USBPHY_CTRL_ENUTMILEVEL2BIT(14)
 #define BM_USBPHY_CTRL_ENHOSTDISCONDETECT  BIT(1)
@@ -96,9 +101,18 @@ static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
/* Power up the PHY */
writel(0, base + HW_USBPHY_PWD);
 
-   /* enable FS/LS device */
-   writel(BM_USBPHY_CTRL_ENUTMILEVEL2 |
-  BM_USBPHY_CTRL_ENUTMILEVEL3,
+   /*
+* USB PHY Ctrl Setting
+* - Auto clock/power on
+* - Enable full/low speed support
+*/
+   writel(BM_USBPHY_CTRL_ENAUTOSET_USBCLKS |
+   BM_USBPHY_CTRL_ENAUTOCLR_USBCLKGATE |
+   BM_USBPHY_CTRL_ENAUTOCLR_PHY_PWD |
+   BM_USBPHY_CTRL_ENAUTOCLR_CLKGATE |
+   BM_USBPHY_CTRL_ENAUTO_PWRON_PLL |
+   BM_USBPHY_CTRL_ENUTMILEVEL2 |
+   BM_USBPHY_CTRL_ENUTMILEVEL3,
   base + HW_USBPHY_CTRL_SET);
 
return 0;
-- 
1.7.8


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 06/15] usb: phy-mxs: change description of usb device speed

2014-02-23 Thread Peter Chen 
Change "high speed" to "HS"
Change "non-high speed" to "FS/LS"

Implementation of notify_suspend and notify_resume will be different
according to mxs_phy_data->flags.

Signed-off-by: Peter Chen 
---
 drivers/usb/phy/phy-mxs-usb.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index 2411e05..1663a66 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -168,8 +168,8 @@ static int mxs_phy_suspend(struct usb_phy *x, int suspend)
 static int mxs_phy_on_connect(struct usb_phy *phy,
enum usb_device_speed speed)
 {
-   dev_dbg(phy->dev, "%s speed device has connected\n",
-   (speed == USB_SPEED_HIGH) ? "high" : "non-high");
+   dev_dbg(phy->dev, "%s device has connected\n",
+   (speed == USB_SPEED_HIGH) ? "HS" : "FS/LS");
 
if (speed == USB_SPEED_HIGH)
writel(BM_USBPHY_CTRL_ENHOSTDISCONDETECT,
@@ -181,8 +181,8 @@ static int mxs_phy_on_connect(struct usb_phy *phy,
 static int mxs_phy_on_disconnect(struct usb_phy *phy,
enum usb_device_speed speed)
 {
-   dev_dbg(phy->dev, "%s speed device has disconnected\n",
-   (speed == USB_SPEED_HIGH) ? "high" : "non-high");
+   dev_dbg(phy->dev, "%s device has disconnected\n",
+   (speed == USB_SPEED_HIGH) ? "HS" : "FS/LS");
 
if (speed == USB_SPEED_HIGH)
writel(BM_USBPHY_CTRL_ENHOSTDISCONDETECT,
-- 
1.7.8


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 08/15] usb: phy-mxs: add controller id

2014-02-23 Thread Peter Chen 
It is used to access un-regulator registers according to
different controllers.

Signed-off-by: Peter Chen 
---
 drivers/usb/phy/phy-mxs-usb.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index cb71135..3009ab5 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -106,6 +106,7 @@ struct mxs_phy {
struct clk *clk;
const struct mxs_phy_data *data;
struct regmap *regmap_anatop;
+   int port_id;
 };
 
 static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
@@ -250,6 +251,11 @@ static int mxs_phy_probe(struct platform_device *pdev)
}
}
 
+   ret = of_alias_get_id(np, "usbphy");
+   if (ret < 0)
+   dev_dbg(&pdev->dev, "failed to get alias id, errno %d\n", ret);
+   mxs_phy->port_id = ret;
+
mxs_phy->phy.io_priv= base;
mxs_phy->phy.dev= &pdev->dev;
mxs_phy->phy.label  = DRIVER_NAME;
-- 
1.7.8


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 15/15] ARM: dts: imx6: add mxs phy controller id

2014-02-23 Thread Peter Chen 
We need to use controller id to access different register regions
for mxs phy.

Signed-off-by: Peter Chen 
Signed-off-by: Shawn Guo 
---
 arch/arm/boot/dts/imx6qdl.dtsi |2 ++
 arch/arm/boot/dts/imx6sl.dtsi  |2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 047b147..581c4c9 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -33,6 +33,8 @@
spi1 = &ecspi2;
spi2 = &ecspi3;
spi3 = &ecspi4;
+   usbphy0 = &usbphy1;
+   usbphy1 = &usbphy2;
};
 
intc: interrupt-controller@00a01000 {
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 30322b5..a06d939 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -27,6 +27,8 @@
spi1 = &ecspi2;
spi2 = &ecspi3;
spi3 = &ecspi4;
+   usbphy0 = &usbphy1;
+   usbphy1 = &usbphy2;
};
 
cpus {
-- 
1.7.8


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 12/15] usb: phy-mxs: Add sync time after controller clear phcd

2014-02-23 Thread Peter Chen 
After clear portsc.phcd, PHY needs 200us stable time for switch
32K clock to AHB clock.

Signed-off-by: Peter Chen 
---
 drivers/usb/phy/phy-mxs-usb.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index 31ef59f..c42bdf0 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -151,6 +151,15 @@ static inline bool is_imx6sl_phy(struct mxs_phy *mxs_phy)
return mxs_phy->data == &imx6sl_phy_data;
 }
 
+/*
+ * PHY needs some 32K cycles to switch from 32K clock to
+ * bus (such as AHB/AXI, etc) clock.
+ */
+static void mxs_phy_clock_switch_delay(void)
+{
+   usleep_range(300, 400);
+}
+
 static int mxs_phy_hw_init(struct mxs_phy *mxs_phy)
 {
int ret;
@@ -261,6 +270,7 @@ static int mxs_phy_init(struct usb_phy *phy)
int ret;
struct mxs_phy *mxs_phy = to_mxs_phy(phy);
 
+   mxs_phy_clock_switch_delay();
ret = clk_prepare_enable(mxs_phy->clk);
if (ret)
return ret;
@@ -289,6 +299,7 @@ static int mxs_phy_suspend(struct usb_phy *x, int suspend)
   x->io_priv + HW_USBPHY_CTRL_SET);
clk_disable_unprepare(mxs_phy->clk);
} else {
+   mxs_phy_clock_switch_delay();
ret = clk_prepare_enable(mxs_phy->clk);
if (ret)
return ret;
-- 
1.7.8


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: chipidea: imx: Use dev_name() for ci_hdrc name to distinguish USBs

2014-02-23 Thread Alexander Shiyan 
Понедельник, 24 февраля 2014, 10:02 +08:00 от Peter Chen 
:
> On Sat, Feb 22, 2014 at 05:17:58PM +0400, Alexander Shiyan wrote:
> > Signed-off-by: Alexander Shiyan 
> > ---
> >  drivers/usb/chipidea/ci_hdrc_imx.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
> > b/drivers/usb/chipidea/ci_hdrc_imx.c
> > index c00f772..2e58f8d 100644
> > --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> > +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> > @@ -96,7 +96,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
> >  {
> > struct ci_hdrc_imx_data *data;
> > struct ci_hdrc_platform_data pdata = {
> > -   .name   = "ci_hdrc_imx",
> > +   .name   = dev_name(&pdev->dev),
> > .capoffset  = DEF_CAPOFFSET,
> > .flags  = CI_HDRC_REQUIRE_TRANSCEIVER |
> >   CI_HDRC_DISABLE_STREAMING,
> > -- 
...
> 
> I don't see too much meaningful for this change, and I don't see
> the meaning of this entry (.name) and no user is using it.

Field "name" is used in the function ci_hdrc_probe() (core.c) for request_irq().
That's what will result:
# cat /proc.interrupts
...
 71:  0  mxc-avic  55  10024400.usb
 72:  0  mxc-avic  56  10024000.usb
 
---

Re: [PATCH] usb: chipidea: imx: Use dev_name() for ci_hdrc name to distinguish USBs

2014-02-23 Thread Peter Chen 
On Mon, Feb 24, 2014 at 08:32:14AM +0400, Alexander Shiyan wrote:
> Понедельник, 24 февраля 2014, 10:02 +08:00 от Peter Chen 
> :
> > On Sat, Feb 22, 2014 at 05:17:58PM +0400, Alexander Shiyan wrote:
> > > Signed-off-by: Alexander Shiyan 
> > > ---
> > >  drivers/usb/chipidea/ci_hdrc_imx.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
> > > b/drivers/usb/chipidea/ci_hdrc_imx.c
> > > index c00f772..2e58f8d 100644
> > > --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> > > +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> > > @@ -96,7 +96,7 @@ static int ci_hdrc_imx_probe(struct platform_device 
> > > *pdev)
> > >  {
> > >   struct ci_hdrc_imx_data *data;
> > >   struct ci_hdrc_platform_data pdata = {
> > > - .name   = "ci_hdrc_imx",
> > > + .name   = dev_name(&pdev->dev),
> > >   .capoffset  = DEF_CAPOFFSET,
> > >   .flags  = CI_HDRC_REQUIRE_TRANSCEIVER |
> > > CI_HDRC_DISABLE_STREAMING,
> > > -- 
> ...
> > 
> > I don't see too much meaningful for this change, and I don't see
> > the meaning of this entry (.name) and no user is using it.
> 
> Field "name" is used in the function ci_hdrc_probe() (core.c) for 
> request_irq().
> That's what will result:
> # cat /proc.interrupts
> ...
>  71:  0  mxc-avic  55  10024400.usb
>  72:  0  mxc-avic  56  10024000.usb
>  
> ---

Get it, thanks.

-- 

Best Regards,
Peter Chen

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

xhci-hcd + NTFS = endless error loop

2014-02-23 Thread Sascha Weaver 
Hi,

I am not very sure if this error belong to ntfs-3g or linux-usb,
but the dmesg says a lot about USB devices so I am reporting it here.
Correct me if I am wrong.

I upgraded to Linux 3.13.5 and found my USB hard disk does not work
properly. But this bug only occurs when mounting an NTFS partition.

I have three different USB hard disks, two of them containing NTFS
partitions. I tried with both of them, and confirmed that only mounting
NTFS partitions will trigger the bug. Mounting ext4 partitions in
these three disks does not trigger the bug (and everything's fine).

I've attached an annotated version of dmesg below. Please read my
comments in that file for more details.

-- 
Sascha Weaver
# System boot completed.
# Inserting Seagate USB disk ...
# (I tried with another USB disk, the errors are the same.)
# (However, mounting an ext4 partition on the same disk does not trigger the
# bug)

[  155.481839] usb 2-1: new SuperSpeed USB device number 2 using xhci_hcd
[  155.525018] usb-storage 2-1:1.0: USB Mass Storage device detected
[  155.525083] scsi3 : usb-storage 2-1:1.0
[  155.525394] usbcore: registered new interface driver usb-storage
[  156.52] scsi 3:0:0:0: Direct-Access Seagate  Backup+  SL  0143 
PQ: 0 ANSI: 6
[  156.531223] sd 3:0:0:0: [sdb] Spinning up disk...
[  159.424726] .ready
[  159.425125] sd 3:0:0:0: [sdb] 1953525167 512-byte logical blocks: (1.00 
TB/931 GiB)
[  159.425745] sd 3:0:0:0: [sdb] Write Protect is off
[  159.425761] sd 3:0:0:0: [sdb] Mode Sense: 2b 00 10 08
[  159.426357] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, 
supports DPO and FUA
[  159.451031]  sdb: sdb1
[  159.452581] sd 3:0:0:0: [sdb] Attached SCSI disk


# Now try to mount /dev/sdb1 ...


[  165.108520] NTFS driver 2.1.30 [Flags: R/W MODULE].
[  165.163328] NTFS volume version 3.1.
[  165.279961] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[  165.293617] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 88020d9e9c80
[  165.293622] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 88020d9e9cc0
[  165.406614] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[  165.420429] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 88020d9e9c80
[  165.420436] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 88020d9e9cc0
[  165.533371] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[  165.547117] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 88020d9e9c80
[  165.547125] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 88020d9e9cc0
[  165.660306] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[  165.673924] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 88020d9e9c80
[  165.673930] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 88020d9e9cc0
[  165.787033] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[  165.800857] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 88020d9e9c80
[  165.800863] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 88020d9e9cc0
[  165.913811] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[  165.927598] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 88020d9e9c80
[  165.927604] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 88020d9e9cc0
[  165.928254] sd 3:0:0:0: [sdb] Unhandled error code
[  165.928258] sd 3:0:0:0: [sdb]  
[  165.928259] Result: hostbyte=0x07 driverbyte=0x00
[  165.928261] sd 3:0:0:0: [sdb] CDB: 
[  165.928262] cdb[0]=0x2a: 2a 00 03 20 08 03 00 00 69 00
[  165.928270] end_request: I/O error, dev sdb, sector 52430851
[  165.928273] Buffer I/O error on device sdb1, logical block 52428803
[  165.928274] lost page write due to I/O error on sdb1
[  165.928276] Buffer I/O error on device sdb1, logical block 52428804
[  165.928278] lost page write due to I/O error on sdb1
[  165.928279] Buffer I/O error on device sdb1, logical block 52428805
[  165.928280] lost page write due to I/O error on sdb1
[  165.928282] Buffer I/O error on device sdb1, logical block 52428806
[  165.928283] lost page write due to I/O error on sdb1
[  165.928284] Buffer I/O error on device sdb1, logical block 52428807
[  165.928286] lost page write due to I/O error on sdb1
[  165.928287] Buffer I/O error on device sdb1, logical block 52428808
[  165.928288] lost page write due to I/O error on sdb1
[  165.928290] Buffer I/O error on device sdb1, logical block 52428809
[  165.928291] lost page write due to I/O error on sdb1
[  165.928292] Buffer I/O error on device sdb1, logical block 52428810
[  165.928294] lost page write due to I/O error on sdb1
[  165.928295] Buffer I/O error on device sdb1, logical block 52428811
[  165.928296] lost page write due to I/O error on sdb1
[  165.928298]

Re: xhci-hcd + NTFS = endless error loop

2014-02-23 Thread Sascha Weaver 
Oh!

I am so sorry! I forgot to install ntfs-3g package!

After the installation of this package the bug exists no more!

I am really sorry for the disturbance ...

2014-02-24 15:18 GMT+08:00 Sascha Weaver :
> Hi,
>
> I am not very sure if this error belong to ntfs-3g or linux-usb,
> but the dmesg says a lot about USB devices so I am reporting it here.
> Correct me if I am wrong.
>
> I upgraded to Linux 3.13.5 and found my USB hard disk does not work
> properly. But this bug only occurs when mounting an NTFS partition.
>
> I have three different USB hard disks, two of them containing NTFS
> partitions. I tried with both of them, and confirmed that only mounting
> NTFS partitions will trigger the bug. Mounting ext4 partitions in
> these three disks does not trigger the bug (and everything's fine).
>
> I've attached an annotated version of dmesg below. Please read my
> comments in that file for more details.
>
> --
> Sascha Weaver



-- 
Sascha Weaver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/6] usb: gadget: gr_udc: Make struct platform_device variable name clearer

2014-02-23 Thread Andreas Larsson 

On 2014-02-18 16:52, Felipe Balbi wrote:

On Thu, Jan 09, 2014 at 11:54:13AM +0100, Andreas Larsson wrote:

Rename struct platform_device pointers from ofdev to pdev for clarity.
Suggested by Mark Rutland.

Signed-off-by: Andreas Larsson 
---
  drivers/usb/gadget/gr_udc.c |   18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/gadget/gr_udc.c b/drivers/usb/gadget/gr_udc.c
index 914cbd8..e66dcf0 100644
--- a/drivers/usb/gadget/gr_udc.c
+++ b/drivers/usb/gadget/gr_udc.c
@@ -2071,9 +2071,9 @@ static int gr_udc_init(struct gr_udc *dev)
return 0;
  }

-static int gr_remove(struct platform_device *ofdev)
+static int gr_remove(struct platform_device *pdev)
  {
-   struct gr_udc *dev = dev_get_drvdata(&ofdev->dev);
+   struct gr_udc *dev = dev_get_drvdata(&pdev->dev);


you can use platform_get_drvdata()


@@ -2083,7 +2083,7 @@ static int gr_remove(struct platform_device *ofdev)
gr_dfs_delete(dev);
if (dev->desc_pool)
dma_pool_destroy(dev->desc_pool);
-   dev_set_drvdata(&ofdev->dev, NULL);
+   dev_set_drvdata(&pdev->dev, NULL);


and platform_set_drvdata()



Yes, but wouldn't that be better handled in a separate patch?

Best regards,
Andreas Larsson
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html