Message ID | 1463606653-325131-1-git-send-email-arnd@arndb.de |
---|---|
Headers | show |
Series | usb: phy: msm: various cleanups | expand |
On 18 May 2016 at 16:24, Arnd Bergmann <arnd@arndb.de> wrote: <snip> > +/* > + * This abstracts the TCSR register area in Qualcomm SoCs, originally > + * introduced by Tim Bird as part of the phy-msm-usb.ko device driver, > + * and split out by Arnd Bergmann into a separate file. > + * > + * This file shouldn't really exist, since we have no way to detect > + * if the TCSR actually exists in the hardcoded location, or if it > + * is compatible with the version that was originally used. > + * > + * If the assumptions ever change, we have to come up with a better > + * solution. > + */ > +#include <linux/module.h> > +#include <linux/io.h> > + > +/* USB phy selector - in TCSR address range */ > +#define USB2_PHY_SEL 0xfd4ab000 > + > +/* > + * qcom_tcsr_phy_sel -- Select secondary PHY via TCSR > + * > + * Select the secondary PHY using the TCSR register, if phy-num=1 > + * in the DTS (or phy_number is set in the platform data). The > + * SOC has 2 PHYs which can be used with the OTG port, and this > + * code allows configuring the correct one. > + * > + * Note: This resolves the problem I was seeing where I couldn't > + * get the USB driver working at all on a dragonboard, from cold > + * boot. This patch depends on patch 5/14 from Ivan's msm USB > + * patch set. It does not use DT for the register address, as > + * there's no evidence that this address changes between SoC > + * versions. > + * - Tim > + */ > +int qcom_tcsr_phy_sel(u32 val) > +{ > + void __iomem *phy_select; > + int ret; > + > + phy_select = ioremap(USB2_PHY_SEL, 4); > + > + if (!phy_select) { > + ret = -ENOMEM; > + goto out; > + } > + /* Enable second PHY with the OTG port */ > + writel(0x1, phy_select); > + ret = 0; > +out: > + iounmap(phy_select); > + return ret; > +} > +EXPORT_SYMBOL_GPL(qcom_tcsr_phy_sel); I'd rather do something like what we did for the GSBI. It needed to change some phy related bits in the TCSR as well. We defined the TCSR as a syscon, with binding documentation under mfd. If we add a syscon entry and use it if it is present, we can deal with that pretty easily. The offsets change for each soc, and this would also fix that issue because we can change offset based on tcsr compat. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 20, 2016 at 02:24:14PM +0200, Arnd Bergmann wrote: > On Thursday 19 May 2016 14:08:43 Andy Gross wrote: > > I'd rather do something like what we did for the GSBI. It needed to > > change some phy related bits in the TCSR as well. We defined the TCSR > > as a syscon, with binding documentation under mfd. If we add a syscon > > entry and use it if it is present, we can deal with that pretty > > easily. The offsets change for each soc, and this would also fix that > > issue because we can change offset based on tcsr compat. > Works for me, but be aware that this will break the server chips, > as ACPI has no support for regmap devices. Just to be clear there's nothing precluding the use of regmap on ACPI devices, it's syscon it doesn't have anything for.