On Sat, Jun 28, 2014 at 12:40 AM, Felipe Balbi <balbi@xxxxxx> wrote: > On Wed, Jun 18, 2014 at 02:15:42PM +0900, Magnus Damm wrote: >> Hi Felipe, >> >> On Fri, Jun 13, 2014 at 11:25 PM, Felipe Balbi <balbi@xxxxxx> wrote: >> > Hi, >> > >> > On Fri, Jun 13, 2014 at 09:20:31PM +0900, Yoshihiro Shimoda wrote: >> >> The R-Car H2 and M2 SoCs come with an xHCI controller that requires >> >> some specific initializations related to the firmware downloading and >> >> some specific registers. This patch adds the support for this special >> >> configuration as an xHCI quirk executed during probe and start. >> >> >> >> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@xxxxxxxxxxx> >> >> --- >> >> >> diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c >> >> new file mode 100644 >> >> index 0000000..ff0d1b4 >> >> --- /dev/null >> >> +++ b/drivers/usb/host/xhci-rcar.c >> >> @@ -0,0 +1,148 @@ >> >> +/* >> >> + * xHCI host controller driver for R-Car SoCs >> >> + * >> >> + * Copyright (C) 2014 Renesas Electronics Corporation >> >> + * >> >> + * This program is free software; you can redistribute it and/or >> >> + * modify it under the terms of the GNU General Public License >> >> + * version 2 as published by the Free Software Foundation. >> >> + */ >> >> + >> >> +#include <linux/firmware.h> >> >> +#include <linux/module.h> >> >> +#include <linux/platform_device.h> >> >> +#include <linux/usb/phy.h> >> >> + >> >> +#include "xhci.h" >> >> +#include "xhci-rcar.h" >> >> + >> >> +#define FIRMWARE_NAME "r8a779x_usb3_v1.dlmem" >> >> +MODULE_FIRMWARE(FIRMWARE_NAME); >> >> + >> >> +/*** Register Offset ***/ >> >> +#define RCAR_USB3_INT_ENA 0x224 /* Interrupt Enable */ >> >> +#define RCAR_USB3_DL_CTRL 0x250 /* FW Download Control & Status */ >> >> +#define RCAR_USB3_FW_DATA0 0x258 /* FW Data0 */ >> >> + >> >> +#define RCAR_USB3_LCLK 0xa44 /* LCLK Select */ >> >> +#define RCAR_USB3_CONF1 0xa48 /* USB3.0 Configuration1 */ >> >> +#define RCAR_USB3_CONF2 0xa5c /* USB3.0 Configuration2 */ >> >> +#define RCAR_USB3_CONF3 0xaa8 /* USB3.0 Configuration3 */ >> >> +#define RCAR_USB3_RX_POL 0xab0 /* USB3.0 RX Polarity */ >> >> +#define RCAR_USB3_TX_POL 0xab8 /* USB3.0 TX Polarity */ >> >> + >> >> +/*** Register Settings ***/ >> >> +/* Interrupt Enable */ >> >> +#define RCAR_USB3_INT_XHC_ENA 0x00000001 >> >> +#define RCAR_USB3_INT_PME_ENA 0x00000002 >> >> +#define RCAR_USB3_INT_HSE_ENA 0x00000004 >> >> +#define RCAR_USB3_INT_ENA_VAL (RCAR_USB3_INT_XHC_ENA | \ >> >> + RCAR_USB3_INT_PME_ENA | RCAR_USB3_INT_HSE_ENA) >> >> + >> >> +/* FW Download Control & Status */ >> >> +#define RCAR_USB3_DL_CTRL_ENABLE 0x00000001 >> >> +#define RCAR_USB3_DL_CTRL_FW_SUCCESS 0x00000010 >> >> +#define RCAR_USB3_DL_CTRL_FW_SET_DATA0 0x00000100 >> >> + >> >> +/* LCLK Select */ >> >> +#define RCAR_USB3_LCLK_ENA_VAL 0x01030001 >> >> + >> >> +/* USB3.0 Configuration */ >> >> +#define RCAR_USB3_CONF1_VAL 0x00030204 >> >> +#define RCAR_USB3_CONF2_VAL 0x00030300 >> >> +#define RCAR_USB3_CONF3_VAL 0x13802007 >> >> + >> >> +/* USB3.0 Polarity */ >> >> +#define RCAR_USB3_RX_POL_VAL BIT(21) >> >> +#define RCAR_USB3_TX_POL_VAL BIT(4) >> >> + >> >> +void xhci_rcar_start(struct usb_hcd *hcd) >> >> +{ >> >> + u32 temp; >> >> + >> >> + if (hcd->regs != NULL) { >> >> + /* Interrupt Enable */ >> >> + temp = readl(hcd->regs + RCAR_USB3_INT_ENA); >> >> + temp |= RCAR_USB3_INT_ENA_VAL; >> >> + writel(temp, hcd->regs + RCAR_USB3_INT_ENA); >> >> + /* LCLK Select */ >> >> + writel(RCAR_USB3_LCLK_ENA_VAL, hcd->regs + RCAR_USB3_LCLK); >> >> + /* USB3.0 Configuration */ >> >> + writel(RCAR_USB3_CONF1_VAL, hcd->regs + RCAR_USB3_CONF1); >> >> + writel(RCAR_USB3_CONF2_VAL, hcd->regs + RCAR_USB3_CONF2); >> >> + writel(RCAR_USB3_CONF3_VAL, hcd->regs + RCAR_USB3_CONF3); >> >> + /* USB3.0 Polarity */ >> >> + writel(RCAR_USB3_RX_POL_VAL, hcd->regs + RCAR_USB3_RX_POL); >> >> + writel(RCAR_USB3_TX_POL_VAL, hcd->regs + RCAR_USB3_TX_POL); >> >> + } >> >> +} >> >> + >> >> +static int xhci_rcar_download_firmware(struct device *dev, void __iomem *regs) >> >> +{ >> >> + const struct firmware *fw; >> >> + int retval, index, j, time; >> >> + int timeout = 10000; >> >> + u32 data, val, temp; >> >> + >> >> + /* request R-Car USB3.0 firmware */ >> >> + retval = request_firmware(&fw, FIRMWARE_NAME, dev); >> >> + if (retval) >> >> + return retval; >> >> + >> >> + /* download R-Car USB3.0 firmware */ >> >> + temp = readl(regs + RCAR_USB3_DL_CTRL); >> >> + temp |= RCAR_USB3_DL_CTRL_ENABLE; >> >> + writel(temp, regs + RCAR_USB3_DL_CTRL); >> >> + >> >> + for (index = 0; index < fw->size; index += 4) { >> >> + /* to avoid reading beyond the end of the buffer */ >> >> + for (data = 0, j = 3; j >= 0; j--) { >> >> + if ((j + index) < fw->size) >> >> + data |= fw->data[index + j] << (8 * j); >> >> + } >> >> + writel(data, regs + RCAR_USB3_FW_DATA0); >> >> + temp = readl(regs + RCAR_USB3_DL_CTRL); >> >> + temp |= RCAR_USB3_DL_CTRL_FW_SET_DATA0; >> >> + writel(temp, regs + RCAR_USB3_DL_CTRL); >> >> + >> >> + for (time = 0; time < timeout; time++) { >> >> + val = readl(regs + RCAR_USB3_DL_CTRL); >> >> + if ((val & RCAR_USB3_DL_CTRL_FW_SET_DATA0) == 0) >> >> + break; >> >> + udelay(1); >> >> + } >> >> + if (time == timeout) { >> >> + retval = -ETIMEDOUT; >> >> + break; >> >> + } >> >> + } >> >> + >> >> + temp = readl(regs + RCAR_USB3_DL_CTRL); >> >> + temp &= ~RCAR_USB3_DL_CTRL_ENABLE; >> >> + writel(temp, regs + RCAR_USB3_DL_CTRL); >> >> + >> >> + for (time = 0; time < timeout; time++) { >> >> + val = readl(regs + RCAR_USB3_DL_CTRL); >> >> + if (val & RCAR_USB3_DL_CTRL_FW_SUCCESS) { >> >> + retval = 0; >> >> + break; >> >> + } >> >> + udelay(1); >> >> + } >> >> + if (time == timeout) >> >> + retval = -ETIMEDOUT; >> >> + >> >> + release_firmware(fw); >> >> + >> >> + return retval; >> >> +} >> >> + >> >> +/* This function needs to initialize a "phy" of usb before */ >> > >> > initializing a PHY looks like something that the PHY layer should do. >> > Why don't you write a PHY driver and teach xhci-core about PHYs ? Then, >> > more people would benefit. >> >> Could you please clarify what you would like Shimoda-san to do? >> >> Like Ben and Shimoda-san mentioned, there is already a PHY driver >> developed for this SoC. The PHY driver is however shared in various >> ways. For example, on one particular SoC the same PHY driver is >> interfacing to a total of 3 different variants of USB controllers >> where XHCI is one of them. And to make things even more complicated, >> depending on SoC variant the XHCI hardware may or may not be available >> - but the PHY portion is more or less the same. >> >> Putting the firmware loader in the XHCI driver like this at least >> keeps it together with the rest of the XHCI stuff and also makes it >> possible to easily access the XHCI I/O register window for firmware >> loading. Moving the firmware loading to the PHY driver however >> complicates the situation when it comes to Kconfig handling of XHCI >> and PHY driver and also forces the PHY driver to access the XHCI >> hardware I/O registers for firmware loading... > > But the firmware is being loaded into the PHY registers, no ? In that > case, it should sit in the PHY driver. The firmware is not loaded into the PHY registers. It is loaded into what is considered XHCI registers by the documentation. Thanks, / magnus -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html