Re: [Xen-devel] [RFC PATCH 29/31] xen/arm: Introduce CPUFreq Interface component

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 6 Dec 2017, Oleksandr Tyshchenko wrote:
> >> +    perf->platform_limit = platform_limit;
> >> +    perf->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> >> +    perf->domain_info.domain = cpumask_first(mask);
> >> +    perf->domain_info.num_processors = cpumask_weight(mask);
> >> +
> >> +    /* Iterate through all CPUs which are on the same boat */
> >> +    for_each_cpu( cpu, mask )
> >> +    {
> >> +        ret = set_px_pminfo(cpu, perf);
> >> +        if ( ret )
> >> +        {
> >> +            printk("cpu%d: failed to set Px states (%d)\n", cpu, ret);
> >> +            break;
> >> +        }
> >> +
> >> +        printk(XENLOG_DEBUG "cpu%d: set Px states\n", cpu);
> >> +    }
> >> +
> >> +    xfree(states);
> >> +out:
> >> +    xfree(perf);
> >> +
> >> +    return ret;
> >> +}
> >> +
> >> +static int __init scpi_cpufreq_postinit(void)
> >> +{
> >> +    struct cpufreq_frequency_table *freq_table = NULL;
> >> +    cpumask_t processed_cpus, shared_cpus;
> >> +    unsigned int cpu;
> >> +    int ret = -ENODEV;
> >> +
> >> +    cpumask_clear(&processed_cpus);
> >> +
> >> +    for_each_online_cpu( cpu )
> >> +    {
> >> +        if ( cpumask_test_cpu(cpu, &processed_cpus) )
> >> +            continue;
> >> +
> >> +        if ( !is_dvfs_capable(cpu) )
> >> +            continue;
> >> +
> >> +        ret = get_sharing_cpus(cpu, &shared_cpus);
> >> +        if ( ret )
> >> +        {
> >> +            printk("cpu%d: failed to get sharing cpumask (%d)\n", cpu, 
> >> ret);
> >> +            return ret;
> >> +        }
> >> +
> >> +        BUG_ON(cpumask_empty(&shared_cpus));
> >> +        cpumask_or(&processed_cpus, &processed_cpus, &shared_cpus);
> >> +
> >> +        /* Create intermediate frequency table */
> >> +        ret = init_cpufreq_table(cpu, &freq_table);
> >> +        if ( ret )
> >> +        {
> >> +            printk("cpu%d: failed to initialize frequency table (%d)\n",
> >> +                   cpu, ret);
> >> +            return ret;
> >> +        }
> >> +
> >> +        ret = upload_cpufreq_data(&shared_cpus, freq_table);
> >> +        /* Destroy intermediate frequency table */
> >> +        free_cpufreq_table(&freq_table);
> >> +        if ( ret )
> >> +        {
> >> +            printk("cpu%d: failed to upload cpufreq data (%d)\n", cpu, 
> >> ret);
> >> +            return ret;
> >> +        }
> >> +
> >> +        printk(XENLOG_DEBUG "cpu%d: uploaded cpufreq data\n", cpu);
> >> +    }
> >> +
> >> +    return ret;
> >> +}
> >> +
> >> +static int __init scpi_cpufreq_preinit(void)
> >> +{
> >> +    struct dt_device_node *scpi, *clk, *dvfs_clk;
> >> +    int ret;
> >> +
> >> +    /* Initialize SCPI Message protocol */
> >> +    ret = scpi_init();
> >> +    if ( ret )
> >> +    {
> >> +        printk("failed to initialize SCPI (%d)\n", ret);
> >> +        return ret;
> >> +    }
> >> +
> >> +    /* Sanity check */
> >> +    if ( !get_scpi_ops() || !get_scpi_dev() )
> >> +        return -ENXIO;
> >> +
> >> +    scpi = get_scpi_dev()->of_node;
> >> +    scpi_ops = get_scpi_ops();
> >> +
> >> +    ret = -ENODEV;
> >> +
> >> +    /*
> >> +     * Check for clock related nodes for now. But it might additional 
> >> nodes,
> >> +     * like thermal sensor, etc.
> >> +     */
> >> +    dt_for_each_child_node( scpi, clk )
> >
> > Wouldn't it make sense to have a proper:
> >
> > DT_DEVICE_START
> > ...
> > DT_DEVICE_END
> >
> > block and register the driver that way?
> 
> I am not sure that I got your question completely.
> Which driver need to be registered in a such way?
> If we had separate dt-related driver to manage clocks we would have to
> register it in a proposed way.
> Here we just iterating through all SCPI child in order to be sure that
> DVFS clock sub-node is present.
> Let say, preliminary check.
> 
> BTW, in a proposed way I register ARM SMC triggered mailbox driver:
> https://www.mail-archive.com/xen-devel@xxxxxxxxxxxxx/msg128411.html
> With adding new DEVICE_MAILBOX class:
> https://www.mail-archive.com/xen-devel@xxxxxxxxxxxxx/msg128402.html

Fair enough, and I see that it is not even scanning the whole device
tree but only the scpi node. It's fine then.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel