Re: [PATCH v3 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller
Hi,
On Wed, 2015-07-22 at 15:22 +0100, Mark Rutland wrote:
On Wed, Jul 22, 2015 at 03:05:42PM +0100, Chunfeng Yun wrote:
add a DT binding documentation of xHCI host controller for the
MT8173 SoC from Mediatek.
Signed-off-by: Chunfeng Yun chunfeng@mediatek.com
---
.../devicetree/bindings/usb/mt8173-xhci.txt| 50
++
1 file changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
new file mode 100644
index 000..94d
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -0,0 +1,50 @@
+MT65XX xhci
+
+The device node for Mediatek SOC usb3.0 host controller
+
+Required properties:
+ - compatible : supports mediatek,mt8173-xhci
+ - reg: Offset and length of registers
Your example has multiple reg entries.
Please list what each entry is, and the order you expect them in.
Ok
+ - interrupts : Interrupt mode, number and trigger mode
+ - power-domains: to enable usb's mtcmos
+ - vusb33-supply: regulator of usb avdd3.3v
+ - clocks : must support all clocks that xhci needs
+ - clock-names: should be sys_mac for sys and mac clocks, and
+ wakeup_deb_p0, wakeup_deb_p1 for wakeup debounce control
+ clocks
+ - phys: the phys that xhci will bind, currently supports up to two
+ phys, so phy index should not greater than one.
+ - phy-names : should be phy-X format, X equals to 0 or 1
This seems somewhat pointless.
I'll describe it more exactly.
+ - usb3-lpm-capable: supports USB3 LPM
+ - mediatek,usb-wakeup: to access usb wakeup control register
What exactly does this property imply?
There are some control registers for usb wakeup which are put in another
module, here to get the node of that module, and then use regmap and
syscon to operate it.
+ - mediatek,wakeup-src: 1: ip sleep wakeup mode; 2: line state wakeup
+ mode; others means don't enable wakeup source of usb
This sounds like configuration rather than a hardware property. Why do
you think this needs to be in the DT?
Yes, it's better to put it in the DT.
+ - mediatek,u2port-num: the number should not greater than the number
+ of phys
What exactly does this property imply?
On some platform, it only makes use of partial usb ports, so disable
others to save power.
Mark.
+
+Optional properties:
+ - vbus-supply : reference to the VBUS regulator;
+
+Example:
+usb: usb30@1127 {
+ compatible = mediatek,mt8173-xhci;
+ reg = 0 0x1127 0 0x4000,
+ 0 0x1128 0 0x0800;
+ interrupts = GIC_SPI 115 IRQ_TYPE_LEVEL_LOW;
+ power-domains = scpsys MT8173_POWER_DOMAIN_USB;
+ clocks = topckgen CLK_TOP_USB30_SEL,
+pericfg CLK_PERI_USB0,
+pericfg CLK_PERI_USB1;
+ clock-names = sys_mac,
+ wakeup_deb_p0,
+ wakeup_deb_p1;
+ phys = u3phy 0, u3phy 1;
+ phy-names = phy-0, phy-1;
+ vusb33-supply = mt6397_vusb_reg;
+ vbus-supply = usb_p1_vbus;
+ usb3-lpm-capable;
+ mediatek,usb-wakeup = pericfg;
+ mediatek,wakeup-src = 1;
+ mediatek,u2port-num = 2;
+ status = okay;
+};
--
1.8.1.1.dirty
--
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 v3 26/46] usb: gadget: pch_ud: add ep capabilities support
Hi,
On 07/20/2015 05:08 PM, Krzysztof Opasiak wrote:
On 07/15/2015 08:32 AM, Robert Baldyga wrote:
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/usb/gadget/udc/pch_udc.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/pch_udc.c
b/drivers/usb/gadget/udc/pch_udc.c
index 613547f..cc8fb3c 100644
--- a/drivers/usb/gadget/udc/pch_udc.c
+++ b/drivers/usb/gadget/udc/pch_udc.c
@@ -2895,11 +2895,21 @@ static void pch_udc_pcd_reinit(struct
pch_udc_dev *dev)
ep-in = ~i 1;
ep-ep.name = ep_string[i];
ep-ep.ops = pch_udc_ep_ops;
-if (ep-in)
+if (ep-in) {
ep-offset_addr = ep-num * UDC_EP_REG_SHIFT;
-else
+ep-ep.caps.dir_in = true;
+} else {
ep-offset_addr = (UDC_EPINT_OUT_SHIFT + ep-num) *
UDC_EP_REG_SHIFT;
+ep-ep.caps.dir_out = true;
+}
+if (i == UDC_EP0IN_IDX || i == UDC_EP0OUT_IDX) {
+ep-ep.caps.type_control = true;
In all previous patches you set both dir_in and dir_out to true for ep0
but in this patch you don't do this. Is there some reason for this or
it's just a mistake?
Most of UDC drivers we have single instance of ep0 for both directions,
but this one has two separate unidirectional ep0in and ep0out.
+} else {
+ep-ep.caps.type_iso = true;
+ep-ep.caps.type_bulk = true;
+ep-ep.caps.type_int = true;
+}
/* need to set ep-ep.maxpacket and set Default
Configuration?*/
usb_ep_set_maxpacket_limit(ep-ep, UDC_BULK_MAX_PKT_SIZE);
list_add_tail(ep-ep.ep_list, dev-gadget.ep_list);
Thanks,
Robert Baldyga
--
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
Fwd: Xenta Mouse Wireless sometimes not working in Linux Kernel 4.0.5
NoIt still same. I have seen some updates for usb_modeswitch but mouse still mice have intermitent connection, reporting same error (code -110). In Windows boot it's work smoothly, this means that device haven't hardware problems. Thanks for your help and sorry for late reply. 2015-06-19 17:45 GMT-05:00 Greg KH g...@kroah.com: On Fri, Jun 19, 2015 at 02:58:27PM -0500, José David León Rodríguez wrote: Sometimes generic mice usb wireless not work with usb_modeswitch enabled. dmesg | grep usb output when kernel not find device descriptors for mouse: [ 154.988937] usb 2-3: new full-speed USB device number 9 using xhci_hcd [ 160.159445] usb 2-3: unable to read config index 0 descriptor/start: -110 [ 160.159450] usb 2-3: can't read configurations, error -110 [ 160.319415] usb 2-3: new full-speed USB device number 10 using xhci_hcd [ 165.489805] usb 2-3: unable to read config index 0 descriptor/start: -110 [ 165.489815] usb 2-3: can't read configurations, error -110 after I disable usb_modeswitch or unplug and plug mouse several times... usb_modeswitch shouldn't care about this, the device isn't communicating well with the system. [ 165.649708] usb 2-3: new full-speed USB device number 11 using xhci_hcd [ 165.705290] usbcore: registered new interface driver usbhid [ 165.705293] usbhid: USB HID core driver [ 165.739693] input: HID Wireless Mouse HID Wireless Mouse as /devices/pci:00/:00:14.0/usb2/2-3/2-3:1.0/0003:1D57:0016.0001/input/input17 [ 165.739838] hid-generic 0003:1D57:0016.0001: input,hidraw0: USB HID v1.10 Mouse [HID Wireless Mouse HID Wireless Mouse] on usb-:00:14.0-3/input0 So it works properly now? 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: [PATCH v3 42/46] usb: gadget: move ep_matches() from epautoconf to udc-core
Alan Stern st...@rowland.harvard.edu writes: Hi Alan, On Sat, 25 Jul 2015, Robert Jarzmik wrote: Petr Cvek petr.c...@tul.cz writes: On 23.7.2015 21:46, Alan Stern wrote: It seems that it allows using a BULK endpoint for requested INT endpoint. For my PXA27x machine the original code returns BULK EP even with valid INT endpoint definition (because BULK EPs are defined earlier than INT EPs). Yes, it does allow a bulk endpoint to be used when an interrupt endpoint was requested. However, it won't return a bulk endpoint if all the bulk endpoints are already in use. This cannot work for pxa27x. Do you mean that on pxa27x, a bulk endpoint cannot be used as an interrupt endpoint? Why not? From the device controller's point of view, there is no difference between bulk and interrupt (except possibly for the maxpacket sizes and high-bandwidth usage when running at high speed). That's the point, maxpacket size and priority. As you said, it's not that it won't work, it won't work with the priority expected by the software stack, ie. higher priority for ISO endpoint. The pxa27x IP has a hardware limitation which prevents an endpoint from changing its type once the UDC is enabled (see the comment at the beginning of pxa27x_udc.c). If that patchset implies that for a requested INT endpoint a BULK endpoint can be returned, that won't work. Felipe and Robert, is that what this patchset implies ? Sort of. The matching code has always behaved that way and this patchset does not change the behavior. Then all is fine I suppose, if it was working before and nothing changes, it will continue to work, won't it ? A default PXA27x configuration returns BULK for requested INT. Which is unfortunate, because PXA27x supports INT endpoints and has one predefined, but this function find BULK first (one BULK is allocated and INT is never used). See above. See response above. Besides, let's say the pxa27x has one bulk and one interrupt endpoint. Now suppose the gadget driver requests a bulk endpoint first. The matching code will allocate the single bulk endpoint. Then the gadget driver requests an interrupt endpoint. The matching code cannot allocate the bulk endpoint, because that endpoint is already allocated. So it will allocate the interrupt endpoint. Thus, as you can see, under the right conditions everything will work as desired. Let me give you another example : - pxa27x_udc offers 3 endpoints : ep-in, ep-out, ep-iso-in - a gadget driver does : - request an ep-in - request an ep-out - request an ep-in - request an ep-iso-in In that case, the ep-iso-in request will fail, right ? Yet I would have expected the second ep-in request to fail, as that's the one which cannot be serviced. Of course, this hypothetical case implies that pxa27x_udc is not compatible with this gadget driver, so it's not really relevant, is it ... Because if they do, the ep_matches() function works poorly. It returns a BULK for device (gadget) side, but host side (PC) thinks that this endpoint is an INT and handles it in this way. But the PXA27x thinks the endpoint is a BULK and handles it in its way (according to datasheet, settings for a BULK and an INT transfers are not 100% compatible). How do they differ? One example I have in mind is chapter 12.4.2 of pxa27x developer manual Endpoint Memory Configuration, quote follows : If the USB host controller transmits more OUT data than the maximum size packet for a bulk or interrupt endpoint, the UDC does not send any handshake to the host controller causing the host controller to time-out. If the USB host controller transmits more OUT data than the maximum size packet for an isochronous endpoint, the UDC sets the data packet error (DPE) bit in the Endpoint Control/Status register, UDCCSRx[DPE]. Perhaps you could submit a patch that adds a do not allocate a bulk endpoint when an interrupt endpoint is requested quirk flag to the usb_gadget structure, and modify the matching code to take the new flag into account. Well, if it was working that way already in the past, I don't see overloading the code with a quirk a necessity. My only need is that it continues to work. Cheers. -- Robert -- 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 v3 42/46] usb: gadget: move ep_matches() from epautoconf to udc-core
On Sat, 25 Jul 2015, Robert Jarzmik wrote: Petr Cvek petr.c...@tul.cz writes: On 23.7.2015 21:46, Alan Stern wrote: It seems that it allows using a BULK endpoint for requested INT endpoint. For my PXA27x machine the original code returns BULK EP even with valid INT endpoint definition (because BULK EPs are defined earlier than INT EPs). Yes, it does allow a bulk endpoint to be used when an interrupt endpoint was requested. However, it won't return a bulk endpoint if all the bulk endpoints are already in use. This cannot work for pxa27x. Do you mean that on pxa27x, a bulk endpoint cannot be used as an interrupt endpoint? Why not? From the device controller's point of view, there is no difference between bulk and interrupt (except possibly for the maxpacket sizes and high-bandwidth usage when running at high speed). The pxa27x IP has a hardware limitation which prevents an endpoint from changing its type once the UDC is enabled (see the comment at the beginning of pxa27x_udc.c). If that patchset implies that for a requested INT endpoint a BULK endpoint can be returned, that won't work. Felipe and Robert, is that what this patchset implies ? Sort of. The matching code has always behaved that way and this patchset does not change the behavior. A default PXA27x configuration returns BULK for requested INT. Which is unfortunate, because PXA27x supports INT endpoints and has one predefined, but this function find BULK first (one BULK is allocated and INT is never used). See above. See response above. Besides, let's say the pxa27x has one bulk and one interrupt endpoint. Now suppose the gadget driver requests a bulk endpoint first. The matching code will allocate the single bulk endpoint. Then the gadget driver requests an interrupt endpoint. The matching code cannot allocate the bulk endpoint, because that endpoint is already allocated. So it will allocate the interrupt endpoint. Thus, as you can see, under the right conditions everything will work as desired. Because if they do, the ep_matches() function works poorly. It returns a BULK for device (gadget) side, but host side (PC) thinks that this endpoint is an INT and handles it in this way. But the PXA27x thinks the endpoint is a BULK and handles it in its way (according to datasheet, settings for a BULK and an INT transfers are not 100% compatible). How do they differ? I cannot test INT as BULK behavior for the gadget functions, because all gadgets which works on PXA27x does not use INT endpoints (some allocate the endpoint but never use it). Ah a bit of history here. At least gadget zero does, and it's my main testing point for pxa27x_udc. Then there should be g_serial (no acm nor obex), but that's something I have not tried since 2009 ... For history also, there was already an attempt a long time ago for epautoconf revamping, done by Rodolfo Giometti IIRC. Anyway, I need pxa27x_udc to remain functional, so I'd like to understand if something will stop working, Robert B. Perhaps you could submit a patch that adds a do not allocate a bulk endpoint when an interrupt endpoint is requested quirk flag to the usb_gadget structure, and modify the matching code to take the new flag into account. 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: [PATCH v3 42/46] usb: gadget: move ep_matches() from epautoconf to udc-core
On Sat, 25 Jul 2015, Petr Cvek wrote: On 25.7.2015 19:04, Robert Jarzmik wrote: Alan Stern st...@rowland.harvard.edu writes: Hi Alan, On Sat, 25 Jul 2015, Robert Jarzmik wrote: Petr Cvek petr.c...@tul.cz writes: On 23.7.2015 21:46, Alan Stern wrote: It seems that it allows using a BULK endpoint for requested INT endpoint. For my PXA27x machine the original code returns BULK EP even with valid INT endpoint definition (because BULK EPs are defined earlier than INT EPs). Yes, it does allow a bulk endpoint to be used when an interrupt endpoint was requested. However, it won't return a bulk endpoint if all the bulk endpoints are already in use. This cannot work for pxa27x. Do you mean that on pxa27x, a bulk endpoint cannot be used as an interrupt endpoint? Why not? From the device controller's point of view, there is no difference between bulk and interrupt (except possibly for the maxpacket sizes and high-bandwidth usage when running at high speed). That's the point, maxpacket size and priority. As you said, it's not that it won't work, it won't work with the priority expected by the software stack, ie. higher priority for ISO endpoint. Yes, maxpacket could be problem. Datasheet has listed range (1-64) for INT and specific values (8, 16, 32, 64) for BULK. In practice I doubt this will matter. Using a larger maxpacket size than the gadget driver expects is rarely important for interrupt transfers, since they almost never involve more than one packet's worth of data. So for example, if the gadget driver wants an interrupt endpoint with maxpacket 42, it almost certainly will work okay if it gets a bulk endpoint with maxpacket 64. If that patchset implies that for a requested INT endpoint a BULK endpoint can be returned, that won't work. Felipe and Robert, is that what this patchset implies ? Sort of. The matching code has always behaved that way and this patchset does not change the behavior. Then all is fine I suppose, if it was working before and nothing changes, it will continue to work, won't it ? Yes functional behavior of this patch is same as in vanilla, I only began this thread, because I have found out that someone is sending patchset. But I found this behavior when I was trying to use g_webcam gadget. I have finally gathered enough information and luck (unstable machine) to try test g_serial so configuration: * modprobe g_serial use_acm=1 n_ports=1 * original version of ep_matches() (returns bulk and int) * compatible EP configuration/definition for UDC side http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/pxa27x_udc.c#L2352 USB_EP_CTRL, USB_EP_OUT_BULK(1), USB_EP_IN_BULK(2), USB_EP_IN_ISO(3), USB_EP_OUT_ISO(4), USB_EP_IN_INT(5), * modified EP configuration for UDC side (just changed EP3 ISO to BULK, so there is one free BULK) USB_EP_CTRL, USB_EP_OUT_BULK(1), USB_EP_IN_BULK(2), USB_EP_IN_BULK(3), //change USB_EP_OUT_ISO(4), USB_EP_IN_INT(5), ===results=== * original configuration is OK, all endpoints are found (in order ep2in-bulk, ep1out-bulk, ep3in-int), INT notification seems to work I don't understand. Above you said that the EP definition in the UDC is USB_EP_IN_ISO(3). So how can you end up with ep3in-int? int != ISO. You should have ended up with the third endpoint being ep5in-int, because ep_matches() doesn't allow an isochronous to match a request for an interrupt endpoint. * modified configuration fails: [ 4259.609088] pxa27x-udc pxa27x-udc: ep15:pxa_ep_enable: type mismatch by this condition: http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/pxa27x_udc.c#L1416 because ep_matches() returns BULK. Okay, that's a problem in pxa27x-udc. Why does it insist on an exact match between the hardware endpoint type and the type contained in the descriptor? It should accept an interrupt descriptor if the hardware type is bulk. g_serial later disables INT notification [ 4259.609871] g_serial gadget: acm ttyGS0 can't notify serial state, -22 So this function is waiting regression, all it takes is just one change into the PXA27x EP configuration or change of allocation order for endpoints in a gadget. And it limits other existing gadget from being supported too (PXA can have only 23 endpoints including different altsetting/interface/cfg combinations). It could be easily fixed by gadget_is_pxa27x() function. Or one of the other techniques we have mentioned. The inability to use the same endpoint in more than one alternate setting is quite a nasty limitation, however. 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: [PATCH v3 42/46] usb: gadget: move ep_matches() from epautoconf to udc-core
On Sat, 25 Jul 2015, Robert Jarzmik wrote: Alan Stern st...@rowland.harvard.edu writes: Hi Alan, On Sat, 25 Jul 2015, Robert Jarzmik wrote: Petr Cvek petr.c...@tul.cz writes: On 23.7.2015 21:46, Alan Stern wrote: It seems that it allows using a BULK endpoint for requested INT endpoint. For my PXA27x machine the original code returns BULK EP even with valid INT endpoint definition (because BULK EPs are defined earlier than INT EPs). Yes, it does allow a bulk endpoint to be used when an interrupt endpoint was requested. However, it won't return a bulk endpoint if all the bulk endpoints are already in use. This cannot work for pxa27x. Do you mean that on pxa27x, a bulk endpoint cannot be used as an interrupt endpoint? Why not? From the device controller's point of view, there is no difference between bulk and interrupt (except possibly for the maxpacket sizes and high-bandwidth usage when running at high speed). That's the point, maxpacket size and priority. As you said, it's not that it won't work, it won't work with the priority expected by the software stack, ie. higher priority for ISO endpoint. As Robert Baldyga pointed out, this isn't relevant to a UDC driver. Only to a host controller driver. The pxa27x IP has a hardware limitation which prevents an endpoint from changing its type once the UDC is enabled (see the comment at the beginning of pxa27x_udc.c). If that patchset implies that for a requested INT endpoint a BULK endpoint can be returned, that won't work. Felipe and Robert, is that what this patchset implies ? Sort of. The matching code has always behaved that way and this patchset does not change the behavior. Then all is fine I suppose, if it was working before and nothing changes, it will continue to work, won't it ? It should. A default PXA27x configuration returns BULK for requested INT. Which is unfortunate, because PXA27x supports INT endpoints and has one predefined, but this function find BULK first (one BULK is allocated and INT is never used). See above. See response above. Besides, let's say the pxa27x has one bulk and one interrupt endpoint. Now suppose the gadget driver requests a bulk endpoint first. The matching code will allocate the single bulk endpoint. Then the gadget driver requests an interrupt endpoint. The matching code cannot allocate the bulk endpoint, because that endpoint is already allocated. So it will allocate the interrupt endpoint. Thus, as you can see, under the right conditions everything will work as desired. Let me give you another example : - pxa27x_udc offers 3 endpoints : ep-in, ep-out, ep-iso-in - a gadget driver does : - request an ep-in - request an ep-out - request an ep-in - request an ep-iso-in In that case, the ep-iso-in request will fail, right ? Yet I would have expected the second ep-in request to fail, as that's the one which cannot be serviced. In this example, the second ep-in request _will_ fail. An isochronous endpoint will not be allocated when the gadget driver requests a bulk endpoint. The bahavior that Petr didn't like was quite different: The matching code will sometimes allocate a bulk endpoint when the gadget driver requests an interrupt endpoint. Of course, this hypothetical case implies that pxa27x_udc is not compatible with this gadget driver, so it's not really relevant, is it ... Because if they do, the ep_matches() function works poorly. It returns a BULK for device (gadget) side, but host side (PC) thinks that this endpoint is an INT and handles it in this way. But the PXA27x thinks the endpoint is a BULK and handles it in its way (according to datasheet, settings for a BULK and an INT transfers are not 100% compatible). How do they differ? One example I have in mind is chapter 12.4.2 of pxa27x developer manual Endpoint Memory Configuration, quote follows : If the USB host controller transmits more OUT data than the maximum size packet for a bulk or interrupt endpoint, the UDC does not send any handshake to the host controller causing the host controller to time-out. If the USB host controller transmits more OUT data than the maximum size packet for an isochronous endpoint, the UDC sets the data packet error (DPE) bit in the Endpoint Control/Status register, UDCCSRx[DPE]. That's a difference between isochronous and bulk/interrupt. We are talking about the difference between bulk and interrupt. 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: [PATCH v3 42/46] usb: gadget: move ep_matches() from epautoconf to udc-core
Hi, On 07/25/2015 07:04 PM, Robert Jarzmik wrote: Alan Stern st...@rowland.harvard.edu writes: Hi Alan, On Sat, 25 Jul 2015, Robert Jarzmik wrote: Petr Cvek petr.c...@tul.cz writes: On 23.7.2015 21:46, Alan Stern wrote: It seems that it allows using a BULK endpoint for requested INT endpoint. For my PXA27x machine the original code returns BULK EP even with valid INT endpoint definition (because BULK EPs are defined earlier than INT EPs). Yes, it does allow a bulk endpoint to be used when an interrupt endpoint was requested. However, it won't return a bulk endpoint if all the bulk endpoints are already in use. This cannot work for pxa27x. Do you mean that on pxa27x, a bulk endpoint cannot be used as an interrupt endpoint? Why not? From the device controller's point of view, there is no difference between bulk and interrupt (except possibly for the maxpacket sizes and high-bandwidth usage when running at high speed). That's the point, maxpacket size and priority. As you said, it's not that it won't work, it won't work with the priority expected by the software stack, ie. higher priority for ISO endpoint. Priority is not dependent on UDC hardware capabilities. Only USB host decides about priority, so there is no problem from UDC point of view. The pxa27x IP has a hardware limitation which prevents an endpoint from changing its type once the UDC is enabled (see the comment at the beginning of pxa27x_udc.c). If that patchset implies that for a requested INT endpoint a BULK endpoint can be returned, that won't work. Felipe and Robert, is that what this patchset implies ? Sort of. The matching code has always behaved that way and this patchset does not change the behavior. Then all is fine I suppose, if it was working before and nothing changes, it will continue to work, won't it ? A default PXA27x configuration returns BULK for requested INT. Which is unfortunate, because PXA27x supports INT endpoints and has one predefined, but this function find BULK first (one BULK is allocated and INT is never used). See above. See response above. Besides, let's say the pxa27x has one bulk and one interrupt endpoint. Now suppose the gadget driver requests a bulk endpoint first. The matching code will allocate the single bulk endpoint. Then the gadget driver requests an interrupt endpoint. The matching code cannot allocate the bulk endpoint, because that endpoint is already allocated. So it will allocate the interrupt endpoint. Thus, as you can see, under the right conditions everything will work as desired. Let me give you another example : - pxa27x_udc offers 3 endpoints : ep-in, ep-out, ep-iso-in - a gadget driver does : - request an ep-in - request an ep-out - request an ep-in - request an ep-iso-in In that case, the ep-iso-in request will fail, right ? Yet I would have expected the second ep-in request to fail, as that's the one which cannot be serviced. Gadget driver cannot simply request ep-in. Endpoints are matched with ep descriptors containing complete information about direction, type, maxpacketsize etc. of requested endpoint. So described situation can never take a place. However if gadget driver requests more endpoints than UDC driver supplies it will do fail ;) Current matching mechanism is very simple and surely will not always return optimal endpont set. Maybe we should try to develop something more sophisticated. Of course, this hypothetical case implies that pxa27x_udc is not compatible with this gadget driver, so it's not really relevant, is it ... Because if they do, the ep_matches() function works poorly. It returns a BULK for device (gadget) side, but host side (PC) thinks that this endpoint is an INT and handles it in this way. But the PXA27x thinks the endpoint is a BULK and handles it in its way (according to datasheet, settings for a BULK and an INT transfers are not 100% compatible). How do they differ? One example I have in mind is chapter 12.4.2 of pxa27x developer manual Endpoint Memory Configuration, quote follows : If the USB host controller transmits more OUT data than the maximum size packet for a bulk or interrupt endpoint, the UDC does not send any handshake to the host controller causing the host controller to time-out. If the USB host controller transmits more OUT data than the maximum size packet for an isochronous endpoint, the UDC sets the data packet error (DPE) bit in the Endpoint Control/Status register, UDCCSRx[DPE]. Perhaps you could submit a patch that adds a do not allocate a bulk endpoint when an interrupt endpoint is requested quirk flag to the usb_gadget structure, and modify the matching code to take the new flag into account. Well, if it was working that way already in the past, I don't see overloading the code with a quirk a necessity. My only need is that it continues to work. In this patchset I'm adding
[RFC ebeam PATCH v2 1/2] hid: Blacklist eBeam devices
Add known eBeam devices usb ids.
Prevent hid-generic to take over these devices. This breaks Luidia's
proprietary application suite.
Signed-off-by: Yann Cantin yann.can...@laposte.net
---
drivers/hid/hid-core.c | 6 ++
drivers/hid/hid-ids.h | 6 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 157c627..db4c7ee 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2267,6 +2267,12 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x0004) },
{ HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x000a) },
+#if defined(CONFIG_INPUT_EBEAM_USB)
+ { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_EBEAM_USB1) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_EBEAM_USB2) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_EBEAM_BT_USB1) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_EBEAM_BT_USB2) },
+#endif
{ HID_USB_DEVICE(USB_VENDOR_ID_ESSENTIAL_REALITY,
USB_DEVICE_ID_ESSENTIAL_REALITY_P5) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC5UH) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC4UM) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index b04b082..ca013c2 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -303,6 +303,12 @@
#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_73F7 0x73f7
#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_A001 0xa001
+#define USB_VENDOR_ID_EFI 0x2650
+#define USB_DEVICE_ID_EFI_EBEAM_USB1 0x1311
+#define USB_DEVICE_ID_EFI_EBEAM_USB2 0x1315
+#define USB_DEVICE_ID_EFI_EBEAM_BT_USB10x1313
+#define USB_DEVICE_ID_EFI_EBEAM_BT_USB20x1320
+
#define USB_VENDOR_ID_ELAN 0x04f3
#define USB_DEVICE_ID_ELAN_TOUCHSCREEN 0x0089
#define USB_DEVICE_ID_ELAN_TOUCHSCREEN_009B0x009b
--
2.3.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
[RFC ebeam PATCH v2 2/2] input: misc: New USB eBeam input driver
Add new USB input driver for Luidia's eBeam devices. Currently supported (tested) : - eBeam classic projection and edge projection models - Nec interactive solution NP01Wi1 NP01Wi2 accessories. Notable stuff : - 13 sysfs custom files : 9 values for the transformation matrix, 4 for xy ranges and a calibration trigger. - need userspace gui tool for calibration (ebeam.tuxfamily.org) Signed-off-by: Yann Cantin yann.can...@laposte.net --- Documentation/ABI/testing/sysfs-driver-ebeam | 53 ++ drivers/input/misc/Kconfig | 22 + drivers/input/misc/Makefile | 1 + drivers/input/misc/ebeam.c | 759 +++ 4 files changed, 835 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-ebeam create mode 100644 drivers/input/misc/ebeam.c diff --git a/Documentation/ABI/testing/sysfs-driver-ebeam b/Documentation/ABI/testing/sysfs-driver-ebeam new file mode 100644 index 000..3a663e8 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-ebeam @@ -0,0 +1,53 @@ +What: /sys/bus/usb/drivers/ebeam/busnum-devnum:confignum.ifacenum/min_x + /sys/bus/usb/drivers/ebeam/busnum-devnum:confignum.ifacenum/min_y + /sys/bus/usb/drivers/ebeam/busnum-devnum:confignum.ifacenum/max_x + /sys/bus/usb/drivers/ebeam/busnum-devnum:confignum.ifacenum/max_y +Date: Jul 2015 +Kernel Version:4.1 +Contact: yann.can...@laposte.net + linux-usb@vger.kernel.org +Description: + Reading from these files return the actually used range values of + the reported coordinates. + Writing to these files preset these range values. + See below for the calibration procedure. + +What: /sys/bus/usb/drivers/ebeam/busnum-devnum:confignum.ifacenum/h[1..9] +Date: Jul 2015 +Kernel Version:4.1 +Contact: yann.can...@laposte.net + linux-usb@vger.kernel.org +Description: + Reading from these files return the 3x3 transformation matrix elements + actually used, in row-major. + Writing to these files preset these elements values. + See below for the calibration procedure. + +What: /sys/bus/usb/drivers/ebeam/busnum-devnum:confignum.ifacenum/calibrated +Date: Jul 2015 +Kernel Version:4.1 +Contact: yann.can...@laposte.net + linux-usb@vger.kernel.org +Description: + Reading from this file : + - Return 0 if the driver is in un-calibrated mode : it actually send + raw coordinates in the device's internal coordinates system. + - Return 1 if the driver is in calibrated mode : it send computed coordinates + that (hopefully) matches the screen's coordinates system. + Writing 1 to this file enable the calibrated mode, 0 reset the driver in + un-calibrated mode. + +Calibration procedure : + +When loaded, the driver is in un-calibrated mode : it send device's raw coordinates +in the [0..65535]x[0..65535] range, the transformation matrix is the identity. + +A calibration program have to compute a homography transformation matrix that convert +the device's raw coordinates to the matching screen's ones. +It then write to the appropriate sysfs files the computed values, pre-setting the +driver's parameters : xy range, and the matrix's elements. +When all values are passed, it write 1 to the calibrated sysfs file to enable the calibrated mode. + +Warning : The parameters aren't used until 1 is writen to the calibrated sysfs file. + +These files can also be accessed via /sys/class/input/inputXX/device/ diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index d4f0a81..22c46a4 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -103,6 +103,28 @@ config INPUT_E3X0_BUTTON To compile this driver as a module, choose M here: the module will be called e3x0_button. +config INPUT_EBEAM_USB + tristate USB eBeam driver + depends on USB_ARCH_HAS_HCD + select USB + help + Say Y here if you have a USB eBeam pointing device and want to + use it without any proprietary user space tools. + + Have a look at http://ebeam.tuxfamily.org/ for + a usage description and the required user-space tools. + + Supported devices : + - Luidia eBeam Classic Projection and eBeam Edge Projection + - Nec NP01Wi1 NP01Wi2 interactive solution + + Supposed working devices, need test, may lack functionality : + - Luidia eBeam Edge Whiteboard and eBeam Engage + - Hitachi Starboard FX-63, FX-77, FX-82, FX-77GII + + To compile this driver as a module, choose M here: the + module will be called ebeam. + config INPUT_PCSPKR tristate PC
Re: [PATCH v3 42/46] usb: gadget: move ep_matches() from epautoconf to udc-core
On 25.7.2015 20:08, Robert Baldyga wrote: Let me give you another example : - pxa27x_udc offers 3 endpoints : ep-in, ep-out, ep-iso-in - a gadget driver does : - request an ep-in - request an ep-out - request an ep-in - request an ep-iso-in In that case, the ep-iso-in request will fail, right ? Yet I would have expected the second ep-in request to fail, as that's the one which cannot be serviced. Gadget driver cannot simply request ep-in. Endpoints are matched with ep descriptors containing complete information about direction, type, maxpacketsize etc. of requested endpoint. So described situation can never take a place. However if gadget driver requests more endpoints than UDC driver supplies it will do fail ;) Yes and returning of BULK instead of INT can cause it (only defined BULK gets eaten by requested INT). Current matching mechanism is very simple and surely will not always return optimal endpont set. Maybe we should try to develop something more sophisticated. I can test it (as I'm trying to get to work other gadgets like g_webcam, g_audio, g_hid and possibly function composites). Of course, this hypothetical case implies that pxa27x_udc is not compatible with this gadget driver, so it's not really relevant, is it ... Because if they do, the ep_matches() function works poorly. It returns a BULK for device (gadget) side, but host side (PC) thinks that this endpoint is an INT and handles it in this way. But the PXA27x thinks the endpoint is a BULK and handles it in its way (according to datasheet, settings for a BULK and an INT transfers are not 100% compatible). How do they differ? One example I have in mind is chapter 12.4.2 of pxa27x developer manual Endpoint Memory Configuration, quote follows : If the USB host controller transmits more OUT data than the maximum size packet for a bulk or interrupt endpoint, the UDC does not send any handshake to the host controller causing the host controller to time-out. If the USB host controller transmits more OUT data than the maximum size packet for an isochronous endpoint, the UDC sets the data packet error (DPE) bit in the Endpoint Control/Status register, UDCCSRx[DPE]. Perhaps you could submit a patch that adds a do not allocate a bulk endpoint when an interrupt endpoint is requested quirk flag to the usb_gadget structure, and modify the matching code to take the new flag into account. Well, if it was working that way already in the past, I don't see overloading the code with a quirk a necessity. My only need is that it continues to work. In this patchset I'm adding 'ep_match' callback to usb_gadget_ops, which can be used to supply non-standard matching algorithm, so there is no need for new quirk. Yeah that would be better, every UDC to handle its way. Cheers, Robert Petr -- 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
[RFC ebeam PATCH v2 0/2] Add a new USB eBeam input driver
Hi, New USB input driver for eBeam devices. Notable stuff : - need userspace gui tool for calibration (ebeam.tuxfamily.org) - This driver breaks Luidia's proprietary application suite. Patch 1 to blacklist the devices for hid generic-usb. Patch 2 is the actual driver. Changes : RFC https://lkml.org/lkml/2015/7/20/634 : Use DEVICE_ATTR_RW() RFC https://lkml.org/lkml/2015/7/21/107 : move usb id definitions out of ebeam.c RFC https://lkml.org/lkml/2015/7/20/657 : Fix ABI documentation Thanks for your help. Yann Cantin (2): hid: Blacklist eBeam devices input: misc: New USB eBeam input driver Documentation/ABI/testing/sysfs-driver-ebeam | 53 ++ drivers/hid/hid-core.c | 6 + drivers/hid/hid-ids.h| 6 + drivers/input/misc/Kconfig | 22 + drivers/input/misc/Makefile | 1 + drivers/input/misc/ebeam.c | 759 +++ 6 files changed, 847 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-ebeam create mode 100644 drivers/input/misc/ebeam.c -- 2.3.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 v3 42/46] usb: gadget: move ep_matches() from epautoconf to udc-core
On 25.7.2015 19:04, Robert Jarzmik wrote: Alan Stern st...@rowland.harvard.edu writes: Hi Alan, On Sat, 25 Jul 2015, Robert Jarzmik wrote: Petr Cvek petr.c...@tul.cz writes: On 23.7.2015 21:46, Alan Stern wrote: It seems that it allows using a BULK endpoint for requested INT endpoint. For my PXA27x machine the original code returns BULK EP even with valid INT endpoint definition (because BULK EPs are defined earlier than INT EPs). Yes, it does allow a bulk endpoint to be used when an interrupt endpoint was requested. However, it won't return a bulk endpoint if all the bulk endpoints are already in use. This cannot work for pxa27x. Do you mean that on pxa27x, a bulk endpoint cannot be used as an interrupt endpoint? Why not? From the device controller's point of view, there is no difference between bulk and interrupt (except possibly for the maxpacket sizes and high-bandwidth usage when running at high speed). That's the point, maxpacket size and priority. As you said, it's not that it won't work, it won't work with the priority expected by the software stack, ie. higher priority for ISO endpoint. Yes, maxpacket could be problem. Datasheet has listed range (1-64) for INT and specific values (8, 16, 32, 64) for BULK. The pxa27x IP has a hardware limitation which prevents an endpoint from changing its type once the UDC is enabled (see the comment at the beginning of pxa27x_udc.c). If that patchset implies that for a requested INT endpoint a BULK endpoint can be returned, that won't work. Felipe and Robert, is that what this patchset implies ? Sort of. The matching code has always behaved that way and this patchset does not change the behavior. Then all is fine I suppose, if it was working before and nothing changes, it will continue to work, won't it ? Yes functional behavior of this patch is same as in vanilla, I only began this thread, because I have found out that someone is sending patchset. But I found this behavior when I was trying to use g_webcam gadget. A default PXA27x configuration returns BULK for requested INT. Which is unfortunate, because PXA27x supports INT endpoints and has one predefined, but this function find BULK first (one BULK is allocated and INT is never used). See above. See response above. Besides, let's say the pxa27x has one bulk and one interrupt endpoint. Now suppose the gadget driver requests a bulk endpoint first. The matching code will allocate the single bulk endpoint. Then the gadget driver requests an interrupt endpoint. The matching code cannot allocate the bulk endpoint, because that endpoint is already allocated. So it will allocate the interrupt endpoint. Thus, as you can see, under the right conditions everything will work as desired. Let me give you another example : - pxa27x_udc offers 3 endpoints : ep-in, ep-out, ep-iso-in - a gadget driver does : - request an ep-in - request an ep-out - request an ep-in - request an ep-iso-in In that case, the ep-iso-in request will fail, right ? Yet I would have expected the second ep-in request to fail, as that's the one which cannot be serviced. Of course, this hypothetical case implies that pxa27x_udc is not compatible with this gadget driver, so it's not really relevant, is it ... I have finally gathered enough information and luck (unstable machine) to try test g_serial so configuration: * modprobe g_serial use_acm=1 n_ports=1 * original version of ep_matches() (returns bulk and int) * compatible EP configuration/definition for UDC side http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/pxa27x_udc.c#L2352 USB_EP_CTRL, USB_EP_OUT_BULK(1), USB_EP_IN_BULK(2), USB_EP_IN_ISO(3), USB_EP_OUT_ISO(4), USB_EP_IN_INT(5), * modified EP configuration for UDC side (just changed EP3 ISO to BULK, so there is one free BULK) USB_EP_CTRL, USB_EP_OUT_BULK(1), USB_EP_IN_BULK(2), USB_EP_IN_BULK(3), //change USB_EP_OUT_ISO(4), USB_EP_IN_INT(5), ===results=== * original configuration is OK, all endpoints are found (in order ep2in-bulk, ep1out-bulk, ep3in-int), INT notification seems to work * modified configuration fails: [ 4259.609088] pxa27x-udc pxa27x-udc: ep15:pxa_ep_enable: type mismatch by this condition: http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/pxa27x_udc.c#L1416 because ep_matches() returns BULK. g_serial later disables INT notification [ 4259.609871] g_serial gadget: acm ttyGS0 can't notify serial state, -22 So this function is waiting regression, all it takes is just one change into the PXA27x EP configuration or change of allocation order for endpoints in a gadget. And it limits other existing gadget from being supported too (PXA can have only 23 endpoints including different altsetting/interface/cfg combinations). It could be easily
Re: [PATCH v3 42/46] usb: gadget: move ep_matches() from epautoconf to udc-core
On 25.7.2015 13:04, Robert Jarzmik wrote: Petr Cvek petr.c...@tul.cz writes: On 23.7.2015 21:46, Alan Stern wrote: It seems that it allows using a BULK endpoint for requested INT endpoint. For my PXA27x machine the original code returns BULK EP even with valid INT endpoint definition (because BULK EPs are defined earlier than INT EPs). Yes, it does allow a bulk endpoint to be used when an interrupt endpoint was requested. However, it won't return a bulk endpoint if all the bulk endpoints are already in use. This cannot work for pxa27x. The pxa27x IP has a hardware limitation which prevents an endpoint from changing its type once the UDC is enabled (see the comment at the beginning of pxa27x_udc.c). Just crazy idea (based on how much I have to recompile kernel, when switching between testing gadgets), how much possible (EP allocation, no resource errors return, configuration/interface settings change) it would be to generate an EP configuration on the fly and only enabling the PXA27x when a set_configuration usb request is received? Petr -- 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 v3 42/46] usb: gadget: move ep_matches() from epautoconf to udc-core
On 25.7.2015 23:36, Alan Stern wrote: On Sat, 25 Jul 2015, Petr Cvek wrote: On 25.7.2015 19:04, Robert Jarzmik wrote: Alan Stern st...@rowland.harvard.edu writes: Hi Alan, On Sat, 25 Jul 2015, Robert Jarzmik wrote: Petr Cvek petr.c...@tul.cz writes: On 23.7.2015 21:46, Alan Stern wrote: It seems that it allows using a BULK endpoint for requested INT endpoint. For my PXA27x machine the original code returns BULK EP even with valid INT endpoint definition (because BULK EPs are defined earlier than INT EPs). Yes, it does allow a bulk endpoint to be used when an interrupt endpoint was requested. However, it won't return a bulk endpoint if all the bulk endpoints are already in use. This cannot work for pxa27x. Do you mean that on pxa27x, a bulk endpoint cannot be used as an interrupt endpoint? Why not? From the device controller's point of view, there is no difference between bulk and interrupt (except possibly for the maxpacket sizes and high-bandwidth usage when running at high speed). That's the point, maxpacket size and priority. As you said, it's not that it won't work, it won't work with the priority expected by the software stack, ie. higher priority for ISO endpoint. Yes, maxpacket could be problem. Datasheet has listed range (1-64) for INT and specific values (8, 16, 32, 64) for BULK. In practice I doubt this will matter. Using a larger maxpacket size than the gadget driver expects is rarely important for interrupt transfers, since they almost never involve more than one packet's worth of data. So for example, if the gadget driver wants an interrupt endpoint with maxpacket 42, it almost certainly will work okay if it gets a bulk endpoint with maxpacket 64. What about higher speeds (not relevant on PXA, but ep_matches() is called from usb_ep_autoconfig_ss() )? According to http://wiki.osdev.org/Universal_Serial_Bus#Maximum_Data_Payload_Size_2 High speed INT endpoint has a maximum data payload 1024 B and BULK only 512 B (are other attributes of the data phase similar?). What about superspeed? If that patchset implies that for a requested INT endpoint a BULK endpoint can be returned, that won't work. Felipe and Robert, is that what this patchset implies ? Sort of. The matching code has always behaved that way and this patchset does not change the behavior. Then all is fine I suppose, if it was working before and nothing changes, it will continue to work, won't it ? Yes functional behavior of this patch is same as in vanilla, I only began this thread, because I have found out that someone is sending patchset. But I found this behavior when I was trying to use g_webcam gadget. I have finally gathered enough information and luck (unstable machine) to try test g_serial so configuration: * modprobe g_serial use_acm=1 n_ports=1 * original version of ep_matches() (returns bulk and int) * compatible EP configuration/definition for UDC side http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/pxa27x_udc.c#L2352 USB_EP_CTRL, USB_EP_OUT_BULK(1), USB_EP_IN_BULK(2), USB_EP_IN_ISO(3), USB_EP_OUT_ISO(4), USB_EP_IN_INT(5), * modified EP configuration for UDC side (just changed EP3 ISO to BULK, so there is one free BULK) USB_EP_CTRL, USB_EP_OUT_BULK(1), USB_EP_IN_BULK(2), USB_EP_IN_BULK(3), //change USB_EP_OUT_ISO(4), USB_EP_IN_INT(5), ===results=== * original configuration is OK, all endpoints are found (in order ep2in-bulk, ep1out-bulk, ep3in-int), INT notification seems to work I don't understand. Above you said that the EP definition in the UDC is USB_EP_IN_ISO(3). So how can you end up with ep3in-int? int != ISO. You should have ended up with the third endpoint being ep5in-int, because ep_matches() doesn't allow an isochronous to match a request for an interrupt endpoint. I have changed definition of ISO to BULK only to accomplish minimal change of driver code (for my demonstration free BULK must be defined before INT - inserting new EP would require to reindex all next EPs and modifying links from PXA side endpoints). The USB_EP_IN_ISO(3) is just unused endpoint. * modified configuration fails: [ 4259.609088] pxa27x-udc pxa27x-udc: ep15:pxa_ep_enable: type mismatch by this condition: http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/pxa27x_udc.c#L1416 because ep_matches() returns BULK. Okay, that's a problem in pxa27x-udc. Why does it insist on an exact match between the hardware endpoint type and the type contained in the descriptor? It should accept an interrupt descriptor if the hardware type is bulk. Hmm, making BULK EP equivalent with INT EP (when INT is requested) would made debugging (there is special bitfield in the config registers) and configuration preset (not anymore unordered set, but definition in the specific sequence) hell. But in other
[GIT PULL] USB driver fixes for 4.2-rc4
The following changes since commit 52721d9d3334c1cb1f76219a161084094ec634dc: Linux 4.2-rc3 (2015-07-19 14:45:02 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.2-rc4 for you to fetch changes up to 1209544d8a2a6084f58625ca66f5cd77580df53f: USB: OHCI: fix bad #define in ohci-tmio.c (2015-07-22 14:49:42 -0700) USB fixes for 4.2-rc4 Here's a few USB and PHY fixes for 4.2-rc4. Nothing major, the shortlog has the full details. All of these have been in linux-next successfully. Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org AMAN DEEP (1): usb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() function Alan Stern (2): USB: OHCI: Fix race between ED unlink and URB submission USB: OHCI: fix bad #define in ohci-tmio.c Alexey Khoroshilov (1): usb: gadget: mv_udc_core: fix phy_regs I/O memory leak Brian Campbell (1): xhci: Calculate old endpoints correctly on device reset Greg Kroah-Hartman (2): Merge tag 'fixes-for-v4.2-rc4' of git://git.kernel.org/.../balbi/usb into usb-linus Merge tag 'phy-for-4.2-rc' of git://git.kernel.org/.../kishon/linux-phy into usb-linus Hans de Goede (1): usb-storage: Add ignore-device quirk for gm12u320 based usb mini projectors Johannes Thumshirn (1): cdc-acm: Destroy acm_minors IDR on module exit John Youn (1): usb: dwc3: Reset the transfer resource index on SET_INTERFACE Lu Baolu (2): usb: ulpi: ulpi_init should be executed in subsys_initcall usb: core: lpm: set lpm_capable for root hub device Mathias Nyman (1): xhci: call BIOS workaround to enable runtime suspend on Intel Braswell Oliver Neukum (1): usb-storage: ignore ZTE MF 823 card reader in mode 0x1225 Rajmohan Mani (1): xhci: Workaround to get D3 working in Intel xHCI Roger Quadros (1): phy: ti-pipe3: fix suspend Sebastian Ott (1): phy/pxa: add HAS_IOMEM dependency Thomas Hebb (2): phy: berlin-usb: fix divider for BG2CD phy: berlin-usb: fix divider for BG2 Yoshihiro Shimoda (1): usb: gadget: udc: core: Fix argument of dma_map_single for IOMMU Zhuang Jin Can (3): xhci: report U3 when link is in resume state xhci: prevent bus_suspend if SS port resuming in phase 1 xhci: do not report PLC when link is in internal resume state drivers/phy/Kconfig | 2 + drivers/phy/phy-berlin-usb.c | 4 +- drivers/phy/phy-ti-pipe3.c | 172 +-- drivers/usb/class/cdc-acm.c | 1 + drivers/usb/common/ulpi.c| 2 +- drivers/usb/core/hcd.c | 7 +- drivers/usb/core/hub.c | 2 +- drivers/usb/core/usb.h | 1 + drivers/usb/dwc3/ep0.c | 4 + drivers/usb/gadget/udc/mv_udc_core.c | 2 +- drivers/usb/gadget/udc/udc-core.c| 14 +-- drivers/usb/host/ohci-q.c| 7 +- drivers/usb/host/ohci-tmio.c | 2 +- drivers/usb/host/xhci-hub.c | 22 +++-- drivers/usb/host/xhci-mem.c | 2 +- drivers/usb/host/xhci-pci.c | 57 +++- drivers/usb/host/xhci-ring.c | 3 + drivers/usb/host/xhci.c | 3 + drivers/usb/host/xhci.h | 1 + drivers/usb/storage/unusual_devs.h | 23 + 20 files changed, 170 insertions(+), 161 deletions(-) -- 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 v3 5/5] arm64: dts: mediatek: add xHCI usb phy for mt8173
hi
On Wed, 2015-07-22 at 21:11 +0300, Sergei Shtylyov wrote:
Hello.
On 07/22/2015 05:05 PM, Chunfeng Yun wrote:
add xHCI and phy drivers for MT8173-EVB
Signed-off-by: Chunfeng Yun chunfeng@mediatek.com
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 15 ++
arch/arm64/boot/dts/mediatek/mt8173.dtsi| 31
+
2 files changed, 46 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index f433c21..202b2b9 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -13,6 +13,7 @@
*/
/dts-v1/;
+#include dt-bindings/gpio/gpio.h
#include mt8173.dtsi
/ {
@@ -32,6 +33,15 @@
};
chosen { };
+
+ usb_p1_vbus: fixedregulator@0 {
Just regulator@0 please. This is more in line with what ePAPR requires
from the node names.
+ compatible = regulator-fixed;
+ regulator-name = usb_vbus;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = pio 130 GPIO_ACTIVE_HIGH;
+ enable-active-high;
+ };
};
pwrap {
[...]
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 0696f8f..aa1ecc7 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
[...]
@@ -393,6 +394,36 @@
#size-cells = 0;
status = disabled;
};
+
+ usb: usb30@1127 {
ePAPR standardizes the name usb for such nodes, please fix.
[...]
ok, I'll revise it, thanks a lot
MBR, Sergei
--
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 v3 3/5] usb: phy: add usb3.0 phy driver for mt65xx SoCs
hi, On Wed, 2015-07-22 at 09:21 -0500, Felipe Balbi wrote: Hi, On Wed, Jul 22, 2015 at 10:05:43PM +0800, Chunfeng Yun wrote: support usb3.0 phy of mt65xx SoCs Signed-off-by: Chunfeng Yun chunfeng@mediatek.com you missed Kishon here. Thank you. --- drivers/phy/Kconfig | 9 + drivers/phy/Makefile | 1 + drivers/phy/phy-mt65xx-usb3.c | 426 ++ 3 files changed, 436 insertions(+) create mode 100644 drivers/phy/phy-mt65xx-usb3.c diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index c0e6ede..019cf8b 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -193,6 +193,15 @@ config PHY_HIX5HD2_SATA help Support for SATA PHY on Hisilicon hix5hd2 Soc. +config PHY_MT65XX_USB3 + tristate Mediatek USB3.0 PHY Driver + depends on ARCH_MEDIATEK OF + select GENERIC_PHY + help + Say 'Y' here to add support for Mediatek USB3.0 PHY driver + for mt65xx SoCs. it supports two usb2.0 ports and + one usb3.0 port. + config PHY_SUN4I_USB tristate Allwinner sunxi SoC USB PHY driver depends on ARCH_SUNXI HAS_IOMEM OF diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index f344e1b..3ceff2a 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -22,6 +22,7 @@ obj-$(CONFIG_TI_PIPE3)+= phy-ti-pipe3.o obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o obj-$(CONFIG_PHY_EXYNOS5250_SATA) += phy-exynos5250-sata.o obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o +obj-$(CONFIG_PHY_MT65XX_USB3) += phy-mt65xx-usb3.o obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o obj-$(CONFIG_PHY_SUN9I_USB)+= phy-sun9i-usb.o obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c new file mode 100644 index 000..5da4534 --- /dev/null +++ b/drivers/phy/phy-mt65xx-usb3.c @@ -0,0 +1,426 @@ +/* + * Copyright (c) 2015 MediaTek Inc. + * Author: Chunfeng.Yun chunfeng@mediatek.com + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include linux/clk.h +#include linux/delay.h +#include linux/io.h +#include linux/module.h +#include linux/of_address.h +#include linux/of_device.h +#include linux/of_gpio.h +#include linux/of.h +#include linux/phy/phy.h +#include linux/platform_device.h +#include linux/pm_runtime.h +#include linux/regulator/consumer.h +#include linux/resource.h + +/* + * for sifslv2 register + * relative to USB3_SIF2_BASE base address + */ +#define SSUSB_SIFSLV_SPLLC (0x) +#define SSUSB_SIFSLV_U2PHY_COM_BASE(0x0800) +#define SSUSB_SIFSLV_U3PHYD_BASE (0x0900) +#define SSUSB_USB30_PHYA_SIV_B_BASE(0x0b00) +#define SSUSB_SIFSLV_U3PHYA_DA_BASE(0x0c00) + +/*port1 refs. +0x800(refer to port0)*/ +#define U3P_PORT_INTERVAL (0x800) /*based on port0 */ +#define U3P_PHY_DELTA(index) ((U3P_PORT_INTERVAL) * (index)) + +#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x) +#define PA0_RG_U2PLL_FORCE_ON (0x1 15) + +#define U3P_USBPHYACR2 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0008) +#define PA2_RG_SIF_U2PLL_FORCE_EN (0x1 18) + +#define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014) +#define PA5_RG_U2_HSTX_SRCTRL (0x7 12) +#define PA5_RG_U2_HSTX_SRCTRL_VAL(x) ((0x7 (x)) 12) +#define PA5_RG_U2_HS_100U_U3_EN(0x1 11) + +#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018) +#define PA6_RG_U2_ISO_EN (0x1 31) +#define PA6_RG_U2_BC11_SW_EN (0x1 23) +#define PA6_RG_U2_OTG_VBUSCMP_EN (0x1 20) + +#define U3P_U2PHYACR4 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020) +#define P2C_RG_USB20_GPIO_CTL (0x1 9) +#define P2C_USB20_GPIO_MODE(0x1 8) +#define P2C_U2_GPIO_CTR_MSK(P2C_RG_USB20_GPIO_CTL | P2C_USB20_GPIO_MODE) + +#define U3D_U2PHYDCR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0060) +#define P2C_RG_SIF_U2PLL_FORCE_ON (0x1 24) + +#define U3P_U2PHYDTM0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0068) +#define P2C_FORCE_UART_EN (0x1 26) +#define P2C_FORCE_DATAIN (0x1 23) +#define P2C_FORCE_DM_PULLDOWN (0x1 21) +#define P2C_FORCE_DP_PULLDOWN (0x1 20) +#define P2C_FORCE_XCVRSEL (0x1 19) +#define P2C_FORCE_SUSPENDM (0x1 18) +#define
Re: [PATCH v3 42/46] usb: gadget: move ep_matches() from epautoconf to udc-core
Petr Cvek petr.c...@tul.cz writes: On 23.7.2015 21:46, Alan Stern wrote: It seems that it allows using a BULK endpoint for requested INT endpoint. For my PXA27x machine the original code returns BULK EP even with valid INT endpoint definition (because BULK EPs are defined earlier than INT EPs). Yes, it does allow a bulk endpoint to be used when an interrupt endpoint was requested. However, it won't return a bulk endpoint if all the bulk endpoints are already in use. This cannot work for pxa27x. The pxa27x IP has a hardware limitation which prevents an endpoint from changing its type once the UDC is enabled (see the comment at the beginning of pxa27x_udc.c). If that patchset implies that for a requested INT endpoint a BULK endpoint can be returned, that won't work. Felipe and Robert, is that what this patchset implies ? A default PXA27x configuration returns BULK for requested INT. Which is unfortunate, because PXA27x supports INT endpoints and has one predefined, but this function find BULK first (one BULK is allocated and INT is never used). See above. Because if they do, the ep_matches() function works poorly. It returns a BULK for device (gadget) side, but host side (PC) thinks that this endpoint is an INT and handles it in this way. But the PXA27x thinks the endpoint is a BULK and handles it in its way (according to datasheet, settings for a BULK and an INT transfers are not 100% compatible). I cannot test INT as BULK behavior for the gadget functions, because all gadgets which works on PXA27x does not use INT endpoints (some allocate the endpoint but never use it). Ah a bit of history here. At least gadget zero does, and it's my main testing point for pxa27x_udc. Then there should be g_serial (no acm nor obex), but that's something I have not tried since 2009 ... For history also, there was already an attempt a long time ago for epautoconf revamping, done by Rodolfo Giometti IIRC. Anyway, I need pxa27x_udc to remain functional, so I'd like to understand if something will stop working, Robert B. Cheers. -- Robert -- 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
