From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: [2/4] usb: dwc3: add dwc3 glue layer for UniPhier SoCs From: Felipe Balbi Message-Id: <87a7x3l8gr.fsf@linux.intel.com> Date: Wed, 24 Jan 2018 14:58:12 +0200 To: Kunihiko Hayashi Cc: linux-usb@vger.kernel.org, Greg Kroah-Hartman , Masahiro Yamada , Rob Herring , Mark Rutland , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Jassi Brar , Masami Hiramatsu , Kishon Vijay Abraham I List-ID: SGksCgpLdW5paGlrbyBIYXlhc2hpIDxoYXlhc2hpLmt1bmloaWtvQHNvY2lvbmV4dC5jb20+IHdy aXRlczoKPiBIZWxsbyBGZWxpcGUsCj4KPiBUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuCj4K PiBPbiBUdWUsIDIzIEphbiAyMDE4IDE1OjEyOjM2ICswMjAwIDxiYWxiaUBrZXJuZWwub3JnPiB3 cm90ZToKPgo+PiAKPj4gSGksCj4+IAo+PiBLdW5paGlrbyBIYXlhc2hpIDxoYXlhc2hpLmt1bmlo aWtvQHNvY2lvbmV4dC5jb20+IHdyaXRlczoKPj4gPiBBZGQgYSBzcGVjaWZpYyBnbHVlIGxheWVy IGZvciBVbmlQaGllciBTb0MgcGxhdGZvcm0gdG8gc3VwcG9ydAo+PiA+IFVTQiBob3N0IG1vZGUu IEl0IG1hbmFnZXMgaGFyZHdhcmUgb3BlcmF0aW5nIHNlcXVlbmNlcyB0byBlbmFibGUgbXVsdGlw bGUKPj4gPiBjbG9jayBnYXRlcyBhbmQgYXNzZXJ0IHJlc2V0cywgYW5kIHRvIHByZXBhcmUgdG8g dXNlIGR3YzMgY29udHJvbGxlcgo+PiA+IG9uIHRoZSBTb0MuCj4+ID4KPj4gPiBUaGlzIHBhdGNo IGFsc28gaGFuZGxlcyB0aGUgcGh5c2ljYWwgbGF5ZXIgdGhhdCBoYXMgc2FtZSByZWdpc3RlciBz cGFjZQo+PiA+IGFzIHRoZSBnbHVlIGxheWVyLCBiZWNhdXNlIGl0IG5lZWRzIHRvIGludGVncmF0 ZSBpbml0aWFsemlhdGlvbiBzZXF1ZW5jZQo+PiA+IGJldHdlZW4gZ2x1ZSBhbmQgcGh5Lgo+PiA+ Cj4+ID4gSW4gY2FzZSBvZiBzb21lIFNvQ3MsIHNpbmNlIHNvbWUgaW5pdGlhbGl6YXRpb24gdmFs dWVzIGZvciBQSFkgYXJlCj4+ID4gaW5jbHVkZWQgaW4gbnZtZW0sIHRoaXMgcGF0Y2ggaW5jbHVk ZXMgdGhlIHdheSB0byBnZXQgdGhlIHZhbHVlcyBmcm9tIG52bWVtLgo+PiA+Cj4+ID4gSXQgc3Vw cG9ydHMgUFhzMiBhbmQgTEQyMCBTb0NzLgo+PiA+Cj4+ID4gU2lnbmVkLW9mZi1ieTogS3VuaWhp a28gSGF5YXNoaSA8aGF5YXNoaS5rdW5paGlrb0Bzb2Npb25leHQuY29tPgo+PiA+IFNpZ25lZC1v ZmYtYnk6IE1vdG95YSBUYW5pZ2F3YSA8dGFuaWdhd2EubW90b3lhQHNvY2lvbmV4dC5jb20+Cj4+ ID4gU2lnbmVkLW9mZi1ieTogTWFzYW1pIEhpcmFtYXRzdSA8bWFzYW1pLmhpcmFtYXRzdUBsaW5h cm8ub3JnPgo+PiA+IC0tLQo+PiA+ICBkcml2ZXJzL3VzYi9kd2MzL0tjb25maWcgICAgICAgICB8 ICAgOSArCj4+ID4gIGRyaXZlcnMvdXNiL2R3YzMvTWFrZWZpbGUgICAgICAgIHwgICAxICsKPj4g PiAgZHJpdmVycy91c2IvZHdjMy9kd2MzLXVuaXBoaWVyLmMgfCA1NTQgKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrCj4+ID4gIDMgZmlsZXMgY2hhbmdlZCwgNTY0IGluc2Vy dGlvbnMoKykKPj4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMvdXNiL2R3YzMvZHdjMy11 bmlwaGllci5jCj4KPiAuLi5zbmlwLi4uCj4KPj4gPiArCj4+ID4gK3N0YXRpYyB2b2lkIGR3YzN1 X3NzcGh5X3Rlc3Rpb193cml0ZShzdHJ1Y3QgZHdjM3VfcHJpdiAqcHJpdiwgaW50IHBvcnQsCj4+ ID4gKwkJCQkgICAgIHUzMiBkYXRhKQo+PiAKPj4gYW55dGhpbmcgd2l0aCBzc2hwaHkgb3IgaHNw aHkgaW4gdGhlIG5hbWUgc2hvdWxkIHByb2JhYmx5IGJlIHBhcnQgb2YgYQo+PiBQSFkgZHJpdmVy IHVzaW5nIGRyaXZlcnMvcGh5LyBmcmFtZXdvcmsuCj4KPiBJIGNhbiB0cnkgdG8gc2VwYXJhdGUg cGh5IGNvbnRyb2wgZnJvbSB0aGlzIGRyaXZlci4KPiBIb3dldmVyLCBwaHkgcmVnaXN0ZXJzIGJl bG9uZ3MgdG8gImR3YzMtZ2x1ZSIgSU8gbWFwIGFyZWEgKDY1YjAwMDAwKSwKPiBhbmQgdGhpcyBh cmVhIGFsc28gY29udGFpbnMgYSByZXNldCBiaXQgZm9yICJkd2MzLWNvcmUiIGhhcmR3YXJlLgo+ Cj4gQWx0aG91Z2ggdGhlIHBoeSBkcml2ZXIgaXMgY2FsbGVkIGZyb20gZHdjMy1jb3JlIGRyaXZl ciwKPiB3ZSBuZWVkIHRvIGRlYXNzZXJ0IHRoZSByZXNldCBiaXQgYmVmb3JlIHByb2JpbmcgZHdj My1jb3JlIGRyaXZlci4KPgo+IEFzIHNob3duIGxhdGVyLCBJIHRoaW5rIHRoYXQgaXQncyBkaWZm aWN1dCB0byBkZXRlcm1pbmUgdGhlIG9yZGVyIG9mCj4gaW5pdGlhbGl6aW5nIHRoZSByZWdpc3Rl cnMgaW4gdGhpcyBhcmVhLgo+Cj4+ID4gK3N0YXRpYyB2b2lkIGR3YzN1X3ZidXNfZGlzYWJsZShz dHJ1Y3QgZHdjM3VfcHJpdiAqcHJpdikKPj4gPiArewo+PiA+ICsJaW50IGk7Cj4+ID4gKwo+PiA+ ICsJZm9yIChpID0gMDsgaSA8IHByaXYtPm52YnVzOyBpKyspIHsKPj4gPiArCQlkd2MzdV9tYXNr d3JpdGUocHJpdiwgVkJVU19DT05UUk9MKGkpLAo+PiA+ICsJCQkJRFJWVkJVU19SRUdfRU4gfCBE UlZWQlVTX1JFRywKPj4gPiArCQkJCURSVlZCVVNfUkVHX0VOIHwgMCk7Cj4+ID4gKwl9Cj4+ID4g K30KPj4gCj4+IGRyaXZlcnMvcmVndWxhdG9yIG1heWJlPwo+Cj4gVkJVU19DT05UUk9MIHJlZ2lz dGVyIGlzIHVzZWQgZm9yIGRldGVybWluZyB3aGV0aGVyICJkd2MzLWdsdWUiIGhhcmR3YXJlCj4g ZW5hYmxlcyB2YnVzIGNvbm5lY3RlZCB3aXRoICJyZWd1bGF0b3IiIGhhcmR3YXJlLgo+Cj4gVGhl IHJlZ3VsYXRvciBkcml2ZXIgc2hvdWxkIG1hbmFnZSAicmVndWxhdG9yIiBoYXJkd2FyZSwgYW5k Cj4gSSBkb24ndCB0aGluayB0aGF0IHRoZSBkcml2ZXIgc2hvdWxkIG1hbmFnZSB0aGlzIHJlZ2lz dGVyLgo+Cj4+ID4gK3N0YXRpYyB2b2lkIGR3YzN1X3Jlc2V0X2luaXQoc3RydWN0IGR3YzN1X3By aXYgKnByaXYpCj4+ID4gK3sKPj4gPiArCWR3YzN1X21hc2t3cml0ZShwcml2LCBSRVNFVF9DVEws IExJTktfUkVTRVQsIDApOwo+PiA+ICsJdXNsZWVwX3JhbmdlKDEwMDAsIDIwMDApOwo+PiA+ICsJ ZHdjM3VfbWFza3dyaXRlKHByaXYsIFJFU0VUX0NUTCwgTElOS19SRVNFVCwgTElOS19SRVNFVCk7 Cj4+ID4gK30KPj4gPiArCj4+ID4gK3N0YXRpYyB2b2lkIGR3YzN1X3Jlc2V0X2NsZWFyKHN0cnVj dCBkd2MzdV9wcml2ICpwcml2KQo+PiA+ICt7Cj4+ID4gKwlkd2MzdV9tYXNrd3JpdGUocHJpdiwg UkVTRVRfQ1RMLCBMSU5LX1JFU0VULCAwKTsKPj4gPiArfQo+PiAKPj4gZHJpdmVycy9yZXNldCA/ Cj4KPiBUaGUgcmVzZXQgZHJpdmVyIG1hbmFnZXMgInN5c2N0cmwiIElPIG1hcCBhcmVhIGluIG91 ciBTb0MuCj4KPiBSRVNFVF9DVEwgcmVnaXN0ZXIgYmVsb25ncyB0byAiZHdjMy1nbHVlIiBJTyBt YXAgYXJlYSwKPiBhbmQgdGhlIGtlcm5lbCBjYW4ndCBhY2Nlc3MgdGhpcyBhcmVhIHVudGlsIGVu YWJsaW5nIHVzYiBjbG9ja3MgYW5kCj4gZGVhc3NlcnRpbmcgdXNiIHJlc2V0cyBpbiAic3lzY3Ry bCIuCj4KPiBJIHRoaW5rIHRoYXQgImR3YzMtZ2x1ZSIgcmVnaXN0ZXIgY29udHJvbCBzaG91bGQg YmUgc2VwYXJhdGVkIGZyb20KPiAic3lzY3RybCIuCgpKdXN0IHNwbGl0IHlvdXIgYWRkcmVzcyBz cGFjZSBhbmQgdHJlYXQgeW91ciBnbHVlIGFzIGEgZGV2aWNlIHdpdGgKc2V2ZXJhbCBjaGlsZHJl bjoKCmdsdWVANjViMDAwMDAgewoJY29tcGF0aWJsZSA9ICJmb28iCgoJcGh5QGJhciB7CiAgICAg ICAgCS4uLgoJfTsKCglzeXNjdHJsQGJheiB7CiAgICAgICAgCS4uLgoJfTsKCglkd2MzQGZvbyB7 CiAgICAgICAgCWNvbXBhdGlibGUgPSAic25wcywgZHdjMyI7CiAgICAgICAgICAgICAgICAuLi4K CX07Cn07CgpUaGVuIHlvdSBrbm93IHRoYXQgeW91IGNhbiBsZXQgZHdjMy9jb3JlLmMgaGFuZGxl IHRoZSBQSFkgZm9yIHlvdS4gSWYgd2UKbmVlZCB0byB0ZWFjaCBkd2MzL2NvcmUuYyBhYm91dCBy ZWd1bGF0b3JzLCB3ZSBjYW4gZG8gdGhhdC4gQnV0IHdlIGRvbid0Cm5lZWQgU29DLXNwZWNpZmlj IGhhY2tzIDstKQo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: balbi@kernel.org (Felipe Balbi) Date: Wed, 24 Jan 2018 14:58:12 +0200 Subject: [PATCH 2/4] usb: dwc3: add dwc3 glue layer for UniPhier SoCs In-Reply-To: <20180124215228.ED43.4A936039@socionext.com> References: <1516712454-2915-3-git-send-email-hayashi.kunihiko@socionext.com> <87o9lklnwb.fsf@linux.intel.com> <20180124215228.ED43.4A936039@socionext.com> Message-ID: <87a7x3l8gr.fsf@linux.intel.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, Kunihiko Hayashi writes: > Hello Felipe, > > Thank you for your comments. > > On Tue, 23 Jan 2018 15:12:36 +0200 wrote: > >> >> Hi, >> >> Kunihiko Hayashi writes: >> > Add a specific glue layer for UniPhier SoC platform to support >> > USB host mode. It manages hardware operating sequences to enable multiple >> > clock gates and assert resets, and to prepare to use dwc3 controller >> > on the SoC. >> > >> > This patch also handles the physical layer that has same register space >> > as the glue layer, because it needs to integrate initialziation sequence >> > between glue and phy. >> > >> > In case of some SoCs, since some initialization values for PHY are >> > included in nvmem, this patch includes the way to get the values from nvmem. >> > >> > It supports PXs2 and LD20 SoCs. >> > >> > Signed-off-by: Kunihiko Hayashi >> > Signed-off-by: Motoya Tanigawa >> > Signed-off-by: Masami Hiramatsu >> > --- >> > drivers/usb/dwc3/Kconfig | 9 + >> > drivers/usb/dwc3/Makefile | 1 + >> > drivers/usb/dwc3/dwc3-uniphier.c | 554 +++++++++++++++++++++++++++++++++++++++ >> > 3 files changed, 564 insertions(+) >> > create mode 100644 drivers/usb/dwc3/dwc3-uniphier.c > > ...snip... > >> > + >> > +static void dwc3u_ssphy_testio_write(struct dwc3u_priv *priv, int port, >> > + u32 data) >> >> anything with sshphy or hsphy in the name should probably be part of a >> PHY driver using drivers/phy/ framework. > > I can try to separate phy control from this driver. > However, phy registers belongs to "dwc3-glue" IO map area (65b00000), > and this area also contains a reset bit for "dwc3-core" hardware. > > Although the phy driver is called from dwc3-core driver, > we need to deassert the reset bit before probing dwc3-core driver. > > As shown later, I think that it's difficut to determine the order of > initializing the registers in this area. > >> > +static void dwc3u_vbus_disable(struct dwc3u_priv *priv) >> > +{ >> > + int i; >> > + >> > + for (i = 0; i < priv->nvbus; i++) { >> > + dwc3u_maskwrite(priv, VBUS_CONTROL(i), >> > + DRVVBUS_REG_EN | DRVVBUS_REG, >> > + DRVVBUS_REG_EN | 0); >> > + } >> > +} >> >> drivers/regulator maybe? > > VBUS_CONTROL register is used for determing whether "dwc3-glue" hardware > enables vbus connected with "regulator" hardware. > > The regulator driver should manage "regulator" hardware, and > I don't think that the driver should manage this register. > >> > +static void dwc3u_reset_init(struct dwc3u_priv *priv) >> > +{ >> > + dwc3u_maskwrite(priv, RESET_CTL, LINK_RESET, 0); >> > + usleep_range(1000, 2000); >> > + dwc3u_maskwrite(priv, RESET_CTL, LINK_RESET, LINK_RESET); >> > +} >> > + >> > +static void dwc3u_reset_clear(struct dwc3u_priv *priv) >> > +{ >> > + dwc3u_maskwrite(priv, RESET_CTL, LINK_RESET, 0); >> > +} >> >> drivers/reset ? > > The reset driver manages "sysctrl" IO map area in our SoC. > > RESET_CTL register belongs to "dwc3-glue" IO map area, > and the kernel can't access this area until enabling usb clocks and > deasserting usb resets in "sysctrl". > > I think that "dwc3-glue" register control should be separated from > "sysctrl". Just split your address space and treat your glue as a device with several children: glue at 65b00000 { compatible = "foo" phy at bar { ... }; sysctrl at baz { ... }; dwc3 at foo { compatible = "snps, dwc3"; ... }; }; Then you know that you can let dwc3/core.c handle the PHY for you. If we need to teach dwc3/core.c about regulators, we can do that. But we don't need SoC-specific hacks ;-) -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felipe Balbi Subject: Re: [PATCH 2/4] usb: dwc3: add dwc3 glue layer for UniPhier SoCs Date: Wed, 24 Jan 2018 14:58:12 +0200 Message-ID: <87a7x3l8gr.fsf@linux.intel.com> References: <1516712454-2915-3-git-send-email-hayashi.kunihiko@socionext.com> <87o9lklnwb.fsf@linux.intel.com> <20180124215228.ED43.4A936039@socionext.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: In-Reply-To: <20180124215228.ED43.4A936039-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Kunihiko Hayashi Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Greg Kroah-Hartman , Masahiro Yamada , Rob Herring , Mark Rutland , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jassi Brar , Masami Hiramatsu , Kishon Vijay Abraham I List-Id: devicetree@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Kunihiko Hayashi writes: > Hello Felipe, > > Thank you for your comments. > > On Tue, 23 Jan 2018 15:12:36 +0200 wrote: > >>=20 >> Hi, >>=20 >> Kunihiko Hayashi writes: >> > Add a specific glue layer for UniPhier SoC platform to support >> > USB host mode. It manages hardware operating sequences to enable multi= ple >> > clock gates and assert resets, and to prepare to use dwc3 controller >> > on the SoC. >> > >> > This patch also handles the physical layer that has same register space >> > as the glue layer, because it needs to integrate initialziation sequen= ce >> > between glue and phy. >> > >> > In case of some SoCs, since some initialization values for PHY are >> > included in nvmem, this patch includes the way to get the values from = nvmem. >> > >> > It supports PXs2 and LD20 SoCs. >> > >> > Signed-off-by: Kunihiko Hayashi >> > Signed-off-by: Motoya Tanigawa >> > Signed-off-by: Masami Hiramatsu >> > --- >> > drivers/usb/dwc3/Kconfig | 9 + >> > drivers/usb/dwc3/Makefile | 1 + >> > drivers/usb/dwc3/dwc3-uniphier.c | 554 ++++++++++++++++++++++++++++++= +++++++++ >> > 3 files changed, 564 insertions(+) >> > create mode 100644 drivers/usb/dwc3/dwc3-uniphier.c > > ...snip... > >> > + >> > +static void dwc3u_ssphy_testio_write(struct dwc3u_priv *priv, int por= t, >> > + u32 data) >>=20 >> anything with sshphy or hsphy in the name should probably be part of a >> PHY driver using drivers/phy/ framework. > > I can try to separate phy control from this driver. > However, phy registers belongs to "dwc3-glue" IO map area (65b00000), > and this area also contains a reset bit for "dwc3-core" hardware. > > Although the phy driver is called from dwc3-core driver, > we need to deassert the reset bit before probing dwc3-core driver. > > As shown later, I think that it's difficut to determine the order of > initializing the registers in this area. > >> > +static void dwc3u_vbus_disable(struct dwc3u_priv *priv) >> > +{ >> > + int i; >> > + >> > + for (i =3D 0; i < priv->nvbus; i++) { >> > + dwc3u_maskwrite(priv, VBUS_CONTROL(i), >> > + DRVVBUS_REG_EN | DRVVBUS_REG, >> > + DRVVBUS_REG_EN | 0); >> > + } >> > +} >>=20 >> drivers/regulator maybe? > > VBUS_CONTROL register is used for determing whether "dwc3-glue" hardware > enables vbus connected with "regulator" hardware. > > The regulator driver should manage "regulator" hardware, and > I don't think that the driver should manage this register. > >> > +static void dwc3u_reset_init(struct dwc3u_priv *priv) >> > +{ >> > + dwc3u_maskwrite(priv, RESET_CTL, LINK_RESET, 0); >> > + usleep_range(1000, 2000); >> > + dwc3u_maskwrite(priv, RESET_CTL, LINK_RESET, LINK_RESET); >> > +} >> > + >> > +static void dwc3u_reset_clear(struct dwc3u_priv *priv) >> > +{ >> > + dwc3u_maskwrite(priv, RESET_CTL, LINK_RESET, 0); >> > +} >>=20 >> drivers/reset ? > > The reset driver manages "sysctrl" IO map area in our SoC. > > RESET_CTL register belongs to "dwc3-glue" IO map area, > and the kernel can't access this area until enabling usb clocks and > deasserting usb resets in "sysctrl". > > I think that "dwc3-glue" register control should be separated from > "sysctrl". Just split your address space and treat your glue as a device with several children: glue@65b00000 { compatible =3D "foo" phy@bar { ... }; sysctrl@baz { ... }; dwc3@foo { compatible =3D "snps, dwc3"; ... }; }; Then you know that you can let dwc3/core.c handle the PHY for you. If we need to teach dwc3/core.c about regulators, we can do that. But we don't need SoC-specific hacks ;-) =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAlpoguQACgkQzL64meEa mQbRig//eBvVqrK+Aq+5r/T2462ZCdpPzRg6hIL5K6DWWYUHGx9k0bLLFvjiniVf k6BViNvKbW717IyhwOeB9VplrLPlAfu8i8bKf382a6lWryO7l8xhDPfl2aTW9toz +DABlwZgWsxyHYIfgOlv4h89WOXYAGdKAywIAc7/qH4WAF1SUxoabfxL0L9NM6YT gP0PN1U7xUp4kCkSFkF8J6ub/cxFsxUZx7lRIdhfWe2S+ulaclktlbs1Hv5eRiGD XyzuVGXjjZNIy4pw7G/BQcQ1JOb13r6W/7cc4D9Gl8XdDcxNLLeP7w/rZADnTLwr 7NDdg9/+SkI07oFMx/heGIQeZ3T3coYkecIq2CB+B6B2PkmgahCSH2AYYopSjyVp 2QGvxLdsSAVA1w4dgdK/De+n4mSkcMOF0DcpbyfXVixwtz1C+HrAosjeMa3iBHGr Ja1a32MAaQgg1SG2QzSFnFSHiBiml8I7Rn5MQFrOkCQi7fv75mwma+mYxG7nQhgy 9kRMJ+4s5/7hikEjQvlIE++sdIsFFnPOV+o9q9VGOuOUvqC2r8NhYTw+w/R2TGul Eie6kB1O+WpFZkb3kB/laAtnk113MEXnAFR8JGQmAiZQ79jlBIZ3/8BB4Al4NYkc PEU5kWz5+SnjtmyY2cNCS/VLlVGEAE8nrPHEhLfbgDXLyXwF32c= =ZeYo -----END PGP SIGNATURE----- --=-=-=-- -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-1668029-1516798721-2-8412906501980525116 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, ME_NOAUTH 0.01, RCVD_IN_DNSWL_HI -5, T_RP_MATCHES_RCVD -0.01, T_TVD_MIME_EPI 0.01, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.132.180.67', Host='vger.kernel.org', Country='US', FromHeader='org', MailFrom='org' X-Spam-charsets: X-Attached: signature.asc X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: linux-usb-owner@vger.kernel.org ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=arctest; t=1516798721; b=icMwAcAgADxBaDHjBgpBgnub2b2dNFsfeSLCvVikE4coQ5e CmkCqTf/I0/+sIzMCqSSeVB31u1JAKBzxdUTcLEJzfR9HSK+lldbxFxskQyueB8j sD4A4mdeBzEJ7XkypplTitb5iOfwykbwUhg+UidQxJxxFn/wrecwcWileYF20B3A padQcyvxFeCZx+NNwJgUCT30SpmecwXZkuIIdClJqsQGcQr3rwMmYC2QfKI8lAy8 /qZfBcgCzjW9deKjyqxDnIaU0ak7XSa82UNA6ZlHtzXaYtSeJQM4ogix88Qqv/Ih z/sGUc739J6jSwBbOfQUWlUyfrVJdXe3p26KGfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=from:to:cc:subject:in-reply-to:references :date:message-id:mime-version:content-type:sender:list-id; s= arctest; t=1516798721; bh=IuGnBYPoCWkeCIYeNts+Ec5svN5kWYtizRCSmQ ajpwQ=; b=oEXeQch+nPbfFwbj+Igi1CST5F/EWaHyAhzUcbeu+VI+lDrGJvLQbb BDReoQQWeqKppwLz2GjoDtFz6SctIhiAQuRuayjxJhpB5Mk9MlF8F7RUGAmjfLle xQ6GDXpjKtswx3kcEgmt5pnA0ht/Ko4p8VEy0hAlJTwWVLiuw/aPfCOYI0Ftuocu LNa3ixvKhSOzOWj7NHQvm72heuGYjbrMI2i9ly5WABYN6gCx+a98Hukd93wGiRiC OhwFZ/inh539v2eiIwEwJjuRS75QcPX4umGWf/C80lvFgyKyJv6s3yaazr07X3yr 9Iu/5VnVAqDQqki7JmeP+qEL3MPozOVw== ARC-Authentication-Results: i=1; mx2.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=kernel.org; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); smime=temperror; spf=none smtp.mailfrom=linux-usb-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=orgdomain_pass; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=kernel.org header.result=pass header_is_org_domain=yes Authentication-Results: mx2.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=kernel.org; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); smime=temperror; spf=none smtp.mailfrom=linux-usb-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=orgdomain_pass; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=kernel.org header.result=pass header_is_org_domain=yes Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933588AbeAXM6X (ORCPT ); Wed, 24 Jan 2018 07:58:23 -0500 Received: from mga14.intel.com ([192.55.52.115]:46474 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933467AbeAXM6X (ORCPT ); Wed, 24 Jan 2018 07:58:23 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,407,1511856000"; d="asc'?scan'208";a="198265512" From: Felipe Balbi To: Kunihiko Hayashi Cc: linux-usb@vger.kernel.org, Greg Kroah-Hartman , Masahiro Yamada , Rob Herring , Mark Rutland , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Jassi Brar , Masami Hiramatsu , Kishon Vijay Abraham I Subject: Re: [PATCH 2/4] usb: dwc3: add dwc3 glue layer for UniPhier SoCs In-Reply-To: <20180124215228.ED43.4A936039@socionext.com> References: <1516712454-2915-3-git-send-email-hayashi.kunihiko@socionext.com> <87o9lklnwb.fsf@linux.intel.com> <20180124215228.ED43.4A936039@socionext.com> Date: Wed, 24 Jan 2018 14:58:12 +0200 Message-ID: <87a7x3l8gr.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Sender: linux-usb-owner@vger.kernel.org X-Mailing-List: linux-usb@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Kunihiko Hayashi writes: > Hello Felipe, > > Thank you for your comments. > > On Tue, 23 Jan 2018 15:12:36 +0200 wrote: > >>=20 >> Hi, >>=20 >> Kunihiko Hayashi writes: >> > Add a specific glue layer for UniPhier SoC platform to support >> > USB host mode. It manages hardware operating sequences to enable multi= ple >> > clock gates and assert resets, and to prepare to use dwc3 controller >> > on the SoC. >> > >> > This patch also handles the physical layer that has same register space >> > as the glue layer, because it needs to integrate initialziation sequen= ce >> > between glue and phy. >> > >> > In case of some SoCs, since some initialization values for PHY are >> > included in nvmem, this patch includes the way to get the values from = nvmem. >> > >> > It supports PXs2 and LD20 SoCs. >> > >> > Signed-off-by: Kunihiko Hayashi >> > Signed-off-by: Motoya Tanigawa >> > Signed-off-by: Masami Hiramatsu >> > --- >> > drivers/usb/dwc3/Kconfig | 9 + >> > drivers/usb/dwc3/Makefile | 1 + >> > drivers/usb/dwc3/dwc3-uniphier.c | 554 ++++++++++++++++++++++++++++++= +++++++++ >> > 3 files changed, 564 insertions(+) >> > create mode 100644 drivers/usb/dwc3/dwc3-uniphier.c > > ...snip... > >> > + >> > +static void dwc3u_ssphy_testio_write(struct dwc3u_priv *priv, int por= t, >> > + u32 data) >>=20 >> anything with sshphy or hsphy in the name should probably be part of a >> PHY driver using drivers/phy/ framework. > > I can try to separate phy control from this driver. > However, phy registers belongs to "dwc3-glue" IO map area (65b00000), > and this area also contains a reset bit for "dwc3-core" hardware. > > Although the phy driver is called from dwc3-core driver, > we need to deassert the reset bit before probing dwc3-core driver. > > As shown later, I think that it's difficut to determine the order of > initializing the registers in this area. > >> > +static void dwc3u_vbus_disable(struct dwc3u_priv *priv) >> > +{ >> > + int i; >> > + >> > + for (i =3D 0; i < priv->nvbus; i++) { >> > + dwc3u_maskwrite(priv, VBUS_CONTROL(i), >> > + DRVVBUS_REG_EN | DRVVBUS_REG, >> > + DRVVBUS_REG_EN | 0); >> > + } >> > +} >>=20 >> drivers/regulator maybe? > > VBUS_CONTROL register is used for determing whether "dwc3-glue" hardware > enables vbus connected with "regulator" hardware. > > The regulator driver should manage "regulator" hardware, and > I don't think that the driver should manage this register. > >> > +static void dwc3u_reset_init(struct dwc3u_priv *priv) >> > +{ >> > + dwc3u_maskwrite(priv, RESET_CTL, LINK_RESET, 0); >> > + usleep_range(1000, 2000); >> > + dwc3u_maskwrite(priv, RESET_CTL, LINK_RESET, LINK_RESET); >> > +} >> > + >> > +static void dwc3u_reset_clear(struct dwc3u_priv *priv) >> > +{ >> > + dwc3u_maskwrite(priv, RESET_CTL, LINK_RESET, 0); >> > +} >>=20 >> drivers/reset ? > > The reset driver manages "sysctrl" IO map area in our SoC. > > RESET_CTL register belongs to "dwc3-glue" IO map area, > and the kernel can't access this area until enabling usb clocks and > deasserting usb resets in "sysctrl". > > I think that "dwc3-glue" register control should be separated from > "sysctrl". Just split your address space and treat your glue as a device with several children: glue@65b00000 { compatible =3D "foo" phy@bar { ... }; sysctrl@baz { ... }; dwc3@foo { compatible =3D "snps, dwc3"; ... }; }; Then you know that you can let dwc3/core.c handle the PHY for you. If we need to teach dwc3/core.c about regulators, we can do that. But we don't need SoC-specific hacks ;-) =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAlpoguQACgkQzL64meEa mQbRig//eBvVqrK+Aq+5r/T2462ZCdpPzRg6hIL5K6DWWYUHGx9k0bLLFvjiniVf k6BViNvKbW717IyhwOeB9VplrLPlAfu8i8bKf382a6lWryO7l8xhDPfl2aTW9toz +DABlwZgWsxyHYIfgOlv4h89WOXYAGdKAywIAc7/qH4WAF1SUxoabfxL0L9NM6YT gP0PN1U7xUp4kCkSFkF8J6ub/cxFsxUZx7lRIdhfWe2S+ulaclktlbs1Hv5eRiGD XyzuVGXjjZNIy4pw7G/BQcQ1JOb13r6W/7cc4D9Gl8XdDcxNLLeP7w/rZADnTLwr 7NDdg9/+SkI07oFMx/heGIQeZ3T3coYkecIq2CB+B6B2PkmgahCSH2AYYopSjyVp 2QGvxLdsSAVA1w4dgdK/De+n4mSkcMOF0DcpbyfXVixwtz1C+HrAosjeMa3iBHGr Ja1a32MAaQgg1SG2QzSFnFSHiBiml8I7Rn5MQFrOkCQi7fv75mwma+mYxG7nQhgy 9kRMJ+4s5/7hikEjQvlIE++sdIsFFnPOV+o9q9VGOuOUvqC2r8NhYTw+w/R2TGul Eie6kB1O+WpFZkb3kB/laAtnk113MEXnAFR8JGQmAiZQ79jlBIZ3/8BB4Al4NYkc PEU5kWz5+SnjtmyY2cNCS/VLlVGEAE8nrPHEhLfbgDXLyXwF32c= =ZeYo -----END PGP SIGNATURE----- --=-=-=--