From: Feng Xiao <xf@rock-chips.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linux@arm.linux.org.uk, heiko@sntech.de, rjw@rjwysocki.net,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, wxt@rock-chips.com, zyw@rock-chips.com,
jay.xu@rock-chips.com, tim.chen@rock-chips.com,
xxx@rock-chips.com, huangtao@rock-chips.com, rjw@rjwysocki.net
Subject: Re: [PATCH v2] cpufreq: rockchip: add driver
Date: Thu, 24 Mar 2016 11:01:40 +0800 [thread overview]
Message-ID: <56F35894.3020106@rock-chips.com> (raw)
In-Reply-To: <20160323044033.GQ5272@vireshk-i7>
hi all,
I found that it could match the cpufreq-dt driver succesfully only
with the following changes.
--- a/arch/arm64/boot/dts/rockchip/rk3366.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3366.dtsi
@@ -139,6 +139,10 @@
};
};
+ cpufreq-dt { //the node name must be cpufreq-dt
+ compatible = "rockchip,cpufreq"; // the compatible
name is insignificant
+ };
+
This was supported by the commit 07e461cd7e73a84f0e3757932b93cc80976fd749
commit 07e461cd7e73a84f0e3757932b93cc80976fd749
Author: Grant Likely <grant.likely@linaro.org>
Date: Wed May 21 15:40:31 2014 +0900
of: Ensure unique names without sacrificing determinism
The way the driver core is implemented, every device using the same bus
type is required to have a unique name because a symlink to each device
is created in the appropriate /sys/bus/*/devices directory, and two
identical names causes a collision.
The current code handles the requirement by using an globally
incremented counter that is appended to the device name. It works, but
it means any change to device registration will change the assigned
numbers. Instead, if we build up the name by using information from the
parent nodes, then it can be guaranteed to be unique without adding a
random number to the end of it.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Cc: Rob Herring <robh@kernel.org>
If so, do I need to continue to add the new cpufreq driver ?
在 2016/3/23 12:40, Viresh Kumar 写道:
> On 23-03-16, 10:18, Feng Xiao wrote:
>> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>> index 14b1f93..1786315 100644
>> --- a/drivers/cpufreq/Kconfig.arm
>> +++ b/drivers/cpufreq/Kconfig.arm
>> @@ -97,6 +97,16 @@ config ARM_OMAP2PLUS_CPUFREQ
>> depends on ARCH_OMAP2PLUS
>> default ARCH_OMAP2PLUS
>>
>> +config ARM_ROCKCHIP_CPUFREQ
>> + tristate "Rockchip CPUfreq driver"
> Since you are allowing it to be built as a module ...
>
>> + depends on ARCH_ROCKCHIP && CPUFREQ_DT
>> + select PM_OPP
>> + help
>> + This adds the CPUFreq driver support for Rockchip SoCs.
>> + The driver will directly use cpufreq-dt driver as backend.
>> +
>> + If in doubt, say N.
>> +++ b/drivers/cpufreq/rockchip-cpufreq.c
>> +static int __init rockchip_cpufreq_driver_init(void)
>> +{
>> + struct platform_device *pdev;
>> + int i;
>> +
>> + for (i = 0; i < ARRAY_SIZE(rockchip_compat); i++) {
>> + if (of_machine_is_compatible(rockchip_compat[i])) {
>> + pdev = platform_device_register_simple("cpufreq-dt",
>> + -1, NULL, 0);
>> + return PTR_ERR_OR_ZERO(pdev);
>> + }
>> + }
>> +
>> + return -ENODEV;
>> +}
>> +module_init(rockchip_cpufreq_driver_init);
> You need a module exit as well to remove the device. Otherwise following
> sequence will give you errors:
>
> insmod rockchip-cpufreq.ko
> rmmod rockchip-cpufreq.ko
> insmod rockchip-cpufreq.ko //Errors on this..
>
> So, either don't allow it to be built as a module or fix the module-exit path.
>
next prev parent reply other threads:[~2016-03-24 3:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-18 12:10 [PATCH] cpufreq: rockchip: add driver Feng Xiao
2016-03-18 12:56 ` Heiko Stübner
2016-03-21 9:50 ` Viresh Kumar
2016-03-21 9:54 ` Heiko Stübner
2016-03-21 9:58 ` Viresh Kumar
2016-03-21 13:24 ` Feng Xiao
2016-03-21 15:13 ` Viresh Kumar
2016-03-21 15:13 ` Heiko Stübner
2016-03-21 15:52 ` Heiko Stübner
2016-03-22 1:28 ` Feng Xiao
2016-03-22 11:57 ` [PATCH v1] " Feng Xiao
2016-03-22 16:07 ` Heiko Stübner
2016-03-23 2:18 ` [PATCH v2] " Feng Xiao
2016-03-23 4:40 ` Viresh Kumar
2016-03-24 3:01 ` Feng Xiao [this message]
2016-03-24 6:43 ` Viresh Kumar
2016-03-24 15:09 ` Finley Xiao
2016-03-25 4:42 ` Viresh Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56F35894.3020106@rock-chips.com \
--to=xf@rock-chips.com \
--cc=heiko@sntech.de \
--cc=huangtao@rock-chips.com \
--cc=jay.xu@rock-chips.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=rjw@rjwysocki.net \
--cc=tim.chen@rock-chips.com \
--cc=viresh.kumar@linaro.org \
--cc=wxt@rock-chips.com \
--cc=xxx@rock-chips.com \
--cc=zyw@rock-chips.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox