Menon, Nishanth n...@ti.com writes:
On Wed, May 25, 2011 at 17:16, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
Since we have multiple CPUs, the cpuinit call for CPU1 causes
freq_table of CPU0 to be overwritten. Instead, we maintain
a counter to keep track of
On Thu, May 26, 2011 at 10:11, Kevin Hilman khil...@ti.com wrote:
When you're talking about potentially concurrent modification of data,
that make sense. Here you're implementing a plugin for an existing
framework, and you can (and have to) make assumptions about when the
callbacks are used.
Nishanth Menon n...@ti.com writes:
Since we have multiple CPUs, the cpuinit call for CPU1 causes
freq_table of CPU0 to be overwritten. Instead, we maintain
a counter to keep track of cpus who use the cpufreq table
allocate it once(one freq table for all CPUs) and free them
once the last user
On Wed, May 25, 2011 at 17:16, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
Since we have multiple CPUs, the cpuinit call for CPU1 causes
freq_table of CPU0 to be overwritten. Instead, we maintain
a counter to keep track of cpus who use the cpufreq table
On Wed, May 25, 2011 at 04:38:51PM -0700, Nishanth Menon wrote:
Since we have multiple CPUs, the cpuinit call for CPU1 causes
freq_table of CPU0 to be overwritten. Instead, we maintain
a counter to keep track of cpus who use the cpufreq table
allocate it once(one freq table for all CPUs) and
On Wed, May 25, 2011 at 18:25, Todd Poynor toddpoy...@google.com wrote:
On Wed, May 25, 2011 at 04:38:51PM -0700, Nishanth Menon wrote:
Since we have multiple CPUs, the cpuinit call for CPU1 causes
freq_table of CPU0 to be overwritten. Instead, we maintain
a counter to keep track of cpus who
