On Thu, Apr 13, 2017 at 12:00:36AM +0800, Dong Aisheng wrote:
> It can solve the problem.
> But it breaks some thing and need a further tiny fix.
> I just replied the mail in your patch thread.
> Please check it!
OK, I'll look out for your mail (I've not seen it yet, guess it's got
held up). Tha
On Wed, Apr 12, 2017 at 11:53 PM, Mark Brown wrote:
> On Thu, Apr 13, 2017 at 03:11:01PM +0800, Dong Aisheng wrote:
>
>> You're absolutely right!
>> I did this because there're some where else did the same thing.
>> e.g. drivers/regulator/fixed.c.
>
>> But it's obviously none of any platform speci
On Thu, Apr 13, 2017 at 03:11:01PM +0800, Dong Aisheng wrote:
> You're absolutely right!
> I did this because there're some where else did the same thing.
> e.g. drivers/regulator/fixed.c.
> But it's obviously none of any platform specific and is perfectly
> to be handled in regulator core.
Did
Hi Mark,
On Tue, Apr 11, 2017 at 09:31:24PM +0100, Mark Brown wrote:
> On Wed, Apr 12, 2017 at 09:58:43AM +0800, Dong Aisheng wrote:
> > Mandatorily set the initdata->supply_regulator while it actually not
> > exist will cause regulator core to resolve supply each time whenever
> > a new regulator
On Wed, Apr 12, 2017 at 09:58:43AM +0800, Dong Aisheng wrote:
> Mandatorily set the initdata->supply_regulator while it actually not
> exist will cause regulator core to resolve supply each time whenever
> a new regulator registered which is meaningless and waste CPU mips.
>
> We can observe more
Mandatorily set the initdata->supply_regulator while it actually not
exist will cause regulator core to resolve supply each time whenever
a new regulator registered which is meaningless and waste CPU mips.
We can observe more than one hundred times of iteration of resolving
during a MX6Q SDB board
6 matches
Mail list logo
