From patchwork Sun Jun 10 14:01:20 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 10456653 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id BEDF360467 for ; Sun, 10 Jun 2018 14:01:29 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9E18626CFF for ; Sun, 10 Jun 2018 14:01:29 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8E7D526E49; Sun, 10 Jun 2018 14:01:29 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 604DD26CFF for ; Sun, 10 Jun 2018 14:01:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753714AbeFJOB0 (ORCPT ); Sun, 10 Jun 2018 10:01:26 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:54512 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751855AbeFJOBZ (ORCPT ); Sun, 10 Jun 2018 10:01:25 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D0880859A2; Sun, 10 Jun 2018 14:01:24 +0000 (UTC) Received: from shalem.localdomain.com (ovpn-116-84.ams2.redhat.com [10.36.116.84]) by smtp.corp.redhat.com (Postfix) with ESMTP id F079A6401F; Sun, 10 Jun 2018 14:01:23 +0000 (UTC) From: Hans de Goede To: Felipe Balbi , Greg Kroah-Hartman Cc: Hans de Goede , Andy Shevchenko , linux-usb@vger.kernel.org Subject: [PATCH v3 1/3] usb: dwc3: pci: Add GPIO lookup table on platforms without ACPI GPIO resources Date: Sun, 10 Jun 2018 16:01:20 +0200 Message-Id: <20180610140122.25510-1-hdegoede@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Sun, 10 Jun 2018 14:01:24 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Sun, 10 Jun 2018 14:01:24 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hdegoede@redhat.com' RCPT:'' Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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. The good news it that all boards (*) use the same GPIOs. This commit fixes the ULPI phy not woring by adding a gpiod_lookup_table call which adds a hardcoded mapping for BYT devices. Note that the mapping added by gpiod_add_lookup_table is a fallback mapping, so boards which properly provide GPIO resources in the ACPI firmware-node resources will not use this. *) Except for the first revision of the evalulation-kit, which normal users don't have Signed-off-by: Hans de Goede --- Changes in v3: -Add the mapping with gpiod_add_lookup_table() unconditionally on BYT devices, as they are only used after checking for GPIO resources in ACPI --- drivers/usb/dwc3/dwc3-pci.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c index c961a94d136b..c58f87b01ac7 100644 --- a/drivers/usb/dwc3/dwc3-pci.c +++ b/drivers/usb/dwc3/dwc3-pci.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include @@ -66,6 +67,15 @@ static const struct acpi_gpio_mapping acpi_dwc3_byt_gpios[] = { { }, }; +static struct gpiod_lookup_table platform_bytcr_gpios = { + .dev_id = "0000:00:16.0", + .table = { + GPIO_LOOKUP("INT33FC:00", 54, "reset", GPIO_ACTIVE_HIGH), + GPIO_LOOKUP("INT33FC:02", 14, "cs", GPIO_ACTIVE_HIGH), + {} + }, +}; + static int dwc3_pci_quirks(struct dwc3_pci *dwc) { struct platform_device *dwc3 = dwc->dwc3; @@ -126,6 +136,13 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc) if (ret) dev_dbg(&pdev->dev, "failed to add mapping table\n"); + /* + * A lot of BYT devices lack ACPI resource entries for + * the GPIOs, add a fallback mapping to the reference + * design GPIOs which all boards seem to use. + */ + gpiod_add_lookup_table(&platform_bytcr_gpios); + /* * These GPIOs will turn on the USB2 PHY. Note that we have to * put the gpio descriptors again here because the phy driver @@ -256,6 +273,7 @@ static void dwc3_pci_remove(struct pci_dev *pci) { struct dwc3_pci *dwc = pci_get_drvdata(pci); + gpiod_remove_lookup_table(&platform_bytcr_gpios); #ifdef CONFIG_PM cancel_work_sync(&dwc->wakeup_work); #endif