Hi Eugeniy, From: Eugeniy Paltsev <palt...@synopsys.com> Date: Fri, Apr 12, 2019 at 14:22:33
> Hi Vitor, > > On Mon, 2019-04-08 at 13:25 +0000, Vitor Soares wrote: > > Hi Eugeniy, > > > > From: Eugeniy Paltsev <palt...@synopsys.com> > > Date: Mon, Apr 08, 2019 at 12:40:00 > > > > > Hi Vitor, > > > > > > On Mon, 2019-04-08 at 12:31 +0200, Vitor Soares wrote: > > > > Some custom IP-block connected to ARC AXS10x board need assert and > > > > deassert functions to control reset signal of selected peripherals. > > > > > > > > This patch improve AXS10x reset driver by adding assert and deassert > > > > callbacks. > > > > > > > > > In the AXS10x reset driver only 'reset' callback is intentionally > > > > implemented. > > > > > > AXS10x is FPGA based boards and with our default firmware AXS10x reset > > > > register is implemented as self-deasserted. > > > > I have another reset block connect through AXI. > > > > > Do you have somehow modified AXS10x firmware where reset register is not > > > > self-deasserted? > > > > > > In that case "simple-reset" driver will be suitable for you, I guess. > > > > I will try it. > > > > > Otherwise this implementation is incorrect - there should be no 'assert' > > > for > > > > reset controller with self-deasserted logic. > > > > So the assert and reset callback are mutually exclusive? > > Not actually. > > Adding 'assert' callback is incorrect for exclusive reset controls in > case of self-deasserted reset controller. > It will cause reset_control_assert() to return success for exclusive > reset controls, even though the .assert op failed to leave the reset > line asserted after the function returns. > Sorry I'm not understanding. Can you please explain? What I see in reset_control_assert() when not shared is return -ENOTSUPP. > > [snap] > > > > Best regards, > > Vitor Soares > > > -- > Eugeniy Paltsev Thanks for your feedback. Best regards, Vitor Soares
