From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ziyuan Xu Date: Fri, 08 Jul 2016 08:40:45 +0800 Subject: [U-Boot] [PATCH v3 1/4] usb: rockchip-phy: implement USB2.0 phy control for Synopsys In-Reply-To: <12908616.UVeBjt7Yt7@phil> References: <1467797663-16276-1-git-send-email-xzy.xu@rock-chips.com> <2545470.JAxZyfFHfp@phil> <577DB74E.7040001@rock-chips.com> <12908616.UVeBjt7Yt7@phil> Message-ID: <577EF68D.3010307@rock-chips.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 2016?07?08? 04:33, Heiko Stuebner wrote: > Am Donnerstag, 7. Juli 2016, 09:58:38 schrieb Ziyuan Xu: >> On 2016?07?06? 21:42, Heiko Stuebner wrote: >>> Am Mittwoch, 6. Juli 2016, 14:48:57 schrieb Heiko Stuebner: >>>> Am Mittwoch, 6. Juli 2016, 18:20:04 schrieb Ziyuan Xu: >>>>> Hi heiko, >>>>> >>>>> On 2016?07?06? 17:34, Ziyuan Xu wrote: >>>>>> From: Xu Ziyuan >>>>>> >>>>>> So far, Rockchip SoCs have two kinds of USB2.0 phy, like Synopsys and >>>>>> Innosilicon. This patch applys dwc2 usb driver framework to implement >>>>>> phy_init and phy_off for Synopsys phy on Rockchip platform. >>>>>> >>>>>> Signed-off-by: Ziyuan Xu >>>>>> >>>>>> --- >>>>>> >>>>>> Changes in v3: >>>>>> - Make UOC_CON registers to be unfixed which should be got from DT >>>>>> >>>>>> Changes in v2: >>>>>> - Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c >>>>>> - Rework the behaviour in otg_phy_init() and otg_phy_off() >>>>>> >>>>>> drivers/usb/phy/Makefile | 1 + >>>>>> drivers/usb/phy/rockchip_usb_syno_phy.c | 47 >>>>>> +++++++++++++++++++++++++++++++++ 2 files changed, 48 >>>>>> insertions(+) >>>>>> create mode 100644 drivers/usb/phy/rockchip_usb_syno_phy.c >>>>>> >>>>>> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile >>>>>> index 93d147e..8002a18 100644 >>>>>> --- a/drivers/usb/phy/Makefile >>>>>> +++ b/drivers/usb/phy/Makefile >>>>>> @@ -7,3 +7,4 @@ >>>>>> >>>>>> obj-$(CONFIG_TWL4030_USB) += twl4030.o >>>>>> obj-$(CONFIG_OMAP_USB_PHY) += omap_usb_phy.o >>>>>> >>>>>> +obj-$(CONFIG_ROCKCHIP_USB_SYNO_PHY) += rockchip_usb_syno_phy.o >>>>>> diff --git a/drivers/usb/phy/rockchip_usb_syno_phy.c >>>>>> b/drivers/usb/phy/rockchip_usb_syno_phy.c new file mode 100644 >>>>>> index 0000000..ab049e1 >>>>>> --- /dev/null >>>>>> +++ b/drivers/usb/phy/rockchip_usb_syno_phy.c >>>>>> @@ -0,0 +1,47 @@ >>>>>> +/* >>>>>> + * Copyright 2016 Rockchip Electronics Co., Ltd >>>>>> + * >>>>>> + * SPDX-License-Identifier: GPL-2.0+ >>>>>> + */ >>>>>> + >>>>>> +#include >>>>>> +#include >>>>>> + >>>>>> +#include "../gadget/dwc2_udc_otg_priv.h" >>>>>> + >>>>>> +#define UOC_CON(x) ((x) * 0x4) >>>>> As you know, dwc2 usb driver didn't apply devicetree model. It's hard >>>>> to >>>>> implement a compatible driver for Rockchip SoCs which use a same udc. >>>> Yeah, it is pretty strange that the dwc2 host part in uboot uses the >>>> devicetree while the gadget part does not - but I maybe someone else >>>> can >>>> answer this, as my contact with uboot was limited until now. >>>> The dwc2 host driver works just fine on my rk3036 kylin board. >>>> >>>>> For example, >>>>> SOFT_CTRL bit is UOC_CON2[2] on RK3288 >>>>> I can't assure it's also UOC_CON[2] on other socs. >>>>> Do you have any good ideas? >>>> Operating under the current constraints, I guess you could simply do >>>> something similar to what socfpga does in its board file. >> socfpga? Could you please indicate which project and file? I can't find >> out it. >> >>>> Aka get the usb controller node, read the phy phandle and get the phy >>>> compatible string from the dts. The usbphys each have per-soc >>>> compatible >>>> values "rockchip,rk3288-usbphy" etc, so you can determine the needed >>>> bits >>>> over that. >> In patchset [v3.3/4](http://patchwork.ozlabs.org/patch/645188/), I had >> get usb-phy offset from grf. >> If I understand it correctly, you mean that implement a struct in driver >> to match compatible and platdata. Then define any properties in >> platdata, contains of some bits which will be used. Something similar >> to https://patchwork.kernel.org/patch/9190287/? > yep, you just need to find some mechanism to identify the soc you're running > on so that the phy part can access the right registers on each one. Thanks for your opinion, I will do it. > > Heiko > > >