From mboxrd@z Thu Jan  1 00:00:00 1970
From: Heiko Stuebner <heiko@sntech.de>
Date: Thu, 07 Jul 2016 22:33:54 +0200
Subject: [U-Boot] [PATCH v3 1/4] usb: rockchip-phy: implement USB2.0 phy
	control for Synopsys
In-Reply-To: <577DB74E.7040001@rock-chips.com>
References: <1467797663-16276-1-git-send-email-xzy.xu@rock-chips.com>
 <2545470.JAxZyfFHfp@phil> <577DB74E.7040001@rock-chips.com>
Message-ID: <12908616.UVeBjt7Yt7@phil>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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 <xzy.xu@rock-chips.com>
> >>>> 
> >>>> 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 <xzy.xu@rock-chips.com>
> >>>> 
> >>>> ---
> >>>> 
> >>>> 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 <common.h>
> >>>> +#include <asm/io.h>
> >>>> +
> >>>> +#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.


Heiko