Hi!
> And both these doesn't happen in this case. OPP tables can be used
> by any other framework and is more or less a core thing..
>
> Now, with this discussion I have another idea here..
>
> Why don't we build these tables automatically on boot from some core
> code, rather than asking driver
On 15 May 2014 14:16, Chander Kashyap wrote:
> Yes exactly. All users of this API need to be modified to handle
> EEXIST as success.
There are very few:
arch/arm/mach-omap2/opp.c
arch/arm/mach-vexpress/spc.c
drivers/devfreq/exynos/exynos4_bus.c
drivers/devfreq/exynos/exynos5_bus.c
So shouldn't
On 15 May 2014 13:57, Viresh Kumar wrote:
> On 15 May 2014 13:55, Chander Kashyap wrote:
>> Then in that case the caller must take care for two type of errors:
>> -EEXIST and -ENOMEM
>
> Actually, success: (0 or -EEXIST), failure: Anything else.
Yes exactly. All users of this API need to be modi
On 15 May 2014 13:55, Chander Kashyap wrote:
> Then in that case the caller must take care for two type of errors:
> -EEXIST and -ENOMEM
Actually, success: (0 or -EEXIST), failure: Anything else.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
On 14 May 2014 19:57, Nishanth Menon wrote:
> On 05/14/2014 06:08 AM, Viresh Kumar wrote:
>> On 14 May 2014 15:01, Chander Kashyap wrote:
say we do at this point:
if (new_opp->rate == opp->rate) {
dev_err(dev, "%s: attempt to add duplicate OPP entry (rate=%ld)\n",
__func__,
On Thu, May 15, 2014 at 11:31 AM, Viresh Kumar wrote:
> On 15 May 2014 11:16, Inderpal Singh wrote:
>> I think I did not make myself clear.
>
> Probably I was the one who got confused :)
>
>> Devfreq will have its own opp table associated with its own device. It
>> does not uses the opp table of
On 15 May 2014 11:16, Inderpal Singh wrote:
> I think I did not make myself clear.
Probably I was the one who got confused :)
> Devfreq will have its own opp table associated with its own device. It
> does not uses the opp table of cpus.
> Hence there may be need to free the table if driver (at
On Thu, May 15, 2014 at 11:07 AM, Viresh Kumar wrote:
> On 15 May 2014 11:00, Inderpal Singh wrote:
>> On Thu, May 15, 2014 at 10:34 AM, Viresh Kumar
>> wrote:
>>> On 15 May 2014 10:22, Inderpal Singh wrote:
>>>
What i am saying that "what if we are not going to re-use again ? "
>>>
>>> T
On 15 May 2014 11:00, Inderpal Singh wrote:
> On Thu, May 15, 2014 at 10:34 AM, Viresh Kumar
> wrote:
>> On 15 May 2014 10:22, Inderpal Singh wrote:
>>
>>> What i am saying that "what if we are not going to re-use again ? "
>>
>> That's what I said:
>>
>> Yes, it will keep occupying some space
On Thu, May 15, 2014 at 10:34 AM, Viresh Kumar wrote:
> On 15 May 2014 10:22, Inderpal Singh wrote:
>
>> What i am saying that "what if we are not going to re-use again ? "
>
> That's what I said:
>
> Yes, it will keep occupying some space but there is only one instance
> of that per 'cluster' an
On 15 May 2014 10:22, Inderpal Singh wrote:
> What i am saying that "what if we are not going to re-use again ? "
That's what I said:
Yes, it will keep occupying some space but there is only one instance
of that per 'cluster' and is very much affordable instead of building it again..
So, we ma
On Thu, May 15, 2014 at 10:06 AM, Viresh Kumar wrote:
> On 15 May 2014 10:02, Inderpal Singh wrote:
>> I feel freeing of opps are needed at least at the driver unregistration
>> time, like we free cpufreq_table.
>> Otherwise it amounts to memory leak unless we assume that the same driver is
>> go
On 15 May 2014 10:02, Inderpal Singh wrote:
> I feel freeing of opps are needed at least at the driver unregistration
> time, like we free cpufreq_table.
> Otherwise it amounts to memory leak unless we assume that the same driver is
> going to re-register and re-use the same opps.
Its memory leak
On 14 May 2014 20:32, Pavel Machek wrote:
> Hmm. Would it be better to actually delete stale OPPs?
I wouldn't call them stale as dtb isn't going to change after boot
and we will always get the same list again, unless some arch has
added few more after boot.
So, there is no point freeing opp's on
Hi!
> From: Chander Kashyap
>
> It may be possible to unregister and re-register the cpufreq driver.
> One such example is arm big-little IKS cpufreq driver. While
> re-registering the driver, same OPPs may get added again.
Hmm. Would it be better to actually delete stale OPPs?
On 05/14/2014 06:08 AM, Viresh Kumar wrote:
> On 14 May 2014 15:01, Chander Kashyap wrote:
>>> say we do at this point:
>>> if (new_opp->rate == opp->rate) {
>>> dev_err(dev, "%s: attempt to add duplicate OPP entry (rate=%ld)\n",
>>> __func__, new_opp->rate)
>>>kfree(new_opp);
>>> return
On 14 May 2014 15:01, Chander Kashyap wrote:
>> say we do at this point:
>> if (new_opp->rate == opp->rate) {
>> dev_err(dev, "%s: attempt to add duplicate OPP entry (rate=%ld)\n",
>> __func__, new_opp->rate)
>>kfree(new_opp);
>> return -EINVAL;
>> }
>
> Yes this is more cleaner.
> But i
Hi Nishant,
On 13 May 2014 18:53, Nishanth Menon wrote:
> On Tue, May 13, 2014 at 2:41 AM, [Chander Kashyap
> wrote:
>> From: Chander Kashyap
>>
>> It may be possible to unregister and re-register the cpufreq driver.
>> One such example is arm big-little IKS cpufreq driver. While
>> re-register
On 05/13/2014 03:22 AM, Viresh Kumar wrote:
> On 13 May 2014 13:11, [Chander Kashyap wrote:
>
> What happened to your name ? "["
>
>> From: Chander Kashyap
>>
>> It may be possible to unregister and re-register the cpufreq driver.
>> One such example is arm big-little IKS cpufreq driver. While
On Tue, May 13, 2014 at 2:41 AM, [Chander Kashyap
wrote:
> From: Chander Kashyap
>
> It may be possible to unregister and re-register the cpufreq driver.
> One such example is arm big-little IKS cpufreq driver. While
> re-registering the driver, same OPPs may get added again.
>
> This patch detec
On 13/05/14 12:57, Chander Kashyap wrote:
On 13 May 2014 16:35, Viresh Kumar wrote:
On 13 May 2014 16:00, Sudeep Holla wrote:
On Tue, May 13, 2014 at 9:22 AM, Viresh Kumar wrote:
On 13 May 2014 13:11, [Chander Kashyap wrote:
What happened to your name ? "["
From: Chander Kashyap
It
On 13 May 2014 16:35, Viresh Kumar wrote:
> On 13 May 2014 16:00, Sudeep Holla wrote:
>> On Tue, May 13, 2014 at 9:22 AM, Viresh Kumar
>> wrote:
>>> On 13 May 2014 13:11, [Chander Kashyap wrote:
>>>
>>> What happened to your name ? "["
>>>
From: Chander Kashyap
It may be possib
Hi Viresh,
On 13/05/14 12:05, Viresh Kumar wrote:
On 13 May 2014 16:00, Sudeep Holla wrote:
On Tue, May 13, 2014 at 9:22 AM, Viresh Kumar wrote:
On 13 May 2014 13:11, [Chander Kashyap wrote:
What happened to your name ? "["
From: Chander Kashyap
It may be possible to unregister and re-
On 13 May 2014 16:00, Sudeep Holla wrote:
> On Tue, May 13, 2014 at 9:22 AM, Viresh Kumar wrote:
>> On 13 May 2014 13:11, [Chander Kashyap wrote:
>>
>> What happened to your name ? "["
>>
>>> From: Chander Kashyap
>>>
>>> It may be possible to unregister and re-register the cpufreq driver.
>>>
On Tue, May 13, 2014 at 9:22 AM, Viresh Kumar wrote:
> On 13 May 2014 13:11, [Chander Kashyap wrote:
>
> What happened to your name ? "["
>
>> From: Chander Kashyap
>>
>> It may be possible to unregister and re-register the cpufreq driver.
>> One such example is arm big-little IKS cpufreq driver
On 13 May 2014 13:11, [Chander Kashyap wrote:
What happened to your name ? "["
> From: Chander Kashyap
>
> It may be possible to unregister and re-register the cpufreq driver.
> One such example is arm big-little IKS cpufreq driver. While
> re-registering the driver, same OPPs may get added aga
From: Chander Kashyap
It may be possible to unregister and re-register the cpufreq driver.
One such example is arm big-little IKS cpufreq driver. While
re-registering the driver, same OPPs may get added again.
This patch detects the duplicacy and discards them.
Signed-off-by: Chander Kashyap
S
27 matches
Mail list logo
