mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®