From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
broonie@kernel.org, vkoul@kernel.org
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
alsa-devel@alsa-project.org, robh+dt@kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [alsa-devel] [RFC PATCH 6/6] soundwire: qcom: add support for SoundWire controller
Date: Sat, 15 Jun 2019 14:24:25 +0100 [thread overview]
Message-ID: <d3ccd866-7bc5-9635-4bb4-6b0765f89835@linaro.org> (raw)
In-Reply-To: <0e836692-2297-4cb7-d681-76692db78a56@linux.intel.com>
On 11/06/2019 13:21, Pierre-Louis Bossart wrote:
>
>
> On 6/11/19 5:29 AM, Srinivas Kandagatla wrote:
>>
>>
>> On 10/06/2019 15:12, Pierre-Louis Bossart wrote:
>>>>>> +
>>>>>> + if (dev_addr == SDW_BROADCAST_DEV_NUM) {
>>>>>> + ctrl->fifo_status = 0;
>>>>>> + ret = wait_for_completion_timeout(&ctrl->sp_cmd_comp,
>>>>>> + msecs_to_jiffies(TIMEOUT_MS));
>>>>>
>>>>> This is odd. The SoundWire spec does not handle writes to a single
>>>>> device or broadcast writes differently. I don't see a clear reason
>>>>> why you would only timeout for a broadcast write.
>>>>>
>>>>
>>>> There is danger of blocking here without timeout.
>>>
>>> Right, and it's fine to add a timeout. The question is why add a
>>> timeout *only* for a broadcast operation? It should be added for
>>> every transaction IMO, unless you have a reason not to do so.
>>>
>>
>> I did try this before, the issue is when we read/write registers from
>> interrupt handler, these can be deadlocked as we will be interrupt
>> handler waiting for another completion interrupt, which will never
>> happen unless we return from the first interrupt.
>
> I don't quite get the issue. With the Intel hardware we only deal with
> Master registers (some of which mirror the bus state) in the handler and
> will only modify Slave registers in the thread. All changes to Slave
> registers will be subject to a timeout as well as a check for no
> response or NAK. Not sure what is specific about your solution that
> requires a different handling of commands depending on which device
> number is used. It could very well be that you've uncovered a flaw in
> the bus design but I still don't see how it would be Qualcomm-specific?
Sorry It took bit more time for digging up the issue which I faced
previously to answer this query. This is now fixed and v2 patchset has
same handling for all the slave registers read/writes with no special
casing.
Thanks,
srini
next prev parent reply other threads:[~2019-06-15 13:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-07 8:56 [RFC PATCH 0/6] soundwire: Add support to Qualcomm SoundWire master Srinivas Kandagatla
2019-06-07 8:56 ` [RFC PATCH 1/6] ASoC: core: add support to snd_soc_dai_get_sdw_stream() Srinivas Kandagatla
2019-06-08 19:22 ` Cezary Rojewski
2019-06-09 12:16 ` Srinivas Kandagatla
2019-06-10 4:34 ` Vinod Koul
2019-06-10 7:58 ` Srinivas Kandagatla
2019-06-07 8:56 ` [RFC PATCH 2/6] soundwire: Add compute_params callback Srinivas Kandagatla
2019-06-07 8:56 ` [RFC PATCH 3/6] soundwire: core: define SDW_MAX_PORT Srinivas Kandagatla
2019-06-07 12:31 ` [alsa-devel] " Pierre-Louis Bossart
2019-06-08 20:04 ` Cezary Rojewski
2019-06-07 8:56 ` [RFC PATCH 4/6] soundwire: stream: make stream name a const pointer Srinivas Kandagatla
2019-06-07 8:56 ` [RFC PATCH 5/6] dt-bindings: soundwire: add bindings for Qcom controller Srinivas Kandagatla
2019-06-07 12:50 ` [alsa-devel] " Pierre-Louis Bossart
2019-06-09 12:16 ` Srinivas Kandagatla
2019-06-10 4:51 ` Vinod Koul
2019-06-10 8:14 ` Srinivas Kandagatla
2019-06-10 13:58 ` [alsa-devel] " Pierre-Louis Bossart
2019-06-07 8:56 ` [RFC PATCH 6/6] soundwire: qcom: add support for SoundWire controller Srinivas Kandagatla
2019-06-07 13:36 ` [alsa-devel] " Pierre-Louis Bossart
2019-06-09 12:15 ` Srinivas Kandagatla
2019-06-10 14:12 ` Pierre-Louis Bossart
2019-06-11 10:29 ` Srinivas Kandagatla
2019-06-11 12:21 ` Pierre-Louis Bossart
2019-06-15 13:24 ` Srinivas Kandagatla [this message]
2019-06-08 21:53 ` Cezary Rojewski
2019-06-09 12:15 ` Srinivas Kandagatla
2019-06-10 6:40 ` Vinod Koul
2019-06-10 8:27 ` Srinivas Kandagatla
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=d3ccd866-7bc5-9635-4bb4-6b0765f89835@linaro.org \
--to=srinivas.kandagatla@linaro.org \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=robh+dt@kernel.org \
--cc=vkoul@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®