All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qii Wang <qii.wang@mediatek.com>
To: AngeloGioacchino Del Regno  <angelogioacchino.delregno@collabora.com>
Cc: <matthias.bgg@gmail.com>, <linux-i2c@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <wsa@kernel.org>,
	<nfraprado@collabora.com>, <kernel@collabora.com>
Subject: Re: [PATCH v2] i2c: mediatek: Optimize master_xfer() and avoid circular locking
Date: Fri, 22 Apr 2022 08:21:09 +0800	[thread overview]
Message-ID: <c8d6f77aac432e8df33372a95c6242fcdbb35090.camel@mediatek.com> (raw)
In-Reply-To: <20220411132107.136369-1-angelogioacchino.delregno@collabora.com>

On Mon, 2022-04-11 at 15:21 +0200, AngeloGioacchino Del Regno wrote:
> Especially (but not only) during probe, it may happen that multiple
> devices are communicating via i2c (or multiple i2c busses) and
> sometimes while others are probing asynchronously.
> For example, a Cr50 TPM may be filling entropy (or userspace may be
> reading random data) while the rt5682 (i2c) codec driver reads/sets
> some registers, like while getting/setting a clock's rate, which
> happens both during probe and during system operation.
> 
> In this driver, the mtk_i2c_transfer() function (which is the i2c
> .master_xfer() callback) was granularly managing the clocks by
> performing a clk_bulk_prepare_enable() to start them and its inverse.
> This is not only creating possible circular locking dependencies in
> the some cases (like former explanation), but it's also suboptimal,
> as clk_core prepare/unprepare operations are using mutex locking,
> which creates a bit of unwanted overhead (for example, i2c trackpads
> will call master_xfer() every few milliseconds!).
> 
> With this commit, we avoid both the circular locking and additional
> overhead by changing how we handle the clocks in this driver:
> - Prepare the clocks during probe (and PM resume)
> - Enable/disable clocks in mtk_i2c_transfer()
> - Unprepare the clocks only for driver removal (and PM suspend)
> 
> For the sake of providing a full explanation: during probe, the
> clocks are not only prepared but also enabled, as this is needed
> for some hardware initialization but, after that, we are disabling
> but not unpreparing them, leaving an expected state for the
> aforementioned clock handling strategy.
> 
> Signed-off-by: AngeloGioacchino Del Regno <
> angelogioacchino.delregno@collabora.com>
> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Reviewed-by: Qii Wang <qii.wang@mediatek.com>

> ---
> 
> v2: Fixed typos in commit description
> 
>  drivers/i2c/busses/i2c-mt65xx.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> 


WARNING: multiple messages have this Message-ID (diff)
From: Qii Wang <qii.wang@mediatek.com>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: <matthias.bgg@gmail.com>, <linux-i2c@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	 <linux-kernel@vger.kernel.org>, <wsa@kernel.org>,
	<nfraprado@collabora.com>, <kernel@collabora.com>
Subject: Re: [PATCH v2] i2c: mediatek: Optimize master_xfer() and avoid circular locking
Date: Fri, 22 Apr 2022 08:21:09 +0800	[thread overview]
Message-ID: <c8d6f77aac432e8df33372a95c6242fcdbb35090.camel@mediatek.com> (raw)
In-Reply-To: <20220411132107.136369-1-angelogioacchino.delregno@collabora.com>

On Mon, 2022-04-11 at 15:21 +0200, AngeloGioacchino Del Regno wrote:
> Especially (but not only) during probe, it may happen that multiple
> devices are communicating via i2c (or multiple i2c busses) and
> sometimes while others are probing asynchronously.
> For example, a Cr50 TPM may be filling entropy (or userspace may be
> reading random data) while the rt5682 (i2c) codec driver reads/sets
> some registers, like while getting/setting a clock's rate, which
> happens both during probe and during system operation.
> 
> In this driver, the mtk_i2c_transfer() function (which is the i2c
> .master_xfer() callback) was granularly managing the clocks by
> performing a clk_bulk_prepare_enable() to start them and its inverse.
> This is not only creating possible circular locking dependencies in
> the some cases (like former explanation), but it's also suboptimal,
> as clk_core prepare/unprepare operations are using mutex locking,
> which creates a bit of unwanted overhead (for example, i2c trackpads
> will call master_xfer() every few milliseconds!).
> 
> With this commit, we avoid both the circular locking and additional
> overhead by changing how we handle the clocks in this driver:
> - Prepare the clocks during probe (and PM resume)
> - Enable/disable clocks in mtk_i2c_transfer()
> - Unprepare the clocks only for driver removal (and PM suspend)
> 
> For the sake of providing a full explanation: during probe, the
> clocks are not only prepared but also enabled, as this is needed
> for some hardware initialization but, after that, we are disabling
> but not unpreparing them, leaving an expected state for the
> aforementioned clock handling strategy.
> 
> Signed-off-by: AngeloGioacchino Del Regno <
> angelogioacchino.delregno@collabora.com>
> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Reviewed-by: Qii Wang <qii.wang@mediatek.com>

