On Fri, Apr 21, 2017 at 08:04:19PM -0700, Stephen Boyd wrote:
> On 04/12, Dong Aisheng wrote:
> >
> > Together with the err path handling for each clocks, it does make
> > things a bit ugly.
> >
> > Since we already have regulator_bulk_get accessories, i thought we
> > probably could introduce cl
On 04/12, Dong Aisheng wrote:
>
> Together with the err path handling for each clocks, it does make
> things a bit ugly.
>
> Since we already have regulator_bulk_get accessories, i thought we
> probably could introduce clk_bulk_get as well to handle such case to
> ease the driver owners' life.
>
On Tue, Apr 11, 2017 at 10:01:29AM -0700, Florian Fainelli wrote:
...
> > This is a RFC patch intending to bring up the idea to discuss.
> >
> > Comments are welcome and appreciated!
>
> Thanks a lot for doing this, we have historically done something similar
> on ARCH_BRCMSTB platforms in our do
On 04/11/2017 09:03 PM, Dong Aisheng wrote:
> These helper function allows drivers to get several clk consumers in
> one operation. If any of the clk cannot be acquired then any clks
> that were got will be put before returning to the caller.
>
> The idea firstly came out when i wanted to clean u
These helper function allows drivers to get several clk consumers in
one operation. If any of the clk cannot be acquired then any clks
that were got will be put before returning to the caller.
The idea firstly came out when i wanted to clean up and optimize
imx6q-cpufreq driver which needs to han
5 matches
Mail list logo
