All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yingjoe Chen <yingjoe.chen@mediatek.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
	broonie@kernel.org, yong.liang@mediatek.com,
	Jiaxin Yu <jiaxin.yu@mediatek.com>,
	lgirdwood@gmail.com, tzungbi@google.com, robh+dt@kernel.org,
	linux-mediatek@lists.infradead.org,
	Philipp Zabel <p.zabel@pengutronix.de>,
	eason.yen@mediatek.com, wim@linux-watchdog.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [alsa-devel] [PATCH v2 2/4] watchdog: mtk_wdt: mt8183: Add reset controller
Date: Sat, 5 Oct 2019 13:59:39 +0800	[thread overview]
Message-ID: <1570255179.29077.24.camel@mtksdaap41> (raw)
In-Reply-To: <a0b2e9a3-ca77-814f-b7bd-edc69f00fce2@roeck-us.net>

On Thu, 2019-10-03 at 06:49 -0700, Guenter Roeck wrote:
> On 9/27/19 3:31 AM, Jiaxin Yu wrote:

<snip..>


> > +static int toprgu_reset_assert(struct reset_controller_dev *rcdev,
> > +			       unsigned long id)
> > +{
> > +	unsigned int tmp;
> > +	unsigned long flags;
> > +	struct toprgu_reset *data = container_of(rcdev,
> > +				struct toprgu_reset, rcdev);
> > +
> > +	spin_lock_irqsave(&data->lock, flags);
> > +
> > +	tmp = __raw_readl(data->toprgu_swrst_base + data->regofs);
> > +	tmp |= BIT(id);
> > +	tmp |= WDT_SWSYS_RST_KEY;
> > +	writel(tmp, data->toprgu_swrst_base + data->regofs);
> > +
> > +	spin_unlock_irqrestore(&data->lock, flags);
> > +
> > +	return 0;
> > +}
> > +
> > +static int toprgu_reset_deassert(struct reset_controller_dev *rcdev,
> > +				 unsigned long id)
> > +{
> > +	unsigned int tmp;
> > +	unsigned long flags;
> > +	struct toprgu_reset *data = container_of(rcdev,
> > +					struct toprgu_reset, rcdev);
> > +
> > +	spin_lock_irqsave(&data->lock, flags);
> > +
> > +	tmp = __raw_readl(data->toprgu_swrst_base + data->regofs);
> > +	tmp &= ~BIT(id);
> > +	tmp |= WDT_SWSYS_RST_KEY;
> > +	writel(tmp, data->toprgu_swrst_base + data->regofs);
> > +
> > +	spin_unlock_irqrestore(&data->lock, flags);
> > +
> > +	return 0;
> > +}
> > +
> > +static int toprgu_reset(struct reset_controller_dev *rcdev,
> > +			unsigned long id)
> > +{
> > +	int ret;
> > +
> > +	ret = toprgu_reset_assert(rcdev, id);
> > +	if (ret)
> > +		return ret;
> > +
> > +	return toprgu_reset_deassert(rcdev, id);
> 
> Unless there is additional synchronization elsewhere, parallel calls
> to the -> assert, and ->reset callbacks may result in the reset being
> deasserted while at least one caller (the one who called the ->assert
> function) believes that it is still asserted.
> 
> [ ... and if there _is_ additional synchronization elsewhere, the
>    local spinlock would be unnecessary ]
> 

I'm not sure if this count as additional synchronization, but you could
get exclusive control to the reset by calling
reset_control_get_exclusive so others won't try to reset the component
while you are using it.

In this case, you still need spinlock because other drivers might trying
to reset their components and they share same register.

Joe.C


_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

WARNING: multiple messages have this Message-ID (diff)
From: Yingjoe Chen <yingjoe.chen@mediatek.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
	broonie@kernel.org, yong.liang@mediatek.com,
	Jiaxin Yu <jiaxin.yu@mediatek.com>,
	lgirdwood@gmail.com, tzungbi@google.com, robh+dt@kernel.org,
	linux-mediatek@lists.infradead.org,
	Philipp Zabel <p.zabel@pengutronix.de>,
	eason.yen@mediatek.com, perex@perex.cz, wim@linux-watchdog.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/4] watchdog: mtk_wdt: mt8183: Add reset controller
Date: Sat, 5 Oct 2019 13:59:39 +0800	[thread overview]
Message-ID: <1570255179.29077.24.camel@mtksdaap41> (raw)
In-Reply-To: <a0b2e9a3-ca77-814f-b7bd-edc69f00fce2@roeck-us.net>

On Thu, 2019-10-03 at 06:49 -0700, Guenter Roeck wrote:
> On 9/27/19 3:31 AM, Jiaxin Yu wrote:

<snip..>


