We are getting EZ questions regarding booting issues on Talise SOM. They are related to this switch should we just remove it from the device tree ?
Here is the topic: https://ez.analog.com/linux-software-drivers/f/q-a/541904/adrv9009-zu11eg-not-booting-from-newest-image-2019_r2

Hi,

Any chance of a backport of df99ea3#diff-525b057455a9d095225dd9ee32dc1d0e into 2018_R2 branch? That would relieve us from carrying the patch downstream, and I guess it is relevant for others as well

Thanks,
Martin

The device tree "zynqmp-zcu102-revB-ad9361-fmcomms2-3.dtb" references "clk100", which is defined in the zynqmp-clk.dtsi, and not the zynqmp-clk-ccf.dtsi, included from zynqmp-zcu102-revA.dts. The reference to "clk100" should be altered to correctly reference the 100MHz clock defined in CCF as "dp_aclk" or a clock should be designed in the PL configuration and a reference to it created in zynqmp-zcu102-revB-ad9361-fmcomms2-3.dtb.

I worked with petalinux v2018.3, external linux kernel (adi-4.14.0 branch) and added meta-adi layers (master branch)
I didn't solve this issue. How can I fix it?

esra@esra-MS-7A38:~/5g/petalinux_projects/xilinx-zcu102-2018.3$ petalinux-build [INFO] building project
[INFO] sourcing bitbake
INFO: bitbake petalinux-user-image
Loading cache: 100% |############################################| Time: 0:00:00
Loaded 1373 entries from dependency cache.
ERROR: ExpansionError during parsing /home/esra/meta-adi/meta-adi-core/recipes-core/libad9361-iio/libad9361-iio_0.2.bb
Traceback (most recent call last):
File "/home/esra/petalinux_20183/components/yocto/source/aarch64/layers/core/bitbake/lib/bb/data_smart.py", line 412, in DataSmart.expandWithRefs(s="${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}+git${SRCPV}", varname='PV'):
try:
> s = expand_var_regexp.sub(varparse.var_sub, s)
try:
File "/home/esra/petalinux_20183/components/yocto/source/aarch64/layers/core/bitbake/lib/bb/data_smart.py", line 111, in VariableParse.var_sub(match=<_sre.SRE_Match object; span=(80, 88), match='${SRCPV}'>):
else:
> var = self.d.getVarFlag(key, "_content")
self.references.add(key)
File "/home/esra/petalinux_20183/components/yocto/source/aarch64/layers/core/bitbake/lib/bb/data_smart.py", line 794, in DataSmart.getVarFlag(var='SRCPV', flag='_content', expand=True, noweakdefault=False, parsing=False):
cachename = var + "[" + flag + "]"
> value = self.expand(value, cachename)

File "/home/esra/petalinux_20183/components/yocto/source/aarch64/layers/core/bitbake/lib/bb/data_smart.py", line 436, in DataSmart.expand(s='${@bb.fetch2.get_srcrev(d)}', varname='SRCPV'):
def expand(self, s, varname = None):
> return self.expandWithRefs(s, varname).value

File "/home/esra/petalinux_20183/components/yocto/source/aarch64/layers/core/bitbake/lib/bb/data_smart.py", line 426, in DataSmart.expandWithRefs(s='${@bb.fetch2.get_srcrev(d)}', varname='SRCPV'):
except Exception as exc:
> raise ExpansionError(varname, s, exc) from exc

bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Unable to resolve '2018_R2' in upstream git repository in git ls-remote output for github.com/analogdevicesinc/libad9361-iio.git

Summary: There was 1 ERROR message shown, returning a non-zero exit code.
ERROR: Failed to build project

Hello,

I was trying to enable a buffer on my embedded system and I kept getting the error: Invalid argument. After a couple hours of digging, I believe the problem comes down to the following line of code:

bytes = ch->scan_type.storagebits / 8; from industrialio-buffer.c

Is it the case that channels with less than 8 storage bits are simply not supported by the IIO code?

For AD9361 register 0x00E - Temperature

The manual says:

The temperature word is proportional to internal die temperature with a slope of 1.16 × temperature.

But in code, ad9361_get_temp() uses 1.14 as the divider:
return DIV_ROUND_CLOSEST(val * 1000000, 1140);

1.16 vs 1.14, which slope is correct?

Hello

I would like to update the parallella-linux repo with a newer kernel with the ADI drivers. This is the current repo, based of a very old fork of this repo. Can I clone and use the master branch for development? I noticed that you don't have any releases, so I am a bit unsure which branch I can go forward with.

Thanks

booting a master kernel with a 2019R1 device tree on ZedBoard + FMCOMMS3, gives me this during boot:

adf4350 spi1.0: spi1.0 supply vcc not found, using dummy regulator
adf4350 spi1.0: Linked as a consumer to regulator.0
adf4350 spi1.1: spi1.1 supply vcc not found, using dummy regulator
adf4350 spi1.1: Linked as a consumer to regulator.0

