public inbox for alsa-devel@alsa-project.org
 help / color / mirror / Atom feed
From: Richard Fitzgerald <rf@opensource.cirrus.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	<broonie@kernel.org>, <cezary.rojewski@intel.com>,
	<peter.ujfalusi@linux.intel.com>,
	<yung-chuan.liao@linux.intel.com>, <kai.vehmanen@linux.intel.com>
Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	patches@opensource.cirrus.com
Subject: Re: [PATCH 08/10] ASoC: cs35l56: Add driver for Cirrus Logic CS35L56
Date: Wed, 22 Feb 2023 11:16:59 +0000	[thread overview]
Message-ID: <0f42c8fa-2c83-8ad0-7668-d7ba1a7dcbe2@opensource.cirrus.com> (raw)
In-Reply-To: <3b8dd6a8-363e-2c38-b1a5-5361fb7bff85@linux.intel.com>

On 21/02/2023 17:58, Pierre-Louis Bossart wrote:
> 
> 
> On 2/21/23 12:18, Richard Fitzgerald wrote:
>> On 21/02/2023 16:45, Pierre-Louis Bossart wrote:
>>>
>>>> +static int cs35l56_sdw_interrupt(struct sdw_slave *peripheral,
>>>> +                 struct sdw_slave_intr_status *status)
>>>> +{
>>>> +    struct cs35l56_private *cs35l56 =
>>>> dev_get_drvdata(&peripheral->dev);
>>>> +
>>>> +    /* SoundWire core holds our pm_runtime when calling this
>>>> function. */
>>>> +
>>>> +    dev_dbg(cs35l56->dev, "int control_port=%#x\n",
>>>> status->control_port);
>>>> +
>>>> +    if ((status->control_port & SDW_SCP_INT1_IMPL_DEF) == 0)
>>>> +        return 0;
>>>> +
>>>> +    /* Prevent host controller suspending before we handle the
>>>> interrupt */
>>>> +    pm_runtime_get_noresume(cs35l56->dev);
>>>
>>> can this happen that the manager suspends in this function?
>>>
>>> Or is this needed because of the queued work which the manager has no
>>> knowledge of?
>>>
>>
>> Because you issue a Bus-Reset when you suspend and clock-stop, if we
>> didn't take our pm_runtime there is a small window of time where we
>> could be reset before we've handled the interrupt. It's unlikely to
>> happen but better to be safe than to rely on autosuspend delays.
> 
> What I meant is that the pm_runtime refcount should be increased prior
> to the SoundWire core using the interrupt_callback.
> 
> So the only window I see is in the second part of in the interrupt
> handling, before the workqueue is scheduled.

Yes, sorry I didn't explain well.
It's because we defer the handling to a workqueue job. It's to prevent
the (small) chance of runtime-suspending and clock-stopping before the
work queue function has had time to process the interrupt.

It only matters because the Intel controller issues a Bus-Reset when
it comes out of clock stop.

>>
>>>> +
>>>> +    /*
>>>> +     * Mask and clear until it has been handled. The read of
>>>> GEN_INT_STAT_1
>>>> +     * is required as per the SoundWire spec for interrupt status bits
>>>> +     * to clear. GEN_INT_MASK_1 masks the _inputs_ to GEN_INT_STAT1.
>>>> +     * None of the interrupts are time-critical so use the
>>>> +     * power-efficient queue.
>>>> +     */
>>>> +    sdw_write_no_pm(peripheral, CS35L56_SDW_GEN_INT_MASK_1, 0);
>>>> +    sdw_read_no_pm(peripheral, CS35L56_SDW_GEN_INT_STAT_1);
>>>> +    sdw_write_no_pm(peripheral, CS35L56_SDW_GEN_INT_STAT_1, 0xFF);
>>>> +    queue_work(system_power_efficient_wq, &cs35l56->sdw_irq_work);
>>>> +
>>>> +    return 0;
>>>> +}
>>>
>>>> +static int __maybe_unused cs35l56_sdw_handle_unattach(struct
>>>> cs35l56_private *cs35l56)
>>>> +{
>>>> +    struct sdw_slave *peripheral = cs35l56->sdw_peripheral;
>>>> +
>>>> +    if (peripheral->unattach_request) {
>>>> +        /* Cannot access registers until master re-attaches. */
>>>
>>> not sure what the comment means, the manager does not attach. did you
>>> mean resume the bus?
>>>
>>
>> If the manager has forced us to reset we can't access the registers
>> until the manager has recovered its state.
> 
> "until the manager restarted the bus and re-enumerated devices" ?
> 

I'll re-word the comment. And also change to "manager".

>>
>>>> +        dev_dbg(cs35l56->dev, "Wait for initialization_complete\n");
>>>> +        if
>>>> (!wait_for_completion_timeout(&peripheral->initialization_complete,
>>>> +                         msecs_to_jiffies(5000))) {
>>>> +            dev_err(cs35l56->dev, "initialization_complete timed
>>>> out\n");
>>>> +            return -ETIMEDOUT;
>>>> +        }
>>>> +
>>>> +        peripheral->unattach_request = 0;
>>>> +
>>>> +        /*
>>>> +         * Don't call regcache_mark_dirty(), we can't be sure that the
>>>> +         * Manager really did issue a Bus Reset.
>>>> +         */
>>>> +    }
>>>> +
>>>> +    return 0;
>>>> +}
>>> ...
>>>
>>>> +static void cs35l56_dsp_work(struct work_struct *work)
>>>> +{
>>>> +    struct cs35l56_private *cs35l56 = container_of(work,
>>>> +                               struct cs35l56_private,
>>>> +                               dsp_work);
>>>> +    unsigned int reg;
>>>> +    unsigned int val;
>>>> +    int ret = 0;
>>>> +
>>>> +    if (!wait_for_completion_timeout(&cs35l56->init_completion,
>>>> +                     msecs_to_jiffies(5000))) {
>>>> +        dev_err(cs35l56->dev, "%s: init_completion timed out\n",
>>>> __func__);
>>>> +        goto complete;
>>>> +    }
>>>> +
>>>> +    if (!cs35l56->init_done || cs35l56->removing)
>>>> +        goto complete;
>>>> +
>>>> +    cs35l56->dsp.part = devm_kasprintf(cs35l56->dev, GFP_KERNEL,
>>>> "cs35l56%s-%02x",
>>>> +                       cs35l56->secured ? "s" : "", cs35l56->rev);
>>>> +
>>>> +    if (!cs35l56->dsp.part)
>>>> +        goto complete;
>>>> +
>>>> +    pm_runtime_get_sync(cs35l56->dev);
>>>
>>> test that this is successful?
>>>
>>
>> Could do. Wasn't really expecting it to fail unless the hardware is
>> already broken.
> 
> it's not supposed to happen indeed, but our CI caught a couple of issues
> over the last two years. Better add a check.
> 

No harm in checking for error.

>>
>>>> +
>>>> +    /*
>>>> +     * Disable SoundWire interrupts to prevent race with IRQ work.
>>>> +     * Setting sdw_irq_no_unmask prevents the handler re-enabling
>>>> +     * the SoundWire interrupt.
>>>> +     */
>>>> +    if (cs35l56->sdw_peripheral) {
>>>> +        cs35l56->sdw_irq_no_unmask = true;
>>>> +        cancel_work_sync(&cs35l56->sdw_irq_work);
>>>> +        sdw_write_no_pm(cs35l56->sdw_peripheral,
>>>> CS35L56_SDW_GEN_INT_MASK_1, 0);
>>>> +        sdw_read_no_pm(cs35l56->sdw_peripheral,
>>>> CS35L56_SDW_GEN_INT_STAT_1);
>>>> +        sdw_write_no_pm(cs35l56->sdw_peripheral,
>>>> CS35L56_SDW_GEN_INT_STAT_1, 0xFF);
>>>> +    }
>>>> +
>>>> +    ret = cs35l56_mbox_send(cs35l56, CS35L56_MBOX_CMD_SHUTDOWN);
>>>> +    if (ret) {
>>>> +        dev_dbg(cs35l56->dev, "%s: CS35L56_MBOX_CMD_SHUTDOWN ret
>>>> %d\n", __func__, ret);
>>>> +        goto err;
>>>> +    }
>>>> +
>>>> +    if (cs35l56->rev < CS35L56_REVID_B0)
>>>> +        reg = CS35L56_DSP1_PM_CUR_STATE_A1;
>>>> +    else
>>>> +        reg = CS35L56_DSP1_PM_CUR_STATE;
>>>> +
>>>> +    ret = regmap_read_poll_timeout(cs35l56->regmap, reg,
>>>> +                       val, (val == CS35L56_HALO_STATE_SHUTDOWN),
>>>> +                       CS35L56_HALO_STATE_POLL_US,
>>>> +                       CS35L56_HALO_STATE_TIMEOUT_US);
>>>> +    if (ret < 0)
>>>> +        dev_err(cs35l56->dev, "Failed to poll PM_CUR_STATE to 1 is
>>>> %d (ret %d)\n",
>>>> +            val, ret);
>>>> +
>>>> +    /* Use wm_adsp to load and apply the firmware patch and
>>>> coefficient files */
>>>> +    ret = wm_adsp_power_up(&cs35l56->dsp);
>>>> +    if (ret) {
>>>> +        dev_dbg(cs35l56->dev, "%s: wm_adsp_power_up ret %d\n",
>>>> __func__, ret);
>>>> +        goto err;
>>>> +    }
>>>> +
>>>> +    if (cs35l56->removing)
>>>> +        goto err;
>>>> +
>>>> +    mutex_lock(&cs35l56->irq_lock);
>>>> +
>>>> +    init_completion(&cs35l56->init_completion);
>>>> +
>>>> +    cs35l56_system_reset(cs35l56);
>>>> +
>>>> +    if (cs35l56->sdw_peripheral) {
>>>> +        if (!wait_for_completion_timeout(&cs35l56->init_completion,
>>>> +                         msecs_to_jiffies(5000))) {
>>>> +            dev_err(cs35l56->dev, "%s: init_completion timed out
>>>> (SDW)\n", __func__);
>>>
>>> shouldn't do the same routine as for a regular pm_runtime resume,
>>> including re-synching regmaps?
>>>
>>
>> Not sure it would help. It's not the same as runtime_resume because
>> we've changed the firmware and rebooted it (the firmware is retained
>> in a runtime_suspend). We need to do some of the first-time init()
>> code again, which we don't need to do in runtime_resume.
>>
>> Also would create a circular dependency between this driver and the
>> cs35l56-sdw driver. (We _could_ call our dev->pm->runtime_resume pointer
>> but that's a bit ugly)
> 
> I wasn't suggesting using a pm_runtime suspend/resume cycle but rather
> use a common helper called from here and from the pm_runtime_resume.
> 
> It's a suggestion only.
> 

It's on my to-do list to see whether this is useful.

Effectively we're re-initializing and the code we want to re-use is what
cs35l56_init() does after it issues SYSTEM_RESET. So cs35l56_init() is
acting as the common code.

We're going to get an update_status() callback when it re-enumerates.
The update_status() calls cs35l56_init() during the first enumeration.
So we are re-using that same code path to call again cs35l56_init() and
repeat the post-SYSTEM_RESET handling.

>>
>>>
>>>> +            goto err_unlock;
>>>> +        }
>>>> +    } else {
>>>> +        if (cs35l56_init(cs35l56))
>>>> +            goto err_unlock;
>>>> +    }
>>>> +
>>>> +    cs35l56->fw_patched = true;
>>>> +
>>>> +err_unlock:
>>>> +    mutex_unlock(&cs35l56->irq_lock);
>>>> +err:
>>>> +    pm_runtime_mark_last_busy(cs35l56->dev);
>>>> +    pm_runtime_put_autosuspend(cs35l56->dev);
>>>> +
>>>> +    /* Re-enable SoundWire interrupts */
>>>> +    if (cs35l56->sdw_peripheral) {
>>>> +        cs35l56->sdw_irq_no_unmask = false;
>>>> +        sdw_write_no_pm(cs35l56->sdw_peripheral,
>>>> CS35L56_SDW_GEN_INT_MASK_1,
>>>> +                CS35L56_SDW_INT_MASK_CODEC_IRQ);
>>>> +    }
>>>> +
>>>> +complete:
>>>> +    complete_all(&cs35l56->dsp_ready_completion);
>>>> +}

  reply	other threads:[~2023-02-22 11:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17 16:14 [PATCH 00/10] ASoC: Initial support for Cirrus Logic CS35L56 Richard Fitzgerald
2023-02-17 16:14 ` [PATCH 01/10] firmware: cs_dsp: Introduce no_core_startstop for self-booting DSPs Richard Fitzgerald
2023-02-17 16:14 ` [PATCH 02/10] ASoC: wm_adsp: Use no_core_startstop to prevent creating preload control Richard Fitzgerald
2023-02-17 16:14 ` [PATCH 03/10] firmware: cs_dsp: Support DSPs that don't require firmware download Richard Fitzgerald
2023-02-17 16:14 ` [PATCH 04/10] ASoC: wm_adsp: " Richard Fitzgerald
2023-02-17 16:14 ` [PATCH 05/10] ASoC: wm_adsp: Expose the DSP boot work actions as wm_adsp_power_up() Richard Fitzgerald
2023-02-17 16:14 ` [PATCH 06/10] ASoC: wm_adsp: Add support for loading bin files without wmfw Richard Fitzgerald
2023-02-17 16:14 ` [PATCH 07/10] ASoC: wm_adsp: Simplify the logging of requested firmware files Richard Fitzgerald
2023-02-17 16:14 ` [PATCH 08/10] ASoC: cs35l56: Add driver for Cirrus Logic CS35L56 Richard Fitzgerald
2023-02-21 16:45   ` Pierre-Louis Bossart
2023-02-21 17:18     ` Richard Fitzgerald
2023-02-21 17:58       ` Pierre-Louis Bossart
2023-02-22 11:16         ` Richard Fitzgerald [this message]
2023-02-17 16:14 ` [PATCH 09/10] ASoC: Intel: sof_sdw: Add support " Richard Fitzgerald
2023-02-21 16:49   ` Pierre-Louis Bossart
2023-02-21 17:32     ` Richard Fitzgerald
2023-02-21 18:03       ` Pierre-Louis Bossart
2023-02-22 11:39         ` Richard Fitzgerald
2023-02-17 16:14 ` [PATCH 10/10] ASoC: Intel: soc-acpi: Add CS35L56 Soundwire to TGL Richard Fitzgerald
2023-02-21 16:52   ` Pierre-Louis Bossart
2023-02-22 11:48     ` Richard Fitzgerald
2023-02-22 14:31       ` Pierre-Louis Bossart

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=0f42c8fa-2c83-8ad0-7668-d7ba1a7dcbe2@opensource.cirrus.com \
    --to=rf@opensource.cirrus.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@opensource.cirrus.com \
    --cc=peter.ujfalusi@linux.intel.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=yung-chuan.liao@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox