From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]:50941 "EHLO ppsw-52.csi.cam.ac.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750704Ab2EKHnJ (ORCPT ); Fri, 11 May 2012 03:43:09 -0400 Message-ID: <4FACC306.8000504@cam.ac.uk> Date: Fri, 11 May 2012 08:43:02 +0100 From: Jonathan Cameron MIME-Version: 1.0 To: michael.hennerich@analog.com CC: Jonathan Cameron , "linux-iio@vger.kernel.org" , "device-drivers-devel@blackfin.uclinux.org" Subject: Re: [PATCH] iio: frequency: New driver for Analog Devices ADF4350/ADF4351 Wideband Synthesizers References: <1336398556-5360-1-git-send-email-michael.hennerich@analog.com> <4FA932D9.5010006@cam.ac.uk> <4FA93D00.2070906@analog.com> <4FABB647.3090200@kernel.org> <4FACC2B2.9000601@analog.com> In-Reply-To: <4FACC2B2.9000601@analog.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: linux-iio-owner@vger.kernel.org List-Id: linux-iio@vger.kernel.org On 5/11/2012 8:41 AM, Michael Hennerich wrote: > On 05/10/2012 02:36 PM, Jonathan Cameron wrote: >> On 5/8/2012 4:34 PM, Michael Hennerich wrote: >>> On 05/08/2012 04:51 PM, Jonathan Cameron wrote: >>>> On 5/7/2012 2:49 PM, michael.hennerich@analog.com wrote: >>>>> From: Michael Hennerich >>>>> >>>>> >>>>> + >>>>> +static const struct iio_chan_spec_ext_info adf4350_ext_info[] = { >>>>> + /* Ideally we use IIO_CHAN_INFO_FREQUENCY, but there are >>>>> + * values> 2^32 in order to support the entire frequency range >>>>> + * in Hz. Using scale is a bit ugly. >>>>> + */ >>>> hmm.. Add IIO_VAL_MEGA_PLUS_INT.. We were always going to need a bigger >>>> version at somepoint... >>> Well - we then need an s64, however read|write_raw feature s32 for >>> val and val2. So shall we pass low word in val and high word in val2? >> I was thinking >> val*1e6 + val2 would fit with what we have done elsewhere? Is that >> enough room? > Hi Jonathan, > > IIO_VAL_MEGA_PLUS_INT versus IIO_VAL_LONG_LONG > > It is enough room. But I wonder why we would do costly divide and > modulus operations, when we can do sifts and ANDs? Splitting a s64 would > give is the maximum available room with very little overhead. human readability. I'm anti breaking that if we can possibly avoid it. > > Thoughts? >