which is fine - this device has no way to tell if it is there or not (it's a write only device), if device tree says it is there - it is.

two issues:

wrong IIO name

names shouldn't be the spi bus - it should be the device name.

iio_attr -c
IIO context has 8 devices:
	iio:device0, ad7291: found 9 channels
	iio:device1, ad9361-phy: found 11 channels
	iio:device2, xadc: found 9 channels
	iio:device3, spi1.0: found 1 channels
	iio:device4, spi1.1: found 1 channels
	iio:device5, cf-ad9361-dds-core-lpc: found 12 channels
	iio:device6, cf-ad9361-lpc: found 4 channels
	iio_sysfs_trigger: found 0 channels

Why is it in device tree?

dtc -I fs /sys/firmware/devicetree/base | less

 adf4351-udc-rx-pmod@1 {
 adf4351-udc-tx-pmod@0 {

why is that in the FMCOMMS2/3 device tree? That should only be in the FMCOMMS5.

According to this post the address range for this device should be 0x1000.

It doesn't appear to break anything by being incorrect though.

Whenever reseting the transceiver I always see these errors:

adrv9009 spi0.1: ADIHAL_resetHw at index
adrv9009 spi0.1: ADIHAL_resetHw at index
adrv9009 spi0.1: ERROR: 44: TALISE_gpIntHandler(): PA Protection Channel2 Reports Error
adrv9009 spi0.1: AUX PLL lock detect reset
adrv9009 spi0.1: RF PLL lock detect reset
adrv9009 spi0.1: GP Interrupt Status 0xC0 Action: ERR_REDUCE_TXSAMPLE_PWR
adrv9009 spi0.1: ERROR: 463: TALISE_setFhmConfig: FHM range maximum frequency should be greater than minimum frequency

Can we handle this better?

I did a pull for this bug which wasn't merged, but when you try to remove the admc_adc module from the kernel, it segfaults.

The reason is that the probe function calls "axiadc_configure_ring_stream" and the remove function calls "axiadc_unconfigure_ring". The bug is fixed by modifying the remove function to call "axiadc_unconfigure_ring_stream" instead.

Setting the DT property adi,fagc-lock-level in the DTSI file has no effect. This is supposed to change the [D6:D0] bits of REG_AGC_LOCK_LEVEL (0x101) when using fast AGC mode. However, the value of these bits is always set to the value of the adi,agc-inner-thresh-high property, regardless of the AGC mode (even though this property is only valid for slow AGC mode). The value of the adi,fagc-lock-level property is correctly read from the DT, but never used.

The current workaround is to use adi,agc-inner-thresh-high as adi,fagc-lock-level in fast AGC mode, but this is misleading.

i am working on adrv9009 with zcu102 up to two days before i am able to build my pealinux project for adrv9009 project i dont know what happened with git code suddenly we are getting error while building petalinux adrv9009 projects. i seen git code committed 2 dayes before here
https://github.com/analogdevicesinc/linux

after this committed code i am getting error in petalinux 2018.3 project

error : ERROR: linux-xlnx-4.14-r0 do_kernel_version_sanity_check: Package Version (4.14) does not match of kernel being built (4.19). Please update the PV variable to match the kernel source or set KERNEL_VERSION_SANITY_SKIP="1" in your recipe.

can u please help me in this .??

note: i changed PV variable in meta-adi/meta-adi-xilinx/recipes-kernel/linux/linuxxlnx_%.bbappend

but i am getting licence issue .

SPI Control of TDD Tx and Rx does not work, without the following patch to ad9361_ensm_set_state function in ad9361.c.(the fix is to set the TXNRX_SPI_CTRL bit appropriately for Tx or Rx)

(I think the original author may have fallen foul of slightly ambiguous datasheet. TXNRX_SPI_CTRL does not set SPI CNTRL MODE (as coded in ad9361_set_ensm_mode).- Instead it controls TX (1) or Rx (0) when in SPI mode.

Would you be able to confirm this is correct, or point me to code responsible for setting SPI control of Tx and RX
Thanks
Matt
patch file wouldnt attach, so here it is inline

--- ad9361.c.ORIG 2015-10-02 18:14:07.000000000 +0100
+++ ad9361.c 2015-10-14 15:33:26.358829249 +0100
@@ -4018,6 +4018,7 @@
int32_t rc = 0;
uint32_t val;
uint32_t tmp;

• uint32_t ensm_config_2;

// if (phy->curr_ensm_state == ensm_state) {
// dev_dbg(dev, "Nothing to do, device is already in %d state",
@@ -4028,6 +4029,7 @@
dev_dbg(dev, "Device is in %x state, moving to %x", phy->curr_ensm_state,
ensm_state);

• ensm_config_2 = ad9361_spi_read(phy->spi, REG_ENSM_CONFIG_2); // if in SPI ctrl mode (NOT pinctrl) we nedd to set this TXNRX bit

if (phy->curr_ensm_state == ENSM_STATE_SLEEP) {
ad9361_spi_write(spi, REG_CLOCK_ENABLE,
@@ -4047,6 +4049,7 @@
switch (ensm_state) {
case ENSM_STATE_TX:
val |= FORCE_TX_ON;

•   ensm_config_2 |=  TXNRX_SPI_CTRL; // Set bit for TX
  if (phy->pdata->fdd)
      rc = -EINVAL;
  else if (phy->curr_ensm_state != ENSM_STATE_ALERT)
  

  @@ -4054,6 +4057,7 @@
  break;
  case ENSM_STATE_RX:
  val |= FORCE_RX_ON;

•   ensm_config_2 &=  ~TXNRX_SPI_CTRL; // clear bit for RX
  if (phy->pdata->fdd)
      rc = -EINVAL;
  else if (phy->curr_ensm_state != ENSM_STATE_ALERT)
  

  @@ -4097,6 +4101,10 @@
  goto out;
  }

• if ((!pinctrl) && (phy->pdata->tdd_use_dual_synth==0) && (phy->pdata->fdd==0)) { // only for TDD, Single Synth, NOT pinctrl mode

•   rc = ad9361_spi_write(spi, REG_ENSM_CONFIG_2, ensm_config_2);
  

•   dev_info(dev, "Extra write for TDD Single_Synth REG_ENSM_CONFIG_2 0x%08x ",ensm_config_2);
  

•   };
  

  rc = ad9361_spi_write(spi, REG_ENSM_CONFIG_1, val);
  if (rc)
  dev_err(dev, "Failed to restore state");

CP_CURRENT must be an device tree attribute.

It depends on the external loop filter design. There are other options such as Phase Detector Polarity and Bleed control. Which are also highly applications specific and must be adjustable.

https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/frequency/adf5355.c#L714
https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/frequency/adf4350.c#L408
https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/frequency/adf4360.c#L1087

Based on the headless.c code the MYKONOS_waitInitCals can easily trigger watchdogs because of the up to 60 seconds it can be in that loop.
do
{
retVal = MYKONOS_readArmCmdStatusByte(device, opCode, cmdStatByte);
if (retVal != MYKONOS_ERR_OK)
{
return retVal;
}
/* If error flag is non zero in [3:1], - return error */
if ((*cmdStatByte & 0x0E) > 0)
{
CMB_writeToLog(ADIHAL_LOG_ERROR, device->spiSettings->chipSelectIndex, MYKONOS_ERR_ARMCMDSTATUS_ARMERROR,
getMykonosErrorMessage(MYKONOS_ERR_ARMCMDSTATUS_ARMERROR));
return MYKONOS_ERR_ARMCMDSTATUS_ARMERROR;
}
if (CMB_hasTimeoutExpired())
{
return MYKONOS_ERR_WAITARMCMDSTATUS_TIMEOUT;
}
} while (*cmdStatByte & 0x01);

Only looking a resolution of 1 ms there does not seem to be much point of checking so frequently. CMB_wait_ms(1) should probably be added to this loop

In commit bbb78df it looks like GPIOs are being added to debugfs; I doubt this will be accepted upstream.
Last time we spoke I believe Robin made the suggestion that GPIOs could be exposed via the gpio sub-system. Can we please do that instead?

Hi,

The generic ad_adc.c driver seems to not be linked to the right Kconfig option.

Should it be moved to something like this?

-obj-$(CONFIG_ADMC) += admc_adc.o admc_speed.o admc_ctrl.o ad_adc.o
+obj-$(CONFIG_ADMC) += admc_adc.o admc_speed.o admc_ctrl.o
+ 
+obj-$(CONFIG_AD_ADC) += ad_adc.o

Thanks,

This issue appears in the axi_dmac_fill_linear_sg function in dma-axi-dmac.c:

When the DMA_LENGTH_WIDTH is 32, the chan->max_length variable is set to 2^32, and the formula used in the DIV_ROUND_UP macro creates an integer overflow:

#define __KERNEL_DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))

This results in the macro returning 0 and a divide-by-zero error in the next line of code, causing the following stack trace:

[   79.624443] divide error: 0000 [#1] PREEMPT SMP PTI
[   79.624450] CPU: 0 PID: 4225 Comm: iiod Not tainted 4.19.0 #31
[   79.624455] Hardware name: AMI AM F5x/msd/AM F5x/msd, BIOS 4.09.01 12/06/2019
[   79.624468] RIP: 0010:axi_dmac_fill_linear_sg.isra.23+0x70/0xe5
[   79.624474] Code: 48 c7 c7 38 c6 6f b2 42 8d 44 31 ff f7 f1 ba 2c 02 00 00 44 89 f1 41 89 c7 41 89 c0 e8 33 0d b5 ff 43 8d 44 3e ff 31 d2 31 f6 <41> f7 f7 ff c8 41 0b 45 00 44 8d 40 01 48 8b 44 24 38 4c 89 c2 39
[   79.624485] RSP: 0018:ffffaba281bf3c00 EFLAGS: 00010246
[   79.624492] RAX: 00000000000fffff RBX: 0000000088100000 RCX: 0000000000000000
[   79.624497] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000ffffffff
[   79.624503] RBP: 0000000000000001 R08: ffffffffb1958250 R09: 0000000000000498
[   79.624508] R10: ffffffffb16f1fc0 R11: ffffffffb30c0f0d R12: 0000000000000002
[   79.624514] R13: ffffa1761af13684 R14: 0000000000100000 R15: 0000000000000000
[   79.624520] FS:  00007f04bdc2b640(0000) GS:ffffa1761da00000(0000) knlGS:0000000000000000
[   79.624527] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   79.624532] CR2: 00007f04b4001db8 CR3: 0000000457b24004 CR4: 00000000003606f0
[   79.624538] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   79.624543] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   79.624548] Call Trace:
[   79.624558]  axi_dmac_prep_slave_sg.cold.29+0xf5/0x14e
[   79.624568]  iio_dmaengine_buffer_submit_block+0x19f/0x1e0
[   79.624578]  axiadc_hw_submit_block+0x1c/0x50
[   79.624585]  iio_dma_buffer_submit_block.part.9+0x29/0x50
[   79.624591]  iio_dma_buffer_enable+0x8f/0x130
[   79.624599]  __iio_update_buffers+0x3bf/0x8b0
[   79.624607]  iio_buffer_store_enable+0x7f/0xe0
[   79.624615]  kernfs_fop_write+0x107/0x180
[   79.624624]  __vfs_write+0x35/0x180
[   79.624632]  vfs_write+0xa4/0x1a0
[   79.624638]  ksys_write+0x4e/0xb0
[   79.624646]  do_syscall_64+0x47/0xf0
[   79.624653]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   79.624659] RIP: 0033:0x7f04bf0d94cf
[   79.624664] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 79 3f f9 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 cc 3f f9 ff 48
[   79.624675] RSP: 002b:00007f04bdc2a2b0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
[   79.624682] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f04bf0d94cf
[   79.624688] RDX: 0000000000000002 RSI: 00007f04b4000e70 RDI: 000000000000000a
[   79.624693] RBP: 00007f04b4000e70 R08: 0000000000000000 R09: 00007f04b4000000
[   79.624699] R10: 0000000000000070 R11: 0000000000000293 R12: 0000000000000002
[   79.624704] R13: 00007f04b4000bd0 R14: 0000000000000002 R15: 00007f04bf1ad720
[   79.624711] Modules linked in:
[   79.624743] ---[ end trace 963fe9dc5135c760 ]---
[   79.624752] RIP: 0010:axi_dmac_fill_linear_sg.isra.23+0x70/0xe5
[   79.624758] Code: 48 c7 c7 38 c6 6f b2 42 8d 44 31 ff f7 f1 ba 2c 02 00 00 44 89 f1 41 89 c7 41 89 c0 e8 33 0d b5 ff 43 8d 44 3e ff 31 d2 31 f6 <41> f7 f7 ff c8 41 0b 45 00 44 8d 40 01 48 8b 44 24 38 4c 89 c2 39
[   79.624768] RSP: 0018:ffffaba281bf3c00 EFLAGS: 00010246
[   79.624777] RAX: 00000000000fffff RBX: 0000000088100000 RCX: 0000000000000000
[   79.624782] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000ffffffff
[   79.624788] RBP: 0000000000000001 R08: ffffffffb1958250 R09: 0000000000000498
[   79.624793] R10: ffffffffb16f1fc0 R11: ffffffffb30c0f0d R12: 0000000000000002
[   79.624799] R13: ffffa1761af13684 R14: 0000000000100000 R15: 0000000000000000
[   79.624805] FS:  00007f04bdc2b640(0000) GS:ffffa1761da00000(0000) knlGS:0000000000000000
[   79.624811] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   79.624816] CR2: 00007f04b4001db8 CR3: 0000000457b24004 CR4: 00000000003606f0
[   79.624822] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   79.624829] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Are these correct? I thought -89.75 to 0 was only valid?

https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/adc/ad7124.c#L690

Doesn't probe for the device, and fail if there isn't anything attached. This means that enabling the driver in the kernel makes it show up, even if no device is actually attached.

There is a device ID register, that we do not check.

mutext_init() is missing.

Hi!

The files in linux/drivers/iio/adc/mykonos/ are marked with the following statement: "Released under the AD9371 API license, for more information see the "LICENSE.txt" file in this zip file."

There is no LICENSE.txt file to be found, nor are the files on GitHub being presented in a zip file (I presume the statement is an artifact left over from a time when the files were distributed in a zip file, and accompanied by a LICENSE.txt file).

Can you please clarify what license applies to the files in linux/drivers/iio/adc/mykonos/ ?

Many thanks!

The second and third examples of the documentation suggest it is possible to load a filter only for Rx or Tx paths. However, using the third example (Tx only) to feed filter_fir_config produces an error because ad9361_parse_fir() expects that both tx and rx variable are valid (code between lines 4963 and 4985). There's also a typo at line 4899, and a possible buffer overflow if the number of coefficients given in the file is bigger than 128.

I don't know whether this is a bug in the driver code or a documentation error, but in case of the former, a patch like this one should be enough to fix it.

The kernel won't compile if AHCI is enabled. I was able to get it to compile by copying the ata directory from the 4.05 release, and also linux/libata.h. I'm still testing the driver now, but it does load ok.

The raw value of this attribute is a 16-bit signed integer. However, the 16-bit spi data was assigned with to an int without sign-extension. This will cause the attribute to be positive and (doubled) in negative revolutions.

Same thing with the temperature attribute. Temperature is signed 12-bit stored as signed 16-bit integer but, was stored as int without sign extension.

Hi,

Looking at drivers/iio/frequency/ad9517.c it seems like the driver cannot update the VCO divider at runtime.
I'm not familiar with the clock framework but would converting st->div0123_freq to hw_clk structures and making it a parent to the ad9517_clk_div structs be the right approach?
I imagine updating the rate of a parent clock will trigger a set_rate for all children.

Thanks,
Liam

Trying to compile ad7768 as part of the kernel results in a linker error:

WARNING: "return_address" [vmlinux] is a static EXPORT_SYMBOL_GPL
  MODINFO modules.builtin.modinfo
  LD      .tmp_vmlinux1
/home/user/build_test_light/host/bin/arm-buildroot-linux-gnueabihf-ld: drivers/iio/adc/ad7768.o: in function `hw_submit_block':
ad7768.c:(.text+0x100): undefined reference to `iio_dmaengine_buffer_submit_block'
/home/usert/build_test_light/host/bin/arm-buildroot-linux-gnueabihf-ld: drivers/iio/adc/ad7768.o: in function `ad7768_probe':
ad7768.c:(.text+0x834): undefined reference to `devm_iio_dmaengine_buffer_alloc'
/home/user/build_test_light/host/bin/arm-buildroot-linux-gnueabihf-ld: drivers/iio/adc/ad7768.o:(.rodata+0x84): undefined reference to `iio_dmaengine_buffer_abort'
/home/user/build_test_light/host/bin/arm-buildroot-linux-gnueabihf-ld: drivers/iio/adc/ad7768-1.o: in function `hw_submit_block':
ad7768-1.c:(.text+0xd4): undefined reference to `iio_dmaengine_buffer_submit_block'
/home/user/build_test_light/host/bin/arm-buildroot-linux-gnueabihf-ld: drivers/iio/adc/ad7768-1.o: in function `ad7768_probe':
ad7768-1.c:(.text+0xc68): undefined reference to `iio_dmaengine_buffer_alloc'
/home/user/build_test_light/host/bin/arm-buildroot-linux-gnueabihf-ld: ad7768-1.c:(.text+0xc7c): undefined reference to `iio_dmaengine_buffer_free'
/home/user/build_test_light/host/bin/arm-buildroot-linux-gnueabihf-ld: drivers/iio/adc/ad7768-1.o:(.rodata+0xa8): undefined reference to `iio_dmaengine_buffer_abort'
Makefile:1077: recipe for target 'vmlinux' failed
make[2]: *** [vmlinux] Error 1

Currently when the gain tables are changed, the device maintains the same index.
Which is not necessarily equal gain, based on the table being used.
Please see struct full_gain_table_abs_gain (https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/adc/ad9361.c#L459)
You can find the default gain table boundaries here:
https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/adc/ad9361.c#L579

A workaround can be to reinforce the manual gain whenever you cross a table boundary.
However ideally we fix-up this in the driver.

Move clk/clk-adf4360.c to iio/frequency/adf4360.c to make it easier to use from userland. I propose the following tasks which each may be several steps to accomplish this.

• Move clk/clk-adf4360.c to iio/frequency/adf4360.c (PR #419)

• Use Regmap API Required custom regmap_write not worth it since a write fn already exists.

• Refactor dt parse code from adf4360_probe (PR #423)

• Convert into an IIO driver retaining clk-provider capability (PRs #428, #433)

• Add IIO support to set frequency of PLL (PR #437)

• Add IIO support to set reference frequency (PR #437)

• Add sysfs register access (PRs #441, #449, #453, #454)

• Add lock detect via GPIO (PR #457)

• Add IIO support to power down chip via registers or GPIO on CE (PR #471)

• Add regulator support (PR #490)

• Add IIO access via attributes for some currently hard-coded register bits (PR #490)

• Update license / copyright & convert dt-bindings instructions to YAML (PRs #522, #523)

• Convert loop-filter-charger-pump-current dt property to microamps (PRs #528)

There's a typo in the cf_axi_tdd driver:

drivers/iio/adc/cf_axi_tdd.c:354:  static IIO_CONST_ATTR(enable_mode_available, "rx_tx rx_only tx_onlx");
drivers/iio/adc/cf_axi_tdd.c:361:  static IIO_CONST_ATTR(dma_gateing_mode_available, "none rx_only tx_onlx rx_tx");

Should be tx_only, while it is tx_onlx.

altera_4.9 branch running on an Arria10 only enables core 0.

kernel config has:
CONFIG_SMP=y
CONFIG_NR_CPUS=2

dmesg.txt

In drivers/iio/dac/ad5592r-base.c there appears to be a small violation of a mutex used in the ad5592r_read_raw() function. This issue manifested itself when attempting to read different ADC channels from different processes, which generated EIO errors somewhat randomly in any of the participating processes. Additionally, error messages in the kernel log were generated like the following: "Error while reading channel 4". This indicated that an ADC reading came from a different channel than expected. Reading from a single process never caused problems.

An example that should hopefully recreate the problem, assuming you have three consoles open and sitting in sysfs path for the device (e.g. /sys/bus/iio/devices/iio:device0), in one shell you can execute:

for (( i = 0; i < 10000; i++)) { cat in_voltage0_raw ; } ;

And in another shell:

for ((i = 0; i < 10000; i++)) { cat in_voltage4_raw ; } ;

If just those two shells are active (assuming from a fresh boot or modprobe), things seem to be okay. But in the third shell execute:

for ((i = 0; i < 10000; i++)) { cat in_temp_scale ; } ;

This should produce many examples of the errors. This will persist even if you stop the third loop with the other two running. I believe I have tracked it down to this code path:

If the condition is true, the mutex is never locked. However, the flow of control proceeds to the end of the function where the mutex is then unlocked, which isn't great for any other process holding the lock. A small patch allowed me to test the idea. With the patch applied, I have stopped receiving the EIO errors whether in my code or the above examples.

Although the mainline kernel has switched over to using a private mutex for the device in this driver, this same code path exists there as well.

diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-base.c
index 095530c233e4..055e45b29cc5 100644
--- a/drivers/iio/dac/ad5592r-base.c
+++ b/drivers/iio/dac/ad5592r-base.c
@@ -417,7 +417,8 @@ static int ad5592r_read_raw(struct iio_dev *iio_dev,
                        s64 tmp = *val * (3767897513LL / 25LL);
                        *val = div_s64_rem(tmp, 1000000000LL, val2);
 
-                       ret = IIO_VAL_INT_PLUS_MICRO;
+                       /* We didn't take the lock and there's no more work to do. */
+                       return IIO_VAL_INT_PLUS_MICRO;
                } else {
                        int mult;

Hi I installed Linux on a set of Samsung NP900X5N laptops and have noticed 3 bugs. 2 of them I found in Bugzilla and replied to them (i915 and Nouveau issues). On other bug I haven't found so therefore a new one: https://bugs.freedesktop.org/show_bug.cgi?id=109178

My samsung-laptop.ko driver isn't loading. If I try to load it manually it complains about 'no such device".
I am not sure what it means. My best guess is that the driver is not suitable for the new hardware.

I did some reading and debugging. To my understanding the module checks the model and type of the laptop. The known models and types are stored in the struct:
"static struct dmi_system_id __initdata samsung_dmi_table[]"

It seems that the NP900X5N notebook is included in this list. With dmidecode -t chassis it shows:
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
Type: Notebook
Lock: Not Present
Version: N/A
Serial Number: 0F4C91CJ900346
Asset Tag: No Asset Tag
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Other
Security Status: None
OEM Information: 0x00000000
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0
SKU Number: Chassis

The struct includes:

	.matches = {
		DMI_MATCH(DMI_SYS_VENDOR,
				"SAMSUNG ELECTRONICS CO., LTD."),
		DMI_MATCH(DMI_CHASSIS_TYPE, "10"), /* Notebook */
	},

The hex data with dmidecode shows indeed 0A, while my (old) NP900X4D shows 09. So I think it is something else that prevents it from loading.

Oh btw, my Linux is running CSM, not EFI. However if I select CSM in the BIOS, it changes to CSM and EFI.

The rf_bandwidth cannot be set to any value, and the driver correctly recalculates it based on the current BBPLL and available dividers. However, this is not written back to the actual struct which is read back for the attribute. So you have no idea what the actual value is. This is true for TX and RX.

Hi Team@ADI,
For some diag/debug purpose, i had to merge code from adi linux to xilinx linux and during the build, this particular Kconfig results in build error.

Kconfig error: "recursive dependency detected"

with below lines

config AD7606
tristate
select IIO_BUFFER
select IIO_TRIGGERED_BUFFER

config AD7606_IFACE_PARALLEL
tristate "Analog Devices AD7606 ADC driver with parallel interface support"
depends on HAS_IOMEM
select AD7606
help
Say yes here to build parallel interface support for Analog Devices:
ad7605-4, ad7606, ad7606-6, ad7606-4 analog to digital converters (ADC).

  To compile this driver as a module, choose M here: the
  module will be called ad7606_parallel.

config AD7606_IFACE_SPI
tristate "Analog Devices AD7606 ADC driver with spi interface support"
depends on SPI
select AD7606
help
Say yes here to build spi interface support for Analog Devices:
ad7605-4, ad7606, ad7606-6, ad7606-4 analog to digital converters (ADC).

  To compile this driver as a module, choose M here: the
  module will be called ad7606_spi.

======================
Thanks

Hi everyone!
i can't manage to make configuration by Default of the kernel image for zynq_xcomm_adv7511.
i received the following error message:
$make zynq_xcomm_adv7511_defconfig

*** Can't find Default configuration "arch/x86/configs/zynq_xcomm_adv7511_defconfig"!

scripts/kconfig/Makefile:113: recipe for target 'zynq_xcomm_adv7511_defconfig' failed
make[1]: *** [zynq_xcomm_adv7511_defconfig] Error 1
Makefile:548: recipe for target 'zynq_xcomm_adv7511_defconfig' failed
make: *** [zynq_xcomm_adv7511_defconfig] Error 2

i already tried to compile the kernel Image using the Linux-xnlx repository but the tutorial that i follow specify this repository and the zynq_xcomm_adv7511 configuration
I am using the the gcc arm Compiler 7.3.0 (CROSS_COMPILE=arm-Linux-gnueabi-) and on the other repository it goes well to the arm Folder and not the x86... I don't understand why now the make command do the link to x86 folder.
i also tested with other configuration files for arm Architecture and the same result… Does someone has an idea?

small precision: i do the compilation on a virtual machine using Debian4.9 the host pc is Windows10 x64

In linux/drivers/iio/adc/xilinx-xadc-core.c (line 1008++), both vccint and vccaux refer to same register XADC_REG_VCCINT.

XADC_CHAN_VOLTAGE(0, 9, XADC_REG_VCCINT, "vccint", true),
XADC_CHAN_VOLTAGE(1, 10, XADC_REG_VCCINT, "vccaux", true),

I believe the driver doc is correct: https://wiki.analog.com/resources/tools-software/linux-drivers/iio-transceiver/adrv9009#observation_rx_signal_path

I believe something might be something wrong with these checks in kfifo's remove from function. Referring to the following code, I understand that we are doing two checks. (1) we check if the fifo has enough data, i.e. enough data to remove a single sample from the buffer, and (2) we check if we were successfully able to remove that data from the fifo.

if (kfifo_size(&kf->kf) < r->bytes_per_datum)
	return -EBUSY;

ret = kfifo_out(&kf->kf, data, r->bytes_per_datum);
if (ret != r->bytes_per_datum)
	return -EBUSY;

Unless I am missing something here, the above code just seems wrong for the following reasons:

1. kfifo_size returns the capacity of the buffer, not how much data is actually there, perhaps this should be kfifo_len?
2. kfifo_size returns the number of elements, not the number of bytes, so it doesn't make sense to compare the returned value to bytes_per_datum
3. kfifo_out takes the number of elements, and returns the number of elements, again the units are in elements, not bytes...

Hello,

i'm trying to compile adi_zynqmp_defconfig for arm64 but i get the next error log:

i have been viewing the code and i have seen that the struct that fails (iio_buffer) was edited recently.

CC drivers/misc/jesd204b/jesd_phy.o
CC drivers/misc/jesd204b/gtx7s_cpll_bands.o
CC drivers/misc/jesd204b/gtx7s_qpll_bands.o
AR drivers/misc/jesd204b/jesd204b_phy.o
CC drivers/misc/jesd204b/xilinx_jesd204b.o
AR drivers/misc/jesd204b/jesd204b.o
AR drivers/misc/jesd204b/built-in.o
AR drivers/misc/lis3lv02d/built-in.o
AR drivers/misc/mathworks/built-in.o
CC [M] drivers/misc/mathworks/mathworks_ip_common.o
CC [M] drivers/misc/mathworks/mathworks_generic_of.o
CC [M] drivers/misc/mathworks/mathworks_generic_pci.o
CC [M] drivers/misc/mathworks/mathworks_ipcore.o
LD [M] drivers/misc/mathworks/mwipcore.o
CC [M] drivers/misc/mathworks/mw_stream_channel.o
In file included from ./include/linux/dmaengine.h:20:0,
from drivers/misc/mathworks/mw_stream_channel.h:12,
from drivers/misc/mathworks/mw_stream_channel.c:12:
drivers/misc/mathworks/mw_stream_channel.c: In function ‘mwadma_allocate_desc’:
drivers/misc/mathworks/mw_stream_channel.c:90:26: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 5 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
dev_dbg(&mwchan->dev,"buf_phys_addr 0x%08lx, size %u\n", (unsigned long) tmp->phys, tmp->length);
^ ~~~~~~
./include/linux/device.h:1360:31: note: in definition of macro ‘dev_dbg’
dev_printk(KERN_DEBUG, dev, format, ##arg);
^~~~~~
drivers/misc/mathworks/mw_stream_channel.c: In function ‘mwadma_start’:
drivers/misc/mathworks/mw_stream_channel.c:296:86: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
dev_err(&mwchan->dev,"prep_slave_single failed: buf_phys_addr 0x%08lx, size %u\n", (unsigned long) mwchan->curr->phys, mwchan->curr->length);
^ ~~~~~~~~~~~~~~~~~~~~
%lu
drivers/misc/mathworks/mw_stream_channel.c: In function ‘mw_stream_chan_show’:
drivers/misc/mathworks/mw_stream_channel.c:1050:29: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘long int’ [-Wformat=]
return sprintf(buf, "%llu\n", atomic64_read(&rxcount));
~~~^
%lu
LD [M] drivers/misc/mathworks/mwipcore_dma_streaming.o
CC [M] drivers/misc/mathworks/mw_stream_iio_channel.o
In file included from drivers/misc/mathworks/mw_stream_iio_channel.c:12:0:
./include/linux/iio/buffer-dma.h:51:26: error: field ‘block’ has incomplete type
struct iio_buffer_block block;
^~~~~
./include/linux/iio/buffer-dma.h:101:20: error: field ‘buffer’ has incomplete type
struct iio_buffer buffer;
^~~~~~
./include/linux/iio/buffer-dma.h:156:9: warning: ‘struct iio_buffer_block_alloc_req’ declared inside parameter list will not be visible outside of this definition or declaration
struct iio_buffer_block_alloc_req *req);
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/misc/mathworks/mw_stream_iio_channel.c: In function ‘mw_stream_iio_buffer_preenable’:
drivers/misc/mathworks/mw_stream_iio_channel.c:114:86: error: dereferencing pointer to incomplete type ‘struct iio_buffer’
mw_ip_write32(mwchan->mwdev->mw_ip_info, mwchan->tlast_cntr_addr, indio_dev->buffer->length);
^
scripts/Makefile.build:314: fallo en las instrucciones para el objetivo 'drivers/misc/mathworks/mw_stream_iio_channel.o'
make[3]: *** [drivers/misc/mathworks/mw_stream_iio_channel.o] Error 1
scripts/Makefile.build:573: fallo en las instrucciones para el objetivo 'drivers/misc/mathworks'
make[2]: *** [drivers/misc/mathworks] Error 2
scripts/Makefile.build:573: fallo en las instrucciones para el objetivo 'drivers/misc'
make[1]: *** [drivers/misc] Error 2
Makefile:1024: fallo en las instrucciones para el objetivo 'drivers'
make: *** [drivers] Error 2

@commodo @larsclausen

looks like it should be:
static IIO_DEVICE_ATTR(rssi_gain_step_error, S_IRUGO | S_IWUSR,

Is this something that Linux users have not needed? Or is the function not achieve anything practical? I am filtering IQ data and using 10 log 10(I^2 + q^2) - rx_hardwaregain_chan0 + offset to get absolute but seems like mag squared values have a std deviation of at least 2.5 dBm even in manual gain mode. <- I'll ask about this bit in the forum

For some embedded systems, a workflow involving external kernel modules that implement IIO devices is more practical than working with in-tree sources. However, there are number of features in the IIO KConfig that can only be switched on by enabling a particular sensor. Some examples of these are:

• config IIO_TRIGGERED_EVENT
• config IIO_TRIGGERED_BUFFER
• config IIO_BUFFER_DMAENGINE

Please consider making it possible to enable this functionality in a kernel without having to select unused sensors.

I think this should be removed as some customers are using it: https://ez.analog.com/linux-device-drivers/linux-software-drivers/f/q-a/113808/ad9361-not-transmitting-when-configured-for-low-sampling-rates

I was trying to clone this repository in windows, using git bash, and the checkout of master fails, with the following 2 files not found error:
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h
Turns out windows doesn't allow file/folder name creation with "aux" since it is a reserved keyword, and an underscore is prefixed when these files are created on filesystem. ("_aux.c" or "_aux.h"). This issue persists with both cloning the git repo from the terminal, or downloading the zip and extracting the repo. Sorry if I am missing it out, but is this repository supported to work with only on a linux station? I know this is a linux kernel repo, but for my application, I am only interested in using some driver files (AD9694 transport layer support), and so was working with a windows dev environment and SourceTree

The driver is producing some wrong rates when not using the FIR.

For example, setting a rate of 6 MSPS I get:

dev 'ad9361-phy', attr 'rx_path_rates', value :'BBPLL:768000001 ADC:48000000 R2:24000000 R1:12000000 RF:6000000 RXSAMP:6000000'
dev 'ad9361-phy', attr 'tx_path_rates', value :'BBPLL:768000001 DAC:48000000 T2:24000000 T1:12000000 TF:6000000 TXSAMP:6000000'

This is just a 2-2-2 decimation, but you can get a 3-2-2 decimation fine.

The implementation in libad9361 does this when you force a FIR decimation of 1. This seems to work in the "copied" driver implementation in the test code here:https://github.com/analogdevicesinc/libad9361-iio/blob/master/test/gen_rates_test.c#L78
by setting phy.rx_fir_dec and phy.tx_fir_dec to 1.

Not really sure what is different in the shipping driver now.