Hi,
On 07-06-18 15:28, Andy Shevchenko wrote:
On Thu, Jun 7, 2018 at 1:38 PM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
Bay Trail / BYT SoCs do not have a builtin device-mode phy, instead
they require an external ULPI phy for device-mode.
Only some BYT devices have an external phy, but even on those devices
device-mode is not working because the dwc3 does not see the phy.
The problem is that the ACPI fwnode for the dwc3 does not contain the
expected GPIO resources for the GPIOs connected to the chip-select and
reset pins of the phy.
I've found the workaround which some Android x86 kernels use for this:
https://github.com/BORETS24/Kernel-for-Asus-Zenfone-2/blob/master/arch/x86/platform/intel-mid/device_libs/pci/platform_usb_otg.c
Which boils down to hardcoding the GPIOs for these devices.
This commit adds a gpiod_lookup_table adding the mappings from Android,
and installs this table on BYT system with their BIOS vendor DMI string
set to "INSYDE Corp.". This seems to indicate that a (mostly) unmodified
version of the reference design BIOS is used. 3 out of the 20 BYT tablets
which I have for testing have an external ULPI phy and all 3 models use
this vendor string.
+ vendor = dmi_get_system_info(DMI_BIOS_VENDOR);
+ if (vendor && strcmp(vendor, "INSYDE Corp.") == 0) {
+ gpiod_add_lookup_table(&platform_bytcr_gpios);
+ dwc->gpio_mapping_added = true;
+ }
I understand that my proposal might sound a bit overkill, though, I
would rather go with normal dmi tables and call back there.
I was actually thinking about maybe going the other direction and
dropping the DMI check all together if it turns out to be too
narrow. If you look at:
https://github.com/BORETS24/Kernel-for-Asus-Zenfone-2/blob/master/arch/x86/platform/intel-mid/device_libs/pci/platform_usb_otg.c
Then all models that code knows except for the 1st gen
development board (Bay Lake CRB/RVP FAB 1) use these gpios.
And *all* FFRDs (Form Factor Reference Designs) use these pins.
Note that the gpiolib code used the lookup table as a fallback,
so if there are proper ACPI GPIO resources in the resource table
those will be used.
So having a hardcoded fallback to the GPIO pins which all
FFRDs use seems reasonable.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
