public inbox for linux-clk@vger.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime@cerno.tech>
To: Priit Laes <plaes@plaes.org>
Cc: Chen-Yu Tsai <wens@csie.org>, Rob Herring <robh+dt@kernel.org>,
	linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-sunxi@googlegroups.com
Subject: Re: [PATCH v3 3/6] net: stmmac: dwmac-sunxi: Implement syscon-based clock handling
Date: Thu, 30 Apr 2020 16:58:17 +0200	[thread overview]
Message-ID: <20200430145817.5cqa542jncomcklt@gilmour.lan> (raw)
In-Reply-To: <20200430115702.5768-4-plaes@plaes.org>

[-- Attachment #1: Type: text/plain, Size: 6420 bytes --]

On Thu, Apr 30, 2020 at 02:56:59PM +0300, Priit Laes wrote:
> Convert the sun7i-gmac driver to use a regmap-based driver,
> instead of relying on the custom clock implementation.
> 
> This allows to get rid of the last custom clock in the sun7i
> device tree making the sun7i fully CCU-compatible.
> 
> Compatibility with existing devicetrees is retained.
> 
> Signed-off-by: Priit Laes <plaes@plaes.org>
> ---
>  .../net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 130 ++++++++++++++++--
>  1 file changed, 122 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
> index 0e1ca2cba3c7..206398f7a2af 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
> @@ -12,8 +12,11 @@
>  #include <linux/module.h>
>  #include <linux/phy.h>
>  #include <linux/platform_device.h>
> +#include <linux/of_device.h>
>  #include <linux/of_net.h>
>  #include <linux/regulator/consumer.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/syscon.h>
>  
>  #include "stmmac_platform.h"
>  
> @@ -22,11 +25,23 @@ struct sunxi_priv_data {
>  	int clk_enabled;
>  	struct clk *tx_clk;
>  	struct regulator *regulator;
> +	struct regmap_field *regmap_field;
> +};
> +
> +/* EMAC clock register @ 0x164 in the CCU address range */
> +static const struct reg_field ccu_reg_field = {
> +	.reg = 0x164,
> +	.lsb = 0,
> +	.msb = 31,
>  };
>  
>  #define SUN7I_GMAC_GMII_RGMII_RATE	125000000
>  #define SUN7I_GMAC_MII_RATE		25000000
>  
> +#define SUN7I_A20_CLK_MASK		GENMASK(2, 0)
> +#define SUN7I_A20_RGMII_CLK		(BIT(2) | BIT(1))
> +#define SUN7I_A20_MII_CLK		0
> +
>  static int sun7i_gmac_init(struct platform_device *pdev, void *priv)
>  {
>  	struct sunxi_priv_data *gmac = priv;
> @@ -38,7 +53,20 @@ static int sun7i_gmac_init(struct platform_device *pdev, void *priv)
>  			return ret;
>  	}
>  
> -	/* Set GMAC interface port mode
> +	if (gmac->regmap_field) {
> +		if (phy_interface_mode_is_rgmii(gmac->interface)) {
> +			regmap_field_update_bits(gmac->regmap_field,
> +						 SUN7I_A20_CLK_MASK,
> +						 SUN7I_A20_RGMII_CLK);
> +			return clk_prepare_enable(gmac->tx_clk);
> +		}

Why do you prepare and enable the clock here? ...

> +		regmap_field_update_bits(gmac->regmap_field,
> +					 SUN7I_A20_CLK_MASK,
> +					 SUN7I_A20_MII_CLK);
> +		return clk_enable(gmac->tx_clk);
> +	}

... while you only enable it here ...

> +	/* Legacy devicetree clock (allwinner,sun7i-a20-gmac-clk) support:
>  	 *
>  	 * The GMAC TX clock lines are configured by setting the clock
>  	 * rate, which then uses the auto-reparenting feature of the
> @@ -62,9 +90,16 @@ static void sun7i_gmac_exit(struct platform_device *pdev, void *priv)
>  {
>  	struct sunxi_priv_data *gmac = priv;
>  
> -	if (gmac->clk_enabled) {
> +	if (gmac->regmap_field) {
> +		regmap_field_update_bits(gmac->regmap_field,
> +					 SUN7I_A20_CLK_MASK, 0);
>  		clk_disable(gmac->tx_clk);
> -		gmac->clk_enabled = 0;
> +	} else {
> +		/* Handle legacy devicetree clock (sun7i-a20-gmac-clk) */
> +		if (gmac->clk_enabled) {
> +			clk_disable(gmac->tx_clk);
> +			gmac->clk_enabled = 0;
> +		}
>  	}
>  	clk_unprepare(gmac->tx_clk);

.... and disable and unprepare it here?

