[PATCH v2 1/6] phy: rockchip-typec: deprecate some DT properties for various register fields.

Heiko Stuebner heiko at sntech.de
Thu Feb 15 08:06:03 PST 2018


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 at 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




More information about the linux-arm-kernel mailing list