> > +static int toprgu_reset_assert(struct reset_controller_dev *rcdev,
> > +			       unsigned long id)
> > +{
> > +	unsigned int tmp;
> > +	unsigned long flags;
> > +	struct toprgu_reset *data = container_of(rcdev,
> > +				struct toprgu_reset, rcdev);
> > +
> > +	spin_lock_irqsave(&data->lock, flags);
> > +
> > +	tmp = __raw_readl(data->toprgu_swrst_base + data->regofs);
> > +	tmp |= BIT(id);
> > +	tmp |= WDT_SWSYS_RST_KEY;
> > +	writel(tmp, data->toprgu_swrst_base + data->regofs);
> > +
> > +	spin_unlock_irqrestore(&data->lock, flags);
> > +
> > +	return 0;
> > +}
> > +
> > +static int toprgu_reset_deassert(struct reset_controller_dev *rcdev,
> > +				 unsigned long id)
> > +{
> > +	unsigned int tmp;
> > +	unsigned long flags;
> > +	struct toprgu_reset *data = container_of(rcdev,
> > +					struct toprgu_reset, rcdev);
> > +
> > +	spin_lock_irqsave(&data->lock, flags);
> > +
> > +	tmp = __raw_readl(data->toprgu_swrst_base + data->regofs);
> > +	tmp &= ~BIT(id);
> > +	tmp |= WDT_SWSYS_RST_KEY;
> > +	writel(tmp, data->toprgu_swrst_base + data->regofs);
> > +
> > +	spin_unlock_irqrestore(&data->lock, flags);
> > +
> > +	return 0;
> > +}
> > +
> > +static int toprgu_reset(struct reset_controller_dev *rcdev,
> > +			unsigned long id)
> > +{
> > +	int ret;
> > +
> > +	ret = toprgu_reset_assert(rcdev, id);
> > +	if (ret)
> > +		return ret;
> > +
> > +	return toprgu_reset_deassert(rcdev, id);
> 
> Unless there is additional synchronization elsewhere, parallel calls
> to the -> assert, and ->reset callbacks may result in the reset being
> deasserted while at least one caller (the one who called the ->assert
> function) believes that it is still asserted.
> 
> [ ... and if there _is_ additional synchronization elsewhere, the
>    local spinlock would be unnecessary ]
> 

I'm not sure if this count as additional synchronization, but you could
get exclusive control to the reset by calling
reset_control_get_exclusive so others won't try to reset the component
while you are using it.

In this case, you still need spinlock because other drivers might trying
to reset their components and they share same register.

Joe.C

WARNING: multiple messages have this Message-ID (diff)
From: Yingjoe Chen <yingjoe.chen@mediatek.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
	broonie@kernel.org, yong.liang@mediatek.com,
	Jiaxin Yu <jiaxin.yu@mediatek.com>,
	lgirdwood@gmail.com, tzungbi@google.com, robh+dt@kernel.org,
	linux-mediatek@lists.infradead.org,
	Philipp Zabel <p.zabel@pengutronix.de>,
	eason.yen@mediatek.com, perex@perex.cz, wim@linux-watchdog.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/4] watchdog: mtk_wdt: mt8183: Add reset controller
Date: Sat, 5 Oct 2019 13:59:39 +0800	[thread overview]
Message-ID: <1570255179.29077.24.camel@mtksdaap41> (raw)
In-Reply-To: <a0b2e9a3-ca77-814f-b7bd-edc69f00fce2@roeck-us.net>

On Thu, 2019-10-03 at 06:49 -0700, Guenter Roeck wrote:
> On 9/27/19 3:31 AM, Jiaxin Yu wrote:

<snip..>


