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(+)
--
2.38.4
On Sat, 15 Jul 2023 14:05:57 +0300
George Stark <[email protected]> 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
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 <[email protected]> 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.
--
With Best Regards,
Andy Shevchenko
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 <[email protected]> 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
>
>
--
Best regards
George
On Mon, 17 Jul 2023 13:01:09 +0300
Andy Shevchenko <[email protected]> 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 <[email protected]> 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
On Tue, 18 Jul 2023 10:41:00 +0100
Jonathan Cameron <[email protected]> wrote:
> On Mon, 17 Jul 2023 13:01:09 +0300
> Andy Shevchenko <[email protected]> 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 <[email protected]> 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