From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-2782072-1516846188-2-5401598839389523049 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, HEADER_FROM_DIFFERENT_DOMAINS 0.25, ME_NOAUTH 0.01, RCVD_IN_DNSWL_HI -5, T_RP_MATCHES_RCVD -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='com', MailFrom='org' X-Spam-charsets: plain='US-ASCII' 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=1516846187; b=BNsVo1jz9xl4PIAS88EGoE2mszibS+GJXMj1t/P/oV2hv0S Wb975HgbwEZhH0FczlaPRuvJxTWUEsxfpNyUtMk5SKhLf6BQjMRpyO1/GPzF+5KD xWb1iX3fZpPkGNm38FDHCf+WPFmRxjvf+BVKPTUay4FXROMSAyE0Q++2qKhUQD0p ftDiDYFoWer+UykQpusYc25FG1xw0joEC5jhKPm7UhMVDRssJH2k/hNRAVv4221o 2w3U6XrSZ8onXl/H4m8c1sx721miY5AAChfP4NZw/tPFwHgVxlg5nwVo7lhAqKYK AdgTJ9YjpGoNwWQOD+1nYWVtfOJIp+V6RKegPsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:subject:cc:in-reply-to :references:message-id:mime-version:content-type :content-transfer-encoding:sender:list-id; s=arctest; t= 1516846187; bh=uFx+r/MBakEwwOXFqcf9pBc4tW18pJ2BGxbsYbWx9yY=; b=N 1rj8paVQsX1j2oz42G+i+EQKhO59J8ceY4IXRN5VO+PxEnO8E0cAJO+SZKFsoMh4 +0Y6jyI4jG9zDUmOFc1TURt4lWkVDP/ziEIn/fGjNe4bzrVsRNxyPF9A/WCcblqp H3PPv2gmTnxil3z0D2BufsZl51UICjc4ndTaCA6D5mo0rXcZ7qmk03BALALPmdd6 NoajCXwnGfHAMWA9QSGA8qJ1fzCNq/z6Zv+m6T05bArKef/YUuw21kF/7qd/isLI xTE47WIto/1aGddVs9kg9eH1baFGx9OdJxMxabGHJyhfbwvt3PBfZy5ftJcKzPDS vfX/yl0ZEMUukV9mAsWKg== 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=socionext.com; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=linux-usb-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; 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=socionext.com 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=socionext.com; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=linux-usb-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; 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=socionext.com header.result=pass header_is_org_domain=yes Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752647AbeAYCJd (ORCPT ); Wed, 24 Jan 2018 21:09:33 -0500 Received: from mx.socionext.com ([202.248.49.38]:25334 "EHLO mx.socionext.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751862AbeAYCJc (ORCPT ); Wed, 24 Jan 2018 21:09:32 -0500 Date: Thu, 25 Jan 2018 11:09:30 +0900 From: Kunihiko Hayashi To: Felipe Balbi Subject: Re: [PATCH 2/4] usb: dwc3: add dwc3 glue layer for UniPhier SoCs Cc: , Greg Kroah-Hartman , Masahiro Yamada , Rob Herring , "Mark Rutland" , , , , Jassi Brar , Masami Hiramatsu , Kishon Vijay Abraham I In-Reply-To: <87a7x3l8gr.fsf@linux.intel.com> References: <20180124215228.ED43.4A936039@socionext.com> <87a7x3l8gr.fsf@linux.intel.com> Message-Id: <20180125110929.C609.4A936039@socionext.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.70 [ja] 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: Hello Felipe, On Wed, 24 Jan 2018 14:58:12 +0200 wrote: > > 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@65b00000 { > compatible = "foo" Just to confirm, instead of SoC-specific glue driver, dwc3-of-simple.c should handle compatible "foo", right? > > phy@bar { > ... > }; > > sysctrl@baz { > ... > }; > > dwc3@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 ;-) I also don't think that dwc3/core.c should have any SoC-specific controls. I've thought the SoC-specific glue driver (dwc3-***.c) calls "clocks", "resets", and "regulators". However, although dwc3-of-simple.c can handle "clocks", it can't handle "resets" and "regulators". Who should call them? Thank you, --- Best Regards, Kunihiko Hayashi