From mboxrd@z Thu Jan 1 00:00:00 1970 From: hayashi.kunihiko@socionext.com (Kunihiko Hayashi) Date: Tue, 24 Jul 2018 20:02:42 +0900 Subject: [PATCH 2/4] phy: socionext: add USB3 PHY driver for UniPhier SoC In-Reply-To: <419fd0cd-9df7-9581-124d-f7ca876eb8af@ti.com> References: <20180717202757.858B.4A936039@socionext.com> <419fd0cd-9df7-9581-124d-f7ca876eb8af@ti.com> Message-ID: <20180724200241.F6E2.4A936039@socionext.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Kishon, On Tue, 24 Jul 2018 09:31:34 +0530 wrote: > Hi, > > On Tuesday 17 July 2018 04:57 PM, Kunihiko Hayashi wrote: > > Hi Kishon, > > > > On Fri, 13 Jul 2018 12:45:06 +0530 wrote: > > > >> Hi, > >> > >> On Wednesday 11 July 2018 05:35 PM, Kunihiko Hayashi wrote: > >>> On Mon, 9 Jul 2018 20:23:19 +0900 wrote: > >>> > >>>> Hi Kishon, > >>>> Thank you for your comments. > >>>> > >>>> On Mon, 9 Jul 2018 10:49:50 +0530 wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> On Friday 29 June 2018 02:08 PM, Kunihiko Hayashi wrote: > >>>>>> Add a driver for PHY interface built into USB3 controller > >>>>>> implemented in UniPhier SoCs. > >>>>>> This driver supports High-Speed PHY and Super-Speed PHY. > >>>>>> > >>>>>> Signed-off-by: Kunihiko Hayashi > >>>>>> Signed-off-by: Motoya Tanigawa > >>>>>> Signed-off-by: Masami Hiramatsu > >>>>>> --- > >>>>>> drivers/phy/Kconfig | 1 + > >>>>>> drivers/phy/Makefile | 1 + > >>>>>> drivers/phy/socionext/Kconfig | 12 + > >>>>>> drivers/phy/socionext/Makefile | 6 + > >>>>>> drivers/phy/socionext/phy-uniphier-usb3hs.c | 422 ++++++++++++++++++++++++++++ > >>>>>> drivers/phy/socionext/phy-uniphier-usb3ss.c | 369 ++++++++++++++++++++++++ > >>>>>> 6 files changed, 811 insertions(+) > >>>>>> create mode 100644 drivers/phy/socionext/Kconfig > >>>>>> create mode 100644 drivers/phy/socionext/Makefile > >>>>>> create mode 100644 drivers/phy/socionext/phy-uniphier-usb3hs.c > >>>>>> create mode 100644 drivers/phy/socionext/phy-uniphier-usb3ss.c > >>>> > >>>> (snip...) > >>>> > >>>>>> --- /dev/null > >>>>>> +++ b/drivers/phy/socionext/phy-uniphier-usb3hs.c > >>>>>> @@ -0,0 +1,422 @@ > >>>>>> +// SPDX-License-Identifier: GPL-2.0 > >>>>>> +/* > >>>>>> + * phy-uniphier-usb3hs.c - HS-PHY driver for Socionext UniPhier USB3 controller > >>>>>> + * Copyright 2015-2018 Socionext Inc. > >>>>>> + * Author: > >>>>>> + * Kunihiko Hayashi > >>>>>> + * Contributors: > >>>>>> + * Motoya Tanigawa > >>>>>> + * Masami Hiramatsu > >>>>>> + */ > >>>>>> + > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> + > >>>>>> +#define HSPHY_CFG0 0x0 > >>>>>> +#define HSPHY_CFG0_HS_I_MASK GENMASK(31, 28) > >>>>>> +#define HSPHY_CFG0_HSDISC_MASK GENMASK(27, 26) > >>>>>> +#define HSPHY_CFG0_SWING_MASK GENMASK(17, 16) > >>>>>> +#define HSPHY_CFG0_SEL_T_MASK GENMASK(15, 12) > >>>>>> +#define HSPHY_CFG0_RTERM_MASK GENMASK(7, 6) > >>>>>> +#define HSPHY_CFG0_TRIMMASK (HSPHY_CFG0_HS_I_MASK \ > >>>>>> + | HSPHY_CFG0_SEL_T_MASK \ > >>>>>> + | HSPHY_CFG0_RTERM_MASK) > >>>>>> + > >>>>>> +#define HSPHY_CFG1 0x4 > >>>>>> +#define HSPHY_CFG1_DAT_EN BIT(29) > >>>>>> +#define HSPHY_CFG1_ADR_EN BIT(28) > >>>>>> +#define HSPHY_CFG1_ADR_MASK GENMASK(27, 16) > >>>>>> +#define HSPHY_CFG1_DAT_MASK GENMASK(23, 16) > >>>>>> + > >>>>>> +#define MAX_CLKS 3 > >>>>>> +#define MAX_RSTS 2 > >>>>>> +#define MAX_PHY_PARAMS 1 > >>>>>> + > >>>>>> +struct uniphier_u3hsphy_param { > >>>>>> + u32 addr; > >>>>>> + u32 mask; > >>>>>> + u32 val; > >>>>>> +}; > >>>>> > >>>>> I'd like to avoid configure the PHY this way, since it's impossible to know > >>>>> which register is being configured. > >>>> > >>> > >>> This way might be misunderstood. > >>> These HS-PHY and SS-PHY have "internal" registers, which are not memory-mapped. > >>> > >>> And to access these internal registers, we need to specify the number > >>> corresponding to the register. > >>> > >>> The "addr" in "uniphier_u3hsphy_param" is just the number of the register. > >>> The "mask" shows a bitfield of the register, that means one of PHY parameters. > >>> The "value" shows a parameter value to set to the bitfield. > >> > >> What does each of these bitfields represent? Which PHY parameter does it > >> configure. Are they really PHY parameters or they also configure clocks/mux > >> etc? I would like the configurations to be more descriptive so that we get to > >> know at least what's getting configured here. > > > > These bitfields represent phy parameters only, not include clocks/mux etc. > > We can express the register (bitfield) name with macros. > > > > However, only recommended values are noted for the bitfields in the specsheet, > > because there are the trimmed values that aren't set as power-on values, > > and we should use the values for stable operation. > > Calibration values are fine but at least the registers and bitfields has to be > described using names. I see. I'll describe bitfields using defined macros. The register numbers are like a page number, so they have no names even in the specsheet because there are various phy parameters in one register. Thank you, --- Best Regards, Kunihiko Hayashi From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kunihiko Hayashi Subject: Re: [PATCH 2/4] phy: socionext: add USB3 PHY driver for UniPhier SoC Date: Tue, 24 Jul 2018 20:02:42 +0900 Message-ID: <20180724200241.F6E2.4A936039@socionext.com> References: <20180717202757.858B.4A936039@socionext.com> <419fd0cd-9df7-9581-124d-f7ca876eb8af@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <419fd0cd-9df7-9581-124d-f7ca876eb8af@ti.com> Sender: linux-kernel-owner@vger.kernel.org To: Kishon Vijay Abraham I Cc: Rob Herring , Mark Rutland , Masahiro Yamada , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Masami Hiramatsu , Jassi Brar List-Id: devicetree@vger.kernel.org Hi Kishon, On Tue, 24 Jul 2018 09:31:34 +0530 wrote: > Hi, > > On Tuesday 17 July 2018 04:57 PM, Kunihiko Hayashi wrote: > > Hi Kishon, > > > > On Fri, 13 Jul 2018 12:45:06 +0530 wrote: > > > >> Hi, > >> > >> On Wednesday 11 July 2018 05:35 PM, Kunihiko Hayashi wrote: > >>> On Mon, 9 Jul 2018 20:23:19 +0900 wrote: > >>> > >>>> Hi Kishon, > >>>> Thank you for your comments. > >>>> > >>>> On Mon, 9 Jul 2018 10:49:50 +0530 wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> On Friday 29 June 2018 02:08 PM, Kunihiko Hayashi wrote: > >>>>>> Add a driver for PHY interface built into USB3 controller > >>>>>> implemented in UniPhier SoCs. > >>>>>> This driver supports High-Speed PHY and Super-Speed PHY. > >>>>>> > >>>>>> Signed-off-by: Kunihiko Hayashi > >>>>>> Signed-off-by: Motoya Tanigawa > >>>>>> Signed-off-by: Masami Hiramatsu > >>>>>> --- > >>>>>> drivers/phy/Kconfig | 1 + > >>>>>> drivers/phy/Makefile | 1 + > >>>>>> drivers/phy/socionext/Kconfig | 12 + > >>>>>> drivers/phy/socionext/Makefile | 6 + > >>>>>> drivers/phy/socionext/phy-uniphier-usb3hs.c | 422 ++++++++++++++++++++++++++++ > >>>>>> drivers/phy/socionext/phy-uniphier-usb3ss.c | 369 ++++++++++++++++++++++++ > >>>>>> 6 files changed, 811 insertions(+) > >>>>>> create mode 100644 drivers/phy/socionext/Kconfig > >>>>>> create mode 100644 drivers/phy/socionext/Makefile > >>>>>> create mode 100644 drivers/phy/socionext/phy-uniphier-usb3hs.c > >>>>>> create mode 100644 drivers/phy/socionext/phy-uniphier-usb3ss.c > >>>> > >>>> (snip...) > >>>> > >>>>>> --- /dev/null > >>>>>> +++ b/drivers/phy/socionext/phy-uniphier-usb3hs.c > >>>>>> @@ -0,0 +1,422 @@ > >>>>>> +// SPDX-License-Identifier: GPL-2.0 > >>>>>> +/* > >>>>>> + * phy-uniphier-usb3hs.c - HS-PHY driver for Socionext UniPhier USB3 controller > >>>>>> + * Copyright 2015-2018 Socionext Inc. > >>>>>> + * Author: > >>>>>> + * Kunihiko Hayashi > >>>>>> + * Contributors: > >>>>>> + * Motoya Tanigawa > >>>>>> + * Masami Hiramatsu > >>>>>> + */ > >>>>>> + > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> + > >>>>>> +#define HSPHY_CFG0 0x0 > >>>>>> +#define HSPHY_CFG0_HS_I_MASK GENMASK(31, 28) > >>>>>> +#define HSPHY_CFG0_HSDISC_MASK GENMASK(27, 26) > >>>>>> +#define HSPHY_CFG0_SWING_MASK GENMASK(17, 16) > >>>>>> +#define HSPHY_CFG0_SEL_T_MASK GENMASK(15, 12) > >>>>>> +#define HSPHY_CFG0_RTERM_MASK GENMASK(7, 6) > >>>>>> +#define HSPHY_CFG0_TRIMMASK (HSPHY_CFG0_HS_I_MASK \ > >>>>>> + | HSPHY_CFG0_SEL_T_MASK \ > >>>>>> + | HSPHY_CFG0_RTERM_MASK) > >>>>>> + > >>>>>> +#define HSPHY_CFG1 0x4 > >>>>>> +#define HSPHY_CFG1_DAT_EN BIT(29) > >>>>>> +#define HSPHY_CFG1_ADR_EN BIT(28) > >>>>>> +#define HSPHY_CFG1_ADR_MASK GENMASK(27, 16) > >>>>>> +#define HSPHY_CFG1_DAT_MASK GENMASK(23, 16) > >>>>>> + > >>>>>> +#define MAX_CLKS 3 > >>>>>> +#define MAX_RSTS 2 > >>>>>> +#define MAX_PHY_PARAMS 1 > >>>>>> + > >>>>>> +struct uniphier_u3hsphy_param { > >>>>>> + u32 addr; > >>>>>> + u32 mask; > >>>>>> + u32 val; > >>>>>> +}; > >>>>> > >>>>> I'd like to avoid configure the PHY this way, since it's impossible to know > >>>>> which register is being configured. > >>>> > >>> > >>> This way might be misunderstood. > >>> These HS-PHY and SS-PHY have "internal" registers, which are not memory-mapped. > >>> > >>> And to access these internal registers, we need to specify the number > >>> corresponding to the register. > >>> > >>> The "addr" in "uniphier_u3hsphy_param" is just the number of the register. > >>> The "mask" shows a bitfield of the register, that means one of PHY parameters. > >>> The "value" shows a parameter value to set to the bitfield. > >> > >> What does each of these bitfields represent? Which PHY parameter does it > >> configure. Are they really PHY parameters or they also configure clocks/mux > >> etc? I would like the configurations to be more descriptive so that we get to > >> know at least what's getting configured here. > > > > These bitfields represent phy parameters only, not include clocks/mux etc. > > We can express the register (bitfield) name with macros. > > > > However, only recommended values are noted for the bitfields in the specsheet, > > because there are the trimmed values that aren't set as power-on values, > > and we should use the values for stable operation. > > Calibration values are fine but at least the registers and bitfields has to be > described using names. I see. I'll describe bitfields using defined macros. The register numbers are like a page number, so they have no names even in the specsheet because there are various phy parameters in one register. Thank you, --- Best Regards, Kunihiko Hayashi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C921FECDFB8 for ; Tue, 24 Jul 2018 11:02:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8B25820856 for ; Tue, 24 Jul 2018 11:02:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B25820856 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=socionext.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388534AbeGXMIi (ORCPT ); Tue, 24 Jul 2018 08:08:38 -0400 Received: from mx.socionext.com ([202.248.49.38]:43763 "EHLO mx.socionext.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388241AbeGXMIi (ORCPT ); Tue, 24 Jul 2018 08:08:38 -0400 Received: from unknown (HELO iyokan-ex.css.socionext.com) ([172.31.9.54]) by mx.socionext.com with ESMTP; 24 Jul 2018 20:02:43 +0900 Received: from mail.mfilter.local (m-filter-2 [10.213.24.62]) by iyokan-ex.css.socionext.com (Postfix) with ESMTP id 94E8560034; Tue, 24 Jul 2018 20:02:43 +0900 (JST) Received: from 172.31.9.53 (172.31.9.53) by m-FILTER with ESMTP; Tue, 24 Jul 2018 20:02:43 +0900 Received: from yuzu.css.socionext.com (yuzu [172.31.8.45]) by iyokan.css.socionext.com (Postfix) with ESMTP id 45762403AB; Tue, 24 Jul 2018 20:02:43 +0900 (JST) Received: from [127.0.0.1] (unknown [10.213.132.48]) by yuzu.css.socionext.com (Postfix) with ESMTP id 0F962120453; Tue, 24 Jul 2018 20:02:43 +0900 (JST) Date: Tue, 24 Jul 2018 20:02:42 +0900 From: Kunihiko Hayashi To: Kishon Vijay Abraham I Subject: Re: [PATCH 2/4] phy: socionext: add USB3 PHY driver for UniPhier SoC Cc: Rob Herring , Mark Rutland , Masahiro Yamada , , , , Masami Hiramatsu , Jassi Brar In-Reply-To: <419fd0cd-9df7-9581-124d-f7ca876eb8af@ti.com> References: <20180717202757.858B.4A936039@socionext.com> <419fd0cd-9df7-9581-124d-f7ca876eb8af@ti.com> Message-Id: <20180724200241.F6E2.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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Kishon, On Tue, 24 Jul 2018 09:31:34 +0530 wrote: > Hi, > > On Tuesday 17 July 2018 04:57 PM, Kunihiko Hayashi wrote: > > Hi Kishon, > > > > On Fri, 13 Jul 2018 12:45:06 +0530 wrote: > > > >> Hi, > >> > >> On Wednesday 11 July 2018 05:35 PM, Kunihiko Hayashi wrote: > >>> On Mon, 9 Jul 2018 20:23:19 +0900 wrote: > >>> > >>>> Hi Kishon, > >>>> Thank you for your comments. > >>>> > >>>> On Mon, 9 Jul 2018 10:49:50 +0530 wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> On Friday 29 June 2018 02:08 PM, Kunihiko Hayashi wrote: > >>>>>> Add a driver for PHY interface built into USB3 controller > >>>>>> implemented in UniPhier SoCs. > >>>>>> This driver supports High-Speed PHY and Super-Speed PHY. > >>>>>> > >>>>>> Signed-off-by: Kunihiko Hayashi > >>>>>> Signed-off-by: Motoya Tanigawa > >>>>>> Signed-off-by: Masami Hiramatsu > >>>>>> --- > >>>>>> drivers/phy/Kconfig | 1 + > >>>>>> drivers/phy/Makefile | 1 + > >>>>>> drivers/phy/socionext/Kconfig | 12 + > >>>>>> drivers/phy/socionext/Makefile | 6 + > >>>>>> drivers/phy/socionext/phy-uniphier-usb3hs.c | 422 ++++++++++++++++++++++++++++ > >>>>>> drivers/phy/socionext/phy-uniphier-usb3ss.c | 369 ++++++++++++++++++++++++ > >>>>>> 6 files changed, 811 insertions(+) > >>>>>> create mode 100644 drivers/phy/socionext/Kconfig > >>>>>> create mode 100644 drivers/phy/socionext/Makefile > >>>>>> create mode 100644 drivers/phy/socionext/phy-uniphier-usb3hs.c > >>>>>> create mode 100644 drivers/phy/socionext/phy-uniphier-usb3ss.c > >>>> > >>>> (snip...) > >>>> > >>>>>> --- /dev/null > >>>>>> +++ b/drivers/phy/socionext/phy-uniphier-usb3hs.c > >>>>>> @@ -0,0 +1,422 @@ > >>>>>> +// SPDX-License-Identifier: GPL-2.0 > >>>>>> +/* > >>>>>> + * phy-uniphier-usb3hs.c - HS-PHY driver for Socionext UniPhier USB3 controller > >>>>>> + * Copyright 2015-2018 Socionext Inc. > >>>>>> + * Author: > >>>>>> + * Kunihiko Hayashi > >>>>>> + * Contributors: > >>>>>> + * Motoya Tanigawa > >>>>>> + * Masami Hiramatsu > >>>>>> + */ > >>>>>> + > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> +#include > >>>>>> + > >>>>>> +#define HSPHY_CFG0 0x0 > >>>>>> +#define HSPHY_CFG0_HS_I_MASK GENMASK(31, 28) > >>>>>> +#define HSPHY_CFG0_HSDISC_MASK GENMASK(27, 26) > >>>>>> +#define HSPHY_CFG0_SWING_MASK GENMASK(17, 16) > >>>>>> +#define HSPHY_CFG0_SEL_T_MASK GENMASK(15, 12) > >>>>>> +#define HSPHY_CFG0_RTERM_MASK GENMASK(7, 6) > >>>>>> +#define HSPHY_CFG0_TRIMMASK (HSPHY_CFG0_HS_I_MASK \ > >>>>>> + | HSPHY_CFG0_SEL_T_MASK \ > >>>>>> + | HSPHY_CFG0_RTERM_MASK) > >>>>>> + > >>>>>> +#define HSPHY_CFG1 0x4 > >>>>>> +#define HSPHY_CFG1_DAT_EN BIT(29) > >>>>>> +#define HSPHY_CFG1_ADR_EN BIT(28) > >>>>>> +#define HSPHY_CFG1_ADR_MASK GENMASK(27, 16) > >>>>>> +#define HSPHY_CFG1_DAT_MASK GENMASK(23, 16) > >>>>>> + > >>>>>> +#define MAX_CLKS 3 > >>>>>> +#define MAX_RSTS 2 > >>>>>> +#define MAX_PHY_PARAMS 1 > >>>>>> + > >>>>>> +struct uniphier_u3hsphy_param { > >>>>>> + u32 addr; > >>>>>> + u32 mask; > >>>>>> + u32 val; > >>>>>> +}; > >>>>> > >>>>> I'd like to avoid configure the PHY this way, since it's impossible to know > >>>>> which register is being configured. > >>>> > >>> > >>> This way might be misunderstood. > >>> These HS-PHY and SS-PHY have "internal" registers, which are not memory-mapped. > >>> > >>> And to access these internal registers, we need to specify the number > >>> corresponding to the register. > >>> > >>> The "addr" in "uniphier_u3hsphy_param" is just the number of the register. > >>> The "mask" shows a bitfield of the register, that means one of PHY parameters. > >>> The "value" shows a parameter value to set to the bitfield. > >> > >> What does each of these bitfields represent? Which PHY parameter does it > >> configure. Are they really PHY parameters or they also configure clocks/mux > >> etc? I would like the configurations to be more descriptive so that we get to > >> know at least what's getting configured here. > > > > These bitfields represent phy parameters only, not include clocks/mux etc. > > We can express the register (bitfield) name with macros. > > > > However, only recommended values are noted for the bitfields in the specsheet, > > because there are the trimmed values that aren't set as power-on values, > > and we should use the values for stable operation. > > Calibration values are fine but at least the registers and bitfields has to be > described using names. I see. I'll describe bitfields using defined macros. The register numbers are like a page number, so they have no names even in the specsheet because there are various phy parameters in one register. Thank you, --- Best Regards, Kunihiko Hayashi