- 08 Aug, 2019 1 commit
-
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
- 05 Aug, 2019 3 commits
-
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
- 31 Jul, 2019 9 commits
-
-
Federico Vaga authored
This reverts commit 265c63476db166c69724c66a30df7e6c6ef1873a.
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
Like this they are visible on the command line Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
This patch port the FMC ADC driver to use DMA engines to handle DMA data transfers in order to move out any custum dependency with the carrier. The dedicated code for `svec` and `spec` are not anymore useful, so I removed those files. Anyway, it is not completely true that we can get rid off the knowledge about the carrier; for instance the `svec` needs a special configuration because of the VME bus. The Linux kernel API does not offer a way to set the DMA context (usefull for VME transfers) to a transfer. So, I have to call the operation directly. In order to find the correct dmaengine channel suitable for the FMC-ADC instance, the dmaengine filter function compares the device instances. If we are on a SPEC, then the dmaengine is on the SPEC itself (in the gateware we have the gennum dma). So, the dmaengine and the FMC-ADC must have the same FMC carrier If we are on a SVEC, then the dmaengine is on the VME bridge. So, the dmaengine and FMC carrier share the same VME bridge. Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
The SVEC version allows DMA within a PAGE_SIZE (4KiB) window. This means that we cannot perform DMA transfers bigger than PAGE_SIZE (4K). The sg_alloc_table_from_pages automatically squash continguos transfers to improve performances, but we cannot use it. In order to avoid to avoid one `if`, I defined this new operation that is configured at probe time so that we can use a no_squash version when necessary. Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
- 22 Jul, 2019 2 commits
-
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
- 18 Jul, 2019 1 commit
-
-
Federico Vaga authored
This driver must handle only its own device. The carrier part will be handled by the carrier driver. We can assume that if this driver is driving an instance the carrier is working correctly (PLL is locked, DDR calibration is DONE, and the application design has been resetted) Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
- 29 Apr, 2019 2 commits
-
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
fmc-bus has been replaced by a simpler platform driver, this means that: - IRQ needs to come through the standard kernel API - Calibration data cannot be read from the fmc-bus, the user (through an udev rule for example) should pass this information to the driver instance. By default the card will run uncalibrated. - registration must happen by other means and not from fmc-bus like before. - FPGA must be programmed before, the driver cannot do it anymore Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
- 15 Apr, 2019 5 commits
-
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
- 19 Feb, 2019 7 commits
-
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
All calibration values are stored as little endian. For this reason we should convert all incoming and outcoming values from little endian to the host endianess. Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
- 18 Feb, 2019 7 commits
-
-
Federico Vaga authored
-
Federico Vaga authored
This program does nothing more than this: dd if=eeprom of=calibration_data ibs=1 skip=256 count=108 obs=108 But it takes the shape of a C program so that we can validate input and we can play with the offset (skip) based on our needs. And we can print them in a more readable format Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
Here we do a little hack because I'm already thinking about a future verison of this driver. Instead of providing a calibration binary attribute the driver offers an eeprom_config binary attribute where you can write data as if it was on the eeprom (calibration data included). The driver will extract the calibration and configure the ADC. I'm doing this because we plan to move to platform devices instead of fmc devices. For this reason the access to the eeprom will not be easy as today. To begin with we will have a binary attrbibute where you can write your eeprom content. Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Tristan Gingold authored
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
this patch indroduces an overflow bug: bb859ef7 drv bugfix according to ZIO offset is uV hwval is 32bit, but since user values are now bigger (uV) the multiplication can overflow. We use 64bit to avoid it. Signed-off-by: Federico Vaga <federico.vaga@cern.ch> Signed-off-by: Milosz Malczak <milosz.malczak@cern.ch>
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-
- 27 Nov, 2018 2 commits
-
-
Federico Vaga authored
-
Federico Vaga authored
the current index variable was not correctly incremented, with the consequence that under certain conditions the return value was wrong. Signed-off-by: Federico Vaga <federico.vaga@cern.ch> Co-Developed: Dimitris Lampridis <Dimitris.Lampridis@cern.ch>
-
- 22 Oct, 2018 1 commit
-
-
Federico Vaga authored
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
-