> ---
> 
> v2: Fixed typos in commit description
> 
>  drivers/i2c/busses/i2c-mt65xx.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> 
_______________________________________________
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: Qii Wang <qii.wang@mediatek.com>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: <matthias.bgg@gmail.com>, <linux-i2c@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	 <linux-kernel@vger.kernel.org>, <wsa@kernel.org>,
	<nfraprado@collabora.com>, <kernel@collabora.com>
Subject: Re: [PATCH v2] i2c: mediatek: Optimize master_xfer() and avoid circular locking
Date: Fri, 22 Apr 2022 08:21:09 +0800	[thread overview]
Message-ID: <c8d6f77aac432e8df33372a95c6242fcdbb35090.camel@mediatek.com> (raw)
In-Reply-To: <20220411132107.136369-1-angelogioacchino.delregno@collabora.com>

On Mon, 2022-04-11 at 15:21 +0200, AngeloGioacchino Del Regno wrote:
> Especially (but not only) during probe, it may happen that multiple
> devices are communicating via i2c (or multiple i2c busses) and
> sometimes while others are probing asynchronously.
> For example, a Cr50 TPM may be filling entropy (or userspace may be
> reading random data) while the rt5682 (i2c) codec driver reads/sets
> some registers, like while getting/setting a clock's rate, which
> happens both during probe and during system operation.
> 
> In this driver, the mtk_i2c_transfer() function (which is the i2c
> .master_xfer() callback) was granularly managing the clocks by
> performing a clk_bulk_prepare_enable() to start them and its inverse.
> This is not only creating possible circular locking dependencies in
> the some cases (like former explanation), but it's also suboptimal,
> as clk_core prepare/unprepare operations are using mutex locking,
> which creates a bit of unwanted overhead (for example, i2c trackpads
> will call master_xfer() every few milliseconds!).
> 
> With this commit, we avoid both the circular locking and additional
> overhead by changing how we handle the clocks in this driver:
> - Prepare the clocks during probe (and PM resume)
> - Enable/disable clocks in mtk_i2c_transfer()
> - Unprepare the clocks only for driver removal (and PM suspend)
> 
> For the sake of providing a full explanation: during probe, the
> clocks are not only prepared but also enabled, as this is needed
> for some hardware initialization but, after that, we are disabling
> but not unpreparing them, leaving an expected state for the
> aforementioned clock handling strategy.
> 
> Signed-off-by: AngeloGioacchino Del Regno <
> angelogioacchino.delregno@collabora.com>
> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Reviewed-by: Qii Wang <qii.wang@mediatek.com>

> ---
> 
> v2: Fixed typos in commit description
> 
>  drivers/i2c/busses/i2c-mt65xx.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> 
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2022-04-22  0:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-11 13:21 [PATCH v2] i2c: mediatek: Optimize master_xfer() and avoid circular locking AngeloGioacchino Del Regno
2022-04-11 13:21 ` AngeloGioacchino Del Regno
2022-04-11 13:21 ` AngeloGioacchino Del Regno
2022-04-21 10:53 ` AngeloGioacchino Del Regno
2022-04-21 10:53   ` AngeloGioacchino Del Regno
2022-04-21 10:53   ` AngeloGioacchino Del Regno
2022-04-22  0:21 ` Qii Wang [this message]
2022-04-22  0:21   ` Qii Wang
2022-04-22  0:21   ` Qii Wang
2022-05-04 20:20 ` Wolfram Sang
2022-05-04 20:20   ` Wolfram Sang
2022-05-04 20:20   ` Wolfram Sang

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=c8d6f77aac432e8df33372a95c6242fcdbb35090.camel@mediatek.com \
    --to=qii.wang@mediatek.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=kernel@collabora.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=nfraprado@collabora.com \
    --cc=wsa@kernel.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 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.