All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ikjoon Jang <ikjn@chromium.org>
To: Crystal Guo <crystal.guo@mediatek.com>
Cc: p.zabel@pengutronix.de, robh+dt@kernel.org,
	matthias.bgg@gmail.com, devicetree@vger.kernel.org,
	yong.liang@mediatek.com, stanley.chu@mediatek.com,
	srv_heupstream@mediatek.com, seiya.wang@mediatek.com,
	linux-kernel@vger.kernel.org, fan.chen@mediatek.com,
	linux-mediatek@lists.infradead.org, yingjoe.chen@mediatek.com,
	s-anna@ti.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [v6,2/3] reset-controller: ti: introduce a new reset handler
Date: Mon, 30 Nov 2020 18:35:05 +0800	[thread overview]
Message-ID: <20201130103505.GA3019533@chromium.org> (raw)
In-Reply-To: <20200930022159.5559-3-crystal.guo@mediatek.com>

On Wed, Sep 30, 2020 at 10:21:58AM +0800, Crystal Guo wrote:
> Introduce ti_syscon_reset() to integrate assert and deassert together.
> If some modules need do serialized assert and deassert operations
> to reset itself, reset_control_reset can be called for convenience.
> 
> Such as reset-qcom-aoss.c, it integrates assert and deassert together
> by 'reset' method. MTK Socs also need this method to perform reset.
> 
> Signed-off-by: Crystal Guo <crystal.guo@mediatek.com>

Reviewed-by: Ikjoon Jang <ikjn@chromium.org>

> ---
>  drivers/reset/reset-ti-syscon.c | 40 ++++++++++++++++++++++++++++++++-
>  1 file changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/reset/reset-ti-syscon.c b/drivers/reset/reset-ti-syscon.c
> index a2635c21db7f..5d1f8306cd4f 100644
> --- a/drivers/reset/reset-ti-syscon.c
> +++ b/drivers/reset/reset-ti-syscon.c
> @@ -15,15 +15,22 @@
>   * GNU General Public License for more details.
>   */
>  
> +#include <linux/delay.h>
>  #include <linux/mfd/syscon.h>
>  #include <linux/module.h>
>  #include <linux/of.h>
> +#include <linux/of_device.h>
>  #include <linux/platform_device.h>
>  #include <linux/regmap.h>
>  #include <linux/reset-controller.h>
>  
>  #include <dt-bindings/reset/ti-syscon.h>
>  
> +struct mediatek_reset_data {
> +	unsigned char *reset_bits;
> +	unsigned int reset_duration_us;
> +};
> +
>  /**
>   * struct ti_syscon_reset_control - reset control structure
>   * @assert_offset: reset assert control register offset from syscon base
> @@ -56,6 +63,7 @@ struct ti_syscon_reset_data {
>  	struct regmap *regmap;
>  	struct ti_syscon_reset_control *controls;
>  	unsigned int nr_controls;
> +	const struct mediatek_reset_data *reset_data;
>  };
>  
>  #define to_ti_syscon_reset_data(rcdev)	\
> @@ -158,9 +166,29 @@ static int ti_syscon_reset_status(struct reset_controller_dev *rcdev,
>  		!(control->flags & STATUS_SET);
>  }
>  
> +static int ti_syscon_reset(struct reset_controller_dev *rcdev,
> +				  unsigned long id)
> +{
> +	struct ti_syscon_reset_data *data = to_ti_syscon_reset_data(rcdev);
> +	int ret;
> +
> +	if (data->reset_data) {
> +		ret = ti_syscon_reset_assert(rcdev, id);
> +		if (ret)
> +			return ret;
> +		usleep_range(data->reset_data->reset_duration_us,
> +			data->reset_data->reset_duration_us * 2);
> +

There are many users using assert() and deassert() seperately
without any delay between them.

If there's a timing requirement between assertion and deassertion,
shouldn't there be a same amount of delay in assert?

> +		return ti_syscon_reset_deassert(rcdev, id);
> +	} else {
> +		return -ENOTSUPP;
> +	}
> +}
> +
>  static const struct reset_control_ops ti_syscon_reset_ops = {
>  	.assert		= ti_syscon_reset_assert,
>  	.deassert	= ti_syscon_reset_deassert,
> +	.reset		= ti_syscon_reset,
>  	.status		= ti_syscon_reset_status,
>  };
>  
> @@ -182,7 +210,11 @@ static int ti_syscon_reset_probe(struct platform_device *pdev)
>  	if (IS_ERR(regmap))
>  		return PTR_ERR(regmap);
>  
> -	list = of_get_property(np, "ti,reset-bits", &size);
> +	data->reset_data = of_device_get_match_data(&pdev->dev);
> +	if (data->reset_data)
> +		list = of_get_property(np, data->reset_data->reset_bits, &size);
> +	else
> +		list = of_get_property(np, "ti,reset-bits", &size);
>  	if (!list || (size / sizeof(*list)) % 7 != 0) {
>  		dev_err(dev, "invalid DT reset description\n");
>  		return -EINVAL;
> @@ -217,8 +249,14 @@ static int ti_syscon_reset_probe(struct platform_device *pdev)
>  	return devm_reset_controller_register(dev, &data->rcdev);
>  }
>  
> +static const struct mediatek_reset_data mtk_reset_data = {
> +	.reset_bits = "mediatek,reset-bits",
> +	.reset_duration_us = 10,
> +};
> +
>  static const struct of_device_id ti_syscon_reset_of_match[] = {
>  	{ .compatible = "ti,syscon-reset", },
> +	{ .compatible = "mediatek,syscon-reset", .data = &mtk_reset_data},
>  	{ /* sentinel */ },
>  };
>  MODULE_DEVICE_TABLE(of, ti_syscon_reset_of_match);

