[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52F11B5C.40407@ti.com>
Date: Tue, 4 Feb 2014 18:54:52 +0200
From: Ivan Khoronzhuk <ivan.khoronzhuk@...com>
To: Thomas Gleixner <tglx@...utronix.de>
CC: <santosh.shilimkar@...com>, <rob@...dley.net>,
<linux@....linux.org.uk>, <galak@...eaurora.org>,
<robh+dt@...nel.org>, <pawel.moll@....com>, <mark.rutland@....com>,
<ijc+devicetree@...lion.org.uk>, <daniel.lezcano@...aro.org>,
<devicetree@...r.kernel.org>, <linux-doc@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, <grygorii.strashko@...com>
Subject: Re: [PATCH v4 1/3] clocksource: timer-keystone: introduce clocksource
driver for Keystone
It was so in v1. But it was decided to use explicit memory barriers,
because we're always sure the memory barriers are there and that
they're properly documented. Also in this case I don't need to add
keystone readl/writel relaxed function variants and to use mixed calls of
writel/writel_relaxed functions.
See:
http://www.spinics.net/lists/arm-kernel/msg294941.html
On 02/04/2014 06:24 PM, Thomas Gleixner wrote:
> On Tue, 4 Feb 2014, Ivan Khoronzhuk wrote:
>> + keystone_timer_writel(off, TCR);
>> + /* here we have to be sure the timer has been disabled */
>> + wmb();
> We have explicit writew_relaxed and writew. Why open coding the
> barriers?
>
> Thanks,
>
> tglx
--
Regards,
Ivan Khoronzhuk
--
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