> > +static int toprgu_reset_assert(struct reset_controller_dev *rcdev,
> > +			       unsigned long id)
> > +{
> > +	unsigned int tmp;
> > +	unsigned long flags;
> > +	struct toprgu_reset *data = container_of(rcdev,
> > +				struct toprgu_reset, rcdev);
> > +
> > +	spin_lock_irqsave(&data->lock, flags);
> > +
> > +	tmp = __raw_readl(data->toprgu_swrst_base + data->regofs);
> > +	tmp |= BIT(id);
> > +	tmp |= WDT_SWSYS_RST_KEY;
> > +	writel(tmp, data->toprgu_swrst_base + data->regofs);
> > +
> > +	spin_unlock_irqrestore(&data->lock, flags);
> > +
> > +	return 0;
> > +}
> > +
> > +static int toprgu_reset_deassert(struct reset_controller_dev *rcdev,
> > +				 unsigned long id)
> > +{
> > +	unsigned int tmp;
> > +	unsigned long flags;
> > +	struct toprgu_reset *data = container_of(rcdev,
> > +					struct toprgu_reset, rcdev);
> > +
> > +	spin_lock_irqsave(&data->lock, flags);
> > +
> > +	tmp = __raw_readl(data->toprgu_swrst_base + data->regofs);
> > +	tmp &= ~BIT(id);
> > +	tmp |= WDT_SWSYS_RST_KEY;
> > +	writel(tmp, data->toprgu_swrst_base + data->regofs);
> > +
> > +	spin_unlock_irqrestore(&data->lock, flags);
> > +
> > +	return 0;
> > +}
> > +
> > +static int toprgu_reset(struct reset_controller_dev *rcdev,
> > +			unsigned long id)
> > +{
> > +	int ret;
> > +
> > +	ret = toprgu_reset_assert(rcdev, id);
> > +	if (ret)
> > +		return ret;
> > +
> > +	return toprgu_reset_deassert(rcdev, id);
> 
> Unless there is additional synchronization elsewhere, parallel calls
> to the -> assert, and ->reset callbacks may result in the reset being
> deasserted while at least one caller (the one who called the ->assert
> function) believes that it is still asserted.
> 
> [ ... and if there _is_ additional synchronization elsewhere, the
>    local spinlock would be unnecessary ]
> 

I'm not sure if this count as additional synchronization, but you could
get exclusive control to the reset by calling
reset_control_get_exclusive so others won't try to reset the component
while you are using it.

In this case, you still need spinlock because other drivers might trying
to reset their components and they share same register.

Joe.C



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

  reply	other threads:[~2019-10-05  6:07 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-27 10:31 [alsa-devel] [PATCH v2 0/4] ASoC: mt8183: fix audio playback slowly after playback Jiaxin Yu
2019-09-27 10:31 ` Jiaxin Yu
2019-09-27 10:31 ` Jiaxin Yu
2019-09-27 10:31 ` [alsa-devel] [PATCH v2 1/4] dt-bindings: mediatek: mt8183: Add #reset-cells Jiaxin Yu
2019-09-27 10:31   ` Jiaxin Yu
2019-09-27 10:31   ` Jiaxin Yu
2019-09-27 10:31 ` [alsa-devel] [PATCH v2 2/4] watchdog: mtk_wdt: mt8183: Add reset controller Jiaxin Yu
2019-09-27 10:31   ` Jiaxin Yu
2019-09-27 10:31   ` Jiaxin Yu
2019-09-28 17:49   ` [alsa-devel] " Guenter Roeck
2019-09-28 17:49     ` Guenter Roeck
2019-09-28 17:49     ` Guenter Roeck
2019-09-30  8:17     ` [alsa-devel] " Yingjoe Chen
2019-09-30  8:17       ` Yingjoe Chen
2019-09-30  8:17       ` Yingjoe Chen
2019-10-03 13:49   ` [alsa-devel] " Guenter Roeck
2019-10-03 13:49     ` Guenter Roeck
2019-10-03 13:49     ` Guenter Roeck
2019-10-05  5:59     ` Yingjoe Chen [this message]
2019-10-05  5:59       ` Yingjoe Chen
2019-10-05  5:59       ` Yingjoe Chen
2019-10-05 14:46       ` [alsa-devel] " Guenter Roeck
2019-10-05 14:46         ` Guenter Roeck
2019-10-05 14:46         ` Guenter Roeck
2019-10-08 14:08         ` [alsa-devel] " Philipp Zabel
2019-10-08 14:08           ` Philipp Zabel
2019-10-08 14:08           ` Philipp Zabel
2019-10-05  5:50   ` [alsa-devel] " Yingjoe Chen
2019-10-05  5:50     ` Yingjoe Chen
2019-10-05  5:50     ` Yingjoe Chen
2019-09-27 10:31 ` [alsa-devel] [PATCH v2 3/4] dt-bindings: medaitek: mt8183: add property "resets" && "reset-names" Jiaxin Yu
2019-09-27 10:31   ` Jiaxin Yu
2019-09-27 10:31   ` Jiaxin Yu
2019-10-08 12:53   ` [alsa-devel] Applied "dt-bindings: medaitek: mt8183: add property "resets" && "reset-names"" to the asoc tree Mark Brown
2019-10-08 12:53     ` Mark Brown
2019-10-08 12:53     ` Mark Brown
2019-09-27 10:31 ` [alsa-devel] [PATCH v2 4/4] ASoC: mt8183: fix audio playback slowly after playback during bootup Jiaxin Yu
2019-09-27 10:31   ` Jiaxin Yu
2019-09-27 10:31   ` Jiaxin Yu
2019-10-05  6:07   ` [alsa-devel] " Yingjoe Chen
2019-10-05  6:07     ` Yingjoe Chen
2019-10-05  6:07     ` Yingjoe Chen
2019-10-08 12:11   ` [alsa-devel] " Mark Brown
2019-10-08 12:11     ` Mark Brown
2019-10-08 12:53   ` [alsa-devel] Applied "ASoC: mt8183: fix audio playback slowly after playback during bootup" to the asoc tree Mark Brown
2019-10-08 12:53     ` Mark Brown
2019-10-08 12:53     ` Mark Brown

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=1570255179.29077.24.camel@mtksdaap41 \
    --to=yingjoe.chen@mediatek.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=eason.yen@mediatek.com \
    --cc=jiaxin.yu@mediatek.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux@roeck-us.net \
    --cc=mark.rutland@arm.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh+dt@kernel.org \
    --cc=tzungbi@google.com \
    --cc=wim@linux-watchdog.org \
    --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.