WARNING: multiple messages have this Message-ID (diff)
From: Ikjoon Jang <ikjn@chromium.org>
To: Crystal Guo <crystal.guo@mediatek.com>
Cc: devicetree@vger.kernel.org, yong.liang@mediatek.com,
	s-anna@ti.com, srv_heupstream@mediatek.com,
	seiya.wang@mediatek.com, linux-kernel@vger.kernel.org,
	fan.chen@mediatek.com, robh+dt@kernel.org,
	linux-mediatek@lists.infradead.org, p.zabel@pengutronix.de,
	matthias.bgg@gmail.com, yingjoe.chen@mediatek.com,
	stanley.chu@mediatek.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [v6,2/3] reset-controller: ti: introduce a new reset handler
Date: Mon, 30 Nov 2020 18:35:05 +0800	[thread overview]
Message-ID: <20201130103505.GA3019533@chromium.org> (raw)
In-Reply-To: <20200930022159.5559-3-crystal.guo@mediatek.com>

On Wed, Sep 30, 2020 at 10:21:58AM +0800, Crystal Guo wrote:
> Introduce ti_syscon_reset() to integrate assert and deassert together.
> If some modules need do serialized assert and deassert operations
> to reset itself, reset_control_reset can be called for convenience.
> 
> Such as reset-qcom-aoss.c, it integrates assert and deassert together
> by 'reset' method. MTK Socs also need this method to perform reset.
> 
> Signed-off-by: Crystal Guo <crystal.guo@mediatek.com>

Reviewed-by: Ikjoon Jang <ikjn@chromium.org>

