Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: srivasam=codeaurora.org@mg.codeaurora.org
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 72E11C433C6
Subject: Re: [PATCH v4 1/2] Partially revert ASoC: qcom: Fix enabling BCLK and
 LRCLK in LPAIF invalid state
To:     Mark Brown <broonie@kernel.org>
Cc:     agross@kernel.org, bjorn.andersson@linaro.org, lgirdwood@gmail.com,
        robh+dt@kernel.org, plai@codeaurora.org, bgoswami@codeaurora.org,
        perex@perex.cz, tiwai@suse.com, srinivas.kandagatla@linaro.org,
        rohitkr@codeaurora.org, linux-arm-msm@vger.kernel.org,
        alsa-devel@alsa-project.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        V Sujith Kumar Reddy <vsujithk@codeaurora.org>
References: <1606539559-4277-1-git-send-email-srivasam@codeaurora.org>
 <1606539559-4277-2-git-send-email-srivasam@codeaurora.org>
 <20201130124617.GC4756@sirena.org.uk>
 <966993b7-4720-bdd2-cf4d-cf5a7c11a0c1@codeaurora.org>
 <20201201175135.GO5239@sirena.org.uk>
From:   Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
Organization: Qualcomm India Private Limited.
Message-ID: <89456f01-aa02-7a7d-a47b-bf1f26e66d4c@codeaurora.org>
Date:   Mon, 14 Dec 2020 18:13:22 +0530
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <20201201175135.GO5239@sirena.org.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Precedence: bulk

Thanks Mark for Your time!!!

On 12/1/2020 11:21 PM, Mark Brown wrote:
> On Tue, Dec 01, 2020 at 11:01:21PM +0530, Srinivasa Rao Mandadapu wrote:
>> On 11/30/2020 6:16 PM, Mark Brown wrote:
>>> Part of this commit message says that the problem was making the registers
>>> non-volatile but both the change and the rest of the commit message say
>>> that the issue was that the registers were made volatile.  I'm also
>>> still unclear as to what the issue is either way - how does reading the
>>> state of the registers from the hardware instead of the cache affect
>>> things?
>> Initial problem was, during playback if device suspended, I2S and DMA
>> control registers
>> are getting reset and unable to recover playback after resume.
>> As these registers were non volatile registers, driver is not getting actual
>> register value
>> and unable to report error state to application. Due to this application
>> keeps on polling for HW current pointer state and not exited from PCM
>> running state.
>> Later from review comments by Srinivas kandagatla, I got to know
>>
>> about regcache sync APIs, which can be used? to sync cache after resume and
>>
>> HW registers can be updated with? original values. With that playback can be
>> continued.
>>
>> So is the reason, I am reverting partial changes in the commit b1824968221c.
> I don't understand why a fix for the register cache not being in sync
> with the hardware doesn't involve syncing the register cache with the
> hardware.

I am sorry I couldn't understand your point. Could you please elaborate 
your query?

Actually I posted V5 version based on review comments.

-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.