Protecting the handlers' vector is not enough. Managing the interrupts
involves other tasks that must be serialized. Mainly to handle the first
request and the last free of a VIC handler.

The VIC internal locking (vec_lock) is not useful anymore, but I do not
remove it because theoretically the VIC should be an independent bunch of
code.

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

When possible, avoid statement-scope variable for a better maintanability
of the code.

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

If there are no reasons for a *_free() function to return an error, change
the return type to void

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

The spec->irq_lock is a SPEC spinlock, but we must protect VIC variables.
In order to make the VIC code independent, use a dedicated VIC spinlock

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Make the VIC code indipendently as much as possible

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Use the specular name: we used init, we should use exit

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

On spec driver remove, do not clean-up VIC stuff. The VIC should be cleaned
by the mezzanine driver when it release all its handlers (see patch f7ee35460).
Just leave a reminder for driver developer when something goes wrong.

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Interrupt resources are not properly released. Mainly two problems:

  1. on IRQ free the driver was using the IRQ number instead of the the
     component base address. So, the component IRQ handlers were never
     released

  2. on IRQ free, supposing that the first problem was not there, when
     all component's IRQ handlers were released the PCI IRQ handler (VIC
     dispatcher) should have released, but it was not. In consequence of this
     even if the driver was removed an interrupt can be handled by a
     ghost handler.

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

The Kbuild writesin 'src' the correct path to the source code automatically.
This avoid us to explicitly write 'M' variable

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
Acked-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
Acked-by: Alessandro Rubini <rubini@gnudd.com>

Benoit Rat authored 11 years ago and Alessandro Rubini committed 11 years ago

This also updates the links to binaries in the documentation.

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

- Remove only for write in #72557df7
- NetworkManger (Unbuntu LTS 12.04) insists on accessing to the phy
when it is used from LM32 and flood the dmesg so we remove the warning.

This also documents how to write the eeprom, using the new writable
file in sysfs.  A working image for the eeprom is included, for people
with devices that were not programmed by the manufacturer.

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

Theodor-Adrian Stana authored 11 years ago and Alessandro Rubini committed 11 years ago

This is needed so the gennum core (as opposed to the gennum chip)
can access the SPI flash from the newly-programmed fpga image.
With this gpio setting, both the lm32 from inside the fpga
and the host computer can read and write the flash device.

Signed-off-by: Theodor Stana <t.stana@cern.ch>
Acked-by: Alessandro Rubini <rubini@gnudd.com>

The device is master-enabled at boot time, but the disable_device()
at remove time clears it. pci_enable_device() doesn't re-enable, so
we need to also pci_set_master().

Otherwise DMA works at first load, and the machine freezes at second load.

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

Juan David González Cobas authored 11 years ago and Alessandro Rubini committed 11 years ago

For traceability purposes, we include commit descriptions
as MODULE_VERSION information in drivers that are deployed
in CERN control system.

Ideally, the commit description should be added to all the
binary blobs installed, but the kernel module is critical
in this connection, as it is crucial to trace back quickly
the whereabouts of installed .ko sources.

The module parameter eeprom=  accepts a list of filenames (looked for
in /lib/firmware) to fake eeprom images. The list is in probe order,
which means it is unpredictable if you have more than one spec card
plugged -- but it's the same every time your reload the module.

This is a tool for developers who want to experiment with eeproms, so
this "rude" approach to multi-card setups is not considered an issue.

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

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

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

Now we read the whole eeprom area with a single command. Reading
time is thus 1/3 of what it was, and initialization time goes
down from 2 seconds to 0.6 seconds.

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

fmc-bus is now fixed WRT the dev->release(). Now devices are correctly
released when their use count reaches zero. Thus, we can't release them
ourselves.

This commit picks the new fmc-bus and adapts th own releae method.

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

When using the SPEC as White Rabbit grandmaster, you need to feed it
with 10MHz, which would kill the computer with an interrupt flood.

DIO interrupts are now disabled if they consume more than 80% of the
total time, which usually triggers between 100kHz and 200kHz. Network
interrupts are not affected.

Thanks to Anders Wallin for reporting the problem and helping in the
diagnosis.

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

This is a long-standing bug, and completely my fault.  Since our i2c
is simply a bitbanging gpio-based interface, I need to add some delays
into the operations.  Without this, accessing eeprom worked with most
mezzanines but not with all of them. The measured speed was more than 1MHz.

The devices are rated at 400kHz, so delay 1.25 usecs at each output
operation (thus, writing is three such delay for each bit).  Addin the
unpredictable software delays I see slightly more than than 200kHz
in my test system.

The driver now takes 2.5s to read the whole eeprom, but there's ample
space to make it better by fixing the FIXME in spec-i2c.c .

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

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

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

Benoit Rat authored 11 years ago and Alessandro Rubini committed 11 years ago

NetworkManager tries to access the phy, so this WARN_ON is
pretty common if the daemon is running. Now we know who is
misbehaving, and the driver can keep silent (disclaimer: this
opinionated message is by Alessandro :)

Benoit Rat authored 11 years ago and Alessandro Rubini committed 11 years ago

When the user passes "gateware=", the code uses a wrong SDB entry
point: "Can't find SDB at address 0x630000" (with one too many zeroes.

Replace typoed constant values with WRN_SDB_ADDR.

SET_HI32(variable, highhalf) was meant to prevent warnings and
unneeded code to get the best of 32 and 64 bits. But I had a bug
in 64-bit mode. This is the trivial fix.

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

While building for a 64-bit host I found a few warnings in format strings.
One is corrected by using "%zi", and other ones are about resources.
Unfortunately %pR was added in 2.6.32, so to avoid introducing backporting
issues to our 2.6.24 cast the argument instead.

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

This includes a new version of the submodule and fixes the code
to match the new set of fields in the fmc structure. The biggest change
is in the i2c address, that is now hosted in the fmc structure (this
changes the spec-i2c file).

Also, use new fmc_reprogram().  The function allows to centralize
dumping the eeprom and the sdb tree, so the bus framework dumps or
not, and can be changed at run time.

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

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

commit "9d4d08e5

kernel: correct warning for uninitialized variable"
introduced a bug, so the process was not properly awoken. The
commit is reported to be by Benoit, but I edited it and introduced
this bug which was missing in his submission.

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

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

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

Juan David Gonzalez Cobas authored 12 years ago and Alessandro Rubini committed 12 years ago

Forgot to deallocate the fmc_device allocated in spec_fmc_create.

Signed-off-by: Juan David Gonzalez Cobas <dcobas@cern.ch>

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

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