Re: Identifying Synopsys USB3 Controller on Baytrail Device
Hi, On Mon, Oct 31, 2016 at 12:57 AM, Felipe Balbi <felipe.ba...@linux.intel.com> wrote: > > Hi, > > Joseph Kogut <joseph.ko...@gmail.com> writes: >> Well, after comparing the kernel log from both systems, it seems that >> the device controller simply isn't being enumerated by the kernel for >> some reason. >> >> Here's the relevant section from the Android kernel: >> >> <6>[0.612857] PCI host bridge to bus :00 >> <6>[0.612869] pci_bus :00: root bus resource [bus 00-ff] >> <6>[0.612877] pci_bus :00: root bus resource [io 0x-0x006f] >> <6>[0.612885] pci_bus :00: root bus resource [io 0x0078-0x0cf7] >> <6>[0.612893] pci_bus :00: root bus resource [io 0x0d00-0x] >> <6>[0.612900] pci_bus :00: root bus resource [mem >> 0x000a-0x000b] >> <6>[0.612908] pci_bus :00: root bus resource [mem >> 0x000c-0x000d] >> <6>[0.612915] pci_bus :00: root bus resource [mem >> 0x000e-0x000f] >> <6>[0.612923] pci_bus :00: root bus resource [mem >> 0x7d01-0x7f00] >> <6>[0.612931] pci_bus :00: root bus resource [mem >> 0x8000-0x90ee] >> <6>[0.612938] pci_bus :00: root bus resource [mem >> 0xfed4-0xfed40fff] >> <7>[0.612960] pci :00:00.0: [8086:0f00] type 00 class 0x06 >> <7>[0.613276] pci :00:02.0: [8086:0f31] type 00 class 0x03 >> <7>[0.613304] pci :00:02.0: reg 10: [mem 0x9040-0x907f] >> <7>[0.613326] pci :00:02.0: reg 18: [mem 0x8000-0x8fff pref] >> <7>[0.613346] pci :00:02.0: reg 20: [io 0x1000-0x1007] >> <7>[0.613672] pci :00:03.0: [8086:0f38] type 00 class 0x048000 >> <7>[0.613696] pci :00:03.0: reg 10: [mem 0x9000-0x903f] >> <7>[0.614052] pci :00:14.0: [8086:0f35] type 00 class 0x0c0330 >> <7>[0.614087] pci :00:14.0: reg 10: [mem 0x90e0-0x90e0 64bit] >> <7>[0.614179] pci :00:14.0: PME# supported from D3hot D3cold >> <7>[0.614473] pci :00:16.0: [8086:0f37] type 00 class 0x0c0380 >> <6>[0.614488] EM:OEM1 table found, size=64 >> <6>[0.614493] OEM1 charging bit = 1 >> <7>[0.614514] pci :00:16.0: reg 10: [mem 0x9080-0x909f] >> <7>[0.614530] pci :00:16.0: reg 14: [mem 0x90e2e000-0x90e2efff] >> <7>[0.614611] pci :00:16.0: PME# supported from D0 D3hot >> <7>[0.614916] pci :00:1a.0: [8086:0f18] type 00 class 0x108000 >> <7>[0.614957] pci :00:1a.0: reg 10: [mem 0x90d0-0x90df] >> <7>[0.614979] pci :00:1a.0: reg 14: [mem 0x90c0-0x90cf] >> <7>[0.615118] pci :00:1a.0: PME# supported from D0 D3hot >> <7>[0.615416] pci :00:1f.0: [8086:0f1c] type 00 class 0x060100 >> <7>[ 0.615775] pci_bus :00: on NUMA node 0 >> >> As you can see, our device controller is recognized and enumerated in >> Android. I suppose this explains why it works there. :) >> >> Here's the relevant section from the mainline kernel: >> >> [0.636189] PCI host bridge to bus :00 >> [0.636196] pci_bus :00: root bus resource [io 0x0070-0x0077] >> [0.636201] pci_bus :00: root bus resource [io 0x-0x006f window] >> [0.636205] pci_bus :00: root bus resource [io 0x0078-0x0cf7 window] >> [0.636209] pci_bus :00: root bus resource [io 0x0d00-0x window] >> [0.636213] pci_bus :00: root bus resource [mem >> 0x000a-0x000b window] >> [0.636217] pci_bus :00: root bus resource [mem >> 0x000c-0x000d window] >> [0.636221] pci_bus :00: root bus resource [mem >> 0x000e-0x000f window] >> [0.636225] pci_bus :00: root bus resource [mem >> 0x90c0-0x90ff window] >> [0.636228] pci_bus :00: root bus resource [mem >> 0x7cf1-0x7ef0 window] >> [0.636232] pci_bus :00: root bus resource [mem >> 0x8000-0x908e window] >> [0.636236] pci_bus :00: root bus resource [mem >> 0xfed4-0xfed40fff window] >> [0.636241] pci_bus :00: root bus resource [bus 00-ff] >> [0.636258] pci :00:00.0: [8086:0f00] type 00 class 0x06 >> [0.636608] pci :00:02.0: [8086:0f31] type 00 class 0x03 >> [0.636627] pci :00:02.0: reg 0x10: [mem 0x9000-0x903f] >> [0.636644] pci :00:02.0: reg 0x18: [
Re: Identifying Synopsys USB3 Controller on Baytrail Device
Well, after comparing the kernel log from both systems, it seems that the device controller simply isn't being enumerated by the kernel for some reason. Here's the relevant section from the Android kernel: <6>[0.612857] PCI host bridge to bus :00 <6>[0.612869] pci_bus :00: root bus resource [bus 00-ff] <6>[0.612877] pci_bus :00: root bus resource [io 0x-0x006f] <6>[0.612885] pci_bus :00: root bus resource [io 0x0078-0x0cf7] <6>[0.612893] pci_bus :00: root bus resource [io 0x0d00-0x] <6>[0.612900] pci_bus :00: root bus resource [mem 0x000a-0x000b] <6>[0.612908] pci_bus :00: root bus resource [mem 0x000c-0x000d] <6>[0.612915] pci_bus :00: root bus resource [mem 0x000e-0x000f] <6>[0.612923] pci_bus :00: root bus resource [mem 0x7d01-0x7f00] <6>[0.612931] pci_bus :00: root bus resource [mem 0x8000-0x90ee] <6>[0.612938] pci_bus :00: root bus resource [mem 0xfed4-0xfed40fff] <7>[0.612960] pci :00:00.0: [8086:0f00] type 00 class 0x06 <7>[0.613276] pci :00:02.0: [8086:0f31] type 00 class 0x03 <7>[0.613304] pci :00:02.0: reg 10: [mem 0x9040-0x907f] <7>[0.613326] pci :00:02.0: reg 18: [mem 0x8000-0x8fff pref] <7>[0.613346] pci :00:02.0: reg 20: [io 0x1000-0x1007] <7>[0.613672] pci :00:03.0: [8086:0f38] type 00 class 0x048000 <7>[0.613696] pci :00:03.0: reg 10: [mem 0x9000-0x903f] <7>[0.614052] pci :00:14.0: [8086:0f35] type 00 class 0x0c0330 <7>[0.614087] pci :00:14.0: reg 10: [mem 0x90e0-0x90e0 64bit] <7>[0.614179] pci :00:14.0: PME# supported from D3hot D3cold <7>[0.614473] pci :00:16.0: [8086:0f37] type 00 class 0x0c0380 <6>[0.614488] EM:OEM1 table found, size=64 <6>[0.614493] OEM1 charging bit = 1 <7>[0.614514] pci :00:16.0: reg 10: [mem 0x9080-0x909f] <7>[0.614530] pci :00:16.0: reg 14: [mem 0x90e2e000-0x90e2efff] <7>[0.614611] pci :00:16.0: PME# supported from D0 D3hot <7>[0.614916] pci :00:1a.0: [8086:0f18] type 00 class 0x108000 <7>[0.614957] pci :00:1a.0: reg 10: [mem 0x90d0-0x90df] <7>[0.614979] pci :00:1a.0: reg 14: [mem 0x90c0-0x90cf] <7>[0.615118] pci :00:1a.0: PME# supported from D0 D3hot <7>[0.615416] pci :00:1f.0: [8086:0f1c] type 00 class 0x060100 <7>[ 0.615775] pci_bus :00: on NUMA node 0 As you can see, our device controller is recognized and enumerated in Android. I suppose this explains why it works there. :) Here's the relevant section from the mainline kernel: [0.636189] PCI host bridge to bus :00 [0.636196] pci_bus :00: root bus resource [io 0x0070-0x0077] [0.636201] pci_bus :00: root bus resource [io 0x-0x006f window] [0.636205] pci_bus :00: root bus resource [io 0x0078-0x0cf7 window] [0.636209] pci_bus :00: root bus resource [io 0x0d00-0x window] [0.636213] pci_bus :00: root bus resource [mem 0x000a-0x000b window] [0.636217] pci_bus :00: root bus resource [mem 0x000c-0x000d window] [0.636221] pci_bus :00: root bus resource [mem 0x000e-0x000f window] [0.636225] pci_bus :00: root bus resource [mem 0x90c0-0x90ff window] [0.636228] pci_bus :00: root bus resource [mem 0x7cf1-0x7ef0 window] [0.636232] pci_bus :00: root bus resource [mem 0x8000-0x908e window] [0.636236] pci_bus :00: root bus resource [mem 0xfed4-0xfed40fff window] [0.636241] pci_bus :00: root bus resource [bus 00-ff] [0.636258] pci :00:00.0: [8086:0f00] type 00 class 0x06 [0.636608] pci :00:02.0: [8086:0f31] type 00 class 0x03 [0.636627] pci :00:02.0: reg 0x10: [mem 0x9000-0x903f] [0.636644] pci :00:02.0: reg 0x18: [mem 0x8000-0x8fff pref] [0.636659] pci :00:02.0: reg 0x20: [io 0x1000-0x1007] [0.637019] pci :00:14.0: [8086:0f35] type 00 class 0x0c0330 [0.637045] pci :00:14.0: reg 0x10: [mem 0x9080-0x9080 64bit] [0.637128] pci :00:14.0: PME# supported from D3hot D3cold [0.637451] pci :00:1a.0: [8086:0f18] type 00 class 0x108000 [0.637477] pci :00:1a.0: reg 0x10: [mem 0x9070-0x907f] [0.637491] pci :00:1a.0: reg 0x14: [mem 0x9060-0x906f] [0.637596] pci :00:1a.0: PME# supported from D0 D3hot [0.637915] pci :00:1f.0: [8086:0f1c] type 00 class 0x060100 [0.638290] pci_bus :00: on NUMA node 0 Here are the complete logs for both systems: Mainline: https://gist.githubusercontent.com/jakogut/f726178f480b5daa1a917e3e41b46d9f/raw/80b0c273ec6a0b434c1ab0f9493283bbd0ab1635/dmesg.log Android: https://gist.githubusercontent.com/jakogut/a0f77161ea3ae886bf31e2ca6c1c33a5/raw/2a2c4b6f9a5f11be15938f58161b77d730874c6d/dmesg.log I modified the _STA method
Re: Identifying Synopsys USB3 Controller on Baytrail Device
Hi Felipe, That's some great information, thanks! At first glance, the DSDT table has two interesting bits. (I would paste the decompiled source, but I think it may be copyrighted? Correct me if I'm wrong.) The first is the USB mux, an SMSC USB3750 connected to I2C1. According to the datasheet, this IC supports switching the USB data lanes between functions. This looks promising. The second interesting bit is a device named "OTG1". The _STA method of OTG1 checks the value of OTGM--defined earlier as an 8-bit field in GNVS (NVRAM?)--and returns 0xF if it's not equal to zero, otherwise it returns zero. I'm guessing this is the host controller, based on the device name, "Baytrail XHCI controller (Synopsys core/OTG)". There's a field called OTGD in the power management capability registers opregion, but it's not referenced anywhere else. There doesn't appear to be anything else related to the device controller. The only OS interface string check appears to be in the configuration of the PCI bus, and it only checks against various versions of Windows. I'm thinking my next step is to boot into Android and dump the DSDT table, and see if it's the same. I'm betting it's not. -- 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: Identifying Synopsys USB3 Controller on Baytrail Device
Hi David, I know this is a pretty old thread. I tried searching for the LKML etiquette on something like this and came up empty. If I should start a new thread, let me know. After what I learned from the last thread, I dropped the idea of using the device controller from the Dell tablet I had. A few months later, I learned that some overseas electronics companies are now making dual-boot tablets, that support both Android and generic x86 operating systems through an IA32 UEFI firmware. I did some research on the devices, and found that they support interaction over USB with the Android tools ADB and fastboot, which indicated to me that they likely had a working USB device controller. With my curiosity piqued, I acquired one. My testing confirmed that the installed Android OS had the capability of utilizing both the host and device controllers, and allowed file transfer over MTP, as well as USB networking. After discovering that much of the kernel code supporting Baytrail had yet to be mainlined, I shelved the device for a few months. In the last few days, I've revisited the tablet, and replaced the second OS that came on it with a Linux distribution running the mainline kernel, compiled with DWC3 and OTG support. After booting the tablet and attempting to load a gadget module, I had a bout of deja vu. The device controller doesn't appear in the list of PCI devices. When attempting to load a gadget module, the kernel log reports: > udc-core: couldn't find an available UDC After reviewing this thread, I confirmed that the device id 8086:0f37 does not appear in the output of 'lspci -nn', but 8086:0f35 does. The dual-boot capability of the device seems to be implemented by switching between two distinct firmwares, but I can't be sure. If that is the case, I'm wondering if the PC compatible firmware just doesn't expose the device controller for some reason. Alternatively, like Felipe mentioned, I wonder if there's not a muxer between the phy and device/host controllers that needs to be configured somehow. Do you have any light to shed on this? Best, Joseph -- 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: dwc3: Moved PCI IDS to linux/pci_ids.h
It seems that the Synopsys vendor ID is used in usb/dwc2 as well, and the rest of the definitions aren't referenced outside of usb/dwc3. Would the proper approach be to move the Synopsys vendor ID to linux/pci_ids.h, remove the redefinition in usb/dwc2, and remove the fixme? -- 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] usb: move definition of PCI_VENDOR_ID_SYNOPSYS to linux/pci_ids.h
Signed-off-by: Joseph Kogut joseph.ko...@gmail.com --- drivers/usb/dwc2/pci.c | 1 - drivers/usb/dwc3/dwc3-pci.c | 2 -- include/linux/pci_ids.h | 2 ++ 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c index a4e724b..6646adb 100644 --- a/drivers/usb/dwc2/pci.c +++ b/drivers/usb/dwc2/pci.c @@ -54,7 +54,6 @@ #include core.h #include hcd.h -#define PCI_VENDOR_ID_SYNOPSYS 0x16c3 #define PCI_PRODUCT_ID_HAPS_HSOTG 0xabc0 static const char dwc2_driver_name[] = dwc2; diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c index 8d95056..b773fb5 100644 --- a/drivers/usb/dwc3/dwc3-pci.c +++ b/drivers/usb/dwc3/dwc3-pci.c @@ -24,8 +24,6 @@ #include platform_data.h -/* FIXME define these in linux/pci_ids.h */ -#define PCI_VENDOR_ID_SYNOPSYS 0x16c3 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd #define PCI_DEVICE_ID_INTEL_BYT0x0f37 #define PCI_DEVICE_ID_INTEL_MRFLD 0x119e diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index e63c02a..38cff8f 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -2315,6 +2315,8 @@ #define PCI_VENDOR_ID_CENATEK 0x16CA #define PCI_DEVICE_ID_CENATEK_IDE 0x0001 +#define PCI_VENDOR_ID_SYNOPSYS 0x16c3 + #define PCI_VENDOR_ID_VITESSE 0x1725 #define PCI_DEVICE_ID_VITESSE_VSC7174 0x7174 -- 2.3.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
[PATCH v2] usb: move definition of PCI_VENDOR_ID_SYNOPSYS to linux/pci_ids.h
Removed FIXME from usb/dwc3/dwc3-pci.c by moving definition of PCI_VENDOR_ID_SYNOPSYS shared with usb/dwc2 to linux/pci_ids.h. Signed-off-by: Joseph Kogut joseph.ko...@gmail.com --- drivers/usb/dwc2/pci.c | 1 - drivers/usb/dwc3/dwc3-pci.c | 2 -- include/linux/pci_ids.h | 2 ++ 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c index a4e724b..6646adb 100644 --- a/drivers/usb/dwc2/pci.c +++ b/drivers/usb/dwc2/pci.c @@ -54,7 +54,6 @@ #include core.h #include hcd.h -#define PCI_VENDOR_ID_SYNOPSYS 0x16c3 #define PCI_PRODUCT_ID_HAPS_HSOTG 0xabc0 static const char dwc2_driver_name[] = dwc2; diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c index 8d95056..b773fb5 100644 --- a/drivers/usb/dwc3/dwc3-pci.c +++ b/drivers/usb/dwc3/dwc3-pci.c @@ -24,8 +24,6 @@ #include platform_data.h -/* FIXME define these in linux/pci_ids.h */ -#define PCI_VENDOR_ID_SYNOPSYS 0x16c3 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd #define PCI_DEVICE_ID_INTEL_BYT0x0f37 #define PCI_DEVICE_ID_INTEL_MRFLD 0x119e diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index e63c02a..38cff8f 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -2315,6 +2315,8 @@ #define PCI_VENDOR_ID_CENATEK 0x16CA #define PCI_DEVICE_ID_CENATEK_IDE 0x0001 +#define PCI_VENDOR_ID_SYNOPSYS 0x16c3 + #define PCI_VENDOR_ID_VITESSE 0x1725 #define PCI_DEVICE_ID_VITESSE_VSC7174 0x7174 -- 2.3.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] usb: move definition of PCI_VENDOR_ID_SYNOPSYS to linux/pci_ids.h
On Mon, 2015-02-16 at 17:57 -0800, Greg KH wrote: On Mon, Feb 16, 2015 at 06:45:53PM -0700, Joseph Kogut wrote: Signed-off-by: Joseph Kogut joseph.ko...@gmail.com You need a changelog description here please. Should I reply inline, or is resending the patch okay? -- 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] usb: dwc3: Moved PCI IDS to linux/pci_ids.h
Moved DWC3 PCI IDS to linux/pci_ids.h per the FIXME.
Signed-off-by: Joseph Kogut joseph.ko...@gmail.com
---
drivers/usb/dwc3/dwc3-pci.c | 10 +-
include/linux/pci_ids.h | 8
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 8d95056..19ca7f6 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -20,19 +20,11 @@
#include linux/module.h
#include linux/slab.h
#include linux/pci.h
+#include linux/pci_ids.h
#include linux/platform_device.h
#include platform_data.h
-/* FIXME define these in linux/pci_ids.h */
-#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
-#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
-#define PCI_DEVICE_ID_INTEL_BYT0x0f37
-#define PCI_DEVICE_ID_INTEL_MRFLD 0x119e
-#define PCI_DEVICE_ID_INTEL_BSW0x22B7
-#define PCI_DEVICE_ID_INTEL_SPTLP 0x9d30
-#define PCI_DEVICE_ID_INTEL_SPTH 0xa130
-
static int dwc3_pci_quirks(struct pci_dev *pdev)
{
if (pdev-vendor == PCI_VENDOR_ID_AMD
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index e63c02a..6fc5cdd 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2312,6 +2312,9 @@
#define PCI_VENDOR_ID_NETCELL 0x169c
#define PCI_DEVICE_ID_REVOLUTION 0x0044
+#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
+#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
+
#define PCI_VENDOR_ID_CENATEK 0x16CA
#define PCI_DEVICE_ID_CENATEK_IDE 0x0001
@@ -2566,12 +2569,14 @@
#define PCI_DEVICE_ID_INTEL_QUARK_X1000_ILB0x095E
#define PCI_DEVICE_ID_INTEL_I960 0x0960
#define PCI_DEVICE_ID_INTEL_I960RM 0x0962
+#define PCI_DEVICE_ID_INTEL_BYT0x0f37
#define PCI_DEVICE_ID_INTEL_CENTERTON_ILB 0x0c60
#define PCI_DEVICE_ID_INTEL_8257X_SOL 0x1062
#define PCI_DEVICE_ID_INTEL_82573E_SOL 0x1085
#define PCI_DEVICE_ID_INTEL_82573L_SOL 0x108F
#define PCI_DEVICE_ID_INTEL_82815_MC 0x1130
#define PCI_DEVICE_ID_INTEL_82815_CGC 0x1132
+#define PCI_DEVICE_ID_INTEL_MRFLD 0x119e
#define PCI_DEVICE_ID_INTEL_82092AA_0 0x1221
#define PCI_DEVICE_ID_INTEL_7505_0 0x2550
#define PCI_DEVICE_ID_INTEL_7205_0 0x255d
@@ -2593,6 +2598,7 @@
#define PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI 0x1e31
#define PCI_DEVICE_ID_INTEL_PANTHERPOINT_LPC_MIN 0x1e40
#define PCI_DEVICE_ID_INTEL_PANTHERPOINT_LPC_MAX 0x1e5f
+#define PCI_DEVICE_ID_INTEL_BSW0x22B7
#define PCI_DEVICE_ID_INTEL_DH89XXCC_LPC_MIN 0x2310
#define PCI_DEVICE_ID_INTEL_DH89XXCC_LPC_MAX 0x231f
#define PCI_DEVICE_ID_INTEL_82801AA_0 0x2410
@@ -2891,6 +2897,8 @@
#define PCI_DEVICE_ID_INTEL_84460GX0x84ea
#define PCI_DEVICE_ID_INTEL_IXP4XX 0x8500
#define PCI_DEVICE_ID_INTEL_IXP28000x9004
+#define PCI_DEVICE_ID_INTEL_SPTLP 0x9d30
+#define PCI_DEVICE_ID_INTEL_SPTH 0xa130
#define PCI_DEVICE_ID_INTEL_S21152BB 0xb152
#define PCI_VENDOR_ID_SCALEMP 0x8686
--
2.3.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: Identifying Synopsys USB3 Controller on Baytrail Device
Why they use uAB connector I can only assume is because of the smaller size then standard-A, and because they are not interested in standards. That actually sounds remarkably characteristic of Microsoft. So 0f35 is indeed is the xHCI host controller. Baytrail boards that have the device controller have second USB controller with device id 0f37. Any idea if the device controller is wholly absent, or simply not connected/enumerated? On Tue, Feb 10, 2015 at 1:39 AM, Heikki Krogerus heikki.kroge...@linux.intel.com wrote: Hi Joseph, On Mon, Feb 09, 2015 at 10:27:53AM -0600, Felipe Balbi wrote: On Sun, Feb 08, 2015 at 02:51:16PM -0700, Joseph Kogut wrote: I have an Intel Valleyview/Baytrail based device (specifically a Dell Venue 8 Pro 5830) that I'd like to be able to use the Linux Gadget subsystem on, but it seems that the controller isn't currently supported. I'm running the 3.19rc7 mainline release. The device has a micro AB connector. Based on my experiences with a similar (Merrifield) platform using Intel's own out of tree patchset that had working DRD support using a modified DWC3 driver, I suspected that the Baytrail platform I'm working on would also use the DWC3 driver. Unfortunately Dell Venue 8 Pro 5000 Series tablets do not have USB device controller. You only have the xHCI host controller. In fact, this is the case with basically all new Windows tablets. Microsoft is simply not interested in USB device mode. Why they use uAB connector I can only assume is because of the smaller size then standard-A, and because they are not interested in standards. The output of lspci -nn shows: 00:14.0 USB controller [0c03]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series USB xHCI [8086:0f35] (rev 09) So 0f35 is indeed is the xHCI host controller. Baytrail boards that have the device controller have second USB controller with device id 0f37. Br, -- heikki -- 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: Identifying Synopsys USB3 Controller on Baytrail Device
Sorry, David, I'm using Gmail, and still new to the LKML. I guess it hid the part that was quoted, I'll have to figure out how to turn that off. Thanks for the information! -- 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
