[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1409041044350.3333@nanos>
Date: Thu, 4 Sep 2014 10:45:51 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: "Li.Xiubo@...escale.com" <Li.Xiubo@...escale.com>
cc: "daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
"Dongsheng.Wang@...escale.com" <Dongsheng.Wang@...escale.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 2/5] Clocksource: Flextimer: Use internal clocksource
read API.
On Thu, 4 Sep 2014, Li.Xiubo@...escale.com wrote:
> > >
> > > Since the FTM will be in BE mode on LS1 platform, but will be in LE mode
> > > On LS2 platform.
> > >
> > > And ftm_clocksource_read_up() will adapt to this different.
> >
> > You are missing the point. Why do you want a conditional in a hot
> > path? You know at init time whether the thing is BE or LE, so you can
> > have separate functions for BE/LE or whatever and register that with
> > clocksource_mmio_init(). i.e.
> >
> > if (be)
> > clocksource_mmio_init(....., cs_read_be);
> > else if (le)
> > clocksource_mmio_init(....., cs_read_le);
> > else if (magic)
> > clocksource_mmio_init(....., cs_read_magic);
> >
>
> There already has the following access interfaces:
>
> static inline u32 ftm_readl(void __iomem *addr)
> {
> if (priv->big_endian)
> return ioread32be(addr);
> else
> return ioread32(addr);
> }
>
> static inline void ftm_writel(u32 val, void __iomem *addr)
> {
> if (priv->big_endian)
> iowrite32be(val, addr);
> else
> iowrite32(val, addr);
> }
>
> So I added the following code:
>
> static cycle_t ftm_clocksource_read_up(struct clocksource *c)
> {
> return ftm_readl(priv->clksrc_base + FTM_CNT) & 0xffff;
> }
>
> clocksource_mmio_init(.....,ftm_clocksource_read_up);
>
> Is this okay ?
No. Sit down, read and try to understand what I wrote, look at your
existing code and figure out WHY it is fundamentally different to what
I told you.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists