Re: Is this 32-bit NCM?y
Hello guys! I am writing this message to hear if there is any progress, Enrico On Wed, 3 Dec 2014, Kevin Zhu wrote: Date: Wed, 3 Dec 2014 07:05:37 From: Kevin Zhu To: Enrico Mioso Cc: Bjørn Mork , Eli Britstein , Alex Strizhevsky , Midge Shaojun Tan , "you...@gmail.com" , "linux-usb@vger.kernel.org" , "net...@vger.kernel.org" Subject: Re: Is this 32-bit NCM? OK. I will. Thank you for everything! Regards, Kevin On 12/03/2014 02:00 PM, Enrico Mioso wrote: Yes - I think this would be ok. You might try this with the 16-bit river first, and then with the 32-bit one to see how things work. I hope for the best. Let us all know, Enrico On Wed, 3 Dec 2014, Kevin Zhu wrote: ==Date: Wed, 3 Dec 2014 06:38:27 ==From: Kevin Zhu ==To: Enrico Mioso ==Cc: Bjørn Mork , Eli Britstein , ==Alex Strizhevsky , ==Midge Shaojun Tan , =="you...@gmail.com" , =="linux-usb@vger.kernel.org" , =="net...@vger.kernel.org" ==Subject: Re: Is this 32-bit NCM? == ==My dongle also works with the huawei driver. I think only the 32bit ==format and NDP location matter. We may modify the TX function to put NTH ==and NDP at the beginning of a NTB and see if it will work with the ==driver cdc_ncm. == ==Regards, ==Kevin == ==On 12/02/2014 11:28 PM, Enrico Mioso wrote: ==> ... And what do you think about the source code of their ndis driver? ==> We at least know now the device work with it, so we have something to mimic :D ==> thank you for your work and patience Kevin. ==> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: ==> ==> ==Date: Tue, 2 Dec 2014 16:04:25 ==> ==From: Kevin Zhu ==> ==To: Enrico Mioso , Bjørn Mork ==> ==Cc: Eli Britstein , ==> ==Alex Strizhevsky , ==> ==Midge Shaojun Tan , ==> =="you...@gmail.com" , ==> =="linux-usb@vger.kernel.org" , ==> =="net...@vger.kernel.org" ==> ==Subject: Re: Is this 32-bit NCM? ==> == ==> ==I do not understand why the wSequence matters. By the way, I think I see some NDPs are right after NTH headers in the windows capture. ==> == ==> == ==> ==From: Enrico Mioso ==> ==Sent: Tuesday, December 2, 2014 21:53 ==> ==To: Bjørn Mork ==> ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; you...@gmail.com; linux-usb@vger.kernel.org; net...@vger.kernel.org ==> ==Subject: Re: Is this 32-bit NCM? ==> == ==> ==Thank you very much Bjorn. ==> == ==> == ==> ==On Tue, 2 Dec 2014, Bjørn Mork wrote: ==> == ==> Date: Tue, 2 Dec 2014 14:37:03 ==> From: Bjørn Mork ==> To: Enrico Mioso ==> Cc: Kevin Zhu , ==> Eli Britstein , ==> Alex Strizhevsky , ==> Midge Shaojun Tan , ==> "you...@gmail.com" , ==> "linux-usb@vger.kernel.org" , ==> "net...@vger.kernel.org" ==> Subject: Re: Is this 32-bit NCM? ==> ==> Enrico Mioso writes: ==> ==> > ... but out of curiosity: are NCM specs allowing to change order of things in ==> > the package or not? ==> > This is not to start philosofical falames or something, but to understand ==> > better how things work. And, if they do: how much arbitrarily? ==> ==> Only the NTB header has a fixed location. The rest can be anywhere and ==> in any order. Quoting from section 3 Data Transport: ==> ==> "Within any given NTB, the NTH always must be first; but the other ==> items may occur in arbitrary order." ==> ==> ==> Bjørn ==> ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. ==> == ==> ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message ==> == ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. == ==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message == This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender
[PATCH net-next] r8152: redefine REALTEK_USB_DEVICE
Redefine REALTEK_USB_DEVICE for the desired USB interface for probe().
There are three USB interfaces for the device. USB_CLASS_COMM and
USB_CLASS_CDC_DATA are for ECM mode (config #2). USB_CLASS_VENDOR_SPEC
is for the vendor mode (config #1). However, we are not interesting
in USB_CLASS_CDC_DATA for probe(), so redefine REALTEK_USB_DEVICE
to ignore the USB interface class of USB_CLASS_CDC_DATA.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 4a9ece0..2d1c77e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
/* Version Information */
#define DRIVER_VERSION "v1.07.0 (2014/10/09)"
@@ -466,9 +467,6 @@ enum rtl8152_flags {
#define MCU_TYPE_PLA 0x0100
#define MCU_TYPE_USB 0x
-#define REALTEK_USB_DEVICE(vend, prod) \
- USB_DEVICE_INTERFACE_CLASS(vend, prod, USB_CLASS_VENDOR_SPEC)
-
struct tally_counter {
__le64 tx_packets;
__le64 rx_packets;
@@ -3915,11 +3913,27 @@ static void rtl8152_disconnect(struct usb_interface
*intf)
}
}
+#define REALTEK_USB_DEVICE(vend, prod) \
+ .match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
+ USB_DEVICE_ID_MATCH_INT_CLASS, \
+ .idVendor = (vend), \
+ .idProduct = (prod), \
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC \
+}, \
+{ \
+ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO | \
+ USB_DEVICE_ID_MATCH_DEVICE, \
+ .idVendor = (vend), \
+ .idProduct = (prod), \
+ .bInterfaceClass = USB_CLASS_COMM, \
+ .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET, \
+ .bInterfaceProtocol = USB_CDC_PROTO_NONE
+
/* table of devices that work with this driver */
static struct usb_device_id rtl8152_table[] = {
- {USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)},
- {USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)},
- {USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101)},
+ {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)},
+ {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)},
+ {REALTEK_USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101)},
{}
};
--
1.9.3
--
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] phy: add Rockchip RK3288 USB2 PHY driver.
Hi Roy,
Why you send two patches with different commit message but the same
change,
you should use V2 for a new patch.
On 12/03/2014 09:46 PM, LiYunzhi wrote:
From: lyz
You don't need the From for the patches from yourself.
Add a driver for the Rockchip SoC internal USB2.0 PHY.
This driver currently support RK3288.
Signed-off-by: lyz
Remember to use you Full name here for From/Signed-off-by
or all the kind of signature.
---
.../devicetree/bindings/phy/rockchip-usb-phy.txt | 17 ++
The document should be in a separate patch, so please split this into
two patches.
drivers/phy/Kconfig| 7 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-rockchip-usb.c | 179 +
4 files changed, 204 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
create mode 100644 drivers/phy/phy-rockchip-usb.c
diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
new file mode 100644
index 000..18ccc2f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
@@ -0,0 +1,17 @@
+ROCKCHIP USB2 PHY
+
+Required properties:
+ - compatible: rockchip,rk3288-usb-phy
+ - rockchip,grf : phandle to the syscon managing the "general
+ register files"
+ - #phy-cells: must be 1
+Refer to phy/phy-bindings.txt for the generic PHY binding
+properties
+
+Example:
+
+ usbphy: phy {
+ #phy-cells = <1>;
+ compatible = "rockchip,rk3288-usb-phy";
+ rockchip,grf = <&grf>;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2a436e6..54ab088 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -218,6 +218,13 @@ config PHY_QCOM_IPQ806X_SATA
depends on OF
select GENERIC_PHY
+config PHY_ROCKCHIP_RK3288_USB2
+ tristate "Rockchip USB2 RK3288 PHY Driver"
+ depends on ARCH_ROCKCHIP && OF
+ select GENERIC_PHY
+ help
+ Enable this to support the Rockchip USB 2.0 PHY.
+
config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index c4590fc..f4f2f79 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -25,6 +25,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2) +=
phy-exynos5250-usb2.o
phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+= phy-s5pv210-usb2.o
obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
obj-$(CONFIG_PHY_QCOM_APQ8064_SATA) += phy-qcom-apq8064-sata.o
+obj-$(CONFIG_PHY_ROCKCHIP_RK3288_USB2) += phy-rockchip-usb.o
Add this after 'CONFIG_PHY_QCOM_IPQ806X_SATA'.
obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA) += phy-qcom-ipq806x-sata.o
obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
new file mode 100644
index 000..2586b76
--- /dev/null
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -0,0 +1,179 @@
+/*
+ * Rockchip usb PHY driver
+ *
+ * Copyright (C) 2014 Roy Li
+ * Copyright (C) 2014 ROCKCHIP, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ROCKCHIP_RK3288_UOC(n) (0x320 + n * 0x14)
+
+#define SIDDQ_MSK (1 << (13 + 16))
+#define SIDDQ_ON (1 << 13)
+#define SIDDQ_OFF (0 << 13)
+
+enum rk3288_phy_id {
+ RK3288_OTG,
+ RK3288_HOST0,
+ RK3288_HOST1,
+ RK3288_NUM_PHYS,
+};
+
+struct rockchip_usb_phy {
+ struct regmap *reg_base;
+ unsigned int reg_offset;
+ struct clk *clk;
+ struct phy *phy;
+};
+
+static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
+ bool siddq)
+{
+ return regmap_write(phy->reg_base, phy->reg_offset,
+ SIDDQ_MSK | (siddq ? SIDDQ_ON : SIDDQ_OFF));
+}
+
+static int rockchip_usb_phy_power_off(struct phy *_phy)
+{
+ struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
+ int ret = 0;
+
+ /* Power down usb phy analog blocks by set siddq 1*/
+ ret = rockchip_usb_phy_power(phy, 1);
Use a MACRO like ON/OFF instead of 1/0?
and then we don't need the comment anymore.
+ if (ret)
+ return ret;
+
+ clk_disabl
Re: Modifying USB Audio gadget driver
Hi, (no top-posting, please) On Wed, Dec 03, 2014 at 05:24:22PM -0600, Priya S wrote: > Great! That fixes it. Thanks. > > Windows is not able to install the driver though. These are the USB > descriptors that I see from the host-side: > > Device Descriptor: > bcdUSB: 0x0200 > bDeviceClass: 0x00 this means that the class is defined at the interface level. > bDeviceSubClass: 0x00 > bDeviceProtocol: 0x00 > bMaxPacketSize0: 0x40 (64) > idVendor: 0x1D6B > idProduct: 0x0101 > bcdDevice: 0x0316 > iManufacturer:0x01 > 0x0409: "Linux 3.2.0 with musb-hdrc" this is one old kernel. You really wanna ask for support from whoever gave you this kernel instead. Considering you're using MUSB and TI has an old 3.2-based SDK, if you got this from TI, get in touch with your FAE and/or use TI's support forum instead. The community cannot support you with such an old kernel. However, if you're willing to move your development to v3.18-rc7 (or at least v3.17.4) then I'll be happy to help you out. > iProduct: 0x02 > 0x0409: "Linux USB Audio Gadget" > iSerialNumber:0x00 > bNumConfigurations: 0x01 > > ConnectionStatus: DeviceConnected > Current Config Value: 0x01 > Device Bus Speed: High > Device Address: 0x1B > Open Pipes: 0 > > Configuration Descriptor: > wTotalLength: 0x0095 > bNumInterfaces: 0x03 > bConfigurationValue: 0x01 > iConfiguration: 0x00 > bmAttributes: 0xC0 (Bus Powered Self Powered ) > MaxPower: 0x01 (2 Ma) > > Interface Descriptor: > bInterfaceNumber: 0x00 > bAlternateSetting:0x00 > bNumEndpoints:0x00 > bInterfaceClass: 0x01 (Audio) and here it is. The class is defined here. Does this work with Linux ? Windows is pretty stupid when it comes to binding drivers to USB devices. It just can't handle bDeviceClass set to "Defined at interface". > bInterfaceSubClass: 0x01 (Audio Control) > bInterfaceProtocol: 0x00 > iInterface: 0x00 > > Audio Control Interface Header Descriptor: > bLength: 0x0A > bDescriptorType: 0x24 > bDescriptorSubtype: 0x01 > bcdADC: 0x0100 > wTotalLength: 0x0028 > bInCollection:0x02 > baInterfaceNr[1]: 0x01 > baInterfaceNr[2]: 0x02 > > Audio Control Input Terminal Descriptor: > bLength: 0x0C > bDescriptorType: 0x24 > bDescriptorSubtype: 0x02 > bTerminalID: 0x02 > wTerminalType: 0x0201 (Microphone) > bAssocTerminal: 0x00 > bNrChannels: 0x02 > wChannelConfig: 0x0003 > iChannelNames:0x00 > iTerminal:0x07 > > Audio Control Output Terminal Descriptor: > bLength: 0x09 > bDescriptorType: 0x24 > bDescriptorSubtype: 0x03 > bTerminalID: 0x01 > wTerminalType: 0x0301 (Speaker) > bAssocTerminal: 0x03 > bSoruceID:0x03 > iTerminal:0x09 > > Interface Descriptor: > bInterfaceNumber: 0x01 > bAlternateSetting:0x00 > bNumEndpoints:0x00 > bInterfaceClass: 0x01 (Audio) > bInterfaceSubClass: 0x02 (Audio Streaming) > bInterfaceProtocol: 0x00 > iInterface: 0x0B > 0x0409: "Playback Inactive" > > Interface Descriptor: > bInterfaceNumber: 0x01 > bAlternateSetting:0x01 > bNumEndpoints:0x01 > bInterfaceClass: 0x01 (Audio) > bInterfaceSubClass: 0x02 (Audio Streaming) > bInterfaceProtocol: 0x00 > iInterface: 0x0C > 0x0409: "Playback Active" > > Audio Streaming Class Specific Interface Descriptor: > bLength: 0x07 > bDescriptorType: 0x24 > bDescriptorSubtype: 0x01 > bTerminalLink:0x01 > bDelay: 0x01 > wFormatTag: 0x0001 (PCM) > > Audio Streaming Format Type Descriptor: > bLength: 0x0B > bDescriptorType: 0x24 > bDescriptorSubtype: 0x02 > bFormatType: 0x01 > bNrChannels: 0x00 > bSubframeSize:0x02 > bBitResolution: 0x10 > bSamFreqType: 0x01 > tSamFreq[1]: 0x00BB80 (48000 Hz) > > Endpoint Descriptor: > bEndpointAddress: 0x01 OUT > Transfer Type: Isochronous > wMaxPacketSize: 0x00C8 (200) > bInterval:0x04 > > Audio Streaming Class Specific Audio Data Endpoint Descriptor: > bLength: 0x07 > bDescriptorType: 0x25 > bDescriptorSubtype: 0x01 > bmAttributes: 0x00 > bLockDelayUnits: 0x00 > wLockDelay: 0x > > Interface Descriptor: > bInterfaceNumber: 0x02 > bAlternateSetting:0x00 > bNumEndpoints:0x00 > bInterfaceClass: 0x01 (Audio) > bInterfaceSubClass: 0x02 (Audio Streaming) > bInterfaceProtocol: 0x00 > iInterface: 0x0D > 0x0409: "Capture Inactive" > > Interface Descriptor: > bInterfaceNumber: 0x02 > bAlternateSetting:0x01 > bNumEndpoints:0x01 > bInterfaceClass: 0x01 (Audio) > bInterfaceSubClass: 0x02 (Audio Streaming) > bInterfaceProtocol: 0x0
Re: Modifying USB Audio gadget driver
On Wed, Dec 03, 2014 at 05:24:22PM -0600, Priya S wrote: > Great! That fixes it. Thanks. > > Windows is not able to install the driver though. These are the USB > descriptors that I see from the host-side: > > Device Descriptor: > bcdUSB: 0x0200 > bDeviceClass: 0x00 > bDeviceSubClass: 0x00 > bDeviceProtocol: 0x00 > bMaxPacketSize0: 0x40 (64) > idVendor: 0x1D6B > idProduct: 0x0101 > bcdDevice: 0x0316 > iManufacturer:0x01 > 0x0409: "Linux 3.2.0 with musb-hdrc" The 3.2.0 kernel release is _very_ old and obsolete. Please use something more recent, like 3.17, in order for us to help you out. If you are stuck at that old kernel version, please get support from the company you are paying to keep you at that kernel version, as that is who needs to support you. Best of 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: Modifying USB Audio gadget driver
Great! That fixes it. Thanks. Windows is not able to install the driver though. These are the USB descriptors that I see from the host-side: Device Descriptor: bcdUSB: 0x0200 bDeviceClass: 0x00 bDeviceSubClass: 0x00 bDeviceProtocol: 0x00 bMaxPacketSize0: 0x40 (64) idVendor: 0x1D6B idProduct: 0x0101 bcdDevice: 0x0316 iManufacturer:0x01 0x0409: "Linux 3.2.0 with musb-hdrc" iProduct: 0x02 0x0409: "Linux USB Audio Gadget" iSerialNumber:0x00 bNumConfigurations: 0x01 ConnectionStatus: DeviceConnected Current Config Value: 0x01 Device Bus Speed: High Device Address: 0x1B Open Pipes: 0 Configuration Descriptor: wTotalLength: 0x0095 bNumInterfaces: 0x03 bConfigurationValue: 0x01 iConfiguration: 0x00 bmAttributes: 0xC0 (Bus Powered Self Powered ) MaxPower: 0x01 (2 Ma) Interface Descriptor: bInterfaceNumber: 0x00 bAlternateSetting:0x00 bNumEndpoints:0x00 bInterfaceClass: 0x01 (Audio) bInterfaceSubClass: 0x01 (Audio Control) bInterfaceProtocol: 0x00 iInterface: 0x00 Audio Control Interface Header Descriptor: bLength: 0x0A bDescriptorType: 0x24 bDescriptorSubtype: 0x01 bcdADC: 0x0100 wTotalLength: 0x0028 bInCollection:0x02 baInterfaceNr[1]: 0x01 baInterfaceNr[2]: 0x02 Audio Control Input Terminal Descriptor: bLength: 0x0C bDescriptorType: 0x24 bDescriptorSubtype: 0x02 bTerminalID: 0x02 wTerminalType: 0x0201 (Microphone) bAssocTerminal: 0x00 bNrChannels: 0x02 wChannelConfig: 0x0003 iChannelNames:0x00 iTerminal:0x07 Audio Control Output Terminal Descriptor: bLength: 0x09 bDescriptorType: 0x24 bDescriptorSubtype: 0x03 bTerminalID: 0x01 wTerminalType: 0x0301 (Speaker) bAssocTerminal: 0x03 bSoruceID:0x03 iTerminal:0x09 Interface Descriptor: bInterfaceNumber: 0x01 bAlternateSetting:0x00 bNumEndpoints:0x00 bInterfaceClass: 0x01 (Audio) bInterfaceSubClass: 0x02 (Audio Streaming) bInterfaceProtocol: 0x00 iInterface: 0x0B 0x0409: "Playback Inactive" Interface Descriptor: bInterfaceNumber: 0x01 bAlternateSetting:0x01 bNumEndpoints:0x01 bInterfaceClass: 0x01 (Audio) bInterfaceSubClass: 0x02 (Audio Streaming) bInterfaceProtocol: 0x00 iInterface: 0x0C 0x0409: "Playback Active" Audio Streaming Class Specific Interface Descriptor: bLength: 0x07 bDescriptorType: 0x24 bDescriptorSubtype: 0x01 bTerminalLink:0x01 bDelay: 0x01 wFormatTag: 0x0001 (PCM) Audio Streaming Format Type Descriptor: bLength: 0x0B bDescriptorType: 0x24 bDescriptorSubtype: 0x02 bFormatType: 0x01 bNrChannels: 0x00 bSubframeSize:0x02 bBitResolution: 0x10 bSamFreqType: 0x01 tSamFreq[1]: 0x00BB80 (48000 Hz) Endpoint Descriptor: bEndpointAddress: 0x01 OUT Transfer Type: Isochronous wMaxPacketSize: 0x00C8 (200) bInterval:0x04 Audio Streaming Class Specific Audio Data Endpoint Descriptor: bLength: 0x07 bDescriptorType: 0x25 bDescriptorSubtype: 0x01 bmAttributes: 0x00 bLockDelayUnits: 0x00 wLockDelay: 0x Interface Descriptor: bInterfaceNumber: 0x02 bAlternateSetting:0x00 bNumEndpoints:0x00 bInterfaceClass: 0x01 (Audio) bInterfaceSubClass: 0x02 (Audio Streaming) bInterfaceProtocol: 0x00 iInterface: 0x0D 0x0409: "Capture Inactive" Interface Descriptor: bInterfaceNumber: 0x02 bAlternateSetting:0x01 bNumEndpoints:0x01 bInterfaceClass: 0x01 (Audio) bInterfaceSubClass: 0x02 (Audio Streaming) bInterfaceProtocol: 0x00 iInterface: 0x0E 0x0409: "Capture Active" Audio Streaming Class Specific Interface Descriptor: bLength: 0x07 bDescriptorType: 0x24 bDescriptorSubtype: 0x01 bTerminalLink:0x02 bDelay: 0x01 wFormatTag: 0x0001 (PCM) Audio Streaming Format Type Descriptor: bLength: 0x0B bDescriptorType: 0x24 bDescriptorSubtype: 0x02 bFormatType: 0x01 bNrChannels: 0x00 bSubframeSize:0x02 bBitResolution: 0x10 bSamFreqType: 0x01 tSamFreq[1]: 0x00BB80 (48000 Hz) Endpoint Descriptor: bEndpointAddress: 0x81 IN Transfer Type: Isochronous wMaxPacketSize: 0x00C8 (200) bInterval:0x04 Audio Streaming Class Specific Audio Data Endpoint Descriptor: bLength: 0x07 bDescriptorType: 0x25 bDescriptorSubtype: 0x01 bmAttributes: 0x00 bLockDelayUnits: 0x00 wLockDelay: 0x What could I possibly be missing? On Wed, Dec 3, 2014 at 4:08 PM, Alan Stern wrote: > On Wed, 3 Dec 2014, Priya S wrote: > >> Thank you. >> >> I've creat
Re: [PATCH v1] usb: phy: generic: migrate to gpio_desc
Alexandre Courbot writes: > I think what you want to do is explained in the "Platform Data" > section of Documentation/gpio/board.txt Ah yeah, already one year and I never checked again this documemtation. Thanks. -- 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: Modifying USB Audio gadget driver
On Wed, 3 Dec 2014, Priya S wrote: > Thank you. > > I've created 2 endpoints. I've defined the endpoint descriptors in the > driver. The IN bEndpointAddress = 0x80 and the OUT endpoint has > bEndpointAddress = 0x00. These values are being modified in > epautoconf.c to 0x81 and 0x01. > > On the Windows host though, I still see that the gadget's endpoint > addresses are 0x80 and 0x00. > > Where else could these values be overwritten? They aren't getting overwritten -- in fact, they aren't getting to the host at all! The values 0x80 and 0x00 refer to endpoint 0, which is always present on every USB device. You're trying to create endpoints 1-IN and 1-OUT, which should have addresses 0x81 and 0x01. 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: Modifying USB Audio gadget driver
Thank you. I've created 2 endpoints. I've defined the endpoint descriptors in the driver. The IN bEndpointAddress = 0x80 and the OUT endpoint has bEndpointAddress = 0x00. These values are being modified in epautoconf.c to 0x81 and 0x01. On the Windows host though, I still see that the gadget's endpoint addresses are 0x80 and 0x00. Where else could these values be overwritten? On Wed, Dec 3, 2014 at 3:28 PM, Greg KH wrote: > On Wed, Dec 03, 2014 at 03:07:11PM -0600, Priya S wrote: >> Hi, >> >> I'm trying to modify the USB Audio Class 1 (UAC1) audio gadget driver >> to make it capable of both sending and receiving audio from the host. >> Currently it can only receive audio from the host. >> >> I've been having some issues modifying the driver. Is this the right >> mailing list to post questions about this? > > Yes it is, ask away! > > 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: Modifying USB Audio gadget driver
On Wed, Dec 03, 2014 at 03:07:11PM -0600, Priya S wrote: > Hi, > > I'm trying to modify the USB Audio Class 1 (UAC1) audio gadget driver > to make it capable of both sending and receiving audio from the host. > Currently it can only receive audio from the host. > > I've been having some issues modifying the driver. Is this the right > mailing list to post questions about this? Yes it is, ask away! 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 3.0 drive crashes system when plugged in - regression
On 2014-12-03 10:53, Oliver Neukum wrote: > On Wed, 2014-12-03 at 10:41 +0100, Marcin Zajączkowski wrote: >> 2014-12-03 Oliver Neukum wrote: >>> On Wed, 2014-12-03 at 00:29 +0100, Marcin Zajączkowski wrote: Hi, After upgrade to Fedora 21 with 3.17.3-300.fc21.x86_64 (from 3.14.x in Fedora 19) my USB 3.0 drive (Seagate Backup+ 1TB) stopped working with USB 3.0 port (works fine with USB 2.0 port). When plug in for the first time (USB 3.0 port) I see in log: > kernel: xhci_hcd :04:00.0: ERROR Transfer event for disabled endpoint or incorrect stream ring > kernel: xhci_hcd :04:00.0: @000241eec570 11979000 0002 0500 01078001 >>> >>> Are you using the UAS driver? >> >> Probably yes. How can check that and/or switch to not UAS driver for a test? > > Sysfs holds the information. I can be comfortably queried with the > "usb-devices" script. > > To switch drivers you can use the "no UAS" quirk which can be given as > a module parameter like other quirks. Thanks Olivier for your reply. UAS keyword helped me to ignore UAS for my drive (via `options usb-storage quirks=vendorId:productId:u`) and my drive can again be used via USB 3.0 port. I was also able to reproduce bug with the latest stable kernel version 3.17.4-301.fc21.x86_64 and I have found a few other UAS related bugs, but most of them seem to be already closed (fixed): https://bugzilla.redhat.com/show_bug.cgi?id=1121288 https://bugzilla.kernel.org/show_bug.cgi?id=79511 http://lists.opensuse.org/archive/opensuse-bugs/2014-07/msg00919.html I have also seen a patch on that mailing list submitted by Hans de Goede which disables UAS for ASM1051 devices: http://www.spinics.net/lists/linux-usb/msg113537.html What would you propose to do with the issue with that Seagate drive (family?)? To either track it or to temporary disable UAS for them globally (to not produce system crashes). Marcin -- 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
Modifying USB Audio gadget driver
Hi, I'm trying to modify the USB Audio Class 1 (UAC1) audio gadget driver to make it capable of both sending and receiving audio from the host. Currently it can only receive audio from the host. I've been having some issues modifying the driver. Is this the right mailing list to post questions about this? Regards, Priya -- 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: [GIT PULL] USB driver fixes for 3.18-rc7
On 02.12.2014 20:18, Greg KH wrote: > On Sun, Nov 30, 2014 at 11:47:20AM -0800, Linus Torvalds wrote: >> Hmm, Greg. >> >> I seem to get this problem possibly more commonly at boot these days: >> >> usb 1-6: new full-speed USB device number 2 using xhci_hcd >> usb 1-6: device descriptor read/64, error -71 >> xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1. >> usb 1-6: hub failed to enable device, error -22 >> usb 1-6: new full-speed USB device number 3 using xhci_hcd >> usb 1-6: device descriptor read/64, error -71 >> usb 1-6: hub failed to enable device, error -22 >> usb 1-6: new full-speed USB device number 4 using xhci_hcd >> usb 1-6: Device not responding to setup address. >> usb 1-6: Device not responding to setup address. >> usb 1-6: device not accepting address 4, error -71 >> usb 1-6: new full-speed USB device number 5 using xhci_hcd >> usb 1-6: Device not responding to setup address. >> usb 1-6: Device not responding to setup address. >> usb 1-6: device not accepting address 5, error -71 >> usb usb1-port6: unable to enumerate USB device >> >> and my keyboard doesn't work. I then unplug and re-plug it, and get >> >> usb 1-6: new full-speed USB device number 9 using xhci_hcd >> usb 1-6: New USB device found, idVendor=2516, idProduct=0020 >> usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 >> usb 1-6: Product: Quickfire Rapid i >> usb 1-6: Manufacturer: CM Storm >> >> Any ideas? Some setup delay that isn't long enough at boot time for a >> slightly finicky device? It has happened before, but now I've gotten >> it twice within a couple of days: >> >> Nov 02 12:18:56 i7.lan kernel: usb 1-6: device descriptor read/64, error >> -71 >> Nov 28 16:54:06 i7.lan kernel: usb 1-6: device descriptor read/64, error >> -71 >> Nov 30 11:26:35 i7.lan kernel: usb 1-6: device descriptor read/64, error >> -71 >> >> (I've had this keyboard since mid-September, and looking at the logs >> this machine has been rebooted 41 times since, with those three >> failures..) > > I've been seeing this occasionally recently as well, but was blaming a > "bad" USB 3 hub I have here that I use, and the problem goes away with a > replug. > > Mathias, any ideas what is going on here? > Looks like when xhci changed to use "new scheme" device enumeration for non SuperSpeed devices, we broke the device descriptor read retry for xhci. Normally we try to read the descriptor again, and if it still fails then fall back to old scheme. In this failing xhci case the slot is left in a default state after first failed descriptor read, and we then try to enable the slot again in retry, which is an invalid xhci context state change, and prints the error message: xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1 After this It might be hard to get the device addressed. I don't know why it fail the first device descriptor read, but fixing the xhci part should allow more real reties. I'll work on it. The change to use xhci "new scheme" enumeration was done in 3.14 to support known legacy devices requiring it. commit 48fc7dbd52c0559647291f33a10ccdc6cdbe4c72 -Mathias > greg k-h > >> >> Linus -- 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] usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN
On Wed, 3 Dec 2014, Sebastian Andrzej Siewior wrote:
> the following error pops up during "testusb -a -t 10"
> | musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128,
> f134e000/be842000 (bad dma)
> hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
> size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
> hcd_buffer_alloc() returning memory which is 32 bytes aligned and it
> might by identified by buffer_offset() as another buffer. This means the
> buffer which is on a 32 byte boundary will not get freed, instead it
> tries to free another buffer with the error message.
>
> This patch fixes the issue by creating the smallest DMA buffer with the
> size of ARCH_KMALLOC_MINALIGN (or 32 in case ARCH_KMALLOC_MINALIGN is
> smaller).
> This might be 32, 64 or even 128 bytes. The next three pools will have
> the size 128, 512 and 2048.
> In case the smallest pool is 128 bytes then we have only three pools
> instead of four.
> The last pool size is always 2048 bytes which is the assumed PAGE_SIZE /
> 2 of 4096. I doubt it makes sense to continue using PAGE_SIZE / 2 where
> we would end up with 8KiB buffer in case we have 16KiB pages.
> Instead I think it makes sense to have a common size(s) and extend them
> if there is need to.
> There is a BUILD_BUG_ON() now in case someone has a minalign of more than
> 128 bytes.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> v2…v3:
> - rewrite and use usb_init_pool_max() instead. Albeit the value
> __alignof__(x) is known at compile time it can't be used in #if
> statement by the CPP. The max_t and if statment in this patch is
> optimized away by the compiler
> - replace PAGE_SIZE / 2 by 2048.
>
> v1…v2: rewrite pool_max so it is less confusing.
>
> drivers/usb/core/buffer.c | 31 ++-
> drivers/usb/core/usb.c| 1 +
> include/linux/usb/hcd.h | 1 +
> 3 files changed, 24 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
> index 684ef70dc09d..8f58b88e9c6b 100644
> --- a/drivers/usb/core/buffer.c
> +++ b/drivers/usb/core/buffer.c
> @@ -22,17 +22,30 @@
> */
>
> /* FIXME tune these based on pool statistics ... */
> -static const size_t pool_max[HCD_BUFFER_POOLS] = {
> - /* platforms without dma-friendly caches might need to
> +static size_t pool_max[HCD_BUFFER_POOLS];
> +
> +void __init usb_init_pool_max(void)
> +{
> + unsigned pool_size = max_t(unsigned, ARCH_KMALLOC_MINALIGN, 32);
> + int i = 0;
> +
> + /*
> + * platforms without dma-friendly caches might need to
>* prevent cacheline sharing...
> + * MIN [1] [2] [3]
> + * 32 128 512 2048
> + * 64 128 512 2048
> + * 128 512 2048-
>*/
The stuff you added to this comment won't mean anything to somebody
unless they already know what's going on. The code below is also
confusing. How does this look instead?
static size_t pool_max[HCD_BUFFER_POOLS] = {
32, 128, 512, 2048;
}
...
/*
* The pool_max values must never be smaller than
* ARCH_KMALLOC_MINALIGN.
*/
if (ARCH_KMALLOC_MINALIGN <= 32)
; /* Original value is okay */
else if (ARCH_KMALLOC_MINALIGN <= 64)
pool_max[0] = 64;
else if (ARCH_KMALLOC_MINALIGN <= 128)
pool_max[0] = 0;/* Don't use this pool */
else
BUILD_BUG();/* We don't allow this */
The compiler should eliminate most of that.
> - 32,
> - 128,
> - 512,
> - PAGE_SIZE / 2
> - /* bigger --> allocate pages */
> -};
> -
> + pool_max[i++] = pool_size;
> + if (pool_size < 128)
> + pool_max[i++] = 128;
> + pool_max[i++] = 512;
> + pool_max[i++] = 2048;
> +
> + /* MINALIGN > 128 hasn't been considered yet */
> + BUILD_BUG_ON(ARCH_KMALLOC_MINALIGN > 128);
> +}
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
[PATCH v3] usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN
the following error pops up during "testusb -a -t 10"
| musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128, f134e000/be842000 (bad
dma)
hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
hcd_buffer_alloc() returning memory which is 32 bytes aligned and it
might by identified by buffer_offset() as another buffer. This means the
buffer which is on a 32 byte boundary will not get freed, instead it
tries to free another buffer with the error message.
This patch fixes the issue by creating the smallest DMA buffer with the
size of ARCH_KMALLOC_MINALIGN (or 32 in case ARCH_KMALLOC_MINALIGN is smaller).
This might be 32, 64 or even 128 bytes. The next three pools will have
the size 128, 512 and 2048.
In case the smallest pool is 128 bytes then we have only three pools
instead of four.
The last pool size is always 2048 bytes which is the assumed PAGE_SIZE /
2 of 4096. I doubt it makes sense to continue using PAGE_SIZE / 2 where
we would end up with 8KiB buffer in case we have 16KiB pages.
Instead I think it makes sense to have a common size(s) and extend them
if there is need to.
There is a BUILD_BUG_ON() now in case someone has a minalign of more than
128 bytes.
Cc: sta...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior
---
v2…v3:
- rewrite and use usb_init_pool_max() instead. Albeit the value
__alignof__(x) is known at compile time it can't be used in #if
statement by the CPP. The max_t and if statment in this patch is
optimized away by the compiler
- replace PAGE_SIZE / 2 by 2048.
v1…v2: rewrite pool_max so it is less confusing.
drivers/usb/core/buffer.c | 31 ++-
drivers/usb/core/usb.c| 1 +
include/linux/usb/hcd.h | 1 +
3 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index 684ef70dc09d..8f58b88e9c6b 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -22,17 +22,30 @@
*/
/* FIXME tune these based on pool statistics ... */
-static const size_tpool_max[HCD_BUFFER_POOLS] = {
- /* platforms without dma-friendly caches might need to
+static size_t pool_max[HCD_BUFFER_POOLS];
+
+void __init usb_init_pool_max(void)
+{
+ unsigned pool_size = max_t(unsigned, ARCH_KMALLOC_MINALIGN, 32);
+ int i = 0;
+
+ /*
+* platforms without dma-friendly caches might need to
* prevent cacheline sharing...
+* MIN [1] [2] [3]
+* 32 128 512 2048
+* 64 128 512 2048
+* 128 512 2048-
*/
- 32,
- 128,
- 512,
- PAGE_SIZE / 2
- /* bigger --> allocate pages */
-};
-
+ pool_max[i++] = pool_size;
+ if (pool_size < 128)
+ pool_max[i++] = 128;
+ pool_max[i++] = 512;
+ pool_max[i++] = 2048;
+
+ /* MINALIGN > 128 hasn't been considered yet */
+ BUILD_BUG_ON(ARCH_KMALLOC_MINALIGN > 128);
+}
/* SETUP primitives */
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 2dd2362198d2..29ee9363faa5 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -1051,6 +1051,7 @@ static int __init usb_init(void)
pr_info("%s: USB support disabled\n", usbcore_name);
return 0;
}
+ usb_init_pool_max();
retval = usb_debugfs_init();
if (retval)
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index cd96a2bc3388..9e8d161bf2db 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -450,6 +450,7 @@ extern const struct dev_pm_ops usb_hcd_pci_pm_ops;
#endif /* CONFIG_PCI */
/* pci-ish (pdev null is ok) buffer alloc/mapping support */
+void usb_init_pool_max(void);
int hcd_buffer_create(struct usb_hcd *hcd);
void hcd_buffer_destroy(struct usb_hcd *hcd);
--
2.1.3
--
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] arm: omap3: twl: remove usb phy init data
On Wed, Dec 03, 2014 at 11:11:09AM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > On Monday 01 December 2014 02:14 PM, Kishon Vijay Abraham I wrote: > > From: Heikki Krogerus > > > > The driver does no use it any more. > > > > Signed-off-by: Heikki Krogerus > > Signed-off-by: Kishon Vijay Abraham I > > This patch is required to get rid of the error that Stephen Rothwell reported. Then please resend it in a format that I can apply it in. 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] phy: add Rockchip RK3288 USB2 PHY driver.
On Wed, Dec 03, 2014 at 09:46:50PM +0800, LiYunzhi wrote: > From: lyz > > Add a driver for the Rockchip SoC internal USB2.0 PHY. > This driver currently support RK3288. > > Signed-off-by: lyz Is this the name you use to sign legal documents? That is what you need to put in your Signed-off-by: and "From:" lines. 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: Ask for help about usb EHCI issue
On Wed, 3 Dec 2014, walkrain wrote: > Hi Stern: > Good afternoon ! Messages like this should always be CC'ed to the linux-usb@vger.kernel.org mailing list. > I am a software engineer in Spreadtrum company in Shanghai,China. > Recently I met a usb issue: > when I plug my mass_storage u-disk to my smart-phone platform and play music > from the u-disk > sometimes it will occurs some errors as follow: > 01-01 01:22:21.259 <3>[ 4950.969390] c1 hub 1-0:1.0: port 1 disabled by hub > (EMI?), re-enabling... > I have found that you have a commit on kernel on Fri,Aug 24 2007: > > commit 14c04c0f88f228fee1f412be91d6edcb935c78aa > Author: Alan Stern > Date: Fri Aug 24 15:40:19 2007 -0400 > USB: reorganize urb->status use in ehci-hcd > This patch (as974) reorganizes the way ehci-hcd sets urb->status. It > now keeps the information in a local variable until the last moment. > The patch also simplifies the handling of -EREMOTEIO, since the only > use of that code is to set the do_status flag. > Signed-off-by: Alan Stern > CC: David Brownell > Signed-off-by: Greg Kroah-Hartman > diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c > index a8f5408..794d27e 100644 > --- a/drivers/usb/host/ehci-q.c > +++ b/drivers/usb/host/ehci-q.c > > but my SOC USB IP is DWC_otg (synopsys product) > and I am not very familiar with dwc_otg driver very well > do you know: > what usb transfer error that will make usb controller root hub disable? I don't know anything about the DWC controller. That's why it's important to use the mailing list -- so that your message will be seen by the people who are able to help. In general, a hub will disable a port if the device attached to that port babbles (sends data at the wrong time). Electromagnetic interference or a bad connection can have the same effect. 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
[PATCH 2/2] dma: cppi41: add a delay while setting the TD bit
The manual says that we need to (repeatedly) set the TearDown-bit for
the endpoint in order to get the active transfer descriptor released.
Doing this "real" quick over and over again seems to work but it also
seems that the hardware might not have enough time to breathe. So I
though, hey lets add a udelay() between between the individual sets
of the bit.
This change with the g_zero testcase resulted in a warning about missing
transfer descriptor (we got the tear-down one). It seems that if the
hardware has some time it manages to release the transfer-descriptor on
the completion queue after the teaddown descriptor.
With this change, I observe that the transfer descriptor is released
after 20-30 retry loops.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/dma/cppi41.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index cb97b73482da..54e9db1cd833 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -1,3 +1,4 @@
+#include
#include
#include
#include
@@ -603,12 +604,16 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
* descriptor before the TD we fetch it from enqueue, it has to be
* there waiting for us.
*/
- if (!c->td_seen && c->td_retry)
+ if (!c->td_seen && c->td_retry) {
+ udelay(1);
return -EAGAIN;
-
+ }
WARN_ON(!c->td_retry);
+
if (!c->td_desc_seen) {
desc_phys = cppi41_pop_desc(cdd, c->q_num);
+ if (!desc_phys)
+ desc_phys = cppi41_pop_desc(cdd, c->q_comp_num);
WARN_ON(!desc_phys);
}
--
2.1.3
--
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 1/2] dma: cppi41: wait longer for the HW to return the descriptor
For a "complete" teardown we have to wait until the teardown descriptor
is returned by the hardware. The g_zero testcase "testusb -a -t 9" triggers
the following warning quite reliable:
|[ cut here ]
|WARNING: CPU: 0 PID: 0 at drivers/dma/cppi41.c:609
cppi41_dma_control+0x198/0x304()
|[] (warn_slowpath_null) from []
|[] (cppi41_dma_control) from []
|[] (cppi41_dma_channel_abort [musb_hdrc])
|[] (nuke.constprop.10 [musb_hdrc])
|[] (musb_gadget_disable [musb_hdrc])
|[] (disable_endpoints [usb_f_ss_lb])
|[] (disable_source_sink [usb_f_ss_lb])
|[] (sourcesink_set_alt [usb_f_ss_lb])
|[] (composite_setup [libcomposite])
|[] (musb_g_ep0_irq [musb_hdrc])
|[] (musb_interrupt [musb_hdrc])
|[] (dsps_interrupt [musb_dsps])
|[] (handle_irq_event_percpu)
|[] (handle_irq_event)
|[] (handle_level_irq)
|[] (generic_handle_irq)
|[] (handle_IRQ)
|[] (omap3_intc_handle_irq)
and complains about a TD descriptor which is not returned. I've been
looking at several things and haven't noticed anything unusual that
might lead to this.
The manual says "to try again" until the descriptor comes out. I limited
the amount of retries to 100 retries in order to avoid an infinite number
of retries and so a busy-loop. Back then testing revealed that the
number of retries were around 20-30 so 100 seemed a good upper limit.
This g_zero test reaches without a problem 98 retries and it jumps
sometimes to 101 on am335x-evm and so the WARN_ON() triggers. Same test
run on beaglebone black and the retries start at 122 and my max value so
far was at 128.
So lets rise the limit to 500.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/dma/cppi41.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index a58eec3b2cad..cb97b73482da 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -567,7 +567,7 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
reg |= GCR_TEARDOWN;
cppi_writel(reg, c->gcr_reg);
c->td_queued = 1;
- c->td_retry = 100;
+ c->td_retry = 500;
}
if (!c->td_seen || !c->td_desc_seen) {
--
2.1.3
--
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] phy: add Rockchip RK3288 USB2 PHY driver.
From: lyz
Add a driver for the Rockchip SoC internal USB2.0 PHY.
This driver currently support RK3288.
Signed-off-by: lyz
---
.../devicetree/bindings/phy/rockchip-usb-phy.txt | 17 ++
drivers/phy/Kconfig| 7 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-rockchip-usb.c | 179 +
4 files changed, 204 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
create mode 100644 drivers/phy/phy-rockchip-usb.c
diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
new file mode 100644
index 000..18ccc2f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
@@ -0,0 +1,17 @@
+ROCKCHIP USB2 PHY
+
+Required properties:
+ - compatible: rockchip,rk3288-usb-phy
+ - rockchip,grf : phandle to the syscon managing the "general
+ register files"
+ - #phy-cells: must be 1
+Refer to phy/phy-bindings.txt for the generic PHY binding
+properties
+
+Example:
+
+ usbphy: phy {
+ #phy-cells = <1>;
+ compatible = "rockchip,rk3288-usb-phy";
+ rockchip,grf = <&grf>;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2a436e6..54ab088 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -218,6 +218,13 @@ config PHY_QCOM_IPQ806X_SATA
depends on OF
select GENERIC_PHY
+config PHY_ROCKCHIP_RK3288_USB2
+ tristate "Rockchip USB2 RK3288 PHY Driver"
+ depends on ARCH_ROCKCHIP && OF
+ select GENERIC_PHY
+ help
+ Enable this to support the Rockchip USB 2.0 PHY.
+
config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index c4590fc..f4f2f79 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -25,6 +25,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2) +=
phy-exynos5250-usb2.o
phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) += phy-s5pv210-usb2.o
obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
+obj-$(CONFIG_PHY_ROCKCHIP_RK3288_USB2) += phy-rockchip-usb.o
obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
new file mode 100644
index 000..2586b76
--- /dev/null
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -0,0 +1,179 @@
+/*
+ * Rockchip usb PHY driver
+ *
+ * Copyright (C) 2014 Roy Li
+ * Copyright (C) 2014 ROCKCHIP, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ROCKCHIP_RK3288_UOC(n) (0x320 + n * 0x14)
+
+#define SIDDQ_MSK (1 << (13 + 16))
+#define SIDDQ_ON (1 << 13)
+#define SIDDQ_OFF (0 << 13)
+
+enum rk3288_phy_id {
+ RK3288_OTG,
+ RK3288_HOST0,
+ RK3288_HOST1,
+ RK3288_NUM_PHYS,
+};
+
+struct rockchip_usb_phy {
+ struct regmap *reg_base;
+ unsigned int reg_offset;
+ struct clk *clk;
+ struct phy *phy;
+};
+
+static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
+ bool siddq)
+{
+ return regmap_write(phy->reg_base, phy->reg_offset,
+ SIDDQ_MSK | (siddq ? SIDDQ_ON : SIDDQ_OFF));
+}
+
+static int rockchip_usb_phy_power_off(struct phy *_phy)
+{
+ struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
+ int ret = 0;
+
+ /* Power down usb phy analog blocks by set siddq 1*/
+ ret = rockchip_usb_phy_power(phy, 1);
+ if (ret)
+ return ret;
+
+ clk_disable_unprepare(phy->clk);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int rockchip_usb_phy_power_on(struct phy *_phy)
+{
+ struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
+ int ret = 0;
+
+ ret = clk_prepare_enable(phy->clk);
+ if (ret)
+ return ret;
+
+ /* Power up usb phy analog blocks by set siddq 0*/
+ ret = rockchip_usb_phy_power(phy, 0);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static struct phy *rockchip_usb_phy_xlate(
[PATCH] add a PHY driver Rockchip RK3288 USB2 PHY
From: lyz This patche to add a generic PHY driver for ROCKCHIP usb PHYs, currently this driver can support RK3288. The RK3288 SoC have three independent USB PHY IPs which are all configured through a set of registers located in the GRF (general register files) module. This driver powered off these USB PHYs and gating their clocks when system suspend for saving power. lyz (1): phy: add Rockchip RK3288 USB2 PHY driver. .../devicetree/bindings/phy/rockchip-usb-phy.txt | 17 ++ drivers/phy/Kconfig| 7 + drivers/phy/Makefile | 1 + drivers/phy/phy-rockchip-usb.c | 179 + 4 files changed, 204 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt create mode 100644 drivers/phy/phy-rockchip-usb.c -- 2.0.0 -- 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 V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7
On Mon, Dec 1, 2014 at 3:21 PM, Vivek Gautam wrote: > On Fri, Nov 28, 2014 at 9:15 PM, Linus Walleij > wrote: >> Apart from that, there are *again* a lot of Exynos patches flying around and >> I start to loose track of them. If they do not apply together and start to >> conflict I will just ask Tomasz to stack them and provide a pull request >> again. > > True, this merge cycle has surely got number of exynos7 related > patches in flight, > which are difficult to keep track of. > Thanks for asking Tomasz. I will probably not take any more Exynos patches for this merge cycle and ask Tomasz to queue the Exynos pinctrl patches for v3.20 after v3.19 merge cycle is complete, so make sure to include Tomasz on reviews. Tomasz: OK? Yours, Linus Walleij -- 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
Western Union wünscht Ihnen ein frohes Weihnachts Im Voraus
Bestätigen Sie Ihre (€ 500.000,00 Euro) Herzlichen Glückwunsch Liebe Begünstigte, Sie haben als einzige Nutznießer der Summe von fünfhunderttausend Euro (€ 500.000,00 Euro), die hier in WESTERN UNION OFFICE durch die ONU Organisation für Sie hinterlegt wurde ausgewählt. http://en.wikipedia.org/wiki/United_Nations Kundendienst Western Union Office® -- 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: gadget: zero: fix INT endpoint assignment
On 11/25/2014 10:52 PM, Sebastian Andrzej Siewior wrote:
The max packet size within the FS descriptor has to be highest possible
value and _not_ the one that is (or will be) used on FS.
The current code sets wMaxPacketSize of FS interrupt endpoint descriptor
as 64, which is in accordance with the usb 2.0 specification, section 5.7.3
I know about the specification. The "1024" is only used initially while
allocating endpoints. It is never passed to the host at FS.
The way the code works (since day 1) is that usb_ep_autoconfig() is
invoked _only_ on the FS endpoint and then the endpoint address is
copies over to HS/SS endpoints. If the any of the "critical" options are
different between FS and HS then we have to pass the HS value and
I think you meant " then we have to pass the *FS* value ", right??
correct later.
What now happens is that we look for an INT-OUT endpoint of 64bytes. The
code will return an endpoint matching this category. Further the
sourcesink will take this endpoint and increase the MPS to 1024. On
SourceSink does this unconditionally, assuming the corresponding EP
supports MPS of 1024. This assumption is incorrect, atleast for net2280
and musb, causing regressions.
This is valid only for HS and SS interrupt endpoints. Right?
Correct *but* the chosen endpoint may not be capable of MPS > what you
were looking for.
net2280 for instance the code tries to be clever to return an endpoint
which can only do 64 MPS. The same happens on musb where we mostlike get
an endpoint which can only do 512. The result is then on the host side:
What is the speed at which your device is operating?
HS.
|~# testusb -a -t 9 -c 2
|unknown speed /dev/bus/usb/002/0450
|usbtest 2-1:3.0: TEST 9: ch9 (subset) control tests, 2 times
|usbtest 2-1:3.0: can't set_interface = 2, -32
|usbtest 2-1:3.0: ch9 subset failed, iterations left 1
|/dev/bus/usb/002/045 test 9 --> 32 (Broken pipe)
because the on the gadget side we can't enable the endpoint because
desc->size > ep->max_size.
Fixes: ef11982dd7a6 ("usb: gadget: zero: Add support for interrupt EP")
Signed-off-by: Sebastian Andrzej Siewior
What I understood is as an effect of this patch, for musb and net2280
ep_autoconfig would provide EPs only in case it is able to find having
MPS of 1024 bytes. In case it doesn't find a free EP, the device won't
have interrupt support at all.
---
drivers/usb/gadget/function/f_sourcesink.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/gadget/function/f_sourcesink.c
b/drivers/usb/gadget/function/f_sourcesink.c
index 80be25b32cd7..7d8f0216e1a6 100644
--- a/drivers/usb/gadget/function/f_sourcesink.c
+++ b/drivers/usb/gadget/function/f_sourcesink.c
@@ -161,7 +161,7 @@ static struct usb_endpoint_descriptor
fs_int_source_desc = {
.bEndpointAddress =USB_DIR_IN,
.bmAttributes =USB_ENDPOINT_XFER_INT,
-.wMaxPacketSize =cpu_to_le16(64),
+.wMaxPacketSize =cpu_to_le16(1024),
.bInterval =GZERO_INT_INTERVAL,
};
@@ -171,7 +171,7 @@ static struct usb_endpoint_descriptor
fs_int_sink_desc = {
.bEndpointAddress =USB_DIR_OUT,
.bmAttributes =USB_ENDPOINT_XFER_INT,
-.wMaxPacketSize =cpu_to_le16(64),
+.wMaxPacketSize =cpu_to_le16(1024),
.bInterval =GZERO_INT_INTERVAL,
};
This change in wMAxPacketSize of FS interrupt descriptors is violation
of the specs.
It is changed back before the descriptor is sent to the host.
That is correct, I agree... but still it is a hack :)
@@ -556,16 +556,6 @@ sourcesink_bind(struct usb_configuration *c,
struct usb_function *f)
if (int_maxburst > 15)
int_maxburst = 15;
-/* fill in the FS interrupt descriptors from the module
parameters */
-fs_int_source_desc.wMaxPacketSize = int_maxpacket > 64 ?
-64 : int_maxpacket;
-fs_int_source_desc.bInterval = int_interval > 255 ?
-255 : int_interval;
-fs_int_sink_desc.wMaxPacketSize = int_maxpacket > 64 ?
-64 : int_maxpacket;
-fs_int_sink_desc.bInterval = int_interval > 255 ?
-255 : int_interval;
-
/* allocate int endpoints */
ss->int_in_ep = usb_ep_autoconfig(cdev->gadget,
&fs_int_source_desc);
if (!ss->int_in_ep)
@@ -587,6 +577,16 @@ sourcesink_bind(struct usb_configuration *c,
struct usb_function *f)
if (int_maxpacket > 1024)
int_maxpacket = 1024;
+/* fill in the FS interrupt descriptors from the module
parameters */
+fs_int_source_desc.wMaxPacketSize = int_maxpacket > 64 ?
+64 : int_maxpacket;
+fs_int_source_desc.bInterval = int_interval > 255 ?
+255 : int_interval;
+fs_int_sink_desc.wMaxPacketSize = int_maxpacket > 64 ?
+64 : int_maxpacket;
+fs_int_sink_desc.bInterval = int_interval > 25
[PATCH 01/11] usb: gadget: at91_udc: Fix clock names
The driver is requesting clock by their global name (those declared in the clk_lookup list), but this only works with !CCF kernels. Now that all SoCs have moved to CCF, fix the driver to use local names (hclk and pclk). Signed-off-by: Boris Brezillon --- drivers/usb/gadget/udc/at91_udc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/udc/at91_udc.c b/drivers/usb/gadget/udc/at91_udc.c index 0716c19..ca6a4b8 100644 --- a/drivers/usb/gadget/udc/at91_udc.c +++ b/drivers/usb/gadget/udc/at91_udc.c @@ -1766,8 +1766,8 @@ static int at91udc_probe(struct platform_device *pdev) udc_reinit(udc); /* get interface and function clocks */ - udc->iclk = clk_get(dev, "udc_clk"); - udc->fclk = clk_get(dev, "udpck"); + udc->iclk = clk_get(dev, "pclk"); + udc->fclk = clk_get(dev, "hclk"); if (IS_ENABLED(CONFIG_COMMON_CLK)) udc->uclk = clk_get(dev, "usb_clk"); if (IS_ERR(udc->iclk) || IS_ERR(udc->fclk) || -- 1.9.1 -- 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 03/11] usb: gadget: at91_udc: Document DT clocks and clock-names property
The at91_udc driver request 2 clocks, and thus need them to be defined in the device tree. Document the clocks and clock-names properties so that everybody use the correct names. Signed-off-by: Boris Brezillon --- Documentation/devicetree/bindings/usb/atmel-usb.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt index bcc..6007231 100644 --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt @@ -36,6 +36,10 @@ Required properties: - compatible: Should be "atmel,at91rm9200-udc" - reg: Address and length of the register set for the device - interrupts: Should contain macb interrupt + - clocks: Should reference the peripheral and the AHB clocks + - clock-names: Should contains two strings + "pclk" for the peripheral clock + "hclk" for the AHB clock Optional properties: - atmel,vbus-gpio: If present, specifies a gpio that needs to be -- 1.9.1 -- 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 02/11] usb: gadget: at91_udc: Drop uclk clock
Now that at91 system clocks forward set_rate request to their parent we
can remove the uclk clock and directly call clk_set_rate on fclk.
Signed-off-by: Boris Brezillon
---
drivers/usb/gadget/udc/at91_udc.c | 27 +++
drivers/usb/gadget/udc/at91_udc.h | 2 +-
2 files changed, 4 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/gadget/udc/at91_udc.c
b/drivers/usb/gadget/udc/at91_udc.c
index ca6a4b8..4ecb576 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -870,8 +870,6 @@ static void clk_on(struct at91_udc *udc)
return;
udc->clocked = 1;
- if (IS_ENABLED(CONFIG_COMMON_CLK))
- clk_enable(udc->uclk);
clk_enable(udc->iclk);
clk_enable(udc->fclk);
}
@@ -884,8 +882,6 @@ static void clk_off(struct at91_udc *udc)
udc->gadget.speed = USB_SPEED_UNKNOWN;
clk_disable(udc->fclk);
clk_disable(udc->iclk);
- if (IS_ENABLED(CONFIG_COMMON_CLK))
- clk_disable(udc->uclk);
}
/*
@@ -1768,25 +1764,17 @@ static int at91udc_probe(struct platform_device *pdev)
/* get interface and function clocks */
udc->iclk = clk_get(dev, "pclk");
udc->fclk = clk_get(dev, "hclk");
- if (IS_ENABLED(CONFIG_COMMON_CLK))
- udc->uclk = clk_get(dev, "usb_clk");
- if (IS_ERR(udc->iclk) || IS_ERR(udc->fclk) ||
- (IS_ENABLED(CONFIG_COMMON_CLK) && IS_ERR(udc->uclk))) {
+ if (IS_ERR(udc->iclk) || IS_ERR(udc->fclk)) {
DBG("clocks missing\n");
retval = -ENODEV;
goto fail1;
}
/* don't do anything until we have both gadget driver and VBUS */
- if (IS_ENABLED(CONFIG_COMMON_CLK)) {
- clk_set_rate(udc->uclk, 4800);
- retval = clk_prepare(udc->uclk);
- if (retval)
- goto fail1;
- }
+ clk_set_rate(udc->fclk, 4800);
retval = clk_prepare(udc->fclk);
if (retval)
- goto fail1a;
+ goto fail1;
retval = clk_prepare_enable(udc->iclk);
if (retval)
@@ -1860,12 +1848,7 @@ fail1c:
clk_unprepare(udc->iclk);
fail1b:
clk_unprepare(udc->fclk);
-fail1a:
- if (IS_ENABLED(CONFIG_COMMON_CLK))
- clk_unprepare(udc->uclk);
fail1:
- if (IS_ENABLED(CONFIG_COMMON_CLK) && !IS_ERR(udc->uclk))
- clk_put(udc->uclk);
if (!IS_ERR(udc->fclk))
clk_put(udc->fclk);
if (!IS_ERR(udc->iclk))
@@ -1911,15 +1894,11 @@ static int __exit at91udc_remove(struct platform_device
*pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region(res->start, resource_size(res));
- if (IS_ENABLED(CONFIG_COMMON_CLK))
- clk_unprepare(udc->uclk);
clk_unprepare(udc->fclk);
clk_unprepare(udc->iclk);
clk_put(udc->iclk);
clk_put(udc->fclk);
- if (IS_ENABLED(CONFIG_COMMON_CLK))
- clk_put(udc->uclk);
return 0;
}
diff --git a/drivers/usb/gadget/udc/at91_udc.h
b/drivers/usb/gadget/udc/at91_udc.h
index 0175246..e647d1c 100644
--- a/drivers/usb/gadget/udc/at91_udc.h
+++ b/drivers/usb/gadget/udc/at91_udc.h
@@ -126,7 +126,7 @@ struct at91_udc {
unsignedactive_suspend:1;
u8 addr;
struct at91_udc_databoard;
- struct clk *iclk, *fclk, *uclk;
+ struct clk *iclk, *fclk;
struct platform_device *pdev;
struct proc_dir_entry *pde;
void __iomem*udp_baseaddr;
--
1.9.1
--
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 06/11] usb: gadget: at91_udc: Simplify probe and remove functions
Make use of devm_ functions to simplify probe and remove code.
Signed-off-by: Boris Brezillon
---
drivers/usb/gadget/udc/at91_udc.c | 116 +-
1 file changed, 39 insertions(+), 77 deletions(-)
diff --git a/drivers/usb/gadget/udc/at91_udc.c
b/drivers/usb/gadget/udc/at91_udc.c
index e7984c0..ef1ee07 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -1697,15 +1697,6 @@ static int at91udc_probe(struct platform_device *pdev)
int retval;
struct resource *res;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENXIO;
-
- if (!request_mem_region(res->start, resource_size(res), driver_name)) {
- DBG("someone's using UDC memory\n");
- return -EBUSY;
- }
-
/* init software state */
udc = &controller;
udc->gadget.dev.parent = dev;
@@ -1718,13 +1709,13 @@ static int at91udc_probe(struct platform_device *pdev)
if (cpu_is_at91rm9200()) {
if (!gpio_is_valid(udc->board.pullup_pin)) {
DBG("no D+ pullup?\n");
- retval = -ENODEV;
- goto fail0;
+ return -ENODEV;
}
- retval = gpio_request(udc->board.pullup_pin, "udc_pullup");
+ retval = devm_gpio_request(dev, udc->board.pullup_pin,
+ "udc_pullup");
if (retval) {
DBG("D+ pullup is busy\n");
- goto fail0;
+ return retval;
}
gpio_direction_output(udc->board.pullup_pin,
udc->board.pullup_active_low);
@@ -1743,32 +1734,32 @@ static int at91udc_probe(struct platform_device *pdev)
udc->ep[3].maxpacket = 64;
}
- udc->udp_baseaddr = ioremap(res->start, resource_size(res));
- if (!udc->udp_baseaddr) {
- retval = -ENOMEM;
- goto fail0a;
- }
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ udc->udp_baseaddr = devm_ioremap_resource(dev, res);
+ if (IS_ERR(udc->udp_baseaddr))
+ return PTR_ERR(udc->udp_baseaddr);
udc_reinit(udc);
/* get interface and function clocks */
- udc->iclk = clk_get(dev, "pclk");
- udc->fclk = clk_get(dev, "hclk");
- if (IS_ERR(udc->iclk) || IS_ERR(udc->fclk)) {
- DBG("clocks missing\n");
- retval = -ENODEV;
- goto fail1;
- }
+ udc->iclk = devm_clk_get(dev, "pclk");
+ if (IS_ERR(udc->iclk))
+ return PTR_ERR(udc->iclk);
+
+ udc->fclk = devm_clk_get(dev, "hclk");
+ if (IS_ERR(udc->fclk))
+ return PTR_ERR(udc->fclk);
/* don't do anything until we have both gadget driver and VBUS */
clk_set_rate(udc->fclk, 4800);
retval = clk_prepare(udc->fclk);
if (retval)
- goto fail1;
+ return retval;
retval = clk_prepare_enable(udc->iclk);
if (retval)
- goto fail1b;
+ goto err_unprepare_fclk;
+
at91_udp_write(udc, AT91_UDP_TXVC, AT91_UDP_TXVC_TXVDIS);
at91_udp_write(udc, AT91_UDP_IDR, 0x);
/* Clear all pending interrupts - UDP may be used by bootloader. */
@@ -1777,18 +1768,21 @@ static int at91udc_probe(struct platform_device *pdev)
/* request UDC and maybe VBUS irqs */
udc->udp_irq = platform_get_irq(pdev, 0);
- retval = request_irq(udc->udp_irq, at91_udc_irq,
- 0, driver_name, udc);
- if (retval < 0) {
+ retval = devm_request_irq(dev, udc->udp_irq, at91_udc_irq, 0,
+ driver_name, udc);
+ if (retval) {
DBG("request irq %d failed\n", udc->udp_irq);
- goto fail1c;
+ goto err_unprepare_iclk;
}
+
if (gpio_is_valid(udc->board.vbus_pin)) {
- retval = gpio_request(udc->board.vbus_pin, "udc_vbus");
- if (retval < 0) {
+ retval = devm_gpio_request(dev, udc->board.vbus_pin,
+ "udc_vbus");
+ if (retval) {
DBG("request vbus pin failed\n");
- goto fail2;
+ goto err_unprepare_iclk;
}
+
gpio_direction_input(udc->board.vbus_pin);
/*
@@ -1805,12 +1799,13 @@ static int at91udc_probe(struct platform_device *pdev)
mod_timer(&udc->vbus_timer,
jiffies + VBUS_POLL_TIMEOUT);
} else {
- if (request_irq(gpio_to_irq(udc->board.vbus_pin),
- at91_vbus_irq, 0, driver
[PATCH 04/11] ARM: at91/dt: at91sam9261: fix clocks and clock-names in udc definition
Peripheral clock is named pclk and system clock is named hclk (those are the names expected by the at91_udc driver). Drop the deprecated usb_clk (formerly used to configure the usb clock rate which is now directly configurable through hclk). Signed-off-by: Boris Brezillon --- arch/arm/boot/dts/at91sam9261.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/at91sam9261.dtsi b/arch/arm/boot/dts/at91sam9261.dtsi index a81aab4..7119f1f 100644 --- a/arch/arm/boot/dts/at91sam9261.dtsi +++ b/arch/arm/boot/dts/at91sam9261.dtsi @@ -122,8 +122,8 @@ compatible = "atmel,at91rm9200-udc"; reg = <0xfffa4000 0x4000>; interrupts = <10 IRQ_TYPE_LEVEL_HIGH 2>; - clocks = <&usb>, <&udc_clk>, <&udpck>; - clock-names = "usb_clk", "udc_clk", "udpck"; + clocks = <&udc_clk>, <&udpck>; + clock-names = "pclk", "hclk"; status = "disabled"; }; -- 1.9.1 -- 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 05/11] usb: gadget: at91_udc: Remove non-DT handling code
Since non-DT board support has been removed from the at91 architecture we
can safely remove non-DT handling code.
Signed-off-by: Boris Brezillon
---
drivers/usb/gadget/udc/Kconfig| 1 +
drivers/usb/gadget/udc/at91_udc.c | 16 ++--
2 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 217365d..36a598d 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -32,6 +32,7 @@ menu "USB Peripheral Controller"
config USB_AT91
tristate "Atmel AT91 USB Device Port"
depends on ARCH_AT91
+ depends on OF || COMPILE_TEST
help
Many Atmel AT91 processors (such as the AT91RM2000) have a
full speed USB Device Port with support for five configurable
diff --git a/drivers/usb/gadget/udc/at91_udc.c
b/drivers/usb/gadget/udc/at91_udc.c
index 4ecb576..e7984c0 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -1697,12 +1697,6 @@ static int at91udc_probe(struct platform_device *pdev)
int retval;
struct resource *res;
- if (!dev_get_platdata(dev) && !pdev->dev.of_node) {
- /* small (so we copy it) but critical! */
- DBG("missing platform_data\n");
- return -ENODEV;
- }
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -ENXIO;
@@ -1715,11 +1709,7 @@ static int at91udc_probe(struct platform_device *pdev)
/* init software state */
udc = &controller;
udc->gadget.dev.parent = dev;
- if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
- at91udc_of_init(udc, pdev->dev.of_node);
- else
- memcpy(&udc->board, dev_get_platdata(dev),
- sizeof(struct at91_udc_data));
+ at91udc_of_init(udc, pdev->dev.of_node);
udc->pdev = pdev;
udc->enabled = 0;
spin_lock_init(&udc->lock);
@@ -1955,14 +1945,12 @@ static int at91udc_resume(struct platform_device *pdev)
#defineat91udc_resume NULL
#endif
-#if defined(CONFIG_OF)
static const struct of_device_id at91_udc_dt_ids[] = {
{ .compatible = "atmel,at91rm9200-udc" },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, at91_udc_dt_ids);
-#endif
static struct platform_driver at91_udc_driver = {
.remove = __exit_p(at91udc_remove),
@@ -1972,7 +1960,7 @@ static struct platform_driver at91_udc_driver = {
.driver = {
.name = (char *) driver_name,
.owner = THIS_MODULE,
- .of_match_table = of_match_ptr(at91_udc_dt_ids),
+ .of_match_table = at91_udc_dt_ids,
},
};
--
1.9.1
--
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 00/11] usb: gadget: at91_udc: Rework for multi-platform support
Hello, This series reworks the at91_udc driver to prepare at91 for multi-platform support. It also include several fixes: - fix clock names to be consistent with other USB drivers - document clocks and clock-names properties in atmel-usb DT bindings doc and some cleanup changes: - remove useless usb_clk - allocate at91_udc instance instead of using the statically defined one - simplify the probe and remove functions by using devm_ helpers - remove !DT specific code The series depends on this patch [1] (which adds matrix registers definition). Regards, Boris [1]https://lkml.org/lkml/2014/12/3/230 Boris Brezillon (11): usb: gadget: at91_udc: Fix clock names usb: gadget: at91_udc: Drop uclk clock usb: gadget: at91_udc: Document DT clocks and clock-names property ARM: at91/dt: at91sam9261: fix clocks and clock-names in udc definition usb: gadget: at91_udc: Remove non-DT handling code usb: gadget: at91_udc: Simplify probe and remove functions usb: gadget: at91_udc: Rework for multi-platform kernel support usb: gadget: at91_udc: Update DT binding documentation usb: gadget: at91_udc: Allocate udc instance ARM: at91/dt: declare matrix node as a syscon device ARM: at91/dt: fix at91 udc compatible strings .../devicetree/bindings/usb/atmel-usb.txt | 10 +- arch/arm/boot/dts/at91sam9260.dtsi | 2 +- arch/arm/boot/dts/at91sam9261.dtsi | 9 +- arch/arm/boot/dts/at91sam9263.dtsi | 2 +- drivers/usb/gadget/udc/Kconfig | 1 + drivers/usb/gadget/udc/at91_udc.c | 530 +++-- drivers/usb/gadget/udc/at91_udc.h | 9 +- 7 files changed, 298 insertions(+), 265 deletions(-) -- 1.9.1 -- 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 07/11] usb: gadget: at91_udc: Rework for multi-platform kernel support
cpu_is_at91xxx are a set of macros defined in mach/cpu.h and are here used
to detect the SoC we are booting on.
Use compatible string + a caps structure to replace those cpu_is_xxx tests.
Remove all mach and asm headers (which are now unused).
Signed-off-by: Boris Brezillon
---
drivers/usb/gadget/udc/at91_udc.c | 288 --
drivers/usb/gadget/udc/at91_udc.h | 7 +
2 files changed, 218 insertions(+), 77 deletions(-)
diff --git a/drivers/usb/gadget/udc/at91_udc.c
b/drivers/usb/gadget/udc/at91_udc.c
index ef1ee07..f870c03 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -31,16 +31,9 @@
#include
#include
#include
-
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
+#include
+#include
+#include
#include "at91_udc.h"
@@ -890,8 +883,6 @@ static void clk_off(struct at91_udc *udc)
*/
static void pullup(struct at91_udc *udc, int is_on)
{
- int active = !udc->board.pullup_active_low;
-
if (!udc->enabled || !udc->vbus)
is_on = 0;
DBG("%sactive\n", is_on ? "" : "in");
@@ -900,40 +891,15 @@ static void pullup(struct at91_udc *udc, int is_on)
clk_on(udc);
at91_udp_write(udc, AT91_UDP_ICR, AT91_UDP_RXRSM);
at91_udp_write(udc, AT91_UDP_TXVC, 0);
- if (cpu_is_at91rm9200())
- gpio_set_value(udc->board.pullup_pin, active);
- else if (cpu_is_at91sam9260() || cpu_is_at91sam9263() ||
cpu_is_at91sam9g20()) {
- u32 txvc = at91_udp_read(udc, AT91_UDP_TXVC);
-
- txvc |= AT91_UDP_TXVC_PUON;
- at91_udp_write(udc, AT91_UDP_TXVC, txvc);
- } else if (cpu_is_at91sam9261() || cpu_is_at91sam9g10()) {
- u32 usbpucr;
-
- usbpucr = at91_matrix_read(AT91_MATRIX_USBPUCR);
- usbpucr |= AT91_MATRIX_USBPUCR_PUON;
- at91_matrix_write(AT91_MATRIX_USBPUCR, usbpucr);
- }
} else {
stop_activity(udc);
at91_udp_write(udc, AT91_UDP_IDR, AT91_UDP_RXRSM);
at91_udp_write(udc, AT91_UDP_TXVC, AT91_UDP_TXVC_TXVDIS);
- if (cpu_is_at91rm9200())
- gpio_set_value(udc->board.pullup_pin, !active);
- else if (cpu_is_at91sam9260() || cpu_is_at91sam9263() ||
cpu_is_at91sam9g20()) {
- u32 txvc = at91_udp_read(udc, AT91_UDP_TXVC);
-
- txvc &= ~AT91_UDP_TXVC_PUON;
- at91_udp_write(udc, AT91_UDP_TXVC, txvc);
- } else if (cpu_is_at91sam9261() || cpu_is_at91sam9g10()) {
- u32 usbpucr;
-
- usbpucr = at91_matrix_read(AT91_MATRIX_USBPUCR);
- usbpucr &= ~AT91_MATRIX_USBPUCR_PUON;
- at91_matrix_write(AT91_MATRIX_USBPUCR, usbpucr);
- }
clk_off(udc);
}
+
+ if (udc->caps && udc->caps->pullup)
+ udc->caps->pullup(udc, is_on);
}
/* vbus is here! turn everything on that's ready */
@@ -1670,12 +1636,202 @@ static void at91udc_shutdown(struct platform_device
*dev)
spin_unlock_irqrestore(&udc->lock, flags);
}
-static void at91udc_of_init(struct at91_udc *udc,
-struct device_node *np)
+static int at91rm9200_udc_init(struct at91_udc *udc)
+{
+ struct at91_ep *ep;
+ int ret;
+ int i;
+
+ for (i = 0; i < NUM_ENDPOINTS; i++) {
+ ep = &udc->ep[i];
+
+ switch (i) {
+ case 0:
+ case 3:
+ ep->maxpacket = 8;
+ break;
+ case 1 ... 2:
+ ep->maxpacket = 64;
+ break;
+ case 4 ... 5:
+ ep->maxpacket = 256;
+ break;
+ }
+ }
+
+ if (!gpio_is_valid(udc->board.pullup_pin)) {
+ DBG("no D+ pullup?\n");
+ return -ENODEV;
+ }
+
+ ret = devm_gpio_request(&udc->pdev->dev, udc->board.pullup_pin,
+ "udc_pullup");
+ if (ret) {
+ DBG("D+ pullup is busy\n");
+ return ret;
+ }
+
+ gpio_direction_output(udc->board.pullup_pin,
+ udc->board.pullup_active_low);
+
+ return 0;
+}
+
+static void at91rm9200_udc_pullup(struct at91_udc *udc, int is_on)
+{
+ int active = !udc->board.pullup_active_low;
+
+ if (is_on)
+ gpio_set_value(udc->board.pullup_pin, active);
+ else
+ gpio_set_value(udc->board.pullup_pin, !active);
+}
+
+static const struct at91_udc_caps at91rm9200_udc_caps = {
+ .init = at91rm9200_udc_init,
+ .pu
[PATCH 09/11] usb: gadget: at91_udc: Allocate udc instance
Allocate udc structure instead of relying on the statically declared
object.
Signed-off-by: Boris Brezillon
---
drivers/usb/gadget/udc/at91_udc.c | 101 ++
1 file changed, 27 insertions(+), 74 deletions(-)
diff --git a/drivers/usb/gadget/udc/at91_udc.c
b/drivers/usb/gadget/udc/at91_udc.c
index f870c03..2b20dd7 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -59,7 +59,15 @@
#defineDRIVER_VERSION "3 May 2006"
static const char driver_name [] = "at91_udc";
-static const char ep0name[] = "ep0";
+static const char * const ep_names[] = {
+ "ep0",
+ "ep1",
+ "ep2",
+ "ep3-int",
+ "ep4",
+ "ep5",
+};
+#define ep0nameep_names[0]
#define VBUS_POLL_TIMEOUT msecs_to_jiffies(1000)
@@ -1477,78 +1485,6 @@ static void nop_release(struct device *dev)
/* nothing to free */
}
-static struct at91_udc controller = {
- .gadget = {
- .ops= &at91_udc_ops,
- .ep0= &controller.ep[0].ep,
- .name = driver_name,
- .dev= {
- .init_name = "gadget",
- .release = nop_release,
- }
- },
- .ep[0] = {
- .ep = {
- .name = ep0name,
- .ops= &at91_ep_ops,
- },
- .udc= &controller,
- .maxpacket = 8,
- .int_mask = 1 << 0,
- },
- .ep[1] = {
- .ep = {
- .name = "ep1",
- .ops= &at91_ep_ops,
- },
- .udc= &controller,
- .is_pingpong= 1,
- .maxpacket = 64,
- .int_mask = 1 << 1,
- },
- .ep[2] = {
- .ep = {
- .name = "ep2",
- .ops= &at91_ep_ops,
- },
- .udc= &controller,
- .is_pingpong= 1,
- .maxpacket = 64,
- .int_mask = 1 << 2,
- },
- .ep[3] = {
- .ep = {
- /* could actually do bulk too */
- .name = "ep3-int",
- .ops= &at91_ep_ops,
- },
- .udc= &controller,
- .maxpacket = 8,
- .int_mask = 1 << 3,
- },
- .ep[4] = {
- .ep = {
- .name = "ep4",
- .ops= &at91_ep_ops,
- },
- .udc= &controller,
- .is_pingpong= 1,
- .maxpacket = 256,
- .int_mask = 1 << 4,
- },
- .ep[5] = {
- .ep = {
- .name = "ep5",
- .ops= &at91_ep_ops,
- },
- .udc= &controller,
- .is_pingpong= 1,
- .maxpacket = 256,
- .int_mask = 1 << 5,
- },
- /* ep6 and ep7 are also reserved (custom silicon might use them) */
-};
-
static void at91_vbus_update(struct at91_udc *udc, unsigned value)
{
value ^= udc->board.vbus_active_low;
@@ -1859,15 +1795,32 @@ static int at91udc_probe(struct platform_device *pdev)
struct at91_ep *ep;
int i;
+ udc = devm_kzalloc(dev, sizeof(*udc), GFP_KERNEL);
+ if (!udc)
+ return -ENOMEM;
+
/* init software state */
- udc = &controller;
udc->gadget.dev.parent = dev;
at91udc_of_init(udc, pdev->dev.of_node);
udc->pdev = pdev;
udc->enabled = 0;
spin_lock_init(&udc->lock);
+ udc->gadget.ops = &at91_udc_ops;
+ udc->gadget.ep0 = &udc->ep[0].ep;
+ udc->gadget.name = driver_name;
+ udc->gadget.dev.init_name = "gadget";
+ udc->gadget.dev.release = nop_release;
+ for (i = 0; i < NUM_ENDPOINTS; i++) {
+ ep = &udc->ep[i];
+ ep->ep.name = ep_names[i];
+ ep->ep.ops = &at91_ep_ops;
+ ep->udc = udc;
+ ep->int_mask = BIT(i);
+ if (i != 0 && i != 3)
+ ep->is_pingpong = 1;
+ }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
udc->udp_baseaddr = devm_ioremap_resource(dev, res);
--
1.9.1
--
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 08/11] usb: gadget: at91_udc: Update DT binding documentation
Three compatible strings have been added to the at91_udc driver.
Update the documentation accordingly.
Signed-off-by: Boris Brezillon
---
Documentation/devicetree/bindings/usb/atmel-usb.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt
b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index 6007231..54a8121 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -33,7 +33,11 @@ usb1: ehci@0080 {
AT91 USB device controller
Required properties:
- - compatible: Should be "atmel,at91rm9200-udc"
+ - compatible: Should be one of the following
+ "atmel,at91rm9200-udc"
+ "atmel,at91sam9260-udc"
+ "atmel,at91sam9261-udc"
+ "atmel,at91sam9263-udc"
- reg: Address and length of the register set for the device
- interrupts: Should contain macb interrupt
- clocks: Should reference the peripheral and the AHB clocks
--
1.9.1
--
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 10/11] ARM: at91/dt: declare matrix node as a syscon device
Signed-off-by: Boris Brezillon
---
arch/arm/boot/dts/at91sam9261.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91sam9261.dtsi
b/arch/arm/boot/dts/at91sam9261.dtsi
index 7119f1f..e52ae97 100644
--- a/arch/arm/boot/dts/at91sam9261.dtsi
+++ b/arch/arm/boot/dts/at91sam9261.dtsi
@@ -257,7 +257,7 @@
};
matrix: matrix@ee00 {
- compatible = "atmel,at91sam9260-bus-matrix";
+ compatible = "atmel,at91sam9260-bus-matrix",
"syscon";
reg = <0xee00 0x200>;
};
--
1.9.1
--
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 11/11] ARM: at91/dt: fix at91 udc compatible strings
The at91rm9200, at91sam9260, at91sam9261 and at91sam9263 SoCs have slightly
different UDC IPs.
Those differences were previously handled with cpu_is_at91xx macro which
are about to be dropped for multi-platform support, thus we need to
change compatible strings.
Signed-off-by: Boris Brezillon
---
arch/arm/boot/dts/at91sam9260.dtsi | 2 +-
arch/arm/boot/dts/at91sam9261.dtsi | 3 ++-
arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi
b/arch/arm/boot/dts/at91sam9260.dtsi
index cb100b0..b43de88 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -848,7 +848,7 @@
};
usb1: gadget@fffa4000 {
- compatible = "atmel,at91rm9200-udc";
+ compatible = "atmel,at91sam9260-udc";
reg = <0xfffa4000 0x4000>;
interrupts = <10 IRQ_TYPE_LEVEL_HIGH 2>;
clocks = <&udc_clk>, <&udpck>;
diff --git a/arch/arm/boot/dts/at91sam9261.dtsi
b/arch/arm/boot/dts/at91sam9261.dtsi
index e52ae97..90f0b59 100644
--- a/arch/arm/boot/dts/at91sam9261.dtsi
+++ b/arch/arm/boot/dts/at91sam9261.dtsi
@@ -119,11 +119,12 @@
};
usb1: gadget@fffa4000 {
- compatible = "atmel,at91rm9200-udc";
+ compatible = "atmel,at91sam9261-udc";
reg = <0xfffa4000 0x4000>;
interrupts = <10 IRQ_TYPE_LEVEL_HIGH 2>;
clocks = <&udc_clk>, <&udpck>;
clock-names = "pclk", "hclk";
+ atmel,matrix = <&matrix>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi
b/arch/arm/boot/dts/at91sam9263.dtsi
index 51416c7d..2c7ed05 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -817,7 +817,7 @@
};
usb1: gadget@fff78000 {
- compatible = "atmel,at91rm9200-udc";
+ compatible = "atmel,at91sam9263-udc";
reg = <0xfff78000 0x4000>;
interrupts = <24 IRQ_TYPE_LEVEL_HIGH 2>;
clocks = <&udc_clk>, <&udpck>;
--
1.9.1
--
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 v4 2/3] i2c: add support for Cypress CYUSBS234 USB-I2C adapter
Hi,
thanks for this submission. Looks like an interesting device. However,
some very high level questions first:
> +/*
> + * It exposes sysfs entries under the i2c adapter for getting the i2c
> transfer
> + * status, reset i2c read/write module, get/set nak and stop bits.
> + */
Yes, I see that. Yet, I don't know why they are needed? The driver
should know when to send NAK/STOP. Why expose that to the user? And why
do we need a reset? Are there stability problems? What about unloading
the module? And what is the use case for reading the status?
> + if (num > 1) {
> + dev_err(&adapter->dev, "i2c_msg number is > 1\n");
> + return -EIO;
> + }
Ouch! Don't you have any repeated start option somewhere?
Thanks,
Wolfram
signature.asc
Description: Digital signature
Re: USB 3.0 drive crashes system when plugged in - regression
On Wed, 2014-12-03 at 10:41 +0100, Marcin Zajączkowski wrote: > 2014-12-03 Oliver Neukum wrote: > > On Wed, 2014-12-03 at 00:29 +0100, Marcin Zajączkowski wrote: > > > Hi, > > > > > > After upgrade to Fedora 21 with 3.17.3-300.fc21.x86_64 (from 3.14.x in > > > Fedora 19) my USB 3.0 drive (Seagate Backup+ 1TB) stopped working with > > > USB 3.0 port (works fine with USB 2.0 port). > > > > > > When plug in for the first time (USB 3.0 port) I see in log: > > > > > > > kernel: xhci_hcd :04:00.0: ERROR Transfer event for disabled > > > endpoint or incorrect stream ring > > > > kernel: xhci_hcd :04:00.0: @000241eec570 11979000 0002 > > > 0500 01078001 > > > > Are you using the UAS driver? > > Probably yes. How can check that and/or switch to not UAS driver for a test? Sysfs holds the information. I can be comfortably queried with the "usb-devices" script. To switch drivers you can use the "no UAS" quirk which can be given as a module parameter like other quirks. Regards Oliver -- 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 3.0 drive crashes system when plugged in - regression
2014-12-03 Oliver Neukum wrote: > On Wed, 2014-12-03 at 00:29 +0100, Marcin Zajączkowski wrote: > > Hi, > > > > After upgrade to Fedora 21 with 3.17.3-300.fc21.x86_64 (from 3.14.x in > > Fedora 19) my USB 3.0 drive (Seagate Backup+ 1TB) stopped working with > > USB 3.0 port (works fine with USB 2.0 port). > > > > When plug in for the first time (USB 3.0 port) I see in log: > > > > > kernel: xhci_hcd :04:00.0: ERROR Transfer event for disabled > > endpoint or incorrect stream ring > > > kernel: xhci_hcd :04:00.0: @000241eec570 11979000 0002 > > 0500 01078001 > > Are you using the UAS driver? Probably yes. How can check that and/or switch to not UAS driver for a test? Marcin -- 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 net-next] r8152: reduce memory copy for rx
Eric Dumazet [mailto:eric.duma...@gmail.com] > Sent: Wednesday, December 03, 2014 3:15 PM [...] > Have you tried using more concurrent RX flows, in a possibly lossy > environment (so that TCP is forced to queue packets in out of order > queue) ? I don't do the test. I would check it next time. > skb cloning prevents GRO and TCP coalescing from working. > > netfilter might also be forced to copy whole frame in case a mangle is > needed (eg with NAT ...) > > I would rather try to implement GRO, and/or using fragments instead of > pure linear skbs. > > (skb->head would be around 128 or 256 bytes, and you attach to skb the > frame as a page fragment) Thanks for your response. I would study the GRO first. Best Regards, Hayes -- 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
