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;
Message-ID: <616401a4.1c69fb81.439b9.441f@mx.google.com>
Date:   Mon, 11 Oct 2021 02:19:32 -0700 (PDT)
From:   srinivas.kandagatla@linaro.org
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
To:     unlisted-recipients:; (no To-header on input)
Precedence: bulk


On 08/10/2021 16:30, Mark Brown wrote:
> On Fri, Oct 08, 2021 at 07:37:12PM +0530, Srinivasa Rao Mandadapu wrote:
>> On 9/28/2021 2:01 PM, Srinivas Kandagatla wrote:
> 
>>> In that case you should probably consider using regmap_register_patch()
>>> for corrections to the default registers in sm8250 case.
> 
>> As regmap_register_patch() not working in this use case, updating defaults
>> in probe for sc7280 specific differences.
> 
> In what way is regmap_register_patch() not working?

SM8250 and SC7280 has different register defaults values for few 
(atleast 2 that we are aware of) registers.

Initially we thought regmap_register_patch() would help in this case, 
but later learned that it was designed for completely different usecase 
and this will not update the cache values with the new values from 
reg_sequence passed to regmap_register_patch().

What we want was to be able to reflect that default values in the 
regcaches, so that subsequent writes are not ignored based on incorrect 
cache values.

There are two ways to fix this, one is to come up with a full default 
register list specific to SC7280 or reuse SM8250 defaults with some 
modifications, other option is to update default registers based on 
compatible string before regmap creation. I suggested Srinivasa to use 
the second option as 99% of the defaults match to SM8250.


--srini

>