On Tue 08 May 05:26 PDT 2018, kgunda@xxxxxxxxxxxxxx wrote:Ok... Out side auto detection, it is used for information purpose. I think it is
On 2018-05-07 22:51, Bjorn Andersson wrote:[..]
> On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:
> > @@ -220,7 +255,12 @@ static int wled_module_enable(struct wled
> > *wled, int val)
> > WLED3_CTRL_REG_MOD_EN,
> > WLED3_CTRL_REG_MOD_EN_MASK,
> > WLED3_CTRL_REG_MOD_EN_MASK);
> > - return rc;
> > + if (rc < 0)
> > + return rc;
> > +
> > + schedule_delayed_work(&wled->ovp_work, WLED_SOFT_START_DLY_US);
>
> Do you really want to delay the work on disable?
>
> Wouldn't it be better to use a delay worker for the enablement and in
> the disable case you cancel the work and just disable_irq() directly
> here.
>
Sure. Will do it in the next series.
> But more importantly, if this is only related to auto detection, do you
> really want to enable/disable the ovp_irq after you have detected the
> string configuration?
>
Ok. This is used for the genuine OVP detection and for the auto detection as
well.
What is the expected outcome of detecting an OVP condition, outside auto
detection?
Regards,
Bjorn