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 <[email protected]>
---
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);
--
2.7.4
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 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 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 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