Unfortunately, fmc-adc is too generic a module name, because we may
expect to have different ADC cards in the same VME rack, at a later
time (and all of them are fmc-adc, in a way).

Also, hardwiring the gateware name as "fmc/spec-fmc-adc-v1.1.bin" is
too specific -- what if 1.2 is a simple fix?

So, the gateware name is a simpler "fmc/adc-100m14b.bin" (which should
be hardware-specific enough while not including a version number.

The module is called fmc-adc-100m14b.ko.

The zio device name is "adc-100m14b" (the fmc- prefix would overflow
the 12-byte maximum device length -- forced by the control structure).
The trigger uses the same name (it's a separate namespace anyways.

This commit trivially updates the manual so all pathnames shown are
correct, leaving a serious manual review to a later time.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This has long been a pain for me, and even Federico agrees the initial
choice of names was wrong.  The common_info_get/common_conf_set
function are now renamed to hardware_read/hardware_write, because this
is what actually they are.

People reviewing the code would have a hard time before realizing that
info_get reads a machine register. I hope this solves the issue for
everybody else.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

We plan to base the FMC-ADC release on an official ZIO version.  So,
this allows removing the register descrition commit from the ZIO
submodule. Federico agrees, as far as I know.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This set of macros were proposed by Federico Vaga as part of ZIO, but
I refuse them, for several reasons.  Since this driver uses them
massively and they are not really zio-specific, what was zio-utils.h
is now a drivers-specific header.

This allows to avoid pulling the ZIO commit in master while still
not forcing massive changes to this driver, which is mostly working.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Part of the calculation was wrong, so offsets didn't properly work.
This commit fixes the offsets and turns their user-accessible
values from 0..0xfff to -5000..5000 as they are now expressed in millivolts.

Unfortunately the code changes more than strictly necessary.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Not all changes here are bug fixes, as I clarified a few minor
details. SPI was not working though, and I let the reader find the
5 bugfixes in this commit (5 bugs from 4 errors: one error is twin).

(note, I'm not upset with the original author, he already ecplained
and apologized)
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This commit redefines the calibration data structure. Mainly, it now
is a single structure. This allows to turn a constant number into a
sizeof and manage the whole structure as a single entity, preparing
for better management (like checking it is valid and fix endianness).
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This commit has very little technical effect, but makes stuff more readable:

  zfad_get_range(): renamed to zfad_convert_hw_range()
  zfad_convert_user_range(): new function, same as above by now
  zfad_calibration(): renamed to zfad_set_range() because this it is.

This also changes some management of the range values, to hide
hardware values as much as possible, and remove the magic numbers
(they now live only within the zfad_hw_range[] array.

As for the big switch of attribute settings, a comment now
explains where setting happens.  And for range settings avoid
using the calibration values for RANGE_OPEN, as the code picked
unpredicatable values, as RANGE_OPEN is out of array bounds.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

The four channels are selected by bits 1..4 not 0..3. This commit
defines them symbolically as well, in order to make the numbering
explicit.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Federico Vaga <federico.vaga@gmail.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This changes trigger selection: it is external by deafault and turned
to internal by setting "-c".  Also, it reorders the help message and
simplifies some things (for example by memsetting the config
structures to zero at the beginning.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

printfing dma_addr_t as %lli requires a cast, since it may be a 32-bit
item, like it is on my computer. I got meaningless numbers on printk.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Federico Vaga <federico.vaga@gmail.com>

Signed-off-by: Federico Vaga <federico.vaga@gmail.com>

Signed-off-by: Federico Vaga <federico.vaga@gmail.com>

Signed-off-by: Federico Vaga <federico.vaga@gmail.com>

Signed-off-by: Federico Vaga <federico.vaga@gmail.com>

Signed-off-by: Federico Vaga <federico.vaga@gmail.com>

Signed-off-by: Federico Vaga <federico.vaga@gmail.com>

Signed-off-by: Federico Vaga <federico.vaga@gmail.com>

Signed-off-by: Federico Vaga <federico.vaga@gmail.com>