> @@ -72,10 +107,55 @@ static void sun7i_gmac_exit(struct platform_device *pdev, void *priv)
>  		regulator_disable(gmac->regulator);
>  }
>  
> +static struct regmap *sun7i_gmac_get_syscon_from_dev(struct device_node *node)
> +{
> +	struct device_node *syscon_node;
> +	struct platform_device *syscon_pdev;
> +	struct regmap *regmap = NULL;
> +
> +	syscon_node = of_parse_phandle(node, "syscon", 0);
> +	if (!syscon_node)
> +		return ERR_PTR(-ENODEV);
> +
> +	syscon_pdev = of_find_device_by_node(syscon_node);
> +	if (!syscon_pdev) {
> +		/* platform device might not be probed yet */
> +		regmap = ERR_PTR(-EPROBE_DEFER);
> +		goto out_put_node;
> +	}
> +
> +	/* If no regmap is found then the other device driver is at fault */
> +	regmap = dev_get_regmap(&syscon_pdev->dev, NULL);
> +	if (!regmap)
> +		regmap = ERR_PTR(-EINVAL);
> +
> +	platform_device_put(syscon_pdev);
> +out_put_node:
> +	of_node_put(syscon_node);
> +	return regmap;
> +}
> +
>  static void sun7i_fix_speed(void *priv, unsigned int speed)
>  {
>  	struct sunxi_priv_data *gmac = priv;
>  
> +	if (gmac->regmap_field) {
> +		clk_disable(gmac->tx_clk);
> +		clk_unprepare(gmac->tx_clk);
> +		if (speed == 1000)
> +			regmap_field_update_bits(gmac->regmap_field,
> +						 SUN7I_A20_CLK_MASK,
> +						 SUN7I_A20_RGMII_CLK);
> +		else
> +			regmap_field_update_bits(gmac->regmap_field,
> +						 SUN7I_A20_CLK_MASK,
> +						 SUN7I_A20_MII_CLK);
> +		clk_prepare_enable(gmac->tx_clk);


If were going to use clk_prepare_enable, we might as well use
clk_disable_unprepare

> +		return;
> +	}
> +
> +	/* Handle legacy devicetree clock (sun7i-a20-gmac-clk) */

That doesn't say much, you should rather explain what the situation is exactly.

> +
>  	/* only GMII mode requires us to reconfigure the clock lines */
>  	if (gmac->interface != PHY_INTERFACE_MODE_GMII)
>  		return;
> @@ -102,6 +182,8 @@ static int sun7i_gmac_probe(struct platform_device *pdev)
>  	struct stmmac_resources stmmac_res;
>  	struct sunxi_priv_data *gmac;
>  	struct device *dev = &pdev->dev;
> +	struct device_node *syscon_node;
> +	struct regmap *regmap = NULL;
>  	int ret;
>  
>  	ret = stmmac_get_platform_resources(pdev, &stmmac_res);
> @@ -124,11 +206,43 @@ static int sun7i_gmac_probe(struct platform_device *pdev)
>  		goto err_remove_config_dt;
>  	}
>  
> -	gmac->tx_clk = devm_clk_get(dev, "allwinner_gmac_tx");
> -	if (IS_ERR(gmac->tx_clk)) {
> -		dev_err(dev, "could not get tx clock\n");
> -		ret = PTR_ERR(gmac->tx_clk);
> -		goto err_remove_config_dt;
> +	/* Attempt to fetch syscon node... */
> +	syscon_node = of_parse_phandle(dev->of_node, "syscon", 0);
> +	if (syscon_node) {
> +		gmac->tx_clk = devm_clk_get(dev, "stmmaceth");
> +		if (IS_ERR(gmac->tx_clk)) {
> +			dev_err(dev, "Could not get TX clock\n");
> +			ret = PTR_ERR(gmac->tx_clk);
> +			goto err_remove_config_dt;
> +		}

I'm not quite sure why you added this clock lookup here? Wasn't it here already?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2020-04-30 14:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-30 11:56 [PATCH v2 0/6] ARM: sunxi: Clean up sun7i-a20-gmac-clk usage Priit Laes
2020-04-30 11:56 ` [PATCH v3 1/6] clk: sunxi-ng: a20: Register regmap for sun7i CCU Priit Laes
2020-04-30 14:51   ` Maxime Ripard
2020-04-30 11:56 ` [PATCH v3 2/6] clk: sunxi-ng: a31: Register regmap for sun6i CCU Priit Laes
2020-04-30 11:56 ` [PATCH v3 3/6] net: stmmac: dwmac-sunxi: Implement syscon-based clock handling Priit Laes
2020-04-30 14:58   ` Maxime Ripard [this message]
2020-04-30 11:57 ` [PATCH v3 4/6] dt-bindings: net: sun7i-gmac: Add syscon support Priit Laes
2020-04-30 15:00   ` Maxime Ripard
2020-05-01 21:12   ` Rob Herring
2020-04-30 11:57 ` [PATCH v3 5/6] ARM: dts: sun7i: Use syscon-based implementation for gmac Priit Laes
2020-04-30 11:57 ` [PATCH v3 6/6] ARM: dts: sun6i: " Priit Laes

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=20200430145817.5cqa542jncomcklt@gilmour.lan \
    --to=maxime@cerno.tech \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=plaes@plaes.org \
    --cc=robh+dt@kernel.org \
    --cc=wens@csie.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox