From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robin Murphy Subject: Re: [PATCH 4/7] io-64-nonatomic: Add relaxed accessor variants Date: Mon, 25 Apr 2016 16:28:01 +0100 Message-ID: <571E3781.3070609@arm.com> References: <571A5A9E.7040305@arm.com> <20160425133242.GC30830@arm.com> <5485134.l18Z1dlVmn@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5485134.l18Z1dlVmn@wuerfel> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Arnd Bergmann , Will Deacon Cc: Hitoshi Mitake , Christoph Hellwig , iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, tchalamarla-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org, brian.starkey-5wv7dgnIgG8@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Darren Hart List-Id: iommu@lists.linux-foundation.org Hi Arnd, On 25/04/16 16:21, Arnd Bergmann wrote: > On Monday 25 April 2016 14:32:42 Will Deacon wrote: >>>>> >>>>> +static inline __u64 hi_lo_readq_relaxed(const volatile void __iomem *addr) >>>>> +{ >>>>> + const volatile u32 __iomem *p = addr; >>>>> + u32 low, high; >>>>> + >>>>> + high = readl_relaxed(p + 1); >>>>> + low = readl_relaxed(p); >>>>> + >>>>> + return low + ((u64)high << 32); >>>>> +} >>>>> + >>>>> +static inline void hi_lo_writeq_relaxed(__u64 val, volatile void __iomem *addr) >>>>> +{ >>>>> + writel_relaxed(val >> 32, addr + 4); >>>>> + writel_relaxed(val, addr); >>>>> +} >>>> >>>> Could we not generate the _relaxed variants with some macro magic? >>> >>> We _could_ - indeed I started doing that, but then decided that the >>> obfuscation of horrible macro-templated functions wasn't worth saving a >>> couple of hundred bytes in some code that isn't exactly difficult to >>> maintain and has needed touching once in 4 years. >>> >>> If you did want to go down the macro route, I may as well also generate both >>> lo-hi and hi-lo headers all from a single template, it'd be really clever... >>> >> >> I certainly wasn't suggesting any more than the obvious macroisation, >> but I'll leave it up to Arnd, as I think this falls on his lap. > > I'd prefer the open-coded variant as well. By that, do you mean sticking with the smmu_writeq() implementation in the driver and dropping this patch, or merging this patch as-is without further macro-magic? Thanks, Robin. > > Arnd > From mboxrd@z Thu Jan 1 00:00:00 1970 From: robin.murphy@arm.com (Robin Murphy) Date: Mon, 25 Apr 2016 16:28:01 +0100 Subject: [PATCH 4/7] io-64-nonatomic: Add relaxed accessor variants In-Reply-To: <5485134.l18Z1dlVmn@wuerfel> References: <571A5A9E.7040305@arm.com> <20160425133242.GC30830@arm.com> <5485134.l18Z1dlVmn@wuerfel> Message-ID: <571E3781.3070609@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Arnd, On 25/04/16 16:21, Arnd Bergmann wrote: > On Monday 25 April 2016 14:32:42 Will Deacon wrote: >>>>> >>>>> +static inline __u64 hi_lo_readq_relaxed(const volatile void __iomem *addr) >>>>> +{ >>>>> + const volatile u32 __iomem *p = addr; >>>>> + u32 low, high; >>>>> + >>>>> + high = readl_relaxed(p + 1); >>>>> + low = readl_relaxed(p); >>>>> + >>>>> + return low + ((u64)high << 32); >>>>> +} >>>>> + >>>>> +static inline void hi_lo_writeq_relaxed(__u64 val, volatile void __iomem *addr) >>>>> +{ >>>>> + writel_relaxed(val >> 32, addr + 4); >>>>> + writel_relaxed(val, addr); >>>>> +} >>>> >>>> Could we not generate the _relaxed variants with some macro magic? >>> >>> We _could_ - indeed I started doing that, but then decided that the >>> obfuscation of horrible macro-templated functions wasn't worth saving a >>> couple of hundred bytes in some code that isn't exactly difficult to >>> maintain and has needed touching once in 4 years. >>> >>> If you did want to go down the macro route, I may as well also generate both >>> lo-hi and hi-lo headers all from a single template, it'd be really clever... >>> >> >> I certainly wasn't suggesting any more than the obvious macroisation, >> but I'll leave it up to Arnd, as I think this falls on his lap. > > I'd prefer the open-coded variant as well. By that, do you mean sticking with the smmu_writeq() implementation in the driver and dropping this patch, or merging this patch as-is without further macro-magic? Thanks, Robin. > > Arnd >