- 09 9月, 2014 3 次提交
-
-
由 Viresh Kumar 提交于
Currently, we defer probe if regulator_get() returned -EPROBE_DEFER, i.e. regulator isn't registered yet. We do a dev_err() in this case. Sending a message to the log on probe defer just duplicates what the driver core is already doing. Convert it to dev_dbg() instead. We should defer in case of clk_get() as well. Current code already does it, but it wasn't intentional probably. Its just that we are returning the right error with wrong print message. Fix print message to convey right error. Tested-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Viresh Kumar 提交于
CPU clk is not optional for this driver and probe would fail if it couldn't find a suitable clock. And so, while calling clk_put() we don't need to validate clocks. Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Viresh Kumar 提交于
Two people are maintaining it now, Viresh and Shawn. Add Viresh's details in MODULE_AUTHOR() and copyright section. Suggested-by: NShawn Guo <shawn.guo@linaro.org> Tested-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 07 8月, 2014 1 次提交
-
-
由 Markus Pargmann 提交于
-EPROBE_DEFER is no real error. We are just waiting unti the necessary components are ready. The driver core infrastructure will also print an appropriate info message. This patch changes the error message to a debug message. Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 16 7月, 2014 1 次提交
-
-
由 Viresh Kumar 提交于
OPPs can be populated statically, via DT, or added at run time with dev_pm_opp_add(). While this driver handles the first case correctly, it would fail to populate OPPs added at runtime. Because call to of_init_opp_table() would fail as there are no OPPs in DT and probe will return early. To fix this, remove error checking and call dev_pm_opp_init_cpufreq_table() unconditionally. Update bindings as well. Suggested-by: NStephen Boyd <sboyd@codeaurora.org> Tested-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 10 6月, 2014 1 次提交
-
-
由 Viresh Kumar 提交于
Sometimes boot loaders set CPU frequency to a value outside of frequency table present with cpufreq core. In such cases CPU might be unstable if it has to run on that frequency for long duration of time and so its better to set it to a frequency which is specified in frequency table. Sachin recently found this problem with cpufreq-cpu0 driver when he was testing it for Exynos. Set this flag for cpufreq-cpu0 driver. Reported-and-tested-by: NSachin Kamat <sachin.kamat@linaro.org> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 20 5月, 2014 1 次提交
-
-
由 Lucas Stach 提交于
This driver is using devres managed calls incorrectly, giving the cpu0 device as first parameter instead of the cpufreq platform device. This results in resources not being freed if the cpufreq platform device is unbound, for example if probing has to be deferred for a missing regulator. Signed-off-by: NLucas Stach <l.stach@pengutronix.de> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Cc: 3.9+ <stable@vger.kernel.org> # 3.9+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 12 3月, 2014 1 次提交
-
-
由 Viresh Kumar 提交于
cpufreq_generic_exit() is empty now and can be deleted. Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 17 1月, 2014 1 次提交
-
-
由 Viresh Kumar 提交于
CPUFreq drivers that use clock frameworks interface,i.e. clk_get_rate(), to get CPUs clk rate, have similar sort of code used in most of them. This patch adds a generic ->get() which will do the same thing for them. All those drivers are required to now is to set .get to cpufreq_generic_get() and set their clk pointer in policy->clk during ->init(). Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: NShawn Guo <shawn.guo@linaro.org> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NShawn Guo <shawn.guo@linaro.org> Acked-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 07 12月, 2013 1 次提交
-
-
由 Paul Walmsley 提交于
Treat both negative and zero return values from clk_round_rate() as errors. This is needed since subsequent patches will convert clk_round_rate()'s return value to be an unsigned type, rather than a signed type, since some clock sources can generate rates higher than (2^31)-1 Hz. Eventually, when calling clk_round_rate(), only a return value of zero will be considered a error. All other values will be considered valid rates. The comparison against values less than 0 is kept to preserve the correct behavior in the meantime. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 04 12月, 2013 1 次提交
-
-
由 Eduardo Valentin 提交于
This patch changes the cpufreq-cpu0 driver to consider if a cpu needs cooling (with cpufreq). In case the cooling is needed, the cpu0 device tree node needs to be properly configured with cooling device properties. In case these properties are present,, the driver will load a cpufreq cooling device in the system. The cpufreq-cpu0 driver is not interested in determining how the system should be using the cooling device. The driver is responsible only of loading the cooling device. Describing how the cooling device will be used can be accomplished by setting up a thermal zone that references and is composed by the cpufreq cooling device. Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <rob.herring@calxeda.com> Cc: cpufreq@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NEduardo Valentin <eduardo.valentin@ti.com>
-
- 31 10月, 2013 1 次提交
-
-
由 Viresh Kumar 提交于
Most of the drivers do following in their ->target_index() routines: struct cpufreq_freqs freqs; freqs.old = old freq... freqs.new = new freq... cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE); /* Change rate here */ cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE); This is replicated over all cpufreq drivers today and there doesn't exists a good enough reason why this shouldn't be moved to cpufreq core instead. There are few special cases though, like exynos5440, which doesn't do everything on the call to ->target_index() routine and call some kind of bottom halves for doing this work, work/tasklet/etc.. They may continue doing notification from their own code as flag: CPUFREQ_ASYNC_NOTIFICATION is already set for them. All drivers are also modified in this patch to avoid breaking 'git bisect', as double notification would happen otherwise. Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: NJesper Nilsson <jesper.nilsson@axis.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NRussell King <linux@arm.linux.org.uk> Acked-by: NStephen Warren <swarren@nvidia.com> Tested-by: NAndrew Lunn <andrew@lunn.ch> Tested-by: NNicolas Pitre <nicolas.pitre@linaro.org> Reviewed-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 26 10月, 2013 4 次提交
-
-
由 Viresh Kumar 提交于
Currently, the prototype of cpufreq_drivers target routines is: int target(struct cpufreq_policy *policy, unsigned int target_freq, unsigned int relation); And most of the drivers call cpufreq_frequency_table_target() to get a valid index of their frequency table which is closest to the target_freq. And they don't use target_freq and relation after that. So, it makes sense to just do this work in cpufreq core before calling cpufreq_frequency_table_target() and simply pass index instead. But this can be done only with drivers which expose their frequency table with cpufreq core. For others we need to stick with the old prototype of target() until those drivers are converted to expose frequency tables. This patch implements the new light weight prototype for target_index() routine. It looks like this: int target_index(struct cpufreq_policy *policy, unsigned int index); CPUFreq core will call cpufreq_frequency_table_target() before calling this routine and pass index to it. Because CPUFreq core now requires to call routines present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time. This also marks target() interface as deprecated. So, that new drivers avoid using it. And Documentation is updated accordingly. It also converts existing .target() to newly defined light weight .target_index() routine for many driver. Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: NJesper Nilsson <jesper.nilsson@axis.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NRussell King <linux@arm.linux.org.uk> Acked-by: NDavid S. Miller <davem@davemloft.net> Tested-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rjw@rjwysocki.net>
-
由 Nishanth Menon 提交于
Since Operating Performance Points (OPP) functions are specific to device specific power management, be specific and rename opp.h to pm_opp.h Reported-by: NRandy Dunlap <rdunlap@infradead.org> Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Nishanth Menon 提交于
Since Operating Performance Points (OPP) data structures are specific to device specific power management, be specific and rename opp_* data structures in OPP library with dev_pm_opp_* equivalent. Affected structures are: struct opp enum opp_event Minor checkpatch warning resulting of this change was fixed as well. Reported-by: NRandy Dunlap <rdunlap@infradead.org> Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Nishanth Menon 提交于
Since Operating Performance Points (OPP) functions are specific to device specific power management, be specific and rename opp_* accessors in OPP library with dev_pm_opp_* equivalent. Affected functions are: opp_get_voltage opp_get_freq opp_get_opp_count opp_find_freq_exact opp_find_freq_floor opp_find_freq_ceil opp_add opp_enable opp_disable opp_get_notifier opp_init_cpufreq_table opp_free_cpufreq_table Reported-by: NRandy Dunlap <rdunlap@infradead.org> Signed-off-by: NNishanth Menon <nm@ti.com> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 16 10月, 2013 3 次提交
-
-
由 Viresh Kumar 提交于
Use generic cpufreq_generic_init() routine instead of replicating the same code here. Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Viresh Kumar 提交于
Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Viresh Kumar 提交于
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines and .attr. So its better if we have generic routines for them which can be used by cpufreq drivers then. This patch uses these generic routines in the cpufreq-cpu0 driver. Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 01 10月, 2013 2 次提交
-
-
由 Viresh Kumar 提交于
Lets use cpufreq_table_validate_and_show() instead of calling cpufreq_frequency_table_cpuinfo() and cpufreq_frequency_table_get_attr(). Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Philipp Zabel 提交于
Since the patch "cpufreq: cpufreq-cpu0: NULL is a valid regulator", cpu_reg contains an error value if the regulator is not set, instead of NULL. Accordingly, fix the remaining check for non-NULL cpu_reg. Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 19 9月, 2013 1 次提交
-
-
由 Sudeep KarkadaNagesha 提交于
Commit f837a9b5 "cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes" assumed the pdev->dev is set to cpu0 device in the platform code. But it actually points to the virtual cpufreq-cpu0 platform device which is not present in the device tree. Most of the information needed by cpufreq is stored in cpu0 DT node. So cpu_dev must point to cpu0 device. This patch fixes the wrong assignment to cpu_dev. Reported-and-tested-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de> Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: NSudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 21 8月, 2013 1 次提交
-
-
由 Sudeep KarkadaNagesha 提交于
Now that the cpu device registration initialises the of_node(if available) appropriately for all the cpus, parsing here is redundant. This patch removes all DT parsing and uses cpu->of_node instead. Acked-by: NShawn Guo <shawn.guo@linaro.org> Acked-by: NRob Herring <rob.herring@calxeda.com> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NSudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
-
- 15 8月, 2013 1 次提交
-
-
由 Mark Brown 提交于
Since NULL could in theory be a valid regulator we ought to check for IS_ERR() rather than for NULL. In practice this is unlikely to be an issue but it's better for neatness. Signed-off-by: NMark Brown <broonie@linaro.org> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 14 8月, 2013 1 次提交
-
-
由 Mark Brown 提交于
Since the cpufreq-cpu0 driver is capable of coping without a software controllable regulator and would be confused by a dummy one it should use devm_regulator_get_optional() to ensure no dummy is provided. Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 05 6月, 2013 1 次提交
-
-
由 Guennadi Liakhovetski 提交于
clk_set_rate() isn't supposed to accept approximate frequencies, instead a supported frequency should be obtained from clk_round_rate() and then used to set the clock. Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by: NShawn Guo <shawn.guo@linaro.org> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 12 5月, 2013 2 次提交
-
-
由 Viresh Kumar 提交于
We are freeing parent node in success cases but not in failure cases. Let's do it. Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Nishanth Menon 提交于
With commit 1e4b545c, regulator_get will now return -EPROBE_DEFER when the cpu0-supply node is present, but the regulator is not yet registered. It is possible for this to occur when the regulator registration by itself might be defered due to some dependent interface not yet instantiated. For example: an regulator which uses I2C and GPIO might need both systems available before proceeding, in this case, the regulator might defer it's registration. However, the cpufreq-cpu0 driver assumes that any un-successful return result is equivalent of failure. When the regulator_get returns failure other than -EPROBE_DEFER, it makes sense to assume that supply node is not present and proceed with the assumption that only clock control is necessary in the platform. With this change, we can now handle the following conditions: a) cpu0-supply binding is not present, regulator_get will return appropriate error result, resulting in cpufreq-cpu0 driver controlling just the clock. b) cpu0-supply binding is present, regulator_get returns -EPROBE_DEFER, we retry resulting in cpufreq-cpu0 driver registering later once the regulator is available. c) cpu0-supply binding is present, regulator_get returns -EPROBE_DEFER, however, regulator never registers, we retry until cpufreq-cpu0 driver fails to register pointing at device tree information bug. However, in this case, the fact that cpufreq-cpu0 operates with clock only when the DT binding clearly indicates need of a supply is a bug of it's own. d) cpu0-supply gets an regulator at probe - cpufreq-cpu0 driver controls both the clock and regulator Signed-off-by: NNishanth Menon <nm@ti.com> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 22 4月, 2013 1 次提交
-
-
由 Viresh Kumar 提交于
Parent node must be put after using it to balance its usage count. This was missing in cpufreq-cpu0 driver. Fix it. Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 02 4月, 2013 4 次提交
-
-
由 Viresh Kumar 提交于
policy->cpus contains all online cpus that have single shared clock line. And their frequencies are always updated together. Many SMP system's cpufreq drivers take care of this in individual drivers but the best place for this code is in cpufreq core. This patch modifies cpufreq_notify_transition() to notify frequency change for all cpus in policy->cpus and hence updates all users of this API. Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Acked-by: NStephen Warren <swarren@nvidia.com> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Viresh Kumar 提交于
Currently we are simply returning from target() if we encounter some error after broadcasting CPUFREQ_PRECHANGE notifier. Which looks to be wrong as others might depend on POSTCHANGE notifier for their functioning. So, better broadcast CPUFREQ_POSTCHANGE notifier for these failure cases too, but with old frequency. Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Viresh Kumar 提交于
It is not possible for init() to be called for any cpu other than cpu0. During bootup whatever cpu is used to boot system will be assigned as cpu0. And later on policy->cpu can only change if we hotunplug all cpus first and then hotplug them back in different order, which isn't possible (system requires atleast one cpu to be up always :)). Though I can see one situation where policy->cpu can be different then zero. - Hot-unplug cpu 0. - rmmod cpufreq-cpu0 module - insmod it back - hotplug cpu 0 again. Here, policy->cpu would be different. But the driver doesn't have any dependency on cpu0 as such. We don't mind which cpu of a system is policy->cpu and so this check is just not required. Remove it. Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Paolo Pisati 提交于
Check for the presence of the '/cpus' OF node before dereferencing it blindly: [ 4.181793] Unable to handle kernel NULL pointer dereference at virtual address 0000001c [ 4.181793] pgd = c0004000 [ 4.181823] [0000001c] *pgd=00000000 [ 4.181823] Internal error: Oops: 5 [#1] SMP ARM [ 4.181823] Modules linked in: [ 4.181823] CPU: 1 Tainted: G W (3.8.0-15-generic #25~hbankD) [ 4.181854] PC is at of_get_next_child+0x64/0x70 [ 4.181854] LR is at of_get_next_child+0x24/0x70 [ 4.181854] pc : [<c04fda18>] lr : [<c04fd9d8>] psr: 60000113 [ 4.181854] sp : ed891ec0 ip : ed891ec0 fp : ed891ed4 [ 4.181884] r10: c04dafd0 r9 : c098690c r8 : c0936208 [ 4.181884] r7 : ed890000 r6 : c0a63d00 r5 : 00000000 r4 : 00000000 [ 4.181884] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : c0b2acc8 [ 4.181884] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 4.181884] Control: 10c5387d Table: adcb804a DAC: 00000015 [ 4.181915] Process swapper/0 (pid: 1, stack limit = 0xed890238) [ 4.181915] Stack: (0xed891ec0 to 0xed892000) [ 4.181915] 1ec0: c09b7b70 00000007 ed891efc ed891ed8 c04daff4 c04fd9c0 00000000 c09b7b70 [ 4.181915] 1ee0: 00000007 c0a63d00 ed890000 c0936208 ed891f54 ed891f00 c00088e0 c04dafdc [ 4.181945] 1f00: ed891f54 ed891f10 c006e940 00000000 00000000 00000007 00000007 c08a4914 [ 4.181945] 1f20: 00000000 c07dbd30 c0a63d00 c09b7b70 00000007 c0a63d00 000000bc c0936208 [ 4.181945] 1f40: c098690c c0986914 ed891f94 ed891f58 c0936a40 c00087bc 00000007 00000007 [ 4.181976] 1f60: c0936208 be8bda20 b6eea010 c0a63d00 c064547c 00000000 00000000 00000000 [ 4.181976] 1f80: 00000000 00000000 ed891fac ed891f98 c0645498 c09368c8 00000000 00000000 [ 4.181976] 1fa0: 00000000 ed891fb0 c0014658 c0645488 00000000 00000000 00000000 00000000 [ 4.182006] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 4.182006] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 4.182037] [<c04fda18>] (of_get_next_child+0x64/0x70) from [<c04daff4>] (cpu0_cpufreq_driver_init+0x24/0x284) [ 4.182067] [<c04daff4>] (cpu0_cpufreq_driver_init+0x24/0x284) from [<c00088e0>] (do_one_initcall+0x130/0x1b0) [ 4.182067] [<c00088e0>] (do_one_initcall+0x130/0x1b0) from [<c0936a40>] (kernel_init_freeable+0x184/0x24c) [ 4.182098] [<c0936a40>] (kernel_init_freeable+0x184/0x24c) from [<c0645498>] (kernel_init+0x1c/0xf4) [ 4.182128] [<c0645498>] (kernel_init+0x1c/0xf4) from [<c0014658>] (ret_from_fork+0x14/0x20) [ 4.182128] Code: f57ff04f e320f004 e89da830 e89da830 (e595001c) [ 4.182128] ---[ end trace 634903a22e8609cb ]--- [ 4.182189] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 4.182189] [ 4.642395] CPU0: stopping [rjw: Changelog] Signed-off-by: NPaolo Pisati <paolo.pisati@canonical.com> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 01 4月, 2013 1 次提交
-
-
由 jhbird.choi@samsung.com 提交于
clk_round_rate() returns singed value which was assigned to an unsigned variable. So it can't be checked for negative. Signed-off-by: NJonghwan Choi <jhbird.choi@samsung.com> Acked-by: NShawn Guo <shawn.guo@linaro.org> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 02 2月, 2013 3 次提交
-
-
由 Viresh Kumar 提交于
policy->shared_type field was added only for SoCs with ACPI support: commit 3b2d9942 Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Date: Wed Dec 14 15:05:00 2005 -0500 P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Many non-ACPI systems are filling this field by mistake, which makes its usage confusing. Lets clean it. Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Shawn Guo 提交于
As multiplatform build is being adopted by more and more ARM platforms, initcall function should be used very carefully. For example, when GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init() will be called on all the platforms to initialize cpufreq-cpu0 driver. To eliminate this undesired the effect, the patch changes cpufreq-cpu0 driver to have it instantiated as a platform_driver. Then it will only run on platforms that create the platform_device "cpufreq-cpu0". Along with the change, it also changes cpu_dev to be &pdev->dev, so that managed functions can start working, and module build gets supported too. The highbank-cpufreq driver is also updated accordingly to adapt the changes on cpufreq-cpu0. Signed-off-by: NShawn Guo <shawn.guo@linaro.org> Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org> Acked-by: NMark Langsdorf <mark.langsdorf@calxeda.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Mark Langsdorf 提交于
Highbank processors depend on the external ECME to perform voltage management based on a requested frequency. Communication between the A9 cores and the ECME happens over the pl320 IPC channel. Signed-off-by: NMark Langsdorf <mark.langsdorf@calxeda.com> Reviewed-by: NShawn Guo <shawn.guo@linaro.org> Reviewed-by: NMike Turquette <mturquette@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 22 1月, 2013 1 次提交
-
-
由 Nishanth Menon 提交于
OPP pointer is RCU protected, hence after finding it, de-reference also should be protected with the same RCU context else the OPP pointer may become invalid. Reported-by: NJack Mitchell <jack@embed.me.uk> Tested-by: NAlexander Holler <holler@ahsoftware.de> Tested-by: NJack Mitchell <jack@embed.me.uk> Acked-by: NAlexander Holler <holler@ahsoftware.de> Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 21 11月, 2012 1 次提交
-
-
由 Bill Pemberton 提交于
CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: NBill Pemberton <wfp5p@virginia.edu> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 10 9月, 2012 1 次提交
-
-
由 Shawn Guo 提交于
It adds a generic cpufreq driver for CPU0 frequency management based on clk, regulator, OPP and device tree support. It can support both uniprocessor (UP) and those symmetric multiprocessor (SMP) systems which share clock and voltage across all CPUs. Signed-off-by: NShawn Guo <shawn.guo@linaro.org> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NAnilKumar Ch <anilkumar@ti.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-