> ---
>  drivers/reset/reset-ti-syscon.c | 40 ++++++++++++++++++++++++++++++++-
>  1 file changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/reset/reset-ti-syscon.c b/drivers/reset/reset-ti-syscon.c
> index a2635c21db7f..5d1f8306cd4f 100644
> --- a/drivers/reset/reset-ti-syscon.c
> +++ b/drivers/reset/reset-ti-syscon.c
> @@ -15,15 +15,22 @@
>   * GNU General Public License for more details.
>   */
>  
> +#include <linux/delay.h>
>  #include <linux/mfd/syscon.h>
>  #include <linux/module.h>
>  #include <linux/of.h>
> +#include <linux/of_device.h>
>  #include <linux/platform_device.h>
>  #include <linux/regmap.h>
>  #include <linux/reset-controller.h>
>  
>  #include <dt-bindings/reset/ti-syscon.h>
>  
> +struct mediatek_reset_data {
> +	unsigned char *reset_bits;
> +	unsigned int reset_duration_us;
> +};
> +
>  /**
>   * struct ti_syscon_reset_control - reset control structure
>   * @assert_offset: reset assert control register offset from syscon base
> @@ -56,6 +63,7 @@ struct ti_syscon_reset_data {
>  	struct regmap *regmap;
>  	struct ti_syscon_reset_control *controls;
>  	unsigned int nr_controls;
> +	const struct mediatek_reset_data *reset_data;
>  };
>  
>  #define to_ti_syscon_reset_data(rcdev)	\
> @@ -158,9 +166,29 @@ static int ti_syscon_reset_status(struct reset_controller_dev *rcdev,
>  		!(control->flags & STATUS_SET);
>  }
>  
> +static int ti_syscon_reset(struct reset_controller_dev *rcdev,
> +				  unsigned long id)
> +{
> +	struct ti_syscon_reset_data *data = to_ti_syscon_reset_data(rcdev);
> +	int ret;
> +
> +	if (data->reset_data) {
> +		ret = ti_syscon_reset_assert(rcdev, id);
> +		if (ret)
> +			return ret;
> +		usleep_range(data->reset_data->reset_duration_us,
> +			data->reset_data->reset_duration_us * 2);
> +

There are many users using assert() and deassert() seperately
without any delay between them.

If there's a timing requirement between assertion and deassertion,
shouldn't there be a same amount of delay in assert?

> +		return ti_syscon_reset_deassert(rcdev, id);
> +	} else {
> +		return -ENOTSUPP;
> +	}
> +}
> +
>  static const struct reset_control_ops ti_syscon_reset_ops = {
>  	.assert		= ti_syscon_reset_assert,
>  	.deassert	= ti_syscon_reset_deassert,
> +	.reset		= ti_syscon_reset,
>  	.status		= ti_syscon_reset_status,
>  };
>  
> @@ -182,7 +210,11 @@ static int ti_syscon_reset_probe(struct platform_device *pdev)
>  	if (IS_ERR(regmap))
>  		return PTR_ERR(regmap);
>  
> -	list = of_get_property(np, "ti,reset-bits", &size);
> +	data->reset_data = of_device_get_match_data(&pdev->dev);
> +	if (data->reset_data)
> +		list = of_get_property(np, data->reset_data->reset_bits, &size);
> +	else
> +		list = of_get_property(np, "ti,reset-bits", &size);
>  	if (!list || (size / sizeof(*list)) % 7 != 0) {
>  		dev_err(dev, "invalid DT reset description\n");
>  		return -EINVAL;
> @@ -217,8 +249,14 @@ static int ti_syscon_reset_probe(struct platform_device *pdev)
>  	return devm_reset_controller_register(dev, &data->rcdev);
>  }
>  
> +static const struct mediatek_reset_data mtk_reset_data = {
> +	.reset_bits = "mediatek,reset-bits",
> +	.reset_duration_us = 10,
> +};
> +
>  static const struct of_device_id ti_syscon_reset_of_match[] = {
>  	{ .compatible = "ti,syscon-reset", },
> +	{ .compatible = "mediatek,syscon-reset", .data = &mtk_reset_data},
>  	{ /* sentinel */ },
>  };
>  MODULE_DEVICE_TABLE(of, ti_syscon_reset_of_match);

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Ikjoon Jang <ikjn@chromium.org>
To: Crystal Guo <crystal.guo@mediatek.com>
Cc: devicetree@vger.kernel.org, yong.liang@mediatek.com,
	srv_heupstream@mediatek.com, seiya.wang@mediatek.com,
	linux-kernel@vger.kernel.org, fan.chen@mediatek.com,
	robh+dt@kernel.org, linux-mediatek@lists.infradead.org,
	p.zabel@pengutronix.de, matthias.bgg@gmail.com,
	yingjoe.chen@mediatek.com, stanley.chu@mediatek.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [v6,2/3] reset-controller: ti: introduce a new reset handler
