[PATCHv2] cpufreq for freescale mx51
yong.shen at linaro.org
Tue Oct 12 07:11:51 UTC 2010
Does anybody have more comments on [PATCHv2] ?
On Thu, Oct 7, 2010 at 8:00 PM, Yong Shen <yong.shen at linaro.org> wrote:
> > Using wp_tbl is because that it also contains information like regulator
>> > voltage.
>> The clock code does not handle the regulators, not even in the fsl
> I did not mean to say clock code will handle regulators. I mean this table
> also contains such information which may be needed in other freescale
> drivers, like dvfs and busfreq.
> > Since the regulator driver for imx51 have not been upstreamed, you
>> > don't see any regulator operation here. Also, like you mentioned, there
>> > two ways to change cpufreq, by post divider or pll change. And post
>> > change is a simpler way and also the only way for babbage, since cpu
>> > and ddr freq are all root from the same pll on babbage and they will
>> > interfere each other.
>> I understand what you have to do, but the way you did really looks
>> strange. You introduce get_cpu_wp() to get the complete array of
>> workpoints. In the cpufreq driver you have this complete array, pick
>> the desired workpoint, pass the frequency to the clock layer which in
>> turn calls get_cpu_wp() to get the array and loop around it to get
>> the workpoint from the frequency again. Addionally you maintain a
>> pointer to what the clock code thinks the current workpoint is.
>> How about making the clock code agnostic of such workpoints and
>> calculate the pll values and dividers for a given frequency based
>> on the frequency. If that's to complicated you could maintain
>> a table in the clock code. If that's not flexible enough you could
>> pass a pointer to this table to mx51_clocks_init. This array could
>> carry information relevant only to the clock code and only relevant
>> to the i.MX51, In the fsl kernel struct cpu_wp is a catch-all struct
>> for all i.MXs. The i.MX51 uses the pdf/mfi/mfd/mfn/cpu_podf fields,
>> the i.MX35 uses the pll_reg and pdr0_reg fields and who knows what
>> the next i.MX needs.
> I strongly agree with you about this, and it is better to letter clock
> calculate by itself.
>> > > > +static struct cpufreq_frequency_table imx_freq_table;
>> > >
>> > > Three frequencies should be enough for everyone, right? This should be
>> > > dynamically allocated like in other cpufreq drivers.
>> > >
>> > Yes, we only support 3 work points, which is for sure. Actually, we only
>> > support 2 points on most mx51 chips. I supposed it is ok to use static
>> > here.
>> Please just add dynamic allocation, then we are safe for any potential
>> future use.
>> Ok! sorry for misunderstanding.
> Here, I am not trying to find excuse for the cpufreq driver designer which
> is my colleague, however the truth is that since in our company the schedule
> is tight for all the tasks, that's why we always code with the first rough
> idea in the head, and having less time to think about the flexibility and
> other good conventions in programming. You can see that even freescale code
> upstreaming is done by people out of freescale, because of we lacking of
> Therefore, I would say we did not mean to have some short-sight design, we
> also want to achieve a better life of coding like you guys are doing, which
> is my direct feeling while I am in Linaro. :)
> Thanks for comments.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the linaro-dev