On Wed, Feb 23, 2011 at 12:16, Vishwanath Sripathy <vishwanath.bs@xxxxxx> wrote:
>
[...]
> > >> +int sr_notifier_control(struct voltagedomain *voltdm, bool enable)
> > >> +{
> > >> + struct omap_sr *sr = _sr_lookup(voltdm);
> > >> + u32 value = 0;
> > >> + if (IS_ERR_OR_NULL(sr)) {
> > >> + pr_warning("%s: sr corresponding to domain not found\n",
> > >> + __func__);
> > >> + return -EINVAL;
> > >> + }
> > >> + if (!sr->autocomp_active)
> > >> + return -EINVAL;
> > > Why you do you return here? Class driver should still be able to place
> > > it's request even if sr is disabled though it will be effective only
> after
> > > sr is enabled.
> >
> > my intents were as following: which useful event would come without SR
> > avs being enabled? what kind of event do you expect with the AVS
> > disabled which is useful for class driver, whose clase init alone was
> > called and not class enable?
> The point I am making here is, why should SR class driver be prevented to
> register for some events when SR is disabled? If it is prevented here,
> then it needs to keep track that the request is denied and needs to make
> the request again when SR is enabled later.
Let me try another way:
a) none of the notifications(SR_NOTIFY_MCUACCUM, SR_NOTIFY_MCUVALID,
SR_NOTIFY_MCUBOUND, SR_NOTIFY_MCUDISACK)
are possible once the SR class is disabled (class1,1.5,2,3) -
essentially coz the SR is expected to be disabled after class->deinit
is called (deinit is called when the autocomp is disabled for the
class driver).
b) class drivers are expected to release all resources once class
deinit is called, essentially meaning that SR module cannot trust to
have a notifier still capable of handling notifications once the
deinit is called.
So I come back to my question - "why does SR class driver need to
enable notification if it was told to be disabled?". Can you
illustrate with an example what I am missing?
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
