On 8 August 2013 00:21, Stephen Warren wrote:
> On 08/07/2013 11:59 AM, Viresh Kumar wrote:
>> On 7 August 2013 23:23, Stephen Warren wrote:
>>> That link only describes why we shouldn't have a dedicated compatible
>>> value for cpufreq. I certainly agree with that. However, I think it's
>>>
On 08/07/2013 11:59 AM, Viresh Kumar wrote:
> On 7 August 2013 23:23, Stephen Warren wrote:
>> That link only describes why we shouldn't have a dedicated compatible
>> value for cpufreq. I certainly agree with that. However, I think it's
>> reasonable that whatever code binds to:
>>
>>
On 7 August 2013 23:23, Stephen Warren wrote:
> That link only describes why we shouldn't have a dedicated compatible
> value for cpufreq. I certainly agree with that. However, I think it's
> reasonable that whatever code binds to:
>
> compatible = "arm,cortex-a9";
>
> ... should
On 08/07/2013 11:49 AM, Viresh Kumar wrote:
> On 7 August 2013 23:16, Stephen Warren wrote:
>> On 08/07/2013 08:46 AM, Viresh Kumar wrote:
>>> cpufreq-cpu0 driver can be probed over DT only if a corresponding device
>>> node is
>>> created for the SoC which wants to use it. Lets create a
On 7 August 2013 23:16, Stephen Warren wrote:
> On 08/07/2013 08:46 AM, Viresh Kumar wrote:
>> cpufreq-cpu0 driver can be probed over DT only if a corresponding device
>> node is
>> created for the SoC which wants to use it. Lets create a platform device for
>> cpufreq-cpu0 driver for Tegra.
>>
On 08/07/2013 08:46 AM, Viresh Kumar wrote:
> cpufreq-cpu0 driver can be probed over DT only if a corresponding device node
> is
> created for the SoC which wants to use it. Lets create a platform device for
> cpufreq-cpu0 driver for Tegra.
>
> Also it removes the Kconfig entry responsible to
cpufreq-cpu0 driver can be probed over DT only if a corresponding device node is
created for the SoC which wants to use it. Lets create a platform device for
cpufreq-cpu0 driver for Tegra.
Also it removes the Kconfig entry responsible to compiling tegra-cpufreq driver
and hence there will not be
cpufreq-cpu0 driver can be probed over DT only if a corresponding device node is
created for the SoC which wants to use it. Lets create a platform device for
cpufreq-cpu0 driver for Tegra.
Also it removes the Kconfig entry responsible to compiling tegra-cpufreq driver
and hence there will not be
On 08/07/2013 08:46 AM, Viresh Kumar wrote:
cpufreq-cpu0 driver can be probed over DT only if a corresponding device node
is
created for the SoC which wants to use it. Lets create a platform device for
cpufreq-cpu0 driver for Tegra.
Also it removes the Kconfig entry responsible to
On 7 August 2013 23:16, Stephen Warren swar...@wwwdotorg.org wrote:
On 08/07/2013 08:46 AM, Viresh Kumar wrote:
cpufreq-cpu0 driver can be probed over DT only if a corresponding device
node is
created for the SoC which wants to use it. Lets create a platform device for
cpufreq-cpu0 driver
On 08/07/2013 11:49 AM, Viresh Kumar wrote:
On 7 August 2013 23:16, Stephen Warren swar...@wwwdotorg.org wrote:
On 08/07/2013 08:46 AM, Viresh Kumar wrote:
cpufreq-cpu0 driver can be probed over DT only if a corresponding device
node is
created for the SoC which wants to use it. Lets create
On 7 August 2013 23:23, Stephen Warren swar...@wwwdotorg.org wrote:
That link only describes why we shouldn't have a dedicated compatible
value for cpufreq. I certainly agree with that. However, I think it's
reasonable that whatever code binds to:
compatible = arm,cortex-a9;
...
On 08/07/2013 11:59 AM, Viresh Kumar wrote:
On 7 August 2013 23:23, Stephen Warren swar...@wwwdotorg.org wrote:
That link only describes why we shouldn't have a dedicated compatible
value for cpufreq. I certainly agree with that. However, I think it's
reasonable that whatever code binds to:
On 8 August 2013 00:21, Stephen Warren swar...@wwwdotorg.org wrote:
On 08/07/2013 11:59 AM, Viresh Kumar wrote:
On 7 August 2013 23:23, Stephen Warren swar...@wwwdotorg.org wrote:
That link only describes why we shouldn't have a dedicated compatible
value for cpufreq. I certainly agree with
14 matches
Mail list logo
