lkml.org 
[lkml]   [2003]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: Cpufreq for opteron
    Date
    > > +#define VERSION "version 1.00.06 - August 13, 2003"
    >
    > If AMD wants it in, let's put it into the /* comment header
    > at the top */ ?

    It gets written to the log file with printk ... if someone needs
    to send me a log file of an error, I find it helpful to know what
    version of the driver it came from.

    > > +static int onbattery = 1; /* Set if running on battery,
    > reset otherwise. */
    > > + /* Of no relevance unless
    > batterypstates < */
    > > + /* numpstates, as defined in the
    > PSB/PST. */
    >
    > I dislike this interaction between ACPI and cpufreq -- it
    > should be done
    > more generally. Let's discuss that seperately, though. And if
    > the code is
    > dead code at the moment.

    The dead code has been removed in 1.00.07 of the driver. I am
    happy to receive suggestions as to better ways of detecting battery
    versus mains power transitions.

    > > +static int
    > > +drv_verify(struct cpufreq_policy *pol)
    > > +{
    > <snip>
    > > + dprintk(KERN_DEBUG PFX
    > > + "ver: cpu%d, min %d, max %d, cur %d, pol %d
    > (%s)\n", pol->cpu,
    > > + pol->min, pol->max, pol->cur, pol->policy,
    > > + pol->policy ==
    > > + CPUFREQ_POLICY_POWERSAVE ? "psave" : pol->policy ==
    > > + CPUFREQ_POLICY_PERFORMANCE ? "perf" : "unk");
    > > +
    > > + if (pol->cpu != 0) {
    > > + printk(KERN_ERR PFX "verify - cpu not 0\n");
    > > + return -ENODEV;
    > > + }
    > > +
    > > + res = find_match(&targ, &min, &max,
    > > + pol->policy ==
    > > + CPUFREQ_POLICY_POWERSAVE ? SEARCH_DOWN
    > : SEARCH_UP, 0,
    > > + 0);
    >
    > Why do you check for CPUFREQ_POLICY here??? In a ->target
    > class cpufreq
    > driver[*] you must not worry about the policy, only about min and max
    > frequency.
    >
    > [*] ->target class cpufreq drivers [cpufreq_driver->target is
    > used] have
    > specific operating frequencies.
    > ->setpolicy class cpufreq drivers have operating frequency ranges
    > [currently only available on Transmeta Crusoe processors]

    If the driver has to expand the range to find a matching frequency, it
    has to know whether to expand up or down. That comes from policy.

    > Also, it'd be great if this driver were converted to use the CPUfreq
    > freuqency table helpers -- check drivers/cpufreq/freq_table.c in
    > linux-2.6.0-test4. Using it makes the code much cleaner, easier to
    > understand, and less prone to errors.

    I'll look into for the next rev.

    > Dominik

    Thanks. Paul.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:48    [W:0.029 / U:29.476 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site