[PATCH v2] ASoC: qcom: soundwire: Add support for controlling audio CGCR from HLOS
Add support for controlling soundwire audio CGCR interface using clock framework to make hclk ungating with software. As per new hardware changes, software has to always ungate hclk if soundwire is operational and keep it running. This requirement is for latest LPASS chipsets for RX, TX and WSA path to work.
Signed-off-by: Srinivasa Rao Mandadapu quic_srivasam@quicinc.com --- This patch set depends on: -- Clock driver patches for CGCR reset control support. --- https://patchwork.kernel.org/project/linux-arm-msm/list/?series=638002 --- https://patchwork.kernel.org/project/linux-arm-msm/list/?series=637998
Changes since v1: -- Add audio cgcr reset control in runtime PM resume handler. -- Update dependency list.
drivers/soundwire/qcom.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c index da1ad7e..445e481 100644 --- a/drivers/soundwire/qcom.c +++ b/drivers/soundwire/qcom.c @@ -13,6 +13,7 @@ #include <linux/of_device.h> #include <linux/pm_runtime.h> #include <linux/regmap.h> +#include <linux/reset.h> #include <linux/slab.h> #include <linux/pm_wakeirq.h> #include <linux/slimbus.h> @@ -142,6 +143,7 @@ struct qcom_swrm_ctrl { struct device *dev; struct regmap *regmap; void __iomem *mmio; + struct reset_control *audio_cgcr; #ifdef CONFIG_DEBUG_FS struct dentry *debugfs; #endif @@ -656,6 +658,8 @@ static int qcom_swrm_init(struct qcom_swrm_ctrl *ctrl) val = FIELD_PREP(SWRM_MCP_FRAME_CTRL_BANK_ROW_CTRL_BMSK, ctrl->rows_index); val |= FIELD_PREP(SWRM_MCP_FRAME_CTRL_BANK_COL_CTRL_BMSK, ctrl->cols_index);
+ reset_control_reset(ctrl->audio_cgcr); + ctrl->reg_write(ctrl, SWRM_MCP_FRAME_CTRL_BANK_ADDR(0), val);
/* Enable Auto enumeration */ @@ -1333,6 +1337,10 @@ static int qcom_swrm_probe(struct platform_device *pdev) ctrl->bus.compute_params = &qcom_swrm_compute_params; ctrl->bus.clk_stop_timeout = 300;
+ ctrl->audio_cgcr = devm_reset_control_get_exclusive(dev, "swr_audio_cgcr"); + if (IS_ERR(ctrl->audio_cgcr)) + dev_err(dev, "Failed to get audio_cgcr reset required for soundwire-v1.6.0\n"); + ret = qcom_swrm_get_port_config(ctrl); if (ret) goto err_clk; @@ -1486,6 +1494,8 @@ static int __maybe_unused swrm_runtime_resume(struct device *dev) qcom_swrm_get_device_status(ctrl); sdw_handle_slave_status(&ctrl->bus, ctrl->status); } else { + reset_control_reset(ctrl->audio_cgcr); + ctrl->reg_write(ctrl, SWRM_MCP_BUS_CTRL, SWRM_MCP_BUS_CLK_START); ctrl->reg_write(ctrl, SWRM_INTERRUPT_CLEAR, SWRM_INTERRUPT_STATUS_MASTER_CLASH_DET);
Quoting Srinivasa Rao Mandadapu (2022-05-18 05:42:35)
diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c index da1ad7e..445e481 100644 --- a/drivers/soundwire/qcom.c +++ b/drivers/soundwire/qcom.c @@ -1333,6 +1337,10 @@ static int qcom_swrm_probe(struct platform_device *pdev) ctrl->bus.compute_params = &qcom_swrm_compute_params; ctrl->bus.clk_stop_timeout = 300;
ctrl->audio_cgcr = devm_reset_control_get_exclusive(dev, "swr_audio_cgcr");if (IS_ERR(ctrl->audio_cgcr))dev_err(dev, "Failed to get audio_cgcr reset required for soundwire-v1.6.0\n");
Why is there no return on error here? Is the reset optional?
ret = qcom_swrm_get_port_config(ctrl); if (ret) goto err_clk;
On 5/21/2022 8:43 AM, Stephen Boyd wrote: Thanks for your time Stephen!!!
Quoting Srinivasa Rao Mandadapu (2022-05-18 05:42:35)
diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c index da1ad7e..445e481 100644 --- a/drivers/soundwire/qcom.c +++ b/drivers/soundwire/qcom.c @@ -1333,6 +1337,10 @@ static int qcom_swrm_probe(struct platform_device *pdev) ctrl->bus.compute_params = &qcom_swrm_compute_params; ctrl->bus.clk_stop_timeout = 300;
ctrl->audio_cgcr = devm_reset_control_get_exclusive(dev, "swr_audio_cgcr");if (IS_ERR(ctrl->audio_cgcr))dev_err(dev, "Failed to get audio_cgcr reset required for soundwire-v1.6.0\n");Why is there no return on error here? Is the reset optional?
Yes it's optional. For older platforms this is not required.
ret = qcom_swrm_get_port_config(ctrl); if (ret) goto err_clk;
On Tue, May 24, 2022 at 04:19:47PM +0530, Srinivasa Rao Mandadapu wrote:
On 5/21/2022 8:43 AM, Stephen Boyd wrote: Thanks for your time Stephen!!!
Quoting Srinivasa Rao Mandadapu (2022-05-18 05:42:35)
diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c index da1ad7e..445e481 100644 --- a/drivers/soundwire/qcom.c +++ b/drivers/soundwire/qcom.c @@ -1333,6 +1337,10 @@ static int qcom_swrm_probe(struct platform_device *pdev) ctrl->bus.compute_params = &qcom_swrm_compute_params; ctrl->bus.clk_stop_timeout = 300;
ctrl->audio_cgcr = devm_reset_control_get_exclusive(dev, "swr_audio_cgcr");if (IS_ERR(ctrl->audio_cgcr))dev_err(dev, "Failed to get audio_cgcr reset required for soundwire-v1.6.0\n");Why is there no return on error here? Is the reset optional?
Yes it's optional. For older platforms this is not required.
If it's optional then either there should be no error message, or the error message should only be logged when the version is >= 1.6.0. There are few things worse than a kernel log riddled with misleading error messages.
On 6/1/2022 4:02 AM, Matthias Kaehlcke wrote: Thanks for Your Time Matthias!!!
On Tue, May 24, 2022 at 04:19:47PM +0530, Srinivasa Rao Mandadapu wrote:
On 5/21/2022 8:43 AM, Stephen Boyd wrote: Thanks for your time Stephen!!!
Quoting Srinivasa Rao Mandadapu (2022-05-18 05:42:35)
diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c index da1ad7e..445e481 100644 --- a/drivers/soundwire/qcom.c +++ b/drivers/soundwire/qcom.c @@ -1333,6 +1337,10 @@ static int qcom_swrm_probe(struct platform_device *pdev) ctrl->bus.compute_params = &qcom_swrm_compute_params; ctrl->bus.clk_stop_timeout = 300;
ctrl->audio_cgcr = devm_reset_control_get_exclusive(dev, "swr_audio_cgcr");if (IS_ERR(ctrl->audio_cgcr))dev_err(dev, "Failed to get audio_cgcr reset required for soundwire-v1.6.0\n");Why is there no return on error here? Is the reset optional?
Yes it's optional. For older platforms this is not required.
If it's optional then either there should be no error message, or the error message should only be logged when the version is >= 1.6.0. There are few things worse than a kernel log riddled with misleading error messages.
In that case, it can be done like below. Kindly let me know your opinion on this.
if (ctrl->version >= 0x01060000) { ctrl->audio_cgcr = devm_reset_control_get_exclusive(dev, "swr_audio_cgcr"); if (IS_ERR(ctrl->audio_cgcr)) { dev_err(dev, "Failed to get audio_cgcr reset required for soundwire-v1.6.0\n"); ret = PTR_ERR(ctrl->audio_cgcr); goto err_clk; } }
On 01/06/2022 13:57, Srinivasa Rao Mandadapu wrote:
On 6/1/2022 4:02 AM, Matthias Kaehlcke wrote: Thanks for Your Time Matthias!!!
On Tue, May 24, 2022 at 04:19:47PM +0530, Srinivasa Rao Mandadapu wrote:
On 5/21/2022 8:43 AM, Stephen Boyd wrote: Thanks for your time Stephen!!!
Quoting Srinivasa Rao Mandadapu (2022-05-18 05:42:35)
diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c index da1ad7e..445e481 100644 --- a/drivers/soundwire/qcom.c +++ b/drivers/soundwire/qcom.c @@ -1333,6 +1337,10 @@ static int qcom_swrm_probe(struct platform_device *pdev) ctrl->bus.compute_params = &qcom_swrm_compute_params; ctrl->bus.clk_stop_timeout = 300;
+ ctrl->audio_cgcr = devm_reset_control_get_exclusive(dev, "swr_audio_cgcr"); + if (IS_ERR(ctrl->audio_cgcr)) + dev_err(dev, "Failed to get audio_cgcr reset required for soundwire-v1.6.0\n");
Why is there no return on error here? Is the reset optional?
Yes it's optional. For older platforms this is not required.
If it's optional then either there should be no error message, or the error message should only be logged when the version is >= 1.6.0. There are few things worse than a kernel log riddled with misleading error messages.
In that case, it can be done like below. Kindly let me know your opinion on this.
if (ctrl->version >= 0x01060000) {
This is not true 1.7+ variants do not require anything as such.
Why not add a flag in struct qcom_swrm_data and pass it as part of of_match data specific to this version?
--srini
ctrl->audio_cgcr = devm_reset_control_get_exclusive(dev, "swr_audio_cgcr"); if (IS_ERR(ctrl->audio_cgcr)) { dev_err(dev, "Failed to get audio_cgcr reset required for soundwire-v1.6.0\n"); ret = PTR_ERR(ctrl->audio_cgcr); goto err_clk; } }
On 6/1/2022 6:36 PM, Srinivas Kandagatla wrote: Thanks for Your time Srini!!
On 01/06/2022 13:57, Srinivasa Rao Mandadapu wrote:
On 6/1/2022 4:02 AM, Matthias Kaehlcke wrote: Thanks for Your Time Matthias!!!
On Tue, May 24, 2022 at 04:19:47PM +0530, Srinivasa Rao Mandadapu wrote:
On 5/21/2022 8:43 AM, Stephen Boyd wrote: Thanks for your time Stephen!!!
Quoting Srinivasa Rao Mandadapu (2022-05-18 05:42:35)
diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c index da1ad7e..445e481 100644 --- a/drivers/soundwire/qcom.c +++ b/drivers/soundwire/qcom.c @@ -1333,6 +1337,10 @@ static int qcom_swrm_probe(struct platform_device *pdev) ctrl->bus.compute_params = &qcom_swrm_compute_params; ctrl->bus.clk_stop_timeout = 300;
+ ctrl->audio_cgcr = devm_reset_control_get_exclusive(dev, "swr_audio_cgcr"); + if (IS_ERR(ctrl->audio_cgcr)) + dev_err(dev, "Failed to get audio_cgcr reset required for soundwire-v1.6.0\n");
Why is there no return on error here? Is the reset optional?
Yes it's optional. For older platforms this is not required.
If it's optional then either there should be no error message, or the error message should only be logged when the version is >= 1.6.0. There are few things worse than a kernel log riddled with misleading error messages.
In that case, it can be done like below. Kindly let me know your opinion on this.
if (ctrl->version >= 0x01060000) {
This is not true 1.7+ variants do not require anything as such.
I think it applies for all upcoming versions as Qualcomm Hardware team. Here is the not from HW Team.
*/Issue: /*
HW CTL on AHB interface to SWR/Codec slave is default ON, the AHB clock is ungated for programmable cycles per transaction
(from valid htrans until slave ready or hysteresis count) and therefore hclk is not free-running.
Without a free-running HCLK, interrupt, CMD FIFO, slave status and other similar logic will have functional issues.
SWR has internal clock gating for address accesses but some logic is running on HCLK
*/Fix: /*
Registers to control HW_CTL is accessible via HLOS – so software has to always ungate hclk if soundwire is operational and keep it running
*/CSR: /*
SoundWire TX/RX.WSA :
Register: *LPASS_SWR_TX/RX/WSA_CONFIG_CGCR* | 0xXXXC010
0x3
0x1
*Bits*
*Field Name*
*Access*
*Description*
*Current PoR*
*SW Update*
1
HW_CTL
HW Dynamic Clock Gating Control Register 1: HW Controlled 0: SW Controlled
1
0
0
CLK_ENABLE
Enabling the clock when in SW Controlled Mode 1: Clock Enabled 0: Clock Disabled
1
1
Why not add a flag in struct qcom_swrm_data and pass it as part of of_match data specific to this version?
--srini
ctrl->audio_cgcr = devm_reset_control_get_exclusive(dev, "swr_audio_cgcr"); if (IS_ERR(ctrl->audio_cgcr)) { dev_err(dev, "Failed to get audio_cgcr reset required for soundwire-v1.6.0\n"); ret = PTR_ERR(ctrl->audio_cgcr); goto err_clk; } }
On 01/06/2022 14:15, Srinivasa Rao Mandadapu wrote:
> + ctrl->audio_cgcr = devm_reset_control_get_exclusive(dev, > "swr_audio_cgcr"); > + if (IS_ERR(ctrl->audio_cgcr)) > + dev_err(dev, "Failed to get audio_cgcr reset > required for soundwire-v1.6.0\n"); Why is there no return on error here? Is the reset optional?
Yes it's optional. For older platforms this is not required.
If it's optional then either there should be no error message, or the error message should only be logged when the version is >= 1.6.0. There are few things worse than a kernel log riddled with misleading error messages.
In that case, it can be done like below. Kindly let me know your opinion on this.
if (ctrl->version >= 0x01060000) {
This is not true 1.7+ variants do not require anything as such.
I think it applies for all upcoming versions as Qualcomm Hardware team. Here is the not from HW Team.
Am testing sm8450 which has 1.7.0 and it does not require/have such control.
I dont understand what is the issue in adding a flag to struct qcom_swrm_data.
This should give finer control rather than matching anything > 1.6.
--srini
On Wed, Jun 01, 2022 at 02:42:30PM +0100, Srinivas Kandagatla wrote:
On 01/06/2022 14:15, Srinivasa Rao Mandadapu wrote:
> > + ctrl->audio_cgcr = > > devm_reset_control_get_exclusive(dev, > > "swr_audio_cgcr"); > > + if (IS_ERR(ctrl->audio_cgcr)) > > + dev_err(dev, "Failed to get > > audio_cgcr reset required for > > soundwire-v1.6.0\n"); > Why is there no return on error here? Is the reset optional? Yes it's optional. For older platforms this is not required.
If it's optional then either there should be no error message, or the error message should only be logged when the version is >= 1.6.0. There are few things worse than a kernel log riddled with misleading error messages.
In that case, it can be done like below. Kindly let me know your opinion on this.
if (ctrl->version >= 0x01060000) {
This is not true 1.7+ variants do not require anything as such.
I think it applies for all upcoming versions as Qualcomm Hardware team. Here is the not from HW Team.
Am testing sm8450 which has 1.7.0 and it does not require/have such control.
I dont understand what is the issue in adding a flag to struct qcom_swrm_data.
This should give finer control rather than matching anything > 1.6.
I agree, a flag seems a suitable option.
On Wed, 18 May 2022 18:12:35 +0530, Srinivasa Rao Mandadapu wrote:
Add support for controlling soundwire audio CGCR interface using clock framework to make hclk ungating with software. As per new hardware changes, software has to always ungate hclk if soundwire is operational and keep it running. This requirement is for latest LPASS chipsets for RX, TX and WSA path to work.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: qcom: soundwire: Add support for controlling audio CGCR from HLOS commit: 32882881078bd8f8fae47ff69c102d9e691f5bb9
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
participants (5)
-
Mark Brown -
Matthias Kaehlcke -
Srinivas Kandagatla -
Srinivasa Rao Mandadapu -
Stephen Boyd