RE: [PATCHv3 3/3] clocksource: Add Freescale FlexTimer Module (FTM) timer support

From: Li.Xiubo@xxxxxxxxxxxxx
Date: Mon May 19 2014 - 05:16:28 EST


> >>> +static inline u32 ftm_readl(void __iomem *addr)
> >>> +{
> >>> + if (big_endian)
> >>
> >> I am not a big fan of addressing global variables in the functions, so
> >> if you can pass the structure pointer around here and the other
> >> functions instead that would be nice.
> >>
> >> Otherwise the patch sounds ok. Thanks for taking care of encapsulating
> >> well the functions and commenting the code.
> >>
> >
> > Yes, I did think so.
> >
> > But some callbacks like ï
> > + static u64 ftm_read_sched_clock(void)
> > + {
> > + return ftm_readl(clksrc_base + FTM_CNT);
> > + }
> >
> > Used by :
> > + sched_clock_register(ftm_read_sched_clock,....);
> >
> > If they are encapsulated in a structure, and should the struct instance
> > be one global instance too ? I'm doubting whether will this make sense ?
>
> Actually, I plan in a near future to consolidate the code and factor out
> some parts with a common structure across the different drivers. So even
> if you address the base@ with the global instance but pass around the
> structure as parameter, that will be ok because that will be less
> modifications in the future. It is not a strong requirement, just put in
> place some encapsulation to make the life easier for after.
>

Yes, sounds good.

I'll follow your advice...


> >>> +static int __init ftm_calc_closest_round_cyc(unsigned long freq)
> >>> +{
> >>> + ps = 0;
> >>> +
> >>> + do {
> >>> + peroidic_cyc = DIV_ROUND_CLOSEST(freq, HZ * (1 << ps++));
> >>> + } while (peroidic_cyc > 0xFFFF);
> >>> +
> >>> + if (ps > 7) {
> >>> + pr_err("ftm: the max prescaler is %lu > 7\n", ps);
> >>> + return -EINVAL;
> >>> + }
> >>> +
> >>
> >> Can you explain how this error can happen ?
> >>
> >
> > Yes, the hardware limitation of the 'ps' is 0~7, and the counter register
> > Is only using the lower 16 bits.
> > If the 'freq' value is too big here, then the periodic_cyc may exceed 0xFFFF.
> >
> > Or should I add some comment here ?
>
> Yes, a comment will be welcome.
>

Okay, Please see the next version.

Thanks very much,

BRs
Xiubo


> Thanks
> -- Daniel
>
> --
> <http://www.linaro.org/> Linaro.org â Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog