All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko@sntech.de>
To: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	Brian Norris <briannorris@chromium.org>,
	dianders@chromium.org, Chris Zhong <zyw@rock-chips.com>,
	William wu <wulf@rock-chips.com>,
	hl@rock-chips.com, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	kernel@collabora.com
Subject: Re: [PATCH v2 1/6] phy: rockchip-typec: deprecate some DT properties for various register fields.
Date: Thu, 15 Feb 2018 17:06:03 +0100	[thread overview]
Message-ID: <2052597.3vIQ3VQ44p@phil> (raw)
In-Reply-To: <20180214165447.12181-1-enric.balletbo@collabora.com>

Hi Enric,

Am Mittwoch, 14. Februar 2018, 17:54:42 CET schrieb Enric Balletbo i Serra:
> Adding properties for various register fields in the DT doesn't scale and
> this information should be in the driver instead.
> 
> Before this patch these registers (description below) were specified in
> the DT, every register node contained 3 sections: offset, enable bit,
> write mask bit.
> 
>  - rockchip,typec-conn-dir : the register of type-c connector direction,
>    for type-c phy0, it must be <0xe580 0 16>;
>    for type-c phy1, it must be <0xe58c 0 16>;
>  - rockchip,usb3tousb2-en : the register of type-c force usb3 to usb2 enable
>    control.
>    for type-c phy0, it must be <0xe580 3 19>;
>    for type-c phy1, it must be <0xe58c 3 19>;
>  - rockchip,external-psm : the register of type-c phy external psm clock
>    selection.
>    for type-c phy0, it must be <0xe588 14 30>;
>    for type-c phy1, it must be <0xe594 14 30>;
>  - rockchip,pipe-status : the register of type-c phy pipe status.
>    for type-c phy0, it must be <0xe5c0 0 0>;
>    for type-c phy1, it must be <0xe5c0 16 16>;
> 
> After this patch these register definitions are in the driver. So can be
> removed from the DT. Note that there are 2 type-c phys for RK3399 with
> different offsets, the driver checks the phy base address of the running
> instance and applies the right offsets.
> 
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>

Generally I really support moving that stuff back into the driver and
judging by the recent mail conversations with Rob and Brian, this also
seems to be a consensus of sorts.

The one but I see here is, that the newly added things represent
rk3399-specific values and should be prefixed accordingly and also
already be flexible enough for the next soc using it.

Examples below.


> @@ -349,6 +349,9 @@
>  #define MODE_DFP_USB			BIT(1)
>  #define MODE_DFP_DP			BIT(2)
>  
> +#define TYPEC_PHY0_BASE_ADDRESS		0xff7c0000
> +#define TYPEC_PHY1_BASE_ADDRESS		0xff800000

RK3399_TYPEC_PHY0_ADDRESS etc ?

> @@ -362,6 +365,20 @@ struct rockchip_usb3phy_port_cfg {
>  	struct usb3phy_reg pipe_status;
>  };
>  
> +static const struct rockchip_usb3phy_port_cfg tcphy0_port_cfg = {
> +	.typec_conn_dir	= { 0xe580, 0, 16 },
> +	.usb3tousb2_en	= { 0xe580, 3, 19 },
> +	.external_psm	= { 0xe588, 14, 30 },
> +	.pipe_status	= { 0xe5c0, 0, 0 },
> +};
> +
> +static const struct rockchip_usb3phy_port_cfg tcphy1_port_cfg = {
> +	.typec_conn_dir	= { 0xe58c, 0, 16 },
> +	.usb3tousb2_en	= { 0xe58c, 3, 19 },
> +	.external_psm	= { 0xe594, 14, 30 },
> +	.pipe_status	= { 0xe5c0, 16, 16 },
> +};

rk3399_tcphy1_port_cfg. Especially important as these are GRF-registers
(general register files = a dumping ground for random settings bits)
and nothing ever stays the same in the GRF between chips.


> @@ -1103,6 +1078,13 @@ static int rockchip_typec_phy_probe(struct platform_device *pdev)
>  	if (IS_ERR(tcphy->base))
>  		return PTR_ERR(tcphy->base);
>  
> +	if (res->start == TYPEC_PHY0_BASE_ADDRESS)
> +		tcphy->port_cfgs = &tcphy0_port_cfg;
> +	else if (res->start == TYPEC_PHY1_BASE_ADDRESS)
> +		tcphy->port_cfgs = &tcphy1_port_cfg;
> +	else
> +		return -EINVAL;

should be selected according to the compatible.
Like just create a struct similar to things like the inno-usb2-phy.
That way you can also just write down the address itself in a reg
property and do not need specific constants like the ones at the top.


Heiko

WARNING: multiple messages have this Message-ID (diff)
From: heiko@sntech.de (Heiko Stuebner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/6] phy: rockchip-typec: deprecate some DT properties for various register fields.
Date: Thu, 15 Feb 2018 17:06:03 +0100	[thread overview]
Message-ID: <2052597.3vIQ3VQ44p@phil> (raw)
In-Reply-To: <20180214165447.12181-1-enric.balletbo@collabora.com>

Hi Enric,

