On Mon, May 18, 2020 at 8:43 PM Jonathan Albrieux <jonathan.albrieux@xxxxxxxxx> wrote: > > On Mon, May 18, 2020 at 07:43:17PM +0300, Andy Shevchenko wrote: > > On Mon, May 18, 2020 at 06:01:20PM +0200, Jonathan Albrieux wrote: > > > On Mon, May 18, 2020 at 05:55:51PM +0300, Andy Shevchenko wrote: > > > > On Mon, May 18, 2020 at 4:38 PM Jonathan Albrieux > > > > <jonathan.albrieux@xxxxxxxxx> wrote: > > > > > > > > > + gpiod_set_value_cansleep(data->reset_gpiod, 1); > > > > > > > > (1) > > > > > > > > ... > > > > > > > > > + /* > > > > > + * If reset pin is provided then will be set to high on power on > > > > > + * and to low on power off according to AK09911 datasheet > > > > > + */ > > > > > > > > Wording is confusing, perhaps you have to use 'asserted / deasserted'. > > > > > > Thank you for the suggestion, I'll be working on rewording as soon as > > > possible. > > > > > > > Btw, in (1) it's also "high" (asserted). I barely understand how it's > > > > supposed to work in all cases? > > > > > > > > > + reset_gpiod = devm_gpiod_get_optional(&client->dev, > > > > > + "reset", GPIOD_OUT_HIGH); > > > > > + if (IS_ERR(reset_gpiod)) > > > > > + return PTR_ERR(reset_gpiod); > > > > > > > > > > I'm sorry but I'm not sure about what you mean by saying all cases. > > > Currently I'm testing this driver on a msm8916 device having AK09911 > > > magnetometer. At the current stage the driver is failing on probe > > > because reset pin is not connected to VID (as datasheet requires in case > > > of pin not being used). In case of reset pin not asserted, register's > > > reset is triggered resulting in empty registers, leading to probe fail. > > > For this reason pin is asserted during power on in order to have > > > informations in registers and deasserted before power off triggering > > > a reset. > > > > > > A workaround that gets AK09911 working on device is by setting the > > > reset pin always high on device tree. This way registers gets reset by > > > a Power On Reset circuit autonomously and reset pin never triggers the > > > reset. > > > > You need to distinguish electrical level from logical (GPIO flag defines > > logical). So, I'm talking about active-high vs. active-low case. > > > > Now I re-read above, and see that here you assert the reset signal. But where > > is desertion? > > Oh I see, I'll try explaining by points the proposed approach: > - reset pin is active low > - during power on gpio is set to 0 so the reset pin is high, thus no reset deasserted > - during power off gpio is set to 1 so the reset pin becomes low, thus resetting asserted > this is a possible solution but maybe there are other ways to achieve that, > do you have suggestions on how to get a better approach for solving this issue? I see now, that at requesting reset you wanted to chip be in reset state (asserted) till driver calls power_on(). Seems everything you done is correct. Just correct terminology, please. -- With Best Regards, Andy Shevchenko
