Re: [PATCH V2 1/4] soc: mediatek: PMIC wrap: DEW base addr may vary

[John Crispin <blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>]

Hi Henry

>>>> not sure if that is a good idea. the code path and dew register usage
>>>> depends on the slave type. putting the dew registers into the DT will
>>>> only have the effect that we will have 1 array less in the driver but in
>>>> turn will have code to load that exact array back. also it wont be a
>>>> simple array that we store in the DT. but we need to match register
>>>> names to register offsets.
>>>>
>>>> although i agree that putting static data into the DT tends to be a good
>>>> thing i believe in this case it is not really sane.
>>>>
>>>
>>> Actually I wasn't thinking of this. My idea (poor mans solution) would
>>> be to identify the pmic dts node and use the values dependent on this,
>>> rather then on the SoC version.
>>
>> i have that bit already in my series based on code i got from mtk.
>>
>> however even cooler might be to just read the CID register and make an
>> educated decision based on that.
>>
> CID of mt6397/mt6391/mt6323 was 0x0100 => bit[7:0]
> 

Yep, i have a patch here that i will test today that utilizes the CID
register.

>> i'll try to cleanup the patches tomorrow and then post them.
>>
>>>
>>> The premium class solution would be to have the registers definded in
>>> the pmic driver and get them accessed through the pmic-wrapper driver.
>>
>> indeed that would be an option.
> There was a problem, pmic-wrapper driver was needed to probe before pmic
> driver, if DEW address was definded in the pmic driver or stored in pmic
> device tree, how could pmic-wrap driver to get them because pmic driver
> was not initialize yet?
> 

That is exactly what i was wondering about. i can only think of
solutions that would

i have respun the series and will resend it today once i tested it on a
device.

	John