Am Mittwoch, 14. Februar 2018, 17:54:42 CET schrieb Enric Balletbo i Serra:
> Adding properties for various register fields in the DT doesn't scale and
> this information should be in the driver instead.
> 
> Before this patch these registers (description below) were specified in
> the DT, every register node contained 3 sections: offset, enable bit,
> write mask bit.
> 
>  - rockchip,typec-conn-dir : the register of type-c connector direction,
>    for type-c phy0, it must be <0xe580 0 16>;
>    for type-c phy1, it must be <0xe58c 0 16>;
>  - rockchip,usb3tousb2-en : the register of type-c force usb3 to usb2 enable
>    control.
>    for type-c phy0, it must be <0xe580 3 19>;
>    for type-c phy1, it must be <0xe58c 3 19>;
>  - rockchip,external-psm : the register of type-c phy external psm clock
>    selection.
>    for type-c phy0, it must be <0xe588 14 30>;
>    for type-c phy1, it must be <0xe594 14 30>;
>  - rockchip,pipe-status : the register of type-c phy pipe status.
>    for type-c phy0, it must be <0xe5c0 0 0>;
>    for type-c phy1, it must be <0xe5c0 16 16>;
> 
> After this patch these register definitions are in the driver. So can be
> removed from the DT. Note that there are 2 type-c phys for RK3399 with
> different offsets, the driver checks the phy base address of the running
> instance and applies the right offsets.
> 
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>

Generally I really support moving that stuff back into the driver and
judging by the recent mail conversations with Rob and Brian, this also
seems to be a consensus of sorts.

The one but I see here is, that the newly added things represent
rk3399-specific values and should be prefixed accordingly and also
already be flexible enough for the next soc using it.

Examples below.


> @@ -349,6 +349,9 @@
>  #define MODE_DFP_USB			BIT(1)
>  #define MODE_DFP_DP			BIT(2)
>  
> +#define TYPEC_PHY0_BASE_ADDRESS		0xff7c0000
> +#define TYPEC_PHY1_BASE_ADDRESS		0xff800000

RK3399_TYPEC_PHY0_ADDRESS etc ?

> @@ -362,6 +365,20 @@ struct rockchip_usb3phy_port_cfg {
>  	struct usb3phy_reg pipe_status;
>  };
>  
> +static const struct rockchip_usb3phy_port_cfg tcphy0_port_cfg = {
> +	.typec_conn_dir	= { 0xe580, 0, 16 },
> +	.usb3tousb2_en	= { 0xe580, 3, 19 },
> +	.external_psm	= { 0xe588, 14, 30 },
> +	.pipe_status	= { 0xe5c0, 0, 0 },
> +};
> +
> +static const struct rockchip_usb3phy_port_cfg tcphy1_port_cfg = {
> +	.typec_conn_dir	= { 0xe58c, 0, 16 },
> +	.usb3tousb2_en	= { 0xe58c, 3, 19 },
> +	.external_psm	= { 0xe594, 14, 30 },
> +	.pipe_status	= { 0xe5c0, 16, 16 },
> +};

rk3399_tcphy1_port_cfg. Especially important as these are GRF-registers
(general register files = a dumping ground for random settings bits)
and nothing ever stays the same in the GRF between chips.


> @@ -1103,6 +1078,13 @@ static int rockchip_typec_phy_probe(struct platform_device *pdev)
>  	if (IS_ERR(tcphy->base))
>  		return PTR_ERR(tcphy->base);
>  
> +	if (res->start == TYPEC_PHY0_BASE_ADDRESS)
> +		tcphy->port_cfgs = &tcphy0_port_cfg;
> +	else if (res->start == TYPEC_PHY1_BASE_ADDRESS)
> +		tcphy->port_cfgs = &tcphy1_port_cfg;
> +	else
> +		return -EINVAL;

should be selected according to the compatible.
Like just create a struct similar to things like the inno-usb2-phy.
That way you can also just write down the address itself in a reg
property and do not need specific constants like the ones at the top.


Heiko

  parent reply	other threads:[~2018-02-15 16:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-14 16:54 [PATCH v2 1/6] phy: rockchip-typec: deprecate some DT properties for various register fields Enric Balletbo i Serra
2018-02-14 16:54 ` Enric Balletbo i Serra
2018-02-14 16:54 ` Enric Balletbo i Serra
2018-02-14 16:54 ` [PATCH v2 2/6] dt-bindings: phy-rockchip-typec: deprecate some register properties Enric Balletbo i Serra
2018-02-14 16:54   ` Enric Balletbo i Serra
     [not found]   ` <20180214165447.12181-2-enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2018-02-15 16:10     ` Heiko Stuebner
2018-02-15 16:10       ` Heiko Stuebner
2018-02-15 16:10       ` Heiko Stuebner
2018-02-14 16:54 ` [PATCH v2 3/6] phy: rockchip-typec: enable usb3 host during usb3 phy power on Enric Balletbo i Serra
2018-02-14 16:54   ` Enric Balletbo i Serra
2018-02-14 16:54 ` [PATCH v2 4/6] phy: rockchip-typec: force to USB2 if DP at 4 lanes mode Enric Balletbo i Serra
2018-02-14 16:54   ` Enric Balletbo i Serra
2018-02-14 16:54   ` Enric Balletbo i Serra
2018-02-14 16:54 ` [PATCH v2 5/6] phy: rockchip-typec: support DP phy switch Enric Balletbo i Serra
2018-02-14 16:54   ` Enric Balletbo i Serra
     [not found] ` <20180214165447.12181-1-enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2018-02-14 16:54   ` [PATCH v2 6/6] drm/rockchip: cdn-dp: remove the " Enric Balletbo i Serra
2018-02-14 16:54     ` Enric Balletbo i Serra
2018-02-14 16:54     ` Enric Balletbo i Serra
2018-02-15 16:06 ` Heiko Stuebner [this message]
2018-02-15 16:06   ` [PATCH v2 1/6] phy: rockchip-typec: deprecate some DT properties for various register fields Heiko Stuebner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2052597.3vIQ3VQ44p@phil \
    --to=heiko@sntech.de \
    --cc=briannorris@chromium.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=enric.balletbo@collabora.com \
    --cc=hl@rock-chips.com \
    --cc=kernel@collabora.com \
    --cc=kishon@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=wulf@rock-chips.com \
    --cc=zyw@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.