[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170816063431.GB24299@vireshk-i7>
Date: Wed, 16 Aug 2017 12:04:31 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Leonard Crestez <leonard.crestez@....com>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <kernel@...gutronix.de>,
Fabio Estevam <fabio.estevam@....com>
Cc: linux-pm@...r.kernel.org,
Vincent Guittot <vincent.guittot@...aro.org>,
linux@...inikbrodowski.net, linux-kernel@...r.kernel.org,
Rafael Wysocki <rjw@...ysocki.net>
Subject: Re: [PATCH V3 3/9] cpufreq: Cap the default transition delay value
to 10 ms
On 28-07-17, 10:58, Viresh Kumar wrote:
> At this point I really feel that this is a hardware specific problem
> and it was working by chance until now. And I am not sure if we
> shouldn't be stopping this patch from getting merged just because of
> that.
>
> At least you can teach your distribution to go increase the sampling
> rate from userspace to make it all work.
Its been 3 weeks since my last email on this thread and no reply yet
from any of the IMX maintainers. Can someone please help here ?
@Shawn: Can you help debugging a bit here, to see what's get screwed
up due to this commit ? Its just that your platform isn't able to
change freq at 10 ms rate.
@Rafael: I am not sure, but should we be stopping this patch because
some hardware isn't able to change freq at 10ms interval and is just
faking the transition delay to start with ?
Maybe we get this merged again and the IMX guys can figure out what's
wrong on their platform and how to fix it ?
--
viresh
Powered by blists - more mailing lists