Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp4489615pxv; Tue, 6 Jul 2021 02:06:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwUko+QjYROWhh7yL/9neKFjiDppgD5G59Y08LzFnbyCzwBTCB59Uk9CFnPWqDWigUOoeCc X-Received: by 2002:a02:a78b:: with SMTP id e11mr4781640jaj.32.1625562401862; Tue, 06 Jul 2021 02:06:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625562401; cv=none; d=google.com; s=arc-20160816; b=k+TQwr3ZbnAZJOLi5xWGPO4dT4Kjio8v9QdGuJjZu4ZL8AhELbYmdFRkNkAYVEKD8V zL8Q3kGWKCueujFYiwE7Dd621NVSVGG02tlwjpCsLPUNV3skaMd0Yk5k5vhdIjdinUJU qCMgD0xjyLWg/ntnNblC0QQPo6uAblxaC4FT8LDTA8RxtDBX5eOlJd+3AzdhR9mpaHTS PuaWGQa9xwI1+RrVQPNR0ylS57rIK7MSJgfVe9VVHMtgK93PPRfXSzOHIQ/2Six6ad+e yvLucBkvGD5pyHQoqfQDU/aQrFkmCIPGagp/H8OSlK3EmNZag6ilk2cI8plJ5FabfSX2 oUIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=BaGdHf8woKranwf4GOma6mVC5xX/ODm51mj9mn5HuPk=; b=Ef7n6VF7+ofDMg8eVV8dKHir1NV6Xo2XJjZgfCtLKLBLTHOap2Z77IQ1zArbeW+IX/ EKSGrBbk4wXzGzXPVEfiJkKIqQbNpb4nO97AU829eYjAwRYmRyMtHMfaLvF7veW7l5h2 MpbG743AzoI5z91zNV4kLrmQJyhSHFsxO0yNQoxckfYo27sbI+oSc/wPAia3DWCGxXGI aGf3BvREptUWfqApIfSYakhMSkDDYx9cC89K4W8hU36JxzBWNUaxLOU4Fm1/KXyoDXaC OXR3zdXiS2j4rkk485u8rBolWC1rzj86QOy4oQOTNSlTbldjWCBiZw+ZutTkkRT6xycP a5kg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w14si17644846ilm.64.2021.07.06.02.06.30; Tue, 06 Jul 2021 02:06:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230508AbhGFJHD convert rfc822-to-8bit (ORCPT + 99 others); Tue, 6 Jul 2021 05:07:03 -0400 Received: from frasgout.his.huawei.com ([185.176.79.56]:3367 "EHLO frasgout.his.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230295AbhGFJHD (ORCPT ); Tue, 6 Jul 2021 05:07:03 -0400 Received: from fraeml742-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GJx8V4t07z6H8xR; Tue, 6 Jul 2021 16:50:18 +0800 (CST) Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by fraeml742-chm.china.huawei.com (10.206.15.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 6 Jul 2021 11:04:22 +0200 Received: from localhost (10.47.82.155) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Tue, 6 Jul 2021 10:04:21 +0100 Date: Tue, 6 Jul 2021 10:04:05 +0100 From: Jonathan Cameron To: "Sa, Nuno" CC: Jonathan Cameron , "Miclaus, Antoniu" , "linux-iio@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , "robh+dt@kernel.org" Subject: Re: [PATCH v4 1/2] iio: frequency: adrf6780: add support for ADRF6780 Message-ID: <20210706100405.00001507@Huawei.com> In-Reply-To: References: <20210702111239.174189-1-antoniu.miclaus@analog.com> <20210703175716.7864358a@jic23-huawei> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8BIT X-Originating-IP: [10.47.82.155] X-ClientProxiedBy: lhreml707-chm.china.huawei.com (10.201.108.56) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 5 Jul 2021 10:18:51 +0000 "Sa, Nuno" wrote: > > -----Original Message----- > > From: Jonathan Cameron > > Sent: Saturday, July 3, 2021 6:57 PM > > To: Miclaus, Antoniu > > Cc: linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org; > > devicetree@vger.kernel.org; robh+dt@kernel.org > > Subject: Re: [PATCH v4 1/2] iio: frequency: adrf6780: add support for > > ADRF6780 > > > > On Fri, 2 Jul 2021 14:12:38 +0300 > > Antoniu Miclaus wrote: > > > > > The ADRF6780 is a silicon germanium (SiGe) design, wideband, > > > microwave upconverter optimized for point to point microwave > > > radio designs operating in the 5.9 GHz to 23.6 GHz frequency > > > range. > > > > > > Datasheet: > > > https://www.analog.com/media/en/technical-documentation/data- > > sheets/ADRF6780.pdf > > > > > > Signed-off-by: Antoniu Miclaus > > > > Hi Antoniu, > > > > Frequency drivers are fairly unusual so if you could add a listing of > > the attributes in sysfs that would be great (it's nice practice anyway but > > I don't insist on it!) > > > > Various fairly minor comments inline. > > > > Thanks, > > > > Jonathan > > > > > > > --- > > > changes in v4: > > > - change license to: GPL-2.0-only > > > drivers/iio/frequency/Kconfig | 13 + > > > drivers/iio/frequency/Makefile | 1 + > > > drivers/iio/frequency/adrf6780.c | 498 > > +++++++++++++++++++++++++++++++ > > > 3 files changed, 512 insertions(+) > > > create mode 100644 drivers/iio/frequency/adrf6780.c > > > > > > diff --git a/drivers/iio/frequency/Kconfig > > b/drivers/iio/frequency/Kconfig > > > index 240b81502512..fc9751c48f59 100644 > > > --- a/drivers/iio/frequency/Kconfig > > > +++ b/drivers/iio/frequency/Kconfig > > > @@ -49,5 +49,18 @@ config ADF4371 > > > > > > To compile this driver as a module, choose M here: the > > > module will be called adf4371. > > > + > > > +config ADRF6780 > > > + tristate "Analog Devices ADRF6780 Microwave Upconverter" > > > + depends on SPI > > > + depends on COMMON_CLK > > > + depends on OF > > > > Why? Pretty much everything seems to have defaults if not provided > > via OF. > > I've asked for the generic firmware functions anyway, so you can drop > > this > > for that reason if nothing else! > > > > > + help > > > + Say yes here to build support for Analog Devices ADRF6780 > > > + 5.9 GHz to 23.6 GHz, Wideband, Microwave Upconverter. > > > + > > > + To compile this driver as a module, choose M here: the > > > + module will be called adrf6780. > > > + > > > endmenu > > > endmenu > > > diff --git a/drivers/iio/frequency/Makefile > > b/drivers/iio/frequency/Makefile > > > index 518b1e50caef..ae3136c79202 100644 > > > --- a/drivers/iio/frequency/Makefile > > > +++ b/drivers/iio/frequency/Makefile > > > @@ -7,3 +7,4 @@ > > > obj-$(CONFIG_AD9523) += ad9523.o > > > obj-$(CONFIG_ADF4350) += adf4350.o > > > obj-$(CONFIG_ADF4371) += adf4371.o > > > +obj-$(CONFIG_ADRF6780) += adrf6780.o > > > diff --git a/drivers/iio/frequency/adrf6780.c > > b/drivers/iio/frequency/adrf6780.c > > > new file mode 100644 > > > index 000000000000..472a66f90c7f > > > --- /dev/null > > > +++ b/drivers/iio/frequency/adrf6780.c > > > @@ -0,0 +1,498 @@ > > > +// SPDX-License-Identifier: GPL-2.0-only > > > +/* > > > + * ADRF6780 driver > > > + * > > > + * Copyright 2021 Analog Devices Inc. > > > + */ > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > > #include > > > > > +#include > > > + > > > +/* ADRF6780 Register Map */ > > > +#define ADRF6780_REG_CONTROL 0x00 > > > +#define ADRF6780_REG_ALARM_READBACK 0x01 > > > +#define ADRF6780_REG_ALARM_MASKS 0x02 > > > +#define ADRF6780_REG_ENABLE 0x03 > > > +#define ADRF6780_REG_LINEARIZE 0x04 > > > +#define ADRF6780_REG_LO_PATH 0x05 > > > +#define ADRF6780_REG_ADC_CONTROL 0x06 > > > +#define ADRF6780_REG_ADC_OUTPUT 0x0C > > > + > > > +/* ADRF6780_REG_CONTROL Map */ > > > +#define ADRF6780_PARITY_EN_MSK BIT(15) > > > +#define ADRF6780_PARITY_EN(x) > > FIELD_PREP(ADRF6780_PARITY_EN_MSK, x) > > > +#define ADRF6780_SOFT_RESET_MSK BIT(14) > > > +#define ADRF6780_SOFT_RESET(x) > > FIELD_PREP(ADRF6780_SOFT_RESET_MSK, x) > > > +#define ADRF6780_CHIP_ID_MSK GENMASK(11, 4) > > > +#define ADRF6780_CHIP_ID 0xA > > > +#define ADRF6780_CHIP_REVISION_MSK GENMASK(3, 0) > > > +#define ADRF6780_CHIP_REVISION(x) > > FIELD_PREP(ADRF6780_CHIP_REVISION_MSK, x) > > > + > > > +/* ADRF6780_REG_ALARM_READBACK Map */ > > > +#define ADRF6780_PARITY_ERROR_MSK BIT(15) > > > +#define ADRF6780_PARITY_ERROR(x) > > FIELD_PREP(ADRF6780_PARITY_ERROR_MSK, x) > > > +#define ADRF6780_TOO_FEW_ERRORS_MSK BIT(14) > > > +#define ADRF6780_TOO_FEW_ERRORS(x) > > FIELD_PREP(ADRF6780_TOO_FEW_ERRORS_MSK, x) > > > +#define ADRF6780_TOO_MANY_ERRORS_MSK BIT(13) > > > +#define ADRF6780_TOO_MANY_ERRORS(x) > > FIELD_PREP(ADRF6780_TOO_MANY_ERRORS_MSK, x) > > > +#define ADRF6780_ADDRESS_RANGE_ERROR_MSK BIT(12) > > > +#define ADRF6780_ADDRESS_RANGE_ERROR(x) > > FIELD_PREP(ADRF6780_ADDRESS_RANGE_ERROR_MSK, x) > > > + > > > +/* ADRF6780_REG_ENABLE Map */ > > > +#define ADRF6780_VGA_BUFFER_EN_MSK BIT(8) > > > +#define ADRF6780_VGA_BUFFER_EN(x) > > FIELD_PREP(ADRF6780_VGA_BUFFER_EN_MSK, x) > > > +#define ADRF6780_DETECTOR_EN_MSK BIT(7) > > > +#define ADRF6780_DETECTOR_EN(x) > > FIELD_PREP(ADRF6780_DETECTOR_EN_MSK, x) > > > +#define ADRF6780_LO_BUFFER_EN_MSK BIT(6) > > > +#define ADRF6780_LO_BUFFER_EN(x) > > FIELD_PREP(ADRF6780_LO_BUFFER_EN_MSK, x) > > > +#define ADRF6780_IF_MODE_EN_MSK BIT(5) > > > +#define ADRF6780_IF_MODE_EN(x) > > FIELD_PREP(ADRF6780_IF_MODE_EN_MSK, x) > > > +#define ADRF6780_IQ_MODE_EN_MSK BIT(4) > > > +#define ADRF6780_IQ_MODE_EN(x) > > FIELD_PREP(ADRF6780_IQ_MODE_EN_MSK, x) > > > +#define ADRF6780_LO_X2_EN_MSK BIT(3) > > > +#define ADRF6780_LO_X2_EN(x) > > FIELD_PREP(ADRF6780_LO_X2_EN_MSK, x) > > > +#define ADRF6780_LO_PPF_EN_MSK BIT(2) > > > +#define ADRF6780_LO_PPF_EN(x) > > FIELD_PREP(ADRF6780_LO_PPF_EN_MSK, x) > > > +#define ADRF6780_LO_EN_MSK BIT(1) > > > +#define ADRF6780_LO_EN(x) > > FIELD_PREP(ADRF6780_LO_EN_MSK, x) > > > +#define ADRF6780_UC_BIAS_EN_MSK BIT(0) > > > +#define ADRF6780_UC_BIAS_EN(x) > > FIELD_PREP(ADRF6780_UC_BIAS_EN_MSK, x) > > > + > > > +/* ADRF6780_REG_LINEARIZE Map */ > > > +#define ADRF6780_RDAC_LINEARIZE_MSK GENMASK(7, 0) > > > +#define ADRF6780_RDAC_LINEARIZE(x) > > FIELD_PREP(ADRF6780_RDAC_LINEARIZE_MSK, x) > > > + > > > +/* ADRF6780_REG_LO_PATH Map */ > > > +#define ADRF6780_LO_SIDEBAND_MSK BIT(10) > > > +#define ADRF6780_LO_SIDEBAND(x) > > FIELD_PREP(ADRF6780_LO_SIDEBAND_MSK, x) > > > +#define ADRF6780_Q_PATH_PHASE_ACCURACY_MSK > > GENMASK(7, 4) > > > +#define ADRF6780_Q_PATH_PHASE_ACCURACY(x) > > FIELD_PREP(ADRF6780_Q_PATH_PHASE_ACCURACY_MSK, x) > > > +#define ADRF6780_I_PATH_PHASE_ACCURACY_MSK > > GENMASK(3, 0) > > > +#define ADRF6780_I_PATH_PHASE_ACCURACY(x) > > FIELD_PREP(ADRF6780_I_PATH_PHASE_ACCURACY_MSK, x) > > > + > > > +/* ADRF6780_REG_ADC_CONTROL Map */ > > > +#define ADRF6780_VDET_OUTPUT_SELECT_MSK BIT(3) > > > +#define ADRF6780_VDET_OUTPUT_SELECT(x) > > FIELD_PREP(ADRF6780_VDET_OUTPUT_SELECT_MSK, x) > > > +#define ADRF6780_ADC_START_MSK BIT(2) > > > +#define ADRF6780_ADC_START(x) > > FIELD_PREP(ADRF6780_ADC_START_MSK, x) > > > +#define ADRF6780_ADC_EN_MSK BIT(1) > > > +#define ADRF6780_ADC_EN(x) > > FIELD_PREP(ADRF6780_ADC_EN_MSK, x) > > > +#define ADRF6780_ADC_CLOCK_EN_MSK BIT(0) > > > +#define ADRF6780_ADC_CLOCK_EN(x) > > FIELD_PREP(ADRF6780_ADC_CLOCK_EN_MSK, x) > > > + > > > +/* ADRF6780_REG_ADC_OUTPUT Map */ > > > +#define ADRF6780_ADC_STATUS_MSK BIT(8) > > > +#define ADRF6780_ADC_STATUS(x) > > FIELD_PREP(ADRF6780_ADC_STATUS_MSK, x) > > > +#define ADRF6780_ADC_VALUE_MSK > > GENMASK(7, 0) > > > +#define ADRF6780_ADC_VALUE(x) > > FIELD_PREP(ADRF6780_ADC_VALUE_MSK, x) > > > > Not used. In general, just use FIELD_PREP / FIELD_GET inline rather > > than having extra > > macros like these. That approach is simpler for reviewers to follow. > > > > > + > > > +struct adrf6780_dev { > > > + struct spi_device *spi; > > > + struct clk *clkin; > > > + /* Protect against concurrent accesses to the device */ > > > + struct mutex lock; > > > + bool vga_buff_en; > > > + bool lo_buff_en; > > > + bool if_mode_en; > > > + bool iq_mode_en; > > > + bool lo_x2_en; > > > + bool lo_ppf_en; > > > + bool lo_en; > > > + bool uc_bias_en; > > > + bool lo_sideband; > > > + bool vdet_out_en; > > > +}; > > > + > > > +static int adrf6780_spi_read(struct adrf6780_dev *dev, unsigned int > > reg, > > > + unsigned int *val) > > > +{ > > > + int ret; > > > + unsigned int temp; > > > + struct spi_transfer t = {0}; > > > + u8 data[3]; > > > + > > > + data[0] = 0x80 | (reg << 1); > > > + data[1] = 0x0; > > > + data[2] = 0x0; > > > + > > > + t.rx_buf = &data[0]; > > > + t.tx_buf = &data[0]; > > > + t.len = 3; > > > + > > > + ret = spi_sync_transfer(dev->spi, &t, 1); > > > > data needs to be dma safe. > > > > > + if (ret < 0) > > > + return ret; > > > + > > > + temp = ((data[0] | 0x80 | (reg << 1)) << 16) | > > > + (data[1] << 8) | data[2]; > > > > Ouch. That's a bit nasty, but why are you writing the reg into > > it? Looks like a get_unaligned_be24() >> 1 and a 16bit mask. > > (use GENMASK(15, 0) for that to make it apparent what is happening. > > > > > + > > > + *val = (temp >> 1) & 0xFFFF; > > > + > > > + return ret; > > > +} > > > + > > > +static int adrf6780_spi_write(struct adrf6780_dev *dev, > > > + unsigned int reg, > > > + unsigned int val) > > > +{ > > > + u8 data[3]; > > > + > > > + val = (val << 1); > > > + > > > + data[0] = (reg << 1) | (val >> 16); > > > + data[1] = val >> 8; > > > + data[2] = val; > > > > An opportunity for > > put_unaligned_be24() with a value of (I think) > > > > (val << 1) | (reg << 17) > > > > > > > + > > > + return spi_write(dev->spi, &data[0], 3); > > > > Needs a dma safe buffer, which basically means it can't be on the > > stack. > > Lots of ways of handling that, but look for __cacheline_aligned in IIO > > drivers > > to see the one we probably use mostly commonly in IIO drivers. > > Hi Jonathan, > > This is something I wanted to ask for some time so I will take the opportunity here :). > Is this something you prefer just not to risk at all and make it an hard requirement > (which is fair)? ... Yes, I think we need to keep this as a hard requirement. There are drivers out there which we missed this on in the past, and I'm not necessarily going to take the time to go through them all as this can be hard to spot, but lets not introduce any more potential problems. > > I'm asking this because, tbh, I would be very surprised if any spi/i2c controller out there > is using dma for a 3byte transfer. I guess the overhead of setting it up is probably not > worth it... There are (I believe) a few i2c and spi controllers out there that don't do anything other than DMA. Wolfram mentioned one of those in his talk on adding DMA support to i2c. Also, the reference in the file below to the wonderful case of USB to i2c bridges that always require DMA safe buffers. > > For instance, in i2c [1], the "educated guess" is around 8byte (to start using dma safe buffers). > > [1]: https://elixir.bootlin.com/linux/latest/source/Documentation/i2c/dma-considerations.rst#L15 > > - Nuno S? >