mbox series

[v1,0/3] iio: adc: meson: tune init sequence

Message ID 20230715110654.6035-1-gnstark@sberdevices.ru
Headers
Series iio: adc: meson: tune init sequence |

Message

George Stark July 15, 2023, 11:05 a.m. UTC 
  This patch is a part of effort to support meson a1 SoC and make meson saradc driver
independent from vendor boot code initialization in common.

Information was taken from vendor kernel 5.4, 4.19 and vendor uboot 2019.
Most of the bits are undocumented at all or it's not said how they affect measuring.

All those bits are already initialized in bl* code and since kernel driver dosn't
rewrite or reset any registers but only changes some bits at init stage everything
works fine.

Test procedure is rather simple - one can change those bits in runtime
(e.g. using devmem) and try to read channels (cat /sys/bus/platform/drivers/meson-saradc/.../iio:device0/*)
changing some of those bits leads to measure procedure errors or abnormal results.
Another test is build meson saradc as module, reset adc by reset bit, reload module
and compare measure results to those got before reset.

George Stark (3):
  iio: adc: meson: init channels 0,1 input muxes
  iio: adc: meson: init internal continuous ring counter
  iio: adc: meson: init voltage control bits

 drivers/iio/adc/meson_saradc.c | 73 ++++++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)

Comments

Jonathan Cameron July 16, 2023, 4:11 p.m. UTC | #1 
On Sat, 15 Jul 2023 14:05:57 +0300
George Stark <gnstark@sberdevices.ru> wrote:

> This patch is a part of effort to support meson a1 SoC and make meson saradc driver
> independent from vendor boot code initialization in common.
> 
> Information was taken from vendor kernel 5.4, 4.19 and vendor uboot 2019.
> Most of the bits are undocumented at all or it's not said how they affect measuring.
> 
> All those bits are already initialized in bl* code and since kernel driver dosn't
> rewrite or reset any registers but only changes some bits at init stage everything
> works fine.
> 
> Test procedure is rather simple - one can change those bits in runtime
> (e.g. using devmem) and try to read channels (cat /sys/bus/platform/drivers/meson-saradc/.../iio:device0/*)
> changing some of those bits leads to measure procedure errors or abnormal results.
> Another test is build meson saradc as module, reset adc by reset bit, reload module
> and compare measure results to those got before reset.
> 
> George Stark (3):
>   iio: adc: meson: init channels 0,1 input muxes
>   iio: adc: meson: init internal continuous ring counter
>   iio: adc: meson: init voltage control bits
> 
>  drivers/iio/adc/meson_saradc.c | 73 ++++++++++++++++++++++++++++++++++
>  1 file changed, 73 insertions(+)
> 
These look fine to me, but I'd like them to sit on list a little while
on off chance anyone else has feedback on them.

Thanks,

Jonathan
George Stark July 17, 2023, 9:41 a.m. UTC | #2 
Hello Jonathan

Thanks for your review

On 7/16/23 19:11, Jonathan Cameron wrote:
> On Sat, 15 Jul 2023 14:05:57 +0300
> George Stark <gnstark@sberdevices.ru> wrote:
> 
>> This patch is a part of effort to support meson a1 SoC and make meson saradc driver
>> independent from vendor boot code initialization in common.
>>
>> Information was taken from vendor kernel 5.4, 4.19 and vendor uboot 2019.
>> Most of the bits are undocumented at all or it's not said how they affect measuring.
>>
>> All those bits are already initialized in bl* code and since kernel driver dosn't
>> rewrite or reset any registers but only changes some bits at init stage everything
>> works fine.
>>
>> Test procedure is rather simple - one can change those bits in runtime
>> (e.g. using devmem) and try to read channels (cat /sys/bus/platform/drivers/meson-saradc/.../iio:device0/*)
>> changing some of those bits leads to measure procedure errors or abnormal results.
>> Another test is build meson saradc as module, reset adc by reset bit, reload module
>> and compare measure results to those got before reset.
>>
>> George Stark (3):
>>    iio: adc: meson: init channels 0,1 input muxes
>>    iio: adc: meson: init internal continuous ring counter
>>    iio: adc: meson: init voltage control bits
>>
>>   drivers/iio/adc/meson_saradc.c | 73 ++++++++++++++++++++++++++++++++++
>>   1 file changed, 73 insertions(+)
>>
> These look fine to me, but I'd like them to sit on list a little while
> on off chance anyone else has feedback on them.

I understand. I'd resend the patches in a week or more if there's no 
feedback.

If someone suggests tests so the community could trust the results I'll 
be happy to run them. I have odroid-c1, vim1, vim3 and a113l board.

> 
> Thanks,
> 
> Jonathan
> 
>
Andy Shevchenko July 17, 2023, 10:01 a.m. UTC | #3 
On Mon, Jul 17, 2023 at 12:41:29PM +0300, George Stark wrote:
> On 7/16/23 19:11, Jonathan Cameron wrote:
> > On Sat, 15 Jul 2023 14:05:57 +0300
> > George Stark <gnstark@sberdevices.ru> wrote:

...

> > These look fine to me, but I'd like them to sit on list a little while
> > on off chance anyone else has feedback on them.
> 
> I understand. I'd resend the patches in a week or more if there's no
> feedback.

There is no need to resend as long as they are available via lore.kernel.org
mail archives.
Jonathan Cameron July 18, 2023, 9:41 a.m. UTC | #4 
On Mon, 17 Jul 2023 13:01:09 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Mon, Jul 17, 2023 at 12:41:29PM +0300, George Stark wrote:
> > On 7/16/23 19:11, Jonathan Cameron wrote:  
> > > On Sat, 15 Jul 2023 14:05:57 +0300
> > > George Stark <gnstark@sberdevices.ru> wrote:  
> 
> ...
> 
> > > These look fine to me, but I'd like them to sit on list a little while
> > > on off chance anyone else has feedback on them.  
> > 
> > I understand. I'd resend the patches in a week or more if there's no
> > feedback.  
> 
> There is no need to resend as long as they are available via lore.kernel.org
> mail archives.
> 

FYI, I track using patchwork.kernel.org so rarely drop a patch set down the back of the
sofa any more...

Jonathan
Jonathan Cameron July 22, 2023, 4:59 p.m. UTC | #5 
On Tue, 18 Jul 2023 10:41:00 +0100
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:

> On Mon, 17 Jul 2023 13:01:09 +0300
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> 
> > On Mon, Jul 17, 2023 at 12:41:29PM +0300, George Stark wrote:  
> > > On 7/16/23 19:11, Jonathan Cameron wrote:    
> > > > On Sat, 15 Jul 2023 14:05:57 +0300
> > > > George Stark <gnstark@sberdevices.ru> wrote:    
> > 
> > ...
> >   
> > > > These look fine to me, but I'd like them to sit on list a little while
> > > > on off chance anyone else has feedback on them.    
> > > 
> > > I understand. I'd resend the patches in a week or more if there's no
> > > feedback.    
> > 
> > There is no need to resend as long as they are available via lore.kernel.org
> > mail archives.
> >   
> 
> FYI, I track using patchwork.kernel.org so rarely drop a patch set down the back of the
> sofa any more...
> 
> Jonathan

Long enough.  Applied to the togreg branch of iio.git and pushed out as testing
for 0-day to see if we missed anything.

Thanks,

Jonathan