On 08-02-16, 14:52, Stephen Boyd wrote:
> Ok the sequence makes sense now that it's clearly explained.
Should I consider it as a Reviewed-by ?
--
viresh
On 08-02-16, 14:52, Stephen Boyd wrote:
> Ok the sequence makes sense now that it's clearly explained. I
> wonder if we should create and destroy OPP tables when a device
> is created and destroyed instead of triggering that from a
> driver. I suppose not creating the tables until they're used is
>
On 02/02, Viresh Kumar wrote:
> On 01-02-16, 18:29, Stephen Boyd wrote:
> > I'm still lost why we need this API. When the OPP is torn down we
> > can call regulator_put there instead. The same style seems to be
> > done for supported hw, and prop_name, which doesn't make any
> > sense either. Just
On 01-02-16, 18:29, Stephen Boyd wrote:
> I'm still lost why we need this API. When the OPP is torn down we
> can call regulator_put there instead. The same style seems to be
> done for supported hw, and prop_name, which doesn't make any
> sense either. Just tear everything down when there aren't a
On 01/28, Viresh Kumar wrote:
> +
> +/**
> + * dev_pm_opp_put_regulator() - Releases resources blocked for regulator
> + * @dev: Device for which regulator was set.
> + *
> + * Locking: The internal device_opp and opp structures are RCU protected.
> + * Hence this function internally uses RCU updat
5 matches
Mail list logo
