| Message ID | 20230715110654.6035-1-gnstark@sberdevices.ru (mailing list archive) |
|---|---|
| Headers | show |
| Series | iio: adc: meson: tune init sequence | expand |
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
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 > >
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.
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
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