Date: Mon, 30 Nov 2020 18:35:05 +0800	[thread overview]
Message-ID: <20201130103505.GA3019533@chromium.org> (raw)
In-Reply-To: <20200930022159.5559-3-crystal.guo@mediatek.com>

On Wed, Sep 30, 2020 at 10:21:58AM +0800, Crystal Guo wrote:
> Introduce ti_syscon_reset() to integrate assert and deassert together.
> If some modules need do serialized assert and deassert operations
> to reset itself, reset_control_reset can be called for convenience.
> 
> Such as reset-qcom-aoss.c, it integrates assert and deassert together
> by 'reset' method. MTK Socs also need this method to perform reset.
> 
> Signed-off-by: Crystal Guo <crystal.guo@mediatek.com>

Reviewed-by: Ikjoon Jang <ikjn@chromium.org>

> ---
>  drivers/reset/reset-ti-syscon.c | 40 ++++++++++++++++++++++++++++++++-
>  1 file changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/reset/reset-ti-syscon.c b/drivers/reset/reset-ti-syscon.c
> index a2635c21db7f..5d1f8306cd4f 100644
> --- a/drivers/reset/reset-ti-syscon.c
> +++ b/drivers/reset/reset-ti-syscon.c
> @@ -15,15 +15,22 @@
>   * GNU General Public License for more details.
>   */
>  
> +#include <linux/delay.h>
>  #include <linux/mfd/syscon.h>
>  #include <linux/module.h>
>  #include <linux/of.h>
> +#include <linux/of_device.h>
>  #include <linux/platform_device.h>
>  #include <linux/regmap.h>
>  #include <linux/reset-controller.h>
>  
>  #include <dt-bindings/reset/ti-syscon.h>
>  
> +struct mediatek_reset_data {
> +	unsigned char *reset_bits;
> +	unsigned int reset_duration_us;
> +};
> +
>  /**
>   * struct ti_syscon_reset_control - reset control structure
>   * @assert_offset: reset assert control register offset from syscon base
> @@ -56,6 +63,7 @@ struct ti_syscon_reset_data {
>  	struct regmap *regmap;
>  	struct ti_syscon_reset_control *controls;
>  	unsigned int nr_controls;
> +	const struct mediatek_reset_data *reset_data;
>  };
>  
>  #define to_ti_syscon_reset_data(rcdev)	\
> @@ -158,9 +166,29 @@ static int ti_syscon_reset_status(struct reset_controller_dev *rcdev,
>  		!(control->flags & STATUS_SET);
>  }
>  
> +static int ti_syscon_reset(struct reset_controller_dev *rcdev,
> +				  unsigned long id)
> +{
> +	struct ti_syscon_reset_data *data = to_ti_syscon_reset_data(rcdev);
> +	int ret;
> +
> +	if (data->reset_data) {
> +		ret = ti_syscon_reset_assert(rcdev, id);
> +		if (ret)
> +			return ret;
> +		usleep_range(data->reset_data->reset_duration_us,
> +			data->reset_data->reset_duration_us * 2);
> +

There are many users using assert() and deassert() seperately
without any delay between them.

If there's a timing requirement between assertion and deassertion,
shouldn't there be a same amount of delay in assert?

> +		return ti_syscon_reset_deassert(rcdev, id);
> +	} else {
> +		return -ENOTSUPP;
> +	}
> +}
> +
>  static const struct reset_control_ops ti_syscon_reset_ops = {
>  	.assert		= ti_syscon_reset_assert,
>  	.deassert	= ti_syscon_reset_deassert,
> +	.reset		= ti_syscon_reset,
>  	.status		= ti_syscon_reset_status,
>  };
>  
> @@ -182,7 +210,11 @@ static int ti_syscon_reset_probe(struct platform_device *pdev)
>  	if (IS_ERR(regmap))
>  		return PTR_ERR(regmap);
>  
> -	list = of_get_property(np, "ti,reset-bits", &size);
> +	data->reset_data = of_device_get_match_data(&pdev->dev);
> +	if (data->reset_data)
> +		list = of_get_property(np, data->reset_data->reset_bits, &size);
> +	else
> +		list = of_get_property(np, "ti,reset-bits", &size);
>  	if (!list || (size / sizeof(*list)) % 7 != 0) {
>  		dev_err(dev, "invalid DT reset description\n");
>  		return -EINVAL;
> @@ -217,8 +249,14 @@ static int ti_syscon_reset_probe(struct platform_device *pdev)
>  	return devm_reset_controller_register(dev, &data->rcdev);
>  }
>  
> +static const struct mediatek_reset_data mtk_reset_data = {
> +	.reset_bits = "mediatek,reset-bits",
> +	.reset_duration_us = 10,
> +};
> +
>  static const struct of_device_id ti_syscon_reset_of_match[] = {
>  	{ .compatible = "ti,syscon-reset", },
> +	{ .compatible = "mediatek,syscon-reset", .data = &mtk_reset_data},
>  	{ /* sentinel */ },
>  };
>  MODULE_DEVICE_TABLE(of, ti_syscon_reset_of_match);

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-11-30 10:36 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30  2:21 [v6,0/3] introduce TI reset controller for MT8192 SoC Crystal Guo
2020-09-30  2:21 ` Crystal Guo
2020-09-30  2:21 ` Crystal Guo
2020-09-30  2:21 ` [v6,1/3] dt-binding: reset-controller: mediatek: add YAML schemas Crystal Guo
2020-09-30  2:21   ` Crystal Guo
2020-09-30  2:21   ` Crystal Guo
2020-10-14 13:30   ` Crystal Guo
2020-10-14 13:30     ` Crystal Guo
2020-10-14 13:30     ` Crystal Guo
2020-11-11  8:28     ` Stanley Chu
2020-11-11  8:28       ` Stanley Chu
2020-11-11  8:28       ` Stanley Chu
2020-12-03  7:41   ` Philipp Zabel
2020-12-03  7:41     ` Philipp Zabel
2020-12-03  7:41     ` Philipp Zabel
2020-12-26  9:06     ` Crystal Guo
2020-12-26  9:06       ` Crystal Guo
2020-12-26  9:06       ` Crystal Guo
2020-09-30  2:21 ` [v6,2/3] reset-controller: ti: introduce a new reset handler Crystal Guo
2020-09-30  2:21   ` Crystal Guo
2020-09-30  2:21   ` Crystal Guo
2020-11-30 10:35   ` Ikjoon Jang [this message]
2020-11-30 10:35     ` Ikjoon Jang
2020-11-30 10:35     ` Ikjoon Jang
2020-12-04  2:34     ` Crystal Guo
2020-12-04  2:34       ` Crystal Guo
2020-12-04  2:34       ` Crystal Guo
2020-09-30  2:21 ` [v6,3/3] reset-controller: ti: force the write operation when assert or deassert Crystal Guo
2020-09-30  2:21   ` [v6, 3/3] " Crystal Guo
2020-09-30  2:21   ` Crystal Guo
2020-11-30 11:13   ` Ikjoon Jang
2020-11-30 11:13     ` Ikjoon Jang
2020-11-30 11:13     ` Ikjoon Jang
2020-12-02 11:06     ` Crystal Guo
2020-12-02 11:06       ` Crystal Guo
2020-12-02 11:06       ` Crystal Guo
2020-12-03  3:30       ` Ikjoon Jang
2020-12-03  3:30         ` Ikjoon Jang
2020-12-03  3:30         ` Ikjoon Jang
2020-12-03  7:45   ` [v6,3/3] " Philipp Zabel
2020-12-03  7:45     ` Philipp Zabel
2020-12-03  7:45     ` Philipp Zabel

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=20201130103505.GA3019533@chromium.org \
    --to=ikjn@chromium.org \
    --cc=crystal.guo@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fan.chen@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh+dt@kernel.org \
    --cc=s-anna@ti.com \
    --cc=seiya.wang@mediatek.com \
    --cc=srv_heupstream@mediatek.com \
    --cc=stanley.chu@mediatek.com \
    --cc=yingjoe.chen@mediatek.com \
    --cc=yong.liang@mediatek.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.